천국과 지옥을 오가는 실존 프로젝트 여정을 낱낱이 기록한 소프트웨어 개발 전기(傳記)

비즈니스위크, 하버드 매거진, 시카고 트리뷴이 격찬한 책!
누구도 이야기하지 않았던 소프트웨어 개발의 은밀한 진실과 오해

프로그래머는 물론 IT 분야에 관심 있는 사람이라면 누구든 꼭 한번 읽어야 할 필독서

소프트웨어 개발은 왜 그토록 어려운 걸까? 버그 없는 소프트웨어 개발이란 과연 가능한 일일까? 누구도 풀지 못한 이 질문에 대한 답을 구하고자 저자 스콧 로젠버그는 마이크로소프트 아웃룩의 독점에 도전장을 낸 챈들러라는 야심 찬 개인정보관리 소프트웨어 개발 프로젝트를 3년 동안 추적했다. 이 책에서는 추상적인 코드와 예측하기 어려운 프로그래머들의 행동과 씨름하면서 이들이 맞닥뜨리는 모험과 퍼즐 속으로 우리를 끌어들인다. 해답을 구할 수 있을까? 소프트웨어 기술의 성배를 찾아 나서는 진지하고도 즐거운 여정에 함께 빠져보자.


[ 추천의 글 ]

소프트웨어는 인류에게 축복인 동시에 골칫거리다. 이 책은 실존한 소프트웨어 개발 프로젝트의 내밀한 속내를 들여다보는 매혹적이고도 절망적인 여정이다. 저자는 소프트웨어 프로그래머들을 산 비탈에서 끊임없이 거대한 바위를 밀어 올리는 형벌을 받은 그리스 영웅 시시포스에 비유한다. 이러한 비유가 얼마나 그럴싸한지 모르겠지만, 저자는 소프트웨어를 만드는 일이 헛된 시도라고는 생각하지 않는다. 그들에겐 즐거움과 희망이 있고 끝이 보이지 않을 것 같던 소프트웨어도 결국은 세상의 빛을 보게 된다. 먼 훗날 챈들러의 최종 버전도 발표될 테니.

비전은 웅대했으나 세세하고 구체적인 요소들은 너무 적었기에, 프로젝트를 지탱하는 바퀴는 계속 헛돌고 있었다. 챈들러 프로젝트가 단시간에 하나의 성과물을 내놓는 데는 실패했을지 모르겠으나, 우리는 개발 프로젝트를 생생하게 역사로 기록한 기념비적인 책을 읽을 수 있게 됐으니 한편으로는 성공적이었다고 말할 날이 올지도 모르겠다. 소프트웨어 산업을 다루는 모든 저자 중에 스콧 로젠버그는 단연 최고다.

『드리밍 인 코드』는 트레이시 키더가 쓴 『The Soul of a New Machine』의 진정한 후속편이라고 할 수 있으며 몇 년 간 접하지 못했던 기술적 전문성과 이야기 화법이 결합되어 있다. 천재 소프트웨어 개발자들이 실제로 무슨 일을 하는지 궁금하다면 이 책을 읽어라.

기술자들은 해결하기 복잡한 문제를 ‘사소하지 않다’고 말한다. 스콧 로젠버그는 정말로 ‘사소하지 않은’ 주제를 선택해 재미있게 풀어냈다. 저자는 코드를 작성하는 사람들에 대한 동경을 솔직하게 표현하지만, 동시에 그들도 우리처럼 복잡하고 결점이 많은 존재라는 사실을 여실히 보여준다. 『드리밍 인 코드』는 진정한, 우리 시대의 소프트웨어 개발 보고서다.

『드리밍 인 코드』는 프로그래밍에 대한 매혹적이면서도 냉철한 탐험이다. 수려한 문체를 뽐내는 이 책은 프로그래머나 비프로그래머 모두에게 창의성과 혁신의 근원이 무엇인지를 보여줄 것이다.

스콧 로젠버그는 그 동안 어떤 프로그래머도 다룰 용기조차 내지 못했던 주제를 용감하게 다뤘다. 이 책은 인간의 창의성을 코드로 변환하고자 몸부림치는 혼란스런 소용돌이에 관해 다룬다. 저자는 소프트웨어 역사 이래 우리가 이론적으로 설명하려 끊임없이 시도해온 개발 프로세스를 소프트웨어 벤처기업의 실화와 맛깔나게 버무려 눈부신 이야기로 빚어냈다.

