자동차는 완전한 패러다임의 변화가 필요하다. 미래의 차량 디자인은 차량 설계에 따른 소프트웨어가 아니라, 소프트웨어 기반 기능을 중심으로 차가 디자인돼야 한다. 과거의 차가 항상 파워트레인 성능을 염두에 두고 설계됐듯이, 이제 자동차는 차세대 프로세서를 중심으로 설계돼야 한다. 전자 하드웨어와 응용 소프트웨어가 자동차의 차별화와 가치창출 및 통제의 주요 전장이 되고 있다.

글｜볼프강 베른하르트(Wolfgang Bernhart), 팔크 마이스너(Falk Meissner) 외
정리｜한 상 민 기자_han@autoelectronics.co.kr
출처｜Roland Berger



“우리는 최근 ‘바퀴 달린 컴퓨터 파트 2: 소프트웨어 역량을 갖춘 OEM 및 서플라이어를 요구하는 소프트웨어 기반 차량(Computer on Wheels Part. 2: Software enabled cars need software enabled OEMs and suppliers)’이란 글을 발표했습니다. 이 글은 제가 오토모티브 일렉트로닉스紙와 지난번 이야기를 나눴던 E/E 아키텍처에 관한 아티클(Computer on Wheels: Disruption in Automotive Electronics and Semiconductors)의 다음 버전입니다. 롤랜드버거(Roland Berger)는 ‘차량 설계를 따르는 소프트웨어’보다는 ‘소프트웨어 기반 기능을 중심으로 설계된 차량’으로 향하는 패러다임 변화의 필요성을 말하고 있습니다. 이는 최근의 다임러와 엔비디아의 협력 발표와 매우 관련 깊다고 생각합니다.” 

7월 초, 롤랜드버거의 팔크 마이스너(Falk Meissner) 파트너가 새로운 아티클과 함께 이렇게 전했다. 그는 미래 차량 E/E 아키텍처, 소프트웨어 플랫폼 및 애플리케이션이 자동차가 항상 파워트레인 성능을 염두에 두고 설계돼 왔듯이 앞으로는 차세대 프로세서를 중심으로 설계돼야 하고, 전자 하드웨어와 응용 소프트웨어가 자동차의 차별화와 가치창출 및 통제의 주요 전장이 될 것이라고 했다. 


■ 바퀴 달린 컴퓨터  

자동차는 다른 제품들과 마찬가지로 대부분의 혁신이 일렉트로닉스와 소프트웨어를 기반으로 하면서 세상과 ‘연결(connected)’되고 있다. 고객은 항상 연결되는 것을 기대한다. 교통정보와 같은 것은 차에서 자동으로 업데이트되고 전기차는 충전 인프라와 통신을 한다. 그러는 동안 앱을 이용한 스마트 주차, 적응형 순항제어와 같은 자동화 기능들은 갈수록 보편화되고 있다. 사실, 자동차는 ‘시스템 오브 시스템(system of systems)’에서 하나의 시스템으로 바뀌고 있다. 곧 거의 모든 차들은 서로 연결되고 사물인터넷(IoT)의 일부가 돼 차량의 라이프사이클 동안 업데이트와 업그레이드를 위한 안전한 연결을 요구할 것이다.

하지만 이런 진행은 말처럼 간단한 것이 아니다. 오토모티브 일렉트로닉스와 분산된 소프트웨어 기능의 복잡성은 전례 없는 수준의 매우 다루기 힘든 상황에 도달했다. 복잡성을 해결하기 위해 새로운 하드웨어와 소프트웨어 기술이 등장했지만 어려움이 없는 것이 아니다. 예를 들어, 자동차 산업은 ECU를 자동차 이더넷에 의해 연결된 중앙집중식 컴퓨팅 플랫폼으로 통합하기 위해 컴퓨팅 파워의 진보를 활용하고 있다. 이는 네트워크 수준에서 복잡성을 크게 줄이고 하드웨어 비용을 감소시키지만, 소프트웨어 복잡성을 프로세서 내에서 엄청나게 증가시킨다.

