Software Defined Vehicle - 40 middleware are too many
SDV, “40개의 미들웨어는 너무 많다”
ETAS 데틀레프 제르포브스키가 말한 SDV의 진짜 그림
2026-07-16 / 09월호 지면기사  / 한상민 기자_han@autoelectronics.co.kr



7월 1일 오전 9시, 수원컨벤션센터에서 열린 AID 2026의 포문을 연 ETAS 데틀레프 제르포브스키 부사장은 지금 자동차 산업이 어디에 서 있는지, 어디로 가야 하는지를 하나의 질문으로 정리했다. "40개의 미들웨어는 너무 많습니다"라면서. 이는 단순히 미들웨어 숫자에 대한 불만이 아니다. OEM이 모든 것을 혼자 만들 수 있다는 오래된 믿음, 그리고 SDV 시대에도 모두가 같은 기반을 각자 다시 만들고 있는 산업의 구조를 향한 문제 제기였다.

글 | 한상민 기자 _ han@autoelectronics.co.kr
IN ENGLISH








40개 미들웨어는 너무 많다

“40개의 미들웨어는 너무 많습니다. 40이라는 숫자는 수사가 아닙니다. 우리가 실제로 세어본 숫자입니다.”
7월 1일 아침 9시 수원컨벤션센터. AID 2026의 첫 번째 마이크를 잡은 ETAS의 데틀레프 제르포브스키(Dr. Detlef Zerfowski) 엔지니어링 엑설런스 부사장이 던진 첫 마디였다. 
유럽과 미국, 중국을 오가며 목격한 소프트웨어 정의 차량(SDV) 생태계에서, 지금 이 순간 실제로 개발되고 있는 미들웨어의 개수가 40개에 달한다는 것이다. 그리고 그는 곧바로 이 발표에서 가장 중요한 말을 던졌다.
“우리는 여러 OEM이 모든 것을 스스로 하려다 처참하게 실패하는 것을 봤습니다. 이건 믿음이 아니라, 실제로 지켜본 결과입니다.”
30분짜리 키노트, 여기에 발표 전체의 결론이 들어 있었다. SDV 시대에 자동차 산업이 반복하고 있는 실수, 그리고 그 실수를 되풀이하지 않기 위한 해법 ‘Open Core’, 그 실체인 Eclipse S-CORE 프로젝트. 그렇게 Automotive Innovation Day 2026이 막을 올렸다.







소프트웨어는 소프트웨어가 아니다

제르포브스키의 발표는 통념을 깨는 것에서 시작했다.
“많은 사람들이 ‘소프트웨어’를 이야기합니다. 그런데 그 말은 이미 틀렸습니다(That’s already wrong). 자동차 안팎에는 근본적으로 다른 다섯 개의 소프트웨어 세계가 존재합니다.”
그림은 이렇다. 첫째, 깊이 임베디드된 ECU(Deeply Embedded ECU). 엔진 관리, ESP, 에어백을 제어하는 하드 리얼타임(hard real-time) 소프트웨어의 세계다. CAN, FlexRay, 기능안전성(ISO 26262), V-모델, ASPICE란 익숙한 단어들이 지배한다. 
“이 소프트웨어는 물리적 실체와 매우 가깝습니다. 내연기관을, 차량 거동을, ESP의 동작 방식을 이해해야 합니다.” 이건 바로 제어 엔지니어의 영역이다.
둘째, 마이크로프로세서 기반의 차량 컴퓨터(Vehicle Computer). 카메라, 라이다, 초음파 데이터가 흘러드는 데이터 기반 세계다. 이런 소프트웨어는 컴퓨터 과학자들이 만드는 것이지, 프로그래밍을 배운 제어 엔지니어가 만드는 것이 아니다. QNX나 Linux 같은 POSIX 기반 운영체제가 하드웨어와 상위 소프트웨어 레이어를 분리해주는 세계이기도 하다.
셋째, 클라우드(Cloud). OTA와 원격 서비스가 살아 있는 영역. 자동차 산업이 최근에서야 도입하고 있는 DevOps 방식은 사실 클라우드 개발에서는 이미 오래전부터 확립되어 있던 것이다. 넷째, 인포테인먼트(Infotainment). 안드로이드와 iOS가 이미 주도권을 가져간, 그러나 기능안전성과는 무관했던 세계다.
마지막은 흔히 잊히는 영역인 툴링(Tooling)이다. AI 기술을 기반으로 지금 가장 빠르게 발전하고 있는 영역이지만, 이 역시 앞의 네 가지와는 완전히 다른 배경에서 나온다. 
이 다섯 세계는 개발 방식도, 필요한 인력도, 심지어 사고방식도 서로 다르다. 그래서 제르포브스키가 한 말은, “단 하나의 회사가 이 모든 것을 혼자서 소유하고 주도할 수는 없습니다”였다.



