-->

멀티테넌트 GPU 클러스터를 운영하면서 온콜 부담을 줄이려고 LLM 에이전트에게 인시던트 원격조치를 맡길지 고민해본 SRE와 MLOps 엔지니어라면, 이 글에서 소개하는 논문이 던지는 질문에 이미 한 번쯤 부딪혀 봤을 것입니다. 에이전트가 스스로 판단해 조치하도록 둘 것인가, 아니면 사람을 호출할 것인가. 이 경계를 직관이나 팀 회의에서의 감으로 정하는 대신, 인시던트 유형별로 위험도를 수식화하고 안전 상한선 아래에서 회복 시간을 최대한 줄이는 임계값을 실제로 계산해낸 연구입니다. Kueue 큐잉과 Kyverno 어드미션 정책으로 GPU 워크로드를 운영하는 조직이라면 곧바로 참고할 만한 방법론을 담고 있습니다.

자율 조치와 완전 회피, 둘 다 답이 아니다

스케줄러 설정 하나가 어긋나거나, 퍼시스턴트 볼륨이 멈추거나, 노드가 메모리 압박에 시달리면 그 위에서 돌아가던 학습·추론 워크로드가 멈춰 서고, 결국 온콜 엔지니어가 시간에 쫓기며 원인을 파악해 고쳐야 합니다. 여기서 부딪히는 비용은 두 가지입니다. 하나는 평균 복구 시간(MTTR)으로, GPU 워크로드가 멈춰 있는 매 순간이 낭비된 용량이자 깨진 서비스 수준 목표입니다. 다른 하나는 온콜 부담으로, 기계적으로 되돌릴 수 있는 단순한 문제 때문에 사람을 매번 호출하는 일은 느릴 뿐 아니라 운영자를 소진시킵니다. LLM 에이전트가 텔레메트리와 컨트롤 플레인 API를 관찰하고 판단해 조치하는 폐루프를 사람 없이 돌리자는 제안이 매력적으로 들리는 이유입니다.

문제는 그 매력만큼 위험도 크다는 점입니다. 모든 것을 자율로 조치하는 에이전트는 언젠가 되돌릴 수 없는 실수를 저지릅니다. 오래된 스냅샷에서 볼륨을 복원하다 실제 데이터를 지워버리거나, 용량을 확보하려고 다른 테넌트의 살아 있는 GPU 작업을 선점해버리는 식입니다. 반대로 모든 것을 사람에게 넘기는 에이전트는 안전하지만 아무것도 자율로 복구하지 못해 애초에 자동화를 도입한 이유를 무색하게 만듭니다. 이 논문의 벤치마크에서도 두 극단의 대가가 뚜렷하게 드러납니다. “항상 에스컬레이션” 정책은 파국적 방치율이 0%지만 MTTR 개선율도 정확히 0%였고, “항상 자율조치” 정책은 MTTR을 96.7% 줄였지만 진짜 위험한 인시던트의 100%를 잘못 자율조치해버렸습니다. 관심을 가져야 할 지점은 자동화를 할지 말지가 아니라, 자율 행동과 에스컬레이션 사이의 경계를 어디에 어떻게 방어 가능하게 그을 것인가 하는 점입니다.

위험도 공식과 176개 인시던트로 경계선을 계산하다

연구진은 이 경계선을 out-of-memory(OOM), 퍼시스턴트 볼륨 클레임(PVC) 실패, 노드 압박, 스케줄러 기아 네 가지 인시던트 유형에 걸쳐 다룹니다. 코드 생성 분야의 loop-engineering에서 나온 “컴파일러를 보상 신호로 쓴다”는 아이디어를 인프라 운영으로 확장한 프레임입니다. 코드에서는 컴파일러나 테스트 스위트가 성공 여부를 객관적으로 판정했다면, 인프라 원격조치에서는 kubectl로 얻는 진단 신호가 그 역할을 맡습니다. 다만 이 신호도 코드의 테스트 스위트와 마찬가지로 완벽한 잣대는 아니어서, 진단 신호가 초록불이라고 해서 조치가 진짜로 안전했다는 보장까지는 되지 않는다는 전제를 논문 전체에서 분명히 하고 있습니다.

