Claude Opus 5 공개: 1M 컨텍스트와 effort 설정이 바꾸는 운영 기준

Anthropic이 2026년 7월 24일 Claude Opus 5를 공개했다. API 모델 ID는 claude-opus-5다. 공식 릴리스 노트에 따르면 Opus 5는 1M token context window를 기본이자 최대값으로 제공하고, 최대 출력은 128k tokens다. 가격은 Claude Opus 4.8과 같은 입력 $5/MTok, 출력 $25/MTok으로 안내됐다.

겉으로는 새 프론티어 모델 출시 뉴스지만, 개발팀 입장에서는 마이그레이션 체크가 필요한 변경이다. Opus 5는 thinking이 기본으로 켜져 있고, effort가 품질·비용·지연시간을 조절하는 핵심 파라미터가 됐다. 또 thinking: {"type": "disabled"}를 xhigh 또는 max effort와 함께 보내면 400 오류가 난다. Claude Opus 4.8에서 그대로 설정을 복사하면 일부 요청이 깨질 수 있다.

이번 업데이트의 핵심은 모델이 더 똑똑해졌다는 문장보다 운영 제어 방식이 바뀌었다는 점이다. 긴 컨텍스트, 긴 출력, thinking 기본값, effort 단계, mid-conversation tool changes, fallback default mode가 함께 들어왔다. 에이전트 제품을 운영하는 팀이라면 모델 교체를 단순한 문자열 변경으로 보면 위험하다.

무엇이 새로 들어왔나

공식 문서에서 강조한 기능은 다섯 가지다. 첫째, Claude Opus 5는 1M 토큰 컨텍스트를 제공한다. 작은 컨텍스트 변형 없이 기본값과 최대값이 모두 1M이다. 대규모 코드베이스, 긴 계약서 묶음, 많은 로그와 대화 기록을 한 번에 다루는 워크로드에 의미가 있다.

둘째, thinking이 기본으로 켜진다. Opus 4.8에서는 별도 설정을 하지 않으면 thinking 없이 실행됐지만, Opus 5에서는 같은 요청이 adaptive thinking으로 실행된다. 따라서 max_tokens는 보이는 답변뿐 아니라 thinking과 응답 텍스트를 합친 총 출력 한도라는 점을 다시 계산해야 한다.

셋째, effort 단계가 더 중요해졌다. Opus 5는 low, medium, high, xhigh, max를 지원한다. 기본은 high다. Anthropic은 기본에서 시작한 뒤 eval 결과에 따라 낮추거나 올리라고 권한다. 비용을 줄이려면 무작정 프롬프트를 줄이기보다 effort sweep을 해야 한다.

넷째, mid-conversation tool changes가 beta로 제공된다. 대화 중 도구를 추가하거나 제거하면서 prompt cache를 유지할 수 있다. 긴 에이전트 세션에서 매 턴 모든 도구 정의를 다시 보내지 않아도 되는 구조다. 다만 beta header mid-conversation-tool-changes-2026-07-01가 필요하다.

다섯째, fallback의 default 모드가 beta로 들어왔다. Anthropic이 추천하는 fallback 모델을 refusal category에 따라 적용하는 방식이다. 직접 모델 리스트를 유지하는 부담을 줄일 수 있지만, 실제 fallback이 어떤 비용과 품질을 만드는지는 운영 로그로 검증해야 한다.

마이그레이션에서 바로 확인해야 할 깨지는 지점

가장 먼저 확인할 것은 thinking disabled와 effort 조합이다. Opus 5에서는 thinking을 끄는 요청이 effort high 이하에서만 허용된다. xhigh 또는 max에서 thinking disabled를 보내면 400 에러가 난다. 기존 코드가 고성능 모드에서 thinking을 꺼 비용을 통제하던 방식이라면 배포 전에 반드시 테스트해야 한다.

두 번째는 max_tokens다. thinking이 기본으로 켜지면 같은 요청도 더 많은 출력 예산을 쓸 수 있다. 기존에 응답 본문 길이만 고려해 max_tokens를 작게 잡았다면, reasoning 과정이 토큰 예산을 먹고 답변이 잘릴 수 있다. 복잡한 도구 호출, subagent 사용, 긴 분석 작업은 더 넉넉한 한도를 잡아야 한다.

세 번째는 응답 길이와 진행 설명이다. Anthropic 문서에 따르면 Opus 5는 기본 사용자 응답과 deliverable이 더 길어질 수 있고, agentic session에서 진행 상황을 더 자주 설명할 수 있다. 제품 UI에서 짧은 답변을 기대하거나, agent 로그를 그대로 사용자에게 보여 주는 경우에는 프롬프트에서 길이를 따로 제어해야 한다. effort를 낮춘다고 visible response가 안정적으로 짧아지는 것은 아니다.

