자동차 소프트웨어 CI/CD — 웹 개발과는 다른 이야기

자동차 소프트웨어에도 CI/CD가 필요한가?

자동차 소프트웨어 개발에 CI/CD를 적용하려고 하면, 일반 웹/앱 개발과는 다른 문제들을 만나게 됩니다. 웹 서비스라면 코드 커밋하고 테스트 돌리고 배포하면 끝이지만, 자동차 소프트웨어는 그렇게 단순하지 않습니다.

그래도 CI/CD는 이제 선택이 아닙니다. 차량 한 대에 들어가는 소프트웨어가 수억 줄에 달하고, ECU 수십 개가 동시에 개발되는 상황에서 수동 빌드와 수동 테스트로는 일정을 맞출 수 없습니다. 특히 SDV(Software-Defined Vehicle) 시대로 접어들면서 OTA 업데이트, 기능 추가, 보안 패치가 양산 이후에도 계속 이루어져야 하기 때문에, 자동화된 파이프라인 없이는 지속적인 소프트웨어 운영 자체가 불가능합니다.

이 글에서는 자동차 소프트웨어 개발에 CI/CD를 적용할 때 실제로 부딪히는 문제들과, 그 문제들을 어떻게 풀어가고 있는지를 이야기합니다.

웹 CI/CD와 무엇이 다른가

자동차 소프트웨어 CI/CD를 처음 구축하려는 팀이 가장 많이 하는 실수가 있습니다. 웹 개발에서 쓰던 Jenkins 파이프라인을 그대로 가져와서 적용하려는 것입니다. 물론 기본 개념은 같습니다. 코드 변경 → 빌드 → 테스트 → 배포. 하지만 각 단계의 복잡도가 완전히 다릅니다.

크로스 컴파일과 타겟 다양성

웹 서비스는 보통 x86 리눅스 서버에 배포합니다. 자동차는 다릅니다. ARM 기반 ECU, 다양한 RTOS, 하이퍼바이저 위에서 돌아가는 소프트웨어를 크로스 컴파일해야 합니다. 타겟 보드마다 빌드 설정이 다르고, BSP(Board Support Package)도 다릅니다. CI 서버에서 이 모든 조합을 관리하는 것만으로도 상당한 인프라가 필요합니다.

테스트 환경의 차이

웹 서비스 테스트는 Docker 컨테이너 하나 띄우면 됩니다. 자동차 소프트웨어는 실제 ECU 없이는 테스트가 어렵고, 실제 ECU가 있어도 물리적인 연결과 네트워크 구성이 필요합니다. HIL(Hardware-in-the-Loop) 장비는 비싸고, 공유 자원이라 CI 파이프라인에서 자유롭게 쓸 수 없습니다.

그래서 Virtual ECU(가상 ECU) 기반의 SIL(Software-in-the-Loop) 테스트가 중요해지고 있습니다. CI 파이프라인에서 가상 ECU를 자동으로 생성하고 테스트를 병렬 실행하면, HIL 장비 없이도 상당 수준의 검증이 가능합니다.

빌드 시간

웹 프론트엔드 빌드가 2-3분이라면, AUTOSAR 기반 ECU 소프트웨어 풀빌드는 30분에서 1시간 이상 걸리는 경우가 흔합니다. CI에서 매 커밋마다 풀빌드를 돌리면 파이프라인이 병목이 됩니다. 인크리멘탈 빌드, 캐싱 전략, 변경 영향도 분석 기반의 선택적 빌드가 필수입니다.

개발 환경 관리라는 숨은 난제

자동차 소프트웨어 CI/CD에서 의외로 많은 시간을 잡아먹는 것이 개발 환경 관리입니다.

툴체인 버전 동기화

프로젝트 하나에 컴파일러, AUTOSAR 스택, 코드 생성기, 정적 분석 도구, 테스트 프레임워크 등 수십 가지 도구가 필요합니다. 이 도구들의 버전이 개발자 PC, CI 서버, 팀원 간에 다르면 "내 PC에서는 빌드가 되는데" 문제가 반복됩니다.

특히 보안 패치나 도구 업그레이드를 동기화하는 것이 큰 과제입니다. 한 팀이 컴파일러를 업그레이드하면 다른 팀의 코드가 깨지고, 보안 취약점이 발견되어 급히 패치해야 할 때 모든 개발 환경을 일괄적으로 업데이트하기가 어렵습니다.

