Sonnet 5.5 vs Opus 5.5 차이: 작업당 비용과 선택 기준

Claude Sonnet 5.5는 2026년 9월 28일에 나왔고, Opus 5.5는 그보다 엿새 앞선 9월 22일에 나왔습니다. Claude API 정가로 보면 Sonnet 5.5는 새 입력, 출력, 캐시 쓰기가 모두 Opus 5.5의 정확히 절반입니다(100만 토큰당 입력 $2 대 $4, 출력 $10 대 $20). 예외는 하나, 캐시 읽기는 두 모델 모두 $0.20로 같습니다.

그렇다고 "절반 가격"이 "작업당 절반 비용"을 뜻하지는 않습니다. Artificial Analysis가 두 모델을 max effort로 돌린 측정에서 작업 하나당 비용은 Sonnet 5.5 $7.60, Opus 5.5 $5.98로, 오히려 Sonnet이 약 27% 더 들었습니다. 작업 하나에 쓰는 토큰과 턴 수, 그리고 추론 강도(effort)가 단가 차이를 뒤집을 수 있다는 뜻입니다.

결론부터 정리하면 다음과 같습니다.

• 범위가 분명하고 테스트로 결과를 확인할 수 있는 작업(명세가 있는 버그 수정·기능 추가, 반복·대량 처리, 매 PR 1차 리뷰)은 Sonnet 5.5를 medium effort로 시작합니다. Anthropic도 Sonnet 5.5가 작업당 더 싸지는 구간을 low·medium 설정으로 설명합니다.
• 원인이 불분명한 디버깅, 설계 판단, 코드베이스 전체 마이그레이션처럼 열려 있고 오래 걸리는 작업은 Opus 5.5를 기본값 medium으로 시작합니다. 어려운 코드 리뷰에서는 제3자 측정에서도 격차가 뚜렷했습니다.
• Sonnet 5.5를 xhigh·max까지 올려 Opus급 점수를 노리면 비용 이점이 거의 사라집니다. 그 수준이 필요하면 Opus 5.5 medium과 먼저 비교하는 편이 낫습니다.
• 판단이 서지 않으면 Anthropic 모델 개요 문서의 권고대로 Opus 5.5에서 시작하고, 자기 작업으로 Sonnet 5.5를 붙여 통과한 결과 1건당 비용을 비교합니다.

두 모델의 차이 한눈에 보기

아래 표는 2026년 9월 29일 기준 Anthropic 모델 개요와 가격 문서의 Claude API 값입니다. 가격 단위는 미국 달러, 100만 토큰당입니다.

표만으로는 보이지 않는 점이 몇 가지 있습니다.

• 캐시 읽기가 같은 가격인 이유는 요율 구조 때문입니다. 다른 모델은 캐시 읽기를 기본 입력가의 0.1배로 받지만, Opus 5.5에는 0.05배라는 특별 요율이 붙어 $0.20가 됐습니다. Sonnet 5.5는 일반 요율 그대로 $2의 0.1배입니다.
• 두 모델 모두 1M 컨텍스트 전체를 표준 요금으로 받고 장문 할증이 없습니다. 캐시할 수 있는 최소 프롬프트도 둘 다 512토큰입니다.
• Sonnet 5.5 요금은 Sonnet 5와 똑같습니다. 요금표 자체와 청구 금액 확인 방법은 Claude Sonnet 5 가격 인상 취소: 현재 API 요금과 청구 금액 확인법에, Opus 5.5 쪽 청구는 Claude Opus 5.5 가격과 사용량 초기화권에 정리돼 있습니다.
• "Fast / Moderate"는 Anthropic이 붙인 상대적 표기이지 측정값이 아닙니다. 실측으로는 Artificial Analysis의 max effort 측정에서 초당 출력 토큰이 Sonnet 5.5 139개, Opus 5.5 94개였습니다.
• 무료 요금제 줄은 claude.com/pricing 표의 "Sonnet: Yes, Opus: No" 표기입니다. 표에 버전 번호는 없으므로, 무료 계정에서 실제로 Sonnet 5.5가 뜨는지는 앱의 모델 선택 메뉴에서 확인해야 합니다.

토큰 단가는 절반인데 작업당 비용이 뒤집히는 이유

