Sonnet 5.5 가격·성능, Opus 대신 써도 될까

Sonnet 5.5를 보면 먼저 드는 생각은 “이 정도면 Opus 대신 써도 되지 않을까”입니다. 입력·출력 토큰 단가는 Opus 5.5의 절반이고, 일부 공개 평가에서는 점수가 비슷하거나 앞섭니다. 반복해서 코드를 고치거나 문서를 처리하는 사람에게는 최고 점수보다 이 조합이 더 중요한 소식일 수 있습니다.

다만 가격표의 절반과 작업비의 절반은 다릅니다. Sonnet이 더 오래 추론하거나 같은 문제를 여러 번 수정하면 단가 차이가 줄어듭니다. Sonnet 5.5는 범위가 분명한 작업의 기본 모델 후보로 검토하되, 완료까지 쓴 비용과 검수 시간을 기준으로 Opus와 비교하는 편이 합리적입니다.

Sonnet 5.5가 바꾼 기본 선택지

Anthropic은 9월 28일 Sonnet 5.5를 발표했습니다. 공식 설명은 복잡하고 열린 문제를 다루는 Opus 5.5와, 범위가 정해진 일상 작업·버그 수정·문서 제작에 강점을 둔 Sonnet을 구분합니다. Sonnet 5보다 출력 생성이 30% 이상 빠르다는 설명도 있지만, 이는 도구 대기와 재시도를 합친 모든 업무가 30% 빨리 끝난다는 뜻은 아닙니다. 공식 발표

모델 문서에 나온 API 모델 ID는 claude-sonnet-5-5이며 컨텍스트 창은 100만 토큰, 최대 출력은 12만 8천 토큰입니다. 긴 자료를 넣을 수 있다는 사양과 그 자료를 끝까지 정확하게 활용한다는 보장은 구분해야 합니다. 결과 검수는 여전히 작업 설계에 포함됩니다.

이를테면 로그인 버튼을 눌렀을 때 특정 계정만 오류가 나는 상황을 생각해 보겠습니다. 재현 계정의 조건, 실패 응답, 변경 가능한 파일, 통과해야 하는 테스트를 이미 알고 있다면 작업의 끝을 정의하기 쉽습니다. 반대로 로그인·결제·권한 구조를 모두 다시 설계해 달라는 요청은 무엇을 바꾸지 말아야 하는지부터 판단해야 합니다. 두 요청을 같은 “코딩”으로 묶으면 모델 선택의 기준이 흐려집니다.

토큰 단가는 절반, 작업비는 사용량까지 계산

표준 API 가격은 100만 토큰당 Sonnet 5.5가 입력 2달러·출력 10달러, Opus 5.5가 입력 4달러·출력 20달러입니다. 반면 캐시 읽기는 두 모델 모두 0.20달러입니다. 5분 캐시 쓰기는 각각 2.50달러와 5달러이며, 더 긴 캐시 보존·배치·도구·데이터 처리 조건은 별도 가격 항목을 확인해야 합니다. 공식 API 가격표

캐시와 도구 비용을 제외한 가상 계산으로 차이를 보겠습니다. 한 작업에 일반 입력 10만 토큰과 출력 1만 토큰을 사용하면 Sonnet은 0.30달러, Opus는 0.60달러입니다. 입력이 같고 Sonnet의 출력이 4만 토큰까지 늘어나면 Sonnet도 0.60달러가 됩니다. 이는 실제 평균 사용량이 아니라 단가가 낮아도 사용량이 늘면 절약이 사라질 수 있다는 산술 예시입니다.

크게 보기

×확대 이미지 닫기

여러 차례 수정한 로그인 오류라면 최초 요청만 계산해서도 안 됩니다. 실패한 시도, 다시 읽은 코드, 추가 테스트, 마지막 수정까지 합쳐야 합니다. 캐시 사용량이 많은 워크플로에서는 동일한 캐시 읽기 단가 때문에 전체 청구액이 입력·출력 단가 비율대로 줄지 않을 수 있습니다.

