와탭랩스는 SaaS 기반의 IT 모니터링 서비스로도 사용할 수 있지만 On-Premises 솔루션으로도 제공되기 때문에 고객과 대화할 때 SaaS와 On-Premises의 장단점에 대한 답을 드려야 할 때가 많습니다.어떻게 비교해야 할까. SaaS와 On-Premises를 비교하기 위해서는 도입 프로세스에서 운영까지의 지속되는 과정에서의 장단점들을 알아봐야 합니다. 많은 고객들이 SaaS를 설명드릴 때, TCO를 기반으로 하는 가격 비교를 하지만 이는 일부일 뿐입니다. Total cost of ownership (TCO) is a financial estimate intended to help buyers and owners determine the direct and indirect costs of a product or system. It is a management accounting concept that can be used in full cost accounting or even ecological economics where it includes social costs.----TCO시스템 또는 제품 구매시에 들어가는 모든 직간접 비용을 의미. 구매비용에서 운영비용은 물론 사회적 비용까지  모두 포함.왜 SaaS로 넘어가야 하나요?현대 조직은 효율적인 비용 구조에 대한 지속적인 압박을 받고 있습니다. 그렇기 때문에 많은 기업들이 IT 기반의 효율적인 기업 관리 시스템을 갖추어 나갔지만 역설적으로 IT 시스템들은 여전히 비싼 가격에 대규모 도입 방식을 사용해 왔습니다. 하지만 클라우드 시장이 만들어지면서 SaaS 시장이 빠르게 발전하고 있습니다. SaaS(Software-as-a- Service)는 공급자가 원격에서 솔루션을 제공하여 관리하는 인터넷 기반의 서비스를 의미합니다. 초기 SMB시장을 위주로 확장을 하던 SaaS 기반의 서비스는 이제 소규만을 위한 서비스가 아닙니다. 소규모 스타트업 뿐만이 아니라 많은 엔터프라이즈 기업들이 SaaS 서비스를 사용하고 있습니다. 낮은 도입 비용SaaS는 On-Premises 방식에 비해 도입 비용이 현저히 낮습니다. 기존 On-Premises의 비용의 많은 부분들이 채널, 컨설팅, 영업 관리 비용이 포함된 금액이였지만 SaaS 방식의 서비스들은 해당 솔루션 기능에 대한 비용만을 청구합니다. 더 이상 부가적인 비용 지출을 하지 않아도 됩니다. 또한 SaaS 기반의 서비스는 실무자가 직접 도입하고 사용해 볼 수 있기 때문에  POC없이 기업에 도입하고 구매 여부를 진행 할 수 있습니다.  POC (Proof Of Concept)기존에 시장에서 사용돼지 않던, 신기술을 프로젝트에 도입하기에 앞서, 검증하기 위한 목적으로 사용. 사업과 관계가 약간은 동떨어진 기술 검토를 위한 프로젝트고객사에서 하고, 업무는 아주 간단한 것을 수반. 신기술 여부는 중요치 않음낮은 TCOSaaS 솔루션은 유지보수 비용 부담이 없습니다. 업데이트에 요금을 부과하지 않으며 대규모 시스템 업데이트로 인한 부담도 존재하지 않습니다. 소프트웨어 구매시 발생하는 하드웨어 구매 비용으로부터 자유로우며 하드웨어를 유지 보수하거나 업데이트 해야 할 일도 없습니다. SaaS 솔루션은 구매비용(CAPEX) 운영비용(OPEX) 모두 절감할 수 있습니다. CAPEX미래의 이윤 창출을 위해 지출한 비용. 기업이 고정자산을 구매하거나, 유효수명이 당회계연도를 초과하는 기존의 고정자산 투자에 돈을사용할 때 발생.회사가 장비, 토지, 건물 등의 물질자산을 구입하거나 유지, 보수할 때 사용되는 비용.OPEX업무지출 또는 운영비용이라고도 하며 갖춰진 설비를 운영하는 데 드는 제반 비용을 의미. OPEX는 인건비, 재료비, 수선유지비와 같은 직접 비용과 제세공과금 등의 간접 비용으로 구성되어 있으며 통상 CAPEX와 함께 대조적으로 많이 쓰이는 용어.빠른 출시SaaS 솔루션은 이미 시장에 배포되는 과정에서 테스트가 완료되어 있습니다. 처음부터 적용하기가 쉬우며 업데이트도 번거롭지 않습니다. 기업은 최신 서비스를 바로 적용하여 더 높은 ROI를 만들어 낼 수 있습니다. 사용량 기반의 과금SaaS는 사용량 단위의 유동적인 과금이 가능합니다. 이는 반대로 대규모 도입후에 시스템이 줄어들게 되더라도 과금이 같이 줄어드는 장점을 가지고 있습니다. 낮은 위험도SaaS는 사용랑 기반의 과금과 쉬운 도입을 제공하기 때문에 On-Promises에 비해 솔루션 변경에 대한 위험도가 낮습니다. 솔루션 사용하기 위해 인프라스트럭처를 도입하지 않기  때문에 해지시에 사용하지 않는 인프라스트럭처가 존재할 위험에서도 빠져나갈 수 있습니다. SaaS 솔루션 도입시 고민해야 할 점SaaS 솔루션이 장점이 많은 구조이긴 하지만 아래와 같이 도입시 고민해야 하는 것들이 있습니다. 인터넷 의존성외부망을 열수 없는 환경에서는 사용할 수가 없습니다. 기업의 정책에 따라 기업의 인터넷 환경을 열수 없다면 SaaS 솔루션을 도입할 수 없습니다. 기업 내재화고객이 SI를 통해 자사를 위한 서비스를 요구하는 경우에 맞지 않습니다. 또는 데이터의 거주 위치에 대해 민감한 경우에도 문제가 될 수 있습니다. 클라우드가 대중화 되면서 데이터의 거주 위치는 실제로 의미가 없어지고 있습니다.On-Premises 솔루션을 도입하는 이유사내에 솔루션을 설치하는 On-Premises 방식은 IT 서비스와 함께 만들어진 방식이며 현재까지도 엔터프라이즈 규모의 기업들이 가장 좋아하는 방식입니다. 기업 내재화On-Premises 방식은 SI를 통한 기업 맞춤형 솔루션 제공이 가능합니다. 기업이 자사에 최적화된 방식으로 솔루션을 변경하여 사용함으로써 만족도를 높일 수 있습니다. 데이터 소유On-Premises 방식은 솔루션과 데이터가 모두 사내에 존재함니다. 외부망이 열려있지 않더라도 사내에서 데이터가 가공되고 처리되기 때문에 문제없이 사용할 수 있습니다.  On-Premises를 떠나는 이유클라우드의 도입과 함께 많은 엔터프라이즈 기업들이 아래의 이유로 On-Premises에서 SaaS로의 전환을 고민하고 있습니다. 비용On-premises의 높은 도입 비용에 대한 고민이 높아지고 있습니다. 특히 클라우드 생태계에서 노드락 라이센스는 의미가 없어지고 있습니다.노드락 라이선스별도의 라이선스 서버없이 해당 장비에서만 사용 가능한 라이선스입니다.플로팅 라이선스별도의 라이선스 서버를 구축하여 클라이언트 요청이 있을때 라이선스 서버에서 클라이언트로 라이선스를 할당하는 방식입니다.유지보수엔터프라이즈 기업은 자사의 수많은 솔루션들을 유지보수 하는 데 지쳐가고 있습니다. 솔루션 유지 보수 비용은 On-Premises 솔루션 가격에 포함되어 있는 경우도 있기 때문에 개개별로 관리하기도 어려운 부분이 있습니다. 점점 복잡해지는 IT 환경 속에서 기업은 유지보수에 대해 민감해지고 있습니다.On-Premises의 대안 Private SaaS SaaS와 On-Premises의 장점을 합친 방식으로 SaaS 솔루션 전체를 패키지로 제공하는 방식입니다. 와탭랩스의 경우 IT 모니터링 서비스 전체를 패키징하여 기업에 제공하고 있습니다. 엔터프라이즈 기업의 서비스 운영팀에 설치하고 기업 내부에서 서비스 방식으로 사용할 수 있습니다. 빌링까지 포함되어 있는 제품이기 때문에 사용량을 체크할 수 있으며 일반적으로는 년단위의 라이센스를 사용하게 됩니다.마무리SaaS와 On-Premises 솔루션을 비교한다면 SaaS가 미래의 솔루션이라고 할 수 있습니다. 하지만 Private 클라우드를 도입하고 외부에 망을 열지 않는 다면 On-Premises를 사용해야 합니다. 뿐만 아니라 와탭랩스의 경우처럼 SaaS 솔루션 전체를 On-Premises로 제공하는 기업들도 있기 때문에 On-Premises 시장도 줄어들지는 않을 것으로 예상되고 있습니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지

 15세기 후반부터 18세기 중반까지 미지의 땅을 찾아 너도나도 탐험에 뛰어들었던 대항해시대(大航海時代).      나는 이번 탐험을 하기 위해 은행에서 융자도 받고, 왕실의 후원도 받았어. 그들은 이번 항해로 엘 도라도의 황금을 한 가득 싣고 오길 기대하고 있지. 우리의 가장 큰 후원자인 여왕은 정해진 기한 내에 온갖 보물을 가지고 돌아오라고 응원 아닌 협박 같은 메시지를 보내왔지.  식량과 물은 오직 6 개월 치 분량인데 항해 도중에 상하거나 버려질 분량을 생각하면 4개월 내에 도착해야할거야. 항해를 위해 뽑은 선원들은 여전히 나를 미심쩍어 하는 눈빛이고 그나마 마음이 통하는 벗이자 항해사가 동행하게 되었지. 떠나기 전 날 연회에서 만난 평생 바닷길 지도를 그려온 학자가 이런 말을 하더군.“너무 서쪽으로 가면 세상 끝 낭떠러지로 떨어질 테니 안전하게 해안가로만 다니세요.”       현재는 바야흐로 대창업의 시대! 대한민국의 청년 실업률이 나날이 증가하고, 국가 성장동력에 이상신호가 감지되는 지금! 정부가 나서서 창업을 독려하고, 많은 지원과 교육/자금을 풀어서 잠재되어있던 수많은 아이디어를 현실에 소환하려는 계획은 어느 정도 효과를 보고 있어.  적어도 수치상으로는 매년 거의 10만개에 가까운 창업기업이 탄생하고 있으며, 언론 매체에서 스타트업 성공신화를 줄기차게 소개하잖아. 그럼에도 불구하고 자금 조달은 어디서 해야 하는지, 사업계획서는 어떻게 써야하는지, 팀 빌딩은 누구를 영입해야 할지에 대한 고민은 끝이 없어. 많은 예비창업자들은 준비단계에서부터 우왕좌왕할거야.  나 역시 2년 동안은 소위 베이킹(baking)이라는 시간을 가졌거든. 뒤늦게 알게 된 거지만, 창업 지원과 인프라, 교육은 다 활용하기 힘들 정도로 넘쳐나. 우리는 단지 방법을 몰랐고, 사람을 몰랐고, 실행을 못 하고 있었던 거지. 돌이켜보면, 조금만 더 디테일하게 신경 썼으면 시간을 더 단축하고, 자금을 더 효과적으로 운영했을 거야.        스타트업의 길은 탐험과도 같아. 어떤 분들은 여행으로 비유하는데 동의하지 못 하겠어. 룰루랄라~ 마음 맞는 친구들과 즐거운 상상을 하면서 계획 해 둔 일정과 여러 SNS 친구들이 방문해 보고 추천했던 맛집들을 찾아다니는 것과 현실은 정반대거든.       사업계획서라는 이름의 항로가 그려지지 않은 채 출처가 불명확한 지도를 가지고 있어. 이 지도는 계속 측정하고 수정하면서 그려 나가야하는 불완전한 지도야. 알음알음 또는 내가 그래도 경험이 있어서 조금은 더 뚜렷해 질 수는 있어도 100% 완벽하지 않기에 스스로 의구심을 가지고 항로를 개척해야 해.      탐험은 예측불가능한 잠재리스크가 많아. 스타트업도 그래. 내부적인 리스크는 관리하고, 조정할 수 있어도, 외부 리스크는 정말 암담하거든. 지난 번에 정치외교적인 사드 문제라던가 한일 외교 경색로 인한 시장 환경 변화는 마치 항해 도중에 만나는 폭풍우와 같아. 아무리 돛을 접고, 방향키를 돌려보아도 망망대해에 높은 파도와 비바람을 견디기란 쉽지 않거든.       계획한대로 흘러가지 않을 때, 팀원들의 불안감과 두려움은 고조되지. 그리고 불만이 여기저기서 독버섯처럼 퍼져나가기도 하지. 그러다 리더십에 대한 의문과 사업 방향에 대한 의심으로 확대 되면 이탈하고자하는 사람들이 나타나. 계획된 목적지 도달 일정이 지연되고 식량이 고갈되는 상황에서 선원들이 해상반란을 일으키는 영화 속 장면이 꼭 멀리 있지는 않거든. 팀 빌딩도 중요하지만, 인력관리는 그 보다 몇 배 더 중요하지.       바쁘고 정신없었던 하루가 끝나갈 때 쯤, 밤이 되면 선장(창업자) 역시 두려움과 고민의 시간을 가지게 되지. 우리가 잘 하고 있는 건지, 무언가 챙기지 못 한 것은 없는지 확인하고 의심해야 해. Plan A, PlanB, Plan Z를 준비해야 하지. 우리 항로에 대하여 가장 잘 아는 사람은 사실 우리거든. 다른 사람이 고민 해 주거나 고쳐주지 않아. 내일 아침도 무사히 항해하기 위해서는 나 자신이 더 확실한 지도를 만들어가야 해.       꿈에서 그려 본 황금의 도시 엘 도라도!  적어도 우리는 엘 도라도가 존재한다고 하는 믿음이 있어야 해. 그곳에 진짜 황금이 있을지, 아니면 우리를 위협할 창과 화살이 있을지는 솔직히 지금은 알 수 없어. 엘 도라도에 대한 우리의 상상과 현실은 다를 수 있지만, 분명한 것은 과거와 달리 지금은 정보가 공유되어 있다는 거야. 이전에 탐험가들은 정보교류나 자신의 지도를 쉽사리 넘겨주지 않았지만 현재는 집단지성과 이 길을 걸어 본 많은 경험자들과 현직자들, 인프라가 유용한 정보는 넘치고 있지. 어쩌면 이미 먼저 도착했던 사람들을 통해 어렴풋이나마 확신할 수 있어.      “당신만의 엘 도라도는 분명하게 있다. 너가 도착할 수 있느냐의 문제만 남아있을 뿐”        투자자가 되었든, 팀원이 되었든, 고객이 되었든 우리가 확신이 없으면 어느 누가 이 항해에 동참하겠어? 이렇게 수많은 위험이 있음에도 불구하고 우리를 웅원하고 후원해 주는 사람들에게 지속적으로 신뢰를 주어야 해. 따라서, 우리는 보다 전략적이고 계획적이며 성과로 증명해 나가야 하지. 효율적이고 영리해져야 해. 대안을 늘 찾아내야 해. 부단히 배우고 성장해야 해.     “너는 엘도라도에 어떻게 갈래?”지난 칼럼에서는 네가 이 탐험을 위해 얼마나 강한 동기를 가지고 있는지를 물었다면, 이번에는 네가 왜 전략과 실행을 끊임없이 반복해야하는지에 대한 이 질문을 던지면서 마무리할게. 의욕으로는 버틸 수 있어도, 전략과 전술이 없으면 목적을 달성하기 어려워.     (역주)* 팀빌딩이란 창업/프로젝트 수행을 위해 적합한 인재/동료/팀원을 구성하는 것을 뜻하며, 초창기 스타트업은 지인과 친구, 가족으로부터 시작해서 확장하는 경우가 많다.* 스타트업계에서 베이킹(baking) 이란 창업을 준비하기 위한 시간을 뜻하며, 보통 사업자등록을 내기 전까지 사업계획을 하고, 팀원을 모으고, 선행조사 등의 활동을 한다* Plan A, PlanB, Plan Z이라는 용어의 뜻은 다음과 같다.Plan A: 어떠한 업무 또는 프로젝트를 수행하는데 최선의 방법/방안/경로를 뜻함 Plan B: Plan A가 달성하지 못 할 때를 대비한 대안/대책을 뜻함Plan Z: 최종적으로 목표 달성이 어려운 상황에 대하여 더 큰 손실이 발생을 회피하고, 피해를 최소화하기 위한 최후의 출구전략을 뜻함 

