자동차 SW 개발팀에게 ASPICE 심사는 매년 돌아오는 무거운 과제입니다. 테스트 결과, 빌드 이력, 변경 요청 기록, 형상 관리 로그 등 심사관에게 제시해야 할 산출물을 수작업으로 취합하다 보면 정작 개발보다 ‘증적 만들기’에 더 많은 시간을 쓰게 됩니다. CloudBees CD/RO(Continuous Delivery/Release Orchestration)는 이러한 반복 업무를 파이프라인 자동화로 줄여주는 솔루션입니다. 이번 콘텐츠에서는 ASPICE 핵심 프로세스와 CloudBees CD/RO 기능이 어떻게 맞닿는지 그리고 도구가 해결하지 못하는 영역은 무엇인지 함께 살펴봅니다.
*본 글은 ASPICE v3.1 ↔ v4.0 동시 대응 관점으로 작성됐습니다.
🗂️ASPICE(Automotive SPICE®)란?
ASPICE는 자동차 SW·시스템 개발 프로세스의 역량을 평가하는 모델입니다. VDA QMC가 발행하며, 글로벌 OEM과 Tier 공급망에서 사실상 표준처럼 활용되고 있습니다.
ASPICE의 Capability Level은 0부터 5까지 구분됩니다. Level 1은 프로세스가 수행되어 산출물이 나오는 상태, Level 2는 산출물이 계획·통제·검토되어 관리되는 상태, Level 3은 조직 표준 프로세스가 정의되고 일관되게 배포된 상태를 의미합니다. 한국 Tier1·Tier2 기업 입장에서 현실적인 1차 목표는 대체로 CL2입니다. CL3는 글로벌 수출이나 안전 SW 사업 확장을 위한 다음 단계로 볼 수 있습니다.
ASPICE 심사의 핵심은 단순합니다. 프로세스를 알고 있느냐가 아니라 해당 프로세스가 실제로 수행되었고, 그 증거를 일관되게 보여줄 수 있느냐가 중요합니다. v4.0에서는 Machine Learning Engineering, Hardware Engineering, ML Data Management 등이 추가되었고, SWE.6도 기존 Software Qualification Test에서 Software Verification 관점으로 변경되었습니다.
이처럼 평가 범위와 용어는 달라졌지만 심사에서 확인하는 핵심은 변하지 않았습니다. 정해진 프로세스가 실제로 수행되었는지, 그리고 그 과정을 신뢰할 수 있는 증거로 보여줄 수 있는지가 중요합니다.
🗂️ASPICE 심사, 무엇이 그렇게 힘들까요?
기술적으로는 이미 ASPICE에 맞춰 일하고 있는 팀도 많습니다. 문제는 그것을 증명하는 데 드는 비용입니다. 심사 직전에는 테스트 결과, 빌드 이력, 코드 리뷰, 변경 이력을 각 시스템에서 수동으로 취합해야 합니다. 이 과정은 개발 생산성을 떨어뜨리고, 데이터 누락이나 버전 불일치로 이어질 수 있습니다. 릴리즈 추적성도 자주 지적되는 영역입니다. 이 빌드가 어떤 변경 요청에서 시작됐는지, 누가 승인했는지, 어떤 테스트를 통과했는지를 한 번에 보여주기 어렵기 때문입니다.
또한 Tier1 기업은 여러 OEM 프로젝트를 동시에 운영하는 경우가 많습니다. OEM마다 ASPICE 버전, 심사 주기, 요구 Level이 다르기 때문에 프로젝트별 증적을 분리해 관리하는 것 자체가 큰 부담이 됩니다. 여기에 v3.1과 v4.0이 함께 운영되는 상황까지 더해집니다. 기존 프로젝트는 v3.1로, 신규 프로젝트는 v4.0으로 진행되는 식입니다. 같은 조직 안에서 두 모델을 동시에 관리해야 하므로 실무 혼선이 발생할 수밖에 없습니다.
마지막으로 중요한 문제는 기록의 진위입니다. 산출물 자체는 ALM이나 문서로 존재할 수 있지만, 그 기록이 실제 시스템에서 조작 없이 수행된 결과인지 증명하는 것은 또 다른 영역입니다.
🗂️CloudBees CD/RO가 해결하는 것
CloudBees CD/RO는 모델 기반 릴리즈 오케스트레이션 플랫폼입니다. 단순히 스크립트를 실행하는 것이 아니라 환경·애플리케이션·파이프라인을 객체화해 관리합니다. 이 구조는 ASPICE가 요구하는 표준 프로세스의 일관 배포와 잘 맞습니다.
① 파이프라인 템플릿
파이프라인 템플릿을 통해 조직 표준 릴리즈 절차를 정의하고 프로젝트별로 상속해 사용할 수 있습니다. 이를 통해 “표준이 정의되어 있다”는 PA 3.1 관점과 “표준이 일관되게 배포됐다”는 PA 3.2 관점을 뒷받침할 수 있습니다.
② Entry/Exit Gates
Entry/Exit Gate를 통해 단계별 승인 통제를 자동화할 수 있습니다. 파이프라인 각 단계의 진입과 종료 시점에 수동 승인, 조건식 승인, 복합 승인 게이트를 둘 수 있고, “누가, 언제, 어떤 근거로 승인했는가”가 자동으로 기록됩니다.
③ Audit Reports
Audit Report를 통해 심사 증적을 자동으로 확보할 수 있습니다. Approvals Audit, Time Duration, Evidence Audit, Deployments, Related Builds 등은 승인 이력, 단계별 소요 시간, 증적 데이터, 배포 이력, 빌드 연관 관계를 확인하는 데 활용됩니다.
④ CI 도구와의 통합
Jenkins, GitLab, QAC, CodeSonar, SonarQube, Jira 등과 연동해 SWE.5와 SWE.6 실행 결과를 파이프라인 안에서 캡처할 수 있습니다.
정리하면 CloudBees CD/RO는 ASPICE의 모든 영역을 대신하는 도구는 아니지만, 실행 이력과 증적을 자동화하는 영역에서는 강점을 가집니다.
🗂️ASPICE 관점에서 CloudBees CD/RO를 어떻게 활용할 수 있을까?
CloudBees CD/RO는 특히 다음 영역에서 ASPICE 대응에 도움을 줄 수 있습니다.
| ASPICE 프로세스 |
CloudBees CD/RO 활용 |
| SWE.5 SW 통합 테스트 |
CI 통합으로 테스트 실행 및 결과 자동 기록 |
| SWE.6 SW 검증 |
자동화 테스트 실행, 결과 캡처, 추적성 연결 |
| SUP.8 형상 관리 |
빌드·릴리즈 식별, 버전, 배포 이력 기록 |
| SUP.10 변경 요청 관리 |
승인 이력과 변경 실행 추적성 확보 |
| MAN.3 프로젝트 관리 |
마일스톤과 게이트 통과 이력으로 진척도 확인 |
| PA 1.1 / PA 2.2 / PA 3.2 |
파이프라인 실행 자체를 디지털 증적으로 활용 |
예를 들어 심사관이 “이 변경은 언제 승인됐는가”, “이 빌드는 어떤 테스트를 통과했는가”, “어떤 버전이 어느 환경에 배포됐는가”를 물었을 때, CloudBees CD/RO의 실행 기록과 감사 리포트가 중요한 증적이 될 수 있습니다. 특히 PA 2.1 중 실행 모니터링과 통제에 해당하는 영역은 CloudBees CD/RO의 자동화 이력으로 뒷받침할 수 있습니다. 다만 PA 2.1의 계획 수립 영역은 별도 문서와 의사결정 기록이 필요합니다.
🗂️도구가 해결하지 못하는 것
여기서 분명히 짚어야 할 점이 있습니다. CloudBees CD/RO를 도입한다고 해서 ASPICE CL3가 자동으로 달성되는 것은 아닙니다. PA 3.1의 표준 프로세스 정의, SOP·QMS 문서, 역할과 책임, 입출력 정의, 측정 항목은 조직이 직접 정리해야 합니다. CloudBees CD/RO는 정의된 표준이 실제 프로젝트에 배포되고 실행되었는지를 증명하는 데 강점이 있습니다.
PA 2.1의 계획 수립 영역도 마찬가지입니다. Process Performance Strategy, Performance Plan, 자원·역량·인터페이스 식별은 계획 문서와 회의록의 영역입니다. CloudBees CD/RO는 실행 이후의 일정, 실적, 승인, 통제 데이터를 자동으로 남기는 역할에 가깝습니다. 또한 SWE.1~SWE.3에 해당하는 요구사항 분석, 아키텍처 설계, 상세 설계의 품질은 도구가 대신할 수 없습니다. 테스트 전략 수립, 리뷰 회의록, 결정 근거, 요구사항과 코드·테스트 간 양방향 추적성 역시 ALM과 사람의 역할이 필요합니다.
즉, CloudBees CD/RO는 ASPICE 대응을 빠르고 체계적으로 만들어주는 도구이지만, 프로세스 자체를 설계하거나 엔지니어링 판단을 대신하는 도구는 아닙니다.
🗂️CloudBees는 Jenkins, GitLab CI와 무엇이 다른가?
Jenkins나 GitLab CI로도 빌드와 테스트 자동화는 가능합니다. 하지만 ASPICE 심사에서 필요한 것은 단순한 CI 실행 여부가 아니라, 릴리즈 과정 전체가 감사 가능한 형태로 관리되고 있는지입니다. CloudBees CD/RO의 차별점은 릴리즈 단계의 다단계 오케스트레이션, 표준화된 감사 리포트, Entry/Exit Gate 기반 승인 통제, ALM과의 오케스트레이션에 있습니다. CI 단계는 여러 도구로 구현할 수 있습니다. 그러나 심사관이 확인하고자 하는 승인, 변경, 테스트, 배포 이력을 한 흐름으로 정리하고 즉시 제시할 수 있다는 점이 CloudBees CD/RO의 핵심 가치입니다.
ASPICE 심사 준비의 본질은 프로세스 정의의 일관성, 산출물의 추적성, 활동 증적의 객관성입니다.
CloudBees CD/RO는 이 중 추적성과 증적의 객관성을 자동화로 확보하는 데 강점을 가집니다. PA 1.1, PA 2.1의 실행 모니터링 영역, PA 2.2, PA 3.2의 증적 신뢰도를 높이고, 심사 준비에 투입되는 시간과 인력 부담을 줄여줍니다. 다만 PA 2.1의 계획 영역, PA 3.1의 표준 정의, 요구공학·아키텍처·테스트 전략은 여전히 사람과 조직의 영역입니다.
그리고 CloudBees CD/RO는 홀로 완성되는 도구가 아닙니다. 요구사항부터 테스트 설계까지의 엔지니어링 의도를 담는 ALM이 함께 있어야, “말한 대로 실행했다”는 무결성을 증명할 수 있습니다.
다음 2편 콘텐츠에서는 ALM과 CloudBees CD/RO의 역할을 나누어 살펴보고, 요구사항부터 실행 증거까지 ASPICE 심사 대응 흐름을 어떻게 완성할 수 있는지 정리해보겠습니다.