캐시는 이전에 처리한 입력을 재사용하는 기능입니다. 예를 들어 이미 만들어진 캐시에서 100만 토큰을 읽고 1만 토큰을 출력하는 호출이라면, 읽기와 출력 비용은 Sonnet 0.30달러, Opus 0.40달러입니다. 이 계산에서는 캐시를 처음 만드는 비용과 새 입력·도구 비용을 제외했습니다. 일반 입력의 비중이 큰 작업과 긴 기록을 반복해서 읽는 작업은 같은 가격표에서도 절약 폭이 다릅니다.

토큰 사용량에는 최종 화면에 보이는 답변만 들어가는 것도 아닙니다. 공식 마이그레이션 문서는 추론 토큰이 출력 토큰으로 과금되고 max_tokens에도 포함된다고 설명합니다. 답변이 짧아 보였다는 이유만으로 비용도 적었다고 추정하면 안 됩니다. 추론 응답과 비용 처리

Claude 앱의 구독 사용 한도도 API 달러 계산과 별개입니다. “API 단가가 절반이니 내 구독에서 두 배 오래 쓸 수 있다”는 결론은 이 가격표만으로 도출할 수 없습니다. 구독 사용자는 자신의 사용량 화면과 작업 완료 기록을, API 사용자는 청구 가능한 토큰 종류별 사용량을 비교해야 합니다.

같은 High보다 같은 비용에서 비교하기

effort는 모델이 답변·도구 호출·추론에 얼마나 많은 토큰을 쓰도록 할지 조절하는 설정입니다. 모델 이름 뒤에 붙은 High가 같다고 작업당 비용이나 도달하는 품질까지 같아지는 것은 아닙니다. 공식 effort 문서는 이 설정이 추론뿐 아니라 응답과 도구 호출에도 영향을 준다고 설명합니다.

모델을 고를 때는 내 예산 안에서 어느 설정이 가장 좋은 결과를 내는가 또는 필요한 품질에 도달하는 가장 싼 설정은 무엇인가를 물어야 합니다. Sonnet High와 Opus High만 짝지어 비교하면, Sonnet Xhigh보다 Opus의 더 낮은 설정이 유리한 경우를 놓칠 수 있습니다.

예산이 먼저 정해진 작업과 품질이 먼저 정해진 작업을 나눠 보면 쉽습니다. ‘요약 한 건에 쓸 수 있는 비용 안에서 가장 나은 결과’를 고르는 일은 예산을 고정한 비교입니다. 반면 ‘정해진 테스트와 검토를 통과하는 로그인 수정’을 고르는 일은 완료 조건을 고정한 비교입니다. 후자에서는 싸게 생성한 코드가 검수를 통과하지 못하면 아직 일을 끝낸 것이 아닙니다. Low·High라는 이름은 이 두 기준을 대신하지 않습니다.

크게 보기

×확대 이미지 닫기

그래프에서 먼저 볼 곳은 각 점의 왼쪽 위입니다. 다른 설정이 그곳에 있다면 비용은 더 적으면서 점수는 더 높다는 뜻입니다. 반대로 더 싼 설정이 모두 낮은 점수라면, 어느 정도의 품질을 요구하는지에 따라 선택이 달라집니다. 이런 식으로 비용과 성능 양쪽에서 다른 선택지에 밀리지 않는 점들의 경계를 파레토 프런티어라고 부릅니다.

위 Terminal-Bench 그래프에서는 Sonnet Xhigh보다 왼쪽 위에 있는 Opus 설정이 보입니다. 이 평가에서 중상위 품질을 원한다면 Sonnet의 추론을 계속 높이기보다 Opus를 비교할 이유가 있습니다. Sonnet Low·Medium은 더 작은 예산의 선택지로 남고, Sonnet Max는 더 비싸지만 가장 높은 점수에 도달합니다. 따라서 Low·Medium 외에는 무조건 쓸모없다는 해석도 정확하지 않습니다. 최고 점수를 위해 추가 비용을 감수할지는 별도의 판단입니다.

