WBS 작성법: 100% 규칙부터 8/80 규칙까지 5단계

WBS(Work Breakdown Structure, 작업분류체계)는 프로젝트의 최종 산출물을 관리할 수 있는 크기까지 계층으로 나눈 구조다. 일정표가 아니라 범위의 지도다. 언제 하느냐가 아니라 무엇을 하느냐를 담는다. 잘 만든 WBS 하나가 견적과 일정, 담당자 배정, 진척 측정의 기준이 된다. 잘못 만든 WBS는 착수 3주 뒤 "이 작업은 누가 하기로 했죠?"라는 질문으로 되돌아온다.

이 글에서는 WBS를 처음부터 만드는 절차를 5단계로 정리한다. 단계마다 PMBOK이 정리해 둔 판단 기준을 하나씩 붙였다. 도구 없이 화이트보드에서도 그대로 쓸 수 있다.

WBS가 아닌 것부터 정리하자

먼저 3가지를 구분해 두면 나머지가 쉬워진다.

• WBS는 일정이 아니다. WBS에는 순서도, 기간도, 담당자도 없다. 선후 관계와 날짜는 그다음 단계인 Activity와 간트차트가 맡는다. 트리에 "1월 착수"를 적고 있다면 서로 다른 두 가지를 한곳에 섞고 있는 것이다.
• WBS는 조직도가 아니다. "개발팀이 할 일 / 기획팀이 할 일"로 1단계를 나누면 팀 경계에 걸친 작업이 사라진다. 나누는 기준은 산출물이다.
• WBS는 할 일 목록이 아니다. 목록만 늘어놓으면 무엇을 빠뜨렸는지 확인할 방법이 없다. 계층이 있어야 "이 묶음을 다 더하면 부모와 같은가"를 물을 수 있다.

1단계: 최종 산출물에서 시작한다

트리의 맨 위에는 프로젝트가 끝났을 때 인수받을 결과물을 적는다. "차세대 ERP 구축"이 아니라 "가동 가능한 ERP 시스템과 운영 이관 완료"처럼 완료 여부를 판정할 수 있는 명사로 쓴다.

그 아래 1단계 자식은 3~7개로 놓는다. 실무에서 잘 통하는 기준은 2가지다.

• 생애주기: 계획 → 요구사항·설계 → 구축 → 테스트 → 이행·오픈 → 안정화
• 산출물: 회계 모듈 / 구매 모듈 / 인사 모듈 / 공통 기반 / 데이터 이행

층이 다르면 두 기준을 섞어도 된다. 상위는 생애주기로, 하위는 모듈로 나누는 식이다. 대신 한 층 안에서는 섞지 않는다. 같은 층에 "설계"와 "회계 모듈"이 나란히 있으면 두 항목의 범위가 서로 겹친다.

2단계: 100% 규칙으로 분해한다

100% Rule은 상위 항목이 하위 항목의 합과 정확히 같아야 한다는 규칙이다. 모자라면 빠뜨린 일이 있는 것이고, 넘치면 범위 밖의 일이 들어온 것이다.

실천 방법은 질문 하나다. 부모 항목마다 "자식을 다 합치면 정말 나인가?"를 소리 내어 묻는다. 테스트 단계를 예로 들어 보자.

질문 전: 통합 테스트 = 시나리오 작성 + 테스트 수행

질문 후: 통합 테스트 = 테스트 계획 수립 + 테스트 환경 구성 + 테스트 데이터 준비 + 시나리오 작성 + 테스트 수행 + 결함 조치·재검증 + 결과 보고

2개였던 항목이 7개로 늘었다. 5개가 새로 드러난 것이다. 그중에서도 테스트 데이터 준비와 결함 재검증이 자주 빠진다. 착수 전에는 눈에 잘 띄지 않다가 실행에 들어가면 만만치 않은 공수를 요구하기 때문이다. 왜 이런 일이 반복해서 빠지는지는 빠뜨린 일은 '계획에 없던 일'이 아니다에서 다른 사례로 살펴봤다.

100% 규칙은 가중치(weight)로 관리하면 검증이 쉬워진다. 형제 항목의 가중치 합이 100이 아니면 그 자리에서 경고가 뜨게 만들 수 있다. 차단이 아니라 경고인 이유는, 계획을 다듬는 동안에는 합이 잠시 어긋나는 것이 정상이기 때문이다. 엑셀로는 이런 검사를 사실상 할 수 없지만, 트리를 데이터로 다루는 도구에서는 당연한 검사다.

3단계: 8/80 규칙으로 크기를 맞춘다

8/80 Rule은 최하위 작업 단위(Work Package)를 8시간보다 작지도, 80시간보다 크지도 않게 나누라는 기준이다. 80시간(2주)을 넘는 항목은 아직 분해가 끝나지 않았다는 신호다. "데이터 이행 5주"라고 적힌 항목은 계획이 아니라 아직 답을 미뤄 둔 질문이다.

기준이 애매하면 질문 2개를 더 던져 본다.

