폭스바겐은 왜 소프트웨어 개발에 막대한 돈을 쓰고도 실패했는가

1. 결론부터 말하면

폭스바겐의 실패 원인은 독일 엔지니어가 부족해서도, 개발자가 무능해서도 아니다.

가장 근본적인 원인은 다음과 같다.

폭스바겐은 소프트웨어를 새로운 제품 운영체계로 보지 않고, 자동차 부품처럼 대규모 조직과 예산으로 통합할 수 있다고 판단했다.

즉, 소프트웨어를 잘 만들기 위해 회사를 바꾼 것이 아니라, 기존 자동차 회사의 구조 안에 소프트웨어 조직을 집어넣었다.

폭스바겐은 제조업에서는 세계 최고 수준이었지만, 바로 그 성공 방식이 소프트웨어에서는 오히려 장애물이 됐다.

2. 정말 23조 원을 투자했는가

폭스바겐의 소프트웨어 투자 금액은 집계 범위에 따라 다르게 표현된다.

폭스바겐은 2020년 당시 2025년까지 디지털화에 약 270억 유로를 투자하겠다고 발표했다. 현재 환율로 단순 환산하면 40조 원을 넘을 수 있다. 다만 이 금액에는 차량 소프트웨어뿐 아니라 공장, 판매, 기업 IT 등 광범위한 디지털 투자가 포함된다. (Volkswagen Group)

소프트웨어 자회사 CARIAD에 직접 투입된 금액은 여러 보도를 종합할 때 약 140억 유로, 한화로 대략 22조~23조 원 수준으로 알려져 있다. 다만 이는 폭스바겐이 공식적으로 발표한 단일 누적 투자액이라기보다 CARIAD의 비용, 손실, 투자액 등을 종합한 추정치에 가깝다. (Adolfo Carreño)

따라서 정확한 표현은 다음과 같다.

폭스바겐이 소프트웨어에 정확히 23조 원을 한 번에 투자한 것이 아니라, CARIAD를 중심으로 장기간 투입한 비용과 손실이 그 정도 규모로 추산된다는 의미다.

3. CARIAD는 무엇을 하려고 했는가

폭스바겐은 2020년 그룹 내 소프트웨어 조직들을 통합해 CARIAD를 만들었다.

목표 자체는 매우 합리적이었다.

폭스바겐, 아우디, 포르쉐, 벤틀리 등 각 브랜드가 따로 개발하던 차량용 운영체제와 전자·전기 아키텍처를 하나로 통합하고, 테슬라처럼 차량 기능을 소프트웨어 업데이트로 지속적으로 개선하려는 계획이었다.

기존 자동차는 수십 개에서 100개가 넘는 전자제어장치, 즉 ECU가 각자 기능을 담당한다. 하지만 소프트웨어 정의 자동차는 중앙 컴퓨터와 통합 운영체제가 차량 전체를 제어한다.

폭스바겐은 이를 위해 다음 세대를 동시에 추진했다.

기존 폭스바겐 전기차용 소프트웨어 1.1
아우디·포르쉐 프리미엄 전기차용 1.2
전 브랜드 공용 차세대 플랫폼 2.0

문제는 이 세 가지를 순차적으로 해결하지 않고, 서로 다른 차량과 브랜드를 대상으로 동시에 개발했다는 점이다.

4. 실패의 근본 원인

4.1 소프트웨어를 부품처럼 생각했다

자동차 제조에서는 요구사항을 먼저 확정하고, 설계하고, 부품을 생산한 뒤 최종 조립한다.

폭스바겐은 이 방식을 소프트웨어에도 적용했다.

수많은 부서와 브랜드가 요구사항을 문서화하고, 이를 CARIAD에 전달하면 CARIAD가 하나의 통합 소프트웨어를 만들어 제공하는 구조였다.

그러나 소프트웨어는 요구사항이 처음부터 완전히 확정되기 어렵다.

실제 제품을 출시하고 사용자의 반응을 확인하면서 짧은 주기로 수정해야 한다. 기능을 조금씩 출시하고, 실패하면 되돌리고, 데이터를 통해 개선해야 한다.

