Sonnet 5의 표면 가격은 Sonnet 4.6보다 낮습니다(2026년 8월 31일까지의 도입 가격 $2/$10, Sonnet 4.6의 $3/$15 대비). 또한 Anthropic의 자체 출시 차트에서는 이를 Sonnet 4.6에 대한 "strict improvement"라고 부릅니다. 우리는 실제로 그 의미가 무엇인지 알아보기 위해 여러 effort 수준에서 같은 task에 두 모델을 모두 실행해 보았습니다. 결과: 우리의 test에서는 Sonnet 5가 시도한 모든 effort 수준에서 Sonnet 4.6보다 더 많은 비용이 들었습니다 — 더 적게가 아니라. 여기서 무엇을 발견했는지와 그 이유를 설명합니다.
하나의 작업, 단일 실행. 아래의 모든 내용은 하나의 코딩 작업에서 나온 것으로, 모델/노력 구성별로 한 번씩 실행한 결과입니다. 구체적인 수치는 통계적으로 평균화된 벤치마크가 아니라 방향성을 보여주는 값으로 보시기 바랍니다. 직접 자신의 워크로드에서 재현하고 싶다면, 정확한 프롬프트와 원시 API 출력 샘플이 부록에 있습니다.
Sonnet 5가 실제로 Sonnet 4.6보다 더 저렴할까? 직접 테스트해 봤습니다.
두 모델 모두에게 동일한 작업을 주었습니다 — Python으로 token-bucket rate limiter를 테스트와 함께 구현하고, 테스트를 실행한 뒤, 실패하는 부분을 수정하는 것 — Claude Code CLI(claude -p --model <id> --effort <level> --output-format json)를 통해 수행했으므로, 비용과 소요 시간은 API 응답에서 바로 가져옵니다. 2026-07-01에 실행.
설정 | 비용 | 기간 | 턴 수 | 결과 |
|---|---|---|---|---|
Sonnet 5, effort | $0.344 | 31.6s | 5 | 6/6 tests pass |
Sonnet 4.6, effort | $0.261 | 36.0s | 6 | 7/7 tests pass |
Sonnet 4.6, effort | $0.253 | 35.3s | 5 | 7/7 tests pass |
Sonnet 5, effort | $0.349 | 36.4s | 5 | 8/8 tests pass |
Sonnet 5는 medium 노력에서 더 빨랐지만, 우리가 테스트한 Sonnet 4.6의 두 구성 모두에서 Sonnet 4.6보다 더 비쌌습니다 — 더 낮은 노력 설정으로 실행된 Sonnet 4.6까지 포함해서요. 이는 같은 노력 등급끼리 비교하면 Sonnet 5가 Sonnet 4.6보다 더 저렴해진다고 주장하는 일부 커뮤니티의 일화적 보고와는 정반대입니다.
가장 가능성이 높은 원인: Sonnet 5는 새로운 tokenizer에서 실행됩니다. Anthropic의 공식 문서에 따르면, 동일한 텍스트에 대해 Sonnet 4.6보다 "약 30% 더 많은 tokens"를 생성합니다. 또한 Simon Willison의 독립 테스트에서는 특히 영어 콘텐츠가 최대 약 1.4배 더 많은 tokens를 사용하는 것으로 나타났습니다. Sonnet 5의 더 낮은 표기 가격은 우리의 테스트 작업에서 그 차이를 완전히 상쇄하지 못했고, 2026년 8월 31일 이후 — Sonnet 5의 도입 가격이 만료되고 두 모델의 표기 요금이 동일한 $3/$15가 되는 시점 — tokenizer 차이만으로도 다른 가격 변동이 없다면 동등한 영어 작업에서 Sonnet 5가 동일한 비용이 아니라 더 비쌀 가능성이 높음을 시사합니다. (언어별 전체 분석은 우리의 Sonnet 5 가격 가이드를 참고하세요.)
비용 외에 또 무엇이 바뀌었나
공식 벤치마크에서 Sonnet 5는 실제 향상을 보입니다: Terminal-Bench 2.1에서 80.4% 대 67.0%, SWE-bench Pro에서 63.2% 대 58.1%이며, 이는 모두 Anthropic의 Claude Sonnet 5 system card를 기준으로 합니다(Opus 4.8을 포함한 전체 벤치마크 표 참조). Anthropic의 출시 발표 차트에서도 Sonnet 5를 Sonnet 4.6보다 "strict improvement"라고 설명합니다.
우리의 네 가지 테스트 출력만 살펴보면, 벤치마크 표에는 드러나지 않는 한 가지 행동상의 차이가 눈에 띄었습니다: Sonnet 5는 요청하지 않은 것들을 추가했습니다. 두 노력 수준 모두에서 테스트에서 monkeypatched된 가짜 시계를 사용해 실제 time.sleep() 호출을 피했고, high 노력에서는 요청받지 않았는데도 rate limiter에 스레드 안전성을 추가했습니다. Sonnet 4.6은 두 노력 수준 모두에서 더 문자 그대로의 작업 설명에 가까웠습니다 — 테스트에서는 실제 time.sleep()을 사용했고, medium 노력에서는 가독성을 위해 요약 표를 추가했지만 실제 구현에는 요청된 것 외에 아무것도 추가하지 않았습니다.
이는 Sonnet 5 출시 첫날에 게시된 실제 사용자 피드백과도 일치합니다. 한 r/claude 스레드에서는 이를 "추론 측면에서는 Sonnet 4.6보다 객관적으로 더 나은 업그레이드지만... 4.6보다 훨씬 더 예민하게 느껴지기도 한다"고 설명했습니다. 우리의 테스트는 하나의 작업에 대한 표본이지만, "요청되지 않은 범위를 더 쉽게 추가한다"는 표현은 바로 그 관찰을 구체적이고 명확하게 풀어쓴 버전입니다.
업그레이드해야 할까요?
업그레이드하세요 당신의 작업 부하가 주로 중국어라면(토크나이저 변경은 중국어 토큰 수에 거의 영향을 주지 않습니다), 또는 Terminal-Bench와 SWE-bench의 성능 향상이 약간의 비용 증가보다 더 중요한 에이전트/도구 중심 작업을 하고 있다면.
잠시 보류하세요 당신의 작업 부하가 대량 처리 중심이고 영어 비중이 높으며, Sonnet 4.6이 이미 품질 기준을 충족하고 있다면 — 특히 2026년 8월 31일에 도입 가격 기간이 끝난 뒤에는, 표시 가격을 그대로 믿기보다 직접 비용 계산을 다시 해보세요.
어쨌든, 더 새롭고 더 저렴해 보이는 모델이 작업당 비용도 자동으로 더 낮을 것이라고 가정하지 마세요. 우리 테스트에서는 그렇지 않았습니다.
자주 묻는 질문
Anthropic이 말하듯이, Sonnet 5는 정말로 Sonnet 4.6보다 “엄격한 개선”인가요?
Anthropic가 발표한 capability benchmarks에서는, 네 — Sonnet 4.6이 앞서는 항목은 찾지 못했습니다. 작업당 비용에서는, tokenizer 변경을 반영하면 저희 테스트에서는 오히려 반대 결과가 나왔기 때문에, “strict improvement”가 모든 workload에 대한 cost-efficiency까지 확장되지는 않습니다.
왜 Sonnet 5는 Sonnet 4.6보다 "더 긴장된" 느낌이 드나요?
Anthropic은 이에 대한 구체적인 내용을 공개하지 않았습니다. 저희 자체 테스트 결과를 보면, Sonnet 5는 Sonnet 4.6보다 요청되지 않은 범위(스레드 안전성, 더 방어적인 테스트 시계 설정)를 더 기꺼이 추가하려는 경향이 있었고, Sonnet 4.6은 문자 그대로의 요청에 더 가깝게 유지되었습니다. 이는 커뮤니티의 설명과 일치하지만, 그보다 범위는 더 좁습니다.
Sonnet 5가 이제 기본 모델인가요? Sonnet 4.6도 계속 사용할 수 있나요?
Anthropic의 출시 발표에 따르면, Sonnet 5는 claude.ai에서 Free 및 Pro 사용자의 기본 모델로 Sonnet 4.6을 대체했습니다. Max, Team 및 Enterprise 사용자와 API 사용자는 여전히 Sonnet 4.6을 직접 선택할 수 있습니다.
Sonnet 5를 Sonnet 4.6과 비교해야 하나요, 아니면 Opus 4.8과 비교해야 하나요?
완전히 다른 선택입니다. 이 페이지는 세대 업그레이드에 대한 내용입니다. 특히 Sonnet 5와 Opus 4.8 사이에서 선택하고 있다면, 저희는 별도의 일대일 테스트 세트를 진행했습니다 — Sonnet 5 vs Opus 4.8: 실제 테스트를 보세요.
온라인에 올라오는 “더 높은 노력 단계가 더 싸다”는 주장은 정말인가요?
우리 테스트에서는 그렇지 않았습니다. 우리는 Sonnet 5를 medium 및 high에서 Sonnet 4.6의 low 및 medium과 비교해 실행했으며, Sonnet 5는 모든 조합에서 비용이 더 많이 들었습니다. 개별적인 경험담은 작업에 따라 다릅니다 — 특정 effort-level 교차점을 가정하기 전에 실제 워크로드에서 직접 비교해 보세요.
부록: 정확한 프롬프트와 원본 출력
우리가 두 모델 모두에게 보낸 작업:
토큰 버킷 속도 제한기를 Python 클래스 `RateLimiter(capacity: int,
refill_rate: float)`로 구현하고, `allow() -> bool` 메서드를 추가하세요. 이 메서드는 요청이
지금 허용되는지 반환해야 하며, 허용된다면 토큰 하나를 소비해야 합니다. 단조 시계(monotonic clock)를 사용하고, 외부
의존성은 사용하지 마세요. 이를 limiter.py에 저장하세요.
그다음 test_limiter.py를 작성하세요. 다음을 포함하는 최소 5개의 테스트 케이스가 있어야 합니다: 용량까지의 연속 요청은
성공한 뒤 차단됨, 시간이 지나면 토큰이 보충됨(time.sleep 또는 mock 가능한 clock 사용),
보충 속도가 준수됨(즉시 전체 회복되지 않음), 용량을 절대 초과하지 않음, 그리고
0/음수 용량이 적절하게 처리됨.
pytest로 테스트를 실행하고 모두 통과하는지 확인하세요. 실패가 있으면 코드를 수정하고
모두 통과할 때까지 다시 실행하세요. 최종 pytest 출력을 보고하세요.
Sonnet 5 (medium) 실행에 대한 실제 API 응답이며, 비용과 시간에 관련된 필드만 추린 것입니다:
{
"duration_ms": 31616,
"num_turns": 5,
"stop_reason": "end_turn",
"total_cost_usd": 0.3438645,
"usage": {
"input_tokens": 4302,
"cache_creation_input_tokens": 60894,
"cache_read_input_tokens": 233420,
"output_tokens": 2172
}
}