아무도 몰랐던 마이크로소프트의 개발 프로세스와 구조조정과 인사고과 시스템의 내부, 그 봉인이 풀린다. 여러 해 동안 수천 명이 넘는 마이크로소프트 직원 사이에서 격렬한 논쟁을 불러 일으킨 연재 칼럼 ‘HARD CODE’ 49선 모음집. 마이크로소프트 내부자가 밝히는 코딩, 테스팅, 프로젝트 관리에 대한 오만방자한 이야기를 지금 공개한다.

“무능한 상사에게 이 책을 들키지 마라!!”
# IT 개발자/관리자가 정상에 오르기 위한 경력 관리/자기 계발 필독서
# 마이크로소프트 골수 관리자가 밝히는 무한 경쟁 시대, 조직에서 ‘당당히’ 살아남는 비법


[ 소개 ]

이 친구, 중고차 판매상이었다면 자질을 의심해봤을 테지만, 소프트웨어 개발 부문이라면 확실하게 뭔가를 알고 있다.

마이크로소프트 직원이라면 누구나 읽어야 하는 필독서

49개가 담긴 칼럼 선집에서, 에릭 브레히너는 가상의 인물 나잘난 박사의 입을 통해 노골적인 독설과 자신을 가장 괴롭히는 문제점을 풀어낸 최상의 해법을 제시하는 데 인정사정을 두지 않는다. 브레히너는 냉소적인 위트와 재치 있는 유머를 덧붙여 개발 프로세스를 상세히 분석하고, 어려운 팀 쟁점을 뜯어보며, 소프트웨어 비즈니스를 운영하는 방식을 비판한다. 브레히너의 생각은 늘 환영 받지는 못하지만(본인은 세간의 평에는 신경조차 쓰지 않는다), 뛰어난 소프트웨어 개발을 촉진하기 위해 토론과 상상력을 불러 일으킨다.

이 책이 파헤친 진실의 뒤안, 그 꾸밈없는 이야기
■ 설계부터 보안에 이르기까지 소프트웨어 품질과 가치 향상
■ 현실적인 프로젝트 일정, 위험, 명세 관리
■ 골수 광신자가 되지 않고서도 프로세스 개선 방법론을 적용하는 기법
■ 성공적이고 만족스러운 경력 관리
■ 독재는 그만! 무럭무럭 자라는 팀 계발과 관리


[ 추천의 글 I ]

소프트웨어를 개발하는 일. 이 멋진 일을 직업으로 유지하는 일이 의외로 녹록하지만은 않다는 것, 이 직업을 가진 이들이라면 특히 요즈음 모두 절실히 느끼고 있지 않을까 합니다. 이 시대, 우리에겐 참 쉽지 않습니다.

“멋진 소프트웨어란 어떻게 만들어지는 것일까?” 그 궁금함에 끌려 시작한 이 일, 의외로 힘들지요. 이 질문에 대한 답은 될 수 없지만, 한 가지 비교적 자명한 대답은 그것은 사람에 의해, 여느 누구나와 마찬가지로 희로애락을 겪으며 일상에 지치기도 하는 ‘우리들’ 사람에 의해 만들어진다는 것입니다.

마이크로소프트의 소프트웨어도 마찬가지인가 봅니다. 마이크로소프트라는 거대 기업도 사람들의 모임. 개별 개발 조직은 힘들게 꾸려져 험난하게 현실을 헤쳐 가고 있음을 1인칭 시점에서 관찰할 수 있게 되는 순간, 우리가 어디에서 무엇을 만들고 있든지 일종의 안도감을 느낄 수 있을지도 모릅니다. “에이 모르겠다. 마이크로소프트도 그렇다던데 그 식으로 한번 해볼까?”라고 편히 마음 먹을 수 있으니 말입니다.

이 책을 읽으면서 놀란 점은 이런 이야기까지 해도 괜찮았었나 할 정도로 직원들이나, 아니 직원들 중 일부나 알고 있을 정도의 상당히 내부적인 이야기가 태연히 흘러 나온다는 점입니다.

실제로 이런 ‘알려진 비밀’은 마이크로소프트를 마이크로소프트답게 만들어 온 것이기에 묘한 매력이 있는 듯합니다. 많은 마이크로소프트 출신 개발자들이 업계 곳곳에서 당시의 추억을 회상하며 마이크로소프트를 졸업하고 나서 느낀 여러 의미의 교훈을 각자의 조직에서 녹여내고 있습니다. 스스로 만들어서 스스로 실무에 써 보는 ‘개밥먹기(dogfooding)’는 어느새 한국 개발조직에서도 트렌드가 되어 가고 있지요. OS에서 게임, 기업 애플리케이션까지 전방위의 대규모 제품이 큰 재앙 없이 (대개의 경우) 완성되는 마이크로소프트풍 개발 방법론, 궁금하지 않을 수 없습니다.

PM, 개발자, 테스터가 동등한 입장에서 뒤엉켜 하나의 제품을 만들어 내는 과정은 국내 개발 풍토에서는 다소 낯설지도 모르겠습니다. 그러나 고군분투 부대끼며 수많은 불확실성과 부조리와 싸워 나가는 현장의 모습은 하나도 다르지 않기에, 읽고 웃고 또 흉내내 볼 가치가 분명 있을 것입니다.

