Agentic AI와 Runbook 자동화: 장애 대응은 어떻게 바뀔까?

알람 이후의 탐색, 판단, 승인 흐름을 AI Agent로 줄이는 방법

"장애 대응 자동화의 목표는 사람을 없애는 것이 아니라, 사람이 판단해야 할 순간까지 더 빨리 도착하게 만드는 것이다."

---

 

1. 장애 대응에서 가장 오래 걸리는 일

1.1 알람은 빠르지만 판단은 느리다

운영 환경에서 알람은 이미 충분히 빠르다. CloudWatch Alarm, Prometheus Alertmanager, Datadog, Slack 알림까지 붙어 있으면 문제 발생 자체는 금방 알 수 있다.

그런데 실제 장애 대응에서 시간이 오래 걸리는 부분은 알람 수신이 아니다. 알람 이후에 "무엇을 먼저 봐야 하는가"를 판단하는 과정이다.

1.1.1 운영자가 동시에 확인하는 정보

예를 들어 API 지연 시간이 갑자기 증가하면 운영자는 보통 다음 정보를 동시에 확인한다.

• 애플리케이션 로그
• p95, p99 latency와 error rate
• 최근 배포 이력
• Kubernetes Pod restart와 event
• 데이터베이스 커넥션 상태
• 외부 API 응답 시간
• 기존 장애 티켓과 Runbook

이 과정은 숙련된 운영자에게도 피곤하다. 특히 야간 온콜, 신규 서비스, 복잡한 마이크로서비스 환경에서는 "첫 10분"이 그대로 장애 대응 품질을 좌우한다.

1.1.2 왜 지금 Agentic AI가 거론되는가

• 운영 데이터가 흩어져 있다: 로그, 메트릭, 이벤트, 배포 이력, 티켓이 서로 다른 도구에 있다.
• Runbook은 있지만 찾기 어렵다: 문서는 존재해도 현재 증상에 맞는 문서를 고르는 일이 별도 판단이다.
• 자동 조치보다 자동 정리가 먼저 필요하다: 많은 팀은 아직 AI에게 변경 권한을 주기보다, 원인 후보와 확인 순서를 정리해주는 기능을 더 현실적으로 필요로 한다.

 

1.2 핵심 질문

💡 핵심 질문: Agentic AI를 장애 대응에 붙인다면, 어디까지 자동화하고 어디서 사람 승인을 받아야 할까?

1.2.1 이 글에서 가져갈 것

• Agentic AI가 Runbook 자동화에서 맡을 수 있는 현실적인 역할
• AWS 운영 환경에서 CloudWatch, Systems Manager Automation, IAM과 연결해 보는 방식
• 프로덕션 장애 대응에 AI Agent를 붙일 때 반드시 나눠야 할 권한과 승인 기준

---

 

2. Runbook 자동화와 Agentic AI의 차이

2.1 Runbook은 절차이고 Agent는 조율 계층이다

2.1.1 Runbook 자동화의 기본 역할

Runbook은 장애 대응 절차를 문서화한 것이다. 예를 들어 CPU 사용률 급증, Pod CrashLoopBackOff, 배포 실패, DB 커넥션 포화 같은 상황에서 어떤 순서로 확인하고 어떤 조치를 할지 적어둔 운영 지식이다.

기존 자동화는 이 Runbook 중 일부를 스크립트나 워크플로우로 실행한다. AWS에서는 Systems Manager Automation runbook을 이용해 반복 작업을 자동화할 수 있고, EventBridge나 CloudWatch Alarm과 연결해 특정 이벤트 이후 진단 작업을 시작할 수도 있다.

⚠️ 흔한 오해: Agentic AI가 Runbook을 대체한다고 생각하기 쉽지만, 실제로는 좋은 Runbook이 있어야 Agent도 좋은 판단을 할 수 있다.

2.1.2 기존 방식과 Agentic AI 방식

기존 방식	Agentic AI를 붙인 방식
운영자가 알람을 보고 직접 로그와 메트릭을 조회한다	Agent가 알람 컨텍스트를 기준으로 관련 로그, 메트릭, 이벤트를 먼저 모은다
운영자가 맞는 Runbook을 검색한다	Agent가 증상과 서비스명을 기준으로 Runbook 후보를 추천한다
운영자가 Slack이나 티켓에 수동으로 상황을 정리한다	Agent가 근거, 원인 후보, 다음 조치 초안을 작성한다

