Why Do AI Agents Systematically Fail at Cloud Root Cause Analysis?

본 논문은 클라우드 시스템의 자동화된 근본 원인 분석 (RCA) 에서 LLM 기반 에이전트가 모델의 성능과 무관하게 공유된 아키텍처 결함으로 인해 체계적으로 실패하는 원인을 규명하고, 프롬프트 엔지니어링보다는 에이전트 간 통신 프로토콜 개선이 더 효과적인 해결책임을 입증했습니다.

핵심

🏭 배경: 거대한 공장의 고장

현대 클라우드 시스템은 거대한 공장처럼 수천 개의 부품 (마이크로서비스) 이 서로 연결되어 돌아갑니다. 이 공장에 고장이 나면 돈이 엄청나게 날아갑니다. 그래서 고장의 **진짜 원인 (Root Cause)**을 찾아내는 '수리 작업'이 필수적입니다.

최근에는 AI(거대 언어 모델) 를 이 수리 작업에 투입했는데, 문제는 AI 가 고장 원인을 찾아내는 정확도가 매우 낮다는 것입니다. (정확도 3.9%~12.5% 수준)

🔍 연구의 핵심: "정답만 보는 게 아니라, '왜' 틀렸는지 보자"

기존 연구들은 AI 가 "정답을 맞췄는지"만 확인했습니다. 하지만 이 논문은 **"AI 가 수리 과정에서 어디서, 어떻게 실수를 했는지"**를 아주 자세히 파헤쳤습니다.

연구진은 5 가지 다른 AI 모델에게 335 가지의 고장 사례를 해결하게 시켰고, 총 1,675 번의 수리 과정을 기록했습니다. 그 결과, AI 가 빠지는 **12 가지의 치명적인 함정 (Pitfall)**을 찾아냈습니다.

🕵️‍♂️ AI 가 자주 빠지는 3 가지 함정 (비유로 설명)

1. 혼자 생각하는 실수 (Intra-Agent Pitfalls)

수석 기사 (컨트롤러) 가 혼자서 데이터를 해석할 때 생기는 실수입니다.

• 환각 (Hallucination): AI 는 마치 마법사처럼, 실제 데이터에 없는 이야기를 지어냅니다. "CPU 사용량이 높네? 아, 메모리 문제가 있겠군!"이라고 데이터를 보고도 엉뚱한 결론을 내립니다. (가장 흔한 실수, 71%)
• 탐색 부족 (Incomplete Exploration): 안일한 탐정처럼, 중요한 단서 (네트워크 로그 등) 는 무시하고 가장 눈에 띄는 단서 (CPU) 만 봅니다. "이거만 보면 되겠지?"라고 생각하다가 진짜 원인을 놓칩니다.
• 증상과 원인 혼동: "머리가 아픈데 (증상), 약을 먹으면 낫겠지?"라고 생각하지만, 진짜 원인은 "뇌종양"일 수 있습니다. AI 는 표면적인 증상만 보고 고장 원인으로 착각합니다.

2. 서로 대화할 때 생기는 오해 (Inter-Agent Pitfalls)

수리 작업은 '지시하는 기사 (컨트롤러)'와 '코드를 실행하는 견습공 (익시큐터)'이 팀을 이뤄 합니다. 이 둘이 대화할 때 문제가 생깁니다.

• 지시와 실행의 불일치: 기사가 "빨간 버튼을 눌러라"라고 말했는데, 견습공은 "파란 버튼을 누르겠다"고 착각합니다. 자연어 (말) 로만 대화하다 보니 맥락이 사라져서 엉뚱한 코드를 작성합니다.
• 무의미한 반복: 견습공이 실패한 방법을 기사가 모르고, 같은 실수를 반복하게 됩니다. "또 실패했네? 다시 해봐!"를 무한 반복하다가 시간이 다 떨어집니다.

3. 작업 환경과의 충돌 (Agent-Environment Pitfalls)

• 메모리 폭주: 견습공이 작업 중이던 데이터를 계속 쌓아두다가, 컴퓨터 메모리가 터져버립니다 (OOM). 수리 과정이 아예 중단됩니다.

💡 해결책: "말을 더 잘하게 하는 것" vs "시스템을 고치는 것"

연구진은 이 문제들을 해결하기 위해 두 가지 방법을 실험했습니다.

❌ 방법 1: "더 잘 설명해줘" (프롬프트 엔지니어링)

AI 에게 "잘 봐, 착각하지 마, 모든 데이터를 확인해"라고 더 자세히 지시하는 것을 시도했습니다.

