Scrapy 쓰던 팀이 Crawlee로 옮긴 몇 달, 잘한 선택이었을까

Scrapy 쓰던 팀이 Crawlee로 옮긴 몇 달, 잘한 선택이었을까

2026년 7월의 한 독립 테스트는 단순한 질문으로 시작했다. "Crawlee가 내 스택에 넣을 가치가 있는가, 아니면 그냥 Playwright를 쓰면 되는가."

테스트의 핵심은 두 엔진이 같은 옷을 입는다는 제조사의 주장이었다. 정적 HTML을 다루는 HTTP 엔진과, 실제 Chromium으로 JavaScript를 실행하는 브라우저 엔진이 같은 핸들러 형태를 쓴다는 것이다. 작성자는 추출 로직을 바이트 단위로 유지한 채 크롤러 클래스만 바꿔 보았다. 결과는 이렇다. JS가 상품 카드를 주입하는 페이지에서 HTTP 엔진은 0개, 브라우저 엔진은 8개 중 8개를 잡았다.

이 글은 그 테스트와 비교 자료, 그리고 옮긴 팀들이 남긴 비용을 함께 정리한다.

1. 자료 범위

독립 테스트 리뷰(2026-07, Crawlee 3.17.0), Scrapy·Crawlee 비교 가이드(2026), Python 포트 평가, 공식 문서를 읽았다. 속도 수치는 테스트자의 단일 기기 단일 회차 수치다.

2. 지켜진 약속 — 두 엔진, 한 API

Crawlee의 핵심 주장은 검증되었다.

엔진 교체는 클래스 교체다. 동일 URL에서 Cheerio 기반 HTTP 크롤러는 약 0.035초, Playwright 크롤러는 약 4.97초. 브라우저 경로가 두 자리 수배 느리지만, 이는 렌더링의 값이다. 중요한 것은 추출 로직을 다시 쓸 필요가 없다는 점이다.

크롤 오케스트레이션이 붙어 있다. 단일 페이지 렌더링이라면 Playwright만으로 충분하다. Crawlee가 주는 것은 그 위의 큐·중복 제거·깊이 제어·재시도다. 테스트에서 같은 호스트 크롤이 깊이 0~2에 걸쳐 11페이지를 walked하고, 500 에러 요청은 조용히 삼키지 않고 failedRequestHandler로 표면화했다.

기본 방어. 세션 풀, 프록시 로테이션, 지문 생성이 기본값에 들어 있어 "봇 보호를 피하는 데 드는 배선 작업"을 줄여 준다는 것이 비교 자료의 공통 평가다. Scrapy가 기본으로 아무것도 하지 않는 것과의 차이다.

3. 치른 비용 — 설치·언어·이전

첫 실행의 마찰. npm install crawlee만으로는 브라우저가 내려받아지지 않는다. npx playwright install chromium을 돌려야 하는데, 약 80MB의 Chromium이 추가된다. 이 단계를 건너뛰면 원인 파악이 어려운 런치 에러가 난다. Playwright의 구조에서 오는 것이지 Crawlee 결함은 아니지만, 첫 경험이 거칠다는 지적이다.

언어의 선택. Crawlee는 Node·TypeScript에서 가장 성숙하다. Python 포트는 존재하지만 기능과 커뮤니티에서 Node 버전에 뒤진다는 것이 2026년 비교 자료의 판단이다. 팀이 이미 Python이라면 Scrapy 쪽에 서가 더 깊다.

이전의 구조적 비용. 기존 Scrapy 프로젝트를 옮기는 것은 조정이 아니라 재작성에 가깝다. Twisted 리액터·스파이더·미들웨어·파이프라인 모델로 사고하는 팀에게 Crawlee의 핸들러 라우터·컨텍스트 객체는 다른 모델이다. 한 평가는 "이미 동작하는 Scrapy 프로젝트에 브라우저 요구가 없다면 옮기지 말라"고 못박는다.

적합하지 않은 범위. 페이지 하나, 필드 하나를 긁는 작업에는 큐·저장소·라이프사이클이 오버헤드다. 그 경우에는 httpx나 requests 한 줄이 짧고 이동 부품도 적다.

4. 옮긴 팀에게 맞는 프로필

이 강점과 비용을 합치면 Crawlee가 맞는 팀의 그림이 나온다.

• Node·TypeScript 코드베이스에서 일을 하며, 한 언어를 유지하고 싶은 팀
• 같은 프로젝트 안에서 정적 HTTP와 JS 렌더링을 섞어야 하는 팀
• 세션·프록시·큐를 처음부터 가지고 시작하고 싶은 팀
• 브라우저 팜을 직접 운영할 의향이 있는 팀

반대로 Python 전용, 기존 Scrapy 유지, 단발 크롤이라면 이전 비용이 약속된 이점보다 클 가능성이 높다.

5. 결론 — 프레임워크가 아니라 크롤의 형태로

Crawlee에 대한 평가는 "Scrapy보다 좋다"가 아니라 다음과 같이 갈린다. 한 프레임워크 안에서 HTTP와 브라우저를 오가는 크롤을 만들 것인가, 아니면 언어 생태계의 깊이를 선택할 것인가.

독립 테스트의 결론은 약간의 별표를 달고서도 "예"였다. 두 엔진의 약속은 지켜졌고, 큐와 깊이 크롤링은 문서대로 작동했다. 남은 것은 설치의 첫 마찰과 팀의 언어 선택이다. 그 두 가지를 이미 알고 시작하면, 옮긴 몇 달의 감상은 대개 "잘한 선택" 쪽에 가까워진다.

관련 글: Crawl4AI 사용자 리뷰 · Exa 사용자 리뷰 · Crawlee 에이전트 허브 항목

출처

• 독립 테스트: Crawlee, Tested: One Node Framework, Two Scraping Engines (Thunderbit, 2026-07)
• 비교: Scrapy vs Crawlee (webscrape.dev, 2026-07) · Scrapy vs Crawlee (Crawlee 공식 블로그, 2024-04, 벤더 글임을 표기)
• Python 포트: Crawlee for Python review (Hysen Labs) · crawlee-python GitHub