이제 9월도 얼마 남지 않았네요. 유난히도 더웠던 올해 여름은 완전히 끝난 듯 합니다.환절기에 감기 조심하세요!오늘은 저희 모인에 지난 8월 말에 입성한 김보국 마케팅 인턴사원을 소개할까 합니다.들어온지 딱 한달 된 그는 벌써 보거스, 뻐꾸기 등 다양한 별명을 가지고 있다- Professional Experience -2016.05 - 2016.07 전용범회계사무소 회계인턴2012.06 - 2012.09 대구지방 국세청 동대구 세무서 세무인턴- Education -2015.08 - 현재 College of William and Mary, Economics2012.09 - 2013.08 University of California, San Diego2008.08 - 2012.06 San Joaquin Memorial High School▶     업무에서 어떤 부분을 담당하고 계신가요? 저는 마케팅팀 인턴으로 사업개발 자료 조사와 컨텐츠 작성 등을 하고 있습니다. 아직은 일을 담당한다기 보다 해보면서 하나하나 배워나가고 있습니다.▶     아직 학생이시죠? 지금 전공하고 계신 과목은 왜 선택하게 되셨나요? 네. 현재 휴학을 하고 모인에서 일하고 있습니다. 사실 저는 캘리포니아 대학교를 다니다가 윌리엄앤메리대학으로 편입을 했습니다. 이 시기에 “자본주의 역사 바로알기"라는 책을 접하게 됐는데, 경제와 금융을 매력적으로 느꼈죠. 내년에 복학을 하면 금융을 주전공으로 하고 회계를 부전공할 계획입니다. 회계의 경우는 숫자로 경영 상태를 측정할 수 있는 법을 배울 수 있는 과목이라 생각합니다. 앞으로 경영인을 꿈꾸는 사람으로서 필요한 과목이라 생각합니다.'나는 여전히 배움에 목마르다' by. 보쿡라테스▶     모인에 합류하게 된 계기는 무엇이었나요? 우연한 기회에 스타트업 전문 구인구직 플랫폼인 로켓펀치에서 모인을 알게 되었습니다. 해외송금은 외국에서 유학을 하고 있는 저와 매우 관련있는 금융 서비스입니다.특히 모인은 송금수수료를 파격적으로 낮추어 사용자가 받을 수 있는 금액을 더 늘려주겠다는 사업 아이템을 바탕으로 합니다. 이 부분이 서비스를 직접 써본 사람으로서 매우 매력적이라고 느꼈습니다. 그래서 지원을 하게 됐습니다. 이후 서일석 대표님과 구글캠퍼스에서 만나 사업에 대한 이야기를 자세히 들을 수 있었습니다.이야기를 하고 나니 제가 해외송금을 필요로 하는 사용자로서 모인 서비스 홍보에 있어 무언가 할 수 있겠다는 생각이 들었습니다. 그래서 모인에 꼭 합류하고 싶었습니다.▶     자신있는 파트와 더 키워나가고 싶은 역량은? 자신있다기보다는 저는 새로운 사람을 만나고 질문 하는 걸 좋아합니다. 새로운 사람을 만나서 질문을 통해 이야기 나누고 서로가 살아온 삶에 대해 공유를 할 수 있다는 점이 즐겁기 때문이죠. 같은 맥락에서 모인 팀원들과 일하는 게 즐겁습니다. 일에 대해서 뿐만 아니라 팀원들 한명 한 명 에게도 물어 보고 싶은 게 엄청 많기 때문입니다.아, 사무적으로 잘 하는 게 있습니다. 저는 하나를 파고드는 걸 좋아해서 조사하고 분석하는 분야에 자신 있습니다. 더 키워 나가고 싶은 역량은 어떤 아이디어를 누군가에게 설득 할 수 있는 능력입니다. 아무리 좋은 아이디어라 하더라도 논리적으로 잘 설명하지 못하면 설득 할 수 없다는 걸 직접 경험하고 아쉬웠던 적이 있기 때문입니다. 그는 질문하기를 정말 좋아한다. 정.말.로.▶     모인에서 한 달 정도 일했는데 어땠나요? 저는 모인에서 매순간이 감사했습니다. 구글캠퍼스라는 멋진 사무공간에서 일할 수 있다는 것뿐만 아니라, 배울 점이 많은 모인 팀원들과의 대화 등 사소한 순간 조차도 즐겁게 느껴졌습니다.사실 처음 대표님과 인터뷰할 때, 지금 당장 팀에 필요한 사람은 안드로이드 개발자라고 하셔서 팀이 저를 필요로할 지 매우 걱정했었기 때문입니다. 결국 모인 직원분들 내부 상의 끝에 제가 인턴을 할 수 있게 됐다고 했을 때, 그 기대에 꼭 부응하겠다고 결심했고, 제 나름대로 한달간 노력했습니다.뿐만 아니라, 뉴스에서만 보던 국내 스타트업 세계 안에서 직접 경험해볼 수 있다는 게 저에겐 정말 소중한 자산이 됐습니다. 구성원들이 서로 배려하고 서로 경청하고 진심어린 조언을 주고 받는 모습에서 모인은 정말 열정적인 사람이 모여있는 곳임을 알 수 있었습니다.김보국 사원에게 '함께 일하고 싶은 사람'이란?#근성 #신뢰 #배려▶     앞으로 어떤 쪽으로 일하고 싶으신가요? 앞으로 저는 졸업 후에 증권사 리서치 센터, 비즈니스 컨설팅 회사, 외국계 투자자문사 쪽에서 커리어를 쌓아보고 싶습니다. 이런 멋진 경험들을 바탕으로 언젠가 저희 모인 대표님과 같이 사용자를 중심으로 하는 프로덕트, 서비스 등을 제공하는 회사를 일구어 보고 싶습니다.▶     아직 한 달정도 밖에 안됐지만 그래도 모인에서 일하면서 스타트업은 어떤 곳이라는 생각이 들던가요? 제가 한 달간 느낀 스타트업은 이렇게 정리 할 수 있을 거 같습니다.첫째, 직급과 상관없이 논리적이고 합리적인 요소에 근거하여 사업에 도움이 되는 아이디어라면 뭐든 받아들일 준비가 되어있는 곳. 둘째, 무엇이라도 먼저 해보고 그 경험을 바탕으로 사업을 더 크게 발전 시킬 수 있는 곳.  셋째, 개개인의 역량 하나 하나가 모여 팀 전체의 발전에 밑거름이 되는 곳이기 때문에 팀 전체에 누가 되지 않고 원동력이 되어야 겠다는 책임감을 심어 주는 곳마지막으로 스스로가 회사에 기여하고 있다는 보람을 느낄 수 있는 곳.  모인에서 많이 배우는 중입니다.  "모인에서 최선을 다하겠습니다"- 김보국이 꼽은 인생 명언 -사소취대(捨小取大)작은 것은 버리고 큰 것을 취한다(순간의 잘못된 선택으로 이제 껏 쌓아온 모든 것들이 무너지게끔 하는 일은 없도록 하자는 제 다짐입니다)#모인 #MOIN #인턴 #인터뷰 #인턴생활 #팀원소개 #팀소개 #기업문화 #조직문화 #사내문화

