the sentientist

#033 드리밍 인 코드 [DREAMING IN CODE]

책의 표지01를 보고 수많은 패턴이 그려져 있어서 ‘패턴에 대한 프로그래밍 책인가?‘하고 읽게 되었는데, 책을 읽을수록 책 안으로 빠져들어 가는 것만 같은 기분이 들더군요. ‘아! 이러다가 책 속으로 빠져 들어가는 거 아닌가? ‘라는 어처구니없는 생각마저 들게 했으니 말입니다. 책의 표지 덕분에 더 빠져 들어갔던 것 같기도 하고요.

원래 책 표지는 에이콘 블로그의 드리밍 인 코드』 트랙백 이벤트 당첨자 발표! 중간쯤에 있는데 개인적으로 번역판 표지가 더 맘에 드네요.

3일 만에 책을 읽었는데, 시간으로 따지면 10시간 정도가 걸린 것 같네요. 다 읽고 난 뒤에 느낀 감정은 마치 역사소설과 애거서 크리스티의 추리소설을 읽는 듯한 기분이 들더군요.

책의 소개를 간단히 하자면, 이 책의 저자인 스콧 로젠버그가 챈들러02 라는 프로젝트에 사서로 참여한 3년간의 기록이 담겨 있는 책으로, 저자는 프로젝트가 진행됐던 과정을 독자들에게 솔직하게 들려주는 책이라고 설명합니다.

이 이야기는 한 팀의 사람들이 코드의 바위 덩어리를 어깨에 이고 힘들게 언덕을 올라가는 과정에 관한 이야기다. 그들은 장애물03 에 걸려 넘어지면서도 실제로 유용하고 오래갈 무언가를 만들고자 하는 노력을 계속해왔다. -저자의 말 중에서

추리소설을 읽는듯한 기분이 든 이유는 수많은 등장인물이 책 속에 나오기 때문인 거 같아요. 노트에 등장인물들을 적어가면서 읽게 되었는데, 책의 맨 뒤쪽에 찾아보기에서도 등장인물이 최초 등장했던 페이지가 적혀 있는 건 저같이 등장인물이 궁금한 독자를 위한 배려 같아 보이더군요.

역사소설을 읽는 듯한 기분이 든 이유는 저자가 IT업계의 다양한 유명인사들을 책 속에 출현시켜 IT역사를 재미있게 설명했기 때문입니다. 솔직히 전 방법론과 프로그래밍언어를 많이 그리고 깊게 아는 것도 아니므로 솔직히 이런 역사적인 내용과 글 안에서 소개된 유명인사의 말과 링크들을 찾아보는 게 더 재미가 있었습니다.
수많은 링크 중에서 꼭 봐야지 하고 했던 게 있는데 나토 소프트웨어공학 콘퍼런스를 요약한 130페이지짜리 책자 2권의 보고서04인 데, 이미 40여 년 전에 현재와 같은 상황이 발생할 거라는 걸 알고 처방법을 보고서로 작성하였는데, 지금의 IT업계는 달라진 게 없는 거 같네요. 저도 당연히 이런 보고서가 있다는 걸 처음 알았고 읽어봐야지 하고 덤볐는데…., ‘으하하 영어인데다 어렵더군요.’

 

(이미지링크 : CookieBox)

콘퍼런스의 참가자들은 덜컹거리는 개발 과정에 대한 좌절감과 대규모 소프트웨어 개발의 불확실한 결과에 대해 기록했고, 그에 대한(나중에 실제 도입될) 각종 처방을 설파했다. 이들 처방에는 ‘소규모 팀‘, ‘디자인 초기 단계에서부터 사용자의 피드백 받기‘, ‘작고 유용한 것부터 당장 실행하기‘, ‘설명하기 쉬워야 한다는 기준을 활용하기‘ 등이 있었다. [p.329]

이 외에도 흥미를 끄는 링크05들과 읽고 싶은 책06 들이 많았지만, 책이 재미있어서 계속 다음 장으로만 넘어가서 모두 다 찾아보지는 못했고 따로 적어두기만 했습니다. 도서관에서 빌린 책이라 따로 적어둬야지 말입니다. 하지만, 꿈을 꾸려면 이 책을 사들여야 할 거 같아요.

