Blog·인사이트

에러 모니터링, 런칭 후 반드시 해야 하는 것

···5분 읽기
요약

불만족한 고객 26명 중 단 1명만 실제로 신고합니다. 나머지 25명은 조용히 이탈합니다. 런칭 후 사용자가 발견한 에러를 운영자가 알 수 있는 유일한 방법은 에러 모니터링입니다. Sentry·Datadog 같은 도구로 자동 수집하지 않으면 보이지 않는 손실이 누적됩니다.

서비스를 런칭하면 개발팀은 안도의 한숨을 쉽니다. 하지만 진짜 전쟁은 그때부터 시작됩니다. 사용자는 버그를 발견해도 신고하지 않습니다. 그냥 앱을 삭제하고 떠납니다. Lee Resources의 조사에 따르면 불만족한 고객 26명 중 단 1명만이 실제로 불만을 제기합니다.

나머지 25명은 조용히 이탈합니다. 이 통계는 B2C 서비스뿐 아니라 B2B SaaS에서도 동일하게 적용됩니다. 에러 모니터링은 선택이 아니라 런칭 후 생존을 위한 필수 장치입니다.

무엇을 모니터링해야 하는가

에러 모니터링의 대상은 크게 네 가지로 나뉩니다. 첫째, JavaScript 런타임 에러입니다. 프론트엔드 컴포넌트 렌더링 에러, undefined 참조 에러, 타입 에러 등이 여기에 해당합니다. 프레임워크가 서버에서 렌더링하는 컴포넌트(Next.js의 RSC, Nuxt의 서버 컴포넌트 등)에서 발생하는 에러는 클라이언트에서는 보이지 않으므로 서버 측 로깅이 반드시 필요합니다.

둘째, API 실패입니다. 4xx 클라이언트 에러와 5xx 서버 에러를 구분해서 추적해야 합니다. 특히 백엔드에서 반환하는 500 에러는 즉시 대응이 필요한 심각한 문제입니다. 403 에러가 갑자기 급증한다면 인증 토큰 만료 로직에 문제가 있을 가능성이 높습니다.

셋째, 느린 응답 시간입니다. 페이지 로드가 3초를 넘으면 사용자의 53%가 이탈한다는 Google의 데이터가 있습니다. 데이터베이스 쿼리 성능 저하가 원인인 경우가 많으므로 슬로우 쿼리 로그도 함께 모니터링해야 합니다.

넷째, 크래시 비율입니다. 특정 디바이스나 브라우저에서 집중적으로 발생하는 크래시 패턴을 파악해야 합니다.

에러 모니터링 도구 비교

Sentry는 가장 널리 사용되는 에러 모니터링 도구입니다. 무료 플랜에서도 월 5,000건의 이벤트를 처리할 수 있어 초기 스타트업에 적합합니다. 다양한 프레임워크(Next.js, Nuxt, Vue, Express, Django, Spring Boot 등)와의 통합이 간편하며, 소스맵 업로드를 지원해 프로덕션 빌드에서도 정확한 에러 위치를 파악할 수 있습니다.

프론트엔드·백엔드 SDK가 모두 제공되어 양쪽을 하나의 대시보드에서 통합 관리할 수 있다는 것이 큰 장점입니다. LogRocket은 세션 리플레이 기능이 강점입니다. 사용자가 에러를 경험하기 직전에 어떤 행동을 했는지 영상처럼 재현할 수 있어 재현이 어려운 버그 추적에 탁월합니다.

월 1,000세션까지 무료로 사용할 수 있습니다. Datadog은 인프라 수준의 모니터링에 강합니다. 클라우드 인프라(GCP, AWS 등)의 CPU, 메모리, 컨테이너 상태까지 통합 관리할 수 있어 대규모 서비스에 적합합니다. 다만 비용이 상대적으로 높아 초기 단계에서는 Sentry로 시작하는 것을 권장합니다.

전용 도구가 부담스러울 때: 글로벌 에러 리스너 + 분석 도구

전용 모니터링 도구를 도입하기 전이라도 자바스크립트만으로 최소한의 에러 수집은 가능합니다. window.addEventListener('error', ...) 와 window.addEventListener('unhandledrejection', ...) 두 개를 글로벌로 달아두면, 어디서든 잡히지 않은 JS 예외와 reject 된 Promise를 한 곳에서 받을 수 있습니다.

리스너 콜백에서 받은 정보(메시지·파일·라인·스택)를 이미 운영 중인 분석 도구로 그대로 흘려보내면 됩니다. Google Analytics 의 이벤트, Mixpanel·Amplitude 의 커스텀 이벤트, 혹은 자체 백엔드의 로그 수집 엔드포인트 어디로 보내도 동작 원리는 같습니다. 이렇게만 해도 "어떤 페이지에서, 어떤 에러가, 어떤 빈도로 발생하는지" 추세는 잡힙니다.

