자동차 소프트웨어 개발 경쟁, 승자의 조건은?

최근 맥킨지(McKinsey & Company) 보고서에 따르면, 전통적인 완성차 업체(OEM)와 1차 협력사는 개발 프로젝트 시작부터 소프트웨어 출시까지 평균 40~50개월에 이르는 긴 개발 주기를 갖는다(그림 1). 반면, 테슬라와 BYD(비야디) 같은 신흥 완성차 업체들은 소프트웨어를 포함한 전체 차량 개발을 24~30개월 안에 끝낸다. 일부 중국 업체는 18개월 만에 개발을 끝내기도 한다. 
이러한 개발 속도 차이는 사실상 결정적인 경쟁 요인이 되고 있다. 전통 완성차 업체들도 이를 실감하고 있으며, 소프트웨어 투자를 늘리고 있다. 예를 들어 폭스바겐은 카리아드(CARIAD)에만 120억 유로(약 19조 4,292억 원) 이상을 투입했다. 현대자동차그룹은 3년간 포티투닷(42dot)에 총 1조 978억 원을 투입했다. 그럼에도 전통적인 완성차 업체와 신흥 업체 간 소프트웨어 격차는 오히려 벌어지고 있다. 
자동차 산업에서 소프트웨어의 중요성은 갈수록 커지고 있다. 많은 사람이 차량 소프트웨어라고 하면 인포테인먼트 시스템을 주로 떠올리지만, 실제로 그 범위는 훨씬 넓다. 오늘날 소프트웨어는 차량의 핵심 기능 대부분을 제어하며, 차량 개발의 속도와 품질을 좌우하는 핵심 요소로 자리 잡고 있다.
소프트웨어는 구동과 제동, 배터리 및 에너지 관리, 주행 다이내믹스와 운전자 보조 시스템뿐 아니라 OTA(Over-the-Air) 업데이트와 다양한 애플리케이션까지 아우른다. 이러한 기능은 차량의 안전, 성능, 사용자 경험과 직결되기 때문에 자동차 제조사에게 소프트웨어 경쟁력은 더는 선택이 아닌 필수 조건이다.
문제는 소프트웨어의 복잡성이 높아지면서 개발 과정에서 발생하는 지연 사례가 늘고 있다는 점이다. 실제로 소프트웨어 문제로 인해, 아우디 Q6 e-트론은 16개월의 출시 지연이 발생했다. 또한, 볼보 EX90과 포드 익스플로러 EV는 6개월이 지연됐다. 이처럼 소프트웨어 문제는 단순한 기능상의 오류를 넘어 차량 개발 전체 일정에 직접적인 영향을 미친다. 소프트웨어가 곧 차량 개발의 타임라인을 결정하는 시대가 된 것이다. 

 

고전적 V-모델

전통적인 완성차 업체들은 차량 개발에 있어서 고전적인 V-모델을 따른다. 이 모델은 왼쪽에서 요구사항 정의와 설계, 하단에서 구현, 오른쪽에서 테스트와 통합이 이뤄지는 구조다. V-모델은 1970년대에 만들어졌으며, 본래 하드웨어 개발에 최적화된 방식이다. 그러나 소프트웨어 개발에서는 두 가지 근본적인 한계를 내포하고 있다.
첫째, 사일로(Silo) 구조다. 각 팀은 서로 단절된 상태에서 개발 업무를 수행한다. 예를 들어 요구사항을 정의하는 팀은 테스트 단계에 거의 관여하지 않는다.
둘째, 워터폴(Waterfall) 방식이다. 이 방식은 프로젝트가 요구사항 정의, 설계, 개발, 테스트, 배포, 유지보수 등의 단계로 폭포수처럼 위에서 아래로 순차적으로 진행되는 전통적인 방법론이다. 각 단계가 상당 부분 완료돼야 다음 단계로 넘어갈 수 있으며, 피드백은 개발 후반에야 이뤄진다. 이는 빠른 반복과 개선이 필수적인 소프트웨어 개발에 큰 걸림돌로 작용한다. 
실제 사례를 들면, 구매 부서와 개발 부서 간의 소통이 원활하지 않아 문제가 발생하는 경우다. 구매 부서는 기술 요구사항을 충분히 이해하지 못한 채 협력사와 가격 협상을 진행하는 경우가 많다. 이러한 구조는 소프트웨어 품질과 개발 효율성 모두에 부정적인 영향을 준다. 

 

차량 모델 다양성 문제

