Phase 21. 핵심에서 삐끗하다... 대안을 찾아야지!사실 원향(fragrance oil, 향수는 콜라와 같이 원액을 공급받아 bottling을 해야한다) 을 공급해주는 회사에 관련해서는, 내가 필요한 것을 잘 해주겠지라는 막연한 생각으로 지금까지 contact을 하지 않고 있었는데.... 그리고, 사실 다른 것들이 만들어지지 않았는데 향부터 이야기를 꺼내봐야 될 것이 없었다. 이제 패키지, bottle, 디자인 등등의 것들이 마무리되어 가는 상황이다 보니 향 회사(Drom Fragrance)에 연락을 하게 되었다. 대답은 부드러웠지만, 독일 특유의 원칙에 어긋나는 것은 할 수 없단다. MOQ(Minumum Order Quantity, 최소주문물량)가 25kg인데, 내가 부탁하는 양은 턱없이 적었고... 최근에 이런 작은 long-tail account를 본인(Drom AP 대표)이 정리하라고 했던 상황이라, 나에게도 동일한 기준을 적용행 하며, 특혜를 주기는 어렵단다. 단, 만약 AP HQ에 방문한다면 나에게 도움이 되는 것들은 최대한 지원해준다는 고마운 말을..ㅎㅎ 그래서 통화를 하면서 대안으로 고민한 것이, Trader를 활용하자는 것이었고 그 대안이 가격 측면에서는 조금 불리하겠지만 앞으로 나아갈 수 있는 길을 계속해서 만들어 갈 수 있는 유일한 방법이다.Phase 22. Harsh 한 부탁이었던가? 주변을 좀 살펴보았나?달성해야 할 목표와 타임라인이 있다 보니.. 맘이 급해진다. 대부분의 것을 혼자 해결해 가고 있지만, 그래도 주변 지인들에게 부탁해야 할 것들이 있었는데... 이런 부탁을 하면서 정말 정중했는지, 또한 그 사람들의 상황을 배려했는지? 에 대한 생각이 드는 시점이다. 일단 내 것을 만들기 위해 너무 harsh 하게 부탁한 것은 아닌지? 계속해서 push 하는 상황을 만들지는 않았는지를 돌아보게 되었다. 그렇게 생각하게 된 배경은.. 향 회사에서 내 메일에 답변이 며칠 간 없어서 이 친구들이 내가 너무 공격적으로 요청을 해서 화가 난 건  아닐까?라는 오해에서 시작되었지만, 암튼 다시 한번 돌아볼 수 있는 좋은 기회였다.Phase 23. 계속해서 사람들과 만나고 communication 하는 것의 중요성사실 새로운 기회를 발견하는 것은 혼자 조용히 앉아 사색하고 책을 읽고 하면서 만들어지는 경우가 많기도 하지만.. 그 생각의 시간에 기본적인 input이 있어야 하는데 그게 바로 다양한 사람들과 만나 이야기하는 것이  아닐까?라는 생각이 든다. 흙으로 뭔가를 혼자서 만드는 것보다, 다른 사람들과 논의하면서 그 안에 지푸라기를 넣어주어 보다 단단한 것을 만드는 것과 같은 효과가 나는 것이다. 이제 내 주변에서 career가 10년 정도는 된 분들인지라 본인의 영역에서의 내공이 나타날 시점이고, 새로운 기회를 포착하는데 눈이 뜨이게 되는 시점이라는 생각이 든다. 새로운 정보와 새로운 기회 하나하나가 모여 큰 것이 만들어지는 기반이 된다는 것! 특별한 목적이 없어도 몇 개의 keyword만 가지고서라도 사람을 만나러 나가 보는 것이 좋겠다.Phase 24. 직접 만나서 얼굴을 한번 보고 일하기3박 4일의 중국 출장은 정말 쉬는 시간 없이 거의 일만 하러 다녔는데, 그 목적 중에 하나는 나와 거래가 필요한 사람들과 만나서 얼굴을 보고 서로 신뢰감을 형성하는 일이었다. 그 와중에는 영어를 하나도 못하는 중국 trader도 있었고, 또 다른 소개를 받아 찾아간 bottle 제조업체에서는 "네가 그 친구의 친구라면 내 친구이기도 하지.. 최선을 다해  도와줄게"라고 말해주는 고마운 사람들도 있었다. 그렇게 얼굴을 한 번이라도 보고서 일을 시작하게 되니 서로에 대한 믿음과 의리가 생기는 듯한 느낌? 발품을 판다는 것이 새로운 것을 찾는 것만을 의미하는 것이 아니라.. 서로 간에 신뢰를 쌓아가는 과정이기도 하다.Phase 25. 최고의 partner를 만나다.Startup에 있어서 가장 중요한 사항중 하나는 역시나 팀을 구성하는 작업이라는 생각이다. 그런데 나에게 가장 필요로 했던 art director (visual designer 말고)를 찾는 쾌거를 거둘 수 있었는데. 바로 대학 동아리 1년 후배이자, 이탈리아에서 10년간 디자이너로 일한 my.yeo 와  함께할 수 있다는 것이었다. 혼자서 일을 만들어 오면서 가장 큰 고민은.. 내가 잘 하지 못하는 영역에서 나보다 뛰어난 사람이 그 고민을  함께해주고 실행해주면  어떨까?라는 것이었는데.. 큰 힘이 되어줄 친구가 조인을 한 것이다. 물론 아직 100% full time은 아니지만, 계속해서 involve 할 수 있도록 도움을 주는 것 또한 내가 해야 할 일이라는 생각이다.#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

