[18호] 기획서 작성에 하루 쓰는 PM, AI에게 10분 맡겨봤습니다

안녕하세요. 프로덕트를 만들며 생각이 점점 많아지고 있는 hubert입니다.

요즘은 기획 문서를 쓰는 방식도 조금씩 달라지고 있는 것 같습니다.
예전에는 빈 문서를 열고 문제 정의부터 하나씩 써 내려갔다면, 이제는 AI에게 먼저 초안을 만들어달라고 요청하는 일이 꽤 자연스러워졌습니다. PRD 초안도 만들 수 있고, 요구사항도 정리할 수 있고, 경우에 따라서는 화면 목업이나 간단한 HTML 프로토타입까지 만들어볼 수 있습니다.

그래서 이런 생각이 들 때가 있습니다.
“기획서 작성에 하루를 쓰던 일을, AI에게 10분 정도 맡겨볼 수 있지 않을까?”
그런데 막상 AI에게 “PRD 작성해줘”라고 요청해보면 이야기가 조금 달라집니다.

문서는 꽤 그럴듯하게 나옵니다. 문제 정의도 있고, 목표도 있고, 요구사항도 정리되어 있습니다. 하지만 실제 업무에 쓰려고 보면 어딘가 어색합니다. 우리 회사에서 쓰는 용어와 다르고, 리뷰어가 기대하는 디테일과 다르고, 실제 운영 기준이나 예외 케이스와 맞지 않는 경우도 많습니다.

결국 다시 PM이 거의 새로 쓰다시피 고쳐야 하는 일이 생깁니다.

저는 이 지점이 꽤 중요하다고 생각합니다. AI가 PRD를 못 쓴다는 뜻이 아닙니다. 오히려 초안은 꽤 빠르게 만들어줍니다. 다만 AI가 만드는 첫 번째 문서는 보통 “우리 회사 문서”라기보다 “인터넷 어딘가에 있을 법한 평균적인 PRD”에 가깝습니다.

그래서 이번 글에서는 단순히 AI에게 PRD를 써달라고 요청하는 방법이 아니라, 우리 회사의 기획 문법을 AI에게 알려주고, 실제 리뷰 가능한 PRD와 인터랙션 목업까지 만들어보는 과정을 다뤄보려고 합니다.

1. 표준 PRD 템플릿은 왜 우리 회사에 잘 맞지 않을까

PRD 템플릿을 검색하면 정말 많은 양식이 나옵니다. 

Problem Statement, Goals, Success Metrics, User Stories, Out of Scope 같은 항목이 깔끔하게 정리되어 있습니다. 처음 보면 “이대로만 채우면 되겠다”는 생각이 듭니다. 그런데 막상 실제 회사 문서로 가져오면 생각보다 잘 맞지 않는 경우가 많습니다.

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

표준 PRD 템플릿은 문서의 뼈대는 알려줍니다.
하지만 그 뼈대에 우리 회사의 맥락을 어떻게 채워야 하는지는 알려주지 못합니다.

예를 들어 내부 어드민 개선 과제를 기획한다고 해보겠습니다.
단순히 “요청 승인 기능을 추가한다”라고 쓰면 요구사항처럼 보일 수는 있습니다. 하지만 실제 리뷰에서는 더 많은 질문이 나옵니다.

이런 질문들은 표준 PRD 템플릿만으로는 잘 드러나지 않습니다. 우리 회사의 시스템 구조, 운영 방식, 리뷰 문화, 의사결정 기준이 들어가야 비로소 실제로 쓸 수 있는 문서가 됩니다.

그래서 저는 좋은 PRD의 기준을 이렇게 생각합니다.  좋은 PRD는 표준 양식을 잘 채운 문서가 아니라, 우리 회사에서 실제로 리뷰되고 개발될 수 있는 문서라고 말이죠.

AI를 활용할 때도 마찬가지입니다. AI에게 표준 양식을 채우게 하면 표준적인 문서가 나오고, 우리 회사의 기획 문법을 알려주면 조금 더 우리 회사에 가까운 문서가 나옵니다.

2. AI에게 먼저 우리 회사의 기획서 문법을 알려주기

