Sonnet 5.5 vs Opus 5.5: 어떤 코딩 작업에 Opus가 필요할까?
버그 수정, 코드 리뷰, 복잡한 변경에서 Sonnet 5.5와 Opus 5.5를 고르는 방법을 설명합니다. 작업 범위와 effort, 캐시 요금, 판단 근거를 함께 비교합니다.
Ofox 
요구사항이 분명한 코딩 작업은 Sonnet 5.5부터 평가하고, 판단이 어렵거나 모호하거나 실패가 반복되는 작업에는 Opus 5.5도 포함하세요. 이는 평가 대상을 고르는 방법입니다. Sonnet이 작은 작업을 항상 해결하거나 Opus가 큰 작업에서 항상 이긴다는 증거는 아닙니다. 합격 기준은 저장소 테스트와 리뷰 기준입니다.
Anthropic은 Sonnet을 더 빠르고 저렴하게 Opus를 보완하는 모델로, Opus를 신중한 판단이 필요한 복잡한 작업에 적합한 모델로 설명합니다. 하지만 과금과 effort 설정을 고려하면 단순히 “Sonnet은 반값”이라고 결정할 수 없습니다. 이 글은 2026년 9월 29일 확인한 문서를 바탕으로 하며 자체 대결 실험을 주장하지 않습니다.
단가만으로 결정할 수 없는 이유
| 공식 Claude API 항목 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|
| 입력 100만 토큰당 | $2 | $4 |
| 출력 100만 토큰당 | $10 | $20 |
| 캐시 읽기 100만 토큰당 | $0.20 | $0.20 |
| API 기본 effort | high | medium |
| 컨텍스트 창 | 1M토큰 | 1M토큰 |
출처: Sonnet 사양, Opus 사양. 공급사 단가이며 구독 한도나 Ofox 견적이 아닙니다. 저장소 문맥을 반복해서 쓸 때는 캐시 읽기 행이 중요합니다. 큰 접두부를 캐시에서 읽는 비용에는 캐시 없는 입력·출력과 같은 2배 차이가 없습니다.
캐시 읽기 100,000토큰과 과금 대상 출력 2,000토큰이 같고, 다른 모든 과금 항목은 제외한 가상 요청을 생각해 보겠습니다. Sonnet은 0.04달러, Opus는 0.06달러입니다. 이 예에서는 캐시 읽기 단가가 같아 비용이 2배가 아닙니다. 한 모델이 더 많은 턴을 사용하면 비교 결과는 다시 달라집니다.
작업을 검증 가능한 결과와 연결하기
| 작업 | 비교를 시작하는 방법 | 남길 증거 |
|---|---|---|
| 확실한 재현 절차가 있는 버그 | Sonnet의 낮은 편 effort부터, 필요하면 Opus | 실패 테스트, 패치, 전체 회귀 테스트 |
| 요구사항이 명확한 작은 기능 | Sonnet과 현재 작동하는 기준 구성 | 합격 체크리스트, 수정 범위 |
| 여러 모듈에 걸친 모호한 장애 | 처음부터 Opus도 포함 | 대안 가설, 확인 파일, 검증된 원인 |
| 저장소 리뷰 | 두 모델에 같은 범위 제공 | 확인된 지적과 오탐 |
| 위험도가 높은 마이그레이션 | 계획과 검증을 분리해 비교 | 마이그레이션 체크리스트, 롤백 경로, 통합 테스트 |
이는 실험 설계이며 측정된 통과율이 아닙니다. 짧은 패치도 어려운 추론이 필요할 수 있고, 길지만 기계적인 변경은 쉬울 수 있습니다. 파일 수나 수정 줄 수만으로 난이도를 판단하기 어렵습니다.
벤치마크는 조건과 함께 읽기
Artificial Analysis의 Sonnet 출시 보고서는 여러 작업에서 좋은 결과를 보고하면서도 max에서 출력 소비가 훨씬 많다고 설명합니다. 테스트한 출시 전 환경의 구조화 출력 문제와 재평가 계획도 명시합니다. 두 모델을 시험할 이유는 되지만 내 작업에 가장 싼 구성을 확정하지는 못합니다.
Opus medium과 Sonnet max를 비교한 결과를 순수한 모델 차이라고 부르면 안 됩니다. 설정을 포함한 비교입니다. 그 자체로 유용할 수는 있지만 양쪽 설정과 실제 예산을 공개해야 합니다. effort 이름이 같아도 계산량이 같다는 보장은 없습니다.
Anthropic의 출시 발표도 모델별 강점과 평가 조건을 설명합니다. 공급사의 주장, 독립 측정, 자체 관찰을 분리하세요. 차트가 다르게 보이는 이유는 작업이나 설정의 차이일 수 있습니다.
간단한 모델 전환 기준
실행 전에 중단 조건을 정합니다. 예를 들어 수정안 하나를 만든 뒤 회귀 테스트를 수행하도록 합니다. 실패하면 다시 실행하기 전에 실패 원인을 살펴보세요. 모델이 작업을 잘못 이해했다면 effort를 무작정 올리지 말고 입력을 명확히 해야 합니다. 문제 위치는 찾았지만 유효한 수정에 실패했다면 Opus를 통제된 조건에서 시험할 이유가 있습니다.
새 실행에 이슈 설명, 관련 파일, 테스트 결과를 전달하세요. 암호화된 thinking 블록을 모델 간에 옮길 수 있다고 가정하면 안 됩니다. Sonnet 5.5의 모델·대화별 규칙은 마이그레이션 가이드에 정리돼 있습니다. 숨겨진 추론의 연속성에 의존하지 말고 눈에 보이는 증거를 보존하세요.
처음 시도와 전환 후 시도의 비용을 합쳐 기록합니다. 첫 실패는 한 모델에 돌리고 마지막 성공만 다른 모델에 계산하면 라우팅 시스템이 실제보다 저렴해 보일 수 있습니다. 리뷰 시간도 남기세요. 컴파일되지만 많은 정리가 필요한 패치는 아직 끝난 작업이 아닙니다.
구독으로 사용할 때
API 요금표를 Claude Code에서 보낼 수 있는 정확한 프롬프트 수로 환산하지 마세요. 구독 사용량과 한도는 계정 및 서비스 조건에 따라 달라집니다. 클라이언트 업데이트나 공급사 변경 뒤에는 실제 선택 모델을 확인하고 과금 방식과 모델 이름을 구분하세요.
Claude Code 설정 가이드는 버전 확인과 명시적 선택을 다룹니다. Effort 가이드에서는 API와 Claude Code 기본값을 구분합니다. 다른 공급사 모델도 고려한다면 Sonnet과 Sol 비교의 통제된 평가 방법을 참고하세요.
자주 묻는 질문
- Sonnet은 항상 Opus 비용의 절반인가요?
- 아니요. 캐시 없는 입력·출력 공시 단가는 절반이지만 캐시 요금, 토큰 소비, 재시도, 도구가 완료 비용에 영향을 줍니다. 위 계산 예제는 그 차이를 분리해 보여 줍니다.
- 코드 리뷰에는 항상 Opus를 써야 하나요?
- 문서에서 그런 보편적 규칙을 도출할 수는 없습니다. 대표 리뷰에서 확인된 지적과 오탐, 각 지적을 사람이 검증하는 시간을 비교하세요.
- 같은 대화를 모델 사이에 옮길 수 있나요?
- 지원되는 흐름에서는 보이는 메시지를 넘길 수 있지만 thinking 블록에는 호환성 규칙이 있습니다. 숨겨진 상태 전체가 이전된다고 가정하지 말고 마이그레이션 문서를 확인하세요.
