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

왜 하나를 더 쓰는가 - PM 문서 가이드 ep.00

PM 문서를 가르치는 자료는 이미 많습니다. PMBOK은 두꺼운 책이고, 회사마다 템플릿이 있고, 인터넷에는 양식이 가득합니다. 그런데도 하나를 더 쓰는 이유가 있습니다. 양식을 늘어놓는 가이드는 많지만, 각 양식이 어떤 결정을 담는지 말해주는 가이드는 잘 없기 때문입니다.

문서는 양식이 아니라 결정의 흔적입니다

신입 PM이 흔히 빠지는 함정은 문서를 제출용 양식으로 보는 것입니다. 차터를 만들어 결재를 받고, PRD를 써서 회의에 올리고, 보고서를 작성해 스폰서에게 보냅니다. 양식이 다 채워지면 일을 다 한 것처럼 느껴집니다.

그러나 좋은 문서는 제출되는 것이 아니라 결정의 흔적이 되는 것입니다. 차터에 서명을 받는 행위는 “이 프로젝트를 해도 좋은가”라는 결정의 기록이고, PRD를 쓰는 행위는 “무엇을 만들지”라는 결정의 기록입니다. 양식은 결정을 담는 그릇일 뿐이고, 그릇 자체가 가치는 아닙니다.

그래서 이 시리즈는 어떤 양식을 채워야 하는지보다 그 시점에 어떤 결정이 필요한지를 먼저 묻습니다. 일곱 단계에서 내리는 결정을 미리 늘어놓으면 이렇습니다.

단계그 단계에서 내리는 결정결정을 담는 문서
정렬이 프로젝트를 해도 좋은가프로젝트 차터
정의무엇을 만들고 무엇을 만들지 않는가PRD
분해어떤 단위로 언제까지 만드는가WBS, 간트 차트
분담누가 책임지고 누가 의견을 내는가RACI 매트릭스
통제무엇을 감수하고 무엇을 바꾸는가리스크 레지스터, 변경 관리 대장
가시화지금 상태를 누구에게 어떻게 알리는가상태 보고서, KPI 대시보드
종결무엇을 남기고 무엇을 닫는가종료 보고서, 레슨런

가상의 프로젝트 하나를 함께 따라갑니다

추상적으로 말하면 글이 흐릿해지므로, 이 시리즈는 가상의 프로젝트 Receipt를 처음부터 끝까지 따라갑니다.

Receipt는 한 회사의 사내 비용 정산 자동화 도구 v1입니다. 300명 규모의 회사에서 쓰는 모바일과 웹 서비스로, 영수증을 사진으로 찍어 올리면 OCR이 금액·날짜·가맹점을 추출합니다. 추출한 내역을 카드 명세서와 자동으로 맞춰보고, 결재 라인을 거쳐 정산까지 이어집니다.

이해관계자는 다섯 그룹입니다.

  • 재무팀: 영수증을 가장 많이 다루는 핵심 사용자입니다.
  • 일반 사원: 영수증을 올리는 최종 사용자입니다.
  • 팀장 그룹: 결재자입니다.
  • IT 운영팀: 보안과 인프라를 지키는 게이트키퍼입니다.
  • 경영진: 비용 가시성에 관심이 있습니다.

기간은 2026년 6월부터 11월까지 6개월입니다. 팀은 PM 한 명, 백엔드 둘, 프론트엔드 하나, 디자이너 하나, QA 하나로 꾸리고, 보안 검토자 한 명이 부분 투입됩니다.

ep.01부터 ep.07까지 이 프로젝트를 시간 순서로 따라가며, 매 시점에 PM의 책상 위에 놓이는 질문과 그 질문에 답하는 문서를 풀어 적습니다.

시리즈의 일곱 단계

일곱 편이 각각 하나의 단계를 맡습니다. 편마다 그 단계의 핵심 질문과, 그 질문에 답하는 문서 서너 개를 다룹니다.

정렬·정의·분해·분담·통제·가시화·종결을 한 줄로 늘어놓으면 PM 일의 큰 그림이 보입니다.

