sangminpark에 관하여

Software Engineer at Eucalyptus Systems. Father of two lovely girls. Living in Seattle, Washington smpark.uva@gmail.com

집에서 일하기

전에 이야기 했는지 모르겠지만 난 집에서 일한다.

얼마전 평소와 같이 일하는데 7살 딸 아이 (샬롯)의 친구가 놀러왔다. 코딩하다가 커피 마시러, 과자 부스러기를 담으려 주방을 왔다갔다 하는 나를 보며 아이의 표정이 약간 일그러졌다. 그리곤 물었다: “Are you Charlotte’s brother? (샬롯 오빠예요?)”. 내가 약간 동안이긴 하지만 전형적인 폐인 너드몸매의 소유잔데 오빠라니…그 아이는 낮 시간에 집에서 왔다갔다 하는 남자 어른을 도무지 이해할 수 없었던 모양이다. 난 그냥 고맙다고만 얘기했다.

나는 자주 큰애, 작은애를 학교에 등하교 시킨다. 등교 시간엔 출근길에 아이를 내려주는 아빠들이 제법 있어서 괜찮다. 문제는 오후 2시쯤 하교 시간이다. 코딩하다 시간되면 평소 작업복인 아디다스 삼줄 추리닝에 두손 집어넣고 학교로 어슬렁 걸어간다. 그러다보면 역시 아이를 픽업하러온 엄마 부대를 마주치게 된다. 평소 안면만 있는 한국 엄마들과 눈이 마주칠때면 얼른 눈길을 돌린다.  ‘저 아줌마는 매일 낮시간에 나오는 날 어떻게 생각할까?’. 엄마들 표정도 약간 당황해 하는 것 같다. ‘저 노는거 아니예요!!’ 소리는 마음에서만 맴돈다. 우리 집에 처음오는 사람들에게 날 소개하며 아내는 꼭 집에서 <일하는>거라고 강조한다. 부끄러워하는것 같다…그래서 손님이 갈때까지 오피스에 숨어있게 하는거겠지.

집에서 일하는 사람의 일상

이런것들이 집에서 일하면서 겪는 일상이다. 이런 방식으로 일한지 이제 2년이 되었다. 지금은 출퇴근 해야하는 직장으로는 다시 돌아갈 수 없을만큼 적응됐고 이 생활이 좋다. 시애틀에 2년전 이사오면서 집의 한 공간을 아래 사진과 같이 오피스로 꾸몄다. 오피스 안에는 프로그래밍 작업을 위한 모든 것이 구비되어 있다. 여러대의 서버, 넷웍 장비, 맥북, 잠잘 수 있는 소파, 두루마리 휴지,.. 심지어 한쪽에는 사우나실도 있다.

IMG_20131124_090218[우리집 한 구석에 마련한 오피스]

원래는 나만의 공간인 오피스로 꾸미려 했는데 어쩌다보니 오피스 메이트가 생겼다. 역시 집에서 대부분 시간을 보내야 하는 세살 짜리 친구 <클라라>인데 잠옷만 입고 다닌다. 지금 블로그를 쓰고 있는 이 순간에도 옆에서 병원놀이 하자고 졸라댄다. (잠깐 놀아주고 더 써야겠다…)

1009331_639629386065773_1242507798_o

[내 오피스 메이트. 잠옷만 입고 다닌다.]

아침에 일어나 대충 추리닝 걸쳐입고 커피 한잔과 베이글 한개 들고 출근(?)해 회사 이메일을 읽는 것으로 하루를 시작한다. 중요한 이메일만 우선 답장을 보낸다. 그리곤 당연히 다른 직장인들이 다 그렇듯 업무는 잠시 미루고 한참 웹서핑을 한다. 트위터, 뉴스, 블로그들을 돌아보면 시간이 잘 간다. 가끔 아내가 들어와 일 잘하나 살펴보는데, 혹 놀고 있다는 걸 들키면 <클라라>를 방에 풀어 놓기 때문에 조심해야 한다. 그렇게 한참 놀다가 지겨워지면 코딩을 시작한다. 코딩하는 동안은 시간이 빨리 지나간다. 일주일에 서너번 전화로 팀미팅이 있다. 가끔 화장실에서 집중하며, 설겆이하면서 미팅을 할때도 있는데 뭐 조금 미안하긴 하지만 괜찮다. 중간 중간 아이와 놀아주기도 하고, 집청소도 하고, 골프 연습장도 다녀오면 하루가 금방 지나간다.

새로운 형태의 조직

우리 회사 유칼립투스의 직원중 약 80% 정도는 이렇게 집에서 일한다. 우리 회사만 아주 특이한 것이 아니다. 워드프레스를 만드는 오토마틱 [1], Ruby on Rails를 만든 David Hansson의 회사 37Signals [2], 그리고 현재 우리 CEO의 전 회사 MySQL [3] 모두 직원의 대부분이 집에서 일한다. 내가 이전에 잠시 일했던 스타트업 Fancy.com은 많은 개발자가 한국에 있는데 역시 모두 집에서 일한다. “재택근무”가 주는 어감은 여전히 <집에서도 부업으로 할 수 있는 000!>라는 스팸메일처럼 다소 2류 문화를 내포하지만, MySQL, 워드프레스, 유칼립투스 모두 소프트웨어 업계의 떠오르는 샛별들이다. 작년 야후가 집에서 일하는 직원들을 모두 해고해 비판을 받았을때, 언론들은 새로운 형태의 조직으로 우리 회사와 워드프레스를 소개해 많은 호평을 받았다.

집에서 일하는 것의 가장 큰 혜택은 자유다. 위에서 설명했듯 우리 회사는 직원이 어디에서, 어떤 시간에 일하든 문제가 없다. 원하면 어디로든 이사갈 수 있고, 여행을 다니며 일해도 상관이 없다. 우리 직원중 한 사람은 사람이 살지 않고 인터넷도 안 들어오는 깊은 산속에서 밭을 일구어 살며 위성 인터넷으로 접속해 일을 한다. 어제는 집 앞에서 만났다고 쿠거(산 사자) 사진을 회사 전체 메일로 보내기도 했다. 아직 회사에서 이 직원의 얼굴을 본 사람이 없다. 나는 골프를 좋아해 주중에 하루는 꼭 라운딩을 나간다. 아침일찍 나가도 점심을 먹고서야 들어오는데, 남들 다 일할때 노는 것만큼 신나는게 없다. 아마 오피스를 나가야 한다면 이런 생활은 포기해야 할거다. 회사가 주는 이런 자유는 직원을 채용할 때 아주 강력한 미끼다. 실력있는 개발자에게 자유만큼 매력적인 것이 없으니까.. 

재택근무를 영어로는 흔히 “Remote employment” 로 지칭한다. 하지만 유칼립투스나 워드프레스는 스스로의 조직 형태를 “Distributed workforce”로 부른다. Remote employment는 헤드쿼터 오피스를 중심으로 매니저가 집에서 일하는 소수의 직원(remote)들을 관리하는 측면이 강하지만, Distributed workforce는 애초에 헤드쿼터라는 물리적 오피스의 개념이 없이, 전세계에 분산되어 일하는 사람들로 구성된 조직이다. 유칼립투스는 CEO부터 거의 모든 임원들까지 각 주에 흩어진 자신의 집에서 일한다. 종종 나 자신도 궁금한것은 이렇게 전세계에 분산돼 자유롭게 일하는 사람들로 구성된 조직이 어떻게 좋은 성과(Performance)를 낼수 있을까 하는 점이다. 앞에서 언급했듯 워드프레스나 유칼립투스 모두 업계에서 가장 영향력있는 소프트웨어를 만드는 조직이다. 단순히 일하는 시간만을 계산한다면 사실 일반 회사들에 비해 많지가 않다. 이들은 오피스에서 긴밀히 얼굴을 마주대고 회의를 할수도 없다. 회식자리에서 만드는 끈끈한 동료애도 기대할 수 없다.

아마 탁월한 동기부여 (motivation)가 답이 아닐까 생각한다. 워드프레스, 37signals, MySQL, 유칼립투스의 공통점은 모두 오픈소스에서 시작한 회사라는 점이다. 집에서 일하는 것은 오픈소스 개발자들의 원래 삶의 방식이다. 폴 그레이엄은 낮에는 밥 벌이를 위해 일하고, 밤에는 진짜 자신의 아름다운 소프트웨어를 만드는 오픈소스 해커를 “낮 일” 하는 사람들이라고 불렀다 [4]. 폴그레이엄이 <해커와 화가>를 썼던 10여년전에는 오픈소스 해커들이 진부한 낮일과 진짜 밤일을 분리해야 했다. 하지만 이제는 오픈소스가 소프트웨어의 주류로 자리잡으며 낮일과 밤일을 구분지을 필요가 없어졌다. 집이 회사고 해킹(밤일)이 직업이다. 오픈소스 해커들에게 “아름다운 소프트웨어를 만드는 것”이 본업이 되었을때 나타나는 퍼포먼스는 매니저에 의해 잘 관리되는 구식 소프트웨어 회사의 조직을 압도한다. 혹 미심쩍다면, 집에서만 일하는 사람의 퍼포먼스를 어떻게 평가 할 수 있을까 생각해보면 된다. 사무실에선 책상에 앉아만 있어도 기본은 먹어준다. 집에서 일하는 사람은 오직 한가지 “코드”로만 평가 받는다.

개인적으로 오픈소스 회사에서 일하며 가장 기쁜 것은 가족과 보내는 시간이다. 아이가 옆에서 떠드는데 일이 되느냐고 사람들이 종종 묻는다. 하지만 그렇게 방해받아도 괜찮다. 막 유치원을 마치고 달려와 내미는 딸아이의 어설픈 그림 한장이 주는 기쁨이 훨씬 크니까. 실제로 적막한 가운데서 코딩하는 것보다 아이들이 옆에서 뛰어 놀때 더 즐겁게 일이 잘된다. 아마 아름다운 음악을 듣고 감동받을때 나오는 주체못할 터보 코딩과 같은 이유일 것이다. 그래서 전화로 하는 팀미팅에선 직원들의 아이들 웃고 우는 소리가 배경음으로 깔린다. 매일 출근했더라면 놓쳐버렸을 아이들의 커 가는 순간 순간을 지켜볼 수 있는 것은 행운이다.

몇가지 관리의 팁

집에서 일하는 사람들로 구성되다보니 오피스에서 일하는 회사들과는 다른 방식으로 소통하고 조직을 관리한다. 그중 몇가지 팁만 소개해본다.

  • 지역 모임: 프로젝트를 시작할때는 대화가 많이 필요하기 때문에, 몇달에 한번 팀 단위로 도시를 돌아가며 모임을 갖는다. 시애틀, 뉴욕, 샌프란시스코등 팀원이 살고 있는 도시로 모여 일주일 정도 오피스를 렌트해 회의하거나 코딩한다. 우리보다 좀 더 갑부인 오토마틱경우는 그리스, 도쿄등 전 세계를 돌아다닌다고 한다 [1].
  • 전체 모임: 큰 오피스를 유지하는데 필요한 비용을 줄이고 대신 그 돈으로 전 직원이 모이는 워크샵 (All-hands meeting)을 괜찮은 여행지에서 갖는다. 우리는 LA 근교의 휴양지에서 주로 모임을 갖고, 오토마틱경우는 전 세계의 휴양지를 돌아다닌다고 한다 [1].
  • 커뮤니케이션: 거의 모든 커뮤니케이션이 이메일, 채팅등 온라인에서 이루어진다. 오피스에 나와 일하는 사람들도 예외가 없다. 바로 옆자리에서 일하더라도 irc 채팅방에서 질문하고 대답해야 한다. 오픈소스회사의 핵심은 투명성이다. 거의 모든 회사의 미팅을 외부에 공개된 irc 채팅방에서 하고, 발표는 외부로 스트리밍 한다.
  • 투명성: 매주 월요일 임원들은 전 직원에게 자기 부서의 상황을 보고해야 한다. CEO는 한주간 누구를 만나서 무슨 이야기를 했는지 보고하고, 세일즈 임원은  몇개의 라이센스를 팔았는지 공개해야한다. CFO는 전 직원에게 현재 회사의 통장 잔고가 얼마인지 공개한다. 눈을 마주보고 이야기할 수 없기 때문에 회사는 직원에게 더 정직해야 한다.
  • 회식: 직장의 꽃 회식은 가족이나 친구와 함께한다. 중요한 프로젝을 마치는등 이벤트때마다 가족, 친구들과 나가 회식하고 영수증을 회사에 제출하면 된다.
  • 개발 장비: 개발팀의 컴퓨터 장비에는 돈을 아끼지 않는다. 팀원들은 여러대의 서버를 집에서 돌리고, 맥프로 레티나등과 같은 최신 노트북을 지급받는다.

