구글 맵스 API를 위한 프록시: 키 차단 없이 비즈니스 데이터의 지오코딩 및 파싱

Google Maps API는 주소 지오코딩, 조직 검색 및 지역 비즈니스 데이터 수집을 위한 강력한 도구입니다. 그러나 대량으로 작업을 시작하면 키 차단, 한도 초과 및 의심스러운 요청이 발생합니다. 이 기사에서는 이러한 일이 발생하는 이유와 키가 소진되지 않고 데이터가 안정적으로 수집되도록 프록시를 설정하는 방법을 설명합니다.

Google Maps API가 키와 요청을 차단하는 이유

하나의 IP 주소 또는 하나의 키로 Google Maps API에 수백 또는 수천 개의 요청을 보낼 때, Google은 이를 비정상적인 활동으로 인식합니다. 보호 시스템은 요청 빈도, IP 지리, 행동 패턴 및 키의 기록과 같은 여러 기준에 따라 작동합니다.

다음은 키가 제한되거나 완전히 차단되는 주요 이유입니다:

• 일일 요청 한도 초과 — 각 키에는 할당량이 있으며, 이를 초과하면 API는 OVER_QUERY_LIMIT 오류를 반환합니다.
• 하나의 IP에서 높은 요청 빈도 — 한도 내에서도 Google은 너무 빠른 연속 요청을 자동화로 인식합니다.
• 여러 키에 대한 하나의 IP — 키를 회전하지만 IP를 회전하지 않으면 Google은 이를 하나의 세션으로 연결합니다.
• 키와 IP의 지리적 불일치 — 키는 한 국가에 등록되어 있지만 요청은 다른 국가에서 발생하여 의심을 불러일으킵니다.
• 요청 간 지연 없음 — 중단 없는 기계적 패턴은 즉시 감지됩니다.
• 마스킹 없는 데이터 센터 IP 사용 — Google은 클라우드 제공업체(AWS, GCP, Azure)의 IP 범위를 잘 알고 있으며, 이들에 대한 검증 수준을 높입니다.

중요한 점은 Google Maps API는 유료 제품이며, Google은 남용뿐만 아니라 청구 우회를 방지하기 위해 이를 보호합니다. 따라서 이곳의 감지 시스템은 일반 웹 검색보다 훨씬 더 엄격합니다. 키가 차단되면 데이터 접근을 잃고 새로운 Google Cloud 계정을 만들어야 하며, 이는 자체적으로 많은 노력을 요구합니다.

비즈니스에서 Google Maps API를 사용하는 사람과 그 이유

기술적 세부 사항으로 넘어가기 전에 실제 사용 시나리오를 살펴보겠습니다. 이는 특정 작업에 적합한 프록시 유형과 회전 전략을 선택하는 데 도움이 됩니다.

대량 주소 지오코딩

물류 회사, 부동산 집계업체 및 배달 마켓플레이스는 정기적으로 수천 개의 텍스트 주소를 좌표로 변환합니다. 예를 들어, 경로 생성을 위해 50,000개의 고객 주소 데이터베이스를 업로드할 때입니다. Geocoding API를 사용하면 이를 자동화할 수 있지만, 짧은 시간에 하나의 키로 50,000개의 요청을 보내는 것은 차단으로 이어지는 직행입니다.

지역 비즈니스 데이터 파싱 (Places API)

마케팅 에이전시, 리드 생성업체 및 기업 데이터베이스는 Places API를 사용하여 조직에 대한 정보를 수집합니다: 이름, 전화번호, 웹사이트, 평점, 운영 시간, 리뷰. 일반적인 작업은 여러 도시에서 모든 레스토랑, 치과 또는 자동차 수리점을 수집하여 후속 전화 또는 이메일 마케팅을 위한 것입니다.

경쟁사 모니터링 및 지리 분석

소매업체는 자사 지역 내 경쟁사의 새로운 매장 오픈을 추적합니다. 프랜차이즈 네트워크는 새로운 매장을 위한 잠재적 위치를 분석합니다. 광고 에이전시는 특정 도시나 지역에서의 지리 타겟팅을 확인합니다.

