장애 감지부터 보고서까지, 자동화할 수 있는 건 어디까지일까?

장애가 나면 매번 같은 걸 반복합니다

장애가 발생하면 하는 일이 매번 비슷하거든요. 대시보드에서 이상을 발견하고, 슬랙에 올리고, 로그를 뒤져서 원인을 추적하고, 영향받는 서비스를 파악하고, 조치하고, 보고서를 씁니다. 장애마다 원인은 다르지만, 이 흐름 자체는 거의 같아요.

그런데 이 흐름을 돌아보니까, 각 단계에서 하는 일이 시스템에 이미 있는 것들이더라고요. 영향도 분석은 BFS로 만들어뒀고, 담당자 파악은 지식그래프에 관계가 있고, 복구 플랜 초안은 LLM이 만들어주고 있었거든요. 개별 조각은 있는데, 루프로 이어져 있지 않았던 거예요.

9단계 루프

장애 대응 전체 흐름을 정리하면 9단계입니다.

① 감지 — 메트릭/로그 이상 감지
② 분석 — 지식그래프에서 영향도 분석
③ 티켓 — Incident 자동 발행 + 담당자 배정
④ 런북 — 과거 이력 기반 조치 절차 추천
⑤ 조치 — 자동/반자동/수동 실행
⑥ 기록 — 조치 결과 감사 로그 + 담당자 코멘트
⑦ 보고서 — AI가 타임라인+영향+조치 종합 초안 생성
⑧ 검토 — 담당자가 확인·수정 → 확정
⑨ 지식 축적 — 확정 보고서를 지식그래프에 반영

9번에서 쌓인 지식이 다음 장애의 2번과 3번에서 근거가 됩니다. 보고서가 임포트되면 지식그래프가 풍부해지고, 다음에 비슷한 장애가 나면 영향도 분석이 더 정확해지고, 런북 추천도 "지난번에 이걸로 해결했다"는 이력이 붙거든요. 일방향이 아니라 루프가 되는 구조예요.

이미 만든 것, 새로 만들 것

9단계를 설계하면서 가장 놀랐던 건, 절반 이상이 이미 만들어져 있었다는 거예요. 개별 기능으로 흩어져 있었을 뿐이었습니다.

✅가 5개, ⚠️가 3개, ❌가 2개. 새로 만들어야 하는 건 런북(④)과 자동조치(⑤) 두 단계뿐이었습니다. 나머지는 기존 기능을 연결하거나 확장하면 되는 수준이에요.

1. 감지 — 알림 시스템은 이미 있었습니다

이벤트 알림 시스템은 이미 구현돼 있거든요. 문서 임포트 완료, 미매핑 타입 발견, 임포트 실패 같은 이벤트가 발생하면 alert_history 테이블에 알림이 쌓이고, 프론트엔드에 severity별로 표시됩니다. AI Server와 Spring Boot가 같은 테이블에 INSERT하는 구조라 소스가 달라도 한 곳에서 관리돼요.

여기에 모니터링 이벤트를 추가하면 됩니다. CPU 90% 초과, 응답 지연 3초 초과 같은 메트릭 기반 알림을 같은 alert_history에 넣는 거예요. 알림 표시, 읽음 처리, severity 분류는 다 있으니까 연동만 하면 되는 수준이에요.

한 가지 중요한 게 있는데, 중복 알림 억제가 필요합니다. 서버 하나가 불안정하면 알림이 수십 건 발생할 수 있거든요. 같은 장애에서 나온 알림을 1건으로 묶는 dedup이 필요하고, 더 나아가면 "DB 다운" + "WAS 연결 실패" + "포털 500 에러"를 하나의 근본 원인으로 묶는 상관 분석까지 갈 수 있어요.

4. 런북 — 새로 만들어야 하는 핵심

9단계 중 진짜 새로운 건 런북 시스템입니다. 장애 유형별로 "이런 증상이 감지되면 이 절차를 따라라"는 조치 매뉴얼을 사전에 등록해두고, 장애 발생 시 자동으로 추천하는 구조예요.