폭스바겐은 소프트웨어를 다음과 같이 접근했다.

text

요구사항 확정
→ 대규모 설계
→ 여러 해 동안 개발
→ 완성 후 차량에 적용

테슬라와 소프트웨어 기업들은 다음과 같이 접근한다.

text

작은 기능 개발
→ 차량에 배포
→ 데이터 수집
→ 문제 수정
→ 반복 개선

폭스바겐의 방식은 출시 전까지 문제가 감춰지고, 통합 단계에서 한꺼번에 폭발하기 쉬웠다.

4.2 하나의 플랫폼으로 모든 브랜드를 너무 빨리 통합했다

폭스바겐 그룹에는 대중차부터 슈퍼카까지 매우 다른 브랜드가 존재한다.

폭스바겐
아우디
포르쉐
스코다
세아트·쿠프라
벤틀리
람보르기니

폭스바겐은 이 모든 브랜드가 사용할 통합 소프트웨어 플랫폼을 빠르게 만들려고 했다.

하지만 각 브랜드의 요구는 완전히 달랐다.

포르쉐는 실시간 주행 제어와 극도로 높은 성능을 요구한다. 아우디는 첨단 전자장비와 프리미엄 사용자 경험을 중요하게 생각한다. 폭스바겐과 스코다는 가격과 대량생산 효율이 중요하다.

이처럼 서로 다른 차량을 처음부터 하나의 플랫폼으로 묶으려다 보니 공통 기능을 결정하는 데 시간이 오래 걸리고, 브랜드마다 예외 기능이 계속 추가됐다.

결국 플랫폼은 단순해지지 않고 더욱 복잡해졌다.

폭스바겐은 공통 플랫폼을 만든 것이 아니라, 모든 브랜드의 요구사항을 한 시스템에 누적했다.

4.3 책임자는 많았지만 최종 제품 책임자는 없었다

자동차 회사는 전통적으로 기능별·부품별 조직으로 나뉜다.

파워트레인
인포테인먼트
섀시
안전
전장
브랜드별 개발조직
외부 부품 공급업체

각 조직은 자신의 부품과 기능에는 책임을 지지만, 사용자가 경험하는 차량 소프트웨어 전체를 한 사람이 책임지기 어렵다.

CARIAD는 그룹 공통 플랫폼을 만들어야 했지만 실제 차량 출시 일정과 판매 성과는 각 브랜드가 책임졌다.

따라서 문제가 발생하면 책임이 나뉘었다.

text

브랜드: CARIAD의 소프트웨어가 늦었다.

CARIAD: 브랜드 요구사항이 계속 바뀌었다.

부품사: 사양이 늦게 확정됐다.

경영진: 조직 간 협업이 부족했다.

결국 모두가 일부 책임을 지면서도, 누구도 전체 결과에 대한 완전한 권한과 책임을 갖지 못했다.

4.4 기존 소프트웨어와 새로운 소프트웨어를 동시에 떠안았다

CARIAD는 깨끗한 상태에서 차세대 플랫폼만 개발한 조직이 아니었다.

이미 문제가 발생하고 있던 폭스바겐 ID 전기차용 소프트웨어를 개선해야 했고, 동시에 아우디와 포르쉐의 신규 플랫폼을 완성해야 했으며, 미래의 통합 플랫폼까지 설계해야 했다.

즉, 다음 세 가지를 한 조직에서 동시에 진행했다.

현재 판매 차량의 오류 수정
곧 출시될 차량의 소프트웨어 개발
수년 뒤 사용할 차세대 플랫폼 구축

현재 차량에 장애가 발생하면 미래 플랫폼 개발자가 긴급 수정 작업에 투입됐다. 신차 출시가 가까워지면 장기적인 아키텍처보다 납기 대응이 우선됐다.

그 결과 긴급 대응이 반복되고, 핵심 플랫폼은 계속 늦어졌다.

4.5 인원을 늘리면 개발 속도가 빨라질 것이라고 생각했다

