무료 체험 시작로그인

지식

사일런트 실패율: 성공한 요청 중 잘못된 콘텐츠를 반환하는 비율

HTTP 200이 페이지를 제대로 받았다는 의미는 아니다. 성공 응답 뒤에 숨은 차단 페이지, 소프트 404, 챌린지에 관한 연구 결과와 이를 직접 측정하는 방법을 소개한다.

Chris Collins

Chris Collins

2026년 9월 23일 · 9 분 소요

모든 스크래핑 대시보드에는 성공률이라는 지표가 있고, 거의 모든 대시보드가 같은 것을 세고 있다. 바로 HTTP 200 응답이다. 수집하기 쉽고 보고하기에도 안심되는 숫자다. 하지만 이는 웹 데이터 수집에서 가장 오해를 부르는 숫자이기도 한데, 200은 그저 서버가 무언가를 응답으로 보냈다는 뜻일 뿐이기 때문이다. 그것이 당신이 요청한 페이지였는지는 전혀 말해주지 않는다.

이 두 가지 사이의 간극이 바로 침묵의 실패율이다. “성공”으로 집계된 요청 중 잘못된 콘텐츠를 반환한 비율을 말한다. 로그에서는 보이지 않는 실패이며, 데이터셋에는 정상 데이터와 똑같은 모습으로 들어온다.

그렇다면 그 규모는 어느 정도일까? 솔직한 답은, 아무도 그것을 발표한 적이 없다는 것이다. 그리고 그 부재 자체가 가장 흥미로운 발견이다. 이 글의 나머지 부분에서는 왜 이런 공백이 존재하는지, 인접한 측정치들이 무엇을 보여주는지, 그리고 자신의 실패율을 어떻게 측정할 수 있는지를 다룬다.

핵심 요약

  • HTTP 200 응답 중 잘못된 콘텐츠를 담고 있는 비율이 웹 전체에서 얼마인지를 측정한 발표된 연구는 없다. 가장 최근의 대규모 봇 차단 연구는 200 응답 내의 콘텐츠 저하가 연구 범위 밖이라고 명시적으로 밝히고 있다.
  • 차단은 흔하지만 제대로 표시되지 않는다. Common Crawl을 대상으로 한 한 연구에 따르면 최소 1.68%의 사이트가 크롤러를 명시적으로 거부했으며, 상태 코드 사용은 일관성이 없거나 심지어 잘못된 경우도 있었다.
  • 차단 페이지도 200으로 도착한다. 쿠바를 대상으로 한 2023년 측정에서, 차단 페이지를 제공한 395개 도메인 중 32개가 200 상태로 이를 제공했다.
  • 주요 링크 부패(link-rot) 연구들은 소프트 404 페이지를 살아있는 페이지로 집계하는데, 이는 콘텐츠를 확인하는 것이 상태 코드를 확인하는 것보다 훨씬 어렵기 때문이다.
  • 자신의 침묵의 실패율은 측정 가능하지만, 상태가 아니라 콘텐츠를 검증해야만 가능하다.

침묵의 실패로 간주되는 것

침묵의 실패란 성공을 보고하지만 실제 방문자가 받았을 콘텐츠를 담고 있지 않은 모든 응답을 말한다. 흔한 형태는 다음과 같다.

형태받게 되는 것성공으로 통과되는 이유
200으로 제공되는 차단 페이지페이지가 있어야 할 자리에 거부 메시지상태는 OK라고 말함
챌린지 또는 인터스티셜CAPTCHA 또는 “브라우저 확인 중” 페이지대개 200, 가끔 에러 코드
소프트 404더 이상 존재하지 않는 콘텐츠에 대해 일반 페이지나 홈페이지 반환서버가 404 대신 200을 반환
빈 껍데기페이지가 JavaScript로 스스로를 구성하기 때문에 콘텐츠가 없는 HTML완전하고 유효한 문서
동의 또는 결제 장벽콘텐츠 앞에 놓인 동의 화면페이지는 로드됐지만 콘텐츠는 아님
잘못된 변형다른 국가의 페이지, 가격 또는 언어완벽하게 실제인 페이지지만 원했던 것은 아님

