Hugging Face에 공개된 ITBench-AA는 AI 에이전트를 운영 업무에 쓰려는 팀이 꼭 봐야 할 벤치마크입니다. 이유는 단순합니다. 최신 frontier model도 Kubernetes 기반 SRE 장애 대응 과제에서 50%를 넘지 못했습니다. AI가 코드를 잘 쓰는 것과 운영 장애의 root cause를 정확히 찾는 것은 다른 문제라는 점을 숫자로 보여줍니다.
Artificial Analysis와 IBM Software Innovation Lab이 공개한 ITBench-AA는 enterprise IT task를 평가하는 benchmark series의 시작점입니다. 첫 범위는 SRE입니다. 모델은 Kubernetes incident snapshot을 받고 로그, trace, metric, event, topology를 확인해 장애를 일으킨 최소 root-cause entity를 찾아야 합니다. 제출은 Kubernetes Deployment, Service, Pod, NetworkPolicy 같은 entity 목록으로 합니다.
결과는 꽤 냉정합니다. Claude Opus 4.7 Adaptive Reasoning Max Effort가 47%, GPT-5.5 xhigh가 46%, Qwen3.7 Max가 42%로 상위권이지만 모두 50% 미만입니다. open-weight 모델 중에서는 GLM-5.1 Reasoning이 40%, Gemini 3.5 Flash high와 사실상 비슷한 수준으로 소개됐습니다.
SRE 장애 대응은 답을 생성하는 문제가 아니라 증거를 좁히는 문제입니다. 로그에는 원인과 증상이 섞여 있습니다. trace에는 실패 경로가 보이지만 최초 원인이 아닐 수 있습니다. Kubernetes event에는 rollout 실패와 resource quota, network policy, connection pool exhaustion 같은 여러 신호가 동시에 나올 수 있습니다.
사람 SRE도 처음부터 정답을 알지 못합니다. alert를 보고 시간대를 좁히고, topology를 따라가고, 로그와 metric을 대조하고, 마지막에 root cause를 특정합니다. AI 에이전트가 이 과정을 하려면 shell 명령을 적절히 실행하고, 관찰한 내용을 기억하고, false positive를 줄여야 합니다.
ITBench-AA가 중요한 이유는 바로 이 false positive를 벌점으로 본다는 점입니다. root cause를 포함해도 관련 없는 entity를 같이 제출하면 precision이 떨어집니다. 실제 운영에서도 ‘이것도 문제일 수 있다’를 많이 던지는 에이전트는 도움이 되기보다 소음을 만듭니다.
ITBench-AA SRE는 59개 과제로 구성됩니다. 이 중 40개는 public task, 19개는 held-out task입니다. 각 task는 sandboxed filesystem에 로그와 snapshot을 제공하고, 모델은 open-source Stirrup reference harness에서 shell 접근 권한을 사용합니다. 각 task는 100 turn cap이 있고, 3회 반복 평가됩니다.
채점은 average precision at full recall입니다. 모델이 ground truth root cause 중 하나라도 놓치면 해당 repeat 점수는 0입니다. 모든 root cause를 찾았을 때는 제출 목록 중 실제 root cause 비율로 점수를 받습니다. 즉 정답 2개를 모두 찾고 오답 2개를 더 넣으면 precision은 50%가 됩니다.
이 방식은 운영 현실과 맞습니다. 장애 대응에서 빠진 root cause는 치명적입니다. 동시에 불필요한 entity를 많이 넣으면 rollback, scaling, 설정 변경 같은 조치가 엉뚱한 곳으로 향합니다. AI 에이전트 평가도 ‘많이 말하기’가 아니라 ‘최소 원인을 정확히 말하기’로 봐야 합니다.
공개 결과에서 흥미로운 점은 turn count입니다. GPT-5.5 xhigh는 평균 31 turn으로 46%를 기록한 반면, Gemini 3.1 Pro Preview는 평균 83 turn을 쓰고 30%에 그쳤다고 소개됐습니다. 더 오래 조사한다고 더 정확해지는 것이 아닙니다.
이건 실제 에이전트 운영에서도 자주 보입니다. 모델이 로그를 많이 볼수록 관련 있어 보이는 증상을 더 많이 발견합니다. 문제는 그 증상들이 root cause가 아닐 수 있다는 점입니다. chaos controller, upstream fault injection, downstream timeout, retry 폭증 같은 것들이 함께 보이면 모델은 이것들을 모두 원인 후보로 넣고 싶어합니다.
따라서 SRE 에이전트에는 stop rule이 필요합니다. 충분한 근거가 모였을 때 더 조사하지 않고 hypothesis를 고정하는 규칙, root cause와 symptom을 분리하는 체크리스트, 제출 전 오답 후보를 제거하는 self-review 단계가 필요합니다.
ITBench-AA를 그대로 내부 서비스에 적용할 필요는 없습니다. 하지만 평가 방식은 가져올 수 있습니다. 먼저 최근 장애 20~50개를 골라 incident snapshot을 만듭니다. alert, log, metric, trace, 배포 이력, topology, runbook을 시간대 기준으로 묶습니다. 그다음 사람이 확정한 root cause entity를 ground truth로 남깁니다.
중요한 것은 에이전트가 production에 직접 접근하지 않아도 평가할 수 있게 만드는 것입니다. snapshot 기반 eval을 만들면 위험 없이 모델을 비교할 수 있습니다. 새 모델이나 새 agent prompt를 도입할 때 같은 incident set으로 재평가할 수 있습니다.
점수도 단순 정답률보다 ITBench-AA처럼 설계하는 게 좋습니다. root cause를 하나라도 놓치면 0점, 모두 찾으면 precision을 계산합니다. 여기에 조사 turn 수, 명령어 수, wall-clock time, 위험 명령 시도 여부를 추가하면 운영 품질을 더 잘 볼 수 있습니다.
운영 장애 대응 프롬프트는 일반 코딩 프롬프트와 달라야 합니다. 목표는 원인을 많이 나열하는 것이 아니라 최소 독립 원인을 찾는 것입니다. 다음 구조가 안전합니다.
목표: incident의 최소 독립 root-cause Kubernetes entity를 찾아라.
금지: 증상, downstream failure, fault-injection mechanism을 root cause로 제출하지 마라.
절차: alert window 확인 → topology 확인 → trace/log로 영향 경로 확인 → manifest/event로 원인 entity 확인.
출력: root_cause_entities 배열과 각 entity별 증거 3개.
제출 전: 각 후보가 symptom인지 root cause인지 한 번 제거 검토하라.
이런 지침은 모델의 탐색 방향을 줄여줍니다. 특히 ‘최소 독립 원인’이라는 표현이 중요합니다. 장애 대응에서 여러 현상은 하나의 원인에서 파생될 수 있기 때문입니다.
ITBench-AA 결과에서는 open-weight 모델의 비용 효율도 언급됩니다. 예를 들어 Gemma 4 31B Reasoning은 37%를 기록하면서 task당 $0.14로, Gemini 3.1 Pro Preview보다 점수와 비용 모두에서 나은 위치로 소개됐습니다. GLM-5.1 Reasoning도 Gemini 3.5 Flash high와 비슷한 점수에서 낮은 비용으로 언급됐습니다.
실무에서는 최고 점수 모델만 고르면 안 됩니다. SRE 에이전트는 장애가 날 때만 쓰는 것이 아니라, 사전 진단, 배포 후 모니터링, runbook rehearsal에도 쓰일 수 있습니다. task당 비용과 latency가 높으면 자주 평가하지 못합니다. 따라서 ‘고위험 incident는 강한 모델’, ‘일상 점검과 과거 incident replay는 저렴한 모델’처럼 계층화가 필요합니다.
ITBench-AA가 주는 메시지는 차갑지만 유용합니다. AI 에이전트가 운영 장애를 맡을 수는 있습니다. 하지만 현재 수준에서는 강한 모델도 절반 이하의 점수에서 시작합니다. 그래서 더 중요한 것은 모델 홍보 문구가 아니라, 우리 환경의 incident eval과 안전한 권한 설계입니다.