LLM API 비용 최적화: 모델 라우팅·프롬프트 캐시·배치 처리로 줄이는 운영법

요약: LLM API 비용은 모델 단가보다 사용 패턴에서 더 많이 새는 경우가 많습니다. 모든 요청을 최고급 모델로 보내고, 같은 시스템 프롬프트를 매번 붙이고, 실시간이 필요 없는 작업까지 동기 처리하면 월 비용이 빠르게 커집니다. 비용 최적화의 핵심은 싼 모델을 쓰는 것이 아니라, 요청 유형별로 모델·캐시·배치·로그 기준을 나누는 것입니다.

왜 LLM API 비용은 예상보다 빨리 커지나

LLM API를 처음 붙일 때는 요청 수가 적습니다. 데모에서는 비용이 거의 안 나옵니다. 문제는 기능이 제품 안에 들어간 뒤입니다. 사용자당 1회 호출로 끝날 줄 알았던 기능이 실제로는 분류, 검색 질의 생성, 답변 생성, 후처리, 안전성 검사까지 여러 번 호출합니다.

토큰 비용도 단순하지 않습니다. 입력 토큰과 출력 토큰 단가가 다르고, 출력 토큰은 보통 더 비쌉니다. 긴 시스템 프롬프트를 매 요청마다 붙이면 입력 비용이 누적됩니다. 답변을 길게 만들면 출력 비용이 더 크게 붙습니다. 문서 요약처럼 긴 컨텍스트를 넣는 기능은 사용자가 몇 명만 늘어도 비용이 튑니다.

2026년 7월 기준 공개 비교 자료들을 보면 고성능 모델은 100만 토큰당 수 달러에서 수십 달러까지 차이가 납니다. 예를 들어 고급 모델은 입력보다 출력이 5배 안팎 비싼 경우가 많고, Flash·Mini·Haiku 계열 모델은 훨씬 낮은 단가로 대량 작업에 적합합니다. 가격표 하나만 보고 결정하면 안 되는 이유입니다.

실무에서는 “어떤 모델이 제일 싸냐”보다 “어떤 요청을 비싼 모델로 보내지 않아도 되냐”가 더 중요합니다.

1단계: 요청을 난이도와 위험도로 분류한다

비용 최적화의 첫 단계는 모델 변경이 아닙니다. 요청 분류입니다. 모든 요청을 하나의 LLM 호출로 취급하면 최적화할 수 없습니다.

제품의 AI 기능을 다음처럼 나눠보세요.

이 표를 만들면 비용 절감 지점이 보입니다. 단순 분류와 형식 변환을 고급 모델로 처리하고 있다면 가장 먼저 바꿀 수 있습니다. 반대로 고위험 판단은 비용을 아끼려고 낮은 모델로 바꾸면 안 됩니다. 비용보다 오류 비용이 더 큽니다.

요청 분류는 코드에도 반영해야 합니다. model = premium 같은 상수 하나로 운영하면 나중에 바꾸기 어렵습니다. task_type, risk_level, latency_budget, max_output_tokens를 함께 넘기는 구조가 좋습니다.

2단계: 모델 라우팅으로 비싼 호출을 줄인다

모델 라우팅은 요청을 여러 모델에 나눠 보내는 방식입니다. 쉬운 요청은 싼 모델이 처리하고, 어려운 요청만 고급 모델로 올립니다. 이 방식은 실제 운영에서 가장 큰 비용 절감 효과를 냅니다. 일부 비용 비교 자료에서도 프리미엄 모델만 쓰는 방식보다 60~80% 절감이 가능하다고 설명합니다. 물론 수치는 제품 구조에 따라 달라집니다.

간단한 라우팅 구조는 다음과 같습니다.

사용자 요청
  → 요청 분류 모델
  → 쉬움: 저가 모델
  → 보통: 중간 모델
  → 어려움/고위험: 고급 모델
  → 검증 실패 시 상위 모델로 재시도

