[수업노트] 기획자는 원래 프롬프트 강자다 — 프롬프트 엔지니어링 첫걸음
좋은 기획서를 쓰는 역량은 그대로 좋은 프롬프트가 된다. 역할·맥락·예시·검증 4가지 기법을 기획자의 언어로 정리.
결론부터: 프롬프트 엔지니어링은 새로운 기술이 아니라, “명확하게 요구사항을 전달하는 기술” 입니다. 기획자·PM이 매일 하던 일이에요.
🤔 왜 기획자가 유리할까
애매한 기획서를 받은 개발자가 엉뚱한 걸 만들어 온 경험, 다들 있죠. AI도 똑같습니다. 애매하게 지시하면 애매하게 답합니다.
| 좋은 기획서의 조건 | = 좋은 프롬프트의 조건 |
|---|---|
| 누가 쓰는지(대상) 명확 | 역할(Role) 부여 |
| 배경·제약 설명 | 맥락(Context) 제공 |
| 참고 예시 첨부 | 예시(Few-shot) |
| 완성 기준 정의 | 출력 형식·검증 기준 |
즉, 기획서를 잘 쓰는 사람은 프롬프트도 잘 씁니다. 도구가 사람에서 AI로 바뀌었을 뿐.
🧩 핵심 기법 4가지 (기획자의 언어로)
1. 역할 부여 (Role)
AI에게 “너는 누구다”를 정해주면 답의 품질이 크게 오릅니다.
❌ “이 문의 분류해줘” ✅ “너는 10년 차 CS 운영 매니저야. 아래 고객 문의를 [환불/버그/기능요청/기타]로 분류해줘.”
2. 맥락 제공 (Context)
왜 이 일을 하는지, 어떤 상황인지 알려줍니다.
“이 요약은 매주 경영진 회의에 쓰여. 그들은 숫자보다 의사결정 포인트를 원해.”
3. 예시 (Few-shot)
말로 설명하기 어려운 건 예시 2~3개가 백 마디를 이깁니다.
“다음처럼 분류해줘. 예) ‘결제가 안 돼요’ → 버그 예) ‘다크모드 있으면 좋겠어요’ → 기능요청”
4. 출력 형식 지정 + 생각할 시간
결과를 어떻게 받을지 못박고, 어려운 판단은 단계적으로 생각(Chain-of-Thought) 하게 합니다.
“먼저 근거를 한 줄 적고, 그 다음 표로 정리해줘. 표 형식: 문의 카테고리 근거”
🆚 나쁜 프롬프트 → 좋은 프롬프트 (실전 예시)
내 운영 리포트 에이전트의 요약 프롬프트로 비교해봤습니다.
1
2
3
4
5
6
7
8
9
❌ Before
"이번 주 지표 요약해줘: 가입 1200, 이탈 300, 전환율 4.1%"
✅ After
"너는 서비스 운영 분석가야. 아래 지표를 경영진용 3줄 요약으로 정리해줘.
- 규칙: 전주 대비 증감과 '주목할 이슈'를 반드시 포함
- 톤: 담백하게, 과장 금지
- 형식: 불릿 3개, 각 줄 앞에 📈/📉/⚠️ 이모지
[데이터] 가입 1200(전주 1000), 이탈 300(전주 280), 전환율 4.1%(전주 4.5%)"
After 쪽이 매번 같은 품질의 결과를 줍니다. 이게 “엔지니어링”이라 불리는 이유 — 재현 가능하게 만드는 것.
✅ 기획자의 무기: 검증(QA) 감각
프롬프트는 한 번에 완성되지 않습니다. 여러 입력으로 돌려보고 → 실패 케이스를 찾아 → 규칙을 보강하는 반복이 핵심. 기획자가 하던 QA·엣지케이스 점검과 똑같아요.
🔗 다음으로
- 이 기법들을 실제로 실험하는 과정은 에이전트 제작기 #3(예정)에서 공개합니다.
- 바로 쓸 수 있는 프롬프트 템플릿은 자료실: 프롬프트 & 체크리스트에 모아뒀어요.