같은 질문을 같은 주에 세 사람이 연달아 묻는 바람에 이 주제에 푹 빠지게 됐다. “ScrapeGraphAI를 Thunderbit 대신 써도 될까?” 한 사람은 경쟁사 가격표를 만들고 있던 1인 마케터였고, 또 한 사람은 RAG 파이프라인을 구축 중인 백엔드 엔지니어였다. 묘하게도 세 번째 사람은 둘 다였다. 도대체 도구를 하나만 써야 하는지, 아니면 두 개가 필요한지 고민하고 있었다.
이 조합의 핵심은 여기다. Thunderbit과 ScrapeGraphAI는 사실 같은 일을 놓고 정면승부하는 관계가 아니다. 하나는 비개발자도 버튼 몇 번만 눌러 깔끔한 표를 뽑을 수 있게 만든 관리형 에이전틱 스크래퍼다. 다른 하나는 개발자가 프롬프트, 스키마, 크롤링, 모니터링을 엮어 자기만의 파이프라인을 만들 수 있게 해주는 AI 네이티브 추출 API다(그 아래에는 오픈소스 코어가 있다). 이 글에서는 두 도구가 실제로 겹치는 부분, 겹치지 않는 부분, 그리고 어느 쪽도 마케팅 페이지에서는 잘 말하지 않으려는 현실적인 비용과 한계를 있는 그대로 정리해보려 한다.
한 줄 답변
세부 설명에 들어가기 전에 먼저 짧게 정리하면:
- Thunderbit는 비즈니스 사용자와 개발자를 위한 관리형 에이전틱 스크래퍼로, Chrome 확장 프로그램, 웹 앱, Open API, MCP 서버, CLI로 제공된다.
- ScrapeGraphAI는 오픈소스 그래프 기반 추출 엔진과 함께, Scrape, Extract, Search, Crawl, Monitor, Schema, History 서비스를 제공하는 호스티드 API를 묶어 제공하며, 자체 MCP 지원도 갖추고 있다.
- 진짜 비교 포인트는 “노코드 vs. 코드”가 아니다. 관리형 원클릭 브라우저 워크플로우와 개발자가 직접 조립하는 API 중심 추출 스택의 차이다.
둘 중 하나가 객관적으로 더 낫다고 말하긴 어렵다. 애초에 겨냥한 사용자가 다르다.
한눈에 보기
| 구분 | Thunderbit | ScrapeGraphAI |
|---|---|---|
| 주요 사용자 | 비즈니스 사용자, 마케터, 영업/운영, 개발자 | AI/데이터 파이프라인을 만드는 개발자 |
| 설정 방식 | 확장 프로그램 클릭, 페이지 자동 감지 | API 키 사용 또는 오픈소스 패키지 셀프 호스팅 |
| 프롬프트/스키마 모델 | 에이전틱 필드 감지, 선택적 필드별 지시문 | 자연어 프롬프트 + 선택적 JSON 스키마 |
| 브라우저/크롤링 계층 | 지원되는 승인된 페이지에서 관리형 브라우저 렌더링 | 관리형 가져오기/렌더링 + 비동기 Crawl 서비스 |
| 호스팅 | 관리형 클라우드 제품(확장 프로그램, 웹 앱, API) | 호스티드 API 또는 오픈소스 코어 셀프 호스팅 |
| API/MCP | Open API, MCP 서버 | v2 API(Scrape/Extract/Search/Crawl/Monitor/Schema/History), MCP |
| 모델 선택 | 제품이 관리 | 오픈소스 엔진 셀프 호스팅 시 설정 가능 |
| 결과물 | 구조화된 테이블, Sheets/Airtable/Excel/Notion 내보내기 | Markdown, HTML, 스크린샷, JSON, 링크, 이미지, 요약 |
| 유지보수 | 벤더 관리형 | 벤더 관리형(호스티드) 또는 자체 관리형(오픈소스) |
| 개인정보 보호 | 표준 관리형 제품 정책 적용 | 무료 플랜은 학습에 데이터가 사용될 수 있으며, 유료 플랜은 다름 — 최신 약관 확인 필요 |
| 가격 | 구독/크레딧 방식 — Thunderbit Pricing 참고 | 크레딧 기반 요금제, ScrapeGraphAI의 최신 가격 페이지 참고 |
| 최적 용도 | 빠른 노코드 추출 + 비즈니스 워크플로우 | 프로그래밍 가능한 추출/검색/크롤/모니터 인프라 |
Thunderbit란?
Thunderbit은 하나의 아주 단순한 원칙 위에 만들어졌다. 웹페이지에서 데이터를 뽑아낼 때 굳이 셀렉터, 스키마, 프롬프트를 직접 적지 않아도 돼야 한다는 것이다. 예전처럼 스크린샷만 보고 감으로 따라 하는 방식이 아니라, 지금 실제 흐름은 이렇다.
접근 권한이 있는 페이지를 연 뒤 Chrome 확장 프로그램에서 One Click Extract를 누르면, 에이전트가 페이지를 감지하고 읽고 분석한다. 상품 목록, 연락처 정보, 채용 공고처럼 페이지에 맞는 데이터 구조를 스스로 파악한 뒤 Run Now를 제안한다. 바로 실행해도 되고, 아무것도 하지 않으면 자동으로 시작된다. 끝이다. 의도적으로 한 번만 클릭하면 되게 만들었고, 셀렉터도, 스키마 작성도 필요 없다.
이후 자동 감지된 구조가 완벽하지 않으면 필드를 손볼 수 있고, 호환되는 사이트에서는 페이지네이션과 하위 페이지도 처리할 수 있으며, Google Sheets, Airtable, Excel, Notion으로 바로 내보낼 수 있다. 브라우저 클릭 이상의 기능이 필요한 팀이라면, 클라우드 실행용 Web App, 백엔드 연동용 Open API, Claude·Cursor 같은 호환 AI 에이전트가 도구처럼 호출할 수 있는 MCP 서버, 터미널과 코딩 에이전트 워크플로우용 CLI도 있다.
핵심 설계 철학은 분명하다. 비기술 사용자가 쓸 만한 데이터셋을 얻기 전에 내려야 하는 결정을 최대한 줄이는 것.
ScrapeGraphAI란?
ScrapeGraphAI는 완전히 다른 성격의 제품이다. 사실 이름은 하나지만 두 가지가 함께 있다. 하나는 사용자가 직접 호스팅할 수 있는 오픈소스 Python 패키지(scrapegraphai)로, 자체 LLM과 인프라를 붙여 쓰는 모듈형 AI 추출 엔진이다. 다른 하나는 그 엔진에 관리형 fetch, 프록시 회전, 크레딧 과금까지 더해 개발자가 비용을 지불하고 사용하는 호스티드 API다.
현재 기준 v2 API에는 다음이 포함된다:
- Scrape — 페이지를 가져와 Markdown, HTML, 스크린샷, 링크, 이미지, 요약, JSON, 브랜딩 정보 반환
- Extract — 자연어 프롬프트와 선택적 JSON 스키마를 이용해 URL, 원시 HTML, Markdown에서 구조화 데이터 추출
- Search — 선택적 페이지 추출과 구조화 출력이 가능한 웹 검색
- Crawl — 시작/중지/재개 제어가 가능한 비동기 다중 페이지 탐색
- Monitor — 웹훅 알림이 포함된 크론 스케줄 변경 감지
- Schema — 재사용 가능한 JSON 스키마 생성
- History — 과거 요청과 결과 확인
한 가지 짚고 넘어갈 점이 있다. 예전 v1 엔드포인트 이름인 smartscraper, searchscraper, smartcrawler는 이제 deprecated 상태이며, v2 용어로 대체됐다. 오래된 블로그 글이나 경쟁사 비교 글 중 이 명칭을 쓰는 것이 있다면, 최신 문서가 아니라는 뜻이다.
ScrapeGraphAI는 공식 MCP 지원도 제공한다. scrape, extract, search, crawl, schema, credits, history, monitor를 AI 에이전트가 호출할 수 있는 도구로 노출한다. 즉, MCP가 Thunderbit만의 전유물은 아니다. 이제 둘 다 그 언어를 쓴다. 사실 이 점이야말로 업계가 어디로 가고 있는지 잘 보여준다.
핵심 차이: 관리형 제품 경험 vs 설정 가능한 AI 스택
첫 결과까지 걸리는 시간
가장 큰 차이는 여기다. Thunderbit은 버튼 한 번 누르고 페이지가 처리될 때까지 기다리는 시간이 곧 첫 결과까지의 시간이다. 페이지 복잡도에 따라 몇 초에서 몇 분이면 된다. 반면 ScrapeGraphAI는 API 키 가입(또는 오픈소스 패키지와 자체 모델 접근 설정), 프롬프트나 스키마 작성, 목적에 맞는 엔드포인트 호출, 그리고 결과를 자신의 코드에서 처리하는 과정이 필요하다. 이는 단점이라기보다 의도된 설계다. 더 유연한 것을 만들고 있기 때문에 런웨이가 더 길 뿐이다.
모델과 파이프라인 제어
ScrapeGraphAI의 오픈소스 코어를 셀프 호스팅하면 LLM을 직접 선택하고 추출 로직을 조정할 수 있으며 파이프라인 전체를 소유하게 된다. 특정 모델 요구사항이 있거나, 데이터가 외부 API를 거치는 위치에 대한 컴플라이언스 제약이 있거나, scrape와 extract 사이에 맞춤 로직이 필요한 새로운 것을 만든다면 이는 큰 장점이다.
Thunderbit은 이 조정 레버를 제공하지 않는다. 모델과 파이프라인은 제품이 관리한다. 제어권을 일부 포기하는 대신 그것에 대해 신경 쓰지 않아도 된다. 바로 마케터나 영업 운영 담당자가 원하는 거래다.
호스팅, 개인정보 보호, 유지보수 책임
여기서는 분명히 말해두는 편이 좋다. ScrapeGraphAI의 이용약관은 2026년 중반 업데이트 기준으로, Free Plan에 제출된 데이터가 연구, 모델 평가, 학습, 파인튜닝, 제품 개선에 사용될 수 있다고 명시한다. 유료 플랜은 별도 옵트인 없이는 학습에 쓰이지 않는 것으로 설명된다. 민감한 데이터를 무료 플랜으로 시험해보려 한다면, 실제로 무엇이 허용되는지 먼저 확인해야 한다. ScrapeGraphAI가 수상한 일을 한다는 뜻이 아니라, 흔히 있는 프리미엄 구조의 트레이드오프지만 “일단 무료 플랜으로 테스트해보자”가 생각보다 더 큰 의미를 가질 수 있기 때문이다.
Thunderbit은 관리형 제품으로서 자체 표준 약관에 따라 데이터를 처리한다. 어느 쪽이든 직접 확인하는 것이 좋다. 어떤 도구든 기밀 정보에 연결하기 전에 최신 약관을 읽는 것이 안전하다.
실제 사용 시나리오
비즈니스 사용자용 페이지→표 추출
디렉터리 사이트에서 리드 리스트를 만들거나, 공급업체 카탈로그 페이지에서 제품 사양을 가져온다고 해보자. 프롬프트를 쓰고 싶지 않고, JSON 스키마를 고민하고 싶지도 않으며, 페이지 레이아웃이 조금 바뀌었다고 Python 스크립트를 디버깅하고 싶지도 않다. 이런 경우는 Thunderbit의 무대다. 클릭하고, 검토하고, 스프레드시트로 내보낸 뒤 하루를 계속 보내면 된다.
개발자가 정의하는 프롬프트/스키마 추출
이번에는 레이아웃이 제각각인 40개 경쟁사 사이트에서 구조화된 가격 데이터를 뽑아야 하고, 모든 결과에 일관된 JSON 스키마와 자체 검증 로직이 필요하다고 해보자. 이럴 때는 ScrapeGraphAI의 Extract 엔드포인트가 딱 맞는 도구다. 프롬프트와 스키마를 정의해 쓰는 구조라서, 어차피 코드는 작성해야 하지만, 사이트마다 셀렉터를 일일이 만들 필요 없이 AI 네이티브 추출 계층을 얹게 된다.
RAG 또는 에이전트 통합
이 영역에서는 두 도구 모두 쓸 수 있다. Markdown 또는 구조화 JSON 형태로 최신 웹 콘텐츠를 끌어와야 하는 RAG 파이프라인을 만든다면, ScrapeGraphAI의 Scrape와 Search 엔드포인트 또는 MCP 서버가 에이전트 프레임워크에 비교적 바로 연결된다. 이건 분명한 강점 중 하나다. Thunderbit의 MCP 서버와 Open API 역시 프로그래밍 및 에이전트 호출형 추출을 지원하므로, 팀이 이미 브라우저 워크플로우는 Thunderbit으로 표준화해두었다면 API 계층 때문에 굳이 다른 벤더를 추가해야 할 필요는 없다. 다만 결정하기 전에는 양쪽 최신 문서를 비교해보는 것이 좋다.
셀프 호스팅과 맞춤 모델 요구사항
추출을 반드시 자신의 인프라 안에서만 돌려야 한다는 강한 요구가 있다면 — 예를 들어 컴플라이언스 의무가 있거나, 그냥 제3자 API로 데이터를 보내고 싶지 않다거나 — 이 목록에서 그 조건을 충족하는 유일한 옵션은 ScrapeGraphAI의 오픈소스 코어다. Thunderbit은 셀프 호스팅 배포를 제공하지 않으며, 모든 접점이 관리형 제품이다.
정확성, 안정성, 비용 통제
이 부분은 신중해야 한다. 비교 글이 자칫 “우리 도구는 절대 실패하지 않는다”는 식으로 흘러가기 쉬운데, 둘 중 어느 제품에도 그런 말을 하는 건 솔직하지 않기 때문이다. LLM 기반 추출은 본질적으로 변동성이 있다. 페이지 리디자인, 특이한 레이아웃, 무거운 JavaScript 뒤에서 로드되는 페이지는 어떤 도구를 쓰든 자동 추출을 흔들 수 있다.
어떤 도구를 쓰든 워크플로우를 만들기 전에 알아두면 좋은 점:
- 봇 차단과 동적 사이트의 한계는 둘 다 존재한다. Thunderbit의 관리형 렌더링과 봇 차단 대응은 지원되는 승인된 페이지에 적용된다. 인터넷상의 모든 반스크래핑 수단을 우회할 수 있다는 보장은 아니다. ScrapeGraphAI의 기반 fetch/render 계층도 비슷한 현실적 제약을 받는다. 어느 쪽도 모든 CAPTCHA나 속도 제한을 무조건 통과한다고 약속하지 않는다.
- 구조화된 스키마는 변동성을 줄이지만, 없애지는 못한다. ScrapeGraphAI의 JSON 스키마 옵션이든 Thunderbit의 필드별 추출 지시문이든, AI가 채워야 할 구조를 더 명확히 주면 일반적으로 더 일관된 결과가 나온다.
- 크레딧/비용 공식은 워크플로우 효율을 보상한다. ScrapeGraphAI는 엔드포인트별 과금 구조를 사용하므로(Scrape와 Crawl, Monitor의 비용이 다름), 목적에 맞는 엔드포인트를 정확히 쓰면 쓸수록 크레딧이 더 오래 간다. 사용량 기반 요금제에서는 어느 벤더든 대체로 같은 논리가 적용된다. 비효율적인 워크플로우는 비용이 더 든다.
가격, 오픈소스, 총소유비용
가격은 특히 조심해서 봐야 한다. 두 제품 모두 숫자가 바뀔 수 있고, 지금 내가 적는 내용이 당신이 읽는 시점에는 이미 오래됐을 수도 있기 때문이다. 아래는 이 글 작성 시점(2026-08-14)에 확인한 최신 수치와 함께 정리한 프레임워크다. 예산을 정하기 전에는 반드시 현재 가격 페이지를 다시 확인하라.
공식 가격 페이지 기준 ScrapeGraphAI 요금제:
- Free — $0, 일회성 500 크레딧, 분당 10 요청, 모니터 1개, 동시 크롤 1개
- Starter — 월 $20, 10,000 크레딧, 분당 100 요청, 모니터 5개, 크롤 3개
- Growth — 월 $100, 100,000 크레딧, 분당 500 요청, 모니터 25개, 크롤 15개, 기본 프록시 회전
- Pro — 월 $500, 750,000 크레딧, 분당 5,000 요청, 모니터 100개, 크롤 50개, 고급 프록시 회전
- Enterprise — 맞춤형
그리고 거의 아무도 명확히 설명하지 않는 부분이 있다. 크레딧 비용은 엔드포인트별로 다르다. 기본 Scrape 호출(Markdown/HTML)은 대략 1 크레딧부터 시작하고, 스크린샷은 약 2 크레딧, 브랜딩 추출은 약 25 크레딧이다. Extract는 약 5 크레딧이며, 더 접근이 어려운 페이지가 필요하면 “stealth” 옵션에 따른 추가 비용이 붙는다. Search는 프롬프트 없이 결과당 2 크레딧, 프롬프트가 있으면 결과당 5 크레딧이다. Crawl은 시작용 2 크레딧에, 크롤링된 각 페이지의 Scrape 비용이 더해진다. Monitor는 매 체크마다 포맷 비용이 들고, 변경이 실제로 감지되면 5 크레딧이 추가된다.
이 구조는 파이프라인 최적화에는 정말 유용하다. 하지만 “얼마나 들까?”라는 질문에 단일 답이 나오지 않는다는 뜻이기도 하다. 어떤 엔드포인트를 얼마나 자주 쓰느냐에 따라 완전히 달라진다. 오픈소스 코어를 셀프 호스팅하면 크레딧 비용 대신 LLM API 비용과 인프라/엔지니어링 시간을 지불하는 셈이다. 규모가 커질수록 더 저렴할 수도 있지만, 팀 안에서 이를 책임질 사람이 필요하다.
Thunderbit의 현재 가격은 공식 가격 페이지를 직접 확인하라. 구독 단계와 크레딧 허용량은 바뀌기 쉬운 부분이라, 다음 분기에는 이미 달라져 있을 수 있는 숫자를 억지로 적기보다 원문을 보는 편이 낫다.
솔직한 결론은 이렇다. 두 도구의 가격을 서로의 단위로 바로 비교할 수는 없다. ScrapeGraphAI의 “크레딧”과 Thunderbit의 “행” 또는 “태스크” 크레딧은 같은 화폐가 아니다. 비용이 핵심 기준이라면, 실제 예상 사용량 — 월 몇 페이지, 주 몇 번의 추출 작업 같은 현실적인 워크로드 — 을 기준으로 두 제품의 현재 가격 페이지를 각각 대조해보고 결정해야 한다.
Thunderbit을 선택해야 하는 사람
마케터, 영업 운영 담당자, 리서처, 소규모 팀 운영자처럼 웹페이지에서 구조화된 데이터를 빠르게 뽑아내고 싶지만 코드, API, 인프라 관리는 원하지 않는다면 Thunderbit이 딱 맞다. 브라우저 추출, 클라우드 실행, API 접근, MCP 연동까지 한 제품으로 해결하고 싶을 때도 마찬가지다.
ScrapeGraphAI를 선택해야 하는 사람
데이터 파이프라인, RAG 시스템, 또는 추출 로직을 프로그램적으로 제어해야 하는 에이전트 워크플로우를 만드는 개발자라면, 자신만의 모델을 선택하고 필요하면 셀프 호스팅도 가능하며, scrape/search/crawl/monitor를 조합 가능한 단계로 오케스트레이션할 수 있는 ScrapeGraphAI의 API 우선 설계가 더 잘 맞는다.
두 도구를 함께 써도 될까?
솔직히 말해 가능하고, 전혀 이상한 일도 아니다. 마케팅/운영 쪽은 Thunderbit으로 빠른 브라우저 추출을 처리하고 — 리드 리스트 만들기, 경쟁사 가격 가져오기 같은 작업 — 엔지니어링 팀은 RAG 시스템이나 내부 도구에 들어갈 백엔드 데이터 파이프라인으로 ScrapeGraphAI API를 쓰는 팀들을 봐왔다. 두 제품 사이의 공식 통합은 없고, 내가 아는 한 계획된 것도 없다. 하지만 아키텍처적으로 보면 회사가 두 도구를 각자 잘 맞는 곳에 쓰는 데 아무런 걸림돌도 없다.
결론
한 문장으로 정리하자면, 누가 작업하는지와 그 파이프라인을 얼마나 통제해야 하는지에 따라 고르면 된다.
Thunderbit은 코드 한 줄 쓰지 않고 깔끔한 표를 얻고 싶은 사람에게 데이터 도달 속도 면에서 강하다. 바로 그게 One Click Extract 워크플로우가 존재하는 이유다. ScrapeGraphAI는 scrape, search, crawl, monitor를 조합해 맞춤형 파이프라인을 만들고 싶은 개발자에게 유연성과 깊이 면에서 강하다. 특히 셀프 호스팅이나 모델 선택이 중요하다면 더 그렇다.
두 도구 모두 모든 웹사이트에서 성공을 보장하지는 않는다. 반봇 대응과 페이지 복잡도는 둘 다 현실적인 한계다. 그러니 예산을 넣기 전에 실제 대상 사이트로 먼저 테스트해보는 게 좋다.
FAQ
ScrapeGraphAI는 완전한 오픈소스인가요?
부분적으로 그렇다. 핵심 추출 엔진(scrapegraphai)은 셀프 호스팅 가능한 오픈소스 Python 패키지다. 관리형 fetch, 프록시 회전, Crawl, Monitor, 크레딧 과금이 포함된 호스티드 API는 그 엔진 위에 얹힌 별도의 상용 제품이다.
ScrapeGraphAI는 API와 MCP를 제공하나요? 그렇다. v2 API에는 Scrape, Extract, Search, Crawl, Monitor, Schema, History 엔드포인트가 포함되며, 호환되는 AI 에이전트를 위한 도구로 동일한 기능을 노출하는 공식 MCP 서버도 있다.
Thunderbit은 코딩이 필요한가요? 핵심 워크플로우에는 필요 없다. Chrome 확장 프로그램은 원클릭 에이전틱 흐름으로 동작하므로 셀렉터, 프롬프트, 스키마가 필요 없다. 프로그래밍 방식 접근이 필요한 개발자는 대신 Open API, MCP 서버, CLI를 사용할 수 있다.
어느 쪽이 셀프 호스팅을 지원하나요? 오픈소스 Python 패키지를 통해 자신의 인프라에서 추출 엔진을 돌리고 싶다면 ScrapeGraphAI다. Thunderbit은 모든 접점이 관리형 제품이며 셀프 호스티드 배포를 제공하지 않는다.
비즈니스 사용자에게 더 빠른 것은 무엇인가요? 실질적으로는 거의 항상 Thunderbit이다. 비기술 사용자가 프롬프트나 스키마를 건드리지 않고, 열린 웹페이지에서 구조화된 내보내기까지 한 번에 가도록 설계된 워크플로우이기 때문이다. ScrapeGraphAI는 API와 코드를 편하게 다루는 개발자를 위한 제품이라서, 여기서의 “속도”는 첫 클릭까지의 시간이 아니라 파이프라인 유연성에 더 가깝다.
