WBS 작성법 — 100% 규칙부터 8/80 규칙까지 5단계
발행
WBS(Work Breakdown Structure, 작업분류체계)는 프로젝트의 최종 산출물을 관리 가능한 크기까지 계층으로 쪼갠 구조다. 일정표가 아니라 범위의 지도다 — 언제 하느냐가 아니라 무엇을 하느냐를 담는다. 잘 만든 WBS 하나가 견적·일정·담당자 배정·진척 측정의 기준선이 되고, 잘못 만든 WBS 는 착수 3주 뒤 "이 작업은 누가 하기로 했죠?"라는 질문으로 되돌아온다.
이 글은 WBS 를 처음부터 다섯 단계로 만드는 절차다. 각 단계에는 PMBok 이 정리한 판단 기준이 하나씩 붙는다. 도구 없이 화이트보드에서도 그대로 쓸 수 있다.
WBS 가 아닌 것부터 정리하자
세 가지를 먼저 구분해야 나머지가 쉬워진다.
- WBS ≠ 일정. WBS 에는 순서·기간·담당자가 없다. 선후 관계와 날짜는 그다음 단계(Activity·간트차트)의 몫이다. 트리에 "1월 착수"를 적고 있다면 두 가지를 섞고 있는 것이다.
- WBS ≠ 조직도. "개발팀이 할 일 / 기획팀이 할 일"로 1단계를 나누면 팀 경계에 걸친 작업이 사라진다. 분해의 축은 산출물이다.
- WBS ≠ 할 일 목록. 평면 리스트는 빠뜨림을 검증할 방법이 없다. 계층이 있어야 "이 묶음의 합이 부모와 같은가"를 물을 수 있다.
1단계: 최종 산출물에서 시작한다
트리의 뿌리는 프로젝트가 끝났을 때 인수될 물건이다. "차세대 ERP 구축"이 아니라 "가동 가능한 ERP 시스템과 운영 이관 완료"처럼, 완료를 판정할 수 있는 명사로 적는다.
그다음 1단계 자식을 3~7개로 놓는다. 실무에서 잘 통하는 축은 두 가지다.
- 생애주기 축: 계획 → 요구사항·설계 → 구축 → 테스트 → 이행·오픈 → 안정화
- 산출물 축: 회계 모듈 / 구매 모듈 / 인사 모듈 / 공통 기반 / 데이터 이행
둘을 섞어도 된다(상위는 생애주기, 하위는 모듈). 중요한 것은 한 층 안에서는 축을 섞지 않는 것이다. 같은 층에 "설계"와 "회계 모듈"이 나란히 있으면 그 두 칸은 서로 겹친다.
2단계: 100% 규칙으로 분해한다
100% Rule — 상위 노드는 하위 노드의 합과 정확히 같아야 한다. 부족하면 빠뜨린 일이 있고, 넘치면 범위 밖의 일이 들어온 것이다.
실천법은 질문 하나다. 부모 칸마다 "자식을 다 합치면 정말 나인가?" 를 소리 내어 묻는다. 테스트 국면으로 예를 들면 이렇다.
질문 전: 통합 테스트 = 시나리오 작성 + 테스트 수행
질문 후: 통합 테스트 = 테스트 계획 수립 + 테스트 환경 구성 + 테스트 데이터 준비 + 시나리오 작성 + 테스트 수행 + 결함 조치·재검증 + 결과 보고
두 칸에서 일곱 칸이 되었다 — 다섯 칸이 새로 드러난 것이다. 특히 테스트 데이터 준비와 결함 재검증은 착수 전에는 눈에 띄지 않다가 실행에서 만만치 않은 공수를 요구하는, 트리에서 자주 빠지는 자리다. 왜 이런 일이 반복해서 빠지는지는 빠뜨린 일은 '계획에 없던 일'이 아니다에서 다른 사례로 해부했다.
한 가지 덧붙이면, 100% 는 가중치(weight)로 관리하면 검증이 자동화된다. 형제 칸의 가중치 합이 100 이 아니면 그 자리에서 경고가 뜨게 만들 수 있다(차단이 아니라 경고다 — 계획 중에는 잠시 어긋나는 것이 정상이므로). 엑셀로는 사실상 불가능하고, 트리를 데이터로 다루는 도구에서는 당연한 검사다.
3단계: 8/80 규칙으로 크기를 맞춘다
8/80 Rule — 최하위 작업 단위(Work Package)는 8시간보다 작지도, 80시간보다 크지도 않게 쪼갠다. 80시간(2주)을 넘는 칸은 아직 분해가 끝나지 않았다는 신호다. "데이터 이행 5주"처럼 적힌 칸은 계획이 아니라, 아직 답을 미뤄 둔 질문이다.
기준이 애매할 때 쓰는 두 개의 보조 질문:
- 보고 가능성: 이 칸의 진척률을 매주 정직하게 보고할 수 있는가? "60% 쯤"이라는 답만 나오면 더 쪼갠다.
- 인수 가능성: 이 칸이 끝났다고 누가 어떻게 판정하는가? 답할 수 없으면 산출물이 불명확한 것이다.
분해의 부산물이 중요하다. 쪼개는 순간 산출물과 완료 기준을 묻게 되고, 그 질문에 답하지 못하는 덩어리가 바로 빠진 일이 숨어 있는 자리다.
4단계: 상호배제로 중복을 걷어낸다
Mutually Exclusive — 어떤 작업도 두 칸에 동시에 속하면 안 된다. 겹치면 "서로 상대가 하는 줄 알았다"가 발생하고, 그 사고는 대개 통합 단계에서 발견된다.
겹침이 자주 생기는 자리는 정해져 있다.
- "API 개발"과 "연동 개발" — 외부 연동 어댑터가 양쪽에 반쯤 걸린다
- "테스트"와 각 모듈의 "단위 테스트" — 통합 테스트 범위가 모호해진다
- "공통 기반"과 각 모듈 — 공통 컴포넌트를 누가 만드는지 불명확해진다
처방은 경계를 명시적으로 적는 것이다. 애매한 칸의 이름 옆에 "포함: … / 제외: …"를 한 줄 붙이면 대부분 해결된다. 이 한 줄이 다음 단계의 WBS Dictionary 로 이어진다.
5단계: WBS 코드와 Dictionary로 고정한다
트리가 완성되면 두 가지를 붙여 계획을 고정한다.
WBS 코드(1.2.3) 는 계층을 읽기 위한 표시용 번호다. 회의에서 "1.4.2 말씀이신가요?"로 소통이 되는 값이지, 작업의 정체성은 아니다 — 칸을 옮기면 코드는 바뀐다. 그래서 종속성이나 참조를 코드로 걸어 두면 나중에 깨진다.
WBS Dictionary 는 각 Work Package 의 정의서다. 최소 네 칸이면 충분하다.
- 작업 정의(무엇을 하는가)
- 산출물(무엇이 남는가)
- 완료 기준(누가 어떻게 인수하는가)
- 제외 범위(무엇을 하지 않는가)
Dictionary 를 쓰기 싫어지는 칸이 있다면, 그 칸은 아직 정의가 안 된 것이다. 작성 부담이 아니라 진단 도구로 쓰면 된다.
흔한 실패 4가지
| 실패 유형 | 증상 | 교정 |
|---|---|---|
| 조직도로 분해 | 팀 경계에 걸친 작업이 트리에 없다 | 1단계 축을 산출물·생애주기로 다시 세운다 |
| 분해 수준 불균형 | 어떤 가지는 4단, 어떤 가지는 "개발" 한 칸 | 80시간 초과 칸을 전부 찾아 재분해 |
| 동사만 있는 칸 | "성능 개선" — 무엇이 남는지 알 수 없다 | 산출물 명사를 붙인다("튜닝 리포트 + 목표 응답시간 충족") |
| 일정과 혼용 | 트리에 착수일·담당자가 들어가 있다 | 날짜·순서는 Activity·간트로 분리 |
네 가지 중 앞의 둘은 계획 단계에서, 뒤의 둘은 실행 2~3주 차에 대가를 치른다. 특히 마지막 항목은 WBS 와 간트를 다른 파일로 관리할 때 필연적으로 벌어지는 일이고, 그 결과는 엑셀로 만든 계획은 만든 날부터 죽는다에 적었다.
30분 완성도 체크리스트
트리를 다 그린 뒤, 회의 시작 30분 전에 이 순서로 훑는다.
- 루트가 인수 가능한 산출물의 이름인가?
- 한 층 안에서 분해 축이 섞이지 않았는가?
- 모든 부모 칸에서 "자식의 합 = 나"가 성립하는가? (가중치 합 100)
- 80시간을 넘는 말단 칸이 하나도 없는가?
- 8시간 미만으로 잘게 쪼갠 칸이 관리 비용만 늘리고 있지 않은가?
- 두 칸에 걸친 작업이 없는가? (특히 공통 기반·연동·테스트)
- 모든 말단 칸에 산출물 명사와 완료 기준이 있는가?
- 인수·검수·교육·이행처럼 끝에 붙는 일이 트리에 있는가?
- 트리에 날짜·담당자가 섞여 들어가지 않았는가?
여덟 번째 항목이 실무에서 가장 자주 걸린다. 프로젝트의 마지막 2주에 해야 할 일은 계획 초기에 가장 상상하기 어렵기 때문이다.
다음에 읽을 것
WBS 가 서면 다음은 순서와 날짜다 — 종속성을 걸고 크리티컬 패스를 계산하는 단계로 넘어간다.
우리가 이 도구를 만들며 실제로 시험해 본 것 중 하나는, 문서를 주고 LLM 에게 WBS 초안을 통째로 맡기는 것이었다. 6개월 ERP 구축을 대상으로 초안·정련·일정·정의서까지 만들게 한 기록이 Claude에게 SI 프로젝트 WBS를 통째로 맡겨봤다에 있다. 결론을 미리 말하면 — 회상은 기계가 잘하고, 약속은 사람이 해야 한다. 위의 다섯 단계 중 기계가 대신할 수 있는 것은 13단계의 초안이고, 45단계의 경계 결정은 여전히 PM 의 판단이다.
wbsgantt 는 이 다섯 단계를 화면에서 따라가게 만드는 도구다. 가중치 합이 100 이 아니면 그 자리에서 경고하고, 코드는 칸을 옮길 때마다 다시 매겨지며, Dictionary 는 노드마다 붙어 있어 따로 관리할 문서가 없다.
자주 묻는 질문
- WBS는 몇 단계까지 쪼개야 하나요?
- 고정된 정답은 없고 8/80 규칙이 기준입니다 — 최하위 Work Package 가 8시간 이상 80시간 이하로 떨어지면 충분합니다. 소규모 프로젝트는 3단계, 6개월 규모의 SI 는 보통 4~5단계에서 멈춥니다. 판단이 서지 않으면 "이 칸의 진척률을 매주 정직하게 보고할 수 있는가"를 물어보십시오. 대답이 애매하면 한 단계 더 내려갑니다.
- WBS와 일정(간트차트)은 어떻게 다른가요?
- WBS 는 무엇을 하는지를 담은 범위의 지도이고, 간트차트는 언제 하는지를 담은 시간의 지도입니다. WBS 에는 순서·기간·담당자가 없습니다. 최하위 Work Package 에 순서와 기간을 붙이면 Activity 가 되고, 그것을 시간축에 늘어놓은 것이 간트차트입니다. 둘을 한 문서에 섞으면 범위 변경과 일정 변경을 구분할 수 없게 됩니다.
- 애자일 프로젝트에도 WBS가 필요한가요?
- 계약·보고 요구가 있다면 필요합니다. WBS 는 무엇을 만드는가의 분해이고 스프린트는 어떻게 실행하는가의 리듬이므로 서로 충돌하지 않습니다. 상위 2~3단(산출물 수준)만 WBS 로 고정하고 그 아래 실행은 백로그·스프린트로 돌리는 하이브리드가 실무에서 가장 흔합니다.
- WBS 가중치는 어떻게 정하나요?
- 공수 비중을 기본으로 쓰고, 비용이 계획의 축이면 원가 비중을 씁니다. 형제 칸의 합이 100 이 되도록 배분하는 것이 핵심이며, 소수점까지 정밀하게 맞추는 것보다 합이 맞는지 자동으로 검사되는 상태를 만드는 것이 중요합니다. 가중치가 틀어지면 진척률과 SPI 가 함께 왜곡됩니다.
- 엑셀로 만들면 안 되나요?
- 초안 단계에서는 엑셀이 가장 빠릅니다. 문제는 그다음입니다 — 100% 규칙 검증, 코드 재부여, 종속성 반영, 진척 집계가 전부 수작업이 되고, WBS 시트와 간트 시트가 서로 다른 말을 하기 시작합니다. 노드가 100개를 넘으면 검증을 사람이 감당하지 못합니다.