Sentry 대신 200줄 에러 트래커를 만든 개발자의 이야기

본문에서는 Sentry와 같은 상용 에러 트래킹 도구 대신 자체 구축을 선택한 배경을 설명한다. 도입 비용(Adoption Cost)과 승인 절차(Approval Process)의 시간적 제약으로 인해, 빠른 프로덕션 배포(Fast Production Deployment)를 위해 자체 솔루션을 선택했다.

결과적으로, 초기 단계에서는 핵심 기능(Core Feature)에 집중하고, 운영 상황에 따라 Sentry와 같은 상용 도구로 전환하는 것이 효율적일 수 있다.

저자는 배포 환경 변화에도 에러를 정확하게 식별하기 위해 Stack Trace 대신 Fingerprint 해싱(Hashing) 방식을 채택했다. 빌드 시마다 변경되는 함수명과 같은 부분을 정규화하고, FNV-1a 32비트 해시를 적용하여 에러의 일관성(Error Consistency)을 유지했다.

이러한 방식은 배포 빈도가 높은 환경(High Deployment Frequency)에서 특히 유용하다.

알림 기준 변경의 유연성을 확보하기 위해, 임계값(Threshold)과 쿨다운(Cooldown)을 클라이언트가 아닌 DB에 저장했다. DB 기반 설정(DB-based Configuration)을 통해 재배포 없이 알림 기준을 변경할 수 있으며, 운영 중 발생하는 다양한 상황(Operational Scenario)에 유연하게 대처할 수 있다.

이러한 방식은 운영 효율성(Operational Efficiency)을 높이고, 빠른 의사 결정(Fast Decision Making)을 가능하게 한다.

3주간의 운영 데이터를 분석한 결과, 대부분의 에러가 일회성으로 발생했으며, 설정한 임계값(Threshold)이 유의미한 에러(Meaningful Error)를 효과적으로 식별하는 데 기여했다. 또한, UA(User Agent) 정보를 함께 저장하여 특정 환경에서 발생하는 에러의 원인을 빠르게 파악할 수 있었다.

결과적으로, 최소한의 에러 트래킹(Minimal Error Tracking)을 통해 운영 가시성(Operational Visibility)을 확보하고, CSR 기반 서비스(CSR-based Service)의 문제점을 개선할 수 있었다.