Anthropic은 2026년 7월 24일에 Claude Opus 5를 출시했습니다. 만약 여러분이 Claude API를 기반으로 구축하고 있다면, 이번 출시 이야기 중 안전하게 건너뛰어도 되는 부분이 하나 있습니다. 바로 벤치마크 차트입니다. 건너뛸 수 없는 부분은 API 계약(API contract)입니다. 오랜만에 Opus 출시가 기존 요청의 동작 방식을 변경했기 때문입니다. Opus 4.8에서는 완벽하게 유효했던 한 가지 파라미터 조합이 이제는 400 error를 반환합니다.

저는 동유럽의 AI 교육 플랫폼인 Cursuri-AI.ro에서 AI 엔지니어링에 대해 쓰고 가르치고 있습니다. 이 포스트는 모든 모델 출시와 함께 제공되기를 바랐던 기록입니다. 즉, "얼마나 똑똑한가"가 아니라, "내 코드에서 무엇을, 어떤 순서로 변경해야 하는가, 그리고 아무것도 변경하지 않았을 때 무엇이 조용히 다르게 동작하는가"에 대한 기록입니다. 아래의 모든 내용은 Anthropic의 공식 "What's new in Claude Opus 5" 문서에서 가져온 것이며, 유출된 수치나 추측(vibes)은 포함되어 있지 않습니다.

빠른 면책 조항: 이 분야는 매달 변화하며, 본 내용은 출시 시점의 스냅샷입니다. 무엇인가를 프로덕션(production)에 연결하기 전에 공식 문서를 통해 확인하십시오.

사양표, 하나의 표로 정리

이 중 두 가지는 보기보다 더 큰 의미를 갖습니다. 1M 컨텍스트 윈도우(context window)는 선택 사항이 아니라 모델이 기본적으로 가진 사양이며, 문서는 윈도우 전체에 걸쳐 일관된 지시 이행(instruction following), 도구 호출(tool calling), 그리고 추론(reasoning)을 보장한다고 명시하고 있습니다. 또한 128k 최대 출력(max output)은 단일 요청으로 긴 결과물(대규모 리팩토링, 전체 보고서 등)을 만드는 것을 현실적으로 만들어 줍니다. 다만 max_tokens와 관련하여 나중에 다룰 주의 사항이 있는데, 이는 모델이 이전보다 더 많은 작업을 수행하기 때문입니다.

Opus 4.8은 모든 플랫폼에서 계속 사용 가능하므로, 당일 마이그레이션(migration)을 강제하지는 않습니다. 하지만 아래의 변경 사항들은 첫 번째 "왜 이 요청이 실패하는가"라는 사건이 발생한 후가 아니라, 발생하기 전에 반드시 이해해 두어야 할 내용들입니다.

변경 사항 #1: 사고(thinking) 기능이 기본적으로 활성화됨

Opus 4.8에서는 thinking 필드가 없는 요청이 확장된 사고(extended thinking) 없이 실행되었습니다. 사용자는 thinking: {"type": "adaptive"}를 통해 이를 선택적으로 활성화했습니다.

Opus 5에서는 동일하게 필드가 없는 요청이 이제 사고 기능이 켜진 상태로 실행됩니다. 모델이 매 턴마다 언제, 얼마나 사고할지를 결정하며, effort 파라미터는 사고의 깊이를 조절하는 노브(knob) 역할을 합니다. 만약 귀하의 코드가 이미 thinking: {"type": "adaptive"}를 전송하고 있다면 문제없습니다. 해당 값은 여전히 유효하며 새로운 기본값과 동일합니다.

이것이 마치 무료 업그레이드처럼 들림에도 불구하고 귀하를 곤란하게 만들 수 있는 이유는 다음과 같습니다:

