버그의 축복

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]

  • 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

소프트웨어, 하드웨어의 아버지

1. 들어가며
요즘 나는 블로그 댓글 보는 재미로 산다. 사람들의 칭찬 한마디 보는게 이제 8개월된 딸내미의 방긋대는 얼굴만큼 흐뭇하다. ‘이러다 너드들 사이에서 강풀 (만화가)되는거 아냐?, 우훗’, 상상도 해보다가 이내 짧은 글심이 떠올라 좋은 주제나 찾아야지 생각하게 된다. 이번에 풀고 싶은 주제 역시 지난번처럼 신문기사를 읽다가 떠올랐다. 안철수님의 “하드웨어 대응 만으로는 승산없다” 라는 기사의 한 부분에 이런 언급이 나온다:

“얼마 전 하드웨어·소프트웨어·인터넷 서비스 등으로 분류해 IT업계 트렌드를 설명했더니 대기업 전자회사 최고기술책임자(CTO) 한 분이 소프트웨어는 하드웨어를 구동시키는 하나의 부분이므로 분류가 잘못됐다고 지적하더라.”

“소프트웨어가 하드웨어를 구동 시키는 하나의 부분”이다. 왠지 울컥하다. 그래, 하드웨어로 성공한 우리나라에서 소프트웨어의 역할은 그게 맞다. 빠른 CPU, 넓은 메모리에 광활하고 밝은 디스플레이, 미려한 외관으로 장식된 하드웨어를 소프트웨어는 “구동” 시키고 있다. “구동”이 주는 어감….그렇지, 소프트웨어는 뛰어난 하드웨어가 돋보이도록 낮은곳에 숨어 봉사하고 있다.  SW에 큰 관심없는 일반인들에겐, 형체없는 소프트웨어를 설명하는데 이것보다 더 좋은 표현이 있을까?. 얼마전 SW벤쳐에서 일하는 내게 아버지가 “너희 회사 공장은 어디있냐?” 하신적도 있다 (공장은 마음속에 있어요 아버지). 아마도 “하드웨어 나고, 소프트웨어가 나오는 거다” 라는게 상식처럼 되어버린 세상인데, 근데, SW로 온가족이 먹고 살아서 그런가, 왜 나는 이 기사에 울컥하고, 뜨거운 것이 솟아오르는 건가?…그렇게 고민하며 주말을 보냈다.

나는 이 에세이에서 그 반대의 이야기를 하고싶다.  “소프트웨어가 하드웨어의 애비다” 라고 외쳐본다. 여기에서 나는 소프트웨어-본질-의 역사와 하드웨어-우연-의 역사에 대해서 소개하고, 역사가 우리 프로그래머들에게 던지는 의미에 대해 쓴다. 이 글의 큰 줄거리는 지난 블로그에서도 소개했던 [1] 에서 영감을 얻었다. 그리고 좀 더 깊게 들어가는 증명은 컴퓨터 이론 텍스트북 [2,3] 에서 찾을 수 있다 (뭐, 증명이라고? — 그렇다. 심하게 재미 없을수도 있다).

2. 라이프니치의 꿈
계산과 논리는 인류가 기록물을 남긴 시절 이전부터 존재했을거다. 1+1=2 라는 사칙연산말고도, 일련의 논리적 절차를 거쳐서 결과를 보이는 계산 — 즉 알고리즘– 에 대한 인류의 자각은 아주 먼 옛날(bc)의 기록에서도 찾을 수 있다 [4]. 비 전공자에게 알고리즘은 좀 낯설수 있으니 예를 들면서 시작하자.

문제: 주어진 임의의 숫자 나열 중 가장 큰 숫자를 찾아라

1) 제일 큰 숫자를 저장할 공간을 a 라고 부른다.
2) 제일 처음 숫자를 a에 집어 넣는다.
3) 모든 수에 대해서 a와 비교해, a보다 더 큰 숫자가 나오면 a에 집어 넣는다.
4) a를 출력한다.

엄청 간단하다. 한단계 이상의 논리적 절차를 걸쳐서 결론을 냈으니 아무튼 알고리즘이다. 조금 더 복잡한 알고리즘을 소개하자면 binary search같은것이 있겠다.

문제: 순차적으로 정렬된 숫자들 가운데서 숫자 K를 찾아라

1) K와 중앙에 위치한 수를 비교한다.
2) 비교한 결과 같을 경우, 찾았음을 알리고 종료한다.
3) K가 작을 경우엔, 처음부터 중앙 바로 전까지의 숫자를 가지고 1)을 반복한다.
4) K가 클 경우엔, 중앙 다음부터 마지막까지 숫자를 가지고 1)을 반복한다.

이같은 알고리즘의 기록은 bc.300 년전 이상으로 올라간다 [4]. 일련의 논리적 절차를 거치는 계산이 알고리즘인것은 알았지만, 17세기까지 아직 절차를 어떻게 표현할 것인가는 인식하지 못했다. 현대의 프로그래밍 언어가 바로 그런 역할을 한다.

그런데 역사상 최고의 수학자중 한명인 독일의 라이프니츠(1646-1716)는 그 옛날 이런 발칙한 상상을 시작한다.

“계산과정(알고리즘)을 몇가지 글자로 표현할 수 있다면, 그럼 어쩌면 세상 모든 알고리즘에 항상 답을 주는 마법과 같은 기계(machine)를 만들수 있지 않을까?”

다시 말해서, 알고리즘을 정해진 언어로 표현해 낼 수 있다면, 그럼 우리는 그 언어로 써내려간 스토리를 마법의 공식에 집어 넣을 수 있지 않을까? 그리고 그 공식은 즉각 답을 내어준다니, 라이프니츠의 상상은 진정 대인배다웠다. 프로그래머라면 금방 알것인데, 라이프니츠의 상상은 우리가 매일 하는 그짓이다. 프로그래밍 언어로 알고리즘을 써내려가고, 이를 컴퓨터에게 주면, 컴퓨터는 항상 답을 준다. 그런데, 그가 발칙한 이유는  이 단어, “항상 (Always)”, 에 있다. 정말 모든 질문에 컴퓨터는 정답을 이야기 하나? 이 질문이 주는 깊이는 대단해서, 참으로 증명되면 적절한 데이터를 주었을때 “신이 존재하는가?” 의 질문에도 답을 할수 있다는 뜻이다. 이에 감명받은 어떤 신학자는 수학 공식으로 신의 존재를 증명하려는 잉여행동까지 감행한다.

