개발자가 PRD 잘 쓰는 법 정리 (작성하지 않으면 왜 실패하는가)

PRD 작성 방법을 검색해 보면 대부분 PM이 PM에게 쓴 글이다. 그러나 정작 부실한 PRD 때문에 야근하는 쪽은 개발자다. 모호한 한 줄짜리 요구사항을 받고 "이것이 어떻게 동작해야 하는가"를 슬랙으로 50번 물어본 경험은 누구에게나 있을 것이다.

 

이 글은 개발자 입장에서 PRD(Product Requirements Document)를 어떻게 바라보아야 하는지, 직접 작성하게 되었을 때 어떻게 써야 하는지를 정리한다. 2026년 현재 Cursor, Claude Code 같은 AI 코딩 도구가 PRD를 직접 읽어서 코드를 생성하는 시대이며, PRD 품질이 곧 코드 품질로 직결되는 흐름까지 함께 다룬다. 형식적인 SW공학 교과서 톤은 배제하고 현장에서 실제로 쓸 수 있는 내용만 추렸다.

 

 

출처: www.smartsheet.com

 

PRD란 무엇인가부터 다시 짚어 보자

 

PRD는 Product Requirements Document의 약자다. 한국어로는 "제품 요구사항 문서"이다. 무엇을 만들 것인지, 왜 만드는지, 어떻게 동작해야 하는지를 한 문서에 정리한 결과물이다. 기획서와 비슷해 보이지만 다소 다르다.

 

PRD vs 기획서 vs 요구사항 명세서의 차이

 

모두 비슷해 보이지만 강조점이 다르다. 표로 정리해 보았다.

 

문서 종류	주 작성자	강조점	분량
**PRD**	PM/PO	"왜" + "무엇을"	1~10페이지
**기획서**	기획자	UI/UX 흐름 위주	보통 두꺼운 편이다
**요구사항 명세서(SRS)**	SI 분석가	기능 단위 형식 완결	매우 두껍다

 

PRD는 "왜 이것을 만들어야 하는가"부터 시작한다. 기획서는 화면 흐름을 그린다. 요구사항 명세서(IEEE 830 같은 것)는 기능 ID를 매기고 추적성을 따지는 데 집중한다. 모던 스타트업 및 IT 회사에서 개발자가 가장 자주 마주치는 문서가 바로 PRD다.

 

PM이 작성하는 PRD와 개발자가 작성하는 PRD는 다소 다르다

 

PM이 작성하는 PRD는 "왜"에 무게가 실린다. 시장, 사용자, 비즈니스 임팩트가 중심이다. 반대로 개발자가 직접 작성하는 PRD는 "어떻게 동작하는가"에 더 깊이 들어간다. API 계약, 데이터 모델, 엣지 케이스, 에러 메시지까지 모두 들어가야 한다.

 

다만 양쪽 모두에서 빠지면 안 되는 요소가 있다. 문제 정의, 사용자 시나리오, 성공 지표, Out of Scope가 그것이다. PM이든 개발자든 PRD에 반드시 포함되어야 한다.

 

PRD가 부실하면 개발자가 가장 큰 피해를 본다

 

PRD가 부실하면 결국 개발자가 손해를 본다. PM은 위에 보고만 잘하면 되지만 코드는 결국 개발자가 작성하기 때문이다. 모호한 PRD를 받으면 추측으로 구현하고, 추측이 틀리면 갈아엎어야 한다.

 

모호한 PRD가 부르는 5가지 재앙

 

실제로 자주 터지는 패턴들이다.

 

1. 개발 중간의 스펙 변경: "이것이 다른 의미였는가?" → 코드 절반을 갈아엎는다
2. 재작업 폭탄: QA 단계에서 "이것은 의도한 동작이 아니다"가 발견된다 → 다시 작성해야 한다
3. 엣지 케이스 누락: 비밀번호가 틀렸을 때 어떻게 표시할지 적혀 있지 않아 출시 직전에 발견된다
4. 팀원 간 해석 충돌: 백엔드는 A로, 프론트는 B로, 디자이너는 C로 받아들인다
5. 리뷰어의 분노: PR을 올리니 "이렇게 동작하면 안 된다"는 코멘트가 달린다 → PRD에는 그런 언급이 한마디도 없었다

 

