스토리 홈

인터뷰

피드

뉴스

조회수 464

컴공생의 AI 스쿨 필기 노트 ⑧의사결정 나무

미국 스탠퍼드대학의 Xuefeng Ling 교수팀이 본태성 고혈압 발병 위험을 예측하는 AI를 개발했다고 해요. 이 연구에서 활용한 AI 모델은 의사결정 트리(decision tree) 기계학습 기법을 적용했는데요. 그 결과 AI를 통하여 10명 중 9명은 1년 내 본태성 고혈압 발병 위험을 정확하게 예측할 수 있었어요. 국내외 연구자들은 이 의사결정 트리 모델을 적용하여 고령화 시대에 폭발적으로 증가한 고혈압 환자 진료 부담을 덜 수 있을 거라고 기대하고 있다고 합니다. (기사 원문: AI 훈풍 타고 '최적 고혈압 관리'로 향한다)(Cover image : Photo by Gabe Pangilinan on Unsplash)8주 차 수업에서는 이렇듯 의학 분야에도 도움을 주고 있는 딥러닝 모델의 하나인 의사결정 트리(Decision Trees)와 의사결정 트리의 문제를 해결해주는 랜덤 포레스트(Random Forests)에 대해 배웠습니다. 예시를 통해 알아볼까요?의사결정 트리(Decision Tree)의사결정 트리는 다양한 의사결정 경로와 결과를 트리 구조를 사용하여 나타내요. 의사결정 트리는 질문을 던져서 대상을 좁혀나가는 스무고개 놀이와 비슷한 개념이에요.위의 그림은 야구 선수의 연봉을 예측하는 의사결정 트리 모델이에요. 의사결정 트리를 만들기 위해서는 어떤 질문을 할 것인지 그리고 그 질문들을 어떤 순서로 할 것인지 정해야 해요. 의사결정 트리의 시작을 ‘뿌리 노드’라고 하는데요, 위의 예에서 뿌리 노드인 ‘Years < 4> 참고로, 의사 결정 트리는 회귀와 분류 모두 가능한데요. 위의 그림과 같이 숫자형 결과를 반환하면 회귀 트리(Regression Tree)라 부르고 범주형 결과(A인지 B인지)를 반환하면 분류 트리(Classification Tree)라 불러요.  이렇게 질문을 던지고 그 질문에 따라 답을 찾아가다 보면 최종적으로 야구 선수의 연봉을 예측할 수 있게 돼요. 최적의 의사결정 트리를 만들기 위한 가장 좋은 방법은 예측하려는 대상에 대해 가장 많은 정보를 담고 있는 질문을 고르는 것이에요. 이처럼 얼마만큼의 정보를 담고 있는가를 엔트로피(entropy)라고 해요. 엔트로피가 클수록 데이터 정보가 잘 분포되어 있기 때문에 좋은 지표라고 예상할 수 있어요. 이처럼 의사결정 트리는 이해하고 해석하기 쉽다는 장점이 있어요. 또한 예측할 때 사용하는 프로세스가 명백하며 숫자형/범주형 데이터를 동시에 다룰 수 있어요. 그렇지만 최적의 의사결정 트리를 찾는 것은 어려운 일인데요. 그래서 오버 피팅, 즉 과거의 학습한 데이터에 대해서는 잘 예측하지만 새로 들어온 데이터에 대해서 성능이 떨어지는 경우가 되기 쉬워요. 이러한 오버 피팅을 방지하기 위해 앙상블 기법을 적용한 랜덤 포레스트(Random Forest) 모델을 사용해요.의사결정 트리 코드아래는 의사결정 트리를 구성하는 코드예요. # classification treefrom sklearn.tree import DecisionTreeClassifierclf = DecisionTreeClassifier()clf.fit(xtrain, ytrain)yhat_train = clf.predict(xtrain)yhat_train_prob = clf.predict_proba(xtrain)yhat_test = clf.predict(xtest)yhat_test_prob = clf.predict_proba(xtest)clf.score(xtrain, ytrain)clf.score(xtest, ytest)sklearn.tree에 있는 DecisionTreeClassifier를 임포트 합니다.clf : 의사결정 트리를 의미합니다.clf.fit으로 모델을 학습시킵니다.  clf.predict : 데이터를 테스트합니다.  clf.predict_proba : 데이터 각각에 대한 확률이 주어집니다.  clf.score : 학습 데이터와 테스트 데이터의 정확도를 확인합니다.랜덤 포레스트(Random Forest)랜덤 포레스트는 많은 의사결정 트리로 이루어지는데요. 많은 의사결정 트리로 숲을 만들었을 때 의견 통합이 되지 않는 경우에는 다수결의 원칙을 따라요. 이렇게 의견을 통합하거나 여러 가지 결과를 합치는 방식을 앙상블 기법(Ensemble method)이라고 해요.그럼 랜덤 포레스트의 ‘랜덤’은 어떤 것이 무작위라는 것일까요? 여기에서 ‘랜덤’은 각각의 의사결정 트리를 만드는 데 있어 쓰이는 요소들을 무작위적으로 선정한다는 뜻이에요. 즉 랜덤 포레스트는 같은 데이터에 대해 의사결정 트리를 여러 개를 만들어서 그 결과를 종합하여 예측 성능을 높이는 기법을 말해요. 많은 의사결정 트리로 구성된 랜덤 포레스트의 학습 과정(사진 출처 : 위키백과)랜덤 포레스트 코드아래는 랜덤 포레스트를 구성하는 코드예요.from sklearn.ensemble import RandomForestRegressorrf = RandomForestRegressor(n_estimators=100, random_state=0)rf.fit(xtrain, ytrain)yhat_test = rf.predict(xtest)rf.score(xtrain, ytrain)rf.score(xtest, ytest)sklearn.ensemble에 있는 RandomForestRegressor를 임포트 합니다.  rf : 랜덤 포레스트를 의미합니다.   rf.fit으로 모델을 학습시킵니다.    rf.predict : 데이터를 테스트합니다.    rf.score : 학습 데이터와 테스트 데이터의 정확도를 확인합니다.  이론 수업을 마치며2018년 5월 22일부터 시작한 8주간의 이론 수업이 이로써 마무리가 되었어요!! 매주 3시간 동안 어려운 내용의 수업을 듣는 게 힘들기도 했지만 그만큼 얻은 게 많아서 뿌듯하기도 합니다. 이론 수업과 AI스쿨 후기는 아쉽게도 이번이 마지막이지만, 앞으로 8주간은 팀 프로젝트 과정과 커리어 코칭 과정이 기다리고 있어요! 지금까지 8주간 이론 공부를 열심히 했기 때문에 굉장히 기대가 되네요. 살짝 알려드리면 저희 조는 시각장애인과 청각장애인을 위한 상황 해설 솔루션을 주제로 프로젝트를 진행하려고 해요! 아직 추상적인 부분이 많아 조교님으로부터 피드백을 많이 받게 될 것 같지만 그동안 배운 이론을 적용시켜서 높은 퀄리티로 프로젝트를 완성시키고 싶다는 욕심입니다. :) 이론 수업의 시작과 함께 우연한 기회로  AI스쿨 후기를 쓰게 되었는데요. 수업 내용도 어렵고 글쓰기도 익숙하지 않아 쉽지 않았지만 배운 내용을 최대한 공유하고자 했습니다. 이를 통해서 배운 내용을 복습하고 부족한 부분을 알 수 있어서 무척 뜻깊은 경험이었습니다. 부족하지만 이 글을 읽고 조금이라도 도움이 되었으면 좋겠어요! AI 스쿨이 인공지능 엔지니어를 꿈꾸는 제게 큰 발걸음이 될 수 있도록 앞으로도 저는 프로젝트에 전력을 다할 것 같습니다. 8주 동안 열심히 수업 들으신 수강생 여러분 모두 좋은 결과가 있기를 바랍니다!* 이 글은 AI스쿨 - 인공지능 R&D 실무자 양성과정 8회차 수업에 대해 수강생 최유진님이 작성하신 수업 후기입니다.
조회수 1513

냉정과 열정 사이

