12월 첫 주, Receipt v1이 정식 출시된 지 두 주가 지났습니다. 신청 건수는 안정적으로 늘고 있고, 재무팀 사람들은 이제 영수증 정리에 야근을 하지 않는다고 말합니다. 회의실에 모인 팀은 어딘가 후련하고 어딘가 허전한 채로 “이제 끝난 거죠?”라고 묻습니다. 끝나지 않은 일이 하나 남아 있습니다. 끝났다는 사실을 문서로 남기는 일입니다.
이 시점의 질문
종결 단계의 문서들은 세 가지 질문에 답해야 합니다.
- 약속한 것과 만든 것은 일치하는가
- 이 과정에서 무엇을 배웠는가
- 그 배움을 다음 사람이 어떻게 받을 수 있는가
세 질문에 답하지 못한 채 프로젝트를 닫으면, 그 프로젝트는 끝났지만 사라지지 않은 채로 남습니다. 같은 실수가 다음 프로젝트에서 다시 일어나는 이유가 여기에 있습니다.
종료 보고서(Closure Report)
종료 보고서(Closure Report) 는 프로젝트가 약속한 것과 만든 것을 대조하는 문서입니다. ep.01 왜 시작하는가의 차터를 한 번 더 꺼내 그 옆에 실제 결과를 적습니다.
기본 구조는 다음과 같습니다.
- 프로젝트 개요와 기간
- 차터의 목표 vs 실제 결과(정량 비교)
- 범위 달성: PRD 기능 목록과 실제 구현을 비교합니다
- 일정·예산 실적
- 미해결 사항과 후속 과제
- 인수인계 정보
- 공식 종료 선언과 서명
가장 중요한 칸은 차터 목표 vs 실제 결과입니다. ep.01에서 적었던 측정 가능한 목표가 진짜로 측정 가능했는지 여기서 드러납니다.
## Receipt v1 종료 보고서
**기간**: 2026.06.01 – 2026.12.05 (계획 2026.11.30 + 5일)
**예산 집행**: 1.32억원 (계획 1.2억원 + 10%)
**상태**: 출시 완료
### 차터 목표 vs 실제 결과
| 목표 | 약속 | 결과 | 평가 |
| --- | --- | --- | --- |
| 처리 시간 | 평균 30분 이내 | 평균 26분 | 달성 |
| 재무 대조 작업 | 70% 감소 | 64% 감소 | 미달 |
| 사용자 만족도 | 4.0/5.0 이상 | 4.2/5.0 | 달성 |
| OCR 정확도 | 90% | 87% | 미달 |
### 범위
- 차터의 범위: 4개 항목 모두 구현 완료
- 범위 외에서 추가: CR-03 법인카드 매칭 (별도 승인)
### 미해결 사항
- OCR 정확도 87% → 90% 도달은 v1.1에서 추진 (사내 영수증 학습)
- 해외 출장비는 v2 범위 (차터 범위 외 그대로 유지)
### 인수인계
- 운영 책임: IT 운영팀 (2026.12.06부터)
- 유지보수 SLA: 영업시간 4시간 응답
- 운영 매뉴얼: [링크]
- 모니터링 대시보드 권한: 운영팀 + PM 잔여 1년종료 보고서에서 신입 PM이 자주 하는 실수는 미달 항목을 숨기는 것입니다. 64%를 약 70%라고 적거나 87%를 90% 수준이라고 적으면, 왜 실패했는지 배우는 기회가 사라집니다. 미달은 미달로, 초과는 초과로 적어야 합니다.
개발자·디자이너 시각
개발자는 종료 보고서에서 기술 부채와 미해결 이슈가 명시되는지를 봅니다. 출시 직전에 임시로 우회한 코드가 영구히 남으면 다음 사람이 고생합니다. 종료 보고서에 “v1.1에서 정리할 임시 처리 N건”이 명시되면 그 목록이 공식 부채가 되어 다음 작업으로 잡힙니다.
디자이너는 디자인 시스템에 추가된 컴포넌트가 기록되는지 봅니다. Receipt를 만들며 생긴 새 카드 패턴, 새 인풋 상태, 새 다이얼로그가 디자인 시스템에 공식 등재되어야 다음 프로젝트가 활용할 수 있습니다.
회고(Retrospective)
회고(Retrospective) 는 팀이 어떻게 일했는지를 돌아보는 문서이자 회의입니다. 종료 보고서가 결과를 다룬다면 회고는 과정을 다룹니다.
회고 형식은 여러 가지가 있지만 가장 자주 쓰이는 둘은 KPT와 4L입니다.
KPT: Keep / Problem / Try
- Keep: 잘 됐던 것, 계속 유지하고 싶은 것
- Problem: 안 됐던 것, 문제였던 것
- Try: 다음 프로젝트에서 시도해 볼 것
4L: Liked / Learned / Lacked / Longed for
- Liked: 좋았던 것
- Learned: 배운 것
- Lacked: 부족했던 것
- Longed for: 있었으면 했던 것
KPT는 액션 지향이고 4L은 감정과 경험 지향입니다. 짧은 프로젝트에는 KPT가, 긴 프로젝트에는 4L이 더 잘 맞습니다. Receipt는 6개월이라 KPT로 진행합니다.
좋은 회고의 조건은 두 가지입니다.
- 솔직함이 가능한 환경: 회고가 책임 추궁으로 변하면 다음부터 누구도 솔직히 말하지 않습니다. PM이 가장 먼저 자기가 놓친 것을 말해야 분위기가 열립니다.
- 액션으로의 전환: Keep과 Problem만 모이면 한탄 회의로 끝납니다. Try 칸이 살아 있어야 다음 프로젝트가 달라집니다.
회고에서 가장 위험한 패턴은 블레임 게임입니다. “A씨가 OCR 일정을 늦췄어요”는 회고 발언이 아니고, “OCR 일정 추정 방식이 OCR 같은 신규 영역에는 적합하지 않았어요”가 회고 발언입니다. 사람이 아니라 시스템과 프로세스를 향해 말해야 합니다.
회고록의 형식은 단순합니다.
## Receipt v1 프로젝트 회고
**일시**: 2026-12-12 (금) 15:00-17:00
**진행**: 외부 퍼실리테이터 (객관성 확보)
**참석**: 9명 (PM, 개발 4, 디자인 1, QA 1, 스폰서 대리 1, 사용자 대표 1)
### Keep (계속할 것)
- [5표] 격주 스폰서 1:1 미팅 유지. 의사결정이 하루 안에 남
- [4표] 회의록의 결정·액션 칸 분리. 누가 뭘 하는지 안 잊음
- [3표] 디자인 검토를 스프린트 직전에 배치
- [2표] OCR 신뢰도 UI 패턴. 사용자가 검토할 곳을 알게 됨
### Problem (문제였던 것)
- [6표] OCR 학습 데이터 부족을 8월에야 발견. 베이스라인이 1주차에 없었음
- [5표] 보안팀 검토 일정을 늦게 잡음. 3주를 대기로 보냄 (R-02 현실화)
- [3표] 범위 외 변경 요청의 영향 분석 시간 부족. CR-03에 3주 걸림
- [2표] 베타 사용자 모집 안내 늦음. 첫 주 참여가 절반밖에 안 됨
### Try (시도할 것)
- [7표] 다음 프로젝트는 1주차에 베이스라인 데이터 확보 필수
- [5표] 보안팀과 킥오프 시점 사전 미팅 (D-7 이내)
- [4표] 변경 요청 표준 영향 분석 템플릿 만들기 (PM이 주도)
- [3표] 베타 모집 D-30 시작. 공지 두 번, 리마인드 한 번투표(dot voting) 점수를 적는 이유는 우선순위를 정하기 위해서입니다. Try가 10개여도 다 시도할 수 없으니, 가장 공감대가 큰 두세 개부터 다음 프로젝트에 가져갑니다.
레슨런(Lessons Learned)
회고가 팀이 무엇을 배웠는지를 다룬다면, 레슨런(Lessons Learned) 은 조직이 무엇을 받을 것인지를 다룹니다. 팀 안에 남으면 회고이고, 조직 차원의 다음 프로젝트에 전해지면 레슨런입니다.
레슨런은 보통 카드형으로 정리합니다. 한 카드에 상황·교훈·적용을 적습니다. 조직의 위키나 PMO 데이터베이스에 쌓이고, 다음 프로젝트의 PM이 비슷한 상황을 만났을 때 검색합니다.
좋은 레슨런은 검색이 되는 형식으로 적습니다. 누군가 “외부 API 도입”이나 “베타 운영 모집”이라고 검색했을 때 걸려야 하므로, 카테고리 라벨과 태그를 반드시 답니다.
Receipt에서 정리한 레슨런 일부는 이렇게 적힙니다.
## L-01 · 외부 OCR API의 학습 데이터 부족 위험
**카테고리**: 외부 의존성
**상황**: Receipt는 외부 OCR API를 도입했고, 일반 한글 인식률은 95%였으나
우리 도메인(영수증) 정확도는 78%로 시작. 5개월간 후처리 룰과 학습 데이터로 87%까지 끌어올림.
**교훈**:
외부 API 벤더가 광고하는 일반 성능과 우리 도메인 성능은 다를 수 있다.
특히 도메인 특수성이 큰 영역(영수증·의료·법률 등)에서 격차가 크다.
**적용 (다음 프로젝트에)**:
- 외부 API 도입 시 우리 도메인 데이터 1,000건 테스트를 1주차에 진행
- 일반 성능이 아니라 우리 도메인 성능을 기준으로 의사결정
- API 정확도가 80% 미만이면 후처리 비용도 견적에 포함
**태그**: 외부API, OCR, 도메인특화, 데이터검증
**작성자**: 파이 (Receipt PM)
**작성일**: 2026-12-15레슨런이 검색 가능한 형식으로 누적되면 조직에는 프로젝트 도서관이 생깁니다. 새 PM이 첫 프로젝트를 시작할 때 이 도서관에서 비슷한 상황을 검색하고, 남이 겪은 시행착오를 처음부터 피할 수 있습니다.
개발자·디자이너 시각
개발자는 레슨런에서 기술 의사결정의 배경을 봅니다. 단순히 “Redis를 썼다”가 아니라 “세션 저장소로 Redis를 선택한 이유와 후회한 점”이 적혀 있어야 다음 사람이 같은 결정을 더 잘 합니다.
디자이너는 사용자 피드백의 진짜 원인을 봅니다. “사용자가 신뢰도 낮은 필드를 못 알아챘다”가 단순한 디자인 실수인지, “사용자가 모바일을 한 손에 들고 쓰는데 노란색 배경이 햇빛 아래서 안 보였다”인지가 다음 디자인의 출발점을 바꿉니다.
세 문서는 남는 곳과 읽는 사람이 다릅니다.
| 문서 | 대조하거나 모으는 것 | 남는 곳 | 읽는 사람 |
|---|---|---|---|
| 종료 보고서 | 차터의 약속과 실제 결과 | 프로젝트 문서함 | 스폰서와 인수 담당 |
| 회고 | 팀이 일한 방식 | 팀 위키 | 같은 팀의 다음 스프린트 |
| 레슨런 | 조직에 전할 교훈 | PMO 데이터베이스 | 다른 프로젝트의 PM |
끝낼 줄 아는 PM이 좋은 PM입니다
PMBOK은 종결 프로세스 그룹(Closing Process Group)을 따로 두고 프로젝트나 페이즈 종결(Close Project or Phase)을 핵심 활동으로 정의합니다. 실무에서는 이 단계가 가장 자주 생략됩니다. 출시 후의 안도감과 새 프로젝트의 압력 사이에서 종결 문서는 나중에 하자는 작업으로 밀려납니다.
그러나 종결을 제대로 하지 않으면 프로젝트는 끝나도 흔적이 남지 않습니다. 같은 회사 같은 팀에서 같은 실수가 3년 뒤에 다시 일어나는 이유는 종결 문서가 없어서이지 사람이 어리석어서가 아닙니다.
좋은 PM은 시작도 잘하지만 끝도 잘 닫습니다. 차터에 서명을 받았듯 종료 보고서에도 서명을 받습니다. 첫 회의록을 남겼듯 마지막 회고록도 남깁니다. 첫 페이지처럼 마지막 페이지도 누군가 한 번 더 읽을 가치가 있는 문서가 되어야 합니다.
시리즈를 닫으며
ep.00 왜 하나를 더 쓰는가에서 시작해 여기까지 왔습니다. 정렬·정의·분해·분담·통제·가시화·종결, 일곱 가지로 23개의 문서를 다루었습니다.
이 시리즈가 PM 문서를 제출하기 위한 자료에서 결정을 남기는 문서로 보는 데 도움이 되었으면 합니다. 문서는 양식이 아니라 프로젝트에서 팀이 함께 만들어낸 결정의 흔적이고, 그 흔적이 다음 사람의 출발점이 됩니다.
가상의 프로젝트 Receipt v1은 여기서 끝나지만, 이 시리즈를 읽은 누군가의 첫 프로젝트는 어디선가 시작되고 있을 것입니다. 첫 차터에 왜 시작하는가를 한 문장으로 적는 그 순간이 ep.01의 그 회의실과 같은 풍경입니다.
참고 자료
- Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition. PMI.
- Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
- Kerth, N. L. (2001). Project Retrospectives: A Handbook for Team Reviews. Dorset House.