프론트 에러 일간 리포트 만들기

신규 에러 모니터는 처음 생긴 에러를 바로 알려줬다. 하루 동안 어떤 에러가 많이 쌓였는지는 따로 Datadog에 들어가 서비스별로 조회해야 했다. 매일 같은 화면을 여는 대신 출근하면 전날 데이터를 Slack에서 먼저 받아보기로 했다.

첫 리포트는 노이즈가 대부분이었다

첫 테스트에서는 선생님용 웹, 수강생용 웹과 앱으로 나눠 상위 에러를 뽑았다. 수강생용 웹에서만 수천 건이 잡혔고 상위 대부분은 Amplitude와 푸시 SDK가 남긴 로그였다.

처음엔 필터를 거의 걸지 않고 그대로 받아봤다. 어떤 로그가 실제 에러를 가리고 있는지 먼저 보고 싶었다. SDK 로그와 봇 세션을 수집 단계에서 줄인 뒤에도 남는 항목은 하나씩 Session Replay를 확인했다.

채널에는 요약만, 상세 내용은 스레드에

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

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

한 세션에서 같은 에러가 반복되면 전체 건수만 크게 늘어난다. 그래서 세션 수도 같이 넣고 전일 대비 변화도 표시했다. 서비스별 상세 목록은 스레드로 보냈다.

원인을 모르면 스레드에서 물어봤다

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

처음에는 프론트 채널에만 올릴까도 생각했다. 그런데 여러 서비스의 오류가 섞였고 API 500처럼 다른 개발자의 확인이 필요한 경우도 많았다. 팀장님께 취지를 설명한 뒤 개발 전체 채널에 올렸다.

금요일에는 한 주치 알림을 다시 봤다

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

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

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

아예 수집할 필요가 없는 SDK 로그는 초기화 설정에서 줄였다. 원본을 남겨야 하는 브라우저 확장 프로그램 에러는 Slack 모니터 쿼리에서만 제외했다.

일간 집계는 Claude 루틴이 맡고 주간 분류와 필터 점검은 GPT 예약 작업으로 돌렸다.

잡히는 에러가 약 84% 줄었다

첫 테스트에서 세 서비스의 운영 에러는 하루 24,494건이었다. 8월 28일 같은 범위로 다시 조회했을 때는 3,877건, 1,071세션이 잡혔다. 처음보다 약 84% 줄어든 수치다.

이걸 전부 리포트의 효과라고 보기는 어렵다. SDK 로그 수집을 끈 것과 봇 세션 제외, 그동안 수정한 버그가 같이 반영됐다. 날짜별 트래픽 차이도 있다.

아직 해결하지 못한 에러도 남아 있다. Load failed는 같은 날 105건, 49세션에서 발생했다. 앱 웹뷰의 일시적인 네트워크 문제와 실제 리소스 실패가 같은 문구로 묶여 있어서 모니터에서 제외하지 않았다.

지금은 출근하면 이 리포트부터 확인한다. 내가 담당하지 않는 서비스는 관련 개발자에게 스레드에서 물어본다. Load failed처럼 아직 원인을 나누지 못한 에러도 여기서 계속 보고 있다.