개념
사용자가 운전 중이다
차량용 인포테인먼트(IVI) 는 겉으로 보면 태블릿 앱과 비슷하다. 지도, 음악, 설정, 연결. 그래서 모바일 QA 경험을 그대로 적용하려는 시도가 생기고, 그 지점에서 어긋난다.
결정적 차이는 하나다. 사용자가 운전 중 이다. 그 조건이 세 가지를 바꾼다.
1) 조작 시간이 안전 문제가 된다. 화면을 보는 시간, 손을 떼는 시간이 주행 안전에 직접 영향을 준다. 모바일에서 "3번 터치로 도달" 은 사용성 지표이고, 차량에서는 안전 제약 이다.
2) 사용자가 기능을 선택할 여유가 없다. 메뉴를 탐색하거나 실패를 재시도할 여유가 적다. 그래서 한 번에 되는가 가 중요하고, 실패했을 때 빠르게 포기할 수 있는가 도 중요하다.
3) 오류의 결과가 다르다. 모바일 앱이 멈추면 다시 켠다. 주행 중 내비게이션이 멈추면 길을 잃고, 그 상태에서 운전자가 화면을 조작하려 한다 — 기능 실패가 주의 분산을 유발 한다.
그래서 IVI 검증은 기능이 되는가 와 그 기능이 주행 중에 쓸 수 있는가 를 나눠 봐야 한다. 후자가 이 레슨의 중심이다.
주의 분산 제약은 안전 요구다
차량 내 조작에 대한 제약은 여러 가이드라인과 규정에서 다뤄진다. 적용되는 지침·규정과 그 구체적 기준(허용 시간, 금지 동작, 측정 방법) 은 해당 문서와 사내 설계 기준에서 확인한다(원문 확인). 지역과 차종에 따라 적용 범위가 다르고 개정된다.
QA 가 알아야 할 것은 제약의 성격 이다. 전형적으로 다루는 축이 셋이다.
| 축 | 다루는 것 |
|---|---|
| 시선 이탈 | 화면을 보기 위해 전방에서 눈을 떼는 시간·횟수 |
| 조작 시간 | 과업 완료까지 걸리는 시간, 조작 단계 수 |
| 주행 중 금지 | 특정 기능·입력을 주행 중에 아예 막는다 |
세 번째가 QA 에게 가장 직접적인 시험 대상 이다. "주행 중에는 이 기능이 잠긴다" 는 구현이고, 구현이면 결함이 있을 수 있다.
주행 중 잠금(흔히 driving restriction, 주행 제한) 의 시험 항목이 이렇다.
| 항목 | 확인할 것 |
|---|---|
| 잠금 조건 | 무엇을 기준으로 주행 중이라고 판정하는가(속도·기어·주차 브레이크) |
| 판정 경계 | 기준값 전후. 정차와 서행의 구분 |
| 잠기는 범위 | 어느 기능·어느 입력이 잠기는가. 명세와 일치하는가 |
| 잠금 중 표시 | 왜 잠겼는지 사용자가 아는가 |
| 잠금 해제 | 정차하면 즉시 풀리는가, 지연이 있는가 |
| 우회 경로 | 잠긴 기능에 다른 경로로 접근할 수 있는가 |
| 동승자 조작 | 동승자 입력을 허용하는 설계면 그 판정이 맞는가 |
여섯 번째가 가장 자주 발견되는 결함 이다. 메뉴 A 에서는 잠겼는데 음성 명령이나 다른 화면 경로, 또는 스마트폰 연동 화면을 통해 같은 기능에 도달할 수 있는 경우다. 잠금은 모든 경로에서 걸려야 하고, 경로를 전부 찾아내는 것이 QA 의 일이다.
첫 번째와 두 번째도 중요하다. 판정 기준이 속도라면 그 경계가 어디인지, GPS 속도인가 차량 속도 신호인가, 신호가 없을 때는 어떻게 되는가. 신호 부재 시 안전한 쪽으로 가는가(잠금 유지) 가 핵심 질문이고, 모듈 62 레슨 6 의 "값이 없음" 처리와 같은 구조다.
음성인식이 실패하는 고유한 모양
음성은 주의 분산을 줄이는 수단이라 차량에서 중요해졌다. 그런데 실패 유형이 많고, 각각 사용자 경험이 다르다.
| 유형 | 무엇인가 | 사용자가 겪는 것 |
|---|---|---|
| 미인식 | 발화를 못 알아듣는다 | 반복하게 된다. 주의 분산 증가 |
| 오인식 | 다른 말로 알아듣는다 | 엉뚱한 동작. 되돌려야 한다 |
| 의도 오분류 | 말은 맞게 들었는데 의도를 틀린다 | "왜 이게 됐지" |
| 깨우기 실패 | 호출어에 반응하지 않는다 | 기능 자체에 도달 못 함 |
| 오작동 깨우기 | 대화 중에 끼어든다 | 거슬리고, 의도치 않은 조작 |
| 지연 | 응답이 늦다 | 사용자가 다시 말하거나 화면을 본다 |
| 중단 불가 | 말하는 중에 멈출 수 없다 | 끝날 때까지 기다린다 |
미인식과 오인식의 교환 관계 가 또 나온다 — 민감하게 하면 오인식이 늘고 보수적으로 하면 미인식이 늘어난다. 레슨 1 의 미검출·오검출, 모듈 41 레슨 9 의 오탐·미탐과 같은 구조 이고, 같은 원칙이 적용된다 — 양쪽을 함께 보고한다.
차량 특유의 시험 조건 이 음성인식 검증을 어렵게 만든다.
| 조건 | 왜 영향을 주는가 |
|---|---|
| 주행 소음 | 속도에 따라 소음이 커진다. 저속과 고속에서 성능이 다르다 |
| 창문·에어컨 | 열린 창, 송풍 세기가 소음을 바꾼다 |
| 음악 재생 | 자기 소리를 제거해야 한다. 제거가 불완전하면 간섭 |
| 탑승자 수·위치 | 운전석 발화와 동승석 발화를 가르는 설계면 그 판정 |
| 발화자 특성 | 억양, 말 속도, 성별·연령대 분포 |
| 언어·혼용 | 외국어 지명·곡명이 섞인 발화 |
마지막이 국내 환경에서 특히 중요하다. "강남 스타벅스 가자" 같은 혼용 발화, 영어 곡명, 지명의 표기 변이. 이런 발화를 시험 데이터 집합 으로 만들어 두는 것이 IVI 음성 검증의 핵심 자산이고, 레슨 3 의 기준 장면 집합과 같은 발상이다.
소음 조건은 재현이 어렵다. 실차 주행에서 재현하려면 시간이 들고 조건이 흔들린다. 그래서 녹음된 소음을 주입하는 환경 이 쓰이고, QA 가 요구할 것이 그것이다. 다만 주입한 소음이 실제 차내 소음과 같은지 는 모듈 62 레슨 3 · 모듈 65 레슨 3 의 모델 타당성 문제와 같다 — 누가 어떻게 확인했는지가 필요하다.
내비게이션이 실패하는 고유한 모양
내비게이션은 데이터·측위·경로 계산 세 축으로 실패한다.
| 축 | 실패 유형 |
|---|---|
| 지도 데이터 | 신설 도로 누락, 폐쇄 도로 잔존, 회전 제한 오류, 일방통행 오류 |
| 측위 | 터널·지하·고층 구간 음영, 평행 도로 혼동, 고가·지하 차도 구분 실패 |
| 경로 계산 | 불가능한 경로, 비합리적 우회, 교통 정보 반영 실패, 재탐색 반복 |
측위 실패가 안전과 가장 가깝다. 고가도로 위에 있는데 아래 도로로 판정하면 안내가 전부 틀리고, 운전자는 혼란 상태에서 화면을 본다. 그리고 레슨 1 에서 본 것처럼 측위는 자율주행 기능의 입력 이기도 하다 — 내비 측위와 주행 기능 측위가 같은 소스를 쓰면 영향이 번진다.
QA 가 설계할 시험 축이 이렇게 된다.
- 경계 구간 — 터널 출입구, 지하 주차장 출입, 고가 진입·이탈, 평행 도로 구간
- 재탐색 — 경로를 벗어났을 때. 재탐색이 반복되는 상태(떨림) 포함
- 안내 시점 — 너무 늦은 안내, 너무 이른 안내. 분기 직전 안내
- 데이터 갱신 — 지도 갱신 전후의 동작, 갱신 중 사용
- 목적지 입력 — 주행 중 제한, 음성 입력과의 결합
- 다중 경로 안내 — 복잡한 분기에서 어느 차로인지 전달되는가
세 번째(안내 시점) 가 주의 분산과 직결된다. 안내가 늦으면 운전자가 급하게 판단하고, 이르면 잊는다. 적절한 시점의 기준은 요구사항에서 온다(원문 확인).
두 번째의 떨림 도 레슨 1 의 결정 떨림과 같은 구조다. 측위가 흔들리면 경로 이탈·복귀 판정이 왕복하고, 안내가 반복된다. 임계값 근처 조건을 만드는 경계값 시험으로 잡는다.
스마트폰 연동 — 조합이 폭발한다
IVI 검증에서 시험 조합이 가장 크게 폭발하는 영역이다. 축이 넷이다.
[차량 측] [연결 방식] [휴대기기] [앱]
IVI 소프트웨어 버전 × 유선·무선 × OS·버전·제조사 × 앱·버전여기에 상태 가 곱해진다 — 연결 중 전화 수신, 연결 중 기기 재시작, 두 기기 동시 연결 시도, 저전력 상태, 기기 잠금 상태.
전수 조합은 불가능하므로 조합 기법과 대표 선정 이 필수다. 모듈 3 레슨 5 와 모듈 52 레슨 4(디바이스 팜) 의 발상이 그대로 쓰인다.
대표를 고르는 근거는 셋이다.
- 시장 점유 — 실제 사용자 기기 분포. 데이터가 있으면 그것을 쓴다
- 위험 — 과거 결함이 많이 나온 조합, 새로 추가된 조합
- 경계 — 지원 최소 버전, 최신 버전, 지원 경계에 있는 기기
세 번째가 자주 빠진다. 지원하는 최소 OS 버전과 그 직전 버전의 동작, 그리고 지원하지 않는 기기를 연결했을 때 어떻게 되는가. 거부하는가, 일부만 되는가, 거부 메시지가 명확한가.
연동에서 자주 나오는 결함 유형이다.
| 유형 | 상황 |
|---|---|
| 연결 실패·불안정 | 특정 기기·버전에서 반복 끊김 |
| 전환 실패 | 유선↔무선, 기기 교체 시 |
| 상태 불일치 | 기기에서 재생 중인데 IVI 는 정지로 표시 |
| 권한·인증 | 기기 잠금 상태에서의 접근, 권한 거부 시 동작 |
| 전화 간섭 | 통화 중 다른 기능 동작, 통화 종료 후 복귀 |
| 주행 제한 우회 | 연동 화면을 통해 잠긴 기능에 접근 |
| 기기 업데이트 후 | 휴대기기 OS 가 올라간 뒤 깨짐 |
여섯 번째가 위에서 말한 우회 경로 다. 차량 화면에서는 잠긴 기능이 연동 화면에서는 열려 있으면 제약이 무의미해진다. 모든 경로를 열거하는 작업 이 필요하고, 연동 화면이 그 목록에 반드시 들어가야 한다.
일곱 번째는 통제할 수 없는 변경 이다. 휴대기기 OS 는 우리가 정하지 않고 올라간다. 그래서 출시 후 회귀 가 계속 필요하고, 그것을 운영 계획에 반영해야 한다 — 모듈 17 레슨 3(OS 업데이트 대응) 의 구조가 그대로 적용된다.
차량 특유의 제약
IVI 를 모바일 앱처럼 시험하면 놓치는 조건들이다.
부팅과 종료. 차량 전원 상태에 따라 IVI 가 켜지고 꺼진다. 확인할 것 — 부팅 시간(사용자가 기다리는 시간), 부팅 중 조작, 빠른 재시동(켜고 바로 끄기), 종료 중 상태 저장, 비정상 종료 후 복구.
부팅 시간이 요구사항인 경우가 많다. 차에 타서 시동을 걸면 몇 초 안에 후방 카메라가 떠야 하는 식이다. 그리고 그 요구는 최악 조건 에서 재야 한다 — 저온, 저장 공간이 찬 상태, 많은 데이터가 쌓인 상태.
전원. 전압 변동, 시동 시 전압 강하, 장시간 주차 후 배터리 저하, 외부 급전. 모듈 46 레슨 6 의 전원 장애 주입이 여기서 쓰이고, 전원 조작은 승인과 안전 조치가 전제 다.
온도. 여름 주차 후 고온, 겨울 저온. 성능 저하와 기능 제한이 명세대로인가. 저온에서 저장 장치 응답이 느려지는 영향도 확인한다.
저장 공간. 지도 데이터, 로그, 음악 캐시가 쌓인다. 가득 찼을 때의 동작 — 모듈 39 레슨 11, 모듈 62 레슨 5 의 용량 소진과 같은 구조다. 실패가 사용자에게 전달되는가 가 핵심이다.
장기 가동. 차량은 며칠씩 꺼지지 않거나, 짧게 반복해 켜진다. 모듈 62 레슨 5 의 누적형 결함이 여기서도 나타난다.
언어·지역. 다국어, 문자 길이 변화로 인한 화면 깨짐, 숫자·날짜·단위 표기, 지역별 지도·규정 차이. 모듈 47 레슨 7(로컬라이제이션) 의 기법이 쓰인다.
사용적합성과의 경계
IVI 검증은 사용적합성과 겹친다. 그리고 겹치는 부분을 QA 가 혼자 판정하지 않는다.
| 영역 | 담당 |
|---|---|
| 기능이 명세대로 되는가 | QA |
| 주행 중 잠금이 모든 경로에서 걸리는가 | QA — 구현 검증이다 |
| 조작 시간·단계 수가 기준 이내인가 | QA 가 측정, 기준은 설계·안전 쪽 |
| 시선 이탈 시간이 허용 범위인가 | 전용 평가 — 측정 방법과 기준이 정해져 있다 |
| 경고·안내가 실제로 전달되는가 | 사용적합성 평가(모듈 49) |
| 운전자가 기능 상태를 올바르게 이해하는가 | 사용적합성 평가. SOTIF 오사용과 연결(레슨 2) |
네 번째는 전용 평가 영역 이다. 측정 방법과 기준이 지침에 정해져 있고, QA 가 임의로 재서 판정하지 않는다. QA 의 자리는 그 평가가 계획에 있는지 확인하고, 측정 가능한 상태로 기능을 준비하는 것 이다.
여섯 번째가 레슨 2 와 직결된다. 운전자가 기능 상태를 잘못 이해하면 예상 가능한 오사용이 되고, 그것은 SOTIF 영역이다. IVI 의 표시가 그 오해를 만들고 있으면 IVI 결함이 자율주행 안전 문제로 번진다.
실무에서 왜 필요한가
IVI 검증에서 조직이 가장 자주 겪는 문제가 모바일 QA 방식의 전이 다. 기능 시험은 충실히 하는데, 주행 중 제약·소음 조건·전원·온도·부팅 같은 차량 특유 조건이 빠진다. 그 결함들은 전부 실제 주행에서 처음 드러난다.
QA 가 기여할 가장 직접적인 지점은 주행 중 잠금의 모든 경로를 찾는 것 이다. 이것은 구현 검증이고 QA 의 고유 영역이다. 메뉴·음성·연동 화면·단축 조작을 전부 열거해 각 경로에서 잠금이 걸리는지 확인하는 작업은 아무도 체계적으로 하지 않는 경우가 많고, 우회 경로가 실제로 발견된다.
두 번째는 발화·소음 시험 데이터 집합 이다. 혼용 발화, 지명 변이, 속도별 소음. 이것을 모아 두면 음성인식 변경마다 빠르게 확인할 수 있고, 없으면 매번 사람이 즉흥적으로 말해 보는 수준에 머문다.
세 번째는 연동 조합의 대표 선정에 근거를 붙이는 것 이다. 조합은 폭발하고 전수는 불가능하므로 고르는 수밖에 없는데, 고른 근거가 없으면 "왜 그 기기에서 안 되는 걸 못 잡았나" 에 답할 수 없다. 점유·위험·경계 세 축으로 근거를 남긴다.
네 번째는 휴대기기 OS 변경에 대한 출시 후 회귀 계획 이다. 우리가 통제하지 않는 변경이므로 출시로 끝나지 않는다. 이것을 운영 계획에 넣는 것이 QA 의 요구다.
채용시장에서의 위치
이 영역은 완성차·부품사의 IVI·커넥티비티 조직, 차량용 소프트웨어 기업, 그리고 음성·내비 솔루션 기업 의 QA 자리다. 공고에는 "IVI", "인포테인먼트", "AVN", "커넥티비티", "스마트폰 연동", "차량용 음성인식" 같은 말이 적힌다.
특징은 모바일 QA 에서 전이하기 좋은 영역 이라는 점이다. 앱·연결·화면 시험 경험이 쓰이고, 거기에 차량 특유 조건을 더하면 된다. 그래서 자율주행 쪽보다 진입이 수월하고, 수요도 꾸준하다.
면접에서 가르는 질문은 둘이다. "주행 중 잠금을 어떻게 시험하시겠습니까" — "속도를 올려서 확인한다" 로 답하면 약하고, 모든 접근 경로를 열거하고 판정 기준·신호 부재 시 동작까지 말하면 다르다. 그리고 "음성인식 성능을 어떻게 판정하시겠습니까" — 미인식과 오인식을 함께 다루고 소음·발화 조건을 들면 실무자로 읽힌다.