자동차 산업에서 소프트웨어 전환이 느린 이유: SDV의 5개 병목

자동차 산업에서 소프트웨어 전환은 늘 곧 가속될 것처럼 보입니다. 완성차 업체마다 전용 운영체제와 OTA, 중앙 컴퓨터를 발표하고 개발자 채용도 늘렸습니다. 그런데 첫 플랫폼을 공개한 뒤 실제 차종에 적용하기까지는 여러 해가 걸리고, 한 번 정한 출시일이 다시 밀리는 일도 드물지 않습니다.

이 시간차를 단순히 전통 완성차의 소프트웨어 역량 부족으로 설명하면 중요한 부분을 놓칩니다. 자동차의 코드는 브레이크, 조향, 배터리와 실내 기능을 실제 하드웨어에서 움직이고, 수많은 공급사의 부품과 함께 인증을 받아야 합니다. 출시 뒤에는 지역과 연식이 다른 차량을 10년 이상 지원해야 하죠. 웹서비스의 릴리스 주기를 자동차에 그대로 적용할 수 없는 이유입니다.

자동차 산업에서 소프트웨어 전환은 코드 생산속도보다 차량 전체를 다시 검증하는 속도에 묶여 있습니다. SDV 전환이 느린 까닭은 개발자가 부족해서가 아니라 E/E 아키텍처, 안전·보안 증거, 조직의 예산과 책임, 부품사 계약, 운행 차량의 버전이 한꺼번에 바뀌어야 하기 때문입니다. 소프트웨어는 빠르게 만들 수 있어도 자동차 시스템은 가장 느린 제약만큼만 움직입니다.

자동차 산업에서 소프트웨어 전환의 실제 단계

SDV는 OTA 기능이 많은 자동차가 아니라 하드웨어 교체 없이 차량 기능의 수명주기를 관리할 수 있는 아키텍처입니다. 기능을 특정 ECU와 분리해 공통 소프트웨어 플랫폼 위에 올리고, 차량 안팎의 데이터를 이용해 개발·배포·진단·개선을 반복하는 구조에 가깝습니다. 인포테인먼트 앱 몇 개를 무선으로 업데이트한다고 차량 전체가 SDV가 되는 것은 아닙니다.

이 차이는 업데이트 범위에서 드러납니다. 지도와 음원 앱은 안전제어와 상대적으로 멀리 떨어져 있어 짧은 주기로 바꿀 수 있습니다. 반면 제동거리, 조향감, 배터리 열관리나 운전자보조 기능을 수정하면 센서 입력, 실시간 처리, 고장모드와 다른 제어기의 반응까지 다시 검증해야 합니다. SDV의 가치는 후자까지 안전하게 바꿀 수 있을 때 커집니다.

따라서 전환은 세 단계로 나눠 보는 편이 정확합니다. 첫 단계는 cockpit과 연결서비스 중심의 OTA이고, 다음은 domain controller와 공통 미들웨어를 여러 차종에서 재사용하는 단계입니다. 마지막은 중앙·zonal E/E 구조 위에서 안전 관련 기능도 독립적으로 개발하고 차량 수명기간 동안 업데이트하는 상태입니다. 완성차의 발표가 어느 단계인지 구분하지 않으면 ‘OTA 가능’과 ‘차량 전체 SDV’를 혼동하게 됩니다.

Toyota의 접근은 이 순서를 보여줍니다. 2025년 말 출시된 RAV4는 Arene을 Toyota Safety Sense와 cockpit 소프트웨어 개발에 처음 사용했고, Toyota는 향후 여러 기능의 동시 업데이트로 확대하겠다고 밝혔습니다. RAV4 공식 발표는 첫 양산 적용과 차량 전체의 지속 업데이트 사이에 아직 단계가 남아 있음을 솔직하게 드러냅니다.

