OS들의 시스템: E/E 아키텍처, 차량 OS, 그리고 AI 정의 차량

초록

‘차량 OS’는 소프트웨어 정의라고 불리고 싶은 모든 완성차 업체가 반드시 가져야 하는 단어가 되었다. 그러나 ‘OS’라고 불리는 것들은 전혀 같은 종류의 것이 아니다. 본고는 존재론적 정리에서 출발한다. 콕핏 OS는 차량 OS가 아니고, 도메인 OS는 차량 OS가 아니며, 런타임은 OS가 아니다. 현재 양산 중인 모든 차량 OS — MB.OS, NIO SkyOS, Li Auto HaloOS, Pleos Vehicle OS — 는 하나의 차량 전체 제어 평면이 거버넌스하는 멀티 커널 조합체다. 우리는 그 제어 평면을 관찰 가능한 세 부분 — 계약, 오케스트레이션, 라이프사이클 — 으로 분해하고, 이로부터 6개 차원의 차량 OS 역량 매트릭스(VOCM)를 도출하여, 이를 D2의 AR 점수와 대조하면서 15개 완성차 업체에 대한 초기 평가를 제시한다.

본고의 핵심은 하나의 인과 구조다. E/E 아키텍처는 차량 OS가 될 수 있는 것의 경계를 정한다. 그러나 기능이 소프트웨어가 되면 인과가 역전된다 — 소프트웨어 워크로드가 다음 세대 E/E 아키텍처를 설계하기 시작한다(아키텍처–OS 공진화 루프). 그 위에서 우리는 다음을 논증한다. 자율주행은 차량 OS가 진짜인지를 가리는 스트레스 테스트다. AI는 OS의 상반부를 얇게 하고 하반부를 두껍게 한다. 그리고 업계가 실제로 표준화하고 있는 것은 ‘하나의 자동차 OS’가 아니라 차량 API, 데이터 모델, 런타임 계약이다. 결론은 세 가지 판단과 한 가지 경고를 제시하고, 다섯 개의 개정 트리거를 붙인다.

---

체재에 관한 주기

본고는 Deep Dive 범주에 속하며, Working Paper 범주가 아니다. 경계선은 길이가 아니라 약속의 수준에 있다:

• Working Paper(D1–D4, Zenodo DOI) = 고정된 주장. 조용히 개정되지 않으며, 5년의 인용을 견디도록 구축된다.
• Deep Dive(본 범주) = 규율 있는 관찰. 개정 가능·반증 가능하며, ‘지금 우리가 보는 것’이라고 명시되고, DOI 체계 밖에 있다.

본고는 Working Paper의 인식론적 규율 — 출처 계층화, 추적 가능한 증거, 필수적인 반론과 실패 모드 — 을 계승하되, 그 최종성은 계승하지 않는다. 본고는 D1–D4의 어떤 발표된 결론도 개정하지 않는다. 본고가 인용하는 D2 점수는 발표된 판본의 점수다. 증거 등급은 본문에 [T1], [T2], [T3], [추론]으로 표시한다. 부록 A를 참조하라. 본고의 결론은 자체 개정 트리거를 갖는다(제10장). 어느 트리거라도 작동하면, 변경을 명시한 개정판을 발표한다.

---

서론: 모두가 쓰지만 아무도 정의하지 않는 단어

2025년 6월, MB.OS를 탑재한 첫 CLA가 Mercedes-Benz Rastatt 공장의 라인을 빠져나왔다[T1]. 같은 시기 NIO는 자사의 SkyOS를 ‘전 도메인 차량 운영체제’라고 불렀고, Li Auto는 HaloOS를 Apache 2.0으로 오픈소스화했으며, Toyota는 신형 RAV4와 함께 Arene을 출시했고, Hyundai는 Pleos를 ‘Vehicle OS’와 ‘Connect’라는 두 브랜드로 분리했다. 2026년에 이르러 ‘차량 OS’는 소프트웨어 정의라고 불리고 싶은 모든 완성차 업체가 반드시 가져야 하는 단어가 되었다.

문제는 ‘OS’라고 불리는 것들이 전혀 같은 종류의 것이 아니라는 데 있다.

Android Automotive는 OS다. BMW Operating System X도 OS라고 불린다. NVIDIA DriveOS도 OS라고 불린다. AUTOSAR는 때때로 잘못 OS라고 불린다. MB.OS, SkyOS, HaloOS, Pleos Vehicle OS도 모두 OS다. 이들을 한 표에 넣고 순위를 매기면, 사과와 오렌지와 과수원을 비교하는 셈이 된다.

본 연구 시리즈는 이 단어를 세 번 다루었지만, 멈춰 서서 정의한 적은 없다. D1은 OS를 7개 아키텍처 제어점 가운데 C3로 열거하고, RTOS·AUTOSAR·미들웨어를 E/E 아키텍처의 소프트웨어 계층에 써넣었으며, §3.4에서 하이퍼바이저가 개방형 생태계와 하드 리얼타임을 잇는 다리라고 논했다. D2는 Mercedes 프로파일에서 MMA(하드웨어 플랫폼)와 MB.OS(소프트웨어 운영체제)를 명시적으로 구분하고, 독자에게 둘을 혼동하지 말라고 경고했다. DD-08 운전자의 퇴장은 인간 운전자가 폴백 체인에서 빠지면 fail-operational이 프리미엄 옵션에서 진입 조건으로 바뀐다고 논했다.

세 편 모두 같은 빈칸을 가리킨다: ‘전기·전자 토폴로지’와 ‘지능’ 사이에서, 어떤 계층이 한 무더기의 컨트롤러를 프로그래밍 가능하고, 계속 진화할 수 있으며, 결국 자율주행과 AI를 실어 나를 수 있는 기계로 바꾸는가?

이것이 본고가 답하는 질문이다. 주된 질문은 하나다:

어떤 조건에서 E/E 아키텍처는 단순한 전자 토폴로지이기를 멈추고 ‘프로그래밍 가능한 자동차’의 플랫폼이 되는가?

우리의 답은 네 문장으로 압축되며, 이는 본고의 골격이기도 하다:

E/E는 기질(substrate)이다. 제어 평면이 OS다. AI는 적응형 지능이다. 자율주행은 스트레스 테스트다.

이를 풀면 여섯 가지 판단이 된다:

• T1 | 정의: 차량 OS는 하나의 운영체제가 아니라, 차량 전체 제어 평면이 거버넌스하는 ‘OS들의 시스템’이다. 제어 평면 = 계약 + 오케스트레이션 + 라이프사이클.
• T2 | 전제: 충분히 디커플링된 E/E 아키텍처 없이는 차량 OS도 없다. 소프트웨어 추상화의 상한은 물리 아키텍처가 정한다.
• T3 | 역전: 기능이 소프트웨어가 되면 인과가 역전된다 — 소프트웨어 워크로드가 다음 세대 E/E 아키텍처를 설계하기 시작한다. 이것이 본고의 핵심 독창적 기여인 아키텍처–OS 공진화 루프다.
• T4 | 스트레스 테스트: 자율주행은 차량 OS가 아니다. 그것은 ‘차량 OS’가 그 이름에 걸맞은지를 시험하는 워크로드다.
• T5 | 거버넌스: AI는 OS를 없애지 않는다. AI는 OS의 상반부를 얇게 하고 하반부를 두껍게 한다 — 확률적 지능은 결정론적 거버넌스 안에서 실행되어야 한다.
• T6 | 수렴점: 업계가 실제로 표준화하고 있는 것은 ‘하나의 자동차 OS’가 아니라 ‘차량 API + 데이터 모델 + 런타임 계약’이다. 커널은 범용화되고 있으며, 제어점 C3는 C2(실리콘)와 C4(미들웨어)에 의해 양쪽에서 압착되고 있다.

가장 기본적인 작업, 즉 단어를 정리하는 일부터 시작하자.

---

1. 명명의 문제: ‘OS’라고 불리는 모든 것이 OS는 아니다

1.1 존재론적 정리

컴퓨터 과학에서 ‘운영체제’는 꽤 명확한 의미를 갖는다: 하드웨어 자원을 관리하고 그 위의 프로그램에 추상화와 격리를 제공하는 소프트웨어 계층. Linux, QNX, 각종 RTOS가 모두 여기에 해당한다. 문제는 자동차 산업이 같은 단어를 적어도 네 가지 서로 다른 수준에 적용한다는 것이다:

• 커널 수준 OS: QNX, Linux, Classic AUTOSAR OS, RTOS, 마이크로커널. 이들은 하나의 칩 또는 하나의 ECU를 관리한다.
• 런타임과 미들웨어: AUTOSAR Adaptive Platform, SOME/IP, DDS, ROS 2. 이들은 통신, 서비스 디스커버리, 실행 관리를 정의하지만, 그 자신은 커널 위에서 실행된다 — Adaptive Platform의 대상 하드웨어는 POSIX PSE51을 준수하는 운영체제를 실행하며, AP는 그 위에 구축된다[T2].
• 도메인 OS: Android Automotive, BMW OS X, NVIDIA DriveOS, HarmonyOS 콕핏. 이들은 콕핏이나 주행 컴퓨터 같은 하나의 기능 도메인을 관리한다.
• OEM이 ‘차량 OS’라고 부르는 것: MB.OS, SkyOS, HaloOS, Pleos Vehicle OS. 이들은 차량 전체를 관리한다고 주장한다.

앞의 세 수준은 명확한 공학적 경계를 갖는다. 네 번째는 그렇지 않다. 그것은 브랜드명이자, 조직적 약속이자, 여러 커널·도메인·칩에 걸친 소프트웨어 덩어리다. 본고 전체는 이 네 번째 수준에 검증 가능한 정의를 부여하려는 시도다.

1.2 세 가지 판별 규칙

정의하기 전에, 세 가지 부정적 규칙을 제시한다. 그 역할은 차량 OS로 간주되지 않는 것을 배제하는 데 있다.

규칙 1: 콕핏 OS ≠ 차량 OS.

BMW Operating System X는 AOSP 기반이며 Panoramic iDrive의 디스플레이, 인터랙션, 디지털 경험을 담당한다[T2]. Neue Klasse의 실제 차량 아키텍처는 인포테인먼트, 자율주행, 주행 다이내믹스, 기본 기능을 위한 네 개의 ‘슈퍼브레인’과 존 컨트롤러로 이루어진다[T1–T2]. Hyundai의 분리는 더욱 깔끔하다: Pleos Connect는 Android Automotive 기반 인포테인먼트 시스템으로 2026년 2분기 출시 예정이며, Pleos Vehicle OS는 고성능 차량 컴퓨터와 존 컨트롤러 위에 구축된 차량 제어 OS다[T2–T3]. 한 회사가 둘을 별개의 브랜드로 분리한다는 사실 자체가 가장 좋은 증거다: 콕핏 화면에서 가장 멋져 보이는 시스템이 차를 제어할 수 있는 시스템은 아니다.

규칙 2: 도메인 OS ≠ 차량 OS.

NVIDIA DriveOS는 가속 컴퓨팅, 센서 통합, 자율주행, AI 콕핏을 위한 운영체제이자 런타임이며, DriveOS 6.0은 TÜV SÜD로부터 ISO 26262 ASIL D 인증을 받았다[T2]. 그것은 해당 분야에서 가장 강력한 제품 중 하나다. 그러나 그것이 관리하는 것은 DRIVE 컴퓨팅 도메인이지, 바디·열관리·에너지·섀시를 포함하는 차량 전체 기능이 아니다.

규칙 3: 런타임 ≠ OS.

AUTOSAR Adaptive는 동작을 정의한다: 실행 관리, 통신, 저장, 보안. 그것은 아래로는 POSIX 커널에, 위로는 OEM 통합에 의존한다. 그것을 ‘OS’라고 부르는 것은 TCP/IP를 네트워크 그 자체라고 부르는 것과 같다.

세 규칙은 하나의 함의를 공유한다: 이름은 기준이 아니다. OS라고 불리는 것이 차량 OS가 아닐 수 있고(BMW OS X는 아니다), OS라고 불리지 않는 것이 실제로는 차량 전체 플랫폼일 수 있다(Tesla는 자사 소프트웨어 스택에 OS 브랜드를 붙인 적이 없으며, Rivian도 마찬가지다). Toyota의 변화하는 어휘는 이 점을 더 날카롭게 한다: 2023년 4월 Toyota는 공식적으로 Arene을 ‘포괄적인 소프트웨어 플랫폼이자 차량 운영체제’라고 기술했지만[T1], 2025년 신형 RAV4와 함께 양산에 이르렀을 때 Toyota와 언론은 그것을 ‘소프트웨어 개발 플랫폼’이라고 부르는 경우가 더 많았다[T2]. 이것은 말장난이 아니다. 이는 제4장에서 다시 다루는 질문을 제기한다: 차량 OS의 제어점은 런타임에 있는가, 아니면 소프트웨어 라이프사이클에 있는가?

1.3 중국의 분류법: 국가 표준이 뒷받침하는 답

정의의 문제에서 중국은 다른 어떤 지역보다 더 멀리 나아갔다. 답을 국가 표준에 써넣었기 때문이다.

2019년, 전국자동차표준화기술위원회는 차량 운영체제 표준 체계를 발표하여, 차량 운영체제를 차량 제어 운영체제와 차량 탑재 운영체제의 두 부류로 나누었다[T1]. 차량 제어 OS는 다시 안전 차량 제어 OS(파워트레인, 섀시, 바디 — 가장 엄격한 실시간성 및 안전 요구사항을 가짐)와 지능형 주행 OS(주행 도메인 컨트롤러용)로 나뉘며, 차량 탑재 OS는 센터 콘솔, 계기판, T-box를 담당한다.

2026년 3월 31일, 이 분류법은 두 개의 권장 국가 표준이 되었으며, 같은 해 7월 1일부터 시행되었다[T1]:

• GB/T 47351-2026: 차량 제어 운영체제. Type I(지능형 주행 OS)과 Type II(안전 차량 제어 OS)를 정의한다.
• GB/T 47341-2026: 차량 탑재 운영체제의 기술 요구사항 및 시험 방법. 상업 번역본 발췌에 따르면, 이 표준은 차량 탑재 OS를 ‘지능형 커넥티드 차량에 주행 자동화 기능의 구현 이외의 서비스를 제공하는 소프트웨어의 집합’으로 정의하며, 계기판 경고처럼 높은 실시간성이 요구되는 시나리오를 지원하는 차량 탑재 OS에 대해서는 ASIL B 이상을 권장한다[T3: 상업 번역본, 표준 원문 아님].

공개 보도에 따르면, 기초 작성 기관 목록 자체가 하나의 산업 지도다: Huawei(Yinwang), Horizon Robotics, Qualcomm, NIO, BYD, Li Auto, Mercedes-Benz China, Volkswagen China 등이 포함된다[T2].

국가 표준의 가치는 운영체제를 브랜드가 아니라 기능 안전 속성에 따라 나눈다는 데 있다. 그러나 표준은 빈틈도 남긴다: 차량 제어 OS와 차량 탑재 OS는 있지만, ‘차량 OS’는 없다. 학계와 산업계에서 흔히 쓰이는 네 갈래 구분 — 안전 차량 제어 OS, 지능형 주행 OS, 지능형 콕핏 OS, 그리고 도메인을 가로지르는 ‘중앙 컴퓨팅 OS’ — 가운데 네 번째는 표준에 대응물이 없다. [추론] 그 빈틈이야말로 ‘차량 OS’라는 마케팅 개념이 사는 곳이며, 본고가 제어 평면이라는 개념으로 고정하려는 바로 그것이다.

1.4 그렇다면 차량 OS는 허위 명제인가?

가장 날카로운 반론을 먼저 테이블에 올려놓자: 브랜드 층을 벗겨내면, 이른바 차량 OS는 QNX + Linux + AUTOSAR + 하이퍼바이저 + 한 무더기의 미들웨어일 뿐이며 — 이 모든 것은 10년 전에도 존재했다. 그렇다면 무엇이 남는가?

우리의 답: 브랜드로서는 과장되었고, 공학적 실체로서는 실재한다. 남는 것은 어떤 단일 커널이 아니라, 여러 커널·도메인·칩을 하나의 자동차로 조직하는 것 — 통일된 서비스 계약, 크리티컬리티 수준을 가로지르는 오케스트레이션, 그리고 차량의 전 생애에 걸친 업데이트·검증 체계다. 다음 장에서 이를 분해한다.

---

2. OS들의 시스템: ‘차량 OS’를 분해하다

2.1 양산 중인 모든 차량 OS는 멀티 커널 조합체다

양산 중인 어떤 차량 OS든 열어 보면, 하나의 커널이 아니라 하나의 패밀리가 나온다.

NIO SkyOS는 ‘1+4+N’ 구조를 사용한다[T2]: ‘1’은 이기종 컴퓨팅을 관리하는 하이퍼바이저 SkyOS-H이고, ‘4’는 서로 다른 시나리오를 위한 네 개의 커널이다 — 차량 제어 커널은 형식 검증된 seL4 마이크로커널을, 콕핏 커널은 깊이 커스터마이즈된 Android를 기반으로 한다. ‘N’은 도메인 간 협조와 라이프사이클 업그레이드를 위한 자체 개발 미들웨어 컴포넌트다. [T3: 나머지 서브 커널 간의 정확한 역할 분담에 대해서는 출처마다 다르며, 여기서는 다루지 않는다.] SkyOS는 2024년 7월 27일에 전면 출시되었으며 NT3 플랫폼 모델에서 전체 범위로 실행된다[T2].

Li Auto HaloOS는 차량 제어 OS, 지능형 주행 OS, 통신 미들웨어의 3부 세트다[T2]. 2025년 3월 27일 Li Auto는 시스템을 오픈소스화하겠다고 발표했고, 4월에 0.1.0(안전 실시간 RTOS와 경량 통신 버스)을, 6월 30일에 1.0.0을 공개했으며, 이어서 가상화 엔진을 공개했다[T2]. Li Auto는 200명 이상의 인력과 10억 위안 이상을 투입했고, 2024년에 첫 양산 버전을 출하했으며, 칩 적응 기간을 3–6개월에서 4주로 단축했다고 밝힌다[T2, 회사 주장].

Hyundai Pleos는 차량 제어 OS와 콕핏 OS를 두 브랜드로 분리한다(1.2 참조). GB/T 47351은 차량 제어 OS 자체를 Type I과 Type II로 나눈다.

결론은 하나뿐이며, 그것이 본고의 첫 번째 테제다:

T1 | 차량 OS는 하나의 운영체제가 아니라, 차량 전체 제어 평면이 거버넌스하는 ‘OS들의 시스템’이다.

2.2 6계층 스택 모델: S0–S5

서로 다른 벤더의 제품을 하나의 그림에 넣기 위해, 우리는 6계층 스택 모델을 제안한다(그림 2.1).

그 주위에는 차량 위에 있지는 않지만 차량이 무엇을 할 수 있는지를 결정하는 외곽 고리가 있다: 클라우드, OTA, 데이터 루프, DevSecOps, 그리고 새롭게 부상하는 모델 라이프사이클.

그림 2.1 — OS들의 시스템: S0–S5 스택과 외곽 고리. 읽는 법: 차량 OS는 그림 속 어느 한 계층이 아니라 S1–S3에 대한 S4의 통일된 거버넌스다. S0는 S4가 얼마나 거버넌스할 수 있는지를 결정하고, 외곽 고리는 차량이 판매된 뒤에도 S4가 계속 진화할 수 있는지를 결정한다.

2.3 제어 평면의 세 부분: 계약, 오케스트레이션, 라이프사이클

‘제어 평면’은 네트워크 공학에서 빌려 온 말이다: 데이터 평면은 각 패킷을 전달하고, 제어 평면은 패킷이 어디로 가야 하는지를 결정한다. 자동차에서 데이터 평면은 S1–S3에서 실제로 실행되는 프로세스, 태스크, 신호이고, 제어 평면은 누가 어디에서, 어떤 우선순위로, 어떤 인터페이스를 통해 실행될 수 있으며, 어떤 조건에서 교체될 수 있는지를 결정하는 계층이다.

우리는 차량 제어 평면을 세 부분으로 분해한다:

1. 계약(Contract): 서비스 인터페이스, 차량 API, 신호 및 데이터 시맨틱. 그것은 ‘기능이 ECU의 물리적 위치로부터 디커플링된다’는 것을 약속한다 — HVAC 제어 서비스는 자신이 결국 어느 칩에서 실행되는지 신경 쓸 필요가 없다.
2. 오케스트레이션(Orchestration): 혼합 크리티컬리티 스케줄링, 격리 증명(freedom from interference), 기능 마이그레이션, 자원 중재. 그것은 ASIL D 제동 기능과 QM 등급 음악 재생이 서로 간섭하지 않고 하나의 칩을 어떻게 공유하는지를 결정한다.
3. 라이프사이클(Lifecycle): OTA, 롤백, 진단, DevSecOps, 그리고 이제는 모델 라이프사이클. 그것은 차량이 공장을 떠난 뒤 얼마나 더, 얼마나 빨리, 어떤 안전 논증 아래에서 변경될 수 있는지를 결정한다.

이 세 부분을 통해 보면, 1.2의 규칙들이 훨씬 분명해진다: 콕핏 OS는 콕핏 도메인에 대해서만 계약을 갖고, 도메인 OS는 강력한 오케스트레이션을 갖지만 한 도메인 안에서만 그러하며, 런타임은 계약을 규정하지만 차량 전체의 오케스트레이션이나 라이프사이클에 대해서는 책임지지 않는다. 계약, 오케스트레이션, 라이프사이클이 함께 차량의 주요 도메인을 포괄할 때에만 우리는 그것을 차량 OS라고 부른다.

이 정의에는 즉각적인 장점이 하나 있다: 관찰 가능하다는 것이다. 어떤 완성차 업체가 차량 OS를 가졌다고 주장한다면, 세 가지만 물으면 된다 — 그 차량 API는 어떤 도메인을 포괄하는가? 그 혼합 크리티컬리티 통합은 어떤 인증 수준에 도달했는가? 그 OTA는 어떤 도메인을 업데이트할 수 있는가? 제5장의 VOCM 점수 매기기는 이 세 질문을 여섯 개의 차원으로 펼친다.

2.4 과소평가된 사실: 하층의 극단적 집중, 상층의 극단적 분산

각 벤더의 제품을 S0–S5에 투영하면, 선명한 그림이 드러난다:

• S1에서 시장은 극도로 집중되어 있다. BlackBerry의 FY2026 연차 보고서는 QNX가 2억 7500만 대 이상의 차량에 탑재되어 있으며(전년 대비 2000만 대 증가), 45개 이상의 자동차 제조사와 협력하고, 상위 10개 OEM과 상위 25개 EV OEM 중 24개를 포괄한다고 공개한다[T1]. QNX OS for Safety와 QNX Hypervisor for Safety는 모두 ISO 26262 ASIL D 인증을 받았다[T1].
• S4에서 시장은 극도로 분산되어 있다. 10개가 넘는 완성차 업체가 각자 자체 차량 OS를 주장하며, 서로 호환되는 것은 하나도 없다.

이것은 D1의 2계층 수렴–발산 모델이 소프트웨어 계층에서 다시 나타난 것이다: 인프라는 하층에서 수렴하고, 제어 시맨틱은 상층에서 발산한다. 이는 또한 제7장에서 논하는 경쟁을 예고한다 — S1과 S2가 범용화될 운명이라면, 가치는 어디로 가는가?

---

3. 차보다 길이 먼저: E/E가 OS가 될 수 있는 것의 경계를 정한다

3.1 분산 아키텍처 위에서 차량 OS가 자라지 않는 이유

100개의 ECU를 가진 전통적인 자동차를 떠올려 보라. 각 ECU는 자체 OSEK 또는 Classic AUTOSAR를 실행하고, 각각 다른 Tier 1에서 오며, 각자 자체 소프트웨어 버전, 캘리브레이션 데이터, 플래싱 프로세스를 갖는다. 이런 자동차에서 차량 OS는 물리적으로 불가능하다 — 통일된 런타임이 살 곳도 없고, 서비스 계약이 ECU 경계를 넘을 만큼 넓은 채널도 없다.

이것이 본고의 두 번째 테제다:

T2 | 충분히 디커플링된 E/E 아키텍처 없이는 차량 OS도 없다. 소프트웨어 추상화의 상한은 물리 아키텍처가 정한다.

3.2 다섯 개의 인에이블러

E/E 아키텍처가 분산형에서 도메인 기반으로, 그리고 다시 존 + 중앙 컴퓨팅으로 이동하면서, 다섯 가지가 차량 제어 평면을 공학적으로 가능하게 만들었다(D1 제2장의 Bosch 6단계 프레임워크에 대응):

다섯 가지 가운데 앞의 네 가지는 제어 평면이 통일될 수 있는지를 결정하고, 다섯 번째는 그것이 신뢰될 수 있는지를 결정한다. 앞의 네 가지가 없으면 차량 OS는 없고, 다섯 번째가 없으면 차량 OS는 fail-soft 세계에 머문다 — 제6장에서 전개하는 논점이다.

3.3 세대 매트릭스: 각 E/E 세대가 담을 수 있는 계층

S0–S5를 E/E 세대와 교차시키면(그림 3.1) 단순한 패턴이 나타난다:

• 분산형: S1만(각 ECU의 자체 RTOS).
• 도메인형: S2와 S3가 나타난다 — 콕핏의 Android, 주행의 Linux / QNX, 도메인 내 SOA. 그러나 각 도메인은 제각각 돌아가며, 이 세대의 ‘차량 OS’ 주장 대부분은 마케팅이었다.
• 도메인 간 융합: 부분적인 S4가 나타난다 — 두세 개의 도메인이 계약을 공유하기 시작하고, 콕핏–주행 통합이 시도된다.
• 존 + 중앙 컴퓨팅: S4가 진정으로 공학적 현실이 된다.
• 중앙 + AI 네이티브: S5가 나타나기 시작한다.

그림 3.1 — 각 E/E 세대가 담을 수 있는 것. x축은 E/E 세대(분산형 → 도메인형 → 도메인 간 융합 → 존 + 중앙 → 중앙 + AI 네이티브), y축은 S1–S5다. 각 셀은 ‘불가능 / 부분적 / 양산 중 / 신흥’으로 표시된다. 읽는 법: S4의 ‘양산 중’ 셀은 존 + 중앙 열부터만 나타난다. 그 이전에 ‘차량 OS’라는 라벨이 붙은 제품 대부분은 실제로는 S3에 위치한다.

이 매트릭스는 반증 가능한 따름정리를 낳는다: 누군가 E/E 세대를 바꾸지 않고 차량의 주요 도메인을 포괄하는 제어 평면을 구축한다면, T2는 개정되어야 한다. 우리는 이를 개정 트리거 가운데 하나로 열거한다(제10장).

---

4. 인과의 역전: 소프트웨어가 하드웨어를 설계하기 시작할 때

4.1 ‘E/E가 OS를 지탱한다’에서 ‘OS가 E/E를 설계한다’로

제3장은 한 방향을 기술했다: E/E가 먼저, OS가 나중. 이것은 업계가 가장 자주 하는 이야기이며 — 덜 완전한 절반이다.

나머지 절반: 완성차 업체가 진정으로 차량 제어 평면을 구축하고 나면, 그것이 거꾸로 다음 세대 E/E 아키텍처를 결정하기 시작한다.

GM은 완성차 업체 스스로 공개한 드문 사례를 제공한다. GM은 자사의 2028 중앙 컴퓨팅 플랫폼이 10배의 OTA 역량, 1000배의 대역폭, 35배의 AI 컴퓨팅을 가져온다고 말한다[T1, 회사 주장]. 이 세 숫자 중 어느 것도 ‘더 좋은 하드웨어’에서 정의된 것이 아니다. 모두 소프트웨어가 해야 하는 일로부터 거꾸로 도출된 하드웨어 사양이다.