냉정과 열정 사이라는 소설이 있다. 대학교 때 읽었던 소설인데 두 사람의 여정을 각자의 시선에서 다룬 소설이다. 에잇퍼센트에 인턴으로 입사해 9개월간 일하고 훨훨 날아간 병훈님과 나도 이 소설처럼 각자의 시선에서 지난 9개월을 되돌아보려 한다. (경고한다. 로맨틱하지 않다.)병훈님이 떠나는 날. 아마 여러분이 보는것과 내가 이 사진을 보는 느낌이 많이 다를거다.1. 만나기까지- 소병훈 이야기2015년 대학교 3학년이 시작될 때부터 졸업 이후에 대한 고민이 생겨났다. 대학원 진학과 취직은 수많은 대학생들의 공통된 고민이기에 수많은 조언이 넘쳐나지만 결론은 '나에게 맞는 길'을 선택하는 것이다. 내 인생 내가 선택해야지 언제까지 남들 좋다는 길로만 가겠는가. 둘 다 겪어보고 내가 선택하겠다고 다짐했다.졸업을 위해서는 대학원에서 과제연구를 1년 해야 했기에 대학원은 겪어 볼 수 있었다. 그러면 취직도 경험해보고 싶은데 어떻게 하지? 대기업에서 1~2개월 인턴을 했던 친구들에게 물어보니 한결같이 '놀고먹다 보니 월급이 나온다'는 경험담을 늘어놓았다. 하지만 정말로 취직해서 놀고먹으면 잘리겠지. 대기업 인턴은 패스. 스타트업 관련 세미나에서 한 VC의 '스타트업은 망해도 스타트업 인턴은 망하지 않는다'는 말을 들었다. 창업에 생각이 있으면 스타트업에서 인턴을 해보라는 말이었다. 그래서 '스타트업에서 일해보자'라고 결정했다.수많은 스타트업 중에서 왜 에잇퍼센트를 선택했다고 물으신다면, 빠른 속도로 성장하면서 변하고 있는 스타트업 속에서 일해보기를 원했기 때문이다. 그리고 당시의 나는 CTO의 멋진 말 한마디에 눈을 반짝이며 '이 회사에서 이 사람과 일하고 싶다'라고 생각하면 앞뒤 안 가리고 지원하는 이상주의자였다. 그래서 페이스북에서 호성님의 글을 읽고 '이 회사가 내가 생각하던 회사구나'라는 생각이 들어서 먼저 지원했던 회사를 포기하고, 에잇퍼센트 입사를 간절히(?) 원하게 되었다.- 이호성 이야기2016년 1월의 첫 번째 근무 날. 대표님이 모두를 불러 모았다. 그리고는 회사의 투자 유치 소식을 알려 주었다. (무슨 투자 유치 소식을 "오늘 저녁에는 치킨을 시켜 먹기로 했어요." 수준으로 재미없게 이야기하는지 모르겠다.) 투자를 받는 것이 확정되었으니 대표님이 내게 전달해 주신 미션은 개발자를 채용해서 제품 개발의 속도를 높이라는 것이었다. 사실 에잇퍼센트에 오기 전에 한 회사에만 오래 있기도 했고 개발자들과의 네트워킹도 게을리했던 터라 당장 좋은 개발자를 뽑을 수 있는 방법이 없었다.그래서 블로그에 회사를 알리는 글을 쓰기 시작하면서 주위 분들께 추천을 부탁드렸다. 그중 JDLab의 양주동 대표님이 괜찮은 학교 후배를 추천해 주신다고 해서 속으로 쾌재를 불렀다. 하지만 추천해 주신 친구가 애매하게 9개월만 일할 수 있는 상황이라고 하니 고민이 되었다. 주니어가 실제로 일을 잘 하게 되려면 꽤 긴 시간이 필요한데, 실제로 일을 잘할 수 있게 되었을 때쯤 회사를 떠나는 게 아닐까 하는 생각이 들었기 때문이다. 하지만 인력(당시 4명)에 비해 해야할 일이 너무나도 많았기에 누군가의 손이라도 빌려야 할 판이었다. 그래서 일단 병훈님을 만나 보기로 했다.2. 면접- 소병훈 이야기에잇퍼센트에 들어가는 과정은 상당히 길다.처음에 간단한 티타임을 시작으로 실제 코딩 문제를 풀어보게 하고, 그 뒤에서 다시 1대 n으로 토론하는 과정, 그리고 대표님과의 이야기로 면접이 이어진다. 요즘은 논술 문제도 있다고 들었다. (역시 취직은 어려워)내 경우는 '면접 보려는 것은 아니니 그냥 커피 한잔 하자'는 부님의 간단한 속임수에 넘어가 티타임을 가졌다. 카페에서 커피 한잔 하면서 부님과 에잇퍼센트는 어떠냐고 물어보려고 왔는데, 어느새 내 앞에는 호성님이 앉아 있었고, 메일로 코딩 문제를 받는 것으로 커피 한잔이 끝났다. 이 티타임은 면접보다는 나에게 회사를 소개하고 회사가 나에게 적합한지 보는 과정이었다.코딩 문제는 성호님의 글로 유명해진 pingpong을 포함한 take-home 과제였다. 문제를 받은 다음날 다른 회사 면접을 보고 온 뒤 밤샘으로 문제를 풀었던 것과 제출할 때 pingpong 문제만큼은 자신 있어했던 기억이 난다. 그때의 기억을 떠올리며 당시에 제출했던 코드를 보니 'Assignment를 쓰지 말 것'이라는 조건이 깨져있었다. 자신감 넘치던 과거의 내가 부끄러워지는 순간이다.마지막 면접 과정도 조금은 숨 막히는 경험이었다. 가볍게 대화하는 분위기 속에서 대학에서 들었던 전공과목 별로 하나하나 물어가며 내 지식의 바닥을 확인했다. 대학에서 3년간 들었던 전공과목은 많지만, 질문 들어오는 족족 '모르겠습니다' 밖에 할 수 없었다. 내가 답할 수 있는 수준을 찾으시려는지 점점 질문의 난이도가 낮아졌고, 마지막으로 스택과 큐를 물어보는 질문에 답하면서 '이 회사는 못 들어가겠구나'라는 생각이 들었다.동시에 진행했던 다른 회사에서 합격 메일이 왔기에 에잇퍼센트에 '0월 0일까지 합격/불합격 결과를 알려주세요'라는 당당한 요구를 한 뒤 떨어졌다는 메일을 기다리고 있었다. 하지만 예상치 못한 합격 메일을 받았고, 그 메일에는실력에 대해서는 회사에 오셔서 보여주세요라는 잊지 못할 문구가 있었다.그리고 첫 출근, 4월 4일 9시 20분에 출근해서 잠긴 문을 보며 에잇퍼센트의 첫 날을 맞이했다.- 이호성 이야기병훈님이 왔다고 하셔서 학교 선배인 부님과 함께 회사 옆 '피어나' 카페로 갔다. (당시만 해도 사무실에 회의실이 없어서 모든 미팅을 회사 옆 카페에서 해야만 했다.) 병훈님의 첫인상은 “꺼벙이"였다.공대에서 흔히 볼 수 있는 스타일. 하지만 말하고 이야기하는 것은 번뜩이는 느낌은 크게 들지 않았다. 아마 나정도로 평범한 느낌이었던 것 같다. 이야기를 하다 보니 다른 곳에 면접을 이미 본 상태였다. 일단 우리 회사와 나에 대해서 좋은 감정을 갖게 하는 것이 좋겠다 싶어서 이래저래 약을 팔았다. 그리고 면접 문제를 메일로 전달하겠다고 하고 첫 번째 만남을 마쳤다.며칠 뒤 제출한 과제를 가지고 다시 한번 병훈님을 만났다. 전공에 관련된 기본적인 질문들을 던졌다.(정확히는 졸업한 지 10년이 지나서 그냥 내가 기억나는 것들을 물어보았다.) 그런데 10개의 질문을 던지면 8개의 질문 은 원하는 답을 듣지 못했다. 실망했다. 겸손하고 배움의 자세가 갖춰져 있는 친구라는 생각은 들었다. 하지만 이렇게 모르는 친구를 뽑아도 될까 하는 생각이 들었다.하지만 뽑았다. 솔직히 그냥 학벌을 보고 뽑았다. 좋은 학교에 다니고 있는 친구이니 지금까지 최소한 한 번쯤은 최선을 다해 본 적이 있겠지 라는 생각을 했다. 무엇보다 당시 나는 꽤 급했다.합격 메일에는 ‘실력에 대해서는 회사에 오셔서 보여주세요'라는 내용을 적어서 보냈다. 부족한 만큼 회사에 와서 최선을 다해주었으면 하는 마음이었다. 그리고 입사할 주에 있을 워크숍 준비에 대한 요청도 함께 드렸다.지금 와서 이야기하는 것이지만 최근에 병훈님을 면접 봤다면 떨어뜨렸을 거다. 생각해 보면 이게 면접, 특히 주니어 면접의 어려움이다. 그 사람이 입사해서의 2주 정도는 예상해 볼 수 있지만 그 뒤는 예상하는 것은 너무나 어려운 일이다.3. 들어와서 처음 했던 일- 소병훈 이야기들어와서 처음으로 했던 일은 나를 대학생에서 직장인으로 바꾸는 일이었다.회사에 들어온 지 1~2개월이 지났을 때 외부 업체와 전문 통신을 개발하는 작업을 맡았다. 대학교에서 두 PC 사이의 전문 통신 프로젝트를 만들었던 기억이 있어 충분히 혼자서(그리고 짧은 기간에) 만들 수 있으리라 생각하고 작업을 시작했다. 기존의 코드를 조금씩 수정하고 추가하던 이전의 작업들과는 다르게 처음부터 만들어내는 일이었다.이 일을 하면서 지금까지 '하나의 동작을 하는 무언가'를 100% 혼자서 만든 적이 없다는 것을 깨달았다. 항상 기본 틀을 받아서 코딩하고, 어려울 때는 모범 답안을 보면서 힌트를 얻었으며, 그러고도 힘이 부치면 7~80%만 완성하고 (시간이 없었다는 핑계를 대면서) 넘어갔었다. 회사에서는 이 일이 '소켓 통신의 이해를 확인하기 위한 프로그래밍'이라고 설명되어 있지 않았고, 어디서 버그가 발생했는지 힌트를 얻을 수 없었다.대학 강의로 들었던 내용들과 전혀 다른 지식들이 필요했지만, 필요한 기초적인 요소들은 구글에서 찾을 수 있었다. 하지만 어떤 키워드를 검색해야 하는지부터가 문제였다. 검색해야 하는 단어를 알아내려고 시니어 개발자님들께 돌아가면서 물어봤다. (너무 자주 물어야 해서 한 분에게만 묻기 죄송했다.) 처음에는 학교에서 배운 내용은 쓸모없다고 생각했었는데, 지금 생각해보니 그마저도 없었으면 구글과 위키의 내용도 이해 못했을 것 같다.웹 개발에 대한 기초도 없고, 어디가 끝인지 확신도 없어서 개발 시간이 길어졌다. 야근을 반복했다. 노력한다고 해서 없던 능력이 생기지는 않았고, 결과로 커다란 똥덩어리 같은 코드가 만들어졌다. 다행히도 (달리는 중간에 몇 개의 부품을 갈아 끼운 이후에) 최소한의 기능은 정상적으로 돌아갔다.그렇지만 이 코드가 12월까지 구린 냄새를 피우고 있었다. 에러를 만들지는 않지만 가독성이 떨어지고 창의적인 구조 때문에, 유지/보수를 할 때마다 과거의 내 실력을 확인하는 좋은 지표가 되었다.- 이호성 이야기시간이 많다면 병훈님을 옆에 앉혀 두고 차근차근 알려주고도 싶고, 같이 스터디도 하고 싶었지만 내게는 당장 해야 하는 일이 쌓여 있었다. 다행히 팀에 계신 시니어 개발자 분들이 병훈님일 이래 저래 잘 돌봐 주었다. (20살이 넘는 청년에게 "돌봐 주었다"라는 표현이 적당한 가에 대해서 곰곰 생각해 보았는데, 흠. 역시 적절하다.) 병훈님께 처음 한 달 동안은 조각을 고치는 일, 작지만 급한 일 들을 맡겼다. 덕분에 시니어 개발자들이 다른 일들에 집중을 할 수 있었다. 그리고는 한 달이 지나자 하나의 일을 떼어서 맡겨볼 수 있겠다는 생각이 들었다. 단순히 개발하는 일뿐만 아니라 다른 회사 개발자들과 커뮤니케이션을 직접 하면서 일을 할 수 있도록 했다. 병훈 님은 잊어버렸을지는 모르겠지만 외부 업체로 처음 전화를 걸었을 때 우리 팀의 시니어 개발자들은 모두들 키보드에서 손을 놓고 병훈님의 대화를 노심초사하면서 듣고 있었다.이 프로젝트는 곧 병훈님이 예상한 일정을 넘어섰고, 얼마 이후에는 내가 예상한 일정도 넘어섰다. 병훈님이 끙끙 앓고 있는 게 보였다. 그 일을 다른 사람에게 넘겨야 하는가의 고민도 여러 번 했다. 병훈님이 만들어 낸 창의적(이라고 말하고 싶겠지만 상식을 벗어난)인 코드들을 뜯어고치고 싶다는 생각도 했다. 하지만 시간은 지났고 테스트를 통과한 코드는 에잇퍼센트 프로덕트의 한 자리를 차지했다.4. 무엇을 배웠을까?- 소병훈 이야기첫 번째로 회사가 어떻게 돌아가는 지를 배웠다. 작은(?) 스타트업이었기에 개발팀 외 다른 팀원들과도 친하게 지낼 수 있었고, 회사 내에서 생기는 사건들을 전부 들을 수 있었다. 그렇게 아이디어가 나오는 순간부터 제품으로 완성되는 과정을 볼 수 있었다. 또한 회사의 크고 작은 의사 결정 과정을 지켜볼 수 있었는데, 모든 의사 결정들에 원인과 논리적인 과정이 따른다는 점이 재밌었다.내가 알지 못하는 원인들과 다른 사람들이 결정하게 된 이유가 궁금해서 여기저기 물어보았고, 모두들 숨기지 않고 말해 주었다. 대표님과의 티타임에 찾아가서 묻기도 하고(모두에게 열려있었는데 단 2명이 왔었다), 퍼포먼스 마케팅이 궁금하다며 점심시간에 옆에 앉아 이야기하고, 전화 응대를 어깨너머로 들어보기 했다. 글로 적어보니 처음 초등학교에 들어간 8살 아이 같기도 하지만, 에잇퍼센트에 있으면서 물어보는 만큼 알 수 있었고, 그만큼 이전과는 다른 세상을 알 수 있었다. (그리고 그만큼 야근을 했다.)두 번째는 개발자가 되는 과정을 배웠다. 당연히 개발 실력도 늘었지만, 조금 더 보태서 개발자가 되는 과정을 배웠다고 말하고 싶다. 누구라고 말할 것 없이 남는 시간을 조금씩 쪼개 공부하고 있는 사람들, 새벽 4시가 넘었음에도 꼼꼼히 기록을 남기며 마무리하는 야간작업, 그리고 혼자서는 만들 수 없는 거대한 코드를 점진적으로 만들어가는 개발팀을 보면서 개발자라는 직업을 만날 수 있었다. 내가 본 개발자는 (에잇퍼센트의 개발자만의 특징일 수도 있지만,) 모든 결과를 '우연'으로 넘기지 않고 원인을 찾았고, 원하는 분야를 찾아서 스스로 공부하고, 삶의 즐거움을 하나씩 가지고 있는 사람들이었다.마지막으로 나 되돌아보기. 나는 내 실력을 과대평가하고 있었다. 회사에 들어오면서 '열심히 하겠다'라고 말했지만 몇 개월 '열심히' 뛰어서 갈 수 있는 거리에는 한계가 있었다. 다른 사람들이 불가능하다고 말해도 혼자서 '노력하면 할 수 있다'라고 생각하면서 오기로 붙잡고 있다가 결국 기한을 넘긴 적이 많았다. 시간이 지나면서 '할 수 있을 것 같다'는 자신감이 아니라 완성된 결과물을 보면서 실력을 확인했다. 항상 자신감이 넘치다 보니 매번 내 생각보다 실력이 뒤에 있었고, 그런 생각이 들 때마다 기숙사에서 공부를 했다.그렇지만 나를 과대평가했던 것처럼 나의 목표도 과대평가 했었다. 내가 도달하려고 했던 목표도 꾸준히 달리면 도달할 수 있는 거리에 있었고, 생각보다 멀리 있지 않았다. 다만 '꾸준히'의 기준이 몇 주, 몇 개월이 아니라는 것을 배웠을 뿐이다.- 이호성 이야기내가 입사하기 전에 에잇퍼센트에 여러 명의 개발 인턴이 있었다고 했다. (commit log에서만 만날 수 있는 그대들이여. 왜 버그를 내게 주고 갔는가.) 그리고 한 명을 제외하고는 회사를 모두 떠났다. 처음에 대표님이 인턴 채용 제안을 몇 번 하셨을 때 개발팀에는 인턴을 채용하지 않겠노라고 말했었다. 사람이 전부인 개발팀에서 떠나는 것이 예정된 사람을 뽑고 싶지 않은 마음이었다. 하지만 병훈님은 이런 내 생각을 바꿔 놓았다.연말 평가에서 성장에 대한 상을 받을 만큼 병훈님의 성장은 눈부셨다. 이제 좋은 주니어는 무엇인가에 대해서 병훈님을 기준으로 생각을 할 수 있게 되었다. 주니어 채용에 대한 성공체험을 했다고도 할 수 있겠다.상은 병훈님이 받는데 주는 사람이 더 좋아하네?좋은 주니어는 당연하게도 일정 시간이 지났을 때 높은 곳에 올라갈 수 있는 사람이다. 높은 곳에 올라가기 위한 조건은 다음과 같은 것들이 있다.1) 상대적으로 이미 높은 곳에 있을 것 전설 속에만 존재하는 시니어 같은 주니어 되시겠다. 고등학교, 대학교 때 많은 지식과 경험을 쌓아서 이미 현업에서 잘할 수 있는 친구들이다.2) 인지능력, 학습능력문제를 이해하고 정의하는 능력이 뛰어나고 논리적인 사고를 한다. 속칭 똑똑한 친구들이다. 문제를 자세하게 설명해 주지 않아도 문제의 본질을 이해할 수 있고, 답으로 가는 길을 빠르게 찾아낼 수 있다. 새로운 것을 빠르게 익히고 배움에 대한 두려움이 없다.3) 지적겸손배움에 대해 열린 자세를 가지고 있어야 한다. 나는 개인적으로 주니어의 경우 이 능력을 "내갈굼력"이라고도 부른다. 다른 사람들에게 지적과 갈굼을 받으면서도 그것이 배움으로 이어진다면 감사한 마음으로 받아들인다. 감사한 마음은 다시 지식을 전해주는 사람에게 긍정적인 피드백이 되어 더 많은 것을 알려주게 되는 선순환 구조를 만들어 간다.4) 태도긍정적이고 도전적인 태도를 갖추어야 한다. 자신의 인생을 발전적으로 개척해 나갈 태도. 그리고 자신을 둘러싼 환경에 감사하는 태도. 이 태도는 팀에도 많은 영향을 미친다.병훈님을 면접 볼 때의 나는 1) 만을 중요하게 생각했기에 병훈님을 떨어뜨려야 하나 하고 생각했다. 하지만 이제 와서 뒤돌아 보니 병훈님은 2), 3), 4)을 모두 갖추고 있는 인재였다. 아마 몇 년 뒤에는 1)도 충분히 갖추게 되리라.5. 어떻게 일했나?- 소병훈 이야기 9개월 동안 에잇퍼센트를 다니면서 항상 내 능력으로 조금 힘들지만 불가능하지 않을 만큼 업무가 들어왔다. 스프린트(2주) 단위로 업무를 나눠가지는데, 일방적으로 업무를 할당받지 않고 팀 회의로 업무를 나눠갖는다. 호성님이 업무를 강요하지도 않고 업무 일정도 각자가 정하지만, 모두가 보고 있다는 느낌과 '스스로를 과대평가하는 나' 때문에 매번 촉박한 일정에 시달리게 되었다. 그렇게 나는 손을 들고 해당 업무의 책임자가 된다. 초반에는(전문 개발할 때까지)는 아예 질문하지 않아서 혼자 끙끙 댔는데, 너무 안쓰러워 보였는지 옆에 앉은 연태님이 먼저 도와주셨다. 시간이 지나면서 길이 명확하게 보이지 않을 때는 시니어 개발자(대부분 연태님)에게 물어보면서 일을 진행했다. 어느 날 호성님이 에잇퍼센트처럼 '실패하면서 성장할 수 있는 환경'이 다른 회사에서는 없다고 말했었다. 생각해보니 내가 자유롭게 개발해도 테스트와 코드 리뷰를 거치면서 문제를 잡아낸다. 그러고도 버그가 생기면 실서버에서 디버깅해서 문제를 해결한다. 심적으로 매우 죄송한 마음이 들지만 추가적으로 다른 벌은 받지 않았다. 일을 시작하기 전부터 지레 겁먹을 필요는 없었다. 그 뒤로 길이 희미하더라도 우선 걸어가 봤다. 그러다가 도저히 길이 보이지 않을 때, 조언을 받는 방식으로 일을 진행했다. 시간이 더 오래 걸리면서 최종 결과물의 수준이 떨어지는 상황이 발생했지만, 코드 리뷰를 받으며 최소한의 수준은 맞춰졌다. (그러면서 시간은 더 오래 걸린다.) 최대한으로 생각해서 만들어도 항상 놓치는 부분이나 더 간단한 해결 방법이 있었고, 그때 느끼는 아쉬움과 안타까움이 다음 개발할 때 잊지 않고 기억나서 내가 성장한다는 느낌이 들었다. 막바지에는 개발을 시작하기 전에 항상 의자를 들고 해당 업무를 요청한 사람 옆으로 갔다. 말로 이야기면 Slack이나 Trello로 이야기하는 것보다 빠르고, 해당 문제를 직접 보면서 자세한 설명도 들을 수 있었다. 요청사항을 받아 개발하는 느낌이 아니고 함께 문제를 해결한다는 느낌으로 이야기하면서 실시간으로 여러 해결방안을 제시하면서 생각을 주고받았다. 문제를 해결하면서 회사에 장기적으로 도움이 되는 방향을 고민하다 보니 '주인의식을 가지고 일한다'는 느낌이 들었다. (정확히는 이왕 만드는 거 아름답게 만든다는 생각이었다.)- 이호성 이야기회사에서 병훈님의 별명은 '아기새'였다. 업무를 하면서도 사람들의 보살핌을 필요로 했지만 그것 외에도 이런저런 허술한 면을 많이 보여줘서 누가 붙였는지 기억이 나진 않지만 모두의 입에 착 붙어 있는 별명이었다. (개발팀 내에서는 간혹 '아. 이런. 손이 많이 가는 친구'로 불리기도 했다.)에잇퍼센트에는 퇴사하면 털린다. 다들 떠나지 마라.병훈님을 연태님 옆자리에 앉게 했다. 회사 내에서 스위퍼(스프린트 내의 개발 잡일들을 처리하는 담당) 팀도 연태님과 같이할 수 있도록 했다. 경험과 인내심이 많고 상냥한 언니 같은 연태님(남자)은 병훈님의 좋은 파트너가 되어 주었다. 그리고 세바님은 어려운 문제를 함께 해결해 주고 코드의 퀄리티에 대한 감시자(갈굼자)가 되어 주었다. 언젠가 병훈님이 개발자의 길을 가게 되어 첫 월급을 받게 되면 이 두 분에게는 빨간 내복을 사드려야 할 거다.처음에는 아기새의 Pull Request(반영하고자 하는 코드 뭉치)에는 코멘트가 수십 개가 달렸다. 그것들을 꾸역꾸역 고치고 나면 다시 그 절반 정도의 코멘트가 달리곤 했다. 하지만 병훈님이 떠날 때쯤에는 내 코드에 "이렇게 저렇게 고치는 게 더 좋은 것 같은데요?"라고 코멘트를 달곤 했으니 발전하지 못한 나는 부끄러울 따름이다.그리고 병훈님은 다른 팀일에도 참 관심이 많았다. 그러고 보면 나도 처음에 스타트업에서 일하기 시작했을 때 다른팀 일들도 왜 그렇게 재미있었는지 모르겠다. 하지만 분명한 것은 작은 조직에서는 다른 팀에 대한 관심이 개발을 잘하는 데 많은 도움이 된다.6. 떠나기 이주일 전- 소병훈 이야기정해졌던 퇴사일이 가까워지면서 새로운 업무는 들어오지 않았다. To-do list는 사라지고, 대신 '인수인계'라는 일이 생겨났다. 지금까지 했던 일들을 문서로 남기면서 새로운 책임자에게 넘겨주는 일이었다. 큰 그림을 그렸던 것들이 있는데 완성을 하지 못한다는 아쉬움이 컸다.호성님께 1,2월 프리랜서 제안서를 받게 된 건 우연이였다. 다 같이 점심을 먹을 때 우연히 호성님과 같은 테이블에 있었고, 1,2월에 남은 일정을 이야기하다 농담처럼 나온 제안이었다.제안서를 받은 날, 기숙사에서 많은 계산을 했다. 개발하는데 어느 정도 시간이 걸릴지, 제안서의 업무 기한을 변경한다면 일정이 어떻게 될지, 그렇게 받은 돈으로 어느 정도 도움이 될지. 충분히 가능한 일정이었다. 못해서 아쉬워하던 일이기도 했다. 그렇기에 더 고민했다.긍정적으로 고민하던 제안을 거절한 이유는 '여행 도중에도 계속 개발을 생각할까 걱정되어서'였다. 이번 여행에서 아쉬움이 남으면 다음은 언제가 될지 모른다는 생각이 들자, 내 시간이 더 귀하다는 생각이 들었다.그러면서 내가 조금이라도 더 필요하다고 말해주는 점이 고마웠다. 내가 생각해보지 못한 선택지를 받아서, 나의 가치관을 되짚어 본 느낌이었다.- 이호성 이야기병훈님과 같이 식사를 했다. 병훈님은 복학하기 전 유럽으로 여행을 다녀온다고 했다. 밤에 돌아다니면 위험하니까 숙소에서 코딩이나 하라고 살살 꼬셨다. 밤에 코딩하고 그 아르바이트비로 낮에 럭셔리하게 맛있는 것 먹고 다니면 얼마나 즐거운 여행이 되겠냐고. 제안서를 하나 작성해서 해야 할 일과 보수를 적어서 병훈님께 주었다. 왠지 넘어올 것만 같은 느낌이었다.병훈님이 하루 정도 생각해 보더니 "어정쩡한 상태가 될 것 같아요. 생각해보니 이런 제안을 주신 것만으로도 정말 감사합니다."라고 했다. 실패했다.회사 입장에서 업무를 잘 알고 있는 병훈님이 조금이라도 일을 더 해주면 하는 마음이었다. 하지만 다시 생각해보니 인생의 후배에게는 좋지 않은 권유였던 것 같다. 돈이 중요할 때가 아니라 세상에 대한 경험과 자신을 뒤돌아 볼 시간이 필요했던 거니깐.7. 떠나는 날케익이나 먹고 떠나랏!- 소병훈 이야기떠나는 날도 크게 다르지 않았다. 코드도 살펴보고 pull request도 적으면서 이전과 같은 하루를 보냈다. 그리고 마지막 날, 혹시 작별 인사를 하면서 내가 울지 않을까 걱정했지만 괜한 걱정이었다. 2달 전부터 작별 인사(라 쓰고 갈굼이라 읽는다)를 받아서 그런지 마지막 인사가 특별한 느낌이 들지 않았다.그렇지만 그 뒤로 며칠간 회사를 나왔다는 묘한 홀가분함과 그동안 했던 일들이 내 손을 떠난 공허함이 있었다. 내가 없으면 회사가 바뀌지 않을까 하는 조그만 기대도 있었지만, 다들 나 없이 잘 지내나 보다. 나는 조금 아쉬웠는데.- 이호성 이야기9개월이라는 시간이 참 금방 지났다. 남은 기간 동안 여행을 떠나는 병훈님에게 사람들이 "에이 그거 여행 가면 뭐해. 그냥 회사에서 일해"와 같은 장난을 수도 없이 했던 것 같다. 하지만 떠날 시간은 정해져 있었고 병훈님은 사람들의 박수를 받으며 떠났다. 마치 80분을 열심히 뛴 축구선수가 교체를 위해 떠날 때 받는 박수처럼.8. 떠나고 난 후- 이호성 이야기며칠 간은 아침 데일리 미팅이 왠지 허전하고, 슬랙으로 말을 걸면 대답을 할 것만 같았다. 하지만 또 새로운 사람이 회사에 들어오고 바쁘게 회사가 돌아가면서 금방 잊혀지긴 하더라. 아 그러고 보니 병훈님이 만든 코드에서 버그가 나올 때마다 우리는 회사에 남은 아기새 인형을 괴롭히긴 했다.병훈님이 떠나고 나서 같은 학교의 후배인 선희님이 회사에 마케팅 인턴으로 들어왔다. 선희님이 자기소개 시간에병훈 선배와 같은 동아리에..라고 말하자마자 전 직원이 다 뒤집어졌다. 그렇다. 우리에게 "병훈"과 "선배"는 함께할 수 없는 단어였다.여행을 갔다가 돌아온 아기새 병훈님이 와인을 하나 물어왔다. 그리고는 파닥파닥.군대 문제가 있기에 당분간 병훈님과 함께 오래 일할 수 있는 기회는 찾아오지 않을 것 같다. 아쉬운 마음이 든다. 에잇퍼센트에서의 병훈님을 "막 알에서 깨어나 호기심을 가지고 세상을 바라보는 아기새"로 기억해야겠다. 그리고 그 모습을 기억하며 나 또한 초심을 되새겨야지.우리가 다시 만날 그날까지 병훈님이 더 큰 날갯짓으로 더 넓은 세상을 여행하길 바란다. 9개월간 함께 해준 병훈님께 감사한다. 안녕!덧, 그나저나 난 또 어디에서 찾아야 하나. 이 다음 아기새를.#8퍼센트 #에잇퍼센트 #인턴 #조직문화 #후기 #팀워크 #팀플레이
조회수 1012