여기서 가로축은 로그 척도입니다. 같은 가로 간격이 같은 달러 차이를 뜻하지 않습니다. 점 사이를 잇는 선도 모든 중간 예산에서 실제 측정했다는 의미는 아닙니다. 이 그림의 비용은 Terminal-Bench의 시도당 비용이며, 자신의 저장소에서 버그 하나를 고치는 가격으로 그대로 옮길 수 없습니다.

다른 코딩 평가에서는 선택이 다시 달라집니다

한 그래프에서 유리한 설정이 다른 작업에서도 유리한지 확인하려면 평가를 바꿔 봐야 합니다. 아래 FrontierCode에서는 Sonnet의 High에서 Xhigh로 갈 때 점수가 오르지만, Max에서는 오히려 떨어집니다. Terminal-Bench에서 Max가 최고점을 낸 모습과 다릅니다.

크게 보기

×확대 이미지 닫기

FrontierCode는 사람이 추가로 수정하지 않고 병합할 수 있는 코드 변경을 평가합니다. 발표 각주는 Sonnet이 Max에서 코드 검토를 더 수행하다가 시간 초과나 요청 범위를 벗어난 수정으로 감점을 받은 사례를 설명합니다. Sonnet의 결과는 Xhigh 52.1%, Max 46.2%입니다. 더 많은 추론이 더 좋은 변경을 보장하지 않는 구체적인 반례입니다. 공식 평가 설명

로그인 버그 하나를 고쳐 달라고 했는데 인증 구조 전체를 정리했다면, 코드가 깔끔해도 요청을 잘 수행했다고 보기 어렵습니다. 작업의 성공 조건에 “기존 동작 유지”와 “지정한 범위 안에서 수정”이 들어가야 하는 이유입니다. 모델이 더 오래 일했는지보다 필요한 변경만 완성했는지를 봐야 합니다.

이 두 그래프로부터 얻을 수 있는 결론은 특정 effort를 영구적으로 금지하자는 것이 아닙니다. 범위가 분명하고 빠른 왕복이 중요한 일에는 Sonnet Low·Medium을 출발점으로 삼을 수 있습니다. 더 높은 품질이 필요해지면 Sonnet의 설정을 높이는 경로와 Opus로 바꾸는 경로를 함께 비교해야 합니다. 다만 어느 쪽이 유리한지는 실제 업무와 가까운 평가에서 다시 확인해야 합니다.

독립 평가에서 드러난 높은 추론 비용

Artificial Analysis의 Sonnet 5.5 평가는 Max·Default Fallback 조건에서 Intelligence Index 56, 해당 지수의 작업당 비용 7.67달러를 표시합니다. Opus 5.5의 같은 설정 평가는 지수 58, 작업당 5.98달러입니다. 이 조건에서는 Sonnet의 토큰 단가가 낮아도 작업당 비용은 더 높습니다.

이 수치는 앞의 가상 로그인 수정비나 모든 API 호출의 평균 가격이 아닙니다. Artificial Analysis가 구성한 여러 평가의 가중 작업당 비용이며, 모델 설정과 평가 버전에 종속됩니다. 낮은 추론 설정에서도 같은 역전이 발생한다고 확대해서는 안 됩니다.

공식 발표가 말하는 비용 개선은 주로 이전 Sonnet과의 비교입니다. 독립 평가의 높은 비용은 특정 설정에서 다른 모델과 비교한 결과입니다. 비교 상대·작업·추론 수준이 다르면 두 설명은 함께 성립할 수 있습니다. 가격 논쟁을 판단할 때 먼저 맞춰야 하는 것은 모델 이름보다 이 세 조건입니다.