AI에게 바로 이렇게 요청할 수 있습니다.

내부 어드민 승인 기능 개선 PRD 작성해줘.

그러면 대체로 문법적으로는 멀쩡한 문서가 나옵니다. 
문제 정의도 있고, 목표도 있고, 요구사항도 정리됩니다. 

하지만 읽어보면 어딘가 “남의 회사 문서” 같습니다.
우리 팀이 쓰지 않는 표현이 들어가고, 정책은 두루뭉술하고, 예외 케이스는 일반론에 머무는 경우가 많습니다.

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

그래서 먼저 해야 할 일은 AI에게 우리 회사의 기획서 문법을 알려주는 것입니다.
방법은 어렵지 않습니다.

이미 우리 회사에서 잘 작성됐다고 평가받은 PRD나 기능 기획서를 1~2개 준비합니다. 그리고 AI에게 그 문서를 따라 쓰게 하는 것이 아니라, 문서의 구조와 작성 방식을 분석하게 합니다.

아래는 우리 회사에서 리뷰가 잘 되었던 PRD 예시입니다.
이 문서들을 분석해서 우리 회사의 기획서 작성 방식을 정리해주세요.

다음 항목을 중심으로 봐주세요.

1. 공통 목차 구조
2. 요구사항을 적는 방식
3. 정책과 예외 케이스를 정리하는 방식
4. 권한, 이력, 운영 항목을 다루는 패턴
5. 자주 쓰는 용어와 표현

분석 결과는 다음에 새 PRD를 작성할 때 참고할 수 있는 작성 가이드 형태로 정리해주세요.

---
[여기에 잘 작성된 PRD 또는 기획서 URL 또는 원문을 붙여넣기]

이렇게 한 번 정리해두면, 이후에는 “방금 정리한 우리 회사 기획 문법에 맞춰서 PRD를 작성해줘”라고 요청할 수 있습니다. 

여기서 중요한 것은 AI에게 예쁜 문서를 쓰게 하는 것이 아닙니다.
우리 회사 사람들이 읽었을 때 익숙하고, 리뷰하기 쉬운 문서를 만들도록 맥락을 주는 것입니다.

물론 실제 사내 문서를 외부 AI 도구에 그대로 넣는 것은 주의가 필요합니다. 고객 개인정보, 내부 시스템명, 보안 정보 등은 제거하고, 구조와 표현 방식 중심으로 정리해 활용하는 편이 안전합니다.

3. 한 번 알려준 문법을 Claude Code가 계속 기억하게 만들기

그런데 매번 PRD를 쓸 때마다 기존 문서와 작성 가이드를 다시 붙여넣는 것은 번거롭습니다. 처음 몇 번은 괜찮지만, 실제 업무에서 계속 쓰려면 결국 재사용 가능한 구조로 만들어두는 편이 좋습니다.

Claude Code를 사용한다면 이 과정을 조금 더 체계화할 수 있습니다. 핵심은 한 번 정리한 회사의 기획 문법을 파일과 설정으로 남겨두고, 이후 작업에서 계속 참고하게 만드는 것입니다.

예를 들어 CLAUDE.md 파일에 기획 문서 작성 규칙을 남겨둘 수 있습니다.

# 기획 문서 작성 규칙

## PRD 작성 요청 시
- 사용자가 "PRD 작성해줘", "기획서 만들어줘"라고 요청하면
  `~/.claude/templates/prd-template.md` 구조를 따른다.
- 제목은 `(YYYY-MM-DD) 과제명` 형식으로 작성한다.
- 문서 상단에는 PM, 개발 담당, 리뷰어, 관련 티켓, 배포 목표일을 포함한다.
- 본문은 아래 순서로 작성한다.
  1. 문제 정의
  2. 목표
  3. As-Is / To-Be
  4. 사용자 및 이해관계자
  5. 주요 요구사항
  6. 정책 / 예외 케이스
  7. 권한 / 이력 / 운영 정책
  8. 오픈 이슈
  9. 출시 후 확인 지표

## 상세기획 작성 요청 시
- 사용자가 "상세기획 작성해줘", "화면 기획서 만들어줘"라고 요청하면
  `~/.claude/templates/screen-spec-template.md` 구조를 따른다.
