소프트웨어 공학 100 주제 시리즈의 3번째 글이다. (카테고리: 기초와 역사)

한 줄 요약

“맨먼스(man-month)” 는 사람과 개월을 서로 바꿀 수 있다고 가정하는 단위인데, 소프트웨어 작업은 나눌 수 없는 부분과 소통 비용 때문에 그 가정이 성립하지 않는다. 그래서 Brooks 는 “늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다” 고 썼다.

왜 필요한가

일정이 밀리면 가장 먼저 나오는 처방이 “사람을 더 붙이자” 다. 예산을 쓸 수 있는 관리자에게는 가장 쉬운 레버이기도 하다. 그런데 신규 인원이 합류한 첫 몇 주 동안 팀의 산출이 오히려 떨어지는 경험은 많은 개발자가 해 봤다. 기존 인원이 온보딩·리뷰·질문 응대에 시간을 쓰고, 일을 다시 나누는 동안 회의가 늘어나기 때문이다.

이 현상을 설명할 언어가 없으면 “새 사람이 아직 손이 느려서” 같은 개인 탓으로 흐르고, 같은 결정이 다음 프로젝트에서 반복된다.

핵심 개념

출처와 배경

Frederick P. Brooks, Jr. 는 IBM 에서 System/360 하드웨어 개발과 이어서 Operating System/360 소프트웨어 개발을 관리했고, 그 성공과 실패를 1975년 책 The Mythical Man-Month 로 정리했다(UNC 에 공개된 그의 약력·CV). 1995년 20주년 기념판이 나왔고, 그는 1999년 ACM 튜링상을 받았다(같은 CV). 1964년 UNC 컴퓨터과학과를 세웠으며 UNC 의 그의 페이지에 따르면 2022년 11월 17일 91세로 별세했다.

이 글의 법칙과 비유는 책 2장 “The Mythical Man-Month” 에 있다. 책은 링크할 공개 원문이 없으므로 서지 정보로 인용한다.

맨먼스가 “미신” 인 이유

Brooks 의 요지는 이렇다. 비용은 인원 × 기간에 비례하지만 진척은 그렇지 않다. 사람과 개월이 서로 교환 가능한 것은 작업이 소통 없이 완전히 나뉠 수 있을 때뿐이다. 밀 수확이나 목화 따기는 그렇지만 시스템 프로그래밍은 그렇지 않다.

작업의 성격에 따라 인원과 기간의 관계를 그려 보면 이렇다.

기간
 │╲                      (a) 완전히 나눌 수 있는 일
 │ ╲                         기간 = 일의 양 / 인원
 │  ╲___
 │      ‾‾‾‾‾‾‾‾‾‾‾‾‾‾     (b) 나눌 수 없는 일 — 사람을 늘려도 그대로
 │
 │╲       ___/            (c) 나눌 수 있지만 소통이 필요한 일
 │ ╲____/                     어느 지점부터 사람을 늘리면 오히려 늘어난다
 └──────────────────── 인원

Brooks 가 든 유명한 비유는 아이를 낳는 데 걸리는 시간이다. 몇 명을 배정하든 아홉 달은 줄지 않는다. 순서 제약이 있는 일은 나눌 수 없다.

소통 비용은 제곱으로 자란다

나눌 수 있는 일이라도 나눈 조각들이 맞물리려면 사람들이 이야기해야 한다. 모든 사람이 서로 조율해야 한다면 소통 경로의 수는

\[\frac{n(n-1)}{2}\]

이다. 3명이면 3개, 10명이면 45개, 20명이면 190개다. 인원이 2배가 되면 경로는 대략 4배가 된다.

여기에 교육 비용이 더해진다. 새 사람은 기술, 목표, 전체 전략, 작업 계획을 배워야 하고, 그것을 가르치는 사람은 기존 인원이다. 교육은 나눌 수 없는 일이라 신규 인원 수에 비례해 늘어난다.

Brooks 의 법칙

이 두 가지를 합친 결론이 그 유명한 문장이다.

Adding manpower to a late software project makes it later. (늦어진 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다.)

늦어진 프로젝트라는 조건이 중요하다. 이미 계획이 깨졌다는 것은 남은 일을 다시 나눠야 한다는 뜻이고, 재분할·교육·추가 소통이 모두 남은 기간 안에 들어간다.

작은 모형으로 확인하기

숫자를 직접 굴려 보면 직관이 생긴다. 아래 모형의 계수는 모두 설명용 가정이다.

# 남은 일 120 인-주, 현재 4명 (계수는 모두 설명용 가정)
# - 소통: 각자 주간 용량의 (동료 수 × c) 비율을 조율에 쓴다.
# - 신규 인원은 ramp 주 동안 생산성이 선형으로 오르고,
#   그동안 기존 인원이 신규 1명당 주 mentor 만큼 교육에 쓴다.
def finish_week(added, join_week, c=0.04, ramp=8, mentor=0.5,
                remaining=120.0, base=4):
    week, ages = 0, []
    while remaining > 0:
        if week == join_week:
            ages = [0] * added
        n = base + len(ages)
        eff = 1 - min(c * (n - 1), 0.9)
        out = base * eff
        for i, a in enumerate(ages):
            if a < ramp:
                out += (a / ramp) * eff - mentor
            else:
                out += eff
            ages[i] += 1
        remaining -= out
        week += 1
    return week

print("추가 인원   처음부터 투입   20주차 투입   28주차 투입")
for k in (0, 2, 4, 8):
    print(f"{k:>5}명   " + "".join(f"{finish_week(k, w):>10}주" for w in (0, 20, 28)))

실행 결과:

