공식 API vs 웹 스크래핑: 택배 추적의 이면

추적 API를 호출하면 데이터는 어딘가에서 가져와야 합니다. 모든 추적 응답 뒤에는 수백 개 택배사에서 각기 다른 기술적 환경에 맞춰 정보를 수집하는 복잡한 시스템이 있습니다. 이 글에서는 추적 데이터를 수집하는 두 가지 핵심 방식인 공식 API와 웹 스크래핑을 비교하고, 각 방식이 추적 데이터의 안정성에 어떤 영향을 미치는지 살펴보겠습니다.

두 가지 접근 방식

공식 택배사 API

일부 택배사는 추적을 위한 공식 REST 또는 SOAP API를 제공합니다:

Your App → WhereParcel API → Carrier Official API → Tracking Data

공식 API를 제공하는 대표 택배사:

FedEx (OAuth 2.0 기반 REST API)
UPS (API 키 기반 REST API)
DHL (API 키 기반 REST API)
Korea Post (EMS API)

장점:

높은 안정성과 가동률
체계적이고 일관된 데이터 형식
공식적으로 지원되며 문서화됨
상대적으로 높은 Rate Limit

한계:

각 택배사와 별도의 비즈니스 계약 필요
API 접근 승인 절차가 복잡한 경우가 많음
일부 택배사는 API 사용에 요금을 부과
모든 택배사가 API를 제공하지는 않음

웹 스크래핑

전 세계 대부분의 택배사는 공개 API를 제공하지 않습니다. 이러한 택배사의 경우, 택배사의 추적 페이지를 프로그래밍 방식으로 방문하여 데이터를 수집합니다:

Your App → WhereParcel API → Carrier Website (HTML) → Parse → Tracking Data

스크래핑이 필요한 택배사:

대부분의 지역 및 국내 택배사
중소 규모 물류 업체
API 프로그램이 없는 우편 서비스

장점:

웹사이트가 있는 모든 택배사에서 동작
별도의 비즈니스 계약 불필요
500개 이상의 택배사를 즉시 지원 가능

과제:

웹사이트 변경 시 파싱이 깨질 수 있음
IP Rate Limiting 및 차단 위험
상대적으로 느린 응답 시간
비정형 데이터 처리 필요

애플리케이션에 미치는 영향

안정성 차이

항목	공식 API	웹 스크래핑
가동률	99.9% 이상	95~99%
응답 시간	200~500ms	1~5초
데이터 일관성	높음	중간
주요 변경사항	버전 관리, 사전 공지	예고 없이 변경
Rate Limit	명확히 공개	예측 불가

WhereParcel의 하이브리드 접근

WhereParcel은 각 택배사에 가장 적합한 방식을 자동으로 선택합니다:

공식 API 우선 — 택배사가 API를 제공하는 경우 항상 API를 사용합니다
스크래핑 폴백 — API가 없는 택배사의 경우, 분산 스크래핑 인프라를 통해 안정적으로 데이터를 수집합니다
통합 응답 형식 — 데이터 출처에 관계없이 동일한 표준화된 응답 형식을 제공합니다

{
  "success": true,
  "data": {
    "carrier": "kr.cjlogistics",
    "trackingNumber": "1234567890",
    "status": "in_transit",
    "source": "api",
    "events": [...]
  }
}

source 필드를 통해 데이터가 api 출처인지 scraping 출처인지 확인할 수 있으므로, 상황에 맞게 예외 처리를 적용하실 수 있습니다.

인프라 과제

대규모 스크래핑 인프라를 안정적으로 운영하려면 여러 가지 까다로운 문제를 해결해야 합니다.

IP 로테이션

택배사 웹사이트는 요청이 과도한 IP를 차단합니다. 프로덕션 수준의 시스템에는 다음이 필요합니다:

여러 리전에 걸친 다중 IP 풀
차단 감지 시 자동 로테이션
요청을 분산시키는 분산 아키텍처

파싱 복원력

택배사가 웹사이트를 리디자인하면 스크래핑이 중단됩니다. 이를 완화하기 위한 전략은 다음과 같습니다:

택배사별 다중 파싱 전략 운용
파싱 실패 자동 모니터링
파서 업데이트의 빠른 배포
파서 수정 중 캐시된 데이터 제공

데이터 정규화

각 택배사의 웹사이트는 데이터를 서로 다른 형식으로 표시합니다. 스크래핑 시스템은 다음 항목을 정규화해야 합니다:

상태 코드 (택배사마다 상이)
타임스탬프 (다양한 형식과 시간대)
지역명 (약어, 다국어)
이벤트 설명 (번역 및 표준화)

통합 모범 사례

1. 즉시 응답을 기대하지 마세요

스크래핑 기반 추적은 약간의 지연이 있을 수 있습니다. UI를 설계할 때 이 점을 고려하세요:

// Show loading state with context
function TrackingStatus({ tracking }) {
  if (tracking.loading) {
    return <div>Retrieving tracking data... This may take a few seconds.</div>;
  }
  return <TrackingTimeline events={tracking.events} />;
}

2. 스크래핑 기반 택배사에는 웹훅을 활용하세요

스크래핑에 의존하는 택배사의 경우 웹훅 활용이 특히 중요합니다. WhereParcel이 스케줄에 따라 택배사 웹사이트를 확인하고 변경사항이 있을 때만 알려주므로, 직접 폴링하여 Rate Limit을 소진할 필요가 없습니다.

3. 적극적으로 캐싱하세요

스크래핑은 API 호출보다 느리고 예측이 어려우므로, 추적 결과를 자체적으로 캐싱하는 것이 좋습니다:

const CACHE_DURATION = {
  api: 5 * 60,      // 5 min for API-sourced data
  scraping: 15 * 60, // 15 min for scraping-sourced data
};

4. 그레이스풀 디그레이데이션을 구현하세요

간혹 택배사 웹사이트가 다운되거나 변경될 수 있습니다. 이러한 상황을 우아하게 처리하세요:

if (tracking.status === 'temporarily_unavailable') {
  // Show last known data with a notice
  return (
    <div>
      <TrackingTimeline events={tracking.lastKnownEvents} />
      <Notice>Live tracking is temporarily unavailable for this carrier.
        Showing last known status from {tracking.lastUpdated}.</Notice>
    </div>
  );
}

앞으로의 전망: 더 많은 API, 더 나은 스크래핑

업계 전체적으로 공식 API를 제공하는 택배사가 점차 늘어나고 있습니다. 그러나 전 세계를 포괄하는 추적 서비스를 위해서는 당분간 웹 스크래핑이 필수적인 역할을 합니다. WhereParcel은 500개 이상의 택배사에서 가장 안정적인 추적 데이터를 제공하기 위해 두 가지 접근 방식 모두에 꾸준히 투자하고 있습니다.

특정 택배사의 데이터 소스에 대한 궁금한 점이 있으시면 택배사 문서를 확인하시거나 문의하기를 통해 연락해 주세요.