알아가는 즐거움 » programming

LDA 실습: 이 블로그의 주제는?

SL — Sun, 14 Nov 2010 12:42:22 +0000

LDA(Latent Dirichlet Allocation)로 검색하다가 아이추판다님 블로그에서 재미난 글을 발견하고 나도 따라 해봤다.

블로그를 시작한 2007년 8월 27일부터 지금까지 작성한 총 136개 포스트를 대상으로 LDA를 돌렸다. 더 이상 직접 구현해 본답시고 삽질하지 않기로 했으므로 인터넷에서 파이썬으로 구현된 LDA 코드를 구했다. 한글 문서를 다룰 때 항상 문제가 되는 어근 추출은 국민대학교 강승식 교수님이 공개한 형태소분석기를 사용해 명사만 뽑는 방식으로 해결했다. 이걸로 준비는 끝, 결과를 살펴보자.

우선, 이 블로그의 주제는?

LDA가 주제의 개수까지 자동으로 찾아주지는 않는다…만 어차피 내가 쓰는 글은 다 거기서 거기이므로 주제 개수를 4 ~ 6개로 돌려보고 가장 그럴듯한 결과를 내는 5로 정했다. 3년 넘게 운영했는데 주제가 고작 5개라니.. 과연 편협한 블로그가 아닌가 ㅋㅋ¹

아래는 주제별로 관련성이 높게 나온 단어 목록이다.

주제 1: 시간 영화 이야기 우리 정도 보고 하나 무척 사진 기억 모습 스스로 아들 느낌 결국
주제 2: 책 저자 내용 이해 설명 연구 필요 방식 우리 스스로 지금 컴퓨터 가장 시작 무엇
주제 3: 게임이론 위험 펀드 얼마 게임 수익 전략 예측 행동 결과 경제학 알파 이론 포트폴리오 시장
주제 4: 문서 논문 단어 검색 결과 쿼리 분류 키워드 클릭 얼마 사용자 알고리즘 표현 중요 방식
주제 5: 파일 프로그램 기능 검색 블로그 사용 사이트 태그 하나 관리 인터넷 인터페이스 얼마 입력 추가

LDA가 찾아낸 주제가 항상 명쾌하게 해석되는 건 아니지만 각 주제를 대충 아래와 같이 이름 지어도 될 것 같다.

주제 1: 감상 (영화, 경험)
주제 2: 독서
주제 3: 경제 / 경영 / 투자
주제 4: 검색 연구
주제 5: 컴퓨터: 소프트웨어, 유저 인터페이스, 블로그

흠, 꽤 그럴듯한걸 :)

다음으로, 주제의 변화, 즉 트렌드를 살펴보자!

각각의 글에 대한 주제 가중치의 변화 추이를 살펴보면 나의 관심이 어떻게 바뀌어왔는지를 알 수 있을 것이다. 윈도우 크기를 5로 잡아서 이동 평균(moving average) 그래프를 그렸다.

지난 3년의 기억이 주마등처럼 스쳐간다.

블로그를 개설하고 책 감상문을 열심히 올리다가 곧 시들해졌지만 최근에 다시 독후감 러쉬를 한 게 드러난다.
한때 프로그래밍이나 유저 인터페이스 관련 얘기를 한 덕분에 컴퓨터 주제가 상승세를 탔으나 이제는 완전 하락세로 들어섰다.
최근에는 투자 이론이나 독후감에 다소 주춤하지만, 그전까지만 해도 꽤 열심히 검색 관련 연구를 소개하곤 했었지.
이전에는 돈에 관련된 얘기는 가계부 정도밖에 없었는데, 현대 투자 이론(Modern Portfolio Theory)을 접하면서 투자나 펀드 평가, 또 게임이론 같은 데로 관심이 확장된 게 노란색 선에 나타난다.

그냥 재미로 시작했는데 이거 진짜로 재밌네. 엠티 끝나고 남은 시간에 혼자 연구소에서 코딩하고 있는 건 좀 안습이지만.

사실은 주제 개수를 10으로 해도 나름 의미있는 분류가 나오기는 하는데 그냥 해석 편의상…

Shoemaker’s Problem

SL — Sun, 28 Mar 2010 11:44:02 +0000

나의 시간과 에너지를 쏟아부을 뭔가가 필요한 꿀꿀한 일요일 오후, 이 문제를 풀기로 했다.

Shoemaker’s Problem

내일까지 못 풀면 팀원들에게 커피를 사야 하기 때문은 아니고(…) 진짜로 정신력을 소모할 거리가 필요했다. 정말로 진짜다.

