brunch

매거진 사례로 보는 효율적인 제품 운영

라이킷 6 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김진회 Jan 18. 2023

폭스바겐 그룹 사례

(4) 제품 전략 - 소프트웨어

지난 글에서는 제품 전략 중 메카트로닉스 영역을 다뤘습니다. 이번 글에서는 소프트웨어 전략을 살펴보도록 하겠습니다. 별도로 표기는 안 했지만, 소프트웨어 전략에 전기전자 아키텍처가 포함되는 것으로 보았습니다. 소프트웨어를 통해서 제어하고, 원하는 바를 실현하는 것이 결국 전기전자 아키텍처이기 때문에 둘을 분리해서 설명하는 것은 불필요하다고 봤습니다.

미래 모빌리티에 있어서 소프트웨어가 중요하다는 말은 아무리 많이 한다고 해도 지나치지 않을 겁니다. 아래 그림과 같이 모빌리티 환경은 극적으로 변화하고 있습니다. 자율 주행, 전기차, 커넥티비티, 다양한 모빌리티 서비스 등은 이제 자사의 미래를 어필하기 위한 단순한 구호가 아니라 당장 실현될 영역으로 다가왔고, 그 중심에는 어김없이 소프트웨어가 있습니다. 소프트웨어를 지배하는 자가 미래를 지배한다는 이야기가 과장이 아닌 셈이죠.

모빌리티 환경 변화

자율주행 영역 선두 업체를 목표로 하는 폭스바겐

폭스바겐 그룹의 소프트웨어 전략의 목표는 내재화되지 않은 소프트웨어 역량을 향상시키는 것을 넘어서서 소프트웨어 선두 업체로의 도약입니다. 폭스바겐 그룹 차원에서는 전동화와 디지털화라는 두 개의 전환 중에 한 축으로 소프트웨어 전략이 놓여 있습니다.

좀더 자세히 살펴보면 기존에 보유하고 있는 메카트로닉스 플랫폼 외에 전기전자 통합 아키텍처, 소프트웨어 플랫폼을 구현하는 과제가 있습니다. 전기전자 통합 아키텍처, 소프트웨어 플랫폼을 구현한다는 것은 그룹 자체적으로 그룹 전 차량에 적용 가능한 소프트웨어 스택을 구현할 수 있다는 것을 의미합니다. 이를 위해서는 그룹 차원의 소프트웨어 개발 역량을 보유하는 것도 중요하지만, 과거와 달리 소프트웨어와 하드웨어 개발을 분리하는 프로세스 측면에서의 변화도 필요로 합니다.

이를 위해서 부족한 영역에 대한 외부 협력 관계 구축과 인수합병이 병행이 될 것이며, 소프트웨어 인력 확보도 당연히 중요할 것입니다. 그리고, 메카트로닉스 전략과 유사하게 로드맵에 따라서 점차 전기전자 통합 아키텍처, 소프트웨어 플랫폼을 전 차량으로 확대하는 과정이 필요할 겁니다.

소프트웨어 관련된 폭스바겐 그룹의 많은 과제들 중에서 순수하게 제품과 관련된 측면만 살펴보도록 하겠습니다.

통합 전기전자 아키텍처, 통합 소프트웨어 플랫폼 구축

폭스바겐의 소프트웨어 전략을 두 문장으로 요약하면 다음과 같습니다.

“소프트웨어 역량을 내재화 한다.”

“하나의 아키텍처, 하나의 플랫폼으로 통합한다”

앞서 메카트로닉스 전략에서 살펴봤듯이 기본적으로 아키텍처, 플랫폼을 하나로 통합한다는 것은 비용 절감 측면 효과를 먼저 생각할 수 있습니다. 그런데, 소프트웨어 전략에서는 비용 이상의 이유를 살펴봐야 합니다. 제품 구성요소 중에서 변화가 가장 큰 영역으로 예상되기 때문입니다.

하나의 아키텍처로 통합

앞서 언급한 바와 같이 전기전자 측면에서는 E3 이렇게 되면, 메카트로닉스, 전기전자, 소프트웨어가 그룹 전체가 각각 하나의 아키텍처, 플랫폼으로 통합이 되는 결과를 얻습니다. 앞으로도 이야기 하겠지만, 아키텍처를 통합하겠다, 플랫폼을 통합하겠다는 말에는 자연스럽게 모듈러 아키텍처를 적용하겠다, 아니 적용할 수 밖에 없다는 의미를 내포합니다.

