프롬프트 잘 쓰는 법

결론부터

1우리가 배운 프롬프트 공식은 보통 'Role(역할) + Context(맥락) + Task(작업) + Output(출력 형식)' 네 칸이었습니다. 이 뼈대 자체는 지금도 유효합니다.
2달라진 건 각 칸을 채우는 방식입니다. 막고, 강조하고, 닦달하던 습관을 덜어내고, 원하는 결과와 범위를 그대로 말하는 쪽으로 바뀌었습니다.
3이 변화는 곧 팀을 운영하는 방식과 같습니다. 강압적 지시 대신 명확한 위임이고, 똑똑한 사람에게 일을 맡기는 원리 그대로입니다.
4한 발 더 나아가, 무게중심이 '문장 잘 쓰기'에서 '일 통째로 맡기기'로 옮겨갔습니다. 이제 핵심은 Role·Context·Task·Output이 아니라 목표·채점기준·검증·멈춤조건입니다(SECTION 3).

SECTION 1 · 프롬프트 공식

뼈대는 그대로, 채우는 법이 달라졌습니다

널리 배운 'Role · Context · Task · Output' 공식이 최신 Claude에서 어떻게 달라졌는지, 칸별로 한 줄씩 정리했습니다.

옛날 공식(취소선) → 지금 채우는 법

RRole(역할) · 길고 화려한 페르소나 → 한 문장이면 충분
CContext(맥락) · 배경만 잔뜩 나열 → '왜'까지 설명, 긴 자료는 맨 위
TTask(작업) · "제안해줘 · 자세히" → 행동 동사 + 목표 수준 + 범위
OOutput(출력) · 형식 강제 · "하지 마" → 원하는 형식을 직접 보여주기

💡

왜 채우는 법이 바뀌었을까요?

과거 모델은 게으르거나 지시를 흘려들을 때가 있어, 사용자들이 강조·반복·단계 지정으로 억지로 끌어내야 했습니다. 최신 모델은 지시를 문자 그대로, 충실히 따릅니다. 그래서 옛날 보조 장치들이 이제는 과잉 반응을 부릅니다. 네 칸을 하나씩 비교해 봅니다.

같은 작업, 예전 프롬프트 → 지금 프롬프트

과거에 쓰던 프롬프트

너는 세계 최고의 마케팅 구루이자 수많은 상을 받은 전설적인 카피라이터야. 아래 보고서를 분석해서 개선점을 가능한 한 자세히, 빠짐없이 제안해줘. 반드시 단계별로 생각하고, 절대 대충 하지 마. 1단계로 문제점을 찾고, 2단계로 해결책을 제시해. 마크다운은 쓰지 마!!!

화려한 역할 + "자세히·반드시·절대" 닦달 + 사고 단계 지정 + 금지어. 게으른 모델을 억지로 끌어내던 방식입니다.

지금 쓰는 프롬프트

너는 노련한 마케팅 카피라이터야. 이 보고서를 임원 보고용으로 다시 써줘. 핵심만 간결하게, 모든 항목에 똑같이 적용해줘. 임원들이 30초 안에 의사결정할 수 있어야 해서 그래. 자연스럽게 이어지는 산문 단락으로 줘.

한 줄 역할 + 행동 동사("다시 써줘") + 목표·범위 + '왜' + 원하는 형식. 똑똑한 동료에게 위임하듯 말합니다.

한눈에 보기 · 과거에 통하던 습관 → 지금 통하는 방식

	과거 (예전 모델)	현재 (최신 Claude)
역할 부여	길고 화려한 페르소나를 잔뜩 쌓기	정확한 한 문장이면 충분
맥락	배경만 나열, 싫은 건 "하지 마"로 막기	'왜'까지 설명, 긴 자료는 맨 위에
작업 지시	완곡한 "제안해줘", "자세히"로 닦달	행동 동사 + 목표 수준 + 적용 범위
출력 형식	prefill·금지어로 형식을 강제 고정	원하는 형식을 직접 보여주기
강조	"반드시", "절대", 대문자·느낌표로 압박	담담하게 한 번만 말하기 (과잉 반응 방지)
사고 단계	"1단계… 2단계…" 추론 과정을 일일이 지정	목표만 주고 방법은 위임

SECTION 2 · 과거 vs 지금

네 칸을 하나씩: 예전 공식 → 지금 방식

Role, Context, Task, Output 순서로 무엇이 달라졌는지 비교했습니다.

R Role · 역할은 길게 줄수록 좋다?

예전 공식

역할을 길고 화려하게 부여할수록 좋다고 배웠습니다.

너는 세계 최고의 마케팅 구루이며 수많은 상을 받은 카피라이터야...

지금은 이렇게

역할을 정해 주는 건 지금도 효과적입니다. 다만 한 문장이면 충분하니, 짧고 분명하게 적어 주세요.

너는 노련한 마케팅 카피라이터야.

왜: 모델의 기본 성능이 올라가면서, 긴 수식어보다 정확한 한 줄이 더 잘 통합니다.