데일리호텔에서는 지난 11월말에 Exit Poll 기능을 서비스에 도입했습니다. 출구 조사는 숙박 예약을 했던 고객 등을 대상으로 간단한 설문을 진행하여 서비스의 품질을 끌어올리는 수단입니다. Product 팀은 이를 구현하기 위해 몇 가지 방안을 검토한 후 아래와 같은 플로우로 작동하는 구현체를 만들기로 했습니다.앱보이에서 캠페인을 진행한다. 앱보이에는 HTML을 푸시로 앱에 날리는 기능이 있으므로 간단한 설문 조사 웹페이지를 앱에 보낼 수 있다.사용자가 설문에 응하면 설문 내용을 서버로 보낸다.서버가 설문을 구글 스프레드시트에 저장한다.업무 관련자는 설문 내용을 담은 구글 스프레드 시트를 공유 받는다.이와 같이 결정하기까지 주로 고려한 점은 다음과 같습니다.앱보이는 고객 세그멘테이션을 나눠서 푸시를 발송하는 기능이 있으므로 캠페인의 효율이 높다.설문 내용은 캠페인마다 바뀌므로 비정형 데이터에 가깝다. 그러므로 관계형 데이터베이스에 넣기에 불편하다. 뿐만 아니라 데이터를 분석하려는 사람은 데이터베이스에서 설문 조사 결과를 자신의 분석도구로 가져가는 일을 따로 해야 한다. 그러므로 바로 분석을 시작할 수 있도록 구글 문서로 결과를 쌓는다.이렇게 구현한 결과물은 다음과 같습니다.설문조사 화면구글 스프레드시트에 쌓인 설문조사 결과이렇게 스프레드시트로 데이터를 바로 쌓기 때문에 시트가 제공하는 기능이나 구글의 또다른 서비스인 데이터스튜디오 등으로 분석을 바로 진행할 수 있습니다. 데이터베이스에서 데이터를 추출해 분석도구에 넣는 작업을 하지 않아도 됩니다.물론 이런 작업 플로우가 모든 데이터에 적합한 것은 아닙니다. 특히 구글이 제공하는 API에 몇 가지 제약이 있기 때문에 주의할 필요가 있습니다. 예를 들어초당 API 호출 회수 등에 제약이 있고스프레드시트 하나는 40만개가 넘는 셀은 담지 못합니다.이러한 제약이 큰 문제가 되지 않는다면 매우 효율적인 작업 플로우로써 기능합니다. 자세한 구현 이슈는 기회가 닿는다면 다른 글로 설명하겠습니다. 그럼 다들 즐거운 하루를~#데일리 #데일리호텔 #개발 #개발자 #기획 #기획자 #마케팅 #마케터 #데이터분석 #인사이트 #도입후기 #일지

일반적으로 콜드 네트워킹이라는 용어보다 콜드콜이라는 용어를 많이 쓰는 듯 하다.근데 필자는 네트워킹이라는 말을 더 좋아해서 낯선 사람에게 도움을 요청하는 모든 것들을 콜드 네트워킹으로 그냥 부른다.현재 필자는 지난 몇년 사이 정말 많은 부분에서 성장을 했다.실무적인 면에서 인간적인 면에서 굉장히 많이 성장을 해왔다고 생각한다.그러나 이 성장은 온전히 나의 열정만으로 나의 노력만으로 이루어진 것은 절대 아니다. 항상 정체되었을 때 슬럼프일 때 해매고 있을 때 항상 누군가의 도움이 있었다. 근데 그 도움은 누가 갑자기 우연히 도와준 것이 아니라 "이 낯선 사람이 나에게 해답을 줄지도 몰라"라는 생각에 무작정 도움을 요청했다. 정중하게 내 상황과 고민을 밝히고 원하는 답에 대해서 조언을 해줄 수 있냐는 식의 요청이였다.나는 이러한 방식의 도움 요청이 인생을 살아가는데 있어서 굉장히 굉장히 중요하다고 생각한다.스티브 잡스도 콜드 네트워킹에 대해 굉장히 강조한 바 있다.필자는 3년전 22살때 굉장히 고민에 빠져 있었다.열정은 충만했고 목숨을 걸어서 무엇인가 하고 싶었다. 근데 내가 좋아하는 것이 무엇인지 사실 잘 모르겠고 내가 잘하는 것이 무엇인지도 몰랐고 어떤 일이 나에게 어울릴지 고민이 많았었다.우연히 IT칼럼을 보다가 인사이트 있는 글이라고 생각했고 그 글의 작성자에게 무작정 진로에 대한 고민을 털어놓았다.돈 한푼 들지 않았던 갑작스러운 이메일 요청으로 내가 어떤 미래를 그려야될지 꽤 명확해졌다.그리고 그것이 현재 나를 만드는 것에 크나큰 기여를 했다.이런 식의 콜드 네트워킹은 굉장히 많았고 그 순간 순간마다 나는 엄청난 성장을 했었다. 그리고 꿈과 열정이 가득했던 한 청년의 이메일에 정성스럽게 답변주신 전혜경님에게 다시 감사의 말을 전하며 식사한 끼 대접할 수 있는 시간을 마련해달라고 메일을 드렸다.필자의 콜드네트워킹 방식은 다음과 같다.1.전화를 하거나( 메세지나 , 메일로 전화번호를 받은 뒤) - ex12.직접 만나거나 & 그 오프라인에서 질문을 직접 한다거나 - ex13.페이스북이나 인스타로 메세지를 한다거나 - ex14.메일로 요청을 한다거나 - ex1 ex2 ex3 ex4(부끄러운 사례들이 정말 많지만.... 공유하기로.....ㅠㅠ)(참 저때 어렸구나 그런 생각.......)사실 콜드 네트워킹 요청했을 때 거절 당한 경우도 꽤나 있었다. 그러나 그런 걸로 상처받을 필요는 없다.그리고 거절 당할 것 같으니깐 안할 필요도 없다.낯선 사람이 도움을 요청하는데 무응답을 하는 것은 어찌보면 당연한 것일 수도 있고 그런데도 불구하고 도와주는 것은 정말 고마우신 분들이기도 하다.콜드하기에 앞서서 상대방을 배려하고 있다는 느낌을 줘야된다. 무작정 요청하기보다 현재 내 상황을 잘 설명하고 원하고자 하는 결과가 무엇인지를 깔끔하고도 명료하게 상대방에게 알려주는 것이 중요하다. 상대방은 어쨌든 답장을 하는데에 시간을 써야하기 때문이다. 그 요령은 한국인으로 구글에서 최연소 상무를 하셨던 김현유님의 팁들을 참조하면 될 듯 하다. 1)콜드콜 노하우  2)네트워킹 이야기누군가에게는 낯선 사람에게 도움을 요청하는 것이 사실 용기를 필요로 한다.그러나 그것도 잠시라고 생각하자.유명한 심리학자 중 프로이트만큼의 명성이 있는 벤듀라는 자기 효험 이론을 내놓았다. 사람들은 어떤 것을 추측할 때 두려운 감정을 느끼지만 실질적으로 그것을 마주하고 나면 두려웠던 경험을 극복하는 것은 물론이며 더 다양한 경험들도 두려움 없이 마주할 수 있다는 것을 실험을 통해 밝힌 바 있다.사실 이러한 것은 virgin의 회장 리처드 브랜슨이 말한 "한가지의 분야에서만 사업을 성공시키면 다른 분야에서 사업도 성공시킬 수 있다고 확신했다." 라고 말하는 것처럼 한번 콜드 네트워킹을 실제로 해보면 그리고 인사이트까지 얻는다면 앞으로 자기가 힘들 때 고민하고 있을 때 슬럼프일 때 정말 잘 헤쳐나갈 수 있는 하나의 유니크한 기술을 가지게 되는 것과 같다고 생각한다.운과 기회, 사람을 기다리지 말고 직접 행동하고 도움을 요청하고 낯선 사람에게도 조언을 충분히 구해보자.앞으로 필자도 이런 것에 대한 두려움과 망설임을 더욱 없애고 자신있고 당당한 삶을 살아갈려고 한다. 단 잊지 말아야할 것은 우리가 그렇게 누군가에게 낯선 도움을 구하듯이 누군가가 나에게 낯선 도움을 요청한다면 정말 감사한 것으로 느끼고 그 사람에게 다시 베풀자.pay it forward !#페오펫 #peopet #인사이트 #꿀팁 #경험공유 #조언

