PRD (제품 요구사항 문서)

만들기 전에 합의할 내용을 남긴다

‘문의 관리 앱을 만들어줘’라는 요청만으로는 누가 어떤 문의를 관리하고 언제 처리가 끝나는지 알기 어렵습니다. PRD는 이런 제품·기능의 요구사항을 공유하는 문서입니다.

Atlassian의 PRD 안내는 제품의 목적과 기능, 사용자 요구를 정리하는 역할을 설명합니다. 문서의 이름이나 양식보다 팀이 같은 요구를 보고 있는지가 중요합니다.

작은 기능의 PRD 예시

다음은 설명을 위한 가상의 문의 목록 기능입니다.

빈칸을 AI가 알아서 채운 뒤 합의된 요구로 취급하지 않습니다. 모르는 조건을 질문으로 남기면 구현할 범위와 확인할 범위를 나눌 수 있습니다.

복사해서 쓰는 PRD 템플릿

아래 양식을 복사해 기능 하나부터 작성해 보세요. 정해지지 않은 항목은 ‘미정’으로 남기고, 확인할 사람과 질문을 적습니다.

# 기능 이름:
작성일 / 담당자:

## 사용자와 문제
- 누가 사용하는가:
- 지금 어떤 어려움이 있는가:
- 이 기능으로 무엇이 달라져야 하는가:

## 이번에 만들 범위
- 반드시 필요한 기능:
- 이번에 만들지 않을 기능:

## 사용 흐름과 데이터
- 사용자가 시작해서 끝내는 순서:
- 입력받거나 조회할 데이터:
- 저장할 데이터와 조회·수정할 수 있는 사람:

## 완료 기준
- 어떤 상황에서:
- 사용자가 무엇을 하면:
- 어떤 결과가 나와야 하는가:
- 빈 입력·실패·권한 없음은 어떻게 처리하는가:

## 제약과 미결 사항
- 기존 시스템·도구·보안 제약:
- 확인할 질문 / 확인할 사람:

## 변경 기록
- 바뀐 요구 / 이유 / 합의한 날짜:

완료 기준은 직접 재현할 수 있게 쓴다

가상의 문의 관리 앱이라면 다음처럼 확인합니다. 팀에서 합의한 요구에 맞춰 항목을 고쳐 쓰세요.

AI에게는 ‘이 PRD에서 모호하거나 서로 충돌하는 조건을 질문으로 정리해 줘. 미정인 요구는 임의로 확정하지 마’라고 요청할 수 있습니다. 질문에 답하고 범위를 합의한 뒤 구현을 시작하세요.

업무 쪼개기와 구현 계획을 연결한다

업무 쪼개기는 원래 업무에서 무엇을 입력받아 어떻게 처리하는지 살펴봅니다. PRD는 그중 제품으로 만들 부분의 요구사항을 정리합니다. 구현 계획은 어떤 구조와 순서로 만들지 다룹니다.

기술 선택을 너무 일찍 고정하면 사용자의 문제가 아니라 선택한 도구에 맞춰 요구를 바꾸기 쉽습니다. 다만 이미 정해진 시스템이나 접근 제한은 실제 제약이므로 명시해야 합니다.

가상 화면과 실제 동작의 완료 기준을 나눈다

BOAZ의 리더 교육 교안은 PRD를 바탕으로 가상 데이터를 사용한 작은 데모를 만들고, 이후 직접 입력과 저장을 붙이는 순서를 다룹니다. 이때 데모에서 확인한 것과 실제 운영에서 확인할 것은 다릅니다.

화면의 버튼이 보이는지, 입력한 데이터가 데이터베이스에 저장되는지, 다른 사용자의 데이터가 섞이지 않는지를 각각 확인합니다. 외부 정보를 사용한다면 API의 응답 실패와 접근 조건도 요구사항에 반영합니다.

AI로 PRD 작성하기

AI에게 PRD를 쓰게 할 때는 빈 문서를 통째로 맡기기보다 위 템플릿의 항목을 순서대로 채우게 합니다. 먼저 누가 어떤 문제를 겪는지와 이번에 만들 범위를 사람이 적고, AI에게는 사용 흐름과 데이터, 완료 기준의 초안을 요청합니다.

AI가 쓴 초안은 세 가지를 확인합니다. 사용자 문제가 실제 상황과 맞는지, 범위에 없던 기능이 추가되지 않았는지, 완료 기준이 눈으로 확인할 수 있는 문장인지입니다. 합의하지 않은 내용은 제안으로 표시해 두고, 작은 구현으로 핵심 가정을 먼저 확인한 뒤 문서에 반영합니다.

AI의 기능 제안을 범위와 대조한다

AI는 간단한 문의 목록에 통계·알림·관리자 화면을 덧붙일 수 있습니다. 유용한 제안일 수 있지만 이번 과제의 완료 조건과는 별개입니다.

이번에 만들 기능과 나중에 검토할 기능을 구분하고, 실제 필요한 기능 하나를 끝까지 확인합니다. 불분명한 요구는 설명이나 작은 화면으로 확인한 뒤 문서를 갱신합니다. 바이브 코딩에서도 이런 합의가 다음 수정을 판단할 기준이 됩니다.

PRD도 결과를 보고 고친다

문서를 처음에 완성한 뒤 고정하기보다, 실행과 사용자 확인에서 바뀐 판단을 남깁니다. 기능을 뺐다면 이유를, 완료 기준이 바뀌었다면 적용 범위를 기록합니다.

검증 Loop는 문서에 적힌 요구와 실제 결과를 대조합니다. 문서가 최신이어도 구현이 따라오지 않았을 수 있고, 구현을 고쳤어도 문서가 오래됐을 수 있습니다. 두 상태를 함께 확인해야 다음 작업이 같은 기준에서 시작됩니다.

팀의 실제 과제로 연습하기

PRD를 써도 같은 질문이 개발 단계에서 반복된다면, 문서 양식보다 누가 어떤 정책과 완료 기준을 합의하는지 살펴볼 때입니다. PO·PM·디자이너의 제품 기획과 검증 방식에서 실제 과제를 다루는 접근을, 제품팀 AX 진행 사례에서 진단과 후속 점검 과정을 확인할 수 있습니다.

기업 AI 교육·AX 워크숍에서는 실제 업무를 바탕으로 요구사항을 정리하고 작동하는 결과물을 확인하는 과정을 다룹니다.