시스템 프롬프트 (System Prompts)

시스템 프롬프트 (System Prompts)

[!NOTE] 원문: Anthropic Docs - Prompting best practices 시스템 프롬프트 페이지는 현재 공식 문서에서 Prompting best practices 가이드로 통합되었습니다. 아래는 그 전문 번역입니다.

이 문서는 현재 Claude 모델(Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, Claude Sonnet 4.6, Claude Haiku 4.5)을 대상으로 한 프롬프트 엔지니어링의 레퍼런스입니다. 페이지는 다음 세 부분으로 구성되어 있습니다.

  • 모델별 가이드 우선: 특정 모델이 다르게 동작하는 경우와, 프롬프트에서 무엇을 바꿔야 하는지.
  • 모든 현재 모델에 적용되는 기법: 일반 원칙, 출력·포맷, 툴 사용, thinking(추론), 에이전트 시스템.
  • 마이그레이션 고려사항 마지막: 이전 세대에서 작성된 프롬프트를 옮기는 경우.

모델 기능 개요는 모델 개요를, Claude Fable 5.1 기능·API 변경은 What's new in Claude Fable 5.1을, Claude Fable 5 기능·API 변경은 Introducing Claude Fable 5 and Claude Mythos 5를, Claude Sonnet 5의 새로운 점은 What's new in Claude Sonnet 5, Claude Opus 5의 새로운 점은 What's new in Claude Opus 5에서 확인하세요. 마이그레이션 안내는 Migration guide를 참고하세요.

모델별 가이드

각 모델은 저마다의 프롬프팅 페이지가 있습니다. 먼저 자신의 모델 문서를 읽은 뒤, 뒤이어 나오는 기법들을 살펴보세요.

모델 가이드 달라진 점
Claude Fable 5.1, Claude Mythos 5.1 Prompting Claude Fable 5.1 Claude Fable 5 대비 차이: effort 레벨, 긴 작업 마무리, 사용자 대상 진행 업데이트, thinking 블록을 그대로 되돌려주기, 에이전트 루프에서 툴 호출 배칭, 낮은 effort에서 검색 트리거, 포맷, 글쓰기 밀도.
Claude Fable 5, Claude Mythos 5 Prompting Claude Fable 5 Claude Opus 4.8 대비 차이: effort 레벨, 지시 따르기, 장기 실행 진행 주장, 메모리 시스템, reasoning_extraction 거절 카테고리.
Claude Sonnet 5 Prompting Claude Sonnet 5 Claude Sonnet 4.6 대비 차이: 응답 길이, effort·thinking 깊이 보정, 툴 사용 트리거, 문자 그대로의 지시 따르기, 디자인·프론트엔드 기본값.
Claude Opus 5 Prompting Claude Opus 5 이전 Opus 모델 대비 차이: 응답 길이와 장황함, 사용자 대상 진행 업데이트, 작성 산출물 길이, 작업 범위와 과도 검증, 서브에이전트 제어, 자기 수정.
Claude Opus 4.8 Prompting Claude Opus 4.8 응답 길이, effort·thinking 깊이 보정, 툴 사용 트리거, 문자 그대로의 지시 따르기, 서브에이전트 제어, 디자인·프론트엔드 기본값.

일반 원칙

이 섹션과 뒤따르는 섹션들의 기법들은 Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5 등 현재 Claude 모델에 적용됩니다. 기법이 특정 모델을 명시하면, 그 모델 기준으로 측정된 것이라 생각하고, 다른 모델에 적용하기 전에 자신의 평가(evals)로 다시 확인하세요.

명확하고 직접적으로

Claude는 명확하고 분명한 지시에 잘 반응합니다. 원하는 출력에 대해 구체적으로 설명할수록 결과가 좋아집니다. "한 걸음 더 나아간(above and beyond)" 동작을 원한다면, 모델이 모호한 프롬프트에서 그 의도를 유추하게 두지 말고 명시적으로 요청하세요.

Claude를 뛰어나지만 회사의 규칙과 워크플로에 대한 맥락이 없는 새 직원이라고 생각해 보세요. 원하는 것을 정확히 설명할수록 결과가 좋습니다.

황금률: 최소한의 맥락만 가진 동료에게 프롬프트를 보여주고 그대로 따라 해보라고 하세요. 그 동료가 헷갈린다면 Claude도 헷갈릴 것입니다.

  • 원하는 출력 형식과 제약 조건을 구체적으로 명시하세요.
  • 순서나 완결성이 중요할 때는 번호 목록이나 글머리 기호를 사용해 단계로 지시하세요.

예: 분석 대시보드 만들기

효과가 떨어지는 프롬프트:

Create an analytics dashboard

더 효과적인 프롬프트:

Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation.

맥락을 더해 성능 개선하기

지시 뒤에 맥락이나 이유를 제공하면, 예를 들어 그 동작이 왜 중요한지 설명하면 Claude가 목표를 더 잘 이해하고 더 목적에 맞는 응답을 내놓습니다.

예: 포맷 선호

효과가 떨어지는 프롬프트:

NEVER use ellipses

더 효과적인 프롬프트:

Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them.

Claude는 설명만으로도 충분히 일반화할 수 있을 만큼 똑똑합니다.

예시를 효과적으로 쓰기

예시는 Claude의 출력 형식·톤·구조를 이끄는 가장 확실한 방법 중 하나입니다. 잘 다듬어진 예시 몇 개(이를 few-shot 또는 multishot 프롬프팅이라 부릅니다)는 정확성과 일관성을 높여줍니다.

예시를 추가할 때는 다음을 갖춰야 합니다:

  • 관련성(Relevant): 실제 사용 사례와 거의 일치해야 합니다.
  • 다양성(Diverse): 엣지 케이스를 다루고, Claude가 의도치 않은 패턴을 배우지 않도록 충분히 달라야 합니다.
  • 구조화(Structured): 예시를 <example> 태그로 감싸세요(여러 개라면 <examples> 태그). 그래야 Claude가 지시와 구분할 수 있습니다.

