금액이 큰 게 문제가 아닙니다. 그 금액이 어느 에이전트의 어느 단계에서 나왔는지 아무도 모르는 게 문제입니다. 월말에 “AI 비용이 올랐다”는 말이 나오면 보통 줄이는 쪽으로 결론이 나고, 잘 돌던 에이전트가 멈춥니다.
이 글은 Claude API 청구서를 10분 안에 읽는 법입니다. 청구서의 네 줄이 무엇인지, 그중 어느 줄이 설계 실수를 드러내는지, 그리고 비용을 움직이는 레버 세 개가 무엇인지 적었습니다. 가격은 2026년 10월 10일 공식 문서 기준이고 바뀌니 링크로 확인하세요.
청구서의 네 줄
Claude API 청구서는 모델별로 네 줄입니다. 입력(input), 출력(output), 캐시 쓰기(cache write), 캐시 읽기(cache read). 이 네 줄의 비율만 봐도 에이전트가 어떻게 설계됐는지 보입니다.
| 모델 | 입력 | 출력 | 캐시 쓰기(5분) | 캐시 읽기 |
|---|---|---|---|---|
| Claude Fable 5.1 | $10 | $50 | $12.50 | $0.25 |
| Claude Opus 5.5 | $4 | $20 | $5 | $0.20 |
| Claude Sonnet 5.5 | $2 | $10 | $2.50 | $0.10 |
| Claude Haiku 5.5 | $0.10 | $0.50 | $0.125 | $0.01 |
백만 토큰당 미국 달러, 2026년 10월 10일 기준. Haiku 5.5는 프롬프트 10만 토큰을 넘으면 5배 요금 구간으로 올라갑니다.
표에서 두 가지를 읽으세요. 출력은 입력의 5배입니다. 에이전트가 길게 쓰면 비싸집니다. 캐시 읽기는 입력의 2.5~10%입니다. 같은 문서를 매번 다시 넣는 에이전트와 한 번 넣고 읽는 에이전트는 입력 비용이 10배 이상 차이 납니다. 청구서에 캐시 읽기 줄이 0에 가깝다면 그게 첫 번째로 볼 곳입니다.
한 가지 더. Claude 4.7 이후 모델은 토크나이저가 바뀌어 같은 글이 약 30% 더 많은 토큰으로 셉니다. 모델을 올렸는데 토큰 수가 늘었다면 그게 이유일 수 있습니다.
출처: Pricing — platform.claude.com
1. 프롬프트 캐싱 — 같은 걸 매번 다시 읽히지 않기
에이전트는 요청마다 시스템 프롬프트, 판단 기준 문서, 참고 자료를 통째로 보냅니다. 견적 에이전트라면 단가표와 거래처 규칙 2만 토큰이 매 건마다 들어갑니다. 하루 300건이면 600만 토큰, Sonnet 5.5 기준 $12입니다. 캐싱을 켜면 첫 건에 $0.05(쓰기)를 내고 나머지 299건은 읽기 요금 $0.60입니다. 같은 일을 $12 대신 $0.65에 합니다.
요청에 cache_control 한 줄을 넣으면 자동으로 캐시 지점을 잡아줍니다. 캐시는 5분 유지되고, 5분 안에 다음 요청이 오면 읽기 요금으로 넘어갑니다. 하루 종일 드문드문 오는 에이전트라면 1시간 캐시(쓰기 2배)가 맞을 수 있습니다.
청구서에서 보는 법: 캐시 읽기 토큰이 입력 토큰보다 적으면 캐싱이 안 되고 있거나 캐시가 계속 깨지고 있습니다. 흔한 원인은 프롬프트 앞부분에 날짜나 건별 정보를 넣어서 매번 내용이 달라지는 것입니다. 변하지 않는 것을 앞에, 변하는 것을 뒤에 두면 해결됩니다.
출처: Prompt caching — platform.claude.com
2. 모델 선택 — 단계마다 다른 모델
에이전트 하나가 모델 하나를 쓰는 게 아닙니다. 견적 처리 열 단계를 뜯어보면 메일 분류, 첨부 추출, 거래처 매칭 같은 단계는 판단이 거의 없고, 단가 결정과 예외 판단만 머리를 씁니다. 전부 Opus로 돌리면 분류 한 건에 $4짜리 모델을 쓰는 셈입니다.
| 단계 성격 | 맞는 모델 | 입력 가격 차이 |
|---|---|---|
| 분류·추출·라우팅 | Haiku 5.5 | 기준 |
| 초안 작성·일반 판단 | Sonnet 5.5 | 20배 |
| 예외 판단·장기 작업 | Opus 5.5 | 40배 |
저희 설계 기본값은 “Haiku로 시작해서 평가셋이 틀리는 단계만 올린다”입니다. 반대로 하면 비용을 절대 못 내립니다. 처음부터 Opus로 맞춘 프롬프트는 내리면 깨지니까요.
청구서에서 보는 법: 모델별 토큰 비율을 보세요. Opus 입력 토큰이 전체의 절반을 넘는데 에이전트가 하는 일이 분류와 요약이면 단계를 쪼갤 여지가 큽니다.
3. 컨텍스트 길이 — 전부 넣는 습관 끊기
가장 흔한 낭비는 “혹시 몰라서” 넣는 것입니다. 거래처 규칙 전체, 지난 1년치 견적 이력, 매뉴얼 PDF 통째. 에이전트는 그걸 매 요청마다 읽고, 요금은 읽은 만큼 나옵니다. 1M 토큰 컨텍스트가 표준 요금이 된 건 좋은 일이지만, 넣을 수 있다와 넣어야 한다는 다른 말입니다.
저희가 쓰는 기준은 “이 단계가 판단하는 데 실제로 필요한 것만”입니다. 거래처 매칭 단계에는 거래처 목록만, 단가 결정 단계에는 해당 거래처 단가표만. 열 단계 에이전트에서 단계마다 컨텍스트를 자르면 총 입력 토큰이 보통 절반 아래로 내려갑니다. 정확도도 같이 올라갑니다. 모델이 관계없는 자료에 덜 헷갈리니까요.
시간이 급하지 않은 일은 배치 API로 보내면 입력·출력 모두 50% 할인입니다. 밤새 돌려도 되는 월말 정산, 과거 건 재분류, 평가셋 실행 같은 일이 여기 해당합니다. 캐싱 할인과 겹쳐 적용됩니다.
청구서에서 보는 법: 요청당 평균 입력 토큰을 보세요. 분류 한 건에 5만 토큰이 들어가고 있다면 그 단계는 받을 필요 없는 자료를 받고 있습니다.
출처: Batch processing — platform.claude.com · Long context pricing
청구서에서 10분 안에 보는 것
☐ 캐시 읽기 토큰이 입력 토큰보다 많은가 → 아니면 캐싱 설계 점검
☐ 출력 토큰이 입력의 20%를 넘는가 → 넘으면 에이전트가 필요 이상 길게 쓰고 있음
☐ Opus 토큰 비중이 절반을 넘는가 → 넘으면 분류·추출 단계를 Haiku로
☐ 요청당 평균 입력 토큰이 단계 성격에 맞는가 → 분류에 수만 토큰이면 컨텍스트 자르기
☐ 밤에 돌려도 되는 일이 실시간으로 돌고 있는가 → 배치 API로
이 다섯 가지를 매달 보는 것이 저희 AI 에이전트 운영·비용 관리 서비스의 Monthly Report입니다. 어느 에이전트의 어느 단계에서 얼마가 나갔는지, 지난달 대비 무엇을 바꿔서 얼마가 줄었는지를 숫자로 드립니다. 청구서가 궁금하신 회사는 현재 사용량 로그를 보내주시면 위 다섯 항목을 무료로 한 번 봐드립니다.