이 기사에서 알 수 있는 것

2026년 7월 24일에 출시된 Claude Opus 5. 가격은 Opus 4.8과 동일한 $5/$25로 유지되며, Fable 5의 절반 가격으로 「프론티어급 (Frontier-class)」을 표방하고 있습니다.

여기서 많은 사람들이 두 번의 걸림돌을 만납니다. 첫 번째는 **「Opus 5와 Fable 5, 결국 어느 쪽이 더 위인가?」**입니다. 숫자가 같은 「5」이고 한쪽이 절반 가격이라 서열을 읽을 수 없습니다. 두 번째는 **「가격이 그대로라면 model ID만 교체하면 되는 것 아닌가?」**입니다. 실제로는 400 에러를 유발하는 파괴적 변경 (breaking change)이 2가지 포함되어 있으며, 게다가 「프롬프트를 추가하는」 것이 아니라 「기존에 작성했던 지시사항을 삭제해야」 합니다.

본 기사는 이 두 가지 혼란을 최단 시간 내에 정리하고, 이행(migration) 시 밟기 쉬운 지뢰와 그 회피책까지 일괄적으로 정리합니다.

※ 본 기사의 정보는 2026년 7월 26일 시점 (Opus 5 출시 2일 후)의 것입니다. 베타 헤더 명칭이나 베타 기능의 사양은 변경될 수 있으므로, 공식 문서에서 최신 정보를 확인하시기 바랍니다.

[★] 「Opus 5는 Fable 5의 하위 버전」이라는 오해 — 3개 계통 정리

가장 먼저 해소해야 할 오해는 이것입니다.

「5」는 세대(generation)를 의미할 뿐 서열이 아닙니다. Opus / Fable / Mythos는 병렬로 진행되는 3개의 라인입니다.

Fable 5가 $10/$50, Opus 5가 $5/$25이므로 「Opus 5 = Fable 5의 저가형 버전」이라고 읽고 싶어지지만, 실제로는 벤치마크상 Opus 5가 Fable 5를 상회하는 영역이 더 많습니다. 저렴한 쪽이 더 높다는 직관에 반하는 상태가 되어 있습니다.

3개 모델의 구분

※ Mythos 5는 현재 Glasswing 파트너(사이버 계열 세이프가드 해제) 한정이지만, Anthropic은 조만간 일부 생물학 연구자에게도 전개할 예정(생물·화학 계열 세이프가드 해제)이라고 발표했습니다. 더 넓은 trusted access 프로그램이 마련될 때까지의 잠정 조치라는 포지셔닝입니다.

그렇다면, 어떻게 구분해서 사용하는가

Anthropic 공식은 Opus 5를 「Fable 5의 프론티어 지능에 절반 가격으로 육박하는」 모델이라고 표현하고 있습니다. Anthropic의 론칭 비교표를 대조한 제3자 집계에 따르면, 두 모델의 수치가 일치하는 9개 항목 중 Opus 5가 5승, Fable 5가 3승, 1개 항목은 실질적 동점이었습니다.

※ 수치는 Anthropic의 2026년 6~7월 론칭 비교표에 기반한 제3자 집계이며, 독립적인 재현 테스트가 아닙니다.

별도의 소스인 BenchLM.ai 리더보드(2026-07-25 기준)에서는 **SWE-bench Pro 결과가 Opus 5 = 79.2% / Fable 5 = 80.0%**로 나타났으며, 1위는 Mythos 5의 80.3%입니다. 소프트웨어 엔지니어링(Software Engineering)의 최난관 영역에서만큼은 Fable / Mythos가 근소한 차이로 앞서고 있습니다.

판단 기준은 간단합니다.

전제: Opus 4.8에서 무엇이 바뀌었는가

가격이 동결되었기 때문에 "변화 없는 업데이트"처럼 보일 수 있지만, 변경 사항은 API 레벨까지 미칩니다. 우선 전체적인 모습을 파악해 보겠습니다.

변경 사항 맵

제공 플랫폼

Claude API : claude-opus-5
Amazon Bedrock : anthropic.claude-opus-5
Google Cloud : claude-opus-5
...

Opus 4.8은 모든 플랫폼에서 계속 이용할 수 있습니다.

