Claude Opus 5 프롬프팅

Claude Opus 5 프롬프팅 (Prompting Claude Opus 5)

이 문서는 Claude Opus 5에 특화된 프롬프팅 패턴을 다루는 가이드예요. 응답 장황함, 에이전트 내레이션, 과제 범위, 하위 에이전트 위임, 자기 교정, 그리고 thinking이 비활성화되었을 때의 출력 산출물을 중심으로 설명해 드릴게요. 복잡한 에이전트 코딩과 엔터프라이즈 작업을 위해 만들어진 모델이니, 어떤 프롬프트 조정이 가장 유용한지 하나씩 살펴볼게요.

출처: 문서

본문

이 가이드는 Claude Opus 5에 특화된 프롬프팅 패턴을 다뤄요. 모델 사양은 Claude Opus 5를, 모든 현재 Claude 모델에 적용되는 기법은 프롬프트 모범 사례를 참고하세요.

Claude Opus 5는 복잡한 에이전트 코딩과 엔터프라이즈 작업을 위해 만들어졌고, 특히 장기 에이전트 과제에 강해요. 기존 Claude Opus 4.8 프롬프트에서도 기본으로 잘 동작해요. 아래 패턴들은 튜닝이 가장 자주 필요한 행동을 다룹니다.

능력 향상 (Capability improvements)

Claude Opus 4.8과 비교해 프롬프팅과 가장 관련 있는 향상:

  • 에이전트 코딩: Claude Opus 5는 어려운 코딩 과제(멀티파일 기능, 더 큰 리팩터, 엔드투엔드 기능 작업)에서 가장 강해요. 스텁이나 플레이스홀더를 남기기보다 전체 과제를 완료하고, 전체 과제 사양을 미리 주고 실행하도록 둘 때 가장 잘 동작해요. 단일 턴 편집 같은 더 쉬운 과제에서도 잘 동작하는데, 이전 모델과의 차이는 더 작아요.
  • 코드 리뷰와 버그 발견: Claude Opus 5는 높은 정밀도와 회상률로 코드를 리뷰해요. 패스당 높은 비율로 실제 버그를 찾고, 추가 발견도 대부분 거짓 양성보다 실제 이슈예요. 낮은 effort 설정에서도 정확도가 유지되는데, 이는 리뷰 시 빠른 패스와 나중에 더 철저한 패스를 지원해요. 리뷰 프롬프트가 "심각도 높은 이슈만 보고하세요"나 "보수적으로 하세요"라고 한다면 모델이 그 지시를 문자 그대로 따라 덜 보고할 수 있어요. 대신 모든 것을 보고하라고 하고 별도 패스로 필터링하세요.
  • 낮은 effort에서의 효율: low와 medium effort는 더 높은 설정의 토큰과 지연의 일부로 강력한 품질을 내요. 기본(high)으로 시작하고 자기 평가로 조정하세요. 품질이 유지되는 곳에서는 토큰 비용과 응답 시간의 주요 제어 수단으로 low와 medium을 자유롭게 쓰고, 까다로운 코딩·에이전트 작업에는 xhigh로 올리세요. 이전 모델에서 effort 기본값을 가져왔다면 자기 평가에서 effort 스윕을 다시 돌리세요. 전체 권장사항은 Effort를 참고하세요.
  • 비전: Claude Opus 5는 차트, 문서, 다이어그램 이해와 UI·프론트엔드 시각 재현에 강해요. 이전 모델용으로 조정한 프롬프트 측 비전 우회책은 재검증하세요. 더 이상 필요하지 않을 수 있어요. 모델이 반복적으로 분석·크롭·시각 검증할 도구가 있을 때 비전 성능이 가장 강하고, thinking만으로보다 도구 사용이 더 비용 효과적인 손잡이예요.
  • 긴 컨텍스트 작업: Claude Opus 5는 1M 토큰 컨텍스트 창을 기본값이자 최대치로 가지며, 지시 이행, 도구 호출, 추론이 창 전체에서 일관되게 유지돼요.
  • 오피스와 문서 과제: Claude Opus 5는 사소하지 않은 수식을 가진 복잡한 멀티시트 스프레드시트를 생성·작업하고, 구조가 잘 잡힌 슬라이드 데크를 만들어요. 따라야 할 특정 스타일이나 템플릿을 프롬프트해 주세요.
  • 멀티 에이전트 조정: Claude Opus 5는 하위 에이전트 팀을 잘 조정해요. 효과적인 writer-verifier 패턴과 에이전트가 서로의 작업을 덮어쓰는 드문 경우를 보여요. 비용 민감 워크로드에서는 위임을 한정하세요. 하위 에이전트 생성 제어하기를 참고하세요.

