잇 AI(Connect AI): 도시 운영을 하나의 AI closed loop로 연결하는 방법

도시의 이동과 물류는 정적인 노선표나 하루 한 번의 배차만으로 운영하기 어렵습니다. 호출 수요가 바뀌고, 주문과 재고가 변하고, 차량과 시설의 상태도 계속 달라집니다. 그때마다 서로 다른 시스템을 열어 보고 판단한 뒤 현장에 전달하는 방식은 속도와 신뢰성 모두에서 한계가 있습니다.

새로운 연결의 시작, 잇

잇은 UMOS ONE이 새롭게 공개한 통합 브랜드입니다. 모빌리티와 물류 곳곳에 흩어진 데이터와 흐름을 연결해, 서비스별 최적화를 넘어 하나의 운영 흐름으로 만든다는 방향을 담고 있습니다. 브랜드 소개에서 확인할 수 있듯, 잇은 각 서비스의 핵심을 연결해 더 직관적인 고객 가치를 만드는 이름이기도 합니다.

잇 AI(Connect AI)는 이 브랜드가 지향하는 연결을 AI 운영 기술로 구현하는 Smart City AI Package입니다. 수요, 경로, 시뮬레이션 결과, 기업 지식과 현장 실행을 하나의 운영 맥락으로 연결합니다.

잇 AI(Connect AI)는 이 문제를 수요 맞춤형 정류장, 물류 배차, 이산 사건 시뮬레이션, 온톨로지 기반 Agentic AI라는 네 가지 엔진으로 나누고, Fleet OS 위에서 다시 하나의 운영 closed loop로 연결합니다. 목적은 AI 기능을 추가하는 것이 아니라, 상황을 이해하고, 결과를 검증하고, 실행한 뒤 다시 운영 데이터로 학습하는 구조를 만드는 것입니다.

문제는 경로 하나가 아니라 운영 전체입니다

예를 들어 출퇴근 셔틀을 설계할 때는 승객을 어느 정류장에 모을지, 차량을 몇 대 투입할지, 도보와 탑승 시간이 어느 정도인지가 함께 결정되어야 합니다. 물류에서는 배송지 순서뿐 아니라 어느 권역을 전용차량으로 운영할지, 당일 발생한 긴급 주문을 어떻게 흡수할지, 차량과 재고의 상태가 어떤지까지 고려해야 합니다.

여기에 정책 또는 설계 변경의 위험도 있습니다. 차량을 늘리거나 물동량이 두 배가 되었을 때 병목이 어디서 생기는지는 실제 운영에 적용하기 전에는 알기 어렵습니다. 그래서 잇 AI는 아래 다섯 단계를 하나의 연결된 흐름으로 봅니다.

단계	운영 질문	잇 AI의 역할
Understand	지금 무엇이 일어나고 있는가	온톨로지와 Enterprise Knowledge Base로 데이터와 맥락을 연결
Simulate	이 정책을 적용하면 어떤 일이 벌어지는가	차량·사람·화물·시설 자원의 흐름을 디지털 트윈으로 재현
Optimize	어떤 정류장·권역·경로가 실행 가능한가	VRP, CP-SAT, VROOM과 RL-SPH로 제약을 반영한 해 탐색
Act	누가 어떤 일을 실행해야 하는가	검증·승인된 액션을 현장 시스템에 전달하고 이력을 남김
Deliver	고객의 실제 업무에 어떻게 녹일 것인가	Fleet OS와 Connect AI를 재사용해 고객별 SaaS로 구현

각 단계는 독립 제품처럼 보일 수 있지만, 실제 현장에서는 앞 단계의 결과가 다음 단계의 입력이 됩니다. 시뮬레이션은 최적화 결과를 검증하고, 온톨로지는 실행 판단의 근거를 제공하며, 실행 이력은 다시 다음 계획의 데이터가 됩니다.

1. 수요가 있는 곳을 정류장으로 바꾸는 VRP

고정 정류장과 고정 노선은 수요가 바뀔 때마다 비효율을 남깁니다. 잇Shuttle의 수요 맞춤형 정류장 설계는 직원 또는 승객 분포에서 출발합니다.

먼저 K-Medoids로 최대 도보거리 안의 승객을 묶어 가상 정류장 후보를 만듭니다. 이후 OSRM으로 후보를 실제 도로 위에 정규화하고 거리·시간 행렬을 생성합니다. 마지막으로 OR-Tools의 CVRP를 사용해 차량 유형, 적재 용량, 방문 순서를 함께 결정합니다.

