얼마전 제게 소프트웨어 개발과 오픈소스에 대해 인터뷰를 부탁하셔서 평소 생각을 말씀 드렸는데 여러 사람들 의견을 모아 책으로 출간이 되었네요. http://jpub.tistory.com/366

인터뷰의 질문과 답 모두 의미가 있는 것 같아 블로그로 공유합니다.

Q: 중국, 인도, 영국 등에서 코딩교육을 의무화한다고 합니다. 국내에서 조심스럽게 프로그래밍을의무교육-입시화 하자는 얘기가 제기되었습니다. 비슷한 맥락에서 ‘10만 SW인력양성론’을 주장하기도 합니다. 조기에 SW를 접하는 것이 중요하다든지, 정책적 차원에서 SW인력을 길러내는 것이 필요하다는 주장에 대해 어떻게 생각하시는지요?

A: 기본적으로 어린 나이에 코딩을 접해야 한다는 것에 동의합니다. 페이스북의 마크 져커버그는 아주 어려서부터 프로그래밍을 했고, 12살 나이에 이미 아버지의 치과 사무실에서 사용하는 메신져 프로그램을 만들었습니다. 져커버그의 관심을 파악한 부모는 코딩 과외를 시켜주기도 했습니다. 트위터를 만든 잭 도시, 텀블러의 데이빗 카프등 거의 모든 소프트웨어 창업자들은 초등학교, 늦어도 중/고등학교 시절부터 프로그래밍을 했습니다.

그런데 어릴적부터 프로그래밍을 해야 하는 이유가 중요합니다. 좀 더 빠르게 접해서 단지 더 많이 배우게 하거나, 코딩을 아주 잘하는 기술자로 만드는게 목적이 아닙니다. 어린 시절에 코딩을 시작하면, 주변에서 접하는 사소한 “문제(Problem)”들을 프로그래밍으로 해결하기 시작합니다. 즉, 져커버그가 아버지 치과 사무실과 자신의 집을 연결시키는 메신저를 만든 이유는, 아버지와 가족이 일하면서도 대화를 나누는 “문제 해결”을 한 것입니다. 계속해서 주변에 존재하는 “문제”들을 인식하던 결과물이 훗날 소셜 네트웍이라는 대박 “문제”를 해결한 페이스북입니다. 어른, 특히 대학교 이후에 직업을 위해 코딩을 배운 사람들은  분명 존재하지만 쉽게 알아채기 어려운 이런 문제들을 발견 못합니다.

한국의 소프트웨어 회사들중 “문제”를 처음 발견하고 그걸 해결한 곳은 거의 없습니다. 네이버는 구글이 발견한 문제를, 삼성은 애플이 발견한 문제를, 다음은 야후가 발견한 문제를 자신들 역시 해결한 것 뿐입니다.  흔히 창의력이 없다 라고 이야기하는 것이, 바로 문제를 발견하는 눈이 없다는 뜻입니다.

프로그래밍 조기 교육 주장의 문제는, “10만 SW인력 양성론”에서 드러나듯 그 목적이 단지 많은 기술자를 양성하려 하는데 있습니다. 기술자를 만들어내는 것은 대학교 교육으로 충분합니다. 절대 프로그래밍은 어려서부터 배워야할만큼 어렵지 않습니다. 우리가 가르치는 목적은 어려서부터 주변의 문제들을 파악하는 감각을 기르기 위함이고 따라서 커리큘럼등이 이에 초점을 맞추어서 만들어져야 합니다.

Q: 오픈소스 관련 한 벤처대표는 오픈소스는 공짜라기보다는 ‘자유’다라고 강조하셨습니다. 참여와 공유를 강조하는 측면입니다. 박상민 연구원님은 블로그에서 “오픈소스가 한국 SW의 근본적 해결”라고 적으셨습니다. 국내에서는 안타깝게도 FTA 이후 오픈소스 관련 분쟁사례가 늘어나고 있는데요. 이 때문에 오픈소스 거번넌스 체계가 시급하다는 지적이 있습니다. 오픈소스의 본질(가능성)은 무엇이라고 생각하십니까? 아울러, 현실에서 오픈소스에 대한 이해 부족 혹은 오해와 곡해를 통한 저작권 침해 등을 해결하기 위한 방안은 무엇이라고 생각하십니까?

A: 그 대표분 말씀대로 오픈소스는 공짜가 아닙니다. 저희 회사 Eucalyptus systems는 모든 소스코드를 github을 통해서 공개하지만, 고객들에게 돈을 받고 소프트웨어를 배포합니다. 저희 회사 CEO는 그 전 오픈소스 회사 MySQL을 1조원 넘는 가격에 팔았습니다. 그래서 흔한 질문이 “소스 코드를 공개했는데, 왜 내가 돈을 지불해야 하는가?” 부분입니다. 답은 “소스코드는 소프트웨어의 단지 한 부분” 이라는 사실입니다. 코드이외에 실제 소프트웨어를 운영하기 위해선 다른 기술들 (패키징, QA)과 고객 서비스 (24시간 콜센터등)가 필요합니다. 그래서 오픈소스 제품을 사는 사람들은 소스를 사는 것이 아니라, 오픈소스 회사의 모든 서비스를 구입하는 것입니다. 반대로 이런 서비스를 구입하지 않고 소스코드만 가지고 스스로 패키징, QA, 서비스 조직을 만들어 운영하는 곳도 있습니다. 저희 CEO의 말을 빌리자면, “어떤 사람들은 돈이 많아서 시간을 절약하고, 어떤 사람들은 시간이 많아서 돈을 아낀다”고 합니다.

오픈소스는 두가지 측면이 있습니다. 첫째는 문화적인 측면입니다. 미국에 끊임없이 소프트웨어 회사가 생기고 회사들이 빠른 시간에 성장하는 이유는 저변에 셀수 없이 많은 오픈소스 해커들이 있기 때문입니다. 스티브 워즈니악이 PC를 취미로 만들고 공유하던 동호회에서 시작한 회사가 애플입니다. 리누스 토발즈는 주말에 시간내서 소스코드 관리툴 git 을 만들었는데, 그 툴을 좋아한 젊은이 둘이 웹 버젼으로 만든 github은 전 세계에서 가장 잘 나가는 스타트업이 되었습니다. 주말에 취미로 만들고 코드를 공개한 소프트웨어가 참여, 공유를 통해서 스타트업, 대기업이 되는 것입니다. 또한 회사가 빠른 시간에 성장하기 위해서는 능력있는 개발자가 많아야 하는데, 오픈소스 문화가 그런 고급 인력을 지속적으로 공급해 줍니다.

두번째는 기업에 도움이 된다는 측면입니다. 최근 몇년사이에 미국에서는 <스타트업은 오픈소스 해야 한다>는게 일종의 불문율입니다. 이유는 주 구매층인 중견 기업, 대기업들이 이를 원하기 때문입니다. 기업들은 몇십년간 마이크로소프트, 오라클등에 종속(lock-in)되어서 어쩔수 없이 많은 지출을 해야 했는데, 이제는 Linux, MySQL등  품질은 비슷하지만 적은 비용으로 소프트웨어를 운영하는 대안을 선택합니다. 80년대-2000년대까지는 소프트웨어의 “품질”이 최고의 요구사항 이었다면, 품질에 차이가 거의 없는 지금은 “자유”, “선택”이 소프트웨어 구매의 최고 요구사항입니다. 코드를 직접 볼 수 있고 필요하다면 구매하지 않고도 소프트웨어를 운영할 수 있는 오픈소스가 이기는게 당연합니다.

개인적으로 한국에 가장 필요한 것은, 성공적인 오픈소스 회사의 등장이라고 생각합니다. 프로그래머들에게조차 오픈소스는 괴짜들이 하는 취미 정도로만 인식되는게 현실입니다. 오픈소스는 취미일뿐 아니라 성공적인 기업 모델입니다. 오픈소스의 전도사 역할을 할만한 회사가 대기업 가운데서도 나와야 하고, 스타트업중에도 성공하는 회사가 있어야 합니다. 법, 제도적으로는 기반이 없는 지금 그런 회사들을 띄워줄 (Bootstrap)만한 지원이 있어야 한다고 생각합니다.

