프롬프팅 모범 사례

이 문서는 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를 포함한 현재 Claude 모델을 대상으로 한 프롬프트 엔지니어링 레퍼런스입니다. 이 페이지는 세 부분으로 구성되어 있습니다:

• **모델별 가이드**가 먼저 나옵니다: 특정 모델이 다르게 동작하는 부분과 프롬프트에서 무엇을 변경해야 하는지 설명합니다.
• 그다음은 모든 현재 모델에 적용되는 기법입니다: 일반 원칙, 출력 및 서식, 도구 사용, 사고, 에이전트 시스템을 다룹니다.
• 마지막은 이전 세대에서 옮겨오는 프롬프트를 위한 마이그레이션 고려 사항입니다.

모델별 가이드

이 모델들은 각각 자체 프롬프팅 페이지가 있습니다. 먼저 사용 중인 모델의 페이지를 읽은 다음, 이어지는 기법들을 읽으세요.

일반 원칙

이 섹션과 이어지는 섹션의 기법들은 Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5를 포함한 현재 Claude 모델에 적용됩니다. 기법에서 특정 모델을 명시하는 경우, 해당 모델에서 측정된 것으로 간주하고 다른 모델에 적용하기 전에 자체 평가로 다시 확인하세요.

명확하고 직접적으로 작성하기

Claude는 명확하고 명시적인 지시에 잘 반응합니다. 원하는 출력에 대해 구체적으로 설명하면 결과를 향상시키는 데 도움이 될 수 있습니다. "기대 이상"의 동작을 원한다면, 모호한 프롬프트에서 모델이 이를 추론하도록 기대하기보다 명시적으로 요청하세요.

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에게 설명하는 것은 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" 프롬프팅이라고 함)는 정확성과 일관성을 향상시킵니다.

예시를 추가할 때는 다음과 같이 만드세요:

• 관련성: 실제 사용 사례를 밀접하게 반영하세요.
• 다양성: 엣지 케이스를 다루고, Claude가 의도하지 않은 패턴을 학습하지 않도록 충분히 다양하게 만드세요.
• 구조화: Claude가 예시를 지시와 구분할 수 있도록 예시를 <example> 태그로 감싸세요(여러 예시는 <examples> 태그로).

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+ 토큰)으로 작업할 때는 최상의 결과를 얻기 위해 프롬프트를 신중하게 구조화하세요:

• 긴 형식의 데이터를 상단에 배치하세요: 긴 문서와 입력을 쿼리, 지시, 예시보다 위쪽인 프롬프트 상단 근처에 배치하세요. 이는 모든 모델에서 성능을 향상시킵니다.

• XML 태그로 문서 콘텐츠와 메타데이터를 구조화하세요: 여러 문서를 사용할 때는 명확성을 위해 각 문서를 <document> 태그로 감싸고 <document_content> 및 <source>(및 기타 메타데이터) 하위 태그를 사용하세요.

  다중 문서 구조 예시

• 인용문에 기반하여 응답하세요: 긴 문서 작업의 경우, Claude에게 작업을 수행하기 전에 먼저 문서의 관련 부분을 인용하도록 요청하세요. 이는 Claude가 관련 콘텐츠에 집중하고 문서의 나머지 부분을 무시하는 데 도움이 됩니다.

  인용문 추출 예시

모델 자기 인식

애플리케이션에서 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를 높이거나 낮춰도 눈에 보이는 응답 길이가 안정적으로 변하지 않습니다. 대신 간결함을 명시적으로 프롬프트하세요. 샘플 지시는 Claude Opus 5 프롬프팅을 참조하세요. Claude Fable 5.1은 에이전트 작업 중 반대 경향을 보입니다: 도구 호출 사이에 사용자 대상 업데이트를 더 적게 작성합니다. 진행 상황 텍스트를 명시적으로 요청하고, 해당 텍스트를 짧게 유지하라는 지시는 모두 제거하세요. 사용자 대상 진행 상황 업데이트 요청하기를 참조하세요.

응답 형식 제어하기

출력 서식을 조정하는 데 특히 효과적인 몇 가지 방법이 있습니다:

