Claude Sonnet 5.5 vs Opus 5.5 뭘 쓸까 2026 — 단가는 2배인데 에이전트 호출 비용은 1.3~2배인 이유와 작업별 선택표

Posted on by

Claude Sonnet 5.5(2026-09-28 출시)는 100만 토큰당 입력 $2·출력 $10이고, Opus 5.5는 입력 $4·출력 $20입니다. 단가는 정확히 2배지만 캐시 읽기는 둘 다 $0.20이라서, 큰 문맥을 반복해 읽는 에이전트 호출에서는 실제 비용 차이가 1.3배까지 줄어듭니다.

먼저 털어놓을 게 하나 있습니다. 제 옵시디언 볼트에는 에이전트와 스킬이 129개(아카이브 제외) 있습니다. 쓰고 있는 AI 에이전트(Claude Code)에게 model 설정을 세어 보게 했더니 sonnet이 106개, haiku 16개, inherit 7개, opus는 0개였습니다. 볼트 규칙에 “sonnet = 분석, 대부분의 에이전트”라고 적어 두고 그대로 따른 결과입니다. Sonnet과 Opus를 작업별로 비교해서 나눈 적은 사실상 없었습니다.

그러다 이번에 알게 된 사실이 있습니다. Claude Code의 sonnet 별칭은 Anthropic API 기준으로 이제 Sonnet 5.5를 가리킵니다. 공식 문서는 별칭이 시간이 지나며 갱신된다고 적고 있습니다. 파일을 하나도 안 고쳤는데 106개가 9월 28일 이후 새 모델로 돌고 있다는 뜻입니다. 그래서 이번에는 제대로 나눠 보기로 했습니다.

10월 4일 갱신: 처음 글을 쓸 때는 두 모델을 실제로 돌려 보지 못했습니다. 하루 뒤 제가 쓰는 AI 에이전트가 Claude Code 서브에이전트로 같은 작업 3개를 두 모델에 돌려 비교했고, 그 결과를 아래 “같은 작업 3개를 두 모델에 직접 돌려 보니” 섹션에 추가했습니다.

작업별 선택표 먼저

공식 단가·Anthropic 발표 벤치마크·아래 비용 계산을 합쳐서 정한 출발점입니다.

작업 기본 모델 근거 Opus로 올릴 신호
문서·보고서·블로그 초안, 데이터 분석 Sonnet 5.5 업무형 벤치마크 GDPval-AA 1844 vs 1846, 단가 절반 같은 원고를 두 번 이상 갈아엎을 때
버그 수정, 일상 코딩, 터미널 작업 Sonnet 5.5 CursorBench 4.0 55.5% vs 57.8%, Terminal-Bench 4.0은 Sonnet이 70.6%로 앞섬 같은 실패가 두 번 반복될 때
큰 문맥을 읽고 짧게 답하는 분류·라우팅 Sonnet 5.5 빠르고, Opus와 비용 차이가 1.3배뿐 오분류 한 번의 비용이 클 때
여러 시간 도는 자율 코딩, 대규모 리팩터링, 컴퓨터 사용 Opus 5.5 공식 선택 매트릭스의 Opus 용도(발표 벤치마크 차이는 작음) —
긴 출력을 대량으로 뽑는 배치 작업 Sonnet 5.5 + Batch 출력이 길면 격차가 거의 2배, 배치는 50% 할인 —

정리하면 기본값은 Sonnet 5.5, Opus 5.5는 오래 도는 자율 작업과 실패 비용이 큰 곳에만 씁니다. 표의 숫자가 어디서 왔고 어디서 틀릴 수 있는지는 아래에서 하나씩 짚습니다.

단가표만 보면 정확히 2배다

공식 가격 페이지를 10월 3일에 다시 확인했습니다. Sonnet 5 시절에 “9월 1일부터 $3/$15로 오른다”는 예고가 있었는데, 그 인상은 취소됐고 $2/$10이 표준가로 확정됐습니다. Sonnet 5.5도 같은 가격입니다.