또한 엔드 투 엔드 소프트웨어 플랫폼은 새로운 기능의 ‘플러그 앤 플레이’를 허용하고 하드웨어 요구사항을 낮춰 소프트웨어 복잡성을 줄일 것을 약속하지만, 베이직 소프트웨어조차 칩셋으로부터 완전히 독립되는 것은 아니다. 소프트웨어 플랫폼과 애플리케이션을 설계할 때 전기/전자(E/E) 아키텍처 뿐 아니라, 프로세서 성능과 가능한 태스크의 병렬화가 고려돼야만 한다. E/E 아키텍처와 차량의 기하학적 아키텍처는 서로 영향을 미치기 때문에 독립적으로 설계될 수 없다.

이런 요인들은 복잡성을 완전히 해소하기 위해 패러다임 전환이 필요하다는 것을 말해준다. 궁극적으로 미래의 차량 E/E 아키텍처, 소프트웨어 플랫폼 및 애플리케이션은 차가 항상 파워트레인 성능을 염두에 두고 설계됐듯이 차세대 프로세서를 중심으로 설계돼야할 것이다. 한마디로 전자 하드웨어와 응용 소프트웨어는 차별화와 가치창출 및 통제의 주요 전장이 될 것이란 말이다.

이 연구는 롤랜드버거의 첨단기술센터의 "바퀴 달린 컴퓨터" 시리즈 중 두 번째 글이다. 각 연구는 자동차 산업이 직면하고 있는 혁신과 도전의 서로 다른 측면을 다루고, 고객과 기타 이해 관계자들을 위한 가시성을 제시하는 것을 목표로 했다.


■ 밸류체인의 붕괴      

‘바퀴 달린 컴퓨터’는 서비스로서의 이동성을 제공할 것이고 궁극적으로는 자율주행을 할 것이다. 완전히 연결되고 디지털화된 환경에서 작동할 것이며, 전기 드라이브트레인으로 구동할 것이다. 롤랜드버거는 이를 MADE(=CASE)라고 명명했다. 이 메가트렌드는 새로운 반도체와 소프트웨어 기술에 기초해 대폭적인 오토모티브 일렉트로닉스의 역할 증대란 결과를 불러온다. 롤랜드버거는 이 연구 시리즈 1부에서 일반적인 일렉트로닉스, 특히 반도체의 역할을 살펴봤다.

그리고 이번 2부에서는 이런 개발을 가능케 하는, 프론트 시트에 해당하는 소프트웨어에 대해 살펴본다. 예를 들어, 모빌리티 영역에서 소프트웨어는 승차 공유, 전기 스쿠터 등을 위한 모빌리티 앱을 가능하게 한다. 또 자동주행에서는 적응형 순항제어와 자동주차, 충돌회피, 교통신호 인식에 이르기까지 첨단 운전자 지원 시스템(ADAS) 기술의 중추적인 역할을 한다. 디지털화의 영역에서, 소프트웨어는 OTA 업데이트와 커넥티드 카 서비스를 가능하게 한다. 또 소프트웨어는 xEV 충전을 위한 스마트 알고리즘의 형태로 전기화의 핵심 역할을 하며, 차량의 동력과 주행거리 증가에도 주도적인 역할을 한다. 

소프트웨어 기반 차량의 등장은 극적인 결과를 가져올 것이며, 자동차의 밸류체인 전체를 따라 구조적인 변화를 일으킬 것이다. 몇 가지 추세는 이미 다음과 같이 가시화되고 있다.

▶OEM은 모듈 통합, 소프트웨어 개발, 심지어 반도체 디자인을 위한 상당한 리소스 추가를 통해 역량을 확장해 밸류체인과 핵심 기능에 대한 통제력을 강화하고 있고 ▶소프트웨어(Software-driven) 자동차에서 가장 높은 일렉트로닉스 BoM(Bill of Material) 점유율을 차지하는 반도체 업체들은 SoC(System-on-a-chip), SiP(System-in-a-Package) 등 칩 기능 통합을 전개하고 있다. 인텔과 모빌아이의 거래에서 알 수 있듯이 그들은 하드웨어에서 애플리케이션 수준의 자동차 소프트웨어로 확장하고 있고, 특수 설계된 새로운 AI 칩들은 GPU보다 훨씬 낮은 에너지 소비 수준과 비용으로 신경망 알고리즘을 실행한다.

