자동차 SW 개발자가 알아야 할 ASPICE란? 개발 프로세스부터 SWE.1~SWE.6까지

자동차 소프트웨어 개발을 하다 보면 한 번쯤 다음과 같은 말을 듣게 된다.

 

"이번 프로젝트는 ASPICE Level 2 대응이 필요하다."

"SWE.1 Requirement부터 다시 확인해 주세요."

"SWE.2 Architecture와 SWE.3 Design의 Traceability가 연결되어 있나요?"

"SWE.4 Unit Test 결과가 필요합니다."

"ASPICE Assessment에서 Evidence를 준비해야 합니다."

 

자동차 SW 개발을 처음 접하는 입장에서는 이런 용어들이 상당히 복잡하게 느껴진다.

 

특히 ASPICE를 처음 접하면 ASPICE를 하나의 개발 방법론이나 인증 규격이라고 생각하기 쉽다.

하지만 정확하게는 자동차 시스템 및 소프트웨어 개발 프로세스의 능력을 평가하기 위한 Process Assessment Model이다.

 

즉, ASPICE는 단순히 소프트웨어가 정상적으로 동작하는지만 확인하는 것이 아니다.

소프트웨어를 개발하면서 요구사항을 어떻게 정의했는지, 설계를 어떻게 했는지, 구현은 어떻게 했는지, 테스트를 어떻게 수행했는지, 그리고 각각의 결과가 서로 추적 가능한지를 체계적으로 확인한다.

 

이 글에서는 자동차 SW 개발자가 실무에서 가장 많이 접하게 되는 ASPICE의 개념과 개발 프로세스, SWE.1~SWE.6의 관계, Capability Level, Traceability까지 하나의 흐름으로 정리한다.

 

ASPICE란 무엇인가?

 

ASPICE는 Automotive SPICE의 약자이다.

 

SPICE는 Software Process Improvement and Capability dEtermination을 의미하며, Automotive SPICE는 자동차 산업의 시스템 및 소프트웨어 개발 프로세스를 평가하는 데 사용되는 모델이다.

 

현재 기준으로 많이 사용되는 공식 문서는 Automotive SPICE Process Reference Model / Process Assessment Model Version 4.0이다. VDA QMC Working Group 13에서 작성되었으며 2023년 11월 29일 Release되었다.

 

여기서 중요한 부분은 ASPICE가 "좋은 소프트웨어를 만드는 방법" 자체를 정의하는 문서가 아니라는 점이다. ASPICE가 중요하게 보는 것은 개발 프로세스가 정의되어 있고, 실제로 수행되며, 그 수행 결과를 객관적으로 확인할 수 있는가이다.

 

그래서 자동차 SW 프로젝트에서 ASPICE를 적용하면 다음과 같은 구조가 만들어진다.

요구사항 → 분석 → 설계 → 구현 → 검증 → 테스트 결과

 

그리고 각각의 결과가 서로 연결되어 있어야 한다.

Requirement → Architecture → Detailed Design → Source Code → Test Case → Test Result

 

이런 연결 관계가 제대로 관리되는지가 ASPICE에서 중요한 부분이다.

 

결국 ASPICE를 가장 간단하게 표현하면 다음과 같다.

"소프트웨어를 제대로 개발하고 있는가?"를 프로세스 관점에서 확인하는 기준

 

이라고 이해하면 된다.

 

ASPICE에서는 무엇을 평가하는가?

ASPICE를 이해할 때 가장 먼저 헷갈리는 부분이 바로 프로세스(Process)이다.

 

ASPICE에는 시스템 개발, 소프트웨어 개발, 하드웨어 개발, 검증, 지원, 관리 등 여러 프로세스가 존재한다.

그 중 자동차 SW 개발자가 가장 자주 접하는 것이 SWE(Software Engineering) 프로세스이다.

 

전체 구조를 아주 단순하게 표현하면 다음과 같다.

                                    Automotive SPICE
                                                 │
             ┌─────────────┴─────────────┐
             │                                                                      │
          SYS                                                                 SWE
System Engineering                                     Software Engineering
             │                                                                      │
System Requirement                                        SW Requirement
             │                                                                      │
System Architecture                                          SW Architecture
                                                                                     │
                                                                          Detailed Design
                                                                                     │
                                                                          Implementation
                                                                                     │
                                                                          Unit Verification
                                                                                     │
                                                                              Integration
                                                                                     │
                                                                       Software Verification

 

여기서 SYS와 SWE의 관계를 이해하는 것이 중요하다.

 