- 화면별로 목적, 진입 조건, 주요 컴포넌트, 버튼 액션, 상태값, 예외 케이스를 정리한다.
- 인터랙션이 필요한 경우 HTML 목업 생성을 제안한다.

이렇게 해두면 다음부터는 “우리 회사 양식에 맞춰 PRD 작성해줘”라고 매번 길게 설명하지 않아도 됩니다. Claude Code가 기본 규칙을 먼저 읽고, 정해진 구조에 맞춰 문서를 작성하기 시작합니다.

다만 CLAUDE.md에 모든 양식을 길게 넣어두면 관리가 어려워집니다. 그래서 실제 템플릿은 별도 파일로 분리해두는 편이 좋습니다.

~/.claude/
├── CLAUDE.md
└── templates/
    ├── prd-template.md
    ├── screen-spec-template.md
    └── admin-mockup-guide.md

각 파일의 역할은 이렇게 나눌 수 있습니다.

prd-template.md
- PRD 기본 목차
- 상단 메타 정보
- 문제 정의 / 목표 / 요구사항 / 정책 / 오픈 이슈 작성 방식

screen-spec-template.md
- 상세기획 화면 작성 방식
- 화면별 컴포넌트 정의
- 버튼 액션, 상태값, 예외 케이스 작성 방식

admin-mockup-guide.md
- 내부 어드민 목업 생성 규칙
- 테이블, 상세 영역, 모달, 상태 배지, 이력 로그 UI 패턴

이렇게 분리해두면 양식이 바뀌었을 때 템플릿 파일만 수정하면 됩니다.
PRD 양식이 바뀌면 prd-template.md만 고치고, 상세기획 포맷이 바뀌면 screen-spec-template.md만 고치면 됩니다.

문서 작업을 하다 보면 템플릿에는 적혀 있지 않지만 매번 반복되는 선호도 생깁니다.

- 오픈 이슈는 반드시 의사결정 필요 항목과 확인 필요 항목으로 나눈다.
- 정책 문장은 "가능하다/불가하다"보다 "제공한다/제공하지 않는다"로 쓴다.
- 화면 요구사항은 "사용자는 ~할 수 있다" 형태로 작성한다.
- 내부 어드민 문서에서는 권한, 상태값, 이력 관리 항목을 반드시 포함한다.
- 개발 리뷰 전에 HTML 목업 파일을 함께 생성한다.

처음부터 완벽한 규칙집을 만들 필요는 없습니다. AI가 만든 초안을 보고 “이건 우리 회사 방식이 아닌데?” 싶은 부분이 보이면, 그때마다 CLAUDE.md나 템플릿 파일에 한 줄씩 추가해나가면 됩니다.

반복 작업은 명령어처럼 묶어둘 수도 있습니다.
예를 들어 내부 어드민 개선 과제에서는 보통 이런 순서로 작업이 이어집니다.

1. PRD 초안 작성
2. 상세기획 화면 정리
3. 인터랙션 목업 HTML 생성
4. 개발 리뷰용 체크리스트 작성
5. 오픈 이슈 정리

이런 흐름을 하나의 작업 단위로 정의해두면, 매번 같은 요청을 반복하지 않아도 됩니다.

# /make-admin-prd

다음 입력을 바탕으로 내부 어드민 개선 과제 산출물을 생성한다.

입력:
- 과제명
- 현재 문제
- 개선 방향
- 사용자 권한
- 주요 상태값
- 필수 정책
- 예외 케이스

생성할 산출물:
1. PRD 초안: `draft/prd.md`
2. 상세기획 초안: `draft/screen-spec.md`
3. 인터랙션 목업: `mockup/admin-mockup.html`
4. 리뷰 체크리스트: `draft/review-checklist.md`

작성 기준:
- `~/.claude/templates/prd-template.md`
- `~/.claude/templates/screen-spec-template.md`
- `~/.claude/templates/admin-mockup-guide.md`