이처럼 집에서 일하는 회사 조직이 모든 경우에 맞지는 않을 것이다. 하지만 스타트업, 특히 소프트웨어, 서비스분야에서 시작하는 회사에서는 시도해 볼만한 가치가 있다고 생각한다. 아침, 저녁으로 낭비하는 출퇴근 시간을 가족과 함께 보내거나 자신을 위해 소비한다면 그것만으로도 가치있는 일일것이다. 하지만 한가지 주의할것은 조직의 구성원이 자신의 일을 자기 가족만큼 사랑해야 한다는 점이다. 오픈소스를 하는 사람들에겐 일과 삶의 구분이 없다. 코딩은 삶의 일부고 아이들은 그런 아빠의 모습을 집에서 보는게 자연스럽다. 놀다가 코딩하고, 코딩하다가 노는게 우리 삶의 방식이다. 구성원이 코딩을 직업으로만 생각해 코딩과 삶을 공간적, 시간적으로 구분짓고자 한다면 아마도 우리의 이 방식은 맞지 않을 것이다.

[1] http://www.businessinsider.com/automattics-awesome-remote-work-culture-2013-8
[2] http://www.forbes.com/sites/danschawbel/2013/03/29/david-heinemeier-hansson-every-employee-should-work-from-home/
[3] http://www.entrepreneur.com/article/228752#
[4] 해커와 화가-2

아이디어 생각 안하기

들어가며

난 어려서부터 코딩한 그런 창조적 아이는 아니었다. 그저 98년 당시 가장 쿨했던 전공 컴퓨터공학(지금은 상상 안가겠지만..) 에 발 담궈봤을 뿐이다. 처음 1년간은 C 프로그래밍이 너무 어려워 학점이 계속 “씨 씨” 욕을 해댔다. 1년정도 지났을때 좀 색다른 경험이 있었다. 교회의 젊은 전도사님이 어느날엔가 잡지책을 한권 펴 놓고 끙끙대고 있는걸 봤다. 무엇을 하시느냐 묻자 잡지사의 상금이  걸린 퍼즐 문제를 푼다고 했다. 그분은 사실 좀 많이 가난했었는데 거기에 진심으로 희망을 걸고 계신 듯 했다. 그런데 문제들중 딱 한가지만 모르겠다고 울상이었다.  퍼즐은 숫자가 나열되어 있고 중간 중간에 비어있는 연산부호를 넣어 결과 숫자를 만들어내는 문제였다. ‘안 어려워 보이는데?’ 생각했지만 한참 끙끙대도 조합이 안 나왔다. 가능한 연산자의 조합이 수도 없이 많으니 당연했다. 그러다가 언뜻 머릿속을 스친 생각이 ‘가만..코드로 짜면 그 많은 조합을 컴퓨터가 할 수 있잖아?’. 막상 코딩하는데는 몇분 안 걸렸고 프로그램은 곧바로 답을 찾아냈다. 이 모습을 곁에서 지켜보던 전도사님은 눈이 휘둥그레져, 과장하자면 마치 홍해가 갈라지는 것을 목격한 사람처럼 흥분했다. 그 주 내내 만나는 사람마다 “저사람 천재”라고, 심지어는 설교중에도 토해내던 흥분이 다음 호 잡지의 당첨자 목록에 본인 이름이 없는걸 확인한 후에야 멈췄다.

두뇌의 조작질

작은 에피소드를 아직 기억하는 이유는 내 코드가 어떤 사람의 중요한 문제를 해결한 첫 경험이기 때문이다. 그전에 학교에서 해오던 숙제, 프로젝트는 매년 반복되는 이미 정답이 정해진 훈련이었다면 그날의 코딩은 일상에서 맞닥뜨리는 살아있는 문제를 해결한 것이다. 요즘 종종 블로그를 읽고 일개 프로그래머인 내게 스타트업 아이디어를 상담해오는 분들이 있다. 대부분 재미있고 신선하다. 그런데 거의 모든 경우 슬라이드를 다 읽고 난 후에도 그 아이디어가 어떤 문제를 해결하는지 알수가 없다. 많은 경우 본인의 아이디어가 “새롭다” 또는 “지금껏 없었다”라고 이야기 한다. 그말이 맞다. 새롭다. 하지만 새로운 아이디어는 무한대로 만들어낼수 있다. 트위터에 한글자 더 추가해 141 글자를 가능케 하는 것도 아이디어고, 139자로 제한하는 것도 아이디어다. 다만 아무도 원하지 않을 뿐.

폴 그레이엄이 “스타트업 아이디어”에서 지적했듯 아이디어에서 시작하는 것은 너무도 위험하다 [1]. 무한한 아이디어의 바다에는 반짝이는 돌들이 너무 많아서 우연히 예쁜 돌맹이 하나를 집어들고 진주라고 믿는 경우가 많다. 스타트업을 꿈꾸는 나는 종종 아침에 샤워하다가 혹은 밤늦게 뜨거운 욕조에 누워 생각하다가 깜짝 놀랄 쿨한 아이디어가 생각나곤 한다. 흥분된 마음에 검색을 해보고 아직 아무도 시도하지 않았다는 걸 알땐 가슴이 벌렁벌렁 한다. 우뇌는 어떻게 구현할까 생각하고, 좌뇌는 벌써 빌게이츠집에 놀러가 있다. 생각의 그 다음단계는 쿨한 아이디어가 해결하는 문제를 “창조”하는 것이다. 사람들은 이러 이러한 문제를 겪고 있는데 내 아이디어가 그들의 문제를 해결해 줄 것이라 가정한다. 생각이 더 깊어지면 창조해낸 그 문제가 내게 그동안 고통이었다고 믿기 시작한다. 문제가 주는 고통이 심하다고 믿으니 아이디어는 더 빛나 보인다. 이 스타트업은 대박이다!

gollum

하지만 냉정하게 돌아보면 결국 두뇌의 장난질이다. 아이디어를 떠올리기 전까지는 사실 그 문제가 쓰라려본 적이 없다. 아이디어를 정당화 시키기 위해 두뇌가 한 조작질에 또 한번 당했을 뿐이다. 아이디어를 갖고 싶어한 그 순간부터 내 두뇌는 내 편이 아니다.

문제부터 생각할때

성공한 스타트업은 모두 문제에서 시작한다. 트위터의 창업자지만 세력 다툼에서 밀린 잭 도시(Jack Dorsey)는 Square라는 모바일 페이먼트(Payment) 스타트업을 다시 시작해 현재 적어도 3조원 이상의 가치를 평가 받는다. 잭 도시는 물건을 살 때마다 이런 질문을 했다. “왜 지금 내가 지갑에 손을 가져가 신용카드를 꺼내야 하지?” “왜 카드가 승인나서 영수증이 나올때까지 어색하게 서서 기다려야 하지?” “왜 또 나는 영수증에 사인해서 다시 돌려주고, 카드를 넣은 지갑을 다시 주머니에 집어 넣어야 하지?” [2] 보통 사람들은 당연하다고 생각한 결제의 과정이 잭 도시의 일상에서는 괴로움이었다. 아마도 리누스 토발즈가 본인을 ‘게으름뱅이’라고 지칭한 이유와 같을 것이다. 대부분 사람들에겐 익숙한 삶의 방식이 창업자들에겐 너무 귀찮고 불 필요해서 코딩으로 해결해야하는 문제로 보인 것이다.

사실 잭 도시, 리누스 토발즈 같은 “난 놈” 들에게만 그런 문제가 보이는 것은 아니다. 때론 누구나 알고 있는 문제를 다른 이유로 해결하지 못하는 경우가 많다. 이번주 미국에서는 홈조이라는 집 청소 스타트업이 약 400억 이상의 펀드를 받았다 [3]. 창업 1년만에 꽤 많은 매출을 올리는 알짜배기 스타트업으로 알려져 이곳 기준으로도 큰 펀드를 받아낸 것이다. 홈조이는 깔끔한 웹 페이지에서 집 청소를 요청하면 미국의 대도시에 있는 청소 업체들을 연결해 청소부를 파송한다. 스스로 청소부를 고용할 필요도 없고 홈페이지 하나 예쁘게 만든다니 마치 대동강 물 팔아먹은 봉이 김선달마냥 기발해 보인다. 그런데 꼭 그런 것일까? 아래는 홈조이의 창업자 Adora Cheung의 트윗에서 발췌한 것이다. 청소부들과 함께 추수감사 식사후 찍은 사진이다.

피부색도 사회적 클래스도 완전히 다른 청소부 사회에 들어가 그 업체들과 네트웍을 만들만한 용기, 적극성을 가진 프로그래머가 얼마나 될까? 실제 Adora Cheung은 인터뷰에서 본인이 청소부로 일했던 경험이 중요했다고 얘기했다. “집청소” 혹은 “청소부 고용” 이라는 문제는 아마도 몇천년의 역사를 가진 누구나 아는 문제인데 그걸 인터넷으로 가지고 온 것은 홈조이가 처음이다. 때론 문제를 알지만 해결할 용기가 없을 뿐이다. 비슷한 다른 예로 Stripe라는 페이먼트 스타트업이 있다 [4]. 수없이 많은 프로그래머들이 자신의 프로그램을 온라인에서 돈 받고 파는 그 과정을 고통스러워했다. 하지만 누구도 해결하려 들지 않았다. 코딩은 자신 있지만, 금융회사를 상대하는건 상상도 못할 일이기 때문에. 그걸 처음 시도해 의외로 쉽게 문제를 해결하고 페이먼트 서비스를 만든것이 Stripe 이다. 모든 프로그래머가 고통을 느꼈지만 금융회사의 문을 한번 두드려볼 용기는 없었다.

그래서 어쩌라고?

아이디어라는 단어를 떠올리는 순간부터 두뇌는 스스로를 속이기 시작한다. 그대신 우리 주변에 있는 문제를 발견하면서 스타트업은 시작된다. 때로는 홈조이, Stripe의 예처럼 스스로 단정지은 영역을 넘지 못해 알면서도 문제를 해결하지 못하는 경우가 있다. 그러나 더 많은 경우는 사실 우리가 문제를 발견할만한 자격을 갖추지 못했기 때문이다. 언젠가 이런 표현을 본 적이 있다. “Founders attract the problem (창업자는 문제들을 매혹시킨다)”. 문제가 매력적이어야 하는게 아니다. 우리 주변에 숨어서 존재하는 문제들중 하나가 당신에게 다가가고 싶을만큼 당신이 매력적이어야 한다는 뜻이다. 이런 표현도 좋다. “Problems want to be discovered (문제는 자신을 드러내고 싶어한다)”. 준비된 사람에게 보일 뿐이다. Ev Williams는 Blogger, Twitter에 이어서 최근엔 Medium 이라는 세번째 스타트업을 창업해 성공 신화를 이어가고 있다. 꾸준히 한 우물만 파다보니, “웹에서 글쓰기” 라는 주제에서는 대박 문제들이 그에게만 자신을 드러내는 것이다.

스타트업을 꿈꾼다면 그래서 보이지 않는 문제들에게 매력적인 사람이 되어야 한다. 방법은 의외로 간단하다. 첫째, 무언가를 정말 좋아해야 하고, 둘째는 작은 문제부터 해결해봐야 한다.  Ev Williams가 글쓰고 읽는 것을 좋아하지 않는다면 2조원 넘는 재산이 있으면서도 medium.com을 창업할 이유가 없다. 잭 도시는 아주 어려서부터 트위터를 상상하고 있었다 [5]. 두 사람 다 문제에 빠져 사는 것이다. 페이스북의 마크 쥬커버그는 어려서부터 아버지의 치과 사무실과 자신의 집을 연결하는 작은 문제를 메신져를 코딩해 해결했다. 페이스북의 전신 Facemesh는 내성적이라 여친을 사귈 수 없었던 쥬커버그가 여학생들 사진을 스토킹하며 문제를 해결한 방식이었다. 사소한 문제를 해결하다보니 소셜 네트웍이라는 대박 문제를 얻은 것이다.

그래서 아이디어 생각은 멈추고, 좋아하는 것(직업일수도 있고 취미 일수도 있는)을 계속 하자. 그 과정에서 나를 괴롭히는 어떤 문제가 있는지 세심하게 관찰하자. 혹 문제가 대박처럼 보이지 않을지라도 내게 중요하다면 코딩으로 해결해보자. 그러다보면 언젠가 대박 문제가 당신에게 노크할지도 모른다.

loveactually

https://twitter.com/sm_park

[1] 스타트업 아이디어 (번역)
[2] http://techcrunch.com/2011/12/25/what-startup-to-build/
[3] http://techcrunch.com/2013/12/05/homejoy-38-m/
[4] http://paulgraham.com/schlep.html
[5] 장관님, 이런 놈들을 찾으십니까?

[번역] 해커와 화가 – 5 (끝)

미술처럼 대부분 소프트웨어는 사람들에게 보이는 (쓰이는)것이 목적이다. 그래서 화가처럼 해커도 “동감”할줄 알아야 작품을 만들수 있다. 사용자의 관점에서 사물을 바라볼때 작품이 나온다.

