SCM API 호출 제한: 오류 재처리가 새 주문을 막지 않게 하는 법

SCM API 재처리는 새 주문과 호출 한도를 나눠 써야 합니다. 2026-10-24 기준, 대기 후 재호출도 업무 기한을 넘기면 보류합니다.

오류 큐가 비어 가는데 새 주문의 처리가 늦어진다면 복구 호출이 같은 API 한도를 소비하는지 보세요. 정상 건을 자동 처리하고 예외만 사람이 확인하는 구조에도 호출 순서와 중단 기준이 필요합니다. 이 글은 실제 고객의 장애나 성과 사례가 아닌, SCM 연동을 인수할 때 사용할 설계·검수 제안입니다.

정상 호출과 재처리는 어떤 한도를 공유하나요?#

공급자가 한도를 계산하는 범위를 먼저 확인합니다. 같은 API라도 앱·계정·상점·엔드포인트별 제한이 다를 수 있고 여러 작업이 한도를 함께 쓸 수도 있습니다. 내부 큐나 작업자 수를 나누는 것은 외부 한도의 분리를 뜻하지 않습니다.

발주 책임자는 주문 접수·재고 갱신·과거 누락 복구의 허용 지연을 정하세요. 구현 담당자는 공급자 문서에서 한도 묶음과 대기 조건을, 운영 담당자는 수동 재처리 버튼을 포함한 호출 경로를 확인합니다. 전체 연동 계약을 정리하는 단계라면 API 연동 개발 가이드부터 보고 아래의 복구 검수를 덧붙이면 됩니다.

429와 Retry-After를 받으면 언제 다시 호출하나요?#

HTTP 429는 일정 시간에 요청이 너무 많았다는 응답입니다. 재호출 시점은 공급자의 정책과 응답을 확인해 정합니다. 한도 범위 전체에 대기가 적용되면 새 주문도 그 대기를 우회해서는 안 됩니다.

IETF RFC 6585의 429 정의는 Retry-After를 선택적으로 포함할 수 있다고 설명합니다. 사용자를 식별하고 요청 수를 세는 범위까지 통일하지는 않습니다. 2012년 4월 발행된 표준이며 2026년 10월 24일 확인했습니다.

RFC 9110의 Retry-After 형식은 HTTP 날짜 또는 응답을 받은 뒤 기다릴 초 단위 값입니다. 2022년 6월 발행됐으며 같은 날 확인했습니다. 아래 표는 표준 설명과 구분한 자사 검수 제안입니다. 헤더가 없거나 잘못된 경우의 처리는 공급자 정책에서 따로 확인합니다.

대기 시간이 끝났다는 사실만으로 다음 호출의 성공이 보장되지는 않습니다. 백오프에 지터를 넣더라도 공급자가 지정한 대기보다 일찍 보내지 않는 조건을 유지하세요. HTTP 날짜를 해석할 때의 시계 오차도 검수 대상입니다.

호출 예산에는 어떤 실행을 포함하나요?#

호출 예산은 같은 한도 안에서 정상 업무와 복구에 허용할 호출량을 정하는 운영 규칙입니다. 큐에서 꺼낸 작업 수가 아닌 실제 외부 API 호출을 기준으로 봅니다. SDK 내부 재호출과 사람이 누른 재실행도 포함합니다.

AWS Builders Library의 타임아웃·재시도·백오프 지침은 과부하 중 재시도가 부하를 키우고, 여러 계층의 재시도가 곱으로 늘어날 수 있다고 설명합니다. 제한된 재시도와 지터, 재시도 책임 지점의 조정을 검토하는 근거입니다. 2019년 12월 5일 발행됐으며 2026년 10월 24일 확인했습니다. AWS의 개별 설정을 모든 SCM API의 계약으로 적용하지는 않습니다.

공통 진입 제어는 한도 묶음별로 적용하고 수동 실행도 같은 경로를 거치게 합니다. 작업자가 늘어도 같은 묶음의 총량은 함께 계산해야 합니다. 지터는 재호출 시점을 분산할 뿐 호출권을 추가하지 않으며, 동시 실행 수만 낮춰도 짧은 요청이 빠르게 반복되면 호출 속도 제한을 넘을 수 있습니다.

새 주문 우선 처리만으로 복구가 끝나나요?#

새 주문을 무조건 우선하면 과거 누락의 복구가 계속 밀릴 수 있습니다. 정상·복구 양쪽의 업무 기한과 최장 대기를 관찰하고 배분 기준을 합의하세요. 정해진 한도에서 둘 다 기한을 지킬 수 없다면 우선순위와 수동 대응을 결정해야 합니다.

