지난해 전체 조직의 96%가 오픈 소스 사용을 늘리거나 유지했다는 사실이 2025 오픈 소스 현황 보고서에 나와 있습니다. 가장 큰 이유는 여전히 “라이선스 비용이 들지 않기 때문”입니다. 하지만 GitHub에서 스크래퍼를 하나 가져올 때 아무도 잘 알려주지 않는 사실이 있습니다. “오픈 소스”와 “상업용 제품에 안전하게 사용할 수 있음”은 같은 말이 아니라는 점입니다.
올해 꽤 많은 시간을 들여 Scrapy, Playwright, Puppeteer 같은 익숙한 도구들과 Crawl4AI, ScrapeGraphAI 같은 최신 AI 네이티브 크롤러를 살펴보면서 느낀 점은, 실제 비즈니스 의사결정에서 중요한 항목이 일반적인 “최고의 스크래퍼” 목록에는 거의 안 나온다는 것이었습니다. 대부분의 리스트는 GitHub 스타 수로 순위를 매깁니다. 저는 법무팀이 “잠깐, 이거 AGPL인가요?”라고 물었을 때 벌어지는 일을 기준으로 정렬합니다. 이 목록은 12개 도구를 먼저 용도 적합성 기준(파서, 브라우저 자동화, AI 네이티브 스크래퍼, 크롤링 프레임워크, 노코드 확장 프로그램)으로 나누고, 그다음 라이선스를 봅니다. 실제 의사결정도 늘 그런 순서로 진행되기 때문입니다.
오픈 소스 웹 스크래퍼를 고를 때 라이선스 유형이 가장 먼저 봐야 할 필터인 이유
“오픈 소스”가 “마음대로 다 해도 된다”는 뜻은 아닙니다. 오픈 소스 정의는 상업적 사용을 차별하는 것을 명시적으로 금지합니다. 그래서 이 목록에 있는 모든 도구는 비즈니스 사용이 가능합니다. 다만 어떤 방식으로 사용할 수 있는지, 그리고 배포할 때 어떤 의무가 생기는지는 각 라이선스에 따라 달라집니다.
MIT, BSD-3-Clause, Apache-2.0 같은 관대한(permissive) 라이선스는 저작권 표시만 유지하면 대부분 자유롭게 사용할 수 있게 해줍니다. Apache-2.0은 여기에 명시적인 특허 허가까지 포함되어 있어, 법무팀이 가장 선호하는 경우가 많습니다. 이 세 가지는 모두 자체 소스 코드를 공개할 의무가 없습니다.
반면 카피레프트 라이선스는 완전히 다릅니다. AGPL-3.0은 많은 사람들이 헷갈리는 라이선스이고, 정확히 Firecrawl의 자체 호스팅 코어가 이 라이선스로 배포됩니다(SDK는 MIT지만 핵심 스크래핑 엔진은 AGPL). AGPL-3.0 13조에 따르면, 적용 대상 프로그램을 수정한 뒤 네트워크를 통해 사용자가 그 수정 버전에 접근하도록 했다면 해당 소스 코드를 제공해야 합니다. 인터넷 포럼에서 흔히 말하는 것처럼 “전체 SaaS가 곧 오픈 소스가 된다”는 뜻은 아니고, 수정된 적용 대상 프로그램을 원격 상호작용에 제공할 때 생기는 의무가 핵심입니다. 하지만 이건 실제 법률 자문이 필요한 문제이지, Closed-source 제품 위에 얹기 전에 Stack Overflow 글 몇 개로 넘길 수 있는 사안이 아닙니다.
그다음은 좀 더 애매한 “오픈 코어” 범주입니다. Web Scraper Chrome 확장 프로그램은 GitHub에 LGPL-3.0 저장소가 있었지만, 그 저장소의 마지막 코드 커밋은 2017년이며 현재 Chrome Web Store에 올라온 확장 프로그램(작성 시점 기준 버전 1.111.13)과 그 오래된 소스 사이에 검증 가능한 연결도 없습니다. 솔직히 말하면, 로컬 확장 프로그램은 무료지만 스케줄링과 프록시 회전이 포함된 Cloud 요금제는 별도의 독점 제품입니다. 전체를 “오픈 소스”라고 부르면 이런 구분이 흐려집니다.
이 12개 최고의 오픈 소스 웹 스크래퍼 도구를 비교한 방법
저는 각 도구를 7가지 기준으로 평가했습니다. 라이선스 유형과 상업적 사용의 부담, 언어/런타임, 기본 JavaScript 렌더링 지원 여부(플러그인 조합이 필요한지 포함), 학습 난이도, 숨겨진 컴퓨팅 또는 프록시 비용, 커뮤니티 건강 지표(열린 이슈, 릴리스 주기, 마지막 커밋), 그리고 가장 적합한 사용 사례입니다.
이 목록은 별점 순이 아니라 카테고리별로 묶었습니다. 정적 파서, 브라우저 자동화 프레임워크, AI 네이티브 스크래퍼, 크롤링 프레임워크, 마지막으로 하나의 노코드 브라우저 확장 프로그램 순입니다. 이는 의도적인 선택입니다. Beautiful Soup과 Scrapy는 둘 다 매우 인기가 많지만 완전히 다른 문제를 해결합니다. 같은 축에서 순위를 매긴다고 해서 도구 선택에 실제 도움이 되지는 않습니다.
| 기준 | 확인한 항목 |
|---|---|
| 라이선스와 상업적 적합성 | 저장소의 정확한 라이선스, 저작자 표시 요구 사항, 카피레프트/네트워크 조항 |
| 런타임과 팀 적합성 | Python, Node/TypeScript, Java 또는 다중 언어 지원 |
| JS 렌더링 | 기본 브라우저 지원 여부, 플러그인 조합 필요 여부, 미지원 여부 |
| 프레임워크 범위 | 파서 전용, 브라우저 드라이버, 전체 크롤링 파이프라인, 또는 관리형 제품 |
| 커뮤니티 건강 | GitHub 스타 수, 최신 릴리스 날짜, 열린 이슈, 마지막 푸시 |
| 숨겨진 비용 | 브라우저 메모리, 프록시 필요 여부, 모델 API 의존성, 유지보수 부담 |
| 최적 적합성 | 문서화된 기능 또는 이슈를 바탕으로 한 구체적인 팀/작업 매칭 |
커뮤니티 건강 수치에 대한 솔직한 단서 하나를 먼저 말하자면, Beautiful Soup의 공식 개발은 GitHub가 아니라 Launchpad에서 이루어집니다. 따라서 GitHub 스타 수(여기서는 223개, 마지막 업데이트는 2022년인 비공식 미러)를 다른 도구들과 같은 기준으로 비교하기 어렵습니다. 아래에서 이 점을 명확히 짚겠습니다.
정적 사이트에 가장 좋은 오픈 소스 파싱 라이브러리: BeautifulSoup
BeautifulSoup은 HTML/XML 파트를 탐색하고 검색하기 위한 Python 라이브러리입니다. 페이지를 가져오지도 않고, JavaScript를 실행하지도 않고, 크롤링 큐를 관리하지도 않습니다. 이미 확보한 마크업을 친숙한 API로 파고들 수 있게 해줄 뿐입니다. 이 좁은 범위가 바로 핵심입니다. 이미 HTML을 갖고 있고 그 안에서 데이터를 뽑아야 할 때 꺼내 쓰는 도구입니다.
- 라이선스: MIT — 관대한 라이선스이며, 표기만 유지하면 별다른 의무가 없습니다
- 학습 난이도: 정말 초보자 친화적입니다. 객체 모델이 부담이 적습니다
- JS 렌더링: 기본적으로 없음 — 렌더링된 HTML을 먼저 가져오는 도구와 함께 써야 합니다
- 알려진 한계: 공식 문서에서도 “아래쪽 파서보다 절대 더 빠르지는 않을 것”이라고 인정합니다. 또한 파서 백엔드(lxml, html5lib, html.parser)에 따라 잘못된 HTML에서 서로 다른 트리를 만들 수 있습니다
추천 대상: 정적 HTML 또는 이미 가져온 HTML에서 빠르게 추출해야 하는 내부 스크립트와 단발성 작업. 대규모 운영이나 JS가 많은 사이트에는 적합하지 않습니다.
레거시 크로스브라우저 테스트에 가장 좋은 오픈 소스 브라우저 자동화 프레임워크: Selenium
Selenium은 이 목록에서 가장 오래된 이름입니다. 원래는 브라우저 테스트용으로 만들어졌지만, 이후 스크래핑 업계의 절반이 용도를 바꿔 사용해 왔습니다. 이 도구의 핵심은 속도가 아니라 범용성입니다. 공식 Selenium 4 바인딩은 Java, Python, C#, Ruby, JavaScript를 지원하고, W3C WebDriver 표준을 통해 Chrome, Edge, Firefox, Safari를 제어합니다.
- 라이선스: Apache-2.0
- GitHub 상태: 34,366개 스타, 열린 이슈 98개, 지난 1년간 안정 릴리스 12개(최신: 4.47.0)
- JS 렌더링: 실제 브라우저를 통해 기본 지원
- 문서화된 불편 요소: Selenium 자체 문서에서도 동기화를 “가장 흔한 과제 중 하나”라고 지적합니다. 문서가 준비되었다고 해서 JS로 추가된 요소까지 준비됐다는 뜻은 아니며, 동적 DOM이 새로 고쳐지면
StaleElementReferenceException이 발생합니다
추천 대상: 멀티브라우저 또는 멀티언어 커버리지가 필요한 팀, 또는 QA에 이미 Selenium을 쓰고 있어 스크래핑에도 같은 역량을 재사용하고 싶은 팀.
최신 JS 중심 사이트에 가장 좋은 오픈 소스 브라우저 자동화 프레임워크: Playwright
Microsoft가 유지보수하는 Playwright는 “Selenium은 느리고 번거롭다”는 불만에 대한 현대적인 해답입니다. Chromium, Firefox, WebKit을 기본적으로 자동화하며, 요소가 실제로 준비될 때까지 자동 대기하는 actionability 검사를 제공합니다. 보이기, 안정성, 활성화 상태를 확인한 뒤 상호작용하기 때문에, 이 자동 대기만으로도 Selenium 사용자가 수동으로 작성하던 WebDriverWait 보일러플레이트를 상당히 줄여줍니다.
여기서 많은 “Scrapy vs. Playwright vs. Selenium” 글에서 놓치는 중요한 차이가 있습니다. Scrapy는 자체적으로 JavaScript를 렌더링하지 않습니다. 브라우저 렌더링을 위해서는 scrapy-playwright라는 별도 플러그인을 붙여야 합니다. 반면 Playwright와 Puppeteer는 렌더링 자체가 제품이므로 기본적으로 렌더링합니다.
- 라이선스: Apache-2.0
- GitHub 상태: 94,443개 스타, 지난 1년간 안정 릴리스 15개(최신: 1.62.1)
- 숨겨진 비용: 브라우저 바이너리만 해도 Chromium 약 281MB, Firefox 187MB, WebKit 180MB가 필요합니다. 또한 1.38의 변경으로 브라우저 자동 다운로드가 중단되었기 때문에 Docker 이미지 버전 고정이 중요합니다
추천 대상: React/Vue 기반 싱글 페이지 앱을 안정적으로 스크래핑하면서 수동 대기 로직을 직접 짜고 싶지 않은 팀.
Chrome 중심 프로젝트에 가장 좋은 오픈 소스 브라우저 자동화 도구: Puppeteer
Google의 자동화 라이브러리인 Puppeteer는 설계상 Chrome 우선입니다. Chrome DevTools Protocol과의 깊은 통합, 기본 스크린샷/PDF 생성 기능 등 필요한 기능을 갖추고 있습니다. 다만 한 가지 오래된 인식은 바로잡을 필요가 있습니다. 현재 Puppeteer는 안정판 Firefox도 공식 지원하므로, 이제 “Chrome 전용”이라고 부르기는 어렵습니다. 그래도 여전히 주 사용처는 Chrome입니다.
- 라이선스: Apache-2.0
- GitHub 상태: 95,458개 스타, 열린 이슈 249개 — Playwright보다 열린 이슈 수가 눈에 띄게 많아 대응 속도를 볼 때 참고할 만합니다
- 안티봇 현실 체크: Puppeteer 이슈 #7006는 완전히 정상적인 탐색이 Cloudflare 챌린지에 걸린 사례를 기록합니다. 페이지를 렌더링한다고 해서 안티봇 시스템에 보이지 않게 되는 것은 절대 아닙니다
추천 대상: Chrome을 표준으로 쓰는 Node.js 팀, 특히 스크래핑과 함께 PDF/스크린샷 생성이 필요한 경우.
LLM 및 RAG 파이프라인에 가장 좋은 오픈 소스 AI 네이티브 스크래퍼: Crawl4AI
Crawl4AI는 내부적으로 Playwright를 사용하며, 원시 HTML 덩어리 대신 LLM 및 RAG 파이프라인용으로 깔끔한 Markdown을 출력하도록 설계되었습니다. “clean Markdown” 모드와 컨텍스트 윈도우에 맞춘 “Fit Markdown” 모드를 모두 지원하고, 필요하면 LLM 기반 추출도 사용할 수 있습니다. CSS/XPath와 BM25 필터링은 모델 API를 전혀 건드리지 않고도 동작합니다.
정확히 짚어둘 점이 하나 있습니다. GitHub에서는 저장소를 Apache-2.0으로 표시하지만, 실제 라이선스 파일에는 공개 사용 및 배포 시 필수 저작자 표시 조건이 추가되어 있습니다. 이것은 일반적인 Apache-2.0이 아니라, 프로젝트 고유 조건이 붙은 Apache-2.0입니다. GitHub 사이드바 배지보다 실제 라이선스 파일을 읽어야 합니다.
- GitHub 상태: 77,959개 스타, 최신 릴리스 v0.9.2(2026년 7월)
- 리소스 요구사항: 셀프 호스팅 가이드는 컨테이너에 최소 4GB RAM을 권장합니다
- 문서화된 불안정성: v0.9.0 변경 로그에는 Docker 서버 인증 기본값 변경과 모듈 이동 등 파괴적 변경이 기록되어 있습니다. 빠르게 변하는 프로젝트이므로 버전을 고정하세요
추천 대상: 새 웹 데이터를 LLM 에이전트나 RAG 파이프라인에 공급하는 Python 팀으로, 브라우저 인프라를 직접 운영할 수 있는 경우.
자체 호스팅 배포에 가장 좋은 오픈 소스 AI 네이티브 스크래퍼(단, 라이선스 주의): Firecrawl
Firecrawl의 자체 호스팅 코어는 AGPL 이야기가 가장 현실적으로 드러나는 부분입니다. Markdown, HTML, 스크린샷, 구조화 데이터를 반환하는 API 우선 크롤러로, Fetch와 Playwright 위에 구축되어 꽤 강력합니다. 하지만 사람들이 “Firecrawl”이라고 들으면 떠올리는 세련된 기능들—관리형 안티봇 처리, 프록시 회전, Fire-engine 스텔스 계층—은 자체 호스팅 저장소가 아니라 Firecrawl Cloud에 속합니다. Firecrawl 자체 호스팅 문서에도 Fire-engine과 고급 안티봇 동작은 기본 자체 호스팅 스택에 포함되지 않으며, 스크린샷/페이지 동작에는 필요하다고 명시되어 있습니다.
- 라이선스: 핵심은 주로 AGPL-3.0-or-later, SDK는 MIT
- GitHub 상태: 166,527개 스타 — 이 카테고리에서는 정말 엄청난 수치입니다
- 설치 현실: 자체 호스팅은 Redis, RabbitMQ, PostgreSQL, 필요 시 FoundationDB까지 구축해야 합니다. 단일 컨테이너로 끝나는 작업이 아닙니다
추천 대상: 내부 도구나, AGPL의 소스 제공 의무를 받아들일 수 있는 오픈 소스 프로젝트. 닫힌 소스 상용 제품을 이 코어 위에 직접 얹으려면 법률 검토 없이 진행하지 마세요.
자연어 추출에 가장 좋은 오픈 소스 AI 네이티브 스크래퍼: ScrapeGraphAI
ScrapeGraphAI는 셀렉터를 직접 작성하지 않고도 원하는 내용을 자연어로 설명하면 됩니다. LLM 호출이 필드 매핑을 담당하는 그래프 기반 파이프라인입니다. MIT 라이선스 라이브러리지만 사용하는 인프라는 사용자가 직접 준비해야 합니다. LLM API 키(토큰 비용을 피하고 싶다면 로컬 Ollama 모델도 가능)와 설정한 Playwright 인스턴스가 그것입니다.
여기서 분명히 짚어야 할 함정이 있습니다. “오픈 소스”라고 해서 “지속 비용이 전혀 없다”는 뜻은 아닙니다. 추출할 때마다 연결한 모델에 따라 토큰이 소모됩니다. 또한 프롬프트 기반 추출에는 셀렉터 기반 도구에는 없는 고유한 실패 모드가 있습니다. 한 개의 열린 이슈는 파이프라인이 모든 단계를 성공적으로 마쳤다고 나오는데도 페이지에 분명히 있던 데이터가 빈 값/NA로 반환되는 사례를 보고합니다. 결정적(deterministic) CSS/XPath 방식에서는 잘 발생하지 않는, 조용한 실패입니다.
- 라이선스: MIT
- GitHub 상태: 29,447개 스타, 최신 안정판 v2.1.6
추천 대상: 프롬프트 유연성이 모델 비용과 검증 부담보다 더 중요한, 불규칙한 단발성 추출 작업.
가볍고 모델 없이 쓰는 오픈 소스 스크래퍼: AutoScraper
AutoScraper는 LLM을 완전히 건너뜁니다. URL과 추출하고 싶은 샘플 값을 주면 페이지에서 구조적 규칙을 추론하고 비슷한 페이지에 재사용합니다. 모델 API 키도, 토큰 요금도 없습니다. 내부적으로는 requests와 BeautifulSoup만 사용합니다.
일부 포럼 글에서 이 도구를 “방치된 프로젝트”라고 부르기도 하지만, 그건 정확하지 않습니다. 2025년 중반에도 실제 커밋이 있었고 저장소의 마지막 푸시도 2026년 7월입니다. 다만 사용자가 실제로 pip install하게 되는 패키지 릴리스는 여전히 2022년의 v1.1.14입니다. “패키지 릴리스 주기가 느리다”는 표현이 맞고, “죽은 프로젝트”라고 하기는 어렵습니다.
- 라이선스: MIT
- GitHub 상태: 7,844개 스타
- 명확한 한계: 기본 JavaScript 렌더링이 없습니다.
requests.get()으로 가져온 HTML만 파싱합니다
추천 대상: 구조가 안정된 정적 페이지에서 소규모 반복 추출을 해야 하는 경우. 디자인 개편 후 가끔 다시 학습하는 정도는 감수할 수 있을 때 적합합니다.
대규모 Python 프로젝트에 가장 좋은 오픈 소스 크롤링 프레임워크: Scrapy
Scrapy는 운영 환경에 맞는 Python 크롤링 프레임워크입니다. 엔진, 스케줄러, 다운로더, 아이템 파이프라인까지 갖춘 완성형입니다. Beautiful Soup이 메스라면 Scrapy는 수술실 전체에 가깝습니다. 비동기 네트워킹, 도메인별 동시성 제어, AutoThrottle, 그리고 CSV, JSON, JSON Lines, XML 또는 클라우드 스토리지로 바로 쓰는 익스포터를 제공합니다.
앞서 언급한 뉘앙스를 여기서도 다시 말해야 합니다. Scrapy의 가장 큰 오해는 기본적으로 JavaScript 렌더링을 하지 않는다는 점입니다. Scrapy 공식 문서는 전체 브라우저를 렌더링하는 것보다, 먼저 실제 데이터 요청을 찾아 재현하는 것이 보통 더 빠르고 더 완전하다고 권장합니다. JS가 정말 피할 수 없을 때만 scrapy-playwright를 사용하라고 안내합니다.
- 라이선스: BSD-3-Clause
- GitHub 상태: 63,830개 스타, 열린 이슈 304개, 지난 1년간 안정 릴리스 9개(최신: 2.17.0)
- 속도 제한 관련 공백: 열린 개선 요청은 AutoThrottle가 HTTP 429 응답이 아니라 지연 시간 기준으로 튜닝한다고 지적합니다. 응답 인식형 백오프는 여전히 직접 만들어야 합니다
추천 대상: 구조화된 파이프라인과 내보내기 유연성이 JS 렌더링보다 중요한 대규모 정적 사이트 크롤링.
Node.js 프로덕션 빌드에 가장 좋은 오픈 소스 크롤링 프레임워크: Crawlee
Apify 팀의 Crawlee는 Scrapy에 가장 가까운 Node/TypeScript 대응 도구입니다. 다만 JavaScript 렌더링이 나중에 덧붙는 것이 아니라, 공통 큐, 저장소, 프록시 회전 계층 아래에서 Playwright 및 Puppeteer 기반 크롤러 클래스와 함께 처음부터 내장되어 있습니다.
- 라이선스: Apache-2.0
- GitHub 상태: 25,364개 스타, 지난 1년간 안정 릴리스 8개(최신: 3.18.1)
- 주목할 점:
AutoscaledPool은 실시간 CPU, 메모리, 이벤트 루프 부하에 따라 동시성을 동적으로 조정합니다. 또한 최소 동시성을 너무 높게 잡으면 전체 크롤링이 중단될 수 있다고 문서에서 명시적으로 경고합니다
추천 대상: Scrapy와 비슷한 수준의 큐 관리와 JS 렌더링이 필요하지만, 구성 요소를 직접 엮고 싶지 않은 Node.js/TypeScript 팀.
엔터프라이즈 Java 인덱싱에 가장 좋은 오픈 소스 크롤링 프레임워크: Apache Nutch
Apache Nutch는 이 목록의 이단아입니다. 대규모 웹 인덱싱을 위해 만들어진 Java 크롤러로, 보통 Solr, Elasticsearch, OpenSearch와 연동됩니다. 경쟁사 사이트에서 상품 가격만 뽑아오려는 용도로 쓰는 도구가 아닙니다. 검색 색인 아래단의 크롤링 계층을 구축하는 엔터프라이즈 검색 팀이 선택하는 도구입니다.
- 라이선스: Apache-2.0
- GitHub 상태: 스타 수는 3,276개에 불과하지만 2026년 8월에도 최근 푸시가 있었습니다. 이 낮은 수치는 방치가 아니라 특화된 니치를 반영합니다
- JS 처리: 별도의
protocol-selenium플러그인이 필요합니다. JIRA 이슈는 해당 플러그인 경로에서 HTTPS 프록시 실패를 기록합니다
추천 대상: Java/Hadoop 인프라를 이미 운영 중이며, 임시 데이터 추출이 아니라 엔터프라이즈 규모 웹 인덱싱이 필요한 팀.
가장 좋은 오픈 소스 노코드 브라우저 확장 프로그램: Web Scraper
Web Scraper는 클릭해서 쓰는 방식의 도구입니다. Chrome DevTools 안에서 동작하는 사이트맵 및 셀렉터 트리 빌더라고 보면 됩니다. 페이지네이션을 따라가고, 버튼을 클릭하고, 무한 스크롤 페이지를 내려가며, 코드 한 줄 없이 CSV/XLSX로 로컬 내보내기를 할 수 있습니다.
이 목록에서 오픈 코어 구분이 거의 어디보다 중요합니다. 로컬 추출은 정말 무료입니다. 하지만 예약 자동화, 클라우드 실행, API 접근, 프록시 관리는 모두 별도 유료 제품인 Web Scraper Cloud 뒤에 있습니다. 앞서 언급했듯이 공개된 LGPL-3.0 소스 저장소는 2017년 이후 코드 커밋이 없습니다. 따라서 “오픈 소스”는 현재 Chrome Web Store 빌드가 아니라, 로컬 확장 프로그램의 역사적 계보를 설명하는 말로 이해해야 합니다.
추천 대상: 코드를 작성하지 않으면서, 가끔 로컬로 추출만 하면 되는 개인 또는 소규모 팀.
정적 파서 vs. 헤드리스 브라우저: JS가 많은 사이트에 맞는 도구 고르기
이 판단을 뒷받침할 수치 하나를 보자면, 웹사이트의 98.9%가 클라이언트 사이드 언어로 JavaScript를 사용합니다. 하지만 이 수치는 자주 “사이트의 98.9%를 스크래핑하려면 헤드리스 브라우저가 필요하다”는 식으로 잘못 인용됩니다. 실제 의미는 그게 아닙니다. 이 수치는 JavaScript의 존재를 측정할 뿐, 원하는 데이터가 초기 HTML 안에 있는지 아니면 스크립트 실행 후에만 나타나는지를 말해주지 않습니다.
바로 그 차이가 실제 의사결정 포인트입니다. 12개 도구를 두 가지 정직한 범주로 나눌 수 있습니다.
정적 파서 — BeautifulSoup, AutoScraper — 는 빠르고 저렴하며, 클라이언트 측에서 렌더링되는 것은 완전히 보지 못합니다. 원하는 데이터가 초기 HTML 응답에 있거나 직접 호출 가능한 JSON 엔드포인트에 있다면, 속도와 단순성 면에서 항상 이 도구들이 유리합니다.
헤드리스 브라우저 프레임워크 — Playwright, Puppeteer, Selenium, Crawlee의 브라우저 크롤러 — 는 실제로 JavaScript를 실행합니다. 즉, 실제 컴퓨팅 비용이 듭니다. HTTP Archive의 2024 데이터에 따르면 모바일 기준 중간 페이지의 JavaScript 페이로드는 558KB이고, JS 요청은 22개입니다. 헤드리스 브라우저는 매 페이지 로드마다 그 작업을 처리해야 하지만, 정적 파서는 그냥 원시 HTML만 가져오면 됩니다.
그리고 Scrapy는 다시 한 번 강조할 만한 중간 지점에 있습니다. 기본 렌더링이 전혀 없는 완전한 크롤링 프레임워크이며, JS가 필요하면 scrapy-playwright를 붙여야 합니다.
“무료”의 숨은 비용: 프록시, 컴퓨팅, 유지보수 시간
라이선스 비용이 0달러라는 것은 총비용의 한 요소일 뿐, 전부는 아닙니다. 실제 비용은 대략 몇 개의 항목으로 나눌 수 있습니다.
컴퓨팅. 헤드리스 브라우저를 대규모로 돌린다는 것은 서버 시간만이 아니라 브라우저 초 단위 비용을 지불한다는 뜻입니다. AWS Fargate는 Linux/x86 기준으로 vCPU-초당 약 $0.000011244, GB-초당 약 $0.000001235를 청구합니다. 실행 중인 Playwright 인스턴스 수를 곱해 보면 생각보다 훨씬 빨리 늘어납니다.
프록시. Bright Data의 공개 요금에서는 주거용 프록시가 GB당 약 $5부터, 데이터센터 프록시는 IP당 $0.9부터 시작합니다. 이 요금 체계에서 “대역폭”에는 다운로드뿐 아니라 요청과 응답 페이로드가 모두 포함됩니다. 속도 제한과 차단을 피하는 일은 공짜가 아니라, 인프라 예산의 반복 항목입니다.
유지보수. 이 목록의 모든 정적 파서와 구조 규칙 기반 도구는 사이트 개편으로 셀렉터가 깨질 위험이 있습니다. AutoScraper의 README 예제도 대상 사이트의 변경 후 가격을 업데이트해야 했습니다. 이것이 라이선스에 적힌 $0 태그가 말해주지 않는 “숨은 컴퓨팅/프록시 비용”입니다. 결국 대상 사이트 개발팀이 개편을 배포했을 때 깨진 추출 로직을 고치느라 쓰는 엔지니어 시간입니다.
이 벽에 계속 부딪히는 팀—셀렉터가 자주 깨지고, 프록시 계정 관리를 해야 하고, 끝이 없는 DevOps 오버헤드가 발생하는 팀—에게는, 엔지니어 시간을 포함하면 자체 호스팅 오픈 소스 스택이 자동으로 더 저렴한 선택은 아닙니다. 개발자가 아닌 사용자를 위해 Thunderbit의 Chrome 확장 프로그램은 다른 접근을 제공합니다. 권한이 있는 페이지를 열고 One Click Extract를 누르면, 페이지를 분석해 무엇을 뽑아야 하는지 파악합니다. 셀렉터도 없고, 레이아웃이 바뀔 때마다 고쳐야 하는 유지보수 스크립트도 없습니다. Scrapy 수준의 크롤링 프레임워크를 대체하는 것은 아니지만, 깨지기 쉬운 AutoScraper 규칙 세트를 손으로 유지해 온 비개발자에게는 합리적인 다음 단계입니다.
의사결정 프레임워크: 팀의 제약에 맞는 도구 고르기
대부분의 비교 글은 “어떤 사용 사례에 최고인가”에서 끝납니다. 그건 변수 하나만 보는 셈입니다. 실제로는 팀이 최소 네 가지를 동시에 따집니다. JS 렌더링 필요 여부 × 팀 언어 × 필요한 출력 형식 × 라이선스 제약입니다.
| 팀 상황 | 최적 도구 | 이유 |
|---|---|---|
| Python, 정적 HTML, 빠른 스크립트 | BeautifulSoup, AutoScraper | JS 불필요, MIT 라이선스, 최소 설정 |
| Python, 대규모 구조화 크롤링 | Scrapy | BSD-3-Clause, 기본 파이프라인 포함, JS가 정말 필요할 때만 scrapy-playwright 추가 |
| Node/TypeScript, JS 포함 프로덕션 크롤링 | Crawlee | Apache-2.0, 큐 시스템에 기본 브라우저 지원 내장 |
| 다중 언어, 다양한 브라우저 조합 | Selenium | Apache-2.0, 가장 넓은 언어/브라우저 지원 |
| 현대 SPA 자동화, 크로스브라우저 | Playwright | Apache-2.0, 기본 렌더링과 자동 대기 내장 |
| Chrome 전용 자동화 및 스크린샷/PDF | Puppeteer | Apache-2.0, CDP와 깊게 통합 |
| LLM/RAG Markdown 파이프라인 | Crawl4AI | Apache-2.0 + 저작자 표시 조항. 추가 조건을 법무팀이 받아들일 수 있는지 확인 필요 |
| 프롬프트 기반, 비정형 추출 | ScrapeGraphAI | MIT, 하지만 LLM 토큰 비용 예산 필요 |
| API에 맞춘 자체 호스팅 크롤러, AGPL 허용 가능 | Firecrawl | AGPL-3.0-or-later. 닫힌 소스 SaaS 위에 올리기 전 법률 검토 필요 |
| 엔터프라이즈 Java/Hadoop 인덱싱 | Apache Nutch | Apache-2.0, 검색 인프라용으로 설계됨 |
| 노코드, 가끔 쓰는 비개발자 | Web Scraper 확장 프로그램 | 로컬에서는 무료. 전체 투명성을 가정하기 전 오픈 코어 구분을 이해해야 함 |
12개 오픈 소스 웹 스크래퍼 도구를 한눈에 비교
| 도구 | 언어 | 라이선스 | 상업적 사용 가능? | JS 렌더링 | 학습 난이도 | 추천 용도 |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ 예 | 없음(별도 조합 필요) | 낮음 | 정적 HTML 파싱 |
| Selenium | 다중 언어 | Apache-2.0 | ✅ 예 | 기본 지원 | 중간 | 멀티브라우저/멀티언어 테스트-스크래핑 |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ 예 | 기본 지원 | 중간 | 최신 JS 중심 사이트 |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ 예 | 기본 지원 | 중간 | Chrome 중심 자동화 |
| Crawl4AI | Python | Apache-2.0 + 저작자 표시 조항 | ⚠️ 조항 검토 필요 | 기본 지원(Playwright 경유) | 중간 | LLM/RAG Markdown 파이프라인 |
| Firecrawl(자체 호스팅) | TypeScript | AGPL-3.0-or-later(코어) | ⚠️ 조건부 | 기본 지원(Playwright 경유) | 높음(다중 서비스) | 자체 호스팅 AI 크롤링, AGPL 허용 가능 |
| ScrapeGraphAI | Python | MIT | ✅ 예 | 기본 지원(Playwright 경유) | 중간 | 자연어 추출 |
| AutoScraper | Python | MIT | ✅ 예 | 없음 | 낮음 | 가벼운 반복형 정적 작업 |
| Scrapy | Python | BSD-3-Clause | ✅ 예 | 별도 조합 필요 | 높음 | 대규모 정적 사이트 크롤링 |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ 예 | 기본 지원 | 중간 | Node.js 프로덕션 크롤러 |
| Apache Nutch | Java | Apache-2.0 | ✅ 예 | 플러그인 필요 | 높음 | 엔터프라이즈 검색 인덱싱 |
| Web Scraper(확장 프로그램) | 해당 없음(노코드) | 오픈 코어 | ⚠️ 요금제에 따라 다름 | 기본 지원(실제 브라우저) | 낮음 | 비개발자의 가끔 쓰는 용도 |
결론: 어떤 오픈 소스 웹 스크래퍼를 써야 할까?
여기에는 단 하나의 “최고” 도구가 없습니다. 정답은 라이선스 제약, 팀의 언어, 그리고 대상 데이터가 정적 HTML에 있는지 아니면 JavaScript 벽 뒤에 있는지에 달려 있습니다. 대규모 정적 Python 크롤링에는 Scrapy가 강합니다. JS 렌더링이 절대적으로 필요하면 Playwright나 Crawlee가 유리합니다. LLM 파이프라인에 데이터를 넣는다면 Crawl4AI가 잘 맞지만, 라이선스 파일에 추가 저작자 표시 조항이 있으니 꼭 한 번 읽어보는 것이 좋습니다. Firecrawl의 자체 호스팅 코어는 강력하지만 AGPL 이슈가 있어, 법무팀이 이를 검토 과정에서 빠져서는 안 됩니다.
그리고 셀렉터 유지보수와 프록시 관리가 스크래핑 자체보다 더 많은 엔지니어 시간을 잡아먹고 있다면, 자체 호스팅 OSS 스택에 또 다른 층을 더하는 것보다 Thunderbit 같은 노코드 대안을 검토할 시점이라는 신호인 경우가 많습니다.
오픈 소스 웹 스크래퍼 도구 FAQ
비즈니스 데이터 수집에 오픈 소스 웹 스크래퍼 도구를 사용하는 것은 합법인가요?
일반적으로 공개된 데이터의 스크래핑은 로그인 뒤나 유료 벽 뒤의 데이터를 스크래핑하는 것보다 위험이 낮지만, 그렇다고 무조건 합법인 것은 아닙니다. 대상 사이트의 이용 약관과 robots.txt를 반드시 확인하세요. 다만 robots.txt는 허가 메커니즘이 아니라 요청 프로토콜이라는 점도 알아두어야 합니다. 따르는 것은 좋은 관행이지만, 그 자체가 법적 허가를 의미하지는 않습니다. GDPR 같은 데이터 보호법도 데이터가 공개되어 있더라도 적용됩니다. 이는 법률 자문이 아니므로, 가볍고 소량인 사용을 넘는다면 변호사와 상의하세요.
“오픈 소스”면 상업적으로 무료로 쓸 수 있다는 뜻인가요?
네, 오픈 소스 정의는 라이선스가 상업적 사용을 차별하는 것을 금지하므로 그 의미에서는 그렇습니다. 하지만 “상업적으로 사용할 수 있음”과 “의무가 없음”은 다른 이야기입니다. Firecrawl의 자체 호스팅 코어에 쓰인 AGPL-3.0은 상업적 사용은 허용하지만, 네트워크를 통해 제공되는 수정 버전에 대해서는 대응 소스 제공을 요구합니다. MIT, BSD, Apache-2.0에는 그런 요구가 없습니다.
오픈 소스 스크래퍼와 노코드 스크래핑 도구의 차이는 무엇인가요?
Scrapy, Playwright, BeautifulSoup 같은 오픈 소스 스크래퍼는 코드를 작성하고 인프라를 관리하며, 자체 크롤링 로직, 프록시, 내보내기까지 직접 처리해야 합니다. Web Scraper Chrome 확장 프로그램이나 Thunderbit의 브라우저 확장 프로그램 같은 노코드 도구는 시각적 인터페이스나 AI 기반 페이지 분석으로 필드 감지와 추출을 처리합니다. 유연성은 조금 줄어들지만 설정 장벽이 크게 낮아집니다.
비개발자에게 가장 좋은 오픈 소스 웹 스크래퍼는 무엇인가요?
이 목록의 대부분 도구—Scrapy, Playwright, Puppeteer, Crawlee 등—는 기본적으로 코드를 쓸 수 있다고 가정합니다. 비기술 사용자라면 Web Scraper Chrome 확장 프로그램이 클릭 기반 설정을 제공하지만, 스케줄링과 클라우드 기능은 유료 요금제 뒤에 있습니다. 셀렉터를 직접 건드리지 않고 자동 필드 감지를 원한다면 Thunderbit의 브라우저 확장 프로그램 같은 에이전틱 노코드 도구가 더 실용적인 출발점입니다.
Scrapy가 JavaScript 렌더링을 위해 별도 플러그인이 필요한 이유는 무엇인가요?
Scrapy는 HTTP 우선 프레임워크로 설계되었습니다. 즉, 요청을 보내고 돌아온 HTML을 파싱할 뿐, 클라이언트 측 스크립트는 실행하지 않습니다. 이 구조는 정적 사이트 크롤링에는 빠르고 가볍지만, JavaScript로 렌더링된 콘텐츠는 Scrapy가 받는 응답 안에 아예 존재하지 않습니다. scrapy-playwright는 렌더링이 정말 불가피할 때 실제 Playwright 브라우저 인스턴스로 특정 요청을 보내 이 간극을 메워줍니다.
더 알아보기
