안녕하세요! 오늘은 기쁜 소식을 가지고 왔습니다~!동연디자인에서는 사무용 가구, 의자, 라운지 소파 등의 다양한 제품을 판매하고 있습니다!다양한 루트를 통해 상담을 진행하고 제품을 구매하실 수 있도록 해왔는데요~!이번에 좋은 기회를 얻게 되어 SK 스토아 홈쇼핑을 진행하게 되었습니다!※ 방송시간 : 5월 9일 (목) 15:36~16:36 (1시간)※ 시청방법- 핸드폰 (SK STOA에서 실시간으로 시청 가능)- TV (위성, 케이블, 유선 등 지역에 따라 채널 상이)※ SK STOA 화면- 네이버에서 SK STOA 검색 혹은 http://m.skstoa.com/index 접속- 홈 화면의 (ON-AIR) 페이지에서 현재 방송 확인할 수 있습니다. TV와 핸드폰 외에도 컴퓨터를 통해 시청이 가능합니다 :)아래의 링크를 이용하시면 바로 방문하실 수 있어요! http://www.corp.skstoa.com/pcweb/tvplan이번에 판매를 진행할 제품은 위에서 보여드린 것처럼! 의자입니다 :)등받이의 깊이 조절이 가능한 제품으로 어린아이부터 성장기를 거쳐 어른이 될 때까지도 사용할 수 있는 제품이랍니다!어린이날 선물로도 제격인 제품이에요~!제품의 소개는 이전에 자세하게 포스팅한 적이 있답니다!아래의 링크를 이용해주세요~!다양한 기능이 담긴 고급스러운 제품이죠?!홈쇼핑을 통해서 저렴한 가격으로 판매를 진행할 예정이랍니다!놓치면 후회하실 거예요~!5월 9일, 오후 3시 반부터 4시 반! 절대 잊지 마시고 본방사수해주세요~!#SK스토아 #SK홈쇼핑 #홈쇼핑 #어린이날선물 #동연디자인 #가구 #의자 #홈쇼핑구매

스타트업은 항상 힘들다.자금 압박과업무 압박과시간 압박 등너무나 많은 스트레스 속에서 창업자들은 하루하루 버텨나간다.어느 대표님이 그러더라."2년째 계속 힘들다 보니 이젠 힘들다는 말도 지겹다."CEO의 약자가 무엇인지알고 있는가?한 분이 매우 공감 가는 말을 하더라.C: 씨발E: 이 짓을 O: 오~언제까지 해야 하는 거야?그러다 보니다들 어느 정도 기업가치를 올리면팔아버리고 사업 접으려는 사장님들이 많아지지.어느 정도 그 마음은 공감한다.그만큼... 아슬아슬한 리스크를 지고,하루하루 고군분투하는 삶의 연속이니까.그래도 어쩌겠어?각오하고 시작한 거 이왕이면,처음 세운 뜻을 다시 되뇌면서우린 꿈을 구현해 가는 사람들이잖아. 나의 월요일은 항상 기쁘다.기다려지고, 행복하다.일이 안 힘드냐고?아니, 진짜 많이 힘들다.피곤하고, 짜증 날 때도 있다.그것과는 별개로 여전히 사업은 즐겁다.나라고 매 순간 웃으면서 살아가는 것은 아니다.진지하게 심각한 고민으로 인상이 찌푸려져 있을 때도 있고,일이 잘 안 풀려 모든 일을 다 정지시키고 한 일주일 정도잠수 타고 싶을 때도 있다.그럴 때,아침마다 나는 거울과 대화를 한다."야! 나는 너를 잘 알잖아~ 오늘도 널 응원해"출근길에 받은 한 통의 전화!나와 동갑내기 창업자의 넋두리에 마무리는..."잘 하고 있어. 너무 고민하지 말고 좀 쉬든지."(출처: 허영만 작가님의 "식객")나는 응원이라는 말을 참 좋아한다.나에게 힘내라는 말보다 응원한다는 말이 너무 당긴다.힘들어서 지쳐있는데힘내라는 말은 얼마나 잔인한가.왠지 힘내서 더 몰아붙이라는 느낌으로 받아들여진달까?"힘내라~""파이팅"내가 너무 예민한가보다.좋은 의미로 건네는 말인데개인적으로힘들 때, 힘내라는 말은 공감되지 않는 인사말이다.너무 잦게, 너무 흔하게 쓰다보니 그런가?어쩌면 나와 거리가 있고, 나의 상황에 공감하지 않은 일상적인 위로이다.그에 반해 내가 좋아하는"응원한다"는 말은나의 힘듦을 어렴풋이나마 알고 있는 사람이나와 같은 상황을 비슷하게나마 공감하기에 할 수 있는 연대감 있는 위로이다.응원과 힘내라가 뭔 차이가 있냐고 물을 수 있다.개념적으로 응원은 여러 가지 의미를 가진다.힘내라고 말하는 것도 응원이겠지만,당신이 무얼 하든, 어떻게 하든전적으로 믿고, 지지한다는 뜻이 내포되어 있다.힘을 더 낸다면, 그것을 지지한다.잠시 쉬어야겠다면, 그것도 지지한다.포기하고 단념한다면, 그것도 지지한다.당신이 나의 의사에 따르는 것이 아니라,당신이 당신 자신의 판단으로 행동하는 것을난 믿고 지지한다.그런 의미로 난 당신을 응원한다.쉰다는 것!불과 10여 년 전만 해도사람들은 쉬는 것을 소비적인 행동으로 보는 경향이 있다.나도 그리 많이 쉰 적이 없는 사람이라이런 말은 할 자격이 없지만,쉬는 것은 생산적인 행동이다.이런 면에서 난 참 생산적이지 못 한 놈이다.쉬는 것은 재충전의 시간이다.힘이 고갈되면 힘을 짜내는 것이 아니라재충전을 해야 한다.그간 나는 휴가는 별로 없었다.어쩌면 정신없이 살아가면서도힘이 남아있었나 보다.그리고퇴근해서 가족과 함께 보내는 시간을 통해 늘 재충전이 되어왔었나 보다.나에게는 가족이 나의 충전소이다.그리고 포기하고 단념하는 것!모든 일에 무조건 끈기 가지고 매달리는 것도 어리석다.어떤 때에는 물러설 줄 알아야 한다.아까워도 포기해야 할 때가 있다.포기한 사람에게 "넌 왜 끈기가 없니?"라는 말보다는"수고했어!"라는 말이 더 필요하다.포기해야 하는 사람의 심정은옆에서 바라보는 사람보다 더 처참하다.더 고민을 많이 했고,더 두려움에 떨어야 했으며,더 자신과 치열하게 싸워서내린 결정이다.그렇기에 우리는 박수를 보내야 한다.비꼬거나, 내 그럴 줄 알았다 하는 식의 박수가 아니라진심으로 그의 선택을 존중하고, 새로운 출발을 응원하는박수를 보내야 한다.(같은 눈높이에서, 같은 것을 각자의 개성적인 시각으로 재해석하여 의견을 나누는 것이 스타트업의 미팅)공감이란 것은 조언하거나 가르치려는 입장에서 나오지 않는다.공감이란 것은 같은 선상에서 바라보려는 입장에서 나온다.회사 내에서 공감이 그러하다.경직된 조직체계와 상급자의 위치에서 직원들을 바라보면, 공감이 생기지 않는다.같은 입장에서 바라보려 하는 자세가 중요하다.스타트업의 수평적인 조직의 결과는단지, 같은 테이블 위에서 자유로운 분위기가 아니다.복장이나 호칭의 문제가 아니다.연공서열이나 나이, 경력의 틀을 깨는 것은 "수단"일뿐이다.수평적인 조직문화의 결과는 "공감"이다.공감하기 위해 우리는 수평적인 문화를 지향하는 것이다.직원들에게 "내 회사라는 주인의식을 가지라"라고 백날 말하는 것보다대표 스스로가 직원의 눈높이에서 바라보았을 때, "이 회사가 내 회사라고 인지"하도록 만드는 게 더 효과적이다.내 회사가 좋은데, 망하게 놔둘 사람이 어디 있는가앞으로 내 인생을 걸만큼 좋은 회사가 내 회사이면,더 좋게 만들려고, 더 힘을 낸다는 건 당연한 이치다.직원이 그렇게 느끼도록 회사를 만들어가려면,직원의 시각에서 회사를 바라봐야 한다.그러면, 무엇을 고쳐나가야 할지,어떻게 이끌어나가야 할지를 알게 된다.그다음은 바로 행동의 문제만 남는다어떤 정치인이 갑자기 지하철로 다니기 시작했단다.유독 선거철이 되면하루 최저생계비로 하루 체험하거나, 극빈층의 삶을 코스프레하기도 한다.그러나 그들을 바라보는 우리는 쇼인 것을 안다.(물론 제대로 된 정치인, 지도층도 있다.)그들이공감능력이 발달하지 않은 이유는 무엇일까?경험해보지 못한 세상이기에 그러하다.쌀이 떨어져 굶어 본 적도,차비가 없어 먼 길을 걸어 본 적도,다수의 남자들이라면 의무적인 군대를 가 본적도,남편과 자식을 위해 뜬 눈으로 걱정하는 어머니인 적도,가족을 위해 온갖 냉소와 거절 속에서 허리를 굽혀야 하는 아버지인 적도,신체의 불편함으로 사회 시스템에서조차 소외를 당한 적도 없다.물론 이런 것을 다 직접 경험한 사람만이 리더의 자격은 아니다.물리적으로도이런 경험을 다 할 수 있는 사람은 없으며,다양한 삶들을 모두 담아낼 수는 없다. 그렇지만우리에게는 간접경험이란 능력이 있다.커뮤니케이션!책이나 매체를 통해서든,사람들과 대화를 통해서든,만남과 협의를 통해서든...간접적인 경험을 통해 공감할 수 있다.상대가 말해도귀에 담아두지도 않기에뇌에 기억하지도 않으며, 마음으로 공감하지 않는다.우리는 머나먼 아프리카에 가 본 적이 없지만,그곳에 굶주리고, 아픈 아이들을 보고 눈물을 흘린다.TV프로에 소년소녀가장을 보며,ARS 후원을 하게 된다.우리는 사회적 약자에게부당하고, 불의한 대우가 있을 때,분노하고 마음의 쓰라림을 느낀다.보고, 들으면서 공감하기 때문이다.더 나아가 문제를 해결하고자 하는 욕구와방법에 대해 고민하며,더 나아가서는 행동으로 표현되어 더 나은 세상을 만드려고 한다.이것이 개인적인 범위에만국한되지 않는다.바로 스타트업에서도 동일하게 적용될 수 있다.더 크게는 분야별로, 국가적으로도 마찬가지다.공감하자.스타트업의 대표들은공감능력을 키워야 한다.배우고,듣고,나누고,행동해야 한다.직원들과의 공감뿐만 아니라고객과의 공감이 스타트업의 성공을 이끈다.오늘도 공감을 위해 글을 남긴다.#클린그린 #스타트업 #스타트업창업 #스타트업창업가 #창업자 #성공 #조언 #응원 #공감

