WBS 자원 할당: 큰 팀이 항상 더 빠른 것은 아니다

Source: Dev.to

사람을 더 늘리면 더 빨리 끝날 거죠?
개발자들은 이 말을 들으면 보통 속으로 한숨을 쉽니다.
실제로는 더 오래 걸릴 수도 있습니다.

브룩스의 법칙—“지연된 소프트웨어 프로젝트에 인력을 추가하면 프로젝트가 더 늦어진다”—는 50년 동안 사실이며 오늘도 여전히 유효합니다. 아래에서는 왜 큰 팀이 항상 더 빠른 것이 아닌지, 그리고 자원을 효과적으로 할당하는 방법을 살펴봅니다.

커뮤니케이션 오버헤드

팀 규모가 커질수록 커뮤니케이션 경로 수는 제곱적으로 증가합니다:

20명 팀에서는 하루에 1시간이 조정에만 사라집니다. 측정된 데이터에 따르면 10명 이상의 개발자 팀은 하루에 4시간 미만을 실제 코딩에 할애하고, 나머지는 회의, 리뷰, 질문·답변, 대기 등에 사용됩니다.

팀 규모 가이드라인

“두 개의 피자로도 배를 채울 수 없는 팀은 너무 크다.” – 제프 베조스

이상적인 구성 (≈ 7명):

• 제품 소유자: 1
• 백엔드 개발자: 2
• 프론트엔드 개발자: 2
• 디자이너: 1
• QA 엔지니어: 1

“최고의 인재만 배정”이 실패하는 이유

Alice가 React 전문가라 하더라도 도메인 지식이 없으면 생산성이 ≈ 50 % 감소한다. 그녀는 여전히 필요하다:

• 기존 코드베이스를 이해하는 데 약 2 주
• 팀 코딩 규칙에 적응하는 데 약 1 주

일반적인 오해

“작업을 10개의 작업으로 나누면, 10명이 동시에 할 수 있다”

// PM's imagination
const ideal_timeline = {
  workDivision: 10,
  peopleAssigned: 10,
  expectedDuration: '1 week',
};

// Actual reality
const reality = {
  dependencyWaiting: '30% time waste',
  integrationWork: 'additional 20% time',
  communication: 'additional 25% time',
  actualDuration: '2.5 weeks',
};

분할 전략

팀 구조

핵심 팀 (3‑4명)

• 핵심 아키텍처 설계
• 주요 결정
• 최종 코드‑리뷰 승인

지원 팀 (5‑6명)

• 특정 기능 구현
• 테스트 작성
• 문서화

장점: 의사결정 속도를 유지하고, 품질 일관성을 보장하며, 효율적인 지식 전달을 가능하게 하고, 단일 작업에 용량의 100 %를 할당하지 않음.

권장 자원 할당

# Recommended allocation (percent of capacity)
recommended_allocation = {
    "Planned work": 70,
    "Urgent issue response": 15,
    "Code review / mentoring": 10,
    "Learning / improvement": 5,
}

경험 수준에 따른 조정

junior_allocation = {
    "Planned work": 50,   # lower to allow learning
    "Learning / improvement": 20,
}

실제 사례

Project A – 3개월 프로젝트, 5인 팀

• 1개월 후: 진행률 20 %에 불과
• 결정: 인원을 5명 추가
• 결과: 교육 오버헤드, 커뮤니케이션 3배 증가, 빈번한 병합 충돌 → 2개월 지연

Project B – 같은 회사, 다음 프로젝트

• 구조: 3명씩 구성된 3팀, 각각 독립 마이크로서비스 담당
• 조정: 사전 정의된 API 계약, 전체 동기화는 주 1회만
• 결과: 2주 일찍 완료

작업 부하 시각화

resource_heatmap = {
    "Mon": {"Alice": 120, "Bob": 80,  "Charlie": 100},
    "Tue": {"Alice": 100, "Bob": 120, "Charlie": 80},
    "Wed": {"Alice": 80,  "Bob": 100, "Charlie": 120},
    # …
}

• ≥ 120 % – 과부하 (빨강)
• 80‑120 % – 적절 (초록)
• < 80 % – 사용 가능 (파랑)

페어 로테이션

// Weekly pair rotation
const pair_rotation = {
  'Mon‑Tue': [
    ['Senior', 'Junior'],
    ['Mid',    'Mid'],
  ],
  'Wed‑Thu': [
    ['Senior', 'Mid'],
    ['Junior', 'Mid'],
  ],
  Fri: 'Individual work / Refactoring',
};

효과

• 지식 공유 극대화
• 코드 품질 향상
• 버스 팩터 감소

글로벌 협업

Korean Team (09:00‑18:00 KST)
   ↓ Handoff
US Team (09:00‑18:00 PST)
   ↓ Handoff
European Team (09:00‑18:00 CET)

24시간 개발 사이클이 가능하지만, hand‑off documentation가 필수적입니다 (예: Plexi의 실시간 WBS 업데이트, GitHub PR 비동기 댓글, Notion RFC, Loom 비디오 스탠드‑업).

핵심 요점

• 5‑7명 규모의 소규모 크로스‑펑셔널 팀이 대규모 그룹보다 성과가 좋다.
• 커뮤니케이션 비용은 제곱적으로 증가하므로 낮게 유지한다.
• 용량의 **≤ 70 %**는 계획된 작업에 할당하고, **≈ 30 %**는 예상치 못한 이벤트에 대비한다.
• “슈퍼스타 의존”을 피하고 팀 전체 역량을 높이는 데 투자한다.
• 페어 프로그래밍과 정기적인 로테이션은 버스 팩터를 낮추고 지식을 확산한다.
• 자원 할당을 복잡한 최적화 문제로 다루며, 단순한 산술이 아니다.

효율적인 자원 관리와 WBS가 필요하신가요? Plexo를 확인해 보세요.