Vector Informatik Dr.-Ing. Marc Weber   벡터 인포매틱 마크 베버 박사    

소프트웨어 정의 자동차(SDV)와 e모빌리티에 대한 벡터의 통찰을 공유하는 행사인 ‘Vector Tech Day 2023’이 지난 8월 30일 서울 여의도 콘래드 서울에서 열렸다. 벡터 임베디드 소프트웨어 수석관리자 마크 베버 박사는 “SDV를 위한 임베디드 솔루션: Vehicle OS부터 백엔드 커넥션까지”를 주제로 기조연설을 했다. 현장에서 연설을 마친 마크 베버 박사와 SDV, Vehicle OS (Automotive OS)를 화두로 인터뷰를 했다. 표준화된 Vehicle OS의 탄생 가능성, 라이프사이클을 고려한 차량 하드웨어의 적정선에 대해 물었다.  

글｜윤범진 기자_bjyun@autoelectronics.co.kr


마크 베버(Marc Weber) 박사는 벡터의 솔루션 관리 임베디드 소프트웨어 수석 관리자다. 그는 독일 에슬링겐 응용과학대학에서 컴퓨터과학(학사)과 자동차 시스템(석사)을 전공했다. 졸업 후 2011년 벡터에 입사했다. 벡터에서 차량 내 통신 네트워크로 이더넷을 도입하는 작업을 수행했으며 2013년부터 2017년까지 임베디드 이더넷 통신 스택의 기술 제품 관리를 담당했다. 2016년에는 카를스루에 공과대학에 과학 연구원으로 합류하여 자동차 전자제어장치(ECU)의 이상 및 침입 탐지라는 주제에 집중했으며, 현재 벡터에서도 이 업무를 담당하고 있다. 현재 임베디드 ECU는 비용에 민감하고 서버 시스템보다 컴퓨팅 성능과 메모리 자원이 제한적이므로 효과적이고 효율적인 임베디드 ECU용 신경망 구현에 집중하고 있다.







Q. 커넥티드, 자율주행, 전기화 및 차량 공유와 함께 왜 자동차 업계가 ‘소프트웨어 정의 자동차(SDV)’에 주목할까요?

A. 지속해서 증가하는 고객(최종 소비자)의 기대치에 부응하기 위한 움직임이라고 봅니다. 고객은 기능 업데이트뿐만 아니라 소프트웨어를 통해 차량을 개인화(personalization)하기를 희망합니다. 이런 요구를 자동차 OEM은 도전과제로 인식하고 있습니다. OEM은 이를 실현하기 위한 하나의 전제조건으로 SDV에 관심을 두기 시작했습니다. 예를 들어 지속적인 기능 업데이트로 최적화된 성능을 유지하는 스마트폰처럼 고객이 차량과 상호작용하고 개인화하고 차량에 새로운 기능을 추가하는 수단으로서 SDV에 관심을 두게 된 것입니다. 모바일 산업이 일종의 개척자 역할을 했다고 봅니다. 

OEM은 SDV를 통해 자동차의 라이프사이클 전반에 걸쳐 가치를 높일 방법을 모색하고 있습니다. 궁극적인 목표는 차를 판매한 이후에도 계속해서 기능을 추가할 수 있도록 하는 것입니다. OEM 입장에서는 이를 통해 새로운 수익 모델을 찾을 수 있습니다. 차를 판매하는 것만으로 수익을 내는 것이 아니라, 판매 이후에 소프트웨어 업데이트를 제공함으로써 애플이나 구글처럼 새로운 수익을 창출할 수 있게 되는 것입니다. 스티브 잡스는 “자동차야말로 궁극의 모바일 기기”라고 했습니다. 실제로 자동차 업계가 그 방향으로 움직이고 있습니다. 벡터의 고객 역시 자동차가 모바일 기기처럼 사용될 수 있기를 기대하고 있음을 확인할 수 있습니다.



Q. 자동차 산업은 SDV로의 전환 과정에서 필연적으로 레거시 코스트를 수반하게 될 것입니다. 유럽도 크게 다르지 않으리라 생각합니다. 