사실 브랜딩이란 단어와 제가 하는 일이 맞는가... 에 대한 고민이 많이 들었어요. 큰 개념으로 생각해보면 무엇이든 브랜딩이 될 수도 있지만 그럼 너무 광의적이잖아요. 직무적으로 제가 하는 것이 브랜딩인가...를 고민해봤을 때는 뒤통수를 긁적이게 되기 일쑤더라구요. 너무 긁어서 두피에 여드름생김하지만 이렇게 생각해봤어요. 어떤 브랜딩이든 정성적인 개념에선 결국 사랑에 빠지는 것과 비슷한 게 아닐까 말입니다. 흔히 소개팅에 비유를 많이 하잖아요. 그걸 직무로 좀 나눠보면 이런 느낌이었어요.어쨋든 내가 구구절절 내 자랑을 늘어놓는 거 말고, 상대가 자발적으로 '저 사람은 어떤 사람이구나...' 하고 느끼게 만드는 것이 브랜딩에 가깝다고 하잖아요. 하지만 느끼는 사람(소비자)에게도 어느 정도의 정보가 있어야 판단의 기준이 설 게 아니겠어요.경험을 통해 느꼈다. 이것은 부드럽구나..그 정보의 종류를 나눠보니 이랬어요.얼굴이 겁나 괜찮은거야. 이건 비쥬얼브랜딩이죠.목소리가 너무 자상하고 말을 이쁘게 해. 이건 애티튜드예요.생각이 너무 올바르고 멋진 가치관을 지니고 있어. 이게 철학과 본질이죠.대화의 주제가 매력있고 재미있어요. 이건 콘텐츠브랜딩이예요.내 맘에 쏙드는 데이트 코스를 만들고 매너도 좋아요. 이건 UX브랜딩이죠.이런식으로 결국 다양한 방식의 정보가 전달되어야 그걸 토대로 소비자도 어떠한 이미지를 그려내고 판단을 하기 마련이예요. 브랜딩전략이란 것은 이런 이미지를 어떻게 구축하고 잘 만들어내느냐....이런 걸 의미하는 것 같아요. 물론 저는 좀 내부의 비효율을 줄이는 방향을 추구하지만 말이예요. (쓸데없이 회사소개서 다시 찍고 창고에 박아두는 그런거...)저는 물론 저 위의 내용 중에서 얼굴을 담당하고 있어요. 예쁘게 꾸미는 것도 중요하지만 에센스만 치덕치덕 대는 것보단 일단 물마셔서 피부수분부터 보충하는게 먼저라는 생각입니다. 나름의 철학을 가지고 쭈욱...일을 해왔는데 한 번 쯤 그간 느꼈던 것에 대해서 정리해보고 싶었어요.브런치에 글을 쓰면서 나름 선방하기도 했고, 구글이나 네이버에 이것저것 나오는 거 보니 개판치진 않은 것 같아요. 하지만 '잘한걸까?' 라는 질문에는 머뭇거려지네요. 최선을 다했긴 했지만요..아패로도 개속...그래서!!핫바리시절부터.... 지금까지 오면서 느낀 것들 쭈욱!~생각해봤습니다..작년 7월7일...1. 브랜딩은 광고일까...말이 많아서 손해보는 브랜드도 있다는...브랜딩은 분명 정보를 제공한단 점에서 자칫 광고와 헷갈릴 수 있는 것 같긴해요. 이건 마치 이런 느낌이예요.광고는 완성된 퍼즐을 이거 19,900원에 팔아요! 이쁘고 재밌음!! 이라고 판매중심의 정보를 제공해요.브랜딩은 퍼즐을 한 두개씩 던져주면서 고객들이 스스로 퍼즐을 맞추게 해요. 그리고 오오..... 맞춰보니 이쁘군? 이라고 생각하게 만들죠. 단서중심의 정보를 제공해요.처음에 광고같을까봐 쫄아서 애프터모멘트를 회사이름을 쓰는게 맞는걸까...도 고민했거든요. 아직도 계정이름이 'roysday' 인 것은 그 때 당시 제 예명이 ROY였기 때문이예요. 홈페이지 링크도 못올렸고, 제가 뭘 운영한다, 전 누구다! 도 얘기할 수 없었어요. 그건 쫄아서였기 때문이죠. 하지만 지나고 생각해보니 오히려 잘한 것 같긴 해요.2. 내가 누군지 모르면 어떡하지...1번과 비슷한 맥락으로 소비자가 빨리 나를 인지했으면 하는 조급한 마음이 안들수가 없었어요. 하지만, 궁금한 분들이 먼저 찾아오시더라구요. 심지어 어떻게 전화번호는 알았는지, 어떻게 메일주소는 알았는지 돌아돌아 수단방법을 가리지 않고 찾아서 연락을 주셨어요. "아니 대표님 왜 컨택포인트가 아무데도 없어요!!?" 라는 질문을 자주 받았었죠.. 생각해보니 사고싶은 물건이 있으면 구글이미지 검색을 해서라도 찾아내는 게 또 소비자예요. 물론 UX적으로 원활함을 만들어내는 것은 매우 중요하지만 그게 먼저는 아닌 것 같아요. 도대체 여긴 뭘까..라고 궁금하게 만드는 게 우선이 아닐까..합니다.3. 아다리의 중요성브랜딩은 전략도 중요하지만 아다리가 정말 중요한 것 같아요. 시장상황도 있겠으나, 뭔가 터졌을 때 그걸 감당하고 유지할 수 있는 내부상황도 중요하죠. 내부에 시스템과 역량을 잘 다듬어야 하는 이유예요. 아다리는 항상 뜬금없이 갑작스레 오거든요. 내일이라도 터질 것처럼 내부관리를 잘 해야해요.저 같은 경우는 쓰지도 않을 맥북을 사놓고 쓰지도 않던 스케치도 구매해서 깔아놓고, 줄 데도 없던 소개서를 있어보일라고 만들고, 허접하게 뚝딱뚝딱 만든 홈페이지도 나름 있긴 했거든요. 바빠지기 시작하니 그런걸 손댈시간도 없더라구요. 미리 만들어놓길 잘했어요....ps. 아다리와 더불어 중요한 건 촉입니다. 결국 인생은 한방...4. 레퍼런스의 양면성잘된 브랜딩을 연구하고 분석하는 건 아름다운 일이예요. 많은 인사이트와 행동방식을 배울 수 있죠. 하지만 한편으론 결과편향에 빠질 수도 있는 것 같아요. 결과가 잘됬으니 과정도 옳은 것이다!..라는 논리가 되어버리면 자칫 오판할 수도 있거든요. 또는 레퍼런스를 너무 맹신하는 것도 마찬가지구요.아마존과 월마트가 이렇게 했으니 우리도 이렇게 하자!! 라는 건 꽤나 매혹적이지만 위험할 수 있는 발상이예요. 우리는 우리의 방식을 만들자! 가 더 맞는 말인 것 같아요. 그리고 그렇게 하기로 했으면.. 아래 9,10번이 중요해져요. 5. 브랜딩은 비용과 엉덩이싸움기술도 좋고 철학도 좋고 뭐 다 좋지만 결국 실천은 돈과 엉덩이에서 비롯돼요. 뭔갈 만들거나 제작하는 데에는 적든 크든 비용이 들어가기 마련이예요. 하지만 브랜딩은 지속력싸움이기 때문에 그 비용이 지속적으로 들어가죠. 그래서 비용관리와 엉덩이힘은 아주 중요해요. 조회수가 1/100로 떨어져서 1달내내 아무 반응이 없어도 그냥 꾸준히 묵묵히 글을 올려야 했는데... 이런 지루하고 긴 터널을 지나는 싸움에서 필요한 건 '무상무념' 인 것 같아요. 물론 긍정적인 마인드와 열정도 좋겠지만... 지속성이란 건 꽤나 사람을 지치게 만들거든요. 기대와 실망의 반복으로 지치기보단 멍하게 꾸준히 올리는 게 좋을 수도 있어요.6. 철학보다 행동철학은 매우 중요해요. 하지만 기업이 만들어진 것 자체가 이미 철학이 구현된 거잖아요. 이제부턴 행동을 해야해요. 문제를 찾아 해결하고 가치를 창출해서 제공해야 해요. 그리고 그걸 다른 가치로 교환할 수 있어야 하죠. 하루종일 내 본질과 초심은 무엇일까... 이것의 철학과 가치는 어디에 있을까를 고민하고 워딩을 짜는 것이 나쁜 것은 아니지만, 그걸 고민하는 시간에도 시간은 흐르고 고객은 다른 곳을 보고 있어요. 여전히 문제는 발생하고 있구요. 해결하기로 마음먹었으면 당장 뛰쳐나가서 해결을 해야해요.앱사업을 하고 있으면 앱사업의 본질은 앱이예요. 그 앱으로 뭘 해결하고싶은지, 그리고 그게 해결되고 있는지. 그게 본질이죠.콘텐츠사업을 하고 있다면 콘텐츠가 본질이예요. 콘텐츠로 무슨 메시지를 주고싶은지 제대로 주고있는지. 그게 본질이예요.전 브랜딩을 한다고 하지만, 막상 클라이언트 사무실가면 제일먼저 창고정리부터 하게 되더라구요.그들에겐 정리되지 않은 시스템과 파일, 엉망진창이 창고가 제일 시급해요. 그것부터 정리하고 동선을 다시 짜고, 파일을 지우고 폴더링을 다시하고, 흩어진 가이드들을 모으는 것이 더 중요했어요. 철학을 논하고 있는 사이에도 실무자들은 여전히 엉망진창인 창고에서 헤매고 있잖아요. 철학은 생각하고 곱씹는게 아니라 행동으로 드러내는 거예요.문제부터 해결해요.7. 매출은?이 부분이 제일 예민한 것 같아요. 매출과 브랜딩이 마치 대척점에 있는 것 같이 자꾸 얘기를 하는 분들이 있어요.브랜딩은 인지도다! 그러니 일단 많이 알려야 사람들이 오는 거고, 사람들이 모이고 나면 궤도에 오를 거고 그 때 우리 색깔을 찾아도 늦지 않다. 근데 여기서 많이 알려서 사람들이 오려면 유인책이나 셀럽이나 이런 외부 리소스가 필요하다.얼핏 들으면 논리적으로 말이 되는 것 같은데 맹점이 있어요. 사람들이 모인 이유는 우리의 인지도가 높아져서가 아니고 유인책이 있었기 때문이예요. 유인책에 의해 몰려와서 우리 브랜드를 잘 알았다고 해봐요. 물론 절대량이 많으니 확실히 매출이 많아지긴 할거예요. 하지만 그게 궤도에 오른 걸까요. 그 때가서 우리 색깔로 바꾸면 사람들이 '아 그렇구나! 대단해! 멋져!' 하면서 끄덕거려줄까요. 냉정하게 얘기하면 이래요. 사실 돈을 가지고 시작하시는 게 속편하죠. 내가 옳다고 생각하는 전략을 이것저것 해보면서 결국 하나가 잡히면 쭈욱 밀고 나갈 수 있는 자본. 이건 뭐 그래요 거의 치트키죠.BUT하지만 돈은 은행에 있는 것이니 우리에겐 돈이 많지 않을거예요. 돈이 많지 않은데 자꾸 이것저것을 하려고 하니까 괜히 생각만 많아지는 거예요. 하나만 정해서 하나라도 제대로 해요. 서버가 개판이라서 자꾸 앱이 다운되면, 물론 증설을 해야겠죠. 근데 당장 그게 안된다면 클레임대응을 정말 황송하고 감동스럽게 해야해요. 꾸준히 그렇게 해요.카페를 하는데 난 커피보다 편안한 공간이 더 중요하다. 라고 하면, 원두는 평타로 하고 겁내 편안하고 안락한 의자와 공간을 만드는 데에만 집중해요. 메뉴판도 신경쓰지 마요. 간판도 몰라요. 그냥 편한 의자와 책상에 공을 들여요. 돈이 없잖아요. 자꾸 눈에 보이는 멋진 것을 만들려고 하면 안돼요. 하나라도 제대로 되고 있는 게 중요해요.한정된 곳에 돈을 써야한다면, 하나에만 집중해요.+더불어, 매출을 늘리자! 라는 말은 사실 좀 이상한 말이예요. 매출은 '효과' 에 가까워요. 마치 '배가 부르자!' 라는 느낌이죠. 우린 밥을 먹자! 라고 얘기해야해요. 밥을 먹으면 배가 불러지는 거잖아요. 어떤 행동을 할 지를 규정해야지 자꾸 효과에 대해서 논하면 안되는 거예요.물론 이 말이 효과를 무시하란 게 아니예요. 배가 부르고싶다는 욕망은 달성이 되어야 해요. 다만 무엇을 어떻게 어디에서 먹을 지가 중요하죠. 물만 벌컥벌컥 먹어도 배는 부를 수 있거든요. 화장실 한 번에 사라져버리지만요.8. 단점은 역으로단점은 잘 보완이 안돼요. 그걸 자꾸 보완하려고 하면, 강점은 점점 희미해지고 애쓰는 모습만 보여요. 소비자들에게 연민을 느끼게 할 생각이 아니라면 애쓰고 울고있는 모습을 보이는 게 좋은 건 아닌 것 같아요. 단점을 숨기고 이빨까라는 건 아니지만 역이용은 항상 옳아요.공간이 좁아터졌으면 퍼스널한 1인식당으로 가는거고, 직원이 없이 혼자 일하는 거면 컴퓨터를 들고 직접 클라이언트네로 갈 수 있는 거예요. 작은 회사면 유도리를 강조하고, 비전공 디자이너면 포폴 이외의 능력을 무기로 삼는 거예요.우리의 강점이 뭘까!! 가 확실하지 않다면 (대부분의 강점은 추상적이더라구요... 단점은 구체적이고..) 구체적인 단점을 역이용해봐요.9. 말했으면 지켜야해요.전략과 인사이트에 대해서 회의하고 결론을 내는 건 솔직히 재미있고 보람찬 일이예요. 하지만 말의 희열에 빠지면 공허의 굴레에서 빙빙 돌다가 서로 지쳐요.죽이 되든 밥이 되든 하기로 했으면 하는거고 데드라인은 목숨걸고 지키는 거예요. 섭외하기로 했으면 뛰어가서 빌든, 사정을 하든, 무리수를 던지든 해서 무조건 섭외하는 거예요. 모두가 얘기만 하고 있고 아무도 발에 물집잡히지 않는 브랜딩은.... 뭐랄까.. 그냥 흥미진진한 썰풀기와 비슷해요.10. 그리 멋지지 않아요.브랜딩은 아름답고 예쁘지 않아요. 결국은 실무자가 밤을 새고, 누군가와 갈등이 생겨요. 만들어야 할 건 많아지고 일에 치이고 허덕이게 돼요. 돈이 들어가고 불안해지고 누군간 퇴사도 해요. 화합과 애정으로 나아가면 최고지만 가끔은 싸우거나 의가 상하고 오해가 생길때도 있어요. 누군간 악역을 맡아야 할 때도 있어요.만약 모두가 웃으면서 즐겁게 일하고 있다면 정말 완벽한 사내문화를 지니고 있거나, 아니라면 높은 확률로.... 그냥저냥 서로 즐거운 수준까지만 일하고 있는 것일수도 있어요.

