주문 수집 자동화가 성공했다는데, 왜 출고 목록에서 주문이 빠질까요?

🍎 바쁘다면 알짜배기만이라도 !

• 주문 수집 자동화가 오류 없이 끝나도, 한 번에 받은 주문만 저장하고 다음 묶음을 요청하지 않으면 나머지는 출고 목록에서 빠집니다. 파일이 만들어졌다는 것과 주문이 전부 들어 있다는 것은 다릅니다.
• 저장된 행 수가 원본 주문 수와 같아도 누락이 있을 수 있습니다. 주문당 한 행인 시험에서 같은 주문 100건을 두 번 받은 결과, 파일은 200행이었지만 서로 다른 주문은 100건뿐이었습니다.

주문 101건 중 파일에 남은 100건

주문 수집 자동화가 시험용 주문 101건 중 100건만 출고 목록에 저장하고도 오류 없이 끝났습니다. 2026년 10월 28일, 거래처 주문을 모아 창고에 출고 목록을 보내는 업무를 가정해 시험했습니다. 주문을 보내는 프로그램은 한 번에 최대 100건씩 전달하도록 만들었습니다. 받는 프로그램이 처음 받은 100건만 저장하고 다음 1건을 요청하지 않아 그 주문이 빠졌습니다.

빠진 한 건은 주문번호를 원본과 대조했을 때 드러났습니다. 받은 파일만 보면 주문번호도 있고 행도 채워져 있습니다. 운영팀장이 이 파일을 출고 목록으로 확정하면, 창고는 빠진 주문을 알 수 없습니다. 실제 고객 장애를 재현한 사례는 아닙니다. 설명용 주문 자료로 어디까지 받아야 수집을 끝낼 수 있는지 검사했습니다.

AI 출고 준비에 필요한 주문 목록의 완전성

AI에 출고 준비를 맡겨도, 수집되지 않은 주문은 처리 대상에서 빠집니다. 자료를 읽고 도구를 사용해 업무까지 수행하는 프로그램을 AI 에이전트라고 합니다. McKinsey Technology·QuantumBlack의 2026년 4월 분석은 이러한 프로그램의 안정적인 운영에 지속적인 고품질 데이터 공급과 데이터 품질 측정이 필요하다고 설명합니다. McKinsey·QuantumBlack, 2026.04

주문 취합에 이 지침을 적용하면 검사 대상은 읽은 값의 정확성뿐 아니라 읽지 못한 주문의 존재까지입니다. 주문번호와 수량을 정확히 읽었더라도, 다음 묶음의 주문을 수집하지 않았다면 전체 출고 목록은 틀립니다. 이 연결은 보고서의 실험 결과가 아닌, 주문 수집 업무에 대한 해석입니다. 화면을 읽는 AI든 정해진 순서로 클릭하는 자동화든, 전체 목록을 받았는지 판정하는 절차가 없으면 같은 누락을 놓칠 수 있습니다.

첫 페이지와 전체 목록의 차이

주문 목록은 여러 번에 나눠 받아야 할 수 있습니다. 화면에서는 아래쪽의 다음 페이지 버튼으로 보이고, 프로그램끼리 데이터를 주고받는 API에서도 한 번에 보내는 건수가 제한됩니다. 목록을 일정 건수씩 나눠 전달하는 것을 페이지 분할이라고 합니다. 화면 대신 공식 API를 쓴다는 이유만으로 전체 목록 수집이 보장되지는 않습니다.

Shopify의 주문 조회 API 문서는 한 번에 최대 250개를 조회하며, 다음 페이지가 있는지와 마지막 항목의 위치를 이용해 이후 자료를 요청하도록 설명합니다. 문서의 예제도 첫 결과를 받은 뒤 다음 요청을 별도로 구성합니다. 한 번의 요청을 정상 처리했다는 응답은 전체 주문 수집을 뜻하지 않습니다. 250개는 해당 API의 조건이고, 이번 설명용 서버의 100개는 임의로 정한 시험 조건입니다. Shopify 공식 페이지 분할 문서, 2026년 열람