Sonnet 구현·Opus 검토가 항상 더 싸지는 않음

구현은 저렴한 모델에 맡기고 검토만 상위 모델로 하는 방식은 매력적입니다. 하지만 분업 자체가 절약을 보장하지는 않습니다. 두 작업을 비교한 개인 사용 사례에는 Sonnet High가 더 빠르고 저렴하게 초안을 만들었지만 누락과 오류가 남았고, Opus 검토 뒤 다시 고치는 과정까지 합치자 Opus 단독보다 비용과 시간이 늘었다는 보고가 있습니다. 공개된 작업 조건과 표본이 제한적이므로 전체 성능의 증거보다 확인할 실패 유형으로 읽는 편이 맞습니다.

같은 논의에는 Sonnet을 요구가 분명하고 빠른 왕복이 필요한 작업에 쓰겠다는 의견과, 그래프 하나로 High·Max의 가치를 모두 부정할 수 없다는 반론도 있습니다. 이 반응들은 모순이라기보다 비교 기준이 다릅니다. 한쪽은 첫 결과까지의 속도, 다른 쪽은 검수를 마친 결과까지의 비용을 보고 있습니다. 어느 쪽이 더 많이 언급됐는지보다 내 작업이 무엇을 ‘완료’로 보는지 정하는 데 참고할 만합니다.

앞의 로그인 오류를 다시 생각해 보겠습니다. Sonnet이 일반 계정의 로그인만 고쳤는데 Opus 검토에서 특정 권한의 계정이 여전히 실패한다는 사실을 찾았다고 가정하겠습니다. 이제 추가 수정, 재검토, 테스트 재실행이 필요합니다. 최초 구현 요청의 청구액만 비교하면 이 왕복 비용이 빠집니다.

혼합 방식의 모델 비용은 최초 구현 + 검토 + 재수정 + 재검토를 합친 값입니다. 여기에 사람이 결과를 확인하고 설명을 다시 쓰는 시간도 별도로 남겨야 합니다. 모델을 나눠 썼더라도 오류가 적고 수정 범위가 작으면 유리할 수 있습니다. 반대로 요구 해석부터 다시 해야 한다면 처음부터 한 모델에 맡기는 쪽이 나을 수 있습니다.

가상의 청구 기록으로는 더 분명해집니다. Sonnet의 첫 구현에 0.30달러, Opus 검토에 0.20달러, 재수정과 재검토에 합계 0.25달러가 들었다면 혼합 방식은 0.75달러입니다. 같은 완료 조건을 Opus 단독이 0.60달러에 통과했다면 혼합 방식의 최초 호출만 저렴했던 셈입니다. 이 숫자는 관찰한 평균이 아니라 계산 구조를 설명하는 예시이며, 실패한 작업을 비교 대상에서 빼지 않는 것이 핵심입니다.

API 비용과 구독 사용률도 섞어서 읽으면 안 됩니다. 한 세션에서 한도가 많이 줄었다는 관찰만으로 모델의 작업당 효율을 비교하기는 어렵습니다. 시작 사용량, 다른 동시 세션, 대화 길이, 도구 호출, 검수 결과까지 조건이 같아야 원인을 좁힐 수 있습니다. “더 싸게 시작했는가”보다 같은 검수 기준을 통과하기까지 덜 들었는가가 선택의 기준입니다.

API 교체는 모델 ID만 바꾸면 끝나지 않습니다

새 기능 문서에 따르면 Sonnet 5.5는 적응형 추론이 기본이며 API의 기본 effort는 High입니다. 공식 발표가 안내하는 Claude 앱·Claude Code의 기본값은 Medium입니다. 같은 이름의 모델을 호출해도 시작 설정부터 다를 수 있으므로 비교 기록에 effort를 명시해야 합니다.