최상의 결과를 위해 3~5개의 예시를 넣으세요. Claude에게 예시의 관련성·다양성을 평가하게 하거나, 초기 예시를 바탕으로 추가 예시를 생성하게 할 수도 있습니다.

XML 태그로 프롬프트 구조화하기

XML 태그는 특히 프롬프트에 지시·맥락·예시·변수 입력이 섞여 있을 때, Claude가 복잡한 프롬프트를 모호함 없이 파싱하도록 돕습니다. 콘텐츠 유형마다 고유한 태그(예: <instructions>, <context>, <input>)로 감싸면 오해가 줄어듭니다.

모범 사례:

  • 프롬프트 전체에 걸쳐 일관되고 설명적인 태그 이름을 쓰세요.
  • 콘텐츠가 자연스러운 계층을 가질 때 태그를 중첩하세요(문서는 <documents> 안에, 각각은 <document index="n"> 안에).

Claude에게 역할 부여하기

시스템 프롬프트에 역할을 설정하면 사용 사례에 맞게 Claude의 동작과 톤이 집중됩니다. 한 문장만으로도 차이가 납니다:

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system="You are a helpful coding assistant specializing in Python.",
    messages=[
        {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ],
)

print(message.content)

긴 컨텍스트 프롬프팅

대용량 문서나 데이터가 많은 입력(20k+ 토큰)을 다룰 때는 최상의 결과를 위해 프롬프트를 신중하게 구성하세요:

  • 긴 데이터를 위쪽에 배치: 긴 문서와 입력을 프롬프트 상단, 즉 질문·지시·예시보다 위에 두세요. 모든 모델에서 성능이 좋아집니다.
    • 특히 복잡하고 다중 문서인 입력에서는 질문을 끝에 배치하면 테스트에서 응답 품질이 최대 30%까지 개선됩니다.
  • 문서 내용과 메타데이터를 XML 태그로 구조화: 여러 문서를 사용할 때 각 문서를 <document> 태그로 감싸고, 명확성을 위해 <document_content>와 <source>(그 외 메타데이터) 하위 태그를 넣으세요.
  • 응답을 인용으로 근거 지우기: 긴 문서 작업에서는 작업을 수행하기 전에 관련 부분을 먼저 인용하라고 요청하세요. 그러면 Claude가 관련 내용에 집중하고 나머지는 무시할 수 있습니다.

모델 자기 인식(Model self-knowledge)

애플리케이션에서 Claude가 올바르게 자신을 식별하게 하거나 특정 API 문자열을 사용하게 하려면:

모델 정체성용 샘플 프롬프트

The assistant is Claude, created by Anthropic. The current model is Claude Opus 5.

LLM 기반 앱에서 모델 문자열을 지정해야 한다면:

모델 문자열용 샘플 프롬프트

When an LLM is needed, please default to Claude Opus 5 unless the user requests
otherwise. The exact model string for Claude Opus 5 is claude-opus-5.

출력과 포맷

커뮤니케이션 스타일과 장황함

Claude의 최신 모델은 이전 모델보다 더 간결하고 자연스러운 커뮤니케이션 스타일을 갖습니다:

  • 더 직접적이고 근거 중심: 자기 칭찬적인 업데이트 대신 사실 기반의 진행 보고를 합니다.
  • 더 대화적: 약간 더 유창하고 구어체에 가까우며, 기계적이지 않습니다.
  • 덜 장황함: 달리 요청받지 않으면 효율성을 위해 상세 요약을 생략할 수 있습니다.

따라서 Claude가 툴 호출 후 말로 요약하는 것을 건너뛰고 바로 다음 동작으로 넘어갈 수 있습니다. 추론 과정을 더 자세히 보고 싶다면:

샘플 프롬프트

After completing a task that involves tool use, provide a quick summary of the work you've done.

장황함에는 예외가 있습니다. Claude Opus 5는 기본 사용자 대상 응답이 이전 모델보다 길며, effort를 올리거나 내려도 표시되는 응답 길이가 확실히 변하지 않습니다. 대신 장황함을 줄이라는 프롬프트를 명시적으로 넣으세요(샘플 지시는 Prompting Claude Opus 5 참고). Claude Fable 5.1은 에이전트 작업 중 반대 경향이 있습니다 — 툴 호출 사이에 사용자 대상 업데이트를 더 적게 씁니다. 진행 텍스트를 명시적으로 요청하고, 그 텍스트를 짧게 유지하라는 지시는 제거하세요(Ask for user-facing progress updates 참고).

응답 형식 제어하기

출력 포맷을 이끄는 특히 효과적인 방법이 몇 가지 있습니다:

  • 하지 말라고 말하는 대신 무엇을 하라고 말하세요
    • 대신: "Do not use markdown in your response"
    • 시도: "Your response should be composed of smoothly flowing prose paragraphs."
  • XML 형식 지시자 사용하기
    • 시도: "Write the prose sections of your response in <smoothly_flowing_prose_paragraphs> tags."
  • 프롬프트 스타일을 원하는 출력에 맞추기
    • 프롬프트에 쓴 포맷 스타일이 응답 스타일에 영향을 줄 수 있습니다. 출력 포맷을 조정하기 어렵다면, 프롬프트 스타일을 원하는 출력 스타일과 최대한 비슷하게 맞춰보세요. 예를 들어, 프롬프트에서 마크다운을 제거하면 출력의 마크다운 양도 줄어듭니다.
  • 특정 포맷 선호에 상세 프롬프트 사용하기
    • 마크다운·포맷 사용을 더 잘 제어하려면 명시적인 지침을 제공하세요:

마크다운 최소화용 샘플 프롬프트