가까이하기엔 너무 먼 팀장

태초에 에이스프로젝트에도 팀장이 있었다. 기획팀이 있으니 기획팀장이 있고 개발팀이 있으니 개발팀장이 있는 것은 어떻게 보면 자연스러운 일이었다. 팀장은 팀을 대표해 다른 팀과 의사소통을 하고, 주요한 업무 내용과 팀의 방향성을 결정했다. 팀원들의 성장을 돕기 위해 또는 고충사항을 해결해주기 위해 면담도 했다. 이런 평범한(?) 조직구조가 크게 불편하지 않았기 때문에 한동안은 팀장 체제를 유지했다. 하지만 자리에서 일어나 둘러보면 전 직원이 한눈에 들어올 만큼 규모가 작던 시기가 지나자 조금씩 문제가 생겼다.팀장은 항상 바쁘다업무과부하에 시달리는 리더"팀장님 어디 갔어요? 저 이거 물어봐야 하는데.."팀장은 항상 자리에 없다. 겨우 회의에서 나왔다 싶으면 다른 회의에 들어간다.이제 말 좀 걸어볼까 하면 스케줄 정리를 하러 다른 팀에 가 있다. 내가 한 것 좀 봐줬으면 좋겠는데 자리에 앉아 있을 때도 너무 바빠 보인다. 팀원은 여럿인데 팀장은 하나, 다들 팀장만 바라보고 있다. 대기번호표라도 뽑아야 하나.팀장 본인도 고달프기는 마찬가지다. 팀에서 일어나는 모든 일에 다 신경을 써야 할 것 같기 때문이다.일정도 꿰고 있어야 하고, 팀원 관리도 해야 하고, 아웃풋 피드백도 줘야 하고, 각종 행정업무도 처리해야 한다. 그뿐인가 앞으로를 위해 업계 트렌드와 신기술에 대한 연구도 해야 하고 팀을 대표해 회사 운영 방향을 결정하는 데도 참여해야 한다. 새로운 팀원이 들어오면 회사생활과 업무에 잘 적응할 수 있도록 물심양면 신경도 써줘야 한다. 너무 많은 역할을 동시에 하다 보니 하루가 모자라다.시간은 제한적인데 몸은 하나, 상황이 이러하자 팀장들은 두 가지 양상을 보였다. 하나는 이 모든 역할에 적당히 타협하는 것이다. 스케쥴링도, 퀄리티 체크도, 팀원 관리도 적당히 적당히. 특별히 잘하는 것은 없지만 그렇다고 특별히 못 하는 것도 없게. 문제는 없는데 뭔가 탁월하게 잘 돼가고 있다는 느낌도 없다.다른 하나는 팀장이 해야 하는 여러 역할 중 한 가지(혹은 두 가지)를 과감하게 포기하는 것이다. 퀄리티 향상에는 심혈을 기울이지만 팀원들의 고충은 좀 덜 들여다보거나, 행정 업무는 완벽하게 하지만 새로운 기술에 대한 서치는 미뤄두는 식이다. 적당히 하건 한두 가지를 포기하건 두 경우 모두 팀원들은 항상 무언가가 부족하다고 느끼고 팀장들은 늘 다 해내지 못했다는 부채감에 시달렸다. 전지전능한 팀장은 없다한 사람이 모든 것을 잘할 수는 없다완벽한 리더?인간이 완벽하지 않은데 인간 카테고리 안에 있는 '팀장'이 완벽할 리가 없다. 문제는 '팀장'이라면 왠지 모든 면에 탁월하고 어떤 단점도 없어야 할 것 같다는 데에 있다. 이런 선입견 때문에 어느 부분에서라도 단점이 드러나면 뵹아리 팀원조차 팀장에게 실망하거나 팀장 스스로 자책하는 일이 생긴다.리더는 단점이 없어서 리더가 된다기보다 장점이 크기 때문에 리더로 인정받는다. 상대적으로 많은 양의 업무를 주지만 그만큼 커리어를 확실하게 보장해 주는 팀장, 의사결정의 속도는 느리지만 그만큼 팀원들의 의견을 잘 수렴하고 설명해주는 팀장 등 장점이 있기 때문에 단점이 생기는 것이다. 에이스프로젝트에도 다양한 유형의 '완벽하지 않은' 리더들이 있다. 함께 일하면 쓴소리를 많이 들어야 하지만 업무 역량만큼은 크게 성장할 수 있게 해주는 리더가 있는가 하면 팀원들의 고충 해결과 진로 개발을 위한 면담에 능한 리더도 있다. 에이스프로젝트는 전문성을 중시한다. 제너럴리스트보다는 한 가지를 전문적으로 잘 하는 스페셜리스트의 중요성을 꾸준히 강조해왔다. 단점을 지적하면서 못 하는 것을 잘 하게 하기보다는 잘할 수 있는 것을 더 잘 하게 도와주는 편이 훨씬 쉽고 긍정적이라고 생각하기 때문이다. 리더가 팀원들의 가능성과 장점을 찾아주기 위해 노력하는 것처럼 리더들도 잘하는 것에 좀 더 집중해 볼 수 있지 않을까 고민을 시작했다. 멀어지는 팀장과 팀원 사이커뮤니케이션에 위계가 생긴다직책? 직위?'직책'과 '직위'는 다르다. 팀장은 직책이지만 흔히 직위와 결합해 인식하는 경우가 많다. 최근 많은 스타트업이 그렇듯 에이스프로젝트에는 대리, 과장, 차장 같은 직위가 없고 팀장만 있기 때문에 구성원들은 더 자연스럽게 팀장을 직위로 인식했다. 팀장의 지위를 나타내는 상징물을 지우려고 했던 노력이나 구구절절한 설명으로 해결되지 않는 문제였다. 사원들이 팀장을 '윗사람'으로 생각하면서 생긴 위계는 원활한 커뮤니케이션을 어렵게 만들었다. '(안 그래도 바쁜) 팀장님한테 내가 이렇게 말해도 될까?' 하는 필터링이 들어가자 팀원들은 말이 없어졌다. '이렇게 말해도 될까?'는 '팀장님이 안 된다고 하실 거야' 혹은 '팀장님이 하라고 했으니까 그냥 해야지'로 확대 해석되기도 했다. 이의를 제기하거나 이해되지 않는 것을 물어보는 횟수가 줄어들었다. 사내 만족도 설문에서는 회의 시간에 대한 문항이 최저점을 기록했다.문제는 내 팀 팀장 하고만 있는 게 아니었다. 나와 전혀 업무 연관이 없는 옆팀 팀장이 한 마디 툭 던지고 가도 사원 입장에서는 '그래도 팀장'이 한 발언을 의식하지 않을 수 없다. 지나가던 동료가 던지고 간 의견이라면 '한 번 생각해봐야겠다' 정도로 받아들일 수 있지만 지나가던 팀장이 던지고 간 의견은 단순한 피드백이 아니라 꼭 고쳐야 하는 지시로 들린다. 정말 "왜"인지는 모르겠지만 왠지 팀장이 하라고 하는 대로 해야 할 것 같은 느낌이 드는 것이다. 단순 직책으로 두고 싶었던 팀장은 결국 직책, 직위를 모두 아우르게 되었고 거기에 나이 차이가 가미되자 에이스프로젝트가 지향해왔던 수평적인 커뮤니케이션은 저 멀리, 저 멀리로 멀어져만 갔다. 이 문제들을 어떻게 해결하기 위해 무엇을 고민했을까?2편에 계속.
조회수 8927

