LLM API 비용 예측 가이드: AI 기능 실서비스 전 토큰·캐싱·트래픽 계산 기준
답부터 말하면, LLM API 비용은 ‘어떤 모델이 100만 토큰당 얼마인가’만 보면 예측할 수 없습니다. 실서비스 비용은 월 트래픽, 요청당 LLM 호출 수, 일반 입력 토큰, 캐시 입력 토큰, 출력 토큰, RAG 문서 길이, 도구 호출, 에이전트 반복 횟수, 실패 재시도율이 곱해져 만들어집니다. 따라서 AI 챗봇, 사내 검색, 상담 자동화, 코드 보조, 업무 에이전트를 붙이기 전에는 모델 선택보다 먼저 사용 패턴 예산표를 만들어야 합니다.
최근 주요 LLM API 문서는 입력·캐시 입력·출력 토큰을 분리하고, Batch·Flex·Priority 같은 처리 티어와 도구 호출 비용을 별도 항목으로 안내합니다. OpenAI 가격표는 Standard, Batch, Flex, Priority와 input, cached input, output 축을 구분하고 도구 호출 비용도 별도로 설명합니다. ([platform.openai.com](https://platform.openai.com/docs/pricing/)) Anthropic은 base input, cache write, cache hit, output을 나누며, Gemini도 context caching과 Batch, Flex, Priority, grounding 관련 비용을 분리해 안내합니다. ([docs.anthropic.com](https://docs.anthropic.com/en/docs/about-claude/pricing?4810b549_page=3&73cdfb14_page=2&939688b5_page=1&e768fcd2_page=2)) 이 글은 대표·PM·마케터·비개발 의사결정자가 실제 견적 전 단계에서 월 운영비를 가늠할 수 있도록 계산 기준을 정리한 가이드입니다.

1. PoC 비용이 실서비스 비용을 대표하지 않는 이유
PoC에서는 질문 몇 개를 던져보고 ‘생각보다 싸다’고 판단하기 쉽습니다. 그러나 운영 서비스에서는 프롬프트가 길어지고, 사용자가 남긴 대화 이력과 검색 문서가 붙고, 실패 재시도와 평가 로그가 생깁니다. 특히 RAG 기반 사내 검색이나 상담 자동화는 사용자의 한 문장보다 시스템 지시문, 검색된 문서 chunk, 상담 정책, 금칙어, 응답 형식 지시가 더 많은 토큰을 차지하는 경우가 많습니다. RAG 구조 자체가 궁금하다면 먼저 RAG 엔터프라이즈 구현 기준을 함께 보는 것이 좋습니다.
- 시스템 프롬프트 증가: 말투, 금지 답변, 출처 표기, 개인정보 처리, 브랜드 톤이 붙으면서 고정 지시문이 길어집니다.
- RAG 문서 주입: top-k 검색 결과, 문서 제목, 본문, 메타데이터, 출처 링크가 입력 토큰을 늘립니다.
- 대화 이력 누적: 멀티턴 상담에서는 이전 질문과 답변이 다시 입력으로 들어갑니다.
- 도구 호출과 에이전트 루프: CRM 조회, 견적 계산, 캘린더 예약, DB 검색을 LLM이 여러 번 호출하면 한 사용자 행동이 여러 API 호출로 확장됩니다.
- 운영 안전장치: 재시도, moderation, 평가용 샘플링, 관리자 검수 로그도 비용표에 포함해야 합니다.
PoC 단계의 단건 비용은 ‘기능이 가능한가’를 보는 숫자입니다. 실서비스 비용은 ‘동일 기능이 하루 수천 번 호출될 때도 총마진을 해치지 않는가’를 보는 숫자입니다.
2. 월간 비용 산식: 트래픽을 바로 비용으로 바꾸지 말고 호출 단위로 쪼개기

LLM 비용표는 다음 흐름으로 작성하는 것이 실무적으로 안전합니다. 방문자 수에서 바로 월 비용을 계산하지 말고, 사용자가 어떤 행동을 할 때 LLM이 몇 번 호출되는지 먼저 세야 합니다. 같은 AI 챗봇이라도 ‘첫 답변 1회’만 생성하는 구조와 ‘질문 의도 분류 → 검색 질의 재작성 → RAG 답변 생성 → 출처 검증’ 구조는 호출 수가 다릅니다.
| 항목 | 확인 질문 | 측정 방법 | 비용 영향 |
|---|---|---|---|
| 월 요청 수 | 한 달에 AI 기능을 몇 번 쓰는가? | MAU가 아니라 AI 버튼 클릭, 상담 세션, 문서 검색 수로 집계 | 전체 비용의 기본 배수 |
| 요청당 LLM 호출 수 | 사용자 행동 1회가 API 몇 번으로 처리되는가? | 의도 분류, 검색 재작성, 답변 생성, 검증 단계를 분리 | 에이전트·RAG에서 과소추정되기 쉬움 |
| 일반 입력 토큰 | 매번 새로 처리되는 입력은 얼마인가? | 사용자 질문, RAG chunk, 대화 이력, 도구 결과를 합산 | 검색 문서와 히스토리가 길수록 증가 |
| 캐시 입력 토큰 | 반복되는 prefix가 실제로 캐시에 맞는가? | provider usage 필드에서 cached token을 확인 | 정적 프롬프트가 길수록 절감 여지 증가 |
| 출력 토큰 | 답변을 얼마나 길게 생성하는가? | max output, 요약 길이, 표 생성 여부를 정책화 | 출력 단가가 높은 모델에서는 핵심 비용 |
| 도구 호출 | 검색, 파일 검색, 코드 실행, 외부 API를 몇 번 부르는가? | tool call 로그와 LLM loop count를 함께 저장 | 토큰 외 별도 과금 또는 추가 입력 토큰 발생 |
| 재시도율 | 타임아웃·rate limit·형식 오류가 얼마나 나는가? | 실패 코드별 retry 로그 측정 | 운영 초기에 10~30% 여유분을 별도 시나리오로 둠 |
기본 산식
월 API 비용은 아래처럼 분리해서 계산합니다. 단가는 실제 선택 모델의 최신 pricing 페이지에서 가져오고, 원화 예산은 회사 내부 환율·카드 수수료·세무 처리 기준을 따로 적용하는 편이 안전합니다.
월 LLM 비용 = Σ[월 호출 수 × {(일반 입력 토큰 × input 단가) + (캐시 입력 토큰 × cached input 단가) + (출력 토큰 × output 단가)} ÷ 1,000,000] + 도구 호출 비용 + 캐시 저장 비용 + 재시도·평가 여유분
OpenAI는 비동기 작업에 Batch API를 제공하며 가이드에서 동기 API 대비 50% 낮은 비용과 24시간 처리 창을 안내합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/batch/?utm_source=openai)) OpenAI 비용 최적화 문서도 요청 수 감소, 토큰 최소화, 더 작은 모델 선택, Batch와 Flex 처리를 비용 절감 수단으로 제시합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/cost-optimization)) 즉, 실시간 UX와 배치 작업을 한 줄 단가로 섞어 계산하면 예측이 틀어집니다.
3. 기능별 토큰 예산: 어떤 AI 기능이 무엇 때문에 비싸지는가
다음 표는 기획자가 초기에 잡아야 할 토큰 예산의 기준입니다. 정확한 숫자는 실제 프롬프트와 샘플 데이터로 token counter를 돌려야 하지만, 무엇이 비용을 밀어 올리는지는 기능 유형별로 어느 정도 예측할 수 있습니다.
| 기능 유형 | 비용을 키우는 요소 | 초기 설계 기준 |
|---|---|---|
| 웹사이트 AI 챗봇 | 브랜드 톤, FAQ, 상담 정책, 대화 이력 | 답변 길이를 제한하고, FAQ 검색 결과는 필요한 chunk만 넣습니다. |
| 사내 검색·RAG | 문서 chunk 수, chunk 길이, 출처 메타데이터 | top-k를 무조건 높이지 말고 중복 제거와 요약 주입을 검토합니다. |
| 상담 자동화 | 고객 상태 조회, 정책 판단, CRM 도구 호출 | 저위험 질문은 자동 답변, 고위험 질문은 상담원 전환 기준을 둡니다. |
| 코드 보조 | 파일 컨텍스트, diff, 테스트 결과, 긴 코드 출력 | 저장소 전체를 넣지 말고 변경 파일·관련 파일 중심으로 제한합니다. |
| 업무 에이전트 | 계획 수립, 도구 호출, 실패 후 재계획, 반복 루프 | loop 최대 횟수, 도구별 timeout, 승인 단계가 비용 통제 장치입니다. |
특히 MCP나 사내 API를 연결한 업무 에이전트는 ‘답변 1회’가 아니라 ‘생각 → 도구 호출 → 결과 해석 → 다음 도구 호출 → 최종 답변’ 구조가 됩니다. 업무 시스템 연결 전 보안과 호출 경계를 정해야 한다면 MCP 서버 구축 전 체크리스트를 참고하세요.
4. 캐싱은 공짜 절감 버튼이 아니라 프롬프트 구조 문제입니다

