모빌리티·자율주행 QA — 인지·판단·제어 검증과 IVI·OTA

학습 목표

이 모듈 한 줄 요약 — "명세대로 동작해도 안전하지 않을 수 있다". 지금까지는 "적어 둔 대로 되는가" 가 기준이었다. 차가 스스로 판단해 움직이는 영역에서는 그 전제가 깨진다 — 고장이 없어도 센서가 상황을 잘못 알아보면 사고가 난다. 그 영역을 어떻게 시험하는지를 다룬다.

모듈 35 에서 기능안전이 요구하는 활동을, 모듈 46 에서 임베디드·제어 영역의 검증 기법을 다뤘다. 이 모듈은 그 둘을 차가 스스로 판단해 움직이는 영역에 적용한다. 그리고 여기서 익숙한 전제 하나가 깨진다. 명세대로 동작해도 안전하지 않을 수 있다. 센서가 사양 범위 안에서 정상 동작했는데 역광에서 정지 차량을 구분하지 못하고, 차선 인식이 설계대로 동작했는데 공사 구간의 지워진 옛 차선을 유효한 것으로 읽는다. 고장이 아니라 성능의 한계 이고, 기능안전의 질문으로는 이 위험이 잡히지 않는다.

이 모듈은 그 간극을 다룬다. 중심 작업은 "어느 단계가 틀렸는지 묻는 일" 과 "아직 모르는 위험을 찾아내는 일" 두 가지다. 전자는 현장 보고 한 줄("차가 이상하게 움직였다")을 책임 소재가 분명한 결함으로 바꾸는 작업이고, 후자는 무엇을 덮었다고 말할 수 있는가 를 정직하게 쓰는 작업이다. 두 작업 모두 숫자 하나로 요약되지 않고, 그래서 이 분야의 QA 산출물은 보고서가 아니라 논증 에 가깝다.

여섯 갈래로 간다. 첫째, 인지·판단·제어 분리 다. 세 단계의 경계에서 무엇을 관측해야 원인이 좁혀지는지, 각 단계가 실패하는 고유한 모양이 무엇인지를 익힌다. 둘째, SOTIF 다. 알려짐과 위험함 두 축으로 시나리오를 네 영역으로 가르고, 운행 설계 영역(ODD)의 경계를 시험하고, 예상 가능한 오사용을 설계 입력으로 다룬다. 셋째, 시나리오 기반 시험과 데이터 재생 이다. 시나리오의 추상 수준을 가르고, 정적 환경과 동적 행동을 나눠 기술하는 구조를 읽고, 두 수단이 각각 보장하지 못하는 것을 분명히 한다. 넷째, 코너 케이스와 커버리지 다. 조합 폭발을 줄이고, 실주행 데이터에서 어려운 장면을 발굴하고, "커버리지 N%" 가 무엇에 대한 비율인지 정의한다. 다섯째, IVI 다. 사용자가 운전 중이라는 조건이 조작 제약을 안전 요구로 만들고, 음성·내비·스마트폰 연동이 각각 고유한 실패 모양을 갖는다. 여섯째, 차량 OTA 다. 갱신을 허용할 차량 상태 조건과 중단·부분 실패에서 안전한 상태로 남는지, 그리고 사용자가 실제로 무엇을 겪는지를 본다.

안전 경계를 모듈 전체에 걸쳐 명시했다. 공도·시험장 주행, 실차 갱신, 전원·배터리 조작은 허가·자격·안전 조치가 전제이고 QA 가 개시하는 작업이 아니다. 이 모듈의 실습 과제는 전부 설계·문서·데이터 분석 과제 이며, QA 의 자리는 시나리오 설계와 결과 분석이고 주행 조작이 아니다. 그리고 공격 기법은 다루지 않는다 — 센서를 속이는 기법과 통신 침입은 모듈 50·모듈 25 레슨 8 의 범위이고, 이 모듈은 기능이 의도대로 동작하는지의 검증을 맡는다. 수치가 필요한 자리는 상상해 넣지 않고 "요구사항·ODD 명세·적용 규정에서 확인한 값(원문 확인)" 으로 썼다.

