차량은 이제 소프트웨어로 정의되는가? 도메인 아키텍처와 SDV 전환

전기 자동차 기술
작성자: Deniz Erkan
생성: 14 10월 2026

100개가 넘는 제어 유닛을 몇 개의 존 컨트롤러로 통합하는 이 아키텍처는 이제 자동차의 정체성을 강철이 아닌 코드로 만들어냅니다.

이 페이지 공유하기

네: 현대 자동차의 동작, 기능, 성능 특성은 이제 소프트웨어가 우선적으로 정의합니다. 소프트웨어 정의 차량(SDV)이라 불리는 이 전환은 차량의 전자 아키텍처를 ECU 집합체에서 도메인 및 존(zone) 컨트롤러로 이동시켜 하드웨어와 소프트웨어를 분리하고, 배선 무게부터 OTA 업데이트까지 모든 것을 새롭게 재편하고 있습니다.

주요 내용

오늘날의 차량 100개 이상의 제어 유닛을 포함할 수 있으며, 새로운 아키텍처는 이 수치를 최대 20%까지 줄이는 것을 목표로 합니다.
도메인 아키텍처는 기능별로, 존 아키텍처는 물리적 위치별로 구성합니다.
존 토폴로지에서는 CAN XL (최대 20 Mbps) 및 기가비트 이더넷과 같은 고대역폭 백본이 사용됩니다.
OTA 업데이트는 하드웨어-소프트웨어 분리 덕분에 가능한 SDV의 핵심 기능입니다.
전환은 점진적으로 이루어집니다: 첫 번째 영역은 바디(body) 도메인이며, ADAS, 파워트레인, 섀시는 더 오랜 기간 기존 구조에 남을 수 있습니다.

소프트웨어 정의 차량이란 정확히 무엇인가?

정의는 명확합니다: 소프트웨어 정의 차량이란 기능과 동작이 하드웨어보다 소프트웨어에 의해 우선적으로 결정되는 차량입니다. 전통적인 자동차에서는 하나의 기능이 그 기능을 위해 특별히 제작된 하드웨어 부품으로 정의되었지만, SDV에서는 동일한 하드웨어가 그 위에서 실행되는 소프트웨어에 따라 서로 다른 기능을 수행할 수 있습니다. 차량이 판매된 후에도 새로운 기능을 추가하고, 동작을 조정(calibration)하며, 오류를 원격으로 수정할 수 있습니다.

오늘날의 E/E 아키텍처는 100개 이상의 제어 유닛으로 구성되어 있으며, 차세대 구조는 제어 유닛 수에서 최대 20%, 소재와 하드웨어에서 최대 10%의 절감을 제공합니다.
Bosch Mobility, E/E 아키텍처 평가

이 문장에 담긴 수치들은 전환의 규모를 요약합니다. 문제는 단지 제어 유닛의 수가 아닙니다: 각 ECU는 자체 배선, 자체 소프트웨어 스택, 자체 검증 부담을 함께 가져옵니다. SDV의 비전은 이러한 분산된 구조를 소프트웨어가 하나의 일관된 계층에서 관리할 수 있는 시스템으로 전환하는 것입니다. 이를 위해서는 전자 아키텍처를 처음부터 다시 설계해야 합니다.

ECU에서 도메인 아키텍처로: 기능별 그룹화

자동차의 모든 작은 기능이 별도의 전자 제어 유닛(ECU)을 갖던 시대는 배선 하네스를 관리 불가능한 수준으로 만들었습니다. 도메인 아키텍처는 이에 대한 첫 번째 체계적인 해답이었습니다: 차량 전자 장치를 ADAS, 인포테인먼트, 파워트레인, 바디 전자 장치, 섀시, 안전과 같은 큰 기능 영역별로 구성합니다. 각 도메인은 일반적으로 자체 프로세서, 소프트웨어 스택, 통신 인터페이스, 센서 및 액추에이터를 갖추고 있으며 도메인 컨트롤러에 의해 관리됩니다.

이 구조는 ECU 혼돈에 비해 상당한 정리 효과를 제공했습니다. 그러나 SDV 목표가 커짐에 따라 도메인 아키텍처의 한계가 드러났습니다. 특히 자율 기능이 생성하는 센서 데이터는 기존 CAN 네트워크의 대역폭을 한계로 몰아넣었습니다. 또한 각 도메인이 자체 연산 자원을 운반해야 한다는 점은 배선 하네스를 복잡하게 유지했고, 소프트웨어가 차량 전체에 확장되는 것을 어렵게 만들었습니다.

존 아키텍처: 조직이 기능에서 위치로 전환되다

