Claude Sonnet 5가 Opus 코앞까지 왔는데 값은 입력 100만 토큰 $2: 진짜 청구서는 새 토크나이저가 정한다

Anthropic이 Claude Sonnet 5를 내놨다. 숫자만 보면 중급 모델이 상급 모델을 밀어 올리는 전형적인 세대교체다. SWE-bench Pro에서 63.2%, 상급인 Opus 4.8의 69.2%에 6점 차로 붙었다. 터미널 작업을 재는 Terminal-Bench 2.1에서는 80.4%로 Opus 4.8의 74.6%를 오히려 앞섰고, 지식노동을 평가하는 GDPval-AA v2에서도 1,618 Elo로 Opus의 1,615를 근소하게 넘겼다. 컨텍스트 창은 100만 토큰. 값은 8월 31일까지 도입가로 입력 100만 토큰 $2, 출력 $10. Free와 Pro의 기본 모델도 이걸로 바뀌었다.

여기까지만 읽으면 결론은 단순하다. Opus 값의 몇 분의 일로 Opus에 가까운 품질을 쓴다. 하지만 실무에서 매달 청구서를 받는 사람이라면 헤드라인 가격 아래 한 줄을 더 봐야 한다.

한눈에 보기

도입가 (8/31까지)	입력 $2 / 출력 $10 (100만 토큰)
정상가 (9/1부터)	입력 $3 / 출력 $15
SWE-bench Pro	63.2% (Opus 4.8: 69.2%)
Terminal-Bench 2.1	80.4% (Opus 4.8: 74.6%)
컨텍스트	100만 토큰
숨은 변수	새 토크나이저, 같은 글이 약 30% 더 많은 토큰

벤치마크는 상급 모델을 위협한다

이번 세대의 핵심은 격차가 좁혀진 게 아니라 항목에 따라 뒤집혔다는 점이다. 코드 저장소를 실제로 수정하는 SWE-bench Pro에서는 여전히 Opus 4.8이 앞서지만, 셸에서 명령을 이어가며 문제를 푸는 Terminal-Bench 2.1과 브라우저로 정보를 찾는 에이전트형 작업에서는 Sonnet 5가 상급 모델을 넘겼다. 에이전트로 반복 작업을 돌리는 1인 SaaS 개발자에게 이 두 항목은 자주 실제 워크로드에 더 가깝다. 하루에 수백 번 도는 자동화라면, 최상위 정확도보다 "충분히 정확한데 값이 몇 분의 일"이 더 나은 선택이 된다.

문제는 그 "몇 분의 일"이 광고 문구만큼 깔끔하지 않다는 데 있다.

진짜 가격은 토크나이저에 숨어 있다

Sonnet 5는 토크나이저를 새로 바꿨다. 같은 입력 텍스트가 이전 세대인 Sonnet 4.6보다 토큰을 약 30% 더 많이 만든다. 토큰이 곧 과금 단위이므로, 단가가 같아도 같은 글을 처리하는 데 드는 토큰 수가 늘면 청구서는 그만큼 커진다.

Anthropic은 이 점을 알고 도입가를 낮춰 잡았다. 8월 31일까지는 입력 $2, 출력 $10로 두어 전환이 대략 비용 중립이 되도록 설계했다는 뜻이다. 즉 지금 갈아타면 토큰이 30% 늘어도 단가가 그만큼 낮아 총액이 비슷하게 맞는다. 함정은 9월 1일이다. 정상가 입력 $3, 출력 $15로 올라가면 단가 인상과 토큰 증가가 겹쳐, 같은 텍스트를 처리하는 비용이 4.6 대비 0에서 35%까지 오를 수 있다.

이건 벤치마크에 안 잡히는 종류의 비용이다. 모델을 바꾸면서 코드는 한 줄도 안 건드렸는데, 다음 달 청구서가 조용히 부풀어 있는 식이다. 특히 입력이 긴 워크로드, 예를 들어 100만 토큰 컨텍스트에 문서를 통째로 밀어넣는 검색·요약 파이프라인이라면 30% 증가가 곧바로 총액에 얹힌다.

어디는 갈아타고 어디는 남길까

그렇다고 갈아타지 말라는 얘기는 아니다. 판단의 기준을 작업별로 나누라는 것이다. 코딩 에이전트나 여러 단계를 이어가는 자동화처럼 품질이 결과를 좌우하는 곳에서는, 토큰이 30% 늘어도 Opus급 정확도를 몇 분의 일 값에 얻는 이득이 그 증가분을 덮는다. 재작업 한 번이 아낀 토큰보다 비싸기 때문이다.

반대로 문장을 짧게 분류하거나 태그를 다는 단순 반복 작업에서는 계산이 달라진다. 이런 작업은 애초에 최상위 모델이 필요 없고, 토큰이 30% 늘면 그 손해가 고스란히 남는다. 값싼 하위 티어 모델이나 더 가벼운 경쟁 모델로 이 구간을 빼면, 늘어난 토큰 수의 영향을 받는 요청 자체가 줄어든다. 100만 토큰 컨텍스트도 마찬가지다. 저장소 전체를 한 번에 밀어넣는 편리함은 크지만, 그 편리함의 값은 입력 토큰으로 매달 청구된다. 정말 전부 필요한지, 관련 파일만 골라 넣어도 되는지를 요청마다 되묻는 습관이 곧 비용 관리다.

anyAX 관점

모델 값을 비교할 때 우리는 보통 가격표의 숫자를 나란히 놓는다. Sonnet 5의 $2와 다른 모델의 $2를 비교하는 식이다. 이번 출시는 그 비교가 왜 위험한지 정확히 보여준다. 단가가 같아도 토크나이저가 다르면 같은 문장을 처리하는 실제 비용이 다르다. 비교해야 할 단위는 "토큰당 얼마"가 아니라 "내 실제 작업 한 건당 얼마"다.

혼자 제품을 돌리는 사람에게 이건 실천 항목이 하나 생겼다는 뜻이다. 지금 Sonnet을 프로덕션에서 쓰고 있다면, 8월 안에 대표적인 요청 몇 개를 골라 실제 입력·출력 토큰 수를 측정해 두는 것. 도입가가 끝나는 9월 1일 전에 내 워크로드가 4.6 대비 몇 퍼센트 더 비싸지는지 숫자로 알고 있어야, 계속 쓸지 다른 모델로 일부를 뺄지 판단할 수 있다. 값싼 분류·요약 작업까지 최상위 모델에 얹어두었다면 지금이 그걸 아래 티어로 내려보낼 때다.

도입가 기간은 판촉이 아니라 유예다. 지금은 값이 맞게 설계돼 있지만, 그 설계가 언제 끝나는지 달력에 적어두지 않으면 다음 분기 손익계산서에서 그 30%를 뒤늦게 발견하게 된다.