확인해보니 번역판에서 “제인”과 “잰”으로 처리한걸 확인. (전자는 제인 세이건, 후자는 마젤란 호의 선장임)
실제 발음은 모르겠지만 — 아시는 분은 제보 좀 (…) — 적절한 처리인 듯?

내 조야한 이해 수준에도 불구하고, 책은 매우 즐겁게 읽었다. 얇지 않은 책이지만 대략 이틀 만에 다 봄. “엘리건트 유니버스”를 읽고 나서 LHC가 만들어진다는 점에 대해 꽤나 관심이 있었는데, 여기에 더 궁금하게 만들고 `왜 중요한지’에 대해서 설명해준 덕에 LHC에 대한 관심이 더 커진 듯.

아래는 약간 방향이 다른 리뷰(…). 사실 이건 제가 책 내용에 대한 기반 지식이 부족해서 그렇습니다 Orz.

1. 책의 전체 방향이랑은 조금 다른 얘기지만, 중간에 인용된 글 한 토막을 여기서 다시 인용해본다. (강조는 저자 분이 한 것)

패스토어 (로드 알랜드 주 상원의원): 이 프로젝트가 소련과 경쟁 관계에 있는 우리에게 제시하는 바는 없습니까?

윌슨 (페르미 랩의 설립자): 오직 장기적인 관점에서의 기술 발전에 있어서만 그렇습니다. 그 외에는 가속기는 이런 것들과 관련이 있습니다. 우리는 좋은 화가인가, 좋은 조각가인가, 훌륭한 시인인가와 같은 것들, 제가 말씀 드리는 것은 이 나라에서 우리가 진정 존중하고 명예롭게 여기는 것, 그것을 위해 나라를 사랑하게 하는 것들 말입니다. 그런 의미에서, 이 새로운 지식은 전적으로 국가의 명예와 관련이 있습니다. 이것은 우리나라를 지키는 일과 관련 있는 것이 아니라, 이 나라가 지킬 만한 가치가 있도록 하는 것과 관련이 있습니다.

지금 한국과, 한국의 사회를 구성하는 사람들은 “한국을 지킬 만한 가치가 있는 나라”로 만드는 부분을 늘리고 있는가? 이런 생각을 하니 굉장히 가슴 한 켠이 서늘해지더라. 정말 지킬 가치가 있는 나라인가?

2. LHC의 건설 비용과 운용 비용에 관한 것. 건설에 CERN이 사용한 비용은 6조 3000억 원. 그리고 검출기와 기타 시설 비용까지 추정하면 대략 10조 원 수준이라 한다.^[1] 운영비는 연간 약 2250억 원, 각 실험 팀의 실험비가 약 400억 원 정도로 예상된다고 한다.^[2] 내가 국가 규모의 예산을 이해할 능력이 없긴 하지만, 이 비용이 정말 큰가? 특히 내가 이 글의 1에서 인용한 내용을 생각하면 정말 큰가? 사대강의 올해 예산이 10조 원이란 주장도 있는 걸 생각하면 말이다…^[3]

예산을 더 들일수록 아마 그 기대 이익이 감소할 (수확체감; law of diminishing returns) 도로나 항만, 공항 같은 기반 시설에 돈을 계속해서 쓰는 게 유의미한가? (물론 기존 인프라를 유지 보수하는 비용이야 어쩔 수 없다고 해도) 과학과 문화에 대한 `사회 간접 자본’은 만들 생각이 없는가? 하다 못해 건물만 번드르르 지어놓은 도서관에 책이라도 채워 놓아야 하지 않을까.

3. LHC의 데이터를 처리하기 위한 시스템 구성에 더 관심이 가는 건 어쩔 수 없나(…)

1. 물론 책의 내용에 따르면 LEP 실험 때 이미 다음 세대의 가속기를 생각해서 터널을 파놓았기 때문에 그 부분의 비용은 추가로 들지 않아서 이런 거라곤 하지만
2. 책 446~447 페이지에 나온 내용
3. 한겨레 신문의 보도 참조; http://www.hani.co.kr/arti/society/society_general/428782.html

저자는 “새 기술/도구/방법론 등등을 도입하려면 어떻게 하는 게 좋을까?”라는 질문에 대해 그다지 두껍지 않은 책으로 풀어놓았다.

책 전반부에서는 사람들이 왜 기술에 반대하는지 설명하고, 후반부에는 이 사람들에게 어떤 방법을 써야 효과적으로 설득할 수 있는 지에 대해서 설명한다. 그리고 몇 가지 주의점?으로 마무리 한다.

우선 사람들이 기술에 왜 회의적인지를 크게 7가지로 분류해놨다.

• 해당 정보가 없는 경우 (the uninformed)
• 끌려가는 군중 (the herd)
• 냉소자 (the cynic)
• 이미 데인 사람 (the burned)
• 시간 없는 경우 (time crunched)
• 보스
• 비합리적인 경우 (the irrational)

…

이름만 보면 대충 알 수 있고, 마지막 경우는 좀 … 이긴 하다. (그러니까 대응 불가)

이런 사람들을 설득하기 위해, 그리고 자기 자신에게 속지 않기 위해, 다음과 같은 방법들을 나열한다.

• 경험을 쌓는다
• 영업(!)한다
• 데모
• 절충안 제시 / 중간 다리 만들기
• 신뢰 쌓기
• 명성 쌓기
• 시너지 만들기

…사실 이건 좀 뻔한다. 다만 앞의 “분류”에 대한 적절한 대응을 언급하는 건 괜찮음.

그렇지만 맺는 말로,

새 기술/… 을 적용하게 한 것에 만족하지 말고, “왜 새 … 를 들여왔는지”에 대해서 생각해야 한다는 점

언제라도 실패할 수 있다는 점

자기자신이 틀렸을 수 있다는 점

문제는 점점 커지고 바뀔 거란 점

을 얘기한다. 사실 이게 더 중요한 문제일지도…

“지금 보이는 문제”를 풀기 위한 방법으로 뭔가 새로운걸 도입하는 것이지만, 새로운 것이라는 점에서 얼마든지 틀릴 수 있다. 그 점에 대해 생각하면서 추진하는 자세가 중요할 듯 싶다.

관련 글:

1. 리뷰: The Design of Design
2. 리뷰: Coders at Work
3. 리뷰: More Joel On Software

“피플웨어”, “프로젝트가 서쪽으로 간 까닭은” 등의 저자인 톰 드마르코의 책이다. 이 책은 정말 한 줄 요약이 가능함.

“발전, 혹은 창의성의 원동력은 잉여(=slack)에서 나온다”

그리고 책 전반에 걸쳐 개인으로 보면 여유 시간, 조직으로 보면 여유 조직(혹은 중간 관리자 계층)이 이런 혁신의 중심지가 되는 이유로 이 slack을 두고 있다. 그리고 더불어, 효율을 중시하면서 이런 중간 관리자나, 개개인의 여유 시간을 제거 했지만(!), 실제로는 개별 효율은 올라갈 수 있어도, 조직 전체로 보면 여유 시간이 없어서 작업이 지연되는 예를 들고 있다.

이건 많은 대학원생, 직장인, 혹은 학생이나 기타 등등의 사람들이 경험하게 되는 일인 것 같다. 일을 계속 붙잡는다고 새 아이디어가 떠오르기 보단, 흥미 본위로, 혹은 곁다리로 하던 일에서 “자신의 주 작업 과제”의 해법이나 아이디어가 떠오르는 일이 정말 흔했던 것 같다. 어떤 의미로 보면 Google의 20% 시간 떼어주기도 이런 맥락일지도?

내가 최근에 만든 크래시 덤프 관련 툴들도 전부 이런 잉여 시간(…)에 만지작거리던 게 회의 시간에 튀어나와서 나온 경우다; 그러니까 뭔가 나오려면, 그 뭔가가 형성되기 위한 잉여 시간이 필요하다. 잉여한건 좋은 것(?).

스티븐 호킹은 이를 생명, 우주, 그리고 모든 것에 대한 궁국의 질문이라고 해놨다.

• 왜 (우주는) 허무한 공간이 아니라 무언가 있는 것인가?
• 왜 우리는 존재하는가?
• 왜 (현재 알고 있는) 특정한 자연 법칙이 있는 것이고, 다른 자연 법칙은 안되는가?

이 질문에 대한 답을 철학, 종교 등에서 뭐라하건간에, 과학의 힘으로 이에 대한 대답을 줄 수 있기 때문에 – 신 따위의 별도 개념 없이 – 철학은 죽었다… 정도의 말을 하고 있다.