기회가 되면 자세히 설명하겠지만 다양한 제품에 동일한 플랫폼, 동일한 아키텍처를 적용하기 위해서는 그만큼 유연하게 변경이 가능해야 함을 의미합니다. 아키텍처나 플랫폼은 하나일 지 모르지만, 그것을 구성하는 모듈의 종류는 다양할 수 있다는 것이죠. 이래야만 특성이 각기 다른 차량 모델에 아키텍처의 변화 없이 대응할 수 있을테니까요.

통합 전기전자 아키텍처 + 통합 소프트웨어 플랫폼

소프트웨어 전략을 하나씩 살펴볼까요?

첫 번째는 앞서 언급했던 소프트웨어 내재화, 자사만의 소프트웨어 플랫폼 구축입니다.

종전에는 왼쪽 그림과 같이 차량별로 탑재된 소프트웨어가 다르고, 탑재된 소프트웨어도 모듈별로 각기 다른 업체에서 개발하여 별도로 동작했습니다. 당연하게도 소프트웨어 개발 역량도 공급업체 Tier 2, 3 에게 있었겠죠. 이런 상황에서는 당연하게도 변화하는 모빌리티 환경에서 뒤쳐질 수 밖에 없습니다. 핵심역량을 외주로 갖겠다는 것 자체가 넌센스입니다. 그래서, 향후에는 오른쪽처럼 차량을 중앙 제어하는 전장 시스템이 있고, 그것을 조정하는 하나의 소프트웨어 플랫폼을 구축하는 것입니다. 그 위에 폭스바겐 그룹이 원하는 기능과 서비스를 장착하는 형태가 되는 겁니다. 이를 위해서 자사만의 소프트웨어 플랫폼이 필요한 것이고요. 이렇게 되면, 장착하는 ECU 종류나 개수가 줄어들기 때문에 원가 측면에서의 장점도 있고, 소프트웨어 개발 기간이 단축되기 때문에 차량 개발 기간 측면에서의 이점도 있을 겁니다.

As-is vs. To-be

두 번째는 하나의 아키텍처, 하나의 플랫폼으로 통합하는 겁니다.

하나의 아키텍처, 하나의 플랫폼으로 통합한다는 말은 단순 명료해서 이해하기 어렵지 않을 겁니다. 오히려 왜 그렇게 해야만 하는 이유를 아는 것이 중요합니다. 여러 개의 아키텍처로 분산되어 있는 것을 하나로 통합하는 것이 좋게 보이지만, 그렇게 까지 할 필요가 있을까 생각이 들 수 있습니다. 결론만 말하면, 통합을 하면 좋은 것이 아니라 통합을 해야만 하는 겁니다.

1. 소프트웨어 역량이 곧 제품의 역량

커넥티비티, 자율주행, 모빌리티 서비스 등 소프트웨어로 제어, 운영, 관리되는 자동차의 경쟁력은 역시 소프트웨어이고, 그러한 경향은 점차 심화 될 것입니다. 그런 와중에 소프트웨어 아키텍처가 모델 별로 분산되는 것은 전사의 역량을 분산하는 것과 동일합니다. 그렇기에 통합하는 것이 절대적으로 필요하겠죠. 애플이나 테슬라의 경우를 생각해보면 이해가 쉬울 겁니다. 자사의 통합 소프트웨어 플랫폼이 있기 때문에 지속적으로 업그레이드, 업데이트할 역량을 집중할 수 있습니다. 만약 운영체제가 모델마다 달라졌다면, 과연 애플이나 테슬라가 지금처럼 제품 경쟁력을 확보할 수 있었을까요? 아마도 기존 모델의 소프트웨어 유지보수만 하다가 시간과 리소스를 허비했을 겁니다.

The future is software

2. 품질, 신뢰성의 관리

급격하게 변화하는 소프트웨어 비중

자동차는 가장 복잡한 인터넷 디바이스가 될 것이다

현재 차량 당 소프트웨어 코드 수가 1억 라인 수준이라고 합니다. 그것이 점차 증가하여 2025년 경에는 10억 라인 수준이라고 합니다. 상상해보죠. 현재 여러 개의 아키텍처가 1억 라인 수준으로 결함의 영향을 최소화하거나, 중대한 결함이 없도록 관리하는 데도 상당한 비용, 기간, 리소스가 투입되는데, 10억 라인 수준의 여러 개의 아키텍처가 그렇다고 가정하면 얼마나 많은 비용, 기간, 리소스가 투입될까요? 소프트웨어 규모가 증가하는 것은 막을 수 없는 경향이라고 한다면, 줄일 수 있는 건 소프트웨어 아키텍처를 통합하는 것 밖에 남지 않는 것이죠. 게다가 자동차의 소프트웨어 결함은 곧바로 인명과 직결될 위험이 큽니다. 더욱더 절실하겠죠.

