“Deere is acquiring Blue River Technology for $305 million.” - CNBC.com 며칠 전 외신에서 익숙한 회사 이름을 발견했다. 블루리버 테크놀로지(Blue River Technology)가 존디어(John Deere)에 약 3,400억원에 인수되었다는 뉴스였다. 블루리버 테크놀로지는 2011년 스탠포드 대학원에서 창업 수업을 함께 들었던 조지 헤로드(Jorge Heraud)가 창업한 농업 기술 회사다. 존디어는 트랙터, 지게차, 불도저 등을 취급하는 미국 최대의 농기계 회사다. 국내에서는 익숙한 이름이 아니지만, 1837년에 설립해 무려 180년의 역사를 가졌다. 친구가 창업한 회사가 불과 6년 만에 이런 성과를 거두었다는 뉴스를 접하니, 오랜만에 우리가 함께 들었던 수업의 광경이 떠올랐다. 이전 포스트에서 소개한 바와 같이, 스탠포드 대학원 재학 시절 정말 듣고 싶었던 린 론치패드(Lean Launchpad) 수업을 수강했다. 실리콘밸리의 전설적인 창업가인 스티브 블랭크(Steve Blank)가 개설한 수업으로, 전세계에 린 스타트업(Lean Startup) 이론 열풍을 일으키는데 큰 역할을 한 수업이다. 과목 코드가 Engineering 245이기 때문에 수업명 대신 흔히 E245 라고 부른다. 2011년 스탠포드 E245 (린 론치패드) 수업의 소개 이미지E245는 이론이 아니라 창업 실전을 경험하게 하는 치열한 수업 방식으로 유명하다. 창업을 꿈꾸는 스탠포드 학생들이면 누구나 듣고 싶어하는 인기 수업이다. 수업에 들어가는 과정의 시작부터 매우 치열하다. 자신의 창업 아이디어를 상세하게 담은 제안서를 제출하면, 약 40명의 수강생을 선발해 10개의 팀으로 구성한다. 각 팀에는 4명의 멘토들이 배정되는데, 우리팀에 함께 한 멘토는 픽사(Pixar)의 전CTO, 구스토(Gusto)의 창업자 등 그 면면이 너무나 뛰어난 분들이었다. 내가 수강했던 2011년 린 론치패드에 참여한 총 40명의 멘토들이 과거에 창업했던 회사들의 시가 총액을 모두 합치면 100조원을 훌쩍 뛰어 넘을 정도였다. 수업 첫 시간에 조지가 내놓은 아이디어는 GPS 기술을 기반으로 한 자동 제초 기계였다. 농장, 골프장, 고속도로 등에서 제초 작업을 위해 불필요하게 많은 인력과 비용이 낭비되고 있어 기술 혁신이 시급하다는 내용이었다. 이와 같은 자신의 창업 아이디어를 발표하며 팀원들을 리쿠르팅하던 조지의 모습이 아직도 생생하다.풀고자하는 문제에 걸맞게 Autonomow 라는 프로젝트 이름으로 E245를 수강했던 조지의 아이디어는 3개월 동안 수차례의 피봇(pivot)을 거쳐 변화해나갔다. 그리고 마침내 이미지 인식 기술을 통해 잡초만 인식해서 부분적으로 제초제를 살포하는 사업으로 구체화되었고, 블루리버 테크놀로지의 창업으로 이어진지 6년 만에 미국 최대 농기계 업체에 인수된 것이다. E245 수업 동안 조지의 팀이 성장한 과정을 스티브 블랭크 교수님이 정리한 “제자들의 성장을 지켜보며(Watching my students grow)” 라는 글 속에서 이 수업의 치열함과 진지함을 조금 더 느껴볼 수 있다. 나 역시 E245 수업에서 실행한 프로젝트로 실제 창업을 했다. 우리팀이 진행한 프로젝트는 ‘조인트바이(JointBuy)’. 2011년 당시는 다수의 고객이 모이면 서비스에 대폭 할인을 제공하는 그루폰(Groupon) 등의 온라인 공동 구매 플랫폼이 폭발적으로 성장하던 때였다. 그러나 실물 상품의 판매는 레스토랑이나 레저 등의 서비스 산업과 다른 점이 있었다. 상품의 제조 수량과 판매 재고 관리에 대한 이슈가 있었기 때문이다. 아이디어를 키워가는 과정에서 특정한 버티컬(vertical)에 최적화된 공동 구매 플랫폼을 만들기 위해서는 전혀 다른 접근 방식이 필요하다는 결론에 이르렀다. 수업 과정에서 만들어진 아이디어는 패션 커뮤니티와 구매 채널을 융합하는 서비스 아이디어로 발전했다. 우리팀은 이 E245 수업에 참여한 10팀 중 2등의 성적을 거두었고, 당시 우리팀의 멘토들과 스티브 블랭크 교수님 역시 빠르게 창업할 것을 권유했다. 유학을 가기 전부터 실리콘밸리에서의 창업을 꿈꿨던 나는 E245 수업 후 스탠포드 대학원에 진학한 지 1년 만에 학교를 자퇴하고 스타일세즈(StyleSays)를 창업하게 되었다. 그당시 함께 E245를 수강했던 나머지 8개 팀의 행적이 궁금해 찾아보았지만 쉽게 찾아지지 않았다. 일부는 고된 창업길의 문턱에서 좌절하고 중단했을 수도 있고 일부는 내 경우와 마찬가지로 프로젝트 이름을 바꾸어 창업 전선에서 계속 혁신을 만들어나가고 있을거라 생각된다.이번 주는 몇 명의 잠재 고객과 대화했는가?매주 수업 시간마다 스티브 블랭크 교수님이 모든 팀들에게 공통적으로 묻는 질문이었다. E245 수업에서 배운 고객 중심의 사고 방식은 한국으로 돌아와 렌딧을 창업하고 발전시키고 있는 지금도 늘 가장 중요하게 생각하는 교훈이다. E245 수업은 창업에 있어 가장 중요한 한 가지인 고객 개발(Customer Development) 방법론을 몸소 부딪치며 실제로 경험할 수 있었던 최고의 수업이었다.

제니퍼는 기업 내부망에 설치되는 On-Premise 방식의 소프트웨어 제품이다. 12년 넘게 국내 점유율 1위를 지키고 있는 제품이다보니 그만큼 고객의 요구사항도 다양하다. 대부분의 솔루션 회사는 제품 개발 초기에 단일 소스코드를 유지하며 개발하는 것을 추구했을 것이다. 하지만 비즈니스를 하다보면 특정 고객을 위한 기능을 추가할 수 밖에 없는 상황이 오게 된다. 보통 이런 경우에는 숨겨진 기능으로 개발하거나 고객사 별로 소스코드를 다르게 가져가기도 한다.기존의 제니퍼를 사용하는 고객들은 애플리케이션 모니터링만이 아닌 브라우저나 스마트폰 같은 클라이언트 영역과 데이터베이스 관리 시스템까지 연계된 통합 모니터링을 하고자하는 요구사항을 오랫동안 요청했었다. 모니터링 제품 간의 연계를 생각하면 약간 생소하게 생각할 수 있는데, 특정 데이터를 수집하고, 이를 가공하여 사용자에게 보여주는 단순한 매커니즘의 하나라고 생각하면 이해가 쉬울 것 같다.즉, 다른 종류의 데이터를 하나의 화면에서 볼 수 있는 통합 환경을 제공해야 한다. 그래서 최근에는 오픈소스로 배포되고 있는 엘라스틱서치나 상용 제품인 스플렁크 같은 로그분석 솔루션이 주목받고 있다. 하지만 위와 같은 제품들을 사용하여 제니퍼 성능 데이터와 연계하여 통합 환경을 구축한다는 것은 말처럼 간단하지 않다. 제품을 구매하고 학습하는 비용이 생각보다 크고, 통합을 위한 별도의 시스템이 갖춰져야 한다는 것은 고객의 입장에서 큰 부담이 된다. 이러한 부담을 덜어주기 위해서 제니퍼는 실험실이라 불리우는 확장 기능을 제공한다. 실험실은 워드프레스의 플러그인과 비슷한 성격을 가지며 코드 레벨 영역에서 확장될 수 있다. 실험실은 처음부터 다른 모니터링 제품과의 연계를 위해 개발된 것은 아니었다. 기획 초기에는 방대한 제니퍼 데이터를 좀 더 다양한 형태의 화면으로 제공하기 위함이었는데, 아무래도 실험적인 요소가 강하다보니 기존의 대시보드나 분석 같은 범주로 들어가기에는 완성도 측면이나 제니퍼의 방향성에 영향을 미칠 수 있다는 판단에 별도의 범주로 만들게 되었다.  실험실이란 이름은 구글 메일의 실험실에서 따온 것인데, 아직 개발 중인 실험적 기능을 위한 테스트 공간이고, 언제든지 변경 또는 중단되거나 사라질 수 있다. 그리고 모든 실험실 소스코드는 깃허브를 통해 공개하는 것이 기본 정책이다. 제니퍼소프트 깃허브에 가보면 실제로 다수의 실험실 프로젝트가 존재한다는 것을 알 수 있다. 그 중 한가지만 간략하게 소개하자면 사용자 관점의 웹 서비스 모니터링 제품인 아르고스와 연계하여 브라우저나 스마트폰 같은 사용자 관점의 성능 데이터를 제니퍼 트랜잭션 데이터와 연계하여 분석할 수 있는 기능을 제공한다. 실은 그동안 고객들에게 사용자 관점의 성능 모니터링에 대한 요구사항이 많았지만 제니퍼 본연의 영역과 확연하게 다른 측면이 있어서 요구사항을 수용하는데 많은 고민이 필요했다. 그래서 우리는 관련된 솔루션 업체를 찾았고, 상호 간의 비즈니스 협력을 통해 서로의 부족한 부분을 보완하기로 결정했다. 실험실은 제니퍼가 시도하고 있는 새로운 기능을 미리 체험해 볼 수 있을 뿐만이 아니라 오픈소스나 관련된 솔루션과의 연계를 하기 위한 화면을 제공할 수 있다. 뿐만 아니라 코드 레벨 영역에서 확장을 하는 것이다보니 제품의 커스터마이징 범위가 넓어진다. 즉, 화면에 대한 고객의 요구사항이 제니퍼의 방향성과 크게 다르더라도 많은 고민을 하지 않고 충분히 원하는 것을 구현해줄 수 있다. 과거와 달리 동일한 데이터라도 좀 더 시각적인 화면을 요구하는 요즘같은 시기에 실험실은 이러한 시도를 하기에 좋은 방법이 된다.제니퍼는 화면 단위의 확장 기능인 실험실 뿐만이 아니라 트랜잭션 데이터가 수집되는 시점이나 특정 이슈가 발생할 때, 생성되는 이벤트 데이터를 어댑터를 통해 전달받을 수 있다. 어댑터도 실험실과 마찬가지로 코드 레벨 영역에서 확장할 수 있다. 실시간으로 전달받은 트랜잭션 데이터는 별도의 스토리지에 저장하여 목적에 맞게 조회해서 사용할 수 있다. 특히 이벤트 관련 어댑터는 가장 많이 사용되는 제니퍼 확장 기능이며, 고객사의 관제시스템 연동에 주로 사용된다.  실험실은 어댑터와 달리 제니퍼 서버에서 전달받은 데이터를 처리만 하는 단순한 구조가 아니었다. 제니퍼와 독립적인 화면 구성에 필요한 모든 요소들을 갖춰야했기 때문에 고려해야할 것들이 너무 많았다.  그럼에도 불구하고 만들게 된 이유는 단순히 필자의 편리함을 위해서였다. 평소에 데이터 시각화에 관심이 많았기 때문에 이미 존재하는 방대한 제니퍼 데이터를 다양한 방식으로 표현하기 위한 시도를 했었다.하지만 상용 솔루션인 제니퍼에 테스트 코드를 필자 임의로 추가해서 배포하거나 숨긴 기능으로 만들기에는 꽤 부담스러운 일이었다. 그렇다고 별도의 소스코드로 다르게 가지고 가기에는 관리 측면에서 어려움이 있다. 그렇기 때문에 기존의 제니퍼 소스코드를 참조만 하되 서로 독립적으로 개발하는 형태를 생각하게 되었다. 이렇게 필자의 편리함을 위해 시작한 실험실이지만 오픈소스나 다른 솔루션과의 연동을 위한 화면을 제공하고, 새로운 제니퍼 기능에 대한 비전을 시사하거나 고객의 피드백을 수용하는 용도로 확장되었다.소프트웨어 개발을 하다보면 제품이 추구하는 방향과 달라서, 또는 구현은 가능하지만 소모되는 리소스 비용이 부담이 될 경우, 그리고 특정 사용자를 위한 특화된 기능을 구현할 때, 모두가 만족할만한 기능이라는 확신이 없다면 제대로 진행하기가 어려운게 현실이다. 사실 새로 시도하는 기능은 시기와 때에 따라 앞에서 고려했던 것들과 다르게 평가되는 경우도 있다.그래서 아무리 작은 아이디어라도 시도를 해보는 것 자체만으로도 큰 의미가 있으며, 새로운 가능성을 발견하는 계기가 될 수 있다. 다만 현재는 제니퍼 기능 확장에 대한 기반 정도만 갖춰진 시작 단계라서 관련된 API 문서나 개발 도구에 대한 지원이 미흡한 것이 아쉬움으로 남는다. 다음 편에서는 자바 개발자 대상으로 실험실을 직접 구현하는 방법에 대해 알아볼 것이다.

