이번 주에 거의 모든 에이전트 빌더(agent builder)가 결국 맞닥뜨리게 되는 실패 모드(failure mode)를 명시한 유용한 논문이 발표되었습니다.

에이전트가 실패하는 단계는 종종 실행을 망가뜨린 바로 그 단계가 아닙니다.

분노하며 디버깅을 해보기 전까지는 이 말이 당연하게 들릴 것입니다. 최종 답변은 틀렸고, 마지막 도구 호출(tool call)은 수상해 보이며, 트레이스(trace)는 80개의 이벤트로 길게 늘어져 있습니다. 하지만 실제 실수는 에이전트가 잘못된 검색 결과(retrieval result)를 수용하거나, 제약 조건(constraint)을 놓치거나, 혹은 잘못된 하위 에이전트(sub-agent)에게 작업을 넘겼던 30단계 전의 일일 수 있습니다. 오류가 표면화될 때쯤이면, 증거는 전체 궤적(trajectory)에 걸쳐 흩어져 버립니다.

UIUC, Toronto, Google, Stanford 등의 연구진이 개발한 새로운 오픈 소스 툴킷인 AgentDebugX는 이러한 혼란을 폐쇄형 디버깅 루프(closed debugging loop)로 전환하려고 시도합니다. 이는 단순히 "여기에 스팬(spans)이 있으니 행운을 빕니다"라고 말하는 또 다른 대시보드가 아닙니다. 이 루프는 탐지(detect), 속성 부여(attribute), 복구(recover), 재실행(rerun)으로 구성됩니다.

이러한 구조는 특정 벤치마크 수치보다 더 중요합니다.

대부분의 에이전트 관측성(observability)은 트레이스 재생(trace replay) 단계에서 멈춥니다. 재생은 필요하지만, 그것이 곧 진단은 아닙니다. 트레이스는 무엇이 일어났는지는 알려줄 수 있습니다. 하지만 어떤 이전의 결정이 나머지 실행을 복구 불가능하게 만들었는지, 또는 재실행 전에 무엇을 변경해야 하는지를 자동으로 알려주지는 않습니다.

AgentDebugX가 흥미로운 이유는 실패한 실행을 단순한 로그(logs)가 아닌 증거(evidence)로 취급하기 때문입니다.

이 툴킷은 실행을 이식 가능한 트레이스 형식으로 정규화하고, 눈에 보이는 실패를 찾아내며, 증상을 발생 가능한 근본 원인(root causes)으로 추적하고, 수정 사항을 제안하며, 체크포인트(checkpoint)로부터 재실행 패키지를 만듭니다. 논문에서는 주요 진단 구성 요소를 DeepDebug라고 부릅니다. DeepDebug는 궤적을 전역적으로 읽고, 후보 원인들을 조사하며, 상충하는 설명들을 교차 검증하고, 증거와 구체적인 수리 방안이 포함된 감사 가능한 근본 원인 보고서(root-cause report)를 생성합니다.

이것이 바로 에이전트 툴링(agent tooling)이 나아가야 할 정확한 방향입니다.

트레이스는 사고(incident) 그 자체가 아닙니다

전형적인 웹 서비스는 보통 더 명확한 실패 지점(failure surface)을 제공합니다. 요청이 에러를 발생시키거나, 데이터베이스 호출이 타임아웃(timeout)되거나, 큐(queue)가 쌓이는 식입니다. 여전히 판단은 필요하지만, 시스템은 대개 명확한 기계적 경계(mechanical boundaries)를 가지고 있습니다.

에이전트(Agents)는 상황이 더 나쁩니다. 에이전트는 겉보기에 합리적으로 보이면서도 실패할 수 있습니다.

잘못된 실행(bad run)에는 유효한 툴 호출(tool calls), 그럴듯한 중간 추론(intermediate reasoning), 깔끔한 JSON, 그리고 여전히 틀린 최종 답변이 포함될 수 있습니다. 버그가 항상 크래시(crash)로 나타나는 것은 아닙니다. 때로는 조용한 의미론적 드리프트(semantic drift)로 나타납니다. 에이전트가 제약 조건을 잊어버리거나, 오래된 메모리(stale memory)를 신뢰하거나, 잘못된 것을 검색하고 그 위에 결과를 쌓거나, 한참 뒤에야 눈에 띄게 틀린 것으로 드러나는 계획(planning) 선택을 내리기도 합니다.

이것이 바로 "트레이스(trace)를 보여달라"는 것만으로는 충분하지 않은 이유입니다. 트레이스는 원재료일 뿐입니다. 그것이 근본 원인(root cause)은 아닙니다.