안녕하세요! 미드레이트 PR러 온입니다~!얼마 전, 한국인터넷진흥원에서 핀테크 아카데미에서 미드레이트 이승행 대표님과 백승한 이사님의 강연이 있었습니다 :D  4차 산업혁명과 함께 주목 받고 있는 핀테크를 배우려는 사람들의 열기로 후끈했는데요! 그 현장 스케치를 지금부터 시작해보겠습니다 :)아침부터 경쾌한 대표님의 발걸음 ~강연이 시작하기 30분 전, 준비를 위해 저희 팀은 미리 방문합니다 : )KISA의 직원분과 게시판을 보며 담소를 나누시는 대표님과 이사님이 곳은 미드레이트에게는 익숙한 장소인데요 ~ ! 대표님이 강연하셨던, 한국직업방송의 청산유수 프로그램의 촬영지이기도 하고, 백승한 이사님께서 KISA주최 금융API 헤커톤에 참가했던 장소이기도 합니다.사진을 감상하시는 대표님의 모습....(?) 하하하금융 API란 무엇인가?미드레이트가 고객님들께 P2P대출 서비스를 할 수 있었던 이유는 바로 농협 오픈API 덕분인데요~!그에 대한 설명이 도식화되어 잘 설명되어 있는 게시물을 볼 수 있었습니다.강연하시는 미드레이트 대표님이 곳에 강연을 들으러 오신 분들은 대부분 개발자의 꿈을 가지신 분들인데요! 대표님은 핀테크에 적용되는 기술인 오픈API에 대한 간단한 설명과 함께, 이 기술과 금융이 결합하여 만들어진 미드레이트의 서비스 P2P금융까지 Smooth~하게 소개하고 계십니다 :D저 또한, 저절로 강연을 들으면서 우리나라의 P2P금융 상황, 해외와의 차이점 등을이해할 수 있었습니다. 유익한 강연!미드레이트의 신용평가 기술을 설명하시는 대표님!금융과 기술이 도입되면 어떤식으로 비용을 절감할 수 있는가에 대해서설명하고 있는 대표님의 모습입니다.기존의 금융권 제공 데이터 뿐만 아니라,미드레이트에서 자체적으로 분석하고 있는 비금융데이터를 통해 더 많은 고객분께 대출을 제공하고투자자분들께도 수익을 가져다 드립니다 :D드디어 백승한 이사님의 기술 강연이 시작되었습니다!좀 더 깊이 들어가서, 오픈API에 대해 강연하시는 백승한 이사님!개발자로서 농협API와 금감원에서 제공하는 API의 차이점 등개발시에 고려해야할 사항들을 가감없이 알려주시고 계십니다!지금 이사님은 여기저기 돌아다니시면서 자유롭게 강의 진행중!고민하는 학생분들의 모습도 보이네요 :)개발에 대한 질문도 꾸준히 이어져서 이에 대해 열심히 답해주시는 이사님의 모습입니다!강연 후, (하 ~ 한시름 놓았다....ㅎㅎ)한 시간 반정도 진행된 강의는 차분하지만서도 궁금함이 넘쳐나는 시간이었는데요 !앞으로도 미드레이트는 핀테크에 대한 강연, TV방송 강연에 많이 참석할 예정이랍니다 : )성장하는 미드레이트!대출자와 투자자가 연결되는 공간, 미드레이트를 기대해주세요#미드레이트 #강연 #이벤트참여 #후기 #P2P금융 #강의

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 조깨비 조경희 님을 만나보세요:)사진1. 스켈터랩스의 조깨비 조경희 님Q. 자기소개를 부탁한다.A. 이름은 조경희, 아이리스 팀에서 소프트웨어 엔지니어로 일하고 있다. 2016년 8월에 입사했으니 이제 스켈터랩스에 합류한 지도 2년이 훌쩍 넘었다.Q. 맡고있는 업무를 설명한다면?A. 우리 팀은 일종의 실시간 맥락 인식(Context Recognition) 기술을 개발하고 있다. 다양한 종류의 맥락 인식이 있겠지만, 현재 우리는 모바일 기기를 주요 디바이스로 삼고있다. 핸드폰을 통해 사용자의 다양한 정보를 수집하고, 우리의 기술이 알아서 사용자의 취향이라던지 성향, 좋아하는 음식부터 음악까지 다양한 정보를 여러 시그널을 바탕으로 추론하고자 한다. 이후에는 사용자에 딱 맞는 ‘추천'까지 제공하는 기술을 개발하는 것이 목표다.Q. 핸드폰 하나로 사용자의 다양한 정보를 수집하고 추론할 수 있다는 부분이 신기하다. 조금 더 자세히 얘기해줄 수 있나.A. 가령 내가 안드로이드 사용자라고 가정해보자. 우리가 택시를 부를 때 흔히 사용하는 것 처럼 내가 현재 위치한 곳을, 즉 장소 정보를 핸드폰은 알아서 수집하고 있다. 우리는 장소를 비롯하여 와이파이나 사운드, 배터리, 자이로센서 등으로부터 시그널을 수집하고, 스트리밍 프로세싱 엔진에 송출한다. 그럼 그 엔진에서 실시간으로 이러한 스트림(정보)를 받고, 받은 데이터를 조합하여 새로운 데이터로 변환한 후 다음 단계를 추론하다. 내가 만일 아침 9시쯤에는 항상 일정한 A라는 장소로 이동하고 있고, A 장소로 이동하는 길목에서 카페에 들러 커피를 한 잔 사는 일과를 가지고 있다면, ‘A는 사용자의 회사이고, 사용자는 출근하기 전 커피를 마시기를 즐기는 사람이다'라고 추론할 수 있다. 우리는 이러한 상황에 대한 추론을 바탕으로, 조금 더 고차원적인 추론을 하거나, 사용자의 취향 및 패턴을 찾는 기술을 개발하고 있다. 궁극적으로는 <아이언맨>에 등장하는 자비스(JARVIS)와 같은 퍼스널 어시스턴트(Personal Assistant)를 세상에 내보이고 싶다. 사실 자비스는 어디까지나 영화 속의 상상이 많이 묻어있고, 현재로서는 갈 길이 멀기도 하다. 하지만 현재 스켈터랩스는 음성 인식이나 이미지(Vision), 챗봇과 같은 다양한 프로젝트를 동시에 진행하고 있으며 각각의 기술력도 뛰어나다. 이 여러가지 기술이 총체적으로 구현된 서비스가 탄생한다면, 일상을 혁신적으로 바꿀 것이라고 생각한다. Q. 지금까지의 개발 상황을 살짝 공개하자면?A. 시장에 공개한 것을 기준으로 하자면, 일단 베타 버전으로 런칭한 앱 서비스 ‘큐(CUE)’ 이야기를 하고 싶다. 간단한 상황 인식을 통해 사용자에게 추천을 제공한다. 가령 강수량이 높게 예고된 날에는 ‘우산 챙겨가'라고 카드를 띄워준다거나, 라면을 즐겨 먹는 사용자에게 ‘오늘은 라면 대신 건강한 샐러드 어때?’라고 말해주기도 한다. 사실 큐에 대한 사용자의 의견은 정말 가지각색이었다. 날씨 예보를 기반으로 한 추천의 경우 ‘너무 뻔해서 의미가 없는 것 같다’ 라고 생각하는 사용자가 있는 반면, 출근 직전과 같은 적시에 카드가 알아서 추천해주니 매우 편하게 느꼈다는 사용자도 있었다. 결국 나는 상황 인식이 사용자에게 유용한 서비스로 와닿기 위해서는 ‘정확성'이 큰 척도라고 생각한다. 적시에, 적절한 장소에서, 나에게 꼭 맞는 추천을 해주는 것, 이를 위해서는 사용자를 정확하게 파악하는 것이 우선되어야 하기 때문이다. 지금까지의 개발이 상황 정보를 적절하게 받을 수 있는 플랫폼 구축 중심이었다면, 현재는 더 자세한 상황을 찾는 쪽으로 초점이 맞추어져 있다. 가령 사용자가 ‘지하철을 타고 이동한다'가 아니라, ‘어느 역에서 지하철에 탑승하여 어느 역에서 내렸다'까지 인식할 수 있는 것이다. 음악도 마찬가지다. 음악과 같이 엔터테인먼트 컨텐츠의 경우 단순히 ‘음악을 듣고 있다'라는 정보가 아니라, 취향 정보가 중요하다. 때문에 ‘어떤 가수의 어떤 음악을 들었다'까지 인식하여 이를 조합한 추론을 만들려고 한다.사진2. 사내 Tech Talk 세미나를 진행하고 있는 경희님Q. 큐의 베타 서비스를 런칭하며 팀원들끼리 자축하던 장면이 떠오른다. 굉장히 뿌듯한 경험이었을 것 같다.A. 나는 사실 뿌듯함 보다는 ‘갈 길이 멀다'라는 생각을 먼저 했다. 베타 버전이기도 했고, 개발한 우리 스스로도 정확성이 기대에 미치지 못하고 있다고 생각했다. 그럼에도 불구하고 런칭을 결정한 이유는 명확하다. 다양한 사용자가 큐를 통해 어떤 경험을 얻고, 어떻게 느끼는지 들어야만 더욱 사용자의 핏에 맞는 정식 버전을 제대로 개발할 수 있을 것이라고 판단했기 때문이다. 모든 서비스가 마찬가지겠지만 나는 큐야 말로 많은 사용자와 함께 만들어가는 서비스라고 생각한다.Q. 경희님 개인의 이야기를 들어보고 싶다. 스켈터랩스에 어떻게 합류하게 되었는가.A. 스켈터랩스의 CTO인 조성진 님과 같은 연구실에서 일했다. 연구를 마친 후 나는 전문연구요원으로 다른 회사에서 일을 했고, 성진님은 구글에 입사한 것으로만 알고 있었는데, 구글을 나와서 회사를 차렸다는 얘기를 듣게되었다. 그때만 해도 대기업이 주는 안정감을 놓칠 수 없어 대기업에 머물러있었다. 하지만 성진님을 자주 만나 스켈터랩스의 프로젝트가 어떠한 방향으로 구체화되고 있는지 들을수록 매력적으로 와닿았다. 대기업의 경우 조직의 구조 때문에 어쩔 수 없이 쪼개진 일에 집중하게 된다. 하지만 스켈터랩스는 구성원들 모두가 자발적으로 참여하여 방향성을 결정 짓고, 개발 환경을 선진적으로 꾸리고 있다는 점도 좋았다. 이러한 요소가 결국 스켈터랩스로의 이직을 결정지었던 것 같다.Q. 스켈터랩스로 이직하여 얻은 가장 큰 성취를 꼽자면?개인적으로 코드리뷰 문화를 통한 개발 실력의 발전을 꼽고 싶다. 다른 조직에서는 다른 사람이 내 코드를 봐주고, 평가하는 것이 마치 자존심 싸움처럼 여겨지곤 했다. 타인의 코드는 일종의 침범할 수 없는 ‘불가침 영역'으로 인식되었다. 하지만 스켈터랩스에서는 코드리뷰가 너무나도 당연하다. 다른 사람에게 코드를 보여주고, 내 코드가 더욱 효율적으로 작동할 수 있도록 바꾸어주는 것이 자연스럽게 이루어지고 있다. 이 과정을 통해 코드를 리뷰하는 사람도, 리뷰받는 사람도 모두가 윈윈(win-win)할 수 있다. 코드리뷰 문화가 익숙하지 않은 사람에게는 이 문화가 마치 일의 효율을 저해하는 것 처럼 여겨질 수 있다. 그러나 결론적으로는 목표에 닿기 위한 가장 빠른 방법이라고 생각한다. 확실히 여러 개발자의 리뷰를 거칠수록, 버그는 적어지고 개인의 실력이 향상될 뿐더러 시야도 넓어질 수 있기 때문이다. 나 또한 같은 경험을 했다. 스켈터랩스에서 몇 개월 근무한 후, 내가 이전에 짜놓은 코드를 보면 ‘어떻게 이렇게 짜놓았지' 싶을 때가 있다. 개발 실력에 관한 이러한 성취를 정량적으로 판단할 수 는 없지만, 회사와 개인이 모두 발전할 수 있는 가장 의미있는 성취라고 생각한다.Q. 반대로 스켈터랩스에서 개발을 하며 가장 어려운 점은 무엇이 있을까.개발 자체에 대한 어려움보다는 방향성에 대한 어려움이 있다. 인공지능이라는 분야는 워낙 넓기도 하고, 상황인식 기술의 경우 근래에 크게 발전하고 있는 것은 맞지만, 세부 기술에 대해서는 시장 자체가 뚜렷하지 않다. 참고할만한 제품도, 경쟁사도 없기 때문에 새로운 시장을 만들어내는 것에 대한 부담이 있다. 언뜻 보기에는 경쟁사가 크게 없는 니치마켓(Niche market)처럼 여겨질 수 있지만, 기술을 쪼개고 쪼개어 들여다보면 하나의 기술을 바탕으로 각각 다른 사용자와 상황을 타깃으로 변주한 다양한 서비스가 등장하는 상황이다. 이러한 기술을 마냥 뭉뚱그린다면 기술에 대한 깊이가 얕아질 수 있고, 특정 상황과 사용자에게만 집중한다면 타깃이 좁아질 위험이 있다. 때문에 시장과 사용자에 대해 매 순간 유추하며 적절한 균형을 가지고 개발을 진행할 수 있도록 노력하고 있다. 사진3. 프로젝트 별 Sync-up 미팅, 짧은 미팅을 통해 업무 효율을 높이고 있다Q. 스켈터랩스의 개발 문화가 타 기업과 확고하게 다르다고 느낀 사례가 있다면, 그 이야기를 구체적으로 듣고싶다.A. 두 가지를 꼽고 싶다. 첫 번째는, 다른 분들도 많이 얘기했을 것 같지만 역시 와 다. 각각 상반기와 하반기에 한 번 씩, 하는 일을 모두 멈추고 일주일 간 원하는 개발에 집중하는 일종의 해커톤이다. 내가 입사한 날이 Demo Days 시작 이틀 전이었다. 입사하자마자 부랴부랴 팀을 만들고, 아이디어를 구체화하여 개발에 매달렸다. Demo Days 기간 내내 팀원들이 밤을 새워가며 개발에 매달리는데, ‘매일 이렇게 일하는 곳인가' 라는 두려움과 ‘이렇게 뛰어난 개발자들이 집중하니까 뚝딱 서비스가 나올 수 있구나'라는 재미를 동시에 느꼈다. 그 기간이 끝나고 보니 역시 매일 그렇게 일하는 것은 아니었다. 일주일 간 그토록 밤을 세워 개발을 할 수 있는 원동력은 ‘내가 원하는 서비스를 직접 만들어볼 수 있다'라는 흥미와 ‘최종 발표일에 어설픈 개발로 쪽팔리고 싶지 않다'라는 감정인 것 같다. 매일 하는 업무에서 벗어나 리프레쉬 할 수 있는 재미요소도 크다. 그 기간의 우리 성과를 돌아보면, 이토록 개발을 사랑하고 기대 수준이 높은 사람들이 모여있으니, 뭘 하던 성공할 것이라는 일종의 확신을 얻을 수 있다. 두 번째는 ‘빠르다'라는 점이다. 새로운 아이디어나 기술에 대해 흥미가 생겼을 때 쉽고 빠르게 팀을 꾸릴 수 있다. 그렇기 때문에 자연스럽게 자신의 흥미와 역량에 맞는 팀을 찾아 이동하는 것도 매우 자발적으로, 빠르게 이루어진다. 오픈 소스 사용도 빠르다. 새로운 기술이나 제품을 들여다보고 싶다면, 그냥 진행해 볼 수 있다. 기존의 큰 회사들은 수직적으로 팀장 급에서 업무를 할당하고 시일에 맞추어 개발을 진행하다 보니, 속도 자체는 빠를 수 있지만 허술한 부분이 생기기 마련이고 새로운 기술을 도입에 있어서도 조심스럽다. 하지만 스켈터랩스에서는 ‘빨리 도입하고 빨리 경험해보자’ 라는 의식을 공통적으로 가지고있다.Q. 개발자는 개발이 막히는 순간도 종종 맞닥뜨릴 것 같다. 그럴 때 어떻게 해결하는지 자신만의 팁을 공유한다면.A. 고민의 양이 아니라, 그저 고민의 끈을 놓지 않고 있는 것이 중요한 것 같다. 나는 개발이 막혔을 때 스트레스를 꽤 많이 받는 편이다. 한 번 막히면 맥주를 마시면서도, 밥을 먹으면서도 항상 머리 한 구석에는 개발 고민을 이어간다. 꿈에서도 하도 코딩을 한 탓에, 와이프가 어느 날 “어젯 밤에도 ‘테스트 코드는 이렇게 해야지’ 라는 잠꼬대 하던데?”라고 말할 정도다. 그러다 신기하게도 개발을 아무 것도 모르는 제 3자와 얘기하다가 번뜩 방법이 떠오르곤 한다. 지극히 일상의 순간, 가령 샤워를 한다거나 멍하니 지하철을 타다가 해결책을 찾기도 한다. 이 방법이 훌륭한 팁은 아닐 수 있지만, 포기하는 것이 아니라 개발에 대한 고민을 놓지않는 것이 중요하다는 얘기를 전하고 싶다.사진4. 경희 님과 아내 분의 투샷Q. 경희님이 회사에서 종종 드라마 얘기를 하는 것을 들었다. 드라마를 많이 보는 편인가, 하루 일과를 듣고 싶다.A. 예전에는 <와우>라는 게임을 정말 많이했다. 덕분에 게임 동호회에도 가입해있는데, 요즘에는 <오버워치>나 <클래시로얄> 정도만 즐기고 있다. 결혼하고 와이프와 시간을 함께 보내면서, TV 시청이 늘었다. 와이프가 워낙 TV를 좋아하기도 하고 함께 집에서 시간을 보낼 수 있는 가장 편리한 방법인 것 같기도 하다. 하루 일과는 그래도 일찍 시작하는 편이다. 와이프는 일곱시 쯤 일어나 출근하는데, 나도 보통은 맞춰서 함께 일어난다. 재택근무를 할 수 있는 환경이다보니, 오전에는 주로 집에서 코딩을 하며 개발에 집중한다. 보통 점심 때 출근을 하거나, 미팅에 맞추어 출근하는 편인데, 오후 시간은 미팅과 개발 모두를 병행해서 꽤 정신 없이 하루가 흘러가는 것 같다.사진5. 게임동호회에 가입하면, 회사의 지원을 받아 게임을 즐길 수 있다.Q. 스켈터랩스에서 이루고 싶은 것을 듣고싶다.A. 나의 꿈이 원래 ‘내가 개발한 기술이나 제품이 최대한 많은 사람에게 편리함을 주는 것'이었다. 우연히도 스켈터랩스의 미션인 “언제 어디서나 우리의 일상을 이해하고, 도와주고, 더 나아지게 하는 머신 인텔리전스의 혁신을 이룬다”와 일치하더라. 덕분에 내 꿈을 이루어나가는 것과 스켈터랩스가 혁신적인 기술을 바탕으로 성장하는 것은 궤를 같이한다. 그것이 내가 스티브잡스 처럼 특정 분야의 스타가 되는 것을 뜻하지는 않는다. 연속성이 있고 확장성이 있는 기술로 우리의 일상을 조금씩 더욱 편리하게 가꾸어나가고 싶다.Q. 마지막 질문이다. 스켈터랩스에 바라는 점이 있다면 무엇인가.A. 내가 입사했을 때만 해도 20명 정도에 불과했던 인원이 현재는 70여 명으로 늘었다. 체감상 인원이 조금씩 느는 것이 아니라 순간적으로 확 늘어나는 시기가 있는 것 같다. 그 때마다 약간의 침체기랄까, 분위기가 변하는 모습이 감지된다. 예전에는 사람이 적기 때문에 자연스레 커뮤니케이션이 자율적이이었지만, 사람이 늘어난 만큼 제한적인 커뮤니케이션 모습을 종종 발견할 수 있었다. 이러한 문제 의식의 발로로 컬쳐커미티(Culture Committee)가 생겨났다. 커미티의 활동 덕분에 매주 1:1로 커피를 마실 수 있는 커피믹스와 같은 제도도 신설되었다. 이렇듯 지속적으로 우리만의 모습을 유지하기 위한 노력이 지속되었으면 좋겠다. “우리는 답을 찾을 것이다. 늘 그랬듯이”, 흔한 명대사지만 스켈터랩스 또한 내부적으로도, 외부적으로 늘 답을 찾아가길 바란다. 물론 나 또한 그 답을 찾는 여정에 함께할 테지만 말이다.

 VCNC에서 엔지니어링 블로그를 시작하고 벌써 새로운 해를 맞이하였습니다. 그동안 여러 글을 통해 VCNC 개발팀의 이야기를 들려드렸습니다. 이번에는 엔지니어링 블로그 자체를 주제로 글을 적어보고자 합니다. 저희는 워드프레스나 텀블러와 같은 일반적인 블로깅 도구나 서비스를 사용하지 않고 조금은 개발자스럽다고 할 수 있는 특이한 방법으로 엔지니어링 블로그를 운영하고 있습니다. 이 글에서는 VCNC 개발팀이 엔지니어링 블로그를 운영하기 위해 이용하는 방법들을 소개하고자 합니다. 그리고 블로그를 운영하기 위해 방법을 다루는 중간중간에 개발팀의 문화와 일하는 방식들에 대해서도 간략하게나마 이야기해보고자 합니다.블로그에 사용하는 기술들Jekyll: Jekyll은 블로그에 특화된 정적 사이트 생성기입니다. GitHub의 Co-founder 중 한 명인 Tom Preston-Werner가 만들었으며 Ruby로 작성되어 있습니다. Markdown을 이용하여 글을 작성하면 Liquid 템플릿 엔진을 통해 정적인 HTML 파일들을 만들어 줍니다. VCNC 엔지니어링 블로그는 워드프레스같은 블로깅 도구를 사용하지 않고 Jekyll을 사용하고 있습니다.Bootstrap: 블로그 테마는 트위터에서 만든 프론트엔드 프레임워크인 Bootstrap을 이용하여 직접 작성되었습니다. Bootstrap에서 제공하는 다양한 기능들을 가져다 써서 블로그를 쉽게 만들기 위해 이용하였습니다. 덕분에 큰 공을 들이지 않고도 Responsive Web Design을 적용할 수 있었습니다.S3: S3는 AWS에서 제공되는 클라우드 스토리지 서비스로서 높은 가용성을 보장합니다. 일반적으로 파일을 저장하는 데 사용되지만, 정적인 HTML을 업로드하여 사이트를 호스팅하는데 사용할 수도 있습니다. 아마존의 CTO인 Werner Vogels 또한 자신의 블로그를 S3에서 호스팅하고 있습니다. VCNC Engineering Blog도 Jekyll로 만들어진 HTML 파일들을 아마존의 S3에 업로드 하여 운영됩니다. 일단 S3에 올려두면 운영적인 부분에 대한 부담이 많이 사라지기 때문에 S3에 올리기로 하였습니다.CloudFront: 브라우저에서 웹페이지가 보이는 속도를 빠르게 하려고 아마존의 CDN서비스인 CloudFront를 이용합니다. CDN을 이용하면 HTML파일들이 전 세계 곳곳에 있는 Edge 서버에 캐싱 되어 방문자들이 가장 가까운 Edge를 통해 사이트를 로딩하도록 할 수 있습니다. 특히 CloudFront에 한국 Edge가 생긴 이후에는 한국에서의 응답속도가 매우 좋아졌습니다.s3cmd: s3cmd는 S3를 위한 커맨드 라인 도구입니다. 파일들을 업로드하거나 다운로드 받는 등 S3를 위해 다양한 명령어를 제공합니다. 저희는 블로그 글을 s3로 업로드하여 배포하기 위해 s3cmd를 사용합니다. 배포 스크립트를 실행하는 것만으로 s3업로드와 CloudFront invalidation이 자동으로 이루어지므로 배포 비용을 크게 줄일 수 있었습니다.htmlcompressor: 정적 파일들이나 블로그 글 페이지들을 s3에 배포할 때에는 whitespace 등을 제거하기 위해 htmlcompressor를 사용합니다. 또한 Google Closure Compiler를 이용하여 javascript의 길이도 줄이고 있습니다. 실제로 서버가 내려줘야 할 데이터의 크기가 줄어들게 되므로 로딩속도를 조금 더 빠르게 할 수 있습니다.블로그 관리 방법앞서 소개해 드린 기술들 외에도 블로그 글을 관리하기 위해 다소 독특한 방법을 사용합니다. 개발팀의 여러 팀원이 블로그에 올릴 주제를 결정하고 서로의 의견을 교환하기 위해 여러 가지 도구를 이용하는데 이를 소개하고자 합니다. 이 도구들은 개발팀이 일할 때에도 활용되고 있습니다.글감 관리를 위해 JIRA를 사용하다.JIRA는 Atlassian에서 만든 이슈 관리 및 프로젝트 관리 도구입니다. VCNC 개발팀에서는 비트윈과 관련된 다양한 프로젝트들의 이슈 관리를 위해 JIRA를 적극적으로 활용하고 있습니다. 제품에 대한 요구사항이 생기면 일단 백로그에 넣어 두고, 3주에 한 번씩 있는 스프린트 회의에서 요구사항에 대한 우선순위를 결정합니다. 그 후 개발자가 직접 개발 기간을 산정한 후에, 스프린트에 포함할지를 결정합니다. 이렇게 개발팀이 개발에 집중할 수 있는 환경을 가질 수 있도록 하며, 제품의 전체적인 방향성을 잃지 않고 모두가 같은 방향을 향해 달릴 수 있도록 하고 있습니다.VCNC 개발팀이 스프린트에 등록된 이슈를 얼마나 빨리 해결해 나가고 있는지 보여주는 JIRA의 차트.조금만 생각해보시면 어느 부분이 스프린트의 시작이고 어느 부분이 끝 부분인지 아실 수 있습니다.위와 같은 프로젝트 관리를 위한 일반적인 용도 외에도 엔지니어링 블로그 글 관리를 위해 JIRA를 사용하고 있습니다. JIRA에 엔지니어링 블로그 글감을 위한 프로젝트를 만들어 두고 블로그 글에 대한 아이디어가 생각나면 이슈로 등록할 수 있게 하고 있습니다. 누구나 글감 이슈를 등록할 수 있으며 필요한 경우에는 다른 사람에게 글감 이슈를 할당할 수도 있습니다. 일단 글감이 등록되면 엔지니어링 블로그에 쓰면 좋을지 어떤 내용이 포함되면 좋을지 댓글을 통해 토론하기도 합니다. 글을 작성하기 시작하면 해당 이슈를 진행 중으로 바꾸고, 리뷰 후, 글이 발행되면 이슈를 해결한 것으로 표시하는 식으로 JIRA를 이용합니다. 누구나 글감을 제안할 수 있게 하고, 이에 대해 팀원들과 토론을 하여 더 좋은 글을 쓸 수 있도록 돕기 위해 JIRA를 활용하고 있습니다.JIRA에 등록된 블로그 글 주제들 중 아직 쓰여지지 않은 것들을 보여주는 이슈들.아직 제안 단계인 것도 있지만, 많은 주제들이 블로그 글로 발행되길 기다리고 있습니다.글 리뷰를 위해 Pull-request를 이용하다.Stash는 Attlassian에서 만든 Git저장소 관리 도구입니다. GitHub Enterprise와 유사한 기능들을 제공합니다. Jekyll로 블로그를 운영하는 경우 이미지를 제외한 대부분 콘텐츠는 평문(Plain text)으로 관리 할 수 있게 됩니다. 따라서 VCNC 개발팀이 가장 자주 사용하는 도구 중 하나인 Git을 이용하면 별다른 시스템의 도움 없이도 모든 변경 내역과 누가 변경을 했는지 이력을 완벽하게 보존할 수 있습니다. 저희는 이런 이유로 Git을 이용하여 작성된 글에 대한 변경 이력을 관리하고 있습니다.또한 Stash에서는 GitHub와 같은 Pull request 기능을 제공합니다. Pull request는 자신이 작성한 코드를 다른 사람에게 리뷰하고 메인 브랜치에 머지해 달라고 요청할 수 있는 기능입니다. 저희는 Pull request를 활용하여 상호간 코드 리뷰를 하고 있습니다. 코드 리뷰를 통해 실수를 줄이고 개발자 간 의견 교환을 통해 더 좋은 코드를 작성하며 서로 간 코드에 대해 더 잘 이해하도록 노력하고 있습니다. 새로운 개발자가 코드를 상세히 모른다 해도 좀 더 적극적으로 코드를 짤 수 있고, 업무에 더 빨리 적응하는데에도 도움이 됩니다.어떤 블로그 글에 대해 리뷰를 하면서 코멘트로 의견을 교환하고 있습니다.코드 리뷰 또한 비슷한 방법을 통해 이루어지고 있습니다.업무상 코드 리뷰 뿐만 아니라 새로운 블로그 글을 리뷰하기 위해 Pull request를 활용하고 있습니다. 어떤 개발자가 글을 작성하기 위해서 가장 먼저 하는 것은 블로그를 관리하는 Git 리포지터리에서 새로운 브랜치를 따는 것입니다. 해당 브랜치에서 글을 작성하고 작성한 후에는 새로운 글 내용을 push한 후 master 브랜치로 Pull request를 날립니다. 이때 리뷰어로 등록된 사람과 그 외 개발자들은 내용에 대한 의견이나 첨삭을 댓글로 달 수 있습니다. 충분한 리뷰를 통해 발행이 확정된 글은 블로그 관리자에 의해 master 브랜치에 머지 되고 비로소 발행 준비가 끝납니다.스크립트를 통한 블로그 글 발행 자동화와 보안준비가 끝난 새로운 블로그 글을 발행하기 위해서는 일련의 작업이 필요합니다. Jekyll을 이용해 정적 파일들을 만든 후, htmlcompressor 통해 정적 파일들을 압축해야 합니다. 이렇게 압축된 정적 파일들을 S3에 업로드 하고, CloudFront에 Invalidation 요청을 날리고, 구글 웹 마스터 도구에 핑을 날립니다. 이런 과정들을 s3cmd와 Rakefile을 이용하여 스크립트를 실행하는 것만으로 자동으로 이루어지도록 하였습니다. VCNC 개발팀은 여러 가지 업무 들을 자동화시키기 위해 노력하고 있습니다.또한, s3에 사용하는 AWS Credential은 IAM을 이용하여 블로그를 호스팅하는 s3 버킷과 CloudFront에 대한 접근 권한만 있는 키를 발급하여 사용하고 있습니다. 비트윈은 특히 커플들이 사용하는 서비스라 보안에 민감합니다. 실제 비트윈을 개발하는데에도 보안에 많은 신경을 쓰고 있으며, 이런 점은 엔지니어링 블로그 운영하는데에도 묻어나오고 있습니다.맺음말VCNC 개발팀은 엔지니어링 블로그를 관리하고 운영하기 위해 다소 독특한 방법을 사용합니다. 이 방법은 개발팀이 일하는 방법과 문화에서 큰 영향을 받았습니다. JIRA를 통한 이슈 관리 및 스프린트, Pull request를 이용한 상호간 코드 리뷰 등은 이제 VCNC 개발팀의 문화에 녹아들어 가장 효율적으로 일할 수 있는 방법이 되었습니다. 개발팀을 꾸려나가면서 여러가지 시행 착오를 겪어 왔지만, 시행 착오에 대한 반성과 여러가지 개선 시도를 통해 계속해서 더 좋은 방법을 찾아나가며 지금과 같은 개발 문화가 만들어졌습니다. 그동안 그래 왔듯이 앞으로 더 많은 개선을 통해 꾸준히 좋은 방법을 찾아 나갈 것입니다.네 그렇습니다. 결론은 저희와 함께 고민하면서 더 좋은 개발문화를 만들어나갈 개발자를 구하고 있다는 것입니다.