승객 주소와 차량 구성
  → 도보 제약을 만족하는 정류장 후보
  → 실도로 거리·시간 행렬
  → 차량별 방문 순서와 노선
  → 도보·탑승 시간, 필요 차량 수, 예상 비용 비교

이 과정에서 중요한 기준은 최단 경로만이 아닙니다. 승객의 도보 부담과 차량의 우회 비용, 노선 간 균형을 함께 봐야 실제로 수용할 수 있는 운영안이 나옵니다. 현재 이 기능은 비용·도보·탑승시간을 비교하는 설계 및 시나리오 엔진이며, 실제 운행 지시까지 자동화하는 단계와는 분리해서 해석합니다.

2. 권역 설계에서 당일 배차까지 이어지는 잇Truck

물류 최적화의 질문은 “배송지를 어떤 순서로 돌 것인가”에서 끝나지 않습니다. “어떤 지역을 전용차량 권역으로 묶을 때 사업적으로 이득인가”와 “오늘 들어온 주문을 어떤 차량이 방문해야 하는가”는 다른 시간 단위의 문제입니다.

잇Truck은 이를 두 단계로 풉니다.

1. 권역 설계: 읍면동 인접 그래프에서 근무시간, 월 용량, 행정 경계, 지리 단절 같은 현장 제약을 지키며 권역 후보를 만듭니다. 절감액이 양수인 후보 중에서는 OR-Tools CP-SAT의 set packing으로 서로 겹치지 않는 조합을 선택합니다.
2. 당일 배차: 선택된 권역과 당일 주문을 Valhalla 실도로 행렬과 VROOM에 전달해 적재량, 방문 수, 체류시간, 도착 시간창을 고려한 차량 배정과 방문 순서를 만듭니다.

이 구조의 핵심은 최적화의 결과를 실행 가능성으로 다시 검증하는 데 있습니다. 후보 단계에서는 빠르게 계산하되, 선정된 권역은 실제 배송지 좌표와 운행일별 주문으로 다시 라우팅해 손익분기 물량과 운영시간을 통과한 경우만 채택합니다.

RL-SPH는 이 위에서 복잡한 상위 배정 문제의 실행가능해를 빠르게 탐색하는 확장 축입니다. 즉, 현재의 권역 후보 생성·CP-SAT 조합 선택·VROOM 실행 경로를 대체하는 이름이 아니라, 동적 재계획이 필요한 상황에서 탐색 범위를 넓히는 보완 계층으로 설계하고 있습니다.

3. 가정 검증을 실시간 운영으로 이어가는 Smart City 시뮬레이터

정책이나 배차안을 현장에 적용하기 전에, 차량·사람·화물이 공간과 자원을 어떻게 점유하는지 먼저 확인할 수 있어야 합니다. 잇 AI의 DES 엔진은 SimPy로 구현한 이산 사건 시뮬레이션을 기반으로 건물, 물류 허브, 교통 시설의 공간·자원·경로와 객체 흐름을 이벤트 단위로 표현합니다. 시간축을 일정 간격으로 단순히 샘플링하는 것이 아니라, 도착·자원 요청·서비스 시작·이동·완료 같은 사건이 발생할 때만 시뮬레이션 시간이 전진합니다.

Smart City 시뮬레이터 하이라이트. 차량·사람·화물의 흐름과 시설 상태를 시간대별로 재생한다.

모델 입력은 IFC 또는 고객 인테이크 데이터를 공통 Model Contract로 정규화합니다. 이 계약은 공간과 링크, 용량 제약이 있는 자원, actor별 경로, 업무량, 운영 정책을 분리해 표현합니다. Workload에는 시간대별 수요, 도착 패턴, 서비스 시간 분포, 실행 seed를 별도 입력으로 두므로, 같은 물리 모델에 다른 물동량이나 정책을 적용해 비교할 수 있습니다.

Model Contract   space · link · resource(capacity) · route · policy
Workload         entity_type · arrival pattern · service-time distribution · volume
Scenario         model + workload + seed + comparison factors

