주문 로직의 8번째 재개발: 내부 아키텍처의 표준화와 로직 충돌 해소

1. 배경 - 이미 존재하던 주문 구조

REINDEERS의 주문 구조는 처음부터 복합적이었다. 견적형 주문과 바로구매형 주문이 병존하며, 포워딩과 운송 일정을 포함하는 다단계 프로세스가 이미 내부 MCP 환경에서 운용되고 있었다. 다만, 이 로직은 외부로 공개되지 않았고, 실제 서비스보다는 내부 자동화-테스트 환경에 최적화되어 있었다.

8번째 리빌드는 새로운 시스템을 만든 것이 아니라, 내부적으로 작동하던 고도화된 주문 엔진을 외부 고객사가 사용하는 서비스 레벨로 정식 통합하고 검증하기 위한 작업이었다. 2015년 IMARKET Thailand 설립 이후 수년간 운영해온 주문 로직이 7번의 리빌드를 거치며 내부적으로 성숙해 있었지만, 4,300개 이상의 파트너가 직접 사용하는 서비스 레벨에서는 다른 수준의 안정성이 요구되었다.

2. 문제 인식 - 로직 충돌과 중복 이벤트

내부 MCP 버전의 주문 시스템은 기능적으로 완성되어 있었지만, 확장성 측면에서는 한계를 드러냈다. 여러 Cloud Function과 MQ Exchange가 동시에 동일 이벤트를 수신하면서, 이벤트 중복 처리, 상태 불일치, TTL 만료 전 복구 불가 등의 문제가 반복되었다.

# 과거 문제 사례 (중복 처리)
[EVENT] payment.confirmed received (Q1)
[EVENT] payment.confirmed received (Q4)
→ PO double-issued (2개의 purchase order 생성)
→ Redis TTL mismatch → DO 전환 실패

특히 포워딩 스케줄 확정 로직과 결제 처리 로직이 동시에 MQ를 발행하면서 순서가 어긋나는 경우가 발생했다. 그 결과, PO가 생성되기 전에 DO가 먼저 발행되거나, 운송 일정이 존재하지 않는 상태에서 통관 요청이 들어오는 등 논리적 오류가 다수 발견되었다.

이 문제는 내부 운영 환경에서는 수동 개입으로 해결할 수 있었다. 하지만 바이어 2,500곳, 공급사 1,800곳, 포워딩 업체 30곳이 동시에 사용하는 서비스에서는 수동 개입이 불가능하다. 모든 예외 상황이 시스템 레벨에서 자동으로 감지되고 복구되어야 했다.

3. 로직 충돌 해소를 위한 구조 개선

문제의 핵심은 이벤트 순서와 중복 발행이었다. 이를 해결하기 위해 MQ와 Redis 간 트랜잭션 구조를 재설계했다.

각 주문 단계별로 idempotency key를 추가하여 중복 실행 방지
Cloud Function 간 실행 순서를 state dependency 방식으로 통제
TTL 만료 이전에 이벤트가 누락되면 AI Ops-Agent가 자동으로 재발행

{
  "order_id": "O34029",
  "event": "payment.confirmed",
  "idempotency_key": "abf2139e8c",
  "dependency": "quote.confirmed"
}

idempotency key의 도입은 단순해 보이지만 실제 구현에서는 고려할 점이 많았다. 키 생성 시점, 키의 유효 기간, 키 충돌 시 처리 방식을 모두 정의해야 했다. REINDEERS는 주문 ID와 이벤트 타입, 타임스탬프를 조합하여 키를 생성하고, Redis에 TTL과 함께 저장하여 동일 키의 이벤트가 중복 처리되지 않도록 했다.

state dependency 방식은 각 Cloud Function이 실행 전에 선행 이벤트의 완료 여부를 Redis에서 확인하는 구조다. payment.confirmed 이벤트를 처리하려면 quote.confirmed 이벤트가 이미 처리 완료 상태여야 한다. 선행 이벤트가 미완료 상태면 현재 이벤트는 큐에 남겨두고, 일정 시간 후 재시도한다.

이렇게 함으로써 MQ 이벤트의 순서 불일치 문제가 제거되었고, Cloud Function의 재처리율은 11%에서 0.4%로 감소했다.

4. 견적형과 바로구매형의 로직 통합

내부 구조에는 이미 두 가지 주문 타입이 존재했다. 다만 두 타입이 같은 큐와 Function을 공유하면서 충돌이 발생하던 부분을 분리했다.

견적형 주문: AI Forwarding-Agent 개입. 운송 일정 자동 확정. 포워딩 업체 입찰 프로세스 포함.
바로구매형 주문: 견적 단계를 패스하고, 고객-공급사 간 직접 거래. 사전 합의된 운송 조건 적용.

# 개선 후 MQ Routing
order.lifecycle.quote.exchange   → quote.request, logistics.confirm, payment.confirmed
order.lifecycle.instant.exchange → instant.purchase, po.issued, do.issued, delivery.handover

두 로직의 큐가 완전히 분리되면서, 서로의 상태가 간섭하는 일이 사라졌다. MQ 처리 순서 충돌도 함께 해소되었다.

견적형 주문의 경우, MQ 라우팅에 logistics.confirm 단계가 추가된 것이 핵심이다. 이 단계에서 AI Forwarding-Agent가 포워딩 업체의 견적을 검증하고, 선사 스케줄 데이터와 대조하여 일정 정합성을 확인한 뒤에야 다음 단계로 진행된다. 바로구매형은 이 검증 단계를 건너뛰되, 사전에 합의된 운송 조건을 자동으로 적용한다. NCP Cloud Functions에서 각 큐별로 별도의 함수가 실행되며, 함수 간 상태 공유는 Turso(LibSQL) 데이터베이스를 통해 이루어진다.

