SDV가 바꾸는 것은 기능이 아니라 개발 순서다

SDV(Software Defined Vehicle)라는 말이 보도자료에 붙기 시작한 지 몇 년이 지났다. 소비자에게 전달되는 이미지는 대체로 하나다. 차를 산 뒤에도 업데이트로 기능이 늘어난다는 것.

그러나 제조사 내부에서 SDV는 훨씬 앞단의 문제다.

60개 ECU의 유산

전통적인 차량은 기능마다 전용 제어기를 붙이는 방식으로 성장했다. 파워윈도, 시트, 공조, 계기판, 제동. 각각의 ECU가 협력사에서 소프트웨어까지 통째로 납품된다.

이 구조에서는 기능 하나를 바꾸려면 해당 협력사의 개발 주기를 기다려야 한다. 차량 전체 소프트웨어를 제조사가 통제하지 못한다.

중앙집중화가 먼저다

SDV의 전제는 제어기 통합이다. 기능별 ECU를 구역(zone) 단위로 묶고, 고성능 중앙 컴퓨터가 로직을 담당한다.

• 배선 하네스가 짧아져 무게와 원가가 줄어든다.
• 소프트웨어가 하드웨어에서 분리돼 업데이트 단위가 커진다.
• 제조사가 차량 소프트웨어의 통합 책임을 가져간다.

세 번째 항목이 조직 문제를 만든다. 그동안 협력사에 있던 역량을 제조사가 직접 갖춰야 한다. 완성차사들이 소프트웨어 자회사를 세우거나 대규모 채용을 진행한 배경이다.

검증이 병목이 된다

기능이 소프트웨어로 정의되면 조합의 수가 폭발한다. 트림, 시장별 법규, 옵션, 업데이트 이력이 곱해진다. 실차 시험만으로는 감당할 수 없다.

그래서 SDV 전환의 실질적 병목은 대개 검증 인프라에 있다.

하드웨어 인 더 루프(HIL) 랙을 몇 대 갖추느냐, 시뮬레이션에서 몇 퍼센트를 걸러내느냐가 개발 속도를 결정한다.

소비자에게 오는 신호

SDV가 잘 준비된 차량인지 판단할 단서는 화려한 디스플레이가 아니다.

• 출고 후 실제로 배포된 업데이트 이력이 있는가
• 인포테인먼트만이 아니라 제어기 펌웨어(FOTA)까지 갱신되는가
• 업데이트 실패 시 롤백 경로가 안내되는가

이 세 가지가 확인되면, 그 차는 최소한 구조적으로 준비가 된 편이다.