C Context · 배경만 많이 넣으면 된다?

예전 공식

배경 정보를 최대한 많이 나열하고, 싫은 건 "하지 마"로 막았습니다.

줄임표 절대 쓰지 마

지금은 이렇게

정보에 더해 '왜'를 설명합니다. 이유를 알면 시키지 않은 상황까지 알아서 맞춥니다.

이 글은 음성으로 읽혀. 그래서 줄임표는 쓰지 말아줘

왜: 모델은 이유를 주면 스스로 일반화합니다. 또한 긴 자료는 프롬프트 맨 위, 질문은 맨 아래에 두면 복잡한 문서에서 응답 품질이 최대 30%까지 좋아집니다.

T Task · "제안해줘, 가능한 한 자세히"?

예전 공식

완곡하게 "제안해줘", 게으름 막으려 "자세히", 사고 단계까지 일일이 지정했습니다.

이 보고서 개선점 제안해줘. 가능한 한 자세히

지금은 이렇게

작업 칸에서 네 가지가 바뀌었습니다.

이 보고서를 임원 보고용으로 다시 써줘. 핵심만 간결하게

1완곡한 '제안' 대신 행동 동사로: "다시 써줘 · 바꿔줘 · 만들어줘"
2목표 수준을 문장에 담기: "기본을 넘어 완성형으로"
3적용 범위 못 박기: "첫 항목만 말고 모든 항목에 똑같이"
4"자세히·반드시" 강조와 단계 지정 빼기: "충분히 검토하고 답해줘"

왜: 최신 모델은 시킨 그대로 정확히 합니다. 완곡하게 말하면 제안만 하고, 강하게 말하면 오히려 과하게 반응합니다.

O Output · 형식은 강제로 고정한다?

예전 공식

답변 첫 글자를 미리 채우거나(prefill), "마크다운 쓰지 마"처럼 금지로 형식을 통제했습니다.

(답변 앞에 '{' 미리 박기) / 마크다운 쓰지 마

지금은 이렇게

원하는 형식을 직접 말하고, 예시나 태그로 보여줍니다. prefill은 막혔습니다(4.6 이상).

JSON 형식으로 줘 / 자연스러운 산문 단락으로 써줘

1금지 대신 원하는 모습을 묘사: "매끄럽게 이어지는 문단으로"
2구조가 필요하면 그냥 요청: "JSON 형식으로 줘" (또는 Structured Outputs)
3예시 3~5개나 태그로 형식을 고정: "이 예시와 같은 형식으로"

왜: 형식 지시를 잘 따르도록 진화해, 억지로 고정하던 장치가 필요 없어졌습니다.

SECTION 3 · 단발 → 위임

한 문장 잘 쓰기에서, 일 통째로 맡기기로

지금까지는 한 번의 프롬프트를 다듬는 법이었습니다. 더 큰 변화는, 모델에게 여러 단계를 스스로 맡길 때 무엇을 적느냐입니다. 무게중심이 '문장'에서 '작업'으로 옮겨갔습니다.

무엇이 중요한지가 바뀌었다 · 문장 설계 → 작업 설계

	과거에 중요했던 것	지금 중요한 것
작업 단위	한 번의 프롬프트 (대화 한 턴)	하나의 작업 위임 (여러 턴·여러 단계)
핵심 요소	Role · Context · Task · Output · Format	목표 · 채점기준 · 검증 · 멈춤조건
'잘한다'의 뜻	문장을 어떻게 쓰느냐	무엇을 맡기고, 어디서 멈추게 하느냐
모델의 역할	답을 한 번 써 주는 작성기	스스로 단계를 밟는 실행자
대표 실패	형식이 틀리거나 톤이 어긋남	시키지 않은 일까지 하거나, 멈출 때 안 멈춤

💡

RCTO는 사라진 게 아닙니다

Role·Context·Task·Output은 여전히 한 문장을 적는 좋은 뼈대입니다. 다만 이제는 더 큰 그릇의 한 부분이 되었습니다. 일을 통째로 맡길 때는, 그 위에 목표·채점기준·검증·멈춤조건이라는 네 가지를 더 얹습니다. '잘 쓴 문장'을 넘어 '안전하게 위임한 작업'이 목표입니다.

1목표Goal

이 작업이 끝났을 때 무엇이 나와야 하는지, 그리고 이번 턴의 범위를 못 박습니다. 산출물의 형태를 분명히 합니다.

이번 턴의 산출물은 '전략 제안'이 아니라 경쟁사 비교 분석표다.

왜: 자율성이 커진 모델은 끝점을 정하지 않으면 다음 단계까지 알아서 달려갑니다.

2채점기준합격선

무엇을 충족해야 '잘한 것'인지, 통과와 실패를 가르는 선을 미리 줍니다. 모호한 '잘해줘'를 대체합니다.

모든 수치는 공시·IR 등 출처에 연결 가능해야 함. 추측성 표현 금지.

