[O2플러스/박상민의 ‘소프트’한국] ⑦ ‘버그’라는 축복

●소프트웨어에서 버그는 상수, 갑-을 관계로 풀 수 없어…
●불편함을 직접 해결하는 얼리아답터의 탄생 필요

국내 한 \'얼리어답터\'의 소지품. 국내 IT소비자란 주로 하드웨어의 소비에 머문다. 하지만 실리콘밸리의 소비자는 소프트웨어 버그까지도 개선의 대상으로 삼는다. 동아일보 DB

약 10년 전부터 필자는 얼리아답터(early adapter)였다.

새 기계와 소프트웨어로 마냥 행복할 것 같은 얼리아답터에게도 고통은 있다. 초기 제품들의 "버그(bug : 오류 및 오작동)" 때문이다.

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

그런데 3년 전 나는 색다른 경험을 했다. 아마존에서 이북리더 킨들이 나오기 전 네덜란드의 iRex라는 벤처회사에서 DR시리즈라는 이북리더를 출시했다. 당시 DR시리즈는 여러 측면으로 혁신적이었는데, 8″와 10″의 대형 스크린, 와콤 타블릿 등 세계 최초로 이북리더의 매력을 보여준 혁신적 제품이었다.

그게 너무 갖고 싶어 가난한 유학생임에도 난 8인치와 10인치 두 버전을 연이어 약 400달러, 600달러 의 돈을 주고 구입했다. 하지만 곧 얼리아답터의 고통이 비싼 가격 만큼이나 강렬하게 찾아왔다. 수없이 많은 버그들을 발견했고, 어떤 것들은 너무 치명적이었다.

설상가상으로 곧 SW를 업데이트 한다던 회사는 몇 달이 지나도 감감무소식이었다. 더 이상 참을 수 없던 필자는 회사에 항의 메일을 써보내기 시작했고 함께할 "동지"가 없는지 찾으려 인터넷DR 커뮤니티의 분위기를 살폈다.

헌데, 그곳 게시판은 이상하리만치 차분했다. 어떤 사람은 DR시리즈의 소프트웨어를 분석하며 왜 업데이트가 늦는지 설명했고 (그곳 직원이 아님에도), 어떤 사람은 DR이 오픈소스였던걸 활용해 몇 가지 버그를 고쳐서 사람들에게 배포했다. 전공이 컴퓨터요, 시간 많은 대학원생 필자는 항의 메일이나 보내고 있는데, 비전공자를 포함한 '너드'들은 직접 문제를 해결하기 시작한 것이다.

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

한 대형게임업체의 대규모 개발자 채용설명회. 최근 국내 SW인재에 대한 인식이 넓어진 것은 사실이다. 하지만 구태의연한 갑-을관계의 혁신 없이는 미래가 불투명하다. 동아일보 DB

■갑과 을, 고통스런 개발 생태계

뼛속 깊이 한국인인 내게 우리 소프트웨어 업계를 지배하는 '갑'과 '을'의 문화는 당연하게 다가온다. 얼마 전 대기업에서 일하는 선배 형이 페이스북에 남긴 메시지는, "금요일 퇴근하며 을에게 전화해 월요일까지 고칠 수 있냐고 물었다. 미안하지만 할 수 없지…." 이런 것이었다.

여기서 SW개발을 두고 벌어지는 '갑'과 '을' 가상의 시나리오를 한번 펼쳐보자.

갑: "앵그리 피그"라는 게임을 개발하려는데, 누가 해볼래?
을: 제가 할 수 있습니다. 맡겨 주십쇼!
갑: 기한은 일주일. 오케이?
을: [월-화요일: 디자인] 바쁘다 바빠, 어떤 게임 알고리즘을 쓸까? [수-금요일: 구현] 게임 캐릭터는 피그니까 귀여운 돼지 캐릭터를 입히자!
갑: [금요일 오후] 아 생각해보니 강아지가 귀여울 것 같은데 "앵그리 도그"로 바꿀 수 있지?
을: 그런 얘기 안 하셨잖아요…(울상)
갑: 그랬나?…이런 미안 허헛… 월요일날 봐~
을: [토-일요일] 출근하며 휴대폰 주소록 갑의 이름을 멍멍이 녀석으로 바꿈.

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

