AI Agent 비용 제어: 모델 라우팅, 도구 예산, 캐시, 재시도 한도 설계

새벽 3 시, 백그라운드 report Agent 가 빈 응답을 돌려줍니다. HTTP 상태 코드는 200 이지만 body 는 비어 있습니다. 재시도 로직은 상태 코드만 확인하므로 계속 다시 시도합니다. 요청마다 500 token 입력을 보내고, 1,500 번 재시도한 끝에 75 만 token 을 태웁니다. 다음 날 아침 청구서를 보고 나서야 문제가 보입니다.

근본 원인은 “비싼 모델을 골랐다”가 아닙니다. 빠진 것은 세 가지입니다. circuit breaker, 예산 확인, 오류 분류입니다. Agent 비용이 통제되지 않는 전형적인 패턴은 세 가지입니다.

재시도에 상한이 없습니다. 실패 모드 분류가 없어 빈 응답을 재시도 가능한 오류로 취급합니다. circuit breaker 도 없어서 1,500 번 연속 실패해도 멈추지 않습니다. 재시도마다 전체 컨텍스트를 다시 보내 비용이 2-5 배 커집니다.

컨텍스트가 비대해집니다. 긴 작업이 6 시간 동안 실행되며 대화 기록이 80K tokens 까지 커집니다. checkpoint 가 없으면 실패 후 처음부터 다시 실행하고, 모든 단계에서 다시 비용을 냅니다.

모델을 과하게 씁니다. 라우팅 전략 없이 모든 작업을 frontier model 로 보냅니다. 단순 분류 작업도 가장 비싼 모델을 사용해 token 의 70% 를 낭비합니다.

Agent 비용 제어는 단일 최적화가 아닙니다. 예산 객체, 라우팅 전략, 캐시 히트, 재시도 차단, 비용 로그, 알림 임계값을 겹겹이 설계하는 일입니다. 이 여섯 가지 엔지니어링 대상을 판단표나 실행 가능한 체크로 바꿔야 합니다.

예산 객체 설계: 무엇을 기록하고, 어디에 두며, 어떻게 차단할까

비용 제어는 예산 객체에서 시작합니다. 총액만 기록해서는 부족합니다. 계층이 없으면 청구 이상이 생겼을 때 어떤 사용자, 작업, 도구가 비용을 태웠는지 찾을 수 없습니다.

7 계층 예산 객체

예산 객체는 거친 단위에서 세밀한 단위로 7 계층으로 나눌 수 있습니다.

예산 계층	예산 객체	권장 상한	알림 조건
Layer 1	user	사용자별 일/월 상한	잔여 < 20% 알림
Layer 2	tenant	tenant 별 독립 예산 풀	잔여 < 30% 알림
Layer 3	workflow	workflow 유형별 독립 예산	잔여 < 40% 알림
Layer 4	task	작업 유형별 독립 예산	잔여 < 50% 알림
Layer 5	tool	도구 호출별 독립 예산	상한 초과 시 도구 건너뛰기
Layer 6	retry	재시도 횟수 상한 + circuit breaker	연속 실패 N 회 후 도구 비활성화
Layer 7	cache	캐시 히트율 모니터링	히트율 < 기대값 알림

각 계층의 예산 상한은 비즈니스 모델에 따라 달라지는 설정입니다. 하지만 계층 구조 자체는 안정적입니다. 남은 예산 필드는 비용 로그에 써서 알림과 차단 판단에 사용합니다.

각 계층이 기록해야 할 필드

각 예산 계층은 다음 필드를 기록해야 합니다.

필드명	용도	타입	기록해야 하는 이유
model	모델 식별	string	모델 라우팅이 적절한지 판단
inputTokens	입력 token 수	integer	입력 비용 계산
outputTokens	출력 token 수	integer	출력 비용은 별도로 기록해야 함
cachedTokens	캐시 히트 token 수	integer	캐시 절감 효과 계산
costEstimate	이번 호출의 비용 추정	float	실시간 비용 누적
budgetRemaining	남은 예산	float	circuit breaker 판단 근거