▶전자제조서비스(EMS, ODM) 플레이어는 엔지니어링 및 IC로 확장되면서 다른 플레이어에 비해 비교할 수 없는 규모의 이점을 제공하고 있으며 ▶이전까지 자동차 시장에서 마이너 플레이어에 불과했던 소프트웨어 전문 서플라이어들은 이제 미들웨어나 애플리케이션 수준에서 밸류체인을 따라 시장에 진출하고 있다. ▶이와 함께, 전통적인 티어1 E/E 서플라이어들은 모든 측면에서 압박을 받고 있다. 그들이 만든 비즈니스 모델은 분열되고 있고 관련 없는 것이 될 위험에 처했다. 게다가 티어1은 멀티 소프트웨어 컴포넌트에 대한 통제력을 잃는 동안 ECU 및 소프트웨어 스택 통합자로서 기존의 프론트라인 책임을 져야하는 위험에 빠졌다.

자동차에서 소프트웨어는 모빌리티, 자율주행, 디지털리제이션, 전기화 혁신을 가능하게 하는 원동력이자 OEM의 하드웨어 중심 조직 및 프로세스에 대한 주요 과제가 됐다. 


■ 오토모티브 SW의 도전과제 

일렉트로닉스 컴포넌트의 소프트웨어 컨텐츠 증가에 따라 이런 컴포넌트들을 차량에 구현할 때의 통합 복잡성 또한 기하급수적으로 증가했다. 주요 리콜, SOP 지연, 개발비용 폭발 등 소프트웨어 중심 일렉트로닉스는 최근의 경영자들에게 가장 큰 골칫거리 중 하나가 됐다. 소프트웨어 및 일렉트로닉스가 최근의 자동차 산업에서 혁신과 차별화의 초점이 됐음에도 불구하고 이는 OEM과 여러 서플라이어들 사이에 너무 자주 발생하는 심각한 문제가 됐다.

차량 아키텍처는 끊임없이 증가하는 안전, 편의, 커넥티드 기능을 지원해야만 한다. 이런 특징과 기능의 복잡성 증가는 80~100개 또는 최대 120개의 ECU에 분산돼 있다. 또 이런 ECU 중 다수는 여러 공급업체를 통해 병렬로 개발되고 있으며 OEM은 제품 포트폴리오에서 다양한 조합을 사용하고 있다.

증가하는 (클라우드) 연결성과 소비자의 이동성 세계로의 완벽한 통합은 다양한 표준과 훨씬 짧은 수명주기를 가진 다른 장치들, 플랫폼 및 서비스 도입을 요구한다. 이는 다년간의 개발주기와 수십 년의 수명을 지닌 플랫폼을 사용하는 OEM에게 새로운 도전인 동시에 차량 승인절차(규정 준수 확인)의 복잡성을 증가시킨다. 그 결과, 고객 관점에서 본질적으로 동일한 기능에 대한 소프트웨어 변형이 많고, 소프트웨어 기능과 하드웨어 간 의존성이 크게 증가했으며, 관리하기 힘든 통합 복잡성이 발생했다.

OEM은 이런 복잡성을 줄이기 위해 단일 기능 ECU에서 보다 다기능적이고 유연한 도메인 컨트롤러로 이동하는 중앙집중화된 E/E 아키텍처를 도입하고 있으며, 범용 컴퓨팅 플랫폼은 추상화 계층 도입을 더욱 간소화해 하드웨어를 소프트웨어 플랫폼에서 분리함으로써 개발 주기 및 서플라이어를 효과적으로 분리하기 시작했다.

새로운 소프트웨어 지원 아키텍처에는 소프트웨어 지원 조직, 프로세스 및 KPI가 필요하다. 하지만 OEM은 필요한 조직 및 프로세스 변경을 구현하지 못하고 있다. 하드웨어 컴포넌트 중심 조직은 여러 도메인에 걸친 기능 통합에 대한 명확한 거버넌스 및 엔드 투 엔드 책임이 없다. 또 전통적인 워터폴(waterfall) 방식의 개발 프로세스는 짧은 소프트웨어 라이프사이클을 따라갈 만큼 민첩하지 못하다. 초기 비용에 초점을 맞춘 구매 및 재무 목표 역시 근시안적인 비즈니스 사례와 소싱 결정으로 이어져 장기적으로 비용과 복잡성을 더욱 증가시킨다.

