SCM 일괄 처리 검수: HTTP 200과 항목별 성공 구분

SCM 일괄 요청은 HTTP 200이어도 항목별 결과를 대조합니다. 2026-11-02 기준, 접수는 최종 업무 완료와 나눕니다.

여러 항목을 한 번에 전달한 뒤 화면에 완료가 표시됐지만, 일부 결과는 거절되거나 도착하지 않은 상황을 가정해 보겠습니다. 전체 요청의 응답만 저장하면 담당자는 어느 항목을 확인해야 할지 알기 어렵습니다. 이 글은 기존 시스템 연동의 오류 확인 요구를 일반화한 검수 설계이며, 특정 고객의 장애나 구축 성과를 소개하는 글은 아닙니다.

전체 요청과 항목 결과를 왜 나눠야 하나요?#

일괄 응답이 알려주는 단계와 업무의 완료 기준이 다를 수 있기 때문입니다. 요청을 묶어 보냈다는 사실이 모든 항목의 원자적 처리나 실행 순서를 보장하지는 않습니다. 인수 문서에서 아래 확인 단위를 분리합니다.

여러 수집 페이지를 어디서 재개할지 결정하는 문제는 SCM 증분 수집의 체크포인트 검수에서 다룹니다. 이번 범위는 한 일괄 요청 안에서 각 항목에 돌아온 결과를 연결하고 표시하는 계약입니다.

공식 API도 전체 200과 항목별 실패를 구별하나요?#

공개된 API 가운데 이 구분을 명시하는 사례가 있습니다. Microsoft Graph의 JSON batching 문서는 전체 200이 개별 요청의 성공을 뜻하지 않는다고 설명합니다. 개별 응답이 요청과 다른 순서로 올 수 있어 id로 대응시키도록 안내합니다. 문서의 최종 갱신일은 2025-02-21, 확인일은 2026-11-02입니다.

Amazon SQS의 SendMessageBatch API 문서도 HTTP 200에서 성공과 실패가 섞일 수 있으므로 배치 오류를 확인하도록 안내합니다. 결과는 Successful과 Failed로 구분됩니다. 발표·최종 갱신일이 표시되지 않은 롤링 문서이며 2026-11-02 확인했습니다.

두 서비스는 계약을 설명하는 예시입니다. 고객의 SCM이 Graph나 SQS를 쓴다는 뜻도, 같은 필드 이름을 반환한다는 뜻도 아닙니다. 사용하는 공급자의 문서와 비식별 응답에서 항목 식별자·결과 상태·원자성·의존성 규칙을 따로 확인하세요. 전체 상태 코드의 의미를 항목 결과에 그대로 복사하지 않는 것이 검수의 출발점입니다.

요청 항목과 응답은 어떻게 연결하나요?#

요청 전에 기대 항목 목록을 남기고, 응답의 항목 ID로 대조합니다. 원천 시스템·업무 키·작업 종류와 입력 버전, 요청 시도 식별자를 연결하면 화면의 행 순서가 바뀌어도 추적할 수 있습니다. 추적용 키가 곧 공급자의 멱등 보장이라는 뜻은 아닙니다.

아래 JSON은 운영 대조를 위한 가상 정규화 기록입니다. 외부 API의 실제 요청·응답 형식이나 고객 자료가 아닙니다. 기대 목록은 r-a·r-b·r-c인데, 반환 기록에는 r-b의 거절과 r-a의 접수만 있습니다.

{
  "expected": ["r-a", "r-b", "r-c"],
  "results": [
    {"id": "r-b", "state": "rejected", "reason": "invalid_input"},
    {"id": "r-a", "state": "accepted", "receipt": "ack-a"}
  ]
}

r-a를 바로 업무 완료로, r-c를 미실행 확정으로 표시하면 근거보다 넓은 결론입니다. 동일 항목의 결과가 중복되거나 기대 목록에 없는 ID가 오면 위치로 끼워 맞추지 말고 응답 이상으로 분리합니다. ID의 대소문자 처리 등 비교 규칙은 해당 공급자 계약을 따라야 합니다.

어떤 표본으로 전체 완료 표시를 검수하나요?#

정상 순서의 전부 성공만 시험하지 않습니다. 같은 기대 목록에 응답 순서 변경·혼합 결과·누락·중복을 넣고 각 항목의 표시가 유지되는지 확인합니다. 아래 표는 항목 결과의 완비성과 업무 완료를 나누는 자체 인수 정책입니다.

