프록시를 통한 병렬 및 순차적 요청: 차단 없이 방법 선택하기

마켓플레이스 파싱, 소셜 미디어 자동화 또는 API를 통한 데이터 수집 시 요청 전송 전략을 올바르게 선택하는 것이 매우 중요합니다. 잘못된 설정은 IP 차단, CAPTCHA 및 시간 낭비로 이어질 수 있습니다. 이 가이드에서는 최대 속도를 위해 병렬 요청을 사용할 때와 보안을 위해 순차 요청을 사용할 때를 살펴보겠습니다.

병렬 요청과 순차 요청의 차이

순차 요청은 스크립트나 프로그램이 요청을 하나씩 전송하는 것입니다: 첫 번째 요청의 응답을 기다린 후에야 두 번째 요청을 보냅니다. 이는 느리지만 안전하며 대상 사이트에 최대한 자연스럽게 보입니다.

병렬 요청은 여러 요청(5, 10, 50 또는 심지어 수백 개)을 동시에 전송하는 것입니다. 이전 요청의 응답을 기다리지 않습니다. 이는 훨씬 빠르지만 서버에 부담을 주고 안티프로드 시스템의 의심을 받을 수 있습니다.

예를 들어, Wildberries에서 10,000개의 상품 가격을 파싱한다고 가정해 보세요. 요청 사이에 2초의 지연을 두고 순차적으로 진행하면 20,000초 또는 5.5시간이 걸립니다. 20개의 병렬 흐름을 실행하면 단 16분이 걸립니다. 차이는 분명하지만 몇 가지 주의할 점이 있습니다.

방법 비교

병렬 요청을 사용할 때

병렬 요청은 속도가 중요하고 데이터 양이 클 때 선택해야 합니다. 그러나 올바른 프록시 설정과 부하 제어가 필요하다는 것을 이해하는 것이 중요합니다.

병렬 요청을 위한 이상적인 시나리오

1. 대규모 카탈로그가 있는 마켓플레이스 파싱
Wildberries 또는 Ozon에서 50,000개의 상품 가격을 수집해야 하는 경우, 순차적 파싱은 며칠이 걸릴 수 있습니다. 20-30개의 병렬 흐름과 데이터 센터 프록시를 사용하면 몇 시간 안에 작업을 완료할 수 있습니다.

설정: 20-30개의 흐름, 각각 개별 IP, 흐름 내 요청 간 1-3초의 지연. 100-200 요청마다 IP를 회전합니다.

2. 공개 API에서 데이터 수집
많은 API(예: 날씨 서비스, 기업 데이터베이스, 지리 위치 서비스)는 하나의 IP에서 요청 수에 제한을 두고 있습니다: 하루에 100-1000개. 프록시 풀을 통한 병렬 요청은 이러한 제한을 우회할 수 있습니다.

예시: 10,000개 기업에 대한 데이터를 API를 통해 수집해야 합니다. 제한은 IP당 500 요청/일입니다. 20개의 프록시를 병렬로 사용하면 = 하루에 10,000 요청을 수행할 수 있어 20일이 아닌 하루에 완료됩니다.

3. 리소스 가용성 확인
웹사이트의 가용성을 확인하거나 미러의 작동을 확인하거나 서버 상태를 모니터링하는 경우 — 병렬 요청은 시간을 절약합니다. 여기서는 사람 행동을 모방할 필요가 없으며 속도만 중요합니다.

4. 대량 프록시 확인
대량의 프록시 풀(1000개 이상의 IP)을 구매할 때는 신속하게 작동 여부, 속도 및 지리적 위치를 확인해야 합니다. 순차적 검사는 몇 시간이 걸리지만 병렬 검사는 몇 분이면 충분합니다.

병렬 요청을 위한 주요 요구 사항

• 대규모 프록시 풀 (최소 10-20 IP, 50-100+이상 권장)
• 오류 발생 시 IP 자동 회전
• 동시 흐름 수 제어 (50-100개 이하)
• 흐름 내 요청 간 지연 (0.5-2초)
• 차단 원인 분석을 위한 오류 로그 기록
• 타임아웃 시 재시도 시스템