CRM 데이터 보강

SaaS 제품 및 B2B 서비스는 자동으로 CRM의 기업 카드에 좌표를 추가하고, 주소의 유효성을 확인하며, Google 비즈니스 프로필에서 데이터를 가져옵니다. 이는 정기적인 백그라운드 API 요청을 자동으로 수행해야 합니다.

이러한 모든 시나리오는 하나의 공통점이 있습니다: 높은 요청 빈도이며, 프록시 없이 차단으로 이어집니다. 문제 해결 접근 방식은 작업에 따라 다릅니다.

Google Maps API 작업에 적합한 프록시 종류

프록시 유형의 선택은 작업의 안정성과 차단 가능성에 직접적인 영향을 미칩니다. Google Maps API 작업에 적합한 세 가지 주요 옵션을 살펴보겠습니다.

주거용 프록시 — 대부분의 작업에 최적의 선택

주거용 프록시는 실제 가정 사용자들의 IP 주소를 사용합니다. Google에는 일반 사용자가 브라우저에서 지도를 열고 있는 것처럼 보입니다. 이는 Places API 및 높은 요청 빈도로 지오코딩 작업을 수행하는 데 가장 안전한 옵션입니다. 큰 IP 풀을 통해 각 요청 또는 몇 개의 요청마다 회전할 수 있어 Google이 이를 하나의 세션으로 연결할 시간이 없습니다.

모바일 프록시 — 최대 신뢰성이 필요한 경우

이동통신 사업자의 모바일 IP는 특별한 경우입니다. 하나의 모바일 IP는 NAT를 통해 여러 장치에서 실제로 사용되므로 Google은 높은 활동에도 불구하고 이러한 주소를 차단하는 경우가 드뭅니다. 작업이 매우 중요하고 중단을 허용할 수 없는 경우 모바일 프록시가 최대의 안정성을 제공합니다. 단점은 더 높은 가격과 적은 주소 풀입니다.

데이터 센터 프록시 — 민감하지 않은 작업에만 사용

서버 프록시는 빠르고 저렴하지만 Google Maps API는 이에 대해 높은 의심을 가지고 있습니다. 중간 빈도와 좋은 회전으로 많은 주소를 지오코딩하는 데 사용하면 작동할 수 있지만, Places API 파싱이나 엄격한 제한이 있는 지역에서 작업할 경우 키 차단 위험이 상당히 높아집니다.

지오코딩을 위한 프록시 설정: 단계별 가이드

가장 일반적인 시나리오인 Geocoding API를 예로 들어 실용적인 설정을 살펴보겠습니다. 작업: 차단 없이 10,000개의 주소 목록을 좌표로 변환합니다.

1단계. 인프라 준비

우선 키와 프록시의 수를 결정하세요. 기본 규칙: 하나의 키 — 하나의 IP 풀. 서로 다른 키에 대해 동일한 프록시 풀을 사용하지 마세요 — Google은 행동 패턴에 따라 이를 연결할 수 있습니다. 10,000개의 주소 작업에는 최소 2-3개의 Google Cloud 키와 50개 이상의 주거용 IP 풀이 권장됩니다.

2단계. IP 회전 설정

지오코딩에 최적의 전략은 요청마다 IP를 변경하는 것이 아니라 10-20 요청마다 IP를 변경하는 것입니다. 너무 잦은 IP 변경도 의심스럽게 보일 수 있습니다. 대부분의 주거용 프록시 제공업체는 지정된 간격에 따라 자동으로 IP를 변경하는 회전 엔드포인트를 제공합니다. 수동 전환이 아닌 이를 사용하세요.

import requests

GOOGLE_API_KEY = "당신의_키"
PROXY_HOST = "rotating.proxyprovider.com"
PROXY_PORT = "8080"
PROXY_USER = "username"
PROXY_PASS = "password"

proxies = {
    "http":  f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}",
    "https": f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
}

