버그의 축복

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

21 thoughts on “버그의 축복

  1. 아마 그래서 우리는 잡스와 같은 혁신가를 만들어내지 못하나 봅니다!
    갑과 을의 관계도 재정립해야지만, 근본적인 건 교육이라는 기초공사가 바뀌지 않으면 요원한 현상일 것 같습니다!

  2. 정말 우리나라는 실수 할수도 있는거고 고치는데 시간이 걸릴수도 있는건데 그걸 아무리 자세히 설명하고 용서를 구해도 무조건 니탓! 그러면서 죽일듯이 달려들고 에초에 명확한 틀조차 제공 안하고 이거만들어! 해놓고 내가 말한거랑 다르잖아! 라는 어이없는 일들의 연속 ……
    지금은 아이폰을 쓰지만 안드로이드 기기를 쓰면서 소프트 적인 버그를 고치기 위해 펌웨어를 풀었다 씌웠다 반복하면서 아 이게 생각만큼 쉬운 일이 아니구나 코드 넣는것도 아니고 펙킹만 풀어서 기능만 고치는 건데도 생각보다 훨씬 어렵더라구요 ㅎㅎ
    일을 대하는 유연한 자세라 저부터라도 마음에 세기고 주위를 바꿔가야겠지요.
    여담이지만 클리앙을 아시면 파코즈도 아시겠지요? 전 주로 파코즈에서 정보를 얻습니다 ㅋ

    • 그렇죠.. 좀 용서나 이해하는 문화가 아쉽습니다. 파코즈 명성은 익히 아는데 전 클리앙이 눈에 익어서 그런지 그곳만 가게 되네요..

  3. 안녕하세요. 좋은 글 잘 읽었습니다.
    “우리는 왜 버그를 수정해나가는 과정을 즐기지 못하고 결과의 깔끔함에만 집착할까” 질문으로부터 “공포”에 대해 쓰신 지난번 글이 떠올라서 댓글을 남깁니다.
    일정을 맞추지 못하면 어쩌나, 출시된 제품에서 결함이 발생하면 AS 비용은 어쩌나, 이러한 “공포”가 지배하는 우리의 일터에서 버그를 즐기기란 쉽지 않을것 같습니다…

    개인의 노력으로 충분한 내공을 갖추어서 어지간한 요구사항에도 대응할 수 있는 슈퍼맨이 되면 “공포”를 극복할 수 있을까요? 공포에 떨며 살지 않아도 생존이 위협받지 않을 정도로 우리 사회가 성숙하려면 어떻게…. 에고, 너무 어려운 문제입니다^^

    • 음 전 개인의 실력보단 공동체로서 갑과 을, 즉 소프트웨어 생산자 소비자가 소프트웨어를 즐긴다는 생각이 많아졌음 좋겠습니다. 꼭 돈과 연결되지 않더라도 좋은 소프트웨어는 충분히 즐길거리가 되니까요..그 시너지속에 대작이 나오겠죠…:-)염

  4. 여유의 차이 아닌가 하는 생각이 듭니다. 프로젝트 한창일 때 할일이 산더미 같은데 휴가 다녀올 건 다 다녀오고, 일이 아무리 바빠도 가족들이랑 보낼 시간은 꼭 짜내고, 꼭 직장에서 뿐만 아니라 그냥 밖에서 접하게 되는 미국인들을 봐도 대체적으로 여유가 배어 있는 느낌이 들더라구요. 일 열심히 할 땐 하고 놀 땐 놀고…

  5. 이젠 고인이 된 스티브 잡스의 말이 생각나네요.
    “우리가 이룬 것만큼 이루지 못한 것도 자랑스럽습니다.
    내가 계속할 수 있었던 유일한 이유는 내가 하는 일을 사랑했기 때문이라 확신합니다”

    우리나라에선 버그를 정말 벌래 쳐다보듯 하는 갑의 인식과
    돈을 줬으니 시킨일은 당연히 해야한다는 생각이 만연해 있는것 같네요.

    아마도 우리 조상들의 “밥값은 해야” 한다는 인식이 갑의 머리에는
    단단히 들어있는것 같네요 ^^;

    • “밥값은 해야” –> 저도 동감입니다. 주변인이 노는것을 참지못하는 그런 면이 분명있는것 같네요..저만 봐도 그래요.

  6. 순수 sw업계는 아닌 h/w적인 내용이 좀더 강한 업종에 있는데요..
    저도, 지난번 글도 이번글도 끄덕이는 부분 많았답니다..

    수년의 경험을 해보니 요런 변경예상 되는 갑이 언급하지 않은 요구사항들,
    미리미리 쳐내버리는 습관이 배어들어 있는 절 발견하곤합니다.. ^^;;

    공감가는 좋은글 잘읽엇습니다… ~

  7. 참 많은 생각을 하게 하는 좋은 글입니다. 소프트웨어를 만들고 있는 입장에서 기준은 늘 갑의 눈이었는데… 스스로를 되돌아가 보게 합니다. 갑의 모습에서 제 자신을 발견하면, 참기 힘들어 하곤 합니다. 다음번에는 실시콘밸리와 비교했을 때 한국인의 장점은 뭔지도 한번 소개해주면 좋겠어요. 이미 소개됐나요? ^^

  8. 핑백: 물통

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중