프롬프트 작성 모범 사례

이 문서는 Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5를 포함한 Claude의 최신 모델을 위한 프롬프트 엔지니어링 참조 자료입니다. 이 페이지는 세 부분으로 구성되어 있습니다:

• 모델별 가이드가 먼저 나옵니다: Claude Fable 5와 Claude Opus 4.8이 다르게 동작하는 부분과 변경해야 할 사항을 다룹니다.
• 그다음 모든 현재 모델에 적용되는 기법: 일반 원칙, 출력 및 형식, 도구 사용, 사고, 에이전트 시스템을 다룹니다.
• 마지막으로 마이그레이션 고려 사항: 이전 세대에서 프롬프트를 이전하는 경우를 다룹니다.



Claude Fable 5

Claude Fable 5 및 Claude Mythos 5에 대한 프롬프트 작성 가이드는 별도 페이지에 있습니다: Claude Fable 5 프롬프트 작성. 이 페이지는 Claude Opus 4.8과의 동작 차이점과 적용할 만한 프롬프트 및 스캐폴딩 변경 사항을 다루며, 여기에는 effort 레벨, 지시 사항 준수, 장기 실행 진행 상황 보고, 메모리 시스템, reasoning_extraction 거부 카테고리가 포함됩니다.



Claude Opus 4.8 프롬프트 작성

Claude Opus 4.8에 대한 프롬프트 작성 가이드는 별도 페이지에 있습니다: Claude Opus 4.8 프롬프트 작성. 이 페이지는 응답 길이, effort 및 사고 깊이 조정, 도구 사용 트리거링, 문자 그대로의 지시 사항 준수, 서브에이전트 제어, 디자인 및 프론트엔드 기본값을 다룹니다.



일반 원칙

이 섹션과 이후 섹션의 기법은 Claude Fable 5 및 Claude Mythos 5를 포함한 모든 현재 Claude 모델에 적용됩니다.



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

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

Claude를 뛰어나지만 여러분의 규범과 워크플로우에 대한 맥락이 없는 신입 직원이라고 생각하세요. 원하는 것을 더 정확하게 설명할수록 결과가 더 좋아집니다.

황금률: 작업에 대한 맥락이 거의 없는 동료에게 프롬프트를 보여주고 따라 해보라고 요청하세요. 동료가 혼란스러워한다면 Claude도 마찬가지일 것입니다.

• 원하는 출력 형식과 제약 조건에 대해 구체적으로 명시하세요.
• 단계의 순서나 완전성이 중요한 경우 번호 목록이나 글머리 기호를 사용하여 지시 사항을 순차적 단계로 제공하세요.



성능 향상을 위한 맥락 추가

지시 사항 뒤에 맥락이나 동기를 제공하는 것, 예를 들어 해당 동작이 왜 중요한지 Claude에게 설명하는 것은 Claude가 목표를 더 잘 이해하고 더 정확한 응답을 제공하는 데 도움이 될 수 있습니다.

Claude는 설명으로부터 일반화할 만큼 충분히 똑똑합니다.



예시를 효과적으로 사용하기

예시는 Claude의 출력 형식, 톤, 구조를 조정하는 가장 신뢰할 수 있는 방법 중 하나입니다. 잘 작성된 몇 가지 예시(few-shot 또는 multishot 프롬프팅이라고 함)는 정확성과 일관성을 크게 향상시킬 수 있습니다.

예시를 추가할 때는 다음을 확인하세요:

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



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

XML 태그는 특히 프롬프트에 지시 사항, 맥락, 예시, 변수 입력이 혼합되어 있을 때 Claude가 복잡한 프롬프트를 명확하게 파싱하는 데 도움이 됩니다. 각 유형의 콘텐츠를 자체 태그(예: <instructions>, <context>, <input>)로 감싸면 오해를 줄일 수 있습니다.

모범 사례:

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



Claude에게 역할 부여하기

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

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-opus-4-8",
    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_content> 및 <source>(및 기타 메타데이터) 하위 태그가 있는 <document> 태그로 감싸세요.

  다중 문서 구조 예시

• 인용문으로 응답 근거 마련: 긴 문서 작업의 경우, Claude에게 작업을 수행하기 전에 먼저 문서의 관련 부분을 인용하도록 요청하세요. 이는 Claude가 문서의 나머지 내용에서 발생하는 노이즈를 걸러내는 데 도움이 됩니다.

  인용문 추출 예시



