RT-T14: 실시간 재최적화 엔진

🎯 실시간 재최적화 엔진 개요정적 배차 → 동적 이벤트 대응

RT-T13까지는 하루 1회 배치로 확정된 배차 계획을 생성하는 구조를 다뤘다. RT-T14는 이 계획이 운행 중인 상황에서 교통사고·도로 통제·긴급 주문 추가·차량 고장 등의 동적 이벤트가 발생했을 때, 전체 배차 계획을 실시간으로 재최적화하는 엔진을 설계한다.

핵심 목표는 이벤트 감지부터 신규 배차 계획 배포까지 30초 이내 SLA를 만족하는 것이며, 불필요한 재계산을 막기 위해 이중 임계값 트리거(지연 위험 delay_risk 및 예상 추가 비용 cost_delta)로 재최적화 실행 여부를 판정한다. 이미 출발한 차량의 현재 배송지는 변경 불가 제약으로 보존된다.

🧭 이벤트 감지 & 재최적화 파이프라인detect → analyze → trigger → OR-Tools → deploy
STEP 1
event_detect

교통정보 API·주문 시스템·IoT 센서에서 이벤트 스트림 수신. 이벤트 타입/영향 범위 분류.

STEP 2
impact_analyze

영향받는 루트·차량·주문 식별. delay_risk, cost_delta 예측치 계산.

STEP 3
trigger_judge

이중 임계값 판정. 둘 중 하나라도 초과 시 재최적화, 그렇지 않으면 기존 계획 유지.

STEP 4
ortools.resolve

OR-Tools CP-SAT 재계산. 25s 하드 타임아웃, 이동 차량은 고정 제약으로 잠금.

STEP 5
plan_deploy

변경된 배차만 차량 단말·기사 앱에 푸시. 기존 유효 배송은 그대로 승계.

🐍 재최적화 트리거 판정 (Python pseudocode)이중 임계값: OR 게이트
# 재최적화 실행 여부 판정
def should_reoptimize(event):
    delay_risk = predict_delay(event)   # 지연 위험 점수 (0~1)
    cost_delta = estimate_cost(event)   # 예상 추가 비용 (원)
    return (
        delay_risk > 0.6
        or cost_delta > 50000   # 5만원 초과
    )

# 재최적화 제약
OR_TIMEOUT_S = 25     # OR-Tools 타임아웃
SLA_TOTAL_S = 30      # detect→deploy 총 SLA
LOCKED_VEHICLES = get_on_route()  # 이동 중 차량은 고정
🚀 이중 임계값 & 응답 SLAtrigger + response_sla
trigger = delay_risk > 0.6 OR cost_delta > 50,000원
response_sla = detect_ms + solve_ms < 30,000ms
# 둘 중 하나라도 초과 시 재최적화 실행 · SLA 미달 시 이전 계획 유지
traffic교통정보 API에서 사고·정체 감지. 영향 루트만 부분 재계산하여 비용/시간 최소화.
urgentPriority=1 긴급 주문 유입 시 현재 배차에 삽입 최적화. 가장 가까운 여유 차량에 할당.
breakdownIoT 센서로 차량 고장 감지 시 해당 차량 주문을 즉각 재배차. backup 차량으로 이관.
constraint이미 출발한 차량의 현재 배송지 변경 불가. OR-Tools 제약에 고정 노드로 추가하여 해공간 보존.

재최적화는 비용이 크기 때문에 모든 이벤트마다 실행하지 않는다. 경미한 지연(예: delay_risk = 0.3)이거나 추가 비용이 적은 경우(예: cost_delta = 20,000원)에는 기존 계획을 유지한다. 이중 임계값(OR 게이트)은 불필요한 재계산 80% 이상 제거하면서도 실제로 영향이 큰 이벤트는 반드시 포착하도록 설계되었다.

참고문헌
[1] OR-Tools Docs, "CP-SAT Solver Time Limits" (2025.10)
[2] Logistics Viewpoints, "AI in Logistics: What Will Scale in 2026" (2025.12)