가맹점 수수료율 인하로 신용카드사들의 수익성이 악화된다고 한다. 회사들은 수익성 개선을 위해 다양한 노력을 기울이고 있지만, 확실한 개선안을 찾는 것이 쉽지 않은 것이 현실이다. 현재는 고수익을 보장하는 일부 상품 판매를 통해 수익성을 제고하고 있음에도, 장기적으로 이보다 더욱 근본적인 신규 수익원 구축이 필요하다. 작년 MasterCard 본사의 북미 지역 사업개발팀의 Finance MBA 인턴으로 일하던 당시에도 신용카드 산업은 한국의 현재와 다르지 않았다. MasterCard는 Visa와의 산업 내 경쟁뿐만 아니라, Paypal, Venmo 등 신용카드를 거치지 않는 다양한 결제 platform 및 ACH(AutomatedClearing House 자동 어음 교환 시스템)의 위협으로부터 회사의 매출을 어떻게 지켜나갈 것인지에 대해 진지하게 고민하고 있었다.Conversation Suite에서 인턴 동기와의 첫 만남 @ 마스터카드본사전사적으로 전략적인 대책 마련에 들어갔고, 다양한 전략들 중 하나는 신용카드사의 “아는” 힘을 최대한 활용하는 방법이었다. MasterCard는 2015년 4월 빅데이터 기업 Applied Predictive Technologies (APT)사를 인수하였다. 피인수 회사는 Cloud-based Analytics 관련된 회사였고, 회사의 임원이 내가 일했던 북미 지역 사업개발팀 전체 회의에서 발표하고 열심히 논의했던 내용들은 어떻게 MasterCard가 보유한 방대한 data를 바탕으로 수익을 발생할 수 있는지에 대한 고민이었다. 다양한 산업 내 merchant 담당자들은 본인이 거래하는 회사에 어떻게 해당 service를 활용할 수 있을지에 대해 구체적인 action item 을 놓고 토론을 진행하였고, 다소 과열되는 분위기에 추가 회의가 있으리라는 공지로 회의는 종료되었다.현재 이 사업은 MasterCard Advisors의 일부로 운영되고 있다. 당시 기억에 남는 comment는 당장 수익에도 일부 기여하겠지만, merchant들이 사업을 잘 운영하도록 도와주고 거래금액을 늘려서 매출의 증가에 기여하겠다는 내용이었다. 더욱 장기적으로는 merchant와 구축한 관계와 신뢰를 바탕으로 MasterCard에서 출시하는 다양한 모바일 페이먼트 솔루션 mobile payment solution을 전파하는 교두보 역할도 담당할 수 있는 것이다.APT의 역량이 포함된 다양한 MasterCard Advisors Product ListBig data는 최근 경영 관련 가장 큰 화두이다. 빅데이터 기업 APT에서 유래한 APT 역량은 간단하게 말해, 정보들을 분석해서 컨설팅 사업을 하는 데 활용하는 주요 tool이자 test and learn 으로서의 고객 소비 행동 Customer spending behavior를 분석해서 client 사업의 의사 결정에 도움을 주는 것이라 말할 수 있다. 한국의 신용카드 회사들도 다양한 방법으로 “아는” 힘을 발휘하고자 노력하고 있다. 일례로, 하나카드는 다양한 O2O서비스업체들(뷰티, 날씨 등)과 제휴를 맺고 사업을 진행 중이고, 현대카드는 Big data 관련 start-up 회사와 카드 영업 관련 신용평가 시스템을 구축하고 있다고 한다. 신규 사업의 요지는 고객을 상세히 분석해서 최고의 고객 밀착 상품을 제공한다는 것이다.* 하나카드는 "이번 협약을 시작으로 다양한 스타트업 기업과의 전략적 제휴를 통해 O2O 서비스 플랫폼 활성화는 물론, 장기적으로 스타트업 기업을 발굴ㆍ육성한다는 계획이다." 라 말한 바 있다. 하나카드 관련기사>>* 현대카드 금융권 관계자는 "알파고와의 바둑 대결 이후 인공지능(AI)에 대한 관심이 커지고 있는데 머신러닝 또한 금융권 활용 가능한 IT기술로 각광받고 있다"며 "카드업종 경영환경 전망이 부정적인 상황에서 카드업계 대부분 대응 전략으로 '디지털'을 내세우고 있고 빅데이터 분석은 그중에서도 대표적인 분야"라고 설명했다.현대카드 관련 기사>>Knowledge is PowerScientia est Potentia결국, 아는 것이 힘이다.프렌시스 베이컨 (Francis Bacon) 은 지식 확립의 방법으로서 귀납법을 들었다. 이 귀납법에 의하여, 자연을 지배하는 힘을 획득한다고 생각하였다. 개별적인 특수한 사실이나 원리로부터 좀 더 확장된 일반적 명제를 이끌어내는 귀납법처럼, 다양하고 미세한 관찰을 바탕으로 회사는 고객에 대해 많은 것을 배울 수 있고, 그 가르침을 통해 더욱 효율적인 경영이 가능해지는 것이다.회사들이 수익성을 극대화하기 위해서 아는 것이 중요하다면, 우리 개인들의 삶에 있어서도 아는 것이 힘을 발휘하지 않을까. 문득 얼마 전 읽었던 Finda의 창립과 관련한 기사가 떠올라서 다시 읽어보았다. 우리가 금융상품에 대해 더 궁금해야 하고 알아야 한다는 사실조차 잊고 있을 때, “아는” 것이 얼마나 중요한 지에 대해 외치는 소리가 있었다. Finda와 함께 알아가는 금융 세상은 나에게 어떤 힘을 줄 수 있는지 기대된다.핀다의 신규사업 리드김도균 드림 Dogyun from FindaBusiness Consultant*관련기사 : 한국 최초 금융상품몰 꿈꾸는 창업가  http://www.sisapress.com/journal/article/148827[인터뷰] 이혜민 핀다(Finda) 대표한국최초 금융상품몰 꿈꾸는 여성창업가www.sisapress.com #핀다 #운영 #컨설턴트 #시장분석 #노하우

데이터진흥원 DB 스타즈 프로그램에서 연락이 와서 오늘 오후 스타트업 얼라이언스에서 진행했던 스타트업 조직문화 특강. 조직,인사 컨설턴트였다가 조직심리 박사과정을 하고 있고(논문 써야 하는데 ㅜㅜ) 이제는 작은 스타트업의 대표가 된 이력때문에 패스트캠퍼스에서 연락이 와서 시작했던 강의인데 그 이후에 이 내용으로 여기저기서 강의 요청이 와서 신기해하고 있다. 그런데 아마 이 내용으로 강의는 다음 달에 있을 현대아산나눔재단이 마지막이지 않을까 싶다. ^^ '나도 팀원으로 일하고 싶은 스타트업 만들기'라는 다소 유치해보이는 강의제목을 달아놓았는데 실제 우리 마보를 그런 스타트업으로 만들어 놓기 전까지는 내가 그런 말을 하고 다닐 자격이 있을까 하는 생각이 들기 때문이다.우리 마보가 저 제목에 당당한 스타트업이 되면 그때 당당하게 우리의 사례를 알리는걸로! 그러려면 마보 서비스를 더 알리고 우리 마보팀부터 키우는 것으로~덧붙임: 그래도 끝나고 Dable 과 rainist 에서 대표로 오신 두분은 도움이 많이 되었다고 하셔서 기뻤음. 사실 이 강의는 스타트업 CEO분들께 꼭 전달하고 싶은 내용임. 한마디로 요약하면 스타트업 대표가 본인 스스로를 동기부여하는 것이 무엇인지 먼저 생각해보고 직원들을 동기부여하라는 것!#마보 #스타트업 #스타트업강연 #강연후기 #조직문화 #기업문화 #사내문화 #특강 #스타트업CEO

