Scrapling 리뷰: 더 빠르고 더 은밀한 Python 스크래핑

Python 웹 스크래핑은 대략 네 시대를 거쳐 왔습니다. urllib과 정규식. 그다음 requests + BeautifulSoup. 그다음 진지한 작업은 전부 Scrapy. 그리고 웹의 절반이 JavaScript-only로 넘어가면서 앞의 셋이 절벽 아래로 떨어지고 Playwright가 그 자리를 차지했습니다.

Scrapling은 이 스택 위에 또 한 층을 쌓으려는 비교적 새로운 라이브러리 중 하나입니다. 간단한 페이지, JS가 무거운 페이지, 그리고 봇 차단으로 보호된 페이지까지 — 세 가지 케이스를 한 라이브러리에서 다루고, 세 가지 다른 라이브러리를 꿰매 붙이지 않아도 되게 만드는 것을 목표로 합니다.

저는 이 프로젝트와 벤치마크, API를 한 차례 훑어봤습니다. 아래는 무엇이 진짜 흥미로운지, 무엇을 조심해야 하는지, 그리고 명백한 대안 대신 이걸 선택할 만한 상황에 대한 정리입니다.

한 문장 정의

Scrapling은 Python 3.10+ 스크래핑 프레임워크로, 세 가지 다른 페치 백엔드 — TLS 핑거프린트 위장이 들어간 일반 HTTP, 안티 디텍션이 적용된 stealth 모드 브라우저, 그리고 풀 Playwright 브라우저 — 를 동일한 셀렉터 API 뒤에 감싸 놓은 것입니다. 라이선스는 BSD-3-Clause.

저장소의 태그라인은 “Effortless Web Scraping for the Modern Web” 인데, 이런 류의 문구는 모든 스크래핑 라이브러리가 합니다. 더 유용한 표현은 이쪽입니다: Scrapy의 spider 모델 + curl_cffi 의 TLS 핑거프린팅 + 디텍션을 피하는 Playwright를 한 번의 import 안에 합치려고 한 것.

세 단계 페처 모델

이 부분이 디자인에서 진짜 잘 만들어졌다고 느낀 곳입니다. 대부분 의 스크래핑 프로젝트는 결국 누더기가 됩니다 — 빠른 페이지엔 requests, JS가 무거운 페이지엔 Selenium이나 Playwright, 보호된 페이지엔 직접 짠 CDN 우회 코드. Scrapling은 이걸 세 계층으로 분리하면서도 응답 객체 모양은 통일해 둡니다:

같은 Spider 클래스 안에서 요청마다 다른 계층을 지정할 수 있습니다. README의 예제를 보면:

async def parse(self, response: Response):
    for link in response.css('a::attr(href)').getall():
        if "protected" in link:
            yield Request(link, sid="stealth")
        else:
            yield Request(link, sid="fast", callback=self.parse)

이게 왜 중요한지: 실제 크롤에서 무거운 백엔드가 정말 필요한 페이지는 일부에 불과합니다. 하지만 도중에 다시 짜기 귀찮아서 보통은 모든 페이지에 브라우저 비용을 그대로 지불하게 됩니다. 하나의 spider가 계층을 섞어 쓸 수 있다는 건, 평균 페이지 비용을 낮춰준다는 뜻입니다.

벤치마크, 약간의 의심과 함께

README는 5,000개의 중첩 요소를 파싱하는 숫자를 공개합니다:

여기서 정직한 두 가지 해석:

예, BeautifulSoup은 실제로 그만큼 느립니다. 오타가 아닙니다. BS4는 사용성 우선 라이브러리이고, 많은 문서를 빡빡한 루프로 도는 작업에서는 lxml 기반 파서(Scrapling, Parsel, raw lxml 모두) 가 몇 자릿수 빠릅니다. 이건 알려진 결과지, Scrapling의 고유한 발견은 아닙니다.

아니요, 파서 레이어에서 Scrapling이 실제로 Scrapy보다 빠르진 않습니다. 표를 보세요. Scrapy가 쓰는 Parsel은 2.04 ms, Scrapling은 2.02 ms. 마이크로벤치마크의 오차 범위 안입니다. “BS4보다 몇 자릿수 빠름"은 사실이지만 “Scrapy보다 빠름"은 파싱 레이어에서는 사실이 아닙니다.