def geocode_address(address):
    url = "https://maps.googleapis.com/maps/api/geocode/json"
    params = {
        "address": address,
        "key": GOOGLE_API_KEY,
        "language": "ko"
    }
    response = requests.get(url, params=params, proxies=proxies, timeout=10)
    return response.json()

# 사용 예
result = geocode_address("모스크바, Тверская 거리, 1")
print(result["results"][0]["geometry"]["location"])

3단계. 요청 간 지연 추가

"최대한 빨리" 모드로 요청을 보내지 마세요. 요청 간에 0.5초에서 2초 사이의 무작위 지연을 추가하세요. 무작위성이 중요합니다 — 고정 간격(예: 정확히 1초)도 기계적 패턴처럼 보입니다. Python에서는 time.sleep(random.uniform(0.5, 2.0))를 통해 구현할 수 있습니다.

4단계. 요청 헤더 올바르게 설정

Google Maps에 대한 API 요청은 현실적인 User-Agent를 포함해야 합니다. 기술적으로 API는 브라우저 User-Agent를 요구하지 않지만, 이를 생략하거나 표준 Python User-Agent를 사용하면 감지 확률이 높아집니다. 실제 브라우저를 모방하는 User-Agent를 사용하고, 동일한 세션 내에서 너무 자주 변경하지 마세요.

5단계. 오류 및 재시도 처리

응답 상태를 올바르게 처리하세요. OVER_QUERY_LIMIT 오류가 발생하면 60초 동안 대기하고 IP를 변경하세요. REQUEST_DENIED 오류가 발생하면 키가 차단된 것이므로 백업으로 전환하세요. ZERO_RESULTS 오류는 주소에 문제가 있는 것이지 프록시에 문제가 있는 것이 아닙니다.

프록시를 통한 Places API 비즈니스 데이터 파싱

Places API는 Geocoding API보다 훨씬 더 민감한 엔드포인트입니다. Google은 대량 요청의 주요 목표가 상업적 데이터 수집이라는 것을 이해하므로 보호가 더 엄격합니다. 이를 올바르게 사용하는 접근 방식을 살펴보겠습니다.

Places API를 통한 데이터 수집 전략

Places API는 두 가지 주요 방법으로 작동합니다: Nearby Search (좌표 및 반경에 따른 검색) 및 Text Search (텍스트 요청에 따른 검색). 넓은 지역을 커버하기 위해 그리드 방법을 사용하여 지역을 격자로 나누고 각 격자를 순차적으로 탐색합니다.

주요 특징: Places API는 한 번의 검색에서 최대 60개의 결과를 반환합니다 (3페이지에 20개씩). 만약 지역에 60개 이상의 객체가 있다면 검색 반경을 줄이고 그리드 밀도를 높여야 합니다. 이는 자동으로 요청 수를 증가시키며, 프록시 회전이 매우 중요해집니다.

import requests
import time
import random

def search_places_nearby(lat, lng, radius, place_type, api_key, proxies):
    results = []
    url = "https://maps.googleapis.com/maps/api/place/nearbysearch/json"
    
    params = {
        "location": f"{lat},{lng}",
        "radius": radius,
        "type": place_type,
        "key": api_key,
        "language": "ko"
    }
    
    while True:
        response = requests.get(url, params=params, proxies=proxies, timeout=15)
        data = response.json()
        
        if data.get("status") == "OVER_QUERY_LIMIT":
            print("요청 한도 초과 — 60초 대기")
            time.sleep(60)
            continue
            
        results.extend(data.get("results", []))
        
        # 다음 페이지의 토큰
        next_token = data.get("next_page_token")
        if not next_token:
            break
            
        # 다음 페이지 요청 전 필수 대기 (Google의 요구 사항)
        time.sleep(random.uniform(2.0, 3.5))
        params = {"pagetoken": next_token, "key": api_key}
    
    return results

Place Details를 통한 상세 데이터 수집

Nearby Search 또는 Text Search를 통해 place_id 목록을 받은 후, 각 장소에 대해 전화번호, 웹사이트, 운영 시간 및 리뷰를 얻기 위해 Place Details에 대한 별도의 요청을 해야 합니다. 이는 요청 수를 두 배로 늘립니다. 여기서 IP 회전이 특히 중요합니다 — 각 Place Details 요청은 풀에서 새로운 주소로 수행하는 것이 좋습니다.