Q: 블로그에 보면 ‘제큐어웹(XecureWeb)’으로 인한 한국 보안 인증체계의 문제점을 언급하셨습니다. 외국에 비해 국내 보안 체계는 매우 복잡하고, 사용자에 책임을 전가한다는 지적이 있습니다.한국과 미국 보안 인증 체계의 차이점은 무엇이라고 보시는지요?

A: 질문과는 반대로 사실 가장 큰 차이는 미국은 사용자에 책임을 지우는 반면, 한국은 정부가 사용자를 보호하려는 의도가 아주 강합니다. 미국의 경우 예를들어 아마존에서 쇼핑을 하면 클릭 한번 하는 것으로 결재가 끝납니다. 구매의 전 과정에서 정부가 규제하는 것은 단 하나도 없습니다. 반대로 한국의 경우 정부가 사업체에 보안 인증을 강제하니까 제품을 한번 구매할때마다 ActiveX, 키보드 보안 프로그램등을 강제로 설치해야 하죠.

정부의 의도가 완전히 잘못 되었다고 생각치는 않습니다. 컴맹이고 나이 든 분들께는 보안을 강제 하는 것이 효과를 발휘할 수도 있습니다. 그러나 소프트웨어는 보안과 뛰어난 사용자 경험이 꼭 밸런스를 맞추어야 합니다. 한국정부는 지나치게 국민을 신뢰 못하는 나머지 보안쪽에 너무 큰 무게를 두고 사용자 경험을 무시했습니다. 웹기업 들이 창의적으로 만들 수 있는 뛰어난 사용자 경험이 정부에 의해 근본적으로 막힌 것입니다. 보안, 인증 체계는 기업들이 만들어야 하고, 자연스럽게 더 나은 보안 체계를 갖춘 회사들이 시장에서 성공해야 합니다. 그런데 정부가 모든 보안의 키를 쥐고 있으니까 오히려 기업들에서는 보안에 신경을 쓰지 않게 되고, 결과적으로는 더 위험한 웹이 되었다고 생각합니다. 지금의 정부 규제는 보안에서, 사용자 경험면에서 모두 실패입니다.

Q: 정부 주도의 진흥 혹은 규제보다는 서비스 사용자 중심의 시장에 의해 성공하는 SW가 나올 것이라는 얘기가 많습니다. 바람직한 SW정책 혹은 SW정책의 방향성은 무엇입니까? 더불어 창조적인 아이디어가 인정받고 스타트업이 시장을 이끌어나가기 위해 한국에서 가장 시급한 과제는 무엇이라고 판단하십니까?

A: 이미 크게 성공하고 있는 카카오톡, 라인등에 정부가 한 역할이 조금이라도 있었을까 궁금합니다. 스타트업이 성공하는 과정에서 대기업등에 의해 불이익을 받지 않도록 보호 해주는 역할 정도가 정부가 해야 할 것으로 생각합니다. 또한 창업자들이 빛을 지거나 신용불량이 되는 등 사업의 결과에 의해 불이익을 받는 일이 없도록 해야 합니다. 실패하면 잃을것이 너무 많은 환경에서 누가 시작을 하겠습니까?

정부 보다는 스타트업으로 이미 성공한 사람들이 투자자, 멘토 역할을 해서 다음 세대를 이끌어야 합니다. 유명한 벤처기업가 폴 그레이엄은 자신의 스타트업을 성공시킨 후 YCombinator를 만들어 매년 수십팀의 스타트업에 초기 자금을 지원하고 멘토링을 해왔습니다. 여기에서 드랍박스, AirBnB와 같은 걸출한 스타트업들이 나왔고 수십조원 가치의 회사들을 탄생시켰습니다. 아마존의 제프 베조스는 구글 창업자 둘의 가능성을 보고 맨 처음 몇억을 투자 했습니다. 우리 역시 성공한 사람들에 의해 다시 투자 되는 벤처 생태계가 필요합니다. 최근 모바일 생태계 조성을 위해 100억 투자를 약속한 카카오 김범수 의장이 좋은 예입니다.

정부가 중점적으로 해야 할 과제는 소프트웨어 문화를 진흥시키는 것이라 생각합니다. 소프트웨어 문화의 핵심은 오픈소스 입니다. 취미로 주말에 코딩을 하는 학생들, 직장인들의 수와 국가의 소프트웨어 경쟁력은 정확히 비례할 것입니다. 학교, 기업들에서 적극적으로 오픈 소스를 도입하고 개발하도록 정부가 지원을 해야 합니다. 앞에서 이야기했듯 오픈 소스는 문화이면서 또한 강력한 경쟁력입니다.

Q: 이번 책의 컨셉이 ‘SW로 성공한다는 것’입니다. 과연 SW의 성공은 어떤 의미라고 생각하시는지요? SW로 성공한다는 것(개발자들의 입장에서)과 SW가 성공한다는 것(제품 혹은 서비스의 입장에서)으로 나누어서 생각해볼 수 있을 것 같습니다. 이에 대해 마지막으로 사례를 포함해서 답변해주시면 감사하겠습니다.

A: 개발자의 입장에서 SW로 성공하는 것은 직업이 즐거움이 되는 것입니다. 한국에서 개발일을 하며 힘들어 하고 불평하는 친구들을 많이 봅니다. 이것은 이상한 현상입니다. SW를 개발하는 과정은 즐거움의 연속이어야 합니다. 오픈소스 개발자들은 직업으로 코딩하는 그 시간만큼 저녁이나 주말에 프로그래밍합니다. 이유는 단 하나 그것이 즐겁기 때문입니다. 소프트웨어를 만드는 것은 스스로 조물주가 되어 생각하고 행동하는 창조물을 만드는 것입니다. 이건 아주 중독성이 강한 즐거움이기 때문에, 경제적으로 아주 성공한 사람들 (예를들어 폴 그레이엄)이 나이 들어서도 코딩하는 것입니다. 미국의 경우 개발자들은 의사를 제외하고 가장 높은 연봉을 받는 직군입니다. 매일 놀이를 하면서 경제적으로 여유롭게 살 수 있는 것은 아마도 SW 개발자들만 누리는 성공이라고 생각합니다.

하지만 위의 설명에서 한가지 빠진 조건은 “능력있는” 개발자가 되어야 한다는 것입니다. 개발을 즐거워 하는 정도와 능력은 정확히 비례합니다. 프로그래밍을 싫어하면서 능력있는 사람은 한번도 못 보았습니다. 프로그래밍을 좋아하는데 능력이 없는 사람은 있을 수 있습니다. 그건 학생이거나 해서 아직 경험이 부족하기 때문입니다. 시간이  지날수록 코딩을 좋아하는 사람들은 능력있는 사람이 되고 경제적으로 여유로워 집니다. 이것이 개발자의 성공이라 생각합니다.

제품/서비스 입장에서 SW가 성공하는 것은 “문제를 해결”하는 것입니다. 모든 성공한 제품은 사람들이 갖고 있는 공통된 문제점 한가지를 해결한 것입니다. 구글은 “알고 싶다”, 아마존은 “사고 싶다”, 페이스북은 “친하고 싶다”, 트위터는 “말하고 싶다”는 문제를 해결한 것입니다. 해결하는 고통의 정도가 크면 클수록 서비스는 더 크게 성공합니다. 구글이 해결한 “알고 싶다”의 문제의 깊이와 현재 구글의 300조 주식 가치는 정확히 비례합니다. 아마도 트위터가 절대로 구글보다 커질 수 없는 이유는 “말하고 싶다”는 본능이 “알고 싶다”는 욕구보다 더 작기 때문일 것입니다.

앱스토어에 출시된 수십만개의 앱들 대부분이 가치가 없는 이유는, 아이디어가 기발하지만 사실 아무 문제도 해결하지 않기 때문입니다. 그중의 아주 소수 앱들만이 사람들의 문제를 해결해주고 성공합니다. 그런데 대부분의 사람들은 주변에 존재하는 문제들을 무시하고 상상속에서 문제를 만들어내 SW로 해결합니다. 제프 베조스는 인터뷰에서 “사람들은 새로운 문제를 해결하려고 하지만, 우리는 이미 다 알고 있고 고통이 큰 문제 (싼 가격에 물건사서 빠르게 받는것)를 해결합니다” 라고 이야기 했습니다.

