그래서 내가 popclient를 넘겨 받았다. 내가 popclient의 사용자들을 넘겨받았다는 것도 그에 못지않게 중요하다. 사용자들이 있다는 것은 매우 좋은 일이다. 당신이 누군가의 필요를 충족시켜주고 있으며 일을 잘 해나가고 있다는 것을 보여주기 때문만은 아니다. 적절하게 유도해 준다면 사용자들은 co-developers가 될 수 있다.
유닉스의 전통이 가지고 있는 또 하나의 강점, 즉 많은 수의 사용자들이 동시에 해커이기도 하다는 것을 리눅스는 좋은 의미로서의 극단까지 밀어붙였다. 소스코드가 공개되어 있기 때문에 그들은 효과적인 해커가 될 수 있다. 이것은 디버깅 시간을 줄이는 데 엄청난 도움이 되었다. 조금만 격려해주면 사용자들은 문제를 분석하고 해결책을 제시하며, 도움 없이 혼자 일할 때보다 훨씬 빨리 코드를 개선시키도록 해준다.
- 사용자들을 co-developers로 여기는 것은 least-hassle 루트들을 빠르게 향상시키며 효율적으로 debugging을 할 수 있게 한다.
이 효과의 위력은 과소평가되기 쉽다. 사실, 오픈 소스 세계의 우리들조차 시스템의 복잡도에 대항하여 많은 수의 사용자가 얼마나 힘이 되는지를 Linus Tovalds가 보여주기 전까지는 과소평가하고 있었다.
실제로 나는 Linus의 가장 영리하고 가장 중요한 해킹은 리눅스 커널을 만들었다는 점이 아니라 리눅스 개발모델을 만들었다는 점이라고 생각한다. Linus에게 이 의견을 말해 주었더니 그는 씨익 웃고서 조용히 여러 번 하던 말을 되풀이했다. "난 기본적으로 매우 게으른 사람이라서 실제로는 다른 사람들이 해놓은 일을 가지고 공로라고 인정받곤 해요." 여우 같은 게으름이다. Robert Heinlein이라면 “실패하기에는 너무 게으르다” 고 말했을 것이다.
되돌아 보면, 리눅스의 성공과 방법론은 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 Lisp 코드가 발표/테스트/개선의 주기를 매우 빨리 반복할 수 있었기 때문에 성공했다.
Emacs의 이야기는 유일하지 않다.다른 성당 방식의 핵심과 시장 도구상자를 포함한 two-level architecture와 two-tier 사용자 커뮤니티 소프트웨어 물품이 존재한다. 그중 하나가 상업적 데이터 분석과 시각화에 사용되는 MATLAB이다. MATLAB과 비슷한 구조의 다른 물품 사용자들은 변함없이 그 행동에 대해 말한다. 그 혁신은 대개 크고 다양한 커뮤니티가 문제를 일으킬 수있는 도구의 열린 부분에서 주로 발생한다.
일찍, 그리고 자주 발표하는 것은 리눅스 개발 모델의 중요한 부분이다. 대부분의 개발자들은 (나를 포함하여) 아주 사소한 프로젝트가 아니라면 이런 정책은 나쁜 것이라고 생각했다. 초기버전들은 예외 없이 버그가 많고, 개발자라면 사용자들의 인내심을 시험하고 싶지는 않기 때문이다.
이런 믿음이 성당건축 스타일의 개발을 더 선호하게 만들었다. 만일 가장 중요한 목표가 사용자들로 하여간 가능한 한 적은 버그를 발견하게 만드는 것이라면 6 개월에 한 번씩 (혹은 그보다 더 늦게) 발표하면서 그동안 죽어라고 일하는 편이 나을 것이다. Emacs C 코어는 이런 식으로 개발되었다. Lisp 라이브러리는 그렇지 않았다. Emacs 의 발표주기와 관계없이 언제든 새로운 개발 코드 버전을 찾을 수 있으며, FSF 의 통제권 밖에 있는 Lisp 라이브러리들이 있었기 때문이다.
이들 중 가장 중요한 아카이브는 오늘날 대형 리눅스 아카이브들의 정신과 많은 기능들을 이미 가지고 있었던 Ohio State의 elisp 아카이브였다. 하지만 우리가 하고 있는 일에 대해, FSF 의 성당건축 개발모델의 문제점들에 대해 그 아카이브의 존재가 무엇을 제시하는지에 대해 우리들 중 소수만이 진지하게 생각하고 있었다. 나는 1992년에 Ohio 코드를 공식적인 Emacs Lisp 라이브러리에 정식으로 병합시키려는 시도를 했으나 정치적인 문제에 부딪쳤고, 큰 실패를 겪었다.
그러나 1년 후에, 리눅스가 널리 알려지기 시작했고, 무언가 다르면서도 훨씬 바람직한 일이 일어나고 있다는 것이 확실해 보였다. Linus의 열린 개발정책은 성당건축과 완전히 반대되는 것이었다. 선사이트와 tsx-11 아카이브가 싹트고 있었고, 다중배포방식이 퍼지기 시작했다. 그리고 이 모든 것이 이전의 어느 소프트웨어보다 자주 릴리즈되는 코어시스템에 의해 주도되고 있었다.
Linus는 가장 효과적인 방식으로 사용자들을 co-developers라고 여겼던 것이다.
- 일찍 발표하고 자주 발표하라. 그리고 고객들의 소리를 들어라.
Linus의 혁신은 그가 이렇게 했다는 점 보다는 (그 비슷한 것이 오랫동안 유닉스 세계의 전통이었다) 그가 개발하고 있던 리눅스 커널의 복잡성에 비견될만한 수준으로까지 끌어올렸다는 데 있다. 초기에 (1991년 경에) 그는 하루에 한 번 이상 새로운 커널을 발표하기까지 했다. Linus가 co-developers들이라는 자신의 기반을 잘 만들었고, 인터넷이라는 지렛대를 이용하여 누구보다도 열심히 협동작업에 몰두했기 때문에 이런 방식은 성공했다.
하지만 어떤 과정을 거쳐 성공할 수 있었을까? 내가 재현할 수 있는 것일까, 아니면 Linus Tovalds만의 천재성이 필요한 것일까?
그렇게 생각되지는 않았다. Linus가 매우 뛰어난 해커라는 점은 인정한다. (우리 중에 상업용 제품 못지 않은 운영체제의 커널을 만들어낼 수 있는 사람이 몇이나 될까?) 하지만 리눅스는 놀랄만한 개념적 전진을 이루어내지는 않았다. Linus는 Richard Stallman이나 James Gosling (NeWS 와 자바를 만든) 과 같은 혁신적인 설계를 이루어내는 천재는 (적어도 지금까지는) 아니었다. 대신 Linus는 공학의 천재인 것으로 보인다. 버그와 개발의 막다른 골목을 피하는 육감, 그리고 A 점에서 B 점까지 가는데 최소노력 경로를 찾아내는 요령을 갖추고 있었다. 실제로 리눅스의 전반적인 설계는 이런 특성을 바탕으로 하고 있으며 Linus의 본질적으로 보수적이고 단순한 설계 방식을 반영하고 있다.
따라서 빠른 릴리즈와 인터넷을 매체로 사용하는 것이 우연히 이루어진 것이 아니라 Linus의 공학적 천재성에 기인한 최소노력 경로에 대한 통찰력의 통합적인 부분이었다면 그가 최대화하고 있는 것은 무엇이었을까? 기계에서 무엇을 뽑아내었던 것일까?
해답은 질문 안에 있다. Linus는 그의 해커/사용자들에게 지속적인 자극과 보답을 제공했다 -- 리눅스 개발에 참여함으로써 자기만족을 얻으리라는 전망에 자극받았고, 그들이 하는 일이 계속해서 (어떤 때는 날마다) 향상되고 있다는 것이 보답이 되었다.
Linus는 만일 처리하기 곤란한 심각한 버그가 발견되면 사용자들이 떨어져 나갈 위험과 코드가 불안정해질 가능성을 무릅쓰고 디버깅과 개발에 투입되는 공수(the number of person-hours)를 최대화 하는 것에 목표를 두었다. Linus는 다음과 같은 신념을 가지고 있는 것처럼 행동했다.
- 충분히 많은 베타 테스터와 co-developers가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다.
덜 형식적으로 말하자면, “보고 있는 눈이 충분히 많으면 찾지 못할 버그는 없다.” 나는 이것을 “Linus’s Law”' 이라고 부른다.
내 원래의 공식적인 서술은 모든 문제는 “누군가에게는 간단할 것이다.” 였다. Linus는 문제를 이해하고 고치는 사람이 그 문제를 처음 파악한 사람과 항상 같은 것이 아니라 오히려 다른 경우가 더 많다고 이의를 제기했다. Linus의 얘기로는, “누군가 문제를 발견합니다. 그리고 또다른 누군가가 그 문제를 이해하지요. 문제를 발견해 내는 것이 더 중요한 일이라고 분명히 말할 수 있습니다.” 하지만 가장 중요한 점은 사람이 충분히 많을 경우 이 두 가지가 모두 매우 빨리 일어나는 경향이 있다는 것이다.
Linus’Law에 따르면, 내 생각에는 여기에 성당 건축과 시장 스타일의 핵심적인 차이점이 있다. 프로그래밍의 성당 건축가 관점에서 보자면 버그와 개발 문제는 어렵고, 까다로우며 심오한 현상이다. 문제를 해결하려면 헌신적인 소수의 사람이 몇 달이고 정밀한 검사를 수행해야 모두 끝났다는 확신을 가질 수 있다. 따라서 발표 사이의 기간이 길어지고, 오랫동안 기다린 릴리즈가 완벽하지 않을 때는 필연적으로 실망이 따른다.
반면, 시장의 관점에서는 버그가 보통 쉽게 해결될 수 있는 것이라고 본다. -- 최소한 새로운 릴리즈가 나올때마다 그것과 씨름하는 수천의 열정적인 co-developers들에게 알려진다면 금방 쉽게 해결할 수 있는 문제로 바뀐다. 따라서 더 많이 교정을 받고 싶다면 자주 발표해야 하며 덤으로 서투른 부분이 드러나더라도 잃을 것이 적다는 이점이 있다.
바로 이것이다. 이것으로 충분하다. “Linus의 법칙” 이 틀렸다면 리눅스 커널과 같이 복잡한 시스템은 어떤 것이라도 수많은 손들에 의해 해킹되면서 일찍이 볼 수 없었던 나쁜 상호작용과 발견되지 못한 “심오한” 버그들에 의해 어느 시점에선가 붕괴되고 말았을 것이다. 반면에, 만일 그 법칙이 옳다면 그 법칙만으로도 리눅스의 상대적으로 적은 버그를 설명할 수 있다.
그리고 이 법칙이 옳다는 것에 대해서 너무 놀라지 말아야 할 것이다. 수년 전, 사회학자들은 비슷하게 전문적인 (혹은 비슷하게 무지한) 관찰자들로 이루어진 대중의 평균적인 의견이 그 관찰자 중 무작위로 뽑은 한 명의 의견보다 더 신뢰할 만하다는 점을 발견했다. 사회학자들은 이것을 Delphi effect 라고 부른다. Linus가 보여준 것은 이 효과가 운영체제를 디버깅하는 데에도 적용될 수 있다는 점이다. Delphi effect는 OS 커널만큼 복잡한 개발까지도 다룰 수 있는 것이다.
Delphi effect에 명확하게 도움이 되는 리눅스 상황의 한 가지 특별한 특징은 주어진 프로젝트의 참여자가 스스로 선택된다는 사실입니다. 빠른 응답자는 무작위 샘플이 아니라 소프트웨어 사용에 관심이 있는 사람들로부터 어떻게 작동하는지 배우고, 발생하는 문제에 대한 해결책을 찾으려고 시도하며, 실제로는 알맞은 합리적인 해결책을 제시한다고 지적했습니다. 이 모든 과정을 통과 한 사람은 기여할 수 있는 무언가를 가질 가능성이 큽니다.
Linus의 법칙은 “디버깅은 병렬처리가 가능하다” 는 말로 표현할 수 있음을 지적해 주었다. 디버거들이 디버깅을 하려면 의사소통을 조정해주는 개발자가 필요하지만 디버거들 사이에는 그다지 조정이 필요하지 않다고 진술한다. 따라서 개발자를 추가 하는 데서 생기는 기하급수적인 복잡성과 관리의 어려움이 디버깅에는 짐이 되지 않는다.
실제로 리눅스 세계에서는 디버거의 작업이 중복됨으로써 생기는 이론적인 효율 저하가 거의 문제되었던 적이 없는 것으로 보인다. “빨리, 그리고 자주 발표하는 것”' 의 효과 중 하나는 피드백되어 오는 수정사항을 빨리 전파함으로써 중복이 최소화된다는 것이다. Brooks(The Mythical Man-Month의 저자)는 “널리 사용되는 프로그램의 유지보수에 들어가는 비용은 보통 개발 시 드는 비용의 40 퍼센트나 그 이상입니다. 놀랍게도 이 비용은 사용자의 수에 큰 영향을 받습니다. 더 많은 사용자들이 더 많은 버그를 찾아냅니다.”
사용자들이 많아지면 프로그램을 시험해보는 방법이 더 늘어나기 때문에 버그를 더 많이 잡아낼 수 있다. 이 효과는 사용자들이 co-developers들일 때 더욱 커진다. 각 사람들이 버그를 찾아낼 때 조금씩 다른 개념의 집합과 분석 도구들을 사용하여 문제의 다른 각도에서 접근하기 때문이다. “Delphi effect” 는 바로 이런 편차에서 비롯되는 것으로 보인다. 또한 디버깅이라는 특정한 환경에서 이 편차는 노력의 중복을 줄여주는 경향이 있다.
따라서 더 많은 베타테스터를 가지는 것은 개발자의 관점에서 현재의 “가장 심오한” 버그의 복잡성을 줄여주지는 않을 테지만, 누군가의 도구가 문제에 딱 들어맞아 그 버그가 그 사람에게는 쉽게 잡을 수 있는 것이 될 가능성을 높여준다.
Linus도 물론 할 일이 있었다. 심각한 버그가 있을 경우에 대비해 리눅스 커널 버전은 잠재 사용자들이 최종적으로 “안정된” 버전을 사용할 수도 있고 새로운 기능을 사용하기 위해 최신의 버그가 있을 수 있는 버전을 사용할 수도 있게 번호가 붙여졌다. 이 전술은 아직까지 대부분의 리눅스 해커들이 따라 하지는 않고 있지만 아마도 따라 하게 될 것이다. 두 가지 선택이 가능하다는 사실이 양쪽 모두를 더 매력적으로 보이게 한다.