Right-sized SDV: 변형을 줄이고, 속도를 얻는 설계

CES 2026에서 Elektrobit(EB)가 강조한 것은 새로운 기능이 아니라 SDV를 감당하는 방식이었다. 수직으로 쪼개진 구조를 수평으로 풀고, Semantic API로 변형을 줄이며, Cost/Value Zone으로 비용과 업그레이드를 분리하는 설계. EB의 SDV는 이제 기술 데모가 아니라 운영 모델로 경쟁한다.

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





SDV는 기술이 아니라 계산서다. 현장에서 SDV를 가로막는 건 기능이 아니라 비용, 일정, 인력, 그리고 변형(variant) 관리다. SDV로 가려는 순간 OEM이 가장 먼저 계산하는 것도 결국 이것들이다. Elektrobit(이하 EB)가 CES 2026에서 꺼낸 화두도 이 불편한 계산서에 가까웠다. EB는 SDV를 ‘갈아엎는 혁명’이 아니라, 감당가능한 비용으로 단계적으로 올라타는 구조로 바꿔야 한다는 것을 보여줬다. EB 코리아의 조정우 대표는 전통적인 개발 방식이 왜 SDV에서 한계에 부딪히는지부터 짚었다. 
OEM이 1차 협력사를 복수로 운영하는 순간, 제어기 하나만 놓고 봐도 변형이 폭발한다. 하드웨어도 다르고, 소프트웨어 플랫폼도 다르고, 애플리케이션 구조까지 갈라진다. 조 대표는 이를 단순히 ‘복잡하다’고 표현하지 않았다.
“하나의 OEM이 동일한 지역에 대해 1차 사를 두 개, 세 개 이상 가져가잖아요. 그러면 관리하는 제어기만 해도 두세 개의 변형이 생깁니다. 이 곱하기로 늘어나는 복잡성이 SDV의 첫 장벽입니다.” 
조직이 만들고 싶은 기능은 많다. 하지만 그 기능을 올릴 그릇이 수직으로 쪼개져 있으면, 개발도 검증도 업데이트도 변형 관리도 끝없이 느려진다. EB가 제시한 답은 수직 계열(Vertical)에서 수평 구조(Horizontal)로의 전환이다.



폭스콘과 ‘Smart EV 플랫폼’이 던진 질문  

EB는 작년부터 대만의 폭스콘과 협업해 ‘Smart EV 플랫폼’을 구축해 왔다. 폭스콘이 레퍼런스 하드웨어 플랫폼을 제공하고, EB는 그 위에 올라가는 소프트웨어 플랫폼을 제공한다. 그리고 그 위에서 SDV 애플리케이션이 작동한다. 
얼핏 들으면 흔한 분업처럼 보인다. 조 대표도 “여기까지는 다른 데와 크게 다를 것이 없어 보인다”고 말한다. 하지만 EB가 여기서 꺼내는 질문은 분업 자체가 아니라 OEM이 SDV를 어떤 방식으로 감당할 것인가다.
EB가 CES 2026에서 이 구조를 설명할 때 반복해 쓴 표현은 ‘공급망을 다시 짜는 언어’였다. “Rethinking The Supply Chain.” 
그리고 목적은 분명하게 “Reduce Time-to-Market and Enable Build-to-Print.” 
SDV를 거대한 맞춤형 프로젝트로 끌고 가는 대신, 시장 투입 시간을 줄이고, 제조까지 사양 기반으로 끌어내리는(build-to-print) 구조를 만들겠다는 것이다. 
전통적인 방식은, OEM이 티어 1에 제어기를 요청하면 그들이 하드웨어를 설계하고, 소프트웨어 플랫폼은 외부에서 구매하며, 애플리케이션은 다시 개발해 수직적으로 쌓아 올리는 구조다. 이 구조는 한 번 구축되면 익숙하지만 복수의 티어 1이 동시에 존재하고, 플랫폼과 하드웨어가 갈라지기 시작하면 변형은 급증한다. 결국 SDV의 비용과 시간이 기능 개발이 아니라 변형 관리의 지옥에서 터진다.
EB가 폭스콘 협업을 통해 시도한 것이 바로 이 수직 구조를 ‘수평으로 풀어’ 선택지를 늘리는 것이다. 하드웨어 제조는 폭스콘에 맡길 수도 있고 기존 티어 1이 계속 맡을 수도 있다. 폭스콘은 텔레매틱스, VCU, ADAS 도메인 컨트롤러, IVI, 센트럴 HPC 등 고성능 제어기 영역에 대한 레퍼런스 하드웨어 디자인을 제공하고, EB는 그 위에 올라가는 소프트웨어 플랫폼을 제공한다. 결국 ‘누가 만들든 상관없이’ 아키텍처를 수평 분리해 관리 가능하게 만드는 구조다.
여기서 중요 포인트는 ‘누가 하드웨어를 만들었느냐’가 아니라, OEM 입장에서 SDV를 진행할 때 비용·시간·인력 부담을 줄일 수 있는 선택지가 생겼다는 점이다. 
“특히 EB가 말하는 타깃이 대기업만이 아니라는 점입니다. 예산과 인력이 제한된 중소 OEM, 혹은 SDV 요구를 함께 떠안아야 하는 티어 1에게 이 선택지가 더 직접적인 의미를 갖습니다.”


 