예를 들어 차량에 다음과 같은 기능 요구사항이 있다고 가정해 보자.

차량 속도가 10 km/h 이하이고 특정 조건을 만족하면 Door Lock 기능을 활성화한다.

 

이것은 차량 시스템 관점에서는 System Requirement가 될 수 있다.

 

시스템 개발 과정에서는 이 요구사항을 분석하고 어떤 ECU가 해당 기능을 담당할지, 다른 시스템과 어떻게 연결되는지 등을 정의한다. 그다음 실제 ECU Software에서 해당 기능을 구현하기 위해 Software Requirement를 만들고 Software Architecture를 설계한다.

 

즉,

차량 요구사항
         ↓
System Engineering
        ↓
ECU가 수행해야 할 기능
         ↓
Software Engineering
         ↓
Software Requirement
         ↓
Software Architecture
         ↓
Software Design
         ↓
      Code
         ↓
      Test

 

와 같은 흐름으로 연결된다.

 

따라서 SYS와 SWE를 완전히 별개의 영역으로 보는 것보다는 시스템 요구사항이 소프트웨어 개발로 어떻게 내려오는지를 보는 것이 중요하다.

 

SWE.1부터 SWE.6까지 이해하기

 

자동차 SW 개발자 입장에서 ASPICE를 공부한다면 가장 먼저 익혀야 하는 것이 SWE.1~SWE.6이다.

 

ASPICE 4.0에서는 Software Engineering Process Group (SWE) 영역에 다음과 같은 프로세스가 정의되어 있다.

SWE.1  Software Requirements Analysis
     ↓
SWE.2  Software Architectural Design
     ↓
SWE.3  Software Detailed Design and Unit Construction
     ↓
SWE.4  Software Unit Verification
     ↓
SWE.5  Software Component Verification and Integration Verification
     ↓
SWE.6  Software Verification

 

이것을 단순히 외우기보다는 "무엇을 → 어떻게 → 구현 → 검증"의 흐름으로 이해하는 것이 좋다.

 

SWE.1 — Software Requirements Analysis

 

SWE.1은 Software Requirements Analysis이다.

말 그대로 Software가 어떤 기능을 수행해야 하는지 요구사항을 분석하고 정의하는 단계이다.

 

예를 들어 상위 시스템에서 "차량 속도가 10 km/h 이하일 경우 Door Lock 기능을 활성화한다." 라는 요구사항이 내려왔다고 하자. Software에서는 이것을 실제 구현 가능한 수준으로 구체화해야 한다.

예를 들어,

SW shall monitor vehicle speed.

If vehicle speed is less than or equal to 10 km/h and the required condition is fulfilled, the software shall activate Door Lock.

 

와 같은 형태로 Software Requirement를 정의할 수 있다.

 

여기서 중요한 것은 단순히 문장을 작성하는 것이 아니다.

요구사항이 명확하고, 모호하지 않고, 일관되며, 검증 가능한 형태인지 확인해야 한다.

 

또한 상위 System Requirement와 Software Requirement 사이의 관계도 관리해야 한다.
이 연결이 나중에 Traceability(추적성)의 출발점이 된다.

 

SWE.2 — Software Architectural Design

 

SWE.1에서 Software가 무엇을 해야 하는지 정의했다면 SWE.2에서는 어떤 구조로 Software를 구성할 것인지를 결정한다.

 

예를 들어 Door Lock 기능을 구현한다고 했을 때 하나의 거대한 함수로 전부 구현할 수도 있지만 실제 자동차 SW에서는 기능을 적절한 Component로 분리한다. AUTOSAR 프로젝트라면 이 과정에서 SWC, Port, Interface, Runnable, RTE 등의 Architecture가 함께 정의될 수 있다.

 

따라서 AUTOSAR를 사용하는 프로젝트에서는 AUTOSAR Architecture와 ASPICE SWE.2가 서로 다른 개념이지만 실제 개발 과정에서는 밀접하게 연결된다.

 

SWE.2에서 중요한 것은 단순히 Architecture 그림 하나를 만드는 것이 아니다.

• 어떤 Component가 어떤 역할을 담당하는가?
• Component 사이에는 어떤 Interface가 존재하는가?
• 어떤 데이터를 주고받는가?
• 어떤 Requirement를 어떤 Architecture 요소가 담당하는가?

등을 명확하게 정의해야 한다.

 

SWE.3 — Software Detailed Design and Unit Construction

 

SWE.2에서 Software의 큰 구조를 정의했다면 SWE.3에서는 이를 실제 구현 가능한 수준까지 구체화한다.

 