우리 모두 때로는 갖가지 개발방법론을 유행처럼 따라도 해보고 원칙으로 돌아가 교과서도 참고해 보지만 결국은 혼돈을 껴안고 좌절하곤 합니다. 이런 인간적 시행착오를 마이크로소프트도 똑같이 겪었음을 증명하는 이 적나라한 기록, 이 책을 통해 여러분의 커리어와 조직의 과거 혹은 미래와 만나는 것은 색다른 재미일 것입니다.

어찌보면 여러분도 마이크로소프트도 지금 변화의 기로에 놓여 있을지도 모릅니다. 그렇기에 이 책, 그 변화의 분기점을 찾아 온 여정임과 동시에 그 기로에 서서 분투중인 우리 스스로의 모습을 비추는 거울이 아닐까 합니다. 거울 앞에서 투덜대듯 속시원한 이 칼럼집, 일독을 권합니다.



[ 추천의 글 II ]

에릭 브레히너를 처음 만났을 때 나는 그가 ‘나잘난 박사(I. M. Wright)’라는 필명으로 쓰는 칼럼을 즐겨 읽는 애독자였다. 당시 나는 내가 대화 중인 사람이 나잘난씨와 동일한 인물인지 한참이나 의심했는데, 완고한 독설가로 유명한 나잘난씨와 달리 에릭은 겸손하고 예의 바르고 친절해서 클라크 켄트 같은 이미지를 풍겼기 때문이다.

내가 가장 좋아하는 칼럼은 마이크로소프트 팀이 소프트웨어를 개발하면서 겪는 기술 문제와 집단 역학에 초점을 맞춘 글이다. 마이크로소프트를 다루는 기사와 책은 엄청나게 많음에도 불구하고 정작 이런 주제를 다루는 글이 별로 없다는 사실은 놀랍기 그지없다.

대규모 소프트웨어 프로젝트를 이끄는 관리자는 근본적으로 세 가지 문제에 직면한다. 첫째, 프로그램 코드는 고치기가 너무 쉽다. 기계 공학이나 토목 공학에서 기존 시스템을 변경하려면 실제로 무언가를 깨부숴야 하지만, 소프트웨어 프로그램은 키보드만 두드리면 족하다. 교각이나 비행기 엔진 구조를 잘못 고쳐서 벌어지는 재난은 비전문가도 능히 내다보지만, 기존 프로그램을 고쳐서 발생하는 위험은 경험이 풍부한 개발자조차 머리를 긁적이며 헛다리를 짚기 일쑤다.

사실 건축과 소프트웨어는 유사한 점이 많다. 프로그램 코드는 각 코드가 속하는 시스템 계층에 따라 ‘기초(Foundation), 틀(Framing), 마무리(Trim)로 나뉜다. 기초에 해당하는 코드는 널리 쓰이지만 파급 효과 없이 변경하기는 어렵다. 마무리에 해당하는 코드는 바꾸기도 쉽고 자주 바꿀 필요도 생긴다. 문제는 복잡한 프로그램을 몇 년 동안 뜯어고치다 보면 프로그램이 개보수를 많이 해 누더기가 된 집처럼 변한다는 데 있다. 콘센트는 캐비닛 뒤에 있고 욕실 환기 장치는 엉뚱하게 부엌으로 빠진다. 변경을 가할 때마다 의도치 않게 생기는 부수 효과와 이에 따르는 궁극적인 대가를 파악하기란 쉽지 않다.

두 번째로 근본적인 문제는 IT 업계 역사가 너무 짧아서 소프트웨어 컴포넌트 재사용에 관한 표준이 사실상 없다는 점이다. ‘1×2미터짜리 건식벽체와 합판을 가로나 세로로 가져다 대려면 간주(間柱)를 40센티미터 간격으로 세워야 한다’와 같은 표준이 없을 뿐더러 간주, 건식벽체, 합판의 조합이 진흙, 짚, 바위, 철, 탄소섬유의 조합보다 나은지 여부조차 결정하지 못한 상태다.

마지막 문제는 두 번째 문제와 같은 맥락이다. 프로젝트를 진행할 때마다 소프트웨어 컴포넌트를 다시 짜면서 이름도 다시 붙인다. 소프트웨어 업계에서는 기존 개념에 새 이름을 붙이거나 기존 개념을 새 방식으로 사용하는 행태가 아주 흔하다. 소프트웨어를 만드는 가장 좋은 방법을 놓고 토론을 벌이는 사람 중 상당 수가 서로 다른 이름을 사용하는 바람에 상대편을 전혀 이해하지 못한다는 사실은 업계에 퍼져있는 공공연한 비밀이다.

언뜻 보기에는 모두가 쉬운 문제다. 표준을 만든 다음 강제하면 된다. 그러나 요즘처럼 우수한 저가 소프트웨어가 대량으로 쏟아지는 초고속 세상에서는 망하기 딱 좋은 방법이다. 사실 소프트웨어 개발에서 최대 장애물은 최대 강점이기도 하다. 저가 개인용 컴퓨터와 인터넷 상에서 돌아가는 유비쿼터스 소프트웨어야말로 급격한 혁신을 일으킨 원동력이 아니던가.

