2026년 AI/LLM 비용을 절감하는 방법: 캐싱(Caching), 저렴한 모델, 그리고 멀티 에이전트 라우팅(Multi-Agent
요약
LLM 사용 비용을 절감하기 위한 3가지 핵심 전략인 프롬프트 캐싱, 모델 적정 규모 결정, 멀티 에이전트 라우팅을 소개합니다. 불필요한 토큰 생성과 과도한 모델 사용을 방지하여 효율적인 AI 애플리케이션 운영을 돕습니다.
핵심 포인트
- 프롬프트 캐싱을 통해 입력 비용을 최대 90%까지 절감 가능
- 캐시 무효화를 방지하기 위해 변동성 높은 데이터를 프롬프트 끝에 배치
- 작업의 난이도에 따라 소형 모델과 프론티어 모델을 구분하여 사용
- Llama, Mistral 등 오픈 소스 모델 활용 시 비용 극적 절감
AI 기능은 빠르게 출시되지만, 그 뒤에는 청구서가 따릅니다. 좋은 소식은 대부분의 LLM 지출이 피할 수 있는 낭비라는 점입니다. 동일한 프롬프트에 천 번을 비용을 지불하거나, 저렴한 모델로 처리할 수 있는 일을 프론티어 모델(Frontier model)로 수행하거나, 아무도 읽지 않는 토큰을 생성하는 것 등이 그 예입니다. 여기에는 실제 비용을 절감할 수 있는 6가지 레버(Lever)가 있으며, 일반적으로 절감되는 금액이 큰 순서대로 숫자와 바로 복사해서 사용할 수 있는 코드를 포함하여 정리했습니다.
레버 1: 프롬프트 캐싱 (Prompt caching) (가장 큰 단일 이점)
대부분의 AI 앱은 매 요청마다 동일한 대규모 접두사(Prefix)를 다시 보냅니다. 시스템 프롬프트(System prompt), 도구 정의(Tool definitions), 지식 베이스(Knowledge base), 퓨샷 예시(Few-shot examples) 등이 이에 해당합니다. 이 접두사는 종종 입력 토큰의 80%를 차지하며, 여러분은 매번 이에 대해 전체 비용을 지불하고 있습니다. 프롬프트 캐싱(Prompt caching)은 캐시 히트(Hit) 시 캐시된 접두사에 대해 입력 가격의 약 10분의 1 수준으로 비용을 청구합니다. 캐시에 쓰는 비용은 약 1.25배이므로, 손익분기점은 두 번의 요청입니다. 그 이후부터는 캐시된 부분에 대해 거의 90% 할인된 가격으로 이용할 수 있습니다.
규칙은 캐싱이 접두사 일치(Prefix match) 방식이라는 것입니다. 캐시 중단점(Breakpoint) 이전의 모든 내용은 요청 간에 바이트 단위로 동일해야 합니다. 안정적인 콘텐츠(고정된 시스템 프롬프트, 결정론적인 도구 목록)를 앞에 두고, 변동성이 큰 콘텐츠(사용자의 실제 질문, 타임스탬프, 요청별 ID)를 마지막에 배치하십시오. 시스템 프롬프트에 삽입된 단 하나의 datetime.now()는 매 요청마다 전체 캐시를 무효화하며, 이는 캐시 히트율(Cache hit rate)이 0에 머무는 가장 흔한 원인입니다.
가장 빠른 감사 방법: 모든 응답에서
cache_read_input_tokens를 로그로 남기십시오. 동일한 시스템 프롬프트를 사용하는 반복적인 요청에서 이 값이 0이라면, 조용한 무효화 요소(타임스탬프, 랜덤 ID, 정렬되지 않은 JSON)가 접두사에 포함되어 있는 것입니다. 그것을 찾아내기만 하면 입력 비용을 최대 90%까지 절감할 수 있습니다.
레버 2: 모델의 적정 규모 결정 (Right-size the model)
모든 것을 가장 똑똑하고 가장 비싼 모델로 라우팅(Routing)하려는 본능은 두 번째로 큰 낭비 원인입니다. 모델 계층(Model tiers)은 가격 면에서 5배 이상 차이가 날 수 있으며, 실제 앱에서의 대부분의 요청(분류, 추출, 짧은 답변, 라우팅)은 최상위 계층을 필요로 하지 않습니다. 핵심은 모델을 여러분의 야망이 아닌, 작업(Job)에 맞추는 것입니다.
| 계층 (Tier) | 대략적인 가격 / 1M 토큰 (입력 / 출력) | 용도 |
|---|---|---|
| 소형 (Haiku급) | ~$1 / ~$5 | 분류 (Classification), 추출 (Extraction), 라우팅 (Routing), 짧은 답변 |
| ... |
가격은 변동되므로 현재 요율을 확인하십시오. 하지만 비율은 유지됩니다. 소형 계층은 입력과 출력 모두에서 프론티어 (Frontier) 모델보다 대략 5배 저렴합니다. 그리고 오픈 소스 (Open-source) 모델을 간과하지 마십시오. Llama, Mistral, DeepSeek, Qwen은 동일한 게이트웨이를 통해 사용할 수 있으며, 대량의 잘 정의된 작업(요약, 추출, 내부 도구)의 경우 호스팅된 프론티어 모델보다 비용을 극적으로 낮출 수 있습니다. 트래픽의 지루한 80%는 저렴한 모델이나 오픈 소스 모델로 라우팅하고, 비싼 계층은 실제로 그것이 필요한 요청을 위해 남겨두십시오.
레버 3: 멀티 에이전트 라우팅 (Multi-agent routing, 캐스케이드 패턴)
레버 1과 2를 결합하면 가장 강력한 레버리지 아키텍처가 됩니다. 저렴한 모델이 각 들어오는 요청을 분류하고, 진정으로 어려운 요청만 비싼 모델로 에스컬레이션(Escalate)합니다. 이것이 캐스케이드 (Cascade)입니다. 즉, 실제 작업 앞에 위치하는 빠르고 저렴한 분류(Triage) 단계입니다. 대부분의 앱에서 분류기(Classifier)의 비용은 오차 범위 수준이며, 트래픽의 대부분을 프론티어 계층으로부터 분산시킵니다.
import { generateText } from 'ai'
async function answer(userMessage: string) {
...
동일한 아이디어를 확장할 수 있습니다. 모든 것을 수행하는 하나의 비싼 범용 모델 대신, 작업별로 특화된 에이전트(저렴한 추출기, 중간 단계의 작성자, 프론티어 플래너)를 사용하는 것입니다. 여러분은 진정으로 최상위 수준의 작업이 필요한 단계에 대해서만 최상위 가격을 지불하게 됩니다.
레버 4: 응답 및 시맨틱 캐싱 (Response and semantic caching)
프롬프트 캐싱 (Prompt caching, 레버 1)은 공유된 접두사 (Prefix)에 할인을 제공합니다. 응답 캐싱 (Response caching)은 동일한 요청이 다시 들어올 때 모델 호출을 완전히 건너뜁니다. 정적 지식 쿼리(FAQ, 정책 조회, 번역, 동일한 문서에서의 추출)의 경우, 게이트웨이에서 응답 전체를 캐싱하고 반복되는 요청은 무료로 제공하십시오.
import { generateText } from 'ai'
const result = await generateText({
...
캐시 키(Cache key)는 모델, 프롬프트(Prompt), 그리고 생성 파라미터(Generation parameters)의 조합입니다. 따라서 동일한 요청은 캐시를 적중(Hit)시키지만, 변동이 있는 부분(실제 대화 등)은 캐시를 놓치며(Miss) 정상적으로 비용이 청구됩니다. 사용자별 개별 대화는 캐싱하지 마십시오. 대신 대부분의 애플리케이션에서 놀라울 정도로 큰 비중을 차지하는 반복적이고 결정론적인(Deterministic) 조회 작업들을 캐싱하십시오.
레버 5: 게이트웨이 수준의 비용 제어 (Gateway-level cost controls)
모든 호출을 단일 게이트웨이(Gateway)를 통해 라우팅(Routing)하는 것이 위에서 언급한 레버들을 이론적인 수준이 아닌 관리 가능한 수준으로 만드는 핵심입니다. 한 곳에서 기능 및 사용자별 지출 귀속(Spend attribution)을 파악할 수 있고, 기본 제공업체나 모델이 다운되거나 속도 제한(Rate-limited)에 걸렸을 때 더 저렴한 제공업체나 모델로 자동 장애 조치(Failover)를 수행할 수 있으며, 한 명의 악용자가 비용을 폭증시키지 못하도록 사용자별 속도 제한(Rate limits)을 설정하고, 월 예산을 초과하기 전에 예산 알림을 받을 수 있습니다.
import { gateway } from 'ai'
const result = await generateText({
...
게이트웨이는 마진(Markup) 없이 제공업체의 정가로 비용을 청구하기 때문에, 제공업체에 직접 호출하는 것보다 토큰당 더 많은 비용을 지불하지 않고도 장애 조치, 추적, 사용자별 제한, 예산 관리와 같은 모든 기능을 누릴 수 있습니다. 태그(Tags)를 활용하면 정체불명의 송장을 기능별 비용 내역으로 전환할 수 있으며, 이를 통해 예산의 절반을 조용히 갉아먹고 있는 특정 엔드포인트(Endpoint)를 찾아낼 수 있습니다.
레버 6: 토큰 위생 (Token hygiene)
화려하지는 않지만 합산되면 큰 차이를 만드는 레버입니다. 입력 토큰(Token in)과 출력 토큰(Token out)에 대해 각각 비용을 지불하므로, 두 가지 모두를 다듬어야 합니다.
- 산문 형태로 JSON을 요청하는 대신 구조화된 출력(Structured output, 스키마)을 사용하십시오. 이는 더 짧고, 파싱(Parse)이 가능하며, 형식을 설명하는 데 토큰을 낭비하지 않습니다.
maxOutputTokens를 사용하여 출력을 제한하십시오. 상한선이 없는 모델은 단 한 문장이 필요한 곳에 기꺼이 세 문단을 작성할 것입니다.- 다시 전송하는 컨텍스트(Context)를 다듬으십시오. 오래된 도구 결과(Tool results)와 오래된 히스토리는 순수한 비용 낭비입니다. 이를 요약하거나 삭제하십시오.
- 실시간이 아닌 작업(야간 보고서, 대량 분류, 임베딩 백필(Embeddings backfills))의 경우 Batch API를 사용하십시오. 이는 약 절반 가격으로 비동기(Asynchronously) 실행됩니다.
종합하기
이 중 어느 것도 생소한 기술이 아닙니다. 이 기술들을 중첩하여 사용하면, 비용 측면에서 AI 기능의 비용을 경악스러운 수준에서 지루한 수준으로 일상적으로 낮출 수 있습니다. 단순한 질문과 어려운 질문이 섞여 있는 고객 지원 어시스턴트의 대표적인 전후 비교는 다음과 같습니다:
| 설정 | 상대적 비용 |
|---|---|
| 모든 것을 프론티어 모델 (Frontier Model)로 처리, 매 요청마다 전체 접두사 (Full Prefix) 포함 | 100% |
| ... |
정확한 수치는 트래픽 구성에 따라 다르지만, 그 형태는 분명합니다. 동일한 제품을 운영하면서도, 실제로 중요한 요청들에 대해서는 품질 저하 없이 운영 비용을 10배(An order of magnitude) 더 저렴하게 만들 수 있습니다. 왜냐하면 프론티어 모델 (Frontier Model)이 여전히 그러한 중요한 요청들을 처리하기 때문입니다. 당신이 절감한 낭비는 결코 유용한 작업을 수행하지 않았던 부분들입니다.
우리의 AI SaaS 스타터 키트인 Keel은 처음부터 비용을 의식하도록(Cost-aware) 설계되었습니다. 게이트웨이 라우팅 (Gateway routing), 모델 폴백 (Model fallbacks), 그리고 문자열 하나로 티어를 교체할 수 있도록 연결된 스트리밍 어시스턴트가 포함되어 있습니다. 이미 당신의 청구서를 존중하는 아키텍처에서 시작하십시오.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기