성호님 졸업식이래요.8월 초 어느날, 심사팀 준호님이 슬랙 전체방을 통해 성호님 졸업식 소식을 알려줬다. 8퍼센트 팀원들은 마치 기다렸다는 듯이 즉각적으로 흥미진진한 이벤트(?)소식을 반겼다.이 슬랙 대화로부터 이 모든 작당이 시작되었다. 더불어 성호님이 개고생(?) 하고 있다는 것도 함께 공개한다. 그런데 박사도 고생길 아닌가? ㅎㅎ여기는 김성호 졸업식 대책반입니다.D-2친절왕 CTO 호성님은 슬랙 비공개 채널을 개설하였고 성호님 졸업식 작당 모의가 본격적으로 시작되었다. 이런 즐거운 장난은 신이 절로 난다. 여러 아이디어가 나왔고 8퍼센트 Way 중 하나인 '나인가 싶으면 나다.'에 입각하여 척척 일을 진행했다.김성호 졸업식 대책방 개설D-1현수막 도착. 동료들은 회의실에 모여 현수막에 축하 메세지를 적었다.성호님, 졸업 축하해요!D-day모든 동료들이 가서 축하해주고 싶었지만 업무 공백으로 고객님들께 불편을 드릴 순 없었다. 구성원들을 대표해서 나, 준협님, 혜승님 이렇게 3명이 졸업식에 갔다.언제나 명랑한 성호님을 사무실 밖에서 그것도 캠퍼스에서 만나니 왠지(?) 무척 반가웠다. 학사모를 쓴 성호님의 모습은 그닥 새롭지 않았다. 왜냐하면 현수막에 해원님이 합성으로 만들어 주신 것과 똑같았으니깐. ㅎㅎ성호님 독사진. 바람이 많이 불었던 날이란 걸 알 수 있다.성호님 어머니께서 '성호가 회사일이 많아 연애를 잘(?) 못하다.'고 하셔서 억울한 마음에 진실(?)을 말씀드릴 뻔 했다. 성호님 웃는 모습이 참 예쁜데 어머니를 꼭 닮았다.성호님, 나(효진), 혜승님, 준협님더 잘 보이는 곳으로 옮긴 후우리가 즐거워 준비한 이벤트가 성호님께 소소한 행복으로 기억되길 바란다. 어머니께서도 즐거워하셨던 것 같아 마음이 따뜻하다.당신의 노력을 알기에.8퍼센트 팀원들이 성호님의 졸업을 다 같이 진심으로 축하하는 것은 일과 학업을 병행하는 과정을 모두 봐왔기 때문이다. 나는 일과 학업을 병행해본 적이 없고 논문을 써본 적이 없어서 상상이 잘 되지 않는다. 다만, 그의 회사 업무가 결코 적지 않았고 퇴근 후와 주말에 쉬거나 놀지 못하고 논문을 써왔음을 슬랙의 #study 채널을 통해 알고 있다.* 참고 : #study 채널은 각자 공부한 것과 글쓰기에 대한 진행을 공유하는 채널로 열심히 사는 동료들의 모습에 서로 자극을 많이 주고 받는다.매주 월요일 각자의 공부 진행을 공유한다. 자랑, 칭찬, 반성, 자극을 주고 받는 곳이다.성호님, 졸업해줘서 고마워요.성호님을 처음 만난 것은 작년 11월, 내가 먼저 페이스북 메세지로 말을 걸어 만나자고 했다. 8퍼센트의 단골 투자고객이었던 성호님은 종종 상품과 서비스에 대한 의견을 주시곤 했다. 글을 통해 지적 호기심과 합리성, 그리고 따뜻함을 느껴 만나보고 싶었고 만나보니 더 좋았다. 금융공학 대학원생이었던 성호님은 외환, 주식, 파생상품, 비트코인 등 다양한 투자를 경험해 보았고 8퍼센트 상품에 대한 이해와 확신을 갖고 있었다. 또한 금융상품을 설계하는데 필요한 금융지식과 구현 역량을 갖추고 있었다. 나는 그 자리에서 "우리 회사에서 인턴해보지 않을래요?"라고 물었다. 성호님은 1초만에 "네! 재미있을 것 같아요."라고 대답했다. 그리고 바로 다음날 출근했다.처음엔 학기중이라 파트타임 인턴으로 일했다. 일을 시작한지 3주쯤 지났을 때 성호님이 면담을 요청했다. 병행해보니 둘 다 한다는 것이 현실적으로 도저히 불가능하고 8퍼센트 일이 재미있어서 휴학을 하고 정식으로 일해보고 싶다고 했다. 성호님은 석사 마지막 학기가 불과 6주 정도 남아있었고 원래 박사과정으로 진학할 계획이었다. 8퍼센트에서 일하는 것은 인생의 변곡점이 되는 결정이고 그 학기 등록금도 환불받지 못한다. 다행히 졸업에 필요한 수업은 다 들어서 추후 논문을 쓰면 석사 학위를 받을 수 있다고 했다. 부담이 조금 되긴  했지만 성호님이 많은 고민끝에 내린 결정을 믿고 성호님 합류가 우리 회사에 큰 힘이 될 것이란 확신이 있었기에 정식으로 함께 일하기로 했다.아무리 성호님 개인의 선택이라지만 그래도 늘 나 혼자만의 부채 의식이 있었다. 석사가 코앞이었는데 8퍼센트 합류로 멀어졌고 내 주변 많은 사람들이 끝내 일과 논문을 병행하지 못해서 졸업이 아닌 수료로 마무리 짓는 것을 봐왔기 때문이다. 그런데 이렇게 무사히 졸업을 해주니 나의 어깨도 조금 가벼워졌다. Thank you!졸업식을 제보해준 준호님, 현수막 아이디어를 내준 연대 동문 혜련님, 현수막 카피라이터 호성님, 현수막을 제작해준 해원님, 처음부터 마지막까지 세세하게 챙기고 참석해준 준협님, 휴가중에도 성호님을 축하해주러 분당에서 연대까지 오신 혜승님, 아이디어를 내고 축하메세지를 남기며 함께 축하하고 즐거워해준 모든 동료들, 그리고 바쁜 회사 생활 와중에도 논문을 완료하여 우리에게 즐거운 이벤트를 마련해준 성호님에게 고맙다.#8퍼센트 #에잇퍼센트 #팀원 #팀플레이 #즐거운분위기 #사내복지 #석사졸업 #이벤트 #조직문화 #기업문화

이 포스트는 플레이팅 개발자 박은환님의 '회사 1일차' 포스트를 오마쥬 한 것 입니다.회사 1일차어쩌다 보니 나도 매달 한 번씩 마루180에서 열리는 플레이팅 액티비티 데이(워크숍)부터 출근을 시작하게 되었다. 워크숍이다 보니 1일 차 때는 맛보기? 정도였고, 2일 차가 된 오늘부터 본격적인 업무가 시작되었다. 언젠가부터 기록(문서화)은 분명 중요한 것이라는 생각이 들어 기록을 남긴다.그래도 첫 출근을 워크숍으로 하니 좋은 점도 있다. 각 팀의 현재 상황을 공유하는 자리이다 보니 현재 회사의 각 팀 업무와 팀별로 엮여있는 각종 상황, 앞으로의 방향성 등 큰 그림 파악하기에 매우 좋은 자리였다.회사 2일차영어 이름을 사용해보자사실 영어 이름은 전 직장인 이큐브랩에서도 사용하던 것이라 거부감이 0에 가까웠다. 개인적으로 국내 회사에서의 영어 이름은 계륵일 수 있다는 입장이지만 2일 차인 아직은 괜찮은 것 같다. 나는 영어 이름보다는 닉네임을 선호하는 편이라 늘 사용하던 요우(Yowu) 라는 이름을 사용하기로 했다. 몇몇 분들은 되게 어려운 이름이라고 하신다. 사실 영어 이름은 군대 시절 해외파 통역병 준엽이 형이 지어준 Anthony라는 부담스러우면서 간지 넘치는 이름이 있지만 사용해본 적이 거의 없어 요우가 편하다.정말 오랜만의 스크럼 회의스크럼 회의를 했다. 지금까지 했던 스크럼 회의보다 훨씬 간단한 형태다. 애자일 보드도 없고 Task를 보면서 하는 회의도 아니었지만 각자 어제 한 일과 오늘 한 일을 간단명료하고 신속하게 공유한 뒤 종료되었다.회사 시스템과 코드를 파악해보자입사 후 1주일 정도의 순수 업무 파악 기간이 있으면 가장 좋지만 아무래도 스타트업이다 보니 바로 내부에서 사용할 간단한 서비스를 만들게 되었다. 회사 개발자들 모두 MacBook Pro 쓸 때 혼자 노트북에서 쓰던 Ubuntu 쓰겠다고 해서 eslint (es6 + airbnb)를 vim으로 올리는데 꽤 애를 먹었다. eslint를 사용하는 것에서 눈치챘겠지만 플레이팅의 기술 스택은 node.js, react.js, redux 등이다. (그런데 airbnb의 컨벤션이 나를 너무 귀찮게 한다.. 그 수 많은 빨간 줄이란..)정말 다행히도 나는 최근 node.js를 메인으로 사용하고 있었고, 더 다행히도 react.js와 redux 역시 최근에 사용하고 있었다. 덕분에 코드 이해는 어렵지 않았지만 node.js 구조화의 자유로움 덕분에 현재 플레이팅에서 사용 중인 Application 구조 파악에 시간이 걸린다. 여기에 내가 사용해보지 않은 기술들. graphQL이나 knex, material-ui 등을 익히는데 걸리는 시간은 어쩔 수 없는 당연한 학습 비용이다. (나는 SQL문을 직접 핸들링하는 걸 더 좋아하는데 ㅜㅜ)다만, 워낙 급성장한 스타트업인 탓에 내부 인프라 개선이나 가이드라인 수립, 데이터베이스, 문서화 등에서 정말 할 일이 많아 보인다.(없는 것 보다는 낫다) 순수 개발은 나보다 감각이 좋은 개발자들이 많으니, 개인적으로 업무도 익힐 겸 한동안 이쪽 부분을 일들을 맡아보는 것도 좋을 것 같다. (바쁘면 그런 거 없겠지만.)그렇다면 이제 밥을 먹어보자플레이팅에서 판매하는 '홍콩식 비빔 탄탄면'이다.역시나 플레이팅에서 판매되는 음식들은 가히 최상급이다. 심지어 신선함을 위한 당일 판매가 원칙이다 보니 당일에 팔지 못한 음식은 재고로 나와 먹고 싶은 직원은 그냥 먹을 수 있다. (물론 오늘 처럼 재고 없이 완판되면 없으면 아무것도 가져갈 수 없다. 흑) 그렇다고 우리가 짬처리되는 음식만 먹을 수 있는 것은 아니고, 직원들을 위한 포인트가 직원 복지로써 따로 지급된다. 그 포인트로 회사 내에서 주문하여 먹을 수 있다. 오늘은 홍콩식 탄탄면을 먹었는데 정말 맛있더라. 내 지출을 분석해보면 앵겔 지수가 매우 높은 편인데, 차후 엥겔 지수의 감소를 기대해본다.플레이팅의 사원에게는 수저 세트가 지급된다. (...군대?)마무리2일 차 출근이지만 제대로 된 1일 차 출근으로써 느낀 점은 개발하는 데 있어 자유로운 분위기가 강하다. 이것이 나에게 어떻게 작용할지는 앞으로 지켜봐야겠지만 스스로 텐션을 잘 조절하고 경계심을 가져야 할 필요를 느낀다. 자유로운 분위기의 스타트업이지만 동시에 물론 급성장하는 스타트업이니만큼 당장 떠오르는 창의적이고 편리한 무언가를 만들기보다 당장 눈앞에 닥친 작업을 하게 될 일이 많을 것이다. 하지만 이는 회사가 어느 정도 안정 궤도에 오르고 나면 언제든지 시도해볼 수 있을 것이다.#플레이팅 #입사 #입사2일차 #출근 #2일차출근 #경험공유 #기업문화 #조직문화 #회사소개 #팀소개