프로젝트가 진행된 시간은 2003년부터 시작되어서 2009년까지 6년이 지났고 현재 내려받기 가능한 챈들러 버전은 1.0.2입니다.
책을 읽다 보면 등장하는 등장인물들의 경력은 어마어마합니다. 이런 대단한 사람들이 모여서 만든 프로젝트도 이렇게 오래 걸리고07 많은 돈이 들어갔지만, 아직도 개발이 진행 중이라는 걸 아니 참 재미있기도 하고 ‘소프트웨어 개발은 어렵구나!‘라는걸 알게 되었습니다. 그렇다고 이 책이 소프트웨어 개발을 어렵게 하지 않고, 어디서부터 잘못되었고, 어떤 것을 고쳐야 하는지에 대한 확실한 답 또한 주지 않고 있습니다.

저는 처음 책을 읽으면서 ‘도대체 챈들러가 뭐야? ‘라는 생각을 하고 책을 다 읽고 프로그램을 찾아서 실행시켜 봐야지 하며 꾹꾹 참고 있었습니다.
챈들러를 실행한 기분은 여기에서 표현하지는 않겠지만, 챈들러보다는 리멤버 더 밀크가 저에게 더 잘 맞는 거 같더군요.

책의 소감은 소프트웨어 개발에 대한 꿈을 꾼듯한 기억만 남아 있고, ‘소프트웨어는 어렵다!‘라는 질문에 대한 답을 찾을 것만 같아서 다시 한번 꿈속으로 아니 책 속으로 빠져 들어가야 할 거 같습니다. 몇 번의 꿈을 다시 꾸고 다른 꿈들도 꾸어야 할 것 같습니다

원서로 읽었으면 잘 몰랐을 내용을 깔끔하게 번역해주셔서 재미있게 읽을 기회를 주신 대산님에게 고마운 마음이 드네요. 다만, 조금의 욕심이 있다면 조엘 온 소프트웨어처럼 글 주석들이 페이지 밑에 달렸으면 책의 맨 뒷장까지 왔다갔다 하지 않고 더 자주 주석의 웹 페이지들을 찾아봤을 텐데 그게 조금 아쉽더라고요08.
이미 많은 개발자가 읽어봤겠지만, IT업계의 사람들이 어떻게 프로젝트를 진행하는지 궁금한 사람들이라면 재미있게 읽을 수 있는 도서인 거 같습니다. 개발자와 관리자라면 머리 좀 싸매고 생각 좀 할 거 같고요. 

아래의 글은 다시 꿈속으로 들어갈 때 쉽게 들어가려고 책을 읽으면서 기록해둔 챕터별 등장인물들과 용어들에 대한 책갈피입니다. OSAF[Open Source Applications Foundation]에 현재 있는 사람들도 있고 퇴사한 사람들도 있고 하지만 그냥 모두 OSAF라고 적어 두었습니다.

01. 불길한 시작.

  • 프레데릭 브룩스 – 소프트웨어 시간, 맨먼스 미신[The Mythical Man-Month], IBM의 시스템/360 시스템용 운영체제 개발 프로젝트 책임 개발 관리자, 브룩스의 법칙09
  • 리처드 스톨만 – MIT의 괴짜 천재, 자유 소프트웨어 재단[Free Software Foundation] 설립, GPL
  • 리누스 토발스 – GNU 운영체제에 커널을 제공. 핵심모듈 리눅스 개발.
  • 에릭 레이몬드 – 에세이 [성당과 시장]의 저자.
  • 빌 조이 – BSD 유닉스 개발자, 썬 마이크로 시스템즈 창업자.
  • 미치 케이퍼 – 로터스 1-2-3 창시자, 모질라 재단 회장, OSAF[Open Source Applications Foundation]창업자. 이 책의 주인공.

02. 어젠다의 비전.

  • 더글라스 잉글바트 – 최초의 Mouse 개발, NLS[oNline System, 개인정보 관리 시스템], 사용자가 기계에 적응해야 한다는 이론.

03. 프로토타입과 파이썬.

  • 고든 무어 – 인텔의 창업자, 무어의 법칙10
  • 귀도 반 로썸 – 파이썬 창시자.
  • 케이티 팰런 – OSAF, 사용자들의 행동패턴 연구, 몇 년 뒤 핵심 직책을 맡음.
  • 존 앤더슨 – OSAF, 아키텍터, GUI
  • 토틱 – OSAF, 넷스케이프의 창업멤버.
  • 존 앤더슨 – OSAF, 넷스케이프의 창업멤버, 쿠키 발명.
  • 제드 버지스 – OSAF, GUI

