다/ㅡ
드리밍 인 코드. 천국과 지옥을 넘나드는 소프트웨어 개발 이야기. geek과 친해지기
로드365
2011. 6. 12. 02:05
긱geek에 대한 상대적이고 절대적인 완벽 가이드는 "드리밍 인 코드" (http://www.acornpub.co.kr/book/dreamingincode) 을 참조하라는 조언이 있었다. ㅎㅎ
5장의 제목은 개와 긱 관리하기
천국과 지옥을 오가는 실존 프로젝트 여정을 낱낱이 기록한 소프트웨어 개발 전기(傳記)
비즈니스위크, 하버드 매거진, 시카고 트리뷴이 격찬한 책!
누구도 이야기하지 않았던 소프트웨어 개발의 은밀한 진실과 오해
프로그래머는 물론 IT 분야에 관심 있는 사람이라면 누구든 꼭 한번 읽어야 할 필독서
소프트웨어 개발은 왜 그토록 어려운 걸까? 버그 없는 소프트웨어 개발이란 과연 가능한 일일까? 누구도 풀지 못한 이 질문에 대한 답을 구하고자 저자 스콧 로젠버그는 마이크로소프트 아웃룩의 독점에 도전장을 낸 챈들러라는 야심 찬 개인정보관리 소프트웨어 개발 프로젝트를 3년 동안 추적했다. 이 책에서는 추상적인 코드와 예측하기 어려운 프로그래머들의 행동과 씨름하면서 이들이 맞닥뜨리는 모험과 퍼즐 속으로 우리를 끌어들인다. 해답을 구할 수 있을까? 소프트웨어 기술의 성배를 찾아 나서는 진지하고도 즐거운 여정에 함께 빠져보자.
[ 추천의 글 ]
소프트웨어는 인류에게 축복인 동시에 골칫거리다. 이 책은 실존한 소프트웨어 개발 프로젝트의 내밀한 속내를 들여다보는 매혹적이고도 절망적인 여정이다. 저자는 소프트웨어 프로그래머들을 산 비탈에서 끊임없이 거대한 바위를 밀어 올리는 형벌을 받은 그리스 영웅 시시포스에 비유한다. 이러한 비유가 얼마나 그럴싸한지 모르겠지만, 저자는 소프트웨어를 만드는 일이 헛된 시도라고는 생각하지 않는다. 그들에겐 즐거움과 희망이 있고 끝이 보이지 않을 것 같던 소프트웨어도 결국은 세상의 빛을 보게 된다. 먼 훗날 챈들러의 최종 버전도 발표될 테니.
비즈니스 위크 리뷰 중에서
비전은 웅대했으나 세세하고 구체적인 요소들은 너무 적었기에, 프로젝트를 지탱하는 바퀴는 계속 헛돌고 있었다. 챈들러 프로젝트가 단시간에 하나의 성과물을 내놓는 데는 실패했을지 모르겠으나, 우리는 개발 프로젝트를 생생하게 역사로 기록한 기념비적인 책을 읽을 수 있게 됐으니 한편으로는 성공적이었다고 말할 날이 올지도 모르겠다. 소프트웨어 산업을 다루는 모든 저자 중에 스콧 로젠버그는 단연 최고다.
조엘 스폴스키 / 『조엘 온 소프트웨어』 저자
『드리밍 인 코드』는 트레이시 키더가 쓴 『The Soul of a New Machine』의 진정한 후속편이라고 할 수 있으며 몇 년 간 접하지 못했던 기술적 전문성과 이야기 화법이 결합되어 있다. 천재 소프트웨어 개발자들이 실제로 무슨 일을 하는지 궁금하다면 이 책을 읽어라.
제임스 팔로우 / 애틀랜틱(The Atlantic)
기술자들은 해결하기 복잡한 문제를 ‘사소하지 않다’고 말한다. 스콧 로젠버그는 정말로 ‘사소하지 않은’ 주제를 선택해 재미있게 풀어냈다. 저자는 코드를 작성하는 사람들에 대한 동경을 솔직하게 표현하지만, 동시에 그들도 우리처럼 복잡하고 결점이 많은 존재라는 사실을 여실히 보여준다. 『드리밍 인 코드』는 진정한, 우리 시대의 소프트웨어 개발 보고서다.
댄 길머 / 시티즌 미디어 본부장, 『We the Media』저자
『드리밍 인 코드』는 프로그래밍에 대한 매혹적이면서도 냉철한 탐험이다. 수려한 문체를 뽐내는 이 책은 프로그래머나 비프로그래머 모두에게 창의성과 혁신의 근원이 무엇인지를 보여줄 것이다.
스티븐 존슨 / 『Everything Bad Is Good for You』와 『The Ghost Map』의 저자
스콧 로젠버그는 그 동안 어떤 프로그래머도 다룰 용기조차 내지 못했던 주제를 용감하게 다뤘다. 이 책은 인간의 창의성을 코드로 변환하고자 몸부림치는 혼란스런 소용돌이에 관해 다룬다. 저자는 소프트웨어 역사 이래 우리가 이론적으로 설명하려 끊임없이 시도해온 개발 프로세스를 소프트웨어 벤처기업의 실화와 맛깔나게 버무려 눈부신 이야기로 빚어냈다.
엘렌 울만 / 『The Bug and Close to the Machine』의 저자
『드리밍 인 코드』에는 진지한 드라마와 유쾌한 코미디, 그리고 애절함과 통렬함, 모든 감정이 녹아 있다. 이야기의 한가운데에는 디지털 혁명에서 가장 매혹적이면서도 제대로 이해 받지 못한 인물인 미치 케이퍼가 있다. 이 책은 소프트웨어 개발을 다룬 어떤 책보다도 재기가 넘치며 수많은 통찰력을 제공한다.
존 하일만 / 『Pride Before the Fall』의 저자
[ 출판사 서평 ]
소프트웨어는 현대 사회의 핵심 인프라를 책임지고 있지만, 그 개발 과정은 여전히 연금술의 수준에 머물러 있다. 게다가 계획이 거창하면 거창할수록 소프트웨어 개발 프로젝트는 그만큼 더 극적으로 실패하는 듯하다.
우리는 대규모 소프트웨어 개발 프로젝트가 중도에 와르르 무너지는 일을 끊임없이 봐왔다. 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
-출처