본문으로 건너뛰기
series design pm project-management documentation status-report burndown dashboard meeting-notes receipt

잘 가고 있는가 - PM 문서 가이드 ep.06

화요일 오후 4시에 재무이사가 메신저로 “프로젝트 잘 되고 있어요?”라고 묻습니다. 거의 같은 시간에 백엔드 리드 A씨가 “이번 스프린트 어디까지 됐죠?”라고 묻고, 한 시간 뒤에는 사내 슬랙에서 누군가 “Receipt 베타 언제부터예요?”라고 묻습니다. 같은 질문처럼 보이지만 답해야 하는 내용이 모두 다릅니다. PM이 일일이 답하면 한 시간을 잃지만, 같은 그림이 문서로 살아 있으면 링크 하나만 보내면 됩니다.

이 시점의 질문

가시화 단계의 문서들은 청중에 따라 다른 질문에 답합니다.

  • 스폰서에게는 지난주 대비 어떻게 갔는가
  • 팀에게는 이번 스프린트를 끝낼 수 있는가
  • 경영진에게는 이 프로젝트가 약속한 가치를 만들고 있는가
  • 미래의 팀에게는 그때 무엇을 결정했는가

네 가지 청중에 네 가지 문서가 대응합니다. 상태 보고서, 번다운, KPI 대시보드, 회의록입니다.

상태 보고서(Status Report)

상태 보고서(Status Report) 는 주간 단위 압축본입니다. 스폰서와 이해관계자가 한 페이지로 프로젝트 상태를 읽을 수 있어야 합니다. 잘 만든 상태 보고서는 받는 사람이 5분 안에 읽고 추가 질문 두 개쯤 떠올릴 만한 분량입니다.

기본 구조는 다음과 같습니다.

  • 헤더: 프로젝트명, 보고일, PM 이름
  • 종합 상태: 빨강 / 노랑 / 초록(RAG status)
  • 이번 주 한 일
  • 다음 주 할 일
  • 이슈와 리스크(Top 3)
  • 결정 필요 사항
  • 마일스톤 진척

빨강·노랑·초록의 기준은 미리 합의되어 있어야 합니다. 느낌으로 색을 정하면 일주일 뒤에 색이 흔들립니다. Receipt 팀의 합의는 다음과 같습니다.

**Status Color 기준**

GREEN: 일정·범위·예산 모두 ±10% 이내, 미해결 High 이슈 0건
YELLOW: 일정 또는 범위 10~20% 변동, 또는 High 이슈 1~2건
RED: 일정 또는 범위 20% 이상 변동, 또는 High 이슈 3건 이상

상태 보고서의 함정은 RED를 RED로 적기 어렵다는 점입니다. 보고를 받는 사람이 화내는 것을 두려워한 신입 PM은 RED를 YELLOW로 적습니다. 그러면 한 달 뒤 갑자기 RED가 되고, 스폰서는 “지난주까지 YELLOW였잖아요”라며 더 화를 냅니다. RED는 일찍 띄울수록 도움을 빨리 받습니다.

## Receipt v1 · 주간 상태 보고서
**보고일**: 2026-08-19 (Week 11)
**PM**: 파이
**종합 상태**: YELLOW

### 한 줄 요약
OCR 정확도가 84%로 목표(90%)에 미달. 베타 일정에 영향 가능. 보안팀 검토는 9월 1일 확정.

### 이번 주 한 일
- OCR 분류 엔진 정규식 후처리 적용, 정확도 78% → 84%
- 결재 시스템 연동 첫 통합 테스트 통과
- 보안 검토 사전 미팅 (8/15)

### 다음 주 할 일
- OCR 정확도 88%+ 목표로 학습 데이터 추가
- 모바일 푸시 알림 베타 환경 배포
- 베타 사용자 30명 모집 안내

### Top 3 이슈/리스크
1. R-01 OCR 정확도 (현 84%, 목표 90%) — Mitigation 진행 중
2. R-02 보안팀 검토 일정 — 9월 1일 확정, 영향 줄어듦
3. I-08 모바일 사파리 카메라 권한 (Low) — 다음 주 해결

### 결정 필요 사항
- CR-03 법인카드 매칭 추가 건 (재무이사 8/12 요청)
  → 8월 26일까지 영향 분석 완료 예정

개발자·디자이너 시각