폭스바겐은 짧은 기간에 수천 명 규모의 소프트웨어 조직을 만들었다.

하지만 소프트웨어 프로젝트는 인원을 두 배로 늘린다고 개발 속도가 두 배로 빨라지지 않는다.

오히려 새 인력이 많아질수록 다음 비용이 증가한다.

의사소통
역할 조정
코드 통합
개발 환경 통일
아키텍처 교육
품질 기준 합의
의사결정 승인

특히 기반 아키텍처가 불안정한 상태에서 인력을 대규모로 늘리면, 많은 사람이 서로 다른 방향으로 빠르게 움직이게 된다.

폭스바겐은 개발자를 확충했지만, 그 개발자들이 빠르게 일할 수 있는 통일된 코드 저장소, 개발도구, 테스트 환경, 배포 체계와 의사결정 구조는 충분히 준비되지 않았다.

문제는 개발자 수가 아니라 개발 시스템이었다.

4.6 자체 개발 비율을 목표로 삼았다

폭스바겐은 차량 소프트웨어의 자체 개발 비중을 크게 높이려 했다.

전략적으로 소프트웨어 역량을 내재화하는 것은 옳은 방향이다. 그러나 내재화 비율 자체가 목표가 되면 문제가 발생한다.

중요한 것은 “얼마나 직접 개발했는가”가 아니라 다음이다.

어떤 기술을 반드시 직접 보유해야 하는가
어떤 기술은 외부 솔루션을 사용하는 것이 유리한가
어떤 부분이 브랜드 경쟁력과 직접 연결되는가
어디에서 개발 속도와 안정성을 확보할 것인가

폭스바겐은 경쟁력의 핵심과 범용 기술을 충분히 구분하지 않은 상태에서 너무 많은 영역을 동시에 내부화하려 했다.

운영체제, 클라우드, 차량 제어, 인포테인먼트, 자율주행, 앱 생태계와 개발도구까지 한꺼번에 직접 장악하려 한 것이다.

이는 소프트웨어 회사 하나를 만드는 것이 아니라, 여러 종류의 소프트웨어 회사를 동시에 만드는 것과 비슷했다.

4.7 하드웨어 중심의 공급업체 구조가 남아 있었다

기존 자동차에서 소프트웨어는 보통 부품과 함께 공급됐다.

예를 들어 인포테인먼트 장치를 공급하는 업체가 하드웨어뿐 아니라 그 안에서 실행되는 소프트웨어도 함께 제공한다.

이 구조에서는 자동차 회사가 차량 전체 소프트웨어의 소스코드, 인터페이스와 데이터 구조를 완전히 통제하기 어렵다.

서로 다른 공급업체가 만든 소프트웨어를 하나로 연결하려면 다음 문제가 발생한다.

중복 기능
호환성 문제
버전 불일치
폐쇄적인 인터페이스
공급업체별 개발도구
복잡한 테스트 과정

폭스바겐은 통합 소프트웨어 회사를 만들었지만, 차량 개발과 공급망은 여전히 부품 중심 구조였다.

소프트웨어 조직만 바꾸고 차량 아키텍처와 계약 구조를 동시에 바꾸지 못한 것이다.

4.8 출시일은 고정했지만 소프트웨어 범위는 줄이지 못했다

전통 자동차 산업에서 신차 출시는 수년 전에 결정된다.

공장 설비, 부품 계약, 마케팅, 인증과 판매 일정이 연결돼 있기 때문에 출시일을 변경하기 어렵다.

소프트웨어 개발이 늦어졌다면 일반적으로 기능 범위를 줄이고 핵심 기능부터 출시해야 한다.

하지만 프리미엄 자동차는 기능을 쉽게 제거하기 어렵다. 아우디와 포르쉐 고객은 높은 완성도를 기대하고, 브랜드별 조직도 자신의 기능을 포기하려 하지 않는다.

결국 일정은 고정돼 있고 요구사항은 계속 유지됐다.