모델 자기 인식

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

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

모델 문자열을 지정해야 하는 LLM 기반 앱의 경우:

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



출력 및 형식



커뮤니케이션 스타일과 상세도

Claude의 최신 모델은 이전 모델에 비해 더 간결하고 자연스러운 커뮤니케이션 스타일을 가지고 있습니다:

• 더 직접적이고 근거 기반: 자화자찬식 업데이트보다는 사실 기반의 진행 상황 보고를 제공합니다
• 더 대화적: 약간 더 유창하고 구어체적이며, 덜 기계적입니다
• 덜 장황함: 별도로 요청하지 않는 한 효율성을 위해 상세한 요약을 생략할 수 있습니다

이는 Claude가 도구 호출 후 구두 요약을 건너뛰고 다음 작업으로 바로 넘어갈 수 있음을 의미합니다. 추론 과정에 대한 더 많은 가시성을 원한다면:

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



응답 형식 제어하기

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

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>



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부터 마지막 어시스턴트 턴의 사전 채워진 응답은 더 이상 지원되지 않습니다. 이러한 모델에 사전 채워진 어시스턴트 메시지가 포함된 요청은 400 오류를 반환합니다. 모델의 지능과 지시 사항 준수 능력이 발전하여 대부분의 prefill 사용 사례에서 더 이상 필요하지 않습니다. 이전 모델은 계속해서 prefill을 지원하며, 대화의 다른 위치에 어시스턴트 메시지를 추가하는 것은 영향을 받지 않습니다.

다음은 일반적인 prefill 시나리오와 이를 마이그레이션하는 방법입니다:



도구 사용



도구 사용법

Claude의 최신 모델은 정확한 지시 사항 준수를 위해 학습되었으며 특정 도구를 사용하라는 명시적인 지시로부터 이점을 얻습니다. "몇 가지 변경 사항을 제안해 줄 수 있나요"라고 말하면, 변경을 의도했더라도 Claude는 때때로 변경을 구현하는 대신 제안만 제공합니다.

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

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 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에서 여전히 작동하지만 더 이상 사용되지 않습니다. effort 설정을 낮추거나 적응형 사고와 함께 max_tokens를 엄격한 제한으로 사용하는 것을 권장합니다.



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

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

Claude Opus 4.6과 Claude Sonnet 4.6은 적응형 사고(thinking: {type: "adaptive"})를 사용하며, 여기서 Claude는 언제 얼마나 사고할지 동적으로 결정합니다. 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.

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

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

budget_tokens가 있는 확장 사고에서 마이그레이션하는 경우, 사고 구성을 교체하고 예산 제어를 effort로 이동하세요:

이전 (확장 사고, 이전 모델):

client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=64000,
    thinking={"type": "enabled", "budget_tokens": 32000},
    messages=[{"role": "user", "content": "..."}],
)

이후 (적응형 사고):

client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # or "max", "xhigh", "medium", "low"
    messages=[{"role": "user", "content": "..."}],
)

확장 사고를 사용하지 않는 경우 변경이 필요하지 않습니다. thinking 매개변수를 생략하면 사고는 기본적으로 꺼져 있습니다.

• 규범적인 단계보다 일반적인 지시를 선호하세요. "철저하게 생각하세요"와 같은 프롬프트는 종종 수작업으로 작성된 단계별 계획보다 더 나은 추론을 생성합니다. Claude의 추론은 종종 사람이 규정하는 것을 능가합니다.
• Multishot 예시는 사고와 함께 작동합니다. few-shot 예시 내에서 <thinking> 태그를 사용하여 Claude에게 추론 패턴을 보여주세요. Claude는 해당 스타일을 자체 확장 사고 블록으로 일반화합니다.
• 대체 수단으로서의 수동 CoT. 사고가 꺼져 있을 때도 Claude에게 문제를 단계별로 생각하도록 요청하여 단계별 추론을 유도할 수 있습니다. <thinking> 및 <answer>와 같은 구조화된 태그를 사용하여 추론과 최종 출력을 깔끔하게 분리하세요.
• Claude에게 자체 점검을 요청하세요. "완료하기 전에 [테스트 기준]에 대해 답변을 검증하세요"와 같은 내용을 추가하세요. 이는 특히 코딩과 수학에서 오류를 안정적으로 포착합니다.