벌금을 최소화하는 스케줄을 찾으라고? 어쩐지 Dynamic Programming의 향기가 난다. 그럼 일단 문제를 쪼개 보자. Job을 A, B, C, …라고 하고, {A, B, C}를 가장 효율적으로 처리했을 때의 벌금(fine) 총합을 S(ABC)라고 하면,

S(AB), S(BC), S(AC)는 쉽게 구할 수 있고,
S(ABC) = minimum( S(A) + S(BC) , S(B) + S(AC) , S(C) + S(AB) )
S(ABCD) = minimum( S(A) + S(BCD) , S(B) + S(ACD) , S(C) + S(ABD) , S(D) + S(BCD) )
…

응? 좀 이상한데? 전형적인 Dynamic Programming 문제라면 이런 식으로 경우의 수가 늘어나면 안 되는데.. 내가 잘못 짚었나?

그럼 Greedy Algorithm을 써보자. 매 선택의 순간마다 가장 벌금을 적게 내는 Job을 고르는 거다.

예제 문제에서 두 번째 (1, 1000)은 빼고

3 4 (Job A)
2 2 (Job B)
5 5 (Job C)

만 놓고 생각해보자.
A를 골랐을 때 포기해야 하는 벌금은 3 days * (2 + 5) cents = 21
B를 골랐을 때, 2 days * (4 + 5) cents = 18
C를 골랐을 때, 5 days * (4 + 2) cents = 30

그러면 B를 고르고, 다음에는

3 4 (Job A)
5 5 (Job C)

A를 고르면 15, C를 고르면 20, 따라서 A, C의 순서대로 한다. 그러면 최종 답은 BAC.

헉? 정답은 ABC라고?? 내가 또 뭘 잘못했나? 아니야, 예제의 답이 틀렸을 거야. 내가 증명해 주마.

(잠시 후) 진짜로 ABC로 하는 게 총 벌금이 가장 적네. 반례를 찾았으므로 증명은 실패. 다시 처음부터 생각해보자.

분명히 Induction을 써서 푸는 문제 같은데… 만약 예제에서 Job이 A와 B만 있다면, 정답은 AB의 순서로 일을 하는 거다 . AB의 순서로 처리했을 때 내야 하는 벌금을 F(AB)라고 하면 다음과 같이 쓸 수 있다.

F(AB) < F(BA)

이렇게 Job이 두 개만 있을 때는 간단하다. 그런데 여기에 C가 추가되면??

F(CAB), F(ACB), F(ABC)를 다 따져보는 건 너무 무식한데..

아, 만약에 F(BC) < F(CB)이면 어떻게 되지?

F(AB) < F(BA) and F(BC) < F(CB)이면 F(AC) < F(CA)가 만족하나?

응, 만족한다. (매우 간단하게 증명할 수 있으나, 블로그에 공간이 부족하므로 자세한 설명은 생략)

자, 정리해보자. 그럼 F(AB) < F(BA) and F(BC) < F(CB) 일 때 {A, B, C}에 대한 최적의 스케줄을 찾는 문제가 되었다.

(손가락이 간질거리기 시작한다.)

근데, 이런 조건이라면 당연히 F(ABC), 즉 A, B, C의 순서대로 일을 하는 게 가능한 모든 조합 중에 가장 최적의 답 아냐? 맞잖아. 아닐 수도 있다고? 맞다니깐. 그럼 증명해봐.

당연한 것 같은데 증명하지 않으면 계속 찝찝할 것 같지만 그래도 그냥 직관에 의존해보자면, 아래의 부등식처럼 다른 Job은 그대로 놓고 인접한 두 개씩만 바꿔서 비교해 보면 다른 어떤 조합보다 F(ABC)의 벌금이 최소라는 걸 보일 수 있을 것 같다.

F(ABC) < F(ACB) < F(CAB) < F(CBA)
F(ABC) < F(BAC) < F(BCA)

그러면 결국 이 문제는 A, B, C, … 이렇게 N개의 Job이 있을 때, 두 개의 Job끼리 우선순위를 비교해서 가장 급한 것부터 하나씩 해나가면 풀리는 Greedy Algorithm 문제였구나. 그럼 뭐야. Job 두 개를 비교하는 함수 하나만 만들면 되잖아. 정렬하는 알고리즘은 C 표준 라이브러리에서 제공하는 qsort()가 있으니까.

코딩은 금방 끝이 났고, 문제 사이트에 코드를 제출했다.

어라? Wrong Answer라고? 그럴 리가… 나의 알고리즘은 완벽해! 아무리 머리를 굴려도 원인을 찾을 수가 없어서 결국 검색해 봤다. 헐.. 출력에서 줄을 바꿀 때 “\r\n”을 하면 안 되고 “\n”만 써야 하는구나. 출력 형식을 제대로 맞추니까 “Accepted”가 오네. 훗, 역시 나는 틀리지 않았어.

