“AI가 잘 안 해줘요”
AI 도구를 쓰기 시작한 동료들이 가장 많이 하는 말입니다.
“AI한테 시켰는데 쓸만한 게 안 나와요.” “ChatGPT에 물어봤는데 뻔한 얘기만 해요.” “프롬프트 엔지니어링? 그거 개발자가 하는 거 아니에요?”
같은 AI를 쓰고 있는데, 누군가는 바로 쓸 수 있는 결과물을 뽑고, 누군가는 “역시 AI는 아직…”이라고 결론을 내립니다. 이 차이가 어디서 오는지 궁금했습니다.
3개월간 업무에 AI를 쓰면서 알게 된 결론부터 말하면 — AI를 잘 쓰는 건 “기술”이 아니라 “요구사항 정의”의 문제였습니다.
프롬프트는 기획서다
저는 PM입니다. AI에게 일을 시키기 시작하면서 깨달은 게 있습니다.
AI에게 주는 프롬프트는 결국 요구사항 정의입니다. 기획서에서 매일 하는 일과 똑같습니다.
- 누구를 위한 건지 (대상)
- 뭘 해야 하는지 (목표)
- 어떤 기준으로 판단하는지 (조건)
- 어떤 형태로 나와야 하는지 (산출물)
개발팀에 “그냥 좋게 만들어주세요”라고 하면 원하는 결과가 안 나오듯이, AI에게 “그냥 분석해줘”라고 하면 뻔한 결과가 나옵니다. 기획서를 잘 쓰는 사람이 프롬프트도 잘 씁니다.
실제 DO / DON’T 비교
DON’T — 추상적으로 시키기
“이 데이터 분석해줘.”
이렇게 시키면 AI는 평균, 중앙값, 분포 같은 기본 통계를 뽑아줍니다. 틀린 건 아닌데, 내가 원했던 건 이게 아닙니다.
“이 회의 내용 정리해줘.”
긴 요약이 나옵니다. 근데 내가 필요한 건 액션아이템이지 요약이 아닙니다.
“대시보드 만들어줘.”
뭔가 만들어지긴 합니다. 근데 원하는 게 아닙니다.
공통점: “뭘 원하는지”를 말하지 않고 “뭘 해줘”만 말하고 있습니다.
DO — 맥락 + 기준 + 형태를 함께 주기
같은 요청을 이렇게 바꿔보겠습니다.
데이터 분석:
“우리 서비스의 M1 리텐션이 30%대에서 정체 중이야. 40% 달성을 위한 선행지표를 찾고 싶어. 가입 후 7일 이내 행동 기준으로, 행동별 리텐션 상관관계를 테이블로 정리해줘. 상관관계 높은 순서로 정렬하고, 선행지표 후보 3개 추천해줘.”
회의 정리:
“이 녹음을 바탕으로 3문장 요약, 주요 키워드 5개, 액션아이템(담당자·기한 포함)을 표 형태로 정리해줘.”
도구 개발:
“크리에이터별 목표 달성률을 보여주는 대시보드를 만들어줘. 데이터는 Google Sheets에서 가져오고, 월별 필터가 있고, 달성률은 프로그레스 바로 표시해줘.”
같은 요청인데 결과물의 질이 완전히 다릅니다.
프롬프트 설계 원칙 3가지
수십 번의 시행착오를 거치면서 정리한 원칙입니다.
1. 맥락을 먼저 준다
AI는 우리 회사의 상황, 이번 프로젝트의 목표, 지금까지의 의사결정 히스토리를 모릅니다. 매번 “우리 지금 이런 상황이고, 이걸 하려는 거야”를 먼저 설명해야 합니다.
| Before | After |
|---|---|
| ”리텐션 분석해줘" | "우리 서비스는 커뮤니티 플랫폼이고, M1 리텐션이 30%대에서 정체 중이야. 40% 달성을 위한 선행지표를 찾고 싶어." |
| "발표자료 만들어줘" | "크리에이터 23명 대상 스터디 세션이야. 목표는 동기부여. S급 게시글이 왜 중요한지 데이터로 보여주고, 어떻게 만드는지 프레임워크를 알려주는 구조야.” |
첫 문장에 맥락을 주는 것만으로도 결과가 확 달라집니다.
2. 구체적 숫자와 기준을 명시한다
“좋은 결과”가 뭔지 AI는 모릅니다. “조회수 1만 이상”, “전환율 3% 기준”, “상위 20%“처럼 판단 기준을 숫자로 줘야 합니다.
| Before | After |
|---|---|
| ”성과 좋은 게시글 분석해줘" | "조회수 상위 10%, 댓글 5개 이상인 게시글을 S급으로 정의하고, S급 게시글의 공통 특성을 분석해줘" |
| "간단하게 요약해줘" | "300자 이내로, 핵심 결론 1개와 근거 3개로 요약해줘” |
기획서에서 AC(Acceptance Criteria)를 쓰듯이, 프롬프트에도 “성공 기준”을 넣는 겁니다.
3. 산출물 형태를 지정한다
“분석해줘”라고 하면 장문의 텍스트가 나옵니다. “테이블로 정리해줘”, “3줄로 요약해줘”, “Before/After로 비교해줘”처럼 형태를 정해주면 바로 쓸 수 있는 결과가 나옵니다.
이건 기획할 때 와이어프레임을 그리는 것과 같습니다. 최종 산출물의 모양을 먼저 정해두면, 과정이 효율적이 됩니다.
실전 사례: AI 요약 프롬프트 개발
원칙을 실제 업무에 적용한 사례입니다.
서비스 내 전문가 칼럼을 AI로 요약하는 기능을 기획할 때, 프롬프트를 직접 설계했습니다.
1차: “이 글을 요약해줘” → 핵심이 빠지고, 어느 글이든 비슷한 뻔한 요약이 나왔습니다.
2차: 카테고리별 톤 가이드를 추가하고, 글자 수를 제한하고, “독자가 다음 단락을 읽고 싶어지게” 목표를 명시 → 요약의 질이 눈에 띄게 달라졌습니다.
3차~4차: 실제 데이터로 테스트하면서 미세 조정 → 최종 프롬프트를 개발팀에 전달해서 서비스에 적용.
코드를 한 줄도 건드리지 않고, 프롬프트만 수정해서 체류시간과 전환율 개선에 기여했습니다. 사용자 맥락을 아는 기획자가 프롬프트를 설계했기 때문에 가능한 결과였습니다.
솔직한 한계
전문 판단은 여전히 사람의 몫
AI가 뽑아준 분석 결과가 “맞는지”는 사람이 판단해야 합니다. 숫자는 정확해도 해석이 틀릴 수 있습니다. 특히 중요한 의사결정에 쓰는 데이터는 반드시 검증 과정을 거칩니다.
처음엔 오히려 느리다
“프롬프트 쓰는 시간에 그냥 내가 하는 게 빠른데?” — 맞는 말입니다. 처음에는요. 하지만 같은 유형의 업무를 3~4번 반복하면, 프롬프트가 자산이 됩니다. 한 번 잘 만든 프롬프트는 계속 재사용할 수 있습니다.
모든 것에 AI를 쓸 필요는 없다
5분이면 끝나는 일에 프롬프트를 정성들여 쓰는 건 비효율적입니다. “이건 AI로 할까, 직접 할까?”를 판단하는 것 자체가 하나의 스킬입니다.
가져가실 것
- 프롬프트 = 요구사항 정의서. PM이 매일 하는 일과 본질적으로 같습니다.
- 맥락 → 기준 → 형태. 이 세 가지만 챙기면 결과물의 질이 확 달라집니다.
- 한 번에 완벽을 기대하지 않기. 프롬프트도 기획서처럼 버전업하는 겁니다.
- 프롬프트 자산화하기. 잘 만든 프롬프트는 저장해두면 복리 효과가 납니다.
그리고 하나 더 — “프롬프트 엔지니어링”이라는 말에 겁먹지 마세요. 기획을 잘 하는 사람이 AI도 잘 쓰는 사람입니다. 이미 하고 있는 일의 연장선입니다.