코드는 고치는데 장애 원인은 못 찾아

“코드를 짜고 고치는 건 되는데, 새벽에 온 알림 하나로 원인을 짚는 건 다른 일이야.”

ORCA-bench 논문이 잡은 문제가 그거야. 프런티어 에이전트 5종을 실제로 돌아가는 시스템에 붙여 원인 분석을 시켰더니, 중간 난도 과제에서 최고 정답률이 25.3%였어. 어려운 난도에서는 10.0%까지 떨어졌고.

7월 30일 arXiv에 올라온 논문이야. 세운 모델은 Claude Opus 4.7, Claude Sonnet 4.6, GPT-5.5, GLM-5, DeepSeek-V4-Pro고, 논문은 중간 난도를 실제 운영에 가장 가까운 입력 조건이라고 불러.

환경을 진짜 온콜처럼 만들었어

  • 살아 있는 시스템: 실제로 돌아가는 마이크로서비스를 놓고, 소스 코드 전체를 볼 수 있게 열어 뒀어.
  • 6일치 관측 데이터: 지표, 로그, 트레이스를 합쳐 50GB야. Prometheus, Jaeger, OpenSearch/Grafana 같은 평소 쓰는 도구로 조사해.
  • 모호한 출발점: 과제는 정리된 오류 메시지가 아니라 사용자가 올린 신고에서 시작해. 장애가 시작되고 몇 시간 지난 뒤부터 붙는 상황도 들어 있어.

과제는 1,079개인데, 그중 195개는 아예 장애가 없는 대조군이야. 없는 원인을 만들어 내는지 보려고 넣은 거지. 나머지는 쉬움 288개, 중간 316개, 어려움 280개로 갈라 놓고 신고가 얼마나 구체적인지, 탐지까지 얼마나 걸렸는지, 장애가 겹쳤는지를 바꿔 가며 짰어.

틀리는 것보다 지어내는 게 문제야

낮은 정답률만큼 눈에 걸리는 값이 하나 더 있어. GLM-5는 자기가 쓴 장애 보고서의 40%에 근거 없는 원인을 적었어. 같은 지표에서 DeepSeek-V4-Pro는 7%였으니까, 모델에 따라 다섯 배 넘게 벌어져.

이건 정답률과 성격이 달라. 못 찾았으면 사람이 이어서 보면 되는데, 그럴듯한 원인을 지어내면 사람이 그걸 따라가느라 시간을 더 쓰게 되거든. 채점 자체는 흔들리지 않았어. 채점자 간 일치도가 가중 카파 0.90이라 기준은 안정적인 편이야.

코드를 안 보면 더 떨어지는데 잘 안 봐

논문이 실험을 하나 더 했어. 소스 코드 접근을 없앴더니 모든 모델에서 정답률이 9~16포인트씩 떨어졌어. 그런데 정작 에이전트들이 코드 탐색에 쓴 명령은 전체의 16~20%밖에 안 돼.

없으면 확실히 나빠지는데 있어도 잘 안 쓴다는 뜻이야. 도구를 더 붙이는 것보다 있는 도구를 언제 쓸지 정해 주는 게 먼저인 상황이야.

온콜에 에이전트를 붙일지 보는 팀이 볼 것

  • 어디까지 맡길지 잘라: 원인 확정을 맡기는 대신 관련 로그·트레이스 수집과 후보 정리까지만 맡기는 구간 분리가 지금 숫자에 맞는 선이야.
  • 출력 형식을 먼저 걸어: 근거 없는 서술이 모델에 따라 40%까지 나오는 조건이라면, 보고서에 근거 링크를 필수로 요구하는 형식이 사람 검토 시간을 줄여.
  • 성적을 옮겨 읽지 마: 이건 코드 수정 벤치마크가 아니야. SWE-Bench 계열 점수가 높다고 온콜 원인 분석도 될 거라고 보면 안 돼.

아직 arXiv 프리프린트 v1이고, 벤치마크 설계와 실행을 저자들이 직접 했어. 다른 팀의 재현 기록도 아직 없어. 그래도 “에이전트가 장애 대응까지 한다”는 얘기를 들었을 때 뭘 물어봐야 하는지는 이 논문이 꽤 구체적으로 알려 줘.