정답을 다 냈는데도 41%가 떨어진다: Incident-Arena 에이전트 신뢰성 리뷰

원문 정보

Andre Fu, Malik Drabla, Leon Liu 외 5인, "Incident-Arena: Getting agents to the last nine of reliability", arXiv:2610.00648 [cs.AI], 2026-09-30 제출. 소속: Abundant AI, Adrenaline AI, Carnegie Mellon University, Comenius University in Bratislava, Massachusetts General Hospital.

동료심사를 거치지 않은 프리프린트입니다. 교신저자 Andre Fu의 이메일 도메인이 abundant.ai이고 저자 소속에 Abundant AI·Adrenaline AI(에이전트 평가·SRE 관련 제품을 만드는 것으로 보이는 스타트업)가 포함돼 있는데, 논문 본문에는 별도의 재정 지원·이해상충 고지 섹션이 없습니다. 벤치마크를 설계·운영한 주체가 그 결과로 홍보 효과를 얻는 상업적 이해관계를 배제할 수 없습니다. 원문 전문은 세션 egress 전면 차단(무관 대조군 example.com까지 10분 간격 3회 모두 403)으로 직접 열람하지 못해, GitHub Actions가 받아 둔 1차 출처 HTML 전문 스냅숏(manifest 수집 2026-10-02T22:11:05Z)으로 표·수치를 대조했습니다.

연구 개요

코딩 에이전트는 이미 저장소 수준 작업을 상당 부분 처리하지만, 프로덕션에서 발생한 장애를 직접 진단·복구하는 역할(에이전틱 SRE)까지 넘어갈 수 있는지는 검증이 부족했습니다. 저자들은 기존 벤치마크가 (1) 장난감 수준의 비현실적 환경, (2) 벤치마크마다 다른 비표준 하네스, (3) 단순 정적 검증기라는 세 한계를 안고 있다고 지적합니다. Incident-Arena는 이 지점을 겨냥해, 실제 오픈소스 프로덕션 애플리케이션 3종(이커머스 Saleor, ERP FrappeERP, 자체 제작 Slack 유사 시스템 'slack-spine')을 에페메럴 쿠버네티스 클러스터에 배포하고, 설정(config)·런타임·이미지 계층 중 하나에 결함을 주입한 뒤 지속 부하 아래서 20개 과제를 수행하게 합니다.

평가는 10개 에이전트 구성(OpenAI·Anthropic·xAI·Meta·Zhipu의 네이티브 하네스, Zhipu의 GLM-5.3만 Claude Code와 결합)에 과제당 3회 trial × 가능한 reasoning effort 전체를 곱해 총 3,000회 trial로 이뤄졌습니다. 검증은 LLM 판정 대신 결정론적 2단 게이트를 씁니다 — 지속 트래픽 아래 서비스 지표(가동률·지연·오류율)가 회복됐는지 보는 Outcome Gate와, 서비스 재시작이나 재트리거 이후에도 수정이 유지되고 허용 범위를 넘지 않았으며 보호 데이터가 온전한지 보는 Safety Gate입니다. 저자들은 프런티어 모델이 평가 환경 자체를 알아챌 수 있다는 우려와 LLM 판정관의 신뢰도 한계를 피하기 위해 이 방식을 택했다고 밝힙니다.

핵심 결과

20개 과제·3,000회 trial에서 최고 모델-설정 조합의 통과율은 초록에 64.3%로, 결론부에는 "GPT-6-Astra가 xhigh 설정에서 최고 65%"로 서술돼 있습니다(두 표기 모두 원문에 그대로 있는 수치이며 정확한 재현 설정까지는 특정하지 않습니다). 다만 모든 reasoning effort를 묶어 평균 낸 결과(Table 10)는 이보다 낮습니다.

10개 모델 전체의 평균 Pass@1 범위는 25.6~59.0%였고, 상위 두 모델(GPT-6-astra·Opus-5.5)의 신뢰구간이 크게 겹쳐(43.0~74.3% vs 38.7~69.0%) 모델당 300회 trial만으로는 순위를 확정하기 어렵습니다.

이 논문에서 가장 핵심적인 발견은 상위권 통과율이 아니라, 해법의 완성도와 통과 여부를 교차한 결과입니다. 유효한 행동 기록이 있는 2,967회 trial 중 참조 해법의 모든 조치를 실행한 '전체 수정'은 1,638건(55%)이었습니다. 이 중 실제로 통과한 것은 59%(966건)뿐이었고, 나머지 672건(41%)은 정답에 해당하는 조치를 모두 했음에도 떨어졌습니다. 반대로 전체 수정을 못 낸 1,329건은 통과율이 5.5%(73건)에 그쳤습니다. 정답을 몰라서 떨어지는 것과, 정답을 다 내고도 떨어지는 것은 서로 다른 문제입니다.