이 다섯 가지가 함께 터지면 1주일 일정이 3주가 된다. 실제로 그렇다.

 

"이것이 어떻게 동작하는가"라는 질문 무한 루프를 만드는 PRD 패턴

 

부실한 PRD의 전형적인 증상이다.

 

• "사용자가 로그인할 수 있게 한다" 같은 한 줄짜리 명세
• "직관적이고 빠르게" 같은 형용사 위주 명세
• 입력값/출력값 예시 부재
• 에러 케이스에 대한 언급이 한 줄도 없다
• "필요시 추후 협의" 떡밥만 잔뜩 붙어 있다

 

이렇게 되면 슬랙 멘션이 무한 루프를 돈다. 답이 나오지 않으니 PM 본인도 헷갈려 "팀장에게 물어보겠다"라며 떠넘긴다. 그동안 개발자는 손을 놓고 기다려야 한다.

 

한 줄 PRD 때문에 3주를 잃은 사례

 

매우 흔한 사례다. "결제 실패 시 사용자에게 알림을 보낸다"라는 한 줄을 보고 개발자가 푸시 알림으로 구현했다. 출시 직전에 "이것은 이메일이어야 하고, 카드사별로 메시지가 달라야 한다"는 코멘트가 붙는다. 푸시 인프라를 모두 구축해 두었는데 이메일 큐 시스템을 새로 붙이고 카드사별 분기 처리를 추가해야 했다. 결국 3주가 더 소요되었다. PRD에 한 줄만 더 있었다면 발생하지 않았을 일이다.

 

좋은 PRD가 갖춰야 할 핵심 구조

 

좋은 PRD는 정해진 형식보다 빠진 것이 없다는 점이 핵심이다. 아래 6개 블록이 모두 포함되어 있다면 형식은 무엇이든 상관없다.

 

문제 정의 (Why) - 이것이 빠지면 모든 것이 무너진다

 

"왜 이것을 만드는가"가 첫 줄에 나와야 한다. 이것이 없으면 개발자가 만들면서도 "왜 만드는가"라는 의문 때문에 의욕이 떨어진다. 더 나쁜 것은 PM조차 "왜"를 모르고 위에서 시켜서 작성하는 PRD다. 그런 PRD는 90% 갈아엎는다.

 

좋은 예: "현재 결제 실패율이 8%이며 그중 60%가 카드 한도 초과다. 사용자가 다른 카드로 즉시 재시도할 수 있게 하면 결제 성공률이 5%p 상승할 것으로 추정된다."

 

사용자 스토리 / 시나리오

 

"누가, 언제, 무엇을, 왜"를 한 문장으로 표현한다. 이 한 줄의 유무가 만드는 차이가 크다.

 

[사용자 스토리]
프리미엄 사용자가 결제 실패 시
다른 카드로 1탭 안에 재시도해서
이탈 없이 구독을 완료할 수 있어야 한다.

 

기능 명세 (What) - 동사 단위로 쪼개라

 

"~할 수 있다"가 아니라 동사 단위로 쪼개야 한다.

 

• ❌ "결제 재시도 기능을 추가한다" (이것이 한 줄 PRD다)
• ✅ 다음과 같이 쪼개야 한다:

 

- 결제 실패 응답을 받으면 실패 사유(코드, 메시지)를 화면에 노출한다

- "다른 카드로 결제" 버튼을 노출한다

- 버튼을 누르면 등록된 카드 목록 모달이 뜬다

- 카드 선택 후 결제 API를 재호출한다

- 재시도 결과를 동일한 결제 결과 화면으로 보여준다

 

Out of Scope - 만들지 않을 것을 명시하는 일이 더 중요하다

 

"이번에는 만들지 않는다" 항목이 PRD에 반드시 있어야 한다. 이것이 빠지면 나중에 "이것도 함께 들어가는 것으로 알고 있었다"가 100% 발생한다. 만들지 않을 것을 적어 두면 분쟁이 한 번에 종결된다.

 

[Out of Scope]
- 신규 카드 등록 플로우 (별도 PRD에서 처리)
- 카드 한도 사전 조회 기능
- 페이팔/간편결제 재시도

 

성공 지표 (Success Metrics)

 

