Skip to main content

REINDEERS DVRP AI CORE ENGINE 소개

REINDEERS는 2026년 3월을 목표로 DVRP(Dynamic Vehicle Routing Platform) 베타 서비스를 공식 오픈한다. 이 플랫폼은 단순한 운송 배차 시스템이 아니라, AI가 실시간으로 판단·결정·지시·최적화하는 차세대 물류 OS로 설계되었다.

이번 글은 기술팀의 시각에서, DVRP가 어떤 구조로 설계되었고 AI가 어떻게 업무를 실제로 "대신 수행"하도록 만든 기술적 기반을 설명한다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 10년간 동남아 B2B 산업 물류를 운영하면서 축적한 현장 데이터와 운영 노하우를 DVRP의 설계 근거로 사용했다. 핵심 알고리즘·AI 아키텍처·동기화 구조·RAG 전략을 상세히 공개한다.


1. 서비스 개요 — AI 기반 물류 엔진의 출현

REINDEERS DVRP는 다음의 핵심 기능들을 통합한 하나의 AI 플랫폼이다.

  • 트럭·기사·창고 간 배차 자동화
  • Direct DO(직배송)의 다구간 경로 계산
  • 입고 ASN·출고 ASN·DO 생성 전체 자동화
  • GPS 기반 실시간 위치 추적 및 ETA 예측
  • FIFO·CBM·거리·로트 기반 재고 할당 엔진
  • LLM 기반 AI 오케스트레이션(업무 지시 자동화)
  • RAG 기반 현실 데이터 참조형 AI 의사결정
  • 대규모 트럭 운영(1000대 규모)을 위한 MQ · 비동기 구조

이 모든 기능은 REINDEERS CORE ENGINE이라는 단일 구조에서 작동한다. Web, Mobile Web, Native App이 동일 엔진을 공유하도록 만들어져 있으며 AI가 어느 디바이스에서든 같은 판단을 내릴 수 있는 구조이다. 4,300개 이상의 파트너사(바이어 2,500+, 공급사 1,800+, 포워더 30+)가 이 단일 엔진 위에서 각자의 역할에 맞는 인터페이스를 사용한다.


2. 프론트 구조 — Web · Mobile Web · Native App 통합

2-1. Web

대량의 데이터 조회, 트럭/기사 모니터링, 창고 운영, DO 처리 등을 담당한다. 업무 플로우를 AI가 자동으로 생성하기 때문에 Web은 단순히 입력·확인 UI 역할을 한다. 관리자와 운영팀이 주로 사용하며, 대시보드에서 전체 물류 현황을 실시간으로 확인할 수 있다. 트럭 위치, 창고별 입출고 현황, 미처리 DO 목록, SLA 위반 경고 등이 한 화면에 집약된다.

2-2. Mobile Web

운전기사와 창고 담당자를 위한 현장 중심 UI이다. 입출고 스캔, 사진 제출, GPS 이벤트 전송, 증빙자료 제출 등이 초경량 UI로 구성되어 있다. 모바일 데이터 불안정 문제를 해결하기 위해 LocalStorage 임시 저장이 자동 적용된다. 동남아 지역의 물류 현장은 네트워크 환경이 불안정한 경우가 많다. 고속도로 구간이나 창고 내부에서 LTE 연결이 끊기는 상황이 빈번하기 때문에, 오프라인 상태에서도 작업 데이터를 로컬에 저장하고 네트워크 복구 시 자동으로 동기화하는 구조가 필수적이다.

2-3. Native App

GPS·카메라·가속도계 등의 모바일 센서 정보를 실시간 수집하고, 트럭 위치 기반 ETA 계산 및 경로 변경 감지를 Core Engine으로 전송한다. GPS 데이터는 1분 단위로 수집되며, 배터리 소모를 최소화하기 위해 트럭이 정차 중일 때는 수집 간격을 5분으로 늘린다. 가속도계 데이터는 급정거·급가속 감지에 사용되어 운전 품질 점수 산출에 반영된다.


3. DVRP Core Engine의 업무 구조

DVRP의 모든 프로세스는 다음 3가지 객체로 돌아간다.

  • 입고 ASN -- 고객사에서 창고로 들어오는 흐름
  • 출고 ASN -- 창고에서 고객사·시장으로 나가는 흐름
  • DO(Delivery Order) -- 픽업, 출고, 직배송 작업의 실제 지시서

각 단계는 AI 엔진이 다음 행동을 결정한다. 사람이 ASN을 등록하면 AI가 자동으로 재고를 확인하고, 최적의 창고를 선택하고, DO를 생성하고, 트럭과 기사를 배정한다. 이 일련의 과정에서 사람이 개입하는 지점은 최초 입력과 최종 승인뿐이다.

