2026년 웹 크롤링 모범 사례: 실무자 가이드
3,100명 이상의 사용자에게 >99%의 성공률로 서비스를 제공하는 15개의 프로덕션 스크래퍼를 만들고 유지보수해온 경험에서, 실제로 중요한 원칙들을 정리했습니다.
아키텍처: 스크립트가 아니라 파이프라인으로 생각하라
가장 흔히 보는 실수는 크롤링을 단일 단계 프로세스로 취급하는 것입니다. 프로덕션 스크래퍼는 데이터 파이프라인입니다:
- URL 발견 — 무엇을 크롤링할지 찾기(사이트맵, 카테고리 페이지, 검색, API)
- 요청 실행 — 적절한 재시도와 로테이션으로 데이터 가져오기
- 파싱 — 원시 응답에서 구조화된 필드 추출
- 정규화 — 출력을 정제, 검증, 표준화
- 저장 — 데이터셋, 데이터베이스, 또는 후속 시스템으로 전달
각 단계는 독립적으로 테스트 및 재시도가 가능해야 합니다. Sephora가 상품 페이지 레이아웃을 변경해도 3단계만 업데이트하면 되고, 나머지 파이프라인은 안정적으로 유지됩니다.
HTML 파싱보다 항상 API를 우선하라
CSS 셀렉터를 단 하나라도 작성하기 전에, 사이트에 다음이 있는지 먼저 확인하세요:
- 퍼블릭 API — JSON을 반환하는 문서화된 엔드포인트
- 비공개 API — 브라우저 DevTools에서 보이는 XHR/fetch 호출
- GraphQL 엔드포인트 — 점점 흔해지고 있으며, introspection이 활성화된 경우가 많음
- 임베디드 JSON — HTML 내
__NEXT_DATA__,window.__INITIAL_STATE__, 또는 JSON-LD
API 응답은 구조화되어 있고, 버전이 관리되며, HTML 레이아웃보다 훨씬 안정적입니다. 제 Sephora 스크래퍼는 모든 웹 URL을 API 호출로 변환하며, 프런트엔드 리디자인으로 인해 깨진 적이 단 한 번도 없습니다.
프록시 전략: 방어 수준에 맞춰라
모든 사이트에 레지덴셜 프록시가 필요한 것은 아닙니다. 제 의사결정 프레임워크는 다음과 같습니다:
| 방어 수준 | 프록시 유형 | 예시 사이트 |
|---|---|---|
| 없음 / 기본 | 데이터센터 | 대부분의 Shopify 스토어, 소규모 사이트 |
| 레이트 리밋 | 로테이팅 데이터센터 | 중견 이커머스, 콘텐츠 사이트 |
| 핑거프린팅 | 레지덴셜 | Sephora, Farfetch 등 주요 브랜드 |
| 고급 WAF | 레지덴셜 + TLS 핑거프린트 | Akamai, Cloudflare Enterprise |
핵심은 이것입니다: 프록시 비용은 방어 수준에 비례해 증가합니다. IP 평판만 확인하는 사이트에 레지덴셜 프록시를 쓰는 것은 돈 낭비입니다. 제 Shopify 스크래퍼는 데이터센터 프록시만으로도 문제없이 동작하는데, Shopify의 기본 방어 수준이 낮기 때문입니다.
세션 관리가 전부다
60%와 99% 성공률의 차이는 대개 세션 관리에서 갈립니다:
- IP뿐 아니라 세션도 로테이션하라 — 같은 쿠키에 새 IP만 쓰면 의심스러워 보입니다
- 세션을 워밍업하라 — 상품 페이지에 접근하기 전에 홈페이지부터 방문하세요
- 레이트 리밋을 준수하라 — 차단당하는 50개보다 성공하는 5개의 동시 요청이 낫습니다
- 지수 백오프 — 즉시 재시도가 아니라 1초, 2초, 4초, 8초 간격으로 재시도
제 Sephora EU 스크래퍼는 자동 갱신과 지수 백오프로 게스트 토큰을 관리합니다. 실제 브라우징 패턴처럼 보이는 지속적인 세션을 유지합니다.
출력을 정규화하라
크롤링으로 얻은 원시 데이터는 지저분합니다. 모든 것을 정규화하세요:
가격
정수(달러가 아닌 센트 단위)로 저장하세요. $29.99는 2999가 됩니다. 이렇게 하면 다운스트림에서 금융 데이터를 훼손하는 부동소수점 정밀도 오류를 방지할 수 있습니다. 제 이커머스 스크래퍼는 모두 이 규칙을 따릅니다.
URL
항상 절대 URL로 저장하고, 상대 경로는 사용하지 마세요. 추출 시점에 경로를 해석하세요.
날짜
ISO 8601(2026-04-01T00:00:00Z) 형식을 항상 타임존과 함께 사용하세요. 로케일별로 포맷된 날짜는 저장하지 마세요.
텍스트
불필요한 공백을 제거하고, 유니코드를 정규화하고, HTML 처리 정책(태그 제거 vs. 포맷 유지)을 정해두세요.
에러 처리: 실패를 예상하라
프로덕션 스크래퍼는 끊임없이 실패합니다 — 관건은 얼마나 우아하게 실패하느냐입니다. 제 접근법은 다음과 같습니다:
1Request fails (network error, timeout, 4xx/5xx)
2 → Retry with exponential backoff (up to 5 attempts)
3 → Rotate session/proxy on retry
4 → Log failure with full context if all retries exhausted
5 → Continue processing remaining URLs (don't crash the batch)
URL 패턴별로 성공률을 추적하세요. /category/* 페이지의 성공률이 갑자기 90% 아래로 떨어지면 사이트에 변화가 생겼을 가능성이 높습니다 — 사용자가 신고하기 전에 먼저 알아챌 수 있습니다.
모니터링과 알림
모니터링이 없는 스크래퍼는 조용히 실패할 날만 기다리는 스크래퍼입니다. 다음을 추적하세요:
- 실행별, URL 패턴별 성공률
- 출력 건수 — 갑작스러운 감소는 무언가 깨졌다는 신호입니다
- 데이터 품질 — null 필드, 예상치 못한 값, 스키마 위반
- 비용 — 프록시 사용량, 컴퓨팅 시간, 스토리지
제 Apify 액터는 모두 이 지표들을 노출합니다. 성공률이 떨어지면 몇 시간 안에 알림을 받으며, 대개 사용자가 알아채기 전에 먼저 파악합니다.
단순하게 시작해서 복잡도를 더하라
제가 만드는 모든 스크래퍼는 동작하는 가장 단순한 형태로 시작합니다:
- 먼저 HTTP + Cheerio(가장 빠르고 저렴함)
- 차단당할 때만 핑거프린팅 추가
- JavaScript가 필요할 때만 브라우저 렌더링 추가
- 레이트 리밋에 걸릴 때만 프록시 로테이션 추가
제 Ulta 스크래퍼는 순수 Cheerio만 사용하며 브라우저가 필요 없습니다. 제 Universal Web Printer는 JavaScript를 렌더링해야 하므로 Playwright를 사용합니다. 작업에 맞는 도구를 쓰는 것이 중요합니다.
이는 이론적인 원칙이 아니라, 수백만 건의 요청을 처리하는 프로덕션 스크래퍼를 실제로 운영하며 얻은 결과물입니다. 이런 원칙으로 만들어진 맞춤 스크래퍼가 필요하다면 이야기해봅시다.