2026년 9월 Leapmotor의 Tech Day는 두 번째의, 더 상세한 사례를 제공했다. Leapmotor는 자사의 E/E 진화를 명확한 세대 계보로 제시한다:

• LEAP 3.0: 2023년에 출시된 ‘네잎클로버’ 중앙 통합 아키텍처.
• LEAP 4.0: D 플랫폼에서의 단일 칩 콕핏–주행 통합[T3].
• LEAP 5.0: 곧 나올 ‘네잎클로버 5.0’, 세 가지 변화[T2–T3]:
  • 제어: 중앙 통합 제어.
  • 전원: 차량 전체 48V 공급, 총 배선 500미터 미만, 하네스 중량 최대 50% 감소, 그리고 — 회사에 따르면 — 배선 발열 손실을 1/16로 감소.
  • 네트워크: 비대칭 대역폭 방식의 차량 전체 Ethernet — 다운스트림 10G, 업스트림 100M.
• 양산: 2027년 첫 모델[T2].

마지막 네트워크 항목은 잠시 멈춰 볼 만하다. 대칭 대역폭은 범용 네트워크의 논리다. 비대칭 대역폭은 네트워크가 데이터가 실제로 흐르는 방식 — 어느 방향이 대량의 트래픽을 나르고 어느 방향이 제어와 상태만 나르는지 — 을 중심으로 설계된다는 뜻이다. [추론] 이것은 소프트웨어와 데이터 흐름이 정의하는 네트워크 토폴로지다: 먼저 제어 평면이 데이터를 어떻게 옮겨야 하는지 알고, 그다음 배선을 어떻게 깔지 결정한다. 48V 공급과 더 짧은 하네스도 같은 논리를 따른다 — 중앙 제어는 전력 분배와 배선을 ‘기능마다 박스 하나’가 아니라 ‘하나의 두뇌와 몇 개의 존’을 중심으로 재조직할 수 있게 한다.

이것이 본고의 핵심 테제다:

T3 | 기능이 소프트웨어가 되면 인과가 역전된다: 소프트웨어 워크로드가 다음 세대 E/E 아키텍처를 설계하기 시작한다.

두 방향을 합치면 하나의 닫힌 루프가 된다(그림 4.1):

E/E 아키텍처 → 차량 제어 평면 → 워크로드 / 데이터 / AI → 차세대 E/E 아키텍처

우리는 이것을 아키텍처–OS 공진화 루프라고 부른다.

그림 4.1 — 아키텍처–OS 공진화 루프. 읽는 법: 루프의 상반부(E/E → OS)는 제3장의 다섯 인에이블러로 이루어진 ‘가능성 경계’이고, 하반부(OS → E/E)는 위 표의 여섯 부류 요구사항으로 이루어진 ‘역설계’다. 어떤 완성차 업체가 소프트웨어 정의 단계에 진입했는지는 OS 브랜드를 가졌는지가 아니라 하반부가 돌기 시작했는지로 판단한다.

분명히 해 두자면, 이 루프는 또 하나의 성숙도 사다리가 아니다. 본 시리즈에는 이미 AR0–AR5(설계된 시스템의 역량 문턱)와 AI²-ML(툴체인의 성숙도)이 있다. 공진화 루프는 등급이 아니라 인과 구조를 기술한다.

4.2 탈지능화 스펙트럼: 신뢰에 관한 의견 차이

루프 하반부의 가장 눈에 띄는 표현은 존 컨트롤러를 어디까지 ‘탈지능화(dumbing-down)‘하는가 — 핵심 제어 로직이 존에 남는가, 중앙으로 옮겨 가는가 — 이다.

한쪽 끝에 GM이 있다. GM의 존 ‘어그리게이터’는 명시적으로 ‘어떤 제어 로직도 실행하지 않는다’. 모든 지능 — 센서 퓨전, 제어 중재, 머신러닝 추론 — 은 중앙 컴퓨터에 있다[T1]. 이것은 완전 탈지능화 경로다.

다른 쪽 끝에 BMW가 있다. Neue Klasse는 주행 다이내믹스를 기존 ECU보다 10배 빠른 ‘Heart of Joy’라는 전용 고성능 컴퓨터에 둔다[T2]. 인포테인먼트, 자율주행, 기본 기능은 각각 자체 슈퍼브레인을 갖는다. 이것은 ‘핵심 제어는 중앙 밖에 둔다’ 경로다.

그보다 더 바깥에는 제어 로직이 많은 ECU에 분산된 전통적 아키텍처가 있다.

그림 4.2 — 존 컨트롤러의 탈지능화 스펙트럼. 왼쪽에서 오른쪽으로: 분산 ECU → BMW식 ‘핵심 제어를 독립 컴퓨팅에’ → GM식 ‘어그리게이터는 전달만 하고, 모든 지능은 중앙에’. 읽는 법: x축은 ‘얼마나 앞섰는가’가 아니라 ‘중앙 제어 평면이 ASIL D 실행 체인을 짊어지도록 얼마나 신뢰하는가’다.

[추론] 이 의견 차이는 하드웨어 토폴로지를 둘러싼 논쟁처럼 보이지만, 실질적으로는 신뢰의 문제다: 중앙 제어 평면의 결정론은 ASIL D 실행 체인을 맡길 만큼 이미 충분히 좋은가? GM의 답은 ‘그렇다’이고, BMW의 답은 ‘완전히는 아니다’이다. 표준 답은 없지만, 인과의 방향은 분명하다 — E/E 토폴로지를 결정하고 있는 것은 OS의 역량에 대한 판단이다.

4.3 관찰 가능한 대리 지표: OTA 입도

제어 평면의 포괄 범위는 외부에서 관찰하기 어렵다 — 완성차 업체는 자사의 차량 API 카탈로그를 공개하지 않는다. 그러나 관찰 가능한 것이 하나 있다: OTA가 어떤 도메인을 업데이트할 수 있는가.

신형 Toyota RAV4는 깔끔한 사례다: Arene으로 콕핏과 ADAS는 무선 업데이트가 가능하지만, 바디와 다이내믹스 기능은 아직 불가능하다[T2]. [추론] 이는 Arene의 계약이 아직 차량 제어 도메인을 포괄하지 않음을 보여 준다. 반대로, 제동이나 파워트레인 캘리브레이션을 무선으로 업데이트할 수 있는 완성차 업체는 안전 핵심 실행 체인을 라이프사이클 관리 아래로 가져온 것이다.

따라서 우리는 OTA 입도를 ‘제어 평면 계약 포괄 범위’의 외부 대리 지표로 사용하며, 이를 VOCM 차원 V5에서 활용한다(제5장). 완벽하지는 않다 — OTA가 가능하다는 것이 아키텍처가 잘 짜였다는 것과 같지는 않다 — 그러나 공개 정보로 검증할 수 있는 몇 안 되는 지표 가운데 하나다.

4.4 Conway의 법칙의 다른 얼굴: 하나의 조직이 납품하는 E/E와 OS

D3는 Tesla가 FSD 팀과 Optimus 팀을 통합한 것을 다루며, 조직 구조로 기술 아키텍처를 빚는 사례로 삼았다. E/E–OS 관계에 대해서는 더 새롭고 더 직접적인 공개 증거가 있다.

2026년 위임장 설명서(proxy statement)에서 Rivian은 Volkswagen Group과의 합작회사 RV Tech를 ‘소프트웨어, 전자 제어 장치 및 관련 네트워크 아키텍처에 중점을 둔 전기 아키텍처 기술 회사’로 정의한다[T1]. 다시 말해, 이 회사에서 E/E 토폴로지, ECU, 소프트웨어는 하나의 납품물이다.

Rivian의 FY2025 수치는 그 납품물의 경제적 무게를 보여 준다: 소프트웨어 및 서비스 매출총이익은 2024년 700만 달러에서 5억 7600만 달러로 증가했으며, 주로 합작회사와 관련된 ‘차량 전기 아키텍처 및 소프트웨어 개발 서비스’가 이를 견인했다[T1].

[추론] 이 숫자들의 의미는 금액이 아니라 가격 매김의 단위에 있다: ‘E/E + OS’는 이제 하나의 전체로서 가격이 매겨지고 거래될 수 있다. 아키텍처를 단독으로 팔 수 있게 되면, 그것은 더 이상 자동차의 부속품이 아니라 하나의 자산이다. 여기서 공진화 루프는 대차대조표상의 대응물을 얻는다.

Volkswagen Group은 한발 더 나아간다: 서로 다른 조직이 납품하는 두 개의 E/E 아키텍처를 동시에 운영한다 — 서반구의 RV Tech와 중국의 CEA. 5.5절에서 이 점으로 돌아간다.

4.5 하위 호환성: 루프의 대가이자 계약의 시금석

공진화 루프에는 간과하기 쉬운 부작용이 있다: 다음 세대 E/E가 소프트웨어 요구에 의해 재설계되는 동안에도, 이전 세대 차량은 여전히 도로 위에 있다. 그 차들은 새 소프트웨어를 계속 받을 수 있는가? 이는 ‘OTA가 가능한가?‘보다 더 엄격한 질문으로 이어진다:

차량 OS는 하위 호환될 수 있는가 — 이전 세대, 심지어 그 이전 세대 하드웨어의 차량이 새 세대 소프트웨어 역량을 무선으로 계속 얻을 수 있게 할 수 있는가?

우리의 답: 하위 호환성은 하드웨어–소프트웨어 디커플링이 진짜인지를 가리는 가장 엄격한 외부 테스트다. 다만 그것은 기능이 동등한지가 아니라 계약이 안정적인지로 판단해야 한다. 이유는 네 가지다.

첫째, 그것은 외부에서 테스트할 수 있는 유일한 형태의 디커플링이다. 모든 완성차 업체가 하드웨어와 소프트웨어를 디커플링했다고 말한다. 그러나 새 소프트웨어가 새 하드웨어에서만 실행된다면, 그 ‘디커플링’은 실제로는 ‘세대마다 다시 통합하기’다. 새 세대 소프트웨어를 같은 계약을 통해 오래된 하드웨어에 배포할 수 있을 때에만 디커플링이 증명된다.

둘째, 보유 차량 기반은 소프트웨어 경제의 분모다. 소프트웨어 구독, 유료 기능, 데이터 루프는 모두 업데이트를 받을 수 있는 차량의 수에 비례해 확장된다. 세대마다 오래된 차를 끊어 버리면, 소프트웨어 수익의 분모는 주기적으로 0으로 리셋된다.

셋째, 규제는 이미 호환성을 업데이트 프로세스에 써넣었다. UN R156 7.1.1항은 제조사의 소프트웨어 업데이트 관리 시스템이 일련의 프로세스를 포함하도록 요구하며, 그 가운데에는 업데이트의 대상 차량 식별(7.1.1.6), 배포 전 업데이트와 대상 차량 구성의 호환성 확인(7.1.1.7), 업데이트되는 시스템과 다른 시스템 간의 상호 의존성 식별(7.1.1.5), 업데이트 전후 RXSWIN 소프트웨어 식별자 유지(7.1.1.3)가 있다[T1]. 하위 호환성은 단순한 사용자 경험의 문제가 아니라, 업데이트 관리 시스템이 반드시 답해야 하는 항목이다.

넷째, 그것은 루프 안의 긴장을 드러낸다. 다음 세대 E/E가 이전 차량을 위해 같은 계약을 유지해야 한다면, 그 계약은 E/E의 진화 경로를 고착시킨다 — 바로 이곳에서 제어 평면의 가치와 비용이 함께 나타난다. 계약을 버리면 보유 차량 기반을 포기하게 되고, 계약을 지키면 새 아키텍처가 오래된 인터페이스를 짊어지게 된다.

그러나 하위 호환성이 기능 동등성을 의미할 수는 없다. 컴퓨팅, 센서 구성, 이중화는 OTA로 바꿀 수 없는 물리적 사실이다. D3는 이미 Tesla의 HW3와 새로운 FSD 버전 사이의 세대 단절을 다루었다: 하드웨어 격차가 너무 크면, 가장 공격적인 소프트웨어 정의 플레이어조차 오래된 하드웨어에서 모든 새 역량을 실행시킬 수 없다.

더 나은 판단 방식은 스마트폰 산업에서 빌려 온다 — 역량 계층화 아래의 계약 안정성:

Leapmotor의 Tech Day는 수준 3의 공개 사례를 제공했다: 그 LWM 월드 모델 주행 보조는 코드량을 90% 줄였다고 하며, 200, 640, 1,280 TOPS의 컴퓨팅 등급에 배포될 수 있고, LiDAR를 장착한 모든 차량 — 언론 보도에 따르면 약 35만 대의 기존 차량 — 에 무료 업그레이드와 평생 무료 사용을 약속한다[T3, 회사 주장]. [추론] ‘하나의 모델, 여러 컴퓨팅 등급’은 그 자체로 하위 호환성을 위한 설계다 — 역량의 차이를 ‘있음과 없음’에서 ‘많음과 적음’으로 바꾼다.

따라서 우리는 하위 호환성을 VOCM V2(하드웨어–소프트웨어 디커플링, 부록 B)의 채점 기준에 포함시킨다: 소프트웨어 역량이 하드웨어 세대를 넘어 제공될 수 있음이 입증될 때에만 V2는 4점 이상을 받을 수 있다. 이것이 일곱 번째 차원이 아닌 이유는, 본질적으로 독립적인 역량이 아니라 디커플링의 테스트이기 때문이다.

4.6 요약: 완성차 업체가 차량 OS를 가졌는지 알려면 하반부를 보라

이 장의 결론은 실용적인 테스트이기도 하다:

완성차 업체가 ‘차량 OS를 가졌는지’ 묻지 말라. 그 하반부가 돌기 시작했는지 물어라 — 다음 세대 E/E 사양이 현 세대 소프트웨어의 요구에 의해 정의되고 있는가?

