장애 알림을 위해 공급업체 상태 페이지를 모니터링하는 방법

2025년 10월 19일 태평양 표준시 자정 직전, Amazon DynamoDB의 DNS 자동화 시스템에서 발생한 경쟁 상태(race condition)로 인해 us-east-1 리전의 엔드포인트에 빈 DNS 레코드가 남겨지는 사고가 발생했습니다. 해당 리전에서 DynamoDB에 의존하던 모든 서비스가 실패하기 시작했고, 피해는 이에 의존하는 다른 AWS 서비스로 확산되었습니다. AWS의 공식 요약 보고서에 따르면 이 장애는 약 14시간 30분 동안 지속되었습니다.

그날 아침, 수많은 개발팀의 자체 서버는 완벽하게 정상 작동하고 있었습니다. 외부 로그인 공급자, 결제 처리기 또는 이메일 서비스가 마비되는 동안에도 내부 업타임 모니터는 계속 녹색 불을 켜고 있었습니다. 물론 대부분의 장애는 이보다 규모가 작습니다. 이메일 벤더의 발송이 40분 지연되고, 지원팀에는 "비밀번호 재설정 링크가 오지 않는다"는 티켓이 쏟아지며, 마침내 누군가 벤더의 상태 페이지를 찾아냈을 때 이미 30분 전부터 "성능 저하(Degraded performance)"가 떠 있었던 식입니다.

저는 공개 웹페이지를 감시하고 중요한 변경 사항이 발생했을 때 알려주는 도구인 Page Deltas에서 일하고 있으므로, 아래에서 다른 도구들과 비교할 때 이 점을 감안해 주시기 바랍니다. 이 글에서는 의존하는 공급업체의 상태 페이지로 도구를 지정하는 방법을 안내합니다. 어떤 URL을 선택해야 하는지, 노이즈를 제거하는 브리프(지침)를 작성하는 방법, 알림을 전달할 채널, 그리고 이 방식이 한계를 갖는 지점을 살펴봅니다.

자체 모니터링이 계속 녹색으로 유지되는 이유

자체 업타임 모니터는 내 웹사이트가 응답하는지만 확인하며, 외부 공급업체가 장애를 겪는 동안에도 내 사이트는 대개 정상적으로 응답합니다. APM 도구는 공급업체 호출 시 에러 급증을 감지하지만, 문제가 내 코드 때문인지 그들의 서비스 때문인지는 알려주지 못합니다. 이것이 바로 상태 페이지가 답해 주는 질문이며, 그 답에 따라 후속 조치가 완전히 달라집니다. 한 시간 전에 배포한 코드를 황급히 롤백하지 않고, 지원팀에 알려진 외부 이슈임을 공유하며, 자체 상태 페이지 업데이트를 검토할 수 있습니다.

그렇다면 공급업체 상태 페이지에서 직접 구독하지 않는 이유는 무엇일까요? 충분히 커버된다면 당연히 그렇게 해야 합니다. 많은 상태 페이지가 Atlassian Statuspage 기반으로 운영되며, 공급업체가 활성화한 옵션에 따라 이메일, SMS, Slack, Teams 또는 웹훅 구독을 제공합니다. 문제는 여덟 번째 공급업체에 도달했을 때 발생합니다. 각 구독은 개별적으로 설정해야 하므로 특정 담당자의 받은편지함에 묻히기 십상이고, 공급업체마다 메시지 형식이 다르며, 실제 사용하는 구성 요소만 골라 필터링하는 기능을 제공하지 않는 경우도 많습니다. 심지어 자체 구축 페이지라 구독 버튼조차 없는 공급업체도 있습니다.

웹 변경 모니터를 사용하면 모든 공급업체에 대해 단일 워크플로를 구축할 수 있습니다. 상태 페이지 URL을 붙여넣고 원하는 내용을 한 문장으로 설명하기만 하면, 모든 알림이 일관된 형식으로 동일한 채널에 도착합니다.

어떤 페이지를 모니터링해야 할까요?