A. 동의합니다. 현재 자동차 산업은 패러다임의 전환 시기를 맞고 있다고 할 수 있습니다. 어떻게 보면 자동차 산업 역사상 최대의 전환기가 아닐까 싶습니다. 다만 그 과정에서 발생하는 쟁점을 ‘갈등’이라고 표현하고 싶지는 않습니다. 논의의 필요성 또는 공통의 이해를 구하는 과정이라고 생각합니다. 이 과정에서 열린 자세가 필요합니다. 새로운 패러다임이 등장하고 있다는 것을 인식하고 과거에 집착하지 않되 과거를 무시하거나 잊어서는 안 됩니다. 레거시가 분명히 존재하는 상황에서 SDV를 일방적으로 강행하기는 불가능하다고 생각합니다. 기계공학, 임베디드, IT 기술 간 융합을 위한 산업 간 협력이 필요합니다. 협력을 위해서는 각자의 의견을 새로운 시각이나 태도 또는 문화라고 인식해야 합니다. 

독일 OEM은 SDV를 하나의 비전으로 삼고 관련 계획을 수립한 상황입니다. 물론 SDV로 가는 길이 평탄치 않겠지만 가치가 있는 길이자 방향이라고 생각합니다. 조직 구성원에게 회사의 방향에 무조건 따르라고 하기보다는 이들이 이해할 수 있도록 그 배경을 충분히 설명하고 동기를 부여하는 자세가 필요합니다. 현재 거의 모든 OEM이 실행 속도는 다를지언정 SDV가 옳은 방향이고 자동차 산업의 미래라는 데 동의하고 있습니다. 한 가지 덧붙이자면, 이제 모든 회사가 이 거대한 흐름 앞에 처음엔 단독으로 시작했지만 더는 혼자 진행할 수 없음을 인식한 것 같습니다. 점점 더 외부 파트너와 협업하려는 움직임이 확산하고 있습니다. 



Q. OEM이 SDV 체제로의 전환을 가속화하기 위해 대규모 IT 인재 확보에 나서고 있습니다. 이런 사정은 독일도 크게 다르지 않으리라 생각합니다. OEM이 IT 인력을 블랙홀처럼 빨아들이는 게 과연 올바른 방향일까요?

A. 독일도 다르지 않습니다. OEM은 수천 명의 소프트웨어 엔지니어를 채용하겠다는 계획을 계속해서 발표하고 있습니다. 그럴 필요가 있다고 봅니다. 조직에 새로운 아이디어와 인재, 그리고 태도를 수혈해야 하니까요. SDV는 새로운 역량이기 때문에 기존 인력을 재교육하는 것도 상당히 어려운 실정입니다. 

OEM이 소프트웨어 엔지니어를 채용할 경우, 먼저 어디까지 업무를 담당해야 할지 범위 설정이 필요하다고 봅니다. OEM의 자체 소프트웨어 개발 역량도 필요하고 인력 채용도 필요하지만, OEM이 할 일이 따로 있습니다. 예를 들어 드라이버 같은 하위 소프트웨어까지 개발하기 위해 엔지니어를 채용할 필요는 없다고 봅니다. 차별화된 고객 경험을 제공할 수 있는 애플리케이션을 개발하겠다는 목표를 설정해 놓고 소프트웨어 개발 인력을 채용하는 태도가 중요하다고 생각합니다. 



Q. OEM이 운영체제(OS)부터 프로세서와 같은 고성능 반도체를 자체 개발하는 것은 어떻습니까? 

A. 대답은 ‘아니오(No)’입니다. 업계도 동의하고 있다고 생각합니다. OEM이 브랜드를 차별화해 주지 못하는 소프트웨어를 개발하기 위해 자원을 추가 확보할 필요는 없습니다. 나중에 다시 언급할 것 같은데, Vehicle OS는 다릅니다. 
OEM이 OS까지 개발할 필요는 없다고 봅니다. 소비자 관점에서 OS는 OEM의 차별화 요소가 아니기 때문입니다. OEM은 시스템에 대한 이해를 바탕으로 전체의 작업을 조율하는 오케스트레이터(Orchestrator)로서 역할을 할 수 있습니다. OEM은 인력을 채용해서 브랜드를 차별화할 수 있는 UI(User Interface)나 주행 기능 또는 애플리케이션 소프트웨어를 개발할 필요가 있습니다. 소비자는 차량 내에서 ECU 간 신호가 어떻게 전달되는지 전혀 관심이 없습니다. 차별화 요소가 될 수 없다는 의미입니다. 이 경우 협력사 또는 표준에 의존할 수 있습니다. 




그림 1 | SDV 시대의 토폴로지 ⓒVector Informatik 



Q. Vehicle OS는 일반적 의미의 운영체제가 아니어서 오해의 소지가 있습니다. 벡터가 말하는 Vehicle OS란 무엇이며, SDV에서 어떤 역할을 담당하나요?