추가 인원   처음부터 투입   20주차 투입   28주차 투입
    0명           35주        35주        35주
    2명           29주        34주        36주
    4명           26주        34주        37주
    8명           26주        36주        39주

표에서 세 가지가 보인다.

  1. 처음부터 넣으면 일정이 줄어든다. 다만 4명에서 8명으로 늘려도 26주 그대로다. 소통 비용이 추가 인원의 몫을 잡아먹기 시작한 것이다.
  2. 20주차에 넣으면 이득이 거의 없고, 8명을 넣으면 오히려 1주 늦어진다.
  3. 28주차, 즉 남은 일이 얼마 없을 때 넣으면 몇 명을 넣든 원래보다 늦어진다. 신규 인원이 제 몫을 하기 전에 교육과 소통 비용만 치르고 끝나기 때문이다.

계수를 바꾸면 숫자는 달라진다. 이 모형이 보여 주는 것은 구조다. Brooks 의 법칙은 “사람을 늘리면 언제나 늦어진다” 가 아니라, 늦게, 나누기 어려운 일에, 학습 곡선이 긴 사람을 넣을 때의 경고다.

책의 다른 주장들

같은 책에는 이 시리즈에서 따로 다룰 주제가 여럿 있다.

장 주제 연결
3장 The Surgical Team 한 명의 핵심 설계·구현자를 여러 역할이 지원하는 팀 구성 팀 구조
4장 Aristocracy, Democracy, and System Design 개념적 무결성(conceptual integrity)이 설계의 가장 중요한 고려사항 아키텍처
5장 The Second-System Effect 두 번째 시스템에 첫 시스템에서 참았던 기능을 다 넣으려는 경향 범위 관리
11장 Plan to Throw One Away 첫 시스템은 어차피 버리게 되니 버릴 계획을 세워라 프로토타이핑

Conway 의 법칙이라는 이름도 이 책에서 붙었다(SE100 #007 에서 다룬다).

실무 적용

일정이 밀렸을 때 “사람 추가” 를 결정하기 전에 확인할 질문:

  1. 남은 일이 나눌 수 있는 일인가? 독립된 기능, 독립된 테스트 작성, 문서화처럼 경계가 명확한 일이면 효과가 있다. 핵심 모듈의 재설계라면 거의 없다.
  2. 신규 인원의 학습 곡선은 얼마인가? 도메인 지식, 코드베이스, 배포 절차를 아는 사람인가?
  3. 누가 가르치는가? 가장 바쁜 핵심 인원이 교육을 맡게 되면, 병목이 더 좁아진다.
  4. 대안은 무엇인가? 범위를 줄이기, 마일스톤을 다시 협상하기, 비핵심 업무를 빼내 핵심 인원을 보호하기가 종종 더 빠르다.
  5. 소통 구조를 줄일 수 있는가? 새 인원을 기존 팀에 섞지 말고, 경계가 명확한 별도 과제를 맡긴다. 소통 경로를 늘리지 않는 배치다.

추정 자체를 다룰 때는 애자일과 스크럼의 속도(velocity) 개념도 같은 함정을 가진다. 팀 인원이 바뀌면 과거 속도는 그대로 쓸 수 없다.

흔한 오해와 함정

  • “Brooks 의 법칙 = 절대 사람을 늘리지 마라.” 조건이 붙은 경험칙이다. 초기에, 나눌 수 있는 일에, 숙련된 사람을 넣으면 효과가 있을 수 있다. 모형에서 보듯 결과는 계수에 따라 달라진다.
  • “소통 비용은 회의만이다.” 코드 리뷰, 인터페이스 합의, 머지 충돌, 같은 파일을 동시에 고치는 조율도 모두 소통 비용이다.
  • “맨먼스로 추정하면 안 된다.” 비용(예산) 계산에는 여전히 유용한 단위다. 문제는 그 숫자로 기간을 거꾸로 나누는 것이다.
  • “n(n-1)/2 는 실제 소통량이다.” 모든 사람이 모든 사람과 조율한다는 최악의 경우다. 실제로는 팀 구조와 인터페이스 설계로 경로를 줄인다. 그것이 모듈화와 팀 경계 설계가 중요한 이유다.

확인 문제

  1. 맨먼스라는 단위가 성립하려면 작업이 어떤 조건을 만족해야 하는가?
  2. 팀이 5명에서 10명으로 늘면, 모든 사람이 서로 조율하는 경우 소통 경로는 몇 개에서 몇 개로 바뀌는가?
  3. 신규 인원 투입이 단기적으로 산출을 떨어뜨리는 두 가지 원인은?
  4. Brooks 의 법칙이 “늦어진” 프로젝트를 조건으로 다는 이유는?
  5. 일정이 밀렸을 때 인력 추가 외의 대안 두 가지를 들라.

풀이

  1. 작업이 서로 소통할 필요 없이 완전히 나뉠 수 있어야 한다.
  2. $5\cdot4/2 = 10$개에서 $10\cdot9/2 = 45$개로 늘어난다.
  3. 기존 인원이 교육에 시간을 쓰는 것, 그리고 인원이 늘면서 조율해야 할 소통 경로가 늘어나는 것. (재분할 작업 자체도 비용이다.)
  4. 계획이 이미 깨진 상태에서는 남은 일의 재분할, 신규 인원 교육, 늘어난 소통이 모두 짧아진 남은 기간 안에서 비용으로 발생하기 때문이다.
  5. 범위 축소, 마일스톤 재협상, 핵심 인원의 비핵심 업무 제거, 경계가 명확한 별도 과제로 신규 인원 배치 등.

더 읽을거리 (References)