응답 길이와 장황함 (Response length and verbosity)

Claude Opus 5의 기본 사용자 대상 응답은 이전 Opus 모델들보다 길어요. effort 파라미터는 모델이 얼마나 생각하는지를 제어하지, 얼마나 말하는지를 제어하지 않아요. effort를 낮추면 thinking 양은 줄일 수 있지만 보이는 응답이 안정적으로 짧아지지는 않아요. 응답 길이를 제어하려면 명시적으로 프롬프팅하세요.

짧은 간결 지시가 효과적이에요. 예를 들어 사용자 대상 멀티턴 제품에서:

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

긴 시스템 프롬프트에서는 프롬프트 끝 근처에 짧은 리마인더와 지시를 짝을 이루세요:

<tone_preference>
Keep outputs reasonably concise.
</tone_preference>

사용자 대상 진행 업데이트 (User-facing progress updates)

Claude Opus 5는 에이전트 작업 중 쉽게 내레이션해요. 하려는 것을 발표하는 경향이 있고, 에이전트 세션에서 메시지당 출력이 이전 모델보다 긴 경우가 많아요. 과제 중 사용자와 어떻게 소통할지에 대한 명시적 안내의 이점을 받아요. 내레이션을 줄이려면 원하는 케이던스와 모양을 설명하세요:

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

내레이션을 늘리거나 스타일을 바꾸려면 같은 손잡이를 반대쪽으로 쓰세요. 업데이트가 어떻게 보여야 하는지 명시적으로 설명하고 예시를 제공하세요. 원하는 소통 스타일의 긍정적 예시가 무엇을 하지 말라는 지시보다 더 효과적인 경향이 있어요.

서면 산출물 길이 (Written deliverable length)

대화 장황함과 별개로, Claude Opus 5가 디스크에 쓰는 파일(보고서, Markdown 문서, 요약)은 이전 모델보다 긴 경우가 많아요. 제품에 Claude가 작성한 문서가 있다면 명시적 길이 보정을 추가하세요:

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

과제 범위와 과도한 검증 (Task scope and over-verification)

Claude Opus 5는 지시 없이도 자기 작업을 검증해요. 프롬프트에 명시적 검증 지시("사소하지 않은 과제에는 최종 검증 단계 포함", "검증에 하위 에이전트 사용")가 있다면 제거하세요. 이런 지시는 Claude Opus 5에서 과도한 검증을 일으키고, 제거하면 품질 손실 없이 낭비되는 토큰이 줄어요. 별도 검증 단계를 추가하는 레거시 하네스 스캐폴딩에도 같게 적용돼요.

Claude Opus 5는 과제 범위를 넓혀 요청되지 않은 단계를 추가하거나 과제가 무엇이어야 하는지 자기 판단을 적용할 수도 있어요. 좁은 과제에서는 범위를 명시적으로 제약하세요:

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

하위 에이전트 생성 제어하기 (Controlling subagent spawning)