과거에도 마이크로소프트가 최고 개발 기법을 연구해 최고 특성을 가려낼 정도로 여유롭지는 않았다. 예전에는 전통적인 방식으로 소규모 프로젝트를 진행하는 수준에 불과했다. 그러나 개인용 컴퓨터와 윈도우 운영체제가 성공하면서 이제는 현존 최대 규모이자 최고로 복잡한 소프트웨어를 대상으로 개발서를 내놓는 수준에 이르렀다.

현재 마이크로소프트는 효율성과 창의력을 높이고 위험을 낮추는 최적의 시스템을 만들고자 부단한 노력을 기울인다. 현대 프로젝트에 따라다니는 엄청난 복잡성을 감안하건대 참으로 용감한 시도라 하겠다. 회사는 ‘출시’라는 업계 최대 난제에 전념하는 전문가와 전문가 조직을 만들었다. 세상에서 가장 복잡한 소프트웨어를 출시하고자 민간 신앙, 관습, 문화, 도구, 프로세스, 경험 법칙도 동원했다. 매일 이런 작업에 참여하다 보면 짜릿함과 좌절감을 동시에 느낀다. 에릭이 쓴 칼럼을 통해 이런 마이크로소프트가 얻은 경험을 공유하고 배우면 좋겠다.

[ 한국어판 출간에 부쳐 ]

나잘난 박사라면 “한국이 소프트웨어 개발을 진지하게 받아들일 때도 됐죠!”라며 큰 소리 쳤겠지만 나로서는 한국어판 번역서가 나온다는 사실을 커다란 영광으로 생각한다.

한국에 가본 적은 없다. 나는 아주 가정적에다 잘 돌아다니지 않는 사람이다. 여권도 2년 전에야 캐나다를 가느라 겨우 만들었을 정도다. 하지만 내 삶은 한국과 인연이 아주 없진 않다. 내가 처음 시범운전 했던 차가 현대 차였다. 후진하다가 소화전을 박는 바람에 영업사원 앞에서 얼굴을 못 들었던 기억이 난다. 가장 추억에 남는 생일 파티 장소도 한국 식당이다. 부모님과 함께 우리 식탁에서 갈비를 직접 구워 먹었다.

물론 내 아내와 아들은 한국산 휴대폰을 사용한다. 특히 내 아내는 새로 장만한 삼성 에픽스(Epix)를 아주 아낀다. 한국 기술이 아주 만족스러웠던 나는 친구들에게 추천도 했다. 또한 레드몬드 본사를 방문한 삼성 임원진 몇 명과 대화할 기회도 있었다. 마이크로소프트 사가 소프트웨어를 개발하는 방식을 질문하기에 나는 이 책에 담긴 내용과 거의 유사한 설명을 해줬다.

이 책에는 없으나 최근 내 ‘HARD CODE’ 블로그에 올린 제안 하나를 언급하자면, 남의 작품을 그대로 답습해서는 안 된다는 사실이다. 대신 그 작품을 연구하고 포용해 확장해야 한다. 예를 들어, 내 첫 번째 MP3 플레이어는 삼성 제품이었다. 그 제품은 윈도우 미디어 플레이어가 아니라 자체 소프트웨어를 사용해 음악과 비디오를 재생기로 올리고 내렸다.

삼성 미디어 플레이어 소프트웨어가 몇 가지 장점은 있었으나 좀 더 성숙한 윈도우 미디어 플레이어 소프트웨어에 비하면 기능과 사용성이 현저히 떨어졌다. 삼성 소프트웨어 개발팀은 윈도우 미디어 플레이어 개발팀이 앞서간 길을 그대로 답습하느라 수많은 시간을 투자했으리라. 하지만 개발 재능을 엄청나게 낭비하고 고객에게 실망만 안겨줬다!

대신 삼성이 윈도우 미디어 플레이어 경험을 포용하고 확장하겠다는 목표를 세우고 그 많은 시간과 노력을 투자했더라면? MP3 플레이어에 더 멋진 기능을 추가하고, 윈도우 미디어 플레이어와 MP3 플레이어를 완벽하게 통합하고, 포장지를 뜯자마자 그대로 사용하는 경험을 고객에게 선사했더라면?

다행스럽게도 오늘날 삼성 소프트웨어는 윈도우 모바일 소프트웨어를 포용하고 확장한다. 남의 작품을 답습하느라 시간을 보내는 대신 혁신적인 방식을 강구하느라 시간을 보낸다는 뜻이다. 앞으로 이런 모습을 더 많이 보고 싶다. 남의 수고를 적극 활용하라. 남의 수고를 발판으로 삼으라. 마이크로소프트 사 개발팀 전체를 여러분의 팀으로 활용하라. 그 위에서 새로운 가능성을 탐험하라.

다른 사람 작품을 토대로 새로운 작품을 쌓아올리면 여러 모로 이점이 많다. 마이크로소프트 플랫폼이든 다른 플랫폼이든 마찬가지다. 사내 동료가 내놓은 코드를 활용할 때도 마찬가지다. 단, 토대로 삼는 코드가 언제나 자신의 코드보다 더욱 안정적이어야 한다는 사실을 명심하자(그러므로 어제 만든 빌드보다 최신 릴리스를 사용하는 편이 낫다).