편집자 주아래와 같이 용어를 표기하기로 저자와 협의함Docker, NodeJS, NginxOverview안녕하세요. 칼 같은 들여쓰기에 희열을 느끼는 브랜디 개발자 강원우입니다! 서버를 운영해본 개발자라면 Fatal 에러, 아웃오브메모리 에러, 또는 전날 흡수한 알코올로 인해 손을 떨다가 한 번쯤 서버를 요단강 너머로 보내봤을 겁니다. 만약 테스트 서버였다면 잠시 마음을 가다듬으면 되지만, 현재 상용 서비스 중인 서버라면 얘기는 달라집니다.님아, 그 강을 건너지 마오!이런 간담이 서늘해지는 경험은 저 하나로 족합니다. 그래서 고군분투했던 지난 날을 되돌아보면서 빠르고 안정적이며, 죽어도 죽지 않는 좀비 같은 서버 구축 방법을 쓰려고 합니다.준비물서비스를 운영할 때 가장 중요하게 여겨야 하는 건 역시 안정성입니다. 이번 글에서는 오래 전부터 개발 세계의 뜨거운 감자였던 Docker와, 단일 스레드와 이벤트 루프로 태생적으로 심플하고 민첩한 NodeJS, 마지막으로 고성능을 목표로 개발된 Nginx를 활용하겠습니다.1. DockerDocker는 컨테이너 기반의 오픈소스 가상화 플랫폼입니다. 대표적으로 LXC(Linux Container)가 있습니다. 화물 컨테이너처럼 어떠한 일련의 기능을 완전히 격리된 소프트웨어 환경에서 작동하게 만드는 기술을 말합니다.OS 가상화와 별반 다를 게 없는 것 같지만 소프트웨어적으로 작동한다는 차이가 있습니다. 다시 말해, 현재 OS의 자원을 그대로 사용하기 때문에 하이퍼 바이저가 가상환경을 위해 가상의 커널을 만드는 오버헤드가 거의 없다는 것이죠.이미지와 속도도 차이를 보입니다. 완벽하게 구성한 세팅을 그대로 이미지화할 수 있고, 해당 이미지는 Docker 위에서 완벽히 동일하게 동작하는 걸 보장합니다. 해당 이미지로 컨테이너를 제작할 땐 1~2초면 새로운 컨테이너가 생겨날 정도로 엄청나게 빠른 속도도 자랑합니다. 1)또한 Docker는 자주 사용되는 다양한 이미지를 퍼블릭 레포지토리에 공유해 사용할 수 있기도 합니다. 양파도 아닌데 특징이 계속 나오죠? 다음 글에서 Docker의 특징을 더 자세히 다루겠습니다.Docker는 리눅스만 지원했었지만, 요즘은 Docker for Windows와 Docker for Mac으로 거의 모든 OS에서 사용할 수 있습니다. 2) Docker 설치 링크는 윈도우와 맥으로 나뉘어져 있습니다. 리눅스는 아래를 참고하세요.curl -fsSL https://get.docker.com/ | sudo sh 2. NodeJSNodeJS는 구글이 구글 크롬에 사용하려고 제작한 V8 오픈소스 자바스크립트 엔진을 기반으로 제작된 자바스크립트 런타임입니다. NodeJS에는 몇 가지 특징이 있습니다.단일 스레드입니다.비동기 방식입니다.이벤트 루프를 사용합니다NPM이라는 끝내주는 동반자가 있습니다.비유하자면 예전엔 낡은 곡괭이로 큰 돌을 캐내려고 수십 명의 인부가 달라 붙었는데, 지금은 육중한 포크래인으로 거대한 돌을 쑥! 뽑아버리는 것과 비슷합니다. 굉장히 효율적이죠. NodeJS는 단일 스레드의 장점을 극대화하려고 이벤트 루프를 통해 모든 처리를 비동기로 수행합니다. 서버 사이드의 묵직한 CPU들이 빠르게 일을 처리하고 이벤트 루프에 등록된 일을 감지해 다음 작업을 빠르게 수행하는 방식입니다.마지막으로 NPM(Node Package Manager)은 NodeJS에서 사용할 수 있는 다양한 모듈을 관리해주는 프로그램입니다. 도커와 상당히 유사합니다. NodeJS에서는 무언가 기능을 만들기 전에 NPM을 먼저 뒤져보라는 말이 있을 정도로 풍부한 모듈 생태계가 구성되어 있습니다. 이는 로깅이나 날짜 계산 등 생각보다 까다로운 것들을 가져다 사용할 수 있게 도와주기 때문에 개발이 빨라집니다. NodeJS 설치링크는 여기를 클릭하세요. 이 글의 예제에서는 NodeJS의 현재시점 LTS인 codename Carbon버젼을 사용합니다!8.x 버젼이 Active LTS 상태입니다.LTS은 Long Term Support의 약자로 가장 오랜기간 지원하는 버전입니다.우선 서비스 구성을 위해 간단한 NodeJS 어플리케이션을 작성해보겠습니다.첫째, packge.json를 작성합시다.{   "name": "nodejs_tutorial_server",   "version": "0.0.0",  "private": true,   "scripts": {     "start": "node nodejs_tutorial_server.js"   },   "description": "NodeJS Tutorial Server",   "author": {     "name": "WonwooKang"   },   "dependencies": {     "express": "^4.16.3",     "uuid": "^3.2.1"   } } nodejs_tutorial_server.js 파일을 메인으로 실행합니다. HTTP Request를 처리하려면 express를 사용해야 하며, 서버를 구분하려면 uuid모듈이 필요합니다.둘째, package.json의 의존 파일들을 설치합시다.npm install npm install 전npm install 후셋째, 간단한 웹 어플리케이션을 작성합시다.var express = require('express'); var app = express(); const port = 3000;  var server = app.listen(port, function () {     console.log("Express server has started on port : "+port);  });  app.get('/', function (req, res) {     res.send('Hello?');  }); 넷째, package.json의 script start 구문을 실행하여 서버를 로드합시다.npm start 3000번 포트로 서버가 시작되었습니다!접속해볼까요?잘 접속됩니다.그런데 수정할 때마다 서버를 매번 다시 띄우면 귀찮을 겁니다. 이럴 땐 nodemon 모듈을 사용합시다. nodemon은 Nodejs의 파일이 수정되는 걸 감지해 자동으로 리로드해주는 편리한 도구입니다.nodemon설치npm install nodemon -g package.json script 변경"scripts": {     "start": "nodemon nodejs_tutorial_server.js"   }, nodemon 실행확인을 위해 약갼의 수정//nodejs_tutorial_server.js 수정 app.get('/', function(req, res) {     res.send('Hello Nodemon');  }); nodemon을 통해 어플리케이션이 실행된 모습파일수정 후 저장했을 때 자동 감지한 모습서버 잘 떴습니다!성공적으로 단 하나의 GET 요청을 처리할 수 있는 심플한 NodeJS 기반 웹 어플리케이션을 완성했습니다. 이제 웹 어플리케이션을 Docker Container위에서 구동해봅시다!3. Docker로 NodeJS Express 서버 구동하기이제 Docker Container위에서 NodeJS서버를 구동할 건데요. 그러려면 우선 Dockerfile을 작성해야 합니다. 물론 Docker의 이미지를 당겨 받고, 컨테이너를 생성하고, 또 컨테이너를 실행해서 Attach하고, 필요한 파일들을 밀어넣는 등 귀찮은 방법도 있습니다. 하지만 개발자에게 이것은 힘든 작업이므로 Dockerfile을 적극 활용합시다. (Dockerfile의 D는 대문자여야 합니다! 꼭이요)Node 도커 이미지에 어플리케이션 파일을 추가해 실행하는 Dockerfile 작성하기FROM node:carbon MAINTAINER Wonwoo Kang [email protected] #app 폴더 만들기 - NodeJS 어플리케이션 폴더 RUN mkdir -p /app #winston 등을 사용할떄엔 log 폴더도 생성 #어플리케이션 폴더를 Workdir로 지정 - 서버가동용 WORKDIR /app #서버 파일 복사 ADD [어플리케이션파일 위치] [컨테이너내부의 어플리케이션 파일위치] #저는 Dockerfile과 서버파일이 같은위치에 있어서 ./입니다 ADD ./ /app #패키지파일들 받기 RUN npm install #배포버젼으로 설정 - 이 설정으로 환경을 나눌 수 있습니다. ENV NODE_ENV=production #서버실행 CMD node nodejs_tutorial_server.js Dockerfile 내용은 node:carbon에서 :carbon이 NodeJS의 이미지 버전 Tag 입니다.Dockerfile을 통해 docker image 빌드하기docker build –tag 레포지토리명: 태그 Dockerfile 경로docker build --tag node_server:0.0.1 [Dockerfile이 위치하는 경로] 호오... 게이지가 마구마구 차오르는군요?build가 완료된 화면입니다. Dockerfile의 내용 순서가 각 Step별로 진행된 것을 알 수 있습니다.빌드 결과 생성된 이미지 확인하기docker images 빌드 명령어에서 입력했던 버전 태그까지 잘 입력된 것을 알 수 있습니다.NodeJS Carbon 이미지를 기반으로 한 node_server 이미지를 제작했습니다. 사이즈는 둘이 합쳐 1Gb가 넘을 것 같지만 실제로는 변경된 부분만 저장됩니다. 그러므로 node_server 이미지의 크기는 6~10Mb 정도입니다.생성된 이미지로 컨테이너 만들기컨테이너 생성 명령어는 아래와 같습니다.docker create --name [서버명] -p [외부 포트:컨테이너 내부포트] [이미지명:버전태그] 주의할 점이 있습니다. 포트번호 바인딩 중 왼쪽은 우리가 접속할 실제 포트이고, 오른쪽은 컨테이너 내부의 NodeJS서버 할당 포트가 된다는 것입니다. 공유기의 포트포워딩 설정과 같습니다.docker create --name NODE_SERVER_0 -p 3000:3000 node_server:0.0.1 알 수 없는 코드가 생성되었습니다. 응?컨테이너 확인하기생성한 컨테이너를 확인해볼까요?docker ps 어.. 없잖아?옵션을 추가합니다.docker ps -a 나타났다!docker ps 명령어는 현재 실행 중(STATUS:Up)인 컨테이너의 목록을 보여줍니다. -a 옵션은 실행하지 않는 모든 컨테이너를 보여줍니다. 위의 이미지에서 node_server:0.0.1이미지로부터 NODE_SERVER_0 이라는 이름으로 2분 전에 생성되었다는 걸 알 수 있습니다. 3)컨테이너 실행하기docker start NODE_SERVER_0 다시 확인하기docker ps 19초 전에 Up상태가 되었다는 걸 알 수 있다.외부 3000번 포트 -> 내부 3000번 포트로 연결되었습니다. 서버도 실행되었고요! 이제 접속해볼까요?내용도 안 바꾸고 새로고침도 빨라서 뜬 건지 잘 모르겠군요. 내용을 수정해서 다시 확인하겠습니다.//nodejs_tutorial_server.js 수정 app.get('/', function (req, res) {     res.send('Hello I\'m In Docker Container Now!');  }); 파일 변경해서 다시 확인하기//버전 태그도 0.0.2로 업해주고 docker build --tag node_server:0.0.2 [Dockerfile위치] 잘 생성되었습니다.//이미지가 잘 생성되었는지 확인하고 docker images 0.0.2가 나타났습니다.//기존 컨테이너를 삭제합니다. -f 옵션은 실행중인 컨테이너도 강제로 삭제하겠다는 뜻입니다.  docker rm -f NODE_SERVER_0 // 잘지워졌나 확인하고  docker ps -a 잘 지워집니다.//0.0.2 버젼 이미지로 컨테이너를 다시 생성합니다.  docker create --name NODE_SERVER_0 -p 3000:3000 node_server:0.0.2   //서버를 실행합니다. docker start NODE_SERVER_0 잘 실행됩니다.이제 다시 접속해봅시다.안녕! 나 지금 Docker 안에 있어!이제 Docker로 여러 개의 서버를 띄우겠습니다. NodeJS는 싱글 스레드이기 때문에 하나의 CPU를 여럿이 나눠 갖는 건 비효율적입니다. 따라서 CPU 숫자에 맞춰서 서버를 띄워보겠습니다.제 맥북엔 CPU가 4개뿐입니다.CPU수에 맞춰 추가로 생성하기추가로 컨테이너를 생성하고, 서버를 실행합니다. 서버 목록도 확인해야겠죠.서버 생성서버 실행서버 목록 확인포트번호는 같은 포트를 쓸 수 없기 때문에 3001, 3002, 3003으로 매핑합니다. 브라우저로 접속해서 확인해보겠습니다.각 포트별 접속 화면미리 만들어둔 이미지 덕분에 서버 3대를 띄우는 데에 5분도 안 걸렸습니다. 하지만 Docker 서버를 여러 개 띄워도 결국 사람의 손이 닿아야 합니다. 따라서 이번에는 NodeJS의 Cluster를 활용해 적은 수의 Docker Container를 이용하면서도 다수의 CPU를 사용하겠습니다. 또 죽은 워커를 다시 살려 서버가 다운되는 것을 막아 안정적인 서비스도 구축해보겠습니다.4. 멀티코어대응 NodeJS Cluster 구성2컨테이너용 NodeJS Cluster서버 어플리케이션 작성하기var cluster = require('cluster'); var os = require('os'); var uuid = require('uuid'); const port = 3000; //키생성 - 서버 확인용 var instance_id = uuid.v4();  /**  * 워커 생성  */ var cpuCount = os.cpus().length; //CPU 수 var workerCount = cpuCount/2; //2개의 컨테이너에 돌릴 예정 CPU수 / 2  //마스터일 경우 if (cluster.isMaster) {     console.log('서버 ID : '+instance_id);     console.log('서버 CPU 수 : ' + cpuCount);     console.log('생성할 워커 수 : ' + workerCount);     console.log(workerCount + '개의 워커가 생성됩니다\n');        //CPU 수 만큼 워커 생성     for (var i = 0; i < workerCount>         console.log("워커 생성 [" + (i + 1) + "/" + workerCount + "]");         var worker = cluster.fork();     }        //워커가 online상태가 되었을때     cluster.on('online', function(worker) {         console.log('워커 온라인 - 워커 ID : [' + worker.process.pid + ']');     });        //워커가 죽었을 경우 다시 살림     cluster.on('exit', function(worker) {         console.log('워커 사망 - 사망한 워커 ID : [' + worker.process.pid + ']');         console.log('다른 워커를 생성합니다.');                 var worker = cluster.fork();     });  //워커일 경우 } else if(cluster.isWorker) {     var express = require('express');     var app = express();     var worker_id = cluster.worker.id;         var server = app.listen(port, function () {         console.log("Express 서버가 " + server.address().port + "번 포트에서 Listen중입니다.");     });        app.get('/', function (req, res) {         res.send('안녕하세요 저는 워커 ['+ cluster.worker.id+'] 입니다.');     });  } CPU 숫자를 받아 CPU 수(4)를 컨테이너 수(2) 로 나눠 워커를 생성하는 NodeJS 클러스터 구성입니다. 이렇게만 해도 운영에는 무리가 없지만 컨테이너 2개의 구분이 안 되서 확인할 수가 없습니다.그러므로 마스터와 워커의 통신을 이용해 마스터의 uuid를 얻겠습니다. (워커와 마스터 간의 데이터 이동은 통신 말고는 메모리DB 등의 데이터 저장소밖에 없습니다)마스터의 아이디를 알아오는 로직이 추가된 어플리케이션 작성var cluster = require('cluster'); var os = require('os'); var uuid = require('uuid'); const port = 3000; //키생성 - 서버 확인용 var instance_id = uuid.v4();  /**  * 워커 생성  */ var cpuCount = os.cpus().length; //CPU 수 var workerCount = cpuCount/2; //2개의 컨테이너에 돌릴 예정 CPU수 / 2  //마스터일 경우 if (cluster.isMaster) {     console.log('서버 ID : '+instance_id);     console.log('서버 CPU 수 : ' + cpuCount);     console.log('생성할 워커 수 : ' + workerCount);     console.log(workerCount + '개의 워커가 생성됩니다\n');         //워커 메시지 리스너     var workerMsgListener = function(msg){                    var worker_id = msg.worker_id;             //마스터 아이디 요청             if (msg.cmd === 'MASTER_ID') {                 cluster.workers[worker_id].send({cmd:'MASTER_ID',master_id: instance_id});            }      }        //CPU 수 만큼 워커 생성     for (var i = 0; i < workerCount>         console.log("워커 생성 [" + (i + 1) + "/" + workerCount + "]");         var worker = cluster.fork();                //워커의 요청메시지 리스너         worker.on('message', workerMsgListener);     }        //워커가 online상태가 되었을때     cluster.on('online', function(worker) {         console.log('워커 온라인 - 워커 ID : [' + worker.process.pid + ']');     });        //워커가 죽었을 경우 다시 살림     cluster.on('exit', function(worker) {         console.log('워커 사망 - 사망한 워커 ID : [' + worker.process.pid + ']');         console.log('다른 워커를 생성합니다.');                 var worker = cluster.fork();         //워커의 요청메시지 리스너         worker.on('message', workerMsgListener);     });  //워커일 경우 } else if(cluster.isWorker) {     var express = require('express');     var app = express();     var worker_id = cluster.worker.id;     var master_id;        var server = app.listen(port, function () {        console.log("Express 서버가 " + server.address().port + "번 포트에서 Listen중입니다.");     });        //마스터에게 master_id 요청     process.send({worker_id: worker_id, cmd:'MASTER_ID'});     process.on('message', function (msg){         if (msg.cmd === 'MASTER_ID') {             master_id = msg.master_id;         }     });        app.get('/', function (req, res) {         res.send('안녕하세요 저는 ['+master_id+']서버의 워커 ['+ cluster.worker.id+'] 입니다.');    });  } Docker Container에 올리기 전 로컬 테스트를 먼저 진행합니다. 서버 구동!두 개의 워커가 실행되었습니다.똑같은 localhost:3000번 접속이지만 워커의 번호가 다릅니다.이제 워커로 CPU 수만큼 워커를 생성할 수 있게 되었습니다. 이제 워커가 어떻게 안정적으로 서비스되는지 테스트하겠습니다. 워커 킬링 테스트하기워커 킬러 로직 작성//워커 킬링 테스트     app.get("/workerKiller", function (req, res) {         cluster.worker.kill();         res.send('워커킬러 호출됨');     }); 실험에 앞서 똑같은 상황 재연 마스터 아이디를 유심히 봐주세요. 워커 킬러를 실행하겠습니다.워커 킬러 호출아래는 호출된 결과입니다. 하나의 워커가 죽자마자 곧장 다른 워커가 태어나(?) 3000번을 Listen하기 시작했습니다. 워커 킬러가 호출된 화면이제 워커 킬러를 여러 번 호출해보겠습니다. CMD+R을 꾸욱 눌러 연속으로 킬링해봤는데 아래 화면처럼 바로 살아납니다.접속해서 현재 워커를 확인합니다.위의 화면처럼 마스터의 UUID가 그대로인데 워커만 교체되었습니다. 준비는 끝났습니다. 이제 Docker를 이용해 2명의 워커를 가진 2개의 NodeJS서버를 실행하고, 4개의 귀여운 CPU를 불살라봅시다! 5. Docker로 NodeJS Cluster 서버 실행하기docker build --tag node_server:0.0.3 /Users/kww/eclipse-workspace/nodejs-for-article docker create --name NODE_SERVER_0 -p 3000:3000 node_server:0.0.3 docker create --name NODE_SERVER_1 -p 3001:3000 node_server:0.0.3 docker start NODE_SERVER_0 docker start NODE_SERVER_1 cluster가 적용된 2개의 컨테이너 start0.0.3번 이미지로 생성된 2개의 컨테이너 서버가 무사히 로드되었습니다. 이제 접속해서 확인해볼까요?cluster가 적용된 2컨테이너 4서버 구동화면WOW! 2개의 URL, 2개의 UUID, 각 2명의 워커까지. 완벽한 2.2.2입니다. 마치 홍진호를 보는 듯한 서버 현황입니다. 이제 워커 킬러로 습격해보겠습니다.워커 킬러 습격 후위의 이미지를 보면 3000번 포트서버에서 13명, 3001번 포트서버에서 22명의 워커가 사망했습니다. UUID를 통해 2개의 서버에서 일정량의 워커가 매우 안정적으로 서버를 지키고 있는 걸 알 수 있었습니다.지금까지 2개의 컨테이너로 4개의 서버를 구성해보았습니다. CPU 숫자와 나눠지는 수에 따라 컨테이너의 수, NodeJS 클러스터 서버의 수를 유동적으로 조정할 수 있습니다. 전에 운영하던 API서버는 16코어 서버였고, 로드벨런서 및 기타 작업용 1코어의 여분을 남기고 15코어 / 3 으로 5개의 워커를 가진 3개의 NodeJS서버를 도커 컨테이너로 운영했었습니다.여기서 문제점이 생깁니다. 우리는 어떤 서비스를 할 때 하나의 도메인을 쓰는데 포트번호가 2개죠? 어떻게 해야 할까요. 여기서 바로 한참을 기다렸던 불곰국의 Nginx가 등장합니다.6. Nginx로 로드밸런싱 하기Nginx은 “더 적은 자원으로 더 빠르게”를 지향합니다. 러시아의 이고르 시쇼브(Игорь Сысоев)는 Apache에서 10,000개의 접속을 동시에 다루기 힘든 걸 해결하려고 Nginx를 개발합니다.Nginx는 NodeJS와 유사하게 싱글 스레드 방식에 이벤트 드리븐 구조 사용하는 오픈소스 HTTP서버로 최근 아파치의 점유율을 상당히 뺏고 있는 서버입니다. 다운로드 링크를 아래에 써두었습니다.Nginx 설치WindowNginx 다운로드Macbrew install nginx Linuxapt-get install nginx or yum install nginx Nginx 설치 성공Nginx 기본 접속 화면서버 조작방법서버 시작 : nginx 서버 중지 : nginx -s stop 서버 재시작 : nginx -r reload (맥에선 이건 안되는듯?) 기본 설정은 8080포트로 되어있습니다. 원하는 포트르 로드벨런싱 설정을 해보겠습니다. Nginx 로드밸런싱 설정아래는 Nginx의 로드밸런싱입니다.#http블럭 내부에 추가     #NodeJS 서버 로드밸런싱     upstream nodejs_server {         #least_conn;         #ip_hash;         server localhost:3000 weight=10 max_fails=3 fail_timeout=10s;         server localhost:3001 weight=10 max_fails=3 fail_timeout=10s;     }        #3333번 포트 NodeJS 서버로 연결     server{         listen               3333;         server_name  localhost;                location / {             proxy_pass http://nodejs_server;         }     } 로드밸런싱이 잘 적용되었는지 확인해보겠습니다. 로드밸런싱 적용 이후모든 브라우저에서 3333번으로 접속했는데 서로 다른 2개의 서버가 번갈아 접속되고, 워커가 가끔 바뀌는 걸 확인할 수 있습니다. 이번엔 로드밸런서로 워커 킬러를 호출하겠습니다.로드밸런싱 포트인 3333번 포트로 여러 번 호출결과 확인Nginx 로드밸런서가 확실하게 작동하는 걸 확인할 수 있었습니다. 위의 이미지에서 서버가 자꾸 바뀌는 모습을 볼 수 있는데, 이는 세션이 유지되지 않기 때문입니다. 실제 서비스에서는 세션의 유지를 위해 ip_hash 옵션이 꼭 필요합니다.ip_hash : 동일한 IP의 접속은 같은 서버로 접속하도록 하는 옵션입니다.  least_conn : 가장 접속이 적은 서버로 접속을 유도하는 옵션으로 ip_hash와 같이쓰입니다. Conclusion자, 고생하셨습니다. 여기까지 Docker와 NodeJS, Nginx를 이용해 관리하기 쉽고, 일부러 죽여도 죽지 않는 안정적인 서비스 환경을 구축해봤습니다. 한 가지 주의할 점이 있습니다. NodeJS의 Cluster는 죽은 워커를 바로 살리는데 싱글스레드여서 그런지 그 속도가 정말 어마어마합니다. 따라서 NodeJS Cluster를 사용할 땐 여러 핸들링에 신중하세요. 모든 promise에 반드시 catch를 달아 핸들링하고, 오류가 날 것 같은 로직엔 반드시 try - catch를 달아 핸들링을 해야 합니다. 그렇지 않으면 다시 살아나는 워커에 의해 서버의 자원이 고갈될 수 있습니다.예전에 16코어 서버를 운영할 땐 서버 자원에 비해 사용자가 적어서..(눈물) 5워커 2개의 서버만 구동하고 여유를 두었습니다. 그리고 서버 패치가 있을 때 3번째 서버를 대기시켰습니다. 앱에서 업데이트가 완료되는 시점에 Docker Container를 바꿔치기 하는 방식으로 Non-Stop서비스를 운영했죠. 혹시 코어가 빵빵한 여유 서버가 있는데 재빠르고 좀비 같은 서비스를 구성해야 한다면 위와 같은 환경 구축을 강력히 추천합니다. 지금까지 긴 글을 읽어주셔서 감사합니다.ps. 글 쓰다 보니 해가 떴네요. 하하.참고1) 가상 머신은 작은 이미지라도 기가바이트 단위의 사이즈와 Load되기까지 상당한 시간이 소요된다.2) 그러나 Windows의 경우, Hiper-v위에 리눅스를 띄워 도커를 구동한다. Mac에서도 가상 머신 위에서 구동된다. 따라서 성능적인 강점은 리눅스에만 적용된다.3) 도커에서는 NAME 속성을 지어주지 않으면 알아서 이름을 지어주는데 romantic한 단어가 많다.글강원우 과장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발팀 #개발자 #개발환경 #업무환경 #인사이트 #경험공유