Scrapling이 실제 워크로드에서 분명히 이기는 곳은 네트워크 레이어입니다 — Fetcher의 TLS 핑거프린트 위장 덕분에 “기본 JA3 핑거프린팅을 통과하기 위해 Playwright를 끼워 넣는” 비용을 건너뛸 수 있습니다. 절약 단위가 마이크로초가 아니라 초입니다.

적응형 셀렉션 — 흥미로운 아이디어

스크래핑의 진짜 고통은 첫 셀렉터를 짜는 게 아니라, 3주 뒤 대상 사이트가 클래스 이름을 바꿔서 셀렉터가 망가지는 일입니다. Scrapling이 이 부분에서 내세우는 건 “smart element relocation after website changes using similarity algorithms”(유사도 알고리즘으로 사이트 변경 후 요소를 재배치) — 즉 원래 셀렉터가 실패했을 때, 라이브러리가 이전에 캡처한 구조와의 구조적 유사도를 비교해 요소를 다시 찾으려 시도한다는 뜻입니다.

이 부분은 조심스럽게 낙관적으로 봅니다. 누구나 원하는 기능입니다. 실무에서는 외형적 변경(클래스 이름 변경, 래퍼 div 추가) 에는 유사도 기반 재배치가 잘 동작할 거고, 의미적 재구성 (데이터가 다른 페이지로 이동, 섹션 자체가 새로 템플릿화됨)에는 실패할 겁니다. “클래스 이름 하나 바뀐 것 때문에 새벽 세 시에 일어나는 걸 막아주는” 기능으로 받아들이고, “스크래퍼가 이제 스스로 유지보수된다"라는 기능으로 오해하지 마세요.

가장 단순하게 동작하는 코드

문서에서 그대로 가져온, 가장 작은 예제는 이렇습니다:

from scrapling.fetchers import Fetcher, FetcherSession

with FetcherSession(impersonate='chrome') as session:
    page = session.get('https://quotes.toscrape.com/', stealthy_headers=True)
    quotes = page.css('.quote .text::text').getall()

끝입니다. “Chrome의 TLS 핑거프린트로 페치하고 파싱하기"가 세 줄. impersonate='chrome' 파라미터가 curl_cffi 스타일의 핑거 프린트 위장입니다. 대상 사이트가 기본 핑거프린트 기반의 봇 디텍션을 쓸 때 유용합니다.

Cloudflare로 보호된 페이지의 경우:

from scrapling.fetchers import StealthyFetcher

page = StealthyFetcher.fetch('https://nopecha.com/demo/cloudflare')
data = page.css('#padded_content a').getall()

StealthyFetcher는 별도 브라우저 설치가 필요합니다:

pip install "scrapling[fetchers]"
scrapling install

scrapling install 단계에서 패치된 Chromium 바이너리를 받아 옵니다. 새 서버 기준 수백 MB 의존성이라서, 작은 VM에 pip install 하기 전에 알아두는 게 좋습니다.

명백한 대안과의 비교

가장 정직하게 말하자면: 프로젝트의 형태가 명확할 때(예: “이미 알고 있는 사이트의 1천만 개 상품 페이지를 크롤링한다”) 그 형태에 특화된 도구를 쓰세요. 큰 규모의 규율 있는 크롤에는 Scrapy가 여전히 정답이고, 진지한 브라우저 자동화에는 Playwright가 여전히 정답입니다. Scrapling의 가치는 형태가 명확하지 않은 프로젝트, 그러니까 그렇지 않으면 세 개의 스크래퍼를 동시에 유지해야 하는 프로젝트에 있습니다.

조심해야 할 것

안티 봇 우회는 움직이는 표적입니다. README도 이 점을 솔직히 인정합니다 — 엔터프라이즈급 시스템(Akamai, DataDome, Kasada, Incapsula)은 별도 솔루션이 필요하고, 이쪽은 약속하지 않습니다. Scrapling이 실제로 타깃하는 시스템 — 특히 Cloudflare Turnstile — 에 대해서도 오늘 되는 게 다음 분기에도 된다는 보장이 없다고 생각하세요. 비즈니스가 여기에 의존한다면 “한 번 설정하고 잊자” 가 아니라 지속적인 유지보수를 예산에 넣어야 합니다.

