기술 요약: ORCA-BENCH: 언어 모델 에이전트는 온콜(Oncall)을 수행할 준비가 되었는가?

문제 정의

대규모 언어 모델(LLM)은 정적 저장소 내에서 코드를 작성하고, 패치하고, 검색하는 데는 능숙함을 보여주었으나, 실제 운영 중인 라이브 프로덕션 시스템의 신뢰성을 관리하는 능력은 아직 입증하지 못했다. 사이트 신뢰성 공학(SRE) 맥의 근본 원인 분석(RCA)은 전통적인 소프트웨어 엔지니어링 벤치마크와는 근본적으로 다르다. 프로덕션 환경에서 온콜 엔지니어는 인시던트가 시작된 지 몇 시간이 지난 후, 모호한 자연어 보고서(예: "사용자들이 문제를 겪고 있음")를 받게 된다. 엔지니어는 라이브 마이크로서비스 메쉬의 노이즈가 섞인 동적인 메트릭, 로그, 트레이스 스택을 바탕으로 추론하여 특정 기능, 배포 또는 컴포넌트의 장애를 식별해야 한다. 기존 벤치마크들은 합성된 결함을 사용하거나, 로우(raw) 텔레메트리 인터페이스 또는 소스 코드에 대한 접근 권이 부족하거나, 사용자 보고의 구체성과 탐지 시간(TTD)을 체계적으로 변화시키지 않는다는 점에서 이러한 복잡성을 포착하는 데 실패한다.

방법론

저자들은 범용 코딩 에이전트를 프로덕션 수준의 온콜 환경에서 평가하기 위해 설계된 벤치마크인 ORCA-bench를 소개한다. 이 방법론은 네 가지 핵심 구성 요소로 이루어져 있다.

1. 환경 (전체 증거 스택)

ORCA-bench는 6일간의 연속적인 시뮬레이션 사용자 부하가 실행되는, OpenTelemetry로 계측된 라이브 마이크로서비스 시스템("Astronomy Shop")을 활용한다. 로우 CSV 파일이나 커스텀 도구를 제공하는 이전 연구들과 달리, ORCA-bench는 현실적인 인터페이스를 통해 전체 증거 스택을 노출한다:

• 메트릭(Metrics): Prometheus를 통해 접근.
• 로그(Logs): OpenSearch를 통해 접근.
• 트레이스(Traces): Jaeger를 통해 접근.
• 인터페이스: 모든 텔레메트리는 Grafana API를 통해 쿼리됨.
• 소스 코드: 터미널을 통해 시스템의 전체 소스 코드에 대한 접근 권한이 제공됨.
  데이터셋은 13개의 서로 다른 언어로 작성된 19개의 마이크로서비스를 포함하며, 6일간의 데이터를 아우르는 50GB 규모이다.

2. 태스크 생성 및 스케줄

이 벤치마크는 합성된 결함을 주입하는 대신 11개의 실제 피처 플래그(feature flags)를 토글함으로써 1,079개의 RCA 태스크를 생성한다. 태스크는 고립형, 독립형, 충돌형, 연쇄형, 순차형 결함 유형을 포함하는 13개의 시나리오를 중심으로 6일간의 스케줄에 따라 구조화된다.

• 가변적 구체성(Variable Specificity): 태스크는 정확한 에러 메시지부터 "사용자들이 사이트 이슈를 보고하고 있다"와 같은 모호한 보고에 이르기까지 "이슈 구체성"(Easy, Medium, Hard)에 따라 달라진다.
• 탐지 시간(TTD): 인시던트 발생 시점과 조사 시작 시점 사이의 시간은 15분에서 24시간까지 다양하다.
• 보고 시간(Report Time): 사용자가 문제를 보고하는 시간은 정확한 시점, 정확한 범위, 넓은 범위로 파라미터화되어 실제 세계의 모호함을 시뮬레이션한다.
• 제어 태스크(Control Tasks): 195개의 태스크는 활성화된 인시던트가 없는 "제어" 태스크로, 문제가 없음을 올바르게 식별하는 에이전트의 능력을 테스트한다.

3. 그라운드 트루스(Ground Truth) 큐레이션

그라운드 트루스는 전문 SRE들에 의해 큐레이션되고 승인된다.

• 증상(Symptoms): 프론트엔드 증상은 브라우저에서 피처 플래그를 재현함으로써 검증된다. 텔레메트리 증상(메트릭, 로그, 트레이스)은 두 명의 전문 SRE에 의해 검증된 반자동 워크플로우를 통해 수집된다.
• 근본 원인(Root Causes): 각 태스크에 대해 그라운드 트루스는 사용자 측 이슈를 설명할 수 있는 가능한 근본 원인의 집합(발생 시간 동안 활성화된 피처 플래그들)으로 정의된다.
• 검증: 40개의 태스크로 구성된 하위 집합("ORCA-bench Verified")은 모든 그라운드 트루스 레이블과 모델별 점수가 인간에 의해 수동으로 확인되었다.

