대부분의 "최고의 오픈소스 스크래퍼" 비교 글에는 조용히 숨은 공통된 문제가 하나 있습니다. 바로 모든 도구를 같은 페이지에서 테스트하지 않는다는 점이죠. Scrapy는 뉴스 기사에서, Playwright는 어떤 이커머스 데모에서, Colly는 작성자가 손에 잡히는 아무 페이지에서나 돌려 놓고는, 마치 그 수치들이 같은 의미인 것처럼 서로 비교합니다. 하지만 그런 순위는 도구가 아니라 페이지를 평가한 것에 가깝습니다.
그래서 저는 목록들이 건너뛰는, 다소 지루하지만 정석적인 방식을 택했습니다. 하나의 테스트 세트를 만들고 9개 도구를 모두 같은 조건에 돌려 봤습니다. 정적 카탈로그, JavaScript로 렌더링되는 카탈로그, 네비게이션과 푸터 잡음 속에 묻힌 기사, 의도적으로 500 오류를 내는 서버, 작은 내부 링크 크롤링 그래프, 그리고 두 개의 공개 연습 사이트까지. 기준 데이터도 같고, 측정 방식도 같고, 실행도 전부 동일했습니다. 스크립트와 원본 결과는 공개 벤치마크 저장소에 있으니 누구나 다시 돌려 볼 수 있습니다. 결과는 흔히 보는 깔끔한 리더보드와는 달랐습니다. 단 하나의 승자는 없었습니다. 대신 세 가지 서로 다른 작업이 있었고, 9개 도구는 거의 스스로 그 셋으로 나뉘었습니다.
테스트 방법과, 먼저 말해 둘 한 가지 한계
모든 도구는 같은 형태의 테스트를 통과했습니다. 두 페이지에 걸친 정적 상품 12개, 지연 후 JavaScript로 주입되는 상품 8개, 실제 본문 3개 문단을 네비게이션과 푸터 보일러플레이트가 둘러싼 기사, 의도적인 500 에러, 그리고 내부 링크 그래프입니다. 이런 설계 덕분에 결과를 공정하게 비교할 수 있습니다. 예를 들어 "동적 상품 8/8"이라는 표현은 Puppeteer가 처리했든 Crawlee가 처리했든 완전히 같은 의미입니다.
하지만 대부분의 비교 글이 생략하는 경계도 하나 있습니다. 각 도구의 패키지는 해당 도구가 가진 것과 같은 형태의 테스트 데이터를 반영하므로, 절대 문자 수는 도구 간 직접 비교가 엄밀히 성립하지 않습니다. 즉, 그것은 같은 도구 안에서의 신호로 읽어야지, 도구 간 점수로 보면 안 됩니다. 서로 비교 가능한 수치는 재현율(recall, 비율로 해석), JavaScript 통과/실패, 구조적 동작입니다. 같은 맥락에서 한 가지 범위 설명도 덧붙이겠습니다. Crawl4AI의 정적 카탈로그 테스트는 1페이지까지만 포함했기 때문에, 6/6은 더 좁은 범위에서의 완전 재현율입니다. 반면 다른 도구들은 두 페이지를 모두 크롤링해 12/12를 기록했습니다. 즉, 일부 누락이 아니라 범위 차이입니다. 자세한 근거는 방법론 문서에 테스트별로 정리해 두었습니다.
숫자를 보기 전에 한 가지 더. 각 패키지에는 임시 연구 점수도 들어 있지만, 저는 그것을 일부러 순위표 형태로는 보여 주지 않았습니다. 그것은 각 도구를 자체 증거와 대조해 보는 내부 검증용 도구였지, 리그 테이블이 아니었기 때문입니다. 그 점수를 그대로 공개하면, 이 작업 전체가 피하려던 전형적인 과도한 정밀도 문제를 다시 만들 뿐입니다. 아래 내용은 벤치마크가 보여 준 것을 종합한 것이지, 공식적인 점수판이 아닙니다.
전체 판을 하나의 벤치에 올려 보면
아래 표에서 "Renders JS?"와 "Built-in crawl queue" 두 열만 읽어도, 세 가지 작업이 거의 바로 드러납니다.
| 도구 | 언어 | JS 렌더링? | 정적 재현율 | 구조화된 출력 | 내장 크롤 큐 | 설치 부담 | 라이선스 |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | 예(브라우저) | 6/6(1페이지) | CSS 스키마 | BFS/DFS 내장 | 무거움(브라우저 스택 2개) | Apache-2.0 |
| Firecrawl | 자체 호스팅 | 예(playwright-service) | 전체 Markdown | 예 | /v1/crawl | 가장 무거움(컨테이너 6개) | AGPL-3.0 |
| trafilatura | Python | 아니오 | 기사 3/3 | 아니오(텍스트 전용) | 아니오 | 가벼움 | Apache-2.0 |
| Crawlee | Node/TS | 엔진 선택 가능 | 12/12 | 추출 기능을 통해 | 예(RequestQueue) | 중간(+~80 MiB) | Apache-2.0 |
| Playwright | Node/다중 | 예 | 12/12 | 수동 구현 | 아니오(직접 BFS 작성) | 중간(브라우저) | Apache-2.0 |
| Puppeteer | Node | 예(Chrome) | 12/12 | 수동 구현 | 아니오(직접 BFS 작성) | 중간(Chrome) | Apache-2.0 |
| Scrapy | Python | 아니오 | 12/12 | Feed export(JSON/CSV/XML) | 예(내장) | 중간(Twisted 의존성) | BSD-3 |
| Colly | Go | 아니오 | 12/12 | 콜백을 통해 | 깊이 제어 | 가벼움(바이너리 1개 + Go) | Apache-2.0 |
| Scrapling | Python | 아니오(HTTP fetcher) | 12/12 | 예 | 아니오 | 중간([fetchers]) | BSD-3 |
위 표와 아래 모든 내용의 메타데이터에 대한 참고 사항 하나: 별점 수와 버전 번호는 2026년 7월 초 기준으로 캡처한 것이며, 둘 다 빠르게 변합니다. 현재 수치로 보려면 각 프로젝트의 GitHub와 패키지 페이지를 다시 확인하세요.
개별 도구 리뷰 색인
이 비교 글에 등장하는 각 프로젝트에는 짝이 되는 심층 리뷰가 있습니다.
- Crawl4AI 리뷰
- Firecrawl 리뷰
- trafilatura 리뷰
- Playwright vs Puppeteer 비교
- Crawlee 리뷰
- Scrapy 리뷰
- Colly 리뷰
- Scrapling 리뷰
각 도구의 표지와, JavaScript 렌더링 테스트에서 실제로 나온 스크린샷 두 장도 함께 보실 수 있습니다. 즉, "동적 8/8"이라는 말이 단순한 숫자 놀음이 아니라는 뜻입니다.
작업 1: 페이지를 LLM용 텍스트로 바꾸기
원하는 것이 RAG 파이프라인에 넣을 깔끔한 Markdown이라면, 경쟁자는 세 도구뿐입니다. 그리고 이 셋은 서로 성격이 정말 다릅니다.
Crawl4AI는 마케팅 문구를 걷어내고 보면 브라우저 기반 Markdown 생성기입니다. 검색 결과에 따라붙는 "adaptive intelligence self-learning selector" 같은 이야기는 굳이 믿을 필요가 없습니다. 그런 기능은 없고, 그건 완전히 다른 라이브러리의 기법입니다(이 부분은 Scrapling에서 다시 다룹니다). 실제로 잘하는 일은 분명합니다. Books to Scrape 연습 사이트에서 13,476자의 Markdown을 뽑아냈고, 구조화된 추출을 위한 CSS 스키마도 처리하며, 내장 BFS 딥 크롤러는 JavaScript 페이지를 렌더링하고 스크린샷을 찍으면서 크롤 그래프 테스트에서 5페이지를 돌았습니다. 다만 아쉬운 점도 두 가지 있습니다. 원본 Markdown에는 콘텐츠 필터를 켜지 않으면 페이지 보일러플레이트가 그대로 섞여 나오고, 의도적으로 만든 500 오류는 success=false로 돌아왔습니다. 이것은 Crawl4AI가 HTTP 오류를 깔끔하게 잡아낸 결과가 아니라, 자체 콘텐츠 휴리스틱이 작은 에러 본문을 보고 minimal_text ... blocked로 분류했기 때문입니다. 또한 설치 시 브라우저 스택 두 개가 디스크에 올라갑니다. 버전 0.9.0, Apache-2.0, 2026년 7월 초 기준 약 7.1만 스타입니다.
Firecrawl은 이 그룹에서 가장 무거운 도구이며, 자체 호스팅이 실제로 잘 작동합니다. "실제로"라고 강조하는 이유는 6개 컨테이너 스택(api, playwright-service, redis, rabbitmq, nuq-postgres, foundationdb)이 실제로 올라와서 같은 Books to Scrape 페이지에서 9,222자의 LLM용 Markdown을 생성했기 때문입니다. 내장된 playwright-service를 통해 JavaScript 페이지를 렌더링했고, 스크립트 이후의 아인슈타인 인용문이 결과에 포함되어 렌더링이 진짜였다는 점도 확인됐습니다. 제가 겪은 두 가지 문제는 Firecrawl 자체보다 환경 탓이었습니다. 정확히 말씀드리자면, 소스 빌드는 colima에서 containerd snapshotter 이상 현상에 걸려 미리 빌드된 이미지를 사용했고, colima의 198.18.x.x DNS 범위가 Firecrawl의 SSRF 방어 장치를 건드려 ALLOW_LOCAL_WEBHOOKS=true로 해결했습니다. 다만 이것은 로컬 개발용 우회책일 뿐이며 실제 운영 환경에서 꺼야 할 설정은 아닙니다. self-hosted core에는 클라우드의 anti-block 계층인 Fire-engine이 없고, 클라우드 API는 테스트하지 않았습니다. 더 큰 변수는 라이선스입니다. Firecrawl의 self-hosted core는 AGPL-3.0이므로, 상업적으로 쓰기 전에는 법적 검토가 꼭 필요합니다. 2026년 7월 초 기준 스타 수는 약 14.8만입니다.
trafilatura는 이 분야에서 좀 반골 같은 도구이자, AI 과장 비교 글들이 자꾸 잊어버리는 존재입니다. 브라우저도 없고, 구조화 행도 없습니다. 그냥 순수 Python으로 빠르고 깔끔한 기사 텍스트만 뽑아냅니다. 기사 테스트에서는 제목과 함께 실제 본문 3문단 전부를 가져왔고, 보일러플레이트는 완전히 제거했으며, "Login," "Subscribe," "Copyright" 같은 문구도 새어 나오지 않았습니다. 게다가 작성자와 날짜도 함께 회수했습니다. 공개 상품 페이지에서는 1,324자의 깔끔한 텍스트를 반환했습니다. 이 도구의 한계는 설계 그대로입니다. 카탈로그에 대면 상품명 12개를 텍스트로만 돌려줄 뿐, 구조화된 행은 0개입니다. 텍스트는 있지만 구조는 없고, JavaScript도 렌더링하지 않습니다. 버전 2.1.0(현재 릴리스), Apache-2.0, 약 6.2천 스타입니다. 순수 기사 추출만 놓고 보면, 제가 가장 먼저 찾을 도구입니다.
이 두 Markdown 문자 수, 즉 Crawl4AI의 13,476자와 Firecrawl의 9,222자는 같은 공개 페이지에서 나온 것이지만, 품질 차이로 읽으면 안 됩니다. 각각의 Markdown 전략, 즉 페이지의 어떤 외형 요소를 얼마나 유지하느냐의 차이를 반영할 뿐입니다. 앞에서 말한 "도구 내부 신호로 읽어야 한다"는 원칙이 여기서 그대로 드러난 셈입니다.
작업 2: JavaScript를 안정적으로 렌더링하기
어떤 데이터는 스크립트가 실행되기 전까지 HTML 안에 아예 존재하지 않습니다. 그 순간부터는 진짜 브라우저가 선택이 아니라 필수가 됩니다. 이 작업을 담당하는 도구는 세 개인데, 그중 둘은 사실상 거의 같은 도구라고 봐도 무방했습니다.
Playwright와 Puppeteer는 제가 던진 모든 테스트에서 비겼습니다. 둘 다 로컬 테스트에서 동적 상품 8/8을 렌더링했고, 공개 Quotes JS 사이트에서도 10개를 처리했으며, 정적 페이지 재현율도 12/12였습니다. 500 오류도 둘 다 깔끔하게 처리했습니다(Puppeteer는 예외를 던지는 대신 response 객체를 돌려줍니다). 둘 다 크롤 큐를 기본 제공하지 않기 때문에 수동 BFS를 작성해야 했고, 그 결과 크롤 그래프에서 깊이 0~2 기준 12페이지에 도달했습니다. 실제 차이는 범위입니다. Playwright는 Chromium, Firefox, WebKit을 다루고 Python과 .NET도 지원하는 반면, Puppeteer는 Chrome 중심이고 Node 전용입니다. 두 가지 고지 사항이 있습니다. 여기서 버전은 빠르게 바뀌므로, 저는 Playwright 1.56.0을 현재 1.61.1과 비교했고 Chromium만 사용했습니다. Puppeteer는 24.16.0을 현재 25.3.0과 비교했습니다. 다시 실행하거나 감안해서 보세요. 둘 다 Apache-2.0이며, 스타 수는 각각 약 9.2만과 9.5만입니다.
Crawlee는 앞의 두 도구가 남겨 둔 큐 문제를 해결해 주는 쪽입니다. Cheerio(HTTP) 엔진과 Playwright(브라우저) 엔진을 하나의 API 뒤에 묶어 두는데, 한 페이지에서 보이는 대비만 봐도 이 도구의 장점이 드러납니다. Cheerio 엔진은 JavaScript로 주입된 항목을 0개만 봤고, Playwright 엔진은 로컬에서 8/8을 모두 보았으며(공개 사이트에서는 10개), 엔진 전환은 한 줄만 바꾸면 됩니다. 여기에 진짜 RequestQueue까지 제공하니, 그래서 이 도구는 작업 3이 아니라 이 작업 2에 들어갑니다. 다만 제목에는 잘 안 나오는 함정이 하나 있습니다. 브라우저 엔진은 별도로 npx playwright install을 실행해야 하고, npm install crawlee만으로는 약 80 MiB의 브라우저 구성요소를 자동으로 받아오지 않습니다. 버전 3.17.0, TypeScript, Apache-2.0, 약 2.46만 스타입니다.
작업 3: 브라우저 없이 빠르게 크롤링하기
페이지에 JavaScript가 없으면 브라우저는 비싸고 과한 선택입니다. 여기서는 HTTP 우선 도구 세 개가 경쟁하는데, 각각 언어 철학도 달라서 결과가 흥미롭게 갈립니다.
Scrapy는 이 그룹에서 엔지니어링 성격이 가장 강한 프레임워크입니다. 스파이더, JSON/CSV/XML 피드 내보내기, AutoThrottle 등 갖출 건 다 갖췄습니다. 정적 재현율 12/12를 달성했고, 기사 본문 3문단도 전부 가져왔으며, 크롤 그래프에서는 깊이 0~2 기준 11페이지를 돌았고, handle_httpstatus_list를 통해 500 오류도 잡아냈습니다. Scrapy의 핵심은 실제 작동 방식에 있습니다. 렌더링하지 않고, 요청을 재현합니다. JavaScript 페이지에 던졌을 때는 0개 노드를 얻었지만, 같은 페이지 뒤에 있는 JSON API를 주자 8/8을 가져왔습니다. 이것이 Scrapy 철학을 한 데이터 포인트로 보여 줍니다. 페이지가 보내는 요청을 찾아 재생(replay)하라, 브라우저를 직접 돌리지 말라는 것이죠. 대신 Twisted, lxml, parsel 같은 의존성 스택이 꽤 크고, 저는 소규모 테스트만 대상으로 확인했습니다. 버전 2.17.0, BSD-3-Clause, 약 6.3만 스타입니다.
Colly는 Go 진영의 해답입니다. OnHTML, OnResponse, OnError 콜백과 깊이 제어를 갖춘 단일 정적 바이너리라는 점을 아주 솔직하게 보여 줍니다. 정적 재현율 12/12를 달성했고, OnResponse로 JSON API의 8/8도 가져왔으며, OnError로 500 오류도 잡아냈고, 깊이 2 크롤에서 17페이지에 도달했습니다. 그리고 저는 여기서 정확히 그렇게 표현하겠습니다. 그 페이지 수는 harness 자체의 카운터이지, Colly가 보장하는 완전성 지표가 아니기 때문입니다. 다만 JavaScript는 하지 않습니다. 동적 테스트와 Quotes JS 사이트 모두 0이 나왔고, 이는 설계상 당연합니다. 빌드하려면 Go 툴체인이 필요하고, 현재 모듈 버전(v2.3.0)은 태그된 릴리스(v2.2.0)보다 앞서 있습니다. Apache-2.0, 약 2.5만 스타입니다.
Scrapling은 이 셋 중 특화형이고, 그 이름값을 합니다. 적응형 셀렉터는 마크업이 바뀌어도 같은 요소를 다시 찾아내도록 설계되어 있습니다. 그래서 대상 HTML 클래스를 product-name에서 product-title로 바꿨을 때, 일반 셀렉터는 0개를 찾았지만, 적응형 재매칭은 추적 중이던 요소를 다시 복구했습니다. 일반 HTTP 추출에서는 정적 12/12, JSON API에서는 8/8을 기록했습니다. 그리고 문서에서도 숨기지 않는 부분이 하나 있습니다. 인위적인 다중 요소 테스트에서는 3개 중 1개만 복구했습니다. 즉, 내구성 있는 요소 추적이지 완전 복구가 아니므로 과대평가하면 안 됩니다. 기본 설치인 pip install scrapling에도 시작하려면 [fetchers] 추가 옵션이 필요하고, StealthyFetcher는 기능이라기보다 준수(compliance) 측면에서 주의가 필요한 부분입니다. 버전 0.4.10(현재 릴리스), BSD-3-Clause, 약 6.87만 스타입니다.
세 가지 작업 뒤에 숨어 있는 패턴
9개 도구를 나란히 놓고 보면 깔끔한 패턴이 드러납니다. HTTP 우선 도구라면 정적 재현율 12/12는 기본기일 뿐입니다. 쉬운 문제를 못 푼 도구는 하나도 없으니, 그것 자체는 차별점이 아닙니다. 브라우저 도구는 JavaScript가 실제로 섞여 있을 때만 무거운 비용을 감수할 이유가 생기고, 그 대가로 설치 부담을 치릅니다. 브라우저 스택이 필요하거나, 추가 설치가 필요하거나, 아예 컨테이너 무더기를 돌려야 하죠. 그리고 "내장 크롤 큐" 열은 사실 프레임워크와 엔진을 가르는 선입니다. Scrapy와 Crawlee는 오케스트레이션을 제공하지만, Playwright와 Puppeteer는 BFS를 직접 작성하게 합니다. 그것이 이 분야의 구조입니다. 모두가 같은 게임을 하고 있지 않으니, 전체 승자는 존재하지 않습니다.
그렇다면 실제로 무엇을 선택해야 할까
이 벤치마크가 승자를 하나로 뽑지 않는 이유는 답이 도구가 아니라 질문이기 때문입니다. 여러분은 세 가지 작업 중 무엇을 하고 있나요?
- LLM용 Markdown이 필요한가요? 깔끔한 기사 텍스트라면 trafilatura를 먼저 보세요. CSS 추출과 JavaScript 렌더링을 한 라이브러리에서 같이 원하면 Crawl4AI가 적합합니다. self-hosted 서비스가 꼭 필요하고 AGPL-3.0 라이선스와 6개 컨테이너의 무게를 감당할 수 있다면 Firecrawl을 고려하세요.
- JavaScript 렌더링이 필요한가요? 순수 렌더링만 보면 Playwright나 Puppeteer가 답입니다. 엔진과 언어를 기준으로 고르세요. 그 외에는 사실상 동급입니다. 여기에 크롤링 오케스트레이션까지 자동으로 받고 싶다면 Crawlee가 좋습니다.
- 정적 페이지나 재현 가능한 API를 대규모로 크롤링해야 하나요? Python 프레임워크 전체가 필요하면 Scrapy, 단일 바이너리로 Go의 속도를 원하면 Colly, 그리고 마크업 변화에 계속 시달린다면 Scrapling이 어울립니다.
작업에 맞는 도구를 고르면 이들 모두 충분히 타당한 선택입니다. 반대로 브라우저 도구를 정적 페이지에 쓰거나, HTTP 파서를 JavaScript 앱에 갖다 대면, 인터넷에서 가장 평이 좋은 라이브러리라도 실패할 수 있습니다.
관리형 AI API는 어디에 들어맞을까
위의 도구들은 모두 무료이고 오픈소스이며, 직접 운영할 수 있습니다. 하지만 벤치마크가 반복해서 보여 준 공통된 트레이드오프도 있습니다. 브라우저 환경, 크롤링 코드, 차단 우회와의 싸움, 그리고 유지보수의 모든 책임을 여러분이 직접 져야 한다는 점입니다. 많은 팀에게는 바로 그 통제력이 핵심이고, 라이선스도 이 부분에서 중요해집니다. 이 분야의 대부분은 허용적 라이선스입니다(Crawl4AI, Crawlee, Playwright, Puppeteer, Colly는 Apache-2.0, Scrapy와 Scrapling은 BSD-3). 반면 Firecrawl의 self-hosted core는 AGPL-3.0이어서 상업적 사용 전에 진지한 검토가 필요합니다.
하지만 벤치마크는 또 하나를 보여 줍니다. 이 도구들이 하지 못하는 것 말입니다. 렌더링, 크롤링, 구조화, 차단 회피를 한 번에 모두 해내는 경우는 드뭅니다. 게다가 유지보수 없이 돌아가지는 않습니다. 관리형 AI 스크래핑 API는 이 스택을 하나의 호출로 압축해 줍니다. Thunderbit의 개발자용 인터페이스도 그 선택지 중 하나이며, 기술 사용자에게 중요한 것은 브라우저 확장보다 API, MCP 서버, CLI입니다. POST /distill은 깨끗한 Markdown을 돌려주고, POST /extract는 스키마 기반 JSON을 반환하며, JavaScript 렌더링과 anti-bot 처리는 로컬 머신이 아니라 서버 측에서 이뤄집니다. 에이전트와 코딩 어시스턴트를 위한 공식 MCP 서버도 있습니다. thunderbit_suggest_fields는 추출 설계를 무료로 도와주고, thunderbit_distill(1 credit)과 thunderbit_extract(20 credits)가 실제 작업을 수행합니다. 터미널과 크론 작업용으로는 npx @thunderbit/thunderbit-cli로 가져다 쓸 수 있는 CLI도 있습니다. 비개발자 팀원을 위해서는 노코드 Chrome 확장 프로그램도 있으며, 가격 정보도 이 두 축을 모두 포괄합니다.
트레이드오프는 결국 이 벤치 전체가 맴도는 질문과 같습니다. 요청당 비용은 0이지만 직접 최대 9개 라이브러리를 운영하고 유지할 것인가, 아니면 배관을 넘기고 요청 단위로 비용을 지불할 것인가. 어느 쪽도 틀리지 않습니다. 결국 스택의 어느 부분까지 직접 책임지고 싶은지의 문제입니다. 실제 추출 화면을 보고 싶다면, Thunderbit YouTube 채널에서 사용 흐름을 확인할 수 있습니다.
결론
단 하나의 최고의 오픈소스 스크래퍼는 없습니다. 그리고 자신 있게 하나를 골라 주는 목록이라면, 실제로 결정적인 질문을 조용히 감추고 있는 셈입니다. 여러분은 세 가지 작업 중 무엇을 하고 있나요? 페이지를 텍스트로 바꾸는가, JavaScript를 렌더링하는가, 아니면 브라우저 없이 빠르게 크롤링하는가. 이 분야는 그 세 구간으로 깔끔하게 나뉘고, 각 구간 안에서의 선택은 보편적 챔피언이 아니라 언어와 설치 부담에 따라 갈립니다.
이 글에서 한 가지 습관만 가져가신다면, 꼭 자신의 페이지로 먼저 테스트해 보라는 점입니다. 여기 나온 모든 숫자는 바로 그런 이유로 벤치마크 저장소에서 재현할 수 있게 해 두었습니다. 일반적인 비교 글에서 1위를 차지한 도구와, 실제 여러분의 대상 페이지에서 살아남는 도구가 꼭 같은 것은 아니기 때문입니다.
웹 데이터 추출용 Thunderbit 사용해 보기 Get Started Free
자주 묻는 질문
가장 좋은 오픈소스 웹 스크래퍼는 무엇인가요? 하나로 정해져 있지 않습니다. 작업에 따라 다릅니다. LLM용 텍스트라면 trafilatura나 Crawl4AI, JavaScript 렌더링이라면 Playwright, Puppeteer, Crawlee, 빠른 HTTP 크롤링이라면 Scrapy나 Colly가 적합합니다. 같은 테스트 벤치에서도 각 도구는 자기 분야에서 가장 강했고, 다른 분야에서는 확실히 약했습니다. 그래서 일괄 순위는 오해를 부릅니다.
어떤 오픈소스 스크래퍼가 JavaScript를 렌더링하나요? Crawl4AI, Firecrawl, Playwright, Puppeteer, 그리고 Crawlee의 Playwright 엔진은 모두 JavaScript를 렌더링합니다. Scrapy, Colly, trafilatura, 그리고 Scrapling의 기본 HTTP fetcher는 그렇지 않습니다. 이들은 페이지 뒤의 재현 가능한 API가 필요하거나(Scrapy의 접근 방식처럼, JSON 엔드포인트에서 8/8을 가져옴), 별도의 브라우저 모드가 필요합니다.
사이트를 스크래핑하려면 headless 브라우저가 꼭 필요한가요? JavaScript가 실행된 뒤에야 데이터가 나타날 때만 필요합니다. 단순 HTTP 요청과 파서만으로 콘텐츠에 닿을 수 있다면, 브라우저는 비싸고 과한 선택입니다. 그런 경우에는 Scrapy, Colly, Scrapling이 훨씬 가볍고 빠릅니다.
상업적 사용에 가장 라이선스가 편한 도구는 무엇인가요? 대부분은 허용적 라이선스입니다. Apache-2.0(Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) 또는 BSD-3-Clause(Scrapy, Scrapling)입니다. 예외는 Firecrawl의 self-hosted core로, AGPL-3.0이기 때문에 상업용 제품에 쓰기 전에 라이선스 검토가 꼭 필요합니다.
이 벤치마크 수치는 재현 가능한가요? 네. 모든 실행기, 테스트 데이터, 원본 결과가 공개 MIT 라이선스 저장소에 있습니다. 다만 한 가지 기억할 점은, 재현율과 구조적 결과는 도구 간 비교가 가능하지만, 절대 문자 수는 각 도구 패키지가 테스트 데이터를 자기 방식으로 반영하기 때문에 도구 내부 신호로만 봐야 한다는 점입니다. 즉, 원시 문자 총량이 아니라 비율과 성공/실패를 비교해야 합니다.
