Selenium과 Playwright 중 레지덴셜 프록시를 거쳐 실행하는 작업에 어느 쪽을 선택할지 고민하고 있거나, 둘 다 유지보수하고 있다면, 유용한 것은 두 개의 별도 설정 가이드가 아니라 비교 자체입니다. 무엇이 동일하고, 무엇이 실제로 다르며, 그 차이 중 어떤 것이 구축 방식에 영향을 미쳐야 하는가. 여기 동일한 작업을 각 프레임워크에서 수행한 결과를 나란히 정리했습니다.
프레임워크별로 더 깊은 세부사항과 각각의 엣지 케이스가 궁금하다면 Selenium에서 레지덴셜 프록시 사용하기와 Playwright에서 레지덴셜 프록시 사용하기를 참고하세요. 이 글은 그 위에 올라가는 비교 계층입니다.
동일한 부분: 게이트웨이
두 프레임워크는 동일한 엔드포인트에 동일한 자격증명으로 통신합니다. 프록시는 무엇이 자신을 구동하는지 신경 쓰지 않기 때문입니다. 호스트 p.shifter.io, 포트 443, 그리고 모든 타겟팅 정보는 사용자 이름에 인코딩됩니다:
customer-USERNAME # rotate, no geo
customer-USERNAME-country-de # German exit
customer-USERNAME-country-us-city-new_york # city level
customer-USERNAME-country-de-sid-abc123-ttl-600 # sticky, ten minutes즉, 지역, 로테이션, 세션 유지 시간에 관한 모든 결정은 문자열이며, 두 프레임워크에서 동일합니다. 아래 섹션에서 다루는 내용은 게이트웨이 자체를 바꾸지 않으며, 각 프레임워크가 이 자격증명을 게이트웨이에 전달하는 방식만 바꿉니다. 형식에 대한 참조는 연결 방법에 있습니다.
진짜 차이: 인증
이것이 실제로 중요한 차이이며, 사람들이 겪는 마찰의 대부분을 설명합니다.
Playwright는 인증이 필요한 프록시를 네이티브로 지원합니다. 사용자 이름과 비밀번호는 일급 옵션이므로 별도 작업 없이 그대로 작동합니다.
Selenium은 그렇지 않습니다. 프록시 호스트와 포트를 설정할 수는 있지만, WebDriver 명세에는 자격증명을 전달할 메커니즘이 없어서 Chrome이 스크립트로 닫을 수 없는 네이티브 인증 대화상자를 표시합니다. Selenium의 모든 해결책은 이 공백을 우회하는 방법이며, 세 가지가 있습니다: 자격증명을 대신 처리해주는 Selenium Wire, 자격증명을 제공하는 작은 생성된 Chrome 확장 프로그램, 또는 브라우저의 디버깅 프로토콜을 직접 구동하는 CDP입니다.
새로 시작하는 상황이고 작업에 인증이 필요한 프록시가 필요하다면, 이 차이만으로도 Playwright를 선호할 정당한 이유가 됩니다.
두 프레임워크에서 동일한 설정
Playwright, Python:
from playwright.sync_api import sync_playwright
USER = "customer-USERNAME-country-de-sid-abc123-ttl-600"
with sync_playwright() as p:
browser = p.chromium.launch()
context = browser.new_context(
proxy={"server": "http://p.shifter.io:443",
"username": USER, "password": "PASSWORD"},
locale="de-DE", timezone_id="Europe/Berlin", # match the exit
)
page = context.new_page()
page.goto("https://ipinfo.io/json")
print(page.inner_text("body"))Playwright, Node:
const ctx = await browser.newContext({
proxy: { server: 'http://p.shifter.io:443',
username: 'customer-USERNAME-country-de-sid-abc123-ttl-600',
password: 'PASSWORD' },
locale: 'de-DE', timezoneId: 'Europe/Berlin',
});Selenium, Python, Selenium Wire 사용:
from seleniumwire import webdriver
USER = "customer-USERNAME-country-de-sid-abc123-ttl-600"
proxy_url = f"http://{USER}:PASSWORD@p.shifter.io:443"
opts = {"proxy": {"http": proxy_url, "https": proxy_url,
"no_proxy": "localhost,127.0.0.1"}}
driver = webdriver.Chrome(seleniumwire_options=opts)
driver.get("https://ipinfo.io/json")
print(driver.find_element("tag name", "body").text)동일한 게이트웨이, 동일한 사용자 이름, 동일한 결과입니다. 유일한 차이는 자격증명이 들어가는 방식입니다.
구조적 차이: 아이덴티티를 분리하는 방식
실제로 설계에 영향을 미쳐야 할 차이는 이것이며, 각 프레임워크에서 분리된 아이덴티티가 얼마나 비용이 드는지에서 비롯됩니다.
Playwright에서는 컨텍스트가 저렴합니다. 브라우저 컨텍스트는 자체 쿠키, 스토리지, 그리고 중요하게는 자체 프록시를 가진 격리된 프로필입니다. 하나의 브라우저 프로세스를 실행하면서 아이덴티티마다 컨텍스트를 만들 수 있으므로, 지역이나 세션을 로테이션하는 것은 새 브라우저가 아니라 새 컨텍스트를 만드는 문제가 됩니다.
browser = p.chromium.launch() # one process
for country in ["de", "fr", "us"]:
ctx = browser.new_context(proxy={"server": "http://p.shifter.io:443",
"username": f"customer-USERNAME-country-{country}",
"password": "PASSWORD"})
page = ctx.new_page()
page.goto("https://example.com")
ctx.close() # identity discarded, process staysSelenium에서는 프록시가 드라이버에 묶입니다. 프록시를 변경하려면 일반적으로 새 드라이버가 필요하고, 드라이버는 하나의 전체 브라우저 프로세스입니다. 시작이 느리고 메모리 부담이 큽니다. 따라서 Selenium의 패턴은 반대입니다. 하나의 아이덴티티에 대해 많은 요청에 드라이버를 재사용하고, 아이덴티티 변경은 요청마다 하는 것이 아니라 배치로 처리해야 할 비용이 큰 작업으로 취급합니다.
실질적인 결과는 이렇습니다: 짧게 유지되는 아이덴티티가 많이 필요한 작업은 Playwright에서 눈에 띄게 더 저렴하고, 하나의 아이덴티티를 긴 시퀀스 동안 유지하는 작업은 어느 쪽이든 적합합니다. Selenium을 실행하면서 요청마다 드라이버를 실행하고 있다면, 가장 먼저 고쳐야 할 것은 그것이지 프록시 설정이 아닙니다.
지역, 로테이션, 세션
타겟팅이 사용자 이름에 담겨 있으므로 이 부분은 프레임워크와 무관합니다. sid를 생략하면 각 새 연결마다 새로운 출구 주소를 얻고, 포함하면 TTL이 만료될 때까지 동일한 주소가 유지됩니다. Playwright에서는 이를 컨텍스트 단위로 범위를 지정하고, Selenium에서는 드라이버 단위로 범위를 지정합니다.
두 경우 모두에서 지켜야 할 한 가지: 국가를 설정할 때는 브라우저의 로케일과 타임존도 그에 맞춰 설정해야 합니다. 독일 출구가 뉴욕 타임존을 보고하는 것은 쉽게 탐지되고 쉽게 피할 수 있는 모순이며, 지역, 타임존, 로케일 일치시키기에 따라 두 프레임워크 모두 이를 컨텍스트 옵션으로 제공합니다.
대역폭: 두 프레임워크가 공유하는 비용
브라우저는 GB당 비용이 드는 제품에서 비싼 편입니다. 실제 브라우저가 가져올 모든 것, 즉 이미지, 폰트, 미디어, 분석 스크립트까지 가져오기 때문입니다. 필요 없는 것을 차단하는 것이 가능한 절감책 중 가장 큰 것이며, 두 프레임워크 모두 이를 지원합니다.
Playwright:
context.route("**/*", lambda route: route.abort()
if route.request.resource_type in {"image", "media", "font", "stylesheet"}
else route.continue_())Selenium은 순정 형태로는 이에 해당하는 한 줄짜리 방법이 없습니다. Selenium Wire를 사용하면 요청을 필터링할 수 있고, 또는 CDP를 통해 리소스 유형을 차단할 수도 있습니다. 어느 쪽이든 해볼 만한 가치가 있습니다. 페이지 크기를 크게 줄이는 경우가 흔하기 때문입니다. 헤드리스 브라우저가 정말 필요한지를 포함한 더 넓은 논의는 헤드리스 브라우저가 필요한 시점과 프록시 대역폭 비용 절감하기에 있습니다.
작동 확인하기, 두 경우 모두
프록시가 적용되었다고 가정하지 마세요. 주소를 보여주는 엔드포인트로 이동해서 자신의 주소가 아닌지 확인하세요:
# Playwright
page.goto("https://ipinfo.io/json"); print(page.inner_text("body"))
# Selenium
driver.get("https://ipinfo.io/json"); print(driver.find_element("tag name", "body").text)주소가 자신의 것이라면 프록시가 전혀 적용되지 않고 있는 것입니다. 주소는 맞는데 콘텐츠가 해당 지역과 맞지 않는다면, 풀을 탓하기 전에 DNS 유출 방지하기에 따라 DNS나 로케일 불일치를 의심하세요.
무엇을 선택할 것인가
기존에 정해진 것이 없고 작업에 인증이 필요한 프록시와 많은 아이덴티티가 관련된다면, Playwright가 더 쉬운 길입니다. 네이티브 자격증명 지원과 저렴한 컨텍스트 단위 격리는 그렇지 않으면 직접 설계해서 해결해야 할 두 가지 문제를 없애줍니다.
이미 Selenium 인프라를 갖추고 있거나, 그리드와 크로스 브라우저 생태계가 필요하거나, 작업이 많은 짧은 세션이 아니라 하나의 오래 유지되는 세션인 경우에는 Selenium도 합리적인 선택입니다. 프록시 지원은 충분히 사용 가능하며, 단지 자격증명을 넣기 위해 라이브러리나 작은 확장 프로그램이 필요할 뿐입니다.
그리고 두 경우 모두, 브라우저는 차단당하지 않는 것의 절반일 뿐이라는 것을 기억하세요. 주소는 문 앞까지 데려다줄 뿐이고, 차단 피하기에 따라 헤더, 핑거프린트, 속도 조절이 그 다음에 무슨 일이 일어날지를 결정합니다.
결론
게이트웨이는 두 프레임워크에서 동일하므로, 지역, 로테이션, 세션 유지 시간은 각각에서 동일한 문자열입니다. 실제 차이는 인증이며, Playwright는 네이티브로 지원하지만 Selenium은 지원하지 않아 Selenium Wire, 확장 프로그램, 또는 CDP가 필요합니다. 아키텍처를 결정해야 할 차이는 격리 비용입니다. Playwright 컨텍스트는 저렴하므로 컨텍스트 단위로 아이덴티티를 로테이션하고, Selenium 프록시는 드라이버에 묶여 있으므로 드라이버를 재사용하고 아이덴티티 변경을 배치로 처리합니다. 두 경우 모두 로케일과 타임존을 출구 지역에 맞추고, GB당 비용이 발생하므로 불필요한 리소스를 차단하고, 무엇을 신뢰하기 전에 출구 주소를 확인하세요.
두 프레임워크 모두 동일한 레지덴셜 프록시에서 작동합니다. 국가와 도시 타겟팅, 플로우가 필요할 때의 고정 세션을 제공하는 하나의 게이트웨이이며, GB당 과금되므로 위에서 다룬 리소스 차단이 곧바로 더 적은 청구액으로 이어집니다.