요약 (TL;DR)
- 현재 경매 입찰가는 최종 거래 금액이 아닙니다.
- 상태, 변형(variation), 배송 컨텍스트, 통화는 비교 가능한 관측치에 포함됩니다.
- 공식 Browse API는 문서화된 검색 및 조회(discovery and lookup)를 지원할 뿐, 모든 과거 판매 질문을 지원하지 않습니다.
- 판매 건수(sold counter)에 현재 가격을 곱한다고 해서 매출이 확정되는 것은 아닙니다.
제가 가장 먼저 내릴 결정
저는 공식 Browse API가 필요한 검색 및 조회 필드를 다루는지 확인하는 것부터 eBay 프로젝트를 시작할 것입니다. 페이지 수집이 필요하더라도, 네이티브 리스팅 식별자(native listing identity), 상태, 변형, 판매자 컨텍스트, 그리고 명시적인 가격 레이블을 원합니다. 현재 입찰가와 고정가 제안은 같은 분석적 값으로 간주되어서는 안 됩니다.
여기서 제가 비교하는 것은 문서화된 기능이며, 모든 서비스에 대한 실제 성능 벤치마크를 보고하는 것이 아닙니다. 순서는 성능 순위라기보다는 저의 의사 결정 과정을 따릅니다.
구현 전에 정의할 기록 (Record)
저는 리스팅 식별자와 금액 의미를 보존하고, 페이지 파서를 유지하기 전에 공식 접근 방식을 조사합니다. 이것들은 공급업체 응답 스키마가 아니라 제안된 애플리케이션 필드입니다.
| Field | 제가 보존할 것 |
|---|
listing_key | 네이티브 또는 검토된 리스팅 식별자 |
| ... | |
옵션을 좁히는 방법
저는 현재 입찰가와 고정가 제안을 레이블 없이 단일 가격 시리즈에 넣지 않을 것입니다. 또한 변형 페이지의 가장 낮은 표시 금액이 제가 비교하고 싶은 선택된 항목에 적용된다고 가정하지도 않을 것입니다. 이것들은 기술적으로 완벽한 가져오기(fetch)를 거치더라도 살아남을 수 있는 해석 오류입니다.
제 기록은 정규화된 값과 함께 원본 레이블을 보존할 것입니다. 배송이 관측되지 않는 경우, 배송비를 0으로 조용히 처리하기보다는 도착 비용 비교가 불완전한 상태로 남아 있어야 합니다.
저는 개별 옵션들이 허용된 작업에 맞는지 여부만 확인했을 때, 감독 도구(supervised tool), 관리형 소스별 경로(managed source-specific route), 그리고 자체 구현을 비교할 것입니다. 모든 옵션을 설계되지 않은 동일한 작업을 강요하지 않을 것입니다.
eBay Browse API: 제가 사용할 곳
eBay Browse API는 리스팅 발견 및 아이템 조회에 대한 eBay의 공식 개발자 인터페이스입니다. 페이지 추출 워크플로우를 확정하기 전에 공식 검색 및 조회 계약을 확인해야 합니다. 이 API는 필요한 데이터가 문서화된 검색 및 상세 작업으로 커버되는 프로젝트에 적합합니다. 검색 요약은 문서화된 아이템 상세 요청으로 이어질 수 있습니다. 이는 시각적 페이지 파서로 시작하지 않고도 애플리케이션에 네이티브 식별자와 명시적인 응답 의미론을 부여합니다. 제공업체는 공식 Browse API 개요에서 이 범위를 설명하고 있습니다.
제가 중요하게 생각하는 기능들
- 문서화된 발견: 지원되는 검색 입력 및 필터는 쿼리 기반 리스팅 집합으로의 명시적인 경로를 제공합니다.
- 네이티브 아이템 식별자: 공식 응답 식별자는 제목 문자열이나 행 위치에서 리스팅 식별자를 생성하는 것을 방지합니다.
- 아이템 조회: 상세 조회가 발견을 따라올 수 있어 애플리케이션이 검색 요약과 특정 리스팅 기록을 분리할 수 있게 합니다.
저의 시작 워크플로우는 간단할 것입니다. 이 워크플로우를 위해 지원되는 필터로 검색하고, 네이티브 아이템 ID를 유지하며, 워크플로우가 검색 요약을 넘어선 상세 정보가 필요할 때 아이템 조회를 사용합니다.
- 사용 가능한 데이터: 리스팅 식별자, 제목, 상태(condition), 선택된 변형(selected variation), 공개 판매자 정보, 가격 레이블 및 보이는 배송 컨텍스트.
- 입력 및 출력: 지원되는 검색어, 필터 또는 품목 ID → 문서화된 검색 요약 및 품목 상세 JSON.
- 최적의 사용처: 지원되는 eBay 접근 및 엔드포인트 약관에 프로젝트가 맞는 개발자에게 추천할 것입니다.
- 시작하기: eBay 개발자 애플리케이션을 등록하고, 승인된 자격 증명(authorized credentials)을 얻고, 해당 Buy API 접근 요구 사항을 충족해야 합니다.
- 결제 모델: 접근은 eBay 개발자 약관 및 호출 제한에 의해 관리되므로, 테스트 자격 증명을 사용한다고 무제한의 프로덕션 또는 대량 액세스를 가정해서는 안 됩니다.
- 부적합한 경우: 명확히 구분할 경계: 브라우즈 커버리지(Browse coverage) 외부의 과거 판매가 또는 완료된 거래 분석, 또는 개발자 접근 약관에 맞지 않는 재사용.
Bright Data: 제가 사용할 곳
Bright Data는 소스별 스크래퍼 제품과 데이터셋 중심의 전송을 제공하는 관리형 수집 플랫폼입니다. 공급자가 해당 파서를 소유하기를 원할 때 전용 소스 계약(source contract)을 검토할 것입니다. Bright Data는 전자상거래 카탈로그에서 eBay 추출 및 검색 워크플로우를 나열합니다. 전용 공급자 소유 기록 계약은 팀이 모든 소스 선택기(source selector)를 유지 관리하지 않고도 리스팅 및 공개 판매자 정보를 수집하는 데 도움이 됩니다. 이는 수동 내보내기보다 반복적인 수집(repeatable ingestion)이 필요한 마켓플레이스 데이터셋에 적합합니다. 공급자는 전자상거래 카탈로그에서 이 범위를 설명합니다.
제가 중요하게 생각하는 기능
- 소스별 계약 (Source-specific contract): 전용 스크래퍼가 지원하는 입력 및 필드를 문서화하여, 모든 소스 파서를 내부적으로 구축할 필요성을 줄여줍니다.
- 관리형 실행 (Managed execution): 제공업체가 운영하는 수집 방식은 데이터 획득 인프라를 고객 애플리케이션 외부로 이동시켜 운영 경계를 단순화합니다.
- 구조화된 전송 (Structured delivery): 문서화된 레코드 형태는 수동 페이지 정리부터 시작하는 대신, 웨어하우스나 분석 워크플로우에 직접 데이터를 가져오는 것을 지원합니다.
저의 초기 워크플로우는 간단할 것입니다. 이 워크플로우를 위해 전용 소스 제품을 선택하고, 적절한 조회 또는 검색 입력을 제출하며, 전달된 레코드를 소스 인식 분석 테이블로 매핑하는 것입니다.
- 사용 가능한 데이터: 리스팅 식별자, 제목, 상태, 선택된 변형(variation), 공개 판매자 정보, 가격 라벨 및 보이는 배송 컨텍스트입니다.
- 입력 및 출력: 선택한 스크래퍼의 문서화된 URL 또는 검색 입력 → 소스별 레코드 및 지원되는 데이터셋 전송.
- 최적의 사용처: 제공업체 소유 추출 계약을 선호하는 데이터 팀에게 추천합니다.
- 시작하기: 계정을 생성하고, 정확한 소스 스크래퍼를 선택한 다음, 그 입력 및 필드 계약을 검토하세요.
- 청구 모델: Web Scraper API 플랜은 전달된 레코드를 측정하며; 실시간 수집과 구매 데이터셋은 별도의 약관이 있습니다.
- 적합하지 않은 경우: 제가 명확하게 구분할 경계입니다. 모든 파서 결정에 대한 직접적인 소유권이 필요하거나, 전용 스크래퍼 계약 외부의 필드 및 소스 컨텍스트가 필요한 팀들입니다.
Apify eBay Actors: 제가 사용하고 싶은 곳
Apify는 Actors를 통해 출처별 입력값, 실행 가능한 수집 작업(collection jobs), 그리고 저장된 데이터셋을 제공하는 호스팅 자동화 플랫폼입니다. 따라서 직접 소스 컬렉터를 구축하기로 결정하기 전에 일치하는 유지보수되는 Actor가 있는지 찾아보는 것이 좋겠습니다. Apify eBay Actors는 유지보수되는 워크플로우가 특정 제품, 검색, 카테고리 또는 판매자 스토어 작업과 일치할 때 유용합니다. 호스팅 실행(Hosted runs)은 수집 로직을 제공하고 그 결과로 생성된 데이터셋을 저장합니다. 저는 이러한 기록들을 자체 실행 플랫폼을 운영하지 않고도 예약된 경쟁사 분석이나 리스팅 조사에 통합할 수 있습니다. 제공업체는 Actor 마켓플레이스에서 이 범위를 설명하고 있습니다.
제가 중요하게 생각하는 기능들
- 사전 구축된 Actors (Prebuilt Actors): 일치하는 Actor는 문서화된 출처에 대한 수집 로직을 제공하여 시작하는 데 필요한 사이트별 코드의 양을 줄여줍니다.
- 호스팅 실행 및 데이터셋 (Hosted runs and datasets): 실행과 결과 저장이 플랫폼에서 이루어지므로, 팀이 수집 작업을 자체 분석 애플리케이션으로부터 분리할 수 있게 합니다.
- 스케줄링 및 통합 (Scheduling and integration): 플랫폼 스케줄링과 API 접근을 통해 검토된 수집 작업을 분석가의 브라우저를 열어두지 않고도 반복적인 워크플로우로 옮길 수 있습니다.
제 시작 워크플로우는 간단할 것입니다. 이 워크플로우를 위해 출처별 Actor를 선택하고, 제한된 입력값(bounded input)을 제출하며, 완료된 데이터셋 항목들을 검사한 다음, 승인된 결과를 분석 워크플로우에 연결하는 것입니다.
- 사용 가능한 데이터: 리스팅 식별자(Listing identity), 제목(title), 상태(condition), 선택된 변형(selected variation), 공개 판매자 정보(public seller information), 가격 라벨(price labels) 및 보이는 배송 컨텍스트(visible shipping context). 선택한 Actor가 문서화한 필드만 공급 출력으로 간주해야 합니다.
- 입력 및 출력: 선택한 Actor의 문서화된 URL, 쿼리 또는 기타 입력 → 해당 Actor의 출력 스키마와 일치하는 데이터셋 항목.
- 적합한 경우: 호스팅 실행을 통해 유지 관리되는 소스별 워크플로우를 원하는 팀에게 추천합니다.
- 시작하기: Apify 계정을 생성하고, 유지 관리되는 Actor를 선택하여 해당 Actor의 입력 스키마, 출력 샘플 및 과금 모델을 검토하세요.
- 청구 모델: 플랫폼 리소스 사용량에 개별 Actor의 가격이 추가되며, 이는 임대(rental), 결과(result) 또는 이벤트(event) 청구를 사용할 수 있습니다.
- 적합하지 않은 경우: 제가 명확히 구분할 경계는 다음과 같습니다. 제3자 Actor 유지 관리에 의존할 수 없거나 필요한 필드 및 입력이 선택된 Actor 계약에 없는 프로젝트입니다.
Scrapy: 제가 사용하고 싶은 영역
Scrapy는 요청을 예약하고, 항목(item)을 추출하며, 애플리케이션 소유 파이프라인을 통해 처리하기 위한 오픈 소스 Python 프레임워크입니다. 저는 Python 크롤러와 그 항목 파이프라인을 직접 소유하는 것이 의도적인 엔지니어링 약속일 때 이를 선택할 것입니다. Scrapy는 명시적인 리스팅 검색 및 항목 처리가 이루어지는 애플리케이션 소유 eBay 파이프라인에 적합합니다. 검색 결과가 상세 작업(detail tasks)을 생성할 수 있으며, 파이프라인은 상태, 변형 및 관찰 기록을 유지합니다. 이는 Python 팀에게 일회성 브라우저 내보내기(one-off browser export)에 의존하는 대신 레코드 생명주기에 대한 통제권을 부여합니다.
제가 중요하게 생각하는 기능
요청 스케줄링(Request scheduling): 크롤러가 브라우저 매크로에 의존하는 대신 소스 범위, 콜백, 그리고 발견된 URL이 작업 부하에 포함되는 방식을 정의할 수 있습니다.
- 아이템 파이프라인(Item pipelines): 유효성 검사(Validation), 정규화(Normalization), 저장소(Storage)를 구조화된 아이템을 중심으로 구성할 수 있어 도메인 규칙을 유지보수 가능한 애플리케이션 코드에 보관할 수 있습니다.
- 확장 가능한 아키텍처(Extensible architecture): 다운로더 및 파이프라인 컴포넌트는 엔지니어가 이 프레임워크를 다중 소스 수집 시스템에 맞게 조정하도록 합니다.
저의 시작 워크플로우는 간단할 것입니다. 이 워크플로우를 위해 승인된 시드(seeds)를 정의하고, 리스트 발견과 상세 파싱을 분리하며, 승인된 아이템들을 유효성 검사 및 영속화(persistence) 파이프라인으로 보냅니다.
- 사용 가능한 데이터: 리스팅 식별자(Listing identity), 제목(title), 상태(condition), 선택된 변형(selected variation), 공개 판매자 정보, 가격 레이블, 그리고 보이는 배송 컨텍스트. 일반적인 수집 경로에서는 이들이 보장되는 네이티브 스키마라기보다는 애플리케이션에서 추출한 필드입니다.
- 입력 및 출력: 시드 URL, 스파이더 콜백(spider callbacks), 아이템 정의 → 애플리케이션 정의 아이템, 피드 내보내기(feed exports), 또는 파이프라인 쓰기(pipeline writes).
- 적합한 경우: 크롤링과 데이터 처리에 대한 직접적인 소유권을 원하는 Python 팀에게 추천할 것입니다.
- 시작하기: Python과 Scrapy를 설치하고, 스파이더, 파싱 규칙, 그리고 유효성 검사/저장소 파이프라인을 작성합니다.
- 청구 모델: 이 프레임워크는 오픈 소스이며, 사용 시간(runtime), 호스팅, 선택적 수집 서비스, 엔지니어링 비용에 대해 지불합니다.
- 부적합한 경우: 제가 명시적으로 유지할 경계는 다음과 같습니다. 추가 렌더링 경로 없이 JavaScript에 의존하는 수집이거나, Python 스파이더와 아이템 파이프라인을 유지 관리할 수 없는 팀입니다.
Playwright: 제가 사용할 곳
Playwright는 탐색(navigation), 상호작용(interaction), 로케이터(locators), 페이지 상태 검사(page-state inspection) 기능을 갖춘 오픈 소스 브라우저 자동화 프레임워크입니다. 저는 실제로 렌더링되거나 선택된 페이지 상태에 의존하는 작업 부분에 대해서는 브라우저 제어를 유지할 것입니다. Playwright는 렌더링된 콘텐츠 또는 허용된 옵션 선택을 포함하는 제한적인 공식 eBay 워크플로우에 대한 직접적인 제어를 제공합니다. 로케이터와 페이지 검사는 어떤 리스팅과 변형(variation)이 읽히고 있는지 확인할 수 있게 해줍니다. 또한 소스 페이지와 반환되는 금액 간의 불일치를 재현하는 데 유용합니다. 제공업체는 이 범위를 공식 브라우저 문서에서 설명하고 있습니다.
제가 중요하게 생각하는 기능들
- 렌더링된 페이지 접근: 브라우저는 페이지 스크립트를 실행하여 첫 번째 HTTP 응답에는 존재하지 않는 공개 콘텐츠로부터 추출할 수 있게 합니다.
- 명시적 상호작용: 로케이터와 상호작용 단계는 허용된 클릭이나 옵션 선택이 필요할 때 선택된 페이지 상태를 재현 가능하게 만듭니다.
- 시각 및 DOM 증거: 스크린샷과 페이지 검사는 데이터 수집이 의도한 항목, 리스팅 또는 답변에 도달했는지 진단하는 데 도움이 됩니다.