어려서부터 나는 다른 사람의 관점에서 사물을 바라보도록 교육받았다. 실제로 이게 의미했던건 내가 원하는 것 보다는 주변의 사람들이 원하는 것을 먼저 해주게끔 배운 것이다. 물론 “동감”말고 이러한 삶의 방식을 나쁘게 부르는 이름이 있고 (역: 자기희생, 눈치보기), 나중엔 태도를 바꿔 내것을 먼저 챙기려고 노력했다.

그런데 내가 틀렸다. 사물을 다른 사람의 관점에서 바라보는 것이 실제론 성공의 비밀이었다. 그게 꼭 자기 희생을 의미하는 것은 아니었다. 실제론 그것과 거리가 멀었다. 다른 사람이 사물을 어떻게 보느냐를 이해하는 것은 꼭 그 사람의 이해관계를 위해 행동하라는 뜻은 아니다. 어떤 경우, 예를 들어 전쟁중에는 그 반대로 행동해야할 때도 있다.

대부분의 maker들은 사람들을 위해 무언가를 만든다. 그리고 사람들을 끌어들이기 위해서는 그들의 필요를 이해해야 한다. 예를들어, 거의 대부분의 명작 미술품들은 사람을 그린 것인데, 그 이유는 사람들은 그림에서 사람을 보고 싶어하기 때문이다.

“동감”은 아마도 괜찮은 해커와 뛰어난 해커를 나누는 가장 중요한 차이일 것이다. 어떤 해커들은 아주 똑똑하지만 동감의 면에 있어서는 아주 자기중심적이다. 그런 사람들은 사용자의 관점에서 사물을 못 보기 때문에, 위대한 소프트웨어를 디자인 하는것이 불가능하다.

해커가 얼마나 동감을 잘 하는지 알려면 기술적 배경이 없는 사람에게 기술 질문에 대한 답을 하는것을 보면 된다. 아마도 우리는 주변에서 똑똑하지만 그런 설명을 어처구니없이 못하는 사람들을 몇명 알고 있을 것이다. 그런 사람은 누군가 저녁식사 자리에서 프로그래밍 언어가 무어냐고 물으면 이런 식으로 대답할 것이다. “아, 하이레벨 언어는 컴파일러가 그걸 인풋으로 받아서 오브젝트 코드로 만들어주는 거예요” “하이레벨 언어?” “컴파일러?” “오브젝트 코드?” 프로그래밍 언어를 모르는 사람이라면 당연히 그런 용어에 무지할텐데 말이다.

소프트웨어가 해야 하는 일중 하나는 그 자신을 사용자에게 설명하는 것이다. 그래서 좋은 소프트웨어를 짜는 것은 사용자들이 기술에 얼마나 무지한지를 아는게 중요하다. 사람들은 소프트웨어에 아무 준비없이 다가갈 것이고, ‘이 소프트웨어는 이렇게 작동할거야’ 생각하며 실행시킬때 그 기대한대로 동작해야 한다. 사용자들은 매뉴얼을 읽지 않을것이기 때문이다. 이 기준으로 내가 경험한 최고의 시스템은 1985년의 최초 매킨토시 컴퓨터다. 매킨토시는 그전까지 소프트웨어가 한번도 못한것을 했다. 그냥 동작했다. (It just worked).

소스코드 역시 자신을 설명해야 한다. 사람들에게 프로그래밍에 대한 딱 한가지 격언만 소개한다면 책 “컴퓨터 프로그램의 구조와 해석”의 첫장에 나오는 이 구절이다.

“프로그램은 기본적으로 사람들이 읽을 수 있도록, 오직 우연히 컴퓨터에 의해 실행되도록 작성해야 한다”

사용자뿐 아니라 소스코드를 읽을 다른 해커들을 향한 동감을 가져야 한다. 사실 당신 자신을 위한 것이다. 많은 해커들은 자신이 짠 프로그램을 6개월 후에 다시 들여다보고는 전혀 감이 안잡히던 경험이 있을 것이다. 많은 이들이 다시는 Perl로 프로그램 안짠다고 맹세한 이유이기도 하다.

어떤이들은 동감할 줄 모르는게 똑똑해서 그렇다고 생각해서, 일부러 더 동감하지 않으려 한다. 하지만 지식과 동감에 꼭 상호연관이 있다고 생각치 않는다. 자연과학과 수학에 뛰어난 사람들은 흔히 사람들을 잘 이해하는데, 자연과학과 수학을 잘 하는 사람들은 보통 똑똑한 이들이다. 무식한 사람들중에 자기 중심적인 사람도 많다. 토크쇼에 전화를 거는 사람들 이야기를 들어보라. 그들은 자기가 무슨 질문을 하는지도 잘 몰라서 사회자가 그들의 질문을 해석해 다시 묻곤 한다.

자 그럼 해킹이 그림, 글쓰기와 같은 것이라면 과연 그런 직업처럼 쿨한 것일까? 당신은 딱 한번 인생을 사는데, 쿨하고 위대한 일에 시간을 보내고 싶을 것이다.

아쉽지만 이 질문에는 답이 어렵다. 멋진 것에는 항상 시간의 차이가 존재한다. 마치 먼 우주속 별이 보내는 빛과 같다. 지금 미술이 사람들 사이에 명망높은 이유는 500년전에 위대한 작품을 만든 사람들 덕분이다. 그 당시에는 지금 우리가 떠받드는 작품들이 대단치 않은 소장품이었다. 그 당시 사람들에게 우르비노의 공작 Federico da Montefeltro이 현 시대 사람들에겐 프란체스카의 그림에 나오는 이상한 코쟁이 인물로만 알려지는게 신기할 것이다.

지금은 해킹이 미술만큼 그렇게 쿨한 것으로 인정받지 못하는게 아쉽지만, 미술 역시 그 영광스런 시대엔 보잘 것 없는 직업으로 취급받았다는 사실을 기억해야한다.

그러나 우리가 확신할 수 있는것은 지금이 해킹의 영광스런 시대라는 사실이다. 대부분 분야에서 가장 훌륭한 작품들은 초기에 만들어졌다. 1430년에서 1500년 사이에 그려진 미술품들은 여전히 최고의 가치를 지닌다. 셰익스피어는 막 사설 극장이 세워지던 시절에 활동했었는데, 그 이후에 모든 극작가들이 그의 그늘 아래에서 작품을 써야만 했다. 알베르트 뒤러는 판화에서, 제인 오스틴은 소설에서 그랬다.

시간이 지나면 지날수록 우리는 같은 패턴을 본다. 새로운 매체가 출현하고 사람들은 그것에 흥분해서 매체의 가능성을 처음 몇 세대동안 모두 탐구해본다. 해킹이 바로 그 시점에 있다.

다빈치는 그의 작품들로 인해 훗날 미술을 쿨한 직업으로 인정받게끔 했지만 그 시대엔 그 영광을 누리지 못했다. 해킹이 얼마나 쿨한 직업으로 훗날 인정받을까의 여부는 지금 우리가 이 매체로 무엇을 만들어낼까에 달려있다.

https://twitter.com/sm_park

[번역] 해커와 화가 – 4

역설적으로 들리겠지만 명작은 훌륭하다고 인정받는 그 수준보다 더 뛰어나야 한다. 예를들어 레오나르도 다빈치가 국립 갤러리의 Ginevra de Benci 초상화를 그릴때 그녀의 머리 뒤편으로 향나무 수풀을 그렸다. 거기에서 각각의 잎을 아주 정교하게 그려냈다. 많은 화가들은 그런 수풀을 그저 인물 머리의 테두리 역할을 하는 배경으로 생각했을 것이다. 누구도 그 부분을 그리 자세히는 안볼테니까.

그러나 다빈치는 아니었다. 남들이 그 부분을 얼마나 자세히 볼런지는 그가 그 부분을 그릴때 중요한 고려대상이 아니었다. 그건 마이클 조단의 태도와 같다. 바로 끈질김이다.

부분들이 합해지면 보이지 않던 디테일이 선명히 드러나기 때문에 결국 끈질김이 이긴다. 사람들이 Ginevra de Benci의 초상화를 지나쳐갈때면 미쳐 다빈치라는 작가 이름을 알아채기도 전에 곧바로 그 그림에 빨려들어가곤 한다. 보이지 않던 디테일들이 모두 모여서 놀라운 형상을 만들어내는 것은 마치 가냘픈 목소리로 천명이 함께 부르는 합창과 같다 .

뛰어난 소프트웨어 역시 아름다움에 대한 광적인 집착을 필요로 한다. 당신이 훌륭한 소프트웨어의 안을 들여다 볼때면 사람들이 관심갖지 않을 부분까지도 아름답게 짜여져있는걸 발견할 것이다. 내가 대단한 소프트웨어를 만든다는 뜻은 아니지만, 나는 코드에 대한 집착이 지나쳐서 삶의 다른 부분까지 비슷한 태도로 대한다면 두통으로 인해 약을 달고 살아야 할 수준이다. 띄어쓰기가 엉망인 코드나 이상한 변수 이름을 사용한 코드를 볼때면 머리가 돌아버릴 지경이다.

해커가 단순히 스펙을 코드로 바꾸는 구현만 하는 개발자였다면, 하수구 구멍 파는 사람처럼 이쪽 끝에서 저쪽 끝까지 땅만 파내려갈 것이다. 하지만 해커가 창조하는 사람이라면, 예술가와 같은 해커의 영감(inspiration)까지도 생각해야 한다.

미술처럼 해킹엔 주기가 있다. 어떤 날에는 새로운 프로젝이 너무 흥분돼 하루 16시간씩 일하기도 한다. 또 다른 날에는 아무것도 흥미로워 보이질 않는다.

뛰어난 일을 지속하기 위해서는 이러한 주기를 염두에 두어서 적절하게 대응해야 한다. 매뉴얼 기어 자동차를 운전하다가 언덕을 만나면 클러치를 때때로 떼어서 엔진이 서는것을 피해야 한다. 비슷하게 잠시 물러설줄 알아야 큰 목적을 이루다가 멈추어 버리는 상황을 피할 수 있다. 그림과 해킹에는 너무 거대해 보이는 작업들이 있고 때로는 편안하게 해결할 수 있는 쉬운것들이 있다. 쉬운 일들을 남겨놓아 당신이 힘든 작업들로 중간에 멈추었을때 쉬운 작업으로 시간을 보내는 것도 좋은 방법이다.

해킹에서는 이러한 것들을 “버그”라고 부른다. 나는 디버깅을 좋아한다. 사람들이 생각하는 해킹의 이미지에 가장 걸맞는 단순 작업일 것이다. 당신 앞에는 완전히 잘 정의된 문제가 있고 오로지 해결만 하면 된다. 프로그램이 x의 일을 해야 하는데, 지금 y를 하고 있을 뿐이다. 무엇이 잘못됐을까? 이 문젠 결국 해결할 수 있다는 것을 안다. 이런 디버깅은 화가에게 벽을 칠하는 것과 같은 휴식이다.

미술에서 개인의 일뿐 아니라 함께 일하는 방법도 배운다. 한 사람의 이름만 박물관에 쓰여져 있지만 사실 과거 작품은 여러 사람의 손에 의해 만들어진 것이 많다. 다빈치는 한때 베로치오의 제자로서 “그리스도의 세례”에서 천사중 하나를 그렸다. 그런 식의 공동 작업은 예외가 아니라 룰이었다. 미켈란젤로는 특이하게 시스티나 성당 벽화의 모든 인물들은 자신이 그리겠다고 우기기도 했다.

내가 아는 한 화가들은 일하면서 그림의 같은 부분을 여러명이 함께 그리는 경우가 없다. 일반적으로 거장 화가가 가장 중심인물을 그리고 조수뻘되는 화가들이 배경을 그린다. 하지만 한 화가가 다른 사람의 작업 위에 덧칠하는 경우는 없다.

나는 이것이 소프트웨어의 협업에 있어 적합한 모델이라고 생각한다. 코드의 한 부분을 세네명의 사람이 같이 해킹하다보면 아무도 코드를 소유하지 않고 결국엔 공동 화장실처럼 되어 버린다. 빛바래고 버려진 것 같으면서 불쾌한 냄새만 쌓여간다. 프로젝을 같이 할땐 프로젝을 정밀하게 모듈로 나누어 해커들에게 모듈을 소유하게끔 해야한다. 모듈간의 인터페이스는 가능하다면 프로그래밍 언어 수준으로 정교하게 디자인하는 것이 필요하다.

https://twitter.com/sm_park

[번역] 해커와 화가 – 3

해커는 과학자라기 보다는 maker이기 때문에, 영감을 얻을 수 있는 분야는 과학보다는 다른 종류의 maker일 것이다. 그 관점에서 미술보다 해킹에 대해 더 잘 드러낼 분야가 또 있을까?