완료 후 할 수 있는 것

• "차가 이상하게 움직였다" 를 단계가 특정된 결함 보고로 바꿀 수 있다
• 인지·판단·제어 세 단계의 입력·출력을 구분하고 경계 관측 가능성을 설계 단계에 요구할 수 있다
• 제어 명령 → 판단 결정 → 인지 출력 → 실제 대조 순으로 원인을 좁히는 절차를 운영할 수 있다
• 절차가 "세 단계 모두 명세대로" 로 끝나면 SOTIF 영역임을 알고 다른 경로로 올릴 수 있다
• 인지 실패 네 유형(미검출·오검출·오분류·상태 오차) 을 구분하고 각각의 결과를 짝지을 수 있다
• 미검출과 오검출의 교환 관계를 알고 양쪽을 함께 보고하는 판정 양식을 만들 수 있다
• 오분류가 어느 판단 오류로 이어지는지 표로 만들 수 있다
• 센서 융합 결함 다섯 가지를 들고, 시간 정렬 오차가 속도에 비례해 위치 오차가 되는 것을 계산할 수 있다
• 한 센서가 가려졌을 때 "모르고 계속 가는 것" 이 가장 위험한 이유를 설명할 수 있다
• 판단 실패 다섯 유형을 알고, 결정 떨림을 경계값 시험으로 재현할 수 있다
• 예측 오류의 판정 기준을 "틀렸을 때 안전한가" 로 쓸 수 있다
• 제어 실패 다섯 유형과, 상태 전환(전달·인수) 이 안전에 가장 직결되는 이유를 안다
• 기능안전과 SOTIF 가 묻는 질문의 차이를 한 문장으로 설명할 수 있다
• 시나리오를 알려짐 × 위험함 네 영역으로 가르고 작업 방향(2→1, 3→2) 을 설계할 수 있다
• 영역 3 의 크기를 알 수 없어 "몇 % 남았다" 고 말할 수 없음을 알고, 그 대신 말할 수 있는 세 가지를 쓸 수 있다
• ODD 가 제약이자 안전 설계인 이유를 알고, 명세가 판정 가능한 수준인지 검토할 수 있다
• ODD 경계를 다섯 축(안쪽 끝·밖·전환 순간·판정 실패·모호한 경계) 으로 시험할 수 있다
• ODD 판정 실패를 양방향으로 보고, 밖인데 안으로 판정하는 쪽이 더 위험한 이유를 설명할 수 있다
• 유발 조건 여덟 축으로 미지 위험을 탐색하는 계획을 세울 수 있다
• 다중 조합이 영역 3 의 주 서식지인 이유를 알고 조합을 의도적으로 만들 수 있다
• 예상 가능한 오사용 여섯 유형을 설계 입력으로 다루고, 우회 기법을 적지 않으면서 감지·대응 설계를 확인할 수 있다
• 시나리오의 세 추상 수준(기능·논리·구체) 을 구분하고 논리 수준에서 파라미터와 범위를 정의할 수 있다
• 정적 환경 기술과 동적 요소 기술의 분리를 이해하고 결합 지점의 결함을 짚을 수 있다
• 전제 조건 검사와 무효 판정을 도입해 "통과했지만 아무것도 시험하지 않은" 시나리오를 걸러낼 수 있다
• 무효를 통과로 집계하면 커버리지가 거짓이 되는 경로를 설명할 수 있다
• 데이터 재생의 개방 루프 한계를 알고 "어느 시점까지 유효한가" 를 결과에 적을 수 있다
• 판정 기준 세 방식의 한계를 알고 기준 라벨 부분집합을 유지해야 정확도를 말할 수 있음을 안다
• 객체 비교 규칙(짝짓기·허용 오차·신뢰도 임계) 이 결과를 바꾸므로 보고서에 명시할 수 있다
• 대량 재생을 메타데이터 → 요약 통계 → 차분 분포 → 설계된 표본 → 시각화로 좁혀 볼 수 있다
• 시뮬레이션 결과를 증거로 쓰기 위한 여섯 조건을 들고, 모델 타당성이 비면 결과가 보장하지 않는 것을 설명할 수 있다
• 결정성이 깨질 때 고정·반복·여유로 대응할 수 있다
• 파라미터를 균등 분할이 아니라 동작 전환점 기준으로 쪼갤 수 있다
• 층을 나눈 조합 설계(전체는 쌍 단위, 위험 부분집합은 더 깊게) 를 하고 근거를 증거로 남길 수 있다
• 탐색적 생성에 현실성 필터를 붙여야 하는 이유를 안다
• 실주행 데이터에서 일곱 발굴 신호로 어려운 장면을 찾아내는 파이프라인을 설계할 수 있다
• 운전자 개입 데이터가 영역 3 의 직접적 단서인 이유를 설명할 수 있다
• 발굴한 장면을 논리 시나리오로 추상화해 "조건 범위 통과" 증거로 올릴 수 있다
• 커버리지의 분모 여섯 종류와 각각의 한계를 들고, 단일 숫자 대신 파라미터 지도와 덮이지 않은 영역을 보고할 수 있다
• 실주행 거리가 다양성을 뜻하지 않는다는 것을 설명할 수 있다
• 커버리지를 목표로 삼지 않는 순서(위험 → 시나리오 → 측정 → 분석) 를 지킬 수 있다
• 주행 중 잠금의 모든 접근 경로를 열거하고 각 경로에서 잠금이 걸리는지 시험할 수 있다
• 잠금 판정 신호가 없을 때 안전한 쪽으로 가야 함을 확인할 수 있다
• 음성인식 실패 일곱 유형을 구분하고 차량 특유의 소음·발화 조건으로 시험 데이터 집합을 만들 수 있다
• 내비게이션의 세 실패 축을 알고, 측위 실패가 자율주행 기능으로 번지는 경로를 짚을 수 있다
• 스마트폰 연동 조합을 점유·위험·경계 세 근거로 줄이고, 연동 화면이 주행 제한 우회 경로가 될 수 있음을 안다
• 휴대기기 OS 변경이 통제 불가 변경임을 알고 출시 후 회귀 계획을 요구할 수 있다
• 차량 특유 제약(부팅·전원·온도·저장 공간·장기 가동·언어) 을 시험에 반영할 수 있다
• 부팅 시간을 최악 조건에서 재야 하는 이유를 안다
• IVI 표시가 기능 상태 오해를 만들면 SOTIF 오사용으로 번진다는 연결을 설명할 수 있다
• 차량 OTA 의 판정 기준이 "성공했는가" 가 아니라 "실패해도 차가 움직이는가" 임을 안다
• 갱신 전제 조건 여덟 축을 설계하고, 조건을 시작 시점에만 확인하면 안 되는 이유를 설명할 수 있다
• 설치 중 운전자 이동 시도에 대한 세 설계 선택과 각각이 보장해야 하는 것을 가를 수 있다
• 부분 갱신 상태를 열거하고 버전 조합 호환성 정의를 요구할 수 있다
• "모든 복구가 실패해도 차량이 안전하게 움직이는가" 요구가 있는지 확인하고, 없으면 설계 지적으로 올릴 수 있다
• 중단 지점 여덟 가지로 시험을 설계하고 되돌리는 중 다시 실패하는 이중 실패를 다룰 수 있다
• 사용자 경험 여섯 영역을 시험하고, 실패 안내를 "사용자가 할 행동이 적혀 있는가" 로 검토할 수 있다
• ODD 축소를 사용자가 모를 때 "작동한다고 믿고 의존하는" 쪽이 더 위험한 이유를 설명할 수 있다
• 갱신 경로 조합에서 오래된 기존 버전 경로가 가장 깨지기 쉬우며 개발 환경에서 시험되지 않는 문제를 안다

