브룩스의 법칙: 지연된 프로젝트의 함정과 팀 전략
출시가 코앞인데 ‘인력을 더 뽑으면 되겠지’라며 인원부터 늘리는 순간, 당신의 팀은 브룩스의 법칙의 절망을 마주하게 된다. 스타트업에서 프로젝트 마감 시한이 임박했는데 개발이 늦어지는 상황을 한 번 떠올려보자. 많은 리더들은 직관적으로 “그럼 개발자를 더 투입하면 되지 않을까?”라는 해결책을 생각한다.
일정 지연을 만회하기 위해 인력을 충원하는 것은 언뜻 합리적으로 들린다. 그러나 소프트웨어 공학 역사에서 내려온 한 격언은 이런 대응이 오히려 독이 될 수 있다고 경고한다. 바로 1975년 프레더릭 브룩스가 그의 저서 The Mythical Man-Month에서 제시한 브룩스의 법칙입니다. 이 글에서는 브룩스의 법칙이 왜 스타트업 경영에 중요한 통찰을 제공하는지 살펴보고, 실제 사례와 함께 스타트업 조직이 프로젝트 일정 및 팀 구성 전략에 이 법칙을 어떻게 적용할 수 있는지 알아보겠습니다.
“늦어진 프로젝트에 사람을 더하면 더 늦어진다”
브룩스의 법칙(Brooks’s Law)이란 “늦어진 소프트웨어 프로젝트에 인력을 추가 투입하면 프로젝트 완성이 더욱 늦어진다”는 원칙입니다. 이는 단순한 경구가 아니라 대형 프로젝트 현장에서 얻은 교훈입니다. 브룩스는 1960년대 IBM의 OS/360 운영체제 개발을 이끌면서 이 사실을 뼈저리게 깨달았습니다. 프로젝트가 지연되자 IBM은 여유 인력을 계속 투입했지만, 인력이 늘어날수록 오히려 일정 지연이 심화되었습니다. 결국 브룩스는 “개발자를 새로 투입할 때마다 프로젝트 완성이 더 멀어졌다”는 깨달음을 얻었고, 이를 바탕으로 브룩스의 법칙을 정립했습니다.
그렇다면 왜 이런 현상이 벌어질까? 브룩스 본인은 이 법칙을 “터무니없이 단순화한 표현”이라고 겸손하게 말했지만, 그 이면에는 소프트웨어 개발의 복잡성을 나타내는 세 가지 핵심 요인이 있다.
의사소통 복잡도 증가: 팀 규모가 커질수록 커뮤니케이션 경로의 수가 기하급수적으로 늘어납니다. 사람 n명이 같이 일하면 의사소통 채널 수는 n(n-1)/2로 증가한다. 예를 들어 5명이던 팀에 새 인력이 합류해 10명이 되면, 소통 채널은 10명 기준으로 45개로 폭증한다. 결국 회의와 보고에 소요되는 시간이 크게 늘어나 실제 개발에 투입할 수 있는 시간이 줄어들게 된다. 제프 베조스가 “커뮤니케이션이 많다는 것은 조직 기능 장애(Dysfunction)의 징후”라며 아마존의 팀을 두 자릿수 인원으로 키우지 않는 것도 같은 이유이다.
신규 인력의 교육 및 초기 부담(Ramp-up 시간): 새로 투입된 개발자가 프로젝트에 생산적으로 기여하기까지는 상당한 러닝 커브를 올라야 한다. 기존 팀원들의 시간 일부가 신규 인력에게 프로젝트 맥락과 코드를 교육하는 데 쓰이므로, 그동안은 오히려 기존 생산성이 저하된다. 숙련된 개발자라도 새로운 코드베이스를 이해하고 도메인 지식을 습득하는 데에는 시간이 필요하며, 그 사이에 버그를 만들어내는 등 역효과를 낳을 수도 있다.
작업의 분할 한계: 모든 개발 작업을 사람 수대로 쪼갤 수 있는 것은 아니다. 일부 작업은 병렬화가 불가능한 순차 의존을 갖고 있어, 여러 사람이 동시에 달려들어도 빨라지지 않는다. 브룩스는 이를 비유하여 “여성 아홉 명이 한 달 동안 임신한다고 해서 한 달 만에 아기가 태어나지는 않는다”고 설명했다. 하나의 기능을 개발하고 디버깅하고 테스트하는 과정은 순서를 따르며, 일정 부분은 한 사람이 끝내야 다음 단계로 넘어갈 수 있기에 인력 추가로 단축되지 않는 시간이 존재한다. 즉, 프로젝트에는 아무리 인원을 투입해도 압축되지 않는 최소 개발 기간이 있다는 뜻이다.
요컨대 브룩스의 법칙은 소프트웨어 개발의 비선형적 특성을 강조한다. 사람과 시간이 단순 1:1로 교환 가능한 맨먼스(M/M, man-month)의 신화가 현실에서 성립하지 않으며, 팀 규모가 커질수록 오히려 비효율이 증가함을 경계하는 원칙인 것이다. 특히 스타트업처럼 민첩성과 효율이 생명인 환경에서는 이 법칙을 무시했다가 치르는 대가가 클 수 있다.
스타트업이 흔히 빠지는 오해 - 사람만 늘리면 만사 OK?
스타트업 환경에서는 한정된 시간과 자원으로 최대 성과를 내야 한다는 압박이 항상 존재한다. 투자자 데모 데이, 중요한 고객과의 약속 등 피할 수 없는 마감일이 정해진 상황에서 개발이 지연되면, 경영진은 종종 인력 충원이나 외주 투입을 만병통치약처럼 여긴다. 겉보기에는 더 많은 사람이 동시에 일하면 “평행 처리”로 작업이 빨라질 것처럼 느껴지기 때문이다. 이를 일종의 “헤드카운트 = 생산력” 함정이라고 부를 수 있다.
이러한 오해 뒤에는 잘못된 전제가 깔려 있다. 즉, 소프트웨어 개발 작업을 마치 공장에서 부품 찍어내듯이 무한히 나눠 투입할 수 있다고 보는 관점이다. 브룩스가 지적했듯이 전통적인 맨먼스 산정 방식은 사람과 시간을 서로 대체 가능하다고 가정하지만, 실제로 이는 거의 성립하지 않는다. 예를 들어 두 배 인력을 투입하면 기간이 절반으로 단축될 것이라 기대하지만, 현실에서는 앞서 설명한 의사소통 비용 증가와 교육 기간, 작업의 상호의존성 때문에 오히려 투입 대비 산출이 떨어지는 경우가 많다.
스타트업에서는 이 함정을 더욱 경계해야 한다. 왜냐하면 스타트업 팀은 대기업보다 구성원 각자의 역할 비중이 크고 전문 지식이 응축되어 있는 경우가 많기 때문이다. 핵심 개발자 한 명이 프로젝트 전반의 구조를 머리에 담고 있는 상황에서, 뒤늦게 투입된 사람이 그 수준에 도달하려면 상당한 시간이 걸린다. 또한 스타트업은 조직 구조가 유연한 대신 프로세스나 문서화가 정형화되어 있지 않을 수 있어, 새 인력은 혼란에 빠지고 기존 인력은 본업과 멘토링을 병행하느라 전체 생산성이 저하되는 악순환에 빠지기 쉽다.
실제 사례로 본 실패의 교훈
이러한 “사람만 더 투입하면 되겠지” 사고가 어떻게 실패로 이어지는지, 유명 IT 업계 사례들을 통해 살펴볼 수 있다.
IBM OS/360 프로젝트 (1960년대) : 앞서 언급했듯이, OS/360 개발은 당초 예상보다 훨씬 복잡해지면서 일정이 계속 지연되었다. IBM 경영진은 프로젝트에 개발자를 추가 배치했지만 문제는 개선되지 않고 더 악화되었고, 결국 계획보다 수 년 지연되어 간신히 마무리되었다. 이 경험은 브룩스의 법칙 탄생의 직접적 배경이 되었고, 대규모 인력 투입이 항상 답이 아님을 일깨운 최초 사례로 남았다.
마이크로소프트 Windows Vista 개발 (2000년대) : 마이크로소프트는 차세대 운영체제 Vista를 개발하면서 수천 명 규모의 대형 팀을 운영했다. 프로젝트 중반에는 보안 이슈 해결을 위해 일부 개발자를 차출하고 다른 기능을 늘리면서 조직과 코드베이스가 비대화되었고, 결국 2004년에 한차례 개발을 초기화해야 할 정도로 일정이 엉켰다. Vista 팀은 사진 한 장에 담기 어려울 만큼 방대했는데, 이러한 거대 조직은 의사결정 지연과 커뮤니케이션 혼선을 가져와 출시가 여러 차례 연기되었다. 결국 Vista는 계획보다 수 년 늦게 출시되었고 시장의 혹평을 받았다. 이 사례는 자원이 풍부한 대기업에서도 팀 관리 실패로 일정 지연을 초래할 수 있음을 보여준다.
미 정부 Healthcare.gov 웹사이트 (2013년) : 오바마 행정부의 보험 가입 사이트인 Healthcare.gov는 초기 개발에 무려 55개 이상의 서로 다른 계약업체가 참여한 복잡한 프로젝트였다. 거대한 외주 팀들이 합심하여 짧은 기간에 결과물을 내놓는 것은 애당초 무리가 있었고, 2013년 론칭 당시 사이트는 잦은 오류와 과부하로 사실상 실패작이라는 평가를 받았다. 당황한 정부는 문제 해결을 위해 테크 지원군(tech surge)이라 불리는 추가 인력 투입을 결정했지만, 정작 업계 전문가들은 이에 회의적이었다. 새로운 개발자들이 복잡한 시스템을 이해하는 데 걸리는 시간과 기존 인력의 교육 부담을 감안하면, 오히려 안 건드니만 못할 수 있다는 것이었다. 결국 정부는 초반 대규모 투입 대신 몇몇 소수 정예의 자원봉사 기술자 팀을 급파하여 문제를 하나씩 해결해 나갔고, 서비스는 몇 달에 걸쳐 안정을 찾았다. 이 사건은 많은 인력이 항상 효율적 해결을 담보하지는 않음을 적나라하게 보여준 사례이다.
위 사례들에서 공통적으로 드러나는 것은 단순히 “사람 숫자”를 늘리는 것이 지연 문제를 해결하기보다, 오히려 새로운 문제를 양산했다는 점이다. 물론 모든 경우에 추가 인력이 독이 되는 것은 아니다. 브룩스의 법칙도 전제가 “이미 늦어진 프로젝트”일 때임을 기억해야 한다. 초기 기획 단계처럼 일이 산탄적으로 벌어지기 전에 인력을 투입하거나, 테스트/문서 작업 등 기존 작업과 독립적인 영역에 사람을 보충하는 경우에는 효과를 볼 수 있다. 하지만 프로젝트 후반부의 일정 압박을 인력으로 만회하려는 시도는 대부분 실패로 끝난다는 것이 역사적 교훈이다.
브룩스의 법칙을 극복하는 스타트업 리더십 전략
그렇다면 스타트업 리더들은 브룩스의 법칙을 어떻게 활용해야 할까? 프로젝트 관리와 팀 운영에서 이 법칙을 인식하고 적용하기 위한 몇 가지 전략이 있다. 목표는 지연을 예방하고, 부득이 지연되었을 때 현명하게 대응하는 데 있다.
소규모 집중 팀 구성:
팀은 가능하면 작고 기민하게 유지하는 것이 좋다. 아마존의 “두 개의 피자 팀” 원칙이 유명한데, 제프 베조스는 한 팀이 두 판의 피자로 배불릴 정도(약 5~10명 이하)로 작아야 효율적이라고 강조했다. 작은 팀은 구성원 간 상호 이해가 높고 의사소통 경로가 단순해 커뮤니케이션 오버헤드가 줄어든다. 연구에서도 팀 인원이 한 자릿수일 때 생산성과 만족도가 최고조에 이른다는 결과가 있다 (Hackman의 연구: “두 자릿수가 되는 순간 협업 효율 급감”, Mueller의 연구: “팀원이 9명을 넘어서면 성과가 급격히 저하”). 스타트업 리더는 팀을 불필요하게 비대하게 키우기보다는 작은 단위의 팀들이 병렬로 움직이게 조직하는 것이 바람직하다. 실제로 넷플릭스나 아마존 AWS도 마이크로서비스 아키텍처를 도입해 작은 팀들이 독립적으로 개발한 뒤 최종 통합하는 방식으로 속도를 높였습니다.
현실적인 일정 수립과 버퍼 확보:
낙관적인 기획은 스타트업의 활력소이지만, 일정만큼은 보수적으로 잡을 필요가 있습니다. 모든 개발 단계를 순조롭게 밟을 확률은 낮기에, 예상치 못한 버퍼 기간을 일정에 포함시켜야 합니다. 초기 일정이 비현실적으로 촉박하면 중반 이후 돌이킬 수 없이 늦어지며, 이때 인력을 투입해도 이미 수렁에 빠진 뒤일 가능성이 큽니다. 리더는 팀과 함께 최악의 시나리오까지 고려한 일정을 잡고, 진행 상황을 투명하게 모니터링하여 조금이라도 지연 조짐이 보이면 초기에 문제를 표면화해야 합니다. 일정 압박이 심해질수록 오판을 할 확률이 높아지므로, 버퍼와 위험관리 문화를 갖추는 것이 장기적으로 속도를 높이는 길이다.
기능 모듈화와 병렬화 전략:
프로젝트를 설계할 때부터 작업을 최대한 독립적인 모듈로 분할해 두면, 나중에 여러 팀원이 동시에 일을 해도 충돌이 줄어듭니다. 좋은 설계 분할은 팀 간 의존성을 낮춰 커뮤니케이션 부담 없이도 각자 작업을 진행하게 해주며, 추가 인력이 투입되더라도 국지적인 영역을 맡겨 전체 속도를 높일 수 있다. 예를 들어 서비스를 마이크로서비스처럼 나누거나, 명확한 컴포넌트 경계를 정의해 두면, 필요시 한 모듈에 별도 인력을 투입해도 다른 부분과의 조율 비용이 크지 않다. 단, 분할을 잘못하면 오히려 경계간 조율 문제가 생길 수 있으므로 초기 아키텍처 설계 때 신중해야 한다.
신규 인력의 점진적 온보딩:
프로젝트가 진행되는 도중 불가피하게 인력을 충원해야 한다면, 한꺼번에 많은 사람을 투입하지 말고 단계적으로 늘리는 것이 좋다. 예를 들어 두 명을 충원한 뒤 이들이 완전히 적응하여 생산성을 내기 시작하면 그때 추가로 또 두 명을 투입하는 식으로 러닝 커브를 분산시키는 것이다. 또한 신입 인력이 바로 핵심 개발에 투입되지 않도록, 온보딩 전담 프로그램이나 멘토링 제도를 운영하면 효과적이다. 구글과 메타(옛 페이스북) 등 빅테크들은 신규 엔지니어가 바로 실무팀에 배치되지 않고 몇 주간 공통 교육과 작은 과제를 수행하는 “부트캠프” 과정을 거치도록 한다. 메타의 사례를 보면, 모든 신입 엔지니어가 약 6주간 전체 코드베이스를 학습하고 버그 수정 등을 경험한 후 자신이 기여할 팀을 결정하도록 되어 있다. 이러한 온보딩 체계는 기존 팀의 부담을 줄이고, 신입도 충분한 배경지식을 갖춘 뒤 합류하게 해줌으로써 브룩스의 법칙이 말하는 초기 생산성 저하를 완화해준다.
커뮤니케이션 구조 개선:
조직이 커질수록 모든 사람이 모든 것을 알아야 할 필요는 없다. 팀 내 역할 분담을 명확히 하고, 진행 상황을 공유하는 체계를 세분화하여 필요한 사람끼리만 효율적으로 소통하도록 유도해야 한다. 이를 위해 일일 스탠드업 미팅이나 칸반 보드 등 애자일 도구를 활용해 짧고 빈번한 정보 교환을 하고, 결정이 필요한 사안은 한 명의 결정권자가 책임지게 하는 것이 좋다. 또한 문서화, 코드 리뷰, 자동화된 CI/CD 파이프라인 등을 통해 사전에 맥락을 공유해 두면 구두 보고나 회의를 남발하지 않아도 된다.
스타트업에서는 조직 문화적으로 “필요 이상으로 회의하지 않고 각자 알아서 움직이는” 분위기를 조성하는 것이 중요하다. 베조스가 팀 간 불필요한 소통을 줄이라고 조언한 것도 같은 맥락이다. 궁극적으로는 협업 도구와 문화를 정비하여 인원 증가에 따른 커뮤니케이션 비용 증가 곡선을 완만하게 만들어야 한다.
이과 같은 전략들은 브룩스의 법칙을 정면으로 극복하기 위한 실천 방안들이다. 핵심은 “개발자는 곧 속도”라는 환상에서 벗어나, 인력 1명의 추가로 인해 생기는 보이지 않는 비용들을 관리하는 데 집중하는 것이다.
이제 글을 마무리하면서, 스타트업 리더들이 팀 운영과 마감 문화를 재설계할 때 참고할 수 있는 행동 가이드를 정리해보겠다.
마감 문화와 팀 운영 재설계를 위한 행동 가이드
최소한의 인원으로 팀을 구성하라:
팀 규모를 가능하면 한 자릿수로 유지하고 필요할 때 새로운 작은 팀을 만드는 것을 고려한다. “두 개의 피자 룰”처럼 팀이 비대해지면 빠르게 둘로 쪼개는 결단도 필요하다. 작은 팀이 민첩하고 책임감 있게 움직일 수 있도록 권한을 부여하라.
일정에는 여유 버퍼를 포함하라:
프로젝트 계획 시 낙관적 시나리오와 비관적 시나리오의 중간쯤에 일정을 잡고, 버퍼 기간을 명시적으로 확보한다. 팀원들에게 문제가 예상될 때 조기에 공유하는 문화를 장려하고, 일정 재조정을 두려워하지 마라. 무리한 데드라인을 맹신하기보다 유연한 조정이 결국 속도를 높인다.
작업을 모듈화하고 병렬로 진행하라:
제품 아키텍처를 설계할 때 기능 모듈 간 결합도를 낮추고 독립성을 높인다. 이렇게 하면 각 모듈을 서로 다른 팀/개발자가 병렬로 개발할 수 있어 전체 일정을 단축하고, 후반부에 특정 모듈에 인원을 추가 투입해야 할 때도 다른 부분에 미치는 영향을 최소화할 수 있다.
인력 충원은 신중하게, 그리고 미리 하라:
프로젝트 후반의 위기 대응용으로 갑작스럽게 사람을 늘리는 것은 최후의 수단으로 남겨두자. 불가피하게 늘려야 한다면 가장 먼저 일정 조정이나 요구사항 범위 축소를 검토하고, 추가 인력은 프로젝트 가능한 한 이른 시점에 투입하여 러닝 커브를 흡수하도록 한다. 또한 새로운 팀원이 합류하면 기존 팀원과 페어 프로그래밍이나 코드 리뷰 파트너를 맺어 빠르게 배울 수 있게 지원하라.
표준 온보딩 프로세스를 구축하라:
신입 개발자가 들어올 때 일관된 교육과 환경 세팅 절차를 마련해 둔다. 예컨대 첫 일주일은 코드를 세팅하고 주요 시스템에 대한 문서를 읽게 하며, 작은 버그 수정부터 시작하도록 가이드하자. 사수-부사수 제도나 멘토를 지정해 질문을 빨리 해결하고 지식을 전파하도록 한다. 이렇게 하면 새로운 사람이 투입되어도 팀 생산성이 덜 흔들린다.
“사람 1명의 추가 비용”을 항상 인식하라:
마지막으로, 리더 자신과 팀원 모두가 브룩스의 법칙을 숙지하도록 하자. 일정이 늦어질 때 섣불리 인원부터 늘리는 결정을 경계하고, 대신 왜 문제가 발생했는지 원인부터 찾는 접근한다. 조직 문화적으로도 야근이나 인력투입 “당근과 채찍”식 해결보다, 문제의 구조적 해결을 우선하는 분위기를 만들자. 브룩스의 통찰을 조직의 DNA로 삼는다면, 스타트업은 적은 인원으로도 기한 내 높은 성과를 내는 스마트한 팀으로 거듭날 수 있을 것이다.
참고 문헌
[1] Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1975.
[2] John Naughton, “Why big IT projects always go wrong,” The Guardian, Apr 20, 2013. [링크]
[3] Wikipedia, “Brooks’s law,” (accessed 2025). [링크]
[4] Ben Fathi, “What Really Happened with Vista: An Insider’s Retrospective,” Medium, Oct 27, 2020. [링크]
[5] Rusty Foster, “Healthcare.gov: It Could Be Worse,” The New Yorker, Oct 2013. [링크]
[6] NPR (Rusty Foster interview), “Despite Glitches, HealthCare.gov Could’ve Been Worse,” Oct 22, 2013. [링크]
[7] AWS Executive Insights, “Amazon’s Two Pizza Teams,” AWS, 2021. [링크]
[8] Alex Ponomarev, “The Power of Two Pizzas: Why Jeff Bezos Limits Teams to 5–7,” Medium, Oct 27, 2023. [링크]
[9] Andrew Bosworth, “Facebook Engineering Bootcamp,” Facebook Engineering, Nov 19, 2009. [링크]
[10] Wikipedia, “Development of Windows Vista,” (accessed 2025). [링크]
