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

WBS 트리는 일의 목록이고, WBS Dictionary는 그 칸 하나하나의 계약서다. 이름만 적힌 칸은 사람마다 다르게 읽는다. 같은 "결제 모듈 설계"를 두고 설계자는 화면 설계로, 개발자는 API 설계로, PM은 둘 다로 이해한다. 세 사람 모두 자기 해석이 맞다고 여긴 채 실행이 시작된다. Dictionary는 이 차이를 계획 단계에서 없애는 문서다. 이 글에서는 실무에 꼭 필요한 필드 3개, 곧 정의·산출물·완료기준을 나쁜 예와 좋은 예로 비교해 가며 쓰는 법을 본다. 이어서 어느 칸부터 쓸지, 왜 대부분의 Dictionary가 방치되는지, AI 초안은 어디까지 맡겨도 되는지를 다룬다.

왜 트리만으로는 부족한가

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

경계가 흐린 채 실행이 시작되면 두 가지 일이 생긴다. 양쪽 모두 자기 범위가 아니라고 여긴 일은 아무도 하지 않고, 양쪽 모두 자기 일이라고 여긴 일은 두 번 한다. 둘 중 어느 쪽이든 대개 검수 직전에야 드러난다. 고쳐 붙이는 비용이 가장 비쌀 때다. 트리 자체를 빠짐없이 만드는 방법은 WBS 작성법 5단계에서 다뤘다. 이 글은 그렇게 만든 칸마다 경계를 긋는 문서를 다룬다.

Dictionary가 담는 3가지

PMBok의 WBS Dictionary는 담당자·기간·원가 견적까지 담을 수 있는 넉넉한 문서다. 그중 없으면 실제로 사고가 나는 필드는 3개다.

첫째는 정의다. 이 칸이 무엇을 포함하고 무엇을 포함하지 않는지, 곧 범위의 경계를 적는다. 둘째는 산출물이다. 이 칸이 끝나면 손에 잡히는 결과물이 무엇인지 명사로 적는다. 셋째는 완료기준이다. 누가 무엇을 확인하면 끝난 것으로 칠지, 검수자가 판정할 수 있는 문장으로 적는다. 이 셋이 각각 "무엇을 하는 일인가", "무엇이 나오는가", "언제 끝난 것인가"에 답한다. 3개가 비어 있으면 담당자나 기간 같은 나머지 필드는 채워도 소용없다. 무슨 일인지 합의되지 않은 일에 담당자와 기간을 붙인 셈이기 때문이다.

정의는 경계를 긋는 문장이다

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

좋은 예는 포함과 불포함을 나눠 적는다. "포함: 결제 흐름 화면 설계(장바구니–결제 완료), 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 초안 활용

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

다만 초안은 기계가 쓰더라도 확정은 사람이 한다. 특히 두 곳은 사람만 정할 수 있다. 하나는 불포함 목록이다. 무엇을 안 하기로 했는지는 조직이 내린 결정이지 추론으로 나오는 값이 아니다. 다른 하나는 완료기준의 판정 주체다. 누가 승인하는지는 권한의 문제다. AI 초안을 받았다면 이 두 곳부터 확인하자.

다음에 읽을 것

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