일단 이 책에서 제시하는 이에 대한 대답은,

중력이 시공간을 변형하기 때문에, 시공간은 국소적으로는 안정적이나 전체적으로는 불안정하다. 우주 전체 스케일에선 질량이 갖는 양의 에너지가 음의 중력에 의해 균형이 맞을 수 있고, 전체 우주가 생겨나는데에는 제한(=질량-에너지 보존 법칙)이 없다. 중력과 같은 법칙이 있기에, (이 책에서 설명하는 방법에 따라) 무에서 우주가 자동적으로(spontaneously) 생겨날 수 있고,

이 자동적인 생성(creation)이 허무한 공간인 우주가 아니라 무언가 존재하는 까닭이고, 왜 우주가 존재하는지 이며, 왜 우리가 존재하는지에 대한 이유이다. 여기에는 신이 우주를 시작한다(light the blue touch paper) 따위의 설명은 필요없다.

이다. 이 책 앞 부분에서 설명한 과학의 발전 – 고대의 사고 실험 수준에서 과학 혁명 시기로 이전해 가면서 나타난 실험/검증에 따른 과학적 방법론, 그리고 모델 기반의 과학들 까지… – 과 물리 법칙들에 대한 설명, 그리고 현재 지구 상의 생명체와 비슷한 생명이 존재하기 위해 물리 법칙들이 어느 만큼 변형될 수 있는지에 관한 얘기들 등등. 이에 대한 설명을 하기 위해 각 후반부 챕터를 사용했다. 근데 이 설명이 좀 짧아서 아쉽다.

책 구매에 대한 평을 하자면(…) 책 자체는 굉장히 짧다. 왠간한 소설 책이 Kindle 에서 5000 줄 쯤 되는데, 이 책은 2387줄이다. 여기엔 용어집과 인덱스도 포함되어 있어서, 실제론 1800줄 수준이라 약간의 여유 시간만 있다면 읽을 만 하다. 어제의 알라딘 스팸(…)에 따르면 이 책의 번역서도 곧 나온다 하니, 원서 읽기는 귀찮은데 논리 전개(?)는 들여다보실 분은 번역서를 기다려도 괜찮을 것 같다.

종교 원리주의자들이라면 좀 많이 싫어할 것 같은 책이지만, 위대한 과학자의 반열에 오른(아마도) 우주의 존재에 관해 과학이 설명할 수 있다는 스티븐 호킹의 논리전개는 꽤나 매력적이었다. 그런 점이 이 책의 장점.

반대로 단점을 말해보자. 앞에서도 말했지만 너무 기본적인 얘기에 쏟은 시간에 비해, 상대적으로 궁굼한 영역(상세한 설명?)에 대해서는 설명이 수박 겉핥기가 아닌가 하는 의구심이 들긴 하다. 그러니까 별 5개는 못줄 책…

관련 글:

1. 리뷰: Complexity: A Guided Tour
2. 리뷰: The Design of Design
3. The Design of design 읽던 중에

SF 소설로, 지난 일주일 정도 동안 열심히 봤다. 사실 이건 빌려놓고 제대로 안 읽고 있다가 막상 돌려줘야 할 때가 되서 + Windows Vista->7 업그레이드 때문에 손놓고 있던 두 시간 정도의 여유 때문(???).

‘노인의 전쟁’을 다 읽고나니, 이 후속작도 있다는 소릴 듣고 열심히 읽고, 아마존 검색 결과 그 다음권도 있길래 냉큼 사서 봤음. 처음 두 권을 한글로 보고나니, 마지막 권은 영문으로 봐도 크게 어렵지 않더라.

많은 SF 소설들이,

“이런 상황이 되었을 때, 인간은 어떤 선택을 하느냐; 나중에 이런 문제가 닥쳐올 텐데 어떻게 할까”

라는 식의 얘기를 많이 하는데, 이 씨리즈에선 약간 다른 방향… 좀 더 오락적이랄까? 으로 나간다. 특히 첫 한 권이 그렇다…

이 아래 리뷰 내용에는 낮은 수준의 까발리기가 포함되어 있다. 그렇지만 본다고 저 세 권의 책을 읽는 재미가 줄어들 수준은 아니라고 생각한다.

첫 책에선 거의 세계관 전달에 촛점을 맞춘다. 인류가 우주 개척 시대에 돌입했지만, 지구는 거의 20세기 말 그대로 남아있고, 노인이 되면(75+) 우주 개척 방위군(CDF)에 자원해서 (뭔가 방법을 써서) 젊어지고 우주에서 싸우게 되는 구조가 된 상태를 설명한다. 그리고 이 전쟁(?)의 시대에 주인공이 자원해서 CDF에서 싸우기 시작하기 까지가 책 내용의 거의 절반에 해당한다.

그 와중에 지구의 인류와 우주에 나가 있는 인류(우주 개척 연맹; Colonial Union; CU)에 대한 얘기가 나오고, 앞으로의 씨리즈에 대한(…) 지구인 관점의 설명이 이어진다. 물론 주절주절 설명하는건 아니고 책 전체에 걸쳐 이걸 느끼게 해주는게 좋았음. 오락적으로도 훌륭한 것 같고.

좀 웃겼던 것(그리고 이 책의 이야기가 가능했던 것)은 CU에서 모든 기술을 거의 통제해서 지구의 기술 발전을 늦춘 것이 가능 하다는 것. 근데 정보는 일단 책에서 얘기하는 공간 도약없이는 광속보다 빨리 전달 할 수 없으니 그냥저냥 말이 되서 책은 계속 읽었다 – 궤도 엘리베이터(space elevator?)라거나, 공간 도약, 유전자 조작 병사, 의식(consciousness)의 이식 등등은 CU만 가지고 있는 상태. 우주에 나간 인류는 기타 지성있는 외계인들의 대립 구도(=만인에 대한 만인의 전쟁)에서 열심히 지식을 습득해서 엄한 속도로 발전해버렸다 정도로 설명을 해서 좀…

물론 1권 처럼 오락적인 면(=전쟁 씬이라거나 계략 구도 등등)도 괜찮았다. 다만 1권의 주인공은 3권이 되어야 나오는 건 좀 불만이었지만, 주인공 자체의 매력은 2권에만 나오는 주인공 자신이 꽤 괜찮았음. 시점도 3인칭으로 옮겨가긴 했지만;;

특히나 복제 인간 격인 존재들의 “자기 선택권”에 대해서 얘기하는건 꽤나 흥미로웠다.

그리고 우주 전체의 대립구도를 바꿔놓으면서 이야기 규모를 팍 키워놓고 2권이 끝나버린다. 야!!!!

여튼 1권의 주인공인 존 페리가 재등장하고, 이 존 페리가 새 개척 행성의 행정관(꼴랑 2500명이 이주하는 거긴하지만)이 되서 벌어지는 이야기와, 여기 담긴 음모, 그리고 전우주 규모의 대립이 3권의 내용.

2권 말미에서 잔뜩 벌여놓은 이야기를 잘 수습한다는 점에서 정말 잘 썼다고 생각한다. 사실 2권 읽고나면 벌어진 이야기의 크기 때문에, 3권이 있는걸 알고 안 읽을 수가 없음(…). 내가 1권에서 품었던 기술 격차 문제(CU vs. 지구)도 어떤 의미론 설명해주는게 이 3권이었던 듯 함.

궁굼한건(…) 3권 등장 인물 중에 Jane과 Zane이 있다. 한국어 번역판에선 어떻게 표기하려나?

여튼 이 책을 읽게 된건, 재밌다고 첫 책을 빌려 준 rica 덕분. 이 자리를 빌려 rica 에게 감사를.

PS. 근데 3권까지 봐도 콘수의 존재 의미는 안 밝혀집니다. 난 이게 제일 궁굼한데 Orz.

외전 격인 두 권의 책이 있긴 하지만 제목 자체가 약간의 까발리기이기도 하고 해서 여기선 언급하지 않는다. 다만 아마존 평점이 그닥이라(씨리즈 3권은 모두 4.5/5 수준의 높은 평점인데 이 건 2.5~3 수준) 안 읽을 가능성이 높음; 근데 소개된 줄거리 만으론 콘수 얘기는 없을 것 같다. 흑흑.

art.oriented의 김민장(object)님이 쓴 책이다. 한빛미디어의 Blog2Book 씨리즈 중 하나.

평소에 저 블로그를 구독하고 있다면, object 님이 전반적인 컴퓨터 구조와 최적화에 관해서 얘기하는 걸 여러 번 봤을 거다 – 구독하지 않고 있다면 RSS 리더에 추가하는 걸 추천! 잘 읽히는 블로그 글 솜씨만큼이나 책도 쉽게 읽을 수 있어서 좋았음.

