기획서 작성에 하루 쓰던 PM, AI로 10분 안에 초안 받는 법

기획서 작성에 하루 쓰던 PM, AI로 10분 안에 초안 받는 법

2026년 6월, 프로덕트 매니저의 기획서 작성 시간은 AI로 단축되고 있다. PRD 초안, 요구사항 정리, 화면 목업까지 자동화하는 사례가 늘고 있다. 그러나 AI에게 "PRD 작성해줘"라고만 하면 "인터넷 어딘가의 평균적인 PRD"가 나온다. 진짜 시간을 줄이려면, AI에게 우리 회사의 기획 문법을 먼저 알려줘야 한다. maily.so 메이커 노트 18호에서 실제로 PRD 작성에 하루를 쓰던 PM이 이 방식으로 10분 안에 초안을 받는 워크플로우를 정리해 소개했다.

표준 PRD 템플릿이 우리 회사에 안 맞는 이유

표준 PRD 양식은 Problem Statement, Goals, Success Metrics, User Stories, Out of Scope 같은 항목을 깔끔하게 정리해준다. 검색하면 정말 많은 양식이 나온다. 처음 보면 "이대로만 채우면 되겠다"는 생각이 든다. 그런데 막상 실제 회사 문서로 가져오면 잘 맞지 않는다.

회사마다 용어가 다르고, 정책을 정리하는 방식이 다르고, 개발팀이 확인하는 포인트도 다르다. 어떤 조직은 화면 단위의 상세 기획을 중요하게 보고, 어떤 조직은 정책과 예외 케이스를 더 중요하게 본다. 또 내부 어드민처럼 운영과 밀접한 기능이라면 권한, 상태값, 이력, 처리 사유 항목이 훨씬 중요해진다.

내부 어드민 개선 과제를 예로 들어보자. 단순히 "요청 승인 기능을 추가한다"라고 쓰면 요구사항처럼 보일 수 있다. 하지만 실제 리뷰에서는 더 많은 질문이 나온다. 누가 승인할 수 있는지, 반려 사유는 필수인지, 이미 처리된 요청은 다시 처리할 수 있는지, 처리 이력은 누가 어디까지 볼 수 있는지, 상태값은 어떤 조합이 필요한지, 운영자가 실수했을 때 되돌릴 수 있어야 하는지. 이런 질문은 표준 템플릿만으로는 잘 드러나지 않는다. 우리 회사의 시스템 구조, 운영 방식, 리뷰 문화, 의사결정 기준이 들어가야 비로소 실제로 쓸 수 있는 문서가 된다.

표준 템플릿은 뼈대만 알려준다. 우리 회사의 맥락을 채우는 방법은 알려주지 못한다. 좋은 PRD는 표준 양식을 잘 채운 문서가 아니라, 우리 회사에서 실제로 리뷰되고 개발될 수 있는 문서다.

AI에게 우리 회사 기획 문법을 먼저 가르치기

AI에게 "내부 어드민 승인 기능 개선 PRD 작성해줘"라고만 하면 문법적으로는 멀쩡한 문서가 나온다. 하지만 우리 팀이 안 쓰는 표현이 들어가고, 정책은 두루뭉술하고, 예외 케이스는 일반론에 머문다.

이유는 단순하다. AI는 우리 회사가 PRD를 어떻게 쓰는지 모르기 때문이다. 그래서 인터넷 평균 PRD 형식을 기준으로 답을 만들어낸다.

해결책은 역발상이다. 잘 작성된 기획서 1~2개를 AI에게 분석하게 해서, 공통 목차 구조, 요구사항 작성 방식, 정책·예외 케이스 정리 패턴, 권한·이력·운영 항목 다루는 방식을 정리해달라고 한다. 한 번 정리해두면 이후에는 "방금 정리한 우리 회사 기획 문법에 맞춰 PRD 작성해줘"라고 짧게 요청할 수 있다.

Claude Code로 회사의 기획 문법을 영구 기억시키기

매번 기존 문서와 작성 가이드를 다시 붙여넣는 건 번거롭다. Claude Code를 쓰면 이 과정을 체계화할 수 있다.

