스타트업 기획에 있어서 비지니스 모델을 설정한다는 것은 굉장히 중요한  일입니다. 단지 "사람들이 좋아하고 잘 쓰는 서비스."를 만드는 것도 중요하지만, 이러한 서비스를 유지하기 위해서는 적절한 수익구조가 필요합니다. 그리고 이러한 비지니스 모델은 추후 투자라든지, MVP(Minimal Value Product)가 나온 이후 수익 서비스를  만드는 데 있어 정말 중요한 요소이기 때문에 처음부터 방향성을 정하고 진행하는 것을 개인적으로 선호하고 추천하는  편입니다.그렇다면 요즘 많은 서비스들이 사용하는 수익 창출 요소 (또는 수익구조 모델링 이라고도 할 수 있지요)인 "광고"나 "Freemium" 같은 일종의 "돈 버는 방법."을 골랐으니, 비지니스 모델을  설정했다.라고만 생각하시는 분들이 있는데 그건 비지니스 모델을 설정하신 것이 아닙니다. 수익구조와 비즈니스 모델은 엄연히 다른 부분입니다.여러분이 기획하시는 서비스는 수익을 냄으로서 어떤 식으로 유저에게 더 유리한 것들을 제공해 줄 수 있고, 이를 통해 어떠한 가치들을 재생산 해 낼 수 있는지 지속적으로 관찰하고 연구해야 더 좋은 비지니스 모델을 설정할 수 있다고 생각합니다. 그리고 이러한 부분에서 수익모델은 비지니스 모델에 종속되어있는 개념으로 연구를 통해 각각의 서비스마다 맞는 비지니스 모델을 설정해야만 합니다. 흔히들 "좋은 기획자"는 관찰력이 좋은, 그리고 기존의 "왜" 보다 한 단계 더 깊은 댑스(Depth)를 생각할 수 있는 사람을 좋은  기획자라고 합니다. 기본적으로 생각할 수 있는 부분에서 한 단계가 아닌  그다음 단계까지 생각할 수 있는 기획자가 좋은  기획자라고 하는데요, 이러한 과정을 통해 보다 "본질"과 "당위"에 대한 인사이트를 키워나갈 수 있는 기획을 하시는 것을 추천해 드립니다. 저도 이렇게 할 수 있도록 많이 노력하고 있고요. 즉, 그냥 "광고" "프리미엄 모델" 아니면  옛날처럼 그냥 "도토리"가 아니라, "(여러분이 제공하려는) 서비스는 어떤 사용자가 메인 타겟이고, 그 타겟이 어떠한 니즈가 있기 때문에 어떤 수익구조를 활용한 비지니스 모델을 사용하는 것이  적합하다."라는 결론을 직접 내릴 수 있어야 하고, 이를 위해 표본 이용자 수집, 인터뷰, 페르소나 작업, 등 사용자 환경과 경험에 대한 연구 또한 소홀히 해서는 안됩니다. 비지니스 모델을 만드는 것은 서비스를 제작하면서 "내 서비스는 이런 거야."를 개발해 나가며 어찌 보면 기획자가, 또는 제작팀이 자신의 입맛대로, 주관적이고 포괄적인 연구 없이 진행될 수 있는 요소라고 생각되나, 정말 오래가고 성공할 수 있는 서비스라면, 전반적인 기획의  시작단에서부터 비지니스 모델링에 대한 깊은 고민을  하는 것을 적극적으로 추천드립니다. p.s: 이번에도 글이 많이 늦었네요 기다리시는 분들에게 정말로 죄송합니다ㅠㅜ 다음부턴 진짜 빨리 쓸게요!#코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 버즈빌의 BM(Business Management)팀에서 Head of Finance Role을 맡고 있는 Roy  Kim (김현우)입니다. 버즈빌에 조인한 건 2016년 8월 29일로, 이제 1년 6개월정도 지났습니다. 저는 4대문 안쪽의 현-마이크로소프트 한국 지사 건물이 있는 곳의 산부인과에서 태어났습니다. 가끔씩 저에게 지방출신이 아니냐고 물으시는 분들이 계신데.. 조선시대였으면 사대부들만이 가능하다는 4대문 안쪽에서 태어난 진정한 성골 서울사람입니다 🙂 태어난 후부터 중간에 잠깐 1.5년을 제외하고는 서울에서 초-중-고등학교를 졸업했고, 2001년부터 2009년까지 약 8년간 미국에서 생활했습니다. 사실 처음에는 1년간 어학연수를 하고 군대를 갈 생각이었으나..어찌저찌 하다보니 대학을 졸업하고 2년간 업무 경험도 쌓을 수 있었네요. 대학에서는 Economic를 전공했기 때문에, 졸업 후 관련 업종을 찾는데 집중했고, 운이 좋게 외교통상부의 해외공관의 경제담당관으로 근무했습니다. 제가 있던곳은 샌프란시스코 총 영사관이 었는데요, 주요 업무는 실리콘밸리 및 샌프란시스코의 비즈니스 네트워크를 만들고 관리하는 업무, 주요 경제 동향 파악 및 리포트 작성, 우리 기업의 현지 진출 지원 등의 업무였습니다. 이후, 좀더 액티브한 업무를 하고 싶어 영사관을 나와 현지 게임회사에서 근무하면서 Local Publishing을 담당했습니다. 해당 업무는 한국에서 미국 진출을 원하는 게임을 가져와서, 현지화 하는 작업을 진행하는 업체로 2~3개의 게임을 실제로 미국에서 런칭하는 등의 경험도 해보았네요.  이후에는 사실 살~짝 권태기가 왔습니다. 졸업과 동시에 일을 시작하기는 했지만, 아직도 제가 무엇을 좋아하고 무엇을 하고싶은지 모르고 있는 건 아닌가라는 고민도 들었구요. 해서 머리도 식힐 겸 영어강사를 시작했고 이 역시 나름 재미있게 하긴했으나, 장기적인 관점에선 재무/회계 역량을 더 발전시키고자 다시 인더스트리로 돌아오게 되었습니다.  버즈빌 입사 바로전까지 일하던 지오시스는 이베이지마켓의 Founder인 구영배사장님이 글로벌 오픈마켓을 지향하면서 런칭한 회사로, 저도 2012년까지는 지마켓의 일원으로 일하다가 지오시스에서 본격적으로 재무시스템기획을 맡으면서 업무를 시작했습니다. 주로 회사의 재무/회계 전반적인 시스템을 구축하는 업무를 맡았고, 업무에 대한 성과 등을 인정받아 팀장으로 팀원들과 함께 회사의 주요 시스템을 기획했습니다. 이때 제가 만든 어드민내 기능만 30가지가 넘었고, Finance를 위한 별도의 어드민을 개발하여 SAP와 연동하는 업무도 진행했습니다. 해당 업무는 정확히 재무회계로 볼수는 없지만, 해당 업무의 지식이 매우 필수적인 업무였기 때문에, 저는 이곳에서 재무회계 관련 업무의 기초지식을 쌓을 수 있었을 뿐만아니라 한국 외 싱가폴, 미국, 일본, 중국, 말레이시아, 홍콩, 인도네시아 법인을 모두 시스템으로 연동하여 관리하는 Role도 맡게 되었습니다.  3.5년쯤 해당업무를 진행하다, 회사의 본격적인 IPO 준비에 앞장서고자 세무 및 회계의 업무로 보직을 전환했고 이 과정에서 1,000억원 증자 및 국세청 세무조사 응대 등의 업무를 진행했습니다. 돌아보면 저에게 엄청난 경험과 성장을 할 수 있게 해 준 회사였지만, 지지부진한 성장과 스스로의 내적 어려움이 있었기 때문에, 회사를 떠나게 되었습니다. 2. 어떻게 버즈빌에 오시게 되셨나요? 이전 직장을 그만두고 이직을 알아보던 중 헤드헌터분이 강하게 추천을 해 주셨습니다. 사실…이직이 확정된 & 면접을 보러다닌 다른 기업들에 비해서는 버즈빌은 저에게 상당히 미지의 존재였기 때문에, 사실 처음에는 전혀 고려대상은 아니었습니다.  그럼에도 불구하고 이곳에 오게 된 계기에는 주변분들의 추천이 있었습니다. 이름을 직접 말씀 드릴 수는 없지만, John의 지인과 버즈빌의 파트너사 및 협력사 분들이 회사에 대해서 발전 가능성이 높고 제가 기여할 부분도 많다고 말씀해 주셨습니다.  사실.. 이전의 회사에서 100명부터 650명이 되는 과정에서 5년이 넘게 회사의 기초 Finance System을 설계했었습니다. 가깝게는 판매자의 정산 및 결제부터 멀게는 회사내의 보상체계까지 다양한 부분의 시스템을 기획하면서, 제 스스로 주어졌지만 사용하지 못한 휴가가 49일이나 됐습니다. 이렇게 일이 많은 회사보다는 그냥 제게 주어진 Task에 집중하면서, 다른 여러가지 사업구상을 할 수 있는 회사를 찾고 있던터라, 처음에 버즈빌에서 최종합격 통보를 주셨을 때 일이 많을 것 같아서 거절을 했었습니다.  하지만, 이후 다시 주변 분들이 너랑 잘 맞는 회사라는 말씀을 거듭 주셨고, 매우 부끄럽게 다시 연락을 드려서 기회가 있는지 물었습니다. 상당히 아이러니 한데요, 합격시켜주니 안간다고하고..알았다고 하니, 다시 가겠다고..이와 관련해서 내부에서도 이야기가 있었던 것으로 알고 있습니다 (저 사람은 들어왔다, 금방 나갈 것 이라고) 결과적으로 전 아직도 이곳에 있고 이곳이 좋습니다. 물론, 다른 기회를 잡았으면 어떨까하는 생각을 안한 것은 전혀 아니나, 이정도면 매우 만족한다고 볼 수 있습니다 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 제가 담당하는 업무는 Accounting and Finance 전반적인 업무를 진행하고 있습니다. 물론 이 외에도 회사의 여러가지 정책을 정립하고 수립하는 업무도 담당하고 있습니다업무를 나누자면 크게 3가지로 나눌 수 있습니다 1) 재무회계업무 2)IR업무 3)기타정책업무. 물론 회사에 따라서는 1)재무회계업무도 1-1 재무 / 1-2 회계 / 1-3세무 로 나누지만, Buzzvil은 아직 인력이 충분하지 않아 동 업무를 모두 같이 처리하고 있습니다   우선 1) 재무회계업무를 보면, 주로 하는 일은 재무관리가 있는데요. 간단하게 말씀드리면 회사의 입/출금을 관리하는 업무입니다. 입금의 경우 회사가 발생시키는 매출에 대해서 매출이 적절하게 회수됐는지 확인을 합니다. 반대로 출금의 경우에는 회사가 지불하는 다양한 서비스 경비에 대해서 비용이 적절하게 승인됐는지, 지불금액은 합리적인지 판단 후 출금을 처리하는 업무를 말합니다. 회계의 경우에는 앞에말씀 드린 입/출금 업무가 제대로 처리됐는지 장부상에서 관리하는 것을 말합니다. 흔히 회계를 단순한 내역정리라고 보시는 분도 계신데요. 회계는 장부를 통해 회사의 살림살이가 제대로 운영되는지 확인하는 기능입니다. 아쉽게 제가 입사하기 이전의 Buzzvil의 회계는 외부기장을 통해 작성되고 있었기 때문에, 장부의 금액에 대해서 회사내에 정확히 파악하시는 분이 없었습니다. 해서, 처음에 이 부분에 대한 파악 및 확인이 시급하였고, 지금은 적어도 어떤 Account의 어떤 비용이 있는지는 파악하고, 관련 내용을 COO 및 CEO, 외부 투자자들에게도 공유 드리고 있습니다  두번째로는 IR업무입니다. 물론 아직 상장을 하지 않은 법인이기 때문에, 정확한 의미의 IR이라고 볼수는 없는데요. 제가 현재 담당하고 있는 IR은 주로 투자자 응대입니다. 저희 회사에 투자한 투자자분들께서 회사의 실적등에 대해서 궁금해 하시기 때문에, 주로 분기별로 응대를 하고 있습니다. 그리고 지난해 Slidejoy를 인수하면서 개인투자자 분들도 많이 추가 되셨기 때문에, 이 분들에게도 관련 자료를 전달 드리고 있습니다. 만약 회사가 Going public으로 간다면, 그때는 관련업무의 depth가 지금보다는 더 깊어질 것으로 보고 있습니다. 따라서 이를 대비하기 위한 IR 자료 준비 등의 업무도 올해부터 시작하려고 하고 있습니다  마지막으로 담당하는 업무는 기타정책업무 입니다. 아직 회사에는 비용에 대한 기안/승인/집행 등과 관련된 프로세스가 정립되지 않았습니다. 따라서 관련 업무를 보다 체계화 시키는 업무를 진행하고 있습니다. 비용관련 정책의 경우 단순하게 BM에서 집행하는 비용 외, 전사에서 발생하는 모든 비용을 대상으로 관련 정책을 수립하고 있습니다. 아울러, 회사가 Going public을 진행하고 있기 때문에 관련해서 사전에 미리 준비해야하는 여러가지 사항에 대해서 처리하고 있으며, 이 중에서 정책적으로 결정해야 하는 일이 있으면, 관련 정책의 수립도 진행하고 있습니다   4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 굉장히 새롭습니다. 스타트업에서 근무해본 경험은 있지만 광고는 처음인터라, 물론 저의 업무특성상 업계에 크게 구애받지 않는 업무이긴 합니다만, 항상 새로운 Industry에 대해서 배우는 것은 저에게 매우 즐거운 일이라 생각합니다.  사실 버즈빌은 광고라기 보다는 광고 및 컨텐츠를 통해서 모바일 잠금화면이라는 새로운 생태계를 구성하는 업체라고 생각합니다. 이는 단순하게 새로운 컨텐츠를 제작하여 배포하는 것도 아니고, 광고만을 수주하여 고객에게 전달하는 것과는 다르다고 생각합니다.  이러한 면에서 사실 이전 회사에서는 접하지 못한 새로운 수익의 창출 및 고객의 니즈를 충족시킬 수 있다는 부분은, 저 스스로에게도 다양한 부분을 시사했던 것 같습니다. 제 개인적으로는 버즈빌이 광고업계라는 업종을 한정시키기 보다는, 모바일을 통한 Life Changer로서의 다양한 Role을 수행해 나가길 희망하고 있습니다  5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요? 우선 버즈빌의 자유로운 분위가 저는 매우 좋습니다. 물론 입사초에는 규정되지 않은 문화가 매우 어지럽고 비효율적이라는 느낌을 받은 것도 사실입니다. 이는 버즈빌의 문화의 잘못이라기 보다는, 제가 있던 곳들이 어쩌면 정형화된 분위기에서 저의 일만 하면 되는 분위기 였기 때문에, 그러한 차이에서 오는 약간의 불편함 이었다고 생각합니다.  보통 회사의 경우 인간적인 관계의 부분도 중요하지만, 공적인 일을 하는 장소라는 인식을 많이 가지고 있습니다. 소통도 상대적으로 덜할 수 밖에 없죠. 그렇지만 버즈빌은 자유로운 문화를 통해 서로 이야기 하고, 불편한 점을 고쳐나가기에 자유로움이 소통으로 더 극대화 되는 좋은 기폭제가 아닌가 생각하게 합니다.   개인적인 경험으로 미루어보아 말씀드려보자면, Top – down 시스템이 익숙한 회사에서 버즈빌에 조인하셨다면, 약간 업무적응에 힘들 수 있습니다 . 왜냐면, 뭔가 exact한 지시를 하는 사람이 없고, 그 지시를 내릴 수 있는 Level의 분들 중 어떤 분들은 중간관리자로 오신 분들보다관련 경험이 없을 수도 있기 때문입니다.  반대로 본인이 주도적 성격을 가지고 업무를 이끌어가는 분이라면 제 생각에는 이곳만큼 좋은 곳이 없습니다. 버즈빌은 Self-leader를 장려하고, 이러한 role에 대한 서로 존경하는  곳 입니다. 따라서, 본인이 하고자 하는 업무가 명확하다면 CEO와의 대화를 통해 이러한 부분을 구체화하고 이끌어 나갈 수 있습니다.  저의 경우에는 버즈빌 입사와 동시에 Finance System을 구축하고 싶다는 목표가 있었습니다. 물론, 아직 관련 계획을 진행하고 있지는 못하지만, 그 System의 기반이 되는 여러가지 데이터의 정리/분석 등을 통해 한단계 한단계 나아가고 있습니다. 만약 제가 과거와 같이 큰 업체이 있었다면, 저의 의견보다는 윗선의 의견을 수렴하여 프로젝트를 진행하는 Role을 맡고 있었을 것 입니다 . 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 버즈빌의 많은 분들처럼 저 역시 창업에 대한 꿈이 있습니다. 이 곳에서 아이템에 대해서 말씀 드리기 어려우나 ^^; 개인적으로는 이전부터 하고 싶었던 창업의 아이템이 있어서, 만약 Buzzvil을 퇴사한다면 관련 사업을 진행하고 싶습니다. 그리고 이 사업을 하면서 버즈빌에서 느낀 여러가지 감정 및 업무 경험이 매우 큰 도움이 될 것이라고 생각합니다.  어떻게 살고싶냐는 질문은 매우 철학적인데요. 개인적으로는 많은 고민과 테스트를 하면서 살고 싶습니다. 저는 이전부터 다양한 분야에 관심이 많았고, 그중에서 가장 관심이 많은 부분은 ‘왜 사람들은 저런 생각을 할까’ ‘왜 저런행동을 할까’ 였습니다. 이것은 단순한 심리에 대한 파악이 아니라, 그 사람의 심리를 관통하는 철학은 무엇이고, 그 철학은 어떻게 생성되었기 때문에 그 사람 안에 깊숙히 스며들어 있는가 등 입니다. 좀 지루한 이야기일지 모르겠지만, 이렇듯 사람은 어떠한 철학, 종교에 영향을 받았고, 그 가치가 그 사람의 언어 및 행동 패턴을 변화시켰다고 생각하기에,  그 변화가 지금 그 사람의 문제에 대한 접근방식 및 결론 내는 부분에도 작용한다고 생각하고 있습니다.  따라서, 저는 앞으로 어떻게 살고 싶냐는 질문에, 지금처럼 이러한 것들에 대해서 다양한 고민을 하고, 저의 가설이 맞는지 증명하는 방향으로 인생을 살아갈 듯 합니다. 물론 이러한 고민이 저에게 어떠한 가치(예: 돈)를 줄지는 솔직히 모르겠습니다. 하지만, 나름 저만의 재미있는 세계를 가지고 인생을 살 수 있게 해줄수 있을것 같습니다. 그리고 또한, 행복한 가정을 꾸리고 가족과 함께 평안한 여생을 보내는 것도 제가 꿈꾸는 미래 중 하나 입니다  