4. 평가 프레임워크

평가는 LLM-as-a-judge (GPT-5.4)를 사용하여 에이전트의 보고서를 채점하며, 정렬(alignment)을 보장하기 위해 Verified 하위 집합에 대해 인간의 재채점 과정을 거친다 (Cohen's $\kappa_w = 0.90$).

• 채점 루브릭(Scoring Rubric): 보고서는 가능한 각 근본 원인에 대해 0–3 척도로 채점되며, 에이전트가 증상을 확인했는지, 특정 텔레메트리 신호를 식별했는지, 그리고 메커니즘을 정확히 명명했는지를 평가한다.
• 지표:
  • RCA 정확도(RCA Accuracy): 에이전트가 나열된 모든 가능한 근본 원인을 모두 지목한 태스크의 비율.
  • RCA 깊이(RCA Depth): 모든 루브릭에 대한 평균 점수(0–3)로, 에이전트가 근본 원인에 얼마나 도달했는지를 나타낸다.
  • 환각률(Hallucination Rate): 비어 있지 않은 보고서 중 에이전트가 가능한 원인 중 어느 것과도 일치하지 않는 근본 원인을 지목한 비율.

주요 결과

논문은 다섯 가지 프런티어 에이전트(Opus 4.7, Sonnet 4.6, GPT-5.5, GLM-5, DeepSeek-V4-Pro)를 이 벤치마크로 평가한다.

• 낮은 전반적 성능: 가장 우수한 성능을 보이는 모델조차 고전한다. 중간 난이도(Medium-difficulty) 태스크(현실적인 입력 설정)에서 최상의 RCA 정확도는 **25.3%**이다. 높은 난이도(Hard) 태스크에서는 정확도가 **10.0%**로 떨어진다.
• 높은 환각률: 에이전트들은 빈번하게 타당하지 않은 근본 원인을 환각한다. 환각률은 DeepSeek-V4-Pro의 7%에서 GLM-5의 40%까지 분포한다.
• 컨텍스트 제거의 영향: 소스 코드 접근 권한을 제거하면 모든 지표에서 성능이 저하된다. RCA 정확도는 9~16 퍼센트 포인트 하락하며, 환각률은 크게 급증한다.
• 텔레메트리 검색 문제: 에이전트들은 텔레메트리를 효과적으로 쿼리하는 데 어려움을 겪는다. 최대 40%의 텔레메트리 호출이 에러를 발생시키거나 빈 결과를 반환한다. GPT-5.5가 가장 효율적이며, 다른 모델들은 필요한 데이터를 검색하는 데 자주 실패한다.
• 실패 모드: 에이전트들은 배경 노이즈(크지만 무관한 증상)에 주의가 분산되는 경향이 있으며, 여러 이슈가 동시에 발생할 때 모든 근본 원인을 철저히 찾아내는 데 어려움을 겪는다. 또한 심각도 증가를 일관되게 정량화하거나 이를 별개의 이벤트로 귀속시키는 데 실패한다.
• Claude Fable 5: 일부 태스크에서 Claude Fable 5는 더 높은 점수(Verified 태스크에서 깊이 58.2%, 정확도 40.6%)를 기록했으나, 여전히 완벽한 신뢰성에는 미치지 못했으며, 이 이득은 주로 쉬운 태스크보다는 중간 난이도 태스크에서 나타났다.

의의 및 주장

저자들은 ORCA-bench를 언어 모델 에이전트에게 실시간 OpenTelemetry 계측 시스템을 엔드 투 엔드로 노출하여, 실제 텔레메트리 인터페이스, 로우 시그널, 그리고 소스 코드를 프로덕션 스타일의 모호함과 결합하여 제공하는 최초의 SRE 벤치마크라고 규정한다.

이 논문의 주요 주장은 프런티어 코딩 에이전트들이 아직 온콜을 수행할 준비가 되지 않았다는 것이다. 보고된 성능 격차(예: 중간 난이도 태스크에서의 25.3% 정확도)는 에이전트에게 프로덕션 신뢰성을 안전하게 위임하기 전에 필요한 엔지니어링 투자의 하한선으로 제시된다. 저자들은 실제 프로덕션 시스템이 여기서 사용된 50GB 테스트베드보다 수십 배 더 크고, 역동적이며, 특이적일 것이라고 주장한다. 또한, 이 벤치마크의 단순화(고정된 코드베이스, 격리된 태스크, 액션 루프의 부재)를 고려할 때, 실제 상황에서의 격차는 훨씬 더 클 것이라고 주장한다.

이 연구는 현재의 에이전트들이 모호하고 지연된 인시던트 보고를 처리하기 위해 소스 코드와 함께 노이즈가 섞인 다중 모드 텔레메트리 데이터를 추론하는 능력이 부족함을 강조하며, 이는 자율적인 시스템 신뢰성을 위한 필수 전제 조건이다.