요즘 운영팀의 공통 고민은 단순합니다. 장애는 빨리 복구해야 하는데, 자동화가 과하면 사고를 키우고 수동 대응은 너무 느립니다. 그래서 2026년에는 “아예 자동"도 “끝까지 수동"도 아닌, **승인형 Auto-Remediation(Approval-Driven Remediation)**이 빠르게 표준으로 자리잡고 있습니다.

핵심은 에이전트가 실행권을 독점하는 구조가 아니라, 탐지·진단·복구안 제안은 자동화하고 최종 실행은 위험도 기반으로 승인 경계에 둔다는 점입니다. 이 방식이 현실적인 이유는 MTTR을 줄이면서도 오복구(잘못된 복구) 비용을 통제할 수 있기 때문입니다.

이 글에서 얻는 것

  • 자동 복구를 도입할 때 “어디까지 자동화할지"를 위험도·영향도 기준으로 결정할 수 있습니다.
  • 승인형 워크플로를 설계할 때 필요한 단계(탐지→제안→승인→실행→검증)를 운영 지표와 함께 설계할 수 있습니다.
  • 도입 후 흔히 생기는 역효과(알림 피로, 승인 병목, 잘못된 롤백)를 줄이는 우선순위를 잡을 수 있습니다.

핵심 개념/이슈

1) 완전 자동 복구가 실패하는 이유

많은 팀이 초기에 “장애면 자동 재시작"부터 붙입니다. 문제는 장애의 원인이 리소스 포화인지, 배포 결함인지, 외부 의존성 장애인지 구분되지 않은 상태에서 같은 액션을 반복한다는 점입니다.

  • 원인 미분류 상태의 자동 재시작은 장애를 숨길 수 있음
  • 잘못된 롤백은 데이터 정합성 이슈를 키울 수 있음
  • 동일 액션 반복으로 에러 버짓을 더 빠르게 소모

즉 자동화의 핵심은 실행 속도가 아니라 실행 조건의 정확도입니다. 이건 SLO/에러 버짓 운영과 같은 관리 프레임 없이는 유지되지 않습니다.

2) 승인형 모델은 “사람을 느리게"가 아니라 “위험을 분리"한다

승인이 들어가면 느려질 것 같지만, 실제로는 위험도에 따라 경로를 나누기 때문에 전체 복구 시간은 오히려 줄어듭니다.

  • Low Risk: 자동 실행 (예: 임시 캐시 플러시, 워커 1개 재기동)
  • Medium Risk: 단일 승인 후 실행 (예: 특정 배포 롤백)
  • High Risk: 2인 승인 + 단계 실행 (예: 데이터 복구, 스키마 전환)

이 구조는 Golden Path와 같은 플랫폼 표준화와 결합될 때 효과가 큽니다.

3) 자동화의 품질 지표는 성공률이 아니라 “안전한 성공률”

복구 자동화에서 단순 성공률은 착시를 줍니다. 예를 들어 복구 성공처럼 보였지만 30분 뒤 재발하면 실패에 가깝습니다.

그래서 아래 지표를 함께 봐야 합니다.

  • Remediation Success Rate: 실행 후 30분 재발 없이 안정화 비율
  • False Remediation Rate: 잘못된 액션으로 상태를 악화시킨 비율
  • Approval Lead Time: 제안부터 승인까지 걸린 시간
  • Rollback Necessity Rate: 복구 액션 후 역으로 롤백한 비율

관측 체계가 약하면 자동화는 통제 불가능한 블랙박스가 됩니다. 기본은 Continuous Profiling과 알람 설계를 같이 맞추는 것입니다.

4) 실제 트렌드는 “AI가 복구"가 아니라 “AI가 제안, 시스템이 통제”

현장에서 강한 패턴은 “AI가 판단을 대신한다"가 아니라, AI가 가능한 복구 시나리오를 제안하고 정책 엔진이 실행 가능 범위를 제한하는 방식입니다. 이 흐름은 에이전트 평가·시뮬레이션과도 맞물립니다. 즉, 모델 성능보다 “정책+평가+승인” 3축이 운영 성패를 가릅니다.