채용시장에서의 위치

이 모듈이 겨냥하는 시장은 완성차와 부품사의 자율주행·ADAS·IVI·커넥티드 조직, 자율주행 솔루션 기업, 차량 소프트웨어 플랫폼 기업, 그리고 시뮬레이션·검증 도구 기업 이다. 국내에서는 완성차와 1차 부품사, 그리고 그 공급망에 수요가 몰려 있고, 공고 문구는 "ADAS 검증", "자율주행 검증", "시나리오 기반 시험", "SOTIF", "주행 데이터 분석", "IVI", "인포테인먼트", "커넥티비티", "OTA" 같은 형태로 나타난다.

이 시장은 두 갈래로 갈려 있고 진입 난이도가 다르다. IVI·커넥티비티 쪽은 모바일 QA 경험이 전이되기 좋아 상대적으로 진입이 수월하고 수요가 꾸준하다. 자율주행 검증 쪽은 센서·제어·차량 동역학의 기초 개념이 필요해 진입 장벽이 높고, 그래서 공급이 적다. 두 갈래를 모두 아는 사람은 특히 희소하다 — IVI 표시가 운전자의 기능 상태 오해를 만들어 SOTIF 오사용이 되는 지점처럼, 두 영역이 실제로 맞물리는 자리가 있기 때문이다.

