인터넷에 떠도는 “Scrapy vs. Selenium” 가이드는 결국 비슷한 얘기로 귀결됩니다. Scrapy는 더 빠르고, Selenium은 JavaScript를 처리하고, 나머지는 상황에 맞게 고르라는 식이죠. 큰 방향은 맞지만, “페이지 수/분” 같은 흔한 수치가 언제나 먹히는 건 아닙니다. 처리량은 대상 사이트, 네트워크, 동시성, 브라우저 수명 주기, 대기 로직, 그리고 봇 차단 정책에 따라 크게 달라집니다.
이 가이드는 프로젝트마다 실제 결과를 갈라놓는 아키텍처와 운영상의 트레이드오프를 비교합니다. 또 대부분의 비교 글이 놓치는 부분도 다룹니다. 브라우저 자동화가 리소스 모델을 어떻게 바꾸는지, 왜 전체를 브라우저로 렌더링하는 것보다 선택적 렌더링이 더 나은 경우가 많은지, 그리고 언제는 두 프레임워크보다 관리형 추출 API가 더 잘 맞는지까지 살펴봅니다.
2026년 기준 간단 결론: Scrapy vs. Selenium
짧게 말하면 이렇습니다. 서버 렌더링 페이지라면 속도, 확장성, 자원 효율성에서 Scrapy가 유리합니다. 반대로 실제 브라우저로 클릭, 입력, 모달 대기 같은 동작이 필요하면 Selenium이 강합니다. 하지만 요즘의 봇 차단 방어를 기본 상태 그대로 뚫는 데는 둘 다 별로 강하지 않고, Playwright가 예전에는 Selenium을 쓰던 많은 사례를 조용히 대체해 왔습니다.
제가 실제로 쓰는 의사결정표는 아래와 같습니다:
| 상황 | 추천 |
|---|---|
| 정적 페이지 또는 서버 렌더링 페이지, 대량 처리 | Scrapy |
| JS 비중이 큰 SPA, 로그인, 클릭, 다단계 흐름 | Selenium 또는 Playwright |
| 혼합형 사이트 — 대부분은 정적, 일부만 JS 전용 | Scrapy-Playwright 하이브리드 |
| URL이 이미 정해져 있고, 구조화된 데이터만 필요하며 유지보수는 최소화하고 싶을 때 | AI 추출 API (Thunderbit 등) |
2026년 중반 기준으로 Scrapy 2.17.0을 사용할 수 있고, Selenium 4는 WebDriver BiDi 지원을 계속 확장하고 있습니다. 또한 scrapy-playwright는 선택한 Scrapy 요청만 브라우저로 보내는, 관리되는 방식의 솔루션을 제공합니다. 일단 이 표를 기억해 두세요. 아래에서 그 이유를 설명하겠습니다.
Scrapy와 Selenium이란 무엇이며, 개발자들이 왜 아직도 이 둘을 비교할까
Scrapy와 Selenium을 비교하는 건 배송 트럭과 승용차를 비교하는 것과 비슷합니다. 둘 다 A에서 B로 무언가를 옮기지만, 하나는 대량 운반에 효율적으로 설계됐고, 다른 하나는 사람이 실제로 조작하며 도로와 상호작용하도록 만들어졌습니다. 이 논쟁이 계속되는 이유는 둘 다 스크래핑은 할 수 있기 때문입니다. 다만 서로 다른 목적을 위해 만들어졌고, 많은 팀이 그 차이를 체감하기 전에 잘못된 도구를 먼저 고르기 때문입니다.
Scrapy: 비동기 크롤링 엔진
Scrapy는 Twisted의 이벤트 기반, 논블로킹 I/O 모델 위에 구축된 Python 전용 프레임워크입니다. 브라우저가 아니며, 애초에 브라우저를 목표로 하지도 않았습니다. HTTP 요청을 보내고 돌아온 HTML을 파싱할 뿐입니다. 핵심은 바로 이 단순함에 있습니다. 브라우저가 렌더링을 끝낼 때까지 기다릴 필요가 없기 때문에, 여러 요청을 동시에 막힘 없이 처리할 수 있습니다.
Scrapy에는 기본적으로 spider, item pipeline, feed exporter, retry middleware, rate limiting 기능이 포함돼 있습니다. 즉, “이걸 직접 다 만들어야 하나?” 하고 걱정할 필요가 없는 프레임워크입니다. 운영 환경에서 필요한 많은 요소가 이미 갖춰져 있습니다. Scrapy의 아키텍처 문서는 Engine, Scheduler, Downloader, Item Pipeline을 분리된 교체 가능한 구성 요소로 설명하는데, 이것이 프레임워크가 오래 살아남은 이유이기도 합니다. 핵심을 다시 쓰지 않고도 기능을 덧붙일 수 있기 때문입니다.
단점도 있습니다. 브라우저가 없으니 JavaScript 실행도 없습니다. 페이지 렌더링 후 클라이언트 측 fetch 호출로 데이터가 로드된다면, Scrapy는 그 내용을 보지 못합니다. 초기 HTML 응답만 읽고 끝입니다.
Selenium: 프로그래밍 가능한 브라우저
Selenium은 W3C WebDriver 프로토콜을 통해 Chrome, Firefox, Edge 같은 실제 브라우저를 제어합니다. 이 표준 사양 덕분에 Selenium은 특정 언어나 브라우저에 종속되지 않습니다. Chrome 전용 꼼수가 아니라는 뜻입니다. JavaScript를 렌더링하고 AJAX 호출을 실행하며, 사람처럼 클릭, 스크롤, 입력도 할 수 있습니다.
그래서 Selenium은 상호작용이 중요한 작업에 적합합니다. 다단계 로그인, 마법사형(wizard) 흐름, 무한 스크롤, API 호출을 유발하는 드롭다운 메뉴 같은 경우죠. 하지만 이런 브라우저 세션은 전부 무겁습니다. Selenium의 Grid 용량 가이드는 계획 단계에서 브라우저 세션당 대략 1GB RAM을 잡으라고 권장합니다. 그리고 여기에 실제 렌더링으로 인한 CPU 부담까지 더해져야 합니다.
사람들이 자주 헷갈리는 부분이 하나 더 있습니다. 페이지 로딩 완료가 UI 준비 완료를 뜻하는 건 아닙니다. Selenium 문서도 implicit wait와 explicit wait를 섞지 말라고 경고하는데, 그렇게 하면 타임아웃이 금방 예측 불가능해지기 때문입니다. Selenium 스크립트가 불안정하다면, 보통 이게 이유입니다.
Scrapy vs. Selenium: 가짜 보편 숫자 없이 성능 보기
신뢰할 수 있는 벤치마크라면 대상 페이지, 캐시 상태, 네트워크 조건, 동시성, 브라우저 재사용 방식, 대기 조건, 그리고 전체 코드를 공개해야 합니다. 이 맥락이 없으면 분당 페이지 수는 증거가 아니라 마케팅입니다. 그래도 아키텍처 비교는 여전히 유효합니다.
| 작업 특성 | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| 서버 렌더링 HTML | 직접 HTTP 경로 | 전체 브라우저 경로 | Scrapy의 직접 경로 사용 |
| JavaScript 렌더링 콘텐츠 | 추가 렌더러 필요 | 브라우저가 직접 실행 | 필요한 페이지만 선택적 렌더링 |
| 동시성 모델 | 비동기 요청 스케줄러 | 코드 또는 Grid가 관리하는 브라우저 세션 | Scrapy 스케줄러 + 브라우저 컨텍스트 |
| 자원 프로필 | 브라우저 렌더링 오버헤드 없음 | 브라우저 CPU 및 메모리 오버헤드 | 렌더링이 필요한 요청만 브라우저 비용 발생 |
| 측정 방식 | 안전한 오류율 기준의 분당 아이템 수 | 안전한 오류율 기준의 분당 완료 흐름 수 | 정적 요청과 렌더링 요청 처리량을 분리 측정 |
Scrapy의 기본 동시 요청 수치는 처리량 보장이 아니라 상한선입니다. 실제 속도는 지연 시간, 도메인별 제한, 스로틀링, 재시도, 응답 크기, 파싱 작업량, 그리고 대상 사이트가 허용하는 요청 속도에 의해 결정됩니다. Selenium은 브라우저 세션을 재사용할 수 있으므로, 페이지마다 새 브라우저를 띄워야 하는 구조는 아닙니다. 다만 활성 세션 하나하나가 여전히 브라우저 환경을 실행하고 렌더링한다는 점은 변하지 않습니다.
하이브리드 모델이 매력적인 이유는 일반 요청은 Scrapy의 HTTP 경로로 처리하고, 렌더링이 필요한 페이지만 브라우저로 보내기 때문입니다. 보통은 브라우저 작업량이 줄지만, 무조건 더 빠른 건 아닙니다. 정적 경로와 렌더링 경로를 따로 측정하고, 실패율과 재시도율도 포함해, 대상 사이트 안전성과 가용 메모리를 모두 기준으로 동시성을 조정해야 합니다.
의사결정을 좌우하는 핵심 차이
속도만이 전부는 아닙니다. 실제 운영에 들어가면 몇 가지 실용적인 요소가 훨씬 중요해집니다.
JavaScript 렌더링과 동적 콘텐츠
Scrapy 단독으로는 클라이언트 측에서 렌더링되는 내용이 보이지 않습니다. Selenium은 실제 브라우저이기 때문에 모든 것을 볼 수 있습니다. 중간 지점으로는 Scrapy-Splash(구형, Lua 스크립트 기반)와 scrapy-playwright(현대적이고 권장됨)가 있습니다. 이들은 모든 요청을 브라우저로 돌리지 않고, Scrapy의 크롤링 루프 안에서 필요한 요청만 선택적으로 렌더링하게 해줍니다. 대상 페이지의 80~90%가 정적 HTML이고 일부만 JS가 필요하다면, 선택적 렌더링이 당연한 선택입니다. 일부 페이지 때문에 전부를 브라우저로 돌리는 건 계산 자원 낭비입니다.
확장성과 동시성
Scrapy를 1,000페이지에서 1,000,000페이지로 확장하는 건 주로 인프라 문제입니다. 동시 요청을 늘리고, 필요하면 Redis로 워커를 분산하면 됩니다. 반면 Selenium을 확장하려면 브라우저 인스턴스를 선형으로 늘려야 하고, 그만큼 RAM과 CPU도 선형으로 증가합니다. 결국 Selenium Grid를 쓰는 브라우저 팜을 운영하면서 장애 복구까지 챙겨야 합니다. Selenium이 확장 불가능하다는 뜻은 아닙니다. 다만 확장은 설정 변경이 아니라 인프라 프로젝트라는 뜻입니다.
데이터 파이프라인과 내보내기
Scrapy의 item pipeline은 검증, 중복 제거, JSON/CSV/DB 내보내기를 기본 기능으로 처리합니다. Selenium은 이런 기능이 전혀 없습니다. 직렬화와 저장 로직을 전부 직접 작성해야 합니다. 데이터 품질과 후속 시스템 연동이 중요하다면, Scrapy가 공짜로 제공하는 이 출발점은 꽤 큽니다.
유지보수와 장기 안정성
제가 관찰한 패턴 하나가 있습니다. Scrapy 스파이더는 미들웨어 기반 구조 덕분에 비교적 오래 버티는 편입니다. 반면 Selenium 스크립트는 쉽게 깨집니다. 브라우저 업데이트가 드라이버를 망가뜨리고, 타이밍 문제로 실행이 들쭉날쭉해지고, DOM이 조금만 바뀌어도 셀렉터를 고쳐야 합니다. 포럼에서 “클라이언트에게 판매할 무언가를 만드는 데는 Selenium이 최선은 아닌 것 같다”는 말을 개발자들이 직접 하는 걸 봤는데, 솔직히 프로젝트가 몇 달 이상 손대지 않은 상태로 버텨야 한다면 그 판단은 맞습니다.
봇 차단 현실 점검: 2026년 방어 체계 앞에서 각 도구는 얼마나 버티나
이 부분은 다른 비교 글들이 대부분 퉁치는 내용이고, 실제로 스크래퍼가 작동할지 여부를 결정하는 핵심이기도 합니다. Scrapy든 Selenium이든 최신 봇 차단 인프라를 염두에 두고 만들어진 건 아닙니다. 그렇지 않다고 가정하는 순간, 운영 단계에서 크게 당황하게 됩니다.
| 방어 계층 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| JS 렌더링 | ❌ 미들웨어 필요 | ✅ | ✅ | ✅ 내장 |
| TLS 지문 | ⚠️ 탐지 가능 | ⚠️ 탐지 가능 | ⚠️ 더 나음, 하지만 완전 해결은 아님 | ✅ 처리됨 |
| CAPTCHA 해결 | ❌ 수동 | ❌ 수동 | ❌ 수동 | ✅ 내장 |
| 속도 제한 회전 | ⚠️ 프록시 직접 구현 | ⚠️ 프록시 직접 구현 | ⚠️ 프록시 직접 구현 | ✅ 관리형 |
Scrapy는 실제 브라우저가 없기 때문에 브라우저 지문 검사에서 바로 걸립니다. 애초에 지문을 남길 브라우저가 없으니, 단순 HTTP 클라이언트처럼 보일 뿐이고, 많은 봇 차단 업체는 이런 트래픽을 실제 브라우저 트래픽으로 보지 않습니다. Selenium은 실제 브라우저이므로 기본적인 JS 검사는 통과하지만, navigator.webdriver 같은 신호로 탐지될 수 있습니다. 이 값은 자동화 환경에서는 true로 표시되는 표준 플래그입니다. undetected-chromedriver 같은 패치는 이를 가리려 하지만, 시그니처를 계속 업데이트하는 탐지 업체와 끝없는 숨바꼭질을 할 뿐입니다.
스텔스 경쟁과 DIY의 취약성
안티 디텍션 패치에 대한 불편한 진실은 이겁니다. 해결책이라기보다 유지보수용 러닝머신에 가깝다는 점입니다. undetected-chromedriver와 playwright-stealth도 Cloudflare Turnstile이나 DataDome가 업데이트를 내놓아 자신들의 기법을 잡아내는 순간까지는 잘 작동합니다. 그러면 다시 패치해야 합니다. 실제 스크래퍼를 만드는 데 쓴 시간보다 스텔스 계층을 유지하는 데 더 많은 엔지니어링 시간을 쓰는 팀도 봤습니다.
속도 제한도 따로 짚고 넘어가야 합니다. 서버가 429 Too Many Requests를 반환할 때 Retry-After 헤더는 권고사항일 뿐 강제 명령은 아닙니다. 많은 사이트가 이 헤더를 아예 보내지 않으며, 어떤 사이트는 다른 신호로 조용히 속도를 제한하기도 합니다. Scrapy의 AutoThrottle은 관찰된 지연 시간에 따라 딜레이를 조정해 도움을 주지만, 예방이 아니라 사후 대응입니다.
이 지점에서 관리형 추출 API의 가치가 드러납니다. 봇 차단 처리는 더 이상 여러분의 엔지니어링 문제가 아닙니다. 아래에서 더 이야기하겠습니다.
Playwright의 등장: 왜 이제는 “Scrapy vs. Selenium”만으로 부족한가
이걸 두 도구의 싸움으로만 보는 건 최근 몇 년간 스크래핑 커뮤니티에서 실제로 일어난 변화를 놓치는 겁니다. 개발자 포럼에는 “Selenium에서 Playwright로 갈아탔는데 꽤 만족스럽다”는 식의 이야기가 넘치지만, 대부분의 비교 글은 Playwright를 한 번 언급하고 지나가거나 아예 빼버립니다.
Microsoft가 만든 Playwright는 하나의 API로 Chromium, Firefox, WebKit을 제어합니다. actionability 모델은 동작을 수행하기 전에 요소가 보이고, 안정적이며, 실제로 상호작용 가능한 상태인지 기다립니다. 그래서 많은 Selenium 스크립트를 괴롭히는 타이밍 불안정성이 크게 줄어듭니다. 또한 browser context를 더 효율적으로 다뤄, 매번 완전히 새 브라우저를 띄우지 않고도 분리된 세션을 쉽게 만들 수 있습니다.
Selenium을 완전히 대체하는 경우
브라우저 테스트용 기존 Selenium 인프라가 아니라, 순수한 스크래핑 용도라면 2026년에는 Playwright가 더 나은 선택인 경우가 많습니다. 컨텍스트 생성이 더 빠르고, 페이지당 자원 사용량이 낮고, 비동기 지원이 기본이며, 네트워크 인터셉션도 내장돼 있습니다. 기존 Selenium 테스트 스위트를 보존할 필요가 없는 새 스크래핑 프로젝트라면, 먼저 Selenium을 고를 이유가 많지 않습니다.
예외는 있습니다. 팀에 이미 Selenium 기반 테스트 인프라가 있거나, Playwright가 깔끔하게 지원하지 않는 아주 특정한 브라우저 프로필 커스터마이징이 필요하다면 Selenium도 여전히 제 몫을 합니다.
scrapy-playwright는 어떻게 동작하나
scrapy-playwright는 Scrapy용 다운로드 핸들러로, meta={"playwright": True}가 붙은 요청만 실제 브라우저로 보내고 나머지는 Scrapy의 빠른 비동기 HTTP 경로에 그대로 남겨 둡니다. 아래는 상품 카드가 클라이언트 측 JS로 렌더링되는 페이지네이션 카탈로그를 크롤링하는 단순화된 spider 예시입니다.
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
실제로 렌더링이 필요한 페이지만 브라우저를 거칩니다. 이것이 하이브리드 접근의 핵심입니다. 모든 요청에 대해 브라우저 비용을 치르는 게 아니라, 꼭 필요한 요청에만 비용을 지불하는 것이죠.
Scrapy-Splash vs. Scrapy-Playwright: 어떤 미들웨어를 써야 할까
Scrapy-Splash는 별도의 Splash Docker 서비스를 띄우고, 상호작용을 위해 Lua 스크립트를 작성해야 합니다. 작동은 하지만 구조가 더 무겁고 오래된 방식입니다. 반면 scrapy-playwright는 Scrapy의 비동기 이벤트 루프에 직접 통합되고, 세 가지 주요 브라우저 엔진을 모두 지원하며, 별도의 스크립팅 언어를 덧붙이지 않고도 복잡한 상호작용을 처리합니다. 2026년에 새 프로젝트를 시작한다면, 이제 Splash를 고를 이유는 거의 없습니다.
운영 가능한 하이브리드 아키텍처
대부분의 글은 “Scrapy와 Selenium을 함께 쓸 수 있다”고만 말하고 끝냅니다. 그건 아키텍처가 아닙니다. 그냥 제안일 뿐이죠. 실제 운영 환경에서는 이렇게 구성됩니다.
흐름은 다음과 같습니다. Scrapy 스케줄러가 URL 라우터로 요청을 보내고, 라우터는 페이지가 정적인지 동적인지 판별합니다. 정적 요청은 Scrapy의 표준 다운로드기로 바로 전달됩니다. 동적 요청은 태그가 붙어서 Playwright 미들웨어로 라우팅되고, 여기서 브라우저 컨텍스트 풀을 관리합니다. 두 경로는 다시 같은 item pipeline으로 합쳐져 검증, 중복 제거, 내보내기를 수행합니다. 데이터가 원시 HTML에서 왔든 렌더링된 DOM에서 왔든 최종 출력은 같은 JSON, CSV, 또는 DB입니다.
프로덕션에 올릴 때는 몇 가지 배포 팁도 있습니다. Playwright 브라우저 바이너리가 환경마다 일관되게 배포되도록 Docker로 컨테이너화하고, 사용 가능한 RAM 기준으로 Playwright 컨텍스트 동시 개수를 제한하세요. 저는 보통 일반적인 4GB 머신에서는 8~10개를 넘기지 않습니다. 또 작업은 무기한 프로세스로 두기보다 cron이나 CI/CD 파이프라인을 통해 스케줄링하는 편이 낫습니다.
이 구성은 제어력이 최대라는 장점이 있습니다. 하지만 브라우저 바이너리 업데이트, 컨텍스트 수명 주기 버그(페이지를 닫지 않으면 크롤링이 멈출 수 있음), 프록시 회전, 그리고 필요한 봇 차단 우회 패치까지 모두 여러분 책임이라는 뜻이기도 합니다. 이건 분명한 엔지니어링 투자이며, 시작하기 전에 그 무게를 솔직히 인정하는 게 좋습니다.
이 인프라를 직접 떠안지 않고 구조화된 출력을 원한다면, Thunderbit의 CLI는 같은 문제를 다른 방식으로 해결합니다:
thunderbit batch extract --schema schema.json --file urls.txt
같은 구조화된 JSON 출력. spider 코드도 없고, 브라우저 풀도 없고, 봇 차단용 연결도 유지할 필요가 없습니다. 대신 커스터마이징 일부를 속도와 배포 편의성으로 바꾸는 셈입니다. 이는 보편적으로 더 좋은 선택이 아니라 정당한 트레이드오프이며, 프로젝트에 실제로 어느 정도 제어가 필요한지에 따라 달라집니다.
“프레임워크를 건너뛰는” 경로: AI 스크래핑 API가 두 도구를 모두 이길 때
어느 순간 개발자는 자신이 사실 크롤링 프레임워크가 필요하지 않다는 걸 깨닫습니다. 이미 알려진 500개 URL에서 구조화된 데이터만 뽑아야 하는데, 이를 위해 spider, 브라우저 풀, 봇 차단 계층까지 만드는 건 과합니다. 실제로 대부분 그렇습니다.
바로 그 공백을 메우기 위해 Thunderbit가 만들어졌습니다. 단, 미리 분명히 하자면 복잡한 재귀형 커스텀 크롤링에서 Scrapy를 대체하는 도구는 아닙니다. 더 좁고 구체적인 문제를 위한 다른 도구입니다.
Open API: POST /extract는 JSON Schema를 입력받아 그 스키마에 맞는 구조화된 데이터를 반환합니다. 원본 HTML도 아니고, 직접 파싱해야 하는 마크다운 덩어리도 아닙니다. POST /distill은 반대로 동작해, RAG 파이프라인이나 LLM에 바로 넣을 수 있는 깔끔한 Markdown을 돌려줍니다. 관리형 서비스가 JavaScript 렌더링과 봇 차단 처리를 지원하므로, 그런 인프라를 직접 관리할 필요가 없습니다. 현재 Distill vs. Extract 가이드에 따르면 Distill은 페이지당 1 크레딧, Extract는 페이지당 20 크레딧이 소요됩니다. 제품 조건은 바뀔 수 있으니 예산을 잡기 전 최신 문서를 꼭 확인하세요.
MCP Server: Claude나 Cursor 같은 AI 에이전트를 위해 Thunderbit의 MCP server는 distillation, 구조화된 추출, 필드 제안, 배치 작업을 도구 형태로 제공합니다. 에이전트가 작업 도중 환경을 벗어나지 않고도 최신 웹 데이터를 끌어올 수 있게 해줍니다.
CLI: 공식 Thunderbit CLI는 thunderbit extract <url> --schema schema.json 같은 명령을 지원하며, 터미널 워크플로와 예약 작업에 자연스럽게 들어맞습니다. 간단한 일회성 조사 작업이라면 distilled Markdown을 다른 도구에 파이프해서 쓸 수도 있습니다.
코드 자체를 아예 건너뛰고 싶다면, Thunderbit Chrome Extension도 같은 영역을 클릭 몇 번으로 처리합니다. 터미널을 만질 필요 없이 데이터를 써야 하는 비개발자 팀이 있다면 충분히 살펴볼 만합니다. 더 넓은 관점이 궁금하다면 AI 웹 스크래핑과 코딩 없이 웹 스크래핑하기에 대해 더 자세히 쓴 글도 있습니다.
어느 쪽에 속하는지 솔직하게 생각해 보세요. 복잡한 다중 사이트 크롤링과 커스텀 로직, 재귀적 링크 추적이 필요하다면 여전히 Scrapy가 정답입니다. 상호작용이 많은 흐름이라면 Selenium이나 Playwright가 맞습니다. 하지만 “이미 정해진 URL에서 구조화된 데이터만 뽑아야 한다”는 문제는 두 도구가 원래 해결하려던 범위보다 훨씬 좁습니다. API를 쓰면 spider 코드, 봇 차단 연결, 그리고 그 인프라를 직접 떠안는 유지보수 부담까지 정말로 없앨 수 있습니다.
Scrapy vs. Selenium vs. Playwright vs. AI API: 한눈에 비교
| 기능 | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| 언어 지원 | Python 전용 | Python, Java, C#, JS, Ruby | Python | REST(언어 무관) |
| JS 렌더링 | 아니오(미들웨어 필요) | 예 | 예 | 예, 내장 |
| 비동기/동시성 | 기본 제공, 고성능 | 인스턴스당 제한적 | Scrapy를 통해 기본 제공 | 서버 측 관리형 |
| 봇 차단 처리 | 직접 구현 | 직접 구현 | 부분적 | 내장 |
| 데이터 파이프라인/내보내기 | 기본 제공 | 직접 구현 | 기본 제공 | 구조화된 JSON 출력 |
| 설정 복잡도 | 중간 | 시작은 쉬움, 규모가 커질수록 복잡 | 중간~높음 | 매우 낮음 |
| 유지보수 부담 | 낮음~중간 | 높음 | 중간 | 거의 없음 |
| 최적 용도 | 대량 정적 크롤링 | 상호작용 중심 흐름 | 정적/동적 혼합 사이트 | 알려진 URL, 구조화 출력 |
이 네 가지 외의 다른 스크래퍼도 고민 중이라면 Instant Data Scraper 대안과 최고의 AI 웹 스크래퍼도 살펴볼 만합니다. 시장이 많이 붐볐고, 모든 도구가 같은 문제를 해결하는 건 아니니까요.
2026년 웹 스크래핑의 법적·윤리적 메모
이 글의 핵심은 아니니 짧게만 말하겠습니다. 그래도 중요합니다. Scrapy의 ROBOTSTXT_OBEY 설정은 spider가 robots.txt 규칙을 따르도록 합니다. 좋은 관행이긴 하지만, Robots Exclusion Protocol 자체가 그 규칙을 법적 접근 허가로 보장하는 것은 아니라는 점도 알아두세요. Selenium과 Playwright는 robots.txt 준수를 기본 제공하지 않습니다. 그건 전적으로 여러분이 구현해야 합니다. 어떤 도구를 쓰든, 데이터를 스크래핑하고 재사용하기 전에 해당 사이트의 이용약관과 관할 지역의 법률을 확인하세요. “공개되어 보인다”는 이유만으로 어디서나 자동으로 합법이 되는 것은 아닙니다.
2026년 스크래핑 프로젝트에 맞는 도구 고르기
결정은 결국 네 가지 질문으로 귀결됩니다. 콘텐츠 유형은 무엇인지, 규모는 어느 정도인지, 상호작용이 얼마나 필요한지, 그리고 얼마나 지속적인 유지보수를 감수할 의향이 있는지입니다. 대규모 정적 페이지라면 Scrapy를 쓰세요. 상호작용이 많은 JS 페이지라면 Selenium이나 Playwright가 맞습니다. 둘이 섞여 있다면 하이브리드로 가세요. 이미 URL이 정해져 있고 구조화된 데이터만 필요하며 유지보수는 최소화하고 싶다면, Thunderbit 같은 API가 드는 시간보다 아껴주는 시간이 더 많을 가능성이 큽니다.
“Scrapy vs. Selenium”은 원래부터 전체 질문이 아니었습니다. 다만 예전에는 그게 유일한 프레임이었을 뿐이죠. Playwright가 중간 지대를 바꿔 놓았고, AI 추출 API는 사실상 인프라를 만드는 일과 비즈니스 문제를 해결하는 일을 구분해 주는 새로운 선택지를 열었습니다. 어느 길이든 바로 커밋하기 전에 무료 플랜부터 써 보는 걸 권합니다. suggest-fields는 무료이고 distill은 1크레딧만 사용하므로, spider 코드를 한 줄도 쓰기 전에 API 방식이 맞는지 감으로라도 확인할 수 있습니다.
자주 묻는 질문
웹 스크래핑에서 Scrapy가 Selenium보다 더 빠른가요? 제 테스트 기준으로는 그렇습니다. 정적 페이지에서는 대개 한 자릿수 이상 차이로 빠릅니다. Scrapy의 비동기 아키텍처는 브라우저 오버헤드를 완전히 건너뛰기 때문입니다. Scrapy가 JS가 많은 페이지에서 Playwright 미들웨어를 사용할 때는 그 격차가 줄어들지만, JS가 없는 페이지는 계속 빠른 경로로 처리되기 때문에 혼합 워크로드에서는 여전히 Scrapy가 전체 처리량에서 앞서는 경우가 많습니다.
Scrapy로 JavaScript 렌더링 페이지를 처리할 수 있나요?
단독으로는 어렵습니다. Scrapy는 초기 HTML 응답만 봅니다. scrapy-playwright나 구형 Scrapy-Splash를 미들웨어로 추가하면, 특정 요청만 실제 브라우저로 렌더링하면서 나머지는 Scrapy의 기본적이고 더 빠른 경로로 유지할 수 있습니다.
언제 Scrapy 대신 Selenium을 써야 하나요? 다단계 로그인, 위저드 클릭, 폼 입력처럼 완전한 브라우저 상호작용이 필요하고, 페이지 수가 아주 많지 않을 때입니다. 또한 Selenium 기반 테스트 인프라가 이미 있고 이를 스크래핑에도 재사용하고 싶을 때도 합리적인 선택입니다.
2026년에는 Selenium보다 Playwright가 스크래핑에 더 좋은가요? 스크래핑 용도만 보면 대체로 그렇습니다. Playwright는 더 나은 성능, 기본 자동 대기(auto-wait), 브라우저 컨텍스트당 더 가벼운 자원 사용량을 제공하는 경우가 많습니다. 다만 기존 크로스 브라우저 테스트 스위트를 이미 운영 중인 팀에게는 Selenium이 여전히 장점이 있습니다. Playwright는 그 인프라를 대체하려고 만들어진 건 아니니까요.
AI 스크래핑 API란 무엇이고, 언제 Scrapy나 Selenium을 대체하나요? Thunderbit의 Open API 같은 AI 스크래핑 API는 서버 측에서 JS 렌더링, 봇 차단 방어, 데이터 추출을 처리하고, 여러분이 정의한 스키마에 맞는 구조화된 JSON을 반환합니다. 이미 알려진 URL에서 구조화된 결과만 필요하고 크롤링 인프라를 직접 만들거나 유지보수하고 싶지 않을 때 적합합니다. 복잡하고 재귀적인 커스텀 크롤링에서 Scrapy를 대체하는 도구는 아닙니다.
더 알아보기
