간편결제, 신용카드 청구할인
인터파크 롯데카드 5% (21,380원)
(최대할인 10만원 / 전월실적 40만원)
북피니언 롯데카드 30% (15,750원)
(최대할인 3만원 / 3만원 이상 결제)
NH쇼핑&인터파크카드 20% (18,000원)
(최대할인 4만원 / 2만원 이상 결제)
Close

HARD CODE : 나잘난 박사의 IT 정글 서이벌 가이드

소득공제

2013년 9월 9일 이후 누적수치입니다.

판매지수 89
?
판매지수란?
사이트의 판매량에 기반하여 판매량 추이를 반영한 인터파크 도서에서의 독립적인 판매 지수입니다. 현재 가장 잘 팔리는 상품에 가중치를 두었기 때문에 실제 누적 판매량과는 다소 차이가 있을 수 있습니다. 판매량 외에도 다양한 가중치로 구성되어 최근의 이슈도서 확인시 유용할 수 있습니다. 해당 지수는 매일 갱신됩니다.
Close
공유하기
정가

25,000원

  • 22,500 (10%할인)

    1,250P (5%적립)

할인혜택
적립혜택
  • I-Point 적립은 마이페이지에서 직접 구매확정하신 경우만 적립 됩니다.
추가혜택
배송정보
  • 4/3(월) 이내 발송 예정  (서울시 강남구 삼성로 512)
  • 무료배송
주문수량
감소 증가
  • 이벤트/기획전

  • 연관도서

  • 상품권

AD

책소개

마이크로소프트는 지금 어떨까?

마이크로소프트 개발 혁신 부사장 에릭 브레히너의 『HARD CODE - 나잘난 박사의 IT 정글 서바이벌 가이드』. 정상의 자리에 오르기를 바라는 IT 개발자와 관리자를 위해 저자가 그동안 마이크로소프트 직원을 위해 저술한 칼럼 49편을 엮은 것이다. IT 정글에서 살아남는 데 필요한 경력관리, 자기계발의 필독서가 되어준다.

이 책은 마이크로소프트의 비공식적인 개발 매뉴얼이다. '나잘난 박사'라는 가상의 인물을 내세워 마이크로소프트의 내부에 퍼져있는 문화와 그것이 가지고 있는 문제를 냉정하고도 유머러스하게 숨김 없이 공개한다. 마이크로소프트의 내부에서 벌어지는 프로젝트 관리와 개선, 부서 간의 공동 연구, 소프트웨어의 품질과 설계, 그리고 개인과 회사 사이에 균형 잡기 등을 노골적으로 엿볼 수 있다.

또한 마이크로소프트가 맞닥뜨린 위험에 대해서도 살펴보면서, 그것을 해결할 최상의 해법도 모색한다. 뛰어난 소프트웨어 개발을 촉진하기 위해 필요한 토론은 물론, 상상력을 불러일으킬 것이다. 아울러 마이크로소프트를 마이크로소프트답게 만들어온 묘한 매력을 느끼게 된다.

출판사 서평

< 요약 >

마이크로소프트 골수 관리자인 에릭 브레히너가 가상의 인물 나잘난 박사를 통해 통렬히 낱낱이 공개하는 비공식 마이크로소프트 개발 매뉴얼. 초우량 기업 관리자가 말하는 IT 정글에서 살아남는 서바이벌 가이드. 이제 그 봉인이 풀린다.

칼럼 49선을 담은 이 책에서, 에릭 브레히너는 제2의 자아를 내세워 노골적인 해설과 자신을 가장 괴롭히는 문제점을 인정사정 없이 풀어내고 최상의 해법을 제시한다. 저자는 냉소적인 위트와 재치 있는 유머를 덧붙여 개발 프로세스를 상세히 분석하고, 어려운 팀 쟁점을 뜯어보며, 소프트웨어 비즈니스를 운영하는 방식을 비판한다. 만인에게 환영 받지는 못할지언정, 뛰어난 소프트웨어 개발을 촉진하기 위해 필요한 토론과 상상력을 불러 일으키는 데 한몫을 한다.


