법적 고지: 이 글은 공개 데이터 수집을 위한 기술 가이드입니다. CFAA(Computer Fraud and Abuse Act)와 GDPR을 비롯한 관련 법률을 준수하고, 대상 사이트의 robots.txt와 이용약관을 존중하며, 개인정보 보호 의무를 다할 책임은 사용자에게 있습니다. 가능하다면 공식 API를 우선 사용하세요.
Python으로 대규모 웹 크롤러를 구축하다 보면, 결국 한 가지 벽에 부딪힙니다: IP 차단. 아무리 User-Agent를 바꾸고 요청 간격을 조절해도, 동일한 IP에서 수백 개의 요청이 들어오면 Cloudflare나 DataDome 같은 봇 방지 시스템이 즉시 차단합니다. Crawlee for Python에서 프록시 로테이션은 이 문제를 해결하는 핵심 기법이며, ProxyConfiguration 클래스와 SessionPool을 조합하면 프로덕션급 수집 파이프라인을 구축할 수 있습니다.
이 글에서는 Crawlee for Python의 아키텍처부터 시작해, residential 프록시를 세션별로 바인딩하는 방법, Cloudflare/Datadome 우회 전략, 그리고 실제 코드 예제와 프로덕션 패턴까지 다룹니다. Crawlee python 프록시 설정을 처음 하는 개발자도, 기존 크롤러를 최적화하려는 엔지니어도 바로 적용할 수 있도록 구성했습니다.
Crawlee for Python에서 프록시 로테이션의 기본: 아키텍처 이해
Crawlee for Python은 Apify 팀이 만든 오픈소스 웹 스크래핑 프레임워크로, 공식 문서에 따르면 BeautifulSoupCrawler와 PlaywrightCrawler라는 두 가지 주요 크롤러를 제공합니다. 두 크롤러 모두 동일한 Request Queue와 AutoscaledPool 위에서 작동하며, 이것이 프록시 로테이션을 일관되게 적용할 수 있는 핵심 이유입니다.
통합 요청 큐와 크롤러 선택
Crawlee의 모든 크롤러는 RequestProvider(기본적으로 메모리 기반 또는 스토리지 기반 큐)에서 URL을 가져옵니다. 이意味着 BeautifulSoupCrawler로 빠른 HTML 파싱을 하다가, JavaScript 렌더링이 필요한 페이지만 PlaywrightCrawler로 전환하는 하이브리드 전략이 가능합니다. 두 크롤러는 동일한 ProxyConfiguration 인스턴스를 공유하므로, 프록시 로테이션 로직을 한 곳에서 관리할 수 있습니다.
SessionPool: 쿠키, 지문, IP의 결합
Crawlee의 SessionPool은 단순한 쿠키 저장소가 아닙니다. 각 세션은 다음을 캡슐화합니다:
- 쿠키 jar: 대상 사이트에서 발급한 세션 쿠키
- 브라우저 지문: User-Agent, Accept-Language, viewport 등
- 프록시 URL: 해당 세션에 바인딩된 프록시 엔드포인트
- 상태 정보: 차단 여부, 재시도 횟수, 만료 시간
이 세 가지가 함께 바인딩되기 때문에, 세션을 로테이션하면 쿠키와 지문도 함께 바뀝니다. 이것이 Crawlee 세션 풀이 단순 IP 로테이션보다 강력한 이유입니다. 봇 방지 시스템은 IP뿐만 아니라 쿠키와 지문 패턴도 추적하기 때문에, 이 세 가지를 함께 로테이션하는 것이 필수적입니다.
AutoscaledPool과 동시성
Crawlee의 AutoscaledPool은 시스템 리소스(CPU, 메모리, 이벤트 루프 지연)를 모니터링하며 동시 실행 수를 자동 조절합니다. 기본값은 최소 1, 최대 200개의 동시 요청입니다. 프록시를 사용할 때는 이 값을 대상 사이트의 rate limit에 맞춰 조절해야 합니다. 예를 들어, 대상 사이트가 분당 100개 요청만 허용한다면 max_concurrency를 10~20으로 제한하는 것이 안전합니다.
ProxyConfiguration 클래스: Crawlee 프록시 로테이션의 핵심
Crawlee의 ProxyConfiguration은 모든 프록시 관리의 중심입니다. 이 클래스는 공식 API 문서에 정의된 대로 두 가지 모드를 지원합니다:
1. 라운드 로빈 로테이션 (기본)
프록시 URL 목록을 전달하면, Crawlee가 각 요청마다 다음 URL을 순환합니다. 단순하지만, 세션과 IP가 분리되므로 쿠키가 IP 간에 섞이는 문제가 발생할 수 있습니다.
from crawlee.proxy_configuration import ProxyConfiguration
# 라운드 로빈 방식 — 각 요청마다 다른 프록시
proxy_config = ProxyConfiguration(
proxy_urls=[
'http://user-country-US:pass@gate.proxyhat.com:8080',
'http://user-country-DE:pass@gate.proxyhat.com:8080',
'http://user-country-GB:pass@gate.proxyhat.com:8080',
]
)2. 세션 기반 프록시 바인딩 (권장)
new_url(session_id=...) 메서드를 사용하면, 동일한 세션 ID에 대해 항상 동일한 프록시 URL을 반환합니다. Crawlee의 SessionPool이 각 세션에 고유 ID를 부여하므로, 세션과 프록시가 1:1로 매핑됩니다. 이 방식이 Crawlee proxyconfiguration의 권장 패턴입니다.
from crawlee.proxy_configuration import ProxyConfiguration
# 세션 기반 — 각 세션에 고정 IP 할당
async def proxy_info_fn(session_id):
# ProxyHat username에 session_id를 포함해 고정 IP 바인딩
username = f'user-country-US-session-{session_id}'
return {
'url': f'http://{username}:pass@gate.proxyhat.com:8080'
}
proxy_config = ProxyConfiguration(
proxy_info_fn=proxy_info_fn
)이 패턴에서 ProxyHat의 username 파라미터 session-{id}가 핵심 역할을 합니다. 동일한 session ID를 전달하면 ProxyHat 게이트웨이가 동일한 residential IP를 반환하므로, 세션 수명 동안 IP가 유지됩니다. 세션이 retire되면 새 session ID가 발급되고, 자연스럽게 새 IP로 전환됩니다.
Residential vs Datacenter: 왜 Crawlee 세션 풀에 residential이 필요한가
봇 방지 시스템은 IP의 ASN(Autonomous System Number)을 조회해 데이터센터 IP를 식별합니다. AWS, Google Cloud, DigitalOcean 등의 IP 대역은 잘 알려져 있어, 데이터센터 프록시를 사용하면 차단 확률이 크게 높아집니다. 반면 residential 프록시는 실제 ISP(예: Comcast, AT&T, Deutsche Telekom)에서 할당된 주소이므로, 일반 사용자의 트래픽과 구별하기 어렵습니다.
| 프록시 유형 | 탐지 난이도 | 평균 지연 | 성공률 (Cloudflare 대상) | 비용 |
|---|---|---|---|---|
| Datacenter | 낮음 (ASN으로 쉽게 식별) | 50~100ms | 20~40% | 낮음 |
| Residential | 높음 (실제 ISP IP) | 200~500ms | 85~95% | 중간~높음 |
| Mobile | 매우 높음 (셀룰러 IP) | 300~800ms | 90~98% | 높음 |
Cloudflare는 Bot Score 시스템을 통해 각 요청에 1~99점의 점수를 매깁니다. 데이터센터 IP는 기본 점수가 낮아 차단되기 쉽고, residential IP는 기본 점수가 높아 정상 트래픽으로 분류될 확률이 큽니다. Crawlee의 세션 기반 로테이션과 residential 프록시를 조합하면, 각 세션이 일관된 IP와 쿠키를 유지해 자연스러운 브라우징 패턴을 만들어냅니다.
티어드 프록시 전략
프로덕션에서는 단일 프록시 유형에 의존하지 않는 것이 좋습니다. 티어드(tiered) 전략은 다음과 같이 작동합니다:
- Tier 1: Residential 프록시로 시작. 차단 발생 시 해당 세션을 retire.
- Tier 2: 동일 URL을 데이터센터 프록시로 재시도. 속도가 빠르므로 간단한 페이지에 유효할 수 있음.
- Tier 3: Mobile 프록시로 최종 시도. 비용이 높지만 가장 통과율이 높음.
Crawlee에서는 max_request_retries와 session_retire 로직을 조합해 이 전략을 구현할 수 있습니다. ProxyHat 위치 페이지에서 각 국가별로 사용 가능한 프록시 유형을 확인할 수 있습니다.
실전 예제: BeautifulSoupCrawler + ProxyConfiguration + ProxyHat
이제 실제로 동작하는 완전한 예제를 살펴보겠습니다. BeautifulSoupCrawler를 사용해 미국 기반 사이트를 수집하면서, 각 세션에 ProxyHat residential 프록시를 바인딩합니다.
import hashlib
from crawlee.beautifulsoup_crawler import BeautifulSoupCrawler
from crawlee.proxy_configuration import ProxyConfiguration
from crawlee.sessions import SessionPool
PROXYHAT_USER = 'your_username'
PROXYHAT_PASS = 'your_password'
# 세션 ID별로 고유한 ProxyHat username 생성
def make_proxyhat_username(session_id: str, country: str = 'US') -> str:
# session_id를 해시해 짧고 고유한 식별자 생성
short_id = hashlib.md5(session_id.encode()).hexdigest()[:8]
return f'{PROXYHAT_USER}-country-{country}-session-{short_id}'
# ProxyConfiguration의 proxy_info_fn — Crawlee가 각 세션마다 호출
async def proxy_info_fn(session_id: str | None = None):
if session_id is None:
session_id = 'default'
username = make_proxyhat_username(session_id, country='US')
return {
'url': f'http://{username}:{PROXYHAT_PASS}@gate.proxyhat.com:8080'
}
proxy_config = ProxyConfiguration(proxy_info_fn=proxy_info_fn)
crawler = BeautifulSoupCrawler(
proxy_configuration=proxy_config,
max_request_retries=4,
max_session_rotations=10,
request_handler_timeout=60,
)
@crawler.router.default_handler
async def handler(request, session, proxy_info, enqueue_links):
# proxy_info에서 현재 세션의 프록시 URL 확인
print(f'세션 {session.id} → 프록시 {proxy_info.url}')
# HTTP 상태 코드 확인
if request.http_method == 'GET':
response = await session.get(request.url)
# 차단 감지
if response.status_code in (403, 429):
print(f'차단 감지: {response.status_code}. 세션을 폐기합니다.')
session.retire()
return
# 정상 응답 처리
html = await response.text()
# 데이터 추출 로직...
# 링크 큐에 추가
await enqueue_links()
async def main():
await crawler.run(['https://example.com'])
if __name__ == '__main__':
import asyncio
asyncio.run(main())이 예제의 핵심 포인트는 proxy_info_fn 콜백입니다. Crawlee가 새 세션을 생성할 때마다 이 함수를 호출하고, 반환된 프록시 URL을 해당 세션에 바인딩합니다. ProxyHat의 username에 session-{short_id}를 포함하면, 동일한 세션 ID에 대해 항상 동일한 residential IP가 반환됩니다.
PlaywrightCrawler로 전환하기
JavaScript 렌더링이 필요한 페이지의 경우, 동일한 proxy_config를 PlaywrightCrawler에 전달하면 됩니다:
from crawlee.playwright_crawler import PlaywrightCrawler
playwright_crawler = PlaywrightCrawler(
proxy_configuration=proxy_config,
max_request_retries=4,
browser_type='chromium',
headless=True,
)
@playwright_crawler.router.default_handler
async def handler(request, page, session, proxy_info, enqueue_links):
# Playwright는 자동으로 프록시를 브라우저 컨텍스트에 적용
await page.goto(request.url, wait_until='domcontentloaded')
# Cloudflare 챌린지 감지
title = await page.title()
if 'Just a moment' in title or 'Attention Required' in title:
print('Cloudflare 챌린지 감지. 세션을 폐기합니다.')
session.retire()
return
content = await page.content()
# 데이터 추출 로직...
await enqueue_links()PlaywrightCrawler는 각 세션마다 새 브라우저 컨텍스트를 생성하며, 프록시 URL을 해당 컨텍스트에 적용합니다. 세션과 브라우저 지문, 프록시가 함께 로테이션되므로 봇 방지 시스템을 더 효과적으로 우회할 수 있습니다.
프로덕션 패턴: 차단 대응, 재시도, 동시성 관리
1. session.retire()로 차단 대응
차단을 감지하면 즉시 session.retire()를 호출해야 합니다. 이 메서드는 해당 세션을 폐기하고, Crawlee가 새 세션(새 IP, 새 쿠키, 새 지문)을 생성하게 합니다. 단순히 예외를 raise하는 것보다 retire를 호출하는 것이 훨씬 효율적입니다. retire된 세션의 IP는 해당 세션에서만 사용되었으므로, 다른 세션에 영향을 주지 않습니다.
2. max_request_retries 설정
기본값은 3이지만, 봇 방지 시스템이 있는 사이트에서는 4~5로 설정하는 것이 좋습니다. 각 재시도마다 새 세션(새 IP)이 할당되므로, 재시도 자체가 IP 로테이션 역할을 합니다. 단, 너무 높게 설정하면 비용이 증가하므로 대상 사이트의 차단 빈도에 따라 조절하세요.
3. 동시성 제어
AutoscaledPool의 max_concurrency를 대상 사이트에 맞게 설정합니다. 일반적으로:
- 소규모 사이트:
max_concurrency=5~10 - 중간 규모 (예: 뉴스 사이트):
max_concurrency=20~50 - 대규모 (예: 이커머스 마켓플레이스):
max_concurrency=50~100
ProxyHat residential 프록시는 수백 개의 동시 세션을 지원하지만, 대상 사이트의 서버 부하를 고려해 적절한 값을 선택하는 것이 윤리적이고 효율적입니다.
4. request_handler 에러 처리
@crawler.router.default_handler
async def handler(request, session, proxy_info):
try:
response = await session.get(request.url)
if response.status_code == 200:
# 정상 처리
html = await response.text()
# 데이터 추출...
elif response.status_code in (403, 429):
# 차단: 세션 폐기 + 재시도 유도
session.retire()
raise RuntimeError(f'Blocked: {response.status_code}')
elif response.status_code >= 500:
# 서버 에러: 재시도 (세션 유지)
raise RuntimeError(f'Server error: {response.status_code}')
else:
# 기타: 로깅 후 계속
print(f'Unexpected status: {response.status_code}')
except Exception as e:
# Crawlee가 max_request_retries까지 재시도
raise e5. 컨테이너화와 스케일아웃
대규모 수집을 위해 Crawlee 크롤러를 컨테이너화할 때는 각 컨테이너가 독립적인 세션 풀을 가지도록 설계합니다. Kubernetes에서 실행할 경우, 각 Pod가 별도의 ProxyHat 세션 네임스페이스를 사용하도록 session_id 접두사에 Pod 이름을 포함시키는 것이 좋습니다. 이렇게 하면 여러 Pod가 동일한 residential IP를 할당받는 충돌을 방지할 수 있습니다.
브라우저 크롤링이 필요 없는 경우와 윤리
브라우저를 언제 피해야 하는가
PlaywrightCrawler는 강력하지만 리소스 소모가 큽니다. 다음 경우에는 BeautifulSoupCrawler를 우선 사용하세요:
- 대상 페이지가 정적 HTML로 모든 데이터를 포함하는 경우
- API 엔드포인트가 존재하는 경우 (브라우저 없이 직접 API 호출)
- 수집 속도가 최우선인 경우 (BeautifulSoupCrawler는 PlaywrightCrawler보다 5~10배 빠름)
- 서버 비용이 제약인 경우 (Playwright는 메모리를 200~500MB 추가 사용)
반드시 브라우저가 필요한 경우는 Cloudflare Turnstile, DataDome CAPTCHA, JavaScript 기반 동적 렌더링이 있는 경우뿐입니다. 이 경우에도 PlaywrightCrawler의 headless=True로 시작하고, 차단이 심한 경우에만 stealth 플러그인을 추가하세요.
윤리와 법적 고려사항
프록시 로테이션은 강력한 기술이지만, 책임감 있게 사용해야 합니다:
- robots.txt 준수: 대상 사이트의 robots.txt를 확인하고, disallow된 경로는 수집하지 마세요.
- Rate limit 존중: 대상 사이트의 서버에 과부하를 주지 않도록 요청 간격을 적절히 설정하세요.
- 공식 API 우선: 대상 사이트가 공식 API를 제공한다면, 스크래핑보다 API를 사용하는 것이 안정적이고 법적으로 안전합니다.
- 개인정보 보호: GDPR, CCPA 등 개인정보 보호법을 준수하세요. 공개 데이터라도 개인정보가 포함된 경우 추가 주의가 필요합니다.
- ToS 확인: 대상 사이트의 이용약관을 검토하고, 스크래핑을 금지하는 조항이 있는지 확인하세요.
미국의 CFAA는 '인가 없는 접근'을 금지하며, 2022년 Van Buren 판결 이후 공개 데이터 수집의 형사 처벌 위험은 줄었지만 여전히 민사 소송의 대상이 될 수 있습니다. EU의 GDPR은 개인정보가 포함된 데이터 수집에 엄격한 제한을 둡니다. 자세한 가이드라인은 FTC 프라이버시 가이드를 참조하세요.
ProxyHat 설정 가이드와 내부 링크
ProxyHat을 Crawlee와 함께 사용하는 것은 간단합니다. 프라이싱 페이지에서 플랜을 선택한 후, 대시보드에서 사용자 이름과 비밀번호를 확인하세요. 모든 프록시 연결은 gate.proxyhat.com:8080(HTTP) 또는 gate.proxyhat.com:1080(SOCKS5)을 통해 이루어집니다.
ProxyHat의 username 파라미터 시스템은 Crawlee의 세션 기반 로테이션과 완벽하게 호환됩니다:
-country-US: 미국 IP 지정-country-DE-city-berlin: 독일 베를린 IP 지정-session-abc123: 세션 ID로 고정 IP 바인딩
자세한 연결 정보는 ProxyHat 공식 문서를 참조하세요. 웹 스크래핑 사용 사례와 SERP 추적 사용 사례 페이지에서 추가 시나리오를 확인할 수 있습니다.
Key Takeaways
Crawlee for Python에서 프록시 로테이션을 구현할 때 핵심 요약:
- ProxyConfiguration + SessionPool 조합이 정답 —
proxy_info_fn콜백으로 세션별 프록시를 동적 생성하세요.- Residential 프록시가 기본 — Cloudflare, DataDome 환경에서 데이터센터 IP는 성공률이 20~40%에 불과합니다.
- session.retire()로 차단 대응 — 403/429 응답 시 즉시 retire하고 새 세션으로 전환하세요.
- max_request_retries는 4~5가 적정 — 각 재시도마다 새 IP가 할당되므로, 재시도 자체가 로테이션입니다.
- 동시성은 대상 사이트에 맞춰 조절 — AutoscaledPool의 max_concurrency를 사이트 규모에 따라 5~100 사이로 설정하세요.
- BeautifulSoupCrawler를 먼저 시도 — 정적 HTML로 충분한 경우 Playwright를 피하면 5~10배 빠릅니다.
- 윤리 준수는 필수 — robots.txt, ToS, GDPR/CFAA를 존중하고 공식 API를 우선하세요.
FAQ
Crawlee for Python에서 프록시 로테이션이란 무엇인가요?
Crawlee for Python에서 프록시 로테이션은 ProxyConfiguration 클래스를 통해 여러 프록시 IP를 순환하며 요청을 분산시키는 기법입니다. 각 요청이나 세션마다 다른 IP를 사용해 차단 위험을 줄이고 수집 성공률을 높입니다. Crawlee의 ProxyConfiguration은 new_url(session_id=...) 메서드로 세션 ID별 고정 IP 또는 라운드 로빈 방식을 지원합니다.
Crawlee for Python에서 프록시 로테이션이 프록시 사용자에게 왜 중요한가요?
프록시 로테이션은 단일 IP에서 발생하는 요청 급증으로 인한 IP 차단을 방지합니다. 특히 Cloudflare나 DataDome 같은 봇 방지 시스템은 동일 IP의 반복 요청을 감지해 차단하므로, residential 프록시와 세션 기반 로테이션을 조합하면 성공률을 90% 이상으로 유지할 수 있습니다. Crawlee의 SessionPool은 쿠키와 지문을 IP에 바인딩해 자연스러운 브라우징 패턴을 시뮬레이션합니다.
Crawlee for Python 프록시 로테이션에 어떤 프록시 유형이 가장 적합한가요?
Cloudflare, DataDome, PerimeterX 등 고급 봇 방지 시스템을 다룰 때는 residential 프록시가 가장 적합합니다. 데이터센터 IP는 ASN이 쉽게 식별되어 차단되지만, residential IP는 실제 ISP에서 할당된 주소이므로 탐지가 어렵습니다. Crawlee의 ProxyConfiguration과 residential 프록시를 세션별로 바인딩하면 안정적인 수집 환경을 구축할 수 있습니다.
Crawlee for Python에서 프록시 로테이션 구현 시 차단을 피하려면 어떻게 하나요?
차단을 피하려면 세션 기반 프록시 로테이션을 사용하고, HTTP 403이나 429 응답 시 session.retire()를 호출해 해당 세션을 폐기하세요. max_request_retries를 3~5로 설정하고, autoscaling 풀의 동시성을 대상 사이트의 허용 범위 내로 유지하세요. 또한 robots.txt를 준수하고 요청 간 지연을 추가하며, 필요시 데이터센터 프록시로 폴백하는 티어드 전략을 사용하는 것이 좋습니다.