대부분의 프로젝트는 실패한다. 처음 세웠던 계획대로 진행되는 경우는 거의 본적 없다.원숭이도 나무에서 떨어지고, 아키텍트도 당연하게 실패를 자주 만나게 된다. 그리고, 프로젝트는 언제나 성공하지 않는다. 성공과 실패를 거듭할 뿐이다. 여기서, 실패를 어떻게 다루느냐에 따라서 아마추어와 프로의 차이는 극명하게 구분된다.아마추어는 실패를 변명하기에 급급하지만, 프로는 실패를 냉정하게 인정하고, 실패를 하게 된 이유를 찾고, 똑같은 실패를 반복하지 않기 위해서 실패의 원인에 대해서 분석하고 리뷰한다.많은 실패를 거듭할수록 전문가가 된다. 전문가는 실패를 반복하지 않기 위해서 언제나 실패에 대해서 필요한 리뷰 스킬을 높이게 된다. 이번 이야기에서는 필자가 지켜보았던 미니 프로젝트의 하나를 기준으로 실패에 대한 이야기를 해보도록 하겠다.여기서 이야기하는 프로젝트는 처음부터 실패가 될 것으로 예견되었다. 그리고, 그 예견된 결과대로 실패했다. 결론적으로 해당 팀이 해체되었고, 관련된 개발자들은 흥미를 잃고 해당 업체를 떠나게 되는 상황까지 진행되었다.문제가 더욱 심각한 것은 이러한 실패의 이유에 대해서 예견되었고, 그 문제를 지적하고, 향후 그 처리방안을 경영진에게 제시하였지만, 결론적으로 회사의 리더의 생각이 변화하지 않았기 때문에 ‘실패에서 주는 경험’이 제대로 전파되지 못했다. 하지만, 아키텍트는 이러한 실패에 대해서 분명하게 기록해두고, 다시 그러한 실패를 하지 않도록 준비를 하는 것이 전문가로 성장하는 가장 중요한 버릇 중의 하나라고 이야기하겠다. 아키텍트가 아니라고 해도 개발자는 자신만의 노트로 '실패'를 기록해야 한다."어떤 실패한 프로젝트에 대한 리뷰"실패에 대해서 정의할 수 있는가? 이 기준에 대해서 느슨하게 적용하게 되면 대부분의 프로젝트는 실패할 이유가 없어지며, 매우 엄격하게 적용하게 되면 대부분의 프로젝트는 실패라고 기록될 것이다.필자는 프로젝트의 성공과 실패의 요소에 있어 가장 중요한 것은 ‘비용’이 계획보다 많이 투자되었다면 그 프로젝트는 ‘실패’라고 평가를 한다. 가능하다면, 아키텍트를 목표로 하고 있는 개발자라면 모든 프로젝트의 기준과 투입인력, 시간과 하드웨어 리소스들을 모두 ‘비용’으로 환산하는 방법을 터득하는 것이 좋다.가능하다면, 필자는 이 기준으로 프로젝트를 평가한다.이 기준에 따라서 필자가 지켜본 미니 프로젝트를 평가해보자. 소프트웨어 개발자의 실제 일하는 것들이 모두 비용이고, 그들이 투입되고 생각하고, 무언가를 하는 행위들은 대부분 ‘비용’으로 모두 환산할 수 있다. 이러한 비용을 기준으로 프로젝트에 투입되게 되면 초기에 필자가 프로젝트의 기준을 세우는 원칙은 다음과 같다.소프트웨어 디자인과 기획에 30%, 실제 개발에 50%, 테스트에 20%를 투여하는 법칙이다. 다만, 이 수치에서의 약간의 차이는 투입되는 팀원이나 회사의 사정에 따라서 조금씩 달라지기는 하지만, 필자는 가능하면 저 수치를 지키려 한다.그동안의 필자의 경험으로 느껴지는 저 수치는 약간의 조정이 있을 수 있으나, 대부분의 국내의 프로젝트에서는 대부분 일치하거나 근사치로 정의될 것이다. 이번 이야기에서 언급하려는 프로젝트는 2013년도에 필자가 실패한 프로젝트의 사례에 해당한다.이 규칙에서 기획에 30%의 투자가 있었어야 했는데, 실제 초기 기획에 2%도 안 되는 투자 후에 실제 개발이 진행되면서, 프로젝트가 제대로 진행되지 않는 케이스가 발생하였다.물론, 이번의 케이스는 작은 스타트업에서 매우 작은 외주 프로젝트를 진행하는 일이었는데, 실제 프로젝트에 참여할 팀원의 구성이나 팀워크, 주된 목표치에 대한 설정 등이 제대로 서술되지 못하면서 기획이 제대로 진행되지 못한 케이스가 되었다.작은 모바일 프로젝트였고, 필자가 판단하기에 4주면 넉넉하게 해결될 프로젝트가, 필자의 계산착오로 4개월간 뒤틀린 프로젝트가 벌어지게 된 것이다. 필자는 왜 이런 실수를 하게 된 것일까?기본적은 린 개발 방법이나 에자일 방법과 같은 방법론의 문제가 아니라. ‘초기 기획’이 부정확한 상태에서, 팀워크도 갖추어지지 않고, 소통이 안 되는 팀원들이 보고체계가 붕괴된 상태에서 프로젝트가 지속되면서, 팀 자체가 와해되어 버린 아주 엉터리같이 진행된 프로젝트가 되어버렸다.필자도, 이러한 대대적인 실패에 대한 경험을 정말 오래간만에 한 셈이 되었는데, 결론적으로는 프로젝트를 수행할 제대로 된 팀원을 제대로 세팅하지 못한 ‘인사’에서 그 문제는 시작되었다고 프로젝트의 실패 원인 중에 가장 큰 원인을 지적하고 싶다.목표도 불확실한 상태에서 기획이 제대로 진행이 안되었고, 서버 개발자의 능력 부족에 아이폰과 안드로이드 앱 개발자의 자기 멋대로의 전횡과 서버 개발자가 이중으로 서버 인터페이스를 구현하면서 보고체계까지 제멋대로 진행된 아주 최악의 프로젝트가 진행되었다는 것을 거의 프로젝트 후반부에 가서야 알 수 있었다. 말 그대로 전형적닌 실패사례가 된 것이다.결론적으로 이야기하자면, 가장 먼저 이야기한 ‘기획’이란 팀 빌딩과 목표 수립과 같은 부분에 대해서 제대로 된 접근을 수행했어야 했는데, 이 부분에 대한 고려와 협의 없이 진행되면서 프로젝트가 일정에 떠밀려서 진행되면서 프로젝트가 상당히 누더기가 되어버렸다.어떻게든 중간에 올바른 방향으로 유도하려고 하였으나, 언제나 입버릇처럼 말하듯이 ‘한번 기본이 뒤틀린 경우에는 다시 바로 잡을 수 없다’가 정답이고, 그 여파로 인하여, 많은 비용과 시간적인 소모, 정력적인 소비까지 매우 불유쾌하게 진행된 프로젝트였다.결론적으로 이 프로젝트는 마무리는 되었지만, 이 프로젝트를 참여하게 된 팀원들은 모두 해산되고, 서버 개발자만 빼고는 모두 팀에서 해체가 되게 되었다. 물론, 이 프로젝트 이후에 해당 문제들을 보완한 상태에서 다시 프로젝트는 본래의 궤도로 올려놓기는 했지만, 이렇게 진행된 부분에 대해서는 명세 화가 절실하게 필요하고, 이를 리뷰해야 한다.이 프로젝트의 가장 큰 원인은 개발에 참여한 개발자나 디자이나, 기획자나 PM의 문제가 아니라, 전체적인 개발의 틀을 만들어 주어야 하는 ‘개발회사의 경영진’이 가장 큰 문제였다. 말 그대로 ‘인사’ 문제였다. 그중에 몇 가지의 문제들에 대해서 언급해보자."개발자의 의사소통의 문제"후반부에 개발과 관련된 보고체계의 문제점은 서버 개발자와 클라이언트 개발자 간의 의사소통과 의사결정에 대해서 개발자들 간에 ‘숨겨왔던 문제’가 드러났다. 가장 큰 원인은 ‘보고’를 제대로 하지 않았다는 것이다.안드로이드와 iOS의 앱 개발을 동시에 진행하였는데, PM이 인터페이스를 ‘동일’하게 추상화해서 구현하라는 방향성에 대해서 클라이언트 개발자들과 서버 개발자들이 서로 협의한 것이 아니라, 서버 개발자가 클라이언트 개발자들의 요구조건을 모두 받아들여, 인터페이스가 두배로 늘어나고, 테스트와 관련된 처리 방안들이 모두 증가하게 된 것이다.실제, 클라이언트에서 구현해야 하는 상당 부분의 기능들을 서버에서 구현하게 한 것은 향후 Web개발을 일부 처리하기 위한 방안이었는데, 이 부분들이 모두 무시된 채로, 클라이언트 개발자들 간에 자신이 하고 싶은 개발을 추진하면서, 서버 개발자가 의지 없이 끌려다닌 결과물이었다.당연하지만, 개발 일정이 늘어나고, 테스트도 진행되지 못하면서, 품질이 저하되는 것뿐만 아니라, 전체적인 프로젝트가 모두 붕괴되었다. 참으로 애통스러운 상황을 지켜보아야 하는 마음은 참으로 아픈 경험이다.그래도, 최악의 프로젝트였지만 ‘테스트’가 좀 더 명쾌했다면, 이 프로젝트는 초기에 문제를 잡을 수 있을 가능성이 있었다. 그래서, ‘테스트’에 대해서 몇 가지 더 정리해봤다."테스트, 그 계획과 실행의 전부"과연, ‘테스트의 적정선은 어느 정도 인가?’. 소프트웨어 개발에 있어서 테스트에 투입되는 비용이나 기간에 대해서 근접한 수치를 보여주거나 적절한 경험성을 부여하는 경우가 매우 드물다. 다만, 경험자의 직관에 의존하는 경우가 많거나, 각 개발사의 프로세스에 따라서 정형화되어 있는 경우가 많다.실제 자기 자신에게 다음의 화두들을 던져보자.정말로 테스트 커버리지 100%의 테스트란 존재하는가제품 개발 시간과 테스트 코드의 비율은 어느 정도가 적정한가?개발에 착수하기 전에 테스트를 얼마나 준비해야 하는가?통합 테스트는 매번 해야 하는가?테스트 전담자는 있어야 하는가?TDD는 비용 합리적인가?과도한 테스트란 어떤 것을 의미하는가?실제 개발환경에서 테스트란 무엇인가?현장 품질 커버리지란 무엇인가?테스트에 대해서 위의 질문에 대해서 독자들은 얼마나 명쾌하게 답변을 할 수 있을까? 아마도, 다음번 칼럼에는 테스트에 대해서 좀 더 자세한 이야기를 할 것으로 계획을 잡고 있다.테스트에 대한 유명한 Kent Beck의 말을 인용해보자.I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.나는 코드가 작동하는지에 대해 보수를 받지, 테스트를 위해서는 보수를 받지는 않는다. 그래서 나의 철학은 신뢰할 수 있는 수준에 도달하기 위해 가능한 한 테스트를 적게 한다는 것이다.(신뢰할 수 있는 수준이라는 것은 업계 표준에 비해 높다. 조금 거만한 들릴지 모르지만). 만약 전형적인 실수(생성자에서 다른 변수를 설정하는 것 같은)를 하지 않는다면, 나는 테스트하지 않는다.-Kent Beck의 말소프트웨어 개발자들에게 테스트 환경과 테스트 조직, 테스트 문화에 대해서 강요하는 것이 바람직한가?라는 물음에 필자는 이렇게 이야기하고 싶다. ‘개발자’에게 ‘테스트’를 강요하지 말고, ‘테스트한 경과’를 제시하고 ‘수정’과 ‘제대로 된 결과’를 강조하라.일반적인 소프트웨어 개발에 대해서 무지한 사람들의 반복적인 질문은 ‘소프트웨어 개발자들은 왜 테스트를 소홀하게 하는 가?’라는 질문을 버그가 발생할 때마다 이야기를 한다. 대부분의 소프트웨어 개발은 ‘목표’가 불명확하기 때문에 ‘버그’가 발생한다고 생각한다.아마도, ‘개발자’에게 사용자의 ‘제약사항’과 ‘하지 말아야 할 행위’에 대한 언급이 없었다면, 개발자는 문제 해결을 위하여 상당 부분 위험요소를 건너뛰거나 넘어서게 된다. 물론, 적절한 여유시간과 품부 한 리소스를 제공한다면, 당연하겠지만. 튼튼한 소프트웨어를 만들기 위해서 노력한다. 하지만, 일정이 정해지고, 목표가 명확한 SI성의 프로젝트의 경우에는 ‘목표’를 향해서 가장 빠른 코드를 만들기를 강요하기 때문에, 이때에 만들어지는 ‘버그’의 대부분은 개발자의 실수이기보다는, ‘요구사항’에 대한 부정확한 전달 때문이다.별 요구사항이 없는 것 같은 DataGrid를 만들어 달라고 이야기를 했지만, 사실, 고객은 Excel정도의 기능을 원하고 있다. 하지만, 일정과 비용상의 문제 때문에 단순 데이터의 표현을 위한 DataGrid인 것처럼 요구를 하는 경우가 대부분이다.이때에 개발자는 당연한 것처럼 최소한의 제약사항과 요구사항을 통해서, ‘숫자’만을 처리할 수 있는 DataGrid를 만들지만, 고객은 개발에 착수함과 동시에 다양한 요구사항들을 요구한다. 문자열을 처리해달라, 날짜, 함수 등등… 그리고, 종이 출력도 자연스럽게 되게 해달라고 한다.개발자는 중간에 발생한 요구사항과 제약사항에 최대한 맞추려고 기능들을 구현하다 보면, 당연한 것처럼 특정 이슈만 처리하는 기능으로 구현되고, 다른 프로세스에서는 당연한 듯이 버그와 같은 현상을 발생시킨다.그럴 때에 고객은 이야기하고, 개발회사의 사장도 이야기한다. ‘개발자가 테스트도 없이 소프트웨어를 만들고 있다’고. 이것이 현실이다.대부분 소프트웨어 개발에 대해서 무지하기 때문에, 이런 일이 반복된다. 필자도, 이러한 경험을 최소한으로 하려고 하였지만, 역시. 회사의 대표가 되어서 프로젝트의 계약부터 관여하기 전에는 이러한 문제들을 모두 해결할 수 없다는 것이 정답일 것이다.필자는 단언한다. ‘소프트웨어 개발자에게 넉넉한 일정과 풍부한 리소스를 제공하지 못한다면, 소프트웨어 개발자가 모든 것을 해결할 것으로 기대하지 말아라’. 다만, ‘소프트웨어 개발자들이 보다 원활하게 개발에 전념할 수 있도록 다음과 같은 필수조직이 따라붙어야 한다.하나. 요구사항에 대해서 고객과 꾸준하게 소통할 수 있는 담당자나 조직둘. 정해진 일정에 맞추어 기능이 동작할 수 있게 하는 테스트 담당자나 조직하지만, 보통의 스타트업이나 작은 SI를 전담하고 있는 기업의 경우에는 위의 가장 중요한 두 조직이나 담당자들이 대부분 부재중이거나 기능이 모호한 경우가 많으며, 위의 두 가지 기능을 모두 담당 개발자의 책임으로 귀속시킨다.만일 이러한 기능이나 리소스를 모두 담당 개발자에게 귀속시키고 있는 회사나 조직에 있다면, 조직을 다시 만들거나, 해당 기업을 빠른 시일에 빠져나가는 것이 가장 현명한 방법일 것이다. 대부분 소프트웨어 개발에 무지한 경우에 이 두 기능을 너무 소홀하게 하고, 개발자들이 대부분 야근과 휴일근무를 밥먹듯이 하게 되는 경우가 이에 해당된다.실제 필자 또한 경험이 풍부했지만, 실제 기업의 인사권과 경영권이 없었기 때문에 이에 대해서 해결할 수 없는 경우를 또 만났기 때문이다. 그래서, 또 실패했다. 아무리 경험 많은 사람이라고 하더라도, 이미 알고 있는 내용이라고 하더라도. 그것을 실제 바꾸지 못한다면, 필패한다는 것이 소프트웨어 개발의 현장이다.그래서, 필자도 크게 실패한 경험을 또 하나 기록에 남기게 되었다."체계적인 품질관리 지표"개발과정에서 발생되는 요구사항의 지표에 대해서 NIPA의 SW Visualization을 참조하면 요구사항 추적성, 요구사항 달성률, 요구사항 커버리지의 3가지 지표에 대해서 서술하고 있다. 여기서, 달성률과 커버리지는 100% 처리가 되는 것을 목표로 움직이는 정략적인 지표로 보면 되고, 실제 개발현장에서 주목할 부분은 요구사항 추적성을 주목해야 한다.개발 공정별로 요구사항의 일관성이 어떻게 유지되고 있는지 확인하면서, 형상관리가 등록된 내용의 변경률과 비교하면서 요구사항의 변화된 추이를 꾸준하게 주목해야 한다. 대부분, 이 부분 때문에 개발이 뒤틀리는 진입점을 제공하게 된다.품질검증에서 사용되는 정적인 테스트는 ‘코딩 표준 준수율’과 ‘메트릭 만족률’, ‘정적 분석 이행률’을 기반으로 진행된다. 대부분 이 정적인 테스트는 ‘자동화 도구’를 사용하여 코드의 룰과 만족 여부를 확인하기 때문에 결국은 ‘개발 비용’을 얼마나 투자하느냐에 달려있는 부분이라고 할 수 있다. 특히, ‘정적 분석 이행률’과 같은 SW 실행 전에 잠재적인 결함을 분석하는 것은 이러한 투자 없이는 대부분 이룰 수 없는 수치이다. 그래서, 보통 ‘정적 테스트’는 제대로 갖추어진 개발 조직이 아니라면 성립하기 어려운 지표가 된다.보통, 이 ‘정적 테스트’ 지표를 얼마나 진행하고 있느냐에 따라서, 소프트웨어 개발 조직의 성숙도를 체크할 수 있으며, 소프트웨어 개발 조직에 얼마나 투자를 하고 있느냐에 대해서 알 수 있는 지표이기도 하다.보통은 품질검증에서 동적 테스트로써 요구사항 검증방법과 구조 검증방법이 진행되는데, 마찬가지로 구조 검증인 구조적 커버리지 또한 Basic path, Statement, Branch, MD/DC Coverage 등을 선택해야 하므로, 이 또한 개발 조직의 투자 없이는 이루어지기 힘들다. 그래서, 대부분의 개발 조직 현장에 가보면 기능 검증, 비기능 검증, 정형 검증, 사용자 검증 중에 기능 검증과 사용자 검증만을 취해서 품질검증을 하는 경우가 대부분이다.소프트웨어 개발자에게 ‘품질검증’을 제대로 요구하기를 원하는 조직이라면, ‘정적 테스트’를 수행할 수 있는 투자나 일정, 준비 또는 품질 관련 조직이 세팅되어 있어야 한다. 이러한 단계 없이, 개발자에게 ‘테스트’를 제대로 하지 않는다고 강요하는 개발회 사는 정말 크게 잘못된 케이스라고 보면 된다. 그런 회사는 배울 것도 없으니 피하는 것이 최선이다.또한, 기능 검증이나 비기능 검증 또한 테스트 케이스에 대한 자동화된 방법들을 사용하지 않는 다면, 이 또한 개발자에게는 상당히 모호한 테스트들만이 존재하게 된다."좌우지간, 소프트웨어 개발의 시각화"소프트웨어 개발의 경험자라고 하더라도, 소프트웨어 개발 현장에서 일어나는 일들을 모두 파악할 수 있는 방법은 ‘지감’밖에 없을 것이다. 그래서, 소프트웨어 개발에 있어서 적정한 범위까지 개발의 과정을 ‘시각화’하는 기준이 필요하다.하지만, 이 ‘시각화’는 말 그대로 ‘과비용’으로 책정되거나, 소프트웨어 개발을 하기도 어려운 일정과 시간에 촉박한 경우에는 이 시각화의 최소 영역에 대해서 고민하고 결정해야 한다. 완전한 시각화를 이룰 경우에는 소프트웨어 개발 관리조직과 품질조직, 테스트 조직 등의 PM관리체계가 완비되어 있는 경우에만 이러한 과정을 수행하는 것이 최선이다.그리고, 중요한 케이스나 문서 등에 대해서 품질관리 조직과 PM조직이 해당 문서를 작성하는 것이 되어야지, 각 개발자에게 이러한 업무를 전가하는 방식으로 진행되어서는 문제가 해결되지 않는다. 언제나, 품질조직은 옥상옥이 되어서는 안된다.2/2페이지결론적으로 '능력 부족한 개발자'소리를 듣는 것이 대부분이다.대부분 급하다고 일을 의뢰하거나 서비스 론칭을 위해서 급하게 요구하는 경우가 있다. 개발자의 선택은 매우 명쾌하다. 정해진 기간과 인원 숫자로 만들어야 하는 서비스가 특정한 시간 내에 동작하게 하는 방법은 동작시에 제약사항과 커버하지 못하는 품질 이슈를 만드는 것뿐이다.말 그대로 기술적 부채를 만들어 낼 수밖에 없으며, 이 기술적 부채는 결론적으로 반복적인 유지보수 업무와 처리하지 못하는 기능들에 대한 하소연을 만들어 낸다.슬프지만 그렇게 반복되는 과정에서 경영진은 해당 개발자를 신뢰하지 못하게 된다. 그리고, 그렇게 반복적인 유지보수 업무를 만든 것은 개발자의 능력 부족이라고 생각하게 되고, 이 관계는 보고서가 늘어나거나 주간회의시에 디테일하게 보고하라는 식의 결론으로 귀결된다.물론, 이런 상황을 만든 '착한 개발자의 결정'이 문제이기는 하다.대부분 경험이 풍부한 개발자들은 이런 과정들을 반복해 보았기 때문에 처음부터 거부하거나 거절하거나, 적정한 선에서 타협하는 방안들을 제시한다. 물론, 그 과정에서 무지한 경영진과 트러블이 발생하는 것도 다반사이다.이 경우 중간관리자가 개입해서 타협하는 경우가 분명 있다.단언컨대 해당 중간관리자는 둘 중 하나이다. 무지하거나 난파하려는 개발 조직을 재빠르게 떠날 사람이다.소프트웨어 개발에서 '급한 일'이란 없다.정해진 규칙과 기본에 충실하게 하고, 빠진 것 없는지 체크하고 디자인, 설계 후에 미래의 변화에 대해서 적절하게 해당 조직의 규모와 형태에 따라서 반영한 후에 '개발'하는 것이다.지금 이상황에도...'급한 일'이라면서 일을 가져다주는 경영진을 만나고 있을 슬픈 개발자들을 위해서...끄적끄적...#와탭랩스 #와탭 #프로젝트 #인사이트 #경험공유 #조언