예산 객체 설계의 핵심은 “차원별 회계”입니다. “total_cost 만 기록”하는 것이 아닙니다. 멀티테넌트에서는 tenantId 로 비용을 나누고, 여러 도구를 쓰는 경우 toolName 으로 블랙박스를 찾아야 합니다.

차단 로직

남은 예산이 임계값보다 낮으면 circuit breaker 를 발동합니다.

def check_budget_before_retry(budget_remaining, retry_cost_estimate):
    if budget_remaining < retry_cost_estimate:
        return "skip_retry"  # 예산을 넘기므로 재시도 건너뛰기
    if budget_remaining < threshold:  # threshold 예: 20%
        return "wait_approval"  # 잔여 예산이 부족하므로 승인 대기
    return "continue"

차단 로직은 재시도 후가 아니라 재시도 전에 남은 예산을 확인해야 합니다. 매번 재시도 전에 비용을 추정하고, 예산을 넘으면 멈춥니다. 그래야 “빈 응답을 1,500 번 재시도해 하루 예산을 태우는” 일을 피할 수 있습니다.

어떤 컨텍스트를 안정적인 prefix 에 넣고 어떤 것을 실행 시 변수로 뒤에 둘지는 같은 시리즈의 context engineering 글에서 다룹니다.

모델 라우팅 전략: 모든 작업에 가장 비싼 모델이 필요한 것은 아니다

ticket triage Agent 의 실제 분포를 보면 70% 는 단순 분류, 20% 는 답변 초안, 고객에게 메일을 보내기 전 frontier model 로 올려야 할 작업은 10% 정도입니다. 라우팅 전략은 비용을 40-85% 줄일 수 있습니다.

모델 계층 라우팅

모델 계층 라우팅은 작업 복잡도로 나눕니다.

작업 계층	전형적 작업	권장 모델 계층	비중	비용 특성
70% - S 급	분류, 추출, 필터링, 간단 Q&A	nano/flash(가장 저렴)	70%	짧은 출력, 적은 턴, 적은 도구 호출
20% - M 급	초안, 요약, 코드 생성, 중간 수준 추론	mid-tier(중간 가격)	20%	중간 길이 출력, 도구 호출 가능
10% - L 급	리뷰, 아키텍처 설계, 복잡 추론, 다중 도구 조율	frontier(가장 비쌈)	10%	긴 출력, 많은 턴, 잦은 도구 호출

라우팅 전략은 세 단계입니다.

첫 단계: 작업을 분류합니다. 각 workflow 에 S/M/L 복잡도 기준을 정의합니다. 출력 길이, 도구 호출 수, 추론 깊이, 위험 수준을 포함합니다.

둘째 단계: 기본값은 S 급입니다. 복잡한 특징에 해당할 때만 M 또는 L 로 올립니다.

셋째 단계: 단계적으로 올립니다. S 급 모델이 실패하면 M 급, M 급이 실패하면 L 급으로 올립니다. L 급도 실패하면 사람 개입으로 넘깁니다. 올리기 전에 남은 예산을 확인하고, 초과하면 업그레이드를 건너뜁니다.

서비스 계층 라우팅

같은 모델도 latency priority 에 따라 나눌 수 있습니다. 할인율과 완료 시간은 변하기 쉬우므로 공개 전에 공식 가격을 다시 확인합니다.

서비스 계층	비용 할인	완료 시간	적합한 경우
Realtime API	할인 없음	즉시 응답	대화형 Agent, 높은 우선순위 작업
Batch API	50% cost discount(공개 전 재확인)	24-hour turnaround(공개 전 재확인)	batch eval, 분류, embedding, 콘텐츠 저장소 처리
Flex Processing	낮은 비용(공개 전 재확인)	느린 응답, 간헐적 사용 불가	낮은 우선순위 비동기 작업, model evaluations, data enrichment

오프라인 작업 라우팅 체크리스트입니다.