04. 레고 가설.

  • 데이빗 맥커스커 – OSAF, 데이터 저장 모듈.
  • 앤디 허츠펠드 – Mac 운영체제, 프로토타입 ‘vista11 ‘ 개발.
  • 모건 세이건 – OSAF, 쉬머라는 RDF-DB 개발.
  • 앤디 바이다 – OSAF, 새로운 데이터 저장소 개발자, 카우보이 개발자12.
  • 마이클 토이 – OSAF, 프로그래밍 팀 관리.
  • 워드 커닝햄 – Wiki를 만든 프로그래머, 카멜 표기법, 소프트웨어 패턴 언어13 .

05. 개와 긱 관리하기.

  • 제임스 고슬링 – 자바의 창시자, 제논의 패러독스와 도구를 만드는 일14.
  • 에릭 레이몬드 – 야생소 털깍이 문제15.

06. 끝도 없는 일 깔끔하게 해치우기.

  • 미첼 베이커 - OSAF, 커뮤니티 관리, 모질라 프로젝트.
  • 하이키 토이보넌 - OSAF, 보안부분, 넷스케이프.
  • 스튜어트 파멘터 - OSAF, 넷스케이프 신동.
  • 미미 인 - OSAF, UI 디자이너, GTD16 원칙을 적용, 스탬핑기능. 
  • 대규모 오픈소스 프로젝트를 시작하려는 이들을 위한 리누스 토발스의 충고. 
  • ‘작게 시작하고, 꿈이 너무 커지지 않도록 조심하고, 구체적인 부분을 늘상 고민하고, 그리고 커다란 비전에 대해서는 생각하지 않았다 하더라도 빠른 성공을 꾀하면 안 된다.’  [ p.211] 
  •  레고 블록을 다시 만들것인가? 기존의 것을 사용할 것인가?

07. 디테일 뷰.

  • 테드 룽 - OSAF, 재택근무, 데이터 저장소의 대용량 데이터 처리.

08. 화이트보드의 포스트 잇.

  • 리사 두솔트 - OSAF, 프로그래밍팀 관리, 마이크로소프트, 웹 표준 의원회, ’ 당신이 세운 계획이 무엇이든 일년 이상이 걸릴 예정이라면, 아마도 실제로는 엉터리 계획임에 틀림없습니다.’
  • WebDAV – 기존의 웹 프로토콜을 확장하는 새로운 표준 재정작업.
  • 아파타 카다키아 - OSAF, QA관리자, 네스케이프.
  • 쉴라 무니 - OSAF, 제품관리, 마이크로소프트. 

09. 개발 방법론.

  • 데이크스트라 – 절차적 프로그래밍 기법(스파게티 코드) -> 구조적 프로그래밍 기법(진주 목걸이)
  • 2가지 개발 방법론 – 계획이냐, 흐르는 대로 개발이냐.
  • 와츠 험프리 – IBM 소프트웨어 개발 총괄 책임자, CMN, TSP, PSP 등의 방식으로 중량 방법론을 이끌어내고 무조건 계획하고 계획한 것을 다시 계획하고 계획에 계획을 한다는 방법론을 사용함. 상부의 명령이나 희망사항에 의한 하양식 개발이 아닌, 계획은 실행할 프로그래머의 경험과 의견을 바탕으로 한 상향식 개발.
  • 애자일 소프트웨어 개발 방법론 – 와츠 험프리와는 상반되는 경량이란 표현을 쓰는 개발 방법론.
  • 애자일 원칙
  • ‘프로세스와 도구’ 보다는 ‘상호작용과 개인’
  • ‘포괄적인 문서’ 보다는 ‘실행 가능한 소프트웨어’
  • ‘계획과 협상’ 보다는 ‘고객과의 협력’
  • ‘계획 준수’ 보다는 ‘변화에 대한 대응’
  • 프리드 – 37 시그널즈 BaseCamp, Ta-da, Backpack , 리치 웹 어플리케이션.
  • 로젠버그의 법칙 – 만들만한 가치가 있는 유일한 소프트웨어는 뭔가 새로운 기능이 들어간 소프트웨어이다17

