개요
이번에는 AI Agent의 비용 최적화에 대해 알아보겠습니다.
단일 LLM 호출만 놓고 보면 비용이 크지 않아 보일 수 있습니다. 하지만 AI Agent 시스템은 하나의 사용자 요청을 처리하는 과정에서 단순히 한 번의 모델 호출로 끝나지 않습니다.
Agent는 목표를 달성하기 위해 생각(Thought) → 행동(Action) → 관찰(Observation) 과정을 반복하는 Loop 구조로 동작하며, 이 과정에서 LLM 호출뿐만 아니라 Tool 호출, 검색, 메모리 조회, 컨텍스트 전달 등이 함께 발생합니다.
특히 Loop 횟수가 증가하거나 매 호출마다 전달되는 컨텍스트가 커질수록 Token 사용량도 함께 증가하기 때문에, 사용자가 체감하기 어려운 수준에서 비용이 빠르게 누적될 수 있습니다.
따라서 AI Agent의 비용을 최적화하려면 단순히 저렴한 모델을 선택하는 것을 넘어, 모델 선택, Token 사용량, Agent Loop 횟수, Tool 호출, Context 관리 등 Agent 전체 실행 구조를 함께 살펴봐야 합니다.
& 비용 폭증의 주요 원인
- Context Accumulation: Loop가 거듭될수록 이전 Tool 실행 결과(Observation)와 대화 내역이 누적되어 Input Token이 기하급수적으로 증가.
- Redundant Tool Descriptions: 매 Step마다 쓰지도 않는 수십 개의 Tool 스키마를 Prompt에 재전송.
- C2J (CJK) Token Efficiency Difference: 동일한 한국어 문장이라도 모델/토크나이저에 따라 토큰 수가 최대 2배 이상 차이 발생.
총 요청 비용
= 모델 호출 횟수 × (Input Token 비용 + Output Token 비용)
+ Cache 비용 + Storage 비용 + 실행 인프라 비용→ 여기서 중요한 것은 단순히 “토큰 단가가 얼마인가”가 아닙니다. 몇 번 호출하는가, 매번 얼마나 긴 입력을 보내는가, 검색과 Tool 결과를 얼마나 많이 붙이는가, 불필요한 재시도가 있는가가 함께 비용을 결정합니다.
| 비용을 키우는 요인 | 예시 |
|---|---|
| 호출 횟수 증가 | Agent Step, Reflection, Multi-Agent 협업 |
| Input Token 증가 | 긴 대화 이력, System Prompt, RAG Context |
| Output Token 증가 | 지나치게 긴 답변, 불필요한 추론·설명 |
| 재시도 증가 | Tool 오류, JSON 형식 오류, 잘못된 검색 |
| 실행 비용 증가 | GPU 서버, Vector DB, Cache Storage |
비용 최적화의 세가지 층 및 LLM의 주요 비용 항목
: 비용 최적화에는 세가지 층으로 나눌 수 있습니다.
해당 층은 독립적이지 않습니다.
예를 들면, 입력을 절반으로 줄이는 것 이모델 교체보다 더 큰 효과를 낼 수도 있습니다.
| 층 | 핵심 질문 | 주요 방법 |
|---|---|---|
| LLM 사용 방식 | 어떤 모델과 호출 방식을 사용할 것인가? | Token 측정, 모델 비교, Prompt Caching, Batch |
| 애플리케이션 | 모델에 어떤 입력과 Tool을 보여줄 것인가? | Single/Multi Turn 분리, History 축약, Tool 제한 |
| 시스템·인프라 | 어떤 실행 기반을 사용할 것인가? | Managed API, Self-hosted GPU, Semantic Cache |
& 주요 비용 항목
| 비용 항목 | 의미 | 확인할 내용 |
|---|---|---|
| Input Token | Prompt, Context, 대화 이력, Tool Schema 등 모델에 전달한 토큰 | 반복되는 긴 입력이 있는가? |
| Cached Input Token | Prompt Caching으로 재사용된 입력 토큰 | Cache Hit가 발생하는가? |
| Output Token | 모델이 생성한 답변 토큰 | 답변이 필요 이상으로 긴가? |
| Reasoning Token | 일부 추론 모델의 내부 처리 토큰 | 모델별 과금 정책은 무엇인가? |
| Batch Discount | 비동기 Batch 처리에 적용되는 할인 | 즉시 응답이 꼭 필요한가? |
| Cache Storage | Cache를 보관하는 비용 | TTL과 재사용 횟수가 적절한가? |
LLM 비용 최적화 (Model & Provider Level)
(1) 토크나이저(Tokenizer)와 CJK 파편화
: 동일한 한국어 문장이라도 모델마다 쪼개는 토큰 단위가 완전히 다릅니다.
- 원인: 영어 기반으로 학습된 토크나이저는 한국어/중국어/일본어(CJK)를 글자 단위나 바이트 단위로 쪼개어 토큰 수가 크게 늘어납니다.
- 시사점: 단가($/1M tokens)만 비교하면 안 되며, '동일한 입력 문장을 처리할 때 발생하는 실제 토큰 수'를 곱해서 비교해야 합니다.
- 실천 가이드: 서비스의 대표 한국어 데이터셋을 추출하여 각 모델별 Tokenizer(OpenAI, Claude, Gemini)로 실측 토큰량을 비교 분석합니다.
| 잘못된 비교 | 더 정확한 비교 |
|---|---|
| 모델의 Input 단가만 비교 | 실제 요청당 총비용 비교 |
| 영어 문장만 측정 | 서비스에서 실제 사용하는 언어·형식 측정 |
| 한 번 호출한 비용 비교 | Agent 전체 Step의 누적 비용 비교 |
| 가격만 보고 선택 | 품질·Latency·Cache·재시도까지 함께 평가 |
(2) 프롬프트 캐싱
: Prompt Caching은 여러 요청에서 반복되는 긴 Prompt의 앞부분을 재사용해 비용과 Latency를 줄이는 방식입니다. 이는 대화 Memory와는 다릅니다. Memory는 사용자의 과거 상태나 정보를 관리하는 개념이고, Prompt Caching은 동일하거나 유사한 Prompt 구간의 처리 결과를 재사용하는 제공자·서빙 계층 기능입니다.
- 캐싱에서는 일반적으로 반복되는 Prefix, 즉 앞부분이 안정적으로 같아야 효과가 큽니다.
- 캐싱 후보군
- 반복되는 긴 System Instruction
- 공통 회사 정책 문서
- 여러 요청에서 동일한 Tool Schema
- 사용자별로 변하지 않는 고정 Context
- Good vs Bad 프롬프트 구조:
- Bad:
[사용자 질문] -> [고정 시스템 지침] -> [도구 목록](앞부분이 매번 바뀌어 캐시 전체 파기) - Good:
[고정 시스템 지침] -> [도구 목록] -> [사용자 질문](앞부분이 동일하여 캐시 Hit 가능)
- Bad:
(3) Batch API (비동기 배치 처리)
- 메커니즘: 24시간 이내 결과 수령을 조건으로 API를 비동기 호출하면 비용을 50% 할인받는 방식입니다.
- 적용 대상: 실시간 대화가 아닌 밤사이에 처리해도 되는 데이터 분석, 백그라운드 요약, 평가 데이터셋 생성, 문서 태깅 등에 활용합니다.
애플리케이션 최적화 (Application & Architecture Level)
: 동일한 모델을 쓰더라도, 애플리케이션이 '무엇을 보여주고 무엇을 숨기는가'에 따라 비용을 수십 퍼센트 절감할 수 있습니다.
(1) Single Turn vs Multi Turn 분리
- Single Turn (단발성): 분류, 추출, 라우팅 등은 이전 대화 기록(History)을 완전히 제거하고 단건 입출력만 수행하여 입력 토큰을 최소화합니다.
- Multi Turn (대화형): 대화 맥락이 필요하지만, 대화 전체를 그대로 붙이면 안 됩니다.
& Chat History 정리 4대 전략
→ Trim: 최근 N개 또는 일정 토큰 예산(Budget) 내의 메시지만 유지.
→ Summarize: 오래된 대화는 LLM을 통해 한 줄 요약문으로 압축 전환.
→ Delete: 해결된 Tool Result 등 불필요한 메시지는 State에서 삭제.
→ Custom Filter: 인사말, 중복 확인 등 의미 없는 발화 제거.
(2) Dynamic Tool Placement (동적 도구 노출)
- 문제점: 등록된 Tool이 30개라면, 매 Step마다 30개의 JSON 스키마 토큰이 프롬프트에 포함됩니다.
- 해결책: 사용자의 현재 상태, 권한, 대화 단계(Stage)에 맞춰 '지금 실행 가능한 Tool'만 프롬프트에 동적으로 주입합니다.
(3) Token Budget (토큰 예산제) 도입
: 각 agent의 요소별로 상한선을 설정해서 무한 비용 증가를 방지해줍니다.
| Budget 종류 | 최적화 대상 | 비효율적인 방식 (Bad) | 최적화 방식 (Good) |
|---|---|---|---|
| History Budget | 대화 기록 토큰 수 | 대화 전체를 매 요청마다 프롬프트에 포함 | 최근 5턴만 유지하거나 오래된 대화는 요약해서 전달 |
| Tool Result Budget | Tool 반환 데이터 크기 | DB 조회 결과의 50개 Column JSON을 그대로 전달 | LLM 판단에 필요한 핵심 Field 4개만 추출하여 전달 |
| Retrieval Budget | RAG 검색 문맥 크기 | 관련 문서 20개를 모두 Context에 포함 | Top-K=3으로 제한하고 Threshold 미달 문서는 제거 |
| Step Budget | Agent 최대 실행 횟수 | 종료 조건 없이 Agent Loop를 계속 실행 | Max Steps=5와 같이 최대 실행 횟수를 제한하고 초과 시 종료 처리 |
시스템 및 인프라 최적화 (System & Infrastructure Level)
(1) Semantic Caching (의미 기반 캐싱)
- 개념: 기존 Key-Value 캐시는 완전 일치(Exact Match)만 캐싱하지만, Semantic Cache는 Vector Embedding 기반으로 문장의 '의미적 유사성'을 판단하여 답변을 재사용합니다.
- 동작 예시
질문 1: "환불 절차 알려줘" → LLM 호출 후 답변 생성 및 Vector DB 저장질문 2: "반품은 어떻게 진행하나요?" → 의미 유사도 95% 이상 감지 LLM 호출 없이 캐시 답변 반환
- 주의점: 유사도 Threshold를 너무 낮추면 엉뚱한 답을 반환하므로, 정책 변경 시 Cache Invalidation(파기) 전략이 필수입니다.
(2) Self-Hosted GPU vs Managed API 판단 기준
AI Agent의 인프라 비용을 최적화할 때는 Managed API를 사용할지, 직접 GPU 서버를 운영할지도 중요한 판단 요소입니다.
여기서 주의할 점은 자체 GPU 서버를 구축한다고 해서 무조건 비용이 저렴해지는 것은 아니라는 점입니다.
GPU는 사용하지 않는 시간에도 서버가 실행되고 있다면 비용이 계속 발생하기 때문에, 결국 핵심은 GPU Utilization(가동률) 입니다.
쉽게 말하면 비싼 GPU를 얼마나 쉬지 않고 효율적으로 사용하고 있는가가 Self-Hosted 환경의 경제성을 결정합니다.
- Managed API (Bedrock, OpenAI 등) 추천
- 트래픽 변동 폭이 큰 경우
- 야간이나 주말에는 요청량이 크게 감소하는 경우
- 서비스 초기 단계라 정확한 사용량을 예측하기 어려운 경우
- GPU 서버 구축 및 운영을 위한 DevOps 비용을 줄이고 싶은 경우
- Self-Hosted GPU가 적합한 경우
- 24시간 지속적이고 높은 트래픽(High QPS)이 보장되어 GPU 가동률이 70% 이상 유지될 때.
- Continuous Batching, PagedAttention, Prefix Caching을 직접 튜닝하여 서빙 효율을 극대화할 수 있는 역량이 있을 때.
정리
AI Agent 비용은 단순히 모델 가격표로 결정되지 않습니다. 한 번의 사용자 요청이 몇 번의 모델 호출로 이어지는지, 각 호출에 얼마나 긴 Prompt와 Context가 포함되는지, Tool과 검색 결과가 얼마나 반복되는지, 오류로 몇 번 재시도하는지에 따라 실제 비용이 달라집니다.
따라서 비용 최적화는 다음 순서로 접근하는 것이 좋습니다.
먼저 관측하고, 그다음 비용 누수를 찾고, 이후 입력·호출·Cache·인프라를 단계적으로 최적화합니다.
가장 먼저 실제 Trace에서 비싼 요청을 찾아야 합니다. 그 요청이 긴 History 때문인지, 불필요한 Tool Description 때문인지, Retrieval Context 때문인지, 반복 호출 때문인지 구분합니다. 이후 Single Turn과 Multi Turn을 분리하고, History·Tool·Context·Retry·Step에 예산을 설정합니다.
그다음 Prompt Caching, Batch, Semantic Cache를 적용할 수 있는 업무를 찾습니다. 트래픽이 충분히 크고 안정적일 때만 Self-hosted GPU의 손익을 계산합니다. 이 과정에서 비용만 보지 말고 정확도·근거 충실도·Latency·실패율·사람 개입률을 함께 확인해야 합니다.
결국 좋은 비용 최적화는 “가장 싼 모델을 쓰는 것”이 아니라, 필요한 품질을 유지하면서 불필요한 토큰·호출·재시도·인프라 유휴 시간을 줄이는 것입니다.
참고 자료
OpenAI Tokenizer
