브룩스의 법칙과 지연된 소프트웨어 프로젝트의 인력 확장
브룩스의 법칙이 지연된 소프트웨어 프로젝트에서 인력 추가를 위험하게 만드는 이유와 팀 확장 전략을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
일정이 밀린 뒤의 인력 충원이 만드는 문제
브룩스의 법칙은 지연된 소프트웨어 프로젝트에 인력을 추가하면 일정이 더 늦어질 수 있다는 명제다. 프레드릭 브룩스(Frederick P. Brooks Jr.)가 1975년 저서 『맨먼스 미신(The Mythical Man-Month)』에서 제시한 이 관점은, 개발 인력이 단순히 더해지는 생산 단위가 아니라는 사실을 짚는다.
브룩스는 IBM에서 System/360 컴퓨터와 OS/360 운영 체제 개발을 지휘한 경험을 바탕으로 이 원칙을 도출했다. 일정이 어긋난 대형 프로젝트에 인력을 추가하는 대응이 문제를 해소하기보다 악화시키는 모습을 직접 관찰한 결과다.
팀이 커질수록 늘어나는 협업 비용
팀원 수가 n명일 때 잠재적인 의사소통 채널 수는 n(n-1)/2다. 4명 팀에는 6개의 채널이 있지만, 8명으로 늘어나면 28개가 된다. 12명 팀에서는 66개까지 증가한다. 프로젝트 후반에 새 인력이 합류하면, 이미 형성된 의사결정과 협업 경로에 이 복잡성이 더해진다.
모든 개발 작업을 같은 방식으로 나눌 수 있는 것도 아니다. 핵심 아키텍처 설계나 중요 알고리즘 개발처럼 본질적으로 병렬화하기 어려운 작업은 여러 사람에게 쪼개 배정한다고 해서 완료 시점이 앞당겨지지 않는다. 브룩스가 든 “9명의 여성이 모여도 1개월 만에 아이를 낳을 수 없다”는 비유가 이를 설명한다.
새 개발자가 합류할 때는 코드베이스, 아키텍처, 비즈니스 규칙을 익히는 시간이 필요하다. 기존 팀 역시 교육과 지원에 시간을 써야 하므로, 이미 지연된 프로젝트에서는 양쪽의 생산성 부담이 동시에 발생한다.
인력 추가가 일정 지연으로 이어진 사례
한 대형 은행의 핵심 뱅킹 시스템 교체 프로젝트는 6개월 지연된 뒤 개발팀을 20명에서 35명으로 확대했다. 이후 기존 개발자 50%가 새 팀원 교육에 시간을 할애했고, 코드 충돌과 통합 문제의 빈도는 3배 증가했다. 추가 인력을 투입한 지 3개월 후 예상 일정은 오히려 9개월 더 지연됐다. 프로젝트는 결국 추가된 15명 가운데 10명을 철수시키고 범위를 축소하는 방식으로 수습했다.
핀테크 스타트업의 제품 출시 지연도 비슷한 양상을 보였다. 출시일을 맞추기 위해 개발 인력을 5명에서 12명으로 늘렸지만, 새 개발자들은 복잡한 결제 시스템 비즈니스 로직을 이해하는 데 예상보다 2배 긴 시간이 필요했다. 아키텍처 이해 부족으로 설계 오류가 발생했고, 기존 코드베이스 수정 과정에서 생긴 버그 때문에 QA 주기가 반복됐다. 제품 출시는 예정일보다 4개월 늦어졌다.
팀 확장을 준비하는 방식
인력은 일정이 위급해진 뒤에 투입하기보다 프로젝트 초기에 필요한 규모와 기술 세트를 정해 계획적으로 조정해야 한다. 핵심 기술 보유자의 이탈 위험에 대비한 지식 공유 체계도 함께 마련해야 한다.
아키텍처는 독립적으로 개발할 수 있는 컴포넌트 단위로 나누는 편이 좋다. 마이크로서비스 아키텍처 등을 활용해 팀 간 의존성을 줄이고, API와 인터페이스를 명확히 정의하면 통합 문제를 앞당겨 다룰 수 있다.
온보딩 비용도 미리 설계해야 한다. 체계적인 문서화와 코드 주석, 새 팀원을 위한 표준화된 온보딩 자료 및 교육 프로그램이 필요하다. 페어 프로그래밍(Pair Programming)이나 멘토링은 지식 전달을 효율화하는 수단이 될 수 있다.
인력 충원 대신 프로젝트 범위를 조정해 MVP(Minimum Viable Product) 접근을 택하거나, 현실적인 새 일정을 세워 이해관계자의 기대치를 조정하는 선택지도 있다. 도구 개선, 프로세스 최적화, 기술적 부채 해소로 기존 팀의 생산성을 높이는 방법도 함께 검토할 수 있다.
애자일, 원격 협업, 자동화 환경에서의 해석
스크럼 팀의 이상적 규모로 언급되는 7±2명, 그리고 스프린트 중간에 팀 구성을 바꾸지 않는 원칙은 브룩스의 법칙과 연결된다. 팀의 속도(Velocity)를 측정하면 인력 변동이 전달 능력에 미치는 영향을 객관적으로 평가할 수 있다.
원격 환경은 의사소통 채널을 디지털화해 일부 오버헤드를 줄일 수 있다. 반면 문서화와 명확한 커뮤니케이션의 필요성은 더 커지며, 시간대 차이는 추가 지연 요인이 될 수 있다.
CI/CD 파이프라인과 자동화된 테스트는 새 팀원의 진입 장벽을 낮출 수 있다. 인프라스트럭처 자동화(IaC)는 환경 설정과 배포 지식의 전달 부담을 줄이는 데 도움이 된다. 다만 이런 도구와 프로세스에도 학습 곡선이 있다는 점은 별도로 고려해야 한다.
브룩스의 법칙은 인력 추가를 무조건 피하라는 규칙이 아니다. 적절한 시기에 필요한 규모와 기술을 갖춘 팀을 만들고, 협업·문서화·지식 공유 구조를 먼저 갖추라는 프로젝트 운영 원칙에 가깝다.