스택 트레이스의 깊이나 사용자 세션 컨텍스트, 알림·그룹핑은 전용 도구 대비 부족합니다. 다만 도구 도입 결정을 미루는 동안 사각지대를 줄이는 가장 가벼운 시작점이고, 나중에 Sentry 등 전용 도구로 옮길 때 기존 리스너 코드를 그대로 갈아끼우면 되기 때문에 매몰 비용도 거의 없습니다.

알림 체계 구축

에러를 수집만 하고 확인하지 않으면 의미가 없습니다. Sentry와 Slack을 연동하면 에러 발생 즉시 개발 채널에 알림이 전송됩니다. 에러 레벨에 따라 알림 강도를 차등 적용하는 것이 중요합니다. Critical 에러는 즉시 알림, Warning은 일일 다이제스트로 정리하는 방식이 효과적입니다.

알림 피로도를 관리하지 않으면 정작 중요한 알림을 놓치게 됩니다. 동일한 에러가 반복 발생할 때는 그룹핑하여 하나의 알림으로 묶고, 발생 빈도를 표시하는 것이 좋습니다. 이메일 알림은 긴급하지 않은 주간 리포트에 활용하고, Slack은 실시간 대응이 필요한 에러에 집중시킵니다.

프로덕트 메이커의 운영 방식

프로덕트 메이커는 모든 프로젝트에 에러 모니터링을 기본 구성합니다. 도구는 클라이언트 환경에 맞춰 선택하며, 그동안 가장 자주 활용한 것은 Sentry입니다. 프론트엔드와 백엔드 양쪽에 SDK를 설치하고, 클라우드 컨테이너 로그도 중앙 로깅 서비스와 연동하여 통합 관리합니다.

특히 런칭 후 첫 2주는 집중 모니터링 기간으로 설정하여 에러 대시보드를 매일 확인합니다. 사용자가 신고하기 전에 운영자가 먼저 인지하는 것이 목표입니다. 특정 브라우저나 디바이스에서만 발생하는 렌더링 문제, 특정 시간대에 몰리는 5xx 에러, 평소보다 갑자기 늘어난 401·403 패턴처럼 사용자 입장에서는 굳이 신고할 정도가 아니지만 누적되면 이탈로 이어지는 신호들을 가장 효과적으로 잡아낼 수 있는 시기입니다.

이후에는 정기 리뷰에서 에러 트렌드를 분석하고, 현황과 대응 결과를 의사결정자에게 직접 공유합니다. 에러 모니터링은 서비스 품질을 지키는 최후의 방어선입니다.

다른 포스팅
Blog·인사이트

에러 모니터링, 런칭 후 반드시 해야 하는 것

···5분 읽기

서비스를 런칭하면 개발팀은 안도의 한숨을 쉽니다. 하지만 진짜 전쟁은 그때부터 시작됩니다. 사용자는 버그를 발견해도 신고하지 않습니다. 그냥 앱을 삭제하고 떠납니다. Lee Resources의 조사에 따르면 불만족한 고객 26명 중 단 1명만이 실제로 불만을 제기합니다.

나머지 25명은 조용히 이탈합니다. 이 통계는 B2C 서비스뿐 아니라 B2B SaaS에서도 동일하게 적용됩니다. 에러 모니터링은 선택이 아니라 런칭 후 생존을 위한 필수 장치입니다.

무엇을 모니터링해야 하는가

에러 모니터링의 대상은 크게 네 가지로 나뉩니다. 첫째, JavaScript 런타임 에러입니다. 프론트엔드 컴포넌트 렌더링 에러, undefined 참조 에러, 타입 에러 등이 여기에 해당합니다. 프레임워크가 서버에서 렌더링하는 컴포넌트(Next.js의 RSC, Nuxt의 서버 컴포넌트 등)에서 발생하는 에러는 클라이언트에서는 보이지 않으므로 서버 측 로깅이 반드시 필요합니다.

둘째, API 실패입니다. 4xx 클라이언트 에러와 5xx 서버 에러를 구분해서 추적해야 합니다. 특히 백엔드에서 반환하는 500 에러는 즉시 대응이 필요한 심각한 문제입니다. 403 에러가 갑자기 급증한다면 인증 토큰 만료 로직에 문제가 있을 가능성이 높습니다.

셋째, 느린 응답 시간입니다. 페이지 로드가 3초를 넘으면 사용자의 53%가 이탈한다는 Google의 데이터가 있습니다. 데이터베이스 쿼리 성능 저하가 원인인 경우가 많으므로 슬로우 쿼리 로그도 함께 모니터링해야 합니다.

넷째, 크래시 비율입니다. 특정 디바이스나 브라우저에서 집중적으로 발생하는 크래시 패턴을 파악해야 합니다.

에러 모니터링 도구 비교

