본문으로 건너뛰기
series design pm project-management documentation wbs gantt sprint receipt

어떻게 쪼개는가 - PM 문서 가이드 ep.03

PRD가 결재 라인을 한 바퀴 돌고 30페이지로 늘어났을 즈음, 회의실에서 익숙한 질문이 다시 옵니다. “그래서, 언제 끝나죠?” 차터를 가리키며 “11월에 끝납니다”라고 답하는 PM은 거짓말을 하는 것은 아니지만 진실을 다 말한 것도 아닙니다. 11월에 끝나려면 8월에는 OCR이 동작해야 하고, 7월에는 인프라가 올라가 있어야 하고, 6월 셋째 주에는 백엔드 스키마가 정해져 있어야 합니다. 이 사슬을 그려내는 일이 분해입니다.

이 시점의 질문

분해 단계의 문서들은 세 질문에 답해야 합니다.

  • 이 프로젝트는 어떤 작업들로 이루어져 있는가
  • 각 작업이 언제 일어나는가
  • 이번 2주 동안 무엇을 끝낼 것인가

세 질문은 비슷해 보이지만 시간 단위가 다릅니다. 첫 번째는 위계, 두 번째는 시간 축, 세 번째는 짧은 약속이라서 문서도 세 종류가 등장합니다.

WBS(Work Breakdown Structure)

WBS(Work Breakdown Structure) 는 프로젝트 전체를 작업 단위로 위계적으로 쪼개는 문서입니다. 트리 구조라서 최상위 항목은 프로젝트, 중간 항목은 단계, 최하위 항목은 작업 패키지(Work Package) 입니다. 작업 패키지는 한 사람이 책임지고 한 주에서 두 주 안에 끝낼 수 있는 크기를 기준으로 잡습니다.

Receipt v1 WBS 트리 다이어그램. 최상단 박스 "Receipt v1"에서 4개 페이즈로 분기한다. 1.0 인프라(서버 구축, 인증 연동, 모니터링), 2.0 영수증 처리(OCR 통합, 분류 엔진, 신뢰도 표시), 3.0 결재 워크플로(결재 라인 설정, 모바일 알림, 반려 처리), 4.0 출시 준비(베타 테스트, 매뉴얼 작성, 사내 공지). 각 페이즈 아래에 3개의 작업 패키지가 박스로 연결되어 있다. 다이어그램 제목은 「하위를 다 더하면 상위와 같아야 합니다」, 부제는 「100% 규칙 · 빠진 것도 겹친 것도 없어야 일정과 예산이 맞습니다」이다. 최상단 박스에는 0.0 PROJECT, 작업 패키지에는 1.1부터 4.3까지 번호가 붙어 있고 옆에 「작업 패키지 하나가 곧 일정표의 한 줄입니다」라는 주석이 있다. 하단에 「작업 패키지는 담당자 한 명이 2주 안에 끝낼 수 있는 크기로 자릅니다. 더 크면 추정이 틀리고, 더 잘게 자르면 관리 비용이 일을 넘습니다」, 「4.2 매뉴얼 작성과 4.3 사내 공지는 출시 직전에 빠뜨리기 쉬운 항목입니다. WBS에 없으면 일정에도 없습니다」라는 두 문장이 적혀 있다.

WBS의 기본 원칙은 100% 룰(100% rule) 입니다. 한 단계 아래에 있는 작업들을 모두 합치면 상위 항목과 정확히 같아야 한다는 규칙입니다. 빠진 일이 있어도 안 되고, 두 번 들어간 일이 있어도 안 됩니다.

신입 PM이 가장 자주 빠뜨리는 항목은 문서화, 교육, 베타 운영입니다. 이 셋이 빠지면 출시 직전에 누군가 “근데 매뉴얼은 누가 쓰죠?”라고 묻고, 그때부터 일정이 흔들립니다.

WBS는 트리 그림으로 그릴 수도 있고 들여쓰기 텍스트로 적을 수도 있습니다. 들여쓰기 버전은 다음과 같습니다.

1.0 인프라
  1.1 AWS 계정·VPC 설정
  1.2 SSO 인증 연동
  1.3 로그·모니터링 구축

2.0 영수증 처리
  2.1 OCR API 통합
  2.2 분류 엔진 학습
  2.3 신뢰도 UI 처리

3.0 결재 워크플로
  3.1 사내 결재 시스템 연동
  3.2 모바일 푸시 알림
  3.3 반려 및 재신청 처리

4.0 출시 준비
  4.1 베타 테스트 (재무팀 30명)
  4.2 사용자 매뉴얼
  4.3 사내 공지·교육

이렇게 적은 WBS가 다음 문서들의 뼈대가 됩니다. 작업 패키지 하나가 간트 차트의 행이 되고, 견적의 항목이 되고, 보고서의 진척률 칸이 됩니다.

개발자·디자이너 시각

개발자는 WBS에서 의존성을 찾습니다. 1.1이 끝나야 2.1을 시작할 수 있고, 2.2가 끝나야 베타가 가능합니다. 의존성 사슬에서 가장 길게 이어진 경로가 임계 경로(Critical Path) 이고, 그 경로의 작업이 늦으면 프로젝트 전체가 늦습니다. 그래서 개발자는 임계 경로 위의 작업을 맡았을 때 가장 신경을 씁니다.

