WBS 작성법 실전 — PM PD가 알아야 할 프로젝트 분해 5가지 원칙

WBS, 어떻게 설계할까. 작업 분해 구조의 원칙과 실전 예시 — 현장에서 직접 정리한 WBS 설계 가이드. 프로젝트 관리의 뼈대를 세우는 법.

WBS를 짜야 하는데 어디서부터 쪼개야 할지 막막하다면, 이 글이 도움이 될 것이다. WBS는 단순 일정표가 아니다. 결과물 중심 분해, 100% 룰, 8/80 룰, 적절한 위계 깊이, 그리고 매주 업데이트 루틴 — 이 다섯 가지가 6개월짜리 프로젝트의 야근을 막는다. 자동차 컨피규레이터 실무에서 직접 겪은 WBS 설계 원칙을 그대로 정리했다.

1. WBS는 일정표가 아니다

 

WBS(Work Breakdown Structure)를 단순히 "할 일 쪼개기"로 이해하면 그 즉시 한계가 생긴다. WBS는 프로젝트의 전체 작업을 위계 구조로 분해한 지도이며, 그 지도가 잘못 그려지면 일정과 예산과 리소스가 동시에 무너진다.

 

작업이 아니라 결과물 중심으로 분해하라: 많은 PD/PM이 WBS를 "작업"으로 채운다. "디자인 회의", "에셋 검토", "수정 작업" 같은 것들이다. 하지만 좋은 WBS는 결과물(Deliverable) 을 단위로 한다. "메인 뷰 자동차 모델 1차 컨셉", "컬러 베리언트 5종 머티리얼 셋업", "인터랙션 프로토타입 v1" — 이런 식이다. 결과물 중심으로 짜야 무엇이 끝났고 무엇이 남았는지가 명확해진다.

 

100% 룰을 지켜라: WBS의 모든 하위 항목을 합치면 상위 항목 100%가 되어야 한다. 빠진 작업이 있어서도 안 되고, 중복된 작업이 있어서도 안 된다. 자동차 컨피규레이터 프로젝트에서 "차량 외관 모델링"이라는 상위 항목이 있다면, 그 아래 하위 항목들을 합쳤을 때 차량 외관 전체가 빠짐없이 다 포함되어야 한다는 뜻이다. 이 룰을 무시한 WBS는 반드시 마지막에 "어? 이건 누구 일이었지?"라는 질문을 만든다.

 

8/80 룰을 적용하라: 하나의 작업 단위는 최소 8시간, 최대 80시간 범위 안에 들어가야 한다. 이보다 짧으면 관리 비용이 작업 비용보다 커지고, 이보다 길면 진행 상황을 추적할 수 없다. 필자는 WBS 작업 단위를 잡을 때 이 범위를 벗어나는 항목이 있는지를 항상 검토한다.

 

 

2. 리얼타임 콘텐츠 WBS의 특수성

일반 영상 제작 프로젝트의 WBS와 리얼타임 콘텐츠 프로젝트의 WBS는 구조가 다르다. 이 차이를 모르면 일반 영상 PM이 짜놓은 양식을 그대로 가져다 써서 첫 한 달 만에 일정이 무너지는 사태가 벌어진다.

 

파이프라인 단계별 의존성: 리얼타임 콘텐츠는 모델링·텍스처·머티리얼·라이팅·인터랙션·최적화가 단순 순차 진행이 아니다. 머티리얼이 임시로 들어간 상태에서 라이팅 셋업을 시작하고, 인터랙션 프로토타입이 돌아가는 동안 모델링 디테일이 계속 들어온다. WBS에 이 비순차적 의존성을 어떻게 표현할지를 처음부터 설계해야 한다.

 

기술 검증 단계를 별도 항목으로 잡아라: 자동차 컨피규레이터처럼 클라이언트가 처음 시도하는 기술 스택이라면, "기술 검증(Technical Proof of Concept)" 단계를 WBS에 별도로 잡아야 한다. 이 단계가 빠지면 본 제작 단계에서 "이게 안 되네요"라는 사태가 벌어진다. 필자의 부서는 본 제작 시작 전 최소 2주의 기술 검증 기간을 항상 확보한다.

 

자산 변환과 보안 절차의 시간 비용: 자동차 OEM 프로젝트는 클라이언트가 제공하는 CAD 데이터를 변환하는 단계가 항상 발생하며, 보안 절차상 자산 전달에 며칠이 걸리는 경우도 흔하다. WBS에 이 시간을 명시적으로 잡아두지 않으면 첫 주부터 일정이 밀린다.

 

 

3. 위계 구조 — 어디까지 쪼개고 어디서 멈출 것인가

WBS의 깊이를 어디까지 가져갈지는 PD/PM의 판단이다. 너무 얕으면 관리가 안 되고, 너무 깊으면 관리 자체가 일이 된다.

 