경쟁력이 되는 것은 넷이다. 첫째, 단계를 가르는 질문을 하는 능력 이다. "갑작스러운 제동이 보고되면 어떻게 접근하시겠습니까" 에 절차를 단계로 답할 수 있으면 즉시 구분된다. 둘째, "결함" 과 "명세 부족" 을 가르는 능력 이다. 기능안전과 SOTIF 의 차이를 "고장 났을 때 vs 고장이 없는데도" 로 답하고 네 영역을 들 수 있는 사람이 많지 않다. 셋째, 커버리지를 정직하게 말하는 능력 이다. 면접에서 "커버리지를 어떻게 정의하십니까" 에 단일 숫자로 답하면 약하고, 분모의 종류와 한계를 열거하며 파라미터 지도와 덮이지 않은 영역을 함께 보고한다고 답하면 검증 리드로 읽힌다. 넷째, 거짓 안심을 찾아내는 눈 이다 — 무효 시나리오를 통과로 집계한 숫자, 개방 루프 한계를 넘은 재생 결과, 모델 타당성이 비어 있는 시뮬레이션 보고. 이 셋을 짚을 수 있으면 조직의 검증 품질을 끌어올리는 사람이 된다.

자격증 축에서는 ISTQB CT-AuT(자동차 소프트웨어 테스터) 가 이 영역의 공통 언어로 쓰이고, CTFL·CTAL-TA 가 설계 기법의 기반이 된다. 기능안전·SOTIF 관련 교육 이수가 이력에 직접 작동하고, 모듈 35 와 함께 익히면 묶음이 된다. 다만 최종적으로 평가되는 것은 "무엇을 덮었는지 설명해 봤는가" 다. 개별 시험을 수행하는 것과 검증 범위를 논증으로 쓰는 것은 다른 수준의 일이고, 후자가 이 분야에서 대체하기 어려운 역량이다. 이 모듈의 실습 과제는 그 경험이 없는 상태에서 해당 산출물 — 단계 분리 절차서, ODD 경계 시험 설계, 전제 조건 검사와 무효 판정, 발굴 파이프라인, 커버리지 보고 양식, 잠금 경로 표, 부분 갱신 상태 설계 — 을 미리 만들어 두는 방향으로 설계했다.