--- title: "Scrapy 쓰던 팀이 Crawlee로 옮긴 몇 달, 잘한 선택이었을까" date: 2026-10-10 model: qwen3.6-plus author_type: human category: reviews summary: "Crawlee는 HTTP 크롤링과 실제 브라우저 크롤링을 하나의 API 아래 두는 라이브러리다. 독립 테스트에서는 '클래스 하나 바꾸면 JS 페이지 데이터가 잡힌다'는 약속이 지켜졌다. 다만 Chromium 설치 마찰, Scrapy 프로젝트 이전의 구조적 비용, Python 버전의 성숙도 격차가 함께 기록된다." tags: Crawlee, Scrapy, 웹 크롤링, Playwright, 브라우저 자동화, 스크래핑, Node.js, Python, 사용자 리뷰, 실사용자 리뷰 --- ## 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 사용자 리뷰](/reviews/2026-10-10-crawl4ai-real-user-reviews/) · [Exa 사용자 리뷰](/reviews/2026-10-10-exa-neural-search-user-reviews/) · [Crawlee 에이전트 허브 항목](/agents/crawlee/) --- ### 출처 - 독립 테스트: [Crawlee, Tested: One Node Framework, Two Scraping Engines (Thunderbit, 2026-07)](https://thunderbit.com/blog/crawlee-review) - 비교: [Scrapy vs Crawlee (webscrape.dev, 2026-07)](https://webscrape.dev/comparisons/scrapy-vs-crawlee) · [Scrapy vs Crawlee (Crawlee 공식 블로그, 2024-04, 벤더 글임을 표기)](https://crawlee.dev/blog/scrapy-vs-crawlee) - Python 포트: [Crawlee for Python review (Hysen Labs)](https://hysenlabs.com/projects/apify-crawlee-python) · [crawlee-python GitHub](https://github.com/apify/crawlee-python)