AI에게 묻고도 늘 엇나가는 이유
AI 프롬포트 스킬 1회
1. 질문이 아니라 ‘요구사항’을 쓰지 않기 때문이다
요즘 사람들은 AI에게 하루에도 수십 번씩 묻는다.
보고서 요약, 기획안 정리, 광고 문구, 블로그 글, 회의 정리, 코딩, 번역, 아이디어 발상까지.
그런데 이상한 경험을 반복한다.
“분명히 말한 것 같은데, 왜 이렇게 엉뚱하게 나왔지?”
“내가 원하는 건 이게 아닌데…”
“다시 말해볼게요.”
“아니, 그러니까 그게 아니라…”
이 장면은 낯설지 않다.
회사에서 신입에게 일을 시킬 때와 거의 똑같다.
“자료 좀 정리해줘.”
→ 신입은 정리했지만, 내가 원한 정리는 아니다.
“아니, 그 정리가 아니라…”
→ 다시 설명한다.
“아, 그럼 이렇게요?”
→ 또 어긋난다.
문제는 능력이 아니다.
지능도 아니다.
요구사항 구조가 없기 때문이다.
AI 프롬프트가 실패하는 본질적 이유도 같다.
우리는 ‘질문’을 던지지만,
AI는 ‘업무 명세서’를 필요로 한다.
2. 실패하는 프롬프트의 전형적인 모습
① 역할이 없다
“이거 정리해줘.”
누가 정리하는가?
기자처럼? 컨설턴트처럼? 신입사원처럼? 교수처럼?
② 목적이 없다
“이걸 요약해줘.”
왜 요약하는가?
발표용인가, 보고용인가, 의사결정용인가?
③ 맥락이 없다
대상 독자는 누구인가?
전문가인가, 초보자인가, 임원인가, 학생인가?
④ 제약이 없다
길이는? 톤은? 형식은?
한 줄인가, 표인가, 보고서 형식인가?
⑤ 기준이 없다
“잘 쓴 요약”이 무엇인가?
예시가 없으니 AI는 추측할 수밖에 없다.
이 다섯 가지가 빠지면 AI는 틀리지 않는다.
다만, 엇나간다.
2. 질문이 아니라 ‘일 시키는 구조’로 바꿔야 한다
사람에게 일을 시킬 때를 떠올려 보자.
일 잘 시키는 상사는 이렇게 말한다.
누구에게
무슨 일을
왜 하는지
어떤 조건으로
어느 수준으로
이 다섯 가지를 모두 말한다.
AI도 같다.
그래서 등장한 구조가 바로 RICCE다.
Role (역할)
Instruction (작업)
Context (맥락)
Constraints (제약)
Examples (기준 예시)
이건 프롬프트 기법이 아니라,
요구사항 설계 구조다.
3. 같은 요청, 전혀 다른 결과
예시 1: “블로그 글 써줘”
❌ 일반 프롬프트
“AI에 대한 블로그 글 써줘.”
결과:
너무 일반적, 방향 불명, 읽고 나면 남는 게 없다.
RICCE 구조로 바꾸면
Role
너는 IT 트렌드를 쉽게 설명하는 콘텐츠 기획자다.
Instruction
AI를 처음 접하는 직장인을 위한 블로그 글을 작성해라.
Context
독자는 기술 비전공자이며, 업무에 AI를 어떻게 써야 할지 막막해한다.
Constraints
2000자 내외
사례 중심
전문용어 최소화
문단마다 소제목 포함
Examples
예시 톤:
“회사에서 엑셀을 처음 배울 때처럼, AI도 처음엔 사용법보다 ‘일 시키는 법’을 알아야 한다.”
결과는 완전히 달라진다.
이제 AI는 ‘글쓰기’가 아니라
콘텐츠 기획 업무를 수행한다.
4. 실전 사례 4가지
사례 1: 보고서 요약
❌
“이 PDF 요약해줘.”
✔ RICCE
Role: 전략 컨설턴트
Instruction: 임원 보고용 요약 작성
Context: 10분 안에 핵심만 파악해야 함
Constraints: 5개 불릿, 각 2줄 이내
Examples: “결론 → 근거 → 리스크 → 제안” 구조
사례 2: 기획안 정리
❌
“이 기획안 정리해줘.”
✔
Role: 서비스 기획 리드
Instruction: 논리 구조 재정렬
Context: 신규 기능 투자 검토 회의용
Constraints: 문제-해결-기대효과-리스크 구조
Examples: 이전 승인된 기획서 구조 제시
사례 3: 광고 문구
❌
“광고 카피 만들어줘.”
✔
Role: 퍼포먼스 마케터
Instruction: A/B 테스트용 헤드라인 10개 생성
Context: 20대 여성, 다이어트 앱
Constraints: 20자 이내, 행동 유도형
Examples: 기존 고성과 카피 3개 제시
사례 4: 회의 정리
❌
“회의록 정리해줘.”
✔
Role: 프로젝트 매니저
Instruction: 결정사항, 할일, 이슈 분리
Context: 다음 주 실행계획 수립 목적
Constraints: 표 형식
Examples: 이전 회의록 포맷 제공
5. 프롬프트는 문장이 아니라 구조물이다
대부분의 사람은 프롬프트를 ‘문장’으로 쓴다.
하지만 실제로는 업무 명세서에 가깝다.
잘 되는 프롬프트는 다음과 같은 구조를 가진다.
정체성(누구처럼 생각할 것인가)
임무(무엇을 할 것인가)
배경(왜, 누구를 위해)
규칙(어떤 형식과 한계)
기준(어디까지가 잘한 것인가)
이 다섯 가지가 갖춰지면,
AI는 더 이상 “대답기계”가 아니라
업무 수행자가 된다.
6. 바로 써먹는 RICCE 템플릿
아래를 그대로 복사해 써도 된다.
너는 [Role]이다.
지금 해야 할 일은 [Instruction]이다.
이 작업의 배경은 다음과 같다:
[Context]
다음 조건을 반드시 지켜라:
[Constraints]
아래 예시 수준을 기준으로 삼아라:
[Examples]
이 구조로 쓰기 시작하면,
프롬프트의 실패율은 급격히 줄어든다.
7. 결론: AI를 쓰는 게 아니라, 일을 시키는 법을 배우는 것이다
AI 시대에 중요한 건
질문을 잘하는 능력이 아니라,
요구사항을 구조화하는 능력이다.
RICCE는 프롬프트 기법이 아니라
사고 정렬 프레임이다.
막연한 요청 → 구조화된 지시
감각적 질문 → 명세 기반 설계
운에 맡긴 결과 → 재현 가능한 결과
AI가 바뀐 게 아니다.
우리가 말하는 방식이 바뀌어야 한다.
