[TMMM] #2 맨먼스 미신

문연수·2022년 10월 14일

TMMM The Mythical Man-Month 맨먼스 미신

TMMM

목록 보기

2/17

소프트웨어 프로젝트가 파국으로 치닫는 과정

1. 낙관주의

시스템 프로그래밍 일정 관리의 바탕을 이루는 잘못된 가정은 다음과 같다:

모든 작업이 예정된 시간 내에 완료될 것이다.

인간이 무언가를 만들 때는, 그 생각에 불완전함이나 모순이 있더라도 실제로 만들기 시작한 후에야 그것이 명확해진다. 따라서 이론가들에게는 글로 쓰거나 실험하는 등의 실제 해보기 가 필수적인 지침이 된다.

컴퓨터 프로그래밍에서 사용되는 재료 (프로그래밍 언어와 도구들) 는 다루기가 무척이나 쉽다. 프로그래머는 순전히 생각만으로 여러 가지 개념과 그것을 표현할 아주 유연한 방법을 만들어 낸다. 재료가 유연하기 때문에 구현에 별다른 어려움이 있을 것라고 생각지는 않으며, 낙관주의는 이렇게 우리 사이에 만연하게 된다.

그러나 우리 아이디어 자체에 흠 이 있기에 버그가 생겨나며, 우리의 낙관주의는 이렇게 정당성을 잃는다.

2. 맨먼스 (Man-Month)

맨먼스 (Man-Month) 란... 추정 및 일정 관리에서 투입된 노력을 셈할 때 쓰는 단위로 사람 당 달수를 뜻한다. 핵심은 다음과 같다:

프로젝트 비용은 사람 수와 달수의 곱 (맨먼스) 을 따르지만, 작업 진척도는 그렇지 않다.

- 맨먼스가 통하지 않는 이유

사람과 일정은 교환이 가능한 유일한 경우는 각자가 맡은 업무가 다른 업무로부터 완벽하게 독립적인 경우 (밀 수확, 목화 따기 등) 에만 해당된다. ( $M = \frac{1}{n}$ , 인원 ( $n$ , 사람 수) 증가하면 소요 기간( $M$ , 개월) 도 급격하게 줄어듬)

작업의 성격 상 순서가 있어서 나누기 어렵다면 (CPU 의 파이프라인을 떠올려보자) , 거기에 어떤 노력을 더 쏟아 붓더라도 일정에는 아무런 영향을 미치지 못한다. ( $M = X$ , 인원에 관계없이 항상 동일한 상수시간( $X$ )가 소요됨)

분할은 가능하지만 나뉜 하위 작업들을 처리하는 데 커뮤니케이션이 필요하다면, 거기에 들어가는 노력 또한 전체 작업에 포함되어야 한다. ( $M = \frac{1}{n} + X$ , $X$ 는 커뮤니케이션 비용)

- 커뮤니케이션 비용

커뮤니케이션으로 추가되는 부담은 훈련과 의사소통의 두 부분으로 나뉜다:

훈련: 모든 작업자는 기술적인 내용, 작업 목표, 전반적인 전략, 업무 계획 등에 대해 훈련을 받아야 하며 이러한 훈련은 분할할 수가 없는 작업이므로 그 부담은 추가로 투입되는 사람 수에 비례해서 증가한다.
의사소통: 각 파트가 모든 파트와 개별적으로 조정을 해야 한다면, 커뮤니케이션 부담은 $\frac{n(n-1)}{2}$ 배가 된다.

여러 사람이 모여서 회의를 통해 문제를 해결해야 한다면 작업을 나눠서 얻는 이점을 상쇄할 수도 있고 이는 위 그래프와 같다.

참고로 그래프는 다음과 같이 그렸다: $f\left(x\right)=\sqrt{\left(\sqrt{x}-1\right)\left(x^{2}-2\right)+\ 1}$

소프트웨어를 만든다는 것은 본래 조직적인 활동, 즉 복잡한 상호연관성을 가진 활동이기 때문에 어설프게 인원을 더 투입하는 것은 일정을 단축시키기는 커녕 더 늘어지게 만든다.

3. 시스템 테스트

계획 수립: $\frac{1}{3}$
코딩: $\frac{1}{6}$
구성 요소 테스트와 초기 시스템 테스트: $\frac{1}{4}$
모든 구성 요소가 준비된 후의 시스템 테스트: $\frac{1}{4}$

위 방식은 일반적인 일정 수립과 비교해서 다음과 같은 중요한 차이점이 있다:

계획 수립에 더 많은 시간이 배정되어 있다. 하지만 이렇게 해도 상세하고 탄탄한 명세를 만들어 내기엔 다소 빠듯하며, 최신 기술에 대한 연구나 조사 활동까지 포함하기에는 충분치 않다.
전체 일정 절반을 완성된 코드의 디버깅에 할당한 것은 통상적인 경우를 많이 벗어난 것이다.
추정하기가 쉬운 부분, 즉 코딩에는 전체 일정의 6분의 1만 배정되어 있다.

초기에 일정을 수립할 때 시스템 테스트에 충분한 시간을 할애 하는 것은 대단히 중요하다.

4. 소심한 추정

희망 사항에서 비롯된 빈약한 예감 대신 추정의 기초를 견고하게 할 필요가 있다:

생산성 수치, 버그 발생률, 추정 원칙 등을 공표하고 또 공유한다.
추정의 기초가 더 견고해지는 그때까지 관리자들은 당당하게 스스로의 추정치를 방어해야 한다.

5. 일정 붕괴의 악순환

프로젝트에 소요되는 기간은 순서대로 처리해야 하는 내부 요소에 좌우되며, 필요한 최대 인원수는 독립된 하위 작업의 개수의 좌우된다. 따라서 더 적은 수의 사람 과 더 긴 기간 에 기초한 일정을 수립할 수 있다 (유일한 위험은 제품이 시대에 처지게 되는 것이다).

그러나 더 많은 사람과 더 많은 사람과 더 짧은 기간으로는 실행 가능한 일정을 만들어 내지 못한다.