자동차 개발에서 협력사 프로세스가 중요한 이유
자동차 소프트웨어 개발은 한 회사가 모든 기능을 단독으로 만드는 구조가 아니다. 완성차 업체, 1차 협력사, 2차 협력사, 소프트웨어 공급사, 반도체 업체가 함께 개발하는 경우가 많다. 하나의 ECU 안에도 여러 업체가 제공한 소프트웨어 모듈, 통신 사양, 진단 기능, 하드웨어 인터페이스가 함께 포함될 수 있다. 따라서 협력사 간 개발 프로세스가 맞지 않으면 요구사항 해석 차이, 인터페이스 오류, 테스트 누락, 일정 지연이 발생할 수 있다.
ASPICE는 이러한 협업 구조에서 공통된 개발 기준을 제공한다. 고객사는 협력사가 요구사항 분석, 설계, 구현, 검증, 형상관리, 변경관리를 체계적으로 수행하고 있는지 확인하고 싶어 한다. 협력사 입장에서는 자신들의 개발 활동이 객관적인 기준에 맞게 진행되었음을 보여줘야 한다. 단순히 기능이 동작한다고 말하는 것만으로는 부족하고, 어떤 요구사항을 기준으로 개발했으며 어떤 테스트로 검증했는지 설명할 수 있어야 한다.
협력사 개발에서 가장 중요한 것은 업무 범위와 책임을 명확히 하는 것이다. 고객사가 제공한 요구사항 중 어떤 부분을 협력사가 담당하는지, 어떤 인터페이스를 기준으로 개발해야 하는지, 어떤 산출물을 제출해야 하는지 초기에 정리해야 한다. 이 기준이 불명확하면 개발 후반에 “누가 해야 하는 일인가”를 두고 혼선이 생길 수 있다.
ASPICE 관점에서 고객사가 확인하는 항목
고객사가 ASPICE 관점에서 가장 많이 확인하는 부분은 요구사항 추적성이다. 고객 요구사항이 협력사의 시스템 요구사항 또는 소프트웨어 요구사항으로 어떻게 반영되었는지 확인할 수 있어야 한다. 또한 해당 요구사항이 설계, 코드, 테스트 케이스로 연결되어야 한다. 고객 요구사항을 받았지만 협력사 내부 산출물과 연결되지 않는다면 요구사항 누락이나 검증 부족으로 볼 수 있다.
두 번째로 확인하는 항목은 산출물의 일관성이다. 요구사항 문서, 설계 문서, 테스트 케이스, 테스트 결과, 결함 이력, 릴리즈 노트가 서로 같은 기준을 바라보고 있어야 한다. 예를 들어 설계 문서에는 기능이 반영되어 있지만 테스트 케이스가 없거나, 테스트 결과는 최신 버전인데 요구사항 문서는 이전 버전이라면 고객사 대응에서 문제가 될 수 있다.
세 번째는 변경관리다. 고객 요청이나 사양 변경이 발생했을 때 협력사가 영향 분석을 수행했는지, 변경 내용을 설계와 테스트에 반영했는지, 재검증 결과를 남겼는지 확인해야 한다. 자동차 개발에서는 사양 변경이 자주 발생하기 때문에 변경을 얼마나 체계적으로 관리하는지가 협력사의 개발 역량을 보여주는 중요한 기준이 된다.
협력사가 고객사 대응을 잘하기 위한 방법
협력사가 고객사 대응을 잘하려면 프로젝트 초기에 산출물 제출 기준을 명확히 합의해야 한다. 어떤 문서를 언제 제출할지, 어떤 형식으로 추적성을 보여줄지, 테스트 결과에는 어떤 정보가 포함되어야 하는지 정해야 한다. 고객사마다 요구하는 양식과 수준이 다를 수 있으므로 내부 기준만으로 준비하면 추가 보완 요청이 반복될 수 있다.
또한 커뮤니케이션 기록을 남기는 것이 중요하다. 요구사항 해석, 변경 요청, 이슈 협의, 테스트 결과 공유, 릴리즈 승인과 관련된 내용은 회의록이나 이슈 관리 시스템에 남겨야 한다. 구두로만 합의한 내용은 시간이 지나면 기준이 불명확해질 수 있다. ASPICE 대응에서는 실제로 어떤 검토와 합의가 있었는지 보여줄 수 있는 기록이 중요하다.
결론적으로 협력사 개발에서 ASPICE는 고객사 대응을 위한 형식적인 기준이 아니라, 여러 조직이 같은 목표로 개발하기 위한 공통 언어다. 요구사항, 설계, 테스트, 변경 이력을 일관성 있게 관리하면 고객사 신뢰를 높이고 프로젝트 리스크를 줄일 수 있다. 협력사는 ASPICE를 심사 준비용 문서 작업으로만 보지 말고, 고객 요구를 정확히 반영하고 검증 결과를 설명하기 위한 실무 프로세스로 활용해야 한다.