IT 기획 실무: AI로 1시간 만에 고퀄리티 PRD(기획서) 작성하는 법
IT 기획 실무: AI로 1시간 만에 고퀄리티 PRD(기획서) 작성하는 법 실전 프로세스
서론: “빈 화면”을 깨는 가장 빠른 방법
기획자의 최대 적은 종종 경쟁사가 아니라 아무것도 없는 문서 첫 화면입니다. PRD(Product Requirement Document)는 배경, 목표, 유저 스토리, 기능 요구사항, 정책, 예외 케이스까지 다 담아야 해서 제대로 쓰면 며칠이 훌쩍 지나가죠.
하지만 AI를 “대필”이 아니라 논리 파트너로 쓰면 흐름이 바뀝니다. Perplexity로 근거를 모으고, Claude로 구조를 세우고, 예외 케이스로 디테일을 두껍게 만들면 1시간 내외로 “공유 가능한 수준의 PRD”를 만들 수 있습니다.
① 근거 있는 방향성
② 읽기 쉬운 구조
③ 개발 커뮤니케이션이 줄어드는 정책/예외 케이스를 1시간 안에 확보하기
(PRD가 아니라 PRD의 “뼈대 + 근거 + 리스크 지도”를 만드는 느낌으로 가면 속도가 납니다.)
1시간 PRD 타임박스 플랜
| 시간 | 할 일 | 산출물 |
|---|---|---|
| 0~10분 | 문제 정의, 타겟, 목표(성공 지표 초안) | PRD 상단 요약(1페이지) |
| 10~25분 | Perplexity로 시장조사/벤치마킹 표 뽑기 | 경쟁/레퍼런스 표 + 차별화 후보 |
| 25~45분 | Claude로 PRD 초안 생성(유저 스토리, 요구사항) | PRD 본문 초안 |
| 45~60분 | 예외 케이스/정책 질문으로 고도화 + 확정/가설 라벨링 | 정책/예외 케이스 섹션 강화 |
- 먼저 빈칸을 채워 문서가 “흐르도록” 만든다.
- 그 다음 개발 비용이 큰 리스크(결제/권한/정산/취소)를 두껍게 한다.
- 마지막으로 확정(Decision)과 검증 필요(Assumption)를 분리해 표시한다.
1단계. 시장 조사와 벤치마킹 자동화 (Perplexity 활용)
기획의 근거가 되는 시장 조사와 경쟁사 분석을 “감”으로 하면, PRD가 회의실에서 종이비행기가 되기 쉽습니다. Perplexity는 실시간 웹 검색 기반으로 출처가 명확한 요약을 얻는 데 유리합니다.
핵심 프롬프트 전략
최근 1년 내 출시된 국내외 '구독형 커머스' 서비스들의 주요 기능과 수익 모델을 표로 정리해 줘.
특히 유저 이탈을 막기 위한 '리텐션 장치' 위주로 분석해 줘.
가능하면 각 항목에 출처 링크도 함께 제공해 줘.기획자의 Role: “수집”이 아니라 “선택”
- 공통 기능 vs 차별화 장치를 분리
- 우리 서비스에 적용 가능한 차별화 후보 3개만 고른다 (많으면 오히려 개발 난이도만 오른다)
- 각 후보에 대해 “왜 필요한가(가설)”를 한 문장으로 적는다
벤치마킹 표가 길어지면 PRD가 아니라 “위키 백과”가 됩니다. PRD에는 결정에 필요한 만큼만 남기고, 나머지는 별도 레퍼런스 문서로 떼어내세요.
2단계. 서비스 로직과 유저 스토리 설계 (Claude 활용)
시장 조사가 끝났다면 이제 “문서의 뼈대”를 세울 차례입니다. Claude는 긴 문맥을 유지하면서 구조화된 문서 초안을 만드는 데 강합니다. 여기서 중요한 건 “멋진 문장”이 아니라 빠르게 논리 구조를 확보하는 것입니다.
PRD 초안 생성을 위한 프롬프트
우리는 [서비스명]을 만들 거야.
주요 타겟은 [대상]이고, 핵심 문제는 [문제]야.
핵심 기능은 [A, B, C]이고, 성공 지표는 [KPI 후보 2~3개]야.
이 정보를 바탕으로 표준 PRD 양식으로 초안을 작성해 줘:
1) 배경/문제정의
2) 목표(정량/정성)
3) 주요 유저 스토리(As a ~ I want ~ so that)
4) 기능 요구사항(MVP/추후)
5) 정책(권한, 결제/환불, 데이터 보존)
6) 비기능 요구사항(성능, 보안, 로그/모니터링, 접근성)
각 섹션에 '확정'과 '검증 필요'를 구분해서 라벨도 붙여 줘.기획자의 Role: “현실 필터” 장착
| 점검 포인트 | 확인 질문 |
|---|---|
| 기술 제약 | 외부 API/결제 모듈/데이터 모델/권한 구조 상 가능한가? |
| 비즈니스 우선순위 | 이번 분기에 반드시 해야 하는 목표와 연결되는가? |
| 운영/CS | 이 기능이 들어오면 CS는 어떤 문의가 늘어날까? |
| 정산/회계 | 환불, 부분 취소, 프로모션 비용 처리가 정의돼 있는가? |
AI가 “이 기능은 쉽습니다”라고 말하면, 개발자 입장에서는 “아, 또 쉽구나… 쉽겠지…”가 됩니다. PRD에서 “쉽다/어렵다” 대신 제약 조건과 대안을 적으면 신뢰도가 급상승합니다.
3단계. 예외 케이스(Edge Case) 및 정책 고도화
PRD의 퀄리티는 “예외 상황을 얼마나 꼼꼼하게 고려했는가”에서 갈립니다. 예외 케이스가 부족하면 개발 중간에 질문이 폭발하고, QA에서 지뢰가 터지고, 일정은… 음, 일정은 스스로 산책을 떠납니다 🐾
놓치기 쉬운 정책 질문 프롬프트
이 서비스의 '결제 취소' 프로세스에서 발생할 수 있는 예외 상황 10가지만 리스트업해 줘.
예시는 아래처럼 단계별로:
- 결제 완료 후 배송 시작 직전 취소
- 부분 취소(옵션/수량 일부) 가능 여부
- 쿠폰/포인트 사용 시 환급 규칙
각 예외 케이스마다 '필요한 정책 결정'도 한 줄로 함께 써 줘.예외 케이스를 “정책”으로 굳히는 3단계
- 발생 가능성: 실제로 사용자/운영에서 자주 발생하는가?
- 영향도: 돈/신뢰/법적 리스크에 영향이 큰가?
- 처리 원칙: “누가, 언제, 어떻게” 처리하고 로그는 남기는가?
- 원칙: 결제 취소는 [배송 시작 전]까지 가능하다.
- 예외: [제작/커스텀 상품]은 결제 완료 후 취소 불가.
- 정산: 쿠폰은 [즉시 재발급/조건부 재발급/소멸] 중 무엇인지 명시.
- 로그: 취소 요청 시점, 처리자, 사유 코드, 환불 금액을 로그로 남긴다.
💡 AI 기획서 작성 시 주의할 점 (Golden Rules)
1) 데이터 보안 주의
- 회사 내부 기밀 지표, 고객사 이름, 개인정보(이메일/전화번호/주문번호) 등은 프롬프트에 그대로 넣지 않는다.
- 필요하면 “범주형”으로 치환: 예) MAU 120만 → “MAU 100만대”, 고객사 A → “엔터프라이즈 고객사”.
2) 팩트 체크 필수
- AI는 존재하지 않는 기능을 있는 것처럼 말할 수 있다.
- 특히 법적 규제, 결제/정산, 기술적 실현 가능성은 “확정” 대신 “검증 필요”로 라벨링한다.
3) 질문이 실력이다
- 질문이 구체적일수록 결과물이 선명해진다.
- 예: “취소 정책” 대신 “배송 상태별 취소 가능 구간 + 환불 규칙 + 쿠폰/포인트 처리”로 쪼개서 묻기
“이건 확정(Decision)이고, 이건 검증 필요(Assumption)입니다.” PRD에 이 문장이 자주 보이면, 팀의 일정이 덜 흔들립니다.
바로 복붙 가능한 PRD 템플릿 (AI와 함께 채우기)
아래 템플릿은 “문서 빈칸 공포”를 박살 내는 용도입니다. 그대로 복사해서 쓰세요.
[PRD] 서비스명: ________
버전: v0.1 작성일: 2026-02-18 작성자: ________
1) 배경/문제 정의
- 현재 문제:
- 왜 지금인가:
- 참고 근거(링크/자료):
2) 목표
- 정량 목표(KPI): (예: 전환율, 재방문율, 환불률, CAC)
- 정성 목표: (예: 신뢰, 편의, 속도)
- 비목표(하지 않을 것):
3) 타겟/유저 페르소나
- 주요 타겟:
- 핵심 니즈:
- 사용 맥락(언제/어디서/왜):
4) 유저 스토리
- US-1: As a ___, I want ___ so that ___.
- US-2:
- 우선순위 기준(가치/난이도/리스크):
5) 기능 요구사항
5-1. MVP
- FR-1:
- FR-2:
5-2. 추후(Backlog)
- BF-1:
6) 정책(Policy)
- 권한/역할:
- 결제/취소/환불:
- 쿠폰/포인트:
- 데이터 보존/삭제:
- 알림(푸시/메일) 발송 기준:
7) 예외 케이스(Edge Case)
- EC-1:
- EC-2:
- EC-3:
8) 비기능 요구사항(Non-Functional)
- 성능:
- 보안:
- 로그/모니터링:
- 접근성/호환성:
9) 오픈 이슈(검증 필요)
- A-1:
- A-2:
템플릿을 AI에게 던질 때는 이렇게 “채움 방식”을 지정하면 결과가 깔끔해집니다.
위 PRD 템플릿을 기준으로,
각 항목을 1) 확정(Decision) 2) 검증 필요(Assumption)로 구분해 채워 줘.
특히 6) 정책과 7) 예외 케이스는 결제/취소/환불/권한을 중심으로 두껍게 작성해 줘.결론: 기획자는 ‘결정’하는 사람입니다
AI는 PRD의 작성 속도를 올려줍니다. 하지만 서비스의 방향성을 결정하는 건 기획자의 몫입니다. AI로 아낀 시간을 “문장 다듬기”에 쓰기보다, 무엇을 할지/무엇을 하지 않을지를 더 선명하게 만드는 데 투자해 보세요.
그러면 PRD는 단순한 문서가 아니라, 팀이 같은 지도를 보게 만드는 의사결정 장치가 됩니다. 그리고 회의실에서 종이비행기 대신, 진짜로 날아가는 제품이 나옵니다 🛫
FAQ
Q Perplexity와 Claude를 PRD 작성에 같이 쓰는 이유는?
A Perplexity는 “출처 기반 리서치”, Claude는 “긴 문서 구조화”에 강합니다. 역할 분리하면 속도와 품질이 함께 올라갑니다.
Q 1시간 PRD는 대충이라는 뜻 아닌가요?
A 1시간의 목표는 “완벽한 문서”가 아니라 “공유 가능한 의사결정 초안”입니다. 이후 2차 개선은 개발/디자인/QA 질문으로 보강하면 됩니다.
Q 예외 케이스는 어떻게 우선순위를 잡죠?
A 발생 확률과 영향도를 기준으로 정렬하세요. 결제·정산·권한·환불처럼 돈과 신뢰가 걸린 영역은 무조건 상단입니다.
Q AI가 만든 문장을 그대로 PRD에 넣어도 되나요?
A 가능하지만, “확정 vs 검증 필요” 라벨을 붙여 문서의 신뢰도를 지키는 게 중요합니다. 확정처럼 보이게 쓰면 나중에 비용이 큽니다.
Q 내부 데이터 없이도 PRD가 의미 있나요?
A 충분합니다. 내부 지표는 범주형으로 치환하고, 의사결정에 필요한 구조와 정책을 먼저 만든 뒤 실제 수치는 로컬에서 교체하면 됩니다.
Q PRD에서 개발자 질문을 줄이는 한 문장은?
A “이 케이스는 정책으로 확정(Decision)이며, 이 항목은 검증 필요(Assumption)입니다.” 이 문장이 PRD에 반복되면 질문이 ‘정리’됩니다.