‘Humans of TODAIT’의 두번째 주인공, 투데잇 안드로이드 개발자 전성윤을 만나봤습니다. 투데잇의 전설(★)이 된 그의 이야기를 함께 들어볼까요?(2016.08)✓ 전설윤, 그는 누구인가Q. 자기소개 부탁드려요.안녕하세요! 투데잇에서 안드로이드 개발자를 맡았던 전성윤입니다. 퇴사자 인터뷰를 하려니까 투데잇을 떠나는 게 정말 실감나네요. 작년 2015년 10월 경, ‘SW 마에스트로’ 과정에서 만난 분께서 대표님을 소개해주셨고, 좋은 인연으로 연결되어 투데잇과 함께 일하게 되었어요. 처음엔 안드로이드 개발자로 들어왔다가 지금은 안드로이드 개발 팀장직까지 맡고 있습니다. (당시 2016.08)Q. 투데잇을 떠나는 이유는 무엇인가요?사실 처음 입사할 때도 1년 정도 생각하고 있었어요. 일하다보니 투데잇이 너무 좋아져서 나가고 싶지 않았지만, 아무래도 군문제와 학교 복학 문제가 마음에 걸리더라고요. 그래서 여러 고민 끝에 할 수 없이 나가게 된 케이스예요. 결국 아쉽지만 이번 8월을 마지막으로 투데잇과 헤어지게 되었죠.Q. 별명이 전설윤이라고 하던데, 왜 전설이라고 불리는 건가요?저도 이번 인터뷰를 통해서 생각해보게 된 건데요. ‘전설’이라는 칭호가 지금은 한물 간 사람에게 붙는 것이 아닌가 싶어요. 다른 팀원분들이 들어오시게 되면서 자연스럽게 리즈시절이 지나게 되었죠. (웃음)다른 이유가 아니라, 혼자만 잘하는 것이 아닌 다 함께 잘하기 위해 애썼기 때문인 것 같아요. 업무에 있어 버려야 할 습관 같은 작업 처리 팁에 대해 새 팀원분들께 적극적으로 공유했고 적당한 선에서 체크해드렸어요. 7–8개월의 짬 덕분인지 기획 단계에서부터 개발 단계 때 준비할 것들이나 구현 방법들이 곧장 떠오르는 경지에 이르더라고요. 이런 점들이 다른 팀원분들이 좋은 퍼포먼스를 낼 수 있게 이끌어주는 역할을 했던 것 같아요. 또 그 분들도 잘 하는 방법에 대해 치열하게 고민했고 실제로도 다들 너무 잘해주셔서 결론적으로 이제는 혼자가 아닌 다 함께 잘하게 된 거죠.✓ 보안 전문가에서 투데잇 안드로이드 팀장으로 레벨 업!Q. 투데잇 안드로이드 팀장까지, 성윤님의 입사 초반부터 지금까지 업무 성장과정이 듣고 싶어요!입사 초기에는 솔직히 맘고생 많이 했어요. 내가 지금 당장 회사에 기여할 수 있는 점이 무엇일까 의욕적으로 많이 고민했지만, 그에 비해 개발 능력은 많이 떨어졌죠. 초기에는 무엇보다 제 개발 능력 수준에 대해 정확히 몰랐고 커뮤니케이션하는 방법이 미숙했던 것 같아요. 그 때마다 대표님, 개발팀장님께서 진심어린 피드백과 따끔한 조언을 계속 해주셔서 해결할 수 있었죠. 두 분의 노력덕분에 중반부터는 업무 처리 능력도 커뮤니케이션 능력도 많이 향상됐어요,이후에 본격적으로 개발자분들이 더 들어오고 협업이 시작되면서 1인 개발자에서 2인 개발자 체제로 바뀌게 되었고, 자연스럽게 그에 따른 새로운 이슈들이 생길 수 밖에 없었어요. 다른 개발자분들에게 업무 분담하고 리드하는 부분에서 어려움을 느꼈지만, 함께 잘 해결해나갈 수 있었죠 지금은 기획적인 틀을 잡고 누군가에게 일을 맡기고 내 일을 해내고 하는 여러 부분에서 팀장의 위치에서 역할을 잘 해내는 것 같아요. (웃음)Q. 그렇다면 특별히 힘들거나 어려웠던 일정은 무엇이 있었나요?되게 좋은 질문이에요! 전 개발자다보니까 이런 질문이 너무 좋네요. (웃음)구매페이지와 그룹 기능 작업이 좀 힘들었어요. 그 중에서도 프로버전 구매페이지 작업이 가장 힘들었는데요. 작업 자체가 힘들다기보다는 구매페이지에서 에러가 나면 유저의 신뢰도에 큰 영향을 주기 때문에 한치의 실수도 용납되지 않는 부분이라는 점이 부담이 됐죠. 처음엔 실수도 많았는데, 그 이후에 치밀하게 설계한 덕분에 두 번째부턴 버그가 터져도 바로 대처할 수 있었어요. 개인적으로 개발적으로 많이 성장한 느낌을 받았죠.그룹 기능 개발은 클라이언트 쪽에서 해결해야 하는 부분이 많아서 힘들었어요. 하지만 릴리즈 이후 유저분들이 격렬하게 환호해주신 덕분에 뿌듯하게 잘 마무리할 수 있었죠. 두 작업 다 힘들었지만, 굉장히 보람됐던 작업으로 기억에 남아요.Q. 유저들의 피드백을 보면서 얻은 게 많다고 하던데, 좀 더 말해주세요!“실제 유저와 소통하고 친근한 서비스를 제공하려고 노력하다보니 유저들의 피드백이 얼마나 소중한 건지 알게되더라구요.”투데잇을 다니기 전까지만 해도 저는 별 5개 짜리 리뷰가 당연하게 받아야할 칭찬이라고 생각했어요. 그래서 사실 크게 반응하지 않았었는데, 실제 유저와 소통하고 친근한 서비스를 제공하려고 노력하다보니 유저들의 피드백이 얼마나 소중한 건지 알게되더라구요. 당연히 좋은 피드백은 정말 힘이 많이 되었고, 좋지 않은 피드백도 굉장히 감사했어요. 사실 유저 입장에서 그냥 지워버리면 그만인건데, 우리 앱의 장점을 알아봐주시고, 개선할 점을 말해주시고 또 기다려주시는 거잖아요. 그런 유저분들 보면서 빨리 개선해드리고 싶단 생각이 들죠. 그 어떤 피드백보다 더 큰 동기부여가 되더라고요.✓ 투데잇 TALK“투데잇팀은 서로 부담없이 정말 효율적으로 커뮤니케이션을 해서 어떻게 하면 서로의 업무 컨텍스트를 빠르게 마무리할지 고민해요.”Q. 투데잇의 힘은 이거다!음 투데잇의 힘은 서로를 존중하고 커뮤니케이션을 중시하는 데에서 나오는 것 같아요. 결국 모든 문제의 결착점은 커뮤니케이션이거든요. 사소한 거라도 시기에 맞춰서 커뮤니케이션이 되어야 하는데, 개발팀과 비개발팀간의 커뮤니케이션이 사실 어렵잖아요. 하지만 투데잇팀은 서로 부담없이 정말 효율적으로 커뮤니케이션을 해서 어떻게 하면 서로의 업무 컨텍스트를 빠르게 마무리할지 고민해요. 누군가 못한 부분이 있더라도 절대 무시하지 않고, 서로의 업무를 존중하고 정식적으로 피드백을 공유하면서 문제를 잘 해결하기 위한 고민을 하죠.Q. 투데잇에서 제일 기억에 남는 순간이 있다면?투데잇에서는 많이 힘들었을 때부터 행복했을 때 그리고 소소한 일상들까지 전부 다 기억에 남아요. 워크샵이라고 가평에 가서 일한 적이 있었는데, 정말 놀지도 못하고 거의 일만했거든요. 근데 밖에 나와서 그런지 그 자체가 너무 재밌었어요. 일하면서도 되게 색다르고 즐거웠죠. (웃음) 제주도로 워크샵 갔을 때도 너무 재미있었고, 정말 매일 매순간이 기억에 남아요. 팀 분위기가 너무 좋아서 그런지 특별한 일들 뿐만 아니라 개발팀 회의할 때나 회사 메신저에서 웃고 떠들고 했던 것들처럼 아주 소소한 일상들까지 모두 에피소드였던 것 같아요. 깜짝 생일파티도 그렇고 되게 예정없이 나온 에피소드가 많았거 든요. 그런게 진짜 참된 에피소드 아닐까요?✓ 마지막으로…Q. 애정이 컸던 만큼 투데잇을 떠나기 많이 아쉬울 것 같아요.네 많이 아쉽죠. 전 투데잇에서 10개월 동안 정말 하루종일 개발만 했어요. 일 하는 게 너무 좋아서 거의 자취하다시피 야근도 매일 했었거든요. 좋아하는 사람과 좋은 분위기에서 재밌게 일하기도 했고, 또 어떤 목표를 이루기 위해 정말 치열하게 고민하고 일할 수 있었는데 이 부분들을 더이상 느끼지 못한다는 점이 많이 아쉬워요.음 아쉬운 사건을 말하라면, 맨 처음으로 앱 안에 코틀린을 적용해볼 때 너무 시간을 오래 끌었던 일이 있었어요. 잘 적용시킬 방법에 대해 혼자 고민하고 정리해보다가 늦어졌었는데, 다른 분들 일정에 피해를 준데다가 실수도 한두개가 아니었거든요. 그 때 제가 계획대로 잘 처리했으면 마케팅적으로나 여러 시도들을 해볼 수 있지 않았을까?하는 아쉬움이 들죠. 결국 개발자가 세운 일정에서 해내는 여부에 따라 회사에 큰 영향이 가고, 다른 팀에도 막대한 영향이 갈 수 있다는 걸 뼈저리게 깨달았어요. 그래도 이 사건 덕분에 업무적으로도 많이 성장할 수 있었던 것 같아요. 몸소 당해봤으니 그럴 수 밖에 없죠. (웃음)Q. 투데잇을 떠나며 마지막으로 하고 싶은 말이 있다면?“충분히 치열하게 일했고 다함께 즐겁게 소통하면서 일했기 때문에 언젠가 또 다시 만나지 않을까 싶어요.”개인적으로 아쉬운 점은 있지만, 충분히 치열하게 일했고 다함께 즐겁게 소통하면서 일했기 때문에 언젠가 또 다시 만나지 않을까 싶어요. 모든 투데잇 사람들과 연을 이어가고 싶기도 하고 특히 대표님께 보답하고 싶다는 마음이 크거든요. 처음 들어갔을 때, 아무 준비 안 돼있는 상태였던 절 믿어주시고 함께 일할 수 있는 기회를 주셨어요. 앞서 말한 것처럼 일하면서 초반에 실수도 많이 했는데 꾸준히 믿고 지금의 포지션까지 저를 밀어주셨다는 점이 너무 감사하거든요. 대표님께 보답하자! 투데잇에 보답하자!가 마지막으로 하고 싶은 말이에요. 저 나가더라도 아는 척해주셔야 해요..!Q. 투데잇을 꿈꾸는 개발자에게 한마디!음 투데잇에 들어오는 건 어쩌면 쉬울 수도 있어요. 저 같은 경우 30분 정도 면접을 보고 당일에 바로 함께하기로 했거든요. 하지만 중요한 건 본인이 ‘함께 성장하고 싶은 사람’인가?에 대해 생각해보셔야 해요. 또 투데잇과 방향성이 맞는지 스스로 생각해보고, 성장하기 위해선 어떤 태세를 취해야 하는지 고민해보아야 하죠. 만약 이런 성향이 맞지 않는 사람이라면 아마 들어오시더라도 투데잇과 잘 맞지 않아서 힘들 수도 있거든요. 투데잇에 들어오고 싶은 분들은 이런 부분들에 대해 한 번 깊게 고민해보셨으면 좋겠어요.#투데잇 #팀원소개 #팀원인터뷰 #팀원자랑 #기업문화 #조직문화 #개발자 #개발팀

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다. 오늘은 정말 셀 수 없이 많은 분들이 궁금해했던 주제인, '한국 아마존 판매자(미국 기준)의 미국 세법 적용 여부'에 대한 주제를 가지고 두 번 다시 의문을 갖지 않도록 완벽하게 설명을 해드리고자 합니다.소개말아마존 실무와 마케팅에만 신경 써도 시간이 모자란데, 세법까지 알아보려니 많이 힘드시죠? 특히 기업이 클수록 한국 본사가 아마존 US에 직접 진출하면서 본사에 대한 대한민국 및 미국 세법이 어떻게 적용되고, 그걸 신고하는 것은 또 어떻게 하는지 알아보려면 매우 막막할 것입니다. 이 칼럼은 "아마존 미국에 판매하는 한국 셀러가 미국에 세금을 납부해야 하는가?"라는 질문에 대해 다방면으로 설명하고 그 설명을 뒷받침하는 근거자료를 제시하는 방향으로 작성되었습니다. 위 질문 외에도 '아마존 매출 신고 방법, 수출 신고 시 영세율 매출에 포함해야 하는지, 부가세 환급 등' 궁금해하실만한 내용들이 상당히 많을 거라고 생각합니다. 하지만 글이 너무 길어지는 것보다 한 가지 질문에 대해 확실하게 답변을 드리는 것이 여러모로 좋을 것 같아, 본 칼럼의 내용을 위 주제 하나를 확실하게 답변드리는 것에 대해서만 모든 포커스를 두었습니다. 부디 이번 포스트 하나만으로도 여러분들이 그동안 궁금해했던 세법 관련 궁금증이 해소되길 간절히 희망합니다.세금의 종류전 세계 모든 나라에서 아래 두 가지 세금을 부과합니다:1) 부가가치세: 거래 단계별로 상품이나 용역에 새로 부가하는 가치이다. 곧, 이익에 대해서만 부과하는 일반 소비세. 2) 소득세/법인세: 개인/법인이 한 해 동안 벌어들인 돈에 대하여 액수별 기준에 따라 매기는 세금(출처: 네이버 사전)한국과 미국의 세법 용어 정리와 세금 구성국세 = Federal Tax주세(한국에선 존재하지 않음) = State Tax부가가치세/부가세 = Value Added Tax/Sales Tax한국과 미국의 세법 차이한국에서 부가가치세는 국가 단위로 관리됩니다. 미국의 부가가치세는 주 단위로 관리됩니다 (이 콘셉트를 많은 분들이 헷갈려 합니다). 한국과 미국 둘 다 소득세/법인세는 국가 단위로 관리됩니다.백마디의 말보다 그림으로 보여드리는 게 이해가 쉬울 것 같아서 아래와 같이 표현해봤습니다. 보시다시피 한국은 부가세와 소득세/법인세를 통틀어 '국세'라는 틀 안에 들어있습니다. 하지만 미국의 경우 소득세/법인세는 '국세'라는 틀 안에 들어있고, 부가세는 '주세'라는 틀 안에 들어있습니다. 따라서 미국의 경우 1) 부가가치세에 대해서는 '미국 주'의 기준과 법을 눈여겨봐야하며 2) 소득세/법인세에 대해서는 '미국 국가'의 기준과 법을 눈여겨봐야합니다.세금 신고와 납부 기준이제 다음으로 짚고 넘어가야 할 문제는 '어느 나라에 세금을 신고 및 납부해야 하는가?'에 대한 것입니다. 이 칼럼은 대한민국 사업자들의 입장에서 미국 세법을 바라보는 기준으로 작성되었기 때문에 대한민국 사업자의 입장에서 모두가 가지고 있을만한 질문을 하겠습니다: 사업 설립을 대한민국에서 했는데, 실제 판매는 미국에서 일어납니다. 사업 설립을 한국에서 했기 때문에 세금(부가세와 소득 모두) 신고와 납부를 한국 국세청에 해야 되나요? 아니면 판매는 어쨌거나 미국에서 일어나는 것이기 때문에 세금(부가세와 소득 모두) 신고와 납부를 미국 국세청에 해야 되나요?미국 소득세/법인세 신고와 납부에 대하여위와 같은 '이중 세금 부과' 문제에 대하여 미국과 한국이 1976년에 협정을 맺었고 (INCOME TAX TREATY 1976: UNITED STATES - REPUBLIC OF KOREA INCOME TAX CONVENTION), 이에 따라 세금 종류 중에 '소득세/법인세'에 해당하는 세금의 신고와 납부는 이중으로 부과되지 않도록 국제법으로써 정했으며, 결론만 말씀드리자면, "세금 중에 '소득세/법인세'에 대한 신고는 본인의 사업장(Permanent Establishment)이 있는 국가에만 신고하고 납부"하도록 정했기 때문에 아마존US에 판매하는 한국 셀러는 미국 소득세/법인세가 아닌 한국 소득세/법인세만 적용받습니다. 참고로, 이 글을 읽고 계신 분들은 아마존US에 판매하는 대한민국 셀러들일 것이기 때문에, FBA 창고에 상품을 보관하여 아마존에게 배송을 위탁하는것이 Permanent Establishment 기준에 적용받는지를 궁금해하실 겁니다. 위 TREATY의 ARTICLE 9 3항 (b)절에 따라, 아마존 FBA 창고에서 단순히 물건이 보관되고 배송되는 것은 Permanent Establishment 기준이 적용되지 않습니다.두 번째로, 아마존에 입점할 당시에도 진행하는 Tax Interview인 Form W-88EN을 통해서도 미국 세법에 적용받지 않는 Foreign Entity라고 입장을 밝히기 때문에, 이 부분에서도 대한민국 셀러는 미국 소득세/법인세를 적용받지 않는다는 주장을 할수가 있습니다.INCOME TAX TREATY 1976 UNITED STATES - REPUBLIC OF KOREA INCOME TAX CONVENTION.pdf근거자료: 아마존 입점 시 제출하는 Tax Interview: Form W-8BEN (미국 소득세/법인세 면제 양식) 아래 스크린샷 참조근거자료: INCOME TAX TREATY 1976 (LETTER OF SUBMITTAL 3번째 문단, ARTICLE 8, ARTICLE 9)한 마디로, 미국의 소득세 및 법인세에 해당하는 주체가 아니라는 뜻미국 부가세 신고와 납부에 대하여그렇다면 '부가세'에 대한 신고는 어떻게 해야 할까요? 여기서부터 많은 분들이 헷갈려 하기 시작합니다. 위의 그림에서 보여드렸듯이 한국 부가세는 국세로 지정되어있지만, 미국 부가세는 주세로 지정되어있습니다. 따라서 방금 전에 언급한 '미국과 한국의 1976년 협정'은 '국가 단위'로 징수하는 국세, 즉 미국의 입장에서는 '소득세/법인세'에 대해서는 협정을 체결하고 결론을 지을 수 있었지만, 미국 세법상 부가세는 주 단위로 관리가 되기 때문에 국가 간의 협정 내용에 미국 부가세에 대한 내용을 협정 맺을 수가 없다고 생각하는 게 통상적입니다. 그래서 실제로 위 협정의 명칭도 'INCOME TAX TREATY'라고 표현되어있습니다. 국가:국가는 국세:국세만 논할 수 있기 때문입니다. 하지만 이것에 대해 아래 두 가지 사실로 인해 여러분들은 안심하셔도 됩니다.1) 위 협정을 자세하게 읽어보시면 아래와 같은 문구를 발견할 수 있습니다: ARTICLE 1 - Taxes Covered... this Convention shall also apply to taxes of every kind imposed at the National, state, or local level. 이 말인즉슨, 본 협정의 적용 범위는 국세에만 해당할 것이 아니라, 국가, 주, 그리고 로컬 지역 단위로 부과되는 모든 종류의 세금에 대하여 적용된다는 뜻입니다. 다른 말로 쉽게 이해하자면, 미국의 국세뿐만 아니라 주세까지도 대한민국 사업자에게는 미국 세금 신고 및 납부에 대한 의무가 이중으로 부과되지 않는다는 말입니다. 즉, 한국 부가세법만 적용받게 된다는 뜻입니다.근거자료: INCOME TAX TREATY 1976 (ARTICLE 1, ARTICLE 7)2) 애초에 대한민국 사업자들뿐만 아니라 아마존의 모든 3rd-party vendors(sellers), 즉 다른 말로 아마존이 직접 아마존의 이름으로 판매하는 게 아닌 '아마존에 판매자로 입점하여 판매하는 이들'의 매출은 애초에 미국 부가세(sales tax) 면제 대상입니다. 하지만 특정 주(본 칼럼을 쓰고 있는 2018년 7월 20일 기준 Washington 주와 Pennsylvania 주)들은 부가세(sales tax)를 부과하며, 다행히도 이 부분은 아마존에서 3p 셀러들을 대신하여 고객으로부터 징수하고 대납까지 하기 때문에 여러분들의 입장에서는 걱정할 필요가 없습니다. 점점 더 많은 주들이 이런 식으로 아마존에게 3p 셀러들의 매출분에 대해서도 부가세를 고객으로부터 애초에 '징수'하고 납부하도록 법을 변경하고 있는 추세입니다. 이것 역시 Washington 주와 Pennsylvania 주에서 주문하는 고객들에게 아마존이 알아서 처리해주듯이 나머지 주들에 대해서도 법이 바뀌는대로 3p 셀러들을 대신하여 처리해줄 것으로 예상됩니다만, 디지털 시대가 매우 빠른 속도로 발전하고 있는 점을 고려하여 여러분들께서도 이러한 세법과 정책 변화에 대해서는 눈여겨보시길 추천합니다.근거자료: https://en.wikipedia.org/wiki/Amazon_tax 근거자료: https://money.cnn.com/2017/03/29/technology/amazon-sales-tax/index.html증빙자료: 아래 스크린샷 참조 (아마존 3p 셀러의 실제 판매 및 세금 징수 내역)한국 소득세/법인세 신고와 납부에 대하여여기까지 이해했다면 이제 한국 국세청의 입장을 설명드리겠습니다. 아마존 FBA 판매를 하는 대한민국 사업자는 Permanent Establishment가 한국에 귀속되기 때문에 위에서 언급했듯이 한국 세법만 적용받게 됩니다. 그리고 한국 세법은 위 그림에서 보이듯이 국세: 소득세/법인세와 부가세가 있습니다. 세법에 대해 잘 모르시는 분들을 위해 다소 기초적인 개념부터 간단하게 언급하고 가겠습니다. 소득세/법인세가 발생하는 기준은, '(소득/매출 - 지출)*소득세율/법인세율'입니다. 다른 말로 순수익에서 소득세율 및 법인세율을 적용한 것이 바로 소득세/법인세입니다. 그럼 이 개념을 아마존에 판매하는 한국 셀러의 입장을 대입하자면 [소득/매출 = 아마존에서 발생한 매출] - [지출 = 아마존에서 발생한 각종 수수료]가 됩니다. 따라서, 아마존에서 조회 및 다운로드할 수 있는 Payment Reports에서 Income(매출)을 매출로 우선 잡고, Expense(지출)을 지출로 처리하여 아마존 판매를 하시면서 결정된 총 순수익을 한국 국세청에 신고하여 소득세/법인세를 정상적으로 신고하고, 그에 맞는 소득세율/법인세율을 적용받아, 최종적으로 소득세/법인세를 납부하면 됩니다.한국 부가세 신고와 납부에 대하여그럼 다음으로 아마존 판매 내역을 한국 국세청에 부가세로써 어떻게 신고하고 납부하는지를 설명드리겠습니다. 1) 부가세 신고: 아마존 판매 내역을 매출로 신고하는 것은 방금 위에서 말한 것처럼 Payments Reports에서 Income 내역을 매출로 잡게 됩니다. 아마존 매출은 수출 신고가 된 내역(수출 번호가 주어지는)이 아니기 때문에 '기타영세율' 매출로 잡게 됩니다 (아마존 매출의 한국 국세청 부가세 신고 부분에 대해서는 별도의 칼럼에서 자세하게 다룹니다). 2) 부가세 납부: 아마존에서 발생한 매출에 대해서는 수출을 장려하는 대한민국이 '영의 세율을 적용해주기 때문에' 납부할 부가세가 없습니다 (납부할 부가세가 없다고 해서 신고를 안하는 건 아닙니다. 여전히 부가세 신고는 해야합니다).위 내용 그 외에도 아마존 매출을 정확하게 부가세 신고하는 방법, FBA 재고를 발송할 당시에 수출신고한 내역을 영세율 매출 자료에 포함하는 등, 환율 적용은 어떻게 하는 등, 부가세 환급은 어떻게 이루어지는 등에 대한 궁금증이 많을거라 생각합니다. 하지만 이번 칼럼은 오직 "대한민국 사업자"가 미국에 납세 의무가 있는지 없는지를 알려주는 것에 중점을 두고 있기 때문에 이번 칼럼에서 다루지 않을 것입니다.마지막으로, 아래에는 미국 내 수입자 역할을 하기 위해 발급받는 EIN 넘버 (미국 수입자 통관고유부호)에 대한 FAQ입니다. 위 세법 내용과 연관 있는 내용이라 보너스로 준비해봤습니다보너스: 미국 수입자 통관고유부호에 대한 FAQ미국 수입자 통관고유부호를 발급받지 않고 빌리면 안 되나요?미국 수입자 통관고유부호를 발급받지 않고 빌리거나 타인의 것을 사용해서 FBA 입고하는 것이 현실적으로는 가능하긴 하겠지만, 저와 여러분과 같은 대한민국 아마존 FBA 판매자가 하고자 하는 것은 '한국에 있는 내가 미국 FBA 창고를 통해 아마존에서 판매할 나에게' 물건을 보내는 것이기 때문에 남의 미국 수입자 통관고유부호를 빌려서 쓴다는 것 자체가 어불성설입니다. 결국 이 물건(화물)이 최종적으로 팔릴 곳인 아마존에서의 판매 주체는 '나'인데, 한국에서 물건을 수출할 당시 미국에서 그 물건을 수입하는 대상이 내가 아니라 엉뚱한 다른 회사이면? 상식적으로도 논리적으로도 이치에 안 맞는 것입니다. 이번에 미국 세관 정책이 바뀐 것은 이미 예전부터 (2~3년 전부터) 말이 많았던 내용입니다. 근데 2~3년 동안 모두가 뒷전으로만 놓고 있던 문제가 드디어 당장 앞으로 다가왔습니다. 이젠 수입자가 무조건 필요합니다. 근데 여기서 또 '정석'이 아닌 다른 '편법'인 남의 미국 수입자 통관고유부호를 임의로 받아쓴다는 것은 결국 또 언젠간 문제가 발생할 소지를 만드는 것이나 다름없으며, 점점 아마존이 커지고 있고 미국 세관도 디지털 시대에익숙해지면서 발 빠르게 대응하고 있는 점을 고려했을 때 그러한 편법도 오래가지 않을뿐더러 나중에 문제가 생길 경우 그동안 벌였던 과오를 책임져야 할 수도 있는 위험을 감수하는 것은 절대 현명한 선택이 아니라고 생각합니다.그럼 제가 미국 수입자 통관고유부호를 발급받으면 미국 국세청에 세금을 납부해야 하는 건가요?'아니요, 안 내도 됩니다.' 미국 수입자 통관고유부호는 '미국 세금 납부 번호'가 맞습니다. 즉, 세금을 납부하기 위해 주어진 고유 부호입니다. 하지만 여러분들은 대한민국 사업자로서 애초에 납세 의무가 없기 때문에 미국 수입자 통관고유부호를 발행 받더라도 여전히 미국 국세청에 납세 의무가 없습니다. 미국 수입자 통관고유부호를 발행 받는 것은 납세를 할 수 있는 조건을 갖춤으로써 '수입자'의 역할을 할 수 있는 권한이 생긴 것뿐이지, 대한민국 사업자라면 미국 국세청에 납세 의무는 여전히 없다고 이해하면 됩니다.마치며이로써 많은 분들이 궁금해했던 대한민국 사업자의 입장에서 바라보는 미국 세법 적용 여부에 대한 궁금증이 풀리셨길 바랍니다. 위 내용은 제가 직접 연구하고 조사한 자료이기 때문에 별도로 세무 전문가와 상담해보실 것을 추천드립니다. 땀 흘리며 작성한 글이기 때문에 부디 무단 도용이나 무분별한 배포는 자제해주시기 바라며, 공유를 하실 경우 반드시 컨택틱이라는 출처를 밝혀주시길 바랍니다.그럼 오늘도 즐거운 글로벌 셀링 되세요! 컨택틱   서울특별시 강남구 강남대로 62길 11, 8층 (역삼동, 유타워)대표 전화: 02-538-3939이메일: support@kontactic.com유튜브: https://www.youtube.com/channel/UC8OxbQGAnMqWGpGj5weLcZA홈페이지: https://www.kontactic.com