즉,

SWE.2
"어떤 구조로 만들 것인가?"
     ↓
SWE.3 "
각 기능을 어떻게 구현할 것인가?"

 

라고 생각하면 된다.

 

예를 들어 Architecture에서 DoorLock이라는 Component를 만들었다면 SWE.3에서는 그 Component를 구성하는 Unit과 각 Unit의 동작을 상세하게 정의한다. 실제 Embedded Software에서는 이 단계가 C/C++ Source Code와 연결된다.

void DoorLockControl_Main(void)
{
    if (VehicleSpeed <= 10U)
    {
        DoorLock_Enable();
    }
}

 

물론 실제 프로젝트에서는 훨씬 복잡한 조건과 Interface가 존재하겠지만 개념적으로는 이런 관계이다.

Software Requirement
        ↓
Software Architecture
        ↓
Detailed Design
        ↓
Source Code

 

여기서 중요한 것이 Design과 Code 사이의 추적성이다.

"이 함수가 왜 존재하는가?" 라는 질문을 했을 때 상위 Requirement나 Design으로 거슬러 올라갈 수 있어야 한다.

 

SWE.4 — Software Unit Verification

 

SWE.3에서 Software Unit을 구현했다면 SWE.4에서는 각각의 Unit이 정상적으로 동작하는지를 검증한다.

흔히 Unit Test와 연결해서 이해하면 쉽다. 예를 들어 DoorLockControl()이라는 함수가 있다고 하자.

Input
  ↓
DoorLockControl()
  ↓
Output

 

그리고 다양한 조건을 넣어서 결과를 확인한다.

VehicleSpeed = 0
→ Door Lock Enable

VehicleSpeed = 10
→ Door Lock Enable

VehicleSpeed = 11
→ Door Lock Disable

 

이처럼 정상 조건뿐만 아니라 경계값, 비정상 조건 등을 포함하여 Unit이 요구된 동작을 수행하는지 확인한다.

여기서 중요한 것은 Test Case와 Requirement의 관계이다.

 

예를 들어

SWR-001
차속이 10 km/h 이하일 경우 Door Lock을 활성화한다.
        ↓
UT-001
VehicleSpeed = 10
        ↓
Expected Result
Door Lock = Enable
        ↓
Actual Result
PASS

 

와 같은 관계가 만들어진다.

 

이것이 바로 ASPICE에서 이야기하는 Traceability(추적성)의 대표적인 예이다.

 

SWE.5 — Software Component Verification and Integration Verification

 

SWE.4에서는 개별 Unit을 검증했다.

하지만 각각의 Unit이 정상적으로 동작한다고 해서 Software 전체가 정상적으로 동작한다고 할 수는 없다.

 

예를 들어 다음과 같은 Software가 있다고 해보자.

Speed Manager
      ↓
Door Status Manager
      ↓
Door Lock Manager
      ↓
Output Control

 

각각의 Unit을 독립적으로 테스트했을 때는 모두 PASS했다고 하더라도 실제로 연결하면 데이터 전달이나 Interface 문제로 동작하지 않을 수 있다.

 

따라서 SWE.5에서는 Software Component와 Component 간 Integration을 검증한다.

 

즉,

SWE.4
각각의 Unit은 정상인가?
        ↓
SWE.5
Unit과 Component를 연결해도 정상인가?

 

라는 차이가 있다.

 

AUTOSAR 프로젝트라면 SWC 간 Interface, RTE를 통한 데이터 전달, Component Integration 등의 검증과 연결해서 생각할 수 있다.

 

SWE.6 — Software Verification

 

SWE.6은 Software 전체를 대상으로 검증하는 단계이다.

 

SWE.4와 SWE.5가 비교적 낮은 단계에서 Software를 검증했다면

SWE.6에서는 전체 Software가 Software Requirement를 만족하는지를 확인하는 관점이 중요하다.

 

결국 Software 개발이 다음과 같은 흐름으로 이어진다.

Requirement
     ↓
Architecture
     ↓
Detailed Design
     ↓
Implementation
     ↓
Unit Test
     ↓
Integration Test
     ↓
Software Verification

 

그리고 최종적으로 다음 질문에 답할 수 있어야 한다.

"처음에 정의했던 Software Requirement를 실제 Software가 만족하는가?"

 

이 질문에 답하기 위해서는 테스트 결과뿐만 아니라 Requirement와 Test 사이의 연결 관계도 중요하다.

 

ASPICE에서 가장 중요한 개념 중 하나, Traceability(추적성)

 