왜 SQLite 에서 Realm 으로 옮겼는가?

SQLite 와 Realm잔디 앱은 2015년 중반부터 앱 내에 Offline Caching 기능이 포함되면서 본격적으로 Local-Databae 를 사용하기 시작했습니다.당시에 Realm 과 SQLite 를 검토하는 과정에서 다음과 같은 사유로 Realm 을 포기하였습니다.1.0 이 아직 되지 않은 미성숙된 상태의 라이브러리사용 사례에서 리포팅되는 버그들 (CPU 지원 등)Data 의 상속을 지원하지 않는 문제Robolectric 미지원 (안드로이드 팀 당시 테스트 프레임웍은 Robolectric 이었으며 현재 Android Test Support Library 입니다.)위의 문제로 인해 SQLite 를 선택하였고 여러 SQLite-ORM Library 를 검토한 후 ORMLite 를 선택하였습니다.누구보다 가볍고 빠르게2016년 6월경 앱의 핵심 데이터에 대해 개선작업이 되면서 그에 따라 기존의 Cache Data 로직도 많은 부분이 변경되었습니다. 그에 따라 실시간성으로 DB 를 대상으로 Read-Write 동작이 발생하게 되었습니다. Locking 등에 대한 처리가 되면서 성능에 대한 이슈가 계속적으로 발생할 수 밖에 없었습니다.간헐적인 성능 이슈는 사용자에게 나쁜 UX 로 다가갈 수 있기 때문에 다음과 같은 병목지점들에 대해 성능 향상을 꾀하였습니다.서버와의 통신 향상비지니스 로직 개선내부 DB 로직 향상서버와의 통신 향상병목 지점이 되는 것으로 판단되는 API 를 찾아 원인을 분석하여 개선요청을 서버팀에서 개선할 수 있도록 하였습니다.비지니스 로직 개선불필요한 객체 생성, 비동기로 처리해도 되는 동작들에 대해서는 로직 수정, 최소한의 검증 후에만 앱 실행, 네트워크 동작 최소화, 캐싱 활용 등 다양한 전략을 시도하였습니다.내부 DB 로직 향상SQLite 를 대상으로 빈번한 쿼리 작업을 최소한으로 하기 위해 2~3개의 쿼리로 이루어진 부분에 대해서 최소한의 쿼리만으로 동작하도록 여러 시도를 하였습니다.ORMLite 의 한계점ORMLite 를 대상으로 여러가지 시도를 하였습니다. 쿼리를 최소한으로 하고 1:N, N:M 동작에 대해서 로직 중간에 Query 가 발생하지 않도록 애초에 Join Query 를 하도록 하는 등 여러가지 전략을 시도하였으나 궁극적으로 ORMLite 자체에 대한 성능을 개선하는 것은 불가능하다는 결론이 도출하였습니다.여러 시도를 하였으나 고작 10~20% 정도의 성능향상밖에 없었으며 이는 사용자 관점에서 여전히 느릴 수 있다고 느끼기 충분한 수준이었습니다. 기존에 목표했던 100ms 이하의 쿼리를 기대하기엔 어려운 상황이었습니다.그래서 GreenDAO, Requery 라이브러리를 검토하였습니다.GreenDAO 의 문제점GreenDAO 를 검토하는 과정에서 겪은 가장 큰 문제점은 실제 Object 코드에 GreendDAO 코드가 생성이 붙으면서 유지보수에 큰 걸림돌이 될 수 있다는 것이 예상되었습니다.Requery 의 문제점성능면에서 ORMLite 에 비해서 큰 개선을 가져오지 못했습니다. Requery 는 JPA 를 가장 잘 채용한 것으로 알려져 있지만 그렇다고 SQLite 자체의 성능을 극적으로 개선했다고 보기엔 어려운 부분들이 있었습니다.SQLite vs RealmSQLite 가 가진 자체적인 성능 이슈를 SQLite 기반 라이브러리 범위안에서는 개선할 수 없다는 결론에 도달하였습니다.검토 방법 : 기존의 Object 를 대상으로 ORMLite 와 Realm 을 대상으로 성능을 검토합니다.데이터는 1:N / 1:1 관계가 되어 있는 여러 Object 의 집합으로 구성되어 있다.Database 에서 데이터를 가져올 때는 Eager Loading 방식으로 택한다.Write : 20회, Read : 20회 를 수행했고 그에 대한 평균 성능을 비교한다. SQLiteRealm성능 향상Write4039ms1142ms3.5xRead6010ms2450ms2.5x(Realm 의 벤치마크 정보와 너무 상이하여 재테스트한 결과 수정하였습니다.)위의 비교차트에서 봤듯이 Realm 은 무시무시한 성능이 입증되었습니다.도입 검토시에 Realm 버전은 2.0 이었기 때문에 충분히 신뢰할 수 있을 만큼 성숙되었다고 판단하고 최종적으로 도입을 결정하였습니다.Realm 도입 과정에서 문제점Realm 을 도입한다고 해서 여전히 잠재적인 문제가 해결된 것은 아니었습니다.파악된 다음 문제를 해결 해야 했습니다.Primitive 타입에 대해 Collection 저장을 지원하지 않는다.RealmObject 에 대한 호출 Thread 를 유지해야 한다.상속을 지원하지 않는다.Primitive 타입에 대한 Collection 관리를 해결하기이 문제는 ORMLite 에서 이미 겪었기 때문에 의외로 쉽게 구할 수 있었습니다. long, int 등에 대한 Wrapper 를 만들고 Json Convert 등의 과정에서 Post Processing 과정에서 Wrapper 로 데이터를 이관하도록 처리하였습니다.// example class Data extends RealmObject { private transient List refs; private List refIds; } class RealmLong extends RealmObject { private long value; } RealmObject 에 대한 호출 Thread 분리Realm 은 Object 에 대해 query 후 객체를 받는다 하더라도 실제로 객체 내 데이터르 접근할 때는 다시 Query 로 접근하기 때문에 실제로 Object 전체에 대해서 Eager Loading 방식으로 접근해야 합니다.Jandi 는 싱글톤 객체를 통해 데이터베이스에 접근하며, Background Thread 에서 진행하고 UI Thread 에서 객체 내 변수에 접근해서 UI 에 그리는 작업이 빈번하기 때문에 Thread 독립을 반드시 해야했습니다.Realm 에서는 Eager-Loading 을 지원하고 있습니다. Realm.copyFromObject() 를 사용하면 Return 값이 Eager-Loading 된 Object 가 반환됩니다.단, Realm 의 가장 큰 특징이로 보는 ZeroCopy 를 포기하는 것이기 때문에 신중하게 생각해야 합니다.// example public Chat getChat(long chatId) { return execute((realm) -> { Chat it = realm.where(Chat.class) .equalTo("id", chatId) .findFirst(); if (it != null) { return realm.copyFromRealm(it); } else { return null; } }); } 상속을 지원하지 않는다.가장 큰 문제였는데 해결방법을 찾을 수 없어 결국 상속을 포기하고 모든 Data 를 1개의 Object 에 표현하기로 하였습니다.위의 3가지 문제를 이렇게 해결해서 안드로이드팀에서는 1차적으로 도입을 완료하였습니다.결론현재까지 Realm 전환에 있어서 성공적인 도입으로 판단되어 차후에 다른 데이터에 대해서도 하나씩 DB 이전을 할 예정입니다.Realm 은 이제 충분히 신뢰할 수 있을만큼 성숙되었다고 생각이며 Realm 에서 처음부터 강조하던 성능또한 믿기 어려울 정도로 빨라졌습니다. 더 빠른 Mobile Database 를 원하신다면 Realm 을 적극 추천합니다.#토스랩 #잔디 #JANDI #개발 #개발환경 #업무환경
조회수 1248