<avoid_excessive_markdown_and_bullet_points>
When writing reports, documents, technical explanations, analyses, or any long-form
content, write in clear, flowing prose using complete paragraphs and sentences. Use
standard paragraph breaks for organization and reserve markdown primarily for `inline
code`, code blocks (```...```), and simple headings (## and ###). Avoid using **bold**
and *italics*.

DO NOT use ordered lists (1. ...) or unordered lists (*) unless: a) you're presenting
truly discrete items where a list format is the best option, or b) the user explicitly
requests a list or ranking

Instead of listing items with bullets or numbers, incorporate them naturally into
sentences. This guidance applies especially to technical writing. Using prose instead of
excessive formatting will improve user satisfaction. NEVER output a series of overly
short bullet points.

Your goal is readable, flowing text that guides the reader naturally through ideas
rather than fragmenting information into isolated points.
</avoid_excessive_markdown_and_bullet_points>

[!NOTE] Claude Fable 5.1은 이미 이전 모델보다 포맷을 덜 사용하므로, 해당 모델에서는 이런 블록이 콘텐츠에 필요한 구조를 오히려 억제할 수 있습니다. 제거하거나 Formatting in chat의 더 짧은 규칙으로 대체하세요.

LaTeX 출력

Claude의 최신 모델은 수학 표현·방정식·기술 설명에 기본적으로 LaTeX를 사용합니다. 순수 텍스트를 원한다면 프롬프트에 다음 지시를 추가하세요:

샘플 프롬프트

Format your response in plain text only. Do not use LaTeX, MathJax, or any markup
notation such as \( \), $, or \frac{}{}. Write all math expressions using standard text
characters (e.g., "/" for division, "*" for multiplication, and "^" for exponents).

문서 생성(Document creation)

Claude의 최신 모델은 강력한 지시 따르기로 프레젠테이션·애니메이션·시각 문서를 만들며, 보통 첫 시도에 쓸 만한 출력을 냅니다.

문서 생성 최상의 결과를 위해:

샘플 프롬프트

Create a professional presentation on [topic]. Include thoughtful design elements,
visual hierarchy, and engaging animations where appropriate.

프리필드 응답에서 마이그레이션하기

Claude 4.6 모델과 Claude Mythos Preview부터, 마지막 어시스턴트 턴에서의 프리필드 응답(Claude가 이어서 완성할 부분 어시스턴트 메시지를 미리 제공하는 방식)은 더 이상 지원되지 않습니다. 이 모델들에 프리필드 어시스턴트 메시지가 포함된 요청은 400 에러를 반환합니다. 모델 지능과 지시 따르기가 발전하면서 프리필드가 필요한 대부분의 사용 사례가 더 이상 필요하지 않게 되었습니다. 이전 모델은 프리필드를 계속 지원하며, 대화의 다른 위치에 어시스턴트 메시지를 추가하는 것은 영향받지 않습니다.

일반적인 프리필드 사용 사례와 마이그레이션 방법:

  • 출력 포맷 제어
  • 전치사(preambles) 제거
  • 나쁜 거절 피하기
  • 이어쓰기(continuations)
  • 컨텍스트 하이드레이션과 역할 일관성

툴 사용

툴 사용법

Claude의 최신 모델은 정확한 지시 따르기로 훈련되었으며, 특정 툴을 쓰라는 명시적 지시를 받으면 잘 따릅니다. "can you suggest some changes"라고 하면, 변경이 의도였더라도 Claude가 구현 대신 제안만 하는 경우가 있습니다. 툴을 정의하고 트러블슈팅하는 방법은 Tool use with Claude를 참고하세요.

Claude가 실제로 행동하게 하려면 더 명시적으로 말하세요:

예: 명시적 지시

효과가 떨어지는 프롬프트(Claude는 제안만 할 것):

Can you suggest some changes to improve this function?

더 효과적인 프롬프트(Claude는 변경을 수행할 것):

Change this function to improve its performance.

또는:

Make these edits to the authentication flow.

Claude가 기본적으로 행동을 더 적극적으로 취하게 하려면 시스템 프롬프트에 다음을 추가할 수 있습니다:

적극적 행동용 샘플 프롬프트

<default_to_action>
By default, implement changes rather than only suggesting them. If the user's intent is
unclear, infer the most useful likely action and proceed, using tools to discover any
missing details instead of guessing. Try to infer the user's intent about whether a tool
call (e.g., file edit or read) is intended or not, and act accordingly.
</default_to_action>

반대로 모델이 기본적으로 더 신중하고, 바로 구현으로 뛰어들지 않으며, 요청받을 때만 행동하길 원한다면 다음과 같은 프롬프트로 동작을 조정할 수 있습니다:

보수적 행동용 샘플 프롬프트

<do_not_act_before_instructions>
Do not jump into implementation or change files unless clearly instructed to make
changes. When the user's intent is ambiguous, default to providing information, doing
research, and providing recommendations rather than taking action. Only proceed with
edits, modifications, or implementations when the user explicitly requests them.
</do_not_act_before_instructions>

Claude Opus 4.5와 Claude Opus 4.6은 이전 모델보다 시스템 프롬프트에 더 잘 반응합니다. 툴이나 스킬의 언더트리거링을 줄이기 위해 설계된 프롬프트를 썼다면, 이제 이 모델들이 오버트리거할 수 있습니다. 해법은 공격적인 표현을 줄이는 것입니다. "CRITICAL: You MUST use this tool when..."이라고 썼다면 "Use this tool when..."처럼 더 일반적인 프롬프팅으로 바꿀 수 있습니다.

병렬 툴 호출 최적화하기

Claude의 최신 모델은 독립적인 툴 호출을 병렬로 실행합니다. 이 모델들은:

  • 연구 중 여러 번의 탐색 검색을 동시에 실행
  • 컨텍스트를 더 빨리 쌓기 위해 여러 파일을 한 번에 읽기
  • (시스템 성능을 병목시킬 수도 있는) bash 명령을 병렬로 실행

