요약: AI 에이전트는 실제 장애 상황에서 도움을 줄 수 있지만, 데모들은 세 가지 어려운 부분을 건너뜁니다. 첫째, 에이전트가 추론할 수 있는 것은 검색 가능한 원격 측정(telemetry)만큼만 좋습니다. 둘째, 쓰기 접근 권한을 주어야만 무언가를 '수정'할 수 있습니다. 그리고 모두가 따라 하는 정확한

이러한 솔루션 중 하나를 판매하는 incident.io는 이에 대해 매우 솔직하게 말합니다. RAG (Retrieval-Augmented Generation)를 통해 모델을 귀사의 특정 인프라에 고정하지 않는다면, "당신은 조사된 결과가 아니라 패턴 매칭에 기반한 추측을 얻게 될 것입니다." 이것이 핵심입니다. 에이전트의 한계는 모델이 아니라 귀사의 관측성 (observability)입니다.

이제 귀사의 실제 스택을 살펴보십시오. 런북 (runbooks)이 최신 상태입니까, 아니면 절반 정도가 2023년에 마지막으로 수정된 Confluence 페이지입니까? 의존성을 인코딩하는 실제 서비스 카탈로그 (service catalog)가 있습니까, 아니면 그 그래프가 시니어 엔지니어 한 명의 머릿속에만 들어 있습니까? 배포 (deploys)가 기계가 쿼리할 수 있는 곳에서 메트릭 (metrics)과 상관관계가 형성되어 있습니까, 아니면 두 개의 탭을 띄워놓고 GitHub 옆에서 Datadog을 눈으로 직접 확인하고 있습니까?

대부분의 팀에게 정직한 답변은 "부분적이고, 오래되었으며, 흩어져 있다"일 것입니다. 이를 LLM (Large Language Model)에 입력하면

1. 엔지니어의 노트북 백그라운드에서 MCP (Model Context Protocol) 서버가 실행되고 있습니다. 정상적인 상황입니다. 엔지니어는 이를 통해 어시스턴트가 클러스터와 통신할 수 있게 합니다.
2. 서버는 localhost에서 대기하며, 취약한 버전에서는 인증 없이 Python의 subprocess를 사용하여 shell=True 옵션으로 명령어를 실행(shell out)합니다.
3. 엔지니어가 악성 웹페이지를 방문합니다. 단지 방문했을 뿐입니다. 해당 페이지의 JavaScript가 localhost로 POST 요청을 보내 MCP 서버를 타격하고, 임의의 셸 명령어를 주입합니다.
4. 해당 명령어들은 노트북의 kubeconfig 권한을 가지고 노트북에서 실행됩니다. 시크릿(secrets), ConfigMap, 서비스 계정(service accounts), 악성 포드(pods)를 배포하고 클라우드의 나머지 부분으로 피벗(pivot)할 수 있는 권한까지 포함하여 클러스터 전체가 완전히 장악됩니다.

이 상황의 형태를 곱씹어 보십시오. 당신은 자격 증명을 입력하도록 피싱을 당한 것이 아닙니다. 잘못된 바이너리를 실행한 것도 아닙니다. 당신은 유용한 작은 서버가 프로덕션(production)으로 가는 열쇠를 쥔 채 localhost에 상주하고 있는 동안 웹 서핑을 했을 뿐입니다. 공개 타임라인 자체가 하나의 교훈입니다. 2025년 11월에 보고되었고, 2026년 1월에 패치되었으며, 5월에 공개적으로 상세 내용이 밝혀졌습니다. 수많은 클러스터가 단 하나의 잘못된 탭 하나로 탈취당할 수 있었던 긴 공백기가 존재했습니다.

핵심은 "이 프로젝트 하나가 허술했다"는 것이 아닙니다(물론 인증되지 않은 localhost 리스너에 shell=True를 사용하는 것은 정말 심각한 문제입니다). 핵심은 구조적인 문제입니다. 에이전트에게 손(권한)을 쥐여주는 순간, 당신은 새로운 공격 표면(attack surface)을 만들게 되며, 이는 대개 엔지니어의 브라우저와 클러스터 자격 증명 바로 옆인 엔지니어의 노트북에 위치합니다. 쓰기 권한을 부여하는 모든 도구는 동일한 유형의 버그가 발생할 후보입니다. CVE-2025-65719는 그저 기억하기 쉬운 번호가 붙은 첫 번째 사례일 뿐입니다.

벽 3: 경제성은 지루한 절반에게만 작동한다

