현대자동차그룹의 ‘셔클’에 대해서 들어본 적 있으신가요? 셔클은 수요응답형 모빌리티 서비스 플랫폼으로 현대자동차의 인공지능 기술 전담 조직인 에어스 컴퍼니(AIRS Company)가 2019년에 선보인 국내 첫 라이드 풀링(Ride Pooling) 서비스입니다.
셔클은 고정 경로형 대중교통과 달리, 차량이 모든 정류장에 정차하지 않고 필요한 정류장에만 정차하는 지능형 모빌리티 서비스입니다. 비용이 높은 택시와 모든 정류장에서 멈춰서는 버스의 단점을 보완한 이동 수단이죠. 셔클은 승객이 앱을 통해 차량을 호출하면 실시간으로 경로를 생성해 경로가 유사한 승객을 함께 태워 이동하기 때문에 근거리 위주의 실생활 이동에 있어 굉장히 유용한 서비스로 자리매김하고 있습니다.
* 연관 기사: 정식 서비스를 시작한 국내 최초의 AI 알고리즘 라이드 풀링 ‘셔클’
안녕하세요, 현대차 셔클 서비스를 개발 중인 AIRS Company의 주영현 기술리더입니다. 셔클 서비스의 개발 환경은 다른 IT 기업과는 달리 소수의 인원, 즉 ‘제로베이스’에서 시작했는데요, 셔클 서비스의 개발 경험을 바탕으로 ‘라이드 풀링 서비스’ 개발에 대해 자세히 설명하겠습니다.
셔클의 아키텍처
셔클 서비스의 개발에는 소수의 인원이 투입되었습니다. 따라서 개발 효율성을 최우선으로 고려해야 했고, 접근이 쉬운 모놀리식(Monolithic) 아키텍처로 서버 개발을 시작했습니다. 하지만 모놀리식 아키텍처는 복잡한 기능을 수행해야 하는 셔클 서비스에 적합하지 않다는 것을 깨닫고, 마이크로서비스(Microservice) 아키텍처로 전환해 다시 시작했습니다.
모빌리티 서비스에는 비교적 많은 구성 요소들이 존재합니다. 아울러 셔클 서비스에는 호출 앱, 기사 앱, 관제 툴 등 다양한 사용자를 지원해야 했습니다. 따라서 각각의 작은 애플리케이션들이 하나의 단위기능을 담당하고, 이를 연계해 전체 서비스가 동작하는 마이크로서비스 아키텍처를 도입했습니다.
각 마이크로서비스들은 서로 API와 이벤트로 통신하고, 사용자별로 게이트웨이 서비스 메시업을 통해 기능을 제공하도록 구성되어 있습니다. 마이크로서비스 아키텍처에는 각 서비스가 하나의 기능을 담당하므로 서비스의 복잡도가 낮아지고, 기능 추가의 부담도 적습니다. 또한 각 서비스의 특성에 맞게 스케일 아웃 범위를 유연하게 조정할 수 있다는 것도 장점입니다. 셔클의 경우, CPU 연산이 많이 필요한 배차 서비스만 CPU 성능이 좋은 서버에 여러 인스턴스를 띄우는 방식으로 스케일 아웃*이 가능합니다. 마지막으로 특정 기능 문제가 전체 서비스 장애로 확장되지 않고 특정 서비스에 국한될 수 있으므로 안정성 확보 측면에서도 장점이 있습니다.
*스케일 아웃(Scale out): 접속된 서버의 대수를 늘려 처리 능력을 향상하는 것.
하지만 당연히 단점도 존재합니다. 개별 서비스의 복잡성은 낮아지지만 분산 시스템에 대한 관리가 필요하고, 늘어난 서비스로 인해 빌드와 배포가 어려워지며, 서비스 간 상태의 정합성도 문제 될 수 있습니다. 서로 다른 데이터베이스를 사용하므로 정합성이 어긋날 경우 트랜잭션(transaction)을 걸 수도 없습니다.
마이크로서비스 아키텍처를 활용하면서 마주하는 위와 같은 문제점들은 통합 IDL 저장소와 서비스별 인터페이스 코드 저장소를 구성하고, Transactional Outbox 방법을 적용함으로써 해결할 수 있었습니다.
셔클 서비스의 구성 요소
셔클 서비스의 구성 요소에서 가장 두드러진 특징은 운행의 주체를 운전기사가 아닌 시스템으로 설정하고 접근한다는 점입니다. 콜택시로 대표되는 전통적인 모빌리티 서비스의 경우, 서비스 요소 대다수가 운전기사에 의해 진행됩니다. 운행의 시작과 종료를 선택하고, 호출을 선택하고, 탑승자를 확인하는 것도 운전기사의 몫입니다. 이러한 방식은 유연한 운영이 가능한 반면 서비스의 품질이 운전기사의 선택에 의해 결정되므로 일관성을 갖기 어렵습니다.
셔클은 안정적인 서비스 품질을 제공하고 운행의 효율성을 높이기 위해 중앙 시스템이 운행을 제어하는 주체가 되도록 설정했습니다. 덕분에 차량은 정해진 스케줄대로 운행되며, 배차와 탑승 확인도 시스템을 통해 자동으로 이뤄집니다. 이외에도 시스템이 제어 주체가 되는 방식은 향후 자율주행이 상용화 되었을 때 자연스러운 전환이 가능하다는 장점이 있습니다. 실제로 저희가 세종시에서 실증한 자율주행 시범 서비스에서도 비상 운전자의 개입을 최소화한 채로 서비스 운행이 가능했습니다.
이처럼 저희 팀은 시스템이 운행의 주체가 된다는 방향성을 중심으로 셔클의 주요 기능을 설계하고, 개발했습니다. 승객 호출에 따른 최적화된 경로 생성, 배차된 차량과 승객이 만나 이뤄지는 승하차, 배정된 경로에 따라 진행되는 운행 등 총 3가지로 구분할 수 있습니다.
경로 생성 – 최적화 문제
셔클의 가장 큰 특징은 경로가 비슷한 승객의 이동을 돕는 라이드 풀링 서비스라는 점입니다. 새로운 승객의 호출이 발생했을 때 어떤 차량이 어떻게 경로를 변경할지 결정해야 합니다. 이를 위해서는 각 차량별로 새로운 승객을 태우고 내릴 때 변경되는 경로의 조합을 산출하고, cost 값을 적용해 최적의 경로를 선별해야 합니다.
실제 서비스가 이뤄지는 현실에서는 조금 더 확장된 개념으로 접근이 필요합니다. 기존 운행 경로의 변경만 고려할 경우 선택된 정거장의 위치에 따라 불필요한 우회 경로가 생성될 수 있기 때문입니다. 셔클이 합승 서비스임을 고려했을 때 이처럼 비효율적인 경로 생성은 기존 승객들에게 불편함을 초래할 수 있습니다.
위의 예시를 살펴보면, 신규 승객의 주변에는 탑승 가능한 위치 1, 2, 3이 있습니다. 2번 정류장을 출발지로 선택 시에는 운행 중인 차량에 비효율적인 경로가 생성됩니다. 이 경우 승객이 조금 더 걷더라도 1번 정류장에서 승차하는 것이 효율적인 경로 생성에 도움이 됩니다. 따라서 승객의 출발지와 목적지 주변 모든 정류장의 조합과 cost를 비교하여 최적의 승하차 정류장과 차량 경로를 선택하도록 개발했습니다.
경로의 품질 문제는 cost와 constraint 정의를 통해, constraint를 만족하면서 가장 적은 cost를 찾아내는 최적화된 방법으로 접근할 수 있습니다. 사용자 관점에서는 대기 시간, 이동 시간, 도보 시간, 그리고 합승으로 인한 우회가 중요한 요소가 될 수 있고, 운영자 입장에서는 차량의 운행 거리, 운행 시간 등이 좋은 경로를 위한 조건이 될 수 있습니다. 또한 도로의 너비, 교통상황, 주 고객층 등의 요소를 반영하기 위해 지역별로 경로 특성을 설정함으로써 서비스 품질을 높이고 있습니다.
승하차 여부 확인 – 할당 문제
처음 셔클 서비스를 공개할 때에는 운전기사가 직접 승객의 승하차를 확인하는 방식을 사용했습니다. 하지만 운전에 집중해야 할 운전기사가 승객의 승하차까지 확인하는 것은 큰 부담이었습니다. 따라서 셔클은 승객의 편의와 보다 효율적인 승하차 확인을 위해 지정좌석제를 도입했습니다. 현재 셔클은 각 좌석의 착석 여부의 판단을 통해 승객의 승하차 확인이 가능합니다.
착석 인식은 차량 내부에 설치된 카메라 비전을 통해 이뤄집니다. 촬영된 이미지에서 승객을 검출하고, 검출된 승객을 좌석과 대조하는 방법으로 착석 여부를 판단합니다. 승객이 좌석에 탑승한 이후엔 몸의 많은 부분이 가려지므로 얼굴 위치 검출에 특화된 CNN 모델 RetinaFace*를 활용했습니다. RetinaFace는 single-stage 모델*이라 임베디드 장치에서 수행하기에도 효율적입니다.
* J. Deng, et al., “RetinaFace: Single-shot multi-level face localisation in the wild,” in Proceedings of the IEEE Conference on Computer Vision and Pattern Recognition, 2020.
* single-stage 모델: 하나의 네트워크만으로 원하는 결과를 얻을 수 있도록 구성된 머신러닝 모델
좌석 할당은 오류를 최소화할 수 있는 방향으로 검출된 승객을 대상으로 진행됩니다. 셔클은 전통적인 헝가리안 알고리즘으로 좌석 할당 문제를 처리할 수 있고, 승객 검출 과정을 거쳐 최종적인 착석 인식 결과를 도출합니다. 비교적 단순하게 구현 가능한 구성 요소지만, 현실에서는 추가적인 고민이 필요했습니다. 착석 인식 과정에서 승객 개인 정보의 보안이 중요하기 때문입니다. 따라서 셔클은 차량에 내장된 NVIDIA Jetson Nano를 통해 이미지를 현장에서 바로 처리할 수 있도록 구현했으며, 이를 현재 셔클 서비스에서 활용하고 있습니다.
차량 운행 – 자원 할당 문제
차량 운행 요소에서 가장 먼저 고려해야 할 점은 운행 스케줄입니다. 서비스 품질 면에서 모든 차량을 서비스 시간 내내 운행하면 좋겠지만, 아직까지는 사람이 운전하기 때문에 인건비와 운행 비용, 그리고 휴식 시간도 고려할 필요가 있습니다. 이는 결국 운전기사라는 한정된 자원을 어떻게 배정할지 결정하는 자원 할당 문제로 접근할 수 있습니다.
셔클에서 운전기사의 자원 할당 문제는 사용자의 호출 수요를 최대한 만족시키는 스케줄을 생성하는 것으로 정의할 수 있습니다. 실제로 지역별, 요일별, 시간대별로 사용자 수요는 큰 차이를 보이고, 수요의 변화를 얼마나 잘 고려하여 스케줄을 작성하였는지가 서비스 품질에 큰 영향을 미칩니다. 또한 차량 고장, 운전기사의 근태 등 자원의 변동성도 고려해야 하므로 자동화가 중요한 항목입니다.
운전기사의 운행 스케줄이 확정되면 해당 스케줄대로 운행할 수 있도록 시스템이 보장해 줘야 합니다. 라이드 풀링 서비스의 특성상 운행 중에도 실시간으로 배차가 이뤄지므로 단순히 운행 종료 시각에 맞춰 배차를 중지하는 방법으로는 운행 시간을 지킬 수 없습니다. 이를 해결하기 위해 셔클은 경로 생성 시 차고지 복귀 시점을 고려해 데드라인 체크를 수행하고 있습니다. 운전기사의 휴식 시간 보장을 고려한 로직을 적용한 것입니다.
승객이 없는 경우의 운행 방법 또한 중요한 문제입니다. 단순히 호출이 있을 때부터 경로 설정이 된다면 수요가 적은 지역에 위치한 차량은 호출 지역으로 장거리를 운행해 승객 대기시간이 길어질 수 있기 때문입니다. 세종시의 평일 오전 7시 수요 분포를 살펴보면 좌측 주거지역에서의 호출이 많고, 우측 학교나 정부청사로의 이동이 많은 것을 확인할 수 있습니다. 이러한 경우 정부청사에서 하차를 완료한 빈 차량을 미리 주거지역으로 이동시켜 놓는다면 신규 호출에 빠르게 대응할 수 있습니다. 셔클은 수집된 수요 패턴을 기반으로 예상 수요에 비해 공급이 부족한 지역으로 미리 차량을 이동시킴으로써 사용자의 대기시간을 단축하고 있습니다.
통신자료를 분석한 결과를 살펴보면 대부분의 일상 속 이동 거리는 2~5km이고, 5km 이내의 이동이 전체 이동의 80% 정도를 차지합니다. 자가용 이용 시에는 주차와 교통혼잡을 고려해야 하고, 택시를 이용할 때에는 다소 비싼 요금과 단거리 이동 시 승차 거부 등의 문제가 부담스러울 수 있습니다. 또한 대중교통의 경우 고정된 노선으로 운행되므로 정류장까지의 이동, 환승 등의 비효율적인 이동을 감수해야 합니다.
생활권 내 이동의 불편함을 해소하는 새로운 모빌리티 서비스 셔클은 발전을 거듭해 세종시와 파주시에서 정식 서비스를 제공하고 있으며, 자율주행 기술과의 연계도 진행하고 있습니다. 하지만 더 나은 서비스를 위해 경로 최적화, 지역 간의 연계, 다양한 모빌리티와의 연동 등 아직 해결해야 할 과제가 많습니다. 따라서 우수한 개발자분들이 함께해 더 나은 서비스를 만들어가기를 희망합니다. 앞으로도 무한한 발전이 기대되는 셔클의 행보에 많은 관심 부탁드립니다.
HMG 저널 운영팀
group@hyundai.comHMG 저널에서 제공되는 정보는 크리에이티브 커먼즈(CCL) 2.0 정책에 따라 콘텐츠의 복제와 배포, 전송, 전시 및 공연 등에 활용할 수 있으며, 저작권에 의해 보호됩니다. 단, 정보 사용자는 HMG 저널에서 제공하는 정보를 개인 목적으로만 사용할 수 있습니다.
HMG 운영정책 알아보기