몇 주 전, 팀원 한 명이 GitHub 이슈 스레드를 보내왔습니다. 금요일 밤 11시에 한 개발자가 세 번째 PlaywrightCrawler 재시도 로직을 디버깅하고 있는 장면이었죠. 바로 아래에는 누군가가 “그냥 Thunderbit 쓰세요”라고 답했고, 원글 작성자는 “그게 핵심이 아니에요. 이걸 제 파이프라인에 넣어야 한다고요”라고 받아쳤습니다. 둘 다 맞는 말이었습니다. 사실 이 한 개의 GitHub 스레드에 Thunderbit vs Crawlee 논쟁의 본질이 다 들어 있습니다.
저는 SaaS와 자동화 툴 사이를 오가며 꽤 오래 일해 왔기 때문에(Automation Anywhere 시절을 떠올리면 더더욱), “어떤 스크래퍼가 더 좋은가”는 거의 항상 잘못된 질문이라는 걸 알고 있습니다. 진짜 중요한 질문은 이겁니다. 누가 실제로 스크래핑을 하고 있고, 그 다음에 무엇이 필요한가? 이제 그 얘기를 해보겠습니다.
진짜 질문은 “어떤 툴이 더 좋은가”가 아니라 “누가 스크래핑을 하느냐”입니다
사람들이 “Crawlee vs [무엇이든]”을 검색할 때마다 늘 헷갈리는 부분이 하나 있습니다. 마치 커피 머신 두 개를 비교하듯 기능 대 기능으로 붙여 보려 한다는 점입니다. 하지만 Crawlee와 Thunderbit은 같은 일을 두고 경쟁하는 제품이 아닙니다. 전혀 다른 두 사람이, 전혀 다른 문제 앞에 서 있을 때 쓰는 도구입니다.
Crawlee는 Apify 팀이 만든 오픈소스 크롤링 라이브러리로, JavaScript, TypeScript 또는 Python으로 코드를 작성하는 데 익숙한 개발자를 전제로 합니다. 설치하고, 요청 핸들러를 작성하고, 셀렉터를 정의하고, 코드를 배포하면 됩니다. Thunderbit은 완전히 다른 사람을 가정합니다. 당장 웹페이지에서 구조화된 데이터를 뽑아야 하는 영업, 마케팅, 운영 팀의 구성원이고, 터미널을 건드릴 생각이 전혀 없는 사람 말입니다.
| 요소 | Crawlee | Thunderbit |
|---|---|---|
| 대상 사용자 | 맞춤형 크롤러를 만드는 개발자 | 비기술 사용자, 운영/영업/마케팅 팀 |
| 초기 설정 | Node.js 또는 Python 설치, 스크래퍼 코드 작성 | 브라우저 확장 프로그램 설치, One Click Extract 클릭 |
| 코딩 필요 여부 | 필요함 (JS/TS 또는 Python) | 필요 없음 |
| 가장 적합한 용도 | 프로덕션 파이프라인, 커스텀 로직 | 페이지 단위의 임시 또는 반복 구조화 추출 |
이 점을 먼저 짚는 이유는, 대부분의 비교 글이 이 갈림길을 아예 건너뛰기 때문입니다. 하지만 사실 어떤 툴을 검토해야 하는지 결정하는 핵심은 바로 여기입니다. 세밀한 재시도, 프록시, 브라우저 풀까지 직접 제어해야 하는 개발자라면, 원클릭 편의성만으로는 절대 만족할 수 없습니다. 반대로 개발자가 아니라면 Crawlee의 유연성은 아무 의미가 없습니다. 애초에 쓰지 않게 되니까요.
Thunderbit이란 무엇인가?
Thunderbit은 제가 말하자면 에이전틱 웹 스크래퍼입니다. 즉, 셀렉터를 직접 하나하나 쓰는 대신 AI 계층이 페이지를 해석하고 어떤 데이터를 추출해야 하는지 판단합니다. Thunderbit Chrome 확장 프로그램의 핵심 흐름은 이렇습니다. 데이터를 가져오고 싶은 페이지를 열고, One Click Extract를 누르면 에이전트가 페이지를 읽고 분석한 뒤, 유의미한 필드를 찾아 실행 준비를 마칩니다. Run Now가 나타나면 즉시 시작할 수도 있지만, 선택 사항입니다. 아무것도 하지 않으면 추출이 자동으로 시작됩니다.
설정은 정말 이게 전부입니다. 스키마를 만들거나 필드를 매핑하는 시간이 따로 필요하지 않습니다. 에이전트가 페이지를 분석하고 추출을 자동으로 실행합니다.
브라우저 확장 프로그램 외에도 Thunderbit에는 Web App, 프로그래밍 방식 접근을 위한 Open API, AI 에이전트 도구 사용을 위한 MCP Server, 그리고 터미널 기반 워크플로우용 CLI가 있습니다. 마지막 항목은 생각보다 중요합니다. 뒤에서 다시 다루겠지만, 이것이 이 글을 단순한 “노코드가 이긴다” 수준으로 끝내지 않는 이유이기도 합니다.
호환되는 페이지에서는 페이지네이션도 처리할 수 있고 하위 페이지 정보도 보강할 수 있습니다. 그리고 데이터를 확보한 뒤에는 스프레드시트나 다른 지원 대상로 내보낼 수 있습니다. 다만 “AI가 페이지를 읽는다”는 표현은 늘 조심해서 봐야 합니다. 호환되고, 사용 권한이 있는 페이지에서 잘 동작한다는 뜻이지, 인터넷의 모든 JavaScript 프레임워크나 안티봇 장벽을 무조건 뚫는다는 보장은 아닙니다.
Crawlee란 무엇인가?
Crawlee는 호스팅 제품이 아니라, JavaScript/TypeScript 또는 Python으로 웹 크롤러와 스크래퍼를 만들기 위한 오픈소스 라이브러리입니다. Apify가 유지 관리하고 있으며, 이 부분은 정확히 짚고 넘어가야 합니다. 많은 사람이 둘을 혼동하는데, Crawlee는 라이브러리이고 Apify는 Crawlee 기반 프로젝트를 호스팅하고 실행할 수 있는 별도의 클라우드 플랫폼입니다. 서로 관련은 있지만 같은 것은 아닙니다.
Crawlee에서 실제로 얻는 것은 도구 상자입니다. JavaScript 의존도가 낮은 가벼운 스크래핑을 위한 HTTP 기반 크롤러와, 실제 렌더링이 필요한 사이트를 위한 Playwright 및 Puppeteer 기반 브라우저 크롤러를 제공합니다. 또 어떤 URL을 이미 방문했는지 수동으로 추적하지 않도록 요청 큐를 관리해 주고, 추출한 데이터를 저장할 스토리지도 처리합니다. 대규모로 수천 페이지를 크롤링할 때 필요한 자동 확장과 세션 풀도 내장되어 있어, 동시성 로직을 처음부터 다시 만들 필요가 없습니다.
하지만 이 모든 것이 버튼 하나 눌러서 되는 건 아닙니다. 코드를 작성해야 합니다. 요청 핸들러를 정의하고, 크롤러 인스턴스를 설정하고, 페이지에 도달했을 때 무엇을 할지 지정해야 합니다. Crawlee는 뼈대를 제공할 뿐, 집을 직접 짓는 건 여전히 당신의 몫입니다.
핵심 차이: 관리형 추출 제품 vs 코드 라이브러리
구조화된 표를 처음 얻기까지 걸리는 시간
가장 뚜렷한 차이가 여기서 드러납니다. Thunderbit은 페이지를 열고 실사용 가능한 데이터 표를 얻기까지, 호환되는 페이지라면 수 초에서 수 분 정도면 충분합니다. 클릭하고, 에이전트가 감지하고 실행하도록 두면 끝입니다.
반면 Crawlee는 아주 단순한 첫 크롤러를 만드는 데도 꽤 많은 초기 작업이 필요합니다. Node.js 또는 Python이 설치되어 있어야 하고, Crawlee 패키지를 추가해야 하며, 요청 핸들러를 작성하고, 페이지를 직접 살펴보며 셀렉터를 찾아야 합니다. 그다음 실행하고, 깨진 부분을 디버깅해야 하죠. 처음 쓰는 사람 기준으로는, 이미 JavaScript나 Python을 어느 정도 안다는 전제하더라도 첫 추출 하나가 동작하기까지 30~60분 정도는 잡아야 합니다.
브라우저/크롤러 로직에 대한 제어 수준
이 부분은 Crawlee가 완전히 앞섭니다. 이견이 없습니다. 어떤 브라우저 엔진을 쓸지, 세션을 어떻게 관리할지, 프록시를 어떤 방식으로 순환할지, 요청 실패 시 무엇을 할지, 링크 탐색을 어디까지 할지, 동시성을 얼마나 제한할지까지 전부 직접 제어할 수 있습니다. 멀티스텝 로그인 흐름 처리나, 일반적인 패턴을 깨는 이상한 페이지네이션처럼 커스텀 로직이 필요한 크롤링이라면 Crawlee는 정확히 그걸 만들 수 있는 기본 도구를 제공합니다.
Thunderbit의 에이전틱 접근은 이런 세밀함을 속도와 접근성으로 바꿉니다. 로직을 직접 쓰는 것이 아니라, AI가 페이지에서 보이는 정보를 바탕으로 추론합니다. 잘 맞아떨어질 때는 아주 강력하지만, 매우 구체적이고 직관적이지 않은 추출 패턴을 강제로 구현해야 할 때는 덜 유용합니다.
배포와 유지관리 책임
Crawlee를 쓰면 배포 책임도 직접 집니다. 즉, 호스팅(자체 서버든 Apify 플랫폼이든 원하는 곳)이 필요하고, 셀렉터를 깨뜨리는 사이트 마크업 변경을 대응해야 하며, 의존성도 계속 업데이트해야 합니다. 분명 지속적인 작업이지만, 그만큼 지속적인 통제권도 있습니다.
Thunderbit은 관리형 인프라에서 동작합니다. 브라우저 확장 프로그램은 세션 내 로컬에서 실행되거나, 예약 작업의 경우 클라우드에서 실행됩니다. 추출 로직 업데이트도 사용자가 아니라 Thunderbit 쪽에서 처리합니다.
실전 시나리오
단발성 페이지 추출
오후 2시 미팅 전에 경쟁사 제품 목록 페이지를 스프레드시트로 옮겨야 한다고 해봅시다. Thunderbit은 이런 상황을 위해 만들어졌습니다. 페이지를 열고 One Click Extract를 누르고, 내보내면 끝입니다. 반대로 Crawlee는 정말 한 번만 필요한 작업에는 과합니다. 스크립트를 작성하는 데 드는 시간이 절약되는 시간보다 더 클 가능성이 높습니다.
커스텀 Playwright/Puppeteer 크롤링
이번엔 인증이 필요한 대시보드에 로그인해서, 세 단계 더 들어가 데이터를 가져와야 하고, 모든 내용을 특이한 DOM 타이밍을 가진 JS 프레임워크로 렌더링하는 사이트를 모니터링 파이프라인으로 만든다고 해보죠. 이건 Crawlee의 주무대입니다. PlaywrightCrawler는 이런 종류의 커스텀 네비게이션 로직을 처리할 수 있는 브라우저 자동화 도구를 제공합니다.
재시도와 저장이 포함된 대규모 큐 크롤링
수만 개의 URL을 크롤링하면서 자동 재시도 로직, 요청 큐의 지속성, 구조화된 저장 출력을 필요로 한다면, Crawlee의 내장 요청 큐와 데이터셋 추상화는 바로 그런 규모를 위해 설계된 것입니다. 이런 용도는 Thunderbit의 브라우저 확장 프로그램이 해결하려는 문제가 아닙니다. Thunderbit은 페이지 단위, 혹은 호환되는 하위 페이지 단위 도구이지, 큐 관리 시스템은 아닙니다.
AI 에이전트에서 추출 호출하기
이 비교에서 사람들이 가장 자주 헷갈리는 부분이 바로 여기입니다. AI 에이전트 워크플로우를 만드는 개발자들은 종종 “AI 에이전트가 데이터를 필요로 한다”는 말이 자동으로 “Crawlee 코드를 직접 작성해서 도구로 감싸야 한다”는 뜻이라고 생각합니다. 그것도 하나의 올바른 방법입니다. 하지만 Thunderbit의 MCP Server는 Claude, Cursor 같은 호환 클라이언트가 맞춤 크롤러를 직접 만들지 않고도 Thunderbit의 추출 기능을 도구처럼 호출할 수 있도록 존재합니다. 이것은 원클릭 브라우저 워크플로우와는 완전히 다른 인터페이스이며, 설정이 필요하고 “클릭하면 끝”은 아닙니다. 하지만 Crawlee 기반 도구를 처음부터 만드는 것과는 또 다른 수준의 작업입니다.
동적 사이트, 규모, 안정성
여기서는 특히 조심해서 말해야 합니다. 마케팅 문구가 가장 쉽게 과장되는 영역이기 때문입니다(과거의 제 글도 예외는 아니었습니다). Crawlee의 브라우저 크롤러는 JavaScript를 실행하고, 동적 콘텐츠를 기다리고, 실제 사용자처럼 페이지와 상호작용할 수 있습니다. 렌더링이 많은 사이트에서 정말 유용하죠. Thunderbit의 브라우저 확장 프로그램도 실제 브라우저 컨텍스트에서 실행되며, 열린 상태의 JS 렌더링 페이지와 함께 작동할 수 있습니다.
하지만 둘 중 어느 것도 어디서나 성공을 보장하지는 않습니다. Crawlee는 개발자가 프록시 순환과 세션 풀을 직접 설정할 수 있게 해 주며, 이는 자동 우회가 아니라 수동이지만 조정 가능한 제어입니다. Thunderbit은 지원되는, 권한이 있는 페이지에서 관리형 렌더링과 안티봇 처리를 적용합니다. 역시 마찬가지로 “모든 곳에서 무조건 된다”는 뜻은 아닙니다. 인터넷의 모든 안티봇 시스템을 100% 뚫는다고 말하는 비교 글을 본다면, 그건 그냥 거짓말입니다.
가격, 라이선스, 총비용
Crawlee 자체는 무료 오픈소스입니다. 예를 들어 Python 버전은 Apache License 2.0으로 배포됩니다. 하지만 “무료”가 곧 “비용 없음”은 아닙니다. 크롤러를 작성하고 유지보수하는 개발자 시간, 호스팅 비용(자체 서버든 Apify 플랫폼이든, 라이브러리와는 별도의 유료 제품입니다), 차단 회피를 위해 대상 사이트에 IP 회전이 필요할 경우 프록시 서비스 비용을 지불하게 됩니다.
Thunderbit은 구독/플랜 기반이며 크레딧 사용량 중심으로 운영됩니다. 수치는 변동될 수 있으니, 정확한 내용은 Thunderbit Pricing 페이지를 직접 확인하시는 게 좋습니다. 여기서는 오래된 숫자를 적어 두고 싶지 않습니다.
솔직한 유지보수 비교를 하자면 이렇습니다. Crawlee 크롤러는 대상 사이트의 마크업이 바뀌면 깨질 수 있는데, 그 이유는 셀렉터가 특정 DOM 구조를 기준으로 작성되어 있기 때문입니다. 누군가 실패를 발견하고 코드를 고쳐야 합니다. Thunderbit의 에이전틱 추출은 실행할 때마다 페이지를 다시 분석하므로 이런 종류의 깨짐을 줄여 줍니다(완전히 없애지는 못합니다). 대상 사이트의 레이아웃이 크게 바뀌면 여전히 영향을 받을 수 있지만, 하드코딩된 셀렉터를 같은 방식으로 유지보수할 필요는 없습니다.
누가 Thunderbit을 선택해야 할까?
개발자가 아니고 웹페이지에서 구조화된 데이터를 뽑아야 한다면 — 리드 리스트, 경쟁사 가격, 시장 조사 등 무엇이든 — Thunderbit은 바로 그런 상황을 위해 만들어졌습니다. 비기술 팀에 셀프 서비스 추출 도구를 넘겨주고 싶은 개발자에게도, 처음부터 크롤러를 만들지 않고 Open API로 프로그래밍 접근을 하고 싶은 경우에도 잘 맞습니다.
누가 Crawlee를 선택해야 할까?
코드베이스 안에서 살아야 하고, 수천 페이지까지 확장해야 하며, 정말로 커스텀한 네비게이션 로직이 필요한 프로덕션 데이터 파이프라인을 구축한다면 Crawlee가 맞는 기반입니다. 재시도와 프록시 동작을 세밀하게 제어하고, 소스 코드를 처음부터 끝까지 직접 소유하고 싶을 때도 Crawlee가 더 나은 선택입니다. 또한 진짜 대규모, 즉 요청 큐 관리가 필요한 수만 페이지 단위의 크롤링이라면 Crawlee가 더 적합합니다. 이건 브라우저 확장 프로그램 워크플로우가 해결하려는 문제와는 결이 다릅니다.
두 가지를 함께 써도 될까?
현실적으로는 그렇습니다. 그리고 저는 그 답을 회피라고 생각하지 않습니다. 함께 일했던 여러 회사에서도 이미 이런 패턴을 많이 봤습니다. 엔지니어링 팀은 데이터 웨어하우스로 흘러 들어가는 반복적이고 대규모의 구조화 크롤링 작업을 위해 Crawlee 기반 파이프라인을 운영하고, 영업/마케팅/운영 팀은 엔지니어링 백로그에 티켓으로 쌓일 만한 “이 페이지 데이터만 지금 당장 필요해요” 같은 업무에 Thunderbit 브라우저 확장 프로그램이나 Web App을 사용합니다. 두 제품을 공식적으로 묶는 통합은 없습니다. 제가 없는 걸 만들어내진 않겠습니다. 하지만 구조적으로는 서로 인접한 문제를 잘 해결하기 때문에, 많은 팀이 결국 두 가지를 모두 쓰게 됩니다.
결론
코드베이스 안에서 살아야 하고, 수천 페이지 규모로 확장해야 하며, 정말 복잡한 네비게이션 로직을 처리해야 하는 것을 만드는 개발자라면 Crawlee가 필요한 통제력을 제공합니다. 대신 시간과 지속적인 유지보수 비용이 듭니다. 반대로 코드 없이 웹페이지에서 데이터를 꺼내고 싶거나, 크롤러를 처음부터 만들지 않고 AI 에이전트에 추출 기능을 도구로 노출하고 싶은 개발자라면 Thunderbit이 더 빠른 길입니다. 추상적으로는 어느 쪽이 “더 좋다”고 말할 수 없습니다. 서로 다른 사람에게, 서로 다른 문제를 해결해 주는 도구이기 때문입니다. 여기서 정말 피해야 할 유일한 실수는, 자신의 상황에 맞지 않는 쪽을 고르는 일입니다.
자주 묻는 질문
Crawlee는 Apify와 같은가요?
아니요. Crawlee는 Apify 팀이 유지 관리하는 오픈소스 크롤링 라이브러리입니다. Apify는 Crawlee 기반 프로젝트를 호스팅하고 실행할 수 있는 별도의 클라우드 플랫폼이며, 프록시나 스케줄링 같은 다른 서비스도 제공합니다. 서로 관련은 있지만, 가격 모델이 다른 별개의 제품입니다.
Crawlee는 무료인가요?
라이브러리 자체는 무료 오픈소스입니다(Python 버전은 Apache License 2.0). 실제 비용은 라이선스가 아니라 개발 시간, 호스팅 인프라, 그리고 필요한 경우 프록시 서비스에서 발생합니다.
Thunderbit은 개발자를 위한 API와 MCP 접근을 지원하나요?
네. 브라우저 확장 프로그램 외에도 Thunderbit은 프로그래밍 접근을 위한 Open API와, 호환되는 AI 호스트가 Thunderbit의 추출 도구를 직접 호출할 수 있게 해 주는 MCP Server를 제공합니다.
코딩 경험이 전혀 없는 사람에게 더 쉬운 것은 무엇인가요?
의심할 여지 없이 Thunderbit입니다. 브라우저 확장 프로그램의 One Click Extract 흐름은 코딩, 셀렉터 작성, 스키마 설정이 전혀 필요 없습니다. Crawlee는 처음부터 JavaScript/TypeScript 또는 Python에 익숙하다는 전제를 둡니다.
재시도나 프록시 같은 크롤러 동작을 더 세밀하게 제어할 수 있는 툴은 무엇인가요?
압도적으로 Crawlee입니다. 세션 풀, 프록시 순환, 요청 큐 관리, 재시도 로직을 개발자가 설정할 수 있는 기본 구성 요소로 제공합니다. Thunderbit은 이 부분을 자체적으로 관리하면서, 그 대신 단순함과 속도를 얻습니다.
