Sentry를 바로 도입하지 않고 200줄짜리 에러 추적기를 만든 이유

핵심 선택

Sentry를 바로 도입하는 대신, 약 200줄 규모의 자체 클라이언트 에러 추적기를 만들었다. 승인과 도입 시간을 아끼고, 당장 필요한 최소한의 운영 신뢰성을 확보하는 쪽이 더 현실적이라고 봤다.

• 수집: window.error, Promise rejection, React Query 실패, Axios 5xx
• 집계: 같은 에러의 반복 발생 횟수 추적
• 알림: 임계값 초과 시 Slack Webhook 전송
• 스팸 방지: 한 번 알린 에러는 일정 기간 재알림 금지

구현 방식

에러는 브라우저와 WebView에서 reportError로 모은 뒤, fingerprint를 생성해 Supabase Edge Function으로 보냈다. Edge Function은 Postgres에 저장하고, 누적 횟수가 기준을 넘었을 때만 Slack 알림을 보냈다.

같은 버그를 같은 버그로 묶기 위해 stack trace를 정규화한 뒤 FNV-1a 32비트 해시를 적용했다. line·col, 번들 해시처럼 배포마다 바뀌는 요소를 먼저 제거해, minified 함수명이 달라져도 같은 이슈로 집계되게 했다.

운영 기준

임계값과 쿨다운은 클라이언트가 아니라 DB의 RPC 함수 안에 넣었다. 숫자를 바꾸려면 SQL Editor에서 수정만 하면 되므로, 재배포 없이 알림 정책을 조정할 수 있다.

Source map symbolication, breadcrumbs, 자동 User ID 주입, 자체 대시보드, 이슈 트래커 자동 생성은 모두 제외했다. 관리 포인트를 늘리기보다 실제 필요한 기능만 남겨 도구가 본업을 잠식하지 않게 하는 데 초점을 맞췄다.

적용 결과

운영 전에는 dev/stage에서 한 달 넘게 QA했고, 최근에 운영 배포까지 진행했다. 다만 운영 표본은 아직 충분하지 않아, 관찰은 주로 dev/stage 데이터를 기준으로 정리했다.

3주 동안 7일 5회 기준을 넘긴 fingerprint는 단 1건뿐이었다. 대부분은 네트워크 일시 단절, 광고 SDK 실패, 빠른 이탈 같은 일회성 에러였고, 임계값을 1로 낮춰 raw 데이터를 보니 그 경향이 더 분명했다.

유일하게 임계값을 넘긴 사례는 특정 OS + WebView 조합에서만 발생한 버그였다. device/browser/platform 메타데이터를 함께 저장해 둔 덕분에 원인 좁히기가 빨랐다.

아쉬운 점도 있었다. 빌드 SHA를 처음부터 넣지 않아 회귀 버그의 시작 배포를 바로 잡기 어려웠고, 이 항목은 지금 우선순위가 올라가 있다. 모든 에러를 완벽히 보는 도구는 아니지만, 반복되는 클라이언트 에러를 놓치지 않는 수준의 가시성은 확보했다.