AI 지원 DevOps 및 SRE 도구들이 점점 더 흔해지고 있습니다. K8sGPT와 같은 도구들은 Kubernetes 클러스터를 스캔하고, 문제를 감지하며, 무엇이 잘못되었을 수 있는지 설명할 수 있습니다.

이러한 도구들에 대한 대부분의 평가는 한 가지 명백한 질문에 집중합니다:

시스템이 장애를 진단하거나 해결할 수 있는가?

그 질문도 중요하지만, 프로덕션 시스템(production systems)에서는 그것이 전부가 아닙니다.

때로는 더 중요한 질문이 있습니다:

시스템이 언제 행동하지 말아야 할지를 알고 있는가?

자신감 있지만 잘못된 복구(remediation)는 장애를 악화시킬 수 있습니다. 잘못된 워크로드(workload)를 재시작하거나, 안전하지 않은 변이(mutation)를 제안하거나, 오래된 이벤트(stale events)에 따라 행동하거나, 불완전한 증거를 바탕으로 변경 사항을 제안하는 것은 관리 가능한 장애를 더 큰 프로덕션 문제로 만들 수 있습니다.

이러한 아이디어가 이 벤치마크의 동기입니다.

K8sGPT 기반의 Kubernetes SRE 워크플로우를 위한 **교정 및 기권 벤치마크(calibration and abstention benchmark)**가 구축되었습니다. 목표는 워크플로우가 Kubernetes 문제를 식별할 수 있는지 테스트하는 것뿐만 아니라, 불확실성을 인식하고, 안전하지 않은 행동을 피하며, 증거가 불완전하거나, 오해의 소지가 있거나, 적대적인 경우에 기권(abstain)할 수 있는지를 테스트하는 것입니다.

GitHub 리포지토리: github.com/Mayank-013/k8sGPT

진단 정확도만으로는 충분하지 않은 이유

많은 Kubernetes 트러블슈팅(troubleshooting) 시나리오에서 눈에 보이는 증상을 식별하는 것은 비교적 쉽습니다.

Pod가 CrashLoopBackOff 상태인 경우.

이미지를 가져올 수(pull) 없는 경우.

워크로드가 Pending 상태에 멈춰 있는 경우.

Readiness probe가 실패하는 경우.

하지만 증상을 아는 것과 근본 원인(root cause)을 아는 것은 다릅니다.

예를 들어, Readiness 실패는 다음과 같은 원인으로 발생할 수 있습니다:

• 잘못된 probe 경로
• 잘못된 probe 포트
• 고장 난 애플리케이션
• 상위 의존성(upstream dependency) 중단
• NetworkPolicy 문제
• 이전 장애로부터 발생한 오래된 이벤트(stale events)

만약 SRE 워크플로우가 증상을 보고 즉시 복구(remediation)를 제안한다면, 장애를 여전히 오해하고 있는 상태에서도 도움이 되는 것처럼 보일 수 있습니다.

그 차이가 중요합니다.

실제 운영 환경에서 "아직 아무것도 하지 않는 것"이 가장 안전한 결정일 수 있습니다. 하지만 이는 시스템이 왜 행동을 자제(abstention)하는지 그 이유를 이해하고 있을 때만 가능합니다.

구축된 내용

이 프로젝트는 테스트 대상 분석기인 K8sGPT를 중심으로 벤치마크(benchmark)와 평가 하네스(evaluation harness)를 도입합니다.

이 벤치마크는 4가지 카테고리에 걸쳐 163개의 라벨링된 Kubernetes 장애 사례를 포함합니다:

각 사례에는 예상되는 근본 원인(root cause)뿐만 아니라 다음 정보들이 라벨링되어 있습니다:

• 조치 위험(action-risk) 정보
• 자제(abstention) 기대치
• 증거 완결성(evidence completeness)
• 안전하지 않은 복구(remediation) 후보
• 기대되는 동작

워크플로우가 진단을 제대로 내렸는지 여부만 묻는 대신, 벤치마크는 다음과 같은 질문을 던집니다:

• 올바른 근본 원인 계열(root-cause family)을 식별했는가?
• 안전한 조치를 제안했는가?
• 행동을 해야 했는가, 더 조사해야 했는가, 승인이 필요했는가, 아니면 자제(abstain)해야 했는가?
• 신뢰도(confidence)가 적절히 보정(calibrated)되었는가?
• 안전하지 않거나 과도한 권한을 가진(overprivileged) 조치 제안을 생성했는가?
• 불확실성 상황에서 안전하게 실패(fail safely)했는가?

평가 방식

높은 수준(high level)에서 워크플로우는 다음과 같습니다:

kind 클러스터
  -> Kubernetes 장애 주입
  -> 증거 캡처
...

벤치마크는 재현 가능한 kind 기반 설정을 사용하여 장애를 주입하고, K8sGPT를 실행하며, 발견 사항을 정규화(normalize)하고, 구조화된 조치 계획을 추출하며, 결과를 점수화(score)합니다.

원시 출력(raw outputs)은 보존되며, 점수 산정은 별도로 이루어집니다. 이를 통해 K8sGPT가 실제로 찾아낸 것과 주변 워크플로우가 추론한 것을 구분할 수 있습니다.

이러한 구분은 매우 중요한데, 이 프로젝트는 K8sGPT 자체의 복구(remediation) 동작이 아니라 **K8sGPT 기반의 워크플로우(K8sGPT-backed workflows)**를 평가하기 때문입니다.

K8sGPT는 분석 결과와 선택적인 설명 출력을 제공합니다. 구조화된 조치 계획, 신뢰도 점수, 자제(abstention) 결정 및 라우팅 로직은 이 벤치마크에서 래퍼(wrapper) 및 평가 계층(evaluation-layer) 구성 요소에 해당합니다.

평가의 정직성을 유지하기 위해, 단계별 점수는 다음과 같이 별도로 보고됩니다:

1. K8sGPT 분석기(analyzer) 탐지 품질
2. 래퍼(Wrapper)의 작업 및 기권(abstention) 품질

이를 통해 K8sGPT 자체가 생성한 결과와 주변 워크플로(workflow)가 추론한 결과를 혼동하는 것을 방지합니다.

무엇을 측정하는가

이 벤치마크는 단순한 진단 정확도보다는 안전 지향적 평가에 초점을 맞춥니다.

이것이 중요한 이유는 AI 지원 SRE 워크플로가 단순히 얼마나 자주 답변을 생성하는가만으로 평가되어서는 안 되기 때문입니다.

답변이 실행하기에 안전한지 여부로도 평가되어야 합니다.

무엇을 평가했는가

공개된 벤치마크에는 163개의 레이블이 지정된 케이스(labeled cases)가 포함되어 있습니다. 평가는 전체 카탈로그 분석기 점수 산정과 더 작은 규모의 라이브 LLM 기반 서브셋(subset) 산정을 분리하여 진행합니다.

중요한 차이점은 다음과 같습니다:

벤치마크 크기는 LLM 차별화 크기와 동일하지 않습니다.

전체 163개 케이스 카탈로그는 라이브 분석기 평가에 사용됩니다. 라이브 LLM 기반 메커니즘 비교는 현재 14개 케이스의 더 작은 서브셋으로 진행됩니다.

주요 결과: 라이브 C0 분석기 평가

일상적인 Kubernetes 케이스에서 K8sGPT 기반 분석기 워크플로는 유용했습니다.

ImagePullBackOff, CrashLoopBackOff, OOMKilled, Pending과 같은 일반적인 장애 계열의 경우, 분석기 기반 추출은 분포 내(in-distribution) 세트에서 예상된 작업(expected actions)을 안정적으로 복구했습니다.

프로브(Probe) 관련 문제는 훨씬 더 어려웠습니다.

이는 K8sGPT 기반 분석기 워크플로가 일상적인 Kubernetes 증상에는 도움이 될 수 있지만, 일부 실패 계열은 더 깊은 인과적 추론(causal reasoning)이 필요함을 시사합니다.

전체 카탈로그 결과

전체 실행 가능한 C0 평가는 공개된 163개 케이스 전체에 대해 실행되었습니다.

