프로덕션 환경에서 AI 에이전트 토큰 비용을 줄이는 방법

TL;DR

AI 에이전트는 각 단계에서 지시문, 대화 기록, 도구 결과, 중간 상태를 반복 처리하기 때문에 토큰 비용이 커집니다.

런 단위 예산, 도구 결과 필터링, 컨텍스트 압축, 재시도 제한, 제어된 추론으로 토큰 볼륨을 줄이세요. 반복되는 입력에는 프롬프트 캐싱을 사용하되, 더 저렴한 모델로 바꾸기 전에 먼저 에이전트 루프를 최적화하세요.

가장 유용한 프로덕션 지표는 최종 호출의 컨텍스트 크기나 요청당 가격이 아니라, 전체 실행을 기준으로 한 성공한 작업당 비용입니다.

이 가이드는 특히 다단계 AI 에이전트에 초점을 맞춥니다. 실행 전반에서 반복 컨텍스트가 어떻게 누적되는지, 가장 큰 낭비 원인을 식별하는 방법, 그리고 무엇부터 통제해야 하는지를 설명합니다.

Introduction

챗봇은 사용자 메시지당 한 번의 모델 요청만 할 수 있습니다. AI 에이전트는 하나의 작업을 완료하기 전까지 10회, 20회 이상 호출할 수 있습니다.

각 단계는 지시문, 대화 기록, 도구 결과, 중간 상태를 다시 보낼 수 있습니다. 재시도, 추론, 서브에이전트가 사용량을 더해, 최종 답변이 짧더라도 많은 토큰을 소비할 수 있습니다.

사용량이 늘수록 비용 예측이 어려워지고 제품 마진이 빠르게 감소할 수 있습니다. 이를 낮추려면 저렴한 모델로 바꾸는 것이 아니라 에이전트 루프 전체를 최적화해야 합니다.

이 글은 에이전트 특유의 비용에 집중합니다. 프롬프트 캐싱, 정확 응답 캐싱, 의미론적 캐싱, 모델 라우팅, 일반적인 API 비용 관리에 대한 폭넓은 가이드는 AI API 비용 줄이는 방법을 참고하세요.

Why Do AI Agent Token Costs Compound?

다단계 에이전트에서 한 작업의 비용은 최종 응답뿐 아니라 모든 모델 호출의 합입니다.

에이전트 토큰 사용의 주요 원천은 다음과 같습니다:

비용을 줄이는 방법은 두 가지입니다:

1. 필터링, 압축, 출력 제한, 루프 제어를 통해 처리하는 토큰 수를 줄입니다.
2. 프롬프트 캐싱이나 모델 선택으로 필요한 토큰의 유효 단가를 낮춥니다.

Key distinction: 프롬프트 캐싱은 반복 입력의 비용을 낮춥니다. 컨텍스트 압축은 반복 입력 자체를 줄입니다.

How Can a 12-Step Agent Process 147,000 Tokens?

가상의 지원 에이전트를 가정해 봅시다:

• 4,000 토큰의 안정적인 프리픽스
• 각 단계 이후 1,500개의 신규 토큰 추가
• 매 요청마다 누적된 전체 히스토리를 재전송
• 총 12회의 모델 호출

단계 n에서의 입력은:

Input at step n = 4,000 + 1,500 × (n - 1)

12회 호출에 걸친 누적 입력은:

Total input
= 4,000 × 12 + 1,500 × (0 + 1 + ... + 11)
= 48,000 + 99,000
= 147,000 input tokens

최종 호출에는 입력 토큰이 20,500개뿐이지만, 전체 실행에서는 누적 입력 토큰이 147,000개 처리됩니다.

여기에 두 가지 통제를 적용해 보겠습니다:

1. 첫 호출 이후 안정적인 4,000 토큰 프리픽스를 캐시합니다.
2. 6단계 이후의 히스토리를 2,500 토큰 상태 요약으로 압축합니다.

이는 벤치마크가 아닌 계획 계산입니다.

모든 요청이 누적된 전체 히스토리를 포함한다고 가정합니다. 과거 메시지를 선택적으로 구성하거나 요약하거나, 관련 정보만 조회하는 에이전트는 다른 비용 곡선을 따를 수 있습니다.