스타트업에 마케터로 합류한 지 1년이 지났다.지난 3월, 중간 점검의 차원에서 이런 글을 썼었는데, https://www.theteams.kr/teams/869/post/64499 오늘은 그 이후의 이야기를 정리해보려고 한다.1. 카카오 1분 채널과 플러스 친구 운영, 쉐어하우스와 협업을 시작하다.3월에 글을 쓸 때는 내가 만들었던 페이스북 콘텐츠와 관련된 내용을 주로 리뷰했었다.그 외에 이메일 서비스를 했던 것, 블로그 운영을 새롭게 시작한 일에 대한 내용이 있었다.그렇게 글을 쓴 후에 또 새롭게 시작한 일이 있다면 카카오 1분 채널과 플러스 친구 운영, 그리고 쉐어하우스와 협업이다. 지금부터 각 채널별로 그간 운영하면서 느꼈던 인사이트들을 갈무리해보겠다.- 카카오 1boon, "카드 뉴스에서 벗어나 더 모바일 친화적인 콘텐츠를 만들어보자!"카카오 1boon 채널을 운영해야겠다 생각하게 된 계기는 전철에서 사람들이 무엇을 자주 보나~ 관찰을 하면서부터였다.나조차도 스마트폰 사용 습관을 돌아보면 페이스북을 가장 먼저 보고 ~ 재미가 없어질 때는 친구들과 카톡으로 대화를 하다가, 채팅 탭 옆에 있는 [ 채널 ]로 들어가 재미있는 콘텐츠들이 무엇이 있나 보곤 하는데다른 사람들도 카카오톡 [ 채널 ]에 올라오는 다양한 콘텐츠를 보고 공유하는 것 같아 '이곳에 콘텐츠를 올리는 방법을 찾아야겠다 '라는 생각을 하게 되면서 1boon 채널 운영을 고려하게 되었다.1boon을 운영한 지는 현재 약 2달, 포스팅 수는 17개 정도 되는데, 그중 가장 잘 되었던 콘텐츠는 <자기소개서에 절대로 쓰면 안 되는 말 7가지>였다. 이 콘텐츠는 약 10만 명이 보았는데, 다른 콘텐츠들은 생각보다 조회수가 높지 못했다.그 원인은 아무래도 1boon이 카카오 담당자가 pick 해주는 콘텐츠만 카카오 [ 채널 ] 또는 1boon 메인에 노출되기 때문인 것으로 보인다.페이스북 페이지처럼 따로 구독하거나 팔로우할 수 있는 채널이 아니기 때문에 고정적으로 조회수가 꾸준히 나오기는 힘든 것그럼에도 불구하고 1boon의 장점이 무엇이 있나?라고 물어본다면 앞서 말한 것처럼 기존에 갖고 있던 페이스북이나 블로그 검색 바깥에 있는 잠재 고객들과 접점을 만들 수 있다는 특징을 들 수 있다.'카카오톡을 쓰는 사람들'이 [ 채널 ] 탭에 노출되어 있는 1boon 콘텐츠를 볼 텐데, 이 '카카오톡을 쓰는 사람들'의 모수가 어마어마함은 두 말하면 입 아프지 않은가그리고 카드 뉴스에서 벗어나 다양한 유형의 모바일 친화적 콘텐츠를 만들 수 있도록 다양한 콘텐츠 포맷을 제공한다.예를 들면 위 사진 중 왼쪽, 맞춤법 콘텐츠 같은 경우에는 퀴즈 형식인데 [ 정답 확인하러 가기 ] 구역을 클릭하면 이미지가 뒤집어져 정답을 볼 수 있는 기능을 적용했다.사진 중 오른쪽, 블라인드 채용과 관련된 콘텐츠는 카카오에서 사용 가능한 저작권을 가지고 있는 뉴스 기사들을 직접 인용해 콘텐츠를 만들었다.이처럼 포토 슬라이드 기능, 투표 기능 등 기존의 카드 뉴스 형태에서 벗어난 새로운 유형의 콘텐츠를 만들 수 있도록 지원하고 있다는 점,그리고 1boon 콘텐츠에 카카오에서 라이선스를 가지고 있는 기사, 움짤, 카카오 이모티콘, 카카오 TV, 카카오 뮤직 등을 자유롭게 쓸 수 있다는 점은 콘텐츠를 만들어야 하는 입장에서 모바일 친화적인 크리에이티브를 다양하게 시험해볼 수 있는 좋은 환경이라는 장점이 있다.- 카카오 플러스친구, "이게 의미가 있나? 싶었는데 의미가 있더라"사실 우리 서비스는 쇼핑몰도 아니고 세일이 있다거나 카카오 플친으로 CS를 해야 할 일이 많거나 하지는 않다.그래서 오래전에 플친을 만들어놓고 종종 오는 메시지에 응답하는 정도로 사용하고 있었는데, 이번에 1boon 채널을 개설하면서 본격적으로 운영을 해보았다.처음에는 1boon과 연계해서 1boon 채널에 발행된 포스팅을 플러스 친구에게도 푸쉬해줘서 두 채널 간의 연계성을 강화하는 방식으로 가려고 했다.거의 하나의 채널이라 생각하고 있었는데, 막상 운영을 해보니 그렇지 않았다.일단 이렇게 카드 뉴스 형식으로 콘텐츠를 제작하고 사이트로 직접 유입을 유도해보았는데, 생각보다 반응이 좋았다.카드를 개별적으로 클릭해 보는 조회수만 7천 이상인 포스팅도 있었고, 실제 클릭까지 이어지는 건수도 평균 100~200은 발생하였다.카카오 플친의 이런 반응을 긍정적으로 생각하는 이유는 플러스 친구는 광고를 해서 모수를 늘릴 수 없는 구조라는 특징 때문이다.다시 말해, 카카오 플친은 유저가 플친 채널을 확인하고 본인에게 유용할 것 같다고 생각하면 친구로 등록해서 카카오톡을 통해 계속 소식을 받아보게 되는데,이렇게 자발적으로 친구 등록을 해놓은 사람들이 위와 같은 반응을 보인다는 것이기 때문에 의미가 있고 계속 운영해 볼만한 채널이란 생각을 하게 되었다.또한, 카카오 플친이 과연 단일 채널로서 얼만큼 효과가 있을까? 에 대한 측면에서도 긍정적으로 생각하게 되었는데 그 이유는 위 맞춤법 포스팅의 반응 때문이었다.이 콘텐츠는 사실 별도로 포스팅을 제작한 것이 아니다. 1boon에 발행했던 맞춤법 포스팅을 공유했을 뿐인데, 플친 채널 안에서 많이 공유가 되면서 조회수가 7만 회 이상이 나왔다.  (1boon에 올린 원래 포스팅보다 더 뜨거운 반응..;; )이것 때문에 1boon과 플친은 별도의 채널로 생각하게 되었다.두 채널 간의 연계는 확실히 쉬운 편이지만, 1boon에서 터졌던 게 플친에서는 반응이 미미할 수도 있고, 오히려 1boon에서 평범했던 포스팅이 플친에서는 터질 수도 있다는 거왜 그렇게 몇몇 브랜드에서 플친 운영에 목숨을 거는지 알겠더라, 마냥 무시할 채널은 아니다.- 쉐어하우스는 "콘텐츠의 마중물, 물꼬를 틔우다"카카오 채널 운영 외에 새롭게 시작한 게 또 하나 있다. 바로 " 쉐어하우스 " 의 하우스메이트가 된 것!아시는 분들이 더 많겠지만, 쉐어하우스는 일상생활에 필요한 각종 노하우에 대한 콘텐츠를 만들거나 공유해주는 서비스인데, 여기에 우리도 자기소개서 쓰는 노하우를 공유하는 일원으로 함께하게 되었다.콘텐츠를 올린 게 6개밖에 없어서 내세울 성과는 아직 없지만, 쉐어하우스는 우리가 가지고 있지 않은 채널로서의 파워가 있어서 시너지를 기대하고 있다.쉐어하우스와의 협업은 우리가 콘텐츠를 올리면 그것을 검토 후에 쉐어하우스 하우스 메이트 블로그에 올려주시고, 쉐어하우스 페이스북에도 한 번 더 포스팅해주는 형태로 진행된다.또한 쉐하가 가지고 있는 네트워크를 활용하여 한국일보에도 한 번 더 올라가게 되는데 이것이야 말로 우리가 할 수 없는 영역이므로 굉장히 의미 있다고 보는 부분 중 하나다.이런 것까지 해주실 줄 몰랐는데 개인적으로 정말 고마웠던 서비스였다 :)또 하나는 동영상 제작 측면에서 기대하는 바가 있다.우리는 내부적으로 영상을 만들 여력이 안 되어서 못 만들어 아쉬운데, 쉐어하우스는 영상에도 특화되어 있는 매체이니 향후에 함께 콘텐츠를 만든다던가 우리 브랜드와 성격이 맞는 영상에 한해 공유를 받는 등의 방법을 통해 윈윈 할 수도 있겠다.위 동영상은 쉐어하우스에서 취업 준비생들을 위해 만들었던 동영상을 공유받아 우리 채널에 포스팅했던 사례로 조회 수만 1만 회 이상이 되어서 좋은 반응을 얻었던 케이스이다.2. 콘텐츠 마케팅은 잘 되고 있나? "아직까지는 Soso.."그렇다면 기존에 운영하고 있었던 채널은 어떻게 되어 가고 있나, 새로운 시도도 좋지만 사실 기존의 것도 잘 유지하는 게 중요하지 않겠나그런 측면에서 현황에 대해 So-So라는 평을 내리고 싶다.이전에 나는 실제로 돈이 되는 콘텐츠 마케팅을 하고 싶다고 글을 쓴 적이 있는데, 그 이후로 실제 우리 광고 상품에 이메일 서비스 외에 SNS 콘텐츠 제작 부분도 추가되었다.그래서 이런저런 시도를 해봤었는데 현재까지 결과는 '잘 될 때도 있었고, 아닐 때도 있었다' 정도였다.- 콘텐츠 마케팅이 성공하려면... 광고주와 서비스의 유저 / 팬들의 fit이 가장 중요하다!콘텐츠 마케팅이란 비록 그것이 광고 의뢰를 받고 제작하게 된 콘텐츠일지라도 유저 혹은 팬들에게 유용한 형태로 재가공하여 그 가치를 전달해야 의미가 있다고 생각한다.그러한 차원에서 위의 포스코 인턴 채용 콘텐츠는 성공적이었던 사례다.사실 포스팅 문구도 가볍게 썼고, 포스팅 내용도 방학 동안 진행되는 포스코 인턴에 빨리 지원해봐라~라고 단순했다.그럼에도 불구하고 12만 명 이상에게 도달이 되었고 (오로지 이 콘텐츠만의 힘이라고는 볼 수 없지만) 우리 서비스 내에서 포스코 인턴 채용 자기소개서를 쓰는 친구들이 2천 명 이상이었다.우리 서비스의 특성상 단순히 제품을 홍보하는 내용의 광고만을 하는 것이 아니라 공채 지원에 유도하는 내용의 광고도 많이 하게 된다.이런 광고가 원하는 결과를 얻기 어려운 이유는 명확하다. '콘텐츠를 보고 -> 입사 지원'이라는 프로세스까지 이어져야 하기 때문.할인 혜택을 받는다던가 사전 예약을 한다던가의 수준이 아니라 '입사 지원'이라는 높은 허들이 있기 때문에 "콘텐츠 광고 효과를 봤다"라고 이야기하기가 힘든 경우가 많다.그럼에도 불구하고 광고주들은 콘텐츠 광고를 통하여 지원자들이 증가하는 것을 바라기 때문에 창업자의 스토리나 회사의 문화, 직원들의 보이스 등을 담는 방식으로 콘텐츠들을 새롭게 개발하고 있다.정말 정말 쉽지만은 않지만, 이것도 잘 해내는 것이 콘텐츠 마케터로서의 역량이라 생각하며... -_- 나 자신과의 싸움 중이다.3. 앞으로는... 지금보다 더 깊게2017년 9월, 하반기 채용 시즌이 다가오고 있다.이 시즌을 맞이하면서, 어떻게 지낼 것인가를 생각해보면 '더 깊게' 가려고 노력하는 게 가장 중요할 것 같다.사용자들의 이야기도 지금보다 더 깊이 듣고, 이것을 더 깊이 있게 전달할 수 있도록 노력할 예정이다.그리고 콘텐츠 마케팅에서만 그치는 것이 아니라 서비스 기획 단과 함께 더 깊이 있게, 사용자 흐름이나 경험을 개선하는 데 집중하려고 한다.올해를 마무리하는 시점에서 이 주제에 대해 다시 한번 글을 쓸 때는 더 깊이 있는 인사이트들을 담길 기대 해보면서 이 글을 마친다.#앵커리어 #마케터 #마케팅 #마케팅팀 #인사이트 #꿀팁 #조언

