Claude Opus 5에서 Opus 5.5로 마이그레이션: API 호출자가 알아야 할 변경 사항

Anthropic은 2026년 9월 22일 Claude Opus 5.5를 출시했습니다. Claude API를 호출하는 사람에게 이번 업그레이드는 문자열 하나입니다. claude-opus-5가 claude-opus-5-5로 바뀝니다.

그 문자열 뒤에 있는 것은 양방향 모두 토큰당 20% 저렴해진 가격, 단일 응답당 최대 128,000 출력 토큰, 출력 속도 30% 향상 주장, 그리고 하나의 작업에 18시간 이상 머무를 수 있도록 설계된 능력입니다. 이 중 어느 것도 Opus 5에 맞춰 튜닝한 코드에 아무 영향을 주지 않는 것은 아닙니다.

이것은 이 모델 라인에서 두 번째 마이그레이션 이동이며, 첫 번째와는 전혀 다르게 읽힙니다. Opus 4.8에서 Opus 5로는 정확성 마이그레이션이었습니다. 기본값이 동작하는 코드 아래에서 바뀌었고, 이전에는 유효했던 한 가지 요청 조합이 하드 400을 반환하기 시작했습니다. 이번 이동은 예산과 운영 범위의 마이그레이션입니다. 이미 한 번 측정한 숫자들을 다시 측정하는 작업인데, 그 모든 숫자가 움직였기 때문입니다. Opus 5.5는 또한 두 개의 새로운 OpenAI 모델과 같은 날 등장했는데, 이는 그 자체로 하나의 이야기입니다.

출처를 확인할 수 있는 항목만 정리한 차이점

빈 칸은 의도적입니다. Anthropic은 자사 모델 페이지에 Opus 5.5 쪽을 공개했지만, 우리는 기억을 더듬어 Opus 5 쪽을 재구성하지 않을 것입니다. 비용 모델에 들어간 잘못된 숫자는 빠진 숫자보다 더 나쁘기 때문입니다. 절감액 추정치를 이 다섯 행 위에 세우기 전에 Anthropic의 가격 페이지에서 직접 가져오세요.

1. id 변경은 사실이고, 20%도 사실이며, 40%는 따져봐야 한다

문자열을 바꾸면 양방향 모두 토큰당 20%를 덜 냅니다. 이 부분은 산수입니다. 입력은 $5에서 $4로, 출력은 $25에서 $20으로, 양쪽 모두 같은 폭으로 인하됩니다.

Anthropic은 또한 Opus 5.5가 Opus 5보다 실행 비용이 40% 적게 든다고 말합니다. 이 두 숫자는 충돌하지 않지만, 같은 주장도 아닙니다. 토큰당 20% 인하만으로는 청구서 40% 절감을 만들어낼 수 없습니다. 나머지 절반은 같은 작업을 끝내는 데 모델이 더 적은 토큰을 사용하는 데서 나와야 하며, 토큰 효율성은 가격표와 달리 워크로드에 따라 달라집니다.

그러니 40%는 예측치에 바로 넣을 숫자가 아니라 다시 측정할 이유로 다루세요. 지난주 실제 트래픽의 대표적인 일부를 동일한 프롬프트와 설정으로 두 모델 id에 대해 재생하고, usage 블록을 인상이 아니라 실제로 비교한 다음, 실제 토큰 수에 새 요금을 곱하세요. 답은 20%와 40% 사이 어딘가에 나올 것이고, 어디에 나오는지가 프롬프트 중 얼마나 많은 부분이 애초에 필요 없었는지에 대한 유용한 정보를 알려줍니다.

2. 캐시 항목이 표에서 가장 큰 가격 변화다

Opus 5.5의 캐시 읽기는 백만 토큰당 $0.20으로, 새 입력의 $4.00에 비해 95% 할인입니다. 캐시 쓰기는 백만 토큰당 $5.00으로, 해당 토큰을 캐시 없이 보냈을 때 냈을 $4.00보다 $1.00 비쌉니다.

이 프리미엄은 첫 적중에서 이미 남는 장사입니다. 프리픽스를 쓰는 데는 캐시하지 않는 것보다 백만당 $1.00 더 듭니다. 그 프리픽스를 이후에 읽을 때마다 백만당 $3.80을 절약합니다. 손익분기점은 대략 재읽기 4분의 1 지점이며, 실무적으로는 프리픽스가 한 번이라도 재사용된다면 캐시하는 것이 옳았다는 뜻입니다.

200,000 토큰 시스템 프롬프트의 경우는 다음과 같습니다. OpenAPI 스펙 번들을 붙여넣으면 흔한 크기입니다.

같은 프롬프트, 같은 모델인데 83% 더 저렴합니다. 두 번째 행을 만들어주는 요청은 프리픽스를 명시적으로 표시합니다.