Cost-growth rule: 전체 실행에 걸친 누적 입력을 측정하세요. 최종 컨텍스트 크기는 처리된 토큰의 총량을 대표하지 않습니다.

Which Metrics Reveal Agent Token Waste?

모델부터 바꾸지 마세요. 먼저 결과를 개선하지 못한 채 토큰을 소모하는 지점을 파악하세요.

각 에이전트 단계에서 다음 필드를 기록하세요:

주요 지표는 다음과 같습니다:

cost per successful task
= total workflow cost
/ accepted tasks

더 저렴한 실행이 실패 증가, 도구 재호출, 사람의 후속 수정으로 이어진다면 개선이 아닙니다.

에이전트 특화 지표 네 가지가 문제 지점을 찾는 데 도움됩니다.

Context Amplification

context amplification
= cumulative input tokens
/ final-step input tokens

값이 높으면 이전 컨텍스트가 반복 처리되고 있음을 의미합니다.

Tool Retention Ratio

tool retention ratio
= tool-result tokens retained in context
/ tokens originally returned by tools

비율이 높으면 원시 증거를 과도하게 다음 단계로 전달하고 있을 수 있습니다.

Retry Tax

retry tax
= retry and repair cost
/ total workflow cost

Reasoning Share

reasoning share
= reasoning-token cost
/ total model cost

워크로드별로 별도 측정하세요. 리서치, 코딩, 브라우저, 고객 지원 에이전트는 공통 기준선을 공유하면 안 됩니다.

Six Ways to Reduce AI Agent Token Costs

1. Set a Budget for the Complete Run

요청당 출력 제한만으로는 다단계 에이전트를 제어할 수 없습니다.

다음 항목에 대해 실행(런) 단위 제한을 설정하세요:

• 전체 모델 단계 수
• 누적 입력/출력 토큰
• 도구 호출 수 및 도구 결과 크기
• 실패 유형별 재시도
• 서브에이전트 수
• 총 경과 시간 또는 예상 비용

다음의 공급자 중립 Python 예시는 각 모델 호출 전에 실행 상태를 평가합니다:

from dataclasses import dataclass
from enum import Enum


class Action(str, Enum):
    CONTINUE = "continue"
    COMPACT = "compact"
    STOP = "stop"


@dataclass(frozen=True)
class Budget:
    max_steps: int = 12
    max_input_tokens: int = 120_000
    max_output_tokens: int = 18_000
    compact_at: float = 0.80


@dataclass
class Usage:
    steps: int = 0
    input_tokens: int = 0
    output_tokens: int = 0


def evaluate_budget(usage: Usage, budget: Budget) -> Action:
    if (
        usage.steps >= budget.max_steps
        or usage.input_tokens >= budget.max_input_tokens
        or usage.output_tokens >= budget.max_output_tokens
    ):
        return Action.STOP

    input_ratio = usage.input_tokens / budget.max_input_tokens

    if input_ratio >= budget.compact_at:
        return Action.COMPACT

    return Action.CONTINUE

모델 요청 전에 매번 이 검사를 실행하고, 공급자가 보고한 토큰 데이터로 Usage를 업데이트하세요.

입력 예산의 80%에 도달하면 상태를 압축하거나 다음 도구 쿼리를 좁히세요. 100%면 구조화된 사유와 함께 중단하세요.

자주 하는 실수: 각 응답만 제한하고 단계, 도구, 재시도는 무제한으로 두는 것.

2. Filter Tool Results Before They Enter the Transcript

에이전트의 다음 결정을 위해 필요한 증거만 반환하세요.

다음 전체 내용을 추가하지 마세요:

• 웹 페이지
• 로그 파일
• 리포지토리 트리
• 데이터베이스 응답
• 터미널 세션
• API 페이로드

다음 단계에 몇 개의 필드만 필요할 때는 특히 그렇습니다.

검색 도구는 다음과 같이 반환할 수 있습니다:

{
  "source_id": "search_17",
  "title": "Relevant page title",
  "url": "https://example.com/page",
  "relevant_passage": "A short evidence block"
}

프롬프트 밖에 전체 산출물을 저장하고, 나중에 더 좁은 섹션을 조회하세요.

