LLM 에이전트 실패 원인 진단: ITBench와 MAST를 활용한 심층 분석

최근 복잡한 IT 워크플로우 자동화를 위해 에이전트 기반 LLM 시스템이 주목받고 있습니다. 하지만 기존의 벤치마크들은 단순히 '성공했는지/실패했는지'라는 단일 지표만 제공하여, 실제 실패 원인이 무엇인지 파악하기 어렵다는 한계가 있었습니다. 본 연구는 IBM Research와 UC Berkeley가 이 블랙박스 문제를 해결하고자 MAST (Multi-Agent System Failure Taxonomy)를 개발하고 적용한 사례를 다룹니다.

1. 에이전트 실패 진단의 새로운 접근: MAST

MAST는 복잡한 에이전트 시스템의 실행 로그(execution traces)를 분석하여, 실패 원인을 14가지의 구체적인 패턴으로 구조화하는 표준 분류 체계입니다. 이는 단순히 '실패'라는 결과가 아닌, 왜 실패했는지에 대한 상세한 진단 보고서를 제공합니다.

MAST는 크게 세 가지 핵심 카테고리로 에이전트 실패를 분류합니다:

• FC1: 시스템 설계 문제 (System Design Issues): 에이전트의 아키텍처나 역할 정의에서 비롯된 문제입니다. (예: FM-1.3 단계 반복(looping), FM-1.5 종료 조건 인지 부족).
• FC2: 에이전트 간 불일치 (Inter-Agent Misalignment): 런타임 중 에이전트들이 환경이나 서로와 소통하는 과정에서 발생하는 문제입니다. (예: FM-2.2 명확화 요청 실패(Clarification Failure)).
• FC3: 작업 검증 (Task Verification): 에이전트가 도출한 결과물의 품질 보증 단계에서 발생하는 오류입니다. (예: FM-3.3 잘못된 검증(Incorrect Verification)으로 성공을 허위 선언).

2. ITBench를 활용한 심층 분석

연구진은 SRE, 보안, FinOps 자동화의 산업 표준 벤치마크인 ITBench를 사용했습니다. 이 벤치마크에서 에이전트는 실제 운영 환경처럼 Kubernetes 장애 진단이나 취약점 패치 등의 작업을 수행합니다.

그들은 Gemini-3-Flash, Kimi-K2, GPT-OSS-120B 세 가지 모델을 사용하여 ITBench SRE 트레이스 310개를 분석했습니다. 이 비교는 단순히 성능 점수를 넘어, 각 모델이 어떤 유형의 실패를 보이는지 '실패 시그니처'를 파악하는 데 초점을 맞췄습니다.

주요 발견 사항:

• 모델 복잡성 차이: 최신 플래시급 모델(Gemini-3-Flash)은 트레이스당 평균 2.6개의 고립된 실패 모드를 보이는 반면, 대규모 오픈 소스 모델(GPT-OSS-120B)은 최대 5.3개에 달하는 연쇄적이고 복합적인 실패 패턴을 보였습니다.
• 가장 위험한 오류: 모든 모델에서 가장 강력하게 나타나는 실패 예측 인자는 **FM-3.3 (잘못된 검증)**이었습니다. 이는 에이전트가 실제 근거(Ground Truth)를 확인하지 않고 '성공'이라고 단정하는 경향을 의미합니다.
• 특정 모델의 약점: Kimi-K2는 작업 완료 시점을 인식하는 데 어려움을 겪으며, 조기 종료(Premature Termination) 및 종료 조건 인지 부족 문제에서 높은 비율을 보였습니다.

3. 에이전트 구축 개발자를 위한 실질적 제언 (Takeaways)

본 분석은 LLM 기반 에이전트를 엔터프라이즈 IT 워크플로우에 적용하는 개발자들에게 중요한 가이드라인을 제시합니다:

1. 검증 과정 외부화 (Externalize Verification): Gemini와 같은 최신 모델을 사용하더라도, LLM 자체의 판단(Self-grading)에 의존해서는 안 됩니다. 반드시 하드웨어 도구 증거(hard tool evidence)를 요구하여 종료 결정을 내리도록 강제해야 합니다.
2. 종료 및 루프 제어 분리 (Decouple Termination Logic): 에이전트의 종료 조건이나 반복적인 도구 호출/액션에 대한 감지 로직은 모델 외부(Outside the model)에 명시적으로 구현되어야 합니다. 이는 가장 흔한 실패 원인 중 하나입니다.
3. 모호성 처리 강제 (Force Clarify-or-Read-Only): 입력이 모호할 경우, 특히 소규모 모델에서 발생하는 '명확화 요청 실패(Clarification Failure)'를 방지하기 위해, 에이전트 그래프의 첫 번째 분기점으로 명확한 질문을 하거나 읽기 전용 모드를 강제하는 것이 필수적입니다.