Anthropic이 공개한 Claude Opus 5 프롬프트 작성법 및 Opus 4.8 마이그레이션 가이드

9bow · 7월 28, 2026, 3:30오전

Claude Opus 5 프롬프트 가이드 소개

Anthropic이 공식 문서에 Claude Opus 5 전용 프롬프트 가이드를 추가했습니다. 새 모델이 나올 때 개발자가 기대하는 것은 대개 "같은 프롬프트로 더 좋은 결과"인데, 이 문서가 다루는 내용은 정확히 그 기대가 어긋나는 지점입니다. Anthropic 스스로도 Claude Opus 4.8 시절 프롬프트에서 "별도 손질 없이 잘 동작한다" 고 적어 두었지만, 그 다음 문장부터 문서 전체가 가장 자주 손봐야 하는 동작들 을 하나씩 짚습니다.

가이드를 관통하는 논지는 한 문장으로 압축됩니다. 이전 모델을 달래려고 써 둔 지시를 지우는 일이, 새 지시를 추가하는 일보다 중요합니다. 예전 Claude에게 "작업이 끝나면 반드시 검증 단계를 넣어라" 라고 적어 두었다면 Opus 5에서는 그 문장이 과잉 검증을 유발하고, "진행 상황을 3번의 도구 호출마다 요약하라" 라고 적어 두었다면 이제는 중복 서술이 됩니다. 모델이 알아서 하게 된 일을 계속 시키면 토큰만 늘고 결과는 나아지지 않습니다.

반대로 새로 적어야 하는 지시도 있습니다. Opus 5는 사용자에게 보여 주는 응답도, 파일로 써 내려가는 산출물도 이전 모델보다 깁니다. 그리고 문서가 못 박아 두는 중요한 사실이 하나 있는데, 응답 길이는 effort 파라미터로 줄어들지 않습니다. effort는 모델이 얼마나 생각하는지 를 조절할 뿐 얼마나 말하는지 를 조절하지 않기 때문에, 분량은 프롬프트로 직접 요구해야 합니다. 비용을 줄이려고 effort만 낮췄다가 응답 길이는 그대로여서 당황하는 경우가 여기서 나옵니다.

이 게시물에서는 프롬프트 가이드의 전체 내용과, 함께 읽어야 하는 Claude Opus 4.8에서 Claude Opus 5로의 마이그레이션 가이드를 묶어 정리합니다. 두 문서는 같은 이야기를 각각 프롬프트 관점과 API 관점에서 서술하고 있어서, 실제로 모델을 갈아 끼울 때는 둘을 함께 봐야 빠지는 항목이 없습니다.

심화 학습: 모델별 프롬프트 가이드

Prompting Claude Opus 5 (영문)

Claude 전 모델 공통 프롬프트 모범사례 (영문)

What's new in Claude Opus 5 (영문)

프롬프트 관점에서 달라진 능력들

Anthropic은 Claude Opus 4.8과 비교했을 때 프롬프트 작성에 직접 영향을 주는 능력 변화만 골라 일곱 가지로 정리했습니다. 벤치마크 수치를 나열하는 대신 "그래서 프롬프트를 어떻게 바꿔야 하는가"를 각 항목에 붙여 놓은 점이 이 목록의 성격을 잘 보여 줍니다.

