AI 에이전트가 HTTP 200을 반환해도 실패할 수 있는 이유

HTTP 200을 반환하는 API는 요청이 성공적으로 완료되었음을 알려줍니다. 하지만 AI 에이전트가 실제로 의도한 작업을 수행했는지 여부는 알려주지 않습니다.

에이전트들이 실제 워크플로우를 처리하기 시작하면서 이 구분이 중요해집니다.

에이전트는 도구를 성공적으로 호출하고, 유효한 응답을 받고, 답변을 반환할 수 있습니다. 인프라 측면에서는 모든 것이 정상으로 보입니다.

하지만 에이전트가 잘못된 도구를 선택했거나, 작업을 완료하지 못했거나, 애플리케이션의 검증 규칙을 통과하지 못하는 출력을 생성했을 수도 있습니다.

기존의 가용성(uptime) 모니터링으로는 이러한 실패를 반드시 포착할 수 없습니다.

가용성만 측정하는 것의 문제점

구조화된 문서를 검증하는 역할을 맡은 에이전트를 생각해 봅시다.

배포 전에는 대부분의 문서가 유효성 검사를 통과합니다. 하지만 모델이나 프롬프트 업데이트 후, 형식이 잘못된(malformed) 출력이 더 자주 발생하게 됩니다.

API는 계속 성공적으로 응답하지만, 애플리케이션 수준의 신뢰성은 저하됩니다.

이러한 퇴행(regression)을 식별하려면 API 요청이 성공했는지 여부보다 더 많은 것을 기록해야 합니다.

최소한 유용한 신호에는 다음이 포함되어야 합니다:

• 애플리케이션 정의 기준에 따라 작업이 성공했는지 또는 실패했는지 여부
• 어떤 유형의 실패가 발생했는지
• 어떤 모델이나 프롬프트 버전이 관련되었는지
• 지연 시간(Latency), 토큰 사용량, 재시도 횟수
• 변경 후 시스템이 복구되었는지 여부

애플리케이션은 이러한 결과(outcome)를 제공해야 합니다. 모니터링 시스템은 HTTP 상태 코드만으로는 작업의 정확성을 신뢰성 있게 추론할 수 없습니다.

재현 가능한 예시

저는 이 문제를 탐구하는 Apache-2.0 오픈 소스 프로젝트인 ReliaMesh를 개발해 왔습니다.

이 프로젝트는 구조화된 신뢰성 이벤트(structured reliability events)를 받아 결정론적 감지 규칙(deterministic detection rules)을 사용하여 저하 및 복구를 식별합니다.

저장소에는 세 단계로 구성된 합성 예시가 포함되어 있습니다:

1. Baseline: 50개의 성공적인 검증 이벤트.
2. Regression: 다른 모델-버전 레이블과 관련된 50개의 검증 실패.
3. Recovery: 이후의 100개 성공 이벤트.

이 예시는 실패율 회귀(failure-rate regression) 사고가 발생하고 나중에 해결되는 과정을 보여줍니다.

설치 지침과 synthetic regression example를 사용하여 로컬에서 재현할 수 있습니다.

유료 API 계정이나 블록체인 연결은 필요하지 않습니다.

탐지 작동 방식

ReliaMesh는 프롬프트와 응답을 다른 LLM에 보내 평가하기보다는, 명시적으로 보고된 결과(outcomes)를 사용하여 작동합니다.

실패율 회귀의 경우, 인접한 50개 이벤트 관측 창(observation windows)을 비교합니다.

회귀 신호는 최소 15 퍼센트 포인트 이상의 실패율 증가와 함께 해당 Wilson 신뢰 구간(confidence intervals) 간의 분리를 요구합니다.

이 시스템은 또한 높은 절대 실패율, 지연 시간(latency), 토큰 사용량, 재시도(retries)에 대한 규칙을 가지고 있습니다.

이는 탐지기가 무적이라는 의미는 아닙니다. 애플리케이션이 보고하는 신호의 변화를 식별할 수 있는 설명 가능하고 재현 가능한 방법을 제공합니다.

탐지 규칙은 여기에 문서화되어 있습니다.

아직 해결하지 못한 부분

ReliaMesh는 여전히 초기 출시 버전입니다.

LLM 응답이 의미론적으로(semantically) 올바른지 자동으로 판단하지 못합니다. 근본 원인(root cause)을 확립하지 못하며, 탐지 임계값은 독립적인 프로덕션 워크로드에 맞춰 보정되지 않았습니다.

조직 간의 신뢰성 인텔리전스 또한 활성화되어 있지 않습니다.

이들은 의미 있는 한계점이며, 특히 유용한 탐지 신호와 통계적으로 검증된 신뢰성 주장(reliability claim)을 구별할 때 더욱 그렇습니다.

더 큰 질문

더 많은 애플리케이션이 AI 에이전트에 의존함에 따라, 인프라 가용성과 작업 신뢰성을 별개의 측정 항목으로 취급해야 합니다.

모델이 도달 가능하고, 툴이 응답하며, 워크플로우가 여전히 실패할 수 있습니다.

다른 개발자들은 프로덕션 환경에서 이러한 실패를 어떻게 측정하는지 궁금합니다.

애플리케이션별 유효성 검사(validation), 평가 프레임워크(evaluation frameworks), 트레이싱 툴(tracing tools) 중 어떤 것에 의존하고 계신가요, 아니면 다른 방법인가요?

프로젝트: https://github.com/PrefilerLabs/reliamesh

공개 고지: 이 글은 프로젝트의 공개 기술 문서를 사용하여 AI 도움을 받아 작성되었습니다.