PM 문서 가이드 시리즈 흐름. 7개의 단계가 가로로 화살표로 연결되어 있다. 정렬(차터, BRD, 이해관계자), 정의(PRD, 유저 스토리), 분해(WBS, 간트), 분담(RACI, 커뮤니케이션), 통제(리스크, 이슈), 가시화(상태, 번다운, 대시보드), 종결(종료, 회고, 레슨런). 각 단계 박스는 해당 편의 accent 색상을 가지고 있고, 그 아래 그 단계가 답하는 핵심 질문(왜·무엇·어떻게 쪼개는가·누가·무엇이 흔들리는가·잘 가고 있는가·무엇을 남기는가)이 적혀 있다. 다이어그램 제목은 「문서는 질문 순서대로 나옵니다」, 부제는 「각 단계는 앞 단계의 답을 전제로 합니다. 순서를 건너뛰면 뒤 문서를 쓸 근거가 없어집니다」이다. 하단에 「앞의 넷은 계획, 뒤의 셋은 실행입니다. 계획 문서가 부실하면 실행 문서는 비교할 기준이 없습니다」라는 문장이 적혀 있다.

신입 PM과 옆자리 동료들

이 시리즈의 일차 독자는 신입 PM입니다. 그런데 각 편의 끝에는 「개발자·디자이너 시각」이라는 짧은 단락을 붙였습니다.

덧붙이면 이 시리즈의 PM은 프로젝트 매니저(Project Manager) 입니다. 한국에서는 기획자나 PO(Product Owner)로도 불리는 프로덕트 매니저(Product Manager) 를 PM이라고 부르는 경우가 많은데, 두 역할은 겹치면서도 다릅니다. 프로덕트 매니저가 무엇을 왜 만들지를 정한다면, 프로젝트 매니저는 정해진 것을 기한과 예산 안에서 끝까지 끌고 갑니다. 작은 조직에서는 한 사람이 둘을 겸하는 일도 흔하고, 그 경우에도 이 시리즈의 문서 이야기는 대부분 통합니다.

PM은 혼자 일하지 않습니다. 같은 문서를 두고 개발자와 디자이너는 서로 다른 각도에서 봅니다. 개발과 디자인 양쪽을 오래 하며 PM도 겸해 온 입장에서, 하나의 문서가 세 입장에서 다르게 읽히고, 저 또한 다르게 읽는 경험을 자주 합니다. 개발자는 측정 가능한 목표에서 성능 요구를 읽고, 디자이너는 사용 시나리오에서 화면 흐름을 읽습니다. PM이 그 차이를 알고 있어야 같은 문서가 두 사람에게 각각 의미를 갖습니다.

참고와 기준

이 시리즈는 PMBOK 7판, Wiegers의 Software Requirements, Cohn의 User Stories Applied를 주요 참고서로 둡니다. 그러나 책의 분류와 용어를 그대로 따라가지는 않습니다. 이론은 확실합니다. 하지만 지금 책상 앞에 앉은 신입 PM에게는 멀게 느껴지기 때문입니다.

시작에 앞서

이 시리즈를 다 읽어도 모든 PM 문서를 완벽하게 쓰는 사람이 되지는 않습니다. 책 한 권으로 되는 일이 아닙니다. 대신 읽고 나면 세 가지가 달라졌으면 합니다.

  • 왜 이 문서를 쓰는지 한 문장으로 말할 수 있게 됩니다.
  • 어떤 결정이 그 문서로 내려지는지 보이게 됩니다.
  • 누가 그 문서를 읽고 무엇을 거기서 읽어가는지 상상할 수 있게 됩니다.

세 가지가 가능해지면 양식에서 결정으로, 제출에서 기록으로 시선이 옮겨갑니다. PM의 글쓰기는 그 전환에서 시작됩니다.

참고 자료

  • Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition. PMI.
  • Wiegers, K., & Beatty, J. (2013). Software Requirements (Third Edition). Microsoft Press.
  • Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
  • Atlassian. Project management documentation guides. https://www.atlassian.com/agile/project-management

시리즈 전체 목차

다음 편 예고

ep.01 - 왜 시작하는가: 정렬을 위한 문서들

Receipt 프로젝트가 처음 회의실에 올라온 날을 따라갑니다. 차터, BRD, 이해관계자 매트릭스가 프로젝트에 시작 자격을 어떻게 만들어주는지 봅니다.