작업당 비용은 단가 × 그 작업에 들어간 토큰입니다. 단가가 절반이어도 토큰이 두 배 넘게 들면 더 비싸집니다. 토큰을 늘리는 요인은 크게 세 가지입니다.

1. effort: 높을수록 오래 생각하고 스스로 검증하므로 출력 토큰이 늘어납니다.
2. 턴 수: 에이전트가 도구를 한 번 더 호출할 때마다 지금까지의 컨텍스트를 다시 읽습니다. 턴이 늘면 캐시 읽기와 새 입력이 함께 쌓입니다.
3. 답의 길이: 같은 결과를 더 길게 쓰는 모델은 출력 비용이 커집니다.

공개된 측정 세 가지를 조건과 함께 보면 이렇습니다.

• Artificial Analysis, 두 모델 모두 max effort: Intelligence Index v4.3.2(평가 10개)에서 Sonnet 5.5는 56점, 작업당 $7.60, 전체 출력 약 4억 1,000만 토큰이었고, Opus 5.5는 58점, 작업당 $5.98, 약 2억 6,000만 토큰이었습니다. 출력 토큰만 보면 Sonnet이 1.58배인데 출력 단가가 절반이니, 출력 비용만으로는 오히려 Opus의 80% 수준이어야 합니다. 그런데도 전체가 27% 더 나왔다면 턴이 늘면서 입력 쪽 토큰까지 불어났다고 보는 편이 자연스럽습니다. "장황해서 비싸다"는 설명만으로는 숫자가 맞지 않습니다.
• Anthropic 자체 설명: Sonnet 5.5 발표문은 Sonnet 5.5가 "낮은 effort 설정에서 작업당 비용이 적어 Opus 5.5를 가장 잘 보완하고, 높은 설정에서는 비슷한 비용으로 비슷한 성능을 낼 수 있다"고 씁니다. low나 medium의 Sonnet 5.5가 여러 벤치마크에서 Sonnet 5의 최고 점수를 약 10분의 1 비용으로 넘었다는 설명도 함께 나옵니다. 다만 effort별 수치는 차트 이미지로만 공개돼 있습니다.
• CodeRabbit, 코드 리뷰 파이프라인: Sonnet 5.5의 리뷰 1건당 Claude 호출 비용은 정가 기준 $0.46~0.47로, Sonnet 5의 $1.16보다 크게 낮았습니다. 같은 글에 Opus 5.5의 건당 비용은 나오지 않습니다.

여기에 기본값 차이가 겹칩니다. Claude API에서 effort를 지정하지 않으면 Sonnet 5.5는 high, Opus 5.5는 medium으로 돕니다. 기본값 그대로 비교하면 Sonnet이 한 단계 높은 설정에서 토큰을 더 쓰는 셈입니다. 반면 Claude Code 문서에 따르면 Claude Code에서는 두 모델 모두 기본 effort가 medium이고, Sonnet 5.5 발표문에 따르면 Claude 앱의 기본값도 Medium입니다. 기본값 불일치는 API를 직접 호출할 때만 생기므로, API로 비교할 때는 effort를 항상 명시해야 합니다.

Sonnet 5.5가 토큰을 몇 배까지 더 써도 싼가

단가 구조가 단순하기 때문에 손익분기점을 직접 계산할 수 있습니다. 한 턴의 비용은 다음과 같습니다(단가는 100만 토큰당).

턴 비용 = 캐시 읽기 토큰 × $0.20 + 새 입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가

Sonnet 5.5는 뒤의 두 항이 절반이고 첫 항은 같습니다. 같은 토큰 수를 넣었을 때 "Opus 비용 ÷ Sonnet 비용"이 곧 Sonnet 5.5가 토큰·턴을 몇 배까지 더 써도 비용이 같아지는지를 나타냅니다. 아래 토큰 수는 계산을 보여 주기 위한 가정값이고 실제 트래픽 측정값이 아닙니다.

캐시 없는 단발 요청이라면 Sonnet 5.5가 토큰을 두 배 가까이 써도 쌉니다. 하지만 큰 코드베이스를 계속 다시 읽는 긴 에이전트 세션처럼 청구액 대부분이 캐시 읽기라면, Sonnet이 25%만 더 써도 비용이 같아집니다. Anthropic도 Opus 5.5 발표에서 캐시 읽기가 에이전트·코딩 작업 비용의 대부분을 차지한다고 설명합니다. 청구액에서 캐시 읽기 비중이 클수록 Sonnet의 가격 이점은 작아집니다. 그 항목이 동가이기 때문입니다.