1. 하지 말아야 할 것 대신 해야 할 것을 Claude에게 알려주세요

   • 이렇게 하는 대신: "응답에 마크다운을 사용하지 마세요"
   • 이렇게 해보세요: "응답은 매끄럽게 흐르는 산문 단락으로 구성되어야 합니다."

2. XML 형식 지시자를 사용하세요

   • 이렇게 해보세요: "응답의 산문 섹션을 <smoothly_flowing_prose_paragraphs> 태그 안에 작성하세요."

3. 프롬프트 스타일을 원하는 출력에 맞추세요

   프롬프트에 사용된 서식 스타일이 Claude의 응답 스타일에 영향을 줄 수 있습니다. 출력 서식의 조정 가능성에 여전히 문제가 있다면, 프롬프트 스타일을 원하는 출력 스타일에 최대한 가깝게 맞춰보세요. 예를 들어, 프롬프트에서 마크다운을 제거하면 출력의 마크다운 양을 줄일 수 있습니다.

4. 특정 서식 선호 사항에 대해 상세한 프롬프트를 사용하세요

   마크다운 및 서식 사용을 더 세밀하게 제어하려면 명시적인 가이드를 제공하세요:

<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>

Claude Fable 5.1은 이미 이전 모델보다 서식을 덜 사용하므로, 해당 모델에서는 이와 같은 블록이 콘텐츠에 필요한 구조를 억제할 수 있습니다. 이를 제거하거나 채팅에서의 서식의 더 짧은 규칙으로 대체하세요.

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).

문서 생성

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 오류가 반환됩니다. 모델 지능과 지시 따르기 능력이 발전하여 대부분의 프리필 사용 사례에서 더 이상 프리필이 필요하지 않습니다. 이전 모델은 계속 프리필을 지원하며, 대화의 다른 위치에 어시스턴트 메시지를 추가하는 것은 영향을 받지 않습니다.

다음은 일반적인 프리필 시나리오와 이로부터 마이그레이션하는 방법입니다:

도구 사용

도구 사용법

Claude의 최신 모델은 정확한 지시 따르기를 위해 학습되었으며, 특정 도구를 사용하라는 명시적인 지시로부터 이점을 얻습니다. "몇 가지 변경 사항을 제안해 줄 수 있나요"라고 말하면, 변경을 하는 것이 여러분의 의도였더라도 Claude는 때때로 구현하는 대신 제안만 제공합니다. 도구를 정의하고 도구 트리거 문제를 해결하는 방법을 알아보려면 Claude와 함께하는 도구 사용을 참조하세요.

Claude가 행동을 취하게 하려면 더 명시적으로 작성하세요:

Can you suggest some changes to improve this function?

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.

긴 에이전트 루프에서 Claude Fable 5.1을 사용할 때는 각 도구 결과 라운드 후에 병렬 호출 지시를 턴 범위의 시스템 메시지로 보내세요. 에이전트 루프에서 독립적인 도구 호출 일괄 처리하기를 참조하세요.

사고와 추론

과도한 사고와 지나친 철저함

Claude Opus 4.6은 특히 높은 effort 설정에서 이전 모델보다 더 많은 사전 탐색을 수행합니다. 이 초기 작업은 종종 최종 결과를 최적화하는 데 도움이 되지만, 모델이 프롬프트 없이도 광범위한 컨텍스트를 수집하거나 여러 리서치 갈래를 추구할 수 있습니다. 이전에 프롬프트에서 모델이 더 철저하도록 권장했다면, Claude Opus 4.6에 맞게 해당 가이드를 조정해야 합니다:

• 포괄적인 기본값을 더 목표 지향적인 지시로 대체하세요. "기본적으로 [tool]을 사용하세요" 대신 "문제에 대한 이해를 높일 수 있을 때 [tool]을 사용하세요"와 같은 가이드를 추가하세요.
• 과도한 프롬프팅을 제거하세요. 이전 모델에서 과소 트리거되던 도구는 이제 적절하게 트리거될 가능성이 높습니다. "확실하지 않으면 [tool]을 사용하세요"와 같은 지시는 과다 트리거를 유발합니다.
• effort를 대안으로 사용하세요. Claude가 계속 지나치게 적극적이라면 effort에 더 낮은 설정을 사용하세요.

