프로젝트 진행을 위한 설계도 WBS

어릴 적을 떠올려보면, 시험기간이 되면 우리는 자연스럽게 계획표를 만들었다.
국어는 월요일, 수학은 화요일, 그리고 영어는 하루 전에 몰아서 ㅋㅋ(?)…
그 계획이 얼마나 지켜졌는지는 모르겠지만, 그 시도만큼은 늘 진지했다.

또, 방학이 시작되면 어김없이 나왔던 '방학 계획표'도 있다.
아침 7시 기상, 8시 독서, 9시 수학 문제집 풀기…
물론 그 표는 3일을 넘기지 못하고 책상 한쪽으로 밀려났지만,
지금 생각해보면 그 계획표들이 나름대로 '프로젝트 관리'였던 셈이다.

 

회사의 프로젝트도 본질은 크게 다르지 않다.
다만, 그 규모와 이해관계자, 금액이 다를 뿐이다.
수천만 원에서 수십억 원의 예산이 투입되고, 수십 명의 인력이 달라붙는 IT 프로젝트에서는
무작정 시작하면 반드시 실패한다. 그래서 꼭 필요한 것이 바로 WBS다.

WBS 작성절차

WBS란 무엇인가?

WBS는 Work Breakdown Structure의 약자로,
프로젝트의 전체 범위를 체계적으로 쪼개어 나누는 작업 구조도라고 이해하면 된다.

“프로젝트의 인도물과 전체 업무 범위를 작고 관리 가능한 최소 단위로 분할한 계층 구조.”

실무에서는 이렇게 이해할 수 있다.
“나중에 ‘이건 누가 하기로 했었지?’라고 말하지 않게 하기 위한 설계도”

실제로 경험한 WBS, 그리고 그것이 왜 중요한지 느낀 순간

나는 몇 년 전, 지방 지자체에서 발주한 중규모 IT 인프라 구축 프로젝트에 참여했었다.
그 프로젝트는 예산만 약 20억 원, 수행 기간은 1년이 넘는 장기 프로젝트였다.

초반에 작성된 WBS는 약 3주 동안 수십 명이 붙어서 만든 문서였다.
그때는 '너무 디테일하게 쪼개는 거 아닌가?' 싶었지만,
3개월이 지나고, 요청사항이 바뀌면서 생각이 완전히 달라졌다.

WBS는 단순한 문서가 아니라, 프로젝트의 ‘기억’이었다.

WBS 작성에는 원칙이 있다 — 단순히 나누기만 하는 것이 아니다

• Two-Week 원칙: 각 작업 단위는 2주 이내로 완결되도록 쪼갠다
• One-Week 원칙: 1주 미만 작업은 통합하여 하나의 작업 단위로 묶는다
• Six-Month 원칙: 6개월 이후 작업은 요약 수준에서 정의
• 장기계획 원칙: 미래 일정은 Phase 단위로 유연하게 계획

구성요소와 100% Rule — WBS는 수치보다 ‘논리’의 언어

• Work Package: 실제 실행 가능한 작업 단위
• WBS Dictionary: 각 작업에 대한 설명과 정의
• Code of Account: 식별 번호
• Control Account: 여러 작업을 묶는 관리 단위
• RAM: 담당자 및 역할 정의

WBS의 100% Rule:

• 모든 작업량과 예산은 상위 계층의 100%를 구성해야 한다
• 상위 작업은 하위 작업의 총합이어야 한다
• 중복 없이, 빠짐 없이 나눠야 한다 (MECE 원칙)

마무리하며

WBS는 한 번 작성하면 끝나는 문서가 아니다.
프로젝트가 끝날 때까지 함께 진화하고, 관리되고, 공유되어야 하는 살아 있는 문서다.

내가 느낀 WBS의 가장 큰 가치는,
‘완벽한 계획’을 세우기 위한 도구가 아니라
‘예상하지 못한 상황에 대처할 수 있는 체계’를 만드는 데 있다는 것이다.

아직 WBS를 그저 ‘형식적인 문서’라고 생각하고 있다면, 다음 프로젝트부터는 진짜로 그 위에 의미를 담아보자.
분명 프로젝트는 훨씬 덜 흔들릴 것이다. WBS에 관심을 가지고 전체 그림을 볼 수 있다면 프로젝트를 진행하는데 있어서 한결

마음에 편해질 것 이다. 아니 더 불안해 질 수도 있나? ㅎㅎ