Sentry를 바로 도입하지 않고 200줄 에러 트래커를 만든 이유
프론트엔드
Sentry를 바로 도입하지 않고 200줄 에러 트래커를 만든 이유
두줄요약
Sentry 대신 필요한 기능만 남긴 작은 에러 트래커를 직접 만들어 운영한 사례를 정리했습니다.재배포 없이 기준을 조정하고 반복 에러만 선별하는 방식의 장단점을 공유했습니다.
핵심 내용
- Sentry 대신 200줄 수준의 자체 클라이언트 에러 트래커를 만든 이유와 운영 경험 정리
- 클라이언트 에러 수집, 중복 집계, Slack 알림만 남기고 나머지 기능은 과감히 제외
- Supabase Edge Function, Postgres, Slack Webhook 조합으로 최소 운영 신뢰성 확보
선택 이유
- 도입 비용과 승인 절차보다 빠른 실행과 즉시 운영 가능성이 더 중요했던 상황
- 자체 구축 시 관리 포인트 증가를 막기 위해 필요한 기능만 제한
- 임계값과 쿨다운을 DB에 두어 재배포 없이 운영 기준 조정 가능
장단점
- 장점: 배포 변경에도 유지되는 fingerprint, 반복 에러 집계, 알림 스팸 억제
- 장점: OS, 브라우저, 플랫폼 메타데이터로 원인 추적 속도 개선
- 단점: Source map symbolication, breadcrumbs, 자동 주입, 대시보드 같은 고급 기능 부재
적용해볼 점
- 반복되는 클라이언트 에러만 먼저 잡는 최소 트래커 전략
- 운영 정책은 클라이언트보다 DB나 서버에서 관리하는 방식
- 배포 SHA 같은 추적 키를 초기부터 넣어 회귀 분석 단서 확보