< 소개 >

내가 뭐라든 나잘난 박사는 들은 척도 않을 테니.
- 존 디반, 마이크로소프트 수석 부사장

이 친구, 중고차 판매상이었다면 자질을 의심해봤을 테지만, 소프트웨어 개발 부문이라면 확실하게 뭔가를 알고 있다.
- 이안 엘리슨 테일러, 마이크로소프트 사 공학 부문 관리자

마이크로소프트 직원이라면 누구나 읽어야 하는 필독서
- 피터 아이젠시, 마이크로소프트 개발 관리자

마이크로소프트 내부자가 마이크로소프트 사가 어떤 곳인지 밝히기 위해 코딩, 테스팅, 프로젝트 관리에 대해 거침없는 하이킥을 날리는 모습을 구경하자. 가상의 인물 나잘난 박사를 내세워 다분히 계획적으로 집필한 혁신 칼럼인 ‘HARD CODE’는 여러 해 동안 마이크로소프트에서 근무하는 수천 명이 넘는 직원 사이에서 격렬한 논쟁을 불러 일으켰다. 그리고 바로 지금 (조금 걱정이 되긴 하지만) 나잘난 박사의 오만방자한 의견을 모두에게 공개한다.

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

이 책이 파헤친 꾸밈없는 진실의 뒤안

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


★ 이 책에 쏟아진 찬사 ★

흔히 대기업은 역설적으로 스스로가 창조한 문화에 발목을 잡혀 희생되기 쉽다. 자칫하면 이상적인 조직 상태나 이상적인 일 처리 방식이 자성적인 예언으로 변해버린다. 이런 태도는 어느 조직이든 치명적이지만, 특히 지속적인 혁신으로 먹고 사는 IT 기업에게는 극약이라 하겠다. 에릭 브레히너는 이런 조직적인 거품에 날카로운 칼날을 들이대 깊숙하게 해부한다. 또한 주저 없이 헛주먹을 날리다가 눈가에 시퍼런 멍이 들기도 한다. 일부 전문용어와 예제가 마이크로소프트 사 내부 문화에 국한된 것도 있지만, 에릭이 보여주는 재치와 혜안은 소프트웨어 업계 전체에 교훈을 던져주기에 부족함이 없다.
클레멘즈 스지퍼스키 / 수석 아키텍트

이 책에 실린 개발 일정 이야기는 정말로 훌륭하다. 현재 우리 그룹이 진행 중인 프로젝트에 딱 맞아 떨어진다.
이안 푸터질 / 그룹 관리자

에릭, 혹시 암살 위협 같은 거 받아본 적 없어요?
트레이시 멜처 / 선임 테스터

농담 맞죠? 아주 솔직히 말하자면, 이런 종류의 어리석음은 위험하답니다.
채드 델린저 / 엔터프라이즈 아키텍트

에릭은 내 영웅이다. 그는 아주 오랫동안 개발 공동체에서 이성적인 목소리를 높여왔기 때문이다.
채드 델린저 / 엔터프라이즈 아키텍트

소프트웨어 엔지니어들은 코드에 빠져들거나, 심하게는 프로세스에 빠져들어 길을 잃기 쉽다. 이 책에 담긴 에릭의 실질적인 충고가 정말로 필요한 때다.
데이비드 그린스푼 / 총괄 관리자

방금 이번 달 칼럼을 읽었는데… 처음으로 에릭이 회사에 해가 되는 잘못된 아이디어를 주장한다고 느꼈다.
데이비드 그린스푼 / 총괄 관리자

멋져요, 에릭. :) PUM과 개발 책임자 몇 명과 똑같은 대화를 몇 달 전에 했답니다. 멋진 칼럼이에요.
스캇 코트릴 / 총괄 개발 관리자

