조엘 온 소프트웨어 유쾌한 오프라인 블로그

서평 

이 책은 번역이 참 마음에 든다. 

이렇게 할 수 있었던 것은 역자의 노력이 었을 것이다. 

중간 중간 마음에 드는 번역들이 많이 있었고 덕분에 좋은 내용을 잘 번역된 한글로 읽을 수 있어 대단히 유용했던 책이다. 

번역서는 추천하지 않는데 원서는 추천하는 경우가 프로그래밍 서적에는 종종 있는데 이 책은 어느 누구에게나 번역서로 

추천하고 싶은 책이다. 한번 쯤 읽어 보면 내용에 놀라지만 번역에 한번 더 놀랄 것이다. 

간단하게 여기에 책 앞 부분을 적어 둘 것이다. 보고 흥미가 있다면 사서 보길 바란다. 

[들어가며]

결코 당신이 스스로 관리자 자리를 자청하지는 않았을 것입니다. 제가 아는 대다수 소프트웨어 개발자처럼 그저 조용히 않아서 코드를 만지기만 하는 편이 훨씬 더 행복했을 것입니다. 하지만 전임 팀장인 니겔 씨가 번지 점프 줄과 랩탑 컴퓨터에 얽힌 불운한 사고를 당한다면, 당연히 팀 최고 개발자인 당신이 팀장으로 승진하겠지요?

 이제 당신에게 (하계 인턴으로 근무할 때부터 운명을 같이했던 공동 큐비클을 대신해) 개인 사무실이 생기고, (온정일 모니터 앞에서 행복하게 눈동자를 굴리는 대신)매년 두 번씩 업적 평가 서류를 채워야만 합니다. 서류 작업에 시달리지 않을 때는 말도 안 되는 온갖 요구로 투덜거리는 변덕쟁이 프로그래머, 뒤통수 치기의 명수인 영업사원, 도대체 '사려 깊은' 사용자 인터페이스를 위한 RGB 값이 뭔지도 모르면서 파리가 미끄러질 정도로 반짝거리는 확인/취소 버튼을 만들어 낸 창조적인 (하나님 맙소사, 그래픽 디자이너라니까요) '사용자 인터페이스 디자이너'와 싸우느라 쓸 데 없는 시간을 낭비하게 될 것이빈다. 그렇지 않다면, 소프트웨어 대한 지식이라고는 델타 항공 기내지에서 읽은 내용이 전부인 양 뻐기는 선임 부사장이 던진 "도대체 오라클 대신에 자바를 사용하지 않는 이유가 무엇인가? 들리는 소문에 따르면 자바가 좀더 통합적이라고 하던데?"와 같은 황당무계한 질문을 처리해야 합니다. 

  관리자 세계에 발을 내딛은 당신을 환영합니다! 그런데 관리가 뭔지 아시나요? 소프트웨어 프로젝트 관리는 프로그래밍과 전혀 관련이 없습니다. 지금까지 당신이 수행한 작업이 단지 코드를 작성하는 일이었다면, 아마도 인간보다 다양한 인텔 CPU를 예측하는 게 좀더 쉽다는 사실을 느끼기 시작할 것입니다. 

  어쨌든 전임 팀장인 니겔 씨는 관리 업무에 결코 익숙하지 못했습니다. 니겔 씨는 조금 허장성세를 섞어서 "나는 요점 없는 회의에 모든 시간을 쏟는 관리자가 되기는 원하지 않는다.", "나는 85% 시간을 코딩에 할애하고, 나머지 시간을 관리 업무에 사용할 수 있다고 생각한다."고 말했습니다. 

  니겔 씨가 정말로 말하고 싶었던 핵심은 "이 프로젝트를 어떻게 관리할지에 대한 아이디어는 전혀 없고, 기술 수석이 되기 전처럼 그저 열심히 코딩을 하다 보면 모든 일이 어떻게 제대로 자리를 잡아가겠지"였을 것입니다. 물론 니겔 씨는 실패했으며, 이를 인정하기 싫었기에 운명적인 사고 당일에 IBM 씽크패드와 함께 번지 점프를 한 거겠지요.

  이랬거나 저랬거나, 니겔 씨는 큰 사고에도 불구하고 금방 회복했으며, 현재 번지점프 동료와 함께 시작한 WhatTimeIsIt.com이라는 작은 회사의 기술 이사로 일하고 있습니다. 하지만 지금 니겔 씨에게는 새로운 시스템을 처음부터 완벽히 구현해서 출시할 시간이 6개월밖에 없으며, 과거처럼 번지점프를 믿고 또 다시 허세를 부릴 수 는 없습니다. 

