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

제목	[번역] 성당과 시장 #2 1998/10/20 (10:29)
이름	김효원
번호	122
조회	2992
본문	11) 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다. (The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better ) 흥미롭게도 만일 당신이 얼마나 다른사람에게 빚을 많이 지고 있는지를 자기비하라고 느껴질 정도로까지 솔직하게 털어놓는다면 대개의 사람들은 당신이 혼자서 거의 모든 일을 해내고서 천재성에 대해서 겸손해 하는 것처럼 대한다는 것을 곧바로 알게 될 것이다. 리누스의 경우를 보라! (1997년 8월, Perl 컨퍼런스에서 이 글을 발표할 때 래리 월이 첫 번째 줄에 앉아 있었다. 바로 윗 줄에 도달했을 때 그는 부흥사라도 된 것처럼 외쳤다. "형제여, 이야기 하시오, 이야기를!" 청중들 모두가 이것이 Perl을 만든 래리에게도 적용된다는 것을 알았기 때문에 웃음을 터뜨렸다) 똑같은 정신으로 프로젝트를 몇 주 진행해 나가자 나는 사용자들 뿐 아니라 이야기를 전해들은 다른 사람들로부터 비슷한 칭송을 받기 시작했다. 나는 그런 email 중 몇몇을 따로 보관해 두었다. 나중에 내 삶이 가치있는 것이었는지 의심스러워질 때 그 메일들을 다시 꺼내볼 생각이다. :-) 모든 종류의 설계에 대해서 적용될 수 있는 두가지 더 기본적이며 비정치적인 교훈이 있다. 12) 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다. (Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong) 나는 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) "(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. (Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away)" 코드가 더 나아지고 간단해 지고 있을 때가 바로 일이 제대로 되어가고 있다는 것을 "알게 되는" 때다. 그리고 그 과정에서 fetchmail 의 설계는 조상격인 popclient 와 다른, 자신만의 정체성을 획득했다. 이름을 바꿀 때가 된 것이다. 새로운 설계는 예전의 popclient 보다는 sendmail 과 비슷해 보였다. 둘다 MTA 였으나 sendmail 은 푸시(push) 후에 메일을 배달했고 새로운 Popclient 는 풀(pull) 후에 메일을 배달했다. 해서 두 달 후에 나는 Popclient 의 이름을 fetchmail 로 변경했다. #133   정직한   (어니스트) [번역] 성당과 시장 (3/4)                     09/09 17:25   228 line 7. Fetchmail 의 성장 이제는 깔끔하고 혁신적인 설계, 매일 사용하므로 잘 작동하는 것을 알고 있는 코드, 발전하고 있는 베타테스터의 목록을 가지고 있었다. 더이상 내가 하고 있는 일이 몇몇의 사람에게 유용할 수도 있는 사소하고 개인적인 해킹은 아니라는 생각이 서서히 들기 시작했다. 내가 가지고 있는 것은 유닉스 박스와 SLIP/PPP 메일 연결을 가지고 있는 모든 해커들이 정말로 필요로 하는 프로그램이었다. SMTP 포워딩 기능으로 fetchmail 은 경쟁에서 멀찍이 앞서나와 "카테고리 킬러," 그러니까 해당분야의 다른 프로그램들은 아예 잊혀져 버릴 만한 경쟁력을 갖추고 자신의 지위를 확고하게 하는 고전적인 프로그램이 될 수 있는 능력을 갖추었다. 이런 결과를 계획하거나 목표로 가질 수는 없으리라고 생각한다. 아주 강력한 설계상의 아이디어로 그런 결과가 불가피하고, 자연스러우며 운명적인 것으로 보이게 함으로써 그런 결과에 도달해야 한다. 그런 아이디어를 구체화해 볼 수 있는 유일한 방법은 수많은 아이디어를 가지는 것이다. 아니면 다른 사람들의 좋은 아이디어를, 원래 생각되었던 것보다 더 멀리 이끌고 가서 구체화 시켜보는 방법이다. 앤드류 타넨바움 (Andrew Tanenbaum) 은 교습도구로 사용하기 위해 386용으로 간단한 네이티브 유닉스를 만들려는 원래의 아이디어를 가지고 있었다. 리누스 토발즈는 이 미닉스의 개념을 앤드류가 생각했던 것보다 더 멀리 밀고 나갔다. 그래서 리눅스는 굉장한 것이 되었다. 똑같은 방식으로 (더 작은 스케일이었지만) 나는 칼 해리스와 해리 호흐하이저의 아이디어들을 가져와 강하게 밀어붙였다. 리누스나 나나 사람들이 천재들이 그러하리라고 생각하는 낭만적인 의미에서 '독창적' 인 것은 아니었다. 하지만 통념과는 반대로 대부분의 과학과 공학과 소프트웨어 개발은 독창적인 천재, 해커의 전설에 의해서 이루어지지 않는다. 결과물은 똑같이 매우 사람을 흥분시키는 것들이다 -- 사실, 모든 해커들은 이런 종류의 성공을 얻기 위해 살아간다! 거기에는 내가 기준을 더 높이 잡아야 한다는 의미도 들어있다. fetchmail을 최상의 것으로 만들기 위해 나는 내자신의 필요뿐 아니라 나와는 상관없지만 다른 사람들에게는 필수적인 기능을 포함시키고 지원해야했다. 게다가 프로그램을 단순하고 튼튼하게 유지시키면서 그런 일을 해야 했다. 이것을 깨닫고 나서 내가 추가한 매우 중요한 첫 번째 기능은 멀티드롭(multidrop) 기능이었다. 그룹이나 사용자들의 메일을 한꺼번에 가지고 있는 메일박스에서 메일을 가져와 각 메일들을 개인 수신자에게 라우트(route) 시켜주는 기능이었다. 멀티드롭 기능을 추가하기로 한 데는 몇몇 사용자들이 원한다는 것도 있었지만 가장 큰 이유는 어드레싱을 완전히 구현함으로써 싱글드롭 코드에 있는 버그들을 잡아낼 수 있으리라고 생각했기 때문이다. 그리고 그렇게 되었다. RFC822(http://www.internic.net/rfc/rfc822.txt) 의 파싱을 제대로 구현하는 것에 매우 오랜 시간이 걸렸는데, 각각의 조각이 어려웠기 때문이 아니라 각각이 서로 의존하고 있으며 세심하게 신경을 써야 하는 사항들이었기 때문이다. 하지만 멀티드롭 어드레싱 역시 매우 훌륭한 설계상의 결정이었던 것으로 드러났다. 다음과 같은 교훈을 얻을 수 있었다. 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) 어떤 종류든 게이트웨이 소프트웨어를 만들려고 한다면 데이터스트림에 가능한 한 최소한의 조작만 가하라 -- 그리고 수신자가 강제로 하게 하지 않는다면 정보를 *절대로* 잘라버리지 말라. (... the data stream as little as possible -- and *never* throw away informtion unless the recipient forces you to!) 이 규칙을 따르지 않았다면 8비트 MIME 지원은 매우 어려웠을 것이며 많은 버그를 만들어 냈으리라. 규칙을 따랐기 때문에 내가 해야 할 일은 RFC 1652 (http://www.internit.net/rfc/rfc1652.txt)를 읽고 헤더생성 로직을 약간 수정하는 것 뿐이었다. 유럽의 몇몇 사용자들은 한 세션에서 가져올 수 있는 메시지의 수를 제한하도록 옵션을 추가해달라고 요구해왔다. (전화 네트워크의 비싼 비용을 조절할 수 있도록 해달라는 말이다) 오랫동안 여기에 저항했고, 아직도 완전히 수긍하지 못했다. 하지만 세계를 상대로 프로그램을 만든다면 고객들의 소리에 귀를 기울여야 한다 -- 그들이 돈을 지불하지 않는다고 해도 마찬가지다. 8. Fetchmail에서 배울 점 일반적인 소프트웨어공학의 주제로 돌아가기 전에 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 코드에서 디코딩하는 코드를 뽑아낼 수도 있다. fetchmail 의 패스워드를 암호화 했다면 사람들은 그리 심각하게 생각하지도 않고 보안에 대해 잘못된 관념을 가지게 되었을 것이다. 여기서 알 수 있는 일반적인 규칙은 다음과 같다. 17) 보안시스템은 그것이 보호하려고 하는 비밀만큼만 안전하다. 가짜 비밀들에 주의할 것. (A security system is only as secure as its secret. Beware of pseudo-secrets) 9. 시장 스타일의 개발에 필요한 선행조건들 이 글을 초기에 검토해준 사람들과 시험적으로 청중이 되었던 사람들은 계속해서 성공적인 시장 스타일의 개발을 위한 선행조건이 무엇인지 물었다. 여기에는 공동개발자의 공동체를 만들기 위해 프로젝트가 공개되는 시점에 리더의 자질과 코드가 어떤 상태인지가 포함된다. 아예 처음부터 시장스타일로 개발할 수 없다는 것은 자명하다. 테스트, 디버그, 그리고 개선은 시장 스타일로 할 수 있다. 하지만 프로젝트를 시/작/할/때/ 시장 스타일로 시작하기는 매우 어렵다. 리누스는 그렇게 하지 않았다. 나도 마찬가지. 개발자들의 공동체는 초기에 실행시키면서 테스트할 수 있는 장난감이 필요하다. 공동체를 만들기 시작할 때 제시할 수 있어야 하는 것은 그럴듯한 장래성이다. 프로그램이 특별히 잘 작동할 필요는 없다. 조잡하거나, 버그투성이여도 되고, 완성되지 않고 문서가 형편없어도 상관없다. 하지만 한가지 확실하게 해야할 것은 잠재적인 공동개발자들에게 이것이 머지 않은 미래에 정말 괜찮은 무언가로 진화할 수 있다는 것을 납득시키는 일이다. 리눅스와 fetchmail 둘 다 강력하고 매력적인 기본설계를 가지고 공개되었다. 내가 시장모델에 대해 이야기하자 많은 사람들이 이것을 중요하다고 생각했고, 높은 수준의 설계에 대한 직관과 영리함이 프로젝트의 리더에게는 필수적인 것이라고 지레짐작으로 결론을 내려버렸다. 하지만 리누스는 그의 설계를 유닉스에서 따왔고 나는 기본적으로 popclient에서 가져왔다. (물론 나중에 많은 것이 바뀌긴 했지만 리눅스는 그보다 훨씬 더 바뀌었다). 그렇다면 시장스타일의 리더/조정자에게 정말 특별한 설계의 재능이 필요한 것일까, 아니면 다른 사람들이 가진 설계의 재능을 이끌어 내는 것이 필요한 것일까? 나는 조정자가 특별하게 영리해서 독창적인 설계를 만들어낼 수 있는지의 여부가 중요하다고 생각하지 않는다. 하지만 조정자가 다/른/사/람/의 좋/은/ 설/계/를 알/아/볼 수 있는지는 절대적으로 중요하다. 리눅스와 fetchmail 프로젝트는 이에 대한 증거를 보여주고 있다. 리누스는 (앞서 논했듯이) 대단히 독창적인 설계자라고는 할 수 없으나 좋은 설계를 알아보는 대단한 요령을 보여주었고, 그것을 리눅스 커널에 통합해 넣었다. 앞서 fetchmail에서 가장 강력한 설계상의 아이디어 하나 (SMTP 포워딩) 가 다른 누군가로부터 온 것이라고 설명한 바 있다. 이 글의 초기 청중들은 내가 설계상의 독창성을 과소평가하는데 내가 그런 독창성을 가지고 있기 때문에 당연한 일로 생각한다고 주장하며 내게 경의를 표시했다. 어느 정도는 사실이다. 설계는 분명히 (코딩이나 디버깅에 비해서) 내가 가장 잘하는 일이다. 하지만 소프트웨어 설계에 있어서 똑똑하고 독창적이라는 것의 문제점은 그게 버릇이 되어버린다는 점이다 -- 설계를 강력하고 단순하게 유지해야 할 때 그렇게 하지 않고 계속해서 일을 멋지고 복잡하게 만들기 시작한다. 이전의 프로젝트에서 나는 그런 성향 때문에 실패한 적이 있었다. fetchmail 에서는 간신히 그것을 이겨냈다. 그래서 나는 fetchmail에서 성공할 수 있었던 것이 부분적으로는 똑똑해지려는 유혹을 이겨냈기 때문이라고 생각한다. 이것은 (최소한) 성공적인 시장 프로젝트에 설계상의 독창성이 필수적이라는 점에 대해서는 반대되는 주장이다. 리눅스를 생각해 보자. 리누스 토발즈가 개발도중에 운영체에 설계에 있어서 근본적인 혁신을 이끌어내려고 노력했다고 가정해 보자. 결과로 만들어진 커널이 우리에게 있는 것처럼 안정적이고 성공적이었을 것이라고 생각이나 할 수 있을까? 어느 정도 기본적인 수준의 설계와 코딩기술은 물론 필요하긴 하지만 시장 스타일의 프로젝트를 시작하려고 심각하게 생각하고 있는 사람이라면 그런 정도는 최소한 넘어섰으리라고 기대하는 것이다. 평판에 대한 오픈소스 공동체의 내부시장은 미묘한 압력을 사람들에게 작용한다. 그래서 지속적으로 따라갈 수 있는 경쟁력을 가지고 있지 않은 사람이라면 개발 프로젝트를 시작하지 않게 된다. 지금까지 이것은 잘 들어맞아왔던 것 같다. 시장 스타일의 프로젝트에서 똑똑한 설계만큼이나 중요하다고 생각하는 것이지만 일반적으로 소프트웨어 개발과는 연관짓지 않는 또 한 종류의 기술이 있다 -- 어쩌면 더 중요할 지도 모른다. 시장스타일의 프로젝트를 조정하거나 이끄는 사람은 사람들과 잘 의사소통하는 기술을 가지고 있어야 한다. 이것은 명확하다. 개발자들의 공동체를 만들려면 사람들을 끌어모아야 하고 무엇을 하고 있는지 그들에게 흥미를 주어야 하고 그들이 하는 일의 결과에 대해서 기분좋을 수 있도록 만들어 주어야 한다. 기술적인 논란(sizzle)은 이런 것을 이룩하는데 도움이 많이 되긴 하지만 그것이 전부는 아니다. 그 사람의 성격도 크게 작용을 한다. 리누스가 괜찮은 녀석이고 다른 사람들이 그를 좋아하게 되며 그를 도와주고 싶어한다는 것은 우연이아니다. 내가 정력적이고 외향적이며 많은 사람들과 일하는 적을 즐기고 만화 속의 인물 비슷한 인상을 주는 것은 우연이 아니다. 시장 모델이 성공하게 하려면 자신이 사람을 끄는 매력이 조금이라도 있는 것이 매우 큰 도움이 된다. #134   정직한   (어니스트) [번역] 성당과 시장 (4/4)                     09/09 17:31   263 line 10. 오픈소스 소프트웨어의 사회적 문맥 다음과 같은 말이 있다. 가장 뛰어난 해킹은 해커의일상적인 문제를 푸는 개인적인 해결책으로 시작한다. 그리고 그 문제가 많은 사용자들에게 전형적이라는 것이 밝혀지면 널리 퍼지게 된다. 첫 번째 법칙으로 되돌아와 (아마도) 더 유용한 방식으로 다시 말해보자. 18) 재미있는 문제를 풀어보고 싶다면 자신에게 재미있는 문제를 찾아 나서는 것부터 시작하라. (To solve an interesting problem, start by finding a problem that is interesting to you) 칼 해리스와 popclient가 그러했고, 나와 fetchmail 이 그러했다. 하지만 이것은 오래전부터 이해되고 있었다. 재미있는 점은 리눅스와 fetchmail 의 역사가 가리키고 있는 것처럼 다음 단계에 있다 -- 사용자와 공동개발자가 이루는 크고 활동적인 공동체의 눈앞에서 소프트웨어가 진화해 가는 것이다. "Man-Month 의 신화"에서 프레드 브룩스는 프로그래머의 시간이 다른 것으로 대체될 수 없다고 진술했다. 지연되고 있는 소프트웨어 프로젝트에 개발자를 더 투입하는 것은 완료시기를 더 늦출 뿐이다. 그는 프로젝트에서 복잡성과 의사소통에 드는 비용이 개발자의 제곱에 비례하는 반면 일이 되어가는 것은 직선적으로만 증가한다고 주장했다. 이 주장은 그때부터 "브룩스의 법칙" 으로 알려졌고 널리 자명한 이치로 간주되었다. 하지만 브룩스의 법칙이 전부라면 리눅스는 불가능했을 것이다. 나중에 제랄드 와인버그의 고전인 "컴퓨터 프로그래밍의 심리학 (The Psychology Of Computer Programming)"에서 브룩스의 말에 대한 중요한 수정사항이 제시되었다는 것을 알 수 있다. "자아를 내세우지 않는 프로그래밍(egoless programming)" 에 대한 논의에서 와인버그는 개발자들이 자신의 코드에 대해서 텃세를 부리지 않고 다른 사람들로 하여금 버그를 찾고 개선가능성을 찾아내도록 격려하는 곳에서는 다른 어느 곳에서보다 극적으로 빠른 개선이 일어난다고 이야기했다. 아마도 와인버그의 분석이 적절한 평가를 받지 못했던 것은 용어선택의 문제 때문이었을 것이다 -- 인터넷의 해커들이 "자아를 내세우지 않는다" 고 묘사하는 것에는 웃음을 지을 수 밖에 없다. 하지만 나는 그의 주장이 지금 그 어느때보다 절실하다고 생각한다. 유닉스의 역사는 우리가 리눅스로부터 배우고 있는 것을 (그리고 내가 실험적으로 더 작은 스케일로 리누스의 방법을 따라 함으로써 검증한 것을) 미리 준비해 두었어야 했다. 다시 말해 코딩은 본질적으로 고독한 작업인데 비해 정말 중요한 해킹은 전체 공동체의 주의와 지력(brainpower)를 이용함으로써 이루어진다는 것이다. 폐쇄된 프로젝트에서 자신의 뇌만을 사용하는 개발자는 수백명의 사람들이 버그를 찾아내고 개선을 이루어내는 열려있는 진화적 문맥을 어떻게 만들어내는지 아는 개발자에게 뒤떨어지기 마련이다. 하지만 전통적인 유닉스 세계에는 이런 접근방법을 끝까지 밀어붙이지 못하도록 하는 요인이 몇 가지 있었다. 첫 번째는 다양한 라이센스의 법적인 제약, 거래비밀, 그리고 상업적인 이해관계였다. 또 하나는 (나중에서야 알게 되었지만) 인터넷이 그리 훌륭하지 못했기 때문이다. 싼 가격에 인터넷을 이용할 수 있게 되기 전에는 지리적으로 좁은 지역에서 공동체가 자리잡고 있었고, 그 공동체의 문화는 와인버그의 "자아를 내세우지 않는" 프로그래밍이 장려되었으며 개발자들은 쉽게 많은 사람들, 숙련된 훈수꾼들과 공동개발자들을 끌어들일 수 있었다. 벨 연구소, MIT 인공지능 연구소, UC 버클리 -- 이곳이 바로 전설적인 혁신들이 일어난 곳이고, 여전히 그런 잠재력을 가지고 있는 곳이다. 리눅스는 재능을 끌어올 풀(pool) 로 전세계를 사용하기 위해 의식적으로, 또 성공적으로 노력한 최초의 프로젝트였다. 나는 리눅스의 태동기가 월드와이드웹의 탄생과 일치하는 것을, 그리고 리눅스가 유아기를 벗어나던 1993-1994년 경에 ISP 산업과 인터넷에 주류의 관심이 폭발하기 시작했던 것을 우연이라고 생각하지 않는다. 리누스는 급속히 보급되는 인터넷을 가능하게 했던 그 규칙에 따라 어떻게 일을 진행해야 하는지 알았던 최초의 사람이다. 저렵하게 인터넷을 사용할 수 있었던 것이 리눅스 모델이 진화하는데 필수적인 조건이었긴 하지만 그것이 충분조건이라고 생각하지는 않는다. 또 하나의 중요한 요소는 리더십 스타일과 협력하는 관습의 발전인데, 이것이 개발자로 하여금 공동개발자를 끌어모으고 매체를 최대한으로 활용하게 했던 것이다. 그렇다면 리더십 스타일이란 무엇이고 이런 관습이란 어떤 것인가? 권력관계에 기반한 것은 분명 아니다 -- 만일 그런 것에 기반했다면 강제에 의한 지도력은 우리가 보고있는 것과 같은 결과를 내지 못했을 것이다. 와인버그는 19세기 러시아 무정부주의자인 표트르 알렉세이비치 크로포트킨의 자서전, "한 혁명가의 비망록" 으로부터 다음과 같은 구절을 인용하고 있다. "농노를 소유한 가정에서 컸기 때문에 나는 내 시대의 모든 젊은이들처럼 능동적인 생활을 했다. 명령하고, 지시하고, 꾸중하고, 벌주는 그런 일에 대한 필요성을 크게 확신하고 있었다. 하지만 내가 큰 사업을 경영해야 했을 때는 다른 사람(자유인)들과 거래해야 했고 단 한 번의 실수가 심각한 결과를 가져올 수 있게 되었을 때 명령과 훈육의 원리에 기반해 행동하는 것과 공동이해의 원리에 의해 행동하는 것 사이의 차이점을 높이 평가하기 시작했다. 군대에서라면 전자에 의해 일하는 것이 훨씬 낫겠지만 실생활에서, 많은 사람들의 의지를 수렴하여 노력해야만 이룰 수 있는 목표를 겨냥했을 때는 별 가치가 없다." "많은 사람들의 의지를 수렴하여 노력하는 것" 이 바로 리눅스와 같은 프로젝트가 요구하는 것이다 -- 그리고 "명령의 원리" 는 결과적으로 우리가 인터넷이라고 부르는 무정부주의자들의 천국에 사는 자원봉사자들에게 적용하기 불가능한 것이다. 효과적으로 일하고 경쟁하기 위해 공동 프로젝트를 이끌어보고 싶은 해커들은 크로포트킨의 "이해의 원리" 가 어렴풋이 제시하고 있는 방식에 따라 같은 관심을 가진 공동체를 어떻게 효과적으로 끌어모으고 격려할 것인지 배워야 한다. 앞에서 나는 리누스의 법칙을 설명하기 위해 "델파이 효과"를 언급했다. 하지만 생물학과 경제학에서의 적응계에 비유하는 것이 더 강력한 비유라고 할 수 있다. 리눅스 세계는 많은 점에서 생태계나 자유시장과 같이 행동한다. 일단의 이기적인 에이전트들이 효용을 극대화시키기 위해 애쓰는 과정을 통해 스스로를 수정하는 자율적인 질서를 만들어 내며 이것은 중앙통제가 이룰 수 있는 어떤 결과보다 더 정교하고 효율적이다. 그렇다면 여기에서 "이해의 원리"를 찾아낼 수 있다. 리눅스의 해커들이 최대화하려고 하는 "효용함수" 는 고전적인 의미에서의 경제적인 것은 아니고 그들 자신의 측정할 수 없는 자아만족과 다른 해커들 사이의 평판이다. (이런 동기를 "이타적" 이라고 말할 지도 모르겠지만 그렇게 말하는 것은 이타주의가 이타주의자가 자아를 만족시키는 한 형태라는 사실을 무시하는 것이다) 이런 방식으로 일을 처리하는 자발적인 문화는 사실 그렇게 찾아보기 힘든 것은 아니다. 내가 오랫동안 참여해왔던 또 하나의 문화는 과학소설 팬들의 세계 (science fiction fandom) 이다. 해커들의 세계와 다르지 않게 여기에서는 "자아상승" (다른 팬들 사이에서 자신의 평판이 높아지는 것) 이 자발적인 활동 뒤의 기본적인 동기라고 분명하게 인식한다. 리누스는 자신을 개발은 대부분 다른 사람들에 의해 이루어지는 프로젝트의 수문장으로 위치시키는데 성공했고, 프로젝트가 스스로 유지할 수 있게 될 때까지 계속해서 흥미거리를 공급해 줌으로써 크로포트킨의 "공유이해의 원리" 의 의미를 정확하게 따랐다. 준-경제학적인 관점에서 리눅스 세계를 보면 어떻게 이해가 적용되었는지를 알 수 있다. 리누스의 방법을 "자아상승" 에 있어서 효과적인 시장을 만드는 길로 볼 수 있다 -- 개개인인 해커들의 이기심을 최대한 단단하게 지속적인 협동으로만 이룩할 수 있는 어려운 목적과 연결시키는 것이다. fetchmail 프로젝트에서 나는 (더 작은 규모였지만) 이 방법을 그대로 따라했고 좋은 결과를 냈다. 아마도 내가 리누스보다 더 의식적이고 체계적으로 일을 해냈을 것이다. 많은 사람들이 (특히 자유시장을 정치적으로 믿지 않는 사람들) 스스로에게 방향이 맞추어진 이기주의자들의 문화가 파편화되어 있으며 텃세가 심하고 소모적이면서, 비밀이 많고 적대적일 것이라고 생각한다. 하지만 이런 기대는 (예를 하나만 들자면) 리눅스 문서의 놀랄만한 다양성과 질, 깊이에 의해 산산이 부서지고 만다. 프로그래머들이 문서작업을 끔/직/하/게 싫/어/한/다/는 것은 모두가 기정사실로 받아들이고 있다. 그렇다면 대체, 리눅스 해커들이 문서를 그렇게 많이 만들어냈다는 것은 어떻게 설명할 것인가? 분명히 리눅스의 자아상승을 위한 자유시장은 막대한 자금이 들어간 상업용 소프트웨어 프로듀서들의 문서작업보다 다른 사람을 위한 고결한 행동을 더 잘 해낸 것이다. fetchmail 과 리눅스 커널 프로젝트는 둘 다 많은 해커들의 자아를 적절히 보상해 줌으로써 강력한 개발자/조정자 가 인터넷을 이용하여 많은 수의 공동개발자를 가지는 이익을 얻으면서 프로젝트가 혼돈스럽게 스스로 붕괴하는 것을 막을 수 있다는 것을 보여준다. 브룩스의 법칙에 대해서 나는 다음과 같은 반대제안을 한다. 19) 개발 조정자가 최소한 인터넷만큼 좋은 매체를 가지고 있으며 강제력을 사용하지 않고 어떻게 이끌어야 할 지 알고 있다면 한 명 보다는 여러명의 리더가 필연적으로 더 낫다. (Provided the development coordinator has a medium at least as good as the Internet, and know how to lead without coercion, many heads are inevitable better than one) 미래의 오픈소스 소프트웨어는 점점 리누스의 게임을 어떻게 해야 하는지 아는 사람들, 성당을 뒤로 하고 시장을 끌어앉을 수 있는 사람들에게 속할 것이라고 생각한다. 개인의 비전과 똑똑함이 문제가 되지 않으리라는 말이라기보다는 오픈소스 소프트웨어의 최첨단은 개인의 비전과 똑똑함에서 시작하여 자발적으로 흥미를 보이는 공동체를 효과적으로 구축해서 그것을 증폭시키는 사람들에게 속할 것이라는 뜻이다. 그리고 오/픈/소/스 소프트웨어의 미래에만 국한되지는 않을 것이다. 닫혀있는 소스로 개발하는 사람은 리눅스 공동체가 문제를 해결하기 위해 끌어낼 수 있는 재능의 풀과 경쟁할 수 없다. 극소수만이 fetchmail 에 공헌했던 20명보다 많은 사람을 고용할 수있을 것이다. 아마 최종적으로는 협동이 더 도덕적이라거나 소프트웨어 "매점" 이 덜 도덕적이라서가 아니라 단지 닫혀진 소스 측과 오픈소스 공동체와의 군비경쟁에서 오픈소스 측이 한 문제에 훨씬 큰 비율로 숙련된 사람의 시간을 쏟을 수 있기 때문에 오픈소스 문화가 승리를 거둘 것이다. 11. 감사의 글 이 글은 많은 사람들과의 대화를 통해 잘못을 수정하는데 도움을 받았다. 특별히 제프 덧키(Jeff Dutck : dutky@wam.umd.edu) 에게 감사한다. 그는 "디버깅은 병렬처리가 가능하다" 는 말을 제안해 주었고 그로부터아어지는 분석을 발전시키는데 도움을 주었다. 낸시 레보비츠(Nancy Lebovitz : nancyl@univers.digex.net) 에게도 감사한다. 그녀는 크로포트킨을 인용하여 내가 와인버그를 흉내내도록 도와주었다. General Technics 리스트의 조안 에슬링거 (Joan Eslinger wombat@kilimanjaro.engr.sgi.com) 와 마티 프란츠 (Marty Franz marty@net-link.net) 도 예리한 비판을 보내주었다. 폴 에거트 (Paul Eggert eggert@twinsun.com) 는 GPL 과 시장 모델의 상충되는 점을 알려주었다. 이 글의 첫 번째 공개버전의 첫 번째 시험적인 청중이 되어준 필라델피아 리눅스 사용자 모임 (PLUG : Philadelphia LInux User's Group) 의 멤버들에게 감사한다. 마지막으로 리누스 토발즈의 논평은 도움이 되었으며 초기에 그가 해준 추천은 매우 격려가 되는 것이었다.

1998 by swindler