예기치 않은 변경 사항에 대비해 자체 웹사이트를 모니터링하는 방법

2022년 9월의 어느 일요일 오후, 누군가가 Fast Company의 콘텐츠 관리 시스템(CMS)에 침입하여 메인 홈페이지의 모든 헤드라인을 음란하고 인종차별적인 메시지로 변조했습니다. 팀은 웹사이트를 즉시 내리고 약 2시간 만에 복구했습니다. 하지만 이틀 후, 동일한 공격자가 Fast Company의 Apple News 팔로워들에게 비슷한 메시지를 푸시 알림으로 전송했고, 결국 사이트는 8일 동안 완전히 오프라인 상태로 닫혀 있어야 했습니다.

이것은 가장 극단적인 사례입니다. 일상에서 일어나는 문제는 훨씬 조용하게 발생합니다. 새로운 배포에서 가격 정책 컴포넌트가 빈 테이블로 렌더링되거나, CMS 편집자가 히어로 섹션에 임시 텍스트(플레이스홀더)가 남겨진 초안을 그대로 게시하기도 합니다. 오타를 수정하다가 실수로 작년의 개인정보 처리방침 버전을 복원해버리기도 합니다. 서버는 정상 작동 중이고 모든 페이지가 문제없이 로드되기 때문에 아무에게도 긴급 호출이 가지 않습니다.

저는 Page Deltas에서 일하고 있습니다. 대부분의 팀은 타사 웹사이트를 추적하기 위해 이 도구를 사용하지만, 이번 글에서는 이를 ‘자체 웹사이트’로 향하게 하는 방법에 대해 다룹니다. 어떤 페이지를 감시해야 하는지, AI 필터가 무엇을 “비정상”으로 인식하도록 브리프(지침)를 작성하는지, 배포 직후 검사를 트리거하는 방법, 그리고 이 도구가 적합하지 않은 영역까지 살펴봅니다.

기존 모니터링 도구가 놓치는 이유

대부분의 웹사이트에는 이미 가동 시간(업타임) 모니터가 설치되어 있습니다. 업타임 모니터는 단 한 가지, “페이지가 응답하는가?”만 묻습니다. 해킹으로 변조된 홈페이지도 완벽하게 200 OK로 응답합니다. 가격 테이블이 깨져버린 페이지도 마찬가지입니다. 업타임 검사는 ‘불이 꺼졌는지’를 확인하는 데는 훌륭하지만, ‘누군가 벽에 페인트칠을 새로 했는지’는 알려주지 못합니다.

서버 측 도구에도 다른 사각지대가 있습니다. 파일 무결성 모니터(FIM)는 로컬 서버 내부의 파일만 감시하므로, 서드파티 스크립트(채팅 위젯, 태그 관리자, 광고 스니펫 등)가 방문자에게 표시되는 화면을 바꿨을 때 이를 감지하지 못합니다. 또한 도메인이 외부 서버로 우회되고 자체 서버는 멀쩡한 DNS 하이재킹도 알아챌 수 없습니다. Visualping의 웹사이트 변조 모니터링 가이드에서도 동일한 점을 지적하며, 이는 지극히 옳습니다. 탐지는 실제 방문자가 마주하는 화면을 기준으로 이루어져야 합니다.

이것이 바로 웹사이트 변경 모니터의 역할입니다. 실제 방문자와 동일하게 외부에서 페이지를 가져와 이전 검사 결과와 비교합니다. 이때 던지는 질문은 “이 페이지가 우리가 의도하지 않은 방식으로 변경되었는가?”입니다.

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

사이트 전체의 모든 페이지를 감시할 필요는 없습니다. 잘못된 변경이 발생했을 때 금전적 손실이나 신뢰 훼손이 가장 빠르게 발생하고, 내부 담당자보다 방문자가 먼저 알아차릴 만한 핵심 페이지부터 시작하세요.

페이지	비정상적인 변경의 형태	브리프(지침)에 입력할 내용
홈페이지	헤드라인 변조, 지원하지 않는 언어의 텍스트, 낯선 도메인 링크	헤드라인, 히어로 문구, 메인 CTA 버튼 또는 가격 변경 시 알림
가격 페이지 (Pricing)	요금제 누락, 잘못된 가격 표기, 빈 테이블	가격, 요금제 또는 한도 변경 시 알림
주요 랜딩 페이지	플레이스홀더(임시 텍스트), 섹션 누락	섹션이 사라지거나 플레이스홀더 문구가 표시되면 알림
이용약관 및 개인정보 처리방침	구버전 복원, 조항 누락	조항의 추가, 삭제 또는 문구 수정 시 알림
사이트맵 (Sitemap)	팀에서 게시한 적 없는 미확인 URL 생성	별도 지침 불필요(사이트맵 모니터는 새로 추가된 URL을 단순 나열함)