Agentic AI는 "명령 하나를 자동 실행하는 도구"라기보다 여러 운영 도구를 조율해 현재 상황을 정리하는 계층에 가깝다.

 

2.2 장애 대응 흐름은 이렇게 바뀐다

2.2.1 전체 흐름

알람 발생
    │
    ▼
Agent가 알람 컨텍스트 수집
    │
    ├── 로그 조회
    ├── 메트릭 조회
    ├── 최근 배포 이력 확인
    └── 클라우드 이벤트 확인
    │
    ▼
Runbook 후보와 원인 가설 정리
    │
    ▼
읽기 전용 진단은 자동 실행
    │
    ▼
변경 작업은 사람 승인 요청
    │
    ▼
실행 결과와 검증 지표 기록

2.2.2 단계별 동작 원리

1. 컨텍스트 수집 — 알람 이름, 서비스명, 리전, 환경, 발생 시각을 기준으로 관련 데이터를 모은다.
2. Runbook 후보 추천 — 증상과 과거 장애 패턴을 기준으로 확인할 문서와 명령을 좁힌다.
3. 승인 기반 실행 — 조회 작업은 자동화하되, 재시작, 롤백, 스케일 조정 같은 변경 작업은 승인 뒤에 실행한다.

---

 

3. AWS 운영 환경에서 어떻게 설계할까?

3.1 CloudWatch와 Systems Manager를 중심으로 보기

상황: 결제 API의 p95 latency가 갑자기 증가했다.
도전 과제: 원인이 배포인지, DB 커넥션인지, 외부 API 지연인지 빠르게 좁혀야 한다.
접근 방법: Agent가 CloudWatch 지표, 로그, 최근 배포 이벤트를 먼저 조회하고 Runbook 후보를 제안한다.

3.1.1 핵심 흐름

CloudWatch Alarm
  -> 조사 워크플로우 시작
  -> CloudWatch Logs, Metrics, CloudTrail, 배포 이벤트 조회
  -> 관련 Systems Manager Automation runbook 후보 제안
  -> 읽기 전용 진단 runbook 실행
  -> 변경 runbook은 승인 후 실행

AWS는 2025년 6월 Amazon CloudWatch investigations의 정식 출시를 알리면서, AI agent가 이상 신호를 찾고 관련 신호를 표면화하며 원인 가설과 대응 단계를 제안할 수 있다고 설명했다. 또한 CloudWatch alarm action, Amazon Q chat, AWS 콘솔에서 조사를 시작하고, 관련 Systems Manager Automation runbook이나 문서를 제안할 수 있다고 안내한다.

이 흐름은 "AI가 곧바로 고친다"가 아니라 "AI가 조사와 Runbook 연결을 빠르게 도와준다"에 가깝다.

3.1.2 권한은 반드시 나눠야 한다

ReadOnlyInvestigationRole
  - CloudWatch metrics/logs read
  - CloudTrail lookup read
  - deployment metadata read

DiagnosticRunbookRole
  - read-only diagnostic automation
  - no production mutation

ApprovedChangeRunbookRole
  - restart, scale, rollback 같은 변경 작업
  - approval workflow 뒤에서만 사용

IAM 역할을 이렇게 나누면 Agent가 실수로 변경 작업을 호출하더라도 실행 경계가 생긴다. 편하다는 이유로 AdministratorAccess에 가까운 권한을 붙이면 장애 대응 자동화가 오히려 운영 리스크가 된다.

 

3.2 예상과 달랐던 문제들

3.2.1 첫 번째 복병: Runbook 품질

🔴 문제: 문서는 있지만 오래되어 실제 서비스명, 네임스페이스, 리전, 명령어가 맞지 않는다.
✅ 해결: Agent 도입 전에 자주 발생하는 알람 5개를 골라 Runbook 적용 조건, 중단 조건, 검증 지표를 먼저 정리한다.

3.2.2 두 번째 복병: 승인 없는 변경