우리가 미술에서 배울 수 있는것 아니 최소한 확인할 수 있는 것은 어떻게 해킹을 처음 배우는가 하는 점이다. 당신은 그림을 직접 그려가며 미술을 배운다. 딩동뎅! 해킹 역시 그렇다. 대부분 해커들은 대학에서 프로그래밍 과목을 수강한후 해킹을 배우지 않는다. 13살때쯤 스스로 프로그램을 만들어보며 해킹을 배운다. 사실 대학 수업역시 진짜 만들어보면서 배우기 마련이다.

화가들은 자신만의 독특한 흔적을 남기기 때문에, 그림을 그려나가며 배웠다는 사실을 알수 있다. 어떤 화가의 작품을 시간순으로 나열해 보면 각각의 작품들이 그 전의 그림들 토대 위에서 만들어진것을 볼 수 있다. 회화에서 특별히 뛰어나게 잘 표현된 부분이 있다면 그 표현의 버전 1을 그 전의 그림들에서 발견할 수 있을 것이다.

대부분의 maker들이 이런 방식으로 일한다. 작가와 건축가 역시 마찬가지다. 아마도 해커는 화가와 비슷한 방식으로, 한가지 프로젝트에 몇년간 계속해서 일하기 보다는 자주 처음부터 프로젝을 새로 시작하면서 기존의 아이디어를 통합해서 발전시켜나가는 것이 좋을 것이다.

해커들은 직접 코딩하면서 배운다는 사실이 바로 해킹과 과학이 별개의 것이라는 증명이된다. 과학자들은 과학을 랩과 문제풀이를 통해 배운다. 과학자들은 처음 배울때 완벽한 것에서 시작한다. 이미 잘 증명된 문제를 실험으로 재현하며 배우고 훗날 자신의 이론을 세우고 실험하는 단계에 이른다. 반면 해커는 처음 시작부터 자신의 일을 한다. 그냥 아직 아주 어설플 뿐이다. 해커들은 처음에 독창적인 것을 하고, 시간이 갈수록 더 나아지는 반면 과학자들은 처음에 완전한 것에서 시작하고 시간이 갈수록 독창성을 가미한다.

Maker들이 배우는 또 다른 방법은 예제를 통해서이다. 화가에게 있어 미술관은 기교를 참조하는 라이브러리다. 수백년간 지속되온 전통적인 미술 교습법은 거장의 작품들을 모방하는 것인데, 그 이유는 모방을 통해서 작품이 만들어진 방식을 유심히 관찰하게 되기 때문이다.

작가역시 그렇다. 벤자민 프랭클린은 Addison과 Steele이 쓴 수필들을 요약해가면서 글쓰는 법을 배웠다. Raymond Chandler역시 같은 방식으로 탐정 소설을 배웠다.

해커 역시 마찬가지로 훌륭한 프로그램을 참조하면서 프로그래밍을 배운다. 단순히 프로그램의 돌아가는 것을 보는것 뿐 아니라 소스 코드를 참조하면서 말이다. 오픈소스 운동의 덜 알려진 혜택중 하나는 프로그램을 배우기 쉽게 한다는 점이다. 내가 처음 프로그램을 배울때는 대부분 책에 소개된 예제를 통해서였다. 그 당시 예제중 가장 큰 소스 코드는 Unix였는데, 그땐 오픈소스가 아니였다. 소스코드를 읽은 대부분 사람들은 John Lions의 책을 복사한 해적판을 읽었는데, 1977년에 쓰여진 그 책은 1996년까지 출판이 금지되었었다.

미술을 통해 얻을 수 있는 또 다른 예제는 점진적인 개선을 통해 작품을 창조해가는 점이다. 그림은 대부분 스케치에서 시작한다. 구체적인 것은 점차 채워져 나간다. 하지만 그 과정이 단지 채워나가는 것만이 아니다. 때때로 처음 계획은 실수로 판가름난다. xray를 통해 보면 수도 없이 많은 그림들이 테두리가 옮겨져있거나 표면 형태들이 새로 적용된 것을 볼 수 있다.

그것이 바로 미술에서 배울 수 있는 점이다. 해킹또한 이렇게 이루어져야 한다고 생각한다. 프로그램의 스펙이 완벽하다고 기대하는건 비현실적이다. 처음부터 그 사실을 인정하고, 프로그램을 만들며 스펙을 고쳐나가는 것이 훨씬 낫다.

(큰 회사의 구조는 이것이 힘들게 되어있는데, 이것이 스타트업의 잇점중 하나다.)

아마 지금쯤 대부분 사람들은 미성숙한 최적화 (premature optimization)의 위험에 대해 알 것이다. 내 생각에 우리는 미성숙한 디자인 (프로그램이 해야하는 일을 너무 일찍 결정하는 것)에 대해서 역시 걱정해야 한다.

올바른 툴은 이런 위험을 피하는데 도움을 줄 수 있다. 좋은 프로그래밍 언어는 유화가 그러하듯이 해커가 마음을 쉽게 바꿀수 있게끔 도와야 한다. 그점에서 동적 타이핑이 승자라고 할 수 있는데 처음부터 특정한 데이터 표현에 묶이지 않기 때문이다. 하지만 그러한 유연성의 핵심은 언어를 아주 추상적으로 만드는 것이라고 생각한다. 바꾸기 가장 쉬운 프로그램은 아주 짧은 것이다 (역: 언어가 추상적일수록 소스코드가 짧다).

https://twitter.com/sm_park

[번역] 해커와 화가 – 2

대학교와 연구소가 해커가 원하는 일들을 못하게 한다면, 아마도 그들이 있을곳은 일반 기업일 것이다. 그런데 불행히도 회사들 역시 해커가 원하는 것들을 하게끔 허락치 않는다. 학교와 연구소가 해커를 과학자가 되도록 강요한다면, 회사들은 그들을 엔지니어로 남도록 강요한다.

나는 이 사실을 최근에서야 알았다. 야후!가 내가 세운 회사 Viaweb을 사고 나서, 내게 무엇을 하기 원하는지 물었다. 나는 비지니스쪽엔 관심이 없었으니까 그저 해킹을 계속하고 싶다고 이야기 했다. 내가 야후에서 일하기 시작한 후에야 그들에게 해킹이 의미하는건 그저 소프트웨어를 구현하는 것이지 디자인하는 것은 아니라는 걸 알았다. 프로그래머는 그저 프로덕트 메니저의 머릿속 비전을 구현하는 기술자일 뿐이다.

그런데 이게 큰 회사들의 기본 구조인 것 같다. 큰 회사들이 이런식으로 운영하는 이유는 예측가능한 결과를 얻고 싶어하기 때문이다. 작은 퍼센트의 해커만이 실제 소프트웨어를 디자인할 수 있는데 회사를 운영하는 사람들은 그들을 전면에 내세우기가 어렵다. 그래서 소프트웨어의 미래를 뛰어난 해커 한 사람에게 맏기기 보다는 대부분 회사는 소프트웨어를 위원회(committee)에서 디자인하고 해커들은 단순히 디자인을 구현하게끔 한다.

여러분이 혹시 언젠가 큰 돈을 벌고 싶다면 이 사실을 꼭 명심해라. 왜냐하면 이것이 스타트업이 이기는 이유이기 때문이다. 큰 회사들은 재앙을 피하기 위해 소프트웨어 결과물의 표준편차를 줄이는 것에만 골몰한다. 하지만 표준편차를 줄이다보면 저점과 함께 고점도 모두 지워나가기 마련이다. 큰 회사들에겐 이런게 큰 문제가 안된다. 그들은 훌륭한 제품을 만들어서 마켓에서 이기는게 아니라 다른 큰 회사보다 조금 더 낫기 때문이다.

그래서 프로덕트 메니저가 소프트웨어를 디자인하는 그런 회사가 여러분의 제품과 디자인 싸움에 뛰어들게끔 한다면, 그들은 절대 여러분을 쫓아오지 못할 것이다. 하지만 그런 기회를 포착하는 것은 쉽지 않다. 큰 회사를 디자인 싸움에 뛰어들게 하는 것은 성벽 안쪽의 적과 싸우는 것만큼 어렵다. 예를들어, 어쩌면 MS 워드보다 더 나은 제품을 만드는건 쉬운 일일지 모른다. 하지만 마이크로소프트는 운영체제 독점이라는 성벽안에서 싸우려 들것이고, 아마도 여러분의 제품이 존재한다는 사실자체도 모를것이다. (역: 큰 기업은 제품보다는 브랜드로 스타트업을 제압한다).

디자인 싸움을 펼쳐야 하는 곳은 그래서 아직 아무도 성벽을 세우지 못한 새로운 마켓이어야 한다. 그곳만이 용감하게 디자인에 접근하면서 구현과 디자인을 함께하는 당신이 크게 이길 수 있는 싸움터다. 마이크로소프트는 시작할때 그랬다. 애플과 HP역시 마찬가지다. 아마 모든 성공한 스타트업이 그랬을 것이다.

그래서 훌륭한 소프트웨어를 만드는 방법은 자신의 스타트업을 시작하는 것이다. 그런데 여기엔 두가지 문제가 있다. 첫째로 스타트업은 소프트웨어 만드는 것 말고도 훨씬 많은 일들을 해결해야 한다. 나는 Viaweb에서 시간의 25% 정도만 코딩하는데 사용해도 그날은 운 좋다고 느꼈었다. 나머지 75%는 지루하거나 다루기 겁나는 일들에 허비해야 했다. 어느날엔가 나는 이사회 회의 중에 나와 충치치료를 할 일이 있었다. 그날 치과 의자에 누워 드릴을 기다리니 마치 휴가지에 와 있는 것 같은 착각이 들 정도였다.

또 다른 스타트업의 문제는 돈벌이가 되는 소프트웨어와 만들기 재미있는 소프트웨어가 그다지 겹치지 않는다는 사실이다. 프로그램 언어는 만드는것이 재미있고 마이크로소프트의 첫 제품이 사실 그거였는데, 지금 시대엔 아무도 프로그램 언어를 돈주고 사지 않는다. 돈을 벌고 싶다면 아무도 공짜로는 해결해주지 않는 그런 지저분한 문제를 파고들어야 한다.

모든 maker들이 이 문제를 겪는다. 가격은 수요와 공급에 의해 결정되는데, 작업이 재미있는 그런 작품들보다는 시시하지만 고객의 개별적인 문제를 해결하는 그런 작품들에 수요가 따르기 마련이다. 언더에서 연극하는 것은 무역박람회 부쓰에서 고릴라 복장하고 있는 것보다 돈을 받지 못한다. 소설보다는 쓰레기통으로 들어갈 광고지 문구 작성하는게 밥벌이에 낫다. 프로그래밍 언어를 해킹하는 것보다는 큰 회사의 옛날 데이터베이스를 웹서버에 연결시켜주는 일이 돈이 된다.

소프트웨어의 경우에 이 문제에 대한 해결은 거의 모든 maker들에게 잘 알려진 개념이다. 그것은 “낮 일 (day job)”을 갖는 것이다. 이 문구는 밤에 직업을 위해 무대를 뛰는 음악가들에게 처음 붙여졌다. 좀 더 넓게 적용하자면, 당신이 돈을 위해 하는 한가지 일과, 사랑해서 하는 다른 한가지 일이 있어야 한다는 뜻이다.

거의 모든 maker들의 커리어 초반기엔 낮 일이 있다. 화가와 작가들에겐 이 용어가 씁쓸한 현실이다. 당신이 운좋다면 당신의 진짜 일과 관련된 낮 일을 얻을 것이다. 음악가들은 종종 레코드 가게에서 일하곤 한다. 프로그래밍 언어나 운영체제를 하는 해커들은 종종 같은 언어나 os를 사용하는 낮 일을 하곤 한다.

해커는 낮 일을 하면서 아름다운 소프트웨어를 만들어야 한다는게 사실 새로운 개념은 아니다. 오픈소스 해커들이 오랫동안 지속한 삶의 방식이다. 이야기 하려고 하는것은, 다른 직업의 maker들에게서 확인되었듯이 오픈소스 방식이 스타트업을 하고자 하는 해커들의 올바른 모델이라는 점이다.

종종 어떤 회사들은 직원들이 오픈소스 프로젝에 참여하는 걸 꺼리는데, 나는 그 사실이 놀랍다. Viaweb에서는 오픈소스 프로젝 경험이 없는 직원을 채용하는걸 꺼렸다. 우리는 인터뷰하며 사람들이 여가시간에 무슨 소프트웨어를 만들었는가를 가장 관심있어했다. 어떤 일을 사랑하지 않고는 정말 잘할 수가 없다. 해킹을 사랑한다면 당신은 분명히 자신의 프로젝을 가지고 일했을 것이다.

https://twitter.com/sm_park

[번역] 해커와 화가 – 1

http://paulgraham.com/hp.html

지난번에 올린것과 같이 폴 그레이엄의 명 에세이 “해커와 화가”를 번역해서 올립니다. 최근에 읽은 글중 가장 좋은 것이기 때문에 번역했습니다. 글이 길어서 2-3회에 걸쳐서 올려야 할 것 같습니다.

—————————————————–

해커와 화가

2003년 5월