앞의 네 행은 일반 페이지 모니터입니다. 마지막 행은 사이트맵 모니터로, sitemap.xml에 새로운 URL이 감지되면 알림을 보냅니다. 이는 도메인 하위에 수백 개의 스팸 페이지가 은밀히 생성되는 특정 유형의 공격을 탐지하는 데 유용하지만, CMS가 해당 페이지들을 사이트맵에 반영할 때만 감지할 수 있습니다.

Free 플랜에서는 10개의 모니터링 URL이 제공되며, 사이트맵 모니터도 1개로 계산됩니다. 이 정도면 홈페이지, 가격 페이지, 주요 랜딩 페이지 3개, 법적 고지 페이지 2개, 사이트맵을 모두 포함하고도 2개의 여유 슬롯이 남습니다.

설정 방법

기본적인 설정은 당사의 웹사이트 변경을 모니터링하는 방법 가이드와 동일하지만 한 가지 차이점이 있습니다. 기대하는 변화를 찾는 대신, “절대로 일어나서는 안 되는 일”을 설명해야 한다는 점입니다.

1. 브리프(지침)와 함께 페이지 등록하기

무료 계정을 생성하고 ‘New monitor’를 클릭한 후 URL을 입력하세요. 설명(Description) 필드는 변경 사항의 중요도를 평가할 때 당사의 LLM이 참조하는 프롬프트입니다. 나 대신 페이지를 지켜보고 있는 동료에게 남기는 업무 지침처럼 작성하세요.

자체 홈페이지의 경우 다음과 같은 지침이 효과적입니다:

우리의 자체 홈페이지(example.com)입니다. 정기 릴리스 외에는 거의 변경되지 않습니다.
헤드라인, 히어로 문구, 메인 CTA 버튼 또는 가격에 변경이 발생하면 알림을 보내주세요.
우리 제품과 무관한 텍스트, 공격적이거나 불쾌한 문구, 우리가 지원하지 않는 언어의 텍스트가 표시되면 알림을 보내주세요.
주기적으로 회전하는 고객사 로고 및 최신 블로그 포스트 미리보기 위젯은 무시하세요.

‘무시(Ignore)’ 항목은 생각보다 매우 중요합니다. 거의 모든 페이지에는 스스로 바뀌는 동적 위젯이 존재하며, 이를 지정해두지 않으면 첫 주 내내 무의미한 알림에 시달리게 됩니다.

2. 두 곳의 채널로 알림 전송하기

‘Channels’ 메뉴에서 알림 수신처를 추가하세요. Slack, Discord, Microsoft Teams는 수신 웹훅(Incoming Webhook) URL을 입력하면 됩니다. 이메일은 수신자가 인증 메일을 먼저 확인해야 하며, 서명된 웹훅을 사용하면 자체 시스템으로 직접 연동할 수도 있습니다. 각 채널에서 ‘Send test’를 클릭하여 정상 수신을 확인하세요.

자체 사이트를 감시할 때는 서로 다른 유형의 채널 두 곳(예: Slack 채널 + 당직자 이메일 그룹)을 연동하는 것을 권장합니다. 각 알림은 채널당 1회 발송되며 자동 재시도가 없으므로, 두 번째 채널이 있으면 Slack의 일시적 장애로 인해 홈페이지 변조 알림을 놓치는 사태를 방지할 수 있습니다.

3. 배포 직후 즉시 검사 트리거하기

Page Deltas에서는 고정된 검사 주기를 수동으로 설정하지 않습니다. 일정은 적응형(Adaptive)으로 작동하므로, 자주 바뀌는 페이지는 더 자주, 정적인 페이지는 덜 자주 검사되며, 대기열이 혼잡할 때는 유료 플랜이 우선순위를 갖습니다. 자체 홈페이지는 일반적으로 정적이기 때문에 검사 주기가 길어지기 쉬운데, 이는 배포 직후 즉각적인 확인을 원하는 상황과 정반대입니다.

해결책은 직접 즉시 검사를 트리거하는 것입니다. 모든 모니터에는 ‘Check now’ 버튼이 있으며 API로도 동일한 작업이 지원되므로, 배포 파이프라인 마지막 단계에 호출 한 줄을 추가하기만 하면 됩니다:

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

수동 검사는 모니터당 분당 1회로 제한되어 있으며, 이는 배포 파이프라인 검증용으로 충분합니다. API 키는 ‘Settings’의 ‘API keys’에서 생성할 수 있으며(editor 또는 admin 권한 필요), 생성 시 1회만 표시되므로 즉시 CI/CD 환경 변수에 저장하세요. 모니터 생성 자체도 스크립트로 자동화하고 싶다면 모든 웹사이트를 변경 감지 API로 변환하는 방법 가이드에서 전체 API를 다루고 있습니다.