급한 불끄기의 악순환 또한 나타나기 마련이다. 통합 복잡성이 꾸준히 증가하면서 소프트웨어 품질 문제가 많이 발생하는데, 제한적인 소프트웨어 역량에서 비현실적인 작업 부하와 스케줄은 내부 자원의 상황을 더욱 악화시킬 수밖에 없다. 잠재적인 지연을 방지하기 위해 역량을 갖춘 인력이 이런 문제의 진화에 투입돼야 하고, 그렇게 되면 새로운 고객 관련 기능의 개발은 폐기 또는 연기되게 된다. 서플라이어는 품질과 관련한 리스크에 충분한 주의를 기울이지 않으면서도 오히려 초기 개발비용에 완전히 초점을 맞춘다. 결과적으로, 서플라이어 측에서 가장 경험이 많고 역량 높은 자원들은 다른, 더 매력적인 프로젝트에 묶여 있다. 이런 결과는 품질 문제와 모든 통합 수준의 지연, 재작업, 론칭 지연, 그리고 더 많은 진화의 요구로 이어진다.  



소프트웨어 역량을 갖춘 회사가 되기 위한 요인, 전제조건, 주요 활동 영역


■ 전환의 여정 

OEM은 자사 제품에서 점점 더 많은 양의 소프트웨어로 인해 발생하는 문제들을 극복하고, 소프트웨어 역량을 갖춘 기업이 되기 위해 총체적인 전환 여정에 착수해야 한다. 성공적인 변혁을 위한 근본은 다음과 같은 두 가지다. 

▶첫째는 기하급수적으로 증가하는 소프트웨어와 통합 복잡성에 대처하기 위한 개발 프로세스에서 시스템 엔지니어링 원칙과 기능 지향성의 도입이고, ▶둘째는 복잡성과 비용을 줄이고 새로운 서비스 에코시스템을 지원하기 위한 중앙집중식 컴퓨팅 및 엔드 투 엔드 소프트웨어 플랫폼을 도입하는 것이다. 

OEM은 이와 함께 4가지 변화를 이행해야만 한다. 

이는 ▶소프트웨어에 대한 IP 및 Make-Buy-Partner 의사결정에 대한 명확한 전략과 프로세스 마련 ▶기능 지향 및 시스템 엔지니어링의 원칙에 따른 엔지니어링 기능의 재구성, 기능, E/E 및 소프트웨어 아키텍처에 대한 중앙집중식 책임성 설정 ▶엔지니어링 뿐만 아니라 조달, 재무/통제, 판매 및 고객 관계에서도 소프트웨어를 처리하는데 필요한 모든 프로세스의 (재)정의 ▶차량의 SOP가 새로운 기능, 업그레이드된 기능 및 업데이트된 기능의 지속적인 배포를 기반으로 하는 통합 제품 및 서비스 오퍼링의 ‘버전 1.0’에 불과하다는 새로운 사고방식의 적용 등이다. 
혁신적인 신차 디자인 및 보급 패러다임의 전환은 다음과 같다. 

E/E 아키텍처는 차량 아키텍처와 패키징을 가이드하는 중심 요소가 되며, 고객을 위한 서비스 생태계를 가능하게 하는 소프트웨어 플랫폼을 호스팅한다는 것이다.

A. 기능 중심              
기능은 고객의 요구와 기술적 실행(솔루션) 사이의 연결고리다. 기능 지향의 본질적인 측면은 고객이 원하는 특징과 속성을 제품의 기능적 요구사항으로 일관성 있게 변환하는 것이다. 이러한 기능 요건은 공통적인 기술 솔루션을 도출하고 재사용을 극대화하기 위해 종합적으로 고려돼야 한다. 기능 지향의 개념은 사실 새로운 것이 아니다. 이는 거의 20년 전 일부 OEM에 의해 처음 적용됐다. 하지만 회사 전체 차원에서, 또는 완벽히 엄격하게 적용된 경우는 드물었다.

제품 전략 및 사전 개발 단계에서 기능 지향은 브랜드 가치 중심의 요구사항 관리를 고객 관련 차량 기능과 연계해 가능하게 한다. 이는 모듈러 키트와 소프트웨어 플랫폼 스택 정의의 기초가 된다. 설계 및 구현의 시스템 엔지니어링은 명확하게 정의된 인터페이스를 제공하고 플러그 앤 플레이 기능으로 통합 노력을 줄인다.



기능 지향: 롤랜드 버거의 “전체 차량 기능 카탈로그”의 개요 


