eBay 목록 및 판매자 데이터 수집을 위한 레지덴셜 프록시 활용법

리셀러와 이커머스 분석가에게 eBay는 다른 어떤 마켓플레이스도 공개적으로 제공하지 않는 한 가지를 제공한다. 바로 **판매 완료된 목록(sold listings)**이다. 대부분의 사이트는 판매자가 부르는 가격만 보여준다. eBay는 실제로 무엇이, 언제, 어떤 상태로, 어떤 판매자로부터 팔렸는지를 보여준다. 이것은 단순한 가격 신호가 아니라 거래 데이터이며, 그렇기 때문에 eBay는 운동화부터 산업용 부품까지 모든 것에 대한 공개 가격 지표 역할을 한다.

문제는 이를 안정적으로 수집하는 것이다. eBay는 가격과 수요가 서로 다른 별도의 지역 마켓플레이스를 운영하고, 자동화된 접근을 방어하며, 방문자에 맞춰 결과를 개인화한다. 단일 사무실 IP로 이 데이터를 가져오면 한 국가의 관점만 얻게 되며, 그마저도 빈틈투성이다. 이 가이드는 무엇을 수집할 가치가 있는지, 언제 공식 API를 대신 사용해야 하는지, 그리고 레지덴셜 프록시를 이용해 나머지를 정확하게 수집하는 방법을 다룬다.

실제로 수집할 가치가 있는 것

eBay 목록 페이지는 정보가 밀집되어 있지만, 분석가가 진짜로 신경 쓰는 것은 특정 하위 집합이다.

목록 수준

• 가격과 형식 — 가격 자체, 그리고 결정적으로 경매(auction)인지 즉시구매(Buy It Now)인지 여부. 이 둘을 섞으면 계산하는 모든 평균값이 왜곡된다.
• 상태(condition) — 새 상품, 중고, 리퍼비시, 부품용. eBay에서는 상태가 거의 그 어떤 요소보다 가격 편차를 크게 좌우한다.
• 배송과 위치 — 실제 도착 가격을 바꾸는 배송 비용과 물품 위치.
• 품목 세부사항 — 브랜드, 모델, 사이즈, 그리고 목록 간 비교를 가능하게 하는 구조화된 속성들.

판매 완료 / 종료된 목록 (가장 가치 있는 부분)

• 실현 가격과 판매일 — 구매자가 실제로 지불한 금액과 그 시점.
• 판매율(sell-through) — 해당 상품 목록 중 실제로 팔린 것과 팔리지 않고 만료된 것의 비율. “소싱할 가치가 있는 것”과 “영영 팔리지 않는 것”을 가르는 수치가 바로 이것이다.

판매자 수준

• 피드백 점수와 평점, 스토어 이름, 비즈니스 판매자 여부.
• 구색과 가격 책정 행태 — 경쟁 판매자가 무엇을, 어떤 가격에 올리고, 얼마나 빨리 판매하는지.

이 세 번째 범주가 수집을 경쟁 정보(competitive intelligence)로 바꾸는 지점이다. 단순히 어떤 제품이 얼마에 팔리는지가 아니라, 어떤 판매자가 그 시장에서 이기고 있는지를 알려주기 때문이다.

맞는 곳에는 공식 API부터 사용하라

명확히 말해둘 가치가 있다. 그래야 수고를 덜 수 있기 때문이다. eBay는 공식 API를 제공하며, 필요를 충족하는 범위 내에서는 이것이 최우선 선택지다. 안정적이고 구조화되어 있으며, 마크업이 바뀌어도 깨지지 않고, 명시적으로 허용된 방법이다. 표준 목록 데이터가 필요하고 규모와 지역이 API의 약관 및 한도 안에 들어간다면, API를 사용하라.

