Skip to main content

REINDEERS TECH DEEP DIVE — Part 3

이번 Part 3에서는 REINDEERS 플랫폼의 고급 엔진 아키텍처를 다룬다. 실제 운영에서 필요한 AI 예측 엔진, 트럭 디지털 트윈, 고급 캐시 계층, CDC 기반 실시간 데이터 스트림 등 플랫폼의 "지능화 및 자동화 기반 기술"을 상세하게 설명한다.

Part 1에서 재고 할당과 직배송 경로 설계를, Part 2에서 배차 엔진과 이벤트 소싱을 다루었다. 여기까지가 "실행 레이어"였다면, Part 3은 실행을 뒷받침하는 "지능 레이어"에 해당한다. 데이터가 쌓이면서 시스템이 점점 더 정확한 판단을 내릴 수 있도록 하는 기술들이다.


14. AI 예측 엔진(Forecasting Engine) — 출고량/재고회전/배송량 예측

물류 데이터가 누적되기 시작하면 가장 먼저 도입되는 기능이 예측이다. REINDEERS의 예측 엔진은 다음 3가지를 핵심 목표로 둔다.

  • 출고량 예측(Outbound Volume Forecast) — 향후 7일/14일/30일 단위
  • 재고 회전율 예측(Inventory Turnover Forecast) — SKU별 적정 재고 수준 산출
  • 배송량/트럭 수요 예측(Delivery Volume Forecast) — 일별 필요 차량 대수 추정

예측 엔진은 단순히 "내일 출고가 얼마나 될까"를 넘어서, 실질적인 운영 결정에 연결된다. 출고량 예측이 정확하면 작업자 배치를 사전에 조정할 수 있고, 트럭 수요 예측이 정확하면 외주 차량 사전 확보나 불필요한 대기 비용을 줄일 수 있다. REINDEERS의 25,000건 이상의 실거래 데이터는 이 예측 모델의 학습 데이터로 활용된다.

14.1 예측에 사용하는 주요 피쳐(Features)

  • 출고/입고(OSN/ASN) 발행량 — 일별/주별 시계열 데이터
  • 고객사별 SKU 사용 패턴 — 특정 고객사의 주기적 발주 주기
  • 요일/월별 계절성(Seasonality) — 명절, 프로모션 시즌의 볼륨 변화
  • 리드타임(생산 → 픽업 → 입고 → 출고) — 공급망 전체 소요 시간
  • 도착지 클러스터(지역 단위 볼륨) — 특정 지역 집중도 분석
  • 차량 가동률 — 현재 가용 차량 대비 사용률
  • AI가 수행한 배차 결과(성공/실패/대안 배차) — 이전 배차의 성과 피드백

이렇게 수집된 피쳐는 "전통적 ML 모델"과 "대규모 언어모델 기반 Feature Reasoning"을 결합한 하이브리드 방식으로 처리된다. 두 가지 방식을 결합한 이유는 명확하다. 시계열 예측은 ML이 더 정확하지만, 비정형 이벤트(갑작스러운 정책 변경, 자연재해 등)에 대한 보정은 LLM이 더 유연하기 때문이다.

14.2 하이브리드 예측 프로세스


Raw Data → Feature Extraction → ML Forecast
                       ↘
                       LLM Reasoner → Confidence 수정
  • ML Forecast: LightGBM / CatBoost 기반 시계열 예측 — 정량적 패턴 학습에 최적화
  • LLM Reasoner: Google(Gemini), DeepSeek 등을 통한 패턴 보정 — 이상치 탐지 및 신뢰도 조정

LLM은 예측값을 직접 출력하지 않고, 예측 상의 이상치를 조정하는 "보정기(Calibrator)" 역할만 수행한다. 예를 들어, ML이 "내일 출고량 200건"을 예측했는데 LLM이 "내일은 태국 공휴일이므로 출고량이 평소의 30% 수준일 가능성이 높다"고 판단하면 신뢰도를 하향 조정한다. 최종 예측값은 ML 예측 기반에 LLM의 신뢰도 가중치가 적용된 값이다.


15. 트럭 Digital Twin — 가상 트럭 상태 시뮬레이션

REINDEERS는 차량마다 Digital Twin(가상 모델)을 유지한다. 이는 실제 트럭 운행 상태를 디지털로 재현하여 배차/정비/경로예측에 모두 사용된다. 물리적 트럭의 현재 상태를 소프트웨어로 복제함으로써, 배차 엔진이 각 차량의 실제 역량을 정확하게 평가할 수 있다.

15.1 Digital Twin 데이터 구조