Semantic API: ‘변형을 없애는 레이어’   

수평 구조로 분리하자는 말은 업계에서 이미 익숙하다. 하드웨어 추상화 레이어, 플랫폼과 앱의 분리, 재사용성 같은 개념은 오래 이야기돼 왔다. 하지만 EB가 CES 2026에서 한 걸음 더 나간 지점은, 이 분리가 실제로 ‘비용을 줄이는 결과’로 이어지려면 신호와 인터페이스가 통일돼야 한다는 데 있다. EB가 그 역할로 내세운 개념이 바로 ‘Semantic API’다.
조 대표는 COVESA의 차량 신호 표준화를 직접 언급하며 브랜드마다 플랫폼마다 차량 신호 체계가 다른 현실을 그대로 유지하면서도 그 위에서 동일한 방식으로 기능을 개발할 수 있는 레이어가 필요하다고 했다.
“Semantic API 위에서는 어떤 모델을 가든 어떤 브랜드를 가든 다 동일하다는 얘기입니다.”
이게 EB의 SDV 접근을 요약한다. 
핵심은 레거시를 부정하지 않는 것이다. 기존 제어기와 기존 소프트웨어를 가능한 한 유지한다. 그리고 최소 하나의 고성능 HPC를 올린다. 그 사이에 ‘변환 레이어’를 둬 브랜드별 신호 차이를 흡수한다. 그러면 위쪽은 차종이 바뀌어도 브랜드가 바뀌어도 동일한 개발 방식으로 움직일 수 있다.
CES 현장 데모 화면은 이것을 더 직설적으로 설명한다. Semantic API는 차량 데이터와 기능을 노출해 ‘독립적인 기능 개발’을 가능하게 하고, 더 중요한 건 구성 차이가 나도 ‘소프트웨어 변형을 만들지 않게(without introducing software variants)’ 만든다는 것이다. 변형이 곱하기로 늘어나는 구조를 관리 가능한 ‘한 층’으로 압축하는 접근이다.
EB는 이 아랫단을 ‘SDV Cost Zone’이라고 부른다. 레거시 ECU를 크게 흔들지 않는다는 뜻이고 비용을 통제할 수 있다는 의미다.
“이 Semantic API가 적용되는 아랫 단계를 SDV 코스트 존이라고 합니다. 기존 제어기를 그대로 거의 유지할 수 있다는 얘기니까요.”

 


SDV Cost Zone과 SDV Value Zone:
비용은 묶고, 업그레이드는 빠르게 