• 즉시 응답이 필요한가요? 예 -> Realtime API, 모델 라우팅 적용.
• 24 시간 지연을 허용할 수 있나요? 예 -> Batch API.
• 낮은 우선순위이고 간헐적 실패를 허용하나요? 예 -> Flex Processing.
• eval, 분류, embedding 같은 batch 처리인가요? 예 -> Batch API.

위험도 분류

작업은 위험 수준별로도 나누고, 이에 따라 라우팅 경로를 바꿉니다.

위험 수준	전형적 작업	라우팅 전략	예산 분기
낮은 위험	분류, 추출, 내부 요약	S 급 모델 + 자동 경로	승인 없음, 예산 상한 여유
중간 위험	고객 답변 초안, 코드 변경 제안	M 급 모델 + 선택 승인	예산 초과 시 승인 요청 가능
높은 위험	고객 메일 발송, 결제, 아키텍처 변경	L 급 모델 + 필수 승인	승인 대기, 거절, timeout 이 예산 분기

승인 대기, 거절, timeout 이 예산 분기에 어떤 영향을 주는지는 같은 시리즈의 Human-in-the-Loop 글에서 다룹니다.

핵심 제약

라우팅 전략에는 몇 가지 제약이 필요합니다.

• 가격 숫자를 하드코딩하지 않습니다: 가격은 변합니다. 비용 공식을 비즈니스 로직에 박지 말고 model + pricingVersion 을 기록합니다.
• 남은 예산을 확인합니다: 올리기 전에 budgetRemaining 을 확인합니다. 예산이 부족하면 건너뛰거나 승인을 요청합니다.
• 오류를 분류합니다: 라우팅 실패는 복구 가능한 모델 능력 부족과 복구 불가능한 파라미터 오류, 권한 거부를 구분해야 합니다.

도구 호출 예산: per-tool budget, timeout, 재시도 상한

도구 호출에는 schema 비용과 API 비용이 함께 있습니다. 매번 schema, 인자, 응답 파싱 컨텍스트를 보내고, 외부 API 는 rate limit 이나 timeout 을 낼 수 있습니다. 이 비용은 모델 호출과 별도입니다.

도구 예산 제어

각 도구에 독립적인 예산 제어를 설정합니다.

제어 항목	권장 설정	모니터링 필드	트리거 동작
Per-tool budget	호출당 상한	tool_cost_estimate	상한 초과 시 도구 건너뛰기 또는 강등
Tool timeout	외부 API timeout	tool_duration	timeout 을 재시도 가능 오류로 표시
Retry limit per tool	단일 도구 재시도 상한	tool_retry_count	상한 초과 시 도구 포기, 루프 진입 방지

검색, 데이터베이스, 외부 서비스 같은 외부 API 도구는 별도로 기록해야 합니다. 그렇지 않으면 도구 호출이 비용 블랙박스가 됩니다.

도구 실패 분류

도구 실패는 복구 가능과 복구 불가능으로 나눕니다.

실패 유형	전형적 오류	처리 전략	비용 영향
복구 가능한 실패	네트워크 timeout, 503 Service Unavailable, 429 Rate Limit	exponential backoff 와 retry-after 로 자동 재시도	각 재시도에서 전체 컨텍스트 소비
복구 불가능한 실패	403 Permission Denied, 400 Bad Request, 없는 도구	재시도하지 않고 오류를 주입해 모델이 판단	재시도 없음, 무효 비용 방지

핵심은 “외부 원인의 일시적 실패만 재시도하고, 내부 설정 오류는 재시도하지 않는다”입니다.

Circuit breaker

연속 실패 N 회 후 도구를 비활성화해 “빈 응답 1,500 회 재시도”를 막습니다.

def circuit_breaker_tool(tool_name, consecutive_failures, threshold=5):
    if consecutive_failures >= threshold:
        return "disable_tool"  # 도구 비활성화
    return "continue"

circuit breaker 상태는 로그에 남깁니다. “왜 도구가 비활성화됐는지”를 추적하기 위해서입니다. 차단 후에는 사람의 개입이나 자동 복구 체크를 기다리고, 불안정한 도구를 반복 호출하지 않습니다.