내 책을 읽는 독자 여러분에게 감사하는 마음을 전한다. 재미있고 유익한 책이라 여겼으면 좋겠다. 우리가 인간으로서 서로에게 배우고 최선을 공유하면 세상이 나아진다. 유치하지만 사실이다. 우리 모두 서로에게서 배우는 세상이 오기를 바란다.



[ 저자 서문 ]

최고 개발 기법을 소개한다는 지침서를 펴 든다. 십중팔구 지루하다. 가끔은 흥미롭고 유익하고 감동스러울지 몰라도, 확실히 건조하고 따분하다. 왜일까?

‘최고’ 개발 기법은 프로젝트와 사람과 목표와 선호도에 따라 달라지기 때문이다. 소위 최고 기법을 소개한다는 지침서가 따분한 이유는 여기에 있다. ‘최고’라는 판단은 지극히 주관적이다. 그래서 저자는 ‘언제, 어느 상황에서, 어떤 이유로 이 기법이 적합하다’는 식으로 표현하는 수 밖에 없다. 이런 설명 방식은 현실적이고 합리적이지만 동시에 따분하고 불충분하다. 확실한 사례 연구를 추가하면 흥미가 더해지지만, 그래도 저자는 여전히 독자에게 선택권을 넘겨야 한다. 안 그럼 거만하고, 독단적이고, 꽉 막혀 보인다.

그럼에도 사람들은 거만하고, 독단적이고, 꽉 막힌 전문가끼리 치고 받는 난상 토론을 즐겁게 관람한다. 전문가 의견을 읽고 친구나 동료와 토론하기도 좋아한다. 그러니 개인 칼럼에서 최고 개발 기법을 토론하지 못할 이유가 무엇이랴? 남들 눈에 꽉 막힌 멍청이로 비쳐도 좋다는 용기만 있으면 충분하다.


[ 저자 소개 ]

에릭 브레히너
마이크로소프트 사에서 개발 혁신 부사장을 맡고 있는 에릭 브레히너는 소프트웨어 업계에서 20년 넘게 경험을 쌓았다. 2001년부터 마이크로소프트 사 내부 직원을 위해 칼럼 ‘HARD CODE’를 쓰기 시작했다. 이 블로그는 처음부터 마이크로소프트 사내 직원 수천 명 사이에서 최고 기법이 무엇인지를 찾는 뜨거운 토론의 불씨를 지폈고, 나머지 개발 공동체에도 끼친 영향이 매우 크다.


[ 옮긴이의 말 ]

박재호

프로젝트가 지연되고 이런저런 복잡한 문제가 터지면서 회사 분위기가 어수선할 때면 야근하다 말고 옥상에 올라가서 하늘을 바라보곤 했다. IT 업계에서 선두 자리를 놓치지 않는 초우량 기업에서는 도대체 어떤 식으로 일을 진행하고 있으며, 과연 개발자에게 있어 실낙원이란 존재하는지 답답함을 느껴 북극성에게라도 물어보고 싶었기 때문이다. 하지만 실제 초우량 기업이라고 불리는 회사에서 운영하는 개발팀에 합류해서 몸소 경험해보지 않는 이상 그 안에서 어떤 일이 벌어지는지 알아내기란 아주 어렵다.

좋다. 그렇다면 직접 경험하지 못한다면 간접 경험이라도 하면 어떨까? 싼 가격에 남의 경험을 통째로 얻을 수 있는 훌륭한 매체로서 우리에게는 책이라는 도구가 있지 않은가? 하지만 지금까지 IT 분야에서 특정 기업 문화를 다루는 책이 몇 권 있었지만, 솔직히 감추고 싶은 분야까지 속속들이 메스를 들이대 폭로해버리는 경우는 드물었다. 대부분 외부인 시각에서 행복한 결말로 끝나는 내용을 담거나 아니면 잘못 알려진 소문을 토대로 터무니없는 평가로 끝나는 내용을 담는 경우가 대부분이었다.

하지만, 이번에 옮긴 이 책은 아주 특이했다. 마케팅에 유리하도록 빌 게이츠를 주인공으로 내세운 진부한 마이크로소프트 철학을 담은 기존 책과는 달리 마이크로소프트 사에 퍼져있는 내부 문화, 이 문화에 얽힌 문제점, 문제점을 개선하기 위한 방향을 내부인 관점에서 속이 다 시원하도록 남김없이 파헤친다. 게다가 마이크로소프트 내부 문화에 경종을 울리는 거침없는 하이킥도 모자이크나 검열 없이 등장하므로, 소위 초우량 IT 기업이라고 불리는 곳에서도 내부적으로는 고민과 갈등이 교차한다는 사실을 확인하며 안도의 한숨을 쉬게 만드는 보너스까지 제공한다.

“그래, 세상은 공평하지 않아!”라고 외치며 좌충우돌하는 에릭 브레히너의 분신 나잘난씨를 뒤쫓아가며 잠깐 동안 이 책에 빠져보자. 마이크로소프트 내부에서 일어나는 프로젝트 관리, 프로세스 개선, 명세, 부서간 공동 연구, 소프트웨어 품질, 소프트웨어 설계, 개발자로서 경력 관리, 개인과 회사 사이에 균형 잡기, 훌륭한 관리자 되기, 마이크로소프트 사 발등에 떨어진 위험 요소에 대한 생생한 내부 이야기와 교훈을 들으면서 이를 타산지석으로 삼아 개발자나 관리자로서 자기 계발에 힘써 보자.