레거시를 흔들지 않으면 비용이 줄어든다. 하지만 SDV가 의미를 가지려면 위쪽에서 기능을 계속 올려야 한다. 그래서 EB는 구조를 둘로 나눈다. 
“Drive for value and optimize cost.” 그리고 그 결론은 “Separation into SDV value zone and SDV cost zone”이다.
여기서 Value Zone은 업그레이드가 일어나는 영역이다. 데모 화면이 말하는 논리는, 기능 업그레이드는 중앙 컨트롤러에서 빠르고 자주 수행돼야 한다. 그러려면 아래쪽은 Cost Zone으로 안정화돼 있어야 하고, 위쪽은 Semantic API를 통해 브랜드와 차종을 넘어 동일한 방식으로 관리돼야 한다.
이 구분이 바로 ‘Right-sized SDV’의 실체다. 전체를 갈아엎지 않아도 비용을 방어하며 SDV로 올라탈 수 있다. EB의 메시지는 ‘올인(all-in)이 아니라 리스크를 통제하면서 진행하라’에 가깝다.


 

단계적 SDV가 Right-sized SDV다: 
화이트라벨부터 개별 ECU까지  

EB가 보여준 도입 방식은 단일 경로가 아니다. EB는 ‘Flexible adoption options’란 문구 그대로 화이트라벨 차량에서 시작해 소프트웨어 플랫폼만 가져가거나, 개별 ECU 단위로 들어가는 단계까지 옵션을 분기한다. 즉, 필요한 속도와 규모로 SDV를 시작하라는 제안이다.
“SDV라고 하면 OEM 입장에서 망설여지는 게 비용과 시간, 인력입니다. 큰 회사는 감당할 수 있어도 중소 OEM이나 티어 1을 위해선 선택의 여지가 필요합니다.”
이는 EB의 전략이 기술보다 운영에 가까운 이유를 보여준다. SDV 전환은 결국 조직의 능력치와 투자 규모가 결정한다. EB는 그 격차를 ‘단계’로 풀어낸다. 레거시를 최대한 유지하며 비용을 방어하고, Semantic API와 HPC 레이어에서 기능 확장을 빠르게 만들고, 필요에 따라 폭스콘 레퍼런스 하드웨어와 EB 소프트웨어 플랫폼을 결합해 화이트라벨 형태로도 제공한다. 고객사가 폭스콘이나 EB 브랜드를 드러내지 않고 자체 브랜드로 가져가고 싶다면 그 방식도 가능하다.
물론, 독자적으로 SDV를 구축하려는 움직임이 강한 곳에는 이 모델이 직접 들어가기 어려울 수도 있다. 하지만 이게 대기업은 안 쓴다는 뜻은 아니다. 오히려 대기업일수록 모든 것을 내부에서 감당하는 방식이 위험하다는 교훈을 이미 경험하고 있기 때문이다. 
“폭스바겐 사례처럼 대규모 자금을 투입한다는 게 위험하다는 걸 알기 때문에, 큰 회사들도 부분적으로 수요가 있습니다.”

 


‘신제품’은 콕핏: EB civion