소프트웨어 프로젝트 관리는 잘 알려진 기술이 아닙니다. 어느 누구도 소프트웨어 프로젝트 관리 분야에서 학위를 딸 수 없으며, 이 주제를 다루는 책도 찾아보기 어렵습니다. 소프트웨어 프로젝트를 성공적으로 수행한 극소수의 사람들은 떼 돈을 벌어 은퇴한 후 송어 양식장에서 낚싯줄이나 드리우고 있기에 다음 세대에 축적된 경험을 전달할 기회도 없습니다. 게다가 다른 몇몇은 지쳐버린 나머지, 도심의 불량배에게 치유 목적으로 교정 영어를 가르치는 등 (소프트웨어 프로젝트에 비해) 스트레스를 조금 덜 받는 분야로 전향했습니다. 

  이런 이유로 인해 많은 소프트웨어 프로젝트는 안팎으로 여러 가지 측면에서 실패를 겪고 있습니다. 이런 실패 이유는 팀에 있는 어느 누구도 소프트웨어 프로젝트를 성공적으로 진행하는 방법을 잘 모르기 때문입니다. 너무나도 많은 팀이 제품을 전혀 출시하지 못하거나, 제품 출시에 너무 많은 시간을 소비하거나, 쓸모없는 제품을 제작하곤 합니다. 하지만 정말로 저를 화나게 만드는 사실은, 팀원이 프로젝트 기간 내내 불행하며, 개발 작업에 들어가는 모든 시간을 저주한다는 사실입니다. 자신의 직업을 저주하며 지내기에는 인생이 너무나도 짧습니다. 

  몇 년 전 제 웹 사이트에, 효율적으로 운영되는 소프트웨어 팀을 특징짓는 열 두가지 항목이 담긴 '조엘 테스트'를 올렸습니다. 여기에는 버그추적을 위한 데이터베이스 유지, 즉석에서 구직 대상자에게 코드를 작성하게 하는 면접방법을 비록해 여러 사항(걱정하지 마세요, 뒤에 이 테스트에 대한 세부적인 내용을 다룰 것입니다.)이 있습니다. 놀랄 만한 사실은 수많은 사람이 자신이 속한 팀이 열두 항목 중에서 둘이나 셋만을 통과했다는 사실을 전하기 위해 제게 이메일을 보냈다는 점입니다. 

  두세 개라니!

  이 얼마나 비현실적입니까? 나사 없이 가구를 만들려는 목수를 한번 상상해봅시다.  이 목수는 못만으로 가구를 만들려하고, 망치를 본적도 없기에 탭 댄스용 구두로 나무에 못질을 합니다. 

  소프트웨어 프로젝트 관리는 코드 작성 작업과 비교해서 전혀 다른 기술과 기교가 필요합니다. 양자는 근본적으로 다르고 관련도 없는 분야입니다. 뇌 수술이 빵 굽기와 근본적으로 다른 것처럼 코드작성 작업도 관리 작업과는 전혀 다른 일입니다. 불가사의하게도 시/공간 4차원 세계의 찢어짐에 휘말려 제빵 공장으로 순간 이동한 똑똑한 뇌 수술 전공 의과의사가 빵 만드는 방법을 희미하게나 알고 있기를 기대할 수는 없습니다. 설령 이 의사가 하버드 의대 졸업생이었다고 해도 말입니다. 그럼에도 불고하고, 사람들은 직무 재조정을 전혀 거치ㄱ지 않은 상태에서 상급 코딩 기술자를 관리자로 밀어붙이는 작업이 가능하다고 받아들입니다. 

  앞서 말한 뇌 수술 전문의처럼, 당신이나 니겔 씨는 전혀 새로운 직업인 관리자로 순간 이동했으며, 이 직업은 당신이 컴파일러가 아닌 (세상에나) 사람을 다루길 원합니다. 오늘날의 자바 컴파일러가 문제가 ㅁ낳고 예측 불가능하다고 생각해왔다면, 일급변덕쟁이 프로그래머가 저지를 사고가 발생할 때까지 기다려보십시오. 사람은 구성한 팀을 관리하는 일에 비하면 C++ 템플릿 정도는 문제도 아닙니다. 

  소프트웨어 프로젝트를 성공적으로 관리리하기 위한 기교는 다양합니다. 현재 수준은 이미 못과 탭 댄스용 구두를 넘어섰으며, 요즘 관리자는 마치, 드라이버, 양날 슬라이딩 복합 밀링 전기 톱을 손에 넣을 수 있습니다. 

  이 책의 목표는 팀이 선도하는 일정 예측에서 시작해 소프트웨어 CEO가 경쟁력있는 전략을 수립하기에 이르기까지 다양한 기법을 소개하는 것입니다. 이 책을 통해 다음고 ㅏ같은 내용을 배울 수 있을 것입니다. 

