Design Tesla Robotaxi Fleet Manager, 가까운 차량을 찾는 문제가 아니라 무인 차량 fleet을 운영하는 시스템
승객은 “차량 호출” 버튼 하나를 누르지만, 내부에서는 수요 예측, 차량 상태, 배터리, 충전 슬롯, 위치 보정, 원격 명령, 규제 구역이 동시 계산
Introduction & Requirements
아래 설계는 Tesla Robotaxi의 공개 문서, Tesla Fleet API 문서, 공개 특허 문헌, 그리고 공개 보도에서 확인 가능한 제품 특성을 바탕으로 최대한 실제 시스템 디자인 특징을 반영한 시스템 디자인 가정입니다.
Tesla는 Robotaxi 네트워크를 자율 차량 fleet으로 설명해 왔습니다. Tesla Fleet API 문서는 차량 상태를 주기적으로 조회하는 대신 차량이 직접 서버로 데이터를 stream하는 Fleet Telemetry 방식을 제공합니다.
이 방식은 불필요한 vehicle wake와 배터리 소모를 줄이기 위한 구조입니다. 또한 Fleet Telemetry 문서는 차량 데이터가 500ms 단위로 전송될 수 있고, 특정 signal은 측정할 수 없는 상태에서 invalid로 표시될 수 있다고 설명합니다.
이 두 가지는 Robotaxi Fleet Manager 설계에서 바로 운영 제약이 됩니다. 차량을 계속 깨워서 상태를 긁어오면 배차 정확도는 좋아 보일 수 있습니다. 하지만 배터리와 연결 비용이 계속 압박받게 됩니다. 그래서 fleet 운영 시스템은 “항상 최신 상태를 polling한다”가 아니라 “차량이 보내는 telemetry stream을 받아 최신 snapshot을 유지한다”는 방향으로 설계해야 합니다.
처음 이 문제를 보면 단순한 ride matching처럼 보일 수 있습니다.
“승객이 출발지와 목적지를 보내면, 가까운 차량 하나를 찾아서 배정하면 되지 않을까요?”
차량 100대가 있고, 도심 하나에서만 운행하고, 모든 차량이 항상 온라인이고, 배터리도 충분하고, 충전소도 비어 있고, 차량 실내 상태도 항상 좋다면 가까운 차량 배정으로 시작할 수 있습니다. 하지만 운전자가 없는 fleet에서는 가까운 차량이 항상 좋은 차량은 아닙니다.
가까운 차량이 배터리 12퍼센트일 수 있습니다. 다음 충전 슬롯이 없을 수 있습니다. 이전 승객 하차 후 실내 검사가 끝나지 않았을 수 있습니다. 현재 위치 신뢰도가 낮을 수 있습니다. 해당 지역에서 규제상 운행이 제한될 수도 있습니다. 그래서 Robotaxi 배차는 “가장 가까운 차량 찾기”가 아니라 “이 ride를 끝까지 안정적으로 완료할 수 있는 차량 찾기”가 됩니다.
“우리가 설계하는 것은 단순 ride matching인가요, 아니면 차량 위치, 배터리, 충전소, 원격 명령, cabin readiness, 규제 구역을 동시에 보는 autonomous fleet operating system인가요?”
이 질문 하나로 저장소와 파이프라인이 바뀌게 됩니다. 단순 ride matching이라면 rides table에서 nearest vehicle을 찾으면 됩니다. 하지만 Robotaxi에서는 차량이 승객에게 가기 전에 이미 자율주행 가능 상태인지, 실내가 다음 승객에게 제공 가능한 상태인지, 충전 계획이 다음 몇 건의 ride 이후에도 가능한지, 차량 명령이 실제로 전달 가능한지 확인해야 합니다.
Tesla Fleet API 문서는 vehicle command가 virtual key와 signed command 처리를 전제로 한다고 설명합니다. 그리고 차량이 online이라고 해서 command 성공이 곧바로 보장되는 것도 아닙니다. 그래서 원격 명령 경로는 일반 상태 조회 경로와 분리되어야 합니다. 승객 앱에는 “차량 배정됨”과 “차량이 명령을 실제로 ack함”을 같은 상태로 보여주면 안 됩니다.
차량 위치도 GPS 좌표 하나로 믿으면 안 됩니다. Robotaxi 배차에서 위치는 곧 비용입니다. 차량이 승객에게 2분 거리라고 계산했는데 실제로는 도로 반대편, 지하 주차장 입구, 접근 불가 차선에 있으면 픽업 실패가 생길 수 있습니다.
Tesla의 “Technologies for vehicle positioning” 공개 특허는 차량들이 map pose와 raw positioning measurement를 공유하고, 서버가 이를 통해 map-relative localization을 보정하는 아이디어를 설명합니다.
이 아이디어를 시스템 디자인에 반영하면, Fleet Manager는 단순 위치 저장소가 아니라 fleet positioning correction service를 가져야 합니다. 차량 위치에는 좌표뿐 아니라 confidence, correction version, stale 여부가 함께 붙어야 합니다.
승객의 현재 위치를 그대로 픽업 지점으로 쓰는 것도 충분하지 않습니다. 승객이 서 있는 위치와 차량이 안전하게 정차할 수 있는 지점은 다를 수 있습니다.
Tesla의 “Autonomous and user controlled vehicle summon to a target” 공개 특허는 사용자가 지도에서 목표 지점을 선택하고, 목적지가 충전소인 경우 차량이 충전 포트와 충전기를 맞추도록 orientation을 잡을 수 있다고 설명하고 있습니다.
이 아이디어는 Robotaxi Fleet Manager에서 두 가지 흐름으로 바뀌게 됩니다. 승객 위치와 실제 승차 지점을 분리하는 pickup rendezvous planner가 필요합니다. 또한 충전소 접근 시 차량 자세와 충전기 정렬을 고려하는 charging alignment planner도 필요합니다.
배터리가 낮은 차량을 그냥 가장 가까운 충전소로 보내는 것도 좋은 설계가 아닙니다. 가까운 충전소가 답처럼 보일 수 있지만, fleet 단위에서는 충전소가 공급 제약이 됩니다. 충전소가 이미 예약되어 있거나, 해당 충전소까지 이동하면 다음 피크 시간대 수요 지역에서 차량이 빠져나가거나, 충전 후 청소와 정비 슬롯이 필요할 수 있습니다.
자동 충전 관련 공개 특허 문헌은 이미지 기반으로 차량 정보를 식별하고, 데이터베이스에서 충전 포트 위치를 찾아 robotic arm이 충전 커넥터를 연결하는 방식을 설명합니다. 또 다른 특허 문헌은 목적지가 충전소일 때 차량이 충전 포트와 charger가 맞도록 orientation을 조정할 수 있다고 설명합니다. 이 내용을 시스템 디자인에 반영하면 충전은 “차량을 충전소로 보내기”가 아니라 charging slot reservation, vehicle alignment, charging command, charging state stream, failure recovery가 묶인 workflow가 됩니다.
승객이 내린 차량을 바로 다음 승객에게 보내도 되는지도 확인해야 합니다. 무인 ride-hailing에서는 차량 실내 상태가 fleet 처리량을 직접 압박하게 됩니다. 공개 특허 문헌 “Controlling environmental conditions in enclosed spaces”는 여러 사람이 공유하는 차량 cabin 같은 enclosed space를 대상으로 sensor data를 바탕으로 sanitation routine을 생성하는 흐름을 설명합니다.
이 내용을 시스템 디자인에 반영하면 Fleet Manager는 ride completion 직후 차량을 바로 배차하지 않습니다. cabin sensor 상태, cleaning requirement, service bay availability, passenger report를 보고 cabin readiness state를 갱신해야 합니다. 실내 상태가 불확실하면 배차 후보에서 보수적으로 제외하는 편이 안전하다고 할 수 있습니다.
Functional Requirements
승객은 출발지, 목적지, 탑승 인원, 접근성 요구, 픽업 시간 조건을 기반으로 Robotaxi ride request를 생성할 수 있어야 합니다.
Fleet Manager는 차량 위치, 배터리, cabin readiness, 충전 계획, 규제 구역, 차량 명령 가능 상태를 바탕으로 차량을 배정할 수 있어야 합니다.
시스템은 차량 telemetry stream을 받아 위치, 충전 상태, 차량 readiness, connectivity, invalid signal을 빠르게 반영할 수 있어야 합니다.
시스템은 차량을 픽업 지점, 하차 지점, 충전소, 정비 지점, 청소 지점으로 보내는 원격 명령 workflow를 관리할 수 있어야 합니다.
시스템은 약한 네트워크와 차량 offline 상태에서도 마지막 명령 상태와 ride 상태를 복구하고, 중복 배차와 중복 명령을 막을 수 있어야 합니다.
Non-Functional Requirements
ride request 접수 ACK는 p95 100ms 이내를 목표로 둡니다. 첫 배차 후보는 p95 500ms 이내, 차량 배정 확정은 p95 2초 이내를 목표로 둘 수 있습니다.
차량 telemetry 지연이나 충전소 예약 지연이 승객 요청 접수와 ride 상태 조회 경로를 같이 밀지 않게 해야 합니다.
차량 원격 명령, ride assignment, charging assignment, cabin readiness override, regulatory hold는 변경 이력과 idempotency_key를 남길 수 있어야 합니다.