페이지 누락·중복을 넣은 수집 시험

마지막 페이지까지 요청한 프로그램은 같은 주문 101건을 모두 저장했습니다. 시험에서는 원본 주문을 고정하고, 첫 페이지만 저장하는 프로그램과 다음 페이지가 없을 때까지 요청하는 프로그램을 비교했습니다. 요청을 받은 프로그램은 매번 정상 처리됐다는 응답을 보냈습니다. 그 응답과 수집한 주문번호를 함께 기록했습니다.

행 수 대조만으로는 중복 페이지를 구별하지 못했습니다. 주문 200건을 준비하고 두 번째 응답에 첫 100건을 다시 보내도록 하자, 마지막 페이지까지 요청한 프로그램도 200행을 저장했습니다. 그러나 서로 다른 주문번호는 100개뿐이었고, 원본의 나머지 100건은 없었습니다. 파일의 행 수와 원본 건수는 일치해도, 같은 주문이 두 번 들어간 것입니다.

시험 자료는 누락 원인을 드러내려고 의도적으로 구성했습니다. 이 결과는 AI 정확도나 상용 RPA의 오류율이 아니며, 실제 거래처 API·화면·ERP에 연결한 시험도 아닙니다. 조회 중 신규 주문이나 취소가 생기는 조건은 이번 고정 자료 시험에 포함하지 않았습니다.

출고 확정에 필요한 원본 주문번호 대조

출고 목록을 확정할 근거는 같은 조회 범위의 원본 주문과 수집 결과가 일치하는지에 있습니다. 날짜, 마감 시각, 주문 상태가 같아야 대조할 수 있습니다. 오전 9시까지 접수된 주문을 수집해 놓고 오전 9시 10분의 전체 주문 수와 비교하면, 그 사이 들어온 주문을 수집 누락으로 오해할 수 있습니다.

원본 목록이나 별도 내려받기 파일을 확보할 수 있다면, 주문번호별로 빠진 건과 중복된 건을 찾을 수 있습니다. 여러 거래처의 번호가 겹칠 수 있는 업무에서는 거래처와 주문번호를 함께 대조합니다. 한 주문에 품목이 여러 개인 자료라면 주문 한 건이 여러 행일 수 있으므로, 단순히 같은 주문번호가 반복됐다는 이유로 행을 삭제해서도 안 됩니다. 이번 시험은 주문당 한 행으로 제한했습니다.

원본 전체 목록을 확보할 수 없는 사이트에서는 완료 판정의 근거가 약해집니다. 마지막 페이지 도달 여부와 표시된 총건수는 검사할 수 있지만, 그 정보만으로 원본의 모든 주문번호와 일치한다고 단정할 수는 없습니다. 수집 파일만 사람이 다시 읽어도 빠진 주문은 찾을 수 없습니다. 거래처에서 같은 마감 시각의 원본 주문 목록을 받는 등 대조 근거가 필요합니다. 다른 경로로도 누락 여부를 판별할 수 없다면 자동 출고 확정은 보류하는 편이 타당합니다.

주문량 증가 때 달라지는 검수 결과

100건으로 성공한 시연은 101건의 수집을 보장하지 못했습니다. 첫 페이지만 저장하는 프로그램도 주문이 한 페이지 안에 있으면 정상 결과를 냈기 때문입니다. 무인 주문 수집의 검수 자료에 페이지 경계를 넘는 주문과 중복 페이지를 포함할 이유가 여기에 있습니다. 이미 원본 주문번호 대조와 누락 시 출고 보류가 구현돼 있다면 같은 검사를 새로 개발할 필요는 없습니다.

주문이 없는 날까지 오류로 처리하는 것도 맞지 않습니다. 이번 시험에서 정상 조회 결과가 0건인 조건은 원본과 수집 결과가 모두 비어 있어 일치했습니다. 운영팀장이 구분할 것은 주문이 없는 날과, 주문이 있는데 파일에 없는 날입니다. 그 차이는 프로그램의 정상 종료 표시만으로는 알 수 없습니다.