TMS 프로젝트를 마치고

0. 들어가며

 

 

TMS

안녕하세요.

지금부터 5개월간 준비하고 게시한 TMS서비스를 소개하려 합니다.

저희 회사 풀필먼트 개발팀이 고민하고 설계한 내용들의 설명이며 프로젝트를 끝내고 돌아보며 회고하기 위해서 작성한 글입니다.

 

1. 프로젝트 설명
2. 문제 해결
3. 마무리

 

1. 프로젝트 설명

---

 

 TMS란?

저희 회사는 새벽 배송을 통해 신선한 상품들을 가게에 공급하고 있습니다.
고객의 상품들이 어떤 루트로 배송되는지와 어느 기사가 배송하는지를 관리하는 것이 TMS(Transportation Management System)입니다.

추가적으로 기사관리,  각종 지표 제공등의 기능을 하며 물류 및 배송 전 과정을 담당하고 있습니다.

 

 
 

기존에는?

회사에는 이미 TMS를 사용하고 있었습니다.
하지만 성장하는 회사의 요구사항을 따라가지 못하였고 작업자 의존도가 높은 시스템이 되어가고 있었습니다.

저희 팀은 확장성과 효율성을 가지는 새로운 시스템을 구축하고자 했습니다.
 

이전 시스템과 비교하여 개선된 점은 다음과 같습니다.

 
분배 최적화의 문제

TMS에서의 분배란 기사에게 배송을 할당하는 것을 말합니다.

이전 시스템에서는 작업자가 주문 업체의 주소를 확인해 해당 구역을 담당하는 기사에게 수동으로 배정했습니다.

과거 주문 내역이 있는 업체는 이전에 설정된 기사에게 배정되었지만 신규 업체의 경우는 작업자가 매번 기사를 새로 배정해야 했습니다.

이는 작업자 의존도가 높은 작업이며 신규 업체가 많은 날에는 작업자의 리소스를 많이 사용하게 됩니다.

 

배송 최적화의 문제

배송 최적화란 기사가 방문하는 업체의 순서를 정하는 것을 말합니다.

배송 순서 또한 운영자가 수작업으로 조정해야 했습니다. 운영자의 판단에 따라 이뤄지며, 작업자 의존도가 높은 작업입니다. 

분배최적화와 마찬가지로 신규업체가 많은 날과 주문업체가 많은 날은 출고 시간이 지연되는 문제가 발생했습니다.

 

 

 

 

2. 문제 해결

---

분배 최적화

설명을 위해 사용되는 이미지들은 카카오 모빌리티를 참고했습니다.

 

밑의 그림은 포인트 하나가 배송지라고 생각하시면 됩니다.

배송 포인트

 

 

포인트들을 기사가 담당할 수 있게 배송 구역을 나누는 절차가 필요합니다.

분배방법으로 널리 알려진 두 가지 방법이 있습니다. 전역 최적화와 권역 기법 최적화입니다.

 

 

전역 최적화

전역 최적화란 전체적으로 포인트들을 근처의 포인트들과 묶어 배송 구역으로 만드는 방식입니다.

장점은 전체적인 배송을 보고 구역을 짜기 때문에 높은 배송 효율이 있습니다.

단점은 기사가 고정된 구역을 담당하는 것이 아니기에 매일 새로운 포인트를 가는 경우가 있습니다.

전역 최적화

 

권역 기법 최적화

권역 기법 최적화란 권역을 담당하는 기사가 존재하는 것입니다.

장점은 기사가 과거에 방문했었던 포인트에 방문하게 됩니다.

단점은 전체적인 효율이 떨어집니다.

권역 최적화

 

 

 

전역 최적화가 좋아 보이지만 현장에서는 여러 제약 사항이 존재합니다.
이미 각 권역에는 담당 기사가 존재하고, 각자의 숙련도가 존재합니다.
차량 주차 및 빠른 배송을 위한 입구, 입장이 어려운 지하상가등 나름의 숙련도가 있는 것입니다.

 

현장에서는 매번 새로운 포인트를 방문하는 것에 거부감이 있었기에 전역최적화의 효율을 포기하고 권역 기법의 최적화로 진행하게 되었습니다.

 

권역을 나누는 방법으로는 우편번호를 사용했습니다. 정부에서 조직화한 우편번호를 통해서 충분히 그룹핑할 수 있었습니다.

우편번호는 배송 구역의 최소단위로 설정하고 해당 배송 구역을 기사가 담당하는 구조입니다.

권역에 해당하는 우편번호를 설정하는 화면의 경우 클라이언트에서 많은 폴리곤을 그리기 때문에 작업자가 보고 있는 부분만 그리는 레이지로딩 기법을 활용했습니다.

우편번호 설정화면

 

 

