자동차 소프트웨어 개발에서 SWE.2는 소프트웨어 아키텍처 설계를 의미한다. SWE.1에서 소프트웨어 요구사항이 정리되면, 다음 단계에서는 그 요구사항을 어떤 구조로 구현할지 결정해야 한다. 이때 작성되는 것이 소프트웨어 아키텍처다. 아키텍처 설계는 단순히 그림을 그리는 작업이 아니라, 소프트웨어 구성 요소를 나누고 각 요소의 역할, 인터페이스, 데이터 흐름, 제어 흐름을 정의하는 핵심 개발 활동이다.
ASPICE SWE.2의 목적은 소프트웨어 요구사항을 기반으로 구현 가능한 소프트웨어 구조를 만드는 것이다. 요구사항이 “무엇을 해야 하는가”를 설명한다면, 아키텍처는 “어떤 구조로 동작하게 할 것인가”를 설명한다. 예를 들어 입력 신호를 수신하는 모듈, 상태를 판단하는 제어 로직, 진단을 처리하는 모듈, 출력 신호를 생성하는 모듈을 구분하고 이들이 어떤 순서와 조건으로 연결되는지 정의하는 것이 아키텍처 설계에 해당한다.
좋은 소프트웨어 아키텍처를 만들기 위해서는 먼저 소프트웨어 요구사항을 정확히 분석해야 한다. 요구사항에 포함된 기능, 타이밍 조건, 오류 처리, 진단 조건, 인터페이스 조건을 확인하고 이를 적절한 소프트웨어 컴포넌트로 분해해야 한다. 기능별 책임이 불명확하면 구현 단계에서 중복 코드가 생기거나 모듈 간 의존성이 복잡해질 수 있다. 따라서 각 컴포넌트가 어떤 역할을 담당하는지 명확하게 정의하는 것이 중요하다.
두 번째로 중요한 것은 인터페이스 정의다. 자동차 ECU 소프트웨어는 여러 모듈과 계층이 함께 동작한다. 입력 신호를 어디서 받고, 내부 데이터는 어떤 형식으로 전달하며, 출력 신호는 어떤 조건에서 갱신되는지 명확해야 한다. 특히 CAN, LIN, Ethernet과 같은 차량 통신 신호, 진단 데이터, 하드웨어 추상화 계층과의 연결은 설계 단계에서 충분히 검토되어야 한다. 인터페이스가 불명확하면 통합 단계에서 오류가 많이 발생할 수 있다.
세 번째는 요구사항과 아키텍처 간 추적성이다. ASPICE에서는 소프트웨어 요구사항이 아키텍처 설계에 반영되었는지 확인할 수 있어야 한다. 하나의 요구사항이 어떤 컴포넌트에서 처리되는지 연결되어야 하며, 반대로 각 컴포넌트가 어떤 요구사항을 만족하기 위해 존재하는지도 설명할 수 있어야 한다. 추적성이 확보되면 요구사항 변경이 발생했을 때 영향을 받는 설계 영역을 빠르게 파악할 수 있다.
네 번째는 품질 속성의 반영이다. 아키텍처 설계는 기능 동작만 고려해서는 부족하다. 응답 시간, 메모리 사용량, 재사용성, 유지보수성, 안전성, 오류 감지, 확장 가능성도 함께 고려해야 한다. 자동차 소프트웨어는 장기간 유지되고 여러 차종에 재사용되는 경우가 많기 때문에 처음부터 구조를 안정적으로 설계하는 것이 중요하다. 기능이 동작하더라도 구조가 복잡하고 변경에 취약하면 좋은 아키텍처라고 보기 어렵다.
SWE.2 산출물에는 소프트웨어 아키텍처 설계서, 컴포넌트 구조도, 인터페이스 정의, 데이터 흐름 설명, 동작 시퀀스, 설계 검토 기록 등이 포함될 수 있다. 중요한 것은 문서의 형식보다 내용의 명확성이다. 설계 문서를 본 개발자가 구현 방향을 이해할 수 있어야 하고, 검증 담당자는 어떤 단위로 테스트를 준비해야 하는지 판단할 수 있어야 한다.
결론적으로 ASPICE SWE.2는 소프트웨어 요구사항을 실제 구현 가능한 구조로 바꾸는 단계다. 좋은 아키텍처 설계는 요구사항을 빠짐없이 반영하고, 컴포넌트의 역할과 인터페이스를 명확히 하며, 변경과 검증에 강한 구조를 제공해야 한다. ECU 개발자라면 SWE.2를 단순한 설계 문서 작성이 아니라 소프트웨어 품질을 결정하는 중요한 실무 활동으로 이해하는 것이 필요하다.