프록시가 필요한 경우는 API가 잘 다루지 못하는 사례들이다. API 범위 밖의 공개 데이터, 분석가 수준의 폭넓은 지역 마켓플레이스 커버리지, 또는 현지 구매자가 실제로 보는 것과 정확히 동일한 방식으로 마켓플레이스를 보는 경우 등이다. 솔직하게 말하면 이 둘은 대체재가 아니라 상호 보완적인 관계이며, 맞는 곳에서는 API부터 시작하는 것이 단순히 더 나은 엔지니어링이다.

나머지가 왜 프록시 문제인가

eBay의 세 가지 특성이 폭넓은 공개 데이터 수집을 접근성 문제로 만든다.

eBay는 마켓플레이스별로 분리되어 있고, 지역에 따라 개인화된다. ebay.com, ebay.co.uk, ebay.de, ebay.com.au는 재고, 가격, 수요, 판매율이 서로 다른 별개의 마켓플레이스다. 심지어 하나의 마켓플레이스 안에서도 결과는 방문자의 위치에 맞춰 개인화되며, 배송 옵션과 상품 재고가 달라진다. 국경을 넘나드는 차익거래를 하는 리셀러에게는 이것 자체가 분석 대상이다. 영국과 독일에서 어떤 물건이 얼마에 팔리는지가 바로 그것이다. 미국 IP로 ebay.de를 가져오면 어느 쪽 관점도 정확하게 얻을 수 없으므로, 측정하려는 시장에 실제로 있어야 한다(국가 및 도시 타겟팅).

eBay는 자동화된 접근을 방어한다. 여느 대형 마켓플레이스와 마찬가지로 봇 방지 시스템을 운영한다. 데이터센터 IP는 플래그가 붙거나, 제한되거나, 중간 페이지(interstitial)를 받게 되어, 실제 구매자의 페이지 대신 봇용 버전을 기록하게 된다(스크레이퍼가 차단되는 이유). 레지덴셜 IP는 실제 사용자로서의 신뢰도를 가지고 있어 실제 목록을 볼 수 있다.

커버리지는 광범위하고 반복적이다. 여러 마켓플레이스에 걸친 카테고리 전수 조사를, 판매율을 최신 상태로 유지하기 위해 매일 갱신하는 것은 상당한 양의 요청이다. 소수의 IP로는 속도 제한에 걸려 부분적인 표본만 얻게 되는데, 이는 여기서 치명적이다. 차단으로 편향된 표본에서 계산된 판매율은 아예 숫자가 없는 것보다 더 나쁘다.

올바른 마켓플레이스로 라우팅하기

Shifter 게이트웨이에서는 프록시 사용자 이름에 국가를 인코딩하여 선택하며, 엔드포인트 하나로 IP 목록이 필요 없다. 프록시 국가를 마켓플레이스 도메인과 일치시켜야 한다.

# ebay.com as a US buyer
curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 \
  "https://www.ebay.com/itm/123456789012"

# ebay.co.uk as a UK buyer
curl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 \
  "https://www.ebay.co.uk/itm/123456789012"

영국의 국가 코드는 uk가 아니라 gb라는 점에 유의하라. 사소해 보이지만 잘못 입력하면 눈치채지 못한 채 잘못된 시장 데이터를 얻게 된다.

코드로 수집하기

대부분의 eBay 목록 데이터는 초기 HTML에 들어 있으므로, 브라우저를 구동하는 것보다 일반 HTTP 클라이언트를 쓰는 것이 훨씬 빠르고 저렴하다(전체 클라이언트 설정은 Python으로 레지덴셜 프록시 사용하기 참고).

import os, requests
from bs4 import BeautifulSoup

USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]

def proxy(country="us"):
    url = f"http://{USER}-country-{country}:{PASS}@p.shifter.io:443"
    return {"http": url, "https": url}

MARKETS = {"us": "ebay.com", "gb": "ebay.co.uk", "de": "ebay.de"}