텔레메트리(telemetry)가 깨끗하고 액세스 권한을 엄격히 제한했다고 가정해 봅시다. 그렇다면 계산이 맞을까요?

그것은 당신이 어떤 작업을 구매하느냐에 전적으로 달려 있습니다. "AI SRE"의 두 가지 측면은 매우 다른 수익률(ROI)을 보여줍니다.

• 조사 및 문서화 (Investigation and documentation): 이것은 오늘날 실제로 측정 가능한 ROI입니다. 사후 분석(post-mortem) 초안을 자동으로 작성하면, Slack 메시지를 훑으며 재구성하는 데 걸리던 약 90분의 시간이 약 10분의 편집 시간으로 줄어듭니다. 지표의 급증(metric spike)을 원인이 된 배포(deploy)와 상관관계로 연결하고, 30초 내에 확인할 수 있는 인용(citation)을 제공하는 것은 식별 시간(time-to-identify)을 진정으로 압축합니다. 만약 팀이 한 달에 18건의 장애(incident)를 처리한다면, 사후 분석에서 절약되는 시간만으로도 상당한 시간을 아낄 수 있습니다.
• 자율적 복구 (Autonomous remediation): 이것은 데모에서는 화려하지만 실제 가치는 없는 영역입니다. 이를 판매하는 벤더(vendor)들조차 헤드라인 너머를 읽어본다면, 자율적인 운영 환경에서의 조치는 "여전히 제한적이며" 인간의 개입(human in the loop)이 필요하다고 말할 것입니다.

그리고 운영 비용은 결코 사소하지 않습니다. 이러한 에이전트들은 방대한 로그 코퍼스(log corpora)를 훑으며 토큰(token)을 소모하며, 실제 비용을 유발하는 동력은 사용자 라이선스(seat licenses)가 아니라 관측 가능성(observability) 데이터의 볼륨입니다. 공개적으로 논의된 한 멀티 에이전트(multi-agent) SRE 설정은 운영 환경에서 월 약 8,500유로에 달하는 비용이 발생한다고 보고되었습니다 (r/sre의 글 참조). 벤더들이 절대적인 수치에 대해 침묵하는 데에는 이유가 있습니다. 당신은 에이전트 비용뿐만 아니라, 에이전트가 가치를 발휘할 수 있을 만큼 충분히 깨끗한 텔레메트리(telemetry)를 쿼리(query) 가능한 상태로 유지하는 비용까지 지불하고 있는 것입니다.

따라서 솔직한 프레임워크는 다음과 같습니다. 당신은 주로 조사와 서류 작업을 자동화하기 위해 실제 돈을 지불하고 있으며 이는 가치가 있지만, 미래처럼 보였던 부분은 여전히 인간의 승인 게이트(human approval gate) 뒤에 머물러 있습니다.

실제로 가치를 창출하는 지점

"AI SRE는 가짜다"라는 결론을 남기고 싶지는 않습니다. 그렇지 않습니다. 단지 홍보 문구보다 범위가 좁을 뿐입니다. 실제 장애 상황에 적용해 본 결과, 다음과 같은 부분에서 일관되게 이득을 얻을 수 있었습니다:

• 트리아지 (Triage) 및 심각도 분류 (Severity classification). "데이터베이스 CPU 높음"은 P1(최우선 순위) 장애일 수도 있고, 예정된 백업 작업일 수도 있습니다. 과거 장애 이력과 서비스 컨텍스트 (Context)에 접근할 수 있는 에이전트는 이를 올바르게 분류하여 불필요한 호출 (Page)을 줄여줍니다.
• 병렬적 근본 원인 상관관계 분석 (Parallel root-cause correlation). 에이전트는 전체 로그 이력을 바탕으로 여러 가설을 동시에 테스트합니다. 이는 새벽 3시에 사람이 순차적으로, 그리고 느리게 수행하는 작업입니다. 에이전트는 가장 가능성 높은 원인을 제시하며, 사용자는 이를 검증하기만 하면 됩니다.
• 사후 분석 (Post-mortem) 및 타임라인 초안 작성. 가장 확실하고 신뢰할 수 있는 이점입니다. 알림 (Alert), 배포 (Deploy), 채팅 기록으로부터 타임라인을 재구성하도록 맡긴 뒤, 사용자는 이를 편집하기만 하면 됩니다.

