본문 바로가기

일상/책 리뷰

실리콘 벨리와 엔지니어, 유튜브 창업이야기 - [유튜브 이야기] 독후감

유튜브 창업주 중 한명인 스티브 첸의 유튜브 창업이야기를 담은 책, [유튜브 이야기]를 읽었습니다. 최근에 유튜브 개발자 채널(데브원영)을 개설하고 컨텐츠를 만들면서 유튜브라는 플랫폼이 어떻게 만들어졌는지, 유튜브 플랫폼의 미래는 무엇인지 궁금하여 찾아 본 책입니다. 

 

유튜브 이야기

언론에 알려진 유튜브 대박의 비밀은 사실이 아니라는데…?전 재산 200달러 시작한 그가 20개월 만에 2조원을 벌었다?카드로 서버 비용을 대느라 급급했던 그는 왜 100억 원의 인센티브를 거절하고 구글을 박차고 나왔을까?2005년 2월 14일은 유튜브가 도메인 등록을 마친 날이다. 그때만 해도 유튜브가 이렇게 세상에서 가장 강력한...

www.yes24.com

이 책에서는 스티브 첸의 일대기를 전반적으로 설명하면서 페이팔 창업스토리, 유튜브 창업스토리 그리고 최종적으로 구글에 팔리게 될 때까지 모든 이야기를 담고 있습니다. 가장 인상깊었던 일부 내용을 이번 포스트에서 이야기 하고자 합니다.


실리콘 벨리와 엔지니어

서비스가 발전함에 있어서 엔지니어의 역할 및 태도 그리고 관리에 대한 묘사가 이 책에서 가장 기억이 납니다.

나는 우리 회사(유튜브)의 천재 엔지니어들이 새로운 기능을 개발하기 위해 얼마나 맣은 프로그램을 짰는지 기억나지 않는다. 아무튼 대단했다. 물론 낭비도 있었다. 창업 초기 유튜브에 존재 했던 최소 20개의 기능이 절반 정도 실행되다가 사라져버렸다. 
p.162

스티브 첸은 완벽한 1개의 기능보다는 불완전하더라도 창의적인 10개의 기능을 추가하여 그 중 3개를 성공시키는 것이 더욱 중요하다고 생각했습니다. 이것은 페이팔이 이베이에 인수합병되면서 겪은 이베이의 불합리한 의사결정 과정에서 비롯된 자신만의 확고한 철학으로 보여집니다. 

"이베이가 자동차라면 너는 작은 나사이고, 이베이가 공장이라면 너는 컨베이어 벨트 앞에 서 있는 일개 노동자일 뿐이야" 이베이의 관리방식은 내게 그렇게 말하고 있었다. ... 그 누구도 "이 부분은 이렇게 기능을 추가하고 또 이렇게 하면 좋겠다"라고 말 할 수 없게 되었다. 단지 위의 명령에 따라 움직여야 했다.
p.106

페이팔이 이베이에 합병된 이후에 엔지니어들의 창의성과 빠른 기능구현이 최우선 요소가 아니게 되었습니다. 이베이의 경영진들은 QA, 서비스기획, 시장조사와 같이 철지히 짜여진 프로세스와 '열차 출발'이라고 불리는 일정한 시간표로 프로젝트를 진행하는 것만이 성공적인 서비스를 만드는 길이라고 생각하고 프로세스를 벗어 나지 않도록 만들었습니다. 

당시 이베이에서는 3주에 한 번씩 그 '열차'를 출발시켰다. "이번 열차는 상품 매니저 1명, 엔지니어 3명, 디자이너 2명이 필요합니다"라고 하면 그에 따라 인원을 파견하고 3주내에 기능을 개발했다. 이 과정에서 엔지니어나 디자이너의 의견은 중요하지 않았으며 멤버는 언제든 교체될 수 있었다.
p.105

이러한 프로세스는 결과적으로 서비스의 성공/실패에 따른 책임을 전가하게 되는 요소로 자리잡게 되어버려 더 이상 서비스의 발전에 창의적인 생각을 더할수 없게 되었습니다. 그리고 명령에 따라 움직이는 나사가 된 엔지니어는 창의적인 개발은 뒷전으로 물러나게 되었고 점점 무료함에 빠져 나태해 지는 요인이 되고 말았습니다. 결과적으로 스티브 첸은 퇴사를 결심하게 됩니다. 스티브 첸(당시 24살)은 이미 페이팔을 이베이에 팔았기에 백만장자(200만 달러 가량의 주식 보유)가 되었지만 여기서 그치지 않고 또 창업을 결심합니다. 

(유튜브)창업과 더불어 내 생활은 완전히 달라졌다. 주말 따위는 존재하지 않고 낮과 밤으로 업무 시간을 구분할 수 없었으며 심지어는 하루를 24시간이라고 할 수도 없었다. ... 대략적으로 보면 24시간 일하고 10시간을 쉬는 패턴이 일반적이였다.

스티브 첸 뿐만아니라 초기 유튜브 엔지니어들은 1주일에 80시간 이상을 일했는데, 이렇게 일한 이유는 엔지니어들이 달성하고자 하는 창의적인 생각을 자유롭게 구현할 수 있도록 환경을 제공했기 때문입니다. 창의성에 제한을 두지 않은 엔지니어들은 자신의 열정에 불을 지펴 더욱 활활 타오르는 장작이 되어 초기 유튜브를 빛의 속도로 발전시키는데 큰 도움이 되었습니다. 스티브 첸과 창업자들은 엔지니어가 일을 하는데 있어 임하는 자세와 생각에 대해 정확히 이해하고 있었다고 볼 수 있습니다.

