AI 운영 self-healing, 무엇까지 자동으로 두어야 하나?
요약: AI 운영의 self-healing(자동 복구)에서 가장 중요한 진실은 셀프힐링엔 레벨이 있다는 것으로 — 재시작은 쉽고, 판단은 사람이다. 이 블로그는 사람 상주 없이 하루 수십 편을 굴리니 자동 복구가 없으면 못 버틴다. 하지만 "코드가 알아서 고친다"는 환상은 위험하다: 업계도 결정적 인프라 복구(재시작·롤백)는 성숙했지만 확률적 로직 자가수정은 여전히 위험한 프런티어라고 본다.
AI 운영의 self-healing(자동 복구)에서 가장 중요한 진실은 셀프힐링엔 레벨이 있다는 것으로 — 재시작은 쉽고, 판단은 사람이다. 이 블로그는 사람 상주 없이 하루 수십 편을 굴리니 자동 복구가 없으면 못 버틴다. 하지만 "코드가 알아서 고친다"는 환상은 위험하다: 업계도 결정적 인프라 복구(재시작·롤백)는 성숙했지만 확률적 로직 자가수정은 여전히 위험한 프런티어라고 본다. 공개 측정으로도 성숙한 자동복구는 MTTR을 평균 65% 단축(4시간→약 1.4시간)하지만, 대부분 팀은 아직 L0(수동)~L1(롤백) 단계다. 그래서 우리 원칙은 감지는 자동, 복구는 레벨대로, 못 고치면 사람 에스컬레이션이다. 요약: 자동은 되돌릴 수 있는 것까지, 판단은 사람.
한 줄 요약: 셀프힐링엔 레벨이 있다 — 재시작·롤백·격리 같은 되돌릴 수 있는 복구는 자동, 확률적 로직 자가수정과 배포 같은 판단은 사람에게 에스컬레이션한다.
쉽게 말하면: 셀프힐링은 자동차의 안전장치와 같다. 타이어 공기압 경고(감지)·ABS(자동 개입)까지는 차가 하지만, 차선을 바꿀지·목적지를 바꿀지(판단)는 운전자 몫이다. 자동화가 핸들까지 뺏으면 오히려 사고가 난다 — 되돌릴 수 있는 것만 자동이 안전선이다.
우리는 어떻게 감지하고 복구하나?#
헬스체크 감지 → 재시작·격리·자동복구 → 에스컬레이션의 흐름이다. 헬스 엔드포인트로 살아있는지 계속 확인하고, 죽으면 런북대로 서비스 재시작(승인된 스크립트, 감사 로그 포함), 발행 초안이 형식을 어기면 격리 폴더로 보내 원인을 남긴다. 어떤 위반은 사람 손 없이 자동 복구된다 — 내부 링크가 부족하면 관련 글 링크를 자동 주입해 다시 게이트에 넣는다. 강점은 평시 무인 안정이지만, 그걸 지탱하는 건 '무엇까지 자동으로 두느냐'의 선긋기다.
| 레벨 | 하는 일 | 우리 현황(측정·관측) |
|---|---|---|
| L0 수동 | 사람이 다 함 | 되돌릴 수 없는 행동만 |
| L1 롤백 | 나쁜 배포 되돌림 | 서비스 재시작 런북 |
| L2 진단 | 롤백+원인 로그 | 격리+원인 기록 |
| L3 복구 | 자동 교정 실행 | 내부링크 자동 주입 |
| L4 폐루프 | 정책게이트 폐루프 | 지향(사람 승인 유지) |
폭주하는 자동복구는 어떻게 막나?#
서킷 브레이커와 감사 로그다. 같은 문제로 자동복구가 반복 발동하면 멈추고 사람에게 알린다 — 반복은 더 깊은 결함의 신호라서, 무한 재시도로 상태를 악화시키지 않는다(우리 발행 리포트에도 near-dup·breaker 신호가 있다). 그리고 모든 복구 행동을 로그로 남긴다 — 인프라가 스스로 나았으면 '무엇을·왜' 고쳤는지 알아야 다음에 판단한다. 폭주 방지의 핵심은 빠른 복구가 아니라 '언제 멈추고 사람을 부르나'를 정하는 것이다.
셀프힐링이 못 고치는 건?#
판단이 필요한 문제, 특히 배포 갭이다. 실제로 개발 브랜치의 수정이 배포 브랜치에 안 실려 프로덕션이 옛 상태로 남은 적이 있는데, 이건 재시작·격리로 안 낫는다 — 머지·배포라는 사람 판단이 필요했고, 자동화가 임의로 배포하지 않고 승인 흐름으로 에스컬레이션했다. 자가수정 로직은 그럴듯하게 틀리기 쉬워, 핵심 판단엔 사람이 핸들을 잡는다. 그리고 셀프힐링은 믿는 게 아니라 일부러 실패를 주입해(카오스) 정기 검증한다 — 안 터뜨려보면 진짜 낫는지 모른다.
그래서 우리 self-healing 운영 원칙은?#
핵심은 되돌릴 수 있는 것만 자동, 판단은 사람이다.
- 감지: 헬스체크·게이트·스모크로 이상을 자동 포착(사일로 방지 — 신호가 흩어지면 오판한다).
- 복구: 재시작·격리·자동교정은 자동, 되돌릴 수 없는 배포·삭제는 사람 승인. 모든 복구는 로그.
- 한계: 반복 발동은 서킷 브레이커로 멈추고 사람 호출, 판단 문제는 에스컬레이션. 카오스로 정기 검증한다.
함께 읽기: 오픈 음성 클로닝, 우리는 이렇게 운영한다 — 파이프라인 회고, 에이전트 브라우저 제어 — 우리는 이렇게 운영한다(회고)
함께 읽기: AI 운영 self-healing 자동화, 직접 써본 실측·한계, 이 블로그의 자동 발행 파이프라인, 직접 써본 실측·한계
참고 링크
- Kubernetes(선언적 상태 복구)
- Google SRE Book(신뢰성 운영)
- Google SRE Workbook(실무 구현)
- Chaos Monkey(카오스 엔지니어링)
- OpenTelemetry(관측·텔레메트리)
참고: MTTR 65%·L0/L1 다수·사일로 28% 같은 수치는 2026년 공개 벤치마크(AIOps 리포트·Forrester 등)에서 인용한 것으로 환경(그린필드 K8s vs 레거시)에 따라 편차가 크다(영구 수치 아님). 자가수정 '로직'은 확률적이라 위험하니 되돌릴 수 없는 판단엔 사람을 둔다. 자동복구 관행은 빠르게 바뀌니 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.