[번역] 해커와 화가 – 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

우리의 강함은.

흔히 해커들은 어려서부터 프로그래밍에 빠졌다고 고백하는 경우가 많다. 솔직히 나는 아니다. 인문학부로 막 대학에 들어간 첫해는 국사, 국문, 영문과마다 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의 해결이 있지 않을까 생각한다. 우리 한국인 고유의 감정의 힘과 잉여스러움의 조화…언젠가 멋지게 어우러지는 날이 오지 않을까?

https://twitter.com/sm_park

오픈소스의 승리

창조란다.

창조경제가 화제다. 큰 누님께서 “앞으로 5년은 창조여..” 하신후 언론, 정치인, 석학들이 제각각 “이게 창조 맞나여?” 떠들어대니, 드디어 그분께서 몇마디 하셨다. (http://news.mt.co.kr/mtview.php?no=2013041815465078255). “창조”라고 말은 꺼냈는데, 막상 그 담에 할말이 없어서 많이 고민하셨을 그뿐께서 싸이의 젠틀맨이야말로 모범 창조라며 숟가락 슬쩍 얹어보는 모습이 참 보기 좋다. 빌 게이츠, 스티브잡스와 같은 창조적 인재를 “양성” 해야 한다는, “인재 양성론” 역시 일관되서 보기 좋다. 과거엔 경제개발 5개년 계획이었다면 지금은 잡스 키우기 5개년 계획을 세우려나 보다.

그분께서 소프트웨어에 각별한 관심을 가지신 것은 나와 같은 일개 코더로서 참 황송한 일이다. 새 정부의 보호아래 높아진 코더의 존엄을 누리며 살게 될지도 모른다. 하지만 기사의 이 부분을 읽으며 마음속 깊은 곳에서 시작되는 빡침을 억누를 수 없다.

박 대통령은 “도전에 대한 두려움이 없어야 하고, 그것에 대해서 정당하게 가치를 인정해줘야 하는데, 그러기 위해서는 당연히 지적재산권이 잘 보호되어야 하고 국내기업들한테도 당연히 로열티를 지불해야한다”며 “소중한 가치를 보호하고 인정해 줘야 하는 것이 중요하다”고 강조했다.

오픈소스, 공짜? 해킹?

지적재산권, 로열티, 라이센스.. 아무래도 그분이 이쪽으로 관심을 가지신 듯 하다. 마음대로 복제 못하는 법을 만들어 코더의 밥 그릇을 보호해 주시려는 어머니의 마음을 느낀다. 물론 나 역시 SW의 불법 복제로 얼마나 많은 코더들이 고통받았는지 알고 있다. 하지만 쌓인 버그리포트에 허덕이는 내가 굳이 이렇게 글질하는 이유는 법과 제도가 아니라, 오픈소스가 한국 SW의 근본적 해결이라고 믿기 때문이다.

그분께서 “거 오픈소스가 뭐요?” 라고 물으면 아마도 주변에서 이리 대답할 것이다: “소프트웨어 공짜로 쓰자는 운동입니다. 소스를 공개해서 로열티도 없다네요. 리차드 스톨만이라고 극좌파 MIT 해커가 시작했는데, 지금은 리눅스라고 서버실에서 종종 쓴다고 합니다요…”. 일단, 뭐 “공짜”, “해커”, “좌파” 요 부분에서 불꽃 싸다구가 한대 날아오지 않을까?

슬프지만 이게 한국의 오픈소스 인식 수준이라고 생각한다. 얼마전 한국에서 거의 유일하게 오픈소스를 만들고, 작디 작은 개발자 커뮤니티를 유지하던 KTH가 정리해고를 했다. 제법 실리콘밸리의 스타트업과 같은 문화를 만들었고, 오픈소스 바닥에서 실력이 쟁쟁하던 사람을 많이 보유했던 회사다. 그런데 사장부터 날고 기던 개발자까지 모두  날려버리고는 이제 SI를 한단다. 작년에 나는 뉴욕의 잘나가는 스타트업 thefancy.com에서 아키텍트로 잠시 일했다. 내가 만나본 사람중 가장 천재같았던 미국인 창업자는 신기하게도 한국인들로 개발팀을 꾸몄다. 그가 꾸린 한국인 팀과 일해보니 이유를 알만했다. 정말 뛰어난 팀이었다. 그런데 그가 유별나게 공들이며 한국 개발자를 스카우트 하던 회사가 있다. 그게 KTH였다. 정말로 삼성같은 곳 출신은 쳐다보지도 않았고, 오로지 KTH 사람만 은밀히 접근해 뽑아왔다. 왜냐하면 거기에 보물들이 있었으니까…그런데 우리의 공적 기업인 KT는 오픈소스쟁이들 돈 못번다고 매몰차게 쫓아냈다.

제국과 문화

역사적으로 현재의 성공적인 실리콘밸리가 있기까지 두개의 가장 큰 SW 물줄기가 있다. 오픈소스 “해커” 파와 비공개소스 “머니”파 이렇게 나눌 수 있다. 그 시작은 해커파였고 큰 형님은 아래의 리차드 스톨먼이라 하겠다

이미지

사진 1: 리차드 스톨먼 – 해커파 원조. 극진 좌파.

1970년대 MIT에서 서식하던 학부 새내기 몇몇은 연구용 메인프레임을, 운영체제나 게임등을 만들어보려 밤마다 해킹했고 그중 스톨먼님이 강력한 해킹실력을 선보였다. 그분은 강한 심성을 지니셔서 MIT에서  패스워드를 사용하는 보안 시스템을 도입하자 곧바로 해킹해 모든 유저에게 패스워드를 사용하지 말라는 경고를 보내기도 하셨다. 사실 그들의 해킹은 파괴가 아니라 재미와 자유의 추구였다. 누구에게도 피해를 주지 않았고 초기 SW의 발전에 핵심이었다. 이후 스톨먼은 오픈소스계의 완전 좌파 GNU를 조직하고 (우파는 Apache 재단), GPL이라 불리는 오픈소스 라이센스를 만들어 이후의 오픈소스 운동에 이론적, 법적 토대를 확립했다.

70년대 미 동부파를 스톨만님이 장악했다면 서부파에는 스티브 워즈니악이라는 얼굴로는 절대 밀리지 않는 분이 있었다. 스티브 잡스와 워즈니악은 Homebrew Computer Club 이라는 직역하자면 “가내수공 컴퓨터 동호회”에서 처음만났다. 잡스가 비지니스로서 컴퓨터의 가능성을 보았다면 워즈니악은 컴퓨터 설계도와 소스를 공짜로 나누어주는 자비로운 해커였다. 워즈니악에겐 만드는 것뿐 아니라 그것을 공유하며 디자인에대해 신나게 떠드는 그 과정이 재미였다. 그래서 해커의 핵심은 파괴가 아니라 공유와 재미다.

이미지

사진 2: 얼굴로 디버깅 하시는 워즈니악님

동네 동호회나 학교 연구실에서 신나게 해킹하던 세력에게 도전장을 던진이가 바로 빌게이츠다. 그가 짠 베이직 컴파일러 소스코드를 당연하게 자기들끼리 나누던 해커 세력에게, 하버드 범생 빌게이츠는 1976년 이런 도발적인 편지를 보낸다 (http://g-ecx.images-amazon.com/images/G/01/books/orly/GatesLetter.pdf). 그 중 한 부분을 번역하자면:

“너희들(해커) 왜 이러니? 너희 취미로 하는 녀석들 왜 소프트웨어를 훔치고 그러니? 너희들 하드웨어는 돈주고 사잖니? 근데 왜 소프트웨어는 공유하고 지랄이야?…좋은 말할때 아래 주소로 돈 보내세요.”

어쩌면 아버지가 부자 변호사였던 빌게이츠에게는 “지적재산권”이 당연한 권리였는지 모른다.

여기로부터 오픈소스 “해커”파와 비공개소스 “머니”파가 갈린다. 머니파에는 그후 오라클의 래리 엘리슨등 거친놈들이 세력을 형성했고, 돈에 눈 뒤집히는 저널리즘은 동호회에서 소스코드나 나누어보는 너드들 커뮤니티보다는 빌게이츠와 래리 엘리슨의 불어나는 재산에 더 관심이 많았다. 폭발적으로 늘어나는 PC, 기업용 컴퓨터 시장이 가져다주는 돈이 “머니”파의 세력을 불렸다. 머니파는 결과적으로 돈의 제국을 만들었다.

그럼 오픈소스 해커파는 죽었는가? 절대로 아니다. 그들은 머니파에 대항해 돈 대신 넘쳐나는 잉여력과 시간으로 그들에 대항했다. 80년대 핀란드의 한 대학생 리누스 토발즈가 재미로 시작했던 리눅스가 윈도우즈에 대항했고, 역시 핀란드의 천재적 해커 몬티가 시작했던 MySQL은 오라클 데이터베이스에 대항했다. 한 두 사람 천재적 해커의 지휘아래 전세계의 개미때같은 해커들이 일어섰다. 누가 돈 주는 일 아닌데도 재미있으니까, 그리고 해커에게 본능적으로 내재된 자유정신이 계속해서 해커파를 살아있게 했다. 오픈소스파는 결과적으로 SW문화를 일구었다.

승리자

자, 그럼 이쯤에서 과거를 정산해보자. 두 세력의 싸움에서 누가 승리했는가? 나는 오픈소스편이지만 과거만 돌아봤을때 머니파의 손을 들어주겠다. 솔직히 리눅스 데스크탑이 윈도우즈와 게임이 되는가? MySQL은 1조원에 팔린 반면 오라클은 여전히 150조원짜리의 회사다. 하지만 우리는 “과거회상부”가 아닌 “미래창조부”라는 부서를 만들었으니 현재와 미래를 생각해 봐야한다. “머니” 제국과 “오픈소스” 문화의 싸움에서 현재 누가 이기고 있는가? 단언컨데 문화가 이기고 있다. 오픈소스 문화를 적극 활용한 곳이 구글, 페이스북등 2000년 이후의 인터넷 기업이다. 구글은 안드로이드를 리눅스 기반 오픈소스로 만들었고, 하둡과 같은 빅데이터 오픈소스 프로젝트에 아이디어를 제공했다. 최근 구글은 오픈소스 회사가 설령 자신의 아이디어를 복제하더라도 고소하지 않겠다는 맹세까지 했다. 구글은 오픈소스 진영의 날고 기는 해커들, 예를 들어 자바의 제임스 고슬링, 파이썬의 Guido van Rossum등을 영입해 오픈소스 문화 중심에 있고 싶어 한다. 구글의 회사가치가 마이크로소프트를 넘어선것은 우연이 아니다. 문화가 이기는 것이다.

스타트업과 오픈소스

하지만 오픈소스 해커 문화가 진짜 꽃피우는 곳은 실리콘밸리의 스타트업이다.  예를들어 github 이라는 오픈 소스 프로젝트의 말그대로 “허브”가 되는 곳이 있다. 2012년 techcrunch의 베스트 오브 베스트 스타트업으로 뽑힌 곳이다. 오픈소스계의 영원한 아이돌 리누스 토발즈는 리눅스 커널을 관리하는 기존 툴이 엉망인 것에 너무 빡친 바람에 git이라는  소스관리 툴을 만든다. 그게 리누스에게 얼마나 깊은 빡침이었는지, 단 2주만에 완성하는 기염을 토했다 (그러고는 후에 “git 만드는게 제일 쉬웠어요” 라는 인터뷰로 나와같은 빠돌이를 지리게했다). github의 두 창업자들은 동네 프로그래밍 동호회(이것봐. 또 동호회다…)에서 만나 git을 인터넷 기반으로 확장하는 아이디어에 착안했다. 각자 직업이 있는지라 주말마다 브런치 먹으면서 코딩을 하고 서비스를 런치했다.

2011년 기준 매일 4500(!)개의 오픈소스 프로젝이 github에서 생성된다. 현재 1조원 가치의 회사로 실리콘밸리의 “달링”으로 사랑받는다. 리누스가 단 2주만에 만든 툴이 1조원짜리 회사, 사실은 그것보다 더 가치있는 인터넷 스케일의 소스코드 저장소를 만들었다. 리누스가 github으로 돈을 벌었다고 들어본적이 없다. 어차피 재미와 빡침의 해소를 위해 코딩하는 사람이니까. 세상 어느곳에서 2주 재미로 코딩하고 1조원짜리 회사가 만들어질 수 있을까? 그게 오픈소스 문화의 힘이다.

마무리

현재도 마이크로소프트나 오라클은 종종 꽤 쿨한 제품을 낸다. 예를들어 클라우드에서 Windows Azure같은 것들이다. 그런데 현지의 분위기는 “뒷방 저 노인네 아직도 뭐 깎고있네…”  이 수준이다. 그들을 추앙했던 저널리즘마저 이제는 제국에 등을 돌려버렸다. 현재는 오픈소스를 가장 강하게 등에 업은 구글, 페이스북, 아마존등이 IT를 이끌고 있다. 그들 역시 문화를 잘 활용한 것일뿐 문화 자체는 아니다. 다음 영웅이 출현하면 언젠가 그  신진 제국들 역시 무너질 것이다. 하지만 문화는 절대로 죽지 않고 도도하게 흐른다.

다시 처음으로 돌아가, 우리는 미래에 대해 이야기하며 소프트웨어가 그 중심에 있다고 말한다. 하지만 청기와집이나 언론 모두 죽어가는 제국을 우러러보며 모델로 삼으려할 뿐이다. 스타트업이 많이 생겨야 한다고 대빵께서 이야기한다. 나는 오픈소스 아닌 MS의 플랫폼에서 만드는 스타트업을 도무지 상상할 수가 없다. 그들의 기억은 슬프게도 여전히 MS나 오라클이 한국에 뿌리내린 제국 그 안에 갇혀있다. 액티브엑스로 보안을 통제해야 하고, ‘을’이 짜낸 윈도우즈 프로그램이 ‘갑’에게 제값 받게 해주는 법 제정, 그것이 그들의 틀이다. 실리콘밸리의 가장 핵심에 있는 오픈소스 해커문화를 이해하는 것은 어렵다 치더라도, github처럼 한두명 젊은이가 오픈소스로 몇조원짜리 회사를 일구었다는 성공신화라도 좀 누가 전했으면 싶다. 제국은 죽지만 문화는 산다.

언젠가 우리 큰분께서 해카톤(Hackathon) 이벤트에 납시어서 해킹에 열중하는 우리의 희망들에게 인자한 미소 한방 날려주는 날이 왔으면 하고 바래본다.

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

버그의 축복

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

비전-눈으로 보는 행위

얼마전 둘째 아이를 낳고 (내가 아니고 부인님이) 그 녀석 돌보는게 너무 피곤한 나머지 초저녁 새우잠을 잔적이 있다. 꿈을 꾸었다. 이유는 알수 없었는데 10여년전 대학생 시절 매일처럼 지나다니던 수원역 거리가 마치 영화 필름 돌려보듯이 너무 생생하게 나타났다. 학교버스에서 내려 신호등 지나면 보이는 수원역전과 그 주변을 가득 매운 노점상, 그리고 총총걸음으로 집으로 돌아가는 사람들. 한참동안 잊고 있었던 그 풍경을 그대로 돌려보니 꼭 예전 발라드 듣고 난 기분 이었다. 그런데 그중에 제일 생생하고 한편으로 왠지 돌아갈수 없을것 같은 아련함까지 느낀건 다름아닌 길거리 노점상들의 오뎅 냄새를 꿈속에서 맡았기 때문이다. 웃기지만, 정말 그 냄새들이 꿈속에서 살아나니 13년전 그때의 분위기 모두 다시 돌아온 기분이었다. 꼭 그 꿈 뿐만이 아니다. 종종 낯선 장소에서 우연히 맡은 어떤 향기 때문에 나는 한참을 잊었던 과거의 기억을 떠올릴때가 많았다. 아마도 후각은 무의식속 과거를 의식으로 끌어올리는 감각 기관인가 보다.

후각이 과거라면, 시각은 미래를 만드는 감각기관이라 생각한다. 비전(vision)의 사전적 해석을 보면:

  1. 눈으로 보는 행위
  2. 앞으로 일어날 것을 기대하는 것

약 9년전쯤에 나는 한국에서 컴퓨터과 대학원을 다녔다 (아주대학교). 학부시절 벤처한다고 밤을 세우고 살았던 것 그리고 인문학과에서 컴퓨터과로 전과를 한 배경때문에 학부 학점이 심히 안 좋았다. 수학등 모든 기초과학 과목에서 B를 맞아본 적이 없을 정도니까. 성공한 사람들은 흔히 학부때 다른 잉여짓에 몰두한 나머지 학점을 소홀히 했다고 이야기 하지만, 나는 나름 열심히 공부해도 안됐으니 안 똑똑해서 그런거라고 고백할수 밖에 없다. 그래서 졸업후 나를 받아주는건 자대 대학원 밖에 없었다.

그러다가 우연히 정부의 눈먼돈 (BK21) 지원을 받아 해외 학회를 가게됐다. 영국에서 열리는 오픈 그리드(GRID) 포럼이라는 곳인데 나 포함해서 네명 정도 같은 연구실에서 동행했다. 너무 예쁜 관광지 에딘버러에서 열리는  학회여서 나와 동기들 모두 신났던걸로 기억난다. 첫날 등록하러 학회 장소로 향하는데, 그 당시 그리드는 지금의 클라우드와 같은 유망한 기술로 소문나 이미 건물주변이 사람들로 북적북적 했다. 우리가 관광하느라 늦게 도착해서 안에서는 이미 IBM같은 거대 기업의 중역들이 키노트를 하고 있었다. 성큼성큼 넓은 홀을 지나가는데,  청바지와 컨퍼런스 티셔츠로 후줄근하게 입고 바닥에 앉아있는 사람들이 눈에 띄었다. 뭘하나 살펴보니 그 사람들은 무선랜으로 터미널을 접속해 프로그래밍 하고 있었다. 2002년 그 당시 우리나라엔 무선랜이 막 보급되는 시점이었는데, 선이 없다는게 그렇게 자유로운건지 그때 알았다. 그 사람들은 안에서 하는 높은분들의 키노트는 별 관심이 없어 보였고 오로지 검은 스크린에 떠오르는 하얀 글씨들만 집중하고 있었다.

그리고 그날 거기서 난 나를 봤다. 그때 눈으로 목격한, 자유분방한 차림에 오로지 코딩에만 집중하는 그 모습이 왜 그리 멋있어 보였는지 모른다. 나와 함께 간 동기들은 별다른 감흥이 없어 보였는데, 나는 그 모습이 혹 나의 모습이 된다면 하는 상상에 몹시 설렜다. 숙소에 돌아가서도 관광 보다는 그 풍경이 떠올라 괜히 터미널을 띄워넣고 “ls; cd; vi”를 반복했던 것 같다. 학교로 돌아와 에딘버러에서 본 그 사람들이 가는 학회에 나도 한번 논문을 내보자라는, 석사1년차로는 얼토당토 않은 생각을 품었다. 교수님은 “안될텐데 거기는…”, 만류 하셨지만, 고집을 부려 두달 부지런히 일했고 논문을 제출했다. 다시 두달후에 논문이 accept됐다는 이메일을 받았을때 아마 그때가 태어나 처음으로 성취감을 느꼈던때 였던것 같다. 그리고 그 논문덕에 구원투수 방어율같던 학점을 극복하고 유학을 나올 수 있었다.

그리고 나는 지금 9년전 눈으로 봤던 그 모습으로 살고 있다. 청바지에 샌달신고 (솔직히 흰양말은 안신는다)  출근해 그때 봤던 그사람들 사이에서 코딩하고 있다 (실제로 지금 회사 동료들이 에딘버러 그곳에 있었다). 아마 그때 그 모습을 못보았다면 지금 난 다른 삶을 살고 있을거라 생각한다. 솔직히 지금 모습이 그렇게 자랑스러워서 글을 쓰는건 아니다. 동기들에 비해 경제적으로는 오히려 궁핍하다. 그냥 눈으로 찍어놓은 가장 인상적인 기억이 구현된 것, 즉 비전의 사전적 의미가 현실에도 적용되는게 신기해서 기록하는 것이다.

그리고 또다시 고민은 10년후에 구현할 내 모습이다. 지금 스냅샷을 찍고 가슴에 담아야 할 생생한 풍경, 비전은 무엇일까? 계속 주변 사람들과 현상을 관찰하는 습관은 아마 그 때문인지도 모르겠다. 뛰어난 영웅 — 최고로 가치있는 삶을 사는 사람 — 을 가까이에 두고 그 모습을 찍고 싶다.

– 박상민 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]

  • HP에서 일하던 스티브 워즈니악과 Atari 라는 게임회사에서 일하던 스티브 잡스는, 원시 PC Altair 에 매혹된 동호회 모임 Home Brew Computer Club (집에서 만든 컴퓨터 클럽) 의 다른 회원들에게 자랑할 컴퓨터를 만들기 시작한다 (1 만족). 워즈니악의 세련된 디자인에 동호회 사람들은 감동하고 (3 만족) 이에 확신을 얻은 잡스는 아직 HP를 떠나지 않은 워즈니악을 설득해 회사를 설립한다. Markkula라는 동네 부자가 2억 5천만원을 투자해 본격적으로 잡스의 집 차고에서 애플 PC를 만들기 시작한다 (4 만족) [참조 5].

  • 빌게이츠와 폴앨런 역시 하버드 신입생 시절 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).

  • 지금 우리 회사 (Eucalyptus systems) 도 정확히 이 패턴으로 성장하고 있다. 2009년 UC 산타바바라에서 교수(Rich Wolski)와 대학원생, 포닥으로 이루어진 6명은  본업인 논문은 안쓰고 몇달간 아마존 클라우드를 오픈소스로 구현하기 시작한다 (1 만족). 이 소식을 접한 옛날 그리드 컴퓨팅 사람들 (시카고의 Ian Foster등)은 클라우드는 그리드랑 똑같으니 뻘짓하지 말라고 지적한다 (2 만족). 간신히 초기 버전을 만들어서 오픈소스로 공개하고 곧 수천번 이상의 다운로드 횟수를 기록한다 (3 만족). 이어서 바로 몇개의 투자 회사(VC) 들이 250억 이상을 투자하고 현재는 60여명 정도의 직원으로 성장한다 (4 만족).

나는 위의 기본 템플릿에 실리콘밸리의 영웅들과 혁신적 기술을 대부분 때려 맞출수 있다고 생각한다. 즉, 기존의 조직 (학교/회사)에서 받아들일수 없는 프로그램을 만든 아웃라이어 (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