Automotive SPICE 4.0 SWE.4와 SWE.6 차이: AI 검증 준비 실무

개발 산출물과 검증 활동을 양방향 화살표로 연결한 자동차 소프트웨어 V모델 개념도

이 글은 ChatGPT로 자동차 소프트웨어 테스트케이스 초안을 작성하는 7단계의 후속 글입니다.

같은 SIL 도구로 실행한 테스트라도 하나는 SWE.4, 다른 하나는 SWE.6일 수 있습니다. 두 프로세스는 장비나 테스트 규모가 아니라 무엇을 어떤 근거와 비교해 검증하는가로 구분하기 때문입니다.

SWE.4: 소프트웨어 단위와 상세설계의 일치 검증
SWE.6: 통합 소프트웨어와 소프트웨어 요구사항의 일치 검증
AI: 요구사항 분석, 테스트 초안, 추적성 누락 탐지 보조
사람: 기대값 확정, 적합성 판정, 안전·릴리스 승인

이 글은 Automotive SPICE 4.0을 기준으로 합니다. 3.1에서 SWE.6의 명칭은 Software Qualification Test였지만, 4.0에서는 Software Verification입니다. 실제 프로젝트에서는 계약상 적용 버전과 공식 PAM을 다시 확인해야 합니다.

안전 고지: 본문과 AI 출력은 검증 준비를 위한 보조 자료입니다. 자동차 안전·품질 관련 산출물의 승인이나 양산 적용에는 해당 분야 전문가와 지정 책임자의 검토가 필요합니다.

30초 요약: SWE.4와 SWE.6의 핵심 차이

[확인된 사실] Automotive SPICE 4.0에서 SWE.4의 직접 비교 기준은 소프트웨어 상세설계이고, SWE.6의 직접 비교 기준은 기능·비기능 정보를 포함한 소프트웨어 요구사항입니다.

상세설계
   ↓
소프트웨어 단위 ── SWE.4: 단위 ↔ 상세설계
   ↓
구성요소 및 통합 소프트웨어 ── SWE.5
   ↓
통합 소프트웨어 ── SWE.6: 통합 SW ↔ SW 요구사항
   ↑
소프트웨어 요구사항

따라서 다음과 같은 분류는 부정확합니다.

“SWE.4는 작은 테스트, SWE.6는 큰 테스트”
“코드 커버리지가 높으면 SWE.4가 완료된다”
“요구사항과 테스트 ID를 연결하면 추적성이 완료된다”

핵심은 검증 대상, 비교 기준, 기대 결과와 추적성 종단점입니다.

실무 요약: SWE.4~SWE.6 → SIL·가상 ECU 중심, SYS.4~SYS.5 → HIL·시스템 Bench 중심. 프로세스를 판정할 때는 검증 대상과 요구사항 기준을 함께 확인합니다.

Automotive SPICE 3.1과 4.0을 섞으면 안 되는 이유

SWE.6 명칭의 변화

프로세스	Automotive SPICE 3.1	Automotive SPICE 4.0
SWE.4	Software Unit Verification	Software Unit Verification
SWE.6	Software Qualification Test	Software Verification

4.0 기준 문서에서는 SWE.6를 계속 “Software Qualification Test”나 “소프트웨어 자격시험”으로 부르지 않는 편이 정확합니다. 해당 명칭은 구버전 문서나 마이그레이션을 설명할 때만 병기해야 합니다.

또한 3.1의 SWE.4 목적에는 비기능 소프트웨어 요구사항 준수 증거가 명시됐지만, 4.0의 목적은 상세설계와의 일치에 초점을 둡니다. 두 버전의 설명을 한 문장에 섞어서는 안 됩니다.

Output Information Items는 필수 문서 목록이 아니다

[확인된 사실] Automotive SPICE 4.0의 Output Information Items는 평가 시 확인할 정보의 지표입니다. 특정 문서 수나 템플릿을 강제하거나 실제 작업산출물과 1:1 대응한다는 의미가 아닙니다.

