Azure SRE Agent를 활용한 자율적 AKS 장애 대응: 알람 발생부터 복구 검증까지 수분 내 완료

AKS(Azure Kubernetes Service) 클러스터에서 Sev1(최고 등급) 알람이 발생했을 때, 탐지 자체가 어려운 일은 거의 없습니다. 진짜 어려운 것은 그다음 단계입니다. 무엇이 왜 고장 났는지 증명하고, 장애 범위를 넓히지 않으면서 문제를 해결하는 과정은 시간적 압박 속에서 진행되며, 종종 새벽 2시에 발생하기도 합니다.

Azure SRE Agent는 이 간극을 메우기 위해 설계되었습니다. 이 에이전트는 Azure 네이티브 관측성(Observability), AKS 진단 기능, 엔지니어링 워크플로우를 단일 장애 대응 루프로 연결합니다. 이를 통해 사람이 대시보드를 뒤지거나 임시로 kubectl 명령어를 실행할 때까지 기다리지 않고도 조사, 복구, 검증 및 후속 조치를 수행할 수 있습니다.

이 포스트에서는 두 가지 실제 AKS 장애 시나리오를 통해 이 루프를 살펴봅니다. 두 사례 모두 에이전트가 인시던트를 수신하고, Azure Monitor 및 AKS 신호를 조사하고, 타겟팅된 복구 조치를 적용하고, 복구를 검증한 뒤, Microsoft Teams를 통해 팀원들에게 상황을 알리면서 GitHub에 후속 과제를 생성하는 과정을 거쳤습니다.

핵심 개념

Azure SRE Agent는 단순히 인프라 접근 권한을 가진 대화형 비서가 아니라, 거버넌스가 적용된 장애 대응 시스템입니다. AKS 장애 대응 워크플로우에서 가장 중요한 5가지 개념은 다음과 같습니다.

1. 인시던트 플랫폼: 인시던트가 시작되는 곳입니다. 이 데모에서는 Azure Monitor를 사용합니다.
2. 기본 제공 Azure 기능: 에이전트는 외부 커넥터 없이도 Azure Monitor, Log Analytics, Azure Resource Graph, Azure CLI/ARM, AKS 진단 기능을 직접 사용합니다.
3. 커넥터: GitHub, Teams, Kusto, MCP 서버 등의 시스템으로 워크플로우를 확장합니다.
4. 권한 수준: 조사 및 읽기 중심 작업을 위한 Reader 권한과, 허용된 경우 운영 변경을 위한 Privileged 권한이 있습니다.
5. 실행 모드: 승인 후 실행되는 Review 모드와 직접 실행되는 Autonomous 모드가 있습니다.

가장 중요한 프로덕션 제어 수단은 프롬프트의 품질이 아니라 권한 수준과 실행 모드입니다. 맞춤형 지침(Custom Instructions)은 워크플로우의 행동을 구체화할 수 있지만, RBAC(역할 기반 액세스 제어), 텔레메트리 품질 또는 도구 가용성을 대체할 수는 없습니다.

안전한 프로덕션 배포 경로: 시작: Reader + Review → 다음: Privileged + Review → 최종: Privileged + Autonomous (신뢰할 수 있는 좁은 범위의 장애 경로에만 적용)

데모 환경

이를 재현하고 싶은 경우 전체 스크립트와 매니페스트를 사용할 수 있습니다.

• 데모 저장소: github.com/hailugebru/azure-sre-agents-aks. README에 설정 및 구성 세부 정보가 포함되어 있습니다.

이 환경은 노드 자동 프로비저닝(NAP), Cilium 기반 Azure CNI Overlay, 관리형 Prometheus 메트릭, AKS Store 샘플 마이크로서비스 애플리케이션, 그리고 인시던트 트리거 조사 및 복구를 위해 구성된 Azure SRE Agent를 갖춘 AKS 클러스터를 사용합니다. 이 설정은 의도적으로 현실적이면서도 최소한으로 구성되었습니다. 장애 대응 워크플로우 자체에 집중하면서도 실제 AKS 장애 모드를 연습하기에 충분한 환경을 제공합니다.

Azure Monitor → 액션 그룹 → Azure SRE Agent → AKS 클러스터 
(알람) (웹훅) (조사 / 수정) (복구) 
↓ 
Teams 알림 + GitHub 이슈 → GitHub 에이전트 → 검토를 위한 PR