* 최고 인재고용과 동기 부여 - 성공적 소프트웨어 프로젝트를 위한 핵심 요소

* 일정 예측과 관리 기법, 이런 기법이 필요한 이유

* 소프트웨어 기능 설걔 방법, '한번 쓰고 결코 읽지 않는', 자리만 차지하는 바인더가 아닌 실용적인 기능 명세서 작성 방법

* 소프트웨어 개발함정 회피방법, '다 버리고 다시 작성하는' 프로그래머가 저지르는 모순

* 팀 조직과 동기부여 방법, 프로그래머에게 개별 작업공간이 필요한 이유

* 업무에 적당한 프로그램 버전을 인터넷에서 찾는 대신, 코드를 새로 작성할 시점

* 소프트웨어 전략과 BeOS가 초기부터 망한 이유

* 그밖에 흥미로운 이야기

  각 주제는 아주 주관적입니다. 단순함을 위해 매 문단의 시작 부분에서 '제 부족한 사견에 따르면'이라는 문구를 빼지 않을 수 없었습니다. 그 이유는 책을 읽으면 아시겠지만, 이 책에 실린 모든 문단이 제 개인적인 의견이기 때문입니다. 비록 이 책이 완벽하지는 못할지라도 틀림없이 좋은 출발점으로 삼을 수 있을 것입니다. 

아, 여러분은 이미 제 블로그를 방문했을 겁니다. 

이 책 내용 대부분은 제 웹 사이트인 조엘 온 소프트웨어에 올라온 기사 시리즈에 먼저 등장했습니다. 이 블로그는 지난 몇 년에 걸쳐 제 생각을 기록해온 장소입니다. 당신이 손에 쥐고 있는 이 책은 웹사이트보다는 대단히 체계적인 구성 방식을 따르고 있습니다. 여기서 체계가 의미하는 바는 '감전사 걱정 없이 욕조에서 읽을 수 있다.'는 뜻입니다. 

  독자를 위해 이 책 내용을 세 가지 주요 부분으로 나눴습니다. 첫째 부문은 소프트웨어를 개발하는 과정에 필요한 소소한 사항입니다. 즉 사람이 다치지 않는 소프트웨어를 만들기 위해 여러분의 팀이 해야 하는 모든 일입니다. 둘째 부문은 프로그래머와 팀을 관리하는 데 필요한 의견을 모았습니다. 셋째 부문은 조금 두서가 없지만, 소프트웨어 개발 비즈니스를 지속적으로 유지하기 위한 큰 전략에 초점을 맞춥니다. 블로트웨어가 항상 승리하는 이유, 벤 앤 제리가 아마존과 다른 이유와, 소프트웨어 개발 방법론에 대한 논쟁은 주로 무능한 조직에서 일어난다는 사실을 독자 여러분에게 보여줄 것입니다. 

  할 말은 아직 더 많지만, 이제 슬슬 본론으로 들어가볼까요?

이 책을 읽으면서 흥미로운 부분이 많이 있었다. 하지만 독자가 마이크로소프트를 다녀서 그런지 마이크로소프트 이야기가 많이 아온다 그래서 인지 MicroSoft니까 저게 가능하지 하면서 본 부분도 조금은 있었던거 같다. 

현업에 있으면서 핑계가 느러가는 것 갔지만 내가 지금 책을 읽고 있다는 것 자체에 난 아직 달리고 있다고 자부한다. 

그래서 이런 책은 또하나의 자극이 되는 것 같다. 한번쯤 읽고 봄직한 내용이다. 돈이 아깝다면 직접 블로그에 들어가 보도록 하자. ㅋㅋ