5. AI Forwarding-Agent 재정비

AI Forwarding-Agent는 이미 내부 MCP에서 운송 일정을 자동 배정하던 모듈이었다. 하지만 내부용 구조는 포워딩 데이터의 일관성을 보장하지 못했다. 이번 리빌드에서는 AI가 포워더 API 응답을 검증한 뒤 "확정" 상태를 명시적으로 MQ로 발행하도록 변경했다.

if forwarder.schedule.verified:
    publish("logistics.confirmed", {"order_id": order.id, "eta": eta, "port_from": port_from, "port_to": port_to})

이로써 과거에는 포워딩 결과가 DB에만 남고 MQ로 전달되지 않던 문제가 해결되었다. 이제 모든 운송 스케줄이 이벤트 체계 안에서 완결된다. AI Forwarding-Agent의 검증 로직은 구체적으로 다음을 수행한다. 선사 스케줄 크롤러가 수집한 HMM, KMTC, SM Line의 실제 운항 데이터와 포워딩 업체가 제출한 ETA를 비교하여 오차 범위를 검증한다. 허용 오차를 초과하는 경우, 해당 견적에 경고 플래그를 부여하고 구매자 화면에 "제안된 ETA와 선사 공식 스케줄 간 차이가 있음"을 표시한다.

6. DO(Delivery Order) 처리 및 스케줄 확정

DO 발행 시점 역시 변경되었다. 과거에는 결제 직후 DO가 자동 생성되었지만, 이번 구조에서는 AI Forwarding-Agent가 일정 확정 후 DO를 발행하도록 바뀌었다. 이렇게 함으로써 운송 일정이 없는 DO가 생성되는 오류가 완전히 사라졌다.

{
  "order_id": "O42110",
  "event": "do.issued",
  "forwarder": "Reindeers Logistics",
  "pickup": "2025-10-08T07:30Z",
  "eta": "2025-10-15T13:00Z"
}

이후 DO는 포트 도착, 통관, 배송 인계 이벤트로 순차 처리되며, 모든 상태는 Redis에 TTL 3600초로 캐시된다. DO 발행 이후의 상태 전이는 다음과 같은 순서를 따른다. DO_ISSUED → PICKED_UP → IN_TRANSIT → PORT_ARRIVED → CUSTOMS_CLEARING → CUSTOMS_CLEARED → DELIVERED. 각 전이 시점에 Telegram 알림이 관련 당사자에게 발송되며, 예외적으로 CUSTOMS_CLEARING 단계에서 지연이 발생하면 운영팀과 구매자 모두에게 별도 알림이 전송된다.

7. 결과 - 충돌 없는 완전한 순차 처리

총 30,000건의 주문 이벤트를 대상으로 한 시뮬레이션 결과, 상태 불일치, 중복 이벤트, 순서 충돌은 0건으로 기록되었다. MQ 처리량은 초당 3,200건, 전체 주문 처리 시간은 평균 290ms였다.

*Order Flow Report*
Total: 30,000
Avg Process Time: 290ms
Retry Rate: 0.4%
Logic Conflict: 0
Duplicate Event: 0

이 결과는 NCP Cloud Functions 환경에서 측정된 것이다. 각 Cloud Function은 256MB 메모리, 60초 타임아웃으로 설정되어 있으며, LavinMQ를 메시지 큐로, Redis를 상태 캐시로 사용한다. 290ms라는 평균 처리 시간은 이벤트 수신부터 DB 기록, 후속 이벤트 발행까지를 포함한 수치다. 재처리율 0.4%는 네트워크 타임아웃 등 인프라 레벨의 일시적 오류에 의한 것이며, 로직 레벨의 충돌은 0건이다.

이제 주문 로직은 견적형과 바로구매형 모두 동일한 트랜잭션 규칙을 따르며, Cloud Function, MQ, Redis 간의 상태 전이가 완벽히 동기화된다. 25,000건 이상의 실거래 데이터가 이 구조 위에서 처리되고 있다.

8. 기존 구조의 정제, 완성된 일관성

이번 8번째 리빌드는 새로운 구조를 만든 것이 아니라, 이미 존재하던 내부 주문 로직의 불일치-중복-충돌을 제거하고 일관성을 확보한 과정이었다. AI Forwarding-Agent, LavinMQ, Redis, Cloud Function은 이미 수년간 내부적으로 검증된 기술이었지만, 이번 작업을 통해 외부 서비스 수준에서도 동일한 안정성을 보장할 수 있게 되었다.

REINDEERS의 주문 엔진은 이제 단순히 "작동하는 구조"를 넘어, 논리적으로 완결된 상태 머신으로 진화했다. 모든 이벤트는 순차적이며, 어떤 시점에서도 복원 가능하다. Turso(LibSQL)에 기록된 이벤트 로그를 통해 특정 주문의 전체 생애주기를 추적할 수 있고, 문제가 발생한 시점의 정확한 상태를 재현할 수 있다.

8번째 리빌드는 공개되지 않았던 기술을 외부 서비스 수준으로 정제한 단계였다. 이 구조 위에서 2025년 12월 REINDEERS가 공식 오픈되었고, 2026년 3월 DVRP 베타, 4~5월 POP 베타로 이어지는 확장의 기반이 되었다. 4개국(한국, 태국, 말레이시아, 중국)에 걸친 크로스보더 거래가 이 상태 머신 위에서 처리되고 있다.

Blog

Search This Blog