중딩시절 판타지소설을 참 좋아했습니다. 물론 그 계기는 집에 들어가기 싫었기 때문입니다. 합법적으로 등짝을 쳐맞지 않고 늦게 들어갈 수 있는 방법은 서점에서 책을 읽는 것이었죠. 당시엔 이우혁의 퇴마록이 세계편까지 등장한 시점이었죠. 전 월향의 쉬이이이이~하는 소리에 소름을 느끼며 판타지소설에 빠져들기 시작했습니다. 퇴마록을 시작으로 그 1년간 판타지소설만 거의 900권 가까이 읽었던 것 같습니다. 하루에 2,3권, 주말엔 3,4권씩 닥치는 대로 봤기 때문이지요. 그렇게 중3까지 판타지를 보고나니, 나중엔 볼 게 없더군요. 볼 게 없어지니 쓰고 싶어졌습니다. 그래서 고등학교 1학년 때 선풍적인 커뮤니티였던 다모임에 판타지소설을 하나하나 연재하기 시작했습니다. 친구들의 이름을 넣어서 말이죠. 친구들은 왜 자길 죽이냐, 날 살려라, 나는 왜 이렇냐, 멋지게 바꿔줘라, 내가 왜 얘랑 커플이냐 등등 각종 MBC아침드라마 시청자게시판같은 피드백을 쏟아내었고 전 임성한작가로 빙의하여 녀석들을 살렸다 죽였다 하면서 책기준으로 3~4권짜리 판타지소설을 쓰게 되었습니다. johnna 전설판타지를 쓰다보니 여러가지 생각이 들더군요. 세계관을 만들어야 하고, 영어사전을 뒤적거리며 겁나 멋진 단어를 찾아야했습니다. 주로 S나 H로 시작하는곳에 멋진 이름들이 많더군요. 영어시간을 이용해서 사전을 뒤적거리니 혼날 일도 없었고, 뭔가 열심히 공부하는 것처럼 보였는 지 선생님도 좋아하셨습니다. 샘, 그 때 전 마법기술 이름 찾고있었어요, 죄송합니다. 브랜딩얘기한다면서 왜 갑자기 판타지소설에 대한 얘기를 하는 지 고개를 양쪽으로 갸웃갸웃하실 분들이 많을 겁니다. 사실 0도 상관이 없어보이기도 하지요. 왜냐면 요즘 사람들이 말하는 브랜딩이란 존나 고귀한 것이라서 가치와 전략을 논하면서 펜돌리기를 시전해야하는 전문적인 영역처럼 비추어지니까요. 하지만 저는 일단 그런 종류의 브랜딩을 논하지 않을 뿐더러, 굴러다니는 돌멩이조차도 브랜딩의 한 부분이라고 생각하는 터라 오늘도 쓸데없는 소재에서 쓸데없는 썰을 풀어보고자 합니다.시작합니다.판타지소설을 읽지 않았거나, 관심없는 분들도 반지의 제왕 정도는 알고계실겁니다. 스타크래프트도 알고 계시겠죠. 먼저 스타크래프트 이야기를 해봅시다. 스타는 전략시뮬레이션 게임의 한 획을 그으며 지금까지도 회자되는 최고의 게임이라고 할 수 있습니다. 스타가 이렇게 성공할 수 있었던 데에는 유닛의 밸런스나 네트워킹을 통한 베틀넷, 친구와의 3:3 무한헌터맵의 졸잼 등이 있겠지만... 그 베이스에는 겁나 엄청난 스토리라인이 있습니다. 엔타로 테사다르압축해보자면 이런겁니다. 젤나가라는 개불을 닮은 창조성애자 외계종족이 재미삼아 프로토스를 만들었는데, 너무 똑똑해져서 창조주 젤나가를 개패듯이 패고 쫓아내버립니다. 마음의 상처를 입은 젤나가는 이번엔 말 잘듣는 멍청이들을 만들어야지!~하면서 저그를 만들었는데, 얘네들도 통제가 안되면서 젤나가는 아씌..다 망했어 싶어서 쓸쓸이 우주 뒷편으로 숨어있습니다. 그러다가 테란이 등장하면서 대우주 삼국지가 펼쳐지는데, 우주에는 대악마같은 나쁜새끼가 있었습니다. 그 놈을 무찌르려면 프로토스와 저그가 힘을 합쳐야 했죠. 그 매개체가 되는 것이 바로 테란의 유닛이었다가 저그에 잡혀와서 레게머리화가 된 캐리건이었습니다. 그리고 스타2에 이르러서 캐리건은 자길 버린 테란의 복수를 하고 프로토스와 저그의 힘을 동시에 받아 나쁜자식을 물리치고 자기가 젤나가가 된다는 스토리입니다. 적과의 동침, 신이된 인간의 클리셰를 따라가지요.우주를 배경으로 했고, 각자의 행성이 존재하고, 3개의 종족이 피터지게 싸우다가 나중엔 공동의 적을 물리치기 위해 손잡고 평화를 되찾았다. 라는 것입니다.올리폰트 왔쪄욤 뿌우!반지의 제왕 스토리는 이런 것입니다. 사우론이 절대반지를 만들고 세계지배잼을 즐기자 요정, 드워프, 인간들이 편먹고 사우론과 싸우다가 손가락을 잘라 절대반지를 되찾습니다. 당연히 그렇듯 반지를 부수라는 말을 안들어쳐먹고 자기가 잘 보관하겠다는 설날명절 엄마멘트를 날린 뒤 반지쟁탈싸움을 벌이다가 이별한 남자친구 마냥 강물에 던져버리고 오랜시간이 흘렀습니다. 강물은 S자를 그리며 안쪽부터 유속이 느려지므로 퇴적물은 그 쪽에 쌓이게 됩니다. (지리시간) 이렇게 쌓인 퇴적물은 농사를 짓기 적합한 비옥한 토양으로 바뀌게 되고 그쪽에 샤이어가 생기고 호빗들이 살아가게 됩니다. 그러다가 생일을 맞은 스미골이 친구와 낚시잼을 즐기다가 강물아래 절대반지를 발견하고 눈이 뒤집힙니다. 서로 반지를 차지하려다 친구호빗을 죽인 스미골은 동굴로 들어가 쑥과 마늘로 100일을 연명하며 골룸으로 변하게 되는데 호빗3부작에서 이 반지를 빌보 베긴스가 줍하는 스토리가 나옵니다. 빌보삼촌에서 프로도로 이어진 후, 간달프가 폭족놀이를 핑계로 반지의 유치권을 행사하려고 하는 것이 반지의제왕의 시작입니다. 나머지는 아시다시피 골룸이 집요하게 내 보물!을 외치고 프로도와 샘이 사랑의 힘으로 반지를 파괴하고 중간계의 평화를 되찾는다는 게이물....아니;; 환타지물입니다.뜬금없이 왜 이런 얘기를 하냐면, 바로 '세계관'에 대한 설명을 해야하기 때문이죠.판타지소설은 기본적으로 가상의 세계를 기반으로 합니다. 때문에 모든 세계를 창조부터 현재의 지도까지 세세하게 구축을 해야하죠. 이러한 세계관의 구축은 스토리의 개연성과 갈등관계, 모든 것들의 존재의 이유를 설명합니다.브랜딩도 마찬가지입니다. 기본적으로 비지니스는 세상에 없었거나 기존에 있던 어떤 것이 달라진 형태로 등장합니다. 그것을 경험하는 소비자입장에선 없던 것이 등장한 것입니다. 때문에 이것의 탄생과 개연성, 존재의 이유를 설명해야 합니다.우리의 비지니스는 어떤 모습으로 그려지고, 어디에 어떻게 위치해 있는지, 어떤 식의 역사가 있었고, 어떻게 지금의 이것이 탄생하게 되었는지 스토리의 개연성을 만들어내야 합니다. 물론 우리가 반지의 제왕 이전의 스토리를 전혀 모르고 있듯, 또는 어벤져스2는 봤지만, 마블세계관에 대해선 별 관심이 없듯 소비자들은 이러한 상세한 세계관에 대해 알려고 하지 않습니다. 귀찮은 일이죠. 반지의 제왕 영화가 나왔을 때도, 이러한 세계관에 대한 자세한 소개는 없었습니다. 그럼에도 불구하고 모든 요소들이 챡챡 맞아들어가거나, 추후에 세계관을 알게되었을 때의 소름을 느끼며, 광대한 세계관에 경악을 금치 못하게 됩니다.세계관 구축은 소비자를 위해서라기 보단 나와 직원들을 이해시키기 위해 필요합니다. 비지니스의 개연성을 확실하게 만들기 위해서죠. 구체적인 세계관을 구축하는 것의 힘판타지소설에서는 탄생설화부터 각 종족의 생성까지 모든 것에 이유와 개연성을 부여합니다. 드래곤은 왜 생겼고, 드워프는 어떻게 생겼고, 각 대륙은 어떻게 존재하게 되었는지 신의 입장에서 모든 세계를 만들어야 하죠. 사실상 비지니스도 비슷한 맥락을 따라갑니다. 우리의 서비스는 무엇을 배경으로 탄생했으며, 그 성장과 갈등관계는 무엇이었는지. 현재 우리 비지니스를 어떠한 세계라고 하면, 왜 이것과 이것은 갈등하게 되었는지, 위협요소는 무엇이고, 옆 나라 협력업체는 누구이고, 우리는 여기서 왜 살아가고있는지에 대한 이유를 알려주어야 합니다.1. 캐릭터의 구축그리곤 캐릭터를 만들어줘야 합니다. 중간계대륙의 지도이러한 멋진 나라가 구축되었고 각 나라가 생겼고, 생긴 이유까지 나왔으면 이제 이 세계를 토대로 움직이는 캐릭터가 있어야 할 게 아닙니까. 세계관의 구축이 브랜딩의 기초와 개연성을 만들어주는 바탕이라면캐릭터는 실제로 브랜딩 퍼포먼스를 의미합니다.캐릭터의 구축방법은 5가지 셋팅을 따라가야 합니다. 한 번 보실까요.1. 일단 기본적으로 외모와 성격을 큼직하게 설정합니다.2. 그 성격이나 흉터 등이 생기게 된 유년시절을 구축합니다.3. 특징이 되는 에피소드를 구체화시키고, 캐릭터가 지닌 가치관과 선입견을 설정합니다.4. 캐릭터 주변의 가족과 친구 등 삶의 영향을 주는 인물들간의 관계를 설정합니다.5. 캐릭터의 동선과 거주지, 관계를 통한 열망과 욕망을 설정합니다.이것을 비지니스로 바꾸어보면 이렇습니다.1. 일단 회사의 성향과 로고, 비쥬얼컨셉을 설정합니다.2. 비지니스의 개연성과 설립목적, 비쥬얼컨셉과의 일관성을 만들어냅니다.3. 주요 레퍼런스와, 회사가 지닌 가치관을 구체화시키고 공유합니다.4. 회사 외적인 요소들간의 관계(경쟁사, 협력사, 벤치마킹 등)을 설정합니다.5. 비지니스의 범위, 활동영역, 타겟팅, 목표를 설정합니다.물론 1,2,3,4,5가 서사적순서로 흘러가는 것은 아닙니다. 어찌보면 거의 동시에 이루어지기도 하고, 경우에 따라 우선순위가 바뀔 때도 있습니다. 그러나 '성격.가치관.철학.욕망' 등이 내적요소와 '관계.환경.신체적요소.시대적배경' 등의 외적요소를 모두 빠짐없이 구축해야한다는 사실은 변함이 없습니다.2. 캐릭터의 디테일무엇보다 캐릭터구축의 핵심은 캐릭터의 모든 행동을 저자가 통제하는 것이 아니라는 점입니다. 캐릭터의 눈 옆에 점이 몇 개 있고 주근깨가 얼마나 있는지까지 디테일하게 설정하고 나면, 캐릭터는 내가 만들어놓은 세계관 안에서 스스로 행동하고 움직이게 됩니다. 모든 것은 개연성에 의해서 필연적으로 일어나는 것들이지요. 심지어 세계관이 구체적으로 설정되어 있으면 우연조차도 필연처럼 느껴지게 됩니다.비지니스 또한 그렇습니다. 비지니스의 거대한 철학을 설정하는 것은 좋지만, 단순히 슬로건만으론 회사의 브랜드는 움직이지 않습니다. 그래서 자꾸 제가 디테일과 실무를 외치는 이유도 그것이죠. 내가 만들어놓은 회사가 스스로 브랜딩이 펼쳐나가기 위해서는 구체적이고 디테일한 성격의 설정이 있어야합니다. 우리가 쓰는 폰트는 어떤 것인가우리가 쓰는 말투는 어떨까우리가 쓰는 양식은 어떤 것인가?우리 사무실에 걸린 액자와, 문구들은 왜?우리 팀원들의 특성과 책상의 모습은?탕비실에 놓여진 커피와 다과류는?이런 세세한 설정들은 암묵적인 선입견과 스키마를 형성합니다. 여기서의 선입견은 나쁜 의미가 아닙니다. 외적으로든 내적으로든 회사에 대한 선입견이 없다는 것은 '존재하지 않는 것' 이라는 의미와 같습니다.선입견이 없다는 것은 '존재하지 않는 것' 이라는 의미와 같습니다.인간은 어떤 정보를 인식한 후 그것을 저장하기 위해 특유의 방향성을 설정하고 임의해석을 통해 변형시킵니다. 나의 가치관의 필터링을 통해 다양한 형태로 저장하려고 하죠. 이렇게 굳혀진 선입견은 오래도록 기억에 남게 됩니다. 때문에 브랜딩은 다른 말로 하면 무의식적인 선입견을 형성하는 과정과도 같죠. 여기서 선입견을 만드는 것들은 추상적이고 거대한 개념들이 아닙니다. 아주 세세한 디테일들이죠. 톨킨이 반지의제왕 세계관을 구축한 이래 대부분의 판타지소설들은 톨킨의 세계관속 클리셰와 미장센을 차용하고 있습니다. 엘프라고 하면 일단 뾰족한 귀에 아름다운 얼굴, 금발의 머리카락 등이 생각나죠. 오크는 투박한 칼과, 근육질, 험상궂은 얼굴등이 생각나죠. 대부분의 캐릭터의 구축과 움직임은 이러한 미장센에서 비롯됩니다. 이 컨셉은 아직도 변하지 않고 있습니다.그리고 소비자에게 보여주는 것도 사실상 거대한 가치관이나 철학에 대한 부분보단, 이러한 미쟝센들일 가능성이 큽니다. 실상은 보여준다기 보단 보여'지는' 것에 가깝겠죠. 기업입장에서야 엄청 선하고 대단한 철학을 막 설명하고 싶겠지만, 소비자들은 결국 포장지나 배송상태, 브로슈어와 명함등을 관찰/경험하게 되니까요.3. 캐릭터의 컨셉사람의 신뢰감은 일관성에 있다고 하듯, 기업의 신뢰감도 다르지 않습니다. 특정한 컨셉과 캐릭터가 구축되었다면 개연성있게 움직이는 것이 옳은 일이겠죠. 이 때 어떤 캐릭터를 구축해야하느냐에 대해 궁금증이 생깁니다. 물론 악역을 맡아서 지구뿌셔버려를 시전하는 것은 안되겠지만, 그 이외에 어떠한 컨셉이든 사실 상관이 없습니다. 죄다 주인공에 착한역할만 하려고 하면 세계관이 개판이 되어버리듯, 컨셉이란 것은 색깔이 뚜렷하면 될 뿐 정답이란 것이 없지요. 어떤 성향, 성격이든 그 개연성이 명확해서 이해가 되는 것이라면 괴팍한 미치광이 과학자 컨셉이라도 매력이 있기 마련입니다.캐릭터의 매력발산은 과거의 에피소드와 환경과의 관계를 통해 만들어진 이유있는 가치관을 통해서입니다. 사람도 그렇듯, 처음엔 뭥미? 싶은 괴팍한 성격도 시간이 지나 술 한 잔 하면서 그의 비하인드스토리를 듣게되면서 고개를 끄덕이게 된 경험이 한 두번씩 있을거예요. 그러니 남들의 시선을 신경쓸 필요 없습니다. 내 비지니스의 성격을 분명하게 한정시키고 '이유'를 만들어주는 작업이 더 중요합니다.4. 드래곤의 탄생드래곤이 등장하면서 판타지소설은 극적으로 변해갑니다. 호빗의 핵심을 만들었던 킬링컨텐츠가 스마우그였듯 말입니다. 또는 엄청난 궁극의 마법사가 대마왕의 반전등이 등장하면서 세계관을 흔드는 절정으로 치닫게 되죠.오이형님이 선방했던 스마우그비지니스에도 드래곤이 있습니다. 이른바 킬링컨텐츠 내지는 코어를 의미하죠. 주사업모델일수도 있고, 주력상품일수도 있겠네요. 이 드래곤의 등장은 그냥 존나 강해서 나머지를 다 싸그리 죽여버리고 혼자 보물을 독차지해서 노후걱정없이 4000년간 잘살았답니다!! 를 말하려고 나온 것이 아닙니다. 드래곤의 등장은 어떤 긴장감과 갈등관계, 긴박감과 묘한 쾌감을 불러일으켜주죠. 킬링컨텐츠란 그런 매력이 있어야합니다. 혼자만 대박 잘나서 다른 상품들을 다 개무시하는 그림을 그려선 안됩니다. 상품의 라인업이나, 신규서비스의 런칭이나, 신규아이템의 등장 등...어떤 비지니스는 대박아이템을 선보일때는 그것이 다른 것들과 어떤 연관성을 지니고 있고, 어느 정도의 위치에 있으며 어떤 타켓을 존나 공격할 것인지 명확하게 보여주어야 합니다. 드래곤에게도 성격을 부여하는 것은 이 때문입니다. 심지어 이 드래곤도 산에 쳐박혀서 혼자 2천년간 잠들어있던 이유가 있으니까요. 그러니 비지니스를 위한 다양한 상품/서비스에는 각각의 위계질서와 서로의 관계도를 설정해주는 것이 필요합니다. 제품의 라인업을 다르게 설정하고 그 중 최상위라인을 다시 만들고, 타겟별로 다시 분류하고, 이 제품과 이 제품은 함께 쓰면 안된다..는 식의 플랫폼 내부에 세계관이 구축되어 있어야 하는 것입니다. 그리고 각 제품은 각자의 성격과 탄생비화가 있어야 하죠.세계관과 캐릭터, 드래곤을 통해서 비지니스 브랜딩의 구축방법을 주절거려보았습니다. 정리해보자면 다음과 같습니다.1. 앞으로 뭔 행동을 하려고 하면 그 땅이 있어야 합니다. 땅엔 도로와 국경, 신호, 길, 옆집, 악당, 친구가 있어야 하죠. 우리 비지니스가 뿌리내리고 탄생하게 된 세계관에 대한 구체적인 설정을 해주어야 합니다.2. 이 세계위에서 우리 브랜드는 하나의 캐릭터가 되어 움직이게 됩니다. 이 때 사람들이 관찰하는 것은 이 캐릭터의 미쟝센이죠. 디테일하고 개연성있는 행동으로 고객들에게 선입견을 주어야 합니다.3. 주인공이 필살기를 쓰거나, 스토리가 절정으로 치닫게 될 때는 킬링컨텐츠나 최상위라인업이 짜잔하고 등장하게 됩니다. 그러나 이 모든 것들의 탄생은 세계관과 캐릭터간의 관계를 통해 설명되어야 합니다. 혼자 뚝...떨어져 나온 (예를 들면 모바일게임이 존나 에이핑크사진만 박아놓는 뭥믜 싶은 것들 말입니다.) 느낌이 들면 사람들은 뭐래...싶기 때문이죠.한 마디로 말하면, '맥락있는 브랜딩' 에 대한 이야기였죠. 판타지소설을 예로 들었던 것은, 그 세계와 캐릭터, 클라이막스와 생소한 아이템들을 모두 내가 창조해야한다는 점에서 비지니스와의 유사점이 있었기 때문입니다요. 창조주잼에 빠져서 자꾸 새로운 걸 만들려고만 하지말고, 만들어놓은 것들이 잘 살아가고 있는지 다시 한 번 검토해보도록 합시다. 끝