max_tokens는 사고(thinking)와 응답 텍스트를 합친 전체 출력에 대한 엄격한 제한입니다. Opus 4.8에서 max_tokens: 2000으로 문제없이 실행되었던 작업(사고 기능 없음, 짧은 답변)은 이제 가시적인 토큰을 하나도 작성하기 전에 추론(reasoning)에 예산의 상당 부분을 소비할 수 있습니다. 공식 가이드는 명확합니다: 이전에 사고 기능 없이 실행되었던 모든 작업에 대해 max_tokens를 다시 검토하십시오.

변경 사항 #2: 실제 파괴적 변경 사항(breaking change) — 사고 비활성화 + 높은 effort = 400 에러

오늘 귀하의 코드베이스에서 검색(grep)해봐야 할 내용은 다음과 같습니다:

• thinking: {"type": "disabled"}는 effort가 high 이하일 때만 허용됩니다.
• thinking: {"type": "disabled"}를 xhigh 또는 max effort와 결합하면 모든 요청에서 400 에러가 반환됩니다.
• 이는 Opus 5부터 적용되는 일반적인 동작(베타 아님)이며, 사고 비활성화가 effort 수준과 무관했던 Opus 4.8과는 다른 파괴적 변경 사항(breaking change)입니다.

만약 현재 높은 effort 수준에서 사고 기능을 비활성화하여 실행하고 있다면, 귀하에게는 정확히 두 가지 탈출구가 있습니다: 사고 기능을 비활성 상태로 유지하면서 effort를 high 이하로 낮추거나, 현재의 effort 수준을 유지하면서 thinking 필드를 완전히 삭제하는 것입니다.

thinking을 그대로 켜두어야 하는 두 번째의 더 미묘한 이유가 있습니다. 문서에 따르면 thinking이 비활성화될 경우, Opus 5는 적절한 tool_use 블록을 생성하는 대신 텍스트 출력 내에 도구 호출 (tool call)을 작성하거나, 내부 XML 태그를 가시적인 응답에 유출하는 경우가 가끔 발생할 수 있다고 명시되어 있습니다. 만약 프로덕션 환경에서 도구 호출을 파싱한다면, 이는 단순한 미관상의 문제가 아니라 핸들러가 반드시 견뎌내야 하는 실패 모드 (failure mode)입니다. Anthropic의 권장 사항은 thinking을 활성화된 상태로 유지하고, 대신 더 낮은 effort 수준으로 비용을 제어하는 것입니다.

변경 사항 #3: 이제 effort가 중요한 제어 레버입니다

thinking이 기본적으로 켜짐에 따라, effort는 통합 (integration)의 핵심 파라미터가 됩니다. Opus 5의 전체 단계는 low, medium, high (기본값), xhigh, 그리고 max로 구성됩니다. 문서에서는 진지하게 받아들일 만한 주장을 하고 있습니다. Opus 5는 추가적인 effort를 이전의 어떤 Opus 모델보다 더 안정적으로 더 나은 결과로 전환한다는 것입니다. 이는 여러분이 선택하는 수준이 4.8 버전에서보다 더 큰 비중을 차지함을 의미합니다. 반대로, low와 medium은 토큰과 지연 시간 (latency)을 아주 적게 사용하면서도 강력한 품질을 생성한다고 명시적으로 언급되어 있습니다.

모든 설정을 최대로 높인 요청은 다음과 같습니다:

import anthropic

client = anthropic.Anthropic()
...

해당 코드 스니펫에는 세 가지 의도적인 세부 사항이 있습니다: thinking 필드가 없으며 (기본값이 원하는 설정임), max_tokens가 크고 (xhigh/max 설정 시 모델이 도구 호출을 통해 생각하고 행동할 공간이 필요함), 그리고 스트리밍 (streamed) 방식이라는 점입니다. 64k 토큰 예산에서는 비스트리밍 (non-streaming) 요청이 시간 제한에 걸릴 수 있습니다.