Mercedes-Benz 역시 CLA를 자체 개발 MB.OS가 들어간 첫 SDV로 규정했으며, 이후 신차로 적용 범위를 넓히는 중입니다. BMW는 Neue Klasse에 새로운 중앙·zonal 전장 구조를 먼저 적용했습니다. 선도 완성차조차 기존 전 차종을 한꺼번에 바꾸지 않고 새 플랫폼과 대표 차종에서 시작한다는 공통점이 있습니다. 이 선택은 다음 병목이 코드가 아니라 차량 아키텍처라는 점을 보여줍니다.

E/E 아키텍처: ECU 통합의 비용

기존 ECU를 중앙·zonal 구조로 통합하는 순간 소프트웨어 전환은 전장 아키텍처 재개발 사업이 됩니다. 전통적인 차량은 엔진, 제동, 차체, 좌석, 조명과 인포테인먼트 기능마다 전용 ECU와 배선을 붙여 왔습니다. 새로운 기능을 추가할 때마다 상자를 하나 더 넣는 방식은 공급사별 책임을 나누기 쉬웠지만, 차량 전체 데이터를 공유하거나 여러 기능을 한 번에 업데이트하기에는 불리합니다.

중앙화는 ECU 수를 줄이는 작업보다 어렵습니다. 어느 기능을 중앙 컴퓨터와 zone controller에 배치할지 정하고, 통신 지연과 대역폭, 전력모드, 부팅순서, 열과 고장격리를 다시 설계해야 합니다. 브레이크 센서의 신호가 여러 소프트웨어 기능에 쓰인다면 한 영역의 장애가 다른 영역으로 번지지 않는지도 증명해야 합니다.

BMW는 Neue Klasse에서 주요 고객 기능을 네 개의 고성능 컴퓨터에 모으고 zonal wiring architecture를 도입했습니다. 회사 발표에 따르면 새 구조는 이전 세대보다 배선을 600m 줄이고 무게를 30% 낮춥니다. BMW의 공식 설명은 소프트웨어 재사용과 함께 물리적 배선, 전력관리와 차량 원가가 동시에 바뀐다는 점을 보여줍니다.

이 변화는 기존 차량에 OTA로 소급하기 어렵습니다. 중앙 컴퓨터의 성능, 네트워크 topology와 zone controller가 처음부터 들어가야 공통 API와 기능분리가 작동하기 때문입니다. 이미 판매 중인 차종의 분산 ECU를 소프트웨어만으로 중앙화할 수는 없습니다. SDV 전환속도가 차세대 vehicle platform의 설계와 SOP 일정에 묶이는 이유입니다.

Volkswagen과 Rivian의 합작사 RV Tech는 2026년 3월 production-intent zonal architecture의 동계시험을 마쳤다고 발표했습니다. 시험차는 Volkswagen, Audi와 Scout 브랜드를 대상으로 하지만 양산차 적용까지는 내구·안전·공장·서비스 검증이 더 남습니다. 공동개발 계약을 체결한 시점과 production-intent hardware가 겨울시험을 통과한 시점 사이에 시간이 필요한 것은 이 통합범위 때문입니다.

표준 미들웨어와 고성능 SoC가 비용을 낮출 수 있다는 반론도 타당합니다. 다만 공통 부품을 산다고 기능할당과 고장책임이 자동으로 정리되지는 않습니다. 같은 SoC를 사용해도 브랜드별 주행감, 센서 구성과 안전목표가 다르면 검증행렬은 다시 늘어납니다. 부품의 표준화보다 차량 플랫폼에서 실제로 재사용되는 소프트웨어 비중을 봐야 합니다.

안전 인증과 OTA 변경관리

OTA가 릴리스를 빠르게 하는 만큼 안전·보안 증거와 변경 추적의 부담도 커집니다. 스마트폰 앱은 문제가 생기면 이전 버전으로 되돌릴 수 있지만, 주행 중인 차량의 업데이트 실패는 제어기 부팅과 안전기능에 직접 영향을 줄 수 있습니다. 업데이트할 수 있다는 능력과 안전하게 반복 업데이트할 수 있다는 능력은 다릅니다.

UNECE의 UN Regulation No. 156는 제조사에 Software Update Management System을 요구합니다. 어떤 소프트웨어 버전이 어느 차량에 들어갔는지, 업데이트가 차종 승인과 안전에 어떤 영향을 주는지, 배포 전후의 무결성과 실패 대응을 어떻게 관리하는지 입증해야 합니다. OTA는 개발팀의 편의기능이 아니라 제조사 차원의 관리체계입니다.

