마켓플레이스 파싱, 경쟁사 가격 모니터링 또는 소셜 미디어 자동화 작업을 수행하는 경우, 429 Too Many Requests 오류를 경험했을 것입니다. 사이트는 귀하의 요청을 의심스러운 것으로 간주하여 차단하며, 모든 자동화가 중단됩니다. 이 기사에서는 이 문제가 발생하는 이유와 올바른 프록시 설정, IP 회전 및 부하 분산을 통해 이를 해결하는 방법을 설명합니다.
우리는 Wildberries 및 Ozon 파싱, 경쟁사 모니터링, 소셜 미디어 API 작업, 대량 데이터 수집 등 다양한 작업에 대한 구체적인 솔루션을 보여줄 것입니다. 모든 권장 사항은 실무 경험에 기반하며 실제 프로젝트에서 효과가 있습니다.
429 Too Many Requests 오류란 무엇이며 왜 발생하는가
429 Too Many Requests 오류는 서버가 특정 시간 동안 허용된 요청 수를 초과할 때 반환하는 HTTP 응답 코드입니다. 이는 사이트가 과부하 및 자동화된 데이터 수집으로부터 보호하기 위한 메커니즘입니다.
429 오류가 발생하는 일반적인 상황은 다음과 같습니다:
- 마켓플레이스 파싱 — Wildberries, Ozon 또는 Avito에서 가격을 수집할 때 분당 수백 개의 요청을 보냅니다. 사이트는 하나의 IP에서 비정상적인 활동을 감지하고 차단합니다.
- 경쟁사 모니터링 — 제품, 가격, 재고에 대한 자동 데이터 수집. 빈번한 확인 시 제한이 작동합니다.
- API 작업 — 많은 API는 엄격한 제한이 있습니다: 예를 들어, Instagram API는 시간당 200개의 요청을 허용하고, Twitter는 15분당 300개의 요청을 허용합니다.
- 대량 등록 또는 작업 — 계정 생성, 메시지 전송, 좋아요. 플랫폼은 자동화를 빠르게 감지하고 IP를 차단합니다.
중요한 점은: 429 오류는 단순한 기술적 제한이 아닙니다. 이는 사이트가 귀하의 활동을 의심스러운 것으로 인식했다는 신호입니다. 동일한 IP에서 계속 공격하면 영구적인 차단을 받을 수 있습니다.
중요: 일부 사이트는 429 대신 403 Forbidden을 반환하거나 단순히 CAPTCHA를 표시합니다. 본질은 동일합니다 — 귀하는 제한을 초과하였고 차단되었습니다.
사이트가 의심스러운 활동을 어떻게 감지하는가
차단을 효과적으로 우회하려면 사이트가 귀하를 어떻게 감지하는지 이해해야 합니다. 현대의 보안 시스템은 여러 매개변수를 분석합니다:
1. IP 주소 및 요청 빈도
가장 명백한 매개변수입니다. 하나의 IP에서 분당 100개의 요청이 들어오고 일반 사용자가 5-10개를 보내는 경우 — 이는 명백한 자동화입니다. 사이트는 제한을 설정합니다:
- Wildberries: 하나의 IP에서 분당 약 60개의 요청
- Ozon: 분당 약 30-40개의 요청
- Avito: 검색 요청에 대해 엄격한 제한
- Instagram API: 애플리케이션당 시간당 200개의 요청
2. User-Agent 및 브라우저 헤더
스크립트를 통해 올바른 User-Agent 없이 요청을 보내면 사이트는 즉시 이것이 실제 브라우저가 아님을 이해합니다. 또한 Accept, Accept-Language, Referer 헤더가 분석됩니다. 이러한 헤더가 없거나 비정상적인 값이 있을 경우 — 이는 빨간 신호입니다.
3. 행동 패턴
실제 사용자는 매 2초마다 완벽한 주기로 요청을 하지 않습니다. 그는 스크롤하고 클릭하며 잠시 멈춥니다. 만약 귀하의 파서가 메트로놈처럼 작동한다면 — 이는 의심스럽습니다.
4. IP 주소 유형
많은 플랫폼은 데이터 센터 IP를 블랙리스트에 올립니다. AWS나 Google Cloud의 저렴한 프록시를 사용하는 경우 차단될 확률이 높습니다. 실제 공급자의 주거 IP는 의심을 덜 받습니다.
프록시 회전: 제한 우회의 주요 방법
429 문제의 주요 해결책은 IP 주소 회전입니다. 모든 요청을 하나의 IP에서 보내는 대신, 여러 주소 간에 부하를 분산합니다. 각 IP는 소량의 요청을 보내고 제한을 초과하지 않습니다.
프록시 회전 유형
| 회전 유형 | 작동 방식 | 언제 사용해야 하는가 |
|---|---|---|
| 요청별 회전 | 각 요청은 새로운 IP에서 진행됩니다. 프록시 제공업체가 주소를 자동으로 변경합니다. | 대량 파싱, 많은 데이터를 빠르게 수집해야 할 때 |
| 타이머별 회전 | IP는 5-30분마다 변경됩니다. 일련의 요청에 대해 하나의 주소를 사용합니다. | 세션이 필요한 사이트 작업 (장바구니, 인증) |
| 정적 프록시 풀 | 100-1000개의 IP 목록이 있습니다. 스크립트는 각 요청에 대해 무작위 주소를 선택합니다. | 회전 및 부하 분산에 대한 완전한 제어가 필요할 때 |
실용적인 예: Wildberries 파싱
예를 들어, 10,000개의 제품 가격을 파싱해야 한다고 가정해 보겠습니다. Wildberries는 하나의 IP에서 분당 60개의 요청 후 차단합니다. 해결 방법은 다음과 같습니다:
- 요청별 회전 사용 — 각 요청은 새로운 IP에서 진행됩니다. 약 167개의 서로 다른 IP가 필요합니다 (10,000 요청 / 분당 60 = 167분, 하나의 IP에서, 그러나 회전으로 10-15분 만에 완료됩니다).
- 지연 설정 — 회전이 있더라도 초당 1,000개의 요청을 보내는 것은 피해야 합니다. 최적: 다양한 IP로 초당 5-10개의 요청.
- 무작위화 추가 — 지연은 무작위여야 합니다: 요청 간 0.5초에서 2초 사이.
이러한 작업에는 주거용 프록시가 이상적입니다. 자동 회전이 가능하며 수백만 개의 IP 풀을 가지고 있어 요청마다 주소를 변경합니다.
요청 간 지연 설정
프록시 회전이 있더라도 사이트에 요청을 최대 속도로 보내서는 안 됩니다. 현대의 보안 시스템은 서버에 대한 전체 부하를 분석하며, DDoS 유사 활동을 감지하면 전체 IP 범위를 차단할 수 있습니다.
지연 설정 규칙
기본 규칙: 실제 사용자를 모방하십시오
- 최소 지연: 요청 간 0.5-1초
- 권장: 무작위 분산으로 1-3초
- 복잡한 사이트(마켓플레이스, 소셜 미디어)의 경우: 2-5초
- 오류 발생 시 지수 지연 사용
지수 지연 (exponential backoff)
만약 429 오류를 받았다면, 사이트를 계속 공격하지 마십시오. 지수 지연 전략을 사용하십시오:
- 첫 번째 시도가 실패 → 1초 대기
- 두 번째 시도가 실패 → 2초 대기
- 세 번째 시도가 실패 → 4초 대기
- 네 번째 시도가 실패 → 8초 대기
- 계속해서 최대치까지 (예: 60초)
이 전략은 서버가 "식을" 시간을 주며, 영구적인 차단 가능성을 줄입니다. 많은 API(구글, 트위터)는 문서에서 이러한 접근 방식을 권장합니다.
다양한 작업에 대한 설정 예시
| 작업 | 요청 간 지연 | 비고 |
|---|---|---|
| Wildberries 파싱 | 1-3초 | 프록시 회전으로 0.5-1초까지 가속 가능 |
| Ozon 파싱 | 2-4초 | Ozon은 자동화에 더 민감함 |
| Instagram API | 18초 | 제한 200 요청/시간 = 1 요청마다 18초 |
| Google 검색 파싱 | 5-10초 | Google은 빠르게 차단하므로 긴 대기 필요 |
| Avito 모니터링 | 3-6초 | 엄격한 보호, 특히 검색에 대해 |
User-Agent 및 헤더: 실제 브라우저 모방
프록시 회전 및 지연은 요청 빈도 문제를 해결하지만, 이것만으로는 충분하지 않습니다. 사이트는 요청을 보내는 방식을 분석합니다. 헤더가 의심스럽게 보이면 차단은 불가피합니다.
브라우저 모방을 위한 필수 헤더
각 요청에 포함되어야 하는 최소한의 헤더 세트:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0User-Agent 회전
모든 요청에 대해 동일한 User-Agent를 사용하지 마십시오. 10-20개의 최신 브라우저 버전 목록을 만들어 무작위로 변경하십시오:
- Chrome (Windows, macOS, Linux)
- Firefox (다양한 버전)
- Safari (macOS, iOS)
- Edge (Windows)
자주 발생하는 오류: 구식 User-Agent 사용 (예: 2024년에 Chrome 90) 또는 데스크탑 사이트에 모바일 User-Agent 사용. 이는 자동화를 즉시 드러냅니다.
Referer 및 Origin
많은 사이트는 요청이 어디서 왔는지 확인합니다. 제품 페이지를 파싱하는 경우, Referer 헤더에는 카탈로그 또는 검색 링크가 있어야 합니다. API를 파싱하는 경우 — 올바른 Origin이 있어야 합니다.
Wildberries 파싱 예시:
Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=노트북
Origin: https://www.wildberries.ru429 우회를 위한 프록시 선택
프록시 유형 선택은 매우 중요합니다. 저렴한 데이터 센터 프록시는 종종 이미 블랙리스트에 올라 있으며, 요청 빈도가 낮더라도 429 오류를 받을 수 있습니다.
제한 우회를 위한 프록시 유형 비교
| 프록시 유형 | 장점 | 단점 | 어떤 작업에 적합한가 |
|---|---|---|---|
| 데이터 센터 | 높은 속도, 저렴한 가격 | 종종 차단됨, 쉽게 감지됨 | 보호가 없는 간단한 사이트 |
| 주거용 | 실제 공급자의 IP, 감지하기 어려움, 큰 주소 풀 | 비쌈, 때때로 느림 | 마켓플레이스, 소셜 미디어, 복잡한 사이트 |
| 모바일 | 모바일 운영자의 IP, 최대 신뢰도 | 비쌈, 제한된 풀 | Instagram, TikTok, Facebook Ads |
선택에 대한 권장 사항
마켓플레이스 파싱(Wildberries, Ozon, Avito)의 경우: 요청별 회전이 가능한 주거용 프록시를 사용하십시오. 풀은 최소 10,000 IP 이상이어야 합니다. 이는 각 IP가 적은 요청을 하여 제한에 걸리지 않도록 보장합니다.
소셜 미디어 API 작업의 경우: 모바일 프록시가 최적의 선택입니다. Instagram 및 TikTok은 모바일 운영자의 IP를 주거용보다 더 신뢰합니다. 하나의 모바일 IP는 문제없이 5-10개의 계정을 처리할 수 있습니다.
경쟁사 가격 모니터링의 경우: 타이머별 회전이 가능한 주거용 프록시(10-15분마다)를 사용하십시오. 이는 하나의 IP로 일련의 요청을 수행하면서 세션을 유지하되, 제한을 초과하지 않도록 합니다.
간단한 작업(뉴스, 블로그 파싱)의 경우: 사이트에 심각한 보호가 없다면 데이터 센터 프록시가 적합할 수 있습니다. 그러나 주기적인 차단에 대비해야 합니다.
실제 사례: 마켓플레이스 및 API 파싱
사례 1: Wildberries 가격 모니터링 (일일 10,000개 제품)
작업: 마켓플레이스 판매자는 10,000개 품목의 경쟁사 가격을 추적합니다. 데이터를 하루에 두 번 수집해야 합니다.
문제: 하나의 IP를 사용하면 50-60개의 요청 후 차단되었습니다. 10,000개 제품을 파싱하는 데 몇 시간이 걸리며 지속적인 차단이 발생했습니다.
해결책:
- 50,000개의 IP 풀과 요청별 회전이 가능한 주거용 프록시를 연결했습니다.
- 요청 간 0.5초에서 2초 사이의 무작위 지연을 설정했습니다.
- User-Agent 회전을 추가했습니다 (Chrome 및 Firefox의 20가지 버전).
- 올바른 Referer 및 Accept 헤더를 설정했습니다.
결과: 10,000개 제품의 파싱이 15-20분 만에 차단 없이 완료됩니다. 각 IP는 최대 1-2개의 요청을 하여 자동화로 감지될 수 없습니다.
사례 2: Instagram 자동화 (고객 50개 계정)
작업: SMM 에이전시는 Instagram에서 고객의 50개 계정을 관리합니다. 콘텐츠를 게시하고, 댓글에 응답하며, 통계를 수집해야 합니다.
문제: Instagram API는 애플리케이션당 시간당 200개의 요청 제한이 있습니다. 50개 계정으로 작업할 경우 제한이 10분 만에 소진되었습니다.
해결책:
- Instagram API의 10개의 서로 다른 애플리케이션을 생성했습니다 (애플리케이션당 5개 계정).
- 각 애플리케이션은 별도의 모바일 프록시를 사용합니다.
- 요청 간 18초의 지연을 설정했습니다 (200 요청/시간 = 1 요청마다 18초).
- 429 오류 발생 시 지수 지연을 추가했습니다.
결과: 모든 50개 계정이 안정적으로 작동합니다. 429 오류는 매우 드물게 발생하며 (주 1-2회) 자동으로 재시도하여 처리됩니다.
사례 3: Avito 파싱 (전국의 광고)
작업: 부동산 집계 사이트는 Avito에서 러시아 전역의 광고를 수집하여 데이터베이스를 만듭니다.
문제: Avito는 러시아 사이트 중 가장 강력한 보호를 가지고 있습니다. 데이터 센터의 서로 다른 IP로도 10-15개의 요청 후 차단이 시작되었습니다.
해결책:
- 지리적으로 연결된 주거용 프록시로 전환했습니다 (파싱하는 도시와 동일한 IP).
- 요청 간 지연을 3-5초로 늘렸습니다.
- 단순 HTTP 요청 대신 headless 브라우저(Puppeteer)를 사용했습니다.
- 사용자 행동을 모방했습니다: 스크롤, 클릭, 마우스 움직임.
결과: 하루에 50,000개 이상의 광고를 성공적으로 파싱합니다. 차단이 95% 감소했습니다. 나머지 5%는 새로운 IP로 재시도하여 처리됩니다.
사례 4: 경쟁사 API 모니터링 (전자상거래)
작업: 온라인 상점은 20개의 경쟁사 API를 통해 제품의 재고 및 가격을 추적합니다.
문제: 대부분의 경쟁사 API는 공개 제한(시간당 100-500 요청)을 가지고 있습니다. 초과 시 429 오류가 반환됩니다.
해결책:
- 우선 순위가 있는 요청 대기를 생성합니다 (가장 중요한 제품은 더 자주 확인됨).
- 응답 헤더(X-RateLimit-Remaining)를 통해 제한을 추적합니다.
- 제한의 80%에 도달하면 자동으로 일시 중지합니다.
- 각 경쟁사에 대해 여러 API 키를 사용합니다 (가능한 경우).
결과: 시스템은 요청을 자동으로 분배하여 제한을 초과하지 않도록 합니다. 데이터는 차단 없이 최대한 자주 업데이트됩니다.
모든 사례에서 얻은 교훈:
429 오류는 종합적으로 해결됩니다: 프록시 회전 + 올바른 지연 + 실제 행동 모방. 하나의 방법에만 의존해서는 안 됩니다. 천 개의 IP가 있어도 의심스러운 헤더로 초당 1,000개의 요청을 보내면 차단됩니다.
결론
429 Too Many Requests 오류는 사이트의 보호 메커니즘으로, 올바른 접근 방식을 통해 우회할 수 있습니다. 문제 해결의 주요 원칙은 다음과 같습니다:
- IP 주소 회전 — 여러 프록시 간에 부하를 분산하여 각 주소가 최소한의 요청을 하도록 하십시오.
- 올바른 지연 — 1초에서 5초 사이의 무작위 간격으로 실제 사용자를 모방하십시오.
- 정확한 헤더 — 최신 User-Agent 및 전체 브라우저 헤더 세트를 사용하십시오.
- 프록시 유형 선택 — 복잡한 사이트(마켓플레이스, 소셜 미디어)의 경우 주거용 또는 모바일 프록시를 사용하십시오.
- 오류 처리 — 429 오류 발생 시 지수 지연을 적용하고 사이트를 재차 공격하지 마십시오.
기억하십시오: 목표는 어떤 대가를 치르더라도 보호를 속이는 것이 아니라, 귀하의 자동화가 최대한 자연스럽게 보이도록 하는 것입니다. 현대의 보안 시스템은 점점 더 스마트해지고 있으며, 무차별적인 공격은 더 이상 통하지 않습니다.
마켓플레이스 파싱, 경쟁사 모니터링 또는 소셜 미디어 자동화를 계획하고 있다면 주거용 프록시를 사용해 보시기 바랍니다. 이들은 대규모 IP 주소 풀을 제공하며, 자동 회전 및 차단 위험을 최소화합니다. Instagram, TikTok 및 기타 모바일 플랫폼 작업에는 실제 통신사 IP를 사용하는 모바일 프록시가 더 적합합니다.