『드리밍 인 코드』에는 진지한 드라마와 유쾌한 코미디, 그리고 애절함과 통렬함, 모든 감정이 녹아 있다. 이야기의 한가운데에는 디지털 혁명에서 가장 매혹적이면서도 제대로 이해 받지 못한 인물인 미치 케이퍼가 있다. 이 책은 소프트웨어 개발을 다룬 어떤 책보다도 재기가 넘치며 수많은 통찰력을 제공한다.


[ 출판사 서평 ]

소프트웨어는 현대 사회의 핵심 인프라를 책임지고 있지만, 그 개발 과정은 여전히 연금술의 수준에 머물러 있다. 게다가 계획이 거창하면 거창할수록 소프트웨어 개발 프로젝트는 그만큼 더 극적으로 실패하는 듯하다.

우리는 대규모 소프트웨어 개발 프로젝트가 중도에 와르르 무너지는 일을 끊임없이 봐왔다. FBI(미 정보국), IRS(미 국세청), 펜타곤(미 국방부), FAA(미 항공청)에, 아니 규모가 어느 정도 되는 아무 기업에나 물어보라. 대형 시스템뿐만 아니라 우리의 데스크탑 컴퓨터에서 돌아가는 소프트웨어 역시 문제는 많다. 마이크로소프트의 윈도우 비스타는 당초 계획보다 개발일정이 수년 이상 늦어졌는데도 여전히 버그투성이다. 인류 역사상 이처럼 신뢰도 낮은 기술에 인류 전체가 이만큼 폭넓게 의존한 적은 없었다.

우리 의지대로 컴퓨터를 활용하는 일이 왜 이처럼 어려운 것일까? 완벽한 프로그램을 만드는 일은 교량을 건설하는 과정과 비슷할까, 아니면 영화를 제작하는 일과 비슷할까? 왜 소프트웨어 개발 과정은 마치 시간의 흐름을 완전히 멈춰버리는 듯한 현상을 일으키는 걸까? 버그 없는 소프트웨어 개발이란 과연 가능한 일일까?

이들 질문에 답하고자 스콧 로젠버그는 마이크로소프트 아웃룩의 독점에 도전장을 낸 챈들러라는 야심 찬 개인정보관리(PIM) 소프트웨어 개발 프로젝트를 3년 동안 추적했다. 챈들러 프로젝트는 로터스 1-2-3의 창시자인 미치 케이퍼가 이끌었다. 프로젝트의 목표는 완전히 새로운 소프트웨어를 만드는 것이었다. 이 애플리케이션은 이메일, 일정, 노트 등을 손쉽게 다른 아이템으로 전환하고 사용자가 원하는 방식으로 관리하고 표시할 수 있는 기능까지 제공해야 했다.

챈들러팀에는 초기 맥 OS 운영체제의 개발자인 앤디 허츠펠드와, 넷스케이프의 공동 창업자이자 웹 브라우저 쿠키를 발명한 루 몬툴리 등 전설적인 개발자들이 여럿 포함되어 있었다. 챈들러팀의 첫 프로젝트 관리자를 맡은 마이클 토이는 신속한 릴리스를 원했지만 이내 소프트웨어 시간의 늪에 빠져 허우적거리게 되었다. 두 번째 관리자 케이티 팰런은 머리는 뛰어나지만 고집이 세기로 유명한 프로그래머 집단을 단호하게 이끌었다. 프로그래머 팀 중에는 종종 지독한 버그를 고치는 일에 몰입하던 사색적인 프로그래머 존 앤더슨과, 고등학교 시절 학교의 미니 컴퓨터를 분해했다가 거기서 자신의 미래를 발견했던 데이터베이스 전문가 앤디 바이다 등도 있었다.

로젠버그의 이야기는 추상적인 코드와 예측하기 어려운 사람들의 행동(특히 그들 자신의)과 씨름하면서 이들이 맞닥뜨리는 모험과 퍼즐 속으로 우리를 끌어들인다. 이 기나긴 여정에서 우리는 블랙홀, 거북이, 뱀, 용, 도끼, 야생소 등을 만나게 되고 소프트웨어 개발 역사에 등장했던 각종 이론과 방법론을 접하게 된다. 이와 함께, 널리 알려진 개념인 ‘맨먼스 미신(Mythical Man-Month)’부터 최근에 유행하는 ‘익스트림 프로그래밍(XP)’까지 등장한다.

기술에 관심이 많은 이들뿐만 아니라 발명의 드라마에 매력을 느끼는 사람이라면 누구라도 『드리밍 인 코드』를 통해 정보화 시대와 인간 정신에 대한 지혜와 성찰을 얻게 될 것이다.


