Claude Code·Codex로 PRD 초안 만들기: AI에게 기획 정리시키는 프롬프트 구조

아이디어는 선명한데 문서로 옮기려 하면 자꾸 멈춥니다. 기능 이름은 떠오르지만 누구의 어떤 문제를 해결하는지, 어디까지 만들지, 실패하면 어떻게 처리할지는 흐려지기 때문입니다. 이때 Claude Code나 Codex를 ‘대신 기획하는 사람’으로 쓰기보다, 흩어진 생각을 질문하고 구조화하는 편집자로 쓰면 PRD 초안을 훨씬 빠르게 만들 수 있습니다.

조코헌트에는 현재 202개의 프로덕트와 160명의 메이커가 출시되어 있습니다. 혼자 만드는 제품이 많을수록 긴 문서보다, 다음 작업을 결정하게 해주는 짧고 검토 가능한 PRD가 중요합니다.

1. 먼저 AI에게 넘길 재료를 정리한다

아이디어를 한 문장으로 압축하기

프롬프트를 쓰기 전에 다음 네 문장을 메모하세요.

• 누구를 위한 제품인가?
• 사용자는 어떤 상황에서 불편을 겪는가?
• 제품은 어떤 행동이나 결과를 돕는가?
• 첫 출시에서 반드시 증명할 가설은 무엇인가?

완벽한 답이 아니어도 됩니다. “직장인이 매일 반복하는 자료 정리를 짧게 끝내도록 돕는다”처럼 현재 알고 있는 범위만 적으세요. 모르는 부분까지 그럴듯하게 채우면 AI가 만든 가정이 사실처럼 PRD에 섞일 수 있습니다.

아이디어를 더 좁히는 과정은 코딩 전에 멈추는 30분: 잘못된 MVP를 피하는 아이디어 검증 체크리스트와 함께 확인하면 좋습니다.

맥락과 제약을 함께 전달하기

다음 요소도 한 번에 붙입니다.

• 현재 가진 기술 스택과 개발 시간
• 목표 사용자의 숙련도
• 출시에서 제외할 기능
• 성공 여부를 판단할 관찰 가능한 행동
• 아직 확인하지 못한 가정

특히 “이번 버전에서 하지 않을 일”을 명시하세요. PRD의 가치는 아이디어를 늘리는 데만 있지 않고, 지금 하지 않을 일을 합의하는 데도 있습니다.

2. 답변보다 질문을 먼저 시킨다

처음부터 “PRD를 작성해줘”라고 하면 빈칸을 임의의 가정으로 채울 가능성이 커집니다. 먼저 질문 모드로 제한하는 것이 좋습니다.

너는 1인 개발자의 기획 편집자다. 아래 아이디어를 바탕으로 PRD를 쓰기 전에, 결정이 필요한 질문을 최대 10개만 우선순위 순서로 물어봐라. 이미 제공한 정보는 다시 묻지 말고, 답을 모르면 ‘미정’으로 표시해라. 질문은 사용자, 문제, 핵심 흐름, 범위, 예외 상황, 성공 판단 기준으로 나눠라.

질문을 받은 뒤에는 한꺼번에 모두 답하려 하지 않아도 됩니다. 중요한 질문부터 답하고, 나머지는 “첫 버전에서는 가정으로 둔다”고 표시하세요. 이 방식은 AI의 유창함과 실제 의사결정을 분리해줍니다.

3. 섹션별로 쪼개서 생성한다

문제와 사용자부터 확정하기

첫 요청에서는 문제 정의, 목표 사용자, 사용 시점, 기존 대안을 작성하게 하세요. 이때 기능 목록은 뒤로 미룹니다. 기능이 먼저 나오면 해결하려는 문제가 기능 설명에 가려지기 쉽습니다.

흐름과 범위를 다음에 만든다

두 번째 요청에서는 핵심 사용자 흐름과 MVP 범위를 생성합니다.

앞서 확정된 문제 정의만 사용해, 사용자가 처음 방문한 순간부터 핵심 결과를 얻는 과정까지 5~7단계로 정리해라. 각 단계에 입력, 시스템의 처리, 사용자에게 보이는 결과를 적어라. 필수 기능과 다음 버전 후보를 분리하고, 근거 없는 기능은 제안하지 마라.

그다음 데이터, 권한, 알림, 오류 처리처럼 구현에 영향을 주는 항목을 별도로 요청합니다. 기존 PRD의 기본 구성은 PRD(제품 요구사항 문서)란 무엇인가: 1인 개발자를 위한 가벼운 PRD 작성 가이드에서 참고할 수 있습니다.

4. 비범위와 엣지케이스를 직접 찌른다

비범위 질문

AI는 사용자가 좋아할 만한 기능을 확장하는 데 익숙하지만, 무엇을 만들지 않는지는 스스로 확정하기 어렵습니다. 다음처럼 요청해보세요.

이 PRD에서 암묵적으로 추가된 기능을 찾아라. 첫 출시에서 제외해야 할 기능, 이유, 나중에 재검토할 조건을 표로 정리해라. 팀이 커졌다는 가정이나 대규모 사용량을 전제로 하지 마라.

“모바일 앱도 필요한가?”, “팀 기능이 필요한가?”처럼 당장 답하지 않아도 되는 질문을 보류 목록으로 보내면 범위가 안정됩니다.

엣지케이스 질문

정상 흐름만으로는 개발 중 재작업이 생깁니다. 빈 입력, 중복 요청, 취소, 권한 없음, 네트워크 오류, 데이터 삭제, 재시도 상황을 각각 물어보세요. 단, 모든 예외를 구현하라는 뜻은 아닙니다. 발생 가능성과 피해를 기준으로 ‘이번 버전에 처리’, ‘안내만 제공’, ‘다음 버전으로 보류’를 나누는 것이 핵심입니다.

5. PRD를 실행 가능한 문서로 검토한다

초안이 나오면 AI에게 문장 다듬기를 시키기보다 모순 검사를 맡기세요.

• 문제 정의와 기능이 직접 연결되는가?
• 사용자가 완료했다고 판단할 기준이 있는가?
• MVP에서 제외한다고 한 기능이 다른 요구사항에 다시 등장하지 않는가?
• 개발자가 추가로 결정해야 할 질문이 남아 있는가?
• 각 기능의 우선순위와 검증 방법이 적혀 있는가?

마지막 프롬프트는 이렇게 구성할 수 있습니다.

아래 PRD를 구현하지 말고 검토만 해라. 모순, 빠진 결정, 과도한 범위, 비현실적인 가정을 찾아 각각 ‘문제-영향-확인 질문-수정 제안’ 형식으로 작성해라. 원문에 없는 수치나 사용자 조사를 만들어내지 마라.

PRD가 끝나면 바로 코딩으로 뛰어들기보다, 핵심 가설을 랜딩페이지나 대기자 명단으로 확인해보세요. 랜딩페이지 한 장으로 수요 검증하기: 출시 전 대기자 명단 모으는 실전 방법처럼 문서의 가정을 실제 반응으로 바꾸는 단계가 필요합니다. 좋은 PRD는 길고 완벽한 문서가 아니라, 다음 질문과 다음 행동을 선명하게 만드는 작업 문서입니다.