Android App Build의 변화Android App 개발에서 빌드는 올해 중순을 기점으로 큰 변화를 가져왔습니다.Ant 에서 Gradle 로… Eclipse 에서 Android Studio 로…Android Studio 는 JetBrains 사의 IntelliJ 의 Community 버전을 커스터마이징한 것입니다.Gradle 은 Ant 의 빌드 기능 에 Maven 의 의존성 관리 기능이 접목된 빌드 툴입니다. 그만큼 제공하는 기능이 다양하며 동시에 의존성에 대한 문제도 함께 해결이 되었습니다.큰 변화는 장점과 단점 모두를 가져왔습니다. 대표적인 장점은 기존에 Eclipse 에서는 한계가 있었던 Plugin 기능이 더욱더 다양해졌다는 것입니다. 반면 갑작스럽게 바뀐 IDE 와 빌드툴은 여전히 큰 장벽으로 존재하고 있습니다.특히 Gradle 의 성능 문제는 줄곧 거론되었습니다. Eclipse 에서는 빠르게 빌드되던 것이 Gradle 기반으로 전환되면서 적게는 2배에서 5배 이상 오래 소요되는 문제를 가져오게 되었습니다.그러한 문제는 토스랩의 안드로이드 팀도 빗겨갈순 없었습니다.코딩-빌드-실행이라는 반복적인 패턴에서 빌드에 소요되는 시간이 개발의 흐름을 끊게 되는 상황에서 이를 개선하는 것은 필수적인 요소였습니다.이 포스팅은 그동안 잔디의 안드로이드 팀이 빌드 속도를 개선하기 위해 노력했던 흔적들의 모음입니다.New Android App Build System1. Bazel (Google)본디 Android 만을 위한 빌드는 아니고 iOS 까지 빌드 할 수 있는 통합 빌드 시스템이라고 보시면 됩니다. Google 의 빌드 시스템인 Blaze 에서 파생된 빌드 프로젝트로 현재 베타로 등록, 진행되고 있습니다.2. Buck (Facebook)Bazel 보다는 좀 더 다양한 언어를 지원하기 위한 프로젝트로 보여집니다. 실제로 Go, Rust 등 다양한 언어를 지원하는 빌드 툴이라고 생각하시면 됩니다.3. Pants (Twitter, FourSquare, Square)3개의 회사가 협동해서 만든 빌드 툴입니다.특이점은 Bazel 만 Mobile Platform 을 위해 개량된 빌드 툴이고 2개는 좀 더 다양한 빌드 환경을 제공한다는 것입니다.Build 시스템의 성능들1. Bazel| —-| 출처 : Bazel(http://bazel.io/docs/mobile-install.html)|구글의 자료에 의하면 기존에 비해 4배~10배 의 성능 향상이 있다고 합니다.2. Buck|**Gradle**|**Buck**| | ----|----|----|----| clean build|31s|6s|5x| incremental build|13s|1.7s|7.5x| no-op build|3s|0.2s|15x| clean install|7.2s|7.2s|1x| incremental install|7.2s|1.5s|4.8x| 출처: Buck (https://buckbuild.com/article/exopackage.html)Gradle 과 비교Gradle 팀에서는 Bazel 에 대해서 2015년 3월 포스팅에 아래와 같이 평하였습니다.Gradle 팀이 꼽은 Bazel 의 단점Bazel 은 구글의 특화 되어 있으며 쉽게 빌드 할 수 있을만큼 고수준 상태가 아니다확장성이 떨어진다.성능은 의존성이 해결된 이후의 문제이다.*nix 환경(Mac, 유닉스, 리눅스를 지칭)에서만 가능하다. 아직 많은 엔터프라이즈 툴들이 .Net 기반이다.(51%)플러그인을 위한 생태계가 구성되어 있지 않다.결론각각의 빌드 시스템들이 제공해주는 정보에 따르면 새로운 빌드 시스템은 큰 차이를 보여주는 빌드 환경을 제공해줍니다. 하지만 그런 이점에도 불구하고 잘 알려지지 않은 이유는 설정에 큰 어려움이 있기 때문입니다. Gradle 과 Android Plugin 에서 제공해주던 것을 직접 스크립트로 작성을 해야하며 각각의 의존성에 대해서도 직접적으로 명시를 해줘야 하기 때문에 정교하고 어려운 작업입니다. 또한 개별적으로 Plugin 을 제공하지 않아 Crash Report 를 위한 툴이나 Build 과정에서 추가적인 작업들이 필요한 경우에도 별도의 작업을 필요로 합니다.이러한 어려움에 기존의 Gradle 에서 새로운 빌드 환경으로의 전환은 쉽지 않으며 끊임없는 도전이 될 것입니다.그래서 잔디의 안드로이드 팀이 선택한 것은 Gradle 에서 성능 극대화 하기 입니다.Gradle 의 성능 개선하기1. Gradle 의 최신화$> vi $project/gradle/wrapper/gradle-wrapper.properties distributionUrl=https\://services.gradle.org/distributions/gradle-2.9-all.zip2. Android Gradle Plugin 최신화buildscrpt { dependencies { classpath 'com.android.tools.build:gradle:1.5.0' } }3. 최소 지원 기기 설정하기android { productFlavors { dev { minSdkVersion 21 } prod { minSdkVersion 14 } } }minSdkVersion 을 LOLLIPOP 으로 설정하게 되면 Build 하는 과정에서 큰 부분이 생략이 되고 특히 MultiDex 를 설정한 프로젝트에서 더 큰 효과를 보실 수 있습니다. Android 는 컴파일 및 패키징과정에서 Class to Dex 와 Merge Dex 을 거치게 됩니다. 이때 하지만 LOLLIPOP 부터는 art 기반이기때문에 Merge Dex 과정이 생략되기에 빌드 성능이 크게 개선됩니다. 단, API 21을 바라보기때문에 lint 나 개발 과정에서 API 특화 대응이 되질 않을 수 있습니다. 유의해서 API 를 사용해주세요.4. Gradle 속성 추가$> vi $project/gradle.properties org.gradle.daemon=true org.gradle.parallel=true org.gradle.jvmargs=-Xmx768m5. DexOption 추가android { dexOptions { incremental true } }※incremental 은 잠재적 오류가 있을 수 있으니 조심해서 사용하라고 합니다. (참고링크)빌드 성능 비교빌드 환경 : MacBook Pro Retina 2012 (i7 2.3Ghz, 8GB Ram)|**변경 전**|**변경 후**| | ----|----|----|----| SingleDex clean build|57s|47s|1.2x| SingleDex incremental build|16.3s|9.6s|1.7x| MultiDex clean build|71s|71s|1x| MultiDex incremental build|48s|17.6s|2.7x| Incremental Build 를 보면 Single Dex, Multi Dex 모두에서 주목할만큼 성능 향상이 있습니다. 개발 과정에서는 Incremental Build 가 대다수의 빌드임을 감안한다면 Gradle 옵션을 수정이 개발 과정에서도 충분히 좋은 성능을 얻을 수 있음을 알 수 있습니다.코딩-빌드-실행을 반복해야하는 패턴에서 최대한 코딩과 테스트에 집중할 수 있는 환경을 만들기 위해 했던 많은 시도들이 다른 안드로이드 개발자분들에게 큰 도움이 되었으면 합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #개발팀 #모바일 #안드로이드 #Android #꿀팁

As a yet minuscule startup, each member holds a significant power over the overall atmosphere of the team. And in our ultimate quest to make big waves in the data world, we need to make sure that the people at the helm are at least kind of cool. We think we’ve done a pretty good job so far in assembling a society of unique but equally driven members.So we bring you this seven-part series, one of each devoted to interviewing each of our members in detail, to give you an in-depth glimpse into the people responsible for bringing you the future of machine learning with Daria. Plus, we peppered the interviews with questions from Dr. Aron’s “The 36 Questions that Lead to Love”*, cherry picked to make work appropriate and concise, but interesting.(*actually falling in love with our members highly discouraged)Jungkap, the most recent addition to our team, made the move from sunny Santa Clara to Seoul, a city that is slowly freezing over as you read this. But he is used to the cold, Jungkap assures us, having spent his doctorate years in the apocalyptic winters of Michigan. When he’s not busy helping build Daria’s machine learning engine, Jungkap devotes his time to re-exploring Korea and taking care of his cats Jolie and Brad (named so before the tragic dissolve of Brangelina). Learn more about him here!Tell us about your role at XBrain.JP: I joined the team as a machine learning engineer, and my main task is to develop our machine learning engine. I have the task of researching and finding solutions to obstacles that hinder people from using automated machine learning technology with ease.What does a typical work day look like for you, morning to evening?JP: I get to work at about 9:15 AM (*the earliest, we note, out of any of the members), and check the Slack messages and emails I got overnight. Since I concentrate the best in the morning, I take a look at relevant articles and dissertations then. Since I didn’t major in machine learning at school, there’s a lot I still have quite a bit to learn, learning’s still a big part of my work process. After I’ve warmed up a bit, I study the code that’s already been written, and develop the parts that need to be developed. Then I have lunch with the team, which is a part of our culture that I really enjoy — a set meal time and a chance to have a conversation with other members. Today I did investigation into an issue we had with the machine learning engine, and worked on how to solve that problem based on my discoveries. I think I’ll be working on constructing that idea into actuality, with a lot of validation, tests, trial and error.What are the parts of your job that you enjoy the most?JP:I enjoy enhancing and optimizing processes, and actually seeing improvement after I’ve worked on something. I’m working on improving the system that we have right now, but a long-term project we have in mind is developing technology of XBrain’s own, and figuring out the needs of our customers. In order to do that, I’m spending a lot of time looking into any issues that we have with our current technology, hoping to get insight from the process.What are the least enjoyable/most challenging parts of your job?JP:The most challenging, rather than the least enjoyable, is issue definition. There are four types of situations to what can happen: either I find a problem that’s already been found, or something that’s so insignificant that no one cares, something that’s unsolvable, and, finally, an issue that’s both important and solvable. The fourth is what we’re going after, and the process is long and arduous, but I do enjoy it to a certain extent.Pick one item on your desk that tells us something about you.JP:I don’t have much stuff on my desk, which is something I also noticed about some of the Silicon Valley companies I visited while I was working in the States, like Twitter or LinkedIn. Most engineers’ desks just had computers on them, and I appreciate that sort of simplicity.Jungkap keeps things on his desk simpleWhat made you go into machine learning?JP:I was on the user end of machine learning technology in grad school and at work thereafter, and felt that the process of utilizing and understanding tools was too complex and difficult. I thought that I might find it fulfilling to optimize this process myself by becoming a machine learning engineer myself.Why XBrain?JP:First off, I really liked how the team was set up, people-wise. I was also struck by the competency of the members and the company culture, which suited me well. The values that XBrain pursues, and the ideas that it had about the future of machine learning technology was in line with my own. Not to see it simply as a source of profit, but as something that could potentially bring a lot of people a great deal of help.As our most recent member, what’s a vision you have for our team?JP:It’s not so much a vision as a direction we should be heading in — despite how machine learning is such a huge buzzword now, I think it’s still in the process of research and development. A lot of work needs to be done before it can start having a real impact in the world. What our role is, then, is to look far ahead and start with the basics.Recommend a movie for our next Cinema Society, please.JP:Downsizing, which hasn’t come out in Korean theaters yet, but I think it presents a lot of points for discussion.If you could sum up XBrain in three words or less?Serious, but quirky.If you could have dinner with any XBrain member, who would it be and why?JP: JY — we haven’t really gotten a chance to share a meal, and I feel like he’d have some interesting storiesWhat can you tell us about the JP 10 years from now?JP:He will probably be a more seasoned machine learning engineer, from his 10 years of research and studying. I’m a novice engineer now, but I’d like to be in a more senior position then, mentoring younger engineers.Given the choice of anyone in the world, whom would you want as a dinner guest?JP:Carl Sagan, who first got me interested in science and technology. In my head, he’s this benevolent father figure who would offer to mentor me.Would you like to be famous? In what way?JP:No…What would constitute a “perfect” day for you?JP:I think a “perfect” day is a day that’s yet to come. Is that too weird to publish?If you were able to live to the age of 90 and retain either the mind or body of a 30-year-old for the last 60 years of your life, which would you want?JP:The body, definitely. Minds can mature — bodies not so much.For what in your life do you feel most grateful?JP:Probably soundness of mind and body.If you could wake up tomorrow having gained any one quality or ability, what would it be?JP:Speedier comprehension upon reading something?What is the greatest accomplishment of your life?JP: Forging strong relationships with good people.What, if anything, is too serious to be joked about?JP:It depends on the audience, I think. Anything that they might consider offensive, or a weak spot, is off limits.Your house, containing everything you own, catches fire. After saving your loved ones and pets, you have time to safely make a final dash to save any one item. What would it be? Why?JP: My hard drive — it has everything on it.#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑 #머신러닝 #머신러닝엔지니어

"안녕하세요. 몇 년간 좋아하는 오빠에게 몇 번을 고백했습니다. 그리고 이번 4월 무렵 다시 한번 좋아한다고 고백을 했습니다. 하지만 제가 들은 대답이 뭔지 아세요? "다음 기회에!"라고 하더군요. 사랑 고백이 뽑기도 아니고, 다음 기회라니요.. 사랑에 있어 희망고문은 아니란 말이 떠올랐어요. 저처럼 이렇게 고백에 대한 황당한 대답을 들어본 사람이 또 있을까요?"-  스푼 유저 '꽃처럼' 님의 사연중A. 안녕하세요. 스푼 라디오입니다.'꽃처럼'님의 사연을 받고 사실 얼마나 당황스러웠는지 모르겠습니다. 얼마나 큰 용기를 가지고 고백을 하셨을지에 대한 짐작도 되었고, 무례한 대답을 듣고 얼마나 속상하셨을지도 느껴졌습니다. 몇 년간 좋아하는 사람에게 몇 번이고 진심을 담아 고백을 하셨다니 정말 많이 좋아하셨을 거라고 생각합니다.그리고 지금의 마음은 어떠하신지도 궁금하기도 합니다. 무례하기 짝이 없는 황당한 대한 들었어도, 좋아하는 마음은 쉽게 내 뜻대로 되지 않으니까요. 단지, 말씀하신 것처럼 사랑은 뽑기도 아니고, 사랑은 희망고문도 아니라는 걸 스스로에게 다시 한번 말해보는 건 어떨까 라는 생각을 해봅니다.내가 좋아하는 사람이 나를 반드시 좋아해 줄 필요도, 할 수도 없는 일임을 잘 아실 거라고 생각합니다. 그래서 짝사랑이 힘든 게 아닐까 싶습니다. 하지만, '꽃처럼'님의 진실된 마음을 가볍게 여기는 상대방에게 그 사랑과 시간은 너무 과분 하단 생각이 듭니다. 나를 사랑해주지 않아서가 아니라, 나의 대한 진심을 짓밟은 몹쓸 말을 하는 그런 사람에게 더 마음을 주기 너무나도 나의 마음이 너무 소중하다는 걸 알아주셨으면 좋겠습니다.나의 대한 가치와 존중을 알아봐 주는 사람에게 나의 마음을 쏟으셨으면 좋겠습니다. 물론 머리는 이해해도 마음이 따라주지 않아서 짝사랑이지만요. 적어도 나에 대한 진심에 모욕감을 주는 사람은 마음속에서 하루빨리 떠나보내 주는 게 전 좋은 선택일 것 같다고 감히 적어봅니다. 나도 분명 예전에 누군가를 짝사랑해 본 적이 있었던 것 같다. 지금은 까마득히 기억도 안 나긴 하지만 말이다.누군가를 좋아하고 사랑한다는 것은 세상에서 가장 아름답고도 아픈 일이 아닐까 싶다. 함께 하는 사랑은 행복한 순간도 있지만 이별을 겪을 수 있기에 가슴 아픈 상처가 될 수도 있고, 혼자 사랑하는 사랑은 혼자만의 감정을 추스르느라 어려운 일임이 분명하다.사람 마음이라는 게 참 분명 내 마음인데 왜 내 뜻대로 되지 않는 걸까? 아무리 그 이성적인 사람이라도 사랑 앞에선 마음 앞에선 결국 약자가 되어버린다. 짝사랑을 해 본 사람들은 아마 공감하지 않을까?1. 언제부터 왜 어떻게 이 사람을 좋아하게 됐는지 나도 잘 모르겠다.2. 그냥 이유 없이 어느 순간부터 나의 모든 시선, 마음 그리고 소중한 이 사람에게 향해있다.3. 그저 바라반 봐도 좋다가도 나도 모르게 은근슬쩍 이 사람으로부터 사랑받고 싶단 생각을 한다.짝사랑은 무조건적으로 마음 아프거나 새드 앤딩으로 끝나진 않지만, 가끔은 나 스스로를 위해서 새드 앤딩이 되어야 할 때가 있다. 사랑은 다른 사랑으로 잊힌다는 말이 있다. 신기하게도 다른 누군가를 좋아하게 되거나 연애를 하게 되면 시간이 흘러 전 사람이 잊히곤 한다. 마치 아무런 일이 없었던 것처럼. (물론 계속 기억에 남는 사람도 있다) 하지만 짝사랑도, 연애도 하면서 중요한 게 딱 한 가지 있다는 걸 최근 돼서야 정확히 아주 명확히 알게 된 사실이 있다.정말 뻔하고도 클리쉐 한 말이지만,'내가 나를 먼저 사랑해야 남을 사랑할 수 있다'라는 말이다. 누구나 쉽게 할 수 있고 많이들 들어본 이야기일 거라고 생각한다. 특히나 사랑에 약한 사람들이 있다. 평상시에는 정말 똑 부러지던 사람이 '사랑'이란 두 글자에 세상 바보 천지가 되는 사람들이 있다. 그건 바보라서가 아니라 그만큼 열정적이게 사랑을 하는 타입의 사람이라고 생각한다. 하지만 분명한 건, 타인을 사랑하면서 나를 사랑하는 법을 잃어버리면 안 된다라는 말을 하고 싶다. 내가 나를 존중하고, 나를 아끼고 사랑할 때 정말 다른 누군가도 나를 존중하고 사랑하고 아껴준다는 말이 뭔지 몇 번의 연애를 끝으로 알게 되었다. 짝사랑에서도 마찬가지이다. 나를 사랑해주지 않는 사람을 사랑하지 말란 말이 아니다. 그저, 짝사랑에도 상도덕(?)이 있다는 것과 고백에 대한 거절, 나의 진심에 대한 존중은 받아야 된다고 생각한다.누구에게나 사연은 있다.당신의 사연, 고민을 함께 나누는 공간 스푼 라디오입니다.사연에 채택되신 스푼 유저 '꽃처럼'님께 스푼 라디오 공식 굿즈를 선물로 보내드립니다.여러분의 이야기를 듣고 싶습니다. 스푼 라디오에 사연을 보내주세요.사연에 채택되신 분들께 소정의 선물을 보내드립니다.자세한 사항은 event@mykoon.com으로 문의 바랍니다.

탈 인구통계적 소비주의2017년은 trendwatching.com이 연례보고서 Post-demographic Consumerism(탈-인구통계적 소비주의)을 통해 인구통계적 정보로 고객의 소비활동을 예측하는 모델을 버리라고 주장한 지 3년이 되는 해입니다. 3년이 지난 지금 우리의 생활은 어떤 모습일까요?(Post-demographic Consumerism 리포트의 첫페이지.  ‘소비자 행동에 혼란스러워하는 사람은 당신만이 아니다. 이제 소비자들은 그들이 행동해야 하는 방식대로 행동하지 않는다’ 라는 문장이 등장합니다) 대중교통 안이나 팀원들과의 점심식사 자리처럼, 물리적으로 동일한 시공간에 타인과 함께 존재하는 순간에도 우리는 스마트폰으로 다른 친구와 카톡을 하고, 관심 있는 기사를 읽고, 셀카를 찍거나, 페이스북 고양이 동영상에 좋아요를 누릅니다. 같은 시공간에 존재한다고 해서 반드시 동일한 집단적 경험을 공유하지는 않게 되었습니다.특히 나이와 소득수준에 관계 없이 스마트폰 보급률이 높은 우리나라는 각자의 취향에 걸맞은 컨텐츠를 소비하고 생산하는 것이 자유롭습니다. 디지털 영역에서 개인별 파편화가 일어나기 쉬운 환경으로, 준거집단이나 인구통계와 같은 집단적 동질성에 기반한 마케팅 전략이 통하기 어려운 시장이란 해석도 가능합니다. (스티브 사마티노는 그의 저서 위대한 해체(The Great Fragmentation)에서 기존 산업사회의 논리가 파편화/해체된 후 디지털 융합으로 최적화 된다고 주장합니다. 개인의 파편화를 커버 아트로 채택한 것이 흥미롭습니다.)소비자 행동 데이터의 필요성마케터, 기획자, MD 등 인간을 소비자로서 이해해야 하는 직업인들에게 이런 현상은 반갑지만은 않을 것입니다. 변화하는 시장에 걸맞은 새로운 전략이 필요해졌기 때문입니다. 여전히 인구주택 총 조사같은 통계자료, 리서치펌의 시장 조사 자료 등을 참고하지만 가장 면밀히 살펴보는 것은 자사 소비자의 행동 데이터입니다.실행 가능한 전략을 만들기 위해서는 통계와 시장조사 자료가 제시하는 거시적인 트렌드와 자사의 소비자행동 간 상관관계를 분석할 수 있어야 합니다. ‘1인가구 시대를 맞아 혼밥혼술이 유행한다’라는 외부 자료가 있어도, 자사 소비자의 선호도와 행동에 관한 데이터가 없다면 무엇을 만들고 어떻게 팔아야 할지 판단이 어려울 것이기 때문입니다.따라서 적어도 자사의 홈페이지, 소셜 채널, 쇼핑몰, 모바일 앱과 같은 온드 미디어(Owned Media)에 적절한 측정 툴을 적용해 소비자의 행동특성을 데이터로 남길 수 있어야 합니다. 어떤 제품을 얼마나 구매하는지, 신규 고객이라면 왜 우리 브랜드를 선택했고 어떤 경로로 유입 되었을지, 기존 고객이라면 방문 횟수, 구매량, 구매빈도에 주목할 만한 변화가 있는지 등을 측정할 수 있어야 합니다.소셜 미디어로 ‘공유’하는 활동도 소비자의 행동특성으로써 측정할 필요가 있습니다. 특히 커머스 분야에서는 상품의 소셜 미디어 공유가 남다른 의미를 가집니다. 상품의 URL을 자신의 메신저로 복사해 놓고 여유 있는 시간에 해당 상품을 비교구매 하는 패턴이 관찰되는 추세입니다. 따라서 소셜 미디어 공유는 강력한 구매징후로 판단하고 관리할 필요가 있습니다.앞으로 3년 후의 환경 역시 변화할 것입니다. 하지만 거시적인 인구통계정보는 변화하는 환경에서의 소비자의 특성을 반영하지 못할 것입니다. 따라서 우리 비즈니스의 소비자를 판단하기 위한 기준은 그들 각각의 행동이고 이것을 데이터화 할 수 있어야 합니다. 자사 채널의 데이터는 미지의 상황에 전략적으로 대응하는데 필요한 강력한 팩트라는 사실을 잊어서는 안되겠습니다.

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.

OverviewQA담당으로 입사하자마자 12월 21일, 22차 업데이트를 위한 앱 QA를 진행했습니다. QA는 이전 직장에서도 꾸준히 했는데도 아직까지 적응하기 어렵습니다. 그렇게 확인을 많이 하는데 오류는 왜 배포 후에 보이는 걸까요.분노를 느끼는 중22차 QA 한줄 요약: 뫼비우스의 QATC 수정 중QA담당자의 카운트다운은 기획이 완료된 SB를 참고하여 TC를 수정하는 것부터 시작됩니다. 물론 이전의 다른 과정들도 중요합니다만 이때부터는 마음속에 폭풍전야의 전운이 돌기 시작합니다. TC를 수정하는 순간 시트를 통째로 머릿속에 외워야 합니다. Depth 구성이나 QA해야할 내용을 담당자가 미리 파악하지 못한다면 테스트 도중 쏟아지는 문의사항들을 감당하지 못하기 때문이지요.뫼비우스의 QA...어떤 문의사항이냐고요? 이것을 설명하려면 브랜디의 QA과정을 먼저 설명드려야 할 것 같습니다. 브랜디의 QA는 내부 테스트와 외부 테스트로 구분되어 있습니다. 내부 테스트는 R&D본부의 서비스팀에서 1차 개발이 완료된 Android, iOS 버전의 앱을 검증합니다. 반면 외부 테스트는 브랜디 전체 직원들이 모여 앱을 검증합니다. 개발자가 아닌 사용자 입장에서 QA가 진행되다 보니 수많은 질문들을 마주합니다.“이건 왜 이럴까요?”“꼭 이래야만 할까요?”“이상한 것 같은데요.”????????그러나, QA담당의 책무를 다하기 위해 이를 꽉 무는 일이 있더라도 친절하게 답변합니다. 좋은 앱을 위해 모두가 노력하는 거니까요. 게다가 QA전문 회사에 다니면서 여러 프로젝트를 경험해봤지만, 회사 직원 전체가 배포 전에 테스트하는 게 굉장히 좋은 과정이라고 느껴졌습니다. 개발자가 아닌 고객의 관점에서 품질을 높이겠다는 회사의 방향을 엿볼 수 있었기 때문입니다.Android QA sheet중 일부iOS QA sheet중 일부사실 이렇게 꼼꼼한 과정을 거쳐도 완벽한 테스트는 없습니다. QA담당은 지속적으로 테스트를 해야 합니다. 그렇기 때문에 입사 후 처음으로 경험했던 브랜디의 QA테스트는 무사히 마쳤지만 아직도 현재진행형이기도 합니다. 내부, 외부 테스트 때 나온 결함을 Android와 iOS개발자에게 직접 전하고, 다시 테스트를 진행하고 있습니다.ConclusionQA 담당자로서 첫 번째로 중요한 업무는 QA프로세스의 정립입니다. 브랜디는 스타트업 회사이기 때문에 QA프로세스의 완성도가 아직 부족합니다. (제가 입사한 이유이기도 합니다.) 두 번째로는 JIRA(BTS) 도입으로 이슈관리의 개념부터 만드는 것도 목표 중에 하나로 생각하고 있습니다. JIRA가 있으면 소스코드 관리, 이슈 관리, 빌드, 프로젝트 관리 등의 효과를 얻을 수 있는데 특히 이슈관리(버그추적) 시스템이 도입되면 신세계가 열립니다. JIRA이슈관리 시스템은 이슈를 쉽게 조회할 수 있고, 저장된 속성을 이용해 통계자료까지 얻을 수 있습니다. 이슈 형태를 이용한 검색도 가능하기 때문에 이전에 발생했던 이슈를 쉽게 찾아볼 수 있습니다. (브랜디를 포함해 이슈관리 시스템을 이용하지 않는 회사가 많습니다만… 여기에 글을 쓴 이상 제가 해야겠지요.) 또한 다른 개발자들과 함께 피, 땀, 눈물을 쏟아내다 보면 selenuim, appium을 이용한 자동화 테스트 도입도 할 수 있을 거라 생각합니다. QA와 관련된 자세한 이야기는 앞으로도 꾸준히 공유하겠습니다. 기대해주세요.글김치영 대리 | R&D PM팀kimcy@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #기업문화 #조직문화 #업무환경 #인사이트 #경험공유

일을 할 때는 반드시 업무분장이란 것을 합니다. 각자 일정파트의 업무를 담당하고 그것에 책임을 진다는 얘기이지요. 매우 행복하고 아름다운 얘기입니다. 그 큰 업무를 어떻게 다 해. 그러니 너는 디자인, 너는 발표, 너는 자료조사, 나는 글을 쓰는 것이죠. 어디서 많이 본 그림입니다. 그렇죠. 조별과제.조별과제전 대학교를 중퇴하고 때려쳤으니, 1년 좀 넘게 경험했고 여러분들은 4년 내내 경험하셨으니 더욱 잘 아시리라 생각됩니다. 조별과제. 공산주의가 망한 이유를 몸으로 체득할 수 있는 또 하나의 교양과목이자, 모두의 할머니 할아버지가 여러 번 돌아가시는 예토전생의 술법이죠. 이 조별과제가 나이를 좀 먹고 장소를 직장으로 옮기게 되면 '업무분장'이라는 이름으로 재탄생하게 되는데, 자꾸 지난 4년간 겪었던 호구의 추억이 되살아나는 듯한 기시감은 떨쳐내기가 힘듭니다.  오늘은 이 업무분장에 대해 알아보도록 하겠습니다. 브랜딩업무는 혼자 할 수 있는 수준의 업무량이 아닙니다. 게다가 그래서도 안되는 것이구요. 브랜딩은 기획단계부터 디자인, 실행, 회계까지 다양한 팀과 업무영역을 아우르게 됩니다. 그도 그럴 것이 브랜딩은 전사적인 단위의 액션이고, 단기적인 프로모션 따위가 아니기 때문입니다. 정체성에 관련된 문제이니 모두가 각 영역에서 하나의 가지를 담당해야 합니다. 그러니 전체직원이 30명이라면 30명이 함께하는 조별과제라고 볼 수 있겠네요. 우리의 경험상 4,5명만 단톡방에 있어도 그 중 한 두명은 반드시 잠수를 탑니다. 더불어 다른 한 명은 도무지 속도를 못 따라오고, 그나마 괜찮은 아이는 자꾸 집안에 무슨 일이 생깁니다. 나를 제외한 모두의 집안에 큰 우환이 생기는 무시무시한 프로젝트죠. 일단 이러한 집안의 큰 변고가 어째서 생기는 지 알아보도록 합시다.업무분장은 왜 항상 폭망인가.1. 방관자이론은 어디에나 적용된다. 내가 아니어도 누군가는 할 겁니다. 이거 못해도 월급은 받습니다. 혼나면 됩니다. 우리 중에 마피아가 있는거야..날로 먹2. 업무역량이 제각각이다.내 기대만큼 일을 잘하는 사람은 세상에 그리 많지 않습니다. 그리고 내가 생각하는 수준의 프로일잘러들은 이미 개인적으로 다 사업을 하고 있거나, 재야에 숨어있거나, 일하느라 바빠서 찾기 힘듭니다.고수들은 산 속에 숨어있다. 채용공고는 비둘기로 날리자.3. 누가 무슨 일을 하는 지 몰라.분명 회의시간엔 서로 나눈 것 같긴 한데 누가 무슨 일을 어떻게 맡고 있는 지를 정확하게 모릅니다. 옆 사람의 업무진행이 어디까지 되었고, 거기에 맞춰 나는 어느 수준까지 해야하는 지 등, 분장의 목표는 집단지성과 다수의 분업을 통해 효율적이고 높은 수준의 결과물을 내는 데에 있지만, 대부분 목표와는 다르게 집단게으름과 한 사람이 만든 것보다도 못한 혼란스럽고 괴이한 혼종이 탄생하는 경우가 많습니다. 느와르 영화 찍는 것도 아니고 도대체 왜 다들 자기 일을 숨기는 걸까요?그래서 나오는 괴이한 혼종...4. 사실은 커뮤니케이션을 못한다.사실은 숨기는 게 아니라, 말을 못하는 겁니다. 어떻게 말해야 할 지도 모르고, 서로 보고하는 것도 눈치보입니다. 솔직히 수평적관계라고 톰, 제임스, 하비 등 영어이름을 붙였지만 몸에 밴 수직적 마인드는 어쩔 수 없습니다. 1년차와 5년차인 내 명함에 똑같이 manager 라고 되어있는데다가 1년차가 자꾸 자기와 동등한 수준의 프로젝트를 맡는다면? 5년 차인 선배의 입장에선 각자의 역량의 차이가 있으니 당연하다. 라고 받아들이기는 여간 어려운 일이 아닐 것입니다. 그런데 자꾸 밖으로는 쿨한 척 해야하고, 속으론 '내가 니 위야' 라는 모순이 발생하면 입은 닫히고 가면만 늘어갑니다. 자꾸 가벼운 얘기들만 오고가고 진지한 싸움과 논쟁을 피하게 됩니다. 화를 내면 진다라는 묘한 명제는 분노의 진실성을 역설하고 있습니다. 먼저 진실을 내비친 사람이 패배하는 것이다라는 체면과 격식의 아이러니죠.눈치만 보는게지.5. 업무분장의 기준이 엉망이야.업무는 케이크쪼개듯 정확히 몇 등분으로 쪼개지지 않습니다. 반드시 많은, 중요한, 급한 일들이 발생하고 누군가는 그것을 떠맡아야 합니다. 업무분장의 기준은 대부분의 회사에서 '잘 하는 사람' 에게 집중되고, '손 빠른 사람'에게 과중됩니다. 직급높은 사람에게 책임직을 맡기고, 일 없는 사람들에게 자잘한 업무들을 던집니다. 그냥 상식선에서 이루어지는 분장이죠. 분장과정에서 이 사람의 역량이나 성향, 관심사나 이전 경험, 인맥과 인사이트가 고려되지 않습니다. 조장님 말씀6. 하던 사람이 계속 하는일이란 것이 참으로 그렇습니다. 사람뽑기가 세상에서 가장 힘든 것이 사업이죠. 그래도 회사에 나를 제외한 내 오른팔과 같은 존재가 한 명 정도는 있기 마련입니다. 대표도 사람인지라 당연히 열 손가락 깨물면 더 아픈 것이 있기 마련입니다. 그런데 대부분 그 아픈 손가락이 굉장히 일을 잘하는 사원이고 믿음이 간단 말이죠? 그러면 배려해주고 쉬게 해주는 것이 아니라, 더욱 많은 일을 맡깁니다. 이것은 상대적인 불신때문입니다. 이 사람이 잘하니까 일을 줘야지! 라고 생각하기 보단 실상 다른 직원에게 주려고 하다보니...고려할 사항이 너무 많습니다. 검증되지도 않았고 애매한 거죠. 그런데 일은 매번 중요한 것들입니다. 그르치면 손해가 막심할 것 같으니 믿음직한 사람에게 고개를 다시 돌립니다. 아이러니하게도 그 믿음직한 사람은 일이 과중되고 지쳐가기 시작합니다. 곧 그 믿음은 실수와 사고로 이어지기 마련이죠.7. 이해를 못함일을 잘하고 못하고를 떠나서 이것은 업무이해도의 문제입니다. 전체그림을 볼 수 있느냐의 문제죠. 브랜딩에 대해 얘기할 때 1화에서 '모든 직원이 내용을 알고 있어야 한다' 라고 꼭 찝었던 것은 이 때문입니다. 업무이해도가 떨어지면 레시피만 보고만든 믹스호떡처럼 괴생명체가 탄생하거나 도무지 처치곤란한 혼종이 등장하게 됩니다. 기껏 일은 일대로 하고 손해는 손해대로 보는거죠.뭐라는 거지...?8. 편가르기, 편애, 미운털, 관계가 망치는 업무특수한 경우라고 믿고싶지만, 은근히 많더군요. 이해는 갑니다. 사람 모인 곳에 어찌 당파가 없을 수 있겠습니까. 라인도 있고, 야당도 있고 여당도 있고 제3당도 있고 많죠. 문제는 자꾸 이러한 인간적관계가 업무에 영향을 미친다는 것입니다.  예를 들어 우리 팀장이 좀 호구같다고 칩시다. 난 오히려 옆 팀의 이사겸 팀장님이 더 좋습니다. 그래서 우리 팀장이 준 일은 미뤄놓고 옆 팀에서 부탁한 일 먼저 처리하고 있습니다. 우리 팀장이 나를 혼냅니다. 난 빡쳤습니다. 그래서 옆에 이대리랑 옥상에서 담배를 피며 말했죠."아 진짜 존나 일도 못하면서 성깔은..아놔"이대리는 거듭니다. 왜냐면 나와 친하니까요"진짜 저 사람은 어떻게 일할려나 모르겠음.. 이번 것도 분명 말아먹을 기센데." 우린 한 당파가 되어 팀장을 깝니다. 그리고 그의 지시를 자꾸 누락하고 미루고 안하죠. 대강하거나. 취합해야 하는 입장에선 자꾸 공백이 생긴 결과물들이 올라옵니다. 하지만 일을 만들긴 만들어야 하니 또 야근을 해야하죠. 야근을 하고 혼자 취합을 하게 되면 실수가 생깁니다. 실수는 문제를 야기하고 문제는 손해로 이어지죠. 손해의 책임은 간부가 1차 타격을 입습니다. 이것도 어불성설입니다. 사실. 수평적 문화라면 책임도 동등하게 가져가야 하는 것이 이치상 맞습니다.  내 기여도만큼의 보상을 받는 만큼, 내 손실분에 대한 타격을 입는 것 또한 수평적 문화의 특징입니다. 특히 성과지표가 분명한 프로젝트 기반의 업무에선 더욱 그러하죠. 어쨋든 팀장은 멘붕이 되고 윗 선에게 심하게 깨집니다. 직원들은 그걸 또 팀장의 탓으로 돌립니다.  물론 이 과정에서 팀장이 잘했다는 얘긴 아닙니다. 애시당초 팀 관리에 문제가 있기도 했겠죠. 하지만 그것을 마냥 팀장이나 간부에게 당신의 리더쉽 탓입니다라고 전가시키기엔 직원들도 결국 마찬가지 수준이었습니다.  업무분장은 어떻게 할까.업무분장의 문제가 해결된다면 전세계 모든 대학교의 조별과제의 악몽이 해결되는 기적이 일어날 수 있을 것입니다. 또한 대부분의 기업의 효율성이 개선되고 생산성이 극대화되어 이 지긋지긋한 장기침체가 끝날 지도 모르겠습니다. 심지어 저도 팀원들과 일을 했을 때, 직원이 있었을 때, 협력업체와 일할 때 등등... 여러 케이스를 겪어봤지만 정확한 정답을 찾지 못했습니다. 다만 소기의 성과와 부작용들을 체험하면서 이건 이럴 때 좋고 이럴 때 좋지 않구나...라는 정도를 짐작할 따름입니다. 그러니 업무분장의 옳은 방법이라기 보단, 뻔하지 몇 가지 유의사항을 중심으로 적어보겠습니다.1. 적어도 분장회의는 심각하게.프로젝트플랜을 짜고, 각자 업무를 나누는 회의를 할 텐데. 전 개인적으로 이 회의를 대충하지 말자는 주의입니다. 조금 과장해서 하루 전체를 그 업무분장 회의에만 써도 괜찮습니다. 하루는 정말 고생하겠지만, 이 후의 확인, 취합, 업무상황 진행 등 모든 전반의 업무효율이 극단적으로 올라갑니다. 다들 그 시트의 데드라인을 맞추기위해 노력하고, 모두가 어떤 상황이 어떻게 돌아가는 지 이해하고 있는 상황이 됩니다. 단, 그 하루동안 해야 할 일이 있습니다. 직원들의 성향파악현재 업무 재정리각자 업무속도 계산프로젝트 기간 내 개인사, 사내일정 스케쥴링정/부 인원 지정보고체계 확립프로젝트 개괄 프레젠테이션상세 업무공유개인별 목표설정 및 평가지표 설정개인별 업무일정 짜기취합 후 프로젝트 플랜시트 제작완성된 플랜시트 피드백적어도 이 부분들은 순서대로 아주 치밀하게 결론을 내는 회의시간이었으면 합니다. '너 일 뭐 있지? 너가 이거 할래?' 이런 식의 분장이 되지 않았으면 좋겠습니다.2. 미달성의 책임은 분명히실무자를 위한 것이기도 합니다. 방관자의 심리의 주된 원인은 책임의 분산입니다. 다수가 존재하는 만큼 해당 이슈에 대한 책임이 분산되며 나에겐 피자 위에 뿌려진 올리브만큼의 책임감만이 스윽 주어지게 되는데 그 정도는 그냥 자기합리화나 집안일핑계로 거뜬히 쳐낼 수 있는 수준의 것들입니다. 이런 식으론 어떤 것도 이루어지지 않습니다. 위 회의에서 개인별 목표설정, 평가지표 설정은 정말 중요한 데 해당목표의 미달성시 어떤 핸디캡을 받고 어떤 책임을 질 것인지도 명확하게 지정하는 것이 좋더군요. '반드시 해내야 한다'는 적당한 압박감은 실패시의 합리화나 책임전가를 막고 외부요인으로 부터 그 핑계를 찾는 사태를 줄여줍니다. 아킨(R.M.Arkin)과 바움 가드너(A.H.Baumgaerdener)의 셀프핸드캐핑 실험에서 증명된 것과 같이 말이죠.3. 업무량은 내 처리수준의 +15%, 데드라인은 항상 -1일긍정적인 마인드와 열정, 화이팅, 돈독한 애사심은 훈훈한 분위기에는 좋을 지 몰라도 업무처리능력과는 별개의 문제입니다. 업무를 완성시키고 직원들을 고무시키고 싶다면 편하고 쉬운 일을 주는 것이 아닙니다. 항상 내가 해결할 수 있는 한계치의 적당량 이상의 어려운 과제, 적당히 급한 데드라인의 선을 지키는 것이 중요합니다. 일의 속도감과 성취감은 '일을 끝냈다!' 에서 오는 것이 아니라 '그 일을 해냈다!' 에서 오는 것이기 때문이죠. 에드워드 데시와 리차드 라이언의 자기결정이론중 인지평가이론(Cognitive Evaluation Theory)을 참조해보면 좋을 듯 합니다.4. 일관성!!1번에서 그렇게 심각하게 회의를 했으면, 중간에 그걸 엎지마세요. 회사 일이란 게 워낙 심각하고 급박하게 돌아가는 것이 많으니 변동과 이슈가 많은 것은 사실입니다. 하지만, 급하니까 너 그거 다 멈추고 이것부터 해! 라고 하는 것은 그냥 파국급행열차 티켓을 끊어 손잡이에 매달린 채 목적지까지 달려가렴. 이라는 소리와 같습니다. 어차피 업무분장회의에서 나왔던 그 일도 해야 하잖아요?? 중간에 일이 들어오면 차라리 경매를 붙여서 스스로 업무량을 조절할 수 있게 하던가, 아니면 다시 전사회의를 거쳐 양해를 구하고 전체플랜에 대한 수정을 전사공지합니다. 정보의 제한과 이해의 부족은 아주 사소한 실수와 그냥 던지는 작은 일조차도 '불신의 씨앗'으로 변하게 합니다. 적어도 우리가 그 날 열심히 만들었던 그 회의는 결코 변하지 않는다라는 일관성과 고집이 있어야 추후에 평가, 책임, 보상 때도 신뢰감이 있는 것입니다. 중간에 자꾸 말바뀌고, 일 틀어버리고, 맡기겠다고 했으면서 계속 간섭하고, 불필요한 과정을 자꾸 삽입해서 보고를 위한 보고를 만들어내면 추후에 그 모든 책임은 다 관리자 본인이 지셔야 합니다. 5. 모든 과정은 결과후에 복기한다.불만이 쌓이는 것은 무서운 일입니다. 그러나 그 불만을 그 때 그 때 터뜨리는 것도 업무에선 그리 좋은 방향은 아닙니다. 물론 순간순간 해결될 수 있는 사안이라면 당장 커피와 함께 멱살을 잡든 엎어치면 되겠지만 대부분의 업무방향은 시스템적인 수정을 필요로 합니다. 때문에 실시간으로 문제해결을 하다간 일이고 나발이고 흐르는 물 막느라 아무것도 못하는 상황이 됩니다. 일단 프로젝트를 끝내는 게 급선무입니다. 단, 일 하나가 끝나고 업무분장된 결과물이 등장하고 난 후 반드시 평가회의를 하시길 추천드려요. 그리고 그간의 모든 일들을 하나하나 정리하면서 복기하셔야 합니다. '아 모두 수고했구요, 참치먹읍시다아~' 이게 아니고... 처음에 하루종일 회의하듯 정말 냉철하고 싸울 듯한 회의가 되어야 해요. 단 회의의 결과는 뭔가 명확한 솔루션을 들고 끝나야겠죠. 안 그러면 감정싸움만 될테니까요.업무분장은 대표입장에서도, 실무자입장에서도 정말 어려운 일입니다. 서로가 서로에 대한 이해가 없이는 일을 할 수도 나눌 수도 합칠 수도 없으니까 말이죠. 자유롭게 서로의 일을 그냥 알아서 하면 얼마나 좋을까요? 각자 일을 찾아서 하는 유토피아같은 사무실 말입니다. 인간은 자유라는 환경이 주어졌을 때 함께 공포를 느낀다고 합니다. 아무런 책임이 없는 상태에선 본능이 가장 먼저 튀어나오고, 애사심이나 업무에 대한 객관적인 판단보단 내 자존심과 타인에 대한 경계심, 심리적관계가 더 먼저입니다. 회사에 들어와서 책상에 앉아 일을 하고 있다고 해서 뭔가 갑자기 일하는 로봇이 되는 것은 아니니까요. 업무분장은 이러한 사람들의 특성을 충분히 고려해야 합니다. 배려할 부분을 배려하고 억압할 부분은 강력하게 억압해야 합니다. 책임과 도전에 따른 보상과 벌도 있어야 합니다. 납득할 만한 이해와 협의도 거쳐야 하며 먼 발치에서 어떤 식으로 누가 무슨 일을 하는 지 확인도 종종 해야합니다. 그냥 '너가 화장실 청소 해.' 라며 던진다고 끝날 문제는 아니라는 것이죠.우리 사무실의 화장실청소는 어떻게 분장되어 있나요? 누가 하고 있나요? 어떻게 그것을 담당하게 되었나요. 만약 그 사람이 청소를 하지 않는다면 한 달 뒤 화장실의 모습은 어떻게 될까요. 회사와 비즈니스는 모두의 손을 거쳐 만들어집니다회사와 비즈니스는 모두의 손을 거쳐 만들어집니다. 사무실부터 작은 앱아이콘, 메뉴텍스트까지 누구 하나의 손이 닿지 않은 곳이 없죠. 모두가 사람이 만들어야 하는 것입니다. 과연 우리 회사엔 누구의 어떤 손길이 얼마나 닿아있는 지 한 번쯤 돌아보는 시간을 가져보는 것도 의미있을 것 같습니다. :)