2010년, 스탠포드 대학(Stanford University)으로 석사 유학을 떠났다. 왜 스탠포드여야만 했는지는 2가지 이유에서였다. 내게 디자인씽킹(design thinking)이라는 새로운 사고 방식을 알게해 준 아이데오(IDEO)의 창업자 데이빗 켈리(David Kelley)를 만나는 것과, 세계 혁신의 중심인 실리콘밸리의 창업 문화를 배우고 싶다는 것이었다. 이전 포스트에서 다뤘듯이 디자인씽킹의 핵심은 (1) 사람들이 무엇을 필요로 하는지 관찰하고 탐색해나가는 니드파인딩(needfinding), (2) 이렇게 발견된 니즈를 충족시켜주기 위한 솔루션을 반복적인 실험을 통해 검증해나가는 프로토타이핑(prototyping)이다. 정말 흥미롭게도, 실리콘밸리의 전설적인 창업가 스티브 블랭크(Steve Blank) 교수의 린 론치패드(Lean Launchpad) 수업에서 나는 디자인씽킹과 동일한 접근을 배웠다. 국내에서는 스티브의 제자인 에릭 리스(Eric Ries)가 2011년 발간한 린 스타트업(The Lean Startup)이라는 책이 크게 화제가 되었는데, 린 스타트업 전략의 핵심은 (1) 기존의 수십, 수백장짜리 사업 계획서를 쓰는 것이 아니라 사업의 핵심 구성 요소와 주요 가정들을 정의하는 비지니스 모델 캔버스(business model canvas)를 작성하고, (2) 이 가정들을 검증하기 위해서 끊임없이 잠재 고객을 만나 테스트하면서 이 캔버스를 수정하는 것이다. 스탠포드 유학에서 만난 교수님들. 데이빗 켈리(출처: ideo.com)와 스티브 블랭크(출처: entrepreneur.com)디자인씽킹과 린 스타트업 방법론은 무언가를 필요로 하는 사람, 즉 잠재 고객을 모든 프로세스의 중심에 둔다는 점에 공통점이 있다. 잠재 고객이 어떤 것을, 어떤 이유로, 어떻게 필요하는지는 아직 아무도 알지 못하기 때문에 이에 대한 가정(hypothesis) 수립이 선행되어야 하고, 이를 검증하기 위한 솔루션의 반복(iteration) 실험이 수반되어야 한다. 린 스타트업에서는 이러한 반복이 비지니스 모델 캔버스에서 정의하고 있는 9가지 요소 중 하나 이상을 크게 뒤집는 경우 이를 피봇(pivot)이라 부른다. 그런데 디자인씽킹이나 린 스타트업 방법론을 실제에 적용할 때 흔히 범하는 실수 2가지가 있다. 첫째, 너무 거대한 가정을 수립하는 것이다. 가정을 최대한 정교하게 쪼개어 하나의 유닛(unit) 단위로 만들지 않으면 반복적인 실험을 함에 있어서 어떠한 이유로 본 가정의 검증이 성공했는지, 실패했는지 알기 어렵다. 린 스타트업 방법론에서 최소 기능 제품(minimum viable product)을 강조하는 이유가 여기에 있다. 가정이 너무 거대하면 이 가정을 검증하기 위한 최소 기능 역시 거대해질 수 밖에 없고, 초기 실험을 위해 너무 많은 리소스가 들어갈 뿐만 아니라 검증의 결과 해석도 어려워진다.둘째, 린 스타트업 방법론을 빠른 제품 개발과 피봇으로 잘못 해석하는 것이다. 린 론치패드 수업을 마치고 스탠포드를 자퇴하며 창업했던 스타일세즈에서 우리 팀이 가장 치명적으로 범했던 실수다. 나의 경우와 마찬가지로, 많은 사람들이 린 스타트업 방법론을 "한두달 안에 빠른 속도로 제품을 개발하고, 반응이 좋지 않으면 아이디어를 뒤집는 방법론"으로 잘못 해석하는 경우가 있다. 하지만 개발할 제품의 스펙을 정의하는데 있어서 앞서 언급한 정교한 가정 수립이 선행되지 않으면, 엉뚱한 제품을 개발한 후 엉뚱한 방향으로 방향을 틀면서도 어디서부터 잘못된 것인지 제대로 파악하기가 힘들다.디자인씽킹과 린 스타트업 방법론 모두 실리콘밸리에서 시작된 실증적 접근 방법이다보니 사실상 맥락을 같이 하고 있는 것으로 생각된다. 다음 포스트에서는 이 방법론들을 잘못 해석함으로 인해서 스타일세즈 창업 때 범했던 실수들을 좀 더 구체적으로 복기해 볼 예정이다.