def fetch_listing(item_id, country="us"):
    domain = MARKETS[country]
    url = f"https://www.{domain}/itm/{item_id}"
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
        "Accept-Language": "en-GB,en;q=0.9" if country == "gb" else "en-US,en;q=0.9",
        "Accept-Encoding": "gzip, br",
    }
    r = requests.get(url, headers=headers, proxies=proxy(country), timeout=30)
    r.raise_for_status()
    soup = BeautifulSoup(r.text, "html.parser")
    return {
        "item_id": item_id,
        "market": country,
        "title": (t := soup.select_one("h1")) and t.get_text(strip=True),
        "price": (p := soup.select_one(".x-price-primary")) and p.get_text(strip=True),
        # Condition, shipping and item specifics live in their own blocks;
        # treat every selector as optional and validate what you extract.
    }

실무적으로 두 가지 유의할 점이 있다. Accept-Language는 타겟으로 하는 마켓플레이스에 맞춰 설정하라. 영국 IP가 en-US를 보내는 것은 굳이 만들 필요 없는 불일치다. 그리고 모든 선택자(selector)를 선택적인 것으로 다뤄라. eBay의 마크업은 카테고리와 목록 유형에 따라 달라지므로, 필드가 존재한다고 가정하지 말고 방어적으로 파싱하며 검증하라.

폭넓은 카테고리 전수 조사에는 요청마다 로테이션하고, 한 판매자의 재고를 페이지네이션할 때는 고정 세션을 유지해 하나의 구매자처럼 보이게 하라. IP 품질이 실제 페이지를 볼 수 있는지 여부를 결정하므로 IP 평판을 이해할 가치가 있으며, 간헐적이 아니라 지속적인 차단은 품질이나 행동 패턴 문제를 가리킨다(차단을 피하는 방법).

목록 데이터를 분석으로 전환하기

수집은 입력값일 뿐이며, 리셀러가 실제로 돈을 버는 곳은 분석이다. 이 데이터를 모델링할 때 중요한 몇 가지가 있다.

판매 완료와 활성 목록을 분리하라. 활성 목록은 판매자가 부르는 가격이며, 이는 희망사항이다. 판매 완료 목록은 실제 거래다. 이 둘을 절대 함께 평균 내지 말고, 어느 쪽을 말하는지 명시하지 않고는 “eBay 가격”을 언급하지 말라.

상태와 형식별로 분리하라. 중고품의 실현 가격과 신품의 실현 가격은 서로 다른 시장이다. 경매 종료와 즉시구매 판매도 다르게 움직인다. 이런 세그먼트를 평균 내면 아무것도 설명하지 못하는 숫자가 나온다.

가격뿐 아니라 판매율을 계산하라. 일정 기간 동안 판매된 수를 전체 등록 수로 나눈 값은 유동성을 알려준다. 판매율이 10%인 높은 가격은, 꾸준히 팔리는 낮은 가격보다 더 나쁜 소싱 대상이다.

시장 간 비교는 의도적으로 하라. 국경 간 가격 격차는 리셀러의 강점이지만, 각 시장의 수치가 실제로 그 시장에서 수집된 경우에만 그렇다. 이것이 바로 위의 지역 라우팅이 중요한 이유다.

결과물을 연구용 데이터셋으로 구조화하는 방법은 웹 스크레이핑으로 데이터셋 만들기에서 그 메커니즘을 다루며, 동일한 원칙이 가격 모니터링과 디지털 셸프 분석의 기반이 된다.

책임감 있게 사용하기

공개 목록 데이터만 수집하라. 구매자라면 누구나 볼 수 있는 제목, 가격, 상태, 배송, 공개 판매자 지표들이다. 개인정보는 대상에서 제외해야 한다. 구매자 신원, 개인 메시지, 계정에 첨부된 개인 정보는 수집 대상이 아니며, 피드백 댓글은 개인정보를 포함할 수 있으므로 신중하게 다뤄야 한다.