Tool-filtering rule: 다음 결정을 위해 필요한 필드만 반환하세요. 나중에 쓸지도 모르는 모든 필드를 담지 마세요.

자주 하는 실수: JSON 페이로드의 앞 1,000자를 단순히 자르는 것. 구조가 깨지거나 실제 필요한 레코드가 제거될 수 있습니다.

먼저 페이로드를 파싱하고, 구조적으로 필드를 선택하고, 배열을 제한한 뒤, 유효한 JSON으로 직렬화하세요.

3. Compact Operational State, Not Just Conversation Text

압축은 다음 행동에 영향이 없는 과거 내러티브를 제거하면서, 작업을 이어가는데 필요한 정보를 보존해야 합니다.

유용한 압축 상태에는 다음이 담깁니다:

• 사용자 목표와 성공 기준
• 이미 내린 결정
• 검증된 사실과 소스 ID
• 변경된 파일 또는 레코드
• 실패한 접근
• 열린 질문
• 다음 액션
• 안전 및 출력 제약

전체 대화를 다시 서술하지는 않아야 합니다.

OpenAI는 장기 Responses API 상호작용을 위한 압축을 문서화하고 있습니다. Anthropic은 오래된 콘텐츠를 비우거나 요약하는 컨텍스트 관리 제어를 제공합니다. 구현이 다르므로 통합 전 최신 공급자 필드를 확인하세요.

Compaction rule: 결정과 미해결 작업을 보존하고, 재조회 가능한 내러티브와 증거는 제거하세요.

자주 하는 실수: 소스 ID, 변경된 파일명, 거부된 접근 방식, 미해결 제약을 누락하는 것.

압축을 추가한 뒤 에이전트가 검색이나 도구 호출을 반복하는지 측정하세요. 프롬프트가 짧아져도 상태를 다시 구축하느라 오히려 비싸질 수 있습니다.

4. Keep the Reusable Prefix Stable

에이전트 프롬프트에는 재사용 가능한 큰 블록이 자주 포함됩니다:

• 시스템 지시문
• 도구 스키마
• 안전 정책
• 출력 형식
• 공통 참고 자료
• 리포지토리 또는 제품 지침

이러한 안정 요소를 요청별 데이터 앞에 배치하세요:

1. System instructions
2. Policies and constraints
3. Tool definitions
4. Stable examples
5. Shared reference material
6. Request-specific data

타임스탬프, 요청 ID, 세션 데이터처럼 자주 변하는 값은 앞부분에 두지 마세요.

프리픽스가 길고 안정적이며 재사용될 때 캐싱이 가장 유용합니다. 세션이 짧거나 프롬프트가 자주 변한다면 비용 절감이 크지 않을 수 있습니다.

자주 하는 실수: 캐시 적중률만 최적화하고, 캐시 쓰기/읽기/저장 비용을 측정하지 않는 것.

공급자별 프롬프트 캐싱, 정확 응답 캐싱, 의미론적 캐싱 비교에 대해서는 AI API 비용 줄이는 방법을 참고하세요.

5. Prevent Retries From Replaying the Same Context

재시도는 보통 동일한 큰 프롬프트로 이루어지는 또 하나의 에이전트 단계입니다.

원인 수정 없이 실패 요청을 반복하지 마세요.

결제, 이메일, 배포, DB 쓰기처럼 부작용이 있는 작업에는 멱등성 키를 사용하세요.

자주 하는 실수: 전체 에이전트 컨텍스트를 매번 재전송하면서 레이트 리밋된 모델을 여러 번 재시도하는 것.

실패 유형별 재시도 비용 비중을 추적하여 가장 큰 루프부터 수정하세요.

6. Limit Reasoning and Subagents to Steps That Need Them

모든 단계에 깊은 추론이 필요한 것은 아닙니다.

추출, 포맷팅, 분류, 검증, 일상적 도구 선택은 낮은 추론 강도와 간결한 구조화 출력으로 충분한 경우가 많습니다.

높은 추론은 다음 작업에 할당하세요:

• 복잡한 계획
• 난이도 높은 코딩
• 다문서 종합
• 모호한 의사결정
• 실행 실패 후 복구

Reasoning rule: 승인율을 유지하는 최저 수준의 추론 강도를 사용하세요.