결과를 보니 내 코드는 0.004초 정도 걸렸는데, 이 정도로 순위권을 넘보는 건 언감생신. 어떻게 된 게 전부 0.000초냐.. -_-;

시간을 내 편으로 만들기

가설사고: 소프트웨어 개발자 관점에서

seunglee — Wed, 30 Dec 2009 07:32:57 +0000

Inuit님 블로그에서 소개하는 글을 읽고 바로 느낌이 와서 지른 책입니다. 책에서는 마케팅 전략이나 컨설팅의 관점에서 얘기를 하지만 저는 해오던 일이 있어서인지 계속 소프트웨어 개발자의 눈으로 생각하게 되네요.

가설사고, 생각을 뒤집어라 –
우치다 카즈나리 지음, 보스턴컨설팅그룹(BCG) 옮김/3mecca.com(쓰리메카닷컴)

1. 디버깅(Debugging)

디버깅이란 컴퓨터 프로그램의 결함(버그라고도 하죠)을 찾아서 고치는 작업입니다. 그러려면 먼저 결함의 원인을 찾아야 하는데요, 경험적으로 크게 두 가지 방법을 쓰는 것 같습니다. 먼저 탐색적인 방법, 프로그램을 한 단계씩 실행하면서 제작자의 의도와 다르게 동작하는 부분을 찾아내는 겁니다. 두 번째는 “직관적으로” 어떤 부분이 문제일 거라는 예측을 하고 나서 진짜 그것 때문인지를 확인하는 방식입니다. 여러 작업이 동시에 실행되는 멀티스레딩 프로그램의 경우에는 첫 번째 방식으로 버그를 추적하기가 어렵기 때문에 이 방법을 자주 씁니다. 그물을 쳐놓고 유인해서 버그가 걸리는지를 확인하는 건데, 책에서 말하는 가설 사고와 공통점이 있네요.

하지만, 링크한 글에서 inuit님이 얘기했듯이 보통은 두 가지 방법을 섞어서 쓰게 됩니다. 그럴 수밖에 없죠. 어디서부터 탐색을 시작할지 결정하는 것은 역시 경험에서 우러나오는 직관이고, 그물에 걸린 버그의 원인을 찾아내려면 또 다시 탐색이 필요하거든요.

2. 큰 그림

큰 그림을 그리면서 일을 한다는 것은 최종 목표 혹은 결론을 염두에 두고 현재 작업의 의의를 끊임없이 생각한다는 뜻으로 이해합니다. 가설을 먼저 세우고 검증하는 접근 방식의 장점이기도 한데요, 이 부분을 읽으면서 제 머릿속에 떠오른 것은 테스트 주도 개발(Test Driven Development, TDD)이라는 단어였습니다.

보통은 소프트웨어를 먼저 만들고 그 후에 제대로 동작하는지 테스트 합니다. 그게 당연한 것 같죠? 그런데 테스트 주도 개발이라는 책에서 켄트 백은 그 순서를 바꿀 것을 제안합니다. 프로그램이 의도한대로 동작하는지 테스트하는 프로그램을 먼저 만들고, 그 다음에 진짜 프로그램을 만들자는 거죠.¹

이 방식에는 여러 장점이 있는데, 그중에서 제가 얘기하고 싶은 것은 모듈의 구체적인 목표와 어떻게 사용될지에 대한 설명이 있기 때문에 공들여 만들고 나서 ‘앗, 이 산이 아닌가봐.’ 하는 경우가 없다는 점입니다. (네, 없어지지는 않죠. 그래도 최소한 줄어는 듭니다 :) 완성된 모습을 먼저 그려놓고 그 속을 채워가는 방식이 실험하기 전에 논문부터 쓴다는 연구자의 얘기(책에 나옵니다)와도 좀 통하지 않나요?

기억을 더듬어보면 우리 공부할 때도 그랬던 것 같습니다. 기본이라는 이름 아래 어디에 쓰일지도 모르는 이상한(?) 개념들을 힘들게 익히고 나면 그제서야 활용 분야라는 녀석이 턱 하고 나타납니다.

‘여기까지 오느라 수고했어. 앞에서 배운 거 기억나지? 나는 여기에 쓰는 거야.’

