개념
무한한 시나리오와 유한한 자원
레슨 3 에서 논리 시나리오 하나가 구체 시나리오를 사실상 무한히 만들 수 있다는 것을 봤다. 파라미터 10개에 각각 범위가 있으면 조합은 셀 수 없다.
그래서 이 분야의 중심 질문이 둘이 된다.
- 무엇을 고를 것인가 — 유한한 실행 횟수로 무엇을 덮을 것인가
- 덮었다고 무엇을 말할 수 있는가 — "커버리지" 가 무엇에 대한 비율인가
두 질문 모두 답이 자명하지 않다. 그리고 두 번째가 특히 위험하다 — 정의되지 않은 커버리지 숫자가 출시 판단의 근거로 쓰이는 일이 실제로 일어난다.
조합을 줄이는 세 가지 방법
모듈 3 레슨 5 의 조합 기법이 여기서 가장 큰 규모로 쓰인다. 자율주행 시나리오에서 쓰이는 방법은 세 가지이고, 섞어 쓴다.
1) 등가 분할 + 경계값. 각 파라미터의 범위를 의미 있는 구간 으로 쪼개고 경계를 고른다. 모듈 3 레슨 1 그대로다.
여기서 중요한 것은 구간을 무엇으로 쪼개는가 다. 균등 분할이 아니라 시스템 동작이 달라지는 지점 으로 쪼갠다.
| 파라미터 | 나쁜 분할 | 좋은 분할 |
|---|---|---|
| 자차 속도 | 10 km/h 단위 균등 | 기능 작동 하한, 제어 모드 전환점, ODD 상한 전후 |
| 초기 거리 | 5 m 단위 균등 | 제동 가능 거리, 경고 임계, 센서 유효 범위 경계 |
| 조도 | 균등 | 주/야 전환, 센서 동작 모드 전환, 역광 임계 |
좋은 분할을 하려면 시스템을 알아야 한다. 그래서 이 작업이 QA 와 설계의 공동 작업이 되고, 설계 문서에서 전환점을 찾아내는 것이 QA 의 일이다. 전환점이 문서에 없으면 질의 대상 이다.
2) 조합 기법. 모든 조합이 아니라 쌍 단위 조합 같은 기준으로 줄인다. 파라미터가 10개면 전수 조합은 폭발하지만 쌍 단위는 다룰 수 있는 수가 된다.
다만 자율주행에서 쌍 단위가 충분하지 않은 경우 가 있다. 레슨 2 에서 다중 조합이 영역 3 의 주 서식지 라고 했다 — 야간 + 비 + 곡선 + 공사처럼 셋 이상이 겹칠 때 성능이 급격히 떨어지는 경우가 남는다. 쌍 단위만 쓰면 그것을 놓친다.
실무적 해법은 층을 나누는 것 이다.
[전체 파라미터] → 쌍 단위 조합으로 넓게
[위험 파라미터] → 이 부분집합만 전수 또는 3-way 이상으로 깊게위험 파라미터를 고르는 근거는 레슨 2 의 유발 조건 분석이다. 무엇을 깊게 볼지 고르는 것이 설계이고, 그 근거를 적는 것이 증거 다.
3) 탐색적 생성. 조합을 미리 정하지 않고 실패에 가까운 쪽으로 찾아 들어가는 방식이다. 안전 여유가 작아지는 방향으로 파라미터를 움직여 경계를 찾는다.
이 방식의 가치는 사람이 생각하지 못한 조합을 찾는 것 이고, 한계는 찾은 것이 현실적인지 따로 판단해야 한다는 것 이다. 물리적으로 불가능한 조합이나 ODD 밖 조합을 찾아내면 그것은 결함이 아니다. 현실성 필터 가 반드시 함께 있어야 한다.
세 방법의 역할 분담 이 이렇게 정리된다.
| 방법 | 역할 |
|---|---|
| 등가 분할 + 경계값 | 알려진 위험(영역 2) 을 체계적으로 덮는다 |
| 조합 기법 | 넓은 범위를 효율적으로 훑는다 |
| 탐색적 생성 | 미지 위험(영역 3) 을 파낸다 |
코너 케이스를 운에 맡기지 않는다
"코너 케이스" 는 흔히 드물고 어려운 상황 을 가리킨다. 문제는 드물다는 성질 때문에 우연히 마주치기를 기다리게 된다는 점이다. 그러면 발견은 운이 되고, 영역 3 은 줄어들지 않는다.
코너 케이스를 체계적으로 모으는 경로 가 다섯 있다.
| 경로 | 무엇을 얻는가 | 한계 |
|---|---|---|
| 유발 조건 분석 | 설계에서 유도한 후보 | 생각의 범위를 넘지 못한다 |
| 실주행 데이터 발굴 | 실제로 있었던 어려운 장면 | 기록에 없는 것은 없다 |
| 현장 보고·운영 신호 | 사용자가 겪은 상황 | 늦고 불완전하다 |
| 탐색적 생성 | 경계 근처 조합 | 현실성 판단이 필요하다 |
| 공개 사례·사고 분석 | 다른 조직이 겪은 상황 | 우리 시스템에 맞는지 번역 필요 |
두 번째가 가장 생산적이고 가장 저평가되어 있다. 이미 수백 시간의 주행 데이터가 있는데, 그 안의 어려운 장면을 찾아내는 작업 이 안 되어 있는 경우가 많다.
찾아내는 방법은 신호를 정해 걸러내는 것 이다.
| 발굴 신호 | 어떤 장면을 찾는가 |
|---|---|
| 인지 신뢰도 급락 | 알고리즘이 어려워한 구간 |
| 객체 추적 끊김 | 놓쳤다 다시 찾은 구간 |
| 센서 간 불일치 | 융합이 흔들린 구간 |
| 판단 결정 전환 빈발 | 떨림이 있었던 구간 |
| 운전자 개입 | 사람이 불안해 개입한 구간 |
| 급제동·급조향 | 결과로 드러난 구간 |
| 기능 자동 해제 | 시스템이 포기한 구간 |
다섯 번째(운전자 개입) 가 특히 값지다. 사고가 나지 않았지만 사람이 불안을 느낀 구간이고, 영역 3 의 직접적 단서 다. 이 데이터를 수집하고 분석하는 체계가 있으면 영역 3 탐색이 크게 효율화된다.
일곱 번째(기능 자동 해제) 도 중요하다. 시스템이 스스로 포기한 구간은 ODD 경계나 성능 한계에 닿은 지점이고, 왜 포기했는지 를 분석하면 레슨 2 의 ODD 경계 시험 설계로 직접 이어진다.
이 발굴을 파이프라인으로 돌리는 것 이 실무적 목표다. 새 주행 데이터가 들어올 때마다 신호로 자동 걸러내 후보를 쌓고, 사람이 검토해 기준 장면 집합 (레슨 3) 에 등록한다.
발굴한 장면을 시나리오로 바꾼다
실주행에서 찾은 장면은 구체 시나리오 하나 다. 그것만으로는 한 번만 쓸 수 있다. 가치를 늘리려면 논리 시나리오로 거꾸로 올린다.
[발굴한 실제 장면] ──추상화──→ [논리 시나리오] ──값 선택──→ [구체 시나리오 N개]
한 번 일어난 일 파라미터 + 범위 변형들이 작업이 발굴의 가치를 몇 배로 만든다. 역광에서 정지 차량을 놓친 장면 하나를 논리 시나리오로 올리면, 역광 각도·차량 색·거리·속도 를 범위로 두고 변형을 만들 수 있다. 그러면 "이 한 장면에서 통과" 가 아니라 "이 조건 범위에서 통과" 가 된다.
추상화할 때 정할 것은 셋이다.
- 무엇이 본질인가 — 이 장면이 어려웠던 이유. 역광인가, 차량 색인가, 둘 다인가
- 무엇을 파라미터로 둘 것인가 — 본질과 관련된 축만
- 범위를 어디까지 — 발굴된 값 주변인가, ODD 전체인가
1번이 어렵고 중요하다. 잘못 판단하면 관련 없는 파라미터를 변형하느라 실행을 낭비한다. 그래서 왜 어려웠는지 를 레슨 1 의 단계 분리로 먼저 분석한다 — 인지가 놓친 것인지, 판단이 과했던 것인지.
"커버리지 N%" — 무엇에 대한 비율인가
이 레슨에서 가장 주의가 필요한 부분이다.
자율주행에서 "시나리오 커버리지 85%" 같은 말이 쓰이는데, 분모가 무엇인지 정의하지 않으면 아무 뜻이 없다. 가능한 분모가 여러 개 있고, 각각 다른 의미다.
| 커버리지 종류 | 분모 | 무엇을 말하는가 | 한계 |
|---|---|---|---|
| 시나리오 목록 | 계획한 시나리오 수 | 계획을 얼마나 실행했는가 | 계획 자체의 완전성은 모른다 |
| ODD 파라미터 | ODD 구간의 조합 | ODD 공간을 얼마나 훑었는가 | 조합 폭발. 균등 분할이면 의미가 약하다 |
| 기능 시나리오 | 식별한 기능 시나리오 수 | 유형을 얼마나 덮었는가 | 유형 정의에 따라 달라진다 |
| 요구사항 | 안전 요구사항 수 | 요구를 얼마나 검증했는가 | 요구에 없는 위험은 안 보인다 |
| 코드 구조 | 분기·조건 | 코드를 얼마나 실행했는가 | 모듈 63 레슨 3 의 모든 한계가 적용된다 |
| 실주행 거리 | 누적 주행 거리 | 얼마나 달렸는가 | 거리는 다양성을 뜻하지 않는다 |
마지막이 특히 오해된다. 같은 고속도로를 100만 km 달리는 것과 다양한 조건에서 1만 km 달리는 것은 전혀 다른 증거다. 거리를 커버리지로 쓰면 쉬운 조건을 많이 달려 숫자를 올릴 수 있다. 모듈 48 레슨 5 의 지표 오염과 같은 구조다.
첫 번째의 한계도 분명히 해야 한다. "계획한 시나리오 1,200건 중 1,150건 실행 = 96%" 는 계획을 지켰다는 뜻 이고, 위험을 덮었다는 뜻이 아니다. 계획에 없는 위험은 분모에 없으므로 영원히 100% 로 보인다. 영역 3 은 분모에 들어갈 수 없다 — 레슨 2 에서 "영역 3 이 몇 % 남았다고 말할 수 없다" 고 한 것과 같은 이유다.
그래서 어떻게 보고하는가
단일 숫자로 보고하지 않는다. 여러 커버리지를 각각의 분모와 함께 보고하고, 덮이지 않은 영역을 명시한다.
보고 양식의 골격이다.
[시나리오 실행 현황]
계획 N건 중 실행 M건, 무효 K건 (레슨 3 의 무효 판정)
→ 무효를 제외한 유효 실행 수를 분모로 쓴다
[ODD 파라미터 범위 현황]
파라미터별로 "어느 구간을 실행했고 어느 구간을 실행하지 않았는가"
→ 비율이 아니라 지도로 보인다
[요구사항 검증 현황]
안전 요구사항별 검증 상태와 증거 위치
[영역 3 탐색 현황]
탐색 방법, 범위, 새로 식별한 위험 시나리오 수, 처리 결과
→ 비율로 쓰지 않는다 (레슨 2)
[덮이지 않은 영역과 남은 가정]
실행하지 않은 구간과 그 이유, 전제한 조건두 번째 항목(파라미터 지도) 이 비율보다 유용하다. "속도 60~80 구간은 실행하지 않았음" 이 "커버리지 85%" 보다 훨씬 많은 정보를 준다. 그리고 실행하지 않은 구간이 위험한 쪽인지 를 바로 볼 수 있다.
마지막 항목을 반드시 둔다. 모듈 63 레슨 2 의 목표-증거 매핑, 모듈 40 레슨 8 의 요구-증거 매핑에서 반복된 원칙 — 비어 있는 곳을 명시하는 것이 증거의 신뢰를 만든다. 100% 라고 적힌 보고서보다 "이 범위는 덮지 않았고 그 이유는 이것이다" 가 심사와 출시 판단에서 더 강하다.
커버리지가 거짓 안심이 되는 경로
정리하면 다섯이다. 각각을 막는 장치가 있다.
| 경로 | 막는 장치 |
|---|---|
| 무효 시나리오를 통과로 집계 | 전제 조건 검사와 무효 판정(레슨 3) |
| 분모가 계획이라 계획 밖 위험이 안 보임 | 영역 3 탐색을 별도로 보고 |
| 균등 분할로 의미 없는 구간을 많이 덮음 | 동작 전환점 기준 분할 |
| 쉬운 조건을 많이 실행해 숫자를 올림 | 파라미터 지도로 분포를 보인다 |
| 거리·실행 수를 다양성으로 읽음 | 조건 다양성을 별도 지표로 |
세 번째가 미묘하고 흔하다. 속도를 10 km/h 단위로 균등 분할하면 구간 수가 많아지고, 쉬운 구간을 다 실행하면 커버리지가 높게 나온다. 실제 위험은 전환점 근처 에 있고, 그것은 한두 구간뿐이다. 구간 수가 아니라 위험 가중 으로 봐야 한다.
가중을 어떻게 줄지는 위험 분석 결과 에서 온다 — 기능안전·SOTIF 쪽 분석의 출력이다. QA 가 임의로 가중을 정하지 않고, 분석 결과를 커버리지 설계에 반영 하는 것이 옳은 순서다.
커버리지를 목표로 삼지 않는다
모듈 63 레슨 3 에서 세운 원칙이 여기서도 적용되고, 자율주행에서 특히 중요하다.
옳은 순서
- 위험 분석과 유발 조건에서 시나리오를 만든다
- 실행하고 커버리지를 측정 한다
- 빈 곳을 왜 비었는지 분석 한다
틀린 순서
- 커버리지 지표를 정한다
- 그 숫자를 올리는 시나리오를 만든다
두 번째 방식의 문제는 모듈 63 레슨 3 과 같다 — 숫자는 오르고 위험은 남는다. 그리고 자율주행에서는 더 나쁘다. 쉬운 조건의 시나리오를 대량 생성해 커버리지를 올리는 것이 기술적으로 쉽기 때문이다.
빈 곳의 분석은 네 분류로 한다.
| 빈 곳의 의미 | 처리 |
|---|---|
| 아직 실행하지 않았다 | 실행 계획에 넣는다 |
| 실행할 수 없다(환경 한계) | 다른 계층에서 확인하거나 남는 위험으로 기록 |
| ODD 밖이다 | 근거를 적고 제외 |
| 물리적으로 불가능하다 | 근거를 적고 제외 |
두 번째가 정직하게 기록되어야 한다. 시뮬레이터가 재현하지 못하는 조건, 실차로만 가능한데 시간이 없는 조건. 이것을 "덮었다" 로 처리하면 거짓이고, 남는 위험으로 기록 하면 조직이 판단할 수 있다.
실무에서 왜 필요한가
자율주행 검증 조직에서 커버리지 숫자가 출시 판단에 쓰인다. 그리고 그 숫자가 무엇에 대한 비율인지 정의되지 않은 채 쓰이는 일이 흔하다. "시나리오 커버리지 95%" 가 보고되고, 경영 판단이 그것을 근거로 내려진다.
QA 가 할 가장 큰 기여는 분모를 명시하게 만드는 것 이다. "무엇에 대한 95% 입니까" 라는 질문 하나가 보고의 성격을 바꾼다. 그리고 단일 숫자 대신 파라미터 지도와 덮이지 않은 영역 을 보이면, 판단의 품질이 달라진다.
두 번째 기여는 실주행 데이터 발굴 이다. 조직에 이미 수백 시간의 데이터가 있는데 어려운 장면을 체계적으로 찾아내는 작업이 안 되어 있는 경우가 많다. 신호를 정해 걸러내는 파이프라인을 만들면 영역 3 탐색의 효율이 크게 오르고, 그 성과는 바로 보인다.
세 번째는 발굴한 장면을 논리 시나리오로 올리는 것 이다. 한 장면에서 통과한 것과 그 조건 범위에서 통과한 것은 전혀 다른 증거다. 이 추상화 작업은 도메인 이해와 시험 설계가 함께 필요해서, QA 가 하기 가장 적합하다.
네 번째는 균등 분할을 전환점 기준 분할로 바꾸는 것 이다. 이것만으로 같은 실행 횟수에서 발견되는 결함이 늘어난다. 전환점을 설계 문서에서 찾고, 없으면 질의로 올리는 작업이 전제다.
채용시장에서의 위치
이 영역은 자율주행 검증 공고의 "시나리오 커버리지", "코너 케이스 발굴", "검증 전략" 에 해당한다. 그리고 검증 리드·시니어 자리의 핵심 역량이다 — 개별 시험을 수행하는 것과 무엇을 얼마나 덮었는지 설명하는 것 은 다른 수준의 일이다.
면접에서 가르는 질문이 분명하다. "커버리지를 어떻게 정의하십니까." 단일 숫자로 답하면 약하고, 분모의 종류를 열거하고 각각의 한계를 말하면서 파라미터 지도와 덮이지 않은 영역을 함께 보고한다 고 답하면 즉시 구분된다. 그다음 질문은 보통 "코너 케이스를 어떻게 모읍니까" 이고, 실주행 데이터 발굴 신호를 들 수 있으면 실무자로 읽힌다.
그리고 이 역량은 AI 시스템 검증 전반 으로 전이된다. "무엇을 덮었다고 말할 수 있는가" 는 의료 AI(모듈 66), LLM 평가(모듈 18b), AI 품질(모듈 36·57) 에서 같은 모양으로 나타나는 질문이다.