이를 라이프니츠의 Dream Machine 이라고 부른다. 그가 상상한 마법의 기계(Machine)는 물리적 기계(하드웨어)가 아닌 무형의 “공식” 혹은 “알고리즘” 이다. 그당시 상상으로는 이 마법 레서피가 적힌 책을 들고 있는 사람에게 알고 싶은 질문을 (프로그램 언어로)써서 주면 그 사람이 마법 레서피로 주어진 문제를 계산해 결과를 가르쳐주는 것이다. 컴퓨터는 컴퓨터인데, 사람이 계산하는 컴퓨터라니, 엄청 느렸을 거고 담당자의 기분 따라서 결과가 달라졌겠지?

어쨌든, 라이프니츠는 인류가 “Let us calculate!” 이렇게 외치는 순간이 곧 올 것이라 믿었다. 라이프니츠 이후, 불(Boole), 프뤠게(Frege), 칸토(Cantor), 힐버트(Hilbert)로 이어지는 논리학, 수학의 거장들이 하나 하나 문제 해결을 위한 단초를 제공하게 된다. 그들은 이 문제에 대해, “Yes: 그래 그런 마법의 공식은 존재해!”, 혹은 “No: 그런 마법 공식은 존재할 수 없어!”, 이 둘 중 한가지를 증명해내기 위해 평생을 잉여짓으로 보낸다. 그리고 20세기에 와서야 우리는 결론에 도달했다.

3. 튜링의 잉여짓
수백년을 이어온 이 질문은 영국의 젊은 천재 수학자 튜링 (Alan Turing, 1912-1954)[6]에게도 최고의 도전거리였다. 하지만 안타깝게도 그 보다 앞서 이  질문에 답을 한 또 하나의 천재 수학자가 있었으니 그가 바로 오스트리아 출신 괴델 (Kurt Godel)[7]이다. 괴델은 25세 되던 1931년 Incompleteness Theorem 을 발표하고, 라이프니츠의 꿈 – Dream Machine – 은 존재할 수 없음을 증명했다. 즉 세상엔 답을 할 수 없는 어떤 문제 (질문)가 존재하는 것이다. 어쩌면 당연하다. 어떻게,”엄마 좋아, 아빠 좋아?” 혹은 “짜장이 갑이냐, 짬뽕이 갑이냐?”  이런 질문들에 답을 할 수 있겠는가?

괴델의 완벽한 증명에도 불구하고 튜링은 왠 똥고집이었는지, 자신만의 사고로  Dream Machine이 존재할 수 없음을 증명하기 시작했다. 잉여짓의 좋은 예다. 그 결과가 컴퓨터 학과 학생들의 헬게이트를 열어버린 튜링 머신이다. 여기서 나도 뭔 똥배짱인지는 모르지만, 튜링의 증명을 소개한다. 그동안 두편의 블로그로 쌓아온 “이해하기 쉽게 쓰는 블로거”의 이미지를 한방에 날려버릴 절호의 찬스다! 굳이 이런 짓을 하는 이유는, 이 증명안에 설명하긴 참 어렵지만, 심오한 진리가 있기 때문이다.

컴퓨터 프로그램은 가장 단순히 표현하면 위의 그림과 같은 일을 한다. 즉 프로그램 P는 주어진 인풋 데이터를 가지고, 질문이 참인지 거짓인지를 대답한다. 바로 이때, “어 근데 어떤 질문들은 참/거짓 말고 다른 대답을 하잖소?” 라고 물을 것이다. 예를 들어, 아까 설명한 최대값 찾는 알고리즘은 결과값이 숫자여야 한다. 하지만 그런 질문들은 쉽게 참/거짓으로 변환이 가능하다. 즉, 나열된 숫자에 대해서 “1보다 더큰 수 있냐?”, “2보다 더큰 수 있냐?” 이런 식으로, “아니오” 가 나올때까지 질문하는 것이다. 이것이 라이프니츠 전까지 존재했던 모든 알고리즘 혹은 논리적 사고의 가장 단순한 형태다.

우리들의 아버지 튜링은, Input, P, 와 T/F 결과값으로 이루어지는 이 단순한 형식을 신비하게 변형시킨다. 아래의 그림은 그의 Halting 프로그램을 표현 한 것이다.

이 프로그램은 특이하게 인풋으로 프로그램(P)과 데이터(I)를 모두 받는다. 그리고 내부에서 하는 일은 받은 P를 데이터 I를 넣어 돌리는것이다 (너드 언어로 에뮬레이션 한다). 그리고 나온 결과 값이 참일 경우, 거짓을 출력하고, 반대로 거짓일 경우 참을 출력한다. 그럼 이런 프로그램을 진짜 만들 수 있냐? 라는 질문이 나오는데, 조금만 생각해 보면 그리 어렵지 않다. 잠시 “너드” 모드로 들어가서 설명하자면:
– H라는 프로그램과 P라는 프로그램 모두 C 언어로 짠다.
– H는 내부에서 gcc 를 콜해서 P를 컴파일 한다. P의 바이너리가 나온다.
– Fork하고 execute해서  P를 돌린다. 데이터는 I를 넣어준다.
– 나오는 결과값 검사해서 반대를 출력한다.

여기까지 읽고 계신분들께 존경을 표한다. 갈길이 그리 멀지 않다. 여기서 한가지 이상한 짓을 해보자. 아래와 같이 H 프로그램의 인풋으로 H 프로그램 소스코드를 두번 넣는 것이다.

이 경우 H프로그램이 하는 일은 무엇일까? 다름 아니고 H프로그램 자신의 소스코드를 컴파일하고, 돌려서 결과를 반대로 출력하는 것이다. 그럼 위의 경우에 H 프로그램의 결과값은 무엇이 될수 있을까?

