송장번호를 받았는데 조회가 안 된다: 예약출고와 실제 배송을 구분하는 작업판

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

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

예약상품을 파는 팀은 택배 송장을 먼저 생성합니다. 그날 밤 고객센터에서 번호를 조회하자 정보가 없어 담당자는 잘못된 송장인지 하나씩 확인합니다. 번호 생성 시점과 실제 택배사 정보 등록 시점을 같은 것으로 취급한 것이 출발점입니다.

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

주문 시스템에 송장 등록시각과 마지막 조회시각을 따로 둡니다. APICK으로 배송정보를 확인하되 정보없음을 분실이나 출고취소로 바꾸지 않습니다. 창고가 확정한 출고 일정은 내부 자료이고 택배 조회 상태와 출처를 구분합니다.

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.

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

조회되지 않은 번호는 일정 간격 뒤 확인할 대기 목록에 둡니다. 정확한 재조회 간격은 출고 방식과 공식 제한에 맞춰 정하고, 클릭할 때마다 즉시 API를 다시 호출하지 않도록 합니다. 장시간 확인되지 않은 건만 담당자가 창고의 접수 기록과 대조합니다.

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

예약 취소나 송장 교체가 생기면 오래된 번호의 재조회 작업을 종료합니다. 새 번호를 받았다는 이유로 이전 번호의 이력을 삭제하지는 않습니다. 자동인식 실패도 택배가 사라졌다는 뜻이 아니므로 알고 있는 택배사 코드를 먼저 확인합니다.

비용과 확인 조건

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

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

이 작업판의 목적은 조회되지 않은 번호를 숨기는 것이 아니라 확인 주체와 다음 작업을 명확히 하는 것입니다. 대기건 수와 실제 확인이 필요한 건수, 불필요한 재조회 횟수를 지표로 삼으면 단순 조회 성공률보다 운영 효과를 잘 볼 수 있습니다.

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

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

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