robots_txt_obey는 기본값이 아니라 opt-in입니다. 의도된 설계 결정입니다(어떤 사용자는 robots 파일을 무시할 합당한 이유가 있죠 — 예: 자기 사이트를 크롤하는 경우). 하지만 이는 의식적으로 켜야 한다는 뜻이기도 합니다. 제3자 사이트에서 켜는 걸 잊으면, 기술적으로 후회하기 전에 법정에서 먼저 후회하게 됩니다.

은밀함 ≠ 허락. 라이브러리에는 인용할 만한 면책 조항이 있습니다:

“이 라이브러리는 교육 및 연구 목적으로만 제공됩니다. 사용함으 로써 귀하는 현지 및 국제 데이터 스크래핑 및 개인정보 보호 법률을 준수하는 데 동의합니다.”

안티 디텍션 능력은 합법적인 케이스에 유용합니다 — 연구, 아카 이빙, 접근성 스크래핑, 권한 있는 사이트 모니터링, 데이터 내보 내기를 막는 서비스에서 자기 데이터를 빼내기. 동시에 정확히 같은 능력이 광고 사기, 콘텐츠 도용, ToS 위반에 쓰입니다. 라이브러리는 당신이 어느 쪽을 하는지 신경 쓰지 않습니다. 법원과 규제기관은 신경 씁니다. “stealthy” 기능은 전동 공구처럼 다루세요 — 유용하지만, 언제 쓰지 말아야 하는지를 알아야 합니다.

제가 실제로 손이 갈 만한 케이스

Scrapling이 잘 어울린다고 생각하는 세 가지 구체적인 상황:

1. 개인 데이터 내보내기. 어떤 서비스가 당신 데이터를 가지고 있는데 진짜 export API를 안 줍니다. 진짜 브라우저로, 천천히, 상대 사이트의 레이트 리밋을 존중하면서 자기 계정을 스크랩 하기 — Scrapling의 DynamicSession이 이 일에 잘 맞습니다.

2. 두세 가지 보호 수준을 모두 겪는 작은 상업용 크롤. 일주일 짜리 프로젝트를 위해 Scrapy + Playwright + curl_cffi 파이프 라인을 설계하고 싶지는 않을 겁니다. Scrapling이 작동하는 프로토타입까지 더 빨리 데려다줍니다.

3. 연구와 아카이빙. 공개 기록 사이트, 데이터셋, 정부 포털, 뉴스 아카이브 스크랩. 대부분은 빠른 HTTP로, 몇몇 까다로운 페이지는 진짜 브라우저로 처리하고 싶은 작업.

처음부터 손이 안 갈 상황: 한 사이트를 깊이 이해하고 몇 년을 크롤 할 거면(이런 곳에선 Scrapy의 규율이 보상해 줍니다), 또는 사이트 소유자가 명시적으로 크롤하지 말라고 하는 경우(이 문제는 어떤 라이브러리도 풀 수 없습니다).

결론

Scrapling은 진짜로 존재하는, 잘 설계된 라이브러리입니다 — 헛바람도 아니고 과대 광고도 아닙니다. BeautifulSoup에 대한 벤치마크는 사실이고, Scrapy에 대한 벤치마크는 솔직히 말해 잡음 범위 안입니다. 진짜 승부수는 세 단계 페처를 가로지르는 통일된 인터페이스와, 브라우저가 필요 없는 케이스에는 브라우저를 띄우지 않게 해 주는 네트워크 레벨의 핑거프린팅입니다.

스크래핑의 진짜 어려운 문제는 풀어주지 않습니다 — 그것들은 전부 법적/윤리적 측면에 있고, 어떤 라이브러리도 거기엔 도움이 안 됩니다 — 하지만 진짜 엔지니어링 문제 하나는 깔끔하게 풀어줍니다. 지금 새로운 스크래핑 프로젝트를 시작하는데 브라우저가 필요할지 아직 모르겠다면, 출발점으로 합리적인 선택입니다.

전체 소스와 문서는 github.com/D4Vinci/Scrapling 에서 볼 수 있습니다.