에이전트 시스템



장기 추론 및 상태 추적

Claude의 최신 모델은 뛰어난 상태 추적 기능으로 장기 추론 작업에 탁월합니다. Claude는 모든 것을 한 번에 시도하기보다는 한 번에 몇 가지 사항에 대해 꾸준히 진전을 이루는 점진적 진행에 집중함으로써 확장된 세션 전반에 걸쳐 방향성을 유지합니다. 이 기능은 특히 여러 컨텍스트 윈도우 또는 작업 반복에 걸쳐 나타나며, Claude는 복잡한 작업을 수행하고 상태를 저장한 다음 새로운 컨텍스트 윈도우로 계속할 수 있습니다.



컨텍스트 인식 및 다중 윈도우 워크플로우

Claude 4.6 및 Claude 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. 새로 시작 vs 압축: 컨텍스트 윈도우가 지워지면 압축을 사용하는 대신 완전히 새로운 컨텍스트 윈도우로 시작하는 것을 고려하세요. Claude의 최신 모델은 로컬 파일 시스템에서 상태를 발견하는 데 매우 효과적입니다. 경우에 따라 압축보다 이를 활용하고 싶을 수 있습니다. 시작 방법에 대해 명확하게 지시하세요:

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

5. 검증 도구 제공: 자율 작업의 길이가 늘어남에 따라 Claude는 지속적인 인간 피드백 없이 정확성을 검증해야 합니다. UI 테스트를 위한 Playwright MCP 서버 또는 컴퓨터 사용 기능과 같은 도구가 도움이 됩니다.

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.



상태 관리 모범 사례

• 상태 데이터에 구조화된 형식 사용: 구조화된 정보(테스트 결과 또는 작업 상태 등)를 추적할 때는 Claude가 스키마 요구 사항을 이해하는 데 도움이 되도록 JSON 또는 기타 구조화된 형식을 사용하세요
• 진행 노트에는 비구조화된 텍스트 사용: 자유 형식의 진행 노트는 일반적인 진행 상황과 컨텍스트를 추적하는 데 잘 작동합니다
• 상태 추적에 git 사용: Git은 수행된 작업의 로그와 복원할 수 있는 체크포인트를 제공합니다. Claude의 최신 모델은 여러 세션에 걸쳐 상태를 추적하기 위해 git을 사용하는 데 특히 뛰어납니다.
• 점진적 진행 강조: Claude에게 진행 상황을 추적하고 점진적 작업에 집중하도록 명시적으로 요청하세요



자율성과 안전성의 균형

가이드 없이 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 호출이 더 빠르고 충분한 경우에도 모델은 코드 탐색을 위해 서브에이전트를 생성할 수 있습니다.

과도한 서브에이전트 사용이 보인다면, 서브에이전트가 필요한 경우와 그렇지 않은 경우에 대한 명시적 가이드를 추가하세요:

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" 미학이라고 부르는 일반적인 패턴으로 기본 설정될 수 있습니다. 놀랍고 즐거운 독특하고 창의적인 프론트엔드를 만들려면:

더 나은 프론트엔드 디자인을 장려하기 위해 사용할 수 있는 시스템 프롬프트 스니펫은 다음과 같습니다:

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

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

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

3. 특정 기능을 명시적으로 요청: 애니메이션과 인터랙티브 요소는 원할 때 명시적으로 요청해야 합니다.

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

5. 사전 채워진 응답에서 마이그레이션: Claude 4.6 모델부터 마지막 어시스턴트 턴의 사전 채워진 응답은 더 이상 지원되지 않습니다. 대안에 대한 자세한 가이드는 사전 채워진 응답에서 마이그레이션하기를 참조하세요.

6. 게으름 방지 프롬프트 조정: 이전에 모델이 더 철저하거나 도구를 더 적극적으로 사용하도록 권장하는 프롬프트를 사용했다면, 해당 가이드를 완화하세요. Claude 4.6 모델은 훨씬 더 적극적이며 이전 모델에 필요했던 지시에 대해 과도하게 트리거될 수 있습니다.

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



Claude Sonnet 4.5에서 Claude Sonnet 4.6으로 마이그레이션

마이그레이션 가이드의 Sonnet 4.5에서 마이그레이션을 참조하세요. 여기서는 effort 기본값 변경과 두 가지 확장 사고 마이그레이션 경로를 다룹니다.