도구 호출의 기본은 도구 호출에서 다루었습니다. 이 글은 per-tool budget, timeout, 재시도 상한을 확장합니다.

Prompt Caching 설계: 안정 prefix, 변수 위치, 1024 token 기준

Prompt Caching 은 안정적인 prompt prefix 의 입력 token 을 최적화하는 기능입니다. 비즈니스 결과 캐시가 아닙니다. 같은 prompt prefix 를 최근 처리한 서버로 요청을 라우팅해 지연 시간과 입력 token 비용을 줄입니다.

Prompt Caching 은 결과 캐시가 아니다

Prompt Caching 이 캐시하는 것은 안정적인 prompt prefix 이며, 비즈니스 결과가 아닙니다. 차이는 중요합니다.

• Prompt Caching: system prompt, tool schema 같은 안정적인 prompt prefix 를 캐시합니다. 히트하면 입력 token 을 절약하지만 추론은 다시 실행됩니다.
• 비즈니스 결과 캐시: 도구 호출 결과나 데이터베이스 조회 같은 완전한 출력을 캐시합니다. 히트하면 모델을 호출하지 않고 바로 반환합니다.

목적이 다릅니다. Prompt Caching 은 입력 token 비용을 최적화하고, 비즈니스 결과 캐시는 전체 호출 비용을 최적화합니다. 둘은 함께 쓸 수 있습니다. 안정적인 prefix 는 Prompt Caching, 자주 쓰는 도구 결과는 비즈니스 캐시에 둡니다.

구조 요구사항

핵심은 안정적인 prefix 와 실행 시 변수를 분리하는 것입니다.

콘텐츠 유형	위치	캐시 히트 가능성	대표 내용
안정 prefix(cache 에 들어감)	Prompt 앞부분	높음	System prompt, Tool schema, Policy 문서, Few-shot 예시
실행 시 변수(cache 에 넣지 않음)	Prompt 뒷부분	낮음	User input, File fragments, Runtime state(현재 대화 턴, 임시 변수)

설계 단계입니다.

1. System prompt, Tool schema, Policy 를 앞에 둡니다: 여러 호출에서 안정적이므로 캐시에 맞기 쉽습니다.
2. User input, File fragments, Runtime state 를 뒤에 둡니다: 매번 바뀌므로 안정 prefix 에 들어가면 안 됩니다.
3. Cache hit rate 를 모니터링합니다: cachedTokens 와 총 입력 token 을 기록하고 히트율을 계산합니다. 40% 초과면 건강하고, 20% 미만이면 prompt 구조를 점검합니다.

기준과 효과

Prompt Caching 의 자동 활성화 기준과 효과는 변할 수 있으므로 공개 전에 공식 문서를 다시 확인합니다.

• 기준: 1024 tokens 이상에서 자동 활성화(공개 전 재확인).
• 효과: 히트 시 비용과 지연 시간을 낮출 수 있음(정확한 비율은 재확인).
• 히트 확인: usage.prompt_tokens_details.cached_tokens 필드.

Prompt Caching 의 지원 모델, 기준, 할인율은 바뀔 수 있습니다. 공개 전 공식 pricing 페이지에서 확인해야 합니다. 안정적인 설계 원칙은 “정적 내용은 앞에, 변동 내용은 뒤에”입니다.

실패 재시도 차단: 멱등성, 상태 저장, 남은 예산 확인

재시도는 비용 폭주의 가장 큰 원인 중 하나입니다. 백그라운드 report Agent 가 불안정한 도구에 걸리고 매번 전체 컨텍스트를 다시 보내면, 1,500 번 재시도 후 비용은 정상 경로에서 크게 벗어납니다.

재시도 전에 예산 확인하기

재시도 후가 아니라 재시도 전에 남은 예산을 확인합니다.

def should_retry(error_type, budget_remaining, retry_cost_estimate):
    # 오류 분류
    if error_type in ["403", "400", "tool_not_exist"]:
        return False  # 복구 불가능 오류, 재시도하지 않음

    # 예산 확인
    if budget_remaining < retry_cost_estimate:
        return False  # 예산 초과, 재시도하지 않음

    return True  # 재시도 가능

