ASPICE를 문서 작업으로만 보는 실수
자동차 SW 개발팀이 ASPICE 프로젝트를 진행할 때 가장 많이 하는 실수는 ASPICE를 실제 개발 프로세스가 아니라 심사를 위한 문서 작업으로만 생각하는 것이다. ASPICE는 요구사항 분석, 설계, 구현, 검증, 변경관리, 형상관리 등 개발 전 과정을 체계적으로 수행했는지 확인하는 기준이다. 따라서 단순히 문서를 많이 만드는 것보다 각 산출물이 개발 흐름 안에서 서로 연결되어 있는지가 중요하다.
첫 번째 실수는 요구사항을 모호하게 작성하는 것이다. “정상적으로 동작한다”, “빠르게 응답한다”, “필요 시 경고한다” 같은 표현은 개발자와 검증자가 서로 다르게 해석할 수 있다. ASPICE 관점에서 요구사항은 명확하고 검증 가능한 형태로 작성되어야 한다. 예를 들어 “입력 신호 발생 후 100ms 이내에 출력 신호를 전환한다”처럼 조건, 동작, 기준이 분명해야 한다. 요구사항 품질이 낮으면 설계와 테스트 품질도 함께 떨어진다.
두 번째 실수는 추적성을 개발 후반에 맞추는 것이다. 많은 프로젝트에서 요구사항, 설계, 코드, 테스트를 먼저 진행한 뒤 심사 직전에 추적성 매트릭스를 정리하려고 한다. 하지만 이 방식은 누락과 오류가 발생하기 쉽다. 고객 요구사항이 시스템 요구사항과 소프트웨어 요구사항으로 연결되고, 다시 설계와 테스트 케이스로 이어지는 구조는 프로젝트 초반부터 관리해야 한다. 추적성은 심사용 자료가 아니라 변경 영향 분석과 검증 완전성을 확인하는 실무 도구다.
세 번째 실수는 설계 문서와 코드가 일치하지 않는 것이다. 설계 문서에는 특정 로직이 있다고 작성되어 있지만 실제 코드에는 다르게 구현되어 있거나, 코드에는 기능이 추가되었는데 설계 문서에는 반영되지 않는 경우가 있다. ASPICE에서는 설계와 구현의 일관성이 중요하다. 요구사항이 설계에 반영되고, 설계가 코드로 구현되며, 테스트로 확인되는 흐름이 설명 가능해야 한다.
네 번째 실수는 테스트 케이스를 요구사항과 연결하지 않는 것이다. 테스트를 많이 수행했더라도 어떤 요구사항을 검증하기 위한 테스트인지 설명할 수 없다면 ASPICE 대응이 어렵다. 유닛 테스트, 통합 테스트, 소프트웨어 적격성 테스트는 각각의 목적과 기준이 분명해야 한다. 테스트 케이스는 요구사항이나 설계 항목과 연결되어야 하며, 실패한 항목은 결함 관리와 재검증 이력까지 남아 있어야 한다.
다섯 번째 실수는 변경관리를 가볍게 보는 것이다. 자동차 소프트웨어 개발에서는 고객 요청, 사양 변경, 결함 수정이 자주 발생한다. 이때 변경 요청의 사유, 영향 분석, 승인 여부, 수정 범위, 재검증 결과를 관리하지 않으면 어떤 기준으로 개발이 완료되었는지 설명하기 어렵다. 요구사항 하나가 바뀌면 설계, 코드, 테스트가 함께 영향을 받을 수 있으므로 변경관리와 형상관리는 반드시 함께 관리해야 한다.
ASPICE 대응을 잘하려면 개발팀 전체가 같은 기준을 이해해야 한다. 요구사항 담당자만 ASPICE를 아는 것으로는 부족하고, 시스템 엔지니어, 소프트웨어 개발자, 검증 담당자, 품질 담당자가 산출물의 목적과 연결 관계를 함께 이해해야 한다. 특히 ECU 개발자는 자신이 작성한 코드가 어떤 요구사항과 설계를 만족하는지 설명할 수 있어야 한다.
결론적으로 자동차 SW 개발팀의 ASPICE 대응은 문서 양을 늘리는 것이 아니라 개발 흐름을 명확히 만드는 데 집중해야 한다. 요구사항은 검증 가능하게 작성하고, 설계와 코드는 일치시켜야 하며, 테스트는 요구사항과 연결되어야 한다. 또한 변경이 발생하면 영향 분석과 재검증 이력을 남겨야 한다. 이러한 기본 원칙을 지키면 ASPICE Assessment 대응뿐 아니라 실제 자동차 소프트웨어 품질 향상에도 큰 도움이 된다.