항목(100만 토큰당) Sonnet 5.5 Opus 5.5 배수
입력 $2 $4 2배
출력 $10 $20 2배
5분 캐시 쓰기 $2.50 $5 2배
캐시 읽기 $0.20 $0.20 1배
Batch API 50% 할인 50% 할인 2배

눈에 걸리는 칸은 캐시 읽기입니다. 대부분 모델의 캐시 읽기는 입력 단가의 0.1배인데, Opus 5.5는 0.05배입니다(Fable 5.1·Mythos 5.1은 0.025배). 입력 단가가 2배 비싼 대신 할인율도 2배라서 결과적으로 둘 다 $0.20이 됩니다.

이게 왜 중요하냐면, 에이전트 비용의 큰 덩어리가 바로 “매번 다시 읽는 문맥”이기 때문입니다. 업계어로 고정 컨텍스트, 사람말로 하면 출근할 때마다 신입이 사내 규정집을 처음부터 다시 읽는 시간입니다. 그 시간의 시급이 두 모델에서 같다면, 계산이 달라집니다.

내 볼트 숫자로 다시 계산하면 1.3~2배

제 볼트에는 9월 중순에 에이전트 토큰을 줄이면서 남긴 운영 로그가 있습니다. 서브에이전트가 호출될 때마다 규칙 파일 묶음을 다시 읽는데, 그 크기가 158,531바이트, 추정 약 4만 7천5백 토큰이었습니다. 9월 15일 모닝 브리핑을 개조하면서 실측한 서브에이전트 1콜은 91,321~125,949토큰이었습니다.

이 고정 바닥 47,500토큰을 공식 단가에 넣어 4가지 경우를 계산했습니다. 두 모델이 같은 글을 같은 토큰 수로 처리한다고 가정한 계산입니다.

경우 조건 Sonnet 5.5 Opus 5.5 배수
분류·라우팅 바닥 캐시 적중 + 새 입력 500 + 출력 300 $0.0135 $0.0175 1.30
일반 워커 바닥 캐시 적중 + 새 입력 3,000 + 출력 2,000 $0.0355 $0.0615 1.73
캐시 빗나감 같은 워커, 바닥을 일반 입력으로 $0.1210 $0.2420 2.00
긴 초안 바닥 캐시 적중 + 새 입력 10,000 + 출력 15,000 $0.1795 $0.3495 1.95

분류 호출 하나를 예로 들면 계산은 이렇습니다. Sonnet은 47,500 × $0.20 + 500 × $2 + 300 × $10을 100만으로 나눠 $0.0135이고, Opus는 같은 식에 $4와 $20을 넣어 $0.0175입니다. 고정 바닥 비용 $0.0095가 두 모델에서 똑같이 깔리니, 나머지에서 생기는 차이가 전체를 2배까지 끌어올리지 못합니다.

이 표를 보고 제 이해가 바뀐 지점이 있습니다. 비용 격차를 정하는 건 모델 이름보다 출력 길이와 캐시 적중이었습니다. 짧게 답하는 분류 호출이라면 Opus로 올려도 30% 더 내는 수준이고, 캐시가 빗나가거나 긴 글을 뽑는 순간 정확히 2배로 돌아옵니다.

그래서 표의 분류·라우팅 줄은 “무조건 Sonnet”이 아닙니다. 오분류 한 번에 뒤 작업 전체가 틀어지는 라우터라면, 30%를 더 내고 Opus를 쓰는 게 싸게 먹힐 수 있습니다. 반대로 블로그 초안처럼 출력이 긴 작업을 Opus로 돌리면 거의 2배를 내야 해서, 품질 차이가 그만큼 나는지부터 따져야 합니다.

성능 차이는 어디서 나나

