서버는 보통 한 번에 다 망가지지 않습니다. 실제로는 사소하고 무시해도 될 것 같은 문제들이 천천히 쌓이다가, 가장 안 좋은 타이밍에 한꺼번에 터지는 장애가 됩니다. 아무도 지켜보지 않는다면 보통 이런 순서로 진행됩니다.
1~4주차: 겉으로는 아무 일도 없다
모든 게 잘 돌아갑니다. 모니터링이 없는 인프라가 문제가 터지기 전까지는 "안전해 보이는" 이유가 바로 이겁니다 — 조기 경보가 없으니까요.
2~3개월차: 작은 비효율들이 쌓이기 시작한다
로그가 디스크 공간을 채웁니다. 알려진 취약점이 있는 의존성이 패치되지 않은 채 방치됩니다. 데이터가 적을 때는 문제없던 데이터베이스 쿼리가 테이블이 커지면서 점점 느려집니다. 아직 긴급 상황은 아니지만, 다음 장애의 연료가 쌓이는 중입니다.
4~6개월차: 첫 번째 실제 증상이 나타난다
보통 애매한 형태로 나타납니다 — 사이트가 "그냥 좀 느려졌다"거나, 백그라운드 작업이 조용히 멈췄거나, 결국 디스크 공간이 다 차서 새벽 2시에 뭔가가 죽습니다. 모니터링이 없으면 첫 번째 문제 신호가 곧 장애 그 자체인 경우가 많습니다.
장애 발생
어느 시점에 쌓여있던 작은 문제들이 한꺼번에 겹칩니다 — 트래픽 급증 중 메모리 부족 오류, 자동 갱신이 안 돼서 만료된 인증서, 정작 복구가 필요할 때 알고 보니 몇 달째 조용히 실패하고 있던 백업. 이 지점에서 사후 대응만 하는 방식은 비용이 커집니다 — 긴급 대응 요금, 업무 중단, 그리고 몇 달간 아무도 들여다보지 않은 시스템을 급하게 파악해야 하는 혼란까지요.
모니터링이 실제로 막아주는 것
거창한 게 필요하지 않습니다. 기본적인 모니터링(가동 상태, 디스크, 메모리, 인증서 만료), 정기 패치, 실제로 테스트된 백업만으로도 대부분의 문제를 아직 저렴하게 고칠 수 있을 때 잡아냅니다 — 몇 시간짜리 장애 대신 5분짜리 알림 대응으로요.
서버, 데이터베이스, API를 한동안 아무도 들여다보지 않았다면, 장애로 번지기 전에 함께 살펴봐요.