에러 모니터링 셋업: Sentry vs GlitchTip 셀프호스트, 1인 운영에서 장애를 먼저 아는 법

사용자가 알려주기 전에 알아야 하는 이유

1인 개발에서 가장 곤란한 장애는 에러 자체보다 ‘언제부터 발생했는지 모르는 에러’입니다. 사용자가 화면을 캡처해 보내기 전까지 로그인 실패, 결제 버튼 오류, 특정 브라우저의 렌더링 문제를 알아차리지 못할 수 있습니다. 로그를 나중에 뒤지는 방식만으로는 원인과 영향 범위를 빠르게 연결하기 어렵습니다.

조코헌트에 출시된 프로덕트는 380개입니다. 제품 수가 늘어날수록 모든 사용자의 환경을 직접 재현하기는 더 어려워집니다. 또 출시 첫 24시간 안에 업보트나 댓글 같은 반응을 하나라도 받은 프로덕트는 44%입니다. 초기부터 실제 사용자가 들어올 수 있다는 뜻이므로, ‘아직 작으니 모니터링은 나중에’라고 미루기보다 첫 배포부터 실패 신호를 모으는 편이 안전합니다.

에러 모니터링의 역할은 단순히 에러 개수를 세는 데 있지 않습니다. 어떤 요청에서, 어떤 사용자 환경에서, 어떤 배포 이후 문제가 시작됐는지를 한곳에 모아 대응 순서를 정하게 해줍니다.

Sentry와 GlitchTip, 먼저 운영 방식을 고르기

Sentry: 관리 부담을 줄이는 클라우드 방식

Sentry는 계정을 만들고 SDK를 연결한 뒤 대시보드와 알림을 사용하는 흐름에 가깝습니다. 서버를 따로 운영하지 않아도 되므로, 혼자 제품 기능과 고객 대응에 집중하고 싶을 때 시작 장벽이 낮습니다.

대신 사용량, 보존 기간, 알림 범위, 팀 기능 등은 현재 요금제와 정책을 확인해야 합니다. 무료 구간이나 세부 제한을 고정된 사실처럼 기억하지 말고 공식 문서에서 확인하세요. 데이터가 외부 서비스로 전송되는 만큼 개인정보와 민감한 요청 정보가 이벤트에 포함되지 않는지도 점검해야 합니다.

GlitchTip: 통제권을 얻는 셀프호스트 방식

GlitchTip은 직접 서버에 배포해 운영할 수 있는 오픈소스 계열의 선택지입니다. 데이터 저장 위치와 보존 정책을 더 세밀하게 통제하고 싶거나, 이미 운영 중인 서버·데이터베이스 환경을 활용하고 싶을 때 검토할 만합니다.

다만 도구를 설치하는 일과 운영하는 일은 다릅니다. 업데이트, 백업, 디스크 부족, 접근 제어, 장애 시 모니터링 도구 자체의 복구까지 책임져야 합니다. 셀프호스트를 선택한다면 배포·호스팅 비교 글에서 다룬 것처럼 ‘호스팅 비용’만 보지 말고 관리 시간까지 함께 계산하세요.

첫 셋업은 알림보다 맥락

이벤트에 남길 정보와 지울 정보

처음에는 모든 로그를 보내려 하기보다 실제로 고칠 수 있는 정보부터 정하세요.

에러 종류와 메시지
발생한 URL 또는 API 경로
앱 버전과 배포 환경
브라우저·운영체제 같은 실행 환경
로그인 사용자라면 내부 식별자

이메일, 전화번호, 토큰, 결제 정보, 원문 입력값처럼 민감할 수 있는 값은 기본적으로 제외하거나 마스킹합니다. 에러 이벤트가 많아지는 것보다, 나중에 봐도 안전하고 이해할 수 있는 이벤트가 쌓이는 것이 중요합니다. 사용자 행동을 분석하려는 목적이라면 제품 분석 도구 스택과 에러 모니터링의 역할을 분리하는 편이 관리하기 쉽습니다.

소스맵으로 스택 트레이스를 읽을 수 있게 하기

프론트엔드 코드를 빌드하면 사용자가 받는 자바스크립트는 압축·변환됩니다. 이 상태에서 에러가 발생하면 스택 트레이스가 알아보기 어려운 파일명과 줄 번호로 표시될 수 있습니다. 소스맵은 배포된 코드의 위치를 원래 소스의 파일과 줄로 연결해주는 지도입니다.

배포 과정에서 소스맵을 생성하고 모니터링 서비스에 업로드하되, 공개 웹 서버가 소스맵 파일을 그대로 제공하지 않는지 확인하세요. 로컬에서는 읽기 쉬운 원본 위치가 보이고, 운영에서는 민감한 소스가 불필요하게 노출되지 않도록 배포 설정을 분리하는 방식이 일반적입니다.

1인 운영에 맞는 선택 기준

Sentry가 어울리는 경우

다음 질문에 ‘그렇다’가 많다면 Sentry부터 시작하는 흐름이 편할 수 있습니다.

이번 주 안에 기능을 출시해야 하는가?
모니터링 서버를 관리할 시간이 거의 없는가?
팀이 작고 장애 알림을 빠르게 받아야 하는가?
사용량과 보존 정책을 확인한 뒤 외부 서비스 사용이 가능한가?

GlitchTip이 어울리는 경우

반대로 데이터 통제와 운영 환경의 일관성이 더 중요하다면 GlitchTip을 검토할 수 있습니다.

로그와 이벤트를 특정 인프라 안에 두어야 하는가?
서버 업데이트와 백업을 맡을 운영 루틴이 있는가?
이미 셀프호스트 환경을 관리하고 있는가?
도구 자체의 장애까지 감당할 준비가 되어 있는가?

처음부터 완벽한 선택을 하려 하기보다, 현재의 병목을 기준으로 고르세요. 에러를 한 번도 추적하지 않는 상태에서 셀프호스트를 정교하게 설계하는 것보다, 관리 가능한 방식으로 먼저 신호를 확보하는 편이 빠른 경우가 많습니다. 전체 스택에서 어디에 붙일지 헷갈린다면 1인 개발자 SaaS 풀스택 도구 지도를 기준표처럼 활용해도 좋습니다.

오늘 바로 적용하는 최소 체크리스트

프론트엔드와 백엔드 중 장애 영향이 큰 곳부터 SDK를 연결합니다.
운영 환경과 로컬 환경을 구분해 이벤트를 보냅니다.
민감한 데이터가 이벤트에 들어가지 않도록 필터를 둡니다.
새 에러와 반복 에러를 구분할 알림 조건을 정합니다.
알림 채널 하나에서 실제 메시지를 받아봅니다.
소스맵을 배포 파이프라인에 연결하고, 운영 코드에서 원본 위치가 보이는지 확인합니다.
테스트 에러를 발생시킨 뒤 알림부터 원인 확인까지 직접 연습합니다.

에러 모니터링은 장애를 없애는 장치가 아니라, 장애를 발견하고 판단하는 시간을 줄이는 장치입니다. Sentry든 GlitchTip이든 중요한 것은 도구 이름보다 ‘문제가 생기면 어디서 알림을 받고, 어떤 맥락으로, 얼마나 빨리 고칠 것인가’를 미리 정해두는 일입니다.