에이전트형 코딩(Agentic Coding): 어려운 코딩 작업에서 가장 강합니다. 여러 파일에 걸친 기능 구현, 큰 규모의 리팩터링, 처음부터 끝까지 이어지는 기능 작업이 여기 해당합니다. 스텁이나 플레이스홀더를 남기지 않고 작업 전체를 완주하며, 작업 명세를 처음에 전부 주고 그대로 두었을 때 가장 좋은 결과가 나옵니다. 단일 턴 편집처럼 쉬운 작업에서도 잘 동작하지만 이전 모델과의 차이는 그만큼 크지 않습니다.
코드 리뷰와 버그 찾기: 정밀도(precision)와 재현율(recall)이 모두 높습니다. 한 번의 패스에서 실제 버그를 찾아내는 비율이 높고, 추가로 보고하는 항목도 대부분 거짓 양성이 아닌 진짜 문제입니다. 낮은 effort에서도 정확도가 유지되므로, 리뷰 시점에는 빠른 패스를 돌리고 나중에 정밀 패스를 한 번 더 돌리는 구성이 실용적입니다. 여기에 함정이 하나 있는데, 리뷰 프롬프트에 "심각도가 높은 문제만 보고하라" 나 "보수적으로 판단하라" 라고 적어 두면 모델이 그 지시를 문자 그대로 따라 보고량을 줄입니다. 전부 보고하게 한 뒤 별도의 패스에서 걸러내는 구성을 권합니다.
낮은 effort에서의 효율: low 와 medium 이 높은 설정 대비 토큰과 지연 시간의 일부만 쓰면서도 강한 품질을 냅니다. 기본값인 high 에서 시작해 자체 평가셋(evals) 기준으로 조정하되, 품질이 유지되는 구간에서는 low 와 medium 을 토큰 비용과 응답 시간의 1차 제어 수단으로 적극 쓰라고 권합니다. 까다로운 코딩과 에이전트 작업에서는 xhigh 로 올립니다. 이전 모델에서 쓰던 effort 기본값을 그대로 물려받았다면 effort 스윕을 다시 돌려야 합니다.
비전(Vision): 차트, 문서, 다이어그램 이해와 UI 및 프론트엔드 시각 복제에 강합니다. 이전 모델용으로 만들어 둔 프롬프트 차원의 비전 우회책이 있다면 다시 검증해 보라고 권하는데, 더 이상 필요 없을 가능성이 높기 때문입니다. 성능이 가장 잘 나오는 조건은 모델이 도구를 써서 반복적으로 분석하고 잘라 보고 시각적으로 확인할 수 있을 때 이며, 이 경우 도구 사용이 사고(thinking)만 늘리는 것보다 비용 효율이 좋습니다.
롱 컨텍스트 작업: 100만 토큰 컨텍스트 윈도우가 기본값이자 최대값입니다. 별도 베타 헤더가 필요 없고 장문 컨텍스트 할증도 없으며, 지시 따르기와 도구 호출, 추론 품질이 윈도우 전체에 걸쳐 일관되게 유지됩니다.
오피스 및 문서 작업: 비자명한 수식이 들어간 복잡한 다중 시트 스프레드시트를 만들고 다루며, 구조가 잘 잡힌 슬라이드 덱을 생성합니다. 따라야 할 특정 스타일이나 템플릿이 있다면 프롬프트로 명시해 주면 됩니다.
멀티 에이전트 조율: 서브에이전트 팀을 잘 조율합니다. 작성자와 검증자를 나누는 writer-verifier 패턴이 효과적으로 동작하고, 에이전트끼리 서로의 작업을 덮어쓰는 사례가 드뭅니다. 다만 비용에 민감한 워크로드라면 위임 자체에 상한을 걸어야 합니다.

응답 분량, effort가 아니라 프롬프트로 잡는다

Claude Opus 5의 사용자 대면 응답은 이전 Opus 모델보다 깁니다. 이 특성이 실무에서 문제가 되는 이유는 직관과 어긋나는 지점이 하나 있기 때문입니다. effort 파라미터는 모델이 얼마나 사고하는지를 제어하지 얼마나 말하는지를 제어하지 않습니다. effort를 낮추면 사고 분량은 줄어들지만 눈에 보이는 응답이 확실하게 짧아지지는 않습니다. 응답 길이를 통제하려면 프롬프트로 명시적으로 요구해야 합니다.

대화형 응답 줄이기

Anthropic이 제시하는 방법은 놀랄 만큼 단순합니다. 짧은 간결성 지시 하나면 충분하다는 것입니다. 여러 턴이 오가는 사용자 대면 제품이라면 다음 문장을 시스템 프롬프트에 넣습니다.

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>

에이전트 세션의 중계 멘트 조율하기

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.

같은 레버가 반대 방향으로도 작동합니다. 중계를 오히려 늘리거나 스타일을 바꾸고 싶다면 원하는 업데이트가 어떤 모습이어야 하는지 명시하고 예시를 주면 됩니다. 이때 문서가 덧붙이는 조언이 눈여겨볼 만합니다. 하지 말아야 할 것을 나열하는 지시보다, 원하는 커뮤니케이션 스타일의 긍정 예시를 보여 주는 쪽이 더 효과적입니다.