그렇다면, 그 업체는 소프트웨어 정의 시대에 진입했다. 그렇지 않다면, OS 브랜드가 무엇으로 불리든, 여전히 ‘하드웨어가 정의하고 소프트웨어로 채우는’ 단계에 있다.

두 번째 질문이 있다: 이전 세대 차량은 여전히 같은 계약 위에 있는가? 하반부가 빨리 돌수록, 이 질문은 더 날카로워진다.

---

5. 2026년의 테이블: 누가 무엇을 하고 있으며, 어디까지 왔는가

5.1 ‘성숙했는가?‘를 묻지 말고 — ‘어느 계층이 성숙했는가?‘를 물어라

‘차량 OS는 성숙했는가?‘에는 답이 없다. 계층마다 한 시대씩 떨어져 있기 때문이다.

전체적인 판단:

2026년은 차량 OS가 ‘아키텍처적 야망’에서 ‘초기 양산 현실’로 넘어간 해다. 그것은 더 이상 슬라이드가 아니지만, Android / iOS 같은 안정된 산업 패러다임과는 아직 거리가 멀다.

양산 상태에 따라, 주요 플레이어는 네 개의 층으로 나뉜다. 이것은 서술적 분류이지 새로운 성숙도 사다리가 아님에 유의하라:

• M1 대규모 인프라(수억 대 / 수백만 대): QNX, Classic AUTOSAR, HarmonyOS 콕핏, Android Automotive.
• M2 양산 중인 OEM 전 도메인 제어 평면: MB.OS(CLA), SkyOS(NT3 플랫폼), HaloOS, BMW Neue Klasse, Tesla.
• M3 첫 출시 또는 부분 도메인 양산: Toyota Arene(RAV4; 바디와 다이내믹스는 아직 OTA 업데이트 불가)[T2]; Hyundai Pleos Connect(2026년 2분기 첫 출시, 인포테인먼트만)[T2–T3]; Rivian 2세대 플랫폼.
• M4 로드맵상에 있거나 재편 중: GM 중앙 컴퓨팅 플랫폼(2028, Cadillac Escalade IQ에서 데뷔)[T1]; Stellantis STLA Brain(원래 2024년 말까지 통합 예정이었으나, 현재는 2027년 STLA One 플랫폼과 처음 통합)[T1–T2]; Volkswagen Group × Rivian RV Tech 아키텍처(2026년 1분기 동계 시험 완료, 2027년 ID.EVERY1과 함께 데뷔)[T1]; Hyundai Pleos Vehicle OS와 그 중앙집중형 존 아키텍처(2030년 목표)[T3].

Volkswagen Group의 중국 아키텍처 CEA는 이미 이 층을 지났다: 2025년 말 안후이에서 양산에 들어갔고 2026년 1월 ID. UNYX 07과 함께 출시되었으며, 회사에 따르면 차량 전체 OTA를 지원한다[T1] — M3 사례다.

반복되는 패턴 하나는 주목할 만하다: M4의 거의 모든 완성차 업체가 자체의 원래 일정보다 늦어지고 있다. Volkswagen Group의 소프트웨어 자회사 CARIAD는 가장 주목받는 사례다: 납품하기로 되어 있던 통합 소프트웨어 플랫폼은 거듭 지연되었고, 회사는 2025년부터 대규모 구조조정과 인력 감축을 겪었으며[T3], 차세대 서방 아키텍처는 이제 RV Tech가 납품한다. [추론] 지연의 원인은 커널이나 칩인 경우가 드물고, 대개는 조직이다 — 수십 개의 기능별 사일로를 하나의 플랫폼 조직으로 바꾸는 것은 하이퍼바이저를 작성하는 것보다 훨씬 어렵다. 제9장에서 이 점으로 돌아간다.

5.2 브랜드가 아니라 역할로: 아홉 종류의 플레이어

차량 OS 테이블에는 전혀 다른 역할의 플레이어들이 앉아 있다. 브랜드로 순위를 매기면 이들이 뒤섞이고, 아키텍처적 역할로 분류하면 실제로 누가 누구와 경쟁하는지가 보인다.

5.3 VOCM: 여섯 차원으로 차량 제어 평면에 점수 매기기

역할 ①부터 ④까지의 플레이어를 하나의 잣대로 측정하기 위해, 우리는 **차량 OS 역량 매트릭스(VOCM)**를 제안한다. 이는 2.3절의 ‘계약 + 오케스트레이션 + 라이프사이클’을 여섯 개의 차원으로 펼친 것으로, 각 차원은 0–5점, 최대 30점이다. 채점 기준은 부록 B에 있다.

VOCM이 본 시리즈의 기존 프레임워크와 어떻게 관계되는가 — 이중 계산을 피하려면 이를 분명히 밝혀야 한다:

• AR0–AR5는 설계된 시스템(차량)의 아키텍처 역량 문턱, 주로 하드웨어 토폴로지와 시스템 통합을 측정한다. VOCM은 소프트웨어 제어 평면만을 측정한다. 둘은 직교한다: 어떤 완성차 업체는 AR에서 높고 VOCM에서 낮을 수 있으며, 그 반대도 가능하다 — 그리고 그 불일치야말로 분석적 가치가 있는 곳이다.
• AI²-ML은 아키텍처 툴체인의 성숙도를 측정한다 — 전혀 다른 대상이다. VOCM의 V2와 V5는 이름상 AI²-ML의 D2(HW/SW 디커플링) 및 D3(OTA)와 비슷하지만, 전자는 차 안의 소프트웨어를, 후자는 차를 설계하는 데 쓰이는 도구를 본다.
• VOCM은 성숙도 사다리가 아니며, ‘VOCM 레벨’을 정의하지 않는다. 그것은 6차원 역량 프로파일이다.

5.4 초기 평가

아래 표는 D2의 AR 스냅숏 점수(Snapshot 2026.1.31, 5개 차원 합계 25점 만점, 여기서는 인용만 하고 재채점하지 않음)와 대조한 VOCM의 초기 평가를 제시한다.

점수는 공개 출처에만 근거한다. 신뢰도 H / M / L은 증거의 강도를 반영한다: H = 대부분의 차원이 Tier 1–2 증거로 직접 뒷받침됨; M = 일부 차원이 회사 주장에 의존함; L = 대부분의 차원이 2차 출처나 추론에 의존함. D2에서와 마찬가지로, 플래그십 아키텍처는 양산 중이지만 차량군 대부분이 아직 전환되지 않은 완성차 업체에 대해서는, 표가 최신 양산 아키텍처를 채점하고 비고에 그렇게 밝힌다.

미채점(이번 회차 증거 불충분): Ford, Lucid, Geely, GWM, SAIC, Stellantis, Renault, Kia.

Leapmotor는 D2의 22개 OEM에 포함되지 않으므로, VOCM 점수는 있지만 AR 점수는 없으며 그림 5.1의 산점도에 나타나지 않는다. 점수의 근거:

• V1, V3: LEAP 3.0 이후의 중앙 통합 아키텍처; LEAP 4.0의 단일 칩 콕핏–주행 통합[T3].
• V2: 그 월드 모델은 세 개의 컴퓨팅 등급에 걸쳐 배포될 수 있으며, LiDAR를 장착한 기존 차량에 무료 제공이 약속되어 있다[T3, 회사 주장].
• V6: 차량–클라우드 AgentOS[T3].
• 나머지 차원은 2차 보도에 근거하며, 신뢰도는 낮다.

LEAP 5.0이 2027년에 양산에 이르면 점수를 갱신할 것이다.

비고:

• Mercedes는 CLA에서 처음 출시된 MB.OS를 기준으로 채점했다.
• Volkswagen Group은 중국 CEA 아키텍처(ID. UNYX 07)를 기준으로 채점했다. 공개 근거: 준중앙 컴퓨팅을 갖춘 존 제어, 제어 장치 약 30% 감소, 차량 전체 OTA 지원, 배터리 전기·하이브리드·내연기관 등 모든 파워트레인 포괄[T1]; 2년마다 새로운 CEA 세대 출시(2027년 2.0, A~D 세그먼트 모델 포괄), 주행 컴퓨팅은 XPeng의 Turing 칩과 CARIZON(Volkswagen과 Horizon Robotics의 합작회사) 솔루션 양쪽 모두로 계획되어 있다[T3]. CEA는 XPeng과 공동 개발되어 그 아키텍처 계보를 이어받았으므로, V1, V3, V4, V5에 관한 공개 정보가 빈약한 부분에서는 점수가 XPeng의 점수를 참조한다[추론] — 이는 부록 B의 ‘증거가 없으면 2점을 넘지 않는다’ 규칙에 대한 동일 계보 예외다. V6는 XPeng보다 1점 낮다: 주행 컴퓨팅이 두 공급업체에서 나오며, 공개 자료로는 XPeng과 같은 엔드투엔드 / VLA와 OS의 공동 스케줄링이 CEA에서 실행되고 있음을 확인할 수 없다.
• RV Tech 아키텍처는 아직 양산되지 않았으며(2027) 이번 회차에서는 채점하지 않는다. 출시 후 갱신할 것이다. 회사는 ‘강력한 모듈형 중앙 컴퓨터가 모든 차량 기능을 제어한다’고 말한다[T1]. 이것이 양산에서 유지된다면, 그 V1은 곧바로 4–5점에 이를 것이다.

그림 5.1 — E/E 아키텍처 × 차량 OS 역량. x축: D2의 AR 스냅숏 합계(/25); y축: VOCM 합계(/30). 완성차 업체당 점 하나; 속이 빈 점은 낮은 신뢰도를 나타낸다. 점선은 등비 대각선(각 척도 최댓값에 대해 같은 비율)이며, 음영 띠는 표본 추세선 ±2.5점(VW CEA를 제외하고 적합)이다. 읽는 법: 추세 대역 안에 있는 완성차 업체는 제어 평면이 E/E와 보조를 맞춰 진화하고 있다. 대역에서 뚜렷이 벗어난 점들이야말로 의문을 제기할 가치가 있다.

5.5 도표 읽기: 네 가지 발견

발견 1: AR과 VOCM은 밀접하게 함께 움직이지만, 제어 평면은 반걸음 뒤처져 있다. VW CEA를 제외하면, 그림 5.1의 13개 점은 거의 한 직선을 이룬다: 적합된 기울기는 약 1.2로 — 두 척도 최댓값의 비율(30/25)과 정확히 같다 — 모든 점이 추세선에서 3점 이내에 있다. 이것 자체가 T2의 증거다 — E/E가 도달한 곳에, 제어 평면도 대략 도달해 있다. 그러나 추세선은 전체적으로 등비 대각선보다 약 3점 아래에 있다: 각 척도의 최댓값으로 정규화하면, 업계의 제어 평면은 대체로 E/E보다 약 10분의 1 뒤처져 있다. [추론] 이는 공진화 루프와 일치한다: 그 상반부(E/E가 가능성의 경계를 정하는 것)는 수년간 돌아왔지만, 하반부(소프트웨어가 E/E를 역으로 설계하는 것)는 이제 막 돌기 시작했다. AR 점수가 15 미만인 완성차 업체 가운데 VOCM이 15를 넘는 곳은 VW CEA뿐이며, 그 이유는 발견 4에서 설명한다.

추세 대역 아래에는 ‘E/E가 제어 평면을 앞서는’ 완성차 업체들이 있다: 가장 뚜렷한 것은 Toyota이며, Rivian은 대역의 아래쪽 가장자리에 있다. [추론] Toyota에게 이는 하드웨어 아키텍처가 먼저 움직였고 Arene의 계약은 아직 따라잡지 못했다는 뜻이다 — 4.3의 OTA 입도 관찰과 일치한다. Rivian은 다르다: 그 E/E는 표본 가운데 가장 공격적인 축에 속하지만, 소프트웨어 스택에 관한 공개는 가장 빈약하다. 낮은 점수는 역량의 결여보다는 증거의 결여(낮은 신뢰도)를 반영한다.

발견 2: 중국 신흥 업체들은 V4와 V2에서 전반적으로 높은 점수를 받는다. Li Auto의 HaloOS 오픈소스화, Huawei의 크로스 브랜드 생태계, Xiaomi의 ‘사람–차–집’ 생태계는 모두 개방을 전략으로 다룬다. [추론] 이는 표준 우선, 공급망 공동 구축이라는 중국의 환경에 부합한다 — 인터페이스가 표준화되면, 개방의 비용은 떨어지고 이익은 올라간다.

발견 3: 같은 AR 층 안에서 Mercedes가 가장 높은 제어 평면 점수를 갖는다. Mercedes와 BYD는 D2에서 모두 AR2.5(17점)이지만, MB.OS의 초기 VOCM(20)은 BYD(17)보다 3점 높아 추세 대역의 위쪽 가장자리에 위치한다. 이는 신중하게 읽어야 한다: D2의 AR 스냅숏은 그룹 전체를 채점하는 반면, MB.OS는 단일 모델 CLA에 처음 도입되었다. [추론] 더 그럴듯한 설명은 Mercedes가 플래그십 모델에서 제어 평면을 먼저 구축하고 E/E는 이후 모델에서 따라잡게 하고 있다는 것이다 — 이는 공진화 루프의 하반부가 돌기 시작할 때의 모습 그대로다. 이것이 맞다면, 차세대 모델은 뚜렷이 더 높은 AR을 보일 것이다. 그렇지 않다면, MB.OS의 계약 포괄 범위가 과대평가된 것이다(실제로 어떤 안전 핵심 액추에이터가 MB.OS 아래에 있는지는 공개되지 않았다).

발견 4: Volkswagen Group은 차량 OS 질문에 ‘하나의 완성차 업체, 두 개의 아키텍처, 두 개의 외부 파트너’로 답했다. 이는 표본에서 가장 특이한 점이며 별도로 논의할 가치가 있다.

