Token 비용 엔지니어링 · 8 / 13

Agent 비용 함정 네 가지와 서킷 브레이커

지난 절에서 본 건 아직 「한 번 성공한 실행」이에요. 현실의 Agent 청구서 사고는 네 방향에서 옵니다: 도구 반환 폭발, 사고 세금, 무한 루프, 히스토리 스노우볼. 각각에 대응 엔지니어링 해법이 있어요.

도구 절단사고 세금루프 서킷 브레이커히스토리 압축

인터랙티브 데모 · 네 함정을 하나씩 뜯어보기

함정 1 · 도구 반환값의 정보 폭발

사용자가 「DB에서 모든 사용자 주문을 조회해 줘」라고 하면, Agent가 SQL 도구로 10,000건 ≈ 500,000 Token을 받아요. 이 50만 Token이 다음 턴 Input에 들어가면 고가 구간을 밟거나 컨텍스트 윈도우를 터뜨리고, 모델은 정보 과부하로 「길을 잃어」 출력 품질이 오히려 떨어져요. 해법은 모든 도구에 절단 보호를 씌우는 거예요:

def safe_tool_call(tool_func, *args, max_tokens=2000, **kwargs): result = tool_func(*args, **kwargs) result_str = json.dumps(result, ensure_ascii=False) estimated = len(result_str) * 0.5 # 粗略估算 Token if estimated > max_tokens: # 保留前后各一段 + 中间标记，提示模型缩小范围 truncated = result_str[:1000] + "\n...[잘림]...\n" + result_str[-500:] return { "status": "truncated", "preview": truncated, "total_records": len(result), "message": f"반환 결과가 너무 깁니다(약 {int(estimated)} Tokens). 잘랐어요. " "전체 데이터가 필요하면 조회 범위를 줄이세요." } return result

SQL 10,000건 ≈ 50만 Token: 절단 보호는 Agent 도구 계층의 기본 사양이에요. (그림: 저자 공유 원본)

함정 2 · 사고 Token의 숨은 청구서

Qwen-Plus 사고 모드, DeepSeek-R1, o1 같은 모델은 「사고 과정」을 생성해요: 사용자는 못 볼 수 있어도 전부 Output으로 과금되고, 단가는 4배（Qwen-Plus 비사고 출력 2위안/M, 사고 모드 8위안/M）. 같은 Agent 작업에 사고 모드를 켜면: 보이는 출력은 그대로(450 Token), 사고 과정 +2,000 Token, 출력 비용이 +2,078% 폭증해요.

작업 유형	사고 모드	이유
단순 검색	❌ 끄기	깊은 추론 불필요
데이터 정제	❌ 끄기	규칙이 명확해서 「생각할」 필요 없음
복잡한 추론	✅ 켜기	정확도를 위해 지불할 가치 있음
코드 생성	⚠️ 상황별	단순 함수는 끄고, 복잡한 아키텍처는 켜기

고급 해법: 0.6B급 초소형 모델로 앞단 분진—몇 리(厘)만 써서 이 요청에 깊은 사고가 필요한지 판단한 뒤 모드로 라우팅. 그게 3절 「T2가 T0을 보조」의 구체 형태예요.

모델의 「속마음」이 전부 돈을 태우고, 단가는 4배: 작업 등급별로 사고 모드를 켜고 끄세요. (그림: 저자 공유 원본)

함정 3 · 무한 루프

Agent가 버그를 고침: A 수정 → B 에러 → B 수정 → A 에러(원점) → …… 15턴째에도 돌아요. 매 턴 Input이 1,000 Token 불어나면 20턴에 비용이 13배; 더 나쁜 건 사용자가 5분을 기다려도 작업이 안 끝나는 거예요. 해법은 강제 서킷 브레이커—세 조건 중 하나라도 맞으면 우아한 종료:

class AgentExecutor: def __init__(self, max_rounds=10, max_tokens=50000): ... def execute(self, task): while not task.is_complete(): self.round_count += 1 # 熔断 1：轮次上限 if self.round_count > self.max_rounds: return self._graceful_exit("최대 실행 턴에 도달했습니다") # 熔断 2：Token 预算 if self.total_input_tokens > self.max_tokens: return self._graceful_exit("Token 예산 상한에 도달했습니다") # 熔断 3：死循环检测（连续 3 轮输出相似度 > 90%） if self._detect_loop(): return self._graceful_exit("무한 루프 가능성이 감지되었습니다") result = self._run_one_round(task) self.total_input_tokens += result.input_tokens

우아한 종료 때는 rounds_executed, tokens_consumed, partial_result를 함께 주세요—반제품이라도 블랙홀보다는 나아요.

턴 상한, Token 예산, 무한 루프 감지: 세 퓨즈로 작업이 무한 대기하지 않게 해요. (그림: 저자 공유 원본)

함정 4 · 히스토리 스노우볼 효과

표준(잘못된) 관행은 매 턴 전체 히스토리를 Input에 넣는 거예요. 최적화는 고정 접두사 + 압축 히스토리 + 최근 N턴: System Prompt는 절대 압축하지 않고(캐시 접두사 유지), 최근 3턴은 세부까지 남기고, 더 이른 히스토리는 소형 모델로 한 문장 요약으로 눌러요.

방안	10번째 턴 Input	설명
무한 팽창	~50,000 Tokens	전체 히스토리 포함
슬라이딩 윈도우(최근 5턴)	~12,000 Tokens	초기 컨텍스트 손실
고정 + 요약 + 최근 3턴	~6,000 Tokens	핵심은 지키면서 길이 통제

종합 체크리스트와 레드라인 세 줄

통제 지점	전략	기대 효과
도구 반환값	절단 + 요약, 상한 2k Tokens	단일 턴 폭발 방지
히스토리 관리	고정 접두사 + 오래된 히스토리 압축	Input 50%+ 절감
루프 통제	서킷 브레이커 메커니즘(턴 / Token / 무한 루프 감지)	밑 없는 구덩이 방지
사고 모드	작업 등급별 켜기	Output 비용 약 4배 절감
모델 선택	단순 서브태스크는 소형 모델	단가 절감
캐시 활용	System Prompt 고정, KV Cache 히트	Input 비용 약 90% 절감

레드라인	권장 임계	결과	대응
단일 턴 Input	< 32k Tokens	고가 구간 진입	히스토리 압축 + 도구 절단
총 턴 수	< 10턴	비용 지수 팽창	서킷 브레이커 메커니즘
I/O Ratio	모니터 > 50:1	Agent가 「공회전」	흐름 최적화 또는 작업 다운그레이드

핵심 요점

✓

도구 반환값에 2k 상한을 두세요: 절단 + 요약 + 범위 축소 안내로 단일 턴 Input 폭발을 막아요.

✓

사고 모드는 작업 등급별로: 안 보이는 속마음도 Output으로 과금되고, 단가는 4배예요.

✓

서킷 브레이커는 Agent의 퓨즈예요: 턴·Token 예산·무한 루프 감지 중 하나라도 맞으면 우아한 종료.

✓

히스토리는 「고정 + 요약 + 최근 3턴」으로, 거친 슬라이딩 윈도우보다 절반은 아끼면서도 기억을 잃지 않아요.

출처: 저자 팀 내부 공유 《AI Token 비용 엔지니어링 전략 공유》「Agentic 앱의 과금 메커니즘」에서 정리했어요. Agent 멈춤·실수 방지의 제품 관점은 실전편에 전용 절이 있고, 컨텍스트 압축은 Harness 핵심 · 컨텍스트 오버플로우를 함께 보세요.