경우에 따라 Claude Opus 4.6은 광범위하게 사고할 수 있으며, 이는 사고 토큰을 부풀리고 응답을 느리게 할 수 있습니다. 이 동작이 바람직하지 않다면, 추론을 제약하는 명시적인 지시를 추가하거나 effort 설정을 낮춰 전체 사고 및 토큰 사용량을 줄일 수 있습니다.

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 상한을 사용한 확장 사고는 Opus 4.6과 Sonnet 4.6에서 여전히 작동하지만 지원 중단되었습니다. Claude 4.7 및 이후 모델에서는 budget_tokens를 설정하면 400 오류가 반환됩니다. effort 설정을 낮추거나 적응형 사고와 함께 max_tokens를 엄격한 한도로 사용하는 것을 권장합니다.

사고 및 인터리브 사고 기능 활용하기

Claude의 최신 모델은 도구 사용 후 성찰이나 복잡한 다단계 추론이 필요한 작업에 특히 도움이 될 수 있는 사고 기능을 제공합니다. 더 나은 결과를 위해 초기 사고 또는 인터리브 사고를 안내할 수 있습니다.

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

다단계 도구 사용, 복잡한 코딩 작업, 장기 에이전트 루프와 같은 에이전트 동작이 필요한 워크로드에는 적응형 사고를 사용하세요. 이전 모델은 budget_tokens를 사용한 수동 확장 사고를 사용합니다. 각 모델이 어떤 구성을 허용하는지는 모델별 구성 표를 참조하세요.

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

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.

적응형 사고의 트리거 동작은 프롬프트로 조정 가능합니다. 크거나 복잡한 시스템 프롬프트에서 발생할 수 있듯이 모델이 원하는 것보다 더 자주 사고한다면, 이를 조정하는 가이드를 추가하세요:

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를 사용한 확장 사고에서 마이그레이션하는 경우, 사고 구성을 교체하고 예산 제어를 effort로 옮기세요. 다음 예시는 마이그레이션 전후의 동일한 요청을 보여줍니다(사용 가능한 수준과 모델별 가용성은 effort를 참조하세요):

# 이전: 수동 예산을 사용한 확장 사고 (이전 모델)
client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[{"role": "user", "content": "..."}],
)