이렇게 해두면 다음부터는 “내부 어드민 요청 승인 기능 개선 과제로 /make-admin-prd 실행해줘”처럼 요청할 수 있습니다. 그 결과 PRD만 나오는 것이 아니라, 상세기획 초안과 목업 파일, 리뷰 체크리스트까지 한 번에 생성할 수 있습니다.

결국 중요한 것은 Claude Code가 알아서 똑똑하게 해주기를 기다리는 것이 아닙니다. AI가 참고할 수 있는 회사의 문서 규칙, 템플릿, 반복 작업 흐름을 미리 정리해두는 것입니다.

이렇게 한 번 구조를 만들어두면, 다음부터는 요청이 훨씬 짧아집니다.

내부 어드민 요청 승인 기능 개선 PRD를
우리 회사 템플릿에 맞춰 작성하고,
리뷰용 인터랙션 목업까지 만들어줘.

이 한 문장만으로도 AI는 표준 PRD가 아니라, 우리 회사 문서 구조와 톤에 가까운 초안을 만들기 시작합니다.

4. 내부 어드민 개선 PRD를 함께 만들어보기

이제 실제 사례를 하나 잡아보겠습니다. 많은 회사에 하나쯤 있을 법한 “내부 어드민 요청 승인 기능 개선” 과제입니다.

현재 상황은 이렇다고 가정해보겠습니다.

개선 방향은 비교적 명확합니다.
어드민에서 요청 목록을 확인하고, 승인 또는 반려 처리를 할 수 있어야 합니다. 처리 시에는 사유를 입력하고, 상태 변경 이력도 남아야 합니다. 운영 담당자, 검토 담당자, 관리자처럼 권한별로 접근 범위와 처리 가능 액션도 달라야 합니다.

이제 이 내용을 AI에게 전달합니다.

앞에서 정리한 우리 회사 기획 문법에 맞춰 PRD 초안을 작성해주세요.

주제는 “내부 어드민 요청 승인 기능 개선”입니다.

현재 승인 요청은 슬랙/메일로 들어오고,
담당자가 스프레드시트로 상태를 관리하며,
실제 처리는 별도 시스템에서 수기로 진행합니다.

문제는 처리 누락, 상태 확인 어려움, 이력 추적 어려움입니다.

개선 후에는 어드민에서 요청 목록 확인, 승인/반려 처리,
처리 사유 입력, 상태 변경 이력 조회가 가능해야 합니다.

운영 담당자, 검토 담당자, 관리자 권한별로
접근 가능 범위와 처리 가능 액션도 구분해주세요.

문제 정의, 목표, As-Is/To-Be, 사용자, 주요 요구사항,
정책/예외 케이스, 권한 정책, 이력 관리, 오픈 이슈를 포함해주세요.

AI가 만든 PRD 초안은 대략 이런 형태로 정리할 수 있습니다.

[PRD] 내부 어드민 요청 승인 기능 개선

1. 문제 정의
승인 요청이 슬랙과 메일로 분산 접수되고,
처리 상태는 스프레드시트로 수기 관리되고 있다.
이로 인해 처리 누락, 상태 확인 지연, 이력 추적 어려움이 반복되고 있다.

2. 목표
요청 접수부터 승인/반려 처리, 이력 확인까지
하나의 어드민 화면에서 관리한다.
모든 처리에는 담당자, 처리 사유, 처리 시각을 기록해 추적 가능성을 확보한다.

3. As-Is / To-Be

- 접수: 슬랙/메일 분산 → 어드민 요청 목록에서 확인
- 처리: 별도 시스템 수기 처리 → 어드민에서 승인/반려 처리
- 사유: 비공식 기록 → 처리 사유 입력 필수
- 이력: 추적 어려움 → 상태 변경 이력 조회
- 권한: 명확한 구분 없음 → 권한별 액션 제어

4. 주요 요구사항

1) 요청 목록을 상태, 요청자, 요청 유형 기준으로 조회할 수 있다.
2) 요청 상세 화면에서 요청 내용과 현재 상태를 확인할 수 있다.
3) 승인 또는 반려 처리 시 사유 입력을 필수로 한다.
4) 처리 완료 후 상태값은 대기에서 승인 또는 반려로 변경된다.
5) 모든 처리 이력은 담당자, 액션, 사유, 처리 시각과 함께 저장된다.
6) 권한에 따라 조회와 처리 가능 액션을 다르게 제공한다.