Claude Opus 5는 이전 모델보다 더 쉽게 하위 에이전트에 위임해요. 위임은 진정으로 독립적이고 상당한 작업 스트림에서 보상을 주지만, 작은 과제에 적용하면 비용과 시간을 배가해요. 하네스가 하위 에이전트를 지원한다면 어떤 시나리오가 위임을 정당화하는지 명시적 안내를 주거나, 실행할 수 있는 에이전트 수에 결정적 상한을 설정하세요. 예를 들어:

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

하네스가 Claude Code 또는 Claude Agent SDK라면 결정적 상한은 CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH와 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS 환경 변수와 SDK의 max_budget_usd 옵션이에요. 이것들은 Claude Code 2.1.217 이상이 필요하므로, 고정된 SDK를 Claude Opus 5를 가리키기 전에 업데이트하세요. Claude Code는 claude_code 시스템 프롬프트 프리셋을 사용할 때만 Claude Opus 5에 자체 위임 지시를 추가해요. 커스텀 또는 생략된 시스템 프롬프트에서는 이 섹션의 예시 같은 위임 지시를 직접 추가하세요. 하위 에이전트 깊이, 동시성, 지출 한정을 Agent SDK 문서에서 참고하세요.

자기 교정 (Self-correction)

Claude Opus 5는 프롬프팅 없이도 자기 실수를 잘 잡고 고쳐요. 자신이 이미 수행하는 재확인("double-check your answer", "re-verify before responding")을 지시하지 마세요. 검증 지시처럼 이는 모델의 자체 행동과 겹쳐 결과 개선 없이 비용을 더해요.

모델은 또한 이전 모델보다 이전 진술에 대한 교정을 더 내레이션하는데, 이는 사용자 대상 제품에서 바람직하지 않을 수 있어요. 교정 내레이션을 중요한 교정으로 한정하려면:

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

thinking 비활성으로 실행하기 (Running with thinking disabled)

Claude Opus 5는 기본으로 thinking이 켜진 채 실행되고, thinking은 effort가 high 이하일 때만 비활성화할 수 있어요. thinking: {"type": "disabled"}와 effort xhigh 또는 max를 결합한 요청은 400 오류를 반환해요. thinking이 비활성화되면 두 가지 산출물이 모델의 보이는 출력에 때로 나타날 수 있어요. 둘 다의 주요 완화는 thinking을 켜 둔 채 유지하고 thinking을 비활성화하는 대신 낮은 effort 수준으로 토큰 비용을 제어하는 것이에요. 대부분의 과제에서 low effort에서 켜진 thinking이 비슷한 비용의 비활성 thinking보다 더 잘 동작해요.

텍스트로 된 도구 호출. thinking이 비활성화되면 모델이 구조화된 tool_use 블록을 내지 않고 사용자 대상 텍스트에 도구 호출을 쓰는 경우가 있어요. 턴은 정상적으로 완료되고 호출은 절대 실행되지 않으며, 에이전트 루프에서 누출된 텍스트는 대화 기록에 남아 이후 턴도 영향받아요. 검색 같은 도구가 많은 워크로드에서 가장 흔해요.

출력의 내부 XML 태그. thinking이 비활성화되면 모델이 보이는 응답에 <thinking> 태그나 다른 내부 XML 태그를 낼 수 있어요. 시스템 프롬프트에 모델에게 생각하지 말거나 추론하지 말라고 지시하는 규칙이 있다면 제거하세요. 그런 지시는 태그 누출을 높여요.

thinking을 비활성화한 채 유지해야 하는 통합을 위해, 단일 결합 지시가 두 산출물을 완화해요. 도구 호출 전에 말할 명시적 허가, 맞는 도구가 없을 때 강제 호출의 대안, 내부 태그에 대한 일반 규칙을 줍니다:

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

thinking 태그를 이름으로 지목하는 지시는 일반 형태보다 덜 효과적이므로, 구체적으로 이름을 말하지 마세요.

더 알아보기 (Learn more)