파일은 맞혀도 원인은 못 짚는다: 분산 시스템 디버깅 에이전트 리뷰 — DistDebug-Bench

원문 정보

Yuxuan Jiang, Chenglin Liu, John Rose, Mason Miller, Ruthesh Thavamani, Juntao Wu, Yinwei Huang, Jiahao Xu, Peng Huang, "DistDebug-Bench: Can LLM Agents Diagnose Bugs in Distributed Systems?", arXiv:2611.03523 [cs.SE], 2026-11-02 제출. 소속: 미시간 대학교(University of Michigan). 벤치마크·평가기 공개(github.com/OrderLab/distdebug-bench), 트레이스·리더보드 공개(distdebug.com).

동료심사를 거치지 않은 프리프린트입니다. 자금 출처는 NAIRR Pilot 보조금(OpenAI API 크레딧 포함)과 NSF 보조금(CNS-2317698, CNS-2317751, CCF-2318937)입니다. OpenAI 쪽 크레딧을 받았지만 평가 대상에 GPT 계열뿐 아니라 Claude Opus 5.5, Gemini 3.5, DeepSeek, Kimi, MiMo, HY3 등 경쟁 모델을 폭넓게 포함했고 1위 모델(GPT-6 Astra)과 2위(Claude Opus 5.5)의 격차가 1.3%p에 불과해, 자금원이 결과를 왜곡했다고 볼 근거는 약합니다.

연구 개요

연구 질문은 "LLM 에이전트가 실제 분산 시스템 장애에서 수정 전 코드의 근본 원인 블록을 정확히 짚어낼 수 있는가"입니다. 기존 SWE-bench류 벤치마크는 테스트 스위트를 통과하는 패치 생성 여부만 채점해, 증상만 가린 패치와 실제 원인 수정을 구분하지 못한다는 한계가 있습니다. 데이터는 11개 널리 쓰이는 분산 시스템(ZooKeeper 등, 5개 프로그래밍 언어)에서 큐레이션한 실제 버그 120건, 정답 원인 블록 218개입니다. 방법론은 각 사례에 인시던트 리포트·증거(로그·스택트레이스)·수정 전 저장소 스냅숏을 주고 에이전트가 원인 코드 블록을 지목하게 한 뒤, 3인 독립 애노테이터가 교차 검증한 정답과 파일·함수·라인·블록 4단계로 대조합니다. 답 유출을 막기 위해 미래 커밋을 제거하고 이슈 식별자를 가린 리키지 가드도 함께 적용했습니다(GPT-5.4 기준 플래그 건수가 102/360건에서 4/360건으로 줄었습니다).

핵심 결과

표 지표는 평균치 기준입니다. 파일·함수·라인·블록은 각 단계의 커버리지(%)이고, 블록 커버리지가 이 벤치마크의 주 지표입니다. 플레이키(flaky)는 같은 버그를 세 번 반복했을 때 블록 커버리지 편차가 0.2를 넘는 비율입니다.

원문 Table 1, 120개 공통 버그 평균. 모든 설정에서 파일 커버리지가 블록 커버리지보다 15~25%p 높습니다 — "관련 파일에 도달"과 "정확한 원인 블록을 짚음" 사이의 간극입니다. 같은 GPT-5.2-Codex를 하니스만 바꿔 비교하면 Mini-SWE-Agent 56.4%, OpenCode 50.0%, Codex CLI 46.5%인데, 블록 정밀도는 반대로 Codex CLI(49.3%)가 가장 높고 Mini-SWE-Agent(43.1%)가 가장 낮습니다 — 하니스 선택이 재현율-정밀도 트레이드오프를 바꿉니다(원문 Table 1).