Overview“JIRA하고, 자빠졌네!” 세종대왕은 확실히 개발자의 두뇌를 가지고 있었던 게 분명합니다. 먼 시대를 지나 오늘날 QA를 하는 저에게 응원을 해주시니 말입니다. 하지만 그는 틀렸습니다. 걱정과는 다르게 다행히 자빠지진 않았거든요. 지라(JIRA) 덕분입니다.갑자기 지라 이야기가 나와 당황하셨죠? 축하해주세요. 드디어 브랜디도 지라를 사용하게 되었답니다. (짝짝짝!) 지라 도입은 처음이라 세팅부터 쉽지 않았는데요. 이번 글은 눈물겨웠던 지라 세팅 과정과 브랜디의 이슈관리를 소개하겠습니다. 스크럼을 쓰면 좋은 점스크럼(Scrum)은 요구 사항 분석부터 하는 칸반(Kanban)보다 효율적입니다. 안드로이드와 iOS로도 나눠져 있고 업무를 짧게 반복하기 때문이죠. 스크럼에 적합한 워크플로우(Workflow)를 볼까요? 이것은 실제로 브랜디 R&D본부에서 사용하고 있기도 합니다. 스크럼에 적합한 워크플로우IN PROGRESS: 이슈나 개발 요건을 티켓으로 만들면 IN PROGRESS 상태가 됩니다. RESOLVED: 이슈나 개발 요건이 완료되면 RESOLVED 상태로 변경합니다.QA: QA가 필요한 개발 요건은 QA상태로 변경합니다.PASS: 이슈 또는 개발 요건이 수정되었거나 문제가 없다면 PASS 상태로 변경합니다.FAIL: 이슈 또는 개발 요건이 제대로 수정되지 않았거나 다른 이슈가 발생하면 FAIL 상태로 변경합니다.QA불필요: QA가 필요하지 않은 개발 요건은 QA불필요 상태로 변경합니다.DONE: 이슈를 해결했거나 개발을 완료하면 DONE 상태로 변경합니다CLOSE: 담당 팀장님이 이슈 확인 후 CLOSE 처리합니다. 예를 들어보겠습니다. 킥오프 서비스 회의를 하고, SB를 제작, 리뷰합니다. 이후에 디자인팀과 개발팀 일정을 공유하고 스크럼 마스터는 스프린트 주기를 책정하죠. 스프린트가 시작되면 개발자는 스토리 티켓을 작성하는데요. 개발이 끝나면 QA가 필요한 티켓은 테스트를 진행하고, QA가 종료되면 스프린트도 종료됩니다.Epic 티켓위의 이미지는 Epic 티켓입니다. Android, iOS, 이슈 등 모든 티켓은 Epic 안에서 관리합니다. 한 곳에서 한꺼번에 관리하기 때문에 히스토리 관리가 편하고, 진행 상황도 확인할 수 있습니다.티켓 생성개발팀의 티켓 생성입니다. 개발자는 SB를 보고 개발 티켓을 작성합니다. 개발 티켓 작성 후에 개발이 진행되며 QA 판단 여부를 체크해 QA 상태로 변경합니다. 변경된 티켓에 관한 QA가 진행되며 문제가 없으면 해당 티켓은 종료됩니다.이슈 생성다음은 이슈 생성입니다. 파악한 SB는 디자인 시안과 비교하며 개발이 된 Android, iOS 테스트 파일을 QA합니다. QA를 진행할 때 발생한 이슈는 지라 티켓으로 등록하여 이슈를 관리합니다. 모든 이슈 티켓 종료되면 해당 차수의 QA는 끝나고 마침내 상용에 배포합니다. 배포가 완료되면 필수 및 크리티컬 리그레이션 테스트가 진행됩니다. Conclusion실수는 항상 모든 것이 끝난 이후에 보이기 마련입니다. 수십 번 QA를 해도 보이지 않던 문제들이 상용에 올라간 이후부터 보이기 시작하죠. 스크럼은 이런 실수들을 가장 최소화할 수 있는 툴이 아닐까 생각합니다. 물론 아무리 좋은 툴을 써도 팀원들과 함께 뭉치는 것보다 중요한 것은 없겠죠. 다음 글은 자동화를 주제로 찾아뵙겠습니다. JIRA하고 자빠지지 않는 개발자가 됩시다!글김치영 대리 | R&D PM팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유 #JIRA

