Thunderbit는 웹사이트에서 데이터를 모아주는 AI 웹 스크래퍼 Chrome 확장 프로그램이에요. ScrapingBee의 가격 페이지는 첫인상은 꽤 저렴하지만, 실제 운영에서 물량을 키우기 시작하면 크레딧이 기본 요금의 5배에서 75배까지 순식간에 빠져나갈 수 있어요. 이 리뷰에서는 보통 글들이 잘 안 다루는 5가지 각도를 짚어요. 대규모 운영 시 실제 비용, 셀렉터 방식과 AI 추출의 차이, 비개발자 입장의 사용성, 스크래핑 이후의 데이터 워크플로, 그리고 2026년 기준 신뢰성 벤치마크까지요. 개발자든, 세일즈 오퍼레이션 담당자든, 창업자든 팀용으로 ScrapingBee를 보고 있다면 꼭 필요한 정리예요.
ScrapingBee란? 빠르게 살펴보기
ScrapingBee는 프록시 순환, JavaScript 렌더링, CAPTCHA 해결을 대신 처리해 주는 웹 스크래핑 API예요. 개발자가 직접 스크래핑 인프라를 짜지 않아도 사이트에서 데이터를 뽑을 수 있게 해 주죠. 파라미터를 붙인 HTTP 요청을 보내면 HTML(일부 엔드포인트는 JSON) 응답이 와요. 눈으로 보면서 만드는 클릭형 인터페이스는 없어요.
주요 기능은 이래요.
- 순환 및 프리미엄 프록시(classic, premium, stealth, residential)
- 헤드리스 브라우저 렌더링(전체 Chrome, 기본 활성화)
- 자동 CAPTCHA 우회
- Google Search API(organic 결과, 광고, 지도, 지식 그래프, People Also Ask, 이미지, 뉴스까지 구조화된 JSON 제공)
- 스크린샷 캡처(기본, 전체 페이지, 또는 CSS 선택자 지정 대상)
country_code파라미터를 통한 지역 타깃팅- CSS/XPath 추출 규칙(선언형 JSON 기반, 구조화된 JSON 반환)
- Amazon, Walmart, YouTube, ChatGPT용 전용 API
- AI 추출(
20242025 추가):ai_query,ai_extract_rules,ai_selector파라미터(+5 크레딧/요청) - CLI 도구(
20252026 출시): 배치 처리, 크롤링, 사이트맵 파싱, CSV 보강, 예약 cron 작업, 프록시 단계적 상향
2019년 프랑스에서 시작한 ScrapingBee는 2026년 초 기준 약 500만 달러 ARR 규모로 컸고, SAP, Zapier, Deloitte, Zillow를 포함해 2,500곳 넘는 고객을 확보했어요. 놀랍게도 이걸 직원 4~6명짜리 부트스트랩 팀으로 해냈어요. 2025년 6월에는 Oxylabs Group이 ScrapingBee를 인수했어요. 브랜드와 리더십은 독립을 유지하고, 지원팀은 2배 넘게 확대돼 시간대별 대응 범위도 좋아졌어요.
한 가지 더 알아둘 게 있어요. ScrapingBee는 여전히 네이티브 시각적 빌더, 클릭형 GUI, 내장 웹 대시보드 스케줄러가 없어요. 예약 실행은 CLI 도구, cron 작업, 또는 Zapier, Make, n8n 같은 외부 자동화 도구가 있어야 해요. 이들이 말하는 「노코드」 가이드도 네이티브 노코드 UI가 아니라 Make와 Zapier 연동을 쓰는 방법을 뜻해요.
ScrapingBee는 실제로 누구를 위한 도구인가?
ScrapingBee는 Python이나 cURL 호출을 짜고, HTML을 읽고, CSS/XPath 선택자를 다룰 줄 아는 개발자를 위해 만들어졌어요. 문서도 코드 중심이라 Python과 cURL 예시가 많아요. Capterra의 한 리뷰어는 「JavaScript 예시는 안 준다」고 했고, 또 다른 사용자는 문서를 두고 「덩치가 커서 읽는 데 하루에서 일주일은 걸린다」고 표현했어요.
그런데 2026년에 「ScrapingBee review」를 검색하는 사람이 백엔드 엔지니어만은 아니죠. 잠재고객 리스트를 만드는 마케팅 매니저, CRM 데이터를 보강하는 세일즈 오퍼레이션 팀, 경쟁사 가격을 보는 이커머스 운영팀, 팀 도입을 검토하는 창업자도 다 포함돼요. 그래서 아래 각 섹션마다 해당 기능이나 한계가 개발자에게, 비개발자에게, 아니면 둘 다에게 얼마나 중요한지 같이 짚을게요.
ScrapingBee 요금제 한눈에 보기
2026년 4월 기준 ScrapingBee의 요금제는 이래요.
| 플랜 | 월 요금 | API 크레딧/월 | 동시 요청 수 |
|---|---|---|---|
| Freelance | $49 | 250,000 | 10 |
| Startup | $99 | 1,000,000 | 50 |
| Business | $249 | 3,000,000 | 100 |
| Business+ | $599 | 8,000,000 | 200 |
| Enterprise | 영업팀 문의 | 4,100만+ | 맞춤형 |
연간 결제 시 17% 할인이 붙어요. 무료 체험은 카드 등록 없이 1,000 API 크레딧을 줘요. Google Search API는 인수 이후 최근 호출당 25 크레딧에서 15 크레딧으로 인하됐고요.
표면 크레딧 수치는 넉넉해 보여요. 하지만 실제는 달라요.
크레딧 배수 표
여기서부터 ScrapingBee 가격 구조가 복잡해져요. 표면 크레딧 수는 실제로 긁을 수 있는 페이지 수와 달라요. 요청마다 어떤 기능을 켜느냐에 따라 달라지거든요.
| 요청 유형 | 요청당 크레딧 |
|---|---|
클래식 프록시, JS 렌더링 없음 (render_js=false) | 1 크레딧 |
| 클래식 프록시, JS 렌더링 사용(기본값) | 5 크레딧 |
| 프리미엄 프록시, JS 렌더링 없음 | 10 크레딧 |
| 프리미엄 프록시, JS 렌더링 사용 | 25 크레딧 |
| 스텔스 프록시(JS 항상 활성화) | 75 크레딧 |
| AI 추출 추가 기능 | 기본 비용에 +5 크레딧 |
핵심은: JavaScript 렌더링이 기본으로 켜져 있다는 점이에요. render_js=false를 직접 지정하지 않으면 모든 요청이 최소 5 크레딧을 써요. 그러니까 Freelance 플랜의 250,000 크레딧은 기본 요청 기준으로 실제 50,000건만 처리할 수 있어요. 250,000건이 아니라요.
아무도 잘 안 보여주는 숨은 크레딧 계산식
10,000페이지를 긁을 때 ScrapingBee 실제 비용이 시나리오와 플랜에 따라 어떻게 달라지는지 볼게요.
| 시나리오 | 필요 크레딧 | Freelance ($49/25만) | Startup ($99/100만) | Business ($249/300만) |
|---|---|---|---|---|
| 1만 페이지(정적 HTML, 1크레딧) | 10,000 | ✅ 커버됨 ($0.20/1K) | ✅ 커버됨 ($0.10/1K) | ✅ 커버됨 ($0.08/1K) |
| 1만 페이지(JS 렌더링, 5크레딧) | 50,000 | ✅ 커버됨 ($0.98/1K) | ✅ 커버됨 ($0.50/1K) | ✅ 커버됨 ($0.42/1K) |
| 1만 페이지(프리미엄 프록시 + JS, 25크레딧) | 250,000 | ⚠️ 정확히 한도 도달 ($4.90/1K) | ✅ 커버됨 ($2.48/1K) | ✅ 커버됨 ($2.08/1K) |
| 1만 페이지(스텔스 프록시, 75크레딧) | 750,000 | ❌ 한도 초과 | ✅ 간신히 커버 ($7.43/1K) | ✅ 커버됨 ($6.23/1K) |
같은 10,000페이지인데도 프록시와 렌더링 설정에 따라 1,000페이지당 $0.20에서 $7.43까지 벌어져요. 게다가 어떤 구성이 필요한지는 직접 돌려보기 전엔 모를 때가 많아요.
예산 시나리오: 월 10,000페이지 리드 생성
세일즈 팀이 리드 생성용으로 매달 기업 페이지 10,000개를 긁는다고 해볼게요. 요즘 B2B 사이트는 대부분 React나 Vue를 써서 JS 렌더링이 필요해요.
- 필요 크레딧: 50,000(1만 × 5 크레딧)
- Freelance 플랜($49): 20만 크레딧이 남으니 충분
- 단, 대상 사이트에 프리미엄 프록시가 필요하면: 250,000 크레딧이 들어 Freelance 한도와 딱 일치, 여유분 없음
- 스텔스 프록시가 필요하면: 750,000 크레딧이라 월 $99 Startup 플랜이 필요
예산 시나리오: 월 100,000페이지 이커머스 가격 모니터링
이커머스 팀이 경쟁사 제품 페이지 100,000개를 모니터링하는 경우예요.
| 구성 | 필요 크레딧 | 필요 플랜 | 월 비용 |
|---|---|---|---|
| 정적 HTML(1크레딧) | 100,000 | Freelance | $49 |
| JS 렌더링(5크레딧) | 500,000 | Startup | $99 |
| 프리미엄 프록시 + JS(25크레딧) | 2,500,000 | Business | $249 |
| 스텔스 프록시(75크레딧) | 7,500,000 | Business+ | $599 |
같은 작업이 월 $49에서 $599까지 달라져요. 사소한 차이가 아니라, 설정에 따라 비용이 12배까지 벌어지는 거예요.
「49달러라는 진입 가격은 스크래핑 API 시장에서 가장 오해를 부르는 숫자다.」 — Prospeo
「JavaScript 렌더링이나 고급 기능을 사용하면 크레딧이 빠르게 소진되어, 소규모 프로젝트나 스크래핑량이 들쭉날쭉한 팀에게는 정당화하기 더 어려워진다.」 — Nick S, 매니저, 컴퓨터 소프트웨어, Capterra
그리고 안 쓴 크레딧은 이월되지 않아요.
ScrapingBee 비용은 경쟁사와 비교해 어떤가?
공정한 비교를 위해 중간급 플랜으로 맞춰 볼게요.
| 시나리오(1,000페이지당) | ScrapingBee ($99/100만) | ScraperAPI ($149/100만) | Scrapfly ($100/100만) |
|---|---|---|---|
| 정적 HTML | $0.10 | $0.15 | $0.10 |
| JS 렌더링 페이지 | $0.50 | $1.64 | $0.60 |
| 프리미엄 + JS | $2.48 | $3.73 | $3.00 |
| 스텔스/울트라 프리미엄 + JS | $7.43 | $11.18 | 해당 없음 |
정적 페이지나 JS 렌더링 페이지에서는 ScrapingBee가 대체로 가장 싸거나 최소한 비슷한 수준이에요. ScraperAPI는 꾸준히 가장 비싼 편이고, JS 렌더링 비용도 ScrapingBee·Scrapfly의 +5 크레딧보다 큰 +10 크레딧이에요. 단, Scrape.do의 독립 테스트를 보면 실제 사이트 복잡도를 반영했을 때 그림이 달라져요.
| 서비스 | 평균 1,000요청당 비용 | 성공률 | 평균 응답 시간 |
|---|---|---|---|
| Scrape.do | $0.80 | 98.19% | 4.7초 |
| ScrapingBee | $3.90 | 92.69% | 11.7초 |
| Scrapfly | $4.11 | — | — |
| ZenRows | $4.48 | 92.64% | 10.0초 |
| ScraperAPI | $8.49 | 92.70% | 15.7초 |
Thunderbit의 크레딧 모델: 전혀 다른 접근
Thunderbit은 훨씬 단순한 가격 모델을 써요. 1 크레딧 = 출력 행 1개이고, JS 렌더링이나 프록시 종류, 타깃 도메인에 따른 배수가 없어요. 하위 페이지 스크래핑은 행당 2크레딧이에요.
| 플랜 | 월 요금 | 크레딧 | 행당 비용 |
|---|---|---|---|
| Free | $0 | 월 6페이지 | 무료 |
| Starter | $15 | 500 | $0.030 |
| Pro 1 | $38 | 3,000 | $0.013 |
| Pro 2 | $75 | 6,000 | $0.013 |
| Pro 3 | $125 | 10,000 | $0.013 |
| Pro 4 | $249 | 20,000 | $0.012 |
JS가 많은 이커머스 사이트에서 상품 목록 10,000개를 긁는 Thunderbit 사용자는, 그 사이트가 JavaScript 렌더링이나 프리미엄 프록시, 봇 차단 우회를 요구하더라도 월 $125만 내요. ScrapingBee에서는 같은 작업이 설정에 따라 $49에서 $599까지 갈 수 있고요. 예산을 예측할 수 있다는 건 실제로 큰 차이예요.
CSS 선택자 vs. AI 추출: 꼭 알아야 할 유지보수 비용
ScrapingBee 리뷰 대부분이 이 부분을 통째로 건너뛰어요. 하지만 몇 달, 몇 년에 걸쳐 대규모로 긁을 계획이라면 어쩌면 가장 중요한 요소일 수 있어요.
ScrapingBee는 HTML에서 데이터를 뽑을 때 CSS/XPath 선택자를 써요. JSON 객체로 추출 규칙을 정의하면 일치하는 데이터를 돌려줘요. 처음엔 잘 돼요. 문제는 그다음이에요.
선택자 깨짐 문제
대상 사이트가 레이아웃을 바꾸면 — 클래스명, DOM 구조, 프레임워크 버전이 달라지면 — CSS 선택자가 깨져요. 2,500개 넘는 활성 작업을 돌리는 성숙한 스크래핑 시스템 연구에서 주당 1~2% 깨짐 비율이 나왔는데, 추출기를 멀쩡히 돌리는 데만 주당 3035건 수정이 필요하다는 뜻이에요. 50개 사이트를 긁는 조직이면 연간 유지보수 시간이 8501,300시간에 이르고, 완전 원가 기준 엔지니어 인건비로 $64,000~$156,000이 들어요.
팀들은 이 비용을 계속 과소평가해요. 처음엔 보통 월 1015시간 유지보수로 잡지만, 실제는 4~6배 더 높아 월 4090시간이 되는 경우가 흔해요. 선택자가 깨졌는데 에러 없이 빈 데이터만 계속 돌려주는 조용한 실패 하나만으로도, 매출 손실과 순위 복구, 직원 시간 손실을 합쳐 약 $38,000~$57,000이 날아갈 수 있어요.
주요 원인은 프레임워크 업데이트 중 CSS 클래스명 변경, 대상 주변에 새 컨테이너 삽입, React/Vue/Angular 버전 업그레이드로 인한 DOM 재구성, 동적 클래스명을 쓰는 A/B 테스트, 그리고 스크래핑 방지용 난독화예요.
AI 기반 추출은 유지보수를 60~80% 줄인다
2025년 DataRobot 연구에 따르면 AI 기반 스크래퍼는 사이트 리디자인 이후 기존 셀렉터 기반 스크래퍼보다 유지보수가 70% 적게 든다고 해요. 시간 배분도 사실상 뒤집혀요.
| 지표 | 기존 방식(CSS 선택자) | AI 기반 방식 |
|---|---|---|
| 리디자인 이후 유지보수 | 기준선 | 70% 감소 |
| 시간 비중(설정 : 유지보수) | 20% : 80% | 데이터 기준 5% : 95% |
| 전체 유지보수 감소 | 기준선 | 60~80% 감소 |
| JS 많은 페이지에서 속도 | 기준선 | 30~40% 더 빠름 |
설정 시간: 선택자 작성 vs. AI 추천 필드
ScrapingBee 설정: 페이지 소스 확인 → CSS 선택자 식별 → JSON으로 추출 규칙 작성 → 테스트 및 디버깅 → 페이지 변형 예외 처리 → 깨짐 모니터링 → 사이트 업데이트 시 깨진 선택자 수정
Thunderbit 설정: Chrome에서 페이지 열기 → 「AI Suggest Fields」 클릭 → AI가 페이지를 읽고 적절한 데이터 유형과 함께 컬럼 제안 → 「Scrape」 클릭. 선택자 작성도, 소스 코드 검토도 필요 없어요. Thunderbit의 AI는 여러 파운데이션 모델(ChatGPT, Gemini, Claude, DeepSeek R1)을 써서 사람처럼 페이지를 시각적으로 읽어요.
Thunderbit의 Field AI Prompts 는 여기에 한 겹을 더해요. 컬럼마다 날짜 포맷 변경, 텍스트 번역, 상품 분류, 이름 분리, 전화번호 정규화 같은 변환 지시문을 붙일 수 있어요. ScrapingBee 사용자라면 따로 만들어야 하는 후처리 단계를 없애 주죠.
구조화된 출력: 원시 HTML vs. 바로 쓸 수 있는 행
| 항목 | ScrapingBee(셀렉터 기반) | Thunderbit(AI 기반) |
|---|---|---|
| 기본 출력 | 원시 HTML | 타입이 지정된 구조화 행 |
| 구조화 추출 | CSS/XPath 규칙 작성 또는 AI 추가 기능(+5 크레딧) 필요 | AI가 필드를 자동 감지 |
| 지원 데이터 유형 | 텍스트(HTML 파싱 필요) | 텍스트, 숫자, 날짜, URL, 이메일, 전화번호, 이미지 |
| 레이아웃 변경 대응력 | ⚠️ 수동 선택자 수정 필요 | ✅ AI가 매번 페이지를 새로 읽음 |
| 필요한 기술 수준 | Python/cURL, CSS 선택자, HTML 이해 | 없음 — 2클릭 워크플로의 Chrome 확장 프로그램 |
| 장기 유지보수 | 지속적 필요(주당 1~2% 깨짐률) | 거의 없음(AI가 자동 적응) |
ScrapingBee도 선택자 유지보수 부담을 좀 덜려고 AI 추출 기능(ai_query, ai_extract_rules)을 추가했어요. 단, 이 기능은 기본 비용 위에 요청당 +5 크레딧이 붙고, 도구 자체는 여전히 시각적 인터페이스 없는 API 우선 구조예요.
비개발자 입장에서 본 ScrapingBee 사용성
ScrapingBee는 비기술 사용자를 겨냥한 도구가 아니에요. API이에요. 코드를 짜서 써야 해요. 마케팅 매니저나 세일즈 오퍼레이션 담당자가 이 글을 보고 있다면, 사실 여기서 결론은 거의 난 셈이에요.
비기술 사용자가 ScrapingBee를 쓸 때 실제로 거치는 과정은 이래요.
- Python, cURL 또는 다른 언어로 API 호출 작성
render_js=true,premium_proxy=true,country_code=us같은 HTTP 파라미터 이해- BeautifulSoup 같은 라이브러리로 원시 HTML 응답 구문 분석
- 특정 데이터 필드를 뽑기 위한 CSS 선택자 작성
- 맞춤 크롤링 로직을 짜서 페이지네이션 처리(ScrapingBee는 단일 페이지 요청만 처리)
- 추출 데이터를 정리·구조화·저장하는 데이터 파이프라인 구축
드래그 앤 드롭 빌더도, 클릭형 인터페이스도, 내가 뭘 긁는지 미리 보여 주는 시각적 미리보기도 없어요.
「학습 곡선이 있어요. 문서도 덩치가 커서 읽는 데 하루에서 일주일은 걸려요.」 — Arvind K, Proprietor, Financial Services, Capterra
「시스템이 꽤 특이해서 코드와 구조를 익히는 데 시간이 꽤 걸려요.」 — Capterra 리뷰
개발자들은 이 방식을 좋아해요. 한 리뷰어는 「완전히 API 기반이라 아주 현대적이고 세련됐으며, 그냥 잘 작동한다」고 했어요. 하지만 개발자가 API를 평가할 때의 「사용성」과, 코딩 없이 리드 리스트를 만들려는 사람이 느끼는 「사용성」은 완전히 다른 얘기죠.
노코드 대안이 더 적합한 경우
Thunderbit Chrome Extension은 완전히 다른 경험을 줘요.
- 확장 프로그램이 깔린 상태로 Chrome에서 웹페이지 열기
- 「AI Suggest Fields」 클릭 — AI가 페이지를 스캔해 적절한 데이터 유형과 함께 컬럼(Product Name, Price, Rating, URL 등)을 제안
- 검토 및 수정 — 컬럼 추가/삭제/이름 변경, 변환용 Field AI Prompt 추가
- 「Scrape」 클릭 — 구조화된 행으로 데이터 추출
- 내보내기 — Google Sheets, Airtable, Notion, Excel, CSV, JSON으로 원클릭 내보내기(모든 내보내기 무료)
API 호출도, 선택자도, 코드도 필요 없어요. Thunderbit은 2026년 4월 기준 55개 언어를 지원해요.
평범한 사이트라면 Thunderbit은 즉시 사용 가능한 스크래퍼 템플릿도 줘요. Amazon, Zillow, Shopify, LinkedIn, Google Maps, Instagram, eBay, Apollo 등용으로 이미 만들어져 유지되는 템플릿이라, AI가 필드를 제안하길 기다릴 필요도 없어요. 바로 돌리면 돼요.
거기에 별도 플랜 없이 쓰는 영구 무료 도구도 몇 개 있어요. 이메일 추출기, 전화번호 추출기, 이미지 추출기가 있어서 빠른 데이터 수집이 필요한 세일즈·마케팅 팀에 유용해요.
의사결정 프레임워크: 누가 무엇을 써야 하나?
| 당신이… | 가장 적합한 선택 |
|---|---|
| API와 HTML 파싱에 익숙한 개발자 | ScrapingBee 또는 ScraperAPI |
| 셀렉터 작업 없이 구조화된 데이터를 원하는 기술 사용자 | Thunderbit API(Extract 엔드포인트) |
| 코딩이 전혀 없는 비즈니스 사용자(세일즈, 마케팅, 이커머스 운영) | Thunderbit Chrome Extension |
| DevOps 없이 예약 모니터링이 필요한 팀 | Thunderbit Scheduled Scraper(자연어 스케줄링) |
| 깨끗한 마크다운이 필요한 LLM/RAG 파이프라인 구축자 | Thunderbit Distill API 또는 Firecrawl |
| 예산 예측 가능성이 중요하고 크레딧 배수를 원치 않는 사용자 | Thunderbit(1 크레딧 = 1 행) |
스크래핑 이후: 내 데이터는 실제로 어디로 가나?
스크래핑은 일의 절반일 뿐이에요. 나머지 절반, 즉 그 데이터를 실제 쓸 수 있는 곳으로 옮기는 단계에서 ScrapingBee 리뷰 대부분은 입을 다물어요.
ScrapingBee: 원시 HTML 출력, 파이프라인은 직접 구축
ScrapingBee는 기본적으로 원시 HTML을 돌려줘요. 그다음은 직접 해야 해요.
- BeautifulSoup 또는 lxml로 HTML 구문 분석
- 내비게이션, 푸터, 스크립트, 스타일 제거(일반적인 페이지 콘텐츠의 80~90%를 차지)
- 특정 데이터 필드 추출
- 구조화된 형식으로 변환
- 페이지네이션 및 오류 상태 처리
- 데이터 저장 및 배포
「ScrapingBee는 원시 HTML을 반환해요. AI 에이전트에는 깨끗한 마크다운, 의미 기반 검색, 웹훅이 필요해요.」 — KnowledgeSDK
ScrapingBee도 return_page_markdown=true, return_page_text=true 옵션과 Google Search API의 구조화 JSON을 제공해요. 하지만 기본 워크플로와 범용 스크래핑 경험은 결국 사용자가 직접 처리해야 하는 원시 HTML이에요.
보통은 BeautifulSoup/lxml 같은 구문 분석 도구, Pandas 데이터 정리, 예약 실행용 cron/Airflow, 다중 페이지용 맞춤 크롤 로직, 거기에 별도 클라우드 저장소까지 더 필요해요. 「긁었다」와 「이제 쓸 수 있다」 사이에 들어가는 엔지니어링이 꽤 돼요.
Thunderbit: 내장 내보내기가 포함된 구조화 출력
Thunderbit은 텍스트, 숫자, 날짜, URL, 이메일, 전화번호, 이미지 등으로 타입이 정해진 구조화 행을 돌려주고, 바로 내보낼 수 있어요. 모든 플랜에서 내보내기가 무료예요.
| 내보내기 대상 | 비용 |
|---|---|
| Excel (.xlsx) | 무료 |
| Google Sheets | 무료(직접 연동) |
| Airtable | 무료(직접 연동) |
| Notion | 무료(직접 연동) |
| CSV | 무료 |
| JSON | 무료 |
이미 Google Sheets나 Airtable을 CRM·운영 허브로 쓰는 팀이라면, 이 기능 하나로 엔지니어링 한 겹을 통째로 덜어낼 수 있어요. Notion이나 Airtable로 내보낼 때 이미지가 이미지 라이브러리에 업로드돼 인라인으로 보이는데, 사소해 보여도 실제 사용성에서는 꽤 중요한 디테일이에요.
ScrapingBee의 연동 생태계
ScrapingBee는 Zapier(8,000개 이상 앱), Make(3,000개 이상 앱), n8n, Microsoft Power Automate 같은 서드파티 연동을 지원해요. 원시 HTML과 목적지 도구 사이를 이어 주지만, 그만큼 비용과 복잡성, 그리고 실패 지점이 하나 더 늘어나요.
개발자를 위한 Thunderbit Open API
프로그래밍 방식 파이프라인을 원하는 독자를 위해 Thunderbit은 두 개의 핵심 엔드포인트를 갖춘 Open API를 제공해요.
- Distill 엔드포인트 — 페이지를 깨끗한 Markdown으로 변환, LLM/RAG 파이프라인에 적합(호출당 1크레딧)
- Extract 엔드포인트 — 사용자가 정의한 스키마에 맞는 구조화 JSON 반환(호출당 20크레딧)
- 배치 처리 — 요청당 최대 100개 URL
즉 Thunderbit은 같은 AI 엔진 위에서 노코드 사용자(Chrome Extension)와 개발자(Open API)를 다 받쳐요. 데이터를 긁을 수 있느냐도 중요하지만, 그 데이터가 어디로 가는지도 함께 따져봐야 해요.
2026년 신뢰성 점검: ScrapingBee는 운영 환경에서도 버틸까?
예전 Reddit 스레드(2021~2023)에는 ScrapingBee 신뢰성을 향한 불만이 있어요. 그게 2026년에도 여전히 유효할까요? 독립 벤치마크 6개를 모아 봤어요. 결과는 엇갈렸고, 때로는 서로 모순되기도 했어요.
Scrapeway 격주 벤치마크(2026년 4월)
전체 성공률: 33.3% — 테스트한 9개 서비스 중 7위였어요.
| 웹사이트 | 성공률 |
|---|---|
| Amazon | 48% |
| 41% | |
| Indeed | 38% |
| Etsy | 21% |
| Booking | 17% |
| Realtor | 0% |
| StockX | 0% |
| Twitter/X | 0% |
| Zillow | 0% |
| Walmart | 0% |
| 0% |
Scrapingdog 1:1 비교 테스트(2025)
| 웹사이트 | ScrapingBee | Scrapingdog | ScraperAPI |
|---|---|---|---|
| Amazon | 100% | 100% | 100% |
| Glassdoor | 0% | 100% | 100% |
| eBay | 100% | 100% | 100% |
| Walmart | 40% | 100% | 100% |
| 90% | 100% | 80% |
Proxyway 벤치마크(2025년 12월)
- 초당 2요청에서 84.47% 성공
- 초당 10요청에서 72.98% 성공 — 부하가 걸리면 12포인트 하락
- 평균 응답 시간 25.46초 — 벤치마크 그룹 중 가장 느림
Scrape.do 벤치마크(2025~2026)
- 전체 성공률 92.69%
- 개별 사이트에서는 강세: Amazon 99.11%, Indeed 99.29%, GitHub 100%, X/Twitter 99.6%
- Capterra에서는 약세: 성공률 59%, 응답 시간 36초
패턴 정리
데이터를 보면 패턴이 꽤 또렷해요.
- ScrapingBee는 평범하고 중간 수준으로 보호된 사이트에서 잘 돼요. Amazon, eBay, GitHub, Indeed는 꾸준히 90~100% 성공률이에요.
- 강하게 보호된 사이트에서는 완전히 실패해요. LinkedIn, Zillow, Realtor.com, StockX, Twitter는 여러 벤치마크에서 한결같이 0%였어요.
- 부하가 올라가면 성능이 크게 떨어져요. 초당 2요청에서 84%였던 게 초당 10요청에서는 73%로 내려가요.
- 벤치마크 결과는 방법론을 많이 타요. 사이트 구성이 넓은 Scrapeway에서는 33.3%, 비교적 무난한 대상을 쓴 Scrape.do에서는 92.69%였어요.
ScrapingBee의 Capterra 평점 4.9/5(리뷰 137개)는 분명 좋은 신호예요. 다만 초기 설정이 쉽다는 높은 평점이 대규모 운영에서의 장기 신뢰성까지 보장해 주진 않아요. 실제로 다른 도구로 갈아탄 사용자는 처음 설정의 어려움보다, 시간이 갈수록 늘어나는 실패율과 비용 상승을 더 자주 꼽아요.
「매우 긍정적이에요. ScrapingBee는 안정적이고 예측 가능하며 운영 환경에 쉽게 통합할 수 있었어요.」 — 검증된 리뷰어, CEO, Capterra
ScrapingBee는 「일관되지 않은 신뢰성」을 보였고, 특히 「Glassdoor에서 0% 성공률」과 「Walmart에서 40%」를 기록했어요.
AI 기반 스크래핑은 신뢰성을 다르게 처리한다
Thunderbit의 AI는 렌더링된 페이지를 실시간으로 읽고, 세션마다 봇 차단 대응과 레이아웃 변화에 맞춰 적응해요. 신뢰성 문제를 다루는 모드가 두 가지 있어요.
- Cloud scraping — Thunderbit 클라우드 서버에서 돌고 한 번에 최대 50페이지를 처리, Amazon, Zillow, Shopify 같은 대규모 공개 사이트 작업에 적합
- Browser scraping — 사용자의 Chrome 브라우저에서 돌고, 이미 로그인한 세션을 활용해요. LinkedIn이나 비공개 대시보드, SaaS 플랫폼처럼 인증 뒤 콘텐츠가 있는 사이트에 이상적이에요. ScrapingBee 같은 API 기반 도구는 이 영역에 접근하지 못해요.
Thunderbit은 자주 쓰는 사이트용 즉시 사용 가능한 스크래퍼 템플릿도 제공하고, 구조가 바뀌어도 계속 돌도록 미리 만들어 유지해요. ScrapingBee가 0% 성공률을 보이는 사이트(LinkedIn, Zillow)에서는, 로그인한 사용자 세션을 쓰는 Thunderbit의 브라우저 스크래핑 모드가 전혀 다른 접근이에요.
ScrapingBee vs. 주요 대안: 나란히 비교
| 항목 | ScrapingBee | Thunderbit | ScraperAPI | Scrapfly |
|---|---|---|---|---|
| 유형 | API 전용 | Chrome Extension + API | API 전용 | API 전용 |
| 시작 가격 | $49/월 | 무료($0) | $49/월 | $30/월 |
| 크레딧 모델 | 배수(1×~75×) | 1 크레딧 = 1 행(배수 없음) | 배수(1×~75×) | 배수(1×~30×) |
| AI 추출 | 있음(+5 크레딧/요청) | 내장(AI Suggest Fields) | 네이티브 AI 없음 | 있음 |
| 노코드 옵션 | 없음(API 전용) | 있음(Chrome Extension) | 없음(API 전용) | 없음(API 전용) |
| 구조화 출력 | CSS 규칙 또는 AI 추가 기능 필요 | 기본 제공(타입 지정 컬럼) | 특정 사이트용 구조화 엔드포인트 | 제각각 |
| 내보내기 대상 | 원시 HTML/JSON(직접 구축) | Excel, Sheets, Airtable, Notion, CSV, JSON(모두 무료) | 원시 HTML/JSON | 원시 HTML/JSON |
| 하위 페이지 스크래핑 | 수동(크롤 로직 직접 작성) | 내장(2크레딧/행) | 수동 | 수동 |
| 예약 스크래핑 | CLI 전용(대시보드 스케줄러 없음) | 내장(자연어) | 내장 아님 | 내장 아님 |
| 무료 티어 | 1,000 크레딧 체험 | 월 6페이지(영구) | 5,000 크레딧(7일 체험) | 1,000 크레딧 |
| 기본 JS 렌더링 | 켜짐(비용 5배) | 포함(추가 비용 없음) | 꺼짐 | 꺼짐 |
| 학습 곡선 | 높음(API + 선택자) | 낮음(2클릭 워크플로) | 높음(API + 선택자) | 높음(API) |
| 가장 적합한 경우 | 프록시 제어를 원하는 개발자 | 비즈니스 사용자 + 개발자 | 개발자 + 구조화 엔드포인트 | ASP 우회를 원하는 개발자 |
| Capterra 평점 | 4.9/5(137개 리뷰) | — | 4.6/5(62개 리뷰) | 4.9/5(221개 리뷰) |
ScrapingBee vs. Thunderbit: 핵심 차이
가장 큰 차이는 결국 아키텍처와 대상 사용자예요.
- API 전용 vs. Chrome Extension + API: ScrapingBee는 모든 상호작용에 코드가 들어요. Thunderbit은 노코드 사용자를 위한 Chrome Extension과 개발자를 위한 Open API를 같이 줘요. 같은 AI 엔진, 두 개의 인터페이스죠.
- 셀렉터 기반 vs. AI 기반 추출: ScrapingBee는 CSS/XPath 선택자를 직접 짜고 유지해야 해요. Thunderbit의 AI는 필드를 자동 추천하고, 사이트가 바뀌면 거기에 맞춰 적응해요.
- 원시 HTML 출력 vs. 무료 내보내기가 가능한 구조화 행: ScrapingBee는 구문 분석해야 하는 HTML을 돌려줘요. Thunderbit은 타입과 라벨이 붙은 행을 돌려주고 Excel, Google Sheets, Airtable, Notion으로 원클릭 내보내기가 돼요.
- 하위 페이지 스크래핑: Thunderbit은 AI가 각 상세 페이지를 방문해 메인 테이블을 채워요. 이 기능이 기본 내장이라 별도 크롤 로직이 필요 없어요. ScrapingBee는 직접 짜야 하고요.
- 즉시 사용 가능한 템플릿: Thunderbit은 Amazon, Zillow, Shopify, LinkedIn, Google Maps, eBay 같은 인기 사이트용 템플릿을 바로 쓰게 해 줘요. ScrapingBee는 Amazon·Walmart용 전용 API가 있지만, 쓰려면 여전히 코드를 짜야 해요.
주목할 만한 다른 대안들
- Scrape.do — 독립 테스트 기준 1,000요청당 $0.80으로 가장 저렴, 성공률 98.19%; 월 $29부터
- Apify — 액터 기반 플랫폼, G2 리뷰 415개 이상(4.7/5)이지만 가장 큰 불만은 「요금제 문제」
- Firecrawl — AI/LLM 네이티브, 원시 HTML보다 67% 적은 토큰을 쓰는 마크다운 반환; 오픈소스 코어; 월 $16부터
- Bright Data — 7,200만+ IP를 보유한 엔터프라이즈급, 월 $499부터; 정액 요금
- ZenRows — 5,500만 residential IP, Amazon/Walmart/Zillow용 사전 구축 스크래퍼 제공, 월 $69부터
우리 팀에 맞는 스크래핑 도구는?
시나리오별 추천은 이래요.
- 커스텀 스크래핑 파이프라인을 만들고 세밀한 프록시 제어가 필요한 개발자라면 → ScrapingBee 또는 ScraperAPI. 세부 HTTP 파라미터, 프록시 유형 선택, 렌더링 제어를 다 얻어요. 단, 크레딧 배수 비용은 감안해야 해요.
- 코딩 없이 사이트에서 리드가 필요한 세일즈/마케팅 팀이라면 → Thunderbit Chrome Extension. 구조화 데이터까지 2클릭, Google Sheets까지 1클릭. API도, 선택자도, 구문 분석도 없어요.
- 인기 사이트에서 구조화 데이터를 빠르게 얻고 싶다면 → Thunderbit Instant Templates. Amazon, Zillow, Shopify, LinkedIn 등용으로 미리 만들어져 유지도 돼요. AI 설정조차 필요 없어요.
- DevOps 없이 일정에 맞춰 가격이나 재고를 봐야 한다면 → Thunderbit Scheduled Scraper. 「매주 월요일 오전 9시」처럼 평범한 문장으로 간격을 설명하면 알아서 돌아가요.
- LLM/RAG 파이프라인을 만들고 대규모로 깨끗한 Markdown이 필요하다면 → Thunderbit Distill API 또는 Firecrawl. 둘 다 AI 소비에 최적화된 마크다운을 돌려줘요.
- 예산 예측 가능성이 중요하고 크레딧 배수를 원치 않는다면 → Thunderbit. JS 렌더링이나 프록시 종류와 무관하게 1 크레딧 = 1 행이에요.
총소유비용은 API 가격만으로 끝나지 않아요. 설정 시간 + 유지보수 시간 + 구문 분석 엔지니어링 + 데이터 내보내기 워크플로까지 다 더해야 해요. ScrapingBee의 표시 가격은 경쟁력 있어요. 하지만 전체 비용 그림은 그렇지 않아요.
이 ScrapingBee 리뷰의 핵심 요약
꼭 기억할 다섯 가지를 정리하면 이래요.
- 크레딧 비용은 규모가 커질수록 빠르게 배수로 늘어나요. $49 시작가도 JS 렌더링과 프리미엄 프록시가 필요해지면 $599 이상으로 뛰어요. Thunderbit의 행당 1크레딧 고정 모델은 이 불확실성을 없애요.
- CSS 선택자는 끊임없는 유지보수 부담이 있지만 AI 추출은 이를 피해요. AI 기반 도구는 유지보수를 60~80% 줄이는 데 도움이 되고, 사이트가 바뀌어도 선택자가 깨질 일이 없어요.
- 비개발자에게 ScrapingBee는 진입 장벽이 높아요. 코딩, HTML 확인, 선택자 작성이 필요한 API 전용 도구예요. 비즈니스 사용자는 노코드 대안을 보는 편이 나아요.
- 데이터 내보내기에 별도 엔지니어링이 필요해요. ScrapingBee는 원시 HTML을 돌려주고, 파이프라인은 직접 만들어야 해요. Thunderbit은 구조화 데이터를 Excel, Sheets, Airtable, Notion으로 무료 내보내기할 수 있어요.
- 어떤 사이트에선 안정적이지만, 다른 사이트에선 일관성이 떨어져요. Amazon과 eBay에선 잘 되지만, LinkedIn·Zillow처럼 보호가 강한 대상에선 0% 성공률이 나와요.
ScrapingBee는 프록시 관리형 HTTP 접근과 세밀한 제어를 원하는 개발자에게는 여전히 유능한 도구예요. 하지만 2026년의 웹 스크래핑 시장은 AI 기반 노코드 쪽으로 옮겨가고 있고, Thunderbit는 바로 그 흐름에 맞춰 설계됐어요. 무료 티어(월 6페이지 무료, 또는 무료 체험으로 더 많이)로 직접 차이를 확인해 보세요.
FAQ
2026년에 ScrapingBee는 쓸 만한가요?
기술 수준과 규모에 따라 달라요. 중간 물량의 정적 페이지를 긁는 개발자라면, ScrapingBee는 문서가 잘 돼 있고 지원도 괜찮은 solid API이며 Capterra 평점 4.9/5도 갖췄어요. 다만 비즈니스 사용자, 대량 스크래핑, 코딩 없이 구조화 데이터가 필요한 팀이라면 Thunderbit 같은 AI 기반 대안이 더 높은 가치를 주고 총소유비용도 훨씬 낮아요.
ScrapingBee는 코딩 없이 사용할 수 있나요?
아니요. ScrapingBee는 API 전용이라 Python, cURL 같은 코드 작성과 HTTP 파라미터 이해가 필요해요. 스크래핑을 만드는 시각적 인터페이스는 없어요. 기술이 없는 사용자는 Thunderbit Chrome Extension처럼 코드 한 줄 없이 긁고 내보낼 수 있는 노코드 옵션을 고려하는 게 좋아요.
ScrapingBee의 페이지당 실제 비용은 얼마인가요?
켜는 기능에 따라 달라요. 정적 HTML 페이지는 1크레딧, JS 렌더링 페이지(기본값)는 5크레딧이에요. 프리미엄 프록시 + JS 페이지는 25크레딧, 스텔스 프록시 페이지는 75크레딧이 들고요. AI 추출은 여기에 +5 크레딧이 붙어요. Freelance 플랜($49/25만 크레딧) 기준이면 정적 페이지 1,000개당 $0.20, 스텔스 프록시 페이지 1,000개당 $14.70 정도예요. 전체 세부 계산은 위의 비용 표를 참고하세요.
2026년 기준 최고의 ScrapingBee 대안은 무엇인가요?
주요 대안으로는 Thunderbit(AI 기반, 노코드 Chrome Extension + API, 1 크레딧 = 1 행), ScraperAPI(특정 사이트용 구조화 엔드포인트를 갖춘 개발자 API), Scrapfly(강력한 봇 차단 우회를 갖춘 개발자 API), Scrape.do(독립 테스트에서 가장 저렴한 요청당 비용), Firecrawl(AI/LLM 네이티브, 깨끗한 마크다운 반환)가 있어요. 각각 강점이 달라요. Thunderbit은 비즈니스 사용자와 비용 예측성에, ScraperAPI와 Scrapfly는 개발자용 프록시 제어에, Firecrawl은 LLM 파이프라인에 적합해요.
ScrapingBee는 JavaScript가 많은 웹사이트도 스크래핑할 수 있나요?
가능해요. 단, 순환 프록시를 쓰면 기본 크레딧의 5배, 프리미엄 프록시를 쓰면 25배가 들어요. JavaScript 렌더링은 기본으로 활성화돼 있어서, 직접 끄지 않는 한 이미 5배 요금을 내고 있는 셈이에요. Thunderbit은 크레딧 배수 없이 JS 렌더링을 자동 처리하며, 페이지 구조와 상관없이 1행당 1크레딧만 써요.
더 알아보기