조교와 강사가 볼 수 있는 대시보드를 이용하면 학생들에 대한 EPS 분포를 확인하고 어떤 학생이 얼마나 열심히 하는지, 얼마나 높은 성취도를 이루었는지 한눈에 확인할 수 있습니다.엘리스에서는 선생님 대시보드에서 Elice Performance Score(EPS)를 확인할 수 있습니다. EPS는 학생들의 교육 현황에 따라 1점부터 5점까지 주어지며, 학생의 지금까지의 상태를 파악하여 수업이 끝날 때 얼마나 높은 성취도를 이룰 수 있을지를 자동으로 예측합니다. 이를 통해 선생님은 EPS가 낮은 학생들을 중점적으로 지도할 수 있으며 학생이 질문하기 전에 학생에게 먼저 다가가는 선제적 교육을 진행할 수 있습니다. 이러한 EPS는 어떻게 연구/개발 되었을까요?Fuller와 Elice의 전산학 교육 분류 체계분류 체계가 뭐지? 하고 갸우뚱하시는 분들이 많을 겁니다. 일반적인 분류학Taxonomy은 생물학의 학문 중 하나로, 지구에 살고 있는 생물들을 특정 기준에 따라 분류한 것을 말합니다. 그중 가장 유명한 것이 린네Carl Linnaeus의 분류법인데요, 이 글을 읽고 있는 독자들도 린네의 분류법에 대해서 배웠던 적이 있을 것입니다.계, 문, 강, 족, 목, 과, 류, 속, 종으로 이루어진 린네의 분류법. Image from Wikipedia이러한 분류법은 고도로 복잡한 생물들을 의미 있는 기준 (역사, 진화 과정, 유전학…) 에 따라 분류하고, 이들 사이의 관계를 체계적으로 밝히는 데에 목적이 있습니다. 이를 통해 기존에 없었던 새로운 동/식물이 발견되더라도 우리는 이미 확고히 정립된 분류 체계를 간단히 확장하는 것만으로 기존에 있던 동/식물들과의 관계를 정립할 수 있습니다. 그뿐만 아니라 과학의 발달과 함께 유전학 등의 도움으로 체계를 더욱 고도화할 수 있습니다.Bloom의 교육 분류체계교육학에서는 교육을 받는 과정에 대한 연구가 활발히 진행되었습니다. 1956년 Benjamin Bloom은 사람의 학습 과정을 인지/정서/정신이라는 세 개의 카테고리로 분류했습니다. 특히, 인지 영역을 낮은 정신 능력에서 고등 정신 능력이 필요한 활동 6가지로 분류했습니다. 학생은 가장 기본이 되는 암기 — 어떤 형상이나 사실에 대한 정보를 기억하는 것 — 로 시작해 이해, 적용, 분석, 평가를 거쳐 창작 — 다양한 원소를 조합해 새로운 구조나 패턴을 창출하는 것 — 으로 배움을 마무리하게 됩니다.Ursula Fuller는 전산학 교육과 기존 교육의 차이점에 주목했습니다. 다른 교육과는 달리, 전산학 교육은 코딩, 즉 창의적으로 새로운 것을 만들어내는 활동이 주가 되는 학문입니다. Bloom의 교육 분류체계에서는 학생이 새로운 코드를 만들어 내기 전에 그곳에서 사용하는 모든 원소에 대한 이해, 적용, 분석, 평가를 모두 완료해야 하지만 실제로 코딩을 배워보신 분들은 그렇지 않다는 것을 알고 있을 것입니다. 예를 들어, Python에서 새로운 개념인 recursion (재귀 호출) 을 배웠다고 하면 이것에 대한 깊은 이해 없이 재귀적으로 호출되는 함수를 만들어 보고 실행해 볼 수 있습니다. 아직 재귀호출이 얼마나 성능이 좋은지 평가하거나 분석할 수 없더라도 재귀적으로 동작하는 함수가 들어있는 프로그램을 만들 수 있습니다.Elice에서 코드를 작성하면서 전산학에 대해 배우는 과정. Fuller의 taxonomy를 Elice 연구팀이 학생의 코드 작성 과정에 적용했습니다. Image from Elice: An online CS Education Platform to Understand How Students Learn ProgrammingFuller는 차원을 하나 확장해 전산학 교육을 학생이 이론적인 것을 배우는 Interpreting 차원과 코드를 통해 새로운 것을 만들어내는 Producing 차원 두 개로 정리했습니다. 예를 들어 Implement 단계는 학생이 이론에 대한 깊은 이해 없이 현상에 대한 기억만을 의존하여 구현하고 테스트를 해 보는 단계입니다. 만약 여기에서 더 이상 이론에 대한 학습이 진행되지 않는다면 학생은 Implement/Test 단계에서 계속 머무르게 됩니다. 실행해 보고, 안 되면 조금 고쳐 보고, 다시 실행해 보고, …학생이 이론에 대해 이해하고, 그 이론에 대해 분석할 수 있는 단계가 되면 (예: 재귀 호출의 시간복잡도를 계산할 수 있게 됨) 학생은 드디어 문제가 무엇인지 판별하고 이것을 고칠 수 있는 활동 (Debug) 을 할 수 있게 됩니다. 코딩 스킬이 받쳐준다면 어떻게 해야 더 좋은 코드를 만들 수 있을지 생각해 볼 수도 있습니다 (Design). 어떻게 고칠지 생각해 내고, 이것을 구현 (Implement) 하는 단계를 반복하다 보면 학생은 이론과 개발 양쪽 차원에서 서서히 학습을 진행하면서 최종 단계인 Refactor 단계에 이르게 됩니다. Refactor는 작성한 코드를 최적화하는 단계로 높은 개발 능력과 이론에 대한 완전한 이해가 있어야만 이룰 수 있습니다.교육 분류 체계를 Elice에 적용하기Elice의 연구팀은 Fuller의 교육 분류체계를 Elice에 맞게 변형시켰습니다. Elice 의 인공지능 시스템 elice-ai는 학생이 제출하는 코드를 자동으로 분석하여 현재 학생이 제출한 코드가 교육 분류체계에서 어떤 단계인지 분류합니다. 이를 통해 학생이 현재 풀고 있는 문제에서, 혹은 과목에서 학생이 이론적으로 얼마나 많이 배웠는지, 얼마나 개발을 잘할 수 있는지 판단할 수 있습니다.Elice 연구팀이 2016년에 Learning at Scale 국제학회에 발표한 논문에서는 1,000명이 참가한 온라인 기계학습 강의에서 이 새로운 교육 분류 체계의 효과성을 검증했습니다. 분석 결과는 굉장히 흥미로웠습니다. 먼저 조교가 있는 조 기반의 학습, 조교가 없는 조 기반의 학습, 그리고 학생 혼자 듣는 상황을 비교했을 때 조교가 있는 조교가 있을 때의 학습 성취도가 조교가 없을 때의 학습 성취도보다, 그리고 조 기반의 학습에서의 학습 성취도가 혼자 수업을 진행할 때의 학습 성취도보다 월등히 높았습니다.4주 동안의 “조교가 있는 조 기반의 학습”, “조교가 없는 조 기반의 학습”, “혼자 학습” 을 진행한 학생들의 학업 성취도. 조교가 있을때, 그리고 조 기반의 학습을 할 때 성취도가 월등하게 높았습니다. Image from Elice: An online CS Education Platform to Understand How Students Learn Programming이러한 발견은 현재 Elice가 수행하고 있는 Python, Java, 데이터 구조 수업에서 강사와 학생 간의 인터랙션을 최대화하는 수업을 진행하는 데에 도움이 되었습니다. 또한, 새로운 분류 체계를 적용한 결과, 기존의 방법에 비해 학생들의 미래 성적을 굉장히 높은 정확도로 예측할 수 있었습니다.2주간의 학생의 학습 현황을 토대로 6주 후의 학습 진행을 예측. Pearson’s r: 0.914, 0.905. Image from Elice: An online CS Education Platform to Understand How Students Learn Programming위 그래프는 학생의 2주간의 학습 현황을 토대로 학생의 8주 뒤의 성적 및 Elice에서 코딩을 위해 쓴 시간을 예측한 것입니다. 예측을 위해 사용한 알고리즘이 굉장히 간단한 알고리즘 (linear regression with OLS)임에도 불구하고, 매우 훌륭한 결과를 보여주었습니다. 이 시스템을 통해, 학생의 초반 행동을 분석하면 학생의 미래 성취도 및 노력을 높은 정확도로 예측할 수 있습니다. 그리고 이것을 수치화한 것이 EPS (Elice Performance Score) 입니다.마치며이번 포스트에서는 엘리스의 AI 시스템이 하는 역할 중 하나인 EPS와 그것의 바탕 이론이 되는 Elice의 학습 분류체계에 대해서 살펴보았습니다. EPS 점수는 수업을 어려워하는 학생을 찾아내는 것 외에도 우수학생 선발 및 교육 과정이 원활히 진행되는지 살펴보는데에도 사용되고 있습니다.이 체계를 더욱 고도화하면 학생들이 문제를 푸는 동안 실시간으로, 선제적으로 도움을 줄 수 있습니다. 예를 들어, 학생이 문제를 풀다 어떤 부분에서 막히게 되면 Implement — Debug 과정을 반복하게 됩니다 (이것을 Implement-Debug cycle이라고 부릅니다). 이 늪에 빠진 학생을 조교가 빠르게 도와줄 수 있다면, 혹은 문제를 이미 푼 다른 학생이 도와줄 수 있다면 교육의 효과성과 즐거움이 더욱 증가할 것입니다.글쓴이김수인: KAIST 전산학부 박사과정 / Research Lead, Elice#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개