그 결과 아우디 Q6 e-tron과 포르쉐 마칸 EV 등 주요 차량의 출시가 소프트웨어 문제로 지연됐다. CARIAD의 소프트웨어 아키텍처 1.2는 추가 지연을 겪었으며, 구조조정과 함께 대규모 인력 감축 계획도 발표됐다. (Reuters)

5. 왜 똑똑한 독일 기업이 실패했는가

5.1 똑똑함의 문제가 아니라 최적화 방향의 문제다

폭스바겐은 매우 복잡한 자동차를 높은 품질로 수백만 대 생산하는 데 최적화된 회사다.

이를 위해 다음 능력을 발전시켰다.

사전 계획
정밀한 사양 관리
단계별 승인
품질 검증
공급업체 통제
장기간의 제품 개발
대규모 생산 표준화

이 방식은 자동차 제조에서는 강력하다.

하지만 빠르게 변화하는 소프트웨어에서는 다음과 같은 약점으로 바뀐다.

제조업에서의 강점	소프트웨어에서 나타난 문제
철저한 사전 계획	요구사항 변경에 느리게 대응
다단계 승인	의사결정 지연
전문 부서 분업	전체 제품 책임 분산
공급업체 활용	핵심 기술 통제력 부족
완성 후 출시	사용자 피드백 반영 지연
대규모 프로젝트	통합 위험 증가
오류 최소화 문화	실험과 빠른 실패를 회피

폭스바겐은 능력이 부족해서 실패한 것이 아니다.

과거의 성공을 만든 능력을 새로운 환경에서도 그대로 적용했기 때문에 실패했다.

5.2 독일식 완벽주의가 출시 속도를 늦췄다

자동차에서 오류는 안전사고와 리콜로 이어질 수 있다. 따라서 독일 자동차 회사의 완벽주의는 합리적인 문화다.

그러나 모든 소프트웨어 기능을 안전 관련 차량 제어 기능과 같은 수준으로 다루면 개발 속도가 지나치게 느려진다.

브레이크 제어 소프트웨어와 화면 테마 변경 기능은 위험도가 다르다.

다음과 같이 구분했어야 한다.

text

안전 핵심 영역
→ 매우 엄격한 검증과 인증

인포테인먼트·사용자 편의 영역
→ 빠른 배포와 반복 개선

하지만 전통적인 자동차 개발 절차에서는 많은 기능이 비슷한 승인 구조를 거쳤다.

안전을 위한 절차가 전체 소프트웨어 개발의 속도를 제한한 것이다.

5.3 정치적으로도 단순한 기술회사가 아니었다

폭스바겐은 일반적인 민간기업보다 이해관계자가 복잡하다.

브랜드 경영진, 노동조합, 독일 니더작센주, 대주주, 지역 공장, 공급업체가 주요 의사결정에 영향을 미친다.

따라서 기술적으로 옳은 결정이라도 다음 문제가 발생한다.

기존 조직의 권한 축소
브랜드별 독립성 약화
인력 이동과 감축
지역별 고용 문제
기존 공급업체 계약 변경

CARIAD 통합은 단순한 개발 프로젝트가 아니라 그룹 전체의 권력과 책임을 재편하는 프로젝트였다.

하지만 기술 플랫폼은 통합하면서 의사결정 권한과 조직 구조는 완전히 통합하지 못했다.

6. 결정적으로 잘못된 접근 방식

폭스바겐은 다음 순서로 접근했다.

text

거대한 중앙 소프트웨어 조직을 만든다.
여러 브랜드의 개발자를 한 조직에 모은다.
모든 브랜드가 사용할 통합 플랫폼을 설계한다.
자체 개발 비중을 크게 높인다.
미래 플랫폼과 현재 차량 문제를 동시에 해결한다.
정해진 신차 일정에 맞춰 완성한다.

보다 현실적인 접근은 다음과 같았어야 한다.

text

한 개 브랜드와 한 개 차량에서 작은 플랫폼을 검증한다.
차량 전자 아키텍처를 먼저 단순화한다.
중앙 컴퓨터와 OTA 업데이트 기반을 완성한다.
개발·테스트·배포 체계를 표준화한다.
성공한 플랫폼을 두 번째 브랜드에 확장한다.
반복되는 기능부터 점진적으로 공통화한다.
충분히 검증된 뒤 그룹 전체로 확대한다.

