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