그러면 무릎을 탁 치고는 개념을 복습하러 갑니다. 벌써 다 까먹었거든요(…) 그런 기억 없으신가요? 저는 특히 선형대수(Linear Algebra)가 그랬는데요, 컴퓨터 그래픽스나 정보검색 등 전혀 생각지도 못하던 분야에 활용되는 걸 보면서 기가 막혀했던 기억이 납니다. 그 후로는 새로운 개념을 공부할 때는 먼저 그 활용 분야부터 살피는 습관이 생긴 것 같아요. 책이나 위키피디아를 볼 때 뒤에서부터 훑어보는 이유도 바로 그런 것이고요.

쓰고 보니 책 소개는 없고 그냥 제 생각만 주저리주저리 늘어놓았군요. 그냥 마무리할게요. 가설을 먼저 세우고 검증해나가는 접근 방식이 생소한 분, 더 효과적으로 일하는 법을 배우고 싶은 분께 이 책을 추천합니다.

프로그램이라는 용어를 썼는데, 사실 완성된 소프트웨어보다는 이를 구성하는 각각의 모듈(module)을 구현하는 단계에 유용한 개념입니다.

프로그래밍, 처음부터 다시 배우기

SL — Wed, 09 Jul 2008 23:10:00 +0000

하나의 방식에 익숙해지는 것은 효율성을 높여주지만 동시에 생각을 틀을 그 안에 가둬버릴 위험을 안고 있다. 요즘에 내가 짠 코드를 보고 있노라면 그런 생각은 더욱 커진다.

새로운 패러다임의 프로그래밍 언어를 공부해볼까?

그러자 갑자기 떠오르는 책 하나가 있었다.

MIT에서 10년이 넘게 프로그래밍 입문서로 쓰이고 있다는 책.
하지만, 아마존의 서평을 보면 훌륭한 책이지만 초심자용은 아니라는 책.
표지의 그림을 따서 마법사 책이라고도 불리는 바로 이 책.

말이다.

아마존에서 사람들이 이 책에 매긴 별점 분포를 보면 참 재미있다. 다섯 개와 한 개에 극단적으로 몰려 있는 것이, 완전히 “모 아니면 도”라는 느낌이 든다.

상당히 많은 추천을 받은 서평이 있기에 쓴 사람이 누군가 하고 봤더니.. 의 공동저자이자 현재 구글의 Director of Research 직을 맡고 있는 피터 노빅(Peter Norvig)이었다. 그는 자동차에 비유하면서, 이 책은 자동차의 동작 원리, 효율적이면서 믿을 수 있는 자동차를 설계하는 방법을 찾는 사람을 위한 것이라고 했다. 운전하는 방법을 가르쳐주는 책이 아니라는 얘기다. 저 정도 되는 사람이 이 책을 읽고 자신의 직업에 대한 생각이 바뀌었다고 할 정도라니… 꽤 솔깃하지 않은가.

이어지는 서평에서도 반가운 이름이 보였다. <해커와 화가>의 저자 폴 그레이엄(Paul Graham)이었는데, 그는 Kenneth Clark의 말을 인용했다.

if a lot of smart people have liked something that you don’t, you should try and figure out what they saw in it.

아무튼 이런 사람들이 적극적으로 나서서 변호해주는 책이라면 후회는 하지 않겠다 싶어서 냉큼 주문했다. 이른바 “프로그래밍, 처음부터 다시 배우기” 프로젝트의 시작이다.

DebugView에서 메시지 필터링하기

SL — Wed, 04 Jun 2008 04:10:00 +0000

얼마 전에 DebugView와 OutputDebugString()에 대한 글을 올리면서, 릴리즈 버전에서까지 디버그 메시지를 출력하는 프로그램에 대해 성토(!)를 한 바 있다. 그런데 사실 이것이 써드파티 소프트웨어만의 문제는 아니다. 마이크로소프트에서 직접 만든 프로그램조차도 이 DebugView의 메시지 창을 지저분하게 만든다. Visual Studio가 유력 용의자로 의심되는 아래의 메시지가 바로 대표적인 경우다.

[1024] DllCanUnloadNow called for VSA7.dll
[1024] DllCanUnloadNow returned S_FALSE

그동안 이런 메시지들 때문에 참 갑갑했는데, 알고 보니 매우 간단한 해결책이 있었다. DebugView의 [Edit] – [Filter/Highligh] 메뉴를 선택해서 나오는 대화상자의 Exclude 창에 필터링해버리고 싶은 문자열을 입력하기만 하면 된다. 반대로 특정 문자열 패턴이 포함된 메시지만 보고 싶다면 Include 창에 적으면 된다. 토큰 구분자는 ;

이런 기능은 충분히 있음직한 것이었는데, 어째서 지금까지 찾아볼 생각을 하지 못했을까…

ImageMagick: 간단한 소개