• 중국의 CEA: Volkswagen Group China Technology Company, CARIAD China, XPeng이 공동 개발했으며, 콘셉트에서 양산까지 18개월밖에 걸리지 않았다 — 회사에 따르면 Volkswagen Group이 완전히 새로운 전자 아키텍처에서 달성한 가장 빠른 일정이다. 일부 핵심 프로젝트에서 신모델 개발 비용이 최대 50% 감소한다[T1, 회사 주장].
• 서방의 RV Tech: Rivian과의 합작회사로, 미국, 캐나다, 스웨덴, 세르비아, 베를린에 걸쳐 1,500명 이상의 직원을 둔다[T1].

두 경로에는 공통점이 하나 있다: Volkswagen Group의 신세대 차량 제어 평면 어느 것도 그룹 자체의 소프트웨어 자회사가 독자적으로 납품하지 않았다. 둘 다 제어 평면에서 이미 앞서 있던 신흥 업체와 공동 구축되었다.

[추론] 그 의미는 Volkswagen을 넘어선다. 이는 차량 제어 평면이 이제 기업 간에 ‘수입’될 수 있음을 보여 준다 — 커널이나 미들웨어를 사는 것이 아니라, 완전한 E/E 토폴로지, 소프트웨어 스택, 개발 방법을 들여옴으로써. CEA의 18개월은 루프의 하반부를 ‘빌려 와서’ 돌게 할 수 있는 속도다. 대가도 마찬가지로 분명하다: 하나의 그룹이 서로 다른 인터페이스 체제(중국 국가 표준과 서방 표준 생태계)를 마주한 두 개의 아키텍처, 두 개의 파트너, 두 벌의 소프트웨어를 유지해야 한다. 각 척도의 최댓값으로 정규화하면, CEA의 초기 VOCM(20/30)은 그룹 전체 AR 스냅숏(13/25)보다 뚜렷이 높으며, 그림 5.1에서 추세 대역보다 훨씬 위에 있는 유일한 점이다. 그 일부는 범위의 문제다 — Mercedes와 마찬가지로 AR은 그룹 전체를 채점하고 VOCM은 최신 아키텍처를 채점한다. [추론] 그러나 주된 이유는 제어 평면이 동일 계보의 아키텍처와 함께 통째로 수입되어, 그룹 전체의 E/E보다 먼저 도달했기 때문이다. CEA는 중국을 위한 하나의 새 아키텍처일 뿐이며, 그것과 유럽에 있는 그룹의 기존 플랫폼 사이의 격차가 추적해야 할 더 중요한 대상이다. RV Tech가 양산에 이르면, Volkswagen Group은 표본에서 두 시장 각각에 별도의 존 + 중앙 컴퓨팅 제어 평면을 가진 유일한 레거시 완성차 업체가 될 것이다. 그것이 과도기적 형태인지, 아니면 다국적 완성차 업체의 표준이 될 것인지는 7.6절의 질문이다.

---

6. 스트레스 테스트: 콕핏은 OS가 앱을 실행할 수 있는지를, 자율주행은 차를 운행할 수 있는지를 시험한다

6.1 자율주행은 OS가 아니다

이는 군더더기처럼 들리지만, 업계는 종종 둘을 혼동한다 — 어떤 회사의 주행 소프트웨어 스택을 그 회사의 ‘OS’라고 부르는 식으로.

T4 | 자율주행은 차량 OS가 아니다. 그것은 제어 평면 위에서 실행되는 가장 까다로운 워크로드이며 — ‘차량 OS’가 그 이름에 걸맞은지를 가리는 최고의 스트레스 테스트다.

한 문장으로:

콕핏은 OS가 애플리케이션을 실행할 수 있는지를 시험하고, 자율주행은 차량 OS가 차량을 운행할 수 있는지를 시험한다.

6.2 고장 결과의 사다리

왜 자율주행이 스트레스 테스트인가? 그것은 고장의 비용을 한 단계씩 끌어올려, 결국 그것을 받아 줄 인간이 아무도 남지 않게 만들기 때문이다.

그림 6.1 — 차량 OS의 스트레스 테스트로서의 자율주행. 읽는 법: 왼쪽에서 오른쪽으로 고장의 비용은 ‘불편’에서 ‘차량 수준 폴백’으로 올라가고, 제어 평면에 대한 요구는 ‘재부팅할 수 있다’에서 ‘부분 고장 상태에서도 여전히 안전하게 작동함을 증명할 수 있다’로 올라간다. L3와 L4 사이의 단이 가장 높다 — 바로 그곳에서 인간이 폴백 체인을 떠난다.

이것이 DD-08 운전자의 퇴장이 논한 분수령이다: 운전자가 퇴장하면, 이중화 하드웨어, safety case, 런타임 모니터링, OTA 검증은 더 이상 부가 요소가 아니라 시스템의 역량 그 자체다. 본고는 DD-08에 하나의 관점을 덧붙인다: 이 모든 요구사항은 결국 제어 평면에 떨어진다. 이중화된 컴퓨팅 유닛에는 그 사이를 전환할 수 있는 오케스트레이션 계층이 필요하다. OTA에는 ‘이 업데이트가 safety case를 깨뜨리지 않는다’는 것을 증명할 수 있는 라이프사이클 체계가 필요하다. 런타임 모니터링에는 AI 워크로드를 격리하고, 관찰하고, 필요할 때 인수할 수 있는 결정론적 기반이 필요하다.

[추론] 따라서 L3 이상의 책임을 한 번도 짊어져 본 적이 없는 ‘차량 OS’는 아직 그 차량 전체적 성격을 시험받지 않은 것이다. 그것은 콕핏, 바디, 에너지에서 뛰어날 수 있지만, 안전 핵심 실행 체인이 같은 제어 평면 안으로 들어와 fail-operational 테스트를 거칠 때에만 ‘차량’이라는 단어가 진정으로 적용된다.

6.3 OS의 새로운 직무: ‘자원 관리’에서 ‘격리 증명’으로

전통적인 운영체제의 핵심 직무는 자원 관리다: CPU, 메모리, I/O의 할당. 혼합 크리티컬리티 자동차 컴퓨팅 플랫폼에서는 이 직무의 성격이 바뀐다 — OS는 서로 다른 크리티컬리티의 워크로드가 서로 간섭하지 않음을 증명해야 한다.

2026년에 이것은 이미 양산 현실이다:

• Qualcomm은 Snapdragon Ride Flex를 ‘업계 최초로 상용화된 혼합 크리티컬리티 플랫폼’이라고 부르며, 단일 SoC에서 QM, ASIL B, ASIL D 워크로드를 실행하고, 전 세계 8개 프로그램에서 양산 중이다[T2, 회사 주장].
• NVIDIA Halos OS는 하이퍼바이저를 사용해 안전 핵심 기능을 AI 워크로드로부터 격리하며, 안전 인증된 CUDA와 TensorRT를 제공한다[T2].

공학적으로 ‘격리 증명’은 하이퍼바이저에서의 공간적·시간적·메모리 대역폭 파티셔닝과, 그 파티션에 대한 형식적 또는 인증 등급의 논증을 의미한다. NIO가 차량 제어 커널에 형식 검증된 seL4 마이크로커널을 사용하는 것[T3]은 ‘증명’을 수학에까지 밀어붙이려는 시도다.

6.4 엔드투엔드 모델이 OS에 요구하는 것

엔드투엔드 주행 모델과 VLA(vision–language–action) 모델의 확산은 제어 평면에 세 가지 새로운 압력을 가한다:

1. 메모리 대역폭 경합: 대형 모델 추론은 DDR 대역폭을 대량으로 소비하며, 같은 칩 위의 실시간 태스크를 압박할 수 있다.
2. 지연 지터: GPU 추론 시간의 불확실성은 본질적으로 제어 루프의 결정론과 충돌한다.
3. 가속기 선점: 주행 모델과 콕핏 대형 모델이 가속기를 공유할 때, 누가 우선권을 갖는가?

NVIDIA의 Halos SDK는 명시적으로 ‘결정론적 스케줄링, 제로 카피 프로세스 간 통신’을 판매한다[T2] — 이 문제들이 연구 주제에서 제품 요구사항으로 옮겨 갔다는 신호다.

6.5 콕핏–주행 통합: 격리가 선택에서 전제로 바뀐다

콕핏과 주행 기능이 같은 칩이나 같은 중앙 컴퓨터에 놓이면, 그것들은 같은 하드웨어 고장 도메인에 들어간다. 분산 아키텍처에서는 둘이 물리적으로 분리되어 있으므로 콕핏 크래시가 제동에 영향을 줄 수 없다. 통합 아키텍처에서는 그 ‘자연적 격리’가 사라지며, 제어 평면이 소프트웨어로 그것을 다시 구축해야 한다.

[추론] 콕핏–주행 통합은 격리를 ‘선택적 최적화’에서 ‘안전 전제’로 바꾼다. 이것이 혼합 크리티컬리티 통합(V3)이 VOCM에서 독립된 차원인 이유다.

6.6 Robotaxi: 이중 채널 구조

L4 무운전자 플릿에서는 [추론: Waymo, Baidu Apollo, Pony.ai, WeRide 등이 자사 소프트웨어 스택의 구현 방식에 대해 공개한 내용은 제한적이다] ‘AI 메인 스택 + 독립적인 안전 모니터와 이중화 컴퓨팅’이 흔한 구조다 — 메인 스택이 주행하는 동안, 두 번째 채널이 그것을 지속적으로 감독하고, 이상 시 차량을 최소 위험 상태로 가져간다. 이 이중 채널 구조는 소프트웨어로 표현된 fail-operational 계약이며, 제어 평면의 오케스트레이션 직무의 가장 극단적인 형태다.

---

7. 문 앞의 수평 플랫폼: Google, 칩 제조사, 그리고 인터페이스를 둘러싼 싸움

7.1 새로운 전장

스마트폰 시대에 Apple과 Google은 운영체제를 집어삼켰고, 단말 제조사들은 하드웨어와 브랜드로 후퇴했다. 지난 10년간 자동차 산업의 합의는 이것이었다: 완성차 업체는 자동차에서 그런 일이 일어나도록 절대 내버려 두지 않을 것이다.

2026년, 그 합의는 첫 번째 실질적 도전에 직면한다.

T6 | 업계가 실제로 표준화하고 있는 것은 ‘하나의 자동차 OS’가 아니라 차량 API, 데이터 모델, 런타임 계약이다. 커널은 범용화되고 있으며, 제어점 C3(OS)는 C2(실리콘)와 C4(미들웨어)에 의해 양쪽에서 압착되고 있다.

7.2 Google: Android가 콕핏 밖으로 걸어 나오다

2026년 3월 24일, Google은 Android Developers Blog에 Android Automotive OS의 SDV 확장(AAOS SDV)을 직설적인 제목 아래 발표했다: Beyond Infotainment[T2]. 검증된 사실:

• 형태: ‘경량의 빠르게 부팅되는 헤드리스 Android 기반(SDV Core, Microdroid와 유사)‘으로, VirtIO를 지원하는 하이퍼바이저 위에서 가상 머신으로 실행된다. 서비스 인터페이스는 Google의 VSIDL과 protobuf로 정의되며, SOME/IP, VirtIO 소켓, Ethernet 등을 통해 외부 ECU에 연결된다. 콕핏 측에는 SDV Gateway가 위치한다[T1: source.android.com, 문서 최종 갱신 2026-09-24, Android 17 이상 대상].
• 포괄 도메인: Google은 ‘Core Compute, Body Controls, and Cluster domains’를 열거하며, 예시 기능으로 시트 액추에이터, 계기판, 공조, 조명, 카메라, 미러, 텔레메트리를 든다[T2]. 공식 자료는 섀시나 ADAS를 언급하지 않는다.
• 안전 경계: 문서도 블로그도 어떠한 ASIL 주장도 하지 않는다. 유일한 안전 관련 내용은 Display Safety(속도와 경고등 같은 계기판 표시)와, 안전 설계 툴체인 및 참조용 Safety Monitor다[T1–T2].
• 채택자: Qualcomm은 CES 2026에서 Snapdragon Digital Chassis 위에 사전 통합된 AAOS SDV 스택을 발표했다. 첫 양산 프로그램은 Renault의 경상용차로, 2026년 말 양산 예정이다[T2]. Google은 AAOS SDV가 2026년 안에 AOSP에 들어갈 것이라고 말한다.

[추론] 이 사실들은 명확한 경계선을 그린다: 수평 플랫폼은 콕핏을 넘어 바디 편의 및 계기판 도메인으로 건너왔지만, 여전히 QM에서 낮은 ASIL의 영역 안에 머물러 있으며, 섀시·제동·조향·자율주행의 안전 핵심 실행 체인에는 아직 닿지 않았다. 이 선이 계속 아래로 내려가는지는 향후 5년간 지켜볼 가장 중요한 산업 신호 가운데 하나다(제10장, 개정 트리거 4).

7.3 칩 제조사: C2가 C3를 흡수한다

Google이 위에서 아래로 누른다면, 칩 제조사는 아래에서 위로 감싼다.

• NVIDIA: DriveOS(ASIL D 인증) + Halos OS(AI 워크로드를 안전 기능으로부터 격리하는 하이퍼바이저) + Halos SDK(결정론적 스케줄링, 제로 카피 IPC)[T2]. GM의 2028 중앙 컴퓨팅 플랫폼은 NVIDIA Thor 기반이다[T1].
• Qualcomm: Ride Flex 혼합 크리티컬리티 플랫폼 + 사전 통합된 AAOS SDV 스택[T2].

[추론] 칩 제조사가 납품하는 것은 더 이상 칩이 아니라 ‘칩 + 하이퍼바이저 + 안전 인증 런타임 + 미들웨어 일부’의 패키지다. 완성차 업체에게 칩을 고르는 것은 점점 더 S1과 S2 — 심지어 S3의 일부 — 를 동시에 고르는 것을 의미한다. D1의 7개 제어점 가운데, 이것은 C2(SoC)가 C3(OS)를 흡수하는 것이다.