이들 각각은 정상 데이터처럼 파싱되고, 저장되고, 집계된다. 어느 것도 에러 알림을 발생시키지 않는다.

아무도 측정하지 않은 숫자

봇 차단과 웹 부패를 연구하는 연구자들은 이 질문을 반복적으로 피해왔고, 여러 명은 이를 명시적으로 언급한다.

가장 최근의 대규모 연구인 Gundelach, Mühlhauser, Herrmann의 “Detecting Bot Detection”(Bamberg 대학교, 2026년 6월)은 2026년 2월 27일부터 3월 2일까지 Tranco 상위 10,000개 사이트를 여러 브라우저 구성으로 스캔했다. 이 연구의 한계 섹션은 직접적이다. “HTTP 200 응답 내의 콘텐츠 저하는 우리의 관찰 범위 밖이다.” 저자들은 또한 81편의 웹 측정 논문을 조사하여 “논문의 5%만이 봇 탐지 또는 차단율을 명시적으로 수량화하며, 83%는 이에 대한 논의를 전혀 하지 않는다”는 것을 발견했다.

이들만 그런 것이 아니다. Common Crawl 거부에 관한 PAM 2025 연구는 비(非)200 응답을 기준으로 작업했다. 2018년의 글로벌 지역 차단 연구는 사이트가 로드되면서도 “로그인 버튼이 사라졌거나 일부 콘텐츠를 이용할 수 없는” 경우가 있을 수 있다고 언급하며, 그런 “더 미묘한 콘텐츠 변화”는 향후 연구로 남겨두었다. Pew Research Center의 2024년 링크 부패 연구는 “콘텐츠가 존재하는지 보장할 수 없는 모호한 상황, 예를 들면 소프트 404 페이지”를 접근 가능한 것으로 처리했다. Internet Archive의 2026년 4월 죽은 웹 연구는 “HTTP 상태 코드에 의존했으며 소프트 404를 확인하기 위해 페이지 콘텐츠를 들여다보지 않았다.”

이는 부주의가 아니다. 상태 코드를 분류하는 것은 수백만 페이지 규모로 확장 가능하지만, 콘텐츠가 올바른지 판단하려면 각 페이지에 대해 무엇이 올바른 것인지를 알아야 한다. 바로 그 이유로 침묵의 실패율은 웹 전체 규모에서는 측정되지 않으며, 바로 그 이유로 무엇이 올바른지를 알고 있는 자신의 타겟에 대해서는 측정이 가능하다.

인접한 측정치들이 보여주는 것

단 하나의 수치가 이 질문에 답하지는 않지만, 여러 측정치가 그 범위를 좁혀준다.

발견출처측정 시점
Headless Chromium은 상위 사이트의 15.2%에서 소프트 차단을 당했고, 다른 브라우저 설정에서는 6.8%에서 7.2%였다. 소프트 차단된 사이트의 81.9%는 봇 탐지에 기인한 것으로 추정되었다Gundelach, Mühlhauser, Herrmann, arXiv, 2026년 6월2026년 2월~3월
최소 1.68%의 사이트가 Common Crawl을 명시적으로 거부했으며, 상태 코드 사용이 일관성이 없거나 심지어 잘못되었다. 거부한 도메인의 80%는 모든 요청을 차단했다Ansar, Sperotto, Holz, PAM 2025Common Crawl 스냅샷, 2023년 말
쿠바 사용자에게 차단 페이지를 제공한 395개 도메인 중 32개가 200 상태를 사용했다Ablove 외, USENIX Security 20242023년 5월
자동화된 크롤링은 실제 사용자가 접한 핑거프린팅 웹사이트의 45%를 놓쳤으며, 그 일부는 봇 탐지를 통과하지 못한 데 기인했다Annamalai, Bilogrevic, De Cristofaro, WWW 202510주간 30명의 사용자
45,000개 사이트 중 0.6%에서, 독일 상위 1,000개 사이트 중 8.5%에서 쿠키 장벽이 발견됨Rasaii, Gosain, Gasser, IMC 20232023년
웹 서버의 7.35%가 알 수 없는 문서에 대해 404 대신 200을 반환했다Prieto Álvarez, Álvarez Díaz, Cacheda Seijo, 20142014년 이전
소프트 404가 죽은 링크의 15% 이상을 차지했다Bar-Yossef, Broder, Kumar, Tomkins, WWW 20042004년 이전

