개념
제품을 보는 표준, 일하는 방식을 보는 표준
이 모듈의 앞 레슨들은 대부분 만들어진 것 을 봤다. ISO/IEC 25010은 제품이 갖춰야 할 품질 특성을 정의했고, ISO 26262·IEC 62304·DO-178C는 그 제품이 고장 났을 때 사람이 다치지 않는지를 따졌다. 이 레슨의 표준들은 질문 자체가 다르다. 제품을 보지 않고 "당신들은 어떻게 일하는가" 를 묻는다.
왜 그런 질문이 따로 필요한지는 자동차 부품 납품 상황을 떠올리면 납득된다. 완성차 업체가 협력사에서 받는 것은 샘플 한 개가 아니라 수년에 걸쳐 수십 번 변경될 소프트웨어다. "이번에 받은 물건이 좋았다"는 사실은 다음 변경분도 좋으리라는 보장이 되지 못한다. 보장을 만드는 것은 결과가 아니라 결과를 반복해서 만들어내는 방식 이다. 그래서 구매자는 제품 규격과 별개로 "이 회사가 요구사항을 어떻게 관리하고 검증하며 그 근거를 어떻게 남기는가"를 심사한다.
이 레슨의 세 표준 — Automotive SPICE, ISO/IEC 20246, ISO/IEC 33063 — 은 각각 개발 프로세스, 정적 테스트 활동, 테스트 프로세스라는 서로 다른 대상에 이 질문을 던진다.
Automotive SPICE — 협력사를 심사하기 위한 모델
Automotive SPICE(줄여서 A-SPICE)는 독일 자동차산업협회(VDA)의 품질관리센터 (VDA QMC)가 관리하는 프로세스 평가 모델이다. 뿌리는 ISO/IEC 330xx 계열 (그 전신은 ISO/IEC 15504, 별칭이 SPICE다)의 프로세스 평가 프레임워크이고, A-SPICE는 그것을 자동차 임베디드 소프트웨어 개발에 맞게 구체화한 판 이다.
가장 중요한 성격은 이것이 구매자가 공급자를 심사하기 위해 쓰는 도구 라는 점이다. 완성차 업체(OEM)가 부품 협력사(Tier 1)를 평가하고, 그 결과가 수주 조건에 직접 연결된다. 그래서 A-SPICE 대응은 품질 부서만의 일이 아니라 영업·개발·QA가 함께 걸리는 사업적 사안이 된다.
| 제품 규격 (예: ISO/IEC 25010, ISO 26262) | 프로세스 평가 모델 (A-SPICE) | |
|---|---|---|
| 보는 대상 | 만들어진 결과물 | 결과물을 만든 방식 |
| 던지는 질문 | 이 제품이 기준을 만족하는가 | 이 조직이 신뢰할 만하게 일하는가 |
| 증거 | 측정값, 테스트 결과, 안전 논증 | 계획서·산출물·기록과 그 일관성 |
| 실패했을 때 | 제품을 고친다 | 일하는 방식을 고친다 |
| 주로 누가 요구하나 | 인증기관, 규제기관 | 고객사(OEM), 상위 협력사 |
즉 A-SPICE 심사에서 증명해야 하는 것은 "우리 제품이 좋다"가 아니라 "우리가 일하는 방식이 신뢰할 만하다" 는 명제다. 심사원은 완성된 ECU를 뜯어보지 않는다. 요구사항 문서와 아키텍처 설계, 테스트 사양과 실행 기록을 펼쳐놓고 그것들이 서로 맞물리는지를 본다.
프로세스 참조 모델 — SWE.5와 SWE.6이 앉는 자리
A-SPICE는 개발 활동을 프로세스 그룹으로 나눈다. 시스템 엔지니어링(SYS), 소프트웨어 엔지니어링(SWE), 지원 프로세스(SUP — 형상관리·문제해결·변경관리 등), 관리 프로세스(MAN — 프로젝트 관리·위험 관리) 등이다. 테스트 엔지니어가 가장 직접적으로 관계되는 것은 SWE 그룹의 뒷부분이다.
- SWE.4 소프트웨어 유닛 검증 — 개별 유닛이 상세 설계대로 동작하는지 확인한다
- SWE.5 소프트웨어 통합 및 통합 테스트 — 유닛을 아키텍처 설계에 따라 통합하고, 통합된 소프트웨어가 아키텍처 설계(특히 인터페이스)에 부합하는지 검증한다
- SWE.6 소프트웨어 검증(자격 테스트) — 통합이 끝난 소프트웨어가 소프트웨어 요구사항을 만족하는지 검증한다
이 번호들은 V-모델 위에 그대로 대응된다. 왼쪽 내려가는 축에서 만든 산출물이 오른쪽 올라가는 축에서 각각 짝을 이루는 검증 활동을 갖는 구조다.
SWE.1 소프트웨어 요구사항 분석 ──────────── SWE.6 소프트웨어 검증(자격 테스트)
SWE.2 소프트웨어 아키텍처 설계 ────────── SWE.5 소프트웨어 통합 및 통합 테스트
SWE.3 상세 설계 및 유닛 구현 ────────── SWE.4 소프트웨어 유닛 검증이 그림이 주는 실무적 함의는 분명하다. 오른쪽 활동은 왼쪽 산출물을 기준으로 평가된다. SWE.6의 테스트 케이스는 소프트웨어 요구사항에서 도출되어야 하고, SWE.5의 테스트 케이스는 아키텍처 설계의 인터페이스에서 도출되어야 한다. "통합 테스트인데 요구사항 문장을 그대로 케이스로 옮겨 적었다"면 그건 짝이 어긋난 것이고, 심사에서 지적된다.
그래서 SWE.5와 SWE.6이 공통으로 요구하는 것은 대체로 이런 항목들이다 — 테스트 전략과 회귀 전략, 테스트 사양의 작성, 실행 결과의 기록, 그리고 요구사항·설계·테스트 케이스·결과 사이의 양방향 추적성 이다. 추적성은 모듈 2(레슨 5)에서 배운 그 개념이고, 여기서는 그것이 심사에서 직접 확인되는 필수 산출물이 된다.
각 프로세스의 정확한 명칭, 기본 실무(Base Practice) 목록, 요구되는 산출물의 세부 정의는 PAM(Process Assessment Model)의 판본(3.1, 4.0 등)에 따라 달라진다. 실제 프로젝트에서는 반드시 계약에 명시된 판본의 원문을 확인하고, 여기 적힌 요약을 그대로 인용하지 마라.
능력 수준 — "한다"와 "관리한다"와 "표준이다"의 차이
A-SPICE는 각 프로세스에 대해 능력 수준(Capability Level) 을 매긴다. 성숙도라는 개념 자체와 계단식 모델의 성격은 모듈 7(레슨 6)에서 TMMi·TPI Next로 이미 다뤘으니, 여기서는 그 계단이 실무에서 무엇이 달라지는 것을 뜻하는지 만 짚는다.
| 수준 | 대략의 이름 | 현장에서 무엇이 달라지는가 |
|---|---|---|
| 0 | Incomplete | 그 활동이 사실상 없거나, 있어도 목적을 달성하지 못한다 |
| 1 | Performed | 어쨌든 한다. 결과물은 나온다. 다만 사람마다 방식이 다르고 기록이 들쭉날쭉하다 |
| 2 | Managed | 계획하고, 담당과 일정을 정하고, 산출물을 형상관리하고, 결과를 검토한다 |
| 3 | Established | 조직 표준 프로세스가 정의되어 있고, 각 프로젝트는 그것을 테일러링해 쓴다 |
| 4~5 | Predictable / Innovating | 프로세스를 정량적으로 관리하고, 그 데이터에 근거해 개선한다 |
현장에서 체감이 가장 큰 구간은 1에서 2로 넘어가는 지점이다. 레벨 1과 2를 가르는 것은 "테스트를 하느냐"가 아니라 "누가, 언제, 어떤 기준으로 무엇을 테스트했고, 그 근거가 남아 있느냐" 다. 성실하게 테스트하고 있어도 기록이 각자의 로컬 스프레드시트와 메신저에만 남는다면 레벨 2를 주장하기 어렵다.
2에서 3으로 넘어가는 것은 성격이 또 다르다. "이 팀이 잘하는 것"을 "회사가 그렇게 하기로 정해둔 것"으로 옮기는 일이다. 이 단계에서는 조직 표준 프로세스, 테일러링 지침, 그리고 프로젝트가 그 표준을 따랐다는 증거가 필요해진다. 모듈 8(레슨 3)에서 본 조직 테스트 프로세스·테스트 정책이 정확히 이 층위의 산출물이다.
실무에서 OEM은 보통 "주요 프로세스에 대해 능력 수준 2 이상" 같은 형태로 목표를 제시한다. 다만 어느 프로세스에 어느 수준을 요구하는지, 각 수준의 프로세스 속성이 무엇을 요구하는지는 고객사와 판본마다 다르다. 이건 외워서 답할 문제가 아니라 계약 문서와 PAM 원문에서 확인할 문제다.
ISO 26262와 A-SPICE — 왜 둘 다 요구받는가
레슨 4에서 본 ISO 26262는 기능안전 규격이다. 제품이 오작동해도 사람이 다치지 않게 하는 것이 목적이고, ASIL 등급이 요구되는 검증의 강도를 결정한다. A-SPICE는 그 제품을 만든 조직의 프로세스 역량을 본다. 목적이 다르므로 둘 중 하나가 다른 하나를 대체하지 못한다.
| ISO 26262 | Automotive SPICE | |
|---|---|---|
| 목적 | 기능안전 — 위험을 허용 가능한 수준으로 | 프로세스 역량 — 반복 가능한 개발 |
| 대상 | 제품(과 그 안전 논증) | 조직의 일하는 방식 |
| 강도를 정하는 축 | ASIL 등급 (레슨 4) | 능력 수준 |
| 대표 산출물 | 안전 목표, 안전 사례, 위험 분석 | 계획서, 사양, 추적성, 검토 기록 |
| 요구하는 쪽 | 규제·법적 책임, OEM | OEM의 구매·품질 부서 |
자동차 협력사의 현실은 둘 다 요구받는다 는 것이다. 다행히 두 표준이 요구하는 것은 상당 부분 겹친다. 요구사항 추적성, 검증 계획, 형상관리, 리뷰, 변경 관리는 양쪽 모두의 기둥이다. 그래서 잘 설계된 조직은 프로세스를 두 벌 운영하지 않는다. 하나의 개발 프로세스에서 나온 산출물이 양쪽 심사의 증거로 동시에 쓰이도록 설계한다.
QA 입장에서 이 관점은 실무 습관으로 번역된다. 테스트 계획서를 한 장 쓸 때 "이 문서가 26262의 어떤 검증 요구를 만족시키고, A-SPICE의 어느 프로세스의 증거가 되는가"를 함께 생각하는 것이다. 이 감각이 없으면 같은 내용을 형식만 바꿔 두 번 쓰는 낭비가 생긴다.
ISO/IEC 20246 — 리뷰를 표준이 규정한다는 것
모듈 2(레슨 6)에서 리뷰 회의에 어떻게 참여하고 어떤 질문을 준비할지는 이미 익혔다. 여기서 볼 것은 진행법이 아니라, 그 활동을 국제 표준이 어떤 틀로 규정하는가 다.
ISO/IEC 20246은 작업 산출물 리뷰(work product review)를 다루는 표준이다. 여기서 "작업 산출물"은 코드만이 아니다. 요구사항 명세, 아키텍처 설계, 테스트 계획과 테스트 케이스, 사용자 매뉴얼까지 개발 과정에서 만들어지는 모든 문서가 대상이 된다. 프로그램을 실행하지 않고 산출물을 검토해 결함을 찾기 때문에 이 활동을 정적 테스트(static testing) 라고 부른다.
표준이 하는 일은 크게 세 가지로 정리된다.
- 용어를 통일한다. "리뷰 좀 봐주세요"라는 말이 회사마다, 팀마다 전혀 다른 무게로 쓰이는 문제를 막는다.
- 리뷰 유형과 형식성 수준을 정의한다. 무엇을 워크스루라 부르고 무엇을 인스펙션이라 부를지에 공통 기준을 준다.
- 역할·절차·기법을 정의한다. 누가 무엇을 하고, 어떤 순서로 진행하며, 어떤 방식으로 결함을 찾을지(체크리스트 기반, 시나리오·퍼스펙티브 기반 등)를 규정한다.
세 번째가 표준다운 부분이다. 리뷰 기법을 이름 붙여 정의한다는 것은 "각자 알아서 꼼꼼히 보자"가 아니라 "이 관점으로 이 항목들을 확인하자"로 바꾼다는 뜻이다. 같은 문서를 다른 사람이 봐도 비슷한 결함이 나오게 만드는 것이 목적이다.
형식성의 스펙트럼 — 표준의 눈으로 다시 보기
리뷰 유형은 형식성과 비용에 따라 한 줄 위에 놓인다. 비공식 리뷰 → 워크스루 → 기술 리뷰 → 인스펙션 순서다. 각 유형이 실제로 어떻게 진행되는지는 모듈 2에서 다뤘으니, 여기서는 형식성이 올라갈 때 무엇이 추가되는가 에 초점을 둔다.
| 유형 | 형식성 | 사전 준비 | 남는 기록 | 상대 비용 |
|---|---|---|---|---|
| 비공식 리뷰 | 낮음 | 없음 | 거의 없음 (구두·메신저) | 매우 낮음 |
| 워크스루 | 낮음~중간 | 선택 | 메모 수준 코멘트 | 낮음 |
| 기술 리뷰 | 중간~높음 | 필요 | 기술적 판단과 근거 | 중간 |
| 인스펙션 | 높음 | 필수 (각자 사전 검토) | 결함 목록·측정치·종료 판정 | 높음 |
이 표에서 오른쪽 두 열이 핵심이다. 형식성이 올라간다는 것은 곧 결과가 재현 가능해지고 기록으로 남는다 는 뜻이고, 기록으로 남는 순간 그것은 A-SPICE나 ISO 26262 심사의 증거가 된다. 비공식 리뷰는 가치가 없어서가 아니라 남는 것이 없어서 증거가 되지 못한다.
역할 구분(모더레이터·작성자·리뷰어·기록자)도 같은 관점으로 다시 볼 수 있다. 표준이 역할과 절차를 정의하는 이유는 회의를 격식 있게 만들기 위해서가 아니라, 리뷰의 품질을 특정 사람이 아니라 프로세스에 귀속시키기 위해서다. 꼼꼼한 선배 한 명이 있어서 결함이 잡히는 조직은 그 사람이 이직하면 품질이 무너진다. 모더레이터가 진행하고, 리뷰어가 정해진 체크리스트로 보고, 기록자가 지적사항을 남기고, 종료 기준으로 판정하는 절차가 있으면 사람이 바뀌어도 결과의 편차가 줄어든다. 표준이 노리는 것은 그 편차 감소다.
정적 테스트가 먼저이고 더 싼 이유
정적 테스트가 동적 테스트보다 우선인 논리는 두 갈래다.
첫째, 시점이다. 동적 테스트는 실행 가능한 코드가 있어야 시작할 수 있다. 반면 리뷰는 요구사항 문서가 한 장 나온 순간부터 가능하다. 결함이 늦게 발견될수록 수정 비용이 커진다는 원리(모듈 1에서 본 결함 비용 곡선)를 그대로 적용하면, 가장 이른 시점에 쓸 수 있는 검출 수단이 곧 가장 싼 검출 수단이다. 요구사항 문장 하나의 모순은 리뷰에서 잡으면 문장 수정으로 끝나지만, 통합 테스트에서 드러나면 코드·테스트 케이스·문서·일정이 함께 흔들린다.
둘째, 검출 가능한 결함의 종류가 다르다. 동적 테스트는 "실행했더니 기대와 다르다"만 찾는다. 요구사항의 누락, 문장 사이의 모순, 명세되지 않은 예외, 읽기 어려운 구조, 코딩 표준 위반은 실행으로 드러나지 않는다. 애초에 기대값이 정해지지 않은 상태는 동적 테스트의 검출 대상이 아니다. 정적 테스트를 예비 단계가 아니라 독립된 검출 수단 으로 봐야 하는 이유다.
A-SPICE와 ISO 26262가 리뷰를 반복해서 요구하는 것도 같은 맥락이다. 안전이 걸린 제품에서 요구사항 결함을 코드 실행 단계까지 끌고 가는 것은 비용 문제 이전에 위험 문제다.
ISO/IEC 33063 — 29119를 기준자로 삼는 평가 모델
ISO/IEC 330xx 계열은 프로세스 평가의 공통 뼈대를 제공한다. 용어와 개념 (33001), 능력 수준의 측정 프레임워크(33020) 같은 것들이다. 그 뼈대 위에 도메인별 평가 모델이 얹힌다. A-SPICE가 자동차 도메인의 적용판이라면, ISO/IEC 33063은 소프트웨어 테스팅 도메인의 적용판 이다.
핵심은 이 모델이 기준으로 삼는 프로세스 참조 모델이 무엇이냐다. 답은 ISO/IEC/IEEE 29119-2 — 모듈 8(레슨 3~5)에서 다룬 조직·관리·동적 테스트 프로세스의 3계층 구조다. 관계를 한 줄로 정리하면 이렇다.
29119-2 : 테스트 프로세스는 이렇게 생겼다 (참조 모델 = 기준자)
33063 : 당신 조직은 그 프로세스를 어느 수준으로 수행하는가 (평가 모델 = 재는 방법)이미 29119를 도입한 조직이라면 33063은 자연스러운 다음 단계가 된다. 쓰고 있는 프로세스 정의를 그대로 평가 기준으로 삼기 때문이다.
배경으로 하나 더 알아둘 것은 이 표준이 한국 전문가들이 주도해 제정한 것으로 알려져 있다 는 점이다. 그래서 국내 공공·SI 영역에서 33063이라는 번호를 만날 가능성이 다른 나라보다 상대적으로 높다.
모듈 7(레슨 6)에서 배운 TMMi와의 차이는 짧게 대비하면 충분하다.
| TMMi | ISO/IEC 33063 | |
|---|---|---|
| 계보 | CMMI 계열 | ISO/IEC 330xx 계열 |
| 기준이 되는 프로세스 | TMMi가 자체 정의한 프로세스 영역 | ISO/IEC/IEEE 29119-2의 테스트 프로세스 |
| 결과 표현 | 조직 전체를 대표하는 단계형 레벨 | 프로세스별 능력 수준 |
| 생태계 | TMMi Foundation의 인증·평가자 체계 | ISO 계열 평가 프레임워크 |
둘 중 무엇이 우월한지를 따지는 것은 의미가 없다. 우리 조직이 이미 어떤 언어를 쓰고 있는지 — CMMI 계열의 성숙도 언어인지, ISO 29119의 프로세스 언어인지 — 가 선택을 사실상 결정한다.
심사를 준비할 때 QA가 실제로 하는 일
이 표준들을 실무에서 만나는 순간은 대개 심사(assessment)나 감사(audit)를 앞두고서다. 진행은 보통 사전 자료 제출 → 담당자 인터뷰 → 산출물 확인 → 판정의 흐름을 따른다. 이때 심사원이 실제로 확인하는 것은 문서의 존재 자체가 아니라 문서와 실제 수행의 일치 다.
QA가 준비 국면에서 하는 일은 대략 네 가지다.
- 증거 자료 정리 — 테스트 계획, 테스트 사양, 실행 기록, 결함 이력, 추적성 매트릭스가 버전·일자와 함께 남아 있는지 모은다
- 프로세스 문서와 실제 수행의 대조 — 절차서에 "테스트 케이스는 리뷰를 거친다"라고 써두었는데 리뷰 기록이 없다면 그 자체가 부적합 항목이 된다
- 인터뷰 준비 — 담당자가 자기 일을 절차서의 언어로 설명할 수 있는지 확인한다. 일은 제대로 했는데 용어가 달라 지적받는 일이 흔하다
- 갭 분석과 내부 사전 점검 — 부족한 부분을 미리 찾아 고칠 시간을 번다
여기서 가장 흔한 실패 방식이 "문서를 위한 문서" 다. 심사 일정이 잡히면 급하게 산출물을 소급 작성하기 시작하고, 그렇게 만든 문서는 날짜와 버전이 실제 개발 이력과 어긋난다. 심사원은 그 어긋남을 인터뷰 몇 마디로 찾아낸다.
더 근본적인 손해는 심사 결과가 아니다. 소급 작성이 관행이 되면 프로세스가 실제 일과 분리되고, 팀은 절차서를 "심사용 문서"로만 취급하게 된다.
이 함정을 피하는 관점은 한 문장으로 요약된다. 증거는 심사를 위해 만드는 것이 아니라, 평소 일하면 저절로 남는 것이다. 이슈 트래커의 결함 이력, 테스트 관리 도구의 실행 기록, 코드 리뷰 승인 기록, CI 로그는 모두 일하는 과정에서 자동으로 쌓이는 증거다. 프로세스를 설계할 때부터 "이 활동의 증거가 어디에 남는가"를 함께 정하면, 심사 준비는 자료를 새로 만드는 일이 아니라 이미 있는 것을 정리하는 일이 된다.
덧붙이면, 절차서를 현실에 맞게 고치는 것도 정당한 선택 이다. 아무도 지키지 않는 절차서는 대개 지킬 수 없게 쓰여 있고, 부적합 지적을 계속 만들어내는 원천이 된다. 실제 방식과 문서가 다를 때 언제나 문서 쪽을 지키는 것이 정답은 아니다.
실무에서 왜 필요한가
웹·앱 서비스 회사에만 있으면 A-SPICE라는 이름을 평생 못 볼 수도 있다. 하지만 자동차 부품사, 의료기기, 항공, 철도로 한 발만 옮기면 QA 업무 시간의 적지 않은 비중이 심사 대응과 증거 관리 에 쓰인다. 테스트를 설계하고 실행하는 능력만 으로는 그 자리에서 제 몫을 하기 어렵다.
프로세스 표준을 이해하면 팀 안에서 다른 효용도 생긴다. "왜 이렇게 번거롭게 문서를 남겨야 하냐"는 질문에 "규정이니까"가 아니라 "이 기록이 없으면 이 부품을 계속 납품할 수 없다"고 답할 수 있게 된다. 프로세스를 강요하는 사람과 그 이유를 설명할 수 있는 사람은 팀 안에서의 무게가 다르다.
ISO/IEC 20246 쪽은 산업을 가리지 않고 바로 쓸 수 있다. 어떤 회사든 리뷰는 하지만, 그 리뷰가 어떤 유형이고 무엇을 남기며 왜 그 형식성을 골랐는지 설명할 수 있는 팀은 드물다. 표준의 언어를 알면 "리뷰를 체계화하자"는 막연한 제안을 "결제 모듈 명세는 체크리스트 기반 인스펙션으로, 나머지는 워크스루로"라는 구체적 설계로 바꿀 수 있다.
채용시장에서의 위치
자동차 부품사 QA 공고에는 "A-SPICE 대응 경험", "SWE.5/SWE.6 산출물 작성 경험", "기능안전(ISO 26262) 프로젝트 수행" 같은 문구가 그대로 등장한다. 앞서 본 것처럼 이 두 요건은 성격이 다르기 때문에, 프로세스 심사 대응과 기능안전을 모두 겪어본 인력 은 상대적으로 희소하다.
심사 대응 경험은 이력서에 구체적으로 쓸 수 있는 몇 안 되는 QA 성과이기도 하다. "A-SPICE 심사를 위해 SWE.6 영역의 테스트 사양과 추적성 매트릭스를 정비했고, 사전 갭 분석에서 식별한 부적합 항목 N건을 해소했다"는 문장은 "테스트를 열심히 했다"보다 훨씬 검증 가능한 진술이다.
ISO/IEC 20246과 33063은 공고에 번호가 직접 적히는 일이 드물다. 이쪽은 "정적 테스트·리뷰 체계를 설계하고 정착시킨 경험" 이라는 서술로 표현하는 편이 전달이 잘 된다.