차터에 재무이사의 서명이 들어오자 회의실의 공기가 바뀝니다. “이거 진짜 하는 거네요”라는 농담이 절반쯤 진심입니다. 그리고 곧 첫 질문이 옵니다. “근데 이거 정확히 뭐 만드는 거죠?” 차터의 한 문장이 PRD 30페이지가 되는 여정이 여기서 시작됩니다.
이 시점의 질문
앞 편에서 왜를 합의했다면, 이제 무엇을 정의할 차례입니다. 이 단계의 문서들은 세 질문에 답해야 합니다.
- 이 제품은 무엇인가
- 사용자가 이걸로 무엇을 하는가
- 한 화면에서 무엇이 보이고 무엇이 동작하는가
세 질문은 비슷해 보이지만 답하는 문서가 다릅니다. 첫 번째는 PRD가, 두 번째는 유저 스토리와 유스 케이스가, 세 번째는 화면설계서가 답합니다.
덧붙이면 이 단계의 문서들은 실무에서 프로젝트 매니저보다 기획자, 즉 PO나 프로덕트 매니저 쪽에서 더 많이 작성합니다. (ep.00 왜 하나를 더 쓰는가의 두 역할 구분을 참고하세요.) 이 시리즈는 한 사람이 두 역할을 겸하는 작은 팀을 가정하므로 PM이 직접 쓰는 흐름으로 적되, 조직에 기획자가 따로 있다면 이 편의 문서들은 기획자가 쓰는 것이 맞습니다.
PRD(Product Requirements Document)
PRD(Product Requirements Document) 는 제품의 큰 그림을 그리는 문서입니다. BRD가 왜를 풀어 썼다면 PRD는 무엇을 풀어 씁니다. 회사마다 양식이 다르고 한 페이지 PRD를 쓰는 곳도 있지만, 핵심 항목은 크게 다르지 않습니다.
- 한 줄 요약(One-liner)
- 문제 정의: 지금 무엇이 안 되고 있는지 적습니다
- 사용자와 사용 시나리오
- 기능 목록(요구사항)
- 비기능 요구사항: 성능·보안·접근성이 여기 들어갑니다
- 출시 기준: 무엇이 충족되면 출시할 수 있는지 적습니다
- 측정 지표
BRD와 헷갈리기 쉬우니 한 문장씩 놓고 비교합니다.
- BRD: “월 평균 영수증 처리 인건비를 1,200만 원 절감합니다”
- PRD: “사용자는 카드 명세서 CSV를 업로드해 영수증과 자동 매칭할 수 있어야 합니다”
같은 프로젝트지만 누구를 향한 문서인지가 다릅니다. BRD는 스폰서에게, PRD는 만드는 팀에게 향합니다.
PRD를 쓸 때는 너무 자세히 쓰려는 욕심을 눌러야 합니다. “버튼은 12px 라운드, 그림자 0 2px 8px”라고 쓰는 PM이 있는데, 그건 PRD가 아니라 디자인 가이드입니다. PRD는 무엇이 동작해야 하는지까지만 적습니다. 어떻게 보이는지는 디자이너의 영역이고, 어떻게 구현하는지는 개발자의 영역입니다.
Receipt PRD의 기능 목록 일부는 이렇게 적힙니다.
## 기능 요구사항
### F-01. 영수증 업로드
- 사용자는 사진(JPG/PNG/HEIC) 또는 PDF로 영수증을 업로드할 수 있다
- 한 번에 최대 10건 업로드 가능
- 업로드 시 OCR이 자동 실행되어 금액·날짜·가맹점을 추출한다
- 추출 신뢰도가 80% 미만이면 사용자에게 확인을 요청한다
### F-02. 카드 명세서 매칭
- 사용자는 카드사 CSV 명세서를 업로드할 수 있다
- 시스템은 업로드된 영수증과 명세서 항목을 자동 매칭한다
- 매칭되지 않은 항목은 별도 영역에 표시한다
### F-03. 결재 라인 연동
- 신청서가 사내 결재 시스템(Approval API)에 전달된다
- 결재자는 모바일 알림으로 신청을 받는다
- 반려 시 사유가 신청자에게 전달된다각 항목은 결과를 적습니다. 어떻게 동작하는지, 즉 알고리즘은 적지 않습니다.
개발자·디자이너 시각
개발자는 PRD에서 “비기능 요구사항”을 먼저 봅니다. OCR 응답 시간 3초 이내, 동시 사용자 100명, 영수증 데이터 90일 보관 같은 숫자가 곧 시스템 구조를 결정합니다. PRD에 비기능 요구사항이 빠져 있으면 개발자는 어림짐작으로 만들고, 출시 직전에 “성능이 안 나옵니다”라는 회의가 열립니다.
디자이너는 PRD에서 “사용 시나리오”를 봅니다. 김 대리가 점심을 먹고 나오는 길에 핸드폰으로 영수증을 찍어 올리는 장면이 시나리오로 적혀 있으면, 디자이너는 모바일 한 손 조작을 전제로 그립니다. 시나리오가 비어 있으면 데스크톱 기준으로 그렸다가 나중에 전부 갈아엎게 됩니다.
유저 스토리(User Story)
PRD가 큰 그림이라면 유저 스토리(User Story) 는 그 그림을 잘게 자른 카드 한 장씩입니다. 형식은 단순합니다.
As a [누가], I want to [무엇을], so that [왜]. (“~로서, ~하고 싶다, 그래서 ~할 수 있다”)
문장 한 줄이 카드 한 장이 되고, 이 카드들이 모이면 백로그가 됩니다.
유저 스토리는 3-Cs라는 원칙을 따릅니다.
- Card: 카드 한 장에 들어갈 만큼 짧게 씁니다
- Conversation: 카드는 대화의 출발점이지 명세서가 아닙니다
- Confirmation: 인수 기준(acceptance criteria)으로 완료를 정의합니다
셋 중에서는 인수 기준이 특히 중요합니다. 유저 스토리만 있고 인수 기준이 없으면 완료의 정의가 사람마다 달라집니다. 인수 기준은 보통 “이런 상황에서(Given), 사용자가 이렇게 하면(When), 시스템이 이렇게 반응해야 한다(Then)” 형식으로 적습니다.
**Story:** 일반 사원으로서, 영수증을 사진으로 업로드하고 싶다.
그래야 손으로 입력하지 않아도 된다.
**Acceptance Criteria:**
- Given 사원이 모바일 앱에 로그인한 상태에서
- When 카메라 버튼을 눌러 영수증 사진을 찍으면
- Then 자동으로 OCR이 실행되어 금액·날짜·가맹점이 채워진다
- And 신뢰도가 낮은 필드는 노란색 배경으로 표시된다이 정도까지 적혀야 개발자는 만들 수 있고 QA는 테스트할 수 있습니다.
개발자·디자이너 시각
개발자는 유저 스토리에서 분량을 잽니다. 한 스프린트(2주)에 들어갈 만한 크기인지 보고, 너무 크면 쪼개달라고 요청합니다. “영수증을 업로드한다” 스토리는 OCR, 신뢰도 표시, 카드 매칭이 다 들어 있어 크기 때문에 보통 세 장에서 네 장으로 쪼개집니다.
디자이너는 유저 스토리의 동사에 주목합니다. “업로드한다”는 화면 한 장이 아니라, 찍고, 자르고, 미리보고, 확인하고, 결과를 보는 다섯 화면이 될 수 있습니다. 디자이너는 동사를 보고 화면 흐름을 그려본 뒤 PM에게 “이거 다섯 화면이 되는데 다 만들어요?”라고 묻습니다. 좋은 PM은 이 질문을 환영합니다. PRD를 다듬는 기회이기 때문입니다.
유스 케이스(Use Case)
유저 스토리가 사용자의 의도를 짧게 적는다면, 유스 케이스(Use Case) 는 사용자와 시스템의 상호작용을 단계별로 풀어 쓰는 문서입니다. 형식은 더 길고 구조적입니다.
**UC-01: 영수증 신청**
- 행위자(Actor): 일반 사원
- 사전조건: 사용자가 로그인되어 있고 모바일 앱이 카메라 권한을 가짐
- 트리거: 사용자가 홈 화면의 [신청] 버튼을 누름
**주 흐름(Main Flow):**
1. 시스템이 카메라 화면을 표시한다
2. 사용자가 영수증을 촬영한다
3. 시스템이 OCR을 실행해 금액·날짜·가맹점을 추출한다
4. 시스템이 추출 결과를 편집 가능한 폼으로 보여준다
5. 사용자가 카테고리를 선택하고 [신청]을 누른다
6. 시스템이 결재 라인을 자동 설정해 신청을 등록한다
**대안 흐름(Alternate Flow):**
- 3a. OCR 신뢰도가 80% 미만이면 4번 단계에서 신뢰 낮은 필드에 경고 표시
- 6a. 결재자가 휴가 중이면 대결자에게 자동 위임
**사후조건:** 신청이 결재 시스템에 등록되고 사용자에게 신청 번호가 표시됨유저 스토리가 왜 그 기능을 원하는지를 적는다면, 유스 케이스는 어떤 절차를 거쳐 그 기능이 동작하는지를 적습니다. 둘은 일대일로 대응하지 않고, 보통 큰 유저 스토리 하나가 여러 유스 케이스로 풀립니다.
회사 문화에 따라 둘 중 하나만 쓰기도 합니다. 애자일 색이 강한 팀은 유저 스토리와 인수 기준만 쓰고 유스 케이스는 생략합니다. 워터폴 색이 강하거나 규제가 엄격한 산업에 속한 팀은 유스 케이스를 정식 산출물로 요구합니다. Receipt는 사내 도구이므로 유저 스토리 중심으로 가되, 결재 흐름처럼 분기가 많은 핵심 기능만 유스 케이스로 보강합니다.
화면설계서(Wireframe / Spec)
PRD가 무엇을, 유저 스토리가 왜를, 유스 케이스가 어떤 절차로 동작하는지를 답한다면, 화면설계서(Wireframe / Spec) 는 그 화면에서 정확히 무엇이 어디 있는지를 답합니다. 화면설계서 자체는 분량이 커서 이 블로그의 화면설계서 가이드 시리즈가 여섯 편에 걸쳐 따로 다루고, 이 편에서는 정의 단계에서 맡는 몫만 짚습니다.
화면설계서는 크게 두 갈래로 나뉩니다.
- 와이어프레임(Wireframe): 회색조 박스로 위치와 흐름만 그립니다.
- 목업·시안(Mock-up): 색·타이포·아이콘이 입혀진 디자인 시안입니다.
PM이 직접 그리는 것은 보통 와이어프레임까지이고, 디자이너가 와이어프레임을 받아 목업으로 발전시킵니다.
화면설계서에서 가장 중요한 것은 주석(annotation) 입니다. 실무에서는 디스크립션(description) 이라고도 부르고, 두 이름이 섞여 쓰입니다. 박스만 있는 와이어프레임은 디자이너에게 추측을 강요합니다. 와이어프레임의 각 요소에 번호를 매기고, 번호마다 그 컴포넌트의 이름·동작·상태·예외를 짧게 적어야 합니다. 위 와이어프레임의 번호 1부터 7까지에 대응하는 디스크립션을 표로 옮기면 다음과 같습니다.
| 번호 | 컴포넌트 | 동작 | 상태·예외 |
|---|---|---|---|
| 1 | 헤더 | 로고 탭 시 홈 이동 | 알림 뱃지 0/N 표시 |
| 2 | 카메라 미리보기 | 자동 초점, 촬영 시 OCR 시작 | 대기·인식 중·완료·실패 |
| 3 | 추출 정보 | 필드 탭 시 직접 수정 | 신뢰도 80% 미만은 앰버 표시 |
| 4 | 카테고리 | 드롭다운, OCR이 추천값 선택 | 미선택이면 신청 불가 |
| 5 | 메모 | 선택 입력, 200자 제한 | 기본 접힘 |
| 6 | 상태 안내 | 검증 실패 이유를 한 줄로 표시 | 문제 없으면 숨김 |
| 7 | 신청하기 | 탭 시 결재 라인으로 전송 | 필수값 누락 시 비활성 |
디스크립션을 이렇게 표로 정리해 두면 디자이너와 개발자에게는 그대로 작업 명세서가 됩니다. 넘버링 체계와 문장 스타일 같은 세부 작성법은 화면설계서 가이드 ep.03 한 장의 화면을 완성하는 법에서 자세히 다룹니다.
개발자·디자이너 시각
개발자는 화면설계서에서 상태(state)를 봅니다. 정상·로딩·에러·빈 상태(empty state)·권한 거부 다섯 상태가 다 그려져 있는지 확인합니다. 다섯 상태가 빠지면 개발자는 자기 마음대로 만들고, 디자이너가 나중에 보고 “이렇게 만든 게 아닌데”라고 말하게 됩니다.
디자이너는 화면설계서가 왜 이렇게 배치됐는지를 묻습니다. PM이 그린 와이어프레임에는 의도가 담겨 있어야 합니다. “카메라가 가장 위에 있는 이유는 한 손으로 들고 찍을 때 엄지가 닿는 위치라서” 같은 메모가 있으면 디자이너는 그 의도를 살려 목업을 그립니다. 의도가 없으면 디자이너는 자기 안목대로 다시 그리고, PM이 또 검토하느라 시간이 길어집니다.
네 문서는 같은 제품을 다른 배율로 봅니다.
| 문서 | 답하는 질문 | 다루는 단위 | 주요 독자 |
|---|---|---|---|
| PRD | 이 제품은 무엇인가 | 제품 전체 | 만드는 팀 전체 |
| 유저 스토리 | 사용자가 무엇을 왜 하려는가 | 카드 한 장 | 개발자와 QA |
| 유스 케이스 | 어떤 절차로 동작하는가 | 기능 하나의 흐름 | 개발자와 QA, 감사 담당 |
| 화면설계서 | 한 화면에 무엇이 있고 어떻게 동작하는가 | 화면 한 장 | 디자이너와 개발자 |
정의는 한 번에 완성되지 않습니다
PMBOK의 계획 프로세스 그룹(Planning Process Group)에는 요구사항 수집(Collect Requirements)과 범위 정의(Define Scope)가 들어 있습니다. 한 번 정의하면 끝이라는 인상을 줄 수 있지만, 실제로는 다섯 번쯤 다시 씁니다. 첫 번째는 추정으로, 두 번째는 인터뷰 후에, 세 번째는 디자인 검토 후에, 네 번째는 첫 프로토타입 후에, 다섯 번째는 베타 테스트 후에 씁니다.
그래서 PRD는 살아 있는 문서(living document)라고 부릅니다. 한 번 결재를 받고 잠그는 것이 아니라 버전을 매기며 함께 진화합니다. 잠긴 PRD를 강제하면 현장은 PRD를 무시하고 일하게 되고, 그 순간 PRD는 죽습니다.
참고 자료
- Cohn, M. (2004). User Stories Applied: For Agile Software Development. Addison-Wesley.
- Cockburn, A. (2000). Writing Effective Use Cases. Addison-Wesley.
- Wiegers, K., & Beatty, J. (2013). Software Requirements (Third Edition). Microsoft Press.
- Atlassian. User stories with examples. https://www.atlassian.com/agile/project-management/user-stories
다음 편 예고
PRD가 완성되면 다음 질문이 옵니다. “그래서 언제 끝나요?” 큰 덩어리를 실행 가능한 작은 조각으로 자르는 일이 시작되고, WBS, 간트, 스프린트 백로그가 차례로 등장합니다.