이 책에서는 컴퓨터 구조, 특히 CPU 에서 명령어를 빨리 실행하기 위해 무엇을 하는지를 중심으로 현대 CPU의 여러 부분을 설명하고 있다. 간단히 읊어 보자면,

• 프로세서의 각 부분에 대한 설명
• 컴퓨터 성능 평가와 암달의 법칙
• 고성능 프로세서에 들어간 최적화 부분: 파이프라인, 비순차 실행, 하이퍼 스레딩, 멀티 코어 그리고 데이터 병렬성
• 분기문의 복잡함과 최적화: if 문, virtual function
• 멀티코어 CPU 혹은 SMP 아키텍쳐에서 벌어지는 몇 가지 문제들
• 느려터진 메모리의 최적화: 캐시와 메모리 계층 구조, 메모리 프리펫치

를 비롯해서, 이 포스팅에선 언급 안한 것도 잔뜩 포함해서, 컴퓨터 구조의 여러 내용을 설명하고 있다. 특히 상대적으로 쉬운 내용 – 프로세서의 나 각 실행/제어 단위에 대한 설명, 기본 개념에 대한 설명 – 부터 시작해서,  비순차 실행이라거나 분기 예측, 투기적 실행(speculative execution)처럼 학부 수준의 컴퓨터 구조 시간에는 간단히만 다루는 현대의 복잡한 CPU 구조의 부분부분을 설명해주기 때문에, 좀 어려울 수는 있어도 따라갈 수 없는 내용은 아니다.

물론 이 주제의 상당 부분은 학부 컴퓨터 구조와 컴파일러 시간에 배우는 내용보다 좀 더 최신이고, 상대적으로 좀 더 깊이 들어간 부분이 있기 때문에, 빈말로도 “쉽다”라곤 말 못하겠다. 그렇지만 학부 수업을 차근차근 듣는 기분으로, 찬찬히 살펴본다면 얻을게 정말 많다.

하드웨어 얘기이긴 하지만, 이 하드웨어가 우리가 만드는 소프트웨어와 직접적으로 연관이 있고, 하드웨어의 많은 부분은 소프트웨어 쪽 구현에도 영향을 준다. 책에서도 몇 번 강조하는 얘기지만, 여기서 설명하는 파이프라인의 개념은 여러 멀티스레드 프로그래밍에 나오는 개념이다(Task-parallel pattern; 잘하면 task+data parallel pattern도 됨). 비슷하게 메모리 미리 읽기(pre-fetch)나 캐시 활용 같은게 실제 응용 프로그램에서 쓰이는 사례는 말 안 해도 알 것이다. 그래서 “난 SW에만 관심이 있어!”라고 말하는 사람(=rein)들에게도 좋은 책이라고 생각한다.

비록 오자가 좀(…) 있다곤 하지만, 빠르게 업데이트 되고 있어서, 오자 페이지를 찾아가서 확인하면서 보면 괜찮을 거다;

rein은 이 책을 그레이트 코드 2권 같은 책에 매우 큰 흥미를 보였거나(…), 컴퓨터 구조에 대해서 알고 싶거나, 혹은 더 배우고 싶은 분들에게 매우매우 추천한다. 비슷한 이유로 팀 신입 사원들에게도 읽어보라고 권하고 있다

관련 글:

1. 멀티코어 활용할 방법이 정말 멀티스레딩 뿐이라고?
2. C# 잡상: 2011-03-04
3. 리뷰: Clean Code

현대 과학에 새로 생겨난(?) 분야 중 하나가 복잡계 과학이란 분야다. 이 책에서 얘기하는 것처럼 명확히 정의되지 않고, 그 경계도 모호한 분야지만 여러 분야 – 생물학, 물리학, 컴퓨터 과학, 수학, 기상학, … – 에서 나타나는 “복잡계” 때문에 많은 사람들에게 친숙(?)한 용어이긴 하다.

이미 번역된 책으로 이머전스, 딥 심플리시티, 링크(linked), 동시성의 과학 싱크(sync) 같은 많은 책이 나와있긴 한데, 좀 묶어서 나온 책이 없다고 생각해서, 추가로 읽게 된 책이다.

책 초반부에 이런 얘기가 나온다:

복잡성에 관한 “하나의 과학”은 아직 없다. 복잡성에 대해 서로 다른 정의를 갖는 몇 개의 서로 다른 과학이 있을 뿐이다. 이 정의(notion)은 일부분에선 매우 수학적(formal)이고, 일부에선 그렇지 않다. 만약 여러 복잡성의 과학이 “하나의” 복잡성의 과학이 된다면, 이 서로 다른 정의가 어떤 관계인지 알게 될 것이다.

즉, 아직 “충분히 연구되지 않아서” 명확히 정의 내리긴 어렵고, 각각의 분야에서 서로 다른 생각을 하고 있다는 것. 그리고 이런 분야에 관해 저자가 하나하나 설명하는 식으로 책이 진행된다(…).

책 전반에서는 “복잡성”의 의미를 저자가 생각하는 몇 가지 카테고리로 나누고, 이에 대한 예를 굉장히 많이 든다. 링크에서 얘기했던 스케일 없는 네트워크 비슷한 내용이라거나, 여러 분야에서 공통으로 반복되는 상수라거나 구조 등등. 일단 복잡성 자체를 “계산”이라는 (그래도 불명확하지만) 의미로 묶고, 이에 대해서 잘 쪼개서 설명하고 있다.

책 자체는 굉장히 쉬운 문체로 쓰여 있어서 술술 잘 읽힌다. 내가 컴퓨터 공학 전공이라 그런지 “복잡계”의 특성으로 “계산”을 가지고 얘기하는 게 꽤나 편하게 들렸다. “파인만의 엉뚱 발랄한 컴퓨터 강의”에서 얘기하는 “계산”의 특성에 관한 내용과 열역학 제 2법칙에 관한 내용도 다루는데, 이 책은 설명이 좀 부실하다. 파인만의 ~~~ 책 쪽이 훨씬 설명이 나음. 더불어, 몇 가지 컴퓨터 공학의 경계(frontier)에 해당할 “유전 알고리즘”이라거나 “셀룰러 오토마타; 세포 자동자”에 관한 얘기도 많이 다룬다. 매스매티카의 울프람 씨 얘기도 많이 나오고, 유전 알고리즘으로 최적화된 셀룰러 오토마톤을 찾는 얘기도 나온다.

다만 저자 자신의 박사 논문에 해당하는 copycat 프로그램을 다루는 절은 좀 지루했다. 스킵해도 뒤에선 별 차이 없더라…

책 자체가 복잡성 과학이 적용된 몇 가지 분야에 대해서 예를 많이 든다는 점은 매우 큰 장점인 듯 하다. . 전산학(계산; 자기복제; 셀룰러 오토마타; 유전알고리즘…), 생물학(유전; 발생; 신경계; …) 등등이 이에 해당. 그래서 상대적으로 저자의 말을 이해 하는 게 쉬웠다. 이런 류의 책의 주 독자층은 적어도 한 두 분야는 약간씩 접해보았거나, 자기 전공과 관련이 있을 테니 꽤나 보기 쉽게 만들어줄 듯 하다.

덤으로 마지막 장에서 저자가 “이 복잡성 과학이 쓸모 없다는 반론이 있지만 나는 그렇지 않을 거라 믿는다”라 말하고 있는데, 나는 대략 반반의 의견. 세부 분야가 정말 쪼개져버리거나 – 각 분야의 이해가 깊어지면서, 그 분야에 맞는 이론으로 고착화 되기 – 아니면 저자 말대로 하나의 과학 분야가 생겨나거나..

관련 글:

1. 리뷰: The Grand Design
2. 리뷰: 이중나선
3. 리뷰: The Greatest Show on Earth

The Myhtical Man-Month 의 저자 Frederick Brooks 의 신작이다.^[1]

일단 이 책은 부제인 “Essay from a Computer Scientist”에 나와 있듯, 일종의 에세이다. 저자의 사고를 일정한 순서로 풀어놓고, 이를 묶어서 책으로 만든 느낌이다.

이 책에서는 “디자인”을 어떻게 하는가 – 그러니까 디자인(설계)을 어떻게 설계해야 하는가 – 를 다룬다. 좀 불명확하긴 하지만, 디자인이 뭔지, 그리고 여기에 들어가는 사람들이 어떻게 사고하며 (이를 위한 SW는 어떤지, 이걸 써본 결과는 어땠는지), 그리고 어떻게 상호작용하는 지도 다룬다. 더불어, 디자인에 영향을 주는 요소들 – 자원(예산), 제약 사항 등등 – 도 다룬다.