기본은 회사 전체의 기능 아키텍처 또는 차량 내 모든 고객 관련 기능과 공통 구문 의미(common syntax and semantics)를 사용하는 관련 ‘서비스 카탈로그’다. ‘시스템’은 차량, IT 백엔드 및 연결된 장치에 의해 실현되며 그것은 ‘시스템 오브 시스템’의 일부분이다. 

초기 카탈로그는 특정 기술 솔루션에 대한 결정이 기능을 더 자세히 설명하기 위해 요구될 때까지 시스템의 기능적 분해에 의해 도출될 수 있다. 기능은 입력 및 출력 값과 프레임 조건(예: 정확도, 거리, 속도 등 물리적 파라미터로 표현되는)으로 설명되며, 구조의 다양한 수준에서 반복될 수 있다. 기능 카탈로그(functional catalog)는 차량용 특정 아키텍처의 모듈 빌드업을 위한 레퍼런스 기반과 요구사항을 위한 입력으로서 역할을 한다. 

잘 정의된 기능 아키텍처는 엔드 투 엔드 소프트웨어 플랫폼을 정의하기 위한 전제조건이며, 그 이점은 제품 전략과 초기 개발 단계뿐만 아니라 차량의 전체 라이프사이클에 걸쳐 나타난다. 검증된 소프트웨어의 재사용을 극대화하고 통합 노력을 최소화한다.

B. 엔드 투 엔드 소프트웨어 플랫폼  
중앙집중화된 E/E 아키텍처의 도입(1부에서 설명)은 소프트웨어 플랫폼의 도입과 병행된다. 이는 하드웨어와 독립적으로 소프트웨어를 개발하거나 소싱하기 위한 전제조건이다. 엔드 투 엔드 소프트웨어 플랫폼에서 사용되는 차량용 소프트웨어 표준은 애플리케이션, 백엔드 및 기타 시스템 간의 ‘추상화 계층’을 도입하는 한편, 플랫폼의 재사용 가능한 소프트웨어와 서비스를 도입함으로써 통합의 복잡성을 줄인다. 이들은 1차 애플리케이션을 실행하고 차량 아키텍처의 다른 하드웨어 요소와 통신을 위해 하드웨어에서 차례로 추상화된다. 

기능 카탈로그의 기능이 플랫폼에 더 많이 통합될수록 더 강력하다. 또 기본 플랫폼 기능과 서비스를 OEM 전체에 걸쳐 표준화해 비용을 절감하고 규모의 경제를 극대화해야 한다.

애플의 iOS와 같은 컨슈머 소프트웨어 플랫폼에는 베이직 소프트웨어, 드라이버, 서비스 외에, 예를 들어 인증(FaceID, 지문, 4자리 코드)과 같은 기능을 위해 사용되는 하드웨어와 독립적인 고급 기능들이 포함돼 있다. 하드웨어 추상화 계층의 강도는 여러 제품 세대에 걸친 상향 및 하향 호환성에 의해 입증된다.
   

베이직 하드웨어의 표준화와 소프트웨어 분리


iOS의 예


C. 구매 파트너 전략과 IP 관리
기능 카탈로그는 소프트웨어 컴포넌트들의 히트맵에 대한 기초로서, make-or-buy decision을 주도하는 IP의 체계적인 평가를 위한 프레임워크다. 소프트웨어 히트맵은 일반적으로 애플리케이션 레이어와 기능들에 상주하는 고객 관련 기능들, 베이직 및 미들웨어 플랫폼을 구성하는 기능, 서비스, 드라이버 등 모든 기능 클러스터를 커버한다.

조달, R&D, 제품 관리 및 품질은 특정 IP의 소유권이 어느 정도 전략적 또는 경제적 이점을 제공하는지 평가한다. 그러한 이점이 제공되지 않고 경제적 이점이 있는 경우 소프트웨어는 하드웨어와 별도로 소싱된다. 그 밖의 분야의 경우, 개발 또는 소싱 모델(내부, 제휴 개발, 서비스로서의 소싱 등)은 일반적으로 일련의 복잡한 기준에 근거해 조인트 크로스-펑션 프러큐먼트 커미티에서 만들어진다.


체계적인 make or buy 평가