장애 유형 정의:

  WAS 프로세스 다운
    감지: 프로세스 모니터링에서 PID 없음
    런북: WAS 재기동 → health check

  DB 연결 실패
    감지: 로그에 "Connection refused"
    런북: listener restart → connection pool reset

  디스크 사용률 초과
    감지: disk usage > 90%
    런북: 로그 정리 (7일 이상 삭제)

장애가 감지되면 감지 조건과 매칭해서 해당 런북을 추천합니다. "이 런북을 실행하시겠습니까?"라는 승인 UI가 뜨고, 담당자가 확인하면 실행되는 거예요.

초기에는 단순 매칭으로 시작합니다. 장애 유형이 10~20개 수준이면 규칙 기반으로 충분하거든요. 파일럿에서 "추천이 안 맞는 경우"가 나오면 그때 AI 에이전트로 고도화할 수 있어요. 과거 이력 + 영향도 기반으로 복합 판단하는 거예요.

5. 조치 — 자동이 아니라 반자동부터

자동조치라고 하면 "AI가 알아서 서버를 재기동한다"를 떠올리기 쉬운데, 현실적으로 첫 단계는 반자동이에요. 장애 등급에 따라 실행 방식이 달라지거든요.

반자동의 핵심은 드라이런입니다. 실제 실행 전에 "이렇게 하겠습니다"를 미리 보여주고, 담당자가 확인한 뒤에 실행하는 거예요. 자동조치가 실패하면 롤백 절차가 자동으로 실행되고, 전부 감사 로그에 기록됩니다.

채팅에서 "물류서버-A 재기동해줘"라고 자연어로 명령하는 건 고도화 단계에서 할 수 있어요. 기존 RAG 채팅에 런북 실행 기능을 연결하면 되는 거라, 기반은 이미 있습니다.

7. 보고서 — 루프의 가장 중요한 출력

장애 보고서가 이 루프에서 가장 중요한 산출물이에요. 보고서 양식은 이렇게 설계했습니다.

1. 개요: 장애 요약 (한 줄)
2. 타임라인: 감지 → 티켓 발행 → 조치 시작 → 조치 완료 → 정상 확인
3. 영향 범위: 영향받은 시스템/서비스 + 사용자 영향
4. 조치 내역: 실행한 런북 + 결과 + 담당자 코멘트
5. 근본 원인: AI 분석 기반 원인 추정
6. 재발 방지: 모니터링 임계값 조정, 용량 증설 등
7. SLA: 감지~복구 소요시간 (MTTR)

이 보고서의 1~4번은 자동으로 채워집니다. 감지 시각은 알림에서, 타임라인은 감사 로그에서, 영향 범위는 영향도 분석에서, 조치 내역은 런북 실행 기록에서 가져오면 되거든요. 5~6번은 LLM이 전체 맥락을 종합해서 초안을 생성합니다. 이미 Object View에서 복구 플랜 생성을 LLM으로 하고 있으니까, 같은 구조를 보고서에 적용하는 거예요.

담당자는 AI 초안을 검토하고 수정해서 확정합니다. 확정된 보고서는 임베딩돼서 다음 장애 시 RAG 검색 대상이 되고, 기존 임포트 파이프라인으로 지식그래프에도 반영됩니다. 이게 ⑨번 단계이고, 여기서 쌓인 지식이 다음 루프의 ②(영향도 분석)와 ④(런북 추천)를 더 정확하게 만들어줍니다.

한 번에 다 만들지 않습니다

이 9단계를 한 번에 다 구현하려면 몇 달이 걸리거든요. 그래서 Phase별로 나눠서 순차적으로 만들 계획입니다.

Phase 2에서는 모니터링 연동과 자동 티켓 발행까지만 만듭니다. 장애가 감지되면 영향도 분석이 자동으로 돌아가고, Incident 티켓이 생성되고, 담당자에게 알림이 가는 거예요. 기존에 만든 것들을 연결하는 작업이라 가장 빨리 체감할 수 있는 구간입니다.

Phase 3에서 런북과 자동조치를 만들고, Phase 4에서 전체 루프를 실제 장애에 적용해봅니다. 파일럿에서 "추천이 안 맞는 경우"가 나오면 AI 고도화로 갑니다.