폴 손 (Paul Sohn)은 그의 블로그에서 ‘문화는 어려움 속에서 반드시 전략을 초월한다’라고 썼습니다. (Here's How Leaders Create Healthy Organizational Culture, http://paulsohn.org/heres-how-leaders-create-healthy-organizational-culture/)시프티의 예를 들면, 비즈니스에 대한 경험이 전무한 두 명의 공동 설립자에 의해서 시작되었습니다. 사업이 계속 성장함에 따라 2017 년 9 월, 2 명의 팀원을 추가로 합류하였고 바로 그 때 시프티의 팀과 문화, 가치에 대해 다시 한 번 생각해 보기 시작했습니다.우리는 모든 회원들이 참여하기를 열망하는 독특한 문화를 육성하여 미래에 시프티 팀에 합류할 모든 구성원들에게도 자연스럽게 전달되게 하고자 했습니다. 시프티의 문화는 우리가 누구인지, 어떻게 사업을 함께 해 왔는지, 그리고 우리 모두가 시프티를 운영하는 데에 서로 동의하는 철학에서 비롯되었습니다. 그래서 우리 고유 문화를 구축하기 위해 2016 년 7 월 시프티 프로젝트가 시작된 후 첫 해를 되돌아 보고 팀과 공유할 시프티의 핵심 가치, 미션과 비전을 수립하였습니다.Unconventional첫 번째로, 우리는 우리가 누구인지, 다른 기업과 다른 차별성이 무엇인지를 아는 것이었습니다. 한 예로 우리는 한국에서는 다소 익숙하지 않을 수 있는 언어를 사용하여 기존 방식과 다른 제품 개발 프로세스를 수행했습니다. 또한 북미 지역에서는 스케줄링, 출퇴근 용 앱 또는 소프트웨어 시장이 상당히 포화 상태라고 말할 수 있지만 한국은 완전히 새로운 시장이었습니다. 중견 기업의 경우에도 오래된 방법으로 출퇴근을 기록하고 근무표 계획과 급여를 엑셀로 처리하는 전통적인 방법에 크게 의존하고 있습니다. 우리는 시프티의 익숙치 않은 언어를 기꺼이 배우고 일해줄 인력을 찾기 어려울 것이라는 예상과 새로운 시장을 개척한다는 위험을 가지고 시작하게 되었고 UNCONVENTIONAL이라는 가치는 시프티가 앞으로 나아가는 데에 있어 중요한 코어 가치가 되었습니다.Insight두 번째 핵심 가치는 INSIGHT입니다. 우리는 나날이 들어오는 사용자들에 신기했지만 많은 사람들이 시프티를 사용하지 않고 떠나는 것들으르 지켜보았습니다. 사용을 하든 떠나든, 우리는 그들의 요구와 불만을 듣는 데에 많은 노력을 했습니다. 이 과정 속에서 우리는 주로 많은 사용자들의 ‘원함’만을 들었습니다. 우선순위가 없는 의견들과 요청들이 난무하여 우선 순위를 정하는 데 어려움이 있었습니다. 시프티 서비스의 핵심과 사용자에게 제공하는 가치의 중심을 지키기 위해 합리적이지 않은 ‘원함’ 류의 피드백 대부분을 제거해야 했습니다. 우리는 비즈니스의 본질 인 사용자가 실제로 ‘필요’로 하는 것을 연구하기 시작했습니다. 우리는이 접근법을 취하면서 더 나은 통찰력을 가지게되었고 사용자가 정말 필요로 하는 기능을 구현할 수가 있었습니다. 우리는 팀에게 다음과 같은 메시지를 전하게 되어 자랑스럽습니다. “단순히 원하는 것이 아니라 사용자가 정말로 필요로 하는 본질을 찾자.”Flexibility제품 초기에는 MVP 만 있었기 때문에 대부분의 대기업 요구에 부응할 수 없었습니다. 그렇다고 당시에는 우리가 소상공인을 위한 문제를 완벽하게 해결할 수 있지도 않았습니다. 초기에는 제품의 성숙도가 낮아서 주요 타겟 시장으로 간주되는 소상공인의 니즈도 거의 처리하지 못했기 때문입니다. 저는 매일 새로운 자영업 사용자에게 시프티를 떠난 이유를 묻곤 했습니다. (MVP가 갓 나온 초기에 심각한 인게이지먼트와 리텐션 문제를 겪었습니다.) 시프티를 그만 두는 핵심 사유를 찾아내려는 많은 시도는 효과가 없었습니다. 많은 사용자는 시프티에서 무엇이 필요한 지를 정확히 표현하지 못했습니다. 우리는 마침내 소상공인으로부터 피드백을 얻는 것이 대기업의 피드백만큼 효과적이지 않다는 것을 알게 되었고, 사업의 방향성을 중소/대기업 중심으로 전환하게 되었습니다. 대기업은 직원 관리에 대한 절차가 확실하여 특정 기능 요청이나 귀중한 피드백을 세세히 제공할 수 있었기 때문입니다. 이러한 피드백들은 지금의 시프티로 성장하는 데에 결정적인 역할을 했습니다. 결국 시장반응에 빠르고 현명하게 변화하기 위해 pivot할 수 있었던 시프티의 세 번째 가치는 FLEXIBILITY입니다. (소상공인도 여전히 시프티를 편리하게 이용할 수 있습니다.)Customer Satisfaction and Openness마지막 두 가지 핵심 가치는 CUSTOMER SATISFACTION과 OPENNESS입니다. 우리는 고객의 니즈에 필수적인 서비스로 고객을 만족시키고자 합니다. 또한 팀 내에서 열린 문화를 가짐으로써 자유롭게 의견을 제시하고 협력을 촉진할 수 있는 환경을 만들고자 합니다. 우리는 계층적 보고 절차를 가진 전통적이고 엄격한 기업이 되고 싶지 않았기 때문입니다.핵심 가치:Unconventional: 다르다는 것을 두려워하지 않음Insight: 원하는 것을 제공하지 않고 사용자가 필요한 것을 제공Flexibility: 변화에 신속한 대응Customer Satisfaction: 고객을 만족시키기 위해 더 나아감Openness: 투명성과 협업을 수용, 구성원의 평등 추구우리가 위에서 확립한 다섯 가지 핵심 가치는 시프티 팀 내에서 공유될 것이며 궁극적으로 아래의 사명을 이루는 데에 기여할 것입니다.사명:올인원 솔루션을 제공하여 직원 근무일정 스케줄링, 출퇴근기록 및 급여정산 프로세스를 간소화합니다.기업의 운영 효율성을 향상시킵니다.고객이 직원 관리 비용을 절감 할 수 있도록 도와줍니다.#시프티 #고객가치 #핵심가치 #기업소개 #서비스소개

페이스북 광고로 성공하거나 실패할 수 있는 방법은 약 백만 가지가 있지만 아래의 Tip을 알고 디자인을 한다면 광고를 성공으로 이끄는 데 도움이 될 것입니다.광고는 타겟팅이 생각만큼 단순하지 않기 때문에 종종 실패할 수 있습니다.이 글에서 소개되는 Tip을 가지고 소비자와 페이스북 모두 좋아할 수 있는 광고를 만들어보세요!페이스북 광고디자인 Tip #1  : 다채로운 광고 이미지를 만들어라 페이스북 뉴스피드를 생각해 봤을 때 따분한 광고들로 가득 차있을 것입니다. 그럴 때 사람들의 시선으로 사로잡을 수 있는 다채로운 광고를 만들어보세요!사람들을 사로잡는 광고는 어렵고 화려한 포토샵 스킬이 들어간 광고가 아닙니다.조사에 따르면 대부분의 사람들은 사람이나 상품의 첫인상을 90초 이내에 평가한다고 합니다. 그중 약 62-90%는 색깔에 영향을 받습니다.만약 어떤 컬러를 사용해야 할지 모를 때엔   브랜드 컬러 유지하기  색깔에 따라 줄 수 있는 심리적인 느낌에 맞게 선택하기  3-5가지 다른 컬러를 A/B 테스트하기 The New York Times는 새로운 페이스북 광고 색상을 다채롭게 사용하여 지속적으로 테스트하고 있습니다. 페이스북 광고디자인 Tip #2  : 대조되는 색상을 사용해라UsabilityTools의 조사에 따르면 대조적인 색상을 사용한 랜딩페이지는 그 전 광고에 비해 클릭률이 75% 증가했다고 합니다. 대조가 강할수록 광고에 더 많은 집중을 가져올 수 있습니다. 나이키의 광고를 예로 들어 보겠습니다. 나이키의 대조적인 광고는 시선을 바로 끌게 합니다.Udemy의 다른 예가 있습니다. (주황색과 흰색 광고 요소의 대비에 주목하세요.)때로는 광고 요소 사이의 대조뿐만 아니라, 전체 뉴스피드와 대조되는 페이스북 광고도 사람들의 시선을 주목시킬 수 있습니다.페이스북 광고디자인 Tip #3  : 긍정적인 이미지를 심어줘라이미지는 이야기를 말하며, 인공지능 개척자 Ray Kurzweil에 따르면 우리의 뇌는 유용한 조언을 찾는 패턴으로 채워져 있습니다. 그렇다면, 페이스북의 광고 디자인이 이야기를 하도록 만들 수 있다면 어떨까요?SumoMe의 광고를 예로 들겠습니다.이 그래프는 꾸준히, 빠르게 성장하고 있는 SumoMe의 성장 곡선입니다.그래프를 보고 부럽다는 생각이 드셨나요?심리학자들은 오늘날 사람들이 브랜드를 결정하게 만드는 것은 정보보다는 감정에 의지한다고 설명합니다. 그렇기 때문에 회사에 긍정적인 부분을 브랜드에 연결하는 것이 중요합니다. (예: 회사의 빠른 성장)뉴스피드에서 이 광고를 본 후, 사람들은 SumoMe를 꾸준히 성장하는 브랜드라고 연상할 것이며, 클릭을 하게 되고 클릭수가 많아질 것입니다.페이스북 광고디자인 Tip #4  : 기억할만한 기호를 사용해라잠재 고객이 긍정적인 감정으로 광고를 기억할 수 있도록 디자인에 '긍정적인 기호'를 포함해야 합니다. '긍정적인 기호'는 다음을 포함할 수 있습니다.체크 표시스마일 이모티콘축하 이모티콘별 표시그 예시로 Asana의 페이스북 광고를 볼 수 있습니다. Asana의 광고디자인에는 확인 표시 아이콘과 함께 성장 곡선을 표시합니다.이러한 기호는 무엇을 느끼게 할까요?이 광고를 보는 사람들은 시간 안에 일을 마친 것 같은 느낌을 느끼게 될 것입니다. 그러한 느낌은 보는 사람들로 하여금 긍정적인 인식을 가져다줄 것이며, 그러한 긍정적인 인식은 광고효과로 이어질 것입니다.페이스북 광고디자인 Tip #5 : 핵심 키워드를 잘 보이게 배치해라 만약 광고를 사람들에게 알리는 것이 첫 번째 목적이라면 이미지 안에 바로 핵심 메시지를 배치하는 것이 좋습니다. 또한 광고 이미지 텍스트가 짧고 간결한지 확인해보세요.Upwork는 핵심 메시지인  “Find Your Perfect Freelancer”를 사람들의 시선에 바로 들어올 수 있는 위치에 배치하여 그들의 핵심 메시지를 바로 눈에 들어올 수 있게 디자인하였습니다.-이제 동일한 광고 디자인을 반복해서 보면서 타깃 고객에 대해 걱정할 필요가 없습니다. 이 글을 통해 페이스북 광고효과가 향상되길 바랍니다:)            퍼포먼스 마케팅 에이전시, 오피노 바로가기

이전 스팀헌트 피칭 글에서 밝혔듯이, 필자는 IEO를 통한 토큰 세일을 진행중이다. 남들은 제품 만들기도 전에 토큰 펀딩을 먼저 하는 이바닥에서 1년간 제품과 유저에만 집중하고 있다가 뒤늦게 토큰 펀딩을 진행하면서, 그동안 내가 전혀 몰랐던, 다소 Dodge한 이야기들에 대해 몇가지 경험담을 풀어보고자 한다.1. 일부 거래소의 수익모델: 순위조작 -> 상장피사실 풍문으로는 어느정도 듣던 이야기이고, 거래소가 오더북 구성을 위해 MM (마켓메이킹)을 돌린다는 미명 하에 자전을 한다는 것도 어느정도는 알고 있었다. 그런데, 한가지 몰랐던 사실은, 일부 "대형" 거래소들의 수익모델 중 하나가, 이런 엄청난 자전으로 코마켓 순위를 펌핑한 다음 이걸 기준으로 "우리 거래소는 대형 거래소니까 상장피 30-50 BTC 내셈" 이라는 상장피 장사라는 거.요즘 돌고있는 아주 재미난 엑셀시트가 하나 있다.https://docs.google.com/spreadsheets/d/13_L5V9elxQ3xps62BeYVyr_Wu-9vfyAyN5tGqLNoV9Y/edit?usp=sharing이건, 각 거래소들의 코인마켓캡에 찍힌 거래량과, 누구나 해당 웹사이트 도메인의 방문자 수를 검색해 볼 수 있는 SimilarWeb의 한달 방문자 수를 비교하여, 보통 방문자 한명당 평균적으로 트레이딩하는 볼륨 수를 추정한 다음 실제 거래량과 비교하여 얼마나 Fake가 많이 섞여있는지를 분석한 구글시트이다.깊게 들여다보면 사실 한명당 평단 거래 금액에서 많은 오류가 있어보이지만, 비교 방식 자체는 사실 우리도 거래소 선정할때 하는 방식이긴 하다.위에서도 말했듯이 거래소에서 "자전"을 돌리는건 뭐 솔직히 안하는 거래소가 거의 없을 정도로 (혹은 거래소에서 토큰들에게 MM 붙이는걸 필수로 요구) 이미 룰 처럼 되어 있는거라, 이걸 논의하는건 아무 의미가 없다. 문제는, 일부 거래소들 중에서 이렇게 자전 펌핑을 엄청나게 시켜놓은 다음에 이걸로 "상장피" 장사를 하고 돌아다닌다는게 참 더지하다는 것이다.이런 거래소 들은 주로 다음과 같은 방식으로 운영된다.1) 자전으로 만들어낸 볼륨으로 코마켓 순위 Top 20위 권을 유지한다2) 전 세계의 수 많은 "리스팅 에이전시"를 돌리는데 (주로 개인이다), 이들은 주로 상장을 유치해 오면 상장피의 일부를 커미션으로 받는다3) 상장피는 보통 30-50 BTC (현 시세로 약 1.4억 - 2.3억원 정도)을 기본으로 받고, 3억 넘게 부르는 경우도 있다고 한다4) 이런곳 상장시키면 대부분 자전이라 실제 거래량은 거의 안나올수밖에 없다 (그 거래소에 실제 유저가 거의 없으니까)예시를 하나만 들어볼텐데, IEO 진행하고 있으면 아래와 같은 이메일, 텔레그램 메시지를 하루에도 몇통씩 받는다.저 거래소는 진짜로 코마켓 들어가보면 상위 20위권은 꾸준히 유지하는 곳이다. 코마켓만 보면 진짜 대형 거래소 같다. 저런 메일을 보내는 사람들은 보통 거래소 영업사원, 상장 에이전시, 개인 사업자인 경우가 많다. 상장피는 보통 30BTC가 미니멈이라고 하고 원래 정가는 50BTC가 넘는데 자기 통해서 다이렉트로 들어가서 그나마 싸게 하는거라는 무슨 브로드밴드 텔레마케팅 전화받는것 같은 얘기를 늘어놓는다.자, 그럼 저기가 정말 저 돈을 내고 들어갈만한 곳일까?이럴때 위에 SimilarWeb을 이용해도 좋지만, 나는 주로 https://www.worthofweb.com/ 사이트를 이용한다. 여기가 SimilarWeb보다 데이터 업데이트가 빠른편이이기 떄문이다. 여기서 위 거래소 트래픽을 조회해 보면 다음과 같다.(거래소 프라이버시를 위해 숫자는 좀 숨겼다)전 세계 Top 20 안에 드는 대형 거래소의 하루 방문자가 겨우 내가 운영하는 스팀헌트 사이트 수준인 13,000명?? 참고로 코마켓에서 거래량 기준 30위권에도 못들어가고 있는 우리나라 최대 거래소인 업비트의 하루 방문자 수 이다.무려 7배 이상이나 많다. 보이는가? 저런식으로 한달에 토큰 20개만 상장시켜도 평균 상장피 40 BTC 잡았을때 우리돈 한 40억원쯤은 그냥 앉아서 돈버는 BM이 탄생하는거다. 저기에 더해서 저렇게 상장피 내고 리스팅하는 토큰들은 MM (마켓메이킹) 돌리는걸 필수로 요구한다. 이들 수법이 뭐냐면, 메인 코인인 비트, 이더, 이오스 등등 일부만 자기들이 자전 돌려서 거래량 펌핑하고 (거래량 Top 20 거래소 만들어야 하니까), 나머지 알트들은 상장피 받아 상장시켜준 후에 그들에게 MM돌리게 요구하고, 그들이 MM돌리면 또 거기서 거래 수수료 받아 처묵처묵하는... 이런 신기한 BM이 돌아가는 세계인 것이다.2. ICOBench 레이팅 사업 --> 돈받고 레이팅 올려줌얼마전에 우리 커뮤니티 매니저님이 이런 메시지를 받았다.으잉? 우린 ICObench에 올린 적이 없는데?? 그래서 들어가보니 진짜로 이렇게 누가 올려놨다.평점 2.9로 엄청 낮다. 이유는 없다. 흐미 어뜨카냐... 그렇게 고민하고 있으면 아래와 같은 메시지를 준다.6이더 내면 자기들이 보유한 평점 매기는 패널들로 평점 부스팅 해주겠다는 뜻이다. 뭐 100만원 좀 안되는 돈이긴 하지만, 저런식으로 지들이 맘대로 ICObench에 평점 ㅈ같이 올려놓고 저런식으로 협박해서 돈받아 처묵처묵하고 평점 장사를 하고 있는 것이다.궁금해서 저런건 시크하게 ㄱ무시 하고 있을법한 멋진 플젝들 몇개 찾아봤다.콘텐츠 프로토콜이 2.9란다 ㅋㅋㅋㅋㅋㅋ 역시 우리랑 같은 상황이다. 누가 지들 멋대로 대충 올려놓고 평점 2.9로 깔아놓은다음에 분명 컨택했겠지. 근데 콘텐츠 프로토콜이 저딴 ICObench 팔아서 홍보해야할 이유가 당근 없으니 걍 무시했겠지 ㅋㅋㅋ물론 여기에 올라간 모든 플젝들의 평점이 다 뻥이라는 뜻은 절대로 아니다. 다만, 저렇게 지들이 멋대로 레이팅 낮게 올려놓은 다음에 돈내면 레이팅 올려줄께 하는 더지한 사업 영역이 있다는걸 보여준 것 뿐이다.3. 유투버, 텔그방 사칭 스캐머이것도 하루에 몇통씩 텔그 메시지를 받는건데, 본인이 무슨무슨 유투브 채널 운영중인데, 돈 얼마 내면 자기가 우리 코인 분석 올려준다고 한단다. 이건 대부분의 유투버들의 비엠이니 전혀 이상할게 없다. 그러나, 아래와 같은 상황이면 뭔가 좀 이상하다.저 유투브 들어가보니 구독자수 12만 이상의 영상도 제법 고퀄이고 모든 영상이 기본 몇만뷰 이상씩 찍고있는 1등급 레벨의 유투버이다.아니 저정도 채널이면 굳이 본인이 저렇게 홍보 안해도 알아서 유료 리뷰 문의가 쇄도할것 같은데 왜 굳이?? 뭔가 이상한 생각이 들어서 저 채널의 공식 이메일 주소를 확인한 후에 저 텔그를 보낸 사람에게 해당 이메일로 메일 한번만 보내달라고 요청했다.참고로 저 채널의 공식 이메일은 아래와 같다.잠시 후 메일이 한통 날라왔다. 메일주소가 [email protected] 라고 한다.... ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ즉, 이렇게 본인이 어떤 대형 유투버, 서브레딧 채널 관리자, 텔그방 관리자 등등을 사칭하면서 교묘하게 스캠을 하려고 메시지를 보내는 사람들이 진짜 하루에도 몇통씩 날라오는데, 왠지 저기에 속는 프로젝트들 제법 있을것 같다.내 브런치를 구독하는 분들이면 아마 익숙할 것이다. 여기부터는 내가 진행중인 프로젝트에 대한 광고가 들어갈 예정이니, 광고 보기 싫으신 분은 창을 닫아주시면 되겠다.위와같이 더지하고 어려운 상황 속에서도, 우리는 스팀헌트라는 스팀 기반의 댑 프로젝트를 열심히 운영중이다.스팀헌트 - https://steemhunt.com/스팀헌트는 테크 얼리어답터들이 인터넷에서 발견한 테크 관련 신박한 제품들을 "나 오늘 이런거 발견했는데 어떰? ㅇㅈ?" 이런 느낌으로 간단하게 공유하고, 서로 니꺼가 쿨하네, 내꺼가 더 ㅇㅈ네 하면서 랭킹 경쟁을 벌이는 커뮤니티 사이트 이다. 이걸 스팀 위에서 돌림으로써, 저런 서로의 덕후심을 뽐내는 이들이 스팀 토큰 보상을 받을 수 있어 더욱 덕후활동을 더 열심히 하게 만드는 댑 (DApp) 인 것이다.나름 1년간 운영하면서 어느새 온체인 유저 수 15000명 이상, 오프체인 유저 수 월 10만 이상, 전 세계 모든 댑들 약 2,600개 중에서 항상 최 상위 20위권을 유지중인 제법 규모있는 댑 서비스로 성장하였다 (참고로 게임이나 도박도 아니면서 이정도 유저 유지하는 댑 서비스 몇 안됨). 이에대한 자세한 얘기는 이 글을 읽어주시기 바란다.스팀헌트 피칭 - https://brunch.co.kr/@andrewyhc/105이 프로젝트에 기업들이 테크 덕후들에게 인플루언서 마케팅 및 크라우드 펀딩을 돌릴 수 있는 플랫폼인 헌트 플랫폼으로 확장하는 프로젝트를 전개하면서, 이에 거래소를 통한 토큰 펀딩인 IEO를 진행중이다.이미 1차 IDCM에서의 세일은 거의 150%의 청약율을 보이며 성공적으로 마무리 되었고, 2차 세일즈는 현재 프로비트 거래소에서 진행중인데, 1라운드는 11초만에 완판되는 기록을 세웠고, 2라운드는 이번주 화요일 (26일)까지 진행 중이다.https://www.probit.com/en-us/ieo/hunt-round1/1실제 1년간 운영중인, 그리고 제법 큰 규모의 온체인 유저가 돌아가고 있는 탄탄한 토큰 경제를 기반으로 한 테크 제품 런칭 시장을 공략하고 있는 헌트 플랫폼에 관심 있으신 분들의 많은 관심 부탁드린다.헌트 플랫폼 소개 - https://token.steemhunt.com/IEO 관련 문의 - https://open.kakao.com/o/g1odiHhb

안녕하세요.미미박스의 소식을 전달드리는 Ava입니다~여러분, 사랑하는 사람에게 사랑을 표현해 본 적이 언제인가요?저는 고향이 대전인데요. 고향에 계신 부모님께 자주 연락드려야지 하면서도연락을 많이 못 드리는 거 같아요 ㅠㅠ우리 의식적으로 사랑을 많이 표현해보아요.이렇게 사랑의 마음을 전달하는 것을 도와드리기 위해꽃다발 이벤트를 기획했는데요.장미수 로센스와 미미박스가 함께 고객들로부터 사연을 받아한 분을 추첨하여 깜짝 이벤트를 함께 기획했습니다. 두근두근 어떤 사연이 뽑혔을까요?바로 윤지영 고객님의 사연이 뽑혔습니다.외숙모와 함께 찍은 사진과 함께 사연을 올려주신 윤지영 고객님!숙모와의 사연에 제가 다 울컥해지네요 ㅠㅠ...이렇게 감사한 외숙모에게 감동 이벤트를 해드리기 위해저희 미미박스가 윤지영 님을 직접 만났습니다!!!!마치 연애 조작단(?)처럼 외숙모를 위한 사전 영상 촬영 및 이벤트 기획을 함께 진행했죠!이렇게 미미박스, 로센스, 윤지영 고객님이 함께 기획한 이벤트...함께 보실까요!?메이크업 이벤트에 당첨되었다고 외숙모를 모시고, 미미박스에서 메이크업을 해드렸습니다. 그리고 2층으로 모셨죠!2층으로 올라가자마자 시작된 윤지영 고객님의 감동 메시지 영상.. ㅠㅠ외숙모의 눈가에 눈물이 마르지 않으시네요 ㅠㅠ이렇게 로센스, 고객님과 함께 진행한 이벤트, 여러분들은 어떠셨나요?우리도 한번 작은 이벤트로 사랑하는 사람들을 감동시켜봐요!!

https://brunch.co.kr/@rr5ys5s/10태그솔루션의 투명디스플레이 이야기 (2)기술 개발 그리고 제조업이라는 높은 벽(?) | 안녕하세요! 태그솔루션의 대표 박승환입니다! 먼저 앞선 글(링크: https://brunch.co.kr/@rr5ys5s/9 )을 통해 태그솔루션의 전체적인 이야기와 밑그림을 보셨다면 이번에는 말씀드렸던 제품 개발 및 양산에 대한 제조의 이야기를 해보려고 합니다! 이 글을 통해서 기술기반의 제조 창업이라는 분야에 대한 거부감이나 어려움을 조금이나마 덜어brunch.co.kr/@rr5ys5s/10 안녕하세요! 이전 글에 이어서 투명 디스플레이 패널의 바디 부분인 패널과 패널의 제어부를 감싸는 기구부에 대해서 이야기해 보록 하겠습니다.또다시 채용 글 링크 첨부 : https://brunch.co.kr/@rr5ys5s/8태그솔루션 콘텐츠 디렉터 채용 공고채용기간 : ~ 10월 중순까지 | 안녕하세요. 하드웨어 제조 스타트업 태그솔루션 입니다. 저희에 대한 자세한 소개글은 아래 링크를 통해 확인할 수 있습니다!^^ https://brunch.co.kr/@rr5ys5s/9 태그솔루션 시작 그리고 비전 태그솔루션은 2015년 1월 사업을 시작한 하드웨어 스타트업입니다. 투명한 유리에 다양한 기술을 융합하여 부가가치를 창출하는 것을 목표로 하는brunch.co.kr/@rr5ys5s/8 1. 투명한 회로를 만드는 방법?플라스틱 소재 위에 말 그대로 투명한 회로를 형성하여 우리 패널이 만들어졌다. 그렇기 때문에 LED부분을 제외한 나머지 부분은 투명할 수 있다. 기존에 회로는 눈에 보이는 게 대부분이지만 눈에 보이지 않는 회로는 어떻게 만들어지는 것일까?이러한 투명전극은 우리 실생활에서도 굉장히 밀접하게 쓰이고 있다. 우리가 매일 손에 들고 다니는 휴대폰의 액정부분에 들어가는 터치패널 역시도 투명 전극으로 대부분 만들어졌다.휴대폰 터치 액정의 모습휴대폰뿐만 아니라 디스플레이 등의 정말 수도 없이 많은 분야에서 투명전극이 활용되고 있다.  투명한 회로는 투명한 물질 자체와 투명해 보이도록 설계된 형상 등으로 구분된다. 말 그대로 투명한 물질을 활용해서 투명한 선을 만들어주거나, 미세한 패턴과 네트워크 구조를 통해서 쓰이는 물질 자체는 투명하지 않지만 투명한 것처럼 보이게 하는 형태로 투명한 회로를 형성할 수 있다.대부분의 투명전극은 자세히 보면 그 회로의 패턴이 보인다.ITO(산화 인듐 주석), 은나노와이어, CNT(탄소 나노튜브), 메탈메쉬 등 다양한 물질 및 형태의 투명전극이 존재한다. 이렇게 천차만별인 투명전극을 형성하는 공정과 물질(전도성 물질 - 구리, 은 등)에 따른 공정 또한 다양하게 존재하며, 실제로 투명전극은 기존에 쓰이는 전극들에 비해서 저항 값이 높아서 용도에 맞게 저항에 대해서 고려를 해야 한다. ( 투명전극의 이슈는 저항과 투명도가 반비례하기 때문에 위 두 가지 부분에서 스펙이 다양해진다고 할 수 있다. 투명도를 포기하면 저항이 낮고, 투명도를 높이려면 저항이 높아지는 공평한 현실... )은나노와이어의 확대된 구조확대되어 보이기 이전에는 투명하지만 나노 단위로 확대하게 되면 은이라는 물질 자체의 네트워크 구조를 만들어서 전기가 통할 수 있게 만드는 것이다. ( 은 자체가 투명하지 않지만 미세한 구조를 만들어서 투명해 보이는 효과를 만들어 내는 것이다! )자 이렇게 투명전극의 종류를 알아보았으면 이렇게 형성된 투명한 전극을 패터닝을 통해 회로를 형성하여야 투명한 회로를 만들 수 있다. 이 과정을 흔히 에칭(etching)이라고 표현을 한다. 에칭은 약품이나 레이저를 통해 금속이나 유리표면을 부식시키는(제거하는) 공정의 표현법 중 하나다.예를 들어서 작은 필름 위 전면에 은나노와이어의 구조를 형성해 준 후에 위 에칭의 과정을 통해서 내가 원하는 회로의 패턴을 형성하는 것이다. 이 에칭 기법은 투명전극뿐만 아니라 PCB, 반도체 등과 같은 다양한 분야에서 활용된다.자작 PCB의 모습 이 또한 에칭기법을 통해 만들어진다.이렇게 투명한 회로를 패널에 입혀서 원하는 방식대로 투명한 전극을 활용하는 것이다. 우리 제품의 경우 LED를 제어하기 위한 패턴이 위와 같은 과정을 통해서 플라스틱 소재 위에 형성되었다고 보면 된다!이렇게 형성된 회로 위에 필요한 칩들과 LED를 부착하는 공정(SMT)을 진행하여 패널이 완성된다.사실 가장 중요한 부분은 새로운 제품을 만들기 위해 공정을 내 제품에 맞게 변형하여 활용하는 것도 참 중요하지만, 실제로 만들어진 제품을 얼마나 정확하게 품질 관리를 할 수 있는지도 굉장히 중요하다.실제로 새로운 규격의 제품을 만들게 되면 그에 맞는 새로운 품질 관리를 위한 검사장비나 품질 체크 장비가 필수적으로 필요하다!투명전극으로 무언가 제품을 만들고 싶다는 생각이 드시는 분은 저에게 메일을 주시면 이야기를 좀 더 구체적으로 이야기 할 수 있을 것 같습니다~ ㅎㅎ 연락 주세요!2. 기구부를 만드는 공정은 어떤 게 있을까?자 먼저 기구부라는 것이 무언인지 감을 잡아보도록 하자.기구부를 만드는 공정에는 흔히 쓰이는 4가지 공정들이 있습니다.1. 사출 : 제품의 형태대로 가공된 금형을 통해 제품의 형태대로 성형물을 찍어내는 방식으로 금형의 비용이 사이즈 혹은 형상별로 비쌉니다. 하지만 형상의 자유도는 높은 편이며, 실제로 일상생활에 쓰이는 대부분의 플라스틱 용품은 다음과 같은 방법으로 만들어집니다.사출의 원리2. 압출 : 흔히 떡을 뽑는 것을 생각하면 이해하기 쉽습니다. 떡고물이 쭈욱 뽑히듯이 일정한 축방향으로 형상을 만들어내는 공정입니다. 특히 알루미늄이 소재로 활용이 많이 되며, 사출 금형에 비해 가격이 저렴하고 형상에 대한 자유도가 사출에 비해 낮은 편입니다.압출물의 다양한 모습3. 프레스 : 흔히 금속 가공이라고 말하는 부분이 프레스입니다. 철판에 일정 압력을 가하여 다양한 형태를 만들어낼 수 있습니다. 실제 프레스는 소형부터 대형까지 금형의 규모도 다양하지만 일반적으로 금속 형태의 단순한 구조물이나 철판을 꺾거나 내리찍는 압력을 통해 생산할 수 있는 공산품들과 금속 케이스 등에 많이 사용됩니다. ( 실제로 프레스 공정의 특성상 노동자들이 실수로 손가락이 절단되는 경우도 굉장히 많습니다. )프레스 공정라인의 모습4. 다이캐스팅 : 금속(합금) 형태의 사출! 흔히 차량에 들어가는 부품이나 전자기기, 건축 기계 등을 만들어낼 때 많이 쓰이는 방식이다. 실제로 금형의 비용이 가장 비싸며, 일상 제품보다는 산업용에 많이 사용되는 편이다. (물론 쓰이는 곳은 분명 있을 수 있지만..ㅎㅎ)실제로 저희는 위 과정 중 사출, 압출, 프레스 등을 진행해보았습니다.실제  태그솔루션의 조명 코스모블랑 사출물과 프레스물의 모습패널의 제어부를 감싸주는 기구부(시제품)의 압출 및 프레스(절곡)된 모습원하는 형상을 디자인을 하더라도 아마 실제로 생산 쪽과 이야기를 해보면 디자인을 변경해야 하는 일이 발생할 확률이 큽니다. 바로 그 이유는 금형을 통한 사출 및 압출에서의 생산 부분의 한계가 있기 때문입니다.실제로 원하는 복잡한 형상을 금형을 통해 사출 한다는 건 굉장히 어려운(비용이 많이 드는) 일이기 때문에 실제 금형 디자인과 사출에서의 생산성은 전문가들과의 여러 번의 회의를 거쳐 디자인이 변경되고 변경되며 타협점을 찾게 될 것입니다. ( 물론! 금형을 한 번이라도 만들어 보신 분들은 어느 정도 감이 생겨서 이를 감안한 디자인이 가능해집니다. ) 압출도 마찬가지로 압출로 밀어내는 형상에 대한 두께와 형상에 따라서 불가능한(가능은 하지만 생산 중에 불량이 날 수 있는...) 형태도 다양하기 때문에 전문가(공장 사장님)와의 상담은 필수적입니다.투명 패널의 기구부 랜더링 모습저희는 현재 생산된 패널을 위한 기구부를 최적화하는 과정에 있습니다. 어떻게 하면 더 가볍고, 간편하게 설치할 수 있는 견고한 구조를 만들 것인지에 대한 설계는 계속되고 있습니다.투명하기 때문에 유리에 설치되어도 유리의 성질을 잃지 않고, 가볍기 때문에 쉽게 설치가 가능한 구조를 통해서 다양한 장소에 패널을 설치하고 활용할 수 있는 구조로 제품을 만들고 있는 상황입니다.제조 역시 소프트웨어의 디버깅과 같이 버그들이 존재합니다. 그 버그들을 차근차근 해결해 나가며 완제품에 가까워질 수 있는데, 사실 기간과 비용에 있어서 로드가 큰 것은 사실입니다.그렇기 때문에 실제로 제품을 만들기 이전에는 3D 프린터를 통한 프로토타이핑과 제품에 대한 시장조사, 가격조사, 중국에서의 생산 유무 등을 정확하게 파악한 후에 접근하는 것이 바람직합니다.다음 편에서는 LED를 제어할 수 있는 제어부와 전원부에 대해서 작성하도록 하겠습니다!질문은 메일로 주시면 답변드리도록 하겠습니다!이상입니다.태그솔루션 박승환 씀

알파고와 이세돌의 대결에서 알파고가 3연승을 거둔 이후에 많은 사람들은 충격에 빠졌다. 인공 지능의 발전으로 인해 없어질 직업들을 걱정하는 사람들부터 더 나아가서는 인류의 종말을 경고하는 사람들도 나오고 있다. 이러한 예상이나 걱정이 완전히 근거가 없는 것은 아니지만 지나친 걱정과 두려움이라는 생각이다. 산업 혁명시대에 기계가 일자리를 빼았는것을 두려워한 사람들이 러다이트 운동을 일으켜 기계를 파괴했던 일이 있었다. 하지만 지금 누구도 방직 기계가 사람의 일자리를 빼앗아 가는걸 두려워하지 않는다. 인공지능은 어차피 인간을 위해 인간이 만들어내는 도구에 불과한것이고 인간을 능가할 수는 없다. 계산기가 인간보다 계산을 잘한다고 해서 계산기가 인간보다 우월하다고 하지 않는다.찬란한 문화 예술의 시대로 불렸던 고대 그리스 시대의 이면에는 잉여 생산을 가능케 한 노예 노동이 있었다. 고대 그리스의 시민들은 고된 노예 노동이 만들어낸 잉여 생산물 기반위에 철학과 과학을 논하고 문화와 예술을 즐겼다. 현대 시대에는 노예 노동은 사라졌다. 하지만 인공지능과 로봇기술의 발전은 극단적인 표현으로 말하자면 새로운 노예 노동의 시대를 만들어 낼 수 있다. 인공지능의 발전으로 인해 인류는 루틴하고 반복적인 일들을 맡길 누군가를 만들어 낼 수 있다. 그리고 인류는 좀더 창조적인 일 즉 인공지능이 할 수 없는 일에 좀더 시간을 쏟을 수 있다. 이것이 인류 문명을 더 찬란하게 만들어 줄 것이라 믿는다.  인공지능이 아름다운 음계를 작곡하고 연주한다 하더라도 그 음악 뒤에 숨어있는 철학과 열정을 만들어 낼 수는 없다. 우리가 조성진의 연주에 감동받는 것은 단순히 그 음악이 아니라 음악을 연주하는 열정을 느끼고 열정에 연결되어 있는 스토리에 감동받는 것이다. 인공지능과 로봇이 외과수술을 대신할 수 있지만, 환자들의 아픔에 공감하고 위로하고 희망을 줄 수 있는 것은 사람 의사만이 할 수 있는 영역이다. 그리고 기존 과학 법칙에 의문을 품고 새로운 법칙을 만들어내거나 기존 법과 제도에 반기를 들고 새로운 질서를 만들어 내는것 또한 인간만이 가질 수 있는 능력이다. 우리가 생각하는 것 이상으로 인간의 창의력과 능력은 인공지능이 가질 수 있는 능력을 넘어선다. 인간보다 빨리 달릴 수 있는 자동차를 만들어냈다고 인간이 자동차를 두려워하지는 않는다. 인공지능도 인간의 능력을 보조하는 역할을 충실히 할 도구에 불과하다.인공지능은 분명 인류의 새로운 진보를 만들어 낼 축복이지만 우리가 이러한 새로운 혁명을 맞을 준비가 되어 있는가에 대해서는 다시한번 생각해 볼 필요가 있다. 난 인공지능이 만들어낼 새로운 시대에 우리가 준비해야할 몇 가지를 말하고 싶다.첫번째, 교육을 근본적으로 바꾸어야 한다. 지금 우리나라의 교육은 산업화 시대에 맞는 인재를 만들어내는 교육이다. 무비판적인 지식의 습득을 강조하는 교육 시스템이다. 우리나라의 교육 시스템하에서 학생들은 정해진 시간에 누가 빨리 암기하고 누가 빨리 문제를 풀어낼 수 있도록 훈련하고 배우고 있다. 무비판적으로 지식을 습득하고 암기한다. 사람이 아무리 빨리 수학계산을 할 수 있도록 훈련한다고 해도 컴퓨터를 이길 수 없고, 사람이 아무리 암기를 잘한다 해도 컴퓨터의 저장능력을 이길 수 없다. 지금 우리 아이들에게 필요한 것은 인공지능이 할 수 없는 영역의 일을 가르쳐야 한다. 기존의 지식에 의문을 품고 질문을 만들어 내고 사람과 사람의 감정을 공감하고 감동을 만들어 낼 수 있는 인재로 교육시켜야 한다. 언제든지 인터넷으로 찾을 수 있는 '수학 공식'과 '역사 연대표'를 외우고 있는 학생들을 보면 안타까운 생각밖에 들지 않는다. 정확한 답을 찾는 교육이 아닌 올바른 질문을 찾아내는 교육이 되어야한다. 질문과 호기심은 인간만의 재능이고 이것이 인류 문명을 발전시켜왔다.두번째, 인공지능이 만들어 낼 잉여 생산을 소수의 사람들이 독점해서는 안된다. 산업화 시대에 태동한 자본주위는 소수의 부의 독점과 그로인한 수요의 실종으로 인해 발생한 대공황때 붕괴 위기를 맞는다. 그리고 경제학자들은 기존의 자본주의를 수정한 수정 자본주의 개념을 도입하고 국가의 개입을 정당화 시켰다. 서양의 사회 복지 제도는 단순히 인본주의 혹은 동정주의로 인한 것이 아니라 사회 시스템을 건강하게 유지시키고 지속 가능한 경제 성장을 만들어내기 위한 방법인 것이다. 그것은 빈부격차가 심한 멕시코와 남미가 치솟는 범죄율과 사회의 불안정으로 인해 경제 성장이 위협받는 것과 안정적인 복지제도로 인해 사회 안정을 바탕으로 지속적인 경제 성장을 만들어내는 북유럽을 비교하면 쉽게 이해 할 수 있을 것이다. 인공지능과 로봇은 잉여 생산을 만들어 낼 것이다. 그리고 그것을 소수가 독점하지 못하도록 사회 시스템을 만들지 못한다면 인공지능과 로봇이 만들어낸 잉여 생산을 사줄 소비자들은 구매력을 상실하고 사회 경제 시스템이 붕괴 위기에 놓일 가능성이 높다. 난 최근 북유럽에서 도입되고 있는 '기본 소득'이 이러한 노력의 일환이라고 생각한다.우리는 새로운 도전의 시대에 살고 있다. 인공지능은 분명 인류의 축복이 될 것이다. 하지만 인공지능은 도구에 불과하다. 그 도구를 제대로 쓰지 못한다면 그 축복은 분명 저주가 될 가능성도 있다. 도구나 기술은 무색무취이다. 결국 도구나 기술을 쓰는 사람들이 그 도구와 기술의 색깔을 만들어 낸다.#NEOFECT #인사이트 #인공지능 #기술혁신 #4차산업혁명

Kafka 도입 이후에 점진적으로 모니터링을 개선해나간다. Kafka와 그 제반 환경에 대해 이해한만큼 모니터링을 구성하고 모니터링 시스템에서 피드백을 받아 다시 학습하고 그렇게 배운 것을 토대로 다시 모니터링을 구성한다. 그 과정을 따라 나가며 Kafka 를 어떻게 모니터링하면 좋을지 알아보자.프로세스 모니터링아무래도 가장 기초적이면서 중요한 지표는 Kafka 프로세스가 잘 살아 있는지 확인하는 것이다. 다섯 대로 구성한 클러스터라면 상시 Kafka 프로세스가 확인되어야 한다. 만약 Kubernetes의 StatefulSet으로 Kafka 클러스터를 구성한 경우라면 Kafka 프로세스 다섯과 프로세스 모두를 엮는 서비스, 그러니까 로드밸런서 하나를 포함해 총 여섯 개의 프로세스를 확인해야 한다. DataDog(통칭 멍멍이)을 이용해 모니터링하는 경우라면 다음과 같이 설정하면 된다.Monitoring Kafka ClusterKafka는 Zookeeper를 이용하므로 ZooKeeper 역시 동일하게 모니터링하면 된다.DataDog을 이용한 메트릭 모니터링`dd-agent는 Kafka 관련 메트릭을 Broker, Consumer, Producer 세 측면에서 수집한다.Monitoring Kafka with DatadogMonitoring Kafka performance metrics위의 두 문서가 Kafka 모니터링의 상세한 측면을 기술하는데 멍멍이를 이용하지 않더라도 꼭 한번 읽어볼만하다. 두 문서가 매우 훌륭하므로 이 글에서는 Kubernetes 환경에 초점을 맞춰 주목할 점만 살펴본다.Kubernetes 환경에서 멍멍이 에이전트는 보통 PetSet으로 구성한다. 말인즉 Kubernetes Worker 한 대마다 에이전트를 한 대씩 띄워서 Worker 안에서 작동하는 모든 도커 인스턴스의 메트릭을 수집한다. 일단 에이전트를 설정하고 나면 아래와 같이 Kafka 모니터링이 정상 작동하는지 확인하면 된다.kube exec -it dd-agent-17vjg -- /opt/datadog-agent/agent/agent.py info kafka ----- - instance #kafka-kafka-0.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-1.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-2.broker-9999 [OK] collected 46 metrics - Collected 138 metrics, 0 events & 0 service checks Emitters ======== - http_emitter [OK]Broker의 경우는 설정하기가 비교적 쉽다. Kubernetes에서 Kafka 같은 Stateful cluster는 StatefulSet으로 구성하게 되는데 이때 호스트 주소가 kafka-0, kafka-1 같이 예측 가능한 이름으로 정해지기 때문에 kafka.yaml을 미리 작성해두기 쉽다.instances: - host: kafka-0.broker port: 9999 # This is the JMX port on which Kafka exposes its metrics (usually 9999) - host: kafka-1.broker port: 9999Producer와 Consumer 모니터링은 이와는 다르다. 구현하기 나름이지만 Producer 또는 Consumer가 되는 응용프로그램은 Stateless cluster일 때가 많고 그런 경우에는 Kubernetes에서 Deployment로 클러스터를 구성한다. 이때는 StatefulSet인 경우와 달리 호스트 주소가 worker-903266370-q3rcx와 같이 예측하기 힘들게 나오므로 에이전트에 미리 설정을 넣을 수가 없다. 상당히 까다로운 문제이다.Consumer 모니터링Kafka의 설계는 매우 단순하면서도 강력해서 감탄하곤 한다. 하지만 복잡한 문제를 단순하게 풀어냈다고 해서 이를 둘러싼 환경을 제대로 모니터링하는 것도 쉽다는 뜻은 아니다. 특히 Consumer groups이 제대로 제 몫을 하고 있는지 파악하기는 더 어렵다. Consumer group마다 모니터링 체계를 갖추자니 번거롭다. 게다가 그런 번거로움을 극복하더라도 Kafka에 문제가 있는 경우를 탐지하기는 여전히 어렵다. 예를 들어 Consumer에게 가야 할 메시지 중 5%가 실제로는 전달되지 않는다 하면 이를 Consumer가 알기는 어려울 것이다. 이 외에도 Consumer 측 모니터링이 엄청나게 까다로운 문제임은 Burrow: Kafka Consumer Monitoring Reinvented에서 잘 밝혔다.Burrow: Kafka Consumer Monitoring Reinvented에 등장하는 Burrow는 Kafka를 세상에 내놓은 LinkedIn 엔지니어링 팀이 개발한 Kafka 컨슈머 모니터링 도구이다. 커뮤니티에서는 대체로 현존하는 가장 뛰어난 모니터링 도구라고 인정하는 분위기이다. 그러니 다른 도구도 많지만 우선 Burrow로 모니터링을 강화하기로 한다.Burrow로 Consumer 모니터링하기Burrow는 Dockerize가 잘 되어 있기 때문에 사용하기 어렵지 않다. LinkedIn이 공식 도커 이미지까지 제공했더라면 더 좋겠으나 GitHub에 Dockerfile과 docker-compose.yml을 올려놓아서 도커를 잘 아는 사람이라면 큰 어려움 없이 바로 설정하고 설치할 수 있다. 컨테이너 환경의 관례대로 주요 설정을 환경변수로 미리 빼놨으면 더 좋았겠지만 …알람 받기Burrow는 문제가 생겼을 때 알람을 발송하는 기능이 있다. 위키에는 이메일 알람과 HTTP 알람(Webhook)을 어떻게 설정하는지 설명한다. 그런데 Burrow 소스코드를 살펴보면 문서화되지 않은 알람 기능도 있으니… 바로! Slack 알람을 제공한다. 아직 공식 문서가 없고 소스코드도 godoc 관례에 맞춰 설명해놓은 부분이 전혀 없기 때문에 소스코드를 읽거나 GitHub 이슈에서 논의된 내용을 토대로 설정해야 한다.[slacknotifier] enable=true url=https://hooks.slack.com/services/xxxx/xxxxxxxxxx group=local,critical-consumer-group group=local,other-consumer-group threshold=0 channel="#general" username=burrower interval=5 timeout=5 keepalive=30멍멍이로 메트릭을 꾸준히 수집하고 이슈가 생겼을 때 알람을 받고자 한다면 packetloop/datadog-agent-burrow를 이용하면 된다.This plugin will push the offsets for all topics (except the offsets_topic) and consumers for every kafka cluster it finds into Datadog as a metric.멍멍이 에이전트에 필요한 파일과 설정을 넣고 나면 아래와 같이 메트릭이 수집된다.kafka.topic.offsets 와 kafka.consumer.offsets 이렇게 두 개의 메트릭만 수집하지만 각 메트릭을 cluster, topic, consumer 세 개의 토픽으로 세분화하기 때문에 실제로는 꽤 다양한 지표를 멍멍이에서 확인하고 이용할 수 있다.알`람 설정하기앞서 살펴봤지만 프로세스 모니터링 등은 어렵지 않다. 클러스터에서 한대라도 빠지면 바로 알람을 받는다. 끝!하지만 그 외의 지표는 알람의 기준을 설정하기가 힘들다. 예를 들어 Burrow의 kafka.topic.offsets 값이 600이면 정상인가? 그렇다면 700은? 또는 400은? 도무지 감을 잡을 수가 없다. 이럴 때는 멍멍이가 제공하는 Outlier detection기능으로 알람을 걸면 쉽다. 이 기능은 쉽게 말해 평소와 다른 행동을 감지했을 때 알람을 보낸다. 그러므로 정상의 범위를 확실하게 모를 때 아주 유용하다.설정 자체는 DBSCAN 또는 MAD라는 알고리즘이 등장하는 것만 빼곤 여타의 모니터링과 다르지 않기 때문에 매우 쉽다.참고 문헌How to Monitor KafkaCollecting Kafka performance metricsOriginally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #기술스택 #스택소개 #Kafka

'스타트업'이라는 단어 아는 사람 치고 '린스타트업'이라는 것을 모르는 사람은 흔치 않을 것이다.내가 린스타트업에 대해 알게 된 것은 2013년이었던 것 같다. 1년 정도 열심히 연구해보면서, 실제로 린스타트업에 맞춰서 사업개발을 해보기도 했고, 여러시도를 해봤던 것 같다. 하지만, 지금 나는 린스타트업 회의론자다. 린 스타트업에는 많은 약점이 있다고 본다.우선, 린스타트업은 기업이라면 마땅히 갖춰야 할 '방향성'과 '거시적인 전략'을 갖추는 부분에 있어 매우 취약하다. 이는, '스타트업'을 아직 '기업'이 되기 이전의 실험적인 임시조직으로 보기 때문이다. 이 때문에 린스타트업은 사업을 Bottom-up 형태로 개발하게 유도한다. 아주 낮은 단계 가설을 세우고, 그것에 맞는 실험을 하여, 실험을 통과하면 그다음 단계 가설로 넘어가는 방식이다.하지만 린스타트업을 알고 5년이 지난 지금 다양한 사례를 보며 연구한 결과, 린스타트업 이론으로 성공한 기업은 매우 드물었다. 마치, 실험실에서 실험을 하는 것처럼 작은 가설을 하나하나 입증한 기업들은 자신의 최종 목적이었던 '특정 타겟군 X를 위한 유튜브(우버, 페이스북 등)'이라는 가설을 입증하는 데 도달한다. 그러나, 사실 이런 린스타트업 모델을 서비스에 적용한 스타트업들의 최종 목적은 여기서 끝나는 것이 아니라 이 작은 승리를 바탕으로 사업을 확장시키는 데 있었다.실제로, 'X를 위한 페이스북'등을 바탕으로 한 많은 SNS, O2O 업체들 중 어느 정도 성공한 스타트업들이 많았지만, 그들이 진짜로 만들고 싶었던 것은 'X를 위한 페이스북' 정도가 아닌 이것을 바탕으로 비즈니스 모델을 하나하나 늘려, 의미 있는 규모의 시장을 빠르고 정확하게 잡아내겠다는 것이었을 것이다. 그리고, 그 최종 가설(방향성)에 금융자본도 몰렸을 것이라 생각한다.하지만, 대부분 이렇게 정확한 타겟팅으로 정확한 실험에 성공한 스타트업은 해당 서비스를 Horizontal 또는 Vertical Expansion 하는 데 대부분 실패했다. 이는 작은실험에 성공한 스타트업들이 일정 궤도 이상으로 지속가능하게 성장 가능한 사업모델을 갖추는 데 실패했음을 의미한다. 왜 이런 일이 발생했을까? '고객이 만족하는 것을 만든 것' VS '고객이 원하는 것을 만든 것'대부분의 Bottom-up 사고방식은 아주 작은 단계에서 그다음 단계로 넘어가는데 너무 집중하는 경향이 있다. 여기에 더해, A/B 테스팅까지 하다 보면, 고객의 취향에 따라 사업의 Focus가 마치 사다리 게임처럼 여기저기 랜덤 하게 움직이게 된다. 결론적으로, 창업자 스스로도 자기가 왜 창업을 했으며, 이 서비스를 하고 있는지 망각하고 전체적인 방향성을 잃고 고객의 취향과 단기적인 실험 결과에 의해 사업을 운영하게 될 수 있다. 하지만 창업자 스스로는 이것을 전혀 문제로 느끼지 않을 확률이 크다. 린스타트업 이론에 너무 몰두하게 되면, 이 상황을 '나는 고객을 만족시켰어'라고 단순하게 바라볼 수 있다. '고객을 만족시켰어'와 '고객이 원하는 것을 마침내 만들었어'에는 아주 큰 차이가 존재한다. 린스타트업 이론은 이 두 가지 경계를 모호하게 만들어 중대한 오류를 야기할 수 있다.고객이 만족하는 것을 만들기 위해서는 고객을 지속적으로 인터뷰하며 직접적 또는 간접적으로 힌트를 얻어, 그들이 원하는 것을 만들어주면 된다. 이 때문에, 린 스타트업은 가설에 대한 반복된 실험을 통해 고객이 '만족하는 것'을 만들 수 있는 완벽한 이론인 것이다. 그러나, 고객이 '원하는 것'을 만드는 것은 실험적으로만 풀어낼 수 없는 것이다. 고객의 '니즈'는 고정된 것이 아니라 시간, 상황 등에 따라 지속적으로 변화하기 때문이다. 대부분의 크게 성공한 비즈니스를 보면 '타이밍'이 가장 핵심 Factor인 경우가 많았다. 즉, A라는 가설을 검증하는 실험에 실패했더라도, 한 달 뒤에 실험을 재개하면 성공할 수 있다는 것이다. 이 때문에 '린스타트업'이라는 실험주의적인 모델은 단독으로 쓰여선 안된다. 무엇보다 먼저, 거시적인 사업전략과 방향성을 세운 뒤, 전략의 실행방안을 디테일하게 세분화하여 그 점들에 국소적으로 '린스타트업'을 적용하는 것이 더 합리적으로 보인다.전통적인 기업들은 이러한 '전략'의 형태가 더욱 강한데, 스타트업들은 이런 것을 대기업들이나 하는 것이라고 무시하는 경향이 있다. 그들이 말하는 전략이 너무 광의의 개념을 담고 있기 때문이다.예를 들어, 삼성전자의 의사결정자가 '우리는 반도체 사업에 사활을 걸겠습니다'라고 말한다면, 똑같은 사업을 하더라도 스타트업의 의사결정자는 '우리는 전자사전 업체가 사용할 수 있는, 기존 메모리칩보다 20배 빠르고 2배 싼 메모리칩을 만듭시다'라고 말한다. 이는 스타트업이 대기업의 소규모팀과 매우 유사하게 생각하고 움직인다는 것을 뜻한다. 대기업의 제품개발팀은 작은 승부에서 승리하거나 실패하거나 결론적으로 생존에는 큰 지장이 없지만, 스타트업은 그 자체로 기업이기 때문에 작은 승리만으로는 살아남을 수 없다. 결국 큰 승리를 위해 작은 승리들이 필요한 것인데, 스타트업의 경우 작은 승리 다음의 시나리오가 매우 약하다. 무엇이 '작은 승리'인지 '큰 승리'인지 정확하게 정의할 수가 없는 것이 린스타트업의 약점인 것이다. '고객'에 따라 전략을 선회하기 때문에 창업자 스스로도 Next를 정확하게 예측하고 준비할 수 없는 것이다.이런 이유들 때문에 스타트업이 사업을 개발하고 계획함에 있어, '린스타트업'은 결코 단독으로 쓰일 수 없는 이론인 것이다. 그렇다면 왜, 린스타트업은 이렇게 선풍적인 인기를 끌었던 것일까?1. 무려 '실리콘밸리'에서 왔다.이미 미국 경영학계, 피터 틸 등 창업자들 사이에서 린스타트업에 대한 반론이 나오고 있는 상황이었지만,우리나라에서는 그 점에 크게 주목하지 않고 린스타트업 이론을 아무 비판 없이 수용했다. 지금도 린스타트업을 국내에서 반대하는 글을 쓴 사람을 찾기 어렵다. 2. 누구나 가르치기 쉽다.우리나라 사람들은 명확한 '답'이 있는 것을 좋아하고 그것을 필기하고 공부하는 것을 좋아한다.불확실한 것을 극도로 피하는 경향이 있는데, 린스타트업은 여기에 딱 맞는 사업 이론이다. 거기에, 린스타트업 책 몇 권 읽고 린 캔버스만 조금 공부하면 누구나 강사가 될 수 있고 책도 쓸 수 있다.편향 확증을 활용하면 모든 스타트업 성공사례에 린스타트업 이론을 적용할 수 있다. 롯데도 일본에서 껌 팔다가 대기업 됐으니, 껌으로 린스타트업한 회사다.3. 투자자금을 끌어들이는 데 유리하다.린스타트업 이론이 없었다면 사실 엔젤투자나 시드 투자가 이렇게 활성되기 어려웠을 것 같다. 린스타트업 이론이 퍼지면서 대부분 스타트업들이 최소한의 제품을 만들어 어느 정도 검증을 한 뒤 투자를 받았다. 투자자 입장에선 린스타트업이라는 게 아주 좋은 이론이라고 생각한다. 초기기업의 마일스톤을 측정할 수 있는 지표가 만들어지기 때문에, 투자자 입장에선 아주 좋은 것 같다.4. 대부분 스타트업에 만능으로 써먹을 수 있다.보통 사업전략이라면 분야마다 다르고, 활용방식도 제각각인데 린스타트업은 어떤 사업에도 적용할 수 있는 이론이다. 모든 사업이 '고객'을 갖고 있기 때문이다. 이 때문에, 다양한 경영사례나 더 광범위한 고객, 시장분석 없이도 매우 적은 범위의 타깃 고객을 대상으로 한 린스타트업 실험만으로도 사업을 시작해볼 수 있다. 거기에 대한 위험성은 위에 언급한 것과 같다.5. 창업자 마음에 위안을 주고, 용기를 준다.창업자로서 가만히 앉아서 생각만 하고 있으면 자괴감이 든다. 뭔가 발로 뛰고 땀 흘리면 더 값진 하루를 보낸 기분이 드는 것도 사실이다. 그리고, 발로 뛰면 당연히 그만큼 피드백 또는 인사이트를 얻는 것이 있다. 린스타트업은 '결론적인 승리'를 위한 것이라기보다는 '효율성'에 초점이 맞춰져 있다. 어차피 대부분의 스타트업이 실패할 거라면 발로 뛰면서 작은 승리라도 쟁취하라는 것이 핵심인 것이다. 린스타트업을 충실히 따르다 보면, 천천히 검증되가는 내 가설을 트렐로의 'Doing'에서 'Done'으로 옮기는 쾌감을 얻을 수 있다. 그리고 열심히 하루 종일 고객들을 만나며 인터뷰한 것을 보며 더 정상에 다다르고 있다는 생각이 들게 만든다. 린스타트업은 창업자에게 정서적으로 좋다. 성취감을 주기 때문이다.린스타트업은 스타트업이 반드시 공부하고 연구해야 할 이론이라고 생각한다. 하지만, 이것 단독으로는 답을 찾을 수 없다고 생각하며, 추가적으로 활용하는 툴 정도로 사용해야 한다고 본다. 린스타트업으로 얻는 작은 승리 또는 성취감 등이 확률적으로는 '큰 승리'에 기여할 확률이 클지도 모르지만, 역으로 '큰 승리'가 '작은 승리'의 합으로 이뤄지냐고 묻는다면, 그렇지는 않은 것 같다. '큰 승리'를 먼저 정의하는 것이 선행되어야 할 것이라고 본다.린스타트업에서 말하는 '가설', '검증', '학습'에는 약점이 분명히 존재한다. 여기에는 '타이밍'이라는 중요한 사업의 성공요인이 배제된다. '타이밍'이라는 것이 '시간의 흐름을 특정 구간에서 절단한 단면'이라면, 우리는 그 '흐름'에도 몸을 실어서 완전히 이입한 상태가 되어야 하지 않을까?그리고 그러한 완전한 이입상태에서 내린 결론이 '사업전략'이 되고 '큰 승리'로 정의될 것이다. 이것은 사업에 대한 '당위성'이 되기도 하며, 이것은 가설이 아니라 목표이자 비전 그 자체가 된다. 그 아랫단에 존재하는 것들은 실험하고 검증하는 것은 필요할 지 모르나, 이것은 실험 대상이 아닌 것이다. '부자가 되려면 부자인 친구 옆에서 살라'고 누가 그랬다. 이게 전통적인 대기업 방식의 사업전략이다.결론은 무조건 부자가 되겠다는 것이다.린스타트업을 여기에 적용하면 '부자가 되기엔 아직 넌 서민이니까 1,000만 원을 모을 수 있는지 먼저 실험해보자'라고 하는 것과 같다. 그다음 가설은 '3000만 원'이다. 이렇게 단계적으로 실험하는 것이 부자가 되는데 큰 영향을 주는지에 대해선 미지수다. 그리고 이러한 가설과 실험에는 '부자가 되지 못할 지도 모른다' 또는 '돈을 모으다 보면 다른 결론에 도달할 지도 모른다'는 모호성이 담겨있다.'반드시 해내야 된다'라고 고집스럽게 정의된 '큰 승리' 없이는 '큰 기업'이 될 수 없다는 것이 나의 결론이다.성공한 사업들과 사업가들의 이야기를 듣고 연구하다 보면, 거기에 너무 다양한 패턴이 있어 이것을 무언가로 명확하게 정의 내릴 수 없다는 생각이 들었다. 결론은 명확하게 정의 내릴 수 있는 답이 없는 것 같다. 너무 많은 요인이 작용한다. 그런데, 답이 있다고 생각하고 몰입하다 보면 무언가를 반드시 놓친다는 것이다. 기민하고 유연하게 전략을 계속해서 수정하는 작업이 필요하겠다.

개발과 운영을 함께 devops - 출처당분간의 일기 내용앞으로 몇 개월 간 신생 스타트업 I/O가 어떻게 devops를 자기네만의 스타일로 조직에 안착시켜 나가는지 그 시행착오를 생생하게 공유하는 일기를 쓰려고 합니다.첫 번 째 편인 오늘의 이야기는 두 가지 내용을 다룹니다.devops 도입배경: 어떻게 하다가 devops를 도입하기로 했는지 그 배경에 대에서 이야기 합니다.devops 필요성 인지: 가장 먼저 소프트웨어팀이 devops 필요성을 느끼도록 시도한 스터디 세미나에 관한 이야기를 합니다.devops 도입 도중에 실패할 수 있습니다. 그래서 1편이 마지막 연재일 수 있습니다. 혹은 온갖 개고생을 해가면서 결국 devops를 성공적으로 조직에 안착시켜 tech기업다운 모습을 갖출 수 도 있습니다. 정답은 시간이 얼마간 흐른 뒤에야 알 수 있겠죠? 무언가를 조직에 도입하는 스토리를 사후적으로 그러니까 프로젝트가 끝난 후에 쓰게된다면 프로젝트 과정의 생생함이 퇴색됩니다. 힘들었던 추억도 되돌아보면 미화되듯이 그 당시에 골치아팠던 일들을 그 당시에 써놓지 않으면 까먹을 때가 꽤나 많습니다. 한 편으로는 이렇게 칼자루를 뽑아놔야 반드시 devops를 성공시키기 위해 제가 더 처절해질 수 있을 것 같습니다. 제 나약한 마음이 바뀌지 않기 위해 devops 시작과 동시에 연재물도 함께 시작하겠습니다.devops 도입배경스위처 M 앱이 출시된지 약 한 달 정도 되었습니다.경영을 해오면서 항상 위기의식을 느끼고 있지만 이번에는 조금 심상치 않았습니다.“아.. 라이브서비스를 하기엔 현재 I/O의 소프트웨어 역량이 심각하게 부족하구나! 하드웨어 역량이 Critical Path일 줄 알았는데 되려 소프트웨어가 우리의 발목을 잡고 있구나..”그동안 하드웨어 멤버들은 초심자의 마음과 책임감을 동시에 갖고 무서운 속도로 성장해왔습니다. 새로운 버전의 스위처(M)에 적용된 기구설계 수준, Supply chain 관리 능력, 블루투스 모듈 성능은 이전 버전(W) 비할바가 안됩니다. 놀랄만큼 일취월장 했습니다. 단적인 예로 현재 스위처M의 블루투스 연결 거리는 오픈필드에서 70m이상 나옵니다. 이전 세대인 스위처W의 연결거리가 약 20m 미만임을 감안하면 연결성이 300%이상 좋아졌다고 볼 수 있습니다.반면 소프트웨어팀은 여전히 초보적인 수준을 벗어나지 못하고 있습니다. 전공분야라는 자만심에 소프트웨어를 밑도 끝도 없는 구렁텅이에 밀쳐 넣고있는 제 자신을 발견 했습니다. 창피했습니다. 가장 중요하다고 볼 수 있는 초기고객으로부터 어처구니없는 버그 리포팅을 받을때면 쥐구멍으로라도 숨고 싶었습니다. Customer Service역할까지 도맡아하는 마케터가 수 많은 컴플레인을 대응하느라 정말 고생이 많았습니다.심각한 문제는 소프트웨어팀이 문제의 원인이 무엇인지 조차 잘 모르고 있다는 사실이었습니다. 그저 열심히 다음 피쳐를 개발하기 위해 코드를 짜내는 데에만 자신을 몰아붙이고 있었습니다.그 모습은 한 편의 코메디 영화를 보는 것 같았습니다.<디버깅루프>(1) 배포한 기능에 버그가 처음으로 발견됩니다.(2) “엇 이상한데? 그럴리가 없는데?” 일단 현실을 부정하고 지켜봅니다.(3) 한 두 명의 문제가 아니라는 버그리포팅이 들어옵니다.(4) 부랴부랴 원인을 추측하고 핫픽스 코드를 짜기 시작합니다.(5) 개발을 마치고 일단 배포해 봅니다.(6) 그런데 해결될 줄알 았던 버그가 다시 보고됩니다.그렇게 상황은 2번으로 돌아가 이 디버깅루프를 몇 바퀴 돌고난 후에야 잠잠해집니다.하하… 개판이구나 — 출처:구글 이미지 검색허나 이미 많은 고객들이 불쾌한 UX를 겪고 난 뒤… 이대로는 도저히 구상하는 I/O의 큰 그림에 도달할 수 있을 것 같지 않아, 당분간 제가 CTO역할을 도맡아서 하려고 합니다. 벤 호로위츠가 쓴 Hardthing에서 C-level의 포지션이 비어있을 경우 진짜 적임자가 나타나기 전까지는 그 역할을 CEO가 직접 수행하기를 권장합니다. 이제까지 바쁘다는 핑계로 조직 부채, 기술 부채를 안고왔었는데 최근 Event3 사고를 겪으면서 이젠 이 부채들을 털어내고 나아가야 겠구나 결심하게 되었습니다. 직접 현장으로 다이빙해서 소프트웨어 엔지니어들과 함께 악전고투하기로 했습니다.린스타트업에서 말하는 5-why기법을 적용해보니. 근본적인 원인은 이것이였습니다.주먹구구식으로 Product Live service가 운영(operation)된다.엔지니어들의 코드 퀄리티가 낮아서가 아니었습니다. 알고리즘을 몰라서가 아니었습니다. 디자인 패턴을 몰라서도, 함수형 패러다임을 이해하지 못해서도, 동시성 문제를 몰라서도가 아니었습니다. 되려 I/O의 소프트웨어 엔지니어들의 CS 기본기는 나쁘지 않습니다. 저희는 엉클밥, 켄트백, 마틴파울러를 존경합니다.바보야, 문제는 코딩이 아니야!문제는 경제가 아니야, 바보야!저희 팀의 제일 큰 문제점은 그냥 예전 처럼 새로운 feature 코드를 찍어내는일이 Product Live service operation의 전부라는 사고방식입니다. 배포되는 코드가 얼마나 신뢰할만한지에 대한 고민은 전혀 없고 밀어내기식으로 다음 기능을 추가하는 데만 몰두했습니다. 실상 지금의 스위처에는 새로운 기능을 추가하기위해 코딩을 할때가 아니었는데 말이죠. 쿼리 속도를 높이기 위해 인덱싱을 고민 할 때가 아닌데 말입니다. 정작 Product Live service operation에 필요한 일들(tasks)을 수행하고 있지 않았기 때문에 이 문제가 발생한건데 말이죠.린스타트업의 MVP 관점을 포기하고 완벽한 제품을 내보낸다는 의미가 아닙니다. 그 Minimum Viable Product 조차 제대로 작동이 못시키는 문제를 바로잡기 위해서 입니다. 스크럼으로 조직 tasks를 관리해왔지만 소프트웨어팀은 devops로 거듭나야할 때가 왔음을 느꼈습니다.최소한의 검증 절차도 없이 버그가 담긴 소프트웨어가 고스란히 고객에게 전달되는 악몽을 더 이상 마주해선 안됩니다. 불편함을 겪는 고객을 위해서라도 경쟁력을 잃어가는 조직을 위해서라도 곁에서 힘들어하는 동료들을 위해서라도 소프트웨어팀은 변해야만 했습니다.devops 필요성 인지멤버들에게 제가 방금까지 이야기한 문제점을 전달하고 각자 devops가 무엇인지 공부하기로 했습니다. 일주일간 리서치를 마친 후 한 명씩 돌아가면서 devops가 무엇인지 발표하는 세미나를 진행했습니다. 결론부터 말해 devops 필요성에 대한 공감대 형성은 성공적으로 첫 걸음을 뗀듯 합니다. 모두들 세미나를 준비하면서 그동안 무엇이 문제인지 조차 모르는 상황은 벗어나 보였습니다. 한 명쯤은 “devops는 필요없습니다. 지금처럼 해도돼요!”라는 반응을 예상하기도 했는데, 모두가 겸손의 자세로 지금까지의 문제를 반성하고 변화의 필요성을 절감했습니다. 끊임없이 성장하려는 자세를 가진 I/O 멤버들에게 참 고맙습니다.우린 여기에서 어디쯤..?펌웨어 개발자는 우리의 현재 모습이 위의 그림에서 나오는 원숭이조차 안되는 것 같다고 고백 하기도 했습니다. 그만큼 I/O 소프트웨어팀은 변화를 갈망하는 단계로 무사히 넘어왔습니다. 성공적으로 devops의 필요성 공감대를 형성 시킬 수 있었던 요인은 slow-start 덕분인듯합니다. 초기 고객분들이 실험대상이 된것 처럼 말해 죄송하지만, 작은 규모로라도 Live를 진행하고 거기서 작게나마 사고를 치도록 내버려둔 환경이 devops의 필요성을 받아들이는 데 큰 역할을 했습니다.만약 처음부터 무리해서 스케일업을 시도했다면 그래서 감당할 수 없는 수준의 사고가 동시다발적으로 터졌다면 저희는 자멸하고 말았을 겁니다. 아니, 기다리는 많은 고객들의 기대감에 지레 겁먹고 최대한 소프트웨어 출시 일정을 늦췄겠죠. 그리고 그렇게 절벽에서 등 떠밀리듯이 제품을 출시해서 줄을 잇는 버그 리포팅을 받아보며 평정심을 잃고 말았을 것입니다. 그러나, 감당할 수 있는 수준으로 제품 판매수량을 조절했기 때문에 개발자가 문제를 직시해볼 기회를 가졌고 devops의 필요성은 조직에 쉽게 받아들여질 수 있었습니다.물론 devops 세미나를 진행하면서 안좋은 냄새(징조)를 맡기도 했습니다. 저에게는 행운이죠. 사전에 미리 문제를 파악할 수 있어서. 그 냄새는 도구만능주의 였습니다. devops 도달하기 위해서는 시중에 존재하는 다양한 tool들을 최대한 빠르게 도입해야 할것만 같은 느낌을 말합니다. devops tool들만 제대로 구축한다면 devops도 저절도 실현될것 같은 기대감에 젖습니다. 이 도구만능주의가 만연해지면 devops의 본질은 보지 못한 채 최신 tool 사용에만 집착하게되는 오류를 범하고 맙니다.다행이 I/O의 도구만능주의는 심각한 수준까진 아니고 누구나 초기에 충분히 실수할 수 있는 미약한 수준이었습니다. 사실 제가 예전 스타트업에서 스크럼을 도입할 때도 빠졌던 도구만능주의가 묘하게 겹쳐보여서 낌새를 비교적 빠르게 눈치 챌 수 있었습니다.출처 : 구글 이미지 검색devop는 문화와 운동(movement)입니다. 즉, 무형에 가까운 개념입니다. tool이 아니라 행위(action)와 사상(idea)에 역점을 둬야 합니다. tool은 그저 거들 뿐이죠.간단한 사고실험을 해보겠습니다. 모든 microservices의 설정들을 chef와 puppet으로 관리하고 뱀부나 젠킨스로 빌드-배포-리포팅 파이프라인까지 구축한 devops팀이 있다고 가정해 보겠습니다. 달리 말해, 이 팀은 커맨드 입력 한 번으로 방금 짠 코드를 고객에게 배포할 수 있습니다. 어느날 이 팀에 속한 개발자 A가 지난 일주일간 개발해온 피쳐를 지금 막 마무리 지었습니다. 이어서 A는 devops tool로 구축한 배포 파이프라인 이용해 아주 간단하게 새로운 기능을 업데이트 하기로 했는데요. 과연 괜찮을까요? 최신 devops tool로 중무장 했으니 문제가 없을 것 같습니다. 잠시 후 그렇게 배포된 기능을 써본 고객들이 컴플레인을 걸어옵니다. 잠시 화장실을 다녀온 엔지니어는 허겁지겁 hotfix 코드를 다시 짭니다. 그래도 괜찮습니다. A가 속한 팀은 최신 devops tool이 구축되어 있기 때문에 금방 hotfix를 재배포할 수 있으니까요. 그런데 이장면 어디서 익숙하지 않나요? 앞에서 소개한 디버깅루프와 비슷해 보입니다.출처 : 구글 이미지 검색과연 이게 devops일까요? tool들을 전부 사용하는게 진정 devops의 실현일까요?코드를 리뷰하지도 자동화된 테스트 코드를 실행해보지도 않은 상태에서 지속적 배포는 그저 똥을 더 자주 고객에게 전달하는 것과 다르지 않습니다.높은 품질의 제품은 보장할 수 없습니다. 그렇다면 우리는 무엇부터 해야할까요?Next Iteration저는 장황한 계획을 혐오합니다. 계획을 짜내느라 쏟는 에너지와 시간이 너무 아깝고 무엇보다 계획대로 진행될 확률이 낮기 때문입니다. 대신 저는 스타트업 환경에 맞는 방식으로 일하기를 선호 합니다. 비교적 긴 시간이 필요한 프로젝트 성격의 일을 할 땐 북극성의 위치만을 기억합니다. 쉽게 말해 우리가 산출해야하는 프로젝트 결과물만 생각합니다. 북극성까지 도달하는 정해진 길 따위는 없다고 가정합니다. 혹시 있었다 해도 그냥 잊어버립니다. 스타트업의 리스크는 워낙 변화무쌍하거든요.계획 대신 무던히 아래 두 가지 행동을 반복합니다.(1) 고개를 들어 몸이 북극성 향하도록 합니다.(2) 고개를 숙여 한 발짝 전진합니다.출처 : 구글 이미지 검색프로젝트가 끝날 때 까지 위의 두 가지 과정만을 반복하려고 합니다. 저는 이 과정을 baby step이라고 하는데요. 욕심내지 않고 작게 작게 한 번에 하나씩 차근차근 진행하는 방식입니다. 지금 내 딛은 한 걸음이 틀릴 수도 있습니다. 그러나 괜찮습니다. 한 걸음 나아간 다음에는 반드시 고개를 들어 내가 북극성과 가까워졌나 멀어졌나 확인하면 되거든요. 방향이 맞다는 판단이 서면 한 걸음 더 나아가고 틀린 예감이들면 방향을 조절하면됩니다. 만약 판단이 애매하면 더 끌리는 쪽을 택하면 됩니다. 단, 절대 바닥만을 주시한채 두 걸음 이상 걷지 않습니다.devops까지 도달하는 데 지름길은 전혀모릅니다. 하지만, devops라는 북극성은 저에게 명료하고 분명한 목표입니다. devops에 조금이라도 가까워지기 위해 지금 당장 해야하는 가장 중요한 일이 무엇인지 세미나를 진행하면서 그리고 세미나를 돌아보면서 치열하게 고민했습니다. 그렇게 집중하고나니 당장해야 하는 일 3가지는 다음과 같았습니다.(1)코드리뷰(2)테스트코드 작성(3)이슈 관리 프로세스이 세 가지의 일이 정답이 아닐 수 있습니다. 정답인지 아닌지는 얼마간 시간이 흐른 후에야 알 수 있겠죠? 다만, 저희는 늘 저희가 하던 방식대로 용기를 갖고 baby step을 무던히 수행해 나갈 것입니다. 다음화는 위의 세 가지 일을 진행하면서 겪은 시행착오를 공유해 보도록 하겠습니다.긴 글 읽어 주셔서 고맙습니다.#스위쳐 #Switcher #DevOPS #데브옵스 #개발자 #개발 #개발문화 #디버깅 #버그수정 #인사이트

앞서 종합 모빌리티 플랫폼인 타다의 시스템 설계를 위한 많은 고민과 기술적 결정들에 대해서 서버팀에서 소개한 바 있습니다. 이번 글에서는 타다 서비스를 출시하기까지 타다 모바일 클라이언트를 개발하는 과정에서 내린 클라이언트 팀의 전략적 결정들과, 타다 클라이언트를 개발하는데 사용한 기술들을 공유합니다.시작 전 상황3달 반의 개발 기간: 타다는 VCNC가 SOCAR에 인수되면서 개발하게 된 서비스입니다. 빠르게 시장에 뛰어들어서 선점하는 것이 무엇보다 중요했기에 시간과의 싸움은 필수적이었습니다. 프로젝트는 6월에 시작되었고 1.0 출시는 추석 연휴 직전인 9월 중순으로 결정되었습니다. VCNC에서 오프라인 운영은 처음이었기 때문에 차량을 실제로 운행해보면서 사용성 경험을 테스트할 필요가 있었습니다. 그래서 8월 초에 사내 테스트용 알파 버전을 출시하기로 했습니다.클라이언트 팀 통합: 비트윈 때는 Android/iOS 팀이 나뉘어 있었습니다. 회사 인수 과정에서 발생한 조직 개편으로 인해 타다 클라이언트 개발자는 5명으로 이루어졌습니다. 전부터 다른 OS 개발도 경험하고 싶던 적극적이고 열정적인 5명의 멤버들은 과감하게 팀을 통합해서 Android/iOS을 함께 개발하기로 했습니다.3개의 앱 개발: 타다의 서비스를 위해서는 Android/iOS, 라이더/드라이버 총 4개의 앱을 제작해야 합니다. 하지만 시간과 일정을 고려했을 때 4개의 앱을 다 제작하기는 무리라고 판단을 했습니다. iOS에서는 내비게이션 앱을 사용 중에 드라이버 앱으로 손쉽게 전환하는 기능을 제공할 수 없고 내비게이션 앱으로 경로 안내를 요청하는 것도 제한적이기 때문에 iOS 드라이버 앱은 제작하지 않기로 했습니다.무에서 시작한 프로젝트: 타다는 코드 베이스가 없는 empty repository에서 시작했습니다. 언어도 바뀌었고 레거시 코드와도 엮이고 싶지 않았기 때문에 비트윈에서 어떠한 라이브러리도 가져오지 않고 전부 새로 만들기로 했습니다.클라이언트 팀의 5명의 정예 용사들. by Sam코드 아키텍처 - RIBs프로젝트가 시작되고 기획이 진행되는 동안 3주의 시간을 기반 작업에 쓰기로 했습니다. 가장 먼저 진행한 것은 코드 아키텍처 정하기입니다. 당시에 제가 SAA(Single-Activity Application)에 관심을 가지고 있었는데, 때마침 Google I/O 2018의 세션 중 Modern Android development: Android Jetpack, Kotlin, and more 에서도 비슷한 언급이 나와서 팀에 제안했고, 본격적으로 조사를 해보았습니다. 팀원들이 조사를 진행해보니 Uber, Lyft, Grab 등 굴지의 모빌리티 서비스 회사들이 전부 SAA 기반으로 앱을 개발했다는 것을 알게 되었습니다. 무거운 리소스인 지도를 중심으로 화면이 구성되기에 반복적인 지도 리소스 할당/해제를 피하기 위한 필연적인 선택으로 보입니다. 큰 기업들이 수년간 서비스를 하며 문제를 느끼고 내린 선택인 만큼 저희도 따라가기로 결정했습니다. 비트윈 때 Activity Stack으로 인해 굉장히 고통을 겪은 적이 있는지라 SAA를 원하는 공감대도 있었고요.SAA로 개발을 하기로 정한 이후에는 어떤 프레임워크를 사용해서 개발할지를 고민했습니다. 여러 개의 오픈소스를 비교할 때 Android/iOS 간의 통일된 아키텍처로 개발할 수 있는지를 가장 중점적으로 보았습니다. 대부분의 팀원이 한쪽 OS에만 익숙하기 때문에 초보임에도 빠르게 적응하고 개발하려면 비즈니스 로직을 구현하는 부분이 통일되어 있어야 한다고 생각했습니다. Uber의 RIBs는 저희의 이런 요구를 가장 잘 충족했습니다. 거기에 데이터의 scope와 전달 방식 명확해서 side-effect 없이 개발할 수 있다는 점, 그로 인해 효율적으로 협업이 가능하고 여러명이 개발한 RIB 을 레고 조립하듯 합쳐서 기능을 완성할 수 있다는 점에서 RIBs를 선택하게 되었습니다.RIBs는 아키텍처를 이해하는 것 자체가 굉장히 난해합니다. 오픈소스 상으로 공개가 되지 않은 부분들도 있어서 저희의 입맛에 맞게 변형하는 데 매우 많은 시간을 할애했습니다. RIBs와 관련한 내용은 Nate(김남현)가 Let'Swift 2018에서 발표한 RxRIBs, Multiplatform architecture with Rx 의 영상 및 발표자료를 참조하세요.추후 RIBs를 상세하게 다루는 포스팅을 해보도록 하겠습니다.서버와의 통신 프로토콜새로운 서버 API가 생길 때마다 해당 API의 명세를 문서화하고 전달하는 것은 굉장히 불편한 일입니다. 또한 문서를 작성할 때나 클라이언트에서 모델 클래스를 생성할 때 오타가 발생할 수도 있습니다. 타다에서는 서버 클라이언트 간 API 규약을 Protocol Buffer를 사용해서 단일화된 방법으로 정의하고 자동화하기로 했습니다. 모든 API의 url은 .proto 파일 이름으로 정형화되어 있고 POST body로 Params 객체를 JSON으로 serialization 해서 보내면 Result JSON이 응답으로 옵니다. 서버가 새로운 API를 개발할 때 .proto 파일만 push 하면 클라이언트에서 스크립트를 돌려서 Model 객체를 생성하고 해당 객체를 사용해서 호출만 하면 되는 아주 간단하고 편한 방식입니다.참고로 타다의 서버군에 대한 설명은 타다 시스템 아키텍처에 기술되어 있습니다.기반 작업타다는 빈 repository에서 시작한 깔끔한 프로젝트였기 때문에 Base 코드와 내부 라이브러리들을 전부 새로 개발했습니다.API Controller, gRPC Controller서버와의 통신에 필요한 모듈들을 개발했습니다. 모든 API는 Rx의 Single과 Completable로 wrapping 되어 있습니다.RIBs가장 자주 사용하는 Router 패턴들을 wrapping.Android에서 구현이 공개되어 있지 않은 ScreenStack 구현.SAA이므로 Android에서 Activity가 아닌 화면 단위의 로깅을 구현.Router의 기초적인 화면 Transition을 구현RIB 뼈대 코드용 template 파일 제작Prefs(Android)/Store(iOS)타다에서는 DB를 사용하지 않고 key-value store로만 데이터를 저장합니다. Android SharedPreference와 iOS UserDefaults의 wrapper를 만들었습니다. Object를 serialization 해서 저장하는 기능, Rx 형태의 getter, cache layer, crypto layer 등이 구현되어 있습니다.Design SupportAndroid에서 drawable을 생성하지 않고 layout.xml 상에서 border, corner-radius, masking을 쉽게 설정하기 위해서 제작했습니다.ButterKtAndroid에서 View Binding 처리를 위해 개발했습니다. 비슷한 기능을 하는 Kotter Knife, Kotlin Android Extension이 가지고 있는 lazy binding 문제를 해결하고 싶었고 가능하면 Butter Knife와 달리 apt 없이 동작하는 라이브러리를 만들고 싶었습니다. 이와 관련된 저희의 생각은 여기에 David(김진형)이 상세하게 기록해 두었습니다. 코드도 공개되어 있으니 잘 활용해 보시길 바랍니다.ToolsModel CompilerPBAndK, swift-protobuf를 수정해 .proto 파일을 저희가 원하는 형태의 kotlin data class와 swift codable struct로 변환하는 스크립트를 구현했습니다.Import ResourceUI/UX 팀에서 작업해서 Google Drive File Stream으로 공유하는 리소스를 프로젝트에 sync 하는 스크립트입니다. 타다에서는 기본적으로 벡터 포맷(Android xml, iOS pdf)을 사용하고 Android에서 벡터로 표현이 안되는 이미지들은 png를 사용합니다. 또한 애니메이션을 위한 Lottie json 파일도 사용합니다. 현재는 Android 용으로만 스크립트가 구현되어 있고 리소스를 프로젝트 내의 각각의 res 폴더에 sync 하는 기능과 svg로 전달받은 벡터 파일을 Android xml 형식으로 변환하는 기능을 포함합니다.sync Lokalise타다에서는 Lokalise로 문자열 리소스를 관리합니다. strings.xml, Localizable.strings 파일로 다운받아서 프로젝트에 sync 하는 스크립트 입니다.Code Template & Settings개발 편의를 위한 간단한 Android Studio Code Template과 코드 통일성을 위한 idea settings를 공유합니다.사용된 기술들OS 공통Firebase: Analytics, Crashlytics, Messaging, Storage 등 다양한 용도로 Firebase를 활용하고 있습니다.gRPC, ProtoBuf: 서버에서 실시간 Event를 받기 위해서 사용합니다.RIBs: 타다의 기반 아키텍처 입니다.Lottie: 애니메이션 요소를 표현하기 위해 사용합니다.Semver: 앱의 버전은 Semantic Versioning 규약을 따라 정의합니다. 버전을 파싱하고 관리하기 위해서 Nate(김남현)가 Kotlin 버전과 Swift 버전의 라이브러리를 제작하고 공개했습니다.Braze: CRM(Customer Relationship Management) 툴인 Braze는 유저를 타게팅해서 전면팝업을 띄우거나 푸시 알림을 발송하기 위해 사용합니다.TeamCity, Fastlane, Beta: CI/CD를 위해서 개발 초기에는 Jenkins를 사용했습니다. 출시 대응을 빠르게 하기 위해서 parallel build 및 우선순위 컨트롤을 하고 싶었는데 Jenkins의 Parallel build가 원하는 대로 동작하지 않아서 현재는 TeamCity로 이전했습니다. Beta를 사용해서 모든 브랜치의 빌드를 배포해서 QA 팀에서 테스트할 수 있게 했습니다. 출시용 빌드는 Android의 경우 아직은 수동 업로드를 하고 있고 iOS의 경우 Fastlane으로 배포합니다.git-flow: Git branching model로는 git-flow를 사용합니다. Branch의 종류에 따라서 TeamCity에서의 빌드 우선순위가 결정됩니다.AndroidKotlin: 당연한 선택이겠죠? 타다의 모든 소스 코드는 Fork 해서 수정한 RIBs의 클래스들을 제외하면 전부 Kotlin으로 구현되어 있습니다.AndroidX: 타다 개발을 시작하는 순간에 AndroidX가 공개되었습니다. 기존 Support Library를 사용하게 되면 언젠가는 migration 해야 할 것이기 때문에 알파 버전임에도 불구하고 처음부터 사용하기로 했습니다. ConstraintLayout, PagingLibrary, Material Component, KTX 등 다양한 Component를 사용합니다.Retrofit, OkHttp: 서버와의 HTTP 통신을 위해서 사용합니다.RxJava: 클라이언트 팀은 Rx 없이는 개발할 수 없을 정도로 적극적으로 Rx를 활용합니다.AutoDispose: Rx subscription을 dispose 하기 위해서 사용합니다. 관련해서 도움이 될만한 글을 읽어보시는 것을 추천합니다. Why Not RxLifecycle?RxBinding: View 이벤트를 Observable 형태로 바꿔주는 RxBinding은 굉장히 유용합니다.Moshi: JSON 라이브러리입니다. Kotlin data class와의 호환을 위해서 Gson 대신 선택했습니다.Glide: 이미지 로딩을 위해서 사용합니다.Detekt: Kotlin을 위한 static code analyzer 입니다. Detekt의 extension을 통해 ktlint도 활용하고 있습니다.Dagger: RIBs는 Dependency injection을 기반으로 합니다. RIBs에선 어떠한 DI system이든 사용할 수 있게 Builder가 분리되어 있습니다. RIBs에서는 Dagger로 설명이 되어 있고 저희도 마찬가지로 Dagger를 사용합니다.ThreeTen Backport: Java8의 날짜 및 시간 라이브러리인 JSR-310의 Java SE6 & 7을 위한 backport 라이브러리입니다. 문자열 파싱 및 시간 연산을 위해 사용합니다.iOSSwift: Kotlin과 마찬가지로 당연한 선택입니다. Swift4.2의 CaseIterable Swift5의 Result 등 항상 최신 버전의 Swift를 사용합니다.RxSwift: 역시나 reactive programming은 필수입니다.RxCocoa, RxGesture: iOS에서도 역시 모든 뷰 이벤트는 Rx 형태로 감지합니다.SnapKit: AutoLayout DSL을 제공하므로 코드상에서 편하게 Constraint를 조절할 수 있습니다.Moya/RxSwift, Alamofire: Http 서버와의 통신을 위해 추상화된 네트워크 라이브러리인 Moya를 사용합니다. 역시나 Rx로 wrapping 된 버전을 사용하고 있습니다.Codable: Swift4부터 제공된 프로토콜로 JSON Encoding, Decoding으로 사용중입니다.Hero: RIBs의 Router가 attach/detach 될 때의 Transition을 처리하는데 이용합니다.Kingfisher: 이미지 로딩을 위해서 사용합니다.KeychainAccess: Access Token 같은 중요 정보를 안전하게 저장하기 위해 사용합니다.Swiftlint: SwiftLint는 fastlane action으로 실행해서 code validation을 합니다.출시 후의 회고짧은 시간에 여러 개의 앱을 만들기 위해서는 시간 및 인원을 아주 효율적으로 배분해야 했습니다. 각 OS의 기존 개발자들이 먼저 프로젝트 기반을 닦는 동안 나머지는 스터디를 진행했습니다. 차량 운영 경험을 쌓는 것이 알파 테스트의 목적이었으므로 일정에 맞추기 위해 드라이버 앱도 개발해야 하는 Android로만 알파 버전을 개발했습니다. 대신에 iOS 알파 버전은 서버팀 YB(김영범)가 아주 빠르게 웹앱으로 개발해주었습니다(1.0은 Native입니다.). 알파 버전의 스펙도 호출-하차까지의 시나리오 외의 다른 부가 기능은 전부 제외했습니다.회사 구성원들이 전부 처음 도전하는 분야였기에 기획을 포함해서 모두가 지속적인 변화에 대응해야 했습니다. 특히 사내 테스트를 시작한 직후 실제 운영을 해보며 깨닫고 변경한 기획 및 UX가 상당히 많았습니다. 개발적으로는 익숙하지 않은 아키텍처인 RIBs를 이해하며 개발하는 것이 생각 이상으로 난도가 높았고 개발하는 중간에도 큰 리팩터링을 여러 번 해야 해서 힘들었습니다. 이러한 이유들로 1.0 출시도 시작 전 상황에서 언급한 것보다 2주 정도 미뤄졌습니다.실제 타다 프로젝트 타임라인하지만 저희는 성공적으로 타다를 출시했습니다! 아래는 팀 내에서 출시를 회고하며 나왔던 몇몇 의견입니다.OS 간 아키텍처가 통일되어서 한 명이 같은 기능을 두 OS 전부 개발할 때 굉장히 효율적이다. 비즈니스 로직의 경우 정말로 Swift <-> Kotlin간 언어 번역을 하면 되는 정도.결과적으로 앱 개발 순서를 굉장히 잘 정했다. 한쪽을 먼저 빠르게 개발하고 문제점을 느껴보며 정비해 나가니까 프로젝트 후반부에 빠른 속도로 기능을 개발하는 데 도움이 되었다. 큰 수정을 양쪽 OS에 하지 않아도 됐던 게 좋았다.짧은 기간 개발했음에도 앱 퀄리티가 굉장히 만족스럽다. 매 상황에서 기술적 선택, 인원 배분 등 경험에서 우러나온 아주 적절한 판단들을 했다고 생각한다.각자 독립적으로 개발하던 기능들이 쉽게 합쳐지고 큰 문제없이 잘 동작하는 하나의 앱이 되는 과정이 정말 신기했다. 아키텍처 설계에 쓴 많은 시간이 결코 아깝지 않았다.마치며아직 저희가 하고 싶고 도전해야 하는 과제들은 무궁무진합니다. 그 중 간략히 몇 가지를 소개합니다.테스트 코드 작성: 시간과의 싸움 속에서 테스트 코드 작성을 지금까지 미뤄왔습니다. RIBs의 Interactor 에 구현된 비즈니스 로직은 반드시 테스트 되어야 합니다.OS 간 구조 통일: 같은 화면임에도 OS 간 작업자가 다른 경우 많은 파편화가 일어났습니다. 1순위로 RIB tree 및 Interactor의 비즈니스 로직 통일하는 작업을 진행하고 있습니다. AlertController 같은 공통적인 컴포넌트들도 최대한 포맷을 통일하려는 작업을 지속해서 진행할 예정입니다.iOS DI: RIBs에서 Android에선 Dagger를 활용해서 쉽게 Builder 구현이 가능하지만, iOS에서는 좋은 방법이 없어서 수동으로 DI를 해결하고 있었습니다. 그래서 Uber가 개발 중인 Needle을 적용하려고 관심 있게 보고 있습니다.네트워크 에러 handling 개선: 중첩돼서 뜨는 Alert를 해결하는 것, global 하게 에러를 처리하는 좋은 구조 찾기 등의 이슈가 있습니다.String Resource 관리: 개발하면서 생성하고 아직 Lokalise에 동기화하지 않은 리소스 키를 체크해서 빌드 오류를 발생시키려고 합니다. 또한 iOS에서 "some_key".localize 형태의 extension으로 번역을 코드상에서 불러오는데 key 값 오타가 나면 런타임에서만 오류를 알 수 있습니다. 따라서 String resource를 enum 형태로 관리하려고 합니다.그 외 50여 가지나 되는 팀원들이 하고 싶은 백로그 목록이 여러분을 기다리고 있습니다. 타다가 성공적으로 런칭할 수 있었던 것은 훌륭한 팀원들이 있었기 때문입니다. 앞으로 저희와 함께 좋은 서비스를 만들어 나갈 멋진 분들의 많은 관심 바랍니다.