아이오에서 일 한지 어느 덧 한 달 가까이 되어간다.이젠 나도 어느 정도 팀의 비즈니스 로직, 도메인, 문화, 사용하는 기술들이 조금씩 이해되기 시작하고 있다.그러자 이번엔, CTO이자 나의 멘토이며 사수인 미정님이, "직접 기능을 하나 TDD로 개발해서 Pull Request 해보라"는 미션을 주었다.API를 보고, 구글링하고, 기존에 미정님이 짰던 코드를 참고해서 만들어갔다.그럼에도 불구하고 제대로 작동하지 않는 코드가 있었다.혼자 해볼 수 있는 것은 다 해 본것 같은데도 해결법이 떠오르지 않아, 미정님에게 이런저런 문제가 있다고 설명하고 도움을 요청했다.미정님이 코드를 좀 보더니 해결했다. 미정님이 짰던 기존 코드에 오류가 있었고, 내가 그것을 참고해서 코드를 짰기 때문에 생긴 문제였다.그녀는 쓴 웃음을 지으며, “변형덕에 오류발견 했네, 잘했어.”라고 약간 주눅들어 말했고,나는 “아, 저는 미정님 코드는 완벽하다 생각하고 그걸 레퍼런스로 하고 코드를 짰는데, 그래서 오류를 못 찾았나봐요.”라고 대답했다.그러자 그녀는 갑자기 눈빛을 바꾸며 역정을 냈다. “그건 변형이 아직 엔지니어의 마인드를 못 갖췄다는 말이야!”예상치못한 임기응변에 순간 나는 움찔했고, 내게 유리했던 분위기를 뺐기고 말았다.그녀의 설명이 이어졌다.“세상에 실수 없는 사람은 없어! 엔지니어라면, 컴퓨터는 믿어도 사람은 못 믿는 다는 생각을 갖고 있어야 되!나는 선배가 짠 코드라도 안 믿어. 심지어 구글러가 짠 코드도 난 안 믿어!100%완벽한 코드는 없어.우리가 TDD를 하는 것도 실수나 오류를 최소한으로 줄이기 위해서지, 그렇게해도 오류없는 100% 완벽한 코드를 보장하지는 않아.그러니까 누가 짠 코드든 완벽하다고 생각하면 안 돼! 내 코드도 마찮가지고!”구구절절이 맞는 말이다.친절한 미정님은 스스로를 실수할 수 밖에 없는 인간으로 낮추면서까지, 엔지니어로서 가져야할 자세를 알려주셨다.진정한 살신성인의 멘토라고 아니할 수 없다.ㅜ친절한 박미정줄여서 친박.앞으로 친박이라 부르고 싶다.#스위쳐 #Switcher #개발자 #스타트업 #스타트업CTO #CTO #개발일지 #경험공유