자기 사용량을 넣어 보려면 아래 함수를 쓰면 됩니다. 캐시 쓰기도 Sonnet이 정확히 절반이므로, 함수에 캐시 쓰기 항목을 더하면 캐시 쓰기가 많은 작업일수록 배수가 2.0 쪽으로 올라갑니다.

# Claude API 정가, 100만 토큰당 USD (2026년 9월 29일 기준, 배치·fast mode 제외)
PRICE = {
    "claude-sonnet-5-5": {"input": 2.00, "output": 10.00, "cache_read": 0.20},
    "claude-opus-5-5":   {"input": 4.00, "output": 20.00, "cache_read": 0.20},
}

def cost(model, cache_read, fresh_input, output):
    p = PRICE[model]
    return (cache_read * p["cache_read"] + fresh_input * p["input"] + output * p["output"]) / 1_000_000

def break_even(cache_read, fresh_input, output):
    """같은 토큰 수에서 Opus 비용 / Sonnet 비용 = Sonnet이 더 써도 되는 배수"""
    return cost("claude-opus-5-5", cache_read, fresh_input, output) / cost("claude-sonnet-5-5", cache_read, fresh_input, output)

print(round(break_even(100_000, 5_000, 6_000), 2))  # 1.78
print(round(break_even(500_000, 2_000, 3_000), 2))  # 1.25

벤치마크: 어디서 따라붙고 어디서 밀리나

아래 수치는 모두 Anthropic의 Sonnet 5.5 발표 표에 실린 벤더 측정값입니다. Opus 5.5 발표문은 따로 표기가 없으면 적응형 thinking의 max effort 결과라고 밝히고 있고, 표의 점수는 대부분 각 모델의 가장 높은 effort에서 나온 값입니다.

읽을 때 조심할 부분이 두 가지 있습니다.

첫째, "Sonnet 5.5가 CursorBench에서 Opus 5.5를 이겼다"는 비교는 조건이 다릅니다. Sonnet 5.5의 55.5%는 최고 점수이고, 그보다 낮은 Opus 5.5의 52.5%는 medium 기본값 결과입니다. 최고 점수끼리 놓으면 Sonnet 5.5가 약 2점 뒤처집니다. Anthropic도 "최고 점수가 Opus 5.5와 약 2점 이내"라고 표현합니다.

둘째, FrontierCode에서 Sonnet 5.5는 Max보다 Xhigh 점수가 높습니다. Anthropic 각주에 따르면 Max에서는 Claude Code의 코드 리뷰 스킬을 더 자주 돌리다가 시간 초과와 범위 밖 수정이 늘었습니다. effort를 끝까지 올린다고 결과가 좋아지는 것은 아닙니다.

Anthropic은 발표문에서 "여러 평가에서 Max effort의 Sonnet 5.5가 Opus 5.5에 버금가지만, 지속적인 판단이 필요한 복잡하고 열린 작업에서는 Opus 5.5가 분명히 더 강하다"고 스스로 선을 긋습니다. 제3자 측정도 같은 방향입니다.

• CodeRabbit의 어려운 코드 리뷰 13건(Elasticsearch, vLLM, Next.js 등 실제 PR에 검증된 버그 하나씩): 알려진 버그를 잡은 비율이 Sonnet 5.5(thinking 켬) 6/13, 실행 가능한 코멘트 정확도 41.2%였습니다. Opus 5.5는 Standard 8/13에 66.7%, Max 10/13에 52.0%였고, Sonnet 5는 4/13이었습니다. Opus 수치는 같은 사례로 9월에 먼저 돌린 결과입니다. CodeRabbit 스스로 13건은 방향을 보는 데 그치고 결론을 내기에는 부족하다고 밝힙니다.
• 같은 CodeRabbit의 Claude Code 병행 빌드 1회: 같은 긴 프롬프트로 앱을 만들게 했더니 Sonnet 5.5가 29분 27초, Opus 5.5가 44분 50초에 끝났습니다. 결과물은 거의 같았고 완성도는 Opus 5.5가 조금 높았습니다. 이 역시 한 번 돌린 결과입니다.