전통적인 완성차 업체가 직면한 현실 중 하나는 간과하기 쉽지만, 치명적인 요소인 제품 다양성 문제다. 맥킨지에 따르면, 이들의 차량 모델 기준 포트폴리오는 신생 경쟁사보다 최대 150배에 이를 수 있다. 이 차이는 수십 개의 서로 다른 모델을 지원해야 하고, 내연기관·전기차·하이브리드 파워트레인을 모두 개발해야 하고, 여러 소프트웨어 플랫폼을 유지해야 할 뿐 아니라, 다양한 시장별 요구사항까지 충족해야 한다는 의미다.
그 결과는 명확하다. 모든 소프트웨어 변경 사항이 수많은 차량 변형 모델과 호환돼야 한다는 점이다. 이는 엄청난 비용을 초래할 뿐만 아니라 개발 속도를 극도로 늦춘다. 이러한 구조적 복잡성이 기존 자동차 제조사들이 소프트웨어 경쟁에서 뒤처지는 요인 중 하나일 수 있다. 

구조적 문제

맥킨지에 따르면, 전통적인 완성차 업체들은 소프트웨어 개발 과정에서 구조적 한계로 인해 경쟁에서 뒤처질 수밖에 없는 상황에 직면해 있다. 맥킨지는 주요 문제를 네 가지로 요약했다. 
첫째, 구식 개발 도구의 사용이다. 기술 기업들은 통합되고 자동화된 개발 프로세스를 활용하지만, 전통적인 완성차 업체들은 서로 다른 도구를 조합해 사용하곤 한다. 요구사항 관리용 시스템, 테스트 케이스용 시스템, 결함 보고용 시스템이 따로 존재하며 각 도구 간 인터페이스가 병목 현상을 초래한다. 
둘째, 미흡한 프로젝트 관리다. 개별 기능 영역별로 여러 계획이 존재하지만, 경우에 따라서 서로 상충되기도 한다. 전체 진행 상황을 한눈에 파악할 수 있는 체계가 부족하다.
셋째, 하드웨어 중심의 소프트웨어 개발 방식이다. 전통적인 개발 프로세스는 하드웨어 개발에 맞춰 설계됐다. 이러한 방식은 반복적이고 빠른 소프트웨어 개발 특성과 맞지 않는다. 전통적인 완성차 업체들은 기존 하드웨어 프로세스 안에서 소프트웨어를 억지로 끼워 맞추려 할 뿐, 새로운 소프트웨어 전용 프로세스를 구축하는 데 난항을 겪고 있다. 
넷째, 불투명한 프로세스의 문제다. 개발 과정에서 품질 기준이 자주 변경된다. 초기에는 허용되던 사항이 나중 테스트에서 문제가 되기도 한다. 이로 인해 생산 일정이 수개월씩 지연되는 사례가 발생한다. 
이 네 가지 구조적 문제는 전통 완성차 업체들이 소프트웨어 경쟁에서 속도를 내기 어렵게 만드는 핵심 요인으로 꼽힌다. 

인재 격차

전통적인 자동차 업계가 직면한 또 다른 중요한 과제는 소프트웨어 인재 부족이다. 소프트웨어정책연구소(SPRi)의 조사에 따르면, 2025년 1월 기준 미래형 자동차 산업의 소프트웨어 개발자 부족 인력은 약 7,000명에 달하며, 이는 자동차 산업 전체 부족 인력의 절반에 가까운 수치다. 또 한국자동차연구원에 따르면, 국내 완성차 업체들의 소프트웨어 인력 규모는 지난해 상반기 기준 1,000명 이하로 추산된다. 
문제의 핵심은 자동차 업체들이 소프트웨어 분야에서 기술 기업들과 동일한 인재를 두고 경쟁해야 한다는 것이다. 하지만 진짜 문제는 단순한 인력 부족을 넘어 더 구조적인 한계가 있다는 것이다. 자동차 기업의 기존 구조는 소프트웨어 인재에 최적화돼 있지 않다. 완성차 업체들이 인재를 놓고 경쟁하는 IT 기업들은 더 매력적인 보상(임금), 문화, 프로세스를 제공한다. 
많은 완성차 업체에서는 전통적인 엔지니어가 소프트웨어 개발을 관리한다. 이들은 공급업체 관리에는 능숙하지만, 소프트웨어 전문 지식은 부족한 경우가 많다. 이러한 인재 구조는 차량 소프트웨어 경쟁력 확보를 어렵게 만드는 요인으로 작용한다. 
신흥 완성차 업체들은 전통 완성차 회사와 달리 소프트웨어 중심의 개발 전략을 채택하여 경쟁력을 높이고 있다. 대표 사례인 테슬라는 차량 리콜의 99%를 OTA(무선 업데이트)를 통해 해결한다. 이는 기존에 없던 전혀 다른 개발 접근 방식의 결과다.
신흥 완성차 업체들은 차량 개발보다 소프트웨어를 중심에 둔 소프트웨어 우선(Software-First) 개발 접근 방식을 취하고 있다. 또 통합 하드웨어-소프트웨어 팀 운영을 통하여 개발 초기부터 하드웨어와 소프트웨어가 긴밀히 협력한다. 게다가 짧은 개발 스프린트(Sprint) 활용으로, 1~2주 단위로 반복적 개발을 진행하여 빠른 피드백과 개선을 가능하게 한다. 
신흥 완성차 업체가 경쟁력을 확보할 수 있는 또 다른 이유 중 하나는 높은 코드 재사용이다. 이들은 이미 작성된 소프트웨어를 다양한 모델과 기능에 효율적으로 적용한다. 
핵심은 이들 기업이 스스로 자동차를 만드는 소프트웨어 기업으로 인식한다는 점이다. 기존 완성차 업체처럼 ‘자동차 기업이 소프트웨어를 활용하는 방식’과는 근본적으로 접근 방식이 다르다. 이러한 사고방식이 신흥 업체들을 소프트웨어 경쟁에서 우위에 서게 만든다. 