기존 코드에서 추론을 끄던 thinking.type: "disabled"는 Sonnet 5.5에서 오류가 납니다. 사전 추론을 끄려면 between_tools를 사용하며 Low·Medium·High에서 허용됩니다. Xhigh·Max에는 적응형 추론이 필요합니다. 강제 도구 선택인 tool_choice의 any·tool도 지원 변화가 있으므로 기존 요청 형식을 확인해야 합니다. 공식 마이그레이션 가이드

도구 사이의 진행 설명이 thinking 블록으로 반환되는 변화도 있습니다. 모델은 일하는데 앱 화면이 조용해 보인다면, 성능 문제로 단정하기 전에 스트리밍 응답 처리부터 살펴볼 필요가 있습니다. 이전 대화의 thinking 블록을 편집된 기록에 다시 붙이는 방식 역시 호환성 검토 대상입니다. 이 글의 선택 비교와 별도로, 운영 코드에서는 기존 요청·응답 처리를 대상으로 회귀 검증을 해야 합니다.

예를 들어 응답의 첫 블록을 언제나 텍스트로 가정해 content[0].text만 읽던 코드는 추론 블록이 먼저 오면 깨질 수 있습니다. 이 경우 ‘Sonnet이 답을 못 했다’와 ‘애플리케이션이 응답을 읽지 못했다’를 구분해야 합니다. 블록의 type에 따라 처리하고, 도구 호출을 이어 갈 때 thinking 블록을 변경 없이 돌려주는 것이 공식 문서의 안내입니다.

평가를 재현할 때는 fallback 설정도 기록해야 합니다. 공식 마이그레이션 문서는 일부 안전 분류에 걸린 요청을 이전 Sonnet으로 재시도하는 서버 측 fallback을 설명하며, 적용 범위와 지원 플랫폼에 조건을 둡니다. 모델 이름만 기록하면 실제 응답 경로의 차이를 놓칠 수 있습니다. 거절과 fallback 관련 변경

로그인 오류 하나로 시작하는 선택 기준

앞의 가상 로그인 오류에 두 모델을 비교한다면 입력을 먼저 고정합니다. 어떤 계정에서 어떤 응답이 나오는지, 어떤 파일까지 수정할 수 있는지, 통과할 테스트가 무엇인지 같은 자료를 제공합니다. 한쪽에만 자세한 오류 로그를 주면 모델 차이와 입력 차이를 구분하기 어렵습니다. 입력과 도구는 맞추되 effort까지 같은 이름으로 고정할 필요는 없습니다. 각 모델에서 예산 안에 들어오는 설정을 찾고, 같은 완료 조건을 통과하는지 비교합니다.

처음에는 Sonnet 5.5의 낮거나 중간 수준 추론으로 범위가 분명한 작업을 맡겨볼 수 있습니다. 단, 이것은 모델 전체에 대한 검증된 최적 설정이 아니라 비용과 품질을 확인하기 위한 시작점입니다. 결과가 부족하면 무조건 추론을 높이기 전에 누락된 입력, 잘못된 성공 조건, 도구 오류를 살핍니다. 정보가 부족한 요청은 더 비싼 모델로 보내도 해결되지 않을 수 있습니다.

제 선택은 기획에 Opus, 구현에 Sonnet

제 생각에는 Sonnet 5.5가 많이 좋아졌더라도, 아직 Opus 5.5를 전면적으로 대체할 수준이라고 보기는 이릅니다. 특히 무엇을 만들지 정하고, 여러 요구의 우선순위를 조율하며, 전체 구조를 판단하는 일에는 여전히 Opus 쪽에 더 무게를 두고 싶습니다. 기획과 계획은 Opus로 정리하고, 범위가 명확해진 구현은 Sonnet에 맡기는 방식이 좋아 보입니다.