비록 인터넷 사업에서 구글에 계속해서 밀리고, 윈도우 비스타 판매 부진으로 인해 운영체제 시장에서도 고전을 면치 못하고 있는 마이크로소프트 사지만, 이런 놀라운 기업 문화를 유지할 수만 있다면 앞으로도 계속해서 IT 왕좌를 유지할지도 모른다는 생각이 머리를 스치고 지나갔다. 자, 이제 다시 한 번 용기를 내어 암울한 주변 상황을 살펴보자. 전 세계에서 가장 큰 IT 개발 조직을 거느린 마이크로소프트 사도 항상 내부 문제점을 직시하고 이를 극복하기 위해 노력하고 있는데, 우리라고 못하리라는 법이 있는가?


이해영

이미 알겠지만, 이 책은 마이크로소프트 사 직원들을 대상으로 썼던 칼럼 모음이다. 그래서 나름대로 장단점이 있다.

단점부터 들자면, 마이크로소프트 사 조직 체계나 특정한 업무 절차를 알아야 이해할 내용이 간간이 보인다. 게다가 주제별로 장을 나누기는 했지만, 칼럼마다 출판 시기가 각각인 탓에, 내용이 중복되는 경우가 있다. 또한 출판 당시 글자 수가 제한된 칼럼이었으므로 한 주제를 아주 깊이 파고들지는 못한다.

반면에, 각 칼럼이 독자적이고 온전한 주제를 다루므로 어느 칼럼이든 순서 없이 골라 읽어도 무방하다. 또한 각 칼럼은 짧고 가벼우면서도 생각하고 토론할 출발점을 제공한다. 독자 여러분이 칼럼이나 블로그 글 모음의 단점을 이해하면서 동시에 장점을 충분히 활용하면 좋겠다.

사실 마이크로소프트 사에서 벌어지는 이야기라지만, 막상 읽어보면 ‘아, 마이크로소프트도 다른 IT 기업과 별반 다르지 않구나’하는 생각이 든다. 책 전반부에서 열거하는 소프트웨어 개발 문제는 어떤 소프트웨어 회사라도 모두 겪는 난관이다. 사람을 관리하는 문제 역시, 분야를 막론하고, 관리자라면 누구나 겪는 고충이 아니던가.

그렇다면 무엇이 마이크로소프트를 오늘의 마이크로소프트로 만들었을까? 책 후반에서 저자는 스스로 이유를 분석한다. 여기에 한 가지 덧붙이자면, 자기 회사와 자기 상사들을 적나라하게 비판하는 칼럼을 사내 직원들에게 버젓이 공개하는 (그것도 모자라 책까지 출판하면서 저자를 키워주는) 회사 문화가 한 몫을 하지 않았을까 생각한다.

한창 번역을 하다가 잠시 걱정을 했었다. 소프트웨어 개발자나 관리자라면 꼭 읽어볼 만한 책이라고 생각하지만 (그렇지 않았다면 번역을 맡지도 않았겠지만), 마이크로소프트 사 이야기라는 이유만으로 색안경을 끼고 보지 않을까… 기우이기를 바란다.


[ 옮긴이 소개 ]