우리는 정말로 이 칼럼을 좋아합니다. 아주 실용적이며, 사리 분별이 정말 뚜렷합니다! 후배 사원들을 교육할 때 칼럼을 언급하면 내용이 너무 재미난 탓에 잊지 않고 기억하길래 종종 써먹습니다.
말리아 앤스베리 / 선임 소프트웨어 엔지니어

멋지군요, 에릭. 이번 칼럼은 진짜로 정곡을 찔렀습니다. 이번 칼럼이 관리자에게 던져주는 메시지는 ‘새로운 시도를 두려워하지 마라’라고 생각합니다. 현실은 이상적인 이론과 크게 다르지요.
밥 프라이즈 / 파트너 개발 관리자

지적이고 통찰력이 넘치는 에릭이 쓴 글을 아주 좋아하며 그가 심각한 문제를 (좋은 방향에서) 재미나게 만드는 재주가 있다는 사실을 말하고 싶을 뿐이다.
닐스 힐마 매드센 / 개발자 전도사

기능 제거 회의를 다음 몇 주에 걸쳐 진행하기로 결정했을 때 에릭이 쓴 ‘죽음의 행진’ 칼럼이 딱 맞춰 나왔다. 누구나 알아야 하지만 너무나 쉽사리 잊어버리는 교훈을 멋지게 지적해 줬다.
브루스 모건 / 총괄 개발 관리자

EE 사이트에 올라오는 글을 아주 재미나고 감명 깊게 읽고 있습니다. 오늘 올라온 칼럼 ‘명세서는 이제 그만’을 읽기 전까지 말입니다. 이번만은 당신 의견에 절대로 찬성하지 못하겠군요.
쳉 웨이 / 프로그램 관리자

나잘난 박사, 당신 누구야, 에릭 브레히너를 어떻게 한 거야?
올로프 헬만 / 소프트웨어 엔지니어

에릭, 당신이 쓴 ‘비교 따윈 하지 말자 - 기능 장애를 일으킨 팀’을 방금 읽었습니다. 회사 내 많은 사람에게 이런 좋은 정보를 알려준 배려에 크게 감사드립니다. 팀을 올바로 관리하고 이끌기 위해 노력하고 ‘노하우’를 공유하는 당신의 열정에 감사드립니다.
테레사 호간 / 비즈니스 프로그램


★ 추천의 글 ★

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

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

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

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

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

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

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

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

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

마이크 진텔
개발 총괄 이사
윈도우 라이브 코어
마이크로소프트
2007년 8월


★ 한국어판 출간에 부쳐 ★

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

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

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

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

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

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

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

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

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

2009년 6월 에릭


★ 저자 서문 ★

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

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

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


★ 옮긴이의 말 ★

박재호

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

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

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

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

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


이해영

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

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

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

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

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

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

목차

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일: 중년의 위기
사람들은 모두 변하나 봐
힘겨운 하루 하루
우연은 없다
지금은 무리야
나이를 먹어가잖아요
쫄지 마라
완벽한 사람은 없다

저자소개

에릭 브레히너 [저] 신작알림 SMS신청
생년월일 -

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

저자의 다른책

전체보기
박재호 [역] 신작알림 SMS신청
생년월일 -

포항공과대학교 컴퓨터공학과 학부와 대학원을 졸업했다. 임베디드 시스템 개발, 기업용 백업 소프트웨어 개발, 방송국 콘텐츠 수신제한 시스템 개발과 운영 지원, 클라우드에서 동작하는 서비스 개발에 이르기까지 다양한 실무 경험을 토대로 고성능 고가용성 시스템을 설계하고 있다. 코스닥 상장사인 엑셈 CTO로 인공지능과 스마트팩토리 관련 개발을 총괄했으며, 클라우드용 모니터링 시스템을 위한 아키텍처 설계도 주도했다. 『마이크로서비스 도입, 이렇게 한다』(책만, 2021), 『Clean Code 클린 코드』(인사이트, 2013), 『피플웨어』(인사이트, 2014) 번역, 『엘라스