참고로 Claude Code에서는 opus 에일리어스(Alias)의 해결 대상이 Opus 5로 전환됩니다. 단, 조건이 있습니다.

• Claude Code v2.1.219 이후 버전이 필요합니다. 그 미만 버전에서는 opus가 Opus 4.8을 계속 반환하며, 선택창(Picker)에 Opus 5가 나타나지 않습니다.
• 해결 대상은 플랜(Plan)에 따라 다릅니다 (Max / Team Premium / Enterprise 종량제 / API에서는 Opus 5. Pro·Team Standard의 기본값은 Sonnet 5 유지).
• 에일리어스 해결 대상은 제공업체(Provider)에 따라서도 다릅니다. Bedrock / Google Cloud를 경유할 경우 다른 버전으로 해결될 수 있습니다.

4.8로 고정하고 싶다면 전체 모델명인 claude-opus-4-8을 명시하거나, ANTHROPIC_DEFAULT_OPUS_MODEL을 설정하십시오.

파괴적 변경 ①: thinking이 기본 ON이 되었다

Opus 4.8에서는 thinking을 생략한 요청은 "사고 없음" 상태로 실행되었습니다. Opus 5에서는 동일한 요청이 "사고 있음" 상태로 실행됩니다.

와이어 상의 값은 변하지 않았습니다. thinking: {"type": "adaptive"}는 계속해서 유효하며, 기본 동작(default behavior)과 동일합니다. 바뀐 것은 **기본값(default)**뿐입니다.

이것이 왜 조용한 사고가 되는가

max_tokens는 사고 토큰(thinking tokens)과 응답 텍스트의 합계에 대한 하드 상한선(hard limit)입니다.

# Opus 4.8에서는 thinking 없이 실행되던 코드
response = client.messages.create(
    model="claude-opus-5", # ← ID만 교체함
    ...
)

에러는 발생하지 않습니다. stop_reason: "max_tokens"와 함께 그럴듯한 중간 문장이 반환됩니다. 배치 처리(batch processing)나 비대화형 파이프라인(non-interactive pipeline)에서는 알아차리기 어렵다는 점이 까다로운 부분입니다.

대처

thinking을 한 번도 설정하지 않았던 모든 경로에 대해, 다음 중 하나를 선택합니다.

# 안A (권장): thinking을 활용하고, max_tokens에 여유를 둠
client.messages.create(
    model="claude-opus-5",
    ...
)

공식 문서에서는 안A를 권장합니다. 이유는 다음 절에서 설명합니다.

파괴적 변경 ②: thinking의 무효화

effort: {"type": "disabled"}는 effort가 high 이하일 때만 받아들여집니다.

xhigh 또는 max와 병용하면 400 에러가 발생합니다.

# ❌ Opus 5에서는 400 에러. Opus 4.8에서는 통과되었던 조합
client.messages.create(
    model="claude-opus-5",
    ...
)

thinking을 껐을 때 발생하는 두 가지 고장 모드 (failure modes)

이 부분이 본 기사에서 가장 간과하기 쉬운 포인트입니다. thinking을 무효화하면, Opus 5는 드물게 다음 두 가지 현상을 일으킵니다.

1. 도구 호출(tool call)이 "그냥 텍스트"로 출력됨

구조화된 tool_use 블록을 내보내지 않고, 도구 호출을 사용자용 텍스트로 작성해 버리는 경우가 있습니다.

• 턴은 정상적으로 종료됨 (stop_reason은 end_turn)
• 도구는 실행되지 않음
• 에러도 경고도 발생하지 않음
• 에이전틱 루프(agentic loop)에서는, 그 가짜 텍스트가 대화 이력에 남아 후속 턴까지 오염시킴

검색 등 도구 사용이 많은 워크로드에서 발생하기 쉽다고 알려져 있습니다. 하네스(harness) 측면에서 보면 "성공했지만 아무것도 하지 않은 턴"이 되기 때문에, 모니터링으로 잡아내기 어려운 종류의 버그입니다.

2. <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을 활성화된 상태로 두고, 비용은 낮은 effort로 제어하는 것"입니다. 대부분의 태스크에서 thinking 활성화 + low effort가, 비슷한 비용으로 thinking 무효화보다 더 좋은 결과를 냅니다.