따라서 다음 표현은 피해야 합니다.

“SWE.4의 필수 문서는 상세설계서다.”
“표준이 지정한 문서 6종을 작성해야 한다.”

보다 정확한 표현은 다음과 같습니다.

SWE.4 수행에는 일반적으로 상세설계, 식별된 소프트웨어 단위, 검증 방안과 선정 기준에 해당하는 정보가 필요하다.

개별 합격 기준과 프로세스 평가 등급

개별 검증 방안의 pass/fail 기준과 프로세스 속성의 N/P/L/F 평가는 서로 다른 개념입니다. 이 글의 합격 기준은 리뷰·분석·테스트 결과를 판정하는 기준을 뜻합니다.

SWE.4 Software Unit Verification

목적과 검증 대상

[확인된 사실] SWE.4는 구현된 소프트웨어 단위가 소프트웨어 상세설계와 일치하는지 검증합니다. 정적 분석, 코드 리뷰, 단위 테스트 등이 가능한 검증 방안의 예입니다.

함수·클래스·모듈은 소프트웨어 단위의 실무 예시일 뿐, 표준이 모든 프로젝트에 동일한 단위 경계를 지정하는 것은 아닙니다.

일반적으로 필요한 정보

[실무 예시]

소프트웨어 상세설계
식별된 소프트웨어 단위와 인터페이스
입출력 및 오류 처리 규칙
검증 방안과 선정 기준
릴리스 범위
회귀 검증 기준
적용 가능한 코딩 규칙

이는 고정된 필수 문서 목록이 아니라 검증 준비에 필요한 정보의 예입니다.

검증 방안과 환경

[확인된 사실] SWE.4 검증 방안에는 필요한 검증 인프라가 포함돼야 합니다. 특정 SIL·HIL 환경을 일률적으로 의무화하지는 않습니다.

[실무 예시]

호스트 또는 타깃 기반 단위 테스트
스텁·목·드라이버를 이용한 테스트 하네스
정적 분석 도구
코드 및 상세설계 리뷰 도구

중요한 것은 환경 이름이 아니라 단위를 적절히 격리하고 입력과 상태를 제어하며 결과를 관찰할 수 있는지입니다.

판정과 추적성

검증 방안별 pass/fail 기준
진입·종료 기준
릴리스 범위에 따른 선정 근거
변경에 따른 회귀 검증 기준
소프트웨어 단위 ↔ 검증 방안
검증 방안 ↔ 검증 결과
예상과 다른 결과의 문제관리 연결

코드 커버리지는 검증 충분성을 검토하는 자료가 될 수 있지만, Automotive SPICE 4.0은 모든 프로젝트에 동일한 수치를 제시하지 않습니다. 목표는 적용 안전 표준, 고객 기준, 조직 절차와 프로젝트 계획에 따라 정해야 합니다.

SWE.6 Software Verification

목적과 검증 대상

[확인된 사실] SWE.6는 통합 소프트웨어가 기능·비기능 정보를 포함한 소프트웨어 요구사항과 일치하는지 검증합니다.

이는 시스템이나 실차 전체의 고객 요구사항 검증과 같지 않습니다. SWE.6의 직접 검증 기준은 소프트웨어 요구사항입니다.

일반적으로 필요한 정보

[실무 예시]

승인·식별된 소프트웨어 요구사항
통합 소프트웨어 구성
릴리스 범위
인터페이스와 운용 상태
환경 제약
검증 방안·기법·순서
환경 설정과 관찰 지점
회귀 검증 기준

일반적인 실무 검증 계층

[실무 기본 매핑] 이 글에서는 자동차 제어기 개발의 일반적인 검증 흐름을 다음과 같이 설명합니다.