개발자와 개발 조직에게 소스코드 리뷰는 필수적이다. 팀간의 협업과 대화를 보다 원활하게 만들어 주는 매우 필요한 절차이다. 슬랙과 같은 협업도구가 명쾌하게 의미 있게 활용되려면 개발팀 간의 소스코드 리뷰는 필수적으로 수행되는 것이 좋다.매우 당연한 이야기이지만, 소스코드 리뷰는 거북하고 불편하고 어렵고 힘들다. 그럼에도 불구하고 필수적인 이벤트가 되어야 하는 이유가 너무도 많다. 개발자들에게 코드리뷰에 대한 이슈를 설득하고 실제 행위를 발생시키는 것은 정말 어려운일이다. 더군다나 뜬금없이 코드리뷰 이야기를 회사나 팀리더에게서 갑자기 듣는다면 개발자는 매우 불편해 한다. 그것은 매우 당연한 반응이다. 그러므로, 가능하다면 팀 세팅 초기 시부터 이 소스코드 리뷰 문화는 만들어질 수 있게 노력하는 것이 최선일 것이다.초기에 세팅된다면 그 후에 들어오는 팀원들은 자연스럽게 그 문화에 익숙해진다. 이런 일련의 작업들은 결국 조직과 팀의 단결과 협력, 향후 유지보수에 매우 긍정적인 효과를 준다.매우 당연하지만 개발자들은 팀에 소속되고 빠져나가기를 반복한다. 이를 두려워하지 않는 방법 중에 가장 먼저 선택할 수 있는 것이 바로 코드 리뷰라는 행위다. 인수인계와 유지보수를 위해서 소스코드 리뷰를 각 단계별에 배치해두고, 그 시간을 투자하는 것을  아까워하지 않도록 하자.그렇다면, 소프트웨어의 본체인 소스코드를 타인이 리뷰한다는 것이 왜 어려울까? 그것은 소스코드는 언제나 완성상태가 아니라는 점 때문이다. 개발자의 생각은 무언가 다양한 변화를 예측하고 있고, 그 상세한 준비를 담고 있다. 언제나 소스코드는 완성 상태가 아니라, 변화되어야 하는 시간의 축을 담고 있기 때문이다.하지만, 소프트웨어 품질이 중요한 현재의 시점에서 본다면, 코드 리뷰라는 행위는 정말 필수 불가결한 행위에  해당한다고 생각한다.이런 필수적인 코드리뷰는 그 형태와 범위에 대해서 팀 내부에 잘 정의되어야 한다.그래서, 보통 이 코드리뷰를 어떻게 할 것인가에 대해서 조직이나 담당하는 사람의 경우에는 명쾌한 판단 기준이 있어야 한다. 그러한 ‘판단기준’을 가져야만 명확한  리뷰될 수 있다.이를 두고, 디자이너에게는 크리틱(critique-비평)이 있고, 개발자에게는 코드리뷰가 있다고 정의한다.좋은 비평을 받고 좋은 리뷰를 하려면 다음의 3가지 원칙이 필수이다.1. 리뷰는 언제나 상호 합의가 되어진 상황에서 진행되어야 한다.2. 리뷰어의 해당 결과물에 대해서 객관성을 가지고 서로 인지해야 한다3. 개발자 자신의 작업물에 대해서 정말 객관적으로 바라볼 수 있는 작성가가 선정되어야 한다.특히, 소프트웨어 코드는 정량적인 검토와 정성적인 검토를 구분해야 한다. 이 영역의 구분이 모호해지면, 리뷰는 그 방향성을 상실하게 된다. 그중에 특히, 정량적인 검토와 기본적인 규칙들은 가능한 자동화하고, 소스 형상관리 도구에서 기본적인 것들의 규칙들을 지키도록 권장하여야 한다. 최소한 이 정량적인 것만 자동화하고  규칙화해도 소프트웨어의 품질은 급상승한다.하지만, 코드는 논쟁을 발생시키고, 어떤 것이 우선적인지에 대해서 서술하기 매우 어렵다. 이러한 점은 정성적인 부분에 대해서 검토할 때에 고민하자.코드리뷰의 정도는 어느 정도 해주어야 하는가?그 전부터 주목하는 개발 방법론의 추세는 ‘테스팅’을 주로 하고, SRS와 같은 요구사항에 집중하기 보다는, TDD와 같은 방법으로 완성 산출물을 높이는 방법을 현재에는 주로 사용하고 있다.그것은 과거에는 요구사항을 통해서 결과물이 완성되는 SI성 개발이 주로였다면, 현재에는 요구사항은 계속 변화하고 버그 없는 결과물이 중요시되는 테스트를 얼마나 더 집중적으로 하느냐에 따른 웹서비스의 시대이기 때문에 그 방향성은 시대에 따라서 변화를 많이 하였다. 그래서, 슬프지만, 당장의 성과물을 위해서라면 코드리뷰보다는 테스팅에 집중하는 것이 더 효율적이다. 빠르게 고속 개발하고 테스트를 통해서 버그를 찾은 다음 수정하는 것이 ‘특정 기능들을 나열하고 기능을 만족하는 소프트웨어’의 경우에는 테스트 주도 개발 방법이 가장 적합하다고 할 수 있다.물론, 이러한 방향성이나 전체적인 틀에 대해서는 아키텍트가 잘 결정하여야 한다. 내가 속한 개발 결과물이 어떤 결과물이냐에 따라서 이 방법은 혼용되어져서 사용되어야 하기 때문이다.하지만, 이번 글의 주목적은 코드리뷰. SRS중심이건, TDD중심이건. 코드리뷰는 중요하다는 것을 강조하고 싶다. 특히, 코드리뷰는 ‘기능 나열’이 아닌, 어느 정도 이상의 복잡도나 코드 품질이 필요한 경우에는 필수적으로 수행하는 것이 매우 현명한 행동이다.물론, 코드리뷰 행위가 불필요한 업무들도 많다. 정해져 있는 단순한 업무를 수행하는 경우에는 굳이 할 필요 없다. 국내에서 SI를 하는 경우에는 대부분 코드리뷰가 필요 없는 업무를 하는 소프트웨어 개발자들이 절대 다수인 경우도 많이 보았다.일반적인 SI의 형태라면 워크 스루의 형태만 적합하다. 특정 도메인에 매몰되어 있고, 처리방법이 명쾌하기 때문에, 해당 경험들을 교환하는 것으로도 충분하기 때문이다. 그리고, 자동화된 테스트 수행방법을 최대한 갖추어두는 것이 가장 현명하다.그러므로, 코드리뷰는 어느 정도 솔루션이나 서비스 등을 고려하고 있는 곳에서 더욱 적합하다고 정의한다.코드리뷰는 특정 제품이나 서비스를 발전적으로 지향하고 있는 경우라면 필수적으로 선택해야 한다. 하지만, 일부 제품의 경우에는 발전적인 지향이 굳이 필요 없는 제품 라인업을 가진 경우에도 굳이 수행할 필요 없다.그 경우에는 선택적인 코드리뷰를 지향하면 된다. 비용상의 문제 때문에 굳이 코드리뷰를 억지로 진행할 필요는 없는 경우도 많다. 대부분의 소프트웨어 개발은 테스트 케이스를 잘 만들고, 통과시키는 것으로써 충분한 신뢰를 가지면 충분한 경우가 대부분이다.특히, 시장이 고착상태이거나, 특별한 변화의 폭이 없다면, 그 정도로 충분한 경우가 된다. 다만, 글로벌 서비스나 웹서비스 등의 지속적인 확장이 필요한 경우라면, 코드리뷰는 필수라고 할 수 있다.코드리뷰가 필요 없는 경우 체크리스트는 다음의 5가지 정도를 체크해보자.1. 특정 도메인만 다루는 팀이나 회사의 개발팀인가?2. 지난 2~3년 정도 솔루션이 크게 변한 것이 없으며, 향후로도 기업이나 팀에서 투자가 없을 예정이다.3. 현재 개발자들이 해당 솔루션에 대한 개발일을 5년 이상하고 있다.4. 기능 위주의 SI성 업무를 주로 처리하고 있으며, 복잡한 알고리즘은 존재하지 않는다.5. 비용과 일정상 개발팀에게 리소스 투여가 불가능하다위의 사례에서 1개 이상이라도 체크된다면, 코드리뷰는 성립하기 힘들다. 대부분 단념하고, TDD나 테스트 케이스를 가능한 많이 축적하여 소프트웨어 품질을 올리기를 권장한다.코드리뷰가 필요한 경우의 체크리스트도 다음의 5가지 정도를 체크해보자.1. 다국어와 시장이 다변화된 환경에서 소프트웨어가 구동되어야 한다.2. 코드의 복잡도가 높으며, 단순 기능 나열의 요구사항이 아니라, 소프트웨어 아키텍처가 별도로 구성되기 시작하였다.3. 사용자의 경험성을 증가하기 위하여 매우 많은 변화가 예측된다.4. 현재 개발 중인 서비스는 중단 없이, 지속적으로 발전되어야 하는 서비스이다.5. 목표 요구사항이 계속 변화하고 있고, 프레임워크를 지향하여 소프트웨어 품질의 요구사항이 매우 중요하다.위의 케이스에서 하나라도 해당이 된다면, 코드리뷰는 매우 효과적으로 소프트웨어에 의미 있는 결과물들을 얻어 내기 위한 좋은 방법이 된다.하지만, 다음과 같은 경우도 같이 고려하여야 한다.코드리뷰의 정도와 질에 대한 검토 리스트의 최소 체크리스트는 다음의 3가지이다. 물론, 이 정의는 조직 내의 아키텍트나 아키텍트 롤을 하는 사람이 결정하는 것이 좋다.1. 실험적인 코드인가?2. 1~2명 이상이 공동으로 작업하는 코드인가?3. 향후 버려질 가능성이 높은 코드인가?코드리뷰를 하지 않는 경우에는 해당 코드의 repository나 디렉터리를 완전하게 분리하고, 리뷰가 안된 코드를 명쾌하게 구분할 수 있어야 한다. 그리고, 그 정보는 팀 전체에게 공개되어야 한다.가장 첫 번째는 코딩규칙 가이드라인의 준수 여부를 체크하는 것이다.개발자들 간의 상호 중요한 것은 스타일 가이드이다. 하지만, 정말 지키기 어려운 것 또한 스타일 가이드라고 할 수 있다. 하지만, 스타일 가이드는 가능한 준수해야 한다. 하지만, 100% 준수하려는 것은 매우 비효율적인 상황을 만들 수 있다. 하지만, 이 경우에 최소한 리뷰어가 제시하는 기준이나 변경 방향에는 대부분 수긍하는 것이 가장 현명하며, 이 부분은 해당 팀의 가장 경험이 풍부한 사람이 리드하는 것이 좋다.그래서, 소프트웨어 개발에는 경험이 풍부한 아키텍트의 역할과 선임의 역할이 가장 중요하다. 소셜에서 이야기하는 가장 중요한 포인트는 이런 경험이 풍부한 선임 개발자가 있다면, 돈이 얼마가 들더라도 ‘개발팀’에 모셔야 한다! 가 정답일 것이다.아직까지 이 부분은 ‘공학’으로 해결할 수 없고, ‘엔지니어링’과 ‘경험’에 의존할  수밖에 없다.주석의 경우에도 ‘가독성’이 충 부한 코드에는 서술할 필요 없다. 이 부분에 대해서는 꾸준한 팀원들 간에 코딩 문화에 대해서  커뮤니케이션하면서 주석의 범위에 대해서 공론화하는 것이 현명하다. 그래서, 소프트웨어 개발은 대부분이 ‘커뮤니케이션’이고 ‘소통’이다. 그래서, ‘팀워크’이 가장 중요한 것이고. 변수의 명칭에 대해서도 ‘명확’하다는 선에서 합의해야 한다.테스트가 쉽지 않은 구조는 다른 문제를 야기한다. Junit과 같은 단위 테스트 도구로 손쉽게 정의가 가능한 구조가 아니라면, 변경해야 한다.코드리뷰 후에 분명하고 타당한 지적에도 고집이 세서 변화가 없는 경우에는 한두 번 이야기하고 더 이상 변화가 없다면, 포기하고. 해당 코드를 격리하여 관리하는 것이 현명하다.  팀원들 간에 감정이 상하는 것이 더 위험하다. 사람은 변하지 않는다 감정에 대한 다툼이나 기대를 할 필요가 없다.UI가 중요한 코드는 해당 코드들이 급변할 가능성이 농후하다. 처음부터 공을 들여서 추상화를 실현하지 않으면, 해당 코드 때문에 프로젝트가 심각해질 수 있다. 사용자에게 더 좋은 경험을 전달하려고 하면, UI코드는 계속 변화를 일으킨다.테스트 코드 여부? 로직에 대한 검토, 변수 네이밍 검토와 레이아웃에 대한 것들? 에 대해서는 다음과 같이 판단하고 체크해보자.코드리뷰는 대부분 ‘직관’에 의존한다. 그래서, 정말 어렵고. 경험이 풍부한 사람이 할  수밖에 없다. 다만, 이러한 코드 리뷰 시의 체크리스트 항목을 몇 가지 간단하게 정리할 수 있다. 최소한의 2가지는 꼭 지키자.코드 리뷰 시의 필수 내용 두 가지는 다음과 같다.1. 코드 검토는 1시간 이내에 끝낼 분량으로 검토한다.2. 코드는 200라인 이상을 한 번에 검토하지 마라이 기준이 어겨지면, 리뷰어는 제대로 된 리뷰를 하기 어려울 것이다.  그리고, 이러한 리뷰를 하는 동안 기능에 대한 검토 체크사항에 대해서 나열해 보면 다음과 같이 나열이 될 수 있을 것이다.1. 시스템의 요구사항이 제대로 반영되었는가?2. 시스템의 설계의 규격대로 구현되었는가?3. 과도한 코딩을 하고 있지 않는가?4. 같은 기능 구현을 더 단순하게 할 수 있는가?5. 함수의 입출력 값은 명확한가?6. 빌딩 블록들( 알고리즘, 자료구조, 데이터 타입, 템플릿, 라이브러리, API )등이 적절하게 사용되었는가?7. 좋은 패턴과 추상화( 상태도, 모듈화 )등을 사용해서 구현하고 있는가?8. 의존도가 높은 함수나 라이브러리 등의 의존관계에 대해서 별도 기술하고 있는가?9. 함수의 반환(exit)은 한 곳에서 이루어지고 있는가?10. 모든 변수는 사용 전에 초기화하고 있는가?11. 사용하지 않는 변수가 있는가?12. 하나의 함수는 하나의 기능만 수행하고 있는가?또한, 스타일과 코딩 가이드에 대해서고 검토하고 리딩을 해야 한다.1. 코딩 스타일 가이드를 준수하고 있는가?2. 각 파일의 헤더 정보가 존재하는가?3. 각 함수의 정보를 코드에 대해서 설명하기에 충분한가?4. 주석은 적절하게 기술되어있는가?5. 코드는 잘  구조화되어있는가? ( 가독성, 기능적 측면 )6. 헤더, 함수 정보를 도구로 추출해서 자동으로 문서화할 수 있는 구조인가?7. 변수와 함수의 이름이 일관되게 기술되어 있는가?8. 프로젝트의 가이드를 통한 네이밍 규칙을 준수하고 있는가?9. 숫자의 경우 단위에 대해서 기술하고 있는가?10. 숫자를 직접 서술하지 않고, 상수를 사용하고 있는가?11. 어셈블리 코드를 사용하였다면 이를 대체할 방법은 없는가?12. 수행되지 않는 코드는 없는가?13. 주석 처리된 코드는 삭제가 되었는가? ( 버전 체크가 되었는가? )14. 간결하지만 너무 특이한 코드가 존재하는가?15. 설명을 보거나 작성자에게 물어봐야만 이해가 가능한 코드가 있는가?16. 구현 예정인 기능이 있다면, ToDo주석으로 표시되어 있는가?가장 중요한 아키텍처에 대한 검토를 잊으면  안 된다.1. 함수의 길이는 적당한가? ( 화면을 넘기면  안 된다. )2. 이 코드는 재사용이 가능한가?3. 전역 변수는 최소로 사용하였는가?4. 변수의 범위는 적절하게 선언되었는가?5. 클래스와 함수가 관련된 기능끼리 그룹화가 되었는가? ( 응집도는 어떤가? )6. 관련된 함수들이 흩어져 있지 않는가?7. 중복된 함수나 클래스가 있지 않는가?8. 코드가 이식성을 고려하여 작성되었는가? ( 프로세스의 특성을 받는 변수 타입이 고려되어있는가? )9. 데이터에 맞게 타입이 구체적으로 선언되었는가?10. If/else구분이 2단계 이상 중접되었다면 이를 함수로 더 구분하라11. Switch/case문이 중첩되었다면 이를 더 구분하라12. 리소스에 lock이 있다면, unlock은 반드시 이루어지는가?13. 힙 메모리 할당과 해제는 항상 짝을 이루는가?14. 스택 변수를 반환하고 있는가?15. 외부/공개 라이브러리 사용하였을 경우에 MIT 라이선스를 확인했는가? GPL의 경우에는 관련된 영역에서만 사용해야 한다.16. 블로킹 api호출시에 비동기적인 방식으로 처리하고 있는가?당연하겠지만, 예외처리 관련 체크리스트도 제대로 검토해야 한다.1. 입력 파라미터의 유효 범위는 체크하고 있는가?2. 에러코드와 예외(exception)의 호출 함수는 분명하게 반환되고 있는가?3. 호출 함수가 어려와 예외처리 코드를 가지고 있는가?4. Null포인트와 음수가 처리되는 구조인가?5. 에러코드에 대해서 명쾌하게 선언하고 처리하고 있는가?6. switch문에 default가 존재하고, 예외처리를 하고 있는가?7. 배열 사용시에 index범위를 체크하는가?8. 포인트 사용시에 유요한 범위를 체크하는가?9. Garbage collection을 제대로 하고 있는가?10. 수학계 산시에 overflow, underflow가 발생할 가능성이 있는가?11. 에러 조건이 체크되고 에러 발생 시 로깅 정보를 남기는가?12. 에러 메시지와 에러코드가 에러의 의미를 잘  전달하는가?13. Try/catch 에러 핸들링 사용방법은 적절하게 구현되었는가?요즘 프로그램은 대부분 이벤트성으로 구동되지만, 시간의 흐름에 대한 체크는 프로그램의 뼈대를 이루게 된다. 이 부분에 대해서도 제대로 검토해야 한다.1. 최악의 조건에 대해서 고려하였는가?2. 무한루프와 재귀 함수는 특이사항이 아니라면 없어야 한다.3. 재귀 함수 사용시에 call stack값의 최댓값이 고정되어 있는가?4. 경쟁조건이 존재하는가?5. 스레드는 정상 생성, 정상 동작하는 코드를 가지고 있는가?6. 불필요한 최적화를 통해서 코드 가독성을 희생하였는가?7. 임베디드의 경우에도 최적화가 매우 중요하지 않다면, 가독성을 더 중요하게 해야 한다가장 중요한 검증과 시험에 대해서도 제대로 인지하여야 한다. 그리고, 테스트를 위해서 가능한 최대한 자동화를 하기 위한 방법들을 이용해야 한다.1. 코드는 시험하기 쉽게 작성되었는가?2. 단위 테스트가 쉽게 될 수 있는가?3. 에러 핸들링 코드도 잘  테스트되었는가?4. 컴파일, 링크 체크 시에 경고 메시지도 100% 처리하였는가?5. 경계값, 음수값, 0/1등의 가독성이 떨어지는 코드에 대해서 충분하게 경계하고 있는가?6. 테스트를 위한 fault 조건 재현을 쉽게 할 수 있는가?7. 모든 인터페이스와 모든 예외 조건에 대해서 테스트 코드가 있는가?8. 최악의 조건에서도 리소스 사용은 문제가 없는가?9. 런타임 시의 오류와 로그에 대비한 시스템이 있는가?10. 테스트를 위한 주석 코드가 존재하는가?간혹 등장하는 하드웨어에 대한 테스트도  마찬가지이다. 다음과 같은 기준들을 통해서 검토해야 한다.1. I/O 오퍼레이션 코드에 대한 테스트로 하드웨어가 정상적인 동작을 보장하는가?2. 최소/최대 타이밍 요구사항에 대해서도 하드웨어 인터페이스가 충족하는가?3. 멀티 바이트 하드웨어 레지스터가 read/write오퍼레이션 중에도 값이 바뀌지 않음을 보장하는가?4. 시스템이 잘 정의된 하드웨어 상태로 리셋하는 것을 S/W가 보장하는가?5. 하드웨어의 전압이 떨어지거나 전원이 차단되는 경우에 잘 처리하는가?6. 대기모드 진입 시와 빠져나 올 때에 시스템이 옳게 동작하는가?7. 사용하지 않는 인터럽트 벡터가 에러 핸들러에 연결되어 있는가?8. EEPROM손상(데이터 깨짐)을 막기 위한 메커니즘이 있는가? ( 쓰기 동작 중 powe loss)등구체적으로 코드리뷰를 하고자 한다면, 다음의 코드리뷰에 대한 기법과 적당한 방법을 다음과 같이 설명할 수 있다.이러한 코드 리뷰를 위한 몇 가지 방법들이 알려져 있다. 그것들을 몇 가지 정리하여 보면 다음과 같다. 코드 인스펙션은 가장 정형화된 기법으로 전문화된 코드리뷰팀을 통해서 구분하는 방법이다. 이 방법은 리소스가 풍부하고, 일정에 여유가 있는 경우에만 사용이 가능하다. 대부분 대기업이나 대형 포털에서 구현 가능한 방법이라고 할 수 있다. ( 이런 곳에 있다면 행복해 하자. ~.~ ) 하여간, 비용과 일정 등이 있다면 이 방법이 현명하다. 그리고, 코드리뷰에 대한 품질에 대해서 정량적인 보고와 구성을 만들어 낼 수 있다는 것은 코드 인스팩션의 가장 좋은 장점이다. 이 코드 인스팩션을 하기 위한 롤을 구분하면 다음과 같이 4가지 롤로 구분할 수 있다.1. ModeratorA. 실질적인 매니저로 팀 간의 인터페이스와 리소스, 인프라를 확보하고, 프로세스에 대한 정의와 산출물의 정리를 담당한다.2. ReaderA. 각 산출물을 읽고, 리뷰하고, 방향성을 제시한다. 보통, 지식이 많은 사람이 담당한다.3. Designer/CoderA. Reader의 지시에 따라서 코드를 검증하고 잠재적인 발견 등의 수정 방안을 만든다.4. TesterA. 진행 중인 코드와 권장 수정 코드에 대해서 검증한다.그리고, 코드 인스펙션은 다음과 같은 6단계로 진행된다.1. PlanningA. 계획 수립2. OverviewA. 교육과 역할 정의3. PreparationA. 인터뷰와 필요한 문서 습득, 툴 환경 구축4. Meeting(Inspection)A. 각자의 역할대로 수행5. ReworkA. 보고된 Defect 수정6. Follow-upA. 보고된 Defect가 수정되었는지 확인이러한 절차를 통해서, 코드 인스팩션이 수행되면, 상당히 명쾌한 리뷰가 진행되게 된다. 하지만, 일정과 비용 문제 때문에 이 작업은 대부분의 스타트업에서는 선택하기 어렵다. 그래서 사용하는 방법 중의 하나가 팀 리뷰이다.팀 리뷰는 일정한 계획과 프로세스만 따르는 방법으로, 코드 인스펙션보다는 좀 덜 정형화된 방법으로 진행한다. 보통은 일주일에 한번 정도 팀 리뷰를 수행하거나, 특정 모듈이나 기능이 완료되는 시점을 기준으로 테스트 결과를 가지고 리뷰를 하는 방법을 사용한다.또한, 위험하거나 의견이 필요한 경우에도 팀 리뷰는 유용하다. 일반적인 팀에서 사용하는 방법이다.하지만, 이 역시. ‘리뷰’에 대한 제대로 된 인식이 없다면, 적용하기 어렵다. 그래서, 가끔 사용되는 방법이고, 과거 국내 SI업체들이 주로 사용하던 방법 중의 하나가 ‘웍쓰로’이다.웍 쓰루(Walkthrough)는 단체로 하는 코드 리뷰 기법 중에 비정형적인 방법으로, 발표자가 리뷰의 주제나 시간을 정해서 발표하고 동료들로부터 의견이나 아이디어를 듣는 시간을 가지는 방법으로써 주로 사례에 대한 정보 공유나 아이디어 수집을 위해서 사용하는 방법이다.이 방법은 ‘특정 도메인’에 종속된 코드를 만들거나, 비슷한 SI성 형태의 업무를 수행하는 경우에 적합하다. 그래서, 국내의 SI업체에서는 적극적으로 사용되면 좋겠지만. 이 ‘시간’마저도 부정확하고, 갑을병정의 SI체게에서 ‘정보공유’나 ‘아이디어 수집’과 같은 커뮤니케이션이 자유롭게 일어나는 것은 매우 힘들다.이 웍 쓰루는 동일한 조직 내에서 동일한 목적의식이 분명한 팀에서나 활용이 가능한 방법이다. 웍 쓰루를 SI에서 시도한 경우에는 대부분 실패했거나, 목적의식이 다르기 때문에 불분명한 결론들이 대부분 도출되었다.대부분의 국내 스타트업이나 IT 전문기업들은 ‘리뷰’에 대해서 상급 관리자들이 제대로 허락을 해주지 않는다.대부분은 팀내에서 어떻게든 자체적으로 해보려고 한다. 그래서, 팀장의 권한 선에서 적절하게 리뷰를 하는 방법 중의 하나가 Peer review or over the shoulder review방법이다. 이 방법은 보통 2~3명이 진행하는 코드리 뷰로 코드의 작성자가 모니터를 보면서 코드를 설명하고, 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 Defect를 발견하는 방법이다.또한, 이 방법은 신입사원이나 인턴사원의 경우에 업무 이해도를 높이면서 해당 코드를 사용할 수 있는 수준으로 활용할 경우에 의미 있는 방법이다. 문제는 이 방법은 개발자의 인력 투입이 거의 두배 이상으로 증가하는 것으로써, 고품질의 영역을 개발하거나, 빠른 시간 안에 신입 개발자의 업무 이해도를 높이는 경우가 아니라면 시행하지 않는다.이렇게도 리뷰가 진행이 되지 않으면, Passaroud는 돌려 보기 방법을 사용한다. 이 방법은 원래 상세한 리뷰 방법은 아니다. 온라인이나 실시간성이 아니라, 리파지토리나 이메일 등을 사용하여 천천히 리뷰하는 방식에 해당하는데, 속도는 느리지만, 중요한 코드이거나, 제품의 기능 개선이 필요한 경우에는 아주 의미가 있다. 보통은 제품의 기능 개선을 위하여 사용하는 방법이다.이처럼 리뷰의 방법에는 다양한 방법이 있지만, 결론적으로는 어느 정도 개발 조직이 서로  커뮤니케이션하고, 목적의식을 통일하고, 적절한 시간 분배를 통해서 리뷰를 할 수 있는 시간을 만들어 내느냐가 리뷰의 핵심이라고 할 수 있다.리뷰를 통해서 소프트웨어의 품질을  끌어올리고, 개발자들과 소통하고, 방향성을 만들어 내며, 새로운 기능 개선 작업을 위해서 리뷰는 다양하게 활용된다. 어떤 관점으로 리뷰를 할 것이고, 어떤 관점으로 리뷰라는 프로세스를 개발 프로세스에 탑재할 것인가에 대해서 진지하게 고민하는 것. 그것이 아키텍트의 첫 번째 역할 아닌가 한다.