스위처 스토리펀딩 종료

지난 1월 25일을 끝으로 44일간, 6편의 글을 연재했습니다. 그리고 35,938,017을 달성하였습니다. 이 숫자를 보고 머릿속에 드는 생각은 다 다를 겁니다. "아이고 기태 잘했네" 하는 사람, "기태 별로네" 하는 사람. 성공의 평가 기준은 주관적이라고 생각합니다. 저는 그저 결과가 나온 과정과, 그 과정의 이유(왜 이런 일을 했는지)에 대해 얘기해주면 독자는 좀 더 객관적으로 생각할 수 있지 않을까? 생각합니다.제가 쓰려는 글은 자랑도, 반성도 아닌 내가 했던 일을 되돌아보고, 결과를 정리하기 위함입니다. (근데, 사실 후자에 가깝습니다.) 위에서 얘기한 결과(숫자)가 나오기까지의 과정, 그 과정의 이유를 정리하기 위함입니다. 그럼 제가 가지고 있는 사고의 한계를 넘어설 수 있지 않을까? 생각합니다.스토리펀딩을 준비하시나요?아님 스타트업에서 마케팅을 하고 계신가요?스토리펀딩을 돌아봅니다. 필요하다? 궁금하다? 싶으면 조금만 기다려주세요. 내용은 다음과 같습니다.(공개는 2월 5일, 일요일 저녁입니다. 빨리 끝나면 빨리 올리고 맥주를 마실 거예요.)1. 스토리펀딩 성과 정리- 스토리펀딩 진행 전 반드시 알아야 할 것2. 스토리펀딩의 목표 (이루고자 한 것)- (1) 목표금액- (2) 스위처 슬로건 변화3. 목표금액 달성을 @을 왜(why?), 어떻게(how) 했는가- (1) 예열 작업- (2) case study- (3) A/B testing4. 스위처 슬로건 변화를 위해 @을 왜(why?), 어떻게(how) 했는가- (1) '귀차니즘' 없애기- (2) 만나야 할 사람 만나기- (3) 메인 영상을 대체할 콘텐츠5. 결과(* 글이 조금 수정될 수 있습니다. 양해해주세요. )궁금한 게 있다면?그냥 써서 올려도 되지만, 고객을 대하듯. 이 글을 읽을 분들이 무엇을 궁금해할지 알면 좀 더 도움이 될만한 글을 쓸 수 있을 것 같습니다. 위 내용과 별개로 궁금한 게 있다면 댓글을 남겨주세요. 확인 후 추가하도록 하겠습니다. (또, 제가 생각하지 못했던 부분도 생각할 수 있으니깐요.)#스위처 #Switcher #콘텐츠 #펀딩 #스토리펀딩 #경험공유 #인사이트 #후기
조회수 1015