첫 두 행은 에러 코드를 통해 볼 수 있는 차단을 설명하며, 이는 확인하기 쉬운 부분이다. 세 번째 행은 나머지 부분도 존재함을 보여준다. 해당 연구에서 대략 열두 개의 차단 페이지 중 하나는 성공으로 위장하고 도착했다. 소프트 404 수치는 오래된 것이며, 그럼에도 가장 최근에 발표된 것이다.

하류에 미치는 비용

실제 데이터셋에서 침묵의 실패를 가장 명확하게 보여주는 그림은 공식 통계에서 나온다. 영국 통계청(Office for National Statistics)이 웹 스크래핑된 슈퍼마켓 데이터로부터 가격 지수를 시험 운영했을 때, 2016년 5월 업데이트는 “이 검증 단계 이후 이상치 또는 오분류로 분류된 상품의 총 비율이 25%였다”고 보고했으며, 가격을 “340만 건에서 250만 건으로” 제거했다고 밝혔다. 데이터 누락은 “주로 소매업체들이 웹사이트에 구조적 변경을 가한 데서 비롯되었다”고 덧붙였다.

이 25%는 HTTP 수준의 실패율이 아니다. 그 대부분은 잘못된 카테고리로 스크래핑된 상품과 이상치 가격이었다. 바로 이 점이 핵심이다. 그 모든 레코드는 성공한 요청에서 돌아온 것이었고, 그중 4분의 1은 사용할 수 없었다. 이를 찾아내기 위해서는 통계청이 구축한 검증 단계가 필요했다.

상태 코드가 이 신호를 전달할 수 없는 이유

서버가 거부를 정직하게 보고한다면 편리할 것이다. 그러나 증거는 서버들이 일관되게 그렇게 하지 않는다는 것을 보여준다. Common Crawl 연구는 거부가 일관성 없고 심지어 잘못된 HTTP 상태 코드 사용을 통해 신호를 보낸다는 것을 발견했다. 쿠바 연구는 차단이 DNS 실패, 타임아웃, 403, 소수의 전용 451 코드, 그리고 200에 걸쳐 흩어져 있음을 발견했다.

일부 인프라는 실제로 도움이 된다. Cloudflare는 모든 챌린지 페이지 유형에 대해 cf-mitigated: challenge 응답 헤더를 설정하는데, 이는 상태 코드보다 훨씬 신뢰할 수 있는 신호다. 이를 확인해보라. 하지만 한 제공업체의 헤더는 웹 표준이 아니며, 대부분의 침묵의 실패는 아무런 표시도 지니고 있지 않다.

자신의 침묵의 실패율 측정하기

정의는 간단하다. 자신의 시스템이 성공으로 집계한 응답 중 콘텐츠 검증에 실패한 비율이다. 작업은 검증 자체에 있다.

  1. 응답이 아니라 레코드를 검증하라. 각 페이지 유형의 모든 레코드가 반드시 포함해야 하는 필드를 정하고, 이를 산출하지 못하는 200 응답은 모두 실패로 처리하라.
  2. 페이지 유형의 정상 크기와 비교하라. 평소 크기의 5분의 1밖에 되지 않는 상품 페이지는 상품 페이지가 아닌 경우가 드물지 않다.
  3. 차단 및 챌린지 표시를 찾아라. cf-mitigated 같은 헤더와 실제 타겟이 사용하는 문구를 포함해서.
  4. 카나리아를 운영하라. 올바른 콘텐츠를 독립적으로 알고 있는 페이지를, 프로덕션과 같은 경로를 통해 가져와서 비교하라.
  5. 어디에서 가져왔는지 기록하라. 잘못된 국가 변형은 접속 지점(vantage point)을 기록해야만 탐지할 수 있으며, 이는 vantage-point 표준에서 다룬 사례다.
  6. 표본을 뽑아 사람이 검토하라. 매주 몇십 개의 응답을 사람이 읽는 것만으로도 어떤 규칙도 예상하지 못한 실패 유형을 잡아낼 수 있다.