SDV의 진짜 문제는 기술이 아니라 경제

발표의 두 번째 축은, 어쩌면 청중이 가장 곱씹어야 했을 대목이다. 제르포브스키가 짚은 문제는 기술적 난이도가 아니라 산업의 구조, 즉 경제였다.
그는 슬라이드 하나에 OEM이 겪는 여섯 가지 고통을 정리해 넣었다. 시장 출시 시간(Time-to-Market)과 혁신 압박, 중복된 개발·통합·검증 노력, 벤더 락인(Lock-in), 조직 파편화, 컴플라이언스 부담, 그리고 20년 이상 지속되는 유지보수. 그리고 그 위에 ‘콘웨이의 법칙(Conway’s Law)‘을 겹쳐 올렸다.
“여러분은 오직 여러분 자신의 조직 구조에 따라서만 무언가를 개발할 수 있습니다. 개발 부서들이 여전히 사일로화돼 있다면, 그 결과물인 소프트웨어도 서로 맞물리지 않습니다.” 제르포브스키가 말했다.
이것은 단순한 조직론이 아니다. 지금 자동차 업계에 미들웨어가 40개나 존재하는 이유를 그는 이 법칙 하나로 설명했다. 즉 40개의 미들웨어는 기술이 부족해서 생긴 결과가 아니라, 40개의 서로 다른 조직이 각자의 벽 안에서 각자의 답을 만든 결과다.
모두가 똑같은 것을 반복해서 만들고 있다. 바닥 공사를 다시 하고, 또 하고, 또 하는 것. 이것이 그가 진단한 SDV 산업의 진짜 문제다. 그리고 회사의 몸집이 작을수록 이 중복 비용의 부담은 더 커진다. 시장 출시 시간, 락인, 파편화, 유지보수 등 모든 고통은 하나의 근본 원인, ‘경제적으로 감당할 수 없는 중복’에서 갈라져 나온 증상들이다.



자동차는 스마트폰이 아니다

“우리는 지금 스마트폰 이야기를 하는 게 아닙니다. 결함이 있는 소프트웨어를 탑재한 휴대폰, 혹은 보안이 뚫린 휴대폰은 여러분의 생명에 위협이 되지 않습니다. 하지만 시속 100, 150킬로미터로 고속도로를 달리고 있는 중에 여러분의 차가 멈춘다면, 그것은 여러분 자신의 생명뿐 아니라 다른 사람들의 생명까지 위협할 수 있습니다.”
이 대조는 발표 전체를 떠받치는 철학이다. 차량용 오픈소스가 일반적인 오픈소스와 결코 같을 수 없는 이유다. 그는 이를 ISO 26262 기반의 인증(Homologation), 제동·조향·운전자 지원에 적용되는 ASIL 등급, 지름길 없는 광범위한 테스트, 새로운 취약점이나 오작동을 절대 허용하지 않는 소프트웨어 업데이트, 그리고 20년 이상 지속되는 유지보수 등 구체적인 목록으로 풀었다. 그리고 이런 철학이 향한 곳이 보안이었고, 반복해서 강조한 단어가 소프트웨어 유지보수와 보안 위험성이었다. 이 두 가지 모두 앞으로 몇 달, 몇 년 사이에 크게 증가할 것이기 때문이다. 
성공적인 사이버 공격이 차량 안전을 직접 훼손할 수 있고, 극단적으로는 누군가가 차량을 해킹해서 원격 무기로 사용하는 시나리오까지 이어질 수 있다. 자동차 산업에서 오픈소스가 그저 ‘무료 소프트웨어’가 아니라, 20년짜리 안전·보안 책임을 짊어진 인프라가 돼야 하는 이유다.