R155의 cybersecurity management 요구도 같은 방향으로 작동합니다. 차량이 외부와 연결되고 업데이트 경로가 열리면 취약점 모니터링, 공급망 위험과 운행기간의 보안 대응이 제조사 책임에 들어옵니다. 출시 시점에 한 번 시험하는 방식으로는 충분하지 않고, 새 취약점과 업데이트가 발생할 때마다 위험판단을 이어가야 합니다.

기능안전은 릴리스의 영향범위를 더 넓힙니다. 제동 제어의 한 모듈을 바꿨더라도 입력신호, scheduling, 통신 timeout과 fallback이 달라지면 연결된 안전분석을 다시 살펴야 합니다. 코드를 한 줄 수정하는 시간보다 그 변경이 기존 safety case를 깨지 않는다는 증거를 만드는 시간이 더 길 수 있습니다.

이 부담을 줄이는 방법은 업데이트를 멈추는 것이 아닙니다. 안전영역과 비안전영역을 격리하고, stable API와 virtualization으로 변경범위를 제한하며, 가상 ECU와 hardware-in-the-loop 시험을 자동화해야 합니다. Toyota가 Arene Tools를 통해 가상환경의 검증·평가를 강조하고 BMW가 하드웨어와 소프트웨어 분리를 내세우는 이유도 여기에 있습니다.

그래도 모든 검증을 소프트웨어로 대체할 수는 없습니다. 전압변동, 열, 진동, 센서 오염과 통신장애는 실제 차량과 환경에서 확인해야 합니다. 규제와 안전이 전환을 느리게 만드는 것이 아니라, 결함비용이 큰 제품에서 릴리스를 반복 가능하게 만드는 최소한의 운영조건이라고 보는 편이 맞습니다.

조직 운영: 프로젝트에서 제품으로

차량 아키텍처가 바뀌어도 조직이 차종 프로젝트 방식에 머물면 릴리스 속도는 크게 달라지지 않습니다. 전통적인 개발조직은 SOP를 목표로 브랜드·차종·기능별 예산을 배정하고, 출시 뒤 인력을 다음 프로그램으로 옮기는 경우가 많습니다. 반면 소프트웨어 플랫폼은 출시 후에도 오류수정, 보안과 기능개선을 계속 담당할 장기 제품팀을 필요로 합니다.

이 차이는 우선순위 충돌을 만듭니다. 플랫폼팀은 공통 API와 코드 재사용을 원하지만 차종 책임자는 정해진 출시일에 필요한 전용기능을 먼저 요구합니다. 공통화가 늦어지면 차종팀은 예외 코드를 만들고, 예외가 쌓이면 다음 차종의 통합비용이 다시 늘어납니다. 단기 SOP를 지키는 합리적 행동이 장기 플랫폼의 속도를 떨어뜨리는 셈입니다.

예산구조도 영향을 줍니다. 공통 플랫폼 투자는 여러 브랜드와 차종이 장기간 혜택을 보지만 비용은 당장 어느 조직이 부담할지 불분명합니다. 효과는 미래 차종의 개발비와 warranty에서 나타나고, 현재 프로젝트에는 일정 위험이 먼저 보입니다. 플랫폼 책임자에게 다년 예산과 차종에 대한 기술결정권이 없으면 재사용 목표는 쉽게 후순위로 밀립니다.

Volkswagen은 2025년 연차보고서에서 CARIAD를 기술적으로 재구조화하고 조직을 더 간결하게 만들었다고 설명했습니다. 동시에 Rivian과의 합작을 통해 새 E/E와 소프트웨어 아키텍처를 개발하고 있습니다. 내부조직을 키우는 것만으로 문제를 풀지 못하고 이미 작동하는 아키텍처와 개발방식을 외부 파트너십으로 보완한 결정입니다.