참: H가 참이 되려면 안에서 돌아간 H가 거짓이어야 한다…어?
거짓: H가 거짓이려면 안에서 돌아간 H가 참이어야 한다…어?

말이 안된다. H는 어떤 결과도 낼 수 없다. 다시 말해  H라는 프로그램은 존재 할 수가 없는 것이다.  바로 이것이 튜링이 라이프니츠의 Dream Machine을 반증하기 위해 만들어낸 존재할 수 없는 알고리즘 (Undecidable problem) 인 것이다.

4. 폰뉴먼과 우연한 하드웨어
과학에 2등은 없다. 튜링은 괴델보다 늦게 증명을 했으니 그는 루저였다. 그러나 튜링은 괴델과 함께 타임지의 20세기 100대 인물에 올라가 있고, 컴퓨터의 아버지라 불리고 있다. 매년 주어지는 컴퓨터의 노벨상을 튜링 어워드라 부른다. 튜링의 놀라운 업적은 증명과정에서 보여준 H라는 프로그램에 있다. 튜링 전에도 원시 형태의 컴퓨터들이 있었는데, 이것들은 기계나 전기를 활용하여 단 한종류의 알고리즘만을 구현하는 것이었다. 이를테면 아래의 사진은 튜링보다 100년이나 앞서 시도됐던 Charles Babbage의 초대형 미분방적 계산기 부속품이다. 오로지 미분방적식만 풀 수 있는 거대한 기계다.

그런데 튜링의 증명과정에서 보여준 H 프로그램은 그 내부에서 임의의 프로그램 P를 수행할 수 있다. 그는 어떤 형태의 프로그램 P든 간에 돌리고 결과값을 산출할 수 있는 H 프로그램을 어떻게 만들어 내는지를, 읽고 쓰기가 자유로운 테이프를 활용해서 보여주었고, 이를 우리는 Universal 튜링 머신이라 부른다. 어떠한 종류의 프로그램 (SW)이든 받아서 돌리고, 결과를 보여주는 어떤것, 왠지 컴퓨터의 냄새가 솔솔 나지 않는가?

이 아이디어를 처음 하드웨어로 구현한 사람은 바로 폰 뉴먼 (John Von Neumann) [8]이다. 폰 뉴먼은 20세기 최고의 천재로 불렸고, 별의 별 분야(사실 잘 모르니 이렇게 표현할 수 밖에)에 업적을 남긴 수학자였다. 그는 1945년, 튜링이 생각해낸 방식을 좀 더 구체화시켜서, 프로그램이 메모리에 저장되는 컴퓨터 EDVAC [5]의 컴퓨터 구조를 고안했다(너드언어로, 프로그램 카운터, 논리연산, 레지스터, 연산과 데이터 메모리 통합 고 따위것들이다). 그가 써내려간 구조를 하드웨어 천재들 ( John Mauchly and J. Presper Eckert)이 구현해 내는데, 이것 저것 잡다한 아날로그 전기부품을 다 써보다가, 우연히 TV등에 널리쓰인 진공관을 활용해 이런 괴물 컴퓨터를 만들어 내기에 이른다.

여담으로, 폰뉴먼은 낚아채기의 달인이다. 폰뉴먼은 튜링의 논문에서 아이디어를 얻었으면서도 자기 저서들에서 이를 언급하지 않았다. 또 함께 일했던 하드웨어 달인들의 영향을 무시하고 무명의 용사들로 만들어 버린 결과, 훗날 그들과 특허 전쟁을 치룬다. 괴델과 튜링 모두 타임지의 20세기 100인에 선정되었지만, 폰뉴먼은 대단한 업적에도 불구하고 선정되지 못했다. 어쨌든, 폰뉴먼의 구조는 70년이 지난 지금도 여전히 유효해서, PC, 타블렛, 스마트폰 모두 여전히 폰뉴먼 구조라 부른다. 다 알다시피, 이후 6-70년대 실리콘과 마이크로프로세서의 혁명으로, 컴퓨터는 인류에게 본격적으로 침투했다.

5. 결론
여기까지 써놓으니 읽는분들께 왠지 미안하다. “이따위 길고 지루한 역사 이야기만 하다니, 대 실망이다!” , 이런 원망이 들리는듯 하다. 내 얕아빠진 지식을 길게, 가까스로 풀어놓은 이유는…

“소프트웨어는 하드웨어를 구동시키는 하나의 부분 ”

나는 이 말이 진정 듣기 싫기 때문이다.

bc 300년전에도 존재한 유클리드의 알고리즘, 라이프니츠가 상상한 모든 질문에 대답해 주는 Dream Machine, 그리고 컴퓨터의 표본인 튜링의 Universal Machine 까지, 그 어떤 것도 하드웨어가 아니었다. 인간의 두뼘남짓 뇌에서 피어난 논리의 결과물, “지식(Knowledge)이란 무엇인가?” 이 질문에 인생을 걸었던 철학/과학자들의 피와 땀이 만들어 낸 결과물은 바로 소프트웨어다.  (참고로 철학박사인 친한 형과 비슷한 대화를 나눈적이 있다. 그 형은 위에 언급된 모든 사람들을 알고 있었다.)

위 카툰처럼 우리의 소프트웨어와 프로그래머들이 받고 있는 대접이 너무 씁쓸하다. 소프트웨어는 우연의 산물 하드웨어를 보조해주는 또 다른 우연이 아니라, 태초부터 인간의 인간다움속에 내재돼있던 고귀한 창조물이다. 학부 1학년이 과제로 짜는 100줄의 코드도, 수백명 엔지니어가 함께 짜는 안드로이드의 100만줄 코드도 모두 동일하다. 주어지는 문제는 다르지만, 우리의 이 작은 뇌로 고도의 생각을 집중하고, 논리의 다리를 쌓아나가 목표에 다다른다. 우연한 하드웨어 (x86, 메모리 크기, 디스크의 속도)와 환경 (데드라인, 돈, 사회적 시선)의 제한에 둘려쌓여 있지만, 우리는 그 한계들마저 소프트웨어로 계산하고, 하나 하나 해결해 나가는 그 즐거움에 취해 산다.