1차 분류기는 아주 작게 구현할 수 있다.

BLOCK_MARKERS = ("captcha", "access denied", "unusual traffic", "verify you are human")
REQUIRED_FIELDS = ("title", "price")


def classify(resp, record, baseline_bytes):
    """Label one response. Anything but "ok" on a 200 is a silent failure."""
    if resp.headers.get("cf-mitigated") == "challenge":
        return "challenge"
    if resp.status_code != 200:
        return "http_error"
    if not record and any(m in resp.text.lower() for m in BLOCK_MARKERS):
        return "block_page"
    if len(resp.content) < 0.2 * baseline_bytes:
        return "too_small"
    if not record or any(record.get(f) in (None, "") for f in REQUIRED_FIELDS):
        return "missing_fields"
    return "ok"

결과를 타겟별, 페이지 유형별로, 이미 갖고 있는 성공률 옆에 보고하라. 이 둘이 서로 어긋날 때, 성공률은 당신에게 거짓말을 하고 있는 것이다. 한 사이트에서 소프트 차단이 증가하는 것은 또한 그 사이트가 크롤러에 등을 돌리기 시작했다는 가장 이른 신호 중 하나이며, 이는 타겟 상태 점수가 잡아내도록 설계된 것이다. 더 넓은 범위의 지표는 웹 스크래핑 파이프라인 모니터링에 정리되어 있다.

도구가 도움이 되는 부분과 되지 않는 부분

관리형 수집은 침묵의 실패 중 일부를 당신에게 도달하기 전에 제거한다. Shifter의 Web Scraping API는 실패한 요청, CAPTCHA, 일시적인 타겟 오류를 최대 세 번까지 서로 다른 프록시로 자동 재시도하며, 성공한 요청에 대해서만 요금을 부과한다. JavaScript 렌더링은 브라우저에서 스스로를 구성하는 페이지에 대한 빈 껍데기 문제를 제거하며, extract_rules는 이름이 지정된 필드를 반환하므로 누락된 필드를 쉽게 탐지할 수 있다.

어떤 수집 계층도 할 수 없는 것은, 완벽하게 정상적으로 형성된 페이지가 잘못된 가격이나 잘못된 국가의 카탈로그를 담고 있다는 것을 아는 일이다. 오직 당신만이 자신의 데이터에 대해 무엇이 올바른지를 알고 있다. 콘텐츠 검증은 페이지를 어떻게 가져왔는지와 관계없이 자신의 파이프라인에 속해야 한다.

결론

200은 서버가 하는 주장이지, 콘텐츠에 대한 보장이 아니다. 차단 페이지, 챌린지, 소프트 404, 빈 껍데기, 동의 장벽, 잘못된 변형 모두 성공으로 위장하고 도착하며, 발표된 연구는 타당한 실무적 이유로 웹 차단에 관해 거의 모든 것을 측정해왔지만 이것만은 예외로 남겨두었다.

그 결과, 당신이 갖게 될 유일한 침묵의 실패율은 스스로 측정한 것뿐이다. 모든 레코드를 검증하고, 답을 알고 있는 카나리아를 유지하고, 그 결과를 성공률과 같은 대시보드에 올려두라. 두 숫자 사이의 차이가 바로 지금 당신이 신뢰할 수 없는 데이터셋의 부분이다.

출처 및 참고문헌

시작할 준비가 되셨나요?

205M개 이상의 IP, 195개 이상의 국가를 지원하는 Shifter의 레지덴셜 프록시를 $0.10/GB부터 이용해보세요.

시작하기

관련 기사

지식
지식

기업들이 프록시 사용을 선호하는 4가지 단순한 이유

2023년 1월 24일
지식
지식

프록시를 사용하는 기업을 위한 5가지 주요 이점

2022년 11월 28일
지식
지식

AI 스크래핑을 위한 레지덴셜 프록시 5종 vs 데이터센터 프록시 비교

2026년 6월 16일