부제: 경영의 난제, 어떻게 풀 것인가?
  원제: The Hard Thing About Hard Things
  저자: 벤 호러위츠
  옮김: 안진환

  스타트업 대표를 거쳐서 지금은 경영의 구루라는 평을 듣고 있는 벤 호러위츠의 CEO 시절과 벤쳐 캐피탈 회사를 만들때의 이야기를 담고 있다. 실상 캐피탈 회사는 거의 부록에 가깝고, 주로 본인이 CEO 를 맡았던 시절의 난제를 담고 있다.

  나는 넘지 못했던 문턱을 넘어섰던 사람들을 만나는 요즘, 나보다 전에 내가 넘어서지 못했던 문턱을 넘어선 사람의 성공적인 이야기가 나에게 감탄과 묘한 씁쓸함을 전해준다.

  혹자의 평은 군주론을 IT 회사에 맞춰서 요약한 것, 회사 초창기의 대표들은 말이 안된다고 생각할지 모르지만, 연배가 있는 사업가들은 당연한 이야기네? 라고 끄덕거릴 만한 내용들이다.

  내 입장에서는 이런 내용을 이렇게 설명할 수 있는 능력에 감탄을 했다. 머리로는 알고 있지만 표현하기 어려운 부분을 잘 설명하고 있다.

  어려운 '자리'고 누구도 믿기 어렵다. 그리고 결단을 내리는 '자리'고 그 누구의 조언도 진심으로 나에게 맞지도 않는다. 다들 본인의 입장에서만 이야기를 한다. 전부 들어보고 판단을 해서 본인의 힘으로 결정을 내리는 '자리' 즉 CEO. 그래서 내린 결정이 맞아 들어가면 극한의 쾌감을 느낄 수 있다. 물론 실패했을때는 그 교훈을 뼈에 새기게 된다. 그만큼 어렵고도 중요한 '자리' 

  그런 '자리'에서 고민을 느끼고 있다면 일독을 권할 수는 있으나, 기술자로 창업을 한 입장에서는 책에서 다루는 고민은 어느정도 발전을 시킨 회사에서 할 만한 고민들로 이루어 졌다고 생각할 수 있다. 창업 한지 얼마 안되는 창업자는 저런 고민 같은 것도 사치다. 살기 위해서 총알이 빗발치는 전장을 뛰어다니는 입장일테니. 

이번에 회사에서 새로운 기능을 런칭했다. 내려오는 데이터 량이 좀 된다. 150K 정도 

스테이징 서버(한국에 있다)에서 혹독한 테스트를 거쳐도 문제가 없고, 론칭후 테스트에서도 별 이상이 밝혀지지 않았다. WI-FI 환경하에서도 동작을 잘하고 

문제는 내 폰에서 발생했다. 참고로 나는 SKT 폰을 사용중이다. SKT 의 LTE 환경하에서는 멈춘거처럼 동작하는 것이다. 150K 다.. 다시 말하면. 그정도 데이터를 내려 봤는데 멈춘다고? 

개발자를 소집해서 물어봤더니 전혀 안 느리다고 한다. 내 폰을 실제로 보여주니 개발자들이 다들 당황하는 것이다. 결국 이런 저런 테스트를 통해서 내린 결론은 SKT - LTE 가 완전 개 구리다는 것이다. 국내는 별 문제가 없으나 특히 해외가

KT, LG, WI-FI 망에서는 아주 잘 동작한다. 이렇게 쓰는 것도 웃기다. 겨우 150K 인데.. 

결국 SKT 의 LTE 환경이 개선되길 바라는 것은 코로나 19가 자연적으로 사라지길 바라는 것만큼 이루어지기 힘든 바람일테니, 우리가 패킷을 다이어트 시켰다. 1/3 로 줄였더니 시간이 많이 단축 됐다. 하.. 5G 시대에 150K 때문에 이런 난리가 일어나다니.. 

결론은 SKT-LTE 가 해외에 있는 서버랑 연결할때 극악의 효율을 보여준다는 것이다. 해외 서비스 준비할때 이런 것도 고려해야 할 것이다. 

저번 글에 관한 제 실제 사례 언급을 하겠습니다. 

패치 전략에 대한 단상에 대한 저번 포스트글

사실 이 외에도 많은 실제 사례가 있지만 이게 가장 최근의 사례 입니다. 

참고로 저는 KPOP 관련 회사에서 일하고 있습니다. 

