"인력 더 투입하면 빨리 끝나겠죠?"
이 질문을 들으면 개발팀장들은 속으로 한숨을 쉽니다.
"아니요, 오히려 더 늦어질 수 있습니다."
브룩스의 법칙이라고 들어보셨나요? "지연된 소프트웨어 프로젝트에 인력을 추가하면 더 늦어진다"는 50년 전 법칙인데, 지금도 여전히 유효합니다.
오늘은 WBS에서 가장 어려운 리소스 배분의 비밀을 파헤쳐보겠습니다.
팀 규모의 역설
커뮤니케이션 오버헤드의 기하급수적 증가
팀이 커질수록 소통 경로는 기하급수적으로 늘어납니다:
# 팀 규모별 커뮤니케이션 경로
# 공식: n × (n-1) / 2
3명 팀: 3개 경로
5명 팀: 10개 경로
10명 팀: 45개 경로
20명 팀: 190개 경로
20명 팀에서는 하루 1시간이 커뮤니케이션으로 사라집니다.
실제로 측정해보면 더 충격적입니다. 10명 이상의 팀에서는 개발자가 실제 코딩에 쓰는 시간이 하루 4시간도 안 됩니다. 나머지는? 회의, 리뷰, 질문, 답변, 대기...
피자 두 판의 법칙
아마존의 제프 베조스가 만든 규칙이 있습니다:
"피자 두 판으로 먹일 수 없는 팀은 너무 크다"
이상적인 팀 구성:
- 제품 책임자: 1명
- 백엔드 개발: 2명
- 프론트엔드 개발: 2명
- 디자이너: 1명
- QA: 1명
- 총 7명
리소스 배분의 실제
1. 스킬 매트릭스의 함정
많은 PM이 이런 표를 만듭니다:
| 이름 | React | Node.js | Python | 가용성 |
|---|---|---|---|---|
| Alice | 5 | 4 | 3 | 80% |
| Bob | 3 | 5 | 4 | 60% |
| Charlie | 4 | 3 | 5 | 100% |
그리고 이렇게 생각합니다: "Alice를 React에, Bob을 Node.js에 배치하면 완벽해!"
현실은 다릅니다.
Alice가 React 전문가라도:
- 프로젝트의 도메인 지식이 없으면 생산성 50% 감소
- 기존 코드베이스 파악에 2주 소요
- 팀 코딩 컨벤션 적응에 1주 추가
2. 병렬 작업의 신화
"작업을 10개로 나누면 10명이 동시에 할 수 있겠네요?"
아닙니다.
// PM의 상상
const ideal_timeline = {
'작업 분할': 10,
'투입 인원': 10,
'예상 기간': '1주',
};
// 실제 현실
const reality = {
'의존성 대기': '30% 시간 낭비',
'통합 작업': '추가 20% 시간',
커뮤니케이션: '추가 25% 시간',
'실제 기간': '2.5주',
};
효과적인 리소스 배분 전략
1. 수직 분할 vs 수평 분할
❌ 수평 분할 (레이어별)
- 프론트엔드 팀 / 백엔드 팀 / DB 팀
- 문제: 끊임없는 조율, 책임 떠넘기기, 통합 지옥
✅ 수직 분할 (기능별)
- 로그인 기능 팀 / 결제 기능 팀 / 검색 기능 팀
- 장점: 독립적 진행, 명확한 책임, 빠른 피드백
2. 코어 팀 + 서포트 팀 구조
코어 팀 (3-4명)
├── 핵심 아키텍처 설계
├── 주요 의사결정
└── 코드 리뷰 최종 승인
서포트 팀 (5-6명)
├── 구체적 기능 구현
├── 테스트 작성
└── 문서화
이 구조의 장점:
- 의사결정 속도 유지
- 품질 일관성 보장
- 지식 전파 효율화
3. 리소스 버퍼 전략
절대 100% 할당하지 마세요.
# 권장 리소스 할당
recommended_allocation = {
"계획된 작업": 70, # %
"긴급 이슈 대응": 15,
"코드 리뷰/멘토링": 10,
"학습/개선": 5
}
# 경험 수준별 조정
junior_allocation = {
"계획된 작업": 50, # 더 낮게
"학습/개선": 20 # 더 높게
}
실제 사례: 리소스 배분 실패와 성공
실패 사례: "더 많은 인력" 함정
한 스타트업의 실제 이야기입니다:
상황: 3개월 프로젝트, 5명 팀
문제 발생: 1개월 후 진척률 20%
잘못된 결정: 5명 추가 투입
결과:
- 기존 팀원들이 신규 팀원 교육에 시간 소비
- 커뮤니케이션 오버헤드 3배 증가
- 코드 충돌 빈발
- 최종 지연: 2개월
성공 사례: "작은 팀, 명확한 경계"
같은 회사, 다음 프로젝트:
접근 방법:
- 3명씩 3개 팀으로 분할
- 각 팀에 독립적인 마이크로서비스 할당
- API 계약만 사전 정의
- 주 1회만 전체 동기화
결과: 예정보다 2주 조기 완료
리소스 최적화 도구와 기법
1. 리소스 히트맵
# 팀원별 작업 부하 시각화
resource_heatmap = {
"월": {"Alice": 120, "Bob": 80, "Charlie": 100},
"화": {"Alice": 100, "Bob": 120, "Charlie": 80},
"수": {"Alice": 80, "Bob": 100, "Charlie": 120},
# ... (% 표시)
}
# 120% 이상: 과부하 (빨간색)
# 80-120%: 적정 (초록색)
# 80% 미만: 여유 (파란색)
2. 스킬-태스크 매칭 알고리즘
단순히 "React 잘하는 사람 = React 작업" 이 아닙니다:
고려 사항:
- 현재 작업 부하
- 도메인 지식
- 성장 욕구
- 팀 내 지식 분산
3. 페어 프로그래밍 로테이션
// 주간 페어 로테이션
const pair_rotation = {
'월-화': [
['Senior', 'Junior'],
['Mid', 'Mid'],
],
'수-목': [
['Senior', 'Mid'],
['Junior', 'Mid'],
],
금: '개인 작업 / 리팩토링',
};
// 효과:
// - 지식 공유 극대화
// - 코드 품질 향상
// - 버스 팩터 감소
원격 근무 시대의 리소스 관리
시간대 차이 활용
한국 팀 (09:00-18:00 KST)
↓ 핸드오프
미국 팀 (09:00-18:00 PST)
↓ 핸드오프
유럽 팀 (09:00-18:00 CET)
24시간 개발이 가능하지만, 핸드오프 문서화가 핵심입니다.
비동기 협업 도구
- 작업 진행 상황: Plexo의 WBS 실시간 업데이트
- 코드 리뷰: GitHub PR의 비동기 댓글
- 의사결정: Notion의 RFC 문서
- 일일 동기화: Loom 비디오 스탠드업
리소스 배분의 골든 룰
작은 팀이 큰 팀을 이긴다
- 5-7명이 최적
- 그 이상은 분할 고려
전문가 한 명보다 균형 잡힌 팀
- 슈퍼스타 의존은 위험
- 팀 전체 역량 향상에 투자
70% 규칙
- 최대 70%만 계획에 할당
- 30%는 예상치 못한 일에 대비
회전 근무 금지
- 컨텍스트 스위칭 비용 고려
- 한 사람은 하나의 프로젝트에
성장 기회 제공
- 모든 작업을 전문가에게만 주지 않기
- 주니어도 도전적 과제 필요
마무리: 적게 투입하고 많이 얻기
"인력을 두 배로 늘리면 기간이 반으로 줄어든다"는 것은 환상입니다.
현실적인 공식:
- 3명이 3개월 걸릴 일
- 6명 투입 → 2.5개월 (이상적인 경우)
- 9명 투입 → 3개월 (동일하거나 더 걸림)
리소스 배분은 단순한 산수가 아닙니다. 팀 다이나믹스, 커뮤니케이션 비용, 지식 공유, 동기부여까지 고려해야 하는 복잡한 최적화 문제입니다.
다음 프로젝트에서는 "몇 명?"이 아니라 "어떻게?"를 먼저 물어보세요.
효율적인 리소스 관리와 WBS가 필요하신가요? Plexo를 확인해보세요.