펼쳐보기
이해영 [역] 신작알림 SMS신청
생년월일 -

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

컴퓨터/인터넷 분야에서 많은 회원이 구매한 책

    리뷰

    0.0 (총 0건)

    100자평

    작성시 유의사항

    평점
    0/100자
    등록하기

    100자평

    0.0
    (총 0건)

    판매자정보

    • 인터파크도서에 등록된 오픈마켓 상품은 그 내용과 책임이 모두 판매자에게 있으며, 인터파크도서는 해당 상품과 내용에 대해 책임지지 않습니다.

    상호

    (주)교보문고

    대표자명

    안병현

    사업자등록번호

    102-81-11670

    연락처

    1544-1900

    전자우편주소

    callcenter@kyobobook.co.kr

    통신판매업신고번호

    01-0653

    영업소재지

    서울특별시 종로구 종로 1(종로1가,교보빌딩)

    교환/환불

    반품/교환 방법

    ‘마이페이지 > 취소/반품/교환/환불’ 에서 신청 또는 1:1 문의 게시판 및 고객센터(1577-2555)에서 신청 가능

    반품/교환가능 기간

    변심 반품의 경우 출고완료 후 6일(영업일 기준) 이내까지만 가능
    단, 상품의 결함 및 계약내용과 다를 경우 문제점 발견 후 30일 이내

    반품/교환 비용

    변심 혹은 구매착오로 인한 반품/교환은 반송료 고객 부담
    상품이나 서비스 자체의 하자로 인한 교환/반품은 반송료 판매자 부담

    반품/교환 불가 사유

    ·소비자의 책임 있는 사유로 상품 등이 손실 또는 훼손된 경우
    (단지 확인을 위한 포장 훼손은 제외)

    ·소비자의 사용, 포장 개봉에 의해 상품 등의 가치가 현저히 감소한 경우
    예) 화장품, 식품, 가전제품(악세서리 포함) 등

    ·복제가 가능한 상품 등의 포장을 훼손한 경우
    예) 음반/DVD/비디오, 소프트웨어, 만화책, 잡지, 영상 화보집

    ·시간의 경과에 의해 재판매가 곤란한 정도로 가치가 현저히 감소한 경우

    ·전자상거래 등에서의 소비자보호에 관한 법률이 정하는 소비자 청약철회 제한 내용에 해당되는 경우

    상품 품절

    공급사(출판사) 재고 사정에 의해 품절/지연될 수 있음

    소비자 피해보상
    환불지연에 따른 배상

    ·상품의 불량에 의한 교환, A/S, 환불, 품질보증 및 피해보상 등에 관한 사항은 소비자분쟁해결 기준 (공정거래위원회 고시)에 준하여 처리됨

    ·대금 환불 및 환불지연에 따른 배상금 지급 조건, 절차 등은 전자상거래 등에서의 소비자 보호에 관한 법률에 따라 처리함

    (주) 인터파크커머스 안전결제시스템 (에스크로) 안내

    (주)인터파크커머스의 모든 상품은 판매자 및 결제 수단의 구분없이 회원님들의 구매안전을 위해 안전결제 시스템을 도입하여 서비스하고 있습니다.
    결제대금 예치업 등록 : 02-006-00064 서비스 가입사실 확인

    배송안내

    • 교보문고 상품은 택배로 배송되며, 출고완료 1~2일내 상품을 받아 보실 수 있습니다.

    • 출고가능 시간이 서로 다른 상품을 함께 주문할 경우 출고가능 시간이 가장 긴 상품을 기준으로 배송됩니다.

    • 군부대, 교도소 등 특정기관은 우체국 택배만 배송가능합니다.

    • 배송비는 업체 배송비 정책에 따릅니다.

    • - 도서 구매 시 15,000원 이상 무료배송, 15,000원 미만 2,500원 - 상품별 배송비가 있는 경우, 상품별 배송비 정책 적용