콕핏은 기능이 가장 빨리 바뀌는 영역이면서, 동시에 검증과 통합이 가장 느린 영역이다.
Smart EV 플랫폼과 Semantic API가 SDV의 구조를 설명한다면, EB civion은 그 구조를 실제로 굴리는 방법을 보여주는 제품이다. 조 대표가 CES 현장에서 가장 길게 설명한 것도 civion이었다. SDV의 현실적인 병목은 결국 콕핏 개발과 통합 단계에서 터지기 때문이다.
기존 콕핏 개발은 바꾸는 데 오래 걸린다. 코드를 수정하고, 빌드하고, 통합하고, 테스트를 돌리고, 결과를 확인한다. 작은 변경 하나에도 짧게는 일주일, 길게는 며칠이 걸린다. EB는 이 과정을 ‘클라우드 기반 가상 환경’에서 압축한다. 
조 대표가 강조한 것은 개발자가 코드를 직접 만지지 않는다는 점이었다.
“브라우저에서, Figma 같은 UX 디자인 툴로 클릭하고 설정하면 결과물이 자동으로 컴파일되고 인테그레이션됩니다. 테스트 케이스도 자동으로 생성되고요.”
civion의 화면이 보여주는 흐름도 같은 방향이다. Figma에서 UI를 설계하면, 컴포넌트가 자동 생성되고(예: Jetpack Compose 기반), 구조가 매핑되며, 차량 데이터는 HAL(Hardware Abstraction Layer)로 이어진다. 즉, 디자인-로직-데이터가 분리된 채 자동 연결돼 개발 루프가 짧아진다.
“이런 변경 사항이 짧게는 1~2분 안에도 될 수 있다는 게 큰 차이점입니다.”
EB는 civion이 갑자기 나온 제품이 아니라, 3년 전부터 소니, 혼다와 진행해 온 아필라 프로젝트의 결과물을 제품화한 것이라고 설명했다. 즉, civion은 개념이 아니라 프로젝트에서 검증된 방식을 떼어내 제품군으로 만든 것이다.
civion은 3개의 제품군으로 나뉜다. 가상화된 CI/CD 개념의 도구를 ‘Creator’, 타깃 소프트웨어 플랫폼을 ‘Core’, 여기에 하드웨어까지 포함해 완성도를 높인 구성을 ‘Cockpit’으로 묶는다. EB는 CES 2026 현장에서 civion을 AMD Ryzen 기반과 Qualcomm 기반으로 각각 구동하는 데모를 동시에 선보였다.
여기에 생성형 AI 요소도 붙었다. EB는 데모에서 구글 Gemini를 연결해 테마 생성 기능을 시연했다. 예를 들어 ‘한국 관련 테마를 적용해 달라’고 지시하면 일정 시간이 지난 후 테마가 생성돼 적용되는 방식이다. EB는 이를 테마 엔진으로 부르는데, 콕핏이 소프트웨어화될수록 디자인·브랜딩 요소까지도 개발 흐름에 포함된다는 점을 보여준 것이다.


 


EB의 ‘감당 가능한 SDV’

EB의 SDV는 멋진 기능이 아니라 운영가능한 구조다. 수직으로 쪼개진 공급망과 개발 구조는 SDV에서 변형 지옥을 만든다. EB는 Smart EV 플랫폼으로 하드웨어·소프트웨어·애플리케이션을 수평으로 분리하고, time-to-market과 build-to-print를 목표로 공급망을 재설계하는 모델을 제시했다. 그리고 Semantic API로 브랜드와 차종의 신호 차이를 흡수해, 구성 차이가 나도 소프트웨어 변형을 만들지 않게 하며, SDV Cost Zone과 SDV Value Zone으로 비용과 업그레이드 영역을 분리했다. 마지막으로 civion은 그 구조를 콕핏 개발의 시간으로 증명하는 바로 시작 가능한 제품군으로 제시됐다.
EB의 SDV는 레거시를 유지할 수 있는 아래쪽에서 비용을 방어하고(SDV Cost Zone), Semantic API와 중앙 컨트롤러 레이어에서 업그레이드를 빠르고 자주 가능하게 만들며(SDV Value Zone), 단계적으로 선택가능한 도입 옵션을 제공한다. 그래서 ‘Right-sized SDV’의 의미가 바로 여기에 있다. SDV의 야망은 커지고 있지만, 모든 조직이 같은 방식으로 전환할 수는 없다. EB는 그 각각의 격차를 ‘단계’로 해결하는 설계도를 꺼내 보였고, civion은 그 설계도를 제품으로 내놓은 결과물이었다.
​​​​​​​

 

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

---