AWS, AI 에이전트 실패 원인까지 자동 진단하는 Strands Evals 디텍터 공개

AWS가 머신러닝 블로그를 통해 AI 에이전트의 실행 트레이스에서 실패를 자동으로 찾아내고 근본 원인을 분석하는 Strands Evals SDK의 '디텍터(Detector)' 기능을 공개했다. 에이전트가 프로덕션에서 실패했을 때 단순히 실패했다는 사실을 아는 것은 시작에 불과하며, 더 어려운 질문은 왜 실패했고 무엇을 고쳐야 하는가다. 디텍터는 이 진단 작업을 자동화해 소요 시간을 수 시간에서 수 분으로 줄여준다고 AWS는 설명했다.

기존 평가 방식은 '에이전트가 목표 달성에서 60점을 받았다'처럼 점수만 알려줄 뿐, 무엇이 잘못됐는지 파악하려면 실행 트레이스를 사람이 직접 검토해야 했다. 예컨대 배포나 프롬프트·툴 변경 이후 목표 성공률이 85%에서 70%로 떨어졌다면, 어떤 행동이 실패를 일으켰는지, 근본 원인과 그에 따른 증상을 어떻게 구분할지, 수정이 시스템 프롬프트에 속하는지 툴 정의에 속하는지를 일일이 판단해야 했다. 이 과정은 시니어 엔지니어가 수백 단계의 트레이스를 span 단위로 들여다봐야 해 확장되지 않았다.

디텍터 파이프라인은 두 단계로 작동하며 각 단계 모두 LLM 기반으로 실행 트레이스를 분석한다. 1단계인 실패 탐지는 세션의 각 span을 아홉 개 상위 범주로 구성된 실패 분류 체계와 대조한다. 환각, 잘못된 행동, 오케스트레이션 오류, 작업 지시 미준수, 실행 오류, 컨텍스트 처리 오류, 반복 행동, LLM 출력 문제, 구성 불일치가 그 범주다. 탐지된 각 실패에 대해 span 위치와 하나 이상의 범주, 신뢰도 점수, 트레이스에서 추출한 증거를 반환한다.

2단계인 근본 원인 분석은 탐지된 실패들 사이의 인과 사슬을 추적한다. 하나의 상위 실수가 여러 하위 실패로 연쇄되는 경우가 많은데, 근본 원인 분석은 원인과 증상을 분리한다. 각 실패의 인과성을 PRIMARY, SECONDARY, TERTIARY로 분류하고 전파 영향을 판단하며, 수정이 시스템 프롬프트와 툴 설명, 기타 중 어디에 속하는지에 따라 수정 권고를 생성한다.

두 단계 모두 세션 크기에 따라 계층적 전략으로 대응한다. 선택한 디텍터 모델의 컨텍스트 윈도에 들어가는 세션은 직접 분석하고, 다소 큰 세션은 조상·자손 span만 남기는 실패 경로 가지치기를 적용하며, 아주 큰 세션은 트레이스를 겹치는 윈도로 나눠 분석한 뒤 결과를 병합하는 청크 분석을 쓴다.

기능은 세 함수로 제공된다. detect_failures는 Strands Evals의 표준 트레이스 형식인 Session 객체를 받아 구조화된 실패 목록을 돌려준다. analyze_root_cause는 탐지된 실패를 받아 인과 사슬을 추적하며, 실패가 주어지지 않으면 실패 탐지를 자동으로 먼저 수행한다. diagnose_session은 두 단계를 하나의 파이프라인으로 묶어 실행하고, 중복이 제거된 권고를 담은 DiagnosisResult를 반환한다.

AWS는 '실제 세계에서 AI에 전력을 공급하는 데 드는 에너지 요구량의 영향을 조사하라'는 요청을 받은 리서치 에이전트 사례를 들었다. 이 에이전트는 툴 구성 문제를 만나 점차 성능이 저하됐는데, 디텍터는 한 번의 분석으로 실행 오류와 일반 지식에 기댄 환각, 목표 이탈 같은 문제를 여러 수준에서 동시에 찾아냈다. 근본 원인 분석은 retrieve 툴의 knowledgeBaseId가 명확히 문서화되지 않은 문제를 TOOL_DESCRIPTION_FIX로, 지속적인 툴 실패를 다루는 지침이 없는 문제를 SYSTEM_PROMPT_FIX로 구분해, 한쪽만 고치면 다른 쪽이 방치된다는 점을 드러냈다.

디텍터는 기존 평가 워크플로에 통합할 때 더 큰 가치를 낸다. DiagnosisConfig를 쓰면 어떤 실험에든 자동 진단을 붙일 수 있어 실패한 테스트 케이스마다 자동으로 진단이 생성된다. 기본값인 ON_FAILURE 모드는 평가에서 하나 이상의 케이스가 실패했을 때만 진단을 실행한다.

디텍터를 사용하려면 Python 3.10 이상과 pip install strands-agents-evals로 설치하는 Strands Evals SDK, 그리고 LLM 기반 분석을 위한 Amazon Bedrock 모델 접근 권한이 필요하다. Amazon CloudWatch 예제를 따라 하려면 logs:StartQuery와 logs:GetQueryResults 권한이 설정된 AWS 자격 증명도 갖춰야 한다.