프리이미지
사이트 내 전체검색

프로젝트를 망치는 개발자, 살리는 개발자 2 [출처] 프로젝트를 망치는 개발자, 살리는 개발자 2|작성자 보통 개발자

페이지 정보

작성일13-07-01 02:43

본문

앞선 논의를 요약해보자.

 

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? 물론 중요하다. 그러나 실제로 고객에게 제품을 쥐어져보면 나오는 반응은 '비밀번호 기능 좀 넣어주세요' 이다. 여성은 서로서로 휴대폰을 빌려주는 일이 많으며, 이 때에 자신의 몸무게가 공개되는 것을 싫어하기 때문이다 (남자 기획자는 결코 알 수 없는 정보다).  만화가 강풀의 경우, 자신의 문하생을 통하여 '몸무게 입력이 두자리 뿐이라 쓰기가 힘듭니다' 란 피드백을 보내온 적도 있다 (몸무게 세자리가 주변에 없는 필자는 결코 생각해 낼 수 없는 이슈이다). 이와 같이 소비자의 피드백은 제품 기획에서 중요한 역할을 수행하는 경우가 많다. 때문에 소비자에게 조금이라도 더 빨리 제품을 전달해주는 것이 중요한 것이다.

 

추천 0
게시물 검색