# 이후: effort를 사용한 적응형 사고
client.messages.create(
    model="claude-opus-4-8",
    max_tokens=16000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

확장 사고를 사용하지 않는다면 변경이 필요하지 않습니다. Claude Opus 4.6부터 Claude Opus 4.8까지와 Claude Sonnet 4.6에서는 thinking 파라미터를 생략하면 사고가 꺼집니다. Claude Opus 5와 Claude Sonnet 5에서는 thinking 파라미터를 생략하면 기본적으로 사고가 켜집니다. Claude Opus 5에서는 effort high 이하에서만 사고를 비활성화할 수 있습니다. Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5에서는 thinking 파라미터 설정 여부와 관계없이 사고가 항상 켜져 있습니다.

• 규범적인 단계보다 일반적인 지시를 선호하세요. "철저하게 생각하세요"와 같은 프롬프트는 종종 손으로 작성한 단계별 계획보다 더 나은 추론을 만들어냅니다. Claude의 추론은 사람이 규정하는 것을 자주 능가합니다.
• 멀티샷 예시는 사고와 함께 작동합니다. few-shot 예시 안에 <thinking> 태그를 사용하여 Claude에게 추론 패턴을 보여주세요. Claude는 그 스타일을 자체 확장 사고 블록으로 일반화합니다.
• 대안으로서의 수동 "chain-of-thought"(사고의 연쇄), 즉 CoT 프롬프팅. 사고가 꺼져 있을 때도 Claude에게 문제를 차근차근 생각해 보라고 요청하여 단계별 추론을 권장할 수 있습니다. <thinking> 및 <answer>와 같은 구조화된 태그를 사용하여 추론과 최종 출력을 깔끔하게 분리하세요. Claude Opus 5에서는 대신 더 낮은 effort 수준에서 사고를 활성화된 상태로 유지하는 것을 권장합니다. 사고가 비활성화되면 모델이 가끔 내부 XML 태그를 눈에 보이는 출력으로 내보낼 수 있으므로, 해당 모델에 이 패턴을 적용하기 전에 사고 비활성화 상태로 실행하기를 참조하세요.
• Claude에게 자체 점검을 요청하세요. "마치기 전에 [테스트 기준]에 대해 답변을 검증하세요"와 같은 문구를 덧붙이세요. 이는 특히 코딩과 수학에서 오류를 안정적으로 잡아냅니다. Claude Opus 5는 예외입니다: 명시적인 지시 없이도 자신의 작업을 잘 검증하며, 이전 모델에 맞춰 조정된 프롬프트에서 가져온 검증 지시는 과도한 검증을 유발하여 토큰과 지연 시간을 늘릴 수 있습니다. Claude Opus 5로 마이그레이션할 때는 이러한 지시를 다시 작성하기보다 제거하세요. 작업 범위 및 과도한 검증을 참조하세요.

에이전트 시스템

장기 추론 및 상태 추적

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.

메모리 도구는 컨텍스트 전환 관리를 위해 컨텍스트 인식과 잘 어울립니다.

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

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

1. 맨 처음 컨텍스트 윈도우에는 다른 프롬프트를 사용하세요: 첫 번째 컨텍스트 윈도우를 사용하여 프레임워크를 설정하고(테스트 작성, 설정 스크립트 생성), 이후 컨텍스트 윈도우를 사용하여 할 일 목록을 반복하세요.

2. 모델이 구조화된 형식으로 테스트를 작성하게 하세요: Claude에게 작업을 시작하기 전에 테스트를 만들고 구조화된 형식(예: tests.json)으로 추적하도록 요청하세요. 이는 장기적으로 더 나은 반복 능력으로 이어집니다. Claude에게 테스트의 중요성을 상기시키세요: "테스트를 제거하거나 편집하는 것은 누락되거나 버그가 있는 기능으로 이어질 수 있으므로 용납되지 않습니다."

3. 편의 도구를 설정하세요: Claude가 서버를 원활하게 시작하고, 테스트 스위트와 린터를 실행하는 설정 스크립트(예: init.sh)를 만들도록 권장하세요. 이는 새로운 컨텍스트 윈도우에서 계속할 때 반복 작업을 방지합니다.

4. 새로 시작하기 대 압축하기: 컨텍스트 윈도우가 지워질 때, 압축을 사용하기보다 완전히 새로운 컨텍스트 윈도우로 시작하는 것을 고려하세요. Claude의 최신 모델은 로컬 파일 시스템에서 상태를 발견하는 데 매우 효과적입니다. 경우에 따라 압축보다 이를 활용하고 싶을 수 있습니다. 어떻게 시작해야 하는지 규범적으로 지시하세요:

   • "pwd를 호출하세요. 이 디렉터리에서만 파일을 읽고 쓸 수 있습니다."
   • "progress.txt, tests.json, git 로그를 검토하세요."
   • "새로운 기능 구현으로 넘어가기 전에 기본적인 통합 테스트를 수동으로 실행하세요."

5. 검증 도구를 제공하세요: 자율 작업의 길이가 늘어남에 따라 Claude는 지속적인 사람의 피드백 없이 정확성을 검증해야 합니다. 컴퓨터 사용 도구, 브라우저 사용 도구 또는 브라우저 자동화 MCP 서버와 같이 Claude가 UI 작업을 검증할 수 있게 하는 도구가 도움이 됩니다.

6. 컨텍스트의 완전한 사용을 권장하세요: Claude가 넘어가기 전에 구성 요소를 효율적으로 완료하도록 프롬프트하세요:

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에게 진행 상황을 추적하고 점진적 작업에 집중하도록 명시적으로 요청하세요.

{
  "tests": [
    { "id": 1, "name": "authentication_flow", "status": "passing" },
    { "id": 2, "name": "user_management", "status": "failing" },
    { "id": 3, "name": "api_endpoints", "status": "not_started" }
  ],
  "total": 200,
  "passing": 150,
  "failing": 25,
  "not_started": 25
}

// Progress notes (progress.txt)
Session 3 progress:
- Fixed authentication token validation
- Updated user model to handle edge cases
- Next: investigate user_management test failures (test #2)
- Note: Do not remove tests as this could lead to missing functionality

자율성과 안전성의 균형

가이드가 없으면 Claude Opus 4.6은 파일 삭제, 강제 푸시, 외부 서비스에 게시하기와 같이 되돌리기 어렵거나 공유 시스템에 영향을 미치는 행동을 취할 수 있습니다. Claude Opus 4.6이 잠재적으로 위험한 행동을 취하기 전에 확인하도록 하려면 프롬프트에 가이드를 추가하세요:

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.

Examples of actions that warrant confirmation:
- Destructive operations: deleting files or branches, dropping database tables, rm -rf
- Hard to reverse operations: git push --force, git reset --hard, amending published commits
- Operations visible to others: pushing code, commenting on PRs/issues, sending
messages, modifying shared infrastructure

When encountering obstacles, do not use destructive actions as a shortcut. For example,
don't bypass safety checks (e.g. --no-verify) or discard unfamiliar files that may be
in-progress work.

리서치 및 정보 수집

Claude의 최신 모델은 여러 소스에서 정보를 효과적으로 찾고 종합할 수 있습니다. 최적의 리서치 결과를 위해:

1. 명확한 성공 기준을 제공하세요: 리서치 질문에 대한 성공적인 답변이 무엇인지 정의하세요.

2. 소스 검증을 권장하세요: Claude에게 여러 소스에 걸쳐 정보를 검증하도록 요청하세요.

3. 복잡한 리서치 작업에는 구조화된 접근 방식을 사용하세요:

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의 최신 모델은 서브에이전트를 기본적으로 오케스트레이션합니다. 이 모델들은 작업이 전문화된 서브에이전트에 위임함으로써 이점을 얻을 수 있는 경우를 인식하고, 명시적인 지시 없이도 적극적으로 그렇게 합니다.

이 동작을 활용하려면:

1. 잘 정의된 서브에이전트 도구를 확보하세요: 서브에이전트 도구를 사용 가능하게 하고 도구 정의에 설명하세요.
2. Claude가 자연스럽게 오케스트레이션하게 하세요: Claude는 명시적인 지시 없이도 적절하게 위임합니다.
3. 과도한 사용을 주의하세요: Claude Opus 4.6은 서브에이전트에 대한 강한 선호가 있으며, 더 간단하고 직접적인 접근 방식으로 충분한 상황에서도 서브에이전트를 생성할 수 있습니다. 예를 들어, 직접적인 grep 호출이 더 빠르고 충분한데도 모델이 코드 탐색을 위해 서브에이전트를 생성할 수 있습니다. Claude Opus 5도 이전 모델보다 더 쉽게 서브에이전트에 위임합니다. 가이드와 샘플 억제 프롬프트는 서브에이전트 생성 제어하기를 참조하세요.

과도한 서브에이전트 사용이 보인다면, 서브에이전트가 언제 정당하고 언제 그렇지 않은지에 대한 명시적인 가이드를 추가하세요:

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.

복잡한 프롬프트 체이닝

적응형 사고와 서브에이전트 오케스트레이션으로 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.

과도한 열의

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 모델에 비해 향상된 비전 기능을 갖추고 있습니다. 특히 컨텍스트에 여러 이미지가 있을 때 이미지 처리 및 데이터 추출 작업에서 더 나은 성능을 보입니다. 이러한 개선 사항은 컴퓨터 사용으로도 이어져, 모델이 스크린샷과 UI 요소를 더 안정적으로 해석할 수 있습니다. 또한 이 모델들을 사용하여 비디오를 프레임으로 나누어 분석할 수도 있습니다.

성능을 더욱 높이는 데 효과적인 것으로 입증된 한 가지 기법은 Claude에게 크롭 도구 또는 에이전트 스킬을 제공하는 것입니다. 테스트 결과, Claude가 이미지의 관련 영역을 "확대"할 수 있을 때 이미지 평가에서 일관된 향상이 나타났습니다. Anthropic은 크롭 도구 레시피를 만들었습니다.

프론트엔드 디자인

Claude Opus 4.5와 Claude Opus 4.6은 뛰어난 프론트엔드 디자인을 갖춘 복잡한 실제 웹 애플리케이션을 구축합니다. 그러나 지침이 없으면 모델은 사용자들이 "AI slop" 미학이라고 부르는 것을 만들어내는 일반적인 패턴을 기본값으로 사용할 수 있습니다. 놀라움과 즐거움을 주는 독창적이고 창의적인 프론트엔드를 만들려면 다음을 참고하세요.

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 모델로 마이그레이션할 때:

1. 원하는 동작을 구체적으로 명시하세요: 출력에서 보고 싶은 것을 정확히 설명하는 것을 고려하세요.

2. 수식어로 지침을 구성하세요: Claude가 출력의 품질과 세부 수준을 높이도록 유도하는 수식어를 추가하면 Claude의 성능을 더 잘 형성하는 데 도움이 될 수 있습니다. 예를 들어, "분석 대시보드를 만들어 줘" 대신 "분석 대시보드를 만들어 줘. 관련 기능과 상호작용을 가능한 한 많이 포함해 줘. 기본을 넘어 완전한 기능을 갖춘 구현을 만들어 줘."를 사용하세요.

3. 특정 기능을 명시적으로 요청하세요: 애니메이션과 대화형 요소는 원할 경우 명시적으로 요청해야 합니다.

4. 사고 구성을 업데이트하세요: Claude 4.6 모델은 budget_tokens를 사용하는 수동 사고 대신 adaptive thinking(적응형 사고)(thinking: {type: "adaptive"})을 사용합니다. 사고 깊이를 제어하려면 effort 파라미터를 사용하세요.

5. 미리 채워진 응답에서 마이그레이션하세요: 마지막 어시스턴트 턴의 미리 채워진 응답(prefilled responses)은 Claude 4.6 모델과 Claude Mythos Preview부터 더 이상 지원되지 않습니다. 대안에 대한 자세한 지침은 미리 채워진 응답에서 마이그레이션하기를 참조하세요.

6. 게으름 방지 프롬프팅을 조정하세요: 이전에 프롬프트에서 모델이 더 철저하게 작업하거나 도구를 더 적극적으로 사용하도록 유도했다면, 해당 지침을 완화하세요. Claude 4.6 모델은 더 능동적이며 이전 모델에 필요했던 지침에 과도하게 반응할 수 있습니다.

7. 사고 블록을 변경 없이 그대로 다시 전달하고 기록을 추가 전용(append-only)으로 유지하세요: 각 어시스턴트 턴을 사고 블록을 포함하여 API가 반환한 그대로 정확히 추가하세요. Claude Fable 5.1에서는 사고 블록 이전의 대화를 수정하면 오류가 발생하거나, 해당 옵션을 선택한 경우 블록이 삭제됩니다. 이전 메시지를 편집하거나, system 또는 tools를 재구성하거나, 요청 사이에 이전 턴을 제자리에서 요약하면 이후의 모든 사고 블록이 무효화되므로, 이러한 변경 사항은 대화 중간 시스템 메시지와 서버 측 컨텍스트 관리로 옮기세요. 대화 기록을 추가 전용으로 유지하기를 참조하세요.

자세한 마이그레이션 단계는 마이그레이션 가이드를 참조하세요.

Claude Sonnet 4.5 또는 이전 버전에서 Claude Sonnet 5로 마이그레이션하기

마이그레이션 가이드의 Claude Sonnet 4.5 또는 이전 버전에서 Claude Sonnet 5로 마이그레이션하기를 참조하세요. 여기에서는 effort 기본값 변경과 수동 확장 사고(budget_tokens)의 제거를 다룹니다.

다음 단계