위 사례에서 몇 가지만 수정하면 깔끔한 '갑'과 '을'의 관계를 만들 수 있다. 즉, '갑'이 월요일 정확한 스펙(앵그리 도그)을 넘겼다거나, 금요일 스펙을 변경하면서 일주일의 기한을 더 주었다면 '을'은 마음편히 주말을 보냈을 것이고, '갑'도 '을' 보기에 미안하지 않았을 것이다.

SW 계약 시에 '갑'은 정확하게 스펙을 던져주고, 프로그래밍 실력이 출중한 '을'은 스펙의 기능을 버그 없이, 기한 안에 완성해 낸다면, 이게 진짜 소프트웨어 유토피아 아니겠는가? 그런데 문제는, 두 사례 모두 소프트웨어 망국으로 향하는 길이라는 사실이다!

■ 버그에서 혁신이 나온다

위의 얼리아답터 사례에 비춰보았을 때 나는 '갑'이었고, DR을 판 회사는 '을'이었다. 나는 당연히 '갑'의 마인드로 스펙과 기한을 못 맞춘 '을'에게 분노하고 이메일에 고소를 운운했다. 그런데, 커뮤니티의 다른 '갑'들은 태도가 달랐다. 끈기 있게 업데이트를 기다려주거나, 스스로 버그를 고쳐나가기 시작한 것이다.

그 당시 이해되지 않았던 그 현상의 의미를, 지금 미국판 '을'이 되고 나서야 깨달았다. 우리 회사의 소프트웨어(eucalyptus)는 약 60만 줄의 복잡도 만큼이나 버그가 많다. 며칠간은 잘 작동하다가도, 갑자기 어이없는 버그가 출현해 우리를 당황시키곤 한다. 그때마다 한국적 '을'의 마인드를 가지고 있는 나는 마치 내가 큰 실수 한 듯 미안해하며 급히 고치겠다고 사과한다.

하지만 내게 더 당황스러운 것은, 별일 아니라고 하며 쉽게 넘어가주는, 심지어 스스로 우리 소스코드를 고쳐 다시 우리에게 제공해주는 해커 '갑' 들의 모습, 그리고 그들의 회사들이다. 우리에게 돈을 지불한 그들이 우리 제품을 고쳐서 사용하고 결과물을 다시 우리에게 돌려주는 것이다!

이것이 바로 실리콘밸리에서 일어나는 버그를 통한 혁신이라고 생각한다. 오픈소스 프로젝트의 바이블인 'Cathedral and the bazaar'에서 설명하듯이 새로운 소프트웨어(SW) 프로젝트의 시작은 기존의 유사한 SW가 가지고 있는 버그나 결함에서 출발한다.

SW를 사용하면서 불편함을 느낄 때 혹은 새 요구조건을 기존 SW가 충족시키지 못할 때 자연스럽게 창조의 욕구가 생겨나고 이는 곧 혁신적인 다음 세대 SW의 출현으로 이어진다. 그래서 오늘 '갑'(사용자)의 자리에서 불편함을 느끼며 SW를 사용하는 사람이 내일 '을'(개발자)의 모습으로 변해 새롭게 SW를 써내려가는 것이다. 그리고 종종 이 불편함에서 출발한 아이디어가 전 세계를 강타하는 초대형 SW로 탄생하는 것이다.

Minix 라는 유명 O/S를 즐겨 사용하던 리누스 토발즈는 모뎀 기능이 없다는 사소한 불편함 때문에 새로이 리눅스를 만들었다. SW업계의 '쾌남' 래리 엘리슨 역시 메인프레임 데이터베이스의 불편함에 착안해 오라클을 시작했다.