SL — Tue, 12 Feb 2008 19:17:00 +0000

그게 뭔가?

ImageMagick을 소개하는 곳에서 공통적으로 쓰이는 정의를 살펴보면, 이미지를 생성하고 편집하는 소프트웨어 스위트(suite)라고 되어 있다. 애플리케이션도, 라이브러리도 아닌 소프트웨어 스위트라는 다소 익숙하지 않은 표현을 사용한 이유는 아마도 ImageMagick을 커맨드라인을 통해 직접 사용할 수도 있고, 프로그램에서 라이브러리로 가져다 쓸 수 있는 특징 때문일 것이다. “커맨드라인을 통해서”라는 것이 중요한데, GUI 없이’도’ 이미지를 편집할 수 있다는 뜻이기 때문이다.

그게 무슨 의미가 있는가?

이미지 조작 작업을 프로그래밍할 수 있다는 말이다. 즉, 단순 수작업으로 처리해야 할 일을 자동화할 수 있게 된다. 아주 간단한 예를 들어 보자. 사진 A와 B가 있다. 그리고 나는 A와 B를 합쳐 C를 만들어야 한다. ImageMagick을 이용하면,

convert A B -append C

라는 명령어로 원하는 결과를 얻을 수 있다.

그런데? 이건 이미지 편집기, 심지어 그림판을 써도 간단하지 않은가?

그런데, (100A, 100B)부터 (999A, 999B)이렇게 총 900개의 쌍에 대해서 동일한 작업을 해야 한다면 어떻게 할텐가? ImageMagick 같은 방식을 이용하면 셸스크립트와의 조합으로 간단하게 처리할 수 있다. 대충 이런 식으로..

index=100
while [ $index -lt 1000 ]
do
convert ${index}A ${index}B -append ${index}C
index=$(($index+1))
done

물론 이런 일이 필요할 확률이 제로에 수렴한다 할지라도 가끔씩은 아주 유용하게 써먹을 수 있으니 익혀둘만 하지 않은가. 살다 보면 무슨 일이 벌어질지 모르는데 말이다. 위의 예는 진짜 간단한 걸로 골랐는데, www.imagemagick.org에 가면 이 소프트웨어의 막강한 기능을 찬찬히 살펴볼 수 있다.

Programming Collective Intelligence: 첫인상

SL — Sat, 01 Dec 2007 16:43:00 +0000

이 책은 요즘 유행하는 웹 2.0을 표방하는 서비스에 적용할 만한 패턴분류(pattern classification) 또는 기계학습(machine learning) 이론을 소개하고, 이를 활용하여 재미있고 유용한 서비스를 구현하는 방법을 설명한다. 책의 구성은 단순하다. 챕터마다 특정 알고리즘을 소개하고 그것을 적용할 만한 웹서비스를 제시한 뒤 실제 구현 코드를 보여주면서 마무리 짓는 형식이다.

등장하는 알고리즘의 면면을 살펴보면, Recommendation, Decision Tree, Neural Network, Bayesian Classifier, Optimization, Clustering, Support Vector Machine, Feature Extraction 등으로 아주 화려하다. 하지만 위의 알고리즘을 모두 제대로 공부할 수 있겠다는 기대로 이 책을 펼친다면 실망하기 십상이다. 이 책은 그저 이런 알고리즘들의 기본 개념과 특징을 쉽게 설명하여 어떤 용도에 쓰면 적절할지 감을 잡게 해줄 뿐이다. 깊이 이해하려면 기계 학습 관련 책을 붙들고 공부해야 할 것이다.

이 책의 눈에 띄는 특징은 보통 이런 내용을 다루는 책에서 당연스럽게 사용하는 수식을 전혀 찾아볼 수 없다는 점이다. 그 대신, 파이썬 프로그래밍 언어로 작성한 코드가 그 자리를 차지하고 있다. (복잡한 알고리즘은 공개된 라이브러리를 가져다가 사용하는 정도로 그치기도 한다.) 아마도 저자가 -수식이 간결 명료하기는 하지만- 프로그래머에게는 익숙한 코드를 보여주는 것이 각 알고리즘의 동작을 설명하는 가장 좋은 방식이라고 생각한 듯하다.

또 다른 장점으로는 책 곳곳에서 소개하는 유용한 오픈 API 목록들을 들 수 있다. 책의 설명과 파이썬 예제 코드를 이용하면 그런 API에 대한 초기 접근성을 낮춰서 쉽게 가져다 쓸 수 있겠다는 생각이 들었다.