예를 들어 차량, 사람, 화물은 각각 SimPy process로 생성되고, 경로의 각 step에서 link 또는 resource를 요청합니다. PriorityResource와 배치 게이트는 우선순위, 용량, 최대 배치 대기시간을 모델링하며, 요청·timeout 경쟁은 자원을 기다리다 이탈하는 운영 상황도 표현합니다. 엔진은 대기시간, 점유시간, 처리량, 자원 사용률과 hotspot을 원시 이벤트와 함께 기록합니다.

MODEL      공간·자원·경로·업무량을 공통 모델로 정규화
SIMULATE   도착·이동·대기·점유·완료 이벤트를 실행
COMPARE    SimPy와 외부 엔진의 결과를 동일 조건에서 비교
EVIDENCE   KPI, 병목, 혼잡, 시계열 이벤트를 운영 화면에 전달

같은 Model Contract, Workload, seed를 로컬 SimPy와 외부 FlexSim에 전달하는 compare 모드는 결과를 엔진별로 교차 검증합니다. 원격 엔진 실행 실패를 임의의 로컬 결과로 대체하지 않는 것도 검증의 원칙입니다. 반복 실험에서는 seed를 바꾼 다중 실행과 신뢰구간을 통해, 정책의 효과와 확률적 변동을 구분합니다.

시뮬레이터는 사전 PoC를 위한 도구로만 머물지 않습니다. 운영 중에는 차량·사람·화물의 위치와 유입 이벤트를 디지털 트윈에 반영하고, 자원 가동률, 대기열, 병목·혼잡 신호를 Smart City Monitoring으로 전달합니다. 운영자는 시간대별 리플레이로 이동을 확인하고, Active·Waiting·Done·Hotspot 상태를 추적하며, 선택한 자원의 병목 원인과 개선안을 함께 분석할 수 있습니다. 대규모 모델에서는 빠른 스크리닝과 상세 이벤트 시뮬레이션의 결과 해석 범위를 분리해, 속도를 위해 근사한 지표를 정밀 DES 결과처럼 취급하지 않도록 설계합니다.

4. 기업 지식을 근거 있는 답변과 행동으로 바꾸는 Ontology Agent

LLM이 기업 운영을 돕기 위해서는 단순한 문서 검색을 넘어, 차량·화물·위치·작업·조직이 서로 어떤 관계인지 알아야 합니다. 잇 AI의 Ontology Bot은 WMS, TMS, FMS, TAP에 흩어진 용어와 데이터를 상위 온톨로지로 연결해 LLM 기반 Enterprise Knowledge Base의 토대를 만듭니다. OWL TBox는 도메인 개념과 관계를 정의하고, ABox는 실제 운영 객체와 이벤트를 담습니다.

이 계층은 “현재 지연된 차량은 무엇인가” 같은 단일 도메인 질문뿐 아니라, “창고 출고 지연이 오늘 배차에 어떤 영향을 주는가”처럼 시스템을 가로지르는 질문을 다룰 수 있게 합니다. 오케스트레이터는 자연어 질문을 도메인별 작업으로 나누고, 에이전트는 SPARQL로 그래프 근거를 조회한 뒤 하나의 답변 또는 실행 제안으로 조합합니다. 응답에는 단순 결론뿐 아니라 어떤 객체·관계·데이터가 근거가 되었는지를 추적할 수 있는 경로가 남습니다.

SHACL은 LLM이 만든 쿼리의 구조를 점검한다

SHACL은 여기서 자유 형식의 자연어 답변을 채점하는 도구가 아닙니다. LLM이 생성한 SPARQL이 존재하지 않는 클래스나 속성을 사용하거나, 특정 클래스에 허용되지 않은 속성을 붙이는 구조적 오류를 실행 전에 찾는 Enterprise Guardrail입니다.

FMS 도메인에서는 TBox TTL에서 sh:closed NodeShape와 class-property 제약을 생성합니다. 쿼리 후보는 RDFLib SPARQL parser로 실행 없이 해석하고, 사용한 Class → property 쌍을 추출합니다. 이를 최소 RDF 그래프로 만든 뒤 pyshacl로 Shape에 대조합니다.

LLM-generated SPARQL
  → RDFLib algebra parse
  → class/property usage extraction
  → SHACL NodeShape validation with pyshacl
  → regeneration feedback or guarded execution result

