실제로 확장되는 Google Places 추출 도구 구축
Source: Dev.to
Google Places에서 데이터를 추출하는 것은 규모를 키우려고 할 때까지는 쉬워 보입니다.
수백 개 정도의 결과는 문제없이 작동합니다. 수천 개가 되면 어려움이 시작됩니다. 전국 규모의 추출은 모든 문제점을 드러냅니다: 페이지네이션 제한, 중복, 속도 제한, 불분명한 비용, 중간에 실패하는 장시간 실행.
이 글에서는 로컬 Google Places 추출 도구를 만들면서 최종적으로 도출한 패턴을 설명합니다. 예시는 실제 영국 프로젝트에서 나온 것이지만, 접근 방식은 국가에 구애받지 않습니다. 스크래핑도, SaaS도 없습니다. 단지 제어된, 반복 가능한 추출만을 제공합니다.
Source:
실제 문제는 접근이 아니라
Google Places 데이터는 공식 API를 통해 접근할 수 있습니다. 이것이 어려운 부분은 아닙니다.
어려운 부분은 그 주변의 모든 것입니다:
- 쿼리를 분산시켜야 하는 페이지네이션 제한
- 동일한 비즈니스가 여러 근접 검색에 중복 표시됨
- API 호출 제한 및 일시적인 오류
- 몇 시간 동안 진행된 후에 실패하는 장시간 추출 작업
- 작업이 완료될 때까지 비용을 알 수 없음
대부분의 도구는 이러한 제약을 무시하거나 구독 형태로 숨깁니다.
구조를 강제한 사용 사례
원래 작업은 문서상으로는 간단했습니다:
- 영국 전역의 이발사 추출
- 전화번호 포함
- CSV로 내보내기
- 중복 방지
- API 비용을 예측 가능하게 유지
실제로는 영국(잉글랜드, 스코틀랜드, 웨일스, 북아일랜드) 전역의 200개 이상의 도시를 포괄하면서 실행을 재개 가능하고 감사 가능하도록 해야 했습니다. 이는 보다 체계적인 아키텍처를 강요했습니다.
Core design principles
Country‑agnostic search strategy
The UK case used a predefined city list. The same approach works anywhere. The key idea is not the country, but the search grid:
- Cities, regions, or custom locations
- One query per location
- Controlled pagination depth per area
Change the input list and the tool works globally.
Explicit pagination control
Google Places pagination is slow and capped. The tool:
- Limits pages per location
- Inserts delays between page requests
- Stops early when results become redundant
This trades raw speed for predictability. At scale, predictability wins.
Deduplication as a first‑class concern
Duplicates are guaranteed. Deduplication happens on:
- Place ID
- Phone number
This removes overlaps across nearby cities and repeated queries. Deduplication is not a cleanup step; it is part of the extraction loop.
Filtering before export, not after
Filtering thousands of rows in Excel is a failure mode. The tool filters during extraction:
- Include keywords
- Exclude keywords
- Optional phone requirement
Bad data is never written to disk.
Rate limiting and checkpoints
Two things matter in long runs:
- Not getting blocked
- Not losing progress
The tool includes:
- Fixed delays between requests
- Periodic checkpoints saved to disk
If the process stops, it resumes from the last checkpoint. No reruns. No wasted quota.
예시 구성 패턴
간단화된 구성은 개념적으로 다음과 같습니다:
- 검색 쿼리 및 선택적 장소 유형
- 목표 결과 수
- 포함 및 제외 키워드
- 페이지네이션 깊이
- 요청 지연 시간
- 출력 형식 및 체크포인트 간격
논리는 안정적으로 유지되고, 변동성은 구성으로 이동합니다.
Why this is not scraping
This approach uses the official Google Places API. That brings trade‑offs:
- You respect rate limits
- You pay per request
- You accept the API’s data model
In return you get:
- Stability
- Legal clarity
- Predictable failures
For many business datasets, this is a better trade than scraping.
이 패턴이 해결하지 못하는 것
명시적인 것이 중요합니다. 이것은 하지 않습니다:
- Google 제한 우회
- 숨겨진 필드 추출
- API 제약을 넘어선 완전성 보장
이것은 제어를 최적화할 뿐, 전지전능을 제공하지 않습니다.
아이디어는 그대로, 스크립트에서 제품으로
첫 번째 버전은 클라이언트 작업을 위해 만든 Node.js 스크립트였습니다. 이후 동일한 패턴이 로컬 데스크톱 앱으로 발전했습니다:
- 설정 파일 대신 UI
- 실시간 비용 추정
- 일시 정지 및 재개 제어
- 필드 수준 내보내기 선택
동일한 원칙. 더 나은 인체공학. 중요한 부분은 앱이 아니라 패턴입니다.
요약
- 지리 정보를 제어된 단위로 나누기
- 페이지네이션과 중복 제거를 핵심 로직으로 다루기
- 비용과 실패를 초기에 가시화하기
- 로컬에서 실행하고, 자체 API 키 사용하기
나머지는 구현 세부 사항일 뿐이다.