{
 "action": "create DO",
 "asn id": "A-392",
 "preferred time": "2026-02-18 10:00",
 "warehouse id": "WH 03",
 "rules": ["FIFO", "capacity optimized"]
}

4. 입고 ASN · 출고 ASN · DO의 기술적 구조

4-1. 입고 ASN

다음 정보가 AI 엔진으로 전달된다.

  • 고객사 정보
  • 상품 SKU
  • 수량
  • 희망 픽업 날짜
  • 주소 및 좌표

AI는 과거 입고 패턴을 분석해 예상 차입시간, 필요 트럭 크기, 예상 CBM, 예상 보관 위치까지 계산한다. 예를 들어 특정 고객사가 매월 초 대량 입고를 하는 패턴이 있으면, 해당 시점에 맞춰 창고 공간을 사전 확보하고 입고 담당 인력을 미리 배치한다. 25,000건 이상의 과거 거래 데이터가 이 예측의 기반이 된다.

4-2. 출고 ASN

출고 과정은 더 복잡하다.

  • FIFO 적용
  • 거리 기반 창고 선택
  • CBM 기준 트럭 분할
  • 로트 일관성 유지

결과적으로 출고 ASN → 출고 최적화 → DO 생성이 자동 흐름으로 이어진다. 출고 최적화에서 가장 까다로운 부분은 다중 창고 재고 분할이다. 동일 SKU가 3개 창고에 분산 보관되어 있을 때, FIFO를 지키면서 동시에 배송 거리를 최소화하는 조합을 찾아야 한다. 이 조합 최적화 문제는 트럭 적재량(CBM/중량)과 고객 수령 시간대(time window)까지 고려하면 경우의 수가 급격히 증가한다.

4-3. DO 생성

DO는 세 가지 형태로 생성된다.

  • 입고 DO -- 픽업 → 창고
  • 출고 DO -- 창고 → 배송지
  • 직배송 Direct DO -- 픽업 → 목적지(다구간 가능)

직배송 Direct DO는 AI가 다음 조건을 모두 만족하는 경로를 자동 생성한다.

  • 가장 짧은 시간 경로
  • 총 비용 최소화
  • 트럭 가용성 고려
  • 기사 근무시간 준수
  • CBM 제한 준수
  • 특수 화물 필요 여부 검증

5. 재고 할당 엔진 — FIFO · 거리 · CBM · 로트 기반 복합 계산

도착지까지의 전체 물류 비용을 최소화하기 위해 다단계 재고 할당 모델을 구축했다.

5-1. FIFO

유통기한이 임박한 순서대로 우선 배치. 산업 자재의 경우 유통기한이 없는 품목도 있는데, 이때는 입고일 기준 선입선출을 적용한다.

5-2. 거리

고정 거리값이 아니라 교통 패턴 기반 실시간 거리를 사용한다. 방콕의 경우 출퇴근 시간대에 동일 구간의 주행 시간이 2~3배 차이가 나기 때문에, 시간대별 교통 패턴 데이터를 반영한 동적 거리 계산이 필수적이다.

5-3. CBM

트럭의 용량 초과를 자동 방지하며, CBM 최적 조합을 구성한다. 적재율이 70% 미만인 트럭이 발생하면 인접 DO와의 합적 가능성을 자동으로 탐색한다.

5-4. 로트 기반 규칙

특정 고객사 계약에 따라 로트 단위가 FIFO보다 우선 적용된다. 예를 들어 제약·화학 분야의 고객사는 동일 로트 내에서만 출고를 허용하는 조건을 계약에 명시하는 경우가 있다.


6. AI Orchestrator — LLM이 직접 업무를 지시하는 구조

REINDEERS의 특징은 "AI가 조언만 하는 것이 아니라 실제 업무를 만든다"는 점이다. 이를 가능하게 하는 구조가 바로 AI Orchestrator이다.

6-1. JSON Action Schema

모든 업무는 아래와 같은 통일된 구조로 생성된다.

{
 "action": "assign truck",
 "do id": 111,
 "truck id": "TH 042",
 "driver id": "DR 299",
 "constraints": {
   "must arrive before": "2026-02-19 16:00"
 }
}

이 명령은 MQ를 통해 비동기로 실행되며, LLM → Orchestrator → Core Engine → MQ → 실행 순서로 처리된다. AI가 생성한 Action은 반드시 Schema Validation과 상태머신 검증을 통과해야 실행된다. 이 2단계 검증이 AI의 잘못된 판단이 실제 운영에 영향을 미치는 것을 방지한다.

