기획서 작성 프롬프트 — AI 기획안이 컨설팅 숙제처럼 읽히는 이유

무엇이 어려운가

기획안을 시키면 자주 이런 문서가 옵니다. 목차에 SWOT·3C·PESTLE이 올라와 있고, 전략 옵션 세 개가 장단점 표와 함께 나열돼 있고, 결론은 '상황에 따라 선택'입니다. 형식은 갖췄는데 읽고 나면 무엇을 하자는 것인지 모릅니다.

원인은 둘입니다. 분석 틀을 목차로 쓰면 틀을 채우는 것이 목적이 되어 결론이 사라집니다 — 틀은 생각하는 도구이지 문서의 뼈대가 아닙니다. 그리고 선택을 요구하지 않으면 AI는 가장 안전한 길인 나열을 택합니다. 의사결정이 통째로 읽는 사람에게 넘어오는 것입니다.

요청에 무엇을 더해야 하는가

1. 틀은 쓰되 소제목에서 지운다

분석 틀을 지정하는 것 자체는 좋은 지시입니다 — 틀 없이 '분석하라'고 하면 목록만 길어집니다. 대신 틀 이름은 소제목으로 올리지 말고, 소제목은 그 대목이 답하는 질문으로 달라고 적습니다. 'VRIO 분석'이 아니라 '우리가 가진 것과 없는 것'입니다.

2. 확정과 근거를 요구한다

옵션을 늘어놓고 끝내지 말고 하나를 확정하되, 왜 그것인지 파급력·리스크·난이도로 근거를 밝히라고 적습니다. 실행 계획의 책임 표에는 최종 승인자를 행마다 정확히 한 명만 두게 합니다 — 승인자가 둘이면 아무도 승인하지 않습니다.

3. 해결안이 이름에서 멈추지 않게 한다

'통합 대시보드 구축' 같은 이름과 한 줄 설명으로 끝난 해결안은 받은 사람이 만들 수 없습니다. 무엇을 만드는가 · 사용자가 무엇을 보고 하는가 · 무엇이 들어가 무엇이 나오는가 · 기존 업무의 어느 단계를 대체하는가 · 무엇이 되면 완성인가 — 다섯을 요구하면 이름이 기획이 됩니다.

7단계 — 각 단계가 답하는 질문

기획마스터 지시문은 문서를 일곱 단계 순서로 쓰게 합니다. 분석 틀은 단계 안에서 쓰이되 소제목으로 올라오지 않고, 표는 1단계와 7단계에만 씁니다.

1. 1과업 분석 — 배경·목적, 투입에서 성과까지의 가치 체계, 핵심 지표, 자원, 리스크. 표를 쓸 수 있는 첫 자리
2. 2프로젝트 브리프 — 문제 정의, 사용자가 실제로 겪는 불편, 근본 원인, 목표와 지표 체계, 범위 안팎, 제약
3. 3환경 분석 — 우리가 가진 것과 없는 것, 밖에서 오는 힘, 둘을 엮은 시사점 서너 개
4. 4전략 옵션과 확정 — 옵션 셋에서 다섯을 낸 뒤 하나를 확정하고 파급력·리스크·난이도로 근거를 밝힙니다. 확정 전략의 과제와 로드맵이 뒤따릅니다
5. 5핵심 성공 요인 — 후보 여덟에서 열둘 가운데 상위 하나에서 셋을 확정하고 근거를 답니다
6. 6해결안 — 요인별 아이디어에서 모순을 먼저 세우고, 그다음에야 발명 원리를 적용해 최종 해결안 하나에서 셋을 확정합니다. 모순 없이 원리만 나열하면 TRIZ가 아닙니다
7. 7실행 계획 — 역할군, RACI 표(행마다 최종 승인자는 정확히 한 명), 비용·기한·리스크 등급, 변화 관리. 표를 쓸 수 있는 둘째 자리

지표는 하나와 둘로 나눕니다

성과 지표를 정성 문구로 끝내지 못하게 합니다. 북극성 지표 하나와 그것을 앞서 움직이는 선행 지표, 뒤따라 확인되는 후행 지표로 나눠 적게 합니다. '고객 만족도 향상'은 지표가 아니고, '월간 재구매율'은 지표입니다.

그리고 문서 전체를 작업 지시 어조로 쓰지 않게 합니다. '~하라'·'~확인한다'는 우리가 AI에게 하는 말이지 기획서의 말이 아닙니다. 확인이 필요한 것은 사실로 적습니다 — '전결 규정은 확인하지 못했다. 확인되면 승인 단계가 바뀐다'처럼.

직접 쓸 때의 체크리스트

1. 1분석 틀을 지정하면서 '소제목으로 쓰지 마라'를 함께 적었는가
2. 2옵션 나열이 아니라 확정과 근거를 요구했는가
3. 3해결안마다 다섯 요소를 요구했는가
4. 4없는 수치·조직명·예산을 지어내지 말고 확인 대상으로 표시하게 했는가
5. 5미정 항목을 문서 앞에 모으지 않게 했는가 — 앞머리가 미정 목록이면 기획서가 아니라 확인 요청서로 읽힙니다