에릭 레이먼드가 쓴 〈성당과 시장〉(The Cathedral and the Bazaar)은 자유 소프트웨어 철학을 대변하는 유명한 글이다. 레이먼드는 이 글에서 리눅스 커널 개발과정과 패치메일이라는 오픈 소스 프로젝트를 개발한 경험을 들어 오픈 소스 개발 방식의 유효성을 설명한다. 1997년 5월 27일 리눅스 회의에서 처음 공개되었으며, 1999년 같은 이름의 책에 포함되어 출판되었다.
글에서 저자는 두 가지 방식의 자유 소프트웨어 개발 모델을 대조한다.
- 성당 모델: 출시 때에만 소스 코드를 공개하고 그 사이에는 제한된 개발자들만 소스 코드에 접근할 수 있다. GNU 이맥스와 GNU 컴파일러 모음가 예이다.
- 시장 모델: 소스 코드가 인터넷으로 일반에 공개된 상태로 개발된다. 레이몬드는 리눅스 커널 프로젝트의 리더인 리누스 투르발스가 이 방식을 발명해 냈다고 쓰고 있다. 그는 또한 페치메일 프로젝트에 자신이 이 모델을 적용한 이야기도 쓰고 있다.
글의 주제는 그가 리누스 법칙이라고 이름붙인 "보는 눈만 많다면, 어떤 버그라도 쉽게 잡을 수 있다"는 명제이다. 이 말은 많은 사람이 테스트하고 훑어보고 실험해 볼 수 있도록 코드가 공개되어 있으면 버그는 빨리 잡힐 것이란 뜻이다. 이에 대해 성당 모델에서는 소스 코드를 여러 명의 개발자들만 볼 수 있으므로 버그를 잡는데에 엄청난 시간과 노력이 든다고 주장했다.
이 글로 인해 GNU 이맥스와 GCC를 포함한 많은 오픈 소스와 자유 소프트웨어 프로젝트들이 시장식의 열린 개발 모델을 사용하게 되었다. 이 중 가장 유명한 것은 넷스케이프가 넷스케이프 커뮤니케이터의 소스를 공개한 것과 모질라 프로젝트를 시작한 것이다.
성당 모델은 상용 소프트웨어의 전형적인 개발 방식이다. 더욱이 상용 소프트웨어는 보통 출시 때 소스가 같이 제공되지 않는다. 그래서 "시장과 성당"이라는 구문은 종종 상용 소프트웨어와 오픈 소스 소프트웨어를 비유하는 데에 쓰인다. 그러나 원래 글에서는 자유 소프트웨어들 중에 두 종류를 비교하여 설명하고 상용 소프트웨어에 대한 언급은 없었다.
성당과 시장의 예는 소프트웨어 프로젝트에만 있는 것이 아니다. 위키백과는 시장식의 프로젝트이고, 누피디아나 브리태니커 백과사전은 성당형의 프로젝트이다.
======================================================================
IT 와 관련되서 MS, IBM 등의 거대 기업의 스타일의 반대편에 서 있는 진영중(GNU, Netscape, BSD 등등) 가장 영향력이 큰 GNU 진영의 Linux 라는 OS (운영체계) 의 개발 스타일에 대한 내용입니다.
소프트웨어를 개발하는 하나의 방법론입니다만 이를 참고로 생각해볼만한 내용이 많아서 글을 오려봅니다.
성당과 시장 본문 => 〈성당과 시장〉, 1.31.2 버전, KLDP 위키, 2001.(그누)
상당히 긴 글이라 귀차니즘에 전체를 않읽어보실 분들을 위해서 글의 내용중 핵심적인 소제목들만 나열해 보도록 하겠습니다.
- 소프트웨어, 프로그램은 민주주의, 사회주의 등 사회 체계로 치환
- 개발자, 프로그래머는 위의 사회 체계를 이끌어가는 리더로 치환
- 사용자, 베타테스터는 위의 사회 체계 및 리더를 따르는 시민으로 치환
1. 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로부터 시작된다. (Every good work of software starts by scratching a developer's personal itch)
2. 좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 (그리고 재사용해야 할 지) 안다. (Good programmers know what to write. Great ones know what to rewrite(and reuse))
3. ``가지고 있는 것을 버릴 계획을 세우라 ; 언젠가는 버리게 될 것이다 (Plan to throw one away; youu will anyhow)'' (Fred Brooks, ``The Mythical Man-Month'', Chapter 11)
4. 적절한 태도를 가지고 있으면 흥미로운 문제가 당신을 찾아갈 것이다. (If you have the right attitude, interesting problems will find you)
5. 프로그램에 흥미를 잃었다면 프로그램에 대한 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다. (When you lose interest in a program, your last duty to it is to hand it off to a competent successor)
6. 사용자들을 공동개발자로 생각하면 코드가 다른 어떤 방법보다도 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다. (Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging)
7. 일찍 발표하고 자주 발표하라. 그리고 사용자들의 소리에 귀를 기울이라. (Release early. Release often. And listen to your customers)
8. 충분히 많은 베타테스터와 공동개발자가 있으면 거의 모든 문제들은 빨리 파악될 것이고 쉽게 고치는 사람이 있게 마련이다. (Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone)
9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다. (Smart data structures and dumb code works a lot better than the other way around)
=> 여기서 자료구조는 공동체의 내부 시스템을 의미하고 코드는 그 시스템의 실행하는 행위를 말합니다.
10. 베타테스터들을 가장 중요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어준다. (If you treat your beta-testers as if the're your most valuable resource, they will respond by becoming your most valuable resource)
11. 좋은 아이디어를 생각해내는 것 다음으로 중요한 일은 사용자들이 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 더 나을 수도 있다. (The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better)
12. 종종 가장 충격적이고 혁신적인 해결책은 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못되어 있다는 것을 깨닫는 것에서 나온다. (Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong)
13. ``(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. (Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away)''
=> 제가 제일 좋아하는 문구입니다.
14. 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았던 용도에 알맞게 된다. (Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected)
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!)
=> 게이트웨이 소프트웨어란 정보나 데이터를 받아들이는 관문의 역할을 하는 소프트웨어를 의미하며 데이터 스트림이란 일련의 데이터들의 리스트입니다.
16. 언어가 튜링-컴플리트하지 않다면 구문상의 유연성이 필요하다. (When your language is nowhere near Turing-complete, syntactic sugar can be your friend)
17. 보안시스템은 그것이 보호하려고 하는 비밀만큼만 안전하다. 가짜 비밀들에 주의할 것. (A security system is only as secure as its secret. Beware of pseudo-secrets)
18. 재미있는 문제를 풀어보고 싶다면 자신에게 재미있는 문제를 찾아 나서는 것부터 시작하라. (To solve an interesting problem, start by finding a problem that is interesting to you)
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)
[이 게시물은 관리자님에 의해 2011-09-05 21:14:36 바보문예에서 이동 됨]
| 
(펌) 어제 표결이 신의한수였…