문제점: 왜 토큰 급증은 눈에 띄지 않고 숨어 있는가

대부분의 AI 팀은 에이전트 실행을 이진적 수준(binary level)에서 모니터링합니다: 성공했거나 실패했거나. 에이전트가 200 OK를 받으면 작업이 성공한 것으로 간주합니다. 하지만 표준 모니터링이 놓치는 실패의 범주가 존재합니다: 실행은 성공했지만 그 과정에서 평소 토큰 예산의 10배를 소비하는 경우입니다.

이런 현상은 에이전트가 루프(loop)에 빠질 때 가장 자주 발생합니다. 도구를 호출하고, 결과를 확인하고, 개선을 위해 도구를 다시 호출하고, 다시 확인하는 과정을 반복합니다. 각 반복(iteration)은 토큰 수에 더해집니다. 20번의 반복이 지나면, 0.02달러가 들어야 할 실행 비용이 2.00달러가 됩니다. 그리고 여전히 200 OK를 반환합니다.

월간 청구서에서 급증한 비용을 확인했을 때는 이미 수천 달러를 잃은 후입니다.

해결책은 루프를 금지하는 것이 아닙니다. 때때로 에이전트는 정답을 얻기 위해 반복이 필요합니다. 해결책은 의미 있는 토큰 이상(anomaly)을 비용이 많이 들기 전에, 즉 연쇄 반응이 일어나기 전 첫 번째 실행 단계에서 탐지하는 것입니다.

수학적 원리: 백분위수 기준선(Percentile Baselines)과 Z-점수(Z-Scores)

견고한 이상 탐지기(anomaly detector)에는 두 가지 요소가 필요합니다: "정상"을 포착하는 기준선(baseline)과 실행이 기준선에서 크게 벗어났을 때를 탐지하는 방법입니다.

파트 1: 백분위수 기준선 구축하기

평균(mean)을 사용하지 마세요. 이동 평균(running average)은 몇 번의 값비싼 실행에 의해 너무 쉽게 상향 편향될 수 있으며, 전형적인 동작의 형태를 알려주지 못합니다.

대신, 이동 창(rolling window, 일반적으로 30일 또는 최근 100회 실행 중 더 큰 값) 동안의 토큰 사용 백분위수(percentiles)를 추적하세요:

p50 = 중앙값(median) 토큰 수
p95 = 95번째 백분위수(95th percentile) 토큰 수
p99 = 99번째 백분위수(99th percentile) 토큰 수

왜 백분위수인가요? 이상치(outliers)에 강건(robust)하기 때문입니다. 에이전트가 보통 500개의 토큰을 사용하는데 한 번의 실행에서 50,000개를 사용한다면(우리가 잡으려는 이상 현상), 중앙값과 p95는 전형적인 동작 범위 내에 머물러 있습니다. 반면 평균은 크게 변할 것입니다.

파트 2: Z > 2.5일 때 토큰 급증 플래그 표시

기준선(특히 p95)이 확보되면, 각 새로운 실행을 확인합니다:

z_score = (이번 실행의 토큰 수 - p95) / 표준편차(standard_deviation)

만약 z_score > 2.5라면, 플래그(flag)를 표시합니다. (2.5는 임계값(threshold)이며, 오탐(false-alarm) 허용 범위에 따라 조정하십시오. 값이 높을수록 알람은 줄어들지만 실제 급증(spike)을 놓칠 위험이 있고, 값이 낮을수록 오탐은 늘어나지만 예외 케이스를 더 일찍 포착할 수 있습니다.)

왜 2가 아니라 2.5인가요? 2.0 표준편차(standard deviations)에서는 정상적인 실행의 약 2.3%가 플래그로 표시될 것으로 예상됩니다(오탐). 2.5에서는 약 0.6%입니다. 비용 거버넌스(cost governance) 측면에서 오탐은 비용이 적게 들지만(번거로울 뿐, 단순히 조사하면 됩니다), 실제 급증을 놓치는 것은 비용 손실로 이어집니다.

