조엘 온 소프트웨어(유쾌한 오프라인 블로그) - 조엘 스폴스키, 2004

"소프트웨어와 관련된 일을 하는 사람들이 동감하고 다시 생각하게 해주는 책"

 'eXtreme Programming Installed' 이후로 오랜만에 읽어보는 Software Engineering 분야의 책이다. 사실 이책은 SE 분야의 책이라고 하기는 모호하다. 그보다는 소프트웨어와 관련 일을 하는 사람들이 동감할 수 있는 다양한 주제의 이야기들을 저자의 경험(주로 마이크로소프트에서의 경험)과 재치있는 입담으로 담아내고 있다.

  이 책은 블로그에 썼던 글들을 편집한 책으로 개발 능력의 밑바탕이 되는 프로그래밍 개념을 다루기도 하고, 명세서 작성 등과 같은 프로젝트에서 어려움을 겪는 부분들에 대한 솔루션을 제시하기도 하고, 개발자들을 관리하는 비결 그리고 이 바닦(?)의 비화들을 다루기도 한다.

  이러한 구성이 어쩌면 여터 Software Engineering 책보다 더 친근감과 동감, 거기에 실질적인 도움까지 줄 수 있는 게 아닐까 싶다. 특정 방법론을 주장하거나 교육하는 것도 아니고 그러다보니 정말 편하게 읽을 수 있는 책이다.

사실 이책이 출간 된 것은 2004년이지만 이 책의 내용이 쓰이기 시작한 건 2000년 쯤으로 거슬로 올라간다.(블로그의 글들을 모은 것이니 당연하다.) 그러다보니 사정이 지금과는 다른 이야기도 있고, 일부는 역자가 이러한 상황을 설명해주기도 한다. 2009년을 사는 우리의 사정은 출간 당시와 또 다르지만 그럼에도 불구하고 지금도 통용 될 수 있는 '필드'의 이야기를 들을 수 있고, 또 한편으로는 그 당시의 시대 상황(?)을 이해하는 데도 큰 도움이 된다.

마지막으로는 내가 떠나온 곳이긴 하지만 대한민국의 소프트웨어 관련 업계에도 이런 고수들이 많이 등장하기를 바래 본다....

-----------------------------------------
1부. 비트와 바이트 : 프로그래밍 실전

3. 조엘 테스트 : 더 나은 코드를 위한 12단계

01. Source Control(소스 컨트롤)을 사용하십니까?
02. 한번에 빌드를 만들어낼 수 있습니까?
03. Daily build(일별 빌드)를 만드십니까?
04. 버그 데이타베이스를 가지고 있습니까?
05. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
06. Up-to-date(최신) 스케줄을 가지고 있습니까?
07. Spec(설계서)를 가지고 있습니까?
08. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
09. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
10. 테스터들을 고용하고 있습니까?
11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
12. Hallway usability testing(무작위 사용성 테스팅)을 하십니까?

명세서

1. 면책조항을 넣을 것
2. 저자는 1명일 것
3. 시나리오
4. 회피 목표(non-goal) : 불필요한 기능을 처내는 작업
5. 개괄(목차)
6. 세부사항
7. 미해결 문제(open-issues)
9. 방주 : 다양한 청중을 고려
10. 지속적으로 개정할 것

프로그램 관리자(Program Manager)
- 마이크로 소프트웨어 개발팀에서 사용하는 개념
- 소프트웨어 관리 고전 "The Mythical Man-Month"
   '이미 늦은 프로젝트에 프로그래머를 더 넣어봤자 더 지연될 뿐이다' (개발자 n명 : 상호대화경로 : n(n-1)/2 , O(n^2))
- 요구사항수집, 명세서 작성, 세부사항 챙기기, 큰그림 염두해서 개발자들이 조각에 집중할 수 있도록 함

명세서
"표준 양식은 해롭다고 간주한다"

13. 종이프로토타이핑(Paper Prototyping)

14. 화성인 아키텍트를 조심하라
- 추상화를 추구하기 위해서 너무 높이 올라가면, 산소 부족에 시달릴 겁니다.
- 냅스터가 인기있었던 이유는 P2P방식이라서가 아니라, 곡명을 검색해 바로 들을 수 있었기 때문이라는 핵심을 놓쳤다는 사실이 중요합니다.

16. 장인정신
- 결함 1%를 고치기위해 500%의 노력이 필요

18. 더불어 살기
- 유닉스 문화는 다른 프로그래머에게 유용한 코드를 제공하는 것에 가치를 두는 반면, 윈도우 문화는 프로그래머가 아닌 사람에게 유용한 코드를 제공하는 것에 가치를 둡니다.

2부. 개발자 다루기

20. 인터뷰를 위한 게릴라 가이드

1. 첫인사
2. 최근 프로젝트 경력
  1) 열정이 보이는가?
  2) 상대 수준에 맞춰 설명할 수 있는가?
  3) 팀 프로젝트였다면 리더십을 발휘했을 것 같은가?
3. 답변 불가능한 질문
  - 'LA에는 주유소가 몇 개나 있을까요?'
  - 번뜩이는 창의력, 문제 해결 능력
