REINDEERS CORE ENGINE DEEP DIVE — PART 2
전 편에서는 재고 할당·직배송 경로 설계·AI Action Schema·RAG 구조 등 물류 시스템의 핵심 알고리즘을 설명했다.
이번 Part 2에서는 REINDEERS 플랫폼의 근본을 지탱하는 배차 엔진, ETA 계산, 이벤트 소싱, 모바일 오프라인 엔진, 멀티테넌시 보안을 기술적 관점에서 심층적으로 다룬다.
7. AI 배차 엔진(Dispatch Engine) — 비용·시간·적재율을 동시에 계산하는 멀티 목표 알고리즘
배차 엔진은 “배송 DO 생성 후” 자동으로 작동한다. 단일 목적 최적화가 아니라, 아래 4개의 목적을 동시에 평가하는 Multi-Objective Optimization 구조를 갖는다.
7.1 평가 지표(Score Model)
score =
(w1 * distance_score)
+ (w2 * eta_score)
+ (w3 * cbm_score)
+ (w4 * cost_score)
- distance_score : 기존 경로에 삽입했을 때 증가하는 총 주행거리
- eta_score : 도착 예정시간(ETA) 지연 정도
- cbm_score : 적재 가능한지, 적재율이 적절한지
- cost_score : 연료 + 인건비 + 트럭 가동 비용
가중치 w1~w4는 회사 정책에 따라 동적으로 변경 가능하다.
7.2 경로 삽입 알고리즘(Route Insertion)
배차 엔진의 핵심은 “진행 중인 트럭의 현재 경로”에 새로운 DO를 삽입할 수 있는지 계산하는 것이다.
기존 경로: [A → B → C]
신규 DO: D
후보:
1) A → D → B → C
2) A → B → D → C
3) A → B → C → D
각 삽입 케이스의 ETA/거리/CBM 계산 → 최적 선택
7.3 배차 결과
- AI 자동 배차 성공
- AI 자동 배차 실패 → 관리자 개입 필요
- 외주 트럭 추천
8. ETA 계산 엔진 — 속도·도로 등급·차량 종류·적재량 기반의 현실적 ETA
일반적인 물류 ETA 계산은 "거리 ÷ 평균속도"로 단순 처리하지만, REINDEERS는 아래 6개 요소를 반영한 가중치 기반 ETA 엔진을 사용한다.
8.1 ETA 구성 요소
- 도로 등급 (고속도로/국도/도심/재래시장 밀집지역)
- 차량 종류(1톤/5톤/냉동/윙바디)
- 적재량(CBM·중량)
- 시간대(출퇴근/심야 등)
- 도심 혼잡도(실시간 API + 과거 통계)
- 기후 요소 (폭우·폭염 시 감속)
8.2 ETA 점수 계산
ETA = base_time
+ traffic_delay
+ load_penalty
+ vehicle_penalty
+ urban_factor
이 계산 결과는 AI 배차 점수에도 반영되며, 전체 DO 스케줄링의 핵심 지표가 된다.
9. 이벤트 소싱 기반 물류 로그(Event Sourcing) — 모든 상태 변화를 재구성 가능한 구조로 저장
물류 시스템은 “입고 → 재고 → 출고 → 배송” 과정이 여러 단계로 나뉜다. 단일 상태 컬럼만 사용하면 원인을 추적할 수 없기에, REINDEERS는 모든 상태 변경을 Event Sourcing 방식으로 저장한다.
9.1 Event Schema
{
"event_id": "ev_239423",
"entity": "delivery_do",
"entity_id": 12034,
"action": "status.update",
"from": "assigned",
"to": "in_transit",
"timestamp": "2025-12-11T09:30:00",
"actor": "driver:902",
"meta": {
"odometer_start": 39200,
"gps": [13.1231, 100.3434]
}
}9.2 Event Sourcing의 이점
- 문제 발생 시 “정확히 언제·누가·무엇을 했는지” 100% 복원 가능
- AI 학습 데이터로 활용 가능
- 실시간 리포트·타임라인 구성에 유리
- 법적 증빙 기록으로도 활용 가능
10. 모바일 오프라인 퍼스트 엔진 — 창고/WMS/기사 앱을 끊김 없이 동작시키기 위한 구조
실제 현장(창고·공장·깊은 공단 지역)에서는 네트워크가 불안정한 경우가 많다. 따라서 모바일 앱은 “오프라인 퍼스트(Offline-first)”로 설계되었다.
10.1 핵심 구조
- 로컬 DB(SQLite)
- 선입력 후동기 방식 (Optimistic UI)
- 충돌 관리(Conflict Resolution)
- Delta Sync (차이만 동기화)
10.2 충돌 처리 예시
1. A 직원: 재고 20 → 15로 스캔
2. B 직원: 재고 20 → 18로 스캔
3. 서버 동기화 시:
- 서버 기준 최신 EventTimestamp 비교
- 이벤트 순서 재구성
- 불일치(discrepancy) 자동 생성
11. 멀티테넌시 보안 구조 — 여러 회사가 한 시스템을 사용해도 100% 데이터 분리
물류 SaaS는 여러 회사의 데이터가 혼재될 위험이 존재한다. 이를 방지하기 위해 REINDEERS는 물리적 테이블 분리 수준에 준하는 논리 격리를 수행한다.
11.1 테넌트 식별자(company_id) 강제 삽입
SELECT * FROM trucks WHERE company_id = :cid
API 요청마다 company_id가 강제 검증된다.
11.2 Role → Company Scope
driver → company_id 제한
wms → company_id 제한
admin → system-wide 접근 (Reindeers 내부 팀)
11.3 회사 간 데이터 접근 시도 → 즉시 403
if (request.company_id != token.company_id) {
abort(403);
}
11.4 AI Action도 멀티테넌시 검사
"action": "create_asn_out",
"context": {
"company_id": 1003
}
→ Action이 실행될 때 company_id가 변조되었는지 다시 검사한다.
12. 전체 엔진 흐름 — 입고/출고/직배송을 하나의 상태머신으로 제어
모든 흐름은 아래와 같은 단일 상태머신을 공유한다.
draft
→ approved
→ processing
→ completed
→ archived
이 상태머신은 아래 5개 엔진이 공유한다.
- 입고 ASN 엔진
- 출고 ASN(OSN) 엔진
- 재고 할당 엔진
- 배차 엔진(DVRP Core)
- 직배송 엔진(Direct DO Routing)
13. 요약 — REINDEERS의 기술 본질
REINDEERS는 단순 물류 솔루션이 아니라, “데이터 기반 자동화 OS”이다.
- AI가 업무를 생성(Action Schema)
- RAG가 문맥을 보완
- 재고 할당 엔진이 실제 물류 흐름을 제어
- DVRP 엔진이 트럭·기사 배차를 자동화
- 오프라인 퍼스트 모바일이 실무 작업을 보조
- Event Sourcing이 모든 기록을 추적 가능하게 저장
- 멀티테넌시가 데이터 보안을 완전 보장
Part 3에서는 “AI 기반 물류 예측(수요예측·출고량·창고 재배치 예측)”과 “트럭 디지털 트윈(Digital Twin) 구조”까지 다룰 예정이다.
Comments
Post a Comment