[★] Opus 5에서 "삭제해야 할" 프롬프트 5선

Opus 5 이행의 본질은 프롬프트를 추가하는 것이 아니라 깎아내는 데 있습니다. 4.8 이전에서 유효했던 테크닉 중 일부가 Opus 5에서는 역효과를 낳습니다.

1. "마지막에 검증 단계를 넣어라"

Opus 5는 말하지 않아도 스스로 검증합니다. 이 지시가 남아 있으면 과잉 검증을 일으켜 토큰을 낭비합니다. 삭제해도 품질은 떨어지지 않습니다.

- 비자명한(non-trivial) 태스크에서는 반드시 최종 검증 단계를 포함할 것.

2. 「서브 에이전트(sub-agent)에게 검증하게 하라」

위와 같습니다. 게다가 Opus 5는 서브 에이전트 위임에 적극적이기 때문에, 이중으로 작용하여 비용이 급증합니다.

3. 「더블 체크한 뒤에 답하라」 「재확인하라」

프롬프트 단위의 재체크 지시도 마찬가지 함정입니다. 「AI에게는 자기 검증을 시켜라」라는 일반적인 베스트 프랙티스(best practice)가 이 모델에서는 반대로 작용한다는 점에 주의하십시오. 프롬프트 라이브러리를 횡단 적용하고 있다면, Opus 5만 예외로 처리해야 합니다.

4. 「더 적극적으로 위임하라」 (Opus 4.8용으로 작성된 지시)

Opus 4.8은 서브 에이전트로의 위임에 소극적이었기 때문에, 많은 사람이 「위임하라」는 내용을 추가했습니다. 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
...

5. 「생각하지 마라」 「추론을 출력하지 마라」

앞서 언급한 바와 같이, thinking 비활성화 시 태그 누락 현상을 악화시킵니다. 삭제해 주십시오.

[★] 공식 문서가 제시하는 베스트 프랙티스

권장 1: 장황함은 effort가 아니라 프롬프트로 제어한다

effort 파라미터는 모델이 얼마나 많이 말하느냐가 아니라, 얼마나 많이 생각하느냐를 제어합니다. effort를 낮춘다고 해서 사고량이 줄어들 뿐, 가시적인 응답이 확실히 짧아지는 것은 아닙니다. 응답 길이를 제어하고 싶다면 명시적으로 프롬프트로 지시하십시오.

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.

긴 시스템 프롬프트에서는 끝부분에 리마인더(reminder)를 덧붙이면 효과적입니다.

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

권장 2: effort는 이전 모델의 설정을 계승하지 말고 반드시 다시 설정한다

기본값(high)에서 시작하여, 자체적인 eval(평가)에 기반해 상하로 조정하십시오. 품질이 유지되는 범위 내에서는 low와 medium을 아낌없이 사용하여 토큰 비용과 응답 시간을 제어하는 주요 수단으로 삼으십시오. 이전 모델의 effort 기본값을 그대로 사용하고 있다면, 자체 eval을 통해 effort sweep을 다시 수행하십시오.

Opus 5는 low/medium이 실용적인 수준에 도달했다는 점이 큰 변화입니다. 「일단 xhigh로 설정하자」는 Opus 5에서 최적의 해답이 아닙니다.

권장 3: 코드 리뷰에서는 「범위를 좁혀라」라고 말하지 않는다

리뷰 프롬프트에 「중대한 문제만 보고하라」, 「보수적으로」라고 적혀 있으면, 모델은 이를 문자 그대로 준수하여 보고를 줄입니다. 모든 것을 보고하게 하고, 필터링은 별도의 경로(path)에서 수행하십시오.

Opus 5는 버그 검출의 정밀도(precision)와 재현율(recall)이 모두 높은데도, 범위를 좁히라는 지시 때문에 실측 recall이 낮아 보이는 현상이 발생합니다. 이는 모델의 퇴보가 아니라 하네스(harness)의 문제입니다.

권장 4: 스코프(scope)를 명시적으로 제한한다

Opus 5는 요청하지 않은 절차를 추가하거나, 태스크의 정의 자체를 스스로 판단하여 확장하는 경우가 있습니다.