4. 프로그래밍 문제
  - 간단한 함수(원래 저장위치에서 문자열을 역순으로 변환, 한바이트에서 1인 비트 세기 등)
  - 성능, 패턴 등
5. 만족합니까?
  - "코드에 만족합니까?", "버그가 어디있죠?", "코드에 버그가 있군요."
6. 질문 있습니까?
  - 총명한 질문을 하는지 판단

21. 성과급은 오히려 해가 된다
  - 부정적인 평가는 사기를 확 떨어뜨리는 반면, 긍정적인 평가는 사기나 생산성에 아무런 영향을 미치지 않음

23. 개발자는 멀티태스킹 기계가 아닙니다.
  - 직렬처리 방식은 평균적으로 결과값이 더 빨리 나온다

25. 드러난 빙산의 비밀(프로젝트 보고 기법)
  - 고객은 자신이 원하는 내용이 뭔지를 모릅니다. 기대하지 마십시오.
  - 핵심원리

1) 프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘 못 만들어진 화면을 보여주면, 사람들은 전체 프로그램의 90%가 잘못됐다고 생각한다.
2) 프로그래머가 아닌 사람에게 아름다운 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 다 끝났다고 생각한다.
3) 그래픽 디자인 버전을 몇 개 더 만들어라. 치명적인 영향이 없는 곳에서 고객 참여를 유도하라
4) 전시할 때는 화면(디자인)이 유일한 고려 사항이다. - 스티브 잡스가 이끄는 애플 사를 생각하라.

26. 허술한 추상화의 법칙
- 추상화에는 구멍이 존재하며, 이러한 구멍은 추상화로 없애 버린 내역에 대해 이해하지 못할 경우, 더 큰 어려움이 된다.

28. 측정
- "아마존닷컴에 전화주셔서 감사합니다. 무엇을 도와드릴까요?" 그리고 딸깍! 이런 현상이 이상합니까? 마이크 데이지에 따르면, 아마존은 시간당 전화를 받는 횟수에 근거해 고객서비스부서 직원의 업무고과를 평가했습니다.

3부. 조엘 따라하기 : 두서 없는 생각, 하지만 놓쳐서는 안 될 이야기

29장. 릭 채프먼이 아둔함을 찾습니다.
- 마케팅팀과 프로그래밍팀 중 어느 것이 중요할까? 그야 당근 둘 다겠지....라는 사실을 실화를 바탕으로 설명...

30. 이 나라에서는 개가 무슨 일을 하죠?
- '자기 개밥을 먹는다'는 말은 컴퓨터 분야에서 쓰는 기발한 표현으로 자기 회사 제품을 실제로 사용해 보는 과정을 가리킵니다.

31. 말단이면서도 해내기

1. 혼자라도 하십시오.
2. 입소문의 힘을 이요하십시오.
3. 우수한 인재를 모으십시오.
4. 고문관은 봉쇄해야 합니다.
5. 방해받지 않는 곳으로!
6. 꼭 필요한 인물이 되십시오.

32장. 이야기 둘
- MS사와 주노사에서의 저자의 경험. 권한 이임과 해당 업무 담당자(개발자)가 권한과 책임을 갖는 MS와 그렇지 못한 주노사 비교.

33장. 빅 맥 對 제이미는 요리사
- 지침으로 가득찬 맛없는 거대 기업 빅맥과 재능있지만 표준이 없어 확장할 수 없는 요리사 '제이미'. '지침서', '방법론' 특히 저질(?)의 IT컨설팅에 대한 단상. '방법론을 조심하라'
- "재능있는 요리사는 맥도널드에서 햄버거를 만드는 일에 만족하지 못할 겁니다. 그런대 왜 IT 컨설턴트는 하나같이 방법론을 그렇게 떠벌릴까요?"

34장. 세상에 쉬운 일은 없습니다.
- XP로부터 "코드가 설계다"라는 가르침을 받은 사람에 대한 경고. 리펙토링은 말처럼 쉽지 않다.(나도 동감) 형식에 지나치게 얽매이는 설계는 시간낭비이지만 설계가 무의미해지는 거대 시스템이 아니라면 설계가 꼭 필요하다.

35장. NIH 신드롬을 옹호하며
- NIH신드롬 : 팀이 스스로 개발하지 않은 기술을 거부하는 현상
- 아웃소싱, 엔진 등에 대한 경고

36장. 전략 메모 I: 벤 앤 제리 對 아마존
- 사업을 한다면 최소한 둘 중 어느쪽인지 확실히 하라

벤 앤 제리	아마존
기존 경쟁업체 많음 Network 효과(멧칼프법칙), Lock-in 효과 없음 자금이 거의 필요하지 않음 단시간에 손익분기점에 도달함 기업문화가 중요함 실수는 귀중한교훈이 됨 매우 느리게 성장 성공할 가능성이 충분함 크게 손해볼 확률은 적음	신기술, 초반에는 경쟁업체 없음 Network효과, Lock-in 효과 강함 자금이 엄청나게 많이 필요함 손익분기점에 도달하기까지 수 년이 걸릴 수도 있음 기업문화 정립이 불가능 실수를 간과하기 쉬움 매우 급속하게 성장 백만장자가 될 가능성이 있으나 아주 적음 실패할 확률이 큼

