IT와 무역이 만나다: 제조업의 새로운 길을 설계하다

요약:
REINDEERS는 단순한 플랫폼이 아니다. 우리는 “무역”이라는 복잡한 산업 언어를 소프트웨어 언어로 바꾸는 실험을 했다. 그리고 그 과정에서 IT와 무역은 충돌했지만, 결국 하나의 구조로 융합되었다. 이번 글은 REINDEERS가 무역 프로세스를 기술로 재정의한 과정을 기록한다.

1. 무역은 코드보다 복잡했다

REINDEERS의 출발점은 단순했다. “제조업과 유통을 연결하자.” 하지만 그 말 한 줄을 시스템으로 바꾸는 데 4년이 걸렸다.

무역은 전자상거래와 다르다. 주문에는 견적(Quote), 발주(PO), 납품서(DO), 상업송장(CI), 관세, 운송, 보험까지 포함된다. 각 단계가 독립적이지만 서로 연결되어야 한다. 한 문서가 늦으면 물류 전체가 멈춘다. 우리는 이 복잡한 절차를 단순한 버튼 하나로 연결해야 했다.

그 시작이 바로 **MCP (Multi-Commerce Platform)** 였다.

2. MCP — 무역 절차를 시스템화한 첫 구조

MCP는 단순한 백엔드 시스템이 아니었다. PO, DO, CI, BL, Payment, Refund 등 각 무역 단계를 독립된 서비스로 나누고, 메시지 큐(LavinMQ)를 통해 연결한 분산 구조였다.

각 서비스는 **이벤트 기반(Event-Driven Architecture)** 으로 작동했다. “견적 확정” 이벤트가 발생하면 자동으로 “운송 일정 생성”과 “결제 요청” 이벤트가 이어졌다. 관리자는 버튼을 누르지 않아도 업무가 진행되었다.

{
  "event": "quote.confirmed",
  "trigger": ["logistics.schedule", "payment.request"],
  "source": "mcp-core"
}

이렇게 MCP는 사람이 업무를 처리하지 않아도 “무역 절차가 스스로 흘러가는 구조”를 만들었다.

3. MQ — 절차를 연결하는 신경망

무역은 수많은 단계가 순차적으로 연결된 프로세스다. 하지만 사람은 그 모든 타이밍을 관리할 수 없다. 그래서 REINDEERS는 메시지 큐(MQ)를 사용했다.

LavinMQ는 REINDEERS의 모든 이벤트를 제어하는 ‘신경망’이다. 견적이 확정되면 “quote.queue”로, 결제가 완료되면 “payment.queue”로, DO가 발행되면 “logistics.queue”로 자동 라우팅된다.

# MQ Topic Structure
order.lifecycle.quote.exchange → quote.create, quote.issue, quote.confirm
order.lifecycle.logistics.exchange → logistics.schedule, logistics.update
order.lifecycle.payment.exchange → payment.request, payment.confirmed

MQ 덕분에 시스템은 언제든 중단되어도 재처리가 가능했다. “견적 발행”에서 멈췄다면, 그 시점의 이벤트만 다시 실행하면 된다. 사람의 개입 없이도 프로세스는 항상 완결된다.

4. Cloud Function — 무역의 자동화를 완성하다

MQ가 데이터를 흘려보낸다면, Cloud Function은 그 데이터를 처리한다. 각 Function은 하나의 역할만 수행하도록 설계되었다. 예를 들어 “견적 확정”은 결제 생성, 운송 일정 확정, PO 발행 세 가지 Function을 동시에 호출한다.

exports.handleQuoteConfirm = async (event) => {
  await trigger("payment.request", event.orderId);
  await trigger("logistics.schedule", event.orderId);
  await trigger("po.issue", event.orderId);
};

Function은 서버가 필요 없다. 확장도 자동이며, 장애가 나면 MQ가 재시도한다. 무역 절차는 이제 코드 한 줄의 이벤트로 제어된다.

5. IT가 무역을 재정의하다

REINDEERS가 만든 MCP 구조는 단순한 IT 프로젝트가 아니다. 무역의 모든 단계가 독립된 마이크로서비스로 분리되어 API와 이벤트로만 소통하는 구조다.

예를 들어 태국 고객이 한국 공급사에게 주문을 넣으면, “견적 → 결제 → 포워딩 → 관세 → 배송 → 수령”의 여정이 하나의 분산 트랜잭션으로 처리된다. 각 단계는 AI 모듈이 모니터링하고, 누락 시 자동 재발행된다.

REINDEERS는 “무역을 자동화”한 것이 아니라, “무역 그 자체를 소프트웨어로 설계”했다.

6. 결론 — 제조업의 디지털 언어를 만들다

무역은 언어의 문제였다. 수출입 문서, 운송 일정, 가격 조건, 결제 방식은 나라마다 달랐다. 우리는 그것을 코드로 통합했고, MCP는 그 언어를 표준화한 첫 번째 구조가 되었다.

REINDEERS의 목표는 단순히 “상품을 사고파는 플랫폼”이 아니다. 그것은 제조업의 절차, 언어, 문화를 디지털 언어로 바꾸는 프로젝트다. 그 변화의 시작이 바로 IT와 무역이 만난 순간이었다.

Blog of Reindeers

Search This Blog