이 글은 프레더릭 브룩스 2세의 맨먼스 미신의 요약이다.
"숱한 노력들이 빠져나오려 몸부림치는 진흙 구덩이이면서도 동시에 모든 기쁨과 고뇌가 함께하는 창조적인 행위, 바로 이것이 프로그램 작업이다."
- 프로그램
프로그램은 자체로 완결적이다.
생산성 추측 대상으로 사용한다.
- 프로그래밍 제품
누구나 실행/테스트/수리/확장할 수 있는 프로그램이다.
입력 범위와 형식은 용납 가능한 선에서 최대한 일반화되어야 한다.
많은 테스트를 거쳐 신뢰성을 입증해야한다.
누구나 실행/테스트/수리/확장 가능하게끔 문서화가 이루어져야 한다.
즉, 유지관리가 될 수 있어야햔다.
- 프로그래밍 시스템
상호작용하는 프로그램들의 집합이다.
모든 입출력의 구문과 의미가 정확히 정의된 인터페이스에 들어맞도록 프로그램을 작성해야한다.
컴퓨팅 자원을 사전에 규정된 한도 안에서만 사용하도록 설계해야 한다.
무결성을 검사해야 한다.
- 프로그래밍 시스템 제품
누구나 실행/테스트/수리/확장할 수 있는, 상호작용하는 프로그램들의 집합이다.
마음 속 깊은 곳에 있는 창작에 대한 열망을 충족시켜주기에 프로그램 작성은 즐겁다.
1. 무엇을 만든다는 순수한 즐거움
2. 다른 사람에게 쓸모 있는 뭔가를 만드는 데서 오는 즐거움
3. 서로 맞물려 돌아가는 퍼즐 같은 복잡한 객체를 멋지게 만들어내는/
절묘한 사이클로 작동하는/
개발 시작 당시 정했던 원칙의 결과를 지켜보는 즐거움
4. 항상 새로운 뭔가를 배운다는 즐거움
5. 다루기 쉬운 매체를 갖고 작업한다는 즐거움
1. 작업은 완벽하게 해야 한다.
2. 목표를 설정하고, 자원을 공급하고, 정보를 제공하는 주체가 내가 아니라 다른 사람이다.
3. 야심찬 개념을 섦계하는 것은 재미있지만, 자잘한 디버깅은 단순노동에 지나지 않는다.
4. 오류 수정 작업은 작업 대비 시간 효율이 선형 또는 그 아래이다.
5. 끝끝내 만든 작업물이 다른 이의 작업물에게 완벽하게 하위호환일 수 있다.
소프트웨어 프로젝트가 실패하는 가장 흔한 이유는 일정 관리 실패이며, 아래는 일정을 맞추지 못하는 주요 원인이다.
1. 견적 기술이 아직 발달하지 못했다.
2. 견적 방식에서 노동력과 작업 진행관계를 혼동한다.
3. 견적 수치에 대한 확신이 없기 때문에, 소프트웨어 관리자들은 업무 진행 원칙을 지키지 못한다.
4. 일정에 따른 진행 상황을 제대로 감독하지 못한다.
5. 일정이 공전되고 있다는 것을 깨달을 때, 인력을 많이 투입하는 해결방식이다.
시스템 프로그래밍 일정 계획의 바탕에 깔리는 첫 번째 잘못으로 모든 임무가 주어진 시간 안에 꼭 완수될 것이라는 가정이다.
대형 프로그래밍 프로젝트는 여러 임무가 유기적으로 연결되어 있으므로 모두 완벽하게 진행될 가능성은 매우 적다.
시스템 프로그래밍 일정 계획의 바탕에 깔리는 두 번째 잘못으로 인력과 기간은 상호 교환할 수 있다는 믿음이다. 이를 표한하는 단위로 맨먼스 (Man-month)가 사용된다.
커뮤니케이션으로 인한 부담: 훈련, 상호 커뮤니케이션
훈련 ∝ 작업자의 수
상호 커뮤니케이션 ∝ (작업자의 수)^2
커뮤니케이션이 필요한 분할 가능한 임무는 사람이 많을 수록 필요한 시간이 줄어들지만 (많은 사람이 들어갈수록 효율이 떨어진다)
상호관계가 복잡한 임무는 사람이 많아도 필요한 시간이 늘어날 수 있다.
디버깅과 시스템 테스트는 낙관주의 때문에 버그의 수를 실제보다 적게 예측하는 경향이 있어 일정 계획에 어려움을 준다.
저자는 다음과 같은 타임라인이 효과가 있다고 한다.
1/3: 계획
1/6: 코딩 작업
1/4: 디버깅과 초기 시스템 테스트
1/4: 시스템 테스트, 모든 컴포넌트 입수
시스템 테스트는 후반에 이루어지니, 여기서 예상치 못한 문제가 일어나면 프로젝트 막바지에 제품 납기에 문제 있음을 알리게 되므로 시스템 테스트에는 넉넉한 시간을 할애해야한다.
고객이 프로그래밍 제품에 독촉을 한다고 해서 완벽한 제품이 빠르게 납기될 수 없다. 완벽하지 못한 제품을 기한 안에 납기하거나, 당겨진 납기일을 지키지 않는 선택지 밖에 없다.
이런 일이 일어나지 않도록 버그 발생 수치, 견적 규칙 등 생산성 수치를 개발하여 일정 계획에 근거를 제공해야한다.
일정이 늦어진 소프트웨어 프로젝트에 인력을 추가하는 것은 일정을 더욱 늦추는 결과를 낳을 뿐이다.
이것은 맨먼스의 미신을 깨뜨리는 발언이다.
일정을 정할때에는 사람 숫자를 되도록 줄이고 일정을 최대한 늘려 잡아야한다.
"상식적인 일정 안에 대형 시스템을 구축해야 하는 경우는 어떻게 할 것인가?"라는 질문을 살펴보자.
유능한 프로그래머와 어설픈 프로그래머는 생산성 차이가 매우 크다.
그렇기에 소수의 유능한 프로그래머로 짜인 팀이 다수의 어설픈 프로그래머로 짜인 팀보다 훨씬 능률이 좋지만,
대형 프로젝트는 일정 수준의 생산량을 필요로 하기에 소수의 유능한 프로그래머팀과 다수의 어설픈 프로그래머팀 모두 프로젝트의 기한을 맞추기 힘들다.
두 팀을 조화시키는 것이 중요한 사안이다.
수술팀과 같이 대형 작업의 각 부분을 팀으로 나누어 처리해야한다.
아래는 수술팀의 각 역할군이다.
기능과 성능 명세 정의, 프로그램 설계, 코딩, 테스트, 문서작업이 모두 가능한 프로그래머 장이다.
외과의사와 같이 모든 작업이 가능하지만 경험이 부족하며, 외과의사와 설계에 대해 토론하며 설계 오류등의 참사를 방지한다.
외과의사 대신 돈과 인력, 공간, 기계, 조직등 행정적인 업무를 처리하는 사람이다.
외과의사의 문서 원고를 받아 첨삭하고 관리한다.
행정관과 편집자가 두는 비서이다. 프로젝트 통신문과 제품 외적 파일을 처리한다.
프로그래밍-제품 라이브러리에 있는 팀의 모든 기술적 기록의 관리 책임을 지는 사람이다.
팀이 필요로 하는 특수 도구들의 적절함을 보장하고 특수 도구들이 구축과 관리 그리고 업그레이드를 책임진다.
시스템 테스트 케이스를 만들고 디버깅을 위한 테스트 데이터를 만들어낸다.
프로그래밍 언어를 깊게 사용할 줄 알아 복잡한 문제를 효과적으로 풀어내는 역할이다.
수술팀은 전통적 방식으로 구성된 프로그래밍 팀(모든 사람이 평등)과 다르다.
수술팀은 전통방식의 팀에 대해 두가지 이 점이 있다.
1. 외과의사가 부기장이 코드 전체를 알고 있기 때문에 작업의 개념성 일관성을 확보할 수 있다.
2. 외과의사가 구성원의 구현 차이를 조정하기에 구성원간 이해관계가 충돌하지 않는다.
규모 확대는 수술팀을 여러 개를 꾸리면 이룰 수 있는데, 이는 외과의사들을 조율하는 것이 선행되야 한다.
설계와 구현의 차이가 명확히 있어야하며, 전체 시스템을 설계만 하는 설계자가 필요하다.
본질적 작업: 소프트웨어의 개념적 구조를 만드는 것
부차적 작업: 추상적 구조를 프로그래밍 언어로 나타내고 제한된 시간/공간적 복잡도 내에 이를 기계어로 구현하는 것
소프트웨어 생산의 발전은 부차적 작업을 줄이므로써 이루어졌으나, 한계에 도달했다.
그래서 본질적 작업을 줄이는 방법을 위해 다음을 제시한다.
1. 구매 가능하면 사서쓰고 직접 구현을 피할 것
2. 소프트웨어 요구사항을 수립하기 위해 빠른 프로토타입 만들기를 계획적으로 반복할 것
3. 시스템을 실행/사용/시험하여 새로운 기능을 추가하고 성장시킬 것
4. 신새대 개념 디자이너들을 찾아낼 것
늑대 인간이 무서운 설화인 이유는 가장 친근한 것이 갑자기 무섭게 변하기 때문이다.
늑대 인간을 손 쉽게 잡기 위해서는 은총알이 필요하다.
소프트웨어 공학도 마찬가지다.
일정 미스, 예싼 초과, 제품의 오류등 단순한 것이 괴물로 돌변한다.
소프트웨어 개발 가격을 낯추기 위한 은총알이 있기를 바란다.
그런건 없지만, 그래도 기술혁신이 이를 미약하게나마 이루어주고 있다.
소프트웨어 시스템에서 도저히 줄일 수 없는 속성들에는 복잡성, 순응성, 변경 가능성, 비가시성이 있다.
1. 복잡성
요소들은 다른 요소들과 비선형적으로 작용하기에, 요소를 추가하는 것은 전체 복잡성을 빠르게 키운다. 이런 복잡성의 비선형적 증가가 소프트웨어 제품 개발에 생긱는 문제들의 주요 원인이다.
2. 순응성
사람마다 만드는 기능 인터페이스는 각기 다른데, 이에 보편된 원리가 없으나 순응하고 개발해야하기에 복잡성이 발생한다.
3. 변경 가능성
소프트웨어는 하드웨어에 비해 변경하기 수월하다는 생각 때문에 기능에 변경이 이루어진다. 이런 기능 변경을 하지 않으면 기술 발전에 따라가지 못하므로 기능 변경에 대한 압박이 생긴다.
4. 비가시성
소프트웨어의 구조는 건물의 설계도처럼 가시적으로 나타내기 힘들다. 각 기능의 규칙을 나타내는 그래프가 복잡히 얽혀있기 때문이다.
1. 고수준 언어
고수준 언어는 소프트웨어의 생산성, 신뢰성, 단순서을 가장 크게 향상시켰다.
소프트웨어의 부차적인 복잡성을 많이 제거했기 때문이다.
2. 시분할
개발한 코드를 빠르게 컴파일 하는 것은 소프트웨어 개발에 대한 생각을 휘발을 어느정도 막아준다.
3. 통합 프로그래밍 환경
유닉스와 인터리스프와 같은 통합 프로그래밍 환경은 둘이상의 프로그램들을 함께 사용하는 것을 가능하게 해줬다.
1. 에이다와 기타 고수준 언어의 발전
고수준 언어는 부차적인 복잡성을 제거해주지만, 전부 제거하지 않으며 작은 문제들을 남겨놓을 것이다. 이런 작은 문제들도 해결하는 고수준 언어를 사용하는 것은 더 적은 부가 이익을 가져올 것이기에 이는 은 총알이 아니다.
2. 객체 지향 프로그래밍
객체 지향 프로그래밍은 추상적 데이터 타입과 계층적 타입을 허용하므로써 한 수준 더 높은 부차적 복잡성을 제거하였다.
3. 인공 지능
인공지능이 스프트웨어 생산성과 품질에서 대대적인 발전을 가져올 수 있으나, 소프트웨어 구축의 어려운 점은 뭘 말해야하는지 결정하는 것이지, 그것을 말하는 것이 이니다. AI는 말하는 것만 할 수 있다.
4. 전문가 시스템
전문가 시스템으로 인터페이스 규칙 제시, 테스트 전략 조언, 버그 타입의 주기를 기억, 최적화 힌트 제시등을 수행할 수 있다. 이는 경험 많은 프로그래머의 경험과 지혜를 경험 적은 프로그래머의 서비스에 담아내는 역할을 해줄 수 있다.
5. '자동' 프로그래밍
자동프로그래밍은 주어진 명세서만 가지고 문제를 해결하는 프로그램을 만들어 내는것 이다. 그러나 이는 고수준 언어의 완곡한 표현일 뿐이고, 명세를 해결할 수단이라고 봐야한다. 그러나 명세를 일반적인 소프트웨어 수준에서 해결하는 것은 매우 어렵다.
6. 그래픽 프로그래밍
VLSI 침 설계 같이 설계의 그래픽컬 표현은 설계에 매우 큰 도움을 주었으나, 소프트웨어 설계는 그래피컬하게 표현해도 그 의미를 기하학적으로 담아내기 힘들다.
7. 프로그램 검증
프로그램 검증은 강력한 디버깅 도구이지만, 결국 프로그램이 주어진 명세의 요구조건을 충족하는 것을 확증하는 것까지만 할 수 있다. 프로그램 구축의 핵심은 명세를 디버깅하는 하는 것이다.
8. 환경과 도구
발전된 환경과 도구 사용은 생산성과 신뢰성에서 결실이 있겠지만, 이는 한계가 있다.
9. 워크스테이션
빠른 컴퓨터는 작업시간의 대부분을 프로그래머의 일과 생각하는 시간으로 대부분 채울 수 있다. 그러나 이것이 소프트웨어 개발의 마법 같은 발전은 아닐 것이다.
1. 구매 대 구축
제일 좋은 구축 방법은 구축하지 않는 것이다. 소프트웨어 패키지로 구축하고자 하는 것이 있으면 이를 구매하여 대체하는 것이 더욱 낫다.
2. 요구사항 다듬기와 빠른 시제품 작업
고객은 사실 자신이 우너하는 것이 무엇인지 잘 모른다.
따라서 명세를 고객과 스프트웨어 개발자가 반복하며 정립하고, 이를 만족하는 시제품을 계속 만들어야한다.
3. 점증적 개발 - 소프트웨어를 구축이 아니라 성장시켜라
소프트웨어 시스템은 날이 갈수록 복합적으로 변했기 때문에 한번의 명세롤 통해 개발될 수 없다.
단계적으로 소프트웨어를 개발하여 차근차근 기능을 추가해야한다. 처음에는 유용한 기능 없이 시스템이 돌아가기만 해도 된다.
4. 대단한 설계사들
훌륭한 설계사는 좋은 개념 설계를 할 수 있으므로 근본적인 문제를 해결한다.
다음은 훌륭한 설계사를 키우는 방법이다.
- 최고 설계자를 빨리 찾는 시스템이 있어야한다.
- 설계자 후보의 개발을 담당하는 이력 스승을 지정하여 이력 파일을 잘 관리한다.
- 설계 후보 개발을 위한 이력 개발 게획을 고안하여 유지 및 관리한다.
- 성장하는 설계자들이 상호작용하고 서로 자극할 수 있는 기회를 제공한다.
좋은 기능들이지만 서로 독립적이고 조화되지 못한 아이디어들을 담고 있는 시스템보다는 여러가지 기능이나 갱신된 내용은 빠졌더라도 통일된 설계 아이디어를 반영한 시스템이 훨씬 좋다.
주어진 기능수준에 대해서 가장 좋은 시스템은 가장 단순하고 직설적으로 명세가능하다.
이러한 단순성과 직설성은 개념적 무결성에서 나오며, 사용의 쉬움은 설계와 개념의 무결성으로부터 나온다.
설계와 구현은 명확히 구별되어야 한다. 이런 방식은 설계자들은 귀족, 구현자들은 평민이 된 구조라고 오해를 일으킬 수 있다.
민주주의적으로 구현자들이 설계에 대해 좋은 아이디어가 있다면 적용시킬 수 있으나, 이는 개념적 무결성을 해칠 수 있다.
전체 시스템 설계에는 통제를 받지만, 구현의 설계에는 통제를 받지 않기에 이는 꼭 귀족주의라고 볼 수 없다.
오히려 시스템의 설계 규제는 구현 설계의 창의성을 증진시킨다.
아키텍처, 구현, 실현은 병렬적으로 이루질 수 있다. 따라서 구현자들은 기다리지 않아도 된다.
구현은 명확히 정의된 비용과 성능목표만 있다면 실행될 수 있고, 설계와 실혐은 그동안 물리적인 구성을 준비하거나 문서화를 진행한다.
개념적 무결성을 유지하는 동시에 시스템 개발이 분업화되면 작업 시간이 길 것 같지만, 오히려 짧다.