나는 컴퓨터 사이언스로 대학원을 마치자마자 미대에 진학해 회화를 공부했다. 주변의 많은 사람들이 컴퓨터를 좋아하는 사람이 그림에도 관심이 있다는 사실에 놀랐다. 아마도 해킹과 미술이 완전히 다른 종류의 일이라고 생각하기 때문인듯 싶다. 해킹이 차갑고, 정밀하고 기술적인 일이라면 그림은 어떤 현상, 사물에 대해 흥분된 감정을 주체못해 표현하는 예술이라고 생각하기 때문이다.

이 두가지 이미지는 사실은 모두 틀리다. 해킹과 미술은 많은 공통점이 있다. 사실 내가 경험했던 모든 사람들 중 그 두가지 직업의 사람들이 가장 서로 닮았다.

해커와 화가의 공통점은 둘 다 maker(만들어내는 사람들)이라는 점이다. 작곡가, 건축가, 작가처럼 해커와 화가는 둘 다 작품을 만들어낸다. 엄밀히 따지면 두 직업의 사람은 연구를 한다고 하긴 어렵다. 하지만 훌륭한 작품을 만들어 내는 과정에서 종종 새로운 기법(technique)을 발견해내는 경우가 있다.

(역: maker 에 맞는 적절한 한국어 단어가 없어 이후 maker를 그대로 사용합니다).

나는 컴퓨터 사이언스라는 용어를 좋아한적이 없다 (역: 미국대학교에서는 컴퓨터전공을 컴퓨터사이언스로 통칭). 가장 큰 이유는 그런 분야가 사실 존재하지 않기 때문이다. 컴퓨터 사이언스는 여러가지 분야가 한 가방안에 역사적인 우연에 의해 뭉뚱그레진것과 같은 학문이다. 이를테면 유고슬라비아 같은 나라와 같다. 한쪽편엔 실제론 수학자면서 자신의 일을 컴퓨터 사이언스라 부르며 국방부의 연구비를 따내는 사람들이 있다. 중간엔 컴퓨터의 자연스런 발전과정에서 실험적 연구를하는 사람들이 있는데 예를들면 네트웍의 라우팅 알고리즘을 하는 사람들이 그렇다. 그리고 다른 극단에는 그저 재미있는 소프트웨어를 만들며, 건축가에게 콘크리트, 화가에겐 물감처럼 컴퓨터를 단지 자신의 생각을 표현하는 수단으로 이용하는 해커 그룹이 있다. 이런 조합은 마치 수학자, 물리학자, 건축가를 모두 한 전공안에 몰아넣은 것과 같다.

종종 해커들이 하는 일을 소프트웨어 공학 이라고 부르는데 이것은 용어의 잘못된 사용일 뿐이다. 뛰어난 소프트웨어 디자이너는 엔지니어보다는 건축가(architect)에 가깝다. 건축과 엔지니어링 사이의 경계가 뚜렷한것은 아니지만 분명히 둘은 구분된다. 무엇을 하느냐와 어떻게 하느냐의 차이라고 생각할 수 있는데, 아키텍트가 무엇을 하느냐를 결정한다면 엔지니어는 어떻게 하느냐를 찾아낸다.

이 “무엇”과 “어떻게”의 관계가 완전히 동떨어진것은 아니다. 당신이 어떻게 만드는지도 모르면서 무언가를 하려고들면 문제만 일으킬게 뻔하다. 하지만 해킹은 그저 스펙을 어떻게 구현할까 생각하는 것 이상의 행위다. 뛰어난 해킹은 스펙 자체를 만들어내고 그 자신이 스펙을 구현할 최적의 기술 또한 선보인다.

어쩌면 유고슬라비아가 그랬듯이 컴퓨터 사이언스는 여러개의 분야로 분리될지도 모르겠다. 아마 그건 좋은 일일 것이다. 특히 그게 나의 “조국” 해킹의 독립을 의미한다면 말이다. 이러한 여러 분야를 한 전공안에 몰아넣은것이 관리의 측면에서 편할런지 몰라도 지적인 면에선 혼란만 일으킨다. 그게 내가 컴퓨터 사이언스라는 용어를 싫어하는 또 다른 이유다. 논란의 여지가 있지만, 중간영역에 있는 사람들 (역: 예를들어 네트웍 알고리즘)은 어떤 실험적 과학을 하는 셈이다. 하지만 양쪽 끝편에 있는 사람들, 즉 수학자와 해커들은 사실 과학을 한다고 말하긴 어렵다.

수학자 그룹은 이런 용어의 문제에 그리 신경쓰지 않는다. 그들은 옆 건물 수학과 사람들처럼 그저 열심히 정리(theorem)를 증명할 뿐이고 아마도 자신들의 건물에붙은 컴퓨터 사이언스 간판을 언젠가부터 인식도 못했을 것이다. 하지만 해커들에게 컴퓨터 사이언스라는 딱지는 문제가 된다. 자신들이 일하는 것을 사이언스라고 부르기 시작하면서 스스로 과학자같은 일을 해야한다고 느끼기 시작한다. 그래서 자신들이 정말 원하는 것, 즉 아름다운 소프트웨어를 디자인하지 못하고 학교와 연구소에서 해커들은 논문 쓰는것을 강요받는 것이다.

좋게 보자면 논문은 그저 형식일 뿐이다. 해커는 쿨한 소프트웨어를 만들고 그것에 대해 논문을 제출할 뿐이다. 논문은 그저 소프트웨어에 대한 소개 그 정도로 한정지을수 있다. 하지만 잘못된 용어는 빈번히 문제를 일으킨다. 아름다운 것을 만드는 자신의 본래 꿈에서 빗겨나가, 추하지만 연구 논문의 주제로 쓰기에 적합한 것들을 만들어내는게 참 쉬운 선택이기 때문이다.

안타깝지만 아름다운 것들은 논문으로서 최고의 주제가 되지는 못한다. 연구의 제1 기준은 독창성이다. 박사 논문을 써본 사람은 알겠지만 누구도 개척하지 않은 분야를 탐험하는 간단한 방법이 있다. 그건 아무도 원하지 않는 곳으로 가는 것이다 (역: 필요없는 연구를 하는 것이다). 두번째로 연구는 무게가 있어야 한다. 다루기 힘든 분야를 하면 많은 논문을 배출하는데 그 이유는 목표를 이루기 위해 많은 벽들을 넘어서야 하기 때문이다. 그래서 풍성한 문제들을 배출하는 최고의 방법은 잘못된 가정에서 시작하는 것이다 (역: 즉 불가능한 목표). 대부분의 인공지능 연구가 그 예다. 당신이 지식이란 논리의 나열로 표현할 수 있고, 나열된 논리가 추상적인 개념마저 표현할 수 있다고 가정하기 시작하면 당신은 풍성한 논문들을 여기에서 만들어낼 수 있다. Ricky Ricardo가 이렇게 이야기 했듯 말이다: “루시, 그거 설명할 게 아주 많아!”

아름다운 것들은 종종 이미 존재하는 것들을 미묘하게 조작하거나 이미 알려진 아이디어를 작게 변형해 조합하면서 만들어진다. 이런 종류의 일은 연구 논문에서 다루기가 어렵다.

그런데 왜 학교와 연구소는 해커를 논문의 수로 평가할까? 이유는 간단한데, 학생의 학습능력을 표준화된 시험으로 평가하는 것이나 프로그래머의 생산성을 코드의 라인수로 측정하는 이유와 같다. 골치 썩힐 필요없이 이렇게 단순한 잣대로 평가하는 것이 달콤한 유혹이기 때문이다.

해커가 진짜로 하려는 것, 즉 아름다운 소프트웨어를 평가하는 것은 훨씬 어렵다. 당신이 훌륭한 디자인을 판별할만한 눈이 있어야 한다. 자신이 그럴만한 안목이 있다고 자신만만해 하는 사람들은, 사실은 그 반대의 소질을 갖고 있는 경우가 많다.

유일한 평가의 기준은 시간이다. 시간이 지나면서 아름다운 것들은 번성하고, 추한 것들은 버려진다. 그런데 어떤 경우엔 사람의 수명보다 더 긴 시간을 요할때도 있다. 사무엘 존슨은 작가의 명성을 수렴하는데는 100년이 걸린다고 이야기 했다. 작가의 영향력있는 친구들과 그 추종자들이 모두 죽고난 후에야 진정한 명성을 이야기할수 있다고 했다.

그래서 내 생각에 해커들은 명성을 그저 행운의 결과라고 치부하는 그런 마음가짐을 가져야 한다. 그런 면에서 다른 분야의 maker들과 다르지 않다. 사실, 비교적 다른 분야에 비해 좀 나은편이다. 해킹에 비해 미술은 훨씬 더 유행에 민감하다.

다른 사람들이 당신의 일을 오해하는 것보다 더 나쁜것이 있다. 그 위험은 당신이 자기의 일을 스스로 오해하는 것이다. 우리는 가까운 곳에서 아이디어를 찾기 마련이다. 그런데 당신이 컴퓨터 사이언스과에 있다면, 자연스레 해킹이란 결국 컴퓨터 사이언스 이론을 응용한 것일 뿐이라는 그런 생각에 빠지게 된다. 나는 대학원에 있으면서 머릿속에 늘 불편한 생각을 가지고 있었다. ‘컴퓨터 이론을 좀 더 많이 알아야 하는데…’ 그런데도 시험을 보면 3주안에 다 까먹어버리는 그 사실에 대한 불안함 말이다.

지금에서야 깨달았지만 그건 실수였다. 화가가 물감의 화학 성분을 이해하는 것 그 수준으로만 이론을 이해해도 괜찮다. 시간과 공간의 복잡도 (BigO) 정도와 튜링 테스트정도만 이해하면 된다. 아마 상태기계(state machine)을 이해하면 Parser나 정규식 라이브러리를 만들때 도움이 될 것이다. 화가는 사실 물감의 화학성분보다 기억해야 할 더 많은 것들이 있다.

한가지 발견한 사실은 아이디어를 찾는 가장 좋은 곳은 이름에 컴퓨터가 붙지 않았지만 maker들로 구성된 분야라는 점이다. 미술은 그래서 내게 컴퓨터 이론보다 훨씬 많은 아이디어를 제공했다.

예를들어 학부 시절에는 컴퓨터 근처에 가지 않고도 프로그램을 완벽히 종이에 써 낼수 있어야 한다고 배웠다. 하지만 나는 이런식으로 코딩하지 않았다. 나는 컴퓨터앞에 앉아 프로그래밍하는게 종이에 하는것보다 더 좋았다. 끈기있게 내가 맞다고 믿으며 완벽한 코드를 종이에 써내려가는 것보다는, 처음에는 완전히 망가진 형태의 코드를 모니터에 타이핑하고 조금씩 모양을 만들어나가는게 더 좋았다. 학교에선 디버깅이 타이포나 부주의한 실수를 잡아내는 마지막 테스트라고 배웠다. 하지만 내게 코딩은 그저 디버깅의 연속이었을 뿐이다.

이런식으로 코딩하면서, 초등학교에서 연필을 이상하게 잡는다고 지적받으며 느꼈던 불편한 감정을 계속 느꼈다. 그 당시 화가, 건축가의 작업 방법을 알았더라면 이런 식의 코딩에 이름이 있다는걸 깨달았을 것이다: 그건 “스케치”다. 내가 분명히 말할 수 있는건 대학들에서 가르치는 프로그래밍 방법은 모두 틀렸다는 것이다. 프로그램은 만들어가면서 배우는 것이다. 작가, 화가, 건축가들이 모두 그러하듯이.

이 사실을 깨달으면 소프트웨어 디자인에 다른 관점을 갖게 된다. 프로그래밍 언어에있어 가장 중요한 것은 변화를 줄 수 있어야 한다는 사실이다. 프로그래밍 언어는 프로그램을 생각하는 과정을 위한 것이지, 이미 당신 머릿속에 그려진 지도를 표현하기 위한 것이 아니다. 즉, 볼펜이 아니라 연필이어야 한다. 정적 타입 (역: static type-c, java 언어)은 대학들에서 가르치는 방법으로 코딩한다면 괜찮은 방법이다. 하지만 내가 아는 한 해커들은 그런식으로 코딩하지 않는다. 우리에게 필요한 언어는 대충 끄적여보면서 고쳐나갈 수 있는 것이다. 조신하게 찻잔(type)을 무릎위에 올려놓고 먼친척 아줌마 “컴파일러”와 공손하게 대화하는 그런식의 프로그램 언어는 틀렸다.

(역: Graham은 2003년에 이 에세이를 썼는데 그 후 지금껏 10년간 해커, 스타트업 세계에서 가장 각광받은 언어는 Python, Ruby, Javascript와 같은 동적 타이핑 언어다. 그레엄이 정확하게 문제를 짚었다는걸 알 수 있다.)