2016, 개발자의 Life.. 꿈...#1

주변 개발자들의 삶이 매우 행복을 추구하는 삶으로 변해가고 있다는 것을 느낀다. 주변의 개발자들의 모습을 몇 가지 정리해보자. 이를 '지속 개발을 위한 개발자 Life 스타일'이라고 정의하겠다.개발자#A10년 넘게 개발하던 패키지를 기반으로 필요 기능을 최소화하여 1인 개발기업에 성공하였고 제주도로 내려가서 지역에 속한 분들과 호흡하는 삶을 추구하면서도 소프트웨어 개발의 핵심을 잃지 않았다. 정말, MVP 기능에 최대한 집중하면서 필요한 시장 영역을 더 확대하지 않고, 소프트웨어를 개발하고 있는 개발자와 해당 소프트웨어를 사용하는 고객과 시장에 대해서 같이 합리적으로 지속할 수 있는 지속할 수 있는 소프트웨어 개발의 삶을 이루었다.그리고, 그러한 Life환경을 주변에 전파하면서 불과 얼마 전 또 한 명의 구 루급 개발자에게 비슷한 삶의 길을 가르쳐준다. 정말 부러운 개발자들...개발자#B복잡한 업무나 더 많은 보수를 위해서 더 좋은 회사를 찾기보다는 삶이 존재하는 근무시간을 위해서 재택근무를 찾고 있다. 비용도 최대한 낮추면서 생활을 위한 회사를 찾아다니고 있다. 아무래도, 외국계 개발회사를 선택할 것 같다.개발자#C오픈소스 진형에서 인정받는 개발자이다. 본인이 원하는 오픈소스 프로젝트를 추진하는 것을 보장받고 외국계 기업의 원격근무를 선택했다. 보수도 나쁘지 않고, 근무시간은 알아서 하는 것이지만, 원격으로 일하는 것이기 때문에 '능력'을 보여주기 위해 더 많은 시간을 소프트웨어 개발에 투자한다. 굳이, 서울 시내에 있을 필요가 없기 때문에 외각으로 집도 옮겼다.개발자#D일부러, 실리콘 벨리의 스타트업을 선택했다. 조만간 상장 예정인데 매우 큰 혜택을 받을 것 같다. 그 역시 지속 개발이 가능한 삶을 추구한다.2016년 올 초의 개발자 트렌드는 '지속 개발을 위한 Life'를 지향하는 개발자들이 늘어났다고 평가해본다.우리 모두 지속개발이 가능한 삶을 지향해 보는 것은 어떨까나...
조회수 601