유용한 단위는 사고 번들(incident bundle)에 더 가깝습니다. 여기에는 궤적(trajectory), 의심되는 근본 원인 단계, 그 의심에 대한 증거, 제안된 수정 사항, 그리고 재실행(rerun) 결과가 포함되어야 합니다. 일단 이를 확보하면, 실패는 재사용 가능한 것이 됩니다. 슬랙(Slack) 속으로 사라져 버리는 일회성 디버깅 세션 대신, 회귀 테스트 케이스(regression case)가 될 수 있습니다.

이것이 제가 AgentDebugX의 Error Hub 아이디어에서 좋아하는 부분입니다. 정제된 실패 번들(failure bundle)은 저장, 비교 및 재생(replay)이 가능합니다. 일반적인 소프트웨어 용어로 말하자면, 이는 "누군가 이게 한 번 고장 났었다고 기억함"과 "우리가 테스트를 추가함"의 차이와 같습니다.

에이전트에게는 후자가 훨씬 더 많이 필요합니다.

속성 부여(Attribution)가 어려운 부분입니다

해당 논문은 벤치마크가 실제 운영 환경(production)은 아니라는 통상적인 주의 사항과 함께, 주목할 만한 두 가지 결과를 보고합니다.

Who&When 데이터셋에서 DeepDebug는 qwen3.5-9b를 사용하여 28.8%의 엄격한 에이전트 및 단계 속성 부여(agent-and-step attribution) 정확도를 달성했습니다. 이는 가장 강력한 단일 패스(single-pass) 베이스라인의 21.7%와 비교되는 수치입니다. GAIA 데이터셋에서는 단 한 번의 재실행으로 실패한 73개 작업 중 13개를 복구했으며, 이는 세 가지 분리된 자기 수정(self-correction) 베이스라인이 4~6개를 복구한 것과 대조적입니다. 이를 통해 전체 정확도를 55.8%에서 63.6%로 끌어올렸습니다.

이것들은 마법 같은 숫자가 아닙니다. 모두가 정직함을 유지할 수 있을 만큼 충분히 작은 수치입니다. 하지만 이 수치들은 올바른 병목 지점(bottleneck)을 가리키고 있습니다.

자기 수정 (Self-correction)은 종종 마지막 답변을 수정해야 할 대상으로 취급합니다. 에이전트 디버깅 (Agent debugging)은 전체 실행 과정을 검사해야 할 대상으로 취급해야 합니다. 중요한 질문은 “모델이 다시 시도할 수 있는가?”가 아닙니다. “시스템이 이전 실행이 어디서 궤도를 벗어났는지 알고 있는가?”입니다.

두 워크플로우 모두 외부에서 보기에는 비슷해 보일 수 있기 때문에 이 차이를 놓치기 쉽습니다. 둘 다 재실행(rerun)합니다. 둘 다 모델에게 도움을 요청합니다. 둘 다 더 나은 답변을 만들어낼 수도 있습니다.

차이점은 재실행이 진단 (diagnosis)에 근거하고 있는지 여부입니다.

귀속 (attribution) 없이는 재실행은 비용만 많이 드는 희망일 뿐입니다. 귀속이 있다면, 그것은 테스트 가능한 개입 (intervention)이 됩니다. 18단계의 변경이 실제로 결과를 수정했는지, 아니면 시스템이 단순히 두 번째 시도에서 운이 좋았던 것뿐인지 질문할 수 있게 됩니다.

이것이 에이전트 데모 (agent demos)와 에이전트 운영 (agent operations)을 가르는 경계선입니다.

내가 여기서 가져오고 싶은 것

만약 당신이 에이전트를 구축하고 있다면, 아마 내일 당장 AgentDebugX의 전체 스택이 필요하지는 않을 것입니다. 하지만 그 형태 (shape)는 필요할 것입니다.

첫째, 모든 실행 과정을 내보낼 수 있게 (exportable) 만드세요. “벤더 대시보드를 볼 수 있다” 수준이 아니라, 내보낼 수 있어야 합니다. 안정적인 이벤트 ID, 도구 입력 및 출력 (tool inputs and outputs), 모델 선택, 프롬프트 또는 프롬프트 해시 (prompt hashes), 검색 결과 (retrieval results), 핸드오프 (handoffs), 그리고 경로를 재구성할 수 있을 만큼 충분한 상태 (state)가 필요합니다. 만약 트레이스 (trace)가 단 하나의 플랫폼 내에만 존재한다면, 프레임워크를 비교하거나 정상적인 경로 (happy path) 밖에서 사고를 재현해야 하는 순간 고통스러워질 것입니다.

