30초 요약: 원칙은 하나, 조정은 모델별
1. 공식 문서는 공통 원칙 문서 1개 + 모델별 프롬프트 문서 5개 구조입니다. Fable 5.1, Fable 5, Sonnet 5, Opus 5, Opus 4.8이 각자 페이지를 가집니다.
2. 모델별 문서 세 개가 하나같이 가장 먼저 다루는 주제가 “응답 길이와 장황함”입니다. 즉 지금 클로드 프롬프트에서 손을 제일 많이 봐야 하는 건 길이 통제입니다.
3. 문서에 그대로 붙여 쓸 수 있는 영문 문구가 들어 있습니다. 직접 짜지 말고 이걸 먼저 쓰는 편이 빠릅니다.
그리고 놓치기 쉬운 것 하나. Sonnet 5에서는 temperature, top_p, top_k를 기본값이 아닌 값으로 넣으면 400 오류가 납니다. 예전 프롬프트를 그대로 옮기면 여기서 막힙니다.
공식 문서는 이렇게 나뉘어 있습니다
프롬프트 엔지니어링 개요 페이지는 의외로 짧고, 본론을 다른 곳으로 넘깁니다. 개요가 강조하는 건 기법이 아니라 전제 조건입니다. 문서는 이 가이드를 읽기 전에 (1) 성공 기준이 명확할 것, (2) 그 기준을 경험적으로 시험할 방법이 있을 것, (3) 개선할 초안 프롬프트가 있을 것을 요구합니다. 셋 중 없는 게 있으면 그것부터 만들라고 합니다.
그리고 한 줄 더 붙습니다. “모든 성공 기준이나 실패한 평가가 프롬프트 엔지니어링으로 가장 잘 해결되는 건 아니다. 예를 들어 지연 시간과 비용은 다른 모델을 고르는 쪽이 더 쉬울 때가 있다.” 프롬프트를 고쳐서 될 문제인지부터 가르라는 뜻입니다.
문서가 권하는 읽는 순서도 명확합니다. “각 모델에는 자체 프롬프트 페이지가 있다. 자기 모델 것을 먼저 읽고, 그다음 이어지는 기법들을 보라.” 공통 원칙부터 읽는 게 아니라 모델 페이지가 먼저입니다.
공통 원칙 여섯 가지
공통 원칙 문서는 현재 세대 모델 전반에 적용되는 기법을 다룹니다. 다만 단서가 붙습니다. “특정 모델을 지목한 기법은 그 모델에서 측정된 것으로 보고, 다른 모델에 적용하기 전에 자신의 평가로 다시 확인하라.”
| 원칙 | 핵심 | 문서가 드는 예 |
|---|---|---|
| 명확하고 직접적으로 | “맥락이 거의 없는 똑똑한 신입”에게 설명하듯 씁니다. 더 잘해 주길 바라면 그걸 명시적으로 요청해야 합니다 | “분석 대시보드 만들어” → “분석 대시보드를 만들되 관련 기능과 상호작용을 최대한 많이 넣고, 기본을 넘어 완성도 있게 구현해” |
| 맥락과 이유를 준다 | 왜 그렇게 해야 하는지 붙이면 모델이 일반화해서 적용합니다 | “말줄임표 쓰지 마” → “이 응답은 TTS로 낭독되니 말줄임표를 쓰지 마. 엔진이 발음을 모른다” |
| 예시를 쓴다 | 출력 형식·톤·구조를 잡는 가장 확실한 방법. 3~5개를 권합니다 | 관련성 있게, 예외까지 다양하게, <example> 태그로 감싸서 |
| XML 태그로 구조화 | 지시·맥락·예시·입력이 섞일 때 각각을 태그로 감싸면 오해가 줄어듭니다 | <instructions>, <context>, <input>. 계층이 있으면 중첩 |
| 역할을 준다 | 시스템 프롬프트에 한 문장만 넣어도 동작과 톤이 달라집니다 | system: "You are a helpful coding assistant specializing in Python." |
| 순서가 중요하면 번호로 | 단계의 순서나 완결성이 중요하면 번호 목록으로 줍니다 | 출력 형식과 제약을 구체적으로 명시 |
여기서 가장 실용적인 건 문서가 “황금률”로 제시한 검증법입니다. “맥락을 거의 모르는 동료에게 프롬프트를 보여 주고 그대로 따라 해 보라고 하라. 그가 헷갈린다면 클로드도 헷갈린다.” 프롬프트를 고칠지 말지 판단이 안 설 때 쓰기 좋은 기준입니다.
모델별로 다르게 조정해야 하는 것
공식 표의 “무엇이 다른가” 열을 모델별로 옮기면 이렇습니다. 앞 모델에서 넘어올 때 새로 손봐야 할 항목이라고 읽으면 됩니다.
| 모델 | 비교 대상 | 새로 조정할 항목 |
|---|---|---|
| Claude Opus 5 | 이전 Opus 계열 | 응답 길이와 장황함, 사용자 대상 진행 상황 보고, 작성 산출물 길이, 작업 범위와 과도한 검증, 서브에이전트 생성 제어, 자기 수정 |
| Claude Sonnet 5 | Sonnet 4.6 | 응답 길이, effort와 사고 깊이 조절, 도구 사용 촉발, 문자 그대로의 지시 이행, 디자인·프런트엔드 기본값 |
| Claude Fable 5.1 | Fable 5 | effort 수준, 긴 작업 끝내기, 진행 상황 보고, 사고 블록 원형 그대로 전달, 에이전트 루프의 도구 호출 묶기, 낮은 effort에서의 검색 촉발, 서식, 글 밀도 |
| Claude Opus 4.8 | — | 응답 길이, effort와 사고 깊이 조절, 도구 사용 촉발, 서브에이전트 제어, 디자인·프런트엔드 기본값 |
흥미로운 건 모델마다 성격이 반대 방향으로 기운다는 점입니다. Sonnet 5는 지나치게 문자 그대로 받아들입니다. 문서 표현으로는 “한 항목의 지시를 다른 항목으로 조용히 일반화하지 않고, 요청하지 않은 것을 추론하지 않는다”입니다. 장점은 예측 가능성이라 구조화된 추출이나 파이프라인에 유리하고, 대신 넓게 적용하고 싶으면 범위를 직접 말해야 합니다. 문서가 드는 예시 문장이 “이 서식을 첫 번째 섹션만이 아니라 모든 섹션에 적용해”입니다.
반대로 Opus 5는 말이 길어지는 쪽입니다. 문서는 “기본 응답이 이전 Opus 모델들보다 길게 나온다”고 적고, 에이전트 작업 중에는 “하려는 일을 먼저 announce하는 경향”이 있어 메시지당 출력이 더 길다고 설명합니다. Fable 5.1은 글이 촘촘해지는 쪽입니다. “문장이 길어지고 문단 나눔이 줄어든다”고 표현합니다.
세 문서가 모두 첫 번째로 다루는 주제
Opus 5, Sonnet 5, Fable 5.1 페이지를 나란히 열면 첫 섹션이 겹칩니다. 전부 길이 이야기입니다. 그런데 처방이 미묘하게 다릅니다.
| 모델 | 기본 성향 | 문서의 처방 |
|---|---|---|
| Opus 5 | 기본 응답이 길다 | effort를 낮춰도 보이는 응답이 짧아지지 않는다. 길이는 프롬프트로 직접 지시해야 한다 |
| Sonnet 5 | 작업 복잡도에 맞춰 길이를 스스로 조절한다 | 단순 조회는 짧고 개방형 분석은 길다. 특정 분량이 필요하면 프롬프트를 손봐야 한다 |
| Fable 5.1 | 글이 조밀하다 | ‘꾸민 문체(mannered prose)’라는 안티패턴을 정의해 주면 개선된다 |
여기서 가장 실무적으로 중요한 문장이 Opus 5 쪽에 있습니다. effort 파라미터는 모델이 얼마나 ‘생각하는지’를 조절할 뿐, 얼마나 ‘말하는지’를 조절하지 않는다는 것입니다. 응답이 길어서 effort를 낮추는 건 잘못된 처방이고, 비용만 아끼고 길이는 그대로일 수 있습니다.
또 하나 반복되는 조언이 있습니다. “하지 마”보다 “이렇게 해”가 낫다는 것입니다. Opus 5 문서는 “원하는 소통 방식의 긍정적 예시가 하지 말라는 지시보다 효과적”이라고 적고, Sonnet 5 문서도 “적절한 간결함을 보여 주는 긍정적 예시가 부정적 예시나 금지 지시보다 대체로 효과적”이라고 같은 말을 합니다. 두 문서가 독립적으로 같은 결론을 적어 둔 셈입니다.
그대로 복사해 쓸 수 있는 문구
문서에 실린 예시는 전부 영문입니다. 한국어로 옮겨 써도 되지만, 문서가 그 표현으로 측정했다고 밝힌 만큼 원문 그대로 쓰는 편이 안전합니다. 용도별로 추렸습니다.
| 상황 | 문서가 제시한 문구 |
|---|---|
| 응답이 너무 길 때 (Opus 5) | Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested. |
| 긴 시스템 프롬프트 끝에 붙일 상기용 | <tone_preference> Keep outputs reasonably concise. </tone_preference> |
| 에이전트 작업 중 보고를 줄이고 싶을 때 | Before your first tool call, say in one sentence what you’re about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome. |
| 문서·보고서 분량이 부풀 때 | Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate. |
| 장황함을 줄일 때 (Sonnet 5) | Provide concise, focused responses. Skip non-essential context, and keep examples minimal. |
| 따뜻한 톤이 필요할 때 (Sonnet 5) | Use a warm, collaborative tone. Acknowledge the user’s framing before answering. |
| 지시를 넓게 적용시킬 때 (Sonnet 5) | Apply this formatting to every section, not just the first one. |
Opus 5 문서는 긴 시스템 프롬프트를 쓸 때 간결함 지시를 프롬프트 끝부분에 한 번 더 넣으라고 권합니다. 앞부분에만 적어 두면 묻힌다는 뜻으로 읽힙니다.
놓치기 쉬운 함정
effort를 낮춰 응답을 줄이려는 것Opus 5 문서가 명시적으로 부정합니다. effort는 사고량이고 응답 길이는 별개입니다. 길이는 프롬프트로 지시하세요.
temperature로 문체를 다양화하던 습관Sonnet 5에서 temperature·top_p·top_k를 기본값 외 값으로 주면 400 오류입니다. 마이그레이션할 때 이 파라미터를 제거하고 시스템 프롬프트로 톤을 지시해야 합니다.
한 모델에서 검증한 프롬프트를 그대로 옮기는 것공통 원칙 문서가 “특정 모델에서 측정된 기법은 다른 모델에 적용하기 전에 다시 평가하라”고 단서를 답니다. 모델 교체는 프롬프트 재검증을 동반합니다.
“하지 마” 목록을 길게 쓰는 것Opus 5·Sonnet 5 문서 모두 긍정 예시가 더 효과적이라고 적습니다. 금지 목록 대신 원하는 결과의 예시를 주세요.
예시를 하나만 넣는 것공통 원칙은 3~5개를 권하고, 다양성이 없으면 모델이 의도치 않은 패턴을 학습한다고 경고합니다.
프롬프트로 해결할 문제가 아닌 경우개요 문서가 직접 말합니다. 지연 시간과 비용은 모델을 바꾸는 편이 쉬울 때가 있습니다.
자주 묻는 질문
한국어로 프롬프트를 써도 되나요?
공식 문서는 언어를 제한하지 않고 원칙(명확성, 맥락, 예시, 구조)만 제시합니다. 다만 문서가 제공하는 예시 문구는 영문 기준으로 안내된 것이라, 그 문구를 쓸 때는 원문 그대로가 안전합니다.
XML 태그를 꼭 써야 하나요?
필수는 아닙니다. 문서는 지시·맥락·예시·가변 입력이 섞이는 복잡한 프롬프트에서 태그가 오해를 줄인다고 설명합니다. 한 문단짜리 요청이라면 굳이 필요 없습니다.
초안 프롬프트가 없으면 어디서 시작하나요?
개요 페이지가 Claude Cookbook의 메타프롬프트 노트북을 안내합니다. 초안을 생성한 뒤 개선하는 순서를 권합니다.
Opus 5와 Sonnet 5 중 프롬프트를 덜 손봐도 되는 쪽은?
용도에 따라 다릅니다. Sonnet 5는 문자 그대로 이행해서 “정교하게 튜닝한 프롬프트, 구조화된 추출, 예측 가능한 파이프라인”에 더 낫다고 문서가 밝힙니다. 반대로 알아서 확장해 주길 원한다면 범위를 일일이 명시해야 해서 손이 더 갑니다.
이 글에 직접 실행한 비교가 있나요?
없습니다. 이번 글은 공식 문서 다섯 페이지를 열어 항목을 대조하고 표로 재구성한 것까지입니다. 같은 프롬프트를 모델별로 돌려 응답 길이를 실측한 비교는 하지 않았고, 그 부분은 별도로 다룰 예정입니다.
2026년 9월 15일 Anthropic 공식 문서(platform.claude.com)의 프롬프트 엔지니어링 개요, 공통 원칙 문서(Prompting best practices), 그리고 모델별 페이지인 Prompting Claude Opus 5·Prompting Claude Sonnet 5·Prompting Claude Fable 5.1을 직접 열어 항목을 대조했습니다. 본문의 인용과 표는 각 문서의 서술을 옮긴 것이며, 모델별 응답을 실제로 생성해 비교하는 실험은 이번에 하지 않았습니다.
프롬프트 엔지니어링 개요 ↗ · Prompting best practices ↗ · Prompting Claude Opus 5 ↗ · Prompting Claude Sonnet 5 ↗