Open Core라는 답

문제, 원인, 제약이 모두 제시된 자리에서 제르포브스키는 ‘Open Core’란 해법을 꺼냈다.
OEM 각자 앱-미들웨어-OS/가상화-코어 미들웨어 레이어-HPC까지 똑같은 구조를 따로따로 쌓아 올리는 모습이 있고, 다른 쪽엔 그 밑단을 하나의 공유된 오픈 코어로 모으고, OEM과 통합자, 하드웨어 티어가 그 코어를 둘러싼 커뮤니티로 함께 참여하는 그림이 있다.
“협업 접근법을 취하더라도 그 기능은 사내에서 자체 개발했을 때와 정확히 동일합니다. 초기 제품 기능성은 어느 쪽이든 동일합니다.” 제르포브스키가 말했다.
즉 Open Core는 기능을 희생하는 타협이 아니라, 같은 결과를 훨씬 적은 중복 비용으로 얻는 구조다. 그 위에서 얻는 이득은 비용 효율성, 짧은 시장 출시 시간, 지속적인 혁신, 강화된 취약점 탐지, 그리고 효율적인 SW 라이프사이클 유지보수로 이어진다.  
이 Open Core의 실제 이름은 Eclipse S-CORE.
“S-CORE는 2022년경, 유럽연합이 유럽 자동차 산업의 공공 자금 지원 프로젝트를 논의하던 자리에서 시작됐습니다. 저는 개인적으로 그 초기 논의에 참여했습니다.” 제르포브스키는 이 프로젝트의 태생을 직접 증언했다. 
2025년 5월 12~14개 유럽 기업이 VDA 주도로 양해각서(MoU)에 서명했다. 그는 이 MoU의 공동 저자였다. 이후 책임이 Eclipse Foundation으로 넘어갔다. 2026년 1월 CES에서는 BMW, Mercedes-Benz, Stellantis, Bosch, Qualcomm, 그리고 한국의 42dot, LG, 현대모비스 등을 포함한 훨씬 더 많은 기업이 서명 명단에 이름을 올렸다.
이것이 작동하는 이유는 세 가지 원칙 때문이다. 벤더 중립적 거버넌스(어느 한 회사도 프로젝트 방향을 좌우하지 않는 평평한 운동장), 견고한 IP 관리(읽을 수만 있고 기여할 수는 없는 ‘가짜 오픈소스’와의 결정적 차이), 그리고 상업 친화적 라이선싱(여러분의 미들웨어 위에 쌓은 독점적 레이어를 오픈소스로 공개하도록 강요받지 않습니다)이다. 그리고 여기에 자동차 산업 전체의 사고 전환을 요구하는 한 가지가 더 올려진다.
“명세 우선이 아니라 코드 우선(Code-first, not specification-first)입니다. 우리는 늘 요구사항 우선으로 접근해 왔습니다. 이제는 그 반대입니다.”



S-CORE는 하이프가 아니라 현실이 됐다