정리하면, 범위가 정해진 작업에서 Sonnet 5.5는 거의 따라붙으면서 1.5배 가까이 빠르고, 놓치면 안 되는 어려운 판단 작업에서는 벤치마크 표보다 격차가 크게 나타납니다.

작업 유형별로 고르는 규칙

표의 effort 출발점은 Anthropic 문서의 권고와 같습니다. Sonnet 5.5 문서는 "에이전트 코딩과 여러 단계 도구 사용에서는 명세가 분명한 작업은 medium, 더 어렵거나 긴 작업은 high, 채팅처럼 지연에 민감한 작업은 medium이나 low"에서 시작하라고 합니다. Opus 5.5는 기본값이 medium이고, Anthropic이 SWE-bench Pro 일부로 잰 결과로는 medium이 high보다 약 2.5점 낮고 비용은 약 70%였습니다. xhigh는 high보다 약 1.4점 높았지만 비용은 2.5배였습니다.

Opus 5.5 high·xhigh로도 모자라면 그다음은 상위 모델입니다. 그 판단은 Claude Fable 5.1 vs Opus 5.5: 코딩·업무용으로 무엇을 선택할까?에서, 다른 회사 모델과의 작업당 비용 비교는 Claude Opus 5.5 vs GPT-6 Sol: 작업당 비용 비교에서 다룹니다.

Claude Code 구독과 API의 판단 기준 차이

API 종량제라면 위 계산이 그대로 청구액이 됩니다. Claude Code를 Pro나 Max 구독으로 쓴다면 토큰 단가가 청구서에 바로 찍히지 않고 사용량 한도가 줄어듭니다. 이때 기준은 결과 품질, 속도, 그리고 한도가 하루 작업을 버티는지입니다. Anthropic 설명대로 Sonnet 5.5는 덜 복잡한 작업을 빠르게 여러 번 고쳐 가는 데 알맞고, Opus 5.5는 놓치면 비싼 어려운 작업에서 강점이 드러납니다.

Anthropic은 Opus 5.5 출시와 함께 Pro, Max, Team, 좌석제 Enterprise의 5시간 사용량 한도를 올렸습니다. 요금제별 한도와 Max가 이득이 되는 지점은 Claude Pro vs Max 2026: 가격, Claude Code 제한, Max 손익분기점에 정리돼 있습니다.

한 작업 안에서 두 모델을 나눠 쓸 때

"Opus가 계획하고 Sonnet이 실행한다"는 분업은 Claude Code에 opusplan이라는 모델 설정으로 이미 들어 있습니다. plan 모드에서는 Opus를, 실행 단계에서는 Sonnet을 씁니다. 토큰 단가만 보면 매력적이지만, 모델을 바꿀 때마다 두 가지 대가가 따릅니다. 대화가 길어 청구액 대부분이 캐시 읽기인 에이전트 작업일수록 이 대가가 단가 차이를 깎아 먹습니다.

전환할 때마다 캐시를 처음부터 다시 읽는다

Claude Code 캐싱 문서에 따르면 프롬프트 캐시는 모델마다 따로 있습니다. /model로 모델을 바꾸면 다음 요청은 내용이 같아도 대화 전체를 캐시 없이 다시 읽고, opusplan에서는 plan 모드를 켜고 끌 때마다 이 일이 일어납니다. 캐시가 살아 있는 동안에는 Claude Code가 전환 전에 확인을 요청합니다.

비용으로 옮기면 이렇습니다. 대화가 200K 토큰까지 쌓였다면 같은 모델로 이어 갈 때는 그 부분이 캐시 읽기 요금으로 $0.04(0.2M 토큰 × $0.20)입니다. 전환 직후에는 최소한 새 입력 단가로 다시 읽어야 하므로 Sonnet 5.5로 넘어가면 $0.40 이상, Opus 5.5로 넘어가면 $0.80 이상이 듭니다. 다시 읽은 내용을 캐시에 새로 쓰면 입력 단가의 1.25배인 5분 캐시 쓰기 요금이 붙어 그보다 더 나올 수 있습니다.