존 아키텍처의 논리는 기존 방식을 뒤집습니다: 전자 장치를 기능별이 아니라 차량 내 물리적 위치에 따라 그룹화합니다. 차량은 전륜 좌측, 전륜 우측, 후륜 좌측, 후륜 우측, 실내와 같은 영역으로 나뉘며, 각 영역에는 하나의 존 컨트롤러가 있어 해당 영역의 센서, 액추에이터, 전력 분배를 총괄하고 중앙의 고성능 처리 플랫폼과 통신합니다.

특징	도메인 아키텍처	존 아키텍처
조직 원칙	기능별 (파워트레인, ADAS, 바디...)	물리적 위치별 (전륜 좌측, 후륜 우측...)
처리 자원	도메인 전용 처리	통합된 중앙/분산 처리
배선	복잡하고 긴 와이어링 하네스	배선과 중량 감소
ECU 수	다수의 ECU	소수의 존 컨트롤러 + 중앙 컴퓨터
소프트웨어 유연성	SDV에 대한 확장이 어려움	높은 소프트웨어 유연성

이득은 구체적이고 측정 가능합니다: 와이어링 하네스 무게가 줄어들고, 점대점 연결이 감소하며, 차량 아키텍처와 시스템 검증 작업이 단순해집니다. 더욱 중요한 것은, 센서와 액추에이터 설계가 중앙 처리 노드로부터 독립되어 하드웨어와 소프트웨어 업데이트 주기가 분리되고, 하나의 센서 설계를 여러 차량 세대에 걸쳐 사용할 수 있게 된다는 점입니다.

존 컨트롤러는 어떤 역할을 할까? 작업 분담과 하드웨어와의 관계

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

존 아키텍처의 핵심은 다수의 액추에이터와 센서를 중앙 처리 ECU에 연결하는 역할을 담당하는 존 컨트롤러입니다. 이 컨트롤러는 단순한 데이터 수집 상자가 아니며, 실시간 제어 루프를 자체적으로 실행할 수 있고, 해당 영역의 장치를 관리하며, 백본으로 필터링되고 우선순위가 지정된 트래픽을 전송합니다. Ti의 엔지니어링 평가에 따르면 존 모듈의 MCU는 높은 실시간 성능, 넓은 메모리, 다양한 ASIL 수준을 위한 가상화 지원, 백본과의 고속 통신, 그리고 CAN FD, LIN과 같은 저비용의 다수 엔드 인터페이스를 제공해야 합니다.

전력 분배는 어떻게 분산화되는가?

도메인 아키텍처에서 전력은 퓨즈와 릴레이를 포함하는 중앙 전력 분배 상자에서 분배됩니다. 존 구조에서는 분배가 분산화됩니다: 단일 전력 하네스가 배터리에서 영역으로 연결되고, 존 모듈이 해당 영역의 모듈들에 전력을 분배합니다. 짧은 전력 케이블은 곧바로 중량과 비용 절감을 의미합니다. 또한 퓨즈를 대신하여 반도체 기반 스마트 퓨즈가 사용되며, I²t 특성을 가진 하이사이드 스위치는 퓨즈 변동성을 줄이고 더 최적화된 케이블 단면을 제공합니다. MCU, 하이사이드 스위치, 트랜시버로 구성된 스마트 전력 분배 상자는 구성이 소프트웨어로 이루어지는 유닛이 되어: 동일한 상자를 모든 존에서 부하에 맞게 조정하여 사용할 수 있습니다.

물리적 I/O와 논리적 I/O의 분리

Zonal 모듈은 여러 ECU의 논리적 입출력 기능을 한곳에 통합하여 배선 복잡성을 줄이며, 센서와 액추에이터의 물리적 위치는 그대로 유지됩니다. 한 단계 더 나아가 엔드 디바이스는 "스마트"해집니다: 로컬 회로가 상태 정보를 유지하고 고장 진단을 수행합니다. CAN FD Light와 같은 간소화된 프로토콜은 일부 엔드 노드에서 별도의 MCU 필요성조차 없앨 수 있습니다. 하드웨어는 고정되고 기능은 소프트웨어로 정의되는 이러한 분리가 SDV의 엔지니어링 근간입니다.

Zonal 차량의 데이터 버스: 대역폭, 타이밍 및 사이버 보안

센서 융합과 AI 워크로드는 zonal 토폴로지를 고대역폭 백본 위에 구축하도록 강제합니다: PCIe, 최대 20 Mbps의 데이터 속도에 도달하고 기존 CAN 호환성을 유지하는 CAN XL과 기가비트 이더넷. 진정한 과제는 대역폭을 넘어 타이밍에 있습니다; 짧은 제어 메시지, ADAS 센서 데이터, 인포테인먼트 트래픽은 서로 매우 다른 지연 시간, 지터 및 동기화 요구 사항을 가집니다. 대략적인 기준은 다음과 같습니다: 오디오는 밀리초 수준, 파워트레인과 섀시 제어는 마이크로초 수준의 지연 시간 목표가 적용됩니다.