필요한 필드만 fields 매개변수를 통해 요청하세요. 이는 요청 비용을 줄이고 전송되는 데이터 양을 줄여 요청 패턴이 트래픽 양 측면에서 덜 의심스럽게 만듭니다.

키와 IP 회전: 안정적인 작업을 위한 방법

Google Maps API와의 전문적인 작업은 단순한 프록시가 아니라 키와 IP 관리에 대한 체계적인 접근이 필요합니다. 올바르게 구성된 인프라는 다음과 같습니다.

Google Cloud 키 풀

Google Cloud Console에서 여러 프로젝트를 생성하세요 — 심각한 작업을 위해 최소 3-5개. 각 프로젝트는 고유한 API 키를 받습니다. 키 간에 부하를 고르게 분산시키세요: 하루에 10,000개의 요청이 있고 5개의 키가 있다면, 각 키는 2,000개의 요청을 수행하게 되어 의심의 문턱이 훨씬 낮아집니다.

중요한 규칙: 각 키를 프록시 풀의 개별 IP 범위에 연결하세요. 키 #1은 A 범위의 IP를 통해서만 작동하고, 키 #2는 B 범위를 통해 작동합니다. 키와 IP를 혼합하는 것은 대량 차단으로 이어지는 주요 오류 중 하나입니다.

요청 일정

모든 요청을 밤이나 비업무 시간에 실행하지 마세요 — 이는 "일반 사용자"에게 비정상적인 패턴입니다. 작업을 업무 시간 동안 분산시키고 자연스러운 활동을 모방하세요. 작업이 여러 날에 걸쳐 수행될 수 있다면, 하룻밤에 모든 것을 처리하기보다는 3-5일에 걸쳐 적절한 부하로 작업을 분산시키는 것이 좋습니다.

키 상태 모니터링

API 응답 상태를 자동으로 모니터링하세요. 제한의 첫 징후가 나타나면(OVER_QUERY_LIMIT 오류 증가) 즉시 해당 키의 요청 빈도를 줄이고 몇 시간 동안 "휴식"을 주세요. 완전 차단을 기다리지 마세요 — 예방하는 것이 치료하는 것보다 훨씬 쉽습니다.

Google Maps API 한도 및 우회 방법

Google Maps API의 한도를 이해하는 것은 인프라 계획에 매우 중요합니다. 한도는 두 가지 유형이 있습니다: 쿼터(하루/한 달에 얼마나 많은 요청을 할 수 있는지)와 비율 한도(초당 얼마나 많은 요청을 할 수 있는지). 프록시는 올바르게 사용하면 두 가지 유형 모두에 도움이 됩니다.

주의: 한도는 키에 연결되어 있으며, IP에 연결되어 있지 않습니다. 따라서 키 회전과 IP 회전을 결합하는 것이 API 비용 증가 없이 작업을 확장하는 유일한 방법입니다. 각각의 무료 쿼터가 $200인 여러 키는 전체 무료 요청량을 상당히 증가시킬 수 있습니다.

프록시가 비율 한도에 어떻게 도움이 되는가

Geocoding API의 50 QPS 비율 한도는 하나의 키로 초당 50개 요청을 넘지 말라는 의미입니다. 여기서 프록시는 이 한도를 우회하는 데 도움이 되지 않습니다 — 이는 키에 연결되어 있습니다. 그러나 프록시는 키 간의 부하를 분산시켜 각 키가 안전한 영역에 머물도록 도와줍니다 (최대 비율 한도의 70-80%를 초과하지 않는 것이 좋습니다).

자주 발생하는 오류 및 피하는 방법

Google Maps API와의 작업에서 발생하는 전형적인 오류 목록이 있습니다. 각 오류를 살펴보고 구체적인 해결책을 제시하겠습니다.

오류 1: 여러 키에 대해 하나의 IP 사용

