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

요약:
본 기록은 REINDEERS 플랫폼의 주문 시스템이 8번째 리빌드를 거쳐 기존 내부용 주문·운송 아키텍처를 공식 서비스 환경으로 이식하는 과정에서, 세부 로직 충돌과 중복 처리를 해소하고 구조를 정제한 기술적 내용을 다룬다. 이번 재개발은 새로운 기능 추가가 아닌, 이미 존재하던 구조를 외부 서비스 수준으로 재정렬하고 안정화한 프로젝트였다.

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

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

8번째 리빌드는 새로운 시스템을 만든 것이 아니라, 내부적으로 작동하던 고도화된 주문 엔진을 외부 고객사가 사용하는 서비스 레벨로 정식 통합하고 검증하기 위한 작업이었다.

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가 먼저 발행되거나, 운송 일정이 존재하지 않는 상태에서 통관 요청이 들어오는 등 논리적 오류가 다수 발견되었다.

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"
}

이렇게 함으로써 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 처리 순서 충돌도 함께 해소되었다.

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로 전달되지 않던 문제가 해결되었다. 이제 모든 운송 스케줄이 이벤트 체계 안에서 완결된다.

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초로 캐시된다.

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

이제 주문 로직은 견적형과 바로구매형 모두 동일한 트랜잭션 규칙을 따르며, Cloud Function, MQ, Redis 간의 상태 전이가 완벽히 동기화된다.

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

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

REINDEERS의 주문 엔진은 이제 단순히 “작동하는 구조”를 넘어, 논리적으로 완결된 상태 머신으로 진화했다. 모든 이벤트는 순차적이며, 어떤 시점에서도 복원 가능하다. 8번째 리빌드는 공개되지 않았던 기술을 외부 서비스 수준으로 정제한 단계였다.

Blog of Reindeers

Search This Blog