우리는 모두가 사이트의 전체 흐름에 대한 공동의 책임 의식을 가지고 새로운 아이디어가 있으면 주저 없이 말하는 분위기를 조성할 수 있었다. 이러한 조직 운영 방식으로 유튜브는 각종 기능이 빠르게 효율적으로 실현되는 곳이 되었다. 엔지니어들은 창의성에 불이 붙으면 놀랄 만 한 결과를 내고, 그럴 때 본인 스스로 행복감을 느끼기 때문이다.
p.160

엔지니어를 위한 환경

스티브 첸은 엔지니어를 위한 환경을 만들기 위해 다방면으로 노력하였는데요. 유튜브에서 운영하던 기업문화는 대부분 페이팔에서의 경험을 빌려왔습니다. 

유튜브를 창업한 후에 나는 페이팔의 초기 방식을 그대로 차용했다. ... 엔지니어들이 먼저 기능을 제안한 후 웹디자이너들과 의논하곤 했다. 그러면 역시 3일 만에 온라인에 적용될 수 있었다. 만약 상품매니저가 끼어 있었다면 새로운 기능이 실현되는데 얼마나 많은 시간이 걸렸을지 생각도 하기 싫다.
p.85

재미있는 점은 유튜브를 운영하면서 엔지니어의 방대한 아이디어를 일부 Cut할 필요가 있음을 알게 되었고 필요없다고 생각했던 직군을 다시 만들어 적용하기도 하였습니다. 조직의 변화에 따라 유연하게 직군이나 프로세스를 바꾸는 노력도 필요하다는 것을 알 수 있습니다.

나중에는 상품 매니저의 역할도 일정 부분 수긍하게 되었다. 그것이 없으면 엔지니어들은 아이디어가 너무 많기 때문에 그 가운데서 실현 가능한 것만 골라내어도 일이 훨씬 효율적으로 돌아갈 수 있었다.
p.86

초기 유튜브가 성장할 때는 빠른 기능 확장과 실패에 대한 부담감을 줄이기 위해 QA를 제거하는 과정도 인상적입니다.

독립된 QA팀은 아예 두지 않았다. 늘 새로운 것을 추구하는 유튜브에서 테스트팀은 시간 낭비에 불과했고, 결과물에 문제가 생겼을 때 직원 간에 책임을 떠넘기는 빌미가 될 뿐이었다. 그 결과는 모두가 사이트의 전체 흐름에 대한 공동의 책임 의식을 가지고 새로운 아이디어가 있으면 주저 없이 말하는 분위기를 조성할 수 있었다.
p.160

유튜브가 빠르게 성장할 수 있는 원동력 중 하나인 엔지니어 중심의 개발(EDD:Engineer Driven Develop)이라는 것을 볼 수 있습니다.


결론

스티브 첸은 엔지니어로서 뛰어난 역량을 가지고 있으면서도 엔지니어의 needs를 잘 파악하여 창업자로서 회사가 빠르게 성장할 수 있는 환경을 만들었습니다. 이러한 노력은 최종적으로 '유튜브'라는 세계 1위 동영상 플랫폼을 만드는 원동력이 되었습니다. 이러한 환경은 실제로 우리가 현업에서 개발 할 때 자주 느끼게 됩니다.

나사가 된 듯 단순히 기능들을 뚝딱뚝딱 만들어내도록 강요받는 조직에서는 많은 개발자들이 무료함과 많은 일에 치여 번아웃되기 십상입니다. 반면 자유롭게 토론하고 개선할 수 있는 여지가 주어진 조직에 있을 경우 주인의식을 가지고 서비스의 발전을 위해 의견을 내고 더 나은 기술적 제안을 위해 노력하는 모습을 주변에서 흔히 볼 수 있습니다. 

물론 모든 조직과 모든 개발자가 유튜브의 사례에 적합하다고 단언하기는 힘듭니다. 그러나 창의성을 제한하고 정해진 기능만 일정 시간내에 만드는 과정이 반복된다면 훌륭한 IT서비스로 발전하는데에는 한계가 있다고 분명히 말할수 있습니다. 딱딱한 프로세스에 갇혀 있고 정체된 조직에 있는 느낌이 드신다면 이 책을 꼭 한번 읽어보고 변화를 통해 더욱 성장하는 조직 그리고 엔지니어가 되어 보는건 어떨까요? 마지막으로 스티브 첸이 엔지니어를 매니지먼트 하면서 느낀점을 아래에 남기면서 포스트 마치겠습니다.

 

엔지니어팀을 관리하는 것은 일종의 에술에 가깝다. 팀원 개개인이 하나같이 천재인 데다 그들 스스로도 그렇게 알고 있기 때문이다. 엔지니어에게 충분한 시간과 여유를 주어야 한다. 이는 페이팔 초기에 이미 효과가 증명되었다. 이후 나는 유튜브에서 그렇게 했으며 구글에서도 마찬가지 방식을 취했다. 물론 관리자가 팀원을 존중만 해서는 안된다. 그래서 관리와 커뮤니케이션의 난이도를 결정해주는 구조가 반드시 필요하다.