• 결과: 실패했습니다. AI 는 "알겠습니다"라고 대답하지만, 실제로는 여전히 환각을 일으키거나 데이터를 잘못 해석했습니다. 말만 잘한다고 문제가 해결되지 않습니다.

✅ 방법 2: "작업 과정을 투명하게 공유해" (시스템 구조 개선)

기사와 견습공이 자연어 (말) 만 주고받는 게 아니라, 작성한 '코드'와 '실행 결과 (오류 메시지)'를 그대로 보여주고 대화하게 했습니다.

• 결과: 대폭 성공했습니다!
  • 기사가 "아, 네가 쓴 코드가 내 지시와 달라서 실패했구나!"라고 바로 알 수 있게 되었습니다.
  • 오류가 15% 이상 줄어들었고, 수리 정확도도 올라갔으며, 작업 시간도 22% 단축되었습니다.
  • 메모리 폭주 문제는 '메모리 감시관'을 붙여서 해결했습니다.

📝 결론: 왜 이 연구가 중요한가?

이 논문은 **"AI 가 똑똑해지면 다 해결될 거야"**라는 생각을 깨뜨립니다.

1. 모델의 능력보다 '시스템'이 문제다: 아무리 똑똑한 AI 모델을 써도, **협업 방식 (대화 구조)**이 나쁘면 실패합니다.
2. 말 (프롬프트) 로는 안 된다: AI 에게 "조심해"라고 말하는 것만으로는 해결되지 않습니다.
3. 구조가 답이다: AI 들이 서로의 작업 내용 (코드, 데이터) 을 투명하게 공유하고, 오류를 바로잡을 수 있는 구조를 만들어야만 클라우드 고장 수리가 가능해집니다.

한 줄 요약:

"AI 수리공들이 고장 원인을 못 찾는 건, 그들이 멍청해서가 아니라 서로 대화하는 방식이 엉망이기 때문입니다. 말을 더 잘하게 하는 게 아니라, 작업 과정을 투명하게 공유하게 하는 시스템을 바꿔야 합니다."

기술 요약

논문 요약: 클라우드 근본 원인 분석 (RCA) 에서 AI 에이전트의 체계적 실패 원인 분석

1. 문제 정의 (Problem)

대규모 클라우드 시스템의 장애는 막대한 금전적 손실과 서비스 중단을 초래하므로, 자동화된 근본 원인 분석 (Root Cause Analysis, RCA) 은 필수적입니다. 최근 대규모 언어 모델 (LLM) 기반 에이전트 (Multi-agent systems) 가 이 작업을 자동화하기 위해 도입되었으나, 실제 성능은 매우 낮습니다.

• 현황: 기존 벤치마크 (OpenRCA) 에서 다양한 LLM 모델을 사용하더라도 완벽한 정확도 (Perfect Accuracy) 는 3.9%~12.5% 에 불과합니다.
• 한계: 기존 평가 프레임워크는 최종 답변의 정답 여부만 평가할 뿐, 에이전트의 추론 과정이나 협업에서 왜 실패했는지에 대한 과정 수준의 (process-level) 통찰을 제공하지 못합니다. 이로 인해 연구자들은 모델 성능 향상이 필요한지, 프롬프트 개선이 필요한지, 아니면 에이전트 프레임워크 자체를 재설계해야 하는지 판단하기 어렵습니다.

2. 연구 방법론 (Methodology)

이 논문은 OpenRCA 벤치마크를 기반으로 한 과정 수준의 실패 분석 (Process-level Failure Analysis) 을 제시합니다.

• 실험 설정: 5 가지 다른 LLM 모델 (Gemini 2.5 Pro, GPT-5 mini, GPT-OSS 120B, Solar Pro 2, Claude Sonnet 4) 을 사용하여 OpenRCA 의 335 개 장애 사례 (Telecom, Bank, Market 도메인) 를 모두 실행하여 총 1,675 회 에이전트 실행을 수행했습니다.
• 분석 프레임워크: 실패를 3 가지 아키텍처 원인에 따라 분류했습니다.
  1. 에이전트 내부 추론 (Intra-Agent): 개별 에이전트의 사고 과정 오류.
  2. 에이전트 간 통신 (Inter-Agent): Controller 와 Executor 간의 정보 전달 오류.
  3. 에이전트 - 환경 상호작용 (Agent-Environment): 실행 런타임 및 데이터와의 상호작용 오류.
• 분류 체계: 수집된 실패 사례를 12 가지 '함정 (Pitfall)' 유형으로 세분화하고, 인간 - 루프 (Human-in-the-loop) 방식을 통해 검증했습니다.

3. 주요 기여 (Key Contributions)