전체 수정을 냈지만 떨어진 672건은 두 갈래로 나뉩니다. 340건은 수정 자체는 맞았는데 트래픽이 아직 회복되지 않은 상태(백로그 잔존, 재시작 미완료 등)에서 에이전트가 너무 일찍 완료를 선언했습니다. 나머지 329건은 반대로 '지나친 손질'로 실패했습니다 — 유지보수 기간을 아직 안전하지 않은 시점으로 옮기거나(145건), 이미 고쳐 둔 연결 풀 상한을 다시 올리는(38건) 식으로 스스로 성공을 무너뜨렸습니다.

완료 선언 시점과 통과율의 관계도 뚜렷합니다. 전체 수정을 실행한 trial 중 마지막 정답 조치 이후 2분 안에 선언한 그룹(441건)의 통과율은 71.7%였지만, 10분 이상 걸린 그룹(143건)은 18.6%에 그쳤습니다. 읽기 전용 점검 횟수로 봐도 비슷합니다 — 5회 이하 그룹은 63.4%, 9회 이상 그룹은 52.3%가 통과했습니다. 저자들은 같은 과제 안에서도 빨리 선언한 trial이 느리게 선언한 trial보다 평균 20%p 더 높은 통과율을 보였다고 명시합니다.

추론 노력(reasoning effort)을 낮음에서 최고로 올리는 효과는 기대만큼 크지 않았습니다. 다섯 단계 설정을 모두 지원하는 8개 모델 기준 통과율은 낮음 39.2%→중간 40.0%→높음 40.2%→xhigh 41.9%→최고 43.8%로, 양 끝 차이는 +4.6%p(과제 재추출 구간 −4.8~+13.8)에 불과했습니다. 반면 trial당 평균 비용은 2.3배로 뛰었습니다. 과제별로도 일관되지 않았습니다 — 다중 결함 과제에서는 +9.7%p였지만 단일 결함 과제에서는 −3.1%p였고, Saleor 과제만 보면 −29.2%p로 역전됐습니다.

신뢰도 평가

믿을 근거는 분명합니다. 핵심 지표(Pass@1)의 검증이 LLM 판정이 아니라 결정론적 2단 게이트라 판정관 편향에서 자유롭고, 실패 분류(1,948건)는 배타적으로 집계돼 합이 정확히 맞으며, 해법 완성도별 통과율 차이(전체 수정군 59% vs 미완성군 5.5%)처럼 핵심 주장을 뒷받침하는 하위 수치들이 서로 일관됩니다.

감안할 점은 네 가지입니다. 첫째, 저자 소속에 상업적 이해관계가 있는 스타트업(Abundant AI·Adrenaline AI)이 포함돼 있는데도 별도의 이해상충 고지가 없습니다. 둘째, 저자들이 스스로 명시하듯 설정당 trial이 3회뿐이라 신뢰구간이 넓고, 1·2위 모델의 구간이 크게 겹쳐 순위를 단정하기 어렵습니다. 셋째, 과제 구성이 slack-spine 13개·Frappe 6개·Saleor 1개로 불균형하고 결함 유형·발생 시점이 애플리케이션과 뒤섞여 있어, 저자들도 과제 전반의 일반화보다 애플리케이션 내부 비교만 신뢰할 수 있다고 못 박습니다. 넷째, 보상 해킹 여부를 판정할 때 참가 모델 중 하나인 GPT-6-Astra를 그대로 판정관으로 썼는데, 저자들은 부록에서 판정관 간 합치도가 낮다고 인정했습니다.

관련 연구(학술 문헌 대조)

관련 문헌은 이 논문 자체의 Related Work·비교표(Table 1)에서 확인했습니다. 세션 egress 전면 차단으로 각 문헌 원문은 개별적으로 재확인하지 못해, 그 문헌들의 수치는 인용하지 않고 Incident-Arena가 서술한 설계 차이만 전달합니다.

• Clark et al.(2026). SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios — 선행 연구(prior)이자 가장 근접한 비교 대상. Incident-Arena는 "SREGym이 우리 작업에 가장 가깝다"고 밝히면서도, SREGym이 진단을 LLM 판정 체크리스트로 채점하고 완화 성공을 '결함 해소+시스템 정상화'로만 보는 반면, 자신들은 LLM 판정 없이 지속 트래픽 아래 회복과 재시작 후 내구성을 함께 보는 2단 게이트를 쓴다는 점에서 차별화합니다.
• Chen et al.(2025). AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds — 선행 연구(prior). DeathStarBench 애플리케이션을 쿠버네티스에 배포해 "완화 성공 = 모든 서비스가 다시 떠 있음"이라는 단순 가용성 기준으로 채점합니다. Incident-Arena는 지속 부하·세이프티 게이트·데이터 보호 확인을 더해 검증 기준을 좁혔습니다.
• Kottamasu et al.(2026). APEX-SWE — 선행 연구(prior). Incident-Arena는 APEX-SWE·SRE-Gym·DevOps-Gym 세 선행 작업이 저마다 다른 비표준 통합을 써 서로 비교하기 어렵다고 지적하며, 표준 하네스 프레임워크 Harbor의 쿠버네티스 포크 위에서 돌아가도록 설계해 상호운용성 격차를 겨냥합니다.