1. 회사에서 라이브 방송의 필요를 이야기함.

 새로운 먹거리를 찾기 위해서 이거 저거 시도하는 중에서 나온 이야기 

2. 아마존 미디어 라이브를 이용해서 빠르게 구현

 클라이언트 작업량 말고 서버 단에서는 작업 자체는 그리 오래 걸리지 않음, SaaS 를 쓰면 좋은 점중 하나

3. 이슈 발생

 - 가격이 쎄다. 1채널 이용시 하루 대략 80만원 비용 나옴 

 - 송출 영상과 클라이언트 간의 영상이 대략 30초 딜레이 발생 (유튜브 12초, 아프리카 6초)

4. 직접 솔루션 만들기로 결정

 - 기존에 비싼 AWS 의 트랜스 코더를 직접 만들어서 비용 절감한 케이스가 있어서 생각보다는 쉬울거라 예상 

 - 결국 예상보다 훨씬 빠른 기간 안에 솔루션 완성

5. 베타 방송시 이슈 발생

 - 영상 송출시 윈도우 머신과 nginx 를 이용한 방식이 동시 분배가 안되고 한쪽에 영상이 안나오는 현상 발견

6. OSX 에서는 그런 현상이 발견 안되고, 윈도우에서 플러그인으로 해결하는 방식으로 해결

 - 송출하는 프로그램과 연결하는 프로그램에서 문제가 발생하는 것으로 원인 파악 

7. 두번째 베타방송시 기술적으로는 성공.

결론적으로는 아마존 미디어 라이브 이용시 하루종일 방송하는 것을 기준으로 할때 한달 방송 1채널 2400만원 , 6채널 일때는 1억 4천 400만원 가량 소요 예정 (방송 딜레이 30초)

새로 만든 솔루션을 이용할때는 하루종일 방송한다는 기준으로 한달에 200만원 가량 소요 예정 (방송 딜레이 7-10 초)

충분히 아이디어 단으로 기획이 충분하고 개발자들이 개발을 진행할 수 있을 정도로만 정리되는 기획과, 이용할 수 있는게 있으면 빠르게 제품을 제작해서 빠르게 기존 전략을 수정하며 개발 방향도 맞춰서 수정하는 쪽으로 대응하는 방식만으로도 시장 속도에 맞출 수 있게 된다는 것을 알게되는게 충분합니다. 

  저번 글 에서 언급했던 것과 같은 사례가 있어서 소개합니다.  바로 Boney M. 이라는 그룹입니다.

