절마다 쓰는 법

아이디어

이 아이디어를 BRD로 키울 가치가 있는지 팀원 누구나 1분 안에 판단하게 한다. 해결책을 정하는 문서가 아니다.

배경필수

무엇을 쓰나 누가, 어떤 순간에, 무엇이 막히나

이렇게 쓴다 1~3줄 목록, 줄마다 한 가지. 숫자가 있으면 숫자. 일어나지 않은 일은 현재형으로 쓰지 않는다

쓰지 않는다 해결책을 먼저 쓰기, "불편하다는 의견이 많다"처럼 출처 없는 일반화

제안필수

무엇을 쓰나 무엇이 달라지면 좋은가

이렇게 쓴다 1~3줄 목록. "사용자가 무엇을 할 수 있게 되나"를 한 줄씩(예: "요청을 걸 때 답이 필요한 날을 고를 수 있다")

쓰지 않는다 만드는 방법(업로드·API·화면 구성), "안내한다·정한다" 같은 일 처리 문장, 상세 정책·예외(BRD·PRD의 일), 배경에 쓴 말 되풀이

기대 효과필수

무엇을 쓰나 누구에게 무엇이 얼마나 좋아지나, 하지 않으면 무엇이 계속되나

이렇게 쓴다 1~3줄 목록. 바뀐 뒤 모습이라 현재형으로 쓴다. 숫자는 아는 것만

쓰지 않는다 근거 없는 목표 숫자

BRD

"이 프로젝트가 성공했다고 말하려면 무엇이 달라져야 하는가"를 팀이 합의한다. 무엇을 만들지(화면·기능)는 PRD가 정한다.

1. 비즈니스 배경필수

무엇을 쓰나 왜 이 방향인가

이렇게 쓴다 1~5줄 목록. 전략·상위 목표·아이디어와의 연결. 아이디어에서 키웠으면 "「아이디어 · 폴더 이름」에서 키웠다" 한 줄

쓰지 않는다 배경 없이 문제부터

2. 해결해야 할 비즈니스 문제필수

무엇을 쓰나 지금 무엇이 막히나

이렇게 쓴다 1~5줄 목록. 프로세스 병목·고객 불편·운영 리스크를 "누가, 어떤 과정에서, 무엇이 반복되고, 그래서 무슨 일이 생기나"로. 숫자는 맥락 뒤에 보조로

쓰지 않는다 "관리자 승인 기능 추가"처럼 기능부터

3. 프로젝트 목표필수

무엇을 쓰나 끝나면 무엇이 달라져 있어야 하나

이렇게 쓴다 1~5줄 목록. 상태 문장("받는 사람이 요청을 열지 않고도 급한 순서를 안다")

쓰지 않는다 기능 목록

4. 비즈니스 요구사항필수

무엇을 쓰나 반드시 충족해야 할 것

이렇게 쓴다 1~5줄 목록. "~할 수 있어야 한다 / ~되어야 한다". 지켜져야 할 결과는 여기, 판정 기준(시점·단위·숫자)은 PRD 정책에

쓰지 않는다 "결제 화면에 버튼 추가", "모달로 띄운다"

5. 성공 지표필수

무엇을 쓰나 무엇을 보고 성공을 판단하나

이렇게 쓴다 1~5줄 목록. 지표 이름. 목표 숫자는 근거가 있을 때만

쓰지 않는다 근거 없는 목표 숫자

6.1 In Scope필수

무엇을 쓰나 이번에 다루는 것

이렇게 쓴다 1~5줄 목록

쓰지 않는다 Out of Scope 를 비워 두기

6.2 Out of Scope필수

무엇을 쓰나 이번에 다루지 않는 것

이렇게 쓴다 1~5줄 목록. 헷갈리기 쉬운 것을 꼭 넣는다

쓰지 않는다 In Scope 만 쓰기

PRD

개발자·디자이너·QA·AI가 이 문서로 만들고 확인할 수 있게, 어떤 문제를 누구를 위해 어디까지 풀고 무엇을 보면 끝났는지 정한다.

• 지나치게 자세히 쓰지 않는다. 만드는 방법은 개발·디자인이 정한다
• 기능 하나만 크게 부풀려 차례가 흐려지지 않게 한다
• 바뀐 것은 고려사항에 한 줄로 남긴다
• 문장마다 그 자체로 읽히게 쓰고, 다른 줄 번호를 가리키지 않는다

1. 요약 및 배경필수

무엇을 쓰나 어떤 문제를 푸나, 왜 지금 풀어야 하나

이렇게 쓴다 누가 · 지금 어떻게 하고 있나 · 그래서 무엇을 잃나(시간·돈·실수) · 왜 지금인가 순서로 2~5문장. BRD 문장을 되풀이하지 않고 이 PRD 가 푸는 문제로 좁힌다

쓰지 않는다 BRD 의 사업 배경 옮겨 적기, 해결책부터 쓰기

1.1 기존 기능과의 관계필수

무엇을 쓰나 이번에 건드리거나 헷갈리기 쉬운 기존 기능이 지금 어떤 상황이고, 이번에 무엇을 바꾸나

