47%에서 멈춘 SRE 에이전트, 쿠버네티스 장애의 현실선

AI 요약

• 무슨 일: Artificial Analysis가 IBM ITBench 기반의 ITBench-AA SRE 에이전트 벤치마크를 공개했습니다.
  • 평가는 59개 Kubernetes 장애 task를 3회씩 실행하고, agent가 root-cause entity를 JSON으로 맞히는지 봅니다.
• 핵심 숫자: 공개 leaderboard 최고 점수는 Claude Opus 4.7의 46.7%, GPT-5.5는 45.8%, Qwen3.7 Max는 42.5%입니다.
• 의미: SRE agent는 대화 품질이 아니라 증상과 원인 entity를 분리하는 운영 신뢰성으로 평가해야 합니다.
  • scoring은 false negative가 있으면 0점이므로, "그럴듯한 설명"보다 빠뜨리지 않는 진단이 중요합니다.
• 주의점: offline snapshot benchmark라서 실제 on-call 권한, rollback 승인, 실시간 변경 대응까지 검증하는 것은 아닙니다.

AI 에이전트가 운영 업무로 들어갈 때 가장 위험한 착시는 "말을 잘하면 일을 잘할 것"이라는 생각입니다. 장애 상황에서는 그럴듯한 설명이 별 도움이 되지 않습니다. 어떤 deployment가 잘못됐는지, 어느 namespace의 ConfigMap이 원인인지, 어떤 pod는 증상일 뿐인지, 어떤 network policy가 실제 contributing factor인지 구분해야 합니다. 그리고 이 판단은 대개 불완전한 alert, event, trace, metric, topology 조각 위에서 이뤄집니다.

2026년 5월 27일 전후 공개된 Artificial Analysis의 ITBench-AA leaderboard는 이 지점을 정면으로 찌릅니다. 이 벤치마크는 IBM의 ITBench를 독립 구현해 AI 에이전트가 Kubernetes 기반 SRE incident root-cause analysis를 얼마나 잘하는지 측정합니다. headline은 꽤 차갑습니다. 공개 페이지 기준 최고 점수는 Claude Opus 4.7 Adaptive Reasoning Max Effort의 46.7%입니다. GPT-5.5 xhigh가 45.8%, Qwen3.7 Max가 42.5%로 뒤따릅니다. frontier model을 붙인 agent도 절반을 넘지 못했습니다.

이 숫자는 "모델이 멍청하다"는 식의 농담으로 소비하기에는 아깝습니다. 더 중요한 메시지는 운영 자동화의 평가 기준이 바뀌고 있다는 점입니다. coding benchmark에서는 patch가 test를 통과했는지 봅니다. customer-support benchmark에서는 정책을 지키며 문제를 해결했는지 봅니다. SRE benchmark에서는 장애의 원인 entity를 빠뜨리지 않고, 증상 entity를 원인처럼 과잉 지목하지 않는지 봅니다. 이 차이가 agent product의 설계와 운영 비용을 바꿉니다.

ITBench-AA가 보는 것은 "장애 설명"이 아닙니다

Artificial Analysis 설명에 따르면 ITBench-AA는 IBM ITBench의 SRE 영역을 독립적으로 구현한 평가입니다. agent는 offline Kubernetes incident snapshot을 받습니다. 그 안에는 alerts, events, traces, metrics, application topology가 들어 있습니다. agent는 shell access를 통해 snapshot을 조사하고, 최종 diagnosis를 structured JSON output file로 작성합니다. 답변은 사람이 읽기 좋은 postmortem이 아니라, 원인으로 작동한 Kubernetes entity 목록입니다.

평가 task는 59개입니다. Artificial Analysis는 이 중 40개가 IBM 공개 release에서 왔고, 19개는 ITBench 팀이 공유한 private task라고 설명합니다. 각 task는 3회 반복됩니다. 실행 환경은 Artificial Analysis의 open-source agent harness인 Stirrup 기반 sandboxed code-execution environment입니다. 즉 모델에게 "이 장애의 원인을 말해 봐"라고 묻는 채팅 평가가 아니라, agent에게 파일과 command line을 주고 실제 조사 loop를 돌리는 평가에 가깝습니다.

scoring도 운영 업무답게 설계돼 있습니다. headline score는 average precision at full recall입니다. task별로 false negative가 없는 경우에만 TP / (TP + FP)를 점수로 주고, false negative가 있으면 0점입니다. 원인을 하나라도 빠뜨리면 안 된다는 뜻입니다. 반대로 관련 없는 entity를 너무 많이 찍으면 precision이 떨어집니다. 이 방식은 SRE 실무의 압박과 닮았습니다. 장애 대응에서 진짜 원인을 놓치면 복구는 늦어지고, 증상만 잡으면 같은 incident가 다시 옵니다. 그렇다고 모든 것을 의심하면 rollback과 mitigation이 불필요하게 넓어집니다.

