AI 에이전트가 처음 회복 불가능해진 순간을 찾는 법
Microsoft Research의 AgentRx가 길고 확률적이며 여러 에이전트가 얽힌 실행 기록에서 결정적 실패 지점과 원인을 어떻게 찾는지 살펴봅니다.

에이전트 디버깅이 어려운 이유는 오류가 한 줄의 예외로 끝나지 않기 때문이다. 실행은 수십 단계로 길어지고, 같은 입력에서도 경로가 달라질 수 있다. 여러 에이전트가 함께 일하면 한 에이전트의 실수가 다른 에이전트의 잘못된 판단으로 이어진다. 도구 출력도 언제나 깨끗하지 않다. 마지막 실패 화면만 봐서는 어디서부터 일이 돌이킬 수 없게 됐는지 알기 어렵다.
Microsoft Research가 공개한 AgentRx는 실패한 실행 전체를 하나의 궤적으로 보고 진단한다. 여기서 중요한 개념은 critical failure step, 결정적 실패 단계다. 단순히 처음 나타난 오류도, 마지막에 관찰된 오류도 아니다. 어떤 에이전트도 더는 회복하지 못한 최초의 실패를 뜻한다.
예를 들어 웹 에이전트가 문서를 내려받지 못했더라도 오케스트레이터가 파일 전용 에이전트로 경로를 바꿔 작업을 이어갔다면 그 오류는 결정적 실패가 아니다. 나중에 파일 경로를 지어내 존재하지 않는 파일을 읽으려 했고 그 뒤로 복구하지 못했다면, AgentRx가 찾으려는 지점은 바로 그 두 번째 실패다. 이렇게 해야 증상과 원인을 구분할 수 있다.

추측 대신 실행 가능한 제약으로 검사한다
AgentRx는 실패한 궤적, 사용할 수 있는 도구와 입출력 스키마, 선택적인 도메인 정책을 입력으로 받는다. 서로 다른 로그 형식은 먼저 공통 중간 표현인 Trajectory IR로 정규화한다. 메시지, 도구 호출, 도구 출력, 관찰 가능한 환경 상태를 같은 단계 구조로 맞추기 위해서다.
그다음 도구 스키마와 정책에서 실행 가능한 제약을 합성한다. 도구 호출에는 필수 인자가 있어야 한다거나, API 응답이 정해진 형식을 만족해야 한다는 검사를 만들 수 있다. 도메인 정책에 “사용자 확인 없이 데이터를 삭제하지 말라”는 규칙이 있다면 그것도 검사 가능한 조건으로 바꾼다. 전역 제약은 스키마와 정책에서 한 번 만들고, 동적 제약은 현재 단계까지 관찰한 궤적의 접두 구간에서 만든다.
각 제약에는 guard와 assertion이 있다. guard는 지금 이 검사를 적용할 상황인지 판단한다. 삭제 도구가 호출되지 않은 단계라면 삭제 확인 규칙은 건너뛴다. 조건이 맞는 단계에서만 assertion을 실행해 충족 또는 위반을 판정한다. 검사는 구조화된 필드에 대한 프로그램식 검사일 수도 있고, 자연어 의미를 판단하는 LLM 검사일 수도 있다.
위반이 발견되면 AgentRx는 단계 번호, 위반한 제약, 이를 뒷받침하는 실행 흔적을 validation log에 함께 남긴다. 마지막의 LLM judge는 전체 궤적만 보고 감으로 고르는 대신 이 근거 로그와 실패 분류 체크리스트를 받아 결정적 실패 단계와 원인 범주를 고른다. 다만 위반 신호는 절대적인 규칙이 아니라 진단 증거다. 전체 맥락과 맞지 않으면 judge가 배제할 수 있다.

115개 실패를 사람이 읽어 만든 기준
2026년 3월 공개 기준 벤치마크는 실패한 궤적 115개로 구성됐다. 구조화된 소매 API 작업인 τ-bench 29개, 실제 장애 대응 흐름인 Flash 42개, 웹과 파일 작업을 여러 에이전트가 수행하는 Magentic-One 44개다. 연구진은 궤적마다 모든 실패를 먼저 표시한 다음, 종료 지점에서 거꾸로 추적해 복구하지 못한 최초의 실패를 결정적 실패로 붙였다. 수동 주석에는 총 42.7시간이 들었다.
분류표는 미리 정한 답안을 적용한 것이 아니라 반복해서 나타난 패턴에서 범주를 도출하는 grounded theory 방식으로 만들었다. 발표 시점의 아홉 범주는 계획 미준수, 근거 없는 정보 생성, 잘못된 도구 호출, 도구 출력 오해, 사용자 의도와 계획의 불일치, 사용자 의도 정보 부족, 지원되지 않는 의도, 가드레일 발동, 시스템 실패다. 무엇을 잘못했는지만이 아니라 계획, 도구, 정보, 안전 정책, 인프라 중 어디에서 실패가 시작됐는지 구분한다.
Microsoft가 발표한 실험 결과에서 AgentRx는 프롬프팅 기준선보다 실패 단계 위치 정확도를 절대 23.6퍼센트포인트 높였고, 근본 원인 귀속도 22.9퍼센트 개선했다. 다만 영역별 차이는 컸다. 짧은 Flash 궤적에서는 기준선도 강했고, 평균 16,484토큰인 Magentic-One의 긴 궤적에서는 전체를 한 번에 보는 제약 생성이 맥락 희석에 취약했다. 길이가 50단계 이하인 하위 집합에서 단계별 생성이 더 안정적이었다.
진단 도구이지 안전 보증서는 아니다
이 결과를 일반적인 에이전트 안전성으로 확대해서는 안 된다. 벤치마크는 세 영역의 실패 사례만 다루며, 여기서 만든 분류표는 다른 현장의 실패를 빠뜨릴 수 있다. 제약 신호가 약하거나 거짓 양성을 포함하면 AgentRx도 잘못된 지점을 고를 수 있다. 프로그램식 검사뿐 아니라 제약 생성, 의미 검사, 최종 판정에 LLM이 관여하므로 확률성과 비용도 남는다.
실행 로그에는 사용자 정보나 업무 데이터가 포함될 수 있어 저장, 접근, 공유 정책도 별도로 필요하다. 무엇보다 설명 가능한 진단 결과가 나온다고 해서 에이전트가 배포하기에 안전하다는 뜻은 아니다. AgentRx는 실패를 더 빨리 찾도록 돕지만, 신중한 테스트와 사람의 검토를 대체하지 않는다.
버전 참고: 이 글의
115개, 9개 범주는 2026년 3월 Microsoft 발표와 arXiv v1 기준이다. 2026년 8월 31일 공개된 논문 v2는 170개 궤적으로 확장됐고, 현재 저장소의 실행 분류에는Inconclusive가 추가돼 10개 항목으로 표시된다.