지난 1월 말, 새해를 맞아 잔디에 새로운 기능이 업데이트되었습니다. 바로 잔디 커넥트에 관한 내용인데요, 협업에서 많이 쓰이는 몇 가지 외부 서비스를 잔디와 쉽게 연동해서 더욱 효율적인 업무 커뮤니케이션을 할 수 있게 되었습니다. 많은 고객분들이 이번 업데이트를 기다려주신 만큼, 저희 개발팀 또한 기대에 보답하고자 지난 몇 주의 스프린트 동안 열심히 준비했습니다. 이번 글에서는 커넥트 동작 방식을 설명하고 그 개발 과정에서 저희가 겪은 시행착오를 비롯한 여러 값진 경험들을 공유하고자 합니다.Integration? Webhook!연동: [기계] 기계나 장치 따위에서, 한 부분이 움직이면 다른 부분도 함께 잇따라 움직임.앞서 말한 대로 잔디 커넥트는 여러 웹 서비스들과 잔디를 연동할 수 있는 기능입니다. 서로 다른 웹 서비스를 연동하기 위해선 한 서비스 내에서 특정 이벤트가 발생 했을 때 다른 서비스로 해당 이벤트를 알려주는 연결 고리가 필요합니다. 이때 해당 연결 고리 역할을 위해 대표적으로 사용되는 기법이 웹훅(WebHook) 입니다. 웹훅은 user-defined HTTP callbacks, reverse APIs 등으로 불리는데, 간단히 설명하자면 웹 서비스에서 공개한 API가 아닌 사용자가 직접 지정한 주소(URL)로 특정 이벤트가 발생 시 HTTP Request를 보내주는 기법입니다. 예를 들어,새로운 일정이 등록된 경우(Google Calender)요청한 Pull Request가 Merge된 경우(GitHub)카드에 새로운 코멘트가 작성된 경우(Trello)이러한 이벤트가 발생했을 때 사용자가 매번 이벤트가 발생했는지 확인하지 않아도 서비스가 먼저 알려줄 수 있도록 일종의 알림을 등록하는 것이죠. 잔디 커넥트는 이와 같은 특징을 이용해서 각각의 웹 서비스에서 제공하는 웹훅을 잔디의 메시지 형태로 전달하는 기능입니다.일반적으로 웹훅은 이벤트에 대한 알림을 외부로 전달하는 것을 말합니다. 이 부분에서 중요한 것은 전달 방향인데, 서비스 내부에서 외부로 전달하기 때문에 이를 Outgoing Webhook으로 부르기도 합니다1. 같은 맥락에서 반대로 생각해보면 외부에서 서비스 내부로 특정 데이터를 전달하는 경우이니 Incoming Webhook이 됩니다. 앞서 웹훅을 reverse API라고 했는데 이를 다시 뒤집으니 결국 서비스 내부로 통신하는 제한적인 API와 같은 역할을 합니다. 굳이 용어를 구분한 이유는 API와 달리 접근하려는 서비스의 별도 인증 절차를 거치지 않고도 사용자가 생성한 웹훅의 URL을 인증 토큰으로 사용하며 약속된 Request Body 포맷만 알고 있다면 자유롭게 사용할 수 있기 때문입니다.개념 설명이 다소 길어졌지만, 이번 잔디 커넥트 기능에 대해 용어나 개념이 낯설다는 피드백이 생각보다 많았기 때문에 이번 글을 통해 더 많은 분들이 웹훅을 이해하는 데 도움이 될 수 있으면 좋겠습니다.구현에 앞서서비스를 운영한지 1년 정도 지난 시점에서 저희 내부적으로는 백엔드의 기술 스택 변경 및 각 서비스 분리에 대한 갈증이 있었습니다. 하지만 이미 서비스를 운영 중이기 때문에 안정성이 최우선시 되는 만큼 꽤 부담스러운 숙제로 미뤄둘 수밖에 없었고요. 때마침 커넥트 기능은 숙제를 시험해볼 만한 좋은 기회임에는 분명했지만, 새로운 기술 스택을 바로 서비스에 적용하기엔 오히려 개발 효율이 떨어질 것이라는 판단하에 일단 서비스 분리에만 집중하기로 했습니다.기본적으로 API와 DB를 기존 서버와 분리하고 웹훅 데이터를 저장하기 위한 큐와 해당 데이터를 처리하는 배치 서버 또한 모두 기존 서비스와 분리해서 최대한 결합도를 제거했습니다. 이런 설계 덕분에 추후 사업 전략이나 각 국가의 특성에 맞춰 커넥트 기능을 어렵지 않게 포함하거나 제외할 수 있게 되었습니다. 전반적인 저희 잔디 백엔드 아키텍쳐에 대해서는 아직 한 번도 소개 해드린 적이 없으니 다음에 따로 주제로 선정해 집중적으로 다뤄보도록 하겠습니다.동작 방식잔디 커넥트가 동작하는 방식은 기본적으로 다음과 같습니다.Incoming Webhook URL 생성 - 외부 서비스 웹훅 등록 - 웹훅 수신 - 메시지 작성 연동 대상 서비스마다 조금씩 차이가 있지만, 기본적으로 모두 위와 같은 방식으로 동작하기 때문에 단계마다 나누어 설명하겠습니다.1. Webhook URL 생성Webhook URL은 https://wh.jandi.com/connect-api/webhook/{teamId}/{webhook-token}와 같은 형태로 생성됩니다. hostname을 별도로 설정함으로써 기존 API 서버와의 분리는 물론이고, nginx의 Limiting the Request Rate 설정을 이용해서 호출되는 웹훅 요청 수를 효과적으로 제한할 수 있었습니다. webhook-token은 중복을 피하면서 각 웹훅에 대한 유효성을 검증할 수 있도록 여러 키를 조합한 md5 hash 값을 이용했습니다.이렇게 생성된 URL은 Incoming Webhook 뿐만 아니라 Google Calendar 등의 서비스에 등록하는 콜백 URL로 사용합니다.2. 외부 서비스 웹훅 등록웹훅을 등록하는 방법은 서비스에 따라 API를 이용하거나 수동으로 직접 등록할 수 있습니다. 사용자가 직접 웹훅을 등록하는 방법은 웹훅 URL만 생성해서 전달하면 등록 과정의 추가 처리가 필요 없어서 간단하지만, 서비스마다 등록하는 방법이 조금씩 다르고 다소 복잡하게 느껴지는 문제가 있습니다. 반대로 각 서비스에서 제공하는 API를 이용해 웹훅을 등록하면 사용자의 부담을 많이 줄일 수 있지만, 그만큼 내부적으로 처리해야 할 작업이 많아집니다. 그래서 구현 초기에 꽤 많은 시간을 투자할 수밖에 없었고 그 과정에서 아래와 같은 어려움을 겪었습니다.웹훅 관련 API를 사용하려면 먼저 인증을 받아야 하는데 서비스마다 제공하는 인증 방식이 조금씩 달라서 이를 통합하는 모델을 만들기가 쉽지 않았습니다. 요약하자면 기본적으로 accessToken을 사용하지만, 인증 방식에 따라 부가적으로 필요한 데이터가 서로 조금씩 다른것이죠. 가령, 구글캘린더는 만료 일시와 토큰 갱신을 위한 refreshToken 값을 별도로 갖고 있어야 합니다. 또 한가지 놓치기 쉬운 부분은 인증 폐기(revoked) 관련한 데이터 처리인데 저희가 경험한 바로는 인증이 폐기되었을 때 별도로 웹훅 알림을 주지 않기 때문에 반드시 인증의 유효성을 확인하는 추가 로직이 필요합니다.대부분의 사무실이 그렇듯이 저희 또한 공유기를 이용해 내부 네트워크를 구성하고 있습니다. 게다가 백엔드 파트는 개개인의 로컬 가상 서버에 동일한 환경을 설정해놓고 개발을 하므로2보통 경우엔 외부(public network)에서 들어오는 요청을 받을 수 없습니다. 그렇다고 매번 외부 네트워크에 있는 서버에 배포 후 테스트하기가 어려우니, 저희는 각 로컬 서버마다 고유 포트 번호를 나눠 갖고 WAN이 물린 공유기의 포트 포워딩을 알맞게 설정한 뒤에 네트워크 터널링 유틸리티인 ngrok을 이용해 내부와 연결되는 public 주소를 생성해서 외부 서비스와 문제없이 통신할 수 있었습니다.3. 웹훅 수신웹훅을 통해 들어오는 Request는 일단 정상 응답을 하는 게 좋습니다. 서비스마다 최초 웹훅 등록 시 유효한 URL인지 확인하는 테스트 요청을 하는데 이때 정상 응답을 하지 못하면 아예 등록조차 처리되지 않습니다. 또한, 정상적으로 등록된 이후 특정 이벤트에 해당하는 웹훅 요청에 대한 응답에도 주의할 필요가 있는데, 만약 에러 응답이 반복되면 일정 시간 동안 각 서비스에서 아예 해당 웹훅을 발송하지 않도록 제한이 걸려 더 이상 테스트를 진행할 수 없는 경우도 있었습니다.따라서 일단 웹훅 요청이 들어오면 teamId와 webhook-token 값으로 올바른 웹훅인지 검증한 후 서비스별 큐에 Request header와 body를 포함한 데이터를 전달한 뒤 바로 응답하고, 큐에 쌓인 데이터는 커넥트 종류별로 배치 서버가 돌면서 처리하게 됩니다. SQS를 사용함으로써 늘어나는 데이터에 대한 안정성을 확보하고 각각의 배치 서버를 독립적으로 분리해서 구현함으로써 자연스레 확장성(scalability)도 보장할 수 있게 되었습니다.4. 메시지 작성웹훅 데이터를 잔디의 메시지로 변환하는 역할은 배치 서버가 담당합니다. 서비스별로 데이터 포맷이 다르므로 해당 데이터를 파싱 및 처리하는 Worker 또한 각각 구현했습니다. 사실 커넥트 기능에서 가장 핵심적인 역할을 하는 부분인 만큼 가장 많은 공수가 드는 작업이였던 것 같습니다.서비스마다 정해놓은 웹훅 이벤트와 잔디 커넥트에서 제공하고자 하는 알림이 서로 완전히 일치하지 않아서 이를 서로 연결하는 작업연동 서비스의 문서가 잘 정리되어 있지 않아서 일일이 필요한 동작을 취하고 그에 따라 들어오는 데이터를 정리하는 작업잔디 계정 언어에 따라 메시지 L10N3을 적용하는 작업커넥트 메시지를 전달하기 위해 기존 멤버와 다른 커넥트 봇을 구현하는 작업등 요약하기 어려울 정도로 크고 작은 이슈들이 많았습니다. 그 내용이 너무 다양해서 모두 상세히 기록하긴 어렵지만, 개중에 도움이 될만한 내용을 추려서 아래 따로 정리했으니 관심 있으신 분들은 참고하시면 좋을 것 같습니다.서비스별 집중 탐구커넥트 구현 일정을 최대한 앞당기기 위해 저희는 개발자들끼리 각각의 커넥트 종류 별로 전담해서 작업하는 전략을 취했습니다. 제가 대표로 글을 작성하기는 하지만 보다 정확하고 구체적인 정보를 전달하는 것이 좋겠다는 생각에 개발을 담당하신 분들과의 짧은 인터뷰 형식을 빌려 공유하겠습니다.- Google CalendarQ. 기술적으로 난이도가 높았던 작업을 소개해달라.전반적으로 어려운 작업이 있었다기보단, 캘린더 특성상 세세하게 처리할 부분들이 많아 설계와 구현이 어쩔 수 없이 복잡해졌다. 가장 골치 아팠던 작업은 일정 알림을 타임존(Time Zone)에 따라 각각 알맞은 시간에 전달하는 작업인데, “잔디 계정의 타임존”, “구글 캘린더의 타임존”, “개별 일정의 타임존” 이렇게 3가지를 모두 고려해서 경우마다 기준이 되는 타임존을 결정하는게 엄청 까다로웠다. 심지어 구현 후 테스트를 하는 과정에서도 출력된 시간이 올바로 표시된 것인지조차 헷갈려서 디버깅하는데 한참 고생할 수 밖에 없었다.웹훅을 등록하고 관리하는 부분도 꽤 복잡했는데, 구글 답게(?) 웹훅에도 만료 기간이 존재한다는 것이 포인트다. 때문에 만료되기 전에 반드시 재등록 및 과거 웹훅 삭제 작업을 하는데, 효과적으로 처리하기 위해 “웹훅을 받을 때마다 만료 기간을 확인”, “등록된 일정이 많지 않아 웹훅을 받지 못하는 경우도 있으니 별도의 배치서버가 하루 단위로 확인” 이렇게 두 가지 로직을 넣어서 자동으로 웹훅을 유지하도록 구현했다.또한, 다른 연동 서비스와 달리 구글은 웹훅 콜백으로 들어오는 요청에 해당 이벤트에 대한 데이터를 직접 담아주지 않기 때문에 key를 가지고 한 번 더 API 호출을 통해 필요한 데이터를 가져와야 한다는 점도 주의해야 한다. 요청해야 할 API 문서는 비교적 잘 정리된 편이지만, 같은 요청에 대해서도 인자를 어떻게 보내는지에 따라 그 응답이 제각각이기 때문에 응답 값에 대해 무조건 신뢰하고 처리해서는 안 된다. 당연히 존재할 것으로 생각한 필드 값에 빈 배열이 들어와서 일정 관련된 데이터를 일부 날리고 나서야 깨달았다.. -_-Q. 가장 처리해야 할 이슈가 많았다고 알고 있는데, 그중에서도 기억에 남는 이슈가 있을 것 같다.너무 많은 이슈를 동시에 처리하다 보니 특별히 기억에 남는 이슈는 없다. 다만 아직도 왜 그랬는지 확실한 이유는 알 수 없지만, 언젠가 한 번 구글에서 웹훅을 아예 전달해주지 않았던 경우가 있었다. 과도한 요청으로 limit이 걸린 것도 아니었는데, 갑자기 웹훅이 안들어오니깐 우리로서는 어떻게 풀어볼 방법이 없었다. 그러다 나중에 확인해보니 대략 12시간쯤 지나고 나서 그동안 밀려있던 웹훅 데이터가 한 번에 밀려서 들어와 있더라. 다행히 그 이후로 지금까지 한 번도 재현되지 않는걸 보니, 혹 동일한 증상을 겪는다면 당황하지 말고 기다려 보시라.반복 일정을 다루는 것도 꽤 골치 아픈 이슈인데, 왜냐하면 일정이 있을 때 마다 웹훅 알림을 주지 않고 처음 등록된 시점에서 한 번만 정보를 알려주기 때문에 등록된 시점 이후의 일정은 내부적으로 계속 등록해줘야 한다. 기본적으로 구글 캘린더는 RFC-55454 표준을 따르지만, 실제 전달되는 데이터 중 일부는 표준과 조금 다른 부분이 있었다. 특히 반복 일정(recurrence) 관련 데이터 포맷이 조금 다르므로 캘린더 데이터를 파싱하기 위해 만약 외부 library를 사용한다면 별도의 예외처리가 필요하다. 더욱 더 까다로운 건 사실 등록된 반복 일정이 수정되거나 삭제되는 경우인데, 이때 “특정 일정만 삭제”, “지금 시점 이후의 일정 모두 수정” 등 워낙 케이스도 많고 각각을 테스트 하는 것도 쉽지 않기 때문에 작업 시간이 꽤 오래 걸렸다. (심지어 아직 확인하지 못한 드문 케이스에서는 잠재된 버그가 있을 수도…)Q. 그 밖의 도움이 될만한 노하우나 꿀팁이 있다면?구글 캘린더 API는 Webhook 보단 Push Notification 키워드를 많이 사용한다. 푸시 노티라는 게 좀 다른 카테고리에서 많이 쓰이는 용어이기도 하다 보니 코드 리뷰 등의 커뮤니케이션을 할 때 혼동이 좀 있었던 것 같다.물론 서비스 요구사항마다 다르겠지만, 잔디 같은 경우엔 요구사항에 맞춰 계속 설계를 변경 및 개선하다 보니 결과적으로 너무 복잡해져 효율이 떨어지는 코드를 작성할 수밖에 없었다. 처음부터 연동을 생각하기보다는 아예 캘린더 자체 기능을 베이스로 설계하고 데이터만 구글에서 가져온다 생각했다면 개발 생산성이 더욱 좋았을 것 같다.- TrelloQ. 기능을 구현하면서 느낀 아쉬웠던 점과 좋았던 점을 짚어달라.트렐로 공식 API 문서가 더 명확했다면 좀 더 개발이 수월했을 것이다. 문서가 RESTful하게 end-point path는 간결하게 잘 정돈되어 있지만, 각 요청 parameter에 대한 설명이나 response 데이터 등이 명확하게 정리되지 않아서 적합한 API를 찾거나 불명확함을 걷어내기 위한 테스트를 하다 보니 전반적으로 시간이 길어지고 비효율적이었던것 같다.그에 반해 트렐로에서 웹훅 이벤트를 발생시키기 위한 유저 액션들이 비교적 간단하고, 그에 따른 콜백 리퀘스트 또한 누락 없이 빠르게 잘 들어와서 그나마 쉽게 테스트를 할 수 있었다.Q. 기능 구현을 위해선 반드시 알아야 할 웹훅 이벤트 종류 및 데이터에 대한 문서는 정리가 전혀 안 되어있다고 하던데 정말인가?그렇다. 처음엔 좀 당황했지만, 그래도 방법이 없으니 일일이 경우마다 테스트해보면서 직접 정리를 하려고 했다. 하지만 각 웹훅마다 큰 구분만 있고 세세한 데이터는 너무 다양해서 깔끔하게 정리하기가 어려워 따로 공유를 위한 문서를 만들지는 못했다. 예를 들자면 트렐로에서 updateCard 라는 action type의 웹훅 데이터를 보내주는데, 그 데이터만 보고 “Card Archive”, “Description 수정/삭제”, “Due date 등록/수정”, “카드 이동” 등의 여러 가지 서로 다른 이벤트를 구분해야 한다. 근데 그 구분하는 방법이 특정 flag가 있는 게 아니라서 각 data를 모아놓고 역으로 분리하다 보니 코드를 깔끔하게 작성하기가 어려움은 물론, 추후 트렐로 측 데이터의 변동이 있을 때의 품질을 보장할 수 없는 리스크를 안고 구현할 수밖에 없었다.Q. 그 밖의 도움이 될만한 노하우나 꿀팁이 있다면?만약 트렐로와 어떤 형태로든 연동하려고 한다면, 설계 전에 모든 API에 대해 꼼꼼히 살펴보고 웹훅 이벤트 또한 직접 테스트해서 일단 전체적으로 리스트업을 정리하는 게 보다 생산성에 도움이 될 것이다. 트렐로를 잘 알고 있더라도 서비스 내부에서 “보드”, “리스트”, “카드”가 어떤 상관관계를 가지는지 미리 정리해보는 것도 좋다.사소하지만 좀 특이했던 점은 웹훅을 처음 등록할 때 해당 URL로 확인 요청을 한번 하는데, 이때 요청은 HTTP method가 POST가 아닌 HEAD로 들어온다. 그래서 반드시 동일한 URL의 HEAD 요청에 대해서도 정상 응답을 할 수 있도록 구현해야 한다.마무리잔디 커넥트를 구현하면서 특히 서비스 품질과 개발 속도 간의 밸런스에 대한 고민을 많이 했습니다. 초반에 서비스 종류별로 작업을 분리하고 각각의 방식으로 설계한 뒤 나중에 정리하는 전략이다 보니 공통으로 가져갈 수 있는 DB 모델이나 서비스 로직이 많아서 이를 통합하기 위해 반복 작업을 할 수밖에 없었는데 이 부분이 저희 내부적으로 느낀 가장 아쉬운 부분이 아니었나 생각합니다. 기능 중 많은 부분이 외부 서비스에 의존적이다 보니 생각하지도 못한 크고 작은 이슈들이 발생해서 일정 산출에도 꽤 어려움을 겪었습니다.커넥트 기능을 출시한 이후로 꽤 시간이 지났음에도 불구하고 이슈 백로그(Backlog)를 보니 아직도 개선할 부분이 많이 남아있는 듯 합니다. 그렇지만 이번에 기반이 되는 작업을 최대한 튼튼히 하기 위한 많은 시행착오를 거쳤기에, 추후 연동되는 커넥트 종류를 늘려나가는 시점5에 보다 효과적으로 개발할 수 있을 것이라 기대하면서 이번 글을 마치겠습니다.Slack API 문서 참고 ↩vagrant의 box로 서로의 로컬 개발 환경을 동일하게 유지하고 있습니다. 참고로, 현재 저희 서버 환경은 Local - Dev - Staging - Production으로 구성되어 단계별로 상황에 알맞게 배포하고 있습니다. ↩Localization의 약어. 잔디는 아시아 시장에 최적화된 서비스를 제공하고자 한국어, 일본어, 중국어 간체자(중국), 번체자(대만/홍콩), 영어 총 5가지 언어를 지원합니다. ↩아이캘린더(iCalendar)로 불리는 인터넷 캘린더의 데이터 포맷에 관한 표준. IETF 문서참고 ↩구체적인 시점은 말씀드리기 어렵지만, 더욱 좋은 사용성을 제공하고자 유저분들의 설문조사를 진행하고 있으니 많은 참여 부탁드립니다. ↩#토스랩 #잔디 #JANDI #개발후기 #일지 #인사이트