합리적인 전략은 문서에 명시된 대로입니다. 기본값인 high에서 시작하여, 느낌(vibes)이 아닌 **자신만의 평가 (evals)**를 기반으로 조정하십시오. 품질이 유지되는 지점에서는 단계를 낮추십시오. 그러면 토큰과 지연 시간 (latency)을 절약할 수 있습니다. 정말 어려운 작업에는 xhigh/max로 단계를 높이십시오. 만약 "노력을 줄였을 때 품질이 유지되었는가?"라는 질문에 답할 수 있는 평가 하네스 (eval harness)가 없다면, 그것이 이번 분기에 구축해야 할 가장 레버리지가 높은 단일 요소입니다. 이는 저희의 프로덕션 환경에서의 LLM 평가 과정 (course on LLM evals in production)에서 기초로 다루는 규율입니다.

변경 사항 #4: 아무것도 바꾸지 않아도 모델의 _동작 방식_이 달라집니다

문서에는 코드를 수정하지 않아도 체감하게 될 차이점에 대해 매우 솔직하게 기술된 섹션이 있습니다:

• 기본 응답이 더 길어집니다 — 사용자에게 보여지는 답변과 작성된 결과물 모두 해당됩니다. 제품에 엄격한 길이 제한이 있다면, 프롬프트 (prompt)에서 이를 강제하십시오.
• 에이전트 세션 (agentic sessions)에서 모델이 진행 상황을 더 자주 설명합니다. UX 투명성 측면에서는 좋지만, 정숙함을 원하는 경우에는 이를 낮추십시오.
• 멀티 에이전트 프레임워크 (multi-agent frameworks)에서 하위 에이전트 (subagents)에게 더 기꺼이 위임합니다 — 이에 맞춰 예산을 책정하십시오. 하위 에이전트 역시 토큰을 소비합니다.
• 지시하지 않아도 스스로 자신의 작업을 검증합니다. 이 부분이 조치가 필요한 부분입니다. 이전 프롬프트에서 상속된 검증 지침 — "최종 검증 단계를 포함할 것", "하위 에이전트를 사용하여 검증할 것" 등 — 은 제거해야 합니다. Opus 5에서는 이러한 지침이 과잉 검증 (over-verification)을 유발하기 때문입니다. 모델이 이미 수행하고 있는 작업에 대해 토큰과 지연 시간 측면에서 비용을 이중으로 지불하게 됩니다.

이는 모든 마이그레이션 (migration)이 가르쳐주는 패턴입니다. 프롬프트는 이전 모델의 약점에 맞춰 조정되며, 그 조정 사항들은 다음 모델에서 마찰 요인이 됩니다. 프롬프트 감사 (prompt audit) 없는 모델 마이그레이션은 절반의 마이그레이션에 불과합니다. 실제 리포지토리 (repos)에서 프롬프트, 도구, 검증을 다루는 이 워크플로우는 저희의 Claude Code 및 에이전트 코딩 과정 (Claude Code and agentic coding course)에서 정확히 훈련하는 내용입니다.

실제로 만족하게 될 더 작은 변화들

• 프롬프트 캐싱 (Prompt caching) 최소 단위가 Opus 4.8의 1,024 토큰에서 512 토큰으로 감소했습니다. 기존에 너무 짧아서 캐싱되지 않았던 시스템 프롬프트들이 코드 변경 없이도 캐싱되기 시작합니다. 압축된 프롬프트를 대량으로 실행한다면, 이 변화만으로도 청구서 금액이 달라지는 것을 확인할 수 있습니다.
• 대화 중간 도구 변경 (Mid-conversation tool changes, beta): mid-conversation-tool-changes-2026-07-01 베타 헤더를 사용하면, 프롬프트 캐시 (prompt cache)를 유지하면서 턴(turn) 사이에 도구를 추가하거나 제거할 수 있습니다. 단계별 에이전트(explore → edit → verify와 같이 각 단계마다 다른 도구 사용)의 경우, 이는 구조적인 타협을 완전히 없애줍니다. 즉,

