Skip to main content

왜 태국·한국·말레이시아·중국인가 — REINDEERS의 글로벌 확장 전략

1. 동시 오픈의 배경

REINDEERS는 처음부터 하나의 국가에서 완성될 수 없는 구조였다. 무역은 복수의 국가가 동시에 참여해야 완전한 프로세스를 이룬다. 그래서 우리는 서비스 초기부터 네 개 국가의 리전을 병렬 설계했다.

태국은 시장이자 물류의 중심, 한국과 중국은 개발의 중심, 말레이시아는 운영과 금융의 허브였다. 네 리전이 동시에 작동해야만 "무역이 움직이는 플랫폼"이 가능했다.

동남아 산업재 B2B 시장은 약 1,300억 달러 규모로 추산된다. 이 시장에서 가장 큰 비효율은 국가 간 정보 비대칭이다. 태국의 바이어가 중국 공급사의 재고 상황을 실시간으로 파악할 수 없고, 말레이시아의 결제 프로세스가 한국의 회계 기준과 맞지 않는 상황이 반복된다. 이 문제를 해결하려면 단일 국가 서비스를 여러 나라에 복제하는 방식이 아니라, 처음부터 다국가 동시 운영을 전제로 설계해야 했다. 4,300개 이상의 파트너와 25,000건 이상의 거래 데이터가 이 구조적 판단의 근거였다.

무역 플랫폼은 단일 국가 서비스와 근본적으로 다르다. 견적 하나를 만들어도 출발지 통화, 도착지 통화, 운임 통화가 서로 다를 수 있다. 세관 규정은 국가마다 다르고, 인증 요건도 산업재 종류에 따라 갈린다. 태국의 TISI 인증과 FDA 규정, 한국의 KC 인증, 중국의 CCC 인증이 동시에 관리되어야 하는 것이다. 이런 복잡성을 하나의 데이터 모델 안에서 처리하려면 각 국가의 규제 체계를 추상화할 수 있는 유연한 스키마가 필요했다. 그것이 REINDEERS가 네 리전을 동시에 설계한 가장 본질적인 이유다.

2. 태국 -- 시장과 물류의 실시간 거점

태국은 REINDEERS의 실제 비즈니스 거래가 이루어지는 핵심 리전이다. 고객사의 견적 요청, 공급사의 견적 발행, DO 생성, 결제, 인보이스 발행 등 모든 상거래 이벤트가 태국 리전의 MCP에서 최초로 발생한다.

서비스 인프라는 Tencent Cloud Bangkok 리전에 구축되었으며, 정적 파일과 이미지 리사이징은 COS Function으로 처리된다. 프론트엔드는 홍콩 CDN에서 배포되어 인접 국가에서도 빠른 응답 속도를 유지한다.

태국이 시장 거점인 이유는 단순히 REINDEERS의 첫 진출 국가이기 때문만은 아니다. IMARKET Thailand 시절부터 11년간 축적된 MRO 유통 네트워크가 이 나라에 있다. 바이어 2,500개 이상, 벤더 1,800개 이상이 태국을 중심으로 활동한다. 태국의 제조업 클러스터는 방콕 동부 산업단지를 중심으로 밀집해 있으며, 이곳에서 발생하는 산업재 수요가 플랫폼의 초기 거래량을 만들어낸다.

물류 측면에서도 태국은 핵심이다. 라엠차방 항만은 동남아 주요 허브 포트 중 하나이며, 중국과 태국 사이의 해상 운송 노선이 안정적으로 운영된다. 포워딩 비딩 시스템에 등록된 30개 이상의 포워더 중 상당수가 이 노선을 기반으로 견적을 제출한다. 견적 요청이 발생하면 이벤트가 태국 리전 MQ에서 시작되고, 이후 물류 스케줄링, 통관 준비, 결제 요청 이벤트가 순차적으로 이어진다. 태국 법인은 현지 관세청과의 연동, TISI와 FDA 인증 데이터 관리, 현지 법규 준수까지 담당한다.

3. 한국 -- 기술의 중심이자 MCP의 제어 리전

한국은 REINDEERS의 핵심 기술 리전이다. MCP, MQ, DTS, Cloud Function 등 플랫폼의 모든 아키텍처 설계와 핵심 코어 개발이 이곳에서 이루어진다.

한국은 단순한 개발 리전이 아니라, 태국과 중국 리전을 동기화하는 메인 컨트롤 허브다. DTS를 통해 태국에서 발생한 트랜잭션은 한국 DB로 즉시 복제되고, 반대로 중국 개발 리전에서 테스트된 코드와 데이터도 동일 구조로 양방향 동기화된다.

{
  "source": ["th-db1", "cn-db1"],
  "target": "kr-db1",
  "sync_mode": "bi-directional",
  "replica_policy": "active-active"
}

이 구조 덕분에 어느 한쪽 리전의 장애가 발생해도 서비스는 중단되지 않는다. 한국은 AI 모델 학습, MQ 제어, 빌드 파이프라인 자동화까지 담당하며 REINDEERS의 기술 생태계의 중심으로 기능한다.

