배송 알림을 두 번 보내지 않으려면: 상태 조회와 고객 통지를 분리하기

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

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

배송 완료 알림을 직접 운영하는 판매사가 있다고 가정합니다. 정기 조회가 실행될 때마다 완료 상태를 보고 같은 알림을 재발송합니다. 고객은 이미 받은 메시지를 또 받고 운영팀은 발송 기록을 수동으로 확인합니다.

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

APICK 조회 결과는 상태 기록으로 저장하고 고객 통지는 별도 작업으로 관리합니다. 마지막으로 안내한 상태와 이번에 확인한 상태를 비교해 필요한 변화만 후보로 만듭니다. API는 배송 조회를 제공하며 메시지 발송 기능까지 대신하는 것으로 설명하지 않습니다.

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.

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

실제 통지는 수신 동의와 적용 법령, 채널 정책을 확인한 뒤 설계합니다. 여기서는 메시지를 보내거나 자동 발송을 설정하지 않습니다. 업무 시스템이 발송 완료를 저장하지 못한 경우를 고려해 중복 안내를 막는 자체 식별자를 둡니다.

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

배송 완료를 확인했다고 고객이 상품 내용에 만족했거나 반품 의사가 없다고 추정하지 않습니다. 상태 문구도 응답에 없는 예상 도착시각이나 사고 원인을 덧붙이지 않습니다. 조회 실패 때에는 이전 완료 알림을 다시 보내는 대신 확인 필요 상태로 남깁니다.

비용과 확인 조건

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

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

연동 효과는 상태 변경 탐지 건수, 실제 필요한 알림 후보 수, 중복 후보 차단 수로 구분해 평가할 수 있습니다. 조회 성공률과 메시지 전달률은 서로 다른 지표이며 고객 통지의 품질을 API 호출 수 하나로 평가하지 않습니다.

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

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

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