물론 이 디자인을 하기 위해 뭘 어떻게 배워야 하는지. 우리가 배울 수 있는 예제들은 어떤지, 그리고 그걸 배우곤 있는 지라거나 등등에 관해서도 열심히 얘기한다. 마지막으로 이 내용들을 몇 가지 사례(컴퓨터 관련, 건축 관련, 책 관련…)를 들어 설명한다.

저자인 브룩스가 IBM의 통합된 형식(프로그래밍 모델이라거나, OS라거나 …)의 컴퓨터 군으론 최초로, 거대한 성공을 이룬 IBM System 360 을 설계 책임자여서인지는 모르겠지만, 여기서 얻은 경험을 예제로 여러 번 들고 있으며, 컴퓨터 구조 및 OS 설계 과정을 케이스 스터디로 각각 다루고 있다.

개인적으로 가장 의미심장 했던 대목을 다루자면,

성공적인 디자인은 공통적으로 이런 패턴을 갖는다: 물리적으로 격리; 작은 팀; 극도의 집중; 한 명의 리더십. 특히 (특정 설계의) 후속 디자인에 비해 어떤 획기적인 디자인에서 이게 반복적으로 나타난다. 예로, Joe Mitchell의 스핏파이어 팀이나, U-2와 F-117을 만든 켈리 존슨의 스컹크 웍스(Skunk Works), 애플에 대항하기 위해 PC를 설계했던 IBM의 격리된 lab이 있다.

이거랑 직접적인 대응은 아니지만, 중간에 다룬 내용으로, system 360 의 아키텍처를 정하기 위해 13 개의 서브 팀으로 쪼갠 후 경쟁 시켰다는 대목이 나온다. 즉, 작은 팀(1~3명)으로 / 격리 시키고 / 단기에 집중 시켜서 얻어낸 결과로 결론을 내렸다는 것. 가장 좋았던 두 개의 후보의 차이는 나머지는 거의 차이가 없고, 6bit 바이트일지 8bit 바이트일지 였다고…

그리고 보론처럼 들어간 게,

저자가 본 모든 팀 프로젝트에서, 디자인의 각 부분은 매 순간 한 사람만 다룬다. 그 한 사람이 그 부분에 대한 제안서를 준비한다. 그리고 동료들과 어떤 부분이 영향을 받는지 아주 작은 세션(micro-session)의 디자인 리뷰를 한다. 그리고 협력해서 내린 각 결정과 방향에 따라 세부 사항을 작업한다.

몇몇 개발 방법론에서 얘기하는 것 처럼, 코드 소유자가 있고, 그 부분을 각자 진행하는 시간이 있다는 것. Coders at Work에 나왔던 Erlang 개발 얘기도 이거랑 비슷한 느낌이 좀 있다.^[2]

덧. 책 내용 자체가 에세이라고 생각하면 상당히 가벼워지긴 하지만, 저자 자체가 갖는 이름값도 굉장하고 해서 좀 무겁게 읽었다. 왠지 이 책과 비교해서 번역서로 읽었던 Mythical Man-Month는 좀 거칠거칠했다는 느낌도 받게 되었음 – 그러니까 번역 후에 어조가 바뀐 느낌; 어쩌면 그 사이에 흘러버린 시간 때문일 수도 있지만.

덧2. 얼마 전에 이 책을 읽다 부끄러워졌다고 썼는데, 이 책에선 디자이너를 어떻게 하면 잘 키워낼까를 얘기하면서 많은 예제들을 보라고 한다. 그래서 나 지금은 좀 하고 있나?(..)

1. 사실 4개월이나 지났지만…
2. 다만 이건 브룩스가 말하는 특별한 케이스 – 2 인 팀 – 이긴 하다

관련 글:

1. 리뷰: Driving Technical Change
2. 리뷰: The Grand Design
3. The Design of design 읽던 중에

Signal vs. Noise 라는 이름으로 37signals^[1] 에서 운영하는 블로그가 있다. 여 튼 이 블로그에 글을 쓰는 사람 중 두 명이, 상당 부분 블로그 내용에 가깝게 책을 썼고, 이게 3월에 발매되었다. 이 책을 산 이유 중 하나는 광고 문구로, “각 종 사업을 시작해보려는 사람, 사업 중인 사람, 혹은 전혀 그럴 생각이 없는 사람들을 대상으로 썼다” 라고 되어 있길래 대체 무슨 소린가 해서. Jeff Atwood라거나 Joel Spolsky 가 추천하는 것도 있었고 …

간단히 요약하자면, 책 저자들이 작은 회사 – 요새 유행하는 용어를 쓰자면 강소 기업? – 를 잘 운영하고 있어서 그런지, 그런 방향으로 “이걸 이렇게 생각해서 성공적이었다”는 식으로 강조하는 게 꽤 많고, 상당히 납득할만한 방식으로 서술해서 재미있게 봤다. 그리고 이걸 잘 돌려서 생각하면, 그냥 고용인 입장에서 봐도 납득할 만한 + 스스로 실천해볼만한 사항이 많다. 그래서 이 책의 권장(혹은 광고 대상?) 독자 층이 저렇게 잡히는 거 같지만.

책은 별로 길지 않다. 본문을 인용하자면,

Lots of things get better as the get shorter. Directors cut good scenes to make a great movie. (중략) We cut this book in half between the next-to-last and final draft. From 57,000 words to about 27,000 words. Trust us, it’s better for it.

더 짧게 만들면 더 좋아지는 것들이 많다. 감독은 명작을 만들어내기 위해 좋은 씬들을 잘라 낸다. (중략). 이 책의 최종 원고와 그 직전 원고 사이에 거의 절반의 양을 잘라 냈다. 대략 5.7만 단어에서 2.7만 단어 수준으로 줄였다. 믿어보자, 이게 더 낫다.

(REWORK 의 Progress – Build half a product, not a half-assed product 에서 발췌; 모든 저작권은 REWORK 의 저자들에게 있다)

즉, 더 나은 책을 쓰려고 양을 반으로 줄여서 그리 길지 않은 – 종이 책 기준으로 약 280 페이지 – 책이 된 것. 덕분에 읽는데 일주일도 안 걸렸다(…). 그리고 많은 내용이 이들의 블로그에서 말한 내용이다. 완전히 같지는 않을지라도, 저 블로그 구독하고 있다면 많이 본 얘기들이 나온다. 뭐 이 책에서 말하는 “문화”란게 저런 거 겠지만;;

책 자체는 중 주제 몇 개를 소주제로 쪼개서 간결한 그림 한 장 + 설명 한 페이지 ~ 세 페이지 정도? 로 설명하고 있다. 여기서 이들의 경험을 기반으로 “어떻게 살아야(?)하는지” 얘기한다. 특히나 벤처, 특히 IT 벤처업계의 상식이(???) 된 얘기들에 반하는 내용을 꽤나 직설적으로 말한다.

처음부터 이익을 낼 수 있어야 한다거나, 몇 년 짜리 계획(혹은 사업 계획서)은 무의미하다거나. 상품만 파는 게 아니라 상품을 만들기 위한 지식도 팔고, 상품에 덤으로 나오는 것도 잘 팔면 된다거나.

벤처 캐피털의 도움을 받는 건 절대 하지 말아야 할 일(Plan Z)라고 부르고 있고, “작은 회사가 좋은 점”에 대해서도 꽤나 길게 몇 개 소주제로 역설한다. 그리고 역시 자신들의 경험에 빗대어 사람을 어떻게 뽑을지, 그리고 지리적으로 넓게 분산되어 있는 팀은 어떤 지도 얘기한다.

맘에 드는 대목을 몇 개 꼽자면,

아이디어는 매우 값싸고 많다. 맨 처음 아이디어 자체는 비즈니스 전체에서는 매우 작은 부분만 차지할 뿐이고, 거의 무시할 수준이다. 정말 중요한 것은 “얼마나 잘 실행하느냐”다.

Go – Start making something,

더 작은 질량을 갖고 간다고 생각하자. 지금 당장이 가장 작고, 군살을 뺀, 가장 빠른 상태며, 앞으론 점점 살이 붙게 된다. 그리고 점점 더 변화하기 힘들게 된다.

Go – Less mass

