※ 이 글의 모든 단가와 정책은 2026년 7월 20일 작성 시점 기준의 공개 문서를 인용한 것입니다. LLM 가격 정책은 자주 바뀌므로, 예산을 확정하기 전에 반드시 각 링크의 원문을 다시 확인하세요.
단가표가 똑같은데 청구서가 더 나올 수 있다면, 그건 사기일까요 함정일까요.
Claude Sonnet 5의 표준 가격은 100만 입력 토큰당 $3, 출력 $15입니다. 이전 세대인 Sonnet 4.6과 숫자 하나 다르지 않습니다. 그런데 Anthropic은 공식 가격 문서에서 조용히 한 줄을 덧붙였습니다. Sonnet 5는 새 토크나이저를 쓰고, 같은 텍스트가 약 30% 더 많은 토큰으로 계산된다고요(Anthropic 가격 문서, 2026-07-20 확인).
단가는 같은데 세는 단위가 커졌습니다. 이게 “클로드 소네트 5 비용"을 검색한 사람이 가장 먼저 알아야 할 사실이고, 대부분의 비교표가 빠뜨리는 사실입니다.
그리고 이 30%는 남의 말을 믿을 필요가 없습니다. 뒤에서 여러분의 실제 프롬프트로 직접 세어보는 방법을 절차째로 적어두었습니다.
그럼에도 저는 Sonnet 5가 에이전트용으로 옳은 선택이라고 봅니다
먼저 제 입장을 밝히고 시작하겠습니다. 위의 30% 함정을 다 감안하고도, AI 에이전트를 구축한다면 지금 기본값은 Sonnet 5여야 한다고 생각합니다. 다만 그 이유가 “싸서"는 아닙니다. 이유는 좀 더 미묘하고, 그래서 더 중요합니다.
에이전트의 비용은 단가가 아니라 횟수가 결정하기 때문입니다.
에이전트가 비싼 진짜 이유: 실패가 곱셈으로 붙는다
챗봇과 에이전트의 비용 구조는 다릅니다. 챗봇은 한 번 물어보고 한 번 답합니다. 에이전트는 계획을 세우고, 터미널을 열고, 결과를 읽고, 틀렸다는 걸 깨닫고, 다시 시도합니다. 이 루프가 12번 돌면 앞선 11번의 대화 기록이 전부 다음 요청의 입력 토큰이 됩니다.
즉 에이전트에서 토큰은 선형이 아니라 누적됩니다. 그리고 모델이 도구 파라미터를 환각해서 한 번 삽질하면, 그 삽질의 흔적이 남은 루프 전체의 입력에 얹혀서 계속 청구됩니다. 저렴한 모델로 에이전트를 돌렸다가 청구서를 보고 놀라는 사람들의 대부분은 여기서 당합니다. 단가가 3배 싼 모델이 루프를 4배 돌면, 산수가 뒤집힙니다.
Anthropic이 Sonnet 5를 소개하며 강조한 지점이 정확히 여기입니다. 계획 수립, 브라우저·터미널 도구 사용, 자율 실행을 “이전에는 더 크고 비싼 모델이 필요했던 수준"으로 해낸다는 것(Anthropic 공지). 긴 도구 체인에서 목표를 잃지 않는 goal fidelity, JSON 출력 정확도, 환각 파라미터 감소 — 벤치마크 점수보다 청구서에 직접 꽂히는 개선들입니다. 테크크런치를 비롯한 매체들이 이 모델을 “에이전트를 더 싸게 돌리는 방법"으로 요약한 것도 같은 맥락입니다(TechCrunch).
디테일 하나가 이 포지셔닝을 잘 보여줍니다. 도구를 정의할 때 자동으로 붙는 시스템 프롬프트 오버헤드가 Sonnet 4.6의 497토큰에서 Sonnet 5는 354토큰으로 줄었습니다(가격 문서). 요청 한 번에 143토큰. 아무것도 아닌 것 같지만, 하루 10만 번 호출하는 에이전트에게는 매일 1,430만 토큰입니다. 이런 걸 깎았다는 건 설계자가 에이전트 청구서를 실제로 들여다봤다는 뜻입니다.
숫자로 세워보는 시나리오
추상론은 그만하고 계산기를 두드려 보겠습니다. 아래는 제가 공개 단가로 계산한 가정 시나리오입니다. 제가 이 워크로드를 직접 돌려본 실측치가 아니며, 실제 워크로드에 따라 크게 달라집니다.
에이전트 작업 1회에 누적 입력 30만 토큰, 출력 2만 토큰이 든다고 가정합시다.
- 도입가($2/$10) 그대로: $0.60 + $0.20 = 약 $0.80
- 표준가($3/$15) 전환 후: $0.90 + $0.30 = 약 $1.20
- 표준가 + 토크나이저 30% 증가 반영: 약 $1.56
- 여기에 프롬프트 캐싱 적중을 붙이면: 반복되는 시스템 프롬프트·도구 정의·이전 턴은 캐시 적중가로 떨어집니다. 적중 시 기본 입력가의 0.1배이며, 캐시에 처음 쓸 때는 기본 입력가의 1.25배(5분 TTL 기준)가 붙습니다(프롬프트 캐싱 문서, 가격 문서). 입력의 80%가 안정적으로 캐시에 적중한다는 가정 아래 입력 비용은 대략 절반 이하로 내려갑니다.
- Batch API를 얹으면: 입출력 모두 50% 할인. 도입가 기준 $1/$5, 표준가 기준 $1.5/$7.5입니다(Batch 처리 문서, 가격 문서).
같은 모델, 같은 작업인데 최저와 최고가 3배 넘게 벌어집니다. 그러니까 “Sonnet 5는 비싼가요"라는 질문은 잘못된 질문입니다. 답은 언제나 “어떻게 쓰느냐에 따라"이고, 그 차이는 모델 선택보다 큽니다.
비교 기준점도 하나 잡아두죠. 같은 시나리오를 Opus 4.8($5/$25)로 돌리면 약 $2.00입니다. Sonnet 5 표준가의 약 1.7배. 반대로 Haiku 4.5는 $1/$5로, 표준가 기준 Sonnet 5보다 3배 저렴합니다(가격 문서).
그 30%, 직접 세어보는 법 (토큰 카운팅 API)
이 글에서 가장 실무적인 부분입니다. “새 토크나이저 때문에 30% 늘어난다"는 주장은 여러분 청구서를 좌우하는데, 여러분의 텍스트가 정확히 몇 %인지는 아무도 모릅니다. 한국어·코드·JSON·로그는 토크나이저 변경에 반응하는 폭이 제각각이기 때문입니다.
Anthropic은 청구되지 않는 토큰 카운팅 엔드포인트를 제공합니다(토큰 카운팅 문서). 절차는 이렇습니다.
- 실제 프롬프트 샘플을 20~50개 모읍니다. 합성 문장 말고, 프로덕션 로그에서 뽑은 진짜 요청이어야 의미가 있습니다. 시스템 프롬프트와 도구 정의(
tools)까지 함께 넣으세요 — 이게 에이전트 입력의 큰 몫입니다. - 같은 페이로드를 두 모델로 각각 카운트합니다.
POST /v1/messages/count_tokens에model만 Sonnet 4.6 / Sonnet 5로 바꿔 두 번 호출하면 됩니다. input_tokens비율을 냅니다. 샘플별 증가율의 중앙값과 최댓값을 같이 보세요. 평균만 보면 꼬리가 긴 요청에서 예산이 터집니다.- 그 비율을 단가에 곱해 재계산합니다. 30%는 문서가 제시한 일반적 수치일 뿐, 여러분의 실측 계수가 예산의 근거가 되어야 합니다.
이 과정은 API 호출 비용이 들지 않으므로, 모델 전환 검토 단계에서 가장 먼저 해야 할 일입니다. 마이그레이션 결정을 내리고 나서 세면 늦습니다.
콘솔에서 실제로 켜는 법: 캐싱·배치·사용량·상한
“캐싱을 쓰면 싸진다"는 말은 많은데, 어디를 눌러야 하는지는 잘 안 알려줍니다. 작성 시점 기준 절차를 정리합니다.
1) 프롬프트 캐싱 — 콘솔 토글이 아니라 요청 파라미터입니다.
캐싱은 계정 설정에 스위치가 있는 기능이 아니라, 요청 본문에서 블록에 cache_control: {"type": "ephemeral"}을 붙여 켜는 기능입니다. 붙이는 위치가 성패를 가릅니다.
- 변하지 않는 것부터, 앞쪽에: 시스템 프롬프트 → 도구 정의 → 고정 문서 순으로 배치하고, 그 마지막 블록에 마커를 답니다. 캐시는 접두사(prefix) 단위로 잡히므로, 앞쪽에 매 요청 달라지는 값(타임스탬프, 사용자 ID, 랜덤 요청 번호)이 하나라도 끼면 전체가 미스가 됩니다.
- Workbench에서 먼저 확인: Claude Console의 Workbench에서 프롬프트를 구성하고 실행하면 응답에서
cache_creation_input_tokens와cache_read_input_tokens를 바로 볼 수 있습니다. 두 번째 실행에서cache_read_input_tokens가 0이 아니어야 캐싱이 실제로 걸린 겁니다. 여기서 확인한 다음 코드에 옮기세요. - TTL 선택: 기본 5분 캐시 외에 더 긴 TTL 옵션이 있고, 쓰기 단가 배수가 다릅니다. 에이전트 루프가 5분 안에 다음 턴을 도는지에 따라 선택이 갈립니다. 자세한 배수는 캐싱 문서에서 확인하세요.
2) Batch API — 즉시 응답을 포기하는 대신 반값.
Batch도 별도 신청이 아니라 다른 엔드포인트입니다. 요청들을 JSONL로 묶어 /v1/messages/batches에 제출하고, 완료되면 결과를 내려받습니다. 최대 24시간 안에 처리되는 비동기 방식이므로 사용자가 화면 앞에서 기다리는 요청에는 못 씁니다(Batch 처리 문서).
에이전트에서 현실적으로 배치로 넘길 수 있는 건 보통 이런 것들입니다 — 야간 문서 재색인, 대량 분류·태깅, 리포트 생성, 평가(eval) 실행. 사용자 대면 루프는 실시간, 백오피스 작업은 배치로 쪼개는 이 분리만으로 전체 청구서의 상당 부분이 반값이 됩니다.
3) 토큰 사용량 확인 경로.
- 응답 본문의
usage객체:input_tokens,output_tokens,cache_creation_input_tokens,cache_read_input_tokens. 진짜 근거는 여기입니다. 에이전트 로그에 이 네 값을 요청마다 남기세요. 캐시 적중률(= cache_read / 전체 입력)을 모르면 절감액을 말할 수 없습니다. - 콘솔 Usage 화면: console.claude.com/usage에서 모델별·기간별 토큰과 비용을 봅니다. 다만 여기서 보이는 건 이미 쓴 돈입니다. 예방책이 아니라 사후 확인용입니다.
- API 키를 워크로드별로 분리: 에이전트·배치·실험을 같은 키로 돌리면 어디서 돈이 샜는지 영영 모릅니다. 키를 나누는 게 가장 값싼 관측 인프라입니다.
4) 비용 상한 — 이걸 안 걸면 나머지가 다 무의미합니다. 에이전트는 루프를 돕니다. 루프는 버그가 나면 안 멈춥니다. 콘솔의 Limits/Billing 설정에서 조직 단위 월 지출 한도와 알림 임계값을 먼저 걸어두세요. 그리고 코드 쪽에도 두 겹을 더 답니다.
- 에이전트 실행당 최대 턴 수(예: 25턴)와 누적 토큰 상한을 하드코딩. 초과 시 중단하고 사람에게 넘김.
max_tokens를 작업 유형별로 다르게. 분류 작업에 4096을 열어둘 이유가 없습니다.
제 경험상 청구서 사고의 대부분은 단가가 아니라 멈추지 않은 루프에서 옵니다. 상한은 절약 기법이 아니라 안전장치입니다.
그래서, 언제 Sonnet 5를 쓰면 안 되는가
이 글이 광고가 되지 않으려면 반대편도 정직하게 적어야 합니다.
첫째, 도입가에 속지 마세요. $2/$10은 작성 시점 기준 2026년 8월 31일까지만 유효한 한시 가격으로 안내되어 있습니다. 9월 1일부터 $3/$15로, 정확히 50% 오릅니다(가격 문서). 지금 이 단가로 유닛 이코노믹스를 짜서 투자자나 상사에게 보고하면, 6주 뒤에 그 표를 다시 만들어야 합니다. 계산은 처음부터 $3/$15로 하고, 그 위에 캐싱·배치 할인을 얹는 게 맞습니다. (물론 이 일정 자체도 공급자가 바꿀 수 있습니다 — 확정 전 원문 재확인.)
둘째, 가벼운 작업에 쓰면 손해입니다. 감성 분류, 짧은 요약, 라우팅 판단 같은 일에 Sonnet 5는 과잉입니다. Haiku 4.5가 3배 싸고, 그런 작업에서는 품질 차이가 청구서 차이를 정당화하지 못합니다. 잘 만든 에이전트는 단일 모델이 아니라 모델 계층으로 굴러갑니다 — 분류는 Haiku, 실행은 Sonnet 5, 최고 난도 아키텍처 판단만 Opus.
셋째, Sonnet 5는 Opus 4.8이 아닙니다. 근접하지만 동등하지 않습니다. 특히 Anthropic 자체 공지가 명시하듯, 익스플로잇 개발 같은 사이버 보안 과제에서 Sonnet 5는 Opus 4.8보다 ‘상당히 낮은’ 성능을 보이며 해당 영역은 의도적으로 학습되지 않았습니다(Anthropic 공지). 보안 리서치 워크로드라면 모델 선택 자체를 다시 해야 합니다.
넷째, 토큰 외 비용이 조용히 붙습니다. 웹 검색 도구는 1,000회당 $10이 토큰 값과 별도로 부과됩니다(웹 검색 도구 문서, 가격 문서). 에이전트가 작업 한 번에 검색을 5회 한다면 회당 $0.05 — 캐싱을 잘 적용해 토큰 비용을 낮춰둔 상태라면, 이 부대비용이 토큰 비용의 20%를 넘길 수도 있습니다. Managed Agents 세션 런타임은 시간당 $0.08이 붙고, 미국 데이터 레지던시(inference_geo="us")를 쓰면 모든 단가에 1.1배 승수가 걸립니다(가격 문서). 규제 때문에 레지던시를 켜야 하는 조직은 위의 모든 계산에 ×1.1을 곱해서 다시 보세요.
그럼 GPT·Gemini 계열보다 싼가요
제목의 질문에 답하려면 이 비교를 피할 수 없습니다. 다만 정직하게 말하면, 각사 단가는 이 글이 유통되는 동안에도 바뀝니다. 그래서 여기서는 제가 확인할 수 없는 남의 숫자를 옮겨 적는 대신, 비교를 직접 수행하는 틀을 드리겠습니다. 단가표 하나로 결론 내리는 비교가 바로 이 글이 반대하는 것이기도 하고요.
에이전트에서 진짜로 비교해야 할 값은 단가가 아니라 이겁니다.