왜: 기준이 있으면 모델이 스스로 자기 답을 검사할 잣대가 생깁니다.

3검증Self-check

답을 내놓기 전에 스스로 점검·반박하게 만드는 단계를 박아 둡니다.

끝낸 뒤, 이 분석에서 가장 약한 근거 3가지를 스스로 지적할 것.

왜: 모델이 자신을 비판하게 하면 그럴듯하지만 틀린 답이 걸러집니다.

4멈춤조건Stop

어디까지 하고 멈출지, 무엇은 절대 하지 말지를 명시합니다. 위임의 안전장치입니다.

비교 분석까지만. 전략 제안·실행안은 절대 금지. 승인 후 다음 단계.

왜: 스스로 도구를 쓰고 실행하는 모델일수록 멈출 선을 줘야 안심하고 맡깁니다.

실제 예시 · 경쟁사 분석 요청

아래 한 통의 요청 안에 네 요소가 모두 들어 있습니다. 라벨을 떼어 보면 구조가 보입니다.

목표Goal "이번 턴의 산출물은 전략 제안이 아니라, 경쟁사 3사를 같은 기준으로 비교한 분석 문서다. 전략·실행안은 승인 뒤 다음 단계에서 만든다."

채점기준합격선 "모든 수치·주장은 출처(공시·IR·뉴스)에 연결 가능해야 함. 3사를 동일 항목·동일 기준으로 비교. 추측성 표현 금지."

검증Self-check "분석을 끝낸 뒤, 스스로 '이 분석에서 가장 약한 근거 3가지'를 별도로 지적할 것."

멈춤조건Stop "비교 분석 문서까지만 작성하고 멈춘다. 전략 제안·실행안 작성·외부 공유는 절대 하지 말 것. 승인 후 다음 단계로 넘어간다."

🧭

왜 무게중심이 옮겨갔을까요?

과거 모델은 한 번 묻고 한 번 답하는 작성기에 가까웠습니다. 그래서 그 한 번의 답이 잘 나오도록 문장(역할·맥락·형식)을 다듬는 게 핵심이었습니다. 최신 모델은 스스로 여러 단계를 밟고, 파일을 읽고, 도구를 쓰고, 코드를 실행하는 실행자로 바뀌었습니다. 일을 통째로 맡길 수 있게 되자, 중요한 것은 '문장을 어떻게 쓰느냐'에서 '무엇을 맡기고, 무엇을 합격으로 보고, 어디서 멈추게 하느냐'로 옮겨갔습니다.

SECTION 4 · 한 장 요약

한 장으로 보는 프롬프트 공식

출력하거나 캡처해서 옆에 두고 쓰세요. 한 문장을 쓸 때의 RCTO와, 일을 통째로 맡길 때의 목표·채점·검증·멈춤을 한 장에 담았습니다.

프롬프트 한 장 요약

한 문장 쓸 때는 RCTO, 일을 통째로 맡길 때는 목표·채점·검증·멈춤

R 역할Role

길고 화려한 페르소나
한 문장이면 충분: "너는 노련한 ○○야"

C 맥락Context

"하지 마"로 막기만
이유('왜')까지 설명하기
긴 자료는 맨 위, 질문은 맨 아래

T 작업Task

"제안해줘 · 자세히 · 반드시"
행동 동사로: "바꿔줘 · 만들어줘"
목표 수준과 범위를 문장에 담기
단계 지정 대신 "충분히 검토하고 답해줘"

O 출력 형식Output

형식 강제(prefill)
원하는 형식을 직접 묘사하기
구조는 그냥 요청: "JSON으로 줘"
예시·태그로 형식 고정

일을 통째로 맡길 때 (위임의 4요소)

RCTO 위에 얹는다 · 한 번의 답이 아니라 여러 단계를 맡길 때

목 목표Goal

끝났을 때 무엇이 나와야 하는지
이번 턴의 범위를 못 박기

채 채점기준합격선

통과·실패를 가르는 선
"출처 연결 가능, 추측 금지"

검 검증Self-check

답 내기 전 스스로 점검
"약한 가정 3가지 지적할 것"

멈 멈춤조건Stop

어디까지 하고 멈출지
"여기까진 절대 금지, 승인 후 진행"

AI ROASTING · 비즈니스 리더를 위한 Claude 완전 정복 · 출처: Anthropic Prompting best practices

📎 출처

Prompting best practices (Anthropic)
Claude 최신 모델(Opus 4.8 / 4.7 / 4.6, Sonnet 4.6, Haiku 4.5) 기준
platform.claude.com · Prompting best practices

이 페이지는 위 공식 가이드의 권고를, 널리 알려진 'Role · Context · Task · Output' 네 칸 공식과 비교해 한국어로 다시 정리한 것입니다. 개발 배경이 없는 리더·실무자도 바로 적용할 수 있도록 풀어 썼습니다. 정확한 원문과 API 설정(effort, adaptive thinking 등)은 위 링크에서 확인하실 수 있습니다.