아래 글은 Eric Raymond의 ‘성당과 시장’ 중 일부를 메모해 둔 것이다. 인상깊은 구절만 발췌했다.
(원문: http://kldp.org/root/cathedral-bazaar/cathedral-bazaar.html)
9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대의 경우보다 훨씬 잘 작동한다. (Smart data structures and dumb code works a lot better than the other way around)
브룩스의 책 9 장(Chapter 9) 에 이렇게 쓰여있다. “내게 [코드]를 보여주고 [자료구조]를 숨긴다면 나는 계속 어리둥절할 것이다. 자료구조를 보여준다면 코드는 볼 필요도 없이 뻔한 것이다.’’ 사실 브룩스는 “흐름도’’ 와 “테이블’’ 이라고 이야기했다. 하지만 30년간 변해온 용어들과 문화를 고려한다면 거의 똑같은 말이라고 할 수 있다.
“Man-Month 의 신화’’ 에서 프레드 브룩스는 프로그래머의 시간이 다른 것으로 대체될 수 없다고 진술했다. 지연되고 있는 소프트웨어 프로젝트에 개발자를 더 투입하는 것은 완료 시기를 더 늦출 뿐이다. 그는 프로젝트에서 복잡성과 의사소통에 드는 비용이 개발자의 제곱에 비례하는 반면 일이 되어가는 것은 직선적으로만 증가한다고 주장했다. 이 주장은 그때부터 “브룩스의 법칙’’ 으로 알려졌고 널리 자명한 이치로 간주되었다. 하지만 브룩스의 법칙이 전부라면 리눅스는 불가능했을 것이다.
나중에 제랄드 와인버그의 고전인 “컴퓨터 프로그래밍의 심리학 (The Psychology Of Computer Programming)’’ 에서 브룩스의 말에 대한 중요한 수정사항이 제시되었다는 것을 알 수 있다. “자아를 내세우지 않는 프로그래밍(egoless programming)’’ 에 대한 논의에서 와인버그는 개발자들이 자신의 코드에 대해서 텃세를 부리지 않고 다른 사람들로 하여금 버그를 찾고 개선가능성을 찾아내도록 격려하는 곳에서는 다른 어느 곳에서보다 극적으로 빠른 개선이 일어난다고 이야기했다.
와인버그는 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)
