REINDEERS TECH DEEP DIVE — Part 3

REINDEERS CORE ENGINE DEEP DIVE — PART 3

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

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

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

출고량 예측(Outbound Volume Forecast)
재고 회전율 예측(Inventory Turnover Forecast)
배송량·트럭 수요 예측(Delivery Volume Forecast)

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

출고/입고(OSN/ASN) 발행량
고객사별 SKU 사용 패턴
요일·월별 계절성(Seasonality)
리드타임(생산 → 픽업 → 입고 → 출고)
도착지 클러스터(지역 단위 볼륨)
차량 가동률
AI가 수행한 배차 결과(성공/실패/대안 배차)

이렇게 수집된 피쳐는 “전통적 ML 모델”과 “대규모 언어모델 기반 Feature Reasoning”을 결합한 하이브리드 방식으로 처리된다.

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


Raw Data → Feature Extraction → ML Forecast
                       ↘
                       LLM Reasoner → Confidence 수정

ML Forecast: LightGBM / CatBoost 기반 시계열 예측
LLM Reasoner: Google(Gemini), DeepSeek 등을 통한 패턴 보정

LLM은 예측값을 직접 출력하지 않고, 예측 상의 이상치를 조정하는 “보정기(Calibrator)” 역할만 수행한다.

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,  // 정비 이력 기반 점수
  "tire_wear": 0.68,
  "last_event": "pickup_start",
  "eta_adjustment_factor": 1.07
}

15.2 Digital Twin 활용 사례

배차 시 검증: 엔진 상태가 낮으면 장거리 배차 제외
ETA 보정: tire_wear가 높으면 감속 패널티 반영
정비 알림 자동화: 통계 기반 수리 주기 계산
운행 패턴 기반 최적 경로 추천

특히 엔진 건강도(engine_health)와 타이어 마모(tire_wear)는 “이벤트 이력 + 트럭 종류 + 총 주행거리 + 정비간격”을 기반으로 점수화된다.

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

물류 시스템은 이벤트가 많기 때문에 주기적 폴링 방식은 비효율적이다. REINDEERS는 CDC 기반 구조를 도입하여 변화가 발생한 레코드만 AI/캐시에 전달한다.

16.1 CDC 이벤트 종류

INSERT: 새로운 ASN/OSN/DO 생성
UPDATE: 상태 변경, 재고 변경
DELETE: 일반적으로 사용하지 않음(아카이브 처리)

16.2 CDC 이벤트 → 내부 Message Queue


DB Row Change
    ↓
CDC Stream
    ↓
LavinMQ Topic
    ↓
구독자 (AI Orchestrator / Cache Sync)

CDC는 단순 알림만이 아니라, AI가 DO 상태를 실시간 decision-making 할 수 있는 기반이 된다.

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

REINDEERS는 “읽기 비중이 높은 시스템”이기 때문에 캐시 전략이 매우 중요하다. 단순 Redis 캐시가 아니라 아래 3단 구조를 적용한다.

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

트럭 상태(in_transit / cbm / 위치)
실시간 DO 상태
AI 엔진 중간 계산값

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

트럭 지도 실시간 위치
배차 리스트 실시간 업데이트
복잡한 집계 없이 즉시 표시 가능한 값

MySQL을 직접 스트리밍하지 않고 캐시를 경유하기 때문에 서버 부하가 최소화된다.

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

작업 중 피킹 리스트
입고/출고 임시 저장 데이터
네트워크 끊김 대비용 오프라인 데이터

이 3단 구조는 네트워크 상태가 좋지 않더라도, 물류 흐름이 전혀 멈추지 않게 하는 핵심 기술이다.

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

RAG는 단순히 문서 검색을 위한 기술이 아니다. REINDEERS에서는 AI가 실제 업무를 생성해야 하므로 아래 3가지 전략을 결합한 “업무 지시 특화 RAG” 구조를 사용한다.

18.1 Schema-Guided RAG

AI가 반환해야 하는 JSON Schema를 먼저 주고 RAG가 “스키마 관련 정보만” 반환하도록 제한한다.


{
  "task": "create_asn_inbound",
  "fields": {
    "vendor_id": "필수",
    "items": "SKU list",
    "expected_date": "필수"
  }
}

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

ASN → DO → 입고 → 재고 → 출고 → 배송 의 관계를 그래프로 구성하여 RAG가 “업무 흐름 구조” 기반으로 검색하도록 설정한다.

18.3 Conflict-Aware RAG

기존 데이터와 충돌할 경우 AI가 경고를 출력하게 설계한다.


경고: 고객사 A의 창고 위치는 B창고입니다.  
OSN 등록 시 warehouse_id가 충돌합니다.

이 기능 덕분에 사람보다 AI가 더 안전하게 업무를 수행할 수 있다.

19. 전체 구조 요약

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

AI가 업무를 생성하는 Action Schema
재고 할당 엔진(FEFO·거리·CBM·LOTT)
직배송 DO 고급 라우팅
Digital Twin을 이용한 트럭 시뮬레이션
CDC 기반의 실시간 데이터 스트림
3단 캐시 계층 (Redis · Firestore · IndexedDB)
RAG 기반의 안정적 의사결정

다음 Part에서는 “AI 재배치 엔진(AI Relocation Engine)”과 “Dynamic Warehouse Optimization(창고 비용 최적화 모델)”을 기술적으로 상세히 이어서 설명한다.

Blog of Reindeers

Search This Blog