프로세스 범위	일반적인 시험 환경	직접 비교 기준
SWE.4~SWE.6	SIL, 가상 ECU, Target SW Bench	소프트웨어 상세설계 및 소프트웨어 요구사항
SYS.4~SYS.5	HIL, System Bench, 실차·부품 시험	시스템 요구사항 및 시스템 동작

즉, SWE.4~SWE.6은 소프트웨어 검증 계층이므로 SIL 또는 가상 ECU 환경에서 운영하는 것이 일반적입니다. SYS.4~SYS.5는 시스템 통합 검증 계층이므로 HIL과 시스템 Bench를 주로 활용합니다.

주의: 위 매핑은 현장 검증 전략의 기본 구조입니다. Automotive SPICE는 HIL과 SIL을 프로세스의 필수 조건으로 지정하지 않으며, 최종 환경은 고객 요구사항과 프로젝트 검증 전략에 따릅니다.

판정과 추적성

조건과 자극
사전조건
관찰 지점
승인된 시간 및 허용오차
pass/fail 기준
진입·종료 기준
검증 순서
회귀 선정 근거
요구사항 ↔ 검증 방안 ↔ 검증 결과

요구사항에 수치나 시간 조건이 없다면 AI나 테스트 작성자가 임의로 보완해서는 안 됩니다. 이 경우 “추가 확인 필요”로 남겨야 합니다.

Automotive SPICE SWE.4와 SWE.6 비교표

항목	SWE.4	SWE.6
핵심 질문	단위가 상세설계대로 구현됐는가?	통합 소프트웨어가 요구사항을 충족하는가?
검증 대상	소프트웨어 단위	통합 소프트웨어
직접 비교 기준	소프트웨어 상세설계	소프트웨어 요구사항
일반적 입력 정보	상세설계, 단위, 인터페이스, 릴리스 범위	요구사항, 통합 SW 구성, 환경·인터페이스 정보
검증 방안 예	정적 분석, 리뷰, 단위 테스트	요구사항 기반 시험·측정·시뮬레이션·분석
환경 관점	단위의 격리·관찰·제어	요구 조건과 통합 동작의 재현
판정	방안별 pass/fail, 진입·종료 기준	방안별 pass/fail, 진입·종료 기준과 순서
직접 추적성	단위 ↔ 검증 방안 ↔ 결과	요구사항 ↔ 검증 방안 ↔ 결과
AI 보조	경계조건·단위 테스트 초안	요구사항 분해·시나리오 초안
사람 책임	기대값·스텁·충분성 승인	요구 해석·환경 대표성·릴리스 판단

입력 정보와 환경은 구현 예시입니다. Automotive SPICE가 특정 문서나 도구를 일률적으로 지정한다는 의미가 아닙니다.

출력 정보항목은 같아 보여도 내용이 다르다

4.0의 SWE.4와 SWE.6에는 공통적으로 다음 출력 정보항목이 제시됩니다.

Verification Measure
Verification Measure Data
Verification Measure Selection Set
Verification Results
Consistency Evidence
Communication Evidence

정보 유형	SWE.4	SWE.6
Verification Measure	단위·상세설계 기반 방안	요구사항 기반 통합 SW 검증 방안
Measure Data	분석 데이터, 단위 입력·로그	시험 입력, 환경 구성, 측정값·로그
Selection Set	릴리스 범위의 단위 검증 선정	릴리스 및 요구사항 기반 선정
Verification Results	단위 검증 결과	통합 소프트웨어 검증 결과
Consistency Evidence	단위와 방안의 의미 일치	요구사항과 방안의 의미 일치

전동화 제어기 가상 예시

[가상 예시] 다음 내용은 개념 설명용이며 실제 ECU, 고객 요구사항 또는 차량 사양과 무관합니다.

가상 요구사항

측정 입력이 정의된 유효 범위를 벗어나면 제어 기능은 제한 상태로 전환하고 진단 상태를 기록해야 한다.

SWE.4 관점

상세설계와 개별 단위의 구현을 비교합니다.