ASPICE를 공부하다 보면 Traceability라는 단어를 굉장히 자주 만나게 된다.

Traceability는 쉽게 말하면 개발 과정에서 만들어지는 여러 산출물 사이의 추적 관계이다.

 

예를 들어 하나의 Software Requirement가 있다고 하자.

SWR-001
   ↓
Software Architecture
   ↓
Detailed Design
   ↓
Source Code
   ↓
Test Case
   ↓
Test Result

 

이렇게 연결되어 있다면 문제가 발생했을 때 어느 부분을 확인해야 하는지 추적할 수 있다.

 

Requirement 100개, Source Code 수천 개, Test Case 300개가 존재하지만 서로 어떤 관계인지 알 수 없다면 특정 Requirement가 실제로 구현되었는지, 해당 Requirement를 테스트했는지 확인하기 어렵다.

 

그래서 실제 프로젝트에서는 Requirement ID를 관리하는 경우가 많다.

 

예를 들어, SWR_001, SWR_002, SWR_003, ...과 같은 ID를 부여하고,

SWR_001
   ↓
Design_001
   ↓
Function_001()
   ↓
TC_001
   ↓
PASS

 

처럼 연결한다.

 

이렇게 하면 다음과 같은 질문에 답할 수 있다.

• 이 Requirement는 어디에 구현되어 있는가?
• 이 Requirement를 검증하는 Test Case는 무엇인가?
• 해당 Test Case는 PASS했는가?
• Test에서 문제가 발생하면 어떤 Requirement와 연결되는가?

이런 추적 관계가 잘 만들어져 있으면 개발과 검증뿐 아니라 변경 영향 분석에도 유용하다.

 

예를 들어 Requirement가 변경되었을 때

Requirement 변경
      ↓
Architecture 영향
      ↓
Design 영향
      ↓
Code 영향
      ↓
Test Case 영향

 

을 추적할 수 있다.

 

따라서 Traceability는 단순히 ASPICE 심사를 통과하기 위한 문서 작업이 아니라

실제 Software 변경 관리에도 중요한 역할을 한다.

 

Capability Level이란?

 

ASPICE에서 또 하나 중요한 개념이 Capability Level이다.

 

ASPICE는 단순하게 "프로세스를 수행했다 / 수행하지 않았다."만 평가하는 것이 아니다.

프로세스가 어느 정도의 능력을 갖추고 관리되는지를 Level로 평가한다.

 

ASPICE 4.0에서는 다음과 같이 Capability Level 0부터 Level 5까지 구분한다.

CL0 Incomplete: 프로세스가 불완전한 상태
CL1 Performed: 프로세스가 수행되는 상태
CL2 Managed: 프로세스가 관리되는 상태
CL3 Established: 정의된 프로세스로 수행되는 상태
CL4 Predictable: 정량적으로 관리되고 예측 가능한 상태
CL5 Innovating: 지속적인 개선과 혁신이 이루어지는 상태

 

실무에서 특히 많이 듣는 것이 Level 1과 Level 2이다.

Level 1에서는 기본적으로 프로세스가 실제 수행되어야 한다.

 

예를 들어 SWE.4라면 실제 Unit Test가 수행되고 결과가 존재해야 한다.

여기서 한 단계 더 나아간 것이 Level 2이다.

 

Level 2에서는 단순히 Test를 수행하는 것뿐만 아니라 계획하고, 자원을 관리하고, 결과물을 관리하는 등 프로세스를 관리하는 활동이 중요해진다.

 

예를 들어 Unit Test를 한다면

• 누가 테스트하는가?
• 언제 수행하는가?
• 어떤 범위를 테스트하는가?
• 완료 기준은 무엇인가?
• 테스트 결과는 어떻게 관리하는가?

등을 체계적으로 관리해야 한다.

 

그리고 Level 3에서는 조직에서 정의된 표준 프로세스를 프로젝트에 적용하고 Tailoring 등을 통해 프로젝트에 맞게 적용하는 수준으로 발전한다.

 

따라서 "ASPICE Level 2 = 문서가 많다"라고 단순하게 이해하면 안 된다.

핵심은 프로세스가 관리되는가이다.

 

ASPICE에서 Evidence(증거)가 중요한 이유

 

실제 Assessment를 생각하면 Evidence, 즉 객관적인 증거가 매우 중요하다.

 

예를 들어 개발자가 "Unit Test는 모두 수행했습니다."라고 이야기한다고 해서 평가가 끝나는 것은 아니다.

실제로 수행했다는 것을 보여줄 수 있어야 한다.

 