부분적 개선으론 부족, 근본적 전환이 답

전통적인 완성차 업체들이 소프트웨어 경쟁에서 뒤처지지 않기 위해서는 근본적인 접근 방식의 변화가 필요하다. 맥킨지는 다섯 가지 핵심 방안을 제시했다.
우선, 소프트웨어 중심 사고(Software-First)를 정착시켜야 한다. 소프트웨어는 개발 초기 단계부터 중심에 놓여야 한다. 하드웨어 먼저가 아니라, 소프트웨어가 주도해야 한다. 이를 위해 소프트웨어 전문가를 핵심 리더십 포지션에 배치하는 것이 표준이어야 한다. 
둘째, 개발 프로세스를 재구성해야 한다. 소프트웨어는 가상 환경에서 테스트할 수 있다. 수개월에 걸친 전통적인 테스트 사이클 대신, 빠른 피드백을 통한 반복적 검증이 시간과 비용을 절약할 수 있다.
셋째, 인재와 조직 문화를 혁신해야 한다. 기존의 경직된 조직 구조에서 벗어나 새로운 경력 경로를 제공하고, 시장 수준에 맞는 보상제를 도입해야 한다. 무엇보다도 소프트웨어 전문가가 성장할 수 있는 환경을 만드는 것이 중요하다. 
넷째, 모델과 변형을 최소화해야 한다. 불필요한 차량 모델과 옵션의 다양성은 개발 속도를 늦춘다. 그룹 내 모든 차량이 공유할 수 있는 통합 운영체제 구축을 목표로 해야 한다. 
다섯째, 협업을 확대해야 한다. 업계 전반의 협업을 통해 소프트웨어를 공동 개발하는 방안이 필요하다. 예를 들어 독일에서 진행되는 S-CORE 프로젝트가 이러한 협력의 대표적인 사례다. S-CORE 프로젝트는 소프트웨어 정의 차량(SDV)를 위한 오픈소스 소프트웨어 스택의 기반을 구축하는 이클립스 재단(Eclipse Foundation)의 프로젝트다. 독일 자동차산업협회(VDA) 주도로 BMW, 메르세데스 벤츠, 폭스바겐 등 유럽의 주요 자동차 기업이 참여하고 있다. 
이 다섯 가지 방안은 전통 완성차 업체들이 소프트웨어 경쟁에서 속도를 높이고, 신흥 경쟁업체와 격차를 줄이는 데 핵심적인 역할을 하게 된다. 
추가로, 소프트웨어 개발 속도를 높이기 위해서는 소프트웨어 생애주기 전반에 걸쳐 AI와 머신러닝(ML)을 적극적으로 도입해야 한다. 맥킨지 보고서는 AI 기반 코드 생성 도구를 활용해 반복적인 코딩 작업의 상당 부분을 자동화하여 신규 기능 개발에 필요한 시간을 대폭 단축하는 방향으로 전환이 필요하다고 지적했다. 또한, 지능형 AI 기반 테스트 프레임워크를 도입함으로써 품질 보증 방식을 혁신하고 개발 초기 단계에서 결함을 사전에 식별하고 해결할 수 있다. 
그동안 많은 전통적인 완성차 업체들은 소프트웨어를 기존 프로세스 안에서 개발하는 방식을 사용해왔다. 그러나 앞으로는 소프트웨어 개발이 핵심에 자리하는 새로운 접근이 필요하다. 단편적인 개선만으로는 충분하지 않으며, 경쟁력 강화를 위해서는 ‘소프트웨어 우선’ 기업으로의 전환이 요구된다. 지금이 그 변화를 시작할 적기다.

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

---