범위 판정 함수의 경계 처리
상태 전환 함수의 분기
오류 상태 설정 단위
데이터형·포화·초기화 처리
반환값과 내부 상태 변화
하위 함수 호출과 전달 인자
스텁·목이 단위 동작을 왜곡하는지 여부

항목	가상 예시
입력	측정값, 유효성 상태
사전조건	초기화 완료 및 정상 상태
실행	범위 판정 단위 1회 호출
출력	범위 상태와 제한 요청
판정	상세설계의 비교 및 상태 규칙과 일치
추가 확인	경계 포함 여부, 데이터형, 초기값

SWE.6 관점

통합 소프트웨어의 관찰 결과를 요구사항과 비교합니다.

정상·경계·범위 초과 입력 제공
제한 상태 전환 확인
진단 상태 기록 확인
복귀 조건 확인
다른 기능과의 상호작용
정의된 시간 조건의 충족 여부

항목	가상 예시
입력	정상 입력 후 범위 밖 입력 제공
사전조건	통합 SW가 정상 운전 상태
관찰	제한 상태, 진단 상태, 외부 출력
판정	요구사항의 동작과 정의된 시간 조건 충족
추가 확인	허용오차, 디바운스, 복귀 조건

같은 기능을 다루더라도 SWE.4는 내부 단위와 상세설계, SWE.6는 통합 동작과 소프트웨어 요구사항을 기준으로 증거를 만듭니다.

양방향 추적성은 링크 개수가 아니다

Automotive SPICE 4.0의 직접 추적 구조는 다음과 같습니다.

SWE.4

상세설계에 정의된 소프트웨어 단위
        ↕
검증 방안
        ↕
검증 결과

SWE.6

소프트웨어 요구사항
        ↕
검증 방안
        ↕
검증 결과

[확인된 사실] 링크의 존재만으로 정보 간 일관성이 보장되지는 않습니다. 추적성은 변경 영향 분석, 일관성 검토와 검증 커버리지 입증을 지원하는 수단입니다.

최소한 다음 항목을 점검해야 합니다.

검증 방안이 없는 단위 또는 요구사항
상위 근거가 없는 고아 검증 방안
실행 결과가 없는 검증 방안
링크는 있지만 조건·입력·기대 결과가 불일치하는 항목

AI는 누락과 의미 불일치 후보를 찾을 수 있지만, 링크의 기술적 타당성은 담당자가 확인해야 합니다.

AI가 지원할 수 있는 안전한 범위

권장 업무

요구사항의 조건·트리거·동작·예외·시간 제약 분해
모호성 및 누락 후보 탐지
정상·경계·비정상 테스트 초안
상세설계 기반 단위 검증 방안 후보 생성
고아 링크, 결과 누락, 중복·상충 후보 탐지
비식별 로그 요약
리뷰 질문과 체크리스트 작성

AI에 맡기지 말아야 할 판단

요구사항의 최종 해석과 승인
기대값과 pass/fail 기준 확정
안전 상태 및 결함 영향 판정
환경 대표성과 검증 충분성 승인
프로세스 적합성 자체 판정
릴리스 및 양산 승인

안전한 실무 절차

단계	AI 입력	AI 출력	사람이 확인할 내용
1. 범위 확정	적용 버전, 검증 수준	용어·범위 점검표	계약 버전과 프로세스 경계
2. 근거 분석	비식별 요구사항·설계	조건·모호성 후보	의도와 승인 근거
3. 테스트 초안	승인 정보, 환경 제약	정상·경계·오류 후보	기대값 출처와 충분성
4. 추적성 점검	익명 ID와 링크	누락·고아·불일치 후보	의미적 타당성
5. 결과 분석	비식별 로그와 기준	이상 구간과 질문	원본 로그·구성·시간축
6. 승인 준비	초안과 원본 증적	누락 체크리스트	지정 책임자의 최종 판정

