대부분의 사람들은 Crawlee를 “어떤 헤드리스 브라우저를 써야 하지?”라는 또 다른 질문을 찾다가 처음 접합니다. 그런데 사실 그 질문 자체가 빗나가 있고, 바로 그 점이 Crawlee의 핵심입니다. Crawlee는 브라우저가 아닙니다. 필요할 때는 브라우저를 감싸서 쓰고, 필요 없을 때는 아예 브라우저 없이도 돌아가는 Node/TypeScript 프레임워크입니다.
저는 Node v22.22.3과 macOS 환경에서, 통제된 테스트용 샘플과 몇 개의 공개 데모 사이트를 대상으로 Crawlee 3.17.0을 며칠 동안 직접 돌려봤습니다. 특히 “하나의 라이브러리, 하나의 API, 내부에는 HTTP 크롤러 또는 실제 브라우저”라는 핵심 구조가 정말 맞는지 집중해서 확인했습니다. 결국 중요한 건 그 주장이 Crawlee를 스택에 넣을 만큼 가치가 있는지, 아니면 그냥 Playwright를 직접 쓰는 편이 나은지를 가르는 기준이기 때문입니다. 짧게 말하면: 두 엔진 전략은 대체로 실제로 잘 작동합니다. 다만 몇 가지 예외는 뒤에서 짚어보겠습니다.
Crawlee는 정확히 무엇이고, 무엇이 아닌가
Crawlee는 Node.js용 웹 스크래핑 및 브라우저 자동화 라이브러리로, 안정적인 크롤러를 쉽게 만들 수 있게 설계됐다고 설명합니다. 공식 소개를 보면 범위가 꽤 넓습니다. AI, LLM, RAG, GPT용 데이터 추출, HTML/PDF/JPG/PNG 같은 파일 다운로드, Puppeteer/Playwright/Cheerio/JSDOM/순수 HTTP 지원, headful/headless 모두 가능, 프록시 로테이션까지 다룹니다. 범위가 넓은 만큼, 무엇이 아닌지도 분명히 해둘 필요가 있습니다.
Crawlee는 렌더링 엔진이 아닙니다. 자체 브라우저를 품고 있지 않습니다. JavaScript 실행이 필요하면 Crawlee가 Playwright나 Puppeteer를 띄우고, 그 도구가 다시 Chromium(또는 다른 브라우저)을 제어합니다. 또 네트워크 너머에서 호출하는 호스팅 서비스도 아닙니다. 직접 설치해서 로컬이나 자신의 환경에서 실행하는 의존성입니다. 정확히 말하면 Crawlee는 페처 위에 얹히는 레이어입니다. 크롤러 클래스, 요청 큐, 스토리지, 링크 추적 로직이 그 역할을 맡습니다. 즉, 아래에 교체 가능한 엔진을 두고 크롤링 전체를 관리하는 프레임워크라고 보면 됩니다.
참고로 제가 테스트한 버전은 3.17.0(2026-06-04 릴리스)이고, TypeScript 기반이며, 라이선스는 Apache-2.0입니다. apify/crawlee의 별점은 2026-07-09 기준 약 24.6k였습니다. 별점은 계속 바뀌므로 이 숫자는 고정값이 아니라 스냅샷으로 보는 게 맞습니다. 제가 지켜본 이틀 동안에도 53개가 늘었습니다.
두 엔진: CheerioCrawler vs PlaywrightCrawler
바로 여기서 이 설계의 진가가 드러났고, 저도 가장 오랫동안 들여다본 부분입니다.
CheerioCrawler는 HTTP 경로입니다. 원격에서 HTML을 그대로 받아와 Cheerio로 파싱합니다. 브라우저도 없고, JavaScript 실행도 없고, 렌더링도 하지 않습니다. 그래서 빠르고 가볍습니다. PlaywrightCrawler는 브라우저 경로입니다. 실제 Chromium을 실행해 DOM을 렌더링하고, 페이지 안의 JavaScript까지 반영하며, 스크린샷도 찍을 수 있습니다.
기능은 완전히 다르지만, Crawlee가 말하는 핵심은 둘이 같은 사용 경험을 제공한다는 점입니다. 둘 다 requestHandler를 받습니다. 둘 다 run()을 제공합니다. 둘 다 enqueueLinks로 링크를 따라갑니다. 한 엔진에서 다른 엔진으로 옮기는 일은 재작성이라기보다 클래스만 바꾸는 수준에 가깝습니다. 저는 추출 로직을 바이트 단위로 똑같이 유지한 채, 그 로직을 감싸는 크롤러 클래스만 교체해서 이걸 확인했습니다.
여기서 꼭 짚고 넘어갈 부분이 하나 있습니다. 바로 콘텐츠를 다루는 핸들입니다. CheerioCrawler의 핸들러 안에서는 $를 받는데, 이미 파싱된 정적 DOM이라 jQuery처럼 조회할 수 있습니다. 반면 브라우저 핸들러에서는 살아 있는 page 객체를 받습니다. 즉, 큐 처리, 라우팅, “이 데이터 넣고, 저 링크 따라가기” 같은 구조는 같지만, 실제로 페이지 내용을 읽는 지점의 형태는 다릅니다. Crawlee 공식 문서도 이 부분을 분명히 밝힙니다. 공유 인터페이스는 크롤링 동작에만 해당하고, 콘텐츠 접근 방식은 다르다고 설명합니다.
| 엔진 | 가져오는 방식 | JavaScript 실행 | 내 테스트(동적 페이지 1개) | 적합한 용도 |
|---|---|---|---|---|
CheerioCrawler | 순수 HTTP + Cheerio 파싱 | 아니오 | 약 0.035초 | 정적 HTML, JSON API, 속도 중시 |
PlaywrightCrawler | Playwright로 실제 Chromium 실행 | 예 | 약 4.967초 | JS 렌더링 페이지, 스크린샷 |
이 시간은 한 대의 머신에서 한 번씩 돌린 값이라 엄밀한 벤치마크라고 보긴 어렵습니다. 그래도 같은 URL에서 브라우저 경로가 대략 두 자릿수 배 더 오래 걸린다는 점은 분명했습니다. 렌더링 비용이 그만큼 든다는 뜻이고, 그래서 기본값으로 브라우저를 고르는 건 아닙니다.
테스트: 같은 URL, 0개 vs 8/8개
말은 누구나 쉽게 합니다. 제가 두 엔진 이야기를 믿은 이유는, 일부러 실패를 확인한 뒤 클래스 하나만 바꿔서 다시 성공시킬 수 있었기 때문입니다.
로컬에서 동적 샘플 페이지를 만들었습니다. 상품 카드가 로드 후 JavaScript로 주입되는 카탈로그 페이지로, 요즘 웹에서 흔히 보는 형태입니다. 여기에 CheerioCrawler를 연결하니 상품 카드가 0개 나왔습니다. 버그가 아니라 원리상 당연한 결과입니다. Cheerio는 JavaScript를 실행하지 않으니, 파싱한 HTML 안에 카드 자체가 처음부터 없었던 겁니다. 같은 URL에 PlaywrightCrawler를 그대로 연결하고 다른 건 아무것도 건드리지 않자, 이번에는 8개 중 8개 상품을 렌더링했고 증거용 스크린샷도 확보했습니다.
제 샘플만의 특이점인지 확인하려고 공개 사이트인 Quotes to Scrape의 JavaScript 데모 페이지에도 같은 패턴을 적용했습니다. 이 페이지 역시 클라이언트 측에서 인용문을 구성합니다. 결과는 똑같이 같은 방향이었습니다. CheerioCrawler는 인용문을 0개 봤고, PlaywrightCrawler는 10개를 복구했습니다.
이 결과가 무엇을 증명하는지는 신중하게 봐야 합니다. 이는 Crawlee가 이미 문서화한 주장, 즉 3.0부터 크롤러 타입 간에 같은 베이스 클래스와 인터페이스를 공유한다는 점을 깔끔하게 재현한 것입니다. 그러니 발견이라기보다 검증에 가깝습니다. 하지만 그게 바로 중요한 지점입니다. “하나의 인터페이스, HTTP든 브라우저든 가능”이라는 말이 실제라는 걸 보여주고, 제가 통제한 샘플과 통제하지 않은 사이트 양쪽에서 0에서 전체 데이터 복구까지 확인됐다는 뜻이니까요.
HTTP 경로가 더 강한 지점
위 내용을 읽고 “그럼 무조건 브라우저를 쓰면 되겠네”라고 생각하기 쉽습니다. 하지만 그러면 안 됩니다. 두 엔진 구조가 의미 있는 이유는 브라우저가 기본값이 아니라, 비싼 대안이기 때문입니다.
정적 콘텐츠에서는 CheerioCrawler가 정확하고 빨랐습니다. 제 정적 카탈로그 샘플은 enqueueLinks({ selector: '.next-page' })로 페이지네이션을 따라가면서 12개 중 12개 상품을 모두 수집했고, 처리 시간은 약 0.155초였습니다. 또 다른 기사 페이지에서는 제목과 본문 3개 중 3개 문단을 가져오면서 로그인/구독/저작권 안내 같은 군더더기를 콘텐츠와 깔끔하게 분리했습니다.
기억해 둘 만한 한 가지는 이겁니다. JavaScript로 데이터가 로드되는 페이지 뒤에는 종종 JSON API가 숨어 있습니다. 제 동적 샘플의 데이터는 엔드포인트에 있었고, CheerioCrawler를 그 API로 직접 연결하니 브라우저 없이도 8개 중 8개 상품을 복구했습니다. 처리 시간은 약 0.035초였습니다. 브라우저 경로가 렌더링하는 데 거의 5초 걸리던 그 동일한 데이터입니다. 오래된 교훈이지만 여전히 맞는 말이죠. 바탕이 되는 요청을 재현할 수 있다면 Chromium을 띄우는 대신 그쪽으로 가야 합니다. Crawlee는 프레임워크를 바꾸지 않고도 크롤러별로 그 선택을 할 수 있게 해줍니다.
Crawlee를 바닐라 브라우저 라이브러리보다 고르는 이유: 크롤링 프레임워크
페이지 하나만 렌더링하면 된다면 Crawlee가 꼭 필요한 건 아닙니다. Playwright나 Puppeteer를 단독으로 써도 됩니다. 하지만 단일 브라우저 라이브러리가 주지 못하는 건 크롤링입니다. 즉, 큐, 중복 제거, 깊이 제어, 재시도 기능입니다. 이 부분이 바로 엔진과는 별개로 Crawlee가 주는 가치입니다.
저는 샘플 루트에서 같은 호스트를 대상으로 enqueueLinks와 깊이 추적을 사용해 크롤링을 돌렸습니다. Crawlee는 깊이 {0:1, 1:3, 2:7}로 나뉜 11개 페이지를 순회했습니다. 루트 1개, 한 단계 아래 3개, 두 단계 아래 7개입니다. 또한 maxRequestsPerCrawl을 중지 조건으로 잘 지켰습니다. RequestQueue가 상태 관리를 맡았습니다. HTTP 500을 반환하는 페이지로 요청을 보냈을 때는 Crawlee가 재시도한 뒤, 조용히 무시하거나 전체 실행을 망가뜨리지 않고 failedRequestHandler로 실패를 넘겼습니다.
이 점이 Crawlee를 단독 브라우저 도구보다 더 강하게 만드는 핵심입니다. 크롤링 오케스트레이션이 내장되어 있고, 더 중요한 건 그 오케스트레이션이 아래 엔진이 HTTP든 브라우저든 동일하게 작동한다는 사실입니다. 큐와 링크 추적 로직은 한 번만 작성하면 됩니다. 각 크롤러가 JavaScript를 렌더링할지 여부는 따로 정하면 됩니다.
설치와 숨겨진 브라우저 다운로드
설치는 대체로 수월했지만, 처음 쓰는 사람이라면 한 번은 걸릴 만한 함정이 있습니다.
npm install crawlee playwright는 문제없이 진행됐고 보안 취약점도 0개로 나왔습니다. 하지만 PlaywrightCrawler를 실제로 실행하려면 npx playwright install chromium도 별도로 해야 합니다. 이 명령은 약 81.7 MiB 크기의 Chromium 바이너리를 내려받습니다. crawlee 패키지만 설치했다고 해서 브라우저까지 함께 들어오는 건 아닙니다. 이 단계를 건너뛰고 바로 브라우저 크롤러를 실행하면, Playwright의 패키징 방식을 이미 알고 있지 않은 이상 원인을 바로 파악하기 어려운 실행 오류를 만나게 됩니다. 이건 Crawlee 자체의 결함이라기보다 Playwright의 동작 방식에서 온 것이지만, 첫 실행에서 체감되는 마찰 포인트라는 건 분명히 짚어둘 만합니다.
운영 측면에서 하나 더 있습니다. 기본적으로 Crawlee는 로컬 storage/ 디렉터리에 데이터를 저장합니다. 제 테스트 하네스는 이를 임시 디렉터리로 돌리고 영속성도 끄는 방식으로 깔끔하게 처리했지만, 일반 실행에서는 프로젝트 안에 storage/ 폴더가 생깁니다. 문제는 아니지만, git status에 갑자기 뜨기 전에 알아두면 좋습니다.
짧게 보는 세 번째 엔진
Crawlee의 동일 인터페이스 이야기는 Cheerio와 Playwright에만 해당하지 않습니다. PuppeteerCrawler도 있습니다. 저는 이 “같은 인터페이스” 주장이 어느 정도까지 이어지는지 클래스와 API 표면 수준에서 확인해 봤습니다. 실사용 크롤링은 아니었습니다.
세 크롤러 클래스는 모두 같은 BasicCrawler 베이스를 공유합니다. CheerioCrawler는 HttpCrawler를 거치고, PlaywrightCrawler와 PuppeteerCrawler는 공통의 BrowserCrawler를 사용합니다. 설치된 패키지를 살펴보니 run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop 같은 큐와 저장소 관련 핵심 기능을 포함해, 세 엔진 모두에서 공통으로 제공되는 공개 메서드가 24개였습니다. 사실 PuppeteerCrawler와 PlaywrightCrawler는 공개 메서드 집합이 완전히 같습니다. 엔진 간 차이는 HTTP와 브라우저가 갈리는 경계에만 존재하며, 그게 딱 있어야 할 자리이기도 합니다.
다만 한계는 분명히 해야 합니다. 저는 PuppeteerCrawler의 실제 크롤링을 실행하지 않았습니다. 테스트 환경에 puppeteer peer dependency가 설치되어 있지 않았고, 이를 돌리려면 또 다른 브라우저 다운로드가 필요했기 때문입니다. 따라서 여기서의 Puppeteer 호환성은 구조적으로 검증한 것입니다. 같은 베이스 클래스, 같은 공유 메서드, 같은 핸들러 컨텍스트 형태라는 뜻이지, 실제 실행 검증은 아닙니다. 그리고 인터페이스가 같다고 해서 내부 동작이 완전히 같지는 않습니다. Crawlee의 공식 가이드도 Playwright는 요소를 자동으로 기다리지만 Puppeteer는 명시적으로 기다려야 한다고 설명합니다. 이건 Crawlee의 문제가 아니라 엔진 특성입니다. 다만 “API가 같다”는 말이 “모든 핸들러 안의 코드가 완전히 같다”는 뜻은 아닙니다.
이번 테스트에서 의도적으로 하지 않은 것
이번 검증에서는 일부러 남겨둔 항목도 있습니다. 결과를 실제보다 넓게 해석하지 않도록 하기 위해서입니다.
- 스케일 테스트: 모두 작은 샘플과 짧은 공개 크롤링에서만 돌렸습니다. 100~1,000페이지급 장기 실행은 하지 않았기 때문에, 실제 대규모 부하에서의 자동 확장이나 안정성은 말할 수 없습니다.
- 큐 지속성 및 재개: 실행 도중 크롤을 강제로 중단한 뒤
RequestQueue가 크래시 이후에도 정상 복귀하는지 확인하지 않았습니다. 긴 작업에서 중요한 기능이지만 이번에는 테스트하지 않았습니다. - Dataset 및 KeyValueStore 내보내기: JSON/CSV 내보내기는 하네스에서 직접 작성했습니다. 프레임워크의
Dataset/KeyValueStore내장 내보내기 편의성은 시험하지 않았습니다. - 프록시 및 세션 풀: Crawlee는 프록시 로테이션과 핑거프린팅 기능을 제공합니다. 저는 이를 우회 기술이라기보다 컴플라이언스와 운영의 영역으로 봅니다. 어느 방향으로도 강하게 테스트하지 않았습니다.
그리고 앞서 언급한 시간 수치들은 모두 단일 머신, 단일 실행 기준입니다. HTTP와 브라우저 비용 차이의 “형태”만 보여줍니다. 벤치마크가 아니며, 그렇게 인용하면 안 됩니다.
장단점 정리
장점
- HTTP와 브라우저 크롤링을 하나의 API로 다룰 수 있음. 로컬 샘플과 공개 사이트 모두에서 0 → 전체 데이터 복구로 엔진 교체가 실제로 검증됨.
- 진짜 크롤링 프레임워크:
RequestQueue, 깊이 제어가 포함된enqueueLinks, 재시도,failedRequestHandler까지 제공. 단순한 페이지 렌더러가 아님. - JavaScript가 방해하지 않는다면 HTTP 추출이 정확함(정적 12/12, 기사 본문 3/3, JSON API 8/8).
- 브라우저 경로는 HTTP 경로가 물리적으로 볼 수 없는 콘텐츠를 복구할 수 있고, 스크린샷도 가능함.
- Apache-2.0, TypeScript, 활발히 유지보수됨.
단점
- 브라우저 크롤러는
npm install crawlee만으로는 해결되지 않는 별도의npx playwright install chromium(~81.7 MiB)이 필요함. 처음 쓰면 놓치기 쉽다. - 브라우저 렌더링은 페이지당 실제 비용이 큼(제 단일 페이지 테스트 기준 약 5초 vs 1초 미만).
- 기본 실행 시
storage/디렉터리가 생김. - 스케일, 큐 지속/재개, 내장 내보내기 편의성은 이번 테스트에서 검증되지 않음.
- 프록시와 핑거프린팅 기능은 사이트 약관과 법률 범위 안에서 써야 하는 책임이 따름. 기능이라기보다 운영상의 의무에 가깝다.
Crawlee를 고를 때와 관리형 API를 고를 때
Crawlee는 직접 만들고 운영하는 도구이며, 많은 팀에 그게 더 잘 맞습니다. 자신의 Node 코드베이스에서 크롤러를 직접 소유하고 싶고, 한 프로젝트 안에서 HTTP와 브라우저 크롤링을 섞어 쓰고 싶고, 큐와 저장소도 직접 제어하고 싶다면 Crawlee를 선택하세요. 브라우저 팜을 운영하고 나중에 확장하는 일까지 감당할 수 있다면, Crawlee는 그 위에 얹을 수 있는 깔끔하고 잘 설계된 뼈대를 제공합니다.
다른 길은 그 인프라를 아예 직접 운영하지 않는 것입니다. Chromium 인스턴스 관리, 프록시 로테이션, 봇 차단 대응에 엔지니어링 시간을 쓰고 싶지 않다면 관리형 API가 대안입니다. 그리고 그 지점에 Thunderbit의 개발자 스택이 맞닿아 있습니다. 기술 사용자에게 Thunderbit은 크롬 확장 프로그램이 아니라 AI 스크래핑 API, MCP 서버, CLI입니다. POST /distill로 페이지를 깔끔한 LLM 친화 Markdown으로 바꾸거나, POST /extract에 JSON Schema를 넣어 구조화된 데이터를 받아올 수 있습니다. renderMode는 none, basic, full 중에서 고를 수 있어, 언제 전체 브라우저 렌더링이 필요한지 직접 결정할 수 있습니다. MCP 서버는 AI 에이전트(Claude, Cursor 및 기타 MCP 클라이언트)가 작업 중간에 스크래핑하도록 해주며, CLI는 터미널이나 CI에서 실행할 수 있습니다:
웹 데이터 추출을 위해 Thunderbit 사용해 보기
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
개발자 입장에서 중요한 차이는 이겁니다. Crawlee는 렌더링된 HTML과 파싱된 노드 같은 원재료를 주고, 파이프라인은 사용자가 책임집니다. 반면 관리형 API는 JS 렌더링, CAPTCHA, 봇 차단 처리를 서버 측에서 끝낸 뒤 스키마에 맞는 구조화 JSON으로 돌려줍니다. 쓰임새가 다릅니다. 최대한의 통제력이 필요하고 운영 부담을 감수할 수 있다면 Crawlee가 맞습니다. 브라우저 팜을 직접 돌리지 않고 데이터를 받고 싶다면 관리형 API가 맞습니다. 많은 팀은 결국 둘 다 씁니다. 맞춤형 크롤링은 Crawlee로, “구조화된 데이터만 빨리 필요하다”는 경우는 관리형 API로 처리합니다. 비용 차이는 Thunderbit 요금제에서 확인할 수 있습니다.
결론
Crawlee를 써야 할까요? 네, Node 또는 TypeScript 개발자이고 HTTP와 브라우저 크롤링을 하나의 프레임워크 안에서 처리하면서 뒤에 진짜 크롤링 큐까지 갖추고 싶다면 그렇습니다. 두 엔진 전략이 Crawlee를 고를 이유이고, 제 테스트에서도 그 약속은 깨지지 않았습니다. 같은 URL이 클래스 하나만 바꿔서 0에서 전체 데이터로 바뀌었고, 정적 추출은 정확하고 빨랐으며, 큐와 깊이 기반 크롤링도 문서대로 작동했습니다.
다만 두 가지는 알고 시작해야 합니다. PlaywrightCrawler를 처음 쓸 때는 숨겨진 브라우저 다운로드 비용을 감안해야 하고, 제가 테스트하지 않은 부분 — 스케일, 장애 후 재개, 내장 내보내기 — 이 제가 확인한 부분만큼 잘 동작한다고 당연하게 보면 안 됩니다. 직접 크롤러를 만들기 위한 기반으로서 Crawlee는 강력하고 설계도 훌륭합니다. 하지만 완성된 무인 데이터 파이프라인으로 보면, 목적지라기보다 출발점에 가깝습니다.
웹 데이터 추출을 위해 Thunderbit 사용해 보기 Get Started Free
자주 묻는 질문
Crawlee는 무료인가요? 라이선스는 무엇인가요?
네. Crawlee는 Apache-2.0 라이선스의 오픈 소스이며 npm(npm install crawlee)에서 설치할 수 있습니다. 제가 테스트한 버전은 3.17.0이었습니다. 브라우저 크롤러를 사용하려면 Playwright를 통해 별도로 Chromium을 내려받아야 하며, 이것도 무료지만 설정에 약 81.7 MiB가 추가됩니다.
CheerioCrawler와 PlaywrightCrawler 중 무엇을 써야 하나요?
데이터가 원본 HTML이나 그 뒤의 JSON API에 있으면 CheerioCrawler를 쓰세요. 훨씬 빠르고 브라우저를 띄우지 않습니다. 콘텐츠가 JavaScript로 렌더링되는 경우에는 PlaywrightCrawler를 쓰세요. HTTP 경로에서 결과가 비어 있을 때 이를 바로 알아차릴 수 있습니다. 제 테스트에서는 JS 렌더링 페이지에서 HTTP 엔진이 0개를 반환했고, 브라우저 엔진은 전부 가져왔습니다. API가 같으므로 전환은 재작성보다 클래스 변경에 가깝습니다.
Crawlee를 실행하려면 브라우저가 꼭 필요한가요?
브라우저 크롤러를 쓸 때만 필요합니다. CheerioCrawler는 브라우저가 전혀 필요 없습니다. PlaywrightCrawler와 PuppeteerCrawler는 브라우저 바이너리가 필요하므로 npx playwright install chromium로 설치해야 합니다. npm install crawlee만으로는 브라우저가 내려오지 않는다는 점이 가장 흔한 첫 실행 함정입니다.
Crawlee는 페이지네이션과 여러 페이지 크롤링을 처리할 수 있나요?
네. 단독 브라우저 라이브러리보다 Crawlee를 고르는 핵심 이유 중 하나가 바로 이것입니다. enqueueLinks가 링크를 따라가고(.next-page 같은 페이지네이션 셀렉터 포함), RequestQueue가 중복을 제거하고 크롤을 관리하며, 깊이 제어와 maxRequestsPerCrawl 제한도 제공합니다. 테스트에서는 같은 호스트에서 깊이 0~2로 11개 페이지를 순회했고, 실패한 요청은 failedRequestHandler를 통해 드러났습니다.
Crawlee는 호스팅된 스크래핑 API와 어떻게 다른가요?
Crawlee는 직접 호스팅하는 방식입니다. 크롤러를 직접 작성하고 실행하며, 확장·프록시·봇 대응도 직접 책임집니다. Thunderbit의 distill/extract 같은 관리형 API는 렌더링과 봇 대응을 서버 측에서 처리한 뒤, 깔끔한 Markdown 또는 스키마 일치 구조화 JSON을 API, MCP 서버, CLI로 제공합니다. 자신의 파이프라인을 최대한 통제하고 싶다면 Crawlee를, 브라우저 인프라 운영을 직접 하고 싶지 않다면 관리형 API를 선택하세요.