개발자가 상태 보고서를 받으면 Top 3 이슈 칸을 봅니다. 자기 영역의 이슈가 거기에 있는지, 없으면 왜 빠졌는지 묻고 싶어집니다. PM이 개발자의 영역을 숨기면 개발자는 PM이 자기 일을 모른다고 느낍니다.

디자이너는 디자인 작업이 한 일과 할 일 목록에 명시되는지 봅니다. 개발 중심으로만 쓰인 보고서는 디자이너에게 자기들은 빠진 사람이라는 메시지를 줍니다.

번다운 차트(Burndown Chart)

번다운 차트(Burndown Chart) 는 스프린트 단위 추세를 보여주는 차트입니다. 이상선과 실제선이 만나야 스프린트가 정상이고, 실제선이 위로 멀어지면 그 스프린트는 위험합니다.

가로축은 시간(스프린트 내 일자), 세로축은 남은 작업량(스토리 포인트 또는 시간)입니다. 시작점은 스프린트 전체 작업량이고, 끝점은 0이 되어야 합니다.

Receipt Sprint 03의 번다운 차트. 가로축은 2주 스프린트의 일자 10일, 세로축은 남은 포인트 0에서 40. 두 개의 선이 있다: 이상선(점선, 40에서 0까지 균등하게 내려가는 직선)과 실제선(실선, 처음 3일은 이상선 위에서 시작해 5일째에 이상선과 만났다가 다시 위로 올라가고 8일째 급격히 떨어진 뒤 마지막 날 5포인트를 남기고 끝남). 우측 상단에 스프린트 정보(Sprint 03, 2026.07.13-07.24, 목표 40pt 완료 35pt)가 적혀 있다. 7일차에 작은 별 표시가 있어 스코프 변경(2포인트 추가)이 일어났음을 나타낸다. 하단에는 일별 작업 완료량을 막대로 표시한 작은 부속 차트가 있다. 다이어그램 제목은 「선이 위에 있으면 늦고, 아래에 있으면 빠릅니다」, 부제는 「Sprint 03 · 남은 포인트를 매일 찍습니다」이다. 가로축 라벨은 D0부터 D10까지이고 범례는 이상선, 실제 남은 포인트, 스코프 변경, 일별 완료 포인트이며 스코프 변경 표식 옆에 「스코프 +2 pt」라고 적혀 있다. 하단 막대의 일별 완료 포인트는 2, 2, 3, 4, 9, 1, 0, 9, 4, 3이다. 하단에 「D6에서 D7 사이에 멈춘 것은 스코프가 늘어서가 아니라 리뷰 대기가 쌓여서였습니다. 선만 보면 원인은 모릅니다. 막대와 같이 봅니다」라고 적혀 있다.

번다운에서는 기울기를 가장 먼저 봅니다. 실제선의 기울기가 이상선보다 완만하면 작업이 빠지지 않는 상태입니다. 신입 PM은 마지막 이틀에 기울기가 갑자기 가팔라지는 cliff 패턴을 보고 안심하기도 하는데, 그 패턴은 보통 Done의 기준을 느슨하게 적용한 결과입니다. 진짜 Done이 아니라 제출만 한 작업이 마지막에 몰리면 다음 스프린트에서 다시 불려옵니다.

번다운의 변형으로 번업(Burnup) 차트가 있습니다. 번다운이 남은 작업을 그린다면 번업은 완료한 작업을 누적해 그립니다. 스코프가 자주 변경되는 프로젝트에서는 번업이 더 정확합니다. 스코프 변경이 일어나면 목표선이 위로 올라가는 것이 보이기 때문입니다.

개발자·디자이너 시각

개발자는 번다운에서 자기 작업이 어디에 있는지를 봅니다. 자기 작업이 마지막 이틀에 몰려 있으면 그 작업은 끝나지 않습니다. 작업이 스프린트 전반에 고르게 퍼져 있어야 건강한 번다운입니다.

디자이너는 디자인 검토 시간이 추정에 들어갔는지를 봅니다. 디자인 검토는 개발 완료 후에 일어나고 보통 하루에서 이틀이 걸립니다. 이 시간이 추정에서 빠지면 디자이너는 스프린트 마지막 날 정신없이 검토합니다.

KPI 대시보드(KPI Dashboard)

KPI 대시보드(KPI Dashboard) 는 실시간 단면을 보여줍니다. 상태 보고서가 주간이라면 대시보드는 상시입니다. 경영진이 언제 들어오든 한 화면에서 핵심 숫자를 확인할 수 있어야 합니다.

