서버가 멈추기 전에 알 수 있을까? 소규모 서비스 모니터링 구성
모든 장애를 미리 예측할 수는 없다. 대신 사용자가 먼저 알려 주기 전에 이상을 발견하고, 원인을 좁힐 자료를 남기고, 같은 장애가 반복되지 않게 만들 수는 있다. 소규모 서비스의 모니터링은 비싼 도구보다 적은 수의 정확한 신호에서 시작하는 편이 낫다.
네 층으로 나눠 본다
1. 외부 가용성
인터넷 밖의 감시 지점에서 로그인 페이지와 핵심 API를 호출한다. 서버 내부의 프로세스가 살아 있다는 신호만으로는 DNS, 인증서, 방화벽, 프록시 장애를 발견하지 못한다.
Uptime Kuma는 HTTP, TCP, WebSocket, DNS, Ping과 인증서 만료 등을 확인하고 여러 알림 채널로 통지할 수 있는 자체 호스팅 도구다. 작은 VPS가 이미 있다면 시작 비용을 낮추기 좋다. 다만 감시 대상과 같은 서버에만 설치하면 서버가 함께 멈출 때 알림도 사라진다. Uptime Kuma 공식 저장소
2. 애플리케이션 오류
오류 개수만 세지 말고 배포 버전, 사용자 요청, 추적 ID, 호출 경로를 연결한다. 같은 오류가 천 번 나면 천 건의 알림을 보내는 대신 하나의 사건으로 묶고 영향을 받은 사용자 수를 본다. 개인정보, 토큰, 요청 본문 전체를 무분별하게 수집하지 않는 것도 중요하다.
3. 자원과 데이터베이스
CPU, 메모리, 디스크 사용률뿐 아니라 증가 속도를 본다. DB는 연결 수, 느린 쿼리, 잠금, 복제 지연을 확인한다. Vercel Observability는 모든 플랜에서 프로젝트의 트래픽과 성능을 볼 수 있고, 더 긴 보존과 추가 기능은 플랜에 따라 달라진다. Vercel Observability
4. 업무 지표
가장 중요한 신호는 기술 지표가 아닐 때가 많다. 결재 요청이 평소보다 급감했는지, 대기 작업의 가장 오래된 항목이 몇 분째인지, 메일 발송 실패가 쌓이는지 확인한다. 서버가 정상이어도 업무 흐름이 멈춘 상태를 잡아낼 수 있다.
처음 설정할 알림
| 알림 | 의미 | 첫 대응 |
|---|---|---|
| 핵심 URL 연속 실패 | 사용자가 접근하지 못할 가능성 | 외부에서 재확인, 최근 배포 확인 |
| 오류율 급증 | 새 코드나 외부 연동 문제 가능성 | 배포 버전과 오류 묶음 확인 |
| 디스크 부족 예상 | 로그, DB, 이미지가 디스크를 채우는 중 | 증가 원인 확인, 안전하게 정리 |
| DB 연결 포화 | 요청 지연과 실패 가능성 | 연결 누수, 풀 설정, 느린 쿼리 확인 |
| 큐의 오래된 작업 증가 | 워커 중단 또는 처리 병목 | 워커 상태, 실패 사유, 재시도 확인 |
| 백업 미실행 | 복구 가능한 시점이 멀어짐 | 백업 작업과 저장 위치 확인 |
| 인증서 만료 임박 | HTTPS 접속 장애 가능성 | 자동 갱신과 DNS 확인 |
한 번의 실패로 야간 알림을 보내면 일시적인 네트워크 흔들림에도 사람이 깨게 된다. 연속 실패 횟수와 일정 시간을 조합하고, 경고와 긴급 알림을 나눈다. 반대로 결재나 결제처럼 한 번의 실패도 중요한 업무는 별도 기준을 둔다.
20명에서 100명까지의 구성
20명
외부 URL 확인, 오류 추적, 플랫폼 기본 지표, 백업 실패 알림이면 충분한 경우가 많다. 알림은 운영 담당자와 한 명의 대체 담당자에게 보낸다.
50명
큐, DB 연결, 주요 업무 성공률을 추가한다. 배포 버전을 오류와 연결하고, 반복 장애에 대한 짧은 대응 절차를 만든다.
100명
서비스별 책임자, 심각도, 공지 채널을 정한다. 운영 대시보드를 만들고 월별로 오류 예산과 복구 시간을 검토한다. 외부 감시와 로그 저장소가 운영 서버와 같은 장애 영역에 있지 않은지도 확인한다.
알림에는 행동이 붙어야 한다
좋은 알림은 무엇이 이상한지, 어느 서비스인지, 언제 시작됐는지, 어디를 확인할지를 담는다. 각 긴급 알림에 한 페이지 분량의 실행 문서를 연결한다. 최근 배포 취소, 워커 재시작, 읽기 전용 전환처럼 안전한 첫 행동을 명시하면 담당자가 바뀌어도 대응 속도를 유지할 수 있다.
모니터링의 목표는 그래프를 많이 만드는 것이 아니다. 사용자 영향이 있는 문제를 빨리 찾고, 원인을 확인할 증거를 남기며, 복구 행동까지 이어 주는 것이다. 처음에는 다섯 개 안팎의 중요한 알림으로 시작하고, 실제 장애에서 쓸모가 없었던 알림은 지우는 편이 건강하다.
함께 읽기
- 사내 시스템 공개 전 확인해야 할 운영 체크리스트 30가지사내 시스템은 외부 고객 서비스보다 사용자가 적다는 이유로 공개 전 점검이 짧아지기 쉽다. 하지만 결재, 계약, 인사, 회계처럼 업무의 기준이 되는 시스템은 한 번의 권한 오류나 데이터 손실도 실제 업무 중단으로 이어진다.
- 듀오랩스가 사내 시스템을 설계하고 운영하는 7가지 원칙사내 시스템의 좋은 아키텍처는 가장 큰 서버나 가장 복잡한 기술 조합이 아니다. 현재 업무를 무리 없이 지원하고, 문제가 생겼을 때 되돌릴 수 있으며, 사용자가 늘면 필요한 부분만 확장할 수 있는 구조다.
- 월 10달러 VPS가 정말 더 저렴할까? 숨은 운영 비용 계산하기월 10달러 안팎의 VPS를 보면 Vercel, Supabase 같은 관리형 서비스를 합친 것보다 훨씬 저렴해 보인다. 실제로 안정적인 부하가 있고 서버를 운영할 사람이 있다면 VPS가 경제적일 수 있다. 하지만 인스턴스 가격만 비교하면 백업, 저장 공간, 전송량, 보안 패치, 장애 대응 시간이 빠진다.
- 클라우드 비용 폭탄을 막는 예산과 사용량 알림 설정클라우드 비용은 서버 한 대의 월정액처럼 움직이지 않는다. 트래픽, 함수 실행 시간, DB 용량, 로그, 파일 전송, 실시간 연결이 각각 늘어난다. 작은 코드 실수나 공개된 API 키 하나가 짧은 시간에 사용량을 키울 수도 있다.
- 배포가 실패해도 5분 안에 되돌리는 소규모 서비스 운영법빠른 롤백은 사람이 명령어를 빨리 입력하는 능력이 아니다. 이전 버전이 무엇인지 알고, 같은 산출물을 다시 실행할 수 있고, DB가 이전 코드와 호환되도록 미리 설계한 결과다. 준비 없이 배포한 뒤 5분 안에 되돌리겠다는 목표는 지키기 어렵다.