WBS Dictionary 작성법 — 정의·산출물·완료기준

WBS 트리는 일의 목록이고, WBS Dictionary 는 각 칸의 계약서다. 이름만 있는 칸은 사람마다 다르게 읽는다. 같은 "결제 모듈 설계"라는 칸을 설계자는 화면 설계로, 개발자는 API 설계로, PM 은 둘 다로 읽는다 — 그리고 세 사람 모두 자기가 맞다고 생각한 채 실행이 시작된다. Dictionary 는 이 간극을 계획 단계에 닫는 문서다. 이 글은 실무 최소셋인 세 필드 — 정의·산출물·완료기준 — 를 나쁜 예와 좋은 예로 작성하는 법을 다루고, 어느 칸부터 쓸 것인지, 왜 대부분의 Dictionary 가 죽는지, AI 초안은 어디까지 맡길 수 있는지로 끝낸다.

왜 트리만으로는 부족한가

WBS 트리는 일을 빠짐없이 나누는 데는 강하지만, 각 칸의 이름은 짧다. 이름은 일을 가리킬 뿐 경계를 긋지 못한다. "데이터 이관"이라는 칸에 검증까지 포함되는지, "화면 설계"에 디자인 시안이 포함되는지는 이름만으로 알 수 없다.

경계가 흐린 채 실행이 시작되면 두 가지가 생긴다. 양쪽 모두 자기 범위가 아니라고 생각한 일은 빠지고, 양쪽 모두 자기 일이라고 생각한 일은 중복된다. 어느 쪽이든 발견되는 시점은 대개 검수 직전 — 가장 비싼 시점이다. 트리 자체를 빠짐없이 만드는 방법은 WBS 작성법 5단계에서 다뤘고, 이 글은 그렇게 만든 칸 하나하나에 경계를 긋는 문서를 다룬다.

Dictionary가 담는 세 가지

PMBok 의 WBS Dictionary 는 담당자·기간·원가 견적까지 담을 수 있는 넉넉한 문서다. 하지만 실무에서 없으면 실제로 사고가 나는 최소셋은 세 필드다.

첫째, 정의 — 이 칸이 무엇을 포함하고 무엇을 포함하지 않는가(범위의 경계). 둘째, 산출물 — 이 칸이 끝나면 손에 잡히는 결과물이 무엇인가(명사의 목록). 셋째, 완료기준 — 누가 무엇을 확인하면 끝난 것으로 치는가(검수 가능한 문장). 셋이 각각 "무엇을 하는 일인가", "무엇이 나오는가", "언제 끝난 것인가"에 답한다. 이 셋이 비어 있으면 담당자나 기간 같은 나머지 필드는 채워도 의미가 없다 — 무엇인지 합의되지 않은 일의 담당자와 기간이기 때문이다.

정의 — 경계를 긋는 문장

나쁜 예부터 보자. "결제 모듈을 설계한다." 칸 이름을 문장으로 늘렸을 뿐, 아무 경계도 긋지 못한다.

좋은 예는 포함과 불포함을 나눈다. "포함: 결제 흐름 화면 설계(장바구니–결제 완료), PG 연동 API 명세. 불포함: PG 사 계약 협상, 정산 배치 설계(1.4.2 에서 수행)." 정의가 계약서가 되는 순간은 불포함을 적는 순간이다. 포함 목록은 다들 쓰지만, 분쟁은 언제나 경계 바깥에서 벌어진다 — "이것도 해 주시는 거 아니었어요?"라는 문장이 나오는 지점이 바로 불포함을 적지 않은 지점이다. 불포함 항목이 다른 칸에서 수행된다면 그 칸의 코드를 함께 적어, 일이 어디에도 속하지 않은 채 사라지는 것을 막는다.

산출물 — 명사로 답한다

나쁜 예: "설계 진행." 이것은 산출물이 아니라 상태다. 상태는 손에 잡히지 않고, 잡히지 않는 것은 검수할 수 없다.

좋은 예: "화면 설계서 v1.0(12화면), PG 연동 API 명세서 1부." 산출물은 명사여야 하고, 가능하면 셀 수 있어야 한다. 산출물이 셀 수 있는 명사가 되는 순간 부수 효과가 하나 따라온다 — 진척률을 셀 수 있게 된다. "12화면 중 9화면 완료 = 75%"는 산출물이 명사로 정의된 칸에서만 가능한 문장이다. "설계 진행" 칸의 진척률은 영원히 담당자의 기분이다.

완료기준 — 검수자가 판정할 수 있는 문장