제르포브스키는 Eclipse S-CORE의 그간 성과에 대해 이야기하기 시작했다. 
2024년 10월 시작된 S-CORE는 그해 12월 약 3,000줄이던 코드가 2025년 3월 30만 줄, 9월 78만 줄을 거쳐 2026년 6월 현재 190만 줄에 도달했다. 기여자는 약 454명이다. 지난 6개월 동안만 2,000건 이상의 풀 리퀘스트가 통합됐고, 4,000건 이상의 풀 리퀘스트가 2024년 12월 이후 종료됐다. 처리 속도는 대부분 24시간 이내.
“우리는 지금 몇 주, 몇 달이 아니라, 몇 시간 단위를 이야기하고 있는 것입니다.” 
제르포브스키가 강조했다.
상위 기여자의 70%는 하나가 아닌 여러 프로젝트 영역을 넘나들며 활동하고, 코드 기여의 절반은 제출된 바로 그날 병합된다. 제기된 작업 항목 3건 중 2건은 원래 담당자가 아닌 다른 커뮤니티 멤버가 해결한다.
즉, S-CORE가 더 이상 유럽발 정책 문서 속 개념이 아니라, 살아 움직이는 개발 커뮤니티라는 것이다. 그리고 이 신뢰를 바탕으로 로드맵이 뒤따르고 있다. v0.5는 2025년에 공개됐고, v1.0은 2026년 안에 완성돼 OEM과 티어 1의 실제 개발에 쓰일 수 있다. ETAS의 배포판인 Vehicle Software Platform Suite는 2027년 개발 착수 준비를 마치고, 2028년 기능 완성, 그리고 2029년 양산 개시(SOP)에 도달한다.
“이 방식의 솔루션을 채택하고자 하는 OEM은 2029년경부터 본격적인 양산 차량 출시에 이를 사용할 수 있습니다.”
그는 자동차 산업 특유의 신중함도 함께 짚었다. S-CORE 프로젝트 자체가 안전 인증서를 받는 것은 아니다. 계속 변화하는 오픈소스 코드 베이스는 애초에 인증 대상이 될 수 없기 때문이다. 대신 S-CORE는 처음부터 자동차 업계의 안전 규칙에 맞춰 설계돼 있어 이를 가져다 제품화하는 티어 1들이 자신의 배포판을 인증받기가 훨씬 쉬워진다. 실제로 이날 로드맵에서도 인증 대상으로 표시된 것은 S-CORE 자체가 아니라, 그다음 단계인 ETAS의 배포판이었다.







OEM은 무엇을 만들어야 하는가

발표의 마지막에 제르포브스키는 이 모든 이야기를 하나의 실질적 아키텍처로 정리했다.
예를 들어, ETAS의 Vehicle Software Platform Suite에서, 마이크로컨트롤러의 하드 리얼타임 영역은 여전히 AUTOSAR Classic이 지킨다.
“저는 AUTOSAR Classic이 사라진다고 말하는 것이 아닙니다. 절대 아닙니다.”
대신 마이크로프로세서 쪽, QNX와 Linux 위에서 ADAS/AD 프로파일, 범용 프로파일, 빠른 앱 개발 프로파일이라는 세 갈래로 S-CORE 기반의 새 층이 자리 잡는다.
즉 미래는 대체가 아니라 공존이다. MCU에는 AUTOSAR Classic, HPC에는 S-CORE다. 그리고 이 아키텍처가 향하는 최종 목적지는, 공통의 기반은 함께 짓고 OEM은 그 위에서만 차별화하는 것이다.
“여러분의 개발 팀이 다른 모든 사람도 똑같이 다시 만들고 있는 동일한 기반 배관을 다시 만드는 대신, 실제로 여러분을 차별화하는 기능을 만드는 데 집중할 수 있도록 해주는 것입니다.”
이것은 30분 전 강연을 연 말, “40개의 미들웨어는 너무 많습니다. 오픈소스 기반의 솔루션으로 함께 나아갑시다”와 같은 이야기다.
그의 30분은 이렇게 정리할 수 있다. SDV의 승자는 모든 것을 만드는 기업이 아니라, 무엇을 함께 만들고 무엇을 차별화할지 아는 기업이다. 



AEM(오토모티브일렉트로닉스매거진)



<저작권자 © AEM. 무단전재 및 재배포 금지>


  • 100자평 쓰기
  • 로그인



TOP