핵심은 한 번 정리한 기획 문법을 파일로 남겨두고, 이후 작업에서 계속 참고하게 만드는 것이다. CLAUDE.md에 기획 문서 작성 규칙을 저장하고, 실제 템플릿은 prd-template.md, screen-spec-template.md, admin-mockup-guide.md로 분리한다. 규칙이 바뀌면 해당 파일만 수정한다.

반복 작업은 명령어로 묶어둘 수 있다. /make-admin-prd처럼 정의해두면, "내부 어드민 요청 승인 기능 개선 과제로 /make-admin-prd 실행해줘" 한 마디로 PRD 초안, 상세기획, 인터랙션 목업, 리뷰 체크리스트가 한 번에 생성된다.

PRD 예시: 내부 어드민 요청 승인 기능 개선

승인 요청이 슬랙과 메일로 분산 접수되고, 처리 상태는 스프레드시트로 수기 관리되는 상황을 가정해 보자. 처리는 별도 시스템에서 수기로 진행되니 누락이 생기고, 상태 확인이 어렵고, 이력 추적도 안 된다.

AI가 만든 PRD 초안은 이런 형태가 된다. 문제 정의, 목표, As-Is/To-Be, 주요 요구사항 6개, 정책/예외 케이스 4개, 오픈 이슈 3개로 구성된다. 빈 문서에서 시작했다면 오래 걸렸을 구조화 작업을 빠르게 줄여준다.

여기서 중요한 점은 AI가 모든 기획을 끝냈다는 뜻이 아니라는 것이다. AI는 PM이 검토할 수 있는 첫 번째 구조물을 만들어줄 뿐이다. 빈 문서에서는 생각이 흩어지지만, 초안이 있으면 빠진 것과 이상한 부분이 명확해진다.

인터랙션 목업까지 함께 만들기

PRD만으로는 유관부서와 개발팀이 같은 화면을 상상하기 어렵다. "요청 목록을 제공한다"는 문장만 봐도 사람마다 떠올리는 화면이 다르다. 그래서 PRD 초안을 만든 뒤에는 인터랙션 목업까지 만드는 게 좋다.

완성도 높은 디자인 시안이 아니어도 괜찮다. 리뷰 자리에서는 "어떻게 생겼는가"보다 "어떤 흐름으로 동작하는가"가 더 중요할 때가 많다. 요청 목록 테이블, 상세 패널, 승인/반려 모달, 처리 이력 영역을 단일 HTML 파일로 만들어두면 개발 리뷰에서 바로 열어볼 수 있다.

PRD가 논의의 기준점을 만든다면, 목업은 그 논의를 같은 화면 위에 올려놓는 역할을 한다. 운영 담당자가 "이 정보가 목록에 더 보여야 한다"고 피드백하고, 개발자는 상태값과 버튼 액션 흐름을 빠르게 이해한다.

AI가 줄여주는 시간과 PM에게 남는 일

PRD 작성에 하루가 걸리던 작업 중 일부는 10분 안에 초안으로 만들 수 있다. 특히 빈 문서에서 목차를 잡고, 요구사항을 나누고, 예외 케이스를 펼치고, 인터랙션 목업까지 만드는 구간이 그렇다.

하지만 여전히 중요한 일은 PM에게 남아 있다. 무엇이 진짜 문제인지 정의하는 일, 어떤 요구사항을 이번 범위에 포함할지 결정하는 일, 어떤 예외를 정책으로 막고 어떤 예외를 운영으로 대응할지 판단하는 일이다.

AI가 기획서를 대신 써준다고 말하기엔 아직 조심스럽다. 하지만 AI가 빈 문서에서 리뷰 가능한 초안까지 가는 시간을 줄여준다는 건 분명해 보인다. 그 시간을 줄이기 위해 필요한 건 더 멋진 프롬프트가 아니라, 우리 회사가 어떤 방식으로 문제를 정의하고 정책을 판단하는지 AI에게 알려주는 일이다.

AI는 도구다. 맥락을 채우는 건 PM의 몫이다. 회사에서 리뷰 가능한 첫 번째 구조물을 빠르게 받아 검토에 들어가는 것이 핵심이다. 2026년 현재, 이 방식으로 PRD 작성 시간을 하루에서 10분 수준으로 단축한 사례가 이미 나오고 있다.