Wildberries와 Ozon의 판매자들은 종종 프록시 예산을 "눈대중"으로 설정하여 3-4배 비싸게 지불하거나, 일주일 만에 소진되는 너무 저렴한 패키지를 구매합니다. 월 10,000개 상품 모니터링을 위한 트래픽 양을 올바르게 계산하는 방법, 이러한 부하에 적합한 프록시 유형 선택 및 데이터 품질 저하 없이 절약할 수 있는 방법을 살펴보겠습니다.
왜 10,000개 상품을 모니터링해야 하는가, 100개가 아닌
100-200개의 상품이 있다면 경쟁업체의 가격을 하루에 한 번 수동으로 확인할 수 있습니다. 하지만 카탈로그가 수천 개의 SKU로 증가하고, 경쟁업체들이 하루에 5-10번 가격을 변경할 때 (특히 Wildberries와 Ozon의 프로모션 기간 동안), 수동 모니터링은 허구가 됩니다 — 데이터가 수집되는 것보다 더 빨리 구식이 됩니다.
10,000개 상품은 여러 카테고리를 가진 중간 규모의 판매자나 5-10명의 고객을 동시에 모니터링하는 에이전시의 전형적인 양입니다. 이러한 규모에는 자동화가 필요합니다: 상품 카드, 카테고리 페이지 및 마켓플레이스 API에 수십만 번의 요청을 보내는 스크립트나 준비된 파싱 서비스가 필요합니다. 그리고 여기서 가장 중요한 질문이 발생합니다 — 이러한 요청을 어떤 경로로 보내야 IP 차단을 두 번째 작업 시간에 받지 않을 수 있을까요?
Wildberries, Ozon 및 Avito는 파싱에 대해 적극적으로 방어합니다: CAPTCHA를 설정하고 응답 속도를 제한하며 데이터센터 IP를 대량으로 차단합니다. 따라서 모니터링 예산은 서버 및 개발 비용뿐만 아니라 프록시에 대한 별도의 비용 항목이기도 하며, 종종 "눈대중"으로 계산할 경우 가장 예측할 수 없는 항목입니다.
한 달에 실제로 필요한 요청 수
예산 계산의 첫 번째 단계는 물리적으로 얼마나 많은 HTTP 요청을 해야 하는지를 이해하는 것입니다. 이는 모니터링 전략에 설정한 가격 업데이트 빈도에 따라 달라집니다.
| 업데이트 빈도 | 상품 1개당 요청 수 (한 달) | 10,000개 상품 요청 수 |
|---|---|---|
| 하루 1회 | 30 | 300,000 |
| 하루 4회 | 120 | 1,200,000 |
| 시간당 1회 (하루 24회) | 720 | 7,200,000 |
대부분의 Wildberries와 Ozon 판매자에게는 하루 4-6회의 업데이트가 충분합니다 — 이는 아침과 저녁의 가격 전쟁을 커버하면서 프록시 풀에 과도한 부담을 주지 않습니다. 매시간 모니터링은 전자기기, 화장품과 같은 고경쟁 분야에서만 대규모 프로모션 기간 동안 필요합니다.
트래픽 계산 공식
프록시가 "소모하는" 트래픽은 요청 수뿐만 아니라 무엇을 파싱하는지에 따라 달라집니다: 상품 카드 전체 (이미지 및 스크립트가 포함된 HTML 페이지) 또는 마켓플레이스 API의 JSON 응답만.
공식:
트래픽 (GB) = 요청 수 × 평균 응답 크기 (KB) / 1,048,576
평균 응답 크기는 방법에 따라 크게 다릅니다:
- 상품 카드 API 요청 (JSON) — 응답당 15-60 KB
- 상품 카드의 전체 HTML 페이지 — 응답당 300-900 KB
- 페이지 카테고리/검색 및 페이지네이션 — 응답당 500-1500 KB
마켓플레이스의 내부 API를 통해 직접 파싱하는 경우 (이 방법이 더 바람직함 — 무게가 적고 속도가 빠르며 CAPTCHA 위험이 낮음), 10,000개 상품에 대해 하루 4회의 업데이트를 하면 1,200,000 요청 × 40 KB ≈ 45.8 GB의 월간 트래픽을 얻습니다. 전체 HTML 페이지를 파싱하면 같은 요청 수가 600-900 GB의 "무게"를 가지게 되며, 데이터 수집 방법에 따라 15-20배의 차이가 발생합니다.
데이터센터, 주거용 및 모바일 프록시: 무엇을 선택해야 할까
프록시 유형은 비용과 성공적인 요청 비율(success rate)에 직접적인 영향을 미칩니다. 마켓플레이스 모니터링에 있어 이는 매우 중요합니다: 프록시가 차단될수록 재시도 횟수가 늘어나고, 계산된 공식 이상의 실제 트래픽 소비가 증가합니다.
| 프록시 유형 | WB/Ozon에서의 성공률 | 언제 사용해야 하는가 |
|---|---|---|
| 데이터센터 프록시 | 40-60% (대량으로 쉽게 차단됨) | 저빈도 모니터링, 테스트 실행, 소규모 카탈로그 |
| 주거용 프록시 | 85-95% | 10,000개 이상의 상품에 대한 주요 옵션, 일일 모니터링 |
| 모바일 프록시 | 90-98% | 강력한 분야에서의 고빈도 모니터링, 강화된 보호 우회 |
데이터센터 프록시는 GB당 가격이 유리해 보이지만, 실제로 Wildberries와 Ozon에서는 활성 파싱 몇 시간 후에 성공률이 떨어집니다 — 마켓플레이스는 호스팅 제공자의 IP 주소 범위를 계산하고 대량으로 접근을 차단합니다. 결국, 재시도에 소비되는 트래픽에 대해 비용을 지불하게 됩니다.
주거용 프록시는 실제 가정 사용자의 IP를 사용하므로 마켓플레이스에서 일반 방문자로 인식됩니다. 10,000개 상품에 대한 안정적인 모니터링을 위해서는 가격과 신뢰성의 최적 균형을 제공합니다. 모바일 프록시는 성공률을 더욱 높여주지만 일반적으로 더 비쌉니다 — 문제 있는 카테고리나 프로모션의 피크 기간에만 선택적으로 연결하는 것이 합리적입니다.
예산 계산의 세 가지 시나리오
10,000개 상품 모니터링의 세 가지 전형적인 시나리오를 살펴보아, 데이터 수집 방법과 업데이트 빈도가 최종 트래픽 양에 미치는 영향을 보여주겠습니다.
시나리오 1: API를 통한 절약형 모니터링
하루 4회 업데이트, 마켓플레이스 내부 API를 통한 파싱 (JSON, 응답당 ~40 KB), 성공률 90%의 주거용 프록시.
- 기본 요청: 월 1,200,000
- 10% 재시도 고려: 1,320,000 요청
- 트래픽: 1,320,000 × 40 KB ≈ 50.4 GB 월간
시나리오 2: HTML 페이지 수집을 통한 평균 부하
하루 6회 업데이트, 가격뿐만 아니라 재고, 리뷰, 검색 위치를 얻기 위해 전체 상품 카드 파싱 (HTML, 응답당 ~500 KB).
- 기본 요청: 월 1,800,000
- 재시도 고려 (15%): 2,070,000 요청
- 트래픽: 2,070,000 × 500 KB ≈ 987 GB 월간
시나리오 3: 피크 시즌의 고빈도 모니터링
API를 통한 매시간 업데이트 (하루 24회), 검색 결과 위치 추적을 위한 카테고리 페이지 추가 파싱, 문제 있는 카테고리를 위한 모바일 프록시.
- 상품 요청: 월 7,200,000 (응답당 40 KB)
- 카테고리 페이지 요청: 월 300,000 (응답당 800 KB)
- 트래픽: (7,200,000 × 40 KB) + (300,000 × 800 KB) ≈ 274.7 + 228.9 ≈ 503.6 GB 월간
시나리오 간의 차이는 데이터 수집 방법이 업데이트 빈도보다 예산에 더 큰 영향을 미친다는 것을 명확히 보여줍니다. HTML 파싱에서 API 작업으로 전환하면 동일한 상품 수와 동일한 확인 빈도로 트래픽 소비를 10-20배 줄일 수 있습니다.
데이터 손실 없이 트래픽 소비 줄이는 방법
예산을 통제하면서 데이터의 최신성을 유지할 수 있는 몇 가지 실용적인 방법이 있습니다.
- HTML이 아닌 API를 파싱하세요. 마켓플레이스가 내부 API를 통해 데이터를 제공하는 경우 (상품 카드 열 때 브라우저의 네트워크 요청을 분석하여 확인 가능), 반드시 이를 사용하세요 — 응답의 무게가 10-20배 줄어듭니다.
- 상품을 우선순위에 따라 나누세요. 모든 10,000개의 SKU가 동일하게 중요한 것은 아닙니다. 경쟁이 치열한 상품은 매시간 모니터링하고, 나머지는 하루에 1-2회 모니터링하세요. 이는 전체 요청 수를 40-60% 줄입니다.
- 정적 데이터를 캐시하세요. 상품의 이름, 설명, 특성은 드물게 변경되므로 주 1회만 수집하면 됩니다. 가격과 재고만 매시간 업데이트하면 됩니다.
- 프록시 회전을 합리적으로 설정하세요. 각 요청마다 IP를 너무 자주 변경하면 CAPTCHA와 재시도 횟수가 증가합니다. 하나의 IP에서 5-10회 요청 후 회전하는 것이 일반적으로 익명성과 성공률 간의 더 나은 균형을 제공합니다.
-
gzip을 통해 트래픽을 압축하세요. 스크립트나 파싱 서비스가
Accept-Encoding: gzip헤더를 전송하는지 확인하세요 — 이는 JSON 응답의 무게를 60-70% 줄입니다.
예산 계산 시 자주 발생하는 오류
10,000개 상품 모니터링 예산을 계획할 때 판매자들은 종종 같은 오류를 범하여 과다 지출하거나 반대로 월 중반에 트래픽이 부족해지는 경우가 발생합니다.
- 재시도를 고려하지 않음. 데이터센터 프록시를 사용할 경우 요청의 40-50%가 CAPTCHA나 차단으로 끝날 수 있습니다 — 실제 트래픽 소비가 계산된 것보다 1.5-2배 높아집니다.
- 모든 것을 동일한 빈도로 모니터링함. 10,000개 상품이 "혹시라도" 매시간 업데이트되면 예산이 실제로 비즈니스에 도움이 되지 않고 몇 배로 증가합니다.
- 계절성을 잊음. 세일 기간 (11.11, 블랙 프라이데이, 새해)에는 경쟁업체들이 가격을 더 자주 변경하며, 이로 인해 마켓플레이스의 파싱 방어가 강화되어 재요청 수가 증가합니다.
- 예산을 계산할 때 여유를 두지 않음. 페이지 구조 변경이나 일시적인 CAPTCHA 증가에 대비하여 계산된 트래픽 양의 20-30% 여유를 두는 것이 합리적입니다.
모니터링 시작 전 체크리스트
- 다양한 상품 그룹에 대한 가격 업데이트 빈도를 결정했습니다 (VIP / 일반 / 낮은 우선순위)
- HTML 페이지 대신 마켓플레이스 API를 통해 파싱할 수 있는지 확인했습니다
- “요청 수 × 응답 크기” 공식을 통해 기본 트래픽 양을 계산했습니다
- 재시도 및 CAPTCHA를 고려하여 20-30% 여유를 추가했습니다
- 주요 양에 대한 주거용 프록시, 문제 있는 카테고리에 대한 모바일 프록시를 선택했습니다
- IP 회전을 합리적으로 설정했습니다 (각 요청마다가 아니라 5-10회 요청마다)
- 응답의 무게를 줄이기 위해 요청에서 gzip 압축을 활성화했습니다
- 프로모션 및 세일의 피크 기간에 대한 추가 예산을 책정했습니다
결론
월 10,000개 상품 모니터링 예산은 고정된 숫자가 아니라 구체적인 결정의 결과입니다: 가격을 얼마나 자주 업데이트할지, 데이터를 어떤 경로로 파싱할지, 어떤 유형의 프록시를 사용할지를 결정합니다. "요청 수 × 응답 크기" 공식을 통한 올바른 트래픽 계산은 재시도에 대한 여유를 고려하여 실제 모니터링 비용을 미리 이해하고 월 중반에 불쾌한 놀라움을 피할 수 있게 해줍니다.
Wildberries, Ozon 및 Avito의 안정적인 모니터링을 위해 평균 및 대규모 예산에서는 주거용 프록시를 시작하는 것이 좋습니다 — 이는 합리적인 트래픽 비용으로 높은 성공률을 제공합니다. 특정 상품 카테고리가 마켓플레이스의 강화된 보호에 해당하는 경우, 전체 카탈로그가 아닌 문제 있는 카테고리에 대해 모바일 프록시를 선택적으로 연결하여 데이터 품질 저하 없이 예산을 통제할 수 있습니다.