경쟁자보다 더 쓰고, 더 팔고, 혹은 더 후원하는 것보다 더 “가르치려고” 하라. 경쟁자는 생각조차 하지 않을 일이고, 이건 일반적인 마케팅 방법으론 얻을 수 없는 “유대감(bond)”을 만들어 줄 것이다.

Promotion – Out-teach your competition

사업가는 왜 더 크게 보이려고, 딱딱한 언어, 공식 발표, 만들어낸 친밀감, 법적인 것들 등등을 왜 쓰는가? 마치 로봇 같다. 즉, 당신과 대화 하려는 게 아니라, 당신에게 설교하려 든다.

읽을 만한 글을 쓰자. 쓰기 위한 글을 쓰면 안 된다. 뭔가 쓰고 난 후엔 크게 소리 내서 읽어라. 대화하는 것처럼 들리는가? 그렇지 않다면 더 대화문같이 수정하자.

Culture – Sound like you

역시 인용된 모든 문구의 저작권은 REWORK의 저자들에게 있다. 이 책 꽤 재미있게 읽었다. 갑자기 찾아온 여름이 덥기도 하니, 약간은 가볍게 읽고 싶은 책이 필요한 사람에게 추천한다.

1. Ruby on Rails 를 만든 회사이기도 하고, 몇 개의 사용하기 쉽고 간결한 툴들을 만든다. 사실 저 프레임웍 자체도 이 툴들 중 하나를 만들다 나온 것.

그리고는, 책장에 꽂힌 내 책(사진의 예쁘장한 파란색 하드커버 책)을 뽑으려고 한다. 김명수 교수님의 모 수업을 들었던 분들은 무슨 책인지 잘 아실 듯(…)

아들이 관심을 갖는 건, 학부 4학년 때? 던가 그 학기에 처음 개설된(…) 3학년 과목의 교재였던 Gilbert Strang 교수의 "Introduction to Applied Mathematics"란 책. 무광 파란색에 하얀 테두리가 맘에 드는 모양(?).

학부 4학년 봄 학기에 가장 많이 뒤져본 책이 아닐까 싶은데, 무겁고(…), 비쌌고!(한 달 생활비 1/4넘게 날아감), 심지어 거의 절판된(지금은 절판) 책이었는데, ‘수학 그게 뭔가요’하는 무지한 공대생들에게, 선형대수학…이라기보단 그 응용을 적절히 다뤄준 책.

심지어 첫 학기라고, 그 랩 박사과정 형님 + 석사과정 누님 한 분이 주말마다 연습문제 풀이도 해주셨음(하지만 토요일 오전 9시던가 10시의 압박은 실로 -ㅁ-)

덕분에 그 이후에 들었던 컴퓨터 애니메이션(…의 탈을 쓴 컴퓨터 그래픽스 + 선형대수학)은 쉽게 쉽게 들었다는 훈훈한 얘기가(???).

근데 아들은 파란색이 맘에 드는지 저 책을 뽑고 + 핥고 + 꾸깃꾸깃(그래 봐야 하드커버!) 하고 싶어한다.  아들아, 추억의 책은 좀 남겨주지 않으련? 절판돼서 아마존에서도 못 구한단다 Orz.

ps. 근데 Gilbert Strang으로 아마존 검색해보니 3년 전에 나온 Computational Science and Engineering 도 있다. 이것도 사서 연습문제 따라 천천히 읽어보고 싶어지네…

관련 글:

1. 제 아이가 태어났습니다

Mythical Man Month 의 Freidric Brooks 의 신작(작년에 나왔지만) The Design of design 을 요즘 읽고 있다.^[1] 반 쯤 읽은 상탠데, 반복해서 강조하는 내용 중 하나가,

디자이너는 자기 분야의 “모범적인 예제(exemplar)”들을 탐구하고, 연구하고, 그 안에 담긴 원리(rationale)를 이해하고 상황에 맞게 해석해야 한다.

의 내용이다.

좀 더 자세히 쓰자면, 해당 분야의 이론이 되는 근거들(컴퓨터 공학이라면 수학/논리학/전기 공학 …)를 충분히 배우는 것도 중요하고 실무의 내용도 알아야 하며, 이를 이해하기 위해 역사적인 모범 예제들을 탐구하라는 것. 그리고 이런 게 정규 교육 과정의 일부가 되어야 한다라는 건데.

학부시절을 생각해보면 이런 걸 제대로 접해본 적이 있나 싶어서 좀 부끄러워 졌음. 작게는 컴퓨터 프로그래밍으로, 조금 넓게는 어떤 서버의 구조를 생각하고 이걸 구현하는 일을 직업으로 삼고 있는데, 나는 얼마나 이 분야의 역사적인 사례(exemplar)에 대해 탐구해왔나 생각해보니 Orz.

학부 내내 코드를 자세히 읽어본 건 거의 최초 버전의 UNIX 운영체제^[2] , linux kernel^[3] 정도 뿐이다. 회사 와서는 이전에 작성된 서버코드를 여러 개(대략 4개?) 쯤 읽긴 했지만, 이건 빨리빨리 보느라 대충 봤으니…

뻔한 소리지만, 컴퓨터 공학 / 전산학 (Computer Engineering, Computer Science) 는 그렇게 역사가 오래된 분야가 아니다. 그런데도 나는 이 분야의 일부에 국한한 부분을 전문(?)으로 하면서도, 역사, 그리고 그 역사에 담긴 모범 예제들, 그리고 그 안에 담긴 생각들에 대해 너무나도 무지하다. 아직 젊다고 자위할 게 아니라, 좀 더 정진해서 배워야 할 필요가 매우 많다.

1. 다만 요즘 출근 시간을 앗싸리 땡겨 버려서, 차가 안막히다 보니(…) 진도가 좀 늦다
2. 수업기간의 1/3 기간 정도를 Lion’s code 라는 책을 가지고 소스 코드를 읽으면서 진행한 수업이 있다; 덤으로 동아리 스터디 + 자체 공부로 약간의 UNIX 내부(system V r4) 약간 공부한 수준이니
3. 2.4.x; 이것도 절반은 자의로 스터디하고, 나머지는 소스 코드 분석해서 문서화하는 알바 하면서 얻은 것

관련 글:

1. 프로그래머의 일상: 빌드 시간 얻기, 하드 링크, …
2. 리뷰: The Grand Design
3. 리뷰: The Design of Design

요즘 출근길에 년초 사놓고 읽다만(…), “A Field Guide for Science Writers: The Official Guide of the NASW” 를 이어서 읽고 있다. 오전에 읽은 부분이 책 중간 쯤의, 21절이Narrative Writing 였다. 이 절의에 초반부에 “이중 나선”의 첫대목이 소개 되어 있었다.

이중 나선 구조를 발견한 크릭, 왓슨, 윌킨스 중 왓슨이 직접 쓴 책인데, 왓슨 자신의 관점으로 “크릭은 이런 사람이다”라고 설명하는 대목이 인용. 근데 이게 거의 절제된 소설 읽는 기분으로 착 감겨서 읽히길래, 퇴근길에 번역서를 질렀다. 원문이 좋아서인지, 번역이 매끄러워서인지는 알기 힘들지만(…), 퇴근길 버스 안 + 자기 전 책읽기고 후다닥 읽어버렸다.

DNA가 이중 나선 구조라는 것은 현재는 매우 잘 알려진 사실이지만, 50년 전만 해도 과학자들이 이 구조를 찾느라 정말 강력하게 경쟁했다. 이 경쟁 와중에 당시 박사 후 연구원이었던 왓슨이 크릭을 만나고, 윌킨스의 X선 회절 실험에 의존하고, 놀고(…), 운동하고, 여자 만나러 다니고, … 그리고 DNA 구조를 추적해 나가는 과정을 –정말 소설처럼 흥미 진진하게 – 책으로 썼다.

이 구조를 찾기 위해, 연구하고, 좌절하고, 좌절하고, 연구하고 … 하다가 최종적으로 상보적인 결합을 이루는 “아름다운 구조”를 발견하기 까지의 이야기를 1인칭 주인공 시점으로(당연한거지만), 써내려가는데 열심히 따라 읽게 만드는 마력이 있다.

폴링이 추정한 단순한 alpha-helix 에서 시작해서, 복잡한 삼중 나선, 그리고 (잘못된 염기 결합을 가정한) 2중 나선, 그리고 다시 생각해서 얻어낸 상보적인 이중 나선. 이 과정을 저자의 사고 흐름, 크릭이나 윌킨스 혹은 프랭클린 같은 주변 인물과의 대화 등등으로 잘 이어나가서, 재미있게 읽을 수 있었다 – 사실 책이 좀 짧다.

