모든것엔 적정선이 있기 마련이다. 가끔 프로젝트를 진행하다면 개발자로 인하여 프로젝트가 망가지는 케이스를 심심찮게 볼 수 있다. 이 모든 건 사실 기획레벨에서 개발에 대한 지식이 부족하여서이겠지만, 그래도 개발 멤버들이 반성해야될 부분도 많다. 개발미스로 프로젝트가 망가지는 건 크게 두가지로 분류할 수 있다. 개발력이 프로젝트에 비해 딸려서거나, 그 반대로 프로젝트에 비해 개발력이 과도해서이다.
1. 자주 지각하는 개발자.
지각은 왜 하는 것일까. 살펴본 결과 몇가지 케이스가 있었다.
개발은 협업적인 측면도 강하지만, 협업할 포인트만 정확히 짚어내면 기본적으로는 개인의 일에 가깝다. 즉, 모듈과 모듈와 연결고리만 정확하게 정의한다면 나머지는 개발자 개인의 일이 된다. 이렇다보니 개발자는 협업에 대한 기본을 망각하기 쉽다. 회사 전체에 대한 개념 없이 '내 할일만 하면 끝이지'란 마인드가 생기는 경우가 있다. 이것이 지각이 만연하게 되는 첫번째 이유다.
한편, 다른 원인으로는 자기관리의 미숙이 있다. 일정한 기상시간을 유지못한다던가, 반대로 일정한 퇴근시간을 유지못하여 누가 시키지도 않은 밤샘작업후에 이틀간 결근을 한다던가 하는 케이스도 웃지 못할 케이스도 많다. 지나치게 일에 열중하여 자신의 페이스를 유지못하는 것은 일을 잘하는 것이 아니라 일을 내팽겨치는 것이다. 결코 이런 케이스에 '너무 열심히 하면 그럴 수도 있지. 다들 본받아요' 라는 메세지를 던져주면 그 회사는 곧 아무도 나오지 않는 회사가 될 것이다.
지각이란 전염되는 측면이 강하다. 필자가 본 한 회사에서는 개발팀장이 자주 지각하더니 성실한 인턴조차 곧 전부 지각하는 현상을 보였다.
사실 이 기저에 깔린 문제는 지각을 용인하는 문화에 있다. 개발물이라는 것은 대체되지 않는다. A, B 기획자가 사장에게 기획발표를 했을때, A발표자가 지각했다면 패널티를 적용하여 B의 기획안을 채택할 수 있다. 그러나 A개발자가 DB모듈, B개발자가 웹모듈을 개발하여 개발발표를 하였을 때 B개발자가 회의에 늦었다고 해서 웹 모듈을 빼고 제품을 출시할 수는 없다. 이러다보니 회사에서는 개발자의 지각에 대해 관대해지기 쉽상이다. 그리고 개발자는 자신의 지각에 대한 변명으로 창의적 회사 분위기를 운운하지만, 사실 생각해보면 지각만큼 회사 분위기를 좀먹는 케이스도 없다.
물론 몇몇 회사의 경우 아예 출퇴근 관리를 개인에게 맡기는 경우도 있다. 특히 연구소와 같은 곳은 지각에 관대해도 큰 문제가 없다. 그러나 반드시 명심해야할 것이 하나 있다. 이런 조직의 경우 대다수 상당히 해고가 자유롭다는 것이다.
창의적인 문화로 칭송받는 세계적 대기업인 A사의 예를 들어보자. 특정한 일을 던져주고, 몇월 몇일까지 해결하라고 한 다음, 실패할 경우 인력을 교체한다던가 개인에게 강력한 패널티를 준다. 문제만 해결할 수 있다면 몇시에 출근하든 몇시에 퇴근하든 신경쓰지 않는다. 급여는 상당히 높다. 언론엔 창의적 회사로 소개된다 (그리고 물론 대학생들도 그걸 믿는다). 그러면 이제 이 회사의 어두운면을 보자. 구성원 대다수는 비정규직이다. 언제 어떻게 짤릴지 모르니 무조건 열심히 하는 수 밖에는 답이 없다. 회사에 들어오고 싶어하는 사람들도 줄을 서 있다. 회사가 사람을 키운다거나 그런 환상은 갖지 않는다. 싹수가 보이는 성실한 인력을 채용할 필요 없다. 좋은 대학의 박사과정을 뽑아서, 필요한 것을 시킨다음, 능력이 고갈되면 회사를 그만두게 하면 된다. (삼성의 경우 성실한 인재를 우선으로 채용한다. 그러나 구글의 경우엔 이미 포지션에 딱 맞는 인재를 영입하는 것이 자신의 인재방침이라고 공공연하게 밝혔다.)
지각 문제를 해결하는 딱히 좋은 방법은 없다. 지각이라는 것은 경고를 아무리 준다고 해도 고쳐지지 않는 습관인 경우가 대다수이다. 벌금제를 채택하면 회사 분위기도 안좋아진다. 해고 외에 좋은 방법을 찾아내긴 어려울 것이다.
2. 일정관리 안되는 개발자.
'지난주 까지 개발하기로 했는데, 왜 아직도 안되었죠?'
'아 거의 다 되었는데 - 지금 이 모듈만 붙이면 됩니다. 다음주 화요일까지는 될겁니다'
이건 그냥 안된거다. 80%가 되었던 20%가 되었던 안된것은 마찬가지다. 개발을 하다보면 급작스런 이슈사항이 발생할 수 있다. 그러나 그에 대해 사전 보고가 올라가지 않았고, 당일에서야 미안하다면서 머리를 긁적이는 개발자. 프로젝트를 망치는 일 순위다. 그러나 잘 들어보면 역시 이유가 있다. '지금 서버에 깔려있는 우분투와 지금 쓰고있는 라이브러리가 충돌해서' 라던가, '제가 XX를 YY인줄알았는데 잘 못 생각했네요' 라던가. 그러나 다음주 화요일이 되면, 또다시 새로운 이슈가 발생할 것이고, 개발은 역시 늦어질 것이다. 이는 프로젝트 관리나 기획의 문제라기보단 개발자 개인의 문제 요소다. 보통 이런 개발자들은 자신이 아는 기술 대신에 새로운 기술을 도입하려다가 회사를 망하게 하는 경우가 많다.
통계적으로 개발자는 자신의 능력을 실제 능력보다 40% 정도 과장하여 생각한다고 한다. 이것은 감안하여 개발스케쥴을 짜야 한다. 그러나 어떤 개발자는 자신의 능력을 100% 200% 과장하여 생각하는 경우도 있다. 이것 또한 해결 방법은 없다. 프로젝트 일정은 끝없이 지연될 것이다. 최대한 빨리 프로젝트를 그만두는 것이 상책이다.
3. 트래픽, 보안에 신경쓰는 개발자.
Paypal 에서 이런이런 보안을 채택했다고 해서 자신이 개발하는 서비스에도 이런 저런 보안 모듈 넣치 않으면 소비자 신뢰가 깨질 것이라는 환상갖는 개발자. 역시 있다.
언제나 적정기술이 중요하다. 만약에 가진 돈이 백만원밖에 없다면, 천만원짜리 금고를 사는 바보는 없을 것이다. 그러나 이용자가 얼마나 될지도 모르는 서비스에 보안때문에 이삼일씩이나 소비하는 개발자는 많다. 일정관리가 안된다면 이 이삼일은 일주일로 늘 것이다. 더 큰 문제는 이런 필요없는 코드때문에 향후 개발속도가 더 느려진다는 것에 있다. 예를들어 개발중인 프로젝트의 통신모듈에 SSL을 붙였다고 생각해보자. 앞으로 이 프로젝트는 패킷을 잡아서 디버깅을 하기 위해서는 일일이 SSL을 뺀 후, 수정하고, 다시 SSL을 붙이는 작업을 반복해야 할 것이다. 이런 작업은 유져가 늘어난 다음 해도 충분하다. 카카오톡 역시 보안이 추가 된 것은 이미 크래킹방법이 널리 퍼진 이후였다.
서버가 해킹을 당하면 기획자는 진심으로 기뻐하며 보도자료를 내면 된다. 만약 출시하는 서비스가 기존에 없던 새로운 서비스라면, 이보다 더 확실한 광고효과는 잘 없을 것이다. 카카오톡의 패킷 스니핑은 네이버 뉴스의 톱도 차지했다. 그러나 유져는 그 누구도 그것때문에 카카오톡의 신뢰성을 떨어뜨리지 않았다.
트래픽도 마찬가지다. 트래픽의 기본은 '맞은 다음 해결한다' 이다. 사용자가 얼마나 될지도 모르는데 애시당초 분산서버 며 캐쉬며 고민 할 필요 없다. 심지어 요즘 클라우드 서비스들은 클릭 한번에 프로세스 늘려주고, 캐쉬달아주지 않던가. 만약에 대기업이라면 분산서버도, 보안도 중요하다. 그러나 스타트업계는 빠르게 만들고, 소비자에게 보여주고, 피드백 받아서 수정하는 것보다 중요한 미덕은 없다. 그 외에 모든 것은 잊어버려야 한다. 보안이나 트래픽때문에 코드 한 줄이라도 쓸데없는데에 낭비되어선 안된다. 디버깅에 걸리적거리기만 할 뿐이다.
어떤 분은 myspace 의 예로 트래픽 관리의 중요성을 말할 지도 모르겠다. 그러나 myspace가 실패한 이유는 트래픽을 맞아서가 아니라 맞은 트래픽 문제에 대한 해결을 실패했기 때문이다. 트래픽 맞은 다음에 해결하면 된다. ( 이는 기획력의 차이일 수도 있다. 왜 Facebook이 학교별로 가입자를 오픈하였는지 잊지 말자. )
4. 확장성에 신경쓰는 개발자.
대기업에서 뭔가 만든다면 트래픽, 보안뿐 아니라 확장성에도 신경써야한다. 프로젝트가 쉽사리 접히지 않기 때문이다. 그러나 스타트업계에선 확장성은 필요없다. 데모만들고, 서버 돌려보는 것이 가장 중요한 일이다. 그러다가 트래픽 몰리면 한밤중에 서버 내리고 모듈 교체하면 된다. 필자가 참여했던 한 프로젝트의 경우, php-mysql 을 쓰고 있었는데 개발팀장은 cubrid DB확장까지 고민하면서 프로그램을 짜고 있었다. 결국 사용자가 100명도 넘지 못했던 이 상용 웹 서비스는 빠르게 pivot 할 수 있는 기회를 잡을 수 있는 대신에 쓸데없는 개발리소스만 잔뜩 투입된채 우울한 시간을 보내야만 했다.
5. 너무 오래된 기술의 사용
개발자 한명이 추가로 투입되었다고 치자. 기존 소스를 어떻게 빨리 따라갈 수 있을까? 방법은 표준화를 하는 것이다. 이를 위하여 많은 모델들이 나와있다. MVC가 대표적 방식이다.
얼마전에 고벤쳐에서 필자가 직접 발표를 하기도 했었다. 지금 시대가 2012년인데 아직도 php를 쓰는 개발자가 많다. 물론 SNS사이트나 백엔드서비스와 같이 페이지 숫자가 많지 않은 방법엔 빠르고 간단하게 개발할 수 있는 php가 좋다. (필자도 다이어트헬퍼라는 앱 개발의 백엔드는 php를 사용하였다). php의 모듈 분리가 정확하게 될 경우는 상당히 인상적인 퍼포먼스를 보인다. 회사의 최고개발자가 php에 상당히 능숙하며, 소규모 개발팀을 운영하고 있다면 php는 좋은 선택이다.
그러나 요즘 신규로 출시되는 대다수의 서비스들 - C2C 마켓플레이스등 - 의 개발외주에서 php를 쓴다는 것은 납득하기 어렵다. 웹서비스 개발외주를 주었더니 코드 유지가 안된 분이 상담해오면 소스는 100% php로 되어있다. MVC툴도 적용되지 않는다. 이 경우 딱히 해줄 말이 없다. '코드 전부 갈아엎으세요. 외주 개발비 버렸다 치고 처음부터 다시하세요' .
6. 너무 앞선 기술의 사용
한 VC인터뷰에서 면접관이 물었다 한다. '요즘 가장 핫한 개발언어는 무엇인가' 쩔쩔매는 면접자에게 면접관이 말했다. '얼랭이지. 자넨 그것도 모르면서 VC하겠다고 하나?'
안좋은 케이스의 대표적 예로 너무 앞선 기술을 쓰려는 개발자나 기획자가 있다. 최근 얼랭에 대한 이야기가 나온다고 그걸 심각하게 도입하려는 기획자나 개발자는 자기 만족 이외에 아무것도 얻을 수 없을 것이다. 대체 그 코드를 누구에게 넘겨줄 것인가. 대표이사이자 최대주주이자 CTO이자 모든 개발을 혼자 하는 슈퍼프로그래머 정도 쓸 수 있을 것이다. 아니면 대기업정도. 남들 다 쓰는 Python, ruby, Obj-C, Java 써서 개발하면 된다. 한국 Go 언어(구글에서 개발한 언어)의 선구자는 먹고살고 또 여유시간있는 NHN이나 삼성전자 개발자들이 맡으면 된다.
남들이 쓰지 않는 기술은 아무리 좋더라도 쓰지 않는게 좋다. 그리고 가장 핫한 언어는 2002년이나 2012년이나 C언어다. ( Java도 Obj-C도 C 에 대한 이해 없이 쓸 수 있을지 의문이다. Ruby도 마찬가지다. )
안정성에 관한 문제도 마찬가지다. 어떤 개발팀의 한 개발자는 알파버젼의 리눅스를 쓰다가 서비스 릴리즈 한달여를 남기고 컴퓨터가 먹통이 되어 포맷해야되는 상황이 발생하였다. 자신의 일을 독립적으로 해야하며 상부통제는 개발문화에 반대된다던 이 개발자는. Git 서버에 업로드하라는 상부 지시도 무시한 채 열심히 개발하다가 소스를 모두 날려버렸다. 서비스 개발은 무기한 연장되었다. 이러한 일이 반복되자 회사는 결국 프로젝트를 포기했다. 책임없는 개발자의 전형적 모습이다. 농담일거 같은가? 최근 한 스타트업에서 발생한 실화 사건이다.
그렇다면 반대로 프로덕트를 살리는 좋은 개발자는 어떤 모습일까.
무엇보다 프로덕트를 제 시간에 맞춰 빨리 만드는 개발자다. 새로운 기술 적용한다고 시간 보내지도 않고, 너무 낡은 기술을 사용하지도 않는다. 기술들은 Git, WebFramework, Redmine 류의 ticket 시스템정도면 충분하다. 새로운 기술을 도입하기보단 이미 확실한 기술들을 조합하여 라이브러리를 구축한다. 형상관리툴은 github 에서 해결하고, 서버는 amazon ec2 정도 사용하면 충분하다. 이런걸 조합하여 목표까지 가장 빠른 개발 방식을 택하면 된다.
스타트업계 개발의 핵심은 encapsulation 과 code-reuse로 인한 빠른 개발이다. 성능의 최적화나 보안은 신경쓰지 않아도 된다 (어차피 기획되는 제품의 90%는 아무도 사용하지 않는다).
코드의 예를 한 번 보자.
만약 obj-c 에서 sqlite3 에 있는 메일 데이타를 가지고 온다고 생각해보자. 어떤 개발자는 sqlite3 라이브러리와 '?' 마크를 이용하여 일일이 데이타를 빼낼 것이다. 변수 설정하고, 일일이 테이블 확인하고, 바인딩해서 데이타 가져온다. 이는 가장 확실한 성능을 보일수 있지만 스타트업계에서 사용하기엔 좋지 않은 방법이다. 어떤 개발자는 코어데이타를 사용하여 코딩할 것이다. 그나마 나은 방법이라고 할 수 있다. 그러나 필자가 가장 추천하는 스타트업계의 코딩은 KVC를 이용한 encapsulation 이다. 다음은 실제로 필자가 DB에서 데이타를 가지고 오기 위하여 사용한 코드이다.
NSString *sql=[NSString stringWithFormat:@"SELECT * from messages where mailbox=%d", mailbox];
Mail *mail=[[Mail alloc] init];
NSArray *arr=[sqliteDb selectWithQry:sql object:mail];
프로그램에선 이렇게만 처리하면 라이브러리 레벨에선 DB칼럼 타입을 조사하고, DB필드명을 조사한다음 이에 맞는 데이터를 DB에서 가져오고, Mail Object를 필요한 수만큼 NSCopyingProtocol 을 사용하여 copy한다. 그 후에는 DB칼럼명과 동일한 오브젝트 변수명에 Key-Value를 이용하여 데이타를 입력한다. 라이브러리가 복잡한 대신, 어플리케이션의 코드량은 단 세줄로 끝나게 된다 (where 구문만 없다면 단 한줄로 처리할수도 있다. SQL도 내부에서 해결하면 되니까.). sqlite3 api를 사용하여 수십라인을 허용하는 것보다 훨씬 빠른 방법이다.
소켓 통신모듈은 어떨까. 어차피 뽑아져나오는 데이타가 동일하다면 아이폰-안드로이드-서버의 동시개발을 위하여 JNI의 도입을 검토할 수도 있다. 만약 아이폰과 서버는 C, 안드로이드는 Java를 채택하기로 했다면 최대한 소켓 규격을 표준화시키고 여기저기서 데이타 필드를 낭비하면서 강력한 Code Reuse를 하여 개발 스케쥴을 당겨야한다.
개인적으로 스타트업계의 기술과 대기업의 기술 방식은 상당히 차이가 있다고 본다. 스타트업계의 경우 성능을 돈으로 해결하는 프로세스가 맞다고 보며, 대기업의 경우는 인력을 돈으로 해결하는 것이 맞는 프로세스다. 대기업은 사람을 데리고올 수 있고, 마케팅이 확실하며, 제품에 신뢰를 잃지 않는 것이 중요하다. 그러나 스타트업은 신뢰를 잃지 않는게 중요한 것이 아니라, 실제로 제품을 만들고, 이런 제품이 있다는 것을 알리고, 제품이 돌아간다는 것을 보여주는 데에 모든 역량을 집중한다는 것이 옳다. 그 다음은, 그 다음에 생각해야한다. 한번에 여러 생각을 하면 단 한가지도 제대로 돌아가지 않는다.
1. 개발자를 번아웃시키더라도 일정관리를 확실히 해야한다. 안된다면 개발자를 교체해라. 모든 것은 일정이다.
2. 트래픽, 보안, 확장성등에 코드를 낭비하지말아라.
3. 너무 앞선 기술, 너무 뒤떨어진 기술을 쓰지말고 적정 기술을 유지하라.
4. 프로덕트의 레벨이 아닌, 기업의 레벨에서 인캡슐레이션과 코드리유즈를 실행해라.
그리고 이 사항들이 목표로하는 것은 단 한가지다. '빠르고 정확한 날짜에게 고객에게 제품을 배달한다. 그 뒤는 그 뒤에 생각하자.'.
이렇게 요약해보면 눈치채는 독자들이 많겠지만, 앞서 한 이야기는 사실 Lean Startup 개념의 MVP 모델과 매우 가깝다. 이번에는 앞선 논의를 여러가지 측면에서 재검토해보자. 왜 이런 MVP모델이나 필자의 논의들이 세상에 등장했는지이다.
1. 기획력의 실상이 드러남
먼저 필자가 중요하게 생각하는 것은 이것이다. 아무리 뛰어난 기획자라고 할지라도, 그 기획자가 내놓은 기획이 통할 가능성은 20%도 채 안된다라는 것이며, VC가 이 제품의 성공을 확신한다하여도 이 제품이 실제 성공할 확률은 50%를 넘길 수 없다는 것이다 (워렌버핏은 '당신의 판단의 51%만 맞더라도 당신은 월스트리트에서 억만장자가 될 수 있다는 말을 남겼다). 타자의 타율보다 낮은게 스타트업의 기획이다. 때문에 어차피 실패할 가능성을 애시당초 염두에 두고 움직이되, 기획자의 제품은 검증을 해야한다. 트래픽은 90% 의 확률로 문제를 발생시키지 않으며, 보안은 99.9%의 확률로 전혀 문제를 일으키지 않는다 (혹시 이전 모 정유회사에서 고객 개인정보가 대규모로 유출된 사례를 기억하는가? 박경철원장은 당시 고객 정보가 유출되었다고해서 기업가치가 하루아침에 5%나 폭락하는 것은 대중의 우매성을 보여주는 사례라 지적하였다). 확장성이 문제가 된다면 자금을 쏟아부어 코드를 처음부터 다시 짜면 된다.
그렇다면 왜 기획자는 기획은 보장 못하는 것일까? 이를 몇 가지 측면에서 살펴보자.
가장 먼저 논리 그 자체에서 찾을 수 있다. 인간의 논리로써는 그 어떤 현상도 확신할 수 없다. 우리는 보통 논리는 완전무결한 것이라고 생각하며, 논리에 뛰어나다는 전략컨설팅펌들에게 돈을 쏟아 붓는다. 보통 사람들은 논리가 맞으면 결과도 맞겠지란 가정을 한다. 그러나 안타깝게도 지금 우리가 쓰는 논리체계는 상당히 헛점 투성이이며, 우리가 논리로 알 수 있는 것은 '논리로는 사실을 파악할 수 없다는 사실' 뿐이다( 사실, 필자의 경우는 3단 논법 자체도 부정한다. ).
예를들어 눈 앞에 물과 같은 액체가 있다고 해보자. 우리는 이 액체가 물이라고 생각한다. 그럼 왜 이 액체가 물이라고 생각할까? 빠르게 우리의 머릿속에 물의 특성과, 다른 액체의 특성을 머릿속에서 대조할 것이다. 우리는 이 액체가 알코올도 아니고, 황산도 아니고, 우유도 아닌 것을 알기에 이 액체가 물임을 추정한다. 그렇다고 이 액체가 물이라고는 확신할 수 없다. 어떤이는 물임을 확신하고 부동액에 라면을 끊여막다가 횡사하신 분도 계시니까 말이다. 또다른 어떤이는 물임을 확신하고 부동액을 끓여먹었음에도 불구하고, 부동액을 소화시키는 비현실적으로 특이체질이라 자신이 마신것이 끝까지 물일 것이라고 생각할 수도 있다. 이런 문제때문에 과학의 근본은 '가정을 긍정' 하는 것보다 '가정에 대한 비판적 가설을 부정' 함으로써 결코 닿을 수 없는 진실에 한 발짝 가까이 감을 목표로 하고 있다. 고등학교때 확률과 통계시간에 가설을 증명하지 않고 null hypo(귀무 가설)을 부정하는 것을 떠올려보면 이해가 쉬울 것이다. 이에 관한 논의는 토마스 쿤이나 포퍼가 많이 전개를 하였으니 이런 분들의 글을 참조하길 바라며, 이제 이 팩트를 기획이나 전략과 연관지어 생각해보자.
기획의 예를 들어보자. 일반적인 기획 틀이다. "앞으로 A의 분야가 유망할 것으로 생각됩니다. 때문에 우리는 A분야의 B제품을 생산할 것입니다. 따라서 이 제품은 널리 퍼질 것이고, 상당한 금액을 벌어들일 것입니다"
이 예를 좀 더 구체적으로 바꿔보자. 다음 예는 얼핏보면 3단 논법의 중첩 형식처럼 보인다.
헬스케어 제품이 미래에는 유망할 것이다.
헬스케어 제품은 건강과 관련된 분야를 뜻한다.
뱀탕은 건강과 관련되어있다.
그러므로 뱀탕은 헬스케어 분야이다.
그러므로 뱀탕은 미래에 유망한 분야이다.
뱀탕에 대해 불확실성을 느낀다면 사철탕으로 바꾸어도 좋다. 한의학은 어떨까? 동양적인 삶은 세계적으로 인기를 끌고있고, 한류도 유망하다. 그러나 왜 한의계는 몰락하고 있을까? 물론 홍삼때문이고, 비아그라때문일테지만, 홍삼과 비아그라가 등장하기전의 정부 정책자들은 머릿 속에 홍삼과 비아그라의 팩터를 감안하여 미래에 필요한 한의생도들의 숫자를 계산할 수 있을까? 물론 불가능하다. 만약에 이것이 가능했다면, 여의도 애널리스트들은 손가락질을 받는 대신 떼돈을 벌고 있고, ROI 좀 볼 줄 안다는 VC들의 연봉의 자릿수가 지금 보다 세네자리는 많아야할 것이다.
또한 보통 기획서에 등장하는 논리들을 따져보면, 단어의 의미(시멘틱이라 이해하여도 좋다)가 상당히 어긋나있다. 앞선 예를 보면, 첫째 문장의 '헬스케어'는 섹터의 성장성으로써의 헬스케어를 말하는 반면, 네번째 문장의 헬스케어는 제품의 합집합의 의미의 헬스케어를 뜻한다. 얼핏설핏봐서는 구분이 안가지만, 두 단어는 다른 의미를 가지고 있다. 이는 단어의 의미가 문장에 종속되는 현상 때문인데, 이 때문에 논리는 추상적 세계에서는 완전무결하나 현실 세계에서는 상당한 제약이 있다.
그러나 실제로 우리는 많은 제품구성을 이와 같은 방식으로 전개한다. 투자도 이와같이 진행한다. 뉴스도 이런식으로 나간다. 알아두어야할 것은 이전에 필자가 설명하였던 '뉴스가 시세를 만든다'가 아니라 '시세가 뉴스를 만든다'는 팩트이다. 박원순 시장이 성과가 혁혁하다면 '트위터로 소통을 잘해서', '일을 추진력있게 밀어붙여서' 이고, 성과가 안나오면 '일할 시간에 트위터질만해서', '그러면서 불도저처럼 자기 주장만 고집해서' 이다. 모두 논리적이지 않은가.
때문에 논리로 전개하는 기획이나 전략은 제품이 시장에 나오기 전까지는 모두 '증명되지 않은 가설'일 뿐이다. 논리로 이 제품이 이런이유로 실패하지 않는다를 보여줄 뿐, 성공을 담보하진 못한다. 때문에 제품의 가설은 시장에서 검증받아야한다.
또 다른 이유는, 회사가 '관리능력' 이 아닌 '제품' 그 자체에 집중한다는 것은 언제나 몰락의 단초가 된다는 점이다. 회사의 기획서 형식이 기획서의 퀄리티를 결정한다 (또다시 마샬 맥루한을 생각해도 좋다, P&G를 머릿속에 그려도 좋다.). 경영학자 짐 콜린스의 표현을 빌리자면, 회사가 'what'때문에 성공했다고 생각하는 순간, 회사는 정체하고, 제품에 매이게 되지만 'how나 why'에 집중하였을때, 또다른 창의적인 제품을 만들 수 있고, 뛰어난 제품에 집중하는 대신 뛰어난 제품을 만드는 철학과 방식을 공유함으로써 앞으로 나아갈 수 있다.
따라서 기획이란건 상당히 모순된 존재일 수 밖에 없다. 회사는 좋은 기획을 탄생시켜야아하지만, 그것이 좋은 기획인 이상 좋은 기획이 되지 못한다는 슬픈 자기 모순에 갇히게 된다.
어쨌거나 결론적으로, 기획의 성공은 보장될 수도, 보장 할수도 없다. 좋은 기획은 실패확률을 줄여줄 뿐, 성공을 담보할 순 없다.
2. 개발 능력의 향상, 자금의 보장
2000년대 중반은 XP의 시대였다. 주당 40시간 개발과 PP라는 개념이 퍼졌고, 프로그래머들을 각종 번아웃에서 안전하게 지키자는 슬로건이 펼쳐졌다. 그러나 현재는 아무도 그런말을 하고 있지 않다. 애플의 초창기엔 주당 90시간을 일했다지만 저 장병규 아저씨는 주당 100시간을 코딩했다고 하고, 심지어 필자는 주당 110시간 일을 하지 않을바에야 삼성에 들어가는게 좋다는 말을 자주 하곤 한다.
2000년대 중후반은 IT의 암흑기라고 불릴만하다. 구글 IPO이후에 메이져사건이 터지지 않았다. 칼리 피오리나는 HP Way에 어울리지 않는 일들을 벌이다 회사에서 쫓겨나야 했고, 한때 애플과 어깨를 나란히했던 실리콘밸리 그래픽스는 몰락했다. 한때 삼성에게 회사를 사달라고 애걸하던 시스코는 MS와 시총1위를 두고 잠깐의 화려한 경쟁을 벌였으나, 곧 우울한 날들이 시작되었다. 구글의 성장이 위안이되었지만, 그만큼 야후의 시총이 주저앉았다. 화룡정점은 노텔의 공중분해였다. 필자가 창업을 결심한 그 즈음엔 IT업계에서 비보가 계속 날아오던 시기였다.
이 시기엔 돈이 돌지 않던 시기다. 기본적으로, 클래스는 영원하다. CMU나 스탠포드 유망주들이 택한 길은 맥킨지를 앞세운 전략컨설팅분야, BOA를 필두로 하는 은행권, 골드만삭스가 포진된 IB나 헷지펀드업계였다. 국내도 다르지않다. 과학고 - PKS 라인을 탄 많은 기대주들은 밋딧릿을 선택하며 치과의사가 되거나, 여의도 증권가로 향했다. 따라서 개발자들의 능력도 하향되었다.
더불어, 새로운 기획이 나오질 않던 시대다. SI업계를 중심으로 IT시장이 재편되었다. 국내는 더 말할 것도 없다. 이 시기에 꾸준한 성장세를 보여준건 삼성 SDS, LG CNS, SK C&C의 3대 SI 회사뿐이었다.
그럼 이 사실을 간단히 머릿속에 넣어두고 XP와 Lean Startup 을 비교해보자. XP가 중요시하는것은 개발자의 보호, Lean이 중요시하는 것은 MVP를 통한 가설 검증 시스템이다. SI에 있어서 중요한 것은 기획이라고 보기 힘들다. 이 제품이 아니면 쓸 게 없다. LG CNS가 그토록 자랑하는 대법원 전자시스템이 없다면 집에서 등기부등본 열람을 어찌할 수 있을까. 이 예에서 보듯, 2000년대 중반에 기업들이 집중하던 G2B 시장에선 기획이나 가설검증은 마이너한 요소가 된다. 여기서 중요한 것은 대규모 인원을 감안한 코드유지력이고, 모듈 분리능력이다. 일정관리는 중요하지만, 어쨌거나 죽이되든 밥이되든 제품은 나온다. 그리고 제품은 돌아간다. SI업계에 천재개발자는 많지 않다. 결국 중요한 것은 한명의 천재가 아니라 100명의 괜찮은 개발자들이고, 이 개발자들의 성능을 유지하는 것에 초점이 맞춰지게 된다. 번아웃안되고, 코드 관리를 잘하는 개발자들과 그 개발자들을 관리할 수 있는 능력이 핵심이 된다.
그러던 어느날 잡스가 대세남이 되었다. 새로운 플랫폼이 나오고, 돈이 몰려든다. 유망주들이 치과의사가 아니라 개발자를 택하기 시작했다. 심지어 몇몇 치과의사와 한의사들은 다시 개발직으로 회귀했다. 개발의 퀄러티가 상승했고, 돈이 돌기 시작했다. 이 돈은 빨리 들어왔다가 빨리 사라지는 돈이다. 유져만 모은다면, 투자가 진행되고, 스타트업은 어쨌거나 생존할 수 있는 환경이 만들어졌다. 이때에 해야할 일은 무엇일까. 실행력을 높여서 제품을 생산하는 일이 되었다. 2년뒤의 장기적(?) 플랜이나 PP, 코드 컨벤션의 중요성은 더 이상 중요하지 않는 시대가 왔다. 앞선 시대가 PL의 Readability 의 시대라면, 2010년을 기점으로 Writability 의 시대로 바뀐 것이다.
타자가 득점을 하려면 무엇을 해야할까? 1루에 나간 타자가 홈까지 들어올 확률은 50%도 채 되지 않는다. 어차피 홈까지 들어오는 것이 운이라면, 일단 안타라도 쳐서 누상에 나가야한다. 그리고 안타가 어차피 확률게임이라면, 타석에라도 많이 들어서야한다. 스타트업의 제품이 어차피 성공확률을 보장할 수 있다면 성공할만한 제품을 최대한 많이 출시해야한다. 그렇다고해서 아무거나 출시하란 말은 아니다. 타자가 안타를 치려면 쓸데 없는 공에 방망이가 나가선 안되듯이, 회사가 성공하려면 쓸데없는 기획에 손이 가선 안된다. 안타가 될만한 공을 쳐보듯이 (그래도 3할하면 잘하는 거겠지만), 스타트업도 될만한 기획을 계속해서 시도해보는 수 밖에 없다. (유명한 HP도 볼링장 센서도 만들고, 심지어 전기충격으로 다이어트를 하는 기계도 만들며 고난의 행군을 하지 않았던가).
개발자 자체의 퀄러티가 높아져서 XP에서 중시한 코드유지력에 대한 이슈가 많이 사그라들었으며, SI 보다 더 작은 규모로 더 큰 벨류에이션을 만들 수 있게 되었다. 그리고 스타트업의 숫자가 증가했다. 스타트업의 장점은 그들이 만든 기획이 통하면 큰 돈을 벌 수 있다는 것이고, 단점은 그들이 만든 기획이 통하지 않을 확률이 매우 높다는 것이다. 투자가들은 스타트업의 가설이 통하는지를 보고싶어한다. 만약 그 가설이 통한다면 아낌없이 돈을 쏟아부울 의향도 있다. 때문에 현재에 가장 중요한 개발 패러다임은 '가설 검증'이 되었다. 단위 시간안에 몇 개의 가설을 검증할 수 있느냐가 어찌보면 현재 UV가 없는 스타트업의 퀄리티라고 할 수 있을 것이다.
3. 기업 전체의 실행력 담보를 위하여
그러면 이 '단위 시간당 가설 검증력'을 높이려면 어떻게 해야할까. 가장 먼저할 일은 프로젝트당 최소한의 인원으로 움직이는 것이다. 어차피 가설이란 뻔하고, 그 가설검증까지 도달하는 인원이란 뻔하다. 개발자 한 명에 디자이너 한명이면 된다. 일전에 배기홍대표님이 4명이상 스타트업에 대한 비판적 의견을 내셨기도 하다. 인재가 부족한 것보다 더 심각한 것은 인재가 넘치는 현상이다. 사람이 할 일이 없이 붕 뜨면 쓸데없는 일을 벌이게 되고, 이는 탁상공론으로 이어져 결국 전투력 저하를 낳게된다. 가장 심각한 것은 중요한 포지션에 역량이 부족한 인재가 영입되는 것이다. CTO에 적당한 사람을 앉혀놓으면 뛰어난 사람을 데리고 오기 힘들어진다 (물론 모스코비츠와 같이 알아서 그 자리에서 사퇴한다면 서로 win-win할 수 있겠지만, 쉽지 않은 일이다). 삼성정도의 대기업이야 성실한 인재를 뽑아서 역량이 만개하기를 기대할 수 있겠지만, 벤쳐업계에서 이런 일은 미친 짓이다. 심지어 구글만하더라도, 인재를 회사안에서 키우기보다는 포지션에 딱 맞는 인재를 영입하는 인재정책을 성공요인으로 자랑한다.
대규모 인원을 유지하는 이상 커뮤니케이션 코스트가 발생하고, 생각할 거리가 많아진다. 검증해야할 가설이 '관악산 정상에서 서울시청이 보일까?' 라고 해보자. 그러면 지금 당장 관악산에 올라가서 확인하는 것이 가장 빠른 길이다. 그러나 어떤 사람들은 주변에서 관악산에 올라갔을만한 사람들의 프로파일을 분석한 다음, 인터뷰를 하고, 관악산에 올라가는데에 필요한 금액을 산정하여, 은행에서 출금하고, 중간중간 긴급상황에 대비한 보급로를 알아보고, 비상사태에 대비한 응급요원을 구한다음 올라가는 사람들이 있다. 누군가가 만약에 대통령을 보좌해서 관악산에 올라간다면 당연히 후자여야 할 것이다. 논리도 완벽하다. 산에 올라가는 것은 위험하며 생명은 돈으로 따질 수 없다. 그러나 이 논리가 옳은가?
스타트업도 그렇다고 본다. 몸을 작게 유지해야 실행력이 높아진다. 같은 의견에 동참하는 사람이 1명이든 10명이든 가설 검증 프로세스엔 아무런 도움이 되지 않는다. 오로지 답은 시장만이 알고 있으며, 스타트업이 할 수 있는 일은 실행력을 극대화시켜 경험치를 빨리 쌓는 것이다.
그렇다면 이와 유사한 사정이 B2B에서는 발생하지 않았을까? 물론 발생했다. 고객도 시장의 일부이므로, SE에서 말하는 프로토타입 개발 방법론이 바로 이런 개념들과 맞닿아있다. IT 초창기엔 고객이 A를 개발 요청했으니 A를 개발해줬다. 그러나 제품 납기를 완료할때쯤엔 고객이 자신이 원하는 것이 A+ 였다고 말했다. 이를 대비하기 위해서 일단 UI만 만들어놓고 손에 쥐어줘 본다던가하는 SE 방법론들이 등장했다. 필자는 자주 '스크린 샷은 만드는게 아니라 도트로 찍는 것' 이라고 한다. 고객이 진정으로 원하는 제품이 고객이 말한 제품인지를 최소한의 툴(목업이나 UI와 같은 ) 형식으로 만든다. 그 제품이 맞다면, 그제서야 엔진을 구현한다.
이 방법론은 실제 스타트업에서도 많이 응용할 수 있을 것이다. MVP 보다도 더 작게, 목업만 구현해서 소비자에게 쥐어준다음 반응이 오면 그제서야 개발에 착수한다던가 하는 방식일 것이다. 예를들어 Dynamic 한 데이타 변경 모듈을 제거하고 DB를 그냥 SQLITE로 디바이스 안에 넣은 다음에 소비자에게 쥐어주는 것이다. 그리고 이 방식의 장점은 우리 제품중에 어떤 feature 가 소비자에게 더 매력적인지 알 수 있다는 데에 있다. 다이어트 앱에서 소비자에게 중요한 것은 무엇일까? 대규모 DB? 물론 중요하다. 간편한 UI? 물론 중요하다. 그러나 실제로 고객에게 제품을 쥐어져보면 나오는 반응은 '비밀번호 기능 좀 넣어주세요' 이다. 여성은 서로서로 휴대폰을 빌려주는 일이 많으며, 이 때에 자신의 몸무게가 공개되는 것을 싫어하기 때문이다 (남자 기획자는 결코 알 수 없는 정보다). 만화가 강풀의 경우, 자신의 문하생을 통하여 '몸무게 입력이 두자리 뿐이라 쓰기가 힘듭니다' 란 피드백을 보내온 적도 있다 (몸무게 세자리가 주변에 없는 필자는 결코 생각해 낼 수 없는 이슈이다). 이와 같이 소비자의 피드백은 제품 기획에서 중요한 역할을 수행하는 경우가 많다. 때문에 소비자에게 조금이라도 더 빨리 제품을 전달해주는 것이 중요한 것이다.
'생산성' 카테고리의 다른 글
| [펌]혹시 당신도? 11가지 나쁜 리더십 행동 프로파일 (0) | 2015.03.19 |
|---|---|
| 프리젠테이션 태반이 지루한 이유··· 해법은 '작가 스타일' (0) | 2015.03.16 |
| 프로그래머가 알아야 할 97가지 (0) | 2015.03.07 |
| 부자들이 매일하는 20가지 (0) | 2015.03.06 |
| 왜 적은 인원으로 빨리 개발하나…개발문화의 비밀 (0) | 2015.03.05 |
