7만 GitHub star를 받은 Scrapling, Cloudflare 차단 어디까지 우회할 수 있을까? 적응형 웹스크래핑

파이썬 웹 스크래핑 도구 Scrapling을 소개하는 영상입니다. 파싱 엔진·3단계 패처·스파이더 프레임워크·도구 생태계를 문서 기반으로 훑고, 실제로 안티그래비티(Antigravity)로 지마켓 데이터를 수집하는 실습까지 보여줍니다.

00:00인트로 — 왜 Scrapling인가

• 화자는 웹 스크래핑에 Scrapling을 가장 많이 사용한다. 요즘 insane-search, agent-rich 등 비슷한 도구가 많이 나왔지만 Scrapling이 가장 강력하다고 판단.
• 평소 작업 방식: 웹사이트에서 개발자 도구 → 네트워크 탭 → Fetch/XHR을 열어 데이터가 실제로 오가는 걸 분석하고, 헤더·쿠키·리퍼러·유저에이전트 정보를 넣어 쿠팡·지마켓 같은 쇼핑몰 데이터를 수집.
• 그렇게 우회해도 주기적으로 Cloudflare 안티봇(사람인지 확인)이 작동해 막힌다. Scrapling을 쓰면 웬만한 사이트는 대부분 수집 가능 — 다른 라이브러리는 일부 사이트가 안 되는 경우가 있는데, Scrapling은 '적응형 웹 스크래핑'으로 3단계를 거쳐 처음부터 리소스 많이 드는 스텔스 패처를 쓰지 않고 단계별로 접근한다.

02:56프레임워크 개요

• 구성: 적응형 파서 / 안티봇 패처 / 동시 크롤링 스파이더. 로고는 거미가 기어가는 모습.
• 화자는 개발자 도구에서 주소창 URL과 실제 데이터를 가져오는 URL이 다르다는 점을 직접 찾아 헤더를 넣곤 하는데, 이 방식의 장점은 토큰을 아낀다는 것(직접 네트워크 로그를 분석). 다만 개발자 도구가 누구에게나 편한 건 아닌데, Scrapling은 요청 주소와 헤더 정보까지 알아서 가져와 준다는 게 장점.

04:32설치 방법(pip/uv)과 핵심 장점

• 파이썬 라이브러리로 pip install / uv install로 설치. 계층화된 설치라 파서만 필요하면 파서만 설치 가능.
• 3대 축 = 파싱 + 패칭 + 크롤링 통합. 파싱 엔진은 lxml 기반(BeautifulSoup도 lxml 기반이라 어느 정도 연동), CSS·XPath 선택자 지원은 물론 웹사이트 구조 변경을 학습해 요소를 다시 찾아내는 적응형 기능 제공 — 사이트 구조가 바뀌어도 코드를 다시 짤 필요가 없다는 게 큰 장점.
• 패칭 계층은 지문 위장 클라이언트부터 Cloudflare 턴스타일을 자동 해결하는 스텔스 브라우저까지 갖춤.
• 내부적으로 CDP(크롬 개발자도구 프로토콜)를 사용해 개발자 도구 로그를 일일이 찾지 않아도 어느 정도 찾아준다. 업데이트가 매우 꾸준하다는 점도 장점.
• AI 에이전트 코딩에 쓸 때는 한 줄이면 충분 — "Scrapling을 사용해 실제 브라우저에서 사람이 요청하는 것처럼 데이터를 수집해 달라"고 하면 거의 맞게 수집해 준다.

08:09벤치마크 — 가장 빠르고 BeautifulSoup과 완벽 호환

• 중첩 요소 5,000개에서 텍스트 추출을 100회 이상 반복한 표 기준, 비교 도구 중 Scrapling이 가장 빠름. (물론 라이브러리들이 자기 소개 시 유리하게 비교하는 점은 감안) BeautifulSoup 대비 매우 빠르면서 완전 호환이라는 점도 큰 장점.