박재호
포항공과대학교 컴퓨터공학과 학부와 포항공과대학교 대학원 컴퓨터공학과를 졸업했다. 블로그 ‘컴퓨터 vs 책’(http://jhrogue.blogspot.com)을 운영하고 있다. 옮긴 책으로 『조엘 온 소프트웨어: 유쾌한 오프라인 블로그』, 『초난감 기업의 조건』, 『The Art of Project Management: 마음을 움직이는 프로젝트 관리』 등이 있다.

이해영
포항공과대학교 컴퓨터공학과 학부와 퍼듀대학교 전자계산학과 대학원을 졸업했다. 오랫동안 소프트웨어 개발에 종사하다가, 2008년 현재 미국에 있는 소프트웨어 개발 회사에서 지역화 전문가 겸 프리랜서 번역가로 일한다. 옮긴 책으로는 『조엘 온 소프트웨어: 유쾌한 오프라인 블로그』, 『초난감 기업의 조건』, 『The Art of Project Management: 마음을 움직이는 프로젝트 관리』 등이 있다.

목차

• 01장 프로젝트 부실 관리
  • 2001년 6월 1일 | 개발 일정과 날아다니는 돼지와 몇 가지 환상
    • 리히터 척도 예측법
    • 위험 관리
    • 고객이 승리한다
  • 2001년 10월 1일 | 개발 일정을 둘러싼 끝장토론 2탄
    • 소프트웨어 공학은 확실히 불확실하다
    • 보이는 건 절반만, 들리는 건 아무것도 믿지 마라
    • 동기 부여: 피자나 맥주가 전부는 아니다
    • 기능 완료일: 미련을 버려라
  • 2002년 5월 1일 | 아직 재미없나요? 선별의 즐거움
    • 전쟁을 피하라
    • 사적인 감정은 버려라
    • 선별 규칙 다섯 가지
    • 세부사항에 숨어 있는 악마
    • 나아갈 때와 물러설 때
    • 작은 차이가 승패를 가른다
  • 2004년 12월 1일 | 죽음의 행진, 관리층이 문제야!
    • 장님 코끼리 더듬기
    • 실패하는 이유
    • 전환점
    • 남들이 가지 않은 길
  • 2005년 10월 1일 | 우리 솔직해지자고요
    • 망상(妄想)에 시달리다
    • 거짓말 하나 “완료했습니다”
    • 거짓말 둘 “나도 어쩔 수 없군요”
    • 거짓말 셋 “문제없습니다”
    • 거짓말 넷 “아는 바 없습니다”
    • 숨기지 말자!
      
• 02장 프로세스 개선, 마법은 없다
  • 2002년 9월 2일 | 6시그마? 제발 쫌~!
    • 참나, 이게 무슨 마법이라냐?
    • 구원병을 요청하다
    • 혼란 속에서 질서를 세우다
  • 2004년 10월 1일 | 담백한 린
    • 중용의 도
    • 낭비가 없으면 부족도 없다
    • 과잉생산
    • 깊이가 먼저다
    • 불필요한 운반
    • 불필요한 동작
    • 대기
    • 불필요한 공정
    • 재고
    • 결함
    • 공생
  • 2005년 4월 1일 | 고객 불만족
    • 아예 모르는 편이 낫다
    • 너무 늦었나요
    • 애자일 환상
    • 되짚어가기
    • 빙산의 일각
    • 적합한 도구
    • 임시변통
    • 고객 만족
  • 2006년 3월 1일 | 애자일 총알
    • 진실의 적
    • 규칙부터 다집시다
    • 색다른 시도
    • 말할 기회를 줘
    • 넌 내 반쪽이야
    • 좀 극단적이군
    • 럭비 한 게임, 어떻습니까?
    • 더 궁금하다면
      
• 03장 비능률 박멸!
  • 2001년 7월 1일 | 막판 명세, 자연의 섭리인가 유전적 결함인가?
    • 막판 엎어치기, 메치기, 뒤집기, 돌려차기
    • 복도 회의
    • 위원회 회의
    • 명세 변경 요청
    • 예방이 최선
  • 2002년 6월 1일 | 노는 손
    • 어비야, 저지레!
    • 그럼 뭘 할까요?
    • 낭비가 없으면 부족도 없다
  • 2004년 6월 1일 | 우리가 만나는 날
    • 왜 모였죠?
    • 목적이 뭐죠?
    • 저 사람들은 왜 참석했죠?
    • 왜 이제서야 말하죠?
    • 다음 단계는 뭐죠?
  • 2006년 7월 1일 | 명세서는 그만 쓰고 기능팀을 한곳으로
    • 제정신입니까?
    • 진퇴양난
    • 특수한 필요성
    • 기억 안 납니다
    • 하나에 집중한다
    • 준비됐습니까?
  • 2007년 2월 1일 | 나쁜 명세서, 누구 탓인가?
    • 환경 탓이다
    • 의사소통 단절
    • 쉽고 단순하다
    • 빈틈이 없다
    • 피드백을 주고받는다
    • 품질을 점검한다
    • 무슨 차이가 있나요?
      
• 04장 부서 간 융합
  • 2002년 4월 1일 | 기묘한 신세대 커플, 개발자와 테스터
    • 우리 사랑할까요?
    • 테스터는 필요악인가 혈맹인가
    • 네 꼬락서니를 알라
    • 너는 내 반쪽이야
  • 2004년 7월 1일 | 지피지기, 테스터가 하는 일
    • 이중 안전망
    • 긍정적인 변화
    • 환상특급
    • 자료 지존
    • 일단 믿어보시라니까요
  • 2005년 5월 1일 | 금성에서 온 문돌이 상사와
• 화성에서 온 공돌이 개발자
  • 피하지 못할 바엔
  • 그들은 우리와 다르다
  • 관문을 통과하려면
  • 일을 성사시키려면
  • 백지장도 맞들면 낫다
• 2005년 11월 1일 | 오합지졸, 전문화가 필요한 이유
  • 그 때를 아시나요
  • 극단에서 극단으로
  • 미식 축구는 과학이다
  • 극단과 극단 사이
  • 어느 선이 적당할까
    
• 05장 소프트웨어 품질, 꿈이 아니다
  • 2002년 3월 1일 | 여러분의 보안은 어떻습니까?
    • 극단과 극단 사이
    • 올바른 방향
    • 가장 취약한 고리만큼만 안전하다
    • 이끌든지, 따르든지, 아니면 비켜서라
  • 2002년 11월 1일 | 알맹이는 어디에? 품질이 필요해
    • 상황이 변했다
    • 그저 괜찮은 정도로는 부족하다
    • 어려운 선택
    • 시간이 있다면
    • 돌다리도 두드려라
    • 스스로 고쳐라
    • 한 번에 한 걸음씩
    • 무리일까요?
  • 2004년 4월 1일 | 소프트웨어 오디세이, 공예에서 공학으로
    • 책상 만들기는 공예, 차 만들기는 공학
    • 사람이 열쇠다
    • 자신에게 솔직하라
    • 알아서 뭐하게?
    • 습관이 차이를 만든다
    • 생각은 크게, 결과는 작게
    • 우수함에서 위대함으로
  • 2005년 7월 1일 | 검토와 검사
    • 바람직하지 못한 조합
    • 완벽한 폭풍
    • 책임자가 누구인가?
    • 이거 어때요?
    • 공식적으로 말입니다
    • 준비됐습니까?
    • 돌다리도 두드려라
    • 신비한 합체 회의
    • 효과를 높여주는 기교
    • 제대로 하기
  • 2006년 10월 1일 | 대담한 품질 예측
    • 수수께끼라고? 천만에
    • 쌍둥이 악마
    • 유력한 용의자
    • 멋지지 않습니까?
    • 거짓말은 이제 그만
    • 품질은 우연이 아니다
      
• 06장 시간 있으면 설계나 합시다
  • 2001년 9월 1일 | 오류 처리라는 비극
    • 공포여, 공포여
    • 예외를 고려하라
    • 잊어먹지 말고 써먹어라
  • 2002년 2월 1일 | 사공이 많으면 배가 산으로 간다
    • 백문이 불여일견
    • 몇 시인지 아는 사람?
    • 사공은 한 명으로 족하다네
    • 세상은 얽히고 설켜있다
  • 2004년 5월 1일 | 적당한 설계란?
    • 어느 정도가 적당할까?
    • 설계 완성도
    • 상세함이 열쇠다
    • 당신의 능력을 보여주세요
    • 격차를 조심하라
    • 성공하는 방법
  • 2006년 2월 1일 | 품질의 이면, 설계자와 아키텍트
    • 전보다는 나아져야 한다
    • 변화가 필요하다
    • 잘못 알았군요
    • 제대로 일하기
    • 다음에는 조각을 해보세요
    • 딱 맞는 도구
    • 벽을 넘어서
  • 2006년 8월 1일 | 고립은 아름다워, 더 나은 설계
    • 쪼개기는 어려워
    • 잘 쪼개기
    • 팀에서 ‘나’는 없다
    • 한 번에 한 걸음씩
    • 사이 좋은 견원지간
      
• 07장 경력 개발이라는 모험
  • 2001년 12월 1일 | 장인 개발자가 되려면
    • 자신의 한계를 알자
    • 만족과 안주
    • 있는 그대로가 좋다
    • 우리는 한 배를 탔다
  • 2002년 10월 1일 | 인생은 공평하지 않다
    • 더 이상은 싫습니다
    • 지식이 힘이다
    • 비즈니스 챙기기
    • 다 덤벼. 운수 대통한 날이군
    • 한 걸음 더 나서라
    • 준비하시고, 쏘세요!
    • 분위기를 바꿔라
    • 운전대를 쥔 사람
  • 2006년 11월 1일 | 경력 단계와 역할
    • 팔방미인
    • 흥행권
    • 저에게는 목표가 있습니다
    • 자격 과잉
    • 저는 전문가에요
    • 경력 단계는 하나뿐입니다
    • 무엇이 되고 싶은가?
  • 2007년 5월 1일 | 인맥 다지기
    • 누구를 아느냐가 중요하다
    • 습관과 일과를 활용하라
    • 궁금하지 않나요?
    • 감사하는 마음을 보여라
    • 연락 드리겠습니다
    • 새로운 세상에 오신 당신을 환영합니다
      
• 08장 인간 개조 프로젝트
  • 2002년 12월 1일 | 모 아니면 도 협상
    • 거부할 수 없는 제안
    • 아픈 만큼 성숙해지고
    • 마음 속에 어둠과 위험이 자라나다
    • 전령을 쏘지마라
    • 같이 행복하기
  • 2005년 2월 1일 | 삶의 균형을 찾자
    • 열쇠는 균형이다
    • 행동보다 앞선 말
    • 가계부 숫자 맞추기도 힘들어요
    • 균형을 잡으면 만사가 형통하다
  • 2005년 6월 1일 | 충분한 시간
    • 탁 까놓고 말하자면
    • 방해해서 미안해
    • 행복한 곳을 찾아서
    • 집단은 개인보다 멍청하다
    • 짐을 나눠라
    • 권한 자체를 위임하라
    • 아닐은 아직 무리야
    • 열심히 일한 당신, 떠나라
    • 질서를 지킵시다
    • 현실화하는 기쁨을 누려라
    • 규모와 책임
  • 2005년 8월 1일 | 꿩도 먹고 알도 먹자 - 상사 다루기
    • 방법이 없습니다
    • 적을 알고 나를 알면 백전백승이라
    • 스스로 변화하라
    • 워너비 봉이 김선달
    • 목표를 향해 쏴라
    • 설득의 묘미
    • 뱃심 좋게 꿈꿔라
  • 2006년 4월 1일 | 저한테 하는 말입니까? 기본적인 의사소통법
    • 저를 좀 배려해주세요
    • 내게서 무엇을 원합니까?
    • 언제까지 필요합니까?
    • 전 주의가 산만합니다
    • 끝났습니까?
  • 2007년 3월 1일 | 솔직함과 정직함을 넘어서
    • 변명하지마!
    • 정직하게 말할게요
    • 쉽지 않아요
    • 개방적이군요
    • 숨을 곳이 없어요
    • 그런 뜻이 아닙니다
    • 이해하시겠습니까?
      
• 09장 관리자냐 악마의 화신이냐?
  • 2003년 2월 1일 | 생산성은 단순히 숫자가 아니다
    • 무엇을 바라는지 신경 씁시다
    • 역할 놀이
    • 뛰어난 개발자의 요건
    • 스스로 판단하라
  • 2004년 9월 1일 | 면접 절차를 벗어나라
    • 적반하장
    • 90% 준비
    • 그것이 문제로다
    • 화이트보드 컴파일러
    • 인사 담당자 준비시키기
    • 면접관 (다시) 준비시키기
    • 점잖은 조언
    • 마지막 퍼즐 조각
  • 2004년 11월 1일 | 무능한 직원 관리하기
    • 무엇을 기대했던가?
    • 이를 악물어라
    • 전문가로부터 도움을 구하라
    • 실패는 없다
    • 목표는 성공이다
    • 질문하라, 그러면 얻으리라
    • 언제나 일이 좋은 쪽으로 풀리지는 않는다
  • 2005년 9월 1일 | 인재 관리와 이직, 흐름에 맡겨라
    • 침착하시구려
    • 어디 막아보겠다고?
    • 언제나 유유히 흐르는 강처럼
    • 참신한 인재
    • 나눔은 보살핌이다
    • 성장할 여지
    • 여행은 필수다
    • 흐름에 내맡겨라
  • 2005년 12월 1일 | 나는 관리자다
    • 그치지 않는 선물
    • 이 정도면 충분해
    • 진정하십시오
    • 일하고 싶어요
    • 나는 물건이 아니다
    • 좋은 관리자를 넘어 훌륭한 관리자로
    • 낮은 자세로 섬기자
  • 2006년 5월 1일 | 비교는 금물
    • 시비 걸기
    • 경쟁이 아니다
    • 힌트 몇 가지
    • 모두를 위한 하나
      
• 10장 마이크로소프트, 싸랑해요!
  • 2001년 11월 1일 | 조직 개편, 걱정을 접고 사랑하게 되기까지
    • 바벨탑 꼭대기에서 내려오는 소식
    • 지옥 같은 삶
    • 가보지 않은 길
    • 문제에 속할 텐가? 해법에 속할 텐가?
  • 2005년 3월 1일 | 여러분의 PUM은 부랑자입니까?
    • 계획의 인간
    • 작전에서 실천까지
    • 악마는 상세함에 있다
    • 여행 규칙
    • 궤도로 돌아가기
  • 2006년 9월 1일 | 윈도우 그룹 대빵? 좋습니다!
    • 마지막으로 할 말 있습니까?
    • 출항 준비
    • 진로 설정
    • 착수
    • 협상
    • 책임 소재
    • 차세대 윈도우
  • 2006년 12월 1일 | 구글, 심각한 위협인가 철자 오류인가?
    • 경쟁사가 비틀거릴 때 우리는 번창한다
    • 고의적인 실패
    • 똑똑한 사람들, 똑똑한 고객들
    • 경계를 늦추지 말자
    • 사선에서
  • 2007년 4월 1일 | 중년의 위기
    • 사람들은 모두 변하나 봐
    • 힘겨운 하루 하루
    • 우연은 없다
    • 지금은 무리야
    • 나이를 먹어가잖아요
    • 쫄지 마라

 1쇄 오류/오탈자 

[ p31 12행 ]
촉진하기 위해 생긴 그룹이 바로 → 촉진하기 위해 바로

[ p31 아래에서 4행 ]
온라인 사이트를 통해 → 온라인 사이트에서

[ p65 아래에서 2행 ]
'기업의 청렴'을 → '기업의 청렴도'를

[ p131 마지막 행 ]
검사에 통과해야 → 검사를 통과해야

[ p165 두 번째 박스 내 2행 ]
정보 공개 → 정보 노출

[ p218 세 번째 문단 4행 ]
에 충족하는 → 을 충족하는

[ p252 박스 내 1행 ]
이 칼럼이 나간 후에 받은 질문을 → 이 칼럼이 나간 후에 질문을

[ p306 박스 아래 1행 ]
7장 '인생은 공평하기 → 7장 '인생은 공평하지

[ p340 '저자 한 마디' 마지막 행 ]
을 권한다. → 를 권한다.

[ p355 '저자 한 마디' 마지막 행 ]
PUM(Product Unit Manager) GPM(Group Program Manager), → PUM(Product Unit Manager), GPM(Group Program Manager),

[ p377 '중간 목표 점검일' 5행 ]
'중간 목표 점검일'를 → '중간 목표 점검일'을

[ p377 아래에서 2행 ]
프로젝트(릴리즈) → 프로젝트(릴리스)

[ p385 '들어가며' 옮긴이 주 ]
1번 설명은 395페이지 '추천의 글' 4행 '클라크 켄트'에 대한 주석입니다.

[ p395 4행 ]
친절해서 클라크 켄트¹ 같은 → 친절해서 영화 <슈퍼맨>에 나오는 클라크 켄트 같은