디스크에 쓰는 산출물의 분량

대화 자체의 장황함과는 별개로, Claude Opus 5가 파일로 써 내려가는 산출물도 이전 모델보다 깁니다. 리포트, 마크다운 문서, 요약본이 모두 여기 해당합니다. 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.

지워야 할 지시, 과잉 검증과 작업 범위

이 절이 가이드에서 가장 실질적인 부분입니다. 이전 모델을 위해 정성껏 써 둔 지시가 Claude Opus 5에서는 그대로 비용이 됩니다.

검증 지시는 삭제 대상입니다

Claude Opus 5는 시키지 않아도 자기 작업을 검증합니다. 프롬프트에 "사소하지 않은 작업에는 반드시 최종 검증 단계를 포함하라" 나 "서브에이전트를 써서 검증하라" 같은 명시적 검증 지시가 들어 있다면 제거해야 합니다. 이런 지시는 Opus 5에서 과잉 검증을 유발하고, 제거하면 품질 손실 없이 낭비되는 토큰만 줄어듭니다. 프롬프트뿐 아니라 별도의 검증 단계를 덧붙이는 레거시 하니스 스캐폴딩에도 같은 원칙이 적용됩니다.

가이드는 자기 교정(self-correction) 절에서도 같은 이야기를 반복합니다. 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.

이 지시문은 두 방향을 동시에 막고 있습니다. 앞부분은 요청 범위를 넘어서는 확장을 막고, 뒷부분의 "Finish the whole task" 는 반대로 작업을 임의로 좁혀 조기에 완료를 선언하는 것을 막습니다. 확장과 축소 중 한쪽만 막으면 다른 쪽으로 새기 때문입니다.

자기 교정 서술 줄이기

Claude Opus 5는 앞서 한 발언을 정정하는 과정을 이전 모델보다 자주 서술합니다. 내부적으로 실수를 잡아내는 것 자체는 좋은 일이지만, 사용자 대면 제품에서는 이 서술이 불필요한 잡음으로 읽힐 수 있습니다. 사용자에게 실제로 영향을 주는 정정만 남기려면 다음처럼 적습니다.

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.

서브에이전트 위임에 상한 걸기

Claude Opus 5는 이전 모델보다 서슴없이 서브에이전트에 위임합니다. 진짜로 독립적이고 규모가 있는 작업 갈래라면 위임이 이득이지만, 작은 작업에 적용하면 비용과 시간이 배로 늘어납니다. 서브에이전트 하나가 뜰 때마다 맥락을 다시 세우고, 다시 탐색하고, 보고하고, 그 보고를 다시 읽는 과정이 반복되기 때문입니다.

여기서 방향이 중요합니다. Claude Opus 4.8은 정반대 성향이었습니다. 4.8은 서브에이전트를 잘 쓰지 않아서 오히려 "이런 경우에는 위임하라" 고 독려하는 지시를 넣어야 했습니다. 4.8용 프롬프트를 그대로 들고 왔다면 그 독려 문장이 이제는 과잉 위임을 부추기게 됩니다. 지우고, 대신 상한을 겁니다.

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.

하니스가 서브에이전트를 지원한다면, 프롬프트 지시와 함께 몇 개까지 띄울 수 있는지 결정론적 상한 을 코드로 거는 방법도 권합니다. 위 지시문에 들어 있는 "do not use subagents to verify or double-check your own work" 는 앞 절의 과잉 검증 문제와 같은 뿌리를 공유합니다. 검증을 서브에이전트에 맡기지 말라는 것은, 검증 자체를 지시하지 말라는 조언을 위임 관점에서 다시 말한 것입니다.

thinking을 끄면 생기는 두 가지 부작용

Claude Opus 5는 사고(thinking)가 기본으로 켜져 있고, effort가 high 이하일 때만 끌 수 있습니다. 그런데 사고를 껐을 때 눈에 보이는 출력에 이따금 나타나는 아티팩트가 두 가지 있습니다. 둘 다 조용히 실패하는 유형이라 특히 조심해야 합니다.