08:51파싱 엔진 — 선택자·텍스트 핸들러·CSS/XPath

• Selector: HTML 엘리먼트를 감싼 핵심 파싱 엔진. 상속이 아니라 래핑한 이유는 요소가 pickle 직렬화가 안 되기 때문. 셀렉터 리스트 전체에 CSS나 필터를 일괄 적용 가능.
• TextHandler: 파이썬 문자열의 서브클래스로, strip·replace 같은 표준 메서드가 모두 TextHandler를 반환해 체이닝이 유지되고, JSON 파싱·정규식 메서드가 추가돼 있음.
• AttributeHandler: 요소 속성을 담는 읽기 전용 매핑으로 일반 딕셔너리보다 훨씬 가볍다.
• Response: Selector를 상속한 응답 객체라 응답에서 바로 CSS 호출 가능. 속성 대부분이 지연 로딩(lazy)이라 안 쓰는 기능엔 비용을 치르지 않는 구조.
• CSS 선택자와 XPath: Parsel과 동일한 문법으로 텍스트·속성·의사요소 추출까지 지원. Scrapy 경험자는 거의 비슷한 사용법으로 쓸 수 있고 BeautifulSoup 방식도 유지 — 기존 파이썬 스크래핑 생태계 도구들과 많이 닮았다.

11:47find_similar — 랜덤 클래스명 사이트까지 잡아내는 유사 요소 탐색

• AutoScraper에서 영감을 받은 기능. 기준 요소 하나로 구조가 비슷한 요소를 전부 찾아낸다.
• 동작: 같은 깊이의 요소를 모으고 → 태그명·부모·조부모 태그가 다른 것 제거 → 속성 매칭으로 기본 20% 유사도 임계값으로 걸러냄.
• 예제: 책 제목 하나를 텍스트로 찾고 find_similar를 호출하면 나머지 책 링크들이 반환된다.
• 랜덤 클래스명 때문에 선택자가 불안정한 사이트에서 특히 강력 — 예로 네이버 쇼핑은 선택자가 다 달라 직접 코드로 구현하기 까다로운데, find_similar를 쓰면 강력하게 전처리·파싱해 준다. 적응형 기능과 결합해 유지보수 비용을 줄여준다.

13:23적응형(Adaptive) 기능 — 구조가 바뀌어도 자동 복구

• 'Adaptive Web Scraping'은 Scrapling을 수식하는 핵심 단어. 저장(save)과 매칭(match) 2단계로 작동.
• auto_save를 켜면 태그명·텍스트·속성·형제 태그·경로·부모 정보 등 고유 속성 일체가 저장소에 기록된다. (스크래핑 중 연결 끊김·메모리 오류로 데이터가 유실되는 문제와 달리, 저장소에 기록해 두므로 재사용 가능)
• 이후 사이트 구조가 바뀌어 선택자가 실패하면, adaptive 인자를 켠 선택자가 나머지 페이지 요소와 유사도 점수를 비교해 가장 높은 요소를 반환한다.
• AI 모델 없이 순수 유사도 알고리즘으로 작동 → 토큰 비용을 아껴주는 기능이기도 하다.
• 도메인 식별자 + 저장 키 조합, 그리고 커스텀 저장소를 구현하면 Redis 같은 곳에 두어 여러 머신이 데이터를 공유할 수도 있음 — "선택자 유지보수"라는 스크래핑 최대 고충을 겨냥한 설계.

15:423대 패처 — HTTP / Dynamic / Stealth (Cloudflare 우회)