서브에이전트에도 명확한 경계를 두세요. 각 작업자에게는 다음을 부여합니다:

• 좁은 작업
• 작업 특화 컨텍스트 슬라이스
• 도구 허용 목록
• 토큰 예산
• 간결한 출력 스키마

루트 에이전트가 필요한 것은 보통 발견사항, 증거 ID, 신뢰도, 미해결 이슈이지 작업자의 전체 대화 내역이 아닙니다.

Subagent rule: 컨텍스트를 중복하지 말고, 독립 작업을 병렬화하세요.

자주 하는 실수: 좁은 작업을 할당하기 전에 루트 에이전트의 전체 히스토리를 모든 작업자에게 전송하는 것.

Which Optimization Should You Apply First?

에이전트 텔레메트리로 첫 개입 지점을 선택하세요.

아래 임계치는 조사 트리거일 뿐, 보편적 기준이 아닙니다.

안전한 구현 순서는 다음과 같습니다:

1. 누적 입력, 도구 유지 비율, 재시도, 추론을 측정합니다.
2. 단계, 도구, 재시도, 총 토큰에 대한 하드 제한을 추가합니다.
3. 큰 도구 결과를 필터링합니다.
4. 측정된 임계치에서 오래된 상태를 압축합니다.
5. 재사용 프롬프트 프리픽스를 안정화합니다.
6. 에이전트 루프를 정리한 후에만 모델 라우트를 비교합니다.

한 번에 하나의 주요 변수를 변경하고 동일한 평가 세트를 재실행하세요.

다음을 비교하세요:

• 작업 승인율
• 성공한 작업당 비용
• 누적 입력
• 도구 호출 수
• 재시도 비용 비중
• 추론 비중
• p50 및 p95 지연시간
• 인간 검토 시간

작업 품질을 떨어뜨리거나 필요한 증거를 제거하여 토큰만 절약하는 변경은 롤백하세요.

Test Agent Workflows With CometAPI

다중 모델 평가를 실행하기 전에, CometAPI의 가격 페이지와 비용 추정 가이드를 사용해 입력, 출력, 캐시 토큰, 추론 비용을 추정하세요.

그 다음 모델 카탈로그로 사용 가능한 라우트를 식별하고 퀵스타트로 OpenAI 호환 클라이언트를 구성하세요.

프로덕션 폴백을 위해서는 CometAPI 모델 폴백 가이드를 따라, 완료된 도구 호출을 반복하거나 검증된 상태를 버리지 않고 라우트를 전환하세요.

통합 액세스는 모델 비교와 폴백 통합을 단순화합니다. 그러나 토큰 예산, 압축, 검증, 도구 필터링, 재시도 제한, 승인 기준은 여전히 애플리케이션 레벨에 있어야 합니다.

FAQ

Why do AI agents use more tokens than chatbots?

에이전트는 여러 차례 모델을 호출하고, 매 단계마다 이전 메시지, 도구 결과, 지시문, 중간 상태를 재전송할 수 있습니다. 이로 인해 이전 컨텍스트가 반복 처리됩니다.

Does prompt caching reduce context-window usage?

아니요. 프롬프트 캐싱은 반복 입력의 비용 또는 지연시간을 낮출 수 있지만, 캐시된 토큰도 처리 컨텍스트의 일부입니다. 프롬프트 크기를 줄이려면 압축, 필터링, 선택적 조회를 사용하세요.

When should an AI agent compact its context?

비용, 지연시간, 가용 출력 공간에 영향이 나타나기 전에 압축하세요. 압축 상태가 결정, 증거 ID, 변경된 파일, 열린 질문, 안전 제약을 보존하는지 확인하세요.

Do subagents reduce token costs?

자동으로 그렇지는 않습니다. 독립 작업의 경과 시간을 줄이거나 커버리지를 높일 수 있지만, 컨텍스트 중복과 분석 중첩은 총 토큰 사용을 늘리는 경우가 많습니다.

What is the best metric for AI agent cost optimization?

주요 지표로 성공한 작업당 비용을 사용하세요. 누적 입력, 컨텍스트 증폭, 도구 보존, 재시도 비용, 추론 비중, 지연시간, 인간 검토 시간으로 진단하세요.