• 보고할 수 있는가: 이 항목의 진척률을 매주 정직하게 보고할 수 있는가? "60%쯤"이라는 답만 나온다면 더 나눈다.
• 인수할 수 있는가: 이 항목이 끝났다고 누가 어떻게 판정하는가? 답할 수 없다면 산출물이 불명확한 것이다.

분해에는 부산물이 따라온다. 항목을 나누는 순간 산출물이 무엇인지, 무엇을 보고 끝났다고 할지 묻게 된다. 그 질문에 답하지 못하는 덩어리가 바로 빠진 일이 숨어 있는 자리다.

4단계: 상호배제로 중복을 걷어낸다

Mutually Exclusive는 어떤 작업도 두 항목에 동시에 속하면 안 된다는 원칙이다. 겹치면 "서로 상대가 하는 줄 알았다"는 상황이 생기고, 대개 통합 단계에 가서야 드러난다.

겹침이 자주 생기는 자리는 정해져 있다.

• "API 개발"과 "연동 개발": 외부 연동 어댑터가 양쪽에 반쯤 걸린다
• "테스트"와 각 모듈의 "단위 테스트": 통합 테스트 범위가 모호해진다
• "공통 기반"과 각 모듈: 공통 컴포넌트를 누가 만드는지 불명확해진다

해결책은 경계를 글로 적어 두는 것이다. 애매한 항목의 이름 옆에 "포함: … / 제외: …" 한 줄을 붙이면 대부분 정리된다. 이 한 줄이 다음 단계의 WBS Dictionary로 이어진다.

5단계: WBS 코드와 Dictionary로 고정한다

트리를 다 그렸으면 2가지를 붙여 계획을 고정한다.

WBS 코드(1.2.3)는 계층을 읽기 위한 표시용 번호다. 회의에서 "1.4.2 말씀이신가요?"라고 서로 확인할 때 쓰는 값이지, 작업의 정체성은 아니다. 항목을 옮기면 코드도 바뀐다. 그래서 종속성이나 참조를 코드로 걸어 두면 나중에 깨진다.

WBS Dictionary는 각 Work Package의 정의서다. 4가지만 적어도 충분하다.

• 작업 정의(무엇을 하는가)
• 산출물(무엇이 남는가)
• 완료 기준(누가 어떻게 인수하는가)
• 제외 범위(무엇을 하지 않는가)

Dictionary를 쓰기 싫어지는 항목이 있다면 그 항목은 아직 정의되지 않은 것이다. 서류 작업이 아니라 진단 도구로 쓰면 된다.

흔한 실패 4가지

앞의 2가지는 계획 단계에서, 뒤의 2가지는 실행 2~3주 차에 대가를 치른다. 특히 마지막 항목은 WBS와 간트를 다른 파일로 관리할 때 거의 예외 없이 벌어진다. 그 결과는 엑셀로 만든 계획은 만든 날부터 죽는다에 적었다.

30분 완성도 체크리스트

트리를 다 그린 뒤, 회의 시작 30분 전에 이 순서로 훑는다.

• 루트가 인수 가능한 산출물의 이름인가?
• 한 층 안에서 분해 기준이 섞이지 않았는가?
• 모든 부모 항목에서 "자식의 합 = 나"가 성립하는가? (가중치 합 100)
• 80시간을 넘는 말단 항목이 하나도 없는가?
• 8시간 미만으로 잘게 나눈 항목이 관리 비용만 늘리고 있지 않은가?
• 두 항목에 걸친 작업이 없는가? (특히 공통 기반·연동·테스트)
• 모든 말단 항목에 산출물 명사와 완료 기준이 있는가?
• 인수·검수·교육·이행처럼 끝에 붙는 일이 트리에 있는가?
• 트리에 날짜·담당자가 섞여 들어가지 않았는가?

8번째 항목이 실무에서 가장 자주 걸린다. 프로젝트의 마지막 2주에 할 일은 계획 초기에 가장 상상하기 어렵기 때문이다.

다음에 읽을 것

WBS가 서면 그다음은 순서와 날짜다. 종속성을 걸고 크리티컬 패스를 계산하는 단계로 넘어간다.

이 도구를 만들면서 실제로 시험해 본 것 중 하나는 LLM에게 문서를 주고 WBS 초안을 통째로 맡기는 일이었다. 6개월짜리 ERP 구축을 대상으로 초안과 정련, 일정, 정의서까지 만들게 한 기록이 Claude에게 SI 프로젝트 WBS를 통째로 맡겨봤다에 있다. 결론을 미리 말하면, 회상은 기계가 잘하고 약속은 사람이 해야 한다. 위 5단계 중 기계가 대신할 수 있는 것은 1단계에서 3단계까지의 초안이고, 4단계와 5단계의 경계 결정은 여전히 PM의 판단이다.

wbsgantt는 이 5단계를 화면에서 그대로 밟아 갈 수 있게 만든 도구다. 가중치 합이 100이 아니면 그 자리에서 경고하고, 항목을 옮기면 코드를 다시 매기며, Dictionary가 노드마다 붙어 있어 따로 관리할 문서가 없다.