A. OS라는 용어로 인해 리눅스와 같은 운영체제로 오해하는 경우가 많은 것 같습니다. SDV의 핵심 구성요소인 Vehicle OS는 하나의 제품을 설명하는 게 아닙니다. Vehicle OS에는 여러 가지 구성요소가 있습니다. 

첫 번째 구성요소는 차량용 애플리케이션을 구동하는 소프트웨어 플랫폼입니다. 여기에는 운영체제와 미들웨어가 있고 그 위에서 애플리케이션이 개발됩니다. 벡터는 이런 기초적인 기능을 하는 애플리케이션 소프트웨어를 위한 프레임워크를 제공하는 런타임 소프트웨어(Runtime Software)를 베이스 레이어(Base Layer)라고 합니다. 베이스 레이어에는 MICROSAR Classic 등 다양한 빌딩 블록이 필요합니다. ECU의 경우, 아주 작은 ECU에서부터 고성능 컴퓨팅(HPC)에 이르기까지 다양한 클래스가 있습니다. 각 타깃 ECU마다 빌딩 블록이 다를 수 있습니다. 

두 번째 구성요소는 소프트웨어 팩토리(Software Factory)입니다. 이것은 워크플로(Workflows)와 일종의 툴로 보면 됩니다. 소프트웨어 팩토리는 Vehicle OS 인프라로서 개발자가 베이스 레이어와 애플리케이션을 개발, 통합 및 배포하는 과정을 지원하고 자동화합니다. 

세 번째 구성요소는 기업 간 협업입니다. 지원 빌딩 블록과 에코시스템을 통한 OEM과 협력업체 간의 긴밀하고 민첩한 협업이 성공의 핵심입니다. 벡터는 포괄적인 빌딩 블록을 제공합니다. 하지만 벡터가 모든 것을 제공하는 것은 아닙니다. 다른 플레이어가 기여할 수 있는 POXIS OS 또는 ADAS·인포테인먼트용 미들웨어, 즉 Vehicle OS에 필요하나 벡터가 제공하지 않는 것도 있습니다. Vehicle OS가 모든 도메인을 포괄하는 개념이기 때문입니다. 다양한 파트너와 협업을 해야만 Vehicle OS를 구현할 수 있습니다. 



그림 2 | 베이스 레이어 아키텍처 및 빌딩 블록 ⓒVector Informatik 
그림 3 | 소프트웨어 팩토리의 워크플로 및 툴 ⓒVector Informatik 



Q. 관련 업계에서 표준화된 Vehicle OS를 만들 가능성이 있을까요? 있다면, 벡터는 어떤 기여를 할 수 있나요?

A. 어려운 질문입니다. 융합은 되리라 생각합니다. 다만 융합된 결과물이 과연 단 하나의 표준이 될지는 잘 모르겠습니다. 오히려 안드로이드와 iOS가 공존하는 모바일 산업처럼 2~3개 정도로 귀결되지 않을까 생각합니다. 지금 모든 회사가 Vehicle OS를 자체 개발하기 시작했지만, 아직 표준화 움직임은 없습니다. 

현재 MB.OS, 스텔란티스(Stellantis) OS, VW.OS 등이 있는데, 통합하자는 목소리가 커지고 있는 것은 사실입니다. 그 결과물이 어떤 형태가 될지는 아직 아무도 모릅니다. 개인적으로 표준 아키텍처가 만들어질 가능성이 있다고 생각합니다. 정해진 소프트웨어 빌딩 블록을 사용하는 게 아니라 지금까지 표준화와는 약간 다른 맥락이 될 것 같습니다. 예를 들어 AUTOSAR는 API 차원에서 굉장히 하위의 표준인데, Vehicle OS는 아키텍처 단에서의 표준이 되지 않을까 싶습니다. 그리고 HPC의 소프트웨어 아키텍처를 연구하게 되리라 생각합니다. 지금 시작하려는 움직임이 보입니다. AUTOSAR에서 범위를 확장하려는 움직임도 있고, 클라우드 네이티브에 집중하는 SOAFEE도 있고, Eclipse SDV와 COVESA 같은 컨소시엄도 있습니다. 표준화에 기여하려는 움직임이 많다고 생각합니다.