지금의 우리들이 생각하기에야 상보적인 이중 나선이 당연한거였지만, X선 회절법을 (계속해서 발전시키면서) 어떤 구조인지(사실 나선에 대한 합의(?)도 책 중간에야 나옴) 짐작도 가지 않는 상황에서 추적해 나가는 과정이란건 꽤나 힘들었을 것이다.

하지만 수학의 수 많은 정리, 많은 물리학 이론이나 좋은(…) 자료구조가 그렇듯이, 완성된 무언가의 아름다움은 정말 각별한듯 싶다.

관련 글:

1. 리뷰: The Grand Design
2. 리뷰: Complexity: A Guided Tour
3. 무신론자를 위한 크리스마스 가이드

책 제목이 참 괜찮게 한글화 된 듯하다. 그래서 산거지만(…)

일단 86 가지의 “팀 (행동) 유형”에 관해서 4 명의 저자들이 (어떻게 보면 굉장히) 가볍게 다룬다. 각 항목마다,

• 항목의 제목(과 그에 해당하는 원본 책의 제목)
• 그에 해당하는 사진 혹은 그림
• 수 단어 ~ 수 줄 수준의 간단한 어구 인용, 혹은 내용 요약
• 본 내용 1~3 페이지 정도.

의 형식으로 다룬다. 덕분에 지하철 2정거장 이동 –> (환승) –> 3정거장 이동인 출/퇴근 길에 끊기는 느낌없이 참 편안히 볼 수 있었다.

인상 깊은 항목이거나, 내가 재밌게 본 항목을 몇 개 인용해보겠다.

7번째 항목 내일(Mãnana)에서는 “막연한 내일”의 문제를 다룬다. “일을 끝내기 위한 긴박감을 느끼는 기간은 약 30일에서 90일”인데, 이에 해당하는 기간이 아니라 막연한 마감시한인 경우(저보다 긴 데드라인), 긴박감을 느낄 수 없다는 문제. 그래서 이걸 잘게 나눠서, 각 기간마다 결과물(프로토타입, 특정 기능집합 …)을 내놓게 해야한다고 설명한다.

이런 식으로 각 문제, 혹은 현상(?)을 가볍게 다루면서 86개의 항목이 나온다. 안 지루하고, 프로젝트 문제점을 지적하는 여러 책들에 비해 상대적으로 통찰력도 주는 느낌이고, 쪼개보기 좋아서 편하게 봤다.

유쾌하게 봤던 항목을 몇 개 꼽자면,

• 16, 대시보드 – 일종의 정보 방열판. 다만 정보과잉은 피할 것.
• 60, 음식++ – 팀원들이 모여서 식사를 하라. 심지어 음식을 만들어먹어라!^[1]
• 67, 십자 나사 – 좋은 아이디어라고 빨리 퍼지는 건 아니다. 이건 회사들어가기 전에 품었던 생각 중 일부를 실제로 실현하는데 걸린 시간을 생각하면 Orz
• 70, 브라운 운동 – 방향성을 응집성 있게 세우는 건 중요하다. 특히 초기에. C++은 한 명이 만들었다. linux도, python도, … 위원회가 만든 ada의 현재 운명은…(하략)
• 80, 해외 개발팀 함정 – L? 전자에서 일하던 친구 A군의 증언이랑 비교해서 생각하니, “이렇게 멍청하게 하는게 정말 실제 사례군”이란 느낌을 받았다

정도? 사실 나머지도 다 유쾌함; 실제 상황이라면 무진장 괴롭겠지만…

예전에 “초난감 기업의 조건”을 읽었을 때 느꼈던, “그래서 어쩌라고?”하는 느낌도 좀 덜해서 – 각 현상의 냄새에 관한 언급이 적절히 끼어들어가 있다 – 어느 정도 추천할만한 책인듯 싶다.

1. 미야자키 하야오 감독이 “센과 치히로의 행방불명”을 제작하던 때에, 돌아가면서 음식을 만들었다는데, 감독 자신도 국수를 만들어 내놨다고 한다;;;; 근데 책에는 센과 히치로라고 오타가 있다. 흑흑

관련 글:

1. 프로그래머의 일상: 빌드 시간 얻기, 하드 링크, …
2. 리뷰: Driving Technical Change
3. 특정 디렉터리 밑의 모든 솔루션 빌드하기

Peter Seibel 의 coders at work 완독. 현업에 있는 / 있었던 유명 프로그래머 – 이쪽 업계에선 여러가지 의미로 슈퍼 스타 – 들의 인터뷰 15개를 엮어놓은 책이다.

인터뷰한 사람들의 면면을 살펴보면, 학계에 있던 사람부터 시작해서 (Knuth 교수라거나 haskell 의 Simon. Peyton-Jones, Guy Steel 등등), 업계에서 처음부터 지금까지 일해온 사람들(Live Journal을 만든 Fitzpatrick, 넷스케이프의 Zawanski, JSON의 Crockford, JavaScript의 Eich, Java Collections 의 저자 Bloch 등등) 혹은 양쪽 다에서 업적을 쌓은 사람들(AI 책의 저자이면서 구글의 리서치 디렉터인 Peter Norvig, UNIX와 C의 Ken Tompson 등등) 을 포함한다.

사실 이렇게 넓은 스펙트럼을 다루고 있어서인지, 프로그래밍에 관한 관점, 프로그래밍에 요구하는 관점, 어떤 언어가 필요한지, 자기 자신을 과학자/공학자/장인(craftsman)/예술가 중 무엇으로 보는지, 얼마나 수학을 해야하는지에 대한 생각이 각자 다르다. Literate Programming에 관해서는 대부분 괜찮지만 난 Knuth 수준으로 안해봤다가 대세였음…

일단 각 사람들이 다루는 분야가 프로그래밍 언어(C, Haskell, Smalltalk, Erlang, JavaScript, Fortress) 나 그에 밀접한 영역(Compiler, Interperter, EMACS(?), Java Collections)이거나, 아니면 현재 우리가 사용하는 시스템의 밑단(UNIX, ARPANET) 인 경우가 대부분이다. 어떤 의미로는 우리 시대의 – 적어도 컴퓨터 공학/전산학 분야에서는 – rocket science 인 듯…

프로그래머가 가져야하는 자질로,

• 간단함, 명료함에 대한 추구
• 자세한 것을 다룰 것
• 추상화 해서 생각할 것
• 수학적인 지식(분석적인 면 말고, 구성적(synthetic)인 면에서)
• 새로운 분야에 대해 호기심을 가질 것

등을 말하고 있다.

다만 실제로 프로그래밍에 임하는 자세에는, “실제로 코드가 동작하고 이를 유지한다” 쪽에 치중하는 계열이 있고, “(API 적인) 명료한 인터페이스를 생각하고, 이를 잘 지지할 테스트를 만든다” 라는 사람들도 있었다. 그리고 정말 극단적으로는, 모든 코드를 종이 위에 작성하고 이걸 만들었더니 거의 버그가 없었다는 Knuth의 TeX도 있다. 허허허(…)

그리고 자기가 일하는 형태에 따라 자기가 과학자 혹은 공학자로 생각하는 경우가 많았고, 대부분 장인과 예술가 적인 면을 가지고 있다고 말했다. 많은 사람들이 C++ 의 거대해진 면에 대해서 비판적이었고, C/C++/Java 그리고 묵시적인 면에서는 python 등도 포함해서 포인터 기반의 연산을 가지고 있는 자체에 대해서 불만을 표시하기도 했다 – 그리고 이 인터뷰 내용을 다른 인터뷰 당하는 사람한테 말하고 반론이 나오기도 해서 꽤나 흥미로웠다(…).

인상적인 구절이 너무 많아서 – 예전에 Peter Norvig이 말한건 간단히 포스팅 했다 – 인용 + 인상 정리로 한 달은 우려먹을 수 있을 것 같지만 이건 이 책 읽을 이들의 즐거움을 위해서 패스하고, 내 맘에 든(…) 구절을 몇 개 정리해보겠다.

Zawanski: I was kind of freaked outwhen I realized that there are people graduating with CS degrees who’d never written C.

Joel Spolsky 가 말하는 거랑 비슷한 의미.

Fitzpatrick: The thing that annoys me about Java is that everyone has such a strong aversion to JNI stuff. Sometimes a library is in C++. The Python people – in the outside community and inside Google – don’t care. They’re like, “Oh, we’ll, SWIG-wrap-it.” They get on their way and they’re happy. Python gets support for something right away if it’s in C++ because they’re not religious about what the source language is.