이 사례를 ‘내재화 실패’로만 읽기도 어렵습니다. 완성차는 차량 통합, 안전·규제와 제조에서 강점을 갖고 소프트웨어 전문조직은 플랫폼과 릴리스 운영에서 앞설 수 있습니다. 중요한 질문은 어느 코드를 직접 쓰느냐보다 플랫폼 roadmap과 인터페이스, 차량 데이터와 최종 품질책임을 누가 통제하느냐입니다.

경영진 입장에서는 개발자 수보다 조직의 의사결정 시간을 측정해야 합니다. 공통 API 변경, 안전 결함의 우선순위와 차종 예외 승인에 몇 개 위원회가 관여하는지, release train을 어느 책임자가 멈출 수 있는지가 실제 속도를 정합니다. 조직도를 바꾸지 않은 채 agile 도구만 도입하면 회의 이름만 달라질 가능성이 큽니다.

부품사 계약과 책임 재배분

차종 프로젝트 조직과 부품사별 블랙박스 계약은 차량 전체 소프트웨어의 단일 책임자를 만들기 어렵게 합니다. 기존 분산형 E/E 구조에서는 완성차가 ECU 성능과 인터페이스를 정의하고 Tier-1이 하드웨어·기본소프트웨어·기능을 묶어 납품하는 방식이 효율적이었습니다. 결함이 나면 해당 부품의 공급사에 책임을 묻기도 쉬웠습니다.

SDV에서는 이 경계가 흔들립니다. 여러 기능이 중앙 컴퓨터의 공통 운영체제와 middleware를 공유하면 한 결함의 원인이 애플리케이션, platform software, semiconductor driver, sensor firmware 또는 network timing 중 어디에 있는지 즉시 분리하기 어렵습니다. 완성차가 통합책임을 지려면 공급사가 보유한 source code, test evidence와 진단데이터에 접근할 수 있어야 합니다.

그 과정에서 계약조건이 기술속도를 좌우합니다. 소스코드 수정권, API 변경권, 취약점 패치기한, 데이터 사용권과 운행기간 지원비를 누가 부담하는지 다시 정해야 합니다. 과거에는 ECU 납품가격에 포함되던 기능이 차량 판매 뒤 반복 업데이트되는 서비스로 바뀌면 지식재산과 warranty 책임의 경계도 달라집니다.

공급사도 쉽게 양보하기 어렵습니다. 수십 년간 축적한 제어 알고리즘과 차량별 튜닝은 경쟁력의 원천이며, 소프트웨어를 개방하면 단순 하드웨어 제조사로 밀릴 위험이 있습니다. 완성차가 내재화를 요구할수록 Tier-1은 개발비 보전과 장기 계약을 요구하게 됩니다. 기술 아키텍처의 전환이 이익배분 협상으로 이어지는 이유입니다.

수직통합에는 반대비용이 있습니다. 완성차가 운영체제부터 애플리케이션까지 모두 개발하면 통제력은 높아지지만 인력, toolchain, 보안대응과 장기 유지비를 직접 부담합니다. 판매량이 충분하지 않거나 여러 브랜드가 코드를 재사용하지 못하면 차량당 소프트웨어 원가는 오히려 올라갈 수 있습니다.

따라서 내재화율 자체는 좋은 KPI가 아닙니다. 안전과 고객경험을 차별화하는 control point는 완성차가 통제하고, commodity layer는 표준과 파트너를 활용하는 경계가 더 중요합니다. 계약상 수정권과 데이터 접근권, 공급사 교체 시 재인증 범위가 줄어드는지를 함께 확인해야 합니다.

차량 수명주기와 버전 부채

한 번의 SDV 출시보다 여러 차종과 연식에서 호환되는 업데이트를 10년 이상 유지하는 일이 더 어렵습니다. 스마트폰은 몇 개의 하드웨어 세대를 빠르게 교체하지만 자동차는 지역, 트림, 파워트레인, 센서와 공급사 조합이 많은 상태로 장기간 운행됩니다. 동일한 소프트웨어 기능도 차량별 hardware bill과 규제조건에 따라 다른 검증이 필요합니다.

