권역 기준이 문서에 없다
어느 동을 어느 차에 붙일지가 담당자 경험에 남아 있습니다. 담당자가 바뀌면 기준도 같이 사라집니다.
물류 운송 관리 SaaS
하나의 배차 엔진,
회사마다 다른 운영 기준
주문 접수부터 배송·정산 완료까지 한 흐름으로 처리합니다. 배차 로직은 모든 고객사가 같은 코드를 쓰고, 권역·적재한도·요율처럼 회사마다 갈리는 값은 코드가 아니라 설정 데이터로 분리했습니다.
- 337영업일 실주문으로 현행 운영을 재현
- 2,384,009건 재현에 투입한 주문
- 1,074,692건 계산한 정차(배송지)
- 113 → 73대 엔진이 산출한 고정차 (−35.4%)
실주문 기반 To-Be 배차 시뮬레이션 · 기준일 2026-07-31. As-Is 113대는 전용 고정차 53대와 공동배송망 이관 60대의 합이며, To-Be 73대는 외부 이관 없이 전량 자차로 흡수한 결과입니다.
현장에서 반복되는 문제
차는 남는데, 물량은 밖으로 나간다
배차를 못 해서가 아닙니다. 무엇을 기준으로 배차했는지가 시스템 밖에 있어서입니다. 기준이 사람 머릿속에 있으면 검증도, 비교도, 인수인계도 되지 않습니다.
회사마다 한도가 다르다
차량당 박스·중량·운행시간 상한이 제각각이라, 같은 자로 재서 비교할 수가 없습니다.
요율이 흩어져 있다
대수는 세어도 금액 비교가 안 됩니다. 곱해야 할 단가가 엑셀과 계약서에 흩어져 있습니다.
남는 물량은 매일 외부로
고정차가 다 싣지 못한 분량이 공동배송망으로 빠집니다. 그만큼 운임은 밖에서 결정됩니다.
RunTMS 의 접근
기준을 사람에게서 꺼내 설정값으로 옮깁니다
세 단계에는 순서가 있습니다. 재현이 안 되면 파라미터의 옳고 그름을 판정할 수 없습니다.
-
1
실적을 그대로 재현한다
지난 영업일의 실주문으로 현행 운영을 다시 만듭니다. 같은 날, 같은 물량입니다. 여기서 맞지 않으면 다음 단계로 가지 않습니다.
- 투입 주문
- 2,384,009건
- 계산 정차
- 1,074,692건
-
2
룰을 파라미터로 꺼낸다
차량당 박스·중량·거리·운행시간·하역시간·속도·도로계수를 코드에서 분리해 설정값으로 둡니다. 값은 고객사가 정합니다. 시스템이 실측으로 학습해 덮어쓰지 않습니다.
- 엔진 파라미터
- 약 70개
- 소유 주체
- 고객사
-
3
실도로로 검증한다
직선거리가 아니라 실제 도로 경로와 ETA 로 계산하고, 산출된 배차안이 규칙을 어기지 않는지 매번 다시 검사합니다.
- 도로 행렬
- 726,528행
- 불변식 위반
- 0건
불변식 검사
엔진이 낸 배차안을 규칙에 다시 대조합니다. 통과하지 못하면 내보내지 않습니다.
“엔진이 틀릴 수 있다”는 전제로 만든 장치입니다. 파라미터가 회사마다 달라져도 이 검사는 공통으로 돕니다.
- 입력된 정차가 결과에서 사라지지 않는다
- 한 착지는 한 차량에만 배정된다
- 박스·중량·거리·운행시간 상한을 넘지 않는다
- 고정차 + 용차 합계가 총 대수와 일치한다
- 차량별 정차 순번이 끊기거나 겹치지 않는다
프로세스 골격
순서는 고정, 조합은 자유
모든 고객사가 같은 파이프라인을 지납니다. 바뀌는 것은 어떤 태스크를 켜느냐입니다. 업종과 운영 방식이 달라도 주문은 반드시 접수에서 실적 분석까지 같은 순서로 흐릅니다.
P1주문 접수수기 · API · 파일 일괄 · 오류 보정
P2배차 계획·확정자동 최적화 · 배차안 비교 · 권역 설계
P3운송 수행상차 · 상태 전이 · 다음 정차 안내
P4인수·증빙서명 · 인수 사진 · 이상/반품
P5운임 정산·청구자동 산정 · 마감 · 세금계산서
P6실적 분석물량 · 비용 · 정시율 · 권역 효율
병행 프로세스
파이프라인 특정 구간에 붙어 동시에 돕니다.
- 실시간 관제·추적
- 고객 배송 트래킹
- 고객 알림(알림톡·푸시)
- 콜드체인 온도 관리
- 사고·클레임
- 용차·협력사 배정
- 운행 법규 준수
기반 프로세스
파이프라인 진입 전에 갖춰지는 상시 기능입니다.
- 접근·인증
- 연계 채널 관리
- 기준정보(거래처·차량·기사·권역)
- 조직·권한·감사로그
- 배차 정책·요율
- 보안·백업
주요 기능
관제실과 운전석이 같은 데이터를 봅니다
주문 수집
수기 등록, 표준 양식 일괄 업로드, 파트너 API 수신을 한 입구로 모읍니다. 멱등 처리로 중복 접수를 막고, 실패 건은 오류 주문으로 분리해 보정 후 승격합니다.
자동 배차 최적화
적재·거리·시간 제약 아래 경로와 묶음을 계산합니다. 배차안 여러 개를 거리·적재율·정차 수로 비교하고, 디스패처가 기사 간 재배치를 직접 편집할 수 있습니다.
권역 설계
행정동 경계 3,558개를 입력으로 인접 동을 묶어 겹침 없는 권역 외곽선을 만듭니다. 요일별 적정 차량 수와 비효율 권역을 리포트로 되돌려 줍니다.
실시간 관제
지도 위에서 차량 위치와 정차 진행을 봅니다. 지연 임계값을 넘으면 권역·기사별로 집계해 알리고, 앱 장애 시에는 관제가 상태를 대신 전이시킬 수 있습니다.
인수 증빙(POD)
전자 서명과 인수 사진을 촬영 위치·시각과 함께 보관합니다. 인수 이상이 등록되면 정상 완료를 막고 관제로 올립니다.
운임 정산
계약 주체 5종 × 요율 10종 × 효력기간으로 운임을 산정합니다. 단가는 고객사가 입력하며 시스템이 만들어내지 않습니다.
고객 트래킹·알림
주문 접수부터 배송 완료까지 단계별 상태를 고객에게 노출합니다. 알림톡·푸시 발송 정책은 빈도까지 고객사가 정합니다.
실적 리포트
물량·비용·정시율·자원을 거래처·권역·기사·차량별로 집계합니다. 조건을 걸어 파일로 추출합니다.
연계 채널
WMS·CS 등 외부 시스템과 API·EDI·SFTP 로 주고받습니다. 필드 매핑과 연계 이력을 화면에서 관리합니다.
아키텍처
중간 레이어 — 회사별 차이가 모이는 곳
엔진 코드는 그대로 둡니다. 회사마다 바뀌는 값만 데이터로 넣습니다. 그래서 회사가 달라도 스키마는 같습니다.
테넌트 구성 레이어
회사별 차이는 전부 여기에만 있습니다 — 코드가 아니라 데이터입니다
권역 정의행정동 묶음 · 외곽선 합성
엔진 파라미터박스 · 중량 · 거리 · 시간 · 속도 · 도로계수
요율 체계계약 주체 5종 × 요율 10종 × 효력기간
운영 정책배차 가중치 · 알림 임계값 · 권한
공통 배차 엔진
모든 고객사가 같은 코드를 씁니다
룰 가중치는 고객사가 정한다
속도·하역시간·도로계수는 고객사 값입니다. 시스템이 실측으로 학습해 덮어쓰지 않고, 실측은 사후 조정 근거로만 씁니다.
테넌트 단위로 격리한다
업무 API 는 테넌트 경로 아래에서만 동작합니다. 서버가 검증한 테넌트 문맥과 권한을 쓰고, 클라이언트가 보낸 소속 정보를 그대로 믿지 않습니다.
운영·분석 데이터를 분리한다
분석 데이터는 언제든 재생성합니다. 계약·요율처럼 사람이 입력한 원본은 재생성할 수 없어 따로 보관합니다.
기사용 배송 앱
배차 확인부터 배송 완료까지
현장에서 기사가 직접 상태를 올리는 것이 정상 경로입니다. 앱이 멈춰도 업무가 멈추지 않도록, 관제가 대신 처리하는 예외 경로를 같이 둡니다.
- 당일 배차 확인 — 상차 계획과 배송 역순 순서까지 한 화면에서
- 상태 셀프 갱신 — 출발 · 도착 · 완료를 기사가 직접 전이
- 인수 증빙 — 서명과 사진을 촬영 위치·시각과 함께 저장
- 오프라인 대기열 — 통신이 끊겨도 단말에 쌓았다가 복구되면 전송
- 위치 기록 — 백그라운드 위치 수집으로 관제 지도에 반영
- 상황 보고 — 지연·사고를 사진과 함께 올리면 관제로 접수
Android · iOS 네이티브 앱과 웹 버전을 함께 제공합니다. 오프라인 대기열과 백그라운드 위치 기록은 휴대폰 앱에서 동작합니다.
요금
차량 대수가 아니라 정차 건수로 받습니다
제품의 핵심 가치가 고정차 적정 대수 산출입니다. 차량당 과금이면 우리가 잘할수록 매출이 줄어, 제안서의 절감 논리와 계약서의 과금 논리가 정면으로 어긋납니다. 정차 기준이면 물량이 늘 때 매출이 늘고, 차량을 줄여줘도 매출은 유지됩니다.
플랫폼 기본료
고정
화면 · 계정 · 마스터 · 배차 엔진 · 리포트와 테넌트 유지.
정차 사용료
변동
정차(배송지) 건수 구간별 체감 단가. 물량에 비례합니다.
외부 서비스 실비
통과
길찾기 API · 알림톡은 마진 없이 원가로 넘기고 관리수수료만 받습니다.
단가는 물량과 거점 수에 따라 달라집니다
하루 정차 건수와 거점 수를 알려주시면 구간 단가를 적용한 월 예상 금액을 정리해 드립니다. 초기 구축(SI)은 범위에 따라 별도 산정하며 구독료에 포함하지 않습니다.
요금 문의하기솔직하게
지금 되는 것과, 아직 만드는 것
화면이 있다는 것과 기능이 끝났다는 것은 다릅니다. 도입 검토에 필요한 구분을 먼저 드립니다.
동작 중
- 주문 · 배차 · 기사 배송 · 사진 · 정산 · 관제 · 알림 · 설정 · 연계 업무 API
- 관제 콘솔과 Flutter 기사앱의 실제 인증 · 실 API 연동
- 테넌트 격리와 권한 검증, 감사 로그
- 337영업일 실주문 기반 배차 엔진 검증과 불변식 검사
구축 예정
- 다이나믹 ETA 예측 모델 — 초기에는 경로 ETA 와 배송 순서 근사로 단계 도입
- 콜드체인 센서 수집과 온도 이탈 알림
- 사고 · 클레임 워크플로우
- 운행 법규 준수 — DTG · 근로시간 · 과적
- 도로 엔진 운영 데이터 투입
도입 범위는 태스크 조합으로 정합니다. 어떤 태스크가 필요한지부터 같이 정리해 드립니다.
운영 기준을 시스템 안으로 옮길 준비가 되셨나요?
보유 차량, 하루 정차 건수, 현재 배차 방식 세 가지만 알려주시면 어느 태스크부터 켜야 하는지 정리해 드립니다.
문의 주시면 영업일 기준 1일 이내에 회신드립니다.