책의 성격이 애매하달 수도 있지만 내가 보기에 저자는 대상 독자층을 매우 잘 선정했다. 수업 시간에 기계학습 이론을 배운 사람에게는 ‘오.. 이런 식으로 활용할 수도 있구나’라는 아이디어와 함께 구현 시 갖다 쓸 수 있는 코드 및 레퍼런스를 제공한다. 반대로, 이론적인 내용에 약한 프로그래머에게는 다양한 알고리즘의 개념을 쉽게 설명하면서 실제로 적용할 때 고려해야 할 요소들을 잘 정리해준다. 이 책은 군더더기 없이 깔끔하게 그 목적을 달성하고 있다.

포터 알고리즘(Porter’s Stemming Algorithm)

SL — Thu, 22 Nov 2007 15:07:36 +0000

정보검색(Information Retrieval; IR)과 관련된 구현을 시작하면서 가장 처음 맞닥뜨리게 되는 현실적인 어려움은 아마도 키워드의 어근 추출 문제일 것이다. 예를 들어 TF-IDF 알고리즘을 구현한다고 해보자. 문서에 포함된 각 단어에 대하여 그 단어와 문서의 연관성을 계산해야 하는데, 어근이 제대로 추출되지 않는다면 최종 구현물의 정확도는 떨어질 수밖에 없다. ability와 abilities가 서로 다른 단어로 처리되기 때문이다.

한국어는 잘 모르겠지만, 영어의 경우에는 일반적으로 잘 알려진 어근 추출 방법이 있다. 개발자인 Martin Porter의 이름을 따서 포터 알고리즘(Porter’s Algorithm)이라고 불리는 방식으로, 최초로 소개된 것이 1979년이니까 벌써 30년이나 숙성된 것이다.

포터 알고리즘을 가져다 쓰기 위해서 내부적인 내용을 반드시 이해할 필요는 없다. 저자가 직접 구현한 C 언어 버전, 그리고 그밖의 많은 사람들이 여러 언어로 포팅한 버전을 여기에서 내려받을 수 있다. 이 알고리즘을 최초로 소개한 논문도 같은 페이지에서 구할 수 있으니 관심있는 분들은 한 번 읽어봐도 좋을 것이다.

조엘 온 소프트웨어

SL — Sat, 01 Sep 2007 06:35:00 +0000

풍부한 프로그래밍 경험과 지식을 가지고 있으며 현업 소프트웨어 제작업체의 CEO로 활약 중인 저자 조엘은 프로그래밍과 소프트웨어 개발에 대하여 상당히 현실적인 조언을 들려준다.

2장 “기본으로 돌아가기”에서 그는 기본기를 강조하여 프로그래머라면 고급 언어로 작성한 코드가 실제 프로세서에서 실행될 때 어떤 일이 발생하는지를 이해하고 있어야 한다고 주장한다. 왜냐하면, 그렇지 않은 경우 추상화에 구멍이 뚫려서 문제가 발생했을 때 효과적으로 대처할 수 없기 때문이다. 대학생이 졸업 전에 갖춰야 할 지식 목록에 조엘이 C 언어를 넣은 것은 바로 그런 상황에 대한 염려로 이해할 수 있다.

또 34장 “세상에 쉬운 일은 없습니다”에서는 기능 설계의 중요성을 예를 통해 차분하게 설명한다. 단순히 설계를 건너뛰기 위한 변명으로 리팩토링을 들먹이다가는 “실제 작업 진행은 고사하고 소프트웨어 허상을 좇아 리팩토링만 계속하는 순환에 빠지게” 된다는 경고와 함께.

22장 “테스터를 두지 않는 (잘못된) 이유 다섯가지”에서는 테스터의 중요성을 역설한다.

프로그래머 두 명 당 테스터가 적어도 한 명은 있어야 합니다. 프로그래머는 각자 만든 빌드를 자주 던져주면서 테스터와 밀접하게 일해야 합니다.

테스터를 고용할 돈이 없다는 핑계에 대해서는 이렇게 일침을 가한다.

아무리 테스터를 찾기가 어려워도, 테스터는 프로그래머보다 쌉니다. 훨씬 쌉니다. 테스터를 고용하지 않으면 프로그래머가 테스팅을 해야 합니다. 테스터가 자꾸 빠져나가 힘들다고 생각하신다면, 연봉 10만달러 짜리 스타 프로그래머가 “출시 전에 몇 주 테스트해보라”는 말에 지쳐서 좀더 전문적인 회사로 옮겨버릴 경우를 상상해 보십시오. 스타 프로그래머를 교체하는 데 드는 비용이 얼마인지 계산해보십시오. 프로그래머 한 명 교체하는 비용으로 테스터 세 명 연봉에 구인 비용까지 충당할 수 있을 겁니다.