네 번째는 검증 프롬프트다. Opus 5는 자체 검증을 더 적극적으로 수행하므로, 예전 모델을 보완하려고 넣어 둔 “마지막에 반드시 별도 검증하라”, “검증용 subagent를 호출하라” 같은 지시가 과검증을 만들 수 있다. 비용과 지연시간이 늘고, 사용자가 원하는 결과보다 검토 로그가 길어질 수 있다.

1M 컨텍스트는 만능이 아니다

1M 토큰 컨텍스트는 매력적이지만, 모든 정보를 통째로 넣는 전략은 여전히 비싸고 느리다. 긴 컨텍스트는 검색 실패를 줄여 주지만, 쓸모없는 문서까지 넣으면 모델이 중요한 신호를 찾는 데 더 많은 토큰을 쓴다. 실무에서는 “큰 컨텍스트가 있으니 RAG를 버린다”가 아니라 “RAG가 실패했을 때 마지막으로 넣을 수 있는 상한이 커졌다”에 가깝다.

코드베이스 분석을 예로 들면, 전체 저장소를 넣는 대신 변경된 파일, 관련 테스트, 인터페이스 정의, 최근 에러 로그를 우선 넣고 부족할 때 범위를 넓히는 방식이 낫다. 법무 문서도 계약서 전체를 넣기 전에 조항별 색인과 질문 의도를 맞춘 뒤 관련 조항을 확장하는 편이 비용 대비 정확도가 좋다.

긴 컨텍스트에서 더 중요한 것은 인용과 근거 표시다. 모델이 많은 문서를 읽었다면 답변에 어떤 문서와 줄을 근거로 삼았는지 남겨야 운영자가 확인할 수 있다. 1M 컨텍스트는 책임 있는 답변을 자동으로 보장하지 않는다.

제품팀이 정해야 할 effort 정책

Opus 5 운영의 핵심은 요청 종류별 effort 기본값을 정하는 것이다. 모든 요청을 high 또는 max로 보내면 비용이 빠르게 커진다. 반대로 전부 low로 낮추면 복잡한 작업에서 품질이 흔들린다.

실무 기준은 다음처럼 나눌 수 있다. 단순 질의응답, 요약, 분류, 라벨링은 low 또는 medium 후보가 된다. 코드 변경 제안, 로그 원인 분석, 복잡한 도구 호출이 있는 워크플로우는 high에서 시작한다. 30분 이상 걸리는 긴 에이전트 작업, 대규모 리팩터링, 중요한 보안 분석은 xhigh를 테스트한다. max는 품질 개선이 eval에서 명확히 확인되는 작업에만 제한적으로 둔다.

중요한 것은 감으로 정하지 않는 것이다. 같은 태스크 50~100개를 샘플링해 effort별 성공률, 평균 지연시간, 평균 비용, 재시도율을 비교해야 한다. 그리고 사용자가 보는 답변 길이는 effort가 아니라 프롬프트와 UI 정책으로 제어해야 한다.

실행 체크리스트

Claude Opus 5는 에이전트 코딩, 긴 문서 작업, 복잡한 분석에서 매력적인 선택지다. 하지만 안전한 도입은 모델 ID를 바꾸는 일보다 운영 파라미터를 다시 설계하는 일에 가깝다.

도입 전 확인할 항목은 다음과 같다.

• 기존 코드에서 claude-opus-4-8을 어디서 쓰는지 찾았는가.
• thinking disabled와 xhigh 또는 max 조합이 없는가.
• max_tokens를 thinking 포함 총 출력 기준으로 다시 계산했는가.
• 요청 유형별 effort 기본값을 정했는가.
• effort별 eval을 돌려 품질·비용·지연시간을 비교했는가.
• 진행 설명이 길어지는 경우를 UI에서 처리할 수 있는가.
• 과거 검증 프롬프트가 과검증을 만들지 않는가.
• 1M 컨텍스트 사용 시 근거 문서와 인용 정책을 정했는가.

작게 시작하려면 사용자에게 바로 노출되지 않는 내부 코드 리뷰나 로그 분석 워크로드 하나를 골라 Opus 5 high와 기존 모델을 비교하라. 그다음 medium, xhigh를 같은 데이터셋에서 돌려 비용 대비 품질 곡선을 확인하는 편이 안전하다.