대시보드는 적게 보여야 합니다. 한 화면에 12개 숫자를 넣으면 아무 숫자도 보지 않으므로, 핵심 KPI를 4개에서 6개로 압축해야 합니다.

Receipt v1 KPI 대시보드 mockup. 화면 상단에 4개의 큰 KPI 카드가 가로로 배치되어 있다. 첫 번째 카드: 누적 사용자 247명(목표 300명 대비 82%, 초록 화살표 위), 두 번째 카드: 평균 처리 시간 28분(목표 30분 대비 달성, 초록), 세 번째 카드: OCR 정확도 84%(목표 90%, 노랑 화살표 옆), 네 번째 카드: 만족도 4.1/5(목표 4.0, 초록). 그 아래 좌측에는 일별 신청 건수 라인 그래프, 우측에는 마일스톤 진척 막대 4개(인프라 100%, 영수증 처리 88%, 결재 75%, 출시 준비 30%)가 있다. 하단에는 최근 이슈 3건과 그 상태가 미니 리스트로 표시되어 있다. 다이어그램 제목은 「숫자 넷이면 회의가 짧아집니다」, 부제는 「Receipt v1 · 2026.09.30 기준 · 목표 대비로 읽습니다」이다. 라인 그래프의 제목은 「일별 신청 건수 · 최근 14일」이고 세로축은 0에서 60, 가로축은 9/17부터 9/30까지다. 최근 이슈 3건은 HIGH 「한글 영수증 OCR 정확도 78% 구간 발생」(In Progress, 백엔드), MED 「iOS 16 이하에서 카메라 권한 팝업 미표시」(Triaged, 프론트엔드), LOW 「카테고리 드롭다운 정렬 순서 문의」(Resolved, 디자이너)이다. 하단에 「OCR 정확도만 노란색입니다. 한 화면에서 어디를 봐야 하는지가 색으로 정해져야 대시보드입니다」라고 적혀 있다.

대시보드에는 경향성(trend) 이 함께 보여야 합니다. 84%라는 숫자만 있으면 그 숫자가 좋은지 나쁜지 모릅니다. 지난주 78%에서 이번 주 84%로 올랐다는 정보가 있어야 상승 추세가 보이고, 화살표 하나로도 충분합니다.

대시보드의 또 다른 함정은 집계 단위입니다. 누적 사용자 247명이 오늘 247명인지 프로젝트 시작 이래 247명인지 명확하지 않으면 숫자는 거짓말이 됩니다. 작은 글씨로 “2026-08-19 14:00 KST 기준” 같은 시점이 적혀 있어야 합니다.

개발자·디자이너 시각

개발자는 대시보드를 보고 이 숫자를 어디서 가져왔는지 묻고 싶어 합니다. OCR 정확도 84%가 어느 테이블 어느 칼럼의 합산인지 알아야 그 숫자를 신뢰할 수 있습니다. 좋은 대시보드에는 각 숫자의 출처와 계산식이 마우스 오버나 별도 문서에 적혀 있습니다.

디자이너는 대시보드의 시각적 위계를 봅니다. KPI 카드 네 개 중 가장 중요한 하나가 먼저 눈에 들어와야 합니다. 모두 같은 크기면 우선순위가 사라지므로, 색·크기·여백의 차이로 PM이 가장 강조하고 싶은 숫자가 한 번에 보여야 합니다.

회의록(Meeting Notes)

상태 보고서·번다운·대시보드가 상황을 그린다면 회의록(Meeting Notes) 은 결정을 기록합니다. 미래의 누군가가 “그때 왜 이렇게 결정했어요?”라고 물었을 때 답하는 문서입니다.

좋은 회의록은 결정과 액션을 중심에 둡니다. 누가 무엇을 말했는지 받아쓰는 회의록은 가치가 낮습니다. 회의에서 결정된 것과 누가 무엇을 하기로 했는지가 명확히 분리되어 적혀야 합니다.

기본 구조는 다음과 같습니다.

# Receipt v1 · 주간 동기화 회의록
**일시**: 2026-08-19 (화) 14:00-15:00
**장소**: 회의실 B / Google Meet
**참석**: 파이(PM), A씨(BE), C씨(FE), D씨(디자인), E씨(QA), 재무팀장