안녕하세요! 옐로모바일 사내기자 Y입니다. 멋진 옐로모바일 패밀리사의 서비스와 팀문화를 소개하는 옐.친.소! 올해 첫 옐친소 타자는 과연 어디일까요? 바로 옐로디지털마케팅(YDM)그룹에서 ‘손(핸드 ㅋㅋㅋ)’ 역할을 담당하고 있는 디지털 프로덕트 에이전시 ‘핸드스튜디오’입니다! 회사 가는 길이 너무나 설렌다는 핸드인들의 즐겁고 흥 넘치는 스토리를 김동훈 대표에게서 들어봤습니다. :)Y: 안녕하세요 김동훈 대표님! 옐로인들에게 핸드스튜디오를 간단히 소개 부탁 드립니다.안녕하세요! 이름에 ‘스튜디오’가 있어서 그런지 가끔 사진관인줄 알고 전화하시는 분들도 계신데요. ^^; 핸드스튜디오는 여느 서비스 스타트업처럼 기획, UI/UX 설계, 디자인, 개발 조직을 갖추고 있는 디지털 프로덕트 에이전시(Digital Product Agency) 입니다. 웹, 앱, 프로토타입, 연구과제, 마케팅 프로모션 등 가리지않고 다양한 협업 프로젝트들을 수행하고 있습니다. Y: 앜ㅋㅋㅋ사진관ㅋㅋㅋ 그럼 핸드스튜디오는 어떤 클라이언트들과 함께 하고 있나요?처음에는 공모전을 통해 유명한 S전자와 프로모션을 함께 했고요, 이후에 여러 노력을 통해 실력을 인정받아 내부에서 조금씩 조금씩 입소문으로 협업하는 부서들이 늘어왔습니다. 현재까지 약 24개 부서와 협업을 하고 있으며, 해외의 큰 기업들인 Amazon, Financial Times, National Geographic 등과 협업하기도 했습니다. 국내에서는 포털사, 방송사, 케이블, 이통사, 홈쇼핑 회사와도 작업을 해왔습니다. 광고회사들과 이벤트 프로모션을 같이 만들기도 했고요!Y: 포트폴리오가 굉장하네요! 옐로모바일/옐로디지털마케팅에는 언제, 어떤 연유로 합류하게 됐나요? 저희는 2015년 6월에 합류했어요. 합류 전에는 항상 어떻게 하면 더 많은 클라이언트들에게 우리 핸드스튜디오를 알리고, 새로운 협업을 할 수 있을지가 고민이었어요. 별도 영업팀 없이 주어지는 업무들 위주로 프로젝트를 진행했었거든요. 게다가 진행했던 프로젝트의 다수가 보안과 관련된 프로젝트였다보니, 당시 포트폴리오로 핸드스튜디오가 무엇을 잘 할 수 있는지 설명하기도 쉽지 않았던 것 같고요. 그래서 이미 업계에 잘 알려진 옐로모바일과 옐로디지털마케팅과 함께 하면 이러한 신규 사업처 발굴에 대한 갈증을 해소해 줄 수 있을 것이라고 생각했습니다.Y: 그럼 이제는 함께해서 좋은 점이 많이 있나요? :) 우선 좋은 점은, 이상혁 대표님, 이상석 대표님 모두 훈남이시고요. (저희 핸드스튜디오입니다!ㅋㅋ) 언제나 믿어 주시고 응원해주셔서 감사합니다.Y: 앗, 너무 대표님들을 의식하신 것 아닌가요?!ㅋㅋㅋㅋ 사실 YDM의 임직원분들도 너무 많은 부분을 챙겨주셔서 감사해요. 그리고 듬직한 가족사들이 있음에 언제나 함께 하고 있음에 마음이 든든합니다. 멋지게 달려가고 계신 모습들을 보며 ‘이정도면 됐어’ 라고 만족하지 않게끔 저희를 채찍질 하는 러닝메이트 인 것 같습니다. Y: 러닝메이트라는 표현 참 좋네요! :)음…사실 러닝메이트라고 하기엔 저희가 굉장히 시끄러운 집단입니다. 웃음소리 때문에 무려 위층에서 항의를 받았던 전력까지 있는데요. 유리 한 칸 사이로 고통받고 계신 5층 이모션 직원분들에게 이 자리를 빌어 다시 한번 사죄 드립니다. ㅠㅠ  Y: 항의받을 정도면 꽤 심각한데요?ㅋㅋㅋㅋ제가 최근에 가장 많이 하는 말은 ‘쉿’과 ‘조금만 조용히 합시다’ 입니다. 더 노력하겠습니다!!! Y: 기대해 보겠습니다! 그럼 구체적으로 옐로모바일 계열사와 협력한 사례가 있다면 공유해주세요~지난 한 해 동안 YDM 가족사인 이모션, 그리고 레코벨과 협업을 했습니다. 레코벨의 Optima 솔루션의 설계, 디자인, 프론트엔드 개발에 참여했고요, 이모션과는 파리바게트, 유플러스, 피자헛 등의 디자인, 개발 작업을 함께 했습니다. 서로 협력하며 많이 배우기도 하고 정말 든든했던 경험이었습니다.Y: 핸드스튜디오는 뛰어난 복지 조건으로 유명한데요, 특히 굉장히 유명한 ‘결혼하면 1000만 원 지급’ 복지가 탄생하게 된 배경이 있는지요?이 복지는 사실 제가 대표를 맡기 이전의 전 대표님이 만드신 건데요, 당시 직원 평균나이가 26살 정도였던 것으로 기억합니다. 미혼들이 많았고요. 결혼이 뭔가 모두에게 굉장한 숙제였고, 어린 나이들이다 보니 인생의 새로운 출발을 굉장히 축하하고 싶었던 마음이었을 것 같습니다. 가짜 아니에요~ 진짜로 줍니다!Y: 엇 그런데 이제는 결혼적령기이신 분들이 꽤 많아졌을 것 같은데요?이제는 평균연령이 29세에 도달했고요. 굉장한 현실로 다가오고 있습니다. (후덜덜..) 마치 천만원을 주기 위해 태어난 사람처럼 오늘도 열심히 일하고 있습니다..ㅠㅠㅋㅋㅋㅋㅋ Y: 또 자랑할 만한 사내문화나 복지혜택이 있다면 무엇이 있나요?5년째 매주하고 있는 카트라이더가 가장 자랑할만한 대표 문화인 것 같습니다. 작년부터는 시즌제로 운영하고 있어요. 매주 우승팀에겐 문화상품권을, 3개월 1시즌이 끝나면 시즌 우승자, 최다 점프, 최다 문화상품권 수상자, 최저 문화상품권 수상자에게 4대상을 수상합니다. Y: 직원분들 모두 카트라이터에 중독되신거 아니에요? ㅋㅋㅋㅋ심지어 점심시간마저 아껴서 근처에서 대충 먹고 뛰어와서 게임하는 열정을 모두가 가지고 있습니다. 이곳은 맛집이 넘치는 가로수길인데 말이죠. ㅎㅎ핸드인들에겐 점심보다 중요한 카트라이더 게임Y: 그 밖에도 자랑할만한 것 있으면 공유해주세요!식사, 간식, 책, 커피 같은 회사에서 일하며 필요한 건 회사에서 모두 지원하고 있습니다.월 1회는 미디어데이를 운영 중입니다. 옷 구매, 영화 관람, 보드 트립 등 그때 그때 테마에 맞게 나들이를 나가고 있습니다.Y: 핸드스튜디오에는 사내 동아리 종류도 굉장히 다양하다고 들었어요~5인이 모이면 동아리가 되는 동아리 정책이 있어요. 대표적으로 야매(야구관람), 볼사조기사단(볼링), 핸슐랭(미식), 책한사람들(독서), 전우협 신사지부(게임), 희내루(당구)가 있습니다. 애드쿠아도 볼링동아리가 있는 것으로 아는데, 내기 한판 어떠실지요? ㅎㅎ핸드스튜디오의 볼사조기사단Y: 저기.. 그럼 일은 언제 하시나요? (조심조심) ^^;;하하하… 당연히 이 모든 것들이 열심히 맡은 바 각자 자리에서 최선을 다하는 핸드인들의 노력이 있기 때문에 이뤄질 수 있는거죠. 겉으로 보기엔 이게 회사야 놀이터야 하시는 분들도 있으시겠지만, 업무 스트레스 없이 즐겁게 일하며 좋은 성과를 만들기 위해 또 그만큼 열심히 일하고 있습니다! Y: 업계에서 핸드스튜디오만의 강점을 뭐라고 생각하시나요?디지털 프로덕트와 관련하여 무엇이든 수행할 수 있는 유연한 능력이 아닐까 싶습니다. 사실 그간 해왔던 일 중 하나도 쉽고 무난한 작업이 없었습니다. 스마트TV나 IoT 개념을 시장에서 가장 먼저 다루기 시작했고, 신제품의 프로토타이핑, 다양한 선행 연구과제 등 시장에 나와있지 않았던 개념들에 대한 프로젝트가 많았어요. 덕분에 어떠한 과제도 옳은 답을 찾아가는 능력들이 배양된 것 같습니다. 다만 보안에 묶여 ‘이런 것도 했어!’ 라고 말하지 못함에 아쉬움이 항상 있습니다. 이번 옐친소 인터뷰를 통해 살짝이라도 공개할 수 있으니 뿌듯하네요.  Y: 핸드스튜디오의 인재상은 무엇인가요?현재 함께하고 있는 팀원들과 잘 어울릴 수 있는 열린 마음과, 신뢰할 만한 인성과, 책임감이있는 사람이면 좋겠습니다. 함께함이 자랑스러울 만한 실력까지 갖추면 더할 나위 없겠지요! 사실 사내에 규율, 규칙이 있기보다는 서로 신뢰와 약속으로 지켜지고 있는 것들이 많습니다. 문화와 팀워크를 깨지 않고, 더 굳건하게 할 수 있는 사람! 이것이 저희가 바라는 인재상입니다.  Y: 음..바라는게 좀 많으신데요? ㅋㅋㅋ 역시 신의 직장에 들어가려면 쉽지 않군요 ㅠㅠ신의 직장이라뇨. 전혀 그렇지 않습니다. ㅎㅎ 우리 핸드인들이 어딜가도 부족하지 않을만큼다 뛰어나기는 하지만(자랑자랑), 그렇다고 채용 시에 학력, 스펙, 토익 점수 등의 일반적인 지표를 기준으로 구성원을 채용하지는 않고 있습니다. 어버이날 부모님께 감사편지 쓰는 핸드인들Y: 올해 사업은 주로 어느 쪽에 주력할 계획이신가요?기존 클라이언트와 새로운 클라이언트의 비중을 6:4 정도로 맞추는 것을 목표로 하고 있습니다. 그를 위해서 올해는 가족사들과 많은 협업을 하였으면 하고, 함께 멋진 결과물들을 만들 수 있었으면 좋겠습니다. Y: 핸드스튜디오가 올해 이루고자 하는 것이 있다면?두 가지가 있어요. 첫 번째는 직원들 근무 만족도와 성취도 증가에요. 핸드스튜디오는 연 2회 업무, 문화/복지, 리더십을 주제로 내부 익명평가를 진행하고 있는데요, 작년 여름에 6.25점을 받고, 7점을 목표로 살아왔는데 겨울에는 8점을 받았습니다. 올해 첫 목표는 여름에 8.1점 이상을 받는 거에요.Y: 두 번째는요?퇴사율입니다. 2015년 초반에 회사의 목표는 ‘퇴사자 5명 이하’ 였습니다. 퇴사나 이직은 무언가의 결핍으로 생겨나는 것이라고 생각하는데, 그 결핍들을 줄여야 더 좋은 회사가 될 수 있을 것이라 생각했습니다. 그 목표를 드디어 작년에 이뤘고요! Y: 와, 축하드립니다! 그렇다면 올해 목표치는요?달성한 김에 올해는 4명 이하로 목표치를 잡아 보았습니다. 핸드는 개개인의 능력의 합으로 이뤄져 있기 때문에, 합에서 마이너스가 생기지 않게 하는게 가장 중요한 목표라 생각합니다. 함께 멀리 갈 수 있는 회사를 견고히 만드는 것이 목표입니다. 더 좋은 대우를 받고, 즐겁게 살기 위해서 함께 더 열심을 쏟아, 많은 것을 이뤄냈음 합니다.Y: 마지막으로 모든 옐로 가족들에게 한 말씀 부탁 드립니다~옐로모바일 가족 여러분 모두 새해 복 많이 받으시고, 물질적, 정신적 기쁨이 충만한 한 해가 되시기를 응원하겠습니다. 핸드스튜디오의 앞으로의 행보에도 많은 관심과 응원을 부탁드리겠습니다. 모두 파이팅입니다! :) 

