Route API와 TMS는 어떻게 다른가 — 조회형 vs 실행형

“경로 최적화 API가 있는데 굳이 TMS가 필요한가?”라는 질문을 자주 받습니다. 결론부터 말하면, 둘은 같은 일을 하지 않습니다. 같은 ‘경로’라는 단어를 쓸 뿐, 해결하는 문제의 범위가 다릅니다.

같은 ‘경로’라는 단어, 다른 문제

조회형은 ‘가장 짧은 길’을 계산합니다. 실행형은 ‘이 기사가, 이 차량으로, 이 시간창과 권역 안에서 실제로 돌 수 있는 배차’를 만듭니다. 전자는 길 안내에 가깝고, 후자는 운영 계획 수립에 가깝습니다.

Route API는 거리·시간·경로를 계산해 알려줍니다. 빠르고 유용하지만, 그 경계가 분명합니다.

그림 1. 조회형은 경로를 계산할 뿐, 배차·제약·관제·증빙은 다루지 않는다.

실행형 TMS는 경로 계산 위에 운영을 얹습니다. 두 범주를 나란히 보면 차이가 분명합니다.

선택은 단순합니다. 단순한 경로 안내가 필요하거나 자사 시스템에 부품으로 넣을 기능이 필요하면 조회형(API)이 맞습니다. 복잡한 제약의 다거점 운영을 실제로 굴려야 하면 실행형(TMS)이 맞습니다. 둘은 대체재가 아니라 용도가 다른 도구입니다.

SEECARGO는 조회를 넘어 실행되는 운영을 지향합니다.

그림 2. 실행형 TMS는 경로 계산 위에 배차·관제·증빙을 쌓는다.

실행형 TMS — 20여 개 현장 제약을 반영한 배차부터 실시간 관제, POD, ESG 리포트까지 하나로 잇습니다.
엔진 API도 제공 — 자사 플랫폼이 있다면 배차 최적화 엔진만 API로 가져다 쓸 수도 있습니다. 즉 ‘완성된 운영’이 필요하면 TMS, ‘부품’이 필요하면 엔진 API라는 두 길을 모두 엽니다.

“경로가 나온다”와 “운영이 돌아간다”는 다릅니다. 우리에게 필요한 것이 길 안내인지, 매일 굴러가는 운영인지를 먼저 정하면 선택이 쉬워집니다.

자주 묻는 질문

경로 최적화 API만 붙이면 배차도 되는 것 아닌가요?

되지 않습니다. API는 보통 정해진 지점들의 빠른 순서나 두 점 사이 경로를 계산합니다. '여러 차량·기사에 일을 나눠 배정하고, 시간창·적재·권역 제약을 동시에 지키는' 배차는 별개의 최적화 문제라, API를 엮는 것만으로는 풀리지 않습니다.

TMS 안에도 경로 계산이 들어 있나요?

네. 실행형 TMS는 내부에 경로·거리 계산 엔진을 두고, 그 위에서 제약을 반영한 배차를 만듭니다. 즉 조회형의 기능을 품은 더 넓은 범주입니다.

우리는 개발팀이 있는데, 부품처럼 가져다 쓰면 안 되나요?

가능합니다. 자사 플랫폼이 있다면 배차 최적화 엔진을 API로 호출해 부품처럼 쓸 수 있습니다. 직접 운영 화면까지 필요하면 TMS, 기능만 필요하면 엔진 API라는 선택지가 있습니다.

조회형이 더 싸지 않나요?

단가만 보면 그럴 수 있지만, 해결 범위가 다릅니다. 조회형으로 다차량 제약 배차·관제·증빙을 대체하려면 결국 그 위에 많은 것을 직접 만들어야 합니다. 비용은 '같은 일을 했을 때'로 비교해야 합니다.