브룩스의 법칙 2026년 정리, 개발팀 증원 전에 일정표를 다시 그리는 법

브룩스의 법칙은 늦어진 소프트웨어 프로젝트에 사람을 더 넣으면 일정이 더 늦어질 수 있다는 관찰입니다. 단순히 개발자가 부족하다는 문제가 아니라 온보딩, 커뮤니케이션, 코드 충돌, 테스트 범위가 동시에 늘어나는 구조를 봐야 합니다.

실무에서는 “몇 명을 더 투입할까”보다 “어떤 일을 독립적으로 떼어낼 수 있나”가 먼저입니다. 새 인력이 바로 처리할 수 있는 업무와 기존 핵심 개발자의 설명이 필요한 업무를 분리하지 않으면 증원은 속도 개선이 아니라 추가 병목이 됩니다.

이 글은 개발팀 증원, 외주 투입, 단기 스프린트 압축, QA 막판 투입을 결정하기 전에 일정표와 의존성을 다시 계산하는 방법을 다룹니다.

목차

• 1. 늦은 개발 프로젝트에서 먼저 봐야 할 것
• 2. 인력 추가가 일정을 늦추는 구조
• 3. 증원 전에 일을 나누는 기준
• 4. 일정 리스크를 숫자로 보는 작은 코드
• 5. 개발팀 운영 체크리스트
• 6. 자주 묻는 질문

늦은 개발 프로젝트에서 먼저 봐야 할 것

브룩스의 법칙은 개발 조직에서 자주 반복되는 착각을 찌릅니다. 일정이 밀리면 사람을 더 붙이면 된다고 생각하기 쉽지만, 소프트웨어 작업은 벽돌 쌓기처럼 단순 병렬화되지 않습니다. 새로 들어온 사람은 도메인, 코드베이스, 배포 방식, 장애 이력, 팀의 암묵 규칙을 배워야 합니다.

문제는 그 학습 비용을 누가 내느냐입니다. 보통 가장 바쁜 핵심 개발자가 설명하고, 리뷰하고, 잘못된 방향을 되돌립니다. 그래서 프로젝트가 이미 늦은 상태라면 새 인력 1명이 들어오는 순간 기존 인력 1명의 집중 시간이 같이 줄어들 수 있습니다.

브룩스의 법칙을 만든 배경을 먼저 확인하면 “사람을 늘리지 말라”가 아니라 “늦은 프로젝트의 병목을 계산 없이 사람으로 덮지 말라”는 뜻에 가깝다는 점을 이해하기 쉽습니다.

브룩스의 법칙 배경 확인하기 →

인력 추가가 일정을 늦추는 구조

늦어진 프로젝트의 핵심 비용은 코드 작성 시간이 아닐 때가 많습니다. 요구사항 해석, 기존 설계 이해, 데이터 마이그레이션, 배포 검증, 장애 대응, 이해관계자 조율이 뒤엉키면 새 인력은 곧바로 생산자가 되기 어렵습니다.

늘어나는 비용	현장에서 보이는 신호	대응 방향
온보딩	개발 환경 구성, 권한 신청, 도메인 설명에 며칠이 걸림	환경 스크립트와 문서를 먼저 정리
커뮤니케이션	회의가 늘고 결정권자가 계속 불려감	질문 채널과 결정 로그를 고정
통합 리스크	브랜치 충돌, API 계약 변경, 회귀 버그가 늘어남	작은 단위 배포와 자동 테스트를 우선
품질 검증	완료된 기능도 QA에서 계속 되돌아옴	완료 조건과 테스트 케이스를 먼저 합의

그래서 증원 판단은 인원 수가 아니라 병목의 종류에서 시작해야 합니다. 개발자가 부족한지, 리뷰가 막힌 것인지, 요구사항이 흔들리는지, QA 기준이 늦게 나오는지에 따라 해법이 다릅니다. 병목이 의사결정이면 사람을 더 넣어도 대기열만 길어집니다.

증원 전에 일을 나누는 기준

사람을 더 넣어도 되는 일은 독립성이 높아야 합니다. 예를 들어 로그 대시보드, 테스트 데이터 생성기, 문서 자동화, 비핵심 어드민 화면처럼 인터페이스가 분명한 작업은 새 인력이 맡아도 위험이 낮습니다. 반대로 결제, 인증, 재고 정산, 핵심 추천 로직처럼 서비스 중심부를 건드리는 일은 설명과 리뷰 비용이 큽니다.

작업 유형	추가 인력에 적합한 경우	주의할 경우
기능 개발	API 계약과 화면 범위가 닫혀 있음	요구사항이 매일 바뀜
리팩터링	테스트가 있고 영향 범위가 작음	도메인 지식 없이는 실패 원인 추적이 어려움
QA 보강	테스트 시나리오와 완료 조건이 확정됨	제품 기준이 늦게 정해짐
운영 자동화	반복 작업과 스크립트 범위가 명확함	권한과 보안 정책이 정리되지 않음

