AI 기능을 붙인 첫 달 청구서는 대개 조용합니다. 테스트 트래픽이 적고, 입력도 짧고, 쓰는 사람도 몇 명뿐입니다. 문제는 그 다음 달입니다.
고객이 PDF를 올리기 시작하고, 대화창을 닫지 않고 하루를 쓰고, 오류가 나면 버튼을 세 번 누릅니다. 같은 기능인데 금액은 몇 배가 됩니다. 토큰 과금은 사용자 수가 아니라 주고받은 글자 수로 매겨지기 때문입니다.
토큰 과금은 요청마다 입력 전체를 다시 보내는 구조입니다
API 요금은 입력 토큰과 출력 토큰을 각각 백만 토큰(MTok) 단위로 셉니다. 2026년 10월 14일 Anthropic 공식 요금 문서 기준으로 Claude Opus 5.5는 입력 $4 / 출력 $20, Sonnet 5.5는 $2 / $10, Haiku 5.5는 $0.10 / $0.50입니다.
세 모델 모두 출력 단가가 입력의 5배입니다. 그래서 답을 길게 쓰게 하는 프롬프트가 가장 먼저 요금을 밀어 올립니다.
그리고 API는 대화를 기억하지 않습니다. 이전 내용을 이어가려면 매 요청에 지금까지의 대화를 전부 다시 실어 보내야 하고, 그 전체가 매번 입력 토큰으로 과금됩니다. 요금이 터지는 세 가지 경로는 모두 이 구조에서 나옵니다.
첫 번째 경로는 입력에 문서를 붙이기 시작하는 순간입니다
Claude 4.6 이후 모델은 Haiku 5.5를 빼고 100만 토큰 컨텍스트를 표준 단가로 제공합니다. 공식 문서 표현대로 90만 토큰 요청도 9천 토큰 요청과 같은 단가로 계산됩니다. 길게 보내도 막히지 않고, 그대로 비례해서 비싸진다는 뜻입니다.
Haiku 5.5에는 경계가 하나 더 있습니다. 프롬프트가 10만 토큰을 넘으면 입력이 $0.10에서 $0.50으로, 출력이 $0.50에서 $2.50으로 다섯 배 올라갑니다. 첨부 파일 한 건 때문에 단가 구간이 바뀌는 셈입니다.
그래서 첨부 기능은 길이 제한과 함께 설계해야 합니다. 토큰 수를 미리 세는 전용 API는 무료이고 메시지 생성과 별도 한도를 쓰므로, 보내기 전에 길이를 재서 거부하거나 잘라내는 쪽이 싸게 끝납니다.
두 번째 경로는 재시도와 도구 호출이 겹치는 구간입니다
분당 한도는 토큰 버킷 방식으로 계산됩니다. 분당 60회 한도가 사실상 초당 1회로 적용될 수 있어서, 짧은 순간에 몰린 요청은 429 오류를 받습니다. 이때 응답의 retry-after 헤더가 몇 초 뒤에 다시 보내야 하는지 알려줍니다.
문제는 재시도를 코드가 알아서 한다는 점입니다. 공식 SDK에는 자동 재시도가 들어 있어서, 화면에서 한 번 누른 작업이 뒤에서 여러 번 성공할 수 있습니다. 도구 호출을 쓰는 기능은 질문 하나가 모델 호출 다섯 번, 열 번으로 늘어나고 그 사이 입력이 계속 누적됩니다.
요금이 터질 때 범인은 비싼 모델이 아니라, 사람이 한 번 누른 버튼이 뒤에서 열 번 호출되는 코드입니다.
세 번째 경로는 대화가 길어질수록 입력이 제곱으로 쌓이는 것입니다
대화가 20턴이면 20번째 요청은 1턴부터 19턴까지를 전부 입력에 포함합니다. 턴마다 길이가 비슷하게 늘어난다고 보면 누적 입력량은 턴 수의 제곱에 가깝게 증가합니다. 사용자가 창을 닫지 않아도 되는 설계는 그 자체로 요금 설계입니다.
추론 과정을 켜 둔 경우도 같습니다. Opus 4.5, Sonnet 4.6, Haiku 5.5 이후 모델은 이전 턴의 thinking 블록을 그대로 유지하고, 그 블록도 입력 토큰으로 계산됩니다.
서버 쪽에서 잘라내는 기능이 있습니다. 컨텍스트 편집(베타)은 기본값으로 입력 10만 토큰을 넘으면 오래된 도구 결과부터 지우고 최근 3개만 남깁니다. 공식 문서 예시에서는 7만 토큰 요청이 2만 5천 토큰으로 줄었습니다.
상한은 조직 한도, 내가 정한 금액, 워크스페이스 세 겹으로 겁니다
조직에는 등급별 월 지출 상한이 이미 걸려 있습니다. Start는 월 $500, Build는 $1,000, Scale은 $200,000이고 Custom 등급은 상한이 없습니다. 이 상한에 닿으면 다음 달 1일 00:00 UTC까지 API 사용이 멈춥니다.
여기에 내가 정한 금액을 더 낮게 걸 수 있습니다. 콘솔 결제 설정의 지출 한도에서 등급 상한 이하 값으로 지정하는 방식입니다. 두 상한은 응답이 다릅니다. 등급 상한은 429를, 직접 설정한 상한은 400을 돌려줍니다.
이 차이가 운영에서 중요합니다. 등급 상한의 429에는 retry-after 헤더가 없어서 재시도 코드가 돌아도 전부 실패합니다. 기능별로 워크스페이스를 나누면 지출과 분당 한도를 따로 걸 수 있지만, 기본 워크스페이스에는 걸 수 없습니다.
- 조직 등급 상한 — 확인만 하고 직접 손댈 수 없습니다
- 직접 설정한 월 지출 상한 — 실제 월 예산 금액으로 잡으세요
- 워크스페이스별 지출·분당 한도 — 사내용과 고객용을 분리하세요
- 분당 요청·토큰 한도 — 폭주를 분 단위에서 끊습니다
분당 요청 제한은 사고를 분 단위에서 끊어줍니다
분당 한도는 요청 수(RPM), 입력 토큰(ITPM), 출력 토큰(OTPM) 세 가지로 모델마다 따로 적용됩니다. Start 등급에서 Opus 5.5와 Sonnet 5.5, Haiku 5.5는 1,000 RPM, 200만 ITPM, 40만 OTPM이고, Build는 5,000 / 500만 / 100만, Scale은 10,000 / 1,000만 / 200만입니다.
중요한 점이 하나 있습니다. 캐시에서 읽은 입력 토큰은 Haiku 3.5를 빼면 ITPM에 포함되지 않습니다. 공식 문서 예시로 200만 ITPM에 캐시 적중률 80%면 분당 1,000만 토큰까지 처리할 수 있습니다.
응답 헤더의 anthropic-ratelimit-input-tokens-remaining 같은 값을 로그에 남겨두세요. 한도에 얼마나 붙어 있는지 월말이 아니라 당일에 알 수 있습니다.
프롬프트 캐싱은 조건이 맞을 때만 단가를 내립니다
캐싱은 반복되는 앞부분을 저장해 두고 다시 쓰는 방식입니다. 저장할 때는 기본 입력 단가의 1.25배(5분 보관) 또는 2배(1시간 보관)를 내고, 적중하면 기본 입력가의 0.1배만 냅니다. Opus 5.5와 Sonnet 5.5는 적중 단가가 0.05배라서 Sonnet 5.5는 $2가 $0.10이 됩니다.
조건이 있습니다. 캐싱되는 최소 길이는 Opus 5.5와 Sonnet 5.5, Haiku 5.5가 512토큰, Sonnet 5는 1,024토큰, Opus 4.5와 Haiku 4.5는 4,096토큰입니다. 이보다 짧으면 오류도 없이 그냥 캐싱되지 않습니다.
보관 기간은 기본 5분이고, 쓸 때마다 추가 비용 없이 5분이 다시 연장됩니다. 반대로 5분 안에 다시 쓰이지 않으면 1.25배를 내고 버리는 셈입니다. 트래픽이 띄엄띄엄한 기능에는 캐싱이 손해입니다.
배치 처리는 50%를 받고 24시간을 내주는 거래입니다
Batch API는 입력과 출력 모두 50% 할인됩니다. 대신 비동기입니다. 대부분 1시간 안에 끝나지만 결과는 전부 완료되거나 24시간이 지나야 받을 수 있고, 24시간 안에 처리되지 않은 요청은 만료되며 만료분은 과금되지 않습니다.
한 배치에는 10만 건 또는 256MB까지 담을 수 있습니다. 배치 할인과 캐싱 할인은 중첩됩니다. 다만 배치 안에서는 캐시를 미리 데워두는 호출이 지원되지 않습니다.
그래서 배치는 야간 분류, 리뷰 요약, 일괄 태깅처럼 내일 아침까지면 되는 작업에만 씁니다. 채팅 응답이나 검색 자동완성에는 쓸 수 없습니다.
기능별로 모델을 나누는 기준을 먼저 정하세요
단가 차이가 기준을 만들어 줍니다. Haiku 5.5는 Opus 5.5보다 입력과 출력이 모두 40배 저렴하고, Sonnet 5.5는 Opus 5.5의 절반입니다. 같은 작업을 Opus로 돌리면 40배를 내는 것입니다.
나누는 기준은 틀렸을 때 사람이 바로 알아채는지 여부입니다. 분류, 추출, 태깅, 라우팅처럼 결과가 짧고 검증이 쉬운 일은 Haiku로 충분합니다. 고객에게 바로 나가는 답변 생성은 Sonnet, 계약서 검토나 코드 수정처럼 틀리면 되돌리기 어려운 일만 Opus로 올리세요.
단가를 올리는 옵션도 확인해야 합니다. 응답 속도를 높이는 fast mode는 Opus 5.5에서 입력 $8 / 출력 $40으로 두 배이고, 추론 지역을 미국으로 고정하면 모든 토큰 단가에 1.1배가 붙습니다.
계약서에는 단가가 아니라 정산 방식을 적으세요
AI 사용료를 월 고정액으로 받으면 사용량 위험을 개발사가 전부 안게 됩니다. 반대로 실비 정산이라고만 적어두면 고객이 상한 없는 청구서를 받습니다. 양쪽을 막으려면 네 가지를 문서에 넣으세요.
- 정산 단위: 공급사 공식 단가 기준 실사용 토큰 금액에 적용 환율과 대행 수수료율을 명시합니다
- 월 상한: 합의한 금액을 지출 상한으로 설정하고, 도달 시 기능이 정지된다는 사실을 함께 적습니다
- 초과 승인: 상한 상향은 고객 서면 동의 후에만 한다고 적습니다
- 단가 변동: 공급사 단가 변경이나 모델 교체 시 정산 단가도 바뀐다고 적습니다
근거 자료도 정해 두세요. 콘솔 사용량 페이지에서 모델별 토큰과 캐시 적중률을 볼 수 있으니, 월 정산서에 그 수치를 첨부하는 방식이 분쟁을 줄입니다. 캐싱과 배치로 아낀 금액이 누구 몫인지도 미리 정해야 합니다.
상한만으로 해결되지 않는 경우도 있습니다
상한은 결국 서비스 정지 장치입니다. 등급 상한에 닿으면 다음 달 1일까지 멈추고, 직접 설정한 상한은 올리거나 풀어야 복구됩니다. 결제나 배송 안내처럼 멈추면 안 되는 흐름에 AI를 넣었다면, 상한보다 모델 없이도 동작하는 대체 경로를 먼저 만들어야 합니다.
캐싱도 만능이 아닙니다. 컨텍스트 편집으로 오래된 내용을 지우면 그 지점의 캐시가 무효화되어 다시 저장하는 비용이 발생합니다. 또 Claude 4.7 이후 모델은 토크나이저가 바뀌어 같은 글이 이전 모델보다 약 30% 많은 토큰으로 계산되므로, 예전 측정값으로 비용을 추정하면 어긋납니다.
숫자는 공급사 공식 문서에서 직접 확인하세요. Anthropic 공식 요금 문서와 실무 가이드 카테고리를 함께 보시고, 상한 설정과 모델 분리를 실제 서비스에 적용하는 일은 Codeforest로 문의하세요.
결론: 상한을 먼저 걸고, 그다음에 단가를 내리세요
요금이 터지는 경로는 셋입니다. 입력이 길어지고, 호출이 반복되고, 대화가 누적됩니다. 세 경로 모두 입력 토큰에서 만나기 때문에 첨부 길이 제한, 재시도 횟수 제한, 대화 길이 제한 세 가지를 코드에 박아두는 것이 효과가 가장 큽니다.
그 위에 월 지출 상한과 분당 한도를 걸고, 조건이 맞는 기능에만 캐싱과 배치를 적용하세요. 계약서에는 월 상한 금액과 상한 도달 시 정지된다는 조항을 함께 적어두세요. 다음 달 청구서를 예측 가능하게 만드는 것은 할인율이 아니라 이 상한입니다.