첫째, 도구 호출이 텍스트로 새어 나옵니다. 구조화된 tool_use 블록을 내보내는 대신 사용자 대면 텍스트 안에 도구 호출을 그대로 써 버립니다. 이때 턴은 정상적으로 완료되고 호출은 실행되지 않습니다. 오류도 없고 잡아낼 tool_use 블록도 없으니, 하니스 입장에서는 아무 일도 하지 않은 성공한 턴을 보게 됩니다. 에이전트 루프에서는 더 나쁩니다. 새어 나온 텍스트가 대화 기록에 남아 이후 턴까지 영향을 주기 때문입니다. 검색처럼 도구를 많이 쓰는 워크로드에서 가장 흔하게 발생합니다.

둘째, 내부 XML 태그가 응답에 섞입니다. 모델이 <thinking> 태그나 다른 내부 XML 태그를 눈에 보이는 응답에 방출합니다. 여기서 가이드가 짚는 대응이 반직관적인데, 시스템 프롬프트에 "생각하지 말라"거나 "추론하지 말라"는 규칙이 있다면 그것을 제거하라 는 것입니다. 그런 종류의 지시는 태그 누출을 억제하는 게 아니라 오히려 늘립니다.

두 문제 모두에 대한 1차 대응은 같습니다. 사고를 켜 둔 채 낮은 effort로 토큰 비용을 제어하는 쪽 이 사고를 끄는 것보다 낫습니다. 문서는 대부분의 작업에서 "thinking enabled at low effort performs better than thinking disabled at similar cost" 라고 못 박습니다. 비슷한 비용이라면 켜 두는 쪽이 결과가 낫다는 뜻입니다.

그럼에도 사고를 반드시 꺼야 하는 통합 환경이라면, 두 아티팩트를 한꺼번에 완화하는 결합 지시 하나를 권합니다. 도구 호출 전에 말할 권한을 명시적으로 주고, 맞는 도구가 없을 때의 대안을 제시하고, 내부 태그에 대한 일반 규칙을 두는 세 부분으로 구성되어 있습니다.

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> 을 콕 집어 언급하는 대신 위처럼 "내부 또는 시스템 XML 태그" 라는 일반적 표현을 쓰라고 권합니다.

심화 학습: thinking과 effort의 상호작용

Effort 파라미터 문서 (영문)

Thinking, steering, and cost (영문)

Task budgets, 에이전트 루프의 토큰 예산 (영문)

Claude Opus 4.8에서 Claude Opus 5로 옮기기

프롬프트 가이드가 동작 차원을 다룬다면, 마이그레이션 가이드는 API 차원을 다룹니다. 요약하면 Claude Opus 5는 Claude Opus 4.8과 동일한 가격(입력 100만 토큰당 $5, 출력 100만 토큰당 $25)의 드롭인 업그레이드이고, 모델 ID 한 줄만 바꾸면 대부분 동작합니다.

model = "claude-opus-4-8"  # Before
model = "claude-opus-5"    # After

claude-opus-5 는 날짜 접미사가 없는 고정 ID로, claude-opus-4-8 과 같은 명명 규칙을 따릅니다. 그리고 4.8에서 이미 돌아가고 있는 코드 기준으로 파괴적 변경이 두 가지 있습니다.

파괴적 변경 1, 사고가 기본으로 켜집니다

Claude Opus 4.8에서는 thinking 필드가 없는 요청이 사고 없이 실행됐습니다. Claude Opus 5에서는 같은 요청이 적응형 사고(adaptive thinking)로 실행됩니다. 와이어 포맷은 그대로이고 thinking: {"type": "adaptive"} 도 여전히 유효하며 기본값과 동일합니다. 바뀐 것은 기본값 자체입니다.

이것이 조용한 비용 증가이자 잘림(truncation) 위험인 이유는 max_tokens 가 사고와 응답 텍스트를 합친 총 출력의 하드 리밋 이기 때문입니다. Claude Opus 4.8에서 사고 없이 돌아가던 워크로드가 답변 길이에 딱 맞춰 max_tokens 를 좁게 잡아 두었다면, Opus 5에서는 응답이 중간에 잘릴 수 있습니다. thinking 을 한 번도 설정하지 않았던 모든 경로에서 max_tokens 를 다시 검토해야 합니다.

파괴적 변경 2, 사고 끄기는 effort `high` 이하에서만