며칠 전에 대출 건으로 XX보증기금에 방문하였다. 다행히도 소개를 받고 간 자리인지라 분위기는 부드러웠고 호의적이었는데.. 지금 하고 있는 paffem 서비스에 대한 이야기(특히 고생하는 파트와 성장하고는 있지만 아직 미약한 매출액)를 듣던 중, 상담하시던 분께서 이런 질문을 던지셨다.그럼 대표님이 직접 Box도 포장하고 그러세요....? 학벌도 좋으시고.. career도 좋으신데...그거 왜 하세요?다소 충격적인 질문이었다.물론 그 자리에서  이런저런 이야기를 하지는 않고, 그냥  웃어넘겼는데.. 이 질문에 대한 나의 대답이 필요하긴 하다는 생각이다.일단 본격적인 이야기로 들어가기 전, 몇 가지 전제가 필요하다. 우선 사람은 모두 성향이 다르다는 것이다. 모든 사람들이 startup과 같은 도전적인 일을 즐길 필요도 없고.. 공무원과 같이 안정적인 직장이 좋다고만도 할 수 없다. 어떤 스타일이 본인과 성향과 잘 맞느냐의 문제이고.. 그 영역에서 본인이 원하는 것을 이룰 수 있다면 다행인 인생이라는 생각이다.나는 5년간 BCG에서 전략 컨설턴트로써의 경험과 삼성전자 GMO에(글로벌마케팅실)서의 경험을 통해... 나는 절대로 대기업 체질이 아니라는 것을 확실히 깨달을 수 있었고,그리고 Groupon KOREA CMO로써 1.5년 정도를 일한 결과..  Startup을 만들어 한번 해볼 만하다는 나름의 자신감을 얻게 되었다.그렇다면, 다시 위의 질문 "그거 왜  하세요?"에 대한 나의 대답을 정리해볼 차례이다. 이것은 나의 인생관과 가치관과도 연결되는 부분인데.. 나의 인생을 살아가는데 있어서 중요한 목표는 "다양한 경험"이다. 그 경험 안에는 일에 대한 경험, 다양한 문화, 도시, 자연.. 그리고 음식, 사람 등등의 모든 것들이 들어가 있다고 봐도 될듯하고, 나름 그러한 것들을 실천하기 위해서 살아왔다.자 이제 구체적으로 정리해 본다면..1. 일의 재미와 성취감정말 중요하다. 지금의 파펨이라는 perfume subscription service를 만들고 나서는 평일에는 거의 24시간을 그 생각을 한다고 해도 과언이 아닌데.. 그 이유는 재미있기 때문이다.  하나하나 고민하는 것이 재미있고, 그 고민을 해결해나가는 과정 (desk job 일수도 있고, 방산시장을 헤매고 다니는 것일 수도.. 혹은 다른 사람을 만나 이야기하는 것일 수도 있다)이 재미있다. 물론 그만큼의 스트레스도 동반되지만, 스트레스라는 것이 답답한 조직 내 hierarchy 라던가, 불필요한 업무를 통해 발생하는 것이 아니기 때문에 나는 건강한 스트레스라는 생각을 한다.또한 성취감이다. 위에 말했듯이 아직 파펨은 론칭한지 6개월이고, 나름의 성장 (월평균 100% 성장을 하고  있다....라고 말하지만 첫 달 매출이 워낙 적어서 나타나는 착시현상임을 고백.. ^^;;)을 이루고 있고, 내가 만든 브랜드와 제품이 나날이 upgrade 되고 있다. 큰 조직에서는 느낄 수 없는 재미이고,  컨설턴트였다면 그 실행의 맛을 느껴보지 못했을 것이다. 하지만 지금은 그 재미를 피부로 느끼며 살고 있다Paffem 런칭 파티때 presentation 하던 모습을 누가 찍었을까....2. High Risk High Return냉정하게 이야기하면, 지금 이 시간에 취업을 하여 월급을 받는다면 적지 않은 금액을 받을 수 있다.(라고 생각만 하고 확신은.. 좀 ㅎㅎ)  아무튼 기회비용이라는 것이 적지 않은 것은 사실이다. 하지만 지금 하고 있는 일을 통해 보다 큰 return을 기대할 수 있고  그것을 내 손으로 만들어 간다는 것이 매력이다. 난 risk taker라고 말하긴 어렵지만.. high return을 추구하는 스타일은 맞다고 말할 수 있는 조금은 어정쩡한 사람이다.또한 하고 싶은 것, 갖고 싶은 것... 이 너무 많고 그것들을 이루기 위해서는 high return이 필요하다. 물론 high risk 이겠지만...  난 이미 이 곳에 들어온 이상 high risk는 의미가 없다. 그저 risk를 낮추는 작업을 계속해야할 뿐..."물론 지금 한 가정의 가장으로써 만약에 wife의 헌신이 없다면... 이런 모험도 해보지 못했을 것이 자명하다. 다시 한번 그분께 감사의 인사를.. 꾸벅"3. 일하는 시간 외에 또 다른 시간이 필요해 &... money컨설턴트로 일하던 시절에는 내 시간이란 거의 없었다. 매일 새벽 1~2시까지는 일을 하는 것이 당연했고, 금요일 저녁에는 만취하도록 마시고는 토요일 늦게 일어나 잠시 쉬다가..  일요일부터는 다시 일을 하는 삶이었다. 그러던 중, 나 자신의 시간을 마련하기 위해서 시작한 것이 화실에 drawing을 하러 간 것이었고, 매주 주말마다 거의 빠지지 않고 화실에 가서 그림을 그렸다.나만의 시간이 필요한 것이다. 내 삶을 조금 더 "맛있게" 만드는 시간들이 필요했던 것이고, 그 이후로는 하고 싶은 많은 것들을 하면서 살자고  맘먹었다. 가고 싶은 여행도 하고 (e.g. Road trip, Coast to Coast in USA), 맛있는 것들을 찾아 먹는 즐거움을 음미하고, 좋아하는 골프에 시간과 돈을 투자하여 좋은 핸디캡도 만들고...그러기 위해서는 시간이 필요하고, 나의 시간을 만들기 위해서는 financially 여유로움은 필수 불가결이다.일반적으로 더 큰 문제는... "시간과 돈이 있어도 본인이 무엇을 좋아하는지 몰라서 아무것도 하지 못하는 것"이다. 그저 정해진 길들을 따라가는 인생.. 나의 20대 중반까지의 삶도 그럴  수밖에 없었다.4. 그 시간에 해야 할 것들...이제 한국 나이로 39세가 되었는데.. 난 지금 이 나이에 하고 싶은 것은 지금 해야 한다고 생각하고 살고 있다. 지금 건강한 몸으로 여행을 가는 것과, 은퇴 후 무거운 몸을 이끌고 동일한 여행지를 가는 것과는 큰 차이가 있고, 젊어서 해야 할.. 바꿔 말하면 그 나이에 해야 할 것들이 있다는 것이다. 그렇게 생각하면 시간이 아깝다.일을 하는 것도, 그리고 이렇게 도전적인 일을 하고, 엄청난 pressure 하에서 일을 해보는 것도 바로 지금 이 시간에 해야 할 것이라는 생각이다.이것이 파펨의 사무실! 친구가 운영하는 클럽 공간을 낮에 활용중내가 만약 40대가 넘었고, 아이가 학교를 다니기 시작해서 뭔가 도전을 하기에 부담스러운 상황들이 된다면  startup이라는 것은 이래저래 꿈꾸기 어려운 환상이 될 것이다. 지금까지의 10년이 조금 넘는 직장 경험과 knowledge, 그리고 network 이 지금 바로 paffem이라는 비즈니스를 만들어 내기에 적절하다는 생각이다.게다가.. 아들이 만 네 살이 된 지금, 그 아이가 커가는 모습을 좀 더 자세히 그리고 같이 볼 수 있다는 점이 참 큰 혜택이다. 맨날 직장에서 지쳐 돌아오고.. 피곤하다며 주말에는 잠을 자야 피로를 풀 수 있는 상황이 발생했던 많은 선배들은, 자식들이 벌써 이렇게 커버렸다며 한탄을 하곤 했다.5. 마지막으로..내 시간은 내가 control 한다.이 이야기가 어떻게 보면 결론적인 것인데..나이가  들어갈수록 재산이 많은 것과 시간이 많은 것 중에 어떤 것을 선택할  것인가?라는 질문에 아마도 시간이 많은 것(좀 바꿔 말하면 젊은것)을 택할 것이다.하지만 시간이 "있는 것"과.. 그것을 "자신이 control or manage"한다는 것은 다른 의미라는 생각이다. 내가 일을 하고 싶을 때 하고, 쉬고 싶을 때 쉬는 것과.. 일을 해야 하는 시간이기 때문에 일을 하고 퇴근을 하는 것은 큰 차이가 있다. 내 시간을 내가 control 할 수 있다는 것이 굉장히 쉽지 않다는 것은 30대 후반쯤 되어서 깨달을 수 있었던 것인데.. 그 이유는 그렇게 하기 위해서는 많은 것들, 예를 들면 금전적인 상황, 직업의 자율성, 가정의 상황, 건강 이런 것들이 모두 맞물려 있는 것이고, 그것들이 모두 잘 맞아 들어갈 때나 가능하다는 점이다.스타트업 그거 왜하세요? (1) 에서는 내 개인적인 이유에 대해서 늘어나 보았다. 하지만, 회사가 존재하는 이유는 그것 말고도 다른 의미가 많다는 생각이고, 그것에 대해서는 두번째 글에서 더 써보고자 한다..To be continued..... 그래서 제가 이거 합니다.#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