이것은 가장 흔한 오류입니다. 키를 회전하지만 모든 요청이 하나의 프록시 또는 작은 IP 풀에서 발생하면 Google은 하나의 주소에서 서로 다른 키가 사용되고 있음을 인식하고 이를 하나의 세션으로 연결합니다. 하나의 키가 차단되면 다른 모든 키도 위험에 처하게 됩니다.

해결책: 키에 따라 IP 풀을 엄격하게 분리하세요. 각 키는 전용 주소 범위를 통해서만 작동해야 합니다.

오류 2: Places API의 페이지 간 필수 대기 무시

Places API는 다음 페이지 요청 전에 최소 2초의 대기를 요구합니다 pagetoken을 사용하여. 즉시 다음 페이지를 요청하면 API는 빈 결과 또는 오류를 반환합니다. 많은 개발자들이 이 요구 사항을 무시하고 잘못된 데이터를 받습니다.

해결책: 항상 다음 페이지 요청 전에 2-3초의 대기를 추가하세요. 이는 Google의 문서화된 요구 사항이며 선택적 권장 사항이 아닙니다.

오류 3: 코드 내에서 보호되지 않은 키

GitHub의 공개 리포지토리에 노출된 Google Maps API 키는 자동으로 봇에 의해 스캔되고 악의적인 사용자에 의해 사용됩니다. Google은 키 유출을 자동으로 감지하고 알림을 보내지만, 피해는 그 이전에 발생할 수 있습니다.

해결책: 키를 환경 변수 또는 비밀 관리 시스템(Vault, AWS Secrets Manager)에 저장하세요. 절대 소스 코드에 키를 하드코딩하지 마세요. Google Cloud Console에서 IP 제한을 설정하세요 — 키는 오직 당신의 프록시 주소에서만 작동해야 합니다.

오류 4: Place Details의 모든 필드 요청

기본적으로 Place Details는 모든 사용 가능한 필드를 반환하며, 여기에는 비용이 많이 드는 필드(분위기, 리뷰)가 포함됩니다. 이는 각 요청의 비용을 2-4배 증가시킵니다. 또한, 응답의 큰 양은 처리 속도를 늦춥니다.

해결책: 항상 fields 매개변수를 사용하고 필요한 데이터만 요청하세요. 예: fields=name,formatted_phone_number,website,opening_hours,rating.

오류 5: 무료 또는 공개 프록시 사용

공개 목록의 무료 프록시는 키를 잃는 확실한 방법입니다. 이러한 IP는 이미 수천 명의 다른 사용자에 의해 사용되고 있으며, 그 중 많은 사용자가 Google이 방지하고자 하는 작업을 수행하고 있습니다. 이러한 IP의 평판은 매우 낮으며, Google은 이를 예방적으로 차단합니다.

해결책: 신뢰할 수 있는 공급자로부터 청정 IP 주소와 독점 사용 보장을 제공하는 유료 프록시만 사용하세요.

결론

Google Maps API를 대량으로 작업하는 것은 항상 데이터 수집 속도와 키 보호 간의 균형을 유지하는 것입니다. 프록시는 IP 차단 문제를 해결하지만, 올바른 아키텍처 — 키 회전, 요청 빈도 제어, 오류 처리 및 작업별 IP 풀 분리를 대체하지는 않습니다.

이 기사의 주요 결론: 주거용 프록시와 회전은 Places API 및 지오코딩 작업에 적합하며, 각 키는 고립된 주소 풀을 통해 작동해야 합니다; 요청 간 지연은 필수이며; 키 상태 모니터링은 자동화되어야 합니다.

Google Maps API를 정기적으로 사용하여 주소를 지오코딩하거나 비즈니스 데이터를 수집하거나 경쟁사를 모니터링할 계획이라면 주거용 프록시에 주목하는 것이 좋습니다. 이는 Google의 높은 신뢰를 보장하고 올바르게 설정된 IP 회전으로 키 차단 위험을 최소화합니다. 중단 없는 최대 신뢰성이 필요한 작업에는 모바일 프록시를 고려하세요 — 이들의 IP는 높은 활동에도 거의 차단되지 않습니다.