개발도구, 테스트 자동화, 로그 수집이 약하면 사람을 늘려도 같은 실수를 반복합니다. 개발팀 운영비를 판단할 때는 IDE, 협업도구, CI, 보안 점검 도구처럼 새 인력이 빠르게 적응하는 기반도 같이 봐야 합니다.

SW 개발도구 비용 조건 같이 보기 →

일정 리스크를 숫자로 보는 작은 코드

정교한 산정 도구가 없어도 간단한 계산표는 만들 수 있습니다. 아래 예시는 남은 작업량, 신규 인력의 온보딩 일수, 기존 핵심 인력의 설명 시간, 통합 리스크를 반영해 “증원 후 실제 단축 효과”를 거칠게 보는 스켈레톤입니다.

from dataclasses import dataclass

@dataclass
class TeamPlan:
    remaining_work_days: int
    current_velocity: float
    new_people: int
    onboarding_days: int
    mentor_hours_per_day: float
    integration_risk_days: int


def estimate_finish_days(plan: TeamPlan) -> float:
    # 새 인력은 온보딩 기간 동안 온전한 생산성을 내기 어렵다.
    mentor_loss_days = (plan.mentor_hours_per_day / 8) * plan.onboarding_days
    added_velocity = max(plan.new_people * 0.6, 0)
    effective_velocity = plan.current_velocity + added_velocity
    base_days = plan.remaining_work_days / effective_velocity
    return base_days + plan.onboarding_days + mentor_loss_days + plan.integration_risk_days

plan = TeamPlan(
    remaining_work_days=80,
    current_velocity=4.0,
    new_people=2,
    onboarding_days=5,
    mentor_hours_per_day=2,
    integration_risk_days=4,
)

print(round(estimate_finish_days(plan), 1))

숫자는 팀마다 달라집니다. 중요한 것은 계산식 자체가 아니라 질문의 순서입니다. 새 인력이 첫날부터 100% 생산성을 낸다고 넣으면 계획은 좋아 보이지만 실제 일정은 틀어집니다. 온보딩과 리뷰 손실, 통합 테스트 시간을 일정표에 따로 넣어야 합니다.

개발팀 운영 체크리스트

브룩스의 법칙을 피하려면 증원 결정을 금지하는 것이 아니라 증원 가능한 조건을 만들어야 합니다. 아래 항목이 준비되어 있으면 새 인력이 들어와도 기존 팀의 집중력을 덜 빼앗습니다.

• 남은 작업을 1~3일 단위로 쪼개고 담당자 없이도 이해되는 완료 조건을 붙였는가
• 신규 인력이 건드려도 되는 모듈과 건드리면 안 되는 모듈을 구분했는가
• 개발 환경 구성, 권한, 테스트 실행, 배포 절차가 문서나 스크립트로 재현되는가
• 리뷰 대기열과 QA 대기열이 이미 포화 상태라면 병목 담당자를 먼저 보호했는가
• 일정 단축 기대치에서 온보딩, 멘토링, 통합 테스트 시간을 뺐는가

스크럼 방식으로 팀을 운영하더라도 같은 원리가 적용됩니다. 스프린트 안에 넣을 수 있는 일은 팀의 실제 처리량과 완료 기준 안에서 결정해야 하며, 역할을 늘린다고 제품 책임, 개발, 검증 책임이 자동으로 정렬되지는 않습니다.

스크럼 팀 운영 기준 확인하기 →

자주 묻는 질문

브룩스의 법칙은 개발자를 더 뽑지 말라는 뜻인가요?

아닙니다. 늦어진 프로젝트에 무작정 사람을 넣으면 온보딩과 조율 비용 때문에 더 늦어질 수 있다는 뜻입니다. 새 인력이 맡을 독립 작업, 설명 문서, 테스트 기준이 준비되어 있으면 증원이 도움이 될 수 있습니다.

외주 개발자를 투입하면 이 문제를 피할 수 있나요?

외주도 같은 원리를 받습니다. 계약 범위가 닫혀 있고 API, 화면, 검수 기준이 분명하면 효과가 있지만, 요구사항이 흔들리는 핵심 기능을 막판에 넘기면 내부 개발자의 설명과 리뷰 부담이 커집니다.

일정이 이미 늦었을 때 가장 먼저 줄일 것은 무엇인가요?

기능 범위와 의존성을 먼저 줄여야 합니다. 핵심 출시 조건, 나중에 미뤄도 되는 기능, 자동화로 대체 가능한 반복 작업을 나눈 뒤 인력 투입 여부를 결정하는 편이 안전합니다.

프로젝트 매니저는 어떤 지표를 봐야 하나요?

남은 작업량만 보지 말고 리뷰 대기 시간, QA 재오픈 비율, 배포 실패 횟수, 질문 응답 시간, 온보딩 완료 시간을 같이 봐야 합니다. 이 지표가 나빠진 상태에서 사람만 늘리면 대기열이 더 길어질 가능성이 큽니다.