10. 공학자와 예술가.

  • 찰스 시모니 – 워드프로세서 소프트웨어 개발, 코딩의 자동화, 위지윅(WYSIWYG18 )개발, UML의 지지자.
  • 조엘 소몰스키 – 조엘 온 소프트웨어의 저자, 추상화는 작업시간을 줄이지만, 학습시간을 줄이지 못한다.
  • 앨런 케이 – 늦은 바인딩, 스몰토크 창시자, 객체지향 개념 만듦.
  • 모템킨 마을 – 1787년 러시아의 한 마을은 고위 관리자들에게 누추한 마을의 모습을 보이기 싫어서 껍데기만 있는 마을을 새로 만듦.
  • 자론 레이니어 – 고디안19 소프트웨어의 문제20, 페노트로픽 소프트웨어를 주장함21.
  • 리처드 가브리엘 – 썬의 뛰어난 전문가. ‘우리는 문학가들처럼 위대한 소스코드를 읽지 않고, 설계공부를 하지 않으며, 그들의 인생을 공부하지 않는다.’
  • 도널드 커누스 – 프로그래밍 분야의 바이블, 수학적인 원리들을 집필. The ART of Computer Programming.
  • Literate Programing – 다른 프로그래머가 코드를 읽는다는 가정하에 코드 작성하기. [p.367]

11. 개밥 먹기로 가는 길.

  • 브라이언 모슬리 - OSAF,  챈들러의 WebDAV 서버 프로젝트 코스모 개발.
  • 필립 보서트 - OSAF, 애플리케이션 팀 관리자, 마이크로소프트, 매크로미디어.
  • 존 매카시 – 리스트(LISP) 프로그래밍, 하나의 위대한 재귀 시스템.
  • 데이빗 해럴 – ‘Computer Ltd’의 저자, ‘정지 문제’, 무한의 시간을 언급.
  • 더글라스 호프스테더 – ‘괴델,애셔,바흐’의 저자, ‘이상한 반복’ 언급.
  • ‘종료조건’ – 리스프 책 인용. 재귀함수는 적절한 종료조건이 없으면 스택 오버플로우 발생.
  • 호프스태더의 법칙 – ‘프로젝트는 오래 걸린다. 이 법칙을 염두에 두고도 말이다.’
  • 제프리 해리스 - OSAF, 반복일정 기능.
  • 마이크 ‘코드베어’ 테일러 - OSAF, 빌드 작업관리 업무.
  • 리누스의 버칙 – 보는 눈이 많다면 모든 버그는 사소하다.
  • 앨런 쿠퍼 – 비주얼 베이식 제작, ‘정신병원을 뛰쳐나온 디자인’의 저자.
  • 데이빗 알랜 – ‘끝도 없는 일 깔끔하게 해치우기[Getting Things Done]‘의 저자.
  • 레이 커즈와일 – 튜링 테스트를 통과하는 컴퓨터를 계획.
  • 베노빈지 – 특이점22이라는 용어를 대중화시킴. 