소프트웨어와 관련된 지적재산권(IP)은 구조적이고 총체적인 접근방식으로 구매, 모니터링, 보호, 판매를 포함하는 보다 넓은 관점뿐만 아니라 전략적인 관점에서 적극적으로 관리돼야 한다. 유리한 라이선스 조건을 달성하기 위한 구매 협상에서부터 제3자에 대한 IP 판매에 이르기까지 밸류체인을 따라 IP 문제를 고려할 필요가 있다. 다른 IP 관리 활동에 필요한 투명성을 제공하기 위해서는 적절한 IP 모니터링과 자산 관리가 필수적이다.

반도체와 컨슈머 전자산업이 IP 경영의 여러 측면에서 상당히 앞선 반면, 자동차 산업은 이제 막 IP 프로세스 적용에 나서고 있다. 대부분의 OEM은 그들의 IP에 완전한 투명성을 가지고 있지 않다. 예를 들어, 그들은 차량에 설치된 소프트웨어 라이센스에 대해 과다하게 지불할 수 있다. 마찬가지로 중요한 것은 OEM은 비용이 많이 드는 소송을 피하기 위해 자신의 IP가 의도치 않게 제3자의 IP를 침해하는 것을 피해야 한다.


소프트웨어 IP 매니지먼트 프레임워크