반대로 effort는 바꿔도 캐시가 유지됩니다. Opus 5.5와 Sonnet 5.5를 API 키나 Claude 구독으로 쓸 때 Claude Code에서 effort를 바꾸면 캐시를 그대로 두고 확인 없이 적용합니다(Amazon Bedrock, Google Cloud, Claude apps gateway에서는 해당하지 않음). 세션 도중 "조금 더 깊게" 또는 "조금 더 가볍게"가 필요하면 모델보다 effort를 먼저 바꾸는 편이 쌉니다. API를 직접 쓸 때는 최상위 effort 값을 요청마다 바꾸면 캐시가 무효가 되고, 두 모델 모두 지원하는 메시지 단위 effort 변경(베타)을 쓰면 캐시가 유지됩니다.

이전 모델의 추론은 넘어가지 않는다

Sonnet 5.5는 Sonnet 5, Opus 4.8, Haiku 4.5와 그 이전 모델의 thinking 블록은 읽지만 Opus 5와 Opus 5.5의 블록은 읽지 못합니다. 반대로 Sonnet 5.5가 만든 thinking 블록은 다른 어떤 모델도 읽지 못합니다. 대화 중간에 모델을 바꾸면 API는 읽을 수 없는 블록을 모델에 넘기기 전에 버립니다. 요청은 오류 없이 성공하고 버려진 블록은 과금되지 않지만, 전환 이후의 턴은 이전 모델이 한 추론 없이 진행됩니다.

그래서 계획을 넘기려면 계획을 thinking이 아닌 텍스트로 남겨야 합니다. 계획 파일이나 명시적인 메시지로 적어 두고 실행 모델이 그것을 읽게 하는 방식입니다. Claude Code 문서가 /model 전환 시 thinking 블록 처리를 따로 설명하지는 않지만, API 규칙을 따르면 같은 일이 생긴다고 보는 편이 안전합니다. 또 /model 전환은 메인 모델을 물려받는 서브에이전트에도 적용되므로, 테스트나 조사를 서브에이전트에 맡기기 전에 바꾸면 그 작업도 새 모델로 돕니다.

advisor tool로 분업하기

모델 분업을 API 한 요청 안에서 처리하는 방법으로는 advisor tool(베타)이 있습니다. Sonnet 5.5가 실행자로 대부분의 턴을 돌고, 막히는 결정에서만 Opus 5.5 같은 상위 모델에 조언을 구하는 구조입니다. Claude Code에도 advisor 모드가 있습니다. 주의할 점은 세 가지입니다.

• 조언 내용은 암호화된 advisor_redacted_result 블록으로 돌아와 클라이언트에서 읽을 수 없습니다.
• 실행자의 effort를 너무 낮추면 막혔다는 사실 자체를 알아차리지 못해 조언을 거의 구하지 않을 수 있고, 그러면 실행자 단독보다 점수가 떨어질 수 있다고 Anthropic 비용 가이드는 경고합니다.
• 같은 가이드는 "조언 모델 하나를 low effort로 돌린 비용을 먼저 재라, 그것이 넘어야 할 기준선"이라고 권합니다. Sonnet 5.5 실행자와 Opus 5.5 조언자 조합, 그리고 5.5 모델로 돌린 opusplan의 비용 측정값은 2026년 9월 29일 기준 공개된 것이 없습니다.

Claude Code와 API에서 모델·effort 바꾸기

Claude Code 모델 설정 문서 기준으로 모델과 effort는 다음처럼 바꿉니다.

• 모델: 세션 중에 /model을 입력하면 선택 메뉴가 뜹니다. Enter는 전환과 함께 새 세션의 기본값으로 저장하고, s는 이번 세션에만 적용합니다. /model claude-sonnet-5-5처럼 바로 입력하면 Enter와 같습니다.
• effort: /effort만 입력하면 슬라이더가 열리고, /effort high처럼 단계를 붙이면 바로 적용됩니다. /effort auto는 저장된 값을 지웁니다. /model 메뉴에서 좌우 화살표로도 조절할 수 있습니다. max는 환경 변수로 지정하지 않는 한 현재 세션에만 적용됩니다.
• 확인: 세션 헤더의 모델 이름 옆에 "with low effort"처럼 현재 effort가 표시되고, /status로도 볼 수 있습니다.

# 이번 세션만 모델·effort 지정
claude --model claude-sonnet-5-5 --effort medium
claude --model claude-opus-5-5 --effort high

# 셸 설정 파일(~/.zshrc 등)에 넣으면 그 셸에서 여는 세션마다 적용
export ANTHROPIC_MODEL="claude-sonnet-5-5"
export CLAUDE_CODE_EFFORT_LEVEL="medium"