증거 품질에 따른 격차도 뚜렷합니다. 이슈 리포트에 원인 메서드명이 명시된 사례에서는 최고 구성이 블록 커버리지 94.8~95.8%에 도달하지만, 스택트레이스도 메서드명도 없는 "모호한" 사례(120건 중 50건, 이 중 42건은 스택트레이스 없음)에서는 65.0%로, 원인 위치가 다른 컴포넌트에 있는 교차 컴포넌트·모호 사례(7건)에서는 40.5%로 떨어집니다(원문 §4.2, 표본이 7건으로 작아 참고용). 고정 기준선인 Mini-SWE GPT-5.2-Codex에서는 이 격차가 82.8%→44.7%→14.3%로 더 큽니다.

신뢰도 평가

믿을 근거는 세 가지입니다. 첫째, 정답 레이블이 3인 독립 애노테이터 교차 검증을 거쳤습니다. 둘째, 벤치마크 유출을 막는 리키지 가드와 클로즈드북 검증을 함께 실행해, 이슈 식별자를 알려줘도 정답률 이득이 거의 없음(저장소 접근 없이 45.5%→21.4%, 식별자 공개 효과는 미미)을 보여 사전학습 유출 우려를 일부 완화했습니다. 셋째, 13개 모델×1개 하니스 + 2개 모델×3개 하니스 조합을 같은 120개 버그에 공통 적용해 모델·하니스 효과를 분리했습니다. 감안할 점은, 동료심사 전 초고이고 모든 수치가 신뢰구간 폭이 7~8%p로 넓어(표본 120건) 1~2%p 차이의 순위는 유의하지 않을 수 있다는 것입니다. 또한 평가 기준이 되는 "블록 커버리지"는 코드 영역 일치만 보므로, 저자들이 스스로 밝힌 대로 제로 커버리지 진단 20건을 블라인드 재감수한 결과 4건은 실제로는 다른 개입 지점을 정확히 짚었던 것으로 드러나(과소평가 가능성), 벤치마크 자체의 채점 보수성도 함께 감안해야 합니다.

관련 연구

• Jimenez et al.(2024, ICLR). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — 선행 연구(prior)이자 비교 대상. 12개 Python 저장소에서 뽑은 2,294건의 GitHub 이슈에 대해 테스트 스위트 통과 패치 생성을 채점합니다. DistDebug-Bench는 패치 성공이 아니라 원인 진단 자체를 직접 채점한다는 점에서 구분되며, 단일 프로세스 Python 프로젝트 대신 11개 분산 시스템·5개 언어로 범위를 넓혔습니다.
• Chen et al.(2025). AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds — 선행 연구(prior)이자 상호 보완 관계. 마이크로서비스에 장애를 주입하고 텔레메트리(지표·트레이스)를 기반으로 탐지·근본원인분석·완화까지 평가하는 48개 과제 프레임워크입니다. DistDebug-Bench는 텔레메트리가 아니라 소스코드 수준의 정밀 진단을 다뤄, 같은 "근본원인분석"이라는 말이 서로 다른 증거·정밀도 수준을 가리킴을 보여줍니다.
• Deng et al.(2025). SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? — 확장 연구(extension). 41개 저장소에서 뽑은 1,865건으로 과제 수와 소요 시간(수 시간~수일)을 늘렸고, 공개판 기준 GPT-5가 23.3%(Pass@1)로 최고 성적이었습니다. 과제 난도를 올렸지만 여전히 패치 성공을 채점한다는 점에서, DistDebug-Bench가 보완하는 "진단과 수정의 분리" 문제를 그대로 남겨 둡니다.

세 선행 연구를 종합하면, 기존 벤치마크들은 패치 성공(SWE-bench, SWE-Bench Pro) 또는 텔레메트리 기반 운영 대응(AIOpsLab)을 채점 대상으로 삼아 왔습니다. DistDebug-Bench는 이 사이의 빈틈 — 소스코드 수준에서 "왜 고쳤는가"를 직접 채점 — 을 메운다는 점에서 보완적이며, 세 선행 연구와 결론이 충돌하지는 않습니다.

리뷰어 판단