알림 수신 시 대처 요령

이처럼 설정해 두면 유의미한 변경이 발생했을 때 자연어로 된 요약문과 함께 변경 전후 스크린샷이 담긴 단일 메시지가 전송됩니다. 서명된 웹훅을 사용하는 경우 수신되는 페이로드는 다음과 같습니다(값은 이해를 돕기 위한 예시입니다):

{
  "event": "change.detected",
  "monitor_id": "01HW2X...",
  "monitor_url": "https://example.com/pricing",
  "monitor_name": "당사 가격 페이지",
  "change_id": "...",
  "detected_at": "2026-10-08T07:12:00Z",
  "summary": "Pro 및 Business 요금제가 더 이상 표시되지 않습니다. 가격표에 현재 Free 요금제만 나타납니다.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

자체 사이트에 대한 대부분의 알림은 팀이 의도하여 배포한 변경 사항입니다. 이는 지극히 정상이며 오히려 유용합니다. 스레드에 “오늘 배포된 건입니다”라고 짧게 답글을 남겨두면, 해당 채널은 무엇이 언제 배포되었는지를 기록하는 실시간 로그가 됩니다. 진정으로 주의해야 할 것은 팀 내 아무도 인지하지 못한 알림입니다.

의문의 알림이 도착했을 때 스크린샷은 두 가지 역할을 합니다. 현재 방문자에게 무엇이 노출되고 있는지 즉시 확인시켜 주며, 추후 보안팀이나 보험사에서 요구할 수 있는 타임스탬프가 찍힌 증거 자료가 됩니다. 변경 이력은 Free 플랜에서 14일, 유료 플랜에서는 더 오래 보관되므로(Starter는 30일, Scale은 최대 730일) 필요한 자료는 미리 다운로드해 두세요.

때로는 최초의 경고가 시스템 알림이 아니라 소셜 미디어에 고객이 올린 스크린샷일 수도 있습니다. 이러한 상황까지 빠르게 파악하고 싶다면 당사의 자매 서비스인 KWatch.io를 활용해 보세요. Reddit, X, LinkedIn, Facebook, Hacker News에서 브랜드명이 언급될 때 실시간으로 알림을 보내줍니다.

도구의 한계와 적용 불가 영역

이 구성으로 감지할 수 없는 몇 가지 사항이 있으며, 전적으로 의존하기 전에 이를 명확히 인지해야 합니다.

저희는 각 페이지의 본문 텍스트를 비교합니다. 내비게이션, 푸터, 광고는 비교 전 자동으로 제외되므로, 푸터에 삽입된 스팸 링크는 감지되지 않습니다. 또한 텍스트 변경 없이 로고 이미지만 교체되는 것과 같은 순수 시각적 변경도 감지되지 않습니다.

이 도구는 업타임(가동 상태) 모니터가 아닙니다. 사이트가 다운되면 알림 대신 검사 실패가 발생하며, 10회 연속 실패 시 모니터가 자동으로 일시 중지되고 관리자에게 안내가 전달됩니다. 장애 대응용으로는 너무 느리므로, 서버 다운 감지에는 기존 업타임 모니터를 계속 유지하세요.

배포 사이의 변경 사항은 다음 예정된 정기 검사에서 감지되며, 검사 간격이 고정되어 있지 않습니다. 특정 페이지를 몇 분마다 무조건 검사해야 한다면 페이지별로 고정 주기를 설정할 수 있는 Visualping이 더 적합합니다. 또한 공개 페이지만 검사할 수 있으므로 로그인 뒤의 보호된 페이지는 감시할 수 없습니다.

마지막으로, Page Deltas는 ‘무언가 변경되었다’는 사실만 알려줍니다. 공격자가 어떤 경로로 침투했는지까지는 밝혀내지 못하므로, 침투 경로 분석은 여전히 전용 보안 도구의 몫입니다.

홈페이지부터 시작해 보세요

먼저 홈페이지와 가격 페이지를 등록하고, 위의 예시를 바탕으로 자체 제외 규칙을 반영한 뒤 두 채널에 테스트 알림을 보내보세요. 그런 다음 배포 스크립트에 check-now API 호출을 추가하세요. Free 플랜은 AI 필터링, 5개 알림 채널 전체, API 액세스가 포함된 10개의 URL 또는 사이트맵을 카드 등록 없이 무료로 제공합니다. 무료로 모니터링 시작하기.

Julien, Page Deltas 프로덕트 매니저