- WBS는 1962년 미국 해군의 폴라리스 잠수함 미사일 프로젝트에서 처음 정형화되었고, 1968년 MIL-STD-881이 발표되면서 국방 표준이 됐다
- 100% 규칙 — 상위 작업의 100%가 하위 작업의 합과 일치해야 하며, 빠진 것도 겹친 것도 없어야 한다
- 8/80 규칙 — 가장 하위 작업(work package)은 8시간에서 80시간 사이여야 한다. 너무 크면 통제 불가, 너무 작으면 관리 오버헤드
- 잘 짠 WBS는 프로젝트 진척률을 실시간으로 알려주지만, 잘못 짠 WBS는 상세할수록 오히려 계획을 왜곡한다
프로젝트 관리의 기본 도구인 WBS(Work Breakdown Structure). 오늘날 모든 프로젝트 매니저가 쓰지만, 이 개념이 어디서 왔는지 아는 사람은 드물다. 1962년 냉전 시대 미국 국방부와 NASA의 대형 미사일·우주 프로젝트에서 처음 등장했다. 그리고 60년이 지난 지금도 프로젝트 실패의 80%가 여기서 갈린다. 왜 그런지.
1962년 폴라리스 프로젝트 — WBS의 태생
1957년, 미국 해군은 소련의 스푸트니크 발사에 충격을 받았다. 맞대응으로 잠수함 발사 탄도마사일(SLBM) 개발 프로젝트인 폴라리스(Polaris)를 초고속으로 밀어붙였다. 문제는 그 규모였다 — 수백 개 업체, 수만 개 사양, 10년짜리 일정. 기존의 프로젝트 관리 방식으로는 통제 불가능했다.
1962년, 해군과 록히드, 부즈 엄다 앱턴(Booz Allen Hamilton) 컴설턴트들이 함께 개발한 것이 PERT(Program Evaluation and Review Technique)였고, 그 밑바닥에 깔린 구조가 WBS다. “프로젝트 전체를 거대한 작업 뎍어리로 보지 말고, 계층적으로 나누어 가장 작은 단위만을 통제하라”는 아이디어였다. 폴라리스는 계획보다 2년 앞당겨 완성되었고, 이 경험이 1968년 미국 국방부 표준 MIL-STD-881로 정립되었다.
흥미로운 것은 60년이 지난 지금 MIL-STD-881이 여전히 살아있다는 점이다. 2022년 개정된 최신 버전(MIL-STD-881F)이 미국 국방 조달 표준이며, 상업 업계의 PMBOK(프로젝트 관리 지식체계)도 WBS를 핵심 기법으로 유지하고 있다.
역사적 맥락 — WBS는 “목표를 정하고 거거서 거꾸로 내려온다”의 방식이 아니다. 오히려 “최종 산출물이 무엇인지를 먼저 정의하고, 그것을 만들기 위해 필요한 보다 작은 산출물들로 나누는” 산출물 중심 사고법이다. 이게 폴라리스가 성공한 근본 이유였고, 오늘날 프로젝트가 실패하는 근본 이유는 이 산출물 정의를 건너뛰기 때문이다.
100% 규칙 — 가장 어기기 쉬운 원칙
WBS의 첫 번째 원칙은 간단하다. 상위 작업의 100%가 그 아래 하위 작업들의 합과 일치해야 한다. 빠진 작업이 있으면 안 되고, 겹치는 작업이 있어도 안 된다. 장난감 같이 들리지만, 실제로 프로젝트에서 이 규칙을 지키는 것은 매우 어렵다.
흔한 실수 예를 보자. “신규 제품 출시”를 상위 작업으로 놓고, 하위에 “설계, 개발, 테스트, 마케팅”을 넣는다. 그런데 “법무 검토”는 어디 들어간는가. “고객 교육”은? “생산 생산 라인 설치”는? 보통 이런 작업들이 빠진 상태로 프로젝트가 시작되고, 중간에 “아, 이게 필요하네”가 들어온다. WBS 계획만 보면 90% 진행된 것 같지만, 실제로는 무엇을 보는지 아무도 모른다.
100% 규칙은 이 문제를 예방한다. 상위 작업을 하위로 나눌 때마다 “이 목록이 상위 작업의 100%를 다 담고 있는가?”를 확인하는 것이 WBS 작성의 핵심 검증 단계다.
8/80 규칙 — 너무 크지도, 너무 작지도 않게
두 번째 원칙은 가장 하위 작업 단위인 “work package”의 적정 크기를 정한다. 약 8시간에서 80시간 사이여야 한다는 경험칙이다. 이보다 크면 진척률을 통제할 수 없게 되고, 이보다 작으면 관리 오버헤드가 생산성을 넘어선다.
만약 하나의 work package가 200시간이라면 — 그것이 30% 진행될 때까지 매니저는 “진행 중”이라는 보고만 받을 수 있다. 진짜 문제가 있는지, 예상보다 느린지는 보이지 않는다. 따로 반대로 work package가 2시간짜리로 잡혀있으면, 기록·보고·리뷰에 들어가는 시간이 실제 작업 시간을 넘어설다.
8/80은 절대적인 규칙이 아니라 대략적인 지침이다. 솜프트웨어 개발 같은 증분적 작업은 8시간으로 가까운 것이 좋고, 건설·설사·교육 같이 복잡하지만 예측 가능한 작업은 40~80시간이 적절하다. 산업·토큰에 맞게 조정해야 한다.
실무 팁 — WBS를 검토할 때 보는 첫 번째 신호는 “하위 말단 작업들의 추정 지속 시간”다. 대부분이 100시간을 넘어서면 프로젝트가 진짜로 통제되지 않는 신호이며, 거의 모두 4시간 이하면 WBS 자체가 지나치게 잡혔어 유지가 불가능해질 수론법이다.
실무에서 WBS를 망치는 3가지 실수
1. 산출물이 아니라 활동으로 나눈다
WBS를 “명사가 아니라 동사로 나누는” 실수가 가장 흔하다. “개발·테스트·검토·사용자 교육”은 활동이지 산출물이 아니다. 이렇게 나누면 진척률 측정이 모호해진다. “개발을 70% 했어요”가 정확히 무슨 뜻인지 아무도 모른다. WBS는 “샜이트 문서 완료”, “사용자 매뉴얼 초안”, “베타 엔드 보고서” 같이 목적어적 산출물로 나눠야 진척률이 이진적으로 측정된다.
2. 수직 계층이 너무 깊다
WBS를 7단계 이상으로 나누면 관리 불가능하다. 교과서적으로는 3에서 5단계가 가장 적은록 보면, 진행이 느려지며 모든 관리 데이터의 해상도가 될수록 떨어진다. 복잡한 프로젝트는 수평적으로 넘어야 하먰, 불필요하게 수직으로 파고들면 안 된다.
3. 조직도와 동일시한다
마지막 실수는 조직도를 그대로 WBS로 옮기는 것이다. “개발팀, 설계팀, 품질팀” 같이 부서 단위로 나누면, 결국 WBS가 부서간 업무 분담표가 된다. 프로젝트가 생산하려는 것은 ‘부서’가 아니라 ‘결과물’이기 때문에, WBS는 산출물 중심으로 짜야 하며 각 작업 단위에 담당 부서를 매핑하는 방식이 올바르다.
관찰 — 이 세 실수는 모두 “WBS를 물리적 산출물이 아닌 다른 것을 기준으로 나누는 습관”에서 나온다. 폴라리스 팀이 60년 전에 발견한 원칙은 간단하다 — “무엇을 만드는가”를 먼저 정의하고, “누가 어떻게”는 그 뒤에 결정한다.
AI가 WBS를 대신 만들 수 있을까
2024년 이후 GenAI가 프로젝트 관리 도구에 대거 들어오면서 “프로젝트 개요만 넣으면 WBS를 자동 생성”이란 기능이 많은 제품에 붙었다. Asana, Monday.com, ClickUp, Notion AI 등이 이미 지원한다. 실제로 쓰면 어떨까.
결론부터 말하면, AI는 WBS의 초안은 멋지게 만든다. 근데 초안만이다. AI가 모르는 것이 세 가지 있다 — 조직의 실제 역량과 경험, 이해관계자의 숮겨진 요구사항, 이전 프로젝트에서 쉽게 겪은 실패 패턴. 이 세 가지는 여전히 프로젝트 매니저의 장인적 판단이 필요한 영역이다.
하지만 AI가 잘하는 것도 있다 — “누락된 산출물 확인” 같은 100% 규칙 검증은 기계가 사람보다 훨씬 잘한다. “이 WBS에는 품질 검증 단계가 빠졌어요” 같은 지적은 AI 검수의 강점이다. 앵병적으로는 사람이 초안을 만들고 AI가 검수하는 방식이 현재까지는 가장 유용하다.
다음 편 예고 — 다음 편에서는 WBS와 함께 쓰이는 Gate Review를 다룸다. NASA가 왜 각 단계 사이에 “관문”을 만들었는지, 그리고 오늘날 스타트업도 왜 이 관문 제도를 도입해야 하는지.
관련 글
참고
- Wikipedia — Work Breakdown Structure
- PMI — PMBOK Guide & Standards
- MIL-STD-881F — US DoD Work Breakdown Structures Standard
AI Biz Insider · AI 제조인사이트 · aibizinsider.com
댓글 남기기