첫째, 이 벤치마크의 가장 실무적인 기여는 "파일 커버리지"와 "블록 커버리지"를 분리해 보여준 것이라고 판단합니다. 현재 벤더 발표나 리더보드는 대부분 패치 성공률 하나로 성능을 요약하는데, 83.9%와 67.7% 사이의 16%p 간극은 에이전트가 "관련 코드에 도달"하는 능력과 "정확한 원인을 짚는" 능력이 같지 않다는 것을 수치로 보여줍니다. 코드 리뷰·머지 게이트에 에이전트 진단을 넣는 팀이라면 이 간극을 전제로 설계해야 합니다.

둘째, 플레이키율(12~29%)이 이 논문에서 가장 과소평가되기 쉬운 수치라고 판단합니다. 같은 버그를 세 번 돌려 결과가 바뀌는 비율이 모델에 따라 최대 29%(HY3)에 달하는데, 실무에서는 보통 한 번만 돌려 결과를 확정합니다. 단일 실행 평가로 에이전트 역량을 판단하면 실제보다 낙관적이거나 비관적인 결론에 이를 위험이 있습니다.

셋째, GPT-5.5가 GPT-5.2-Codex보다 모호한 사례에서 15.4%p 더 개선했지만 블록 정밀도는 43.1%에서 34.7%로 떨어진 트레이드오프를 주목할 필요가 있다고 판단합니다. 더 강한 모델이 항상 더 쓸모 있는 진단을 내놓는 것은 아니며, 재현율을 높이는 대가로 틀린 블록을 더 많이 포함시킬 수 있다는 뜻입니다.

실무 적용

• 블록·함수 단위로 검수 기준 재설정 — "관련 파일을 열었다"가 아니라 정확한 원인 블록을 짚었는지로 에이전트 디버깅 결과를 승인합니다.
• 최소 3회 재시행으로 플레이키 확인 — 단일 실행 결과로 에이전트의 디버깅 신뢰도를 결론 내리지 않고, 편차가 큰 사례는 사람 검토로 넘깁니다.
• 증거 품질별 자동 에스컬레이션 — 스택트레이스나 원인 메서드명이 리포트에 없는 "모호한" 인시던트는 에이전트 단독 진단 대신 우선적으로 사람에게 넘깁니다.
• 하니스별 정밀도-재현율 특성 파악 후 선택 — 오탐 비용이 큰 운영 환경은 정밀도가 높은 하니스(Codex CLI류)를, 탐색 범위가 중요한 환경은 재현율이 높은 하니스를 고릅니다.
• 탐색 고정(tunnel vision) 방지 체크포인트 — 초기 탐색 두 파일 내에서 결론이 나지 않으면 가설을 재점검하도록 강제하는 중간 점검을 하니스에 넣습니다.

결론

DistDebug-Bench는 "에이전트가 관련 코드를 찾는가"와 "정확한 원인을 짚는가"를 분리해 측정함으로써, 현재 SOTA 에이전트가 전자에서는 80%대를 넘지만 후자에서는 60%대에 머문다는 것을 보였습니다. 증거가 빈약한 사례일수록 이 간극이 커지고, 같은 버그를 반복 실행해도 결과가 자주 바뀐다는 점까지 더하면, 디버깅 에이전트를 운영에 투입할 때는 평균 성공률 하나만 보고 판단하기 어렵습니다. 동료심사 전 초고이고 표본이 120건으로 신뢰구간이 넓다는 한계를 감안해, 수치는 방향 신호로 읽고 자체 코드베이스에서 재확인하는 것이 안전합니다. 머지 전 자동 승인 기준을 설계하는 운영 관점은 코딩 에이전트 완전통과율 게이트 설계 체크리스트에서 이어서 다룹니다.

참고 링크

• DistDebug-Bench: Can LLM Agents Diagnose Bugs in Distributed Systems? — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용
• SWE-bench(Jimenez et al., 2024) — 관련 연구 원문
• AIOpsLab(Chen et al., 2025) — 관련 연구 원문
• SWE-Bench Pro(Deng et al., 2025) — 관련 연구 원문
• 코딩 에이전트 완전통과율 게이트 설계 체크리스트 — sunny34.com 블로그