{
  "truck_id": 901,
  "status": "in_transit",
  "load_cbm": 3.2,
  "max_cbm": 5.0,
  "battery": 78,          // 전기트럭 사용 시
  "engine_health": 0.92,  // 정비 이력 기반 점수 (0~1)
  "tire_wear": 0.68,      // 타이어 마모도 (0~1, 1이 신품)
  "last_event": "pickup_start",
  "eta_adjustment_factor": 1.07,
  "total_km": 128400,
  "last_maintenance": "2025-11-20"
}

15.2 Digital Twin 활용 사례

  • 배차 시 검증: 엔진 상태(engine_health)가 0.7 미만이면 장거리 배차에서 제외
  • ETA 보정: tire_wear가 높으면 감속 패널티 반영하여 도착 시간을 보수적으로 계산
  • 정비 알림 자동화: 총 주행거리, 정비 간격, 엔진 건강도를 종합하여 정비 시점 예측
  • 운행 패턴 기반 최적 경로 추천: 해당 차량의 과거 운행 데이터에서 최적 속도 구간 학습

특히 엔진 건강도(engine_health)와 타이어 마모(tire_wear)는 "이벤트 이력 + 트럭 종류 + 총 주행거리 + 정비간격"을 기반으로 점수화된다. 이 점수는 실시간으로 갱신되며, GPS 데이터에서 추출한 급가속/급제동 빈도도 엔진 건강도에 영향을 미친다. Digital Twin은 Redis에 캐싱되어 배차 엔진이 조회할 때 지연 없이 최신 상태를 참조할 수 있다.


16. CDC(Change Data Capture) — 실시간 데이터 스트림 기반 알림/AI

물류 시스템은 이벤트가 많기 때문에 주기적 폴링 방식은 비효율적이다. REINDEERS는 CDC 기반 구조를 도입하여 변화가 발생한 레코드만 AI/캐시에 전달한다. 폴링 방식은 변경이 없어도 매번 DB를 조회하기 때문에 불필요한 부하가 발생한다. CDC는 DB의 변경 로그(binlog)를 직접 읽어서 변경분만 추출하므로 DB 부하를 최소화하면서도 실시간성을 확보할 수 있다.

16.1 CDC 이벤트 종류

  • INSERT: 새로운 ASN/OSN/DO 생성 — AI 배차 엔진 트리거
  • UPDATE: 상태 변경, 재고 변경 — 캐시 무효화 및 대시보드 갱신
  • DELETE: 일반적으로 사용하지 않음(아카이브 처리) — 데이터 보존 정책 준수

16.2 CDC 이벤트 → 내부 Message Queue


DB Row Change (MySQL binlog)
    ↓
CDC Stream (변경분 추출)
    ↓
LavinMQ Topic (메시지 라우팅)
    ↓
구독자 (AI Orchestrator / Cache Sync / Dashboard)

CDC는 단순 알림만이 아니라, AI가 DO 상태를 실시간 decision-making 할 수 있는 기반이 된다. 예를 들어, 새로운 출고 요청(OSN)이 INSERT되면 CDC가 이를 감지하고, LavinMQ를 통해 AI Orchestrator에 전달한다. AI Orchestrator는 즉시 재고 할당과 배차를 시작한다. 이 전체 과정이 사람의 개입 없이 수 초 내에 완료된다.


17. 고급 캐시 계층 — Redis + Firestore + Local Index의 3단 구조

REINDEERS는 "읽기 비중이 높은 시스템"이기 때문에 캐시 전략이 매우 중요하다. 트럭 위치 조회, 재고 현황, 배차 상태 등은 초당 수천 건의 읽기 요청이 발생한다. 단순 Redis 캐시가 아니라 아래 3단 구조를 적용한다.

17.1 1단계: Redis (핵심 실시간 데이터)

  • 트럭 상태(in_transit / cbm / 위치) — TTL 30초, GPS 수신 시마다 갱신
  • 실시간 DO 상태 — 상태 변경 이벤트 발생 시 CDC를 통해 자동 갱신
  • AI 엔진 중간 계산값 — 배차 점수, ETA 계산 결과 등
  • Digital Twin 데이터 — 차량별 최신 상태 정보

17.2 2단계: Firestore (React 프론트 실시간 스트림)

  • 트럭 지도 실시간 위치 — 관리자 대시보드에 실시간 표시
  • 배차 리스트 실시간 업데이트 — 상태 변경 시 즉시 반영
  • 복잡한 집계 없이 즉시 표시 가능한 값 — 프론트엔드 최적화

MySQL을 직접 스트리밍하지 않고 캐시를 경유하기 때문에 서버 부하가 최소화된다. Firestore를 선택한 이유는 Next.js 기반 프론트엔드와의 실시간 연동이 용이하고, 별도의 WebSocket 서버를 운영할 필요가 없기 때문이다. Redis에서 Firestore로의 동기화는 CDC 이벤트를 구독하는 Worker가 처리한다.