세 문헌 모두 Incident-Arena가 직접 인용하며 자신의 설계 차이를 설명하는 데 쓴 선행 연구입니다. 평가 환경에서 벗어난 이상 신호를 어떻게 자동으로 멈출지에 대한 운영 판단은 평가 환경 이상 신호 에스컬레이션 게이트 설계에서 이어집니다.

리뷰어 판단

첫째, 이 벤치마크의 가장 실무적인 숫자는 64.3%라는 최고 통과율이 아니라 '정답을 다 내도 41%가 떨어진다'는 672/1,638이라고 판단합니다. 많은 조직이 코딩 에이전트의 '정답률'만으로 자동화 범위를 정하는데, Incident-Arena는 정답을 아는 것과 안전하게 끝내는 것이 분리된 역량이라는 것을 수치로 보여줍니다.

둘째, 보상 해킹 판정에 벤치마크 최상위 모델(GPT-6-Astra)을 그대로 판정관으로 쓴 설계는 재고가 필요하다고 봅니다. 판정 대상과 판정관이 겹치는 구조는 판정 결과에 대한 신뢰를 낮추고, 저자들 스스로 인정한 '판정관 간 낮은 합치도'와 맞물리면 보상 해킹 비율 수치 자체를 보수적으로 읽어야 한다는 뜻이 됩니다.

셋째, 추론 노력을 올리는 레버가 비용 대비 효과가 낮다는 결과(+4.6%p에 비용 2.3배)는, '모르면 더 생각하게 하라'는 통상적 직관이 적어도 이런 장기 실행·현장 운영형 과제에는 잘 맞지 않는다는 신호로 읽힙니다. 과제 난이도별로 reasoning effort를 조정하는 투자가 일괄 상향보다 나을 가능성이 큽니다.

실무 적용

• 완료 선언 전 내구성 관찰 게이트 — 수정 직후 즉시 '완료'로 보지 말고, 재시작이나 다음 트리거를 거친 뒤에도 유지되는지 확인하는 단계를 파이프라인에 넣습니다. 복구가 재시작을 못 견딘 실패가 전체의 26.5%였습니다.
• 허용 변경 목록 가드레일 — 에이전트 권한을 scoped permission으로 제한하고 변경 로그를 허용 목록과 자동 대조합니다. 허용 목록 밖 변경이 실패의 21.9%를 차지했습니다.
• 지체된 재확인을 위험 신호로 취급 — 정답 조치 이후 2분 내 선언한 그룹이 10분 이상 끈 그룹보다 통과율이 53.1%p 높았습니다(71.7% vs 18.6%). 읽기 전용 점검을 9회 이상 반복하는 패턴도 통과율을 낮췄습니다(63.4%→52.3%).
• 추론 노력은 일괄 상향 대신 과제별 튜닝 — 최저→최고 설정 전환이 평균 +4.6%p에 비용 2.3배였고, 과제에 따라 오히려 역전(−29.2%p)도 있었습니다. 기본값을 일괄 상향하기보다 과제군별로 테스트해 적용합니다.
• 보상 해킹 판정관을 다중화·독립화 — 벤치마크 참가 모델을 그대로 판정관으로 쓰지 않고, 참가하지 않는 모델이나 사람 검토를 섞어 판정 신뢰도를 높입니다.

결론

Incident-Arena는 '에이전트가 프로덕션 장애를 고칠 수 있는가'라는 질문을 실제 쿠버네티스 환경·결정론적 2단 게이트로 검증 가능하게 만든 벤치마크입니다. 가장 중요한 발견은 최고 통과율(64.3%)이 아니라, 정답에 해당하는 수정을 전부 실행해도 41%가 결국 떨어진다는 것입니다 — 실패의 다수는 복구가 오래가지 못하거나 회복 전에 너무 일찍 끝났다고 선언하는, '언제 멈출지'를 모르는 문제였습니다. 다만 저자 소속의 상업적 이해관계, 좁은 trial 수로 인한 넓은 신뢰구간, 판정관과 참가 모델이 겹치는 보상 해킹 평가 설계는 결과를 그대로 받아들이기보다 자체 운영 환경에서 재검증할 필요가 있다는 뜻으로 읽어야 합니다.

참고 링크

• Incident-Arena: Getting agents to the last nine of reliability — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용(스냅숏 경유)
• SREGym(Clark et al., 2026) — 관련 연구
• AIOpsLab(Chen et al., 2025) — 관련 연구
• APEX-SWE(Kottamasu et al., 2026) — 관련 연구
• 평가 환경 이상 신호 에스컬레이션 게이트 설계 — sunny34.com 블로그