Tracking API 가격 모델 설명: 호출당 과금 vs 배송 건당 과금 및 실제 비용 추정 방법
호출당 추적 API 가격은 청구 가능한 요청에 대해 요금을 부과하고, 배송 건당 가격은 등록된 추적 번호와 같은 정의된 추적 단위에 대해 요금을 부과합니다. 어느 쪽이 자동으로 더 저렴한 것은 아닙니다. 실제 비용을 추정하려면 동일한 배송 물량, 업데이트 요구 사항, 추적 기간 및 청구 규칙을 기준으로 두 모델을 비교한 다음 플랫폼 요금, 초과 사용료 및 통합 비용을 추가하세요.
엔지니어링, 운영 및 조달 팀에 유용한 비교 기준은 단순히 호출당 가격과 배송 건당 가격 중 어느 쪽이냐가 아닙니다. 핵심은 비즈니스에 필요한 배송 가시성을 제공하는 데 드는 총비용입니다. 요청 빈도가 낮더라도 빈번한 폴링으로 비용이 커질 수 있고, 배송 건수가 적더라도 추적 기간이나 포함 서비스가 워크플로에 맞지 않으면 오해를 불러일으킬 수 있습니다.
각 가격 모델이 실제로 측정하는 것
첫 단계는 세 가지를 구분하는 것입니다. API 요청, 배송 등록, 추적 업데이트는 서로 다른 이벤트이며, 계약에 따라 각각 다른 청구 방식이 적용될 수 있습니다.
| 비교 항목 | 호출당 가격 | 배송 건당 가격 |
|---|---|---|
| 청구 기준 | 청구 가능한 것으로 정의된 요청 또는 요청 단위 | 청구 가능한 것으로 정의된 배송 단위 |
| 주요 비용 요인 | 애플리케이션이 청구 가능한 요청을 수행하는 빈도 | 청구 가능한 추적 단위가 범위에 들어오거나 남아 있는 수 |
| 해결해야 할 청구 질문 | 어떤 엔드포인트, 응답 및 배치 항목이 집계되는가? | 배송 1건은 무엇으로 구성되며, 추적은 얼마 동안 포함되는가? |
| 잠재적 비용 노출 | 반복 폴링, 재시도 및 불필요한 조회 | 중복 등록, 여러 소포 및 추적 기간 제한 |
| 가장 적합할 수 있는 조건 | 요청량이 통제되는 저빈도 조회 | 업데이트가 배송 요금에 포함된 지속적인 모니터링 |
호출당 가격이라고 해서 모든 HTTP 요청의 비용이 반드시 같은 것은 아닙니다
견적에는 청구 가능한 엔드포인트와 해당 단위를 명시해야 합니다. 추적 번호 등록, 저장된 결과 조회, 새로고침 요청 및 구독 관리는 서로 다른 방식으로 처리될 수 있습니다. 실패한 요청이 무료라거나 성공한 요청은 항상 청구된다고 가정하지 마세요.
배치에 대해서도 명확한 정의가 필요합니다. 추적 번호 100개가 포함된 하나의 요청이 요청 1건, 추적 단위 100개 또는 계약상 다른 수량으로 계산될 수 있습니다. 네트워크 트래픽을 줄였다고 해서 과금 측정 규칙이 이를 뒷받침하지 않는 한 비용이 절감되는 것은 아닙니다.
배송 건당 가격이라고 해서 반드시 주문 건당 가격을 의미하지는 않습니다
전자상거래 주문 1건에서 여러 소포가 발생할 수 있습니다. 청구 단위가 추적 번호라면 분할 주문은 여러 단위를 사용할 수 있습니다. 반품, 교체 배송 및 운송업체 인계도 명확하게 처리해야 합니다.
요금이 특정 기간 동안의 추적을 구매하는 것인지, 정의된 완료 이벤트까지의 추적인지, 아니면 다른 제한이 적용되는지 확인하세요. 이미 등록된 배송이 이후 청구 기간에 새로운 요금을 발생시키는지도 정해야 합니다. 이러한 세부 사항은 가격 플랜의 명칭보다 더 중요합니다.
주문 수가 아니라 워크플로에서 비용을 추정하세요
대표적인 운영 기간을 정하고 배송 수준의 데이터를 기반으로 예측을 작성하세요. 신규 배송뿐 아니라 계속 모니터링해야 하는 이전 배송도 포함하세요. 데이터가 불완전하다면 결과를 정확한 견적으로 제시하기보다 가정을 명시하세요.
- 추적 가능한 소포를 계산하세요. 결제 주문이 아니라 고유한 소포 추적 단위부터 시작하세요. 청구 방식이 확인될 때까지 발송 소포, 반품 및 교체 배송을 별도로 관리하세요.
- 모니터링 기간을 측정하세요. 관련되는 경우 운송 전 기간과 예외 기간을 포함하여 각 배송에 업데이트가 필요한 기간을 추정하세요.
- 필요한 업데이트 빈도를 정의하세요. 애플리케이션에 최신 정보가 필요한 빈도와 배송 상태에 따라 그 빈도가 달라지는지 지정하세요.
- API 워크플로를 매핑하세요. 통합에서 사용할 등록, 결과 조회, 새로고침 요청, 수정, 재시도 및 기타 엔드포인트를 나열하세요.
- 청구 규칙을 적용하세요. 제안된 계약을 사용하여 기술 활동을 청구 가능한 호출 또는 배송 단위로 변환하세요.
- 사용량 외 요금을 추가하세요. 해당되는 구독료, 최소 약정, 선택 서비스 및 구현 또는 운영 비용을 포함하세요.
조회 1회당 추적 번호 하나를 사용하는 단순한 폴링 통합의 경우 시작 추정치는 다음과 같습니다.
조회 요청 수 = 모니터링 배송 수 × 평균 모니터링 일수 × 일일 조회 수
이 간편한 계산은 모든 배송이 동일한 평균 일정으로 진행된다고 가정합니다. 더 정확한 모델은 각 배송 또는 배송 코호트의 요청을 합산한 다음 등록 호출 및 기타 청구 가능한 활동을 추가합니다. 배송이 월말을 넘어 활성 상태로 남아 있는 경우 해당 요청이 발생한 청구 기간에 요청을 배분하세요.
계산 예시: 더 저렴한 모델이 바뀌는 경우
다음 수치는 계산을 설명하기 위해서만 가정한 것입니다. 17TRACK의 가격, 공급업체 견적 또는 시장 벤치마크가 아닙니다.
10,000개의 소포가 동일한 모델링 기간 내에 등록되고 완전히 모니터링된다고 가정해 보겠습니다. 각 소포에는 등록 요청 1회와 8일 동안 하루 3회의 조회 요청이 필요합니다. 모든 요청이 청구 가능하고, 각 요청이 하나의 소포와 관련되며, 재시도, 배치 할인, 허용량 또는 고정 요금은 없다고 가정합니다.
- 등록 요청: 10,000회.
- 조회 요청: 10,000 × 8 × 3 = 240,000회.
- 총 청구 가능 요청: 250,000회.
- 예시 호출당 요금: $0.002.
- 예시 배송 건당 요금: 필수 모니터링을 포함하여 $0.04.
호출당 사용 비용은 250,000 × $0.002 = $500입니다. 배송 건당 사용 비용은 10,000 × $0.04 = $400입니다. 이러한 가정에서는 배송 건당 가격이 사용량 기준으로 $100 더 저렴합니다.
이제 조회 빈도만 하루 1회로 변경해 보겠습니다. 요청 수는 등록 10,000회와 조회 80,000회를 합한 90,000회가 됩니다. 호출당 사용 비용은 $180로 낮아지는 반면, 예시 배송 건당 사용 비용은 $400로 유지됩니다. 선호하는 모델이 바뀌는 이유는 어느 가격 구조가 본질적으로 더 우수해서가 아니라 작업량이 변했기 때문입니다.
손익분기점을 찾으세요
두 플랜에 고정 요금, 허용량 또는 추가 요금이 없을 때는 다음을 사용하세요.
배송 1건당 손익분기 청구 가능 호출 수 = 배송 요금 ÷ 호출 요금
이 예시에서는 $0.04 ÷ $0.002가 배송 1건당 청구 가능 호출 20회입니다. 호출 수가 20회를 초과하면 배송 요금이 더 낮고, 20회 미만이면 호출 요금이 더 낮습니다. 이 예시의 가정에서는 등록 호출도 해당 기준에 포함됩니다.
이 간편 계산은 단계별 요금제, 선불 크레딧, 엔드포인트별 요금 또는 최소 약정에는 충분하지 않습니다. 이러한 상품의 경우 명시된 단가만 비교하지 말고 각 예측 물량에서 전체 청구서를 계산하세요.
웹훅은 폴링을 줄일 수 있지만 청구 확인은 여전히 필요합니다
폴링은 애플리케이션이 추적 정보를 반복적으로 요청하는 방식입니다. 웹훅을 사용하면 서비스가 애플리케이션으로 이벤트를 전송하므로, 이벤트 스트림이 요구 사항을 충족할 때 반복 조회의 필요성을 줄일 수 있습니다.
그러나 조회 요청이 줄었다고 해서 청구서가 자동으로 낮아지는 것은 아닙니다. 웹훅 전송이 포함되는지, 전송 또는 재시도가 과금되는지, 조정 조회가 여전히 필요한지 확인하세요. 또한 애플리케이션은 중복 이벤트나 순서가 뒤바뀐 이벤트를 안전하게 처리하고 전송 실패에서 복구할 수 있어야 합니다.
또 하나 구분해야 할 점은 정보를 더 자주 요청한다고 해서 기본 운송업체가 새로운 스캔을 생성했다는 보장은 없다는 것입니다. 운영상 가치가 거의 없는 폴링 빈도에 비용을 지불하기 전에 조회 결과와 데이터 새로고침 방식이 무엇인지 확인하세요.
표면적인 요금에 숨겨질 수 있는 비용
포함 허용량, 최소 요금 및 선불 잔액
최소 청구 금액과 사용량이 포함된 구독을 구분하세요. 최소 청구 금액은 지출 하한을 설정할 수 있고, 허용량은 초과 사용료가 적용되기 전에 정해진 수량을 보장할 수 있습니다. 선불 크레딧에는 만료, 환불 및 미사용 잔액에 대한 별도의 질문이 발생합니다.
초과 사용료보다 먼저 허용량이 차감되는 플랜에는 다음과 같은 구조가 유용합니다.
API 청구액 = 고정 플랜 요금 + 청구 가능한 초과 사용료 + 해당 추가 기능 요금
이 공식이 계약과 일치하는 경우에만 사용하세요. 동일한 포함 사용량을 두 번 더하거나 모든 플랜이 동일한 방식으로 한계 요금을 적용한다고 가정하지 마세요.
장기 운송 중인 배송과 반복 등록
폴링 방식에서는 모니터링 기간이 길어질수록 조회량이 증가합니다. 배송 건당 가격에서는 최초 요금이 해당 기간을 포함하는지가 핵심 질문입니다. 빠르게 완료되는 배송뿐 아니라 예외 상황과 지연 배송도 테스트하세요.
또한 동일한 추적 번호가 두 번 제출되거나, 수정되거나, 삭제 후 다시 추가되거나, 다른 운송업체와 연결될 때 어떻게 처리되는지 확인하세요. 적절한 경우 중복 방지를 구현하되, 애플리케이션 수준의 중복 제거가 공급업체의 청구 식별 기준과 완전히 일치한다고 가정하지 마세요.
요청 제한 및 피크 용량
월간 허용량이 저렴하다고 해서 통합이 대규모 가져오기나 트래픽 급증을 처리할 수 있다는 뜻은 아닙니다. 요청 속도 제한, 배치 제한, 동시성 제한 및 제한에 도달했을 때의 예상 동작을 확인하세요. 월간 물량은 충족하지만 필요한 워크플로를 지원할 수 없는 플랜은 동일한 조건의 대안이 아닙니다.
엔지니어링 및 운영 비용
API 청구서와 총 소유 비용을 분리하세요. 내부 비용에는 통합 개발, 웹훅 호스팅, 큐, 모니터링, 장애 대응, 데이터 저장 및 유지 관리가 포함될 수 있습니다.
자체 인력 및 인프라 추정치를 사용하세요. 더 비싼 구독이라도 운영 작업을 실제로 줄인다면 경제적일 수 있지만, 그러한 절감 효과는 가정하지 말고 검증해야 합니다.
견적을 비교하고 최종 후보를 검증하는 방법
각 공급업체에 동일한 작업 사양을 기준으로 가격을 제시하도록 요청하세요. 사양에는 소포 물량, 배송 구성, 모니터링 기간, 업데이트 요구 사항, 엔드포인트, 피크 부하 및 필요한 서비스가 포함되어야 합니다. 청구 단위에 대한 서면 설명과 샘플 청구 계산도 요청하세요.
17TRACK을 고려하는 팀이라면 공식 Tracking API 페이지와 API 문서가 제품 및 통합 평가를 위한 관련 출발점입니다. 예측에 모델을 배정하기 전에 해당 가격 및 청구 정의를 직접 확인하세요. 이 문서는 현재 17TRACK 플랜의 가격을 제시하거나 분류하지 않습니다.
약정하기 전에 대표적인 배송을 사용하여 통제된 파일럿을 실행하세요. 분할 주문, 중복 제출, 지연 소포, 국경 간 이동 및 청구 경계를 넘는 배송을 포함하세요. 서비스가 허용하는 방식으로만 실패 또는 재시도 동작을 테스트하세요.
- 요청 로그를 공급업체의 사용량 기록과 비교하세요.
- 등록된 추적 단위와 청구된 배송 단위를 대조하세요.
- 필요한 업데이트 주기가 실제로 달성되는지 확인하세요.
- 피크 수요를 월간 사용량과 별도로 측정하세요.
- 비용을 확대 추정하기 전에 설명되지 않은 차이를 조사하세요.
최소 세 가지 예측을 작성하세요. 정상 운영, 계절적 피크 및 장기 운송입니다. 청구서에 임의의 비율을 추가하지 말고 기본 요인을 변경하세요. 예를 들어 피크 상황에서는 더 많은 소포를, 지연 상황에서는 더 긴 모니터링 기간을 모델링하세요.
어떤 모델을 선택해야 할까요?
호출당 가격을 선호하세요 조회 빈도가 낮고 요청 수요를 측정할 수 있으며, 등록 및 기타 청구 가능한 활동을 포함한 예측이 손익분기점보다 낮을 때입니다. 빈번한 폴링이나 예측하기 어려운 모니터링 기간으로 요청 비용 노출이 상당해지는 경우에는 덜 매력적입니다.
배송 건당 가격을 선호하세요 지속적인 모니터링이 필요하고 견적된 배송 요금에 필요한 업데이트 빈도, 추적 기간 및 전송 방식이 포함될 때입니다. 거의 사용하지 않는 모니터링에 비용을 지불하거나 배송 정의로 인해 예상치 못한 추가 단위가 발생하는 경우에는 덜 매력적입니다.
최종 결정에는 운영 소포 1개당 총비용을 사용해야 합니다. 즉 API 청구액에 귀속 가능한 운영 비용을 더한 후, 비즈니스에서 모니터링해야 하는 고유 소포 수로 나눈 값입니다. 공급업체마다 다른 청구 단위를 사용하더라도 견적 간 내부 소포 정의는 일관되게 유지하세요.
FAQ
실패한 API 요청도 청구되나요?
어느 쪽이라고 가정하지 마세요. 유효성 검사 오류, 인증 실패, 속도 제한 응답, 서버 오류 및 시간 초과의 처리 방식을 문의하세요. 시간 초과가 발생하면 애플리케이션이 재시도하기 전에 요청이 처리되었는지 여부가 불확실해질 수도 있습니다.
주문 1건은 항상 배송 1건으로 계산되나요?
아닙니다. 하나의 주문에 별도로 추적되는 여러 소포가 포함될 수 있습니다. 예산을 책정할 때 주문을 추적 단위에 매핑한 다음 공급업체의 정의를 적용하세요. 반품, 교체 및 운송업체 인계가 어떻게 계산되는지 확인하세요.
배치 요청을 사용하면 청구액이 줄어드나요?
청구 규칙이 배치를 유리하게 취급하는 경우에만 그렇습니다. 배치는 네트워크 요청을 줄일 수 있지만 청구 가능한 추적 단위를 줄이지는 않을 수 있습니다. 배치 제한과 청구가 요청당, 항목당 또는 가중 단위를 통해 적용되는지 확인하세요.
웹훅으로 모든 조회 요청을 없앨 수 있나요?
일상적인 폴링을 상당 부분 제거할 수 있지만, 설계상 초기 조회, 누락된 이벤트 이후의 복구 또는 주기적인 조정이 여전히 필요할 수 있습니다. 해당 호출을 추정에 포함하고 웹훅 전송에 요금이 부과되는지 확인하세요.
다음 달에도 계속 활성 상태인 배송의 예산은 어떻게 책정해야 하나요?
호출당 가격의 경우 해당 배송이 다음 기간에 생성할 요청을 예측하세요. 배송 건당 가격의 경우 모니터링이 계속 포함되는지 또는 추가 요금이 발생하는지 확인하세요. 진행 중인 작업량을 추정할 때 새로 생성된 배송만 계산하지 마세요.
출처
위 계산은 공개된 공급업체 가격이 아니라 명시적으로 가정한 입력값을 사용합니다. 17TRACK을 평가할 때는 다음 공식 참조 페이지를 사용하고 상업적 조건을 직접 확인하세요.