1. 좋은 연애(결혼)가 있고 위대한 연애(결혼)가 있다.  좋은 연애는 서로 그냥 좋아서 하는거고 위대한 연애는 서로를 뛰어넘는 꿈과 목표가 있고 성장에 더 많은 초점을 둔다. 그 속에서 사랑을 "느낄 줄 안다." 느낄 줄 안다는 것은 능력이다. 이건 각자의 개인의 삶이 감정을 넘어선 꿈의 더 우선 순위를 둔 사람들의 조합이 그렇다. 이들은 서로 더 많이 만나기보다 더 성장하기를 서로에게 바라고 각자가 뭘 이뤄내기보다 함께 시너지를 내서 더 큰 무언가를 이뤄내겠다는 롤모델이 되려고 한다. 마치 위대한 연애는 팀빌딩과 유사하다.2. 한 사람이 꾸는 궁극적인 꿈의 크기가 얼마나 큰지에 따라 그 사람의 모든 것을 결정한다. 10억짜리, 1000억짜리, 1000조짜리.. 그 궁극적인 크기에 따라 내가 만나는 사람, 의사결정의 기준, 압도적인 노력, 깊이 있는 고민이 다 달라진다.3. 각자가 꾸는 꿈의 종류는 달라도 되지만 꿈의 크기는 달라서는 안된다. 모든 사람의 꿈은 결국 각자 위치에서 대단히 커야된다. 이는 사회 전체적인 성공률을 높이기 때문이다. 목표는 나의 성공이 아니라 우리의 성공이며 푸른 행성에서의 공공선이다. 손정의 선생님이 말씀하시길.. "각자 위치에서 세상을 바꿔주시길 부탁드립니다."가 이 문맥이라고 믿는다. 4. 사람을 판단할 때는 보통 질문에 대한 대답을 통해서 의사결정을 한다. 하지만 생각이라는 것은 뇌에 기반한 것에서 나오는 화학 작용이고 뇌 자체는 오류 투성이다. 오류 투성을 가지고 있는 함수에 질문을 던져봤자 제대로된 답이 나올리가 없다. 그러면 그나마 객관적인 질문은 무엇일까? 평소에 그 사람이 가장 많이 만나는(시간을 할애하는) 사람이 누구인지를 본다. 5. 개인의 성장에 가장 중요한 3가지가 있다고 믿는다. 첫째는 몰입해야되는데 이걸 할려면 다 쳐내야한다. 거절이 가장 중요하다. 그리고 나서 할일들을 나열하고 우선 순위를 부여해서 반드시 그것대로 행하고 또 행한다. 아주 단시간내에 효율적으로 빠르게. 둘째는 자기가 엄청난 퍼포먼스를 내야하거나 고민되는 분야는 책을 통해 정제되지 않은 인터넷 정보에 노출을 줄인다. 책에서 영감을 얻는 사람들은 대단한 사람들이 많다. 그 사람들은 책에 대한 아주 강한 믿음을 가지고 있다. 셋째는 내가 만나는 사람의 수준이 달라지지 않을때 정체된다. 보통은 만날때 내 감정이 편한 사람들을 위주로 만난다. 내 얘기 잘 들어주고 어릴적 친구의 그런 편한 느낌을 원한다. 이게 정체다. 내가 만나는 사람들이 달라져야 하면서 동시에 수준이 올라가야된다. 주변에 나를 부끄럽게 만들고 현실 감각을 땅바닥까지 내려가게 만드는 사람들을 많이둬야된다. 불편한 자리를 좋아해야한다.6. 책 중에 가장 위대한 책은 기업가의 자서전이라고 믿는다. 자서전에는 그 사람이 일어나고부터 뭘하는지 누굴 만나는지 어떤 의사결정을 내리는지 세상을 보는 뷰는 어떻게 다른지 다 나와있다. 그들을 미친듯이 따라하고 훔치고 내 장점을 추가시킨다. 최고의 성장 방식이라 믿는다.7. A급 인재는 자발적인 환경에서 최고의 효율을 내고 창의성을 뿜어낸다. B급 인재는 그런 환경에서 괴로워하고 지시를 기다린다. 주도하지 않는다.#페오펫 #peopet #아이디어기업 #기업문화 #목표 #비전 #각오 #인사이트

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