지금까지 정적 타이핑에 대해 이야기 했지만, 우리 자신을 maker라고 생각할때 과학이 주는 또 다른 고통으로부터 자유로워진다. 그것은 수학에 대한 질투다. 과학계의 모든 사람들이 비밀스럽게 믿는 한가지 사실은 수학자가 자신보다 더 똑똑하다는 것이다. 수학자 자신도 그렇게 믿는다고 생각한다. 그래서 결과적으로 과학자들은 자신의 일을 수학처럼 보이게 하길 좋아한다. 물리학과 같은 분야에선 그리 문제가 안되겠지만 자연과학에서 멀어질 수록 이게 큰 문제가 된다.

한 페이지에 가득 채워진 수학 공식은 아주 인상적이다 (팁: 더 인상적으로 보이려면 그리스 기호를 쓰라). 그래서 여러가지 문제중 수학 공식으로 표현 할 수 있는 문제를 다루려는 큰 유혹이 생긴다. 더 중요한 문제들을 앞에 두고도 말이다.

해커가 스스로를 작가나 화가와 동일시했다면 그런 유혹은 받지 않았을 것이다. 작가와 화가는 수학에 질투하지 않는다. 완전히 다른 종류의 일을 하고 있다고 느낄 뿐이다. 해커도 마찬가지여야한다.

— 다음 편에 계속 —

https://twitter.com/sm_park

세상에서 가장 웃긴 스타트업 아이디어들