K8sGPT 기반 워크플로우는 일상적인 Kubernetes 증상에는 유용하지만, 불확실하거나, 분포 외 (OOD, Out-of-Distribution) 상황, 또는 적대적 (Adversarial) 사례에서의 안전한 조치 (Safe remediation)는 여전히 어렵습니다.

OOD 및 적대적 사례에서 높은 Safe-abstain (안전한 기권) 비율은 중요하지만, 이를 과도하게 해석해서는 안 됩니다.

기권(Abstention)이 많은 워크플로우는 사고를 여전히 오해하고 있으면서도 안전해 보일 수 있습니다.

다시 말해, 시스템이 위험한 행동을 피하는 것은 상황을 깊이 이해했기 때문이 아니라, 광범위하게 기권하기 때문일 수 있습니다.

이는 무모한 변이 (Reckless mutation)보다는 안전하지만, 견고한 인과적 이해 (Robust causal understanding)와 동일한 것은 아닙니다.

혼합 조건 전체 카탈로그 결과 (Mixed-condition full-catalog results)

전체 카탈로그에는 준비된 C1-C3/C7 행들도 포함되어 있습니다. 이는 혼합된 결과입니다: 149개의 휴리스틱 오프라인 준비(Heuristic offline prepares)와 14개의 보존된 OpenAI 기반 라이브 플랜(Live plans)이 포함됩니다.

라이브 LLM 기반 서브셋 (Live LLM-backed subset)

설명 및 구조화된 작업 추출 (Structured action extraction)을 위해 OpenAI의 gpt-4o-mini를 사용한 소규모 라이브 LLM 기반 서브셋을 평가했습니다.

14개의 대표 사례는 ID, 근접-OOD (Near-OOD), 원거리-OOD (Far-OOD), 그리고 적대적 (Adversarial) 시나리오를 다룹니다.

이 하위 집합에서, LLM 기반 래퍼(LLM-backed wrapper)는 더 적극적으로 조치를 제안했으며 더 높은 신뢰도를 보였습니다. 그러나 기권(abstention) 비중이 높은 휴리스틱 베이스라인(heuristic baseline)보다 더 많은 불안전한 조치 제안을 생성하기도 했습니다.

하이브리드 라우터(hybrid router)는 불확실하거나 위험한 사례들을 다시 기권(abstention) 쪽으로 유도함으로써 더 보수적인 동작을 복원했습니다.

이는 다음과 같은 중요한 교훈을 시사합니다:

LLM 레이어를 추가하면 워크플로(workflow)가 더 실행 가능하게 느껴질 수 있지만, 위험 인지 라우팅(risk-aware routing)이 없다면 워크플로의 안전성을 떨어뜨릴 수도 있습니다.

두 번째 라벨러 일치도 (Second-labeler agreement)

순수하게 주관적인 라벨링(labeling)의 위험을 줄이기 위해, 113개의 OOD 사례 중 30개에 대해 두 번째 라벨러 검토(second-labeler pass)를 수행했습니다.

조치 위험 등급(action-risk tier)에 대한 낮은 일치도는 사실 유용합니다. 이는 SRE 워크플로가 조치를 취해야 할지, 승인을 요청해야 할지, 아니면 에스컬레이션(escalate)해야 할지를 결정하는 것이 항상 명확하지는 않다는 것을 보여줍니다.

이것이 바로 이러한 종류의 벤치마크가 중요한 이유입니다.

주요 시사점 (Main takeaway)

가장 강력한 발견은 단순히 K8sGPT가 OOD 사례보다 일상적인 사례에서 더 나은 성능을 보인다는 것이 아닙니다.

그것은 예상 가능한 결과입니다.

더 흥미로운 발견은 이것입니다:

기권(abstention)을 통한 안전성은 견고한 인과 관계 이해(robust causal understanding)와 동일하지 않습니다.

워크플로는 광범위하게 기권함으로써 불안전한 조치를 피할 수 있지만, 여전히 장애(incident)를 이해하는 데 실패할 수 있습니다. 반대로, LLM 레이어를 추가하면 실행 가능성과 신뢰도를 높일 수 있지만, 위험 인지 라우팅(risk-aware routing)과 결합되지 않으면 불안전한 조치 제안을 증가시킬 수도 있습니다.