🔴 문제: latency가 높다는 이유만으로 재시작이나 롤백을 자동 실행하면 장애가 더 커질 수 있다.
✅ 해결: 조회와 진단은 자동화하고, 프로덕션 변경은 승인 요청에 근거와 예상 영향을 포함한다.

💬 현장 목소리: *"장애 중에 필요한 것은 자동 복구보다, 지금 무엇을 봐야 하는지 빠르게 정리해주는 기능일 때가 많다."*

 

3.3 Azure는 언제 언급할 만한가?

3.3.1 특이 강점이 있을 때만 비교한다

이 글의 메인 관점은 AWS다. 다만 Azure 환경을 함께 운영하는 팀이라면 Azure Monitor alert의 action group으로 Automation runbook, Azure Functions, Logic Apps, ITSM 연동을 트리거할 수 있다는 점은 참고할 만하다.

또한 Azure AI Foundry의 tracing은 OpenTelemetry 기반 추적과 Application Insights 연계를 제공하므로, Agent의 tool call, latency, exception, 실행 메타데이터를 관측성 관점에서 보고 싶은 팀에는 강점이 있다.

구분	표면적 이해	실전 인사이트
AWS	CloudWatch 알람 뒤에 자동화 연결	조사, Runbook 추천, IAM 분리가 핵심
Azure	Azure Monitor로 알림과 자동화 연결	Action group과 Application Insights 추적이 강점
공통	AI가 장애를 고친다	AI는 조사와 판단 준비를 돕고 변경은 통제해야 한다

---

 

4. 실무자가 가져갈 기준

4.1 세 줄 요약

4.1.1 동료에게 이렇게 설명할 수 있다

• Agentic AI는 Runbook을 대체하지 않는다: 오래된 Runbook 위에 AI를 붙이면 더 빠르게 잘못된 절차를 실행할 수 있다.
• 처음에는 조회 자동화가 가장 현실적이다: 로그, 메트릭, 배포 이력, 이벤트를 모아주는 것만으로도 장애 초기 대응 시간이 줄어든다.
• 변경 작업은 승인과 감사 로그가 필요하다: 재시작, 롤백, 스케일 조정, 권한 변경은 근거와 예상 영향을 남긴 뒤 실행해야 한다.

 

4.2 도입 순서

4.2.1 난이도별 행동 가이드

1. 쉬움: 자주 울리는 알람 5개 정리 — 알람명, 서비스명, 영향 범위, 관련 로그와 대시보드 링크를 표준화한다.
2. 중간: 읽기 전용 진단 Runbook 만들기 — CloudWatch Logs 조회, 최근 배포 확인, Kubernetes event 확인처럼 변경 없는 작업부터 자동화한다.
3. 어려움: 승인 기반 변경 자동화 — 재시작, 롤백, 스케일 조정은 승인자, 실행 근거, 검증 지표, 실패 시 중단 조건을 포함해 설계한다.

 

4.3 마무리 질문

4.3.1 자동화보다 먼저 정해야 할 것

Agentic AI와 Runbook 자동화의 핵심은 장애 대응을 완전히 무인화하는 것이 아니다. 운영자가 장애 초기에 해야 하는 탐색, 정리, 후보 판단, 상황 공유를 줄이고, 위험한 변경 작업은 승인과 감사 로그 안에서 실행하도록 만드는 것이다.

좋은 시작점은 간단하다. 가장 자주 울리는 알람 하나를 고르고, 관련 Runbook을 최신화한 뒤, AI Agent에게 읽기 전용 조회와 요약만 맡겨보는 것이다. 그 작은 흐름이 안정적으로 동작하면 그다음에 진단 스크립트, 승인 기반 변경, 사후 회고 자동화로 넓혀갈 수 있다.

---

 

참고 자료

• AWS, Now in GA: Accelerate troubleshooting with Amazon CloudWatch investigations
• AWS, AWS Systems Manager Incident Manager
• AWS, Tutorial: Using Systems Manager Automation runbooks with Incident Manager
• AWS Cloud Operations Blog, Getting started with Amazon CloudWatch investigations
• Microsoft Learn, What are Azure Monitor alerts?
• Microsoft Learn, Set up tracing in Microsoft Foundry

 

---