1. 12 가지 함정 유형 분류 체계 (Taxonomy): 결과 기반 평가를 넘어 에이전트 실패의 원인을 체계적으로 진단할 수 있는 12 가지 실패 패턴을 정의했습니다.
2. 공통된 실패 모드의 발견: 모델의 능력 (Capability Tier) 이 다르더라도 모든 모델에서 동일한 실패 패턴이 우세하게 나타남을 실증했습니다. 이는 실패의 주원인이 개별 모델의 한계가 아니라 공유된 에이전트 프레임워크 (Agent Framework) 에 있음을 시사합니다.
3. 통제된 완화 실험 (Mitigation Experiments): 프롬프트 엔지니어링만으로는 주요 실패를 해결할 수 없으며, 에이전트 프레임워크의 구조적 수정 (특히 통신 프로토콜 개선) 이 효과적임을 입증했습니다.

4. 주요 결과 및 발견 (Key Results)

A. 주요 실패 패턴 (Pitfalls)

• 가장 빈번한 실패:
  • 해석에서의 환각 (Hallucination in Interpretation, 71.2%): 에이전트가 데이터를 사실적으로 읽지 않고, 일관성 있어 보이지만 사실과 다른 서사를 부여하는 현상. 모든 모델에서 66% 이상 발생.
  • 불완전한 탐색 (Incomplete Exploration, 63.9%): 관련 KPI 나 컴포넌트 범위를 무시하고 분석을 좁게 수행.
• 모델 간 차이: 코드 생성 오류 (Code generation error) 는 모델에 따라 편차가 컸으나 (Gemini 2.5 Pro 는 1.8%, Claude Sonnet 4 는 65.5%), 해석 환각과 불완전한 탐색은 모델과 무관하게 고르게 발생했습니다.

B. 완화 실험 결과

1. 프롬프트 엔지니어링의 한계 (Intra-Agent):
   • 가설 기반 프롬프팅 (Hypothesis-driven) 이나 함정 인식 프롬프팅 (Pitfall-aware) 을 적용해도 해석 환각은 줄어들지 않았습니다. 에이전트는 더 넓은 범위를 탐색하더라도 찾은 데이터를 잘못 해석하는 경향이 변하지 않았습니다.
2. 통신 프로토콜 개선의 효과 (Inter-Agent):
   • 개선 방안: Controller 와 Executor 간 통신 시 자연어 요약뿐만 아니라 생성된 Python 코드, 실행 출력, 예외 메시지 (Stack trace) 를 함께 공유하도록 프로토콜을 강화했습니다.
   • 성과: 통신 관련 실패 (지시 - 코드 불일치, 의미 없는 반복 등) 가 최대 15% 포인트 감소했습니다.
   • 종합적 이점: 모든 모델에서 완벽한 탐지율이 상승했고, 불필요한 단계 감소로 인해 실행 시간이 22.3% 단축되었습니다.
3. 환경적 문제 해결 (Agent-Environment):
   • 메모리 누수로 인한 실행 중단 (OOM) 을 방지하기 위해 '메모리 워처 (Memory Watcher)'를 도입하여 임계치 초과 시 재시작을 유도함으로써 OOM 실패를 완전히 제거했습니다.

5. 의의 및 결론 (Significance & Conclusion)

• 구조적 개편의 필요성: 이 연구는 클라우드 RCA 에이전트의 성능 저하가 단순히 더 강력한 LLM 모델을 사용하는 것으로 해결될 문제가 아님을 보여줍니다. 오히려 에이전트 프레임워크의 구조적 결함 (불투명한 통신, 상태 관리 부재, 검증 부재) 이 주원인입니다.
• 실무적 시사점:
  • 프롬프트 튜닝만으로는 한계가 명확하며, 에이전트 간 정보 공유의 투명성 (코드 및 원본 데이터 노출) 을 높이는 구조적 변경이 필수적입니다.
  • 제안된 12 가지 함정 분류 체계는 향후 더 신뢰할 수 있는 자율 에이전트 설계와 지속적인 모니터링 파이프라인 구축의 기초가 될 것입니다.
• 미래 방향: 해석 환각과 같은 근본적인 문제를 해결하기 위해서는 외부 검증 모듈 (Verification Modules) 도입, 구조적 상태 공유, 적응형 작업 분해 등 더 근본적인 아키텍처 변경이 필요함을 강조합니다.

이 논문은 AI 에이전트의 실패를 단순히 '정답률'로 평가하는 것을 넘어, 왜 실패하는지를 진단하고 구조적으로 해결하는 새로운 패러다임을 제시했다는 점에서 중요한 의의를 가집니다.