예시 task가 말하는 어려움

Artificial Analysis가 공개한 예시를 보면 왜 이 문제가 쉽지 않은지 보입니다. task 3은 OpenTelemetry Demo application에서 feature flag misconfiguration이 ad service의 CPU와 latency를 올리는 사건입니다. 표면 증상은 ad deployment와 pod 쪽에 나타납니다. 하지만 기대 root cause는 ad deployment가 아니라 otel-demo namespace의 flagd-config ConfigMap입니다. agent가 "느린 서비스"를 원인으로 찍으면 틀립니다. 실제로는 feature flag가 downstream symptom을 만든 것입니다.

task 16은 shipping service가 quote service의 잘못된 port를 바라보는 사건입니다. QUOTE_ADDR 환경 변수가 quote:0000으로 바뀌었고 checkout trace에는 connection failure가 나타납니다. 여기서도 agent는 downstream 실패를 만든 caller chain을 읽고, 잘못된 environment variable을 가진 shipping Deployment를 찾아야 합니다. 단순히 trace에 실패가 많이 보이는 service를 찍는 방식으로는 부족합니다.

task 20은 product-catalog Deployment가 존재하지 않는 container image를 참조해 Ready 상태가 되지 못하는 사건입니다. KubePodNotReady alert가 뜨고 dependent service도 실패합니다. 하지만 expected root cause는 downstream service가 아니라 invalid image reference를 가진 product-catalog Deployment입니다. 이 세 예시는 모두 같은 구조를 갖습니다. 관측된 증상과 실제 원인이 떨어져 있습니다. 좋은 agent는 로그를 많이 읽는 agent가 아니라, causal graph를 좁히는 agent입니다.

이 지점은 현재 많은 "AI SRE" 제품 설명과 다릅니다. 제품 데모에서는 alert를 요약하고, Slack thread를 만들고, runbook을 찾아주고, probable cause를 설명합니다. 모두 유용합니다. 하지만 ITBench-AA가 요구하는 것은 한 단계 더 낮고 더 엄격합니다. 원인 entity를 정확히 적어야 합니다. 이 차이는 incident automation의 배포 경계를 정합니다. 요약 agent는 read-only assistant로 시작할 수 있습니다. RCA agent가 remediation suggestion을 하려면 precision과 recall이 필요합니다. rollback이나 config 변경까지 맡기려면 훨씬 더 높은 신뢰성이 필요합니다.

원 논문은 이미 2025년에 경고했습니다

ITBench-AA는 새 leaderboard지만, 토대가 된 IBM ITBench 논문은 2025년 2월에 공개됐습니다. 논문은 AI agent가 critical IT task를 자동화하려면 effectiveness를 측정하고 이해할 수 있어야 한다고 말합니다. 초기 release는 SRE, CISO, FinOps 세 영역을 겨냥했습니다. arXiv abstract 기준 ITBench는 94개 real-world scenario를 포함했고, 당시 state-of-the-art model 기반 agent의 resolution rate는 SRE 13.8%, CISO 25.2%, FinOps 0%였습니다.

이 숫자는 지금의 46.7%와 직접 비교하면 안 됩니다. 평가 구성, agent harness, 모델 세대, scoring 방식이 다릅니다. 그래도 방향은 중요합니다. 2025년 원 논문이 보여준 것은 "엔터프라이즈 IT 자동화는 일반 QA나 코딩 문제보다 훨씬 거칠다"는 사실입니다. 2026년 ITBench-AA는 그 문제를 Kubernetes SRE RCA로 좁히고, 최신 frontier model들을 같은 leaderboard에 올렸습니다. 결과는 좋아졌지만 아직 운영 자동화를 마음 놓고 맡길 수준은 아닙니다.

IBM ITBench GitHub 저장소는 이 벤치마크의 의도를 더 분명히 보여줍니다. ITBench는 Kubernetes 기반 scenario environment, push-button deployment tooling, SRE/CISO baseline agent, managed leaderboard를 제공합니다. use case도 availability와 resiliency의 SRE, compliance와 security enforcement의 CISO, cost와 ROI optimization의 FinOps로 나눕니다. 즉 ITBench는 "모델이 운영 지식을 알고 있는가"가 아니라 "운영 환경에서 task를 수행할 수 있는가"를 묻습니다.

왜 최고 모델도 50% 아래인가

이 결과를 해석할 때 먼저 봐야 할 것은 task의 성격입니다. Kubernetes incident RCA는 단일 정답 문장 문제가 아닙니다. agent는 snapshot 안의 여러 파일과 신호를 탐색해야 합니다. alert는 증상을 가리킬 수 있고, event는 원인에 가까울 수도 있지만 noise가 섞입니다. trace는 propagation path를 보여주지만, 최초 원인을 바로 알려주지 않습니다. topology는 dependency를 보여주지만, 어떤 dependency가 이번 incident에 실제로 작동했는지는 별도 증거가 필요합니다.