“소프트웨어는 하드웨어를 구동시키는 하나의 부분 “

천하에 불효자들이나 지껄일 수 있는 소리일 뿐이다.

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

[1] The Universal Computer: The Road from Leibniz to Turing by Martin Davis
[2] Introduction to Automata Theory, Languages, and Computation, by John E. Hopcroft, et al.
[3] Introduction to the Theory of Computation, by Michael Sipser
[4] Euclidean Algorithm: http://en.wikipedia.org/wiki/Euclidean_algorithm
[5] EDVAC: http://en.wikipedia.org/wiki/EDVAC
[6] People of the century: Alan Turing (http://www.time.com/time/magazine/article/0,9171,990624,00.html)
[7] People of the century: Kurt Godel (http://www.time.com/time/magazine/article/0,9171,990621,00.html )
[8] John Von Neumann: http://en.wikipedia.org/wiki/John_von_Neumann

소프트웨어, 실무형 인재의 신화

1. 들어가며
며칠전 쓴  “소프트웨어, 잉여와 공포”, 이 글이 생각보다 흥해서 충격을 받았다. 음, 솔직히 말하자면 회사에서 일은 안하고 방문자수를 체크하며 혼자 흐뭇해 하는 저질스러운 나를 발견했다. 흥한 글 다음에 망글을 쓰면 어쩌나 하는 부담감에, 좀 더 좋은 주제가 생각나면 써야지 생각하다가 다음과 같은 제목의 기사를 읽게 됐다:  “SW 실무 인재 직접 양성”…NHN ‘SW 아카데미’ 설립. 마음에 타오르는걸 꼭 써야할것 같아 어쩔수 없이 키보드 앞에 앉았다 (솔직히 재미없을까봐 두렵다).

예상되듯, 국내의 큰 포털회사가 실무와 동떨어진 대학 커리큘럼에 실망해 직접 큰 규모의 SW학원 (어쩜 학교일지도)을 시작한다는 것이다. 그동안 삼성이 언론을 통해 자주 이야기 하던 그것인 듯 하다 (더 글을 쓰기전 이점을 밝혀두고 싶다: 나는 삼성이나 타 IT기업에 전혀 악감정을 갖고 있지 않다. 오히려 선후배, 친구들이 많이 그곳에서 일하니까 잘 되었으면 하는 바램이다. 이글에서 삼성은 특정 회사를 지칭하기 보다 한국의 대기업 전체를 지칭한다고 보는게 좋겠다).

“요즘 졸업생들은 실무 교육이 너무 안돼 있다. 다시 재교육을 시켜야 하는데…(짜증난다). 학교들아, 좀 제대로 가르쳐라”

물론 호통만 치는게 아니라 학교들에 돈을 좀 쥐어주고 졸업생 취업을 보장하는 등의 당근을 제공한다. 학교는 이에 맞추어 커리큘럼을 “삼성형 인재” 개발로 최적화 하는 패키지로 보답한다. 이 스토리엔 삼성취업 xx% 라는 문구에 따라 변하는 입학생 수능점수 때문에 어쩔수 없이 자존심 굽히는 학교의 애잔함이 녹아있다.

교육덜된 학생에게 호통치는 삼성은 개인적으로도 경험했다. 작년 영원할것 같던 박사과정을 마치면서 삼성 계열사에 면접을 본적 있다 (해커의 자존심을 지키기 위해 밝히자면 면접보자고 연락을 먼저 해왔다). 먼 도시까지 달려가 임원 면접이라는 것을 보게됐는데, 이런 상황이 연출됐다:

막내 대리 : (생글 생글) 박사님 연구 방향을 좀 소개해 주시죠?
나: (짐짓 태연) 네 저는 가상화 어쩌고, 운영체제 어쩌고, …., 를 했습니다 (그래서 제가 이렇게 잘났습니다 크흠)
임원님: (처음부터 쉿 드신 표정이었다) 그래서 어쩌라고요? 그게 우리 회사랑 뭔 상관이냐고? 박XX씨가 우리 회사를 위해 할수 있는게 뭔지 한번 말해 보라고.
나: (급 당황) 아 예..어 저는 삼성의 요번 새로 시작하는 비지니스에…(더듬 더듬) ..
임원님:  난 당신 그 말이 이해가 안된다고(요)..우리가 얼마나 큰 회사인지 아냐고(요). 학교에서 컴터 몇대놓고 조물대던거 가지고 무슨 도움이 되는지 얘기를 해보라고요.. 
나: (망했다). 

위의 상황은 정확한 대화 기록은 아니지만 대충 기억에 따르면 그랬다. 임원분은 호통만 치다가 면접이 끝났다. 물론 나중에 압박면접 이었노라고 날 달래주었고 나쁘지 않은 조건으로 입사를 제의받았다. 하지만, 분명히 알것 같았다. “아 저런 상황을 견딜수 있는 대인배들만 받겠다는 거구나” — 즉 공포의 관리에 내가 얼마나 견디는지를 시험해본 것이다. 난 소인배여서 가지 않았고, 다음날부터 교수님에게 “제발 자리좀 알아봐 주십쇼…” 애걸했다.

이 블로그는 제목 그대로 소프트웨어 실무형 인재 그 허구를 이야기 하고자 한다. 또 대학과 정부에 대해서 한소리 하고자 한다.

2. 실무형 인재
실무형  인재란 회사마다 정의가 다를 것이다. 삼성의 TN 부서라면 임베디드 시스템을 알고, 통신 프로토콜을 구현할 수 있으며, 인도사람 영어를 잘 알아듣는사람일 것이다. NHN이라면 기사에 나와있는 그대로 웹, 스마트폰, 게임 프로그래밍 전문가를 이야기 할 것이고. SI라면 DB설계, SW 디자인, ‘을’로 살아가는 법을 아는 사람을 실무형 인재라고 이야기 할 것이다. 스펙트럼이 이렇게 다양한 회사들이 학교에게 ‘실무형’ 인재를 가르치라면, 학자로서의 자존심 있는 대학들은 “엿이나 드쇼” 하고 싶지만, 수능점수가 아쉬워 어쩔수 없이 커리큘럼 세트를 만들어 낼수 밖에 없다. 빅맥 삼성 탤런트 세트, NHN 웹퍼 세트, SI 을고기버거 세트.  이제 몇년간은 아이폰, 안드로이드에 정통한 졸업생들을 만날 생각에 마음이 뿌듯하기 그지 없다.

3. 소프트웨어 – 추상적 사고 (Abstract thinking) 와 우연한 구현 (Accidental Implementation)
좋은 소프트웨어 엔지니어 교육을 이야기 하는 것은 쉽지 않고, 위험하다. 누구나 다른 관점에서 바라보고, 자신이 걸어온길을 돌아보며 설명하려 하기 때문이다. 나 역시 내가 유학시절 경험한 과정과 미국 벤처생활을 통해서 배운것으로, 좋은 소프트웨어 교육을 이야기 하려고 한다. 참고로 나는 버지니아 주립대학 (UVA)이라고, 나름 잘 가르친다고 평가받는 학교에서 낮은(!) 학점으로 박사를 마쳤다.  소프트웨어의 본질은 Fred Brooks 의 No Silver Bullet [1] 이라는 에세이에서 가장 정확히 다룬 듯 하다 (혹시 Mythical Man-month를 안 읽어보았다면 절대 강추다. SW고전중의 고전이니까; 번역도 되었으리라 생각한다).

6-70년대에 운영체제 같은 소프트웨어가 본격 개발되면서, 엄청나게 돈이 많이 들고 매번 데드라인을 넘기면서 나오는 작품들이 거지같다는 것을 (그제서야) 깨달았다. 기계나 HW는 안 그런데, 왜 SW만 그런것인지 사람들은 분개하기 시작했고, 최고의 엔지니어이자 Writer였던 F Brooks 는 이렇게 설명했다. 소프트웨어에는 내제된 어려움 (Essential Difficulties)과 우연한 어려움 (Accidental Difficulties)이 있다. 내제된 어려움은, 세상에 어떤 기술로도 해결할 수 없는 소프트웨어의 특성 때문이다. 즉 문제 자체가 워낙 복잡하고, 쉽게 바뀌며 (고객이 요구사항 바꾸듯), 보이는 실체가 없다는 점이다 (즉 얼마나 진행되었는지 알 방법이 없다). 반면 우연한 어려움들은 HW와 SW의 진화를 통해서 그동안 해결되었다. 우연한 어려움과 해결의 예로는:

  • 0/1 이진법으로 돌아가는 기계를 코딩하기가 쉽지 않다. ==>  C와 같은 하이레벨 언어를 써라
  • 컴퓨터를 여러 사람이 쓰기 쉽지 않다 (혹은 초기 아이폰처럼 여러 프로그램을 돌릴수가 없다). ==> 멀티 태스킹을 운영체제에 구현해라.
  • A에서 짠 프로그램을 B 컴퓨터에서 못 돌린다. ==> 라이브러리를 통합해라.

좋은 대학교의 컴퓨터 과학(공학) 전공은 본질과 우연한 어려움 두가지 모두를 해결하도록 돕는다. 즉, 알고리즘, 컴퓨터 이론, 데이터 구조, 소프트웨어 개발론 이런 과목들은 본질적인 어려움을 깨부수는데 필요한 이론들을 가르친다. 원체 복잡한 문제를 해결할때는 문제를 추상화 시키고,  잘 알려진 자료구조(예를 들어 그래프)로 표현해 낸후, 이미 알려진 알고리즘 혹은 새 알고리즘을 적용해서 해결한다 (참고로 컴퓨터 전공자들은 [2]를 강추한다. 이론때문에 고생하던 내가 눈물을 흘리며 읽었던 명서적이다). 반면 우연한 어려움을 해결하는데 역사적으로 사용된 기술들은 운영체제, 컴파일러, 네트워크 이런 과목들을 통해서 배운다. 즉 한국형 안드로이드 투자액 30억중 5만원으로는 운영체제책을 (공룡책 강추) 사야한다.

나의 경험을 통해 보면 미국에선 본질적 문제를 해결하는 과목에 좀 더 집중한다. 반면 한국은 우연한 문제를 해결하는 과목에 치중하고 있고, 이에 더해서 삼성은 그들만의 어려움을 해결할 테크닉을 가르치라고 닥달한다.  나는 본질적 문제를 해결하는 것을 교육하라고 주장한다. 왜나면 거기에 SW 경쟁력이 있기 때문이다. 검색의 예를 들어 보자. 초기 검색엔진 시장은 알타비스타 라는 엔진이 장악했다. 이 엔진은 알고리즘은 그저 그랬는데, DEC라는 예전 대기업에서 운영했기 때문에 서버와 데이터를 많이 갖고 있었다 (즉 우연한 문제를 해결했다). 반면 구글 창업자 래리 페이지와 세르게이 브린은 스탠포드 대학원시절 Page Rank라는 뛰어난 알고리즘을 가지고 데스크탑 한대로 서비스를 시작했다 (즉 본질적 문제를 해결했다). 결과는 우리가 잘 알고 있다.

좋은 소스 코드를 보면, 마치 좋은 책을 읽는듯 마음이 흡족하다. 좋은 소스 코드는 프로그래밍 언어의 숨겨진 마법을 잘 쓴 (이를테면 C의 포인터 장난) 그런 것이 아닌, 프로그래머의 뛰어난 표현력 (자료구조), 논리력 (알고리즘), 그리고 디자인 (소프트웨어 공학) 이 드러나는 그런 창작물이다.  어떤 이는 이렇게 주장할 것이다 “한국처럼 후발주자가 미국 따라가려면 좀 덜 고상한 방법을 써서라도 구현만 하면 됩니다!” . 그건 기계와 HW에 적용될지 몰라도, SW 엔 절대 안된다. 제 아무리 빠른 삼성 CPU를 써도 버블소트는 퀵 소트를 이기지 못한다.

4. 정부와 학교의 놀음
이 글을 높으신 누군가 보고, “옳커니 그럼 이론쪽을 강화하는 교육을 하면 되겠구만 (…할리도 없다 사실은…)” 라고 마음 먹어도, 문제는 그리 간단하지 않다. 학교들에 그쪽을 전공한 교수들이 많지가 않기 때문이다. 이유는 그동안 정부와 대학의 이런 놀음 때문이다:
“정부: 000 대통령 취임에 맞추어 xxx (예:유비쿼터스,그리드,클라우드,스마트폰,월드클래스) 프로젝트를 하사하노라. 대학들은 줄을 서도록 하라”
“대학:  예이”
“정부:  전문가를 프로젝트에 집어넣거라”
“대학: 뽑겠나이다”

이렇게 뽑은 교수들은 모두 우연한 어려움을 해결하는데 전문가들이다. 그쪽 분야가 쓸모 없다는 뜻이 아니다. 절대적인 비율로 그 분야들만 뽑아들이는것이 문제다.  내가 학교 생활을 하면서 세번의 정부가 바뀌었는데, 이 패턴은 늘 같았다. 사실 이 이야기는 내 발등을 찍는것과 같은데, 왜냐면 나 자신도 분야가 그쪽이기 때문이다.

5. 결론
이 블로그는 결론이 제일 어렵다. SW의 본질적인 어려움을 해결하는 대학 본래의 모습을 찾아라, 이것이 하고자 하는 말인데, 그럼 어떻게 해야 지금 우리 현실에서 그게 가능할지 이 질문에는 답이 나오질 않는다. 하지만 제일 문제있는 그룹은 공무원과 정치가라고 자신있게 이야기 할 수 있다. 왠지 한참 전에 읽은 J.C.R Licklider 라는 양반의 일대기 [3] 가 기억에 남는다. Licklider는 원래 MIT (인가 하버드인가) 심리학 교수였는데, 대단한 잉여자였다. 전공도 아닌 컴퓨터에 홀려서 카드를 집어넣는 집채만한 컴퓨터앞에 매일처럼 앉아 일과 상관없는 프로그래밍 하던 사람이다. 아마 나중에 교수도 그만두고 슈퍼컴퓨터 만드는 회사에서 일한 것으로 안다. 이 사람이 나중에 어쩌다보니 미 정부의 연구 프로젝트를 총괄하는 사업 책임자가 되었다 (즉 공무원이 되었다).  이 사람의 잉여력과 비전으로 추진된 두가지 사업이 있다:
1.  미 국방부의 ARPANet : 국방부 산하 슈퍼컴퓨터를 네트웍으로 연결해보는 프로젝트
2.  MIT의 Multics 라는 운영체제 개발

어떤분들은 이미 아실것 같다. 1 사업이 나중에 인터넷이 되었고, 2 사업은 그 자체는 빛을 못봤지만, 프로젝트에 참여했던 사람들이 회사로 옮겨 곧 C언어와 Unix 를 만들었다 (Linux는 Unix의 후손이고). 즉, 한 공무원이 IT기술의 물줄기를 열어버린 것이다.

우리 정부와 학교에도 그런 잉여와 비전이 넘치는 분이 나오길 기대하며 글을 마친다.

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

[1] No silver bullet – The Mythical Man-Month 챕터 16, by Fred Brooks.
[2] The Universal Computer: The Road from Leibniz to Turing by Martin Davis
[3] The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal (http://en.wikipedia.org/wiki/J._C._R._Licklider)

소프트웨어, 잉여와 공포

1. 들어가며
요즘 포털을 통해 접하는 IT 뉴스 제목들은 한결같이 “위기의 한국 소프트웨어(SW)… ” 인듯 하다. 특히 지난주 구글이 모토롤라 Mobility 사업부를 인수하면서, 안드로이드에 의존하는 스마트폰 사업이 몰락하는 것 아닌가 하는 두려움이 극에 달했고 결국은 “한국 정부: 안드로이드와 경쟁할 새 오픈소스 OS 개발” 이라는 기사마저 출현케 했다. 이럴 때 영어로는 “성스러운 똥” 이라는 단어로 대응하고 싶다. 꼭 한국만 SW 분야에서의 위기 의식을 느끼는 것은 아니다. HP가 PC 사업을 접고 현금을 모두 끌어모아 Autonomy 라는 영국 SW 회사를 인수준비 한다는 기사를 보았을 것이다. 미국의 초대형 IT회사들 근본마저 흔들고 있는 소프트웨어 혁명앞에 우리는 두려움에 떨고 있는 듯 하다.

하지만 이것이 한때의 지나가는 바람이 아님은 확실하다. 네츠케이프 설립자이자, Facebook, twitter등의 잘 나가는 인터넷 기업들에 투자한 Marc Andreesen 이 지난주 월스트레이트 저널에 “왜 소프트웨어가 세상을 먹어치우고 있는가?” 라는 글을 기고했다. 여기에서 그는 제목 그대로 소프트웨어가 구식 산업을 먹어치우고 (disrupt) 있다고 진단하며 몇가지 예를 들었다:

  •  아마존은 온라인 서점과 이북 (킨들)을 성장시켰고, 대형 서점 체인 Borders를 문닫게했다.
  •  Netflix 는 영화 스트리밍을 정착시켰고, 구식 대여점 블록버스터는 결국 도산했다.
  •  Farmville을 히트시킨 인터넷 게임 회사 Zynga와 Angry Birds와 같은 스마트폰 게임은 급격히 성장하고 있고, EA와 닌텐도와 같은 전통 게임 회사는 하락하고 있다.
  • 가장 빠르게 성장하는 통신(telecom)회사는 Skype 이고, Qwest와 같은 구식 통신사는 날이갈수록 매출이 감소하고 있다.

Andreesen 은 정확히 보았다. 진정으로 소프트웨어가 세상을 먹어 치우고 있다. SW없이구식 산업으로 “눈부시게” 성장한 한국이 두려워하는 것은 기우가 아니다. 하지만 과연 우리는 미국 SW 시장을 제대로 알고 있을까? 갓 30년 남짓한 세월에 세상을 먹어 치우는 실리콘밸리의 화려함에만 집착하는 것은 아닐까?

2. 해커 문화가 근본이다
Steven Levy 가 쓴 Hackers 라는 책이 그 문화를 가장 잘 소개한 듯 하다 [1]. 실리콘밸리의 뿌리는 해커 문화다. 남의 시스템을 침범해서 정보를 훔치는 그런 해커가 아니다. 주말이나 주중에 일 끝나고 재밌어서, 궁금해서 등등 이유로 직업과 상관없이 SW, 하드웨어를 만들고 고쳐보는 그런 행동 말이다. 해커 문화의 시작은 전자공학, 컴퓨터공학을 전공하는 사람들이 아니었다. MIT의 모형 기차 동아리 (Tech model rail road club) 에서 의기투합한 새내기 몇명이 연구용 메인프레임을 뜯어보고, 운영체제를 고치고 새로 만들어보면서 해커 문화가 시작 되었다.  1975년 조그만 전자제품 회사 MITS 뒷 마당에서 큰 기대없이 만들어 $439 에 팔았던 Altair 8080라는 첫 PC가 있다 [2].

Altair 8080의 광고: 저 못생긴 것이 PC다.

이Altair가 해킹 문화를 폭발 시켰다. Altair는 운영체제, 컴파일러(프로그램 개발툴)와 같은 필수 SW도 없이 본체에 LED와 버튼 몇개 달려 있었고, 애초에 취미로 갖고 놀 장난감을 찾는 사람들을 타겟으로 했다. 싼 값에 사서 집에서 고쳐볼 수 있는 Altair의 매력에 빠진 사람들은 다양하게 이 조잡한 기계를 고쳐 보았다 (사실 SW가 없었으니, 해킹은 필수였다) . 예를 들자면:

  • 하버드 기숙사에서 빌게이츠는 수업에 안나가고 Altair에서 돌아가는 BASIC 컴파일러를 만들어 팔았다. MS의 시작이다.
  • 워즈니악과 스티브 잡스는 Altair에 관해 이야기 하는 동호회에서 처음 만나 해킹을 시작했다. 워즈니악은 곧 훨씬 더 진보된 PC인 애플1을 디자인한다. 애플의 시작이다.

1991년 핀란드 헬싱키 대학교의 21살 학부생 리누스 토발즈는 취미로 유닉스를 닮은 운영체제를 만들기 시작했다. 간신히 돌아가는 첫 버전을 완성한 후, 인터넷 메일 리스트에 자신의 프로젝트를 수줍게 광고했다:

“386/486 PC에서 돌아가는 무료 운영체제를 만들고 있어요 (취미로 그냥, GNU처럼 대단하고 전문적인 건 아니고요…) — I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. “

그 후 몇년간 리눅스는 눈부시게 발전했다 (한국에선 안타깝지만 아니다). 전 세계의 내노라하는 해커들이 몰려들어 잉여력을 과시했고 젊은 리누스 토발즈는 해킹 실력보다 더 훌륭한 해커 관리 능력 — 전 세계에서 몰려드는 소스코드의 안정성과 품질을 관리하는 능력 — 을 보였다. 대기업에서 전문적으로 관리하는 소프트웨어도 흔히 실패하는 것을 보면 리눅스의 성공은 신의 은총이라 생각들기도 한다.  지금 리눅스 없이 세상이 돌아갈 수 있을까? 구글, 페이스북, 트위터등 거의 모든 인터넷 기업은 리눅스로 운영된다. 한국이 노심초사하는 안드로이드 역시 리눅스로 돌아간다.  클라우드 컴퓨팅도 기본은 리눅스다.

3. 잉여가 해커 문화를 낳았다 
해커 문화의 근본은 잉여 (Abundance) 정신이다. 즉 시간 남으면 야근하거나, 다른 “생산성” 있는 일을 하는게 아니라 그냥 며칠 저녁, 주말 내내 돈 벌이 안되는 뻘짓 하는 것이다. 그럼 해커들은 왜 그렇게 잉여력이 폭발해서 뻘짓을 하는 걸까?

  • 재미있다. 코딩은 재미있는 창조 행위다. 직소 퍼즐을 맞추어 본 사람은 알것이다. 1000 번째 피스가 끼워졌을때의 그 성취감. 소프트웨어를 완성하는건 그림이 퍼즐에서 뛰쳐나와춤추는것 과 같다. 내 상상의 결과물이 눈앞에서 움직여 뛰는 것과 같은 그런 흥분, 성취감때문에 해커들은 코딩한다. 직장에서 10시간 코딩하고, 집에와서 재미삼아 5시간 더 코딩하는 사람들이 널려있다.
  • 선물 (gift) 정신이다. 해커들은 자신이 며칠밤 세워 만든 소스 코드를 “선물”로 동료들에게 배포한다. 취미 생활로 해킹하기 때문에 돈을 받는 것은 생각지도 않고, 혹 그런 시도를 했을 경우 커뮤니티에서 매장당한다. 내가 오늘 1,000 줄의 소스코드를 선물 했으면 내일은 누군가 또 공짜로 새로운 툴을 선물 할 것이다. 선물은 받는 것도 좋지만, 하는 것이 더 즐겁다.
  •  명성(reputation)을 얻고 싶어 한다. 돈에는 초연하지만 자신의 이름을 높이는 것에 최선을 다한다. X의 해킹 능력은 최고다 하는 평가를 얻으려, 버그 없고 훌륭하게 디자인된 소스코드를 짠다. 선물의 댓가는 해커들 사이에서 드날리는 명성이다. 지저분한 턱수염, 긴 생머리를 날리는 옆 사람을 너무 무시하지 말자. 해커 사회에서는 브레드피트 일수도 있으니까…
  • 여유로운 사회다. 미국에 10년 가까이 살아온 난 한국에 가서 며칠만 지내면 갑자기 두려움이 엄습해 온다. “내가 이렇게 쉽게 쉽게 살아도 되나? 사람들은 이렇게 열심히 일하는데… ” 그런데 미국 집으로 돌아오면 얼마 지나지 않아 곧 주말이면 골프치는 재미, 저녁이면 책 읽고 해킹 하는 재미로 근심이 사라진다. 저녁에 야근 안해도, 주말에 일 안해도 별 걱정이 없다. 사회가 여유롭게 돌아간다.

해커 정신은 사라진 전설이 아니다. 수백억의 돈을 매일 투자하는 실리콘밸리 투자자들은 지금도 새로운 아이디어를 가진 해커를 찾아다닌다. 구글, 페이스북에 취업하는 가장 쉬운 방법은 아파치 같은 오픈소스 프로젝트에서 해킹한 경력이다. 오픈소스와 해킹에 관심있는 사람은 [4]를 읽어 보시길 권한다.

4. 공포에 사로잡힌 한국
잉여와 해커 정신이 실리콘밸리의 근본이라면, 한국의 근본 정서는 무엇일까 생각해 본다. 나는 “공포(fear)” 라고 생각한다. 공부를 못하면 루저가 된다는 공포, 숙제를 안해가면 맞을거라는 공포, 소프트웨어때문에 삼성이 무너진다는 공포, 6/25 시절로 다시 돌아갈지도 모른다는 공포.

다른 사람들은 어떤지 모르겠지만, 나는 겪어보지도 않은 6/25에 대해 막연한 두려움이 있다. 언젠가 북한이 쳐들어오면 한국은 다시 리셋된다는, 실현 불가능한 그 공포가 왜 사라지지 않는지 논리로는 설명할 수 없다. 초등학교 6학년 시절 아이들을 웃겨 주려 헛소리 한번 했다가, 50명의 아이들 앞에서 뺨을 여러대 맞은 기억이 있다. 그날 이후 나는 사람들 앞에서 실수하지 않으려, 최대한 말을 아끼는 아이가 되었다. 1년 후를 기약할 수 없는 벤처에서 일하며 처자식을 먹여 살리는 내가 불안한 부모님은 삼성이 주는 안정감과 지위에 대해”엄친아”의 예제를 들어가면서 설득하신다.  도대체가 이 두려움들에서 벗어날 수 없다.

우리는 개인, 집단 모두 공포에서 벗어나려 치열하게 살고있다. 뛰어난 해킹 잠재력을 가진 얼마나 많은 사람들이 공무원과 교사 시험을 준비하고 있을까? 이건희 회장이 주기적으로 이야기하는 “삼성 최대의 위기”는 정말 언제로 오는 걸까? (SW는 정말로 위기라고 생각한다). 한국형 안드로이드라는 “성스로운 똥” 아이디어를 낸 공무원들은 한국 SW의 미래가 얼마나 두려웠을까?

5. 결론
결론적으로 공포가 지배하는 문화에서 잉여와 해커의 정신은 살아 날 수가 없다. 최근 얼마나 많은 수의 한국 해커들이 국제 오픈소스 프로젝트 (예: Apache) 에 참여하고 있는가 세어본적이 있다. 정말 몇안되는 사람들 뿐이었다. 삼성, LG는 눈부시게 아름다운 하드웨어를 만들어 파는것에 몰두한 나머지, 구글, 페이스북, 아마존을 떠 받치는 오픈소스 프로젝트들을 잊고 있는 것 같다. 아니면, 돈 받지 않고 소스코드를 선물 하는 실리콘밸리의 해커 정신을 고위 임원진 들이 이해하는것이 불가능한 것인가? 그럼 구글이 공짜로 안드로이드 커널을 배포한다고 했을때 그것은 어떻게 이해 했을까?

내가 발견한 한국 최고의 잉여 생산지는 “dcinside”다.  거기엔 잉여가 넘친다. 그리고 놀랍게 해커 정신과 많이 닮아있다. 사람들은 1) 재미있기 때문에 사진을 해킹 (합성)하고, 합성한 사진들을 2) 공짜로 서로 나누며 키득댄다. 고품질의 합성 사진을 다작한 사람들은 3) 명예의 전당에 올라 있으며, 매일 매일 쉬지않고 업데이트 되는 합성 사진과 미디어들은 얼마나 사람들이 4) 잉여 넘치는지 (여유로운지) 보여준다. 미국에는 dcinside 같은 그런 재기발랄한 미디어 해킹 사이트는 없는듯해 보인다.