이 동작은 조정할 수 있습니다. 프롬프트 없이도 병렬 툴 호출 성공률이 높지만, 약 ~100%까지 끌어올리거나 공격성을 조절할 수 있습니다:

최대 병렬 효율용 샘플 프롬프트

<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the tool
calls, make all of the independent tool calls in parallel. Prioritize calling tools
simultaneously whenever the actions can be done in parallel rather than sequentially.
For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into
context at the same time. Maximize use of parallel tool calls where possible to increase
speed and efficiency. However, if some tool calls depend on previous calls to inform
dependent values like the parameters, do NOT call these tools in parallel and instead
call them sequentially. Never use placeholders or guess missing parameters in tool
calls.
</use_parallel_tool_calls>

병렬 실행을 줄이는 샘플 프롬프트

Execute operations sequentially with brief pauses between each step to ensure stability.

[!NOTE] Claude Fable 5.1의 긴 에이전트 루프에서는, 각 툴 결과 라운드 이후 병렬 호출 지시를 턴 범위 시스템 메시지로 보내세요(Batch independent tool calls in agent loops 참고).

Thinking과 추론

과도한 사고와 과도한 철저함

Claude Opus 4.6은 이전 모델보다, 특히 높은 effort 설정에서 초기 탐색을 더 많이 수행합니다. 이 초기 작업이 종종 최종 결과 최적화에 도움이 되지만, 모델이 프롬프트 없이도 과도하게 컨텍스트를 모으거나 여러 연구 스레드를 추적할 수 있습니다. 프롬프트가 이전에 모델을 더 철저하게 장려했다면, 그러한 지침을 Claude Opus 4.6에 맞게 조정하세요:

  • 포괄적 기본값을 더 목표 지향적인 지시로 대체: "Default to using [tool]" 대신 "Use [tool] when it would enhance your understanding of the problem." 같은 지침을 추가하세요.
  • 과도한 프롬프팅 제거: 이전 모델에서 언더트리거했던 툴은 이제 적절히 트리거될 가능성이 높습니다. "If in doubt, use [tool]" 같은 지시는 오버트리거를 유발합니다.
  • effort를 대안으로 사용: Claude가 계속 과도하게 공격적이라면 effort를 더 낮게 설정하세요.

어떤 경우 Claude Opus 4.6은 과도하게 사고하여 thinking 토큰을 부풀리고 응답을 느리게 할 수 있습니다. 이런 동작이 바람직하지 않다면, 추론을 제한하는 명시적 지시를 추가하거나 effort 설정을 낮춰 전체 thinking·토큰 사용을 줄일 수 있습니다.

샘플 프롬프트

When you're deciding how to approach a problem, choose an approach and commit to it.
Avoid revisiting decisions unless you encounter new information that directly
contradicts your reasoning. If you're weighing two approaches, pick one and see it
through. You can always course-correct later if the chosen approach fails.

사고 비용에 상한이 필요하다면, budget_tokens 상한을 쓰는 extended thinking이 Opus 4.6과 Sonnet 4.6에서 여전히 동작하지만 **deprecated(더 이상 권장되지 않음)**입니다. Claude 4.7 이후 모델에서 budget_tokens를 설정하면 400 에러가 반환됩니다. effort 설정을 낮추거나, adaptive thinking과 함께 max_tokens를 하드 상한으로 쓰는 쪽을 선호하세요.

thinking & 인터리브드 thinking 활용하기

Claude의 최신 모델은 툴 사용 후 반성이나 복잡한 다단계 추론을 포함하는 작업에 특히 유용한 thinking 기능을 제공합니다. 초기 또는 인터리브드 thinking을 안내해 더 나은 결과를 얻을 수 있습니다.

Claude 4.6 이후 모델과 Claude Mythos Preview는 adaptive thinking(thinking: {type: "adaptive"})을 사용하는데, Claude가 언제·얼마나 생각할지를 동적으로 결정합니다. Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5에서는 thinking이 항상 켜져 있으며 adaptive thinking이 유일한 모드입니다. Claude는 effort 파라미터와 쿼리 복잡도라는 두 가지 요소로 thinking을 보정합니다. effort가 높을수록 더 많이 생각하고, 더 복잡한 쿼리도 마찬가지입니다. thinking이 필요 없는 쉬운 쿼리에는 모델이 직접 응답합니다. 내부 평가에서 adaptive thinking은 extended thinking보다 일관되게 더 나은 성능을 끌어냅니다. adaptive thinking으로 전환하는 것을 고려하세요.

다단계 툴 사용, 복잡한 코딩 작업, 장기 에이전트 루프 같은 에이전트 동작이 필요한 워크로드에는 adaptive thinking을 사용하세요. 이전 모델은 budget_tokens로 수동 extended thinking을 사용하며, 각 모델이 어떤 구성을 받아들이는지는 모델별 구성 표를 참고하세요.

Claude의 thinking 동작을 안내할 수 있습니다:

예시 프롬프트

After receiving tool results, carefully reflect on their quality and determine optimal
next steps before proceeding. Use your thinking to plan and iterate based on this new
information, and then take the best next action.

adaptive thinking의 트리거 동작은 프롬프트로 조정할 수 있습니다. 크거나 복잡한 시스템 프롬프트에서 모델이 원하는 것보다 더 자주 생각한다면, 안내를 추가해 조정하세요:

샘플 프롬프트

Thinking adds latency and should only be used when it will meaningfully improve
answer quality - typically for problems that require multistep reasoning. When in
doubt, respond directly.

budget_tokens로 extended thinking에서 마이그레이션한다면, thinking 구성을 교체하고 예산 제어를 effort로 옮기세요. 다음 예시는 마이그레이션 전후의 동일 요청을 보여줍니다(effort의 가용 레벨과 모델별 가용성은 effort 참고):