최근 이슈가 되고 있는 IT 업계의 관습화된 초과 근무와 연관지어 여러 가지를 생각하게 하는 대목이다.

드러난 모든 버그는 당연히 수정해야 한다고 생각하는 사람에게, 11장 “고리타분한 버그 수정”은 조금 색다른 관점을 제시할 것이다. CEO답게 조엘은 버그 수정의 경제성을 얘기한다.

버그 수정은, 수정한 버그 가치가 수정 비용을 넘어설 때만 그 의미가 있습니다.

하지만 그것이 치명적이지 않은 버그는 고치지 않아도 좋다는 뜻은 결코 아니다. 오히려 그는 -아주 특별한 상황이 아닌 다음에는- 사소한 버그를 수정하는 것도 명백한 투자 대비 효용가치가 있다는 견해를 밝히고 있으니까 말이다.

개인적으로 가장 통쾌함을 느끼며 읽었던 건, 14장 “화성인 아키텍트를 조심하세요” 였다. 진정한 핵심을 놓치고, 아키텍쳐를 위한 아키텍쳐에 빠져버린 사람을 그는 화성인으로 분류한다.

추상화를 추구하기 위해서 너무 높이 올라가면, 산소 부족에 시달릴 겁니다. 때로는 똑똑한 사상가라도 어디서 멈출지를 모르기 때문에, 모순이 생기고 전체만을 아우르는, 그저 멋지고 훌륭한, 고차원적인 성운 사진만 찍어 냅니다. 하지만 실제로 이 사진에는 어떤 의미있는 내용도 담겨있지 않습니다. 이런 사람을 화성인 아키텍트라고 부르겠습니다.

물론, 실용성이 조금 떨어지더라도 그러한 연구는 필요하고 또 그 나름의 의미를 갖는다고 보지만, 조엘은 철저하게 실용성의 기준에서 비판한다. 아마도 쓸데없이 과장된 마케팅 수사에 지쳤던 게 아닐까.

화성인 아키텍트는, 해결하면 도움이 되는 문제점보다는, 풀 수 있을 것 같은 문제점만을 해결한다는 점을 명심하세요. (중략) 제발 제가 옛날에 할 수 없었던 일을 가능하게 해주는 신기술을 알려주세요. 위대한 화성인 여러분, 앞으로는 화성에서 그냥 조용히 지내시면서 더 이상 황금같은 제 시간을 낭비하지 말아주세요.

37장 “전략 메모II: 닭이 먼저냐, 달걀이 먼저냐”와 38장 “전략 메모 III: 나 다시 돌아갈래!”에서는 마이크로소프트가 치열한 소프트웨어 경쟁에서 승리할 수 있었던 비밀을 들려준다. IBM PC의 소프트웨어 플랫폼 시장에서 PC-DOS가 경쟁자들을 물리칠 수 있었던, 또 DOS에서 윈도우 3.x를 거쳐 윈도우 95로 성공적으로 이주할 수 있었던 비결을, 조엘은 바로 하위호환성 확보에서 찾는다. 특히 심시티 게임(의 버그)을 위해서 윈도우 95개발자들이 특별한 플래그를 추가했다는 대목에서는, 그 철두철미함에 살짝 전율까지 느껴졌다.

파이어폭스 개발자들이 내부적인 반대에도 불구하고 비표준태그인 document.all을 지원하기로 했던 결정이, 오늘날 (한국에서의) 파이어폭스 점유율과 무관하지 않다는 사실을 떠올리게 된다.

37장에서 압도적인 시장 지배자가 없는 상황에서 치고 나올 수 있었던 이유를 설명했다면, 38장에서는 이미 업계 1위의 로터스 123이 있는 시장에서 엑셀이 승리할 수 있었던 비결을 소개한다. 잠재고객이 언제든 쉽게 돌아갈 수 있도록, 강요하지 않는 성숙한 전략이 프로그램에 대한 진입장벽을 낮추었고 결국 사용자를 끌어올 수 있었다는 것이다.

그밖에도 에릭 레이몬드의 “The Art of Unix Programming” 책에 대한 감상문으로 느껴지는 18장 “더불어 살기”에서는 (유닉스 문화와 비교해가며) 최종 사용자에 대한 배려를 무엇보다 우선시하는 윈도우 문화에 대해서, 그리고 그러한 가치를 이끌어낸 배경에 대해서 조리있게 설명한다.

또 개인적으로는 30장 “이 나라에서는 개가 무슨 일을 하죠?”의, 개발 중인 소프트웨어를 스스로 사용해보라는 조언을 실천하면서 그의 말이 옳았음을 실감하고 있기도 하다.