신규 개발자 온보딩

새로운 팀원이 합류하면 개발 환경 세팅에 며칠이 걸리는 일이 흔합니다. AUTOSAR 도구 설치, 라이선스 설정, 빌드 환경 구성, 타겟 보드 연결까지. 문서가 있어도 OS 버전이나 라이브러리 충돌 때문에 시행착오가 반복됩니다.

Docker 컨테이너 기반으로 개발 환경을 표준화하면 이 문제를 크게 줄일 수 있습니다. 개발 환경 전체를 컨테이너 이미지로 관리하면, 신규 팀원이 이미지만 받아서 바로 개발을 시작할 수 있고, CI 서버와 동일한 환경에서 로컬 개발이 가능합니다.

안전 인증과 CI/CD

자동차 소프트웨어 CI/CD에서 가장 까다로운 부분이 안전 인증과의 관계입니다.

ISO 26262 도구 적격성

ISO 26262는 안전 라이프사이클에 사용되는 모든 도구에 대해 도구 적격성(Tool Qualification)을 요구합니다. CI/CD 파이프라인에서 사용하는 빌드 도구, 정적 분석 도구, 테스트 프레임워크도 예외가 아닙니다. 도구가 안전 관련 출력을 만들어낸다면, 그 도구가 올바르게 동작한다는 증거가 있어야 합니다.

이것은 단순히 도구를 검증하라는 이야기가 아닙니다. CI/CD 도구 자체가 적격성 평가 대상이 될 수 있고, 파이프라인 구성이 변경될 때마다 영향도 분석이 필요할 수 있습니다. 그래서 안전 관련 프로젝트에서는 CI/CD 파이프라인의 변경 관리가 소프트웨어 변경 관리만큼 중요합니다.

정적 분석의 자동화

MISRA C/C++ 준수는 자동차 소프트웨어에서 사실상 필수입니다. CI/CD 파이프라인에 정적 분석을 통합하면, 코드가 커밋될 때마다 MISRA 규칙 위반을 자동으로 검출할 수 있습니다. 이렇게 하면 코드 리뷰에서 스타일 문제를 일일이 잡는 대신, 리뷰어가 로직과 설계에 집중할 수 있습니다.

다만 정적 분석 도구의 실행 시간이 길 수 있으므로, 변경된 파일만 분석하는 인크리멘탈 분석과 전체 코드를 분석하는 풀 분석을 나눠서 운영하는 전략이 실무적입니다. 커밋 시에는 인크리멘탈 분석을, 야간 빌드에서는 풀 분석을 실행하는 방식입니다.

인증 프로세스의 병목

안전 관련 시스템은 광범위한 검증이 필요합니다. 자동화 없이 이 검증을 수행하면, 인증 과정 자체가 프로젝트의 병목이 됩니다. 테스트 실행, 결과 수집, 리포트 생성, 추적성 매트릭스 업데이트를 수동으로 하면 릴리스마다 몇 주가 걸립니다.

CI/CD 파이프라인에 검증 자동화를 통합하면, 매 빌드마다 테스트 결과와 커버리지 리포트가 자동으로 생성되어 인증에 필요한 증적이 축적됩니다. 릴리스 시점에 "그때 돌린 테스트 결과가 어디 있지?"가 아니라, 모든 빌드의 검증 이력이 이미 기록되어 있는 상태가 됩니다.

ASPICE 4.0과 DevOps

2023년 11월에 출시된 ASPICE 4.0은 자동차 소프트웨어 개발 방법론에 큰 변화를 가져왔습니다. 기존 ASPICE는 V모델 기반의 순차적 개발 프로세스를 전제로 했지만, ASPICE 4.0은 Agile과 DevOps 방법론을 명시적으로 포함하도록 범위가 확장되었습니다.

이것은 단순한 문서 업데이트가 아닙니다. OEM 심사에서 "Agile로 개발했는데 ASPICE 평가를 어떻게 받지?"라는 고민이 있었던 팀들에게, ASPICE 4.0은 DevOps 기반 개발이 ASPICE와 양립 가능하다는 공식적인 근거를 제공합니다.

다만 이것은 "CI/CD만 구축하면 ASPICE 4.0 대응 끝"이라는 뜻이 아닙니다. ASPICE가 요구하는 것은 프로세스의 체계적 수행과 그 증거입니다. CI/CD는 이 증거를 자동으로 생성하고 관리하는 도구이지, 프로세스 자체를 대체하는 것은 아닙니다.