thinking: {"type": "disabled"} 는 effort가 high 이하일 때만 허용됩니다. xhigh 나 max 와 조합하면 400 오류 를 반환합니다. Claude Opus 4.8은 이 조합을 받아들이므로, 사고를 끄는 요청이 있다면 마이그레이션 전에 감사해야 합니다.

검사는 요청 단위로 독립 수행됩니다. 대화 앞부분의 요청들이 통과했더라도, 사고를 끈 상태로 effort를 xhigh 로 올리는 후속 요청은 거부됩니다.

# Claude Opus 4.8에서는 통과, Claude Opus 5에서는 400
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}],
)

해결책은 둘 중 하나입니다. thinking 필드를 제거해 사고를 다시 켜거나, 사고를 끈 채로 effort를 high 이하로 낮추는 것입니다.

# 방법 1: 사고를 켠다 (기본값이므로 필드 제거)
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}],
)

# 방법 2: 사고를 끄고 effort를 낮춘다
client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "high"},  # 또는 "medium", "low"
    messages=[{"role": "user", "content": "..."}],
)

앞서 살펴본 사고 비활성화 부작용을 감안하면, 지연 시간 때문에 xhigh 와 사고 끄기를 함께 쓰던 경로는 대개 medium 에 사고를 켜 두는 쪽 이 더 나은 선택입니다.

effort를 다시 재야 하는 이유

Claude Opus 5는 다섯 단계의 effort를 모두 지원하며, 각 단계 뒤의 토큰 배분이 Claude Opus 4.8과 달라졌습니다. 이전 모델에 맞춰 튜닝한 값을 그대로 가져오지 말고 자체 평가셋으로 스윕을 다시 돌리라고 권하는 이유입니다.

effort	설명	대표 용도
`max`	토큰 지출에 제약을 두지 않는 최대 역량	가장 깊은 추론과 철저한 분석이 필요한 작업
`xhigh`	장기 실행 작업을 위한 확장 역량	30분 이상 이어지는 에이전트, 코딩 작업
`high`	기본값. 파라미터를 넣지 않은 것과 동일	복잡한 추론, 어려운 코딩, 에이전트 작업
`medium`	균형점. 적당한 토큰 절감	속도, 비용, 성능의 균형이 필요한 에이전트 작업
`low`	가장 효율적. 상당한 토큰 절감과 약간의 역량 감소	서브에이전트처럼 단순하고 빠른 작업

문서가 권하는 순서는 이렇습니다. 기본값 high 에서 출발해 양방향으로 조정합니다. 품질이 유지되는 구간에서는 단계를 내려 토큰과 지연 시간을 아끼고, 가장 까다로운 작업에서는 올립니다. max 는 역량이 비용보다 중요할 때만 시험해 보되, 토큰 사용량 증가 대비 수익이 체감할 수 있고 단순한 작업에서는 과잉 사고로 흐를 수 있다는 점을 감안합니다. xhigh 나 max 로 돌릴 때는 서브에이전트와 도구 호출 전반에 걸쳐 사고하고 행동할 여유가 필요하므로 max_tokens 를 최소 64k 정도로 크게 잡고 조정 하라고 권합니다.

함께 챙기면 좋은 것들

파괴적 변경은 아니지만 마이그레이션 시점에 같이 손보면 이득인 항목들입니다.

