[TMMM] #8. 예고 홈런

문연수·2022년 10월 27일

TMMM The Mythical Man-Month 맨먼스 미신

TMMM

목록 보기

8/17

1. 네이너스(Nanus)와 파(Farr)의 연구 결과

시스템 프로그래밍 작업에 드는 시간 추정에 있어 두 가지 사항을 유념해야 한다:

코딩 부분만을 추정한 다음에 비율을 역산해서 전체 작업량을 추정해선 안된다. 코딩은 전체의 6분의 1 정도에 불과하고, 그에 대한 추정이나 비율이 잘못된 경우 터무니 없는 결과가 나올 수 있다.
독립된 소규모 프로그램에 대한 데이터를 프로그래밍 시스템 제품에 적용해서는 안 된다. 100야드(91.44미터) 단거리 기록으로 외삽을 한다면 1마일(약 1.60킬로미터)을 3분 내에 뛸 수 있다는 결론이 나온다.

이 수치들은 작업에 드는 노력이 프로그램 크기의 거듭 제곱에 비례하여 늘어남 을 시사한다.

시스템 디벨롭먼트 코퍼레이션(System Development Corporation, SDC)의 네이너스와 파에 의한 연구 결과에 의하면 거듭 제곱의 지수는 1.5 이다:

투입공수 = (상수) \times(명령문\;개수)^{1.5}

2. 포트먼(Portman)의 데이터

찰스 포트먼의 데이터에 따르면 개발 팀이 일정을 절반 정도밖에 지키지 못한다는 것을 발견했다. 각 작업은 애초 추정한 것보다 대략 두 배의 시간이 소요되었다.

개발자들에게 하루 시간을 어떻게 썼는지에 대한 상세한 기록을 요청했고 그 결과, 개발 팀들이 실제 프로그래밍과 디버깅에 쓸 수 있었던 시간은 전체의 50% 밖에 되지 않았다.

요컨데, 원래의 추정은 기술적인 업무를 처리할 시간에 대해 비현실적인 가정을 깔고 있었던 것이다.

3. 아론(Aron)의 데이터

그는 아홉 개의 시스템을 프로그래머간의 상호 작용 정도에 따라 나누었으며, 그 생산성에 대해 다음과 같은 결과에 도달했다:

상호 작용이 거의 없는 경우: 맨이어 당 1만 명령어
약간의 상호 작용이 있는 경우: 맨이어당 5000 명령어
상호 작용이 많은 경우: 맨이어당 1500 명령어

4. 하의 데이터

-	단위 프로그램 개수	프로그래머 수	소요 기간 (년)	투입 맨이어	프로그램 크기(워드)	맨이어당 워드 수
운영	50	83	4	101	52,000	515
유지 관리	36	60	4	81	51,000	630
컴파일러	13	9	2 $\frac{1}{4}$	71	38,000	2230
번역기 (데이터 어셈블러)	15	13	2 $\frac{1}{4}$	11	25,000	2270

생산성도 마찬가지로 두 부류로 나뉜다. 제어 프로그램의 경우 맨이어당 600워드, 언어 번역기는 2200워드였다. 네 프로그램 모두 크기는 비슷하지만 작업 그룹 크기, 시간 길이, 모듈 수에서 차이가 난다.

ESS 데이터에 의하면 프로그래밍, 디버깅 예측치와 실제 진척도, 그리고 프로그램 크기에 대한 월별 추정치의 경우 다음과 같다:

프로그램 크기에 대한 월별 추정치는 최초 예상에 비해 아주 소폭 상승한다.
예상 프로그래밍 진척도는 선형적이만 실제 프로그래밍 진척도는 시간이 지날수록 점점 더디게 증가한다. (제곱근과 같이)
예상 디버깅 진척도는 점진적으로 증가하다 종래에 수렴하리라 생각했으나 실제 디버깅 진척도는 선형적이며 더 오래 걸렸다.

5. OS/360 의 데이터

아론, 하, OS/360 데이터 모두, 작업 자체의 복잡도 및 난이도와 관련된 생산성의 차이가 현저함을 확인해준다. 복잡도 추정이라는 난감한 작업에 대한 내 조언은, 컴파일러는 통상적인 일괄 처리 응용 프로그램보다 세 배, 운영 체제는 컴파일러보다 세 배 복잡하다는 것이다.

6. 코르바토(Corbato) 의 데이터

하와 OS/360 의 데이터는 둘 다 어셈블리 언어(???) 로 프로그래밍한 경우였다. 시스템 프로그래밍에 더 고수준 언어가 사용되었을 때의 생산성 자료는 MIT 의 프로젝트 맥 소속인 코르바토에 의하면, 크기가 100만 ~ 200만 워드 사이인 멀틱스 시스템의 평균 생산성이 맨이어당 디버깅된 PL/I 코드 (이딴게... 고수준?) 단위로 1200 라인이라고 한다.

이를 통해 알 수 있는 중요한 결론은 이하와 같다:

생산성은 기본적인 문장 단위로 볼 때 일정 수준으로 유지된다.
프로그래밍의 생산성은 적절한 고급 언어가 사용될 경우 다섯 배 까지도 늘어날 수 있다.

솔직히 어셈블리로 작성된 시스템이라고 생각을 전혀 못했다가 마지막 코르바토의 데이터에서 깜짝 놀랐다. 현대에도 이와 같은 이유로 다층의 추상화 과정이 이뤄지고 있으며 최신 트렌드가 확장성있는 방식으로 빠르게 (대형 설계 자체를 피하는 방식으로) 개발하고 배포한다는 점을 생각해보면 그의 혜안에 놀라지 않을 수 없다.