프롬프트 캐싱은 반복되는 긴 prefix를 더 낮은 비용과 지연시간으로 처리하기 위한 장치입니다. 하지만 캐싱은 ‘켜기만 하면 절감’되는 기능이 아닙니다. 시스템 지시문, 예시, 도구 정의, 고정 문서처럼 반복되는 내용을 앞에 두고, 사용자별 질문·시간값·검색 결과처럼 변하는 내용을 뒤에 둬야 캐시가 맞습니다. OpenAI 문서는 캐시 히트가 정확한 prefix 매칭에서 가능하며 정적 콘텐츠를 앞에, 변동 콘텐츠를 뒤에 두라고 설명합니다. 또한 1024 토큰 이상 프롬프트에서 자동 캐싱이 동작한다고 안내합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/prompt-caching))
| 구분 | 캐싱 방식 | 비용표에 넣을 항목 | 주의점 |
|---|---|---|---|
| OpenAI 계열 | 최근 모델에서 자동 prompt caching 중심 | 일반 input과 cached input을 분리 | 동일 prefix가 짧은 시간에 반복되어야 하며, 도구·이미지·구조화 출력 schema도 prefix 변동 요인이 될 수 있음 |
| Anthropic Claude | 자동 caching 또는 명시적 cache breakpoint | base input, 5분 cache write, 1시간 cache write, cache hit을 분리 | 기본 5분 TTL, 1시간 TTL은 추가 비용. 5분 write는 base input의 1.25배, 1시간 write는 2배, cache read는 0.1배로 안내됨 ([docs.claude.com](https://docs.claude.com/en/docs/build-with-claude/prompt-caching?_bhlid=b8c18e03b1a33b4448fd0488e89cafa0e5db4c14)) |
| Gemini | Gemini 2.5 이상 implicit caching, 대부분 모델에서 explicit caching | cached token 단가와 storage duration 비용을 분리 | 명시적 캐시는 TTL이 있으며 기본값은 1시간으로 안내됩니다. 캐시 토큰 수와 저장 시간, 일반 입력·출력 비용을 함께 봐야 합니다. ([ai.google.dev](https://ai.google.dev/gemini-api/docs/caching/)) |
캐시 히트율을 예측할 때 보는 질문
- 고정 시스템 프롬프트가 최소 캐싱 기준을 넘을 만큼 긴가?
- 사용자별 이름, 현재 시각, 세션 ID가 프롬프트 앞부분에 섞여 있지 않은가?
- RAG 문서 순서가 매번 달라져 prefix가 깨지지 않는가?
- 도구 정의와 tool choice가 요청마다 동일하게 유지되는가?
- 사용자가 5분, 1시간 등 캐시 TTL 안에서 후속 질문을 할 가능성이 있는가?
Gemini 문서는 token counting에서 입력, 출력, cached content, thinking token을 usage metadata로 확인할 수 있다고 설명합니다. ([ai.google.dev](https://ai.google.dev/gemini-api/docs/tokens)) 실무에서는 ‘캐싱을 적용했다’가 아니라 ‘지난 7일간 cached token 비율이 몇 %였는지’를 관리자 화면에 보여줘야 합니다.
5. 모델 조합은 ‘한 모델’이 아니라 라우팅표로 정합니다
AI 기능 견적에서 자주 나오는 실수는 모든 요청을 가장 똑똑한 모델 하나로 보내는 것입니다. 정확도는 올라갈 수 있지만, 의도 분류나 간단한 요약까지 고성능 모델을 쓰면 단위 경제성이 빨리 무너집니다. 모델 라우팅은 다음처럼 기능 단계별로 나누는 것이 현실적입니다.
| 단계 | 모델 선택 방향 | 상위 모델로 올리는 조건 |
|---|---|---|
| 의도 분류·라벨링 | 저비용·저지연 모델 | 분류 confidence가 낮거나 민감 카테고리일 때 |
| 검색 질의 재작성 | 작은 모델 또는 규칙 기반 | 검색 결과가 없거나 사용자가 전문 용어를 입력했을 때 |
| RAG 답변 생성 | 중간 성능 모델 | 복수 문서 충돌, 법무·의료·계약 등 고위험 답변일 때 |
| 코드·분석·계획 수립 | 추론 성능이 높은 모델 | 테스트 실패, 긴 의존성 분석, 다단계 도구 호출이 필요할 때 |
| 평가·로그 분석 | Batch 또는 Flex 처리 가능한 모델 | 실시간 사용자 응답에 영향이 없을 때 |
이 라우팅표는 개발 범위를 줄이는 도구이기도 합니다. 정부지원사업 MVP나 초기 SaaS라면 모든 AI 기능을 한 번에 넣기보다, 사용자가 비용을 지불할 핵심 행동부터 정해야 합니다. 기능 우선순위 판단은 MVP 기능 우선순위 매트릭스 설계와 함께 정리하면 예산 낭비를 줄일 수 있습니다.
6. Batch, Flex, Priority는 월 비용표에 별도 열로 둡니다
LLM API는 이제 단순히 ‘동일 모델 동일 단가’로만 계산하기 어렵습니다. 실시간 사용자 응답, 야간 배치, 평가 데이터 생성, 문서 색인, 관리자 검수 작업은 처리 시간이 달라도 됩니다. OpenAI는 Batch API가 비동기 대량 작업에 적합하고 24시간 처리 창을 제공한다고 설명하며, 비용 최적화 문서에서 Flex를 더 낮은 비용과 느린 응답·일시적 자원 부족 가능성을 교환하는 옵션으로 소개합니다. ([platform.openai.com](https://platform.openai.com/docs/guides/batch/?utm_source=openai)) Anthropic과 Gemini도 Batch 처리의 비용 절감 구조를 문서화하고 있습니다. ([docs.anthropic.com](https://docs.anthropic.com/en/docs/about-claude/pricing?4810b549_page=3&73cdfb14_page=2&939688b5_page=1&e768fcd2_page=2))
| 업무 | 권장 처리 방식 | 이유 |
|---|---|---|
| 사용자 채팅 답변 | Standard 또는 Priority | 응답 지연이 곧 이탈로 이어질 수 있음 |
| 대량 FAQ 분류 | Batch | 즉시 응답이 필요 없고 단가 절감 여지가 있음 |
| 야간 문서 요약 | Batch 또는 Flex | 운영자가 다음 날 보면 되는 작업 |
| 모델 평가·회귀 테스트 | Batch | 수천 건을 반복 실행하므로 비용 차이가 누적됨 |
| 관리자 보고서 초안 | Flex 가능 | 몇 초 이상 지연되어도 업무 영향이 작음 |
주의할 점은 Batch가 사용자 화면의 대기 시간을 해결하는 수단이 아니라는 것입니다. 즉시 답변이 필요한 UX에는 쓰기 어렵고, 캐시가 필요한 후속 요청은 배치 처리 중 TTL이 만료될 수도 있습니다. 예산표에는 ‘실시간 호출’과 ‘비동기 호출’을 반드시 나눠야 합니다.
7. 예시 계산: 상담 자동화 기능의 월 비용을 어떻게 잡을까
아래는 특정 벤더 가격이 아니라 계산 방식을 보여주기 위한 가정값입니다. 실제 프로젝트에서는 선택 모델의 최신 단가를 넣고, 최근 50~100개 실제 상담 로그로 토큰을 다시 측정해야 합니다.
| 월 상담 세션 | 20,000건 |
|---|---|
| 세션당 LLM 호출 | 4회 |
| 월 LLM 호출 | 80,000회 |
| 호출당 정적 프롬프트 | 2,500 tokens |
| 호출당 동적 입력 | 1,700 tokens |
| 캐시 히트율 가정 | 정적 프롬프트의 70% |
| 호출당 출력 | 450 tokens |
| 가정 단가 | input $0.75/M, cached input $0.075/M, output $4.50/M |
| 항목 | 월 토큰 | 단가 | 월 비용 |
|---|---|---|---|
| 일반 입력 | 196M tokens | $0.75/M | $147.00 |
| 캐시 입력 | 140M tokens | $0.075/M | $10.50 |
| 출력 | 36M tokens | $4.50/M | $162.00 |
| 소계 | - | - | $319.50 |
| 재시도·도구·평가 여유분 20% | - | - | $63.90 |
| 월 예측 비용 | - | - | $383.40 |
같은 조건에서 캐시가 전혀 맞지 않으면 정적 프롬프트가 모두 일반 입력으로 계산되어 비용이 더 올라갑니다. 반대로 출력 길이가 길어지면 캐싱보다 output token 제어가 더 중요해질 수 있습니다. 그래서 비용 최적화는 ‘프롬프트를 짧게 한다’가 아니라 ‘무엇이 매번 반복되고, 무엇이 사용자마다 달라지며, 어느 구간에서 긴 출력이 꼭 필요한가’를 나누는 작업입니다.
8. 손익분기점은 사용자 수보다 ‘AI 호출을 만드는 행동’에서 계산합니다
AI 기능의 손익분기점은 MAU만으로 판단하면 위험합니다. 무료 사용자가 많아도 AI 버튼을 거의 누르지 않으면 비용은 낮고, 소수 유료 고객이 대량 문서 분석을 반복하면 비용은 커집니다. SaaS라면 다음 산식을 요금제 설계에 넣어야 합니다.
AI 기능 공헌이익 = AI add-on 매출 또는 ARPU 상승분 - 사용자당 LLM 변동비 - 벡터DB·로그·모니터링 등 운영비
손익분기 유료 사용자 수 = 월 고정 AI 운영비 ÷ 사용자당 AI 기능 공헌이익
상담 자동화라면 ‘상담원 처리 시간을 얼마나 줄이는가’도 함께 봐야 합니다. 다만 건당 인건비 절감액은 회사마다 다르므로 외부 평균값을 가져오기보다 내부 상담 처리 시간, 전환율, CS 품질 기준을 넣어야 합니다. 코드 보조나 업무 에이전트는 생산성 향상을 숫자로 바로 환산하기 어려우므로, 먼저 반복 업무 시간 절감, 오류 감소, 승인 대기 시간 단축 같은 운영 지표를 정해야 합니다.
9. 출시 전 비용 통제 체크리스트

LLM 비용 예측은 엑셀에서 끝나면 안 됩니다. 출시 후에는 관리자 화면과 로그에서 비용을 계속 확인할 수 있어야 합니다. 다음 항목은 MVP 단계에서도 가능하면 넣는 편이 좋습니다.
- 토큰 계측: request_id별 input, cached input, output, tool call, retry count를 저장합니다.
- 사용자별 quota: 무료 체험, 베이직, 프로, 엔터프라이즈 요금제별 월 AI 사용량 한도를 둡니다.
- 예산 알림: 일일·월간 예산의 50%, 80%, 100% 도달 시 관리자에게 알립니다.
- 모델 라우팅 로그: 어떤 조건에서 상위 모델로 올라갔는지 기록합니다.
- 에이전트 loop 제한: 도구 호출 최대 횟수, 실행 시간, 실패 후 중단 조건을 둡니다.
- RAG chunk 정책: top-k, chunk size, 중복 제거, 출처 표기 여부를 버전 관리합니다.
- 프롬프트 버전 관리: 프롬프트 변경 전후 토큰 수와 품질 지표를 비교합니다.
- Batch 분리: 평가, 요약, 색인처럼 실시간이 아닌 작업은 별도 queue로 보냅니다.
- 관리자 대시보드: 일별 비용, 기능별 비용, 고객사별 비용, 캐시 히트율을 보여줍니다.
10. AgentMit이 실제 구현에서 먼저 확인하는 것
AgentMit은 AI 서비스 개발이나 BizMit 기반 업무 자동화, SaaS 관리자 대시보드, 정부지원사업 MVP를 설계할 때 특정 모델을 먼저 정하지 않습니다. 먼저 사용 시나리오, 예상 QPS, 평균·상위 10% 토큰, 캐시 가능한 정적 프롬프트, RAG 문서 길이, 모델 라우팅 기준, 실패 재시도 정책을 숫자로 적습니다. 그다음 MVP 범위에서 꼭 필요한 AI 기능과 운영 이후 확장할 기능을 나눕니다.
실제 구현이 필요한 단계라면 비용 예측표는 백엔드 구조와 함께 설계되어야 합니다. 예를 들어 사용자별 quota는 결제·권한 시스템과 연결되고, 캐시 히트율은 프롬프트 구조와 연결되며, 에이전트 loop 제한은 관리자 승인·감사 로그와 연결됩니다. 단순 챗봇 위젯을 붙이는 일이 아니라 운영 가능한 AI 기능을 만드는 일에 가깝습니다.
참고한 공개 문서
- OpenAI API Pricing: 모델별 input, cached input, output과 Standard·Batch·Flex·Priority, 도구 호출 비용 구조를 확인했습니다. ([platform.openai.com](https://platform.openai.com/docs/pricing/))
- OpenAI Prompt Caching 및 Batch API: 자동 캐싱 조건, 정확한 prefix 매칭, 비동기 처리 비용 구조를 참고했습니다. ([platform.openai.com](https://platform.openai.com/docs/guides/prompt-caching))
- Anthropic Claude Pricing 및 Prompt Caching: cache write, cache hit, 5분·1시간 TTL, cache read 배수를 확인했습니다. ([docs.anthropic.com](https://docs.anthropic.com/en/docs/about-claude/pricing?4810b549_page=3&73cdfb14_page=2&939688b5_page=1&e768fcd2_page=2))
- Gemini Pricing, Context Caching, Token Counting: explicit caching, TTL, storage duration, usage metadata 기반 토큰 계측 기준을 참고했습니다. ([ai.google.dev](https://ai.google.dev/pricing))
FAQ
LLM API 월 비용은 어떻게 계산하나요?
월 요청 수, 요청당 LLM 호출 수, 호출당 일반 입력 토큰, 캐시 입력 토큰, 출력 토큰, 도구 호출 수, 재시도율을 분리한 뒤 모델별 100만 토큰 단가를 곱해 계산합니다. PoC 평균값만 쓰지 말고 p50, p90, 트래픽 3배 시나리오를 함께 잡는 것이 안전합니다.
프롬프트 캐싱을 적용하면 비용이 얼마나 줄어드나요?
정적 프롬프트가 길고 같은 prefix가 반복될수록 효과가 큽니다. 반대로 사용자별 문구, 시간값, RAG 문서 순서가 매번 앞부분에서 바뀌면 캐시 히트율이 낮아집니다. 따라서 절감률을 고정값으로 가정하지 말고 실제 로그에서 cache hit tokens 비율을 측정해야 합니다.
AI 챗봇은 처음부터 고성능 모델을 써야 하나요?
대부분의 서비스는 의도 분류, 검색 질의 재작성, 단순 요약은 저비용 모델로 시작하고, 고객에게 최종 답변을 생성하거나 복잡한 판단이 필요한 구간만 상위 모델로 라우팅하는 방식이 비용 관리에 유리합니다. 단, 정확도 기준과 fallback 조건을 먼저 정의해야 합니다.
RAG를 붙이면 LLM API 비용이 왜 늘어나나요?
RAG는 사용자 질문 외에 검색된 문서 chunk, 출처, 메타데이터, 지시문을 프롬프트에 함께 넣기 때문에 입력 토큰이 증가합니다. top-k 개수, chunk 길이, 중복 제거, 요약 후 주입 여부에 따라 비용이 크게 달라집니다.
트래픽이 갑자기 늘 때 LLM 비용 폭증을 막으려면 무엇을 준비해야 하나요?
사용자·워크스페이스별 quota, 일일 예산 한도, 모델별 rate limit, 긴 답변 제한, 에이전트 loop 최대 횟수, 캐시 히트율 모니터링, 관리자 비용 대시보드를 출시 전부터 넣어야 합니다. 결제형 SaaS라면 요금제별 AI 사용량 정책도 함께 설계해야 합니다.