Java people are like, “Must be pure Java. We cannot use JNI because then if the JVM crashes, we don’t know why.” The problem with that is you end up writing everythin twice, once for C++ and Python and all the other languages, and the once for Java. So if they could come up with a good embedding story or get over this fear of JNI, then I wouldn’t mind it.

Java를 쓰는 사람들이 “그냥 SWIG 래핑해서 쓰지”하는 Python 계열의 사람들과 달리, “JNI가 아니라서 크래시 나면 어딘지 알수 없잖아”라고 해서 라이브러리를 두번 작성한다고 불평. 다만 Java가 더 좋은 임베딩 방법을 찾거나, JNI 문제에 덜 신경쓰게 되면 좋겠단다… 이래서 내가 C++/Python 패러다임에 살고 있는지도.

Bloch: Even today, writing unit tests for concurrency utilities is an art form.

Mutex 버그로 고생했던 기억을 회상하면서, “병행성을 다루는 도구의 유닛 테스트를 작성하는건 아직도 예술의 영역이다”라고 말하고 있다 ㅠㅠ. 회사에서 내가짜는 유닛 테스트 중에 병행성 테스트는 없다(…). 그냥 부하 잔뜩 걸어서 테스트해보는 정도?-0-

Erlang 의 저자인 Joe Armstrong은 코드 재사용성의 문제가 OOP에 있다고 생각한다.

I think the lack of reusability comes in OO langueages, not in functional languages. Because the problem with OO languages is the’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

코드 재사용성을 (어느정도는) 강조하는 OOP지만, 실제적으론 묵시적으로 들고다니는 환경 때문에 너무 많은 의존성을 낳아 오히려 재사용이 안되고 함수형 언어에는 그런 문제가 없다는 것. 덤으로, 난 erlang을 함수형 언어로만 생각했는데, Armstrong 인터뷰에서 가장 많은 영향을 준 언어는 prolog 라고 말한다. PL 시간에 쌩고생 시킨 그 언어가 Orz

적절히 인용할 부분을 찾진 못하겠지만(…), SSA (컴파일러 이론의 static single assignment) 를 생각해내기도하고, 첫번째 튜링 어워드를 받은 여성인 Fran Allen은 “C의 성공 때문에 컴파일러가 최적화할 여지가 없거나 적은 언어들이 주류 언어가 되어버렸다”라고 비판했다. 즉, 좀 더 고수준의 언어를 가지고 만들어야 컴퓨터 공학이 발전할텐데, 시스템 프로그래밍 언어였던 C가 크나큰 성공을 거둬서 앞으로 갈 길이 너무 멀고, 발전이 너무 더디다라고 말한다.

이건 Python 도 저수준 언어의 기능 – 명시적인 메모리 공간에 대한 모델 – 이 있기에 겪을 수 있는 문제가 있는걸 생각하면, 약간은 수긍이 가는 듯도…

여기에 대해 ARPANET의 초기 구현을 작성한 Bernie Cossell은, 어셈블리어 프로그래밍을 하던 사람들에게 C의 표현력은 신선한 공기와 같아서 어쩔 수 없었고, 그 표현력과 저수준 지원 때문에 C는 다른 모든 언어 – 심지어 DoD가 우리와 계약하려면 Ada를 써라! 라고 했는데도 C가 더더욱 번성해버릴 정도로 – 보다 더 널리 쓰였다고 변호한다.

여튼 더 인용하고 싶은 문장은 매우 많지만, Bloch의 인터뷰를 인용해서, 내가 이 직업에 있는 이유를 설명해놓고 리뷰를 끝낸다.

What we’re doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills – all of these things that we don’t necessarily thik of as engineering but without which I don’t hink you’ll ever be a really good engineer. So I thik it’s just something that we have to remind ourselves of. But I think it’s one of the most fun jobs on the planet. I think we’re really lucky to have grown up at the time that we did when these skills led to these jobs. I don’t know what we would have been doing a few generations back.

우리가 하고 있는 일은 미적인 추구다. 우리가 하는 일은 장인 정신 뿐만 아니라 수학과 사회적인 기술과, 글 쓰는 기술을 모두 필요로 한다. 이 모든게 공학에 꼭 필요한 거라고 생각되진 않지만, 이것 없이는 정말 뛰어난 공학자가 될 수 없다. 그래서 난 이것들이 우리가 상기해야할 무언가라고 생각한다. 그렇지만 난 이 일이 세상에서 가장 재밌는 일 중 하나라고 생각한다. 우리가 이 기술을 가지고 이 직업을 갖게만든 시대에 태어난걸 행운이라 생각한다. 만약 수 세대 전에 태어났다면 난 내가 뭘 하고 있을지 상상도 못하겠다.

컴퓨터 공학을 전공하고, “뭔가를 만들어보고 싶다”는 열망이 있다면 꼭 한 번 읽어보라고 권하고 싶은 책이다. 다만 다루는 내용으로 볼 때 이거 한국어판이 나올 수 있을까?-_-;

관련 글:

1. 2011, 내 프로그래밍 언어는…
2. 리뷰: Driving Technical Change
3. 내가 서로 다른 언어로 프로그래밍할 때의 느낌

이 이하의 인용은 Norvig 이 인터뷰한 내용. 모든 저작권은 Seibel 및 출판사에 있다.

Norvig: I thik one of the most important things is being able to keep everythin in your head at once. If you can do that you have a much better chance of being successful. That makes a small program easier. For a bigger problem, you need extra tools to be able to handle that. It’s also import to know what you’re doing. When I wrote my Sudoku solver, some bloggers commented on that. They said, “Look at the contrast – here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve fogottent, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere. Hehad five different blog posts and in each on he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve problem.

한 TDD 구루와 자신이 작성한 수도쿠 솔버를 가지고 벌어진 논쟁에 대한 언급.^[2] 피터 노빅이 보기에 가장 중요한 것은 모든 것을 한 번에 머릿속에서 굴리는 것, 그리고 자신이 뭘 하고 있는지를 아는 것. 그래서 TDD 가 도구가 아니라 목적이 되면 – 즉 테스트에 너무 집착하면 – 정작 해야하는 일, 문제 풀이에 집중하지 않게 되고 원하는 결과를 얻지 못할 수도 있다는 것.

물론 TDD 자체에 대한 반감은 아니라고 언급한다.

Then bloggers were arguing back and forth about what this means. I don’t think it means much of anything – I think test-driven design is great. I do that a lot more than I used to do. But you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution.

내 생각에도, 모든 소프트웨어 공학툴이 어떤 은탄환이 아니듯, TDD 역시 하나의 도구일 뿐이다. 도구가 강력하다고 모든 문제를 해결해주는 것이 아니니, 결국 우리가 해야하는 일은 “문제를 풀 수 있도록 자신을 갈고 닦는 일도 병행”하는 수 밖에 없다. 즉, 좋은 도구니까 잘 쓰면 좋을게다. 여기에 집착만 하지 않으면…

PS. Coders at work를 읽고나서 나랑 비슷한 글을 쓴 사람들이 꽤 있다.

1. 피터 노빅은 현재 Google의 연구 디렉터(Director of Research)다.
2. 이 논쟁글은 Learning from Sudoku solver, How to not solve a sudoku, Solving Sudoku with TDD 에 있다. 여기서 피터 노빅이 이름을 기억하지 못한다는 TDD 구르는 론 제프리스(Ron Jeffries)로, XP의 창안자 중 한 명이며, XP installed의 저자다.

관련 글:

1. The Design of design 읽던 중에
2. 리뷰: Coders at Work
3. 내가 원하는 test-runner 의 조건

예전에도 iPhone/iPod touch 용 응용프로그램으로 존재했었지만, 가장 저변이 넓을(…) 기기인 PC로도 나오게 된 것. 곧 Mac 버젼도 나온다한다.

일단 스크린 샷 부터.

초기 화면(Home)^[1]

실제 책 읽는 화면^[2]

Kindle or Kindle DX의 Home 화면 느낌에 각 책의 표지가 추가된 형태로 첫 페이지가 뜬다. Archived Items 역시 Kindle 자체와 동일한 기능을 수행한다. 자기가 구입한 책들을 저기서 확인한 후 Home 으로 가져오면 로컬 PC에 저장된다.

Kindle for iPhone/iPod touch는 안써봐서 모르겠지만, Kindle for PC도 Kindle 용으로 구입한 책을 받으려면 사용자 인증(amazon.com 로그인)이 필요하다. 그리고 Amazon.com에서 구입한 책만 나타나서 pragpub 등지에서 구입한 녀석들은 여기 안보인다 ;ㅁ;

