💡 핵심 인사이트
브룩스의 법칙은 **"일정이 지연되고 있는 소프트웨어 개발 프로젝트에 새로운 인력을 추가로 투입하면, 프로젝트는 오히려 더 지연된다"**는 소프트웨어 공학의 가장 유명한 격언입니다.
인력을 늘리면 속도가 빨라질 것이라는 제조업의 상식이 '지식 집약적 노동'인 IT 산업에서는 절대 통하지 않음을 경고합니다.

Ⅰ. 브룩스의 법칙 개요

IBM의 전설적인 운영체제 OS/360 개발을 총괄했던 **프레더릭 브룩스(Fred Brooks)**가 자신의 저서 『맨먼스 미신 (The Mythical Man-Month)』에서 제창한 법칙입니다.

경영진들은 프로젝트 마감일이 다가오는데 진척이 느리면 "개발자 5명을 더 투입해!"라는 결정을 내립니다. 사람 인(Man) × 달 월(Month) = 총 노동력이라는 산술적 착각(맨먼스 미신) 때문입니다. 하지만 현실은 배가 산으로 가며 일정이 더욱 파탄 납니다.

Ⅱ. 왜 인력을 추가하면 더 늦어지는가? (원인 분석)

소프트웨어 개발은 벽돌을 나르는 단순 노동(Partitionable task)이 아니라, 극도로 복잡한 개념을 공유하고 연결하는 작업이기 때문입니다.

1. 램프업 타임 (Ramp-up Time, 교육 시간)

새로운 개발자가 투입되면 바로 코드를 짤 수 있는 것이 아닙니다. 기존 시스템의 아키텍처를 이해하고, 팀의 코딩 컨벤션을 숙지하며, 수만 줄의 코드를 읽어보는 데 몇 주에서 몇 달이 걸립니다. 이때 기존의 에이스 개발자들이 신입을 교육하느라 본인의 업무를 멈춰야 하므로 전체 팀의 생산성은 일시적으로 급락합니다.

2. 의사소통 오버헤드의 기하급수적 증가 (Communication Overhead)

사람이 늘어날수록 서로 코드를 맞추고 회의해야 하는 통신 경로(경우의 수)가 기하급수적으로 늘어납니다.

• 통신 경로 계산 공식: $N(N - 1) / 2$ ($N$은 인원 수)
• 5명일 때: $5 \times 4 / 2$ = 10개의 소통 채널
• 10명으로 늘리면: $10 \times 9 / 2$ = 45개의 소통 채널 (인원은 2배 늘었는데 소통의 복잡도는 4.5배 폭증)
• 서로의 코드가 충돌(Conflict)하는 횟수가 늘어나 이를 해결하는 데 코딩보다 더 많은 시간을 쏟게 됩니다.

3. 작업의 분할 불가능성

어떤 작업은 물리적으로 더 이상 쪼갤 수 없습니다. "임산부 9명이 모인다고 아기를 1달 만에 낳을 수는 없다"는 브룩스의 비유처럼, 순차적으로 진행되어야 하는 디버깅이나 설계 작업은 사람을 밀어 넣는다고 병렬 처리되지 않습니다.

Ⅲ. 실무적 대안

일정이 지연될 때 경영진과 PM이 취해야 할 올바른 조치는 사람을 때려 넣는 것이 아닙니다.

1. 기능의 축소 (Scope Reduction): 마감일을 맞추기 위해 덜 중요한 기능을 다음 릴리스(버전 2.0)로 과감히 미룹니다.
2. 일정의 재조정: 고객과 협상하여 마감일을 현실적으로 연장합니다.
3. 최소 인원 정예화: 오히려 팀을 작게 쪼개고 권한을 위임하여 의사소통 비용을 최소화합니다. (아마존의 '피자 두 판의 규칙')

📢 섹션 요약 비유: 브룩스의 법칙은 **"불이 난 좁은 주방에 요리사 10명을 더 밀어 넣는 것"**과 같습니다. 요리가 빨리 나오기는커녕 서로 동선이 엉키고 국자만 부딪히다가 결국 냄비를 엎어버리게 됩니다.