* 마이크로소프트사의 소프트웨어 개발방법
1부. 일정 맞추기
1. 아는 체 하지 마라
2. 상황을 파악한 다음에 움직여라
3. 제품-일정-비용 삼각형을 기억하라
4. 어둠 속으로 돌진하지 마라
5. 무결점 이정표를 사용하라
6. 팀워크를 유지하라
7. 일정에는 조삼모사가 없다.
8. 일정이 밀리면, 전열을 가다듬어라
9. 밑바닥 기술이 중요하다
10. 설계할 때는 설계만 한다.
11. 만들어야 출시할 수 있다.
12. 호환성은 카누 만들 때나 필요하다.

2부 위대한 소프트웨어
13. 고객을 감동시켜라
14. 통일성이라는 한가지 명제만 기억하라
15. 설계 사상을 명확하게 잡아라
16. 비교하라
17. 균형을 맞춰라
18. 발전시켜라
19. 제품을 층층이 쌓아라
20. 공유할 비전을 정하라

3부. 출시
21. 팀을 항상 출시 모드로 유지하라.

37장. 전략 메모 II: 닭이 먼저냐, 달걀이 먼저냐
- 플랫폼(주로 OS?)과 어플리케이션의 관계. 저자는 '하위호환성을 솔루션으로 제시

38장. 전략 메모 III: 돌아가게 해주세요!
- 반즈엔 노블즈 : 소파와 카페를 차려놓은 서점. '고객이 사고 싶은 책을 발견할 확률은 서점에서 보내는 시간에 비례한다.'

39장. 전략 메모 IV: 블로트웨어와 80/20 미신
- '블로트웨어' : 제공하는 기능에 비해 상대적으로 많은 디스크 공간과 메모리를 요구하는 소프트웨어.
- 개발자가 코드 크기를 적정하지 않으니까 출시를 앞당기거나 더 많은 기능을 넣을 수 있음
- '80/20법칙' : 사용자의 80%는 20%의 기능만 사용한다. 20%의 기능만 갖춘 경량의 소프트웨어가 성공할까?

40장. 전략 메모 V: 오픈소스 경제학
- 대체재(substitutes)와 보완재(complements)
- '보완재가격이 하락하면 제품 소요는 증가한다.' 마이애미행 항공권 가격이 하락하면 마이애미 호텔 수요가 는다.
- 똑똑한 회사는 자사 제품의 보완재를 일반 재화로 만들려고 애씁니다. 여기에 성공하면 자사 제품 수요는 증가합니다.
- IBM의 오픈소스 SW개발 투자 - 기업용SW를 일반재화로 만들어 IT컨설팅을 키우기 위함
- 넷스케이프의 웹 브라우저 소스 공개 - 브라우저를 일반재화로 만들어 서버시장을 키위기 위함

42장. 마이크로소프트 사가 API 전쟁에 진 이유
- 정말 재미있게 읽은 장. MS의 하위 호환성을 중요시 하던 '레이먼드 첸 진영'과 새기술을 'MSDN 매거진 진영'의 이야기, MSDN 진영의 승리로 나온 .NET(1.1과 1.0도 호환성을 제공하지 않음), Win32를 대체할 WinFX, XAML,아발론, 롱혼에 이어지는 이야기. 그리고 웹의 등장으로 관심에서 멀어져 가는 데스크탑 API. 결국 새로운 승자는 HTML?

4부 .NET에 대한 쓴소리
43장. 마이크로소프트가 난관에 부딪히다.
- 마이크로소프트가 .NET을 통해 보여주려는 장미빛 미래에는 장미가 없다? 결국 보여줄 미래가 없고, 그런 미래를 만들 수 있는 사람이 없거나(결코 똑똑한 사람들이 없다는 건 아니다.) 그것이 반영될 수 있는 구조가 아니라는 저자의 생각.

44장. 우리의 .NET 전략
45장. 저기, 링커 좀 주시면 안될까요?
- 두 이야기는 공통적으로 .NET에 대한 부정적인 시각. 그중에서도 20M짜리 CLR(.NET런타임)에 대한 문제 지적. 생각해보니 왜 정말 필요한 라이브러리만 bind하는 링커를 제공하지 않는걸까? 자신들이 Java 진영이라고 착각하고 있는걸까?

5부 하나 더
조엘에게 물어보기, 가장 재미있었던 질문
- "모든 일이 개발자 맘대로 쉽게 되는 듯이 느끼게 만들어야 진짜 훌륭한 관리자입니다."
- "경쟁사에 대해서는 신경을 끄세요. 그리고 자, 저를 따라 하십시오.
   경쟁사가 아니라, 고객에게 귀를 기울인다.!
   경쟁사가 아니라, 고객에게 귀를 기울인다.!
   경쟁사가 아니라, 고객에게 귀를 기울인다.!"
- "왜 이런 기능은 없나요?" 보다는 "당사 제품을 좋아하지만, 이런 이유로 사지 않습니다"에 귀기울여라.