만들고 난 뒤 "잘 되었는지"를 어떻게 판단할 것인가. 숫자로 적어야 한다.

 

• 결제 실패 후 재시도 성공률 30% 이상
• 결제 실패에 따른 이탈률 4%p 감소
• 재시도 추가에 따른 결제 평균 응답 시간 +500ms 이내

 

엣지 케이스와 예외 처리

 

여기서 PRD 품질이 갈린다. 행복 경로(happy path)만 있는 PRD는 반드시 실패한다.

 

• 모든 카드가 한도 초과라면? → 안내 메시지 + 고객센터 링크
• 네트워크가 끊긴다면? → 재시도 버튼 + 30초 후 자동 재시도
• 사용자가 동일 카드로 5회 이상 재시도한다면? → 차단 + 다른 결제수단 안내
• 결제 진행 중 앱이 종료된다면? → 다음 진입 시 결과 확인 모달

 

개발자가 PRD를 작성할 때 자주 빠뜨리는 항목들

 

PM이 작성한 PRD에는 사용자 관점이 있으나 기술 디테일이 부족하다. 반대로 개발자가 작성한 PRD에는 기술이 있으나 다른 디테일이 빠진다. 개발자가 자주 누락하는 항목을 정리한다.

 

API 계약 / 데이터 스키마

 

요청/응답 예시 JSON을 PRD에 직접 박아 두면 협업이 매우 수월해진다. 백엔드, 프론트, QA 셋 모두가 동일한 그림을 보게 된다.

 

POST /api/payments/retry
{
  "payment_id": "pay_xxx",
  "card_id": "card_yyy"
}

200 OK
{
  "status": "success",
  "transaction_id": "tx_zzz"
}

402 Payment Required
{
  "status": "failed",
  "reason_code": "LIMIT_EXCEEDED",
  "reason_message": "카드 한도가 초과됨"
}

 

에러 핸들링과 사용자 메시지

 

에러 케이스마다 어떤 메시지를 보여줄지 PRD에 적어 두어야 한다. 프론트가 임의로 만들면 톤도 어긋나고 CS 대응도 꼬인다.

 

권한과 인증 시나리오

 

• 비로그인 사용자가 접근하면 어떻게 되는가?
• 권한 없는 사용자가 호출하면 어떻게 되는가?
• 토큰 만료 중에 액션을 시도하면 어떻게 되는가?

 

이 세 가지는 거의 모든 기능에 적용되므로 미리 적어 두어야 한다.

 

성능 / 부하 기준

 

"빠르게"가 아니라 숫자로 표현한다. "P95 응답 시간 300ms 이내", "동시 1만 요청까지 무중단" 같은 방식이다.

 

마이그레이션과 롤백 계획

 

기존 데이터에 영향을 주는 변경이라면 마이그레이션 스크립트 계획과 롤백 시나리오까지 PRD에 들어가야 한다. 이것을 빠뜨리면 배포 직전에 SRE에게 크게 혼난다.

 

AI 코딩 시대의 PRD - Cursor, Claude Code에 잘 먹히는 작성법

 

이제 진짜 중요한 파트다. 2026년 현재 PRD는 사람만 읽는 문서가 아니다. Cursor, Claude Code, GitHub Copilot Workspace 같은 AI 도구가 PRD를 직접 읽고 코드를 생성한다. 즉, PRD 품질이 곧 코드 품질이 된다.

 

 

출처: sentisight.ai

 

AI는 모호한 PRD를 받으면 마음대로 만든다

 

사람은 모호한 PRD를 받으면 PM에게 다시 묻는다. 그러나 LLM은 묻지 않는다. 스스로 그럴듯한 내용으로 채워 넣는다. 그래서 결과물이 사양과 미세하게 다른 지점이 수십 군데 발생한다. 그것을 다시 잡아내는 일에 더 많은 시간이 든다.

 

해법은 단순하다. AI가 추측할 여지를 0으로 만드는 것이 좋은 PRD다.

 

코드 생성용 PRD에 반드시 포함해야 할 것들

 

LLM이 코드를 작성할 때 결정적으로 필요한 정보다.

 