예를 들어 다음과 같은 결과물이 있을 수 있다.

Unit Test Specification
        ↓
Test Case
        ↓
Test Execution
        ↓
Test Result
        ↓
Test Report

 

그리고 해당 결과가 Requirement나 Software Unit과 연결되어 있어야 한다.

즉, "했다고 말한다" ≠ "했다는 증거가 있다" 이다.

 

ASPICE에서는 실제 개발 활동과 그 결과를 확인할 수 있는 Objective Evidence가 중요하다.

 

그래서 프로젝트에서 생성되는 SRS, Architecture, Design, Source Code, Test Specification, Test Report, Review Record 등의 산출물이 단순한 문서가 아니라 개발 프로세스가 수행되었다는 근거로 사용될 수 있다.

 

ASPICE가 특정 파일명이나 문서 양식을 강제하는 것은 아니다. 중요한 것은 프로젝트에서 정의된 개발 프로세스에 따라 필요한 Work Product가 생성되고, 실제 개발 활동과 연결되어 있으며, 그 결과를 확인할 수 있는가이다.

 

ASPICE와 AUTOSAR, ISO 26262는 어떻게 다른가?

 

자동차 SW 개발에서는 ASPICE와 함께 AUTOSAR, ISO 26262라는 용어도 자주 등장하기 때문에 이 세 가지를 구분해두는 것이 좋다.

 

가장 간단하게 보면 다음과 같다.

구분	핵심 관점
ASPICE	개발 프로세스를 어떻게 수행하고 관리하는가
AUTOSAR	자동차 Software Architecture와 플랫폼을 어떻게 구성하는가
ISO 26262	Functional Safety를 어떻게 확보하는가

 

예를 들어 AUTOSAR 프로젝트라면 다음과 같은 구조를 사용할 수 있다.

Application SWC
      ↓
Runnable
      ↓
   RTE
      ↓
   BSW
      ↓
   MCAL
      ↓
   MCU

 

이것은 Software Architecture와 구현 방식에 대한 이야기이다.

반면 ASPICE에서는 이 Software를 개발하는 과정에서

Requirement
      ↓
Architecture
      ↓
Detailed Design
      ↓
Implementation
      ↓
Verification

 

이 제대로 수행되는지를 본다.

 

ISO 26262는 여기에 Functional Safety라는 별도의 관점을 추가한다.

예를 들어 안전과 관련된 기능이라면 Hazard Analysis, ASIL, Safety Requirement, Safety Mechanism 등의 개념이 등장한다.

 

실제 자동차 프로젝트에서는 이들이 서로 독립적으로 존재하는 것이 아니라 하나의 개발 프로젝트 안에서 서로 연결되어 사용된다.

 

결국 ASPICE를 어떻게 이해하면 되는가?

 

ASPICE를 처음 공부할 때 가장 어려운 부분은 프로세스 이름을 하나씩 외우려고 하기 때문이다.

사실 SWE.1부터 SWE.6까지를 다음 질문으로 바꾸면 훨씬 이해하기 쉽다.

SWE.1 "Software가 무엇을 해야 하는가?"
      ↓
SWE.2 "그 Software를 어떤 구조로 만들 것인가?"
      ↓
SWE.3 "각 기능을 어떻게 상세하게 설계하고 구현할 것인가?"
      ↓
SWE.4 "각 Unit이 제대로 동작하는가?"
      ↓
SWE.5 "Component와 Integration이 제대로 동작하는가?"
      ↓
SWE.6 "전체 Software가 요구사항을 만족하는가?"

 

그리고 이 전체 과정이 다음과 같이 연결된다.

System Requirement
        ↓
Software Requirement
        ↓
Software Architecture
        ↓
Detailed Design
        ↓
Source Code
        ↓
Unit Test
        ↓
Integration Test
        ↓
Software Verification

 

여기에서 가장 중요한 것이 Traceability이다. 추적성 관계가 명확하게 연결되어 있으면 개발 과정에서 변경이 발생했을 때 영향 범위를 추적하기 쉽고, 테스트가 어떤 요구사항을 검증하는지도 확인할 수 있다.

 

결국 ASPICE의 핵심은 단순히 "문서를 많이 만드는 것"이 아니다.

 

무엇을 개발해야 하는지 정의하고 → 그것을 설계하고 → 구현하고 → 검증하고 → 그 과정과 결과를 추적할 수 있도록 관리하는 것이 핵심이다.

 

참고자료: VDA QMC — Automotive SPICE PAM 4.0 공식 문서

https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf?trk=public_post-text