핵심은 첫 분류 모델을 너무 복잡하게 만들지 않는 것입니다. 분류 기준은 5개 이내가 좋습니다. 예를 들어 “정확한 숫자가 필요한가”, “고객에게 바로 노출되는가”, “긴 문서 컨텍스트가 필요한가”, “실패 비용이 큰가”, “코드 실행 검증이 가능한가” 정도면 충분합니다.

라우팅에는 fallback도 필요합니다. 저가 모델이 JSON 스키마를 깨거나, 근거 없는 답변을 만들거나, confidence가 낮으면 상위 모델로 넘깁니다. 이때 같은 요청을 그대로 보내기보다 실패 이유를 함께 넘기면 좋습니다.

예시:

{
  "task_type": "support_reply_draft",
  "risk_level": "medium",
  "first_model": "fast",
  "validation_error": "missing_policy_reference",
  "retry_model": "strong"
}

이렇게 로그를 남기면 어떤 요청이 계속 상위 모델로 올라가는지 볼 수 있습니다. 그 유형은 프롬프트를 고치거나 별도 기능으로 분리할 수 있습니다.

3단계: 프롬프트 캐시로 반복 입력 비용을 줄인다

많은 LLM 기능은 같은 시스템 프롬프트와 같은 정책 문서를 반복해서 보냅니다. 고객지원 봇은 매번 응대 정책을 붙이고, 코드 리뷰 봇은 매번 코드 스타일 가이드를 붙이고, 문서 요약 봇은 매번 출력 형식을 설명합니다. 이 반복 입력은 비용을 계속 만듭니다.

프롬프트 캐시는 이런 반복 입력을 줄이는 기능입니다. 제공자마다 방식은 다르지만, 공통 아이디어는 같습니다. 자주 반복되는 긴 프롬프트나 문서 부분을 캐시하고, 이후 요청에서는 캐시된 입력을 더 낮은 비용으로 재사용합니다. Anthropic, OpenAI, Google 등 주요 제공자는 각자 형태는 다르지만 캐시 또는 캐시성 할인 구조를 제공합니다.

캐시에 적합한 입력은 다음과 같습니다.

• 긴 시스템 프롬프트
• 제품 정책 문서
• 코드 컨벤션 문서
• 자주 쓰는 API 명세
• 변하지 않는 RAG 배경 문서

캐시에 적합하지 않은 입력도 있습니다.

• 사용자 개인정보
• 매 요청마다 바뀌는 대화 내용
• 짧아서 캐시 이득이 거의 없는 프롬프트
• 자주 바뀌는 정책 문서

개발팀은 캐시를 붙이기 전에 프롬프트를 두 부분으로 나누는 습관을 들여야 합니다. 안정적인 부분과 요청별 부분입니다. 안정적인 부분이 커야 캐시 효과가 납니다.

[캐시 후보]
- 역할 설명
- 출력 규칙
- 정책 문서
- 예시 5개

[요청별 입력]
- 사용자 질문
- 현재 주문 정보
- 최근 대화 3턴

이렇게 나누면 비용뿐 아니라 프롬프트 관리도 쉬워집니다.

4단계: 실시간이 필요 없는 작업은 배치로 보낸다

모든 AI 기능이 실시간일 필요는 없습니다. 사용자가 기다리는 채팅 답변은 실시간이 필요합니다. 하지만 야간 문서 분류, 대량 태깅, 로그 요약, 주간 리포트 생성은 몇 분 늦어도 됩니다. 이런 작업은 배치 API나 비동기 큐로 보내는 것이 좋습니다.

배치 처리의 장점은 3가지입니다.

1. 비용 할인을 받을 수 있는 경우가 있습니다.
2. 피크 시간대의 동시 호출을 줄일 수 있습니다.
3. 실패 재시도와 부분 완료 처리가 쉬워집니다.