1. 치명적인 조합 검색 (Grep for the fatal combination): effort가 xhigh 또는 max인 근처에 thinking: {"type": "disabled"}가 어디든 있다면 → 이제 이는 400 에러를 발생시킵니다. 통합 방식에 따라 결정하세요: thinking 필드를 제거하거나, effort를 낮추십시오.
2. max_tokens 재검토: 4.8 버전에서 사고 과정(thinking) 없이 실행되었던 모든 요청에 대해 재검토하십시오 — 이제 예산(budget)에 추론(reasoning)과 응답(response)이 모두 포함됩니다.
3. 모델 ID 교체: 하드코딩된 문자열이 아닌, 설정 변수(config variable)를 통해 claude-opus-5로 교체하십시오. (모델 은퇴(retirement)는 하드코딩된 ID를 운영 환경의 404 에러로 만듭니다. 제가 어떻게 아는지 물어보세요.)
4. 검증 지침(verification instructions)에 대한 프롬프트 감사: 프롬프트를 감사하여 검증 지침을 제거하십시오 — Opus 5에서 과도한 검증(over-verification)은 순전한 낭비입니다.
5. 스트리밍(streaming) 활성화: max_tokens가 큰 모든 작업에 대해 스트리밍을 활성화하십시오.
6. 반드시 사고 과정(thinking)을 비활성화해야 하는 경우: 텍스트 내의 도구 호출(tool calls)과 흩어진 XML 태그에서도 견딜 수 있도록 파서(parser)를 만드십시오.
7. 트래픽을 전환하기 전에 평가(evals) 재실행: "평균적으로 더 낫다"는 것이 "당신의 작업에 더 낫다"는 뜻은 아닙니다.

만약 당신의 아키텍처가 3단계를 두렵게 만든다면 — 즉, 모델 ID가 서비스 전반에 흩어져 있고, 설정 레이어(config layer)가 없으며, 평가 게이트(eval gate)도 없다면 — 이는 한 번 제대로 고칠 가치가 있는 구조적인 문제입니다. "코드베이스 곳곳에 뿌려진 API 호출"에서 "모델 교체가 설정 변경만으로 가능한 애플리케이션"으로 나아가는 것이 저희의 Python으로 AI 애플리케이션 구축하기 코스가 지향하는 궤적입니다.

핵심 요약 (The bottom line)

Opus 5는 새로운 API를 배우라고 요구하지 않습니다. 대신 기존 코드가 구축되었던 **가정들을 재점검(re-check the assumptions)**할 것을 요구합니다. 별도로 명시하지 않는 한 사고 과정(thinking)은 켜져 있으며, effort가 중요한 레버(lever)가 되고, max_tokens는 이제 인지(cognition) 비용까지 지불하며, 이전에는 유효했던 하나의 파라미터 조합이 이제는 엄격한 에러(hard error)가 됩니다. 그 대가로 당신은 기본값으로 1M 토큰 컨텍스트 윈도우(window), 128k 출력, 더 저렴한 캐싱(caching), 그리고 실제 아키텍처의 고통을 해결해 주는 베타 기능들을 얻게 됩니다.

이것을 단순히 모델 이름만 찾아 바꾸는 작업이 아니라, 체크리스트 기반의 마이그레이션(migration)으로 취급하는 팀들은 기존보다 더 저렴하고 신뢰할 수 있는 통합(integration) 결과물을 얻게 될 것입니다. 그리고 한 번 구축된 이러한 규율(discipline)은 이후의 모든 출시 과정에서 다시 한번 보상으로 돌아옵니다.

만약 평가(evals), 에이전트 기반 코딩(agentic coding), 프로덕션 LLM 앱(production LLM apps) 등 이 중 어떤 것에 대해서라도 구조화된 실습 교육을 원하신다면, 그것이 바로 저희가 Cursuri-AI.ro에서 만들고 있는 것입니다.