Rewriting Cheezburger Saved My Life – Ben Huh
한동안 블로그 포스팅을 쉬었다. 여러가지 이유가 있었지만 일단 한번 멀어지니 다시 손이 잘 안가게 되는 것이 사실이라,억지로라도 글을 하나 써야겠다는 생각이 들었다. 기술적인 포스팅이나 생각을 정리하여 포스팅하는데는 시간이 걸리기에 복귀글(?)로 Cheezburger의 CEO인 Ben huh님의 기업가 정신 관련 포스팅을 번역해 보았다. 작년쯤 읽어야겠다고 생각하고 스크랩 해둔 글인데, 한동안 미루다 보니 방치되어 잊고 있다가 작업목록 정리중에 다시금 발견했다.
기업가들의 성공 스토리는 영웅담처럼 미화되기 마련이고, 어두운 면에 대한 언급은 거의 하지 않는다. 대부분 불굴의 의지와 영감과 실행력으로 모든것을 이겨내는 사람들로 묘사되지만, 실제로 발을 담궈보면 그렇게 간단히 치부하기에는 너무도 많은 어려움들이 있는 것이 사실이다. 많은 어려움 중에서도 정신적인 흔들림은 창업자를 궁지로 몰아넣는데, 비슷한 느낌을 느끼고 있던 차에 해당 글을 읽으며 많은 힐링이 되었다. 작년에 읽었다면 아무런 느낌이 없었을지도 모르겠건만 지금 이 글을 읽게 된 것이 어떤 운명이 아니었나 하는 생각도 하게 된다.
각설하고, 원문 번역은 다음과 같다.
제 이름은 벤 허, 엔터테인먼트 회사인 Cheezburger의 CEO이자 설립자입니다. 2007년에 회사를 시작해 고양이 사진들이 온라인 상에서 유명해지게 만들었습니다. 지금은 여러 유머 사이트를 운영 중입니다. 그리고 오늘 우리는 iOS 앱을 내놓았습니다. 이 순간이 매우 자랑스럽지만, 지금부터 할 이야기는 앱에 대한 이야기는 아닙니다.
저는 이 앱이 나오기까지의 모든 이야기를 여과하지 않고 말하려 합니다. 사람들을 즐겁게 하기 위해 디자인된 앱이고 개발과정도 특별하진 않지만, 저는 이 제품의 이야기가 기업가 정신에 대한 이야기가 될 것이라 믿습니다. 저에게는 앱을 내놓는 과정이 부활과도 같았습니다.
기업가들은 대부분 새로운 제품의 행복하고, 자랑스러운 면만을 공유합니다. 축하하는 동안은 정직할 때가 아니라는 듯이 내내 우리를 따라다니던 실패들은 제쳐둡니다. 모든 신제품에는 고통스러운 역사가 있는대도 말입니다.
Cheezburger는 2007년 제 아파트에서 ICHC를 시작으로 웹 사이트들을 사모으는 너저분한 원맨 스타트업으로 시작되었습니다. 몇 달 후 웹사이트 명단이 커지기 시작했고, 팀은 시애틀에 있는 작은 방으로 사무실을 옮겼습니다. 우리는 Know Your Meme나 FAIL Blog와 같은 meme 관련 웹사이트를 사거나, 만들어가며 확장했습니다.
우리는 유머 왕국을 완성할때까지 계속해서 확장하고 더해 나갔습니다. 우리는 lean 했지만 자원이 풍족했고, 새로운 아이디어를 테스팅 하는대도 뛰어났습니다. 우리는 빠르게 커졌습니다.
2011년 Cheezburger는 30만 달러라는 놀라운 자금을 첫번째 펀딩으로 유치하게 됩니다. 그 돈으로 Cheezburger는 가내수공업을 벗어나 미디어의 관심속에 엄청난 벤쳐 펀딩의 시기를 맞이하게 됩니다. 우리는 투자금을 제 비전에 따라 유치했습니다: 모든 사람이 그들의 유머감각을 뽑낼수 있는 곳을 만들자는 비전말입니다. 단순히 새로운 소재들을 뽑아내는 것이 아니라, 유저들이 재미있는 아이디어들을 불편 없이 표현할 수 있는 플랫폼을 운영해야 했습니다.
돈이 쏟아져 들어오며, 저는 길을 잃었습니다. 결국 저는 인생에서 3년의 시간과 수백만달러를 낭비했습니다.
오직 지난 4달이 우리가 실제 새로운 앱을 만들기 시작한 때입니다.
간단히 말해서, 우리는 우리가 뭘 하고 있는지 몰랐습니다. 우리는 수 년동안 광고를 유치하고, 티셔츠와 책을 팔고, 심지어 리얼리티쇼 까지 출현해 수익성이 있었습니다. 하지만 은행에 넣어둔 투자금은 우리에겐 새로운 것이었습니다. 더 중요하게는, 워드프레스 사이트를 만들고 인수하던 우리를 컨텐츠 플랫폼 회사로 변신시키는 것 또한 새로웠습니다. 우리는 인원을 3배로 늘렸습니다.
하지만 초기 투자자가 빠져나간 후, 우리의 30만 달러는 4만 달러가 되었습니다. 벤처캐피털 기준에는 적은 돈이지만 우리는 현금속에서 유영하는것 같이 느꼈습니다. 그러나 우리는 돈을 잃어가며, 당황하게 됩니다.
2011년의 과다 고용 몇달 후 저는 우리의 CTO와 이야기를 나눴습니다.
나: 우리 프로덕트 릴리즈 페이스는 어떤가요?
CTO: 인원 고용하느라 너무 바빠서, 아무것도 만들지 못하고 있습니다.
저는 할말이 없었습니다.
그때가 CEO가 강제로 끼어들어 직원들의 우선 순위를 바꿔놓을 순간이었습니다. 새로운 사람들을 고용하는 이유는 빠르게 변화하고 경쟁적인 환경에서 새로운 기능과 향상을 좀 더 빠르게 하기 위한 것이었습니다.
우리가 코드를 작성하지 않는다면, 우리는 수백달러를 모닥불에 던져놓는 셈이었죠. 항공사가 이렇게 말하는 것을 상상해 보십시오. “우리는 새로운 비행기를 사는데 너무 바빠서, 모든 비행편을 취소하기로 마음먹었습니다.”
끼어들어 중재하기보다, 저는 우리 팀을 위한 변명을 만들었습니다: 이익은 아직 적정 수준으로 상승하고 있었습니다. 머뭇거림은 일시적이었죠. 우리가 데려온 사람들은 우리를 다음 레벨로 데려다 줄 것입니다. 우리는 모두가 고용된 이후 한번에 따라잡을 생각이었죠.
2012년, 몇달의 지연 끝에 우리는 모든 사이트를 우리의 플랫폼으로 옮겼고, 유저들은 그것을 싫어했습니다.
유저들은 그들이 익숙하던 여러 기능들의 부재에 대해 불평하기 시작했습니다. 팀의 불일치는 점점 심화되었습니다. 톱 경영진들은 해고되거나 회사를 그만두었습니다. 제가 데려온 사람들은 저를 다음 레벨로 데려다 주지 못했습니다.
늦은 2012년 저는 새로운 CRO인 Amber Dunn을 AllRecipes로 부터 영입했습니다. 그녀는 재능이 있고, 함게 일하는 사람들로부터 존경받고 사랑받는 사람이었습니다.
그리고 그녀는 난소암을 가지고 있었습니다.
그녀의 암은 비밀이 아니었습니다. 저는 그녀가 정기적인 치료를 받으면서 암을 제어하며 정상적인 삶을 살고 있기에 고용했습니다. 그녀는 새로운 팀을 모으고 재조직하는데 도움이 되었습니다. Amber는 재미있는 이미지를 공유하고 리믹스하는 플랫폼 대신 미디어 회사를 세우는 전략을 세웠습니다. 그녀는 우리가 우리의 강점을 살리길 바랬습니다: 우리의 유저들은 충성스러웠고, 많은 트래픽을 가지고 있었으며, 수익과 투자로 인한 몇백만 달러를 가지고 있었습니다. 우리는 플랫폼 대신 재미있는 사이트를 구성하여 그들에게 광고를 파는데 집중해야 했습니다.
Amber의 제안을 들었을때, 유머 플랫폼을 만드려는 이미 망쳐버린 기회에 대한 생각이 떠올랐습니다. 아마 내가 틀렸을지도 모르겠구나. 그래서 저는 그녀의 아이디어를 받아들였습니다. 저는 이런 변화에 대해 이사진을 설득하기도 했습니다.
누구나 코미디 마스터가 될 수 있는 곳을 만드려던 제 꿈은 미뤄둬야만 했습니다.
우리는 2013년 높은 기대와 함께 시작했습니다. 우리는 경험있는 미디어인 몇몇을 고용했습니다. 우리는 일류 세일즈 팀을 여러 도시에 세웠습니다. 우리는 계획적으로 투자모드로 돌아섰습니다.
그때 Amber가 병원에 실려갔습니다. 그녀의 암이 좀 더 심해져 있었습니다. 회사는 혼돈에 빠져들었습니다. 저는 충분한 에너지와 열정과 제품 아이디어가 있었으나, 나머지 반 – 어떻게 미디어 전략을 세우고 광고를 팔지 – 은 알지 못했습니다. 4월, 우리는 병원에 있는 Amber를 포함한 회사의 1/3을 해고했습니다. 우리는 그녀가 나갈때 기분이 상하지 않도록 신경썼습니다. 하지만 그 어떤것도 병원에 있는 말기 암환자인 한 아이의 엄마를 해고했다는 사실을 기분좋게 할 수는 없었습니다.
Amber Dunn은 남편과 어린 딸을 남겨두고 몇 달 후에 임종을 맞이했습니다. 때때로 저는 그녀의 삶을 단축시킨대 책임이 있는지 생각하곤 합니다.
Cheezburger 이야기는 거기서 끝날수도 있었습니다. 해고 이후 재능있는 직원들이 회사를 떠났습니다. 하지만 감사하게도, 많은 직원들이 남았습니다. 사기는 끔찍했고, 저는 비참했습니다. 투자자 중 한명인 Brad Feld의 재촉에 따라 CEO 코치를 만나기 시작했습니다.
코치들은 당신의 기분을 낫게 만들지는 못합니다. 그건 그들의 일이 아닙니다. 그들은 당신을 좀 더 잘 볼 수 있게 해줍니다. 모든 것을 망쳐버렸다고 느껴지고 그것을 크게 외치는 것 말고는 다른 대안이 없을 때 말입니다. 저는 제 코치인 뉴욕에 있는 Jerry Colonna의 소파에 앉아, 처음으로 나 자신과 다른 사람에게 자신의 깊은 공포를 인정했습니다.
“뭘 해야 될지 모르겠습니다.”
“아마도 제 회사에 알맞은 CEO는 제가 아닌것 같습니다.”
“제가 Amber를 죽였는지도 모르겠습니다.”
공포를 이해하기 위해 저는 공포를 받아들이고, 공포가 저를 삼키게 두었습니다.
저는 제가 상실속에 빠져있다는 것을 깨달았습니다. – 나의 플랫폼을 갖겠다는 실패한 시도에 대한 후회, 투자자들의 돈을 낭비한 것에 대한 죄책감, Amber의 쇠락에 일조했다는 불안감. 저는 제 회사를 객관적으로 보는 것에 어려움을 겪고 있었습니다.
그리고 회사안에서 어떤 일이 벌어졌던간에 아직 수백만의 사람들이 우릴 사랑한다는 사실은 바뀌지 않았다는 것을 깨닫기 시작했습니다. 우리는 세계 여러곳의 사람들을 행복하게 만드는 것을 계속하기 시작했습니다. 제 방향상실은 일시적인 퇴보였을 뿐이었습니다. 하지만 그것을 일시적으로 두기 위해선 의기소침해질 수 없었습니다. 저는 실망감을 이겨내야 했습니다.
2001년 첫번째 스타트업이 실패했을때, 저는 우울증과 자살에 대한 생각들과 싸워야 했습니다. 2013년 여러가지 상황들이 나빠 보였지만, 저는 전과 같이 어둡고 도움받을 수 없는 상황으로 돌아가지 않기로 자신과 약속했습니다. 많은 기업가들에게 삶과 비즈니스는 같은 것입니다 – 이는 자아를 파괴하는 위험입니다. 당신이 정말 당신과 당신의 비즈니스가 하나이고, 비즈니스의 실패가 당신을 파괴하고 성공이 끝없는 보상을 준다고 믿는다면 말이죠. 하지만 어떠한 결과도 그런 희생을 보증하지 못합니다.
저는 제 실패를 껴안으며 저의 두 정체성을 떼어놓기 시작했습니다. 저는 해고에 대해 공개적으로 토론했습니다. 공개적인 실패는 당황과 고립을 동반합니다. 당신은 부정적인 흐름의 타겟이 됩니다.
지인이나 타인들은 당신을 괴짜, 사기꾼, 날강도와 같이 부릅니다. 당신은 모든 세계의 경제적, 사기 저하, 사회적 잘못에 대한 희생양이 됩니다.
한번 공개적으로 실패를 밝히고 나면, 당신은 하나의 선택만 남게됩니다: 나아가는 것입니다. 저는 사직하는 것을 고려했으나 그러지 않기로 했습니다. 제 잘못을 바로잡고 버텨내는 것이 제 직원들과 투자자들에게 할 수 있는 최소한이라 생각했습니다.
세번째로 새로운 팀을 조직했습니다. 저는 Cheezburger를 플랫폼으로 만들어 모든 사람들이 유머감각을 펼칠 수 있는 곳을 만드려고 하는 초기 아이디어로 돌아갔습니다. 2013년 8월, Scott Moore를 사장겸 COO로 고용했습니다. 초기의 비전으로 돌아가는 것은 어려웠습니다. 첫번째로, 저는 투자자들에게 돌아가 더 많은 돈을 투자받아야 했습니다. 그리고 저는 지금의 팀에게 플랫폼 아이디어는 추구할만한 가치가 있는 것이고 저는 믿을만한 리더라는 사실을 납득시켜야 했습니다. 우리는 가능성을 본 새로운 경영진을 고용해야만 했습니다. 그리고 이번에는 좀 더 잘 위임해야만 했습니다. 쉽지 않았죠.
동정심을 사기 위한 이야기가 아닙니다. 저는 결단을 내렸고 그것을 사랑했습니다. 저는 기업가가 그들의 비전을 약간의 운을 가지고 현실로 만들수 있는 기회를 얻을 수 있는 나라에 사는 것을 감사하게 생각합니다. 미국에서 여러해의 고생과 불확실성이 따름에도 투자자들은 나같은 이민자에게 재미있는 앱을 만들라며 수백만 달러를 줍니다. 물론 모든 이야기의 끝에서는 당신은 스스로를 보여주거나 계속 시도해야합니다.
여러 몸부림을 통해 모바일 세계에서 미디어 논제가 어떻게 될지에 대해 보고 듣고 다듬었습니다. 저는 Matt Galligan 과 Arsenio Santos와 함께 저널리즘 회사인 Circa를 공동 설립했습니다. 이는 제 논제에 대한 첫번째 테스트가 될 것입니다. Cheezburger 앱은 제 전투에서의 피와 살이 될 것입니다. 이 앱에 깔려있는 철학은 CEO로서의 지난 3년간 제가 배운 교훈을 나타냅니다.
1. 소비는 배움이다.
기업가로서 배운 거의 모든 것은 다른 사람들이 일하는 것을 보면서 배운 것입니다. 유사하게, 우리는 유저들이 우리가 매일 실어나르는 유머들의 홍수에 영감을 받기를 바랍니다. 유저들은 그들의 친구의 피드 프로필과 좋아하는 사이트들을 Cheezburger 네트워크에서 볼수 있습니다 – 우리의 사이트와 우리의 유저들은 동등하게 취급됩니다. 많은 컨텐츠를 넉넉히 소비함으로써 사람들은 어떻게 다른 사람들을 웃길수 있는지 배우게 됩니다.
2. 리믹스는 협동이다
모든 아이디어는 비판이나 협동에 대해 열려있어야 합니다. 창의적이 되기 위해서, 우리는 다른 사람들의 아이디어를 우리 자신의 것으로 통합해야 합니다 – 저는 이것을 제가 점점 위임을 잘하게 되어가며 배웠습니다. 앱에서 우리는 다른 이미지나 GIF를 한번에 리믹스할수 있게 함으로써 이런 원리를 삽입했습니다. 우리는 친구들에게 영향을 받고 우리 또한 친구들에게 영향을 줄수 있게 했습니다. 리믹스는 아름답고, 진화하는 공동체 입니다. 우리는 그것을 포용했습니다.
3. 마찰은 죽음. 속도는 승리.
마찰은 꿈을 갉아먹습니다. 속도는 모든 비즈니스에서 큰 이점입니다. 저희와 유저들은 아이디어로부터 최대한 빨리 시작하는 것을 원했습니다. 우리는 유저들이 앱의 컨텐츠에서 원하는 것이 우리 회사의 관심사가 아니더라도 그들이 원하는 것들은 무엇이든 하게 해주었습니다.
바깥세상에서, 오늘날의 많은 테크 기업정신은 몇 메가바이트로 이루어진 간단한 기능들과 같이 보입니다. 당신은 프로젝트에 깔린 거대한 비전에 대해 들을지도 모르겠습니다. 아주 가끔 당신은 지저분한 전체 스토리에 대해 알게 될 것입니다. 이 개인적인 모험을 공유함으로서, 저는 당신이 제가 이 앱을 제가 원하던 미래를 형상화 – 모두를 위한 재미있고, 행복한 세상 – 한 것이라 할때 유머를 던져줬으면 합니다.
비록 초기 비전이 종종 실패하고 무시되더라도, 기업가들은 제품이 세상으로 뛰어드는 순간을 위해 피를 흘립니다. 3년간의 출혈 끝에, Brad 는 저에게 말했습니다. “이제 속죄는 끝내도 된다네.”
이 앱의 릴리즈는 저의 부활과도 같은 것이며, Cheezburger의 모두가 열심히 일했기에 가능했습니다. 저는 그들이 매우 자랑스러우나 아직 많은 것들이 남아있습니다. 제가 원하는 것은 더 많은 앱을 만들고 더 많은 릴리즈를 하는 것이니까요. 아무도 당신에게 성공을 약속하지 못합니다. 제가 할수 있는 것은 계속 시도하는 것뿐입니다.
원문보기
https://medium.com/backchannel/rewriting-cheezburger-saved-my-life-76fa09404916
IT 회사들의 Stack 엿보기, Stackshare
여러 굵직한 IT 회사들이나 스타트업들은 어떤 기술을 이용하고 있는지 궁금할 때가 있다.
구글링을 하거나 Quora와 같은 사이트를 찾다보면 어렵지 않게 찾아볼 수 있긴 하지만, 그래도 그 작업 자체가 번거롭긴 하다.
웹서핑을 하다가 이런 정보들을 모아놓은 사이트가 있는 것을 발견했는데, 주소는 다음과 같다.
사이트에 들어가보면 위와 같이 여러 Tech company들의 Tech stack, Utilities, DevOps, Business tool 들에 대한 정보들이 나온다. 자세한 정보가 나열된 것은 아니지만 각각의 회사들이 어떠한 툴들을 사용하고 있고, 어떤 툴이 어떤 용도로 널리 쓰이는지에 대해서 훑어보기는 편리하다.
사이트 로그인을 하지 않아도 이런 정보를 볼 수 있기는 하지만, Github 계정으로 가입할 수 있게 만들어놓은 점이 특이해서 가입을 해보았다. 가입하자마자 자신의 Stack을 share할 수 있게 해주는 페이지로 연결되는데, 이런식으로 스타트업이나 테크 기업들의 Stack을 수집하고 있는 것 같다.
사이트에 대해 좀 더 알아보니, Stackshare 자체도 하나의 스타트업으로 이미 펀딩도 받은 상태였다. 비즈니스 모델이 어떻게 되는지 자세히는 찾아보지 않았으나 굵직한 회사들의 Stack들을 소개하는 위쪽 공간에 영세 스타트업의 Stack을 소개해주는 광고(?) 비스무리한 배너가 출력되는 것을 보니, 스타트업에 어떤 기술 스택을 적용할지 고민하는 사람들이나 이에 관심있는 사람들을 끌어들이고, 여기에 소규모 스타트업들이 노출 될 수 있는 공간을 제공하려는 것 같다.
골드러시 시절엔 금캐는 사람들보다 청바지 만드는 사람들이 돈을 더 벌었고, 지금의 실리콘 밸리는 부동산 소유주들이 상당한 재미를 보고 있다고 한다. 남들은 다 황금을 쳐다보고 있을 때, 황금을 캐는 사람들의 니즈를 찾아 발빠르게 서비스를 제공하는 Stackshare와 같은 회사들이 더 재미를 볼 지는 지켜볼 일이다.
Layout XML의 Background 이미지에 할당된 메모리 즉시 반환하기
앱을 제작하는데 있어 Layout XML의 Background로 이미지를 포함시키는 작업은 상당히 빈번하게 이루어진다.
public class MainActivity extends ActionBarActivity {
private Button launchBtn;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
launchBtn = (Button) findViewById(R.id.button);
launchBtn.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Intent i = new Intent(MainActivity.this, SecondActivity.class);
startActivity(i);
finish();
}
});
}
}
위는 액티비티를 생성하고 Launch 버튼을 클릭하면 다음 액티비티가 실행되는 간단한 코드이다.
실행 결과는 다음과 같다.
Background로 포함된 이미지가 OOM을 유발한 만큼 크지 않은 이상 위와 같이 정상 실행된다.
여기서 문제는 아래의 화살표 부분에서 첫번째 Activity를 종료시키고 두번째 Activity를 실행했음에도 첫번째 Activity의 background XML에 할당된 이미지가 계속 메모리 공간을 점유하고 있고, 이 메모리가 언제 반환될지 알 수 없다는 것이다.
이는 이미지가 커서 많은 메모리를 점유하고 있거나, 다음 Activity에서 메모리가 많이 필요한 작업을 할 경우에 OOM을 유발시킬 수 있는 요인이 될 수 있는데, 이를 간단히 해결하는 방법은 다음과 같다.
@Override
protected void onDestroy() {
super.onDestroy();
findViewById(R.id.rootView).setBackground(null);
System.gc();
}
OnDestroy에서 Activity가 destroy될 때 View의 Background를 null로 설정하고 명시적으로 gc를 호출했다.
이로써 두번째 Activity가 시작될 때 첫번째 Activity의 XML에 할당된 메모리를 회수했음을 확인할 수 있다.
Technology Entrepreneurship (Lecture 4~8, 마무리하며)
Lecture 4. From idea to Opportunity
1) Technology는 Introduction, over exposure, parody/remix, equilibrium과 같은 Lifecycle을 가짐.
처음 발견되어 널리 퍼지게되면, 누구나 다 과도하게 사용하게 되고, 이후 이에 대한 패러디나 재발견 등을 거쳐 다시 평형 상태를 찾는다.
2) 팀을 구성할때는 누가 ‘A Player’고, 어떤 스킬셋을 가지고 있느냐가 다가 아니다. 어떤 목표를 가지고 있고, 어떻게 전념할 것인지 정확히 정의해라.
Lecture 5. Legal Aspects of Startups
1) 누가 공동창업자이고, 어떻게 지적 재산권을 분배할 것인지, 어떻게 주식이 분배될지 등 가능한 한 모든것을 문서화하라.
이러한 것들이 초창기에 문서화되지 않으면, 후에 충돌이 발생하게 된다.
2) 지적재산권(IP)에 대해서는 매우 조심해야 한다. 기존 고용주와 깔끔하게 갈라서고 싶고, 그들의 축복을 받으며 떠나고 싶다면 말이다. 하지만 기존 고용주와 일하고 있는 동안에는 스타트업에 대한 일을 해서는 안된다.
3) 어떻게 주식을 분배하고, 퇴직자 연금처리리 등에 대한 대화를 해라. 이러한 것들은 돈이 연관되어 있지 않을 때 이야기 하는 것이 훨씬 쉽다.
4) 다른 나라에 있는 공동 창업자나 이민 문제는 불행히도 매우 까다롭다. 법의 지역성 때문에 가이드라인을 잡기 힘들어진다. 분명히 모두가 한곳에 있다면 훨씬 쉬워질 것이다. 이를 피하는 방법이 몇가지 있긴 하지만, 복잡성을 증가시키고, 시간을 들여야하며 창의력을 발휘해야 한다. 몇몇 나라들이 다른나라보다 좀 더 쉬운편인데, 예를 들어 캐나다는 스타트업 비자를 가지고 있다.
미국은 조금 느린편이지만 무엇인가 대책을 마련하긴 할 것이다.
5) 기업 설립이나 지적재산권에 대해 변호사와 상담해야 하는지 궁금해지기 시작했다면, 그래야만 한다. 좋은 변호사를 찾는 가장 좋은 방법은 같은 지역에 있는 다른 창업자들에게 물어보는 것이다. 그들은 누가 함께 일하기 좋은지 말해줄 것이며, 좋은 스타트업 변호사들은 비용 지불을 펀딩을 받을때까지 연기해 줄 것이다. 종종 변호사들은 펀딩을 받기 쉽도록 도와주는데, 이를 위해선 당신의 스타트업이 리스크를 감당할만한 장래 유망한 스타트업이라는 것을 확신시켜야 한다.
6) 지적재산권(IP)을 보호하기 위한 몇가지 방법이 있다. 기업 비밀(Trade secrets), 상표(Trademarks), 특허(patents), 저작권(Copyright)이다. 좋은 변호사는 당신의 비즈니스 타입에 따라 어떤 선택을 해야하는지 도와줄 것이다. 투자자들은 때때로 지적재산권이 보호되는지 보곤하는데, 바이오테크를 제외한 기업가에게는 마켓에 대한 빠른 접근과 비즈니스 모델을 제대로 만들고, 효과적으로 실행하는 것이 최고의 보호방법이 된다.
7) 돈을 받거나 투자를 받기전에는 언제나 변호사와 상담하라. 특히 친구나, 가족, 엔젤투자자들이 돈을 주기 전에 말이다. 초창기에 한 실수들은 나중에 돈을 투자받기 어렵게 만든다.
Lecture 6. Customer Development and Lean Startups
1) Entrepreneurship은 Balancing Act
– optimistic/pessimistic, flexible/persistent : 너무 긍정적이면 현실을 파악하기 어렵고, 너무 비관적이면 사업을 시작하기가 쉽지 않다. 너무 유연하면 Customer development가 힘들고, 너무 경직되어 있으면 잘못된 컨셉에 너무 묶여 있게된다.
2) Startup process는 Unknown을 known으로 바꾸는 작업
– 가설을 설정하고 시험하며, 가설이 맞는지 확인하고 틀렸을 경우 pivot이 필요
– Customer가 원하는 것은 엔지니어 팀이 무엇을 만들고 싶어하나와 일치하지 않는다. (엔지니어 팀은 sexy한 프로덕트를 만들어내고 싶어하고, customer가 필요로 하는 것은 sexy한 프로덕트가 아니다. 실제 고객을 접하는 것이 중요하다.)
3) Lean/Fat startup에 대한 논쟁
– Ben Horowitz : Lean Startup 모델에서는 customer market fit을 찾은 후 go fat을 하라고 말한다. 하지만 이 모델에는 문제점이 있다. 첫번째로 Market fit을 정확히 알 수 있다고 가정한다. (Ipod의 경우 밀리언 셀러가 되는데 2년이 걸렸고, Iphone의 경우에는 3일이 걸렸다. Market fit을 정확히 어떻게 알 수 있나?) 두번째로는 Market fit을 이루면 그 상태가 계속될 것이라고 가정한다. (브라우저 시장의 예를 들면 MS가 윈도우에 익스플로러를 끼워팔면서 기존 브라우저 시장이 뒤엎어 지기도 했다. Market fit이 유지될지는 알 수 없다.) 마지막으로는 Market fit을 이룰때까지 경쟁이 없을 것이라는 가정을 한다. 경쟁자들은 기다려주지 않고 빠르게 움직인다.
– Fred Wilson : Double amount of cash가 창업가의 Exit 확률을 높여주지 않는다. 스타트업의 value를 이루는 것은 아이디어나 프로덕트 팀의 quality, 운 등 여러 요소이고, 자금은 그 중 하나의 요소일 뿐이다. go fat을 빠르게 가는 것은 도움이 되지 않는다.
Lecture 7. Entrepreneurship in Emerging Economies
1) 중국에서의 Entrepreneurship 환경 – 펀드 레이징 관련
– Seed money 구하기 힘들다, 은행에서 대출을 통해 초기 자금을 구하기도 어렵다.
비즈니스가 일정 궤도에 오른 후에도 중국에서의 펀드레이징은 창업자와의 관계를 중시하고 이는 펀드레이징을 받기 힘들게 만든다. 큰 돈은 Guanxi(꽌시)를 가지고 있는 사람들에게 가고, 대부분의 창업자들의 경우 Diao si이므로 (연줄도 없고, 돈도 없는 일반 가정 출신의 가난한 젊은이를 나타내는 중국어 슬랭) 펀딩을 받는 것은 매우 어렵다. 그래서 비즈니스를 운영하기 위해서는 현금흐름을 만들거나 친구들에게 돈을 빌려야 한다. VC와의 Term sheet에 사인을 하더라도 돈을 바로 받을 수 있는 것이 아니고, 실제적인 관계 형성을 하기까지 오랜 시간을 기다려야 한다. 이 와중에도 Commitment 이슈등이 생기면 언제든지 일이 틀어질 수 있고, 이는 펀딩을 더 어렵게 만든다.
2) 중국에서의 Entrepreneurship 환경 – 정부 및 그 외 관련
– 정부 관련 문제들은 피할 수 없다. 베이징 쪽은 좋지 않고, 그나마 상하이쪽의 정부관료들은 생산적이다.
그 외에도 사기나, 부패와 같은 것들과 싸워야 한다.
중국 Startup Entrepreneur(YingYi) 인터뷰 링크
https://vimeo.com/74811163
https://vimeo.com/74812478
https://vimeo.com/74811164
Lecture 8. Entrepreneurial Marketing and Sales
1) 사람들이 어떻게 물건을 사게 만드나?
– 확실한 value proposition을 가질 것
– Demand creation 실험을 할 것
– Influencer를 찾을 것
– Bowling pin strategy를 이용할 것
연초에 계획했던 Technology Entrepreneurship 강의를 드디어 끝마쳤다. 중간에 약간 강의가 밀리기도 하고, 팀 프로젝트도 조금 소홀히 하긴 했지만, 어찌됐든 마무리를 지었다.
이론적인 내용들도 많았지만 Lean/Fat 스타트업에 대한 논쟁과 중국의 스타트업 환경 및 창업자 인터뷰 부분은 재미있게 들었다. 중국의 “꽌시” 문화와 그 때문에 스타트업 생태계가 받는 영향에 대한 창업자의 인터뷰를 통해 그러한 환경에서도 꾸준히 도전하는 중국의 Diao si들의 열망을 볼 수 있었다.
스타트업의 주요 키워드 중 하나인 Lean Startup도 하나의 관점일 뿐이라는 깨달음 아닌 깨달음도 얻었다. 주변에서 다들 Lean Startup이나 MVP를 외치고 있다보면, 그것이 마치 진리인 양 생각하게 되버린다. 장하준의 경제학 강의를 읽고 경제학에도 여러 관점과 접근법이 있고 각각의 한계가 명확하다는 사실에 충격을 받고, (Freakonomics와 같은 책을 재미있게 읽었던 나로서는 속았다는 기분도 약간 들었다.) 넓은 관점을 가져야 겠다고 생각한 것이 얼마 전인데 벌써 이러는 것을 보면 아직 갈 길이 멀다.
Lean Startup이 아니면 뭔가 잘못된 방법으로 스타트업을 하고 있는 것처럼 여겨지는 분위기와는 별개로, 각 방법론의 장단점을 정확히 알고 사용하도록 해야겠다.
마지막으로 강의를 마무리하며 Heidi Roizen의 인터뷰를 들었다. 실리콘 밸리의 Legendary connector라고까지 불리는 무게감과는 달리 편안하고, 밝고 유머러스한 분위기로 시종일관 인터뷰를 지속 하는 모습에 좋은 인상을 가지게 되었다. 간단히 인터뷰에 대한 느낀 점과 감사 인사를 메일로 적어 보냈는데, 몇시간 뒤 답장이 왔다. 긴 답장은 아니었지만 예상도 못한 답장에 대단한 사람이구나 하는 생각을 다시금 했던 것 같다.
Android Studio로 버전코드/버전네임 관리하기
PlayStore에 등록된 앱은 VersionCode와 VersionName의 두가지 속성을 가지고 있다.
VersionCode는 정수값을 이용하는데, 플레이 스토어 내부적으로 상위 버전을 구분하는데 사용되고, VersionName은 플레이 스토어에서 사용자에게 보여주기 위한 값으로 사용된다.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.example"
android:versionCode="0"
android:versionName="0.0.0.0">
보통 AndroidManifest.xml에 위와 같이 정의하여 사용하는데, 안드로이드 스튜디오에서는 Gradle scripts의 Build.gradle(Module:app)에 정의된 아래 값에 의해 manifest에 정의된 값이 무시된다.
android {
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "com.android.example"
minSdkVersion 14
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
자동화된 빌드 툴을 쓰지 않고 일일히 버전코드와 버전네임을 관리하는 것은 귀찮은 일인데, 이럴때 간단하게 버전 코드를 업데이트 해줄 방법은 다음과 같다.
apply plugin: 'com.android.application'
import java.util.regex.Pattern
android {
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "com.android.example"
minSdkVersion 14
targetSdkVersion 21
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:21.0.3'
}
task('increaseVersionCode') << {
def manifestFile = file("src/main/AndroidManifest.xml")
def pattern = Pattern.compile("versionCode=\"(\\d+)\"")
def manifestText = manifestFile.getText()
def matcher = pattern.matcher(manifestText)
matcher.find()
def versionCode = Integer.parseInt(matcher.group(1))
def manifestContent = matcher.replaceAll("versionCode=\"" + ++versionCode + "\"")
manifestFile.write(manifestContent)
}
task('incrementVersionName') << {
def manifestFile = file("src/main/AndroidManifest.xml")
def patternVersionNumber = Pattern.compile("versionName=\"(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)\"")
def manifestText = manifestFile.getText()
def matcherVersionNumber = patternVersionNumber.matcher(manifestText)
matcherVersionNumber.find()
def majorVersion = Integer.parseInt(matcherVersionNumber.group(1))
def minorVersion = Integer.parseInt(matcherVersionNumber.group(2))
def pointVersion = Integer.parseInt(matcherVersionNumber.group(3))
def buildVersion = Integer.parseInt(matcherVersionNumber.group(4))
def mNextVersionName = majorVersion + "." + minorVersion + "." + pointVersion + "." + (buildVersion + 1)
def manifestContent = matcherVersionNumber.replaceAll("versionName=\"" + mNextVersionName + "\"")
manifestFile.write(manifestContent)
}
tasks.whenTaskAdded { task ->
if (task.name == 'generateReleaseBuildConfig' || task.name == 'generateDebugBuildConfig') {
task.dependsOn 'increaseVersionCode'
task.dependsOn 'incrementVersionName'
}
}
default config의 versionCode/versionName를 삭제한 후, Build.gradle에 위와 같이 task 구문을 추가해 주면 빌드 시마다 Manifest의 VersionCode가 +1씩 증가하게되고, VersionName은 0.0.0.0 (Major.Minor.Point.Build 버전) 순으로 형성되어 빌드 시마다 빌드버전이 +1씩 증가된다.
public class MainActivity extends ActionBarActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
PackageInfo pInfo = null;
try {
pInfo = getPackageManager().getPackageInfo(
this.getPackageName(), 0);
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
int versionCode = pInfo.versionCode;
String versionName = pInfo.versionName;
TextView versionCodeTextView = (TextView) findViewById(R.id.versionCode);
versionCodeTextView.setText("VersionCode:"+Integer.toString(versionCode));
TextView versionNameTextView = (TextView) findViewById(R.id.versionName);
versionNameTextView.setText("VersionName:"+versionName);
}
}
매니페스트 상에서도 바로바로 업데이트 되는 것을 볼 수 있지만 위와 같이 버전명과 버전코드를 호출해서 확인도 가능하다.
Android Studio Getter/Setter prefix 설정법
클래스의 멤버 변수나 스태틱 변수 이름 명명 시 mVariable, sVariable과 같이 접두사를 이용하는데,
안드로이드 스튜디오에서는 Getter/Setter의 prefix를 설정하는 방법을 몰라서 Getter/Setter 자동 생성시
getmVariable, setmVariable과 같이 메소드 명이 생성되어 손이 두번 가곤 했다.
접두어 설정 방법은 메뉴에서 File -> Other Settings -> Default Settings 에 들어간 후 Code Style -> Java
이후 Default에 있는 Code Generation의 Name Prefix를 Field : m, Static Field : s로 설정해 놓으면 된다.
SporTracker 제작 후기 (2) – Amazon Web Service, Elastic Beanstalk 사용기
SporTracker를 제작하며 개인 기록을 저장할 간단한 서버가 필요했다.
AWS EC2에는 어느 정도 익숙한 편이지만, 일일히 EC2 인스턴스에 DB를 설치하고 웹서버를 설정하고 다시 앱과 연동하는 것은 간단히 빠르게 구현해 업로드 하려던 프로젝트의 취지에 맞지 않았다.
그래서 눈을 돌리게 된 것이 Elastic Beanstalk다. 콘솔을 통한 몇번의 클릭만으로도 Auto Scaling이 지원되는 서버를 쉽게 설정할 수 있고, mysql을 지원하는 RDS를 통해 DB 로그 보기나 DB 백업등의 관리를 손쉽게 가능하게 해준다. Cloud watch와 연동하여 여러 조건에 대해 이메일 알람을 받는것도 쉽게 설정할 수 있으며, 자체적인 버전 관리 기능도 가지고 있다.
어플리케이션 배포는 콘솔을 통해 zip 파일을 올리는 것으로도 가능하고, 이와 더불어 git을 통한 퍼블리싱도 가능하다.
나의 경우에는 Beanstalk-CLI (링크)를 설치하고, 파이썬과 boto 인터페이스(링크)를 설치 한 후 git을 통해 beanstalk 서버에 직접 업로드 하는 방식을 사용했는데, 설정도 간편하고 git을 통해 푸시하는 방식은 익숙하다 보니 어렵지 않게 이용할 수 있었다.
DB에 접속할 때, php의 경우
$dbhost = $_SERVER['RDS_HOSTNAME'];
$dbport = $_SERVER['RDS_PORT'];
$dbname = $_SERVER['RDS_DB_NAME'];
$dsn = "mysql:host={$dbhost};port={$dbport};dbname={$dbname}";
$username = $_SERVER['RDS_USERNAME'];
$password = $_SERVER['RDS_PASSWORD'];
$dbh = new PDO($dsn, $username, $password);
와 같이 접근하면 DB 핸들러를 얻을 수 있다.
그 이후에는 다른 서버에서 작업할때와 별반 다른점이 없는데, 다만 고생했던 점은.. DB 테이블의 인코딩을 UTF-8로 설정하고, 앱에서도 제대로된 인코딩 값을 보내주는데 DB에서 계속 한글이 깨지게 출력되어 알고보니 RDS DB의 기본 encoding 설정이 utf-8이 아닌 latin1으로 되어었었다.
문제는 이 설정값은 Beanstalk에 의해 생성된 인스턴스에 접근해서 my.cnf 파일을 수정해도 바꿀 수가 없다는 것인데, 온갖 방법으로 시도해봐도 영 바뀌지가 않아 고생하고 있다가 결국 해결책을 찾아냈다.
AWS관리 콘솔에 들어가서 RDS 대쉬보드에 들어가 Parameter charset을 UTF-8로 적용한 그룹을 생성하고, RDS 인스턴스 중에서 Elastic beanstalk가 생성한 인스턴스에서 instance action를 선택, 이후 modify -> Database options 하위에서 해당 Parameter group을 적용한 후 RDS 인스턴스를 재부팅하면 된다.
이후 다시 DB에 접속하여 show variables like ‘c%’를 쳐보면
character_set_client utf8 character_set_connection utf8 character_set_database utf8 character_set_filesystem utf8 character_set_results utf8 character_set_server utf8 character_set_system utf8 character_sets_dir /rdsdbbin/mysql-5.5.40b.R1/share/charsets/ collation_connection utf8_general_ci collation_database utf8_general_ci collation_server utf8_general_ci completion_type NO_CHAIN concurrent_insert AUTO connect_timeout 10
아마존에서는 RDS의 파라미터 값을 바꾸는 것을 권장하지 않아 이런식으로 파라미터를 잠가 놓았다는데, 기왕이면 utf-8로 설정해주지 latin1이라니.. 그 탓에 Elastic beanstalk를 포기하고 EC2 인스턴스를 그냥 하나 생성할까도 고민했었다.
간단한 서버의 배포를 위해 이 모든것을 설정하는데, EB를 이용하면 5분이 채 걸리지 않는다. (나처럼 헤매지 않는다는 가정하에..)
더구나 Free tier에서 이용 가능하므로 이 모든 것을 이용하면서도 비용이 청구되지 않는다. (서비스 트래픽이 증가해 Auto Scaling이 되지 않는 이상, Auto Scaling 되더라도 기본 설정은 t1.micro 4대까지 이므로 적절히 한달 가동시간 750시간을 넘기지 않게 잘 관리해주면 된다.)
SporTracker 제작 후기 (1) – Twitter Fabric, Crashlytics kit 사용기
지난달 남는 시간을 들여 만든 앱을 하나 앱스토어에 등록했다.
Eclipse ADT만 사용하다가 Android studio로 갈아탄 후 제작한 첫 앱인데, 처음엔 IDE가 익숙하지 않아 고생했지만 이런저런 시행착오를 한 덕에 Android studio에 익숙해졌다.
앱에 대한 설명을 간단히 하자면, 개인적으로 수영을 즐겨 하기에 내 수영 기록을 로컬 DB에 저장 관리하면서 그래프로 기록 추이를 나타내서 보여주면 좋겠단 생각에서 시작했다. 1주일 정도 짬짬히 시간을 내서 오픈소스와 기본 위젯들을 간단히 변형하여 완성했는데, 켤때마다 투박한 모습이 거슬려서 material 디자인 스타일의 위젯으로 전부다 갈아 엎었다.
기왕 깔끔하게 만들기로 작정한 참에 여러 사람이 쓸 수 있도록 공개해야겠다는 생각이 들어, 여러 사람들의 기록을 저장할 수 있도록 AWS를 이용해서 DB와 웹서버도 붙이고, 구글플러스 로그인 연동을 붙여 구색을 맞추어 놓았다.
IDE에 익숙해지려고 시작한 작은 프로젝트가 너무 커진다는 생각이 들어서, 웹서버쪽의 세세한 구현은 추후 반응이 있으면 추가 구현하기로 마음먹고 버전을 릴리즈했다. 첫 커밋을 한 후 정확히 한달 째 되던 날 코딩을 마무리하고 앱을 마켓에 등록했다.
나름 마켓에 등록한 앱이니 Crash report도 붙여놨는데, 작은 프로젝트들에 대하여 자주 사용했던 URQA (링크) 대신, Twitter Fabric(링크)을 대신 이용해 보았다.
Android Studio에 Fabric을 설치하는 것은 설명이 필요 없을 정도로 쉽다. 플러그인만 설치하면 되고, 이마저도 튜토리얼이 제공된다. 튜토리얼을 따라서 Fabric을 설치하고 나면 안드로이드 스튜디오가 알아서 프로젝트에 Crashlytics를 추가해준다. 추가한 후 에는 Fabric Answer 탭에서 아래와 같은 창을 볼 수 있다.
DAU등과 더불어 각각의 Activity에 대한 세션 길이또한 보여준다.
덕지덕지 붙여놓은 Google Analytics가 무색해질만큼 간단한 정보는 편리하게 받아 볼 수 있다.
사실 이러한 기능보다 더욱 더 편리하다고 생각되는 것은 Beta라는 기능이다.
소규모 앱개발자들의 경우 베타테스터에게 앱을 릴리즈하고, 테스트 리포트를 받아보는 과정은 상당히 까다로운 과정이다.
APK를 일일히 보내서 업데이트하기도 번거롭고, 그렇다고 구글 플레이 스토어의 베타 업로드 기능을 사용하려면, 한번 업로드 하고 그 내용이 적용되기까지 몇시간은 그냥 날려먹어야 한다.
하지만 Beta를 이용하면 아래의 인터페이스를 통해 간단히 베타 버전을 릴리즈 할 수 있다.
Add Tester 버튼을 통해 이메일 주소만 추가하면 해당 메일을 통해 베타 테스트 앱 링크가 날아가고, 해당 메일을 선택하여 Accept를 선택하면 Beta 앱이 베타테스터의 디바이스에 설치된다.
링크를 선택해 Beta를 실행시키면 위와 같이 베타버전 접속이 가능하다.
권한이 허가되면 마지막 화면과 같이 릴리즈 노트와 베타버전을 다운받을 수 있는 버튼이 표시된다.
베타 테스터들의 테스트 결과는 Crash report와 Fabric Answer에 바로 적용되고, Fabric 인터페이스를 통해 베타테스터의 권한을 회수하거나, 테스터마다 다른 권한을 주어 관리하고, 테스터 그룹을 생성/관리할 수 있다.
마지막으로 Crash report 항목이다.
위와 같이 어디서 크래쉬가 발생했고, 몇명의 유저가 영향을 받았는지 표시된다.
버전별, 시간대별로 정렬 가능하고 Jira와 같은 Issue 트래킹 시스템 만큼은 아니지만 간단히 Issue의 Open/Closed 상태도 관리가 가능하다.
상세 issue정보를 보면, 기기의 루팅 상태나 Storage, memory 상태들을 볼 수 있고 좀더 자세히 살펴보면
위와 같이 기기 정보나, 배터리 정보, UI orientation 에 대한 정보도 출력된다. 커스텀 키를 설정해서 추가 정보를 받을 수도 있는 것 같은데, 여러모로 이슈 트래킹에 도움이 될 것으로 보인다.
이슈를 close 하게되면 위와 같이 표시되며, Crash report 리스트 상에서는 취소선이 표시된다.
간단히 사용할 수 있고, 편리하지만 그렇다고 기능이 가볍지는 않다.
아직 세세한 기능까지는 사용해보지 않았고, Fabric 자체도 아직은 베타 버전이지만 지금까지의 상태만으로도 충분히 강력하고, 기대되는 모습을 보여준다. 특히 Beta의 강력한 베타테스터 배포 기능은 Fabric이 앞으로 널리 쓰이게 될 것이라는 확신을 갖게 해준다.
얼마나 사용히 간편한지 간단한 튜토리얼을 보고 싶다면, 아래의 링크에 접속해보시길 바란다.
http://www.crashlytics.com/blog/launching-beta-by-crashlytics/
MAC OS의 Vim에서 Syntax highlight 사용하기
Mac에서 터미널을 진입하여 Vim을 사용하려고 보면 Syntax highlight가 되지 않고 아래와 같이 출력된다.
하이라이트가 되지 않아 코드 식별이 힘든 Mac의 Default vim..
colorscheme delek등을 수행해봐도 아무런 색상 적용이 되지 않는데, /usr/share/vim/vim73/colors 하위를 확인해보면 아래와 같이 colorscheme 들은 포함되어 있다.
이때는 /usr/share/vim/vimrc 파일을 수정하여 syntax on 이라는 문장을 추가해주면 된다.
전체 유저에게 적용할 default theme를 적용하려면 colo desert와 같이 한 줄을 더 추가한다.
보는바와 같이 desert 테마가 적용되었다.
custom scheme를 추가하기 위해서는 root 계정이 필요한대 Mac OS에서는 기본적으로 비활성화 되어있으므로 여기를 참조하여 root 계정을 활성화 하고 /usr/share/vim/vim73/colors/ 하위에 custom scheme을 복사해 넣고 동일한 방법으로 적용하면 된다.
Technology Entrepreneurship (Lecture 3: Framework, Business, Models and Team Building)
Lecture 3. Framework, Business, Models and Team Building
1) Business Model Testing
– Entrepreneurship : experimentation & search Process
스타트업은 Repeatable, Scalable 비즈니스 모델을 찾아야 함. Biz model 에 대한 Evidence를 찾아가는 과정
– Biz model을 이루는 가정정에 대한 Experimentation Progress를 계속 반복하고 Documentation 하는 과정이 중요
https://www.leanlaunchlab.com 와 같은 사이트에서 9-Block biz model에 대한 버전관리를 제공함 (30 Day Trial)
Lean launch lab
– 모든 모델의 Segment에는 가정이 필요하다.
Smartphone App의 Customer segment가 30~50대의 스마트폰 유저라고 가정했다면, 왜 30~50대인가, 왜 그보다 더 어리거나 늙은 사람은 대상이 될 수 없는가, 30~50대의 Single인가 married인가 등에 대해 확실하고 구체적인 가정을 세우고, 그 가정에 대해 검증을 실시해야 한다.
– 타겟 그룹에 대하여 여러 채널을 통해 정말 구매 의사가 있는가 확인할 것 (실제 User들을 만나라.)
– Web Startup Building에 대한 Steve Blank의 글 (원문 링크)
- Set up the logistics to manage your team
– Biz model의 변화를 기록하고, 팀원간의 소통을 위한 채널 만들기 - Craft company hypotheses
– 9블록 모델 생성
– Key Feature를 정의하고, 이를 제공할 MVP(Minimum viable product) 정의
– Google Trends, FaceBook Ads 등을 통해 시장크기 파악(시장 세분화), crunchbase (스타트업 투자 정보) 사이트를 통해 경쟁자 파악
– 시장 타입 파악 (existing, new, resegmented) : 새로운 타입의 서비스와 기존 시장에 침투하는 서비스의 경우 서로 다른 Sales/Marketing 전략을 수립해야 함 - Write a value proposition statement that other people understand
– “We help X do Y by doing Z”와 같은 형식으로 정의, 이후 여러 사람에게 의견을 물을 것. 사람들이 이해하지 못할 경우 설명해주고, 그 설명에 대한 요약을 요청해볼 것 - Set up the Website Logistics
– 웹사이트 운영에 관련된 도메인, 이메일 등등 기반 갖추기 - Build a “low-fidelity” web site
– Splash 페이지에 서비스 설명이나, 설문조사, Pre-order form을 갖춤 - Get customers to the site
– 잠재 사용자에게 사이트 노출, Customer segment와 Value proposition 테스팅
– 광고, 지인 등을 여러 채널 통해 홍보
– MVP나 Website에 대한 feedback을 받을 것 - Add the backend code to make the site work
– 웹사이트 상세 구현 - Test the “problem” with customer data
– Analytics tool (Google Analytics 등)의 여러 통계 툴을 이용해 고객 데이터 분석
– User satisfaction을 측정하고, feedback이나 기능 제안등을 수집
– Is there anything preventing you from signing up?, What else would you need to know to consider this solution? 등 일반적인 질문보다는 구체적 질문을 포함할 것
– in-depth conversation이 가능한 채널 확보할 수 있으면 확보 - Test the “solution” by building the “high-fidelity” website
– 5~8을 통해 얻은 정보로 서비스 업데이트트
– High-Fidelity가 Complete product를 말하는 것이 아님, 계속 검증하며 전체 서비스의 질을 높임 (Be professional and credible!)
– 고객정보는 계속 Tracking하고 분석 - Ask for money
– 완벽한 제품 런칭 전 “Pre-order” 페이지 준비
– Paying solution 고려할 것
이러한 과정에 대한 대략적인 예 How to Create a Million-Dollar Business This Weekend (Examples: AppSumo, Mint, Chihuahuas)
2) 9 Frameworks for Entrepreneurship
Entrepreneurial process를 설명하는 9개의 Framework
– Market과 Product/Service 간의 Missing link를 찾는 Opportunity Recognition과 Pursuit of Opportunity의 Phase로 구분
New Technology부터 이것이 Market에서 어떻게 사용될 것인지를 찾거나, 반대로 Market의 Needs 충족시킬 수 있는 Technology를 찾아내고, 이를 구현할 팀과 조직을 형성하고, 자원을 조달함
– 어떤 Business인가, 무엇을 이룰 것인가에 대한 비전 정의, 이후 비전을 수행할 전략을 세워 실행
– People, Deal, Resources, Opportunity의 4요소가 모여 비즈니스 모델을 이룸
– VC들이 고려하는 Entrepreneur
– Startup에 존재하는 Risk의 분류와 어떻게 Risk를 줄여가느냐에 대한 Framework
– 사람들의 성향을 Innovators/Early Adopters/Early, Late Majority/Laggards 로 분류, Startup은 Early Adopter가 움직인 이후 Chasm(협곡, Bowling alley)를 넘겨야 성장
– 고객을 어떻게 정의하고, 점검하느냐에 대한 프로세스
– Startup이 설립되고, 성장하여 Exit에 이르는 결과에 대한 Framework
– Framework 2의 역 접근법으로 지금 가진 것으로 할 수있는 것에서부터 시작해 전략과 비전으로 이동한다.
우리는 창업가나 기업가와 같은 단어들을 떠올릴 때, 자신만의 insight와 확실한 vision을 통해 스타트업을 이끌어 가는 사람들을 생각한다. 이번 강의는 스타트업의 운영이 실험/검증에 대한 프로세스를 통해서도 올바른 방향으로 나아갈 수 있다는 것을 시사한다. 여러가지 Framework를 통해 가능한 많은 분야를 고려하고, Risk를 줄이며 발전해 나가는 것이 모두가 Steve jobs와 같은 visionary가 될 수 없는 상황에서는 더욱 현실적일 것이다.
P.S
점점 강의에서 요구하는 것이 많아지고 있다.
10 Best, 5 Worst 스타트업 아이디어를 제출하는 과제부터 시작해, 다른 사람들의 스타트업 아이디어를 평가하고, 이번주에는 다른 사람들과 팀을 이루어 주었다.
내가 있는 팀은 브라질 사람들이 주가 된 9명으로 된 다국적 팀이며, 이중 한명은 이미 2개의 사업을 가지고 있는 사람이다.
계속 짬을 내 강의를 보고 과제를 제출하고 결과를 정리하는 것이 쉽지만은 않지만, 스타트업에 관심있는 세계 각국의 사람들의 의견을 듣고, 내 의견에 대한 솔직한 피드백을 들을 수 있다는 점은 즐거운 일이다.
Ringster's Techblog 