## 결정 사항
| ID | 내용 | 결정자 |
| --- | --- | --- |
| D-19 | CR-03 법인카드 매칭 영향 분석을 8월 26일까지 PM이 정리 | PM·재무팀장 |
| D-20 | 모바일 사파리 카메라 권한 이슈는 다음 스프린트로 이월 | 팀 합의 |

## 액션 아이템
| ID | 내용 | 담당 | 기한 |
| --- | --- | --- | --- |
| A-31 | OCR 학습 데이터 1,000장 추가 라벨링 발주 | A씨 | 08-23 |
| A-32 | 베타 모집 사내 공지 초안 작성 | PM | 08-22 |
| A-33 | 결재 시스템 연동 테스트 시나리오 추가 | E씨 | 08-26 |

## 논의 메모
- OCR 정확도 84% 도달. 90% 목표는 사내 영수증 학습 후 재평가.
- 베타 사용자 30명 중 재무팀이 15명, 일반팀 15명으로 분배.

## 다음 회의
2026-08-26 (화) 14:00 · 같은 장소

회의록의 결정과 액션 두 칸이 잘 되어 있으면, 한 달 뒤에 “그때 뭐 결정했더라”라는 질문에 30초 안에 답할 수 있습니다.

회의록에서 논의 메모는 보조 정보이고, 중심은 결정과 액션입니다. 신입 PM이 자주 하는 실수가 논의 메모를 길게 쓰고 결정과 액션을 빼먹는 것입니다. 그러면 회의록은 읽기 좋은 일기가 되지만 프로젝트의 기록은 되지 못합니다.

개발자·디자이너 시각

개발자는 회의록에서 자기 이름이 들어간 액션 아이템을 가장 먼저 봅니다. 회의에 참석하지 못한 개발자도 회의록만 읽으면 다음에 무엇을 해야 하는지가 명확해야 합니다. 액션은 개인에게 떨어져야 합니다. 팀에게 떨어지면 결국 아무도 안 합니다.

디자이너는 결정 사항이 디자인에 영향을 주는지를 봅니다. D-19처럼 기능 추가가 결정되면 디자이너는 즉시 화면 작업 일정에 반영해야 합니다. 회의록이 결정 사항을 명시하지 않으면 디자이너는 한 주 뒤에 “그게 결정된 거였어요?”라고 묻게 됩니다.

네 문서는 청중과 주기가 서로 다릅니다.

문서청중주기답하는 것
상태 보고서스폰서와 이해관계자주간지난주 대비 어떻게 갔는가
번다운 차트팀매일이번 스프린트를 끝낼 수 있는가
KPI 대시보드경영진과 모두실시간약속한 가치가 만들어지고 있는가
회의록미래의 팀회의마다그때 무엇을 결정했는가

가시화는 신뢰의 인프라입니다

PMBOK의 감시 및 통제 활동에는 작업 성과 보고(Work Performance Reporting)가 들어 있습니다. 책에서는 보고서를 경영진에게 올리는 산출물로 그리지만, 현장에서 더 중요한 것은 팀이 같은 그림을 보는 것입니다.

스폰서에게는 상태 보고서가 가고, 팀에게는 번다운이 보이고, 모두에게 대시보드가 열려 있고, 회의록은 사내 위키에 살아 있으면 모두가 같은 그림을 봅니다. 그러면 PM은 같은 질문에 다섯 번 답하지 않아도 됩니다. PM이 같은 답을 다섯 번 하고 있다면 가시화가 부족해서입니다.

가시화의 진짜 목적은 통제가 아니라 신뢰입니다. 스폰서가 PM을 신뢰하는 이유는 PM이 알아서 잘하기 때문이 아니라 상태가 늘 보이기 때문입니다. 상태가 보이지 않으면 나쁜 상태로 추정할 수밖에 없습니다.

참고 자료

  • Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition. PMI.
  • Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall.
  • Few, S. (2013). Information Dashboard Design: Displaying Data for At-a-Glance Monitoring (Second Edition). Analytics Press.

다음 편 예고

ep.07 - 무엇을 남기는가: 종결을 위한 문서들

프로젝트의 마지막 날도 문서로 끝납니다. 종료 보고서로 약속과 결과를 대조하고, 회고로 팀의 배움을 정리하고, 레슨런으로 조직에 무엇을 남길지 결정합니다. 끝낼 줄 아는 PM이 좋은 PM입니다.