ASPICE란? — 자동차 소프트웨어 품질의 기준

ASPICE가 뭔가요?

ASPICE(Automotive SPICE)는 자동차 소프트웨어 개발 프로세스의 성숙도를 평가하는 국제 표준 프레임워크입니다. 쉽게 말하면, "이 회사가 소프트웨어를 체계적으로 개발하고 있는가"를 측정하는 기준입니다.

원래는 일반 소프트웨어 프로세스 평가 모델인 ISO/IEC 330xx(SPICE)를 자동차 산업에 맞게 특화한 것입니다. 독일 VDA(자동차산업협회)가 주도하여 만들었고, 현재 유럽과 아시아의 주요 OEM(완성차 업체)이 부품 공급사에 ASPICE 인증을 요구하고 있습니다.

왜 OEM이 ASPICE를 요구할까?

자동차 한 대에 들어가는 ECU(전자제어장치)는 수십 개에서 많게는 100개가 넘습니다. 각 ECU에는 소프트웨어가 탑재되고, 이 소프트웨어의 품질이 차량 안전과 직결됩니다.

OEM 입장에서는 수많은 Tier1(부품 공급사)이 납품하는 소프트웨어의 품질을 일일이 검증하기 어렵습니다. 그래서 "개발 프로세스 자체의 품질"을 평가하는 방식을 택합니다. 프로세스가 체계적이면 결과물도 체계적일 가능성이 높다는 논리입니다.

현재 글로벌 주요 OEM은 Tier1에게 최소 ASPICE CL2(관리 수준) 이상을 요구하며, 안전 관련 소프트웨어에는 CL3(확립 수준)을 요구하는 추세입니다.

역량 수준 (Capability Level)

ASPICE는 프로세스의 성숙도를 6단계로 나눕니다.

CL0 — 불완전: 프로세스가 구현되지 않았거나 목적을 달성하지 못하는 상태.

CL1 — 수행: 프로세스가 목적을 달성하긴 하지만 체계적으로 관리되지 않는 상태. 결과물은 나오지만 "왜 이렇게 했는지", "다음에도 같은 품질이 나올 수 있는지"를 보장하기 어렵습니다.

CL2 — 관리: 프로세스가 계획되고 추적됩니다. 산출물이 정의되어 있고, 요구사항과의 추적성이 확보됩니다. 대부분의 OEM이 최소 요구하는 수준입니다.

CL3 — 확립: 조직 전체에 표준 프로세스가 정의되고, 프로젝트마다 이를 맞춤 적용합니다. 프로세스 개선이 체계적으로 이루어집니다. 안전 관련 SW에 요구되는 수준입니다.

CL4 — 예측 가능: 프로세스 성과를 정량적으로 측정하고 예측할 수 있습니다.

CL5 — 혁신: 지속적인 프로세스 혁신이 이루어집니다.

실무에서는 CL2~CL3이 핵심입니다. CL4 이상은 이론적으로는 정의되어 있지만, 실제로 요구되는 경우는 드뭅니다.

핵심 프로세스 영역

ASPICE에서 자동차 소프트웨어 개발과 가장 직결되는 프로세스 영역은 소프트웨어 엔지니어링(SWE) 그룹입니다.

• SWE.1 — 소프트웨어 요구사항 분석: 시스템 요구사항에서 소프트웨어 요구사항을 도출하고 분석합니다.
• SWE.2 — 소프트웨어 아키텍처 설계: 소프트웨어 구조를 설계하고 컴포넌트 간 인터페이스를 정의합니다.
• SWE.3 — 소프트웨어 상세 설계 및 구현: 상세 설계에 따라 코드를 작성합니다.
• SWE.4 — 소프트웨어 단위 검증: 단위 테스트를 통해 개별 모듈을 검증합니다.
• SWE.5 — 소프트웨어 통합 및 통합 테스트: 모듈을 통합하고 인터페이스를 검증합니다.
• SWE.6 — 소프트웨어 자격 테스트: 소프트웨어 요구사항 대비 최종 검증을 수행합니다.

이 6개 프로세스가 V-Model의 왼쪽(개발)과 오른쪽(검증)을 구성합니다. 요구사항에서 시작해서 설계, 구현을 거쳐 단위-통합-자격 테스트로 이어지는 흐름입니다.

ASPICE 4.0에서 달라진 것

2023년 11월, ASPICE 4.0이 공식 출시되었습니다.

가장 눈에 띄는 변화는 머신러닝 프로세스(MLE.1~MLE.4)가 새로 생긴 것입니다. AI/ML 기반 소프트웨어 개발에 대한 프로세스가 처음으로 정의되었고, 데이터 관리부터 모델 학습, 검증까지 포함됩니다. 하드웨어 엔지니어링 프로세스(HWE.1~HWE.4)도 추가되어 메카트로닉 시스템 전체를 다룰 수 있게 되었습니다.

그 외에도 Agile/DevOps 방법론을 공식적으로 수용했고, ISO/SAE 21434와 정렬하여 사이버보안 요구사항을 강화했습니다. 용어도 바뀌어서 기존의 "작업 제품(Work Product)" 대신 "정보 항목(Information Item)"이라는 개념을 사용합니다.

ASPICE 대응, 어떻게 시작해야 할까?

처음 ASPICE를 준비하는 조직이라면, 먼저 현재 개발 프로세스의 갭 분석(Gap Analysis)부터 시작해야 합니다. 현재 수준이 CL0인지 CL1인지를 파악하고, 목표 수준(보통 CL2)까지 어떤 프로세스와 산출물이 필요한지를 정의합니다.

가장 시간이 많이 걸리는 부분은 검증 단계(SWE.4~SWE.6)입니다. 테스트케이스 작성, 추적성 매트릭스 구축, 커버리지 리포트 생성이 수작업으로 이루어지면 엄청난 공수가 들어갑니다. 이 부분을 자동화하면 ASPICE 대응 시간을 크게 줄일 수 있습니다.

PopcornSAR의 PARVIS가 이 영역을 다루고 있습니다. 요구사항을 분석하고(PARVIS-Spec), 코딩 규칙을 자동 적용하고(PARVIS-Coder), 테스트케이스를 자동으로 만들어줍니다(PARVIS-Verify). 실제 프로젝트에서 수작업보다 3~4배 빠르게 산출물을 만들 수 있었고, ASPICE 컨설팅이나 교육이 필요한 경우에도 지원하고 있습니다.

PARVIS 제품 페이지에서 자세한 내용을 확인하실 수 있고, 궁금한 점이 있으시면 편하게 문의해 주세요.