디자이너, 언제까지 을?

디자이너.가족, 또는 가까운 친척 중의 한 명은 디자이너인 시대에 살고 있다.한 해에 배출되는 디자인 전공 졸업자가 2만 명이 넘는 시대이니, 그럴 법도 하다. (10년 전에는 3만명이 훌쩍 넘었었다)훌륭한 디자이너?대기업부터 스타트업에 이르기까지, 디자이너의 손길이 필요한 영역이 분명히 존재하고, 좋은 디자이너를 찾기 위한 노오오력도 어렵지 않게 보곤한다.하지만 기업 입장에서 좋은 디자이너를 찾으려는 노력에 비해서, 실상 어렵게 채용한 디자이너가 기대치를 만족시키는 확률은 높지 않다. 이것을 디자이너의 자질 때문이라고 보고, 동기부여가 떨어지는 디자이너는 또 다시 시장으로 나오고, 기업은 좋은 디자이너를 찾아 챗바퀴 돌 듯이 이런 일들이 반복되기 일쑤이다. (에이전시를 활용하는 경우도 마찬가지이다)무엇이 훌륭한지 아닌지를 판단하려면, 당연하게도 그것이 무엇인지 이해해야 한다. 그래야 좋은 디자이너를 구분할 수 있고, 맞는 역할에 활용할 수 있다. 좋은 소프트웨어 엔지니어를 뽑으려면, 어떤 역량이 필요하고, 어떻게 일하는지 알아야 하는 이유와 비슷하다.모르면 막 뽑고, 뽑아놓고선 막 평가한다. 악순환이다.쓰리풀(3-ful)개인적으로 좋은 디자인이 갖춰야 할 3가지 요소를 뽑자면 다음과 같다. (굿 디자인의 기준은 다양하지만, 개인적으로 가장 공감하는 세 단어이다.)Beautiful(심미성), Useful(유용성), Meaningful(의미)대부분의 디자인 대학의 커리큘럼은 이 세 가지를 육성하기 위해서 짜여져있고, 지도하는 교수님들도 이부분을 강조하고 있다고 생각한다.학생들이 기업에 들어오기 전까지는 아름답고(Beatiful)+ 유용하고(Useful)+ 의미있는(Meaningful) 요소를 모두 담기 위해 노력하고, 학생들의 훌륭한 아이디어들이 실제 세계적인 Award에서 많은 수상을 하는 이유도 거기에 있다고 본다. 또한, 이것은 여러 번의 산학 협동 과제를 통해서도 여러차례 느낀 점들이다.(물론 전문성의 깊이는 충분치 않겠지만, 그것은 당연한 것이다)하지만, 신기하게도 기업에 들어와 2년 정도 지나면, '생각'이 사라진다. 조직에 들어오는 순간 'Beautiful'만 강요받기 때문이다.우리나라에서 좋은 디자이너가 육성되지 못하고, 좋은 디자이너가 탄생하지 못하는 결정적인 이유이다.국내 대표적인 디자이너 이름 3 명을 떠올려보라!쉽지 않을 것이다. 이것은 디자이너만의 책임이 아니다.모두가 디자인 비평가회사에서 디자인이 결정되는 과정을 살펴보면, 주로 비디자이너 출신의 경영자들이다. 이분들은 실제로 오랜 경험과 시장에 대한 이해도가 매우 높은 분들이다. 이 점은 인정해야 한다. 하지만 디자인에 대한 이해는...글쎄... 잘 모르겠다.우리나라의 디자인의 수준은 디자이너의 수준이 아니라, 의사결정자의 수준이다. 좋은 디자인이 없어서가 아니다. 좋은 디자인을 구분하는 능력이 부족하기 때문이다.좋은 생각이 아닌, 'Beauty'의 기준만을 근거로, 그것도 개취가 개입하여 판단하기 때문이다.실제로, 소비자의 안목은 굉장히 높다. 대중이 선택한 good 디자인이냐 아니냐의 여부는 매우 정확하다. 하지만, 훌륭한 영화 비평가가 반드시 좋은 영화 제작자가 될 수 없듯이, 주어진 답안지를 채점하는 것과 답을 만들어내는 것은 다른 차원이라는 것을 착각한다.때문에 많은 의사결정권자들은 자신의 안목을 맹신하게 되고, 실패를 반복하게 되는 것이다.이런 나의 확신은 실제 10년이 넘는 기간동안 디자인 현장에서 관찰하고, 경험한 것에 근거한다. 에이전시, 벤쳐기업, 대기업을 포함하여, 그 사이 협력한 국내 디자인 에이전시, 해외 유명 디자인 에이전시, 국내외 주요 디자인 대학과의 산학 협동, 그리고 운 좋게 경험한 몇몇 세계적 디자인 대가들과의 협업을 통해서 생생하게 느낀 것이다.Beauty 만 강요하는 '갑'좋은 디자인은 '좋은 생각'이다. 남들이 미쳐 생각하지 못했던 좋은 생각 말이다. 이 생각을 생각에 머물러있지 않도록, 세상에 Cool 한 형상으로 끌어낼 수 있는 능력, 게다가 우리 삶을 긍정적으로 변화시킬 수 있는 유용함까지 갖추게 했을 때, 디자인이 감동을 주는 것이다.식상한 생각과 아이디어에 '예쁘게 좀 해주세요~'의 관점으로 디자이너를 활용한다면, 이미 잘못 시작한 것이다. 세계적인 디자인 대가에게 맞기더라도 이미 실패할 수밖에 없다.좋은 디자인은 좋은 철학의 보여지는 영역좋은 디자인은 좋은 철학의 드러나있는 영역이다. 생각과 형태가 일치되었을 때 꽃을 피우게 된다.우리 사회에 좋은 디자이너가 드문 이유이다. 좋은 생각과 철학을 가진 클라이언트가 드물기 때문이다. 을의 문제가 아니라, 갑의 문제이다. 스포츠카를 타고, 1단 기어로 하이웨이를 달리는 격이다.내 주변에는 좋은 역량을 가진 디자이너가 많다. 하지만 슬프게도 역량을 발굴하고 활용하는 안목이 우리사회에는 아직 부족하다. 여러분의 주위에도 마찬가지일 것이다.디자이너가 갑이 되는 세상앞선 질문에, 내 머리 속에 떠오르는 3명의 국내 디자이너가 있다. 누구는 실제 디자이너고, 다른 누구는 디자이너가 아니다.다만, 공통점은 좋은 생각과 철학을 가지고 있다는 것이다. 그리고 자신의 손으로든, 좋은 디자이너를 활용해서든 멋진 철학을 세상에 다양한 형태로 표현할 수 있는 사람이다.나는 디자이너가 갑이 되는 시대를 기대한다.아니, 이미 그렇게 되어가고 있다. 이제는 이미 Maker의 시대이기 때문이고, 무언가를 다른 방식으로 사고하고, 그것을 표현할 수 있는 디자이너는 세상을 주도할 수 있는 역량을 갖추고 있다. 훨씬 다양하고 풍부한 멋진세상이 될 것이다.디자이너가 주체가 되는 세상!멋진 생각이 존중 받는 세상!!!
조회수 2730

스타트업 주식과 삼성전자 주식은 뭐가 다를까?