저는 코딩에서만큼은 Opus가 확실히 앞설 거라고 생각했습니다. Anthropic이 9월 28일 Sonnet 5.5를 발표하면서 공개한 비교표를 열어 보니 그림이 달랐습니다. 자체 발표 수치이고, 표 안에서도 effort 조건이 줄마다 다르다는 점은 감안해야 합니다.

평가 무엇을 재나 Sonnet 5.5 Opus 5.5 차이
GDPval-AA v2.1 여러 직군의 실제 업무 1844 1846 Opus +2점
AA-Briefcase v1.1 업무 산출물 1811 1822 Opus +11점
Terminal-Bench 4.0 터미널에서 여러 단계 작업 70.6% 66.4% (Xhigh) Sonnet +4.2%p
CursorBench 4.0 실제 Cursor 세션의 모호한 다중 파일 과제 55.5% 57.8% Opus +2.3%p
FrontierCode 1.1 사람 수정 없이 머지될 코드인가 46.2% (Max) 54.4% Opus +8.2%p
OSWorld 2.1 컴퓨터 사용(부분 점수 기준) 80.1% 81.8% Opus +1.7%p

문서·분석 같은 업무형 평가는 사실상 동점입니다. 코딩도 한 방향이 아닙니다. Terminal-Bench는 Opus의 최고 점수(Xhigh)와 비교했는데도 Sonnet이 앞서고, 다중 파일 과제인 CursorBench는 2.3%p 차이입니다.

FrontierCode의 8.2%p가 제일 커 보이지만 조건이 붙어 있습니다. 발표 각주에 따르면 Sonnet 5.5의 46.2%는 Max effort 값이고, Max에서 오히려 Xhigh보다 점수가 낮았습니다. Max에서 리뷰를 서브에이전트로 쪼개다 시간 초과나 범위 밖 수정이 생겼다는 설명입니다. 본문에는 High effort에서 Sonnet 5보다 10점 높다고 적혀 있어서, 같은 effort끼리 비교하면 격차는 표보다 작을 가능성이 큽니다.

그래서 성능 쪽 결론은 이렇습니다. 발표 수치로는 Opus의 우위가 대부분 2~3점 안팎이고, 일부는 뒤집힙니다. 그런데 단가는 2배입니다. 공식 선택 매트릭스는 Opus 5.5를 여러 시간 자율 코딩·대규모 리팩터링·컴퓨터 사용에 두는데, 이건 벤치마크 점수보다 “오래 혼자 돌다 틀리면 손해가 큰 일”에 Opus를 쓰라는 판단으로 읽는 게 맞아 보입니다.

같은 작업 3개를 두 모델에 직접 돌려 보니

10월 4일, 이 글을 고치는 Claude Code 세션에서 서브에이전트를 sonnet과 opus로 각각 지정해 같은 프롬프트 3개를 시켰습니다. 볼트의 에이전트들이 서브에이전트로 불릴 때와 같은 경로입니다(측정은 general-purpose 서브에이전트로 했습니다). 전역 설정이 effortLevel: medium이라 두 모델 모두 medium으로 돌았고, 실행과 기록은 제가 쓰는 AI 에이전트가 했습니다.

작업은 세 종류로 골랐습니다. T1은 파일·웹 도구 없이 푸는 비용 계산(정답이 정해져 있음, 표의 도구 호출 1회는 결과를 돌려주는 호출), T2는 제 볼트에서 에이전트·스킬의 model 설정을 세는 읽기 전용 작업, T3는 사실 다섯 개로 150자 이내 메타 설명을 쓰는 작업입니다.

작업 모델 결과 토큰 시간 도구 호출
T1 비용 계산 Sonnet 5.5 정답 102,959 5.9초 1
T1 비용 계산 Opus 5.5 정답 102,839 6.6초 1
T2 볼트 집계 Sonnet 5.5 정답(106/16/7/0) 119,349 10.7초 2
T2 볼트 집계 Opus 5.5 정답 + 함정 1개 추가 보고 121,020 20.9초 4
T3 메타 설명 Sonnet 5.5 조건 충족, 103자 103,285 8.1초 1
T3 메타 설명 Opus 5.5 조건 충족, 142자 103,705 14.1초 1