순차 요청을 사용할 때

순차 요청은 속도보다 안전성과 신뢰성을 선택하는 것입니다. 이는 실제 사용자 행동을 모방하고 보호된 플랫폼에서 차단 위험을 최소화합니다.

순차 요청을 위한 필수 시나리오

1. 광고 계정 작업
Facebook Ads, TikTok Ads, Google Ads는 IP뿐만 아니라 행동 패턴도 추적합니다. 하나의 계정에서 병렬 요청을 하면 즉시 의심을 받을 수 있습니다. 하나의 계정 = 하나의 흐름 = 5-15초의 지연을 두고 순차적인 작업.

예시: Dolphin Anty의 안티탐지 브라우저를 통해 20개의 Facebook 광고 계정을 관리합니다. 각 계정은 모바일 프록시가 있는 개별 프로필에서 작동하며, 작업은 엄격히 순차적으로 진행됩니다: 로그인 → 통계 확인 → 입찰 조정 → 로그아웃. 작업 간 7-12초의 지연이 있습니다.

2. 소셜 미디어에서의 작업 자동화
Instagram, TikTok, VK는 좋아요, 팔로우, 댓글에 대해 엄격한 행동 제한이 있습니다. 제한 초과 또는 너무 빠른 행동 = 섀도우밴 또는 완전 차단. 오직 순차 요청만으로 20-60초의 무작위 지연을 두어야 합니다.

Instagram 설정: 하나의 계정은 최대 60개의 좋아요를 할 수 있습니다. 이는 1분에 1개의 좋아요로 45-75초의 지연이 필요합니다 (무작위화가 중요합니다!). 각 계정에 대해 개별 프록시를 사용합니다.

3. 개인 계정에서의 인증 및 작업
계정 로그인(이메일 서비스, 은행, 판매자로서의 마켓플레이스 등)이 필요한 모든 작업은 순차적으로 수행해야 합니다. 여러 IP에서 동일한 계정으로 병렬 로그인 시도는 차단으로 이어질 수 있습니다.

4. 강력한 안티봇 보호가 있는 사이트
Cloudflare, Akamai, PerimeterX가 있는 플랫폼은 요청 빈도뿐만 아니라 패턴도 분석합니다. 하나의 IP 또는 User-Agent에서 동시에 10개의 요청이 들어오면 이는 명백한 봇의 징후입니다. 3-10초의 지연이 있는 순차 요청은 자연스럽게 보입니다.

5. 소량 데이터
50-100페이지를 파싱해야 하는 경우, 순차적 파싱과 병렬 파싱 간의 시간 차이는 미미합니다 (5분 대 1분). 그러나 순차 방법은 문제 발생을 보장합니다.

순차 요청을 위한 올바른 지연

다양한 방법에 따른 차단 위험

위험을 이해하면 올바른 전략을 선택하고 보호를 설정하는 데 도움이 됩니다. 차단은 요청 빈도뿐만 아니라 패턴 때문에 발생합니다.

안티프로드 시스템이 추적하는 것

1. 하나의 IP에서의 요청 빈도
하나의 IP에서 분당 100개의 요청이 들어오면 — 이는 명백한 봇입니다. 제한은 다릅니다: 일반 사이트는 분당 10-30개의 요청을 허용하고, 보호된 플랫폼은 분당 2-5개의 요청을 허용합니다.

병렬 요청을 위한 해결책: 요청을 대규모 IP 풀에 분산시킵니다. 예를 들어, 분당 1000개의 요청 = 50개의 IP에서 각각 20개의 요청을 보냅니다. 이는 50명의 일반 사용자가 요청하는 것처럼 보입니다.

2. 요청 간 동일한 간격
요청이 정확히 2.00초마다 이루어지면 — 이는 자동화의 징후입니다. 사람은 다양한 간격으로 클릭합니다: 1.8초, 3.2초, 2.1초 등.