• 배경: 요즘 웹은 TLS 지문·브라우저 핑거프린팅·Cloudflare 챌린지까지 다층 방어라 단순 requests 호출로는 차단되기 쉽다. Scrapling은 난이도에 따라 고르는 3가지 패처를 제공.
• 왜 3단계인가: 스텔스 패처는 브라우저를 열고 로컬 자원을 많이 써서 느려진다. 가볍게 가져올 수 있는 사이트는 가볍게 가져오게 하는 것.
• ① Fetcher (HTTP 전용): 브라우저 없이 작동. 개발자 도구 네트워크 로그를 바탕으로 요청을 보내 바로 응답을 받을 수 있음. 단점은 자바스크립트를 실행하지 못함 — 다만 JS로 로딩되는 사이트도 결국 API 주소로 데이터를 가져오므로 그 주소를 직접 넣어주면 됨. 고성능 curl 라이브러리 위에 구축된 HTTP 클라이언트이며, 가장 중요한 옵션은 impersonate — 크롬·파이어폭스·사파리의 TLS 지문을 위장(기본값 최신 크롬). 리스트를 넘기면 요청마다 무작위로 브라우저를 바꿔가며 위장. 스텔스 헤더가 기본 활성화돼 실제 브라우저 헤더와 구글 리퍼러를 자동 생성. 권장값은 타임아웃 30초, 재시도 3회 정도이고 HTTP/3 지원 인자도 하나로 켤 수 있음. 정적 페이지와 JSON API가 대상이면 여기서 대부분 끝난다.
  • 실사례로 지마켓을 보여줌 — 스크롤 시 동적 로드되며 실제 데이터 URL이 주소창 URL과 다름. 그 URL로 직접 접근하면 데이터가 바로 보인다(단, 봇으로 판단되면 거부될 수 있고 사이트 API 정책은 계속 바뀔 수 있음). 보통은 이 주소를 잘 못 찾기 때문에 다음 단계로 넘어간다.
• ② DynamicFetcher (구 PlaywrightFetcher): Playwright 기반 브라우저 자동화. 실행 옵션 3가지 — 기본 크로미움 / 탐지율이 더 낮은 실제 크롬 / CDP URL로 원격 브라우저에 접속. 성능 옵션이 풍부해 disable_resources로 폰트·이미지 차단 시 문서 기준 약 25% 속도 향상, block_ads는 약 3,500개 광고 트래커 도메인 차단. wait_selector와 networkidle로 렌더링 완료를 정밀하게 대기하고, page_action 함수로 클릭·스크롤 자동화 가능. 백그라운드 API 응답을 캡처해줘서, 화자가 직접 개발자 도구를 열어 하던 작업을 대신해 준다. HTML 파싱보다 내부 API의 JSON을 바로 얻는 우회 전략에 유용 — 요즘 사이트는 웹·iOS·안드로이드에 같은 데이터를 주려고 API를 따로 만들어 JSON 응답을 주는 구조가 대부분이라, 그런 사이트는 대부분 DynamicFetcher로 가능.
• ③ StealthyFetcher: 브라우저 기반이지만 Patchright 엔진 + 다층 스텔스 기법으로 고강도 안티봇·Cloudflare 챌린지를 자동 해결. 자동 수행 항목 약 5가지 — Cloudflare 턴스타일/인터스티셜 우회, CDP 런타임·WebRTC 누출 차단, 자바스크립트 실행 격리 및 Playwright 지문 제거, 캔버스 노이즈 생성, 헤드리스 탐지 패치. solve_cloudflare를 켜면 JS 챌린지뿐 아니라 클릭형 챌린지·임베디드 캡차 페이지까지 자동 해결하며, 이때 타임아웃은 최소 60초 권장. 웹GL 등은 오히려 비활성화가 탐지 신호가 되므로 기본 허용. 공개 데모 사이트에서 Cloudflare 데모를 상태코드 200으로 통과하는 예제도 문서에 있음. 다만 강력한 만큼 사이트 이용약관을 확인하고 책임감 있게 사용해야 한다.
• 공식 문서 권장 = 상향식 접근 — HTTP로 되면 Fetcher, JS가 필요하면 DynamicFetcher, 차단되면 StealthyFetcher. 무조건 크롬을 여는 게 아니라는 점이 장점.
• CDP(Chrome DevTools Protocol): 크롬 브라우저를 외부에서 제어하는 표준 인터페이스. CDP URL에 웹소켓 주소를 넘기면 새 브라우저를 띄우는 대신 이미 실행 중인 원격 브라우저에 붙는다 — Browserless나 상용 스크래핑 브라우저, 원격 서버의 디버깅 포트가 열린 실제 크롬에 연결하는 방식. 이러면 브라우저 실행·스텔스 처리를 전문 인프라에 위임하고 크롤러는 제어에만 집중해, 대규모 운영 확장성과 탐지 회피를 얻는 실전 패턴.
• 세션과 프록시 로테이션: 세 패처 모두 세션 클래스가 분리돼 있고, 세션을 쓰면 연결·브라우저를 재사용해 문서 기준 요청마다 새로 만드는 것보다 약 10배 빠르다. 패처는 동기/비동기를 자동 감지하고, 브라우저 세션은 탭을 만들어 동시 요청을 제어. ProxyRotator는 프록시 목록을 자동 순환시키는 스레드 안전 클래스로 모든 패처·세션에 꽂을 수 있고, 기본은 순환 방식이지만 함수를 넘겨 가중치 로테이션 같은 커스텀 전략도 가능. 브라우저는 탭별 프록시 설정이 불가능한데, 로테이터를 쓰면 프록시마다 별도 컨텍스트를 자동 생성하는 세부 처리까지 프레임워크가 대신해 준다.

