AI 운영 self-healing 자동화: 관측을 넘어 스스로 고치는 닫힌 루프

AI 운영 self-healing(자가복구) 자동화는 관측에서 멈추지 않고 스스로 고치는 닫힌 루프다. 이상을 감지하면 검증된 런북(runbook, 사고 대응 절차서)으로 재시작·스케일·롤백을 실행하고, SLO(서비스 수준 목표) 대비 복구를 확인한 뒤 루프를 닫는다. 업계 보고로는 MTTR(평균 복구 시간)이 40~60%, 최고 87%까지 줄고 알림은 최대 95% 감소한다. 이 블로그 운영도 watchdog(감시 프로세스)가 헬스체크 실패를 잡아 자동 복구하고, 큰 행동만 사람이 승인한다.

한 줄 요약: self-healing은 스스로 반창고를 붙이는 시스템이다. 사람을 깨우기 전에 흔한 고장은 알아서 복구하고, 심각할 때만 호출한다.

관측만으로는 왜 부족한가?#

데이터가 많아도 감지와 조치 사이의 간격이 넓으면 복구가 늦기 때문이다. 2024~2025년 텔레메트리(운영 계측 데이터)가 폭증하며 알림 피로가 생기고, "완전한 가시성이 더 나은 통제로 이어지지 않는" 역설이 드러났다. 정적 스크립트와 티켓 중심 워크플로는 복잡도를 못 따라간다. 그래서 흐름이 관측-경보에서 관측-결정-조치-검증으로 옮겨갔다.

번레이트로 긴급도를 어떻게 나누나?#

오류 예산의 소모 속도로 나눈다. 여기서 번레이트(burn rate)란 SLO가 허용하는 실패 여유(오류 예산)를 얼마나 빨리 써버리는지의 비율이다. 의료 비유가 적절하다 — 천천히 타는 경미한 저하는 아침에 약(이메일 알림)으로 처리하고, 빠르게 타는 장애는 즉시 제세동기(페이저·자동 재시작)로 대응한다. 정적 임계값("CPU 90%")이 아니라 SLO 위반 속도로 긴급도를 정하면 한밤중 헛알림이 준다. 실제로 한 사례는 알림을 하루 800건+에서 20~50건으로 95% 줄였다.

자율은 곧 방치인가?#

아니다. human-on-the-loop(사람이 루프 위에서 감독)다. 엔지니어는 직접 손을 대는 대신 정책·허용 행동·비즈니스 의도를 정의하고 결과를 평가한다. 핵심 위험은 자동화 드리프트(설정이 슬금슬금 어긋남)·오탐·과신이라, 모든 복구 스크립트를 코드처럼 버전·리뷰·CI 테스트한다(runbooks-as-code). 우리 운영도 같다 — watchdog는 흔한 고장을 자동 복구하되, 되돌리기 어려운 행동(배포·삭제)은 사람 승인을 거친다.

직접 시작하려면?#

작게, 저위험부터.

• OpenTelemetry로 관측을 깔고, 가장 흔한 런북 몇 개를 코드로 옮긴다.
• 신뢰 임계값과 가드레일을 둬 자동 조치 범위를 좁게 시작한다.
• MTTR과 알림 노이즈 변화를 측정한다 — 보통 파일럿 30일 안에 개선이 보인다.

참고 링크#

• OpenTelemetry(관측 표준)
• Google SRE Book(SLO·오류예산)
• Prometheus(모니터링·알림)
• Kubernetes(자가복구 오케스트레이션)
• Model Context Protocol(에이전트 도구 표준)

참고: MTTR·알림 감소 수치는 2025~2026년 벤더·사례 공개 보고로 범위·범주에 따라 크게 다르다(40~87%). 정확한 효과는 내 시스템에서 파일럿으로 직접 측정하라. 자동화 범위는 저위험부터 넓히고 가드레일을 유지하라. 분기별 갱신.