Automotive SPICE 3.1과 4.0 차이: SYS.5 인정시험이 System Verification으로 바뀐 이유
자동차 개발 문서를 검토하다 보면 같은 SYS.5인데도 어떤 문서에는 System Qualification Test, 어떤 문서에는 System Verification이라고 적혀 있습니다. 국내 실무에서는 전자를 ‘시스템 인정시험’ 또는 ‘시스템 자격시험’으로 번역해 온 경우가 많아, Automotive SPICE 4.0 문서를 처음 접하면 “SYS.5의 역할 자체가 달라진 것인가?”라는 의문이 생깁니다.
결론부터 말하면 SYS.5가 시스템 요구사항에 대한 최종 검증을 수행한다는 핵심 목적은 유지되지만, Automotive SPICE 4.0에서는 명칭과 프로세스 설명이 Verification 중심으로 정비됐습니다. 따라서 구버전 프로젝트의 문서를 무조건 틀렸다고 판단해서는 안 되고, 적용한 PAM 버전과 계약·고객 기준을 먼저 확인해야 합니다.
이 글은 공개된 Automotive SPICE PAM을 바탕으로 용어와 실무 적용 방법을 설명합니다. 회사명, 고객명, 프로젝트 코드 및 양산 사양은 포함하지 않았습니다. 실제 프로젝트에서는 계약 버전과 조직 표준을 우선하십시오.
30초 요약
- Automotive SPICE 3.1의 SYS.5 공식 영문 명칭은 System Qualification Test입니다.
- Automotive SPICE 4.0에서는 System Verification으로 변경됐습니다.
- 3.1에서 사용하던 ‘인정시험’이라는 표현이 역사적으로 잘못된 것은 아니지만, 4.0을 적용하는 새 문서에서는 ‘시스템 검증’처럼 현재 명칭에 맞춘 표현이 더 정확합니다.
- SYS.5는 시스템 요구사항을 기준으로 통합된 시스템을 검증합니다. V 모델에서는 SYS.2와 SYS.5가 대응합니다.
- SYS.4는 시스템 아키텍처와 인터페이스를 기준으로 통합 결과를 검증하므로 SYS.3와 SYS.4가 대응합니다.
- SIL·HIL·Bench·실차는 시험환경입니다. 환경 이름만으로 SYS.4와 SYS.5를 구분할 수 없습니다.
- 구버전 문서를 전환할 때는 단순 문자열 치환이 아니라 목적, 입력정보, 검증 방안, 결과 및 추적성까지 함께 검토해야 합니다.
1. 왜 같은 SYS.5에 두 가지 이름이 있을까?
원인은 대부분 적용 버전의 차이입니다. Automotive SPICE 3.1과 4.0 문서를 섞어서 읽거나, 조직의 한글 표준용어가 구버전 명칭을 유지하면 같은 프로세스를 서로 다르게 부르게 됩니다.
| 프로세스 | Automotive SPICE 3.1 | Automotive SPICE 4.0 | 실무에서 자주 쓰는 표현 |
|---|---|---|---|
| SYS.4 | System Integration and Integration Test | System Integration and Integration Verification | 시스템 통합 및 통합시험·통합검증 |
| SYS.5 | System Qualification Test | System Verification | 시스템 인정시험·자격시험·시스템 검증 |
| SWE.5 | Software Integration and Integration Test | Software Component Verification and Integration Verification | 소프트웨어 통합 및 통합시험·통합검증 |
| SWE.6 | Software Qualification Test | Software Verification | 소프트웨어 인정시험·자격시험·소프트웨어 검증 |
따라서 문서 제목에 ‘SYS.5 시스템 인정시험 계획서’라고 쓰여 있다고 해서 즉시 부적합이라고 판단할 수는 없습니다. 그 프로젝트가 Automotive SPICE 3.1을 계약 기준으로 사용한다면 당시 공식 영문 명칭을 조직의 용어로 번역한 것일 수 있습니다. 반대로 4.0 적용을 선언한 신규 프로젝트가 모든 문서에 Qualification Test를 사용한다면, 버전 기준과 내부 용어집이 일치하는지 확인할 필요가 있습니다.
핵심은 번역 단어 하나가 아니라 다음 세 가지입니다.
- 어떤 PAM 버전을 적용했는가?
- SYS.5의 검증 기준이 시스템 요구사항과 연결되어 있는가?
- 검증 방안과 결과가 양방향으로 추적되는가?
2. Qualification Test와 Verification은 무엇이 다른가?
‘Qualification Test’는 개발된 시스템이 정해진 요구와 사용 목적을 충족해 인도 가능한 수준인지 확인하는 최종 시험의 뉘앙스가 강합니다. 그래서 국내에서는 인정시험, 자격시험 또는 적격성 시험으로 번역돼 왔습니다.
‘Verification’은 산출물이 정의된 요구사항과 기준을 충족하는지 객관적 증거로 확인하는 더 넓은 개념입니다. Automotive SPICE 4.0에서는 시스템·소프트웨어·하드웨어 엔지니어링 영역의 검증 활동을 보다 일관된 구조로 설명하기 위해 Verification 중심 명칭을 사용합니다.
그렇다고 SYS.5가 갑자기 개발 중간 단계의 가벼운 검토로 바뀐 것은 아닙니다. SYS.5는 여전히 통합된 시스템이 시스템 요구사항을 충족하는지 확인하는 시스템 수준 검증입니다. 환경·성능·내구·진단·고장반응 등 시스템 요구사항에 포함된 항목이 검증 대상이 될 수 있습니다.
이때 ‘고객이 최종적으로 제품을 수락하는 활동’과 SYS.5를 완전히 같은 것으로 보아서는 안 됩니다. 고객 인수, 차량 수준 승인, 법규 인증 및 생산 승인에는 별도의 계약·조직·법규 절차가 적용될 수 있습니다. SYS.5는 개발 조직이 시스템 요구사항에 대해 만드는 검증 증거에 초점을 둡니다.
3. V 모델에서 SYS.2와 SYS.5가 연결되는 이유
Automotive SPICE 시스템 엔지니어링의 핵심 관계를 가장 간단히 표현하면 다음과 같습니다.
| 개발 측 프로세스 | 검증 측 프로세스 | 직접 비교 기준 |
|---|---|---|
| SYS.2 시스템 요구사항 분석 | SYS.5 시스템 검증 | 시스템 요구사항 |
| SYS.3 시스템 아키텍처 설계 | SYS.4 시스템 통합 및 통합검증 | 시스템 아키텍처, 인터페이스, 통합 순서 |
SYS.2에서는 이해관계자의 요구를 기술적으로 분석하고, 시스템이 충족해야 할 기능·성능·인터페이스·환경·진단·안전 관련 요구사항을 정의합니다. SYS.5에서는 통합된 시스템을 대상으로 이 요구사항이 실제로 충족되는지 검증합니다.
예를 들어 “저전압 조건에서도 지정된 성능 저하 전략을 수행해야 한다”는 시스템 요구사항이 있다면 SYS.5 검증 방안은 다음 정보를 포함해야 합니다.
- 시험 대상 시스템 구성과 소프트웨어·하드웨어 버전
- 공급전압 범위와 변화 조건
- 부하 및 온도 조건
- 관찰해야 할 시스템 출력과 진단 상태
- 허용오차 및 시간 조건
- 합격·불합격 기준
- 시험 데이터와 로그의 보관 방법
- 요구사항 ID와 검증 결과 ID의 연결
반면 SYS.4는 내부 구성요소가 올바른 순서로 통합됐는지, 시스템 아키텍처에서 정의한 인터페이스와 상호작용이 정상인지 확인하는 데 초점을 둡니다. 같은 HIL 장비를 사용하더라도 검증의 직접 기준이 아키텍처인지 시스템 요구사항인지에 따라 SYS.4와 SYS.5의 성격이 달라집니다.
4. SYS.5는 반드시 HIL에서 수행해야 할까?
아닙니다. Automotive SPICE는 SYS.5를 특정 장비 하나에 고정하지 않습니다. 필요한 검증 인프라와 환경은 검증하려는 시스템 요구사항, 제품 구성, 리스크 및 재현성에 따라 정해야 합니다.
| 검증환경 | 강점 | 대표적인 활용 | 주의점 |
|---|---|---|---|
| 시뮬레이션·가상환경 | 빠른 반복, 위험조건 재현 | 초기 알고리즘·모델 검증 | 실제 HW·센서·부하 차이를 반영해야 함 |
| SIL | 소프트웨어 실행과 자동화에 유리 | 로직, 상태천이, 경계조건 | 시스템 전체 물리특성 검증에는 한계 |
| HIL | 실시간 신호, 결함 주입, 반복성 | ECU 입출력, 통신, 고장반응 | 플랜트 모델의 타당성 확인 필요 |
| Bench | 실제 부품과 부하를 사용 가능 | 전압·전류·열·통신·성능 측정 | 안전설비와 계측 불확도 관리 필요 |
| 환경챔버 | 온도·환경조건 재현 | 저온·고온, 열보호, 성능 변화 | 안정화 시간과 센서 위치 관리 필요 |
| 실차·시스템 실물 | 최종 사용환경과 유사 | 차량 상호작용, 실제 부하 확인 | 비용, 안전, 재현성 및 원인 분리가 어려움 |
중요한 것은 “HIL을 사용했는가?”가 아니라 검증하려는 요구사항에 충분한 환경과 관찰수단을 선택했는가?입니다. 하나의 시스템 요구사항을 HIL에서 검증하고, 다른 요구사항은 Bench 또는 환경챔버에서 검증할 수 있습니다. 필요하면 여러 환경의 결과를 조합해 하나의 검증 근거를 구성합니다.
5. 3.1 문서를 4.0으로 전환할 때 생기는 실수
가장 흔한 실수는 Qualification Test를 Verification으로 일괄 치환하고 내용은 그대로 두는 것입니다. 버전 전환은 단순 번역 작업이 아닙니다.
| 실수 | 발생할 수 있는 문제 | 권장 조치 |
|---|---|---|
| 문서명만 변경 | 표지와 본문·추적성 데이터가 모순됨 | 목적, 입력정보, 검증 방안과 결과까지 검토 |
| 시험 개수만 확대 | 릴리스 범위와 변경 위험을 설명하지 못함 | 검증 방안 선택 및 회귀검증 근거 기록 |
| 링크 존재만 확인 | 수치·단위·허용오차가 서로 다를 수 있음 | 링크된 내용의 일관성까지 확인 |
| SYS.5와 고객 인수를 동일시 | 계약·법규·승인 활동의 경계가 흐려짐 | 개발 검증과 고객 인수 절차를 구분 |
| 기존 용어를 모두 삭제 | 3.1 계약과 과거 증거의 맥락이 사라짐 | 적용 버전을 표시하고 구·신 용어 대응표 유지 |
6. 실무 문서 전환 7단계
- 적용 기준 확정: 계약, 개발계획, 심사 범위와 조직 표준에서 적용 버전을 확인합니다.
- 용어 대응표 작성: 3.1·4.0 프로세스명, 내부 한글 명칭과 문서명을 연결합니다.
- 목적과 범위 검토: SYS.4는 아키텍처·통합, SYS.5는 시스템 요구사항 관점으로 구분합니다.
- 검증 방안 점검: 합격 기준, 진입·종료 기준, 순서, 환경, 계측 및 회귀선정 기준을 확인합니다.
- 양방향 추적성 확인: 요구사항→방안→결과와 결과→방안→요구사항을 모두 점검합니다.
- 형상정보 연결: HW·SW·모델·스크립트·장비 설정, 원본 로그와 결과 보고서를 연결합니다.
- 리뷰와 승인: 자동변환 결과를 담당자가 검토하고 변경 사유와 승인자를 기록합니다.
7. AI는 어디까지 활용할 수 있을까?
AI는 대량 문서에서 3.1·4.0 용어를 찾고, 추적성 누락과 모순 후보를 정리하는 데 유용합니다. 하지만 프로세스 적합성, 안전 영향 및 최종 승인까지 AI에게 맡겨서는 안 됩니다.
AI에 적합한 작업
- 구버전 프로세스명과 문서 제목 검색
- 동일 문서 안의 3.1·4.0 용어 혼용 탐지
- 요구사항과 검증 방안의 링크 누락 후보 검색
- 요구사항 수치와 합격 기준의 불일치 후보 비교
- 고아 요구사항과 고아 테스트 목록 생성
- 변경 전후 문서의 차이 요약
- 리뷰 질문과 체크리스트 초안 작성
사람이 반드시 판단할 작업
- 계약상 적용 버전과 고객 기준 확정
- 시스템 경계와 검증 수준 결정
- 시험환경의 충분성과 플랜트 모델 타당성 판단
- 안전 관련 합격 기준 승인
- 실제 로그와 계측 불확도 해석
- 프로세스 적합성 및 릴리스 승인
복사해서 사용하는 AI 점검 프롬프트
역할: Automotive SPICE 문서 전환 검토 보조자
입력:
- 비식별화한 프로세스 문서와 내부 용어집
- 요구사항·검증 방안·결과 ID 목록
작업:
1. 3.1·4.0 명칭 혼용 위치와 수정 후보를 표로 정리한다.
2. SYS.2↔SYS.5, SYS.3↔SYS.4 추적성 누락 후보를 찾는다.
3. 수치, 단위, 허용오차, 버전과 합격 기준의 불일치 후보를 표시한다.
4. 확인되지 않은 내용은 '사람 검토 필요'로 분류한다.
5. 원문에 없는 요구사항, 수치와 결과를 만들지 않는다.
출력:
- 위치·ID / 현재 표현 / 4.0 표현 / 위험 / 수정 제안 / 확인 근거
보안:
회사명, 고객명, 프로젝트 코드와 실제 양산 사양은 입력하지 않는다.
8. 프로젝트에서 사용할 권장 표기법
문서 첫 부분에 적용 버전과 표기 원칙을 적으면 혼란을 줄일 수 있습니다.
본 프로젝트는 Automotive SPICE 4.0을 적용한다. SYS.5의 공식 영문 명칭은 System Verification이며, 한글 문서에서는 ‘시스템 검증’을 사용한다. 과거 문서의 ‘시스템 인정시험’ 또는 ‘System Qualification Test’는 Automotive SPICE 3.1 기반의 구버전 명칭으로 관리한다.
고객 계약에서 인정시험을 사용한다면 임의로 삭제하지 말고 다음처럼 병기할 수 있습니다.
시스템 검증(System Verification, 고객 문서의 ‘시스템 인정시험’에 대응)
이렇게 하면 공식 명칭과 고객 용어를 모두 보존할 수 있습니다.
9. 자주 묻는 질문
Q1. Automotive SPICE 4.0에서는 ‘시스템 인정시험’이라고 쓰면 무조건 틀린가요?
무조건 틀렸다고 단정할 수는 없습니다. 다만 4.0 공식 명칭은 System Verification이므로 적용 버전과 용어 대응 관계를 명시해야 합니다.
Q2. SYS.5가 System Verification이면 SYS.4보다 범위가 작아진 건가요?
아닙니다. SYS.4는 시스템 아키텍처와 통합을, SYS.5는 시스템 요구사항 충족을 직접 검증합니다.
Q3. SYS.5는 HIL, SYS.4는 Bench로 구분하면 되나요?
안 됩니다. HIL과 Bench는 환경입니다. 시험계획에 검증 수준, 비교 기준과 추적성 관계를 명시해야 합니다.
Q4. 3.1 문서를 4.0으로 일괄 치환해도 될까요?
권장하지 않습니다. 문서명만 바꾸면 목적, 추적성, 결과 형식과 용어가 불일치할 수 있습니다. 자동 변환 후 엔지니어 리뷰와 형상관리 승인이 필요합니다.
Q5. AI가 Automotive SPICE 적합 여부를 판정할 수 있나요?
AI는 누락과 불일치 후보를 찾는 보조도구로 사용할 수 있지만, 공식 심사 판정이나 안전·릴리스 승인을 대신할 수 없습니다. 원본 근거와 실제 수행 증거를 사람이 확인해야 합니다.
마무리
SYS.5가 System Qualification Test에서 System Verification으로 바뀐 것은 단순한 번역 교체가 아닙니다. Automotive SPICE 4.0이 시스템·소프트웨어·하드웨어 영역의 검증 활동을 더 일관된 Verification 구조로 설명하려는 변화로 이해해야 합니다.
그러나 실무에서 가장 중요한 것은 단어 자체가 아닙니다. 적용 버전을 명확히 하고, 시스템 요구사항과 검증 방안·결과를 연결하며, 재현 가능한 객관적 증거를 남기는 것이 핵심입니다. 기존 3.1 문서는 역사적 근거와 계약 기준을 보존하고, 신규 4.0 프로젝트는 공식 명칭과 조직 용어집을 맞추는 방식으로 관리하면 불필요한 혼란을 줄일 수 있습니다.
AI는 이 과정에서 용어 혼용, 추적성 누락, 수치 불일치 후보를 빠르게 찾을 수 있습니다. 다만 최종 판단과 승인은 시스템·검증 엔지니어와 지정 책임자가 수행해야 합니다.
함께 읽으면 좋은 글
- SYS.4와 SYS.5 차이 — 시스템 통합 검증 vs 시스템 검증
- Automotive SPICE 4.0 SWE.4와 SWE.6 차이: AI 검증 준비 실무
- Automotive SPICE SYS.2에서 SYS.5 테스트 케이스 생성하기
- SIL·HIL·Bench 테스트 비교: 전동화 제어기 검증 환경 선택 기준
- 요구사항–테스트 양방향 추적성 작성법
글을 읽어보니, 제가 용어를 많이 헷갈리게 사용했네요... 용어부터 명확히 할 필요가 있을 것 같습니다.
답글삭제