프롬프트 모범 사례

마이그레이션: 매우 긴 대화에서는 이전에 프리필 어시스턴트 리마인더였던 것을 사용자 턴에 주입하세요. 컨텍스트 보강이 더 복잡한 에이전트 시스템의 일부라면, 도구를 통해 보강하는 것을 고려하세요(턴 수 같은 휴리스틱에 따라 컨텍스트가 든 도구를 노출하거나 사용을 권장) 또는 컨텍스트 컴팩션 중에.

도구 사용 (Tool use)

도구 사용법 (Tool usage)

Claude의 최신 모델은 정밀한 지시 이행으로 훈련되어 있고, 특정 도구를 쓰라는 명시적 지시의 이점을 받아요. "can you suggest some changes"라고 하면 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..." 같은 평범한 프롬프팅으로 바꿀 수 있어요.

병렬 도구 호출 최적화하기 (Optimize parallel tool calling)

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에서 긴 에이전트 루프에서는 각 도구 결과 라운드 후 병렬 호출 지시를 턴 범위 시스템 메시지로 보내세요. 에이전트 루프에서 독립적인 도구 호출 배치하기를 참고하세요.

Thinking과 추론 (Thinking and reasoning)

과도한 생각과 지나친 철저성 (Overthinking and excessive thoroughness)

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]" 같은 지시는 과도 트리거링을 일으켜요.
• fallback으로 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 상한이 있는 확장 thinking은 Opus 4.6과 Sonnet 4.6에서는 여전히 동작하지만 더 이상 사용되지 않아요(deprecated). Claude 4.7 이상 모델에서 budget_tokens을 설정하면 400 오류가 나요. effort 설정을 낮추거나, 적응형 thinking과 함께 max_tokens을 하드 한계로 쓰는 것을 선호하세요.

thinking과 인터리브 thinking 활용하기 (Leverage thinking & interleaved thinking capabilities)

Claude의 최신 모델은 도구 사용 후의 반성이나 복잡한 다단계 추론 같은 과제에 특히 유용한 thinking 기능을 제공해요. 초기 또는 인터리브 thinking을 이끌어 더 나은 결과를 얻을 수 있어요.

Claude 4.6 이상 모델과 Claude Mythos Preview는 적응형 thinking(thinking: {type: "adaptive"})을 사용해요. Claude가 언제 얼마나 생각할지 동적으로 결정하는 방식이죠. Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5.5에서는 thinking이 항상 켜져 있고 적응형 thinking이 유일한 모드예요. Claude는 effort 파라미터와 질의 복잡성 두 가지 요소로 thinking을 보정해요. 노력 수준이 높을수록 더 많이 생각하고, 질의가 복잡할수록 더 많이 생각해요. thinking이 필요 없는 더 쉬운 질의에서는 모델이 직접 응답해요. 내부 평가에서 적응형 thinking은 확장 thinking보다 훨씬 안정적으로 더 나은 성능을 내요. 적응형 thinking으로 옮기는 것을 고려하세요.

다단계 도구 사용, 복잡한 코딩 과제, 장기 에이전트 루프 같은 에이전트 행동이 필요한 워크로드에는 적응형 thinking을 사용하세요. 이전 모델은 budget_tokens이 있는 수동 확장 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.

적응형 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.

확장 thinking에서 budget_tokens으로 마이그레이션한다면 thinking 설정을 교체하고 예산 제어를 effort로 옮기세요. 다음 예시는 마이그레이션 전후의 같은 요청을 보여줘요(사용 가능한 수준과 모델별 가용성은 effort 참조):

