몇 달 전 Stack Overflow의 한 개발자가 2012년부터 아직도 열려 있는 질문을 올렸습니다. "Google Places API Place Details limited to 5 reviews?" 14년이 지난 지금도, 추천 수는 수백 개가 쌓였는데 답은 여전히 같습니다. 맞습니다, 리뷰는 최대 5개입니다. 이 한 가지 제한만 봐도 왜 이 논쟁이 계속되는지 바로 감이 옵니다.
Google Places 데이터를 대규모로 다뤄본 적이 있다면 — 리드 리스트, 경쟁사 리뷰, 유동 인구 패턴, 로컬 SEO 감사 같은 작업 말이죠 — 아마 같은 갈림길에 선 적이 있을 겁니다. 공식 Google Places API는 깔끔하고 구조화되어 있으며 문서도 잘 정리되어 있습니다. 하지만 Google Maps 페이지에서 눈으로 볼 수 있는 모든 내용을 다 돌려주지는 않고, 무료 구간을 넘어서면 비용도 금방 커질 수 있습니다. 반면 스크래핑은 더 많은 데이터를 가져올 수 있고, 비용 구조도 다르지만 CAPTCHAs, 깨지는 셀렉터, 법적 회색지대 같은 골칫거리도 따라옵니다. 저는 API 문서, 가격 체계, 스크래핑 도구, 실제 운영에서의 트레이드오프까지 꽤 오래 파고들었고, 이 글은 그 결과물입니다. 필드별 데이터 차이, 1만/10만/100만 레코드 기준의 실제 비용, 안티봇 현실, 그리고 실무형 하이브리드 전략까지 다룹니다. 마지막에는 결정 플로차트도 넣었습니다. 3,000자를 읽고도 결국 뭘 골라야 할지 모르겠는 일은 없어야 하니까요.
Google Places API란 무엇이며, 실제로 무엇을 제공할까?
Google Places API는 Google이 공식적으로 제공하는 구조화된 방식으로 비즈니스 데이터를 가져오는 방법입니다. 이름, 주소, 전화번호, 평점, 리뷰, 사진 같은 정보를 데이터베이스에서 꺼내 HTTP 요청으로 보내면, 정리된 JSON 형태로 응답을 받습니다. 승인된 경로라고 보면 됩니다.
현재 버전인 Places API “New”는 모든 것을 필드 마스크(field masks) 중심으로 구성합니다. Place Details를 호출할 때 displayName, formattedAddress, rating, reviews, photos 등 원하는 필드를 정확히 지정해야 하며, Google은 요청한 필드 중 가장 높은 요금 등급을 기준으로 과금합니다. 필드 마스크를 빼먹으면 기본 응답이 아니라 에러가 납니다. 이건 의도된 설계입니다. Google은 사용한 만큼만 내게 하되, 더 유용한 데이터일수록 더 많은 비용을 받으려는 것이죠.
이용 가능한 필드는 요금 등급별로 나뉩니다:
| 등급 | 예시 필드 | 제공되는 정보 |
|---|---|---|
| Essentials | Place ID, 형식화된 주소, 위치, 사진 메타데이터 | 기본 식별 정보와 위치 정보 |
| Pro | 표시 이름, 영업 상태, Google Maps URI, 기본 유형 | 더 풍부한 비즈니스 정보 |
| Enterprise | 평점, 사용자 평점 수, 웹사이트, 전화번호, 영업시간, 가격대 | 실제 비즈니스 사용자들이 가장 많이 원하는 항목 |
| Enterprise + Atmosphere | 리뷰, 리뷰 요약, 생성형 요약, 편의시설, 주차, 포장/배달 | 가장 풍부하지만 가장 비싼 데이터 |
대부분의 사용자가 가장 많이 쓰는 핵심 엔드포인트는 Autocomplete(검색어 자동완성), Text Search와 Nearby Search(장소 탐색), Place Details(기존 장소 정보 보강), Place Photos(이미지 조회)입니다.
하지만 중요한 제한도 있습니다:
- 리뷰: Place 리소스는 장소당 최대 5개 리뷰만 반환합니다. 더도 말고 덜도 말고 5개입니다.
- 사진: Place 리소스에서 장소당 사진 참조 10개로 제한됩니다.
- 인기 시간대 / 실시간 혼잡도: 표준 Places API 필드로는 제공되지 않습니다. Google은 이 데이터가 존재한다는 점은 확인했지만(집계·익명화된 Location History 기반), Maps 블로그에서 동작 방식을 설명하면서도, 필드 목록에는 넣지 않았습니다.
- Q&A 섹션: 노출되지 않습니다.
- "사람들이 함께 검색한 항목" 경쟁사 정보: 노출되지 않습니다.
- 메뉴 / 가격표: 표준 필드가 아닙니다.
보통 누가 Google Places API를 사용할까?
- 물류 회사: 주소 검증 및 지오코딩
- 여행/숙박 앱: 주변 호텔, 음식점, 관광지 표시
- 부동산 플랫폼: 매물 정보에 지역 비즈니스 데이터 추가
- 로컬 SEO 대행사: NAP(이름, 주소, 전화번호) 일관성 점검
- 영업팀: Place ID와 기본 비즈니스 정보로 리드 리스트 구축
유스케이스가 “구조화된 장소 데이터를 프로덕션 앱에 넣고 싶다”에 가깝다면 API가 출발점으로 맞습니다. 반대로 “모든 리뷰”, “인기 시간대”, “경쟁사 분석” 같은 말이 들어간다면 계속 읽어보세요.
Google Places 데이터 스크래핑이란 무엇일까?
웹 스크래핑은 공식 API 대신 소프트웨어로 웹페이지에서 데이터를 자동 추출하는 방식입니다. 여기서는 Google Maps나 Google Search 결과 페이지를 대상으로 합니다. 스크래퍼는 브라우저처럼 페이지를 읽고, 비즈니스 이름, 주소, 리뷰 텍스트, 별점, 인기 시간대 히스토그램, Q&A, 경쟁사 추천, 전체 사진 갤러리 등 화면에 렌더링된 구조화된 정보를 뽑아냅니다.
핵심 차이는 이겁니다. API는 Google이 공개하기로 정한 정보만 줍니다. 스크래핑은 이론상 사람이 화면에서 볼 수 있는 거의 모든 것을 가져올 수 있습니다.
다만 "스크래핑"은 하나의 방식이 아닙니다. 크게 세 가지 접근이 있고, 각 방식의 장단점 차이도 큽니다.
직접 구현 스크립트 vs 관리형 스크래핑 API vs 노코드 도구
| 접근 방식 | 동작 방식 | 적합한 경우 | 핵심 단점 |
|---|---|---|---|
| 직접 구현 스크립트 (Puppeteer, Playwright, Selenium) | 헤드리스 브라우저 스크립트를 직접 작성·유지보수하면서 Google Maps 페이지를 탐색하고 DOM을 파싱 | 완전한 제어와 커스텀 로직이 필요한 개발자 | 유지보수 부담이 가장 큼 — Google이 UI를 바꾸면 셀렉터가 깨짐 |
| 관리형 스크래핑 API (Thunderbit API, SerpApi, Outscraper) | URL이나 쿼리를 API에 보내면 렌더링, 안티봇 대응, 파싱까지 처리해 구조화된 데이터를 반환 | 스크래퍼를 직접 관리하지 않고도 구조화된 결과가 필요한 개발자 | 벤더별 가격과 품질 차이가 크며, 제3자에 의존해야 함 |
| 노코드 브라우저 확장 프로그램 (Thunderbit Chrome Extension) | 브라우저에서 클릭 몇 번으로 추출 — AI가 필드를 추천하고, 사용자는 "Scrape"를 누른 뒤 Sheets/Excel로 내보냄 | 스프레드시트용 데이터를 빠르게 뽑아야 하는 비개발자, 마케터, 영업팀 | 복잡한 파이프라인에는 유연성이 떨어지고, 도구의 AI 품질에 좌우됨 |
짧게 정리하면 이렇습니다. DIY는 가장 유연하지만 유지보수 부담이 가장 큽니다. 관리형 API는 구조화된 결과를 주지만 유지보수는 필요 없습니다. 노코드 도구는 비개발자에게 가장 빠릅니다.
Google Places API와 스크래핑 비교: 필드별 데이터 차이
제가 이 주제를 조사하면서 가장 먼저 찾고 싶었던 표입니다. 비즈니스 사용자나 개발자가 필요로 할 수 있는 모든 필드를 나란히 비교했습니다:
| 데이터 필드 | Google Places API | 웹 스크래핑 |
|---|---|---|
| 비즈니스 이름 | ✅ 전체 제공 (Pro 등급) | ✅ 전체 제공 |
| 주소 / 위치 | ✅ 전체 제공 (Essentials 등급) | ✅ 전체 제공 |
| 전화번호 | ✅ Enterprise 등급 | ✅ 표시되는 경우 |
| 웹사이트 URL | ✅ Enterprise 등급 | ✅ 표시되는 경우 |
| 종합 평점 | ✅ Enterprise 등급 | ✅ 전체 제공 |
| 사용자 평점 수 | ✅ Enterprise 등급 | ✅ 전체 제공 |
| 개별 리뷰(텍스트 + 평점) | ⚠️ 최대 5개 리뷰 | ✅ 노출된 모든 리뷰 |
| 인기 시간대 / 실시간 혼잡도 | ❌ 표준 API 필드 아님 | ✅ 렌더링되면 추출 가능 |
| Q&A 섹션 | ❌ 노출되지 않음 | ✅ 추출 가능 |
| 사진 메타데이터 | ✅ Photos 엔드포인트를 통해 최대 10개 참조 | ✅ 전체 갤러리 |
| 메뉴 / 가격표 | ❌ 표준 필드 아님 | ⚠️ 페이지에 존재할 경우 |
| "사람들이 함께 검색한 항목"(경쟁사) | ❌ 노출되지 않음 | ✅ 추출 가능 |
| 영업시간 | ✅ Enterprise 등급 | ✅ 표시되는 경우 |
| 가격대 | ✅ Enterprise 등급 | ✅ 표시되는 경우 |
| Place ID | ✅ 매우 강력함 (Essentials) | ⚠️ 가능하지만, API가 정식 기준 소스 |
| Google Maps URI | ✅ Pro 등급 | ✅ 페이지 URL 자체 |
| 리뷰에 대한 업주 답변 | ⚠️ 현재 제공 여부 확인 필요 | ✅ 자주 표시됨 |
| SERP / 지도 팩 순위 | ❌ API의 목적 아님 | ✅ SERP 스크래핑으로 가능 |
가장 큰 차이는 이것입니다. 감성 분석, 평판 모니터링, 경쟁 벤치마킹을 위해 전체 리뷰 세트가 필요하다면 API만으로는 부족합니다. 장소당 5개 리뷰는 데이터셋이 아니라 샘플에 불과합니다.
인기 시간대와 유동 인구 패턴도 마찬가지입니다. 리테일 컨설턴트나 상업용 부동산 분석가라면 스크래핑이 사실상 유일한 방법입니다. 그 데이터는 API에 없으니까요.
반대로 정식 Place ID, 지오코딩용 구조화 주소, 매장 찾기(store locator) 기능이 필요하다면 API가 더 깔끔하고, 안정적이며, 공식 지원도 받습니다.
진짜 비용: 1만, 10만, 100만 레코드 기준 Google Places API vs 스크래핑
이 결정에서 가장 오해가 많은 부분이 비용입니다. 많은 사용자가 API의 무료 구간으로 프로토타입을 만들고, 규모를 키운 뒤 청구서를 보고 놀랍니다. 스크래핑 쪽에서는 프록시 비용과 개발자 시간을 과소평가하는 경우가 많고요.
그럼 숫자로 보겠습니다.
Google Places API 요금 구조
Google은 2025년 3월 Maps Platform 요금을 개편해, 기존의 월 $200 크레딧 방식 대신 SKU별 무료 사용 한도와 사용량 기반 단계제를 도입했습니다. 현재 요금은 다음과 같습니다.
- Essentials 필드(Place Details): 월 10,000회 무료 요청, 이후 100K까지 1,000회당 $5.00
- Pro 필드(Place Details): 5,000회 무료, 이후 1K당 $7.00
- Enterprise 필드(Place Details): 1,000회 무료, 이후 1K당 $20.00
- Enterprise + Atmosphere(리뷰, 편의시설): 1,000회 무료, 이후 1K당 $25.00
중요한 점은, 필드 마스크에 reviews 같은 Enterprise + Atmosphere 필드가 하나라도 들어가면 요청 전체가 그 등급으로 과금된다는 것입니다. 또 일반적인 워크플로는 여러 SKU를 연달아 사용합니다. 예를 들어 Text Search Pro로 장소를 찾고, 이어서 Place Details Enterprise + Atmosphere로 보강하는 식입니다. 그래서 비용이 누적됩니다.
즉, 하나의 “조회”가 보통 하나의 청구 단위로 끝나는 게 아닙니다.
스크래핑 비용: 도구, 프록시, 개발자 시간
스크래핑 비용은 보통 세 가지로 나뉩니다.
- 도구 구독 또는 API 크레딧: 관리형 스크래핑 API는 요청당, 크레딧당, 또는 레코드당 요금을 받습니다. SerpApi는 검색 단위 과금입니다. Outscraper는 레코드당 종량제입니다. Thunderbit API는 크레딧 시스템을 사용하며, Extract는 요청당 20크레딧이 듭니다. Thunderbit Chrome Extension은 결과 행 1개당 1크레딧입니다.
- 프록시 비용(DIY에만 해당): Google Maps 스크래핑용 residential proxy는 보통 사용량과 공급자에 따라 월 $50~$300 정도입니다.
- 개발자 시간(DIY에만 해당): Puppeteer/Playwright 스크립트를 만들고 유지보수하는 데 드는 시간입니다. 이게 DIY 경제성을 무너뜨리는 숨은 비용입니다(아래에서 더 설명합니다).
규모별 API vs 스크래핑 비용 비교표
| 규모 | Google Places API (Enterprise + Atmosphere) | 관리형 스크래핑 API(추정) | DIY 스크래핑(프록시 + 개발 시간) |
|---|---|---|---|
| 월 1만 레코드 | 약 $225 (1천 무료, 9천 × $25/1K) | 공급자에 따라 약 $50~$150 | 프록시 약 $50 + 월 2~4시간 개발 |
| 월 10만 레코드 | 약 $2,475 (무료 한도 이후 단계 요금 적용) | 약 $250~$500 | 프록시 약 $150 + 월 8~16시간 개발 |
| 월 100만 레코드 | 약 $17,975 (대량 구간 할인으로 단가 감소하지만 총액은 여전히 큼) | 약 $1,500~$3,000 | 프록시 약 $300 + 월 20시간 이상 개발 + 장애 위험 |
참고: API 추정치는 공개된 단계 요금을 기준으로 하며, Place Details Enterprise + Atmosphere에 대해 1천 무료 한도 이후 적용한 값입니다. 관리형 스크래핑 API 추정치는 공급자별 대략적인 범위입니다. DIY 개발 시간은 총 인건비 기준 시간당 $50~$100을 가정했습니다.
패턴은 분명합니다. 취미 수준(1만 건 이하)에서는 API의 무료 한도 덕분에, 특히 Essentials나 Pro 필드만 필요하다면 가장 저렴할 수 있습니다. 하지만 비즈니스 규모(10만 건 이상)로 가면, 특히 풍부한 필드가 필요할수록 API 비용이 급격히 올라갑니다. 엔터프라이즈 규모(100만 건 이상)에서는 API가 월 수만 달러까지 치솟을 수 있고, API가 제공하지 않는 추가 필드가 꼭 필요한 경우라면 스크래핑이나 데이터셋 서비스가 경제적으로 더 매력적입니다.
만약 주소와 Place ID만 필요하다면 스크래핑하지 마세요. 그 용도라면 API가 더 저렴하고 더 좋습니다. 스크래핑의 비용 논리는 API가 줄 수 없는 데이터를 필요로 할 때만 성립합니다.
안티봇 현실 점검: DIY Google 스크래퍼가 깨지는 이유
스크래핑을 옹호하는 사람들이 잘 생략하는 부분이 바로 이것입니다. Google은 사람들이 Google Maps를 스크래핑하는 것을 원하지 않습니다. 그래서 여러 방어층을 쌓아두고, 계속 업데이트합니다.
Google의 다층 방어
- reCAPTCHA 챌린지: 자동화 브라우저는 일반 사용자보다 CAPTCHA를 훨씬 자주 만납니다
- 클라이언트 측 JavaScript 렌더링: Google Maps는 무거운 JavaScript 앱입니다. 단순 HTTP 요청만으로는 렌더링된 내용을 얻을 수 없고, 전체 헤드리스 브라우저가 필요합니다
- 브라우저 핑거프린팅: Google은 canvas fingerprint, WebGL, navigator 속성 등 여러 신호로 헤드리스 브라우저를 탐지합니다
- IP 속도 제한: 같은 IP나 같은 프록시 대역에서 요청이 너무 많으면 차단됩니다
- DOM 구조 변경: Google은 페이지 구조를 자주 바꿉니다. Reddit과 GitHub 이슈 전반의 공통된 경험은 셀렉터가 몇 주에서 몇 달마다 깨진다는 것입니다
마지막 항목이 조용한 킬러입니다. 6월에 완벽하게 작동하던 Puppeteer 스크립트가 7월에는 결과가 비어 있을 수 있습니다. Google이 CSS 클래스를 바꾸거나 div 구조를 재배치했기 때문이죠.
DIY 스크립트 유지보수의 숨은 비용
Google이 DOM을 바꿀 때마다 팀 누군가는 아래 작업을 해야 합니다.
- 스크래퍼가 깨졌다는 사실을 인지하기
- 새 페이지 구조를 분석하기
- 셀렉터 수정, 새로운 CAPTCHA 대응, 재시도 로직 조정하기
- 테스트하고 재배포하기
1년만 지나도 이 유지보수 시간은 관리형 스크래핑 API 구독료를 쉽게 넘을 수 있습니다. 저는 Google Maps 스크래퍼를 유지하려고 연간 개발자 시간 40시간 이상을 쓰는 팀을 본 적이 있습니다. 중간 정도 복잡도의 환경 기준으로도 꽤 보수적인 추정치입니다.
관리형 스크래핑 API가 존재하는 이유
바로 이런 유지보수 부담 때문에 Thunderbit API, SerpApi, Outscraper 같은 서비스가 존재합니다. 이들은 JS 렌더링, CAPTCHA 해결, 프록시 로테이션, 셀렉터 유지보수 같은 안티봇 복잡성을 대신 떠안고, 구조화된 데이터를 돌려줍니다.
Thunderbit의 POST /extract 엔드포인트는 renderMode: "full" 옵션으로 Google Maps 같은 JavaScript 중심 페이지를 처리하고, 아직 파싱이 필요한 원시 HTML이 아니라 스키마에 맞는 구조화된 JSON을 반환합니다. MCP 서버는 이를 AI 에이전트까지 확장해 Claude, Cursor, 기타 LLM 기반 워크플로가 작업 중에 Google Maps 데이터를 환경을 벗어나지 않고도 스크래핑할 수 있게 해줍니다.
비기술 사용자라면 Thunderbit Chrome Extension이 유지보수 제로 옵션입니다. Google Maps 페이지를 열고, "AI Suggest Fields"를 클릭한 뒤, "Scrape"를 누르고 Sheets로 내보내면 끝입니다. 셀렉터도 없고, 프록시도 없고, 디버깅도 없습니다.
SerpApi와 Outscraper도 가격 구조와 출력 형식이 다른 훌륭한 대안입니다. SerpApi는 검색마다 구조화된 JSON을 반환하고, Outscraper는 레코드당 종량제를 씁니다. 적절한 선택은 데이터량, 예산, 그리고 구조화된 JSON이 필요한지 혹은 반구조화된 출력을 직접 파싱해도 되는지에 달려 있습니다.
하이브리드 전략: Google Places API와 스크래핑을 함께 쓰는 방법
이 주제의 상위권 글들 중 실제로 가장 잘 작동하는 방식을 제안하는 곳은 많지 않습니다. 바로 둘 다 쓰는 방법입니다. 많은 팀은 공식 API로 일부 작업을 처리하고, 다른 작업은 스크래핑에 맡깁니다. 핵심은 도구마다 역할을 정확히 나누는 것입니다.
공식 API가 더 유리한 경우
- 실서비스 앱의 자동완성: 낮은 지연시간, 약관 준수, 신뢰할 수 있는 SLA. 비교할 필요도 없습니다.
- 위치 기반 앱 백엔드: 매장 찾기, 주소 검증, Place ID 매칭. API는 구조화되어 있고, 지원되며, 문서도 잘 되어 있습니다.
- 준법이 중요한 통합: 엔터프라이즈 계약, 대외 공개 제품, 혹은 Google ToS 준수가 절대적인 상황
스크래핑이 더 유리한 경우
- 전체 리뷰 추출(장소당 5천 개 이상): 감성 분석, 평판 모니터링, 경쟁 벤치마킹. API의 5개 리뷰 제한으로는 사실상 불가능합니다.
- 한 번성 리드 리스트 추출: 지속 과금이 없는 배치 작업이라면 더 저렴합니다. Thunderbit 같은 노코드 도구를 쓰면 수분 안에 비즈니스 목록을 스프레드시트로 내보낼 수 있습니다.
- 인기 시간대 / 유동 인구 분석: API로는 제공되지 않습니다. 끝입니다.
- Q&A 데이터, 경쟁사 "사람들이 함께 검색한 항목": 페이지에는 보이지만 API에는 없습니다.
하이브리드가 특히 잘 맞는 경우
- 지속적인 가격/평점 모니터링: 기본 구조 데이터(Place ID, 주소, 종합 평점)는 API로 가져오고, 전체 리뷰나 인기 시간대 같은 깊은 정보는 스크래핑으로 보완합니다.
- 보강(enrichment) 워크플로: API로 Place ID와 정식 비즈니스 정보를 얻은 뒤, 각 개별 목록 페이지를 스크래핑해 전체 리뷰, Q&A, 경쟁사 맥락을 수집합니다.
- 정기 모니터링: Thunderbit의 예약 스크래퍼(노코드 사용자용)나 CLI 배치 추출(개발자용)로 커스텀 인프라 없이 반복 작업을 처리할 수 있습니다.
유스케이스별 의사결정 매트릭스
| 유스케이스 | 추천 방식 | 이유 |
|---|---|---|
| 실시간 앱의 자동완성 | ✅ 공식 API | 낮은 지연시간, 약관 준수, 안정성 |
| 전체 리뷰 5천 개 이상 수집 | ✅ 스크래핑 / 스크래핑 API | API는 장소당 5개 리뷰로 제한됨 |
| 한 번성 지역 비즈니스 리드 리스트 | ✅ 스크래핑(또는 Thunderbit 확장 프로그램) | 배치 작업에 더 저렴, 지속 과금 없음 |
| 인기 시간대 / 유동 인구 분석 | ✅ 스크래핑만 가능 | API로는 제공되지 않음 |
| 지속적인 가격/평점 모니터링 | ⚠️ 하이브리드 | 기본 데이터는 API, 심층 데이터는 스크래핑 |
| 위치 기반 앱 백엔드 | ✅ 공식 API | 구조화, 지원, SLA |
| 로컬 SEO SERP 순위 추적 | ✅ 스크래핑 / SERP API | Places API의 목적이 아님 |
| 경쟁사 "사람들이 함께 검색한 항목" | ✅ 스크래핑만 가능 | API에 노출되지 않음 |
결정 플로차트: Google Places API vs 스크래핑, 무엇을 선택할까?
애매한 “경우에 따라 다르다”가 아니라, 좀 더 구체적인 결정 프레임워크를 드리겠습니다. 아래 네 가지 질문을 순서대로 보세요.
1. 프로덕션 앱에서 실시간 데이터가 필요한가? → 예: 공식 API를 쓰세요. 지원이 있고, SLA가 있으며, 약관도 준수합니다. 여기서 끝입니다. → 아니오: 다음 질문으로.
2. API가 돌려주지 않는 데이터(전체 리뷰, 인기 시간대, Q&A)가 필요한가? → 예: 스크래핑이 필요합니다. API는 애초에 이 데이터를 줄 수 없습니다. → 아니오: 다음 질문으로.
3. 월 레코드 수가 얼마나 되는가? → 1만 건 미만: 특히 Essentials나 Pro 필드만 필요하다면 API가 아마 가장 저렴합니다. 이 규모에서는 무료 한도가 큰 도움이 됩니다. → 1만 건 초과: 특히 풍부한 필드가 필요하다면 스크래핑이나 관리형 스크래핑 API가 더 경제적일 가능성이 큽니다.
4. 스크래퍼를 직접 만들고 유지보수할 개발 리소스가 있는가? → 예: Puppeteer/Playwright로 직접 구축하면 통제력은 가장 높습니다(다만 유지보수 예산은 반드시 잡아야 합니다). → 아니오: 관리형 스크래핑 API(Thunderbit API, SerpApi, Outscraper) 또는 노코드 도구(Thunderbit Chrome Extension)를 사용하세요.
개발자 관점 대안 비교
| 도구 | 가격 모델 | 출력 형식 | 안티봇 대응 | 배치 지원 |
|---|---|---|---|---|
| Thunderbit API / MCP | 크레딧 기반(Extract = 요청당 20크레딧) | 스키마 일치 구조화 JSON | ✅ JS 렌더링, 프록시 로테이션, 지역 라우팅 | ✅ 배치당 최대 100개 URL |
| SerpApi | 검색당 과금(단계형 플랜) | 구조화 JSON | ✅ | ✅ API 파라미터로 가능 |
| Outscraper | 레코드당 과금(종량제) | JSON / CSV | ✅ | ✅ 작업 큐로 가능 |
| DIY (Puppeteer/Playwright) | 프록시 + 개발 시간 | 원시 HTML(직접 파싱 필요) | ❌ 직접 처리해야 함 | ✅ 직접 만든 만큼 |
Thunderbit API의 차별점은 사용자가 정의한 JSON Schema를 기준으로 스키마에 맞는 구조화 JSON을 돌려준다는 점입니다. 파싱이 필요한 원시 HTML이나 Markdown이 아닙니다. LLM 파이프라인에 넣거나 데이터베이스에 적재한다면 후처리 시간을 크게 줄일 수 있습니다.
Thunderbit이 어디에 들어맞는가 (비즈니스 사용자와 개발자 모두를 위해)
우리는 Thunderbit을 “Google Maps 데이터가 필요하다”와 “스크래핑 인프라 엔지니어가 되고 싶지는 않다” 사이의 간극을 메우기 위해 만들었습니다. 두 사용자층에서 각각 어떻게 작동하는지 보겠습니다.
비기술 사용자를 위한 Chrome Extension
- Google Maps 페이지를 엽니다 — 검색 결과 페이지나 개별 비즈니스 목록 페이지 모두 가능
- "AI Suggest Fields"를 클릭합니다 — Thunderbit의 AI가 페이지를 읽고 컬럼을 추천합니다(비즈니스 이름, 주소, 평점, 리뷰, 전화번호 등)
- "Scrape"를 클릭합니다 — 확장 프로그램이 데이터를 구조화된 표로 추출합니다. 클라우드 모드를 사용하면 최대 50페이지까지 동시 처리할 수 있습니다
- 하위 페이지를 스크래핑합니다 — 각 목록 페이지를 방문해 상세 정보를 더 가져오려면 "Scrape Subpages"를 누르세요
- 내보냅니다 — Excel, Google Sheets, Airtable, Notion으로 export 가능. 데이터 내보내기는 무료이며, 페이월이 없습니다
매주 경쟁사 평점 체크나 신규 사업체 목록 모니터링 같은 반복 작업은 예약 스크래퍼로 설정한 주기에 맞춰 자동 실행할 수 있습니다.
개발자를 위한 API, MCP 서버, CLI
POST /extract+ JSON Schema: Google Maps URL을 보내고 원하는 필드를 정의하면 구조화 JSON을 돌려줍니다. JavaScript가 많은 페이지는renderMode: "full"로 처리합니다. Thunderbit은 렌더링, 안티봇 대응, 프록시 로테이션, 지역 라우팅을 처리합니다.POST /distill: 어떤 페이지에서든 깔끔한 Markdown을 얻을 수 있습니다. 구조화 필드보다 원문 콘텐츠가 필요한 LLM 파이프라인에 유용합니다. Extract는 20크레딧, Distill은 1크레딧입니다.- MCP Server: Claude, Cursor 같은 AI 에이전트가 작업 중간에 Google Maps 데이터를 스크래핑할 수 있습니다. distillation, 구조화 추출, 필드 제안, 최대 100개 URL 배치 작업을 지원합니다.
- CLI:
thunderbit batch extract --file urls.txt --schema places.json형태로 예약 작업이나 CI/CD 통합 스크래핑을 실행할 수 있습니다.
크레딧 요금은 Extract = 요청당 20크레딧, Distill = 요청당 1크레딧입니다. API 크레딧은 행당이 아니라 요청당 과금입니다(확장 프로그램은 1크레딧 = 결과 행 1개). 최신 요금은 Thunderbit Pricing을 확인하세요.
법적 사항과 서비스 약관 고려사항
짧고 사실적으로만 말씀드리겠습니다. 겁주거나 영업하지 않겠습니다.
Google Places API는 명확한 약관을 제공합니다. Google의 서비스별 약관에 따르면 Places API 콘텐츠는 Google Map 없이 사용할 수 있지만, Google이 아닌 지도와 함께 사용해서는 안 됩니다. 위도/경도 값은 최대 30일 연속 캐시할 수 있으며, Place ID는 무기한 저장할 수 있습니다. 세부 정보, 사진, 리뷰에는 출처 표기가 필요합니다.
Google Maps 스크래핑은 Google의 서비스 약관을 위반할 수 있습니다. 집행 강도는 상황에 따라 다르며, IP 차단, CAPTCHA 벽, 드물게는 법적 조치까지 위험이 있습니다. 관리형 스크래핑 API는 보통 사용자를 대신해 일부 준법 부담을 흡수하지만, 이것이 법적 면책이 되는 것은 아닙니다.
최종 사용자를 대상으로 하는 프로덕션 앱이라면 공식 API가 더 안전한 선택입니다. 내부 리서치, 배치 분석, 경쟁 정보 수집에서는 스크래핑이 업계에서 흔한 관행입니다. 상업적 워크플로라면 반드시 법률 자문을 받으세요.
내가 실제로 고른다면 무엇일까? 그리고 그 이유
가격 체계, 필드 목록, 커뮤니티 스레드, 도구 문서를 모두 살펴본 뒤 제 결론은 이렇습니다.
- 공식 API를 사용할 때: 실시간이고 약관에 맞는 데이터를 프로덕션 앱에서 써야 하거나, Essentials/Pro 필드만으로 충분하고 월 1만 건 미만의 규모라면 API가 맞습니다. 소규모에서는 무료 한도가 넉넉하고, 데이터 품질도 믿을 수 있습니다.
- 스크래핑을 사용할 때: 전체 리뷰, 인기 시간대, Q&A, 경쟁사 맥락, 또는 API가 노출하지 않는 필드가 필요하다면 스크래핑이 맞습니다. 또한 월 1만~10만 건 이상으로 올라가고 Enterprise + Atmosphere 같은 풍부한 필드를 요청한다면 API 비용을 정당화하기 어려워집니다.
- 둘 다 사용할 때: 정식 Place ID와 기본 구조 데이터는 API로, 화면에서 보이는 심층 정보는 스크래핑으로 가져와야 하는 워크플로라면 하이브리드가 정답입니다. 사실 이 경우가 생각보다 훨씬 많습니다.
비용의 변곡점은 이렇습니다. 기본 필드 기준 월 약 1만 건 이하는 API가 더 단순하고 종종 무료입니다. 그 이상, 특히 풍부한 데이터가 필요할수록 스크래핑이 더 경제적입니다. Enterprise + Atmosphere 필드로 월 100만 건이라면 API 비용은 약 1만8천 달러 수준이고, 관리형 스크래퍼는 그 일부에 불과할 수 있습니다.
직접 시험해보고 싶다면 Thunderbit Chrome Extension이 스크래핑이 무엇을 가져오고 API와 어떻게 다른지 가장 빨리 확인하는 방법입니다. 개발자 워크플로라면 Thunderbit API 문서에서 시작에 필요한 모든 것을 찾을 수 있습니다. 그리고 코딩 없이 웹 스크래핑하기나 AI 웹 스크래핑에 대해 더 깊이 알고 싶다면, 블로그에서 이미 자세히 다뤘습니다.
핵심 요약
- Google Places API는 프로덕션 앱, 자동완성, 구조화된 장소 조회에 적합합니다. 다만 리뷰는 5개, 사진은 10개로 제한되며, 인기 시간대, Q&A, 경쟁사 추천은 제공하지 않습니다.
- 스크래핑은 Google Maps 페이지에 보이는 모든 것, 즉 전체 리뷰 세트와 인기 시간대 데이터까지 가져올 수 있지만, 안티봇 방어를 직접 관리하거나 관리형 서비스를 써야 합니다.
- 월 1만 건 이하에서는 API의 무료 한도가 가장 저렴한 옵션이 되는 경우가 많습니다. 10만 건 이상에서는 풍부한 데이터를 기준으로 스크래핑이나 관리형 스크래핑 API가 대체로 더 경제적입니다.
- DIY 스크래퍼는 Google의 안티봇 방어와 DOM 변경 때문에 자주 깨집니다. 유지보수용으로 연간 개발자 시간 40시간 이상을 잡거나, 관리형 도구를 쓰는 편이 낫습니다.
- 실제로 가장 잘 맞는 전략은 하이브리드인 경우가 많습니다. 정식 ID와 기본 필드는 API로, API가 못 주는 심층 인텔리전스는 스크래핑으로 처리하는 방식입니다.
- Thunderbit은 두 진영 모두를 지원합니다. 노코드 사용자를 위한 Chrome Extension과, 개발자를 위한 구조화 JSON API/MCP 서버를 제공합니다.
자주 묻는 질문
Places API로 Google 리뷰를 5개 이상 가져올 수 있나요?
아니요. Google Places API는 장소당 최대 5개 리뷰만 반환하며, 관련성 순으로 정렬됩니다. 이 제한은 API 출시 이후 계속 유지돼 왔고, 개발자 요청이 수년간 이어졌음에도 바뀌지 않았습니다. 비즈니스의 모든 리뷰를 보려면 스크래핑(직접 구현이든 관리형 스크래핑 API든)만 가능합니다.
Google Maps 스크래핑은 합법인가요?
전 세계적으로 단정할 수 있는 예/아니오 답은 없습니다. 공개적으로 보이는 Google Maps 데이터를 스크래핑하는 것은 Google의 서비스 약관을 위반할 수 있고, 집행은 IP 차단부터 드물게 법적 조치까지 다양합니다. 많은 기업이 내부 리서치와 경쟁 정보 수집에 문제 없이 사용하고 있습니다. 관리형 스크래핑 API는 일부 준법 리스크를 줄여주지만, 법적 방패는 아닙니다. 상업용 제품을 만들거나 개인정보를 처리한다면 법률 자문을 받으세요.
10만 조회 기준 Google Places API 비용은 얼마나 되나요?
어떤 필드를 요청하느냐에 따라 다릅니다. Place Details의 Essentials 등급이면 약 $450, Pro 등급이면 약 $1,615, 리뷰와 편의시설이 포함된 Enterprise + Atmosphere는 약 $2,475입니다. 검색용으로 Text Search Pro까지 필요하다면 약 $3,040가 추가됩니다. 이 추정치는 Google의 공개 단계 요금을 기준으로 하며, 무료 한도 이후 레코드당 1회 과금을 가정합니다.
스크래핑 API와 노코드 스크래핑 도구는 어떻게 다른가요?
Thunderbit의 Open API 같은 스크래핑 API는 개발자가 HTTP 요청을 통해 스크래핑을 코드, 자동화 파이프라인, AI 에이전트 워크플로에 통합할 때 사용합니다. Thunderbit Chrome Extension 같은 노코드 도구는 비기술 사용자가 브라우저에서 클릭만으로 데이터를 추출하고 내보낼 수 있게 해줍니다. 둘 다 구조화된 데이터를 돌려줄 수 있지만, 차이는 인터페이스와 통합 방식에 있습니다.
Thunderbit은 Google Maps 페이지에서도 작동하나요?
네. Chrome Extension은 Google Maps 검색 결과와 개별 비즈니스 목록을 스크래핑할 수 있고, AI가 자동으로 필드를 제안합니다. 클라우드 모드로 최대 50개 페이지를 동시에 처리할 수 있습니다. API의 POST /extract 엔드포인트는 renderMode: "full"로 Google Maps의 JavaScript 렌더링 페이지를 처리하고, 스키마에 맞는 구조화 JSON을 반환합니다. MCP 서버는 AI 에이전트가 워크플로 중간에 Google Maps 데이터를 스크래핑할 수 있게 해줍니다.
더 알아보기
