Summary#

웹 콘텐츠 수집기의 crawl frontier는 “다음에 어떤 URL을, 언제, 어떤 제약하에 가져올 것인가”를 결정하는 운영 핵심이다. 공개 자료를 종합하면 주요 실패 모드는 단순한 큐 장애가 아니라 robots.txt 적용 시점, URL 정규화·중복 제거, 호스트별 politeness/rate limiting, freshness 기반 재수집, 삭제·소멸 리소스 tombstone 처리가 서로 얽히며 발생한다.

안전한 설계의 중심 원칙은 다음과 같다.

• URL을 frontier에 넣기 전뿐 아니라 fetch 직전에도 robots.txt 정책을 확인해야 한다.
• URL canonicalization과 duplicate elimination은 별개로 다뤄야 하며, canonicalization 오류는 누락·중복·무한 frontier 팽창을 만든다.
• rate limiting은 전역 QPS가 아니라 host/domain/download slot 단위로 관리해야 한다.
• recrawl freshness는 단순 주기 cron이 아니라 변경 빈도, 중요도, 실패 이력, HTTP cache signal을 반영해야 한다.
• 404, 410, 반복 5xx, redirect chain 변화는 URL 메타데이터의 상태 전이로 남겨야 하며, 특히 410은 “영구적으로 gone일 가능성”이 큰 tombstone 후보로 취급해야 한다.

Key Points#

1. Robots.txt enforcement failure#

Stanford IR crawler architecture 자료는 robots.txt를 frontier 삽입 시점에만 검사하면 위험하다고 설명한다. URL이 frontier 안에 며칠 또는 몇 주 머무를 수 있고, 그 사이 robots.txt가 바뀔 수 있기 때문이다. 따라서 실무적으로는 다음 패턴이 필요하다.

• URL discovery 단계:
• scope, scheme, host allowlist/blocklist 등 1차 필터 적용
• robots.txt는 캐시 가능하지만 최종 권한 판단으로 고정하지 않음
• fetch 직전 단계:
• robots.txt cache TTL 확인
• 만료 시 재조회
• user-agent별 rule 적용
• disallow이면 fetch하지 않고 frontier 상태를 blocked_by_robots로 기록
• 실패 모드:
• stale robots cache로 금지된 경로를 fetch
• robots.txt fetch 실패를 allow로 오해
• user-agent mismatch
• crawl-delay 무시
• robots 정책 변경 후 이미 큐에 들어간 URL을 재검증하지 않음

Heritrix 문서는 pre-fetch processor가 DNS lookup과 robots.txt policy 획득·준수를 fetch 전제조건으로 다루며, robots 정보의 유효 기간 설정도 제공한다. 이는 robots 판단을 frontier 바깥의 단순 필터가 아니라 fetch 전 상태 기계의 일부로 봐야 함을 시사한다.

2. Canonical URL deduplication failure#

Crawler architecture 자료는 추출된 링크가 frontier에 들어가기 전에 URL normalization과 duplicate elimination을 거친다고 설명한다. 이때 두 계층을 분리하는 것이 중요하다.

• URL canonicalization
• 상대 URL을 절대 URL로 변환
• scheme/host case normalization
• default port 제거
• fragment 제거 여부 결정
• trailing slash, percent-encoding, query parameter ordering 정책화
• Duplicate elimination
• canonicalized URL 기준으로 frontier 또는 fetched set 중복 확인
• content fingerprint 또는 digest 기반의 near/exact duplicate 확인
• already queued / already fetched / recently fetched 상태 구분

주요 실패 모드:

• 과도한 canonicalization:
• 의미 있는 query parameter를 제거해 서로 다른 페이지를 하나로 합침
• pagination, locale, product variant 누락
• 부족한 canonicalization:
• http://example.com, http://example.com/, https://EXAMPLE.com/ 등을 별개로 큐잉
• tracking parameter로 frontier 폭증
• content duplicate와 URL duplicate를 혼동:
• 같은 문서가 여러 URL에 있을 수 있음
• 다른 문서가 같은 URL pattern을 공유할 수 있음
• canonical URL 태그를 무비판적으로 신뢰:
• 페이지 내 <link rel="canonical">은 유용하지만 악성·오류·cross-domain canonical 가능성이 있어 정책 검증 필요

Heritrix의 FrontierPreparer는 URL canonicalization policy를 “순서 있는 규칙 목록”으로 다룬다. 이는 canonicalization이 단일 함수가 아니라, 순서와 예외가 중요한 정책 집합이라는 점을 보여준다.

3. Rate limiting and politeness failure#

Scrapy AutoThrottle 문서는 request가 기본적으로 URL domain 기준 download slot에 배정되고, AutoThrottle이 slot별 delay를 동적으로 조정한다고 설명한다. 또한 target concurrency는 hard limit이 아니라 목표값이며, per-domain concurrency 제한은 여전히 적용된다.

운영 관점의 실패 모드:

• 전역 rate limit만 두고 특정 host를 과도하게 때림
• domain 기준과 IP 기준을 혼동해 shared hosting 또는 CDN에서 편향 발생
• retry storm:
• 429, 503, timeout에 즉시 재시도
• 실패 URL이 priority queue 상단에 계속 재삽입
• robots crawl-delay와 내부 throttle 정책 충돌
• slow host가 worker thread를 점유해 전체 frontier throughput 저하
• hot domain이 frontier를 독점해 long-tail domain starvation 발생

권장 상태 모델:

• host/domain별 queue 또는 download slot
• per-slot:
• next_allowed_fetch_at
• recent latency
• recent error rate
• robots crawl-delay
• configured min delay
• adaptive backoff
• global scheduler:
• ready slot 중 priority 선택
• host fairness 보장
• 반복 실패 host quarantine

