기술 요약: SREGym – AI SRE 에이전트를 위한 라이브 벤치마크

1. 문제 제기

본 논문은 **사이트 신뢰성 엔지니어링 (SRE)**을 위한 AI 에이전트 평가의 중요한 격차를 다룹니다. AI 에이전트가 생산 환경의 장애를 진단하고 완화하기 위해 점점 더 많이 배포되고 있지만, 기존 벤치마크는 다음 세 가지 주요 이유로 충분하지 않습니다:

• 과도한 단순화: 현재 벤치마크 (예: 정적 Q&A 데이터셋, 이상 탐지 작업) 는 실제 현장의 사고 대응이 가진 역동적이고 다단계적인 특성을 포착하지 못합니다. 종단 간 해결보다는 정적 데이터나 고립된 증상에 기반하여 에이전트를 평가하는 경우가 많습니다.
• 신뢰성 부족: 기존 라이브 벤치마크 (예: AIOpsLab, ITBench) 는 장애를 시뮬레이션하지만 생산 환경의 복잡성을 갖추지 못합니다. 주로 애플리케이션 계층의 문제에 초점을 맞추고, "주변 잡음 (관련 없는 일시적 사건)"을 무시하며, 메타스테이블 상태나 상관관계 장애와 같은 복잡한 장애 모드를 모델링하지 못합니다.
• 확장성 문제: 많은 벤치마크는 새로운 시나리오를 구성하거나, 분산된 이벤트를 조정하거나, 문제 공간을 확장하기 어렵게 만드는 전용 하드코딩 스크립트 (예: Ansible) 에 의존합니다.

또한, AI 생성 코드의 부상은 새로운 신뢰성 문제를 야기하고 있으며, 보고에 따르면 AI 코드는 인간이 작성한 코드보다 훨씬 더 많은 결함을 도입하고 테스트를 더 자주 통과하지 못한다고 합니다. 이는 코딩을 넘어 실시간 완화를 포함하는 견고한 에이전트형 SRE 역량이 필요함을 시사합니다.

2. 방법론: SREGym 프레임워크

저자들은 SREGym을 제시합니다. 이는 실제 클라우드 네이티브 시스템 스택 (Kubernetes) 위에 구축된 고신뢰도 라이브 벤치마크입니다. 정적 데이터셋과 달리 SREGym 은 에이전트가 표준화된 인터페이스를 통해 실행 중인 시스템과 상호작용할 수 있는 라이브 환경을 제공합니다.

핵심 아키텍처

• 시스템 환경: SREGym 은 Kubernetes 운영자가 관리하는 클라우드 네이티브 애플리케이션 (예: DeathStarBench, TrainTicket, Astronomy Shop) 과 백엔드 시스템 (MongoDB, TiDB, Kafka) 의 카탈로그를 배포합니다.
• 에이전트 인터페이스: 에이전트는 **모델 컨텍스트 프로토콜 (MCP)**을 통해 상호작용하며, 지표 (Prometheus), 로그 (Loki), 트레이스 (Jaeger), 그리고 클러스터 제어 (kubectl) 를 위한 도구에 접근합니다.
• 장애 및 잡음 주입: 프레임워크는 다음을 시뮬레이션하기 위해 모듈식 주입기 세트를 사용합니다:
  • 장애: eBPF 를 통한 하드웨어 장애, OS 커널 장애, 잘못된 구성, 코드 버그, 운영자 오류 등 스택 전반에 걸친 근본 원인.
  • 잡음: 목표 장애와 관련 없는 pod 크래시, 패킷 손실과 같은 일시적이고 자가 회복되는 교란으로, 에이전트가 신호와 잡음을 구별하는 능력을 테스트하도록 설계됨.
• 문제 정의: 문제는 환경, 에이전트 인터페이스, 장애/잡음, 오라클로 구성된 튜플 $P = (E, I, F, O)$로 정의됩니다.
• 평가 오라클:
  • 진단 오라클: 자연어 진단을 평가하기 위해 구조화된 체크리스트 (3 가지 차원: 장애 위치 특정, 장애 특성화, 실패 범위 전반에 걸친 9 개의 예/아니오 질문) 를 갖춘 LLM-as-a-Judge 방식을 사용합니다. 이는 취약한 문자열 매칭을 피하고 세밀한 평가를 가능하게 합니다.
  • 완화 오라클: 클라이언트 측 (요청 성공률) 과 시스템 측 가시성을 모두 사용하여 목표 장애가 해결되고 시스템이 건강한 상태로 돌아갔는지 프로그래밍 방식으로 검증합니다.

핵심 설계 원칙

1. 증상이 아닌 장애 시뮬레이션: 시스템은 크래시된 pod 과 같은 증상보다는 누락된 환경 변수와 같은 근본 원인을 주입하여 에이전트가 근본적인 결함에 대해 추론하도록 요구합니다.
2. 조립성: Python 기반 런타임이 장애 및 잡음 주입기를 오케스트레이션하여 메타스테이블 장애 (자가 유지되는 저하) 및 동시/상관관계 장애와 같은 복잡한 시나리오를 가능하게 합니다.
3. 확장성: 프레임워크는 문제 생성을 위한 "원클릭 (push-button)" 방식으로 설계되어 연구자가 기존 시나리오를 변형하거나 API 를 통해 새로운 시나리오를 생성할 수 있도록 합니다.