같은 문서는 medium을 "범위가 분명한 일상 개발 작업(새 기능 구현 등)", high를 "검증이 중요하거나 예외 상황이 많을 작업(기존 코드베이스의 버그 수정 등)"에 권하고, max는 수확이 줄고 과하게 생각하는 경향이 있으니 넓게 쓰기 전에 시험해 보라고 적고 있습니다.

모델 별칭은 조심해야 합니다. sonnet과 opus는 "최신" 모델을 가리키지만 제공처마다 결과가 다릅니다.

Bedrock이나 Google Cloud로 Claude Code를 쓰는 팀이라면 sonnet이나 opusplan을 골라도 실행 모델이 Sonnet 5.5가 아닐 수 있습니다. claude-sonnet-5-5처럼 전체 ID(또는 해당 클라우드의 모델 ID)로 고정해야 비교가 의미를 가집니다.

API에서는 모델 ID와 함께 effort를 반드시 명시합니다. 생략하면 Sonnet 5.5는 high, Opus 5.5는 medium으로 돌아서 같은 조건 비교가 되지 않습니다.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5-5",          # 또는 "claude-opus-5-5"
    max_tokens=16000,
    output_config={"effort": "medium"},  # low / medium / high / xhigh / max
    messages=[{"role": "user", "content": "이 테스트가 실패하는 원인을 찾아 고쳐 줘"}],
)

Opus 5.5는 같은 effort에서도 Opus 5보다 턴마다 더 많이 생각하는 편이라 max_tokens에 여유를 두라는 것이 Anthropic의 안내입니다. Sonnet 5.5는 effort 단계가 Sonnet 5와 다르게 재조정됐으므로, 이전 모델에서 쓰던 effort 값을 그대로 옮기지 말고 다시 맞춰야 합니다.

모델 ID만 바꾸면 깨지는 부분

Sonnet 5나 Opus 5에서 쓰던 코드를 5.5로 옮기거나, 두 5.5 모델 사이를 오갈 때 400 오류가 나거나 조용히 동작이 바뀌는 지점입니다. 각 모델의 What's new 문서(Sonnet 5.5, Opus 5.5) 기준입니다.

이 가운데 가장 놓치기 쉬운 것은 도구 호출 사이 텍스트입니다. 오류가 나지 않기 때문에, 진행 상황을 사용자에게 스트리밍하던 화면이 도구 호출 사이마다 멈춘 것처럼 보이는 현상으로만 드러납니다. 또 Sonnet 5.5의 thinking 블록은 그것을 만든 계정(또는 연결된 계정)에서만 유효합니다. 다른 계정으로 보내면 블록이 버려집니다.

자기 작업으로 작업당 비용 재는 법

2026년 9월 29일 기준 공개된 측정은 max effort 결과이거나 벤더 차트 이미지뿐이고, 두 모델을 같은 medium에서 비교한 작업당 비용 수치는 없습니다. 결국 자기 작업으로 재는 수밖에 없습니다. Anthropic의 비용·성능 최적화 가이드도 토큰당이 아니라 완료된 작업당으로 모델을 비교하라고 권합니다.

1. 작업 고르기: 최근 실제 작업에서 몇십 건을 고르되, 가장 어려운 10%를 반드시 넣습니다. Anthropic 가이드의 표현대로 청구액은 싼 모델이 실패하는 작업에서 결정됩니다. 실패한 작업도 토큰은 청구되고, 그 뒤에 재시도 비용이 붙습니다.
2. 조건 고정: Sonnet 5.5 medium, Opus 5.5 medium을 기본으로 하고, 여유가 있으면 Sonnet 5.5 high를 추가합니다. effort는 코드에 명시합니다.
3. 사용량 기록: 응답의 usage에서 input_tokens, cache_creation_input_tokens, cache_read_input_tokens, output_tokens를 저장해 위의 단가로 환산합니다.
4. 통과 판정: 테스트나 검증 스크립트처럼 사람 판단이 끼지 않는 기준을 씁니다.
5. 계산: 통과한 결과 1건당 비용 = 실패를 포함한 전체 비용 ÷ 통과 건수. 결과를 검토하고 고치는 데 든 사람 시간도 옆에 적어 둡니다.