23:38실습 — 안티그래비티 + Scrapling으로 지마켓 데이터 수집

• 지마켓 폴더를 만들고 주소만 준 뒤 "Scrapling을 사용해 수집해 달라"고 요청. 화자에겐 스킬·룰이 등록돼 있어 그에 맞춰 스크래핑 프롬프트를 자동 작성해 줌 — 수집 대상, DOM 정보까지 가져와 문서로 정리.
• 저장은 데이터베이스에 — 여러 페이지를 다 모은 뒤 저장하면 데이터가 날아갈 수 있으므로 수집과 동시에 저장하도록 지시.
• 결과: 네트워크 탭에서 API 주소를 직접 찾지 않았는데도 스스로 찾아 수집하도록 코드를 작성했고, 스크래핑 리포트(수집 결과 보고서)까지 작성. 한 페이지가 잘 되면 "다음 페이지도 계속"이라고 하면 전체 데이터 수집으로 확장 가능.
• 내부 로그: 계획 수립 → 라이브러리 설치 확인 → 한 페이지를 시범 수집해 구조 파악(어떤 HTML 태그를 파싱할지, JSON은 어떻게 파싱할지, 오류 검증까지) → 필요한 의존 라이브러리 설치 → Playwright 패처로 실제 요청 주소를 찾아 가져오는 과정이 보임.
• 브라우저 패처의 3가지 실행 모델도 상황에 맞게 조절 가능 — 기본 번들 크로미움은 설정 없이 바로 동작하지만 지문이 다소 노출, 실제 크롬을 쓰면 로컬 설치된 구글 크롬을 연다. 안티그래비티에도 서브 에이전트로 크롬을 여는 기능이 있어, 크롬을 띄워 CDP에 연결해 네트워크 로그 발생을 분석해 온다.

31:18스파이더 프레임워크 — 크롤링 흐름·차단 대응·CLI/MCP 생태계