Sentry는 가장 널리 사용되는 에러 모니터링 도구입니다. 무료 플랜에서도 월 5,000건의 이벤트를 처리할 수 있어 초기 스타트업에 적합합니다. 다양한 프레임워크(Next.js, Nuxt, Vue, Express, Django, Spring Boot 등)와의 통합이 간편하며, 소스맵 업로드를 지원해 프로덕션 빌드에서도 정확한 에러 위치를 파악할 수 있습니다.

프론트엔드·백엔드 SDK가 모두 제공되어 양쪽을 하나의 대시보드에서 통합 관리할 수 있다는 것이 큰 장점입니다. LogRocket은 세션 리플레이 기능이 강점입니다. 사용자가 에러를 경험하기 직전에 어떤 행동을 했는지 영상처럼 재현할 수 있어 재현이 어려운 버그 추적에 탁월합니다.

월 1,000세션까지 무료로 사용할 수 있습니다. Datadog은 인프라 수준의 모니터링에 강합니다. 클라우드 인프라(GCP, AWS 등)의 CPU, 메모리, 컨테이너 상태까지 통합 관리할 수 있어 대규모 서비스에 적합합니다. 다만 비용이 상대적으로 높아 초기 단계에서는 Sentry로 시작하는 것을 권장합니다.

전용 도구가 부담스러울 때: 글로벌 에러 리스너 + 분석 도구

전용 모니터링 도구를 도입하기 전이라도 자바스크립트만으로 최소한의 에러 수집은 가능합니다. window.addEventListener('error', ...) 와 window.addEventListener('unhandledrejection', ...) 두 개를 글로벌로 달아두면, 어디서든 잡히지 않은 JS 예외와 reject 된 Promise를 한 곳에서 받을 수 있습니다.

리스너 콜백에서 받은 정보(메시지·파일·라인·스택)를 이미 운영 중인 분석 도구로 그대로 흘려보내면 됩니다. Google Analytics 의 이벤트, Mixpanel·Amplitude 의 커스텀 이벤트, 혹은 자체 백엔드의 로그 수집 엔드포인트 어디로 보내도 동작 원리는 같습니다. 이렇게만 해도 "어떤 페이지에서, 어떤 에러가, 어떤 빈도로 발생하는지" 추세는 잡힙니다.

스택 트레이스의 깊이나 사용자 세션 컨텍스트, 알림·그룹핑은 전용 도구 대비 부족합니다. 다만 도구 도입 결정을 미루는 동안 사각지대를 줄이는 가장 가벼운 시작점이고, 나중에 Sentry 등 전용 도구로 옮길 때 기존 리스너 코드를 그대로 갈아끼우면 되기 때문에 매몰 비용도 거의 없습니다.

알림 체계 구축

에러를 수집만 하고 확인하지 않으면 의미가 없습니다. Sentry와 Slack을 연동하면 에러 발생 즉시 개발 채널에 알림이 전송됩니다. 에러 레벨에 따라 알림 강도를 차등 적용하는 것이 중요합니다. Critical 에러는 즉시 알림, Warning은 일일 다이제스트로 정리하는 방식이 효과적입니다.

알림 피로도를 관리하지 않으면 정작 중요한 알림을 놓치게 됩니다. 동일한 에러가 반복 발생할 때는 그룹핑하여 하나의 알림으로 묶고, 발생 빈도를 표시하는 것이 좋습니다. 이메일 알림은 긴급하지 않은 주간 리포트에 활용하고, Slack은 실시간 대응이 필요한 에러에 집중시킵니다.

프로덕트 메이커의 운영 방식

프로덕트 메이커는 모든 프로젝트에 에러 모니터링을 기본 구성합니다. 도구는 클라이언트 환경에 맞춰 선택하며, 그동안 가장 자주 활용한 것은 Sentry입니다. 프론트엔드와 백엔드 양쪽에 SDK를 설치하고, 클라우드 컨테이너 로그도 중앙 로깅 서비스와 연동하여 통합 관리합니다.

특히 런칭 후 첫 2주는 집중 모니터링 기간으로 설정하여 에러 대시보드를 매일 확인합니다. 사용자가 신고하기 전에 운영자가 먼저 인지하는 것이 목표입니다. 특정 브라우저나 디바이스에서만 발생하는 렌더링 문제, 특정 시간대에 몰리는 5xx 에러, 평소보다 갑자기 늘어난 401·403 패턴처럼 사용자 입장에서는 굳이 신고할 정도가 아니지만 누적되면 이탈로 이어지는 신호들을 가장 효과적으로 잡아낼 수 있는 시기입니다.

이후에는 정기 리뷰에서 에러 트렌드를 분석하고, 현황과 대응 결과를 의사결정자에게 직접 공유합니다. 에러 모니터링은 서비스 품질을 지키는 최후의 방어선입니다.

다른 포스팅
WebGL프로젝트 상담