두 번째는 agent loop의 불안정성입니다. 같은 모델이라도 어떤 command를 먼저 실행하는지, 어느 로그를 더 오래 읽는지, 중간 요약에서 무엇을 버리는지에 따라 최종 diagnosis가 달라집니다. false negative가 있으면 0점이 되는 scoring에서는 작은 탐색 누락이 치명적입니다. 일반 chat benchmark에서 "대략 맞는 설명"은 부분적으로 받아들여질 수 있습니다. SRE RCA에서는 빠뜨린 entity 하나가 전체 실패입니다.

세 번째는 비용과 시간 제한입니다. Artificial Analysis는 평균 turn, output token, cost per task 같은 축도 함께 제공합니다. 운영 환경에서 agent가 오래 조사할수록 비용이 늘고, incident 대응 시간도 늘어납니다. agent가 100-turn cap에 가까워질수록 사람에게는 "아직 조사 중"인 시간이 길어집니다. 반대로 너무 빨리 결론을 내리면 증상 entity를 원인으로 오판할 가능성이 커집니다. SRE agent는 정확도만이 아니라 latency, token budget, escalation timing을 함께 최적화해야 합니다.

네 번째는 evaluation target이 "모델"만이 아니라 "모델을 감싼 agent system"이라는 점입니다. 어떤 shell command를 허용할지, 파일 구조를 어떻게 설명할지, intermediate observation을 어떻게 압축할지, final JSON schema를 어떻게 강제할지, 실패 시 재시도를 어떻게 할지가 모두 점수에 영향을 줍니다. 이는 최근 agent benchmark 전반의 흐름과 맞닿아 있습니다. 더 좋은 모델은 중요하지만, agent harness와 environment protocol이 같은 모델의 성능을 크게 바꿉니다.

개발팀에 필요한 것은 자동 복구보다 자동 검증입니다

ITBench-AA가 바로 "AI가 SRE를 대체할 수 없다"는 결론을 뜻하지는 않습니다. 오히려 실무적으로는 더 좁은 결론이 유용합니다. 지금 가장 먼저 배포할 가치가 있는 것은 autonomous remediation보다 investigation assistant와 verification layer입니다. agent가 alert를 묶고, 관련 trace와 event를 모으고, candidate root cause를 제안하고, 사람이 확인할 evidence를 정리하는 일은 이미 유용할 수 있습니다. 하지만 자동 rollback, config patch, network policy 수정은 별도의 승인 경계가 필요합니다.

SRE 팀이 이 벤치마크에서 배울 수 있는 첫 번째 원칙은 "agent output을 postmortem prose로 받지 말라"입니다. 최종 진단은 구조화돼야 합니다. namespace, deployment, service, pod, ConfigMap, network policy 같은 entity type과 name을 분리해야 합니다. evidence link도 붙어야 합니다. agent가 어떤 command를 실행했고, 어떤 file을 읽었고, 어떤 signal을 근거로 삼았는지 trace를 남겨야 합니다. 그래야 사람 reviewer가 빠르게 판단하고, 이후 regression test로 바꿀 수 있습니다.

두 번째 원칙은 "증상과 원인을 분리하는 test set을 만들라"입니다. production incident의 많은 실패는 noisy symptom에서 시작합니다. CPU가 높은 service가 원인이 아닐 수 있고, error rate가 높은 endpoint가 root cause가 아닐 수 있습니다. feature flag, env var, secret, image tag, deployment rollout, network policy, DNS, quota, storage, dependency outage 같은 원인을 synthetic incident로 재현할 수 있어야 합니다. ITBench의 의미는 공개 leaderboard 자체보다 이런 평가 문법을 제공한다는 데 있습니다.

세 번째 원칙은 "agent를 SLO에 넣기 전에 agent 자체의 SLO를 정하라"입니다. 예를 들어 P1 incident에서 agent가 3분 안에 candidate cause를 제시해야 하는지, 10분 안에 confidence와 evidence를 내야 하는지, false negative를 얼마나 허용할 수 있는지 정해야 합니다. 사람보다 느리지만 더 꼼꼼한 agent가 필요한 상황도 있고, 빠른 triage만 맡기는 것이 맞는 상황도 있습니다. 하나의 "AI SRE" 제품으로 모든 대응 단계를 덮는 접근은 위험합니다.

benchmark의 한계도 같이 봐야 합니다