이 판단은 Anthropic이 설명하는 두 모델의 역할과도 맞닿아 있습니다. 회사는 지속적인 판단이 필요한 복잡하고 열린 작업에서는 Opus 5.5가 더 강하다고 설명합니다. 공식 발표에 실린 제작자 Kevin Ngo의 의견에도 Opus가 구조를 정한 뒤 Sonnet이 구현하는 구상이 등장합니다. 다만 이는 제작사의 설명과 초기 사용자의 의견이며, 이 분업이 모든 프로젝트에서 가장 효율적이라는 검증 결과는 아닙니다. 공식 성능 설명과 제작자 의견

여기서 근거로 삼는 것은 공개된 작업별 성능과 역할입니다. 확인한 공식 자료에서는 두 모델의 파라미터 수를 비교할 수 없었으므로, Opus가 더 큰 모델이어서 반드시 더 좋다고 단정하지는 않겠습니다. 앞서 본 것처럼 Sonnet이 앞서는 평가도 있어, Opus가 모든 작업에서 우위라는 뜻도 아닙니다.

로그인 오류 사례라면 Opus가 원인 후보, 바꾸지 말아야 할 동작, 수정 범위와 통과할 테스트를 먼저 정리하고, 사람이 그 계획을 확인한 뒤 Sonnet이 구현하도록 나눌 수 있습니다. 구현 중 계획의 전제가 틀린 것으로 드러나거나 권한 설계까지 바꿔야 한다면, Sonnet에 계속 수정을 반복시키기보다 계획 단계로 돌아가 다시 판단하는 편이 좋겠습니다. 이는 제가 선호하는 역할 분담이며, 실제 절약 여부는 앞서 설명한 검토·재작업 비용까지 합쳐 확인해야 합니다.

이 분업에서 중요한 산출물은 긴 계획서보다 구현자가 판단을 다시 시작하지 않아도 되는 작업 지시입니다. 다음은 조직을 옮긴 계정의 로그인 오류를 가정한 요청 예시입니다. 실제 프로젝트에서는 오류 로그와 관련 코드, 테스트 정보를 함께 제공해야 합니다.

기획 단계에는 이렇게 요청할 수 있습니다.

상황
조직을 옮긴 계정만 권한 확인 단계에서
403이 발생합니다. 일반 계정은 성공합니다.

요청
아직 코드를 수정하지 말고
계획을 작성해 주세요.
확인된 사실과 원인 가설을 구분하고
가설을 검증할 방법을 적어 주세요.
수정 후보 파일, 유지할 동작,
통과해야 할 테스트를 정리해 주세요.

제약
권한 검사를 제거하지 말아 주세요.
추가 정보가 필요한 판단을
추측으로 확정하지 말아 주세요.

사람이 근거와 범위를 확인한 계획은 구현 단계에 이렇게 넘길 수 있습니다.

첨부한 계획과 재현 자료를 기준으로
최소 범위를 수정해 주세요.
새로 발견한 사실이 계획과 충돌하면
변경을 넓히기 전에 알려 주세요.

다음 세 가지를 검증해 주세요.
- 실패 계정의 로그인
- 일반 계정의 로그인
- 타 조직 접근 차단

마지막에 변경 파일, 테스트 결과,
미확인 항목을 남겨 주세요.

계획을 전달받았다고 Sonnet이 요구를 그대로 이해했다고 가정하지 않는 편이 좋습니다. 구현을 시작하기 전에 수정 범위와 완료 조건을 짧게 다시 정리하게 하면 어긋난 해석을 찾기 쉽습니다. 반대로 계획이 ‘인증을 개선한다’ 수준에 머물러 있다면 모델을 나눠도 판단 부담을 넘겼을 뿐입니다. 그때는 더 자세한 입력을 준비하거나 Opus에서 설계를 계속하는 선택이 맞겠습니다.

Sonnet을 선택할 이유는 충분히 늘었지만, 복잡한 판단까지 모두 넘기기보다는 작업을 나눠 활용하는 쪽이 현재 제 판단입니다.