매일 내려받은 주문 파일에 어제 송장이 또 있다: 중복 조회를 막는 가져오기

에이픽 서비스를 소개하는 홍보 글입니다. 현실적인 업무를 바탕으로 구성한 가상 시나리오이며 실제 고객 후기나 실측 성과가 아닙니다. 공식 문서의 2026-11-05 확인 기록을 기준으로 작성했습니다. 아래 요청·응답은 미실행 정적 예시입니다.

반복 작업은 어디에서 시작되는가

출고 파일을 매일 업로드하는 운영팀이 누적 목록과 신규 목록을 혼용합니다. 어제 등록한 송장이 오늘도 새 작업으로 들어가 같은 건을 여러 번 조회합니다. 담당자는 파일명으로 구분하려 하지만 재업로드만으로 중복을 막기는 어렵습니다.

자동화할 단위를 먼저 정합니다

파일 단위가 아니라 내부 배송건 단위로 등록 여부를 확인합니다. 택배사와 송장, 주문 연결 관계를 검토해 기존 건은 갱신하고 새 건만 추가합니다. 송장번호만 영원히 고유하다고 가정하지 않으며 업무 기간과 원천 식별자를 함께 관리합니다.

apick.app에서 서버 연결을 준비합니다

공식 홈페이지에서 해당 상품의 최신 개발가이드와 이용 조건을 확인하고 계정을 준비합니다. 인증키는 서버 환경변수 APICK_API_KEY로 읽고 브라우저·앱·공개 저장소에 넣지 않습니다. 키를 출력하는 디버그 로그도 끕니다. 아래 네 장은 공통 준비 절차를 보여주는 2026-10-28 공개 보관 화면이며, 이 상품을 실행한 결과 사진이 아닙니다. 당시 화면의 상품 수나 표시는 현재 상태를 보증하지 않습니다.

상품과 개발가이드로 이동하는 에이픽 공개 홈. 당시 메뉴 화면이며 현재 상품 수를 뜻하지 않습니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

계정 준비 단계에서 만나는 빈 회원가입 양식. 정보 입력이나 가입 실행 화면이 아닙니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

서버 환경변수에 인증키를 보관하는 공통 시작 가이드. 실제 키 값은 없는 공개 문서입니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

공식 요청과 마스킹 응답 예시

승인된 업무의 송장과 현재 공식 허용 택배사 코드를 서버 환경변수에 연결하는 구조입니다. 실제 값과 실제 API 키는 포함하지 않았습니다. 두 예시는 서로 다른 선택 경로이며 같은 건에 모두 연속 실행하라는 뜻이 아닙니다.

# 공식 명세 기반 정적 예시이며 실제 요청을 실행하지 않았습니다.
curl --fail-with-body --request POST 'https://apick.app/rest/parcel_tracking' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string "carrier=${APICK_CARRIER}" \
  --form-string "trackingNumber=${APICK_TRACKING_NUMBER}"

# 택배사를 모르는 건만 별도로 검토하는 자동인식 경로
curl --fail-with-body --request POST 'https://apick.app/rest/parcel_tracking_auto' \
  --header "Authorization: Bearer $APICK_API_KEY" \
  --form-string "trackingNumber=${APICK_TRACKING_NUMBER}"

아래는 공식 응답 일부 구조의 정적 예시입니다. 송장번호를 마스킹했으며 실제 배송이 완료됐다는 증거가 아닙니다.

{
  "data": {
    "carrier": {
      "code": "cj",
      "name": "CJ대한통운"
    },
    "trackingNumber": "[마스킹]",
    "status": "DELIVERED",
    "carrierStatus": "배달완료"
  }
}

공통 연결 확인용 /rest/info의 정적 cURL 화면. 아래 상품 API의 호출 결과가 아닙니다. 2026-10-28 보관 화면, 공개 이미지 접근 및 내용 확인 2026-11-05.

우리 업무 화면에는 이렇게 연결합니다

APICK 조회는 가져오기 검수 후 추적이 필요한 목록에만 수행합니다. 중복 파일 업로드를 배송 상태 변경으로 취급하지 않고, 기존 건의 마지막 조회시각과 다음 확인 필요성을 먼저 봅니다. 덕분에 데이터 가져오기와 외부 유료 요청을 분리할 수 있습니다.

예외를 숨기지 않고 분리합니다

한 송장이 합배송으로 여러 주문에 연결될 수 있으므로 같은 번호를 발견했다고 주문 연결을 삭제하지 않습니다. 반대로 재발송으로 번호가 바뀐 건은 이전 배송건과 새 배송건을 별도로 보관합니다. 이런 관계는 API가 아니라 주문 시스템의 책임입니다.

비용과 확인 조건

공식 문서는 국내외38개 택배사와 자동 택배사 인식을 안내합니다. 지정조회 기본요금은5P, 실패·정보없음은 무과금 안내이며 자동인식 단가를 같은5P로 가정하지 않습니다. 택배사를 알 때 지정조회가 빠르고 저렴하다는 안내를 참고하세요. 공개 상태표의 확인 중 표시만으로 전체 정상이나 전체 장애를 단정하지 않습니다.

도입 효과는 무엇으로 확인할까

가져온 행 수와 실제 신규 배송건 수, API 요청 수를 따로 집계합니다. 세 수가 다르다고 오류는 아닙니다. 파일 업로드를 몇 번 해도 불필요한 요청이 늘지 않는지 확인하는 것이 이 연동의 핵심 검수입니다.

이 글은 직접 구현할 업무 흐름 제안이며 에이픽이 완성된 관리 화면이나 자동 알림 시스템까지 제공한다는 뜻이 아닙니다. 실제 처리시간을 측정하지 않았으므로 밤새던 작업이 몇 분에 끝났다는 실적을 주장하지 않습니다. 승인 대기·기관 응답·예외 검토 시간을 포함해 작은 적법한 범위에서 확인한 뒤 확대 여부를 결정하세요.

실제 이름·전화번호·차량번호·송장·통관부호·거래 식별자·문서 원문은 공개 글과 공유 로그에서 제외합니다. 내부 저장도 목적과 권한·보관기간을 정하고 원문 전체를 불필요하게 복제하지 않습니다.

공식 서비스: apick.app · 개발가이드: parcel_tracking