실무 적용

1) 30일 파일럿 도입 순서

  • 1주차: 장애 유형 상위 10개 분류, 자동화 가능한 액션/금지 액션 정의
  • 2주차: 승인형 워크플로(슬랙/디스코드/내부 콘솔) 연결, 실행 전 체크리스트 삽입
  • 3주차: Low Risk 액션만 자동 실행, Medium은 승인 후 실행
  • 4주차: 재발률/오복구율 리뷰 후 정책 임계치 조정

처음부터 모든 장애를 자동화하면 실패 확률이 높습니다. 반복 빈도가 높고 영향 범위가 작은 액션부터 시작하는 게 맞습니다.

2) 의사결정 기준(숫자·조건·우선순위)

우선순위는 안전성 > 복구 속도 > 비용 절감으로 두는 것이 일반적으로 맞습니다.

  • 자동 실행 허용 조건
    • 예상 영향 대상이 전체 트래픽의 5% 미만
    • 최근 30일 동일 액션 성공률 98% 이상
    • 데이터 변경 없는 인프라 액션
  • 단일 승인 조건
    • 영향 대상 5~30%
    • 롤백 5분 내 가능한 액션
  • 이중 승인 조건
    • 데이터 변경 포함
    • 결제/권한/정산 도메인 영향 가능성 있음

즉, “급하니까 자동"이 아니라 영향 범위와 가역성으로 결정해야 합니다.

3) 운영 런북 최소 구성

  • 장애 시그널 정의(지표/로그/트레이스 기준)
  • 자동 제안 가능한 액션 목록(우선순위 포함)
  • 액션별 선행 조건(예: 에러율 10분 평균, CPU/메모리 포화 여부)
  • 승인자 역할/대체 승인자
  • 사후 검증 기준(재발 없음 시간, 성능 회복선)

운영에서 가장 중요한 건 “누가 어떤 조건에서 버튼을 누를 수 있는가"를 모호하지 않게 문서화하는 것입니다.

4) 실패를 줄이는 가드레일

  • 동일 액션 반복 제한(예: 30분 내 2회 초과 금지)
  • 자동 실행 전 드라이런 시뮬레이션
  • 실행 후 10분 관찰 자동 강제
  • 실패 시 자동 확산 금지(같은 액션 다른 서비스로 전파 금지)

이 가드레일이 없으면 자동화는 장애 증폭기가 됩니다.

트레이드오프/주의점

  1. 승인 병목 리스크
    승인자를 1명에게만 묶으면 야간/휴일에 MTTR이 오히려 늘어납니다. 역할 기반 대체 승인 경로가 필요합니다.

  2. 알림 피로
    모든 제안을 사람에게 던지면 결국 무시됩니다. Low Risk 자동 경로를 반드시 분리해야 합니다.

  3. 정책 과적합
    특정 장애에 맞춰 임계치를 과도하게 튜닝하면 새로운 유형에서 오작동합니다. 월 단위 리셋 리뷰가 필요합니다.

  4. 성과 측정 왜곡
    “자동 실행 건수"를 KPI로 두면 위험한 자동화가 늘어납니다. 재발률/오복구율 중심으로 KPI를 잡아야 합니다.

체크리스트 또는 연습

팀 체크리스트

  • 장애 액션을 Low/Medium/High Risk로 분류했다.
  • 승인 없이 실행 가능한 액션의 조건을 숫자로 정의했다.
  • 승인자 부재 시간대 대체 경로를 마련했다.
  • 자동 복구 성공률과 오복구율을 동시에 측정한다.
  • 실행 후 재발 여부를 30분 이상 추적한다.

연습 과제

  1. 최근 1개월 장애 20건을 기준으로, “자동화 가능/승인 필요/금지"로 다시 분류해보세요.
  2. 가장 자주 발생한 장애 1개를 골라 승인형 워크플로 다이어그램을 작성해보세요(탐지→제안→승인→실행→검증).
  3. “자동 재시작 3회 후에도 실패” 상황에서 다음 액션을 어떻게 제한할지 정책 문구를 작성해보세요.

관련 글