# Before: extended thinking with a manual budget (older models)
client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[{"role": "user", "content": "..."}],
)

# After: adaptive thinking with effort
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

extended thinking을 사용 중이 아니라면 변경할 필요가 없습니다. Claude Opus 4.6 ~ Claude Opus 4.8과 Claude Sonnet 4.6에서는 thinking 파라미터를 생략하면 thinking이 꺼집니다. Claude Opus 5와 Claude Sonnet 5에서는 thinking 파라미터를 생략하면 thinking이 기본으로 켜집니다. Claude Opus 5에서는 effort high 이하에서만 끌 수 있습니다. Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5에서는 thinking 파라미터를 설정하든 말든 thinking이 항상 켜져 있습니다.

  • 일반 지시를 처방적 단계보다 선호하세요. "think thoroughly" 같은 프롬프트가 손으로 쓴 단계별 계획보다 더 나은 추론을 만들어내는 경우가 많습니다. Claude의 추론은 인간이 처방하는 내용을 자주 능가합니다.
  • Multishot 예시는 thinking과 함께 동작합니다. few-shot 예시 안에 <thinking> 태그를 사용해 추론 패턴을 보여주세요. 그러면 모델이 그 스타일을 자기 extended thinking 블록에 일반화합니다.
  • 수동 chain-of-thought(CoT) 프롬프팅을 대안으로. thinking이 꺼져 있을 때도 문제를 단계적으로 생각하라고 요청해 단계별 추론을 장려할 수 있습니다. <thinking>과 <answer> 같은 구조화된 태그로 추론과 최종 출력을 깔끔하게 분리하세요. Claude Opus 5에서는 thinking을 끈 채 더 낮은 effort 레벨로 유지하는 것을 선호합니다: thinking이 꺼지면 모델이 가끔 내부 XML 태그를 보이는 출력에 새어 나오게 할 수 있으므로, Running with thinking disabled를 참고하고 나서 이 패턴을 적용하세요.
  • 셀프 체크를 요청하세요. "Before you finish, verify your answer against [test criteria]." 같은 문장을 덧붙이세요. 특히 코딩과 수학에서 오류를 확실히 잡아냅니다. Claude Opus 5는 예외입니다. 명시적 지시 없이도 스스로 잘 검증하며, 이전 모델용으로 조정된 프롬프트에서 넘어온 검증 지시는 오버-버리피케이션(과도한 검증)을 유발해 토큰과 지연을 늘릴 수 있습니다. Claude Opus 5로 마이그레이션할 때는 이런 지시를 다시 쓰지 말고 제거하세요(Task scope and over-verification 참고).

참고: extended thinking이 꺼져 있을 때, Claude Opus 4.5는 "think"라는 단어와 그 변형에 특히 민감합니다. 그런 경우 "consider", "evaluate", "reason through" 같은 대안을 사용하는 것을 고려하세요.

thinking 기능에 대한 더 자세한 내용은 Thinking과 Steering thinking을 참고하세요.

에이전트 시스템

장기 추론과 상태 추적

Claude의 최신 모델은 강력한 상태 추적으로 장기 추론 작업을 처리합니다. Claude는 한 번에 여러 가지를 시도하기보다 몇 가지에 꾸준히 작은 진전을 이루며 점진적으로 나아가는 데 집중해, 긴 세션에서 방향을 유지합니다. 이 능력은 특히 여러 컨텍스트 윈도우나 작업 반복에 걸쳐 두드러지며, Claude가 복잡한 작업을 수행하고 상태를 저장한 뒤 새로운 컨텍스트 윈도우로 이어갈 수 있습니다.

컨텍스트 인식과 멀티윈도우 워크플로

Claude Sonnet 5, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Haiku 4.5는 컨텍스트 인식 기능을 갖추어, 대화 내내 남은 컨텍스트 윈도우(즉 "토큰 예산")를 추적할 수 있습니다. 이를 통해 Claude는 작업에 사용할 공간이 얼마나 남았는지 이해하고 작업과 컨텍스트를 더 효과적으로 관리할 수 있습니다.

컨텍스트 제한 관리:

Claude Code처럼 컨텍스트를 압축하거나 외부 파일에 저장하도록 하는 에이전트 하네스에서 Claude를 쓰고 있다면, 이 정보를 프롬프트에 추가해 Claude가 그에 맞게 행동하도록 고려하세요. 그렇지 않으면 Claude가 컨텍스트 한계에 가까워지며 자연스럽게 작업을 마무리하려 할 수 있습니다. 다음은 예시 프롬프트입니다:

샘플 프롬프트

Your context window will be automatically compacted as it approaches its limit, allowing
you to continue working indefinitely from where you left off. Therefore, do not stop
tasks early due to token budget concerns. As you approach your token budget limit, save
your current progress and state to memory before the context window refreshes. Always be
as persistent and autonomous as possible and complete tasks fully, even if the end of
your budget is approaching. Never artificially stop any task early regardless of the
context remaining.

메모리 툴은 컨텍스트 전환을 관리할 때 컨텍스트 인식과 잘 어울립니다.

여러 컨텍스트 윈도우에 걸친 워크플로