OverviewAWS CodeStar를 이용하면 애플리케이션의 개발-빌드-배포까지 빠르게 진행할 수 있습니다. CodeStar는 몇 가지 장점을 가지고 있는데요. 오늘은 간단한 Python App Service Tutorial을 통해 CodeStar를 사용하는 방법을 알아보겠습니다. CodeStar의 장점통합된 UI로 한 번에 여러 활동 관리 가능Continuous Delivery 도구 체인을 구성해 신속한 코드 배포 가능소유자, 기여자 및 최종 사용자 추가로 안전한 협업 가능Dashboard를 사용해 전체 개발 프로세스의 진행 상황 추적 가능CodeStar 사용하기1-1. 처음 CodeStar를 실행하면 나오는 화면입니다. ‘Start a Project’를 누르면 프로젝트 템플릿을 선택할 수 있습니다. 1-2. 이것은 아직 지원되지 않는 지역(Region)에서 노출되는 화면입니다. 2-1. ‘Start a Project’를 클릭하면 프로젝트 템플릿을 선택할 수 있습니다. 2-2. Python과 AWS Lambda를 이용해 Web service를 구현해보겠습니다. 3. Project Name을 지정하고 repository를 선택합니다. 여기서는 AWS CodeCommit으로 선택하여 진행해보겠습니다. CodeCommit의 경우 Repository name을 따로 지정할 수도 있습니다. Repository name까지 지정했다면 Next를 클릭합니다. 4. 아래의 화면은 프로젝트의 흐름입니다. CodeCommit에 소스가 저장되고 AWS CodeBuild를 통해서 Build와 Test가 진행됩니다. 그리고 AWS CloudFormation을 통해서 Deploy가 진행되며 Monitoring은 Amazon Cloud Watch를 통해 진행합니다. CodeStar의 경우 IAM 사용자에 AWSCodeStarFullAccess 관리형 정책을 적용합니다.1) 5. Create Project를 클릭하면 프로젝트가 생성되고, CodeStar 유저 설정을 할 수 있습니다. 6-1. 이제 editor를 선택해봅시다. Command line tools, Eclipse, Visual Studio 등을 고를 수 있습니다. 툴은 언제든지 바꿀 수 있으니 여기서는 Eclipse를 이용하여 프로젝트를 진행하겠습니다. 6-2. See Instructions를 클릭하면 Eclipse를 다운로드 받아 설정하는 방법을 볼 수 있습니다. 6-3. 이제 Eclipse를 설치하고 AWS Toolkit for Eclipse를 설치해보겠습니다. Eclipse의 종류는 Eclipse IDE for java EE Developers 에디션을 설치하겠습니다. 다른 버전은 AWS Toolkit 설치할 때 의존성 문제가 발생할 수 있습니다. 7. Eclipse를 설치하고 Eclipse Marketplace에서 AWS Toolkit for Eclipse 2.0를 설치합니다. 8-1. import를 클릭하고 8-2. AWS -> AWS CodeStar Project를 선택합니다. 8-3. 지역(Region)을 선택하면 해당 지역의 CodeStar 프로젝트를 import 할 수 있습니다. 이 때 CodeCommit의 HTTPS Git credentials를 입력해야 합니다. 9. IAM -> Users -> 사용 계정을 선택해 HTTPS Git credentials for AWS CodeCommit에 가면 User Name과 Password를 Generate 할 수 있습니다. (아래 이미지에 민감한 정보는 삭제했습니다.) 10. CodeStar에서 Project를 Eclipse에 import한 모습입니다. buildspec.yml, index.py, README.md, template.yml이 clone 된 것을 확인할 수 있습니다. 11. 브라우저의 Eclipse 설치 설명 화면에서 back을 클릭해 에디터 선택 화면으로 돌아갑니다. 12. 도쿄 지역에 아직 출시되지 않은 Cloud9은 선택을 마치면 자동으로 셋업이 완료됩니다. 그러나 Eclipse는 Skip을 클릭해야 CodeStar Dashboard로 이동할 수 있습니다. 13. CodeStar Dashboard에 진입하였습니다. IDE는 이미 설정이 끝났으므로 I have already done this를 선택합니다. 화면 하단에 파란색 직육면체가 계속 그려지면 deploy가 완료된 상태가 아니므로 조금 기다렸다가 refresh를 해줍니다. 14-1. deploy가 완료되면 위와 같이 Team wiki tile, Application endpoints, Commit history, Continuous deployment, Application activity등이 나타납니다. 14-2. JIRA를 연동해서 사용할 수도 있는데, 그 내용은 다음에 다루겠습니다. ???? 15. 우선 첫 deploy가 완료된 것을 자축하며 Application endpoints를 클릭합니다. 개발자들에게 굉장히 익숙한 “Hello World”가 나옵니다! 간편하게 소스를 deploy 하여 AWS Api-Gateway와 연결했습니다. 이제 각 파일의 용도에 대한 설명과 새로운 method를 추가하는 작업을 진행해보겠습니다. 16. 이미지처럼 sample.py 파일을 추가하고 아래 코드를 추가합니다. import json import datetime def handler(event, context):     data = {         'output': 'Sample! pathParameters test = ' + event["pathParameters"]["test"]     }     return {'statusCode': 200,             'body': json.dumps(data),             'headers': {'Content-Type': 'application/json'}} 17. 그리고 template.yml에는 아래 내용을 추가합니다. — template.yml —  Sample:     Type: AWS::Serverless::Function     Properties:       Handler: sample.handler       Runtime: python3.6       Role:         Fn::ImportValue:           !Join ['-', [!Ref 'ProjectId', !Ref 'AWS::Region', 'LambdaTrustRole']]       Events:         GetEvent:           Type: Api           Properties:             Path: /sample/{test}             Method: get — 18-1. 이제 수정한 내용을 CodeStar에 반영해보겠습니다. 프로젝트에서 오른쪽 클릭을 해 Team -> Commit을 선택하고 Commit합니다. 18-2. 수정한 파일을 Commit하고 Push합니다. 18-3. Dashboard를 보면 Commit history에 Commit 내용이 반영되었습니다. 19-1. Dashboard에 Continuous deployment를 보면 Source -> Build -> Deploy를 통해서 수정한 내용이 반영되는 것을 실시간으로 확인할 수 있습니다. 이 작업은 생각보다 시간이 많이 소요됩니다. Deploy까지 Succeeded로 완료가 되면 새로 만들어진 URL을 클릭합니다. 19-2. 아래와 같이 pathParameters가 정상적으로 출력되는 것을 확인할 수 있습니다. 20. 이어서 새로 만든 API에 단위테스트를 추가해보겠습니다. sample_test.py라는 파일을 만들고 아래 코드를 추가합니다. — sample_test.py — from sample import handler   def test_sample_handler():         event = {         'pathParameters': {             'test': 'testMessage'         }     }         context = {}         expected = {         'body' : '{"output": "Sample! pathParameters test = testMessage"}'         ,'headers': {             'Content-Type': 'application/json'         },         'statusCode': 200     }         assert handler(event, context) == expected  — 21. 그리고 buildspec.yml 파일을 아래와 같이 수정합니다. — buildspec.yml —  version: 0.2 phases:    install:     commands:       - pip install pytest    pre_build:     commands:       - pytest    build:     commands:       - pip install --upgrade awscli       - aws cloudformation package --template template.yml --s3-bucket $S3_BUCKET --output-template template-export.yml artifacts:   type: zip   files:     - template-export.yml  — 22-1. Commit을 진행합니다. 그리고 다시 Source -> Build -> Deploy 를 거쳐서 Succeeded가 되면 Build 부분의 CodeBuild로 들어가서 Build 결과를 확인합니다. 22-2. 맨 마지막에 Build 결과를 클릭하면 Build 상세 내역을 확인하실 수 있습니다. 22-3. Build logs부분을 보면 sample_test.py를 이용한 단위테스트가 정상적으로 진행된 것을 확인할 수 있습니다. Conclusion지금까지 CodeStar를 이용한 간단한 튜토리얼을 진행했습니다. 다음 화에서는 다양한 방법으로 CodeStar를 활용할 수 있는 방법을 소개하겠습니다. CodeStar에 대한 자세한 내용은 여기를 참조하세요. 참고 1) AWS CodeStar 설정글윤석호 이사 | 브랜디 CTOyunsh@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유 #CTO

