토큰 폭발이란 무엇인가?
AI 에이전트(Agent)는 스스로 생각하고, 도구를 사용하고, 여러 단계에 걸쳐 작업을 처리하는 AI 시스템입니다. 처음 들으면 굉장히 편리하게 느껴지지만, 에이전트가 작업을 처리하는 과정에서 생각보다 엄청나게 많은 토큰을 소비한다는 함정이 있습니다. 이를 "토큰 폭발(Token Explosion)"이라고 합니다.
왜 폭발적으로 늘어날까요? 에이전트는 매 단계마다 지금까지의 대화 내용(컨텍스트)을 전부 모델에 다시 입력합니다. 3단계를 거치는 작업이라면, 1단계 내용이 2단계에, 1~2단계 내용이 3단계에 누적되어 들어갑니다. 단계가 늘어날수록 입력 토큰이 기하급수적으로 늘어나는 것이죠. 10단계짜리 작업이라면 토큰 사용량은 단순 계산보다 몇 배나 더 많아집니다.
처음 에이전트를 만들었을 때 저는 이 사실을 몰랐습니다. "문서 요약 → 핵심 키워드 추출 → 관련 자료 검색 → 최종 보고서 작성"이라는 4단계 파이프라인을 만들었는데, 한 번 실행할 때마다 예상보다 8~10배 많은 토큰이 소비됐습니다. 처음에는 버그인 줄 알았지만 알고 보니 컨텍스트 누적이 원인이었습니다. 그날 이후로 에이전트를 설계할 때는 반드시 토큰 사용량을 먼저 계산하는 습관이 생겼습니다.
에이전트 시스템의 편리함만 보고 도입을 결정하면, 나중에 청구서를 보고 멘붕할 수 있습니다. 자동화가 늘어날수록 비용도 자동으로 늘어납니다. 편리함과 비용 사이의 트레이드오프를 반드시 이해하고 시작해야 합니다. "에이전트를 도입하면 효율이 좋아진다"는 말은 토큰 비용을 잘 관리할 때만 사실입니다.
에이전트가 토큰을 많이 쓰는 이유
에이전트의 토큰 소비가 일반 챗봇보다 훨씬 많은 이유는 크게 세 가지입니다.
첫째, 시스템 프롬프트(System Prompt) 반복 입력입니다. 에이전트는 매 단계마다 "너는 이런 역할을 하는 AI야, 이런 도구를 쓸 수 있어"라는 긴 설명을 처음부터 다시 받습니다. 이 설명이 500 토큰이라면 10단계 작업에서만 5,000 토큰이 시스템 프롬프트로만 낭비됩니다.
둘째, 히스토리 누적입니다. 앞서 설명한 것처럼 대화 히스토리가 계속 쌓여 매 단계 입력 토큰이 늘어납니다.
셋째, 도구 호출(Tool Call) 결과 포함입니다. 에이전트가 웹 검색이나 데이터베이스 조회를 할 때 그 결과 전체가 다음 입력에 포함됩니다. 검색 결과가 2,000 토큰이라면 그게 고스란히 다음 단계 입력에 더해집니다.
[일반 챗봇 1회 요청]
입력: 사용자 질문 50 tokens + 시스템 프롬프트 200 tokens = 250 tokens
출력: 답변 200 tokens
합계: 450 tokens
[4단계 에이전트 동일 작업]
1단계: 250 + 200 = 450 tokens
2단계: 450 + 이전결과 300 + 200 = 950 tokens
3단계: 950 + 이전결과 500 + 200 = 1,650 tokens
4단계: 1,650 + 이전결과 400 + 200 = 2,250 tokens
합계: 5,300 tokens (챗봇 대비 약 12배)
이걸 처음 계산해봤을 때 솔직히 충격이었습니다. 내가 만든 에이전트가 겨우 4단계짜리인데 이미 챗봇의 12배를 쓰고 있다니. 실제 서비스에는 10~20단계짜리 워크플로우도 흔한데, 그렇다면 비용이 단순 계산으로도 수십 배가 됩니다. 에이전트는 자동화의 꽃이지만, 비용이라는 가시가 있다는 걸 잊지 말아야 합니다.
이 문제는 단순히 개발자의 실수가 아니라 에이전트 시스템의 구조적 특성에서 비롯됩니다. 그러므로 비용 폭발을 막으려면 "어떻게 에이전트를 잘 만드냐"가 아니라 "에이전트가 정말 필요한 작업인가"를 먼저 판단하는 것이 더 중요합니다. 단계가 많은 에이전트가 항상 좋은 에이전트는 아닙니다.
실제 비용이 얼마나 늘어나나?
구체적인 숫자로 살펴보겠습니다. 예를 들어 채용 지원서를 자동 분석하는 에이전트를 만든다고 가정합니다. 이력서를 읽고 → 직무 요건과 비교하고 → 점수를 매기고 → 합격 여부를 판단하는 4단계 구조입니다.
[단순 1회 처리 시 예상 비용]
이력서 텍스트: 800 tokens
직무 요건: 300 tokens
시스템 프롬프트: 400 tokens
각 단계 출력 합산: 약 600 tokens
단순 합산: 약 2,100 tokens
[실제 에이전트 처리 시]
컨텍스트 누적 포함 실제 토큰: 약 7,500~9,000 tokens
(단순 예상의 3.5~4.3배)
월 1,000건 처리 × 8,000 tokens × $15/1M tokens = $120/월
만약 단순 처리였다면: 1,000건 × 2,100 tokens × $15/1M tokens = $31.5/월
차이: 약 4배, 월 $88.5 추가 발생
직접 채용 자동화 PoC(개념 검증)를 만들면서 이 수치를 경험했습니다. 처음 기획서에 써둔 예상 비용의 4배가 나왔고, 팀장에게 보고했다가 한 소리 들었습니다. 그때 배운 교훈이 "에이전트 비용은 반드시 실제 실행해서 측정하라"입니다. 이론적 계산과 실제는 항상 차이가 있습니다.
비용 예측의 어려움은 에이전트 시스템의 큰 단점 중 하나입니다. 일반 API 호출은 요청당 비용이 예측 가능하지만, 에이전트는 실행 경로가 동적으로 달라지기 때문에 어떤 때는 3단계로 끝나고 어떤 때는 15단계로 늘어납니다. 이런 불확실성 때문에 예산 책정이 어렵고, 갑작스런 비용 급증이 발생하기 쉽습니다. 사전에 최대 단계 수 제한, 토큰 상한선 설정 등의 안전장치를 반드시 마련해야 합니다.
토큰 절약 전략
토큰 폭발을 막는 실전 전략들을 소개합니다.
1. 컨텍스트 압축(Context Compression): 매 단계가 끝나면 이전 내용을 요약해서 저장하고, 전체 원문 대신 요약본만 다음 단계에 전달합니다. 원문 1,000 토큰을 100 토큰 요약으로 교체하면 90%를 아낄 수 있습니다.
2. 체크포인팅(Checkpointing): 각 단계의 결과를 데이터베이스나 파일에 저장합니다. 에이전트가 중간에 실패해도 처음부터 다시 시작하지 않고, 마지막 성공 단계부터 재개합니다. 실패 재시도 비용을 크게 줄입니다.
3. 필요한 정보만 전달(Selective Context): 다음 단계에 필요한 정보만 골라서 전달합니다. 전 단계의 모든 결과가 다음 단계에 반드시 필요한 건 아닙니다.
4. 단계 수 최소화: 에이전트를 설계할 때 "이 단계가 정말 필요한가?"를 계속 질문합니다. 합칠 수 있는 단계는 합치고, 생략 가능한 단계는 과감히 제거합니다.
# 컨텍스트 압축 예시
def compress_context(full_context: str, model: str) -> str:
summary_prompt = f"""
다음 내용을 핵심만 100 토큰 이내로 요약하세요:
{full_context}
"""
return call_model("haiku", summary_prompt) # 저렴한 모델로 압축
# 각 에이전트 단계에서 사용
compressed = compress_context(previous_step_result)
next_step_input = f"{system_prompt}\n이전 결과 요약: {compressed}\n현재 작업: ..."
컨텍스트 압축을 적용하고 나서 실제로 토큰 사용량이 약 60% 줄었습니다. 하지만 처음에 압축 프롬프트를 잘못 짜서 중요한 정보가 요약에서 빠지는 일이 있었습니다. 압축을 너무 공격적으로 하면 에이전트가 잘못된 판단을 내릴 수 있어서, 압축 수준의 조정이 꽤 까다로웠습니다. 압축 자체도 결국 모델을 한 번 더 쓰는 것이라 너무 잦은 압축은 오히려 비효율이 될 수 있습니다.
이 전략들이 모두 유효하지만, 어떤 것도 은총알(Silver Bullet)은 아닙니다. 상황에 따라 맞는 전략이 다르고, 여러 전략을 조합해야 최적 결과가 나옵니다. 가장 중요한 건 자신의 에이전트 파이프라인에서 어디서 토큰이 가장 많이 소비되는지 먼저 측정하고, 그 병목을 집중적으로 공략하는 것입니다. 감으로 접근하지 말고 데이터로 접근하세요.
자동화와 비용의 균형 잡기
에이전트 시스템을 잘 활용하려면 "자동화의 가치 > 추가 토큰 비용"인지를 항상 계산해야 합니다. 어떤 작업을 에이전트로 자동화했을 때 사람이 하는 시간을 1시간 줄일 수 있다면, 그 자동화에 드는 추가 비용이 1시간의 인건비보다 낮아야 합니다. 이 기준이 명확해야 불필요한 자동화를 막을 수 있습니다.
비용 모니터링 시스템도 필수입니다. 에이전트가 실행될 때마다 토큰 사용량을 로깅하고, 비용이 임계값을 넘으면 알람이 오도록 설정해야 합니다. 나중에 청구서로 알게 되면 이미 늦습니다.
# 비용 모니터링 예시
import logging
MAX_TOKENS_PER_RUN = 50000 # 1회 실행 최대 토큰
DAILY_BUDGET_USD = 50.0 # 일일 예산
class TokenMonitor:
def __init__(self):
self.daily_usage = 0
self.daily_cost = 0.0
def log_usage(self, tokens: int, model: str):
cost_per_token = self.get_cost(model)
cost = tokens * cost_per_token
self.daily_usage += tokens
self.daily_cost += cost
if self.daily_cost > DAILY_BUDGET_USD * 0.8:
logging.warning(f"⚠️ 일일 예산 80% 도달: ${self.daily_cost:.2f}")
if self.daily_cost > DAILY_BUDGET_USD:
raise Exception("❌ 일일 예산 초과. 에이전트 실행 중단.")
예산 초과 경험을 한 번 해본 뒤로 모니터링에 신경을 많이 쓰게 됐습니다. 주말에 에이전트를 자동 실행으로 설정해두고 월요일에 출근했더니 예상보다 10배 많은 비용이 찍혀 있었습니다. 루프 버그로 에이전트가 같은 작업을 수백 번 반복한 것이었습니다. 그 이후로는 최대 실행 횟수, 총 토큰 상한선, 비용 알람을 항상 먼저 설정하고 에이전트를 배포합니다.
에이전트 시스템은 분명 미래입니다. 하지만 "자동화 = 효율"이라는 단순한 공식은 위험합니다. 자동화할수록 비용도 함께 자동화되어 늘어납니다. 에이전트를 도입하기 전에 반드시 비용 시뮬레이션을 해보고, 모니터링 체계를 갖추고, 단계 수를 최소화하는 설계 원칙을 지켜야 합니다. 멋있어 보인다는 이유만으로 에이전트를 남발하면 서비스가 아니라 비용 기계가 탄생합니다.
📌 출처 및 참고 자료
- Anthropic — Building Effective Agents: https://www.anthropic.com/research/building-effective-agents
- LangGraph 공식 문서 — Agent 비용 관리: https://langchain-ai.github.io/langgraph/
- Anthropic Claude API — Token Usage Tracking: https://docs.anthropic.com/en/docs/build-with-claude/token-counting
- OpenAI Cookbook — Reducing LLM Costs: https://cookbook.openai.com/
- Harrison Chase (LangChain) — Managing Agent Token Costs: https://blog.langchain.dev/