swindler's board

재밌고 가슴이 따뜻해지는 글

제목	[번역] 성당과 시장 1998/10/20 (10:27)
이름	김효원
번호	121
조회	3018
본문	『리눅스 학당-번역물 (go LINUX)』 218번 제 목:[번역] 성당과 시장 올린이:k2linux (엄기성 ) 98/10/19 04:12 읽음: 17 관련자료 없음 ----------------------------------------------------------------------------- 하이텔에서 가져왔습니다. 리동 사람들이면 꼭 읽어보세요. KLDP에 가시면 sgml 한글 소스도 구할 수 있습니다. 기성 #130 정직한 (어니스트) [번역] 성당과 시장 (0/4) 09/09 17:20 39 line Eric Raymond 의 The Cathedral and the Bazaar 를 번역했습니다. 리눅스를 비롯한 오픈소스 개발에 관심있는 사람이라면 한번쯤 읽어 보아야 할 글인 것 같군요. ------- 성당과 시장 by Eric S. Raymond $Date: 1998/05/13 17:29:31 $ 리눅스의 역사에 의해 제시된 소프트웨어 엔지니어링의 놀라운 이론의 신중한 테스트로 실행된 성공적인 오픈소스 프로젝트, fetchmail을 분석한다. 이 이론들을 두 개의 근본적으로 다른 개발 스타일의 용어들로 논할 것이다. 두가지 스타일이란 상업용 소프트웨어의 "성당" 모델과 리눅스 세계의 "시장" 모델이다. 이 모델들은 소프트웨어 디버깅 작업의 본질에 대한 서로 대립되는 가설들로부터 파생되었다는 것을 보일 것이다. 그리고 나서 리눅스의 경험으로부터 "충분히 많은 사람이 있다면, 찾을 수 없는 버그란 없다" 는 일관된 주장을 펴고, 다른 이기적인 에이전트들의 자가수정 시스템과의 생산적인 비유를 제시한 다음, 소프트웨어의 미래를 위해 이 통찰이 가지는 의미에 대한 탐구로 마무리짓는다. ----------------- 순서 1. 성당과 시장 2. 메일은 배달되어야만 한다 3. 사용자가 있다는 것의 중요성 4. 일찍 발표하고, 자주 발표하라 5. 장미가 장미다우려면 6. Popclient 가 Fetchmail 이 되다 7. Fetchmail 의 성장 8. Fetchmail에서 배울 점 9. 시장 스타일의 개발에 필요한 선행조건들 10. 오픈소스 소프트웨어의 사회적 문맥 11. 감사의 말 12. 읽어볼 만한 글들 13. 후기 : 넷스케입이 시장스타일을 받아들이다! 14. 버전과 변천사 #131 정직한 (어니스트) [번역] 성당과 시장 (1/4) 09/09 17:22 242 line 1. 성당과 시장 리눅스는 파괴적이다. 파트타임으로 해킹을 하면서 인터넷이라는 가느다란 선만으로 연결되어 있는 전세계 수천명의 개발자들에 의해 세계적인 수준의 운영체제가, 마치 마술로 된 것처럼 만들어질 수 있었으리라고 5년 전에 누가 상상이나 할 수 있었을까? 나는 분명 상상하지 못했다. 1993년 초, 리눅스가 내 레이다 화면에 잡혔을 때 나는 이미 유닉스와 오픈소스 개발을 10년 동안 해오고 있었다. 1980년대 중반에 GNU 에 공헌한 첫 번째 사람들 중 한명이었다. 나는 네트워크 상에 꽤 많은 오픈소스 소프트웨어를 발표했고, 지금도 널리 사용되고 있는 몇몇 프로그램을 개발중이거나 공동개발하고 있었다. (네트핵, Emacs VC 와 GUD 모드, xlife, 등등) 나는 프로그램이 어떻게 개발되어야 하는지 알고 있다고 생각했다. 리눅스는 내가 알고 있다고 생각한 것을 많은 부분 뒤집어 버렸다. 몇 년 동안이나 나는 작은 도구, 빠른 프로토타이핑, 그리고 진화적인 프로그래밍을 여러 해 동안 유닉스의 복음으로 설교해 오고 있었다. 하지만 나는 어떤 종류의 매우 중요한 복잡성이 있어서 거기에는 더 집중되고 선험적인 접근방법이 필요하다고 믿고 있었다. 가장 중요한 소프트웨어 (운영체제나 Emacs 같이 대단히 커다란 커다란 도구들) 은 성당을 건축하듯이, 즉 찬란한 고독 속에서 일하는 몇 명의 도사 프로그래머나 작은 그룹의 뛰어난 프로그래머들에 의해 조심스럽게 만들어지고 베타버전도 필요없이 발표되어야 한다고 생각했던 것이다. 리누스 토발즈의 개발 스타일은 - 일찍, 그리고 자주 발표하며 다른 사람들에게 위임할 수 있는 것은 모두 위임하고, 뒤범벅이 된 부분까지 공개하는 그런 스타일 - 나에게 놀라움으로 다가왔다. 고요하고 신성한 성당의 건축방식은 여기에서 찾아볼 수 없었다. 대신, 리눅스 공동체는 서로다른 의견과 접근방법이 난무하는 매우 소란스러운 시장같았다. (리눅스 아카이브 사이트가 이것을 적절히 상징하고 있다. 이곳에는 누/구/나/ 파일을 올릴 수 있다) 이런 시장바닥에서 조리있고 안정적인 시스템이 나온다는 것은 연속된 기적으로만 가능한 것처럼 보였다. 시장 스타일이 매우 효과적이라는 사실은 분명히 충격이었다. 리눅스 공동체에 익숙해 가면서 나는 개개의 프로젝트에만 열심이었던 것이 아니라 왜 리눅스 세계가 혼란속에 갈라지지 않을 뿐 아니라 성당건축가들이 간신히 상상만 할 수 있는 속도로 갈수록 강해지는지 이해하려고 애썼다. 1996년 중반에야 이해가 되기 시작했다. 내 이론을 시험해 볼 수 있는 완벽한 기회가 오픈소스 프로젝트의 형태로 찾아왔다. 여기에서 나는 의식적으로 시장 스타일을 시도해 볼 수 있었고, 큰 성공을 거두었다. 이 글의 나머지 부분에서는 그 프로젝트에 대해 이야기하고 효과적인 오픈소스 개발에 대한 격언들을 제시할 것이다. 내가 이 모든 것을 리눅스 세계에서 배운 것은 아니지만 리눅스 세계가 이 격언들에게 특별한 요점을 가질 수 있게 해주었다. 만일 내가 옳다면, 독자들은 이 격언들로부터 리눅스 공동체가 훌륭한 소프트웨어를 만들어내는 원천이 될 수 있었던 이유를 이해할 수 있을 것이며, 독자 자신들도 더 생산적으로 될 수 있을 것이다. 2. 메일은 배달되어야만 한다. 1993년에 서 펜실베니아 주, 서 체스터(West Chester) 시의 자그마한 무료 ISP 인 체스터 카운티 인터링크 (Chester County InterLink : CCIL) 에서 기술적인 측면을 담당하고 있었다. (나는 CCIL 의 공동설립자였으며 우리만의 멀티유저 게시판 소프트웨어를 작성했다 - locke.ccil.org 에 telnet 으로 접속하면 볼 수 있다. 지금은 19 회선으로 3000 여명의 사용자를 지원한다) 이 일 덕분에 나는 하루 24시간 내내 CCIL 의 56K 회선을 통해 네트워크에 접근할 수 있었다. 사실, 그렇게 해야만 하는 상황이었다. 그래서 나는 즉시 배달되는 인터넷 이메일에 매우 익숙해졌다. 복잡한 이유로 인해 내 집의 컴퓨터 (snark.thyrsus.com) 과 CCIL 사이에 SLIP 연결을 하기가 힘들었다. 마침내 성공하고 나자, 주기적으로 locke 에 접속해 메일이 왔는지 체크해 보는 것이 매우 귀찮은 일이라는 것을 알게 되었다. 나는 내 메일이 snark 로 배달되었을 때 바로 알 수 있고, 내 도구들을 가지고 메일을 다룰 수 있게 되는 것을 원했다. sendmail을 이용해 단순히 포워드시키는 것은 소용이 없었다. 내 개인 컴퓨터가 항상 네트워크에 연결되어 있는 것도 아니고 고정적인 IP 어드레스를 가지고 있지도 않았다. SLIP 연결이 되면 내 메일을 배달해주는 프로그램이 필요했다. 그런 프로그램이 몇 개 있었고, 대부분은 프로토콜로 POP (Post Office Protocol)을 사용했다. 물론, locke 의 BSD/OS 운영체제에는POP3 서버가 포함되어 있었다. 내게 필요한 것은 POP3 클라이언트였다. 그래서 네트워크를 뒤져 하나를 찾아냈다. 사실은 서너개를 찾아내긴 했다. 잠시동안은 pop-perl을 사용했지만 기본적인 기능이 빠져있었다. 가져온 메일에서 발신인의 주소를 제대로 처리하지 못해 답장을 보낼 수가 없었다. locke 의 사용자 중에 joe 라는 사람이 나에게 메일을 보냈다고 해보자. snark 로 메일을 가져와서 그 메일에 답장을 하려고 하면 메일 프로그램은 snark 에는 있지도 않은 joe 에게 답장을 보내려고 시도한다. 그래서 손으로 '@ccil.org'를 뒤에 붙여주어야 했는데, 곧 매우 성가시게 느껴졌다. 이것은 분명히 컴퓨터가 해주어야 하는 일이었다. 하지만 이미 있는 POP 클라이언트들 중 어느것도 이 일을 해주지 못했다. 여기에서 첫 번째 교훈을 얻을 수 있다. 1) 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다. (Every good work of software starts by scratching a developer's personal itch) 명확해 보이는 교훈이긴 하지만 ("필요는 발명의 어머니" 라는 오래된 속담이 있지 않은가)소프트웨어 개발자들은 너무나자주, 단지 돈 때문에 그들이 필요로 하지도 않고 좋아하지도 않는 프로그램을 만들어 내는데 시간을 쓰고 있다. 하지만 리눅스 세계에서는 그렇지 않다 - 아마도 이것이 리눅스 공동체에서 만들어진 소프트웨어들의 평균적이 품질이 그렇게나 좋은지를 설명해줄 것이다. 그래서 내가 이미 있는 POP3 클라이언트들과 경쟁하는 새로운 프로그램을 곧바로 코딩하기 시작했을까? 천만에. 나는 이미 가지고 있는 POP 유틸리티들을 조심스럽게 살피면서 스스로에게 물었다. "내가 원하는 것과 가장 가까운 프로그램이 어느 것일까?" 그 이유는 2) 좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 (그리고 재사용해야 할 지) 안다. (Good programmers know what to write. Great ones know what to rewrite(and reuse)) 내가 위대한 프로그래머라는 말은 아니지만 흉내내려고는 했다. 위대한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름이다. 그들은 들인 노력으로가 아니라 결과로 평가받는다는 것을 알고 있으며 완전한 무에서 시작하는 것보다는 부분적으로나마 좋은 해결책에서 시작하는 것이 거의 항상 더 쉽다는 것을 알고 있다. 리누스 토발즈 (http://www.earthspace.net/~esr/faqs/linus)를 예로 들자면 그는 맨바닥에서 Linux를 써내려고 하지 않았다. 대신 그는 386 기계를 위한 Unix 비슷한 OS, Minix 의 코드와 아이디어를 재사용하는 것으로부터 시작했다. 결국 모든 Minix 코드는 사라지거나 새로 쓰여졌다 -- 하지만 Minix 의 코드가 남아있을 동안 그 코드는 나중에 Linux 가 될 어린 아기의 발판 역할을 했다. 똑같은 생각으로 나는 이미 있는 POP 유틸리티 중 코딩이 잘 되어있는 것을 찾아 개발의 기초로 사용하려 했다. Unix 세계의 소스를 공유하는 전통은 언제나 코드를 재사용하는데 호의적이었다. (GNU 프로젝트가 Unix 자체에 대한 심각한 의혹에도 불구하고 Unix 를 기본 OS 로 선택한 것도 바로 이런 이유에서였다) 리눅스 세계는 거의 기술적인 한계에 다다를때까지 이 전통을 받아들였다. 일반적으로 찾아볼 수 있는 오픈된 소스가 수 테라바이트에 달하는 것이다. 그래서 누군가의 거의 완성된 소스를 찾아보는데 시간을 들이는 것이 다른 어느 곳에서보다 리눅스 세계에서는 좋은 결과를 가져다 줄 가능성이 높다. 나에게도 역시 그랬다. 예전에 찾아놓은 것에다가 두 번째 검색결과를 더하니 모두 아홉 개의 후보가 생겼다. fetchpop, PopTart, get-amil, gwpop, pimp, pop-perl, popc, popmail, 그리고 upop 이었다. 내가 제일 먼저 신경을 집중한 것은 오승홍 씨의 fetchpop 이었다. 헤더 재작성 기능과 더불어 몇몇 개선사항을 그 안에 추가했고, 저자가 릴리즈 1.9 에 그것을 수용했다. 몇 주 후에 나는 Carl Harris 가 만든 popclient 의 코드를 들여다 보다가 문제점을 발견했다. fetchpop 에는 훌륭한 독창적인 아이디어가 들어 있었지만 (daemon 모드 같은 것) POP3 만을 처리할 수 있었고, 아마추어 티가 나는 코딩이었다. (오승홍 씨는 똑똑하기는 하지만 경험이 부족한 프로그래머였으며 그 두 가지 특징 모두를 코딩에서 볼 수 있었다) Carl 의 코드는 탄탄한 프로페셔널의 더 나은 코드였으나 몇가지 중요하면서도 구현하기 위해서는 약간의 잔머리가 필요한 fetchpop 의 기능들이 (내가 추가한 기능들을 포함해서) 빠져 있었다. 머물러 있을 것인가, 옮겨갈 것인가? 옮겨간다면 더 나은 개발기반을 위해 이미 해놓은 코딩을 포기해야만 했다. 옮겨가는데 실질적인 동기가 되었던 것은 다중프로토콜 지원 여부였다. POP3 가 우체국 서버 프로토콜 중에서 가장 널리 쓰이는 것이긴 했지만 유일한 프로토콜은 아니었다. fetchpop을 비롯하여 다른 경쟁자들은 POP2, RPOP, 또는 APOP를 지원하지 않았고, 나는 당시에 재미삼아서 IMAP (Internet Message Access Protocol; http://www.imap.org; 가장 최근에 고안되었으면 가장 강력한 우체국 프로토콜) 을 지원해볼까 하는 생각을 가지고 있었다. 하지만 옮겨가는 것이 좋은 생각이라는 좀 더 이론적인 이유도 가지고 있었다. 오래전에 리눅스에서 배운 교훈이었다. 3) "가지고 있는 것을 버릴 계획을 세우라 ; 언젠가는 버리게 될 것이다 (Plan to throw one away; youu will anyhow)" (Fred Brooks, "The Mythical Man-Month", Chapter 11) 다른 말로 하자면, 첫 번째 해결책을 구현할 때까지도 진짜 문제가 무엇인지 이해하지 못하는 경우가 종종 있다는 것이다. 두 번째가 되어서야 어떻게 하는 것이 옳은 것인지 충분히 알게 될 수 있다. 따라서 만일 올바른 방법을 찾고 싶다면 최/소/한 한 번은 처음부터 다시 시작할 준비를 해 두어야 한다. 그래, fetchpop을 고친 것은 내 첫 번째 시도였어, 하고 스스로에게 말하고 나서 나는 popclient 로 옮겨갔다. 1996년 6월 25일에 Carl Harris 에게 내 첫 번째 popclient 패치를 보낸 후, 나는 그가 popclient 에 대한 흥미를 이미 잃었다는 것을 알게 되었다. 코딩이 좀 지저분했고, 자잘한 버그들이 널려있었다. 수정을 많이 가했고, Carl 과 나는 곧 내가 프로그램을 넘겨받는 것이 합리적이라는 데에 동의하게 되었다. 내가 알아차리지 못하는 새에 프로젝트가 차츰 궤도에 오르기 시작했다. 나는 이미 존재하고 있는 POP 클라이언트의 마이너 패치를 생각하는 것이 아니었다. 클라이언트 하나를 통채로 관리하고 있었으며 내 머리에서는 커다란 변화가 될 아이디어들이 솟아나고 있었다. 코드공유를 장려하는 소프트웨어 문화에서는 이런 방식으로 프로젝트가 진화하기 마련이다. 이렇게 말할 수 있다. 4) 적절한 태도를 가지고 있으면 흥미로운 문제가 당신을 찾아갈 것이다. (If you have the right attitude, interesting problems will find you) 하지만 Carl Harris 의 태도가 훨씬 더 중요했다. 그의 태도는 5) 프로그램에 흥미를 잃었다면 프로그램에 대한 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다. (When you lose interest in a program, your last duty to it is to hand it off to a competent successor) 토론할 필요도 없이 Carl 과 나는 가장 좋은 해결책을 찾아낸다는 목표를 가지게 되었다. 우리에게 남아있는 한가지 문제는 내가 적임자라는 것을 입증할 수 있느냐 하는 것이었다. 내가 그것을 증명하자 그는 기꺼이, 그리고 신속하게 행동했다. 내가 그렇게 행동할 차례가 되었을 때 나도 그만큼 잘 할 수 있기를 바란다. 3. 사용자가 있다는 것의 중요성 그래서 내가 popclient를 넘겨받았다. 내가 popclient 의 사용자들을 넘겨받았다는 것도 그에 못지않게 중요하다. 사용자들이 있다는 것은 매우 좋은 일이다. 당신이 누군가의 필요를 충족시켜주고 있으며 일을 잘 해나가고 있다는 것을 보여주기 때문만은 아니다. 적절하게 유도해 준다면 사용자들을 공동개발자가 될 수 있다. 유닉스의 전통이 가지고 있는 또하나의 강점, 즉 많은 수의 사용자들이 동시에 해커이기도 하다는 것을 리눅스는 좋은 의미로서의 극단까지 밀어붙였다. 소스코드가 공개되어 있기 때문에 그들은 효/과/적/인/ 해커가 될 수 있었다. 이것은 디버깅 시간을 줄이는 데 엄청난 도움이 되었다. 조금만 격려해주면 사용자들은 문제를 분석하고 해결책을 제시하며, 도움없이 혼자 일할 때보다 훨씬 빨리 코드를 개선시키도록 해준다. 6) 사용자들을 공동개발자로 생각하면 코드가 다른 어떤 방법보다도 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다. (Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging) 이 효과의 위력은 과소평가되기 쉽다. 사실, 오픈소스의 세계의 우리들조차 시스템의 복잡도에 대항하여 많은 수의 사용자가 얼마나 힘이 되는지를 리누스 토발즈가 보여주기 전까지 과소평가하고 있었다. 실제로 나는 리누스의 가장 영리하고 가장 중요한 해킹은 리눅스 커널을 만들었다는 점이 아니라 리눅스 개발모델을 만들었다는 점이라고 생각한다. 리누스에게 이 의견을 말해 주었더니 그는 씨익 웃고서 조용히 여러번 하던 말을 되풀이했다. "난 기본적으로 매우 게으른 사람이라서 실제로는 다른 사람들이 해놓은 일을 가지고 공로라고 인정받곤 해요." 여우처럼 게으르군. 로버트 하인라인이라면 실패하기에는 너무 게으르다고 말했을 것이다. 되돌아 보면, 리눅스의 성공과 방법론은 GNU Emacs Lisp 라이브러리와 Lisp 코드 아카이브에서 그 선례를 찾아볼 수 있다. Emacs C 코어와 다른 대부분의 FSF 도구들의 성당건축 스타일과는 대조적으로 Lisp 코드 풀의 진화는 유동적이었고, 사용자가 주도한 것이었다. 아이디어와 프로토타입 모드들은 안정적인 최종형태를 갖추기까지 종종 서너번씩 다시 쓰여졌다. 느슨하게 묶인 공동작업이 인터넷으로 인해 가능해졌고, 리눅스에서는 매우 자주 일어나는 일이 되었다. 사실 fetchmail 이전에 내 자신의 가장 성공적인 해킹은 아마 Emacs VC 모드였을 것이다. 세 명의 사람들과 email을 통해 리눅스와 비슷한 협동작업을 했고, 그 셋 중의 한 명 (리차드 스톨만:Richard Stallman. Emacs 의 저자이면서 FSF 의 설립자) 만을 지금까지 만나고 있다. VC 모드는 SCCS, RCV 와 CVS 를 위한 Emacs 내의 프론트엔드였고, "원터치" 버전컨트롤 기능을 제공했고, 누군가 만들어 놓은 작고 조악한 sccs.el 모드로부터 진화한 것이었다. VC 의 개발은 Emacs 와는 다르게 Emacs List 코드가 발표/테스트/개선의 주기를 매우 빨리 반복할 수 있었기 때문에 성공했다. 코드를 GPL 에 법적으로 묶어두려던 FSF 의 정책은 한가지 예기치 못한 부작용을 가져왔다. FSF 는 20줄 이상의 개인적인 공헌에 대해서 저작권을 받아야 한다고 생각하기 때문에 시장모드를 사용하는 절차가 어려워졌다는 것이다. 이것은 GPL 의 코드가 저작권법 하에서 도전받는 것을 방지하기 위한 정책이다. BSD 와 MIT 의 X 콘소시엄 라이센스를 사용하여 저작권을 얻는사람은 이런 문제를 겪지 않는다. 그들은 누군가가 도전할 동기를 가질만한 권리를 가지려 하지 않는다. #132 정직한 (어니스트) [번역] 성당과 시장 (2/4) 09/09 17:23 317 line 4. 일찍, 그리고 자주 발표하라 일찍, 그리고 자주 발표하는 것은 리눅스 개발모델의 중요한 부분이다. 대부분의 개발자들은 (필자를 포함하여) 아주 사소한 프로젝트가 아니라면 이런 정책은 나쁜 것이라고 생각한다. 초기버전들은 예외없이 버그가 많고, 개발자라면 사용자들의 인내심을 시험하고 싶어하지 않기 때문이다. 이런 믿음이 성당건축 스타일의 개발을 더 선호하게 만들었다. 만일 가장 중요한 목표가 사용자들로 하여간 가능한 한 적은 버그를 발견하게 만드는 것이라면 6 개월에 한 번씩, 혹은 그보다 더 늦게 발표하면서 그동안 죽어라고 일하는 편이 나을 것이다. Emacs C 코어는 이런 식으로 개발되었다. Lisp 라이브러리는 그렇지 않았다. Emacs 의 발표주기와 관계없이 언제든 새로운 개발 코드 버전을 찾을 수 있으며, FSF 의 통제권 밖에 있는 Lisp 라이브러리들이 있었기 때문이다. 이들 중 가장 중요한 아카이브는 오늘날 대형 리눅스 아카이브들의 정신과 많은 기능들을 이미 가지고 있었던 오하이오 주 elisp 아카이브였다. 하지만 우리가 하고 있는 일에 대해, FSF 의 성당건축 개발모델의 문제점들에 대해 그 아카이브의 존제가 무엇을 제시하는지에 대해 우리들 중 소수만이 진지하게 생각하고 있었다. 나는 1992년에 오하이오 코드를 모다 공식적인 Emacs Lisp 라이브러리로 만들려는 시도를 했으나 정치적인 문제에 부딪쳤고, 큰 실패를 겪었다. 1년 후에, 리눅스가 널리 알려지기 시작했고, 무언가 다르면서도 훨씬 바람직한 일이 일어나고 있다는 것이 확실해 보였다. 리누스의 열린 개발정책은 성당건축과 완전히 반대되는 것이었다. 선사이트와 tsx-11 아카이브가 싹트고 있었고, 다중배포방식이 퍼지기 시작했다. 그리고 이 모든 것이 이전의 어느 소프트웨어보다 자주 릴리즈되는 코어시스템에 의해 주도되고 있었다. 리누스는 가장 효과적인 방식으로 사용자들을 공동개발자라고 여겼던 것이다. 7) 일찍 발표하고 자주 발표하라. 그리고 사용자들의 소리에 귀를 기울이라. (Release early. Release often. And listen to your customers) 리누스의 혁신은 그가 이렇게 했다는 점 보다는 (오랫동안 유닉스 세계의 전통이었던 것처럼) 그가 개발하고 있던 리눅스 커널의 복잡성에 비견될만한 수준으로까지 끌어올렸다는 데 있다. 초기에 (1991년 경에) 그는 하/루/에 한 번 이상 새로운 커널을 발표하기까지 했다. 리누스가 공동개발자들이라는 자신의 기반을 잘 만들었고, 인터넷이라는 지렛대를 이용하여 누구보다도 열심히 협동작업에 몰두했기 때문에 이런 방식은 성공했다. 하지만 어/떤 과정을 거쳐 성공했을까? 내가 재현할 수 있는 것일까, 아니면 리누스 토발즈만의 천재성이 필요한 것일까? 그렇게 생각되지는 않았다. 리누스가 매우 뛰어난 해커라는 점은 인정한다. (우리중에 상업용 제품 못지 않은 운영체제의 커널을 만들어낼 수 있는 사람이 몇이나 될까?) 하지만 리눅스는 놀랄만한 개념적 전진을 이루어내지는 않았다. 리누스는 리차드 스톨먼이나 제임스 고슬링 (NeWS 와 자바를 만든) 과 같은 혁신적인 설계를 이루어내는 천재는 (적어도 지금까지는) 아니없다. 대신 리누스는 공학의 천재인 것으로 보인다. 버그와 개발의 막다른 골목을 피하는 육감, 그리고 A 점에서 B 점까지 가는데 최소노력경로를 찾아내는 요령을 갖추고 있었다. 실제로 리눅스의 전반적인 설계는 이런 특성을 바탕으로 하고 있으며 리누스의 본질적으로 보수적이고 단순한 설계 방식을 반영하고 있다. 따라서 빠른 릴리즈와 인터넷을 매체로 사용하는 것은 우연히 이루어진 것이 아니라 리누스의 공학에 대한 천재성의 일부분으로 최소노력경로에 대한 통찰력으로 된 것이라면 그가 최대화 하고 있는 것은 무엇이었을까? 기계에서 무엇을 뽑아내었던 것일까? 해답은 질문 안에 있다. 리누스는 그의 해커/유저들에게 지속적인 자극과 보답을 제공했다. 리눅스 개발에 참여함으로써 자기만족을 얻으리라는 전망에 자극받았고, 그들이 하는 일이 계속해서 (어떤 때는 날/마/다) 향상되고 있다는 것이 보답이 되었다. 리누스는 코드의불안정성과 만일 처리하기 곤란한 심각한 버그가 발견되면 사용자들이 떨어져 나갈 것을 무릅쓰고 디버깅과 개발에 투입되는 공수(the number of person-hours)를 최대화 하는 것에 목표를 두었다. 리누스는 다음과 같은 신념을 가지고 있는 것처럼 행동했다. 8) 충분히 많은 베타테스터와 공동개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다. (Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone) 덜 형식적으로 말하자면, "눈알이 충분히 많으면 찾지 못할 버그는 없다". 나는 이것을 "리누스의 법칙" 이라고 부른다. 내 원래의 공식적인 서술은 모든 문제는 "누군가에게는 간단할 것이다" 였다. 리누스가 문제를 이해하고 고치는 사람이 그 문제를 처음 파악한 사람과 항상 같은 것이 아니라 오히려 다를 경우가 더 많다고 이의를 제기했다. 리누스 말로는 "누군가 문제를 발견합니다. 그리고 또/다/른 누군가가 그 문제를 이해하지요. 문제를 발견해 내는 것이 더 중요한 일이라고 분명히 말할 수 있습니다." 하지만 가장 중요한 점은사람이 충분히 많을 경우 이 두 가지가 모두 매우 빨리 일어나는 경향이 있다는 것이다. 내 생각에는 여기에 성당건축과 시장 스타일의 핵심적인 차이점이 있다. 프로그래밍의 성당건축가의 관점에서 보자면 버그와 개발 문제는 어렵고, 까다로우며 심오한 현상이다. 문제를 해결하려면 헌신된 소수의 사람이 몇 달이고 정밀한 검사를 수행해야 모두 끝났다는 확신을 가질 수 있다. 따라서 발표 사이의 기간이 길어지고, 오랫동안 기다린 릴리즈가 완벽하지 않을 때는 필연적으로 실망이 따른다. 반면, 시장의 관점에서는 버그가 보통 쉽게 해결할 수 있는 것이라고 본다 - 최소한 새로운 릴리즈가 나올때마다 그것과 씨름하는 수천의 열정적인 공동개발자들에게 알려진다면 금방 쉽게 해결할 수 있는 문제로 바뀐다. 따라서 더 많이 교정을 받고 싶다면 자주 발표해야 하며 덤으로 서투른 부분이 드러나더라도 덜 창피하게 되는 이점이 있다. 바로 이것이다. 이것으로 충분하다. "리누스의 법칙" 이 틀렸다면 리눅스 커널과 같이 복잡한 시스템은 어떤 것이라도 수많은 손들에 의해 해킹되면서 일찍이 볼 수 없었던 나쁜 상호작용과 발견되지 못한 "심오한' 버그들에 의해 어느 시점에선가 붕괴되고 말았을 것이다. 반면에, 만일 그 법칙이 옳다면 그 법칙만으로도 리눅스의 상대적으로 적은 버그를 설명할 수 있다. 그리고 이 법칙이 옳다는 점에 대해서는 너무 놀라지 않았어야 할 것이다. 수년 전, 사회학자들은 비슷하게 전문적인 (혹은 비슷하게 무지한) 관찰자들로 이루어진 대중의 평균적인 의견이 그 관찰자 중 무작위로 뽑은 한 명의 의견보다 더 신뢰할 만하다는 점을 발견했다. 사회학자들은 이것을 "델파이 효과" 라고 부른다. 리누스가 보여준 것은 이 효과가 운영체제를 디버깅하는 데에도 적용될 수 있다는 점이다. 델파이 효과는 OS 커널만큼 복잡한 개발까지도 다룰 수 있는 것이다. 고맙게도 제프 덧키(Jeff Dutck) 는 리누스의 법칙을 "디버깅은 병렬처리가 가능하다" 는 말로 표현할 수 있음을 지적해 주었다. 제프는 디버거들이 디버깅을 하려면 의사소통을 조정해주는 개발자가 필요하지만 디버거들 사이에는 그다지 조정이 필요하지 않다고 진술한다. 따라서 개발자를 추가하는데서 생기는 기하급수적인 복잡성과 관리의 어려움이 디버깅에는 짐이 되지 않는다. 실제로 리눅스 세계에서는 디버거의 작업이 중복됨으로써 생기는 이론적인 효율의 저하가 거의 문제되었던 적이 없는 것으로 보인다. "빨리, 그리고 자주 발표하는 정책" 의 효과 중 하나는 피드백 되어오는 수정사항을 빨리 전파함으로써 중복이 최소화된다는 것이다. 브룩스(Brooks)는 제프의 진술과 관련하여 즉석에서 다음과 같은 말을 했다. "널리 사용되는 프로그램의 유지보수에 들어가는 비용은 보통 개발시 드는 비용의 40 퍼센트나 그 이상입니다. 놀랍게도 이 비용은 사용자의 수에 큰 영향을 받습니다. 더/많/은 사/용/자/들/이 더/많/은 버/그/들/을 찾/아/냅/니/다." (필자의 강조) 사용자들이 많아지면 프로그램을 시험해보는 방법이 더 늘어나기 때문에 버그를 더 많이 잡아낼 수 있다. 이 효과는 사용자들이 공동개발자들일 때 더욱 커진다. 각 사람들이 버그를 찾아낼 때 조금씩 다른 개념의 집합과 분석 도구들을 사용하여 문제의 다른 각도에서 접근하기 때문이다. "델파이 효과" 는 바로 이런 편차에서 비롯되는 것으로 보인다. 또한 디버깅이라는 특정한 환경에서 이 편차는 노력의 중복을 줄여주는 경향이 있다. 따라서 더 많은 베타테스터를 가지는 것은 개/발/자/의 관점에서 현재의 "가장 심오한" 버그의 복잡성을 줄여주지는 않을 테지만, 누군가의 도구가 문제에 딱 들어맞아 그 버그가 그/사/람/에/게/는 쉽게 잡을 수 있는 것이 될 가능성을 높여준다. 리누스도 물론 할 일이 있었다. 심각한 버그가 있/을 경우에 대비해 리눅스 커널 버전은 잠재 사용자들이 최종적으로 "안정된" 버전을 사용할 수도 있고 새로운 기능을 사용하기 위해 최신의 버그가 있을 수 있는 버전을 사용할 수도 있게 번호가 붙여졌다. 이 전술은 아직까지 대부분의 리눅스 해커들이 따라하지는 않고 있지만 아마도 따라하게 될 것이다. 두 가지 선택이 가능하다는 사실이 양쪽 모두를 더 매력적으로 보이게 한다. 5. 장미가 장미다우려면 리누스의 행동을 연구하고 그것이 왜 성공적이었는지에 대한 이론을 만든 후, 나는 이 이론을 내 새로운 프로젝트 (물론 훨씬 덜 복잡하고 덜 야심적인 프로젝트) 에 적용해 보기로 했다. 그러나 내가 가장먼저 한 일은 popclient를 더 재조직화하고 단순화한 것이었다. 칼 해리스 (Carl Harris) 의 구현방식은 매우 건강한 것이었지만 많은 C 프로그래머들에게서 볼 수 있었던 것처럼 일종의 불필요한 복잡성을 보여주고 있었다. 그는 코드를 중심적인 것으로, 자료구조는 코드를 받쳐주는 것으로 취급했다. 그 결과 코드는 아름답지만 자료구조는 임시변통으로 설계되었고, 보기에 좋지 않았다. (최소한 옛 LISP 해커의 높은 기준에서 보자면 말이다) 그리고 코드와 자료구조를 개선하는 것 말고도 나는 또다른 목적을 하지고 있었다. popmail을 내가 완전히 이해하는 무엇인가로 진화시키고 싶었다. 이해하지 못하는 프로그램의 버그수정책임을 맡는 것은 괴로운 일이다. 처음 한달 정도가 지날 동안 나는 그저 칼의 기본적인 설계가 어떤 의미를 가지고 있는지 따라다니기만 했다. 내가 처음으로 중요한 수정을 가한 것은 IMAP 지원이었다. 프로토콜 머신을 일반적인 드라이버와 세가지 메소드 테이블 (POP2, POP3, IMAP을 지원하는) 로 재조직했다. 이것과 그 이전의 변경들은 프로그래머들이 기억해 둘만한 일반적인 원리를 보여준다. 특히 C 와 같이 즉흥적으로 프로그램하기 힘든 언어에서는. 9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다. (Smart data structures and dumb code works a lot better than the other way around) 브룩스의 책 9 장(Chapter 9) 에 이렇게 쓰여있다. "내게 [코드]를 보여주고 [자료구조]를 숨긴다면 나는 계속 어리둥절할 것이다. 자료구조를 보여준다면 코드는 볼 필요도 없이 뻔한 것이다." 사실 브룩스는 "흐름도" 와 "테이블" 이라고 이야기했다. 하지만 30년간 변해온 용어들과 문화를 고려한다면 거의 똑같은 말이라고 할 수 있다. 이 시점에서 (1996년 9월 초, 일을 시작하고 6 주가 지난 후) 나는 이름을 바꿀 때가 되었다고 생각하기 시작했다. 이 프로그램은 더 이상 POP 클라이언트만이 아니었다. 하지만 설계상에 정말 새로운 것이 들어가 있지 않았기 때문에 머뭇거리고 있었다. 내가 만든 popclient 는 아직 스스로의 정체성을 확립하지 못하고 있었다. fetchmail 이 어떻게 SMTP 포트로 가져온 메일을 포워드 시켜야 하는지 알고 난 후에는 상황이 급변할 것이었다. 잠시 후면 그렇게 될 것이 분명했다. 하지만 그보다 먼저, 앞서 나는 리누스 토발즈가 옳은 방법으로 일을 해냈다는 내 이론을 시험하기 위해 이 프로젝트를 수행하기로 했다고 말했다. 어떻게 시험을 했을까? 다음과 같은 방법을 사용했다. (1) 일찍, 자주 발표했다. (발표간격이 10일을 넘는 경우는 거의 없었으며 개발에 몰두해 있을 때는 하루에 한번씩 발표했다) (2) fetchmail 에 대한 일로 나와 접촉하는 사람은 누구든지 베타테스터 목록에 올렸다. (3) 새로 발표할 때마다 베타테스터들에게 떠들썩하게 발표를 알리며 사람들이 참여하도록 격려했다. (4) 그리고 그들의 이야기를 들었다. 설계 결정에 대해 투표를 하기도 했고 패치나 피드백을 보내올 때마다 베타테스터들을 구슬렀다. 이 단순한 방법들은 즉각 효력을 나타냈다. 프로젝트를 시작할 때부터 개발자들이라면 학수고대할 만한 버그 리포트를, 때로는 훌륭하게 수정된 코드를 받을 수 있었다. 사려깊은 비판과 팬 메일, 기능제안들을 받았다. 이것은 10) 베타테스터들을 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다. (If you treat your beta-testers as if the're your most valuable resource, they will respond by becoming your most valuable resource) fetchmail 의 성공을 재는 재미있는 척도 중 하나는 프로젝트 베타테스터 메일링리스트인 fetchmail-friends 의 크기이다. fetchmail을 개발하고 있을 때 목록에는 249 명이 있었고 1주일에 2-3 명이 추가되었다. 1997 년 5월말 경에 수정을 했을 때 목록은 300명 가까이 되었고, 멤버들이 흥미로운 이유 때문에 조금씩 줄기 시작했다. 몇몇 사람들이 구독을 중단하면서 fetchmail 이 잘 작동하기 때문에 더 이상 메일링리스트를 보고 있을 이유가 없다고 말했다. 아마 이것이 성숙한 시장 스타일의 프로젝트가 가지는 일반적인 라이프사이클 중 하나일 것이다. 6. Popclient가 Fetchmail이 되다 fetchmail 프로젝트에서 큰 전환이 일어났던 것은 해리 호흐하이저(Harry Hochheiser) 가 클라이언트 머신의 SMTP 포트로 메일을 포워딩하는 대략적인 코드를 보내준 때였다. 보자마자 이 기능을 안정적으로 구현한다면 다른 모든 배달 방법은 구식이 되리라는 것을 깨달았다. 여러 주 동안 나는 fetchmail을 조금씩 뜯어고치고 있었는데, 인터페이스 설계가 작동하긴 하지만 지저분하다고 느끼고 있었다. 우아하지도 않고 몇 안되는 옵션들이 너무 여기저기 흩어져 있었다. 가져온 메일을 메일박스 파일에 부어놓을 것인지, 표준출력으로 내보낼 것인지 결정하는 옵션이 특히 골치거리였지만 왜 그런지 확실히 깨닫지는 못했다. SMTP 포워딩을 생각하자 그동안 popclient 가 너무 많은 것을 해내려고 했다는 것을 알게 되었다. poopclient 는 MTA (Mail Transport Agent) 와 MDA (Mail Delivery Agent) 기능을 모두 가지도록 설계되었다. SMTP 포워딩만 할 수 있다면 MDA 기능을 없애 순수한 MTA 가 될 수 있었다. sendmail 과 마찬가지로 최종적인 메일 배달은 다른 프로그램에게 맡기면 되는 것이다. TCP/IP를 지원하는 플랫폼이라면 거의 어디에나 25번 포트가 기다리고 있는데 무엇 때문에 복잡한 MDA 기능을 설정하거나 메일박스를 잠그고 덧붙이는 (lock-and-append) 문제를 가지고 고생을 하는가? 더구나 포워딩을 사용하면 가져온 메일이 평범한 SMTP 메일처럼 보일 것이고, 우리가 원하는 것이 바로 그것이었는데 말이다. 몇가지 배울 점이 있었다. 먼저, SMTP 포워딩에 대한 아이디어는 내가 리누스의 방법을 모방하려고 의식적으로 노력한 것에 대한 가장 큰 보답이었다. 사용자 한 명이 내게 끝내주는 아이디어를 주었다. 내가 해야했던 일은 그 의미를 이해하는 것 뿐이었다.

1998 by swindler