AI로 제품 요구사항 문서(PRD) 쓰는 법 (무료 템플릿)

제품 요구사항 문서(PRD)는 여러분이 무엇을 만들고 있는지, 누구를 위한 것인지, 무엇을 해야 하는지, 그리고 제대로 동작하는지 어떻게 알 수 있는지를 평이한 말로 적은 짧은 문서입니다. AI를 쓰면 훨씬 빨리 쓸 수 있습니다. 대충 적은 메모를 주면 구조화된 섹션, 사용자 스토리, 엣지 케이스로 바꿔 줍니다. 여러분의 역할은 AI가 대신 결정할 수 없는 부분, 즉 목표, 범위, 그리고 제외할 항목을 정하고 AI가 추가한 내용을 확인하는 것입니다.

이 가이드는 PRD에 무엇이 들어가야 하는지, 어떤 AI 어시스턴트로든 초안을 쓰는 단계별 방법, 각 섹션용 프롬프트, 그리고 그대로 복사해 쓸 수 있는 빈칸 템플릿을 다룹니다.

PRD의 역할 (그리고 아닌 것)

PRD는 네 가지 질문에 답합니다:

1. 우리는 왜 이것을 만들까? 어떤 문제를, 누구를 위해 해결할까?
2. 첫 버전에서 무엇을 해야 할까?
3. 아직 무엇을 하지 않을까?
4. 어떻게 해야 잘 됐다는 것을 알 수 있을까?

PRD는 기술 설계가 아닙니다. 어떤 데이터베이스나 프레임워크를 쓸지는 말하지 않습니다. 그것은 필요하다면 별도의 기술 명세서에 들어갑니다. 마케팅 브리프나 사업 계획서도 아닙니다. PRD를 제품의 동작에만 집중하게 하는 것이 모두에게 유용하게 만드는 이유입니다. 디자이너, 개발자, 승인하는 이해관계자, 또는 이를 코드로 바꾸는 AI 앱 빌더 모두가 이 문서를 보고 일할 수 있습니다.

누구에게 필요한가

• 1인 창업자는 범위가 커지기 전에 막고 싶을 때.
• 작은 팀은 “우리가 합의한 것”이 한 곳에 있어야 할 때.
• 프리랜서나 에이전시를 고용하는 사람은, 명확한 PRD가 있어야 더 정확한 견적을 받을 수 있으므로. 개발자 고용 또는 AI로 직접 만들기를 참고하세요.
• AI로 만드는 사람은, PRD의 사용자 스토리와 데이터 목록이 정리되지 않은 요청 목록보다 좋은 프롬프트가 되므로.

AI가 잘하는 것과 못하는 것

가장 흔한 실패는 위에서 두 번째 행이 뒤집힌 경우입니다. AI가 사용자, 시장 규모, 행동에 대해 그럴듯한 추측으로 빈틈을 자신 있게 채워 버리는 것입니다. AI가 사용자, 시장, 행동에 대해 쓴 내용은 사실이 아니라 검증해야 할 질문으로 다루세요.

1단계: 아는 것 쏟아내기

프롬프트를 쓰기 전에 대충 메모를 적으세요. 글머리 기호도 괜찮습니다. 다음 내용을 다루세요:

• 사용자 관점에서 본 문제를 한두 문장으로.
• 누가 그 문제를 겪는지. 구체적으로 쓰세요. “중소기업”이 아니라 “고객 10~40명을 맡은 프리랜서 장부 담당자”처럼요.
• 지금은 대신 무엇을 쓰는지 (스프레드시트, 이메일, 싫어하는 도구).
• 첫 버전을 성공으로 만들 한 가지 결과.
• 하지 않겠다고 이미 알고 있는 것.
• 확실한 제약: 마감, 예산, 휴대폰에서 동작해야 하는지, 이미 쓰는 도구와 연동해야 하는지.

문제를 겪는 사람과 한 번도 이야기해 보지 않았다면, 먼저 그것부터 하세요. 앱 아이디어 검증하는 법에 실용적인 방법이 있습니다. 추측에 기반한 PRD는 형식만 잘 갖춘 추측일 뿐입니다.

2단계: AI에게 첫 초안 부탁하기

메모를 붙여넣고 고정된 구조로 초안을 요청하세요. 잘 되는 프롬프트 예시:

제 제품에 대한 메모를 드립니다. 이것을 다음 섹션을 정확히 사용해서 제품 요구사항 문서로 바꿔 주세요: 요약, 문제, 사용자, 목표와 성공 지표, 범위(포함 / 제외), 인수 조건이 붙은 사용자 스토리, 데이터, 권한, 엣지 케이스, 미결 질문. 두 페이지 이내로 유지하세요. 사용자나 시장에 대한 사실을 지어내지 마세요. 메모에 없는 내용은 미결 질문에 질문으로 적어 주세요.

마지막 지시가 중요합니다. 모르는 부분을 채우는 대신 ‘미결 질문’으로 보내라고 하면 훨씬 정직한 초안이 나옵니다.

3단계: 각 섹션 다듬기

초안을 섹션별로 하나씩 살펴보세요. 다음 후속 프롬프트가 도움이 됩니다:

문제와 사용자

문제 정의를 사용자 관점에서 한두 문장으로 다시 써 주세요. 해결책 관련 단어는 빼 주세요.

문제 정의에 여러분의 제품이 언급되어 있다면, 그것은 문제가 아니라 해결책을 설명하고 있는 것입니다.

목표와 성공 지표

첫 버전을 위한 성공 지표를 세 가지 제안해 주세요. 소수의 사용자로 첫 달에 측정할 수 있어야 합니다. 각각 어떻게 측정할지도 적어 주세요.

그중 한두 개를 고르세요. “사용자 20명이 한 달 동안 매주 사용한다”는 측정 가능합니다. “생산성을 높인다”는 측정할 수 없습니다.

범위

이 PRD에 있는 항목 중, 핵심 흐름을 깨지 않고 나중 버전으로 미룰 수 있는 것을 모두 나열해 주세요.

AI 도구는 기능을 더하는 경향이 있습니다. 이 프롬프트는 반대로 하게 만듭니다. 냉정하게 하세요. 대부분의 첫 버전 PRD는 너무 큽니다. MVP란 무엇인가에서 작은 첫 버전이 더 많은 것을 가르쳐 주는 이유를 설명합니다.

사용자 스토리와 인수 조건

각 요구사항을 사용자 스토리(“[사용자]로서, [행동]을 원한다, 그래야 [결과]이기 때문이다”)로 쓰고, 각각에 Given / When / Then 형식의 인수 조건을 두세 개씩 붙여 주세요.

인수 조건은 나중에 테스트할 때 쓸 체크리스트입니다. “예약된 시간대가 있을 때, 다른 고객이 캘린더를 보면, 그 시간대는 표시되지 않는다”는 테스트할 수 있습니다. “예약이 잘 동작한다”는 테스트할 수 없습니다.

엣지 케이스와 권한

각 사용자 스토리에 대해, 데이터가 비어 있을 때, 잘못된 입력이 들어왔을 때, 네트워크가 느리거나 요청이 실패했을 때, 그리고 접근 권한이 없는 사용자가 들어왔을 때 어떻게 되는지 나열해 주세요.

여기서 AI가 진가를 발휘합니다. 사람들이 자주 놓치는 빈 상태와 권한 빈틈을 빠르게 찾아냅니다.

4단계: 회의적인 시각으로 검토하기

전체를 한 번 더 읽으며 다음을 확인하세요:

• 사용자에 대한 모든 주장이 여러분이나 조사에서 나온 것이지, AI가 쓴 것이 아닌지.
• **범위의 ‘제외’**가 ‘포함’만큼은 길거나 그보다 긴지.
• 각 사용자 스토리의 인수 조건을 여러분에게 묻지 않고도 누군가 테스트할 수 있는지.
• 데이터 섹션이 앱이 보관하는 모든 종류의 기록과 그것을 볼 수 있는 사람을 나열하는지.
• 미결 질문마다 담당자와 날짜가 있는지.
• 실제 제약이 아닌 기술 내용이 몰래 들어가지 않았는지 (“오프라인에서 동작해야 한다”는 요구사항이지만, “Redis를 쓴다”는 아닙니다).

그런 다음 제품을 쓰거나 만들 한 사람에게 보여 주고, 무엇이 불분명한지 물어보세요. 그 사람의 질문이 바로 빈틈입니다.

빈칸 채우기 PRD 템플릿

이것을 문서에 복사하고 대괄호를 채우세요. 정말 해당되지 않는 섹션은 지우세요.

제품 이름: [이름] 담당자: [결정을 책임지는 사람] 상태: [초안 / 검토 중 / 합의 완료] — 마지막 수정: [날짜]