3단계가 기본, 4단계는 예외: 대부분의 리얼타임 콘텐츠 프로젝트는 3단계 위계로 충분하다. 1단계는 프로젝트 페이즈(기획/제작/검수/납품), 2단계는 결과물 카테고리(모델링/텍스처/인터랙션 등), 3단계는 개별 결과물(메인 차량 외관 모델링 v1 등)이다. 4단계까지 내려가는 경우는 작업 규모가 크거나 외주 발주 단위로 쪼개야 할 때뿐이다.

 

관리할 의지가 없는 깊이는 만들지 마라: 필자가 본 가장 흔한 실수는 처음에 의욕적으로 5단계까지 쪼개놓고 일주일 뒤부터 업데이트를 포기하는 패턴이다. 업데이트되지 않는 WBS는 WBS가 아니다. 단순한 그림일 뿐이다. 자신이 매주 업데이트할 수 있는 깊이까지만 만들어야 한다.

 

페이즈 게이트를 명확히 표시하라: 각 페이즈가 끝나는 지점, 즉 다음 페이즈로 넘어가기 위한 검수와 컨펌이 필요한 지점을 WBS에 명시적으로 표시해야 한다. 이 게이트가 없으면 페이즈가 흐릿하게 섞여서 진행되고, 결국 "다 만들었는데 왜 컨펌이 안 났지?"라는 상황이 생긴다.

 

 

4. AI를 활용한 WBS 초안 — 직접 짜는 시간을 줄여라

WBS를 처음부터 빈 시트에서 짜는 시대는 끝났다. 2026년 현재의 AI 도구들은 과거 프로젝트 데이터를 학습시키면 비슷한 규모의 새 프로젝트 WBS 초안을 빠르게 만들어낸다.

 

과거 프로젝트 데이터의 자산화: 필자의 부서는 완료된 프로젝트의 실제 WBS와 실제 소요 시간 데이터를 별도로 정리해 보관한다. 이 데이터가 쌓이면 새 프로젝트의 WBS 초안을 만들 때 가장 강력한 무기가 된다. 정확히 같은 프로젝트가 두 번 있는 경우는 없지만, 비슷한 패턴은 반복된다.

 

보안 환경에서의 AI 활용: 자동차 OEM 프로젝트의 WBS는 신차 정보, 클라이언트 내부 일정, 본사 컨펌 라인 같은 보안 민감 정보를 포함한다. 이 정보를 클라우드 기반 AI에 입력하는 것은 계약 위반이다. 사내 보안 정책에 부합하는 로컬 AI 솔루션을 사용해야 한다. 이 원칙을 어기는 순간, 효율을 추구한 결과가 신뢰를 잃는 사고로 돌아온다.

 

AI는 초안, 검증은 PD/PM의 일: AI가 만들어낸 WBS는 어디까지나 초안이다. 100% 룰이 지켜졌는지, 8/80 룰이 적용됐는지, 우리 프로젝트의 특수성이 반영됐는지를 검증하는 것은 결국 PD/PM이다. AI 초안을 그대로 클라이언트에게 보내거나 부서 내부에 공유하기 시작하는 순간, PD/PM의 가치는 빠르게 사라진다.

 

 

5. WBS는 살아있는 문서다

WBS를 짜놓고 한 번도 업데이트하지 않는 PD/PM이 의외로 많다. 그 결과 WBS와 실제 프로젝트 진행이 따로 노는 상황이 만들어지고, WBS는 결국 누구도 보지 않는 죽은 문서가 된다.

 

주간 업데이트 루틴 확보: 매주 정해진 요일과 시간에 WBS를 업데이트하는 루틴을 만들어야 한다. 필자는 매주 금요일 오후를 이 루틴에 쓴다. 한 주 동안 진행된 결과물을 표시하고, 다음 주 작업을 확정하고, 일정 변동이 있다면 반영한다. 이 30분이 다음 주 전체의 방향을 결정한다.

 

변경 이력을 남겨라: WBS가 변경될 때마다 변경 사유를 함께 기록해야 한다. "클라이언트 요청에 의한 색상 옵션 5종 추가 — 추가 견적 제출 완료"처럼 변경의 맥락을 남겨두면, 나중에 분쟁이 생겼을 때 강력한 근거가 된다. 필자가 속한 부서는 이 변경 이력 덕분에 대형 OEM 프로젝트에서 추가 수주를 정당화할 수 있었다.

 

부서 내부 가시성 확보: WBS는 PD/PM 한 사람만 보는 문서가 아니다. 부서 전체가 같은 WBS를 같은 해석으로 보고 있어야 한다. 공유 도구와 공유 채널을 확보하고, 변경 사항을 매주 부서에 공지하는 루틴을 만들어야 한다. 공유되지 않는 WBS는 PD/PM 머릿속의 그림일 뿐이다.

 

 

결론

WBS는 형식이 아니라 프로젝트 운영의 핵심이다. 결과물 중심으로 분해하고, 100% 룰과 8/80 룰을 지키고, 적절한 깊이에서 멈추고, AI를 초안 작성에 활용하되 검증은 직접 한다. 그리고 무엇보다 매주 업데이트한다. 이 다섯 가지가 갖춰진 WBS는 6개월짜리 프로젝트의 마지막 한 달을 야근이 아닌 여유로 만든다.