SERP 모니터링 갱신이란? 왜 IP 수가 중요한가
매일 10,000개 키워드의 순위를 추적하면서 HTTP 429 에러가 쏟아진다면, 가장 먼저 던질 질문은 "IP가 몇 개 필요한가?"입니다. SERP 모니터링 갱신은 검색엔진 결과 페이지(SERP)에서 특정 키워드의 순위를 주기적으로 수집하는 작업이며, 갱신 주기가 짧을수록 단위 시간당 요청 수가 늘어나고 더 많은 프록시 IP가 필요합니다.
핵심은 단순히 "IP가 많을수록 좋다"가 아닙니다. IP가 너무 적으면 429 차단과 CAPTCHA가 발생하여 데이터 수집이 중단되고, 너무 많으면 불필요한 비용만 증가합니다. 이 가이드에서는 키워드 수, 갱신 빈도, 검색엔진 정책을 기반으로 필요 IP 수를 정확히 산정하는 방법을 설명합니다.
검색엔진은 왜 IP별 요청을 제한하는가
Google, Bing, Naver 등 주요 검색엔진은 자동화된 스크래핑을 방지하기 위해 IP별 요청 속도를 제한합니다. 이는 서버 부하 방지와 사용자 경험 보호가 주된 목적입니다. 단일 IP에서 단기간에 과도한 요청이 들어오면 검색엔진은 HTTP 429 Too Many Requests 상태 코드로 응답하거나 CAPTCHA 챌린지를 반환합니다.
Google의 크롤링 정책에 따르면, Googlebot이 아닌 일반 IP에서 대량의 검색 요청을 보내면 자동화 탐지 시스템이 활성화됩니다. Google Search Central 문서에 따르면 Google은 공식 크롤러(Googlebot)와 일반 사용자 트래픽을 구분하여 처리하며, 비공식 자동화 트래픽에는 별도의 제한을 적용합니다.
실제 경험상 Google 검색에서 IP당 시간당 약 100-200회 요청부터 소프트 차단(일시적 CAPTCHA)이 시작되며, 300-500회를 넘기면 하드 차단(429 응답)이 발생합니다. Bing은 Google보다 관대한 편이지만 유사한 메커니즘을 사용합니다.
요청량 산정: 키워드 수 × 갱신 빈도
IP 수를 계산하려면 먼저 갱신 주기당 총 요청 수를 구해야 합니다. 기본 공식은 다음과 같습니다:
총 요청 수 = 키워드 수 × 검색엔진 수 × 기기 유형 수 × 지역 수예를 들어 다음과 같은 조건을 가정해 봅니다:
- 키워드 5,000개
- 검색엔진 2개 (Google, Bing)
- 기기 2종 (데스크톱, 모바일)
- 지역 3곳 (미국, 영국, 일본)
이 경우 갱신 주기당 총 요청 수는 5,000 × 2 × 2 × 3 = 60,000회입니다. 매일 1회 갱신한다면 하루 60,000회, 시간당 약 2,500회의 요청이 발생합니다.
갱신 주기가 IP 수에 미치는 영향
갱신 주기는 IP 풀 크기에 가장 큰 영향을 미치는 변수입니다. 같은 60,000회 요청을 24시간에 분산하면 시간당 2,500회지만, 1시간 안에 처리하면 시간당 60,000회가 필요합니다. 이는 곧 24배의 IP가 필요하다는 뜻입니다.
| 갱신 주기 | 시간당 요청 수 | 최소 IP 수 (100 req/IP/hr) | 안전 마진 포함 (×1.5) |
|---|---|---|---|
| 24시간 (일일) | 2,500 | 25 | 38 |
| 12시간 (반일) | 5,000 | 50 | 75 |
| 6시간 | 10,000 | 100 | 150 |
| 1시간 (시간별) | 60,000 | 600 | 900 |
이 표에서 알 수 있듯, 갱신 주기를 24시간에서 1시간으로 단축하면 필요 IP 수는 25개에서 600개로 24배 증가합니다. 갱신 빈도를 결정하기 전에 실제로 얼마나 자주 순위 변동을 확인해야 하는지 비즈니스 요구사항을 명확히 해야 합니다.
IP 풀 사이징 공식
위의 요소들을 종합하여 IP 풀 크기를 계산하는 공식은 다음과 같습니다:
최소 IP 수 = (총 요청 수 ÷ 갱신 주기 시간) ÷ IP당 시간당 요청 수
안전 IP 수 = 최소 IP 수 × 1.5 (안전 마진)IP당 시간당 요청 수는 검색엔진과 프록시 유형에 따라 다릅니다. 보수적으로 100 req/IP/hr를 사용하는 것을 권장합니다. 안전 마진 1.5배는 예상치 못한 차단, 재시도, 네트워크 지연을 흡수하기 위한 버퍼입니다.
실제 계산 예제
시나리오 A: 중소 규모 SEO 대행사
- 키워드 1,000개 × Google 1개 × 데스크톱 1종 × 1개 지역 = 1,000회/갱신
- 일일 갱신 (24시간)
- 최소 IP 수: (1,000 ÷ 24) ÷ 100 = 0.42 → 올림하여 1개
- 안전 마진: 1 × 1.5 = 2개
이 규모에서는 소수의 IP만으로도 충분합니다. ProxyHat 요금제의 소규모 패키지로 충분히 커버할 수 있습니다.
시나리오 B: 대규모 SERP 추적 플랫폼
- 키워드 50,000개 × Google+Bing 2개 × 데스크톱+모바일 2종 × 5개 지역 = 1,000,000회/갱신
- 6시간 갱신
- 최소 IP 수: (1,000,000 ÷ 6) ÷ 100 = 1,667개
- 안전 마진: 1,667 × 1.5 = 2,500개
이 규모에서는 대규모 주거용 프록시 풀이 필요합니다. ProxyHat의 주거용 프록시 풀은 수백만 개의 IP를 보유하고 있어 이 수준의 요청을 충분히 처리할 수 있습니다.
주거용 vs 데이터센터 프록시 비교
SERP 모니터링 갱신에 어떤 프록시 유형을 사용할지는 성공률과 비용에 직접적인 영향을 미칩니다.
| 항목 | 주거용 프록시 | 데이터센터 프록시 |
|---|---|---|
| IP 출처 | 실제 ISP 가입자 | 데이터센터 서버 |
| 차단 위험 | 낮음 | 높음 |
| 평균 응답 속도 | 200-800ms | 50-200ms |
| 가격 (GB당) | $3-$15 | $0.5-$2 |
| SERP 모니터링 적합도 | 높음 | 중간 (소규모만) |
| IP당 시간당 안전 요청 수 | 100-200회 | 50-100회 |
데이터센터 프록시는 빠르고 저렴하지만, Google은 데이터센터 IP 대역을 식별하여 더 엄격한 제한을 적용합니다. 일일 1,000회 이하의 소규모 갱신에서는 데이터센터도 가능하지만, 그 이상에서는 주거용 프록시를 권장합니다. 자세한 비교는 웹 스크래핑 사용 사례 페이지를 참조하세요.
회전 전략: 요청별 회전 vs 고정 세션
IP 회전 전략은 SERP 모니터링 갱신의 안정성에 큰 영향을 미칩니다.
요청별 회전 (Per-request Rotation)
모든 요청에 새로운 IP를 할당합니다. 같은 IP가 연속으로 사용되지 않으므로 IP당 요청 수가 자연스럽게 분산됩니다. SERP 모니터링 갱신에는 일반적으로 이 방식이 가장 적합합니다.
고정 세션 (Sticky Session)
특정 시간 동안 같은 IP를 유지합니다. 로그인이 필요한 페이지나 페이지 간 세션 유지가 필요한 경우에 사용합니다. SERP 모니터링에서는 일반적으로 불필요하지만, 동일 IP에서 페이지네이션을 처리해야 하는 경우 10-30분 고정 세션을 사용할 수 있습니다.
ProxyHat에서 세션 ID를 지정하려면 사용자 이름에 sid- 플래그를 추가합니다:
http://user-sid-abc123:pass@gate.proxyhat.com:8080요청별 회전을 사용하려면 세션 플래그 없이 기본 연결을 사용하면 됩니다:
http://user:pass@gate.proxyhat.com:8080지역 타겟팅 고려사항
SERP는 검색자의 위치에 따라 다르게 표시됩니다. "피자 배달"을 서울에서 검색한 결과와 뉴욕에서 검색한 결과는 완전히 다릅니다. 따라서 다국가 순위를 추적하려면 각 지역의 IP가 필요합니다.
ProxyHat에서 국가를 지정하려면 사용자 이름에 country- 플래그를 사용합니다:
# 미국 IP
http://user-country-US:pass@gate.proxyhat.com:8080
# 독일 베를린 IP
http://user-country-DE-region-state_of_berlin-city-berlin:pass@gate.proxyhat.com:8080지역 수가 늘어나면 총 요청 수가 선형적으로 증가하므로 IP 풀도 비례하여 커져야 합니다. 5개 국가를 추적한다면 단일 국가 대비 5배의 요청이 발생합니다. ProxyHat 위치 목록에서 지원 국가를 확인하세요.
ProxyHat 설정 및 코드 예제
Python (requests)
import requests
import time
import random
PROXY = "http://user:pass@gate.proxyhat.com:8080"
PROXIES = {"http": PROXY, "https": PROXY}
keywords = ["seo tools", "proxy service", "rank tracking"]
search_url = "https://www.google.com/search?q={}&num=100"
for kw in keywords:
url = search_url.format(kw.replace(" ", "+"))
try:
resp = requests.get(url, proxies=PROXIES, timeout=30,
headers={"User-Agent": "Mozilla/5.0"})
if resp.status_code == 429:
print(f"429 blocked on: {kw}")
time.sleep(60)
continue
print(f"{kw}: {resp.status_code}")
except Exception as e:
print(f"Error: {kw} - {e}")
time.sleep(random.uniform(2, 5))curl
curl -x http://user:pass@gate.proxyhat.com:8080 \
"https://www.google.com/search?q=seo+tools&num=100" \
-H "User-Agent: Mozilla/5.0" \
-H "Accept-Language: en-US,en;q=0.9"Node.js (axios)
const axios = require("axios");
const { HttpsProxyAgent } = require("https-proxy-agent");
const agent = new HttpsProxyAgent("http://user:pass@gate.proxyhat.com:8080");
async function checkRank(keyword) {
const url = `https://www.google.com/search?q=${encodeURIComponent(keyword)}&num=100`;
try {
const resp = await axios.get(url, {
httpsAgent: agent,
timeout: 30000,
headers: { "User-Agent": "Mozilla/5.0" }
});
console.log(`${keyword}: ${resp.status}`);
} catch (err) {
console.error(`Error: ${keyword} - ${err.message}`);
}
}
checkRank("seo tools");더 많은 사용 사례는 SERP 추적 사용 사례 페이지와 ProxyHat 문서를 참조하세요.
흔한 실수와 엣지 케이스
1. 안전 마진을 무시한 IP 수 계산
이론적 최소 IP 수만 계산하고 마진을 두지 않으면, 단 한 개의 IP가 차단되어도 전체 갱신 주기가 지연됩니다. 항상 1.5배 이상의 안전 마진을 확보하세요.
2. 랜덤 지연 없는 고속 요청
IP가 충분하더라도 단기간에 집중적으로 요청을 보내면 차단됩니다. 요청 사이에 2-5초의 랜덤 지연을 추가하여 사람과 유사한 패턴을 만드세요.
3. User-Agent 누락
기본 HTTP 클라이언트의 User-Agent(예: "python-requests/2.31.0")는 자동화 트래픽으로 즉시 식별됩니다. 항상 실제 브라우저의 User-Agent를 설정하세요.
4. 429 응답 시 즉시 재시도
429를 받고 즉시 재시도하면 차단이 더 심해집니다. 지수 백오프(60초 → 120초 → 240초)를 사용하여 점진적으로 재시도하세요.
5. 지역별 IP 불일치
미국 순위를 수집해야 하는데 한국 IP를 사용하면 잘못된 결과가 수집됩니다. 각 추적 지역에 맞는 국가 플래그를 반드시 설정하세요.
6. robots.txt 무시
Google의 robots.txt를 확인하여 허용된 경로와 제한을 파악하세요. robots.txt를 준수하는 것은 윤리적 스크래핑의 기본입니다.
