자동차를 구동하는 소프트웨어가, 이를 개발한 도구들의 한계를 뛰어넘고 있다
현대 자동차는 더 이상 소프트웨어 레이어가 덧씌워진 기계적 제품이 아니라, 바퀴 달린 소프트웨어 플랫폼입니다. 오늘날 평균적인 자동차는 수십 개의 독립적인 전자 제어 장치(ECU)에 분산된 수억 줄의 코드를 실행하며, 경우에 따라 소프트웨어의 복잡성 면에서 상업용 항공기에 필적하기도 합니다. 전력 관리, 차체 제어, 인포테인먼트, 첨단 운전자 보조 시스템(ADAS) 등은 모두 코드에 의존하며, 그 코드는 끊임없이 변화하고 있습니다.
그러나 많은 자동차 임베디드 팀은 여전히 5년 개발 주기가 당연시되던, 완전히 다른 시대를 위해 구축된 워크플로우와 아키텍처에 얽매여 있습니다. 오늘날, 업계 관계자들이 ‘중국식 속도’라고 부르는 현상—신규 OEM들이 차량을 시장에 출시하고 고객에게 무선(OTA) 업데이트를 제공하는 끊임없는 속도—에 힘입어, 그 일정은 2년 미만으로 단축되었습니다. ‘차이나 스피드’는 더 이상 예외가 아닙니다. 이는 차량이 설계, 제작, 업데이트되는 속도에 대한 전 세계의 기대치를 재편하고 있습니다.
IAR이 ‘1억 라인의 덫’이라고 부르는 바로 이 현상이, 자동차 시장을 위한 안전이 핵심인 임베디드 소프트웨어를 개발하는 모든 팀에 매우 실질적인 영향을 미치고 있습니다.
다른 산업에서 볼 수 있듯이, 빠르게 움직이며 문제를 일으키려는 방식은 자동차 소프트웨어 분야에서는 단순히 통하지 않습니다. 리콜과 늦은 수정 조치는 예측할 수 없는 비용과 브랜드에 대한 장기적인 위험을 초래합니다.
이 함정에서 벗어나기가 왜 이렇게 어려운 것일까요?
핵심 문제는 코드 양 자체가 아니라, 그 코드가 어떻게 구조화되고 관리되는지에 있습니다. 기존의 자동차 플랫폼은 수십 개의 독립적인 ECU를 중심으로 구축되어 있으며, 각 ECU는 자체 소프트웨어 스택을 실행하고, 별도의 공급업체가 관리하며, 고유한 수명 주기를 가지고, 모든 시스템이 경쟁적으로 사용하는 CAN 버스를 통해 통신합니다.
이러한 환경에서는 사소한 변경조차도 막대한 조정 작업을 필요로 합니다. 단일 기능을 업데이트하는 데에도 여러 공급업체의 협력이 필요할 수 있으며, 다양한 ECU에 걸친 광범위한 재테스트와 새로운 검증 자료가 확보되어야만 안전 인증 기관이 릴리스를 승인합니다. 그 결과 릴리스 속도가 느려지고, 패치되지 않은 취약점에 노출되는 기간이 길어지며, 기술적 부채가 누적되어 향후 모든 변경에 더 많은 비용이 소요됩니다.
다음과 같은 네 가지 지속적인 과제가 팀들의 발목을 잡고 있습니다:
- 레거시 하드웨어의 제약: CAN을 통해 연결된 기존 ECU 설계는 하드웨어와의 밀접한 결합, 대역폭 및 메모리 한계로 인해 소프트웨어 재사용을 제한하고 개발 속도를 저하시킵니다.
- 서로 맞지 않는 프로세스: 하드웨어 중심의 개발 모델은 현대적인 DevOps 및 CI/CD 관행과 상충되어 자동화, 시뮬레이션, 재현 가능한 빌드를 어렵게 만들며, 이러한 시스템에서는 소프트웨어의 성장 속도가 하드웨어의 성장 속도를 앞지르고 있습니다.
- 분산된 아키텍처: 통합된 접근 방식이缺如한 상태에서 팀들은 AUTOSAR, 서비스 지향 미들웨어, 혼합 통신 프로토콜을 통합하는 데 어려움을 겪는 독자적인 스택을 구축합니다.
- 규정 준수 복잡성: 수십 개의 ECU에 걸쳐 ISO 26262 기능 안전 및 ISO/SAE 21434 사이버 보안 요구 사항을 충족하는 작업은 시간이 오래 걸리고 많은 자원을 소모합니다. 사소한 변경조차도 전체 재인증을 유발할 수 있습니다.
- 인피니언(Infineon), Qt, 벡터(Vector), 일렉트로비트(Elektrobit) 등 파트너사와 사전 통합된 소프트웨어 번들은 즉시 사용 가능한 검증된 기반, 그래픽 스택, 안전 크리티컬 제어 소프트웨어를 제공하여, 팀이 통합 작업을 처음부터 시작하지 않고도 개념 단계에서 양산 단계로 바로 넘어갈 수 있도록 지원합니다.
- Vector, ETAS, Elektrobit 등의 파트너와 검증된 AUTOSAR Classic 및 MCAL 통합을 통해 안전 크리티컬 MCU를 위한 결정론적이고 ISO 26262에 최적화된 워크플로우를 제공하여, 통합 위험과 재인증 노력을 줄여줍니다. 도메인 전반에 걸쳐 확장 가능한 ECU 개발을 실현하면서도 최고 수준의 안전 요구 사항을 충족합니다.
- Dojo5와 같은 CI/CD 파이프라인 전문가는 사내 DevOps 전문 지식이 부족한 팀을 위해 컨테이너화된 파이프라인을 설정하고 유지 관리할 수 있습니다. 이들은 파이프라인을 구축하여 인계하거나, 엔지니어에게 유지 관리 방법을 교육하거나, 지속적으로 운영할 수 있으므로, 소규모 팀의 경우에도 전담 CI/CD 전문가가 없어도 도입에 지장이 없습니다.
이러한 과제들이 복합적으로 작용하면 자동차 소프트웨어의 확장이 극도로 어려워지며, 이는 새로운 아키텍처와 워크플로가 더 이상 선택 사항이 아닌 이유를 설명해 줍니다.
아키텍처 재고: 도메인에서 존으로
이러한 함정에서 벗어나기 위해서는 차량 아키텍처와 이를 둘러싼 개발 워크플로우를 모두 재고해야 합니다. 기존의 자동차 플랫폼은 ECU 중심의 도메인 아키텍처(차체, 파워트레인, ADAS 등)를 기반으로 구축되어 있으며, 이러한 구조 내에서도 팀들은 소프트웨어 중복, 복잡한 배선, 그리고 시스템 전반에 걸친 느린 업데이트 문제에 직면하고 있습니다.
이미지: 지멘스 디지털 인더스트리즈
현재 업계는 구역(zonal) 및 혼합 도메인 구역 아키텍처로 전환하고 있습니다. 구역 기반 설계는 ECU를 기능별로 분류하는 대신 차량 내 물리적 위치에 따라 그룹화하고, 이를 중앙 집중식 또는 지역별 컴퓨팅 구조에 연결합니다. 이를 통해 배선과 무게를 줄이고, 데이터 처리량을 늘리며, 무엇보다도 통합 및 업데이트 과정을 획기적으로 간소화할 수 있습니다.
더 많은 기능이 더 적고 강력한 컨트롤러로 통합됨에 따라, 컨테이너화와 가상화는 필수적입니다. 이를 통해 서로 다른 중요도 수준의 소프트웨어를 공유 하드웨어에서 안전하게 실행할 수 있습니다. 그러나 이를 확장하기 위해서는 소프트웨어를 하드웨어로부터 분리하여, 지속적인 재인증 없이도 재사용 및 업데이트가 가능해야 합니다. 이를 위해서는 새로운 워크플로우, 하드웨어·소프트웨어·기능 안전·사이버 보안 팀 간의 긴밀한 협업, 그리고 재현 가능한 CI/CD 파이프라인을 갖춘 통합 툴체인이 필요합니다.
현대적인 아키텍처는 워크플로가 아키텍처와 함께 진화할 때만 진정한 가치를 제공합니다.
OTA 업데이트, 재현 가능한 빌드, 그리고 장기적인 전략
소프트웨어 정의 차량(SDV)의 세계에서 소프트웨어는 양산 개시(SOP) 시점에 변화가 멈추지 않습니다. 안전이 중요한 시스템에서조차 빈번한 무선 업데이트(OTA)는 이제 표준이 되었습니다. 차량은 수명 주기 전반에 걸쳐 현장에서 패치, 업데이트 및 개선을 받아야 하는데, 이는 기존의 V-사이클 프로세스만으로는 지원할 수 없는 부분입니다.
이로 인해 많은 팀이 과소평가하는 요구 사항이 발생합니다. 바로 수년 후에도 정확히 동일한 소프트웨어를 재빌드하여 OTA 업데이트를 검증하고, 현장 문제를 조사하며, 기능 안전 규정을 준수할 수 있어야 한다는 점입니다. 컨테이너화가 이를 가능하게 하는 핵심 요소입니다. 툴체인 및 빌드 환경을 컨테이너 내에 고정함으로써, 팀은 규제 당국이 신뢰할 수 있는 결정론적이고 추적 가능한 바이너리를 생성할 수 있습니다. 이 바이너리는 개발자의 컴퓨터, CI 파이프라인, OTA 배포 시스템에서 모두 동일하게 유지됩니다.
이는 단순한 이론적 이점이 아닙니다. IAR의 웨비나에서 진행된 실습 시연에서는, GitHub Actions 파이프라인에서는 정상적으로 빌드되던 모터 제어 프로젝트가, 동일한 툴체인 버전과 소스 코드를 사용했음에도 개발자의 로컬 머신에서는 실패하여 서로 다른 결과가 나오는 사례가 확인되었습니다. 빠진 부분은 바로 인피니온(Infineon) MCU용 디바이스 지원 파일이었는데, 이 파일은 컨테이너화된 Docker 이미지에는 포함되어 있었으나 로컬 설치 환경에는 없었습니다. 파이프라인이 사용하는 것과 동일한 환경인 개발용 컨테이너 내에서 프로젝트를 열자 문제가 즉시 해결되었습니다. 동일한 빌드. 오류 없음. 이것이 바로 재현 가능한 빌드가 실제로 어떤 모습인지 보여주는 사례입니다.
또한 차량의 수명이 10년, 15년, 심지어 25년 이상에 달하기 때문에 장기 지원은 단순히 ‘있으면 좋은’ 것이 아닙니다. 이는 기능 안전 규정 준수를 유지하기 위한 토대입니다. 툴체인이 변경될 때마다 개발 팀과 안전 재인증 절차에 마찰이 발생합니다. 안정적이고 지원이 보장된 툴체인이 없다면, 출시 5년 이후의 모든 OTA 업데이트는 재인증 프로젝트가 되어버립니다. 장기 지원은 CI/CD 파이프라인과 안전 증거의 유효성을 유지하여, 차량 수명 주기 전반에 걸쳐 전체 차량에 대한 OTA 업데이트가 안전하고 규정을 준수하며 예측 가능하도록 합니다.
IAR 플랫폼: 차량의 전체 수명 주기를 위해 설계됨
IAR은 출시 시점뿐만 아니라, 초기 설계 확정부터 수십 년에 걸친 현장 업데이트에 이르기까지 소프트웨어 정의 차량(SDV)의 전체 수명 주기를 위해 설계된 안전 인증 개발 플랫폼을 통해 이러한 과제를 해결합니다.
출시 첫날부터 ASIL D 등급까지의 안전 인증 지원
IAR의 툴체인은 기능 안전성 기준 중 가장 엄격한 수준인 자동차 안전 무결성 수준 D(ASIL D)까지 ISO 26262 인증을 TÜV SÜD로부터 획득했습니다. 이는 많은 팀이 인식하는 것보다 훨씬 더 중요한 사항입니다. 사전 인증된 툴체인이 없다면, 팀들은 일반적으로 새로운 인증 프로젝트가 있을 때마다 컴파일러를 재인증하는 데 6~12인월을 소요하며, 툴체인이 재현 가능하고 표준을 준수하는 결과를 산출함을 입증하기 위해 광범위한 테스트를 수행해야 합니다.
사전 인증된 툴체인을 사용하면 이러한 증거가 이미 확보된 상태입니다. 팀은 툴 인증서를 인증 기관에 제출하면, 인증 기관은 툴체인 자체보다는 애플리케이션의 안전 기능과 이에 대한 테스트에 집중하게 됩니다. 이를 통해 시간, 비용 및 위험을 상당히 절감할 수 있습니다.
이는 일부 팀을 놀라게 하는 결정, 즉 기능 안전 툴링은 개발 도중 도입하는 것이 아니라 프로젝트 초기 단계에서 선택해야 한다는 주장을 뒷받침합니다. 프로그램이 이미 진행 중인 상태에서 툴체인을 교체하는 것은 팀이 할 수 있는 가장 큰 차질을 초래하는 일 중 하나이며, 인증 기관은 이를 부정적으로 평가할 것입니다. 실제로, 팀이 인증된 툴체인을 표준으로 채택하면 해당 제품의 전체 수명 주기(일반적으로 10~15년) 동안 이를 계속 사용합니다. 툴체인 선정은 단순한 조달 세부 사항이 아니라 프로그램 차원의 약속입니다.
내장된 디버깅, 분석 및 코드 품질
멀티코어 디버깅, 라이브 코드 프로파일링, RTOS 인식 기능을 포함한 고급 디버깅 및 추적 기능을 통해 복잡한 SDV 시스템을 관찰하고 예측할 수 있습니다. C-STAT을 활용한 내장 정적 분석과 런타임 분석은 개발 주기 초기에 문제를 조기에 포착하며, 모델 기반 설계와 MISRA 준수 코드 생성은 구조화되고 인증 가능한 개발을 지원합니다. 그 결과, 빌드할 때마다 품질과 규정 준수가 자동으로 확보되므로, 업데이트가 막판에 이루어지는 위험 평가로 전락하는 일이 없습니다.
광범위한 MCU/MPU 지원, 하드웨어 종속성 없음
IAR은 ARM, RISC-V, Renesas, STM8 및 기타 여러 아키텍처를 지원하며, Infineon, NXP, Microchip, STMicroelectronics, SemiDrive 등의 실리콘에 대한 심층적인 디바이스 지원을 제공합니다. 이러한 폭넓은 지원 덕분에 팀은 새로운 플랫폼이 나올 때마다 소프트웨어를 다시 작성할 필요 없이 ECU, 구역 및 차량 세대를 넘나들며 소프트웨어를 재사용할 수 있습니다. 이는 불안정한 공급망으로 인해 하드웨어 전환이 불가피한 상황에서 매우 중요한 이점입니다. 오늘의 유연성이 내일의 장기적인 프로그램을 보호합니다.
CI/CD, 컨테이너 및 최신 임베디드 워크플로우
IAR은 GitHub Actions, GitLab CI, Jenkins, Kubernetes와 같은 최신 CI/CD 환경에 직접 통합되므로, 임베디드 소프트웨어 팀은 클라우드 소프트웨어 팀과 동일한 속도로 업무를 진행할 수 있습니다. VS Code용 IAR 확장 프로그램과 헤드리스 빌드를 위한 IAR Build Tools는 안전 인증을 받은 동일한 툴체인을 컨테이너화된 DevOps 파이프라인에 적용합니다. 클라우드 기반 라이선싱을 통해 툴체인은 고정된 머신이 아닌 팀과 함께 이동합니다. 컨테이너화된 환경은 일상적인 개발 과정에서 발생하는 마찰을 제거합니다. 빌드는 예측 가능하고, 업데이트는 반복 가능하며, “내 컴퓨터에서는 잘 작동하는데”라는 문제가 사라집니다.
대규모 프로덕션 환경을 위해 구축된 생태계
'중국식 속도'로 나아가기 위해서는 훌륭한 툴체인뿐만 아니라, 수개월에 걸친 초기 구축 노력을 없애주는 사전 검증된 통합 생태계가 필요합니다. 맞춤형 글루 코드와 불안정한 워크플로우를 피하기 위해, IAR은 팀이 검증된 기반 위에서 시작할 수 있도록 파트너 생태계를 구축했습니다:
이 마지막 요점은 겉보이는 것보다 훨씬 중요합니다. 컨테이너화는 종종 전담 플랫폼 팀을 보유한 대규모 조직만의 문제로 여겨지곤 합니다. 하지만 그렇지 않습니다. 소규모 팀에서는 한 개발자의 컴퓨터가 어느새 사실상 빌드 서버 역할을 맡는 경우가 흔합니다. 그 사람이 자리를 비우면 빌드 작업이 중단됩니다. 컨테이너화는 이러한 단일 장애 지점을 제거하고, 온보딩 과정을 간소화하며, 성장에 따라 인프라를 재구축할 필요 없이 팀이 규모를 확장할 수 있도록 지원합니다. 투자 비용은 적지만, 위험 감소 효과는 결코 작지 않습니다.
장기 지원이 공급업체의 결정이 아닌 안전 문제인 이유
자동차 소프트웨어의 수명 주기는 다른 어떤 산업과도 비교할 수 없을 정도로 독특합니다. 전기차는 구매자의 직장 생활 대부분을 함께할 수 있도록 설계됩니다. 기능 추가, 결함 수정, 보안 취약점 해결은 양산 개시(SOP) 후 20년에서 25년이 지난 시점에도 이루어져야 할 수 있습니다. 이 전체 기간 동안 팀은 소프트웨어를 재구축하고, OTA 업데이트를 배포하며, 규제 당국이 인정할 수 있는 규정 준수 증빙 자료를 마련해야 합니다.
이를 위해서는 20년 후에도 여전히 존재하며, 지원을 받고, 인증된 유지보수 릴리스를 배포할 수 있는 툴체인 공급업체가 필요합니다. 장기 지원은 단순한 운영상의 세부 사항이 아니라, 소프트웨어 정의 차량에서 기능적 안전성을 유지하기 위한 토대입니다. 이것이 없다면, 출시 후 첫 몇 년이 지난 후 이루어지는 모든 툴 업데이트는 기존 안전 증거의 유효성을 상실하게 하고, 막대한 비용이 드는 재인증 절차를 강요할 위험이 있습니다.
IAR은 1983년부터 사업을 운영해 왔습니다. 자동차 소프트웨어의 수명이 대부분의 기술 기업보다 길기 때문에, 장기 보증 서비스, 유지보수 릴리스, 인증된 서비스 팩, 안정적인 라이선싱이 플랫폼 모델에 정교하게 통합되어 있습니다. 이는 조달 시 반드시 고려해야 할 사항입니다. 툴체인 결정은 팀이 프로그램의 전체 수명 주기 동안 함께해야 할 선택이며, 자동차 업계에서는 종종 이를 개발한 엔지니어들의 경력보다 더 오래 지속되는 것을 의미하기 때문입니다.
오늘 자신감을 가지고 개발을 시작하고, 앞으로 펼쳐질 긴 여정 동안 그 예측 가능성을 유지하십시오.
예기치 못한 상황을 줄이고, 중요한 일을 개발하는 데 더 많은 시간을 할애하세요
‘1억 라인의 함정’은 실재하지만, 피할 수 없는 것은 아닙니다. 아키텍처를 재검토하고, 워크플로를 현대화하며, 진정한 장기 지원이 제공되는 안전 인증 플랫폼에 개발을 기반을 둔 팀이라면 이 함정에서 벗어날 수 있습니다.
실제 적용 사례: ASIL D 등급까지 사전 인증된 솔루션을 활용하면 첫 번째 스프린트부터 인증 작업량과 위험을 줄일 수 있습니다. 현대적인 워크플로우와 컨테이너를 통해 팀은 코드 품질을 저하시키지 않으면서도 더 빠르게 진행할 수 있습니다. 이 플랫폼은 문제를 조기에 파악하여, 가장 예측 불가능한 비용을 초래하는 리콜 및 개발 후기 단계의 수정 작업을 최소화합니다. 광범위한 AUTOSAR 및 MCAL 지원, 심층적인 MCU/MPU 지원 범위, 강력한 타사 생태계와 결합되어, 팀은 각 아키텍처, 공급업체, 차량 도메인마다 동일한 소프트웨어를 재작성할 필요 없이 유연하게 개발할 수 있습니다.
부담은 줄이고, 예상치 못한 문제는 최소화하며, 현대 자동차 소프트웨어가 요구하는 속도에 맞춰 브랜드를 정의하는 기능을 제공하는 데 더 많은 시간을 할애할 수 있습니다. 이것이 바로 IAR 플랫폼입니다.
다음 단계는 무엇일까요?
온디맨드 웨비나 ”'100M 라인의 덫에서 벗어나기: 레거시 사일로에서 애자일 소프트웨어 정의 차량으로'”를 시청하여, 컨테이너화된 빌드가 안전이 중요한 임베디드 개발에서 “내 컴퓨터에서는 잘 돌아가는데”라는 문제를 어떻게 해결하는지 등 실용적인 데모를 확인해 보세요.
또는 대화형 데모를 통해 IAR 플랫폼이 안전 인증 컴파일러 및 코드 분석, 고급 디버깅, 최신 CI/CD를 활용하여 ISO 26262 규정 준수 위험을 어떻게 줄여주는지 확인해 보세요.
