Datadog RUM 신규 에러를 Slack으로 받기

Datadog RUM과 Session Replay는 이미 쓰고 있었다. 하지만 에러를 확인하는 시점은 대부분 CS 문의가 들어온 뒤였다. 담당자가 알려준 사용자와 발생 시각으로 세션을 찾고, 에러가 나기 전후 화면을 돌려봤다.

문의로 이어지지 않은 에러는 직접 Datadog을 열기 전까지 알기 어려웠다. RUM에 새로 쌓이는 에러를 Slack으로 받아보기로 했다.

서비스와 환경을 나눠 모니터 6개를 만들었다

주말에 Claude와 이 불편을 이야기하다 Datadog 모니터 구성을 같이 살펴봤다. RUM 데이터를 조회하면서 어떤 조건으로 신규 에러를 구분할지 정했다.

서비스 3개와 dev/prod 환경을 조합해 모니터 6개를 만들었다. 새로운 에러 패턴이 잡히면 전용 Slack 채널로 알림이 오게 했다.

dev 모니터는 배포 전에 확인할 때 썼다. QA 중 dev에서 처음 발생한 에러를 보고 운영 배포 전에 수정한 적도 있었다.

막상 모니터를 켜니 알림이 꽤 많이 왔다. 앱 웹뷰의 User-Agent가 봇으로 분류되는 경우도 있었다. 테스트 중인 설정과 쿼리는 프론트엔드 채널에 공유했다. 다른 개발자도 현재 조건을 볼 수 있게 했다.

수정한 PR은 알림 댓글에 달았다

새 알림이 오면 발생량과 Session Replay를 확인했다. 실제 버그라면 수정한 뒤 해당 알림의 댓글에 PR 링크를 달았다.

민감한 오류 정보 생략

Slack에 처음 찍혔다고 전부 버그는 아니었다

신규 에러라고 전부 수정해야 하는 건 아니었다. 브라우저 확장 프로그램이나 외부 SDK에서 반복되는 로그도 있었고, 당장 원인을 확정하기 어려워 조금 더 봐야 하는 에러도 있었다.

처음부터 제외 조건을 많이 넣으면 실제 버그까지 놓칠 수 있었다. 일단 알림을 받은 다음 하나씩 열어보고 쿼리를 고쳤다. Claude는 첫 쿼리 형태를 잡고 Datadog 문법을 확인할 때 썼다. 실제로 무엇을 뺄지는 RUM 데이터와 Slack에서 받은 의견을 보고 정했다.

이 과정에서 반복해서 보이던 SDK 로그는 수집 단계에서 줄였다. 자세한 내용은 Datadog RUM에서 SDK 로그 제외하기에 적었다. 남은 에러를 매일 확인하는 과정은 프론트 에러 일간 리포트 자동화로 이어진다.