예산 확인은 재시도 로직보다 앞에 있어야 합니다. 그래야 빈 응답을 1,500 번 재시도해 하루 예산을 쓰는 일을 피할 수 있습니다.

멱등성

재시도는 이메일 발송이나 결제 같은 부작용을 반복 실행하면 안 됩니다.

• 도구 호출에는 requestId 같은 멱등 ID 를 사용합니다. 외부 API 가 같은 ID 를 받으면 작업을 다시 처리하지 않고 캐시된 결과를 반환해야 합니다.
• 멱등 ID 는 비용 로그에 기록해 중복 호출을 판단할 수 있게 합니다.

멱등 설계의 핵심은 “같은 작업이 두 번 비용을 쓰지 않게 하는 것”입니다. 없으면 재시도가 비용과 부작용을 모두 증폭합니다.

상태 저장(Checkpoint)

긴 작업은 실패 후 전체 workflow 를 다시 실행하지 않아야 합니다.

• 중요한 노드에 도달하면 완료된 단계, 현재 상태, 컨텍스트 요약을 포함해 checkpoint 를 저장합니다.
• 실패 복구 시 처음부터가 아니라 checkpoint 에서 이어갑니다.
• Checkpoint 는 영속 저장소에 씁니다. 메모리에만 두면 부족합니다.

checkpoint 와 thread state 설계는 LangGraph Agent 아키텍처에서 다루었습니다.

재시도 전략

오류 유형별로 재시도 전략을 달리해야 합니다.

오류 유형	전형적 오류	재시도 전략	비용 영향
네트워크 timeout	10 초 응답 없음	exponential backoff + retry-after, 최대 3 회	각 재시도에서 전체 컨텍스트 소비
503/429	Service Unavailable, Rate Limit	rate limit window + retry-after 대기, 최대 3 회	대기는 token 을 쓰지 않지만 재시도는 사용
403/400	Permission Denied, Bad Request	재시도하지 않고 오류를 주입해 모델 판단	재시도 없음, 무효 비용 방지

핵심은 “복구 가능한 오류만 재시도”하는 것입니다. 무효 요청을 모델에 반복해서 보내면 안 됩니다.

Circuit breaker

연속 실패 N 회 후 재시도를 멈추고 개입을 기다립니다.

def circuit_breaker(consecutive_failures, threshold=5):
    if consecutive_failures >= threshold:
        return "stop_retry"  # 재시도 중지
    return "continue"

circuit breaker 판단은 로그에 남겨야 합니다. 왜 재시도를 멈췄는지 설명하기 위해서입니다. 차단 후에는 사람의 개입이나 예산 회복을 기다리고, 불안정한 도구나 모델을 반복 호출하지 않습니다.

비용 로그와 알림: 어떤 필드와 임계값을 둘까

비용 관측성은 비용 제어의 전제입니다. 로그 필드가 부족하면 문제 위치를 찾을 수 없습니다.

OpenTelemetry trace span attributes

비용 로그는 세 계층 span 으로 설계합니다.

Agent run span(최상위):

필드명	용도	타입	기록해야 하는 이유
runId	특정 실행 식별	string	같은 workflow 의 여러 실행 구분
tenantId	tenant 식별	string	멀티테넌트 비용 분배
userId	사용자 식별	string	사용자별 비용 추세 확인
workflowName	workflow 식별	string	workflow 유형별 비용 확인
totalCost	총 비용 추정	float	실시간 비용 누적
budgetRemaining	남은 예산	float	circuit breaker 판단 근거
totalRetries	총 재시도 횟수	integer	재시도 증폭 확인

Model call span(자식 span):

필드명	용도	타입	기록해야 하는 이유
model	모델 식별	string	모델 라우팅이 적절한지 판단
pricingVersion	가격 버전	string	비용 공식을 하드코딩하지 않기 위함
inputTokens	입력 token 수	integer	입력 비용 계산
outputTokens	출력 token 수	integer	출력 비용 별도 기록
cachedTokens	캐시 hit token 수	integer	캐시 절감 계산
costEstimate	이번 호출 비용 추정	float	실시간 비용 누적
latencyMs	호출 지연 시간	integer	Batch/Flex 적합성 판단