건수만 맞추면 중복 결과가 누락을 가릴 수 있습니다. 기대 ID 집합과 응답 ID의 대응, 중복·미지 ID를 함께 확인하고 알려지지 않은 상태 값도 자동 성공으로 넘기지 않습니다. 최종 결과가 뒤늦게 도착하면 어떤 시도의 결과를 갱신하는지도 연결합니다.

접수 확인 뒤 재처리는 언제 결정하나요?#

성공의 단계부터 확인합니다. RFC 9110의 202 Accepted 정의는 요청을 처리하도록 접수했지만 완료하지는 않았다는 의미입니다. 2022년 6월 발행 원문을 2026-11-02 확인했습니다. 큐에 메시지를 넣는 데 성공했다는 결과도 그 뒤의 ERP 반영 증거를 대신하지 않습니다.

거절 원인을 해결할 수 있는지, 같은 작업의 결과를 조회할 수 있는지, 중복 방지·선행 작업 의존성이 어떤지 확인한 뒤 재처리 후보를 정합니다. 결과가 미확인인 항목과 이미 확정된 항목을 묶어 무조건 재전송하지 않습니다. 호출 한도와 복구 기한은 SCM API 재처리 예산에서 별도로 정리합니다.

원장을 바꾸는 작업이라면 ERP 변경의 승인·경합·재실행 검수도 필요합니다. 배치 응답 대조가 실행 승인이나 전체 롤백 기능을 만들어 주지는 않습니다. 검수 로그에는 비식별 키와 필요한 결과 근거를 남기고 고객 원문·인증 정보를 그대로 복제하지 않습니다.

알파카랩스의 공개 업무 자동화·API 연동 서비스는 부분 수집·중복·누락과 재처리, 운영 인수 조건을 협의한다고 설명합니다. SCM 운영대시보드 서비스의 기본 범위는 조회·대사이며 실행은 별도 요구사항입니다. 2026-11-02 확인한 자사 제공 범위의 자기표기이며, 이 글의 배치 검수 기능을 특정 제품이나 고객에게 구현했다는 주장은 아닙니다.

SCM 일괄 처리 검수 FAQ#

일괄 API가 HTTP 200이면 모든 항목이 성공한 건가요?

개별 API의 계약을 확인해야 합니다. Microsoft Graph의 JSON batch와 Amazon SQS SendMessageBatch는 전체 응답이 200이어도 개별 실패가 있을 수 있다고 안내합니다. 사용하는 SCM 연동도 항목별 결과를 어디에서 확인하는지 먼저 정하세요.

응답 배열의 순서대로 요청 항목과 연결해도 되나요?

순서를 보장하는 계약이 없다면 항목 식별자로 연결합니다. Microsoft Graph는 개별 응답 순서가 요청과 다를 수 있다고 명시합니다. 공급자의 ID 비교 규칙을 따르고 중복·미지 ID와 응답 없는 항목을 별도로 검수합니다.

응답에서 빠진 항목은 실패로 보고 바로 재전송하나요?

결과를 받지 못했다는 사실만으로 미실행을 확정하지 않습니다. 상태 조회나 원천의 처리 이력으로 확인하고, 확인할 수 없으면 결과 미확인으로 남깁니다. 재전송은 중복 방지와 의존성·승인 범위를 확인한 뒤 결정합니다.

접수 성공이나 큐 등록 성공도 업무 완료인가요?

해당 단계의 성공입니다. RFC 9110의 202 Accepted는 처리 접수와 완료를 구별하며, 큐 등록 결과만으로 이후 ERP 반영까지 확인할 수는 없습니다. 업무가 끝나는 기준 시스템과 결과 증거를 별도로 합의해야 합니다.

부분 실패가 생기면 배치 전체를 되돌릴 수 있나요?

전체 원자성이나 롤백 지원은 API별 계약입니다. 일부 항목이 이미 반영됐다면 보상 처리도 새로운 업무 변경이 될 수 있습니다. 항목별 확정 결과와 후속 의존 작업, 권한을 확인하고 복구 범위를 정합니다.

항목별 결과 대사표를 준비하세요#

비식별 요청 항목 목록과 응답, 최종 확정 근거를 같은 표에 놓으세요. 접수·거절·미확인과 응답 이상을 구분하면 운영자가 확인할 항목과 인수 범위를 정할 수 있습니다. 준비·상담 시간과 비용은 API 접근 조건, 처리 종류와 최종 확인 수단을 검토한 뒤 협의합니다.