좋은 기획서는 설명서가 아니라 의사결정 문서다.

A great planning doc is not a brochure — it is a decision document.

서비스·소프트웨어·사업·전략 기획서를 의사결정 문서로 만들기 위한 10가지 원칙. 어떤 AI 에이전트(Claude Code, Codex CLI, Gemini CLI, Cursor 등)에서도 그대로 쓰는 드롭인 시스템 프롬프트입니다.

Ten rules that turn any AI agent (Claude Code, Codex CLI, Gemini CLI, Cursor, etc.) into a senior planner who writes service / software / business / strategy planning documents at decision-grade quality.

GitHub 저장소GitHub repository CLAUDE.md AGENTS.md

왜 필요한가

Why this exists

좋은 기획서는 다음 한 줄이 모든 챕터를 관통합니다.

A great planning document has one single thread running through every chapter:

왜 해야 하는가 → 어떤 문제를 해결하는가 → 누구를 위한 것인가 → 무엇을 만들 것인가 → 어떻게 실행하는가 → 어떻게 검증하는가 Why we should do it → What problem it solves → Who it is for → What to build → How to execute → How to verify.

대부분의 기획서 템플릿이 실패하는 이유는 챕터만 나열할 뿐, 위 한 줄로 묶이지 않기 때문입니다. 승인자는 비용 대비 효과를 찾지 못하고, 개발자는 예외 케이스를 못 찾고, QA는 수용 기준을 못 찾습니다. 이 열 가지 원칙은 모든 챕터가 같은 실 하나로 꿰이도록 강제합니다.

Most templates fail because they only list sections without binding them together. An approver cannot find the cost vs. value. A developer cannot find the exception cases. QA cannot find the acceptance criteria. The Ten Rules block all of those by forcing the same single thread through every section.

설치

Install

에이전트가 읽는 파일을 홈 디렉토리 또는 프로젝트 루트에 넣으면 됩니다.

Drop the file your agent reads into your home directory or project root.

도구	Tool	File
Claude Code	`~/.claude/CLAUDE.md`
OpenAI Codex CLI	`~/.codex/AGENTS.md`
Google Gemini CLI	`~/.gemini/AGENTS.md`
OpenCode	`~/.config/opencode/AGENTS.md`
Cursor / Windsurf	`<repo>/AGENTS.md`

한 줄 설치

One-liner

curl -fsSL https://raw.githubusercontent.com/cskwork/planning-doc-rules/main/AGENTS.md -o ~/.codex/AGENTS.md
curl -fsSL https://raw.githubusercontent.com/cskwork/planning-doc-rules/main/CLAUDE.md -o ~/.claude/CLAUDE.md

여러 CLI에서 단일 출처로

Single source of truth across CLIs

git clone https://github.com/cskwork/planning-doc-rules.git ~/planning-doc-rules

ln -sf ~/planning-doc-rules/CLAUDE.md   ~/.claude/CLAUDE.md
ln -sf ~/planning-doc-rules/AGENTS.md   ~/.codex/AGENTS.md
ln -sf ~/planning-doc-rules/AGENTS.md   ~/.gemini/AGENTS.md
ln -sf ~/planning-doc-rules/AGENTS.md   ~/.config/opencode/AGENTS.md

10가지 원칙

The Ten Rules

Why를 먼저 고정하라

무엇을 만들 것인가가 아니라, 왜 지금 해야 하는가, 해결하지 않으면 무엇이 깨지는가, 어떤 조직·사용자·시장 니즈에 답하는가를 먼저 쓴다.

문제를 As-Is / To-Be 격차로 정의하라

불만이나 아이디어가 아니라 현재 상태, 목표 상태, 그 차이, 핵심 원인, 우선 해결 순서로 쓴다.

독자의 우려를 목차로 바꿔라

작성자가 하고 싶은 말이 아니라 승인자·개발자·디자이너·운영자·투자자가 걱정하는 순서대로 챕터를 배치한다.

리서치로 주장과 의견을 분리하라

데스크 리서치, 경쟁 분석, 사용자 인터뷰, 로그, 리뷰, VOC에서 근거를 가져온다. 검증 안 된 부분은 가정 또는 추가 검증 필요로 명확히 표시한다.

사용자 시나리오에서 요구사항을 도출하라

페르소나, 상황, 목표, 여정이 먼저고, 기능은 그 행동에서 떨어져 나온다.

요구사항을 모호하지 않게 명세하라

ID, 명, 목적, 상세, 사용자, 입력값, 처리 조건, 출력값, 예외, 우선순위, 수용 기준까지 적어 개발·QA·운영이 같은 기준으로 판단하게 한다.

IA → Flow → Wireframe → Spec을 연결하라

모든 화면은 어떤 요구사항을 충족하는지, 모든 요구사항은 어느 화면에 떨어지는지 추적 가능해야 한다.

정책과 예외를 먼저 정의하라

정상 플로우가 아니라 권한, 상태값, 데이터 보관·삭제, 알림, 승인·반려, 오류, 운영자 개입 케이스를 스펙 확정 전에 박는다.

실행 가능성을 숫자와 계획으로 증명하라

범위, 제외 범위, 우선순위, 일정, 인력, 리소스, 의존성, 리스크, 대안, 단계별 실행 계획을 모두 적는다.

검증·론칭·운영까지 닫아라

개발 완료가 끝이 아니다. QA 시나리오, 테스트케이스, 론칭 계획, 운영 매뉴얼, CS 대응, KPI, 사후 고도화 사이클까지 포함한다.