코드 스케치 (The Code Sketch)

import numpy as np
from collections import deque

...

윈도우(window) 내의 모든 실행 토큰 수를 기록합니다. 새로운 실행이 도착하면, 윈도우로부터 p95와 표준편차(standard deviation)를 계산하고, z_score를 산출하여 임계값을 초과하면 플래그를 표시합니다. 그 후 새로운 실행을 윈도우에 추가합니다.

지연 시간(Latency)과 상관관계를 분석해야 하는 이유

토큰 이상 징후(anomalies)는 종종 지연 시간(latency) 급증과 함께 나타납니다. 만약 어떤 실행이 평소보다 10배 많은 토큰을 사용했으면서 동시에 완료하는 데 5배 더 오래 걸렸다면, 이는 거의 확실하게 루프(loop)에 빠졌거나 재시도 로직(retry logic)에 갇힌 상태입니다.

두 번째 신호를 추가하십시오:

latency_z = (latency_this_run - p95_latency) / std_latency
anomaly = (token_z > 2.5) and (latency_z > 2.0)  # 두 신호 모두 급증해야 함

두 신호가 동시에 급증하도록 요구하는 것은 더 보수적인 방식(더 적은 오탐)이지만, 토큰을 과다하게 사용하면서 동시에 엄청난 시간이 걸린 에이전트와 같은 진짜 원인을 잡아낼 수 있습니다. 그것이 바로 루프입니다.

빠른 이상 징후(예: 토큰 사용량은 많지만 지연 시간은 정상인 상태에서, 에이전트가 매우 빠른 속도로 50번의 도구 호출(tool calls)을 수행한 경우)까지 잡아내고 싶다면, 세 번째 신호로 **도구 호출 횟수(tool-call count)**를 추적하십시오:

tool_calls_z = (tool_calls_this_run - p95_tool_calls) / std_tool_calls
anomaly = (token_z > 2.5) or (tool_calls_z > 2.5)  # 신호 중 하나만 발생해도 감지

이제 느린 루프(토큰 + 지연 시간 급증)와 빠른 루프(토큰 + 도구 호출 횟수 급증)를 모두 잡아낼 수 있습니다.

종합하기: 알림(The Alert)

이상 징후가 감지되면 즉시 표면화하십시오:

• 어떤 에이전트인지 (Which agent): 이름과 프레임워크.
• 무엇이 급증했는지 (What spiked): 토큰 (500개에서 12,000개로), 지연 시간 (Latency, 2초에서 15초로), 도구 호출 (Tool calls, 3회에서 47회로).
• 기준점 (The baseline): "정상적인 p95는 600 토큰입니다. 이번 실행은 20배 더 높았습니다."
• 비용 (The cost): 토큰이 10배 급증했다면 비용도 10배 급증했습니다. 실질적인 체감을 위해 달러 금액을 표시하십시오.
• 조치 (The action): 어떤 도구 호출이 루프를 시작했는지 확인할 수 있도록 해당 실행의 전체 실행 추적 (Execution trace) 링크를 제공하십시오.

이것이 중요한 이유 (Why This Matters)

폭주하는 루프를 첫 번째 실행 단계에서 감지하는 것(비용: $0.50, 몇 초 내에 알림 수신)과 월간 청구서에서 감지하는 것(비용: $5,000, 이미 피해 발생)의 차이는 바로 이상 탐지기 (Anomaly detector)에 있습니다.

수식은 간단합니다. 하지만 그 영향은 막대합니다.

추가 읽기 (Further reading): AI 에이전트를 구축하고 있다면, 첫날부터 토큰 기준점 (Token baseline)을 설정하십시오. 평균 (Average)이 아닌 백분위수 (Percentiles)를 사용하십시오. 그리고 토큰 급증을 지연 시간 (Latency) 및 도구 호출 횟수 (Tool-call count)와 상관 분석하십시오. 여러 신호를 결합하면 오탐 (False alarms)을 줄이고 실제 문제를 더 빠르게 잡아낼 수 있습니다.