1. 무역은 코드보다 복잡했다
REINDEERS의 출발점은 단순했다. "제조업과 유통을 연결하자." 하지만 그 말 한 줄을 시스템으로 바꾸는 데 4년이 걸렸다.
무역은 전자상거래와 다르다. 주문에는 견적(Quote), 발주(PO), 납품서(DO), 상업송장(CI), 관세, 운송, 보험까지 포함된다. 각 단계가 독립적이지만 서로 연결되어야 한다. 한 문서가 늦으면 물류 전체가 멈춘다. 우리는 이 복잡한 절차를 단순한 버튼 하나로 연결해야 했다.
그 시작이 바로 MCP (Multi-Commerce Platform)였다.
2. 왜 무역 플랫폼은 전자상거래보다 어려운가
일반적인 전자상거래 플랫폼은 "상품 등록 - 결제 - 배송"이라는 비교적 단순한 흐름을 따른다. 통화는 하나이고, 규제는 한 국가의 법률만 따르면 되고, 물류는 국내 택배사에 위탁하면 된다. 하지만 국경을 넘는 B2B 무역은 완전히 다른 세계다.
첫째, 다중 통화(Multi-Currency) 문제가 있다. 태국 바트로 견적을 내고, 중국 위안으로 결제하고, 한국 원화로 정산하는 거래가 일상적이다. 견적 시점의 환율과 결제 시점의 환율이 다르면 마진이 증발하거나 손실이 발생한다. 환율은 하루에도 여러 번 변동하므로, 시스템은 견적 발행 시점의 환율을 고정하고, 결제 시점에 실시간 환율로 재계산하는 이중 구조를 가져야 한다.
둘째, 다중 언어(Multi-Language)의 벽이 있다. 단순히 UI를 번역하는 것이 아니다. 상품명, 규격서, 인증서, 통관 서류까지 모든 것이 거래 당사자의 언어로 작성되어야 한다. 태국 구매 담당자가 보는 품목명과 중국 공급사가 등록한 품목명이 서로 대응되어야 하고, 통관 서류에는 또 다른 공식 명칭이 필요하다.
셋째, 다중 규제(Multi-Regulation) 환경을 다뤄야 한다. 태국의 TISI 인증, 한국의 KC 인증, 중국의 CCC 인증 -- 같은 제품이라도 국가마다 요구하는 인증이 다르다. 관세율도 HS 코드에 따라 국가별로 다르고, FTA 적용 여부에 따라 또 달라진다. 이 모든 규제 정보가 주문 시점에 자동으로 확인되지 않으면, 통관 단계에서 화물이 묶이는 사태가 발생한다.
3. MCP -- 무역 절차를 시스템화한 첫 구조
MCP는 단순한 백엔드 시스템이 아니었다. PO, DO, CI, BL, Payment, Refund 등 각 무역 단계를 독립된 서비스로 나누고, 메시지 큐(LavinMQ)를 통해 연결한 분산 구조였다.
각 서비스는 이벤트 기반(Event-Driven Architecture)으로 작동했다. "견적 확정" 이벤트가 발생하면 자동으로 "운송 일정 생성"과 "결제 요청" 이벤트가 이어졌다. 관리자는 버튼을 누르지 않아도 업무가 진행되었다.
{
"event": "quote.confirmed",
"trigger": ["logistics.schedule", "payment.request"],
"source": "mcp-core"
}
이렇게 MCP는 사람이 업무를 처리하지 않아도 "무역 절차가 스스로 흘러가는 구조"를 만들었다.
이 아키텍처를 선택한 이유는 무역의 본질적인 특성 때문이었다. 무역의 각 단계는 서로 다른 담당자가, 서로 다른 시간대에서, 서로 다른 시스템을 사용해 처리한다. 구매 담당자는 방콕 사무실에서 견적을 확인하고, 물류 담당자는 광저우 창고에서 선적을 준비하고, 재무 담당자는 서울 본사에서 결제를 승인한다. 이들을 하나의 모놀리식 시스템에 묶어놓으면, 한 단계의 지연이 전체 시스템의 병목이 된다. 각 서비스를 독립시키고 MQ로 연결하면, 한 단계가 지연되더라도 다른 단계는 정상적으로 진행될 수 있다.
4. 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 덕분에 시스템은 언제든 중단되어도 재처리가 가능했다. "견적 발행"에서 멈췄다면, 그 시점의 이벤트만 다시 실행하면 된다. 사람의 개입 없이도 프로세스는 항상 완결된다.
5. 하나의 거래가 만드는 여정 -- 태국 구매자와 중국 공급사
MCP 아키텍처가 실제로 어떻게 작동하는지, 하나의 거래를 따라가 보면 명확해진다.
방콕 외곽의 자동차 부품 공장에서 구매 담당자가 REINDEERS 플랫폼에 접속한다. 필요한 것은 CNC 선반용 절삭공구 200개. 플랫폼은 이 요청을 받아 중국 광저우에 있는 3개 공급사의 재고와 단가를 실시간으로 조회한다. 구매 담당자가 태국어로 입력한 품목명은 시스템 내부에서 표준 SKU 코드로 변환되고, 중국 공급사에게는 중국어 품목명으로 표시된다.
구매 담당자가 공급사를 선택하고 견적을 요청하면, "quote.create" 이벤트가 발생한다. 이 이벤트는 동시에 세 가지를 트리거한다. 첫째, 해당 시점의 THB/CNY 환율이 견적서에 고정된다. 둘째, 물류 서비스가 광저우에서 방콕까지의 해상 운송 일정과 비용을 자동으로 계산한다. 셋째, 인증 자동화 서비스가 해당 품목의 태국 수입에 필요한 TISI 인증 여부를 확인한다.
견적이 확정되면 결제 요청, 선적 예약, 통관 서류 준비가 MQ를 통해 자동으로 진행된다. 광저우 창고에서 화물이 출발하면 "logistics.departed" 이벤트가 발생하고, 태국 세관에 도착하면 "customs.arrived" 이벤트가 이어진다. 각 단계에서 담당자는 앱에서 상태를 확인하고, 필요한 경우에만 개입한다. 하나의 주문이 완결되기까지 보통 7~14일이 걸리지만, 사람이 직접 처리해야 하는 단계는 최소한으로 줄어든다.
6. 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가 재시도한다. 무역 절차는 이제 코드 한 줄의 이벤트로 제어된다.
7. AI가 메우는 간극 -- 언어와 규제의 자동 번역
다국가 무역에서 AI의 역할은 단순한 텍스트 번역을 넘어선다. REINDEERS에서 AI는 세 가지 핵심 영역에서 "간극을 메우는" 역할을 한다.
품목명 매칭
태국 구매자가 입력한 태국어 품목명, 중국 공급사가 등록한 중국어 품목명, 그리고 통관에 필요한 영문 HS 코드 명칭 -- 이 세 가지가 같은 제품을 가리키고 있는지를 AI가 판단한다. 11년간 축적된 SKU 데이터가 이 매칭의 정확도를 높이는 핵심 학습 자료다.
규제 자동 확인
특정 품목이 태국으로 수입될 때 TISI 인증이 필요한지, FDA 등록이 필요한지를 AI가 HS 코드와 품목 속성을 기반으로 자동 판별한다. 이전에는 통관 전문가가 수작업으로 확인하던 것을, 데이터베이스화된 규제 정보와 AI 추론을 결합해 자동화했다.
이상 거래 감지
과거 거래 패턴과 크게 벗어나는 주문이 들어오면 AI가 플래그를 달아 담당자에게 알린다. 예를 들어, 평소 월 50개를 주문하던 공장이 갑자기 5,000개를 주문하거나, 기존에 거래한 적 없는 품목이 대량 주문되는 경우다. 이것은 단순한 규칙 기반 필터가 아니라, 거래 이력 전체를 학습한 모델이 판단하는 것이다.
8. 왜 점진적 개선이 아닌 전면 재설계였는가
기존 Buybly 시스템을 부분적으로 개선하는 방법도 있었다. 하지만 우리는 전면 재설계를 선택했다. 이유는 단순했다. 기존 시스템의 근본 가정이 틀렸기 때문이다.
Buybly의 아키텍처는 "하나의 국가, 하나의 통화, 하나의 언어"를 전제로 설계되었다. 여기에 다중 통화를 추가하고, 다중 언어를 추가하고, 다중 규제를 추가하는 것은 기존 건물의 1층에 지하 3층을 파는 것과 같았다. 구조적으로 불가능했다. 데이터 모델부터 다시 설계해야 했고, 그것은 곧 전면 재설계를 의미했다.
재설계에는 6개월이 걸렸다. 그 기간 동안 기존 시스템은 계속 운영되었고, 새 시스템은 실제 거래 데이터를 기반으로 병렬 테스트를 진행했다. 2025년 12월 1일 플랫폼이 정식 오픈했을 때, 5개 플랫폼이 하나의 MCP 아키텍처 위에서 동시에 작동하기 시작했다.
9. 결론 -- 제조업의 디지털 언어를 만들다
무역은 언어의 문제였다. 수출입 문서, 운송 일정, 가격 조건, 결제 방식은 나라마다 달랐다. 우리는 그것을 코드로 통합했고, MCP는 그 언어를 표준화한 구조가 되었다.
REINDEERS의 목표는 단순히 "상품을 사고파는 플랫폼"이 아니다. 그것은 제조업의 절차, 언어, 문화를 디지털 언어로 바꾸는 프로젝트다. 그 변화의 시작이 바로 IT와 무역이 만난 순간이었다.
IT가 무역을 만났을 때 가장 어려웠던 것은 기술적 난이도가 아니었다. 가장 어려웠던 것은 "무역을 이해하는 개발자"와 "기술을 이해하는 무역 전문가"를 같은 팀에 모으는 일이었다. REINDEERS가 네 번의 팀 교체를 거치면서 결국 도달한 답은, 양쪽을 모두 이해하는 사람들이 하나의 목표를 공유할 때 비로소 플랫폼이 만들어진다는 것이었다. MCP는 그 팀이 만든 첫 번째 결과물이고, 4,300개 이상의 파트너사와 25,000건 이상의 거래는 그 결과물이 현실에서 작동한다는 증거다.