폭스바겐은 플랫폼이 검증되기 전에 조직과 적용 범위를 먼저 크게 만들었다.

작은 성공을 확장한 것이 아니라, 거대한 통합을 먼저 선언하고 나중에 성공을 만들려고 했다.

7. 테슬라와 가장 크게 달랐던 점

테슬라는 처음부터 소프트웨어 중심 차량 구조를 설계했다.

차량의 중앙 컴퓨터, 소프트웨어, 데이터 수집, OTA 업데이트와 사용자 앱을 하나의 제품 체계로 만들었다.

반면 폭스바겐은 기존 차량 구조 위에 소프트웨어 플랫폼을 추가하려 했다.

비유하면 다음과 같다.

테슬라는 처음부터 스마트폰을 설계했고, 폭스바겐은 기존 피처폰에 앱스토어를 붙이려고 했다.

폭스바겐에는 기존 공장, 기존 차량 플랫폼, 기존 공급업체, 기존 브랜드와 이미 판매된 차량이 있었다.

따라서 테슬라보다 훨씬 어려운 문제를 풀어야 했다.

다만 어려운 문제였다는 사실과, 접근 방식이 적절했다는 것은 별개의 문제다.

8. 실패 이후 폭스바겐은 무엇을 바꿨는가

폭스바겐은 CARIAD를 완전히 폐기하지 않았다.

경영진을 교체하고 조직을 축소했으며, CARIAD는 기존 차량용 소프트웨어 유지·개선과 그룹 내 통합 역할에 더 집중하도록 재편됐다.

2025년에는 약 1,600명 규모의 추가 인력 감축이 보도됐으며, 이는 당시 약 5,900명 인력의 30%에 가까운 수준이었다. (Reuters)

가장 중요한 변화는 모든 기술을 자체 개발하겠다는 방식에서 벗어난 것이다.

폭스바겐은 2024년 리비안과 전기·전자 아키텍처 및 차량 소프트웨어 공동개발 회사를 설립했고, 투자 규모를 최대 58억 달러로 확대했다. (Volkswagen Group)

이는 사실상 다음과 같은 전략 전환이다.

text

과거
폭스바겐이 모든 핵심 소프트웨어를 직접 통합 개발

현재
CARIAD는 기존 플랫폼과 그룹 통합을 담당
차세대 차량 구조는 리비안 등 외부 파트너와 공동개발
중국 시장은 중국 기술기업과 현지형 플랫폼 개발

2026년 기준 CARIAD는 매출 증가와 적자 축소를 발표하고 있어 완전히 실패한 회사라고 단정할 수는 없다. 2025년 매출은 18억 유로로 증가했으며, 2026년 1분기에도 매출 증가와 손실 개선이 보고됐다. (CARIAD)

따라서 정확한 평가는 다음과 같다.

CARIAD 자체가 완전히 망한 것은 아니지만, 폭스바겐이 처음 계획했던 단일 자체개발 소프트웨어 플랫폼 전략은 사실상 축소·수정됐다.

9. 폭스바겐이 처음부터 다시 한다면

9.1 플랫폼보다 먼저 조직의 책임 구조를 바꿔야 한다

차량 한 대의 소프트웨어 전체를 책임지는 단일 제품 책임자가 필요하다.

그 책임자에게 다음 권한이 함께 주어져야 한다.

기능 우선순위 결정
일정 조정
기능 제거
브랜드 간 요구사항 조정
외부 솔루션 도입
출시 여부 결정

책임만 있고 권한이 없거나, 권한이 여러 브랜드에 흩어져 있으면 통합 제품을 만들 수 없다.

9.2 하나의 차량에서 완성한 뒤 확대해야 한다

첫 번째 목표는 전 브랜드 공통 운영체제가 아니라, 한 개 차량에서 안정적으로 동작하는 소프트웨어 플랫폼이어야 한다.

