AI 에이전트를 프로덕션(production) 환경에 배포하기 전에, 에이전트가 조용히 고장 났을 때 어떤 일이 발생하는지 알아야 합니다. 대부분의 팀은 고객의 불만이 접수될 때까지 이 사실을 알지 못합니다.

그 이유는 구조적인 문제입니다. 에이전트가 HTTP 200을 반환하고, 로그에는 성공으로 표시되며, 테스트를 통과하더라도 에이전트가 실제로 아무것도 수행하지 않았을 수 있습니다. 소비된 토큰(tokens)도 없고, 출력(output)도 없으며, 취해진 조치(action)도 없습니다. 요약을 요청했는데 빈 문자열(empty string)을 반환하거나, 이메일 분류를 요청했는데 null을 반환하는 경우입니다. 호출은 성공했지만, 에이전트는 실패한 것입니다.

이는 에러(errors)와는 다릅니다. 에러는 소란스럽습니다. 모니터링 시스템이 이를 포착하고, 알림(alerting)이 울리며, 바로 수정할 수 있습니다. 반면 조용한 실패(Silent failures)는 더 조용하며, 숨어 있기 때문에 훨씬 더 비용이 많이 듭니다.

당신에게 필요한 것은 체크리스트입니다. 즉, 실제로 중요한 실패를 포착할 수 있도록 프로덕션 이전에 모니터링(instrument)해야 할 항목들의 집합입니다. 모든 지표(metric)가 아니라, 고장 난 에이전트를 예측할 수 있는 지표들 말입니다.

주의 깊게 살펴봐야 할 6가지 실패 모드

1. 출력 토큰(Zero output tokens)이 0인 경우

입력 토큰(input tokens)은 소비했지만 출력 토큰(output tokens)을 전혀 생성하지 않은 LLM 호출은 위험 신호입니다. 모델이 호출되었고 실행되었지만, 아무것도 생성하지 않은 것입니다. 길기 제한(length limit)에 걸렸을 수도 있고, 생성 도중 루프(loop)에 빠져 타임아웃(timeout)이 발생했을 수도 있으며, 프롬프트(prompt)를 완전히 거부했을 수도 있습니다.

확인 방법은 간단합니다: output_tokens가 0이고, input_tokens가 0보다 크며, 상태(status)가 성공(success)인 경우입니다. 한 번 발생한다면 아마 노이즈(noise)일 것입니다. 하지만 두 번 연속으로 발생한다면 무언가 잘못된 것입니다.

이를 에이전트별, 모델별, 일별로 추적하세요. 수요일에 에이전트의 zero-output 비율이 5%를 넘는다면, 고객이 알기 전에 이미 문제가 발생한 것입니다.

2. 출력 요약이 비어 있거나 명백히 틀린 경우

에이전트가 텍스트를 반환하지만, 그 텍스트가 비어 있거나 "[No response]" 또는 "ERROR: could not generate output"와 같은 환각(hallucinated)된 자리 표시자(placeholder)인 경우입니다. 에이전트가 실행에 실패한 것이 아니라, 실행은 되었으나 쓰레기 값(garbage)을 생성한 것입니다.

출력값의 짧은 요약(처음 50~100자) 또는 에이전트가 구조화된 데이터(structured data)를 반환하는 경우 핵심 필드를 캡처하세요. 그런 다음 알림(alert)을 설정하십시오. 만약 2회 연속 실행 결과가 공백이거나 명백히 비어 있는 요약으로 생성된다면, 담당자에게 호출(page)을 보냅니다.

이것은 법칙이 아니라 휴리스틱(heuristic)입니다. 하지만 이는 고객의 지원 대기열(support queue)이 막혀서 새벽 3시에 문제를 발견하느냐, 아니면 오후 스탠드업 미팅 중에 발견하느냐의 차이를 만듭니다.

3. 지연 시간 급증 (모델 타임아웃 또는 루프 발생)

평소 2초가 걸리던 에이전트 호출이 60초가 걸린다면 이는 하나의 증상입니다. 보통 이는 두 가지 중 하나를 의미합니다: 모델이 재시도 루프(retry loop)에 빠졌거나, 토큰(token) 생성 중에 멈춰서 타임아웃(timeout)에 걸린 것입니다.

에이전트별로 p50 및 p95 지연 시간(latency)을 추적하세요. 만약 p95가 갑자기 10배로 뛴다면, 그것은 단순한 노이즈가 아닙니다. 무언가 변했다는 신호입니다.

4. 토큰 소비량이 예상보다 훨씬 높음

평소 실행당 500 토큰을 사용하는 에이전트를 배포했습니다. 화요일에 동일한 입력, 동일한 쿼리, 동일한 모델을 사용함에도 불구하고, 같은 에이전트가 실행당 15,000 토큰을 소비하고 있습니다. 토큰 사용량이 폭발하고 있는 것입니다.

이는 대개 에이전트가 루프에 빠졌거나, 단일 실행 내에서 모델을 여러 번 호출하고 있거나, 자신의 출력을 다시 자신에게 입력으로 넣고 있거나, 혹은 프롬프트(prompt)에 토큰 집약적인 생성을 강제하는 적대적 콘텐츠(adversarial content)가 주입되었음을 의미합니다.