```bash CLI
# Before: extended thinking with a manual budget (older models)
ant messages create <<'YAML'
model: claude-sonnet-4-5-20250929
max_tokens: 16000
thinking:
  type: enabled
  budget_tokens: 10000
messages:
  - role: user
    content: "..."
YAML

# After: adaptive thinking with effort
ant messages create <<'YAML'
model: claude-opus-4-8
max_tokens: 16000
thinking:
  type: adaptive
output_config:
  effort: high
messages:
  - role: user
    content: "..."
YAML

# 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": "..."}],
)

// Before: extended thinking with a manual budget (older models)
await 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
await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 16000,
  thinking: { type: "adaptive" },
  output_config: { effort: "high" },
  messages: [{ role: "user", content: "..." }]
});

// Before: extended thinking with a manual budget (older models)
await client.Messages.Create(new MessageCreateParams
{
    Model = "claude-sonnet-4-5-20250929",
    MaxTokens = 16000,
    Thinking = new ThinkingConfigEnabled(budgetTokens: 10000),
    Messages = [new() { Role = Role.User, Content = "..." }]
});

// After: adaptive thinking with effort
await client.Messages.Create(new MessageCreateParams
{
    Model = Model.ClaudeOpus4_8,
    MaxTokens = 16000,
    Thinking = new ThinkingConfigAdaptive(),
    OutputConfig = new OutputConfig { Effort = Effort.High },
    Messages = [new() { Role = Role.User, Content = "..." }]
});

// Before: extended thinking with a manual budget (older models)
client.Messages.New(ctx, anthropic.MessageNewParams{
	Model:     "claude-sonnet-4-5-20250929",
	MaxTokens: 16000,
	Thinking: anthropic.ThinkingConfigParamUnion{
		OfEnabled: &anthropic.ThinkingConfigEnabledParam{BudgetTokens: 10000},
	},
	Messages: []anthropic.MessageParam{
		anthropic.NewUserMessage(anthropic.NewTextBlock("...")),
	},
})

// After: adaptive thinking with effort
client.Messages.New(ctx, anthropic.MessageNewParams{
	Model:     anthropic.ModelClaudeOpus4_8,
	MaxTokens: 16000,
	Thinking: anthropic.ThinkingConfigParamUnion{
		OfAdaptive: &anthropic.ThinkingConfigAdaptiveParam{},
	},
	OutputConfig: anthropic.OutputConfigParam{
		Effort: anthropic.OutputConfigEffortHigh,
	},
	Messages: []anthropic.MessageParam{
		anthropic.NewUserMessage(anthropic.NewTextBlock("...")),
	},
})

// Before: extended thinking with a manual budget (older models)
client.messages().create(MessageCreateParams.builder()
    .model("claude-sonnet-4-5-20250929")
    .maxTokens(16000L)
    .thinking(ThinkingConfigEnabled.builder().budgetTokens(10000L).build())
    .addUserMessage("...")
    .build());

// After: adaptive thinking with effort
client.messages().create(MessageCreateParams.builder()
    .model(Model.CLAUDE_OPUS_4_8)
    .maxTokens(16000L)
    .thinking(ThinkingConfigAdaptive.builder().build())
    .outputConfig(OutputConfig.builder()
        .effort(OutputConfig.Effort.HIGH)
        .build())
    .addUserMessage("...")
    .build());

// Before: extended thinking with a manual budget (older models)
$client->messages->create(
    model: 'claude-sonnet-4-5-20250929',
    maxTokens: 16000,
    thinking: ['type' => 'enabled', 'budget_tokens' => 10000],
    messages: [['role' => 'user', 'content' => '...']],
);

// After: adaptive thinking with effort
$client->messages->create(
    model: 'claude-opus-4-8',
    maxTokens: 16000,
    thinking: ['type' => 'adaptive'],
    outputConfig: ['effort' => 'high'],
    messages: [['role' => 'user', 'content' => '...']],
);

# 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: "..." }]
)

확장 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, Claude Opus 5.5에서는 thinking 파라미터 설정 여부와 무관하게 thinking이 항상 켜져 있어요.

• 처방적 단계보다 일반 지시를 선호하세요. "think thoroughly" 같은 프롬프트가 손으로 쓴 단계별 계획보다 더 나은 추론을 만들어내는 경우가 많아요. Claude의 추론은 인간이 처방하는 것을 자주 초과해요.
• Multishot 예시는 thinking과 함께 동작해요. few-shot 예시 안에서 <thinking> 태그를 사용해 Claude에게 추론 패턴을 보여주세요. 그 스타일을 자신의 확장 thinking 블록에 일반화할 거예요.
• 수동 chain-of-thought(CoT) 프롬프팅을 fallback으로. thinking이 꺼져 있을 때도 Claude에게 문제를 단계적으로 생각하라고 요청해 단계별 추론을 장려할 수 있어요. <thinking>과 <answer> 같은 구조화 태그를 사용해 추론과 최종 출력을 깔끔하게 분리하세요. Claude Opus 5에서는 thinking을 낮은 노력 수준에서 켜 둔 채 유지하는 것을 선호하세요. thinking이 비활성화되면 모델이 때로 보이는 출력에 내부 XML 태그를 내보낼 수 있으니, 그 패턴을 적용하기 전에 thinking 비활성으로 실행하기를 보세요.
• Claude에게 자기 검증을 요청하세요. "Before you finish, verify your answer against \test criteria." 같은 것을 추가하세요. 특히 코딩과 수학에서 이 방법이 오류를 확실히 잡아요. Claude Opus 5는 예외예요. 명시적 지시 없이도 자기 작업을 잘 검증하고, 이전 모델용으로 조정한 프롬프트에서 이어온 검증 지시는 과도한 검증을 일으켜 토큰과 지연을 더할 수 있어요. Claude Opus 5에서는 이 지시들을 다시 쓰지 말고 제거하세요. 과제 범위와 과도한 검증을 참고하세요.

에이전트 시스템 (Agentic systems)

장기 추론과 상태 추적 (Long-horizon reasoning and state tracking)

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

컨텍스트 인식과 멀티윈도우 워크플로 (Context awareness and multiwindow workflows)

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.

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

여러 컨텍스트 창에 걸친 워크플로 (Workflows across multiple context windows)

여러 컨텍스트 창에 걸친 과제:

1. 첫 컨텍스트 창에는 다른 프롬프트를 사용하세요: 첫 컨텍스트 창으로 프레임워크를 세우고(테스트 작성, 설정 스크립트 생성), 이후 컨텍스트 창으로 투두리스트를 반복하세요.

2. 모델이 구조화된 형식으로 테스트를 쓰게 하세요: 작업을 시작하기 전에 Claude가 테스트를 만들고 구조화된 형식(예: tests.json)으로 추적하게 하세요. 그러면 장기적으로 반복 능력이 좋아져요. 테스트의 중요성을 상기시키세요: "테스트를 제거하거나 편집하는 것은 기능 누락이나 버그를 일으킬 수 있으므로 받아들일 수 없습니다."

3. 삶의 질 도구를 설정하세요: Claude가 설정 스크립트(예: init.sh)를 만들어 서버를 깔끔하게 시작하고 테스트 스위트와 린터를 실행하게 하세요. 그러면 새 컨텍스트 창에서 이어갈 때 반복 작업을 막을 수 있어요.

4. 새로 시작 vs 컴팩션: 컨텍스트 창이 비워지면 컴팩션을 쓰는 대신 완전히 새로운 컨텍스트 창으로 시작하는 것을 고려하세요. 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."

5. 검증 도구를 제공하세요: 자율 과제가 길어질수록 Claude는 지속적인 인간 피드백 없이도 정확성을 검증해야 해요. computer use 도구, browser use 도구, 또는 브라우저 자동화 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.

상태 관리 모범 사례 (State management best practices)

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

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

자율성과 안전성 균형 맞추기 (Balancing autonomy and safety)

안내 없이 Claude Opus 4.6은 파일 삭제, force-push, 외부 서비스에 게시 같은 되돌리기 어렵거나 공유 시스템에 영향을 주는 행동을 할 수 있어요. 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.

연구와 정보 수집 (Research and information gathering)

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가 큰 자료를 체계적으로 처리하고 그 발견을 반복적으로 비판하도록 도와줘요.

하위 에이전트 오케스트레이션 (Subagent orchestration)

Claude의 최신 모델은 하위 에이전트를 네이티브로 오케스트레이션해요. 이 모델들은 과제가 전문화된 하위 에이전트에 위임하면 좋을지 인식하고, 명시적 지시 없이도 적극적으로 그렇게 해요.

이 행동을 활용하려면:

1. 잘 정의된 하위 에이전트 도구를 확보하세요: 도구 정의에 하위 에이전트 도구를 사용 가능하고 서술되게 두세요.
2. Claude가 자연스럽게 오케스트레이션하게 두세요: 명시적 지시 없이도 Claude가 적절히 위임할 거예요.
3. 과용을 주의하세요: Claude Opus 4.6은 하위 에이전트를 강하게 선호해서, 더 단순한 직접 접근으로 충분한 상황에서도 하위 에이전트를 만들 수 있어요. 예를 들어 직접 grep 호출이 더 빠르고 충분한데 코드 탐색을 위해 하위 에이전트를 만들 수 있죠. Claude Opus 5도 이전 모델보다 더 쉽게 하위 에이전트에 위임해요. 안내와 예시 감쇠 프롬프트는 하위 에이전트 생성 제어하기를 참고하세요.

하위 에이전트를 과도하게 사용하는 게 보인다면 언제 하위 에이전트가 warranted한지 아닌지에 대한 명시적 안내를 추가하세요:

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.

복잡한 프롬프트 체이닝 (Chain complex prompts)

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

가장 흔한 체이닝 패턴은 자기 교정(self-correction): 초안 생성 → Claude가 기준 대비 검토 → 검토를 바탕으로 다듬기. 각 단계는 별도 API 호출이라 어느 지점에서든 기록·평가·분기할 수 있어요.

에이전트 코딩에서 파일 생성 줄이기 (Reduce file creation in agentic coding)

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.

테스트 통과에 집착하고 하드코딩하는 것 피하기 (Avoid focusing on passing tests and hardcoding)

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.

에이전트 코딩에서 환각 최소화하기 (Minimizing hallucinations in agentic coding)

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>

기능별 팁 (Capability-specific tips)

향상된 비전 기능 (Improved vision capabilities)

Claude Opus 4.5와 Claude Opus 4.6은 이전 Claude 모델보다 향상된 비전 기능을 가져요. 이미지 처리와 데이터 추출 과제에서, 특히 컨텍스트에 여러 이미지가 있을 때 더 잘 동작해요. 이러한 개선은 computer use로도 이어져서 모델이 스크린샷과 UI 요소를 더 안정적으로 해석해요. 비디오를 프레임으로 나눠 분석하는 데도 이 모델들을 쓸 수 있어요.

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

프론트엔드 디자인 (Frontend design)

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>

전체 스킬 정의도 참고할 수 있어요.

마이그레이션 고려사항 (Migration considerations)

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

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

2. 수식어로 지시를 구성하세요: 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."를 사용하세요.

3. 특정 기능을 명시적으로 요청하세요: 애니메이션과 상호작용 요소는 원할 때 명시적으로 요청해야 해요.

4. thinking 설정을 업데이트하세요: Claude 4.6 모델은 budget_tokens이 있는 수동 thinking 대신 적응형 thinking(thinking: {type: "adaptive"})을 사용해요. effort 파라미터로 thinking 깊이를 제어하세요.

5. 프리필 응답에서 벗어나세요: 마지막 어시스턴트 턴의 프리필 응답은 Claude 4.6 모델과 Claude Mythos Preview부터 더 이상 지원되지 않아요. 대안에 대한 자세한 안내는 프리필 응답에서 벗어나기를 참고하세요.

6. 안티-나태 프롬프팅을 조정하세요: 프롬프트가 이전에 모델을 더 철저하게 또는 도구를 더 공격적으로 쓰게 했다면 그 안내를 줄이세요. Claude 4.6 모델은 더 적극적이고 이전 모델에 필요했던 지시에 과도 트리거할 수 있어요.

7. Thinking 블록을 그대로 되돌려 보내고 기록을 append-only로 유지하세요: 각 어시스턴트 턴을 API가 반환한 그대로(thinking 블록 포함) 추가하세요. Claude Fable 5.1과 Claude Opus 5.5에서 thinking 블록 앞의 대화를 수정하면 오류가 나거나, 선택하면 블록이 삭제돼요. 이전 메시지 편집, system이나 tools 재구축, 요청 사이에 이전 턴을 제자리에서 요약하는 것 모두 이후의 모든 thinking 블록을 무효로 만들어요. 그러니 이런 변경을 대화 중간 시스템 메시지와 서버 측 컨텍스트 관리로 옮기세요. 대화 기록을 append-only로 유지하기를 참고하세요.

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

Claude Sonnet 4.5 이하에서 Claude Sonnet 5로 마이그레이션하기 (Migrating to Claude Sonnet 5 from Claude Sonnet 4.5 or earlier)

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

다음 단계 (Next steps)

더 알아보기 (Learn more)

• Claude Fable 5.1 프롬프팅
• Claude Fable 5 프롬프팅
• Claude Sonnet 5 프롬프팅
• 프롬프트 엔지니어링 개요