올해 1월, Google Analytics(이하 GA)에서 Audience 카테고리에 Cohort Analysis(코호트 분석)라는 리포트가 추가되었습니다. 그런데 UI가 늘 보던 리포트와 달리 독특해서 이 리포트는 어떻게 데이터를 보고 해석해야 할지 막막하기까지 합니다. 일단 리포트보다 용어조차 생소한 코호트에 대한 이해가 필요합니다.( GA > Audience > Cohort Analysis Report )코호트 분석이란코호트 : 특정 기간에 특정의 경험을 공유한 사람들의 집합http://en.Wikipedia.org/wiki/Cohort_(statistics)코호트 분석 : 특정 기간에 특정의 경험을 공유한 집단간의 행동패턴을 비교/분석http://en.Wikipedia.org/wiki/Cohort_analysis리포트 조회 방법모바일 앱 분석에서 가장 많이 사용하는 코호트 분석은 같은 기간에 앱 설치를 경험한 사용자 그룹이 시간이 지남에 따라 앱의 꾸준한 사용여부(Retention)를 분석하는 것입니다. 앱은 설치보다 지속적인 재사용성이 앱 비즈니스를 좌우하기 때문입니다.( WISETRACKER > 방문행동 > Retention 리포트 )A열은 특정 기간에 앱을 설치한 사용자의 집단이며, +기간이 표기된 B열은 설치 시점으로부터 재사용율/삭제율을 제공하고 있는데, 여기서 데이터를 해석하기 위해선 데이터를 수직적으로 바라봐야 합니다.위 데이터로 예를 들면 다음과 같습니다.A : 2016년 12월 1일부터 5일까지 설치수가 꾸준히 증가하고 있다.B : 설치 후 하루가 지난 뒤 재사용률은 지속적으로 떨어지고 있고 오히려 삭제율이 증가하고 있다.코호트 분석 왜 필요한가첫째, 비즈니스 상황을 알 수 있다.위 그림의 데이터를 단순 앱 설치 추세 리포트로 보았다고 생각해봅시다. 설치수가 꾸준히 증가하고 있기 때문에 “우리 앱의 시장반응이 좋구나”라는 1차원적인 결과만 얻었을 것입니다. 그러나 코호트 분석을 통해 신규 고객 획득은 잘 이루어지고 있으나, 고객이 된 이후의 사용성이 떨어지고 앱을 삭제하는 비율이 점점 증가하고 있다는 사실을 인지함으로, 마케팅은 밑 빠진 독에 물 붓는 격이니 보다 고객관리/최적화에 먼저 집중해야 함을 알 수 있습니다. 이처럼 현재의 상황을 정확히 이해해야 더 나은 의사결정을 할 수 있습니다.둘째, 깊은 마케팅 인사이트 얻을 수 있다.보통 모바일 마케팅의 성과 지표로 얻을 수 있는 건 클릭수, 설치수 정도 입니다. 그러나 이것만으로 가치 채널을 도출하고 마케팅 전략을 수립하기엔 데이터가 부족한 것이 사실입니다. 같은 채널이라 하더라도 시점에 따라 게재하는 광고 내용도 다를 수 있고, 설치수가 많더라도 체리피커들 때문에 설치 후 바로 삭제하는(광고비만 날리는..) 비율도 꽤 높기 때문에 설치 이후의 데이터가 꼭 필요합니다. 코호트 분석은 특히 모바일 앱 기반의 스타트업에게 매우 중요한 분석기법으로, 사업 단계마다 우리가 잘하고 있는지 여부를 판단하고 더 나은 의사결정을 돕는 중요한 나침반 역할을 할 것입니다. * WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #데이터분석 #서비스소개 #코호트분석

#페이스북 #마케팅 #강의 #뒷북후기 #퇴사학교 #콘텐츠 #콘텐츠마케팅 #콘텐츠마케터 #마케터"내가 뭐라고 강의를 해?"강의를 처음 맡았을 때는 그렇게 생각했다. 그래서 더더욱 내가 잘 알아서 누군가를 가르치는 것이 아니라, 그냥 편하게 내가 1-2년 남짓이나마, 경험하고 배운 것들을 나눠줘야겠다 생각하려했다.대학생, 실무 마케터, 창업자 등등에게 몇 차례 강의를 하다보니 배우는 게 참 많다.1.내가 너무나도 당연했던 것들이 그 누군가에게는 완전히 신세계일 수 있구나.때론 꽉 막혀있던 부분을 뻥 뚫어주는 인사이트가 될 수도 있고, 나도 몰랐던 나를 발견하게 하는 새로운 경험이 될 수도, 작지만 새로운 자극이 될 수도 있겠구나.2.그리고 내가 당연하다고 생각한 것들은 어쩌면 정말 당연한 것이 아니구나. 내가 '알고 있다고' 생각한 것들이 나의 언어와 그림, 체계로 표현되지 않으면 이건 진짜 알고 있는 것이 아니구나. 그동안 '배웠다'라고 생각한 것들은 진정 내 것이 아니었구나. 그리고 내가 당연하다고 생각하고 있었지만, 정작 나는 실무에서 정말 실행해본 적이 있는가.3."나는 아직 부족한데... 준비가 다 되면 해야지..."라고 생각하면 뭐든지 평생 할 수 없겠구나. 세상엔 다 준비되고 완벽한 건 없으니까. 내가 지금껏 쌓아온 경험들은 어쨌든 세상에서 오직 '나'만이 경험해 본 시간들이다. 그러니 나의 경험, 시간들은 이미 그 자체만으로 남들에겐 새로운 자극이 될 수 있고, 가치있을 수 있다는 것.예를 들면 콘텐츠 100만 도달. 어떤 콘텐츠 마케터에겐 당연할 수 있지만 누군가에겐 100만 도달이라는 건 생각조차 못해봤을 수 있는 것이다.4.강의라는 것은 여러모로 참 나에게 감사한 기회가 되는 것 같다 :) 스타강사를 꿈꾸지도 않고 전업 강사도 생각은 없지만..어떤 브랜드/서비스/ 사람 성장하게끔 만드는 것을 즐거워하는 나에게는 강의를 준비하는 시간이나 하는 시간이나 끝난 뒤 회고하는 시간이나, 모든 순간들이 참 의미있는 시간인 것 같다 :)-P.s) 그런 의미에서 디지털 마케팅 잘하는 분(..)께 마니 좀 배우고 싶다....ㅠ.ㅠ