해결책: 기본 지연의 ±30-50%를 무작위화합니다. 고정된 5초 대신 random(3.5, 7.5)를 사용하세요.

3. 사용자 행동의 전형적인 부재
실제 사용자는 상품 페이지로 바로 가지 않습니다 — 먼저 메인 페이지에 들어가고, 카테고리를 검색하고, 상품을 클릭합니다. 봇은 즉시 특정 URL을 요청합니다.

중요한 플랫폼을 위한 해결책: 사용자 전체 경로를 모방하세요. 상품 파싱 전에 2-3개의 요청을 하세요: 메인 → 카테고리 → 상품. 이는 작업을 느리게 하지만 차단 위험을 70-80% 줄입니다.

4. 의심스러운 User-Agent 및 헤더
구식 User-Agent(예: 2024년에 Chrome 95), Accept-Language, Referer 헤더의 부재는 봇의 징후입니다.

해결책: 최신 User-Agent(Chrome 120+, Firefox 120+)를 사용하고, 실제 브라우저와 같은 전체 헤더 세트를 추가하세요. User-Agent를 IP와 함께 회전시킵니다.

차단 위험 비교

각 방법에 적합한 프록시

프록시 유형은 병렬 요청 또는 순차 요청을 사용할 수 있는 가능성에 직접적인 영향을 미칩니다. 잘못된 선택은 차단이나 과도한 비용으로 이어질 수 있습니다.

병렬 요청을 위한 프록시

데이터 센터 프록시는 대량 파싱 및 병렬 요청에 최적의 선택입니다. 저렴하며 (IP당 월 $1-3), 빠르며 (핑 20-50ms) 대량으로 제공됩니다. 단점은 쉽게 프록시로 식별되므로 보호된 플랫폼에는 적합하지 않습니다.

사용 시기: 마켓플레이스 파싱, 공개 출처에서 데이터 수집, 리소스 가용성 확인, 강력한 보호가 없는 서비스에 대한 대량 API 요청.

설정: 50-100개의 IP 풀을 구매하고, 20-30개의 병렬 흐름을 설정하며, 각 흐름은 자신의 IP를 사용합니다. 100-200 요청마다 또는 오류 발생 시 IP를 회전합니다.

레지던트 프록시는 더 비싸지만 (GB당 $3-7) 실제 사용자처럼 보입니다. 속도가 필요하지만 주의해서 사용해야 하는 보호된 플랫폼에 대한 병렬 요청에 적합합니다.

사용 시기: 소셜 미디어 파싱(인증 없이), Cloudflare가 있는 사이트에서 데이터 수집, 데이터 센터를 차단하는 플랫폼에서 작업. 병렬 요청을 위해서는 자동 회전이 가능한 대규모 IP 풀이 필요합니다.

중요: 레지던트 프록시를 통한 병렬 요청 시 트래픽 소비를 모니터링하세요. 10,000 요청은 5-10GB를 소모할 수 있으며, 이는 $20-50의 비용이 발생할 수 있습니다. 데이터 센터는 더 저렴하며: 100 IP당 월 $100-200의 무제한 트래픽.

순차 요청을 위한 프록시

모바일 프록시는 보호된 플랫폼에서 작업할 때 가장 신뢰할 수 있는 유형입니다. IP는 실제 모바일 장치(4G/5G 운영자)처럼 보이므로 차단 위험을 최소화합니다. 단점은 비쌉니다 (IP당 월 $50-150).

사용 시기: Facebook Ads, Instagram, TikTok, Google Ads — 최대한의 안전성과 실제 사용자 행동을 모방해야 하는 모든 곳. 하나의 계정 = 하나의 모바일 프록시 = 순차적인 작업.

설정: 각 광고 계정 또는 소셜 미디어 계정은 개별 모바일 IP에 연결됩니다. 작업은 10-60초의 지연을 두고 엄격히 순차적으로 진행됩니다. IP는 회전하지 않습니다 (하나의 계정은 항상 동일한 IP에서 작업합니다).