현재 가동 상태를 보여주는 페이지를 선택하세요. 보통 status.vendor.com 형식입니다. 공급업체의 메인 홈페이지나 마케팅용 신뢰성(Trust) 페이지는 피하세요. 대부분의 SaaS 상태 페이지는 유사한 구조를 가집니다: 구성 요소 목록과 상태 표시, 진행 중인 장애 배너, 예정된 정기 유지보수, 전체 이력 링크가 포함된 최근 인시던트 목록입니다.

장애 발생 시 고객이 가장 먼저 체감할 핵심 종속성부터 시작하세요. 대부분의 소프트웨어 팀에게 이는 비교적 명확하고 짧은 목록입니다.

모니터링할 수 있는 개수가 제한적이라면 맨 위 항목부터 시작하세요. 결제 및 로그인 장애는 몇 분 만에 고객 지원 문의로 폭주하지만, 느려진 CDN은 초기에는 내부 메트릭 지표에만 나타날 수 있습니다. 무료 플랜의 10개 URL 한도면 이 5개 항목을 모두 커버하고도 아래에서 다룰 추가 페이지들을 등록할 여유가 충분합니다.

추가로 알아두면 유용한 페이지가 두 가지 더 있습니다. 첫째는 이력 페이지(주로 /history)로, 깊이 의존하는 핵심 공급업체의 두 번째 모니터로 적합합니다. 짧은 인시던트는 메인 페이지의 점검 주기 사이에 발생했다가 해결될 수 있지만, 이력에는 기록으로 남으므로 뒤늦게라도 정확한 상황을 파악할 수 있습니다. 둘째는 장기화되는 중대 장애 시 해당 인시던트의 전용 상세 페이지를 임시 모니터로 등록하여 매 업데이트를 실시간 추적하는 것입니다. 인시던트가 해결되면 모니터를 삭제하세요. 모든 모니터가 URL 한도에 포함되기 때문입니다.

모니터링 설정 방법

설정에는 약 5분이 소요되며, 모니터링 지침(브리프) 내용만 다를 뿐 당사의 변경 로그 모니터링 가이드와 동일한 절차로 진행됩니다.

1. 계정 생성 및 채널 연동

무료 계정에 가입하고 "Channels"를 열어 알림을 수신할 대상을 추가합니다. #engineering 처럼 메시지가 많은 채널에 게시하면 묻히기 쉬우므로 #vendor-status 와 같은 전용 채널을 생성하는 것을 권장합니다. Slack, Discord, Microsoft Teams는 수신 웹훅(Incoming Webhook) URL을 입력받습니다. Teams에서는 채널을 마우스 우클릭한 후 "커넥터" → "Incoming Webhook" → "구성"을 선택하고 발급된 URL을 Page Deltas에 붙여넣습니다. 이메일 채널은 수신자가 확인 메일을 먼저 승인해야 합니다. 각 채널에서 "Send test"를 클릭하여 테스트 메시지가 정상 수신되는지 확인하세요.

2. 브리프(지침)를 작성하여 모니터 추가

"New monitor"를 클릭하고 상태 페이지 URL을 붙여넣습니다. 공급업체별로 하나의 모니터를 유지하여 브리프에 해당 공급업체의 구성 요소 이름을 정확히 기재할 수 있도록 하고, 팀마다 담당하는 공급업체가 다르다면 모니터별로 서로 다른 알림 채널을 지정하세요.

상태 페이지는 장애가 없는 평온한 날에도 생각보다 자주 변경됩니다. 가동률 백분율이 미세하게 바뀌고, "최종 업데이트" 타임스탬프가 갱신되며, 최근 인시던트 목록에는 매일 "보고된 인시던트 없음"이라는 새로운 행이 롤오버됩니다. 정기 점검 공지는 몇 주 전부터 미리 게시됩니다. 단순한 텍스트나 DOM 차이점 비교 도구는 이런 무의미한 변화마다 매번 알림을 울립니다.