Footnotes
  1. 표지 삽화 홍인기 – 수학 공식을 적용해 간단한 나뭇잎 이미지 하나로 복잡미묘한 재귀적 패턴을 만들어냈다. 끝도 없이 반복되는 소프트웨어 시간의 엔트로피를 상징한다. – 책표지에 []
  2. MS의 익스체인지 서버를 대신할 오픈소스 기반의 프로젝트이며 모든 플랫폼에서 사용할 수 있으며, 이메일과 일정관리에 중점을 두고, 로터스 어젠다의 동적인 특성을 물려받은 P2P Web Dav 서버기반의 개인정보관리 시스템. [p.105], 아직 책을 읽기 전이라면 설치는 나중에 해 보세요. []
  3. 과거부터 있었던 그리고 또 새로운 []
  4. 이후 40년 동안 소프트웨어 분야에서 논의될 모든 주제, 아이디어들에 대한 논란의 전조가 됨. []
  5. 마우스를 처음 발명한 엥겔바트의 데모 동영상 -clip 12 []
  6. The Art of Computer Programming []
  7. 오픈소스니깐 오래 걸릴 만하지만…., 길어도 너무 긴 거 같습니다. 뭐 리누스 토발즈는 리눅스개발만 13년 이상 하고 있다니깐 할 말 없죠. []
  8. 그래도 궁금한 건 왔다갔다하면서 찾아보게 되더군요. []
  9. 이미 지연된 프로젝트에 추가 인력을 투입하는 것은 일정을 더 늦출 뿐이다는 법칙. []
  10. 하드웨어의 빠른 발전을 예측. 40년 동안 컴퓨터는 매년 더욱 빨라졌고 또한 저렴해졌다. []
  11. 윈도우 vista 아닌 쉬머라는 데이터베이스를 사용하는 음악수집용 프로그램. []
  12. 규칙을 따르는 것을 거부하고, 혼자 작업하기를 선호하며, 항상 최신 기술을 사용하는 걸 좋아한다. []
  13. 알렉산더의 [A Pattern Language]는 성공적인 건축물에서 공통적인 요소나 패턴을 관찰해 일종의 건축 설계 원칙을 기술한 책이다. 이를 소프트웨어에 적용하기 위해 만들어진 것이 바로 소프트웨어 패턴 언어이다. []
  14. 도구의 도구를 만드는 일에 대한 내용. []
  15. 겉보기에는 아무 쓸모가 없어 보이는 작업이지만 실제로는 다른 문제를 해결하는데 필요하며, 이 다른 문제는 또 다른 문제를 해결하는 데 필요하고, 또 다른 문제는 또 다른 문제를 해결하는 데 필요하고, 이런 식으로 결국에는 당신이 해결하고자 하는 진짜 문제를 해결하는 데 필요한 일이라고 정의.[p.177] []
  16. 끝도 없는 일 깔끔하게 해치우기[Getting Things Done] []
  17. 로젠버그의 법칙은 IT업계에 법칙이 많으니 저자도 하나 만들어 낸 법칙이네요. []
  18. What you see Is What you get []
  19. 그리스 신화에 나오는 고르디우스라는 왕이 만들었다는 매듭으로, 이 매듭을 푸는 사람이 아시아를 지배할 것이라는 전설이 있었는데 알렉산더 대왕이 칼로 잘라버렸다고 합니다. [p.353 -조엘온소프트웨어] []
  20. 풀 수 없게 꼬여 있는 소프트웨어 문제. []
  21. 확실성보다는 확률에 근거한 점차 정확해 지는 소프트웨어를 지지함. []
  22. [Sigularity] 어느 순간 과거와의 단절이 이루어지는 지점을 말함. []

7 Comments so far

  1. Avatar
    DalKy on March 27th, 2009

    챈들러 M. 빙인가…

  2. Avatar
    DalKy on March 27th, 2009

    How project Really work 는 2006년에 나온 이미지인데 워낙 폭발적인 공감대가 형성되어서…지금은 2.0 버전까지 있다능.

    http://www.projectcartoon.com/cartoon/3 Ver 1.0
    http://www.projectcartoon.com/cartoon/2 Ver 1.5
    http://www.projectcartoon.com/cartoon/1 Ver 2.0

  3. Avatar
    DalKy on March 27th, 2009

    씨발 TACP 는 따로 샀는데…합본판이 나왔다니…

  4. Avatar
    DalKy on March 27th, 2009
  5. Avatar
    B00unge on March 28th, 2009

    프랜즈를 좋아하는 달키는 당연히 그 챈들러를 말할지 알았음. 책에도 ‘챈들러라고 하면 사람들이 의심하지 않을까요?’란게 있더라구~
    How project Really work는 너무 재미있다능. 2.0은 처음보네!!
    TACP도 읽고 싶은데 그 전에 사둔 Great Code라도 한번 봐야겠다능.
    고르디우스의 맵을 정말 싹둑 잘라버렸네…. 얼마나 어려우면 짤랐을까나. ㄲㄲ

  6. Avatar
    에이콘 on April 28th, 2009

    트랙백 타고 와서 글 잘 읽었습니다. 이렇게 꼼꼼한 서평은 못 봤던 것 같은데, 재미있게 읽어주셔서 정말 감사합니다.

    (아쉬운 점을 짚어주셔서 말씀드리자면, 주석은 원서에도 뒷 부분에 실려있어서 글의 흐름이 끊어질까 봐 그대로 실었습니다. ^^)

  7. Avatar
    B00unge on April 28th, 2009

    저도 다른 책들을 읽을때는 주석처리가 깔끔하게 된걸 좋아하는 편인데, 이 책에 나오는 주석들은 한번씩 찾아보고 싶어지더라구요.
    좋은 책 읽게 해 주셔서 고맙습니다. :D

Leave a Reply