장애는 대개 사용자 메시지로 먼저 옵니다
혼자 웹서비스를 운영하다 보면 이런 순간이 꼭 옵니다. 아침에 메일함을 열었더니 "어제 저녁부터 로그인이 안 돼요"라는 문의가 와 있습니다. 확인해 보면 밤사이 배포 하나가 결제 페이지를 깨뜨렸고, 그동안 들어온 방문자는 조용히 떠났습니다.
팀이 있는 회사라면 당직자가 있겠지만, 1인 메이커는 자는 동안 서비스를 지켜볼 사람이 없습니다. 그래서 필요한 게 모니터링입니다. 거창한 관제 시스템이 아니라, 문제가 생기면 내 휴대폰이 울리게 만드는 최소한의 장치입니다.
이 글에서는 크게 두 가지를 다룹니다. 하나는 에러 추적(코드 안에서 무엇이 터졌는지), 다른 하나는 업타임 모니터링(사이트가 바깥에서 열리긴 하는지)입니다. 둘은 겹치는 것 같지만 잡아내는 문제가 다릅니다.
에러 추적과 업타임 체크는 무엇이 다를까
업타임 모니터링: 문이 열려 있는지
업타임 도구는 정해진 주기마다 바깥에서 내 사이트 주소를 호출해 봅니다. 응답이 없거나 500 같은 오류 코드가 오면 알림을 보냅니다. 도메인 만료, 서버 다운, DNS 설정 실수, SSL 인증서 만료처럼 사이트 전체가 안 열리는 사고를 잡는 데 강합니다.
대신 페이지는 열리는데 버튼 하나가 동작하지 않는 문제는 놓칩니다. 메인 화면은 멀쩡히 200을 돌려주니까요.
에러 추적: 안에서 무엇이 깨졌는지
에러 추적 도구는 앱 코드 안에 작은 SDK를 심어, 예외가 발생할 때마다 스택 트레이스와 브라우저·경로 정보를 모아 줍니다. "결제 완료 페이지에서 특정 브라우저 사용자만 undefined 오류가 난다" 같은 부분 장애를 찾아내는 쪽입니다.
정리하면, 업타임은 "사이트가 살아 있나", 에러 추적은 "살아 있는데 어디가 아픈가"를 봅니다. 혼자라면 둘 다 아주 가볍게라도 켜 두는 게 좋습니다.
도구를 고를 때 볼 기준
- 무료 구간으로 버틸 수 있는지: 트래픽이 적은 초기에는 대부분 무료 플랜으로 충분합니다. 다만 이벤트 수·체크 주기·보관 기간 한도는 서비스마다, 시기마다 달라지니 가입 전에 공식 요금표를 꼭 확인하세요.
- 알림 경로: 이메일만 되는지, 슬랙·디스코드·텔레그램·푸시까지 되는지. 실제로 내가 바로 보는 채널로 와야 의미가 있습니다.
- 내 스택 지원 여부: Next.js, React, Node, Python 등 쓰는 프레임워크용 SDK가 공식으로 있는지 봅니다.
- 개인정보 처리: 에러 로그에 이메일·토큰 같은 값이 섞여 들어가기 쉽습니다. 민감 필드를 걸러내는 설정이 있는지 확인합니다.
- 설정 난이도: 혼자라면 30분 안에 첫 알림을 받아볼 수 있는 쪽이 오래 갑니다.
에러 추적 쪽 대표 선택지
Sentry
에러 추적하면 가장 먼저 거론되는 서비스입니다. 프런트엔드와 백엔드를 함께 볼 수 있고, Next.js용 설정 마법사가 있어 처음 붙이기가 비교적 수월합니다. 같은 오류를 하나로 묶어 보여 주고, 어느 배포 이후에 생겼는지 연결해 볼 수 있어서 "방금 올린 코드가 원인인가"를 빠르게 판단할 수 있습니다.
기능이 많은 만큼 화면이 처음엔 복잡하게 느껴질 수 있습니다. 처음에는 성능 추적이나 세션 리플레이 같은 부가 기능은 끄고, 에러 알림만 켜 두는 것을 권합니다. 이벤트 한도를 아끼는 데도 도움이 됩니다.
오픈소스·셀프호스팅 계열
GlitchTip처럼 Sentry SDK와 호환되는 오픈소스 대안도 있습니다. 데이터를 직접 보관하고 싶거나 이미 운영 중인 서버가 있다면 고려해 볼 만합니다. 다만 서버 업데이트와 백업까지 내 몫이 되므로, 모니터링 도구 자체가 또 하나의 장애 지점이 될 수 있다는 점은 기억해 두세요.
호스팅 플랫폼 기본 로그
Vercel, Netlify 같은 호스팅을 쓰고 있다면 대시보드에서 함수 로그와 오류 응답을 어느 정도 볼 수 있습니다. 별도 도구 없이 시작하기 좋지만, 보관 기간이 짧거나 알림 기능이 제한적인 경우가 많아 "사후 확인용"에 가깝습니다.
업타임 모니터링 쪽 대표 선택지
UptimeRobot
가볍게 시작하기 좋은 업타임 체크 서비스입니다. 주소만 등록하면 주기적으로 접속을 확인하고, 응답이 없으면 메일이나 메신저로 알려 줍니다. 공개 상태 페이지를 만들어 "지금 점검 중입니다"를 사용자에게 보여 줄 수도 있습니다.
Better Stack(구 Better Uptime) 등
업타임 체크에 장애 기록, 상태 페이지, 당직 알림까지 묶어 주는 서비스들도 있습니다. 화면이 깔끔하고 전화·문자 알림 같은 옵션이 있어, 결제가 걸린 서비스라면 눈여겨볼 만합니다.
Uptime Kuma
직접 올려 쓰는 오픈소스 업타임 도구입니다. Docker 하나로 띄울 수 있고, 여러 알림 채널을 지원합니다. 단, 모니터링 서버를 서비스와 같은 서버에 두면 함께 죽어서 아무 알림도 오지 않습니다. 셀프호스팅이라면 반드시 다른 곳에 두세요.
30분 안에 끝내는 최소 설정 순서
- 업타임 체크 하나 등록: 메인 주소와 함께, 가능하다면 로그인이나 결제처럼 중요한 페이지 하나를 추가합니다.
- 헬스 체크 경로 만들기:
/api/health처럼 DB 연결까지 확인하고 200을 돌려주는 가벼운 경로를 하나 두면, "화면은 뜨는데 DB가 죽은" 상황도 잡을 수 있습니다. - 에러 추적 SDK 설치: 프레임워크 가이드대로 설치하고, 일부러 오류를 한 번 던져서 알림이 실제로 오는지 확인합니다. 테스트하지 않은 알림은 없는 것과 같습니다.
- 알림 채널 정리: 휴대폰에서 바로 보는 메신저 하나로 모읍니다. 메일함 구석에 쌓이는 알림은 결국 안 보게 됩니다.
- 민감 정보 거르기: 요청 본문, 쿠키, 인증 헤더가 로그에 그대로 남지 않도록 SDK 옵션을 확인합니다. 개인정보처리방침의 수탁사 목록도 함께 갱신해 두면 좋습니다.
- 도메인·인증서 만료 알림: 의외로 많은 장애가 갱신 누락에서 생깁니다. 업타임 도구가 SSL 만료 알림을 지원하면 켜 두고, 도메인 등록 업체의 자동 갱신도 확인하세요.
알림 피로를 피하는 요령
모니터링을 처음 켜면 알림이 쏟아져서 금방 꺼 버리는 경우가 많습니다. 몇 가지만 지키면 오래 유지할 수 있습니다.
- 봇·크롤러가 만든 오류는 무시 규칙으로: 존재하지 않는 경로를 두드리는 요청 때문에 생긴 404류 오류는 필터로 빼 둡니다.
- 같은 오류는 묶어서: 새로 생긴 오류나 갑자기 늘어난 오류만 알림으로 받도록 설정합니다.
- 연속 실패 기준 두기: 업타임 체크가 한 번 실패했다고 바로 울리게 하지 말고, 두세 번 연속 실패할 때 알리도록 하면 일시적인 네트워크 흔들림에 덜 시달립니다.
- 주간 점검 시간 정하기: 급하지 않은 오류는 일주일에 한 번 몰아서 봅니다. 모든 오류에 즉시 반응할 필요는 없습니다.
정리
혼자 운영하는 웹서비스에서 모니터링은 "있으면 좋은 것"이 아니라, 잠든 사이 떠나는 사용자를 줄이는 가장 값싼 보험입니다. 사이트가 열리는지는 업타임 체크로, 열린 사이트 안에서 무엇이 깨졌는지는 에러 추적으로 봅니다. 처음부터 완벽하게 갖출 필요 없이, 업타임 체크 하나와 에러 알림 하나만 실제로 울리는지 확인해 두는 것만으로도 충분히 시작할 수 있습니다.
서비스 운영에 도움이 되는 다른 도구가 궁금하다면 유틸리티와 비즈니스·생산성 카테고리에서 비슷한 웹서비스를 더 둘러보세요.