그투그 #6 스타트업 주식은 삼성전자 주식과 뭐가 다를까?주변에 주식형 크라우드 펀딩 한번 해보고 싶다는 분들이 많습니다. 그런데 일반적으로 주식하면 딱 떠오르는 코스피 주식 거래와 뭐가 어떻게 다른지 모르겠다고 하세요. 그래서 이번 주에는 주식형 크라우드 펀딩의 기본 of 기본을 알려드립니다.신주 발행 VS 구주매출: 새로 만들어 팔거나 가지고 있는 걸 팔거나주식형 크라우드 펀딩에 투자하는 것은 우리가 일반적으로 알고 있는 주식투자와 조금 달라요.구주매출은 기존 주주가 이미 가지고 있던 지분 일부를 일반인들에게 파는 행위를 말합니다. 기존 주주는 주식을 팔아 투자금을 회수하고, 새로운 주주는 기존 주주가 가졌던 지분과 의결권 등의 권리를 양도받는 거예요. 코스피, 코스닥 시장에서 투자자들끼리 주식을 사고파는 행위가 대표적인 구주매출입니다.신주 발행은 새롭게 주식을 발행해 투자자를 모으는 것을 말합니다. 이때 확보된 투자금은 회사의 경영활동을 위해 쓰입니다. 와디즈 플랫폼에서는 초기 기업이 일반 대중을 대상으로 신주를 발행하여 기업 활동에 필요한 자본금을 마련합니다. 투자자는 이 기업이 성장해서 기업가치가 오르면, 구주매출 등을 통해 이익을 실현할 수 있겠죠.그래서 주식형 크라우드 펀딩을 진행하는 기업의 투자설명서에는 다음과 같이 새로운 주식 발행에 관련된 내용이 포함되어있어요. 용어가 복잡하고 어려우니 실제 투자설명서의 일부를 가져와서 하나하나 볼까요?1) 액면가와 발행가액 : “이 주식 얼마에요?”액면가는 주식을 처음 발행할 때 주권 표면에 쓰여 있는 금액입니다. 우리나라에서 발행되는 주식의 액면가는 500원이나 5,000원이 제일 많아요.발행가액은 발행된 주식을 투자자가 처음 인수할 때의 가격을 말해요. 액면가가 500원이라도 8,000원에 인수하면 발행가액은 8,000원이 됩니다. 투자자들은 보통 그 기업의 주당 가치가 앞으로 8,000원보다 높아질 거라고 생각하기 때문에 액면가보다 비싸게 주식을 인수합니다. 그래서 일반적으로 발행가액이 액면가보다 더 높죠.발행가액에 모집수량을 곱하면 모집총액이 됩니다. 쉽게 말해 기업이 새롭게 조달하는 투자금을 말하죠. 모집총액이 회사의 투자 후 기업가치(포스트 밸류)에서 차지하는 비율이 신주 발행 지분율이고요.2) 최소 청약단위와 청약증거금: “8,000원만 있으면 되나요?”제가 이 회사에 투자하기로 했다면 최소 청약단위인 25주를 투자해야 합니다. 발행가액은 8,000원에 25주를 곱하면 최소 20만 원이 필요하죠.저는 30주를 투자하려고 합니다. 주식을 사기 위해 계약금 형식으로 내야 하는 청약증거금이 청약금액의 100%이기 때문에 24만 원이 있어야 하겠죠.신주의 배정 방법이 금액 순익 아니라 청약 순인 경우가 대부분이기 때문에 청약 기간이 남았더라도 모집금액의 100%가 다 차기 전에 빠르게 투자해야 합니다. 신주의 배정 방법이 금액 숙이면 청약 순서와 관계없이 많은 금액을 투자한 사람이 투자자로 배정받게 됩니다.3) 주권발행일과 주권입고일: “저는 언제부터 주주가 되나요?” 빠르게 투자에 성공했다 하더라도 바로 주주가 되는 건 아닙니다. 청약 종료 후 7 영업일이 지나야 투자자 배정이 끝납니다. 8 영업일째 되는 날엔 기업에 투자금(모집총액)이 전달됩니다. 그리고 그 다음날 주식이 발행됩니다. 주식이 발행되는 날(주권발행일)부터 주주의 권리도 생겨납니다. 증권계좌에서 투자 내역을 보려면 시간이 조금 더 필요합니다. 청약 종료 후 21 영업일 이내로 주권이 입고됩니다(주권 입고일). 이때부터 증권계좌에서 주식을 확인할 수 있어요.4) 배당기산일: “배당은 언제부터 받나요?”또 하나 봐야 할 것은 신주의 배당기산일입니다. 배당기산일은 배당금이 계산되는 최초의 일자를 말합니다. 보통 배당은 한 해를 기준으로 이루어지죠. 작년부터 이 회사의 주식을 가지고 있던 기존 주주들은 연말에 2018년 1월 1일부터 2018년 12월 31일까지에 해당하는 배당을 받게 되겠죠.그런데 이 회사가 9월 8일에 새로운 주식을 발행하게 되면 새로운 주주들에게 어떻게 배당을 해야 할까요? 기존 주주들과 같게 배당을 할지, 아니면 주주가 된 시점부터 계산해서 배당할지 미리 배당기산일을 정해야 합니다.이 기업의 경우 배당기산일이 2018년 1월 1일이니 새로운 주주들도 기존 주주들과 똑같이 1년 치 배당을 받게 됩니다.새롭게 발행된 주식이 보통주 면 1주에 1 의결권을 받게 되지요. 하지만 이 회사처럼 우선주를 발행하는 경우, 의결권이 없는 대신 보통주에는 없는 다른 권리들이 주어지는 경우가 많아요. 그 자세한 내용은 투자설명서 내에 <우선주의 주요 권리> 항목에서 볼 수 있습니다. 우선주에 투자하려고 한다면, 내가 어떤 권리를 행사할 수 있는지 하나하나 잘 따져보고 투자해야겠죠? 다음 글에서 이어서 알려드릴게요.글 김영아와디즈의 막내 투자 콘텐츠 디렉터(CD)입니다. 우리의 작은돈이 필요한 곳에 모여 세상을 바꾸는 꿈을 꾸고 있어요. 아 물론 돈도 벌면서요. 더 많은 ‘우리’에게 크라우드 펀딩을 알리기 위해 어렵고 복잡한 투자 이야기를 쉽고 재미있게 풀어내는 일을 합니다.그림 이윤경와디즈의 브랜드 디자이너입니다. 좋은 '사람' 와디즈가 좋은 '브랜드'로 무럭무럭 자라나도록 물을 주고 있어요. 더 많은 사람들의 시작을 돕기를, 그리고 더 재미있는 세상을 만들어 가기를 기대하고 있습니다.#와디즈 #금융지식 #서비스소개
조회수 1175

[아마존 FBA] 04. 관세 납부 편

인사말안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다. 저번 포스팅 "관세"편의 연장선이자 오늘은 관세는 얼마나 발생하고, 누가 납부하나에 관한 내용을 다루도록 하겠습니다. 특히 관세를 누가 납부하냐는 부분은 인보이스 작성 시에도 필요하기 때문에 많은 분들이 궁금해하시는데요. 오늘의 포스팅을 통해서 그간 궁금해하시던 내용이 해결되시기를 바랍니다. QUESTION 4. 관세는 얼마나 발생하나요?목록통관 기준을 벗어난 Invoice Value가 $800 이상인 화물에 대한 관세는 얼마나 발생하나요ANSWER 4. 제품에 따라 다릅니다. 관세율을 결정짓는 것은 HS Code입니다.관세청, 트레이드네비, 등등의 사이트를 통해 '수입국가' 기준으로 내 상품의 HS Code를 조회하면 관세율을 알 수 있습니다. HS Code는 Harmonized System Code의 약자로, 전 세계에 존재하는 그 어떤 제품이라고 하더라도, 전 세계적으로 통용할 수 있는, 한마디로 표현하자면, ‘상품의 분류를 나타내는 “분류 번호”’입니다. 내가 보내는 화물의 제품들의 HS Code의 관세율 * Invoice Value = 관세 납부액입니다.QUESTION 5. 관세가 발생한다면 누가 납부하나요?저는 한국에서 아마존 FBA 창고 주소로 바로 화물을 보내려고 합니다. 관세가 발생하면 누가 납부하나요?ANSWER 5. 운송사에게 화물을 접수할 때 무역조건을 어떻게 정했는지에 따라 관세 납부 주체는 발송인이 될 수도 있고 수취인이 될 수도 있습니다.당연한 얘기지만, 아마존은 여러분들의 화물에 대해 관세를 납부해줄 의무가 없습니다. 따라서 EMS 같은 서비스를 이용해서 화물을 보내게 되면 무역조건이 DDU밖에 안되기 때문에 (수취인이 관세를 납부하는 조건) 화물 총액이 $800이 넘어가는 화물에 대해서는 반드시 해외 특송을 사용하고 무역조건을 DDP로 설정하시길 권장합니다 (발송인이 관세를 납부하는 조건). 저도 지금까지 수백수천 회 해외로 물건을 보내고 FBA 입고를 해봤지만, 화물 총액이 $800이 넘어도 관세가 발생하지 않은 경우도 많았습니다. 하지만 이 글의 목적은 '정석'을 알려드리는 것이기 때문에 안전함을 추구하는 여러분이라면 위험을 감수하지 마시고 정석의 방법으로 위처럼 진행하시길 바랍니다.마치며컨택틱에서 가장 많은 문의 중 하나인 "관세"부분에 대한 여러분의 궁금증이 해결되었기를 바랍니다. 또한, 이와 관련하여 도움이 필요하신 분들은 언제든지 컨택틱을 찾아주시기 바랍니다.그럼 오늘도 즐거운 글로벌 셀링 되세요!컨택틱  서울특별시 강남구 강남대로 62길 11, 8층 (역삼동, 유타워)  대표 전화: 02-538-3939  해외 부서: 070-7771-1727  영업 부서: 070-7771-1728  이메일: [email protected]  유튜브: https://www.youtube.com/channel/UC8OxbQGAnMqWGpGj5weLcZA 홈페이지: https://www.kontactic.com

기업문화 엿볼 때, 더팀스

로그인

/