5. 정책 / 예외 케이스

- 사유를 입력하지 않으면 승인/반려 처리를 할 수 없다.
- 이미 승인 또는 반려된 요청은 재처리할 수 없다.
- 처리 권한이 없는 사용자는 버튼을 볼 수 없거나 비활성화된 상태로 본다.
- 대기 상태가 아닌 요청에는 승인/반려 버튼을 노출하지 않는다.

6. 오픈 이슈

- 반려 후 재요청 플로우를 이번 범위에 포함할지 검토가 필요하다.
- 슬랙/메일 접수 건을 자동 연동할지, 초기에는 수동 등록으로 시작할지 결정이 필요하다.
- 이력 보관 기간과 감사 로그 요건은 보안/운영 부서 확인이 필요하다.

여기까지 오면 AI가 모든 기획을 끝냈다는 뜻은 아닙니다.
하지만 빈 문서에서 시작했다면 오래 걸렸을 구조화 작업을 빠르게 줄여줍니다.

PM은 여기서부터 실제 회사 정책, 개발 범위, 이해관계자 피드백을 반영해 문서를 다듬으면 됩니다.
저는 이 구간이 꽤 의미 있다고 봅니다.
AI가 완성본을 만들어주는 것이 아니라, PM이 검토할 수 있는 첫 번째 구조물을 만들어주는 것이기 때문입니다. 빈 문서에서는 생각이 흩어지지만, 초안이 있으면 빠진 것과 이상한 것이 훨씬 잘 보입니다.

5. PRD에서 끝내지 않고, 인터랙션 목업까지 만들어보기

PRD만으로는 유관부서와 개발팀이 같은 화면을 상상하기 어렵습니다.

“요청 목록을 제공한다”는 문장만 봐도 사람마다 떠올리는 화면이 다릅니다. 어떤 사람은 테이블을 생각하고, 어떤 사람은 카드형 목록을 생각합니다. 상세 화면, 승인 버튼, 반려 모달, 처리 이력 영역도 마찬가지입니다.

그래서 PRD 초안을 만든 뒤에는 간단한 인터랙션 목업까지 만들어보는 것이 좋습니다.

완성도 높은 디자인 시안이 아니어도 괜찮습니다. 리뷰 자리에서는 “어떻게 생겼는가”보다 “어떤 흐름으로 동작하는가”가 더 중요할 때가 많기 때문입니다.

위 PRD를 바탕으로 단일 HTML 파일로 동작하는 인터랙션 목업을 만들어주세요.

파일명은 `mockup/admin-approval-mockup.html`로 저장해주세요.

조건은 다음과 같습니다.

- 외부 라이브러리 없이 HTML/CSS/JavaScript만 사용
- 요청 목록 테이블 제공
- 목록 클릭 시 상세 정보 표시
- 승인 버튼 클릭 시 승인 사유 입력 모달 노출
- 반려 버튼 클릭 시 반려 사유 입력 모달 노출
- 승인/반려 완료 시 상태값 변경
- 처리 이력 영역에 로그 추가
- 운영 담당자, 검토 담당자, 관리자 권한별 버튼 활성/비활성 처리

파일 구조는 단순하게 가져갈 수 있습니다.

project/
├── draft/
│   ├── prd.md
│   ├── screen-spec.md
│   └── review-checklist.md
└── mockup/
    └── admin-approval-mockup.html

이렇게 만들어두면 draft/prd.md는 문서 초안으로, mockup/admin-approval-mockup.html은 유관부서와 개발 리뷰에서 바로 열어볼 수 있는 시연용 파일로 활용할 수 있습니다.

1) 요청 목록 - 한 화면에서 대기 건수와 상태를 한눈에

2) 요청 상세 선택 - 행을 클릭하면 우측에 상세내용과 승인/반려 버튼 노출

3) 승인 사유 입력 모달

4) 처리 이력 관리 - 처리 즉시 상태 변경, 담당자/사유/처리시각 기록