17.3 3단계: Local IndexedDB (모바일/웹 오프라인)

  • 작업 중 피킹 리스트 — 스캔 데이터 로컬 저장
  • 입고/출고 임시 저장 데이터 — 작업 완료 전 중간 저장
  • 네트워크 끊김 대비용 오프라인 데이터 — 동기화 전까지 로컬에서 작업 가능

이 3단 구조는 네트워크 상태가 좋지 않더라도, 물류 흐름이 전혀 멈추지 않게 하는 핵심 기술이다. 동남아시아 물류 현장에서는 창고 내부, 공단 지역, 항만 인근에서 네트워크가 불안정한 경우가 흔하다. 이 환경에서도 작업이 중단되지 않도록 오프라인 퍼스트 설계가 적용되었다.


18. RAG 강화 전략 — 도메인 지식 기반 물류 의사결정

RAG는 단순히 문서 검색을 위한 기술이 아니다. REINDEERS에서는 AI가 실제 업무를 생성해야 하므로 아래 3가지 전략을 결합한 "업무 지시 특화 RAG" 구조를 사용한다. 일반적인 RAG가 "질문에 대한 답변 검색"에 초점을 맞추는 것과 달리, REINDEERS의 RAG는 "올바른 업무 명령을 생성하기 위한 컨텍스트 제공"을 목적으로 한다.

18.1 Schema-Guided RAG

AI가 반환해야 하는 JSON Schema를 먼저 주고 RAG가 "스키마 관련 정보만" 반환하도록 제한한다. 이 방식은 AI가 불필요한 정보에 혼란을 겪지 않도록 하며, 생성되는 Action의 데이터 정합성을 보장한다.


{
  "task": "create_asn_inbound",
  "fields": {
    "vendor_id": "필수 - 공급사 ID",
    "items": "SKU list - 품목 및 수량",
    "expected_date": "필수 - 입고 예정일",
    "warehouse_id": "필수 - 대상 창고"
  }
}

18.2 Graph RAG (업무 관계 그래프)

ASN → DO → 입고 → 재고 → 출고 → 배송 의 관계를 그래프로 구성하여 RAG가 "업무 흐름 구조" 기반으로 검색하도록 설정한다. 예를 들어 "출고 요청"이라는 컨텍스트에서 RAG가 검색할 때, 단순 키워드 매칭이 아니라 출고 노드와 연결된 재고/피킹/배차 노드의 정보까지 함께 반환한다. 이를 통해 AI는 전후 맥락을 이해한 상태에서 업무를 생성할 수 있다.

18.3 Conflict-Aware RAG

기존 데이터와 충돌할 경우 AI가 경고를 출력하게 설계한다. 충돌 감지는 RAG 검색 결과에 포함된 데이터와 현재 요청 데이터를 비교하여 수행된다.


경고: 고객사 A의 지정 창고는 B창고입니다.
현재 OSN 등록 시 warehouse_id가 C창고로 지정되어 충돌합니다.
→ 계약 조건 위반 가능성이 있습니다.

이 기능 덕분에 사람이 놓치기 쉬운 계약 조건 위반이나 데이터 불일치를 AI가 사전에 감지할 수 있다. 3PL 운영에서 고객사별 계약 조건은 매우 다양하고 복잡하기 때문에, 이런 자동 충돌 감지는 운영 안정성에 크게 기여한다.


19. 전체 구조 요약

Part 1 ~ 3에서 다룬 기술은 아래와 같이 정리할 수 있다.

  • AI가 업무를 생성하는 Action Schema — 구조화된 JSON 기반 업무 명령
  • 재고 할당 엔진(FEFO/거리/CBM/LOTT) — 다중 제약 조건 동시 평가
  • 직배송 DO 고급 라우팅 — 중간 창고 없이 직접 배송하는 경로 최적화
  • Digital Twin을 이용한 트럭 시뮬레이션 — 차량 상태의 실시간 가상 모델링
  • CDC 기반의 실시간 데이터 스트림 — 폴링 없는 이벤트 기반 아키텍처
  • 3단 캐시 계층 (Redis / Firestore / IndexedDB) — 서버부터 클라이언트까지 연결된 캐시
  • RAG 기반의 안정적 의사결정 — Schema-Guided + Graph + Conflict-Aware

이 기술들은 독립적으로도 의미가 있지만, 하나의 시스템으로 통합될 때 진정한 가치가 발휘된다. 다음 Part에서는 "AI 재배치 엔진(AI Relocation Engine)""Dynamic Warehouse Optimization(창고 비용 최적화 모델)"을 기술적으로 상세히 이어서 설명한다.

시리즈 가이드

이 시리즈는 REINDEERS CORE ENGINE / TECH DEEP DIVE 전체 흐름 중 하나입니다.

관련 글

Popular posts from this blog

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

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

레인디어스, Buybly로 동남아시아 산업자재 시장 혁신