비식별 입력
   ↓
AI 초안·누락 후보
   ↓
기술 담당자 검토 및 수정
   ↓
원본 근거와 추적성 확인
   ↓
지정 책임자 승인

복사해 쓰는 AI 프롬프트

아래 템플릿은 비식별 데이터에만 사용하십시오. 출력은 공식 검증 자산이 아니라 검토 전 초안입니다.

SWE.4 단위 검증 초안

기준: Automotive SPICE 4.0 SWE.4
역할: 소프트웨어 단위 검증 준비를 보조하며 최종 적합성을 판정하지 않는다.

입력:
- 비식별화된 단위 ID
- 상세설계
- 입출력과 데이터형
- 상태 및 사전조건
- 오류 처리 규칙

작업:
1. 상세설계에서 검증 가능한 동작을 추출하라.
2. 정적 분석, 리뷰, 단위 테스트 후보를 제안하라.
3. 각 항목에 설계 근거 ID, 사전조건, 입력, 실행 절차,
   기대 결과, pass/fail 초안, 스텁·목 필요 여부를 표시하라.
4. 입력에 없는 수치나 동작을 만들지 마라.
5. 불충분한 정보는 “추가 확인 필요”로 표시하라.
6. 안전 적합성이나 검증 완료 여부를 판정하지 마라.

SWE.6 요구사항 기반 검증 초안

기준: Automotive SPICE 4.0 SWE.6
역할: 통합 소프트웨어 검증 방안의 초안을 작성하며 승인 결정을 하지 않는다.

입력:
- 비식별화된 요구사항 ID와 문장
- 운용 상태와 인터페이스
- 입력 범위와 환경 제약
- 알려진 오류 조건

작업:
1. 요구사항을 조건, 트리거, 동작, 출력, 시간 제약, 예외로 분해하라.
2. 기능 정보와 비기능 정보를 구분하라.
3. 정상, 경계, 비정상, 상태 전이, 회귀 검증 후보를 작성하라.
4. 필요한 환경, 관찰점, 자극, 기대 결과와 pass/fail 초안을 작성하라.
5. 근거 없는 수치나 안전 동작을 생성하지 마라.
6. 기대 결과를 확정할 수 없으면 “추가 확인 필요”로 표시하라.
7. 최종 합격이나 프로세스 적합성을 판정하지 마라.

양방향 추적성 점검

역할:
추적성 데이터의 누락과 의미 불일치 후보를 찾는 검토 보조 도구다.
링크 존재만으로 일관성이나 적합성을 판정하지 않는다.

입력:
A. 요구사항 또는 소프트웨어 단위 목록
B. 검증 방안 목록
C. 검증 결과 목록
D. 현재 추적 링크

검사:
1. 검증 방안이 없는 상위 항목을 찾아라.
2. 상위 근거가 없는 고아 검증 방안을 찾아라.
3. 결과가 없는 검증 방안을 찾아라.
4. 변경·폐기된 항목과 연결된 링크를 찾아라.
5. 조건, 입력 범위, 기대 결과의 의미 불일치 후보를 찾아라.
6. 확실하지 않은 내용은 결함으로 단정하지 말고 리뷰 후보로 분류하라.
7. SWE.4와 SWE.6 결과를 분리하라.

사람 검토 체크리스트

공통

[ ] 적용 버전과 프로세스 명칭이 일치하는가?
[ ] 검증 대상과 직접 비교 기준이 식별됐는가?
[ ] 릴리스 구성이 명확한가?
[ ] 기대 결과가 승인된 근거에서 도출됐는가?
[ ] pass/fail 및 진입·종료 기준이 판정 가능한가?
[ ] 환경이 검증 목적에 적합한가?
[ ] 회귀 선정 근거가 기록됐는가?
[ ] 결과·이슈·원본 로그가 연결됐는가?
[ ] 추적 링크의 의미적 일관성을 확인했는가?
[ ] AI가 수치나 요구사항을 임의 생성하지 않았는가?
[ ] 모델·프롬프트·입력 버전이 기록됐는가?
[ ] 검토자와 승인 이력이 남아 있는가?