모니터의 "Description(설명)"은 변경 사항의 중요도를 LLM이 판단할 때 참조하는 프롬프트 역할을 합니다. 나 대신 페이지를 지켜보고 있는 동료에게 남기는 메모처럼 작성하세요. 이메일 서비스 공급업체의 경우 다음과 같이 작성할 수 있습니다:

이메일 공급업체의 상태 페이지입니다. 당사는 미국(US) 리전의 Email API 및 Webhooks 구성 요소만 사용합니다.
해당 구성 요소나 리전에 영향을 주는 새로운 인시던트가 등록되거나, 상태 및 심각도가 변경되거나, 장애가 해결되었을 때 알림을 보내주세요. 두 구성 요소 중 하나라도 Operational(정상)에서 변경되면 알려주세요.
가동률 백분율, "최종 업데이트" 타임스탬프, 매일 갱신되는 "보고된 인시던트 없음" 행, 다른 리전의 인시던트는 무시하세요.
정기 유지보수는 48시간 이내에 시작되는 경우에만 알려주세요.
영향을 받는 구성 요소, 현재 상태, 최신 업데이트 내용을 간결히 요약해 주세요.

이 "무시하세요(Ignore)" 지침이 핵심적인 필터링 역할을 수행합니다. 이를 생략하면 첫 주 내내 자정마다 인시던트 목록이 갱신될 때마다 불필요한 알림을 받게 됩니다.

대형 클라우드 제공업체의 경우 리전 및 서비스 이름을 구체화하는 것이 더욱 중요합니다. 퍼블릭 클라우드 대시보드는 수십 개 리전에 걸친 수백 개의 서비스를 다루며, 평상시에도 어딘가의 서비스는 경미한 장애를 겪고 있습니다. 자사가 실제로 사용 중인 리전과 서비스명을 명시하고, 그에 관한 내용만 알림을 받도록 요청하세요.

3. 첫 번째 점검으로 기준선(Baseline) 설정

모니터를 생성하면 곧바로 첫 번째 점검이 실행됩니다. 이 점검을 통해 초기 기준 상태가 저장되므로, 점검 주기 사이에 페이지가 변하지 않는 한 생성 첫 1분 동안 허위 알림이 발생하지 않습니다. 첫 점검 완료 후 모니터를 열고 스크린샷을 확인하여 예상한 구성 요소 목록이 올바르게 캡처되었는지 확인하세요.

4. 이상 징후 발생 시 "Check now" 실행

Page Deltas에서는 점검 간격을 수동으로 지정할 필요가 없습니다. 스케줄은 적응형(Adaptive)으로 작동하여 자주 바뀌는 페이지는 더 자주 점검되며, 유료 플랜은 큐가 붐빌 때 우선순위를 갖습니다. 상태 페이지는 평소에는 매우 조용하므로, 사내 에러율이 치솟고 공급업체 장애가 의심될 때는 모니터 화면에서 "Check now"를 클릭하세요. 동일한 작업은 API를 통해서도 실행 가능하며, 모니터당 분당 1회로 제한됩니다:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

알림을 수신했을 때의 대응 방법

브리프 조건에 부합하는 변경이 감지되면 읽기 쉬운 요약과 함께 변경 전후의 비교 스크린샷이 담긴 알림 메시지가 발송됩니다. 서명된 웹훅을 사용하는 경우 페이로드는 다음과 같습니다(예시를 위한 가상 데이터입니다):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "이메일 공급업체 상태",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "새 인시던트: 미국 리전 이메일 발송 지연. Email API가 Operational에서 Degraded Performance로 변경됨. 상태: 조사 중.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

알림을 가장 먼저 확인한 사람은 해당 장애가 자사에 미치는 영향을 스레드에 답글로 남겨 즉시 공유해야 합니다. 고객 지원팀은 문의가 쏟아지기 전에 외부 알려진 이슈에 대한 공지를 고정할 수 있습니다. 당직 엔지니어는 장애의 원인이 아닌 무고한 최신 배포를 헛되이 파헤치는 낭비를 피할 수 있으며, 고객에게 직접적인 영향을 미치는 장애라면 자사의 상태 페이지를 선제적으로 업데이트하여 고객이 다른 곳에서 불만을 제기하기 전에 먼저 안내할 수 있습니다.