[ 책 속으로 ]

(몬티 파이썬의 형식을 깨뜨리는 허무주의에 열광하는 팬들 중에는 컴퓨터 프로그래머들도 적지 않았다. 광고성 이메일을 가리키는 ‘스팸’이라는 표현도 몬티 파이썬에 나오는 식당 메뉴인 ‘계란, 소세지, 스팸, 스팸, 스팸, 스팸뿐!’에서 유래됐다) -3장 92P

펄이 다른 무엇보다도 표현의 자유를 가장 중요시하는 언어라는 것은 어쩌면 당연한 일이다. 펄의 슬로건은 “무슨 작업을 하든 한 가지 이상의 방법이 있다(There’s more than one way to do it)”이지 않은가! (약어를 좋아하는 프로그래머들은, 여기에 하나의 추상층을 더해 이를 TMTOWTDI(‘팀토우디’라고 발음한다)라고 부르기도 한다.) -3장 93P

‘세상을 바꾸자’는 말은 애플의 스티브 잡스가 펩시 CEO인 존 스컬리를 스카우트할 때 사용한 이후로 실리콘 밸리에서 유행이 식지 않는 표현이었다. 스티브 잡스는 존 스컬리에게 “평생 설탕물만 파실 겁니까? 아니면 저와 함께 컴퓨터로 세상을 바꾸시겠습니까?”라고 물었다고 알려져 있다. -2장 48P

2004년 비즈니스위크 지와의 인터뷰에서 리누스 토발즈는 “과학은 사람들이 서로 결과를 공유하고 그 위에 새로운 것을 쌓아가는 방식으로 발전합니다. 반면에 마술의 경우에는 누군가 작은 비밀을 소유하곤 다른 누구에게도 이를 알려주지 않죠. 기존의 소프트웨어 개발은 마술에 가까웠습니다. 마술은 이제 사라지다시피 했죠. 소프트웨어에서도 비슷한 일이 일어날 것입니다. 난해한 문제를 해결하기 위해서는 개인이나 일개 회사가 그들만의 비밀을 가지는 방식으로는 한계가 있습니다. 우리 모두가 함께 지식을 공유해야만 합니다.” -2장 57P

“연구의 결과물은 지능 개선 시스템을 연구하고 개발하는 과정의 프로그래밍 작업을 좀더 효율적으로 만드는 데 사용될 것이다. 컴퓨터 프로그램을 설계, 구현, 변경하는 능력은 연구가 성과를 내는 속도에 큰 영향을 미칠 것이다.” 다시 말해서 만약 NLS가 프로그래밍 작업 자체에 도움이 된다면 결과적으로 그들이 NLS를 개선하는 속도를 더 빠르게 만들 것이다. 즉 ‘재귀적 선순환 효과’가 발생하는 것이다. 잉글바트는 이를 ‘부트스트래핑(bootstrapping)’이라고 불렀다. -2장 62P

컴퓨터 공학자인 자론 레이니어는 젊은 시절의 잉글바트가 인공지능의 아버지라 불리는 MIT의 마빈 민스키(Marvin Minsky) 교수를 처음 만났을 때를 다음과 같이 기억한다. 인공지능이 컴퓨터에 위대한 이성의 힘을 부여하게될 것이라는 민스키 교수의 장황한 설명을 들은 잉글바트는 바로 이렇게 대꾸했다. “컴퓨터를 위해 그 많은 일을 할 예정이시군요. 근데 사람들을 위해서는 어떤 일을 해주실 건가요?" -2장 65P

오늘날 대규모 소프트웨어 개발 프로젝트를 시작하는 사람들은 이처럼 맥 빠지는 과거를 잊어서는 안 된다. 소프트웨어의 역사는 우리에게 이런 질문을 던지기 때문이다. “왜 당신은 다를 거라고 생각합니까?” -2장 66P

어떤 작업은 특정 선행 작업이 완료되기 전에는 시작하는 것조차 불가능하다. 이는 아무리 많은 인원이 개발에 투입돼도 달라지지 않는다. “임신부가 아이를 낳기까지는 9개월의 시간이 걸린다. 몇 명의 여자가 동원되는지는 중요하지 않다.” -1장 31P

프로그래밍 분야에서 가장 권위 있는 책의 저자인 도널드 커누스는 “소프트웨어 개발은 어렵다”5고 말했다. 하지만 도대체 왜 그래야만 한다는 말인가? -0장 17P

