Sonnet 5.5 vs Opus 5.5: 어떤 코딩 작업에 Opus가 필요할까?

요구사항이 분명한 코딩 작업은 Sonnet 5.5부터 평가하고, 판단이 어렵거나 모호하거나 실패가 반복되는 작업에는 Opus 5.5도 포함하세요. 이는 평가 대상을 고르는 방법입니다. Sonnet이 작은 작업을 항상 해결하거나 Opus가 큰 작업에서 항상 이긴다는 증거는 아닙니다. 합격 기준은 저장소 테스트와 리뷰 기준입니다.

Anthropic은 Sonnet을 더 빠르고 저렴하게 Opus를 보완하는 모델로, Opus를 신중한 판단이 필요한 복잡한 작업에 적합한 모델로 설명합니다. 하지만 과금과 effort 설정을 고려하면 단순히 “Sonnet은 반값”이라고 결정할 수 없습니다. 이 글은 2026년 9월 29일 확인한 문서를 바탕으로 하며 자체 대결 실험을 주장하지 않습니다.

단가만으로 결정할 수 없는 이유

출처: Sonnet 사양, Opus 사양. 공급사 단가이며 구독 한도나 Ofox 견적이 아닙니다. 저장소 문맥을 반복해서 쓸 때는 캐시 읽기 행이 중요합니다. 큰 접두부를 캐시에서 읽는 비용에는 캐시 없는 입력·출력과 같은 2배 차이가 없습니다.

캐시 읽기 100,000토큰과 과금 대상 출력 2,000토큰이 같고, 다른 모든 과금 항목은 제외한 가상 요청을 생각해 보겠습니다. Sonnet은 0.04달러, Opus는 0.06달러입니다. 이 예에서는 캐시 읽기 단가가 같아 비용이 2배가 아닙니다. 한 모델이 더 많은 턴을 사용하면 비교 결과는 다시 달라집니다.

작업을 검증 가능한 결과와 연결하기

이는 실험 설계이며 측정된 통과율이 아닙니다. 짧은 패치도 어려운 추론이 필요할 수 있고, 길지만 기계적인 변경은 쉬울 수 있습니다. 파일 수나 수정 줄 수만으로 난이도를 판단하기 어렵습니다.

벤치마크는 조건과 함께 읽기

Artificial Analysis의 Sonnet 출시 보고서는 여러 작업에서 좋은 결과를 보고하면서도 max에서 출력 소비가 훨씬 많다고 설명합니다. 테스트한 출시 전 환경의 구조화 출력 문제와 재평가 계획도 명시합니다. 두 모델을 시험할 이유는 되지만 내 작업에 가장 싼 구성을 확정하지는 못합니다.

Opus medium과 Sonnet max를 비교한 결과를 순수한 모델 차이라고 부르면 안 됩니다. 설정을 포함한 비교입니다. 그 자체로 유용할 수는 있지만 양쪽 설정과 실제 예산을 공개해야 합니다. effort 이름이 같아도 계산량이 같다는 보장은 없습니다.

Anthropic의 출시 발표도 모델별 강점과 평가 조건을 설명합니다. 공급사의 주장, 독립 측정, 자체 관찰을 분리하세요. 차트가 다르게 보이는 이유는 작업이나 설정의 차이일 수 있습니다.

간단한 모델 전환 기준

실행 전에 중단 조건을 정합니다. 예를 들어 수정안 하나를 만든 뒤 회귀 테스트를 수행하도록 합니다. 실패하면 다시 실행하기 전에 실패 원인을 살펴보세요. 모델이 작업을 잘못 이해했다면 effort를 무작정 올리지 말고 입력을 명확히 해야 합니다. 문제 위치는 찾았지만 유효한 수정에 실패했다면 Opus를 통제된 조건에서 시험할 이유가 있습니다.

새 실행에 이슈 설명, 관련 파일, 테스트 결과를 전달하세요. 서명된 thinking 블록을 모델 간에 옮길 수 있다고 가정하면 안 됩니다. Sonnet 5.5의 모델·대화별 규칙은 마이그레이션 가이드에 정리돼 있습니다. 숨겨진 추론의 연속성에 의존하지 말고 눈에 보이는 증거를 보존하세요.