벡터의 기여에 대해 질문해 주셨는데요, 벡터는 시장에서 다양한 OEM과 Vehicle OS 개발을 함께한 유일한 회사입니다. 예를 들어 Vehicle OS 개발을 위해 메르세데스 벤츠, 스텔란티스와 협업을 했습니다. 벡터는 스택 제공업체이면서 Vehicle OS 공급업체라고 자처합니다. 저희도 표준화된 접근방식을 원하기 때문에 우리의 경험이 기여할 수 있는 부분이 있다고 봅니다. 그동안 다양한 프로젝트 경험을 통해 전문성을 축적해 왔습니다. 앞서 언급한 아키텍처 차원의 베이스 레이어, 소프트웨어 팩토리, 지원 서비스 등 모든 구성요소에서 유의미한 기여를 할 수 있습니다. 그 차원에서 AUTOSAR와 SOAFEE에 참여하고 있고, Eclipse SDV와 COVESA에도 필요하다면 참여할 것입니다.



Q. Vehicle OS가 공급망에 큰 변화를 가져오리라 생각합니다. OEM과 티어 1의 역할은 어떻게 바뀔까요?

A. Vehicle OS가 OEM과 티어 1뿐만 아니라 공급망 전반에 변화를 가져올 것입니다. SDV 개념이 부상하면서 OEM은 차량의 실제 가치를 결정하는 HPC와 영역 컴퓨팅(Zonal compute)에 집중하게 되고, 간단한 센서, 액추에이터, ECU는 티어 1의 영역으로 점차 넘어가게 될 것입니다. 이런 제품은 점차 범용화될 것이기 때문입니다. 

티어 1의 선택지는 두 가지라고 봅니다. 하나는 소프트웨어 통합을 추진하고 있는 OEM에게 하드웨어만 제공하는 공급사가 되는 것입니다. 또 다른 선택지는 OEM이 모든 소프트웨어를 개발하지 않을 것이기 때문에 순수 소프트웨어 공급사가 되는 것입니다. 또는 OEM의 통합 노력을 지원할 수도 있습니다. 결국, OEM이 HPC 부분에서 작업을 얼마나 흡수하냐에 따라 티어 1의 역할이 달라질 것입니다. 벡터와 협업하고 있는 OEM은 HPC와 영역별 컴퓨트에 집중하고 있습니다. 



Q. 기조연설에서 “시중에서 가장 강력한 하드웨어를 SDV에 적용할 것”을 강조했습니다. 차량의 라이프사이클을 고려해 추가 하드웨어 자원의 적정선을 결정할 수 있을까요? 

A. 사실 어려운 문제입니다. 일단 스마트폰과 비교해보겠습니다. 자동차가 스마트폰보다 훨씬 더 복잡하니 둘의 비교는 선호하지 않지만, 여기서는 꽤 들어맞을 것 같습니다. 갤럭시나 아이폰의 경우 이미 내장된 앱이 프로세서 부하의 80%를 차지합니다. 따라서 하드웨어 자원의 제약으로 넷플릭스나 틱톡 등 원하는 앱을 내려받지 못할 수 있습니다. 

자동차도 이와 비슷한 방향으로 가고 있습니다. SDV는 스마트폰처럼 소프트웨어 업데이트를 통해 기능을 확장할 수 있어 하드웨어 자원의 여유 공간을 남겨둬야 합니다. 문제는 얼마나 남겨두느냐입니다. 지금은 사용하지 않는 하드웨어 자원을 추가한다면 당장은 추가 비용이 들겠지만, 결국은 OEM에게 수익화할 기회를 제공할 것입니다. 이것은 일종의 트레이드오프의 문제입니다. 스마트폰 기업도 SOP 이후 하드웨어만 판매하는 것보다 소프트웨어 서비스로 훨씬 더 많은 수익을 창출하고 있습니다. 자동차 OEM의 목표도 이와 같다면 현재 최고의 하드웨어를 찾아서 적용할 것을 추천합니다. 가장 높은 컴퓨팅 파워를 갖춘 프로세서를 탑재하는 것이 좋다는 것입니다. 

결국은 더는 새로운 기능을 추가할 수 없는 시점이 곧 차량의 라이프사이클이 끝나는 시점이 될 것입니다. 따라서 차량에 가장 강력한 하드웨어를 탑재함으로써 차량의 라이프사이클을 연장할 수 있고, 그만큼 자동차 한 대로 수익화할 수 있는 기간도 길어집니다. 구체적인 추가 하드웨어 자원의 적정 용량을 말하기는 어렵습니다. 다만, 이론적으로 현존하는 최고의 하드웨어를 적용할 것을 권장합니다. 하드웨어와 마찬가지로 소프트웨어도 진화하고 있습니다. 향후 하드웨어 자원 소비(Resource-consumption)가 얼마나 될지 계산하기는 어렵습니다. 어떤 일이 일어날지 알 수 없기 때문입니다.