에이전트 구성 방식

구성 요소는 범위(Scope), 권한, 인시던트 수신, 대응 모드의 네 가지로 요약됩니다. 에이전트의 범위를 데모 리소스 그룹으로 한정하고, Azure 액세스를 위해 사용자 할당 관리 ID(UAMI)를 사용했습니다. 이 범위가 에이전트가 조사할 수 있는 대상을 정의하며, RBAC은 수행할 수 있는 작업을 결정합니다.

실습 환경에서 에이전트가 복구를 완벽히 수행할 수 있도록 프로덕션 기본 권장 사항보다 넓은 AKS 권한을 부여했습니다. 여기서 중요한 차이점이 있습니다. 권한은 에이전트가 액세스할 수 있는 대상을 제어하고, 실행 모드는 에이전트가 승인을 요청할지 아니면 직접 행동할지를 제어합니다. 이 시나리오에서는 Azure Monitor를 인시던트 플랫폼으로 사용했고, 수동 승인 단계 없이 워크플로우가 실행될 수 있도록 신뢰할 수 있는 특정 경로에 대해 대응 계획을 Autonomous로 설정했습니다.

또한, 워크플로우가 Azure를 넘어 확장될 수 있도록 Teams 및 GitHub 연동을 추가했습니다. Teams는 인시던트 발생 중 주요 진행 상황을 업데이트하고, GitHub은 복구 후 지속적인 후속 조치를 제공합니다. 전체 설정은 README를 참조하세요.

문맥(Context)에 대한 참고 사항: 환경, 리소스, 런북, 컨벤션에 대해 더 많은 문맥을 에이전트에 제공할수록 성능이 향상됩니다. 범위 경계, 알려진 워크로드, 공통 장애 패턴 및 관련 문서 링크는 에이전트의 조사를 더욱 날카롭게 만들고 탐색 시간을 단축합니다. 맞춤형 지침과 커넥터 콘텐츠를 사후 고려 사항이 아닌 최우선 입력값으로 취급하십시오.

두 가지 인시던트, 두 가지 대응 모드

이 인시던트들은 동일한 세션의 클러스터에서 발생했으며 두 가지 현실적인 운영 모드를 보여줍니다.

1. 알람 트리거 자동화: Azure Monitor 알람이 발생할 때 에이전트가 작동합니다.
2. 애드혹(Ad hoc) 채팅 조사: 엔지니어가 먼저 증상을 발견하고 에이전트에게 조사를 요청합니다.

실제 환경에서는 둘 다 중요합니다. 전자는 확장을 위한 경로이고, 후자는 운영자 보조를 위한 경로입니다.

인시던트 1. CPU 고갈 (알람 기반, MTTR 약 8분)

makeline-service 배포 매니페스트에 시작 단계에서 실행 불가능한 CPU 및 메모리 설정이 포함되어 있었습니다.

resources:
  requests:
    cpu: 1m
    memory: 6Mi
  limits:
    cpu: 5m
    memory: 20Mi

5분 이내에 Azure Monitor에서 pod-not-healthy Sev1 알람이 발생했습니다. 에이전트가 즉시 이를 수신했습니다.

다음은 에이전트가 포드 상태, 프로브 동작, 종료 코드를 통해 내린 핵심 진단 결론입니다.

"종료 코드 1(137 아님)은 OOMKill 가능성을 배제합니다. 포드는 런타임 메모리 압박이 아니라 시작 단계에서 실패했습니다. CPU 제한 5m는 시작 프로브(startup probe)가 타임아웃되기 전에 프로세스가 포트를 바인딩하기에 부족합니다. 이는 리소스 고갈 시나리오가 아니라 구성 오류입니다."

이것은 온콜(on-call) 엔지니어가 압박 속에서 CPU 고갈로 인한 시작 실패인지, 메모리 압박으로 인한 런타임 종료인지를 증명하기 위해 몇 분 동안 고군분투해야 하는 바로 그 지점입니다.

이후 에이전트는 다음을 수행했습니다.

