이 글은 ‘가동 시간 방정식’의 2부입니다. 제1부에서는 에서는 차량 컨텍스트를 차량에서 직접 수집해야 하는 이유를 살펴보았습니다. 이번 편에서는 이를 수행하는 데 드는 비용을 살펴보겠습니다.
한 플랫폼 팀은 트럭의 후처리(배출가스 제어) 시스템에서 고장이 발생하기 몇 주 전에 이를 예측하는 모델을 보유하고 있습니다. 기술적인 문제는 해결되었습니다. 하지만 플랫폼 관련 문제는 아직 남아 있습니다. 바로 이 모델을 어디에서 실행할 것인가 하는 점입니다. 만약 이 모델이 트럭에 이미 장착된 게이트웨이나 텔레매틱스 컨트롤러에 탑재될 수 있다면, 기존 생산 라인을 통해 출하할 수 있습니다. 하지만 더 높은 성능을 갖춘 컨트롤러가 필요하다면, 다음 전기/전자(E/E) 아키텍처가 도입될 때까지 기다려야 하며, 이미 도로에 운행 중인 트럭에는 이 모델이 적용되지 않게 됩니다.
이는 새로운 데이터 활용 사례가 등장할 때마다 제기되는 질문이며, 상용차의 경우 그 해답에 담긴 경제적 측면이 승용차와 세 가지 측면에서 다릅니다.
트럭의 경우 왜 계산 방식이 다른가
판매량. 2025년 미국 내 클래스 8 트럭 소매 판매량은 2025년에 208,386대. 미국 내 경차 신차 판매량은 1,620만 대로, 약 78배에 달했습니다. 중형 트럭과 특수 목적 트럭을 포함하면 그 격차는 좁혀지지만 완전히 해소되지는 않습니다. 추가된 컴퓨팅 하드웨어에 투입된 1달러와 새로운 컨트롤러를 통합하고 검증하는 데 지출된 1달러는 극히 일부의 차량에만 분배됩니다.
수명. 미국 내 대형 트럭의 평균 12.1년 입니다. 또한 운송 업체들은 트럭을 더 오랫동안 운용하고 있습니다: ACT Research의 자료에 FleetOwner가 보도한 바에 따르면 에 따르면, 차량 관리 업체에서 운용 중인 클래스 8 트럭의 평균 운용 기간은 6.3년으로, 2013년 이후 가장 긴 수치를 기록했습니다. 성능이 향상된 게이트웨이, 텔레매틱스 장치, ECU와 같은 새로운 컴퓨팅 하드웨어는 신차 생산에만 도움이 될 뿐입니다. 기존 차량들은 출고 당시 장착된 하드웨어를 10년 이상 계속 사용하며, 가동 시간 가치 의 상당 부분은 바로 이 기존 차량 기반에 집중되어 있습니다.
아키텍처의 주기. 상용차의 E/E 아키텍처는 수년 주기로 갱신되며, 많은 컨트롤러는 OEM이 완전히 통제하지 못하는 공급업체에서 공급받습니다. 새로운 컴퓨팅 하드웨어와 관련된 사용 사례는 이러한 일정에 따라 결정됩니다.
이 세 가지 요소를 종합해 보면, 한 가지 질문에 대한 중요성이 더욱 커집니다. 바로 트럭에 필요한 지능 중 어느 정도는 새로운 하드웨어에서 확보해야 하고, 어느 정도는 기존 하드웨어를 더 효율적으로 활용함으로써 얻을 수 있는가 하는 점입니다. 차량 내 지능( AI)에 대한 비용을 충당하는 방법에는 두 가지가 있습니다. 하나는 기능을 구매하는 것이고, 다른 하나는 효율성을 높이는 것입니다.
첫 번째 방법: 역량 확보
하드웨어를 선택해야 할 타당한 이유는 분명합니다. 중앙 집중식 및 구역 기반 아키텍처는 워크로드를 더 적고 더 강력한 컨트롤러에 통합하며 배선도 줄여줍니다. 맥킨지는 이러한 컨트롤러에 더 많은 처리 능력이 필요하기 때문에, 추가 비용이 발생할 수 있다고 지적합니다. 상용차 OEM 업체들도 이러한 방향으로 나아가고 있습니다. 2025년에 출범한 다임러 트럭(Daimler Truck)과 볼보 그룹(Volvo Group)의 합작 회사인 ‘코레는 2025년에 출범한 다임러 트럭(Daimler Truck)과 볼보 그룹(Volvo Group)의 합작사로, 공유형 소프트웨어 정의 차량 플랫폼을 구축하고 있습니다. 또한 상용차용 중앙 집중식 고성능 컨트롤러를 사양화하고 조달할 예정이며, 첫 제품은 이번 10년 말까지 해당 차량에 탑재될 목표로 하고 있습니다.
고성능 중앙 또는 구역별 컨트롤러, 전용 AI 가속기 등 더 강력한 컴퓨팅 하드웨어는 카메라 인식, ADAS, 자율주행과 같이 워크로드에 이러한 성능이 반드시 필요한 경우, 혹은 차량의 수명 주기 동안 차량당 창출되는 가치가 생산 규모를 고려했을 때 추가 비용을 분명히 상회하는 모든 경우에 적합한 해결책입니다. 또한 새로운 플랫폼을 설계하는 단계에서도 이러한 하드웨어를 도입하는 것이 합리적입니다.
하지만 한계가 있습니다. 이 기술은 플랫폼의 출시 일정에 따라 신차에만 적용됩니다. 또한 컨트롤러의 크기가 커진다고 해서 효율적인 소프트웨어의 필요성이 사라지는 것은 아닙니다. 공유 컴퓨터에서 실행되는 모든 워크로드는 동일한 자원을 놓고 경쟁하기 때문입니다. 맥킨지가 자동차 분야의 엣지 AI 에 대한 맥킨지의 연구에서, 응답자의 46%가 시스템 온 칩(SoC) 리소스의 한계를 장애 요인으로 꼽았습니다.
두 번째 방법: 효율성 제고
이 소프트웨어 방식은 기존 하드웨어의 성능을 더욱 극대화합니다. 현재 다음과 같은 여러 기술이 성숙 단계에 이르렀습니다:
- 모델 압축. 정수 양자화를 통해 모델의 크기는 크기는 약 4배 줄이고 실행 속도는 3배 빠르게 정확도 손실은 거의 없습니다. 프루닝과 양자화를 결합하면 모델 저장 용량을 정확도에 영향을 주지 않으면서 35배에서 49배까지 줄일 수 있습니다. 맥킨지(McKinsey)는 마이크로컨트롤러가 에지에서 경량화된 딥러닝( AI ) 모델을 실행할 수 있는 능력이 점점 더 향상되고 있다고 지적합니다.
- 주문형 실행. 모델은 항상 가동된 상태로 유지되지 않고도 차량에 설치될 수 있습니다. '상시 가동(Always-On) AI 모델이 상용차 자원을 과부하시키는 문제'에서 설명한 바와 같이, 공유된 차량 내 런타임을 통해 지속적 또는 안전에 중요한 모델은 지속적으로 실행하고, 차량 상태가 필요할 때만(예: 차고 정차 중 배터리 상태 점검 등) 다른 모델을 활성화할 수 있습니다.
- 이벤트 기반 수집 및 차량 내 압축. 차량은 모든 데이터를 스트리밍하는 대신, 특정 이벤트와 관련된 데이터만 저장하고 전송합니다.
- 가상 센서. 소프트웨어는 물리적 센서를 추가하는 대신, 차량 네트워크에 이미 존재하는 신호를 바탕으로 값을 추정할 수 있습니다. 한 파트너 사례 연구에서는 CAN 신호를 기반으로 구축된 소프트웨어 전용 헤드라이트 레벨링 센서를 통해 차량당 하드웨어 비용을 최대 20달러까지 절감했습니다. 이 경우 소프트웨어 방식은 단순히 BOM 비용 증가를 피하는 데 그치지 않고, 해당 비용을 완전히 제거합니다.
트럭 분야에서 소프트웨어 기반 접근 방식의 가장 큰 장점은 적용 범위입니다. 이 방식은 이미 운행 중인 차량에 대해, 해당 차량의 연산 능력 범위 내에서, 그리고 차세대 아키텍처를 기다릴 필요 없이 기존 프로그램 상에서 무선으로 배포될 수 있습니다. 이것이 바로 Fastlane™ Edge는 전용 ‘ AI ’ 가속기 없이도 고성능 게이트웨이, 텔레매틱스 장치, 중앙 컴퓨터 등 차량이 이미 탑재하고 있는 컴퓨팅 리소스를 활용해 ‘ AI ’ 모델, 가상 센서 및 예측 진단 기능을 실행합니다. 트럭에 아직 이러한 컴퓨팅 리소스가 없는 경우, Fastlane™ Copilot 프로토타입 및 테스트 차량에서 생산 아키텍처를 변경하지 않고도 기존 차량에 고성능 게이트웨이를 추가합니다.
하지만 이 방법에도 한계가 있습니다. 소프트웨어만으로는 게이트웨이를 지각 컴퓨터로 바꿀 수 없습니다. 소프트웨어는 연산 여유 용량, 메모리, 검증 작업의 한계로 인해 제약을 받으며, 안전, 사이버 보안, 수명 주기 관리 측면에서도 별도의 비용이 발생합니다.
이것을 하나의 결정으로 여기세요
하드웨어와 소프트웨어를 별개의 예산으로 취급하는 것이 실수입니다. 소프트웨어의 효율성에 따라 필요한 하드웨어의 양이 결정됩니다. 플랫폼 팀을 위한 실용적인 절차는 다음과 같습니다:
- 먼저 최적화를 수행한 다음, 하드웨어 사양을 결정하십시오. 압축 및 이벤트 기반 설계가 적용된 후의 워크로드 요구 사항을 파악해야 하며, 그 이전 단계가 아닙니다.
- 가치가 어디에 있는지 물어보세요. 그 가치의 대부분이 설치 기반에 있다면, 하드웨어 방식으로는 그 가치를 확보할 수 없습니다.
- 귀사의 생산량 기준에서 가치와 비용을 비교해 보십시오. 차량 1대당 수명 주기 동안의 가치를, 실제 생산 대수에 분산된 추가 하드웨어 및 통합 비용과 비교해 보십시오.
- 새로운 아키텍처가 곧 도입될 예정인 경우, 여유를 확보해 두십시오. 효율적인 소프트웨어가 그 여백을 채울 것이라는 전제 하에 계획을 세우십시오.
소프트웨어에도 별도의 비용이 발생합니다. 트럭에 추가되는 각 모델에는 연산 능력, 메모리, 통합 작업, 검증 과정이 필요하며, 차량의 수명 기간 동안 유지보수가 이루어져야 합니다. 모델은 필요할 때만 실행하고, 하나의 런타임을 모델 간에 공유함으로써 새로운 사용 사례가 생길 때마다 비용이 늘어나는 것을 막을 수 있습니다.
작업 부하가 온프레미스 환경에 적합해지면, 다음으로 고려해야 할 점은 어떤 작업이 온프레미스에 배치되어야 하고 어떤 작업이 클라우드에 배치되어야 하는지입니다. 이에 대해서는 3부에서 다룰 예정입니다.
결론: 풍부한 차량 컨텍스트를 수집하고 차량에서 딥러닝( AI )을 실행하는 데는 비용이 들며, 상용차 OEM들은 승용차 제조사들보다 훨씬 적은 생산 규모로 이 비용을 부담해야 합니다. 이들은 두 가지 방식으로 비용을 충당할 수 있습니다. 더 고성능의 하드웨어를 추가하고 데이터의 가치로 이를 정당화하거나, 차량에 이미 탑재된 컴퓨팅 자원으로도 실행될 수 있을 만큼 소프트웨어를 효율적으로 만드는 것입니다. 대부분은 두 가지 접근 방식을 모두 채택할 것입니다. 그러나 낮은 생산량, 12년에 달하는 수명, 긴 아키텍처 주기를 고려할 때, OEM들은 소프트웨어를 기본 옵션으로 삼아야 합니다. 즉, 트럭에 이미 탑재된 컴퓨팅 자원을 활용해 새로운 워크로드를 실행하고, 카메라 인식과 같은 워크로드에 필요한 경우나 새로운 E/E 아키텍처가 이미 설계되고 있는 경우에만 컴퓨팅 하드웨어를 추가해야 합니다.