대부분의 "최고의 오픈소스 스크래퍼" 정리 글에는 조용히 공통된 약점이 하나 있습니다. 바로 같은 페이지에서 도구를 비교하지 않는다는 점이죠. Scrapy는 뉴스 기사로, Playwright는 어느 이커머스 데모로, Colly는 작성자가 손에 잡히는 아무 페이지로나 테스트한 뒤, 마치 그 결과가 같은 기준인 것처럼 서로를 줄 세웁니다. 하지만 그런 순위는 도구가 아니라 페이지에 대한 이야기일 뿐입니다.
그래서 저는 목록들이 건너뛰는 가장 단순하고 지루한 방법을 택했습니다. 하나의 테스트 환경을 만들고, 9개의 도구를 모두 거기에 통과시켜 본 것이죠. 정적 카탈로그, JavaScript로 렌더링되는 카탈로그, 네비게이션과 푸터의 잡다한 요소 속에 묻힌 기사, 의도적으로 발생시킨 HTTP 500 오류, 작은 내부 링크 크롤링 그래프, 그리고 두 개의 공개 연습 사이트까지. 기준 데이터도 같고, 측정 방식도 같고, 실행도 모두 동일했습니다. 스크립트와 원본 결과는 공개 벤치마크 저장소에 있으니, 누구든 직접 다시 돌려볼 수 있습니다. 그 결과는 정리 글들이 약속하는 깔끔한 리더보드와는 전혀 달랐습니다. 단 하나의 승자는 없었거든요. 대신 세 가지 서로 다른 업무가 있었고, 9개 도구는 거의 저절로 그 안에 나뉘어 들어갔습니다.
테스트 환경은 어떻게 구성했나, 그리고 내가 먼저 말하고 싶은 한 가지 한계
모든 도구는 동일한 형태의 테스트 파일을 받았습니다. 두 페이지에 나뉜 12개 정적 상품, 지연 후 JavaScript로 주입되는 8개 상품, 실제 본문 3개 문단을 네비게이션과 푸터 boilerplate가 둘러싼 기사, 의도적으로 만든 서버 500, 그리고 내부 링크 그래프까지요. 이런 설계 덕분에 결과가 정확히 맞물립니다. 예를 들어 "동적 상품 8/8"은 Puppeteer가 만들었든 Crawlee가 만들었든 완전히 같은 의미가 됩니다.
그런데 대부분의 비교 글이 빼먹는 경계가 하나 있습니다. 각 도구의 패키지는 그 도구에 맞춘 자체 복사본을 포함하므로, 절대 문자 수는 도구 간에 엄밀히 비교할 수 없습니다. 같은 도구 안에서만 의미 있게 보아야 하죠. 서로 비교 가능한 수치는 재현율(recall, 비율로 해석), JavaScript 통과/실패 여부, 구조적 동작입니다. 같은 맥락에서 하나 더 짚자면, Crawl4AI의 정적 카탈로그 테스트는 1페이지만 포함했기 때문에 6/6은 더 좁은 범위에서의 완전 재현율입니다. 반면 다른 도구들은 두 페이지를 모두 크롤링해 12/12를 기록했습니다. 즉, 범위가 더 작았던 것이지 일부를 놓친 것은 아닙니다. 이 모든 판단 근거는 방법론 문서에 테스트 파일별로 정리해 두었습니다.
숫자를 보기 전에 하나만 더 덧붙이겠습니다. 각 패키지에는 임시 연구 점수도 들어 있지만, 저는 그것을 의도적으로 순위표 형태로는 공개하지 않았습니다. 도구가 자기 증거와 얼마나 잘 맞는지 확인하기 위한 내부 보조값일 뿐, 리그 테이블이 아니기 때문입니다. 그런 숫자를 그대로 공개하면, 바로 이 실험이 피하려던 과도한 정밀성의 함정이 다시 생깁니다. 아래 내용은 벤치마크가 보여 준 것을 종합한 것이지, 공식 순위표가 아닙니다.
전체 도구를 한 벤치에 올려 보니
이 표에서 두 열, "Renders JS?"와 "Built-in crawl queue"만 내려다보면 세 가지 업무가 바로 드러납니다.
| 도구 | 언어 | JavaScript 렌더링? | 정적 재현율 | 구조화된 출력 | 내장 크롤 큐 | 설정 부담 | 라이선스 |
|---|---|---|---|---|---|---|---|
| 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/multi | 예 | 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 심층 크롤은 크롤 그래프 테스트에서 5개 페이지를 걸었고, JavaScript 페이지를 렌더링하면서 스크린샷도 캡처했습니다. 다만 두 가지 아쉬움이 있습니다. 원본 Markdown에는 콘텐츠 필터를 켜지 않으면 페이지 boilerplate가 그대로 남고, 의도적으로 만든 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 페이지를 렌더링했고, 스크립트 이후에 등장하는 Einstein 인용문이 출력에 들어가 렌더링이 진짜였음을 확인할 수 있었습니다. 제가 겪은 두 가지 문제는 Firecrawl 자체의 문제가 아니라 환경 문제였고, 혹시 다른 사람이 잘못된 해결법을 따라 하지 않도록 분명히 말해두고 싶습니다. 소스 빌드는 colima 아래에서 containerd snapshotter의 일시적인 오류에 걸렸고, 그래서 사전 빌드 이미지로 전환했습니다. 또 colima의 198.18.x.x DNS 범위가 Firecrawl의 SSRF 방어를 자극했는데, 이것은 ALLOW_LOCAL_WEBHOOKS=true로 해결했습니다. 이는 로컬 개발용 우회책일 뿐, 실제 배포에서 꺼서는 안 됩니다. 셀프 호스팅 코어에는 클라우드의 차단 우회 계층인 Fire-engine도 없고, 저는 클라우드 API도 테스트하지 않았습니다. 더 중요한 건 라이선스입니다. Firecrawl의 셀프 호스팅 코어는 AGPL-3.0이므로, 상업적으로 쓰기 전에는 반드시 법적 검토가 필요합니다. 2026년 7월 초 기준 스타 수는 약 14.8만입니다.
trafilatura는 이 무리에서 가장 반대편에 서 있는 도구이고, AI 과장 섞인 목록들이 가장 자주 잊는 도구이기도 합니다. 브라우저도 없고, 구조화된 행도 없습니다. 대신 순수 Python으로 빠르고 깔끔한 기사 본문 텍스트를 뽑아냅니다. 기사 테스트 파일에서는 제목과 실제 문단 3개 중 3개 전부를 가져왔고, boilerplate는 완전히 제거되어 "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 객체를 돌려줍니다). 둘 다 크롤 큐를 제공하지 않기 때문에, 12페이지 링크 그래프를 돌기 위해서는 직접 BFS를 작성해야 했습니다. 실제 차이는 범위뿐입니다. 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도 제공하는데, 이것이 Crawlee를 업무 3이 아니라 여기, 업무 2에 넣는 이유입니다. 다만 제목에 잘 안 적히는 한 가지가 있습니다. 브라우저 엔진은 별도의 npx playwright install이 필요하고, npm install crawlee만으로는 약 80 MiB의 브라우저 구성요소를 가져오지 않습니다. 버전 3.17.0, TypeScript, Apache-2.0, 스타 수는 약 2.46만입니다.
업무 3: 브라우저 없이 빠르게 크롤링하기
페이지에 JavaScript가 없다면 브라우저는 비싸고 과한 선택입니다. 여기서는 HTTP 우선 도구 세 개가 경쟁하고, 언어 철학별로 하나씩 나뉘어 흥미로운 차이를 보입니다.
Scrapy는 이 중 가장 엔지니어링 지향적인 프레임워크입니다. spider, JSON/CSV/XML feed export, AutoThrottle 등 갖출 건 다 갖췄습니다. 정적 재현율은 12/12였고, 기사 3개 문단도 모두 가져왔으며, 크롤 그래프에서는 깊이 0~2 범위에서 11페이지를 돌았고, handle_httpstatus_list를 통해 500 오류도 잡았습니다. 핵심은 세계관입니다. 렌더링하지 않고, 요청을 재현합니다. JavaScript 페이지에 던졌을 때는 0개 노드만 얻었지만, 그 페이지 뒤에 붙은 JSON API는 8/8을 가져왔습니다. 이것이 Scrapy 철학을 한 줄로 보여 주는 결과입니다. 페이지가 보내는 요청을 찾아 재생하라, 브라우저를 직접 돌리지 말라는 것이죠. 대신 Twisted, lxml, parsel 같은 꽤 큰 의존성 묶음이 따라오며, 저는 소규모 테스트 파일에만 적용했습니다. 버전 2.17.0, BSD-3-Clause, 스타 수는 약 6.3만입니다.
Colly는 Go 진영의 답이고, 자신이 무엇인지 매우 솔직합니다. 하나의 정적 바이너리, OnHTML, OnResponse, OnError 콜백 중심, 그리고 depth control까지. 정적 재현율은 12/12였고, JSON API에서는 OnResponse로 8/8을 가져왔으며, 500 오류는 OnError로 잡았고, 깊이 2 크롤에서는 17페이지에 도달했습니다. 다만 정확히 그렇게 표현해야 합니다. 그 페이지 수는 Colly가 보장하는 완전성 기준이 아니라, 테스트 하니스의 카운터값이기 때문입니다. JavaScript는 당연히 하지 않습니다. 동적 테스트 파일과 Quotes JS 사이트 모두 설계상 0이었습니다. 빌드하려면 Go 툴체인이 필요하고, 현재 모듈 버전(v2.3.0)은 태그된 릴리스(v2.2.0)보다 앞서 있습니다. Apache-2.0, 스타 수는 약 2.5만입니다.
Scrapling은 특화 도구이고, 그 이름값을 합니다. adaptive selector는 마크업이 바뀐 뒤에도 요소를 다시 찾아내도록 설계됐습니다. 그래서 대상 HTML 클래스 이름을 product-name에서 product-title로 바꿨을 때, 일반 셀렉터는 0을 반환했지만 adaptive re-match는 추적하던 요소를 다시 찾아냈습니다. 일반 HTTP 추출에서는 정적 12/12, JSON API에서는 8/8을 기록했습니다. 그리고 문서에서도 숨기지 않는 부분이 하나 있습니다. synthetic multi-element 테스트에서는 3개 중 1개만 복구했습니다. 즉, 이것은 회복 탄력적인 요소 추적이지, 완전 복구가 아닙니다. 머릿속에서 과장해서는 안 됩니다. 기본 pip install scrapling만으로는 시작이 안 되고, [fetchers] 추가 패키지가 필요합니다. 또 StealthyFetcher는 장점이라기보다 컴플라이언스상 주의사항에 가깝습니다. 버전 0.4.10(현재 릴리스), BSD-3-Clause, 스타 수는 약 6.87만입니다.
세 가지 업무 아래에 깔린 공통 패턴
9개 도구를 한 줄로 세워 보면 깔끔한 패턴이 드러납니다. 정적 페이지에서의 완전한 12/12 재현율은 HTTP 우선 도구라면 기본 요건일 뿐입니다. 그 쉬운 문제에서 모두 성공했으니, 그것만으로 차별화되지는 않습니다. 브라우저 도구가 추가 무게를 감수할 이유는 실제로 JavaScript가 개입할 때뿐이고, 그 비용은 설정에서 치릅니다. 브라우저 스택, 추가 설치, 또는 통째로 돌아가는 컨테이너 군집이 그 예입니다. 그리고 "내장 크롤 큐" 열은 결국 프레임워크와 엔진을 가르는 선입니다. Scrapy와 Crawlee는 오케스트레이션을 제공하고, Playwright와 Puppeteer는 BFS를 직접 쓰게 만듭니다. 이게 전체 판의 모양입니다. 아무도 같은 게임을 하고 있지 않으니, 전체 1등도 없습니다.
그렇다면 실제로 무엇을 골라야 하나
이 벤치마크가 승자를 뽑지 않는 이유는, 정답이 도구가 아니라 질문이기 때문입니다. 당신이 하고 있는 일이 세 가지 중 무엇인지가 중요합니다.
- LLM에 바로 넣을 수 있는 Markdown이 필요하다면? 깔끔한 기사 본문이 목적이라면 trafilatura를, CSS 추출과 JavaScript 렌더링을 한 라이브러리에서 함께 원한다면 Crawl4AI를, 셀프 호스팅 서비스가 필요하고 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의 AGPL-3.0 셀프 호스팅 코어만은 상업적 사용 전에 진지한 검토가 필요합니다.
하지만 벤치마크가 함께 보여 준 또 다른 사실도 있습니다. 이런 도구들이 하지 않는 일들 말입니다. 렌더링, 크롤링, 구조화, 차단 우회가 한 번에 다 되지는 않고, 유지보수 없이 굴러가지는 않습니다. 관리형 AI 스크래핑 API는 이 스택을 하나의 호출로 압축합니다. Thunderbit의 개발자용 인터페이스도 그런 선택지 중 하나이고, 기술 사용자에게 중요한 것은 브라우저 확장보다 API, MCP 서버, CLI입니다. POST /distill은 깔끔한 Markdown을 반환하고, POST /extract는 스키마 정의 JSON을 반환하며, JavaScript 렌더링과 안티봇 대응은 로컬 머신이 아니라 서버 측에서 처리됩니다. 에이전트와 코딩 어시스턴트를 위한 공식 MCP 서버도 있습니다. thunderbit_suggest_fields로 추출 계획을 무료로 짠 뒤, thunderbit_distill(1 크레딧)과 thunderbit_extract(20 크레딧)가 실제 작업을 수행합니다. 터미널과 cron 작업용으로는 npx @thunderbit/thunderbit-cli로 가져다 쓸 수 있는 CLI도 있습니다. 개발자가 아닌 팀원을 위해서는 노코드 Chrome 확장 프로그램도 있고, 요금제는 두 영역을 모두 다룹니다.
결국 선택지는 이 벤치마크가 끝내는 질문과 같습니다. 직접 9개의 라이브러리를 운영하며 호출당 비용 0원을 택할 것인지, 아니면 인프라를 넘기고 요청당 비용을 지불할 것인지입니다. 어느 쪽도 틀리지 않습니다. 얼마나 많은 스택을 직접 소유하고 싶은가의 문제일 뿐입니다. 실제 추출이 어떻게 보이는지 보고 싶다면 Thunderbit YouTube 채널에서 과정별 시연을 볼 수 있습니다.
{{INTERNAL_BLOG_LINKS}}
결론
단 하나의 최고의 오픈소스 스크래퍼는 없습니다. 그리고 자신 있게 하나를 찍어 주는 목록은, 사실 정답을 가르는 진짜 질문을 슬쩍 숨기고 있는 경우가 많습니다. 당신은 지금 텍스트를 뽑고 있나요, 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을 가져왔습니다), 별도의 브라우저 모드가 있어야 합니다.
사이트를 스크래핑하려면 헤드리스 브라우저가 꼭 필요한가요? JavaScript가 실행된 뒤에야 데이터가 나타나는 경우에만 필요합니다. 단순 HTTP 요청과 파서로 콘텐츠에 닿을 수 있다면 브라우저는 비싸고 과한 선택입니다. 그런 경우에는 Scrapy, Colly, Scrapling이 훨씬 가볍고 빠릅니다.
상업적 사용에 가장 우호적인 라이선스는 무엇인가요? 대부분은 관대합니다. Apache-2.0(Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) 또는 BSD-3-Clause(Scrapy, Scrapling)입니다. 예외는 Firecrawl의 셀프 호스팅 코어로, AGPL-3.0이기 때문에 상업용 제품에 적용하기 전에 반드시 라이선스 검토가 필요합니다.
이 벤치마크 수치는 재현 가능한가요? 네. 모든 실행기, 테스트 파일, 원본 결과가 공개 MIT 라이선스 저장소에 들어 있습니다. 다만 한 가지 기억할 점이 있습니다. 재현율과 구조적 결과는 도구 간 비교가 가능하지만, 절대 문자 수는 각 도구가 같은 정본이 아니라 자체 테스트 파일 복사본을 사용하기 때문에 도구 내부 신호로만 보아야 합니다. 따라서 비교할 때는 문자 총량이 아니라 비율과 통과/실패 여부를 보세요.