SWE.4

[ ] 단위 경계가 상세설계와 일치하는가?
[ ] 스텁·목이 실제 동작을 왜곡하지 않는가?
[ ] 상세설계와 기대값이 일치하는가?
[ ] 필요한 정적 분석·리뷰·단위 테스트 조합을 선택했는가?

SWE.6

[ ] 기능·비기능 요구사항이 검증 범위에 포함됐는가?
[ ] 환경이 요구 조건을 대표하는가?
[ ] 정상·경계·비정상·상태 전이를 검토했는가?
[ ] 요구 조건과 관찰 결과를 직접 비교할 수 있는가?

한계·보안·안전 주의사항

회사명, 고객명, 프로젝트 코드와 실제 소스코드를 외부 AI에 입력하지 않습니다.
실차 사양, 보안키, 취약점, 개인정보와 미공개 결함 로그를 입력하지 않습니다.
조직이 승인한 서비스와 데이터 보존 정책을 확인합니다.
AI 출력과 원본 검증 증적을 분리하고 원본을 덮어쓰지 않습니다.
모델·프롬프트·입력 버전과 검토자를 기록합니다.
AI가 제시한 수치·기대값·추적 링크는 승인된 원본과 대조합니다.
실제 타깃의 타이밍, 전기적 고장 반응과 환경 대표성은 AI 문서 분석만으로 입증할 수 없습니다.
AI 결과를 전문가 검토 없이 안전·품질 판단이나 양산 승인에 사용하지 않습니다.

자주 묻는 질문

SWE.4는 단위 테스트만 의미하나요?

아닙니다. Automotive SPICE 4.0은 정적 분석, 코드 리뷰와 단위 테스트 등을 검증 방안의 예로 제시합니다.

SWE.6는 어떤 환경에서 수행하나요?

SWE.6는 SIL, 가상 ECU, Target SW Bench 등에서 수행할 수 있습니다. HIL도 사용할 수 있지만, 시험 장비의 이름만으로 SWE.6와 SYS.4·SYS.5를 구분해서는 안 됩니다. 검증 대상과 직접 비교 기준으로 판단해야 합니다.

코드 커버리지 100%가 SWE.4의 공통 기준인가요?

아닙니다. Automotive SPICE 4.0은 모든 프로젝트에 동일한 코드 커버리지 수치를 제시하지 않습니다.

추적 링크가 있으면 일관성도 충족되나요?

아닙니다. 링크의 조건과 기대 결과가 상위 근거에 부합하는지 별도로 확인해야 합니다.

AI가 만든 테스트를 바로 공식 증거로 등록해도 되나요?

권장하지 않습니다. 요구 근거, 기대값, 환경, 구성과 추적성을 담당자가 확인하고 조직 절차에 따라 승인해야 합니다. AI 생성물의 별도 인정 조건은 공개 PAM만으로 일률적으로 확정할 수 없어 추가 확인 필요입니다.

결론

SWE.4와 SWE.6는 테스트 크기나 실행 장비가 아니라 검증 대상과 직접 비교 기준으로 구분합니다. SWE.4는 소프트웨어 단위와 상세설계를, SWE.6는 통합 소프트웨어와 소프트웨어 요구사항을 연결합니다.

AI는 테스트 초안과 양방향 추적성 점검을 보조할 수 있지만 적합성 판단자는 아닙니다. 프로젝트 적용 전 공식 PAM, 계약 버전과 조직·고객 기준을 확인하고, 안전·품질 결과는 반드시 전문가와 지정 책임자가 승인해야 합니다.

검증된 참고자료

SIL·HIL·Bench 테스트 비교: 전동화 제어기 검증 환경 선택 기준 →