ORCA-bench, 온콜 에이전트의 현실 점수를 공개하다

온콜은 코딩 벤치마크가 아니다

ORCA-bench 논문은 LLM 에이전트 평가를 운영 장애 현장으로 끌고 온다. 연구진은 코드 작성이나 patch 생성이 아니라 root cause analysis, 즉 온콜 엔지니어가 하는 원인 분석을 평가했다. 문제는 더 모호하다. 사용자는 애매한 장애 리포트를 남기고, 사고는 이미 몇 시간 전에 시작됐으며, 로그와 지표와 trace와 소스코드는 동시에 봐야 한다.

논문은 OpenTelemetry가 붙은 microservice 시스템, Prometheus, Jaeger, OpenSearch via Grafana, 전체 소스코드 접근, 6일치 관측 데이터를 구성했다고 설명한다. 과제는 1,079개이고, 데이터 규모는 50GB다. 사람 SRE가 ground truth 증상을 큐레이션했고 LLM-as-judge 결과도 사람이 재채점해 Cohen kappa 0.90을 보고했다. MAI-Cyber-1-Flash, 보안 AI의 비용 전쟁이 보안 모델의 가격을 봤다면, ORCA는 운영 문제의 난도를 본다.

최고 성능도 아직 낮다

가장 중요한 숫자는 차갑다. 논문 초록 기준 다섯 frontier agent 중 최고 RCA Accuracy는 Medium 난이도에서 25.3%, Hard 난이도에서 10.0%였다. 가장 약한 모델은 incident report의 40%에서 그럴듯하지만 말이 안 되는 root cause를 환각했다. 소스코드 접근을 제거하면 모든 metric이 나빠졌다.

이는 모델이 못났다는 단순한 이야기가 아니다. 실제 온콜은 지저분한 데이터 통합 문제다. OpenTelemetry, Prometheus, Grafana, Jaeger는 각각 다른 관찰 창을 제공한다. 에이전트는 이 창들을 오가며 시간 범위, 배포 이력, 증상과 원인을 분리해야 한다. 코드 검색만 잘하는 에이전트로는 부족하다.

사람을 대체하기보다 triage를 좁혀야 한다

ORCA-bench가 공개한 public set은 에이전트 벤치마크가 더 현실적인 방향으로 가고 있음을 보여준다. 그러나 결과는 단독 온콜 자동화가 이르다는 쪽에 가깝다. 최고 성능 25.3%는 좋은 데모를 만들 수는 있어도, 새벽 3시에 production rollback을 맡기기에는 낮다.

실무적으로는 에이전트를 RCA 최종 판단자가 아니라 triage 압축기로 쓰는 편이 맞다. 의심 서비스, 관련 배포, 증상이 시작된 시간, 상관 로그, 반례 지표를 묶어 사람에게 넘기는 방식이다. Codex Security 오픈소스, 보안 리뷰의 새 기준처럼 보안 리뷰도 자동 제안과 사람 확인이 함께 갈 때 가치가 커진다.

한국 SRE 팀의 도입 순서

한국 기업은 온콜 자동화를 모델 구매로 시작하기 쉽다. 하지만 먼저 할 일은 관측 데이터 표준화다. trace id가 로그와 연결되는지, 배포 이벤트가 시간축에 남는지, 대시보드 쿼리를 API로 호출할 수 있는지, 장애 리포트가 구조화되는지 확인해야 한다. 에이전트가 볼 수 없는 데이터는 추론할 수 없다.

두 번째는 권한이다. 온콜 에이전트가 production 로그를 읽고, incident channel에 쓰고, runbook을 수정하고, rollback을 제안할 수 있다면 각 권한은 분리되어야 한다. 과학 코드로 들어간 에이전트, 검증이 핵심이다에서처럼 검증 가능한 산출물을 요구해야 한다. 로그 링크, metric query, 시간 범위, 대안 가설을 남기지 않는 답은 운영 판단으로 쓰면 안 된다.

자주 묻는 질문

Q1: ORCA-bench는 무엇을 평가하나요?

A: production에 가까운 microservice 환경에서 LLM 에이전트가 장애 원인을 찾는 능력을 평가한다.

Q2: 왜 정확도가 낮나요?

A: 온콜은 코드 검색뿐 아니라 noisy telemetry, 시간 지연, 동시 장애, 애매한 사용자 리포트를 함께 다뤄야 하기 때문이다.

Q3: 에이전트를 온콜에 쓰면 안 되나요?

A: 쓸 수는 있다. 다만 최종 판단자가 아니라 증거 수집, 후보 원인 정리, runbook 제안 역할부터 시작해야 한다.

Q4: 소스코드 접근이 왜 중요한가요?

A: 로그와 지표만으로 증상을 볼 수는 있지만, 실제 원인을 확인하려면 코드 경로와 배포 변경을 함께 봐야 하기 때문이다.

Q5: 한국 팀의 첫 단계는 무엇인가요?

A: OpenTelemetry 기반 trace-log-metric 연결, 배포 이벤트 기록, read-only observability API, 사람 승인 workflow부터 갖추는 것이다.