팀이 PagerDuty 등 전문 인시던트 관리 도구를 기반으로 운영된다면, 서명된 웹훅을 경량 릴레이 서버를 통해 연동할 수 있습니다. 당사의 페이로드는 PagerDuty 표준 형식이 아니므로, 서명을 검증하고 이벤트를 전달하는 몇 줄의 서버리스 함수 코드가 필요합니다:

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

JSON 파싱을 수행하기 전에 원본 바디(rawBody)를 해시해야 서명이 일치합니다. 자세한 내용은 알림 채널 문서를 참조하세요. 각 알림은 채널당 1회씩 발송되며 자동 재시도는 지원되지 않으므로, 절대 놓쳐선 안 되는 핵심 공급업체의 경우 릴레이나 Slack 자체의 장애에 대비해 다른 유형의 보조 채널(Slack + 이메일 조합 등)을 함께 등록해 두는 것이 좋습니다.

이 접근 방식의 한계점

이 설정은 공급업체가 "공개적으로 알린 내용"을 전달하는 구조이며, 실무에 적용하기 전에 몇 가지 한계를 명확히 이해해야 합니다.

첫째, 공급업체의 공식 공지는 지연되는 경우가 빈번합니다. 상태 페이지에 장애가 인정되기 전에 사내 에러 모니터링 그래프가 먼저 이상을 감지하기도 하므로, 상태 페이지 알림은 최초 경보라기보다는 공식적인 원인 확인 용도로 취급해야 합니다. 또한 자체 API에 대한 신세틱 점검(Synthetic Check)이나 업타임 모니터링을 대체할 수 없습니다. 후자는 내 제품이 고장 났다는 사실을 알려주고, 상태 페이지는 그 이유를 설명해 줍니다.

둘째, 점검 주기 사이에 일어난 변화는 다음 예정된 점검 시점에 감지되므로 고정된 초 단위의 즉시성을 보장하지는 않습니다. 몇 분 차이가 매우 중요한 극소수의 핵심 공급업체는 공급업체 자체의 알림 구독도 유지하고, 나머지 대다수 공급업체 관리에 Page Deltas를 활용하는 것이 현명합니다. 또한 공개 웹페이지만 모니터링하므로 공급업체의 관리자 콘솔 내부에 로그인해야만 보이는 비공개 상태는 감지할 수 없습니다.

셋째, 당사는 페이지의 텍스트 변경을 비교합니다. 텍스트 변경 없이 색상이 변하는 신호등이나 점(dot) 그래픽만으로 상태를 나타내는 공급업체의 경우 감지할 수 없습니다. 화면의 픽셀 영역을 시각적으로 비교해야 한다면 Visualping 같은 도구가 더 적합합니다. 마지막으로 상태 페이지 자체가 다운되면 알림 대신 점검 실패로 처리되며, 10회 연속 점검에 실패하면 모니터가 자동으로 일시 정지되고 관리자에게 안내 메일이 발송됩니다.

핵심 3개 공급업체부터 시작하세요

장애 발생 시 비즈니스에 가장 큰 타격을 줄 상위 3개 공급업체(대개 결제, 인증, 이메일)를 선택해 보세요. 각 상태 페이지 URL을 등록하고, 위에 제공된 템플릿을 참고하여 실제 사용하는 구성 요소와 리전에 맞게 브리프를 조정한 뒤 #vendor-status 채널로 테스트 알림을 발송해 보세요. 무료 플랜은 신용카드 등록 없이도 10개 URL, AI 필터링, 전체 알림 채널 및 API 연동을 모두 지원합니다. 무료로 모니터링 시작하기.

Julien, Page Deltas 프로덕트 매니저