D. 조직개편 
“시스템을 디자인하는 조직은 ... 조직의 커뮤니케이션 구조와 일치하는 디자인을 생성하도록 제약받는다”라는 (1968년 컴퓨터 과학자가 만든) ‘콘웨이 법칙(Conway's Law)’은 자동차 산업과 그 어느 때보다 관련 깊다. 수십 년 동안 대부분 OEM은 엔지니어링 및 직접 구매 기능을 차체, 섀시, 파워트레인, 인테리어 및 일렉트로닉스 등 4개, 또는 5개 도메인 중심으로 구성했다. 이 영역은 파워트레인, ADAS/섀시, 바디 일렉트로닉스 및 인포테인먼트/커넥티비티 등 일반적인 현재의 E/E 아키텍처에도 반영된다.

하드웨어의 수직구조와 박스를 중심으로 설계된 조직에서 커뮤니케이션 구조, 프로세스 및 예산에 대해 설정된 구조는 하드웨어에 적합할 수 있지만, 이는 소프트웨어에는 적용되지 않는다. 따라서 새로운 중앙집중식 E/E 아키텍처와 엔드 투 엔드 소프트웨어 플랫폼의 도입은 일관되게 재구성이 수반돼야 한다. 기능 원칙을 따르는 새로운 횡적인 ‘소프트웨어 조직’이란 방향성과 시스템 엔지니어링의 창조가 요구된다. 

도메인 주변의 수직적인 사일로를 횡적인 조직 단위로 교체해야 한다. 이것들은 아키텍처(기능, E/E 및 소프트웨어), 플랫폼 미들웨어 및 서비스, 일렉트로닉 하드웨어(센싱, 컴퓨팅 및 액추에이션), 전원 및 신호 분배(와이어링 하니스 포함), 하드웨어 추상화 계층 및 관련 IT 백엔드 기능에 대한 중앙집중식 책임을 갖는다. 또, 구체적인 제품관리(IP·연계 서비스 관리)와 지원 기능(공통 툴·방법 확보)이 요구된다. 구매는 소프트웨어 소싱 및 소프트웨어 공급업체 관리를 위한 특정 조직을 구현해야 한다.

미래 사업을 위한 이런 조직의 중요성을 반영하기 위해서는, 특정 자동차 라인으로부터 독립된 보드 레벨의, 예산 책임에 대한 대표권을 갖는 것을 포함하는 현재의 엔지니어링 기능과 동일한 새 조직이 필요하다. OEM은 특히 기능 지향 및 시스템 엔지니어링 원칙이 아직 엄격한 방식으로 적용되지 않았기 때문에 조직 부서들에 대한 역할과 책임에 대한 명확한 정의에 어려움을 겪고 있지만, 저마다 ‘소프트웨어 조직’을 구현하기 시작했다. 


하드웨어 지향 대 소프트웨어 지향 조직 비교 


E. 프로세스의 재정의  
커넥티드 카에서 소프트웨어를 다룰 때, 소프트웨어 관련 프로세스의 올바른 정의는 필수다. 대부분의 직간접 비즈니스 프로세스는 하드웨어에 맞게 조정돼 있어 소프트웨어를 올바르게 처리할 수 있도록 조정돼야 한다. 포괄적인 감사를 통해 회사별 우선순위가 높은 전환 영역을 신속하게 파악할 수 있다. 하지만 여기서 가장 중요한 주제는 두 가지다.

바로 ▶통합 책임조정을 위한 초기 서플라이어의 참여 ▶소프트웨어 개발 프로세스의 산업화 또는 궁극적인 “소프트웨어 팩토리”의 창조다.
때때로 통합 책임은 오더 전에 정의되고 동기화되지 않으며, 그렇게 되면 이후의 조정 여지도 거의 없게 된다. 계약 체결 전에 적절한 산업화의 기초를 확립해야 한다. 신속한 변화를 위한 프로젝트에서는 더욱 그렇다. 

주요 OEM은 서플라이어에 의한 개발 스타트 시 ‘컨트롤 보드’를 셋업한다. 이 위원회는 기능 컨텐츠를 정의하고 시스템(완전한 시스템 릴리스)이나 차량 레벨의, 일련의 통합 이벤트를 일치시킨다. 소프트웨어 개발 시작 이전은 제어 능력이 높고 프로세스를 적극적으로 관리할 수 있지만 적절한 계획이 없다면 이후 단계에서 가능한 유일한 조치는 대처일 뿐이다. 

조달과 엔지니어링은 소프트웨어 서플라이어 선정에서 핵심적인 역할을 한다. OEM은 일반적으로 초기 개발비용에 너무 많이 집중하는 경향이 있다. 협상 중에 적용되는 가격 압력은 공급업체가 가장 경험이 풍부한 자원으로 프로젝트를 수행할 수 없도록 만든다. 그 결과인 품질 문제는 종종 결과물의 지연으로 이어지고, 모든 통합 단계에 계단식 영향을 미쳐 궁극적으로 차량 SOP를 지연시킬 수 있다. 또 이는 상당한 비용 증가로 나타나 초기 비용 절감액을 훨씬 초과하게 만든다.

따라서 소프트웨어 개발 계약 체결 이전에 서플라이어에 대한 평가 및 협상에는 다음과 같은 4가지 중요 영역이 반영돼야만 한다. 

4가지란 ▶시스템 통합 기능[시스템 엔지니어링, 통합 역량 및 필요 리소스의 확장성 평가(램프 업 속도)] ▶중요 리소스의 캐파(동일한 애플리케이션 도메인에 있는 다른 OEM과 병렬 프로젝트 수행으로 서플라이어의 중요 리소스가 다른 중요 프로젝트에 묶여 있는가) ▶프로젝트 조직(모든 기능 개발 영역이 서플라이어 측에 적절히 배치돼 있고, 그에 따라 OEM 반영을 보장하는가) ▶일반적인 SW 역량(다른 OEM 경험을 포함해 현재 및 완료된 서플라이어의 SW 역량의 체계적 평가) 등이다. 

이후 지속적인 통합과 전개를 실현하기 위해서는 실제 소프트웨어 개발이 산업화돼야 한다. 소프트웨어의 ‘팩토리’ 개념은 기술기업에서 꽤 오랫동안 사용돼 왔지만 자동차 업계에는 생소하다. 그것은 장인정신적 접근에서 산업화된 소프트웨어 생산으로 나아가는 것을 목표로 한다. 소프트웨어 공장에서 다루는 프로세스는 구현(implementation) 모델, 소프트웨어 구현, 통합 및 테스트, 그리고 평가/검증 등이 포함된다.

소프트웨어 팩토리 실행을 위한 전제조건은 다음과 같다. ▶가상화된 기능을 재구성할 수 있는 확장 가능한 모듈식, 서비스 지향 아키텍처 ▶재사용 가능한 소프트웨어 자산 및 컴포넌트 ▶환경구축(BE), 소프트웨어, 테스트 등에서 일관된 버전을 제공하는 컨피규레이션 관리 ▶오류 감지를 위한 노력을 줄이는 실질적인 오류 방지 방법 등이다. 
소프트웨어 팩토리는 명확한 입력 및 출력 아티팩트를 사용한 자동화에 기초해 모듈식 빌드 단계로 구성된 조정된 다단계 워크플로를 보장하며, 이를 통해 전체 제품 수명주기와 확장된 제품 라이프사이클에 걸쳐 지속적인 통합과 전달을 가능하게 한다.



소프트웨어 팩토리의 모범 사례

F. SOP = 버전 1.0           
커넥티드 카에 탑재된 소프트웨어는 SOP 이후 항상 업데이트해 사이버 공격에 대한 보안을 확보해야 한다. 그런 점에서 자동차는 우리의 PC나 모바일 기기에 더 가까워지고 있다. 또 다양한 수익창출 기회를 포착하기 위한 B2B와 B2C 서비스는 차량 내 기능, 즉 차량 데이터의 수익화, B2C 서비스(온디멘드 기능) 및 B2B 서비스의 조정/업데이트 능력을 요구한다.

온디멘드 기능(B2C 서비스)은 점점 더 중요해지고 있다. 예를 들어, 테슬라는 2012년에 이같은 비즈니스 모델을 최초 도입했다. 테슬라는 복잡성을 줄이기 위해 40 kWh 모델에 60 kWh 배터리를 장착해 고객들에게 요금제 업그레이드를 제공했다. 뿐만 아니라, SOP 이후 차량 내에서 소프트웨어를 잠금 해제하거나 능동적으로 다운로드할 수 있도록 하는 한편, 이미 주행 중인 차에서도 오토파일럿 하드웨어를 업그레이드할 수 있도록 했다. 이때부터 다른 OEM도 최종 고객을 위해 온디멘드 기능이나 기존 소프트웨어에 대한 업그레이드를 판매하기 시작했다. 

B2B 측면에서는 소프트웨어를 업데이트하는 기능 추가 서비스가 가능하게 됐다. 예를 들어, 렌터카 업체 SIXT는 그들의 플릿에서 원격으로 차량 상태를 모니터링하고 관리할 수 있다(마일리지, 연료 상태 등).

또 소프트웨어 개발 키트를 제공하는 성공적인 모델을 통해 자체적으로 새로운 차량 관련 기능을 개발하는 다른 회사가 이를 적용할 수 있게 해 라이센스 비용을 받거나 수익 공유 모델에서 추가적인 수익을 창출할 수 있는 기회도 만든다. 예를 들어 차량의 기본적인 ADAS 기능은 주차장에서 저속 자동 발렛 파킹 서비스 개발에 사용될 수 있고, 이는 추가적인 기능성과 수익을 증가시킬 수 있다. 


■ OEM을 위한 프레임워크        

자동차는 완전한 패러다임의 변화가 필요하다. 미래에는 차량 디자인에 따른 소프트웨어가 아니라, 소프트웨어 기반 기능을 중심으로 차량이 설계돼야 한다. 롤랜드버거는 전략, 조직, 각종 프로세스 등 기업의 소프트웨어 전환 여정의 현황을 체계적으로 평가할 수 있는 신속한 감사 방법뿐 아니라, 오토모티브 일렉트로닉스·소프트웨어에 대한 우수 프레임워크를 개발했다.

롤랜드버거의 이 프레임워크는 네 가지 핵심 영역을 포함하며, 다음과 같이 평가한다.

1. 전략적 입력 - OEM의 기본 소프트웨어 전략 및 기술 솔루션
2. 소프트웨어 소싱 및 개발을 포함한 핵심 소프트웨어 프로세스
3. 프로세스 지원과 인에이블러들
4. 기본 소프트웨어 조직

이 프레임워크를 적용하면 차량 소프트웨어의 복잡성 관리에 관한 현황에 대한 신속한 평가, 자동차 및 기타 산업의 모범 사례와의 비교, OEM에 대한 우선 조치 영역 정의를 할 수 있다.

오토모티브 일렉트로닉스와 소프트웨어의 변화는 자동차 산업을 교란시키고 있다. 이에 따른 과제를 해결하기 위해 OEM은 조직, 기능 및 프로세스를 총체적으로 전환해 문제를 해결하고, 급한 불을 끄고, 비용 초과, 사이버 공격, SOP 지연 등의 문제를 줄여야만 한다. 
일단 기능적인 조직이 구축되면, 민첩한 프로세스 및 올바른 KPI는 OEM을 위한 차별화된 가치제안을 창출하게 하고 지속가능한 가치창출을 할 수 있는 잠재력을 지닌 새로운 일렉트로닉스 및 소프트웨어 아키텍처를 제공할 수 있을 것이다.



오토모티브 일렉트로닉스와 소프트웨어 관리를 위한 프레임워크