3. 주요 기여

• SREGym 벤치마크: 하드웨어, OS, 애플리케이션 계층을 아우르는 90 개의 현실적이고 도전적인 SRE 문제를 포함한 라이브 오픈소스 벤치마크.
• 고신뢰도 장애 모델링: 벤치마크에서 이전에 다루지 않았던 복잡한 장애 모드의 도입:
  • 메타스테이블 장애: 일시적 이벤트에 반응하여 저하되고 특정 개입 없이는 회복되지 않는 시스템.
  • 동시 장애: 동시에 발생하는 여러 독립적인 장애.
  • 상관관계 장애: 공유된 근본 원인으로 인해 여러 구성 요소가 실패하는 경우.
• 주변 잡음 시뮬레이션: 에이전트가 관련 없는 데이터를 필터링하도록 도전하는 일시적이고 저영향의 교란을 주입할 수 있는 능력.
• 견고한 평가 프로토콜: 인간 전문가와의 높은 일치도 ($\kappa = 0.90$) 를 달성하면서도 대규모 데이터셋으로 확장 가능한 체크리스트 기반 LLM 평가 방법.

4. 실험 결과

저자들은 최첨단 모델 (Sonnet-4.6, GPT-5.4, Kimi K2.5) 을 기반으로 한 세 가지 에이전트인 Stratus(전문 SRE 에이전트), Claude Code, OpenAI Codex를 평가했습니다.

전반적 성능

• 성공률: 진단 성공률은 38.9% 에서 72.6% 사이였으며, 완화 성공률은 57.3% 에서 78.5% 사이였습니다.
• 종단 간 (E2E) 성능: 올바른 진단 + 올바른 완화를 의미하는 E2E 성공률은 에이전트 - 모델 쌍 간에 크게 달라, 최대 **40%**의 차이가 있었습니다.
• 잡음의 영향: 잡음의 존재는 모든 에이전트의 진단 성공률을 일관되게 감소시켰습니다. 완화는 더 견고했지만 여전히 영향을 받았습니다.

주요 발견

1. 계층별 약점: 에이전트는 애플리케이션 계층 문제에서는 잘 수행되었지만 OS 나 하드웨어와 같은 하위 계층에 뿌리를 둔 장애나 복잡한 패턴에서는 크게 어려움을 겪었습니다. 예를 들어, 하드웨어 장애 시나리오 (디스크 섹터 오류) 에서 에이전트는 하드웨어 근본 원인을 식별하지 못하고 종종 이를 애플리케이션 로직으로 잘못 귀속시켰습니다.
2. 메타스테이블 장애의 도전: 에이전트는 애플리케이션 수준의 트리거를 식별할 수 있었지만, 메타스테이블 상태를 해결하는 데 필요한 인프라 제약 (예: 리소스 할당량) 과 이를 연결하는 데 자주 실패했습니다.
3. 탐욕적 진단: 반복되는 실패 모드는 "탐욕적 접근"으로, 에이전트가 첫 번째 그럴듯한 이상 (종종 잡음이나 관련 없는 문제) 에 매달려 더 이상 조사하지 않아 잘못된 근본 원인 귀속으로 이어지는 경우였습니다.
4. 토큰 효율성: 전문 SRE 에이전트 (Stratus) 는 관측 데이터를 전처리함으로써 코딩 에이전트 (Claude Code, Codex) 보다 토큰 효율성이 훨씬 높았습니다 (약 3 배 적은 ��큰 사용). 이는 E2E 성공률을 희생하지 않았습니다.
5. 진단 - 완화 상관관계: 올바른 진단은 성공적인 완화와 강력하게 상관되었습니다 ($P(M|D) \approx 0.69\text{--}0.88$). 그러나 에이전트는 잘못된 진단을 하더라도 시스템을 반복적으로 관찰하고 튜닝함으로써 장애를 완화할 수 있었으나, 이는 덜 효율적이었습니다.

5. 의의 및 주장

본 논문은 SREGym 을 생산 준비가 된 에이전트형 SRE를 향한 기초적인 단계로 위치시킵니다.

• 현실성: 생산 환경의 "잡음"이 많고 "사건"이 많은 특성을 시뮬레이션함으로써, SREGym 은 정적 벤치마크보다 에이전트의 실제 배포 준비 상태를 더 정확하게 측정합니다.
• 커뮤니티 리소스: 오픈소스 확장 가능 프레임워크로서, 다양한 에이전트 아키텍처와 모델을 평가하기 위한 공통 기반을 제공함으로써 연구 가속화를 목표로 합니다.
• 한계: 저자들은 배포된 애플리케이션의 규모가 하이퍼스케일 생산 시스템에 비해 작다는 점, 단순화된 잡음 모델, 그리고 현재 소수의 에이전트 - 모델 쌍만 평가되었다는 점을 겸손하게 인정합니다. 그들은 SREGym 에서 높은 점수를 받는 것은 생산 안전을 위한 필요 조건이지만 충분 조건은 아니라고 강조합니다.

결론적으로, SREGym 은 최첨단 AI 에이전트가 SRE 작업에서 유망한 모습을 보이지만, 고신뢰도, 다계층, 잡음이 많은 장애 시나리오를 처리하는 데에는 여전히 상당한 격차가 있음을 보여줍니다. 이는 에이전트 신뢰성 엔지니어링의 지속적인 개발 필요성을 강조합니다.