새 플랫폼과 기존 fleet가 공존하는 기간에는 두 비용이 겹칩니다. 중앙·zonal architecture용 신규 코드를 만들면서 분산 ECU 기반 차량의 보안패치와 결함수정도 계속해야 합니다. 신차 판매가 모두 새 플랫폼으로 바뀌기 전까지 legacy toolchain과 공급사 계약을 유지해야 하므로, 전환 초기에는 비용절감보다 중복비용이 먼저 나타납니다.

버전 수가 늘면 OTA의 장점도 약해집니다. 하나의 패치를 여러 ECU 세대와 지역규정에 맞게 빌드하고, 각 조합에서 검증한 뒤 단계적으로 배포해야 합니다. 배터리 상태나 통신환경 때문에 업데이트가 중단되면 rollback과 서비스센터 대응도 준비해야 하죠. 배포버튼을 한 번 누르는 모습 뒤에 거대한 configuration management가 있습니다.

BMW는 Neue Klasse의 소프트웨어가 첫 차량 출시 뒤에도 진화하면서 초기 차량과의 호환성을 유지하겠다는 목표를 제시했습니다. 이 목표가 중요한 까닭은 신규기능 수보다 platform continuity가 고객 신뢰와 개발비를 좌우하기 때문입니다. 차세대 모델의 코드가 이전 모델에도 안전하게 적용돼야 진정한 재사용 효과가 생깁니다.

Toyota도 Arene을 RAV4의 안전·cockpit 영역에서 시작해 지역별 기능과 다기능 업데이트로 확대할 계획입니다. 대량판매 차종을 첫 적용대상으로 고른 것은 데이터와 학습규모를 확보하는 장점이 있지만, 다양한 지역과 사양을 동시에 지원해야 하는 부담도 큽니다. 성공 여부는 최초 탑재보다 이후 연식에서 같은 플랫폼을 얼마나 재사용하는지로 드러날 것입니다.

수명주기 경제성은 구독매출보다 먼저 warranty와 품질비용에 나타날 수 있습니다. OTA로 서비스센터 방문을 줄이면 비용이 낮아지지만, 잦은 오류와 rollback은 고객불만과 보증비를 키웁니다. GM은 2025년 10-K에서 소프트웨어 기반 서비스 확대를 설명하는 동시에 warranty 관련 비용과 캠페인 증가도 공시했습니다. 두 항목을 직접 인과로 묶을 수는 없지만, 디지털 기능의 성장과 품질비용을 함께 봐야 한다는 점은 분명합니다.

SDV 전환의 판정 지표

SDV 전환은 개발자 수가 아니라 공통 플랫폼 적용 차종, ECU 통합, 검증시간, OTA 성공률, 결함비용과 공급사 의존도의 동시 개선으로 확인해야 합니다. 플랫폼 이름을 발표하는 일보다 같은 코드와 toolchain이 여러 차종에서 반복 사용되고, 변경 한 건당 검증범위와 현장 결함이 줄어드는지가 중요합니다.

판정은 세 층으로 나눌 수 있습니다. 아키텍처에서는 ECU·배선 수, 공통 API와 중앙컴퓨팅 적용 차종을 봅니다. 개발운영에서는 코드 재사용률, 통합·검증 lead time, release 빈도와 rollback 비율을 확인합니다. 손익에서는 차종당 개발비, 출시지연, warranty와 서비스센터 방문이 줄어드는지 측정해야 합니다.

투자자 입장에서 핵심은 소프트웨어 투자액을 성과로 착각하지 않는 것입니다. 대규모 채용과 R&D 비용은 전환 의지를 보여주지만, 아키텍처가 공통화되지 않으면 차종마다 같은 문제를 다시 풉니다. 공통 플랫폼 적용률과 차종별 engineering cost가 같은 방향으로 개선될 때 투자효율을 확인할 수 있습니다.

업체별 공시문도 단계에 맞춰 읽어야 합니다. 운영체제를 공개했다면 양산 적용 차종과 기능영역을, OTA를 강조한다면 안전 관련 update 비중과 성공률을, zonal architecture를 발표했다면 ECU 통합과 배선·원가 절감이 실제 차량에서 재현되는지 묻습니다. 소프트웨어 매출목표에는 활성차량, 유료전환, 서비스 제공비와 warranty를 붙여 봐야 합니다.

