Eric Steven Raymond
Copyright: Permission is granted to copy, distribute and/or modify this doucument under the terms of the Open Publication License, version 2.0.
성공적인 오픈 소스 프로젝트인 fetchmail에 대해서 분석한다. 이 프로젝트는 리눅스 역사에 의해 제시된 놀라운 소프트웨어 엔지니어링 이론을 신중하게 테스트하기 위해 실행된 것이다. 이 이론들을 근본적으로 두 가지 개발 스타일, 즉 상업 세계의 대부분의 대한 성당모델과 리눅스 세계의 시장모델의 관점에서 논할 것이다. 이 모델들이 소프트웨어 디버깅 작업의 본질에 대한 서로 대립되는 가설으로부터 파생된다는 것을 보일 것이다. 그리고 나서 “충분한 눈들이 있다면, 찾을 수 없는 버그는 없다”라는 제의를 위한 리눅스 경험에서 지속적인 논쟁을 만들었고 다른 이기적인 에이전트의 자가 정정 시스템과 함께 생산적인 비유를 제안했으며 미래의 소프트웨어를 위한 통찰력에 관한 결과의 탐구로 마무리짓는다.
- 성당과 시장
- 메일은 반드시 배달되어야만 한다.
- 사용자가 있다는 것의 중요성
- 일찍, 자주 발표하라.
- 얼마나 많은 눈이 문제를 지켜보는가
- 장미가 장미다우려면
- Popclient가 Fetchmail이 되다.
- Fetchmail의 성장
- Fetchmail에서 배울 점
- 시장 스타일에 필요한 전제 조건
- 오픈소스 소프트웨어의 사회적 맥락
리눅스는 파괴적이다. 5년 전 (1991년)만 해도 그 누가 세계 정상급 운영 체제가 이너넷을 통해 지구상의 흩어진 수천명의 개발자들이 파트타임으로 개조하여 마술처럼 융합 할 수 있다고 생각했을까요? 물론 나는 아닙니다. 리눅스가 나의 레이더 화면에 잡혔을 때는 1993년 쯤이며, 저는 이미 10년 동안 유닉스와 오픈소스 개발에 참여해 왔습니다. 저는 1980년 중반 최초의 GNU 기여자 중에 한 명입니다. 나는 많은 양의 오픈소스 소프트웨어를 인터넷에 공유했으며, 개발했거나 공동한 개발한 프로그램들은 (nethack, Emacs's VC and GUD 모드들, xlife와 기타 등등) 오늘날에도 전세계적으로 사용된다. 나는 프로그램이 어떻게 개발되어야 하는지 알고 있다고 생각했다.
리눅스는 내가 알고 있다고 생각한 많은 부분을 뒤집어 버렸다. 수 년 동안 나는 작은 도구, 빠른 프로토타이핑, 그리고 진화적인 프로그래밍을 여러 해 동안 유닉스의 복음으로 설교해 오고 있었다. 그러나 나는 어떠한 종류의 중요한 복잡성이 있어서 거기에 더 집중되고 선험적인 접근방법이 필요하다고 믿고 있었다. 가장 중요한 소프트웨어(운영체제나 Emacs 같이 엄청나게 큰 도구들)는 성당을 건축하듯이, 즉 찬란한 고독 속에서 일하는 몇 명의 프로그래머 귀재들이나 작은 그룹의 마법사들에 의해 조심스럽게 만들어지고 때가 되기 전에 출시되는 베타버전도 없어야 한다고 믿었다.
리누스 토발즈의 개발 스타일은 -- 일찍, 그리고 자주 발표하며 다른 사람들에게 위임할 수 있는 것은 모두 위임하고, 난잡한 부분까지 공개하는 것 -- 놀라움으로 다가왔다. 고요하고 신성한 성당의 건축은 찾아볼 수 없었으며, 리눅스 공동체는 서로 다른 의견과 접근방법이 난무하는 매우 소란스러운 시장같았다. (리눅스 아카이브 사이트가 상징하고있다. 누구나 파일을 올릴 수 있다) 이런 곳에서 일관성있고 안정적인 시스팀이 나온다는 것은 외견상으로는 기적에 의해서 성공한 것으로 보인다.
시장 스타일이 작동하고 심지어 잘 작동한다는 사실은 분명한 충격으로 다가왔다. 내 주관대로 배우면서, 나는 개인 프로젝트만 열심히 했을 뿐만 아니라, 리눅스 세계가 혼돈에 의해 각각 분리되지 않고 성당 건설자들의 속도와 비슷하게 직진할 수 있었는가를 이해하려했다.
1996년 중반에야 내가 이해를 하기 시작했다고 생각했다. 내 이론을 완벽하게 시험해 볼 수 있는 기회가 오픈 소스 프로젝트의 형태로 찾아왔다. 그래서 나는 시험했고, 그것은 눈에 띄는 성공이었다.
위 글은 프로젝트의 스토리에 관한 내용이다. 나는 이 스토리를 효과적인 오픈소스 개발에 관한 몇 개의 격언을 제안하기 위해 사용할 것이다. 이 모든 것들은 내가 리눅스 세계에서 처음으로 배운 것은 아니지만, 리눅스 세계가 그들에게 특별한 점을 어떻게 제공하는지 보게 될 것이다. 만약 내가 맞는다면, 그들은 리눅스 공동체를 훌륭한 소프트웨어의 샘으로 만드는 것이 무엇인지 정확히 이해할 수 있게 도와 줄 것이며, 아마 여러분들이 스스로 더 생산적으로 될 수 있도록 도울 것입니다.
1993년에 나는 펜실베니아 주, 웨스트 체스터의 작은 무료 IPS인 체스터 카운티 인터링크 (Chester County InterLink)에서 기술적인 부분을 담당하고 있었다. 나는 CCIL의 공동 설립자였으며 우리의 고유한 멀티유저 게시판 소프트웨어를 작성했다. -- locke.ccil.org에 telnet을 통해 확인할 수 있다. 오늘날 이것은 3000명의 유저를 30개의 회선으로 지원할 수 있다. 이 일은 나에게 하루 24시간동안 CCIL의 56K 회선을 통해서 네트워크에 접속할 수 있도록 하였다. -- 사실, 그렇게 해야만 했다.
나는 인스턴트 인터넷 이메일에 익숙해 있었다. 나는 정기적으로 telnet 위에 있는 locke를 통해서 성가시게 나의 메일을 확인해야했다. 내가 원하는 것은 내 메일이 snark(나의 집 시스템)로 수신되면 내가 알수있고 로컬 도구들을 이용해 메일을 다룰 수 있게 되는 것이었다.
SMTP (Simple Mail Transfer Protocol)이라 불리는 인터넷의 기본적인 메일 포워딩 프로토콜은 내 요구사항에 맞지않았는데 컴퓨터가 상시 연결되어 있어야만 잘 작동했기 때문이다. 내 개인 컴퓨터는 항상 연결되어 있지 않았고 정적 아이피 주소를 가지고 있지도 않았다. 내가 필요한 것은 간헐적 다이얼 업 연결을 통해 내 메일들을 가정 컴퓨터로 배달되는 프로그램이었다. 나는 이미 이런것들이 있다는 것을 알았고 대부분은 POP (Post Office Protocol)이라 부르는 간단한 어플리케이션 프로토콜을 사용했었다. POP은 현재 대부분의 메일 클라이언트들을 지원하지만 당시에 내가 사용하던 메일 리더에는 내장되어 있지 않았다.
나는 POP3 클라이언트가 필요했었고 그래서 나는 인터넷에서 하나를 찾았다. 실질적으로, 3개에서 4개였다. 그것들 중에 하나를 잠시 사용했지만 그것은 분명한 특징을 놓치고 있었다. 가져온 메일에서 주소를 변경하여 답장을 보내는 기능이었다.
문제는 이것이었는데 locke 내에서 'joe'라는 이름을 가지고 있는 사람이 나에게 메일을 보낸다 가정했을때 만약 내가 snark로 메일을 가져오고 그것에 답장을 하려고 시도했을때 존재하지않은 snark 내에서 'joe'라는 이름으로 보내려고 한다. 문제를 해결하기 위해서는 @ccil.org를 수작업으로 붙어줘야하는데 이것은 심각한 문제가 되었다.
이것은 분명히 컴퓨터가 나를 위해 해야한다. 그러나 존재하는 어느 POP 클라이언트들 중에 이 방법을 알고있는 것은 없었다. 그리고 이러한 일들은 우리를 첫번째 교훈으로 이끈다.
1. 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다.
명확해 보이는 교훈이긴 하지만 ("필요는 발명의 어머니" 라는 오래된 속담이 있다) 소프트웨어 개발자들은 너무 자주, 단지 돈 때문에 그들이 필요로 하지도 않고 좋아하지도 않는 프로그램을 만들어 내는데 시간을 쓰고 있다. 하지만 리눅스 세계에서는 그렇지 않다 -- 아마도 이것이 왜 리눅스 공동체에서 만들어진 소프트웨어들의 평균적이 품질이 그렇게나 좋은지를 설명해줄 것이다.
그래서 내가 이미 존재하는 POP3 클라이언트들과 경쟁하기 위해서 새로운 클라이언트들 곧바로 코딩하기 시작했을까? 천만에! 나는 이미 가지고 있는 POP 유틸리티들을 살피면서 스스로에게 물었다. "이 중에서 내가 원하는 것과 가장 가까운게 무엇일까?" 그 이유는
2. 좋은 프로그래머들은 어떻게 작성해야하는지 알고 있다. 위대한 프로그래머는 무엇을 다시 작성해야하는지 알고 있다.
내가 위대한 프로그래머가 되라는 말은 아니지만 흉내내려고했다. 위대한 프로그래머의 중요한 특징 중 하나는 건설적인 게으름이다. 그들은 들인 노력으로가 아니라 결과로 평가받는다는 것을 알고 있으며 완전한 무에서 시작하는 것보다는 좋은 부분적 해결법에서 시작하는 것이 거의 항상 더 쉽다는 것을 알고 있다.
리누스 토발즈를 예로 들자면 밑바닥부터 리눅스를 만들려하지 않았다. 대신 그는 PC 클론들을 위한 작은 유닉스와 같은 Minix의 아이디어와 코드를 재사용하는 것으로부터 시작했다. 결국 모든 Minix 코드는 사라지거나 새로 쓰여졌다 -- 하지만 Minix 의 코드가 남아있을 동안 그 코드는 나중에 Linux 가 될 어린 아기의 발판 역할을 했다.
똑같은 생각으로 나는 이미 있는 POP 유틸리티 중 코딩이 잘 되어있는 것을 찾아 개발의 기초로 사용하려 했다.
Unix 세계의 소스 공유하는 전통은 소스 재사용에 대해 호의적이었다 (GNU 프로젝트가 Unix 자체에 대한 심각한 의혹에도 불구하고 Unix를 기본 OS로 선택한 이유였다). 리눅스 세계는 거의 기술적 한계에 다다를 때까지 이 전통을 받아들였다. 일반적으로 사용 가능한 오픈 소스가 수 테라바이트에 달했다. 그래서 리눅스 세계에서는 다른 어느 곳에서보다 누군가의 거의 완성된 소스를 찾아보는데 시간을 들이는 것이 좋은 결과를 가져다 줄 가능성이 높다.
나에게도 역시 그랬다. 나는 Carl Harris의 popclient 코드가 눈에 띄었고 문제를 찾았다. fetchpop에는 훌륭한 독창적인 아이디어가 들어 있었지만 (백그라운드-데몬 모드와 같은 것) POP3만으로 처리할 수 있었고, 아마추어 티가 나는 코딩이었다. (오승홍씨는 똑똑하기는 하지만 경험이 부족한 프로그래머였으며 그 두가지 특징을 코등에서 볼 수 있었다). Carl의 코드는 전문가가 만든 탄탄하면서 더 나는 코드였으나 몇가지 중요하면서도 구현하기 위해서는 약간의 잔머리가 필요한 fetchpop의 기능들이 (내가 추가한 기능들을 포함해서) 빠져 있었다.
머물러 있을 것인가, 옮겨갈 것인가? 옮겨간다면 더 나은 개발기반을 위해 이미 해놓은 코딩을 포기해야만 했다.
옮겨가는데 실질적인 동기가 되었던 것은 다중 프로토콜 지원 여부였다. POP3 가 포스트-오피스 서버 프로토콜 중에서 가장 널리 쓰이는 것이긴 했지만 유일한 프로토콜은 아니었다. fetchpop 을 비롯하여 다른 경쟁자들은 POP2, RPOP, 또는 APOP 를 지원하지 않았고, 나는 당시에 재미삼아서 IMAP(Internet Message Access Protocol, 가장 최근에 고안되었으며 가장 강력한 우체국 프로토콜) 을 지원해 볼까 하는 생각을 가지고 있었다.
하지만 옮겨가는 것이 좋은 생각이라는 좀 더 이론적인 이유도 가지고 있었다. 리눅스를 알기 오래전에 배운 교훈이었다.
3. "가지고 있는 것을 버릴 계획을 세우라; 어떻게든 버리게 될 것이다." (Fred Brooks, The Mythical Man-Month, Chapter 11)
다른 말로 하자면, 첫 번째 해결책을 구현할 때까지 진짜 문제가 무엇인지 이해하지 못하는 경우가 종종 있다는 것이다. 두 번째가 되어서야 어떻게 하는 것이 옳은 것인지 충분히 알게 될 수 있따. 따라서 만약 올바른 방법을 찾고 싶다면 최소한 한 번은 처음부터 시작하는 것이었다.
fetchpop을 고친 것은 내 첫 시도였고 popclient로 변경했다.
1996년 6월 25일에 Carl Harris에게 내 첫 번째 popclient 패치들은 보낸 후, 나는 그가 popclient에 대한 흥미를 이미 잃었다는 것을 알게 되었다. 코딩이 좀 지저분했고, 자잘한 버그들이 널려있었다. 내가 수정해야 할 것이 많았고, 우리는 프로그램을 넘겨받는 것이 합리적이라는 데에 동의하게 되었다.
내가 알아차리지 못하는 새에 프로젝트는 차츰 궤도에 오르기 시작했다. 나는 이미 존재하고 있는 POP 클라이언트의 마이너 패치를 생각하는 것이 아니었다. 클라이언트 하나를 통채로 관리하고 있었으며 내 머리에서는 커다란 변화가 될 아이디어들이 솟아나고 있었다.
코드 공유를 장려하는 소프트웨어 문화에서는 이런 방식으로 프로젝트가 진화하기 마련이다. 이렇게 말할 수 있다.
4. 만약 당신이 올바른 태도를 가지고 있으면, 흥미로운 문제들이 당신을 찾을 것이다.
그러나 Carl Harris's의 태도가 훨씬 더 중요했다. 그는 이것을 이해하고 있었다.
5. 프로그램에 흥미를 잃었다면, 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다.
토론할 필요도 없이 Carl과 가는 가장 좋은 해결책을 찾고 있다는 것을 알고 있었다. 우리에게 남아있는 한가지 문제는 내가 적임자라는 것을 입증할 수 있느냐 하는 것이었다. 내가 그것을 증명하자 그는 기꺼이, 그리고 신석하게 행동했다. 내가 그렇게 내 차례가 되었을 때 나도 그만큼 잘 할 수 있기를 바란다.
나는 popclient를 넘겨받았다. 동시에 popclient의 사용자들도 넘겨받았다.
6. 사용자들을 공동개발자로서 생각한다면 코드가 다른 어떤 방법보다 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.
이는 오픈소스 세계에서 리누스 토발즈가 명확하게 보여주었다.
나는 리누스가 했던 해킹중 가장 중요한 것은 리눅스 개발 모델을 만들었다는 점이라고 생각한다. 리눅스의 성공은 GNU Emacs Lisp 라이브러리와 Lisp 코드 아카이브에서 선례를 찾아볼 수 있는데, 이는 다른 성당건축 스타일과는 대조적으로 유동적이고 사용자가 주도하였다.
이를 미루어 봤을때 내가 fetchmail 이전에 했던 가장 성공적인 해킹은 아마 Emacs VC 모드였을 것이다. 세 명의 사람들은 email을 통해 리눅스와 비슷한 협동작업을 하였고, 이를통한 VC의 개발은 Emacs와는 다르게 Emacs Lisp 코드가 발표/테스트/개선의 주기를 매우 빨리 반복할 수 있었기 때문에 성공하였다.
코드를 법적으로 GPL(자유 소프트웨어 재단에서 만든 자유 소프트웨어 라이선스 - 엮은이)에 묶으려는 FSF(자유 소프트웨어 재단(Free Software Foundation) - 엮은이)의 정책은 시장모드를 사용하는 것을 절차적으로 까다롭게 만드는 부작용을 가져왔다. 그들은 GPL 코드를 저작권법 하에서의 도전으로부터 면역시키기 위해 20줄 이상의 개인적인 공헌에 대해서는 저작권을 주어야 한다고 믿기 때문이다.
일찍, 그리고 자주 발표하는 것은 리눅스 개발 모델의 중요한 부분이다. 대부분의 개발자들은 (필자를 포함하여) 아주 사소한 프로젝트가 아니라면 이런 정책은 나쁜 것이라고 생각했다. 초기버전들은 예외없이 버그가 많고, 개발자라면 사용자들의 인내심을 시험하고 싶지는 않기 때문이다.
이런 믿음이 성당건축(Cathedral) 스타일의 개발을 더 선호하게 만들었다. 만일 가장 중요한 목표가 사용자들로 하여금 가능한 한 적은 버그를 발견하게 만드는 것이라면 6 개월에 한 번씩 (혹은 그보다 더 늦게) 발표하면서 그동안 죽어라고 일하는 편이 나을 것이다. Emacs C 코어는 이런 식으로 개발되었다. Lisp 라이브러리는 그렇지 않았다. Emacs 의 발표주기와 관계없이 언제든 새로운 개발 코드 버전을 찾을 수 있으며, FSF 의 통제권 밖에 있는 Lisp 라이브러리들이 있었기 때문이다.
이들 중 가장 중요한 아카이브는 오늘날 대형 리눅스 아카이브들의 정신과 많은 기능들을 이미 가지고 있었던 오하이오 주의 elisp 아카이브였다. 하지만 우리가 하고 있는 일에 대해, FSF 의 성당건축(Cathedral) 개발모델의 문제점들에 대해 그 아카이브의 존재가 무엇을 제시하는지에 대해 우리들 중 소수만이 진지하게 생각하고 있었다. 나는 1992년에 오하이오 코드를 공식적인 Emacs Lisp 라이브러리에 정식으로 병합시키려는 시도를 했으나 정치적인 문제에 부딪쳤고, 큰 실패를 겪었다.
1년 후에, 리눅스가 널리 알려지기 시작했고, 무언가 다르면서도 훨씬 바람직한 일이 일어나고 있다는 것이 확실해 보였다. 리누스의 열린 개발정책은 성당건축과 완전히 반대되는 것이었다. 선사이트와 tsx-11 아카이브가 싹트고 있었고, 다중배포방식이 퍼지기 시작했다. 그리고 이 모든 것이 들어보지 못한 방법의 자주 릴리즈 되는 코어시스템에 의해 주도되고 있었다.
리누스는 가장 효과적인 방식으로 사용자들을 공동개발자라고 여기고 있었던 것이다.
7. 일찍, 자주 발표하고, 소비자들에게 귀를 기울여라.
리누스의 혁신은 그가 이렇게 했다는 점 보다는 (그 비슷한 것이 오랫동안 유닉스 세계의 전통이었다) 그가 개발하고 있던 리눅스 커널의 복잡성에 비견될만한 수준으로까지 끌어올렸다는 데 있다. 초기에 (1991년 경) 그는 하루에 한 번 이상 새로운 커널을 발표하기까지 했다. 리누스가 공동개발자들이라는 자신의 기반을 잘 만들었고, 인터넷이라는 지렛대를 이용하여 누구보다도 열심히 협동작업에 몰두했기 때문에 이런 방식은 성공했다.
하지만 어떤 과정을 거쳐 성공할 수 있었을까? 내가 재현할 수 있는 것일까, 아니면 리누스 토발즈만의 천재성이 필요한 것일까?
그렇게 생각되지는 않았다. 리누스가 매우 뛰어난 해커라는 점은 인정한다. (우리중에 상업용 제품 못지 않은 운영체제의 커널을 만들어낼 수 있는 사람이 몇이나 될까?) 하지만 리눅스는 놀랄만한 개념적 전진을 이루어내지는 않았다. 리누스는 리차드 스톨먼이나 제임스 고슬링 (NeWS 와 Java를 만든) 과 같은 혁신적인 설계를 이루어내는 천재는 (적어도 지금까지는) 아니었다. 대신 리누스는 공학의 천재인 것으로 보인다. 버그와 개발의 막다른 골목을 피하는 육감, 그리고 A 점에서 B 점까지 가는데 최소노력 경로를 찾아내는 요령을 갖추고 있었다. 실제로 리눅스의 전반적인 설계는 이런 특성을 바탕으로 하고 있으며 리누스의 본질적으로 보수적이고 단순한 설계 방식을 반영하고 있다.
따라서 빠른 릴리즈와 인터넷을 매체로 사용하는 것이 우연히 이루어진 것이 아니라 리누스의 공학적 천재성에 기인한 최소노력 경로에 대한 통찰력의 통합적인 부분이었다면 그가 최대화하고 있는 것은 무엇이었을까? 기계에서 무엇을 뽑아내었던 것일까?
해답은 질문 안에 있다. 리누스는 그의 해커/사용자들에게 지속적인 자극과 보답을 제공했다 -- 리눅스 개발에 참여함으로써 자기만족을 얻으리라는 전망에 자극받았고, 그들이 하는 일이 계속해서 (어떤 때는 날마다) 향상되고 있다는 것이 보답이 되었다.
리누스는 만일 처리하기 곤란한 심각한 버그가 발견되면 사용자들이 떨어져 나갈 위험과 코드가 불안정해질 가능성을 무릅쓰고 디버깅과 개발에 투입되는 공수(the number of person-hours)를 최대화 하는 것에 목표를 두었다. 리누스는 다음과 같은 신념을 가지고 있는 것처럼 행동했다.
8. 충분히 많은 베타테스터와 공동개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다.
덜 형식적으로 말하자면, "보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다." 나는 이것을 리누스의 법칙 이라고 부른다.
내 원래의 공식적인 서술은 모든 문제는 "누군가에게는 간단할 것이다" 였다. 리누스는 문제를 이해하고 고치는 사람이 그 문제를 처음 파악한 사람과 항상 같은 것이 아니라 오히려 다른 경우가 더 많다고 이의를 제기했다. 리누스의 얘기로는, "누군가 문제를 발견합니다. 그리고 또다른 누군가가 그 문제를 이해하지요. 문제를 발견해 내는 것이 더 중요한 일이라고 분명히 말할 수 있습니다." 하지만 가장 중요한 점은 사람이 충분히 많을 경우 이 두 가지(발견하는 것과 고치는 것)가 모두 매우 빨리 일어나는 경향이 있다는 것이다.
내 생각에는 리누스의 법칙 에는 성당 건축(The Cathedral) 과 시장 스타일(The Bazaar) 의 핵심적인 차이점이 있다. 프로그래밍의 성당 건축가 관점에서 보자면 버그와 개발 문제는 어렵고, 까다로우며 심오한 현상이다. 문제를 해결하려면 헌신적인 소수의 사람이 몇 달이고 정밀한 검사를 수행해야 모두 끝났다는 확신을 가질 수 있다. 따라서 발표 사이의 기간이 길어지고, 오랫동안 기다린 릴리즈가 완벽하지 않을 때는 필연적으로 실망이 따른다.
반면, 시장의 관점에서는 버그가 보통 쉽게 해결될 수 있는 것이라고 본다 -- 최소한 새로운 릴리즈가 나올때마다 그것과 씨름하는 수천의 열정적인 공동개발자들에게 알려진다면 금방 쉽게 해결할 수 있는 문제로 바뀐다. 따라서 더 많이 교정을 받고 싶다면 자주 발표해야 하며 덤으로 서투른 부분이 드러나더라도 잃을 것이 적다는 이점이 있다.
바로 이것이다. 이것으로 충분하다. "리누스의 법칙" 이 틀렸다면 리눅스 커널과 같이 복잡한 시스템은 어떤 것이라도 수많은 손들에 의해 해킹되면서 일찍이 볼 수 없었던 나쁜 상호작용과 발견되지 못한 "심오한" 버그들에 의해 어느 시점에선가 붕괴되고 말았을 것이다. 반면에, 만일 그 법칙이 옳다면 그 법칙만으로도 리눅스의 상대적으로 적은 버그를 설명할 수 있다.
그리고 이 법칙이 옳다는 것에 대해서 너무 놀라지 말아야할 것이다. 수년 전, 사회학자들은 비슷하게 전문적인 (혹은 비슷하게 무지한) 관찰자들로 이루어진 대중의 평균적인 의견이 그 관찰자 중 무작위로 뽑은 한 명의 의견보다 더 신뢰할 만하다는 점을 발견했다. 사회학자들은 이것을 델파이 효과 라고 부른다. 이는 리누스가 보여준 것이 이 효과가 운영체제를 디버깅하는 데에도 적용될 수 있다는 점을 보여준다. - 델파이 효과는 OS 커널만큼 복잡한 개발까지도 다룰 수 있는 것이다.CV
확실히 델파이 효과를 도와주는 리눅스의 상황의 한가지 특별한 특징은 어떠한 주어진 프로젝트의 기여자들은 그 프로젝트를 스스로 선택했다는 점이다. 응답자들은 기여자들이 랜덤 샘플로부터 수용된 것이 아닌 그 소프트웨어를 사용하고, 어떻게 작동하는지 배우고, 그들이 처한 문제의 답을 찾으려고 시도하고, 사실상 명확하게 합당한 수정을 제공할만큼 관심이 있는 사람들이라고 지적했다. 이 모든 필터를 거친 어떤사람이든 프로젝트에 기여하기에 유용한 어떤 것을 가지고 있을 것이다.
리누스법칙은 "디버깅은 병렬처리가 가능하다"라고 다르게 표현될 수 있다. 디버거들이 디버깅을 하려면 의사소통을 조정해주는 개발자가 필요하지만 디버거들 사이에는 그다지 조정이 필요하지 않다. 그러므로 개발자를 추가하는데서 생기는 기하급수적인 복잡성과 관리의 어려움이 디버깅에는 짐이 되지 않는다.
실제로 리눅스 세계에서는 디버거의 작업이 중복됨으로써 생기는 이론적인 효율 저하가 거의 문제되었던 적이 없는 것으로 보인다. "빨리, 그리고 자주 발표하는 정책" 의 효과 중 하나는 피드백되어 오는 수정사항을 빨리 전파함으로써 중복이 최소화된다는 것이다. JH
브룩스(Brooks)(The mythical Man-Month 의 저자)는 즉석에서 다음과 같은 말을 했다. "널리 사용되는 프로그램의 유지보수에 들어가는 비용은 보통 개발시 드는 비용의 40 퍼센트나 그 이상입니다. 놀랍게도 이 비용은 사용자의 수에 큰 영향을 받습니다. 더 많은 사용자들이 더 많은 버그를 찾아냅니다."
사용자들이 많아지면 프로그램을 시험해보는 방법이 더 늘어나기 때문에 버그를 더 많이 잡아낼 수 있다. 이 효과는 사용자들이 공동개발자들일 때 더욱 커진다. 각 사람들이 버그를 찾아낼 때 조금씩 다른 개념의 집합과 분석 도구들을 사용하여 문제의 다른 각도에서 접근하기 때문이다. "델파이 효과" 는 바로 이런 편차에서 비롯되는 것으로 보인다. 또한 디버깅이라는 특정한 환경에서 이 편차는 노력의 중복을 줄여주는 경향이 있다.
따라서 더 많은 베타테스터를 가지는 것은 개발자의 관점에서 현재의 "가장 심오한" 버그의 복잡성을 줄여주지는 않을 테지만, 누군가의 도구가 문제에 딱 들어맞아 그 버그가 그 사람에게는 쉽게 잡을 수 있는 것이 될 가능성을 높여준다.
리누스도 물론 할 일이 있었다. 심각한 버그가 있을 경우에 대비해 리눅스 커널 버전은 잠재 사용자들이 최종적으로 "안정된" 버전을 사용할 수도 있고 새로운 기능을 사용하기 위해 최신의 버그가 있을 수 있는 버전을 사용할 수도 있게 번호가 붙여졌다. 이 전술은 아직까지 대부분의 리눅스 해커들이 따라하지는 않고 있지만 아마도 따라하게 될 것이다. 두 가지 선택이 가능하다는 사실이 양쪽 모두를 더 매력적으로 보이게 한다. HBS
시장 스타일이 디버깅과 코드 개발을 크게 가속화한다는 것은 전체적으로 보아야 할 한가지 사실입니다. 또한 이 방법을 통해 개발자와 테스터의 작업 방식과 그 이유를 마이크로 레벨에서 정확하게 이해할 수 있습니다. 이 섹션(원문으로 부터 3년 후 작성되었고, 원문을 읽고 개발 방식을 고친 개발자들이 고안하여 작성한 섹션입니다) 에서는 실제 작동 메커니즘을 자세히 살펴보겠습니다. 기술적면에 관심이 없는 독자는 다음 섹션으로 건너뛰셔도 무방합니다.
한가지 알고 가야할 점은, 프로그램 내부 구조를 모르는 사용자들의 버그 리포트가 어째서 그리 유용하지 않은지 정확히 파악해야 한다는 것입니다. 내부 구조를 모르는 사용자들은 대부분이 겉으로 드러나는 현상에 대해서만 보고합니다. 그들은 자신들의 사용 환경이 일반적이라 생각해서 (a) 중요한 백그라운드 데이터를 생략하고 (b) 버그를 재현하기 위한 방법에 대해 거의 보고하질 않습니다.
여기서 보이는 근본적인 문제는 테스터와 프로그램 개발자의 사고방식이 일치하지 않는다는 점입니다. 테스터는 외부적인 면을 보고, 개발자는 내부적인 면을 봅니다. 클로즈드 소스 개발을 하다 보면 그들 모두 한가지 면에만 얽매이는 경향이 있고, 서로의 전적에 대해 이야기하면서 서로 깊은 좌절감을 느꼈다는 것을 알게 됩니다.
오픈 소스 개발은 이러한 문제점을 타개 할 수 있습니다. 오픈소스를 통해 테스터와 개발자들이 실제 소스 코드를 기반으로 효과적으로 소통하고 서로 생각하는 바를 뚜렷하게 공유할 수 있습니다. 사실상, 사용자가 프로그램의 표면적인 면만 볼 수 있던 것과 개발자의 소스 코드 속 생각까지 들여다 볼 수 있는 것은 버그 리포트를 만들때 커다란 차이가 있습니다.
대부분의 버그는, 대부분의 경우에, 사용자의 오류 환경에 대해 소스 코드 수준으로 표현해주면 표현이 완전하지 않고 암시적이더라도 쉽게 파악할 수 있습니다. 베타 테스터가 "어떤어떤 라인에 바운더리 문제가 있습니다."라고 하거나 또는 그냥 "X, Y, Z 조건하에 이 변수가 문제가 될 수 있습니다."는 식의 지적을 해주면 빠르게 코드를 살펴보고 곧바로 문제 해결에 착수할 수 있습니다.
따라서, 둘의 소스코드에 대한 공통된 인식은 베타 테스터의 보고와 핵심 개발자가 알고있는 것 사이에 훌륭한 소통과 시너지를 이끌어냅니다. 즉, 많은 협력자들과 함께하더라도 핵심 개발자들의 시간은 낭비되지 않는다는 의미입니다.
개발자의 시간을 절약해주는 오픈 소스의 또 다른 특징은 오픈소스 프로젝트의 의사소통 구조입니다. 위에서 "핵심 개발자"라는 표현을 사용했는데, 이는 프로젝트 코어(대체로 수가 적고, 일반적으로 한명이며, 주로 한명에서 세명 사이)와 베타 테스터 및 후원자(주로 그 수가 수백에 이르는)와 같은 프로젝트 할로 사이의 차이를 나타내기 위함입니다.
전통적인 소프트웨어 개발 조직의 근원적 문제점은 "Brook's Law", 즉 프로그래머가 많을 수록 프로젝트 완성시기가 늦어진다는 것 입니다. 일반적으로, 브룩의 법칙은 개발자의 수가 늘어남에 따라 작업은 산술급수적으로 증가하는 반면에 프로젝트의 복잡성과 커뮤니케이션 비용은 기하급수적으로 커진다는 사실을 알려줍니다.
클러스터의 인터페이스 코드를 서로 다른 사람이 작성하는 사이에 버그가 매우 자주 발생하며 커뮤니케이션/조정 오버헤드는 사람 사이의 수많은 인터페이스로 인해 발생한다는 경험적인 사실을 기반으로 브룩의 법칙이 만들어졌습니다. 즉, 문제의 규모는 개발자의 수의 제곱에 비례하는 가능한 의사소통 가짓수에 따라 커집니다.(좀더 정확하게는 개발자의 수가 N명일 때 N*(N-1)/2 공식을 따릅니다.)
브룩의 법칙에 대한 분석(개발집단의 많은 수의 개발자들에 대한 걱정)은 프로젝트 커뮤니케이션 구조가 모든 각각의 사람들이 서로 간에 소통하는 완전한 그래프 형태라는 가정에 기반합니다. 하지만 오픈 소스 프로젝트에서 할로 개발자들은 서로간에 영향이 거의 없는 병렬적이고 분리가능한 일을 수행한다. 코드 수정과 버그 리포트는 핵심그룹을 통해 전달되고, 오로지 그 작은 규모의 핵심 그룹 내에서만 브룩시안 오버헤드 비용이 발생하게 됩니다
소스코드 수준의 버그 리포트가 매우 효율적인 이유는 또 있습니다. 하나의 오류가 사용자의 사용 패턴 및 이용환경에 따라 어려가지 증상을 보일 수 있다는 사실에 초점을 맞춥니다. 이런 오류들은 정확히 원하는 대로 재현하거나 정적 분석을 통해 해결하기 가장 어려운, 복잡하고 미묘한 종류의 오류(dynamic-memory-management error 또는 nondeterministic interrupt-window artifacts 과 같은)이며, 소프트웨어에서 장기적인 문제를 발생시킵니다.
그러한 multi-symptom 버그에 대해 소스코드 수준의 시험적인 서술(예를 들면 "1250번째 줄의 신호 처리에 보안 문제가 있는것 같아요"라던가 "그 버퍼를 어디서 초기화했나요?" 같은)을 보내는 테스터는 개발자에게 이질적인 증상에 대한 절반짜리 중요한 단서를 제공해줍니다. 이러한 경우에, 버그로 인해 어떤 외부적인 증상이 발생할지는 모르지만, 그건 딱히 알 필요가 없습니다. 다른 협력자들이 그들의 버그가 고쳐졌는지의 여부를 빠르게 알아낼 수 있을 것입니다. 많은 경우의 소스코드 레벨의 버그 리포트는 특별한 해결책을 제시하지 않을 수도 있습니다.
복잡한 multi-symptom 에러는 겉으로 드러나는 증상에서 실제 버그까지의 추적 경로도 다양합니다. 개발자나 테스터가 추적할 수 있는지의 여부는 개인 환경의 세부사항에 따라 달라질 수 있고, 결정론적인 방식이 아닐 수도 있습니다. 실제로, 각 개발자와 테스터는 증상의 인과 관계를 찾을 때 프로그램의 설정 상태를 반무작위적으로 조정합니다. 버그가 더 미묘하고 복잡할수록, 이런 기술을 통해 샘플과의 관련성이 보장될 확률이 낮아집니다.
단순하고 쉽게 재확인할 수 있는 버그의 경우에, "무작위"가 아닌 "반"에 더 강조를 줍니다. 이때 코드와 그것의 구조에 관한 디버깅 스킬과 정교함이 크게 영향을 미칩니다. 하지만 복잡한 버그의 경우에는 "무작위"가 더 중요합니다. 이러한 상황에서는 많은 수의 사람들이 버그를 추적하는 것이 상대적으로 수준이 높은 소수의 사람들이 순차적으로 추적해보는 것보다 훨씬 효과적일 것입니다.
만일 서로다른 표면적인 증상에서 버그에 이르기 까지의 경로를 추적하는 어려움이 증상을 보고 예측할 수 없는 방식으로 두드러지게 진행된다면 이 효과는 크게 증폭됩니다. 순차적으로 버그를 파악하는 식의 한 개발자의 첫번째 시도는 어려운 방식의 추적 경로를 골라버릴 가능성이 있습니다. 반면에 소스를 빠르게 공개 하면서 많은 사람이 다양한 추적 경로를 파악한다고 가정합시다. 그러면 확률적으로 그들 중 한명은 가장 쉬운 길을 곧바로 찾아버릴 것이고, 훨씬 짧은 시간 안에 그 방법을 채택할 수 있습니다. 프로젝트 관리자는 그것을 통해 새로운 버전을 제공하고 다른 사람들이 똑같은 버그에 대해 더 어려운 방법으로 시간을 들이는 것을 멈출 수 있습니다.
리누스의 행동을 연구하고 그것이 왜 성공적이었는지에 대한 이론을 만든 후, 나는 이 이론을 내 새로운 프로젝트 (물론 훨씬 덜 복잡하고 덜 야심적인 프로젝트) 에 적용해 보기로 했습니다.
그러나 내가 가장 먼저 한 일은 popclient 를 더 재조직화하고 단순화한 것이었습니다. 칼 해리스의 구현방식은 매우 유효한 것이었지만, 많은 C 프로그래머들에게서 볼 수 있었던 것처럼 불필요한 복잡성이 있었습니다. 그는 코드를 핵심적인 것으로, 자료구조는 코드를 받쳐주는 것으로 취급했습니다. 그 결과 코드는 아름답지만 자료구조는 ad-hoc으로 설계되었고, 보기에 좋지 않았습니다. (최소한 옛 LISP 해커의 높은 기준에서 보자면 말이다)
코드와 자료구조를 개선하는 것 말고도 나는 또다른 목적을 가지고 있었습니다. 그건 코드를 내가 완전히 이해하는 무엇인가로 진화시키는 것이었습니다. 이해하지 못하는 프로그램의 버그를 수정하는 책임을 맡는 것은 재미없는 일이었습니다.
처음 한달 정도가 지날 동안 나는 그저 칼의 기본적인 설계가 어떤 의미를 가지고 있는지 따라다니기만 했습니다. 내가 처음으로 중요한 수정을 진행한 것은 IMAP 지원이었습니다. 프로토콜 머신을 일반적인 드라이버와 세가지 메소드 테이블 (POP2, POP3, IMAP을 지원하는)로 재조직했습니다. 이와 그 이전의 변경들은 프로그래머들이 알아둘 만한 일반적인 원리를 보여줍니다. 특히 C 와 같이 즉흥적으로 프로그래밍하기 힘든 언어에서 말입니다.
9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다.
브룩스의 책 9장 에 이렇게 쓰여있습니다. "내게 순서도를 보여주고 표를 숨긴다면 나는 계속 어리둥절할 것이다. 표를 보여준다면 순서도는 볼 필요도 없이 뻔한 것이다." 하지만 30년간 변해온 용어들과 문화를 고려한다면 거의 똑같은 말이라고 할 수 있습니다.
이 시점에서 (1996년 9월 초, 일을 시작하고 6 주가 지난 후) 나는 이름을 바꿀 때가 되었다고 생각하기 시작했습니다. 이 프로그램은 더 이상 단순한 POP client가 아니었다. 하지만 디자인에 완전히 새로운 것은 들어가 있지 않았기 때문에 나는 머뭇거리고 있었습니다. 내가 만든 popclient는 아직 스스로의 정체성을 확립하지 못하고 있었습니다.
fetchmail이 어떻게 SMTP 포트로 가져온 메일을 이동시켜야 하는지 알고 난 후에는 상황이 급변했습니다. 그에 대해서는 나중에 말하겠습니다. 하지만 그보다 먼저, 앞서 나는 리누스 토발즈가 옳은 방식으로 일을 해냈다는 내 이론을 시험하기 위해 이 프로젝트를 수행하기로 했다고 말했습니다. 어떻게 시험을 했을까? 다음과 같은 방법을 사용했습니다.
일찍, 자주 발표했습니다. (발표간격이 10일을 넘는 경우는 거의 없었으며 개발에 몰두해 있을 때는 하루에 한번씩 발표했다)
fetchmail 에 대한 일로 나에게 연락해 오는 사람은 누구든지 베타테스터 목록에 올렸습니다.
새로 발표할 때마다 베타테스터들에게 떠들썩하게 발표를 알리며 사람들이 참여하도록 격려했습니다.
그리고 그들의 이야기를 들었습니다. 설계 결정에 대해 투표를 하기도 했고 패치나 피드백을 보내올 때마다 베타테스터들을 구슬렀습니다.
이 단순한 방법들은 즉각 효력을 나타냈다. 프로젝트를 시작할 때부터 개발자들이라면 학수고대할 만한 버그 리포트를, 때로는 훌륭하게 수정된 코드를 받을 수 있었다. 사려깊은 비판과 팬 메일, 기능제안들을 받았다. 여기서 다음과 같은 결론을 이끌어 낼 수 있다.
10. 베타테스터들을 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다.
fetchmail 의 성공을 재는 재미있는 척도 중 하나는 프로젝트 베타테스터 메일링리스트인 fetchmail-friends 의 크기이다. 이 글을 쓰고있을 때 목록에는 249 명이 있었고 1주일에 2~3명이 추가되었다.
1997 년 5월말 경에 글을 수정하면서 보니까 목록은 300명 가까이 되었고, 멤버들이 조금씩 줄기 시작했는데 그 이유가 흥미로왔다. 몇몇 사람들이 구독을 중단하면서 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 포워딩에 대한 아이디어는 내가 리누스의 방법을 모방하려고 의식적으로 노력한 것에 대한 가장 큰 보답이었다. 사용자 한 명이 내게 끝내주는 아이디어를 주었으며 내가 해야했던 일은 그 의미를 이해하는 것 뿐이었다.
11. 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다.
흥미롭게도 만일 당신이 얼마나 다른사람에게 빚을 많이 지고 있는지를 자기 비하라고 느껴질 정도로까지 솔직하게 털어놓는다면 대개의 사람들은 당신이 혼자서 거의 모든 일을 해내고서 천재성에 대해서 겸손해 하는 것처럼 대한다는 것을 곧바로 알게 될 것이다. 리누스의 경우를 보라! (1997년 8월, Perl 컨퍼런스에서 이 글을 발표할 때 래리 월이 첫 번째 줄에 앉아 있었다. 바로 윗 줄에 도달했을 때 그는 부흥사라도 된 것처럼 외쳤다. "형제여, 이야기 하시오, 이야기를!" 청중들 모두가 이것이 Perl을 만든 래리에게도 적용된다는 것을 알았기 때문에 웃음을 터뜨렸다.)
똑같은 정신으로 프로젝트를 몇 주 진행해 나가자 나는 사용자들 뿐 아니라 이야기를 전해들은 다른 사람들로부터 비슷한 칭송을 받기 시작했다. 나는 그런 email 중 몇몇을 따로 보관해 두었다. 나중에 내 삶이 가치있는 것이었는지 의심스러워질 때 그 메일들을 다시 꺼내볼 생각이다.
모든 종류의 설계에 대해서 적용될 수 있는 두가지 더 기본적이며 비정치적인 교훈이 있다.
12. 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다.
나는 popclient를 MTA/MDA 기능을 다 갖추고 복잡한 지역배달모드들까지(local delivery modes) 갖춘 것으로 개발해 나가면서 틀린 문제를 풀려고 노력하고 있었다. fetchmail의 설계는 가장 기초적인 것부터 재고하여 SMTP 포트로 메일을 배달하는 인터넷 메일 경로의 한 부분인 순수 MTA 가 되어야 했다.
개발 도중에 벽에 부딪친다면 - 다음번 패치 후에 무엇을 해야 할 지 모르겠다면 - 그때는 정답을 가지고 있는지 생각할 것이 아니라 질문이 올바른 것인지 의문을 가져보아야 하는 경우가 종종 있다. 아마도 문제의 틀을 다시 잡아야 할 것이다.
그래서, 나도 내 문제의 틀을 다시 잡았다. 분명히 제대로 일을 진행하려면 (1) SMTP 포워딩 지원 기능을 일반 드라이버에 포함시키고, (2) SMTP 포워딩을 기본모드로 만들고 (3) 최종적으로는 다른 배달모드들, 특히 '파일로 배달하기' 와 '표준출력으로 배달하기'를 제거해야 했다.
나는 단계 (3)에서 조금 머뭇거렸는데, 이유는 오랫동안 popclient 를 써오면서 다른 배달모드에 의존하고 있을 사용자들의 심기를 불편하게 만들고 싶지 않았기 때문이다. 이론적으로는 그들 모두 즉시 .forward 파일이나 sendmail 외의 비슷한 프로그램으로 전환하여 동일한 결과를 얻을 수 있었다. 실제로는 전환 자체가 큰 일이 될 것이었다.
하지만 단계 (3)을 실행하고 나자 이점이 매우 큰 것으로 나타났다. 드라이버 코드 중 가장 힘든 부분이 사라졌다. 설정이 엄청나게 간단해졌다 - 시스템의 MDA 와 사용자의 메일박스를 일일이 찾아다니며 굽실거릴 필요도 없어졌고, OS 가 파일 잠금을 지원하는지 걱정할 필요도 없어졌다.
게다가 메일을 잃어버릴 한가지 가능성도 사라졌다. '파일로 배달하기'를 선택했을 때 디스크가 꽉 차 있으면 메일이 사라져 버렸던 것이다. SMTP 포워딩에서는 SMTP 리스너가 메시지 배달이 가능하거나 나중에 배달할 수 있도록 스풀해 놓기 전에는 OK를 돌려주지 않을 것이기 때문에 이런 일이 일어날 수가 없다.
성능도 향상되었다(한두번 실행시켜서는 느끼지 못하겠지만). 또 변경에 따르는 그다지 중요하지 않은 이익이라면 매뉴얼 페이지가 훨씬 간단해 졌다는 것이다. 나중에 나는 사용자가 지정한 지역 MDA를 통해 배달하는 기능을 다시 넣어야 했다. 동적인 SLIP를 포함하여 몇몇 애매한 상황을 다루어야 했기 때문이다. 하지만 처음보다 훨씬 간단한 방법을 찾아낼 수 있었다.
교훈이라면? 낡아서 사용할 수 없는 기능이라면 효율을 떨어뜨리지 않고 제거할 수 있을 때는 망설이지 말고 제거해 버리라. 앙뜨완 드 생떽쥐뻬리는 (아동서적 작가였으며 남는 시간에는 비행기 조종과 설계를 했던) 이렇게 말했다.
13. (설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다.
코드가 더 나아지고 간단해지고 있을 때가 바로 일이 제대로 되어가고 있다는 것을 알게 되는 때다. 그리고 그 과정에서 fetchmail 의 설계는 그 조상격인 popclient 와 다른, 자신만의 정체성을 획득했다. 이름을 바꿀 때가 된 것이다. 새로운 설계는 예전의 popclient 보다는 sendmail 과 비슷해 보였다. 둘다 MTA였으나 sendmail은 푸시(push) 후에 메일을 배달했고 새로운 popclient 는 풀(pull) 후에 메일을 배달했다. 해서 두 달 후에 나는 popclient 의 이름을 fetchmail로 변경했다.
이제는 깔끔하고 혁신적인 설계, 매일 사용하므로 잘 작동하는 것을 알고 있는 코드, 발전하고 있는 베타테스터의 목록을 가지고 있었다. 더이상 내가 하고 있는 일이 몇몇의 사람에게 유용할 수도 있는 사소하고 개인적인 해킹은 아니라는 생각이 서서히 들기 시작했다. 내가 가지고 있는 것은 유닉스 박스와 SLIP/PPP 메일 연결을 가지고 있는 모든 해커들이 정말로 필요로 하는 프로그램이었다. SMTP 포워딩 기능으로 fetchmail 은 경쟁에서 멀찍이 앞서나와 카테고리 킬러, 그러니까 해당분야의 다른 프로그램들은 아예 잊혀져 버릴 만한 경쟁력을 갖추고 자신의 지위를 확고하게 하는 고전적인 프로그램이 될 수 있는 능력을 갖추었다. 이런 결과를 계획하거나 목표로 가질 수는 없으리라고 생각한다. 아주 강력한 설계상의 아이디어로 그런 결과가 불가피하고, 자연스러우며 운명적인 것으로 보이게 함으로써 그런 결과에 도달해야 한다. 그런 아이디어를 구체화해 볼 수 있는 유일한 방법은 수많은 아이디어를 가지는 것이다. 아니면 다른 사람들의 좋은 아이디어를, 원래 생각되었던 것보다 더 멀리 이끌고 가서 구체화 시켜보는 방법이다. 앤드류 타넨바움 (Andrew Tanenbaum) 은 교습 도구로 사용하기 위해 386용으로 간단한 네이티브 유닉스를 만들려는 원래의 아이디어를 가지고 있었다. 리누스 토발즈는 이 미닉스의 개념을 앤드류가 생각했던 것보다 더 멀리 밀고 나갔다. 그래서 리눅스는 굉장한 것이 되었다. 똑같은 방식으로 (더 작은 스케일이었지만) 나는 칼 해리스와 해리 호흐하이저의 아이디어들을 가져와 강하게 밀어붙였다. 리누스나 나나 사람들이 천재들이 그러하리라고 생각하는 낭만적인 의미에서 `독창적' 인 것은 아니었다. 하지만 통념과는 반대로 대부분의 과학과 공학과 소프트웨어 개발은 독창적인 천재, 해커의 전설에 의해서 이루어지지는 않는다. 결과물은 똑같이 매우 사람을 흥분시키는 것들이다 사실, 모든 해커들은 이런 종류의 성공을 얻기 위해 살아간다! 거기에는 내가 기준을 더 높이 잡아야 한다는 의미도 들어있다. fetchmail을 최상의 것으로 만들기 위해 나는 내자신의 필요뿐 아니라 나와는 상관없지만 다른 사람들에게는 필수적인 기능을 포함시키고 지원해야했다. 게다가 프로그램을 단순하고 튼튼하게 유지시키면서 그런 일을 해야 했다. 이것을 깨닫고 나서 내가 추가한 매우 중요한 첫 번째 기능은 멀티드롭(multidrop) 기능이었다. 그룹이나 사용자들의 메일을 한꺼번에 가지고 있는 메일박스에서 메일을 가져와 각 메일들을 개인 수신자에게 라우트(route) 시켜주는 기능이었다. 멀티드롭 기능을 추가하기로 한 데에는 몇몇 사용자들이 원한다는 것도 있었지만 가장 큰 이유는 어드레싱을 완전히 구현함으로써 싱글드롭 코드에 있는 버그들을 잡아낼 수 있으리라고 생각했기 때문이다. 그리고 그렇게 되었다. RFC 822의 파싱을 제대로 구현하는 것에 매우 오랜 시간이 걸렸는데, 각각의 조각이 어려웠기 때문이 아니라 각각이 서로 의존하고 있으며 세심하게 신경을 써야 하는 사항들이었기 때문이다. 하지만 멀티드롭 어드레싱 역시 매우 훌륭한 설계상의 결정이었던 것으로 드러났다. 다음과 같은 교훈을 얻을 수 있었다. 14.어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았던 용도에 알맞게 된다. (Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected) 미처 생각하지 못했던 멀티드롭 fetchmail 의 용도는 메일링리스트를 그대로 유지한 채, 알리아스 확장이 된 채로 SLIP/PPP로 연결된 클라이언트 쪽에서 메일링리스트를 운영하는 것이었다. 개인의 컴퓨터로 ISP 계정을 통해 접속하는 사람이 ISP 의 알리아스 파일에 지속적으로 접근하지 않고도 메일링리스트를 운영할 수 있다는 것을 의미한다. 베타테스터들이 요구한 중요한 변경사항중 또 하나는 8비트 MIME 오퍼레이션이었다. 이것은 내가 코드를 8비트에 대비하여 계속 유지시켜왔기 때문에 매우 쉬운 일이었다. 이런 기능에 대한 요구를 미리 예측해서 그랬던 것은 아니다. 다음과 같은 규칙을 따르려고 해서였다. 15.어떤 종류든 게이트웨이 소프트웨어를 만들려고 한다면 데이터 스트림에 가능한 한 최소한의 조작만 가하라 그리고 수신자가 강제로 하게 하지 않는다면 정보를 절대로 잘라버리지 말라. (When writing gateway software of any kind, take pains to disturb the data stream as little as possible -- and never throw away informtion unless the recipient forces you to!) 이 규칙을 따르지 않았다면 8비트 MIME 지원은 매우 어려웠을 것이며 많은 버그를 만들어 냈으리라. 규칙을 따랐기 때문에 내가 해야 할 일은 RFC 1652 를 읽고 헤더 생성 로직을 약간 수정하는 것 뿐이었다. 유럽의 몇몇 사용자들은 한 세션에서 가져올 수 있는 메시지의 수를 제한하도록 옵션을 추가해달라고 요구해왔다.(전화 네트워크의 비싼 비용을 조절할 수 있도록 해달라는 말이다) 오랫동안 여기에 저항했고, 아직도 완전히 수긍하지 못했다. 하지만 세계를 상대로 프로그램을 만든다면 고객들의 소리에 귀를 기울여야 한다 그들이 돈을 지불하지 않는다고 해도 마찬가지다.
일반적인 소프트웨어공학의 주제로 돌아가기 전에 fetchmail의 경험으로부터 배울 점이 몇 가지 더 있다. rc 파일의 구문은 선택사항으로 `noise' 라는 키워드를 포함하는데 이것은 파서에 의해 무시된다. rc 파일에서 허용하는 영어와 비슷한 구문은 잘라낼 것을 모두 잘라낸 후에 얻는 전통적이고 간명한 키워드-밸류 짝에 비해 훨씬 알아보기 쉽다.
이것은 내가 rc 파일의 선언들이 명령형 소언어 (imperative minilanguage)를 얼마나 많이 닮아가기 시작했는지 알아차리고 나서 한밤중의 실험으로 시작되었다. (popclient 의 "server" 라는 키워드를 "poll" 로 바꾼 이유도 이것이다)
명령형 소언어를 더 영어처럼 만들면 사용하기 쉬울 것으로 보였다. 지금은 내가 비록 Emacs 나 HTML, 그리고 많은 데이터베이스 엔진에서 볼 수 있듯이 설계를 할 때 "언어처럼 만드는" 파의 일원이긴 하지만 ``영어와 비슷한'' 구분을 가지는 것에 대해서는 그다지 달가와 하지 않는다.
전통적인 프로그래머들은 정확하고 짧으며 중복을 허용하지 않는 제어구문을 선호하는 경향이 있다. 이것은 컴퓨팅 자원이 비싸서 파싱하는 단계가 최대한 싸고 간단해야 했을 때부터 내려온 문화적 유산이다. 영어는 대략 50% 정도의 중복을 허용하므로 대단히 부적절한 모델인 것으로 보인다.
이것이 내가 영어와 비슷한 구문을 일반적으로 피하는 이유는 아니다. 이 문제를 언급한 이유는 그런 관습을 없애기 위해서다. 사이클과 코어의 값이 싸졌는데도 간명함은 저절로 없어지지는 않았다. 최근에는 언어가 컴퓨터의 관점에서 싼 가격이라는 점보다는 사람에게 편리한가 하는 점이 더 중요하다.
물론 조심해야 할 이유는 충분히 있다. 한 가지는 파싱하는 단계의 복잡성에 대한 비용이다 -- 파싱하는 단계를 버그가 우글거리는 데다가 사용자로 하여금 그 자체만으로 혼란을 일으키게 만들고 싶지는 않을 것이다. 또 하나의 이유는 언어의 구문을 영어와 비슷하게 만들려고 노력하면 그 "영어" 가 심각하게 왜곡되어 자연어와의 피상적인 유사점이 전통적인 구문만큼이나 혼란스럽게 되는 경우가 많다는 점이다. (소위 ``4세대'' 언어와 상업용 데이터베이스 질의어에서 이런 경우를 많이 볼 수 있다)
fetchmail 제어구문은 이런 문제를 피하려고 했다. 언어의 영역이 매우 제한되어 있었기 때문이다. 일반적인 목적의 언어와는 거리가 멀었다. 언어가 표현하는 것이 별로 복잡하지 않았기 때문에 영어의 일부분에서 실제 제어언어로 옮겨가는데 혼란을 일으킬 가능성이 적었다. 더 넓은 의미의 교훈을 여기에서 얻었다.
16.언어가 튜링-컴플리트하지 않다면 구문상의 유연성이 필요하다. (When your language is nowhere near Turing-complete, syntactic sugar can be your friend)
또하나의 교훈은 불투명함에 의한 보안에 대해서이다. fetchmail 의 사용자 중에는 스누퍼들이 우연히 패스워드를 보지 못하도록 rc 파일에 있는 패스워드를 암호화하여 가지고 있게 하자고 이야기하는 사람들이 있었다.
나는 그 이야기를 받아들이지 않았는데, 그렇게 한다고 해서 보안이 강화되는 것이 아니기 때문이다. rc 파일의 읽기 퍼미션을 얻은 사람이라면 사용자와 마찬가지로 fetchmail을 실행시킬 수도 있는 것이다 -- 그리고 그들이 패스워드를 원하는 것이라면 패스워드를 얻기 위해 fetchmail 코드에서 디코딩하는 코드를 뽑아낼 수도 있다.
.fetchmailrc 의 패스워드를 암호화 했다면 사람들은 그리 심각하게 생각하지도 않고 보안에 대해 잘못된 관념을 가지게 되었을 것이다. 여기서 알 수 있는 일반적인 규칙은 다음과 같다.
17.보안시스템은 그것이 보호하려고 하는 비밀만큼만 안전하다. 가짜 비밀들에 주의할 것. (A security system is only as secure as its secret. Beware of pseudo-secrets)
이 에세이의 사전 검토자들과 시험 독자들은 성공적인 바자르 스타일 발전을 위한 전제 조건에 대해서 질문했다. 여기에는 프로젝트가 공개되고 공동 개발자 커뮤니티를 만들려고 노력하는 시점에서의 프로젝트 리더의 자질과 코드의 상태가 포함되었다.
완전 기초부터 바자르 스타일로 코드할 수 있는 것이 아닌건 확실하다. 누군가는 테스트 디버그 그리고 바자르 스타일로 발전 시킬 수 있지만, 시작할 때 바자르 모드로 개발 하기는 힘들다. 리누스 그리고 나도 이 방법으로 하지는 않았다. 초기 개발자 커뮤니티는 구현가능하고 시험가능한 무언가를 가지고 있어야 한다.
커뮤니티 빌딩을 시작할 때, 꼭 당신이 해야할 일은 지킬 수 있는 약속을 하는 것이다. 당신의 프로그램이 특별히 잘 작동할 필요는 없다. 대충될 수도 있고, 버그가 많을 수도 있고, 불완전하고 문서화가 덜 될 수도 있다. 절대 실패하지 말아야 할 것은, 가까운 미래에 뭔가 괜찮은 것이 개발될 수 있겠다는 확신을 동료 개발자에게 확신을 주는 것이다.
리눅스와 페치매일은 모두 강하고, 매력적인 기본 디자인을 가진 상태에서 공개되었다. 내가 이야기 하자, 많은 사람들은 바자르 모델을 중요하다고 생각하였고, 높은 수준의 디자인 교육기관 학위와 영특함이 프로젝트 리더에게는 필수적인 것이라는 결론을 내려버리게 되었다.
그러나 리누스는 유닉스로부터 그의 디자인을 뽑아냈다. 나는 ancestral popclient( 물론 나중에 그것이 거대한 변화를 불러 일으켜 왔다. 리눅스를 가졌을 때와 비교해서 얘기해보자면) 에서 가지고 왔다. 바자르 스타일의 리더 / 보조자는 반드시 예외적인 디자인 능력 또는 다른 사람들의 디자인 능력을 끌어낼 수 있어야 할까?
나는 보조자가 디자인에 대해서 예외적인 영특함을 가지고 있는 것이 중요하지는 않지만, 보조자가 좋은 디자인 아이디어를 다른 것들로부터 구별하고 인식해낼줄은 알아야 하는 것은 매우 중요하다고 생각된다.
리눅스와 페치메일 프로젝트 2개 다 모두 이것의 증거가 된다. (전에 논의 되었듯이) 그렇게 특출난 디자이너가 아닌 리누스는 특출난 디자인을 골라내고 그것을 리눅스 커널에 합치는 뛰어난 능력을 보여줘 왔다.그리고 나는 페치 메일에서 강력한 디자인 아이디어가 다른 사람에게서 나왔다고 이미 묘사했다.
이 에세이의 사전 구독자들은 내가 디자인 독창성을 가지고 있고 당연시 여기기에 바자르 프로젝트에서 디자인 독창성을 내가 평가절하한다고 생각하고 경의를 표했다. 어느 정도는 사실이다 ; 디자인(코딩 또는 디버깅과는 상반되는) 은 분명 내가 제일 잘하는 일이다.
그러나 소프트웨어 디자인에서 똑똑하고 독창성을 가지게 되는 것에 대한 문제는 그것이 습관화 된다는 것이다. - 당신이 강력하고 간단하게 해야할 때 반사적으로 물건들을 복잡하게 만들기 시작하는 것이다. 나의 그런 성향 때문에 내가 망친 프로젝트가 있었다. fetchmail에서는 그래도 잘 조절해서 실패를 피했다.
그래서 나는 페치메일 프로젝트는 성공했다고 믿는다 왜냐하면 부분적으로는 똑똑지기 위한 나의 경향성을 저지하였기 때문이다 ; 성공적인 바자르 프로젝트의 필수적인 요소가 디자인 독창성이라는 주장과 상반된다 . 리눅스를 고려해보자. Linus Torvalds 가 운영체제 디자인을 개발하는데 있어서 기본적인 혁신을 끌어내려고 노력했다고 가정보자 ; 이것이 커널을 지금처럼 안정적이고 성공적인 결과로 이끌 수 있었을까?
물론 어느정도 기본적인 수준의 디자인 또는 코딩 기술은 필요하다. 그러나 바자르 스타일의 프로젝트를 시작하려고 심각하게 생각하는 사람은 최소 그 정도는 넘었다고 예상한다. 오픈소스 커뮤니티의 내부 시장에서 평판은 미묘하게 사람들에게 영향력을 행사한다. 그래서 만약 지속적으로따라올 정도로 능숙하지 않다면 개발 프로젝트를 시작하지 않게 된다. 지금까지는 이 규칙이 꽤나 잘 적용되어 왔다.
바자르 프로젝트에서 디자인 영특함 만큼 중요하다고 생각되는 또 다른 종류의 기술이 있다 - 아마 더 중요할 것이다. 바자르 프로젝트의 협동자와 리더는 반드시 좋은 커뮤니케이션 스킬을 가지고 있어야 한다.
이것은 확실시 되어야 한다. 개발자 커뮤니티를 만들기 위해서는, 사람을 끌어야 하고, 당신이 하는 일에 대해서 관심을 갖도록 해야 한다. 그리고 그들이 하는 일에 대해서 계속 행복하게 해야 한다. 기술적인 논란은 이런 것들을 이뤄나가는데 많은 도움이 되긴 하지만, 그것이 전부는 아니다. 사람의 성격도 프로젝트에 큰 영향을 끼친다.
리누스가 사람들로 하여금 그를 좋아하게 하고 돕고 싶게 만들만큼 좋은 사람이라는 것은 우연이 아니다. 내가 정열적이고 사람 무리들과 어울리기 좋아하고 만화 속 인물 처럼 보이는 것 역시 우연이 아니다. 바자르 모델이 성공하려면 사람을 끌어들이는 매력이 큰 도움이 된다.
이런 말이 있다 : 최고의 해킹은 해커의 일상적인 문제에 대한 개인적인 해결책으로부터 시작되고 그 문제들은 곧 큰 집단의 유저들의 전형적인 문제로 밝혀지면 퍼지게 된다. 첫번째 법칙으로 돌아와서 더 유용한 방법으로 말해 보자 : 18. 흥미로운 문제를 풀기 위해서는, 당신을 흥미롭게 하는 문제를 먼저 찾는 것으로 시작하라.
결국 이것은 Carl Harris 와 ancestral poplient 그리고 나와 fetch mail이 이러했었다. 그러나 이것은 오래 전부터 이해되어져 왔다. 흥미로운 점은 리눅스와 페치메일의 역사가 가리키고 있는 것처럼 다음 단계에 와 있다는 것이다 - 크고 역동적인 유저와 공동 개발자 들의 커뮤니티에서 소프트웨어가 발전을 하고 있다는 것
Man - Mouth 의 신화에서, Fred Brooks 는 프로그래머의 시간은 대체 불가능한 것이라는 것이라고 하였다 ; 늦은 소프트웨어 프로젝트에 개발자를 추가로 투입하면 더 늦어지게 된다. 전에 보았듯이, 그는 프로젝트의 복잡성과 커뮤니케이션 비용이 개발자 수의 제곱에 비례해서 증가하는 반면, 일처리양은 선형적으로 증가한다고 주장하였다. 이는 브룩스의 법칙으로 알려졌고, 진리 처럼 여겨졌다. 그러나, 이번 에세이에서 오픈 소스 개발의 과정에서 여러가지 방법으로 그 가정들이 틀렸다는 것을 알 수 있었다 - 브룩스의 법칙이 전부였다면, 리눅슨는 불가능 했을 것이다.
제라드 와인버그의 고전 ‘ the psychology of computer programming ‘ 에서 우리는 브룩스에 대한 중요한 수정을 진행했다는 것을 볼 수 있다. “egoless programming” 에 대한 논의를 볼 때, 윈더버그는 자신의 코드에 대해서 소유권을 주장하지 않고, 사람들로 하여금 버그를 찾아내고 잠재적인 발전 가능성을 찾아내도록 독려하면, 다른 곳에서는 찾아볼 수 없는 엄청난 발전이 이뤄진다는 것을 발견 했다. (최근에 Kent Beck의 ‘extreme programming’ 에서 코더들이 짝을 이루어서 서로의 코드를 어깨넘어 검토하는 것이 이 효과로 부터 야기된 도전의 일환이라고 볼 수 있다.)
윈더버그의 용어 선택이 아마, 그의 분석이 마땅히 받을 만한 평가를 받지 못하게 했을 것이다. - 누군가는 인터넷 해커들을 “자아가 없는” 이라는 단어로 묘사한 것에 대해 웃을 수 밖에 없을 것이다. 그러나 나는 이 논쟁이 그 어느 때보다 지금 가장 절실하다고 생각한다.
“자아 없는 프로그래밍” 효과의 총 힘을 모은 바자르 방법은 브룩스의 법칙의 효과를 강력하게 완화시켰다. 브룩스의 법칙을 뒷받침하는 원칙들은 폐지되지는 않았지만, 많은 개발자 인구수와 값 싼 커뮤니케이션 비용으로 보았을 때 이것의 효과는 다른 방식으로는 볼 수 없는 경쟁적인 비선형성에 의해 침체 될 수 있다. 이것은 뉴턴과 아인슈타인 물리의 관계와 비슷하다. - 구 시스템은 여전히, 적은 에너지에서는 유효하지만, 질량과 속도를 핵 폭발이나 리눅스 처럼 크게 하면 놀라움을 얻을 수 있다.
유닉스의 역사는 우리가 리눅스로부터 배웠던 것을(그리고 내가 실험적으로 더 작은 스케일로 리눅스의 방법을 따라서 검증해낸 것을) 준비했어야 한다. 코딩은 고독한 개인의 분야인 것에 비해, 정말 대단한 해킹들은 커뮤니티 전체의 주의력과 지능을 한데 모아서 이루어지기 때문이다. 폐쇄된 프로젝트에서 오직 그 혹은 그녀 자신 만의 두뇌를 사용하는 개발자들은 디자인 스페이스를 찾아내고 피드백하며, 코드 기여를 하고, 버그 찾기 그리고 수백만명의 사람들에게서 오는 개선을 이루는 열려있고 발전적인 문맥을 만들 수 있는 개발자에게 밀리기 마련이다.
그러나 전통적인 유닉스 세계에서는 여러가지 요인들 때문에 이렇게 밀어 붙이는 것이 금지 되었었다. 하나는 다양한 라이센스에 대한 법적인 제약, 거래 비밀 그리고 상업적인 이해관계이다. 또 다른 것은 (나중에서야 알게 됨) 인터넷이 아직 충분히 좋지 않았다는 것이었다.
값 싼 인터넷 전에, 와인버그의 “자아가 없는” 프로그래밍을 장려하고 수많은 숙련된 훈수꾼들과 동료 개발자들을 쉽게 끌어들여올 수 있는 문화가 정착된 지리학적으로 몰려 있는 몇개의 커뮤니티가 존재했었다. 벨 연구소, MIT 인공지능 연구소, UC 버클리 - 전설적인 혁신들의 본고장이 된 곳이고 여전히 그런 잠재력을 가지고 있다.
리눅스는 인재 풀을 전세계로 사용하기 위해서 의식적이고 성공적으로 노력한 첫 번째 프로젝트이다. 리눅스의 태동기와 월드 와이드 웹의 탄성이 일치하는 것이 우연이라고 생각하지 않는다, 그리고 리눅스의 발전기가 ISP 산업의 시작과 인터넷의 주류로서의 폭발적인 관심을 끌은 1993-1994년 인 것 역시 우연이라고 생각하지 않는다. 리누스는 쉬운 인터넷 접속이 가능한 새로운 룰을 처음으로 활용할 줄 알았던 첫 번째 사람이다.
리눅스 모델이 발전하는데 있어서 값 싼 인터넷이 필수적인 조건이긴 하지만, 나는 그것이 충분조건이라고 생각하지는 않는다. 또 다른 중요한 요소는 리더십 스타일의 발전과 개발자가 동료 개발자를 모으고 매체를 최대한으로 사용할 수 있었던 것 이다.
그런데 리더십 스타일이란 무엇이고 이 관습들은 무엇인가? 권련 관계를 기반으로 한 것은 아니다. - 그리고 설사 그럴지라도 강제에 의한 리더십은 우리가 보고있는 이러한 결과들을 못 만들었을 것이다. 와인버그는 19세기 러시아 무정부주의자 Pyotr Alexeyvich Kropotkin 의 자서전 ‘Memoirs of a Revolutionist’ 에서 한 구절을 인용하였다.
‘ 농노를 소유한 가정에서 태어나 자라왔기에 명령하고, 지시하고, 꾸짖고, 벌주고 그런 것들의 필요성에 대한 강한 확신을 가지고 그 시대 나와 비슷한 나이대의 다른 젋은이들과 마찬가지로 능동적으로 내 삶을 살아왔다. 그러나 내가 큰 사업을 운영해야 될 때, 다른 사람들과 거래를 해야했고, 각각의 실수가 엄청난 결과를 이끌어 올 때, 나는 원칙과 규율에 의해 행동하는 자와 일반 상식에 의해 움직이는 자의 차이점에 대해서 인식하기 시작하였다. 전자는 군사 퍼레이드를 할 때나 좋아 보이지만, 실상 현실에서는 아무 쓸모 없고 수많은 의지를 모아서 노력에 의해서만 목표가 성취될 때는 큰 의미가 없었다.’
“수많은 의지를 모아서 노력하는 것”은 정확히 리눅스 같은 프로젝트가 필요로 하는 것이다. - 그리고 명령의 원리는 우리가 인터넷이라고 부르는 무정부주의자들의 천국에 있는 자원 봉사자들에게는 적용하는 것은 불가능하다. 효과적으로 실행하고 경쟁하기 위해서, 협업 프로젝트를 이끌고 싶어하는 해커들은 Kropotkin 의 “이해의 원리”에서 모호하게나마 제시된 방법에 따라 어떻게 채용하고 공동체의 관심을 촉진시킬지를 배워야 한다. 그들은 리누스의 법칙을 사용할 줄 알아야 한다.
전에, 리누스의 법칙을 설명하기 위해서 델파이 효과를 언급하였다. 그러나 생물학과 경제학의 시스템의 적응계에 비유하는 것이 더 강력하다고 할 수 있다. 리눅스 세계는 많은 부분에서 일정 수의 이기적인 주체들이 효용을 극대화 시키기 위해서 노력하는 과정 속에서 자가 수정하고 더 정교하게 하며 그 어떤 중앙 집권하의 계획보다 더 효율적으로 움직이는 시장과 생태계와 같다. 여기서 “이해의 원리”를 찾아낼 수 있다.
리눅스 해커들이 최대화하려는 효용함수는 고전적 경제의 의미가 아니고 다른 해커들 사이에서의 명성이나 자가 만족과 같은 무형의 것이다. (혹자는 그들의 동기를 이타적이라고 하지만, 이것은 이타주의가 이타주의자들의 자가 만족의 한 형식 그 자체라는 팩트를 무시한 발언이다.) 이런 방식으로 진행되는 자발적 문화는 사실 그렇게 희귀한 것은 아니다 ; 내가 오랫동안 참여해왔던 또 하나의 그룹은 과학소설 팬 모임이었다. 해커들의 모임과 크게 다르지 않게 “egoboo”(자아 상승 혹은 다른 팬들 사이에서 한 사람의 명성이 올라 가는 것) 을 자발적 행동의 기초적인 원동력으로 생각한다.
대부분 타인들에 의해서 발전된 프로젝트의 게이트 키퍼로서 자리를 공공히 하는데 성공하고 프로젝트가 유지될 수 있도록 흥미거리를 지속 공급한 리누스는 Kropotkin dml “공유 이해의 원리”의 의미를 정확하게 보여주었다. 이 준경제학적인 관점으로 리눅스 세계를 보았을 때, 어떻게 이해가 적용되었는지를 알 수 있다.
우리는 리누스의 방법을 자아 상승에 있어서 효율적인 시장을 만드는 방법 중 하나라고 볼 수 있다. - 해커 개개인의 이기심을 최대한 단단하게 지속적인 협동으로만 이룩할 수 있는 어려운 목적과 연결 시키는 것이다. 페치 메일 프로젝트에서는 나는 (더 작은 규모에서) 이 방법을 그대로 따라하여 좋은 결과를 낸 것을 보여주었다. 아마도 내가 그보다 조금 더 의식적이고 체계적으로 일처리를 했었을 것이다.
많은 사람들은(특히나 자유시장을 정치적으로 신뢰하지 않는) 스스로에게 맞추어진 이타주의자들의 문화가 파편화되고 텃세가 심하고 소모적이며 비밀이 많고 적대적일 것이라고 기대한다. 그러나 그 기대는 완벽하게 (예를 하나 들자면) 놀랄만한 다양성, 질 그리고 깊은 리눅스 문서에 의해 허구임을 알 수 있게 된다. 프로그래머들이 문서화 작업을 끔찍히 싫어하는 것은 자명한 사실로 받아들여지고 있다. 그런데 그렇다면 리눅스 해커들이 그렇게 많은 문서들을 생성해낸 것은 어떻게 설명할 것인가? 분명히, 리눅스의 자아상승을 위한 자유시장은 막대한 자금이 들어간 상업용 소프트웨어 프로듀서들의 문서작업보다 다른 사람을 위한 고결한 행동을 더 잘 한 것이다.
페치메일과 리눅스 커널 프로젝트 모두 적절하게 많은 해커들의 자아를 보상해줌으로써, 강력한 개발자 / 협력자 가 인터넷을 이용하여 많은 수의 공동개발자를 가지는 이익을 얻으면서 프로젝트가 혼돈스럽게 스스로 붕괴하는 것을 막을 수 있다는 것을 보여준다. 브룩스 법칙에 대해서 나는 반대 의견을 제안한다 :
- 인터넷 만큼 괜찮은 통신 수단이 있고 강제력 없이 어떻게 이끌어 나갈지 안다면 한명 보다는 여러 명의 리더가 필연적으로 더 낫다.
내 생각엔 미래의 오픈소스 소프트웨어는 리누스의 게임을 어떻게 하는지 아는 사람들, 성당을 뒤로하고 바자르를 포용할 수 있는 사람들에게 점점 더 속할 것이라고 생각한다. 개인의 비전과 똑똑함이 문제가 되지 않는다는 말보다는 오픈 소스 소프트웨어의 최첨단은 개인의 비전과 똑똑함에서 출발해서 자발적으로 흥미를 보이는 공동체를 효과적으로 구축해서 그것을 증폭시키는 사람들에게 속할 것이라는 의미이다.
아마도 이것은 오직 오픈 소스 소프트 웨어만의 미래는 아닐 것이다. 그 어떤 닫힌 소스 개발자도 문제를 해결하기 위해서 리눅스 공동체가 끌어들이수 있는 인재풀의 능력과 경쟁할 수 없을 것이다. 극소수만이 페치메일에 공헌한 200명 이상의 사람을 고용할 수 있을 것이다.
아마도 결국에는 오픈소스 문화가 도덕적으로 더 옳거나 소프트웨어 ‘매점’이 도덕적으로 틀려서가 아니라 단지 닫힌 소스 세계가 특정 문제에 더욱 숙련된 사람의 시간을 쏟을 수 있는 오픈 소스 공동체에게 군비 경쟁을 하였을 때 이길 수 없을 것이기에, 오픈 소스 문화가 이길 것 이다.