레지던트 프록시는 예산이 제한된 경우 모바일 프록시의 좋은 대안입니다. 덜 중요한 작업에 적합합니다: 인증이 필요한 파싱, SMM 자동화, 판매자로서의 마켓플레이스 작업.

사용 시기: 마켓플레이스 계정 관리(Wildberries, Ozon 판매자로서), 소셜 미디어에서의 게시물 자동화(대량이 아닌), 인증이 필요한 데이터 파싱.

프록시 선택에 대한 권장 사항

최적의 설정: 지연, 흐름, 타임아웃

매개변수의 올바른 설정은 속도와 안전성 간의 균형을 유지하는 데 중요합니다. 너무 공격적인 설정은 차단으로 이어지고, 너무 조심스러운 설정은 시간 낭비로 이어질 수 있습니다.

병렬 요청 설정

동시 흐름 수 (concurrency)
이는 핵심 매개변수입니다. 너무 많은 흐름은 프록시와 대상 서버에 과부하를 주고, 너무 적은 흐름은 속도를 낮춥니다.

권장 사항:

• 마켓플레이스 파싱: 50개 이상의 프록시 풀에서 20-50개의 흐름
• 공개 API: 10-30개의 흐름, API 제한에 따라 조정
• 보호된 사이트: 5-15개의 흐름, 그 이상은 차단 위험
• 프록시 확인: 50-100개의 흐름 (여기서는 속도가 더 중요함)

흐름 내 지연
병렬 작업을 하더라도 각 흐름은 요청 간에 일시 중지를 해야 합니다. 이는 하나의 IP에 대한 부하를 줄이고 차단 위험을 감소시킵니다.

권장 사항:

• 일반 사이트: 하나의 흐름 내 요청 간 0.5-2초
• 마켓플레이스: ±30%의 무작위화가 있는 1-3초
• Cloudflare가 있는 사이트: ±40%의 무작위화가 있는 2-5초
• 제한이 있는 API: 제한에 따라 계산 (예: 100 요청/분 = 0.6초/요청, 여유를 두어 1초로 설정)

타임아웃 (timeout)
서버의 응답을 기다리는 시간입니다. 너무 짧은 타임아웃은 느린 응답으로 인해 데이터 손실을 초래할 수 있습니다. 너무 긴 타임아웃은 흐름을 멈추게 합니다.

권장 사항:

• 빠른 사이트: 10-15초
• 느린 사이트/API: 20-30초
• 레지던트 프록시를 통한 요청: +5-10초 (데이터 센터보다 느림)
• 연결 타임아웃: 5-10초 (연결 설정 시간)

재시도 (retry)
오류 발생 시(타임아웃, 503, 프록시 차단) 다른 IP로 요청을 반복해야 합니다. 재시도가 없으면 일부 데이터를 잃게 됩니다.

설정: 요청당 2-3회의 시도, 각 실패 시 프록시 변경, 재시도 전 3-5초의 일시 중지.

순차 요청 설정

요청 간 기본 지연
플랫폼과 작업 유형에 따라 다릅니다. 주요 규칙은 실제 사용자를 모방하는 것입니다.

플랫폼별 권장 사항:

• Facebook Ads (계정 간 이동): 7-15초
• Instagram (좋아요): 45-90초, 최대 60 좋아요/시간
• Instagram (팔로우): 60-120초, 최대 30 팔로우/시간
• TikTok (조회수): 30-60초
• 인증이 필요한 파싱: 3-7초
• 마켓플레이스 (판매자 계정 내 작업): 5-10초

무작위화
모든 순차 요청에 필수입니다. 기본 지연의 ±30-50%를 사용하세요.

예시: 기본 지연이 10초인 경우, 무작위화 ±40% → 실제 지연은 6-14초가 됩니다 (매번 무작위 값).