• kubectl top을 사용하여 구성된 제한의 112~200%를 사용하는 CPU 스로틀링 포드 3개를 추가로 식별했습니다.
• makeline-service, virtual-customer, virtual-worker, mongodb 등 4개의 워크로드에 패치를 적용했습니다.
• 클러스터 전체에서 재시작 횟수 0으로 모든 영향받은 포드가 정상 가동 상태로 돌아왔음을 검증했습니다.

![이미지] Azure SRE Agent의 인시던트 기록 블레이드: 4개의 패치 적용, 불량 포드 0개 - 사람의 개입 없이 전체 클러스터 복구 완료.

결과: 약 8분 만에 전체 클러스터 복구 완료, 사람의 개입 0회.

인시던트 2. OOMKilled (채팅 기반, MTTR 약 4분)

두 번째 사례의 경우, 의도적으로 리소스를 작게 할당한 order-service 버전을 배포했습니다.

kubectl apply -f .\manifests\aks-store\order-service-changed.yaml -n pets

알람 트리거가 아닌 인터랙티브 문제 해결 흐름을 보여주기 위해 포드 단계(Pod Phase) 알람이 발생하기 전에 채팅으로 조사를 시작했습니다. 이는 알람 누락이 아니라 데모를 위한 선택이었습니다. CrashLoopBackOff는 포드 단계가 아니라 컨테이너 대기 사유이므로, 프로덕션 환경에서는 포드 단계만 보는 것이 아니라 Prometheus 기반의 크래시 루프 신호를 통해 커버리지를 확보해야 합니다. 다음은 제가 이러한 등급의 실패를 잡기 위해 Azure Monitor에서 사용하는 PromQL 쿼리입니다.

sum by (namespace, pod) ( ( max_over_time( kube_pod_container_status_waiting_reason{ namespace="pets", reason="CrashLoopBackOff" }[5m] ) == 1 ) and on (namespace, pod, container) ( increase( kube_pod_container_status_restarts_total{ namespace="pets" }[15m] ) > 0 ) ) > 0

이 쿼리는 지난 5분 이내에 컨테이너가 CrashLoopBackOff 상태였으며, 지난 15분 동안 재시작 횟수가 증가한 경우 실행됩니다. 프로덕션에서는 하드코딩된 네임스페이스를 정규식 매처로 바꾸거나 제거하여 모든 네임스페이스를 커버하세요.

프롬프트: pets 네임스페이스의 order-service 포드가 정상이 아닙니다. 조사해서 근본 원인을 파악하고 수정해 주세요.

에이전트의 추론:

"컨테이너 로그가 비어 있습니다. 프로세스가 첫 로그 라인을 쓰기도 전에 종료되었습니다. 종료 코드 137은 OOMKill을 확인해 줍니다. ConfigMap에 NODE_OPTIONS가 없는 것으로 보아 V8 힙 오설정은 아닙니다. 20Mi 제한은 포드에서 관찰된 런타임 베이스라인 50Mi보다 12.8배 낮습니다. 이 제한은 이 워크로드에서 결코 유지될 수 없는 수준입니다."

에이전트는 메모리 제한(20Mi → 128Mi)과 요청(10Mi → 50Mi)을 늘린 다음, 새 포드가 재시작 없이 74Mi/128Mi(사용률 58%)에서 안정화되었음을 검증했습니다.

결과: 수동 클러스터 조작 없이 약 4분 만에 서비스 복구 완료.

나란히 비교

이것이 중요한 이유

대부분의 AKS 환경은 이미 Azure Monitor와 관리형 Prometheus를 통해 풍부한 텔레메트리를 방출하고 있습니다. 여전히 수동으로 남아있는 부분은 대응입니다. 엔지니어들이 대시보드를 훑고, 임시 kubectl 명령어를 실행하고, 시간 압박 속에서 핫픽스를 적용하는 과정 말이죠. Azure SRE Agent는 반복 가능한 조사 및 복구 경로를 자동화된 워크플로우로 전환함으로써 이를 바꿉니다.

가치 있는 것은 단순히 에이전트가 CPU 제한을 패치했다는 사실이 아닙니다. 장애 모드와 상관없이 조사, 복구, 검증 루프가 동일하게 작동하며, 여러분의 팀원들이 잠든 사이에도 이 과정이 진행된다는 점입니다.

이 실습에서의 영향은 측정 가능했습니다.