ITBench-AA는 중요한 신호이지만, 실제 운영 신뢰성의 전부는 아닙니다. 첫째, offline snapshot benchmark입니다. 실제 production에서는 시간이 흐르는 동안 metric이 바뀌고, 다른 engineer가 조치를 취하고, 새로운 alert가 붙고, rollback window가 줄어듭니다. snapshot은 재현성과 비교 가능성을 위해 필요하지만, live incident의 상호작용을 모두 담지는 못합니다.

둘째, root-cause diagnosis와 remediation은 다른 문제입니다. 원인을 맞히는 agent가 항상 안전하게 고치는 것은 아닙니다. 반대로 원인을 100% 맞히지 못해도 사람이 확인할 evidence bundle을 잘 모아주면 incident response time은 줄어들 수 있습니다. leaderboard score는 제품 가치의 일부입니다. 그래서 ITBench-AA를 vendor 선택의 단일 기준으로 쓰기보다, 자체 runbook과 incident 유형에 맞는 내부 평가로 확장하는 것이 맞습니다.

셋째, 공개 결과는 특정 model, effort level, harness, task set 조합의 결과입니다. 모델은 계속 바뀌고 agent framework도 빠르게 바뀝니다. 특히 reasoning effort를 높이면 정확도는 올라갈 수 있지만 cost와 latency도 커집니다. 운영에서는 "가장 높은 점수"보다 "우리 incident class에서, 우리 token budget과 escalation rule 안에서, 반복 가능한 성능"이 더 중요합니다.

커뮤니티 반응도 이 균형을 요구합니다. benchmark에 대한 일반적 회의는 여전히 많습니다. 어떤 Reddit 토론에서는 더 나은 leaderboard가 있어도 내일의 deploy를 맡길 agent instance의 trust profile을 주지는 않는다는 취지의 지적이 나왔습니다. 맞는 말입니다. 하지만 그렇다고 benchmark가 쓸모없다는 뜻은 아닙니다. 좋은 benchmark는 모델 홍보 문구를 줄이고, 실패를 비교 가능한 형태로 드러내는 시작점입니다.

SRE 에이전트의 다음 병목

이제 agentic development의 관심은 code generation에서 운영 workflow로 이동하고 있습니다. coding agent가 pull request를 만들고, observability tool이 agent timeline을 제공하고, cloud provider가 sandboxed agent runtime을 내놓는 흐름은 이미 뚜렷합니다. 그 다음 자연스러운 질문은 "장애 대응도 agent에게 맡길 수 있는가"입니다. ITBench-AA의 대답은 조심스럽습니다. 도울 수는 있지만, 아직 자율 운영자로 보기에는 부족합니다.

다음 병목은 모델 크기만이 아닙니다. agent가 operational evidence를 다루는 방식입니다. file tree를 훑고 끝나는 agent가 아니라, topology graph와 trace dependency를 명시적으로 만들고, hypothesis를 세운 뒤 반증 evidence를 찾고, candidate root cause를 좁히는 구조가 필요합니다. runbook과 과거 incident를 retrieval하는 것도 중요하지만, retrieval된 지식을 현재 snapshot의 evidence와 연결하는 검증이 더 중요합니다.

또 하나의 병목은 사람과의 handoff입니다. incident commander는 "아마 product-catalog가 문제입니다"보다 "product-catalog Deployment의 image reference가 invalid하고, KubePodNotReady alert와 downstream checkout failure가 그 결과로 보이며, ConfigMap과 network policy에서는 반대 증거를 찾지 못했습니다"를 원합니다. 이 문장은 길지만 구조화할 수 있습니다. agent UI는 confidence score보다 evidence graph와 alternative hypothesis를 보여줘야 합니다.

마지막 병목은 조직의 평가 데이터입니다. ITBench-AA는 공개 benchmark로 출발점을 제공합니다. 하지만 각 회사의 Kubernetes cluster, naming convention, observability stack, deployment pattern, incident taxonomy는 다릅니다. 실제로 AI SRE를 도입하려면 과거 incident postmortem과 synthetic failure injection을 기반으로 내부 benchmark를 만들어야 합니다. agent가 일반적인 Kubernetes 지식만으로는 알 수 없는 조직 특유의 failure mode를 배워야 하기 때문입니다.

47%라는 숫자는 실망스럽게 보일 수 있습니다. 그러나 이 숫자가 유용한 이유는 에이전트가 어느 지점에서 아직 불안한지 보여주기 때문입니다. SRE 업무는 말솜씨가 아니라 원인 추적, 증거 연결, 누락 없는 진단, 안전한 handoff의 문제입니다. ITBench-AA는 그 현실선을 공개 leaderboard 위에 올렸습니다. 이제 개발팀이 봐야 할 것은 "어떤 모델이 1등인가"보다 "우리 운영 자동화는 이 기준으로 얼마나 검증됐는가"입니다.