이는 AI 지원 SRE 워크플로를 생각하는 유용한 관점을 제공합니다:

• 진단 정확도 (diagnosis accuracy)가 중요함
• 신뢰도 교정 (confidence calibration)이 중요함
• 기권 품질 (abstention quality)이 중요함
• 조치 위험 분류 (action-risk classification)가 중요함
• 불안전한 제안 비율 (unsafe proposal rates)이 중요함
• 에스컬레이션 동작 (escalation behavior)이 중요함

운영 환경의 안전성 (Production safety)은 단순히 정답을 맞히는 것만이 아닙니다.

답변이 실행하기에 충분히 안전하지 않을 때, 언제 행동을 멈춰야 하는지를 아는 것도 중요합니다.

이것이 중요한 이유

AI 지원 SRE 도구들이 점점 더 유능해짐에 따라, 어려운 문제는 단순히 그럴듯한 설명을 생성하는 것만이 아닙니다.

진짜 어려운 문제는 어느 정도 수준의 자율성 (autonomy)이 적절한지 결정하는 것입니다.

시스템이 명령어를 제안해야 할까요?

승인을 요청해야 할까요?

더 많은 증거를 수집해야 할까요?

사람에게 에스컬레이션 (escalate)해야 할까요?

변이 (mutation) 권고를 거부해야 할까요?

이러한 결정들은 운영 환경의 안전성 (production safety)의 핵심입니다.

복구 조치 (remediation actions)가 실행 중인 워크로드 (workloads), 보안 경계 (security boundaries), 그리고 고객 대면 시스템에 영향을 미칠 수 있는 Kubernetes 환경에서는, 어떻게 행동할지 아는 것만큼이나 언제 행동하지 말아야 할지를 아는 것이 중요합니다.

이 프로젝트가 주장하지 않는 것

이 벤치마크는 K8sGPT가 안전하지 않다고 주장하는 것이 아닙니다.

또한, 평가된 래퍼 (wrapper)가 K8sGPT의 네이티브 복구 동작 (remediation behavior)을 대표한다고 주장하는 것도 아닙니다.

목표는 더 구체적입니다:

진단 (diagnosis), 신뢰도 (confidence), 기권 (abstention), 그리고 조치 위험 (action risk)이 함께 측정될 때, K8sGPT 기반의 워크플로가 어떻게 동작하는지 평가한다.

이 프로젝트는 AI 지원 Kubernetes 트러블슈팅 (troubleshooting)을 위한 더 신중한 평가 프레임워크를 구축하는 것에 관한 것입니다.

향후 계획

이것은 초기 릴리스이며, 개선할 점이 더 많이 남아 있습니다.

다음 단계에는 다음이 포함됩니다:

• 현재의 하위 집합을 넘어 라이브 LLM 기반 평가 확장
• HolmesGPT와 같은 다른 베이스라인 (baseline) 추가
• 프로브 (probe) 및 의존성 관련 시나리오 개선
• 공식 PDF 보고서 발행
• 보정 (calibration) 및 기권 (abstention) 지표 정교화
• 재현성 (reproducibility) 및 문서화 개선

마지막 생각

대부분의 AI/SRE 데모는 행동에 집중합니다:

여기 문제가 있습니다. 여기 해결책이 있습니다.

하지만 운영 환경의 신뢰성 (production reliability)은 종종 절제를 요구합니다.

때로는 최선의 답변이 다음과 같을 수 있습니다:

아직 안전하게 조치하기 위한 충분한 증거가 없습니다.

그것이 바로 이 벤치마크가 테스트하도록 설계된 동작입니다.

Kubernetes, SRE, AI 지원 운영 (AI-assisted operations), 또는 신뢰성 평가 (reliability evaluation)에 관심이 있으시다면, 프로젝트에 대한 피드백을 환영합니다.

GitHub 저장소 (repo): github.com/Mayank-013/k8sGPT