전기 공무와 전문건설 공무 합 1년 경력의 커뮤케이션 능력자 안병섭입니다. 언론사 2년 6개월 스크랩 업무 부터 사무보조 및 기타 업무kb카드 도급사 7년 재직 각종 스캔업무와 서버 등록 및 각종 간단한 공사업무엔텍월드 3개월 재직, 하도급 신고, 현장관리, 출역현황표 작성, 내역서 작성 견적 등한신안전산업 2018년 11월~현재 재직중 기성, 퇴직공제작성과 신고 키스콘 등록 및 원, 하도급 관리 및 기성 검토와 실적신고작성 물량 산출 등

오늘은 성공이 아니라 실패에 대한 이야기를 해볼까 합니다.제가 개발팀을 채용하면서 새로 인터뷰 보는 사람에 대해 내세웠던 세 가지 원칙이 있습니다.1. 현재 우리 팀원들과 잘 어울릴 수 있는지?2. 현재 우리 회사와 잘 어울릴 수 있는지?3. 현재 우리 회사의 다른 팀원들과 잘 어울릴 수 있는지? 결론부터 이야기하자면 이 세 가지 원칙들이 완전히 틀린 것은 아니지만 조금은 틀렸습니다. 여기서 "어울릴 수 있는지"라는 말은 새로운 사람이 우리 팀원들의 생각과 비슷하냐는 것입니다. 물론 생각이라는 단어가 많은 의미를 포함하고 있지만 여기서는 "부딪히지 않고 함께 일할 수 있는가?"를 중점적으로 보았습니다. 그러나 한 기업의 CEO를 보고 나서 "부딪히지 않는다"라는 생각이 얼마나 위험한 것인지 2년 만에 깨닫게 되었습니다. 얼마 전까지 정말 흥미롭게 읽던 책이 있었습니다. 애덤 그랜트의 [오리지널스]라는 책인데요. 여러 회사의 사례에서 우리와 같은 일반 사람들이 천재적으로 직무를 수행했거나, 처참하게 실패했거나, 위기상황을 모면해 나가는 것을 설명해놓은 책입니다. 애덤 그랜트는 조직이 더욱 효과적으로 성장하려면 여러 부류의 사람들이 모여야 한다고 설명합니다. 다양한 사람들이 다양한 사고를 하고 다양한 행동들을 할 때 다양한 아이디어가 나오고 그 아이디어들이 부딪히면서 엄청난 결과가 도출될 수 있다고 말하고 있죠. 위에서 언급한 한 기업의 CEO는 애덤 그랜트와 정확히 반대의 생각을 했습니다. 물론 저도 일부분 마찬가지였고요.나의 비전을 함께 할 수 있는 사람들로 회사를 채워야 한다 표면적으로 보면 틀린 말이 없어요. 나의 비전을 실행시키려면 비전을 함께해야 하죠. 그런데 여기서 비전의 의미가 정말 중요합니다. 이 CEO는 자신의 생각과 똑같이 생각하는 사람 = 비전을 공유하는 사람이라고 생각하는 오류를 범했어요. 그래서 그 CEO는 자신의 생각에 반대하는 사람을 모두 멀리했습니다. 자신의 생각과 반하는 사람들을 감정적으로 무시하거나 미팅을 하지도 않았고 심지어 회사에서 쫓아내기까지 했어요. 어느새 그의 옆에 있는 팀원들은 모두 들어온 지 세 달이 채 안된 사람들로 가득 차 있었지요. 그의 팀원들은 CEO의 생각을 반대하지도 않았고 그의 의도에 대해 묻지도 따지지도 않았으며 묵묵히 그가 말하는 대로 움직일 뿐이었습니다.폴라로이드 카메라를 들고있는 에드윈 랜드 오리지널스에서는 폴라로이드 카메라를 발명하여 폴라로이드사를 폭발적으로 성장시킨 에드윈 랜드의 이야기를 예로 들고 있습니다. 랜드는 즉석 필름 카메라 폴라로이드 카메라를 발명할 당시에는 기술보다는 자신의 비전을 공유하는 사람들로 채워 열정적이고 헌신적으로 일할 팀을 꾸렸습니다. 그러나 이후의 개발 과정에서 그는 엄청난 돈을 쓰게 되고 회사의 이사진들은 그의 개발을 반대하였지만 그는 들은 척도 하지 않고 그의 추종자들과 계속해서 개발을 했다고 합니다. 랜드는 개발실을 다른 공간에 따로 마련하고 자신의 생각과 반대하는 사람들의 출입까지 통제했다고 해요. 그렇게 그는 자신만의 왕국을 건설하려고 하였고 실패하였습니다. 애덤 그랜트는 에드윈 랜드의 사례를 들어 집단사고의 위험성을 경고하고 있습니다. 그랜트는 오리지널스의 결론에서 사람을 뽑을 때는 "조직문화에 기여할 수 있는 사람을 뽑아라"라고 충고하고 있습니다. 조직문화에 기여할 수 있는 사람이란 현재 있는 조직문화에 자연스레 순응하거나 안 좋은 점을 발견하고 부딪혀서 바꿀만한 용기와 실행력이 있는 사람을 이야기합니다. 조직이 발전하려면 해당 조직의 문제점을 발견해주는 사람이 필요한데 그런 사람은 보통 조직이 현재 가지고 있는 사람들과 다른 성향의 사람들이 더 발견할 가능성이 높다는 게 그의 주장입니다. 이 글을 쓰면서 여러 가지 생각이 들었고 저를 반성하는 계기가 되었습니다. 저도 한번 더 우리 팀을 멀리서 보고 더 잘 될 수 있는 방안이 무엇이 있을지 고민해보았습니다. 문득 떠오르는 생각이 지금 있는 사람들이 모두 바보들은 아닐 텐데라는 생각이 들었어요. 왜 그들이 새로운 시도를 하지 않는지 CEO의 말에 복종할 수밖에 없는지를 생각해보았습니다.새로운 시도를 하지 않는 팀원 그들은 왜 CEO의 생각에 반대를 하지 않는 것일까. 어떤 생각에 반대한다는 것은 위험을 무릅쓰는 일입니다. 자신의 생각이 100% 맞다고 할 수도 없으니까 미래에 자신의 생각이 틀렸을 경우에 비난을 받는 것을 두려워하는 것일 테지요. 만약 자신이 주장한 아이디어가 실패하면 CEO로부터 엄청난 욕을 먹을지도 모르는 게 두려워서입니다. 실패를 용납하지 않는 문화가 우리를 겁쟁이로 만들었고 우리는 더 이상 입 열기를 거부한 것이지요. 로마에선 로마법을 따르고 절이 싫으면 중이 떠나라라는 논리를 너무나도 잘 지키게 되었습니다. 과연 회사를 위해, 우리를 위해 입을 닫는 그 선택이 맞는 걸까요? 그냥 가만히 있으면 우리는 발전할 수 있을까요? 아닐 거라고 확신합니다. 팀원들의 입을 열기 위해선 리더의 역할이 중요합니다. 왜냐하면 조직 문화를 만드는 것은 리더의 행동으로부터 시작되기 때문이지요. 사이먼 사이넥의 "리더는 마지막에 먹는다" TED 강연에서 사이넥은 이렇게 말합니다. 전쟁터에서 이등병들이 부사관들을 위해 기꺼이 희생하는 것을 보고 그들에게 "왜 이렇게까지 합니까? 왜 피와 땀과 눈물을 저 사람을 위해 바칩니까?"라고 물어보았습니다. 그러자 너나 할 것 없이 그들은 이렇게 대답했답니다.왜냐하면 그들도 우리를 위해 이렇게 할 테니까요 실패를 두려워하지 않는 팀원들은 한 번은 실패할 수도 있습니다. 두 번 실패할 수도 세 번 실패할지도 모르지요. 그러나 그들은 실패로부터 많은 교훈을 얻고 실패하지 않을 계획을 세우고 더 크게 성공할 발판을 마련합니다. 리더에게 비난받기를 두려워하지 않는 부하직원은 미팅에서 엉뚱한 의견을 낼지도 모릅니다. 그러나 그 엉뚱한 의견들에서 창의적인 아이디어가 나올 가능성이 높아지지요. 그런 분위기를 만드는 것은 리더이며 다양한 팀원들은 그런 분위기에서 양질의 아이디어를 낼 수 있습니다. 리더는 집단사고를 예방하기 위해 다양한 생각들을 수용해야 하며 - 특히 애덤 그랜트는 "악마의 변호인 Devil's Advocate"(반대 역할 전담)을 배치하라고 추천합니다 - 다양한 생각들을 내는 조직을 만들기 위해서 다양한 사람들과 함께 일해야 할 것입니다.경영자로서 나의 일은 실패를 끌어안는 문화를 이어가는 것이다. 아예 실패할 작정을 하고 실험을 해야 한다.성공을 목표로 하면 거기서 멈춰버린다. 그러나 실패를 목표로 하면 실패할 때까지 끊임없는 혁신과 변혁이 일어난다. 오히려 지루하게(boring) 성공한 직원들이 회사에 불필요한 존재이다.- 제프 베조스, 아마존 CEO실패와 혁신은 쌍둥이입니다. 이것이 우리가 1000억 달러(약 109조 원)의 매출을 내면서도 끊임없이 실패에 도전하는 이유입니다.그래서 나는 아마존을 가장 성공한 회사보다도 가장 편하게 실패할 수 있는 회사로 만들고자 합니다.- 제프 베조스, 아마존 CEO, 2016. 4. 9, 주주들에게 보낸 연례서한 중 다양한 성향의 팀원들은 나와 생각이 다르고 실패할 수 있습니다. 그들이 실패했을 때 "그러게 내 말대로 하지 그랬어!"라고 윽박지르기보다는 "어떻게 하면 다음에 더 잘할 수 있을까?"라고 말을 건네어 보는 것은 어떨까요?#비주얼캠프 #인사이트 #경험공유 #조언

