클로드 Opus 5 출시 — 뭐가 달라졌나, 지금 갈아탈 만한가 (2026)
단가는 그대로입니다. 대신 같은 모델이 다섯 가지 속도로 움직이기 시작했습니다.
2026년 7월 24일, 앤트로픽이 Claude Opus 5를 내놨습니다. 에이전틱 터미널 코딩 벤치마크 Frontier-Bench에서 21.1%였던 Opus 4.8의 점수가 43.3%로 올라갔습니다. 두 배가 조금 넘습니다.
그런데 가격표는 백만 토큰당 입력 $5, 출력 $25로 전작과 같습니다. 성능이 두 배가 되고 값은 그대로라면 갈아타지 않을 이유가 없어 보이지요. 실제 결정은 조금 더 복잡합니다.
가격표는 그대로, 안쪽이 바뀌었다
먼저 숫자부터 정리하겠습니다. 세 모델을 나란히 놓으면 이렇습니다.
| 항목 | Opus 4.8 | Opus 5 | Fable 5 |
|---|---|---|---|
| 입력 / 출력 단가 | $5 / $25 | $5 / $25 | $10 / $50 |
| 컨텍스트 | — | 100만 토큰 | 100만 토큰 |
| 최대 출력 | — | 12.8만 토큰 | — |
| Frontier-Bench | 21.1% | 43.3% | — |
| effort 단계 | — | low·medium·high·xhigh·max | — |
같은 값에 두 배 성능이라는 표현이 과장은 아닙니다. 다만 그 43.3%가 어떤 설정에서 나온 숫자인지가 이 글의 핵심입니다.
진짜 변화는 벤치마크가 아니라 effort 다이얼이다
Opus 5는 요청마다 추론 강도를 고를 수 있습니다. low · medium · high · xhigh · max 다섯 단계이고, API 기본값은 high입니다. xhigh는 이번에 새로 붙은 단계이고, max는 상한을 두지 않는 쪽에 가깝습니다.
이게 왜 중요하냐면, 공개된 벤치마크 상당수가 상위 설정 기준으로 측정됐기 때문입니다. CursorBench 3.2에서 Fable 5 최고점과 0.5% 차이라는 수치도 최고 노력 설정에서 나온 값입니다. 기본값 그대로 호출해 놓고 "기사에서 본 점수가 안 나온다"고 하는 건 다른 설정을 비교하는 셈이지요.
단가($5/$25)는 단계와 무관하게 같습니다. 대신 추론 단계가 높아질수록 출력(사고) 토큰이 늘어납니다. 청구서는 단가가 아니라 토큰 수로 커집니다. 같은 질문에 max로 답하면 low보다 몇 배의 출력 토큰이 나올 수 있습니다.
실무적으로는 이렇게 나눠 쓰는 편이 낫습니다. 분류·추출·포맷 변환처럼 답이 정해진 작업은 low나 medium. 코드 리뷰·설계 검토처럼 한 번 틀리면 되돌리는 비용이 큰 작업은 xhigh 이상. 대부분의 일상 작업은 기본값 high로 충분합니다.
실제 호출에서는 요청 본문에 한 줄이 늘어나는 정도입니다. 모델을 바꾸는 게 아니라 같은 모델의 강도를 지정하는 것이라, 라우팅 로직을 새로 짤 필요는 없습니다.
effort를 올려두고 그대로 방치하면 토큰 사용량이 조용히 몇 배로 뜁니다. 첫 주에는 작업 유형별 평균 출력 토큰을 한 번 찍어 보고 단계를 조정하세요.
그럼 Fable 5는 왜 남아 있나
여기까지 보면 질문이 하나 남습니다. 절반 값에 0.5% 차이라면 Fable 5를 쓸 이유가 있나?
그 0.5%에는 조건이 붙어 있습니다. 특정 벤치마크의 최고 설정에서 좁혀진 격차이지, 모든 작업에서 동일하다는 뜻이 아닙니다. OSWorld 2.0 같은 컴퓨터 사용 벤치마크에서는 Opus 5가 Fable 5의 최고 기록을 넘어섰다는 보고도 있고, 반대로 특정 유형에서는 여전히 Fable 5가 앞섭니다. 벤치마크 하나로 순위를 고정하기 어려운 국면입니다.
비용 계산에서도 함정이 있습니다. Opus 5의 Fast mode는 단가가 두 배($10/$50)로 올라가고 대신 2.5배가량 빠릅니다. 이 모드를 상시로 켜두면 Fable 5와 단가가 같아집니다. "절반 값"이라는 표현은 기본 모드 기준이라는 걸 기억해 두는 게 좋습니다.
갈아타기 전 확인할 두 가지
기존 코드를 그대로 옮기면 걸릴 수 있는 지점이 있습니다.
- thinking 비활성화가 막힙니다.
xhigh나maxeffort에서thinking: {"type": "disabled"}를 함께 보내면 400 에러가 돌아옵니다. 사고 과정을 끄고 쓰던 파이프라인이라면 effort를 낮추거나 옵션을 빼야 합니다. - 1M 컨텍스트는 공짜가 아닙니다. 창이 넓어졌다고 로그 전체를 밀어 넣으면 입력 토큰 청구가 그대로 따라옵니다. 컨텍스트 상한은 넣을 수 있는 양이지 넣어야 하는 양이 아닙니다.
구독 플랜 쪽은 계산이 다릅니다. Claude Code를 구독으로 쓰고 있다면 API 단가와 무관하게 사용량 한도 안에서 돌아가므로, 위 비용 논의보다 어떤 작업에 어떤 effort를 쓸지가 더 실질적인 결정입니다.
그래서 지금 바꿔야 하나
Opus 4.8을 쓰고 있다면 옮길 이유가 분명합니다. 같은 값에 코딩·에이전트 작업 성능이 눈에 띄게 올랐고, effort 다이얼이 생겨 비용 조절 폭도 넓어졌습니다.
Fable 5를 쓰고 있다면 한 번 재볼 만합니다. 지금 돌리는 작업 중 상위 effort로도 충분한 게 얼마나 되는지 헤아려 보세요. 절반이 넘는다면 그만큼이 그대로 절감분입니다.
그리고 이번 발표에서 가장 오래 남을 변화는 점수가 아닐 겁니다. "어떤 모델을 쓸까"가 "이 요청에 얼마나 생각하게 할까"로 바뀌기 시작했다는 것. 다음 세대에서는 이 다이얼을 얼마나 잘 돌리느냐가 실력의 일부가 될지도 모릅니다.