GPT로 PRD를 ‘생각하게 만드는 법’
왜 PRD를 ‘쓰게’ 하는 것이 아니라 ‘생각하게’ 해야 하는가
PRD(Product Requirements Document)는 꼭 필요할까요?
저는 소프트웨어 개발에 있어
“무조건적으로 필요한 개발 문서/개발 방법론은 없다”고 생각합니다.
필요하면 쓰고, 필요하지 않으면 안 쓰면 될 뿐이죠.
중요한 건 해당 방법론을 쓰는 이유와 당위성입니다.
조직의 현재 상황, 문제의 성격, 팀의 역량에 따라
PRD 혹은 6pager 같은 문서가 “필요한 순간”이 옵니다.
PRD가 필요한 이유는 ‘문서’가 아니라
‘대합의(Alignment)’ 때문
PRD/6pager는 결국 Alignment 문서입니다.
왜 이 일을 해야 하는지
어떤 방식으로 진행할지
어떤 기준으로 성과를 판단할지
즉, 조직 전체가 같은 방향을 바라보게 만드는 절차가 필요할 때 작성합니다.
저는 보통 개발 공수가 2주~1달 이상 필요할 경우
PRD 작성이 필요하다고 조언합니다.
그 정도 볼륨의 일감이면
누구나 자신의 시각대로 문제를 판단할 수 있어
파편화가 쉽게 발생합니다.
그걸 방지하기 위한 한판 정리가 바로 PRD의 역할입니다.
문제는… “좋은 PRD는 시간이 많이 든다”
그동안 PRD/6pager는
PM의 경험, 글쓰기 실력, 구조화 능력 같은
개인 능력치에 크게 의존했습니다.
그래서:
작성에 시간이 오래 걸리고
공수 대비 효율이 떨어지고
팀 내 문서 수준도 편차가 컸습니다.
하지만 이제는 상황이 달라졌습니다.
GPT로 PRD를 쓰면,
초안은 30분이면 충분합니다.
단, GPT에게 바로 답을 요청하면 절대 안 됩니다.
많은 분들이 GPT에게 이렇게 지시하죠.
“PRD 써줘.”
그러면 결과가 어떻게 나올까요?
예상하셨겠지만 피상적인 문서만 나옵니다.
왜냐하면 GPT는 “문서 작성”에는 뛰어나지만
문제를 정의하고 사고의 체계를 만드는 것은
사용자가 주입해줘야 하기 때문입니다.
PRD는 문서가 아니라 사고의 구조화 과정입니다.
즉, GPT는 “작성자”가 아니라 PM의 사고를 이식받는 보조 브레인이어야 합니다.
이걸 이해하지 못하면 GPT는 절대 실전 PRD를 못 씁니다.
얼마 전 ‘열다’ 팀에 전달한 PRD 초안 — 20분 만에 완성
얼마 전까지 ‘정리 플랫폼 열다’에서
애자일 코치로 업무 프로세스 정립을 도와드렸습니다.
당시 PM이 없는 상황에서
“PRD를 제대로 쓰는 법”에 대한 고민을 듣게 되었고,
제가 기존에 사용해오던 방법을 GPT 기반으로 적용해보았습니다.
마침 랜딩 페이지 개편을 앞두고 계셔서
‘랜딩 페이지 개편안 PRD’를 실전으로 만들어 드렸습니다.
초안 생성까지 걸린 시간은 20분도 채 되지 않았습니다.
하지만 그 “20분”이 가능한 이유는
GPT에게 사고의 단계와 구조를 주입했기 때문입니다.
아래는 제가 실제로 사용한 7단계 사고 구조 주입 과정입니다.
GPT로 PRD를 ‘생각하게’ 만드는 7단계
1) 밑작업: 서비스 이해시키기
먼저 GPT에게 ‘열다’라는 서비스의 본질을 이해시키기 위해
URL을 공유하고 서칭을 통해 확인할 수 있는 정보를 Feed했습니다.
타겟 유저
서비스 요약
주요 페인
제공 가치
Business Model
경쟁 구도
GPT가 문서를 잘 쓰려면
문서의 맥락인 ‘비즈니스’를 먼저 이해해야 합니다.
2) 휴리스틱 기반 랜딩 페이지 문제점 도출
두 번째는 랜딩 페이지 URL을 공유하고
방금 분석한 서비스 맥락과 UX 휴리스틱을 결합해
문제점을 도출하게 했습니다.
“이 서비스의 고객이 이 랜딩을 봤을 때 어디서 막힐까?”
이 질문에 답하도록 만든 단계입니다.
3) 핵심 고객층의 감정·페인 분석
PRD는 고객 관점에서 논의되어야 하기 때문에
핵심 고객층이 실제로 랜딩 페이지를 보며 느낄 감정과 불편을
구체적으로 정리하게 했습니다.
이는 해결책 방향성을 정교하게 만드는 데 필수입니다.
4) 실제 데이터 결합
이제 이론 기반 분석이 끝났다면
실제 고객 데이터와 결합해야 합니다.
열다 팀의 Slack 채널에서
VoC와 리뷰를 추출해 GPT에게 입력했습니다.
GPT는 이 데이터를 기반으로
“마음속의 고객”이 아니라
“실제 고객의 목소리”에 기반한 문제 정의를 하게 됩니다.
5) PRD 구조(Flow) 먼저 제시
가장 중요한 단계입니다.
GPT에게 “작성해봐”라고 하는 게 아니라
PRD의 요소를 먼저 사람이 정의하는 것입니다.
제가 제시한 흐름은 다음과 같습니다.
한 줄 소개
배경
목적/목표
고객/시장
기대효과
문제 정의
해결책
핵심 플로우/시나리오
제품 요구사항
비범위(하지 않을 것)
마일스톤
기술 고려사항
FAQ
GPT에게 문서 작성의 궤도를 먼저 주고
그 궤도 안에서 논리를 채워 넣게 하는 과정입니다.
6) 레퍼런스 문서 제공
제가 이전 회사에서 직접 작성했던 6pager 전문을 학습시키고
그 구조와 톤을 참고하게 했습니다.
GPT는 예시 기반 학습이 매우 강력합니다.
좋은 레퍼런스를 먹이면
결과물도 확실히 좋아집니다.
7) PRD 초안 생성
모든 인풋이 준비된 뒤
최종적으로 PRD 초안 생성을 요청했습니다.
이때 GPT는 더 이상
“기계적 문서 작성”을 하는 것이 아니라
앞서 학습한 모든 단계의 정보를 종합해
사고의 결과물로서 문서를 작성하게 됩니다.
결과는 어땠을까요?
단순히 “PRD 써줘”라고 할 때와는
전혀 다른 수준의 문서가 나왔습니다.
전략적 맥락이 연결되어 있고
고객의 실제 언어를 반영하고
개편 방향성이 명확하며
기능이 아닌 “문제–해결” 중심으로 구성되고
팀 align이 당장 가능한 구조
즉, 단순 문서가 아니라 ‘사고의 흔적’이 남아 있는 PRD가 나왔습니다.
GPT 시대의 PRD 작성 — PM의 역할은 더 중요해졌다
GPT가 PRD를 “대신 작성해주는 시대”처럼 보이지만
실제로는 반대입니다.
PM의 사고 구조를 GPT에게 정확하게 이식할 수 있는 사람이
더 큰 가치를 만들어냅니다.
지금 PM에게 필요한 건
문제 정의 능력
구조화
프롬프팅
chain of thought 설계
데이터와 맥락 결합 능력
즉, 사고 엔지니어링(Thinking Engineering)입니다.
결론
GPT를 잘 쓰면
PRD 작성 시간은 최소 10배 줄어듭니다.
하지만 그 효과는 GPT가 만드는 것이 아니라
PM이 만드는 사고 구조에서 시작됩니다.
단순히 “해줘”가 아니라
정교한 사고와 구조화된 프롬프트만이
GPT를 실전에서 활용 가능한 수준으로 끌어올립니다.
더 깊이 알고 싶다면
링크드인으로 궁금한 점은 언제든 DM 주세요.
감사합니다.
