전 테슬라 엔지니어가 느끼는 현대자동차의 문제점 (맹성준 작가)
학습 가이드
- 이 영상에서 확인할 것
- 제어기·소프트웨어·시험 데이터를 연결하면 실제 엔지니어의 업무가 어떻게 달라지는지 사례로 살펴봅니다. 수직 통합의 장점뿐 아니라 기존 차종·공급망·조직을 바꾸는 비용과 다른 전략의 가능성도 비교할 수 있습니다.
- 알아두면 도움되는 것
- 기업의 소프트웨어 경쟁력을 볼 때 기능 수보다 코드 변경 권한, 데이터 접근, 부서 간 협업과 검증·배포 속도를 질문할 수 있습니다. 자율주행을 평가할 때도 서비스 지역·차량·감독 책임·검증 조건을 구별하는 데 도움이 됩니다.
시간순
8개 구간출연자는 자체 도구·제어기와 원격 데이터가 연결되면서 시험·분석·업데이트 방식이 달라졌다고 설명한다. 핵심은 무선 업데이트 기능의 유무만이 아니라 필요한 변경을 누가 수행하고 결과를 얼마나 빨리 검증할 수 있는가다. 모델로 시험 조건을 보정하는 사례도 검증된 적용 범위와 오차 관리가 전제되어야 하며 실제 시험을 언제나 대체할 수 있다는 뜻은 아니다.
ASSETCASTING 학습 메모
별도로 작성한 학습 메모이며 원영상 제작자의 발언이 아닙니다. 영상의 모든 주장을 검증한 것은 아닙니다.
작업 속도보다 변경을 기다리는 시간이 더 클 수 있다
자체 가정으로 기능 변경 한 건에 실제 개발·검증 2일과 부서·공급사 응답 대기 8일이 걸리면 전체 소요기간은 10일이다. AI로 개발·검증을 1일로 줄여도 대기가 그대로면 9일로, 전체 개선은 10%다. 반대로 실제 작업은 2일을 유지하고 권한·협업 구조를 바꿔 대기를 2일로 줄이면 전체 4일로 60% 짧아진다. 따라서 도구 도입 효과를 볼 때 실제 작업시간과 대기시간을 따로 기록하고, 안전 검증을 생략해 얻은 단축은 개선으로 세지 않아야 한다.
직접 점검하기
- 지난 변경 작업에서 실제 개발·검증과 승인·응답 대기는 각각 얼마나 걸렸는가?
- 누가 코드와 데이터를 바꿀 권한을 가지며 병목을 옮기지 않고 대기를 줄일 수 있는가?
- 출시 속도를 높이면서 회귀 오류·안전 검증·유지보수 비용은 어떻게 확인할 것인가?
적용의 한계
수치는 설명을 위한 가정이며 테슬라나 현대차의 실제 개발기간을 측정한 결과가 아니다. 직렬 작업을 가정했으므로 병렬화·공유 인력·법정 승인 등이 있는 실제 일정에는 별도 분석이 필요하고 내재화가 항상 최선이라는 결론도 아니다.