목업은 완성된 디자인 산출물이 아닙니다. 하지만 리뷰용으로는 충분히 유용합니다.

특히 운영 담당자가 별도로 있는 경우 “이 화면에서 실제로 처리할 수 있겠다” 또는 “이 정보가 목록에 더 보여야 한다”고 피드백 할 수 있습니다. 개발자는 상태값, 버튼 액션, 모달, 이력 저장 흐름을 더 빠르게 이해할 수 있습니다. PM 입장에서도 텍스트로 설명할 때보다 훨씬 구체적인 피드백을 받을 수 있습니다.

PRD가 논의의 기준점을 만든다면, 목업은 그 논의를 같은 화면 위에 올려놓는 역할을 합니다.

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

이번 화에서 다룬 내용은 거창한 AI 자동화가 아닙니다.

AI에게 “기획서 작성해줘”라고 맡기고 끝낸 것도 아닙니다. 오히려 그 반대에 가깝습니다. 우리 회사의 기획 문법, 기존 PRD의 구조, 실제 업무 맥락, 내부 어드민 개선 사례를 최대한 구체적으로 알려주고, AI가 그 기준 안에서 초안을 만들도록 한 것입니다.

그 결과 PRD 작성에 하루가 걸리던 작업 중 일부는 10분 안에 초안으로 만들 수 있었습니다. 특히 빈 문서에서 목차를 잡고, 요구사항을 나누고, 예외 케이스를 펼치고, 간단한 인터랙션 목업까지 만드는 구간은 AI의 도움을 크게 받을 수 있었습니다.

하지만 여전히 중요한 일은 PM에게 남아 있습니다.

무엇이 진짜 문제인지 정의하는 일.
어떤 요구사항을 이번 범위에 포함할지 결정하는 일.
어떤 예외를 정책으로 막고, 어떤 예외를 운영으로 대응할지 판단하는 일.
유관부서와 개발팀이 실제로 리뷰할 수 있는 수준으로 문서를 다듬는 일.

AI가 기획서를 대신 써준다고 말하기에는 아직 조심스럽습니다.
하지만 AI가 빈 문서에서 리뷰 가능한 초안까지 가는 시간을 줄여준다는 것은 분명해 보입니다.

그리고 그 시간을 줄이기 위해 필요한 것은 더 멋진 프롬프트 하나가 아닐지도 모릅니다. 오히려 우리 회사가 어떤 방식으로 문제를 정의하고, 요구사항을 나누고, 정책을 판단하고, 화면을 리뷰하는지 AI에게 알려주는 일이 더 중요합니다.

AI에게 좋은 PRD를 쓰게 하려면, 먼저 PM이 좋은 맥락을 제공해야 합니다.

결국 중요한 것은 AI가 문서를 대신 써주는지가 아니라, PM이 가진 문제의식과 회사의 기획 문법을 얼마나 잘 전달하느냐일지도 모릅니다. 제품은 문서가 완성되는 순간 만들어지는 것이 아니라, 같은 맥락을 공유한 사람들이 같은 화면을 보며 논의하기 시작할 때 조금씩 구체화되는 것 같습니다.

📮 다음 호 예고

[객원노트] 도움이 필요한 상태라면 당근을 흔들어 주세요

다음 호에는 특별히 판교에서 오랜 시간 PM으로 일해온 객원작가님의 이야기를 담아보려 합니다. AI가 빠르게 정답을 만들어내는 시대 속에서, 우리는 어떤 가치를 증명하며 일해야 할까요? 또 누군가는 큰 성과와 자산을 만들어가는 동안, 왜 우리는 점점 ‘벼락거지’가 된 것 같은 기분을 느끼게 되는 걸까요?

이번 객원노트에서는 AI와 함께 일하며 느끼는 불안, 노동의 가치, 관계와 맥락의 의미에 대해 한 명의 IT 노동자의 시선으로 조용히 풀어냅니다. 완벽한 정답보다는 흔들리는 마음과 현실적인 고민에 가까운 이야기들. 어쩌면 지금 우리 모두가 책상 서랍 속에 하나쯤 넣어두고 살아가는 질문들일지도 모르겠습니다.

✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요. 🙂