중앙집중형 HPC 아키텍처와 CI/CD

최근 자동차 E/E 아키텍처가 분산형 ECU 구조에서 중앙집중형 HPC(High-Performance Computer) 구조로 전환되고 있습니다. 수십 개의 ECU가 담당하던 기능을 몇 개의 고성능 컴퓨터로 통합하는 것입니다.

이 변화는 CI/CD에도 직접적인 영향을 미칩니다. HPC 하나에서 돌아가는 소프트웨어의 규모가 커지면서, 빌드와 테스트의 복잡도가 비례하여 증가합니다. 여러 도메인(ADAS, 인포테인먼트, 바디 컨트롤)의 소프트웨어가 하나의 플랫폼 위에서 통합되어야 하므로, 통합 테스트의 중요성이 더 커지고 있습니다.

주요 클라우드/IT 기업들이 SDV DevOps 툴체인 레퍼런스 아키텍처를 제공하기 시작한 것도, 이런 변화에 대응하기 위한 업계 움직임의 하나입니다. 자동차 소프트웨어 개발에 특화된 CI/CD 인프라에 대한 수요가 그만큼 커지고 있다는 의미입니다.

실무에서 CI/CD를 시작하려면

자동차 소프트웨어 CI/CD는 한 번에 완벽하게 구축하기 어렵습니다. 단계적으로 접근하는 것이 현실적입니다.

1단계: 빌드 자동화

수동 빌드를 자동화하는 것부터 시작합니다. 코드가 커밋되면 자동으로 빌드가 돌아가고, 빌드 실패 시 담당자에게 알림이 가는 것만으로도 큰 개선입니다.

2단계: 정적 분석 통합

MISRA C/C++ 정적 분석을 CI 파이프라인에 추가합니다. 커밋마다 인크리멘탈 분석, 야간 풀 분석으로 나눠서 운영하면 실행 시간 부담을 줄일 수 있습니다.

3단계: 테스트 자동화

단위 테스트부터 CI에 통합하고, 점차 통합 테스트, SIL 테스트로 확장합니다. Virtual ECU를 활용하면 HIL 장비 없이도 상당 수준의 자동화가 가능합니다.

4단계: 컨테이너 기반 환경 표준화

개발 환경을 Docker 컨테이너로 표준화하여, 로컬 개발과 CI 환경의 일관성을 확보합니다.

5단계: 인증 증적 자동화

테스트 결과, 커버리지 리포트, 추적성 매트릭스를 자동 생성하여 ASPICE/ISO 26262 인증 대응을 자동화합니다.

PopcornSAR의 CI/CD 솔루션

PopcornSAR는 자동차 소프트웨어 개발에 특화된 CI/CD 도구와 솔루션을 제공합니다.

PACON IDE는 Docker 컨테이너 기반의 개발 환경으로, Jenkins CI/CD와 통합됩니다. 개발 환경 전체가 컨테이너로 관리되므로 팀 전체의 환경 일관성이 보장되고, 신규 개발자 온보딩이 빨라집니다. CI/CD 파이프라인에서 Virtual ECU를 자동 생성하여 복수의 가상 ECU에서 병렬 테스트를 실행할 수 있어, HIL 장비 의존도를 줄이면서도 검증 범위를 넓힐 수 있습니다. 자세한 내용은 PACON IDE 제품 페이지에서 확인하실 수 있습니다.

PARVIS는 AI 기반 자동화로 CI/CD 파이프라인의 각 단계를 강화합니다. PARVIS-Coder는 MISRA C/C++ 준수를 자동화하여 CI의 정적 분석 단계에 통합됩니다. PARVIS-Verify는 테스트 케이스를 자동 생성하여 CI/CD 테스트 단계에 투입합니다. 요구사항이 변경되면 영향받는 테스트를 자동으로 식별하고 업데이트합니다. PARVIS 제품 페이지에서 더 알아보실 수 있습니다.

AutoSAR.io는 ARXML 설정 파일의 형상 관리를 지원하여, CI/CD 워크플로우에서 AUTOSAR 구성 변경을 체계적으로 관리할 수 있게 합니다.

자동차 소프트웨어 CI/CD 구축에 대해 더 궁금하신 점이 있다면, 문의 페이지를 통해 편하게 연락해 주세요.