7.4 미들웨어와 ‘Vehicle OS 벤더’: C4의 확장

또 하나의 힘은 미들웨어와 제3자 Vehicle OS 벤더에서 온다.

• Applied Intuition은 완성차 업체에 Vehicle OS를 공급한다. 2026년 5월 Stellantis는 STLA Brain에 관해 이 회사와의 협력 확대를 발표했다[T1]. 회사는 세계 상위 20개 자동차 제조사 가운데 18곳이 자사 솔루션을 사용한다고 말한다[T2, 회사 주장].
• Eclipse S-CORE: 2025년 6월, 11개 기업이 오픈소스 SDV 협력에 관한 VDA 양해각서에 서명했다(BMW, Continental, ETAS, HELLA, Mercedes-Benz, Qorix, Bosch, Valeo, Vector, Porsche, ZF)[T1]. 2026년 1월 7일 VDA 보도자료에 따르면, 서명사는 32곳으로 늘었다[T1–T2]. S-CORE 0.5는 2025년 11월에 공개되었으며, 참조 플랫폼은 QNX와 Qualcomm 하드웨어에서 처음 시연되었다[T2].

[추론] 어떤 유럽 완성차 업체가 S2에 오픈소스 S-CORE를, S1에 QNX를, 격리에 칩 제조사의 하이퍼바이저를 쓰고, S4의 일부에는 제3자 Vehicle OS를 산다면, 그 업체가 실제로 여전히 소유하는 것은 무엇인가? 답: 차량 시맨틱, 안전 책임, 그리고 통합·검증·데이터 루프 운영의 역량.

7.5 싸움은 커널이 아니라 인터페이스를 둘러싼 것이다

세 힘을 합치면 과소평가된 사실이 드러난다: 모든 당사자가 실제로 다투고 — 실제로 표준화하고 — 있는 것은 인터페이스 계층이다.

[추론] 이 노력들은 함께 하나의 결론을 가리킨다: 표준화로 향하고 있는 것은 ‘하나의 자동차 OS’가 아니라 ‘차량 API + 데이터 모델 + 런타임 계약’이다. 이는 2.3절의 제어 평면 세 부분 가운데 첫 번째 — 계약 — 에 정확히 대응한다.

이로부터 가치가 어디에 있는지에 관한 따름정리가 나온다:

계약 계층은 수렴하고 있다. 오케스트레이션과 라이프사이클이 완성차 업체 차별화의 남은 공간이다.

7.6 수평 플랫폼 대 OEM 제어 평면: 종국은 무엇인가?

그렇다면 업계는 수평적 차량 OS로 수렴할 것인가, 아니면 완성차 업체가 차량 제어 평면을 지킬 것인가?

[추론] 우리의 판단: 양자택일이 아니다. 하층의 인프라(S1, S2와 계약 계층 표준)는 계속 수렴할 것이고, 차량 시맨틱, 안전 책임의 소유, 브랜드 차별화(오케스트레이션, 라이프사이클, 데이터 루프)는 계속 발산할 것이다. 이것은 D1의 2계층 수렴–발산 모델이 소프트웨어 계층에서 두 번째로 다시 나타난 것이다.

네 종류의 완성차 업체가 네 가지 다른 종국에 이를 것이다:

1. 수직 통합자(Tesla, Huawei, NIO): C2, C3, C4를 함께 소유하며, 제어 평면은 전적으로 자기 것이다. 이들은 T6에 대한 가장 강력한 반례다 — 이들에게 OS는 범용화되는 무언가가 아니라 해자의 일부다.
2. 연합형 제어 평면: 지역별로, 심지어 파트너별로 구축된 여러 제어 평면이 브랜드, 공급망, 기반의 일부를 공유하지만, 단일 글로벌 소프트웨어 스택을 추구하지는 않는다. Volkswagen Group이 오늘날 가장 분명한 사례다: 중국에서는 XPeng과 공동 구축한 CEA, 서방에서는 Rivian과 공동 구축한 RV Tech(5.5의 발견 4 참조). 장점은 속도와 현지 적합성이다 — 양산까지 18개월, 중국 국가 표준 및 현지 주행 생태계와의 직접적 정합. 리스크는 규모의 경제가 쪼개진다는 것이다: 두 개의 아키텍처는 두 개의 검증 체제, 두 개의 OTA 운영, 두 개의 인재 파이프라인, 그리고 장기적 통합 비용을 뜻한다. [추론] 차량 OS의 종국이 반드시 ‘모든 것을 지배하는 하나의 커널’일 필요는 없다. 연합형 제어 평면은 중국과 서방의 표준이 갈라지는 상황에 직면한 다국적 기업에게 합리적 선택일 수 있다 — 그러나 그 연합이 다음 세대에 하나로 수렴할 수 있는지가, 이 경로가 결국 ‘과도기’로 끝날지 ‘부채’로 끝날지를 결정한다.
3. 플랫폼 소비자: S4에서조차 제3자 솔루션(Applied Intuition, Google, 칩 제조사 패키지)을 사며, 차별화를 브랜드, 디자인, 채널에 집중한다.
4. 제어 평면 수출자: 자체 차량 제어 평면을 — E/E 토폴로지 및 개발 방법과 함께 — 하나의 제품으로서 다른 완성차 업체에 수출한다. 이는 2025–2026년에 등장한 가장 새로운 형태이며, 그 주인공은 거의 모두 중국 완성차 업체다:
   • XPeng은 Volkswagen과 CEA를 공동 구축했다(5.5);
   • 2026년 Tech Day에서 Leapmotor는 자사 전자 시스템이 이제 다섯 파트너와 협력하고 있으며, FAW, Stellantis 등에 차량 수준 기술 역량을 제공하고 있다고 말했다[T3];
   • Huawei의 HarmonyOS 콕핏과 Qiankun은 25개 브랜드를 포괄한다[T2].

[추론] 네 번째 형태는 T6가 그리는 그림을 바꾼다. 제어점 C3는 칩 제조사(C2)와 미들웨어 / 수평 플랫폼(C4)에 의해 위아래에서 압착될 뿐만 아니라, 또 다른 종류의 완성차 업체에 의해 옆에서도 쟁탈되고 있다. 수입자에게 제어 평면을 들여오는 것은 구축하는 것보다 훨씬 빠르다: CEA는 콘셉트에서 양산까지 18개월이 걸렸다. 수출자에게 제어 평면은 두 번째 수익 곡선이자 규모의 증폭기가 된다 — Leapmotor가 주장하는 90%의 플랫폼 공용률이 바로 제어 평면을 수출용으로 복제 가능하게 만드는 것이다[T3, 회사 주장]. Stellantis가 Applied Intuition(제3자 Vehicle OS) 및 Leapmotor(차량 수준 기술)와 동시에 협력한다는 것은, 하나의 완성차 업체가 서로 다른 시장과 모델에서 ‘플랫폼 소비자’이자 ‘제어 평면 수입자’일 수 있음을 보여 준다.

네 형태 가운데 어느 것도 우월하지 않다. 각각은 제어점이 어디에 있어야 하는지에 대한 서로 다른 베팅이다.

---

8. AI가 운영체제에 들어올 때: 모래시계와 결정론적 거버넌스

8.1 차에 대형 모델을 넣는 것은 AI가 OS에 들어오는 것이 아니다

‘AI와 차량 OS’에 관한 가장 흔한 — 그리고 가장 얕은 — 논의는 어떤 대형 모델이 차 안에 있는가에 관한 것이다: Gemini, GPT, DeepSeek, Pangu, 또는 Grok. 그것은 애플리케이션으로서의 AI다. 진짜 변화는 더 깊은 곳에서 일어나며, 세 단계로 온다.

단계 B에는 간과하기 쉽지만 파급력이 큰 따름정리가 있다: 모델이 일급(first-class) 소프트웨어 산출물이 된다. 오늘날 OTA 업데이트는 ‘소프트웨어 패키지 v3.7’을 전달한다. 내일은 ‘소프트웨어 + 모델 + 정책 + 에이전트 그래프 + 안전 엔벨로프’의 묶음을 전달할 것이다. 라이프사이클 관리의 대상이 코드에서 확률적 산출물로 확장된다.

업계는 이미 단계 B를 향해 움직이고 있다:

• Mercedes의 MBUX Virtual Assistant는 Microsoft와 Google 양쪽의 AI를 통합하며, Gemini 위에 자동차 AI 에이전트를 구축한다[T2].
• Hyundai의 Gleo AI 에이전트는 Pleos Connect와 함께 도입된다. Hyundai는 이 전환을 SDV에서 ‘AIDV’(AI 정의 차량)로의 이동으로 규정한다[T2].
• NIO는 SkyOS를 ‘AI를 위한 전 도메인 차량 운영체제’라고 부른다[T2].
• 2026년 Tech Day에서 Leapmotor는 ‘차량–클라우드 AgentOS’를 출시했다: 차량의 코어 에이전트는 저지연 및 프라이버시에 민감한 태스크를 처리하고, 클라우드 에이전트는 복잡한 추론과 장기 기억을 처리한다[T3]. [추론] 이것은 ‘신뢰와 지연에 따라 지능을 나누는’ 설계이며 — 제어 평면의 외곽 고리(클라우드, OTA, 데이터 루프)에 깔끔하게 대응한다: 에이전트 자체가 ‘차 안의 결정론적 부분’과 ‘클라우드의 확장 부분’으로 나뉜다.
• 2025년 10월, 중국 자동차 기초 소프트웨어 생태계 위원회(AUTOSEMO)는 중국 자동차 기초 소프트웨어 발전 보고서 6.0을 발표하여 AIOS에 초점을 맞추고, ‘컴퓨팅 추상화 — 데이터 융합 — 기능 서비스화’의 아키텍처를 제안했다[T2].

8.2 OS는 더 얇아질 것인가, 두꺼워질 것인가?

AI는 운영체제를 흡수할 것인가? 두 견해 모두 일리가 있다.

얇아진다는 쪽: 인터랙션, 애플리케이션 오케스트레이션, 기능 로직이 대형 모델과 에이전트에 흡수되고 있다. 한때 하드코딩해야 했던 HMI 흐름, 메뉴 계층, 규칙 엔진이 의도를 이해하는 모델로 대체되고 있다. 엔드투엔드 주행 모델은 예전에 인지, 예측, 계획 모듈로 나뉘어 있던 미들웨어도 흡수했다. 이렇게 보면, OS의 상반부는 얇아지고 있다.

두꺼워진다는 쪽: 모델이 불확실할수록, 결정론적 골격이 더 필요하다. 자원 격리, 시간적 결정론, 안전 모니터링, 증명 가능한 폴백 경로, 그리고 ISO/PAS 8800이 요구하는 AI 라이프사이클 증거 체인은 모두 OS 계층으로 가라앉아야 한다. NVIDIA는 ‘안전 핵심 기능을 AI 워크로드로부터 격리하는 하이퍼바이저’를 Halos OS의 핵심 셀링 포인트로 삼는다[T2]. 이렇게 보면, OS의 하반부는 두꺼워지고 있다.

우리의 답: 둘 다 동시에 일어나고 있다.

T5 | AI는 차량 OS를 없애지 않고, 양극화할 것이다: 상반부(인터랙션, 오케스트레이션)는 얇아지고, 하반부(결정론, 격리, 증명)는 두꺼워지며, 그 사이의 서비스 계약은 잘록한 허리가 된다. 확률적 지능은 결정론적 거버넌스 안에서 실행되어야 한다.

그림 8.1 — 모래시계: AI는 차량 OS를 어떻게 재편하는가. 넓은 상부: 모델에 흡수되는 인터랙션, 오케스트레이션, 기능 로직. 잘록한 허리: 제어 평면의 서비스 계약. 넓은 하부: 두꺼워지는 결정론적 계층(격리, 스케줄링, 안전 모니터링, 폴백, 증거 체인). 오른쪽은 소프트웨어 산출물이 어떻게 진화하는지 보여 준다: ‘코드’ → ‘코드 + 모델 + 정책 + 에이전트 그래프 + 안전 엔벨로프’.

이는 ‘AI는 두뇌가 아니라 언어 능력이다’라는 D3의 판단과 완전히 일치한다: 언어 능력은 모델로 올라가고, 안전의 ‘뇌간’ — 결정론적 골격 — 은 OS에 남는다. 둘은 서로 모순되지 않는다. 같은 것의 양면이다.

8.3 반증 가능한 예측

‘양극화’는 ‘양쪽 다 옳다’는 얼버무림이라고 비판받기 쉽다. 이를 피하기 위해, 사실에 의해 뒤집힐 수 있는 명확한 예측을 제시한다:

[추론] 2030년 이전에, 대형 언어 모델이나 범용 에이전트가 ASIL D 액추에이터의 제어권을 직접 얻는 양산 승용차는 나오지 않을 것이다. 에이전트는 제안하고, 요청하고, 승인된 차량 서비스를 호출할 수 있지만, 제동과 조향 같은 안전 핵심 액추에이터에 대한 최종 제어권은 여전히 결정론적 제어 평면이 판정할 것이다.

이 예측이 뒤집히면, T5는 개정되어야 한다(제10장, 개정 트리거 3).

8.4 표준과 규제: OS 속 AI에 대한 제약은 이미 형태를 갖추었다

AI가 차량 OS에 들어오는지는 기술만으로 결정되지 않는다. 그것을 제약하는 규칙 체계는 이미 형태를 갖추었다:

• ISO 26262(기능 안전)와 ISO 21448(SOTIF, 의도된 기능의 안전)[T1].
• ISO/PAS 8800:2024(Road vehicles — Safety and artificial intelligence), 2024년 12월 발행, ISO 26262 Part 4, 6, 8의 관련 조항을 조정[T1]. 2025년 8월, SGS-TÜV Saar는 Geely에 세계 최초의 ISO/PAS 8800 프로세스 인증을 수여했다[T2].
• UN R155 / R156(사이버보안 관리 시스템 / 소프트웨어 업데이트 관리 시스템), 그리고 이에 대응하는 중국의 강제 표준 GB 44495 / 44496 / 44497, 2026년 1월 1일부터 시행[T1].