실행당 입력 및 출력 토큰을 추적하세요. 상한선(ceiling)을 설정하십시오: 단일 실행이 해당 에이전트의 정상적인 토큰 사용량 중 90 백분위수(90th percentile)의 10배를 초과한다면, 이는 조사해야 할 신호입니다.

5. 성공률이 기준치(baseline) 아래로 하락

당신은 에이전트의 평소 성공률이 얼마인지 알고 있습니다. 97%일 수도 있고, 87%일 수도 있습니다. 무엇이든 그것이 당신의 기준치(baseline)입니다. 만약 그것이 70%로 떨어진다면, 문제가 발생한 것입니다.

대부분의 모니터링 도구는 에러(error), 예외(exception), 500 에러, 타임아웃을 측정합니다. 하지만 에이전트는 모든 호출이 200(성공)을 반환하여 매우 높은 "성공"률을 보이면서도, 호출의 절반이 빈 출력을 생성하여 "유용"한 비율은 낮을 수 있습니다. 이 두 가지를 모두 추적하세요.

성공률 (Success rate)은 전체 호출 횟수 대비 비어 있지 않고 환각 (hallucination)이 없는 결과를 반환한 호출의 비율로 정의해야 합니다. 만약 이 수치가 전일 대비 10포인트 이상 하락한다면 알림을 설정하세요.

6. 실행당 비용 (Cost per run)의 급증

지난주에 에이전트의 실행당 비용이 $0.02였다면, 이번 주에는 입력 분포와 모델이 동일함에도 불구하고 실행당 $0.50가 되고 있습니다. 무언가가 토큰 (token) 사용량을 부풀리고 있는 것입니다.

대개 이는 다시 루프 (loop) 문제로, 에이전트가 한 번의 실행당 모델을 여러 번 호출하거나, 더 비싼 모델을 사용하거나, 프롬프트 (prompt)가 비대해졌을 때 발생합니다. 하지만 수치를 확인하기 전까지는 알 수 없습니다.

입력 토큰 (input tokens)과 출력 토큰 (output tokens)을 더한 값에 모델 가격을 곱하여 실행당 계산 비용을 산출하세요. 실행당 비용이 5배 급증한다면, 그것이 바로 위험 신호입니다.

이러한 점검을 위한 계측 (instrumentation) 방법

이를 포착하기 위해 거창한 플랫폼이 필요한 것은 아닙니다. 다음이 필요합니다:

실행당 다음 필드들을 캡처하세요: 상태 (status: 성공, 에러, 타임아웃), 입력 토큰 (input_tokens) 및 출력 토큰 (output_tokens), 지연 시간 (latency_ms), 출력에 대한 짧은 요약 (처음 100자, 또는 비어 있을 경우 null), 비용 (cost_usd: 토큰에 모델 가격을 곱하여 계산), 그리고 타임스탬프 (timestamp).

데이터베이스, 로그 집계기 (log aggregate), 모니터링 도구 등 어디든 저장하세요. 시작 단계에서는 5분마다 업데이트되는 CSV 파일만으로도 충분합니다.

네 가지 알림을 설정하세요: 지난 1시간 동안의 무출력 비율 (zero-output rate) 5% 초과, 두 번 연속된 실행에서 요약이 공백인 경우, p95 지연 시간이 기준치(baseline)의 10배를 초과하는 경우, 그리고 실행당 비용이 90 백분위수 (90th percentile)의 5배를 초과하는 경우입니다.

매일 확인하거나, 출시 주간 동안 모니터링할 수 있도록 대시보드 (dashboard)를 구축하세요.

그게 전부입니다. 머신러닝 (ML)도, 이상 탐지 (anomaly detection)도, 정교한 알림 시스템도 필요하지 않습니다. 필요한 것은 체크리스트와 고객의 에러 예산 (error budget)이 소진되기 전에 이를 확인하는 규율입니다.

프로덕션 적용 전 이것이 중요한 이유

침묵하는 실패 (Silent failures)는 초기에 수정하면 비용이 적게 들지만, 늦게 수정하면 비용이 많이 듭니다. 프로덕션에 적용하기 전에 무출력 루프를 발견하면 프롬프트를 수정하고 다시 배포하면 됩니다. 하지만 고객이 데이터를 처리할 수 없어 새벽 2시에 이를 발견하게 된다면, 당신은 화재 진압 모드 (firefighting mode)에 돌입하게 될 것입니다.

그 차이는 관측 가능성 (Observability)에 있습니다. 단순히 에이전트가 실행되었다는 것을 아는 것이 아니라, 실행되었을 때 무엇을 했는지 아는 것입니다.

배포하기 전에 이 체크리스트를 훑어보세요. 이 여섯 가지 신호 (signals)를 계측 (instrument) 하세요. 출시하는 날에 이를 확인하세요. 그러면 미처 몰랐던 문제들을 발견하게 될 것이며, 다음 문제들이 장애 (incidents)로 이어지기 전에 찾아낼 수 있다는 사실을 알기에 더 편안하게 잠들 수 있을 것입니다.

조용히 실패하는 에이전트는 당신이 계측한 에이전트가 아니라, 당신이 살펴보지 않고 배포한 에이전트입니다.