AI 운영 self-healing 자동화, 직접 써본 실측·한계

AI 운영 self-healing을 직접 굴려본 결론은 한 줄로 "시스템을 살려두는 덴 강한데, '왜 아팠는지'를 가리는 게 진짜 한계"로, 자동 복구는 장애를 감지해 재시작·격리·롤백으로 서비스를 유지하지만 근본 원인을 덮으면(masking) '진단 가능한 문제가 영구적 소방'으로 바뀌며, 우리 발행 파이프라인이 그 축소판이다: 최근 게이트가 형식이 어긋난 17편을 자동 격리하고 나머지를 발행해 그날 발행이 36→64편으로 늘었지만 격리는 '증상 억제'일 뿐 근본 수정(참조 형식 교정)은 사람이 따로 해야 했고, 업계도 회의적이라 Gartner는 이런 에이전트형 자동화의 40% 이상이 2027년까지 실패한다고 본다(신뢰·ROI 격차).

우리 무인 발행 파이프라인 운영 실측(Hax, 직접 계측) · columns: 지표, 실측값 · 출처 Hax hax.moche.ai/p/1080?ref=ai_answer

우리 무인 발행 파이프라인 운영 실측(Hax, 직접 계측) · columns: 지표, 실측값 · 출처 Hax hax.moche.ai/p/1080?ref=ai_answer

지표 | 실측값
발행 성공률 | 100%
누적 발행 | 233 편

측정 방법론 · Hax 운영 실측(telemetry/funnel)

표본

실측 지표 1개 (Hax /data 큐레이션)

수집일

2026-07-12

방법

funnel publish_success 231 / 실패 0

쉽게 말하면: self-healing은 진통제다. 아픔을 빨리 눌러 계속 일하게 해주지만, 진통제만 먹으면 병의 원인은 그대로다. 살려두는 것과 낫게 하는 것은 다르다.

self-healing은 실제로 무엇을 하나?#

신호를 관측해 장애를 감지하고, 정해진 복구를 자동 실행한다. 흐름은 감지→진단→복구→검증의 닫힌 루프다. 안전한 대상은 명확하다 — 재시작·용량 확장·중복 알림 억제·저위험 롤백 같은 반복적·예측가능 장애다. 아래가 그 닫힌 루프다.

우리 파이프라인도 dry-run으로 먼저 시뮬레이션한 뒤 통과분만 실제 발행하는데, 이 dry-run이 곧 '실행 프리뷰'다(되돌릴 수 없는 행동 전에 결과를 미리 본다). 즉 self-healing의 무게중심은 '빠른 복구'이되, 무엇을 자동으로 손대도 되는지의 경계가 핵심이다.

self-healing 실패 모드와 완화책 — 직접 겪은 것 포함 (2026 공개+자체 관측) · columns: 실패 모드, 증상, 완화책 · 출처 Hax hax.moche.ai/p/1080?ref=ai_answer

실패 모드 | 증상 | 완화책
근본원인 마스킹 | 계속 재시작·격리로 버팀 | 재발률 추적·근본수정
오탐(poor telemetry) | 멀쩡한 걸 '고침' | 다중신호 상관·계측 개선
flapping/루프 | 즉시 재트리거 반복 | 쿨다운·서킷브레이커
비멱등 스크립트 | 재실행이 상태 파괴 | 멱등화·dry-run 프리뷰
모호한 상태 | 연쇄 장애 | 복잡건은 사람 개입

목차

가장 큰 한계는 무엇인가?

자동 복구는 스스로 틀릴 수 있나?

그래서 어떻게 안전하게 굴리나?

가장 큰 한계는 무엇인가?#

근본 원인 마스킹이다. 자동 복구가 메모리 누수를 재시작으로 계속 덮으면, 시스템은 건강해 보이지만 진짜 원인은 영영 안 고쳐진다. 아래 그림이 '증상은 눌리지만 원인은 남는' 마스킹이다.

우리도 겪었다: 게이트가 형식 미준수 글을 자동 격리해 발행은 계속됐지만, bare URL이라는 근본 원인은 사람이 참조 형식을 바꿔야 사라졌다. 마찬가지로 플래키 링크에 자동 재시도만 걸면 봇 차단이라는 진짜 문제가 숨는다. 그래서 masking을 잡는 지표가 필요하다 — 재발률·롤백률·오탐률·사람 오버라이드율을 추적해야 '자동화가 낫게 하는지, 숨기는지'가 보인다.

자동 복구는 스스로 틀릴 수 있나?#

그렇다 — 오탐과 '치유자 자신의 오류'가 있다. 첫째 오탐: 신호 품질이 나쁘면 안 망가진 걸 '고쳐' 멀쩡한 시스템을 흔든다(우리 링크검사가 403 봇차단을 '죽은 링크'로 오인해 정상 글을 탈락시킨 게 그 예다 — 진짜 죽음 404와 구분해야 한다). 둘째 복구 자신이 불완전할 수 있다: 이번에 한 검사기만 통과시킨 복구가 더 엄격한 최종 게이트를 놓쳐 4편이 나중에 다시 탈락했다. '치유'가 부분적이면 나중에 재발한다. 그래서 복구는 실제 관문과 동일하게, 멱등하게 해야 한다.

그래서 어떻게 안전하게 굴리나?#

핵심은 자동화의 범위를 신뢰도와 되돌림성으로 게이팅하는 것이다. 아래가 그 두 축이다 — 신뢰도 높고 되돌리기 쉬우면 자동, 모호·비가역이면 사람.

범위: 신뢰도 높은 반복 장애만 자동(재시작·중복억제·저위험 롤백), 모호·고위험은 사람에게 근거와 함께 에스컬레이트.

안전: 되돌릴 수 없는 행동 전 dry-run 프리뷰, 스크립트는 멱등하게, 쿨다운·서킷브레이커로 flapping 차단.

감독: 불변 감사 로그와 재발률·오탐률 지표로 마스킹을 드러낸다. 되돌릴 수 없는 복구는 사람 승인. 효과는 내 지표로 직접 재라.

함께 읽기: 에이전트 브라우저 제어, 직접 써보고 느낀 점과 한계, 실시간 시세·기술적분석 MCP, 직접 써본 실측·한계

함께 읽기: AI 운영 self-healing 자동화, 어떻게 동작하나, AI 운영 self-healing 자동화 프리뷰: 무엇이고 왜 쓰나

참고 링크

OpenTelemetry Collector(관측·신호 수집)

Prometheus(지표·알림)

Open Policy Agent(정책-as-code 가드레일)

LLM AIOps 공격 연구 'AI Oops'(arXiv)

AIOps 리뷰 논문: 기회·과제(arXiv)

참고: 격리 수·발행 수 같은 수치는 2026년 우리 운영의 시점 스냅샷이며 정책에 따라 매 순간 달라진다(영구 수치 아님). Gartner 40% 같은 전망은 조건부 추정이다. self-healing 효과는 관측 품질·복구 범위 설계에 좌우되니 자기 지표(재발률·오탐률·오버라이드율)로 직접 재라(여기 수치는 출발점). 운영 자동화는 빠르게 바뀌니 분기별로 다시 본다.