Tool call span(자식 span):

필드명	용도	타입	기록해야 하는 이유
toolName	도구 식별	string	도구 호출 overhead 식별
toolBudget	도구 예산 상한	float	circuit breaker 판단 근거
toolTimeout	도구 timeout	integer	timeout 실패 분류
retryCount	재시도 횟수	integer	재시도 증폭 측정
errorType	오류 유형	string	복구 가능/불가능 분리

total_cost 만 기록하지 마세요. 차원별로 나눠야 합니다. 이런 필드가 없으면 청구 이상은 “초과”만 말해줄 뿐, 어떤 사용자, 도구, 재시도 경로가 원인인지 알려주지 않습니다.

로그, 알림, 실패 복구의 전체 설계는 Agent 모니터링과 복구에서 다루었습니다. 이 글은 비용 필드와 예산 객체를 보완합니다.

알림 임계값

알림 임계값은 차원별로 설정합니다.

알림 차원	알림 임계값	알림 방식	트리거 동작
전체 예산 소비	70%, 90%, 100%	Slack/이메일 알림	70% 알림, 90% 강등, 100% 차단
단일 user/tenant 소비	평균의 3 배 초과	Slack/이메일 알림	비정상 호출 확인
단일 모델 실패율	> 5%	Dashboard 알림	모델 라우팅 또는 서비스 상태 확인
단일 도구 재시도 횟수	> 임계값	Dashboard 알림	도구 안정성 확인
캐시 히트율	< 기대값	Dashboard 알림	prompt 구조 확인

알림 임계값은 비용 로직에 있어야 자동으로 알림과 circuit breaker 를 발동할 수 있습니다.

강등 전략

알림 후 강등 경로는 다음과 같습니다.

강등 경로	강등 방식	적합한 상황	비용 영향
모델 강등	큰 모델 -> 작은 모델	단일 모델 실패율이 높음	비용 감소, 품질 저하 가능
경로 강등	Realtime API -> Batch API -> Flex Processing	전체 예산이 너무 빨리 소진됨	지연 증가, 비용 감소
기능 강등	비핵심 도구 호출 끄기	단일 도구 재시도가 많음	도구 호출 overhead 감소
사용자 강등	rate limit, queue, “나중에 다시 시도” 안내	단일 사용자 소비가 비정상	한 사용자가 예산을 태우는 것 방지

강등 전략은 예산 로직 안에 있어야 합니다. 알림이 발생하면 사람이 개입한 뒤가 아니라 시스템이 자동으로 강등해야 합니다.

다음 단계

Agent 비용 제어는 모니터링, 도구 호출, context engineering 과 함께 봐야 합니다.

• 게시됨: Agent 모니터링과 복구: 로그 필드, 알림 설정, 실패 복구. 이 글은 비용 필드와 예산 객체를 보완합니다.
• 게시됨: LangGraph Agent 아키텍처: checkpoint, thread state, 긴 작업 복구.
• 게시됨: 도구 호출: 도구 호출 기초. 이 글은 per-tool budget, timeout, 재시도 상한을 확장합니다.
• 같은 시리즈: context engineering: 안정 prefix 와 캐시 히트, 어떤 컨텍스트를 안정 prefix 에 넣고 어떤 것을 실행 시 변수로 둘지.
• 같은 시리즈: Human-in-the-Loop: 승인 대기, 거절, timeout 예산 분기와 승인이 비용 및 재시도 경로에 주는 영향.

먼저 세션 단위 방어선부터 시작합니다. per-session cost limit 을 설정하고 단일 세션이 예산을 넘으면 자동 종료합니다. 폭주한 작업 하나가 하루 예산을 태우는 것을 막는 가장 빠른 첫 단계입니다. 이후 예산 객체 계층화, 모델 라우팅, 도구 호출 예산, Prompt Caching, 재시도 차단, 비용 로그로 확장합니다.