예를 들어 과거 누락분을 복구하는 도중 새 주문이 들어오는 상황을 검수 표본으로 만듭니다. 같은 계정 한도 안에서 복구 호출을 조절했을 때 새 주문이 합의한 기한에 처리되는지, 복구 큐도 계속 진행하는지 봅니다. 이는 가상 검수 상황이며 처리량이나 지연 개선 수치를 가정하지 않습니다.

재개 직전에는 주문의 현재 상태와 작업의 유효성을 다시 확인합니다. 취소됐거나 기한이 지난 지시를 오래된 내용 그대로 보내지 않습니다. 응답을 놓친 쓰기는 이미 반영됐을 수 있으므로 결과 확인과 멱등성 조건이 우선입니다. 상태·원본 책임은사내 시스템 통합 가이드, 물류 처리의 취소 경계는 WMS·OMS·TMS 연동 설계에서 별도로 확인할 수 있습니다.

오류 큐를 비우기 전에 무엇을 인수 검수하나요?#

재처리의 최종 성공 건수와 새 업무의 지연을 함께 봅니다. 한도 문서·입력 부하·업무 기한을 같은 조건으로 맞추고 아래 표본의 기대 결과를 합의하세요. 다음 표는 2026년 10월 24일 작성한 자사 검수 제안으로, 공급자별 수치는 확인한 문서와 측정값으로 채워야 합니다.

인계 기록에는 비식별 업무 키, 마지막 응답과 원격 반영 확인 상태, 다음 실행 가능 시각, 누적 시도·경과, 중단 사유와 담당자를 남깁니다. 보류는 원격 처리의 취소나 데이터 삭제를 뜻하지 않습니다. API 키·개인정보를 원문 로그로 남기지 않고, 기록의 보존·폐기 범위는 별도 정책으로 정합니다.

알파카랩스와 재처리 범위를 어떻게 정하나요?#

알파카랩스의 공개 업무 자동화 서비스는 API 권한·호출 제한 확인과 실패·중복·누락의 재처리, 수동 전환과 운영 인수 범위를 협의한다고 안내합니다. 게시일은 표시돼 있지 않으며 2026년 10월 24일 확인한 자사 제공 범위입니다. 모든 채널의 접근이나 일정한 처리량, 상시 운영 대행을 보장하는 설명은 아닙니다.

비식별 연동 목록, 공급자의 한도·오류 정책 문서, 업무별 허용 지연과 실패 표본을 준비하세요. 한도를 공유하는 범위와 재개·보류 조건, 인수 표본을 묶은 검수 조건 초안을 협의합니다. 별도 산출물과 비용·기간은 접근 조건과 운영 지원 범위를 확인한 뒤 정합니다.

SCM API 호출 제한과 재처리에서 자주 묻는 질문#

SCM API가 429를 반환하면 오류 건을 바로 재처리해도 되나요?

같은 요청을 즉시 반복하면 호출 제한이 이어질 수 있습니다. 공급자 문서와 Retry-After를 확인하고 해당 한도 범위의 대기를 지킨 뒤 다시 호출할 여유와 업무 유효기한을 확인합니다. 이미 반영됐을 가능성이 있는 쓰기는 결과 확인이 먼저입니다.

정상 주문 큐와 오류 큐를 나누면 API 한도도 분리되나요?

큐를 나누는 것만으로 공급자의 호출 한도가 늘거나 분리되지는 않습니다. 계정·앱·엔드포인트 등 공급자가 정한 한도 묶음을 확인하고 같은 묶음의 모든 호출을 함께 제어해야 합니다. 수동 재처리도 같은 진입 조건을 거칩니다.

Retry-After가 없는 API는 어떻게 재시도하나요?

공급자가 명시한 오류별 재시도 정책을 먼저 따릅니다. 별도 지침이 없다면 제한된 횟수와 누적 대기, 백오프·지터를 검토하되 헤더가 없다는 이유로 즉시 반복하지 않습니다. 정책과 한도를 확인할 수 없는 연동은 자동 복구 가능 범위를 미확인으로 남깁니다.

SDK에 재시도가 있으면 작업 큐에서도 다시 보내면 안 되나요?

SDK와 큐가 각각 재시도하면 실제 외부 호출이 예상보다 늘어날 수 있습니다. 재시도 정책의 책임 지점을 정하고 각 계층의 실제 호출 횟수·대기·중단 조건을 함께 검수하세요. 바깥 큐가 업무를 재개하더라도 안쪽 호출까지 포함한 총량과 기한을 관리해야 합니다.

업무 기한이 지난 실패 건은 삭제하면 되나요?

자동 재호출을 보류하고 책임자에게 넘기되 기록을 성공이나 삭제로 바꾸지 않습니다. 쓰기 응답이 불명확하면 원격 반영 여부를 먼저 확인하고 최신 주문 상태와 후속 업무를 판단합니다. 보존·폐기는 별도 정책에 따르며 보류가 원격 처리 취소를 뜻하지는 않습니다.