디자이너는 WBS에서 디자인 작업이 어디에 있는지를 봅니다. WBS가 개발 중심으로만 쪼개져서 디자인이 “2.3 UI 처리” 한 줄로 뭉쳐 들어가 있으면, 디자이너의 작업은 보이지 않게 됩니다. 좋은 PM은 디자인 작업도 별도 항목으로 쪼개 WBS에 넣어둡니다.

간트 차트(Gantt Chart)

WBS가 위계를 그렸다면 간트 차트(Gantt Chart) 는 그 위계를 시간 축에 펼친 그림입니다. 가로축은 시간, 세로축은 작업이고, 각 작업이 막대로 표현되어 막대의 시작과 끝 위치가 일정이 됩니다.

Receipt 프로젝트 간트 차트. 가로축은 2026년 6월부터 11월까지 6개월, 세로축은 WBS의 작업 패키지 12개가 페이즈별로 그룹화되어 있다. 인프라 페이즈는 6월부터 7월 초, 영수증 처리는 7월부터 9월 중순, 결재 워크플로는 8월부터 10월 초, 출시 준비는 9월 중순부터 11월에 배치되어 있다. 작업 간 의존 화살표가 점선으로 표시되어 있고, OCR API 통합, 결재 라인 설정, 베타 테스트 막대가 붉은색으로 칠해져 임계 경로를 나타낸다. 우측에 마일스톤 다이아몬드 3개(개발 시작 6월 1일, 베타 9월 15일, 출시 11월 30일)가 표시되어 있다. 다이어그램 제목은 「순서와 겹침이 보여야 일정입니다」, 부제는 「WBS의 항목 12개를 시간 위에 놓았습니다 · 붉은 막대가 임계 경로입니다」이다. 하단에 「임계 경로는 OCR 통합에서 결재 라인, 베타 테스트로 이어집니다. 여기서 하루 밀리면 출시가 하루 밀립니다」, 「나머지 작업에는 여유가 있습니다. 여유가 있는 곳의 지연은 보고 대상이 아닙니다」라고 적혀 있다.

간트는 한눈에 보입니다. 누가 어떤 작업을 언제 하고 있고 어디가 병목인지가 그림 한 장에 다 들어갑니다. 단점도 둘 있습니다. 첫째, 너무 정밀해 보이는 거짓을 만들어냅니다. 9월 23일에 막대 끝이 인쇄되어 있으면 그날 끝날 것처럼 보이지만, 실제로는 며칠 내지 2주의 오차가 보통입니다. 둘째, 변화에 약합니다. 한 작업이 늦어지면 뒤따르는 작업들의 막대를 다 옮겨야 하는데, 번거롭다고 안 옮기면 간트가 틀린 것이 됩니다.

그래서 요즘은 간트로 대략적인 시간 감각만 잡고, 세부 일정은 스프린트 백로그로 관리합니다.

간트에서 빠뜨리지 말아야 할 두 가지는 의존성과 마일스톤입니다.

  • 의존성(Dependency): 한 작업이 끝나야 다른 작업이 시작될 때 화살표로 잇습니다. 의존성이 표시되면 한 작업이 늦었을 때 어디까지 영향이 미치는지 즉시 보입니다.
  • 마일스톤(Milestone): 작업이 아니라 시점입니다. “개발 시작”, “베타 오픈”, “정식 출시” 같은 것이고, 다이아몬드 모양으로 표시하는 관례가 있습니다. 마일스톤은 완료 기준이 명확한 점이어야 합니다. “베타 오픈”이 마일스톤이면 베타 시작일에 30명의 사용자가 실제 영수증을 올릴 수 있어야 완료로 봅니다.

개발자·디자이너 시각

개발자는 간트에서 겹쳐 그려진 막대를 봅니다. 같은 사람이 동시에 두 막대를 차지하고 있으면 그 일정은 지켜지기 어렵습니다. 보통 한 사람은 한 번에 하나의 일만 하므로 두 막대 중 하나는 늦어집니다. 신입 PM이 자주 하는 실수인데, “병렬로 가면 빠를 줄 알았어요”라고 하지만 사람은 병렬 처리되지 않습니다.

디자이너는 디자인 막대가 개발 막대보다 충분히 앞서 있는지를 봅니다. 디자인이 끝난 다음 개발이 시작되어야 하는데, 둘이 너무 가까이 붙어 있으면 디자인 검토가 끝나기 전에 개발이 시작되고, 나중에 뜯어고치는 비용이 커집니다. 일반적으로 디자인 막대의 끝은 개발 막대의 시작보다 1주에서 2주 앞에 둡니다.

스프린트 백로그(Sprint Backlog)

WBS와 간트가 전체 그림을 그린다면 스프린트 백로그(Sprint Backlog) 는 지금 당장의 2주간에 집중하는 문서입니다. 애자일 환경에서 가장 자주 쓰이는 실행 문서입니다.