편집자 주 외래어 표기법에 따르면 ‘원어에서 띄어 쓴 말은 띄어 쓴 대로 한글 표기를 하되, 붙여 쓸 수도 있다.’고 규정하고 있다.(제3장 제1절 영어의 표기, 제10항과, 컴퓨터 전문어, 전기 전문어 등) 즉 ‘원칙’과 ‘허용’이 모두 가능하다는 의미다. 이를 바탕으로 여러 표기 용례를 참고한 결과, TableView는 ‘테이블뷰(원칙)’로 표기해야 하나, 본문에서는 독자의 가독성을 높이기 위해 ‘테이블 뷰(허용)’로 표기한다. 응용하여, CollectionView는 ‘컬렉션 뷰’로, TableViewCell은 ‘테이블 뷰 셀’ 등으로 띄어 쓴다. Overview앱에서 데이터를 사용자에게 보여줄 땐 여러 가지의 모습으로 나타납니다. 설정 앱처럼 목록으로 보여줄 때도 있고, 사진 앱처럼 그리드(grid) 형식으로 보여줄 때도 있습니다. 이처럼 데이터를 보여줄 때 많이 사용되는 뷰는 테이블 뷰(UITableView) 또는 컬렉션 뷰(UICollectionView)입니다. 각자 특징이 있기 때문에 앱의 성격에 따라 적절한 뷰를 사용해야 합니다. 왜냐하면 목록을 보여주는 디자인을 바꿀 때, 다시 개발해야 하는 수고를 덜 수 있기 때문입니다. 이번 글에선 각각의 뷰를 간략하게 알아보겠습니다. 목록 형식의 설정 앱과 그리드 형식의 사진 앱 스크린샷테이블 뷰(UITableView)단일 열에 배열된 행을 사용해 데이터를 표시하는 뷰입니다. 수직 스크롤만 가능하며, 테이블의 개별 항목을 구성하는 셀은 테이블 뷰 셀(UITableViewCell) 객체입니다. 테이블 뷰는 이 객체들을 이용해 테이블에 표시되는 행을 그립니다. 여러 행은 하나의 섹션 안에 구성될 수 있으며, 각 섹션은 헤더(header)와 푸터(footer)를 가질 수 있습니다. 섹션과 행은 인덱스 번호로 구별하는데, 번호는 0부터 시작합니다. 테이블 뷰는 plain과 grouped 스타일 중 한 가지의 스타일을 가질 수 있습니다. Plain 스타일은 보통 목록 스타일입니다. 섹션의 헤더와 푸터는 섹션 분리기(inline separators)로 표시되고 스크롤을 할 때 해당 섹션 안에 있는 콘텐츠 위에 나타납니다. Grouped 스타일은 시각적으로 뚜렷한 행 그룹을 표시하는 섹션이 있습니다. 섹션의 헤더와 푸터는 콘텐츠 위에 나타나지 않습니다. 아래와 같은 사진을 보시면 확연히 차이를 볼 수 있습니다. plain 스타일의 연락처 앱과 grouped 스타일의 설정 앱테이블 뷰의 많은 메소드들은 인덱스패스(NSIndexPath) 객체를 매개변수 또는 리턴 값으로 사용합니다. 테이블 뷰는 해당하는 행의 색인 인덱스와 섹션 인덱스 값을 가져올 수 있게 인덱스패스의 범주를 선언합니다. 또한 색인 인덱스와 섹션 인덱스 값을 가지고 인덱스패스를 만들 수 있습니다. 특히 여러 섹션이 있는 테이블 뷰는 섹션 인덱스 값이 반드시 있어야 행의 인덱스 번호로 구별할 수 있습니다.override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"              guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }                 let attraction = attractions[indexPath.row]                 cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.image = attraction.photo                 cell.attractionImage.tag = indexPath.row                 attraction.indexPath = indexPath                 ...                 return cell     } 위의 코드는 데이터 소스(data source) 메소드로, 테이블 뷰의 특정한 위치에 셀을 추가합니다. 다시 말해, 이 메소드는 테이블 뷰가 ‘표시할 새로운 셀이 필요할 때마다’ 특정 행에 노출할 정보가 있는 셀을 만들고 리턴하는 걸 말합니다. 매개변수로 필요한 셀 객체의 행을 가리키는 indexPath 값을 전달합니다. 그리고 indexPath의 row 값을 이용해서 attraction이라는 배열 인덱스로 활용하고, 셀에 표시할 정보들을 설정합니다. 여기서 attraction 배열은 관광 명소들의 정보들이 담고 있는 배열인데, 1행은 첫 번째로 저장한 관광 명소, 2행은 두 번째로 저장한 관광 명소 등 순서대로 설정하도록 indexPath.row 값을 이용하는 것입니다. indexPath의 row 값과 배열의 인덱스 값은 0부터 시작하기 때문입니다. 해당 예제는 섹션이 1인 경우이기 때문에 섹션 인덱스 값이 없지만, 섹션이 여러 개 있다면 반드시 섹션 인덱스 값을 이용해서 설정해야 합니다.테이블 뷰 객체는 데이터 소스(data source)와 델리게이트(delegate)가 필요합니다. 데이터 소스는 UITableViewDataSource 프로토콜을 구현해야 하고, 델리게이트는 UITableViewDelegate 프로토콜을 구현해야합니다. 데이터 소스는 테이블 뷰가 테이블을 만들 때 필요한 정보를 제공하고 테이블의 행이 추가, 삭제 또는 재정렬할 때 데이터 모델을 관리합니다. 델리게이트는 화면에 보이는 모습과 행동을 담당합니다. 예를 들어 표시할 행의 수, 사용자가 특정 행을 터치했을 때, 행의 재정렬 등과 같은 것입니다.override func numberOfSections(in tableView: UITableView) -> Int {         // #warning Incomplete implementation, return the number of sections         return 1     }      override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {         // #warning Incomplete implementation, return the number of rows         return attractions.count     } 위의 두 소스는 데이터 소스가 필수적으로 구현해야 하는 메소드입니다. 하나는 섹션의 개수를 리턴하고, 또 하나는 한 섹션 안에 있는 행의 개수를 리턴합니다.테이블 뷰는 수정 모드에서 행을 추가, 삭제, 재정렬할 수 있습니다. 각 행은 테이블 뷰 셀에 연관된 editingStyle에 따라서 추가, 삭제, 재정렬을 할 수 있는데, 예를 들어 editingStyle이 insert라면 추가하는 메소드를 실행하고, delete면 삭제하는 메소드를 실행합니다. 행의 showsReorderControl 속성이 true라면, 재정렬하는 메소드를 실행할 수 있습니다.// Override to support editing the table view.     override func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {         if editingStyle == .delete {             // Delete the row from the data source             ...                 // delete rows and attractions and reload datas             attractions.remove(at: indexPath.row)             tableView.deleteRows(at: [indexPath], with: .middle)             tableView.reloadData()         } else if editingStyle == .insert {             // Create a new instance of the appropriate class, insert it into the array, and add a new row to the table view         }     } 위 소스는 editingStyle이 delete일 때 셀을 삭제하고 테이블 뷰를 다시 로드하는 기능을 구현한 것입니다.테이블 뷰를 만드는 가장 쉽고 권장하는 방법은 바로 스토리보드에서 테이블뷰컨트롤러(UITableViewController)를 이용해서 만드는 겁니다. 런타임에 테이블뷰컨트롤러는 테이블 뷰를 만들고 델리게이트와 데이터 소스를 자기 자신으로 할당합니다.컬렉션 뷰(UICollectionView)컬렉션 뷰는 테이블 뷰에서 할 수 있는 모든 것을 할 수 있습니다. 섹션을 가질 수 있고, 인덱스패스 값을 이용해서 셀을 구별합니다. 이 셀들은 컬렉션 뷰 셀(UICollectionViewCell)의 서브 클래스이며 데이터 소스(UICollectionViewDataSource)와 델리게이트(UICollectionViewDelegate)가 필요합니다. 셀을 추가, 삭제, 재정렬하는 기능도 구현할 수 있습니다. 그렇다면 컬렉션 뷰와 테이블 뷰를 구분하는 특징은 무엇일까요? 바로 레이아웃입니다. 컬렉션 뷰는 여러 개의 열과 행으로 셀을 표현할 수 있습니다. 예를 들어, 그리드(grid) 형태로 아이템의 목록을 보여줄 수 있습니다. 그래서 수직 스크롤뿐만 아니라 수평 스크롤도 할 수 있습니다.스토리보드에서 디자인한 테이블 뷰 셀과 컬렉션 뷰 셀위 스크린샷에서 테이블 뷰와 컬렉션 뷰의 가장 큰 차이는 바로 셀입니다. 테이블 뷰에서는 하나의 열에 여러 행을 표시하는 형식이기 때문에, 셀의 모습을 행에 맞춰서 디자인합니다. 하지만 컬렉션 뷰는 열과 행을 만들 수 있기 때문에, 꼭 행의 모습이 아니더라도 다양한 모습으로 셀을 디자인할 수 있습니다. 컬렉션 뷰 셀의 가장 큰 특징이기도 하죠. 위처럼 셀을 디자인하고 앱을 실행하면 아래의 화면이 나타납니다.테이블 뷰와 컬렉션 뷰의 앱 화면 차이또한 컬렉션 뷰는 레이아웃 객체가 있습니다. 기존에 제공하는 flow layout을 사용해도 괜찮지만, 본인이 원하는 레이아웃 모양을 custom layout을 만들어서 사용합니다. 이를 담당하는 프로토콜은 UICollectionViewDelegateFlowLayout 입니다.func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {         let fullWidth = collectionView.frame.size.width - (self.CGFLOAT_INSET_WIDTH * 3) - (self.CGFLOAT_ITEMSPACING * 3)         let width = fullWidth/3         return CGSize(width: width, height: width + self.CGFLOAT_HEIGHT_ATTRACTIONCELL_DEFAULT)     }         func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, insetForSectionAt section: Int) -> UIEdgeInsets {         return UIEdgeInsetsMake(self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH, self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH)     } 위 소스에서 collectionView(:layout:sizeForItemAt:) 메소드는 해당하는 셀의 사이즈를 설정하고, collectionView(:layout:insetForSectionAt:) 메소드는 섹션 안에 margin을 설정합니다.여러 모양의 셀을 이루어 하나의 뷰 화면을 구현할 수도 있습니다. 섹션마다 셀을 만들어 각각 다른 모습의 셀을 설정하고, 한 화면에 다양한 모습의 셀을 가진 뷰를 만드는 것입니다. 예를 들어, 헤더, 메뉴, 본문, 푸터 각각 셀을 만들어서 원하는 모양으로 만들고, 하나의 뷰 컨트롤러에 셀을 조합해서 한 화면에 나타나게 할 수 있습니다. 이 방법을 사용하면 자주 사용하는 셀을 재활용할 수 있습니다. 똑같은 헤더와 푸터 셀을 여러 번 만들지 않고 기존의 셀을 재활용하면 시간도 절약하고, 훨씬 깔끔한 소스를 만들 수 있을 겁니다.브랜디 앱 스크린샷 일부위의 스크린샷처럼 여러 화면에서 보여줘야 할 똑같은 뷰가 있을 때, 셀 xib 파일을 만들고 컬렉션 뷰에서 셀을 섹션별로 설정 및 사용하면 재활용하기 좋습니다.Conclusion지금까지 테이블 뷰와 컬렉션 뷰의 특징들을 살펴봤습니다. 한마디로 정리하면 테이블 뷰는 가장 간단한 목록을 만들 수 있습니다. 컬렉션 뷰는 다양한 모습의 목록으로 커스터마이징(Customizing)할 수 있습니다.그렇다면 우리는 어떤 것을 선택해야 할까요? 구현할 목록이 얼마나 복잡한지에 따라 선택은 달라집니다. 테이블 뷰는 간단하고 보편적인 목록을 만듭니다. 반면에 컬렉션 뷰는 특정한 모습의 목록을 만들 수 있습니다. 그래서 테이블 뷰는 목록이 간단하고 디자인 변경이 없을 때만 사용하길 권장합니다. 하지만 나중에 디자인이 바뀔 수도 있다면 컬렉션 뷰를 사용하는게 더 좋겠죠.Simple is the best! 간단하게 구현할 수 있는 건 테이블 뷰를 사용합시다. 테이블 뷰에서 구현하기 힘들다면 컬렉션 뷰를 이용해 개성 있는 목록을 마음껏 만들어봅시다!참고UITableView - UIKit | Apple Developer DocumentationUICollectionView - UIKit | Apple Developer Documentation 글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

 한 달에 한 번 정도 대표님 또는 이사님과 면담을 나누곤 합니다. 두 분이 모두 회사 경영 및 인사에 있어 면담의 중요성을 강조하시는 편이어서 같은 팀원인 저로서는 굉장히 만족스럽습니다. 최근에 진행된 면담에서는 저와 다른 팀원과 문제는 없는지, 특히 인간관계에 대해 많은 말들을 나누었습니다. 그 중 저와 한 프로젝트를 함께 진행하는 다른 팀원에 대한 이야기를 솔직하게 말했습니다. 그 친구와 제가 일하는 스타일이 정반대여서 가끔씩 스트레스를 받는 일이 있었고, 대표님은 이미 회사의 대부분의 사람들이 그것을 알고 있고 일부는 공감하고 있다고 대답했습니다. 그러면서 덧붙이는 말이사람의 단점을 장점으로 변화시키려고 하지말고장점을 더 장점으로 만들 수 있는 방법을 연구하라이 말인 즉슨 여러분도 이미 많이 들으셨겠지만, 같이 일하는 사람의 단점을 바꾸는 것보다 장점을 극대화 하는 것이 더 좋다는 말입니다. 저 또한 이미 이런 말들을 여러 경로를 통해 들어왔고 그것이 저나 그 사람이나 더 편하다는 것을 잘 알고 있습니다. 근데 의문이 들었던 점은 "어떻게 사람의 장점을 극대화 할 수 있을까"하는 점이었습니다. 저는 그래서 어떻게 그 사람의 장점을 극대화할 수 있을까 생각했습니다. 우선 지금까지 저의 잘못된 행동들을 반성해보았습니다.1. 나는 그 사람의 단점을 본다(찾는다)2, 그 사람의 단점을 어떻게 바꿀지 생각한다3. 그 사람에게 이렇게 바꾸면 어떨지 제안한다(요청한다) 위에서 관찰한 저의 행동들은 지극히 부정적인 피드백에 집중되어 있습니다. 그래서 저는 단순히 부정적인 피드백을 긍정적인 피드백으로 바꾸기로 결심했습니다.1. 나는 그 사람의 장점을 본다(찾는다)2. 그 사람의 장점을 어떻게 부각시킬지 생각한다3. 그 사람에게 "당신의 행동이 이런 좋은 결과를 불러왔다"라고 이야기한다 이 행동의 결과는 정말 좋았습니다. 그 친구는 자신이 팀에 기여하는 점이 어떤 부분인지 깨닫고 그 부분을 더 열심히 갈고 닦았습니다.(자세한 결과는 언급하지 않겠습니다. 여러분이 직접 실험해보세요) 부정적인 피드백의 방법과 긍정적인 피드백의 큰 차이는 문장에서도 극명히 차이를 보입니다. 전자의 부정적인 피드백의 방법은 "나"가 중심이 되고 후자의 긍정적인 피드백의 방법은 "그 사람"이 중심이 됩니다. 부정적인 피드백의 방법은 "내"가 그 사람의 단점을 보고 바꿔달라고 요청하는 것이고 긍정적인 피드백의 방법은 "그 사람"이 자신이 행동하여 얻은 결과를 스스로 깨닫고 바꾸도록 합니다. 여러분도 느끼셨겠지만 남이 이렇게 해주세요라고 직접 지시하는 것보다, 자신이 직접 깨닫고 느낀 것이 바로 행동으로 이어지기 쉽지요. 또한 자신이 직접 깨닫는다는 것은 그 행동을 해야하는 동기부여에도 많은 영향을 주는 것이 사실입니다. 더 구체적이고 더 좋은 꿀팁을 하나 더 드리자면, 그 사람의 행동을 칭찬하기 보다는 그 사람 자체의 인격을 언급하는 것이 장기적으로 봤을때 효과적입니다. 사람의 행동을 칭찬하게 되면 그 사람은 칭찬하는 사람으로부터 인정을 받기위해 그 행동을 반복하거나 칭찬하는 사람이 좋아할만 행동을 찾아나서게 됩니다. 반대로 사람 자체의 인격이 어떻다는 사실을 언급하게 되면 그 사람은 자신의 인격에 대해 생각하게 되고 자신이 그런 인격을 가진 사람이 되기위해 노력하게 됩니다. 어린 아이의 예를 들어 간단하게 설명해보도록 하겠습니다. 공부와 운동을 열심히 하는 남들이 보기에도 정말 성실한 아이가 있었습니다. 그 아이에게 긍정적인 피드백을 주는 방법은 아래와 같이 두 가지가 있습니다."공부도 열심히 하고 운동도 열심히 하는구나. 참 잘했다""공부도 운동도 열심히 하는구나. 너는 참 성실한 아이야" 두 개의 문장 모두 긍정적인 피드백임엔 틀림없지만, 전자의 경우 잘했다는 칭찬을 듣기위해 아이는 공부를 잘하기위해, 운동을 잘하기위해 더 노력할지도 모릅니다. 그렇지만 후자의 경우는 어떤가요? 후자의 경우는 긍정적인 피드백이 아이가 중심이 되고, 그 아이는 자신이 성실한 사람이 되기위한 방법이 무엇인지 연구할 것입니다. 여러분만의 긍정적인 피드백을 주는 방법은 무엇인가요? 그리고 사람을 기분좋게 움직이게 하는 다른 방법엔 또 무엇이 있을까요?#비주얼캠프 #인사이트 #경험공유 #조언