앤더슨의 “딱 맞는 솔루션을 찾았다”는 주장과 토틱의 “우리가 새로 개발하는 편이 낫다”는 주장은 소프트웨어 재사용에 있어 전형적인 딜레마였다. 자체적으로 개발할 것인가, 기존 것을 빌려다 쓸 것인가? 모든 소프트웨어 프로젝트는 어느 순간 이러한 갈림길 앞에 서게 된다. -4장 117P

“실제로 시도해본 결과, 쓸모있고, 재사용에 성공적이며, 프로그래머들이 쉽게 이해해 활용할 수 있고, 지속적으로 쏟아져 나오는 하드웨어 플랫폼에 쉽게 이식되며, 기능 업데이트가 기존 코드와 충돌이 나지 않은 컴포넌트를 개발해서, 모든 것을 자체적으로 개발하려는 문화를 가진 시장에서 판매하는 것은 불가능할 정도로 어려운 일이었다.” -4장 121P

“만약 무엇을 찾다가 2분 27초가 넘게 걸린다면 보통의 프로그래머는 찾으려던 게 존재하지 않는다고 결론을 내리고 바로 새 개발에 들어갈 것입니다.” -4장 125P

소프트웨어 산업에는 수십 년째 ‘카우보이 개발자(Cowboy Coder)’란 표현이 쓰이고 있었다. 카우보이 개발자는 규칙을 따르는 것을 거부하고, 혼자 작업하기를 선호하며, 항상 최신 기술을 사용하는 걸 좋아한다. 관리자에게 카우보이 개발자는 악몽과도 같지만, 프로그래머들은 그를 영웅시한다. -4장 138P

[ 저자의 말 ]

서점의 프로그래밍 코너에 가면 소프트웨어 개발자들을 위한 ‘하우투(how-to)’ 책들이 잔뜩 꽂혀 있다. 이 책은 그와 같은 길잡이나 완벽 가이드 류의 책은 절대 아니다. 나는 굳이 따지자면 초보 프로그래머에 불과하다. 그런 내가 전문가들을 가르쳐보겠다고 나서는 건 어불성설이다. 그리고 만약 내가 이 리서치를 통해 소프트웨어 개발에서 새로운 혁신이나 비법을 발견했다면 나는 책을 쓰기보다는 투자가를 찾아갔을 것이다.

프로그래머들은 물론 이 책을 재미있게 읽으리라 생각하지만, 사실 이 책은 비프로그래머들을 위해 썼다. 이 책은 의문을 하나 던지고 이야기를 풀어나간다. 좋은 소프트웨어를 만드는 일은 왜 그토록 어려운 걸까? 21세기 초반인 지금, 이미 컴퓨터 시대가 시작된 지 50년이 흘렀건만, 누구도 이에 대해 확실한 답을 제시하지 못하고 있다. 그래서 나는 실제로 한 소프트웨어 프로젝트가 진행됐던 과정을 독자 여러분께 들려주고자 한다.

이 이야기는 한 팀의 사람들이 코드의 바위 덩어리를 어깨에 이고 힘들게 언덕을 올라가는 과정에 관한 이야기다. 그들은 장애물(과거부터 있었던, 그리고 또 새로운)에 걸려 넘어지면서도 실제로 유용하고 오래 지속될 무언가를 만들고자 하는 노력을 계속해왔다.


[ 저자 소개 ]

스콧 로젠버그 www.wordyard.com
살롱닷컴(Salon.com)을 공동으로 창업한 후 기술 편집장과 총 편집장을 차례로 역임했으며 현재는 신규 사업 담당 부사장이다. 살롱닷컴을 창업하기 이전에 ‘샌프란시스코 이그재미너(San Francisco Examiner)’에 연극, 영화, 테크놀러지에 관해 기고해왔으며 그의 리뷰는 ‘조지 진 네이던 어워드George Jean Nathan Award’를 받기도 했다. 스콧의 글은 뉴욕타임스, 와이어드 등 여러 신문/잡지에 실렸다. 지금은 캘리포니아의 버클리시에서 부인과 두 아들과 함께 살고 있다. 홈페이지는 http://www.wordyard.com이며, 이 책에 대한 더 많은 정보는 http://www.dreamingincode.com에서 찾아볼 수 있다.


[ 옮긴이의 말 ]

“소프트웨어를 만드는 일은 어렵다. 그런데 왜 그토록 어려운 것일까?”