[추론] 이 표준들의 결합 효과: AI가 많아질수록, 라이프사이클 관리는 더 무거워진다. 모든 모델 업데이트는 갱신된 safety case를 요구할 수 있고, 차량 동작 권한을 부여받은 모든 에이전트에는 감사 가능한 권한 모델이 필요하다. 이 부담은 모델 자체가 짊어질 수 없다. 제어 평면만이 짊어질 수 있다.

답해지지 않은 질문이 하나 남아 있다: AI가 생성한 OS 코드는 어떻게 ISO 26262 안전 논증에 들어가는가? D4는 이미 아키텍처 툴체인에서 ‘AI 생성’ 역량이 ‘추론 자율성’과 디커플링되었음을 보였다. 차량 OS 수준에서는, 본고의 데이터 기준일 현재, AI가 생성한 코드가 ASIL 논증에 들어간 공개 양산 사례를 찾지 못했다. 지켜볼 가치가 있는 공백이다.

---

9. 로드맵 2026–2035: 소프트웨어 정의에서 AI 정의로

9.1 다섯 단계

표는 관찰된 상태와 연구 가설을 구분한다. 앞의 세 단계는 관찰된 것이고, 뒤의 두 단계는 가설이다.

주: 단계 V는 본 시리즈의 8단계 EEA 진화 분류법의 L8 ‘AI-Defined Vehicle’과 이름을 공유하지만, 둘은 서로 다른 대상을 기술한다: 8단계 분류법은 차량 EEA의 형태를 기술하고, 이 표는 소프트웨어 제어 평면의 형태를 기술한다. 두 차원은 직교하며 섞어서는 안 된다.

9.2 단계 III, IV, V를 실제로 가르는 것

뒤의 세 단계는 가장 혼동하기 쉽다. 한 문장으로: 단계 III는 기능을 소프트웨어로 바꾸고, 단계 IV는 소프트웨어를 스케줄링 가능한 자원으로 바꾸며, 단계 V는 무엇을 스케줄링할지 결정하는 데 모델이 참여하게 한다.

데이터 센터의 진화가 손쉬운 비유를 제공한다:

• 단계 III는 가상 머신 시대와 같다: 서버는 가상화되지만, 각 VM이 무엇을 실행하고 어디에 위치하는지는 운영 팀이 미리 설정한다.
• 단계 IV는 Kubernetes 시대와 같다: 워크로드는 표준 단위로 패키징되어 스케줄러가 규칙에 따라 자원 풀에 배치하며, 마이그레이션, 확장, 교체가 가능하다.
• 단계 V는 AI 네이티브 시대와 같다: 스케줄러 위에 의도를 이해하는 모델 계층이 있어, 시스템이 아무도 미리 작성하지 않은 흐름을 즉석에서 구성할 수 있다.

단계 IV의 여섯 가지 특징은 각각 구체적인 형태를 갖는다:

1. 동적 기능 배치. 주 컴퓨팅 유닛이 고장 나면, 오케스트레이터는 비안전 핵심 기능을 백업 유닛으로 마이그레이션한다. 또는 같은 기능이 차량 구성에 따라 서로 다른 노드에 배포된다.
   • 한 가지 한계를 강조해야 한다: ASIL D 기능은 가까운 미래에 ‘동적으로’ 스케줄링되지 않을 것이다. 그 마이그레이션 경로는 미리 설계되고 인증된 이중화 전환이다. 진정으로 동적인 것은 주로 QM과 낮은 ASIL 워크로드다.
2. 공유 컴퓨팅. 차가 주차되어 있을 때, 주행 칩의 컴퓨팅 대부분은 유휴 상태다. 단계 IV 플랫폼은 그것을 콕핏의 대형 모델, 센트리 모드의 영상 분석, 또는 차량 내 데이터 전처리에 빌려주고, 차가 움직이면 우선순위에 따라 회수할 수 있다. 단계 III는 이렇게 할 수 없다. 콕핏과 주행이 두 개의 소프트웨어 스택을 가진 두 개의 도메인에 속하기 때문이다.
3. 도메인 간 서비스. 단계 III에서 ‘캠핑 모드’는 HVAC, 디스플레이, 배터리 관리, 도어 잠금 코드의 변경을 요구하는 전용 기능이다. 단계 IV에서 그것은 단지 기존 서비스의 조합이다. 중국 완성차 업체의 ‘장면 오케스트레이션’ 기능은 이미 이 방향으로 가고 있지만, 대부분은 아직 콕핏 수준에 머물러 있고 차량 제어 깊숙이까지 닿지는 못했다[추론].
4. 클라우드–차량 개발 동등성. 같은 소프트웨어 컨테이너가 클라우드의 가상 차량에서 회귀 테스트를 마친 뒤 실차에 배포된다. Google의 AAOS SDV 문서는 가상 머신에서 실행하는 것이 ‘클라우드에서의 테스트와 통합을 용이하게 한다’고 명시한다[T1].
5. 일반화된 혼합 크리티컬리티 통합. 오늘날 Ride Flex는 8개 양산 프로그램에서 ASIL D와 QM 워크로드가 칩을 공유하게 한다[T2] — 아직은 ‘첫 물결’이다. 단계 IV에서 그것은 셀링 포인트가 아니라 신규 플랫폼의 기본 구성이 된다.
6. 표준화된 모델 라이프사이클. 주행 모델의 버전 관리, 검증, 롤백이 각 회사의 자체 도구에서 소프트웨어와 같은 파이프라인으로 옮겨 가며, ISO/PAS 8800과 R156의 제약을 받는다. Leapmotor의 ‘하나의 모델을 세 개의 컴퓨팅 등급에 배포’[T3]는 하드웨어 등급에 따라 배포 결정을 내리는 초기 사례다.

단계 IV와 V의 경계는 누가 규칙을 쓰는가에 있다. 단계 IV의 오케스트레이터가 아무리 영리해도, 그것은 엔지니어가 쓴 규칙을 실행한다. 단계 V에서는 모델과 에이전트가 결정에 참여하기 시작한다. 비교해 보라:

• 단계 IV: 사용자가 ‘캠핑 모드 켜 줘’라고 말하면, 시스템은 미리 구축된 서비스 조합을 실행한다.
• 단계 V: 사용자가 ‘오늘 밤은 산에서 보내고 내일 아침에 시내로 운전해서 돌아가야 해’라고 말한다. 에이전트는 남은 충전량을 귀환 거리와 대조하고, HVAC가 쓸 수 있는 에너지를 계산하고, 배터리 예비 하한을 설정하고, 화면을 어둡게 하고, 내일 경로상의 충전소를 찾는다. 어떤 엔지니어도 이 조합을 작성한 적이 없다. 그것은 권한 모델과 안전 엔벨로프 안에서 즉석에서 생성된다.

Leapmotor의 AgentOS, Hyundai의 Gleo AI, Mercedes의 Gemini 기반 에이전트는 모두 아직 제8장에서 기술한 ‘AI가 OS 서비스가 되는’ 단계에 있다: 그것들은 의도를 이해하지만, 호출할 수 있는 차량 서비스의 범위와 권한은 여전히 제한적이다.

업계가 단계 IV에 진입했음을 어떻게 알 수 있는가? 관찰 가능한 네 가지 신호를 지켜보라:

1. 새 소프트웨어 릴리스 없이 컴퓨팅 유닛 사이를 마이그레이션하는 기능을 가진 양산차;
2. 클라우드에서 검증된 같은 소프트웨어 컨테이너가 여러 하드웨어 등급에 걸쳐 배포됨;
3. 기본적으로 ASIL D와 QM 워크로드가 SoC를 공유하는 신규 플랫폼;
4. 롤백을 갖춘, 통일되고 규제된 파이프라인에 들어가는 모델 업데이트.

단계 V의 신호는 권한 모델을 통해 차량 서비스를 호출하는 에이전트를 가진 양산차, 그리고 미리 코딩되지 않고 사용자 의도로부터 생성된 기능 조합이다.

[추론] 세 단계 사이의 경계는 흐릿하다. 같은 완성차 업체가 두 단계에 걸쳐 있는 경우가 많다. 이 표는 무게 중심의 이동을 기술하는 것이지, 깔끔한 단절을 기술하는 것이 아니다.

9.3 제어점의 이동

[추론] 지금부터 2030년까지, D1의 7개 제어점 가운데 여기에 관련된 세 개는 다음과 같이 변할 것이다:

• C2(SoC): 계속 위쪽으로 흡수하며, ‘칩 + 하이퍼바이저 + 인증된 런타임 + 미들웨어 일부’의 풀스택을 납품한다.
• C3(OS): 커널과 기본 런타임은 범용화되고, 독립적 가치는 제어 평면의 오케스트레이션과 라이프사이클로 이동한다.
• C4(미들웨어): 오픈소스(S-CORE, HaloOS)와 표준(VSS, 중국 국가 표준)이 수렴을 가속하며, 계약 계층은 점차 공유재가 된다.

그림 9.1 — C3의 압착: 차량 OS 가치는 어디로 이동하는가. 읽는 법: C3는 위아래의 힘에 의해 압착된다. 완성차 업체 자신의 것으로 남는 것은 오케스트레이션, 라이프사이클, 데이터 루프(C5)다.

9.4 중국의 경로: 자체 개발, 오픈소스, 국가 표준의 병행

중국의 차량 OS 진화에는 독특한 구조가 있다: 자체 개발, 오픈소스, 국가 표준이 병행하여 전진하며 서로를 강화한다.

• 자체 개발: NIO SkyOS, Huawei의 HarmonyOS 콕핏과 Qiankun, XPeng, Xiaomi 등이 자체 소프트웨어 스택을 구축하고 있다[T2].
• 오픈소스: Li Auto는 HaloOS를 Apache 2.0으로 오픈소스화하여(2025), 자체 개발 성과를 산업 공유재로 바꾸었다[T2].
• 국가 표준: GB/T 47351 / 47341-2026은 2026년 7월 1일에 시행되었고, 세 개의 강제 표준 GB 44495 / 44496 / 44497은 UN R155 / R156과 조화되어 2026년 1월 1일에 시행되었다[T1].

[추론] 국가 표준의 중요한 귀결 하나: 그것은 중국에서 판매하는 모든 완성차 업체 — 외국 완성차 업체 포함 — 가 맞춰야 하는 인터페이스가 된다. Mercedes-Benz China와 Volkswagen China가 기초 작성 기관에 이름을 올린 것은 외국 완성차 업체들이 이를 인식했음을 보여 준다. 이는 또한 ‘연합형 제어 평면’이 전 세계적으로 나타나는 구조적 이유 가운데 하나일 수 있다: 같은 완성차 업체가 중국과 다른 지역에서 서로 다른 인터페이스 체제를 마주한 소프트웨어 스택을 유지해야 할 수 있다.

9.5 경제와 조직: 진짜 병목

경제적으로, 차량 OS는 네 가지 방식으로 투자를 회수한다: ECU와 배선의 부품원가 절감, 모델 간 소프트웨어 재사용, 플랫폼 비용의 상각, 그리고 차량 판매 후의 소프트웨어 수익. Rivian의 소프트웨어 및 서비스 매출총이익이 FY2025에 700만 달러에서 5억 7600만 달러로 뛰어오른 것[T1]은 자산으로서의 ‘E/E + OS’의 가치가 이미 재무제표에 나타날 수 있음을 보여 준다.

조직적으로, 그 비용은 종종 과소평가된다. 5.1절은 로드맵 층(M4)의 거의 모든 완성차 업체가 지연되었음을 지적했다. [추론] 원인은 기술인 경우가 드물고, 대개는 조직이다:

• 수십 개의 기능 기반 부서를 하나의 플랫폼 조직으로 바꾸기;
• Tier 1 계약을 ‘블랙박스 ECU’ 단위에서 ‘소프트웨어 모듈 + 통합 책임’ 단위로 바꾸기;
• 현행 모델의 출하를 유지하면서 차세대 플랫폼 구축하기.

이것은 차량 OS에 적용된 Conway의 법칙이다: 당신의 제어 평면은 당신의 조직을 닮게 될 것이다. 여전히 ‘바디, 섀시, 파워트레인, 콕핏’ 부서로 나뉘어 있는 완성차 업체는 네 도메인 모두에 걸친 제어 평면을 구축하는 데 어려움을 겪을 것이다.

이 장을 한 문장으로 요약하면:

중앙집중화는 시스템 복잡성을 만들어 냄으로써 국소 복잡성을 제거한다. 그것은 100개 ECU 사이의 파편화를 없애지만, 더 큰 폭발 반경, 더 집중된 공격 표면, 더 복잡한 검증 — 그리고 차를 재조직하기 전에 스스로를 재조직해야 하는 조직을 가져온다.

---

10. 스스로의 목에 칼을 대다: 반론과 개정 트리거

10.1 일곱 가지 반론

반론 1: 차량 OS는 마케팅 개념일 뿐이다. 브랜드 층을 벗겨내면 남는 것은 QNX + Linux + AUTOSAR + 하이퍼바이저다. 응답: 이것이 바로 T1이 출발하는 지점이다. 우리는 차량 OS가 새로운 커널이라고 주장하지 않는다. 그것이 여러 커널을 거버넌스하는 제어 평면이라고 주장한다. 브랜드는 실제로 과장되었지만, 그 세 부분 — 계약, 오케스트레이션, 라이프사이클 — 은 실재하고, 관찰 가능하며, 점수를 매길 수 있다.

반론 2: 중앙 컴퓨팅은 수지가 맞지 않을 수 있다. 가상화, 이중화, 액랭의 오버헤드가 ECU 감소로 인한 절감을 상쇄할 수 있다. 응답: 우리는 여기서 결론을 내리지 않는다. 경제성은 차량 볼륨과 소프트웨어 수익에 달려 있으며, 공개 데이터로는 판단하기에 불충분하다. 우리는 단지 ‘중앙집중화는 국소 복잡성을 시스템 복잡성과 맞바꾼다’는 점을 지적할 뿐이다 — 그 거래가 수지가 맞는지는 완성차 업체에 달려 있다.

