PRD는 '제품 요구사항 문서'지만, 개인이 클로드로 앱을 만들 때는 거창한 기획서가 필요 없습니다. 필요한 건 딱 하나, 모델이 마음대로 해석하면 곤란한 지점을 미리 못 박아두는 것입니다. 항목 여섯 개만 채우면 대화가 길어져도 결과물이 흔들리지 않습니다. 그대로 복사해 쓸 수 있는 템플릿과, 좋은 문장 vs 나쁜 문장 비교까지 정리했습니다.
1. PRD가 없으면 무슨 일이 생기나
가장 흔한 증상은 기능 범위가 대화할 때마다 달라지는 것입니다. 어제는 없던 관리자 페이지가 오늘 생기고, 분명히 있던 검색 기능이 리팩터링 후 사라집니다.
더 곤란한 것은 판단 기준이 없다는 점입니다. 결과물을 받아도 "이게 맞게 된 건가?"를 확인할 근거가 없으니, 잘못된 방향으로 스무 걸음쯤 간 뒤에야 알아차리게 됩니다.
2. 여섯 가지 항목이면 충분합니다
- 한 줄 정의 – 누가, 무엇을, 왜 쓰는지 한 문장
- 사용자와 시나리오 – 대표적인 사용 흐름 2~3개
- 포함 기능과 제외 기능 – 첫 버전에 넣을 것과 빼기로 한 것
- 화면 목록 – 화면 이름과 각 화면의 목적 한 줄
- 데이터 항목 – 저장할 정보와 서로의 관계
- 완료 조건 – 어떤 상태가 되면 이 버전을 끝으로 볼지
이 중 실무에서 효과가 가장 큰 것은 3번의 '제외 기능'과 6번의 '완료 조건'입니다. 대부분의 프로젝트가 끝나지 않는 이유는 기능이 부족해서가 아니라, 끝나는 지점을 정하지 않았기 때문입니다.
3. 그대로 복사해 쓰는 템플릿
📄 PRD.md
한 줄 정의 — 누구를 위한, 무엇을 하는 서비스인가
사용자 — 주 사용자층과 사용 환경(모바일/PC)
핵심 시나리오 — 사용자가 들어와서 목적을 달성하는 흐름
포함 기능 — 첫 버전에 반드시 있어야 할 기능
제외 기능 — 첫 버전에서 만들지 않을 기능
화면 목록 — 화면 이름 + 목적 한 줄
데이터 항목 — 저장할 정보 목록
완료 조건 — 무엇이 동작하면 완성으로 보는가
제약 — 기술 스택, 기간, 비용 한도
분량은 A4 두세 장이면 충분합니다. 길어질수록 오히려 핵심이 묻히고, 사람도 다시 읽지 않게 됩니다.
4. 나쁜 문장과 좋은 문장
PRD의 품질은 문장의 구체성에서 갈립니다. 같은 내용도 이렇게 달라집니다.
| 회원가입 기능이 필요함 | 이메일·비밀번호 가입. 소셜 로그인은 v1 제외. 가입 시 이메일 인증 필수 |
| 빠르게 동작해야 함 | 목록 화면은 데이터 100건 기준 1초 안에 표시 |
| 디자인은 깔끔하게 | 메인 컬러 1개·보조 컬러 1개, 본문 폰트 1종, 모서리 둥글기 8px 통일 |
| 모바일도 지원 | 화면 폭 768px 미만에서 1단 배치, 하단 고정 버튼 |
5. PRD를 실제로 쓰는 방법
첫째, 프로젝트 폴더 안에 파일로 두세요.
대화창에 붙여넣는 방식은 세션이 바뀌면 사라집니다. 프로젝트 폴더에 PRD.md로 저장해 두면 언제든 다시 참조하게 할 수 있습니다.
둘째, 작업을 시작할 때 읽게 하세요.
"PRD.md를 먼저 읽고, 거기 정의된 범위 안에서 작업해줘"라고 지시하면 범위 이탈이 크게 줄어듭니다.
셋째, 기능을 추가할 땐 PRD부터 고치세요.
코드를 먼저 바꾸고 문서를 나중에 고치면 결국 문서가 죽습니다.
순서를 지켜야 문서가 살아 있는 기준으로 남습니다.
6. 예시로 보는 한 페이지 PRD
'간단한 가계부 앱'을 예로 들면 이 정도 분량이면 충분합니다. 문장이 짧아도 판단 가능한 표현이면 제 역할을 합니다.
한 줄 정의 — 혼자 쓰는 사람이 하루 지출을 3초 안에 기록하는 모바일 웹 가계부
사용자 — 가계부 앱을 여러 번 포기해 본 20~40대, 주로 스마트폰
핵심 시나리오 — 앱을 열면 금액 입력창에 커서가 있고, 금액과 분류만 고르면 저장
포함 기능 — 지출 입력, 월별 합계, 분류별 합계
제외 기능 — 은행 연동, 예산 설정, 통계 그래프, 다중 사용자
화면 목록 — 입력 화면(기본), 내역 목록, 월별 요약
데이터 항목 — 날짜, 금액, 분류, 메모
완료 조건 — 지출을 넣고 목록에서 확인하고 이번 달 합계를 볼 수 있으면 v1 완료
여기서 '제외 기능' 네 줄이 문서 전체에서 가장 값진 부분입니다. 은행 연동을 뺐기 때문에 인증, 보안, 외부 연동 문제가 통째로 사라졌습니다.
7. 자주 하는 실수 세 가지
너무 길게 쓰는 것. 스무 장짜리 문서는 아무도 끝까지 읽지 않습니다. 두세 장으로 압축하고, 세부 사항은 필요할 때 추가하세요.
구현 방법까지 전부 지정하는 것. 라이브러리와 폴더 구조까지 못 박으면 더 나은 선택지를 막게 됩니다. 결과 조건을 적고 방법은 열어두는 편이 낫습니다.
완료 조건을 빼먹는 것. "로그인하고 글을 쓰고 목록에서 볼 수 있으면 v1 완료" 같은 한 줄이 있어야, 끝없는 기능 추가를 멈출 수 있습니다.
자주 묻는 질문 (FAQ)
Q. PRD를 클로드에게 대신 쓰게 해도 되나요?
A. 초안 작성은 맡겨도 좋습니다. 다만 제외 기능과 완료 조건은 직접 정하세요. 이 두 항목은 취향과 목적의 문제라 대신 정해줄 수 없습니다.
Q. 개발을 하다 보니 PRD와 달라졌습니다.
A. 정상입니다. 중요한 것은 문서를 지키는 게 아니라 바뀐 내용을 문서에 반영하는 것입니다. 반영하지 않은 변경이 쌓이는 순간부터 PRD는 기준으로서 기능하지 못합니다.