프록시 인프라를 설계할 때 가장 중요한 결정 중 하나는 고정 vs 회전 프록시 세션 중 어느 것을 사용할지 선택하는 것입니다. 회전 게이트웨이는 요청마다 새로운 엑시트 IP를 할당하지만, 고정 세션은 하나의 레지덴셜 IP를 고정 TTL(일반적으로 1~30분) 동안 유지합니다. 이 가이드에서는 두 방식의 기술적 차이, ProxyHat에서 세션을 제어하는 방법, 그리고 실무에서 언제 어느 것을 선택해야 하는지를 설명합니다.
고정 vs 회전 프록시 세션의 핵심 차이
회전 프록시 세션(Rotating Proxy Session)은 각 HTTP 요청이 게이트웨이의 IP 풀에서 무작위로 선택된 새로운 엑시트 IP를 통해 나가는 방식입니다. 대규모 공개 데이터 수집, SERP 스크래핑, 분산된 페이지 크롤링에 적합합니다. 단일 IP당 요청 밀도가 낮아져 차단 임계값을 넘을 확률이 줄어듭니다.
고정 프록시 세션(Sticky Proxy Session)은 지정된 식별자(세션 ID)에 대해 동일한 엑시트 IP를 일정 시간 동안 유지합니다. ProxyHat에서는 기본적으로 최대 30분까지 IP를 고정할 수 있습니다. 로그인 상태, CSRF 토큰, 장바구니, 페이지네이션 토큰 등 IP 기반 상태 검증이 필요한 워크플로우에 필수적입니다.
| 특성 | 회전 세션 (Rotating) | 고정 세션 (Sticky) |
|---|---|---|
| 엑시트 IP | 요청마다 변경 | TTL 동안 동일 IP 유지 |
| 최대 지속 시간 | 단일 요청 | 1~30분 (재사용 가능) |
| 적합한 용도 | 대량 공개 데이터 수집, SERP | 로그인, 결제, 페이지네이션 |
| IP당 요청 밀도 | 낮음 (분산됨) | 높음 (집중됨) |
| 상태 유지 | 불가 | 가능 (동일 IP 내에서) |
왜 IP 기반 상태가 고정 세션을 필요로 하는가
많은 웹 애플리케이션은 보안을 위해 세션 상태를 IP 주소에 바인딩합니다. 이는 OWASP가 설명하는 CSRF 방어 메커니즘의 일환으로, 인증 토큰이 발급된 IP와 후속 요청의 IP가 일치해야 토큰을 승인하는 방식입니다. 회전 프록시를 사용하면 로그인 직후 두 번째 요청이 다른 IP에서 들어오므로 서버가 세션을 거부합니다.
구체적인 시나리오는 다음과 같습니다:
- 로그인 플로우: POST /login으로 인증 쿠키를 받은 뒤, GET /dashboard를 호출할 때 IP가 바뀌면 401 Unauthorized 반환.
- CSRF 토큰: 폼 페이지에서 CSRF 토큰을 발급받고 제출할 때 IP가 다르면 403 Forbidden.
- 장바구니 / 결제: 전자상거래 사이트에서 카트에 상품을 담고 결제 페이지로 넘어갈 때 IP가 바뀌면 세션 만료.
- 페이지네이션 토큰: 검색 결과의 다음 페이지 토큰이 최초 요청 IP와 매핑되어, IP가 바뀌면 400 오류.
이런 경우 레지덴셜 고정 세션이 필요합니다. 레지덴셜 IP는 실제 ISP가 할당한 IP이므로 타겟 사이트의 안티봇 시스템에서 데이터센터 IP보다 신뢰도가 높으며, 고정 세션을 통해 IP 기반 상태 검증을 통과할 수 있습니다.
ProxyHat에서 세션 제어하기: 사용자 이름 토큰
ProxyHat은 프록시 인증 사용자 이름에 토큰을 추가하여 세션 동작을 제어합니다. 별도의 API 호출이나 헤더 조작 없이, 사용자 이름 문자열만으로 회전과 고정을 전환할 수 있습니다.
회전 세션 (기본)
세션 토큰 없이 기본 인증을 사용하면, 게이트웨이가 각 요청마다 새로운 IP를 할당합니다:
http://user:pass@gate.proxyhat.com:8080이 엔드포인트로 1,000개의 요청을 보내면 최대 1,000개의 서로 다른 엑시트 IP가 사용됩니다. 대량 공개 데이터 수집에 적합합니다.
고정 세션: 세션 ID + 국가 지정
사용자 이름에 -session-abc123 토큰을 추가하면, 동일한 세션 ID에 대해 동일한 엑시트 IP가 유지됩니다. -country-US를 함께 사용하면 미국 레지덴셜 IP를 고정할 수 있습니다:
http://user-session-abc123-country-US:pass@gate.proxyhat.com:8080이 URL로 보내는 모든 요청은 동일한 미국 IP를 통해 나가며, 세션 ID가 유지되는 동안 IP 기반 상태가 보존됩니다. 세션 TTL은 기본적으로 최대 30분이며, 새로운 세션 ID를 생성하면 새로운 IP가 할당됩니다.
도시 단위 지정
더 세밀한 지역 타겟팅이 필요한 경우 도시를 지정할 수 있습니다:
http://user-country-DE-city-berlin-session-xyz789:pass@gate.proxyhat.com:8080베를린 레지덴셜 IP를 고정하여, 지역 제한 콘텐츠 접근이나 현지 가격 비교에 활용할 수 있습니다. ProxyHat 지원 위치 목록에서 사용 가능한 국가와 도시를 확인하세요.
실무 구현 예제
예제 1: Python requests로 회전 세션 사용하기
대량의 공개 페이지를 수집하는 시나리오입니다. 각 요청마다 새로운 IP가 할당되므로, 단일 IP당 요청 밀도가 낮아 차단 위험이 줄어듭니다:
import requests
# ProxyHat 회전 엔드포인트 (세션 토큰 없음)
proxy_url = "http://user:pass@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}
urls = [
"https://example.com/page/1",
"https://example.com/page/2",
"https://example.com/page/3",
]
for url in urls:
try:
resp = requests.get(url, proxies=proxies, timeout=30)
print(f"{resp.status_code} - {url} - IP rotated")
except requests.RequestException as e:
print(f"Error: {url} - {e}")이 패턴은 SERP 추적이나 대규모 제품 페이지 크롤링에 적합합니다. 각 요청이 독립적이므로 IP 기반 상태가 필요 없습니다.
예제 2: Node.js에서 고정 세션으로 다단계 플로우 유지하기
로그인 → 대시보드 → 데이터 조회의 3단계 플로우를 구현합니다. 동일한 세션 ID를 사용하여 IP를 고정합니다:
const http = require('http');
const SESSION_ID = "order-flow-20240115";
const baseAuth = `user-session-${SESSION_ID}-country-US:pass`;
const proxyHost = "gate.proxyhat.com";
const proxyPort = 8080;
async function request(targetUrl) {
return new Promise((resolve, reject) => {
const url = new URL(targetUrl);
const options = {
hostname: proxyHost,
port: proxyPort,
path: targetUrl,
method: 'GET',
headers: {
'Host': url.hostname,
'Proxy-Authorization': 'Basic ' + Buffer.from(baseAuth).toString('base64')
}
};
const req = http.request(options, (res) => {
let data = '';
res.on('data', (chunk) => data += chunk);
res.on('end', () => resolve({ status: res.statusCode, body: data }));
});
req.on('error', reject);
req.end();
});
}
(async () => {
// 1단계: 로그인 (POST는 별도 구현 필요)
const login = await request('https://target-site.com/login');
console.log(`Login: ${login.status}`);
// 2단계: 대시보드 (동일 IP 보장)
const dashboard = await request('https://target-site.com/dashboard');
console.log(`Dashboard: ${dashboard.status}`);
// 3단계: 데이터 조회 (동일 IP 보장)
const data = await request('https://target-site.com/api/data');
console.log(`Data: ${data.status}`);
})();세션 ID order-flow-20240115는 세 단계 모두 동일한 엑시트 IP를 보장합니다. 워크플로우가 끝나면 새로운 세션 ID를 생성하여 다음 작업에 사용하면 됩니다.
운영 가이드: 세션 TTL 튜닝과 병렬 세션 관리
TTL 튜닝
고정 세션의 TTL은 워크플로우 길이에 맞춰야 합니다. 짧은 로그인 플로우(2~3단계, 30초 이내)는 5분 TTL로 충분합니다. 반면, 페이지네이션을 포함한 긴 크롤링 작업(50페이지 이상, 10~20분)은 30분 TTL이 필요합니다. 세션이 만료되기 전에 워크플로우를 완료해야 IP 변경으로 인한 세션 끊김을 방지할 수 있습니다.
429/403 발생 시 세션 재활용
고정 세션 사용 중 429(Too Many Requests) 또는 403(Forbidden) 응답을 받으면, 해당 세션 ID를 폐기하고 새로운 세션 ID로 전환해야 합니다. 동일 IP에서 차단이 발생했다면, 그 IP로 계속 요청을 보내는 것은 차단을 악화시킬 뿐입니다:
import requests
import uuid
def make_sticky_request(url, session_id=None):
if session_id is None:
session_id = str(uuid.uuid4())
proxy_url = f"http://user-session-{session_id}-country-US:pass@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}
resp = requests.get(url, proxies=proxies, timeout=30)
if resp.status_code in (429, 403):
# 세션 재활용: 새 ID로 재시도
return make_sticky_request(url, session_id=str(uuid.uuid4()))
return resp, session_id병렬 세션 수 산정
동시에 실행할 고정 세션 수는 타겟 사이트의 속도 제한과 IP 풀 크기에 따라 결정됩니다. 일반적으로 한 IP당 분당 30~60 요청 이하를 유지하는 것이 안전합니다. 100개의 병렬 고정 세션을 실행하면, 분당 3,000~6,000 요청을 분산시킬 수 있습니다. 하지만 타겟 사이트가 엄격한 속도 제한을 적용한다면, 세션당 요청 속도를 낮추거나 세션 수를 줄여야 합니다.
실제 운영에서는 성공률 95% 이상을 유지하는 것을 목표로 해야 합니다. 성공률이 90% 이하로 떨어지면, 세션당 요청 속도를 줄이거나 병렬 세션 수를 조정해야 합니다.
회전 세션이 유리한 경우: 대량 공개 데이터 수집
모든 시나리오에서 고정 세션이 정답은 아닙니다. 다음 조건에서는 회전 세션이 더 효율적입니다:
- 독립적인 페이지 수집: 각 페이지가 서로 다른 IP에서 수집되어도 되는 경우. 예: 10,000개의 제품 페이지 메타데이터 수집.
- SERP 스크래핑: 검색 결과 페이지는 로그인이 필요 없고, 각 요청이 독립적입니다. 회전 세션으로 단일 IP당 1~2 요청만 보내면 차단 위험이 최소화됩니다.
- 경쟁사 가격 모니터링: 여러 사이트의 가격을 주기적으로 확인할 때, IP를 분산시키면 패턴 감지를 피할 수 있습니다.
- AI 학습 데이터 수집: 대규모 공개 웹 페이지를 수집하여 모델 학습용 코퍼스를 구축할 때, 회전 세션으로 처리량을 극대화합니다.
이러한 용도에서는 웹 스크래핑에 회전 세션을 사용하고, 처리량을 늘리기 위해 동시 연결 수를 늘리는 것이 효과적입니다. ProxyHat의 회전 엔드포인트는 자동으로 IP를 분배하므로, 추가 세션 관리 로직 없이도 대량 요청을 처리할 수 있습니다.
법적 고려사항: CFAA와 GDPR
프록시 사용이 기술적으로 가능하다고 해서 법적으로 허용되는 것은 아닙니다. 미국에서는 CFAA(Computer Fraud and Abuse Act)가 인가되지 않은 접근을 제한하며, 명시적 로그인이 필요한 영역을 우회하여 접근하는 것은 법적 위험이 있습니다. 유럽 연합에서는 GDPR 제5조가 개인 데이터 처리의 합법성, 최소화, 목적 제한을 요구합니다.
실무 권장사항:
- robots.txt 확인: 타겟 사이트의 robots.txt를 먼저 확인하여 수집이 허용된 경로인지 확인하세요.
- 이용약검 검토: 사이트의 ToS(Terms of Service)에서 자동화 수집을 금지하는 조항이 있는지 확인하세요.
- 개인 데이터 최소화: 개인 식별 정보(PII)가 포함된 데이터를 수집할 때는 GDPR/CCPA 요구사항을 준수해야 합니다.
- 속도 제한 준수: 타겟 사이트의 서버에 부하를 주지 않도록 적절한 요청 간격을 유지하세요.
비용-효율 분석: 구매 vs 자체 구축
프록시 인프라를 자체 구축하는 것과 프록시 서비스를 구매하는 것의 비용을 비교해 봅니다. 자체 구축 시 1,000개의 레지덴셜 IP를 확보하려면, 최소 $5,000/월 이상의 인프라 비용(서버, IP 대역, 유지보수)이 발생합니다. 반면 ProxyHat과 같은 서비스를 사용하면, 사용량 기반 과금으로 필요한 만큼만 비용을 지불할 수 있습니다. ProxyHat 가격 페이지에서 현재 요금제를 확인하세요.
ROI 계산 예시: 한 이커머스 스크래핑 팀이 50,000개 제품 페이지를 매일 수집한다고 가정합니다. 자체 인프라로 차단률 20%를 경험하면, 10,000개 페이지 재수집에 추가 시간이 소요됩니다. ProxyHat 회전 세션으로 차단률을 5% 이하로 낮추면, 재수집 비용이 75% 감소하여 월 $2,000의 프록시 비용으로 월 $8,000의 운영 비용 절감 효과를 얻을 수 있습니다.
Key Takeaways
핵심 요약:
- 회전 세션은 요청마다 새 IP, 고정 세션은 TTL 동안 동일 IP — 워크플로우의 상태 의존성에 따라 선택.
- ProxyHat은 사용자 이름 토큰(
-session-abc123,-country-US)으로 세션을 제어 — 추가 API 호출 불필요.- 로그인, CSRF, 장바구니, 페이지네이션은 IP 기반 상태 검증을 하므로 고정 세션 필수.
- 429/403 발생 시 세션 ID를 재생성하여 새 IP로 전환 — 차단된 IP 재사용 금지.
- 대량 공개 데이터 수집에는 회전 세션이 더 효율적 — IP당 요청 밀도 최소화.
- robots.txt, ToS, GDPR/CCPA 준수는 법적 필수 사항 — 기술적 가능성 ≠ 법적 허용.
자세한 연동 방법은 ProxyHat 문서를 참조하세요. 세션 제어, 지역 타겟팅, 인증 방식에 대한 전체 API 레퍼런스가 제공됩니다.