https://www.youtube.com/watch?v=l3QxT-w3WMo

  1974년, 독일의 대중음악 프로듀서 프랑크 파리안(Frank Farian) 이 흑인들이 나오는 수사물을 보고 영감을 받아서 노래를 한 곡 작곡합니다. 흑인 분위기만 날뿐 실제로는 프랑크가 노래를 직접 부르고 녹음해서 빠르게 앨범을 내 봤는데 이 앨범이 히트를 쳐서 여기 저기서 공연 요청이 쇄도 했다고 합니다.

  그래서 빠르게 자메이카 출신들과 다른 한명의 흑인들을 조합해서 그룹을 만들고 그 그룹으로 여기 저기 공연을 다니면서 엄청난 인기를 누렸습니다. 전설적인 그룹 아바 와 유럽 팝계를 양분했을 정도니 어마 어마한 인기였겠지요.

  게다가 그룹의 이름을 유지한 채 , 멤버들이 교체되면 계속 유지하는 전통도 만들어 낸 그룹이라고 합니다.

  빠른 기획 실행의 전형적인 과정입니다.

  재미 있는 아이디어 -> 빠른 기획 (거의 아이디어와 동시에 대충 이렇게 하면 되겠다 정도) -> 초 빠르 실행 (실행하는데 전혀 머뭇거리면 안됩니다.) -> 이슈 발생 (실제로 그룹이 존재하지 않는다) -> 패치 (그러면 그룹을 만들면 되지) -> 이슈 발생(멤버가 나감) -> 패치 (새로 뽑고 기존 멤버는 졸업이라 함 )

  이슈 큰 것만 꼽아 봤는데 긴 기간 동안 얼마나 많은 이슈가 있었을까요? 그 수 많은 이슈를 패치해 가며 그룹 (프러덕트)을 유지해 왔을 것입니다. 

  '계획적으로 살아라' , '너는 왜 아무 계획없이 사냐?', '사업은 기획에서 부터 다 결정된다.'

  나도 이 말을 맹신하던 시절이 있었다. 물론 아예 기획 없이 진행해야 한다는 것은 아니다. 사전 계획은 무슨 일이던 필수이다. 다만 탑-다운 방식으로 성대하게 계획을 하고 세부 계획까지 세우고 일을 진행하는 방식에 회의가 있다는 말이다. 
  
  예전 기록을 살펴보면 탑-다운 식 설계의 유명한 프랭클린 플래너도 샀다. 그리고 열심히 연초에 그 해의 할 일들 이루어 내야 할 일들을 적어내고 그 해에 그걸 지켜보려고 노력을 했다. - 예를 들면 다이어트 -  그리고 연말에 돌이켜 보면 연초에 열심히 계획했던 일이 하나도 지켜지지 않는 상황에 대한 자괴감도 컸던거 같다.

  즉.. 계획한대로 또는 기획한대로 일이 흘러가는건가에 대한 고찰이다. 물론 잘 지켜지는 사람에 대해서는 예외로 한다. 철저하게 나를 중심으로 생각하는 것이다. 나 자신도 내가 계획한대로 흘러가지가 않는데 여러 인격이 모인 팀이나 회사 입장에서 철저하게 세운 계획대로 흘러갈 수 있을까?

  수 많은 기업들이 최초의 계획대로 흘러가는 경우가 얼마나 될까? 본인이 다니는 회사에서도 성대하게 세운 계획하에 진행된 일 보다 시작은 가벼운 기획이 제대로 소비자의 관심을 끌어서 알아서 광고가 되는 경우가 있다.

  구글이 처음부터 지금 같은 회사가 되기를 계획했을까? 시작은 스탠포드 대학교의 검색 라이브러리 였다. 아마존은 지금과 같은 거대한 제국을 이루었을까? 그냥 도서 판매하는 사이트였다. 넷플릭스는 지금처럼 거대한 OTT의 최강자가 되리라고 초반에 DVD 대여 사업을 할 때 생각을 했을까? 페이스북은 하바드대학교의 미녀들 품평하는 사이트에서 지금같은 초 거대 SNS 의 강자가 될 수 있음을 계획했을까?

  가볍게 해외의 예만 적었지만 지금 합병된 카카오의 PC 포탈 플랫폼인 다음은 초창기에 구상했던 사업은 지금과는 전혀 다른 서비스였다. 거대한 IT 회사가 될 수 있게 해준 한메일은 여러가지 사업이 실패하고 재기를 꿈꾸던 포트폴리오의 가장 마지막을 차지했던 서비스였다.

  카카오는 어떤가? 카카오의 전 회사 이름은 기억도 나지 않는다. 카카오톡이 뜨고 나서 회사 이름까지 바꿨으니 카카오톡이 카카오가 진행한 프로젝트중 5번째 프로젝트다. 회사 창업한지 몇 년이 지난 후로 알고 있다.

  앵그리버드는 로비오 엔터테인먼트의 36번째 게임이였다.

  결론을 짜맞춘다고 볼 수도 있지만 결국 핵심은 '실행' 이였던거 같다. 가벼운 생각이 공상이나 망상에 그치지 않게 그 아이디어를 간단하게 기획하고 일단 실행을 하는 것이다. 그리고 상황에 맞게 거기에 '패치' 작업을 하는 것이다.

  패치는 개발 용어로 문제가 생긴 코드나 새로운 기능을 덧붙여서 기존 코드를 변경하거나 추가하는 행위를 말한다.

  왜 이래야 하는걸까? 현실이 너무 많은 변수가 있기 때문에 계획서에 다 담거나 계획서에 쓰여진대로 실행하다가는 현실의 변수를 무시 못하기 때문에 그 과정을 맞춰가며 바꾸다 보면 계획만 하다가 끝나는 경우가 너무 많기 때문이라고 본다.

  즉 머릿속에서 생각하는 환경 자체가 현실하고 동 떨어져 있는 경우가 정말 많다. 게다가 대중의 선택이라는게 그리 쉬운 일은 아닐것이고.

  주저리 주저리 말이 많았지만 하고자 하는 내용의 핵심은

  기획하는데 쏟아낼 수많은 에너지를 '실행'에 집중해라. 일단 '시작' 하고 상황이나 시장의 반응에 맞춰서 기획을 지속적으로 '수정'(패치) 하라.