Quora에 올라온 질문 “세상에서 가장 웃긴 아이디어였지만 훗날 성공한 스타트업은 무엇이 있나요?” 에 대한 답이 인상적이라 번역해 봅니다. 답변을 한 사람은 성공한 창업자중 하나인 Michael Wolfe 입니다 (http://www.crunchbase.com/person/michael-wolfe). 원문은 이곳에 있습니다: http://www.quora.com/What-were-the-most-ridiculous-startup-ideas-that-eventually-became-successful#ans2309896

——————————————-

괜찮은 아이디어를 가지고 괜찮은 스타트업을 만드는 것은 그리 어렵지 않다. 그러나 많은 뛰어난 스타트업은 직접 제품이 동작하는 것을 보기전까진 아이디어가 우습다. 당신이 벤처캐피털리스트 (돈 대는 회사들)라 가정하고 누가 이런 아이디어로 당신에게 투자하라고 열변을 토한다 생각해보라. 당신의 반응은 어땠을까?

페이스북 – 세상은 또다른 마이스페이스나 프렌드스터를 원합니다. 뭐 몇년 늦게 출시해도 괜찮습니다. 우린 처음에 너드에 공부만 열심히 하는 아이비리그 학생에게 오픈할 겁니다. 다른 사람들은 곧 따라서 가입할 겁니다 .하바드 학생들이 좀 쿨하잖아요? 

드랍박스 – 우리는 파일을 공유, 싱크하는 앱을 만들겁니다. 근데 마이크로소프트나 다른 회사들이 여러개 만들긴 했네요. 지금은 그런 솔루션을 사용하는 사람들이 없긴 한데… 우리는 한가지만 잘 할겁니다. 그럼 사용자들은 가지고 있는 컨텐츠를 드랍박스로 다 옮길거예요.

아마존 – 아직 사람들이 웹에서 신용카드 긁는 것을 무서워하긴 하는데, 그래도 우리는 온라인에서 책을 팔 겁니다. 배송비를 따지면 사실 그리 싸지는 않을거예요. 온라인? 편하잖아요. 일주일 정도는 배송을 기다릴수 있을 겁니다.

버진 아틀란틱 – 항공사가 좀 쿨하죠. 한번 시작해 봅시다! 항공사 하나 만드는거 뭐 어려울것 있겠습니까? 안전교육 비디오 좀 웃기게 만들어주고, 똥꼬짓만(ass hole) 안하면 되잖습니까? 

민트 – 갖고 있는 은행, 주식계좌, 신용카드 정보만 줘봐요. 그러면 예쁜 폰트로 정보를 모아서 보여줄께요. 부자라고 느낄수 있게 예금액을 초록색으로 보여주면 좋겠죠?

크레이그 리스트 – 사이트가 좀 못생기긴 했지만 중고품을 거래할 수 있죠. 공짭니다. 근데 술집 아가씨한텐 돈을 받을거예요.

iOS – 맥, 윈도우즈, 리눅스에서 만들어진 수백만개의 어플리케이션을 하나도 못 돌리는 운영체제를 만들겁니다. 오직 애플만 앱을 만들수 있지요. cut and paste 기능은 안되고요.

구글 – 세계에서 20번째로 검색 엔진을 만들겁니다. 다른 회사들은 돈이 안되니까 이미 다 포기해버린 사업이긴 한데..뉴스나 포털의 기능들은 다 빼버리고 검색을 공짜로 해줄겁니다.

깃헙(Github) – 오픈소스 해커들이 매월 일정액을 평생동안 내면서 우리 서비스를 사용할 겁니다. 아 근데 git은 원래 공짜 소프트웨어예요!

페이팔 – 사람들은 안전하지 않은 AOL이나 야후 메일 주소를 사용해서 서로 진짜 돈을 보낼 겁니다. 우리가 은행도 아니고 직원이 아직 20명도 안되긴 하지만…믿겠죠?

Paperless Post – 우리는 Evite와 같은 초청장 사이트예요..근데 우린 돈을 받죠. 우리것을 쓰면 친구들은 여러분을 병신이라고 생각할 겁니다. 

인스타그램 – 필터죠! 맞습니다. 사진에 필터만 있으면 돼요!

링크드인 – 바쁜 3-40대 직장인들을 위한 소셜 네트워크 어떨까요? 아마 잡서치할때, 5년에 한번 정도는 사이트에 들를겁니다. 

테슬라 – 전기 배터리나 만드는 쪼잔한거 말고, 큰거 한번 만들어봅시다. 우리는 전기 자동차를 아예 처음부터 모두 만들거고 판매망도 다 구축할겁니다. 경제가 불황이긴 한데 그까짓것 쯤이야..

스페이스 X – 나사가 할 수 있으면 우리도 할수 있죠. 우주비행, 거 대단한것 아닙니다. 

파이어팍스 – 전세계 90% 사람들이 무료로 배포되는 웹브라우져를 쓰기는 하는데 그래도 우린 더 나은 웹브라우저를 만들겁니다. 우리한테 그거 잘만드는 사람 한명 있습니다.

트위터 – 이메일 같기도하고, 문자메시지나 RSS리더 같기도 한데…딱히 할 수있는건 많이 없죠. 처음엔 긱, 너드들이 많이 쓸거고요 브리트니 스피어스, 찰리쉰 같은 사람들이 곧 이용할 겁니다.

https://twitter.com/sm_park

 

번역: 스타트업 아이디어

아래의 글은 최근에  Paul Graham 의 에세이 Startup Idea를 읽고 감동받아 번역한 것입니다. 원본은 이곳에 있습니다: http://paulgraham.com/startupideas.html . 참고로 Paul Graham은 YCombinator를 시작해 Dropbox, Reddit, Airbnb등의 스타트업을 키워낸 대가입니다. 뛰어난 해커이기도 하고 특히 글을 아주 잘 써서 좋아합니다.

————————————————————–

스타트업 아이디어를 생각해내는 최고의 방법은 스타트업 아이디어를 생각하지 않으려 노력하는 것이다. 문제를 찾아내되 가능하면 당신 자신이 경험하는 문제를 찾는 것이다.

가장 뛰어난 스타트업 아이디어는 세가지 공통점을 갖는다: 그것은 창업자 자신이 원하는 솔루션이고, 그들 스스로 만들수 있으며, 다른이들이 가치있다고 여기지 않은 것들이다. 마이크로소프트, 애플, 야후, 구글, 페이스북 모두 이같은 방식으로 시작됐다.

왜 당신 자신이 겪고 있는 문제에서 시작하는게 중요한가? 그것은 문제 자체가 존재한다는 것을 입증하기 때문이다. 얼핏 “존재하는 문제”를 해결하는 것이 너무 당연하게 들리겠지만, 현재까지 거의 모든 스타트업들의 공통된 실수는 누구도 신경쓰지 않는 문제를 해결하려 했다는 점이다 (역: 학계에서 연구하고 논문을 쓸때도 마찬가지).

나 스스로 그런 실수를 경험했다. 1995년에 미술작품들을 온라인에서 전시하는 회사를 시작했다. 하지만 갤러리들은 온라인을 원하지 않았다. 미술 비지니스는 그런식으로 움직이지 않았다. 그럼 나는 왜 6개월이나 이 어이없는 아이디어를 가지고 낭비했을까? 내가 사용자에게 관심을 기울이지 않았기 때문이다. 내가 머리속으로 상상한 미술 비지니스의 모델은 실제와는 달랐는데도, 그 모델을 구현하려 노력한 것이다. 내가 사용자들에게 비용을 청구하기 전까지 나는 내 모델이 틀렸다는 사실을 깨닫지 못했다. 그것을 깨닫기까지 너무 오랜 시간을 허비했다. 내 상상속의 세계, 그 모델에 나는 집착했고 엄청난 시간을 소프트웨어를 만드는데 투자했다. 세계는 내 작품을 원했어야만 했다!

왜 그럼 많은 창업자들이 누구도 원하지 않는 것들을 만들까? 시작할때부터 스타트업 아이디어를 생각하기 때문이다. 이것은 사실 대단히 위험한데, 아이디어를 아예 못 만들어낸다면 모를까, 스스로 생각하기에 너무 그럴듯한 아이디어를 만들고 거기에 속아넘어가 열정을 쏟아붓는다.

YCombinator에서는 그런 스타트업 아이디어를 “창조형” 혹은 “시트콤” 아이디어라 부른다. tv쇼에서 배우들이 스타트업을 시작한다고 생각해보자. 작가는 무언가 스타트업다운 아이디어를 만들어야 한다. 그런데 좋은 스타트업 아이디어를 얻는 것은 어렵다. 생각한다고 떠오르는게 아니다. 그래서 작가들은 얼핏 듣기에 그럴싸한 아이디어를 만들어내지만 실제론 가짜일 뿐이다.

예를들어, 애완동물을 키우는 사람들의 소셜 네트웍을 생각해보자. 그렇게 이상하다고 생각되지 않을것이다. 수백만의 애완 동물 키우는 사람이 있고 그들중 많은 사람들이 애완동물에 많은 돈을 써가며 정성을 기울인다. 당연히 사람들은 어딘가 온라인에 모여서 다른 애완동물 애호가들과 이야기 나누고 싶어할 것이다. 그들중 단 2-3%만 사이트에 꾸준히 방문한다면 그것만으로 백만 이상의 사용자를  얻을것이다. 그 사람들에게 최적화된 광고를 제공하거나 아니면 돈을 받는 고급 서비스를 제공할 수도 있을것이다.

이 뛰어난(사실은 위험한) 아이디어를 가지고 친구에게 간다고 생각해보자. 친구는 “절대 그런 서비스는 사용 안해!” 라고 이야기 하지 않는다. “그래 어쩌면 언젠가 나도 그런 서비스 사용할지도 모르겠다” 이야기할 것이다. 회사를 시작하는 순간까지 아이디어는 많은 사람들에게 그럴듯해 보일 것이다. 그 사람들은 당장 그 서비스를 사용하고 싶어하진 않는다. 하지만 다른 사람들이 원할거라고는 쉽게 상상한다. 모든 인구가 이런 반응을 보인다고 생각해보자. 당신은 단 한명의 사용자도 얻지 못한다.

우물

스타트업을 시작할때는 제품을 간절히 원하는 최소 몇명의 사용자가 꼭 필요하다. 언젠가 사용할거라고 생각하는 사람들 말고 지금 급하게 원하는 사람들이 필요하다. 보통 이런 얼리아답터 사용자들은 숫자가 얼마 안되는데 이유는 단순하다. 만일 많은 수의 사람들이 간절히 원하는데, 스타트업의 적은 자원으로도 만들 수 있는 제품이 있다고 생각해보자. 아마도 그런 제품은 이미 시장에 존재할 것이다. 결론적으로 그럼 타협이 필요하다. 많은 사람들이 조금씩 원하는 제품을 만들수도 있고, 적은 숫자의 사람들이 많이 원하는 제품을 만들수도 있다. 후자를 택해라. 모든 후자 타입이 좋은 스타트업 아이디어는 아니다. 하지만 모든 성공한 스타트업의 아이디어는 그런 타입이었다.

그래프를 한번 상상해보자. x축은 당신의 제품을 원하는 사람들을 나타내고, y축은 그들이 얼마나 간절히 원하는지를 나타낸다. y축을 거꾸로 놓으면 당신의 회사는 구멍과 같은 모양을 그릴 것이다. 구글은 아주 큰 구덩이였다. 수억명의 사람들이 구글의 검색을 간절히 원했다. 이제 막 시작하는 스타트업은 그만큼 큰 구덩이를 파내는건 힘들다. 당신에게 남은 선택은 그래서 두가지 모양의 구멍이다. 넓고 얕은 구멍 아니면 좁은데 깊은 마치 우물같은 모양 말이다 (역: 우물 모양은 적은 수의 사용자가 간절히 원하는 형상).

시트콤 스타트업의 아이디어는 보통 첫번째 타입이다. 많은 수의 사람들이 아주 조금 애완동물 소셜네트워크를 원한다.

거의 모든 좋은 스타트업 아이디어는 두번째 타입이다. 마이크로소프트가 Altair에 올라가는 베이직을 만들때 그랬다. 당시 겨우 몇천명의 Altair 사용자가 있었지만 컴파일러 없이 그들은 머신 언어로 프로그래밍 해야 했다. 30년후 페이스북도 같은 모양이었다. 그들의 첫 사이트는 몇천명 안되는 하버드 학생이 대상이었지만 그 몇천명은 페이스북을 간절히 원했다.

당신이 스타트업 아이디어가 있다면 이렇게 질문해라: 누가 이것을 지금 원하는가? 누가 이것을 지금 간절히 원하기에 한 두 사람 스타트업이 만든 허접한 버전이라도 쓰려고 할까? 여기에 답할 수 없다면 아마도 그 아이디어는 별로인 것이다.

위의 그래프에서 사실 얼마나 우물이 좁은지는 크게 중요치 않다. 우물의 깊이가 중요하다 (역: 얼마나 원하는가). 때로 우물이 좁은 이유는 적은 자원으로 깊은 구덩이를 만들어야 하기 때문이다. 어찌됐건 처음에 우물은 좁기 마련이다. 실제 우물의 깊이와 좁은 정도는 연관성이 강력해서 만일 당신의 아이디어가 아주 특정한 계층의 사람들에게 강력하게 어필한다면 그것은 좋은 사인이 된다.

그러나 우물과 같은 모양의 아이디어는 필요하지만, 그것이 충분조건은 아니다. 져커버그가 오로지 하버드 학생들에게만 먹히는 것을 만들었다면 그건 좋은 아이디어가 아니었을 것이다. 페이스북이 좋은 아이디어였던 것은 작은 사용자 그룹에서 빠르게 퍼져나갈 수 있는 경로가 있었기 때문이다. 하버드에서 통하는 걸 만들었다면 어떤 대학교에서도 통할 것이다. 그럼 빠르게 대학교들로 서비스를 확장하면 된다. 모든 대학생들을 끌어들였다면 그 외의 일반인들은 오픈만 해주면 들어오게 되어있다.

마이크로소프트 역시 마찬가지였다. Altair를 위한 베이직. 다른 컴퓨터를 위한 베이직. 베이직 말고 다른 언어들. 운영체제. 어플리케이션. 주식 상장.

당신 자신

그럼 초기 아이디어에서 확장할 수 있는 경로가 있는지 어떻게 알까? 어떤 아이디어가 거대한 회사의 dna를 가졌는지 아니면 그저 작은 마켓에 머무르게 될지 알 수 있을까? 보통 이 대답은 어렵다. Airbnb의 창업자들은 그들이 얼마나 큰 시장에 발을 들여놓는지 몰랐다 (역: Airbnb는 공유 경제의 시작). 처음에 그들은 더 작은 아이디어로 컨벤션 센터에서 호스트들이 전시장 공간을 렌트하는 서비스에서 시작했다. 그 아이디어가 어떻게 확장될런지 그들은 몰랐다. 자연스레 확장된 것 뿐이다. 그들이 처음에 알았던 유일한 사실은 그들이 가능성있는 무언가를 잡고있다는 느낌 뿐. 빌게이츠나 마크 저커버그 역시 처음엔 그랬을 것이다.

어떤때는 초기의 작은 성공에서 퍼져나갈 경로가 있는지 확연히 보일때가 있다. 종종 나는 다른 사람들이 포착 못하는 경로를 볼 때가 많다. 그게 YCombinator의 특기중 하나다. 하지만 아무리 경력이 많다 하더라도 한계가 있다. 제일 중요한 점은 그래서 처음 아이디어에서 퍼져 나가는 성장 경로의 여부는 알기 힘들다는 사실이다.

그럼 아이디어의 확장 여부를 예측 못한다면 다양한 아이디어중 어떻게 선택을 할 수 있을까? 대답은 실망스럽지만 또 한편 흥미롭다: 당신이 적합한 사람이라면, 당신에게는 그 아이디어를 찾아낼 감각이 있다. 당신이 빠르게 변화하는 분야의 최 선봉에 서있는데, 어떤 아이디어가 가치있다고 느껴진다면 그게  맞을 가능성이 많다.

“오토바이 관리와 명상” 이라는 책에서 Robert Pirsig은 이야기 하기를:

“페인팅을 최고로 잘 하는 방법을 알고 싶습니까? 쉽습니다.
먼저 최고가 되고, 그 다음 자연스럽게 칠하면 됩니다.”

고등학교에서 이 대목을 접한 이후 계속 궁금했다. 그게 페인팅에 얼마나 적합한 조언인지는 모르겠지만, 여기서 설명하는 상황엔 잘 맞아 떨어진다. 경험적으로 볼때 좋은 스타트업 아이디어를 찾는 방법은 그런 것을 갖을 수 있는 사람이 되는 것이다.

어떤 분야의 최첨단에 있다는 것은 꼭 기술을 만드는 사람을 의미하진 않는다. 사용자로서 최첨단에 서 있을 수 있다. 저커버그가 페이스북 아이디어를 생각한 것은 그가 프로그래머여서라기 보다는 컴퓨터를 워낙에 많이 사용했기 때문에 그랬다. 2004년 당시 40대의 사람들에게 자신의 일상을 인터넷에 반 공개적으로 포스팅 하면 어떨지 묻는다면 대부분 기겁했을 것이다. 하지만 저커버그는 이미 온라인에서 살고 있어서 그 아이디어는 자연스러웠다.

Paul Buchheit는 빠르게 변하는 분야의 최첨단에 서있는 사람은 “미래에 산다” 고 이야기 했다. 이 말을 Pirsig의 말과 합하면 이렇게 요약할수 있다.

“미래에 살아라 그리고 비어있는 것을 채워라”

이것이 현재 가장 성공한 스타트업의 시작 방식이다. 애플, 야후, 구글, 페이스북 모두 처음엔 큰 회사가 될지 상상 못했다. 모두 창업자들이 그 당시에 비어있다고 생각한 공간을 채운 결과물이다.

성공한 창업자들이 처음 아이디어를 얻은 방식을 보면, 그들의 준비된 마인드를 어떤 외부의 자극이 때려서 얻은 것이 많다. 빌게이츠와 폴엘런은 Altair에 대한 뉴스를 접하고  “우리가 베이직 컴파일러를 만들수 있을걸?” 생각했다. Drew Houston는 (Dropbox 창업자) USB 스틱을 자주 잃어 버린 후에 “내 파일들을 온라인에 모두 올려놔야겠어”라고 생각했다. 기존의 경험들이 창업자들을 미리 준비시켰기에 외부의 자극을 받았을때 기회를 포착하는게 가능했던 것이다.

스타트업 아이디어를 생각할때 써야 할 동사는 “생각해내기”가 아니라 “발견하기(알아채기)” 이다. YCombinator에서는 그런 아이디어를 자연스럽게 나왔다고 해서 “올개닉” 아이디어라 부른다. 성공한 스타트업은 그렇게 시작했다.

아마도 당신이 듣고 싶어한 대답은 아니었을지 모른다. 아이디어를 생각하는 어떤 레서피를 기대했을텐데, 나는 올바른 방식으로 준비된 마인드를 갖는게 핵심이라고 이야기 하니까. 실망스럽더라도 그게 진리다. 어떤 면에선 그게 레서피다. 다만 한주에 생각해내기 보다는 일년이 넘게 걸리는 레서피일 뿐이다.

당신이 빠르게 변하는 분야의 첨단에 서있는 상황이 아니라면, 그렇게 만들 수 있다. 예를들어 적당히 똑똑한 사람이라면 1년정도 시간을 투자해 프로그래밍의 최첨단에 서 있을수 있다 (모바일 프로그램을 만든다든지). 성공적인 스타트업이 최소 3-5년이 걸린다고 생각한다면 1년 정도 준비하는건 큰 투자가 아닐것이다. 특히 공동 창업자를 찾고 있다면.

최첨단에 서기위해 프로그래밍을 꼭 배울 필요는 없다. 다른 분야도 빠르게 변하니까. 해킹(코딩)이 반드시 필요한 것은 아니지만, 몇십년 미래를 보았을때 충분한 툴이 될 것이다. 마크 엔드리슨이 이야기했듯 소프트웨어는 세상을 먹어 치우고 있고 몇십년간 이 트렌드는 지속될 것이다.

해킹 할줄 안다는 것 (역: 해킹=코딩)은 아이디어가 생겼을때 구현이 가능하다는 뜻이다. 그게 아주 반드시 필요한 것은 아니지만 잇점이 된다. 당신이 대학교 페이스북을 온라인에 올리는 그런 아이디어를 생각한다면 코딩이 가능한 것은 사실 큰 잇점이다. 그저 “그거 괜찮은 아이디어네” 생각하기 보다 “오늘 밤에 초기버전 한번 만들어봐야겠다”는 생각이 훨씬 유리하다. 당신이 프로그래머면서 동시에 사용자라면 그건 더 유리하다. 새 버전을 만드는 것과 사용자 측면에서 테스트 하는것이 한 두뇌안에서 이루어지기 때문이다.

알아채기

어떤 형태로든 미래에 살고 있다면 스타트업 아이디어를 알아채는 것은 비어있는 공간을 찾는 것과 같다. 빠르게 변하는 분야의 최첨단에 있다면 확연히 비어있는 어떤 것을 발견 할 것이다. 그런데 확실하지 않은 한가지는 비어있는 그것이 좋은 아이디어인가 하는 점이다. 그래서 스타트업 아이디어를 찾을때는 단지 “뭐가 비어있지?” 라는 필터를 켜놓는 것 뿐 아니라 다른 필터들을 모두 꺼버리는 게 필요하다. 특히 “이게 큰 회사가 될까?” 이런 필터는 나중에 충분히 걱정할 시간이 있다. 초기에 그런 생각을 한다면 많은 훌륭한 아이디어를 필터링 해버릴 뿐 아니라, 별로인 아이디어에 집중하게끔 만든다.

비어있는 어떤 것들을 보는 것엔 시간이 걸린다. 자신에게 거의 속임수를 걸어야 주변에 있는 아이디어를 볼 수 있다.

하지만 당신은 아이디어가 거기에 있다는 것을 “안다”. 이 질문(아이디어가 과연 있을까?)엔 언제나 명확한 답이 있다. 오늘이 기술의 진보가 멈추는 바로 그날 이라고 생각하는 건 거의 불가능하다. 확신컨데 사람들은 다음 몇년간 새로운 것들을 만들 것이고 당신은 몇년후 “제품 x가 없을땐 어떻게 살았지?” 물을 것이다.

그런 문제들이 해결된 후에 과거를 돌아보면 너무나 당연해보일 것이다. 당신이 해야 하는 것은 그런 아이디어를 못보게끔 만드는 필터들을 모두 꺼버리는 것이다. 그런 나쁜 필터중 가장 강력한 것은 현재의 세계를 당연하다고 받아들이는 마음가짐이다. 우리중 가장 진보적이고 오픈마인드인 사람조차도 자주 그런다. 침대에서 일어나 현관문에 이르기까지 모든 것에 질문하지 않으면 아이디어는 없다

당신이 아이디어를 찾으려한다면 현재의 상황에 만족하면서 얻는 효율을 희생해야 하고 질문하기 시작해야 한다. 예컨데, 왜 당신의 이메일 인박스는 늘 차고 넘치는가? 이메일을 정말 많이 받으니까? 아니면 이메일을 지우기가 힘드니까? 왜 그럼 이메일을 그렇게 많이 받는가? 사람들은 무슨 문제를 해결하려고 당신에게 이메일을 그렇게 보내는가? 이 문제를 해결할 더 나은 방법은 없나? 왜 이메일을 인박스에서 꺼내기 어려운가? 왜 이메일을 읽은 후에도 남겨 놓는가? 이메일 인박스가 정말 최적의 툴인가?

당신을 괴롭히는 것들에 특히 주의를 기울여라. 현재 기술을 당연하게 받아들인다면  지금 인생이 효율적이고 편안하다고 느낄 것이다. 그러나 당신이 50년후에 우리가 사용할 어떤 것들을 모두 알고 있는데 지금 그것들이 주위에 없다면 현재의 날들은 아주 불편할 것이다. 한번 타임머신을 타고 50년전으로 돌아갔다고 상상해 보라. 어떤 것들이 당신을 짜증나게 한다면, 당신이 미래를 살고있기 때문인지도 모른다.

당신이 적절한 문제를 찾았다면, 그 문제는 (최소한 자신에게) 아주 분명하게 설명할 수 있을 것이다. 우리가 Viaweb 을 시작했을때 모든 인터넷 상점들의 사이트는 웹디자이너들이 하나 하나 HTML페이지를 써서 만들었다. 우리에게는 그 당시 그런 사이트의 HTML을 소프트웨어로 자동 생성해야 한다는게 너무 당연한 사실이었다.

그래서 스타트업 아이디어를 생각하는 것은 아주 당연한 것을 찾는 문제다. 좀 이상하게 들리는 이 프로세스는 이렇게 설명할 수 있다: “당신은 아주 당연한것을 찾으려 하는데, 그것을 아직 본적은 없다.”

당신에게 필요한 것은 마음을 좀 더 느슨하게 오픈하는 것이다. 이 문제에 직접적인 공격 (즉 앉아서 아이디어를 생각해내려 애쓰는것) 은 피하는 것이 좋다. 아마 최고의 전략은 그저 백그라운드 프로세스가 돌아가게 하고, 비어있는 것같은 어떤 것들을 찾아보는 것이다. 호기심으로 그저 어떤 어려운 문제를 해결해보려 노력해라. 하지만 또 하나의 당신을 백그라운드에 세우고 어깨 너머에 비어있는 것, 이상한 것들을 기록하게 하라.

자신에게 시간을 좀 주어라. 얼마나 빨리 자신의 마인드를 준비시키는가 여부는 당신에게 달려있지만 아이디어를 터뜨리는 외부의 자극은 당신 손에 달려있지 않다. 빌게이츠와 폴알렌이 한달안에 스타트업 아이디어를 생각하려 했다고 치자. 만일 그 한달안에 Altair가 나오지 않았다면 어떠했을까? 아마 덜 성공적인 아이디어에 매달렸을 것이다. Dropbox를 만든 Drew Houston은 Dropbox전에 별 가능성이 없던 SAT 준비 소프트웨어를 만들었다. 하지만 Dropbox는 시장성에서 그리고 그의 기술력에 있어서도 훨씬 더 나은 아이디어였다.

아이디어를 발견하도록 자신을 단련하는 방법은 뭔가 쿨해보이는 프로젝을 시작하는 것이다. 그러면 자연스럽게 비어있는 것들을 만들게끔 되어있다. 현재 존재하는 것들을 다시 만드는 것은 그렇게 재미있지 않으니까.

스타트업 아이디어를 짜내려 애쓰는 것은 나쁜 아이디어를 낳기 마련이다. 대신 “장난감”이라 치부되는 것들을 만들다보면 종종 좋은 것들이 나온다. 장난감이라 불리는 것들은 사실 “중요하다”는 점 빼고는 스타트업 아이디어의 모든 것들을 갖고 있다. 쿨하고 사용자들이 좋아한다. 그냥 중요하지 않은 것일 뿐이다. 하지만 당신이 미래에 살고 있고, 쿨한 어떤것을 만들어 사용자들이 좋아한다면 다른이들이 생각하는 것보다 사실 더 중요한 것일수 있다. 애플과 마이크로소프트가 마이크로컴퓨터를 만들때 그건 사실 장난감처럼 보였다. 그 당시 시대를 기억한다면 마이크로컴퓨터를 갖고있던 사람들을 “취미그룹, 동호회” 라 불렀던 것을 알 것이다. BackRub (구글의 스탠포드 시절 서버)은 별 의미없는 과학 프로젝트처럼 보였다. 페이스북은 학부생들이 다른 아이들 스토킹하는 사이트에 불과했다.

YCombinator에서 일하다보면, 전문가 포럼에서 “장난감”이라 무시하는 아이디어를 만드는 스타트업을 만날때 늘 흥분된다. 우리에겐 그게 좋은 아이디어라는 증거가 된다.

당신이 스타트업에 대해 좀 더 긴 플랜을 가질 수 있으면 (아마 빠르게 쥐어짜기 식으로는 사실 불가능할 것이다), “미래에 살고 비어있는 것을 채워라” 이 구절을 이렇게 더 나은 버전으로 만들 수 있다.

“미래에 살고 재미있어 보이는 것을 만들어라”

장관님, 이런 놈들을 찾으십니까?

이상한 녀석들

세인트루이스 도심 기차역에 어려서부터 말을 더듬었던 그래서 내성적일 수 밖에 없었던 한 10대 아이가 앉아있다. 아이는 복잡하게 얽힌 기찻길을 사고한번 없이 정교하게 지나가는 기차들을 경이롭게 바라보며 비디오로 찍어댄다.  그에겐 기차, 택시와 같은 교통수단들이 지점 A에서 지점 B로 정확하게 이동하는 그 과정이 참으로 신비하다. 호기심많은 이 아이는 또한 경찰과 앰뷸런스의 비상 라디오 채널에 무선 주파수를  맞추고 거기서 들려오는 “짹짹” 대는 듯한 짧고 강렬한 메시지들에 매료되어 있다. 그는 복잡한 교통 지도와 짦은 메시지로 표현되는 이 도심 전체를 재현해보고 싶었다. 그가 트위터를 만든 Jack Dorsey 다 [1].

dorsey

사진 1: 잘생겼다! Jack Dorsey

뉴욕주에 어려서부터 참 코딩을 좋아한 녀석이 있었다. 그는 갓 12살 되는 나이에 아버지의 치과 사무실과 집을 연결하는 메시징 프로그램을 만들었다. 아래는 그가 만든 홈페이지인데, 저 가운데 떡하니 박힌 공룡 눈깔은 90년대 너드의 풍모를 제대로 풍긴다.

mark zuckerberg

사진 2: 공룡 눈깔 홈페이지                                              사진 3: The Web

그런데 그중 “The web” 이라는 링크를 따라 들어가면 오른쪽 그림과 같은 사람과 사람이 연결된 복잡한 그래프가 나온다.  웹의 정의는 HTML 문서와 문서가 링크되는 것인데, 사람과 사람이 연결되는 그런 웹이라니…? 이것은 페이스북의  Mark Zuckerberg가 고1때 만든 홈페이지다 [2]. 짧은 스토리에서 드러나는 두 사람의 공통점이 있다. 어려서부터 프로그래밍을 참 좋아했고 잘했다는 것. 그리고,

남들이 쉽게 이해할 수 없는 아주 이상한 것에 꽃혀 있었다는 사실이다.  

한번 이런 상상을 해보자. 우리 동네에 어떤 형 하나가 있는데 말도 더듬고 내성적이다. 비디오 카메라를 가지고 전철역에 나가서는 기차가 왔다갔다 하는 모습을 항상 찍는다.  무전기를 꺼내 경찰의 신호를 도청하며 듣고, 복잡한 교통 지도를 뚫어져라 쳐다보곤 웃는다.  난 그 사람을 이렇게 부를거다: “동네 바보형”.

초딩? 코딩?

Jack Dorsey나  Mark Zuckerberg 이야기를 꺼내는 이유는 다름아닌 창조경제의 떠오르는 키워드 “초딩 코딩”을 다루고 싶어서다. 우선 나는 코딩을 일찍 가르쳐야 한다는 주장에 동감한다. 거의 모든 성공적인 해커들이 어려서부터 코딩했으니까. 아래 비디오에 나오는 강호의 고수들이 거짓말을 할거라 생각하지 않는다.

그러나 한가지 마음속 깊은곳부터 “그건 아닌데…” 라고 반항하는 이유는 아마도 우리 높으신 장,차관님들의 제한된 생각 때문인듯 싶다.

“우리나라 젊은이들이 능숙하게 컴퓨터 언어를 구사할 수 있도록 초등학생들을 대상으로 컴퓨터 프로그램 개발 교육을 진행할 예정이다. 어릴 때부터 컴퓨터 교육을 진행하면서 창조경제에 적합한 인재를 키워내겠다는 전략이다 [3].”

“윤 내정자는 ‘우리 아이들이 ICT로 발달한 결과물(게임, 인터넷)만 가지고 노는 것에 익숙하다보니 게임 중독도 나오고 인터넷 중독도 나오는 것’이라면서 ‘소프트웨어에 대한 체계적인 교육에 기반해 아이들의 놀라운 호기심과 능력을 직접 만들고 개발하는 쪽으로 돌릴 수 있다면… [4].”

창조형 인재를 “키워내겠다”는 의지는 고마운데 그 과정에서 혹시 저기 노량진역에 앉아 기차들을 비디오로 찍는, 말 더듬는 그런 아이 하나도 창조형 인재로 인정해 줄 수 있을까? 혹시 그런 아이들을 게임 중독에 빠진 아이와 같은 비 창조형으로 낙인찍진 않을까?

장관님, 저 코딩은 좀 합니다

이 동네에 만 34세에 코딩을 꽤 하는 사람이 있다. 실리콘밸리의 잘 알려진 스타트업에서 IaaS 클라우드를 만드는데 10개 넘는 언어중 아무거나 골라잡아 코딩할 수 있고, 리눅스나 윈도우즈든 가리지 않는다. 뭐 버는 것도 쏠쏠찮다. 그래서 뻔뻔하게 “장관님 저 코딩은 좀 합니다” 라고 이야기 할만한 그 사람은 바로 나다.

ujjurago

그런데 내겐 마음 한구석 늘 빈공간이 하나 있다. 나도 무언가 내것을 창조해보고 싶다. 내가 시작하는 스타트업을 하고 싶다는 생각은 10년 넘게 지겹게 날 쫓아왔다. 코딩 실력은 부족하지 않다. 20대만큼 잠 적게 자며 코딩할 수 있는 자신도 있고 체력도 있다. 늘 하는 이런 고민을 하던중 얼마전 새벽 갑자기 스치는 생각에 놀라 잠에서 깼다.

내게는 비젼(Vision) 이 없구나.

아니 사실은 예전 블로그에서 이야기 했듯  미국의 너드 프로그래머들 사이에서 코딩하는 그 비젼은 있었고 이루었다 [링크]. 하지만 넘치는 코딩 능력과 열정을 쏟아부어 이루고 싶은 그림, 오랜 시간 집착하게 만드는 그런 그림이 내게는 없었다. 붓도 물감도 모두 준비되었지만 꼭 그려내야 할 나만의 세계관이 없었다.

SW 스타트업 – 집착(Obsession) 과 비젼

Jack Dorsey가 어린시절 빠져있었던 것은 도심의 복잡한길을 정교하게 통과하는 기차, 택시 그리고 그것들이 만들어내는 “짹짹”대는 소음들이었다. 그 집착(Obsession)이 코딩을 만난 결과물이 트위터다.  Mark Zuckerberg는 문서와 문서가 연결되는 웹이 아닌, 사람과 사람이 연결되는 웹을 생각했다. 고1때 그런 웹을 생성하는  Java프로그램을 홈페이지에 올렸고, 훗날 하버드 기숙사에서는 Facemash라는 해킹을 통해 사람과 사람을 연결하는 집착을 지속했다. 요즘 가장 잘 나가는 스타트업 Pinterest를 시작한 Ben Silbermann은 어려서부터 우표, 돌, 곤충을 수집했고 자신이 수집한 것들이 자기를 표현한다고 믿었다 [5]. 최근 가장 크게 주목받은 Tumblr의 David Karp는 고등학교를 중퇴해 처음 일한곳에서 블로깅 사이트를 만들다가, “‘this blogging thing is too hard”라 선언하며 사용자 친화적인 블로그에 집착했다. 어려서부터 지속되는 바보같은 집착이 코드를 만날때, 집착은 비전이 되고 코드는 전세계에 그림을 그린다.

pinterest

사진 4: Pinterest – 온라인 곤충 수집

우리 아이들

창조경제의 핵심이 SW라고 믿는다면, 창업자들의 독특한 세계관에 대한 “집착”에 대해서도 이야기 해야 한다. 지금 우리 눈에 바보처럼, 엉뚱한 짓거리 하는 것처럼 보이는 아이의 집착을 과연 우리는 용납할 수 있을까? 나는 30대 중반에서야 깨달은 이 SW의 진실이 참 억울하다. 80-90년대를 지나며 그런 바보짓할 여유를 주지 않았던 부모님과 한국 학교, 사회가 참 야속하다. ‘만일 그때 나도 Jack처럼 비디오 카메라 들고 전철역에 앉아 있었더라면….’. 지금도 분명 우리 가운데 Jack같은 아이들이 초등학교, 역전, 시장통 어딘가에서 엉뚱한 짓거리를 하고 있을거다. 그 아이들에게 코드는 가르치자..그리고 그 집착은 눈감아주자… 

— 박상민  https://twitter.com/sm_park

[1] http://www.vanityfair.com/business/features/2011/04/jack-dorsey-201104
[2] http://www.huffingtonpost.co.uk/2013/04/04/mark-zuckerbergs-first-website-angelfire-screenshots_n_3012148.html
[3] http://news.inews24.com/php/news_view.php?g_serial=746979&g_menu=020400&mains=News
[4] http://media.daum.net/digital/others/newsview?newsid=20130324164805713
[5] http://money.cnn.com/gallery/magazines/fortune/2012/10/11/40-under-40.fortune/18.html