첫째로 눈에 띈 건 토큰입니다. 한 줄짜리 계산에도 호출 한 번에 약 10만 토큰이 들었고, 두 모델의 차이는 작업마다 1,700토큰 이하였습니다. 서브에이전트가 뜰 때마다 볼트 규칙을 다시 읽는 고정 바닥이 대부분을 차지하고, 작업 자체의 토큰은 그 안에 묻힙니다. 이 바닥이 캐시 읽기로 처리된다면 두 모델 단가가 $0.20으로 같으니, 짧은 작업의 실제 비용 차이는 위 계산표의 1.3배보다도 작을 수 있습니다. 다만 Agent 결과는 토큰 합계만 보여 줘서 캐시·입력·출력으로 나눈 정확한 달러 금액은 계산하지 못했습니다.

둘째는 시간입니다. Opus가 매번 더 느렸고, 도구를 쓰는 T2에서는 약 1.95배, 글을 쓰는 T3에서는 약 1.73배였습니다. 사람이 기다리는 대화형 작업이라면 이 차이가 단가보다 먼저 체감됩니다.

셋째가 가장 흥미로웠습니다. T2에서 두 모델 모두 지시한 규칙대로 106/16/7/0을 정확히 셌습니다. 그런데 Opus만 “스킬 2개는 model이 frontmatter 최상위가 아니라 metadata: 아래에 들어 있어서 세지 않았다”고 따로 알렸습니다. 파일을 열어 보니 사실이었고, Claude Code 스킬 문서는 metadata를 Claude Code가 내용을 쓰지 않는 자유 형식 칸이라고 설명합니다. 즉 그 두 스킬의 model: sonnet은 처음부터 적용되지 않고 있었습니다. 업계어로 하면 설정 드리프트, 사람말로 하면 “적어 놓긴 했는데 아무도 안 읽는 메모”입니다.

그래서 실측 뒤 판단은 이렇게 정리됩니다. 정답이 정해진 작업에서는 두 모델 결과가 같았고 Sonnet이 더 빨랐습니다. Opus를 쓸 이유는 “더 정확한 답”보다 “시키지 않은 함정을 하나 더 짚어 주는 검토” 쪽에 있었습니다. 감사·리뷰처럼 놓치면 비싼 일에 Opus를 두는 게 이 결과와 맞습니다. 물론 작업당 한 번씩만 돌린 결과라, 우연을 걸러 내려면 같은 작업을 여러 번 반복해야 합니다.

같은 “기본값”이 실행 환경마다 다르다

비교할 때 함정이 하나 더 있습니다. API에서 effort를 안 정하고 부르면 Sonnet 5.5는 high, Opus 5.5는 medium으로 돕니다. 싼 모델이 더 오래 생각하고, 비싼 모델이 덜 생각하는 조합이라 “기본값끼리 비교”가 공정한 비교가 아닙니다.

Claude Code는 또 다릅니다. Claude Code 문서 기준으로 Opus 5.5와 Sonnet 5.5의 기본 effort는 둘 다 medium이고, 설정에 effortLevel이 있으면 그게 먼저 적용됩니다. 제 전역 설정에는 effortLevel: medium이 들어 있어서, 제 sonnet 에이전트 106개는 지금 Sonnet 5.5 medium으로 돈다고 보는 게 맞습니다.

Sonnet 5.5 문서는 effort 단계가 재보정됐다고 적고 있습니다. 같은 medium이어도 Sonnet 5 때와 생각하는 양이 다르니, 예전 설정을 그대로 믿지 말고 다시 재라는 뜻입니다. 에이전트 코딩은 medium에서 시작하고, 어렵고 긴 작업에서 high로 올리라는 게 공식 권장입니다.

