개념
모듈 25에서 이어지는 자리
모듈 25 레슨 8에서 ISO/SAE 21434와 UNECE R155·R156을 다뤘다. 그건 "자동차 회사가 갖춰야 할 체계" 의 이야기였다 — 사이버보안 관리체계 (CSMS)를 만들고, TARA를 하고, 형식승인을 받는다.
이 레슨은 그 체계 안에서 실제로 무엇을 어떻게 시험하는가 를 다룬다. 활용·개발 맵과 Ver.2023 표준연계 활용맵의 스마트자동차 칸을 펼치면 구체적인 규격 번호들이 나오고, 각각이 어느 검증 영역을 담당하는지가 보인다.
전체 지도 — 다섯 층으로 나눠 본다
자율주행·커넥티드카 관련 표준은 수십 개가 얽혀 있어서 그냥 나열하면 외울 수 없다. 검증 대상별로 층을 나누면 정리된다.
① 통신 층 ── 차가 바깥과 어떻게 말하는가
3GPP TS 23.287 (5G V2X 아키텍처), TR 23.776, TR 23.700-33
IEEE 1609 (WAVE), IPWAVE (IP 기반 차량 네트워킹)
맵 항목: 5G C-V2X 기술 표준, IP기반 차량 네트워킹을 위한 IPWAVE 표준
② 데이터 층 ── 도로와 주행환경을 어떤 형식으로 표현하는가
맵 항목: 정적 정밀도로구조 데이터 모델 및 인코딩 표준
주행환경 동적 데이터모델 및 인코딩 표준
3차원 도시공간객체 모델 및 공유 인터페이스 표준
차량 정보 서비스 API 표준
③ 플랫폼 층 ── 차 안의 소프트웨어가 어떤 구조로 도는가
맵 항목: 자율자동차를 고려한 AUTOSAR Adaptive 플랫폼 표준
④ 보안 층 ── 공격을 어떻게 막고 탐지하는가
ITU-T X.1371~X.1376 (SG17)
맵 항목: 커넥티드카 침입 탐지 및 방지 시스템 표준
V2X 통신 및 응용 서비스 보안 가이드라인 표준
⑤ 안전 검증 층 ── 충분히 검증했음을 어떻게 증명하는가
ISO 26262 (기능안전), ISO 21448 SOTIF (의도된 기능의 안전)
맵 항목: 자율주행 에지 케이스 검증을 위한 가상환경 시뮬레이션 표준
안전한 자율주행차 거동을 위한 유스케이스 및 데이터 표준테스터에게 가장 중요한 층은 ⑤ 이고, 그다음이 ④다. ①~③은 개발이 주도하고 QA는 인터페이스 검증으로 붙는다.
① 통신 층 — V2X 검증에서 실제로 어려운 것
V2X는 차량이 다른 차량(V2V), 인프라(V2I), 보행자(V2P), 네트워크(V2N)와 통신하는 것이다. 3GPP의 5G V2X 아키텍처(TS 23.287)와 근접 서비스 확장 연구(TR 23.700-33)가 여기 걸린다.
검증에서 어려운 것은 프로토콜 자체가 아니라 상황을 만들어내는 일 이다.
| 시험하고 싶은 것 | 현실적 난점 | 대응 |
|---|---|---|
| 교차로에서 사각지대 차량 경고 | 차 두 대와 교차로가 필요 | 시뮬레이터 + 일부 실차 검증 |
| 수십 대가 동시에 메시지를 뿌릴 때의 혼잡 | 수십 대를 못 모은다 | 메시지 생성기로 부하 주입 |
| 통신 두절 구간 진입 | 재현 어려움 | 차폐 환경 또는 강제 차단 |
| 위조 메시지 수신 | 실차에서 만들면 위험 | 폐쇄 환경 + 주입 도구 |
대부분이 시뮬레이션과 주입(injection)으로 간다. 그래서 "실차 시험을 얼마나 했는가"보다 "시뮬레이션 결과를 실차로 얼마나 검증했는가"가 질문이 된다.
② 데이터 층 — 정적과 동적을 나눠 본다
맵이 정적 정밀도로구조 데이터 모델과 주행환경 동적 데이터모델을
따로 세운 것에 의미가 있다.
정적 데이터 차선, 표지, 신호등 위치, 곡률, 경사
→ 바뀌는 주기가 길다. 검증은 '정확성'과 '최신성'
동적 데이터 주변 차량, 보행자, 신호 현시, 공사 구간, 노면 상태
→ 실시간으로 변한다. 검증은 '지연'과 '일관성'QA가 확인할 것이 각각 다르다.
정적 데이터(정밀도로지도)의 검증 항목
- 지도 버전과 실제 도로 상태의 차이 — 공사·차선 변경이 반영되는 주기
- 좌표계와 측지계가 시스템 전체에서 일관된가
- 지도가 없는 구간(터널, 신설 도로)에 진입했을 때의 동작
- 지도 데이터 손상·부분 결손 시의 동작 (안전하게 축퇴하는가)
동적 데이터의 검증 항목
- 정보의 나이(age) — 수신 시점과 생성 시점의 차이를 시스템이 인지하는가
- 오래된 정보를 언제 버리는가. 그 기준이 명시돼 있는가
- 서로 모순되는 정보를 두 소스에서 받았을 때의 우선순위 규칙
- 정보 없음과 "장애물 없음"을 구분하는가 ← 가장 중요
마지막 항목이 실무에서 반복되는 함정이다. 센서나 통신에서 데이터가
안 왔을 때 이것을 "아무것도 없다"로 해석하면 치명적이다. 없음과
모름은 다른 상태 이고, 시스템이 이 둘을 구분하는지 확인하는 것은
전형적인 QA의 일이다.
③ 플랫폼 층 — AUTOSAR Adaptive가 검증에 주는 의미
기존 자동차 소프트웨어는 AUTOSAR Classic 위에서 돌았다. 정적으로 모든 것이 결정되고, 부팅 후 구성이 바뀌지 않는 구조다. 자율주행은 고성능 연산과 동적 업데이트가 필요해서 AUTOSAR Adaptive 가 나왔다.
이 차이가 검증을 바꾼다.
| Classic | Adaptive | |
|---|---|---|
| 구성 | 빌드 시 정적 확정 | 실행 중 동적 |
| 통신 | 신호 기반(CAN 등) | 서비스 지향(SOME/IP 등) |
| 업데이트 | 전체 플래싱 | 부분 업데이트 가능 |
| 검증 초점 | 타이밍 결정성 | 서비스 발견·버전 호환·업데이트 안전성 |
Adaptive 환경에서 새로 생기는 시험 항목이 있다.
- 서비스 발견(service discovery)이 실패했을 때의 동작
- 구버전 서비스와 신버전 서비스가 공존할 때의 호환성
- 부분 업데이트 중 전원이 끊겼을 때의 복구 (A/B 파티션 전환)
- 롤백 시 이전 구성으로 안전하게 돌아가는가
이건 웹 서비스의 마이크로서비스 검증과 사고방식이 거의 같다. 다만 실패했을 때 결과가 500 에러가 아니라 사고 라는 차이가 있다.
④ 보안 층 — ITU-T X 시리즈를 검증 항목으로
Ver.2023 표준연계 활용맵의 스마트자동차 × 차세대보안 칸에는 ITU-T
SG17의 권고안들이 줄줄이 붙어 있다. 각각이 담당하는 검증 영역을
정리하면 이렇다.
| 권고안 | 다루는 것 | QA가 만들 시험 항목 |
|---|---|---|
| X.1371 | 커넥티드 차량의 보안 위협 | 위협 목록을 시험 시나리오의 출발점으로 쓴다 |
| X.1372 | V2X 통신 보안 가이드라인 | 메시지 서명 검증, 인증서 폐기 처리 |
| X.1373 | ITS 통신 기기의 안전한 소프트웨어 업데이트 | 서명 검증, 변조 펌웨어 거부, 롤백 방지 |
| X.1374 | 차량 접근 가능 외부 인터페이스·기기의 보안 요구사항 | OBD 포트, 충전기, 블루투스, 앱 연동 지점 |
| X.1375 | 차량 내부 네트워크 침입탐지 시스템 가이드라인 | IDS가 실제로 탐지하는가, 오탐률은 |
| X.1376 | 빅데이터 기반 오동작 탐지 메커니즘 | 이상 패턴 주입 시 탐지되는가 |
국내 표준도 짝을 이룬다. TTAK.KO-12.0208(차량 간 통신 보안 요구사항), TTAK.KO-12.0238(차량 간 통신 인증 서비스 구조), TTAK.KO-12.0260(차량 간 통신 환경에서의 메시지 암호화 규격), TTAK.KO-12.0286(자동차 전자제어장치 간의 통신보안 요구사항), TTAK.KO-12.0346(차량 내부 네트워크 보안 요구사항), TTAK.KO-12.0357(AUTOSAR 기반 차량 보안 기능 개발 지침), TTAE.IT-X.1373(ITS 통신 디바이스를 위한 안전한 소프트웨어 업데이트 프로세스) 등이다.
X.1373의 검증은 QA가 직접 할 수 있는 영역 이라 특히 실용적이다. 소프트웨어 업데이트 보안 시험은 다음처럼 구성한다.
[안전한 소프트웨어 업데이트 시험 세트]
TC-01 정상 서명된 정상 펌웨어 → 설치 성공
TC-02 서명 없는 펌웨어 → 거부
TC-03 잘못된 키로 서명된 펌웨어 → 거부
TC-04 서명은 맞지만 내용이 변조된 펌웨어 → 거부
TC-05 구버전(취약점 존재) 펌웨어 → 롤백 방지로 거부
TC-06 업데이트 중 전원 차단 → 이전 버전으로 안전 복구
TC-07 업데이트 중 통신 단절 → 재개 또는 안전 복구
TC-08 차량 주행 중 업데이트 시도 → 차단되는가 (조건 검증)
TC-09 대상 차종이 아닌 펌웨어 → 거부
TC-10 설치 후 무결성 재검증 수행 여부TC-08이 놓치기 쉽다. 업데이트 가능 조건(정차, 주차 브레이크, 배터리 잔량)이 규정돼 있다면 그 조건이 실제로 강제되는지 봐야 한다.
⚠️ 이 시험들은 실차가 아니라 벤치(HIL) 환경이나 폐쇄 시험장에서 수행한다. 공도 주행 중인 차량에 변조 펌웨어를 주입하는 시험은 하지 않는다.
⑤ 안전 검증 층 — SOTIF와 시나리오 기반 검증
여기가 자율주행 검증의 핵심이다.
ISO 26262는 "고장으로 인한 위험"을 다룬다. 센서가 고장 났을 때, ECU가 멈췄을 때 안전한가.
ISO 21448(SOTIF)은 "고장이 없는데도 생기는 위험"을 다룬다. 모든 부품이 정상 동작하는데도, 인식 성능의 한계나 예상 못 한 상황 때문에 위험이 생기는 경우다. 역광에 가려진 보행자, 특이한 형태의 장애물, 설계자가 상상하지 못한 상황.
SOTIF의 4분면
알려진 상황 알려지지 않은 상황
안전 ① 알려진 안전 ③ 모르는 안전
위험 ② 알려진 위험 ④ 모르는 위험 ← 여기를 줄이는 것이 목표
검증 활동의 본질:
④를 ②나 ③으로 옮기고 (발견하고)
②를 ①로 옮긴다 (대책을 세우고)④ 영역을 줄이는 활동이 곧 탐색적 테스팅 이다. 모듈 5에서 배운 차터 기반 탐색이 여기서 그대로 쓰인다. 다만 대상이 화면이 아니라 주행 상황이다.
자율주행 에지 케이스 검증을 위한 가상환경 시뮬레이션 표준이라는 맵
항목이 정확히 이 문제를 겨냥한다. 실차로 모든 상황을 겪을 수는 없으니
시뮬레이션으로 대량 검증하고, 그 시나리오를 표준 형식으로 주고받자는
것이다. 국제적으로는 ASAM의 OpenSCENARIO(시나리오 기술)와
OpenDRIVE(도로망 기술)가 이 역할을 한다.
시나리오 기반 검증을 설계하는 법
시나리오를 무작정 많이 만드는 것은 답이 아니다. 차원을 정의하고 조합 설계 기법을 쓴다 — 모듈 3에서 배운 것 그대로다.
[시나리오 차원 정의]
도로 직선 / 곡선 / 교차로 / 합류 / 램프 / 터널
기상 맑음 / 비 / 눈 / 안개 / 역광
시간 주간 / 야간 / 여명·황혼
교통 한산 / 보통 / 정체 / 돌발 정지
행위자 승용차 / 트럭 / 이륜차 / 보행자 / 자전거 / 동물
행동 정상 / 급제동 / 급차선변경 / 역주행 / 무단횡단
센서상태 정상 / 오염 / 부분 가림 / 일시 실명
전조합 = 폭발한다 → 페어와이즈로 줄이고,
위험도가 높은 조합(역광 + 무단횡단 + 곡선)은 반드시 포함시킨다이것이 리스크 기반 테스트(모듈 4)를 주행 시나리오에 적용한 형태 다. 페어와이즈로 기본 커버리지를 확보하고, 리스크가 높은 조합은 별도로 지정해 추가한다.
시뮬레이션 결과를 어디까지 믿을 것인가 도 정해야 한다. 시뮬레이터의 센서 모델이 실제 센서와 다르면 시뮬레이션 통과가 실차 안전을 보장하지 않는다. 그래서 시나리오 일부를 실차·HIL로 교차 검증하고, 그 일치율을 근거로 시뮬레이션 신뢰도를 논증하는 구조를 만든다.
사례 — 시나리오 1만 건을 돌렸는데 놓친 것
자율주행 기능의 시뮬레이션 검증에서 시나리오 12,400건을 통과했다. 보고서의 숫자는 좋았고, 실차 시험 단계로 넘어갔다. 그런데 제한 구역 실증에서 같은 유형의 문제가 세 번 나왔다.
원인을 추적하자 숫자 뒤의 구조가 보였다.
| 드러난 것 | 내용 |
|---|---|
| 12,400건의 차원 분포 | 날씨 3종 × 시간대 2종 × 차량 수 4종 × … 로 곱해진 수 |
| 실제로 다룬 경계 조건 | 각 차원의 중간값 중심. 끝값 조합은 거의 없음 |
| 놓친 유형 | 역광 + 젖은 노면 + 저속 선행차 같은 조합의 끝 |
| 시나리오 출처 | 대부분 표준 시나리오 세트에서 가져옴 |
| 운용 데이터 반영 | 없음 |
두 번째 줄이 핵심이다. 조합을 곱해 수를 늘리면 건수는 커지는데 경계는 안 늘어난다. 모듈 3의 경계값 분석이 시나리오 차원에서도 그대로 적용되는데, 자동 생성에 맡기면 중간값이 과잉 표본이 된다.
바꾼 것은 셋이었고 건수는 오히려 줄었다.
- 차원별 끝값과 경계를 먼저 고정하고, 그 조합에 페어와이즈를 적용 (모듈 3) → 12,400건 → 3,800건
- 운용·사고 데이터에서 실제로 있었던 조합을 시나리오로 역산해 추가
- 보고서에 건수 대신 "다룬 차원 조합의 커버리지" 를 적기 시작
3번이 보고의 성격을 바꿨다. "12,400건 통과" 는 커 보이지만 무엇을 안 봤는지 알 수 없는 숫자이고, "경계 조합 커버리지 72%, 미커버 영역은 이것들" 은 판단이 가능한 숫자다(모듈 6 레슨 5·모듈 8 레슨 6과 같은 원칙).
교훈이 셋이다.
- 시나리오 건수는 품질 지표가 아니다 — 분모가 정의되지 않은 숫자다 (모듈 27 레슨 5의 "자동화 70%" 와 같은 함정)
- 자동 생성은 중간값을 과잉 표본으로 만든다 — 끝값을 사람이 지정한다
- 운용 데이터에서 역산한 시나리오가 표준 세트보다 우리 제품에 가깝다
실무에서 왜 필요한가
자율주행 과제의 검증 계획은 전부 이 구조다
국내 자율주행 실증 과제의 검증 계획서를 열어보면 대개 같은 골격이다 — 시나리오 목록, 시뮬레이션 결과, 실차 검증 결과, 안전 조치, 보안 시험. 이 레슨의 다섯 층이 그 목차와 거의 일치한다.
QA가 이 구조를 알고 들어가면 처음부터 빠진 층을 지적할 수 있다. 보안 층(④)이 통째로 빠진 계획서가 의외로 흔하다.
완성차·부품사 채용에서 직접 요구된다
ISO 21434, UNECE R155, SOTIF, AUTOSAR Adaptive, HIL,
시나리오 기반 검증 — 자동차 QA 채용공고에 그대로 나오는 단어들이다.
모듈 25 레슨 8이 체계 쪽이었다면, 이 레슨은 실제 시험 설계 쪽이다.
둘을 함께 말할 수 있으면 면접에서 확실히 구분된다.
일반 소프트웨어에도 옮겨오는 개념
SOTIF의 4분면은 자동차 바깥에서도 유용하다. "고장은 없는데 의도대로 동작하지 않아 생기는 위험" 은 추천 알고리즘, 자동 심사, LLM 기반 기능 어디에나 있다. 모듈 18b(AI 시스템 테스트)와 함께 보면 연결이 보인다.
채용시장에서의 위치
완성차·부품사·자율주행 스타트업의 QA 자리는 도메인 지식 요구가 명확 하고, 그래서 일반 웹 QA 경력만으로는 통과하기 어렵다. 반대로 이 레슨의 다섯 층을 말할 수 있으면 지원 가능한 범위가 크게 넓어진다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "자율주행 검증을 어떻게 설계하세요?" | "다양한 시나리오로 테스트합니다" | "통신·데이터·플랫폼·보안·안전 다섯 층으로 나눕니다. 층마다 시험 수단이 다릅니다" |
| "시나리오는 몇 건이 적당한가요?" | "많을수록 좋습니다" | "건수는 지표가 아닙니다. 차원별 끝값을 고정하고 페어와이즈로 줄입니다" |
| "SOTIF와 기능안전의 차이는요?" | "둘 다 안전입니다" | "기능안전은 고장, SOTIF는 고장이 없는데도 의도대로 안 되는 경우를 다룹니다" |
| "시뮬레이션만으로 충분한가요?" | "실차 시험도 합니다" | "수단별로 증명되는 것을 나눠 적습니다. 센서 특성과 환경 요인은 시뮬레이션으로 안 됩니다" |
| "커넥티드카 보안은 어디서 시작하세요?" | "취약점을 점검합니다" | "소프트웨어 업데이트 경로부터요. 업데이트가 뚫리면 나머지 통제가 무의미합니다" |
두 번째가 가장 변별력이 크다. 시나리오 건수를 성과로 보고하는 관행이 널리 퍼져 있어서, "건수는 분모가 없는 숫자" 라고 말하는 사람은 드물다. 모듈 27 레슨 5의 "자동화 70%" 사례와 같은 감각이다.
세 번째는 기본 질문인데 틀리는 경우가 많다. 고장 유무로 갈린다는 한 줄만 정확히 말해도 다르게 읽힌다(모듈 25 레슨 4·8).
공고 표현으로는 "자율주행 검증", "V2X 테스트", "ADAS QA", "시나리오 기반 검증", "AUTOSAR", "차량 보안" 이 이 레슨에 걸린다. 그리고 모듈 25 레슨 8(21434·R155)과 짝으로 익혀 두면 체계와 검증 양쪽을 말할 수 있다.