WBS와 애자일은 싸우지 않는다
발주사와의 착수 회의. 고객사 PMO(프로젝트 관리 전담 조직)가 말한다. "월별 마일스톤과 WBS 기반 진척 보고를 요청드립니다." 돌아온 사무실, 개발 리드가 말한다. "우린 스크럼으로 일해요. WBS는 워터폴 유물 아닌가요?"
PM은 그 사이에 서 있다. 계약과 보고는 WBS를 요구하고, 팀은 스프린트로 돌아간다. 많은 PM이 이 상황을 "둘 중 하나를 속이는 것"으로 해결한다. 팀에는 안 보이는 곳에서 몰래 WBS를 관리하거나, 고객에게는 스프린트 보드를 WBS처럼 포장해 보여주거나. 어느 쪽이든 이중장부다. 그리고 이중장부는 반드시 들킨다.
프레임이 잘못됐다
"WBS냐 애자일이냐"는 질문 자체가 범주 오류다. 둘은 경쟁 관계가 아니라 차원이 다른 도구이기 때문이다.
WBS는 What의 분해다. 이 프로젝트가 인도해야 할 것의 전체를, 빠짐도 겹침도 없이 구조화한 것(1편의 100% Rule이 이것이다). WBS는 일하는 방식에 대해 아무 말도 하지 않는다.
애자일은 How의 실행이다. 정해진 범위를 어떤 리듬으로, 어떤 피드백 주기로 만들어낼 것인가의 방법론이다. 스프린트는 일하는 방식이지, 범위의 구조가 아니다.
"WBS는 워터폴 유물"이라는 말은 What과 How를 혼동한 것이다. 실제로 PMBok 7판은 라이프사이클을 Predictive(예측형)부터 Adaptive(적응형)까지의 스펙트럼으로 정의하고, 상황에 맞게 재단(Tailoring)하라고 말한다. 순수 워터폴도, 순수 애자일도 스펙트럼의 양 끝단일 뿐이며, 현실의 계약 기반 프로젝트 대부분은 그 사이 어딘가 — 하이브리드에 있다.
하이브리드의 실전 구조
이중장부 없이 양쪽을 만족시키는 구조는 이렇다.
상위 2~3레벨은 WBS로 고정한다. 인도물과 주요 마일스톤, 계약 단위의 범위는 트리로 구조화하고 베이스라인(3편)을 건다. 이 층은 고객·경영진과의 약속이며, 변경통제의 대상이다. 움직임이 느린 층이다.
최하위 Work Package의 내부는 팀에 위임한다. "정산 모듈(120시간)"이라는 Work Package를 어떻게 구현할지 — 몇 개의 스토리로 쪼개고 어느 스프린트에 태울지 — 는 팀의 백로그가 결정한다. 이 층은 빠르게 움직이고, 고객 보고에 노출되지 않는다.
두 층의 접점은 진척 규칙 하나로 잇는다. 스프린트에서 Work Package에 속한 스토리가 완료(Done)되면, 그 완료가 Work Package의 진척으로 집계된다(4편의 이벤트 기반 산정이 여기서도 작동한다). 팀은 스토리 포인트(작업 크기의 상대 추정 단위)로 말하고, 고객은 마일스톤과 SPI로 듣는다. 같은 사실의 두 가지 언어일 뿐, 장부는 하나다.
구조를 표로 정리하면 이렇다. 핵심은 Work Package가 두 세계의 경첩이라는 것.
| 계층 | PM 세계 (WBS) | 팀 세계 (Backlog) | 누가 통제하는가 |
|---|---|---|---|
| Level 1~2 | 인도물·단계 | (Epic에 대응) | PM — 베이스라인·변경통제 |
| Level 3 | Work Package | Feature / Story 묶음 | 경계선 — 여기서 만난다 |
| 그 아래 | (내려가지 않는다) | Story·Task, 스프린트 배정 | 팀 — 백로그 정제(refinement) |
Epic·Story는 애자일의 요구사항 단위다 — Epic이 큰 묶음, Story가 스프린트에 들어가는 작은 단위.
진척은 아래에서 위로 흐른다. Story Done → Work Package 진척 반영(EV 획득) → 마일스톤·SPI로 집계 → 고객 보고. 팀은 위를 올려다볼 필요가 없고, 고객은 아래를 내려다볼 필요가 없다.
계약형 프로젝트에서 애자일을 굴리는 법
"계약은 고정인데 애자일이 가능한가"라는 질문에는 세 가지 분리로 답한다.
- 범위는 고정, 상세는 가변: Work Package 수준의 범위는 계약·베이스라인으로 고정하되, 그 내부의 구현 방식·스토리 분해는 팀이 스프린트마다 조정한다
- 마일스톤은 고정, 반복은 자유: 고객과의 검증 지점은 날짜로 약속하고, 그 사이를 몇 번의 스프린트로 채울지는 팀이 정한다
- 변경은 CR로, 개선은 refinement로: Work Package의 경계를 넘는 요구는 변경통제(3편)로, 경계 안의 조정은 백로그 refinement로 처리한다. 이 구분이 무너지면 "애자일이니까요"라는 이름으로 범위가 새기 시작한다
양쪽에 하는 말도 준비해 두자. 개발팀에는 — "WBS는 일하는 방식을 통제하지 않는다. 우리가 무엇을 약속했는지 기록할 뿐이고, 스프린트 안은 전적으로 팀의 것이다." 고객에는 — "스프린트는 내부 실행 단위입니다. 보고는 승인된 인도물과 마일스톤 기준으로 드립니다."
도구가 문제를 다시 만든다
구조는 명쾌한데 현실에서 자주 무너지는 이유는, 도구가 한쪽 세계관만 지원하기 때문이다. 스프린트 도구에는 WBS·베이스라인·EVM이 없고, 전통 PM 도구에는 백로그와 스프린트가 없다. 그래서 PM은 결국 두 도구 사이에서 수작업 다리를 놓다가 2편의 이중 장부 문제로 회귀한다. 우리가 도구를 설계하며 하이브리드를 별도 모드가 아닌 기본 전제로 둔 이유가 이것이다. 상위는 WBS와 베이스라인, 하위는 팀의 실행 리듬 — 한 데이터 모델이 두 언어를 모두 말해야 한다.
WBS와 애자일을 싸움 붙이는 것은 도구와 관성이지, 원리가 아니다. What의 지도를 쥔 채로 How의 자유를 주는 것. 하이브리드 시대 PM의 일은 그 두 손을 동시에 쓰는 것이다.
PM의 실행 블록
내일 바로 할 일 3가지
- 현재 WBS에서 "팀에 위임할 경계"인 Work Package 레벨을 명시적으로 정한다
- 백로그의 Epic/Story를 Work Package에 매핑한다 — 매핑 안 되는 스토리가 곧 범위 이슈다
- "Story Done이 Work Package 진척에 어떻게 집계되는가" 규칙 하나를 팀과 합의한다
회의에서 던질 질문
- "이 스토리는 어느 Work Package에 속합니까? 없다면 왜 하고 있습니까?"
- "이 고객 요구는 Work Package 경계 안입니까, 밖입니까?" (안이면 refinement, 밖이면 CR)
- "고객 보고의 마일스톤 날짜와 스프린트 캘린더가 충돌하는 지점이 있습니까?"
좋은 신호 / 나쁜 신호
| 좋은 신호 | 나쁜 신호 |
|---|---|
| 모든 스토리가 Work Package를 부모로 가진다 | 백로그와 WBS가 서로 모르는 사이다 |
| 범위 요구가 CR과 refinement로 자동 분류된다 | "애자일이니까"가 범위 변경의 근거로 쓰인다 |
| 팀은 스프린트를, 고객은 마일스톤을 본다 | 고객 보고용 자료를 매주 손으로 짜맞춘다 |
도구는 무엇을 해결해야 하는가
이중장부의 근원은 두 세계관을 각각 지원하는 두 도구였다. wbsgantt를 설계하며 하이브리드를 별도 모드가 아닌 기본 전제로 둔 이유다 — 상위는 WBS·베이스라인·EVM, Work Package 아래는 팀의 실행 단위가 붙고, Done 이벤트가 자동으로 위로 집계된다. 장부가 하나면, 번역은 필요해도 이중 기입은 필요 없다.