이렇게 쓴다 줄마다 기존 기능(사용자가 부르는 이름) · 지금(되는 것과 안 되는 것 한두 문장) · 바꾸는 것(한 문장, 바꾸지 않는다·함께 보여 준다·막는다 같은 결과로 끝낸다). 예: 쿠폰 최소 결제금액 칸 · 저장만 하고 결제 계산에는 쓰지 않는다 · 결제할 때 이 금액 미만이면 쿠폰을 막는다. 문서와 코드가 다르면 지금에 「문서는 X, 코드는 Y」로 쓴다

쓰지 않는다 「이 기능에 맞게 넓힌다」처럼 무엇이 바뀌는지 없는 말, 이번 PRD 와 상관없는 기능 나열, 코드 위치(파일:줄·파일 경로·함수 이름)

2. 목표와 성공 지표필수

무엇을 쓰나 비즈니스 목표와 사용자 목표, 무엇을 보고 이뤘다고 하나

이렇게 쓴다 목록. 줄마다 「비즈니스 목표: …」(KPI·기간·숫자, 예: 3개월 안에 전환율 5% 증가) 또는 「사용자 목표: …」(사용 경험, 예: 주문 시간 30% 단축)로 시작하고, 끝에 「재는 방법: …」을 붙인다(예: 「사용자 목표: 주문 시간 30% 단축 — 재는 방법: 장바구니 진입부터 주문 완료까지 걸린 시간 중앙값」). 합쳐 2~3줄. 숫자를 모르면 목표치 미정

쓰지 않는다 근거 없는 목표 숫자, 기능 목록

3. 핵심 고객 여정필수

무엇을 쓰나 고객이 문제를 알아차리고 이 기능으로 일을 마치기까지의 이야기(유저 스토리)

이렇게 쓴다 누가(주인공) · 어떤 상황에서 · 무엇을 하려고 · 어디서 막히고 · 우리 서비스로 무엇을 해서 · 무엇을 얻나를 사용자 입장의 이야기로 2~4문단. 단계가 많으면 Mermaid journey 하나

쓰지 않는다 화면 구성·API 설명, 기능 목록, 실패만 모은 목록

4. 기능 정의필수

무엇을 쓰나 이번에 만드는 기능 카드 여러 개

이렇게 쓴다 카드 = 기능 · 동작(무엇을 하면 무엇이 되나, 한두 문장) · 완료 기준. 카드는 모두 이번에 만드는 것이고, 카드 차례가 만드는 차례다. 카드 하나는 따로 만들고 따로 확인할 수 있는 크기로, 한 카드만 크게 부풀리지 않는다. 이번에 안 만드는 것은 Out of Scope 에 쓴다. 완료 기준은 한 줄에 하나, 「(조건)일 때 (행동)하면 (결과)」 꼴로 사람이나 AI 가 해 보고 맞다·틀리다를 가를 수 있게(예: 「확인 요청이 열린 문서에서 확인 완료를 누르면 상태가 확인 완료로 바뀌고 열린 메모가 닫힌다」). 완료 기준 꼬리표는 정상·경계·권한·오류·미결 다섯 개만

쓰지 않는다 만드는 방법(화면 구성·API), 다른 카드나 줄의 번호 가리키기

4.1 In Scope

무엇을 쓰나 이번에 만드는 것

이렇게 쓴다 기능 정의의 카드 이름이 저절로 보인다. 따로 쓰지 않는다

4.2 Out of Scope필수

무엇을 쓰나 이번에 안 하는 것

이렇게 쓴다 목록. 헷갈리기 쉬운 것을 꼭 넣고 이유를 한 줄로

쓰지 않는다 기능 정의에 있는 것 되풀이

5. 화면 요구사항

무엇을 쓰나 바뀌거나 새로 생기는 화면마다 꼭 보여야 할 것과 상태

이렇게 쓴다 목록. 줄마다 화면 이름: 꼭 보여야 할 것·차례·빈 상태·휴대폰에서 달라지는 것. 디자인이 있으면 링크 한 줄

쓰지 않는다 픽셀·색 같은 디자인 세부, 만드는 방법

6. 고려사항

무엇을 쓰나 정한 것, 지킬 규칙, 그대로 둘 것, 기술 제약, 아직 못 정한 것

이렇게 쓴다 목록, 한 줄에 하나. 정한 것(누가·언제, 예: 「메일 알림은 이번에 하지 않기로 했다(10/10 도윤)」) → 지킬 규칙 → 그대로 둘 것 → 기술 제약 → 못 정한 것(「못 정한 것 — 질문」, 선택지와 무엇이 갈리나) 차례로, 있는 것만. 문서를 쓰는 동안 바뀐 것도 한 줄로 남긴다

쓰지 않는다 주어 없는 꼬리표 줄(「검토 필요」), 코드 위치, 다른 절에 이미 쓴 말 되풀이

7. 용어

무엇을 쓰나 처음 보는 말

이렇게 쓴다 표

8. 참고 자료

무엇을 쓰나 인터뷰·조사·경쟁사·관련 문서

이렇게 쓴다 목록. 문서 링크나 주소

쓰지 않는다 본문에 이미 쓴 말 되풀이