오프라인 고객 분석 솔루션 워크인사이트를 개발해 온 조이는 최근 온라인 접객 서비스 채널을 런칭했습니다. 이 글은 채널과 관련된 기술 블로그의 첫번째 글로 채널 데스크 프론트엔드(웹, 윈도우, OSX)의 기술 스택 및 개발 환경을 소개하도록 하겠습니다.React채널 개발을 처음 시작할 당시 (지금으로부터 1년 전) 에 워크인사이트 대시보드 및 기타 사내 툴에서는 AngularJS 1을 사용하고 있었습니다. 비교적 적은 코드로 복잡한 애플리케이션을 빠르게 만들 수 있는 점에는 만족했지만 퍼포먼스면에서는 아쉬운 부분이 많았습니다. 따라서 새로운 프레임워크 및 라이브러리를 리서치 했고 매우 가볍고 렌더링 퍼포먼스 면에서 AngularJS 1 대비 우위에 있던 React 를 사용하기로 결정했습니다.컴포넌트의 설계 패턴은 Redux를 만든 Dan이 제안한 Container 와 Presentational 컴포넌트를 구분하는 방식으로 설계하고 있습니다. 따라서 Container 가 data fetch 및 update 등의 액션을 실행하고 Presentational 컴포넌트들을 조합하여 렌더링을 하게 됩니다.React를 실제 1년째 사용해 본 결과 저를 비롯한 팀원들은 매우 만족하고 있습니다. 구조, 스타일, 동작을 한 컴포넌트로 묶어 재사용성이 매우 높아졌으며 React의 휴리스틱한 Dom diff algorithm 덕분에 렌더링 퍼포먼스에서도 많은 이득을 얻을 수 있었습니다.Facebook Flux Utils아키텍쳐는 페이스북이 제안한 flux 철학에 따라 설계되었습니다. flux를 구현하기 위한 기본적인 유틸리티 기능을 제공하는 Flux Utils을 사용합니다. Flux의 많은 구현체 중에 요즘 가장 인기인 Redux도 고려했었습니다. 저희가 프로젝트를 시작할 당시에 Redux는 5~6개월밖에 되지 않은 프로젝트였고 거의 Dan의 1인 프로젝트였기 때문에 향후 메인터넌스를 장담할 수 없다고 판단했습니다. 그보다는 페이스북이 만든 Flux Utils가 그런 면에서는 더 안전할 거라고 생각했던 것이죠.약 1년 정도 Flux Utils로 개발해오며 몇 가지 문제를 겪게 되었습니다. 애플리케이션이 커지면서 관리해야할 State가 많아지고 그들 사이의 의존성 관리 때문에 Store의 복잡도가 빠르게 증가했습니다. 그에 따라 테스트가 어려워지고 올바른 유닛테스트를 위해서는 테스트 코드 역시 매우 복잡해지는 문제가 있었습니다.그래서 Redux를 다시 리서치하게 되었고, 결론적으로 “단일 Store, 다수Reducer” 라는 Redux의 철학을 통해 State 관리 로직(Reducer)을 단순하고 테스트도 쉽게 유지할 수 있겠다는 생각을 하게 되었습니다. 뿐만 아니라 그 동안 설계와 관련되어 고민하고 필요한 경우 저희 스스로 개발해서 사용하던 많은 부분이 Redux의 서브 프로젝트 형태로 (redux-actions, redux-thunk, reselect 등) 개발되어 사용되고 있는 것을 발견해서 Redux로의 마이그레이션을 결정했고 현재 진행 중에 있습니다.Electron이 글의 도입부에서 이야기한 것처럼 채널 데스크는 윈도우용, OSX용 애플리케이션으로도 제공됩니다. 채널 개발 초기 당시 윈도우, OSX 각각 네이티브로 만들 리소스가 부족했기 때문에 웹 기술 기반으로 네이티브 앱을 만들 수 있는 다양한 솔루션들을 리서치했고 그 중 Electron을 선택하게 되었습니다.Electron은 제가 정말 좋아하는 제품인 Slack, Simplenote에서 사용하고 알려져 있고 국내에서는 Remember 등에서 사용하고 있습니다. 초기 개발 당시에는 안정성에 의문을 제기하는 개발자들도 많았고 저희도 여러 문제와 삽질(인증, 패키징, 이슈 레포팅의 어려움, 메모리릭 등등)을 많이 겪긴 했습니다만 개인적으로는 충분히 프로덕션에 쓸 수 있을 정도 수준이라고 생각합니다. 무엇보다 프론트엔드 개발자가 매우 적은 노력으로도 네이티브 데스크탑 앱을 만들 수 있는 장점이 다른 모든 문제점을 상쇄하고도 남습니다.언어개발 언어로는 자바스크립트 ES6를 사용합니다. 언어를 선택할 당시에도 여러 옵션이 있었는데 가능하면 실험적이지 않고 표준을 사용하는 것이 미래 유지보수에 안전하다고 판단했습니다. 또한 다른 자바스크립트 대안 언어를 사용하지 않더라도 ES6 (일부 ES7 포함) 스펙도 충분히 효율적인 개발이 가능하다고 생각했습니다.코딩 스타일은 기본적으로 Airbnb의 코딩 스타일 가이드라인을 따르며 조이의 상황과 맞지 않는 부분은 엔지니어들과 상의 후 수정해서 사용하고 있습니다. 스타일 체크는 ESLint로 자동화한 뒤 Circle CI와 붙여서 모든 풀리퀘스트에 대해 점검하고 있습니다.테스트초기 개발할 때는 테스트 코드를 별도로 붙이지 않았습니다. 고객의 요구와 기타 상황에 따라 기획과 설계가 크게 변경되기도 했고 그 때마다 기민하게 반응하기 위해서, 어느 정도 확립된 제품이 되기 이전에는 테스트 코드는 작성하지 않는 것이 좋다고 판단했습니다. 이제는 많은 부분이 확정되었고 안정성이 중요해지기 시작했으며 애플리케이션이 커지면서 자동화된 테스트는 필수가 되기 시작했기에 최근에 도입을 하고 있습니다.테스트를 위한 도구는 Jest, Enzyme 등을 사용합니다. Presentational 컴포넌트에 대한 테스트는 props에 따라 원하는 형태로 렌더링이 이루어지는지, 이벤트에 따라 콜백이 잘 실행되는지 등의 Spec 을 작성합니다. Container 컴포넌트에 대한 테스트는 각종 이벤트 및 동작을 시뮬레이션하고 그에 따라 Action이 잘 발생하는지 또는 내부 state가 잘 변경되는지를 테스트합니다. 또한 Store (또는 Reducer), Action Creator, Model, Util 등 모든 구성 요소에 대한 테스트를 붙이려고 노력하고 있습니다. 유닛 테스트가 아닌 e2e 테스트 혹은 css 스타일 테스트 등은 하지 않고 있습니다.빌드 및 배포현재 채널 데스크는 Client-side rendering을 합니다. 초기 로딩 속도가 느리다는 단점이 있어서 Server-side rendering으로의 전환도 고려하고 있습니다. 이미 Node.js 를 사용하고 있어서 Isomorphic Javascript의 형태로 어렵지 않게 전환이 가능합니다.작성된 자바스크립트는 Babel로 컴파일되고 Webpack으로 번들화됩니다. css를 포함한 각종 리소스들 역시 Webpack을 통해 처리됩니다. 웬만한 작업은 npm과 Webpack으로만 자동화하려고 했으며, Electron과 관련된 작업(패키징, 인증 등)들만 gulp를 이용해 자동화됩니다. 모든 리소스들은 Node.js + express 서버로 Serving 되고, Node.js 앱은 Docker로 빌드되어 AWS EC2로 배포됩니다.마무리이상으로 채널 데스크 프론트엔드의 기술 스택을 소개해드렸습니다. 앞으로 각 부분 별로 저희 팀이 고민해 온 문제들과 해결 방법을 공유하고자 합니다. 뛰어난 개발자 분들의 많은 관심과 피드백 부탁드립니다!