둘째, 탐지 (detection)와 귀속 (attribution)을 분리하세요. 탐지는 출력이 실패했거나, 도구 호출 (tool call)에 오류가 발생했거나, 에이전트가 루프를 돌았거나, 제약 조건이 위반되었다고 말합니다. 귀속은 어떤 이전의 결정이 아마도 그것을 유발했을 것이라고 말합니다. 이 둘은 서로 다른 작업입니다. 이 둘을 섞어버리면, 모두가 지목하기 가장 쉬운 마지막 가시적 오류를 탓하게 되는 익숙한 사후 분석 (postmortem) 상황이 발생하게 됩니다.

셋째, 실패한 실행(runs)을 회귀 테스트 케이스(regression cases)로 저장하세요. 이 논문의 Error Hub 프레임링(framing)은 설령 이를 지루한 JSON 파일 폴더 형태로 구현하더라도 여기서 유용합니다. 실패 사례, 의심되는 근본 원인(root cause), 수정 사항, 그리고 재실행(rerun) 결과를 함께 보관하세요. 미래의 에이전트들은 단순히 합성 벤치마크(synthetic benchmark)를 통과하는 것이 아니라, 어제의 기이한 실패 사례들을 극복해야 합니다.

넷째, 복구(recovery)를 '느낌적인 느낌'에 의존한 재시도(vibes retry)가 아닌, 통제된 재실행(controlled rerun)으로 취급하세요. 만약 수정 사항이 "12단계에서의 검색 쿼리(retrieval query) 변경"이라면, 해당 체크포인트(checkpoint)부터 재실행하여 분기(branches)를 비교하십시오. 시스템이 체크포인트를 생성할 수 없다면, 장기적 행동(long-horizon behavior)을 제대로 디버깅할 수 없습니다. 그저 처음부터 다시 시작하며 주사위 운이 더 좋기를 바랄 뿐입니다.

이 중 그 어떤 것도 화려하지 않습니다. 대부분은 배관 작업(plumbing)에 가깝습니다. 하지만 대개 레버리지(leverage)는 바로 그곳에서 나옵니다.

불편한 한계

제가 과장하고 싶지 않은 한 가지가 있습니다.

AgentDebugX는 여전히 진단적 판단(diagnostic judgment)에 의존합니다. DeepDebug는 후보들을 교차 검증하고 증거를 생성할 수 있지만, 조용한 의미론적 드리프트(semantic drift)는 매우 까다로운 대상입니다. 어떤 실패들은 하나의 깔끔한 근본 원인을 갖지 않습니다. 잘못된 지시(instruction), 취약한 검색(retrieval), 지나치게 광범위한 도구 권한(tool permission), 그리고 누락된 검증기(verifier)가 결합되어 서서히 실패하는 실행이 발생할 수 있습니다.

따라서 저는 원인 규명(attribution)을 신탁(oracle)처럼 취급하지 않겠습니다. 대신 감사 추적(audit trail)을 갖춘 가설 생성기(hypothesis generator)로 취급하겠습니다.

이것만으로도 가공되지 않은 트레이스(raw traces)보다는 여전히 큰 개선입니다.

업계는 마치 다음 단계가 더 높은 자율성(autonomy)인 것처럼 에이전트에 대해 계속 이야기합니다. 그럴지도 모릅니다. 하지만 더 실질적인 다음 단계는 더 나은 증거(evidence)입니다. 에이전트가 티켓, 셸(shells), 리포지토리(repos), 고객 데이터 또는 예산에 접근할 수 있다면, 디버깅 범위(debugging surface)가 단순히 스크롤 기록(scrollback)과 어깨를 으쓱하는 것으로 끝나서는 안 됩니다.

제가 원하는 표준은 지루하고 엄격한 것입니다. 모든 중요한 에이전트 실행은 다른 사람, 모델, 또는 미래의 버전이 다음 세 가지 질문에 답할 수 있을 만큼 충분한 증거를 남겨야 합니다.

무엇이 실패했는가?

어디서부터 실패하기 시작했는가?

재실행했을 때 무엇이 변했는가?

이 질문들에 답할 수 있을 때까지, 당신은 에이전트 플랫폼을 가진 것이 아닙니다. 그저 자신의 사고(incidents)를 망각하는 영리한 프로세스를 가진 것뿐입니다.

출처: AgentDebugX 논문 및 프로젝트 사이트.