스프린트 백로그에는 보통 다음 항목이 들어갑니다.

  • 스프린트 목표: 이번 스프린트에서 달성할 것을 한 문장으로 적습니다
  • 들어간 유저 스토리와 작업 목록
  • 각 작업의 담당자와 추정 시간
  • 상태(To Do / In Progress / Done)
## Sprint 03 (2026.07.13 - 07.24)

**스프린트 목표**: 사용자가 영수증을 사진으로 업로드하고
OCR 결과를 확인·수정할 수 있다 (모바일 한정)

### 백로그
| 스토리 | 작업 | 담당 | 추정(h) | 상태 |
| --- | --- | --- | --- | --- |
| US-01 | 카메라 화면 UI | 디자이너A | 8 | Done |
| US-01 | 카메라 컴포넌트 구현 | 프론트B | 16 | In Progress |
| US-01 | OCR API 연동 | 백엔드C | 12 | In Progress |
| US-01 | 신뢰도 표시 처리 | 프론트B | 6 | To Do |
| US-01 | 인수 테스트 | QA-D | 8 | To Do |

스프린트 백로그는 매일 아침 스탠드업의 기준이 됩니다. 어제 무엇을 했고, 오늘 무엇을 할 것이고, 막힌 것은 무엇인지 표를 보며 이야기합니다. 표 위의 상태가 움직이면 스프린트가 살아 있는 것이고, 움직이지 않으면 어딘가 막혀 있는 것입니다.

스프린트 백로그가 잘 운영되려면 완료의 정의(Definition of Done, DoD) 가 합의되어 있어야 합니다. “구현 끝남”이 Done인지, “QA 통과”가 Done인지, “운영에 배포됨”이 Done인지 팀마다 다르고, 합의가 없으면 같은 표를 보면서 서로 다른 그림을 그립니다.

Receipt 팀의 DoD는 이렇게 정해졌습니다.

**Definition of Done**
- [ ] 코드 리뷰 통과 (2인 이상 승인)
- [ ] 단위 테스트 작성 및 통과 (커버리지 70% 이상)
- [ ] 인수 기준 충족 (PRD 명시 기준)
- [ ] 스테이징 환경에 배포되어 동작 확인
- [ ] 문서 업데이트 (필요 시)

체크리스트를 모두 통과해야 비로소 Done입니다.

개발자·디자이너 시각

개발자는 스프린트 백로그의 추정 시간을 자기 자신에게 던지는 질문으로 받아들입니다. 이 작업이 16시간 안에 끝나는지 묻습니다. 신입 개발자는 낙관적으로, 시니어는 비관적으로 추정하는데, PM이 그 차이를 알고 있어야 백로그가 거짓말을 하지 않습니다.

디자이너는 자기 작업이 스프린트 처음에 배치되어 있는지를 봅니다. 디자인이 스프린트 후반에 있으면 개발이 그 스프린트 안에 따라올 수 없습니다. 보통 디자인은 한 스프린트 앞서 끝나야 합니다. 즉, 이번 스프린트의 개발에 들어갈 화면은 지난 스프린트에 디자인이 끝났어야 합니다.

세 문서는 같은 작업을 다른 단위로 자릅니다.

문서자르는 기준다루는 시간문제 없이 돌아가는지 보는 법
WBS위계프로젝트 전체100% 룰이 지켜지는가
간트 차트시간 축월과 주지연이 뒤 작업에 반영되는가
스프린트 백로그실행 단위2주상태 칸이 매일 움직이는가

분해는 합의의 도구입니다

PMBOK은 분해를 계획 프로세스 그룹(Planning Process Group)의 핵심 활동으로 정의합니다. 그러나 분해의 진짜 가치는 일정표를 만드는 것이 아니라 팀이 같은 그림을 보게 하는 것입니다.

WBS를 함께 그리는 워크숍을 해보면 알게 됩니다. 같은 PRD를 보고도 사람마다 머릿속에서 작업을 다르게 쪼개고 있습니다. 워크숍에서 그 차이가 드러나고 합의를 해야 비로소 같은 프로젝트가 됩니다. 그래서 WBS는 PM이 혼자 책상 앞에서 그리는 문서가 아니라, 회의실에서 포스트잇으로 그리고 사진을 찍어 디지털로 옮기는 문서입니다.

간트와 백로그도 마찬가지입니다. PM이 일방적으로 늘어놓는 일정은 거짓말이 되어버리기 일쑤입니다. 일정은 그렇게 산정한 사람이 책임져야 합니다.

참고 자료

  • Project Management Institute. (2019). Practice Standard for Work Breakdown Structures – Third Edition. PMI.
  • Schwaber, K., & Sutherland, J. (2020). The Scrum Guide. https://scrumguides.org
  • Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.

다음 편 예고

ep.04 - 누가 책임지는가: 분담을 위한 문서들

작업이 쪼개졌으니 이제 사람에게 붙일 차례입니다. RACI 매트릭스로 책임 라인을 그리고, 리소스 플랜으로 사람의 시간을 잡고, 커뮤니케이션 플랜으로 누구에게 무엇을 언제 알릴지를 정합니다.