실제 살아있는 클러스터에 에이전트를 붙여 실험하면 통제 불가능한 변수가 너무 많아지기 때문에, 연구진은 실제 조직의 GitOps 저장소에서 가져온 22개의 Kueue·Kyverno YAML 매니페스트를 8가지 원격조치 액션 클래스와 교차시켜 176개의 인시던트 이벤트를 만들었습니다. 각 이벤트의 위험/안전 정답 라벨은 되돌릴 수 있는지, 데이터가 손실되는지, 테넌트 경계를 넘는지를 기준으로 한 명시적 기준표에서 나왔습니다. 실제 배포된 에이전트의 확신도 대신, 액션 클래스의 되돌릴 수 있는 정도에 따른 기본 위험도, YAML 라인 수로 정규화한 구조적 폭발반경 지표, 클러스터 전역에 영향을 미치는 Kyverno 어드미션 정책인지 여부라는 세 요소를 가중합산한 투명한 위험도 공식을 세웠습니다. 이 공식은 학습된 모델이 아니라 사람이 설계한 대리 지표라는 점을 논문은 반복해서 강조합니다.

이 위험도 점수가 임계값 아래면 자율조치, 그 이상이면 사람에게 넘기는 단순한 결정 규칙 위에서, 파국적 방치율을 2% 이하로 묶는 안전 상한선을 걸고 임계값을 훑었습니다. 그 결과 얻어진 전역 최적 임계값(τ=0.325)은 파국적 방치가 전혀 없는 상태에서 MTTR을 41.7% 줄였고, 이는 항상 에스컬레이션과 항상 자율조치라는 두 극단을 모두 지배하는 지점이었습니다.

MTTR-vs-Safety Pareto Frontier 임계값 τ가 0.35를 넘어서면 파국적 방치율(실선)이 가파르게 치솟는 반면, 불필요한 에스컬레이션율(점선)은 계속 낮아집니다. 삼각형으로 표시된 전역 최적점(τ=0.325)에서 파국적 방치 없이 MTTR을 41.7% 줄였습니다. AI Platform Demo 클러스터의 로컬 벤치마크(176개 합성 인시던트 이벤트)로 측정한 결과이며, 자율조치 지연은 40초, 에스컬레이션 지연은 1200초로 가정했습니다.

진짜 핵심: 인시던트 유형별로 임계값을 따로 잡아야 한다

논문의 중심 발견은 여기서 한 걸음 더 나아갑니다. 인시던트 유형마다 폭발반경과 테넌트 노출도가 크게 다르기 때문에, 하나의 전역 임계값으로는 이 차이를 담아낼 수 없다는 것입니다. 네 가지 유형별로 안전 상한선(2%)을 유지하면서 각각 최적 임계값을 따로 계산했더니, 노드 압박은 보수적인 τ=0.30(28.6% 개선), PVC 실패는 τ=0.35(43.9% 개선), 스케줄러 기아는 τ=0.45(39.5% 개선), OOM은 훨씬 관대한 τ=0.475(96.7% 개선)로 서로 크게 갈렸습니다. 이 네 유형의 개선율을 평균 내면 52.2%로, 단일 전역 임계값을 모든 유형에 똑같이 적용했을 때의 41.7%보다 약 10.4%포인트 더 높습니다. 같은 안전 상한선을 지키면서도 유형별로 임계값을 나눠 잡는 것만으로 그만큼의 자율성을 추가로 확보할 수 있다는 뜻입니다.

Per-Incident-Type MTTR Reduction Under 2% Safety Ceiling 인시던트 유형별로 임계값을 따로 보정하면 평균 52.2%의 MTTR 개선을 얻어, 단일 전역 임계값의 41.7%를 웃돕니다. 유형마다 폭발반경과 테넌트 노출도가 다르기 때문입니다. 같은 로컬 벤치마크에서 측정했으며, OOM은 이 기준표에서 위험 라벨이 붙은 액션이 하나도 없어 유독 관대한 임계값(τ=0.475)을 쓸 수 있었습니다.