운영 환경 (Production)과 맞닥뜨렸을 때 살아남는 사고 모델은 "글래스 박스 (Glass box)", 즉 투명한 상자 모델입니다. 블랙 박스 (Black box)는 "근본 원인은 auth-service의 메모리 누수입니다"라고 말하지만, 왜 그렇게 생각하는지 알 수 없습니다. 반면 글래스 박스는 "14:31에 auth-service 메모리가 98%임을 보여주는 이 로그 라인과, 세션 캐싱을 변경한 이 커밋 (Commit) 사이의 상관관계를 바탕으로 볼 때, 원인은 캐시가 제거되지 않는 것으로 보입니다"라고 말하며 두 출처를 모두 연결해 줍니다. 사용자는 30초 만에 이를 검증할 수 있습니다. 만약 벤더 (Vendor)가 이러한 인용 경로 (Citation trail)를 보여주지 못한다면, 미련 없이 돌아서십시오.

다음은 제가 의도적으로 망가뜨린 실제 클러스터 (Cluster)에서 이 패턴을 적용한 사례입니다. 읽기 전용 (Read-only) 에이전트가 증상, 경고 이벤트 (Warning event), 그리고 이를 유발한 변경 사항을 추출한 뒤, 실제 커밋과 대조하여 확인할 수 있는 가설을 사용자에게 전달합니다:

그리고 여러분을 안전하게 지켜주는 운영 패턴은 단일 단계가 아닌 세 단계로 이루어집니다:

에이전트는 증거와 함께 **제안(proposes)**합니다. 사람이 이를 **승인(approves)**합니다. 그런 다음 제한된 범위 내에서 감사(audited) 가능한 경로를 통해 동작이 **실행(executes)**됩니다. AI가 롤백(rollback)을 위한 PR을 초안 작성하면, 당신은 버튼을 클릭합니다. 제안의 품질이 아무리 좋아지더라도, 중간 단계가 사라지게 두어서는 안 됩니다.

어차피 실행할 계획이라면, 이렇게 하세요

아마 당신은 이를 시도해 볼 것이므로, 이것이 귀하의 환경에서 CVE-2025-65719가 되지 않도록 방지하는 짧은 목록을 정리해 드립니다:

1. 기본값은 읽기 전용(Read-only). 에이전트의 서비스 계정(ServiceAccount)은 특별한 이유가 없는 한 get, list, watch 권한만 가져야 하며 그 외의 권한은 없어야 합니다. 최소한의 Role은 다음과 같습니다:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata
...

이를 전용 ai-sre-readonly ServiceAccount에 바인딩(Bind)하세요. create, update, delete, patch는 허용하지 않습니다. 정말로 필요한 경우가 아니라면 Secret을 읽어서도 안 되며, 필요한 경우에도 지정된 리소스(named resources)로 범위를 제한하세요. kubectl auth can-i를 사용하면 경계를 구체화할 수 있으며, 다음은 해당 서비스 계정의 실제 출력 결과입니다:

1. MCP 서버를 네트워크에 절대 노출하지 마세요. localhost에만 바인딩하고, 로컬에서도 인증(authentication)이나 API 키를 요구하며, '직접 웹 접근' 같은 편의 기능은 잠재적 위험 요소로 간주해야 합니다. 전체 CVE는 인증되지 않은 localhost 리스너가 웹페이지를 통해 도달할 수 있다는 점에 달려 있었습니다.

2. 패치하고 버전을 고정하세요(Patch and pin). kubectl-mcp-server를 사용한다면 1.2.0 이상 버전을 사용해야 합니다. MCP 서버는 다른 모든 특권 종속성(privileged dependency)처럼 취급하세요. 보안 권고(advisories)를 확인하고, 버전을 고정하며, 스캔해야 합니다.

3. 모든 쓰기 작업에 대해 사람의 승인 게이트를 유지하세요. 제안(Propose), 승인(Approve), 실행(Execute). 쓰기 작업을 PR이나 명시적인 확인 절차 뒤에 두고, 이를 정당화한 근거(citations)와 함께 모든 행동을 감사 추적(audit trail)에 기록해야 합니다.

4. 관측 가능성(observability)을 먼저 개선하세요. 만약 운영 매뉴얼(runbooks)이 오래되었고 토폴로지가 누군가의 머릿속에 존재한다면, 에이전트에 돈을 쓰기 전에 그곳에 돈을 써야 합니다. 에이전트는 이미 가지고 있는 데이터 품질을 양방향으로 증폭시키기 때문입니다.

실제 핵심 교훈(The actual takeaway)