{
  "model": "claude-opus-5-5",
  "max_tokens": 4096,
  "system": [
    {
      "type": "text",
      "text": "<your 200k-token spec bundle>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "Which endpoints changed between v2 and v3?"}
  ]
}

그다음 응답을 읽어 적중했는지 확인하세요. 있다고 생각했는데 없는 캐시가 가장 비싼 종류입니다.

"usage": {
  "input_tokens": 41,
  "cache_creation_input_tokens": 204800,
  "cache_read_input_tokens": 0,
  "output_tokens": 612
}

첫 호출에서는 cache_creation_input_tokens가 부하를 담당합니다. 그 이후의 모든 호출에서는 그 숫자가 0으로 떨어지고 cache_read_input_tokens가 이를 이어받아야 합니다. 그렇지 않다면 업스트림 어딘가에서 프리픽스를 변경하고 있는 것이며, 보통 타임스탬프, 요청 id, 또는 순서가 바뀐 도구 목록이 원인입니다. Apidog에서 호출 하나를 저장해 두 번 실행하면 두 필드 중 어느 쪽이 움직이는지 가장 빠르게 확인할 수 있습니다. 1M 컨텍스트를 캐시할 가치가 있는 경우까지 포함한 전체 산수는 Opus 5.5 캐싱 비용 산수에 있습니다.

3. 128,000 토큰 응답은 모델 문제이기 전에 클라이언트 문제다

Opus 5.5는 한 응답에서 최대 128,000 출력 토큰을 반환합니다. 백만당 $20이면 한 번 가득 채운 호출에 $2.56이며, 누군가 재시도 루프에서 max_tokens를 최대치로 설정하기 전에 알아둘 만합니다.

더 큰 문제는 모델과 여러분의 코드 사이에 있는 모든 것입니다.

• HTTP 읽기 타임아웃. 그렇게 긴 응답은 초가 아니라 분 단위로 걸립니다. 대부분의 SDK와 리버스 프록시의 기본 클라이언트 타임아웃은 그보다 짧습니다.
• 프록시 및 게이트웨이 버퍼. 전체 본문을 버퍼링한 뒤 전달하는 게이트웨이는 진행 중인 요청마다 메가바이트를 붙들고 있으며, 일부는 그냥 연결을 끊어버립니다.
• 비스트리밍 호출. 스트리밍이 없으면 아무것도 보지 못하고 아무것도 체크포인트하지 못한 채 그 시간을 전부 기다립니다.
• 잘린 JSON. 객체 중간에 max_tokens에 도달하면 복구할 수 있는 부분 객체가 아니라 유효하지 않은 JSON이 나옵니다. 파싱하기 전에 stop_reason을 확인하세요.

최대치가 올라갔다고 max_tokens를 올리는 것은 쉬운 절반입니다. 타임아웃 체인, 버퍼, 파서를 새 최대치에 맞추는 것이 장애를 일으키는 나머지 절반입니다.

4. 출력이 빨라진다고 기다림이 짧아지는 것은 아니다

Anthropic은 Opus 5.5가 Opus 5보다 출력을 30% 빠르게 생성한다고 밝힙니다. 출력 속도는 실제로 제공하는 지연 시간의 한 항일 뿐입니다. 첫 토큰까지의 시간, 재시도, 대기열이 그 옆에 나란히 있으며, 더 빠르게 스트리밍하는 모델도 첫 토큰이 도착하기 전에 더 오래 생각한다면 여전히 더 느리게 느껴질 수 있습니다.

그러니 측정하세요. 같은 네트워크 위치에서 대표 프롬프트의 고정된 세트를 두 모델 id에 쏘고, 첫 토큰까지의 시간과 전체 시간 각각에 대해 p50과 p95를 따로 기록하세요. 평균 지연 시간은 여러분을 호출 알림으로 깨우는 상황을 숨깁니다.

Apidog에 API 테스트 시나리오를 두고 있다면 이건 작은 작업입니다. 저장된 요청 하나를 복제하고 모델 id를 바꾼 뒤 둘 다 일정에 따라 실행하고, 스톱워치가 아니라 응답 시간 시계열을 읽으세요. 요점은 마이그레이션에 '이전' 숫자를 가지고 들어가는 것입니다. 전환하고 나면 그 숫자를 얻을 방법이 없기 때문입니다.

5. 패스트 모드는 정확히 정가의 두 배다

Opus 5.5의 패스트 모드는 백만 입력당 $8.00, 백만 출력당 $40.00입니다. 표준 요금 $4.00과 $20.00 옆에 놓으면 가격 규칙은 머릿속에 담기 쉽습니다. 패스트 모드는 양쪽 모두 정확히 2배입니다.

그러면 결정은 판단이 아니라 산수가 됩니다. 특정 라우트의 지연 시간이 그 라우트의 토큰 청구서를 두 배로 만들 가치가 있다면 거기서 쓰고, 그렇지 않으면 쓰지 마세요. 흔한 구분은 대화형 경로에는 패스트 모드, 배치와 백그라운드 작업에는 표준 요금입니다.

6. 벤치마크 표는 결과가 아니라 테스트할 이유로 다뤄라

Anthropic이 공개한 Opus 5.5 수치는 강력합니다. Terminal-Bench 4.0 66.4%, FrontierCode v1.1 54.4%, CursorBench 4.0 57.8%, GDPval-AA v2.1 1846 Elo, AutomationBench 40.0%, 도구 사용 시 Humanity's Last Exam 67.7%, OSWorld 2.0 81.8%, Chartography 89.0%입니다. 두 벤더 중 어느 쪽도 아닌 제3자인 Artificial Analysis는 자사 지수에서 212개 모델 중 1위로 58점을 부여했습니다.

경쟁력보다 운영 측면에서 중요한 벤더 주장이 두 가지 더 있습니다. Opus 5.5는 단일 작업에 18시간 이상 머무르도록 설계되었는데, 이는 타임아웃, 재시도, 재개 가능성에 대한 평범한 가정 여럿을 깨뜨립니다. 그리고 Anthropic은 성공적인 경계 우회 시도가 85% 줄었다고 보고하는데, 이는 상속받는 속성이 아니라 여러분 자신의 엔드포인트에서 테스트 가능한 속성입니다.

이 중 어느 것도 Opus 5.5가 여러분의 프롬프트에서 더 나은지를 알려주지 않습니다. 벤더의 벤치마크 수치로 데이터베이스 업그레이드를 배포하지 않을 것과 같은 이유로, 프로덕션을 전환하기 전에 자체 평가 세트를 두 id에 걸쳐 실행하세요.

마이그레이션 체크리스트

1. 모든 서비스가 아니라 한 서비스에서 claude-opus-5를 claude-opus-5-5로 바꾸세요.
2. 파라미터 표면이 그대로라고 가정하기 전에 이번 이동에 대한 Anthropic의 마이그레이션 가이드를 읽으세요. 4.8에서 5로의 점프는 기본값을 조용히 바꿨으니, 추론하지 말고 확인하세요.
3. 실제 트래픽의 일부를 두 id에 대해 재생하고 usage 블록을 비교하세요.
4. $4와 $20 기준으로, 그리고 별도로 $5 캐시 쓰기와 $0.20 캐시 읽기 기준으로 월 지출을 다시 계산하세요.
5. 프리픽스가 안정적이라고 믿지 말고 cache_read_input_tokens에서 캐시 적중을 확인하세요.
6. 누군가 max_tokens를 128,000 근처로 설정하기 전에 HTTP 읽기 타임아웃을 늘리고 게이트웨이 버퍼를 점검하세요.
7. 전환하기 전에 두 id의 p50 및 p95 지연 시간을 기록하세요.
8. 패스트 모드는 정가의 2배를 기준으로 라우트별로 결정하세요.
9. 자체 평가 세트를 다시 실행하세요. 벤더 벤치마크는 테스트 그 자체가 아니라 테스트할 이유입니다.

Opus 5.5는 이미 호출하고 있는 모델의 더 저렴하고, 더 빠르고, 더 오래 실행되는 버전입니다. 마이그레이션 위험은 문자열 변경이 실패하는 것이 아닙니다. 이미 다른 모델에 맞춰 크기를 잡아둔 비용 모델, 타임아웃, max_tokens 값을 그대로 들고 넘어가는 것입니다.

FAQ

claude-opus-5-5는 claude-opus-5의 드롭인 대체품인가요? 이번 이동에 대한 Anthropic의 마이그레이션 가이드를 확인한 뒤에만 그렇게 취급하세요. id 변경은 한 줄 수정이지만, 이 라인의 이전 이동은 요청 형태를 바꾸지 않고 기본값을 움직였으므로 검증은 값싼 보험입니다.

Opus 5.5는 얼마나 더 저렴한가요? 양방향 모두 토큰당 20% 저렴해서, 입력은 $5에서 $4로, 출력은 $25에서 $20로 내려갑니다. Anthropic은 별도로 실행 비용 40% 절감을 밝히는데, 이는 요금 인하 위에 토큰 효율성 향상이 더해진다는 뜻입니다. 두 수치 사이 어디에 위치하는지 알려면 자체 워크로드를 측정하세요.

Opus 5.5에서 프롬프트 캐싱 비용은 얼마인가요? 쓰기는 백만 토큰당 $5.00, 읽기는 백만당 $0.20이며, 캐시하지 않은 입력은 $4.00입니다. 캐시된 프리픽스를 한 번만 재사용해도 쓰기 프리미엄을 충분히 상쇄합니다.

128,000 토큰 출력 제한이 제 클라이언트에 영향을 주나요? 보통은 그렇습니다. HTTP 읽기 타임아웃, 게이트웨이 버퍼링, 스트리밍 여부를 확인하세요. 또한 파싱 전에 stop_reason을 확인하세요. 상한에 객체 중간에 도달하면 잘린 객체가 아니라 유효하지 않은 JSON이 나오기 때문입니다.