분산 주문 관리(DOM, Distributed Order Management)는 단일 창고가 아닌 다수의 풀필먼트 거점(Fulfillment Node) 중에서 EDD(약속 도착일) · 재고 · 용량 · 비용을 종합 평가해 주문 한 건당 최적 거점을 결정하는 오케스트레이션 계층이다. 거점이 많아질수록 의사결정 공간이 폭발적으로 커지므로, 사람이 룰로 관리하는 방식은 200ms 이내 응답·99.5% 매칭 정확도 같은 e-commerce SLA를 맞출 수 없다.

RT-O1은 이를 해결하기 위해 DOM Score Engine(Python)과 n8n 워크플로우를 결합한 1차 프로토타입이다. 주문이 들어오면 전처리 → 카테고리 분류(STD/EXPRESS/COLD) → DOM 거점 선택 → 재고 Lock → WMS 피킹 지시 → TMS 배차 연동 → EDD 통보 → PromiseLog 갱신까지를 단일 워크플로우로 자동화한다. 1월 테스트에서 예외 상황 90% 무인 처리를 목표했으나 단일 레이블 분류의 한계로 미달했고, 2월 RT-O2에서 멀티 레이블로 보강할 예정이다.

def score_node(order, node, carrier):
    # 1) 재고 가용 여부
    inv_ok    = inventory.check(node.id, order.skus)
    # 2) 도착 예상 시간 (lead + 운송)
    eta_hr    = node.lead_hr + carrier.transit_hr
    edd_score = 1.0 if eta_hr <= order.requested_hr else 0.0
    # 3) 거점 큐 여유 (capacity)
    cap_score = 1 - (node.queue / node.capacity)
    # 4) 비용 정규화 (낮을수록 좋음)
    cost_norm = normalize(carrier.cost * order.weight)
    return 0.35*edd_score + 0.30*inv_ok + 0.20*cap_score - 0.15*cost_norm

EDD 가중치를 가장 높게(0.35) 두어 약속한 도착일 충족이 1순위. 재고(0.30)·용량(0.20)이 보조이며, 비용은 음수 가중(-0.15)으로 들어가 score가 동률일 때 저비용 거점이 우선된다.

예) 서울 동남권 고객이 익일 도착 요청한 표준 주문(STD)에 대해 NODE-A (가산)는 EDD=1, Inv=1, Cap=0.7, Cost=0.5 → 0.35 + 0.30 + 0.14 − 0.075 = 0.715 로 NODE-B(이천 0.62), NODE-C(부산 0.41)를 제치고 선택된다.

# n8n 워크플로우 (RT-O1 ver.0.1, 2026-01-04)
Webhook(POST /orders/receive)
  -> Code(전처리: 주소정규화, SKU검증, 무게계산)
  -> AI_Agent(카테고리 분류: STD/EXPRESS/COLD)
  -> Switch(routingKey 기반 에이전트 분기)
  -> AI_Agent_R0(표준 DOM 거점 선택)
  -> HTTP_WMS(피킹 지시 전송)
  -> HTTP_TMS(배차 요청)
  -> Respond_Webhook(EDD 반환)
  -> Gmail(고객 배송 확인 메일 발송)

# 평균 노드 7개, end-to-end p95 ≈ 720ms (1월 4주차 기준)

n8n으로 1차 구현한 이유는 비-개발자 PM도 워크플로우를 시각적으로 수정할 수 있어 빠른 반복(쉬운 A/B)이 가능하기 때문. 다만 Switch 노드가 단일 routingKey만 받기 때문에 "냉장 + 당일"처럼 두 카테고리에 걸친 주문을 처리하지 못해 RT-O2에서 멀티 레이블 분기로 재설계할 예정이다.

NODE-A는 서울 수요 밀집 지역에 가까워 가장 자주 선택되며, NODE-B는 용량이 가장 커 다량 주문 분산 처리에 유리. NODE-D는 콜드체인 전용으로 COLD 카테고리에서 사실상 단독 후보로 작동한다. 부산 NODE-C는 영남권 고객에 한정적으로 선택돼 평균 score가 낮다.