개념
제품이 아니라 일하는 방식을 판정받는다
모듈 25 레슨 6에서 Automotive SPICE(이하 ASPICE)가 협력사를 심사하기 위한 프로세스 평가 모델 이라는 것, 프로세스 참조 모델에서 SWE.5·SWE.6이 V-모델의 어디에 앉는지, 능력 수준이 "한다"·"관리한다"·"표준이다"의 차이라는 것을 봤다. 이 모듈의 레슨 1~6은 기능안전 규격으로 제품의 증거 를 만들었다.
ASPICE 평가는 그 증거를 프로세스의 증거 로 다시 본다. 평가자(assessor)는 "이 소프트웨어가 안전한가"를 묻지 않는다. "이 조직이 검증 활동을 계획대로, 기준에 맞게, 추적 가능하게 수행하고 결과를 관리하는가"를 묻는다. 자동차 OEM이 협력사에게 ASPICE 능력 수준 2나 3을 요구하는 이유가 이것이다. 한 번 좋은 제품을 만든 것이 아니라 다음 프로젝트도 같은 방식으로 만들 것 이라는 증거를 원한다.
이 레슨은 시험 조직의 QA가 평가에서 직접 답하게 되는 SWE.4·SWE.5·SWE.6 을 중심으로, 원문의 기본 실천(Base Practice, BP)을 증거로 옮긴다.
PAM 4.0에서 달라진 것 — QA가 알아야 할 네 가지
ASPICE 프로세스 평가 모델·참조 모델 4.0은 VDA QMC 작업반 13이 2023년 11월 29일 발행했다. 3.1에서 옮겨 온 조직이 많아 두 판의 차이가 평가 대응에 영향을 준다.
| 변화 | 3.1 | 4.0 | QA 영향 |
|---|---|---|---|
| 산출물 개념 | 작업 산출물(work product) | 정보 항목(information item) | 문서 이름이 아니라 정보가 존재하는지 를 본다. 도구 안의 데이터도 정보 항목이 될 수 있다 |
| 추적성·일관성 | 별도 기본 실천 | 하나의 기본 실천으로 통합 ("일관성을 보장하고 양방향 추적성을 수립") | 링크만으로는 부족, 내용 일치까지 한 번에 평가 |
| 검증 프로세스 이름 | SWE.5 통합·통합 시험, SWE.6 적격성 시험 | SWE.5 컴포넌트 검증과 통합 검증, SWE.6 소프트웨어 검증 | "시험"이 "검증 수단(verification measure)"으로 넓어짐 — 리뷰·정적 분석·시뮬레이션 포함 |
| 프로세스 그룹 | — | 검증(VAL.1), 머신러닝 엔지니어링(MLE), 하드웨어 엔지니어링(HWE) 추가 | AI 기능이 있는 제품은 MLE 평가 범위 가능성 |
SWE.4·SWE.5·SWE.6의 공통 구조
세 프로세스는 거의 같은 뼈대를 공유한다. SWE.6(소프트웨어 검증)의 기본 실천을 기준으로 보자.
| BP | 이름 (요지) | 원문이 요구하는 핵심 |
|---|---|---|
| BP1 | 검증 수단 명세 | 기법, 합격·불합격 기준, 진입·종료 기준, 필요한 순서, 필요한 검증 인프라·환경 설정 |
| BP2 | 검증 수단 선택 | 회귀 검증 기준을 포함한 선택 기준으로 선택을 문서화. 선택은 릴리스 범위에 대해 충분한 커버리지 를 가져야 함 |
| BP3 | 통합 소프트웨어 검증 | 선택한 수단으로 수행, 합격·불합격 상태와 검증 수단 데이터를 기록 |
| BP4 | 일관성 보장·양방향 추적성 수립 | 검증 수단 ↔ 소프트웨어 요구사항, 검증 결과 ↔ 검증 수단 |
| BP5 | 결과 요약·전달 | 모든 관련 당사자에게 요약해 전달 |
SWE.4(단위 검증)는 대상이 상세 설계의 단위이고, 원문 주석이 정적 분석(MISRA 규칙 세트 등)·코드 리뷰·단위 시험을 예로 든다 — 레슨 4·5의 MISRA 준수 증거가 SWE.4의 증거가 된다. SWE.5는 BP가 일곱 개로, 통합 검증 수단(통합 순서·전제 조건 포함)과 컴포넌트 동작 검증 수단 을 따로 명세하고 소프트웨어 요소를 통합하면서 검증한다.
정보 항목과 QA 증거 대응
세 프로세스의 출력 정보 항목은 번호로 식별된다.
| 정보 항목 | 이름 | QA 조직의 실제 증거 예 |
|---|---|---|
| 08-60 | 검증 수단 | 시험 명세(시험 케이스와 합격 기준·진입/종료 기준·환경), 정적 분석 규칙 세트와 적용 범위, 리뷰 체크리스트 |
| 08-58 | 검증 수단 선택 세트 | 릴리스별 실행 대상 목록과 선택 근거(변경 영향 분석, 회귀 기준) |
| 03-50 | 검증 수단 데이터 | 실행 로그, 측정값, 커버리지 데이터, 정적 분석 원시 결과 |
| 15-52 | 검증 결과 | 합격·불합격 기록과 이상 목록, 결함 티켓 연결 |
| 13-51 | 일관성 증거 | 추적표와 일관성 검토 기록 |
| 13-52 | 전달 증거 | 결과 요약 보고서, 릴리스 회의록, 배포 목록 |
| (SWE.5) 06-50 | 통합 순서 지시 | 통합 계획·빌드 순서·전제 조건 |
정보 항목 개념의 실무 의미는 크다. 평가자는 "시험 결과 보고서라는 이름의 문서"를 찾는 것이 아니라 그 정보가 어딘가에 신뢰할 수 있게 존재하는지 를 본다. 테스트 관리 도구의 실행 기록, CI의 판정 레코드(모듈 38 레슨 4)도 요건을 채우면 증거가 된다. 대신 평가 중에 어디에 있는지 즉시 보여줄 수 있어야 한다.
추적성은 링크가 아니라 일관성이다
SWE.4~6의 BP4 주석은 공통으로 이렇게 말한다. 양방향 추적성은 일관성을 뒷받침하고 변경 영향 분석과 검증 커버리지 입증을 돕지만, 링크가 존재한다는 것만으로 정보가 서로 일관된다는 뜻은 아니다.
평가자가 실제로 확인하는 방식은 표본 추출 이다.
[평가자의 전형적인 일관성 확인]
1. 요구사항 SRS-SW-0412 를 무작위로 고른다 ("브레이크 신호 소실 200ms 이상 시 경고 램프 점등")
2. 연결된 검증 수단 SWT-0412-01 을 연다
→ 시험 조건이 180ms·220ms 인가? 기대 결과가 "경고 램프 점등"인가? 200ms 경계가 있는가?
3. 연결된 검증 결과를 연다
→ 결과가 해당 릴리스 베이스라인의 소프트웨어 버전인가? 합격인가? 불합격이면 SUP.9 티켓이 있는가?
4. 요구사항이 v3 에서 "150ms"로 바뀌었다면 → 시험 명세와 결과가 v3 기준으로 갱신됐는가?4번에서 가장 자주 약점이 나온다. 요구사항은 바뀌었는데 링크는 그대로 있고 시험 조건은 옛 값이다. 링크 수만 세는 추적표로는 절대 드러나지 않는다. 레슨 2의 "요구사항 기반 시험의 완전성"과 모듈 2 레슨 5의 추적성이 여기서 내용 대조 로 평가받는다.
대응 방법은 일관성 검토를 기록으로 남기는 것 이다. 요구사항 변경 시 연결된 검증 수단을 검토했다는 기록(검토자·일자·결과), 릴리스 전 표본 일관성 점검 기록이 13-51 일관성 증거가 된다.
검증 수단 선택 — "전부 돌렸다"도 근거가 필요하다
BP2는 선택을 문서화 하라고 한다. 원문 주석은 선택 기준의 예로 요구사항 우선순위, 지속적 개발, 변경에 따른 회귀 필요, 배포 릴리스의 의도된 용도(시험 벤치·시험 주행로·공공 도로)를 든다.
[검증 수단 선택 세트 — 릴리스 R2.3 (시험 주행로 배포)]
릴리스 범위: 요구사항 변경 14건 (브레이크 경고 로직 3, 진단 11), 버그 수정 6건
선택 기준:
- 변경·영향 요구사항에 연결된 검증 수단 전부 (변경 영향 분석 CIA-R2.3)
- 안전 관련(ASIL B 이상) 요구사항의 검증 수단 전부 — 변경 여부와 무관 (프로젝트 규칙)
- 그 외 요구사항은 스모크 세트 (시험 주행로 배포 조건)
- 공공 도로 배포 릴리스에서는 전체 세트 필수 (이번 릴리스 해당 없음)
선택 결과: SWT 1,842 중 612 선택, 제외 1,230 의 제외 근거: 위 기준
커버리지 판단: 릴리스 범위 요구사항 100% 에 검증 수단 선택됨, 안전 관련 100%"매번 전체를 돌리니 선택 근거가 필요 없다"는 답은 약하다. 전체를 돌리는 것 자체가 선택 기준 이고, 그 기준이 릴리스 범위에 충분하다는 판단을 기록해야 한다. 그리고 전체를 돌릴 수 없는 날(하드웨어 벤치 부족)이 오면 기준 없이 줄이게 된다. 모듈 38 레슨 4의 변경 영향 지도가 이 BP의 실무 도구다.
진입·종료 기준과 합격 기준
BP1의 진입·종료 기준 은 시험 조직에서 자주 비어 있다. 원문이 요구하는 것은 시험 케이스의 합격 기준만이 아니라 검증 수단 단위의 진입·종료 조건 이다.
SWT 세트 "브레이크 경고 HIL"
진입 기준: 소프트웨어 빌드가 SUP.8 베이스라인에 등록됨, HIL 벤치 교정 유효(교정일 기록),
SWE.5 통합 검증 결과에 이 컴포넌트의 치명 불합격 없음
종료 기준: 선택된 케이스 100% 실행, 불합격은 전부 SUP.9 티켓 등록·분류 완료,
재시험이 필요한 수정은 재실행 완료
환경: HIL 벤치 B-02 구성 기록, 차량 네트워크 시뮬레이션 모델 버전진입 기준에 베이스라인 등록 을 넣는 것이 SUP.8(형상관리)과 SWE.6을 잇는 고리다. 개발자 PC에서 빌드한 바이너리로 시험하면 결과가 어느 베이스라인의 것인지 증명할 수 없다.
지원 프로세스와의 연결 — SUP.1·SUP.9·SUP.10
QA 조직은 SWE 프로세스만이 아니라 지원 프로세스에서도 평가받는다.
| 프로세스 | QA와 맞닿는 기본 실천 (요지) | 흔한 약점 |
|---|---|---|
| SUP.1 품질보증 | BP1 독립성·객관성 보장 (자기 감시 금지), BP2 품질 기준 정의, BP3 산출물 품질 보증, BP4 프로세스 활동 품질 보증, BP5 요약·보고, BP6 부적합 해결, BP7 부적합 상위 보고 | 시험팀이 자기 시험 프로세스를 스스로 "품질보증"함 — 독립성 부족 |
| SUP.9 문제 해결 관리 | 문제 식별·기록, 원인·영향 분석, 긴급 조치 승인, 경보, 해결 착수, 종결까지 추적, 상태 보고 | 불합격 결과와 티켓의 연결 누락, 원인 분석 없이 "수정됨" 종결 |
| SUP.10 변경 요청 관리 | 변경 요청 식별·기록, 분석·평가, 구현 전 승인, 양방향 추적성, 구현 확인, 종결 추적 | 변경 요청과 영향받은 검증 수단 사이 추적 없음 |
| SUP.8 형상관리 | 형상 항목 식별, 수정 통제, 베이스라인 수립, 상태 보고, 완전성·일관성, 백업·복구 가용성 검증 | 시험 환경 구성(벤치·모델 버전)이 형상 항목이 아님 |
SUP.1 BP1의 원문 주석은 독립성 평가 입력으로 재무·조직 구조의 배치와 품질보증 대상 프로세스에 대한 책임 을 든다. 괄호 안의 "자기 감시 금지"가 핵심이다. 시험 리더가 시험 프로세스 준수를 스스로 점검하는 구조는 독립성 약점으로 평가될 수 있다. 조직이 작으면 교차 점검(다른 프로젝트의 QA가 점검)으로 대응한다.
판정 척도 — N·P·L·F와 비율
평가자는 각 프로세스의 과정 속성(Process Attribute, PA) 을 네 단계로 판정한다. PAM 4.0이 ISO/IEC 33020:2019에서 가져온 척도다.
| 판정 | 뜻 | 달성 비율 |
|---|---|---|
| N (Not achieved) | 달성 증거가 거의 없음 | 0% ~ 15% 이하 |
| P (Partially achieved) | 일부 접근과 일부 달성, 예측 불가한 측면 | 15% 초과 ~ 50% 이하 |
| L (Largely achieved) | 체계적 접근과 상당한 달성, 약점 일부 존재 가능 | 50% 초과 ~ 85% 이하 |
| F (Fully achieved) | 완전하고 체계적인 접근과 완전한 달성, 중대한 약점 없음 | 85% 초과 ~ 100% |
P와 L은 더 세분할 수 있다. P−(1532.5%)·P+(32.550%)·L−(5067.5%)·L+(67.585%).
능력 수준 결정 규칙
능력 수준은 과정 속성 판정의 조합으로 정해진다. 일반 규칙은 "해당 수준의 과정 속성은 L 또는 F, 그보다 낮은 수준의 과정 속성은 모두 F" 다.
| 능력 수준 | 필요한 판정 |
|---|---|
| 1 | PA 1.1 (과정 수행) L 또는 F |
| 2 | PA 1.1 F, PA 2.1 (수행 관리) L 또는 F, PA 2.2 (산출물 관리) L 또는 F |
| 3 | PA 1.1·2.1·2.2 F, PA 3.1 (프로세스 정의) L 또는 F, PA 3.2 (프로세스 전개) L 또는 F |
이 규칙의 함의가 평가 준비 전략을 정한다. 수준 2를 받으려면 PA 1.1이 F여야 한다. 즉 SWE.6의 기본 실천 수행 자체에서 약점이 크면(L), 계획·관리가 아무리 훌륭해도 수준 2가 안 된다. 반대로 BP는 모두 잘 수행하는데 계획·모니터링(PA 2.1)이나 산출물 관리(PA 2.2)가 약하면 수준 1에 머문다.
PA 2.1·2.2가 시험 조직에 요구하는 것은 대략 이렇다.
| 과정 속성 | 시험 조직의 증거 예 |
|---|---|
| PA 2.1 수행 관리 | 검증 목표와 전략, 일정·자원(HIL 벤치·인원) 계획, 계획 대비 진척 모니터링과 조정 기록, 관련 당사자 간 인터페이스(개발·통합·고객) 관리 |
| PA 2.2 산출물 관리 | 시험 명세·결과에 대한 요구사항(양식·필수 항목), 저장·통제 요구사항(버전·접근), 식별·저장·통제, 검토와 조정 기록 |
"계획 대비 진척 모니터링과 조정" 기록이 흔히 비어 있다. 일정이 밀렸을 때 무엇을 줄이거나 미루기로 했는지, 누가 결정했는지가 남아 있어야 PA 2.1의 증거가 된다. 모듈 4 레슨 4의 일정·종료 조건과 모듈 38 레슨 5의 결정 기록이 여기서 쓰인다.
평가 범위와 평가자
OEM이 요구하는 평가는 대개 VDA 범위 를 기준으로 한다. VDA 범위는 프로젝트 관리(MAN.3), 시스템 엔지니어링(SYS.25), 소프트웨어 엔지니어링(SWE.16), 품질보증·형상관리·문제 해결·
변경 요청 관리(SUP.1, SUP.8~10) 등을 기본으로 하며, 하드웨어·머신러닝 같은 확장 그룹을 플러그인 으로 더한다. 정확한 구성은 평가 계약과 VDA의 범위 정의 판본으로 확인한다.
사이버보안 프로세스는 별도의 ASPICE for Cybersecurity 모델로 평가하며, ISO/SAE 21434·UNECE R155(모듈 25 레슨 8)와 연결된다.
평가는 intacs 인증 평가자가 수행하는 것이 일반적이고, 평가자는 산출물·저장소 내용과 수행자·관리자 인터뷰 로 증거를 얻는다. VDA는 판정 일관성을 위해 평가 지침서(Automotive SPICE Guidelines)를 발행하며, 규칙·권고로 판정 간 일관성을 요구한다(예: 어떤 BP의 약점이 다른 BP·과정 속성 판정에 어떻게 반영되어야 하는지). 지침서도 판이 갱신되므로 평가 계약에 명시된 판을 확인한다.
모의 평가 — 평가자처럼 표본을 뽑는다
실제 평가 전에 모의 평가 를 하면 약점을 미리 찾을 수 있다. 핵심은 문서 목록 점검이 아니라 평가자처럼 표본을 뽑아 따라가는 것 이다.
[SWE.6 모의 평가 체크 시트 — 발췌]
BP1 시험 세트 3개 표본: 진입/종료 기준 [있음/없음] 합격 기준 [있음/없음] 환경 설정 [있음/없음]
BP2 최근 릴리스 2개: 선택 세트 [있음/없음] 선택 근거 [있음/없음] 릴리스 범위 대비 커버리지 판단 [있음/없음]
BP3 결과 표본 10건: 베이스라인 버전 일치 [n/10] 검증 수단 데이터(로그) 접근 가능 [n/10]
BP4 요구사항 표본 10건 (최근 변경 5 포함): 링크 [n/10] 내용 일치 [n/10] 변경 후 갱신 [n/5]
BP5 결과 요약 전달 기록: 대상자 [목록] 전달 증거 [있음/없음]
인터뷰 연습: "이 요구사항이 바뀌었을 때 시험은 누가 어떻게 갱신합니까?" — 수행자 두 명이 같은 답을 하는가마지막 줄이 중요하다. 인터뷰에서 수행자마다 다른 절차를 말하면 문서가 있어도 프로세스가 정의·전개되지 않은 것으로 읽힌다(PA 3.2 약점, 수준 2 목표라도 PA 1.1 신뢰도 하락).
흔히 발견되는 약점
| 약점 | 영향받는 판정 | 대응 |
|---|---|---|
| 시험은 있지만 합격 기준이 "정상 동작" | SWE.6 BP1 | 기대 결과를 관찰 가능한 값으로 |
| 추적 링크는 있지만 요구사항 변경 후 시험 미갱신 | BP4 | 변경 시 연결 검증 수단 검토를 SUP.10 흐름에 넣기 |
| 회귀 선택 근거 없음 | BP2 | 선택 기준 문서 + 릴리스별 선택 세트 |
| 결과가 어느 베이스라인인지 모름 | BP3, SUP.8 | 진입 기준에 베이스라인 등록, 결과에 빌드 ID |
| 불합격 결과와 문제 티켓 불연결 | BP3, SUP.9 | 불합격 → 티켓 자동 초안 (모듈 38 레슨 5) |
| 결과 요약이 대시보드에만 있고 전달 기록 없음 | BP5 | 릴리스별 요약 배포와 수신자 기록 |
| QA 점검을 시험 리더가 수행 | SUP.1 BP1 | 조직상 독립된 QA 또는 교차 점검 |
| 일정 지연 시 범위 축소 결정 기록 없음 | PA 2.1 | 조정 결정 기록 |
애자일·CI와 ASPICE
"우리는 애자일이라 ASPICE가 맞지 않는다"는 말을 자주 듣는다. ASPICE는 무엇을 달성해야 하는지 를 묻지 개발 방법론을 강제하지 않는다. SWE.5 원문 주석도 통합 전제 조건이 빅뱅 통합, 지속적 통합, 단계적 통합을 허용할 수 있다고 적는다. CI 환경에서는 오히려 증거를 자동으로 남기기 쉽다.
| BP | CI 환경의 증거 |
|---|---|
| BP2 선택 | 변경 영향 기반 테스트 선택 규칙(코드), 파이프라인 단계별 실행 대상 |
| BP3 수행·기록 | 파이프라인 실행 기록과 판정 레코드(커밋·환경·결과) |
| BP4 일관성 | 테스트 이름·태그의 요구사항 ID, 요구사항 변경 시 PR 체크로 연결 테스트 검토 강제 |
| BP5 전달 | 릴리스 후보별 자동 요약과 배포 기록 |
주의할 점은 CI 기록의 보존과 베이스라인 연결 이다. CI 도구가 실행 기록을 30일 후 지우면 평가 시점에 증거가 없다. 릴리스 베이스라인에 해당하는 실행 기록은 형상관리 대상 저장소로 옮겨 보존한다.
실무에서 왜 필요한가
자동차 전장 협력사에게 ASPICE 능력 수준은 수주 조건 이다. OEM이 수준 2나 3을 요구하고, 평가에서 약점이 나오면 개선 계획과 재평가 전까지 신규 프로젝트 참여가 제한될 수 있다. 평가 결과는 개발 조직 전체의 것이지만, SWE.4~6과 SUP.1·9에서 약점이 나오면 시험 조직의 증거 관리 가 직접 원인이 된다.
시험 경력자가 자동차 SW 테스터로 옮길 때 ASPICE는 "프로세스 문서 작업"으로 오해받기 쉽다. 실제로 평가가 보는 것은 합격 기준이 구체적인가, 회귀 선택에 근거가 있는가, 요구사항이 바뀌면 시험이 따라가는가, 결과가 어느 빌드의 것인가 — 좋은 시험 조직이 원래 해야 하는 일 이다. 면접에서 "모의 평가에서 요구사항 변경 후 미갱신 시험을 표본으로 찾아내 SUP.10 흐름에 검토 단계를 넣었다" 같은 이야기가 평가 대응 실습 경험을 보여준다.