좋은 제품 요구사항 문서(PRD)를 어떻게 작성하나요?

Question

Accepted Answer

**제품 요구사항 문서(PRD, Product Requirements Document)**는 *무엇을* 만들고, *왜* 만들며, *성공했는지 어떻게 알 것인지*를 설명합니다. 그래서 엔지니어링과 디자인이 끊임없는 확인 없이 올바른 것을 만들 수 있게 합니다. 좋은 PRD는 관료적 서류가 아니라 사고의 도구이자 정렬의 산출물입니다.

## 탄탄한 PRD 개요

```text
1. 문제 / 맥락 → 어떤 문제, 누구를 위해, 왜 지금
2. 목표 & 성공 지표 → 어떤 성과, 어떻게 측정
3. 비목표(Non-goals) → 이것이 명시적으로 다루지 않는 것
4. user story / 요구사항 → 무엇을 해야 하는가
5. UX → 흐름, 와이어프레임, 핵심 상태
6. 엣지 케이스 → 오류, 빈 상태, 한계
7. 의존성 & 리스크 → 무엇이 이것을 막거나 깨뜨릴 수 있는가
8. 미해결 질문 → 해소해야 할 알려진 미지수
```

## 왜로 시작하라

단 하나의 가장 중요한 섹션은 **문제와 목표**입니다. 팀이 *왜*와 *성공이 어떤 모습인지*를 이해하면, 당신이 명세한 것보다 더 나은 해결책을 찾아내는 경우가 많습니다. 단순한 기능 명세에 그치는 PRD는 이를 놓칩니다.

## 비목표는 과소평가된다

무엇이 범위 밖인지 명시적으로 밝히면 scope creep과 "하는 김에..."의 함정을 막습니다. 이는 요구사항 자체만큼이나 가치 있습니다.

## 흔한 함정

```text
✗ 어떻게(HOW)를 과도하게 명세 → 엔지니어링의 더 나은 아이디어를 가둔다
✗ 성공 지표 없음 → 효과가 있었는지 알 수 없다
✗ 혼자 작성 → 문제를 일찍 잡으려면 엔지니어링/디자인을 참여시켜라
✗ 고정된 것으로 취급 → PRD는 살아 있는 문서다
```

## 왜 중요한가

대부분의 재작업은 정렬 실패에서 옵니다. 팀이 필요했던 것이 아니라 요청받은 것을 만든 것이죠.

명확한 PRD는 누군가 코드를 쓰기 *전에* 그런 빈틈을 드러냅니다.

또한 *당신*이 문제를 끝까지 생각하도록 강제합니다.

목표와 성공 지표를 명확히 쓸 수 없다면, 아직 그것을 만들 만큼 문제를 잘 이해하지 못한 것입니다.