
AI 시대의 운영·유지보수 · Ep.06
시스템은 스스로 복구했다.
무엇을 고쳤는지는 아무도 몰랐다.
장애 대응: 자동복구 시대, 사람은 어디에 있는가 · HFC Consulting
새벽 3시, 배치가 실패했다. AI 기반 자동복구 스크립트가 즉시 재시도를 실행했고, 두 번째 시도에서 성공했다. 아침에 출근한 담당자는 로그에서 실패와 성공 기록만 보았다. 무엇이 실패의 원인이었는지, 재시도 사이에 무엇이 바뀌었는지는 기록에 없었다. 시스템은 스스로 고쳤다고 말했을 뿐, 무엇을 고쳤는지는 말하지 않았다.
이번 화는 자동화된 장애 대응 안에서 사람의 자리를 다시 그리는 이야기다.
오픈 전 가정 — 자동복구가 있으니 장애는 줄어든다
자동 재시도, 자동 스케일링, AI 기반 이상 탐지가 도입되면 체감 장애 건수는 확실히 줄어든다. 이 가정 위에서 조직은 장애 대응 인력을 줄이거나, 야간 대기 체계를 느슨하게 만드는 선택을 하기 쉽다.
오픈 후 현실 — 보이지 않는 장애가 늘어난다
자동복구는 증상을 없애지만 원인을 남긴다. 재시도로 넘어간 실패는 로그에 묻히고, 같은 원인이 누적되다 자동복구의 한계를 넘는 순간 큰 장애로 터진다. 그리고 그 순간은 대개 사람이 가장 적게 있는 새벽이다. AI가 만든 긴급 패치가 그 자리에서 배포될 때, 검증할 사람이 없다는 문제도 함께 온다. AI Agent의 자율 행동 권한을 3분류로 나눠 승인 경계를 두어야 한다는 원칙은 3기 6화에서 다뤘다. 운영 단계의 자동복구·자동패치는 그 권한 체계가 실제로 시험되는 현장이다.
DevOps 파이프라인의 재설계에서 자동화가 표준이 되는 지점과 사람이 남아야 하는 지점을 구분해야 한다는 지적은 4기 8화에서 다뤘다. 장애 대응에서 그 경계는 더 뚜렷해야 한다. 자동화가 실패를 숨기는 도구가 아니라 드러내는 도구여야 하기 때문이다.
역설적으로, 자동복구가 잘 작동할수록 이 위험은 커진다. 사람이 개입할 일이 줄어드니 담당자의 시스템 이해도도 함께 낮아진다. 몇 달간 조용했던 시스템에서 자동복구의 한계를 넘는 장애가 터지면, 대응할 사람은 있지만 그 시스템을 깊이 아는 사람은 없는 상황이 벌어진다. 자동화가 지식의 공백을 만들지 않도록, 자동 대응 이력을 정기적으로 사람이 검토하는 습관 자체가 지식 유지의 수단이 된다.
장애 대응 체계와 검증 절차
장애 대응 체계도 (3단계)
① 자동 대응 — 사전 정의된 범위 내 재시도·스케일링. 모든 발동 이력을 로그화하고 익일 리뷰 대상으로 표시한다.
② 사람 승인 대응 — 정의된 범위를 벗어난 조치(재시작 범위 확대, 긴급 패치 배포)는 사람의 승인을 거친다. 새벽에도 승인자는 지정되어 있어야 한다.
③ 사후 검증 — 자동·수동 조치와 무관하게, 발생한 모든 장애는 익영업일 원인 분석 리뷰를 거친다.
긴급 패치 사후검증 체크리스트 4
① 패치 배포 전 승인자가 지정되어 있었는가.
② 패치의 생성·검토 로그(프롬프트·코드·리뷰어)가 남아 있는가.
③ 배포 후 24시간 내 정식 검토를 거쳤는가.
④ 검토 결과가 다음 회 변경관리 절차에 반영되었는가.
예상 반론과 대응
반론 — "새벽마다 승인자를 대기시키면 자동화의 이점이 사라진다. 비용도 늘어난다."
대응 — 모든 조치에 실시간 승인이 필요한 것이 아니다. 사전 정의된 범위 안의 자동 대응은 그대로 두고, 그 범위를 벗어나는 예외적 상황에만 사람을 부른다. 대기는 상시가 아니라 온콜(on-call) 형태로 충분하다. 비용은 늘지만, 그 비용은 큰 장애 하나를 며칠씩 붙잡는 비용보다 항상 작다.
사후 검증 리뷰를 형식적으로 만들지 않는 것도 중요하다. "장애 없이 자동 복구됨"이라는 한 줄로 끝나는 리뷰는 리뷰가 아니라 기록이다. 무엇이 왜 실패했는지, 다음에도 같은 방식으로 복구될지, 복구되지 않는다면 어떤 조건에서 그런지를 묻는 것이 리뷰다. 이 질문에 답할 수 없다면, 그 장애는 아직 이해되지 않은 채로 다음 발생을 기다리고 있는 것이다. 리뷰에 걸리는 시간은 길 필요가 없다. 세 가지 질문에 답하는 15분이면, 다음번 같은 장애가 새벽 대신 낮에, 혹은 아예 발생하지 않는 차이를 만든다.
체크포인트 — 자동 대응 범위의 사전 정의 / 범위 초과 시 승인자 지정 / 온콜 체계 존재 / 긴급 패치 사후검증 의무 / 익일 원인 분석 리뷰
이 체계를 만드는 부담을 걱정할 필요는 크지 않다. 3단계 체계의 상당 부분은 이미 존재하는 모니터링·알림 도구 위에 절차 한 겹을 얹는 일이다. 새로운 시스템을 구축하는 것이 아니라, 자동 대응의 범위를 문서로 명확히 하고 그 범위를 벗어났을 때 누구를 호출할지 정하는 것이 핵심이다. 기술의 문제가 아니라 합의의 문제인 경우가 대부분이다. 도구를 새로 사는 것보다, 이미 있는 도구의 경보를 누가 받고 어떤 조건에서 다음 단계로 넘길지를 정하는 것이 먼저다. 그 합의를 문서 한 장으로 남기는 순간, 팀은 이미 3단계 체계를 절반쯤 갖춘 셈이다. 나머지 절반은 그 합의를 실제 장애 상황에서 몇 번 시험해 보며 다듬는 일이다.
자동복구는 장애를 줄이는 도구이지 원인을 없애는 도구가 아니다. 그 차이를 기억하는 조직만이, 재시도가 조용히 감춘 근본 원인을 새벽이 아니라 낮에 발견한다.
📎 더 읽을거리
인공지능 발전과 신뢰 기반 조성 등에 관한 기본법 (국가법령정보센터) — AI 자동화 조치의 투명성·관리 의무를 규정한 기본법 원문
HFC의 관점
귀사의 자동복구, 무엇을 고쳤는지 다음 날 확인할 수 있습니까. HFC컨설팅은 자동 대응과 사람의 승인 경계를 설계하고, 긴급 패치 사후검증 체계를 구축합니다.
1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석
본 연재의 문구·양식 예시는 법률 자문을 대체하지 않으며, 실제 발주·계약 시 법무 검토를 권장합니다.
'IT 인사이트 > AI 시대의 운영·유지보수' 카테고리의 다른 글
| SM 계약과 성과: 다음 재계약을 준비하는 법 (08/08) (0) | 2026.07.30 |
|---|---|
| 변경관리: 운영 중의 변경이 개발 때보다 무겁다 (07/08) (0) | 2026.07.30 |
| AI 운영비용: 보이지 않던 비용이 청구서로 온다 (05/08) (0) | 2026.07.30 |
| 하자담보책임의 경계: AI가 만든 버그는 누구 책임인가 (04/08) (0) | 2026.07.30 |
| 이관: 지식은 문서가 아니라 사람 안에 있다 (03/08) (0) | 2026.07.30 |