ChatGPT API 비용은 가격표 한 줄만 보고 판단하기 어렵습니다. 같은 모델을 써도 input token, output token, context 길이, 캐시 hit 여부, 도구 호출 여부에 따라 실제 비용이 달라집니다.
그래서 비용을 볼 때는 모델 이름보다 먼저 구조를 봐야 합니다. 얼마짜리 모델인가보다 더 중요한 질문은 token이 어디에서 얼마나 생기는가입니다.
OpenAI의 공식 API Pricing, Prompt Caching, Batch API 문서를 기준으로 설명하겠습니다.
ChatGPT API 비용을 볼 때 먼저 나눌 것
ChatGPT API 비용의 기본 단위는 token이다
API 비용은 대체로 요청 횟수만으로 계산되지 않습니다. 모델이 읽은 글자량과 생성한 글자량이 token으로 환산되고, 그 token 수에 모델별 단가가 곱해집니다.
대략적인 비용 감각
비용 = input token 비용 + output token 비용 + 도구/저장소 등 부가 비용
input token = 시스템 지시문 + 대화 기록 + 문서 context + 사용자 질문
output token = 모델이 실제로 생성한 답변여기서 자주 놓치는 부분은 output만 비용이 아니라는 점입니다. 긴 시스템 프롬프트, 긴 RAG 문서, 많은 대화 기록도 모두 input token입니다.
input token과 output token을 따로 봐야 한다
많은 모델은 input token과 output token 단가가 다릅니다. 답변을 짧게 제한해도, 매 요청마다 긴 문서를 넣으면 input 비용이 커질 수 있습니다.
- 챗봇: 대화 기록이 길어질수록 input token이 커진다
- RAG: 검색 문서를 많이 넣을수록 input token이 커진다
- 리포트 생성: 긴 답변을 만들수록 output token이 커진다
- 평가 자동화: 같은 기준표를 반복해서 넣으면 캐시 가능성을 봐야 한다
예를 들어 LLM judge처럼 평가 기준표를 매번 넣는 구조라면, 기준표 자체가 반복 input이 됩니다. 이때는 모델 선택만큼 prompt 구조도 중요합니다.
context window가 크면 비용도 같이 커질 수 있다
context window가 크다는 것은 더 긴 입력을 넣을 수 있다는 뜻이지, 항상 더 싸거나 더 좋은 답을 준다는 뜻은 아닙니다. 긴 context는 모델이 읽어야 하는 input token을 늘립니다.
특히 RAG에서는 검색된 문서를 많이 넣는다고 항상 좋아지지 않습니다. 관련성이 낮은 문서가 섞이면 답변 품질도 흔들리고 비용도 늘어납니다. 그래서 RAG reranking이나 context packing이 비용 관리와도 연결됩니다.
실무에서는 context window를 “넉넉한 저장 공간”처럼 생각하기 쉽습니다. 하지만 API 요청에서는 넣은 만큼 읽는 비용이 생깁니다. 긴 문서를 매번 통째로 넣는 구조라면, 모델을 바꾸기 전에 먼저 문서 자르기, 검색 범위, 요약 캐시, 이전 대화 압축을 봐야 합니다.
간단한 비용 예산은 이렇게 잡는다
정확한 비용은 공식 가격표와 실제 usage 로그를 봐야 합니다. 그래도 설계 단계에서는 대략적인 예산표를 먼저 만들 수 있습니다.
하루 요청 수: 10,000건
평균 input: 2,000 tokens
평균 output: 500 tokens
하루 input tokens = 10,000 * 2,000 = 20,000,000
하루 output tokens = 10,000 * 500 = 5,000,000
월 비용을 보려면
- input 20M * 30일 * 모델 input 단가
- output 5M * 30일 * 모델 output 단가
- 도구 호출, 파일 검색, 저장소 비용을 별도 합산이 표를 만들면 어디를 줄여야 할지 보입니다. output이 비싼 모델이라면 답변 길이 제한이 중요하고, input이 크다면 context 정리와 prompt caching 가능성이 중요합니다.
비용이 예상보다 커지는 흔한 패턴
- 매 요청마다 긴 정책 문서나 매뉴얼 전체를 넣는다
- 대화 기록을 끝없이 이어 붙인다
- 사용자에게 보이지 않는 내부 추론용 답변을 길게 생성한다
- 검색 결과를 많이 넣지만 실제 답변에는 일부만 쓴다
- 실시간이 필요 없는 대량 작업도 동기 API로 처리한다
이 패턴들은 모델 선택보다 구조 문제에 가깝습니다. 그래서 비용 최적화는 “더 싼 모델로 바꾸자”보다 “왜 이렇게 많은 token이 생기나”를 먼저 봐야 합니다.
Prompt Caching은 반복 prefix가 있을 때 의미가 있다
OpenAI 문서에 따르면 Prompt Caching은 반복되는 prompt prefix가 있을 때 자동으로 작동합니다. 긴 시스템 지시문, 공통 예시, 고정된 tool 정의처럼 매번 앞부분이 같으면 캐시 hit 가능성이 생깁니다.
캐시를 기대하려면 고정 내용은 앞에 두고, 사용자별로 달라지는 내용은 뒤에 두는 편이 좋습니다. 단, 캐시는 비용을 없애는 기능이 아니라 반복 input 비용과 지연 시간을 줄일 수 있는 최적화입니다.
예를 들어 모든 요청에 같은 역할 지시문, 같은 출력 형식, 같은 tool 정의가 들어간다면 이 부분은 앞에 고정하는 편이 낫습니다. 반대로 사용자 질문, 검색 결과, 현재 화면 상태처럼 매번 바뀌는 값은 뒤쪽에 두는 것이 캐시 관점에서 유리합니다.
서비스 유형별로 비용이 커지는 지점이 다르다
ChatGPT API 비용을 볼 때 모든 서비스를 한 가지 방식으로 계산하면 빗나가기 쉽습니다. 챗봇, RAG 검색 답변, 대량 분류 작업은 비용이 커지는 지점이 서로 다릅니다.
- 챗봇: 대화 기록과 시스템 지시문이 계속 누적되면서 input token이 커진다
- RAG 답변: 검색 문서와 인용 근거가 많아질수록 input token이 커진다
- 리포트 생성: 긴 결과물을 만들수록 output token이 커진다
- 데이터 분류: 요청 수가 많아져 총 token과 rate limit이 함께 문제가 된다
그래서 비용 최적화도 다르게 해야 합니다. 챗봇은 오래된 대화 요약과 히스토리 절단이 중요하고, RAG는 검색 결과 수와 문서 길이 조절이 중요합니다. 대량 분류는 실시간 처리보다 Batch API가 더 자연스러운지 봐야 합니다.
챗봇 비용 점검
- 최근 대화 몇 턴까지 넣는가?
- 오래된 대화는 요약하는가?
RAG 비용 점검
- 검색 문서 top-k가 너무 크지 않은가?
- chunk 하나가 지나치게 길지 않은가?
대량 처리 비용 점검
- 지금 꼭 실시간 응답이 필요한가?
- 실패한 요청 재처리 전략이 있는가?즉시 응답이 필요 없는 작업은 Batch API를 본다
모든 API 요청이 실시간일 필요는 없습니다. 문서 분류, 대량 평가, embedding 생성처럼 나중에 결과를 받아도 되는 작업은 Batch API가 더 적합할 수 있습니다.
OpenAI Batch API 문서는 비동기 대량 작업에 대해 비용 효율과 별도 rate limit pool을 제공한다고 설명합니다. 대신 사용자에게 바로 답해야 하는 챗봇 응답에는 맞지 않습니다.
실무에서 먼저 계산해볼 질문
- 한 요청에 평균 input token이 얼마나 들어가는가?
- 답변 길이는 평균 몇 token까지 허용할 것인가?
- RAG 문서를 몇 개까지 넣을 것인가?
- 시스템 프롬프트와 tool 정의가 매 요청 반복되는가?
- 즉시 응답이 필요한 작업과 배치 처리 가능한 작업을 나눴는가?
이 질문에 답할 수 있으면 모델 가격표를 훨씬 현실적으로 읽을 수 있습니다.
정리
ChatGPT API 비용은 모델 단가 하나로 끝나지 않습니다. input token, output token, context 길이, prompt caching, Batch API, 도구 호출 비용을 나눠서 봐야 합니다.
처음부터 가장 싼 모델만 찾기보다, 어떤 token이 반복되고 어떤 token이 꼭 필요한지 줄이는 것이 더 오래 가는 비용 관리 방법입니다.