• 입출력 예시: 함수 시그니처와 호출 예시 1~3개
• 자료 구조: 핵심 객체의 필드와 타입
• 에러 케이스 분기: 어떤 조건에서 어떤 에러를 반환할지
• 테스트 케이스: 통과해야 할 케이스 명시
• 명시적 제약: "절대 이렇게 하지 말 것" 항목

 

이 다섯 가지가 들어간 PRD를 LLM에 주면 결과물이 완전히 달라진다. 넣지 않고 돌리면 LLM이 스스로 패턴을 만들어 코드베이스의 일관성이 깨진다.

 

PRFAQ 스타일이 AI에 잘 먹히는 이유

 

아마존이 만든 PRFAQ(Press Release + FAQ)가 최근 다시 주목받는다. 이유는 "Why → What → How" 흐름이 LLM의 추론 패턴과 잘 맞기 때문이다.

 

• 첫 부분에 "왜"가 명확히 있어 LLM이 의도를 파악한다
• FAQ 형식이 엣지 케이스를 자연스럽게 다룬다
• 결정 사항이 문장으로 박혀 있어 추측의 여지가 적다

 

PRD를 짧게 작성할 것이라면 PRFAQ 포맷을 한번 시도해 볼 만하다. 마티 케이건이 정리한 PM 원칙이나 Lenny's Newsletter 같은 글로벌 자료에서도 PRFAQ 부활 흐름을 자주 다룬다.

 

망한 PRD vs 잘 쓴 PRD 비교 (Before/After)

 

말로만 하면 와닿지 않으므로 동일한 기능을 두 가지 형태로 작성해 보았다.

 

Before - "로그인 기능 추가" 한 줄

 

[기능] 로그인 기능을 추가한다.

 

농담 같지만 실제로 이런 PRD를 받는다. 받은 개발자의 머릿속을 들여다보자.

 

• 이메일인가, 소셜인가, OTP인가, 매직링크인가?
• 비밀번호 정책은 무엇인가?
• 자동 로그인 유지 기간은 얼마인가?
• 비밀번호가 틀렸을 때 메시지는 무엇인가?
• 로그인 5회 실패 시 차단할 것인가?
• 로그아웃은? 다른 기기 로그아웃은?

 

질문이 30개가 나온다. 그 30개를 PM에게 모두 묻거나 추측으로 구현해야 한다.

 

After - 동일한 기능을 30줄로 작성한 PRD

 

## 로그인 기능

### Why
회원가입 후 재방문 시 사용자가 자기 데이터에 접근할 수 있어야 한다.
초기에는 이메일+비밀번호만 지원하며 소셜은 후속 PRD에서 다룬다.

### 사용자 스토리
회원가입한 사용자가 이메일/비밀번호로 로그인하여
대시보드에 진입할 수 있어야 한다.

### 기능 명세
- 로그인 화면: 이메일, 비밀번호, "로그인" 버튼, "비밀번호 찾기" 링크
- 이메일은 RFC 5322 형식으로 검증한다
- 비밀번호는 8자 이상, 대소문자+숫자를 포함한다
- 성공 시 JWT 토큰 발급 (만료 24시간), HttpOnly 쿠키에 저장한다
- 실패 시 에러 메시지: "이메일 또는 비밀번호가 일치하지 않습니다"
  (이메일 존재 여부 노출 금지 - 보안)
- 5회 연속 실패 시 30분간 잠금
- "자동 로그인" 체크박스: 30일 유지 (refresh token)

### Out of Scope
- 소셜 로그인 (별도 PRD)
- 2FA
- 비밀번호 재설정 플로우 (별도 PRD)

### 성공 지표
- 로그인 성공률 95% 이상
- 로그인 평균 응답시간 P95 200ms 이내

### 엣지 케이스
- 잠금 상태에서 시도: "30분 후 다시 시도" 안내
- 토큰 만료 중 API 호출: 401 + 자동 재로그인 시도
- 다른 기기 로그인 감지: 알림 메일 발송

 

차이가 만드는 결과물의 차이

 

동일한 기능인데 결과 차이가 크다.

 

항목	Before (한 줄)	After (30줄)
질문 메시지 횟수	30개+	2~3개
개발 완료 후 재작업	거의 100%	거의 0%
QA 추가 발견 이슈	5~10개	0~1개
AI 코딩 결과물 품질	추측 50% 혼입	95% 의도와 일치
일정 추정 정확도	50% 빗나감	±10% 이내

 

