개요

Brooks's law : "adding human resources to a late software project makes it later"

브룩스의 법칙 : "늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다"

프레드 브룩스(Frederick P. Brooks Jr.)가 자신의 책 [[Mythical-Man-Month]] 2장 '맨먼스 미신'에서 제시한 법칙이다.

맨먼스 미신 내용 요약

소프트웨어 프로젝트가 망가지는 주요 원인은 시간이 부족한 탓이다.

  • 시간이 부족한 원인은 다음과 같다.
    • 추정을 할 때 투입 공수와 작업 진척도를 혼동한다.
    • 일정 진척도가 제대로 모니터링되지 않는 것도 문제.
    • 일정이 어긋났을 때 인력을 추가로 투입한다.

너무 긍정적으로 일정을 짠다.

  • 작업이 한 가지 뿐이라면 낙관주의적으로 일정을 산출해도 된다.
  • 그러나 대형 프로그래밍 프로젝트는 수많은 작업으로 이루어진다.
    • 각각의 모든 작업이 모두 예정대로 진행될 확률은 매우 낮다.

맨먼스(Man-Month) 단위를 사용해 일정을 추정하는 것은 잘못된 사고방식이다.

  • 맨몬스는 프로젝트 비용의 관점에서만 의미가 있는 단위이다.
  • 맨몬스는 사람과 일정이 서로 교환 가능하다는 인식이 깔려 있다.
    • 사람과 일정이 서로 교환 가능한 경우는 다음과 같다.
      • 순서를 고려하지 않고 여러 사람에게 나눠줄 수 있는 일.
      • 작업자들 간에 의사소통이 필요없는 일.
      • 즉, 프로그래밍에서는 이 관점이 해당되지 않는다.
  • 순서가 정해져 있는 작업이라면, 작업자를 더 쏟아부어도 일정을 앞당기는 것은 불가능하다.
    • 예: 임산부가 9명이라고 해서 1달 만에 아기가 태어나는 것은 아니다.
    • 소프트웨어 개발 작업은 각 단계별로 순차적으로 진행된다. (개발 - 디버깅 - 테스트…)
    • 커뮤니케이션도 전체 일정에 포함시켜야 한다.

프레드 브룩스의 성공적인 일정 수립 방법

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

\({1 \over 4} + {1 \over 4} = {1 \over 2}\) 이니까, 테스트가 절반이나 된다.

일반적인 방법으로 일정을 관리했던 프로젝트들을 살펴보다가 발견한 사실은, 일정의 절반을 테스트에 배정한 경우는 거의 없었지만 대부분 나중에는 그만큼의 시간을 결국 테스트에 썼다는 것이다. 그런 프로젝트들이라 해도 상당수가 시스템 테스트 전까지는 원래 일정대로 진행되고 있었다.

특히 시스템 테스트에 충분한 시간을 배정하지 않는 것은 아주 참담한 결과를 초래한다. 일정 지연은 프로젝트 말미에 발생하기 때문에, 납품일이 코앞에 닥칠 때까지 어느 누구 하나 일정에 문제가 있다는 것을 알아차리지 못한다.

추정은 소심하게 하고, 관리자들은 고객들의 일정 축소 요구로부터 스스로의 일정 추정을 지켜야 한다.

일정 붕괴의 악순환

\(n\) 명이 수행중인 프로젝트 막바지에 새로 \(m\) 명의 인력이 투입되었다.

  • 실력이 아무리 뛰어나도, 기존 멤버로부터 프로젝트에 대한 훈련을 받아야 한다.
  • 규모가 커지므로, 조직 구성이나 업무 분배에 있어서 본질적인 차이가 발생한다.
  • 원래 \(n\) 으로 분할했던 작업을 \(n + m\) 으로 나눠야 한다.
    • 이미 진행된 작업 중 일부가 날아간다.
    • 시스템 테스트 시간도 더 미뤄지고 늘어난다.

지금까지의 내용을 극도로 단순화하면, 다음과 같은 브룩스의 법칙을 제시할 수 있을 것이다.
"늦어진 소프트웨어 프로젝트에 인력을 추가로 투입하면 더 늦어지게 된다."
이렇게 해서 우리는 맨먼스에 관련된 미신을 걷어낼 수 있다. 프로젝트에 소요되는 기간은 순서대로 처리해야 하는 내부 요소에 좌우되며, 필요한 최대 인원수는 독립된 하위 작업의 개수에 좌우된다.