쉐어링 이후 맛있는 베트남스타일 샌드위치를 먹었습니다.스타트업 팀들은 모이면 무슨 이야기를 할까요? 오늘 오전 바쁜 시간을 쪼개 디캠프 GoD 프로그램에 선발된 팀들이 한자리에 모였습니다. 더팀스도 디캠프에 입주해 있어 참여하게 됐습니다. 이번 시간은 디캠프에 입주한 GoD 팀들이 서로의 인사이트와 이슈에 대해 공유하는 자리였습니다.  네 가지 주제로 1시간가량의 발표를 진행했는데 무척 알차서 짧게 요약해 공유합니다 :)오늘의 주제는... 1. 스타트업 간의 인수합병 비하인드 스토리 2. 프라이머 투자유치 경험 공유 3. 디지털 광고 인사이트: 곧 성공할 스타트업을 위한 마케팅 지식  4. 창업자에게 필요한 심리적 기술들데이터스톰 안강민 대표님 (사진 제공: 디캠프)1. 스타트업간의 인수합병 과정 공유 (발표자: 데이터스톰 안강민 대표): 최근 8억 원을 투자 받은 자비스 김범섭 대표의 제안으로 카이스트 출신 개발자 3명으로 이뤄진 데이터스톰(디캠프 GoD 입주팀)과의 인수합병이 진행됐는데요. 데이터스톰 안강민 대표가 인수합병 계기와 과정에 대한 이야기를 공유했습니다. "입주 전부터 자비스 김범섭 대표님과 개인적으로 연락을 했어요. 데이터스톰은 경력단절 구직자들에게 온라인으로 일자리를 연결해주는 서비스를 구상하고 있었고, 자비스는 고객이 촬영한 영수증을 업로드하면 재택근무자들이 영수증을 작성해서 업로드하는 업무를 처리해줬어요. 처음에는 저희를 통해 모바일에서도 영수증 타이핑 업무를 공유하자는 영업 제안을 드리려고 연락을 했어요. 결과적으로 그 제안은 잘 안됐죠". (데이터스톰 안강민 대표)데이터스톰 안강민 대표가 제안했던 협업은 무산됐지만 얼마 후 자비스 김범섭 대표가 역으로 인수합병 제안을 해왔습니다. “김범섭 대표님이 한 번 보자고 하셔서 티타임을 가졌는데 창업을 왜 했냐, 돈과 하고 싶은 일 중 무엇을 선택할 것이냐 등의 생각을 물어보시면서 자비스가 궁극적으로 하려는 일에 대한 미션을 공유하시더라고요.” 안강민 대표는 그 전 스타트업에서도 좋은 조건으로 잡 오퍼를 받았지만, 궁극적으로 하고 싶은 그림이 아니기에 거절하고 학교로 다시 돌아갔습니다. 그랬던 그가 이번 자비스 인수합병을 결정했던 이유는...  서로 비슷한 그림을 바라봤고 서로 어려워하는 포인트와 서로 가진 역량이 달랐기 때문   자비스 이슈: 업력 있는 1인 CTO가 안드로이드, 웹, iOS 개발 총괄을 하느라 일정 이슈 자비스 강점: 서비스 기획 및 영업, 서비스 진행 능력 데이터스톰 이슈: 서비스 관련 일거리 정의 방식, 클라이언트 확보 이슈 데이터스톰 강점: 3명의 스마트한 개발 인력  발표를 통해 얻은 인사이트: 서로가 봉착했던 이슈를 서로 가진 강점으로 상호 보안을 통해 앞으로 나아갈 수 있다고 판단 인수합병 결정오누이 고예진 대표님 (사진 제공: 디캠프)2. 프라이머 인큐베이팅 프로그램 선발 및 투자유치 경험 공유 (오누이 고예진 대표)오누이는 월 4만 원으로 모르는 수학 문제를 물어볼 수 있는 앱 서비스를 운영하는 팀인데요.  프라이머 투자유치를 진행하면서 봉착했던 문제와 과정을 공유해줬습니다. 프라이머 인큐베이팅 프로그램: 프라이머는 모바일/인터넷 서비스, 소프트웨어, 헬스케어, HW&SW 융합 등의 분야의 창업팀에게 초기 창업자금을 투자하고, 멘토링을 통해 성공을 돕는 인큐베이팅 프로그램을 운영합니다.  프라이머 엔턴십 프로그램: 엔턴십 프로그램은 1년에 1-2회 개최되는 스타트업 멘토링 및 교육 프로그램입니다. 엔턴십 프로그램을 졸업한 팀 가운데 우수한 팀들은 프라이머가 투자하고 인큐베이팅 팀으로 선정합니다.  고예진 대표가 생각하는 프라이머 엔턴십 장점은?  :참가한 50개 팀에 대한 BM 서로 평가/피드백(온라인으로 진행)을 할 수 있어 서비스 개선에 필요한 알찬 리뷰를 받을 수 있다. 프라이머 인큐베이팅 프로그램 선발 및 투자 과정은? “처음부터 프라이머 투자 유치를 성공한 게 아니라 권도균 대표님께 페이스북을 통해 저희를 소개했고, 이후 화상 채팅을 하면서 저희 서비스와 관련해 틈날 때마다 성장하고 있는 수치나 데이터를 증명했어요.” 오누이가 봉착했던 문제 (1) 실시간 질의응답이라고 했는데 진짜 10분 안에 답이 와? -> 론칭하고 5개월 고생 (2) 이걸 누가 돈 주고 써?-> 론칭 6개월 후 의미 있는 매출로 증명(3) 이거 돈 얼마나 될까, 스케일업 가능, 후속 투자 가능성에 대한 증명-> 투자 후 3개월 안에 매출 3배 목표 설정 발표를 통한 인사이트: “저희는 프라이머 9기에 선발됐는데, 보통 프라이머에 2000명/500여 개 팀 가량이 지원해 7개 팀을 선발하더라고요. 저희는 한 번에 된 게 아니라 작년부터 컨택을 해서 올해 선발된 거예요. 저희가 봉착했던 문제를 정의해 해결하는 과정과 의미 있는 데이터를 보여주려고 노력했던 거 같아요.” (오누이 고예진 대표)코인덱스 이한상 CXO (사진 제공: 디캠프) 3. 곧 성공할 스타트업을 위한 마케팅 지식 (코인덱스 이한상 CXO)이한상(Han Lee) CXO는 디자인, 브랜드 전문가로서 Brand New School 아트 디렉터를 역임(1) 광고인에게는 보편적이나 일반인에게는 생소한 용어: - USP(Unique Selling Proposition)당신의 제품이 팔리는 독특한 이유를 제시해야 한다.  * 다른 것이 USP가 아니고 더 좋은 것이 USP다.- BIG IDEA: USP를 한 방에 설명하는 이미지, 카피, 슬로건, 그림예시: TOP AD Slogans(자체 검색한 예시 참고 사이트: http://www.fbml.co.kr/2014/06/25/good-advertising-headlines/)   - 케이스 스터디코인덱스 빅아이디어 사례: 국내 최초 디지털 화폐 선물 거래소 (슬로건 도출):국내 선물 거래에 대한 진입 장벽이 높은 상황에서 프로페셔널 투자자들이 신뢰할 수 있는 거래소 이미지를 전달하려고 했으나 한국 사람들에게는 인지도가 떨어져-> 최초의 선물 거래라는 개념으로 先 접근 코인덱스 브랜딩 전략: 30-50대 선호도에 따른 브랜딩 반영- 아기자기하면서 촌스럽게 웹사이트 구성시 센터를 중심으로 사이드 메뉴 배치 (반찬 이론) -> 주식시장의 상승 의미 빨간색 강조  텐시티 문현철 대표님 (사진 제공: 디캠프)4. 창업자에게 필요한 심리적 기술들(텐시티 문현철 대표)(1) 사람들의 편향사람들의 편향은 뱅뱅 이론을 통해 쉽게 발견할 수 있다.뱅뱅 이론은:  주위에선 ‘뱅뱅’ 브랜드의 청바지를 입은 사람을 보지 못했지만 여전히 국내 청바지업계 매출 1위를 굳건히 지키고 있음 (머니 위크 기사 발췌)인간의 인지 방식은.. 경험을 바탕으로 필터가 쌓이면 그 바탕으로 판단을 하게 된다. 이에 따른 문제는.. 나의 견해에 대해서만 이야기를 나눠요. ->나는 맞고 상대방은 틀리다며 논쟁  문현철 대표가 팀원과 일하면서 제기했던 문제: 회의를 길게 한다고 해서 완벽한 결론을 낼 수 있나?발표를 통한 인사이트: 문현철 대표는 스타트업을 하면서 가장 필요했지만 힘들었던 순간을 “나의 사고방식이 틀렸다고 인정하는 과정”으로 꼽았습니다.     (2) 누군가를 미워하는 것은 열렬히 사랑하는 것과 같다사례: 문혈철 대표가 출전했던 토론대회에서 우승자한테 패했던 결정적 이유(준우승)-> 논리에 대한 반박에만 집중했다는 것-> 아무리 반박해봤자 배심원들이 보기에는 상대편에 대한 논거에 대한 이야기일 뿐 결과적으로 상대방에 대한 유리한 논조를 강조한 것스타트업에 적용할 수 있는 인사이트* 상대 서비스에 대한 단점으로 접근하기보다 우리 서비스에 대한 순수한 장점에 대해 집중해야 한다.-> 어떤 서비스가 잘못됐다는 것에 대한 논리를 펼치는 경우가 많은데 우리 팀 서비스의 장점을 순수하게 드러내는 경우에 대한 작업이 필요 * GoD 쉐어링데이: 디캠프 GoD (Game of Dcamp)프로그램에 선발된 팀들이 디캠프에 입주해 코워킹 스페이스에서 함께 교류하며 시너지를 내고 있습니다. 이번 쉐어링 데이는 강의보다는 서로의 인사이트에 대한 공유에 더 가깝습니다.  빨리 정리해 공유하느라 글이 조금 부산한 점 너그럽게 양해 부탁드립니다. #더팀스 #THETEAMS #스타트업 #마인드셋 #인사이트 #이벤트참여 #이벤트후기 #인사이트 #경험공유

고3 시절 자발적 재수를 선택할 때도,대학원 논문을 접을 때도,5년 전 뒤늦게 라식을 결심할 때도,8개월 전 퇴사를 결정할 때도,시작은 다분히 우발적이었다.모든 선택은돌이켜 보면 섣부른 감정으로 시작되었고,판단의 순간은(돌이켜보면) 찰나였지만,순간 순간의 고민은 심해를 뚫는 듯 했다. 그럼에도 나는 큰 결정을 꽤 많이 해 온 편이다.그리고 후회도 잘 하지 않는다.모든 선택에는 기회비용이 발생하고얻는게 있으면 잃는 것이 있는건 당연한 법이다.잃게 될 무언가 때문에대부분의 선택이 문 앞에서 '현상 유지'로 돌아선다.크나큰 결단을 하게되면잃어버린 기회비용 만큼이나 변화에 적응해야하는과도기가 필요하다.그것은 항상 진통처럼 온다. 진통의 과정은수고스럽지 않은 경우가 없었고 인내가 필요하다.그리곤 아픈 만큼 새 살이 올라오는 경험을 가졌다.하지만되돌아 보면선택 자체가 무언가 결정짓는 것이 아니라,선택한 후 그것을 받아들이는 마음가짐이  모든 것을 좌우했던 것 같다.이제는두려워 하지 않는다.선택을 즐기고,결정할 수 있는 용기를 발휘할 수 있음에 감사하고,그 과정을 만끽할 뿐이다.무엇이 더 좋은 선택인지아무도 단언할 수 없다.50대 50이다.'좋은' 선택은 없다.선택하고 '좋게' 만들 뿐이다.

(UX 디자이너 Nikita Gangwal의 미디엄을 번역하였습니다. 의역 많습니다. 원문 출처: https://medium.com/@nikitagangwal.27)어떻게 하면 앱 개인화를 통해 사용자 경험을 다음 단계로 끌어올릴 수 있을까?앱을 비롯한 많은 제품들의 개인화는 사용자들에게 유용한 정보를 추가적으로 제공함으로써(그들이 요구하지 않았음에도) 사용자 경험을 한 단계 끌어올린다. 낯선 장소에 방문했을 때 그 곳에 대한 추천을 받고 싶지 않은 사람은 몇이나 될까? 매일 아침 간단한 아침 레시피를 빠르게 추천받고 싶지 않은 사람은? 만약 네비게이션이 당신의 사용 패턴을 파악한 뒤 매일 저녁 6시에 집으로 향할 것인지 조심스레 물어본다면 어떨까? 이 모든 것들이 당신이 요청하기도 전에 이뤄진다면? 이처럼 인간은 누군가가(혹은 무언가가) 자신들을 관리해주고 작업량을 덜어줄 때 편안함을 느끼는 경향이 있다.‘개인화’란 무엇일까?시스템이 정보, 기능, 콘텐츠 등을 사용자의 니즈와 기대에 따라 실시간으로 추천(curation)해줄 때, 우리는 이것을 개인화라고 부른다. 이 때 앱은 사용자에게 가장 최적화된(unique) 경험을 제공하기 위해 시스템 내에서 유저 데이터로부터 습득한 기술을 사용한다.개인화는 왜 필요한가?사람들은 앱이 개인적인 경험을 제공할 때 더 좋아한다. 자신이 좀 더 특별하고 앱과 연결된 것처럼 느낄 수 있기 때문이다. 만약 앱에 개인화된 요소가 단 하나도 없다면, 해당 앱이 실제로는 도움이 될지언정 사용자는 딱히 도움이 안된다고 느낄 수도 있다. 이해를 돕기 위해 Spotify Running의 사례를 보면, 스포티파이는 이제 단순한 음악 감상 앱이 아니다. 스포티파이는 단순 음악 감상에서 나아가, 사용자가 달리는 속도에 맞는 템포의 음악을 추천함으로써 달리기를 계속할 수 있도록 의욕을 불어넣어 준다. 핸드폰 센서를 통해 사용자가 분 당 몇 걸음이나 걷는지를 감지하고 이와 비슷한 비트의 곡을 찾아내는 것이다. 이처럼 Spotify Running이라는 고도화된 개인화 기능이 없다면, 스포티파이는 단순한 음악 앱에 불과할 것이다. 오해는 마시라. 플레이리스트에서 내가 가장 좋아하는 곡을 찾아 듣는 경우라면, 스포티파이는 여전히 최고다. 하지만 여기서 한걸음 더 나아가, 개인화된 서비스는 사용자의 페인 포인트와 니즈에 적절히 대응할 수 있다는 점에서 대단히 매력적으로 어필할 수 있다. 이는 빠르게 사용자와 앱 사이의 유대감을 만들어내고 해당 브랜드에 대한 충성(loyalty)을 이끌어낸다.앱 내에서 개인화 서비스가 효과적으로 이루어진다면, 당신은 브랜드에 대단한 충성심과 애착(affinity)을 지닌 사용자들을 확보한 셈이 되고 장기적으로 매출이 눈에 띄게 오를 것이다. 연구에 따르면 유저가 멋진 사용자 경험을 했을 경우 ‘closing the deal’ 상황에서 더 빠르게 행동하는 경향이 있다.어떻게 제대로 실행할 것인가?1) 리서치, 또 리서치: 절대 이 단계를 건너 뛰면 안된다. 당신의 브랜드에 개인화가 필요하다면 어느정도가 적당한지 반드시 이해하라. 사용자에게 무엇이 중요한지, 한계는 무엇인지, 다양한 고객과 관련되어 있는지 파악하라. 2) 단순하고 자연스럽게: 사용자가 앱을 이용할 때 단 1초라도 혼란을 느낀다면 좋은 경험이 아니다. 개인화는 물흐르듯한 사용자 경험을 위한 첫 단계이기 때문에 사용자가 거의 눈치챌 수 없을 정도로 매끄러워야 한다.3) 반복적인 테스트: 1단계 리서치 만큼이나 중요하다. 유저 테스트는 지금 하고 있는 것이 옳은 것인지 알 수 있는 유일한 방법이다. 반복된 테스트를 통해 발견하는 인사이트는 대단히 놀라울 것이다. 이를 통해 각각의 사용자에게 꼭 맞는(tailor-made) 경험을 제공할 수 있을 것이다.Luminosity사용자의 매일의 활동과 스킬 수준에 따라 훈련 활동을 추천해주는 고도로 개인화된 두뇌 훈련 앱이다. 사용자는 앱에 빠르게 적응함으로써 서비스를 대단히 흥미롭고 재미있게 이용할 수 있다.Airbnb최근 업데이트된 에어비앤비 모바일 앱은 개인화가 핵심이라고 한다. 사용자가 도착지를 설정하면 에어비앤비는 백만 개가 넘는 현지인의 여행 팁이 담긴 해당 도시의 가이드북을 제공해준다. 가이드북에는 해당 도시에 살고 있는 호스트가 직접 추천한 최고의 식당, 경험, 볼거리 등이 담겨있다.Netflix넷플릭스는 사용자가 봤던 영화들과 비슷한 종류의 시리즈를 추천해줌으로써 개인화를 제공한다. 이들은 사용자들의 영화 관람 내역과 랭킹을 모니터링하는 복잡한 자체 알고리즘을 통해 이를 성공적으로 해내는 중이다.YummlyYummly는 사용자의 음식 선호도나 제약 조건과 관련된 레시피를 찾도록 도와주는 유명한 사이트 중 하나다. 사이트에 접속했을 때 사용자들은 본인의 음식 선호를 나타내는 조건들을 세팅하게 된다. Yummly는 이 조건들과 함께 사용자의 검색 패턴을 이용해 그들의 기대에 완벽하게 부응하는 레시피를 추천한다.개인화가 잘못되었을 때...개인화 경험을 제공할 때 주의를 기울이지 않으면 사용자와의 유대감 뿐만 아니라 그동안 이들과 쌓아올린 브랜드의 신뢰도까지 망가질 수 있다. 이러한 실수를 방지하기 위해서는 당신의 사용자에 대해 잘 아는 것이 중요하다. 요약하자면, 개인화는 적절한 사람에게 적절한 타이밍에 적절한 양의 정보를 제공할 때에 효과적이다.Know your audience!완전히 잘못된 타이밍에 적절하지 않은 사용자에게 정보를 제공한다고 가정해보자. 어떤 일이 벌어질까? 아마 당신은 전반적인 브랜드 평판에는 영향을 주지 않는 작은 에러 정도로 생각할 수도 있겠다. 하지만 불행히도 마케팅이 잘못됐을 때, 이는 정말(very, very wrong) 잘못될 가능성이 있다. 이 예가 대단히 정확하진 않지만 나는 시사하는 바가 있다고 생각한다. 다음과 같은 최악의 고객 경험을 생각해보자. 이 아버지의 날 광고는 고객 타겟팅을 할 때 절대 하지 말아야 할 완벽한 예시다. 이 광고는 많은 잠재 고객들을 고려했지만, 때때로 이 가정들이 옳지 않을 수도 있음을 보여준다. 잠재 고객의 고통을 의도한 건 아니지만 이는 명백히 잘못된 타겟팅이다.몇 가지 중요한 팁들1. 개인화를 가치를 더하기 위해 사용하라. 그냥 중요하다고 느껴져서 사용하는 것은 삼가라.2. 잠재 고객에 대해 가정하지 마라. 완전하고 정확한 정보를 얻을 때까지 조사하고 테스트하라.3. 개인화가 너무 자세해지면(If it goes to far) 사용자는 소름끼쳐 한다.4. 좋은 사용자 경험은 미묘하고 눈에 띄지 않을 정도로 이루어질 때 가능함을 기억하라.사용자 경험의 전망개인화 트렌드는 계속 진화하고 있다. 가장 친숙한 개인화 방법은 사용자의 이름을 불러주거나 키워드 매칭을 통해 그들과 관련된 콘텐츠를 보여주는 것이다. 현재 앞서 살펴본 사례들과 같이 다방면에서 개인화된 앱을 볼 수 있다. 앞으로 머신러닝이 사용자의 정성적인 데이터로부터 ‘스토리’를 이해하고, 사용자들이 삶 전반의 다양한 변화를 경험함에 따라 개인화는 완전히 새로운 수준의 완성도를 갖추게 될 것이다. 이를 통해 개인화된 앱들은 사용자에게 놀라운 경험을 제공하게될 것이다.#더팀스 #THETEAMS #디자이너 #디자인 #인사이트 #성장 #마음을움직이는디자인

뭐가 문제였나필자는 현재 HMR(가정간편식) 커머스를 다루는 모 스타트업에서 백엔드 개발자로 재직 중이다. 말이 백엔드지 최근 변화되고 있는 트렌드에 맞춰 열심히 API 작성 셔틀을 하고 있다.API 개발에 주로 사용하는 HTTP 상태 코드는 주로 200 (정상), 400 (잘못된 요청), 401 (보안 토큰 에러), 403 (권한 없음), 404 (찾을 수 없음) 정도가 있었다.문제는 여기에서 발생했는데, API를 계속 개발해 나가다 보니 API 요청 시 데이터가 없을 때 200 상태 코드에 빈 배열을 돌려주어야 하는지, 404 상태 코드를 돌려주어야 되는지 상황에 따라 다를 수 있겠다는 생각이 들었다.만약 '데이터가 없을 수도 있는 상황'과 '데이터가 없으면 안 되는 상황'에서 404 Not Found 에러 코드로 같게 응답할 경우 다음과 같은 애매한 상황이 펼쳐질 수 있다.API를 사용하는 클라이언트가 404 에러에 대한 대응을 에러로 표시할지 데이터 없음으로 표시할지 상황에 따라 다르게 정의해줘야 한다. 결과적으로 클라이언트에서 API 요청에 대한 처리가 복잡해진다.// front-endimport fetch from 'node-fetch'; function fetchUserList() {  // 유저 목록을 가져오는 API를 사용한다고 가정  return fetch('https://api.exmaple.com/users')    .then((response) => {      if (response.statusCode === 404) {        // 이 404 Http 상태 코드를 에러로 처리할 것인가? 데이터 없음으로 처리할 것인가?        // 에러일 경우 : throw new Error('Not Found');        // 데이터 없음일 경우 : return [];      } else if (response.statusCode === 200) {        return response.json();      } else {        throw new Error('Unexpected Http Status Code');      }    })    .then(result => render(successPage, result))    .catch(error => render(failurePage, error));}결국, 어떤 식으로 표시해야 명확하게 표현할 수 있을까 하여 페이스북 존잘 개발자님들에게 의견을 물었다. # 굉장히 많은 분이 의견을 주셨고 나름대로 생각을 정리할 수 있었다.결론적으로는 '데이터 없음'과 '404 Not Found'를 같은 용도로 사용하면 안 된다.그렇다면 뭘 어째야 하나위에서 나온 결론을 조금 더 자세히 풀어보면 다음 내용이다.상황에 따라 데이터가 없는 것이 정상인 상황이 있고, 데이터가 없는 것이 에러인 상황이 있다. 이를 구분 해야 한다.데이터가 없는 것이 정상일 수 있는 상황// server-sideAPI.get('/orders/date/:date', async (request, response) => {  // 특정 날짜의 주문을 검색. 특정 날짜에 주문이 없을 수도 있다.  const { date } = request.params;  const orders = await Repository.Order.findByDate(date);  // 200: OK  // 204: No Contents  response.statusCode(orders.length > 0 ? 200 : 204).json(orders);});데이터가 없는 것이 에러인 상황API.get('/orders/:orderId', async (request, response) => {  // 특정 ID의 주문을 검색. 데이터가 없으면 에러다.  const { orderId } = request.params;  const order = await Repository.Order.find(orderId);  if (order.length > 0) {    response.statusCode(200).json(order);  } else {    // 404: Not Found    response.statusCode(404).json({      message: `${orderId} is Not Found`    });  };});그렇다면 요청한 API 리소스가 없는 경우에는 어떤 에러를 보여줘야 하는가? 일반적으로는 404 Not Found 가 통상적으로 사용되지만 우리는 이미 404를 다른 용도로 사용하고 있다. 다행히도 HTTP 상태 코드에는 501 Not Implemented 이라는 좋은 친구가 있다. 이 친구를 사용할 수 있다.import { Users, Orders } from './Routes'; app.route('/users', Users);app.route('/orders' Orders);app.all('*', (request, response) => {  // 501: Not Implemented (구현되지 않음)  response.statusCode(501).json({    message: 'This Method is Not Implemented',  });})대충 이 정도면 클라이언트는 Http 상태 코드를 보고 다음 로직을 처리할 수 있을 것이다.물론 일반적으로 사용되는 상태 코드들이지만 실제 개발 진행 시에는 클라이언트를 개발하는 개발자와 미리 어떤 상황에서 어떤 상태 코드를 보낼 것인지 정해야 할 것이다.마무리API 개발 시 사용할 법 직한 응답 코드를 정리해보았다.200: OK (정상, 데이터 있음)204: No Contents (정상, 데이터 없음)301: Moved Permanently (리다이렉션)400: Bad Request (실패, 클라이언트에서 넘어온 파라미터가 이상함)401: Unauthorized (실패, 클라이언트에서 넘어온 보안 토큰이 이상함)403: Forbidden (실패, 사용자의 권한으로 리소스를 사용할 수 없음)404: Not Found (실패, 데이터가 있어야 하나 없음)410: Gone (실패, 데이터가 있었으나 삭제됨. 이건 굳이...?)500: Internal Server Error (실패, 서버 로직 문제)501: Not Implemented (실패, 없는 리소스 요청)기타 304나 502, 503 등의 상태 코드의 경우 API Application을 작성하는 개발자의 역할보다는 Server 쪽의 역할에 가깝다고 생각하여 작성하지 않음.뭔가 어렵다고 느껴진다면 다음 짤을 참고해서 쉽게 이해할 수 있다. #플레이팅 #개발 #개발자 #인사이트 #경험공유 #조언 #꿀팁 #HTTP #버그 #버그수정 #문제해결

스마트폰 생태계가 성숙되어가면서 액티비티 트래커, 구글 글래스, 스마트 워치류의 웨어러블 디바이스들이 쏟아져 나오고 있다. 초기의 낙관적인 시장전망과는 다르게 시장은 빠르게 변화하고 있고, 기존의 플레이어들은 역사뒤로 사라지고, 또 새로운 플레이어들이 나타나면서 역사는 반복되고 있다[1]. 여전히 사용자관점에서는 그 필요성에 대해 회의가 많다. 진정한 웨어러블의 빅뱅은 시기상조이며 웨어러블의 성공적인 시장을 만드는 것도 요원해 보인다.  우리가 놓치고 있는 진정한 웨어러블의 본질은 무엇인가?웨어러블의 본질웨어러블이 확산되는데 있어 가장 큰 장벽은 무엇인가를 착용한다는 것에 대한 불편함이다. 사람의 몸은 익숙하지 않은 것을 받아들이기까지 참아내야 할 시간이 필요하다. 하지만 웨어러블이 그 인내를 가질만큼 사람들에게 가치가 있는 것인가? 인내를 가질만큼의 가치를 줄 수 없다면 선택되지 못하거나 선택되어도 사람들 곁에 지속될 수 없다. 그래서 요즘 많은 사람들이 예전에 구매했던 액티비티트래커나 스마트워치라 불리우는 것들을 책상 서랍에 넣고 잊어버린 지 오래이다.   1. 첫 번째 가치: 불편함을 넘어 습관이 되거나 대체불가능한 본연의 기능성안경을 착용한 사람들중에 안경을 끼고 세수를 한 경험이 있는 사람들이 있을 것이다. 안경을 써보지 않은 사람들은 믿지 않겠지만 오랫동안 착용하다보면 몸의 일부처럼 체화되어 마치 없는 듯 느껴지기 때문이다. 하지만 처음에 쓸때는 어떠할까? 매우 불편하다. 귀도 아프고 코도 아프고, 눈도 따끔거린다. 하지만 그걸 참을 만한 단하나의 기능이 있다. 안경을 써야 보인다는 것이다. 안경없이는 칠판도 안보이고 간판글씨도 잘 안보이는데 안경을 착용하는 순간 세상이 밝아지고 환해진다. 그래서 불편함을 무릅쓰고라도 쓸만한 가치가 있다. 그런데 쓰다보면 불편함이 느껴지지 않는 순간, 즉 습관이라는 것이 만들어지는 때가 온다. 이렇게 안경, 썬글래스, 콘택트렌즈 모두 그것을 착용하지 않을 때와 착용 할 때의 기능적 차이가 명확하다. 보청기도 마찬가지이다. 이 명확한 기능성덕에 사람들은 눈이 부실때는 썬글래스를, 스키탈때는 고글을, 수영할때는 수경을, 오토바이탈때는 헬멧을 착용할 수 있다.2. 두 번째 가치: 보는 것이 아닌 나를 보여주는 것시간을 보기 위해 시계를 착용한다고 하는 사람들이 많이 있다. 하지만 그들에게 있어 시계는 악세서리의 가치가 훨씬 크다. 시간보는 것을 원하는 소비자들은 쉽게 대체제를 찾아 이미 시계를 벗어버렸다. 모바일폰이나 삐삐가 있기전에 많은 사람들이 시계를 차고 다녔다. 그 때는 진짜 시간을 보기 위해서였다. 하지만 모바일폰으로 쉽게, 더 정확하게, 알람기능도 편하게 볼수 있게 되면서 그 불편하던 시계를 벗어버린 사람들이 많다. 지금 시계를 착용하고 있는 사람들은 패션으로서의 가치가 크기 때문에 그 불편한 시계를 차고 다니는 것이며 정확하게는 차고 있기 때문에 시간을 보는 것이다. 물론 100%라고 일반화 할 수는 없다. 지금도 시계를 착용하는 많은 사람들은 새로 멋지고 좋은 브랜드의 시계를 선물받았거나 구매했기에 차기 시작한 사람들도 있지만, 대부분은 대체제가 나타났을 때도 관성에 의해 계속 시계를 차고 있었던 덕에 습관이라는 행동패턴이 생긴 소비자들인 경우일 것이다. 습관이 되어 버린 이들에게는 시계를 착용하는 불편함은 더 이상 인지되는 문제가 아니다.이는 신발이나 모자, 옷과 같이 패션과 기능이라는 면에 있어 너무도 확고한 의류(wear 웨어)가 가지고 있는 것과 동일한 가치이다. 여기서 웨어(wear)와 웨어러블(wearable)의 차이는 본질적인 속성의 차이이다. 이미 입고 있는 웨어와 입거나 찰 수 있는 웨어러블은 인간에게 있어 수십, 수백년의 역사속에서 만들어진 습관을 극복 할 가치의 차이에 있는 것이다. 웨어러블은 이 두가지 본질적 가치를 줄 수 있을 때 비로소 인간에게 선택될 수 있는 티핑이 시작 될 것이다.거부하지 않는 소비자들웨어러블은 그래서 거부하지 않는 소비자에 집중해야 한다. 거부하지 않는 소비자란, 불편함을 참아야 할 기능적 니즈를 가지고 있거나, 이미 사용하고 있는 습관을 가지고 있는 사람들이다. 안경을 착용하고 있거나, 시계를 차고 있는 소비자는 이미 웨어러블을 사용하고 있는 사람들이다. 이들에게 필요한 기능과 디자인, 그리고 가치에 집중해야 하며 웨어러블이 포스트스마트폰이 될 거라는 고정관념을 버려야 한다. 스마트폰은 인간을 정보의 중심으로 만들어 준 컴퓨터의 속성이 본질이기에 웨어러블은 사람과의 인터페이스의 관점에서 접근해야 한다. 궁극적으로 컴퓨터를 담을 수 있는 미래가 오겠지만 그전까지는 인터페이스가 가장 중요한 본질로 소구될 것이다. 이에 더해서 VR/AR 헤드셋이나 정보축적을 위한 QS(Quantified Self)의 영역에서 많은 버티컬 케이스들이 만들어 질 것이다.두번째 거부하지 않는 소비자는 자신의 의지를 표현할 수 없지만 많은 케어가 필요한 유아와 건강을 집중적으로 관리해야 할 중증환자와 실버세대이다. 이들의 공통점은 타인의 케어가 필요한 대상들이며 특별한 목적과 기능을 가진 웨어러블이 적용되어야 할 주요 소비자이다. 이들은 불편함을 참아가면서 케어 해야 할 니즈가 있고 시대의 변화는 이러한 니즈를 충족시켜 줄 기술을 가능하게 만들어가고 있기 때문에 큰 비용을 기꺼이 지불하는 연계 서비스까지도 적극적으로 수용 할 대상이다. 이들에겐 생명이나 건강과 직결되어 있는터라 웨어러블이 가진 불편함은 기꺼이 참을만한 트레이드오프(Trade-off) 일 뿐이다.또 하나 거부하지 않는 소비자는 반려동물을 기르는 사람들이다. 반려동물 역시 타인의 케어와 관심이 필요하며 사람들이 점점 더 많은 비용을 지불하게 될 대상이다. 웨어러블을 선택하는 대상과 사용하는 대상이 다른 경우인데, 반려동물 역시 불편함을 거부하는 의사표현을 하지 않기 때문에 반려동물의 소유자에게 가치가 있다면 잠재성이 큰 시장으로 성장 할 것이다. 이미 많은 제품과 서비스가 출시되었고, 반려동물의 건강을 모니터링하며 반려동물과 소유자가 인터랙션을 할 수 있게 도와주는 웨어러블과 함께 다양한 서비스들이 바인딩될 것이며 사물인터넷이 케어인터넷으로 진화하는 그 시작점이 될 것이다.지금은 웨어러블 시장이 양극화되고 경쟁도 심화되고 있지만 결국 다양성을 담는 방향으로 계속 진화를 할 것이며 웨어러블이 웨어가 될 수 있는 본질적 가치를 가지게 될 때 자연스럽게 이들은 우리의 습관이 되어 인간의 삶에 한 부분이 될 것이다.[1] 역사뒤로 사라진 페블에게서 배우는 교훈이미지출처: https://www.flickr.com/photos/keoni101/7069578953 CC-BY#라이프스퀘어 #스타트업 #창업자 #창업가 #마인드셋 #조언

안녕하세요 협업툴 플로우입니다.회사 생활을 함께했던 팀원이 퇴사한다고 했을 때, 가장 먼저 무엇이 떠오르시나요? 성공적인 이직과 새 출발을 축하하며 쿨하게 이직 선물을 고민하고 싶지만, 현실은 인수인계에 대한 걱정이 앞서게 됩니다. 새로운 직원을 뽑으면 다행이지만, 그렇지 못할 경우에는 다른 직원이 인수인계를 받아야 하죠. 인수인계는 구전동화와 비슷해서 많은 사람을 거칠수록 내용이 달라지거나 누락되기 쉽습니다. 오늘은 인수인계 누락을 줄이기 위한 확실한 방법에 대해서 알아보려 합니다. 먼저 가장 흔하게 인수인계가 누락되는 세 가지 상황을 볼까요.1. 인수인계 내용이 많은 경우인수인계를 할 수 있는 기간은 길어봐야 1개월입니다. 도의적인 책임을 묻지 않기 위해 대부분 규정대로 1개월 후 퇴사를 하지만, 빠른 경우 2~3일 안에 퇴사를 하는 경우도 있습니다. 매일, 매주, 매월, 매년 했던 일을 정리하기 위해서는 누구에게나 물리적인 시간이 필요합니다. 하지만 인계자(전임자)는 이미 마음이 뜬 상태이고, 알려줄 내용이 많은 상황이라면 내용을 축소하거나 요약하여 인계하는 경우가 발생합니다. 인수자(후임자) 역시 갑작스럽게 많은 양의 정보들을 숙지해야 하는 상황이 온다면 포인트만 기억하게 되고, 전임자가 떠난 후에는 ‘이게 무슨 말이었지?’라는 아찔한 경험을 하게 되죠.인수인계 내용이 많다면, 직원을 붙잡으세요! 회사에 도움이 되는 능력자입니다!2. 책임과 기간이 명확하지 않은 경우퇴사하는 직원은 있지만, 신규 직원을 채용하지 않는 경우도 있습니다. 이런 상황에서는 다른 직원이 일을 맡아야 합니다. 하지만 업무가 바뀌고 쪼개지면 일의 책임과 기간이 불명확해지기 때문에, 아무리 인계자(전임자)가 열심히 설명하더라도 일이 누락되는 경우가 발생합니다. 만약 인수자(후임자)가 들어온다고 하더라도, 업무의 기간이 명확하지 않다면 일을 놓칠 수 있고 중요한 프로젝트라면 회사에 큰 손실을 줄 수도 있습니다.과정 없이 결과만 남은 경우, 처음으로 돌아갈 가능성이 높다.3. 히스토리 없이 결과만 남은 경우디자인 작업물의 경우 수정을 하기 위해서 포토샵, 일러스트 같은 원본 소스 파일이 필요합니다. 문서에도 수정이 가능한 워드(word)나 한글(hwp), 엑셀(xls), 파워포인트(ppt) 파일이 있어야 하죠. 만약 pdf, jpg 파일만 있다면 처음부터 일을 다시 해야 하는 경우가 발생합니다. 파일과 마찬가지로 프로젝트에도 결과물과 소스가 있습니다. 여기서 말하는 소스란 히스토리입니다. 왜 이 프로젝트를 하게 되었는지, A/B 안 중에 A를 결정한 이유가 무엇인지 등 가볍게 말하면 히스토리지만, 중요하게 생각하면 회사의 기밀이자 팁, 노하우로 볼 수 있습니다. 히스토리 없이 결과만 공유된다면 후임자는 전임자의 똑같은 실수를 반복하게 됩니다.누락 없는 인수인계를 할 수 있다면?직원들의 퇴사와 입사가 반복되면 팀장님과 대표, 회사에게는 큰 리스크입니다. 그동안 쌓아온 노하우들이 한순간에 사라질 수 있죠. 인수인계가 제대로 이뤄진다면 퇴사로 인한 부담요소를 조금이나마 줄일 수 있습니다. 협업툴 플로우를 이용해서 말이죠.프로젝트별 파일 보관카테고리만 잘 분류해 놓으면 원하는 파일을 빠르게 찾을 수 있는데요. 플로우는 프로젝트별로 파일을 보관할 수 있어 찾아보기 편리합니다. USB나 외장하드 같은 관리 위험부담이 큰 저장장소가 아닌 클라우드로 저장할 수 있어, 언제 어디서나 다운로드가 가능하죠.댓글 방식의 히스토리업무를 진행하는 데 있어 결과만큼이나 중요한 것이 히스토리입니다. 히스토리를 알고 있다면 기회비용을 줄일 수 있는데요. 플로우는 업무에 대한 히스토리를 댓글 형태로 남길 수 있습니다. 프로젝트별, 업무별로 다른 팀과 논의했던 히스토리, 외주 업체와 공유했던 내용들은 모두 볼 수 있습니다.‘역사를 잊은 민족에게 미래가 없다’라는 유명한 말처럼 회사에서도 역사(History)가 중요합니다. 또 후대가 역사를 알기 위해서는 기록이 수반되어야 하죠. 지금도 늦지 않았습니다. 회사에 안전한 기록을 남기기 위해, 인수인계 누락을 줄이기위해 근본적인 제도가 필요하다면, 협업툴과 같은 업무 도구를 이용해 보시는 것도 도움이 될 수 있습니다.협업툴 플로우 바로가기