바로 써먹는 PRD 템플릿과 작성 팁

 

말이 길었다. 이제 실제로 써먹을 수 있는 내용을 정리한다.

 

1페이지 PRD 템플릿 (작은 기능용)

 

# [기능명] PRD

## Why
- 문제 1줄
- 가설 1줄

## 사용자 스토리
[누가] [언제] [무엇을] 할 수 있어야 한다.

## 기능 명세
- 동사 단위로 쪼갠 항목 5~10개

## Out of Scope
- 만들지 않을 항목 명시

## 엣지 케이스 / 에러
- 케이스별 동작 정의

## 성공 지표
- 숫자로 표현

 

풀 PRD 템플릿 (큰 기능 / 제품용)

 

# [제품/기능명] PRD

## 1. 배경 및 문제 정의
## 2. 목표와 비목표 (Goals / Non-goals)
## 3. 사용자 페르소나와 시나리오
## 4. 기능 요구사항
   - 4.1 화면별 상세
   - 4.2 API 계약 / 데이터 스키마
   - 4.3 권한 / 인증
## 5. 엣지 케이스와 에러 처리
## 6. 성능 / 보안 / 접근성 요구사항
## 7. 마이그레이션 / 롤백 계획
## 8. Out of Scope
## 9. 성공 지표 및 측정 방법
## 10. 일정 / 마일스톤
## 11. 오픈 이슈

 

PRD 작성 시간을 줄이는 5가지 팁

 

1. PRFAQ로 시작한다: 1페이지 보도자료 형식으로 작성하면 핵심부터 잡힌다
2. 사용자 스토리를 먼저 쓴다: 한 문장을 만들고 거기서 기능을 뽑아내면 누락이 없다
3. Out of Scope를 먼저 쓴다: "만들지 않을 것"부터 적으면 스코프가 자동으로 정리된다
4. API 응답 예시를 박아 넣는다: JSON 한 덩어리가 글 30줄보다 명확하다
5. AI에 한 번 돌려본다: Cursor나 Claude Code에 PRD를 던져 "어떻게 구현하겠는가"라고 물어보면 모호한 부분이 즉시 드러난다

 

PRD 리뷰 체크리스트

 

마지막에 본인 PRD를 검수할 때 이 다섯 가지만 확인하면 80점은 확보된다.

 

• [ ] "왜"에 한 줄로 답할 수 있는가?
• [ ] 사용자 스토리가 한 문장으로 표현되는가?
• [ ] 기능 명세가 동사 단위로 쪼개져 있는가?
• [ ] Out of Scope가 명시되어 있는가?
• [ ] 엣지 케이스 / 에러 케이스가 최소 5개 있는가?

 

PRD 작성 방법은 개발자에게 무기다

 

PRD는 PM이 작성하는 행정 문서가 아니다. 개발자에게 PRD는 분쟁을 막는 무기이며 재작업을 0으로 만드는 보험이다. 좋은 PRD 한 페이지가 1주일의 야근을 막아 준다.

 

다시 정리한다.

 

• 모호한 PRD는 개발자가 가장 큰 손해를 본다
• 좋은 PRD에는 Why, 사용자 스토리, 동사 단위 명세, Out of Scope, 엣지 케이스, 성공 지표가 모두 들어간다
• 개발자가 직접 작성할 때는 API 계약, 에러 메시지, 권한, 성능, 롤백까지 챙겨야 한다
• AI 코딩 시대에는 PRD가 추측의 여지를 0으로 만들어야 LLM이 제대로 코드를 작성한다
• PRFAQ 같은 짧은 포맷이 AI에 더 잘 먹힌다
• 한 줄 PRD와 30줄 PRD는 결과물이 완전히 다르다

 

PRD 작성 방법을 익혀 두면 PM이 부실하게 던졌을 때 직접 보강할 수도 있고, 본인이 사이드 프로젝트를 할 때도 AI에 잘 먹히는 문서를 만들 수 있다. 개발자 PRD를 한번 제대로 작성해 보면 다음부터는 작성하지 않으면 불안할 정도가 된다. 오늘 하나 만들어 보기를 추천한다.