Anchor "Why" first

Open with the reason this work exists, why it must happen now, what breaks if it does not, and which organizational / user / market need it answers. Never start with "what to build."

Define the problem as an As-Is / To-Be gap

Not a complaint, not an idea. Current state, target state, gap, root cause, priority of what to solve first.

Turn the reader's worries into the table of contents

Order sections by the anxieties of approver, developer, designer, operator, investor — not by what the author wants to say.

Separate claim from evidence with research

Pull from desk research, competitor analysis, user interviews, logs, reviews, VOC. Mark anything not yet supported as assumption or needs further validation.

Derive requirements from user scenarios

Persona, situation, goal, journey first. Features fall out of behavior, not the other way around.

Specify requirements without ambiguity

ID, name, purpose, detail, users, inputs, processing conditions, outputs, exceptions, priority, acceptance criteria — so dev / QA / ops judge the same way.

Connect IA → Flow → Wireframe → Spec

Every screen traces back to a requirement; every requirement lands on a screen.

Define policy and exceptions first

Access, state values, data retention, notifications, approval / rejection, error handling, operator-intervention cases — before the spec stabilizes.

Prove feasibility with numbers and a plan

Scope, out-of-scope, priority, schedule, headcount, resources, dependencies, risks, alternatives, phased plan.

Close the loop through QA, launch, and operations

Test scenarios, launch plan, runbook, CS response, KPI, post-launch improvement cycle.

표준 목차

Standard table of contents

이 원칙대로 작성된 기획서가 보통 따르는 순서. 순서 자체가 규칙(원칙 3)입니다 — 각 챕터는 그 시점에 독자가 갖는 특정 우려에 답합니다.

The order is itself a rule (Rule 3) — each section answers a specific worry the reader has at that point.

01한 줄 결론

02Executive Summary

03배경과 문제

04As-Is / To-Be

05목표·성공 지표

06리서치

07핵심 인사이트

08해결 방향·대안

09범위·제외 범위

10사용자 시나리오

11요구사항

12IA / 메뉴 구조

13주요 Flow

14와이어프레임

15정책·예외

16일정·리소스·리스크

17QA·검증

18론칭·운영·KPI

01One-line conclusion

02Executive summary

03Background & problem

04As-Is / To-Be

05Goals & metrics

06Research

07Key insights

08Solution & alternatives

09Scope

10User scenarios

11Requirements

12IA / menu

13Key flows

14Wireframes

15Policy & exceptions

16Schedule & risks

17QA & verification

18Launch & ops & KPI

사용 흐름

How an agent uses this

에이전트가 CLAUDE.md / AGENTS.md를 시스템 프롬프트로 로드한다.
The agent loads CLAUDE.md / AGENTS.md as its system prompt.
사용자는 1번 기획 주제, 2번 현재 상황, 3번 목표 등 입력 항목을 채워서 던진다.
The user fills in the input form (topic / situation / goal / users / desired output level).
에이전트는 정보 부족 영역을 가정 / 추가 확인 필요 / 현재 정보로 작성 가능한 범위로 구분해서 응답한다.
The agent splits gaps into reasonable assumptions, questions to confirm, and the part it can draft now.
20단계 출력 구조에 맞춰 초안을 작성한다. 초안이 가능하면 질문만 하지 않는다.
It drafts against the 20-section output structure. If a draft is possible, it does not stop at questions.
10원칙 자가 진단 체크리스트와 100점 채점을 마지막에 반드시 출력한다.
It must run the 10-rule self-diagnostic checklist and the 100-point score at the end.

참고 문헌

References

국내 기획·서비스·소프트웨어 기획 서적과 공공 SW 가이드에서 반복적으로 등장하는 패턴을 정리한 것입니다.

Distilled from repeated patterns across Korean planning, service-planning, and software-planning literature plus public-sector RFP guidance.

박신영, 『기획의 정석』, 세종서적 — 3WR, 5Why, 현상 분해와 그룹핑, “상대방의 두려움을 없애는 기획서” 관점.decomposition and grouping, "the planning document removes the reader's fear."
조이, 『서비스를 성공시키는 기획자의 비법 노트』, BJ퍼블릭 — 리서치 → 문제 정의 → 요구사항 → 페르소나 → 시나리오 → IA → 메뉴 트리 → 플로우차트 → 와이어프레임 → 프로토타이핑 → 기능 요구사항 명세서 → 화면 ID → 정책서 → QA → 론칭 → 운영 → 성과 측정.full pipeline: research → problem → requirements → persona → scenarios → IA → flow → wireframe → prototype → functional spec → screen ID → policy → QA → launch → ops → measurement.
이경희, 『서비스 기획 용어사전』, 연플 — 실무 공용 언어로서의 요구사항 정의서, 플로우차트, IA, 와이어프레임, 정책, 분기·예외처리, 화면설계서, QA·테스트케이스.shared vocabulary: requirements doc, flowchart, IA, wireframe, policy, branching, exception handling, screen design, QA test cases.
Rational 기술팀, 『똑똑한 소프트웨어 개발을 위한 실용 가이드』, 한국아이시스 — 요구사항 관리, 설계·모델링, 요구사항-개발-테스트 추적성, 협업, 품질 관리.requirements management, requirement-development-test traceability, quality management.
정보통신산업진흥원(NIPA) — 공공 SW 사업 요구사항 상세화 가이드 (RFP 수준 요구사항 명세의 제도적 기준).public SW project requirement-detailing guidance (institutional standard for RFP-grade requirement specification).