트위터, 블로거, 미디움 세개의 서비스를 연속해 성공시킨 에반 윌리엄스는 사람들의 공통된 문제중 하나를 골라, ‘기다리기 싫어함’, ‘생각하기 싫어함’ 두가지만 SW로 해결해주면 스타트업은 반드시 성공한다고 이야기 했습니다. 그래서 SW의 성공은 고통의 정도가 큰 문제를 발견하는 것에서 시작합니다. 내가 만드는 SW가 사람들의 고통을 해결해 주는 것은 SW개발하는 과정 만큼이나 즐거운 일입니다.

https://twitter.com/sm_park

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

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

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

집에서 일하는 사람의 일상

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

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

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

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

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

새로운 형태의 조직

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

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

문제부터 생각할때

성공한 스타트업은 모두 문제에서 시작한다. 트위터의 창업자지만 세력 다툼에서 밀린 잭 도시(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는 내성적이라 여친을 사귈 수 없었던 쥬커버그가 여학생들 사진을 스토킹하며 문제를 해결한 방식이었다. 사소한 문제를 해결하다보니 소셜 네트웍이라는 대박 문제를 얻은 것이다.

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

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] 장관님, 이런 놈들을 찾으십니까?

아래의 글은 최근에  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에서 일하다보면, 전문가 포럼에서 “장난감”이라 무시하는 아이디어를 만드는 스타트업을 만날때 늘 흥분된다. 우리에겐 그게 좋은 아이디어라는 증거가 된다.

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

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

흔히 해커들은 어려서부터 프로그래밍에 빠졌다고 고백하는 경우가 많다. 솔직히 나는 아니다. 인문학부로 막 대학에 들어간 첫해는 국사, 국문, 영문과마다 MT를 따라다니며 그때까지 남아있었던 인문학의 끝자락 낭만을 구경했다. 제 멋대로 머리기르던 “스티븐 시발”형들이 길목마다 가득했다. 절친 형이 컴퓨터를 너무 사랑해 밤마다 프로그래밍 하던 모습이 사실 그것보다 더 좋아보였다. 그래서 컴퓨터과에 전과를 했다.

고등학교부터 인문학돌이였던 내가 그렇게 첫 프로그래밍 수업을 들었다 (참고로 나는 수능 언어영역에서는 늘 99.9% 에 들었고, 수리 영역에서는 50%를 간신히 턱걸이했다). C언어를 하는 그 수업에서 이렇게 생각했다. “아 처음이라 어렵긴 하구나…”.  두번째 수업을 마치고 “확실히 이과 애들은 다른가보다. 생긴것들 봐봐….”.  막 전과한터라 도움 받을 사람도 없이 결국은 학기말까지 이해 안되는 코딩…어떻게든 버텼고 랩실에서 기말 시험을 보았다.  시험 내용은 아마도 Sorting 알고리즘 하나를 구현하는걸로 기억한다. 그런데…

‘컴파일이 되지 않았다.’…

시험 마치기까지 데이터 정렬을 하기는 커녕 프로그램이 컴파일조차 안됐다. 조교가 결과값을 확인하러 왔을때 결국 컴파일 에러가 가득한 모니터를 보여줄 수 밖에 없었다. C언어 수업 결국 C를 받았다. 그날 부끄러워서 조교형 얼굴도 못쳐다보며 컴퓨터실을 나오고 마음속에 무언가 감정이 솟구쳤다.

학부 3학년, 때마침 한국은 벤처의 광풍이 몰아쳤다. 앞에 소개한 형이 한 벤처 회사의 CTO가 되었고, 그동안 간신히 덜덜덜 거리며 프로그램 수업듣던 내게 일을 제의했다. 일년간 정말 열심히 코딩했다. 낮에는 학교를 다니고 밤에는 코딩하다가 회사의 아주 조그만 서버실 뒤에서 매트리스를 깔고 잤다. 너무 생각을 많이해 때로는 꿈에서 알고리즘을 얻기도 했다. 아침에 회사 화장실에서 대충 머리를 감고 나오자면 청소부 아줌마가 늘 ‘저건 뭐하는 자식이야?…’ 이런 얼굴로 쳐다보던 기억이 난다.

이제 어느정도 자신이 있었다. 그당시 비지니스 모델 찾는다고 마음만 바쁘던 회사는 처음으로 (대기업!) 나우누리에서 프로젝을 수주했다. 그런데 사실 개발 경험이 거의 없던 회사였던지라 진도가 영 부진했다. 간신히 apache, tomcat 셋업하고 자바 서블릿 튜토리얼 보아가며 ‘달달달’ 겨우 코딩하던 꼬꼬마였다. ‘갑’ 나우누리는 진도가 안 나오는 우리를 전화로 닥달하다가 결국 개발자 보내라고 요구했다. 아…가지 말았어야 했는데, 왜 그랬는지..이제 겨우 학부 3학년 꼬꼬마가 그곳에 갔다. 그래도 ‘갑’이 부르시니 좋은거 입고 가야한다고…아 그러지 말았어야 했는데..은갈치 정장을 입고 갔다.

개발자들 수두룩하고 터미널이 가득한 커다란 방에 은갈치가 던져졌다. 그리고 데모를 해야 하니 준비를 하란다. 윈도우즈가 세상의 전부인줄 알았던 나는 리눅스를 배운지 이제 갓 몇주. “ls” “cd” “mkdir”..이런 단 몇개의 커맨드라인으로 무장한 나를 유닉스 터미널에 앉혀놓고 다시 올테니 데모를 준비해 놓으란다. 정장을 하고 앉은 나는 땀을 삐질삐질 흘리며 그렇게 갑의 회사 터미널에 한시간동안 ls, cd만 쳐대고 있었다. 결국 그날 갑의 팀장에게 정말 무섭게 혼나며 세상맛을 보았다. 속으로는

‘저 이제 학부 3학년 어린이예요..리눅스 지난주에 배웠어요’

말하고 싶었지만 분위기상 혼나는게 맞았다. ‘아 처음 만나는 사람에게도 혼날수 있구나’ 그날 알았다. 그렇게 그곳 개발실을 나오며 마음속에서 무언가 또 솟구쳤다.