처음 시도와 전환 후 시도의 비용을 합쳐 기록합니다. 첫 실패는 한 모델에 돌리고 마지막 성공만 다른 모델에 계산하면 라우팅 시스템이 실제보다 저렴해 보일 수 있습니다. 리뷰 시간도 남기세요. 컴파일되지만 많은 정리가 필요한 패치는 아직 끝난 작업이 아닙니다.

세 가지 토큰 구성으로 비용 비율 계산하기

같은 두 모델도 작업 구성에 따라 비용 비율이 달라집니다. 다음은 토큰 수를 같게 고정하고 표준 서비스의 정가로 계산한 합성 사례입니다. 다른 비용은 제외하며 모델 행동보다 과금 차이를 먼저 분리합니다.

Opus의 5분·1시간 캐시 생성 요율은 백만 토큰당 $5·$8이며 Sonnet은 $2.50·$4입니다. 각 모델에 100K짜리 5분 캐시를 한 번 쓰고 아홉 번 읽으며 열 번 모두 2K를 출력하면 Sonnet 소계는 $0.63, Opus는 $1.08입니다. Sonnet은 생성 $0.25 + 읽기 $0.18 + 출력 $0.20, Opus는 $0.50 + $0.18 + $0.40입니다. 약 1.71배로, 항상 2배가 아닙니다.

모델을 바꿔도 이전 캐시를 이어 쓴다고 가정하지 마세요. 이 사례는 모델별 첫 쓰기를 각각 계산합니다. 실제 토큰 수와 재사용도 달라질 수 있습니다. 저렴한 모델이 두 배의 시도를 요구하면 단가 이점이 사라질 수 있습니다. 비싼 모델도 설명만 길어지고 같은 실패 패치를 내면 적절한 선택이 아닙니다.

어떤 어려움이라면 Opus를 일찍 포함할까?

난도는 수정 크기보다 올바른 동작의 불확실성에서 나올 때가 많습니다. 권한 검사 한 줄이 30개 파일의 API 이름 변경보다 신중한 판단을 요구할 수 있습니다. Anthropic의 포지셔닝은 오래 걸리고 판단이 필요한 일에 Opus를 후보로 넣을 근거가 되지만, 특정 한 줄 버그에 반드시 Opus가 필요하다는 보장은 아닙니다.

근본 원인이 아직 불명확한가, 요구사항이 충돌하는가, 결과가 비싼 부작용을 낼 수 있는가, 검수가 정답 대조보다 대안 평가를 요구하는가를 물어보세요. 여러 항목이 맞으면 패치를 채택하기 전에 두 번째 설정을 시험할 이유가 됩니다. 도구 권한을 넓힐 이유는 아닙니다.

실패하는 스냅샷 테스트가 있는 국소적인 서식 버그는 Sonnet으로 시작하고 해당 테스트와 주변 회귀를 요구할 수 있습니다. 결제 재시도가 중복 청구를 일으킬 수 있다면 멱등성, 부분 실패, 복구를 검수에 포함해야 합니다. 필요하면 Opus도 조사에 참여시키되 민감한 수정은 픽스처와 사람의 검토를 사용합니다. 더 강한 모델이 외부 부작용의 격리를 대신하지는 않습니다.

아키텍처 작업은 두 후보에게 제약, 대안, 되돌릴 수 있는 이전 절차를 요구하세요. 자신 있게 그린 그림이 아니라 실제 코드와 배포 제약에 맞는지 판단합니다. 관련 모듈 참조와 중간 상태도 유효한 구현 순서를 요구합니다. 입력이 부족하다면 견해 차이를 모델 약점으로 보기 전에 먼저 보충하세요.

첫 시도 전에 상위 모델 전환 예산 정하기

간단한 정책은 범위를 정한 Sonnet 한 번, 실패 진단 한 번, 그다음 설명 보완과 Opus 중 의도적으로 선택하는 방식입니다. 같은 프롬프트를 무한 재시도하지 마세요. 의존성이 없거나 픽스처가 깨졌다면 모델 변경으로 환경이 고쳐지지 않습니다. 환경부터 수정하고 추론 실패와 별도로 기록합니다.

