레지덴셜 프록시는 저희가 판매하는 제품이기 때문에, 언제 필요하지 않은지에 대해 글을 쓰는 것이 이상하게 보일 수 있습니다. 하지만 모든 작업에 프록시를 구매하는 팀은 비용을 과다 지출하게 되고, 모든 실패를 프록시 탓으로 돌리는 팀은 몇 주를 허비하게 됩니다. 어떤 사이트에 레지덴셜 IP가 필요한지, 어떤 사이트에는 아무것도 필요 없는지, 어떤 사이트에는 전혀 다른 것이 필요한지를 아는 것이 웹 데이터 수집에서 가장 비용 효율적인 최적화입니다.
이를 구체적으로 확인하기 위해 소규모 테스트를 진행했습니다. 2026년 10월 9일, 데이터센터 IP 주소를 사용하는 클라우드 서버에서 30개의 공개 페이지를 각각 3회씩 요청한 뒤, 미국 엑시트를 사용하는 Shifter 레지덴셜 프록시를 통해 다시 동일하게 요청했습니다. 두 실행 모두 동일한 단순 Python HTTP 클라이언트를 사용했습니다. 30개 페이지 중 16개는 데이터센터 IP에서 매번 작동했습니다. 3개는 레지덴셜 엑시트를 통해서만 작동했습니다. 나머지 11개는 양쪽 모두에서 실패했는데, 이는 레지덴셜 IP로 해결되지 않는 이유 때문입니다.
테스트: 30개 페이지, 데이터센터 IP vs 레지덴셜 프록시
테스트 대상은 여섯 가지 유형의 사이트, 즉 공개 API 및 오픈 데이터, 참고자료 및 문서 사이트, 뉴스 홈페이지, 전자상거래 검색 페이지, 여행 검색 페이지, 그리고 소셜, 구인, 검색 페이지 묶음을 포함했습니다. 각 요청은 동일한 데스크톱 브라우저 User-Agent를 사용했으며, 단순히 상태 코드가 아니라 실제 콘텐츠 여부를 확인했습니다. 즉 검색 결과 카드처럼 실제 콘텐츠에만 나타나는 마커가 응답에 포함된 경우에만 성공으로 집계했습니다. 따라서 흔히 발생하는, 상태 200을 반환하는 차단 페이지는 실패로 집계되었습니다.
마커는 최종 실행 전에 양쪽 네트워크에서 저장한 응답을 검토해 선정했으며, 실제 콘텐츠와 로그인 장벽 또는 빈 JavaScript 셸을 구분할 수 없었던 후보 페이지 5개는 제외했습니다.
| 카테고리 | 사이트 | 데이터센터 IP | 레지덴셜 엑시트 | 판정 |
|---|---|---|---|---|
| 공개 API 및 오픈 데이터 | en.wikipedia.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 공개 API 및 오픈 데이터 | api.github.com | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 공개 API 및 오픈 데이터 | data.sec.gov | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 공개 API 및 오픈 데이터 | api.worldbank.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 공개 API 및 오픈 데이터 | ecb.europa.eu | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 참고자료 및 문서 | docs.python.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 참고자료 및 문서 | developer.mozilla.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 참고자료 및 문서 | rfc-editor.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 참고자료 및 문서 | en.wikipedia.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 참고자료 및 문서 | arxiv.org | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 참고자료 및 문서 | stackoverflow.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 뉴스 | bbc.com | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 뉴스 | reuters.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 뉴스 | nytimes.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 뉴스 | theguardian.com | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 뉴스 | edition.cnn.com | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 뉴스 | bloomberg.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 전자상거래 검색 | amazon.com | 3회 중 3회 | 2회 중 3회 | 프록시 불필요 |
| 전자상거래 검색 | walmart.com | 0회 중 3회 | 3회 중 3회 | 레지덴셜 IP 필요 |
| 전자상거래 검색 | ebay.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 전자상거래 검색 | bestbuy.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 시간 초과 |
| 전자상거래 검색 | etsy.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 여행 | booking.com | 0회 중 3회 | 2회 중 3회 | 레지덴셜 IP 필요 |
| 여행 | expedia.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 여행 | airbnb.com | 3회 중 3회 | 2회 중 3회 | 프록시 불필요 |
| 여행 | tripadvisor.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 여행 | kayak.com | 0회 중 3회 | 3회 중 3회 | 레지덴셜 IP 필요 |
| 소셜, 구인, 검색 | linkedin.com | 3회 중 3회 | 3회 중 3회 | 프록시 불필요 |
| 소셜, 구인, 검색 | indeed.com | 0회 중 3회 | 0회 중 3회 | 양쪽 모두 차단됨 |
| 소셜, 구인, 검색 | google.com | 0회 중 3회 | 0회 중 3회 | 브라우저 필요 |
‘양쪽 모두 차단됨’은 단순 HTTP 클라이언트가 두 네트워크 모두에서 차단되었음을 의미합니다. 브라우저 점검을 처리하는 실제 브라우저나 스크래핑 API라면 해당 사이트에서도 충분히 성공할 수 있지만, 이번 테스트에서는 시도하지 않았습니다.
카테고리별로 결과를 정리하면 다음과 같습니다:
| 카테고리 | 페이지 수 | 프록시 불필요 | 레지덴셜 IP 필요 | 양쪽 모두 실패 |
|---|---|---|---|---|
| 공개 API 및 오픈 데이터 | 5 | 5 | 0 | 0 |
| 참고자료 및 문서 | 6 | 5 | 0 | 1 |
| 뉴스 | 6 | 3 | 0 | 3 |
| 전자상거래 검색 | 5 | 1 | 1 | 3 |
| 여행 | 5 | 1 | 2 | 2 |
| 소셜, 구인, 검색 | 3 | 1 | 0 | 2 |
| 합계 | 30 | 16 | 3 | 11 |
30개 페이지 테스트가 보여주는 것
공개 API, 오픈 데이터, 문서 사이트는 프록시가 필요 없습니다. 테스트한 API 및 참고자료 페이지는 한 곳을 제외하고 모두 데이터센터 IP에서 매 시도마다 작동했습니다. 이러한 서비스는 프로그램이 사용하도록 설계되어 있습니다. 이들이 원하는 것은 설명이 담긴 User-Agent, 합리적인 요청 속도, 그리고 일부의 경우 API 키입니다. 프록시는 비용만 추가할 뿐 다른 효과는 없습니다.
많은 대형 사이트는 데이터센터 IP를 전혀 차단하지 않습니다. 뉴스 홈페이지 6개 중 3개, Amazon 검색, Airbnb 검색, LinkedIn 회사 페이지는 클라우드 서버에 3회 중 3회 모두 실제 콘텐츠를 제공했습니다. 이러한 사이트에서 소량으로 데이터를 수집한다면, 사이트의 이용약관과 요청 속도 제한을 지키는 한 프록시 없이 시작하는 것도 합리적입니다.
Amazon과 Airbnb는 각각 데이터센터 IP에서 3회 중 3회, 레지덴셜 엑시트에서 3회 중 2회 작동했습니다. 사이트당 3회 시도에서 1회 실패는 정상적인 변동 범위 안에 있으며, 레지덴셜 IP가 그곳에서 더 나쁜 성능을 보인다는 증거가 아닙니다. 각 레지덴셜 요청은 서로 다른 가정용 연결에서 출발하며, 개별 엑시트는 고정된 클라우드 서버와 달리 느리거나 동일 사이트에 최근에 포착되었을 수 있습니다. 교훈은 결정을 내리기 전에 여러 번 테스트하라는 것이며, 아래의 점검 방법이 이를 쉽게 해줍니다.
일부 사이트는 IP 평판으로 차단하며, 이 지점에서 레지덴셜 엑시트가 중요해집니다. Walmart, Kayak, Booking.com은 매번 데이터센터 IP를 거부했지만 레지덴셜 엑시트를 통해서는 콘텐츠를 제공했습니다. 이러한 사이트는 요청이 들어오는 네트워크에 점수를 매기며, 클라우드 서버의 주소는 낮은 점수를 받습니다. 이것이 바로 레지덴셜 프록시가 존재하는 이유입니다.
일부 사이트는 IP가 아니라 클라이언트를 차단합니다. eBay, Etsy, Expedia, Tripadvisor, Indeed, Stack Overflow와 뉴스 사이트 3곳은 단순 Python 클라이언트를 두 네트워크 모두에서 차단했습니다. 이들은 요청이 어디에서 오는지 확인하기 전에, TLS 핑거프린트, HTTP 헤더, JavaScript 실행 여부 등 클라이언트가 어떻게 연결하고 동작하는지를 확인합니다. 스크립트임을 드러내는 클라이언트는 레지덴셜 IP로도 해결되지 않습니다. 이러한 점검이 작동하는 방식은 저희의 TLS 및 HTTP/2 핑거프린팅 가이드에서 설명합니다.
일부 페이지는 네트워크와 무관하게 브라우저가 필요합니다. Google 검색은 두 네트워크 모두에 JavaScript를 요구하는 페이지를 반환했으며, HTML에는 결과가 없었습니다. 이런 페이지에서는 헤드리스 브라우저와 데이터를 직접 반환하는 API 중에서 선택해야 합니다.
사이트에 무엇이 필요한지 판별하는 방법
대부분의 대상은 아무것도 구매하기 전에 반나절 만에 이 그룹들로 분류할 수 있습니다. 아래 함수는 테스트에서 사용한 점검 방법으로, 페이지를 가져와 실제 콘텐츠를 얻었는지, 차단되었는지, 오류가 발생했는지, 아니면 빈 셸인지를 판단합니다.
import re
import requests
BLOCK = re.compile(r"captcha|access denied|are you a robot|just a moment|unusual traffic|"
r"verify you are human|request blocked|pardon our interruption|enable javascript and cookies",
re.IGNORECASE)
HEADERS = {
"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36",
"Accept-Language": "en-US,en;q=0.9",
}
def check(url, marker, proxies=None):
"""Did this request get the real content, or a block, an error or an empty shell?"""
try:
response = requests.get(url, headers=HEADERS, proxies=proxies, timeout=30)
except requests.RequestException as error:
return {"url": url, "result": "error", "detail": type(error).__name__}
body = response.text
if response.status_code != 200:
result = "blocked" if response.status_code in (202, 401, 403, 429, 503) else "error"
elif BLOCK.search(body[:20000]) and marker.lower() not in body.lower():
result = "blocked"
elif marker.lower() not in body.lower():
result = "no content"
else:
result = "ok"
return {"url": url, "result": result, "status": response.status_code, "bytes": len(response.content)}원하는 콘텐츠에만 나타나는 마커를 선택하십시오. 예를 들어 결과 카드의 클래스 이름이나 JSON 응답의 필드 이름 등입니다. 페이지 제목에 나오는 단어는 사용하지 마십시오. 차단 페이지와 로그인 장벽에서도 자주 반복되기 때문입니다. 그런 다음 각 대상에서 몇 개의 페이지에 대해 실행해 보십시오:
from check import check
print(check("https://api.github.com/repos/python/cpython", '"full_name"'))
print(check("https://www.ebay.com/sch/i.html?_nkw=laptop", "srp-results")){'url': 'https://api.github.com/repos/python/cpython', 'result': 'ok', 'status': 200, 'bytes': 6617}
{'url': 'https://www.ebay.com/sch/i.html?_nkw=laptop', 'result': 'blocked', 'status': 403, 'bytes': 1832}스크래퍼가 실제로 실행될 위치(운영 환경이 클라우드 서버라면 노트북이 아니라 그 서버)에서 하루에 걸쳐 몇 차례 실행해 보십시오. 결과는 다음과 같은 결정으로 이어집니다:
| 클라우드 서버에서 관찰되는 현상 | 일반적인 의미 | 사용해야 할 것 |
|---|---|---|
| 지속적으로 실제 콘텐츠가 표시됨 | 해당 사이트는 현재 요청량에서 데이터센터 트래픽을 차단하지 않음 | 프록시 없음, 또는 규모 확장을 위한 데이터센터 IP |
| 차단되거나 챌린지가 발생하지만 가정용 연결에서는 실제 콘텐츠가 표시됨 | 해당 사이트는 IP 평판으로 차단함 | 레지덴셜 프록시 |
| 모든 네트워크에서 차단됨 | 해당 사이트는 클라이언트를 점검함 | 실제 브라우저나 스크래핑 API, 보통 그 아래에 레지덴셜 IP 사용 |
| 데이터 없는 빈 셸 | 콘텐츠가 JavaScript로 렌더링됨 | 헤드리스 브라우저, 또는 해당 페이지가 호출하는 API |
| 로그인 장벽 | 콘텐츠가 공개되어 있지 않음 | 허가 없이 수집하지 말 것 |
두 가지 보완 사항이 있습니다:
- 요청량에 따라 답이 달라집니다. 클라우드 서버에서 보낸 10건의 요청은 무시하는 사이트도 1만 건은 차단할 수 있습니다. 한 번만 테스트하지 말고 실제 운영할 속도로 다시 테스트하십시오.
- 위치에 따라 답이 달라집니다. 사이트는 국가별로 다른 콘텐츠를 제공하고 다른 규칙을 적용합니다. 독일에서 보이는 데이터가 필요하다면 독일에서 테스트하십시오.
위치별 데이터에 레지덴셜 프록시가 필요한 경우
저희 테스트는 한 가지 질문만 다뤘습니다. 사이트가 콘텐츠를 제공하는가 하는 것입니다. 그러나 흔히 더 중요한 두 번째 질문이 있습니다. 특정 장소에 있는 실제 사람이 보게 될 콘텐츠를 제공하는가 하는 것입니다.
클라우드 서버는 소수의 데이터센터 위치에 자리하며, 많은 사이트는 데이터센터 주소를 인식해 기본 버전을 보여줍니다. 전 세계 공통 홈페이지, 미국 달러로 표시된 가격, 현지 재고 없음, 또는 광고 자체가 없는 경우 등입니다. 특정 국가나 도시의 사용자가 보는 내용에 작업이 좌우된다면, 그곳에, 실제 사용자가 사용하는 네트워크상에 있는 엑시트가 필요합니다. 여기에 해당하는 경우는 다음과 같습니다:
- 지역별 검색 결과 및 순위, 도시마다 달라집니다.
- 가격, 재고, 배송 옵션, 소매업체와 여행 사이트가 시장별로 설정합니다.
- 광고 및 랜딩 페이지, 광고주가 위치별로 타겟팅하며 데이터센터 트래픽에는 표시되지 않는 경우가 많습니다. 이를 확인하는 것이 광고 검증의 핵심입니다.
- 국가별로 라이선스가 부여되거나 제한되는 콘텐츠입니다.
이런 경우 사이트는 데이터센터 IP를 전혀 차단하지 않을 수도 있지만, 올바른 위치의 레지덴셜 엑시트 없이는 여전히 잘못된 데이터를 수집하게 됩니다.
중간 단계의 선택지
선택지는 프록시 없음과 레지덴셜 프록시 사이의 양자택일만 있는 것이 아닙니다.
- 데이터센터 IP는 저렴하고 빠르며, 차단하지 않는 사이트에는 적합합니다. ISP 프록시와 데이터센터 프록시 비교 글에서 언제 이것으로 충분한지 다룹니다.
- ISP 프록시는 소비자용 인터넷 제공업체에 등록된 주소로, 더 긴 기간 동안 유지됩니다. 장시간 세션이나 본인 계정 로그인에 적합합니다. Shifter의 ISP 프록시는 전체 청구 기간 동안 선택한 도시와 ISP(ASN)를 그대로 유지하며 무제한 트래픽을 제공하므로, 이를 허용하는 사이트에서의 대용량, 지속적인 작업에도 적합합니다.
- 스크래핑 API는 브라우저, 재시도, IP 선택을 대신 처리해 주며, 기가바이트 단위가 아니라 성공한 페이지 단위로 과금합니다. 클라이언트를 점검하는 사이트에서는 직접 브라우저 레이어를 구축하고 유지할 필요가 없기 때문에 흔히 가장 저렴한 선택지가 됩니다. JavaScript 중심 사이트 스크래핑 가이드를 참고하십시오.
- 레지덴셜 프록시는 사이트가 요청이 들어오는 네트워크를 판단 기준으로 삼을 때, 즉 동일한 클라이언트가 가정용 연결에서는 성공하고 클라우드 서버에서는 실패할 때 적합한 도구입니다.
FAQ
웹 스크래핑에 프록시가 필요한가요?
항상 그런 것은 아닙니다. 저희 테스트에서는 모든 공개 API와 대부분의 문서 사이트를 포함해 30개 공개 페이지 중 16개가 프록시 없이도 클라우드 서버에 실제 콘텐츠를 제공했습니다. 먼저 스크래퍼가 실행될 위치에서 대상을 테스트하십시오.
레지덴셜 프록시는 언제 필요한가요?
사이트가 데이터센터 IP에서의 요청은 차단하지만 동일한 클라이언트를 가정용 연결에서는 허용할 때입니다. 저희 테스트에서는 30개 사이트 중 3개(Walmart, Kayak, Booking.com)가 이런 방식으로 동작했습니다.
레지덴셜 프록시를 사용해도 왜 여전히 차단되나요?
보통 사이트가 IP가 아니라 클라이언트를 점검하고 있기 때문입니다. 많은 사이트는 TLS 핑거프린트, 헤더, JavaScript 부재 등으로 스크립트임이 드러나는 HTTP 클라이언트를 차단합니다. 저희 테스트에서는 단순 Python 클라이언트를 사용했을 때 30개 페이지 중 11개가 두 네트워크 모두에서 실패했습니다. 해결책은 다른 IP가 아니라 실제 브라우저나 스크래핑 API입니다.
스크래핑에 데이터센터 프록시로 충분한가요?
공개 API, 문서, 많은 뉴스 사이트, 일부 대형 소매업체의 경우 적당한 요청량에서는 충분합니다. IP 평판으로 점수를 매기는 사이트에는 충분하지 않습니다. 추측하지 말고 각 대상을 테스트하십시오.
데이터센터 IP와 레지덴셜 IP의 차이는 무엇인가요?
데이터센터 IP는 호스팅 또는 클라우드 제공업체 소유입니다. 레지덴셜 IP는 소비자용 인터넷 제공업체 소유이며 실제 가정용 연결에서 사용됩니다. 많은 사이트가 레지덴셜 주소를 더 신뢰하는데, 이는 일반 방문자들이 이를 사용하기 때문입니다.
사이트가 데이터센터 IP를 차단하는지 어떻게 테스트하나요?
클라우드 서버에서 몇 개의 페이지를 요청하고, 단순히 상태 코드가 아니라 실제 콘텐츠에만 나타나는 마커가 응답에 있는지 확인하십시오. 그런 다음 레지덴셜 엑시트를 통해 동일하게 반복하십시오. 클라우드 서버는 거부되고 레지덴셜 엑시트는 허용된다면, 해당 사이트는 IP 평판으로 차단하는 것입니다.
위치별 데이터에 레지덴셜 프록시가 필요한가요?
보통 그렇습니다. 클라우드 서버를 전혀 차단하지 않는 사이트조차도 기본 버전의 페이지를 보여주는 경우가 많습니다. 특정 국가나 도시의 사용자가 보는 지역 검색 결과, 가격, 광고를 보려면 그 장소의 엑시트가 필요합니다.
테스트에서 Amazon과 Airbnb가 레지덴셜 프록시로는 왜 덜 자주 작동했나요?
각각 레지덴셜 시도 3회 중 1회 실패했는데, 이는 3회 시도에서 정상적인 변동 범위 안에 있습니다. 모든 레지덴셜 요청은 서로 다른 가정용 연결에서 출발하며, 개별 엑시트는 느리거나 해당 사이트에 최근 포착되었을 수 있습니다. 결론을 내리기 전에 여러 번 테스트하십시오.
결론
레지덴셜 프록시는 한 가지 특정한 문제, 즉 요청이 들어오는 네트워크로 판단하는 사이트를 해결합니다. 클라이언트를 점검하는 사이트에는 도움이 되지 않으며, 공개 API나 클라우드 트래픽을 차단하지 않는 사이트에는 불필요합니다. 스크래퍼가 실행될 위치에서 각 대상을 테스트해 이 그룹들 중 하나로 분류하고, 결과가 달라지는 경우에만 레지덴셜 트래픽에 비용을 지불하십시오. 책임감 있는 수집의 나머지 부분은 저희의 웹 스크래핑 모범 사례에서 다룹니다.