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