Sonnet 한 번이 $0.06, Opus 추가 시도가 $0.12이며 추가는 한 번까지만 허용한다고 가정합시다. 전환이 필요한 비율이 e이면 제출 작업당 평균 토큰 비용은 $0.06 + $0.12e입니다. e = 25%이면 $0.09, 50%이면 $0.12로 처음부터 Opus 한 번을 쓰는 가정과 같습니다. 50%를 넘으면 이 라우팅은 직접 Opus 기준선보다 비쌉니다.

이는 통과율 예측이 아닙니다. 성공률 차이, 맥락 준비, 캐시 상태, 리뷰, 지연은 제외했습니다. Opus도 실패하거나 턴을 더 쓰면 비용을 추가해야 합니다. 합격 작업 비용과 미해결 비율을 같이 보고하세요. 급한 일에서는 중요한 작업마다 추가 단계로 지연된다면 낮은 평균 비용도 나쁜 정책일 수 있습니다.

두 번째 모델에게 검증 가능한 자료 넘기기

의도한 동작, 현재 commit, 재현 명령, 실제 실패, 시도한 패치, 반려 이유를 짧게 정리하세요. 관련 파일이나 다음 실행이 접근할 수 있는 참조만 포함합니다. 원인이 불명확하다면 패치를 바꾸기 전에 원인을 설명하도록 해서 이미 틀린 것으로 확인한 가정을 반복하지 않게 합니다.

“이전 모델이 X라고 했으니 X가 맞다”는 자료가 되면 안 됩니다. 실제 테스트 출력과 모델 해석을 구분하세요. 첫 시도가 파일을 수정했다면 동일 기준선으로 되돌리거나 다른 시작 상태를 명확히 기록합니다. 그렇지 않으면 Opus의 겉보기 성공은 Sonnet이 먼저 한 작업에 의존할 수 있고, 겉보기 실패는 손상된 작업 공간을 물려받은 결과일 수 있습니다.

리뷰에서는 파일과 줄, 발동 조건, 재현 가능한 영향, 패치 이전에도 있던 문제인지를 각각 검증합니다. 중복 발견은 합친 후 셉니다. 두 번째 모델은 설명을 반박하는 데 도움이 되지만 두 모델의 동의가 재현된 결함과 같지는 않습니다.

작업 유형별로 적용할 라우팅 정책

자주 발생하고 명확하며 저렴하게 검수할 수 있는 일에는 Sonnet을 후보로 유지합니다. 불확실하거나 실패 비용이 큰 일에는 Opus를 포함하고, 전환 자체가 낭비인지 알 수 있게 직접 Opus 기준선도 남깁니다. 특정 유형이 반복해서 전환을 요구하면 잘못된 프롬프트나 통합 고장을 먼저 배제한 후 직접 배정하세요.

저장소 검색, 구현, 최종 리뷰에는 서로 다른 요구가 있을 수 있지만 나누면 인계 비용도 듭니다. 전체 흐름을 재기 전에 절감을 주장하지 마세요. 구독에서도 같은 품질·시간 프레임을 사용할 수 있지만 API 계산을 계정별 이용 한도 대신 쓰면 안 됩니다. 최종 선택은 어떤 일을 어느 모델로 보내는지, 이유는 무엇인지, 어떤 증거가 결정을 바꿀지 설명해야 합니다.

구독으로 사용할 때

API 요금표를 Claude Code에서 보낼 수 있는 정확한 프롬프트 수로 환산하지 마세요. 구독 사용량과 한도는 계정 및 서비스 조건에 따라 달라집니다. 클라이언트 업데이트나 공급사 변경 뒤에는 실제 선택 모델을 확인하고 과금 방식과 모델 이름을 구분하세요.

Claude Code 설정 가이드는 버전 확인과 명시적 선택을 다룹니다. Effort 가이드에서는 API와 Claude Code 기본값을 구분합니다. 다른 공급사 모델도 고려한다면 Sonnet과 Sol 비교의 통제된 평가 방법을 참고하세요.