재무팀장이 회의실로 들어와 노트북을 펴고 말합니다. “이번 분기 영수증 검증에만 인당 80시간 들었어요.” 화면에는 산처럼 쌓인 영수증 사진이 있고, 누군가는 한숨을 쉬고, 누군가는 “그거 자동화하면 되잖아요”라고 가볍게 답합니다. 보통은 회의가 끝나면 그 말도 잊힙니다. 이번에는 PM이 그 말을 들었습니다.
이 시점의 질문
회의실의 가벼운 한마디와 실제 프로젝트 사이에는 큰 거리가 있습니다. 그 거리를 메우는 일이 정렬(alignment), 즉 관련된 사람들이 같은 곳을 바라보게 만드는 일입니다.
이 단계의 문서들은 세 가지 질문에 답해야 합니다.
- 왜 시작하는가
- 누가 시작에 동의했는가
- 무엇을 약속하는가
세 질문에 답이 없으면 어느 순간 누군가가 “아니 이거 왜 하는 거였죠?”라고 묻습니다. 그때 답이 없는 PM은 회의실에서 가장 외로워집니다.
프로젝트 차터(Project Charter)
프로젝트 차터(Project Charter) 는 프로젝트가 존재해도 좋다는 공식 허가증입니다. 분량은 한두 페이지면 충분하고, 길수록 좋은 문서가 아닙니다.
차터에 들어가는 항목은 단순합니다.
- 프로젝트 이름과 한 문장 요약
- 배경과 목적
- 측정 가능한 목표: 목표가 측정 불가능하면 끝낼 수가 없습니다
- 범위(할 것)와 범위 외(안 할 것)
- 스폰서(sponsor) 와 PM: 스폰서는 보통 담당 임원이나 상급 책임자가 맡고, 조직에 따라 클라이언트나 투자자가 이 자리에 들어갑니다
- 대략적인 일정과 예산
- 핵심 리스크
Receipt의 차터를 한 페이지로 압축하면 다음과 같습니다.
차터에서 가장 중요한 칸은 “범위 외”이고, 신입 PM이 가장 자주 빠뜨리는 칸이기도 합니다. 사람들은 무엇을 할지에만 집중하지만, 무엇을 안 할지를 미리 못 박지 않으면 한 달 뒤 누군가가 “ERP 연동도 같이 되는 거 맞죠?”라고 물어옵니다. 그때 차터를 가리키며 “이건 다음 단계에서 다룹니다”라고 말할 수 있어야 합니다.
차터의 효력은 서명에서 옵니다. 스폰서(여기서는 재무이사)가 서명하지 않은 차터는 종이일 뿐입니다.
개발자·디자이너 시각
개발자는 차터를 받으면 “측정 가능한 목표” 칸을 먼저 봅니다. “처리 시간 30분 이내”라는 문장은 곧 성능 요구사항이 됩니다. OCR 응답 시간, 분류 추론 속도, 결재 워크플로 지연이 모두 이 숫자에서 역산됩니다. 그래서 차터의 목표가 막연하면 개발자는 아키텍처를 잡지 못합니다.
디자이너는 “범위”와 “범위 외”를 봅니다. 모바일 업로드가 범위에 들어가는지에 따라 화면 설계 시간이 두 배로 갈리기 때문입니다. 차터에 적힌 “사용자 만족도 4.0/5.0” 같은 정량 목표를 보면 측정 방식도 묻게 됩니다. 만족도 조사가 NPS인지 CSAT인지, 어느 화면을 본 직후에 측정하는지에 따라 디자인이 달라지기 때문입니다.
BRD(Business Requirements Document)
차터가 “왜 시작하는가”를 한 페이지로 압축한 문서라면, BRD(Business Requirements Document) 는 그 “왜”를 길게 풀어쓴 문서입니다. 차터가 결재용이라면 BRD는 설득용입니다.
BRD에는 대략 다음이 들어갑니다.
- 비즈니스 배경: 지금 무엇이 문제이고, 그래서 무엇이 손해인지 적습니다
- 비즈니스 목표: 얼마를 줄이고 얼마를 늘리고 싶은지 적습니다
- 핵심 가정과 제약
- 비즈니스 요구사항: 기능이 아니라 비즈니스가 무엇을 할 수 있어야 하는지를 적습니다
- 성공 기준
- 대안 검토: 왜 직접 만들고 왜 사 오지 않는지 적습니다
BRD와 PRD는 헷갈리기 쉽습니다. BRD는 비즈니스 언어로, PRD는 제품 언어로 쓴 문서입니다.
- BRD: “월 평균 영수증 처리 인건비를 1,200만 원 절감합니다”
- PRD: “사용자는 카드 명세서 CSV를 업로드해 영수증과 자동 매칭할 수 있어야 합니다”
같은 프로젝트라도 누구를 설득하느냐에 따라 다른 문장이 나옵니다. 스폰서와 경영진은 BRD를 보고, 개발팀과 디자인팀은 PRD를 봅니다. BRD는 이 편에서, PRD는 ep.02 무엇을 만드는가에서 다룹니다.
소규모 프로젝트에서는 BRD를 따로 만들지 않고 차터 안에 녹이기도 합니다. Receipt처럼 사내 도구라면 차터의 “배경과 목적” 칸을 두 단락쯤 두텁게 쓰는 것으로 BRD를 대체할 수 있습니다.
개발자·디자이너 시각
개발자는 BRD에서 “대안 검토” 칸을 유심히 봅니다. 사 올 수 있는 SaaS가 있는데 직접 만든다면 그 이유가 명확해야 합니다. “보안 정책상 외부 SaaS 불가” 같은 한 줄이 있으면 클라우드 선택부터 인증 방식까지 달라집니다.
디자이너는 “비즈니스 요구사항” 칸을 사용자 경험으로 번역하기 시작합니다. “영수증 처리 인건비 절감”이라는 문장이 디자이너의 머릿속에서는 “업로드 한 번에 끝나는 흐름”으로 바뀝니다. BRD 단계에서 디자이너가 함께 읽으면 PRD 단계의 사고가 한결 빨라집니다.
이해관계자 매트릭스(Stakeholder Matrix)
차터가 무엇을 약속하는 문서라면, 이해관계자 매트릭스(Stakeholder Matrix) 는 누구에게 약속하는지 정리하는 문서입니다.
가장 자주 쓰이는 형식은 권력/관심도 매트릭스(Power/Interest Grid) 입니다. 가로축은 관심도, 세로축은 영향력이고, 네 칸이 나옵니다.
이해관계자를 모두 동등하게 대하면 안 됩니다. 우상단(영향력 높음·관심도 높음)에는 가장 많은 시간을 써야 하고, 좌하단(영향력 낮음·관심도 낮음)에는 가장 적은 시간을 써야 합니다.
Receipt에서는 재무이사와 재무팀장이 우상단에 있습니다. 둘은 매주 챙겨야 하는 사람입니다. IT 운영팀은 좌상단에 있습니다. 평소에는 관심이 없지만 보안 이슈가 생기면 즉시 거부권을 가지므로, 만족은 시키되 일상적으로는 멀리 둡니다. 일반 사원은 우하단에 있습니다. 화면이 쓰기 좋으면 그만이고 의사결정에는 영향을 주지 않지만, 정보는 충분히 제공해야 합니다.
매트릭스 옆에는 보통 표 하나가 따라붙습니다.
| 이해관계자 | 역할 | 주요 관심사 | 영향력 | 관심도 | 커뮤니케이션 빈도 |
|---|---|---|---|---|---|
| 재무이사 | 스폰서 | ROI, 일정 준수 | 상 | 상 | 격주 1:1 |
| 재무팀장 | 핵심 사용자 대표 | 검증 정확도 | 상 | 상 | 주간 미팅 |
| IT 운영팀장 | 게이트키퍼 | 보안, 운영 부담 | 상 | 중 | 마일스톤 단위 |
| 일반 사원 | 최종 사용자 | 편의성 | 하 | 중 | 사내 공지·뉴스레터 |
| 팀장 그룹 | 결재자 | 결재 흐름 가시성 | 중 | 중 | 격주 공지 |
| 경영진 | 모니터링 | 전사 비용 가시성 | 중 | 하 | 월간 리포트 |
마지막 칸의 커뮤니케이션 빈도가 ep.04 누가 책임지는가에서 다룰 커뮤니케이션 플랜의 기반이 됩니다. 누구에게 얼마나 자주 무엇을 어떻게 알릴지를 여기서부터 고민하게 됩니다.
개발자·디자이너 시각
개발자는 이 매트릭스에서 게이트키퍼가 누구인지를 봅니다. Receipt에서는 IT 운영팀장입니다. 보안 검토를 통과하지 못하면 코드가 아무리 잘 돌아가도 배포가 막히므로, 개발자는 이 인물의 우선순위를 일찍 파악하고 싶어 합니다. 매트릭스에 게이트키퍼가 명시되어 있으면 코드를 짜기 전에 보안 요건을 미리 물을 수 있습니다.
디자이너는 최종 사용자가 어디에 있는지를 봅니다. Receipt에서 일반 사원은 우하단입니다. 영향력은 낮지만 실제로 화면을 쓰는 사람들이라 사용성 테스트의 대상이 됩니다. 의사결정자와 실제 사용자가 다르면 디자인도 둘에게 다른 방식으로 검증해야 합니다. 디자이너는 이 매트릭스에서 그 사실을 일찍 알아볼 수 있습니다.
세 문서를 나란히 놓으면 각자 맡은 몫이 갈립니다.
| 문서 | 답하는 질문 | 주요 독자 | 분량과 갱신 |
|---|---|---|---|
| 프로젝트 차터 | 이 프로젝트를 해도 좋은가 | 스폰서와 결재 라인 | 한두 페이지, 서명 뒤에는 기준점으로 유지 |
| BRD | 왜 지금 이 일에 돈과 사람을 쓰는가 | 스폰서와 경영진 | 수 페이지, 착수 전 작성 |
| 이해관계자 매트릭스 | 누구에게 약속하고 누구를 먼저 챙기는가 | PM과 팀 | 한 페이지, 마일스톤마다 다시 그림 |
정렬은 한 번에 끝나지 않습니다
PMBOK은 이 단계를 착수 프로세스 그룹(Initiating Process Group)으로 묶고 차터를 핵심 산출물로 정의합니다. 다만 책의 묘사와 달리 실제 현장에서 정렬은 한 번의 회의로 끝나지 않습니다. 차터에 서명을 받아도 두 달 뒤 누군가는 “그게 우리 우선순위였어요?”라고 묻습니다. 그래서 PM은 차터를 시작 의식이 아니라 반복해서 가리키는 기준점으로 둡니다.
이 단계의 문서가 잘 만들어졌는지는 두 달 뒤에 알 수 있습니다. “그거 차터에 적혀 있잖아요”라는 한마디가 회의를 5분 안에 끝낼 수 있다면, 그 차터는 잘 만든 차터입니다.
참고 자료
- Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition. PMI.
- Mendelow, A. L. (1981). Environmental Scanning—The Impact of the Stakeholder Concept. Proceedings of the Second International Conference on Information Systems.
- BABOK Guide. International Institute of Business Analysis. A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3.
다음 편 예고
차터에 서명이 떨어지면 비로소 무엇을 만들 것인가라는 질문이 시작됩니다. PRD가 등장하고, 유저 스토리가 카드 형태로 흩어집니다. Receipt의 화면설계서가 처음 그려지는 순간을 따라갑니다.