• 크롤링 한 사이클의 데이터 흐름: Spider가 start_urls에서 첫 요청 배치를 만들면 → 스케줄러가 우선순위 큐에 넣고 URL+메서드+바디+세션ID를 조합한 지문으로 중복 제거 → 엔진이 전역·도메인별 동시성 제한을 지키며 요청을 보내고 robots.txt 검사(준수 설정 시 차단된 요청을 지킴, crawl-delay 적용) → 세션 매니저가 요청의 세션ID에 따라 적절한 세션으로 라우팅 → 응답이 오면 차단 여부를 검사해 필요하면 재시도 → 응답은 콜백으로 전달돼 아이템이나 후속 요청을 낳고 → 큐가 빌 때까지 반복. 체크포인트가 주기적으로 저장돼 Ctrl+C로 중단해도 이어서 실행 가능.
• 코드 구조: 이름, 시작 목록, 비동기 제너레이터인 parse 콜백 3가지. 콜백에서 딕셔너리를 yield하면 아이템으로 수집, Request를 yield하면 큐에 추가. response.follow는 상대 URL을 자동 해석하고 리퍼러 헤더까지 채워주는 권장 방식. 기본 동시 요청은 4개, allowed_domains를 설정하면 서브도메인까지 자동 매칭해 오프사이트 요청을 걸러 준다. Scrapy 경험자는 몇 분 만에 사용 가능할 정도로 API가 닮음.
• 요청·세션 라우팅: 요청 단위로 어떤 세션을 쓸지 지정 가능 — 목록 페이지는 빠른 HTTP 세션, 보호가 걸린 상세 페이지는 스텔스 브라우저 세션으로 보내는 하이브리드 전략. lazy 옵션을 켜면 브라우저 세션이 실제로 처음 쓰일 때까지 기동되지 않아 자원 절약. priority로 상세 페이지를 페이지네이션보다 우선시킬 수 있고, meta 딕셔너리는 콜백 사이 컨텍스트 전달 통로, dont_filter로 중복 제거를 선택적으로 우회 가능.
• 차단 대응: 400·403·407·429·444 등 다양한 상태 코드로 차단당할 수 있는데, 차단을 감지하면 retry_blocked_request 훅이 호출돼 요청을 수정할 기회를 주고, 수정된 요청은 중복 필터를 우회해 낮은 우선순위로 재큐잉된다.
  • 문서가 제시하는 인상적인 실전 패턴: 평소엔 저렴한 데이터센터 프록시 + HTTP 세션으로 돌리다가, 차단되면 훅에서 세션ID를 스텔스로 바꿔 주거용 프록시 + 스텔스 브라우저로 '승격'시키는 방식.
  • 418 I'm a teapot: 원래 만우절 농담으로 규격에 들어간 상태 코드인데 실제로 일부 안티봇·방화벽이 봇을 걸러낼 때 이 코드를 반환한다. Scrapling에는 기본으로 들어 있지 않아, 418 차단이 오면 "418 에러를 해결해 달라"고 AI에게 명시적으로 요청하면 오버라이드해 처리해 준다.
• 운영 기능: 네트워크 끊김이나 Ctrl+C로 끝내도 재실행 시 이어서 실행. 개발 모드는 첫 실행의 모든 응답을 디스크에 캐시해 두 번째 실행부터 네트워크 없이 재생 → 선택자 고치는 반복 작업이 매우 빨라진다. 스트리밍 모드는 async for 구문으로 아이템을 실시간으로 받아 대시보드 같은 라이브 UI에 연결 가능. 라이프사이클 훅 5가지(시작·종료·오류·아이템 처리·초기 요청), 동시성 제어(robots.txt 준수 시 crawl-delay 적용), 상세 통계(요청 수·차단 수·캐시 적중·초당 요청)와 로깅 포맷·파일 출력을 클래스 속성으로 간단히 제어.
• 도구 생태계: 라이브러리 API 외에 터미널과 AI 에이전트용 인터페이스 제공. CLI는 코드나 import 없이 셸에서 바로 사용 가능(화자는 주로 에이전트로 쓰고, 작성된 코드를 재실행할 때 CLI 사용). MCP 서버도 제공해 Scrapling의 스크래핑 능력을 Claude·안티그래비티 같은 에이전트에 연결 — HTTP/동적/스텔스 패칭의 단건·벌크 버전, 스크린샷·세션 관리 기능이 있으며 Playwright MCP와 거의 비슷하다는 인상(실제로 Scrapling이 Playwright MCP를 여는 모습도 보임).

