왜 4,200달러가 사라졌을까? 숨겨진 성공적인 재시도들.

해당 장애는 서비스 중단(outage)이 아니었습니다. 에이전트(agent)는 건강해 보였습니다. 작업은 완료되었고, 트레이스(traces)는 녹색이었으며, 주간 대시보드에는 96.8%의 성공률이 표시되었습니다. 비용 누수는 성공적인 경로(successful path) 내에 존재했습니다. 하나의 도구 노드(tool node)가 결정론적 검증 실패(deterministic validation failures)에 대해 다섯 번째 시도까지 재시도(retry)를 반복했고, 그 후 대형 모델(larger model)이 인자(arguments)를 다시 작성하면서 보통 복구되었습니다. 모든 사고는 status=ok로 종료되었기 때문에, 일반적인 실패 알림(failure alerts)은 조용히 유지되는 동안 청구 금액은 계속 올라갔습니다.

OpenAI, Anthropic 또는 OpenRouter의 트래픽 증가 없이 에이전트 비용이 급증할 때, 제가 이제 agent_trace_spans.jsonl, retry_policy.py, 그리고 cost_guard.yaml에서 가장 먼저 검색(grep)하는 형태는 다음과 같습니다.

node=tool_argument_repair
attempts=5
final_status=ok
...

함정은 대부분의 대시보드가 최종 상태(final status)를 기준으로 그룹화한다는 점입니다. 만약 체인(chain)이 다섯 번째 시도에서 성공한다면, 그것은 성공으로 집계됩니다. 비용 시스템은 상관하지 않습니다. 첫 번째, 두 번째, 세 번째, 네 번째, 그리고 다섯 번째 시도에 대해 모두 비용을 청구했습니다.

탐지 쿼리 (The detection query)

지난 7일에서 30일 동안의 트레이스(traces)를 내보내고, 최종 결과가 아닌 원래의 에러 클래스(error class)별로 그룹화하십시오.

select
  node_name,
  first_error_class,
...

그 다음 에러를 두 개의 버킷(bucket)으로 나눕니다:

에러 클래스 (Error class)	재시도 정책 (Retry policy)	이유 (Why)
provider_429	backoff를 이용한 재시도 (retry with backoff)	보통 일시적임 (transient).
...

비용이 많이 발생하는 클래스는 최종 성공률(final success rate)은 높으면서 재시도 횟수(retry count)도 높은 클래스입니다. 이는 에이전트가 결국 작동은 하지만, 동일한 의미론적 실수(semantic mistake)에 대해 여러 번 비용을 지불한 후에야 작동한다는 것을 의미합니다.

보통 승리하는 해결책 (The fix that usually wins)

대형 모델(large model)이 모든 잘못된 형식의 인자(malformed argument)를 처음부터 다시 수정하게 만들지 마십시오. 두 번째 모델 호출 전에 로컬 수정 단계(local repair stage)를 추가하십시오.

def classify_error(error):
    if error.kind in {"rate_limit", "provider_5xx", "network_timeout"}:
        return "transient"
...

스키마 오류 (schema failures)의 경우, 작은 로컬 모델 (local model)이나 심지어 결정론적 강제 변환 함수 (deterministic coercion function)가 또 다른 프런티어 모델 (frontier model)을 호출하는 것보다 더 나은 성능을 보이는 경우가 많습니다. 핵심은 50~100개의 예시로 구성된 평가 (eval)를 통해 복구 품질 (repair quality)을 측정하는 것입니다. 만약 로컬 복구가 허용 오차 범위 내에 있다면, 비용이 많이 드는 모델을 기본 경로 (default path)가 아닌 예외 경로 (exception path)로 만드세요.

더 많은 팀이 가졌으면 하는 알림 (alert)

성공률 (success rate) 옆에 지표를 하나 더 추가하세요:

cost_per_successful_chain = total_chain_cost / successful_chains

그런 다음 노드 (node)별 주간 변동 사항에 대해 알림을 설정하세요:

if cost_per_successful_chain(node) > 1.35 * trailing_4_week_median(node):
    page("성공 비용이 상승했습니다")

이 알림은 조용한 실패 모드 (silent failure mode)를 포착합니다. 즉, 제품은 여전히 작동하고 사용자들은 여전히 답변을 받지만, 각 답변의 비용이 지난주보다 조용히 2배에서 10배 더 많이 드는 상황을 잡아냅니다.

이 패턴을 놓치기 쉬운 이유

엔지니어는 빨간색 추적 (red traces)을 조사하고, 재무팀은 송장 (invoices)을 확인합니다. 비용 누수는 그 사이에 존재합니다. 운영 측면에서는 녹색(정상)이지만, 재무 측면에서는 빨간색(비정상)인 상태입니다.

에이전트 (agent) 비용을 감사할 때는 성공적인 재시도 (successful retries)부터 시작하세요. 실패한 호출 (failed calls)은 명확하게 드러납니다. 비용이 많이 드는 버그는 바로 성공적인 재시도 속에 숨어 있습니다.