반론 3: 차량 OS는 실제로 시스템적 리스크를 증가시킨다. 응답: 동의한다. 이것이 바로 제6장의 논증이다: 중앙집중화는 격리를 자연적 속성에서 증명되어야 하는 속성으로 바꾼다. 리스크가 통제되는지는 V3(혼합 크리티컬리티)가 얼마나 잘 이루어지는지에 달려 있다.

반론 4: 표준화된 API는 완성차 업체의 차별화를 쓸어버릴 것이다. 응답: 계약 계층에서의 차별화는 실제로 줄어들 것이다(T6). 그러나 오케스트레이션, 라이프사이클, 데이터 루프는 여전히 차별화의 공간으로 남는다. 차별화는 사라지지 않고, 이동할 것이다.

반론 5: AI 에이전트는 절대 안전 핵심 제어 경로에 들어와서는 안 된다. 응답: 우리의 입장은 더 구체적이다: 에이전트는 제어 평면에 들어올 수 있지만, 결정론적 거버넌스 아래에서만 그렇다. ASIL D 액추에이터에 대한 최종 제어권은 가까운 미래에 에이전트에게 넘어가지 않을 것이다(8.3의 예측).

반론 6: 지역화된 소프트웨어 스택은 글로벌 차량 OS를 가로막을 것이다. 응답: 동의한다 — 그리고 이것은 문제가 아니라 종국일 수 있다. 7.6에서 논한 ‘연합형 제어 평면’이 바로 이 판단을 전개한 것이다.

반론 7: L4는 결국 차량 OS의 일부가 아니라 자체 OS를 필요로 할 것이다. 응답: 이것은 열린 질문이다. 이중 채널 구조(6.6)는 L4 안전 모니터링 채널이 논리적으로 차량 제어 평면과 독립적이라는 것을 의미할 수 있다. L4 플릿이 승용차 차량 OS와 완전히 분리된 소프트웨어 스택을 널리 채택한다면, T4는 ‘자율주행은 차량 OS와 안전 채널 사이의 계약을 시험한다’로 다시 서술되어야 한다.

10.2 다섯 개의 개정 트리거

다음 중 어느 하나라도 발생하면, 해당 테제는 개정되어야 한다:

---

11. 결론: 세 가지 판단과 한 가지 경고

제목으로 돌아가자. ‘OS들의 시스템’은 수사가 아니다 — 그것은 모든 소프트웨어 정의 자동차 안의 그 계층에 대한 가장 정확한 기술이다. 그것은 너무나 많은 ‘OS’라는 이름으로 불려 왔기에, 아무도 멈춰 서서 그것이 실제로 무엇인지 묻지 않았다.

우리의 답: 그것은 계약, 오케스트레이션, 라이프사이클로 이루어진 제어 평면으로서, 일련의 운영체제를 거버넌스한다 — 어느 하나의 운영체제 그 자체가 아니다.

판단 1: 차량 OS는 OS들의 시스템이며, 그 경계는 E/E 아키텍처가 긋는다. OS라고 불리는 것이 차량 OS가 아닐 수 있고, OS라고 불리지 않는 것이 차량 OS일 수 있다. 판별 기준은 브랜드명이 아니라, 계약이 어떤 도메인을 포괄하는가, 오케스트레이션이 격리를 증명할 수 있는가, 라이프사이클이 어떤 계층을 업데이트할 수 있는가다. 그 세 가지가 어디까지 갈 수 있는지는 무엇보다 먼저 E/E 아키텍처가 어느 세대에 도달했는지에 달려 있다.

판단 2: 진짜 분수령은 인과의 역전이다. 완성차 업체가 소프트웨어 정의 시대에 진입했다는 표지는 OS 브랜드를 가졌는지가 아니라, 공진화 루프의 하반부가 돌기 시작했는지 — 다음 세대 E/E 사양이 현 세대 소프트웨어의 요구에 의해 정의되는지 — 다. GM의 ‘10배 / 1000배 / 35배’, 존 컨트롤러를 어디까지 탈지능화할 것인가를 둘러싼 BMW와 GM의 갈라짐, 그리고 Rivian이 ‘E/E + OS’를 하나의 전체로 판매하는 것은 모두 루프가 돌기 시작했다는 신호다.

판단 3: AI는 운영체제를 덜 중요하게가 아니라 더 중요하게 만든다. AI는 OS의 상반부를 흡수하겠지만 하반부를 더 두껍게 만들 것이다. 확률이 많아질수록, 결정론은 더 귀해진다. 자율주행은 이것의 스트레스 테스트다: 콕핏은 OS가 애플리케이션을 실행할 수 있는지만 시험하지만, 운전자 없는 차는 차량 OS가 차량을 운행할 수 있는지를 시험한다.

한 가지 경고: ‘OS를 소유하는 것’을 결승선으로 여기지 말라. 커널은 범용화되고, 계약은 표준화되고 있으며, 칩 제조사와 수평 플랫폼이 양 끝에서 압착하고 있다. 대부분의 완성차 업체에게 진짜 질문은 ‘자체 OS를 만들어야 하는가?‘가 아니라 ‘제어 평면의 어느 부분에서 우리가 최종 결정권을 가져야 하는가?‘다. 오케스트레이션, 라이프사이클, 데이터 루프, 그리고 안전 책임의 궁극적 소유 — 이것들이 표준화의 물결 이후에도 여전히 완성차 업체에 속하는 것이다.

차량 OS 경쟁은 하나의 시스템이 승리하는 것으로 끝나지 않을 것이다. 그것은 더 담백한 질문으로 끝날 것이다: 자동차의 모든 계층을 살 수 있을 때, 살 수 없는 계층은 어느 것인가? 본고는 좌표계를 테이블 위에 펼쳐 놓았다. 어디에 베팅할지는 언제나 독자 자신의 결정이었다.

---

부록 A | 증거 등급과 주요 출처

A.1 증거 등급

주: 모든 미래 날짜(GM 2028, STLA One 2027, Hyundai 2030 등)는 회사의 계획이나 목표이지 사실이 아니며, 지연의 전례가 있다.

A.2 주요 출처(주제별, 발췌)

• QNX 탑재 기반: BlackBerry FY2026 10-K — https://www.sec.gov/Archives/edgar/data/1070235/000107023526000039/bbry-20260228.htm
• MB.OS 양산 개시: Mercedes-Benz Group, Rastatt CLA 양산 개시 — https://group.mercedes-benz.com/company/production/production-network/start-of-production-cla-rastatt.html
• NIO SkyOS: NIO 공식(풀스택 기술: 전 도메인 차량 OS) — https://www.nio.cn/smart-technology/20251215002 ; IT Home — https://www.ithome.com/0/720/560.htm
• Li Auto HaloOS 오픈소스: TechNode — https://cn.technode.com/post/2025-03-29/lixiang-xinghuan-os/
• 중국 국가 표준: 국가 표준 정보 공공 서비스 플랫폼 — https://std.samr.gov.cn/gb/search/gbDetailed?id=0BBF0FBBBE1AE46FE06397BE0A0AD1FD ; https://std.samr.gov.cn/gb/search/gbDetailed?id=D33BADAFBDDF2CD0E05397BE0A0A113C
• GB/T 47341-2026 상업 번역본(T3) — https://www.chinaautoregs.com/archives/7587
• GM 중앙 컴퓨팅 플랫폼: GM 보도자료, 2025-10-22 — https://news.gm.com/home.detail.html/Pages/news/us/en/2025/oct/1022-SDV-GM-centralized-vehicle-computer-platform-electric-gas-vehicles.html
• BMW Neue Klasse 슈퍼브레인: https://www.bmwgroup.com/en/news/general/2025/superbrains.html
• Toyota Arene / RAV4: https://pressroom.toyota.com/three-two-one-toyota-debuts-amazing-all-new-rav4/ ; https://insideevs.com/news/775729/2026-toyota-rav4-phev-arene-software-ev/
• Toyota Arene(2023년 표현): Toyota 보도자료, 2023-04-11 — https://global.toyota/en/newsroom/corporate/39070846.html
• Hyundai Pleos: https://www.hyundainews.com/releases/4774 ; S&P Global Mobility — https://www.mobilityglobal.com/en-us/automotive-insights/blog/hyundai-pleos-software-launch-shifts-mobility-game
• Rivian / RV Tech: Rivian FY2025 8-K — https://www.sec.gov/Archives/edgar/data/1874178/000187417826000007/ex-991pressrelease4q25earn.htm ; DEF 14A — https://www.sec.gov/Archives/edgar/data/0001874178/000187417826000023/rivn-20260427.htm
• RV Tech 진척: Volkswagen Group 보도자료, 2025-11-12 — https://www.volkswagen-group.com/en/press-releases/one-year-after-its-founding-joint-venture-between-volkswagen-group-and-rivian-shows-strong-progress-19980 ; 동계 시험 — https://www.electrive.com/2026/03/27/vw-and-rivian-conclude-winter-testing-programme/
• Volkswagen Group CEA: Volkswagen Group 보도자료, 2026-01-28 — https://www.volkswagen-group.com/en/press-releases/volkswagen-group-china-starts-production-of-its-first-locally-developed-zonal-electronic-architecture-20144 ; CarNewsChina — https://carnewschina.com/2026/01/29/volkswagen-starts-production-of-xpeng-co-developed-cea-architecture-five-new-models-due-in-2026/ ; CarNewsChina, 2025-12-10 — https://carnewschina.com/2025/12/10/volkswagen-and-xpengs-first-joint-vehicle-id-unyx-07-nears-production-after-just-18-month-chinese-led-development/ ; IT Home — https://www.ithome.com/0/903/897.htm
• CARIAD 구조조정(T3): https://allthingstalent.org/volkswagen-to-cut-1600-jobs-at-cariad-software-division-in-major-restructuring-move/2025/03/13/
• Leapmotor LEAP 5.0: Stellantis Media(Leapmotor Tech Day 2026, 2026-09-30) — https://www.media.stellantis.com/uk-en/leapmotor/press/leapmotor-unveils-next-generation-vehicle-architecture-battery-technology-at-tech-day-2026 ; Gasgoo — https://autonews.gasgoo.com/articles/ev/leapmotor-counters-tech-peak-theory-with-one-architecture-and-three-systems-2101156419729817601 ; Sina Auto, 2026-09-16 — https://auto.sina.cn/news/2026-09-16/detail-inirzwqt4627345.d.html
• Qualcomm Ride Flex: TechInsights — https://www.techinsights.com/blog/qualcomm-integrates-cockpit-adas
• NVIDIA Halos: https://www.nvidia.com/en-us/ai-trust-center/halos/autonomous-vehicles/
• Google AAOS SDV: Android Developers Blog, 2026-03-24 — https://android-developers.googleblog.com/2026/03/Beyond-Infotainment-Extending-Android-Automotive-OS-for-Software-defined-Vehicles.html ; AAOS SDV 시스템 아키텍처 — https://source.android.com/docs/automotive/sdv/sdv-system-architecture
• Stellantis × Applied Intuition: https://www.stellantis.com/en/news/press-releases/2026/may/stellantis-and-applied-intuition-expand-collaboration-with-stla-brain-to-advance-vehicle-software-and-enhance-customer-experience
• VDA / Eclipse S-CORE: https://blogs.eclipse.org/post/sara-gallian/eclipse-sdv-2025-all-roads-lead-open-source ; https://www.adt.media/software-defined-vehicles/vda-and-eclipse-foundation-expand-sdv-software-ecosystem/2587652
• SOAFEE: https://www.globenewswire.com/news-release/2026/04/22/3279060/0/en/here-joins-soafee-to-bring-expertise-in-ai-powered-mapmaking-into-open-software-defined-vehicle-platforms.html ; Open AD Kit — https://autoware.org/open-ad-kit-the-first-soafee-blueprint-powering-open-collaboration-in-autonomous-driving/
• Eclipse Open Vehicle API: https://projects.eclipse.org/projects/automotive.openvehicle-api/reviews/eclipse-open-vehicle-api-2026.08-progress-review
• AUTOSAR Adaptive와 POSIX: UL Solutions — https://www.ul.com/sis/blog/autosar-part-2-adaptive-platform
• UN R156(7.1.1항 원문): EUR-Lex — https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:42021X0388
• ISO/PAS 8800: UL — https://www.ul.com/sis/blog/safety-related-systems-road-vehicles-artificial-intelligence-are-addressed-isopas-88002024 ; Geely 인증(SGS) — https://www.sgs.com/en-hk/news/2025/08/geely-auto-awarded-first-global-ai-safety-certification-for-road-vehicles
• Huawei HarmonyOS 콕핏 / Qiankun 탑재 기반: https://news.qq.com/rain/a/20260908A0664N00
• AUTOSEMO 보고서 6.0: Reach Auto(Neusoft) 보도자료, 2025년 10월, AUTOSEMO를 대신하여 보고서 발표 — https://www.reachauto.com/en/2025/10/

---

부록 B | VOCM 채점 기준

각 차원은 0–5점으로 채점한다. 점수는 공개 출처에만 근거한다. 증거가 불충분한 차원은 2점을 넘을 수 없으며, 또는 n.a.로 표시할 수 있다.

신뢰도: H = Tier 1–2 증거가 대부분의 차원을 직접 뒷받침함; M = 일부 차원이 회사 주장에 의존함; L = 대부분의 차원이 2차 출처나 추론에 의존함.

동일 계보 예외: 이미 채점된 완성차 업체와 공동 개발되어 같은 아키텍처 계보를 이어받은 플랫폼(예: XPeng과의 VW CEA)은 자체 공개 정보가 빈약한 차원에서 해당 업체의 점수를 참조할 수 있다. 그러한 차원은 각각 비고에 명시해야 하며, 신뢰도는 L로 제한된다.

---

부록 C | 약어