프롬프트 캐시 최소 길이가 512 토큰으로 내려갔습니다. Claude Opus 4.8에서는 1,024 토큰이었습니다. 짧아서 캐시가 안 걸린다고 포기했던 프롬프트들이 코드 변경 없이 캐시 엔트리를 만들게 됩니다. 다시 점검해 볼 가치가 있습니다.
대화 중 도구 변경(베타) 이 추가됐습니다. 베타 헤더 mid-conversation-tool-changes-2026-07-01 을 보내면 대화 턴 사이에 도구를 추가하거나 제거하면서도 이전 턴의 프롬프트 캐시 히트를 유지할 수 있습니다. 기존에는 도구 목록이 바뀌면 캐시된 프리픽스 전체가 무효화됐습니다. 작업 진행에 따라 도구를 점진적으로 노출하거나 회수하는 에이전트 워크로드에 유용합니다.
fallbacks: "default" 모드 를 검토할 만합니다. Claude Opus 5에는 사이버보안 안전 분류기가 붙어 있어서 특정 요청이 거절될 수 있고, 이 경우 stop_reason: "refusal" 이 담긴 정상 200 응답이 돌아옵니다. response.content[0] 을 무조건 읽는 코드는 여기서 깨집니다. 베타 헤더 server-side-fallback-2026-07-01 과 함께 fallbacks: "default" 를 넣으면 거절 범주에 따라 Anthropic이 권장하는 폴백 모델로 자동 재시도합니다. 사이버 범주 거절은 Claude Opus 4.8로 라우팅됩니다.
web fetch 도구는 Claude Opus 5에서 지원되지 않습니다. 쓰고 있었다면 대안을 준비해야 합니다.
Priority Tier도 Claude Opus 5에서는 지원되지 않습니다. Claude Opus 4.8은 계속 지원하므로, Priority Tier 약정이 있다면 용량 계획을 따로 세워야 합니다.
Fast mode 는 Claude Opus 5에서 쓸 수 있지만 Claude API 한정입니다. Amazon Bedrock, Google Cloud, Microsoft Foundry에서는 제공되지 않으며 가격은 입력 100만 토큰당 $10, 출력 100만 토큰당 $50입니다.

두 모델의 차이를 한눈에 보면 다음과 같습니다.

항목	Claude Opus 4.8	Claude Opus 5
`thinking` 필드 생략 시	사고 없이 실행	적응형 사고로 실행
`thinking: disabled` 허용 범위	effort와 무관하게 허용	effort `high` 이하만, 그 위는 400
effort 단계	`low` ~ `max`	`low` ~ `max` (토큰 배분 재조정)
프롬프트 캐시 최소 길이	1,024 토큰	512 토큰
컨텍스트 윈도우	100만 토큰	100만 토큰 (기본이자 최대)
최대 출력 토큰	128k	128k
가격 (100만 토큰)	입력 $5 / 출력 $25	동일
web fetch 도구	지원	미지원
Priority Tier	지원	미지원
Fast mode	지원	지원 (Claude API 한정)

정리, 프롬프트에서 지울 것과 더할 것

가이드 전체를 실행 가능한 형태로 압축하면 두 개의 목록이 남습니다. 새 모델로 옮길 때 프롬프트를 처음부터 다시 쓸 필요는 없고, 아래 항목만 확인하면 됩니다.

지울 것

최종 검증 단계를 넣으라는 지시, 서브에이전트로 검증하라는 지시
"답변을 다시 확인하라", "응답 전에 재검증하라" 같은 재확인 요구
하니스에 별도로 붙여 둔 검증 스텝
진행 상황을 N번의 도구 호출마다 요약하라는 강제 중계 스캐폴딩
Claude Opus 4.8용으로 넣어 둔 "더 적극적으로 위임하라" 류의 문장
시스템 프롬프트의 "생각하지 말라", "추론하지 말라" 규칙
리뷰 프롬프트의 "심각도 높은 것만 보고하라" 필터

더할 것

대화형 응답에 대한 간결성 지시, 그리고 긴 시스템 프롬프트라면 끝부분의 짧은 리마인더
파일로 쓰는 산출물에 대한 분량 보정 지시
에이전트 세션의 중계 케이던스와 형태에 대한 서술
작업 범위를 좁히는 지시 (넓히지도, 좁히지도 말 것)
서브에이전트 위임 조건과 결정론적 상한
사용자에게 영향을 주는 정정만 남기라는 자기 교정 지시
사고를 끈 경로에는 도구 호출과 내부 태그에 대한 결합 완화 지시

마이그레이션 관점에서는 여기에 세 가지가 더 붙습니다. thinking 을 한 번도 설정하지 않은 경로에서 max_tokens 재검토, thinking: disabled 와 xhigh 또는 max 조합 감사, 그리고 자체 평가셋 기준의 effort 스윕 재실행입니다. 앞의 둘은 하지 않으면 잘림이나 400 오류로 이어지고, 마지막 하나는 비용과 품질의 균형점을 다시 찾는 작업입니다.

Prompting Claude Opus 5 프롬프트 가이드

Claude Opus 4.8에서 Claude Opus 5로의 마이그레이션 가이드

What's new in Claude Opus 5

Anthropic Claude 개발자 플랫폼

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~