의도된 범위 내에서 요청된 사항을 전달하세요. 일상적인 판단은 스스로 내리고, 요청에 대한 해석이 달라질 경우 작업 결과에 실질적인 차이를 유발할 수 있는 상황에서만 확인을 요청하세요. 만약 요청이 잘못되었다고 판단되거나 더 나은 접근 방식이 있다면, 다음과 같이 말하세요...

[★] 흔히 저지르는 안티 패턴 7가지

1. max_tokens를 방치함

모델 ID만 교체하고 thinking: disabled를 xhigh/max와 함께 사용한 채로 이전하는 경우입니다.

2. 400 에러가 발생합니다. 게다가 요청 단위로 검증되므로, effort를 동적으로 변경하는 코드에서는 간헐적으로 에러가 발생하며 중단됩니다.

3. thinking 비활성화를 통해 비용을 절감하려 함

thinking 비활성화는 **가장 비용이 많이 드는 레버(lever)**입니다. 앞서 언급한 두 가지 고장 모드(failure mode)를 유발합니다. 비용 절감은 effort: low/medium을 통해 수행하십시오.

4. Opus 4.8용 검증 지시 및 위임 지시를 남겨둠

과도한 검증과 과도한 위임으로 인해 토큰 사용량이 배로 증가합니다. Opus 5로의 이전은 '지우는' 작업이라는 점을 이해하지 못하면, 비용이 절감되기는커녕 오히려 상승합니다.

5. 레이트 리밋(Rate Limit) 한도를 승계할 수 있다고 믿음

Opus 5는 Opus 4.x(4.8/4.7/4.6/4.5)의 합산 한도와는 **별도의 버킷(bucket)**입니다. 트래픽을 옮긴다고 해서 기존 한도가 비워지거나, 기존 한도를 승계할 수 있는 것도 아닙니다. 이전하기 전에 본인 티어(tier)의 Opus 5 상한을 확인하십시오.

6. Bedrock / Google Cloud / Foundry에서 Fast mode를 작성함

Fast mode (speed: "fast", $10/$50)는 **Claude API 전용 리서치 프리뷰(research preview)**입니다. 서드파티 경로의 코드에서는 speed 설정을 제거하십시오.

또 다른 간과하기 쉬운 제약 사항은, Fast mode는 Batch API와 병행할 수 없다는 점입니다. 배치 처리로 비용을 절반으로 줄이면서 Fast mode로 속도를 높이는 조합은 성립하지 않으므로 주의하십시오. 또한 Fast mode는 표준 Opus 한도와는 **별도의 레이트 리밋(rate limit)**을 가집니다.

7. 거부(refusal)를 무시함

Opus 5 역시 안전 분류기(safety classifier)가 요청을 거부할 수 있습니다. 이때 반환되는 값은 **HTTP 200 + stop_reason: "refusal"**이며, 예외(exception)가 발생하지는 않습니다.

response = client.messages.create(model="claude-opus-5", max_tokens=4096, messages=[...])
if response.stop_reason == "refusal":
    handle_refusal(response.stop_details) # content는 비어있거나 부분 출력됨
...

response.content[0]을 무조건적으로 읽는 코드는 거부 발생 시 에러가 납니다. 신기능인 fallbacks: "default" (베타 헤더 server-side-fallback-2026-07-01)를 사용하면, 거부 카테고리에 따라 Anthropic이 권장하는 폴백(fallback) 대상으로 서버 측에서 자동으로 전환해 줍니다.

effort 최적값 요약표

Opus 5는 "추가적인 effort를 확실하게 결과 개선으로 전환하는" 정도가 역대 Opus 모델 중 가장 높으며, 그만큼 effort 선택이 결과에 큰 영향을 미칩니다. 기본값은 high입니다.