이 결과는 2026년 4월 10일 통제된 실행 환경에서 도출되었습니다. 실제 결과는 알람 품질, 클러스터 규모 및 활성화된 자동화 수준에 따라 달라질 수 있습니다. 참고로 PagerDuty 및 Datadog의 업계 보고서에 따르면 Kubernetes 환경의 수동 Sev1 MTTR은 일반적으로 30~120분 범위입니다.

Teams + GitHub 후속 조치

런타임 복구는 이야기의 절반일 뿐입니다. 포드가 다시 정상화되었을 때 워크플로우가 끝나버리면, 다음 배포 때 동일한 문제가 다시 발생합니다. 이것이 바로 장애 이후의 경로가 중요한 이유입니다.

인시던트 1이 해결된 후, Azure SRE Agent는 GitHub 커넥터를 사용하여 인시던트 요약, 근본 원인 및 런타임 변경 사항이 포함된 이슈를 생성했습니다. 데모에서는 해당 이슈를 GitHub Copilot 에이전트에게 할당했고, 이 에이전트는 소스 매니페스트를 핫픽스 내용과 일치시키기 위한 풀 리퀘스트(PR) 초안을 열었습니다. 에이전트는 단순히 이슈를 여는 것뿐만 아니라 워크플로우 내에서 직접 PR을 제출하도록 구성할 수도 있으므로, 누군가 알림을 확인했을 때는 이미 검토 대기열에 수정 사항이 올라와 있게 됩니다. 머지 전의 최종 제어 지점은 여전히 사람의 검토로 유지됩니다. GitHub 커넥터에 대한 자세한 설정은 데모 저장소 README에, 공식 참조 문서는 Azure SRE Agent 문서에 있습니다.

Azure SRE Agent가 실시간 문제를 해결하고, GitHub 후속 조치가 지속적인 소스 수정을 준비하여 향후 배포 시 동일한 구성 문제가 재발하지 않도록 합니다.

![이미지] 운영에서 엔지니어링으로의 핸드오프: Azure SRE Agent가 실시간 클러스터를 수정하고, GitHub Copilot 에이전트가 지속적인 소스 수정을 준비하여 동일한 오설정이 다시 배포되지 않도록 방지합니다.

동시에 Teams 커넥터는 인시던트 진행 중에 주요 단계별 업데이트를 게시했습니다.

• 조사 시작
• 근본 원인 및 복구 조치 식별
• 인시던트 해결

Teams는 실시간 상황 인식을 담당하고, GitHub은 지속적인 엔지니어링 후속 조치를 담당합니다. 이들이 함께 운영과 소프트웨어 전달 사이의 간극을 메웁니다.

핵심 요약

기억해야 할 세 가지:

1. Azure SRE Agent를 인프라 접근 권한이 있는 챗봇이 아니라 거버넌스가 적용된 장애 대응 시스템으로 취급하십시오. 가장 중요한 제어 요소는 프롬프트 품질이 아니라 권한 수준과 실행 모드입니다.
2. 기존 인시던트 플랫폼에 탐지 기능을 고정하십시오. 이 데모에서는 Prometheus와 Azure Monitor를 사용했지만, 신호가 어디에 있든 이 패턴을 적용할 수 있습니다. 커넥터를 사용하여 워크플로우를 외부로 확장하세요. 실시간 조율에는 Teams를, 지속적인 엔지니어링 후속 조치에는 GitHub을 사용하십시오.
3. 편안한 지점부터 시작하십시오. 이제 막 시작 단계라면 하나의 리소스 그룹, 하나의 인시던트 유형, 그리고 Review 모드부터 시작하십시오. 텔레메트리가 흐르고, RBAC이 올바르게 범위 지정되었으며, 알림 규칙이 실제 관심 있는 장애 모드를 커버하는지 검증한 후 Autonomous를 활성화하십시오. 각 레이어가 신뢰될 때만 확장하십시오.

다음 단계

• 포드 단계 규칙을 보완하기 위해 CrashLoopBackOff, ImagePullBackOff 및 노드 리소스 압박에 대한 Prometheus 기반 알람 커버리지를 추가하세요.
• 단일 클러스터 경로가 신뢰되고 검증되면 다중 클러스터 관리 범위로 확장하세요.
• 에이전트를 다중 서비스 연쇄 실패 시나리오에서 테스트하여 여전히 사람의 에스컬레이션이 필요한 지점을 파악하세요.

리소스