#Frontend

Sentry를 바로 도입하지 않고 200줄 에러 트래커를 만든 이유

Summary

Edge Function과 SQL만으로 복잡한 도입 승인 없이 실시간 에러 가시성 확보하기

표준 솔루션 도입의 높은 진입 장벽 대신, 정말 필요한 에러 수집과 알림 기능만 구현하여 운영 신뢰성을 확보한 사례를 소개합니다. FNV-1a 해싱을 통한 에러 식별과 DB 기반의 정책 관리 등 작지만 견고한 시스템 구축 노하우를 담고 있습니다.

도입 승인이 까다로운 대규모 조직이나, 복잡한 기능보다 핵심 지표 위주의 빠른 가시성이 필요한 초기 단계 프로젝트에 적합한 방식입니다.

Sentry와 같은 상용 솔루션 도입 시 발생하는 비용과 복잡한 승인 절차를 밟는 대신, 당장 서비스 운영의 신뢰성을 확보하기 위한 최소한의 클라이언트 에러 트래킹 수단이 필요했다.

Supabase Edge Function, Postgres, Slack Webhook을 조합하여 에러 수집, 중복 집계(Fingerprinting), Slack 알림이라는 핵심 기능에만 집중한 200줄 규모의 가벼운 에러 트래커를 직접 구축했다.

운영 3주 만에 불필요한 일회성 에러 노이즈를 7일 5회 임계값으로 필터링하는 데 성공했으며, 특정 환경에서 반복적으로 발생하는 유의미한 에러를 정확히 포착하여 원인을 파악하는 성과를 거두었다.

Trade-off

소스맵 심볼리케이션, 사용자 행동 이력(Breadcrumbs), 대시보드 UI 등 Sentry의 고급 기능을 배제했으며, 특히 초기 설계 시 빌드 SHA 기록을 누락하여 회귀 버그의 추적 시점을 명확히 알기 어렵다는 한계를 보였다.

Concept · 01

에러의 이름, 메시지, 스택 트래이스 등을 조합하여 고유한 식별자를 생성함으로써 동일한 원인의 에러를 하나의 그룹으로 묶는 기법이다.

Concept · 02

사용자와 가까운 전 세계 엣지 위치에서 실행되는 서버리스 함수로, 지연 시간이 적고 확장이 용이한 실행 환경이다.

Concept · 03

수집된 데이터 중 배포 환경이나 시점에 따라 변하는 가변 정보를 제거하여 일관된 데이터 형식을 유지하는 전처리 과정이다.

Continue reading · same source