# xhigh / max 설정 시에는 max_tokens에 충분한 여유를 두고 스트리밍(streaming)한다
with client.messages.stream(
model="claude-opus-5",
...

모델 비교표

※ Sonnet 5는 2026년 8월 31일까지 도입 가격 $2/$10. 2026년 9월 1일부터는 $3/$15가 됩니다 (※ 2026년 7월 기준).

실전 체크리스트

이전 전

• thinking을 설정하지 않은 콜 사이트(call site)를 전부 파악했는가
• thinking: disabled × effort: xhigh / max 조합이 없는지 grep 했는가
• max_tokens를 응답 길이에 딱 맞게 설정한 곳이 없는가
• 자신의 티어(Tier)에 따른 Opus 5 레이트 리미트 (Rate Limit) (Opus 4.x와는 별도)를 확인했는가
• Bedrock / Google Cloud / Foundry 경로에 speed: "fast"가 남아있지 않은가

프롬프트 정리 ("삭제" 작업)

• "최종 검증 단계를 넣어라" 계열의 지시를 삭제했는가
• "서브 에이전트로 검증하라"를 삭제했는가
• "더블 체크하라", "재확인하라"를 삭제했는가
• Opus 4.8용으로 작성한 "더 많이 위임하라"를 삭제하고 상한 지시로 대체했는가
• "생각하지 마라" 계열의 규칙을 삭제했는가
• 대신에 간결함 지시, 범위(Scope) 지시를 추가했는가

이전 후

• effort 스윕(sweep)을 자신의 평가(eval)로 다시 돌렸는가 (이전 모델의 설정을 그대로 이어받지 말 것)
• stop_reason == "refusal" 핸들링을 넣었는가
• 캐시 최소 길이가 512로 변경됨에 따라, 새롭게 캐시 대상이 되는 프롬프트가 없는지 재검토했는가
• 생성되는 문서가 너무 길어지지 않았는가 (길이 지시 추가를 검토)

요약

• "5"는 세대(Generation)를 의미하며 서열(Sequence)이 아니다. Opus / Fable / Mythos는 병렬적인 3개 라인이다. Opus 5는 Fable 5의 절반 가격이며, 많은 벤치마크에서 동등하거나 그 이상이다. Fable 5가 명확하게 우위에 있는 경우는 장시간 자율 에이전트와 최난도 소프트웨어 작업에 국한된다.
• 가격 동결 = 변화 없음, 이 아니다. thinking의 기본값 ON 설정과, thinking: disabled × xhigh / max 조합은...

400이라는 두 가지 파괴적 변경(breaking changes)이 있다. 전자는 에러가 발생하지 않고 조용히 응답을 끊어버리기 때문에 특히 위험하다. -
thinking 비활성화는 가장 비용이 많이 드는 레버(lever)다. 도구 호출(tool call)이 텍스트화되어 묵묵히 실행되지 않거나, 내부 태그가 유출되는 두 가지 고장 모드(failure mode)를 유발한다. 비용 절감은 effort: low / medium으로 수행한다. -
이전 작업의 본질은 "지우는 것"이다. 검증 지시, 재확인 지시, 위임 촉진 지시는 Opus 5에서는 역효과를 낸다. "AI에게 자기 검증을 시켜라"라는 일반적인 베스트 프랙티스(best practice)가 이 모델에서는 반전되어 있다. -
effort는 반드시 다시 설정해야 한다. low / medium이 실무 수준에 도달한 것이 Opus 5의 가장 큰 실무적 변화다. "일단 xhigh로 설정하자"는 최적해(optimal solution)가 아니다.

가격이 변하지 않는 업데이트일수록 차이점 확인이 뒤로 밀리기 마련이다. Opus 5는 바로 그 패턴에 해당하며, 모델 ID를 한 줄 바꾸는 것만으로 끝날 것처럼 보이지만, 조용히 망가지는 부분이 두 곳 있다. 이전하기 전에 체크리스트라도 훑어본다면, 나중에 원인 불명의 끊김 현상을 추적하는 시간을 통째로 절약할 수 있다.

참고 링크

• Introducing Claude Opus 5 — Anthropic
• What's new in Claude Opus 5 — Claude Platform Docs
• Prompting Claude Opus 5 — Claude Platform Docs
• Migration guide — Claude Platform Docs
• Effort — Claude Platform Docs
• Pricing — Claude Platform Docs
• Rate limits — Claude Platform Docs (Opus 5가 Opus 4.x 합산 버킷에 포함되지 않는다는 출처)
• Refusals and fallback — Claude Platform Docs (stop_reason: "refusal"과 fallbacks의 출처)
• Fast mode — Claude Platform Docs
• Claude Opus 5 vs Claude Fable 5 — llm-stats (벤치마크 비교 제3자 집계)