6-2. LLM 활용 방식

LLM은 다음 단계에서 사용된다.

  • 업무 플로우 자동 생성
  • DO 상태에 따른 작업 추천
  • GPS 지연 감지 및 조치
  • 트럭 경로 선택
  • 문서 자동 작성
  • 포워딩 스케줄 분석

7. RAG — 현실 데이터 기반의 안전한 AI

AI가 잘못된 판단을 하지 않도록 RAG(Retrieval Augmented Generation)를 적극 채택했다.

7-1. Embedding 데이터

  • 트럭 스펙(차종, CBM, 적재중량, 냉장/위험물 여부)
  • 국가별 도로 패턴(방콕 시내 vs 외곽, 말레이시아 고속도로 등)
  • 창고 구조(Zone/Rack/Bin 배치, 입출고 게이트 위치)
  • 재고 로트(유통기한, 입고일, 보관 조건)
  • 과거 운행 시간(동일 구간의 시간대별 소요 시간)
  • 기사별 근무 패턴(선호 경로, 평균 운행 시간, 피로도 이력)

7-2. 알고리즘

메타데이터 기반 필터링 → Cosine Similarity 기반 최근접 검색 → LLM 판단. 필터링 단계에서 국가·회사·창고 등의 메타데이터로 후보군을 먼저 좁히고, 그 안에서 벡터 유사도 검색을 수행한다. 이 2단계 구조로 검색 정확도와 속도를 동시에 확보한다.

7-3. 장점

  • 실제 현장 로직에 맞는 판단 제공
  • Hallucination 방지 -- AI가 존재하지 않는 트럭이나 창고를 참조하는 것을 원천 차단
  • 국가·고객사 규칙 차이 자동 반영 -- 4개국 법인별로 다른 물류 규정이 자동으로 적용

8. GPS 기반 실시간 업데이트

Native App에서 1분 단위 GPS를 수집하여 Core Engine으로 전달한다. AI는 이 데이터를 기반으로 DO의 ETA를 지속적으로 다시 계산한다. ETA 재계산은 단순 거리/속도 비례가 아니라, 해당 시간대의 해당 구간 교통 패턴 데이터를 반영한다.

  • 지연 발생 시 자동 DO 재배차 제안 -- 15분 이상 지연 시 대체 트럭 후보를 자동으로 산출
  • 우회 경로 자동 탐지 -- 기사가 지정 경로를 이탈한 경우 알림 발생
  • 트럭 만차 여부 판단 -- 적하차 완료 이벤트를 통해 현재 적재 상태를 실시간 추적

9. 글로벌 확장을 위한 설계

REINDEERS DVRP는 초기 설계부터 다국가 운영을 전제로 개발되었다. 한국, 태국, 말레이시아, 중국 4개국 법인의 물류 환경이 모두 다르기 때문에, 데이터 스키마부터 UI까지 지역 확장성을 고려했다.

  • 국가별 타임존 자동 변환 -- UTC 기준 저장, 사용자 로케일에 따라 자동 변환
  • 전화번호 규격 처리 -- E.164 포맷 기반 통합 관리
  • 다국어 UI -- 한국어, 태국어, 영어, 중국어, 말레이어 5개 언어 지원
  • 국가별 트럭 규격 대응 -- 태국의 6바퀴/10바퀴 트럭, 한국의 1톤/5톤 분류 등 국가별 차량 체계 반영
  • 데이터 스키마의 지역 확장성 -- 국가별 필수 필드(세금번호 형식, 사업자등록 체계 등)를 유연하게 추가 가능한 구조

10. 2026년 로드맵

2026년 3월 — DVRP 베타

  • 입고 ASN·출고 ASN·DO 전체 흐름 검증
  • 트럭 GPS 실환경 테스트
  • RAG 기반 의사결정 검증
  • 재고 할당 엔진 1차 완성

2026년 4~5월 — POP 베타 및 기능 고도화

  • Direct DO 고급 알고리즘 완성
  • AI 스케줄 자동 설정
  • 풀필먼트 연동
  • 포워딩 자동화 기능

REINDEERS DVRP는 단순한 디지털화를 넘어서, AI가 물류를 직접 운영하는 구조를 목표로 설계되었다.

입고에서 출고까지, 그리고 트럭의 실시간 움직임까지. 모든 요소가 하나의 Core Engine에서 움직이며 AI가 업무를 orchestrate하는 구조다. $130B 이상 규모의 동남아 B2B 시장에서 이 수준의 물류 자동화를 구현한 플랫폼은 아직 없다. REINDEERS가 그 첫 번째 사례가 되려고 한다.

관련 글

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 공...