1. 요약

[두세 문장: 무엇인지, 누구를 위한 것인지, 주요 결과는 무엇인지.]

2. 문제

[사용자 관점에서 본 문제. 지금 무엇을 하고 있고 왜 불편한지.]

3. 사용자

4. 목표와 성공 지표

• 목표: [첫 버전이 달성해야 하는 결과]
• 지표: [측정 방법과 목표치]
• 비목표: [사람들이 이 버전이 하려고 한다고 오해할 수 있지만, 아닌 것]

5. 범위

첫 버전에 포함:

• [기능]
• [기능]

첫 버전에서 제외:

• [기능, 그리고 나중에 해도 되는 이유]
• [기능, 그리고 나중에 해도 되는 이유]

6. 사용자 스토리

스토리 1: [사용자]로서, [행동]을 원한다, 그래야 [결과]이기 때문이다.

• Given [상황], when [행동], then [결과].
• Given [상황], when [행동], then [결과].

스토리 2: [사용자]로서, [행동]을 원한다, 그래야 [결과]이기 때문이다.

• Given [상황], when [행동], then [결과].

7. 데이터

8. 권한

[누가 로그인할 수 있는지, 어떤 역할이 있는지, 각 역할이 보고 바꿀 수 있는 것.]

9. 엣지 케이스

• [빈 상태: 아직 데이터가 없을 때 무엇이 보이는지]
• [잘못된 입력: 잘못된 이메일이나 누락된 필드가 들어왔을 때 어떻게 되는지]
• [접근: 보면 안 되는 페이지를 누군가 열었을 때 어떻게 되는지]

10. 연동과 제약

[결제, 이메일, 기존 도구, 마감, 예산, 반드시 동작해야 하는 기기.]

11. 미결 질문

PRD에서 프롬프트로

좋은 PRD는 AI 앱 빌더용 프롬프트로 거의 그대로 바뀝니다:

• 요약, 사용자, 데이터 표가 첫 프롬프트가 됩니다.
• 각 사용자 스토리가 후속 프롬프트 하나가 됩니다.
• 각 인수 조건이 미리보기에서 확인할 항목이 됩니다.
• ‘첫 버전에서 제외’ 목록은 아직 요청하지 않을 것들입니다.

PRD 전체를 붙여넣고 모든 것을 한꺼번에 요청하기보다, 스토리를 하나씩 만들고 다음으로 넘어가기 전에 인수 조건을 확인하는 편이 훨씬 안정적입니다. AI 앱 빌더용 프롬프트 쓰는 법에서 프롬프트 쪽을 더 자세히 다룹니다.

흔한 실수

• 해결책을 문제로 쓰기. “사용자에게 대시보드가 필요하다”는 해결책입니다. “사장님은 청구서를 하나하나 열어보지 않고는 어떤 청구서가 연체되었는지 알 수 없다”가 문제입니다.
• ‘범위 밖’ 섹션이 없음. 없으면 대화할 때마다 범위가 다시 열립니다.
• AI가 사용자를 지어내게 두기. AI가 만든 페르소나는 실제처럼 느껴지지만 실제가 아닙니다.
• 측정할 수 없는 지표. 셀 방법이 없다면 지표가 아닙니다.
• 한 번도 업데이트하지 않기. 만들고 있는 것과 맞지 않는 PRD는 아예 없는 것보다 나쁩니다. ‘마지막 수정’ 날짜를 적고, 결정이 바뀔 때마다 고치세요.

Mythex에서 PRD 사용하기

Mythex에서 만든다면 채팅에 PRD를 바로 붙여넣을 수 있습니다. PRD에는 Plan(계획) 모드로 시작하는 것이 잘 맞습니다. 에이전트가 문서를 읽고 접근 방식과 단계별 체크리스트를 제안하며, 여러분은 계획 탭에서 검토할 수 있습니다. **Build(빌드)**를 누르기 전까지는 파일을 고치지 않습니다. 대상 사용자, 브랜드, 규칙처럼 항상 적용되어야 하는 내용은 프로젝트 지식으로 저장해 두면 채팅마다 반복하지 않아도 됩니다. Build, Plan, Ask 모드에 대한 설명은 채팅 문서를 참고하세요. 전체 문서를 쓰기 전에 첫 버전이 어떻게 보일지 보고 싶다면 템플릿이 빠른 방법입니다.

자주 묻는 질문