Artificial Analysis와 IBM Software Innovation Lab이 ITBench-AA를 공개했습니다. 첫 평가 영역은 엔터프라이즈 Site Reliability Engineering 작업입니다. 결과는 꽤 냉정합니다. Claude Opus 4.7 Adaptive Reasoning Max Effort가 47%, GPT-5.5 xhigh가 46%, Qwen3.7 Max가 42%로 상위권이지만, 모든 프런티어 모델이 50% 아래에 머물렀습니다. Hugging Face에 공개된 설명에 따르면 이 벤치마크는 Kubernetes 장애 스냅샷을 보고 실제 root-cause entity를 찾아내는 작업으로 구성됩니다.
이 뉴스는 “모델이 아직 약하다”는 단순한 이야기가 아닙니다. 기업 IT 운영에 AI 에이전트를 넣으려는 팀에게 중요한 경고입니다. 채팅 답변, 코딩 문제, 터미널 벤치마크에서 좋은 점수를 받은 모델도 실제 SRE 원인 분석에서는 쉽게 흔들립니다.
SRE 작업은 일반 질의응답과 다릅니다. 장애가 나면 로그, 메트릭, 이벤트, trace, topology, Kubernetes manifest가 동시에 튀어나옵니다. 증상은 여러 곳에서 보입니다. 하지만 실제 조치해야 할 원인은 보통 더 작습니다. 잘못된 NetworkPolicy 하나, resource quota exhaustion, rollout failure, connection pool exhaustion, network partition 같은 구체적 엔티티를 찾아야 합니다.
ITBench-AA의 SRE 태스크는 59개입니다. 40개는 공개 태스크, 19개는 새 held-out 태스크입니다. 각 태스크는 Kubernetes incident snapshot을 제공하고, 모델은 shell access가 있는 sandboxed file system에서 로그와 스냅샷을 읽어 root-cause Kubernetes entity 목록을 제출합니다. 제출 형식은 구조화된 진단입니다.
이 방식은 실무와 가깝습니다. 실제 장애 대응에서도 모델은 “아마 네트워크 문제입니다”라고 말하는 것만으로 충분하지 않습니다. 어떤 namespace의 어떤 NetworkPolicy, Deployment, Service, Pod가 원인인지 식별해야 합니다.
ITBench-AA의 흥미로운 결과 중 하나는 turn count와 정확도가 단순히 비례하지 않는다는 점입니다. GPT-5.5 xhigh는 태스크당 평균 31턴으로 46%를 기록했고, Gemini 3.1 Pro Preview는 평균 83턴을 쓰면서도 30%에 그쳤습니다. 더 많이 뒤진다고 더 정확해지는 것이 아닙니다.
벤치마크 설명은 모델이 upstream fault-injection mechanism이나 동시 발생 증상을 root cause로 잘못 제출하는 경우를 언급합니다. 이것은 실무에서도 자주 보이는 패턴입니다. 장애 대응 초반에는 많은 신호가 보입니다. CPU가 튀고, 요청 실패가 늘고, 특정 서비스 로그가 쌓이고, downstream timeout이 발생합니다. 하지만 그중 상당수는 원인이 아니라 결과입니다.
ITBench-AA의 scoring도 이 문제를 강하게 반영합니다. 모델이 ground truth root cause를 하나라도 놓치면 해당 repeat 점수는 0입니다. 모두 찾았더라도 false positive를 많이 넣으면 precision이 낮아집니다. 즉 “관련 있어 보이는 것 다 제출하기”가 통하지 않습니다.
SRE 에이전트를 만들 때 많은 팀이 도구 접근성부터 늘립니다. 로그를 읽게 하고, kubectl을 붙이고, trace를 보게 하고, 대시보드를 열어줍니다. 하지만 더 중요한 것은 제출 기준입니다. 에이전트가 어떤 조건에서 원인으로 확정할 수 있는지, 어떤 것은 증상으로만 기록해야 하는지 정해야 합니다.
좋은 진단 출력은 최소한 다음을 분리해야 합니다.
이 구조가 없으면 에이전트는 긴 보고서를 만들지만 조치 가능한 결론을 주지 못합니다. 장애 상황에서는 예쁜 요약보다 정확한 축소가 중요합니다.
ITBench-AA 결과에서 또 하나 볼 점은 비용 대비 성능입니다. 공개 설명에 따르면 GLM-5.1 Reasoning은 40%로 Gemini 3.5 Flash high와 비슷한 점수를 내면서 태스크당 비용은 더 낮았습니다. Gemma 4 31B Reasoning은 37%를 기록했고, 태스크당 $0.14로 Gemini 3.1 Pro Preview보다 점수와 비용 모두에서 나은 결과로 제시됐습니다. Claude Opus 4.7은 47%로 1위지만 태스크당 $5.38로 가장 비쌌습니다.
이 숫자는 그대로 구매 결정을 하라는 뜻이 아닙니다. 다만 SRE 에이전트에서는 “가장 비싼 모델 하나”보다 “단계별 라우팅”이 유효할 수 있음을 보여줍니다. 예를 들어 저비용 모델이 초기 로그 분류와 후보 축소를 하고, 고비용 모델은 최종 root-cause 검증에만 쓰는 구조입니다.
ITBench-AA를 보고 바로 운영 시스템에 AI 에이전트를 붙이면 안 됩니다. 먼저 사내 벤치마크를 만들어야 합니다. 과거 장애 티켓, postmortem, Kubernetes 이벤트, 로그 일부, trace 샘플을 익명화해 태스크로 구성하세요. 목표는 모델의 일반 지식이 아니라 우리 인프라에서 원인을 찾는 능력을 보는 것입니다.
태스크는 다음 형식이 좋습니다.
이렇게 해야 모델이 “말을 잘하는지”가 아니라 “운영 원인을 맞히는지”를 볼 수 있습니다.
SRE 에이전트를 운영에 넣을 때는 자동 조치보다 진단 보조부터 시작해야 합니다. restart, scale, rollback, network policy 수정 같은 명령은 실수 비용이 큽니다. 초기에는 읽기 전용 권한으로 원인 후보와 근거를 정리하게 하고, 사람이 승인한 뒤 조치하는 구조가 안전합니다.
또한 에이전트의 탐색 로그를 저장해야 합니다. 어떤 파일을 읽었는지, 어떤 명령을 실행했는지, 어떤 후보를 버렸는지 남기지 않으면 오진을 개선할 수 없습니다. ITBench-AA가 Stirrup reference harness로 모델 간 조건을 고정한 것처럼, 사내에서도 같은 harness로 모델을 비교해야 합니다.
ITBench-AA의 메시지는 분명합니다. 엔터프라이즈 IT 에이전트는 아직 쉬운 문제가 아닙니다. 하지만 이 벤치마크는 좋은 출발점을 줍니다. SRE 자동화의 핵심은 많은 로그를 읽는 모델이 아니라, 증상과 원인을 구분하고 조치 가능한 엔티티를 좁히는 모델입니다.
참고: Hugging Face Blog, “ITBench-AA: Frontier Models Score Below 50%...”, 2026-05-27.
