- 1좋은 프롬프트의 구성 요소인 'Role · Context · Task · Output'은 지금도 유효합니다.
- 2달라진 건 칸을 채우는 방식입니다. 이것저것 금지하고 강조하고 재촉하던 습관을 버리고, 원하는 결과와 범위를 그대로 말합니다.
- 3이건 곧 팀 운영과 같습니다. 강압적 지시가 아니라, 똑똑한 동료에게 맡기는 명확한 위임입니다.
- 4무게중심도 '문장 잘 쓰기'에서 '일 통째로 맡기기'로 옮겨갔습니다. 핵심은 목표·채점기준·검증·멈춤조건입니다.
공식은 그대로, 채우는 법이 달라졌습니다
'Role · Context · Task · Output' 공식이 최신 Claude에서 어떻게 달라졌는지 칸별로 정리했습니다.
같은 작업, 예전 프롬프트 → 지금 프롬프트
화려한 역할 + "자세히·반드시·절대" 재촉 + 사고 단계 지정 + 금지어. 게으른 모델에서 답을 끌어내던 방식.
한 줄 역할 + 행동 동사("다시 써줘") + 목표·범위 + '왜' + 원하는 형식. 똑똑한 동료에게 위임하듯 말합니다.
한눈에 보기 · 과거에 통하던 습관 → 지금 통하는 방식
| 과거 (예전 모델) | 현재 (최신 Claude) | |
|---|---|---|
| 역할 부여(Role) | 길고 화려한 페르소나를 잔뜩 쌓기 | 정확한 한 문장이면 충분 |
| 맥락(Context) | 배경만 나열, 싫은 건 "하지 마"로 금지 | '왜'까지 설명, 긴 자료는 맨 위에 |
| 작업 지시(Task) | 완곡한 "제안해줘", "자세히"로 재촉 | 행동 동사 + 목표 수준 + 적용 범위 |
| 출력 형식(Output) | 답변 미리 채우기·금지어로 형식을 강제 고정 | 원하는 형식을 직접 보여주기 |
| 강조(Emphasis) | "반드시", "절대", 대문자·느낌표로 압박 | 담담하게 한 번만 말하기 (과잉 반응 방지) |
| 사고 단계(Reasoning) | "1단계… 2단계…" 추론 과정을 일일이 지정 | 목표만 주고 방법은 위임 |
네 칸을 하나씩: 예전 공식 → 지금 방식
앞의 표에서 본 네 칸을, 이번엔 예시와 이유까지 하나씩 풀어봅니다.
역할을 길고 화려하게 부여할수록 좋다고 배웠습니다.
역할 부여는 지금도 효과적입니다. 다만 한 문장이면 충분합니다.
왜: 모델의 기본 실력이 좋아져서, 역할을 길게 꾸미는 것보다 정확한 한 문장이 더 잘 통합니다.
배경 정보를 최대한 많이 나열하고, 싫은 건 "하지 마"로 금지했습니다.
정보에 '왜'를 더합니다. 이유를 알면 시키지 않은 상황까지 맞춥니다.
왜: 이유를 알려주면 모델이 말하지 않은 부분까지 알아서 맞춥니다. 또 수십 쪽짜리 긴 자료는 맨 위에, 질문은 맨 아래에 두면 응답 품질이 최대 30%까지 좋아집니다.
완곡하게 "제안해줘", 게으름 막으려 "자세히", 사고 단계까지 지정했습니다.
작업 칸에서 네 가지가 바뀌었습니다.
- 1'제안' 대신 행동 동사: "다시 써줘 · 바꿔줘 · 만들어줘"
- 2목표 수준을 담기: "초안 말고, 바로 보고에 쓸 수준으로"
- 3적용 범위 못 박기: "첫 항목만 말고 모든 항목에"
- 4강조·단계 지정 빼기: "충분히 검토하고 답해줘"
왜: 최신 모델은 말한 그대로 따릅니다. 그래서 완곡하게 말하면 제안에 그치고, 너무 세게 말하면 오히려 과하게 반응합니다.
답변 첫 글자를 미리 채우거나(prefill), "마크다운 쓰지 마"로 형식을 통제했습니다.
원하는 형식을 직접 말하거나 예시로 보여줍니다. prefill(답변 미리 채우기)은 지금도 되지만, 예전만큼 필요하지 않습니다.
- 1금지 대신 원하는 모습 묘사: "매끄럽게 이어지는 문단으로"
- 2구조는 그냥 요청: "JSON 형식으로 줘"
- 3예시 3~5개나 태그로 고정: "이 예시와 같은 형식으로"
왜: 형식 지시를 잘 따르도록 진화해, 굳이 고정할 필요가 없어졌습니다.
한 문장 잘 쓰기에서, 일 통째로 맡기기로
지금까지는 한 번의 프롬프트를 다듬는 법이었습니다. 더 큰 변화는, 여러 단계를 스스로 맡길 때 무엇을 적느냐에 있습니다. 무게중심이 '문장'에서 '작업'으로 옮겨갔습니다.
무엇이 중요한지가 바뀌었다 · 문장 설계 → 작업 설계
| 과거에 중요했던 것 | 지금 중요한 것 | |
|---|---|---|
| 작업 단위 | 한 번의 프롬프트 (대화 한 턴) | 하나의 작업 위임 (여러 턴·여러 단계) |
| 핵심 요소 | Role · Context · Task · Output · Format | 목표 · 채점기준 · 검증 · 멈춤조건 |
| '잘한다'의 뜻 | 문장을 어떻게 쓰느냐 | 무엇을 맡기고, 어디서 멈추게 하느냐 |
| 모델의 역할 | 답을 한 번 써 주는 작성기 | 스스로 단계를 밟는 실행자 |
| 대표 실패 | 형식이 틀리거나 톤이 어긋남 | 시키지 않은 일까지 하거나, 멈출 때 안 멈춤 |
끝났을 때 무엇이 나와야 하는지와 이번 턴의 범위를 못 박습니다.
왜: 끝나는 지점을 정해 주지 않으면, 모델이 시키지 않은 다음 단계까지 알아서 진행해 버립니다.
무엇이 '잘한 것'인지, 통과와 실패를 가르는 선을 미리 줍니다. 모호한 '잘해줘'를 대체합니다.
왜: 기준이 있으면 스스로 자기 답을 검사할 잣대가 생깁니다.
답을 내놓기 전에 스스로 점검·반박하게 만드는 단계를 박아 둡니다.
왜: 모델이 자신을 비판하게 하면 그럴듯하지만 틀린 답이 걸러집니다.
어디까지 하고 멈출지, 무엇은 절대 하지 말지를 명시합니다. 위임의 안전장치입니다.
왜: 스스로 도구를 쓰고 실행하는 모델일수록 멈출 선이 있어야 맡길 수 있습니다.
실제 예시 · 경쟁사 분석 요청
🧭 왜 무게중심이 옮겨갔을까요?
과거 모델은 한 번 묻고 한 번 답하는 작성기에 가까웠습니다. 그래서 그 한 번의 답이 잘 나오도록 문장(역할·맥락·형식)을 다듬는 것이 핵심이었습니다. 최신 모델은 스스로 여러 단계를 밟고, 파일을 읽고, 도구를 쓰고, 코드까지 실행하는 실행자로 바뀌었습니다. 이제 중요한 것은 '프롬프트를 어떻게 쓰느냐'가 아니라 '무엇을 맡길지, 무엇을 합격으로 볼지, 어디서 멈추게 할지'입니다.
한 장으로 보는 프롬프트 공식
출력하거나 캡처해서 옆에 두고 쓰세요. 한 문장을 쓸 때의 RCTO와, 일을 통째로 맡길 때의 목표·채점·검증·멈춤을 한 장에 담았습니다.
- 길고 화려한 페르소나
- 한 문장이면 충분: "너는 노련한 ○○야"
- "하지 마"로 금지만
- 이유('왜')까지 설명하기
- 긴 자료는 맨 위, 질문은 맨 아래
- "제안해줘 · 자세히 · 반드시"
- 행동 동사로: "바꿔줘 · 만들어줘"
- 목표 수준과 범위를 문장에 담기
- 단계 지정 대신 "충분히 검토하고 답해줘"
- 형식 강제(답변 미리 채우기)
- 원하는 형식을 직접 묘사하기
- 구조는 그냥 요청: "JSON으로 줘"
- 예시·태그로 형식 고정
- 끝났을 때 무엇이 나와야 하는지
- 이번 턴의 범위를 못 박기
- 통과·실패를 가르는 선
- "출처 연결 가능, 추측 금지"
- 답 내기 전 스스로 점검
- "약한 가정 3가지 지적할 것"
- 어디까지 하고 멈출지
- "여기까진 절대 금지, 승인 후 진행"
📎 출처
Prompting best practices (Anthropic)
Claude 최신 모델(Opus 4.8 · 4.7 · 4.6 · Sonnet 4.6 · Haiku 4.5) 기준
platform.claude.com · Prompting best practices