결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.소프트웨어 개발에서 '급한 일'이란 없다.정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.지금 이상황에도...'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...끄적끄적...

진저티프로젝트는 세상을 변화시키는 사람들을 주목하고, 그들의 비전을 함께 꿈꾸고, 탁월한 조직으로 성장하도록 함께 고민하여 비영리섹터의 실제적변화를 돕는 공익프로젝트 컨설팅 전문회사입니다.진저티프로젝트는 비영리섹터의 건강한 성장과 탁월한 성과를 위한 구체적이고 실행가능한 변화를 지원합니다.우리는 NPO의 사회적 영향력이 건강하게 사회적으로 확산될 수 있기를 바랍니다.▶ 가치: 공감, 존중, 에너지, 열정적인사람, 확산적사고, 본질에 집중, 측정가능한 변화▶ 목적:Bring Real Change: 믿을 수 있는 변화(Change We can Believe)를 가져오는 서비스를 비영리, 자선사업의 모금, 커뮤니케이션, 경영, 교육 영역에 제공합니다.Connect NPO Professionals: 비영리컨설팅/경영전문성을 대내외적으로 구축합니다. 내적으로는 외부자극에 유연한 학습조직으로 운영, 외적으로는 비영리경영전문가 집단의 지원 네트워크 구축합니다.Appreciate Efficient/ Respected Work Environment: 비영리섹터의 효율적, 개방적 자원의 운영을 추구하며, 구성원의 라이프싸이클과 상황이 고려되는 업무환경/커리어패스를 추구합니다. ▶ 서비스: A. 비영리단체 서포트 프로젝트BIC Project 를 활용한 비영리단체 자가진단, 이슈파악, 솔루션 도출 (2일, 단체방문 1회): 주기적 BIC 멘토링 진행 (교육, 자가진단, 이슈파악), 단체 방문(모니터링, 문제해결), 온/오프라인을 통한 지속적 어드바이스 제공, 전문가 연계조직 전반/장기 컨설팅 (BIC Project 모듈 활용, 전문가집단과 협업, 6-12개월): 단체의 총체적/근본적 경영/관리 문제 해결 (6-12개월)슈별/소규모/단기 컨설팅 (BIC Project 모듈 필요 영역별 활용, 1-3개월): 모금솔루션 (모금스터디) 매니지먼스 솔류션 (투명성, 리더쉽, 자원관리, 시스템, 프로젝트)위탁운영서비스 (BIC Project 모듈 활용, 전문가집단과 협업, 1-2년): 비영리단체 운영을 위탁위임 받아 총체적 근본적/경영관리 문제 해결B. 비영리 연구/출판 프로젝트자선/비영리 사업의 기반이 되는 기초 조사 (현황파악, 욕구조사)자선/비영리 조직/역량강화를 위한 출판 사업C. 기업/기업재단 사회공헌 프로젝트기금사업관리 (기획, 운영, 평가)사회공헌프로젝트 (교육, 워크샵, 프로그램)스타트업 컨설팅 (사회적기업, 소셜벤쳐)▶ 사람들: 최경인 [email protected]전문영역: 통합 마케팅/소비자 조사, 모금/배분 사업 기획/관리, 국내외 비영리관련 연구조사2014 (현)진저티프로젝트 / 프로젝트팀장2011 - 2013 Give2Asia 한국지역 어드바이저2009 - 2010 아름다운재단 국제협력연구팀장2005 - 2007 포뎀대학 사회복지대학원2003 - 2004 아름다운가게 팀장1999 - 2003 한국피앤지유한회사 브랜드매니저서현선 [email protected]전문영역: 교육기획•교육컨설팅, 모금기획•모금조직관리2014 (현)진저티프로젝트 / 프로젝트팀장2011 (현) 여명학교 모금위원장2010 - 2011 Give2Asia 한국지역 어드바이저2008 - 2009 아름다운재단 나눔교육전문위원2002 - 2007 아름다운재단 국제협력연구팀장황선미 [email protected]전문영역: 비영리 조직관리(커뮤니케이션, 투명성, 모금, 리더쉽) 모금•배분•교육•연구 사업기획, 민간재단 및 기업사회공헌 트렌드 연구조사2014 (현)진저티프로젝트 / 프로젝트팀장2013 모금스터디 진행 및 모금컨설팅2003 - 2012 아름다운재단 사업국장2000 - 2002 품청소년문화공동체 홍주은 [email protected]전문영역: 기부문화 연구, 비영리 교육 및 번역 출판, 국내외 비영리 트렌드 조사2014 (현) 진저티프로젝트 / 프로젝트매니저2013 (현) 보스톤한미예술협회 펀드레이징 어드바이저2006 – 2009 아름다운재단 국제협력연구팀 기부문화연구소 담당 김지연 [email protected] (현) 진저티프로젝트/BIC프로젝트매니저2007-2009 부여군 청소년수련원2005-2007 군포시 당동청소년문화의집2003-2004 한국방송제작단(프로덕션)2002-2003 품청소년문화공동체 이슬기 [email protected] (현) 진저티프로젝트 / 프로젝트어시스턴트2014 (현) 여명학교 계절학기/방과후 프로그램 코디네이터2013-2014 끌리베에듀케이션(Kliebe Education) 교사, 통역사2013 에모리대학교(Emory University) 심리학 & 교육학 졸업 w/ honors2011-2013 에모리대학교(Emory University) 연구원2013 Marcus Autism Center Early Intervention Program 보조교사#진저티프로젝트 #회사소개 #서비스소개 #기업문화 #가치소개