고려사항

권역 기법 최적화 시에 한 가지 고려해야 할 것이 있습니다.

고객 이벤트나 명절이 있는 경우 배송이 권역의 할당량을 초과하는 경우가 있습니다.

이를 적절하게 주변 권역의 기사에게 나눠줘야 합니다. 

저희는 이것을 "배송이동"이라고 부르기로 했습니다.

 

먼저 배송 이동의 목표는 2가지였습니다.

한 곳에 몰린 포인트를 주변으로 적절히 분배할 것

분배를 하되 기사의 이동거리가 비이상적으로 늘지 않을 것 

 

저희 2가지 목표를 바탕으로 계획과 설계를 하게 되었습니다.

 

 

 

가운데 보라색 권역의 할당량이 포인트 3개인 경우 나머지 3개를 주변 권역의 기사에게 나눠줘야 합니다.

 

가장 왼쪽의 포인트를 예시로 보면 노란색 기사와 하늘색 기사에게 나눠줄 수 있습니다.

노란색 기사에게 할당하게 되면 하늘색 기사가 할당했을 때보다 상대적으로 이동거리가 증가하게 됩니다.

그렇기에 하늘색 기사님이 할당하는 것이 전체적인 효율을 늘릴 수 있습니다.

 

주변 권역 또한 할당량이 초과했을 경우

하지만 주변 권역 또한 할당량이 초과되었다면 포인트를 넘겨받을 수 없는 상황이 됩니다.

포인트들이 이동하지 못하는 상황이 되기에 저희는 초과되는 포인트를 다른 권역으로 넘기기 위한 몇 가지 조건을 추가했습니다.

처음 이동 시 타켓 권역이 소화할 수 있는 양보다 많은 포인트를 넘겨주고 거기서 다시 한번 주변 권역으로의 이동을 하게 하는 것입니다.

 

해당 방식의 유효성을 확인하기 위해 배송이 많았던 날, 적었던 날 등의 데이터를 통해 유효성을 검증했고 현장에 도입하게 되었습니다.

현장에서는 초과되는 배송이 많을 때의 작업량이 줄었으며 이를 통해 고객에게 더 빨리 물건을 가져다줄 수 있게 되었습니다.

 

 

 2번째 이동했을 경우에 주변이 모두 초과라면 이동되지 않지만 그럴 경우는 회사의 주문량이 증가했다는 것이고 권역을 좀 더 세분화하여 기사를 증가시켜야 합니다.   

 

이외에도 몇 가지 아이디어들이 있었습니다.

재귀 형식으로 계속해서 포인트를 이동시킨다, 기사의 이동거리를 기반으로 배송을 이동시킨다.

등의 의견이 있었지만 모두 테스트를 통해 일정하게 평균값이 나오는 지금의 방법으로 하게 되었습니다.
 

배송 최적화

 

배송의 순서를 정하는 방법은 대부분 다익스트라 알고리즘을 사용할 것으로 예상됩니다.

https://ko.wikipedia.org

 

저희가 가지고 있는 데이터 중 사용할 수 있는 가중치는 직선거리뿐입니다. 직선거리 기반의 배송 최적화는 산을 뛰어넘고 지형을 고려하지 않기 때문에 적절하지 않습니다.

저희는 배송 지역의 특성에 따라 최적화된 배송 경로를 추천해 주는 외부 API를 활용하기로 결정했습니다. TMap, SKTms과 같은 솔루션을 사용하여 거리 정보 등을 바탕으로 최적의 배송 경로를 제공합니다.

이러한 외부 솔루션을 활용하여 보다 효율적인 배송 시스템을 구축하였습니다.

 

 

하지만 외부 API가 장애를 낼 경우 저희 쪽에서는 배차를 진행하지 못할 수 있습니다.
이를 위해 사용자가 수동으로도 배차를 진행할 수 있도록 조치도 해두었습니다.

 

 

 

3. 마무리

프로젝트를 끝내고 느낀 점을 간단히 말하자면,

기술적으로는 백엔드와 프론트엔드를 모두 경험할 수 있어서 매우 유익한 경험이었습니다. 

프론트엔드의 개발 방식을 조금이나마 이해할 수 있게 되었습니다.

발생한 오류를 해결하는 과정에서도 많은 것을 배울 수 있었습니다. 오류에 관해서는 다음 글로 써보도록 하겠습니다.

 

외적으로는 프로젝트 결과물이 현장에서 좋은 반응에 뿌듯하기도 했고, 작업의 속도의 개선과 누구든지 배차를 할 수 있게 되어 회사에 좋은 영향력을 끼쳤다고  생각합니다.

개발자로서 피드백을 받는 환경이 업무에 더 애착을 같게하는 것 같아 좋은 경험이었습니다.