몇년후, 이전 블로그에서 소개했던 내용이 계기가 되어 유학을 나왔다.(https://sangminpark.wordpress.com/2011/09/15/%EB%B9%84%EC%A0%84-%EB%88%88%EC%9C%BC%EB%A1%9C-%EB%B3%B4%EB%8A%94-%ED%96%89%EC%9C%84/) 비록 학부 학점은 요즘 류현진 방어율 비슷하지만 코딩은 이제 제법 자신있었다. 게다가 다른 신입생들과 다르게 나는 이미 여러편 논문을 쓴 경험이 있었다. 미국에서도 잘 할것 같았다. 두학기 지난후 퀄 시험이라는 박사자격시험을 보았다. 안될것같은 학생은 미리 걸러내는 시험이다. 열심히 준비했다. 아직 20대 초반 어린 아내가 싸준 도시락 도서관에서 같이 먹으며 공부했다. 아 이렇게 많이 배우는구나 생각했다. 시험을 치뤘다 그리고..

‘나는 한 문제도 맞추지를 못했다….’

아니 정확히 표현하면, 무어라고 답을 적어낸 문제가 거의 없었다. 빈 종이를 내고 나오며 혹 교수님과 눈이라도 마주칠까 부끄러웠다. 집에 돌아와 걱정 가득한 얼굴로 맞아준 아내를 방에서 나가게 하고 그냥 침대에 누웠다. 살면서 처음으로 ‘정말 안될것 같다’ 라는 패배감이 가득했다. 아마 한 문제만 제대로 답을 써봤어도 그렇진 않았을텐데…간신히 잠을 청하고 저녁즈음 일어나며 드는 어떤 감정이 있었다.

돌아보면 세가지 일을 겪은후 마음속을 가득 채운 그것은 “분함”이었다. C학점을 받은것도, ‘갑’에게 혼났던 것도, 빈 답안지를 냈던 것도 모두 내 모자람때문이었는데 나는 왜 그게 그렇게 분하고 원통했는지 모른다. “분함”이란 풀어 쓰자면, “두고봐라 내가 지금은 이래도 앞으로는 달라질 거다” 라는 일종의 선언이다. 그렇게 처음 분함을 품은지 10년이 좀 더 지났다. C코드 컴파일도 못시키던 꼬꼬마가 지금은10개 정도 언어로 몇십만 라인 코드를 짜고 있다. 리눅스를 몰라 ls, cd만 땀흘리며 톡톡댔었는데 지금은 ubuntu, redhat 사람들과 같이 일을한다. 정말로 안될줄 알았던 퀄시험도 그냥 책을 통째로 외우는 비장함으로 마쳤다.

이렇게 개인적 일화를 길게 적어간 이유는 “다 잘되었노라” 자랑하기 위함이 아니다. 나는 이 “분함”이 한국인이 가진 가장 강한힘이라 생각하기 때문이다. 지난번 블로그를 올린후 누군가 한국인으로서의 강점이 무엇인지 물었다. 우리는 미국과 같은 잉여 문화도 없고, 거대한 오픈소스 커뮤니티도 없다. SW를 제대로 만들어본 경험도 없다. 무엇일까…나름 고민을 하다가 결국 다다른것은 우리에겐 이 “분함”과 같은 강한 감정의 힘이 있다는 사실이다. 미국인 동료들과 일하며 그들의 너드스런, 잉여스런 집착에 감탄하고, 정말 화려한 코딩 실력에 많이 감동할때가 많다. 하지만 한국인 동료들만큼 자신의 코드에 감정적으로 접착(attach)되는 사람은 별로 못 보았다. 때로 우리는 툴툴대긴 하지만, 주말에도 밤에도 코딩할만큼 자신의 일에 감정적으로 몰입한다. 혹 누군가 내 코드가 영 별로라고 말하면 미국 사람들은 “입닫고 저리 가” 하겠지만, 한국 사람은 그말이 분해서 디버그하고 또 디버그한다.

우리가 가진 이 강한 감정의 힘. 이것이 어떻게 일상의 행복, 잉여의 문화와 결합할 수 있을까?…추상적인 질문이지만 개인적으론 여기에 SW의 해결이 있지 않을까 생각한다. 우리 한국인 고유의 감정의 힘과 잉여스러움의 조화…언젠가 멋지게 어우러지는 날이 오지 않을까?

1. 얼리아답터

언제부터인가 난 얼리아답터 (early adapter) 였다. 아마도 10년전쯤 나온 PDA 소니 클리에를 사면서 시작된것 같다. 지난번 포스팅한 너드들 특징중 하나가 바로 이 얼리아답터 성향이다. 남들은 아~무도 신경 안쓰는 새 전자기기를 부모님들이 알면 까무라칠 가격으로 사들인다. 그리고 어딜 갈때든 주머니속에 꼬옥 넣고 다니다가 괜히 한번씩 꺼내보고는 씩 웃는다. 몰려든 여동생들이 “와 오빠 이거 신기하다~” 외치면 기분이 업되서 한참동안 어썸한 기능을 설명하곤 한다 (하지만 결혼을 하고 여자의 심리를 좀 더 이해한 지금, 여자들의 감탄에 속지 말아야 함을 밝힌다). 곧 아주 간단한 기능들 – 예를 들어 바로 옆 메모지를 놔두고 기어이 PDA에 꾹꾹 노트를 입력하는 일 -을 데모하다보면 안쓰럽게 바라보던 여동생들은 어디로 사라지고 나와 PDA만 남곤했는데…

2002년 로망 클리에

새 기계와 소프트웨어로 마냥 행복할 것 같은 얼리아답터에게도 고통은 있다. 초기 제품들의 “버그” 때문이다. 새 제품 A가 출시되면 얼리아답터 커뮤니티는 (예: clien.net) 흥분의 도가니가 된다.  A의 새 기능들을 침이 마르도록 칭찬하고, 서로 서로 지름을 권유하고 축하한다. 하지만 이도 잠시, 곧 몇주가 지나고 나면 하나 하나 발견해가는 A의 버그로 인해 게시판이 서서히 불만으로 달구어진다. 곧 나온다던 SW 업데이트가 미뤄질수록 게시판의 분노는 점점 하늘을 찌르고, 누군가 당기면 촛불시위라도 시작할듯 A에 대한 첫사랑은 잊혀지고 만다.

그런데 3년전 나는 색다른 커뮤니티 경험을 했다. 아마존에서 이북리더 킨들이 나오기 전 네델란드의 iRex라는 회사에서 DR시리즈라는 이북리더를 출시했다. 당시 DR시리즈는 여러가지로 혁신적이었는데, 8″와 10″의 대형 스크린, 와콤 타블릿등  e-ink 디바이스의 매력을 처음으로 제대로 보여줬다. 그게 너무 갖고 싶어 가난한 유학생임에도 난  8″와 10″ 두 버전을 연이어 약 $400, $600 의 가격으로 샀다. 그리고 곧 인터넷의 DR시리즈 포럼에 드나들기 시작했다. 하지만 곧 얼리아답터의 고통이 비싼 가격만큼이나 강렬하게 찾아왔다. 수없이 많은 버그들을 발견했고, 어떤것들은 너무 치명적이었다. 그런데 곧 SW를 업데이트한다던 회사는 몇달이 지나도 감감무소식이었다. 더이상 참을 수 없던 나는 회사에 항의 메일을 써보내기 시작했고 나와 함께할 “동지”가 없는지 게시판 분위기를 살폈다. 헌데, 그곳 포럼은 이상하리만치 차분했다. 어떤 사람은 DR시리즈의 소프트웨어를 분석하며 왜 업데이트가 늦는지 설명했고 (그곳 직원이 아님에도), 어떤 사람은 DR이 오픈소스였던걸 활용해 몇가지 버그를 고쳐서 사람들에게 배포했다. 난 전공이 CS요, 시간많은 대학원생이었음에도 항의 메일이나 보내고 있는데, 비전공자를 포함한 너드들은 직접 문제를 해결하기 시작한 것이다.

몇년이 지나고 오픈소스 회사에서 일하고 있는 지금에서야, 그 경험이 바로 실리콘밸리의 고유한 해커 문화인걸 깨달았다.

2. 갑과 을 – 고통스런 파트너

뼛속 깊이 한국인인 내게 우리 소프트웨어 업계를 지배하는 ‘갑’과 ‘을’의 문화는 당연하게 다가온다. 얼마전 대기업에서 일하는 선배형이 페이스북에 남긴 메시지는, “금요일 퇴근하며 을에게 전화해 월요일까지 고칠수 있냐고 물었다. 미안하지만 할수없지….” 이런 것이었다. 여기서 SW개발을 두고 벌어지는 ‘갑’과 ‘을’ 가상의 시나리오를 한번 펼쳐보자.

• 갑: 데이터 정렬(sorting)하는 프로그램 필요한데, 누가 해볼래?
• 을:  제가 할 수 있습니다. 맡겨 주십쇼!
• 갑: 기한은 일주일. 오케이?
• 을: [월-화요일: 디자인] 바쁘다 바빠, quicksort를 쓸까 mergesort를 쓸까? [수-금요일: 구현] 제일 빠른 quicksort로 구현하자. 거의 다 됐다.
• 갑: [금요일 오후] 아 참, 데이터 추출이 많은데, 당연히 해쉬테이블 썼지?
• 을: 그런 얘기 안 하셨잖아요 ㅠㅠ
• 갑: 그랬나?…이런 미안 ^__^ 월요일날 봐~
• 을: [토-일요일]  출근하며 핸펀주소록 갑의 이름을 “멍멍이 키즈”로 바꿈.

스펙을 중간에 바꾸는 ‘갑’의 부도덕한 행위는 꼭 ‘을’에게만 고통을 주는건 아니다. ‘갑’ 자신도 즐거워야 할 주말에 일을 강요해야 하는 사실이 미안하고 부담스러울 수 밖에 없다.

3. 갑과 을  – 깔끔한 파트너

위 사례에서 몇가지만 수정하면 깔끔한 ‘갑’과 ‘을’의 관계를 만들 수 있다. 즉, ‘갑’이 월요일 정확한 스펙(해쉬테이블)을 넘겼다거나, 금요일 스펙을 변경하면서 일주일의 기한을 더 주었다면 ‘을’은 마음편히 주말을 보냈을 것이고, ‘갑’도 ‘을’ 보기에 미안하지 않았을 것이다. SW 계약시에 ‘갑’은 정확하게 스펙을 던져주고, 프로그래밍 실력이 출중한 ‘을’은 스펙의 기능을 버그 없이, 기한안에 완성해 낸다면, 이게 진짜 소프트웨어 유토피아 아니겠는가? 그런데 문제는,

두 사례 모두 소프트웨어 망국으로 향하는 길이라는 사실이다!

4. 버그와 혁신

위의 얼리아답터 사례에 비춰봤을때 나는 ‘갑’이었고, DR을 판 회사는 ‘을’이었다. 나는 당연히 ‘갑’의 마인드로 스펙과 기한을 못 맞춘 ‘을’에게 분노하고 심지어 고소를 운운했다. 그런데, 커뮤니티의 다른 ‘갑’들은 태도가 달랐다. 끈기있게 업데이트를 기다려주거나, 스스로 버그를 고쳐나가기 시작한 것이다. 그 당시 이해되지 않았던 그 현상의 의미를, 지금 오픈소스 회사에서 일하며 SW를 판매하는 미국판 ‘을’이 되고 나서야 깨달았다. 우리 소프트웨어(eucalyptus)는 약 60만 라인의 복잡도 만큼이나 버그가 많다. 며칠간은 잘 작동하다가도, 갑자기 어이없는 버그가 출현해 우리를 당황시키곤 한다. 그때마다 한국적 ‘을’의 마인드를 가지고 있는 나는 마치 내가 큰 실수 한듯 미안해하며 급히 고치겠다고 사과한다. 하지만 내게 더 당황스러운 것은, 별일 아니라고 하며 쉽게 넘어가주는, 심지어 스스로 우리 소스코드를 고쳐 다시 우리에게 제공해주는 해커 ‘갑’ 들의 모습, 그리고 그들의 회사들이다. 우리에게 돈을 지불한 그들이 우리 제품을 고쳐서 사용하고 결과물을 다시 우리에게 돌려주는 것이다!

이것이 바로 실리콘밸리에서 일어나는 버그를 통한 혁신이라고 생각한다. 오픈소스 프로젝트의 바이블인 Cathedral and the bazaar [1]에서 설명하듯이 새로운 SW프로젝트의 시작은 기존의 유사한 SW가 가지고 있는 버그나 결함에서 출발한다. SW를 사용하면서 불편함을 느낄때 혹은 새 요구조건을 기존 SW가 충족시키지 못할때 자연스럽게 창조의 욕구가 생겨나고 이는 곧 혁신적인 다음 세대 SW의 출현으로 이어진다. 그래서 오늘 ‘갑'(사용자)의 자리에서 불편함을 느끼며 SW를 사용하는 사람이 내일 ‘을'(개발자)의 모습으로 변해 새롭게 SW를 써내려가는 것이다. 그리고 종종 이 불편함에서 출발한 아이디어가 전 세계를 강타하는 초대형 SW로 탄생하는 것이다. Minix 라는 기존 O/S를 즐겨 사용하던 리누스 토발즈는 모뎀 기능이 없다는 사소한 불편함때문에  새로 리눅스를 만들었다. SW업계의 “쾌남” 래리 엘리슨도 메인 프레임 DB 프로그래밍하며 느낀 불규칙한 인터페이스의 불편함에 착안해 오라클을  시작했다.

불편함을 감수하는 얼리 아답터는 개인에게만 해당되는 것이 아니다. 스타트업에게 바이블중 하나인 Crossing the chasm [2] 을 읽다보면 실리콘밸리 기업들이 얼마나 조직적으로 이 불편함을 감수하는지 알수 있다. 기업들은 새로운 기술을 선보인 작은 회사들 SW를 전략적으로 구입하고, 그 기업이 성장하기까지의 과정을 유심히 지켜본다. 그들은 SW를 사가면서 완벽함을 기대하지 않는다. 새롭게 시작하는 회사의 비전을 믿어주고, 비전이 성공했을경우 자신들에게 돌아오는 혁신에 투자하는 것이다. 우리 회사는 직원 60명의 작은 규모지만, 고객중에 대기업들이 많다. 그리고 그 기업들의 엔지니어들은 꾸준히 자신이 고친 우리 소스코드를 우리에게 피드백한다. 대기업은 스타트업의 제품을 사서 스타트업의 생명을 이어가게 하고, 버그를 통해 스타트업의 혁신을 수혈받는 것이다.

5. 결론

우리에게 문제는 “버그(과정) = 고통” 이라는 등식이다. 깔끔한 솔루션을 원하는 ‘갑’에게 있어 버그는 ‘을’의 계약 위반이고, ‘을’이 어떻게든 해결해야 하는 그들의 “고통”이다. ‘을’에게 있어 버그는 SW 배달전 모조리 잡아야 할(아님 감춰야 할) 치욕이다. ‘갑’이 버그를 발견했을때 받을 더 큰 서러움(혹은 더러움)을 피하기 위해서는 기한전에 고통을 감수하는게 낫다. 버그없는 SW는 존재하지 않기 때문에 하나 하나 잡아내는 버그는 SW의 진화 과정 그 자체다. ‘갑’에게도 ‘을’에게도 이 과정은 피하고 싶은 고통일 뿐이다. 우리에겐 깔끔한 솔루션이 가장 달콤하다. 그리고 그 달콤함에 탐닉하는 동안 SW산업은 서서히 경쟁력을 잃어가는 것이다.

그래서 SW의 참 경쟁력은 버그를 해결해가는 과정과 거기에 참여한 개인, 기업들의 시너지에 있다. 그리고 실리콘밸리의 해커와 기업들은 그 과정을 기꺼이 즐긴다. 각자 짠 코드의 버그를 발견할때마다 한번씩 그 뉘앙스에 웃어주고, 누가 먼저할 것 없이 고쳐나가는 사람들.  하지만 뼛속까지 한국인인 나를 돌아볼때 너무나 자주, 결과의 깔끔함에 집착하고 과정을 즐기지 못하는, 달리 표현하면 높은 “생산성”에만 몰두하는 자신을 발견한다. 나와 내 동료들이 일의 과정을 대하는 다른 자세, 그 이유는 무엇일까 많이 궁금하다. 어쩌면 새마을 시절부터 “지금 삽질은 힘들지만, 훗날 떵떵거리고 살수있다” 는 토목 정신이 흘러서 그런가? 그런데, 지금 많이 넉넉해진 우리는 왜 여전히 불안하고 고통스러워 하는건지…  초중고교 시절을 이어온 주입식 교육 -배움은 고통이고, 극복하면 밝은 미래 – 이 여전히 뇌신경 줄기마다 박혀있어서 그런건지도 모르겠다. 오랫동안 유토피아를 갈망해온 우리에게 진짜 유토피아는 우리가 지나오던 그 길 이었는지도 모른다. 소프트웨어의 축복이 버그에 있듯이.

“It is better to travel hopefully than to arrive. – R L Stevenson”

— 박상민 http://twitter.com/#!/sm_park

[1] The Cathedral and Bazaar by Eric S. Raymond
[2] Crossing the chasm by Geoffrey A. Moore

꽤 오래 블로그를 안해서 그런지 손가락이 찌뿌드드하다. 오늘은 무슨 이야기를 해볼까 생각하다가, 문득 그동안 관찰한 인류의 한가지 패턴중 하나인 너드(Nerd)를 떠올렸다. 한국에도 너드 인종이 분명 존재하지만, 여기 미국의 너드 인종은 사회가 자유로워서 그런지 마음껏 DNA에 새겨진 너드 향기를 풍기며 산다. 그리고 신기하게도 그들과 함께 지내면서 그들의 너드향에 취해 나 또한 너드가 되어 가는것을 발견한다. 완전히 너드인으로 감염되기 전에 어서 나의 발견을 세상에 알려야겠다는 사명감이 들어 키보드를 두들긴다.

우선 유식하게 보이기 위해, 너드 (Nerd)의 사전적 정의를 한번 먼저 살펴보자 (http://dictionary.reference.com/browse/nerd).

1. 멍청하고, 쓸모없고, 매력없는 사람
2. 똑똑하지만 비 사회적인 취미나 이상에 깊이 빠져있는 사람

멍청한 사람도 너드고 똑똑한 사람도 너드라니 재밌다. 미묘하게 두 반의어 사이를 오가는 인종을 너드인이라고 해야 할까? 참고로 유사어로는 Geek 정도가 있고, 한국에서 서식하는 너드는 흔히 오탁후, 잉여인등의 명칭으로 불린다. 그럼 본격적으로 너드의 코드를 분석해 보자.

1. 너드의 드레스 코드 (Nerd’s dress code)

너드라면 패션센스 없는게 상식이다. 나는 한국에 갈때마다 한가지 스트레스를 받는데, 나름 집에서 제일 깨끗한 옷으로 잘 차려입고가 비행기에서 내리면, 부모님, 특히 엄마가 너무 속상해하신다. 미국에서 거지온줄 알았다고…하루, 이틀 여행가방에 넣어온 옷들 — 주로 검은 티셔츠와 갭 반바지 — 을 입고 돌아다니면, 결국 이웃들 보기 부끄러우신지 내 손을 이끌고 메이커 옷가게로 향하신다. 몸에 착 달라붙는 그 옷들을 한국에서만 간신히 입어 드리다가 미국에서는 옷장에 쳐박고 다시 나만의 드레스코드로 돌아간다. 그럼 너드의 드레스 코드, 그 기준은 무엇인가? 개콘의 애정남 프로가 유행인데 최효종처럼 그럼 나도 이 자리에서 애매한 그 기준을 정확히 정해드리겠다.

• C급 너드: 면바지 + 카라 있는 옷 (폴로 티셔츠나 남방)
• B급 너드: 청바지 + 카라 없는 티셔츠
• A급 너드: 청바지/반바지 + 공짜 티셔츠 (주로 컨퍼런스에서 주는 홍보 티) + 샌달
• 일진 너드: 반바지 + 공짜 티셔츠 + 샌달 + 양말 (흰색이 갑)

여기에 예외는 없다. 내가 수년간 관찰한 결과이기도 하고 리누스 토발즈가 그의 책 (Just for fun)에서 밝히기도 한 그의 드레스 코드다.

        리누스 토발즈와 흰양말                                     귀여운 검은 티셔츠 고슬링 옹

오른쪽 사진은 두달전쯤 우리 회사에 놀러온 제임스 고슬링 옹이시다(고 밑에는 본인). 나의 기대를 저버리지 않고 그분은 반바지, 공짜 티셔츠, 샌달에 양말을 정확히 착용하고 계셨다. 우리 회사에선 마케팅 차원에서 회사의 로고가 새겨진 가장 싼(!) 티셔츠를 선물했고, 티셔츠의 로고를 약 10초간 흐뭇하게 바라보며 좋다고 하던 그의 모습을 잊을 수 없다.

우리 회사의 개발팀 막내는 작년 막 대학을 졸업한 ‘개럿’이라는 녀석이다. 이 친구가 저 멀리 미네소타주에서 인터뷰 하러 온날, 나와 동료들은 그의 모습을 보자마자 결론을 내렸다: “대박이다. 뽑자!”. 두뺨을 살포시 덮는 꼬불꼬불한 금발, 여드름끼가 가시지 않은 희고 큰 얼굴에 두툼한 안경을 낀 그 녀석의 호기심 가득한 얼굴은 동화속에서 막 뛰어 나온것 같은 너드나라 어린왕자였다. 깔끔해 보이려고 입은 흰 남방을 힘겨워 하는 그를 보며 , 면접을 위해 엄마가 정성껏 골라준 옷이었다는 사실을 모두 직감했다. 그의 패션센스는 반바지에 매달고 다니는 알루미늄 물통에서 절정을 이룬다. 회사에 들어온후 우리의 예상대로 그는 실력에서도 일진이었다. 개발팀에서 가장 어리고, 팀 절반은 박사들이지만 그의 패키징 지식은 팀의 그 누구도 따라갈 수가 없다. 개럿은 Fedora 커뮤니티에서 존경받는 개발자중 하나다.

2. 너드의 생활 코드 (Nerd’s social code)

너드들과 어울려 생활하다 보면 묘하게 발견되는 대화와 인간관계, 그리고 취미의 공통점이 있다. 오늘은 특이한 두가지만 소개해 본다.

– 마음 여린 독설가
경험상 성격이 유순하고 두루 두루 사람들과 잘지내는 사람가운데 뛰어난 프로그래머는 드물다. 뛰어나고 감각적인 코더들은 종종 성격이 지랄 맞거나, 아니면 대화의 기술이 부족해서 표현이 아주 직설적이다. 이를테면 우리 회사의 개발회의는 종종 이런식의 대화가 오간다.

CTO ‘리치’ (약 50세, 사진속 고슬링과 대화) – “얘들아 우리 경쟁회사 애들이 A라는 기능을 새로 추가했단다. 우리도 그 기능을 만들어볼까?”

나 (순한 32세) – “오 좋은 아이디어. 나도 그런거 생각했어요 (일종의 아첨…).”

개발자 ‘닐’ (31세) – “오 쒯, 왓 더 뻥! 코딩도 제대로 못하는 잡놈들이 만든걸 따라하라고?”

회의중에 “쒯” “왓 더 뻥” 이런 상스런 표현은 아주 흔하게 접한다 (뻥유 까지는 안한다). 회사에 ‘닐’ 이라는 이름의 31살 친구가 있는데 이 친구는 욕쟁이다. 까무잡잡한 얼굴에 까만 구레나룻이 나서 좀 무섭게 생겼고, 운동을 열심히 해서 몸도 근육질인데 이 친구는 회의할때면 종종 흥분해서 욕을 내뱉는다. 개발팀엔 50대 아저씨들도 있고 CTO는 예전 지도교수인데도 욕은 때와 장소를 가리지 않는다. 사실 표현이 거칠어서 그렇지 대부분 맞는 이야기를 한다. 약간은 어색한 가운데 회의가 끝나면 ‘닐’은 이런 사진을 모두에게 보내곤 한다.

그렇다. 그는 험상궂은 얼굴에 욕을 달고 살아도 마음만은 고양이 사진을 좋아하는 여린 청년인 것이다!

대부분 너드들은 마음이 여리고 착하다. 뛰어난 화술과 감정을 숨길줄 아는 사회 생활 스킬은 부족해도, 그래서 종종 친구들이 없고 외로워 보여도, 내가 만난 진짜 너드들은 모두 착한 사람들이었다. 소프트웨어 회사의 진정한 힘은 MBA 출신에 서글서글 사교성 좋은 사람들보다, 이렇게 거칠지만 마음 여린 개발팀 너드들이다.

– 잉여 폭발
지금까지 여러번 강조했지만, 폭발하는 잉여력은 너드들의 특징중 하나다. 회사에서 누가 지시하지도 않았는데 너드들은 종종 밤을 세우고 심혈을 기울여 대단한 작품을 만들어 내곤 한다. 그리고 그 작품에 다들 감탄하지만, 누구나 곧 이 의문을 갖게 된다. “근데 왜 했지?” — 예를 들어 ‘앤드류’라고 주말에도 회사에서 사는 젊은 너드가 최근 액셀 파일을 하나 만들었는데, 실시간으로 회사의 서버 정보들을 취합하는 매크로를 사용해 대단한 그래프를 선보였다. 내가 보기에 너무 멋졌다. 근데 왜 한건지는 잘 모르겠다. 이미 그 기능을 하는 웹페이지가 있었는데…

종종 이런 잉여력은 취미 생활로 나타난다. 우리 회사엔 자전거에 미친 사람이 많은데, 매일 나가서 20 km 정도를 달리고 온다. 보기 좀 민망하게 어떤 부위에 착 달라붙는 자전거복을 입고 복도를 왔다갔다 하는 사람들 보면 “난 누군가, 여긴 어딘가” 생각이 절로 난다. 회사의 한국인 교포 친구는 써핑을 좋아해서 매일 아침 써핑하고 1시에 출근한다. 밤늦게까지 일하며 자기 몫은 잘 해낸다. 코딩을 하다보면 종종 기타소리가 들리는데, 자기 방에서 갑자기 미친듯 기타를 치는 대니얼과 그의 전 지도교수 리치다. 한때 골프에 미친 나는 1년동안 매일 아침 라운딩을 돌고 출근했다.

3. 너드의 인생 코드 (Nerd’s life code)

너드의 인생은 호기심으로 충만하다. 재미있는 장난감에 어린아이처럼 좋아하고, 새로나온기계에 흥분을 멈추지 않는다. 우리 회사 사무실엔 장난감 헬리콥터가 날아다니고 모형 기차가 비좁은 개발실 가운데에서 빙글빙글 돌아간다. 고등학생 아들이 있는 엔지니어 아저씨 ‘데이빗’은 어느날 흥분하며 로봇 프로그래밍을 해보자고 제안한다 (회사의 비지니스와 관련도 없는데). 그의 입사를 환영하는 회식은 비좁은 사무실에서 시켜먹은 인도 카레와, 그가 들고온 X-box 게임이 전부였다.

잉여짓과 같은 작은 비전도, 때로는 세상을 바꾸는 큰 비전도 너드의 세상가운데 피어난다. 너드는 자신이 꿈꾸는 비전을 향해 코딩을 멈추지 않는다. 나이가 들수록 오히려 그 열망은 강해지는듯 하다. 우리 개발팀 최고 노장 아저씨 ‘밋치’는 아마 나이로는 50을 넘겼을거다. 하지만 우리 개발팀중에 그가 제일 유명하고 실력도 최고다. 구글을 포함 수만명이 그가 만든 아마존 웹서비스 클라이언트 라이브러리를 사용한다. 아저씨는 낮에는 회사일로, 밤과 주말에는 사람들이 보내온 패치를 적용하고 코딩하느라 정신이 없다.  우리회사의 창업자이자 CTO인 ‘리치’역시 비슷한 연배의 대학 정교수다. ‘리치’는 개발팀 사람들 중 매일 아침 가장 일찍 출근해 코딩한다. 노트북 스크린을 뚫어버릴듯이 집중하며 키보드를 두들겨대다가, 밝게 웃으며 느즈막이 출근하는 우리들을 맞는다. CTO 역할은 좀 더 높은 자리에서 회사의 비전과 경영을 논해야 하건만, 그는 여전히 버그를 잡으려 GDB를  돌리고 시스템을 테스트할 스크립트 짜기에 여념이 없다. 출장길 공항에서도 그는 SSH로 접속해 시스템을 점검한다.

“너드: 똑똑하지만 비 사회적인 취미나 이상에 깊이 빠져있는 사람” — 그 이상이 세상을 바꾼다.

4. 마무리

의문이 든다. 나는 진짜 너드일까?
패션감각은 제로니까 OK. 지금쓰는 블로그를 포함해 종종 잉여짓을 하니까 그것도 OK.
그런데 내가 프로그래밍하게끔 하는 힘은 정말 호기심과 비전일까?

두 딸과 아내의 생계를 위해 내가 희생한다고 생각했던적이 얼마나 많았는데…
박사학위를 받으면 코딩하지 않아도, 고상한 논문에 남들을 지도하는 것만으로도 존경받을거라 생각한적도 있었는데…
뛰어난 프로그래머가 아니면 도태될까봐, 그 “공포”에 질려 기술책들을 읽어가던 그런 때가 얼마나 많았는데…

그런데 50세가 넘어서도 코딩하는 나의 모습을 나는 정말 바라고 있었던 걸까? ….

아무쪼록, 훗날 내 아이들의 아이들을 무릎에 앉혀놓고 내가 만든 시스템을 보여줄 그런 날을 맞게되길 소망해본다.

– 박상민 http://twitter.com/#!/sm_park

1. 들어가며
바야흐로 소프트웨어 시대가 도래했다.
벤처붐 빵 터질때 쌈짓돈 탈탈 털어서 투자한 국민을 울렸던 그 소프트웨어, 그 얄미운 것이 이제 다시 이 나라의 희망으로 멋지게 컴백한 것이다.
1999년 당시 대학 2학년이던 나는 조그만 벤처 사무실에서 인턴으로 일 했는데, 딱히 기술도 없던 회사가 신문에 광고 한번으로 투자금 10억을 모았다. 곧 200평은 족히 되는 사무실을 임대해 이사했고, 회사 임직원은 뜨거운 마음으로 밤낮없이 일해 그 돈을 다 날렸다. 그 당시 내가 일했던 그 회사 같은 곳이 얼마나 많았는지 생생히 기억난다. 오죽했으면 그때 최고 신랑감 1위가 벤처사업가 였겠는가? 지금은 우스갯소리로 35위쯤 된다고 한다. 34위가 광부라고 하던가 배 있는 어부 (36위-배없는 어부) 라던가? 아무튼 그리 화려했던 그 회사들은 이제 구글로 검색을 해도 찾을 수가 없다.

그런데 이번에 부는 소프트웨어 바람은 양상이 다르다. 국민들의 기대는 삼성과 같은 대기업에 쏠려있다. 즉 “우리 뒤통수 친 구글좀 혼내줘!”, 이런 화려한 복수극을 내심 기대하고 있다. 국민의 마음을 잘 헤아리는 언론들은 이런 기사들을 주구장창 내보내고 있다.

“삼성에 대한 걱정에 송구, OS문제 걱정 안해도 돼… 바다도 있고 리눅스 기반한 스마트폰 운영체제 곧 나와” – 최지성 부회장 [1]

염려하는 우리를 달래기 위한 그분들의 배려는 곧 “삼성전자 소프트웨어 인력 2만명에 달함” [1] 혹은 “소프트웨어 인력 따로 선발” [2] 등의 기사에 구구절절 드러난다. 대한민국 소프트웨어 통일을 노리던 구글은 이제 큰일이다. 중공군이 바글바글 압록강 건너듯  “2만+α” 의  소프트웨어 인재들이 구글을 다시 밀어내버릴 것이기 때문이다. 전국의 컴퓨터학과 학생들에겐 좋은 세상이다. 그들은 이제 삼성의 +α 인재들로 업그레이드 될 것이다. 수만명 인재들이 만들어낼 제 2의 안드로이드, 클라우드, 소셜네트워크를 생각하니 너무 흥분돼 키보드 치는 손가락이 바들바들 떨린다.

2. 실리콘밸리의 영웅들
실리콘밸리의 역사는 영웅의 역사다. 실리콘밸리의 영웅은 자본과 인재로 넘치는 큰 조직에서 나오지 않았다. 한 시대 관점에서는 아웃라이어 (outlier) 인 사람이나 기술이, 패러다임이 변하는 시점에 영웅으로 승화하는 것이다 (즉 구글이 웹 패러다임의 영웅이 되었듯). 지금까지 실리콘밸리 역사를 바꾸었던 소프트웨어 기술과 회사들은 항상 이런 패턴으로 발전했다.

1. 본업 (학교/회사)이 따로 있는 프로그래머 A가 잉여짓으로 프로그램을 만든다 [참조 3]
2.  A는 자신이 만든 프로그램을 큰 조직(회사)에 알린다. 윗분에게 뻘짓 했다는 소리만 듣는다.
3. A는 조직 밖 대중에게 프로그램을 공개한다. 사용자가 급격히 증가한다.
4. 투자자들의 눈에 띄어 투자를 받는다. A는 마음맞는 프로그래머들을 뽑아 제대로 회사를 시작한다.

위의 기본 공식에 몇가지 사례를 한번 대입해 보자.

• 구글 창업자 래리 페이지와 세르게이 브린은 스탠포드에서 박사 논문 준비중 떠오른 검색 알고리즘 Page Rank를 구현하기 시작한다. 본업인 박사 논문은 뒷전이다 (1 만족). 구현된 프로그램을 그 당시 잘 나가던 야후! 의 임원진(창업자 제리양이 스탠포드 선배)에게 보여주고 거래를 제의한다. 야후는 포털인데 검색기능이 너무 훌륭하면 사람들이 금방 포털에서 다른 사이트로 이동한다고 생각해 거래를 거절한다 (2 만족). 래리와 세르게이는 아이디어가 팔리지 않아 결국 자신의 기숙사 컴퓨터로 서비스를 시작한다 (3 만족).  곧 아마존 CEO 제프 베조스등 몇사람으로 부터 100만불 투자를 받고 본격적으로 사업을 시작한다 (4 만족). [참조 4]

• 빌게이츠와 폴앨런 역시 하버드 신입생 시절 Altair PC에 매료되어, 본업이었던 수업에 나가지 않고 BASIC 컴파일러를 만든다 (1 만족). 그의 BASIC 컴파일러는 곧 위에 언급한 Home brew computer club 사람들 사이에 유행하게 된다 (3 만족).  게이츠는 타고난 사업 수완을 발휘해 그 원시적인 BASIC 컴파일러로 돈을 벌고, 곧 IBM과 DOS 계약을 체결해 따로 투자를 받지 않고도 사업을 궤도에 올린다 (4 만족) [참조 5]. 참고로 갓 21살 빌게이츠가 클럽 사람들에게 자기 소프트웨어는 돈 내고 쓰라고 공개 편지를 쓴 사건은 오픈소스와 독점소스의 역사를 나누는 기준이 된다 (http://g-ecx.images-amazon.com/images/G/01/books/orly/GatesLetter.pdf).

나는 위의 기본 템플릿에 실리콘밸리의 영웅들과 혁신적 기술을 대부분 때려 맞출수 있다고 생각한다. 즉, 기존의 조직 (학교/회사)에서 받아들일수 없는 프로그램을 만든 아웃라이어 (outlier) 해커들은 IT의 큰 패러다임 변화 (PC, 웹, 클라우드) 속에서  영웅으로 등극하는 것이다. 그리고 그들이 제국을 10여년 세우고 나면, 또 새로운 영웅들이 위의 템플릿에 맞추어 등장하고, 기존 영웅들을 역사속으로 보내버린다.

3. 왜 꼭 영웅인가?
실리콘밸리의 영웅들은 나이와 상관없이 자신이 창업한 회사를 지배하고 성장시킨다. 주변에서 조언해주는 어른들은 분명 도움이 되지만, 창업자가 가지고 있는 명확한 비전에 따라 회사의 흥망 성사가 결정된다. 쥬커버그가 이제 만 26살 이지만 페이스북 가치는 삼성의 100조원 시가총액에 가깝게 평가받는다. 지구를 한동안 지배한것 같은 구글의 레리와 세르게이는 이제 갓 30대 후반이다. 우리의 기업 조직 — 5,60대 임원들의 지휘하에 40대 부장, 30대 과장, 그리고 20대 일꾼들 — 은 새마을 운동 시절부터 변함이 없지만, 실리콘밸리는 젊은 영웅이 만들어내는 새로운 “컨셉”에 의해 재편된다. 이는 창업자에게만 해당되는 것이 아니다. 역사적인 소프트웨어들은 한, 두 명의 핵심 해커들에 의해 개발되었다. 예를 들어, Unix와 C언어는 켄 톰슨, 데니스 리치 두 사람이 개발했다. Java 언어는 제임스 고슬링 혼자 만들었고 리눅스는 리누스 토발즈가, TCP/IP는 빈트 서프와 로버트 칸 이 만들었다. 물론 후에는 여러 엔지니어가 참여해서 개발을 돕지만, 여전히 기술을 지배하는 건 소프트웨어 영웅들이다. 예를 들어 리누스 토발즈는 지금도 리눅스 커널에 모듈을 추가할지 여부에 대해 100% 독재적으로 결정한다 (그래서 그는 자기를 이렇게 소개하기도 했다: “My name is Linus Torvalds and I am your god [6]”)

나는 이러한 인물 중심적인 발전은 소프트웨어의 특성이 아닐까 생각한다. 브룩스는 그의 베스트셀러 The Mythical Man-month에서 끊임없이 “개념의 일관성 (Conceptual Integrity)” 을 강조했다. 즉 아무리 큰 규모의 소프트웨어 프로젝트를 하더라도 단 한명만 소프트웨어를 디자인 하라는 것이다. 우리는 그 예를 스티브 잡스를 통해서 쉽게 찾을 수 있다. 오로지 그의 감각에 의해 디자인되는 애플 제품들에 얼마나 많은 사람들이 흥분을 하나? (너무 흥분해서 싸우기도 잘한다) 빌게이츠가 MS의 최고 소프트웨어 아키텍트 자리에서 물러나기전 레이 오지라는 천재 SW 디자이너를 그 자리에 앉히려고 아예 그의 회사를 사 버린 것은 유명한 이야기다 [8]. 그마저 떠나고  “MBA 경영인” 스티브 발머가 이끄는 MS는 지금 얼마나 많이 헤매고 있나? 구글의 역사를 다룬 책 “In the plex” [4] 에서는 CEO 에릭 슈미츠 (그 자신도 Lex를 만든 유명한 SW 엔지니어) 뒤에 가려진듯 했던 레리와 세르게이가 핵심 제품들 디자인에 얼마나 깊게 관여하는지 보여준다. 예를 들어 구글의 심플한 디자인과 “I’m feeling lucky” 버튼은 레리의 고집, 곧 “개념의 일관성”에 따른 결과라 할 수 있다. 즉 밑바닥 해커에서 시작한 영웅의 비전이 신개념을 창조하고, 그의 독점적 지배하에 개념의 일관성이 유지된다.

1998년 구글 홈페이지: 지금과 별 차이가 없다

실리콘밸리는 그래서 영웅의 흥망성쇠에 따라 끊임없이 이동한다. 나 같은 범인 프로그래머들은 영웅이 창조해 낸 새로운 시대를 따라갈 뿐이다. 운이든, 안목이든 조금이라도 빨리 영웅의 스타트업에 몸을 담는 사람은 평생 그 혜택을 누릴수 있다. 구글에서 마사지해주던 안마사는 지금 넓은 저택에서 안마 받으며 살고 있다. 아래 그림처럼 새 영웅 쥬커버그의 도래에 실리콘밸리의 재능들은 그의 영지 페이스북으로 몸을 맡기는 것이다. 페이스북이 주식 상장 하는 날에 일찍 주군을 모신 사람들은 포르쉐 매장으로 향하는 거다.

출처: http://www.fastcodesign.com/1664037/infographic-of-the-day-facebook-is-winning-silicon-valleys-talent-war

4. 결론
우리 소프트웨어 영웅은 그럼 누군가? 1938년 창업한 삼성그룹의 오너가 영웅이라면, 그 영웅은 좀 너무 쉬어버린것 아닌가? 거기서 조직을 관리한 임원들을 영웅으로 모시기에는 그분들의 소프트웨어에 대한 철학 부재를 설명할 방법이 없다 (예: 2만+α 양병론). 벤처붐 이후 살아남은 기업들 (NHN, 다음 등), 그곳의 영웅들은 여전히 해커의 통찰력과 개념의 일관성을 갖고 있는지 의문이다. 아마 그랬으면 네이버 검색의 품질이 훨씬 좋았겠지? 나는 실리콘밸리 해커들의 전설이야기에 매일 흥분하는데, 그 이름이 하도 많아 외울 수 조차 없다. 한국의 전설적인 해커는 그 이름을 들은적이 없으니 외울수가 없다.

영웅이 없는데 “2만+α” 의 소프트웨어 인력은 무엇을 해야 하나? 정부와 기업의 잘 관리된 조직과 플랜에 따라 척척척 “한국형 안드로이드”, “한국형 클라우드”, “한국형 소셜네트워크”를 만들어 내겠지? 해커가 밑바닥부터 일구어낸 개념의 일관성 (Conceptual Integrity)보다는 임원단부터 아래로 내려오는 명령체계가 소프트웨어 강국을 만들어 낸다면 나는 그 날로 우리 아버지 시골집에 내려가 소나 키우련다.

끝으로 나는 10여년전의 벤처 바람이, 그런 광풍까지는 아니어도 다시 훈풍으로 불길 바란다. 그때 크게 데이신 분들이 눈살을 찌푸릴지 몰라도, 한번 더 우리의 잉여력을 믿어주고 부동산으로 돌아갈 돈이 소프트웨어 영웅들의 손에 쥐어졌으면 한다. 우리가운데 영웅은 분명히 그 시간을 기다리고 있다.

– 박상민 http://twitter.com/#!/sm_park

[1] http://news.chosun.com/site/data/html_dir/2011/09/03/2011090300287.html
[2] http://media.daum.net/cplist/view.html?cateid=1006&cpid=129&newsid=20110901110341745&p=seouleconomy
[3] https://sangminpark.wordpress.com/2011/08/23/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%9E%89%EC%97%AC%EC%99%80-%EA%B3%B5%ED%8F%AC/
[4]  In The Plex: How Google Thinks, Works, and Shapes Our Lives, by Steven Levy
[5] 해커 그 광기와 비밀의 기록: http://www.yes24.com/24/goods/2256?scode=032&srank=16
[6] Just for Fun: The Story of an Accidental Revolutionary, by Linus Torvalds and David Diamond
[7] The Mythical Man-Month, by Fred Brooks
[8] http://news.cnet.com/Microsoft-to-buy-Groove-Networks/2100-1014_3-5608063.html