이 격차가 생기는 이유는 명확합니다. 전역 임계값은 가장 위험한 유형(노드 압박이나 테넌트를 넘나드는 스케줄러·PVC 조치)까지 안전 상한선 안에 묶어두려다 보니 보수적으로 잡힐 수밖에 없고, 그 대가는 원래 훨씬 더 자율적으로 돌아도 괜찮았을 유순한 유형들이 함께 치르게 됩니다. 유형별 보정은 이 결합을 풀어냅니다. 실무적으로 보면, 자율 운영 플랫폼이 “위험 허용치” 하나짜리 전역 손잡이만 노출하는 대신, 각 인시던트 클래스가 가진 되돌릴 수 있는 정도와 테넌트 경계 프로필에 맞춰 에스컬레이션 임계값을 따로 잡아야 한다는 설계 시사점으로 이어집니다.

회사와 커뮤니티에 남기는 것

이 결과는 ThakiCloud가 Kueue·Kubernetes 기반 GPU 인시던트 대응을 실제로 자동화해나갈 때 실측 가능한 자율성 경계 프레임워크로 곧바로 쓸 수 있습니다. MTTR과 온콜 부담을 줄이겠다는 계획을 감이 아니라 근거 데이터 위에서 세울 수 있게 됩니다. 더 넓게는 무인 인프라 운영을 시도하는 다른 조직도 재사용할 수 있는 안전 경계 설계와 에스컬레이션 정책 방법론을 제시한다는 점에서 의미가 있습니다. GPU 클러스터뿐 아니라 스키마 마이그레이션 대 단순 행 수정을 오가는 데이터베이스, 라우팅 변경 대 장비 초기화를 오가는 네트워크, 스냅샷 복원을 다루는 스토리지 등 되돌릴 수 있는 조치와 되돌릴 수 없는 조치가 섞여 있는 어떤 멀티테넌트 컨트롤 플레인에도 같은 구조가 그대로 적용됩니다. 학술적으로는 코드 생성에서 쓰이던 “컴파일러를 보상 신호로” 삼는 loop-engineering 아이디어를 인프라 원격조치 영역으로 명확히 확장하고, 자율성과 안전성의 트레이드오프를 인시던트 유형별로 정량화하는 새로운 측정 방법론을 더했다는 데 기여가 있습니다.

한계도 분명히 짚어야 합니다

이 결과를 읽을 때 반드시 기억해야 할 전제가 있습니다. 연구진은 실제 살아있는 클러스터에 LLM 에이전트를 배치해 실험하지 않았습니다. 22개의 YAML 매니페스트는 실제 GitOps 저장소에서 가져온 진짜 자원이지만 176개의 인시던트 이벤트와 그 결과는 구성된 것이지 실제 운영 로그에서 관측한 것이 아닙니다. 위험도 공식 역시 학습된 모델이 아니라 사람이 설계한 투명한 대리 지표이며 실제 배포된 에이전트의 확신도를 재현한다는 보장은 없습니다. 자율조치 40초, 에스컬레이션 1200초라는 지연 시간 가정도 실제 인시던트 로그에서 측정한 값이 아니라 전형적인 컨트롤러 재조정 시간과 온콜 서비스 수준 목표를 참고한 추정치입니다. 2%라는 안전 상한선도 데이터에서 유도한 값이 아니라 되돌릴 수 없는 조치를 향한 보수적 태도를 반영한 정책적 선택입니다.

OOM 유형이 52.2%라는 평균 개선율을 크게 끌어올린다는 점도 짚어야 합니다. 이번 기준표에서 OOM 액션 두 가지가 모두 안전으로 분류돼 있기 때문에 생긴 결과이며, 다른 테넌트의 파드를 강제 종료하는 조치까지 OOM 대응에 포함시키면 이 수치는 달라질 수 있다고 논문 스스로 밝히고 있습니다. 그래서 이 연구는 특정 배포된 에이전트의 성능을 측정한 것이 아니라 임계값 보정 방법론 자체의 타당성을 검증한 것으로 읽어야 합니다. 다음 단계로는 실제 에이전트의 검증 루프 신호로 위험도 공식을 대체하고 실제 인시던트 로그로 검증하는 작업, 그리고 컨포멀 위험 제어를 얹어 경험적 안전 보장을 분포 무관 보장으로 끌어올리는 작업이 남아 있습니다.

논문 상세 페이지는 다음에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-07-16-safe-autonomy-k8s-remediation

참고