CFO인터뷰어제 옐로모바일의2015년 실적 발표가 있었죠.약3,200억원의 매출과470억원의 영업손실을 기록하며 한 해를 마무리했는데요,연 단위의 적자이긴 했으나 마지막4분기에 매출1,000억원과 소폭이지만 영업이익 흑자전환을 이루어낸 것에 대해서는 긍정적인 여론이 형성되고 있는 것 같습니다.국내외 다양한 유니콘 및 독보적 스타트업들이 수익성 확보에 어려움을 겪고 있는 것을 감안할 때,이 정도 규모의 분기 매출 및 흑자전환은 옐로모바일의 재무 성장성 및 건전성에 대해 새로운 시각을 갖게 하는 기회가 될 수도 있을 것 같다는 생각이 들었는데요,이와 관련하여 이상훈CFO와 간단하게 몇 마디 나누어 보았습니다.드디어 분기 영업이익이 흑자로 돌아섰는데요,감회가 새로우시겠어요.하하 실은 예상된 시나리오대로 진행 중이라 실적에 대한 긴장과 감동이 있지는 않습니다만, 그래도 영업적자대신 영업이익이라는 단어를 쓰게 되니 기분은 좋네요 :) 많은 분들께서 잘 모르고 계시는 사실이 있는데요, 옐로모바일은 2014년 상반기까지 영업이익 흑자를 기록하던 회사입니다. 2014년 하반기부터 사업 규모 확장 및 성장 촉진을 위해 다방면의 투자를 시작했고, 2014년 포메이션8 (Formation8)의 투자 이후 2015년 상반기에는 투자 규모를 보다 확대했죠. 이로 인해 2014년과 2015년 각각 영업손실로 한 해를 마무리하긴 했지만,애당초 옐로모바일은 수익을 충분히 낼 수 있는 체력을 확보한 상태였습니다. 수익의 규모를 늘리는 것이 관건이었죠.특히 이번 2015년 연말 실적은 3분기까지 회사 자체적으로 진행했던 가실적 발표가 아닌 금융감독원이 지정한 지정 감사인의 공신력 있는 감사를 통과한 성과라 더 의미가 있습니다. 감사인의 판단 기준에 따라기존 발표내용보다 분기별 영업손실 기준이 조정되어 4분기 영업이익이 20억원대 후반 수준까지 갈 수 있었는데 가지 못한 점은 좀 아쉽지만요.그럼2016년은 영업이익 흑자를 기록할 수 있을 것으로 보시나요?물론입니다. 2015년 투자의 많은 부분이 쿠차에 집행되었는데,쿠차는 이미 월 단위의 흑자전환을 이루었고,계속해서 성장할 플랫폼입니다.또 다른 집중 투자 대상이 미디어 사업을 이끌고 있는 피키캐스트인데,피키캐스트는 올해부터 본격적으로 수익화를 준비하고 있습니다.올 해 안에 연 단위의 흑자 달성은 무리일 수 있지만,적어도 연 내에 월 단위의 흑자는 낼 수 있을 것으로 기대하고 있습니다.이에 더해 광고,여행, O2O사업은 원래도 흑자를 내 온 사업들이기에, 2016년은 무리 없이 연 단위의 영업이익 흑자를 기록할 것으로 예상되며, 2017년이 되면 다섯 개 사업 그룹 모두가 각자 흑자를 달성할 것입니다.그렇군요.그럼 조금 다른 방향에서 질문을 드려볼까 합니다.실은 옐로모바일은 아직 스타트업이고 비상장사인데,왜 이익을 내는데 집중하고 계신가요? 여타의 주목받는 스타트업들도 아직 적자를 기록하고 있는 것으로 알고 있지만 여전히 이익보단 성장에 초점을 맞추고 있는 것 같은데 말이죠.저희가 이익에만 집중하고 있는 것은 절대 아닙니다.성장하는 회사에게는 어찌 보면 매출 성장(Top-line Growth)이 더 중요할 수 있고,그렇기에 저희도 지속적으로 외형적 성장을 이어가고 있습니다.네이버, 카카오, 옐로모바일의 2015 분기별 매출 비교다만,결국 외형적 성장의 끝에 있는 목표는 수익이죠. 국내의 주요 스타트업들 역시 궁극적으로 훌륭한 수익 기반을 마련하기 위해 전략을 수립하고 실행하고 있을 것이라 생각합니다.유니콘의 단계를 넘어선 기업이 수익성을 확보하지 못했을 때 생기는 문제가 조금씩 드러나고 있는 곳이 오늘날의 실리콘밸리인 것 같아요.최근 타임지(TIME)에서도트위터(Twitter)의 수익성 문제를 지적한 적이 있죠.트위터는 상장 이전에 이미4억 달러 이상의 누적 적자를 기록하고 있었고,상장 이후 상황이 극적으로 호전되지 못하고 있는 실정입니다.최근3년 연속 영업손실을 기록하고 있죠.옐프(Yelp)역시 고전을 면치 못하고 있는데요, 2015년4분기에2,200만 달러의 적자를 보이며 네 분기 연속 적자를 기록,주가 관리에 어려움을 겪고 있습니다.물론 상장사이기 때문에 이러한 문제에 더 노출되어 있는 것은 맞습니다.그렇다고 해서 비상장 기업이 성장을 위해 수익성을 간과해도 된다고 생각하지는 않습니다.제가 꼭CFO여서 그러는 것이 아니라,안정적인 수익에 기반하여 성장할 수 있는 회사가 가장 이상적이지 않을까요?그런 의미에서 옐로모바일은 오늘도 성장과 수익이라는 두 마리 토끼를 잡는 쉽지 않은 길을 계속해서 걸어가고 있습니다.기업의 존재 이유가 이윤 추구만은 아닐 것입니다.그러나 동시에 기업의 생존과 지속 가능성을 위해 필수적인 요소가 수익인 것은 부정할 수 없는 사실이죠.스타트업이 언제부터 수익을 내야 하는지에 대한 정답은 없는 것 같습니다.또한 성장성과 수익성이 항상 상반되는 개념도 아닌 것 같고요.빠르게 성장하는 회사가 이익까지 낼 수 있다면,정말 더할 나위 없는 상황이겠지만,설령 둘 중 하나가 조금씩 정체되더라도 꾸준히 나아지는 모습을 보이는 것이 가장 중요한 것이 아닐까 싶습니다.옐로모바일이 어제보다 오늘,오늘보다 내일이 나은 회사가 될 수 있기를 기대해 보며,이상Y였습니다.