추가 적립 안내

천국과 지옥을 오가는 실존 프로젝트 여정을 낱낱이 기록한 소프트웨어 개발 전기(傳記)
비즈니스위크, 하버드 매거진, 시카고 트리뷴이 격찬한 책!
누구도 이야기하지 않았던 소프트웨어 개발의 은밀한 진실과 오해

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

소프트웨어는 현대 사회의 핵심 인프라를 책임지고 있지만, 그 개발 과정은 여전히 연금술의 수준에 머물러 있다. 게다가 계획이 거창하면 거창할수록 소프트웨어 개발 프로젝트는 그만큼 더 극적으로 실패하는 듯하다.
우리는 대규모 소프트웨어 개발 프로젝트가 중도에 와르르 무너지는 일을 끊임없이 봐왔다. FBI(미 정보국), IRS(미 국세청), 펜타곤(미 국방부), FAA(미 항공청)에, 아니 규모가 어느 정도 되는 아무 기업에나 물어보라. 대형 시스템뿐만 아니라 우리의 데스크탑 컴퓨터에서 돌아가는 소프트웨어 역시 문제는 많다. 마이크로소프트의 윈도우 비스타는 당초 계획보다 개발일정이 수년 이상 늦어졌는데도 여전히 버그투성이다. 인류 역사상 이처럼 신뢰도 낮은 기술에 인류 전체가 이만큼 폭넓게 의존한 적은 없었다.
우리 의지대로 컴퓨터를 활용하는 일이 왜 이처럼 어려운 것일까? 완벽한 프로그램을 만드는 일은 교량을 건설하는 과정과 비슷할까, 아니면 영화를 제작하는 일과 비슷할까? 왜 소프트웨어 개발 과정은 마치 시간의 흐름을 완전히 멈춰버리는 듯한 현상을 일으키는 걸까? 버그 없는 소프트웨어 개발이란 과연 가능한 일일까?
이들 질문에 답하고자 스콧 로젠버그는 마이크로소프트 아웃룩의 독점에 도전장을 낸 챈들러라는 야심 찬 개인정보관리(PIM) 소프트웨어 개발 프로젝트를 3년 동안 추적했다. 챈들러 프로젝트는 로터스 1-2-3의 창시자인 미치 케이퍼가 이끌었다. 프로젝트의 목표는 완전히 새로운 소프트웨어를 만드는 것이었다. 이 애플리케이션은 이메일, 일정, 노트 등을 손쉽게 다른 아이템으로 전환하고 사용자가 원하는 방식으로 관리하고 표시할 수 있는 기능까지 제공해야 했다.
챈들러팀에는 초기 맥 OS 운영체제의 개발자인 앤디 허츠펠드와, 넷스케이프의 공동 창업자이자 웹 브라우저 쿠키를 발명한 루 몬툴리 등 전설적인 개발자들이 여럿 포함되어 있었다. 챈들러팀의 첫 프로젝트 관리자를 맡은 마이클 토이는 신속한 릴리스를 원했지만 이내 소프트웨어 시간의 늪에 빠져 허우적거리게 되었다. 두 번째 관리자 케이티 팰런은 머리는 뛰어나지만 고집이 세기로 유명한 프로그래머 집단을 단호하게 이끌었다. 프로그래머 팀 중에는 종종 지독한 버그를 고치는 일에 몰입하던 사색적인 프로그래머 존 앤더슨과, 고등학교 시절 학교의 미니 컴퓨터를 분해했다가 거기서 자신의 미래를 발견했던 데이터베이스 전문가 앤디 바이다 등도 있었다.
로젠버그의 이야기는 추상적인 코드와 예측하기 어려운 사람들의 행동(특히 그들 자신의)과 씨름하면서 이들이 맞닥뜨리는 모험과 퍼즐 속으로 우리를 끌어들인다. 이 기나긴 여정에서 우리는 블랙홀, 거북이, 뱀, 용, 도끼, 야생소 등을 만나게 되고 소프트웨어 개발 역사에 등장했던 각종 이론과 방법론을 접하게 된다. 이와 함께, 널리 알려진 개념인 '맨먼스 미신(Mythical Man-Month)'부터 최근에 유행하는 '익스트림 프로그래밍(XP)'까지 등장한다.
기술에 관심이 많은 이들뿐만 아니라 발명의 드라마에 매력을 느끼는 사람이라면 누구라도 [드리밍 인 코드]를 통해 정보화 시대와 인간 정신에 대한 지혜와 성찰을 얻게 될 것이다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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