웹사이트는 만든 다음 날부터 조용히 무너지기 시작한다. 새벽에 서버가 재시작되거나, SSL 인증서가 만료되거나, 어느 페이지가 500 에러를 뱉고 있어도 사장님은 출근 후 고객의 항의 전화로 그 사실을 알게 된다. 백업이 사고 후의 안전망이라면, 모니터링은 사고가 매출 손실로 번지기 전에 손을 쓰는 첫 번째 방어선이다.
1. 외부에서 본 우리 사이트를 30초마다 확인한다
사장님 컴퓨터에서 잘 열린다고 안심하면 안 된다. 해외 데이터센터에서 우리 사이트의 메인 URL과 결제 페이지에 주기적으로 접속해 보는 외부 헬스 체크가 필요하다. UptimeRobot, BetterStack, Pingdom 같은 서비스를 쓰면 30초 간격으로 사이트 상태를 점검할 수 있다.
중요한 건 모니터링 대상을 메인 페이지 한 곳에만 두지 않는 것이다. 메인, 결제, 로그인, 핵심 API 응답까지 매출에 직결되는 경로 서너 개를 따로 등록한다. 메인은 정상인데 결제만 죽어 있는 사고는 의외로 자주 일어난다.
2. 응답 속도가 평소보다 느려지는 순간을 포착한다
사이트가 완전히 죽어야만 사고가 아니다. 평소 0.4초에 응답하던 페이지가 갑자기 3초가 걸리고 있다면 이미 고객은 이탈하고 있다. '살아 있는가'가 아니라 '평소처럼 빠른가'를 기준으로 임계치를 잡아야 한다.
응답 속도 알림은 절댓값보다 추세로 보는 편이 현실적이다. 지난 24시간 평균 대비 두 배 이상 느려지면 알림을 보내는 식이다. CDN 장애, DB 쿼리 폭주, 외부 API 지연처럼 '죽지는 않은 사고'를 이 임계치가 잡아낸다.
3. 에러 로그는 쌓이는 게 아니라 알림으로 와야 한다
서버에 SSH로 들어가서 로그 파일을 들여다볼 시간이 사장님에겐 없다. 500 에러가 한 시간에 몇 번 이상 발생하면 자동으로 알림이 오는 구조가 필요하다. Sentry, Bugsnag 같은 전용 도구도 좋고, 로그 수집과 슬랙 웹훅을 묶어 직접 만들어도 충분하다.
특히 결제 실패, 로그인 실패율 급증, 폼 제출 에러처럼 매출에 직접 연결되는 이벤트는 일반 500 에러와 다른 채널로 분리한다. 이 알림이 울리는 동안에도 매출이 빠져나가고 있기 때문이다.
4. SSL 인증서와 도메인 만료는 두 번 알린다
SSL 인증서가 만료되면 브라우저는 빨간 경고창을 띄우고, 그 순간부터 신규 고객은 사이트에 들어오지 않는다. 도메인 만료는 더 치명적이다. 인증서와 도메인 만료는 30일 전, 7일 전 두 번 알림이 와야 한다.
Let's Encrypt 같은 자동 갱신 인증서를 쓰더라도 안심하면 안 된다. 갱신 스크립트가 조용히 실패하는 사고가 잦다. '갱신이 성공했는가' 자체를 모니터링 대상에 포함시켜 두자.
5. 알림이 너무 많으면 결국 아무도 안 본다
모니터링을 처음 도입하면 알림이 쏟아지고, 며칠 뒤에는 알림 채널을 모두가 음소거한다. 알림은 '진짜 사람이 지금 손 써야 하는 사고'에만 와야 한다.
- 치명 — 사이트 다운, 결제 실패 급증. 즉시 전화나 카카오톡으로 알림.
- 주의 — 응답 속도 저하, SSL 만료 임박. 슬랙이나 메일로 알림.
- 참고 — 트래픽 추이, 느린 쿼리 목록. 주간 리포트로 묶어서 발송.
이 세 단계가 섞이면 알림 시스템 전체가 무너진다. 채널을 나누는 일이 모니터링 도구를 도입하는 일보다 먼저다.
모니터링은 시스템이 아니라 운영의 습관이다
장비를 깔아도 임계치를 손보지 않으면 알림은 의미가 없고, 알림이 와도 응답 절차가 없으면 그저 기록일 뿐이다. CYAN은 사이트를 만들면서 어떤 지표를 어디로 보낼지, 누가 가장 먼저 받을지까지 함께 설계한다. 사장님이 잠든 새벽에도 사이트가 안전하려면, 코드보다 먼저 운영의 그림이 그려져 있어야 한다.