3. 지속적인 소프트웨어 변경과 업그레이드로 인한 복잡성 비용 절감

현재 개발되어 출시되는 소프트웨어는 릴리즈 하면 끝인 완성형 소프트웨어가 거의 없습니다. 온라인으로 연결되어서 기능을 업그레이드 해줘야 하고, 버그나 에러가 발견되면 패치를 깔아줘야 하고, 소비자가 원하는 기능을 변경을 해줘야 합니다. 그것을 수 개의 소프트웨어 아키텍처 별로 따로따로 해준다고 상상해보죠. 끔찍하지 않나요? 앞서 언급했던 애플의 경우, 메이저 체인지는 물론, 수시로 일어나는 마이너 체인지를 통해서 애플 운영체제를 최신화 합니다.

4. 소프트웨어 개발 속도 가속화

차량마다 별개로 소프트웨어를 개발하는 것보다 당연하게도 기존 소프트웨어를 재사용하고 공용화 하는 편이 개발 속도를 빠르게 할 수 있는 방법이겠죠. 10억 라인 넘는 소프트웨어를 차량마다 개발을 해야 하고, 차량에 맞춰서 커스터마이징을 한다는 것은 오히려 차량 개발 속도를 기존보다 늦추는 결과를 나을 뿐입니다. 하드웨어와 소프트웨어 개발을 분리하고, 차량에 특화된 개발과 차량에 독립적인 개발을 분리하여 자동차 개발 속도가 소프트웨어 개발 때문에 늦춰지지 않도록 만들 필요가 있습니다.

끊김 없는 모빌리티 생태계 구축

5. 폭스바겐 만의 모빌리티 생태계 구축

플랫폼이 곧 전략이다

애플이 아이폰을 통해서 자사를 중심으로 하는 애플 생태계를 만들었듯이, 디지털 전환에 있어서 소프트웨어 플랫폼 구축, 커넥티비티 구현, 지속적인 업데이트 및 업그레이드 등을 통해서 모빌리티를 위한 끊김 없는 디지털 생태계를 구축하고자 하는 겁니다. 아이폰이 모델별로 다른 운영체제를 가졌다면 과연 지금과 같은 애플 생태계가 만들어질 수 있을까요? 자동차 회사는 자신의 제품을 단순히 판매하는 것 뿐만 아니라, 소비자와 여러 개발자들을 하나의 생태계로 묶고 싶어합니다. 즉, 모빌리티 생태계를 구축하길 원하는 것이죠. 그런데, 생태계의 기반이 될 소프트웨어가 제각기 다른 아키텍처를 갖는다? 과연 온전한 생태계가 구축이 될까요?

자, 이렇게 폭스바겐 그룹은 소프트웨어를 내재화 하여 자사만의 전장/소프트웨어 플랫폼을 만들고, 이를 그룹 전체를 통합하고자 합니다.

이 다음은 어떻게 할 것인가에 대한 답이 나와야겠죠.

위와 같이 소프트웨어 제품 전략을 실행하기 위한 플레이어가 바로 폭스바겐 그룹 내 CARIAD입니다. CARIAD는 소프트웨어 역량을 그룹 내 내재화하고, 그룹을 통합하여 소프트웨어 플랫폼 및 솔루션을 개발하고 공급하기 위한 기업입니다. 그룹 전체를 통합하고자 하는 데, 특정 모델 산하에 소프트웨어 기업을 두는 것은 말이 안되겠죠. 전 제품에 공통으로 사용하는 모듈을 만들고 싶다고 할 때 기본이 조직과 프로세스를 분리하는 것입니다. 그와 마찬가지로 그룹 산하에 독립 된 CARIAD를 두고 소프트웨어 역량 내재화, 소프트웨어 플랫폼 통합이라는 과제를 담당하게 하는 것이죠. 그와 더불어 폭스바겐 그룹은 CARIAD를 통해서 소프트웨어를 통한 비즈니스 모델 전환을 꾀하고 있습니다. 사족이겠지만, 자동차 기업의 문화와 소프트웨어 기업의 문화가 다르기 때문이기도 하겠죠?