전 편에서는 재고 할당/직배송 경로 설계/AI Action Schema/RAG 구조 등 물류 시스템의 핵심 알고리즘을 설명했다.
이번 Part 2에서는 REINDEERS 플랫폼의 근본을 지탱하는 배차 엔진, ETA 계산, 이벤트 소싱, 모바일 오프라인 엔진, 멀티테넌시 보안을 기술적 관점에서 심층적으로 다룬다. Part 1이 "무엇을 처리하는가"에 대한 설명이었다면, Part 2는 "어떻게 안정적으로 처리하는가"에 대한 설명이다.
7. AI 배차 엔진(Dispatch Engine) — 비용/시간/적재율을 동시에 계산하는 멀티 목표 알고리즘
배차 엔진은 "배송 DO 생성 후" 자동으로 작동한다. 단일 목적 최적화가 아니라, 아래 4개의 목적을 동시에 평가하는 Multi-Objective Optimization 구조를 갖는다. 일반적인 배차 시스템이 "가장 가까운 차량"만 선택하는 것과 달리, REINDEERS의 배차 엔진은 거리, 도착 시간, 적재 효율, 비용을 동시에 고려하여 전체 최적해를 찾는다.
7.1 평가 지표(Score Model)
score =
(w1 * distance_score)
+ (w2 * eta_score)
+ (w3 * cbm_score)
+ (w4 * cost_score)
- distance_score : 기존 경로에 삽입했을 때 증가하는 총 주행거리. 값이 클수록 패널티가 커진다.
- eta_score : 도착 예정시간(ETA) 지연 정도. 기존 DO들의 ETA에 미치는 영향도 포함.
- cbm_score : 적재 가능한지, 적재율이 적절한지. 트럭의 잔여 CBM과 화물 CBM을 비교.
- cost_score : 연료 + 인건비 + 트럭 가동 비용. 외주 차량 사용 시 추가 비용 반영.
가중치 w1~w4는 회사 정책에 따라 동적으로 변경 가능하다. 예를 들어, "비용 우선" 모드에서는 cost_score의 가중치가 높아지고, "시간 우선" 모드에서는 eta_score의 가중치가 높아진다. "균형" 모드는 4개 지표의 가중치를 동일하게 설정한다. 물류사는 관리자 웹에서 이 모드를 시간대별로 다르게 설정할 수도 있다. 출퇴근 시간대에는 시간 우선, 야간에는 비용 우선으로 자동 전환하는 식이다.
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 계산 → 점수 합산 → 최적 선택
삽입 가능한 모든 위치를 평가하되, 기존 DO의 시간 제약을 위반하는 경우는 즉시 제외된다. 예를 들어, B 지점의 도착 시간 제한이 14:00인데, D를 B 앞에 삽입하면 B 도착이 14:30으로 지연되는 경우, 해당 후보는 필터링된다.
7.3 배차 결과
- AI 자동 배차 성공 — 최적 차량에 DO가 자동 할당되고 관리자에게 알림
- AI 자동 배차 실패 — 가용 차량 없음, 시간 제약 충족 불가 등의 사유와 함께 관리자에게 전달
- 외주 트럭 추천 — 자사 차량으로 불가능한 경우, 외주 차량 풀에서 최적 후보 제시
배차 실패 시 AI는 "왜 실패했는지"를 구조화된 형태로 제공한다. "A 트럭: CBM 초과(2.3CBM 부족), B 트럭: ETA 위반(40분 지연)" 같은 형태다. 관리자는 이 정보를 바탕으로 수동 배차를 결정하거나 외주를 선택할 수 있다.
8. ETA 계산 엔진 — 속도/도로 등급/차량 종류/적재량 기반의 현실적 ETA
일반적인 물류 ETA 계산은 "거리 / 평균속도"로 단순 처리하지만, REINDEERS는 아래 6개 요소를 반영한 가중치 기반 ETA 엔진을 사용한다. 동남아시아, 특히 태국의 도로 환경에서는 단순 거리 기반 ETA가 실제 도착 시간과 30% 이상 차이 나는 경우가 빈번하다.
8.1 ETA 구성 요소
- 도로 등급 (고속도로/국도/도심/재래시장 밀집지역) — 등급별 평균 속도 테이블 관리
- 차량 종류(1톤/5톤/냉동/윙바디) — 차종별 최대 속도 제한 적용
- 적재량(CBM/중량) — 적재율에 따른 감속 계수 반영
- 시간대(출퇴근/심야 등) — 시간대별 교통 지수 테이블
- 도심 혼잡도(실시간 API + 과거 통계) — Google Maps Traffic API 연동
- 기후 요소 (폭우/폭염 시 감속) — 기상청 API 연동, 악천후 시 10~20% 감속 패널티
8.2 ETA 점수 계산
ETA = base_time // 거리 / 도로 등급별 기준 속도
+ traffic_delay // 실시간 교통 지연
+ load_penalty // 적재량에 따른 추가 시간
+ vehicle_penalty // 차종별 속도 제한 반영
+ urban_factor // 도심 진입/이탈 시 추가 시간
이 계산 결과는 AI 배차 점수에도 반영되며, 전체 DO 스케줄링의 핵심 지표가 된다. ETA는 고정값이 아니라 트럭이 이동하는 동안 실시간으로 갱신된다. GPS 데이터를 기반으로 실제 이동 속도와 예측 속도의 차이를 계산하고, 편차가 크면 ETA를 재계산하여 고객사에게 알림을 전송한다. Digital Twin의 eta_adjustment_factor도 이 과정에서 활용된다.
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],
"device": "mobile_app_v2.1"
}
}9.2 Event Sourcing의 이점
- 문제 발생 시 "정확히 언제/누가/무엇을 했는지" 100% 복원 가능 — 이벤트 재생으로 특정 시점의 상태 재현
- AI 학습 데이터로 활용 가능 — 상태 전이 패턴에서 비효율을 감지
- 실시간 리포트/타임라인 구성에 유리 — 고객사 포털에서 배송 진행 상황 표시
- 법적 증빙 기록으로도 활용 가능 — 통관/세관 분쟁 시 근거 자료 제공
이벤트는 append-only 방식으로 저장되며, 한 번 기록된 이벤트는 수정되거나 삭제되지 않는다. 이벤트 데이터는 최근 90일분은 MySQL에, 그 이전 데이터는 아카이브 스토리지에 보관된다. 현재 하루 평균 생성되는 이벤트 수는 수만 건 수준이며, 이 데이터가 AI 예측 엔진의 핵심 학습 데이터로 활용된다.
10. 모바일 오프라인 퍼스트 엔진 — 창고/WMS/기사 앱을 끊김 없이 동작시키기 위한 구조
실제 현장(창고/공장/깊은 공단 지역)에서는 네트워크가 불안정한 경우가 많다. 특히 동남아시아의 물류 현장에서는 이 문제가 더 심각하다. 태국의 대형 창고 내부, 공업 단지, 항만 근처에서는 4G/5G 신호가 약하거나 끊기는 경우가 빈번하다. 따라서 모바일 앱은 "오프라인 퍼스트(Offline-first)"로 설계되었다.
10.1 핵심 구조
- 로컬 DB(SQLite) — 작업 데이터의 로컬 사본 유지
- 선입력 후동기 방식 (Optimistic UI) — 사용자 입력 즉시 로컬에 저장, 서버 동기화는 백그라운드 처리
- 충돌 관리(Conflict Resolution) — 동일 데이터에 대한 동시 수정 시 이벤트 타임스탬프 기반 해결
- Delta Sync (차이만 동기화) — 전체 데이터가 아닌 변경분만 전송하여 네트워크 사용량 최소화
10.2 충돌 처리 예시
1. A 직원: 재고 20 → 15로 스캔 (10:31:05)
2. B 직원: 재고 20 → 18로 스캔 (10:31:12)
3. 서버 동기화 시:
- 서버 기준 최신 EventTimestamp 비교
- 이벤트 순서 재구성 (A가 먼저, B가 나중)
- 불일치(discrepancy) 자동 생성
- 관리자에게 재확인 요청 알림 발송
충돌이 자동으로 해결될 수 없는 경우(두 직원이 동일 SKU에 대해 다른 수량을 입력한 경우), 시스템은 이를 "discrepancy" 레코드로 기록하고 관리자에게 확인을 요청한다. 자동 해결이 가능한 경우(동일 방향의 수정, 예: 두 명 모두 수량을 줄인 경우)에는 타임스탬프 기준 최신 값을 적용한다.
11. 멀티테넌시 보안 구조 — 여러 회사가 한 시스템을 사용해도 100% 데이터 분리
물류 SaaS는 여러 회사의 데이터가 혼재될 위험이 존재한다. 한 물류사의 고객 정보, 재고 데이터, 운송 기록이 다른 물류사에 노출되면 심각한 보안 사고가 된다. 이를 방지하기 위해 REINDEERS는 물리적 테이블 분리 수준에 준하는 논리 격리를 수행한다.
11.1 테넌트 식별자(company_id) 강제 삽입
SELECT * FROM trucks WHERE company_id = :cid
API 요청마다 JWT 토큰에서 company_id가 추출되고, 모든 쿼리에 강제 삽입된다. 이 삽입은 ORM 레벨이 아니라 미들웨어 레벨에서 수행되므로, 개발자가 실수로 company_id 조건을 빠뜨려도 자동으로 추가된다.
11.2 Role → Company Scope
driver → company_id 제한 (자사 배차/DO만 조회 가능)
wms → company_id 제한 (자사 창고/재고만 조회 가능)
admin → system-wide 접근 (REINDEERS 내부 팀만 해당)
11.3 회사 간 데이터 접근 시도 → 즉시 403
if (request.company_id != token.company_id) {
log.warn("Cross-tenant access attempt", {
requested: request.company_id,
actual: token.company_id,
endpoint: request.path
});
abort(403);
}
크로스 테넌트 접근 시도는 모두 로깅되며, 비정상적인 패턴이 감지되면 Telegram을 통해 보안 알림이 발송된다.
11.4 AI Action도 멀티테넌시 검사
"action": "create_asn_out",
"context": {
"company_id": 1003,
"warehouse_id": 205,
"requester": "ai_orchestrator"
}
Action이 실행될 때 company_id가 변조되었는지 다시 검사한다. AI가 생성한 Action이라 하더라도 company_id 검증은 동일하게 적용된다. AI 엔진 자체도 테넌트별로 격리된 컨텍스트에서 실행되므로, 한 물류사의 데이터가 다른 물류사의 AI 학습에 영향을 주지 않는다.
12. 전체 엔진 흐름 — 입고/출고/직배송을 하나의 상태머신으로 제어
모든 흐름은 아래와 같은 단일 상태머신을 공유한다. 상태 전이는 엄격하게 제어되며, 허용되지 않은 전이는 시스템 레벨에서 차단된다.
draft
→ approved (관리자 승인)
→ processing (작업 시작)
→ completed (작업 완료)
→ archived (이력 보관)
이 상태머신은 아래 5개 엔진이 공유한다.
- 입고 ASN 엔진 — 공급사에서 창고로의 입고 프로세스
- 출고 ASN(OSN) 엔진 — 창고에서 고객사로의 출고 프로세스
- 재고 할당 엔진 — FEFO/거리/CBM/LOTT 기반 재고 선택
- 배차 엔진(DVRP Core) — AI 기반 차량 할당 및 경로 최적화
- 직배송 엔진(Direct DO Routing) — 창고 경유 없이 직접 배송하는 경로
하나의 상태머신을 5개 엔진이 공유함으로써, 어떤 유형의 작업이든 동일한 이벤트 로그, 동일한 권한 체계, 동일한 알림 구조가 적용된다. 이는 시스템 복잡도를 크게 줄여준다.
13. 요약 — REINDEERS의 기술 본질
REINDEERS는 단순 물류 솔루션이 아니라, "데이터 기반 자동화 OS"이다. 25,000건 이상의 실거래 데이터와 4,300개 이상의 파트너사 운영 데이터가 이 시스템의 AI를 지속적으로 학습시킨다.
- AI가 업무를 생성(Action Schema) — 구조화된 명령으로 입출고/배차 자동 생성
- RAG가 문맥을 보완 — 고객사 계약 조건, 창고 정책 등을 AI 판단에 반영
- 재고 할당 엔진이 실제 물류 흐름을 제어 — 다중 제약 조건의 동시 평가
- DVRP 엔진이 트럭/기사 배차를 자동화 — 멀티 목표 최적화 기반
- 오프라인 퍼스트 모바일이 실무 작업을 보조 — 네트워크 끊김에도 작업 지속
- Event Sourcing이 모든 기록을 추적 가능하게 저장 — 법적 증빙까지 대응
- 멀티테넌시가 데이터 보안을 완전 보장 — 미들웨어 레벨의 강제 격리
Part 3에서는 "AI 기반 물류 예측(수요예측/출고량/창고 재배치 예측)"과 "트럭 디지털 트윈(Digital Twin) 구조"까지 다룰 예정이다.
시리즈 가이드
이 시리즈는 REINDEERS CORE ENGINE / TECH DEEP DIVE 전체 흐름 중 하나입니다.
- (이전) REINDEERS CORE ENGINE DEEP DIVE — 재고할당·직배송·AI 지시엔진·RAG 인덱싱까지
- (다음) REINDEERS TECH DEEP DIVE — Part 3
- (전체 목록) Part 1(2025-11-22), Part 2, 3, 4, 5, 6, 7, 8