B2B 오픈마켓 REINDEERS, 한국 기업의 글로벌 진출을 돕다 레인디어스, 머신러닝 기반의 산업자재 매칭 솔루션으로 경쟁력 강화 김명훈 레인디어스 대표 산업자재 시장의 복잡성과 유통장벽은 많은 기업들에게 큰 도전 과제가 되어왔다. 특히 동남아시아 시장 진출을 원하는 한국의 산업자재 제조사들은 현지의 불투명한 거래 환경과 물류 문제로 어려움을 겪어왔다. 이러한 상황에서 레인디어스의 REINDEERS 플랫폼은 새로운 기회를 제시하고 있다. REINDEERS는 B2B 오픈마켓으로, 한국 기업들이 손쉽게 동남아시아 시장에 진출할 수 있도록 지원하며, 유통의 복잡성을 해결하는 혁신적인 솔루션으로 주목받고 있다. 이러한 변화의 중심에는 레인디어스 대표가 있다. 그는 지난 9년간 태국에서의 경험을 바탕으로 고객의 pain point를 해결하기 위해 REINDEERS를 개발했다. 이번 인터뷰를 통해 그의 비전과 경영 철학, 그리고 REINDEERS가 어떻게 산업자재 시장을 변화시키고 있는지에 대해 깊이 있는 이야기를 나누게 되었다. 김명훈 레인디어스 대표 -.소개 레인디어스는 국내 산업자재 제조사들이 동남아시아 시장에 쉽게 진출할 수 있도록 돕는 B2B 오픈마켓인 REINDEERS를 운영하고 있다. 해외 시장 진출에서 가장 큰 장애물인 유통, 물류, 무역의 장벽을 해결해주는 것이 이 플랫폼의 핵심이다. REINDEERS는 단순한 거래 플랫폼이 아니라, 산업자재 구매와 공급 과정을 간소화하고 최적화하는 One-Stop 솔루션으로 자리 잡았다. 레인디어스의 서비스는 REINDEERS와 Enterprise Solution(ERP, POP, WMS)으로 구성되어 있다. 이 솔루션은 동남아시아 현지의 고객사와 공급사에 맞춤형으로 제공되며, 산업현장의 선진화를 이끌어낸다. 기업 운영과 생산 관리, 재고 관리를 전산화해 이익을 극대화하는 데 기여하고 있다. REINDEERS는 산업현장에서 획득한 Raw data를 활용해 인공지능 분석을 통해 발주 ...

JD 플랫폼 매니저 (Platform Manager )

🇰🇷 플랫폼 매니저 (운영 / 글로벌 B2B & AI Agent 기반 자동화 플랫폼) 회사명: (주)레인디어스 | REINDEERS Co., Ltd. 근무지: 서울 / 방콕 (Hybrid 가능) 고용형태: 정규직 (계약-전환형 가능) 회사 소개 REINDEERS는 산업자재 및 무역 중심의 글로벌 B2B 플랫폼을 운영하는 기술 기반 기업입니다. 한국, 태국, 말레이시아, 중국 4개 주요 아시아 시장에서 견적–발주–물류(3PL)–통관–정산–재고관리(WMS)를 통합 관리하는 시스템을 제공합니다. REINDEERS는 POP과 DVRP를 AI로 전환되는 구조로 설계하고 있습니다. 사람은 전략과 방향을 결정하고, 실제 업무는 AI Agent가 실행하는 구조입니다. 조직도에 직원을 등록할 때 사람, AI Agent, 로봇 중에서 선택할 수 있으며, 같은 워크플로우와 같은 권한 체계로 협업합니다. CEO Agent가 전사 전략과 자원 배분을 총괄하고, 구매·생산·영업·물류·재무·통관 Agent가 각 부서 업무를 자율적으로 실행합니다. REINDEERS는 운영 중심의 플랫폼 관리 전문가를 찾습니다. 본 포지션은 플랫폼의 운영·유지·관리·발전·확장을 담당하며, 사람 담당자와 AI Agent, 그리고 향후 합류할 로봇 작업자가 같은 조직도 안에서 협업하는 환경을 관리하는 역할을 맡습니다. (※ 개발 업무를 직접 수행하지 않으며, 개발팀 및 AI Agent 팀과 협업해 개선을 주도합니다.) 이 포지션이 일하는 환경 REINDEERS는 POP과 DVRP를 "조직도 기반 AI 법인" 구조로 설계하고 있습니다. 외부 AI 도구를 연결하는 방식이 아니라, AI Agent가 회사 조직 구조에 직접 통합되어 있습니다. 플랫폼 매니저는 이 Agent들이 정상적으로 작동하는지 모니터링하고, 예외 상황에 대한 승인과 에스컬레이션을 처리하며, 사람 운영자와 AI Agent 간의 협업 경계를 정의하는 역할을 합니다. 현재는 Tool 단계(사...