e0014726_475b5941c724f

dcinsde: 재기발랄한 미디어 해킹을 보라!

그런면에서 나는 dcinside와 같이 한국에 고유하게 살아있는 해킹문화를 연구하고, 거기에서 힌트를 발견하는 것이 소프트웨어 근본을 만드는 방법이라 생각한다. 언론에서는 페이스북 창업자 츄커버그가 얼마나 부자인지를 생각해 보라며 젊은 이들을 꼬시지만, “부”는 해커의 운좋은 부산물이지 목적이 될수 없다. 정부에서는 스티브잡스같은 인재가 수만명을 먹여 살린다며 SW 엘리트 양성을 부르짖지만, 이 역시 성스러운 똥같은 생각이다. SW 엘리트는 dcinside 의 자조섞인 “잉여인” 들 중에서 몇 사람이 태어나지, 나라가 맘먹고 키워내는 게 아니다. 나는 컴퓨터 정규교육 과정을 따라 미국에서 박사학위를 받았고 다수의 논문을 썼다. 그러나 이것은, 생산성에 몰두한 나는 진정한 해커는 아니었다는 말이다. 혹 엘리트라고 칭찬받지 못해도, 잉여가운데 피어나는 한국형 해커들을 많이 만났으면 하는것이 바램이다.

— 박상민 http://twitter.com/#!/sm_park
[1] 해커 그 광기와 비밀의 기록: http://www.yes24.com/24/goods/2256?scode=032&srank=16
[2] Altair 8080: http://en.wikipedia.org/wiki/Altair_8800
[3] History of Linux http://en.wikipedia.org/wiki/History_of_Linux
[4] The Cathedral and the Bazaar http://catb.org/~esr/writings/homesteading/