저명한 저널리스트인 동시에 아마추어 프로그래머이기도 한 스콧 로젠버그는 소프트웨어 업계에서 수수께끼처럼 여겨지는 이 물음에 대한 해답을 찾기 위해, 직접 소프트웨어 개발 프로젝트 일선에 뛰어들었다. 프로그래머가 아닌 관조적인 입장에서 소프트웨어 개발 과정을 상세히 기록하는 사서(史書)로서 참여했던 것이다. 그리고 2003년부터 2005년까지 챈들러라는 이름의 소프트웨어 개발 프로젝트 안에서 꼬박 3년의 시간을 보낸다.

챈들러는 로터스 1-2-3의 창시자이자 모질라 재단 회장인 미치 케이퍼가 궁극의 개인정보관리 소프트웨어를 만들려는 포부를 품고 2001년 초에 시작한 오픈소스 프로젝트다. 소프트웨어 업계의 전설인 케이퍼를 필두로 수많은 천재 프로그래머가 참여한 챈들러 프로젝트는 시작한 후 7년을 넘기고 8백만 달러의 비용을 지출한 2008년 8월이 되어서야 버전 1.0을 발표한다.

챈들러의 완성을 간절히 기다렸던 스콧은 2005년 여전히 소프트웨어 시간의 블랙홀에서 헤어나오지 못하는 프로젝트에서 발을 빼게 된다. 이 책은 스콧이 프로젝트와 함께한 3년의 시간 동안, 챈들러라는 ‘드라마’에서 수십 명의 등장인물들이 벌인 사투를 통해 ‘소프트웨어 개발의 오해와 진실’을 풀어내고 있다. 독자는 그의 이야기를 통해 소프트웨어 개발을 어렵게 만드는 그 ‘무엇’의 본질을 발견하게 될 것이다.

이 책의 주인공은 저자 스콧 로젠버그도, 챈들러 프로젝트를 이끈 미치 케이퍼도 아니다. 오늘도 여전히 코드 속에서 꿈을 꾸는 수많은 프로그래머, 소프트웨어 시간의 늪에서 허우적거리며 천국 같은 희열과 끝없는 나락을 경험하는 당신과 나의 이야기다.


[ 옮긴이 소개 ]

황대산
2002년 예일대학교 수학과를 최우수 졸업하고 6년의 프로그래밍 경력을 쌓은 후, 웹 애플리케이션 개발/운영 전문회사인 페퍼코드(http://peppercode.com)를 설립했다. 루비 프로그래밍 언어의 솔라리스 릴리스 관리자를 맡고 있으며, ‘IBM 디벨로퍼 웍스’, ‘마이크로 소프트웨어’ 등에 정기적으로 기고해왔다. 기술과 사회에 관한 대화를 즐기며, 자신의 소소한 생각을 담은 개인 블로그 ‘Trace Forward’(http://blog.daesan.com)를 운영하고 있다. 저서로 『웹 개발 2.0 루비 온 레일스』(에이콘출판, 2007)가 있다.

목차

• 00장 소프트웨어 시간 ● 13
  • [1975년-2000년]
    
• 01장 불길한 시작 ● 25
  • [2003년 7월]
    
• 02장 어젠다의 비전 ● 49
  • [1968년-2001년]
    
• 03장 프로토타입과 파이썬 ● 77
  • [2001년-2002년 11월]
    
• 04장 레고 가설 ● 109
  • [2002년 11월-2003년 8월]
    
• 05장 개와 긱 관리하기 ● 147
  • [2003년 4월-8월]
    
• 06장 끝도 없는 일 깔끔하게 해치우기 ● 179
  • [2003년 7월-11월]
    
• 07장 디테일 뷰 ● 213
  • [2004년 1월-5월]
    
• 08장 화이트보드의 포스트잇 ● 253
  • [2004년 6월-10월]
    
• 09장 개발 방법론 ● 285
  
• 10장 공학자와 예술가 ● 325
  
• 11장 개밥 먹기로 가는 길 ● 371
  • [2004년 11월-2005년 11월]
    
• 에필로그 미래를 건 내기 ● 411
  • [2005년-2029년, 그 후]
    

[ p96 4행 ]
변수 타입에 있어 아도 → 변수 타입에 있어

[ p216 아래에서 5행 ]
SWIF(Simplified Wrapper and Interface Generator)를 → SWIG(Simplified Wrapper and Interface Generator)을

[ p423 두 번째 문단 1행 ]
표지의 부제에 나오는 → 원서 표지의 부제(Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software)에 나오는

[ p424 ]
Chapter 01 파멸 → Chapter 01 불길한 시작

[ p433 ]
Chapter 07 자세히 보기 → Chapter 07 디테일 뷰