Q. 결국은 비용문제로 귀결됩니다. 과연 이 제안을 OEM이 수용할 수 있을까요?
A. 사실 이 문제는 이견이 존재합니다. 기술자와 관리자, 영업 담당자 간에 생각이 다릅니다. 적극적인 사람도 있고 보수적인 사람도 있습니다. 결국, OEM이 전략을 세워야 합니다. 비전이 무엇이고, 얼마만큼의 기능을 추가할지에 따라 달라질 것입니다. 자동차가 안정적이었으면 한다면 헤드룸이 많이 필요하지 않을 것입니다. 반면, 좀 더 확장할 수 있기를 원한다면 더 적극적이어야 하고 더 많은 헤드룸을 확보해야 합니다. 결국은 OEM의 철학에 따라, 또 볼륨 모델이냐 고급 브랜드 모델이냐에 따라 달라질 것입니다. 



Q. (OEM 관점에서) 어떻게 수익원을 창출할 것인가도 고민입니다. 

A. 수익 모델을 찾는 게 어렵다는데 전적으로 동의합니다. OEM이 차량의 시트 열선 기능을 구독 서비스로 전환했다가 철회한 예가 있습니다. 따라서 OEM은 고객의 기대가 무엇인지, 자동차의 필수 기능은 무엇인지, 구독료를 낼 의향이 있는 추가 소프트웨어 기능은 무엇인지를 고객 관점에서 합리적으로 판단해야 합니다. 

소비자 관점에서 훨씬 더 합리적이고 실제로 도움이 되는 일회성 구독 서비스 사용사례를 생각해 볼 수 있습니다. 예를 들어 가속이나 감속 기능은 당연히 구독 서비스가 될 수 없지만, 운전자가 스포티한 차를 가지고 있고 주말에 레이스 트랙(Race track)을 방문했다면 일회성 레이싱 모드를 구독할 수 있지 않을까요? 또는 장거리 여행하는 경우 일회성으로 비용을 내고 특정 편의 기능을 이용할 수도 있습니다. 고객이 자동차에서 기본적으로 기대하는 기능에 대해 추가 비용을 청구하거나 구독 서비스로 제공하는 경우, 저항에 부딪힐 수 있으므로 신중하게 선택해야 합니다. 







Q. SDV는 벡터와 벡터 제품에 어떤 영향을 미치고 있나요?

A. 이에 대해 벡터는 많은 내부 논의를 거쳤으며 큰 기회가 될 것으로 보고 있습니다. 벡터는 이미 여러 제품을 제공해 왔습니다. 예를 들어, 베이스 레이어의 경우 과거 독립 제품이었던 MICROSAR Classic과 MICROSAR Adaptive가 SDV라는 공통의 비전이 제시되면서 제품의 연결고리가 생겼고 하나로 묶이는 계기가 됐습니다. 어떻게 보면 Vehicle OS와 SDV는 회사 내 여러 부서와 제품을 하나로 묶는 연결고리이자 새로운 포장지 역할을 해주고 있다고 봅니다. 소프트웨어 팩토리의 경우 실제로 종단 간(end to end) 포괄적 개념이기 때문에, 오히려 여러 소프트웨어나 툴 부서 간의 소통이 크게 늘었고, 저희는 큰 기회로서 기대가 큽니다. 



Q. 그렇다면, 벡터가 기여할 수 있는 바는 무엇인가요? 

A. 일단 제품 측면에서, 벡터는 베이스 레이어를 구축하는 데 필요한 거의 모든 빌딩 블록을 제공합니다. 예를 들어 MICROSAR Classic과 Adaptive, MICROSAR Classic veSwitch, veHypervisor, veHSM, 데이터 수집 및 소프트웨어 업데이트(OTA)를 위한 솔루션 등을 제공합니다. 소프트웨어 팩토리 측면에서는 워크플로와 DaVinci, PREEvision, CANoe와 같은 툴을 제공합니다. 워크플로의 경우 협업을 하는 방식, 저희가 원하는 비전을 강요할 수 없으나 일종의 청사진과 아이디어를 고객에게 제공합니다. 

지원 서비스 측면에서는 Vehicle OS 공급업체로서 전반적으로 모든 빌딩 블록이 어떻게 함께 작동하는지에 대한 전문성을 제공합니다. 이를 통해 벡터 제품이 아니더라도 빌딩 블록 간의 상호운용성을 보장합니다.