프로그래머가 이 책을 읽는다면, 그의 주력 플랫폼이 무엇이건 개발하는 소프트웨어가 무엇이건 상관없이 저자의 경험으로부터 우러나오는 실용적인 조언들을 통해 많은 통찰을 얻을 수 있을 것이다.

해커와 화가 – 폴 그레이엄

SL — Mon, 27 Aug 2007 14:11:55 +0000

책표지에 쓰여있는 것처럼 “이단적인 통찰과 현실적인 지혜”로 가득차 있는 책이다. 특히 “공부벌레는 왜 인기가 없는가”라는 조금은 엉뚱한 질문으로 시작하여 학교 시스템에 대한 색다른 관점을 제시하는 1장은 한 번쯤 깊이 곱씹어볼 만한 가치가 있다. 2장은 이 책의 제목 “해커와 화가”에 가장 잘 어울리는 장으로서, 해커이자 동시에 화가인 저자의 프로그래밍에 대한 생각을 살펴볼 수 있다.

이 책에서 저자는 프로그래밍 대신 (아마도 의도적으로) 해킹이라는 용어를 사용하고 있는데, 여기서의 해킹이란 -흔히 알려진 것처럼 남의 컴퓨터에 침입하거나 또는 운영체제를 깊이 파헤치는 행위가 아니라- (프로그래밍 언어를 포함하는) 소프트웨어를 디자인하고 구현하는 작업 전체를 아우르는 행위다.

그에 따르면 해킹은 수학이나 자연과학 같은 학문과는 다른 종류의 일이며, 또한 얼핏 비슷해보이는 소프트웨어 공학과도 구분된다. 소프트웨어 공학이 ‘어떻게’라는 방법에 집중하는 반면, 해킹은 ‘무엇을’이라는 문제에도 관심을 쏟기 때문이다.

… 해킹이라는 것은 분명 주어진 요구사항을 단순히 어떻게 구현할 것이지 정하는 일이 아니다. 진정한 해킹이란 사실 요구사항 자체를 창조하는 것이다. 요구사항을 만들어 내는 최선의 방법은 그것을 실제로 구현해 보는 것인 경우가 많다.

그는 해커와 화가의 작업 방식의 유사함을 설명하면서, 해킹이 컴퓨터 과학보다는 오히려 소설쓰기나 그림그리기와 같은 예술적 창조 행위에 더 가깝다고 말한다.

… 나는 오랫동안 이런 프로그래밍 방식에 대해서 남몰래 부끄러워했다. 하지만 내가 그 당시에 화가나 건축가 같은 다른 창조자들이 일하는 방식을 알았더라면, 내가 프로그래밍 하는 방식을 지칭하는 특별한 이름이 있다는 사실을 알 수 있었을 것이다. 그 이름은 바로 ‘스케치’다. (중략) 소설가, 화가, 그리고 건축가의 작업이 그런 것처럼 프로그램이란 전체 모습을 미리 알 수 있는 것이 아니라 작성해 나가면서 이해하게 되는 존재다.

하지만 그림과 소프트웨어 사이의 무시할 수 없는 차이, 즉 그림이나 건축과 같은 작품은 (창조자에 의해) 한 번 완성된 뒤에는 그대로 보존하기만 하면 되는 반면, 소프트웨어는 끊임없는 유지보수를 필요로 한다는 사실에 대해서는 어떻게 생각할까? 그는 이렇게 답한다.

어느 한 화가의 작품을 시간 순서대로 확인해 보면 하나의 작품은 바로 이전 작품에서 학습한 내용을 토대로 구축되어 있음을 알게 된다. (중략) 하나의 프로젝트를 붙들고 몇 년 동안 일하면서 나중에 새롭게 떠오르는 생각을 프로젝트에 부분적으로 적용하여 개정판을 만들어 나가는 것보다는, 화가와 같이 처음부터 새롭게 시작하는 프로젝트를 규칙적으로 반복하는 것이 더 바람직하다고 본다.

2장을 마무리지으면서 그는 레오나르도 다빈치의 시절에만 해도 그림이란 지금만큼 멋진 일이 아니었음을 강조하며 “해킹의 전성기는 바로 지금”이라는 말로 독자를 해커의 길로 유혹한다. 작품의 질은 창조자가 그 일에 어떻게 반응하는가에 달려있듯이 해킹이 얼마나 멋진 일이 되는가도 우리가 지금 해킹을 통해 무엇을 하는가에 달려 있다는 것을 너무나도 잘 알고 있기 때문이리라.

꼬리에 꼬리를 무는 책읽기

조엘 온 소프트웨어