예를 들어 다음처럼 진행할 수 있다.

text

1단계: 한 개 대중차 모델
2단계: 같은 플랫폼의 SUV 모델
3단계: 같은 브랜드 전체
4단계: 인접 브랜드
5단계: 프리미엄 브랜드

공통화는 선언으로 이루어지는 것이 아니라 반복되는 성공을 통해 만들어야 한다.

9.3 안전 소프트웨어와 일반 소프트웨어를 분리해야 한다

모든 기능을 하나의 개발 절차로 관리해서는 안 된다.

제동·조향·배터리 제어: 엄격한 인증과 장기 검증
인포테인먼트·앱·개인화: 짧은 주기의 지속적 배포
클라우드 서비스: 차량과 독립적인 수시 업데이트

영역별 위험도에 따라 개발 속도와 검증 절차를 달리해야 한다.

9.4 내부 개발과 외부 기술의 경계를 명확히 해야 한다

반드시 직접 보유할 영역은 다음과 같다.

차량 데이터 구조
차량 제어 인터페이스
OTA 업데이트 권한
사이버보안 핵심
고객 계정과 서비스 플랫폼
차량 전체 아키텍처

반면 범용 지도, 음성인식, 앱 생태계와 클라우드 인프라는 외부 전문기업을 활용할 수 있다.

핵심은 모든 코드를 직접 작성하는 것이 아니라, 시스템의 구조와 최종 통제권을 보유하는 것이다.

10. 기업과 개발 조직이 얻어야 할 교훈

교훈 1. 큰 예산은 불명확한 구조를 해결하지 못한다

아키텍처와 책임 구조가 불명확한 프로젝트에 인력과 예산을 추가하면 개발 속도가 빨라지는 것이 아니라 혼란의 규모가 커진다.

교훈 2. 디지털 전환은 IT 조직을 만드는 일이 아니다

기존 회사 옆에 소프트웨어 조직을 하나 추가한다고 소프트웨어 기업이 되는 것은 아니다.

제품 결정 방식, 예산 배분, 평가 기준, 조직 권한과 출시 방식까지 바뀌어야 한다.

교훈 3. 플랫폼은 처음부터 크게 만드는 것이 아니다

플랫폼은 여러 제품에서 검증된 공통 부분을 추출한 결과여야 한다.

아직 제품 하나도 완성하지 못한 상태에서 전사 플랫폼부터 만들면 추상화와 조정 비용이 폭발한다.

교훈 4. 기존 사업에서 뛰어난 조직일수록 변화가 더 어렵다

폭스바겐은 무능해서 실패한 것이 아니다.

기존 방식으로도 오랫동안 큰 성공을 거뒀기 때문에, 그 방식을 근본적으로 바꾸기 어려웠다.

성공 경험이 강할수록 기존 구조를 포기하는 비용도 커진다.

11. 최종 평가

폭스바겐의 소프트웨어 실패는 기술 문제가 아니라 운영체계의 충돌이었다.

text

자동차 제조의 운영체계
정확한 계획 → 부품 분업 → 단계별 승인 → 완성 후 출시

소프트웨어의 운영체계
작은 출시 → 사용자 데이터 → 반복 개선 → 지속적 업데이트

폭스바겐은 두 번째 운영체계가 필요했지만 첫 번째 운영체제로 관리했다.

독일의 정밀함, 품질관리, 분업과 장기계획은 자동차 산업을 지배하게 만든 힘이었다. 그러나 소프트웨어 시대에는 같은 특성이 느린 의사결정, 조직 간 책임 분산과 과도한 통합으로 나타났다.

따라서 폭스바겐 사례의 핵심은 다음 한 문장으로 정리할 수 있다.

폭스바겐은 소프트웨어 개발에 돈을 적게 써서 실패한 것이 아니라, 소프트웨어를 만드는 방식으로 회사를 바꾸지 않은 채 돈만 크게 썼기 때문에 실패했다.

폭스바겐은 왜 소프트웨어 개발에 막대한 돈을 쓰고도 실패했는가 - 23조 ~40조 프로젝트

중년개발자