바꿀 때는 Sonnet에서 Opus로 올린다

대화 도중에 모델을 바꿀 때 방향이 중요합니다. Sonnet 5.5 문서에 따르면 Claude API와 Google Cloud에서 Opus 5.5는 Sonnet 5.5가 남긴 사고 블록을 읽을 수 있습니다. Sonnet으로 시작했다가 막혀서 Opus로 올리면 앞의 추론이 이어집니다.

반대 방향은 다릅니다. Opus에서 Sonnet으로 내리는 등 다른 이동에서는 읽을 수 없는 사고 블록이 요청에서 빠지고, 전환 뒤 턴은 그 추론 없이 진행됩니다. 요청 자체는 성공하고 빠진 블록은 과금되지 않지만, 앞에서 쌓은 생각의 맥락은 넘어가지 않습니다.

오늘 제 작업 순서가 마침 이 방향이었습니다. 아침 블로그 브리핑은 Sonnet 5.5 세션에서 돌렸고, 이 글을 쓰기 전에 /model claude-opus-5-5로 바꿨습니다. 다만 위 사고 블록 규칙은 API 문서 기준이고, Claude Code의 /model 전환에서도 똑같이 동작하는지는 확인하지 않았습니다.

마이그레이션할 때 걸리는 지점도 있습니다. Sonnet 5.5는 tool_choice를 any나 특정 도구로 강제하면 400 에러가 나고, 사고를 끄려면 disabled 대신 between_tools를 보내야 합니다. Opus 5.5도 도구 강제나 사고 끄기를 쓰는 통합이라면 전환 전에 breaking changes를 먼저 확인하라고 안내합니다.

공식 문서끼리도 기본 추천이 다르다

반론도 남겨 둡니다. Anthropic 모델 개요 첫 문단은 “확실하지 않으면 대부분의 작업은 Opus 5.5로 시작하라”고 합니다. 같은 회사의 가격 페이지 비용 최적화 항목은 “Sonnet은 대부분의 프로덕션 작업, Opus는 가장 복잡한 추론”이라고 합니다.

두 문장은 관점이 다릅니다. 앞의 것은 품질부터 확보하고 나중에 내리라는 capability-first, 뒤의 것은 비용부터 보라는 쪽입니다. 저처럼 에이전트를 여러 개 돌리고 호출 수가 많은 구조라면 Sonnet을 기본으로 두고 필요한 곳만 올리는 쪽이 맞다고 판단했습니다. 처음 만드는 제품이고 품질 기준이 아직 없다면 Opus로 시작하는 쪽도 합리적입니다.

그리고 제 계산은 두 모델이 같은 토큰 수를 쓴다는 가정 위에 있습니다. Opus medium이 Sonnet high보다 생각 토큰을 덜 쓴다면 실제 격차는 표보다 작아질 수 있습니다. 공식 문서도 결국 “내 평가셋으로 직접 비교하라”고 결론 냅니다. 선택 문서에는 모델을 바꾸기보다 effort를 조정하는 게 나은 경우가 많다는 말도 있습니다.

그래서 오늘 할 일

순서 할 일 확인 방법
1 model: sonnet 에이전트가 이제 Sonnet 5.5로 돈다는 걸 인정하기 에이전트 frontmatter의 model 값 집계
2 effort 설정 위치 확인 전역 effortLevel, modelSettings, --effort
3 위 선택표로 작업별 기본 모델 정하기 장시간 자율 작업·실패 비용이 큰 작업만 Opus 후보
4 비용은 출력 길이와 캐시 적중부터 보기 응답 usage의 cache_read_input_tokens, output_tokens
5 같은 작업 3~5개로 두 모델 직접 비교 품질·토큰·시간을 한 표에 기록, 작업당 여러 번 반복
6 스킬의 model이 frontmatter 최상위에 있는지 확인 metadata: 아래에 있으면 적용되지 않음