타임아웃
순차 요청의 경우, 모든 흐름이 차단될 위험이 없으므로 더 긴 타임아웃을 사용할 수 있습니다.

권장 사항: 보호된 플랫폼(Facebook, Instagram)의 경우 30-60초, 일반 사이트의 경우 15-30초.

두 방법을 구현하기 위한 도구

도구 선택은 작업과 기술적 능력에 따라 다릅니다. 비즈니스 작업(중재, SMM, 전자상거래)에는 코드 없이 사용할 수 있는 솔루션을 사용하세요. 기술적 작업에는 라이브러리와 프레임워크를 사용하세요.

코드 없는 비즈니스 솔루션

다중 계정 작업을 위한 안티탐지 브라우저
광고 계정이나 소셜 미디어와 작업할 때 안티탐지 브라우저는 산업 표준입니다. 이들은 자동으로 프록시, 브라우저 지문을 관리하고 계정을 격리합니다.

인기 있는 솔루션:

• Dolphin Anty: Facebook/TikTok 중재자를 위한 리더, 10개 프로필에 대한 무료 요금제, 프록시 설정이 간단함
• AdsPower: 전자상거래에 적합(Amazon, eBay), 코드 없이 RPA를 통한 자동화 제공
• Multilogin: 가장 비쌈 ($100+/월), 그러나 심각한 중재를 위한 최대 보호 제공
• GoLogin: 예산 친화적인 대안 ($25/월), SMM 및 소규모 팀에 적합

프록시와의 작동 방식: 브라우저 프로필을 생성 → 프록시 연결 → 이 프로필 내의 모든 작업은 이 IP를 통해 진행됩니다. 하나의 프로필 = 하나의 계정 = 순차적인 작업. 병렬 작업을 위해 여러 프로필을 동시에 열 수 있습니다 (각각 자신의 프록시와 함께).

파서 및 스크래퍼 (기성품)
마켓플레이스 및 웹사이트에서 데이터를 수집하기 위한 기성 도구가 존재하며, 프로그래밍이 필요하지 않습니다.

• Octoparse: 시각적 파서 생성기, 프록시 지원, 인터페이스를 통해 병렬 흐름 설정 가능
• ParseHub: Octoparse의 유사 제품, 200페이지에 대한 무료 요금제, GUI를 통한 지연 설정
• Scrapy Cloud: Scrapy 스파이더를 실행하기 위한 클라우드 서비스 (최소한의 Python 지식 필요)

SMM 자동화 (코드 없음)
소셜 미디어 관리를 위한 인터페이스를 통한 자동화 서비스가 있습니다.

• Jarvee: Instagram, TikTok, Twitter 자동화, 프록시 지원 내장, GUI를 통한 지연 설정 (주의: 공격적인 자동화는 차단으로 이어질 수 있음)
• Ingramer (Inflact): 안전한 Instagram 자동화, 그들의 프록시를 통해 작동
• Combin: Instagram에서의 타겟팅된 팔로우/좋아요, 외부 프록시 지원

개발자를 위한 기술 도구

파싱 또는 자동화를 위한 스크립트를 작성하는 경우, 검증된 라이브러리를 사용하세요.

Python (파싱에 가장 인기 있는 언어):

• Requests + threading/asyncio: 간단한 병렬 요청을 위한, 프록시 설정이 쉬움
• aiohttp: 고속 병렬 요청을 위한 비동기 라이브러리 (1000개 이상 동시)
• Scrapy: 파싱 프레임워크, 프록시 회전 지원 내장, 지연을 위한 미들웨어
• Selenium: JavaScript가 있는 사이트를 위한, 느리지만 많은 보호를 우회함
• Playwright: Selenium의 현대적인 대안, 더 빠르고 편리함

JavaScript/Node.js:

• Axios: HTTP 요청을 위한 인기 있는 라이브러리, 프록시 설정이 간단함
• Puppeteer: Chrome을 제어하기 위한 고급 라이브러리, 웹 스크래핑에 유용함