불편함을 감수하는 얼리아답터는 개인에게만 해당되는 것이 아니다. 스타트업에게 바이블중 하나인 "캐즘 극복하기(Crossing the chasm)"을 보면 실리콘밸리 기업들이 얼마나 조직적으로 이 불편함을 감수하는지 알 수 있다.

기업들은 새로운 기술을 선보인 작은 회사들 SW를 전략적으로 구입하고, 그 기업이 성장하기까지의 과정을 유심히 지켜본다. 그들은 SW를 사가면서 완벽함을 기대하지 않는다. 새롭게 시작하는 회사의 비전을 믿어주고, 비전이 성공했을 경우 자신들에게 돌아오는 혁신에 투자하는 것이다.

우리 회사는 작은 규모지만, 고객 가운데 대기업들이 많다. 그리고 그 기업들의 엔지니어들은 꾸준히 자신이 고친 우리 소스코드를 우리에게 피드백한다. 대기업은 스타트업의 제품을 사서 스타트업의 생명을 이어가게 하고, 버그를 통해 스타트업의 혁신을 수혈 받는 것이다.

리눅스의 창시자 리누스 토발즈(오른쪽). 그는 Minix 라는 O/S를 사용도중 모뎀 기능을 추가하기 위해 직접 리눅스를 만들었다.

■ 버그는 고통 아냐! 함께 풀어야할 공동의 과제다!

우리에게 문제는 "버그(과정) = 고통" 이라는 등식이다. 깔끔한 솔루션을 원하는 '갑'에게 있어 버그는 '을'의 계약 위반이고, '을'이 어떻게든 해결해야 하는 그들의 "고통"이다. '을'에게 있어 버그는 SW 배달 전 모조리 잡아야 할 치욕이다. '갑'이 버그를 발견했을 때 받을 더 큰 서러움을 피하기 위해서는 기한 전에 고통을 감수하는 게 낫다.

버그 없는 SW는 존재하지 않기 때문에 하나하나 잡아내는 버그는 SW의 진화 과정 그 자체다. '갑'에게도 '을'에게도 이 과정은 피하고 싶은 고통일 뿐이다. 우리에겐 깔끔한 결과가 가장 달콤하다. 그리고 그 달콤함에 탐닉하는 동안 SW산업은 서서히 경쟁력을 잃어가는 것이다.

그래서 SW의 참 경쟁력은 버그를 해결해가는 과정과 거기에 참여한 개인, 기업들의 시너지에 있다. 실리콘밸리의 해커와 기업들은 그 과정을 기꺼이 즐긴다. 각자 짠 코드의 버그를 발견할 때마다 한번씩 그 뉘앙스에 웃어주고, 누가 먼저 할 것 없이 고쳐나간다. 하지만 뼛속까지 한국인인 나를 돌아볼 때 너무나 자주, 결과의 깔끔함에 집착하고 과정을 즐기지 못하는, 달리 표현하면 높은 "생산성"에만 몰두하는 자신을 발견한다.

필자와 미국 동료들이 일의 과정을 대하는 다른 자세, 그 이유는 무엇일까 많이 궁금하다. 어쩌면 새마을 시절부터 "지금 삽질은 힘들지만, 훗날 떵떵거리고 살 수 있다" 는 건설정신이 남아있기 때문일까?

그런데, 지금 많이 넉넉해진 우리는 왜 여전히 불안하고 고통스러워하는 건지… 초중고교 시절을 이어온 주입식 교육, "배움은 고통이고, 극복하면 밝은 미래," 이 여전히 뇌신경 줄기마다 박혀있어서 그런 것인지도 모르겠다. 오랫동안 유토피아를 갈망해온 우리에게 진짜 유토피아는 우리가 지나오던 그 길이 아니었을까? 소프트웨어의 축복이 버그에 있듯이….

"It is better to travel hopefully than to arrive(목표를 향해 희망차게 나아가는 것이 목표를 이루는 것보다 더 행복할 수 있다). - R. L. Stevenson"

박상민 twitter : @sm_park