프론트엔드 알림과 AI 지원 트리아지 봇

문제

서드파티로 넘어가는 구간의 조용한 이탈은 며칠 뒤 고객 지원을 통해서야 발견됐습니다. 알림은 임계값 기반이라 잡음이 많았고, 사람들은 무시하는 데 익숙해져 있었습니다.

접근 방식

• 고정 임계값이 아닌 상대 기준선. 알림 서비스는 텔레메트리 저장소에 SQL을 실행해 각 지표를 지난주 같은 시간대와 비교합니다. 20% 하락은 어느 지역의 새벽 3시에도 다른 지역의 정오에도 의미가 있고, 전 세계 트래픽의 오르내림은 더 이상 오경보를 일으키지 않습니다.
• 맥락과 함께 도착하는 알림. 알림이 울리면 팀 채팅에 인시던트 카드가 올라옵니다. 이어서 백그라운드 워커가 최근 프론트엔드 오류, 활성 설정 버전, 배포 로그를 모아 구조화된 프롬프트로 LLM API에 보냅니다.
• 스레드에 달리는 요약. 봇은 가능성 높은 근본 원인으로 답합니다. 예를 들면 한 단계의 전환율이 한 지역에서 떨어졌고, 네이티브 래퍼에서 null 포인터 오류가 났고, 15분 전에 설정 변경이 배포됐고, 하위 서비스가 타임아웃되고 있다는 식입니다.

결과

감지 시간이 몇 시간 또는 며칠에서 몇 분으로 줄고, 대응 시간도 단축됐으며, 알림은 사람들이 믿는 신호가 됐습니다. 알림의 신호 대 잡음 비율(실제 사고와 연결되는 알림의 비중)과 프론트엔드 모듈의 평균 고장 간격도 추적했습니다.

이 방식을 택한 이유

일반적인 알림은 무언가 고장 났다는 사실만 알려 줍니다. 데이터를 자동으로 모으고 요약하면 지표와 사람의 이해 사이의 간극이 좁혀지고, 대응 시간의 대부분이 바로 그 간극에서 사라지고 있었습니다.