전체적인 사용자 경험은 Kindle 의 PC 이식이란 느낌이 될 듯. 심지어 메뉴 구성이나, 바로 접근할 수 있는 설정 키들이 Kindle 판박이다(글자 크기 조절이라거나). 다만 직접 사용자가 조작하기 편한 Kindle과 달리 PC 키보드/마우스로는 조금 불편한듯도 싶다. 게다가 창 크기를 조절하면 좌우의 마진은 전혀 줄어들지 않는다거나 =_=;;

한국 내에서 쓰고 있을 때의 문제지만(Kindle 2 international edition을 구입한 사람은 쓸 수 있는 기능이라 상관없는 얘기지만), 위스퍼 넷을 통해서 읽은 범위/북마크 등을 동기화해주는데, 이 기능은 못 씀.

곧 기능에 추가된다는 것들 = 아직 없는 기능들이 나와있는데, 책 내부를 검색하는 기능도 현재는 빠져있다. 그리고 (기기 쪽에서 남긴)북마크나 노트를 볼 수 는 있지만, 이걸 PC 버젼에서 기록하지는 못하고, PC 버젼에서 무척 구현하기 쉬울듯한 이미지 확대/회전도 안된다고 한다.

여튼 정식 릴리즈를 기다려줘야할듯; 근데 텍스트 긁어서 복사하는건 DRM 문제 때문인지 아마 앞으로도 안 될 것 같긴하다; 프로그래밍 책은 저게 되야 편하긴한데;;

1. 각 표지의 저작권은 출판사 혹은 원저작자에 있습니다
2. 이 책의 저작권은 Joel Spolsky에 있습니다

관련 글:

1. Amazon Kindle International 출시
2. Kindle DX 와 함께한 한 주
3. Amazon Kindle DX 도착

여러가지 의미에서 Kent Beck의 Implementation Patterns 과 비슷한 느낌의 책이다.

우리가 다루는 프로그래밍 추상화 단계 – 각 단위의 이름(변수나 함수, 클래스 등등…), 실행문(statement), 함수, 클래스, 시스템 레벨에서 어떻게 하면 “쉽게 읽고, 이해하고, 변경할 수 있는” 코드를 짤 수 있는지 설명한다. 그리고 comment나 클래스 설계 원칙에 대한 일반론들(open-closed principle, single responsibility principle…) 역시 다룬다. 사실 일종의 best-practice 북인 셈?

하지만 단순한 이런 류의 책에서 더 나아가서 – 개인적으론 이 부분이 Kent Beck의 Implementation Pattenrs 보다 훨씬 나은 점인 것 같다; 사실 TDD by examples 같은 느낌이기도 하다 – 실제 코드 (JUnit에서 따온 것도 있고, SerialiDate 클래스 같은 것도 있고 … ) 를 점진적으로 개선하는 실제 작업 내용을 한 단계씩 차근차근 밟아가면서 비교해주는 점이 좋았다. “나쁜 ???”에 해당하는 예를 적절히 보여준다는 것도 장점. 특히나 이것들을 “실제로 동작하는 프로그램”에서 가져온다는 점이 아주 좋음…

병행성(concurrency)에 대해서 다루는 부분도 읽을만 했다 – 물론 단점이 꽤 있다. 특히 처음 인용한,

“Objects are abstractions of processing. Threads are abstractions of schedule”

은 꽤나 맘에 듬.

곧 번역서가 나올 것이란 얘기도 있으니, 발간되고 나면 한 번 읽어보는 것도 괜찮겠다.

하지만 이 책에 단점이 없는 것은 아니다. 일단, 이건 개인적인거지만 Java 에 완전히 종속적인 부분이 나오며, 다른 언어에 대한 추가 고려는 없다(…). 그리고 첫 장에서 저자가 설명하듯이,

“모든 내용에 대해서 독자들이 동의할 거라곤 생각하지 않는다.”

에 해당하는게 꽤 보였다. 사실 그게 크게 작용한 것은 병행성 부분. 13 장과 부록에서 크게 다루고 있는데, 저자가 너무 지엽적인데 목매달고 있으며, library와 잘 알려진 concurrent data-structure/model을 쓰라고 하면서도, 정작 중요한(적어도 현재는) Java Executor Services에 대해선 너무 짧게 다룬다. Producer-consumer나 reader-writer 문제 같이 OS 시간에 다뤄서 충분할 내용들을 길게 다루고, 현재 OS나 platform 단에서 잘 정의해서 쓸 수있게 만든 executor service 나 Future construct에 해당하는 녀석들은 제대로 다뤄주지도 않는다.

실제로 여기서 설명하는 것들 – 공유 변수의 ++ 문제 – 같은 건 그냥 병행성 입문 교재에서 다루는 정도도 충분하다. 이 책의 다른 부분들 – 정도의 차이가 꽤 크긴 하지만 – 수준으로 다뤄졌어야 한다. 특히 병행성이 어떻게 구현될 수 있는지 – data parallel, task parallel … – 같은 부분은 거의 생략하면서, 실행 순서 문제나, lock 의 가벼운 정도(Java 5의 AtomicInteger vs. synchronized construct) 주제는 너무 길게 다루고, 큰 의미도 없다. 사실 더 중요한 캐시 친화적인 프로그래밍 같은건 싹 빠졌음 Orz.

실제로 synchronized 대신에 Atomic???  류를 쓰는 것이 좋긴 하다. 그렇지만 더 중요한 것은 lock 의 세밀함(coarse-grained vs. fine grained)이나, lock 자체를 피해갈 수 있는 전반적인 프레임웍 문제지, 지엽적인 주제에 집착하는 것은 그닥 좋지 않다. 이 부분의 저자가 컨설턴트인데 이러는 것도 좀 그렇긴하다(…).

차라리 이 부분은 적당히 건너뛰고, Art of concurrency나 Patterns for Parallel Programming, 혹은 Java Concurrency in Practice 같은 책을 보는게 이 항목에 대해선 좋은 선택인 듯 싶다.

총평: 일부 동의할 수 없는 내용이나, 미진한 내용(개인적으론 concurrency 부분의 두 챕터)이 있긴하지만, 전반적으로 괜찮은 책이니, 시간이 되면 한 번 읽어보시라.

관련 글:

1. 리뷰: 프로그래머가 몰랐던 멀티코어 CPU 이야기
2. 리뷰: Coders at Work

Kindle Wireless Reading Device (6″ Display, U.S. & International Wireless, Latest Generation)

현재는 일단 preorder(선주문) 받는 상태. 2 주 후에 실제 제품이 배송되기 시작한다고 한다.

해외에서 HSDPA 모뎀을 사용해서 컨텐츠를 구입/다운로드 할 수 있는 킨들이 생긴 것. 이 모델은 Kindle 2에 대응한다. 6″ 디스플레이로 아이리버에서 나온 스토리랑 크기가 같다.

가격은 북미 전용 모델은 $259, 해외에서도 쓸 수 있는 모델은 $279다. 한화로 325,175원 정도.
한국은 현재 아마존이 들어와있지 않고, MVNO 사업자도 없기 때문에, HSDPA 모뎀은 사용가능한 국가지만 킨들의 무선 컨텐츠 망은 쓸 수 없다.

이웃나라인 일본의 경우엔 amazon japan이 입점해 있고, 무선 사업자랑 파트너쉽도 맺었는지 바로 서비스가 시작될거라고 한다.

그리고 미국 외의 IP 주소로 아마존에서 킨들 컨텐츠를 살 수 없게 되었다. 정확히는 주소를 선택하는 메뉴가 뜬다. 여기에서 현재 내 IP에 해당하는 주소(한국 주소)로 했더니, 아시아-태평양 지역으로 선택되면서, 모든 책의 가격이 $2씩 오른다 ㅠㅠ.

이제 $9.99에 사던 책들이 죄다 $11.99 Orz.

Updated. 아마 추가되는 $2는 HSDPA로 전송하는 요금일듯? 파트너 사와 계약에 따라 다르겠지만(물론 일본같이 아마존이 들어가 있으면 MVNO 사업을 해버리겠지만), 대략 망사용료를 겨우 충당하는 수준일듯. 과연 한국에서 $2로 800KiB에서 1.7MiB쯤하는 책들을 전송할 수 있을까? 일단 아마존에서 설명하는 Wireless coverage area 에는 한국이 들어가있지만(3G 망), 이건 그냥 들어간단 소리지 당장 서비스 된단 소리는 아닐거 같긴하다;;

관련 글:

1. iPad 단상
2. Kindle for PC beta released
3. 독서 잡담: 2009년 9월 11일