프론트 에러 일간 리포트 자동화

Datadog 신규 에러 알림을 Slack으로 보내고 반복되는 SDK 로그도 줄였다. 그래도 쌓인 알림은 내가 하나씩 열어봐야 했다.

전날보다 에러가 늘었는지 보려면 Datadog에서 서비스별 데이터를 다시 조회해야 했다. 새로 생긴 에러도 따로 찾아야 했다. 출근해서 매번 같은 화면을 여는 대신 전날 데이터를 Slack에서 먼저 보기로 했다.

채널에는 요약만 올렸다

Claude 예약 작업이 매일 오전 10시에 전날 데이터를 조회한다. 채널 메시지에는 전체 에러 수와 세션 수, 전일 대비 변화, 신규·급증 에러만 넣었다. 서비스별 상위 에러 10개는 스레드에 올렸다.

📊 프론트 일간 에러 리포트 (8/6 목요일)
전체 N건 / N세션 (전일 -53.2%) · 신규 11 · 급증 0
[채널 본문] 서비스별 발생량과 눈에 띄는 에러 요약
[스레드] 서비스별 상위 에러 10개
           (🆕 신규 / 🔁 반복 / 📈 급증)

한 세션에서 같은 에러가 반복되면 전체 건수만 크게 늘어날 수 있다. 그래서 에러가 발생한 세션 수도 같이 넣고 전일 대비 변화를 표시했다. 채널에서 메시지가 너무 길어지지 않도록 서비스별 상세 목록은 스레드로 보냈다.

모르는 에러는 스레드에서 물었다

API 응답 오류처럼 프론트 코드만 보고 원인을 알기 어려운 항목은 같은 스레드에서 담당자에게 물었다. 원인을 확인하면 답변과 후속 조치도 그 아래에 이어서 남겼다.

리포트를 프론트 채널에만 올릴지도 고민했다. 여러 서비스의 오류가 섞이고 API 500처럼 다른 영역의 확인이 필요한 경우가 있어서 개발 전체 채널에 공유했다.

한 주치 알림은 issue.id로 다시 묶었다

하루치만 보면 같은 에러가 한 주 동안 얼마나 반복됐는지 놓치기 쉬웠다. GPT 예약 작업으로 한 주 동안의 알림을 issue.id로 다시 묶었다. Slack 스레드에 남긴 답변과 후속 조치도 함께 보게 했다.

보고서에서는 실제 버그와 반복 노이즈, 더 지켜볼 에러를 나눴다. 실제 버그는 P1~P3로 표시하고 발생량과 세션 수, 사용자 수, 전주 대비 변화를 같이 적었다.

새로운 노이즈가 보이면 제외 조건도 제안하게 했다. 제안된 조건을 그대로 적용하지는 않았다. 에러 타입 전체를 빼면 실제 버그까지 가릴 수 있어서 RUM 데이터와 Slack 스레드를 다시 확인한 뒤 직접 수정했다. 이때 정한 기준은 SDK 로그를 수집 단계에서 줄인 과정과 같았다.

일간 집계는 Claude 예약 작업, 주간 분류와 필터 점검은 GPT 예약 작업으로 나눴다.

리포트는 지금도 내가 먼저 본다

첫 일간 리포트와 열흘 뒤 리포트를 비교했을 때 전체 에러 건수는 약 80%, 에러가 발생한 세션 수는 약 45% 줄었다. 이 수치는 리포트만의 결과가 아니다. 같은 기간에 적용한 SDK 로그 차단과 실제 버그 수정도 함께 반영돼 있다.

지금은 내가 리포트를 먼저 확인한다. 담당하지 않는 서비스의 에러는 바로 판단하기 어려워 관련 담당자와 스레드에서 같이 본다.