구매대행 주문부터 창고 출고까지의 처리 흐름

작성 2026-09-16

고객 구매신청 한 건이 결제확인, 중국 발주, 현지 입고, 검수, 합포장, 국제배송을 거쳐 고객에게 도착할 때까지 시스템이 관리해야 하는 상태와 데이터를 순서대로 정리했습니다.

한 건의 주문이 거치는 길

고객이 버튼 하나를 누르면 시스템 안에서는 여러 개의 데이터가 생기고, 서로 다른 속도로 움직입니다. 이 글은 구매신청 한 건이 국내 고객의 손에 닿을 때까지 시스템이 관리해야 하는 상태를 순서대로 정리한 것입니다.

1단계. 구매신청 → 주문 생성

고객이 SKU와 수량을 선택해 신청하면 주문이 만들어집니다. 이때 금액은 아직 확정이 아닙니다. 국제 배송비는 실물 무게가 나와야 정해지기 때문입니다. 화면에는 예상 금액임을 명확히 표시하고, 데이터에는 예상 금액과 확정 금액을 각각 둡니다.

2단계. 결제확인

입금이 확인되면 주문이 확정됩니다. 여기서 흔히 놓치는 것은 부분 입금과 초과 입금입니다. 결제 여부를 true/false로만 관리하면 이 두 가지를 표현할 수 없습니다. 금액 이력(입금·환불·추가 청구)을 쌓고, 주문 상태는 그 합계에서 계산하는 방식을 권합니다.

3단계. 발주 분할

확정된 주문의 상품들을 판매자별로 묶어 발주합니다. 한 주문에서 세 개의 발주가 나올 수 있습니다. 각 발주는 자기 상태를 가집니다.

• 발주 대기 — 아직 구매하지 않음
• 발주 완료 — 구매 완료, 판매자 발송 대기
• 부분 발주 — 일부 수량만 구매됨
• 품절 — 구매 불가. 고객 안내와 환불/대체 흐름으로 이어짐

주문 상태는 이 발주 상태들에서 파생됩니다. 예를 들어 발주 중 하나라도 품절이면 주문은 담당자 확인이 필요한 상태로 바뀌어 처리 대기 목록에 올라갑니다.

4단계. 입고예정 생성

발주가 완료되면 현지 창고에 입고예정이 생깁니다. 이 데이터가 없으면 창고에 도착한 박스를 어느 발주와 맞춰야 할지 알 수 없습니다. 입고예정에는 발주 번호, SKU, 예정 수량, 예상 도착일이 들어갑니다.

5단계. 입고와 검수

도착한 물건을 입고예정과 대조합니다. 이 단계에서 기록해야 하는 것은 수량만이 아닙니다.

• 실입고 수량 (예정과 차이가 있으면 차이 사유)
• 파손·오배송 여부와 사진
• 검수 담당자와 시각

검수를 통과한 물건에 자체 바코드를 붙입니다. 이 순간부터 물건은 '발주의 일부'가 아니라 '창고의 재고'가 되고, 이후 모든 작업은 스캔으로 처리됩니다.

6단계. 합포장

같은 고객의 여러 발주 건이 모이면 한 박스로 묶습니다. 여기서 데이터 구조가 한 번 더 바뀝니다.

7단계. 출고와 국제배송

박스별 무게·부피가 확정되면 실제 배송비가 나옵니다. 이 시점에 예상 금액과의 차액을 정산합니다 (추가 청구 또는 환불). 운송장을 발행하고 재고를 차감하면 출고가 끝납니다.

8단계. 통관과 국내 배송

통관에 필요한 정보는 필요한 범위만 수집하고 보관 기간을 정해 관리합니다. 국내 택배로 인계되면 운송장이 또 바뀌므로, 고객 화면에서는 국제 구간과 국내 구간을 하나의 타임라인으로 이어 보여 줍니다.

상태 설계에서 기억할 두 가지

고객이 보는 상태와 내부 상태를 분리한다

내부에는 "부분 발주", "검수 보류" 같은 상태가 필요하지만 고객에게는 혼란만 줍니다. 내부 상태를 그대로 노출하지 말고, 고객용 상태로 변환해 보여 주는 계층을 두십시오.

모든 상태 변경에 이력을 남긴다

"언제 누가 이 주문을 배송중으로 바꿨는가"를 답할 수 없으면, 문제가 생겼을 때 원인을 찾을 수 없습니다. 상태 이력은 용량을 거의 차지하지 않지만, 운영에서 가장 자주 들여다보는 데이터가 됩니다.

정리

구매대행 물류의 복잡함은 데이터 단위가 세 번 바뀐다는 데서 옵니다. 주문(고객 단위) → 발주(판매자 단위) → 박스(배송 단위). 이 세 단위를 각각 독립된 데이터로 두고 서로 연결하면 대부분의 예외 상황을 표현할 수 있습니다. 반대로 하나로 합치면, 처음에는 단순해 보이지만 곧 담당자의 메모장이 시스템을 대신하게 됩니다.

관련 내용