안녕하세요 "사운들리"입니다 :)오늘은 사운들리의 코드 품질 관리에 대해 이야기 해보려 합니다.몇몇 개발자에게는 지루하고 악몽같은 이야기일 수 있겠네요.제 경우에는 예전에는 이런 품질이라는 단어를 멀리했지만 결국 제가 작성한 코드에 발목을 많이 잡히다 보니, 자연스레 관심을 갖게 되었습니다.일단, 어떤 소프트웨어가 좋은 품질의 소프트웨어일까요?좋은 품질이란? 책에 나올법한 내용을 보면, 아래와 같은 항목을 토대로 소프트웨어 품질을 판단한다고 합니다.ISO/IEC 9126 : Software engineering - Product qualityFunctionality: 명시된 요구사항을 잘 충족했는지Reliability: 명시된 조건과 시간 아래에서 일정 성능을 유지 하는지Usability: 사용하기 위해 어느정도의 노력과 자원이 필요한지Efficiency: 소모 자원과 성능간의 효율Maintainability: 수정하기 위해 어느정도의 노력이 필요한지Portability: 다른 환경에서도 사용 할수 있는지출처: https://en.wikipedia.org/wiki/ISO/IEC_9126 뭔가 복잡해 보이지만, 결국 개발자라면 위의 항목은 누구나 추구하게 되는 가치라고 생각 합니다.그런데 말입니다. 이런 좋은 내용을 마음 속으로만 간직한 채 코드를 작성하면 정말 좋은 소프트웨어를 만들 수 있을까요? 저는 객관적인 방법으로 코드를 평가한다면 좋은 피드백이 될 것이라고 생각합니다. (물론 이 성적표를 남에게 보여주는 것과는 다른 문제에요 ㅎㅎ)어떻게 품질을 체크하는가 소프트웨어의 품질을 체크하는 데에 다양한 방법과 툴이 제시되고 있는데요, 저는 크게 두 가지로 분류 해보겠습니다.유저 입장의 품질: 유저의 요구사항에 맞는 소프트웨어인지 체크개발자 입장의 품질: 내가 지금 이 코드를 의도한 대로 잘 작성하고 있는지 체크 유저 입장의 품질은 언급하지 않아도 중요함을 누구나 알고 있습니다. 이 부분이 만족이 되지 않으면 제품이 아니죠! 그래서 저는 개발자 입장에서 스스로 챙길수 있는 품질을 사운들리는 어떻게 챙겨보고 있는 지 이야기 해보도록 하겠습니다. 실은 제가 개발자 입니다 ㅎㅎ사운들리 개발자의 코드는 아래와 같이 흘러갑니다.<그림1> 사운들리 코드 개발상의 품질 관리 순서도간단히 각 항목을 훑어 보겠습니다.Local Machine 각자 갖고 있는 맥북으로, 다양한 IDE를 사용해 코딩합니다. 그리고 git 을 이용해 commit 하고, github 에 push 하죠.Github push 된 수정사항은 pull request 를 통해 동료에게 알려집니다. 이후 코드리뷰를 통해 merge 하게 됩니다. 코드리뷰는 많은 사람들에 의해 그 중요성이 부각되고 있습니다. 사운들리는 같은 모듈을 만드는 개발자끼리, 그리고 다른 모듈에 영향을 주는 코드일 경우에는 해당 모듈의 개발자도 리뷰를 합니다. 코드리뷰를 통해 다른 사람이 어떤 기능을 작성했는지 보고, 오류도 찾고, 더 좋은 방법이 있으면 공유도 하고, 칭찬도 하고, 훈수도 두고 합니다. 참고로 사운들리는 git-flow 정책에 따라 git branch를 운영하고 있습니다.Jenkins  Github 에 commit 이 등록되면 Jenkins 는 자동으로 빌드를 시작 합니다. Jenkins 는 단순 빌드 성공 실패를 떠나서, 코드 품질에 대한 몇가지 report 를 발생 시킵니다. 아래에서 좀더 자세히 다뤄보겠습니다.SonarQube Jenkins 에서 빌드하면서 SonarQube 에 포함된 분석 기능을 사용하게 됩니다.그렇다면, 코드 품질의 지표는 무엇일까요?Jenkins가 발생시키는 레포트를 통해서 알 수 있는 내용은 아래와 같습니다.코딩 스타일 체크 결과: 작성된 코드가 미리 정의된 코딩 스타일에 맞게 작성되어 있는지?Unit Test 결과: 유닛 테스트 결과 (당연히 전부 pass 해야겠죠)Test code coverage 결과: 테스트 코드가 전체 코드의 몇 % 를 커버 하고 있는지 (우리의 최종목표는.. 60%.. 덜덜덜)정적 분석 결과: 코드를 실행하지는 않지만, 코드 그 자체에서 발생할 수 있는 결함을 찾아줍니다. 이 네 가지 레포트는 객관적 수치를 나타내주기 때문에 일종의 코드 품질 지표로 삼을 수 있습니다. 물론 이 지표만 잘 관리 했다고 해서 좋은 코드를 작성했다고 말할 수는 없습니다. 다만 좋은 코드를 작성하기 위한 기초 중의 기초라고 볼 수 있겠죠 :)품질 체크를 위한 툴(tool)은 개발 언어에 따라 다를 수 있습니다. 사운들리에서는 다양한 언어로 소프트웨어가 작성되어 있습니다. 따라서 언어마다 위의 결과를 얻기 위해서 서로 다른 툴을 사용하고 있습니다. AndroidJavaJavascriptC/C++코딩 스타일checkstylecheckstyle jshintcppcheckUnit testjunitjunitmochagoogletestCode coveragejacococoberturamocha-covgcov정적 분석sonarqubesonarqube sonarqubecppcheck 각 개발자는 위의 네 가지 결과를 얻기 위해서 빌드 시스템에 툴을 포함하여 개발하고 있습니다. 제가 주로 개발하고 있는 java 언어에 해당하는 툴들을 좀 더 자세히 살펴보겠습니다.checkstyle코딩 스타일을 체크 해줍니다. xml 파일로 미리 정의 되어있고요. 매번 빌드할때마다 스타일이 틀린것을 지적해 줍니다.코딩 스타일은 중요합니다. 같이 개발하는 개발자와 코딩 스타일이 같다면 마치 내가 작성한 코드처럼 쉽게 읽을 수 있죠.junitjunit 은 자바 유닛 테스트 프레임워크 입니다. 유닛 테스트 코드를 편하게 작성하게 해주고, 쉽게 테스트 결과를 볼 수 있습니다.유닛 테스트 코드를 작성하면 내가 작성한 모듈을 작은 단위로 테스트 해서, 작은 로직에서 발생하는 시시콜콜한 문제를 방지 할 수 있습니다. 테스트 코드를 작성해서 검증한 부분은 스스로도 신뢰가 갑니다.기능 수정간에 유닛 테스트에서 fail 이 나는 경우가 발생하는데, 모르는 사이에 다른 모듈에 영향을 준 것을 알게 됩니다. 다른 모듈에 모르고 영향을 주게 되면 뒷처리가 어려워지잖아요~coberturacode coverage 를 계산해 주는 툴입니다.유닛 테스트 코드가 실행되면, 작성된 코드의 각 부분을 실행하게 됩니다. cobertura 는 이때 각 코드의 어느부분이 실행되었는지 확인해서 통계를 내줍니다.주로 line coverage / branch coverage 두 지표를 보는데요, line coverage 는 해당 라인이 한번이라도 실행 되면 check 되고, branch coverage 는 각 라인에 있는 조건문을 다 따로 check 합니다. 당연히 branch coverage 를 달성하는게 어렵겠죠?sonarqube소나큐브는 다양한 plug-in 을 통해서 정적 분석을 하고, 시각화를 해주는 툴입니다.사운들리는 주로 정적 분석 용도로만 소나큐브를 사용하고 있습니다. (지원하는 plug-in 을 보면 젠킨스와 기능이 겹치는 부분이 있습니다.)정적분석으로 실제 문제가 되는 부분을 찾는 경우도 있고, minor 한 부분에 대한 지적을 하는 경우도 있습니다. 그러나 이런 minor 한 부분도 꼼꼼하게 잘 챙겨야 좋은 개발자가 된다고 믿고 있습니다.마치며 여기까지 사운들리의 코드 품질 관리에 대해 이야기 해보았습니다. 품질 관리를 해보신 분은 아시겠지만, 이런 툴을 쓰다보면 항상 행복하게 코드 품질을 관리할 수는 없습니다. 매달 세워놓은 목표를 달성하기 위해서 뼈를 깎는 노력으로 테스트 코드를 작성해야 되고, 당장 기능 수정해서 배포해야 되는데, 작성해 둔 테스트 케이스가 Fail 되어 말썽을 부릴 수도 있습니다. 그렇지만 객관적 기준으로 코드 품질을 관리하다보면 어느샌가 큰 노력없이 좋은 코드를 작성하는 개발자가 되지 않을까 생각해 봅니다. 코드 졸면서 막 짜도 style warning 0건/ 정적분석 오류없음 / 테스트 코드 기본 탑재 뭐 이런 개발자 말입니다 ㅎㅎ 다른 개발자분들은 어떻게 자신이 작성한 코드의 품질을 관리하고 있는지 궁금하네요.알고 계신 좋은 방법이 있다면 언제든지 공유 부탁드리겠습니다~!#사운들리 #개발자 #개발 #인사이트 #조언 #개발후기 #후기

미디언스에 동료들(미.인.)과 함께한지 1년이 지났습니다. 지난 1년간 참 많은 성장을 했습니다. 매출 증가보다 더 중요한것은 미.인.과 미디언스 그리고 함께하는 동료들간의 믿음이 커진것입니다. 1년간 미.인.들과 비전을 공유하고 미션을 해결하며 핵심 가치를 만들어가면서 서로에 대한 믿음, 자신에 대한 믿음, 우리 업과 일에 대한 '믿음'이 "확신"으로 성장했습니다. 미.인. 개인의 꿈을 미디언스는 응원합니다. 그리고 그 꿈을 미디언스에서 이룰수 있도록 최선을 다해 도우며 함께 성장할 것입니다. 미디언스는 꿈을 꾸는 사람들이, 그 꿈을 이룰수 있다는 확신을 가지고, 그 꿈을 이루는 방법을 찾고 실행해, 그 꿈을 현실로 만드는 회사로 성장하겠습니다. 지난 1년간 함께 꿈을 이야기하고, 꿈을 이루어가고 있는 미.인.들 정말 고맙고 감사합니다. 더불어, 미디언스의 성장에 도움주신 많은 분들에게도 진심을 다해 감사드립니다. 앞으로 꿈꾸는 사람들이 넘쳐나는 미디언스와 함께~ 꿈 같은일 , 꿈 꾸는일 같이 하시죠 ! 그 꿈 미디언스에서 이루어 드리겠습니다! Special Thanks To모르는것을 물어보면 언제나 대답해주시는 만물박사 풀스택 개발자 임지훈 리더님 감사합니다. 큰 누나처럼 미디언스의 궂은일 힘든일 맡아주시는 기획자 임현진 리더님 감사합니다. 부처같은 맨탈로 이슈가 났을때마다 만사형통으로 해결해주시는 AE 장동호리더님 감사합니다. 언제나 긍정적 마인드로 멀티플레이어처럼 활약해주시는 퍼포먼스 마케터 이호연 매니저님 감사합니다. 미디언스의 활력소이자 곧 새댁 파워 인플루언서가 되실 AE 최한별 플래너님 감사합니다. 소리없이 강한 그리고 엄청난 퍼포먼스를 만들어가고있는 개발자 최미리님 감사합니다. 기획및 운영 그리고 중국어, 영어 더불어 동료들도 꼼꼼히 챙기는 마음까지 깊은 현승아 플래너님 감사합니다. 알바에서 인턴 그리고 정직원 그 다음은 미디언스 대표자리를 노리는 조윤상 플래너님 감사합니다. 늘 생기있고 사업에 대한 꿈을 갖고 달려 곧 랜인지로버 오너 드라이버가 되실 박수연 플래너님 감사합니다. 영업 열혈 청년으로 단신으로 광고주 미팅을 하며 신화를 만들고 있는 방승환 플래너님 감사합니다. 플랫폼 디자인, 로고제작, 명함제작, 굿즈제작, 카드뉴스제작.....세상의 모든 디자인을 디자인하고 계신 성현지 디자이너님 감사합니다. 짧은 기간 많은 캠페인을 진행하며 스스로 인사이트를 만들고, 동료들에게 많은 질문을 하며 폭풍 성장하고 있는 정혜선 플래너님 감사합니다.#미디언스 #기업문화 #조직문화 #팀원자랑 #팀소개