GPT, Claude, Gemini API를 서비스에 붙이기 전에 가장 막막한 질문은 “한 달에 얼마 나올까”입니다. 토큰 단위 종량제라 콘솔 대시보드를 보기 전까진 감이 잘 안 잡히고, 막상 청구서를 받고 놀라는 경우도 흔합니다. 이 글은 GPT·Claude·Gemini API의 월 비용을 직접 계산하는 공식과 재사용 가능한 계산기 코드, 그리고 프롬프트 캐싱·배치 API로 실제 비용을 줄이는 방법을 다룹니다. 정확한 단가는 각 사가 수시로 조정하므로 이 글에서는 “숫자를 대입하면 답이 나오는 계산 틀”을 드리고, 최신 단가는 공식 문서에서 확인하는 방식을 권합니다.
왜 “일단 써보면” 비용 예측이 안 될까
GPT·Claude·Gemini API는 모두 입력 토큰과 출력 토큰에 서로 다른 단가를 매기는 종량제 구조입니다. 출력 토큰 단가가 입력 토큰보다 3~5배 비싼 경우가 많아서, 같은 1만 요청이라도 답변이 긴 서비스(요약, 코드 생성, 리포트 작성)와 답변이 짧은 서비스(단순 분류, 태깅)의 월 비용이 크게 갈립니다.
여기서 ‘토큰’은 단어 그대로가 아니라 모델이 텍스트를 쪼개는 최소 단위로, 한글은 영어보다 토큰 소모가 많은 편입니다. 토큰화 개념 자체를 처음 접한다면 위키백과의 토큰화(자연어 처리) 문서를 참고하면 원리를 빠르게 잡을 수 있습니다.
또 하나 예측을 어렵게 만드는 요소는 시스템 프롬프트, RAG로 붙이는 검색 결과, 대화 히스토리입니다. 사용자가 입력창에 치는 텍스트는 몇 줄이어도, 실제로 API에 전송되는 입력 토큰에는 이 부가 컨텍스트가 전부 포함됩니다. 그래서 월 비용을 계산하려면 “사용자가 보는 입력”이 아니라 “API가 실제로 받는 입력”의 평균 토큰 수를 기준으로 삼아야 합니다.
월 비용 계산 공식과 셀프 계산기 코드
기본 공식은 단순합니다.
월 비용 = 요청 수 × (평균 입력 토큰 / 1,000,000 × 입력 단가
+ 평균 출력 토큰 / 1,000,000 × 출력 단가)
여기에 캐싱 적중률과 배치 사용 여부를 변수로 추가하면 실무에서 바로 쓸 수 있는 계산기가 됩니다. 아래는 파이썬으로 만든 간단한 버전입니다. 단가(price_in, price_out)는 설명을 위한 예시값이므로, 실제 계산 시에는 사용 중인 모델의 최신 단가로 반드시 교체해야 합니다.
def monthly_cost(requests, avg_input, avg_output,
price_in, price_out,
cache_ratio=0.0, cache_discount=0.9,
batch_discount=0.0):
cached_tokens = avg_input * cache_ratio
normal_tokens = avg_input * (1 - cache_ratio)
input_cost = (normal_tokens / 1_000_000 * price_in
+ cached_tokens / 1_000_000 * price_in * (1 - cache_discount))
output_cost = avg_output / 1_000_000 * price_out
total_per_request = input_cost + output_cost
total = total_per_request * requests
total *= (1 - batch_discount)
return round(total, 2)
# 예시 단가: 입력 $3/1M, 출력 $15/1M (설명용 임의값)
base = monthly_cost(10000, 1500, 500, price_in=3, price_out=15)
cached = monthly_cost(10000, 1500, 500, price_in=3, price_out=15,
cache_ratio=0.7, cache_discount=0.9)
cached_batch = monthly_cost(10000, 1500, 500, price_in=3, price_out=15,
cache_ratio=0.7, cache_discount=0.9,
batch_discount=0.5)
print(base, cached, cached_batch)
실행 결과: 120.0 91.65 45.83
같은 1만 요청이라도 캐싱과 배치를 함께 적용하면 예시 단가 기준으로 비용이 약 62% 줄어드는 것을 볼 수 있습니다. 이 계산기의 핵심은 정확한 단가를 맞히는 게 아니라, 캐시 적중률과 배치 비율을 바꿔가며 “어떤 최적화가 우리 서비스에 실질적으로 효과가 있는지”를 미리 시뮬레이션해볼 수 있다는 점입니다.
1만 요청, 요청 유형별로 얼마나 달라지나
1만 요청이라는 숫자는 같아도 요청 유형에 따라 평균 입출력 토큰 규모가 크게 다릅니다. 아래는 서비스 유형별 대략적인 토큰 규모 범위입니다. 실제 값은 프롬프트 설계에 따라 달라지므로, 자체 로그에서 평균 토큰 수를 직접 뽑아보는 것이 가장 정확합니다.
| 요청 유형 | 평균 입력 토큰(대략) | 평균 출력 토큰(대략) | 비용에 미치는 영향 |
|---|---|---|---|
| 단순 분류/태깅 챗봇 | 200~500 | 20~100 | 출력이 짧아 전체 비용이 낮음 |
| 고객 상담 챗봇(히스토리 포함) | 1,000~3,000 | 200~500 | 대화가 길어질수록 입력 토큰이 누적 |
| RAG 문서 요약/QA | 2,000~8,000 | 300~800 | 검색된 문서 청크가 입력 비용을 지배 |
| 코드 생성/리팩터링 | 1,500~5,000 | 500~2,000 | 출력 단가가 비싸 총비용에 큰 영향 |
이 표에서 알 수 있는 실무 포인트는, 입력 토큰을 줄이는 최적화(불필요한 히스토리 자르기, RAG 청크 수 조정)와 출력 토큰을 줄이는 최적화(응답 형식을 JSON으로 강제해 군더더기 문장 제거, max_tokens 상한 설정)의 효과가 서비스 유형마다 다르다는 것입니다. RAG형 서비스는 입력 최적화가 우선이고, 코드 생성형 서비스는 출력 최적화가 우선입니다.
프롬프트 캐싱으로 입력 비용 줄이기
시스템 프롬프트, 고정된 few-shot 예시, RAG 문서처럼 요청마다 반복되는 입력 부분이 있다면 프롬프트 캐싱이 가장 확실한 절감 수단입니다. Anthropic Claude는 캐시에 처음 쓸 때(cache write)는 기본 입력 단가보다 약간 비싸게, 이후 같은 내용을 다시 읽을 때(cache read)는 대폭 할인된 단가로 처리하는 구조를 공식 문서에서 안내하고 있습니다. 구조와 조건은 Anthropic 공식 프롬프트 캐싱 문서에서 확인할 수 있습니다.
OpenAI GPT 계열도 일정 길이 이상의 반복 입력에 대해 캐시 적중 시 할인 단가를 자동 적용하는 방식을 제공하며, Gemini도 컨텍스트 캐싱 기능을 통해 반복되는 대용량 컨텍스트(긴 시스템 프롬프트, 문서 전체)를 별도 저장해두고 재사용 시 비용을 낮추는 구조를 갖고 있습니다. 세 회사 모두 세부 할인율·캐시 유지 시간·최소 토큰 조건이 다르고 수시로 조정되므로, 서비스에 적용하기 직전에는 반드시 해당 모델의 최신 공식 문서에서 조건을 재확인하는 것이 안전합니다.
캐싱 효과를 극대화하려면 프롬프트 설계 단계에서 “자주 안 변하는 내용(시스템 지시문, 고정 예시)”을 앞쪽에, “매번 바뀌는 내용(사용자 질문)”을 뒤쪽에 배치하는 순서 규칙을 지키는 것이 중요합니다. 대부분의 캐싱 구현이 프롬프트 앞부분부터 일치하는 만큼만 캐시로 인정하기 때문입니다.
배치 API로 실시간이 아닌 작업 비용 낮추기
즉시 응답이 필요 없는 작업(야간 배치 요약, 대량 데이터 라벨링, 리포트 사전 생성)이라면 배치 API를 검토할 가치가 있습니다. OpenAI, Anthropic, Google 세 회사 모두 별도의 배치 처리 엔드포인트를 제공하며, 실시간 응답 대신 일정 시간(대체로 24시간 이내) 안에 결과를 모아 돌려주는 방식으로 표준 단가 대비 상당한 할인을 적용하는 구조를 채택하고 있습니다. 정확한 할인율과 처리 시간 조건은 제공사·시점별로 다를 수 있으므로 도입 전 해당 API의 배치 문서를 직접 확인해야 합니다.
배치 API는 비용 절감 폭이 크지만 실시간 응답이 아니라는 제약이 있으므로, 서비스를 실시간 처리용과 배치 처리용으로 나눠 설계하는 것이 실무적으로 유리합니다. 예를 들어 사용자 질문에 즉시 답해야 하는 챗봇 경로는 표준 API로, 매일 새벽 쌓인 로그를 요약해 리포트를 만드는 경로는 배치 API로 분리하면 같은 총 요청량이라도 월 비용을 크게 줄일 수 있습니다. 위 계산기 코드의 batch_discount 인자에 실제 확인한 할인율을 넣어보면 이 경로 분리가 얼마나 이득인지 바로 시뮬레이션할 수 있습니다.
정리 및 다음 단계
GPT·Claude·Gemini API의 월 비용은 “요청 수 × (입력 토큰×입력 단가 + 출력 토큰×출력 단가)”라는 단순한 공식에서 출발하되, 실제로는 반복 컨텍스트를 얼마나 캐싱하는지, 실시간이 필요 없는 작업을 얼마나 배치로 돌리는지에 따라 최종 청구액이 몇 배씩 차이 납니다. 오늘 바로 할 수 있는 다음 단계는 세 가지입니다. 첫째, 최근 1주일치 API 로그에서 평균 입력·출력 토큰 수를 뽑아 위 계산기 코드에 대입해봅니다. 둘째, 반복되는 시스템 프롬프트나 RAG 컨텍스트가 있다면 캐싱 적용 전후 비용을 비교해봅니다. 셋째, 즉시 응답이 필요 없는 작업을 골라내 배치 API로 옮길 수 있는지 확인합니다.
자주 묻는 질문(FAQ)
Q1. 입력 토큰과 출력 토큰 단가가 왜 이렇게 차이가 나나요?
출력 토큰은 모델이 매 토큰마다 새로 추론(생성)해야 하는 반면, 입력 토큰은 한 번에 병렬로 처리되는 연산 특성 차이 때문에 대부분의 제공사가 출력 단가를 입력 단가보다 높게 책정합니다. 그래서 답변 길이를 제어하는 것이 비용 절감에 직접적인 효과를 냅니다.
Q2. 캐싱을 적용했는데 비용이 기대만큼 안 줄어요.
캐시는 보통 프롬프트의 앞부분부터 완전히 일치하는 구간까지만 적용됩니다. 사용자 질문이나 타임스탬프 같은 가변 요소를 프롬프트 맨 앞이나 중간에 두면 캐시가 매번 깨질 수 있으므로, 고정 컨텍스트를 앞으로, 가변 입력을 뒤로 재배치했는지 먼저 점검하는 것이 좋습니다.
Q3. 배치 API는 어떤 작업에 적합한가요?
사용자가 실시간으로 응답을 기다리지 않는 작업, 예를 들어 야간 데이터 라벨링, 대량 문서 요약, 정기 리포트 생성처럼 결과를 몇 시간 뒤에 받아도 되는 작업에 적합합니다. 반대로 채팅 UI처럼 즉시 응답이 필요한 경로에는 표준 API를 유지하는 것이 좋습니다.