결과가 검증 가능하다면 "모두 낮은 effort로 돌리고 실패한 것만 high로 다시 돌리는" 정책도 함께 비교해 볼 만합니다. Anthropic이 Opus 5.5로 SWE-bench Pro 일부를 계산한 결과, low로 돌린 뒤 실패한 13%만 high로 재실행하자 약 97%가 통과했고 작업당 약 $0.17이 들었습니다. 전부 high로 돌렸을 때는 95.3% 통과에 $0.29였습니다. Opus 5.5 기준 측정이며 Sonnet 5.5 수치는 공개되지 않았습니다.

판정은 간단합니다. Sonnet 5.5의 통과율이 비슷하고 1건당 비용이 낮으면 기본값을 Sonnet 5.5로 둡니다. 실패가 가장 어려운 10%에만 몰린다면 그 유형만 Opus 5.5로 보내면 됩니다. Sonnet 5.5가 통과를 위해 effort를 high 이상으로 올려야 하고 비용이 Opus 5.5 medium과 비슷해진다면, 속도가 급하지 않은 한 Opus 5.5 쪽이 낫습니다.

자주 묻는 질문

무료 요금제에서도 Sonnet 5.5를 쓸 수 있나요?

claude.com/pricing 표 기준으로 Free 요금제는 Sonnet과 Haiku를 쓸 수 있고 Opus는 쓸 수 없습니다. 표에 버전이 적혀 있지 않으므로 Sonnet 5.5인지는 앱의 모델 메뉴에서 확인해야 합니다. Opus 5.5를 쓰려면 Pro(월 $20, 연간 결제 시 월 $17) 이상에 가입해야 하고, Max는 월 $100부터입니다.

Sonnet 5에서 Sonnet 5.5로 바꾸면 비용이 늘어나나요?

토큰 단가는 완전히 같습니다. Anthropic은 Sonnet 5.5가 같은 일을 훨씬 적은 토큰으로 처리해 작업당 최대 30% 싸고, 출력 속도는 30% 이상 빠르다고 설명합니다. 다만 effort 단계가 재조정됐고 thinking 끄기, 강제 도구 호출, 샘플링 파라미터에서 400 오류가 날 수 있으니 위의 호환성 표를 먼저 점검해야 합니다.

보안 관련 작업 중에 모델이 저절로 바뀌었어요

Claude 앱에서는 안전 장치에 걸린 요청이 다른 모델로 넘어갑니다. Sonnet 5.5는 익스플로잇 작성, 바이너리 기반 취약점 스캔, 침투 테스트처럼 위험도가 높은 공격형 보안 요청과 일부 최첨단 LLM 개발 요청을 Sonnet 5로 넘기고, 생물학 관련 요청과 내부 추론을 뽑아내려는 요청은 아예 차단합니다. Opus 5.5는 보안 요청을 Opus 4.8로 넘깁니다. 한 번 넘어가면 직접 되돌리기 전까지 그 대화는 대체 모델에 머뭅니다(Claude 도움말: Sonnet 5.5 대화에서 모델이 바뀐 이유). Claude Code에서도 같은 분류기에 걸리면 요청을 대체 모델로 다시 실행하고 세션이 그 모델에서 이어지며, 이 역시 모델 전환이라 캐시를 새로 읽습니다. 소스 코드에서 취약점을 찾는 일상적인 보안 작업은 Sonnet 5.5에 그대로 남습니다. API에서는 stop_reason: "refusal"로 응답이 옵니다.

한국에서 두 모델을 바로 쓸 수 있나요?

Anthropic의 지원 국가 목록에 대한민국이 포함돼 있어 Claude 앱과 Anthropic API 모두 쓸 수 있습니다. AWS(Amazon Bedrock에서는 anthropic.claude-sonnet-5-5, anthropic.claude-opus-5-5), Google Cloud, Microsoft Foundry에서도 같은 모델을 제공하며, 이 경우에는 각 클라우드의 약관과 리전 조건을 따릅니다.

Haiku 5.5는 언제 나오나요?

Anthropic은 Sonnet 5.5 발표에서 대량·비용 민감 작업용 Claude Haiku 5.5가 "앞으로 몇 주 안에" 5.5 제품군에 합류한다고만 밝혔고, 날짜는 공개하지 않았습니다. 반복·대량 처리에서 Sonnet 5.5 low도 비싸다면 Haiku 5.5 출시 뒤 한 번 더 비교해 볼 만합니다.