예를 들어 고객 피드백 10,000건을 태깅해야 한다면, 사용자 요청이 들어올 때마다 동기 호출로 처리할 필요가 없습니다. SQS, Cloud Tasks, BullMQ 같은 큐에 넣고 밤에 배치로 처리하면 됩니다. 결과는 DB에 저장하고, 사용자는 이미 계산된 태그를 봅니다.

배치 작업에는 idempotency key가 필요합니다. 같은 입력이 재시도되어도 중복 과금과 중복 저장을 줄여야 합니다. 또한 실패한 항목만 다시 돌릴 수 있게 job_id, item_id, input_hash, model, status, cost_estimate를 남기는 것이 좋습니다.

5단계: max tokens와 출력 형식을 통제한다

LLM 비용에서 출력 토큰은 자주 놓칩니다. 모델이 긴 답변을 만들수록 비용이 늘어납니다. 특히 내부 처리용 호출에서 장문 설명을 받는 것은 낭비입니다. 분류, 추출, 검증 작업은 짧은 JSON으로 받는 편이 낫습니다.

예를 들어 문의 분류는 이렇게 받습니다.

{
  "category": "refund",
  "confidence": 0.82,
  "needs_human": false
}

모델에게 “이유를 자세히 설명해줘”라고 하면 출력 토큰이 늘어납니다. 사람이 읽지 않는 내부 단계라면 이유는 짧게 제한하세요.

출력 길이 통제 기준은 다음과 같습니다.

• 내부 분류: 50~150 토큰
• JSON 추출: 필요한 필드만
• 고객 답변 초안: 300~600 토큰
• 긴 문서 요약: 섹션별 제한
• 보고서: 사용자에게 보여줄 때만 장문 허용

또한 답변을 짧게 만드는 것은 비용만 줄이는 일이 아닙니다. 사용자 경험도 좋아집니다. 필요한 정보만 주는 답변이 긴 일반론보다 낫습니다.

비용 관측: 모델별·기능별로 봐야 한다

마지막으로 비용 로그가 필요합니다. 월말 청구서만 보면 늦습니다. 어떤 기능이 비용을 만들었는지 알아야 고칠 수 있습니다. 최소한 다음 필드를 남기세요.

• user_id 또는 tenant_id
• feature_name
• task_type
• model
• input_tokens
• output_tokens
• cached_tokens
• latency_ms
• retry_count
• estimated_cost
• success 또는 validation_error

이 로그를 대시보드로 보면 바로 패턴이 보입니다. 특정 고객의 사용량이 급증했는지, 특정 기능이 출력 토큰을 많이 쓰는지, 특정 모델에서 재시도가 많은지 확인할 수 있습니다.

비용 알림도 필요합니다. 일별 예상 비용이 평소의 2배를 넘으면 알림을 보내고, 특정 테넌트가 한도를 넘으면 저가 모델로 제한하거나 사용량 경고를 띄우는 방식입니다.

지금 적용할 체크리스트

LLM API 비용 최적화는 모델 교체 한 번으로 끝나지 않습니다. 아래 순서대로 적용하세요.

• AI 기능을 task_type 기준으로 분류한다.
• 단순 분류, 형식 변환, 초안 생성, 고위험 판단을 같은 모델로 처리하지 않는다.
• 쉬운 요청은 저가 모델, 실패한 요청만 상위 모델로 올리는 라우팅을 만든다.
• 긴 시스템 프롬프트와 정책 문서를 캐시 후보로 분리한다.
• 실시간이 필요 없는 대량 작업은 배치 처리로 옮긴다.
• 내부 처리용 호출은 JSON 출력과 max tokens 제한을 둔다.
• 모델별·기능별 비용 로그와 일별 예산 알림을 만든다.

가장 좋은 비용 최적화는 무조건 싼 모델을 쓰는 것이 아닙니다. 쉬운 요청에 비싼 모델을 쓰지 않고, 반복 입력을 매번 과금하지 않고, 실시간이 필요 없는 작업을 비동기로 빼는 것입니다. 이 3가지만 해도 대부분의 팀은 비용 그래프를 안정시킬 수 있습니다.