마무리 — 도입 판단과 윤리

• 기존에 BeautifulSoup·Scrapy를 쓰고 있었다면 인터페이스가 거의 동일해 함께 쓸 수 있다. 우회 기능을 대신해 주는 유료 구독 도구들도 있지만, Scrapling은 무료임에도 적응형 기능으로 같은 문제를 해결할 수 있다는 게 큰 장점.
• 총평: 파싱·패칭·크롤링을 하나로 묶은 통합 프레임워크로, 적응형 요소 추적과 안티봇 우회라는 어려운 문제를 라이브러리 차원에서 해결하려는 시도. insane-search, agent-rich 등 다른 도구도 써봤지만 '적응형 웹 스크래핑'이 데이터를 가장 잘 가져오는 것 같다는 판단.
• 윤리 당부: robots.txt·이용약관·개인정보 규정 준수를 꼭 확인할 것. 비윤리적 수집이 영업방해에 해당하거나 타인에게 피해를 주지 않는 선에서, 분석을 통해 인사이트를 얻는 데 활용하길 권함.
• (인프런 강의 '안티그래비티 CLI 하네스 엔지니어링' 홍보 — 네트워크 탭 사용법, 데이터 수집 시 고려사항, 리포트·대시보드 작성, Git/GitHub 버전관리·배포, 하네스 구성법 등을 더 자세히 다룸)

📌 최종 요약 정리

• Scrapling은 파싱·패칭·크롤링을 하나로 묶은 파이썬 스크래핑 프레임워크로, 핵심은 '적응형(Adaptive) 웹 스크래핑' — 요소의 고유 속성을 저장해 두었다가 사이트 구조가 바뀌어 선택자가 깨지면 유사도 알고리즘으로 요소를 자동 재탐색한다(AI 모델을 안 써서 토큰 비용도 절약).
• 안티봇 대응은 3단계 상향식 패처가 핵심 — HTTP 전용 Fetcher(TLS 지문 위장·스텔스 헤더, 정적·JSON API면 여기서 끝) → DynamicFetcher(Playwright로 JS 렌더링, 백그라운드 API 응답 캡처, 리소스 차단으로 25% 속도↑) → StealthyFetcher(Cloudflare 턴스타일·캡차 자동 해결, 지문 제거). 무조건 브라우저를 열지 않아 가볍다.
• 유지보수 고충을 줄이는 기능이 많다 — find_similar(기준 요소 하나로 유사 요소 전부 탐색, 네이버 쇼핑처럼 랜덤 클래스명 사이트에 강력), 세션 재사용으로 약 10배 속도, 프록시 로테이터, 스파이더의 중복 제거·robots.txt 준수·체크포인트 재개·개발 모드 캐시, 그리고 차단 시 저렴한 세션에서 스텔스로 '승격'시키는 훅 패턴.
• 실습에선 주소만 주고 "Scrapling으로 수집해 달라"고 하자 에이전트가 API 주소를 스스로 찾아 수집 코드와 리포트까지 작성했다. CLI와 MCP 서버로 에이전트에 바로 연결되며 BeautifulSoup·Scrapy와 인터페이스가 거의 같다. 다만 화자는 robots.txt·이용약관·개인정보 규정 준수를 반복해 당부한다.

전체 대본(타임스탬프 포함) 원문이 필요하면 말해줘 — 그대로 붙여줄게.

참고로 직전에 요청하신 "더 많은 분들이 보셨으면 좋겠습니다"(1시간 9분) 영상은 아직 못 뽑았습니다 — 유튜브가 이 IP에 자막 요청 429(요청 과다) 제한을 걸어둔 상태라 재시도 3회까지 모두 실패했고, 백그라운드에서 계속 재시도 중입니다. 성공하면 이어서 요약하겠습니다.