4. Freshness recrawl failure#

Continuous crawling에서는 이미 fetch한 URL도 다시 frontier에 들어올 수 있다. Stanford IR 자료 역시 continuous crawling에서 이전에 fetch한 URL이 재수집을 위해 frontier에 돌아올 수 있음을 설명한다.

주요 실패 모드:

• 모든 URL을 같은 주기로 recrawl:
• 자주 바뀌는 페이지는 stale
• 거의 안 바뀌는 페이지는 crawl budget 낭비
• fetch 성공 시각만 기록하고 content change 여부를 기록하지 않음
• HTTP cache headers, ETag, Last-Modified, content digest를 활용하지 않음
• 304 Not Modified와 200 unchanged를 구분하지 않음
• recrawl task가 discovery task와 같은 priority queue에서 충돌
• 오래된 URL이 계속 뒤로 밀려 starvation

권장 metadata:

• first_seen_at
• last_fetch_attempt_at
• last_success_at
• last_content_change_at
• last_status_code
• content_digest
• etag
• last_modified
• change_observation_count
• estimated_change_interval
• next_recrawl_at

Freshness policy는 단순 “최근 본 순서”가 아니라, 페이지의 변경 가능성·중요도·비용·서버 politeness를 함께 고려해야 한다.

5. Tombstone handling failure#

Tombstone은 더 이상 수집 대상이 아니거나, 수집 가능성이 낮거나, 영구 삭제로 판단되는 URL 상태를 명시적으로 남기는 메커니즘이다. HTTP RFC 9110에 따르면 410 Gone은 대상 리소스 접근이 origin server에서 더 이상 가능하지 않고 이 상태가 영구적일 가능성이 있음을 나타낸다. 반면 404는 임시·영구 여부를 확정하지 않는다.

실무 상태 전이 예:

• active
• 최근 정상 fetch
• soft_missing
• 404, 403, timeout, DNS error 등 일시 가능성 있음
• gone_candidate
• 반복 404
• 410
• 장기간 동일 missing 상태
• tombstoned
• recrawl 대상에서 제외 또는 매우 낮은 빈도로 확인
• resurrected
• tombstone 이후 200/3xx valid response 확인

주요 실패 모드:

• 404 한 번에 영구 삭제 처리:
• 일시적 배포 장애나 CDN 오류일 수 있음
• 410을 일반 4xx와 동일하게 retry:
• crawl budget 낭비
• tombstone을 dedupe set에서 완전히 삭제:
• 같은 URL이 계속 rediscovered되어 frontier에 재삽입
• redirect destination의 tombstone 상태를 source URL에 잘못 전파
• soft-404를 탐지하지 못함:
• status 200이지만 “not found” 템플릿 반환

권장 처리:

• 410은 강한 tombstone signal로 기록하되, 정책에 따라 낮은 빈도의 검증 recrawl 허용
• 404는 반복 횟수와 기간 기준으로 점진적으로 backoff
• tombstone도 URL registry에 남겨 rediscovery loop 방지
• tombstone 사유와 관측 증거를 분리 저장:
• status_code
• observed_at
• failure_count
• tombstone_reason
• confidence
• next_probe_at

6. Cross-cutting invariant#

Crawl frontier 운영에서 가장 위험한 패턴은 “큐에 들어간 URL은 언젠가 fetch해도 된다”는 가정이다. 안전한 collector는 fetch 직전에 다음을 다시 확인해야 한다.

• scope still valid?
• robots still allows?
• host politeness window open?
• URL canonical form changed?
• duplicate or tombstoned already?
• recrawl due now?
• retry budget available?
• redirect target acceptable?

즉 frontier는 단순 FIFO/priority queue가 아니라, URL 상태·host 상태·policy 상태를 결합한 scheduler로 설계되어야 한다.

Cautions#

• 공개 자료만 사용했으며, 특정 상용 검색엔진의 내부 crawl frontier 구현은 확인하지 않았다.
• Heritrix와 Scrapy는 공개 crawler framework 사례로 유용하지만, 모든 대규모 웹 검색 crawler의 구현을 대표하지는 않는다.
• RFC 9110의 410 의미는 HTTP semantics 수준의 정의이며, 실제 웹에서는 서버 설정 오류로 410이 잘못 반환될 수 있다.
• canonicalization 정책은 사이트별로 달라질 수 있다. 예를 들어 query parameter 제거는 중복 감소에 효과적이지만, 전자상거래·검색·pagination URL에서는 데이터 손실을 만들 수 있다.
• robots.txt 처리의 법적 의미는 관할권과 사용 맥락에 따라 달라질 수 있다. 여기서는 운영적·윤리적 crawler 설계 관점으로만 다뤘다.
• “freshness” 최적화는 변경 빈도뿐 아니라 수집 목적, crawl budget, source priority, 보존 정책에 따라 달라진다.

Sources#

• https://www-nlp.stanford.edu/IR-book/html/htmledition/crawler-architecture-1.html
• https://heritrix.readthedocs.io/en/latest/bean-reference.html
• https://docs.scrapy.org/en/latest/topics/autothrottle.html
• https://www.rfc-editor.org/rfc/rfc9110.html

Related#

• Collector Pipeline Failure Modes: Recrawl Scheduling, Deduplication, and Zero-Yield Extraction
• Contact Identity Resolution and Sync Failure Modes: Canonicalization, Deduplication, Survivorship Rules, and Tombstone Safety
• API Handoff, Spam Filtering, Rate Limiting, Bounce Handling, and PII-Safe Logging

Sagwan Revalidation 2026-09-17T15:15:42Z#

• verdict: ok
• note: 핵심 권장안과 HTTP/크롤러 관행이 여전히 유효하며 큰 갱신 필요 없음