배차 시스템, 직접 만들까 사서 쓸까 — 자체 개발 전에 따져볼 것들

IT 조직이 있는 회사가 배차 문제를 만나면 자연스럽게 이 질문이 나옵니다. “우리가 만들면 안 되나?” 합리적인 질문입니다. 다만 이 질문의 답은 ‘만들 수 있는가’가 아니라 **‘무엇을 만들게 되는가’**를 정확히 알고 내려야 합니다.

갈래는 셋입니다

많은 회사가 두 갈래(만들기 vs 사기)로만 놓고 고민하는데, 실제로는 세 번째 갈래가 있습니다. 자사 플랫폼이나 기사 앱을 이미 갖고 있다면, 화면과 업무 흐름은 그대로 두고 가장 어려운 배차 계산만 API로 사 오는 방식입니다.

자체 개발에서 과소평가되기 쉬운 것

자체 개발 견적이 낙관적으로 나오는 이유는 대체로 하나입니다 — 눈에 보이는 부분(화면·관리 기능)으로 전체를 추정하기 때문입니다. 배차 시스템의 난이도는 눈에 안 보이는 곳에 있습니다.

1. 최적화 엔진의 난이도 — 배송지 수십 곳만 돼도 방문 순서의 경우의 수는 천문학적입니다. 여기에 시간창·냉장냉동·다회전·권역·근로시간 제약이 ‘동시에’ 걸립니다. 좋은 답을 짧은 시간에 내는 엔진은 논문이 아니라 현장 피드백으로 다듬어지는 영역이고, 그 축적에는 수년이 걸립니다.
2. 예외 처리의 현장성 — 물량이 넘치는 날 “배차 불가”를 띄우는 엔진은 개발 완료가 아닙니다. 과적·초과근무를 감수하고 일단 실행 가능한 답을 내는 처리까지 가야 현장에서 쓰입니다. 이 요구사항은 대부분 운영을 시작한 뒤에야 발견됩니다.
3. 끝나지 않는 유지보수 — 지도·교통 데이터 갱신, 현장 조건 변화, 담당 개발자 이직. 만든 순간부터 시스템은 유지보수 대상이 되고, 이 인건비는 구독료와 달리 줄지 않습니다.

참고로 SEECARGO 엔진의 20여 개 현장 제약 옵션은 14년간 현장에서 다듬어 온 결과물입니다. 같은 것을 처음부터 만드는 일과, 만들어진 것을 쓰는 일의 차이가 이 시간입니다.

판단 기준 — 두 가지 질문이면 갈립니다

1. 배차 알고리즘이 우리 회사의 차별점인가? — 그렇다면(그리고 전담 인력을 수년 유지할 수 있다면) 자체 개발이 정당화됩니다. 아니라면 만들 이유가 약합니다.
2. 자사 플랫폼·앱·WMS가 이미 있는가? — 있다면 엔진 API 연동이 자연스럽습니다. 없다면 SaaS 구독이 가장 빠르고 쌉니다.

SEECARGO는 세 갈래 중 둘을 제공합니다

• SaaS 구독 — 설치 없이 웹에서 바로. 엑셀 업로드로 시작하고, 공개 요금으로 규모에 맞게 씁니다. 월 배송지 1,000개까지는 무료입니다.
• 엔진 API·White Label — 자사 플랫폼에 배차 계산만 얹습니다. 14년 다듬어 온 엔진을 API로 연동하고, 필요하면 자사 브랜드로 제공(White Label)할 수도 있습니다.
• 낮은 위험의 전환 경로 — SaaS로 배차 품질을 먼저 검증하고, 자사 시스템이 갖춰지면 같은 엔진을 API로 전환하는 순서도 가능합니다. 처음부터 큰 결정을 내릴 필요가 없습니다.

‘만들까 사서 쓸까’는 자존심의 문제가 아니라 배분의 문제입니다. 우리 개발 인력은 우리 사업의 차별점에 쓰고, 이미 수년간 다듬어진 계산은 사 오는 것 — 대부분의 회사에서 총비용이 가장 낮은 답은 그 조합입니다.