한계

  • 10월 4일 실측은 작업 3개를 모델마다 한 번씩만 돌린 결과입니다. 같은 시각에 병렬로 돌려서 시간은 서버 상황 영향을 받았을 수 있고, 토큰은 합계만 나와 정확한 비용으로 바꾸지 못했습니다. general-purpose 서브에이전트라 고정 바닥이 커서, 바닥이 작은 구조에서는 모델 차이가 더 크게 보일 수 있습니다.
  • 볼트 에이전트·스킬 집계와 비용 계산은 제가 쓰는 AI 에이전트(Claude Code)가 10월 3일 제 볼트에서 실행한 것입니다. 고정 바닥 47,500토큰은 9월 운영 로그의 추정값이고, 캐시 쓰기 비용은 계산에서 뺐습니다.
  • 벤치마크는 Anthropic 자체 발표이고, 줄마다 effort 조건이 다릅니다(Terminal-Bench의 Opus는 Xhigh, FrontierCode의 Sonnet은 Max). 같은 effort끼리의 비교표는 공개되지 않았습니다.

FAQ — 자주 묻는 질문

Q1. Claude Sonnet 5.5 가격은 얼마인가요?

A: 100만 토큰당 입력 $2, 출력 $10입니다(2026-10-03 공식 가격 페이지 확인). 캐시 읽기는 $0.20, 5분 캐시 쓰기는 $2.50이고 Batch API는 50% 할인입니다. Sonnet 5와 같은 가격입니다.

Q2. Opus 5.5는 Sonnet 5.5보다 몇 배 비싼가요?

A: 입력·출력 단가는 정확히 2배입니다. 캐시 읽기는 둘 다 $0.20이라서, 큰 문맥을 캐시로 읽고 짧게 답하는 호출은 계산상 1.3배 수준까지 차이가 줄어듭니다. 출력이 길거나 캐시가 빗나가면 거의 2배입니다.

Q3. 코딩은 무조건 Opus 5.5가 낫나요?

A: 발표 수치로는 아닙니다. 다중 파일 과제인 CursorBench는 57.8% vs 55.5%로 Opus가 조금 앞서지만, Terminal-Bench는 Sonnet 5.5가 70.6%로 Opus 5.5(Xhigh, 66.4%)보다 높습니다. FrontierCode는 Opus가 8.2%p 앞서지만 Sonnet 쪽이 Max effort 값이라 조건이 다릅니다. 코딩도 Sonnet 5.5로 시작하고, 여러 시간 혼자 돌리는 작업이나 같은 실패가 반복될 때 Opus로 올리는 걸 권합니다.

Q4. Claude Code에서 sonnet이라고 적은 에이전트는 어떤 모델로 도나요?

A: Claude Code 문서 기준으로 Anthropic API를 쓰면 sonnet 별칭은 Sonnet 5.5로 해석됩니다. AWS·Bedrock·Foundry 같은 다른 공급자에서는 다른 버전으로 해석되니 본인 환경의 표를 확인하세요.

Q5. 대화 중간에 모델을 바꿔도 되나요?

A: Claude API와 Google Cloud 기준으로 Sonnet 5.5에서 Opus 5.5로 올리는 방향은 사고 블록이 이어집니다. 반대 방향이나 다른 이동에서는 읽을 수 없는 사고 블록이 빠진 채 진행됩니다.

Q6. 실제로 같은 작업을 시키면 Opus 5.5가 더 잘하나요?

A: 10월 4일 Claude Code 서브에이전트로 작업 3개를 한 번씩 돌린 결과, 정답이 있는 계산·집계는 두 모델 모두 맞혔고 Sonnet 5.5가 더 빨랐습니다. 차이는 Opus 5.5가 시키지 않은 설정 오류(metadata 아래 model) 하나를 더 찾아낸 점이었습니다. 표본이 작아 반복 측정이 필요합니다.

관련 글

참고 자료