나쁜 예: "개발 완료." 무엇이 어떤 상태면 완료인지, 누가 판정하는지가 없다. 이런 칸은 8주째 "80% 완료"에 머무는 칸이 된다.

좋은 예: "12화면 전부 디자인 리뷰 통과, PO 승인 기록." 좋은 완료기준의 조건은 두 가지다. 예/아니오로 판정할 수 있는 조건일 것, 그리고 판정하는 주체가 명시될 것. 수치(12화면 전부)·통과 조건(디자인 리뷰)·승인자(PO)가 들어가면 "끝났다/안 끝났다" 논쟁이 설 자리가 없어진다. 완료기준은 작업자를 압박하는 문서가 아니라 보호하는 문서이기도 하다 — 기준을 충족했다면 추가 요구는 범위 변경이지 마무리가 아니다.

어느 칸에 쓰는가

전 노드에 의무화하는 것은 Dictionary 를 형식 문서로 죽이는 가장 빠른 길이다. 우선순위는 두 겹이다.

먼저 Work Package(최하위 칸) 에 쓴다. 실제 일과 검수가 벌어지는 곳이 여기고, 상위 칸은 자식들의 합이라 대개 따로 쓸 내용이 없다. 다음으로, Work Package 중에서도 해석이 갈리면 비싼 칸부터 쓴다 — 외주사와의 경계에 있는 칸, 팀과 팀 사이의 인수인계 지점, 고객 검수가 걸린 칸. 모두가 같은 회사, 같은 팀이라면 이름만으로도 통하는 칸이 많다. 경계 바깥에 다른 조직이 있는 칸은 그렇지 않다.

안 쓰이는 Dictionary의 병리

많은 프로젝트에서 Dictionary 는 킥오프 무렵 한 번 작성되고 다시는 열리지 않는 워드 파일이다. 성실함의 문제가 아니라 위치의 문제다 — 계획 문서가 실행 데이터와 분리된 폴더에 살면, 실행 중에 그것을 열 이유가 없고, 열리지 않는 문서는 갱신되지 않으며, 갱신되지 않는 문서는 신뢰를 잃는다.

살아 있는 Dictionary 는 노드에 붙어 있다. 작업을 열면 그 자리에서 정의와 완료기준이 보이고, 주간 점검에서 "이 칸 끝났나요"라는 질문이 나올 때 완료기준이 그 자리에서 판정한다. 보고서·검수 문서가 이 데이터에서 추출되는 구조라면 Dictionary 는 저절로 유지된다 — 산출물은 작성하는 것이 아니라 추출하는 것이어야 한다는 원칙은 보고서를 만드느라 프로젝트를 못 챙기는 PM에서 다뤘다.

AI 초안 활용

세 필드는 형식이 정해져 있다 — 정의는 포함/불포함, 산출물은 명사 목록, 완료기준은 판정 문장. 형식이 정해진 글은 AI 초안이 잘 맞는 영역이라, 칸 이름과 프로젝트 맥락을 주면 쓸 만한 초안이 나온다. 실제로 Claude 가 6개월 ERP 구축 프로젝트의 WBS 를 만들면서 Work Package 별 정의서 초안까지 쓴 기록은 Claude에게 SI 프로젝트 WBS를 통째로 맡겨봤다에 있다.

다만 초안은 기계가 쓰고 확정은 사람이 한다. 특히 두 곳은 사람만 정할 수 있다 — 불포함 목록(무엇을 안 하기로 했는지는 조직의 결정이지 추론이 아니다)과 완료기준의 판정 주체(누가 승인하는가는 권한의 문제다). AI 초안을 받았다면 이 두 곳부터 검토하는 것이 요령이다.

다음에 읽을 것

Dictionary 는 홀로 서는 문서가 아니라 여정의 가운데에 있다. 앞 단계는 일을 빠짐없이 나누는 WBS 작성법이고, 뒤 단계는 이렇게 정의된 칸의 진척을 정직하게 재는 측정과 보고다 — 산출물이 명사로, 완료기준이 판정 문장으로 적힌 칸에서만 진척률과 검수가 논쟁 없이 굴러간다. wbsgantt 에서는 모든 WBS 노드가 Dictionary 를 1:1 로 갖는다 — 정의·산출물·완료기준에 가정·제약·견적·참고자료까지, 채움 정도는 완성도로 표시되고, MCP 를 연결하면 AI 초안을 받아 검토·확정할 수 있다. 승인 워크플로 같은 결재 기능은 없으므로, 확정의 기록은 완료기준 문장 안에 승인 주체를 적는 방식으로 남긴다.