여러 컨텍스트 윈도우에 걸친 작업에는:

  • 첫 번째 컨텍스트 윈도우에는 다른 프롬프트를 사용: 첫 컨텍스트 윈도우로 프레임워크를 구축(테스트 작성, 셋업 스크립트 생성)한 뒤, 이후 윈도우들에서는 todo-리스트를 반복 진행하세요.
  • 모델이 구조화된 형식으로 테스트를 쓰게 하기: 작업을 시작하기 전에 Claude가 테스트를 만들고 구조화된 형식(예: tests.json)으로 추적하게 하세요. 이는 장기적으로 반복 능력을 향상시킵니다. 테스트의 중요성을 상기시키세요: "It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality."
  • 품질 향상 도구 설정: Claude가 셋업 스크립트(예: init.sh)를 만들어 서버 시작, 테스트 스위트, 린터를 우아하게 실행하게 장려하세요. 새 컨텍스트 윈도우에서 이어갈 때 반복 작업을 막아줍니다.
  • 새로 시작 vs 압축: 컨텍스트 윈도우가 비워질 때 압축(compaction)보다 완전히 새로운 컨텍스트 윈도우로 시작하는 것을 고려하세요. Claude의 최신 모델은 로컬 파일시스템에서 상태를 발견하는 데 매우 뛰어납니다. 어떤 경우 압축보다 이를 활용하는 것이 좋습니다. 시작 방식을 명시적으로 지정하세요:
    • "Call pwd; you can only read and write files in this directory."
    • "Review progress.txt, tests.json, and the git logs."
    • "Manually run through a fundamental integration test before moving on to implementing new features."
  • 검증 도구 제공: 자율 작업의 길이가 길어질수록 Claude는 지속적인 인간 피드백 없이도 정확성을 검증해야 합니다. computer use 툴, browser use 툴, 브라우저 자동화 MCP 서버처럼 UI 작업을 검증하게 해주는 툴이 유용합니다.
  • 컨텍스트의 완전한 사용 장려: 진행하기 전에 컴포넌트를 효율적으로 완료하도록 프롬프트하세요:

샘플 프롬프트

This is a very long task, so it may be beneficial to plan out your work clearly. It's
encouraged to spend your entire output context working on the task - just make sure you
don't run out of context with significant uncommitted work. Continue working
systematically until you have completed this task.

상태 관리 모범 사례

  • 상태 데이터에는 구조화된 형식 사용: 테스트 결과나 작업 상태 같은 구조화된 정보를 추적할 때는 JSON이나 다른 구조화된 형식을 사용해 Claude가 스키마 요구사항을 이해하게 하세요.
  • 진행 메모에는 비구조화 텍스트 사용: 자유 형식 진행 메모는 일반 진행 상황과 컨텍스트를 추적하는 데 잘 작동합니다.
  • 상태 추적에 git 사용: Git은 무엇이 완료되었는지의 로그와 복원 가능한 체크포인트를 제공합니다. Claude의 최신 모델은 여러 세션에 걸쳐 상태를 추적하는 데 git을 특히 잘 사용합니다.
  • 점진적 진전 강조: Claude에게 진행 상황을 추적하고 점진적 작업에 집중하라고 명시적으로 요청하세요.

자율성과 안전의 균형

지침이 없으면 Claude Opus 4.6은 파일 삭제, force-push, 외부 서비스 게시처럼 되돌리기 어렵거나 공유 시스템에 영향을 주는 행동을 할 수 있습니다. 잠재적으로 위험한 행동 전에 확인을 받길 원한다면 프롬프트에 안내를 추가하세요:

샘플 프롬프트

Consider the reversibility and potential impact of your actions. You are encouraged to
take local, reversible actions like editing files or running tests, but for actions that
are hard to reverse, affect shared systems, or could be destructive, ask the user before
proceeding.

확인이 필요한 행동의 예:

  • 파괴적 작업: 파일이나 브랜치 삭제, 데이터베이스 테이블 drop, rm -rf
  • 되돌리기 어려운 작업: git push --force, git reset --hard, 게시된 커밋 amend
  • 다른 사람에게 보이는 작업: 코드 푸시, PR/이슈에 댓글 달기, 메시지 보내기, 공유 인프라 수정

장애물이 생겼을 때 파괴적 행동을 지름길로 사용하지 마세요. 예를 들어 안전 검사 우회(예: --no-verify)나 진행 중인 작업일 수 있는 익숙하지 않은 파일을 버리는 것을 하지 마세요.

연구와 정보 수집

Claude의 최신 모델은 여러 소스에서 정보를 찾고 종합하는 데 효과적입니다. 최적의 연구 결과를 위해:

  • 명확한 성공 기준 제시: 연구 질문에 대한 성공적인 답이 무엇인지 정의하세요.
  • 소스 검증 장려: 여러 소스에 걸쳐 정보를 검증하라고 요청하세요.

복잡한 연구 작업에는 구조화된 접근을 사용하세요:

복잡한 연구용 샘플 프롬프트

Search for this information in a structured way. As you gather data, develop several
competing hypotheses. Track your confidence levels in your progress notes to improve
calibration. Regularly self-critique your approach and plan. Update a hypothesis tree or
research notes file to persist information and provide transparency. Break down this
complex research task systematically.

이 구조화된 접근은 Claude가 큰 말뭉치를 체계적이고 반복적으로 처리하고, 자체 발견을 비판적으로 검토하도록 돕습니다.

서브에이전트 오케스트레이션

Claude의 최신 모델은 서브에이전트를 네이티브로 오케스트레이션합니다. 이 모델들은 작업을 전문 서브에이전트에 위임하는 것이 유리한 경우를 인식하고, 명시적 지시 없이도 적극적으로 그렇게 합니다.

이 동작을 활용하려면:

  • 잘 정의된 서브에이전트 툴 확보: 서브에이전트 툴이 툴 정의에 존재하고 설명되어 있어야 합니다.
  • Claude가 자연스럽게 오케스트레이션하게 두기: 명시적 지시 없이도 Claude는 적절히 위임합니다.
  • 과도한 사용 주시: Claude Opus 4.6은 서브에이전트에 강한 성향이 있어, 더 단순하고 직접적인 접근이면 충분한 상황에서도 서브에이전트를 생성할 수 있습니다. 예를 들어 직접 grep 호출이 더 빠르고 충분한 코드 탐색에서도 서브에이전트를 만들 수 있습니다. Claude Opus 5도 이전 모델보다 더 쉽게 서브에이전트에 위임합니다(제어 안내와 샘플 감쇠 프롬프트는 Controlling subagent spawning 참고).