이 방식은 단순히 Vehicle과 hasAvailableStatus라는 이름이 각각 존재하는지 확인하는 flat allow-list보다 강합니다. 예를 들어 hasAvailableStatus가 정의된 속성이더라도 다른 클래스에 잘못 붙이면 class-property 제약 위반으로 검출할 수 있습니다. 검증 결과는 생성 재시도 프롬프트에 피드백으로 제공되고, 운영 모드에 따라 경고와 감사 근거로 남습니다. Shape는 TBox에서 생성하므로, 온톨로지 정의와 검증 규칙이 서로 다른 스냅샷으로 드리프트하는 위험도 줄입니다.

액션 실행은 SHACL과 별도의 통제 계층을 갖습니다. OWL ActionType의 mutation type, 파라미터 범위, 현재 상태와 상태 전이를 검증하고, 필요한 경우 사람의 승인 토큰을 받은 뒤 Local, REST, MCP 인터페이스로 실행합니다. 실행 전 원격 상태와 그래프 상태를 재조정하고, 결과는 감사 로그와 관측 데이터로 남깁니다.

현재 구현 범위는 현황 조회와 원인 연결을 중심으로 한 Descriptive·Diagnostic 추론, 복합 질의 계획, FMS SPARQL 경로의 SHACL 기반 구조 검증, 검증·승인 기반 액션 실행입니다. 환경 변화에 따라 정책을 스스로 바꾸는 완전 자율 Adaptive 운영과 모든 도메인으로의 SHACL 확대는 다음 확장 단계로 남겨두고 있습니다.

Fleet OS와 AI-Native Enterprise SaaS Foundry

네 개의 엔진을 고객사마다 처음부터 다시 만들면, 도입 속도와 운영 품질 사이에서 계속 타협하게 됩니다. 잇 AI는 Fleet OS를 공통 기반으로 둡니다. Fleet OS는 차량·사람·화물의 상태와 이벤트 수집, 고객 시스템 연계, 권한·보안, 워크플로, 현장 실행을 담당합니다.

그 위에 Connect AI Package가 VRP, RL-SPH, DES, Ontology Agent를 연결하고, AI-Native Enterprise SaaS Foundry가 고객별 화면·워크플로·업무 규칙을 구현합니다. 이 구조가 뜻하는 바는 단순한 커스터마이징이 아닙니다. 플랫폼에서 검증된 데이터 모델과 실행 인터페이스를 재사용하면서도, 고객의 운영 방식에 맞춘 잇Shuttle, 잇Truck, 잇Stock, 잇Fleet을 빠르게 제공하는 방식입니다.

AI로 빠르게 만들고, 플랫폼으로 품질을 보증합니다. 개발 기간과 비용을 낮추되, 보안·운영 안정성·확장성은 공통 플랫폼의 기준을 따릅니다.

잇 AI가 먼저 풀고자 하는 세 가지 현장 문제

적자 노선과 배차 비효율을 줄이는 수요응답형 모빌리티

수요가 낮은 고정 노선을 지역 맞춤형 DRT로 재설계하고, 승객 분포에서 가상 정류장과 셔틀 경로를 생성합니다. 운행 전에 필요 차량 수, 도보·탑승시간, 예상 비용을 비교해 접근성과 운영 경제성을 함께 판단합니다.

배송비·공차·지연을 동시에 줄이는 동적 물류 운영

주문, 재고, 차량 상태를 연결해 당일 실행 가능한 배차를 만들고, 긴급 주문, 지연, 도로 변화가 발생하면 재계획합니다. 운영자는 도착 예정, 차량 가동률, 미배정 주문, 재고 흐름을 하나의 맥락에서 추적합니다.

투자 전에 병목과 운영 리스크를 검증하는 디지털 트윈

물동량, 차량 수, 운영 정책을 바꿔가며 대안별 결과를 비교하고, 대기열·자원 가동률·혼잡 구간을 시계열로 식별합니다. KPI와 실행 이력, 3D 리플레이는 투자와 정책 판단의 근거로 남습니다.

마치며

잇 AI의 핵심은 VRP, 강화학습, 시뮬레이션, 온톨로지 중 하나를 고르는 데 있지 않습니다. 운영 데이터를 이해하는 계층, 미래를 검증하는 계층, 실행 가능한 해를 만드는 계층, 그리고 현장에 안전하게 전달하는 계층을 끊기지 않게 연결하는 데 있습니다.

이제 1차 구현 범위를 기반으로 고객 현장의 실제 데이터와 업무 규칙을 연결하고, 시나리오 검증에서 운영 SaaS까지 이어지는 closed loop를 확장해 나가고자 합니다.