이러한 서로 다른 트래픽 클래스를 단일 네트워크에서 전송하기 위해 이더넷 기반 Time-Sensitive Networking(TSN)이 해결책으로 부상합니다. 시간 동기화(IEEE 802.1AS), 시간 민감 트래픽 셰이핑(802.1Qbv), 익스프레스 트래픽(802.3br), 프레임 선점(802.1Qbu), 이중화(802.1CB)와 같은 표준은 중요 데이터에 결정론적 지연 시간 보장을 제공합니다. 안전 측면에서는 ISO 26262 지원, 이중 통신 경로, 안전 분할 및 고장 감지가, 사이버 보안 측면에서는 ISO/SAE 21434 표준, UNECE 규정, MACsec과 같은 하위 수준 암호화-인증 메커니즘이 결정적입니다. Zonal 아키텍처는 네트워크를 중앙 집중화하기 때문에 이더넷 기반 공격 방법도 실행 가능해집니다; 보안 침해 시 입출력-처리 분리 개념의 붕괴는 개별적으로 평가해야 할 위험입니다.

하드웨어-소프트웨어 분리는 OTA 업데이트를 어떻게 가능하게 하는가?

OTA 업데이트는 대부분의 SDV 논의에서 가장 먼저 떠오르는 기능이지만, 그 자체로 하나의 역량이 아니라 아키텍처의 결과입니다. 소프트웨어가 하드웨어 추상화 계층(HAL)을 통해 특정 칩에서 분리되지 않고, 차량 기능이 독립적이고 재사용 가능하며 느슨하게 결합된 서비스로 나뉘지 않은 채(서비스 지향 아키텍처, SOA) 끊김 없는 업데이트를 제공할 수 없습니다. 분리는 동시에 서로 다른 안전 등급을 가진 소프트웨어들의 상호 격리도 포함합니다.

구체적인 의미는 다음과 같습니다: zone 아키텍처는 OTA/FOTA 업데이트와 지속적인 클라우드 연결을 통해 고수준 소프트웨어 유지보수의 통제권을 제조사에 넘기면서, 실시간 제어 루프는 zone 모듈로 이전시킬 수 있습니다. 사용하지 않는 모듈의 전력 차단 같은 세밀한 조정도 이 구조에서는 쉬워집니다. 궁극적으로 전기차 소프트웨어는 단순한 업데이트 채널을 넘어, 차량의 기능, 안전 시스템, 성능 특성을 결정하는 정의 계층입니다. 차량은 바퀴 위에 분산된 데이터 센터처럼 되어가고 있으며, 가치 사슬은 소프트웨어, 연산 능력, 시스템 아키텍처에 기반합니다.

전환은 얼마나 빠르게 이루어질 것이며 Zonal 아키텍처만으로 충분할까?

전환은 점진적으로 이루어질 것입니다. 바디(body) 도메인은 수많은 분산 액추에이터와 센서 ECU를 포함하고 있어 zone 아키텍처로 전환할 첫 번째 영역이 되며, ADAS, 파워트레인, 섀시 제어의 전환은 안전이 중요한 특성 때문에 더 많은 시간이 걸릴 수 있습니다. 2017년 이후 MCAL, BSW 및 애플리케이션 계층에서 일어난 진화는 이것이 단순한 기술 프로젝트가 아니라 업계 전반의 사고방식 변화임을 보여줍니다.

균형 잡힌 시각도 필요합니다. Zonal 아키텍처는 차량을 물리적으로 재편하지만, 논리적·소프트웨어 측면(SOA, HAL, 사이버 보안)은 별도로 해결해야 합니다. 배선만 다시 정리한다고 차량이 소프트웨어로 정의되는 것은 아닙니다. 시장 규모 전망 역시 범위 정의에 따라 크게 달라집니다. E/E 아키텍처 시장과 관련된 상이한 수치는, 시장을 무엇(연산 플랫폼만인지, 아니면 모든 분산 전자 장치까지인지)으로 계산하느냐에 따른 측정 방식 차이에서 비롯됩니다. 또한 전환의 당사자인 반도체 및 솔루션 공급업체들이 이 전환에 자연스럽게 이해관계를 갖고 있다는 점도 잊어서는 안 됩니다.

결론은 명확한 공학적 균형입니다. 차량의 소프트웨어 정의는 단일 소프트웨어 프로젝트가 아니라, 도메인 및 zonal 컨트롤러에 기반한 새로운 하드웨어 구성, 분리된 소프트웨어 계층, 그리고 결정론적이고 안전한 데이터 백본이 동시에 존재할 때 가능합니다. OTA 업데이트는 이 통합 구조의 가장 눈에 띄는 결실이며, 진정한 혁명은 차량의 하드웨어가 자신의 임무를 소프트웨어에 위임하는 데 있습니다.