과도한 서브에이전트 사용이 보인다면, 서브에이전트가 언제 적절하고 적절하지 않은지 명시적인 안내를 추가하세요:

서브에이전트 사용용 샘플 프롬프트

Use subagents when tasks can run in parallel, require isolated context, or involve
independent workstreams that don't need to share state. For simple tasks, sequential
operations, single-file edits, or tasks where you need to maintain context across steps,
work directly rather than delegating.

복잡한 프롬프트 연결(Chaining)

adaptive thinking과 서브에이전트 오케스트레이션으로 Claude는 대부분의 다단계 추론을 내부적으로 처리합니다. 중간 출력을 검사하거나 특정 파이프라인 구조를 강제해야 할 때는 명시적 프롬프트 체이닝(작업을 순차 API 호출로 분해)이 여전히 유용합니다.

가장 흔한 체이닝 패턴은 자기 수정입니다: 초안 생성 → 기준에 맞춰 Claude가 검토 → 검토를 바탕으로 Claude가 다듬기. 각 단계는 별도의 API 호출이므로 언제든지 로그 기록, 평가, 분기할 수 있습니다.

에이전트 코딩에서 파일 생성 줄이기

Claude의 최신 모델은 특히 코드 작업 시 테스트·반복 목적으로 새 파일을 만들 때가 있습니다. 이 접근으로 Claude는 최종 출력을 저장하기 전에 파일(특히 Python 스크립트)을 "임시 스크래치패드"로 사용할 수 있습니다. 임시 파일 사용은 특히 에이전트 코딩 사용 사례에서 결과를 개선할 수 있습니다.

순신규 파일 생성을 최소화하고 싶다면 Claude에게 정리하라고 지시할 수 있습니다:

샘플 프롬프트

If you create any temporary new files, scripts, or helper files for iteration, clean up
these files by removing them at the end of the task.

과잉(overeagerness)

Claude Opus 4.5와 Claude Opus 4.6은 요청되지 않은 파일을 생성하거나, 불필요한 추상화를 추가하거나, 요청되지 않은 유연성을 구축하는 식으로 과도하게 엔지니어링하는 경향이 있습니다. 이런 원치 않는 동작이 보이면 솔루션을 최소로 유지하라는 구체적인 안내를 추가하세요.

예를 들어:

과도한 엔지니어링 최소화용 샘플 프롬프트

Avoid over-engineering. Only make changes that are directly requested or clearly
necessary. Keep solutions simple and focused:

- Scope: Don't add features, refactor code, or make "improvements" beyond what was
asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need
extra configurability.

- Documentation: Don't add docstrings, comments, or type annotations to code you didn't
change. Only add comments where the logic isn't self-evident.

- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios
that can't happen. Trust internal code and framework guarantees. Only validate at system
boundaries (user input, external APIs).

- Abstractions: Don't create helpers, utilities, or abstractions for one-time
operations. Don't design for hypothetical future requirements. The right amount of
complexity is the minimum needed for the current task.

테스트 통과와 하드코딩에 집중하는 것 피하기

Claude는 때때로 더 일반적인 솔루션을 희생하고 테스트를 통과시키는 데 너무 집중하거나, 표준 툴을 직접 쓰는 대신 복잡한 리팩터링에 헬퍼 스크립트 같은 우회 방법을 사용할 수 있습니다. 이런 동작을 막고 일반화되는 솔루션을 얻으려면:

샘플 프롬프트

Please write a high-quality, general-purpose solution using the standard tools
available. Do not create helper scripts or workarounds to accomplish the task more
efficiently. Implement a solution that works correctly for all valid inputs, not just
the test cases. Do not hard-code values or create solutions that only work for specific
test inputs. Instead, implement the actual logic that solves the problem generally.

Focus on understanding the problem requirements and implementing the correct algorithm.
Tests are there to verify correctness, not to define the solution. Provide a principled
implementation that follows best practices and software design principles.

If the task is unreasonable or infeasible, or if any of the tests are incorrect, please
inform me rather than working around them. The solution should be robust, maintainable,
and extendable.

에이전트 코딩에서 환각 최소화

Claude의 최신 모델은 환각에 덜 취약하고, 코드를 바탕으로 더 정확하고 근거 있고 지능적인 답을 냅니다. 이 동작을 더 장려하고 환각을 최소화하려면:

샘플 프롬프트

<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file,
you MUST read the file before answering. Make sure to investigate and read relevant
files BEFORE answering questions about the codebase. Never make any claims about code
before investigating unless you are certain of the correct answer - give grounded and
hallucination-free answers.
</investigate_before_answering>

기능별 팁

개선된 비전 능력

Claude Opus 4.5와 Claude Opus 4.6은 이전 Claude 모델보다 개선된 비전 능력을 갖습니다. 특히 컨텍스트에 이미지가 여러 개 있을 때 이미지 처리와 데이터 추출 작업에 더 뛰어납니다. 이러한 개선은 computer use에도 이어져, 모델이 스크린샷과 UI 요소를 더 확실히 해석할 수 있습니다. 또한 이 모델들로 비디오를 프레임으로 분해해 분석할 수 있습니다.

성능을 더 끌어올리는 데 효과가 입증된 기법 하나는 Claude에게 크롭 툴이나 에이전트 스킬을 주는 것입니다. 테스트에서 Claude가 이미지의 관련 영역을 "확대(zoom)"할 수 있을 때 이미지 평가에서 일관된 향상이 있었습니다. Anthropic은 크롭 툴 레시피를 만들었습니다.

프론트엔드 디자인

Claude Opus 4.5와 Claude Opus 4.6은 강력한 프론트엔드 디자인으로 복잡하고 실제적인 웹 애플리케이션을 구축합니다. 하지만 안내가 없으면 모델이 사용자들이 "AI 슬롭" 미학이라 부르는 일반적인 패턴으로 기본 설정되는 경우가 있습니다. 차별화되고 창의적이어서 놀라움과 즐거움을 주는 프론트엔드를 만들려면:

프론트엔드 디자인 개선에 대한 상세 가이드는 skills를 통한 프론트엔드 디자인 개선 블로그 글을 참고하세요.

API 밖에서의 프론트엔드 디자인 작업에는, Claude Design이 Claude가 상호작용적으로 디자인을 생성·반복할 수 있는 캔버스와 디자인 툴을 제공합니다.

더 나은 프론트엔드 디자인을 장려하는 데 쓸 수 있는 시스템 프롬프트 스니펫:

프론트엔드 미학용 샘플 프롬프트

<frontend_aesthetics>
You tend to converge toward generic, "on distribution" outputs. In frontend design, this
creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive
frontends that surprise and delight.

Focus on:
- Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic
fonts like Arial and Inter; opt instead for distinctive choices that elevate the
frontend's aesthetics.
- Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency.
Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw
from IDE themes and cultural aesthetics for inspiration.
- Motion: Use animations for effects and micro-interactions. Prioritize CSS-only
solutions for HTML. Use Motion library for React when available. Focus on high-impact
moments: one well-orchestrated page load with staggered reveals (animation-delay)
creates more delight than scattered micro-interactions.
- Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer
CSS gradients, use geometric patterns, or add contextual effects that match the overall
aesthetic.

Avoid generic AI-generated aesthetics:
- Overused font families (Inter, Roboto, Arial, system fonts)
- Clichéd color schemes (particularly purple gradients on white backgrounds)
- Predictable layouts and component patterns
- Cookie-cutter design that lacks context-specific character

Interpret creatively and make unexpected choices that feel genuinely designed for the
context. Vary between light and dark themes, different fonts, different aesthetics. You
still tend to converge on common choices (Space Grotesk, for example) across
generations. Avoid this: it is critical that you think outside the box!
</frontend_aesthetics>

전체 스킬 정의도 참고할 수 있습니다.

마이그레이션 고려사항

이전 세대에서 현재 Claude 모델로 마이그레이션할 때:

  • 원하는 동작을 구체적으로 명시: 출력에서 보고 싶은 것을 정확히 설명하는 것을 고려하세요.
  • 한정어로 지시를 구성: Claude가 출력의 품질과 디테일을 높이도록 장려하는 한정어를 추가하면 성능을 더 잘 다듬을 수 있습니다. 예를 들어 "Create an analytics dashboard" 대신 "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation."를 사용하세요.
  • 특정 기능을 명시적으로 요청: 애니메이션과 인터랙티브 요소는 원할 때 명시적으로 요청해야 합니다.
  • thinking 구성 업데이트: Claude 4.6 모델은 budget_tokens을 쓰는 수동 thinking 대신 adaptive thinking(thinking: {type: "adaptive"})을 사용합니다. thinking 깊이를 제어하려면 effort 파라미터를 사용하세요.
  • 프리필드 응답에서 마이그레이션: 마지막 어시스턴트 턴의 프리필드 응답은 Claude 4.6 모델과 Claude Mythos Preview부터 더 이상 지원되지 않습니다. 대안에 대한 자세한 안내는 Migrating away from prefilled responses를 참고하세요.
  • 반(反)나태(anti-laziness) 프롬프팅 조정: 프롬프트가 이전에 모델을 더 철저하게 하거나 툴을 더 공격적으로 쓰도록 장려했다면 그 안내를 완화하세요. Claude 4.6 모델은 더 적극적이며, 이전 모델에 필요했던 지시에 오버트리거할 수 있습니다.
  • thinking 블록을 그대로 되돌려 보내고 히스토리를 append-only로 유지: 각 어시스턴트 턴을 API가 반환한 그대로, thinking 블록을 포함해 정확히 추가하세요. Claude Fable 5.1에서 thinking 블록 이전 대화를 수정하면 에러가 발생하거나(선택 시 블록이 버려질 수 있음): 이전 메시지 편집, 시스템·툴 재구성, 요청 사이 기존 턴을 제자리에서 요약하는 것은 이후 모든 thinking 블록을 무효화합니다. 그런 변경은 대화 중간 시스템 메시지와 서버 측 컨텍스트 관리로 옮기세요(Keep the conversation history append-only 참고).

자세한 마이그레이션 절차는 Migration guide를 참고하세요.

Claude Sonnet 4.5 이하에서 Claude Sonnet 5로 마이그레이션

마이그레이션 가이드의 Migrating to Claude Sonnet 5 from Claude Sonnet 4.5 or earlier를 참고하세요. effort 기본값 변경과 수동 extended thinking(budget_tokens) 제거를 다룹니다.

다음 단계

  • Prompting Claude Fable 5.1 — effort, 작업 완료, 진행 업데이트, thinking 블록, 툴 호출 배칭, 글쓰기 스타일을 다루는 Claude Fable 5.1의 행동 차이와 프롬프팅 패턴.
  • Prompting Claude Fable 5 — effort, 지시 따르기, 장기 실행, 메모리, 스캐폴딩 변경을 다루는 Claude Fable 5와 Claude Mythos 5의 행동 차이와 프롬프팅 패턴.
  • Prompting Claude Sonnet 5 — effort, adaptive thinking 기본값, 툴 사용, Claude Sonnet 4.6에서의 마이그레이션을 다루는 Claude Sonnet 5의 행동 차이와 프롬프팅 패턴.
  • Prompting Claude Opus 5 — 응답 장황함, 에이전트 내레이션, 작업 범위 지정, 서브에이전트 위임, 자기 수정을 다루는 Claude Opus 5의 행동 차이와 프롬프팅 패턴.
  • Prompt engineering overview — 프롬프트 엔지니어링을 언제 사용하고, 프롬프트를 조정하기 전에 접근을 어떻게 계획할지.