한국 리전이 기술 허브가 된 구체적인 이유가 있다. 첫째, Event + State + Log 데이터 모델의 설계와 유지보수가 한국 개발팀에서 이루어진다. 60개에서 250개로 확장된 테이블 구조의 정규화 작업이 모두 이곳에서 수행된다. 둘째, LavinMQ 기반의 메시징 시스템 운영과 모니터링이 한국 리전에 집중되어 있다. MQ 재시도 큐 관리, 실패 메시지 분석, 이벤트 시퀀스 보장 로직이 한국팀의 핵심 역할이다. 셋째, Redis 캐시 클러스터와 DTS 지연 임계치 관리가 한국에서 수행된다. 캐시 히트율 80% 이상을 유지하기 위한 무효화 전략과 환율 변동 시 관련 데이터 전파 로직이 모두 한국 리전 코드에 구현되어 있다. 넷째, 한국 법인은 기업부설연구소로 인증받아 지속적인 R&D 투자를 수행하고 있으며, 혁신 성장 벤처기업과 기술보호 우수기업 인증을 보유하고 있다.

4. 중국 -- 공급망이자 개발의 또 다른 축

중국은 단순히 공급망 데이터 리전이 아니다. REINDEERS의 보조 개발 리전이자 AI와 프론트엔드 개발 인력이 상시 협업하는 환경이다.

중국 리전에서는 Playwright 기반의 대규모 크롤링으로 제조사 및 SKU 데이터를 수집하고, 이를 MCP의 표준 데이터셋으로 정규화한다. 동시에, Vue3와 Nuxt 기반 프론트엔드 빌드 및 번역 테스트도 중국 개발자들이 직접 수행한다.

{
  "role": ["frontend_dev", "data_crawler", "ai_preprocessor"],
  "tools": ["Playwright", "Nuxt", "Claude Code Agent"],
  "sync": "via MQ + DTS"
}

한국 개발팀은 인프라와 아키텍처를, 중국 개발팀은 실제 코드와 데이터 최적화를 담당한다. 두 팀은 하나의 Git 리포지토리에서 브랜치를 공유하며, MQ 로그를 통해 자동 배포 상태를 확인한다.

중국이 공급망 관점에서 중요한 이유는 구체적인 숫자로 설명된다. 플랫폼에 등록된 공급사의 상당 부분이 중국 제조사이며, 이들이 제공하는 산업재 SKU 데이터는 수만 건에 달한다. 문제는 이 데이터의 품질이다. 중국 공급사가 등록하는 상품명, 규격, 카테고리 정보는 표준화되지 않은 경우가 대부분이다. 같은 알루미늄 프로파일이 서로 다른 이름으로 등록되는 일이 빈번하다. 이를 해결하기 위해 중국 리전에서는 크롤러가 제조사 카탈로그에서 SKU 데이터를 수집하고, Translation Agent가 다국어 정규화를 수행하며, AI 기반 카테고리 매핑 엔진이 수집된 데이터를 REINDEERS의 표준 카테고리 트리에 자동 분류한다. 이 과정에서 RAG 파이프라인이 기존 매핑 이력을 참조해 분류 정확도를 높인다.

5. 말레이시아 -- 금융과 정산과 운영의 허브

말레이시아는 Cross-Region Settlement의 핵심이다. ASEAN의 금융 중심지로서 PG 연동, 환율 관리, 국가별 세금 규정을 통합 관리한다.

결제 통화는 각국 화폐로 이루어지지만, 환율 기준은 말레이시아 중앙은행 데이터를 기준으로 실시간으로 반영된다. 이 데이터는 Redis Cache에 저장되어 MQ 이벤트 처리 시 즉시 활용된다.

{
  "fx_base": "MYR",
  "source_bank": "Bank Negara Malaysia",
  "update_cycle": "1h",
  "cache": "Redis Global FX Pool"
}

이렇게 통합된 정산 구조 덕분에 태국, 한국, 중국에서 발생한 모든 결제는 동일한 구조로 회계 처리된다.

말레이시아의 금융 허브 역할은 정산 구조의 복잡성에서 비롯된다. REINDEERS의 정산은 단순한 구매자와 판매자 사이의 2자 거래가 아니다. 구매자가 플랫폼에 결제하면, 플랫폼은 이를 벤더와 포워더에 분배한다. 이 다자간 정산 구조에서 각 참여자의 정산 주기가 다르다. 벤더는 납품 완료 후 7일, 포워더는 운송 완료 후 15일 등 설정 가능한 주기로 정산이 이루어진다. 이 모든 정산 로직이 말레이시아 법인의 회계 기준에 맞춰 자동 처리된다. 환율 관리도 단순하지 않다. 4개국 통화가 동시에 움직이며, 견적 시점의 환율과 결제 시점의 환율 차이가 발생한다. 환율 스크래퍼가 4개국 중앙은행과 시중은행에서 실시간 환율을 수집하고, 이를 캐싱하여 정산 시점에 정확한 환율을 적용한다.

