← 포트폴리오 · 무신사

신뢰성 자동화 — Alert Gateway와 인시던트 봇

멀티소스 알림을 하나로 모아 중복을 제거하고 LLM·RAG로 컨텍스트를 붙인 뒤, Slack에서 장애 대응 전 과정이 흐르게 만들었습니다.

문제

알림은 많은데 정보는 없었습니다.

• CloudWatch · Datadog · Grafana가 각각 알림을 보냈고, 하나의 장애가 세 채널에서 서로 다른 모양으로 도착했습니다.
• 같은 알림이 반복 발화되면서 실제 신호가 묻혔습니다.
• 알림 본문만으로는 대응을 시작할 수 없었습니다. 어느 서비스인지, 최근에 무슨 배포가 있었는지, 이전에 같은 일이 있었는지를 매번 따로 찾아야 했습니다.

그리고 장애가 선언되면 채널 생성 → 티켓 생성 → 온콜 호출 → 문서 링크를 사람이 손으로 했습니다. 가장 급한 순간에 가장 기계적인 일이 사람 손에 있었습니다.

제약

• 알림 소스를 하나로 통일하는 것은 불가능했습니다. 각각 존재 이유가 있었습니다.
• 자동화가 틀리면 대응이 더 느려집니다. 실패했을 때 사람이 바로 이어받을 수 있어야 했습니다.
• LLM 응답 지연이 알림 전달을 막으면 안 됐습니다.

설계

1. 멀티소스 Alert Gateway

CloudWatch ┐
Datadog    ├→  정규화  →  Redis 중복 제거  →  심각도 분류  →  LLM·RAG 컨텍스트 보강  →  전달
Grafana    ┘

• 정규화 — 소스별로 다른 페이로드를 공통 스키마로 변환. 이게 없으면 뒤의 모든 단계가 소스별 분기가 됩니다.
• Redis 기반 중복 제거 — 동일 조건 알림을 윈도우 단위로 묶어 한 번만 전달
• 심각도 분류 — SEV 등급 체계와 연결
• LLM · RAG 컨텍스트 보강 — 관련 문서·과거 사례·서비스 정보를 알림에 붙여서 보냄

보강 단계는 실패해도 알림은 나갑니다. LLM 호출이 느리거나 실패하면 원본 알림이 그대로 전달됩니다. 보강은 부가 가치지 전달 경로가 아니어야 합니다.

2. Slack 인시던트 봇

Jira · PagerDuty · Confluence를 연동해 장애 대응 동선을 Slack 안에서 끝나게 했습니다.

• 장애 선언 → 채널 생성 → Jira 티켓 생성 → PagerDuty 온콜 호출
• 프레임워크 문서(SOP·체크리스트) 링크 자동 첨부
• 타임라인 기록 — Scribe 역할의 기계적인 부분을 봇이 대신함

프레임워크에서 정의한 역할 모델과 Close 게이트가 봇의 동작으로 구현돼 있습니다. 문서로만 있는 절차는 지켜지지 않고, 도구에 박혀 있는 절차는 지켜집니다.

3. PagerDuty 온콜 체계 전사 확장

온콜을 일부 조직의 관행에서 전사 체계로 확장하고, 온콜 건전성을 지표로 관리했습니다.

4. 격주 Incident Flash Report

SLA 위반 추적과 Error Budget 모니터링을 격주 리포트로 묶어 경영 보고 라인에 연결했습니다. 대응 결과가 조직 밖으로 나가지 않으면 개선에 필요한 리소스도 받을 수 없습니다.

결과

• 알림 중복 제거로 실제 신호의 가시성 확보
• 장애 선언 이후의 준비 작업이 사람 손에서 빠짐 — 대응 시작 시점이 앞당겨짐
• 프레임워크 절차가 도구에 구현되어 준수율이 문서 의존에서 벗어남
• 격주 Flash Report로 SLA 위반·Error Budget이 정기 보고 항목이 됨

회고

LLM을 경로가 아니라 곁가지에 붙인 것이 맞았습니다. 보강 단계를 필수 경로에 두면 모델 지연이 곧 알림 지연이 됩니다. "실패하면 원본 그대로 나간다"는 설계가 실제 운영에서 여러 번 값을 했습니다.

자동화의 이득은 시간보다 순서였습니다. 채널 생성에 드는 30초를 줄인 것보다, 대응자가 도착했을 때 이미 티켓과 문서와 타임라인이 준비돼 있다는 점이 컸습니다.

관련 케이스 — 전사 장애관리 프레임워크 · AI 거버넌스 프레임워크

CloudWatch Datadog Grafana Redis LLM/RAG Slack API Jira PagerDuty Confluence Python