단 하나의 Google Shopping 검색 페이지에도 유기적 결과 사이에 스폰서 노출이 끼어들고, 품절 상품은 가격이 아예 사라지며, 같은 상품이 서로 다른 판매자 다섯 곳에 중복으로 표시될 수 있습니다. 저는 지난 몇 주 동안 이런 복잡한 데이터를 깔끔하고 쓸 수 있는 형태로 정리해 준다고 주장하는 아홉 가지 도구를 하나씩 뜯어봤습니다. 솔직히 말하면, "최고"가 무엇인지는 개발자가 파이프라인을 만들고 있는지, 아니면 금요일까지 스프레드시트에 숫자만 있으면 되는 마케터인지에 따라 완전히 달라집니다.
이런 차이는 리서치 곳곳에서도 드러납니다. r/learnpython과 r/node에서는 사람들이 Puppeteer, Playwright, 프록시 로테이션 이야기를 주고받습니다. 반면 r/PPC에서는 “코드는 건드리기 싫고, 그냥 데이터만 주세요”에 가까운 요청이 많죠. 그래서 저는 이 아홉 가지 도구를 알파벳순으로 줄 세우거나, 홈페이지가 가장 화려한 업체에 무작정 "종합 1위" 배지를 붙이지 않았습니다. 대신 여섯 가지 구체적인 기준으로 각각을 평가하고, 워크플로우 기준으로 정리했습니다. 즉, 관리형 SERP API를 먼저, 그다음 프록시·스크레이퍼 인프라, 그다음 개발자용 액터 플랫폼, 마지막에 노코드 브라우저 도구 순서입니다.
"최고의" Google Shopping 스크래퍼는 무엇일까? 평가 기준
많은 비교 글에서 "최고"는 너무 쉽게 남발됩니다. 그래서 여기서는 각 벤더의 마케팅 문구를 반복하지 않고, 동일한 여섯 가지 기준으로 아홉 개 도구를 평가했습니다.
- 데이터 커버리지 — 문서화된 스키마가 가격, 판매자, 평점, 리뷰 수, 배송 정보, 그리고 스폰서와 유기적 결과의 실제 구분까지 안정적으로 반환하는가?
- 로케일/지역 지원 — 특정 국가, 언어, 디바이스를 제대로 지정할 수 있는가, 아니면 프록시 IP가 우연히 해석하는 값에 맡겨야 하는가?
- 설정 복잡도 — API 키와 GET 요청이면 끝나는가, 아니면 콜백이 있는 큐 작업인지, 토큰을 이어 붙이는 2단계 워크플로우인지, 아니면 클릭만 하는 페이지형 도구인지?
- 유지보수 부담 — Google이 HTML 구조를 바꾸거나 CAPTCHA를 띄웠을 때 책임은 누구에게 있는가? 사용자 본인인가, 벤더인가?
- 내보내기/연동 경로 — JSON 덤프면 되는가, 아니면 Sheets, Airtable, 데이터 웨어하우스로 바로 연결되는가?
- 가격 투명성 — 실제 단가를 계산할 수 있도록 공개하는가, 아니면 아무것도 알 수 없게 "세일즈 문의"를 해야 하는가?
여기서 제가 하지 않을 한 가지는 성공률, 속도 벤치마크, 정확도 퍼센트를 지어내는 일입니다. 이 목록에 있는 누구도 서로를 상대로 독립적인 벤치마크를 공개한 적이 없고, 벤더가 말하는 "99.9% 성공률"이나 "압도적으로 빠름" 같은 표현은 측정값이 아니라 마케팅 문구일 뿐입니다. 대신 제가 보여드릴 것은 각 벤더의 공식 문서가 실제로 무엇을 증명하는지입니다. 생각보다 꽤 많은 정보를 얻을 수 있습니다.
개발자는 코드를 원하고, 마케터는 노코드를 원한다
스크래핑 관련 커뮤니티를 조금만 봐도 이미 이 구분이 존재한다는 걸 알 수 있지만, 이 리스트의 순서를 이해하려면 굳이 짚고 넘어갈 가치가 있습니다. 데이터 파이프라인을 만드는 개발자는 API 키, 예측 가능한 JSON, 명시적인 로케일 파라미터, 그리고 후단에서 검증·정규화할 수 있는 스키마를 원합니다. 이들은 프록시 로테이션과 헤드리스 브라우저 렌더링에 대해 묻는 사람들입니다.
반면 마케팅이나 PPC 담당자는 “페이지를 가리키면 스프레드시트가 나오는” 수준을 원합니다. 이번 분기에 Google이 쇼핑 레이아웃을 세 번째로 바꾸면 Puppeteer 스크립트를 유지보수하고 싶어 하지 않죠. 그리고 실제로 그럴 겁니다. Google은 쇼핑 마크업을 꽤 자주 바꾸기 때문에, API 벤더조차 변경 로그를 따로 올릴 정도입니다.
그래서 이 목록은 관리형 SERP API 제공업체(SerpApi, Serper, SearchAPI, DataForSEO)부터 시작합니다. 이들은 구조화된 JSON을 제공하고, 프록시 작업은 필요 없지만 여전히 코드가 필요합니다. 그다음은 더 많은 제어권을 주는 대신 설정이 더 필요한 프록시·스크레이퍼 인프라(Bright Data, Oxylabs), 그다음은 완전한 커스터마이즈가 가능한 개발자 액터 플랫폼(Apify), 마지막은 스크래핑 코드를 직접 작성하거나 유지보수하고 싶지 않은 사람들을 위한 노코드 에이전틱 브라우저 도구 Thunderbit입니다.
한눈에 보는 최고의 Google Shopping 스크래퍼 9개
| 도구 | 수집 방식 | 설정 난이도 | 로케일 지원 | 적합한 사용자 | 유지보수 부담 |
|---|---|---|---|---|---|
| SerpApi | 관리형 Shopping API | 낮음(API 키) | 강함(location, gl, hl, device) | 데이터 엔지니어, SEO 도구 | 벤더 관리 |
| Serper | 범용 SERP API, Shopping은 결과 유형 중 하나 | 낮음 | 보통(국가/언어 문서화) | 비용 민감한 개발자 | 벤더 관리 |
| SearchAPI | 관리형 Shopping + Product Offers API | 낮음~보통(오퍼는 2단계) | 보통 | 오퍼/판매자 비교 팀 | 벤더 관리 |
| DataForSEO | 작업 기반 Merchant API | 보통(큐/콜백) | 강함 | 대량/정기 파이프라인 | 벤더 관리 |
| Bright Data | 데이터셋 + Scraper API + SERP API | 보통(표면별 상이) | 매우 강함 | 엔터프라이즈 데이터 팀 | 공유 |
| Oxylabs | 검색 + 상품 상세 2단계 API | 보통(토큰 체인) | 매우 강함 | 엔터프라이즈 데이터 팀 | 공유 |
| Scrapingdog | 전용 Shopping 엔드포인트 | 낮음~보통 | 보통 | 예산을 아끼는 개발자 | 벤더 관리 |
| Apify | 액터/개발자 플랫폼 | 보통~높음 | 액터에 따라 다름 | 맞춤 파이프라인 구축자 | 사용자 관리 |
| Thunderbit | 에이전틱 노코드 브라우저 추출 | 매우 낮음(원클릭 추출) | 대상 페이지에 따라 다름 | 마케터/PPC, 비개발자 | 낮음, 페이지 의존 |
(실제 사용 전에 각 벤더의 최신 문서에서 가격, 크레딧 한도, 로케일 지원 범위를 꼭 확인하세요. 이 영역은 변화가 빠르고, 2026년에 이미 여러 벤더가 변경 사항을 배포했습니다.)
1. SerpApi — 관리형, 기능 풍부, 그리고 캐시 정책이 명확함
SerpApi는 전용 Google Shopping 엔진(engine=google_shopping)을 제공하며, 쿼리를 받아 구조화된 shopping_results를 반환합니다. 여기에는 위치, 제목, 상품 ID, 가격과 추출된 숫자 가격, 기존가/할부가, 배송, 상태, 평점, 리뷰, 이미지가 포함됩니다. 스키마 자체가 상당히 강력합니다. 또 SerpApi는 Google Ads Shopping 스키마를 통해 스폰서 Shopping 결과도 별도로 문서화하므로, 스폰서 노출을 찾을 수는 있습니다. 다만 전용 Shopping 응답 안에 sponsored: true/false 같은 단일 신호로 깔끔하게 들어가 있지는 않습니다.
SerpApi가 돋보이는 이유는 나중에 문제를 일으키기 쉬운 요소들을 아주 명확하게 밝혀둔다는 점입니다. 위치 타겟팅은 도시 단위의 표준 location이나 정확한 uule을 지원하며, 별도로 gl(국가), hl(언어), device(desktop, tablet, mobile) 파라미터도 제공합니다. 그리고 동일한 쿼리는 기본적으로 최대 1시간 동안 캐시를 탈 수 있다고 분명히 적어둡니다. 캐시 적중은 무료이며, no_cache=true를 쓰면 새 결과를 강제로 가져옵니다. 이런 수준의 공개는 대부분의 벤더가 숨기거나 아예 생략하는 내용입니다.
가격(2026-08-13 기준)은 공개 월정액입니다. Free tier는 250 searches, Starter는 1,000건에 $25, Big Data는 30,000건에 $275까지 있습니다. 성공한 검색만 쿼터에 반영되고, 캐시 적중이나 실패 요청은 제외됩니다. 참고할 점은 2026년 초 Google이 SerpApi를 데이터 접근 방식 문제로 소송 제기했다는 것입니다. SerpApi는 그 해석에 이견이 있으며, 공개·비인증 결과에 접근한다고 주장합니다. 아직 법적 판단이 내려진 사안은 아니므로, 아예 피해야 할 이유라기보다 리스크 요인으로 지켜봐야 할 이슈로 보는 편이 맞습니다.
추천 대상: 가장 풍부하게 문서화된 Shopping 스키마와 캐시·로케일 제어를 원하는 개발자.
2. Serper — 빠르고, 저렴하고, 최신성 주장도 가장 깔끔함
Serper는 Shopping을 Search, Images, News, Maps 등 여러 결과 유형 중 하나로 포함한 범용 Google SERP API입니다. 이미 일반 검색 결과를 가져오고 있고 여기에 Shopping 데이터만 추가하면 된다면, 별도의 전용 벤더를 새로 세우는 것보다 훨씬 덜 번거롭습니다.
공개된 Shopping 예시는 제목, 출처, 직접 판매자 링크, 서식이 적용된 가격, 배송, 평점, 평점 수, 오퍼 수, 상품 ID, 위치를 반환합니다. 기본적인 상품 카드 모니터링에는 충분히 괜찮지만, SearchAPI나 Oxylabs가 문서화한 수준의 판매자 오퍼 상세 정보나 프로모션 가격 필드는 공개 문서에서 확인되지 않습니다. Serper의 가장 강한 장점은 최신성 약속입니다. 모든 호출이 Google을 실시간으로 조회하며 캐시를 쓰지 않는다고 밝히기 때문에, SerpApi에서 사용자가 직접 결정해야 하는 캐시 관리 부담이 없습니다. 대신 반복 쿼리도 매번 비용이 든다는 점은 감안해야 합니다.
가격은 구독형이 아니라 선불 크레딧 방식입니다. 시작 시 2,500 무료 쿼리를 제공하고, 그 뒤로는 $50에 50,000 크레딧부터 시작해 상위 구간에서는 1,000건당 $0.30 수준까지 내려갑니다. 크레딧은 6개월간 유효합니다. 가격 페이지에는 또 한 가지 인상적인 솔직함이 있습니다. Google에 재시도해야 할 때 개별 요청은 2~4초가 걸릴 수 있다고 명시합니다. 벤치마크가 아니라, 실제로 계획에 넣어야 할 지연 꼬리입니다.
추천 대상: 더 넓은 SERP API를 이미 통합 중이고, Shopping은 보너스처럼 추가하려는 팀.
3. SearchAPI — 오퍼 단위 상세 정보가 강하지만 문서상 주의점이 있음
SearchAPI는 판매자 수준 가격 비교가 필요할 때 아주 유용한 2단계 워크플로우를 제공합니다. Shopping 엔드포인트는 일반적인 카드 필드와 함께 product_token을 반환하고, 이 토큰으로 별도의 Product Offers API를 호출하면 offers 배열을 받아볼 수 있습니다. 여기에는 판매자 링크, 가격, 배송비, 총액, 재고 상태, 결제 수단이 판매자별로 포함됩니다. “정확히 이 상품이 판매자별로 얼마에 팔리고 있는가?”가 목적이라면, 이 목록에서 가장 직선적인 경로입니다.
다만 주의할 점이 하나 있습니다. 2026년 5월 15일 기준 Google의 변경으로 인해 SearchAPI는 요청마다 새로운 product_token을 요구하게 되었고, 예전의 product_id/prds 파라미터는 이제 단순 400 오류를 반환합니다. 오래된 코드 예제나 튜토리얼을 기반으로 통합하고 있다면, 어느 순간 깨져 있는데도 한참 뒤에야 알게 될 수 있습니다.
SearchAPI는 또 검색어 안에 넣는 자연어 필터(예: “$30 이하”, “중고”)는 엄격한 필터가 아니라 힌트일 뿐이라고 명시합니다. 조건에 맞는 결과가 적으면 Google이 범위를 벗어난 결과를 보여줄 수 있습니다. 엄격한 방식은 인코딩된 shoprs 필터입니다. 게다가 문서상 충돌도 하나 있습니다. SearchAPI는 이 엔드포인트를 “real-time”이라고 홍보하지만, 데이터 처리 계약에는 성능을 위해 결과를 캐시한다고 적혀 있습니다. 어느 쪽이든 공개된 TTL은 없습니다. 가격 변동이 빠른 상황이 중요하다면, 신선도 가정에 의존해 파이프라인을 만들기 전에 반복 조회로 먼저 테스트하는 것이 좋습니다.
가격(2026-08-13 기준)은 Developer tier 월 $40에 1,000건당 $4부터 시작하며, 더 높은 볼륨에서는 단가가 내려갑니다. 문서화된 월간 상한은 월 크레딧의 20%입니다.
추천 대상: 두 번의 요청 워크플로우와 직접 신선도 테스트를 감수할 수 있는, 판매자/오퍼 단위 비교 팀.
4. DataForSEO — 대규모 Merchant 및 Shopping 데이터를 큐 기반으로 처리
DataForSEO는 이 그룹에서 확실히 특이한 편입니다. 실시간 요청/응답 API가 아니라 작업 기반 큐이기 때문입니다. 키워드, 위치, 언어를 넣어 작업을 POST하고, 작업 ID를 받은 뒤 결과를 폴링하거나 콜백 URL을 설정합니다. 핵심 Shopping 엔드포인트는 표준 조회 방식만 지원하며, 일반 마케팅 문구가 암시하는 것과 달리 라이브 모드는 없습니다.
이건 설정 복잡도 계산을 바꿔 놓습니다. 정확히 어렵다고 말하긴 힘들지만, “API 호출 → JSON 반환”과는 다른 사고방식이 필요합니다. 작업 상태를 관리해야 하고, DataForSEO 문서에 따르면 10초 안에 응답하지 않는 콜백 서버는 작업을 "Tasks Ready" 큐로 넘기며, 이후에는 수동 폴링이 필요합니다.
이 도구가 이 목록에 들어올 만한 이유는 대량 리서치입니다. Products 엔드포인트는 rank, domain, title, price, old price, rating, vote count를 반환하며, 결과 유형 식별자로 google_shopping_sponsored_carousel, google_shopping_paid, 유기적 결과를 명확하게 구분합니다. 이 전체 목록에서도 스폰서와 유기적 결과의 구분이 가장 명확한 편 중 하나입니다. 또한 product_id가 동적이며 null일 수 있다고 분명히 경고하고, 사용자 이력이나 위치 선호 같은 개인화 요소는 결과에서 의도적으로 제외된다고 밝혀둡니다. 대부분의 벤더가 생략하는, 꽤 유용한 솔직함입니다.
가격은 결과 블록 단위로 과금됩니다(Product는 40개, Sellers/Reviews는 10개). 일반 큐 속도는 최대 45분, 우선 큐는 두 배 가격으로 최대 1분입니다. 새 계정에는 만료 없는 $1 체험 크레딧이 제공됩니다.
추천 대상: 대량의 판매자/상품 데이터를 정기적으로 다루며, 큐 기반 워크플로우에 익숙한 팀.
5. Bright Data — 하나의 이름표 아래 세 가지 다른 제품
여기서는 잠시 속도를 늦춰야 합니다. Bright Data는 실제로 Google Shopping 데이터를 얻는 세 가지 서로 다른 방식을 제공하는데, 서로 동작 방식이 완전히 다릅니다. 사전 수집 데이터셋(74억 개 이상 레코드로 마케팅되며, JSON/CSV/Parquet 형태로 일정에 맞춰 클라우드 웨어하우스로 전달), Google Scraper API(전용 Shopping scraper ID로 동기/비동기 작업 수행), SERP API(실시간 Shopping URL을 가져와 결과를 파싱)가 있습니다. 이 셋을 하나의 제품처럼 취급하는 비교 글이 많은데, 저는 그렇게 하지 않겠습니다.
데이터셋의 샘플 데이터만 봐도 일부 레코드에서 product ID, description, rating, reviews count가 null입니다. 즉, “구조화된 데이터셋”이 곧 “모든 필드가 항상 채워짐”을 뜻하지는 않는다는 첫 번째 근거가 됩니다. SERP API는 Product Listing Ads를 별도 결과 유형(top_pla, bottom_pla, jackpot_pla)으로 문서화하며, title, price, shop, rank를 제공합니다. 단, 이 구분은 데이터셋이 아니라 SERP API에서 특히 유용합니다.
Scraper API의 비동기 작업은 전체적으로는 “success”를 반환해도 배치 안의 개별 입력은 실패할 수 있습니다. 문서에서는 errors 필드를 확인한 뒤 실패 항목만 개별 재시도하라고 명시합니다. 대량 배치를 운영한다면 꼭 염두에 둬야 할 유지보수 포인트입니다.
가격(2026-08-13 기준)은 표면마다 크게 다릅니다. 데이터셋은 일회성 100,000 레코드에 $250, SERP API는 월 5,000 무료 요청 후 종량제 1,000건당 $1.50, 전용 Shopping Scraper API는 또 별도의 무료 구간과 요율이 표시됩니다. 이 숫자들은 서로 대체 가능한 것이 아닙니다. 실제로 쓰려는 정확한 제품 페이지를 확인해야 합니다.
추천 대상: 준비된 데이터셋과 라이브 API 접근을 모두 아우르는 단일 플랫폼을 원하고, 표면별 가격을 따로 계산할 수 있는 엔터프라이즈 팀.
6. Oxylabs — 검색 + 상품 상세의 2단계 체인이 가장 명확함
Oxylabs는 Shopping을 두 개의 전용 타깃으로 나눕니다. google_shopping_search는 목록 수준 결과를, google_shopping_product는 개별 상품 상세를 담당하며, 둘은 product token으로 연결됩니다. 검색 응답은 pla(유료 리스트 광고)와 organic 제품을 깔끔하게 분리하는데, 이건 아마 이 목록 전체에서 가장 명확한 스폰서/유기적 구분일 겁니다. 상품 엔드포인트는 판매자별 오퍼에 숫자 가격, 상태, 세금, 총액, 배송 정보를 더해 줍니다.
하지만 중요한 조건이 있습니다. 이 토큰 워크플로우는 검색 요청에 render: "html"과 parse: true가 모두 들어가 있어야만 작동합니다. 둘 중 하나라도 빠지면 product token을 얻지 못하고, 상품 상세 단계 전체가 무너집니다. Oxylabs는 검색 요청과 상품 요청이 완전히 동일한 로케일 값을 써야 한다고도 명시합니다. 두 호출의 geo_location이 다르면 상품 결과가 불완전하거나 틀리게 나올 수 있습니다. 그리고 더 많은 판매자 오퍼를 보려면 “More stores” 패널을 펼치기 위해 렌더링을 켜야 하며, 이는 비용을 더 높입니다.
놓치기 쉬운 세부 사항 하나: Oxylabs의 가격 FAQ는 성공한 요청, 즉 과금 대상 요청에 2xx뿐 아니라 4xx 응답도 포함된다고 정의합니다. 요청을 잘못 보냈더라도 과금될 수 있다는 뜻입니다.
상품 리뷰는 미국 로케일 전용으로 문서화되어 있고, locale/language와 locale/results-language는 서로 독립적인 제어값입니다. 하나를 설정한다고 다른 하나가 자동으로 맞춰지지 않습니다.
추천 대상: 랭킹 수준 정보와 판매자별 오퍼 상세를 모두 필요로 하며, 토큰 체인과 로케일 일관성을 설정 일부로 감당할 수 있는 기술 팀.
7. Scrapingdog — 단순한 엔드포인트, 공개 문서는 다소 얇음
Scrapingdog은 API 키와 쿼리만 받는 단일 전용 Google Shopping 엔드포인트를 제공합니다. 반환 JSON에는 제목, 가격과 추출된 숫자 가격, 기존가, 평점, 리뷰, 출처/판매자, 배송, 위치가 들어갑니다. 또한 가격, 브랜드, 국가, 언어 기준 필터링을 지원한다고 설명하며, 스폰서 노출 추적용 별도 "ads" 응답 카테고리도 있습니다. 다만 공개 페이지에는 정확한 ads 스키마와 로케일 필터 파라미터 이름이 충분히 문서화되어 있지 않으므로, 자동화를 본격적으로 짜기 전에 본인 사용 사례로 먼저 테스트할 시간을 확보하는 게 좋습니다.
이 목록에서 공개 문서만으로는 크레딧 비용 계산이 맞아떨어지지 않는 유일한 항목이기도 합니다. Scrapingdog의 가격 페이지는 월 크레딧 할당(LITE는 월 $40에 200,000 크레딧, STANDARD는 월 $90에 1,000,000 크레딧)을 보여주지만, Google Shopping 요청 하나가 실제로 몇 크레딧인지 명확히 밝히지 않습니다. 일반 검색 API 예시와 1:1이라고 가정하지 마세요. 실제 단가를 계산하기 전에 벤더에게 직접 확인해야 합니다.
대부분의 벤더처럼 Scrapingdog도 기본 제공 회전형 residential proxy와 자동 CAPTCHA 처리를 벤더 관리 범위로 홍보합니다. 이는 접근 보장의 증거가 아니라, 유지보수 책임의 경계를 말하는 것으로 이해해야 합니다.
추천 대상: 예산에 민감한 개발자로서 좁고 전용화된 엔드포인트가 필요하고, 사용 전 크레딧 비용을 직접 검증할 의향이 있는 경우.
8. Apify — 마켓플레이스가 아니라 액터를 평가해야 함
솔직히 말해야 할 부분이 있습니다. Apify는 단일 Google Shopping 스크래퍼가 아닙니다. 독립적으로 관리되는 "Actor"들의 마켓플레이스이고, 제가 자세히 본 이 액터(Google Shopping Insights, 개발자 epctex 제작, "Maintained by Community" 표시)는 위의 벤더 운영형 도구들과는 꽤 다르게 동작합니다. Apify는 런타임, 프록시 인프라, 데이터셋/내보내기 도구를 제공합니다. 실제 Shopping 추출 로직과 유지보수는 Apify가 아니라 epctex의 몫입니다.
이 구분이 중요한 이유는, 이 특정 Actor의 공식 예시 출력 자체에 price 필드가 null로 표시되기 때문입니다. “가끔”이 아니라 “품절 상품에서만”도 아닙니다. 문서에 실린 샘플 레코드 자체가 상품명, 판매자, 평점은 채워져 있는데 price: null, withoutDiscountPrice: null을 보여 줍니다. 이 전체 비교에서 가격 데이터가 완전하다고 가정할 수 없다는 가장 강력한 1차 증거이며, 그것도 도구 자체 문서에서 나온 것입니다.
설정 가능한 입력값으로는 includeSponsoredResults, 판매자 간 가격 비교를 위한 includeComparisonPrices, 국가 코드 타겟팅, maxItemsPerQuery가 있고, 필수 프록시 설정도 제공합니다(자체 프록시 또는 Apify 프록시). 결과는 Apify의 Dataset 시스템을 통해 JSON, XML, CSV, Excel로 내보낼 수 있습니다. 제가 확인한 Store 목록에서는 총 사용자 수가 약 2,300명이었지만, 당시 월간 활성 사용자는 2명뿐이었습니다. 커뮤니티 유지보수 방식의 양면성이 드러나는 지점입니다. 유연하긴 하지만, 실제 신뢰성은 누가 적극적으로 쓰고 이슈를 올리느냐에 달려 있습니다.
추천 대상: 특정 Actor의 유지보수 활동과 실제 출력 스키마를 먼저 검토할 수 있는 개발자. Apify라는 브랜드가 일관된 동작을 보장해 주길 기대하는 사람에게는 적합하지 않습니다.
9. Thunderbit — 마케터를 위한 노코드 수집 도구
Thunderbit는 이 목록의 다른 끝을 대표합니다. Google Shopping API를 연동하는 대신, 눈앞에 보이는 페이지를 검토해서 구조화된 표로 바꾸고 싶은 사람들을 위한 브라우저 기반 노코드 워크플로우입니다. 그래서 마케터, PPC 운영자, 임시 점검 위주의 소규모 이커머스 팀에 가장 자연스럽게 맞습니다.
얻을 수 있는 것은 브라우저 측 추출입니다. 필요한 Shopping 결과 페이지를 열고, Thunderbit가 렌더링된 페이지를 한 번에 읽도록 한 뒤, 필드를 Excel, Google Sheets, Airtable, Notion으로 바로 내보냅니다. 다만 주의할 점이 있습니다. 이건 도구 자체의 문제가 아니라 Shopping 데이터의 특성입니다. 추출은 현재 열려 있는 페이지를 대상으로 이루어지므로, 결과는 해당 브라우저의 위치, 언어, 세션을 그대로 이어받습니다. 이번 주 데이터와 지난주 데이터를 비교하려면 먼저 이 설정을 고정해 두세요. 이는 다음 섹션에서 다루는 필드 신뢰성 문제와 동일하며, 이 목록의 모든 옵션에 적용됩니다.
추천 대상: 개발자가 관리하는 JSON 파이프라인보다, 눈으로 확인하고 검토한 브라우저 추출을 선호하는 비기술 팀. 그리고 대규모 멀티 지역 크롤링보다, 필요할 때 특정 Shopping 페이지를 즉시 뽑는 방식에 맞는 팀.
실제로 믿을 수 있는 데이터는 무엇일까? 필드 신뢰성 문제
이 부분은 대부분의 Google Shopping 비교 글이 완전히 건너뛰는 영역이자, 자동화를 시작하기 전에 반드시 이해해야 할 가장 중요한 내용입니다. 모든 필드가 모든 상품에 나타나는 것은 아니며, "누락됨"을 "0"으로 처리하면 데이터가 조용히 망가집니다.
| 필드 | 신뢰도 | 주의할 점 |
|---|---|---|
| 제목 | 높음 | 여러 소스의 상품을 매칭할 때 변형/번들 버전을 먼저 정규화해야 함 |
| 상품 ID | 조건부 | DataForSEO는 이를 동적이며 때때로 null이라고 명시함 |
| 가격 | 조건부 | Apify의 공식 예시에서도 완전히 채워진 레코드에 null 가격이 나타남 |
| 판매자/상점 | 대체로 존재 | 다중 판매자 리스트에서는 한 상품에 여러 오퍼가 존재할 수 있음 |
| 평점/리뷰 수 | 조건부 | 새 상품이나 평가가 없는 상품은 아예 표시되지 않을 수 있으므로 0으로 강제 변환하면 안 됨 |
| 배송/배달 | 일관성 낮음 | 목적지, 판매자 재고, 세션에 따라 달라질 수 있음 |
| 스폰서 플래그 | 도구 의존적 | Oxylabs는 pla와 organic를 명확히 구분하지만, 다른 도구들은 행별 신뢰 가능한 라벨 없이 스폰서 결과 포함/제외만 제공하기도 함 |
실무 규칙은 간단합니다. 어떤 워크플로우를 자동화하든, 먼저 실제 키워드로 샘플을 받아서 무엇이 null인지, 중복인지, 빠졌는지 확인하세요. 문서가 “있어야 한다”고 암시하는 내용이 아니라, 실제로 무엇이 들어오는지가 중요합니다.
공식 Google Merchant Center vs. Google Shopping 스크래퍼: 무엇이 필요할까?
이 질문은 이커머스 팀이 벤더를 비교하기도 전에 가장 먼저 묻는 내용이고, 분명하게 답할 가치가 있습니다. 자신의 상품 등록, 가격, Shopping 광고를 관리하는 것이 목적이라면, 그건 서드파티 스크래퍼가 아니라 Google의 공식 Merchant Center 도구를 써야 하는 일입니다. 이 목록의 스크래핑 도구들은 다른 사람의 리스트를 관찰하는 데 쓰입니다. 경쟁사 가격, 시장 가시성, 카테고리 리서치, 스폰서 노출 모니터링이 여기에 해당합니다. 둘을 혼동하지 마세요. Google의 첫 번째 당사자 API의 현재 이름과 범위는 수시로 바뀌고 재구성되므로, 최신 공식 문서를 직접 확인하는 것이 좋습니다.
이 도구들은 Google의 안티봇 방어를 어떻게 다루나
이건 “Google을 어떻게 이길까”가 아니라 거버넌스의 문제로 봐야 합니다. 그게 가장 정직한 관점이기 때문입니다. 여기 있는 여러 벤더 — SerpApi, SearchAPI, Bright Data, Oxylabs, Scrapingdog — 는 프록시 로테이션, 브라우저 렌더링, CAPTCHA 처리를 자사에서 관리한다고 공개적으로 밝힙니다. 이건 분명 중요한 유지보수 경계입니다. 새벽 2시에 차단된 IP를 붙잡고 디버깅하는 사람이 바로 당신이 아니라는 뜻이니까요. 하지만 이것은 영구적이거나 보편적인 접근을 보장한다는 뜻으로 읽어서는 안 됩니다.
완전 관리형 벤더를 써도 사라지지 않는 것들: 속도 및 비용 제어, 오류 분류, 재시도, 그리고 Google이 무엇인가를 바꿨는지 감시하는 모니터링입니다. 제가 SearchAPI와 Oxylabs의 변경 로그에서 확인한 바로는 이런 변화는 꽤 정기적으로 일어납니다. Bright Data는 부분 배치 실패를 명시적으로 문서화하고, DataForSEO는 콜백 타임아웃 동작을 설명하며, Oxylabs는 잘못된 토큰 실패를 문서화합니다. 여기에는 어떤 우회법도 없습니다. 단지 어떤 실패 모드를 누가 책임지는지에 대한 정직한 분담표일 뿐입니다.
팀에 맞는 최고의 Google Shopping 스크래퍼 고르는 법
아래 순서대로 검토하세요.
- 자신의 페르소나를 먼저 정하세요. 개발자로서 파이프라인을 만드는가, 아니면 코드를 건드리지 않고 결과만 원하는 마케터/운영 담당자인가?
- 실제로 필요한 필드를 정의하세요. 랭킹 수준 데이터와 판매자/오퍼 수준 가격 상세는 다릅니다. 후자에서는 SearchAPI와 Oxylabs가 특히 강점을 보입니다.
- 유지보수 역량을 솔직하게 보세요. API 매핑과 오류 처리, Actor 설정과 프록시 구성, 또는 검토 가능한 페이지 기반 추출 중에서 팀이 장기적으로 책임질 수 있는 것을 고르세요.
- 실제 쿼리로 로케일/디바이스 동작을 테스트하세요. 공개 문서가 실제 동작과 완벽히 일치하지 않는 경우가 있기 때문입니다.
- 내보내기 경로가 현재 스택에 맞는지 검증하세요. 데이터 웨어하우스로 JSON을 넣는 일과, 마케터가 바로 열어볼 수 있는 스프레드시트를 만드는 일은 전혀 다른 수준의 작업입니다.
결론: 어떤 Google Shopping 스크래퍼를 써야 할까?
여기에는 단 하나의 "최고"가 없습니다. 이 글이 그렇지 않다고 말한다면, 의심해도 됩니다. 데이터 파이프라인을 만드는 개발자이고, 캐시와 로케일 제어가 명확한 가장 풍부한 문서화 스키마를 원한다면 SerpApi부터 시작하세요. 판매자별 오퍼 단위 가격 비교가 진짜 목표라면 SearchAPI나 Oxylabs의 토큰 체인 워크플로우가 더 직접적입니다. 대량의 정기 리서치를 수행하고 큐 기반 모델을 감수할 수 있다면 DataForSEO가 잘 맞습니다. 준비된 데이터셋과 라이브 쿼리를 모두 아우르는 하나의 엔터프라이즈 플랫폼을 원한다면 Bright Data가 가장 넓은 범위를 커버합니다. 다만 표면별 가격은 따로 계산해야 합니다.
그리고 PPC나 마케팅 팀처럼 API 키를 직접 다루고 싶지 않다면, Thunderbit로 대표되는 브라우저 기반 카테고리가 “코딩 프로젝트 말고, 그냥 데이터만 필요하다”는 요구에 가장 직접적인 답입니다. 다만 어떤 방식의 표면을 선택하는지 분명히 하세요. 브라우저 워크플로우는 직접 열어 보고 검토하는 페이지를 위해 설계된 것이고, Thunderbit의 API 문서와 CLI는 별도의 개발자 지향 경로입니다. 팀의 실제 작업 방식과 맞는 쪽을 고르세요.
어떤 도구를 고르든, 먼저 실샘플을 받아보세요. 이 목록의 모든 벤더는 항상 존재하지는 않는 필드를 하나 이상 문서화하고 있습니다. 무언가를 만들기 전에 반드시 확인해야 합니다.
자주 묻는 질문
Google Shopping 데이터를 스크래핑하는 것은 합법인가요? 이 질문에 대해 단정적으로 답할 수는 없고, 어떤 비교 글도 그래서는 안 됩니다. 공개적으로 보이는 데이터와 벤더의 준수 주장만으로 모든 사용 사례가 자동으로 합법이 되지는 않습니다. 무엇을 만들기 전에 Google의 최신 서비스 약관을 확인하고, 관할 지역의 관련 법률을 검토하고, 수집 방식이 허용되는지 확인하세요. 이건 블로그 글이 결론낼 수 있는 문제가 아니라, "자문을 받아 확인해야 하는 사안"으로 보아야 합니다.
SERP API와 Google Shopping 스크래퍼의 차이는 무엇인가요? SERP 또는 Shopping API는 구조화된 요청 파라미터를 받아 파싱된 JSON을 반환합니다. 벤더가 대부분의 수집 인프라를 처리합니다. 브라우저 기반 스크래퍼(예: Thunderbit)는 실제로 사용자 또는 본인이 열어 둔 페이지에서 데이터를 추출합니다. 데이터셋 제품(Bright Data의 일부 제품처럼)은 실시간 요청이 아니라, 사전 수집된 레코드를 일정에 맞춰 제공합니다. 목적은 비슷하지만, 최신성, 로케일 제어, 그리고 실제로 얼마나 많이 직접 유지보수해야 하는지는 꽤 다릅니다.
Google Shopping을 스크래핑하려면 코딩 능력이 꼭 필요한가요? 항상 그런 것은 아닙니다. Thunderbit의 핵심 가치는 바로 이 점에 있습니다. 클릭 기반 노코드 워크플로우니까요. Apify도 웹 UI만으로는 코드를 쓰지 않고 사용할 수 있지만, 진짜 커스터마이징을 하려면 어느 정도 기술적 이해가 도움이 됩니다. 이 목록의 API 기반 도구 — SerpApi, Serper, SearchAPI, DataForSEO, Bright Data, Oxylabs, Scrapingdog — 는 최소한 기본적인 개발 역량, 즉 인증, 파라미터 처리, 오류 확인이 필요합니다.
Google Shopping 데이터는 얼마나 자주 바뀌나요? 많은 사람들이 생각하는 것보다 자주 바뀌지만, “몇 시간마다 갱신된다” 같은 보편적 규칙은 없습니다. 가격, 재고, 스폰서 노출, 순위는 세션, 로케일, 시간대에 따라 달라질 수 있습니다. 이 분야에서는 캐시된 데이터가 금방 낡기 때문에, 여러 벤더가 live/real-time 모드를 제공하는 것입니다. 의사결정이 현재 가격에 달려 있다면, 어제의 결과를 믿지 말고 쿼리를 다시 실행하세요.
더 알아보기
