1. 개념적 일관성
만드는데 여러 세기가 걸리는 것도 아닌 프로그래밍 시스템에서는 대부분 대성당보다 훨씬 심각한 개념적 불일치 가 발견된다. 왜 Why?
설계 책임자들이 대를 이어가는 경우보다도 여러 명이 설계 작업을 나눈 경우에 이런 문제가 발생한다.
좋기는 하지만 연관성 없고 조율도 안된 기능을 많이 넣기 보다는, 이례적인 일부 기능이나 개선 사항을 빼더라도 일련의 설계 사상 (개념적 일관성) 을 고수하는 편이 더 낫다.
2. 개념적 일관성의 획득
사용의 용이성 은, 시스템을 공부하고 외우며 메뉴얼을 찾는 시간보다, 기능을 명세할 때 얻는 시간적 이득이 클 때에만 향상되었다고 할 수 있다.
- OS/360 과 PDP-10 의 시분할 시스템 이 반쪽짜리(?) 인 이유
OS/360은 가장 많은 기능 을 탑재했기에 자기 작품이 최고라고 생각함.PDP-10 의 시분할 시스템은 그 단순성 과 개념의 단출함 때문에 자기들 것을 최고라 여김.
그러나, 판단의 기준을 사용의 용이성 으로 삼는 즉시, OS/360 은 기능 대비 시스템을 익히는 시간적 측면에서, PDP-10 의 시분할 시스템 은 시스템을 이해하는 시간 대비 기능적 측면에서 부족한 시스템이 된다.
일정 수준의 기능을 제공한다는 가정 하에서라면, 최대한 단순하고 명확하게 사용할 수 있는 시스템 이 최상이다. 이러한 단순성 과 명확성 은 개념적 일관성 속에서 완성되어 진다.
3. 귀족 정치와 민주주의
일정 압박에 의해 여러 사람이 참여해야 하는 시스템 구축에 있어 어떻게 극소수의 사람만으로 실계를 이룰 수 있는가.
- 1. 아키텍처와 구현의 분할
아키텍처: 사용자 인터페이스의 완전하고 상세한 명세. (e.g. 컴파일러에게 언어 메뉴얼, 컴퓨터에게 프로그래밍 메뉴얼)구현: 아키텍처의 실질적인 동작 방식 (e.g. 모든 시계는동일한 명세를 가지기 때문에 누구나 읽을 수 있으나, 시계의 동작 방식은 구현자에 따라 달라질 수 있다.)
-2. 귀족 정치 vs. 민주주의
* Q1. 명세 개발을 소수에게 맡기는 것보다는 민주적 절차에 따라 모든 팀으로부터 아이디어를 모으는 것이 더 나은 제품을 만드는 길이 아닌가?
아키텍트들만이 설계에 대해 좋은 아이디어를 낸다는 주장이 아니다. 참신한 생각이 구현자나 사용자에게서 비롯되는 경우 (작가가 2장에서 언급한 직접 해보기 가 바로 그것이 아닐까 싶다.)
그러나, 아무리 출중한 기능이나 아이디어라 해도 시스템의 기본 개념에 들어맞지 않는다면 배제하는 것이 상책이다.
* Q2. 아키텍트들은 새로운 귀족 계급이자 지적인 엘리트로서, 가엾고 우둔한 구현자들에게 해야 할 일을 알려주는 존재는 아닌가?
"예" 이면서, "아니요" 이다.
-
"예": 아키텍트는 소수여야만 하며 그들이 빚어낸 결과물은 구현자들의 것보다 더 오래 지속되어야 하기 때문이다. 시스템이 개념적 일관성을 가져야 한다면, 누군가가 그 개념을 통제해야 한다.
-
"아니요": 외부적인 명세를 기술하는 것이 구현 방안을 설계하는 것보다 더 창조적이지는 않다는 점 때문이다. 사용의 용이함이 아키텍트에게 달려 있는 것처럼 제품의 가격 대 성능비는 오롯이 구현자의 손에 달려 있다.
* Q3. 창조적인인 일은 모두 이런 엘리트의 몫으로 돌아가고 구현자들은 기계 부속품으로 돌아가는 것이 아닌가?
외부로부터 아키텍처가 주어진다는 사실이 구현 담당 그룹의 창조성을 저해하는 것이 아니라 더 높인다고 생각한다. 구현자들은 그 즉시 문제 안에서 누구도 다루지 않았던 부분에 초점을 맞출 것이며 거기에서 독창성이 솟아나기 시작한다. (이러한 대목은 UNIX 의 역사에서도 확인할 수 있다.)
4. 구현자들은 기다리는 동안 무엇을 하는가?
소규모 아키텍처 팀이 컴퓨터 또는 프로그래밍 시스템에 대한 외부 명세를 모두 작성한다고 했을 때, 구현 담당자들은 세 가지로 반론을 제기한다:
- 명세에 너무 많은 기능이 포함될 것이며 비용에 대한 현실적인 고려도 미비할 것이다.
- 창조적인 즐거움은 모두 아키텍트 몫이 되고 구현자들의 독창성은 배제될 것이다.
- 아키텍처 팀이라는 좁다란 깔대기를 지나서 명세가 모습을 드러낼 때까지, 많은 구현자들은 하는 일 없이 앉아 있어야 할 것이다.
첫 번째 반론은 다음 장에서, 두 번째는 이전 파트에서 언급했듯이 오해에 지나지 않는다. 마지막 반론의 경우 타이망과 단계적 실행의 문제이다.
명세가 완성되기 전까지는 구현자들을 배정하지 말라는 것을 의미하며, 실제 개발 단계에서는
아키텍처,구현,제품화의 세 단계가 거의 동시적으로 진행된다.
-> 여기에 관련된 내용은EETB에서도 자세하게 확인할 수 있다.
글쓴이의 주장은 다른 여러 책에서도 찾아볼 수 있는 내용이기에 크게 새롭거나 하진 않았다. 그들 역시 The Mythical Man-Month 를 읽고 그러한 프로젝트 진행 방식을 고수하게 된 것인지는 불분명하나, 위 책의 영향이 전혀 없지는 않았으리라 생각한다.
출처
[책] 맨먼스 미신: 소프트웨어 공학에 관한 에세이 (프레더릭 브룩스 지음, 강중빈 옮김)