그 외에도 eBay의 이용약관과 속도 제한을 준수하고, 사이트 성능을 저하시키지 말며, 사용 사례를 충족하는 경우 공식 API를 우선하라. eBay 약관은 자동화된 접근을 제한하므로, 수집은 공개 데이터에 한정하고, 합리적인 속도를 유지하며, 불확실한 부분은 법률 자문을 받아라(웹 스크레이핑은 합법인가). 프록시는 요청이 어떤 IP에서 오는지를 바꿀 뿐, 그 요청을 해도 되는지 여부를 바꾸지는 않는다. Shifter에서 무엇이 허용되는지는 이용 정책이 판단 기준이다.

자주 묻는 질문

eBay 데이터에 왜 프록시가 필요한가? eBay가 가격과 수요가 다른 별도의 지역 마켓플레이스를 운영하고, 위치에 따라 결과를 개인화하며, 자동화된 접근을 방어하기 때문이다. 하나의 IP로는 하나의 시장을, 그것도 부분적으로만 볼 수 있다. 레지덴셜 프록시를 사용하면 실제 현지 구매자처럼 각 마켓플레이스를 수집할 수 있다.

대신 eBay API를 사용해야 하는가? 필요를 충족하는 범위라면 그렇다. API는 안정적이고 구조화되어 있으며 공식적으로 허용된다. 프록시는 API 범위 밖의 공개 데이터나 여러 지역 마켓플레이스에 걸친 폭넓은 수집에 사용한다. API부터 시작하고 나머지는 수집으로 처리하라.

판매 완료된 목록을 수집할 수 있는가? 판매 완료된 목록은 공개적으로 표시되며, 판매자가 부르는 가격이 아니라 실현 가격이기 때문에 리셀러에게 가장 가치 있는 입력값이다. 이를 공개 데이터로 수집하고, 분석에서 판매 완료와 활성 목록을 구분하며, eBay의 약관과 속도 제한을 준수하라.

영국은 왜 국가 코드 gb가 필요한가? 게이트웨이가 ISO 국가 코드를 사용하기 때문이며, 영국(United Kingdom)의 코드는 gb이다. uk를 사용하면 조용히 타겟팅이 실패하며, 잘못된 시장에서 ebay.co.uk를 수집하고 있다는 사실을 깨닫지 못할 수 있다.

eBay에는 레지덴셜 프록시와 데이터센터 프록시 중 무엇을 써야 하는가? 레지덴셜이다. 마켓플레이스는 데이터센터 IP를 탐지하여 다르게 취급하므로, 속도 제한이 걸리거나 저하된 페이지를 받게 된다. 레지덴셜 IP는 실제 구매자가 보는 것처럼 정확한 지역의 실제 목록을 볼 수 있다.

결론

eBay의 공개된 판매 완료 목록 데이터는 희망사항이 아니라 거래 기반이기 때문에 이례적으로 가치가 높으며, 리셀러의 소싱, 가격 책정, 판매율 분석의 근간이 된다. 문제는 이 데이터가 지역 마켓플레이스별로 분리되어 있고, 위치에 따라 개인화되며, 방어되고 있다는 점이다. 따라서 분석의 정확성은 전적으로 각 시장을 그 시장의 실제 구매자로서 수집하는 데 달려 있다. 적합한 곳에는 공식 API를 사용하고, 나머지는 마켓플레이스에 맞춘 레지덴셜 IP로 라우팅하며, 방어적으로 파싱하고, 모델에서 판매 완료와 활성 목록을 분리해서 유지하라.

이렇게 하면 소싱하고 가격을 매길 수 있는 숫자를 얻게 되며, 아무것도 설명하지 못하는 혼합 평균을 얻지 않게 된다. 양질의 레지덴셜 프록시 네트워크가 이러한 수집을 지역적으로 정확하고 완전하게 유지해주며, 가격 페이지에는 실제로 거래하는 카테고리와 마켓플레이스를 대상으로 시험해볼 수 있는 GB당 요금제가 있다.