6. 네 리전의 기술적 연결 구조

REINDEERS의 네 리전은 LavinMQ 기반의 메시징 시스템으로 연결된다. 예를 들어 태국 고객이 중국 공급사 상품을 주문하면 다음과 같은 이벤트 시퀀스로 자동 처리된다.

quote.confirmed → logistics.schedule → customs.prepare → payment.request → settlement.finalize

각 단계는 Cloud Function으로 분산 실행되며, MQ의 Retry Queue가 장애 발생 시 자동 복구를 담당한다. 네 리전의 서버는 완전히 분리되어 있지만, 시스템은 하나의 이벤트 네트워크로 작동한다.

이 이벤트 시퀀스가 실제로 어떻게 4개국을 관통하는지 구체적으로 살펴보면 이렇다. 태국 바이어가 견적을 확정하면 이벤트가 태국 리전 MQ에서 발행된다. 한국 리전의 MCP가 이 이벤트를 수신해 주문 데이터를 생성하고, 중국 리전의 공급사 시스템에 발주 알림을 전달한다. 물류 스케줄이 확정되면 등록된 포워더 30개 이상에게 비딩 요청이 전달된다. 포워더가 경로와 가격과 일정을 제출하면 바이어가 비교 후 선택한다. 통관 준비 이벤트는 태국 통관 요건에 맞춰 필요 서류를 자동 확인하고, 결제 요청은 말레이시아 정산 허브를 통해 다통화 결제를 처리한다. 이 전체 시퀀스에서 각 이벤트는 독립적인 Cloud Function으로 실행되며, 하나의 Function이 실패해도 재시도 큐가 자동으로 복구한다. 부분 장애가 전체 거래 흐름을 중단시키지 않는 것이 핵심이다.

7. 리전별 법인의 역할

  • REINDEERS Fulfillment (Thailand) -- 현지 거래, 물류, 관세, 포워딩 운영
  • REINDEERS Co., Ltd (Korea) -- MCP와 MQ와 AI Agent 개발, 기술 제어 허브
  • REINDEERS China Ltd. -- 프론트엔드와 데이터 크롤링과 AI 사전처리 개발 병행
  • REINDEERS Malaysia Sdn. Bhd. -- 결제 정산, 환율 및 회계 데이터 관리

한국과 중국은 공동 개발 리전으로 상호 백업 구조를 갖추고 있으며, 태국과 말레이시아는 서비스 운영과 회계 관리의 중심 리전으로 분리되어 있다.

이 법인 구조는 단순한 법적 분리가 아니다. 각 법인은 해당 국가의 규제 환경에 맞춘 독자적인 운영 체계를 갖추고 있다. 태국 법인은 태국 관세청 연동과 산업표준원 인증 데이터를 관리하며, 한국 법인은 기업부설연구소를 운영하면서 핵심 기술 개발에 집중한다. 말레이시아 법인은 ASEAN 역내 결제 규정 준수와 국가 간 정산 보고를 담당하고, 중국 법인은 중국 내 데이터 보안 규정을 준수하면서 크롤링과 개발 협업을 수행한다. 네 법인이 하나의 플랫폼을 위해 각자의 역할을 수행하되, 기술적으로는 MQ와 DTS로 완전히 연결되어 있어 법인 간 데이터 격차가 발생하지 않는다.

8. 결론 -- 기술의 국경을 없애다

REINDEERS의 글로벌 구조는 분산되어 있지만, 그 모든 데이터는 하나의 MCP 내에서 통합된다. 각 리전은 역할이 다르지만, 구조는 같다. 한국과 중국은 개발의 양축으로, 태국은 시장의 중심으로, 말레이시아는 운영의 중심으로 플랫폼을 완성한다.

우리는 기술로 국경을 넘은 것이 아니라, 데이터 구조로 국경을 없앴다. 그것이 REINDEERS의 진짜 글로벌 전략이다.

이 전략의 효과는 운영 지표로 드러난다. 네 리전이 동시에 작동하면서 견적 요청부터 정산 완료까지의 리드타임이 기존 오프라인 프로세스 대비 대폭 단축되었다. 과거에는 이메일과 전화로 수일이 걸리던 포워딩 견적 비교가, 플랫폼 위에서는 포워더들의 실시간 비딩으로 즉시 이루어진다. 환율 변동에 따른 정산 오류는 실시간 환율 반영으로 사라졌다. 그리고 어느 한 리전에서 장애가 발생해도 다른 리전에서 서비스가 계속 작동하는 고가용성이 확보되었다. 1,300억 달러 시장의 구조적 비효율을 기술로 해소한다는 것, 그것이 네 국가를 동시에 열어야 했던 가장 본질적인 이유이자, 지금까지 이 구조를 유지해온 원동력이다.

관련 글

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...