현재 사례는 전환이 실패하고 있다는 뜻이 아닙니다. BMW, Mercedes-Benz, Toyota와 Volkswagen 모두 새 차종과 플랫폼에서 중앙화·공통 소프트웨어·OTA 범위를 넓히고 있습니다. 다만 그 진전은 앱 출시처럼 전 차종에 즉시 복제되지 않고, 신규 vehicle platform과 안전인증의 일정에 맞춰 계단식으로 나타납니다.

AlixPartners의 2026년 글로벌 SDV 조사도 경쟁초점이 단순 코드량에서 software control point, 재사용과 차량 수명주기 경제성으로 이동한다고 지적합니다. 조사결과를 개별 기업의 성패로 바로 적용할 수는 없지만, 무엇을 측정해야 하는지에는 유용합니다. 출시기능 수보다 한 플랫폼이 몇 차종과 연식에서 비용을 줄였는지가 더 강한 증거입니다.

이 판단이 빗나갈 수 있는 경우

첫째, 새 EV 전용 플랫폼을 처음부터 설계하는 업체는 기존 ECU와 계약을 걷어낼 필요가 없어 훨씬 빠르게 움직일 수 있습니다. 차종 수와 지역 변형이 적다면 공통 hardware와 software를 유지하기도 쉽습니다. 이들에게 전통 완성차의 속도제약을 그대로 적용하면 경쟁력을 과소평가하게 됩니다.

둘째, 안전과 무관한 영역은 이미 소비자 전자제품에 가까운 속도로 바뀔 수 있습니다. 인포테인먼트, 음성비서와 일부 개인화 기능은 격리된 domain에서 업데이트할 수 있고 규제 영향도 상대적으로 작습니다. 전체 차량 전환이 느리더라도 고객이 체감하는 디지털 경험은 빠르게 개선될 가능성이 있습니다.

셋째, 표준 middleware, 공통 SoC와 가상검증 기술이 예상보다 빨리 성숙하면 재개발과 인증비용이 크게 낮아질 수 있습니다. 기능의 의존관계를 자동으로 추적하고 simulation evidence가 규제기관과 고객에게 받아들여지면 릴리스 병목은 완화됩니다. 이 경우 기존 조직도 새 toolchain을 통해 더 빠르게 전환할 수 있습니다.

넷째, 소프트웨어 플랫폼을 외부에서 도입하는 전략이 자체개발보다 나은 결과를 낼 수 있습니다. 독자 OS를 보유하지 않아도 인터페이스와 데이터, safety case의 최종 통제권을 확보한다면 고객가치와 개발속도를 동시에 얻을 수 있습니다. 내재화 비중을 경쟁력과 동일시하면 이런 모델을 놓치게 됩니다.

자동차의 소프트웨어화는 되돌리기 어려운 방향입니다. 다만 전환의 경제성은 코드가 많아지는 데서 나오지 않습니다. 공통 E/E 플랫폼이 여러 차종에 재사용되고, 안전한 update의 검증시간이 줄며, 공급사와 책임경계가 정리되고, 운행 fleet의 품질비용이 내려가야 합니다.

경영진과 투자자가 봐야 할 것도 개발자 수나 화려한 데모가 아닙니다. ECU 통합과 공통 플랫폼 적용률, 검증 lead time, OTA 성공·rollback, warranty와 차종당 engineering cost가 함께 개선되는지 확인해야 합니다. 이 지표가 좋아질 때 소프트웨어는 비용센터에서 반복 가능한 제품역량으로 바뀝니다.

SDV 전환은 소프트웨어 기업처럼 빨리 움직이는 경주가 아니라 자동차 기업이 반복 가능한 소프트웨어 생산체계를 갖추는 전환입니다. 승자는 코드를 가장 많이 쓰는 회사보다 아키텍처·안전·조직·계약·수명주기의 제약을 하나의 운영모델로 묶는 회사일 가능성이 높습니다.