우리는 Uptime Metrics를 신뢰하지 않게 되었습니다. 대신 우리가 모니터링하는 것은 이것입니다.
Source: Dev.to
위 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다.
실제 가동 시간 모니터링이 하는 일
전형적인 가동‑시간 모니터링 도구가 무엇을 확인하는지 구체적으로 살펴보겠습니다. 여기에는 애매함이 없습니다 – UptimeRobot, Pingdom, Better Stack 등 대부분의 도구가 따르는 표준 모델입니다:
- 당신의 URL에 HTTP 요청을 보냅니다.
- 응답을 받습니다.
- 상태 코드를 확인합니다.
200 OK이면 → 정상으로 표시합니다.5xx이거나 타임아웃이면 → 다운으로 표시합니다.
- 가동 시간 비율을 보고합니다.
그게 전부입니다. 바로 그 검증이죠.
서버가 살아 있고 요청에 응답하는지를 알려줍니다. 이 부분은 잘 수행하고, 한때는 이것만으로 충분했습니다—서버가 켜져 있으면 사이트가 작동한다는 전제였으니까.
하지만 이제는 더 이상 그렇지 않습니다.
가동 시간 모니터링이 확인하지 못하는 항목
표준 가동 시간 검사가 놓치는 항목들의 비포괄적 목록은 다음과 같습니다:
| Issue | Why it’s missed |
|---|---|
| 자산 무결성 | HTML은 로드되지만, 참조된 JavaScript 번들이 404를 반환합니다. CDN이 삭제된 파일을 가리키는 오래된 HTML을 계속 제공하기 때문입니다. 페이지는 빈 흰 화면으로 표시됩니다. 문서의 상태 코드: 200. |
| MIME 타입 | 서버가 Content‑Type: text/html 헤더와 함께 JS 파일을 반환합니다. 브라우저는 파일을 다운로드하고 헤더를 읽은 뒤, 조용히 실행을 거부합니다. SPA가 전혀 부팅되지 않습니다. 상태: 200. |
| 리다이렉트 체인 | 사이트가 /page → /page/ → /page → /page/ 로 리다이렉트됩니다. 브라우저는 20번의 홉 이후에 포기합니다. 가동 시간 도구는 첫 번째 리다이렉트만 따라가 200을 받고 종료합니다. |
| 콘텐츠 정확성 | 누군가가 새벽 2시에 CMS에서 홈페이지를 변경했거나, CDN이 마이그레이션 후 잘못된 오리진에서 콘텐츠를 제공하기 시작했습니다. 페이지는 로드되지만, 잘못된 페이지가 표시됩니다. 상태: 200. |
| 서드‑파티 의존성 | Stripe의 JS가 로드되지 않아 결제 화면이 빈 <div>로 표시됩니다. 인증 제공자가 다운돼 사용자가 로그인할 수 없습니다. 페이지 자체는 정상적으로 로드되었으며, 깨진 리소스는 다른 도메인에 있습니다. |
| 지역별 차이 | 사이트는 US‑East에서는 정상 작동하지만, 프랑크푸르트에서는 CDN 엣지가 세 번 전 배포된 오래된 캐시 자산을 제공하고 있습니다. 단일 지역 가동 시간 검사는 이를 전혀 감지하지 못합니다. |
이 모든 경우가 200 OK를 반환합니다. 표준 가동 시간 검사를 모두 통과합니다. 그러나 사용자 입장에서는 모두 정상 작동하지 않는 것입니다.
웹사이트 모니터링이 대신 확인하는 것
웹사이트 모니터링은 가동 시간 모니터링이 끝나는 지점에서 시작합니다. “서버가 응답했는가?”를 묻는 대신 “응답이 정상적인 페이지를 구성했는가?”를 묻습니다. 이는 다음을 의미합니다:
- HTML 문서를 목적지가 아닌 매니페스트로 취급하기. 문서는 1단계입니다. 웹사이트 모니터링은 이어서 해당 문서가 참조하는 JS와 CSS 번들이 실제로 로드되는지 확인합니다. 올바른 MIME 타입을 반환하고 있나요? 유효한 상태 코드를 반환하고 있나요?
- 리다이렉트 체인을 끝까지 따라가기. 첫 번째 홉만 확인하는 것이 아니라 전체 체인을 확인합니다. 해결되나요? 루프가 있나요? 예상치 못한 곳에서 끝나나요?
- 시간에 따른 콘텐츠 지문 생성. 배포 없이 응답 본문이 변경되면 이를 알아야 합니다. SHA‑256 해시를 이용한 콘텐츠 지문은 무음 CMS 편집, CDN 원본 변동, 캐시 중독을 포착합니다.
- 다중 지역에서 검사하기. CDN 장애는 지역적 특성을 가집니다. 한 위치에서는 정상인데 다른 위치에서는 문제가 될 수 있습니다. 웹사이트 모니터링은 전체 검사 스위트를 여러 지리적 위치에서 독립적으로 실행합니다.
- 근본 원인 분류하기. “무언가 잘못됐다”는 것뿐 아니라 “왜”인지를 파악합니다. 배포 아티팩트인가요? CDN 캐시 문제인가요? DNS 변동인가요? 애플리케이션 오류인가요? 근본 원인 분류는 알림을 실행 가능한 정보로 전환합니다.
실용적인 비교
다음은 두 관점에서 본 동일한 시나리오입니다:
시나리오: Nuxt 3 앱을 Vercel에 배포합니다. 빌드는 성공했지만, 유럽에 있는 CDN 엣지 노드가 여전히 이전 HTML을 제공하고, 그 HTML은 app.7fb2e.js를 참조합니다. 해당 파일은 새로운 빌드에서 삭제되었습니다.
| Aspect | Uptime monitoring | Website monitoring |
|---|---|---|
| HTTP status | 200 OK ✅ | 200 OK (document) |
| Asset check | Not checked | app.7fb2e.js → 404 ❌ |
| MIME validation | Not checked | N/A (asset missing) |
| Multi‑region | Single region ✅ | EU: broken ❌, US: ok ✅ |
| Alert | None | Incident: deployment artifact missing, EU region |
| Root cause | N/A | CDN cache stale, Vercel ISR |
| User impact | Unknown | European users see blank page |
같은 사이트. 같은 순간. 완전히 다른 그림.
They’re complementary, not competing
우리는 명확히 하고 싶습니다: 가동 시간 모니터링이 쓸모없다고 말하는 것이 아닙니다. 그렇지 않습니다. 서버가 다운됐을 때를 반드시 알아야 합니다. 503이나 타임아웃은 실제 장애이며 즉시 인지해야 합니다.
문제는 가동 시간 모니터링을 충분하다고 여기는 데 있습니다. 이는 한 종류의 실패만을 포착하는 한 층에 불과합니다. 놓치는 실패—즉 “200 OK이지만 깨진” 실패—가 실제로 사용자에게 피해를 주는 경우가 점점 늘고 있습니다.
현대적인 웹 애플리케이션 모니터링 스택은 두 가지를 모두 갖추어야 합니다:
- Uptime monitoring → 서버가 살아 있나요? 응답하고 있나요? 인프라가 정상 가동 중인가요?
- Website monitoring → 사이트가 제대로 동작하나요? 자산이 로드되나요? 콘텐츠가 올바른가요? 모든 환경에서 작동하나요?
첫 번째만 가지고 있다면 사각지대가 생깁니다. 바로 그 사각지대에서 대시보드는 “99.9 % uptime”이라고 표시하지만, 사용자는 빈 페이지를 마주하게 됩니다.
이것이 우리가 Sitewatch를 만든 이유
Sitewatch 은 웹사이트 모니터링이며, 가동 시간 모니터링이 아닙니다. 이 구분은 우리에게 중요합니다. 왜냐하면 제품이 존재하는 전체 이유이기 때문입니다.
우리는 다음을 확인합니다:
- 자산 무결성
- MIME 타입
- 리다이렉트 체인
- 콘텐츠 지문
- 다중 지역 일관성
무언가가 깨지면, 우리는 근본 원인을 인프라스트럭처, 애플리케이션, 또는 콘텐츠 전달로 분류하고 해결 방안을 제공합니다.
SiteWatch – 무료 가동 시간 및 웹사이트 모니터링
모든 체크는 2‑of‑3 재시도 확인 모델을 사용하여 일시적인 CDN 문제로 새벽 3시에 알림이 울리지 않도록 합니다. 중복 알림은 SHA‑256 지문과 30분 쿨다운을 통해 중복 제거됩니다.
- 무료 티어 1개 사이트에 제공
- 신용카드 필요 없음
- 설정 시간 30초: getsitewatch.com
가동 시간 모니터링은 서버가 살아 있는지를 알려줍니다. 웹사이트 모니터링은 사이트가 정상 작동하는지를 알려줍니다. 두 질문은 동일하지 않으며, 하나에 대한 답이 다른 하나에 대한 답을 의미하지 않습니다.