시나리오 기반 시험과 주행 데이터 재생 — 상황을 만들고 다시 돌리기

개념

두 가지 수단, 다른 질문

레슨 2 에서 영역 3(미지의 위험) 을 줄이는 것이 검증의 목표라고 했다. 그 작업에 쓰이는 수단은 둘이고, 답하는 질문이 다르다.

수단	답하는 질문	한계
주행 데이터 재생	실제로 일어난 상황에서 올바르게 동작했는가	일어나지 않은 상황은 알 수 없다
시나리오 기반 시뮬레이션	만들어 낸 상황에서 올바르게 동작하는가	만든 상황이 현실과 같은지는 별개다

두 한계가 서로를 메운다. 데이터 재생은 현실성 이 보장되지만 범위 가 제한되고, 시뮬레이션은 범위를 넓힐 수 있지만 현실성 을 증명해야 한다.

그래서 둘 다 쓰고, 각각의 결과를 어느 수준의 증거로 쓸지 가른다 — 모듈 63 레슨 4 에서 세운 원칙이 그대로 적용된다.

시나리오의 추상 수준 세 단계

공개 자료가 널리 설명하는 구분이다. 이 구분을 모르면 "시나리오" 라는 말이 회의에서 서로 다른 것을 가리킨다.

[기능 시나리오]  ──파라미터 범위 도입──→  [논리 시나리오]  ──값 선택──→  [구체 시나리오]
  자연어 기술                             범위를 가진 기술              값이 고정된 기술
  사람이 읽는다                           아직 실행 불가                 실행 가능

공개 자료의 설명으로 각 수준은 이렇다.

기능 시나리오(functional scenario) — 시나리오를 비형식 자연어로 기술 한 것. 추상 수준이 가장 높고, 사람이 읽을 수 있으며 해석의 여지가 크게 남아 시뮬레이터에서 직접 실행할 수 없는 것이 일반적이다. 운행 설계 영역이나 운용 개념과 연결된 시나리오를 흔히 이렇게 부른다
논리 시나리오(logical scenario) — 추상 시나리오를 파라미터화 가능한 속성마다 파라미터 범위를 도입 해 구체화한 것
구체 시나리오(concrete scenario) — 각 파라미터 범위에 선택 기법을 적용해 구체적 값을 고정 한 것. 기계가 읽을 수 있고, 모든 동작·조건이 하나의 구체적 값으로 파라미터화되어 있으며, 어느 시점에서든 파라미터와 변수의 변화가 완전히 결정되어 있다

QA 작업이 이 세 수준에 걸쳐 있다.

수준	QA 의 작업
기능	위험 상황을 자연어로 발굴(레슨 2 의 유발 조건 탐색)
논리	파라미터와 범위를 정의. 여기서 경계값 분석이 들어간다
구체	범위에서 값을 고르는 전략 을 정한다(레슨 4 의 커버리지)

논리 수준이 QA 의 핵심 자리 다. 기능 시나리오 하나가 논리 시나리오가 되면서 파라미터가 붙고, 그 파라미터의 범위와 경계 를 정하는 것이 전형적인 QA 작업이다. 그리고 논리에서 구체로 가는 선택이 시험 케이스 수를 정한다 — 범위를 어떻게 쪼개는가가 곧 시험 설계다.

정적과 동적을 나눠 기술한다

시나리오 기술 표준 계열의 구조에서 알아야 할 핵심이 이것이다. 공개 자료는 역할을 이렇게 설명한다.

정적 환경 기술 — 도로와 표지 같은 정적 내용을 기술한다. 직선·곡선 같은 개별 도로 요소를 파라미터화하고 조합해 전체 경로를 구성한다
동적 요소 기술 — 시간에 따라 변하는 동적 요소를 기술한다. 공급사에 독립적인 동적 교통 요소와 기동(maneuver) 라이브러리를 제공한다

구분을 명확히 보여 주는 예가 공개 자료에 있다 — 신호등의 위치는 정적 기술에, 신호가 바뀌는 시각은 동적 기술에 들어간다. 그리고 이 표준 계열이 함께 다층 환경 을 이뤄 운전자 보조·자율주행 환경의 시험·타당성 확인·인증을 지원한다고 안내한다.

표준 이름·버전·구성 요소와 각 요소의 정확한 범위는 해당 표준의 공개 문서에서 확인한다(원문 확인). 버전에 따라 개념이 확장되고 도구 지원 범위가 다르다.

QA 관점에서 이 분리가 뜻하는 바가 있다. 결함이 어느 쪽에서 오는지 가를 수 있다.

증상	의심할 곳
도로 형상이 의도와 다르다	정적 기술
차량이 의도한 대로 움직이지 않는다	동적 기술 또는 시뮬레이터
같은 시나리오가 실행마다 다르다	동적 기술의 비결정성 또는 시뮬레이터 설정
시나리오가 의도한 상황을 만들지 못한다	두 기술의 결합 — 좌표·기준점 불일치

네 번째가 실무에서 자주 생긴다. 동적 기술이 참조하는 위치가 정적 기술의 좌표계와 맞지 않으면, 차량이 의도한 차선에 놓이지 않는다. 그러면 시나리오는 실행되지만 의도한 상황이 아니다 — 그리고 통과한다. 가장 위험한 조합이다.

그래서 시나리오 자체를 검증하는 단계 가 필요하다. 아래에서 다룬다.

시나리오를 먼저 검증한다 — 통과가 거짓일 수 있다

이 레슨에서 가장 실무적으로 중요한 부분이다.

시뮬레이션 시험의 고유한 위험은 시나리오가 의도한 상황을 만들지 못한 채 통과하는 것 이다. 예를 들면 이렇다.

끼어드는 차량을 배치했는데 거리가 멀어 실제로 끼어들지 않았다 → 통과
보행자를 배치했는데 차량 경로 밖에 있었다 → 통과
안개를 설정했는데 센서 모델에 반영되지 않았다 → 통과
정지 차량을 놓았는데 시작 시점에 이미 지나쳐 있었다 → 통과

모두 통과한다. 그리고 "시나리오 1,200건 통과" 에 포함된다. 이것이 자율주행 검증에서 가장 비싼 거짓 안심이다.

막는 방법은 시나리오의 전제 조건을 검사하는 것 이다.

[시나리오 실행]
      ↓
① 전제 조건 검사 — 의도한 상황이 실제로 만들어졌는가?
      ↓ (만들어지지 않았으면 "통과" 가 아니라 "무효")
② 판정 — 시스템이 올바르게 동작했는가?

①이 없으면 ②의 결과를 믿을 수 없다. 전제 조건 검사의 예다.

검사	확인
상호작용 발생	대상 차량과의 최소 거리가 임계 이하로 들어왔는가
경로 교차	보행자·차량의 경로가 자차 경로와 실제로 교차했는가
환경 반영	설정한 날씨·조도가 센서 입력에 반영되었는가
시야 내 존재	대상이 센서 시야에 들어온 시간이 있었는가
시작 상태	시작 시점의 거리·속도가 의도한 값인가
기능 작동	시험 대상 기능이 실제로 켜져 있었는가

마지막이 가장 허무한 실패 다. 기능이 ODD 밖이라고 판정해 꺼져 있는 상태에서 시나리오가 돌면, 아무것도 시험하지 않고 통과한다.

판정 결과를 세 가지로 두는 것 이 실무적 해법이다 — 통과 / 실패 / 무효. 무효는 시나리오 문제이고, 무효 비율이 높으면 시나리오 품질을 손봐야 한다는 신호다. 무효를 통과로 집계하면 커버리지 숫자가 거짓이 된다(레슨 4 와 직결).

주행 데이터 재생 — 보장하는 것과 못 하는 것

기록된 실주행 데이터를 다시 흘려 넣어 인지·판단을 검증하는 방식이다. 현실성이 보장된다 는 강점이 있고, 그래서 인지 알고리즘 검증의 주력이다.

그런데 보장 범위를 정확히 알아야 한다.

보장하는 것

같은 입력에 대한 출력의 변화 를 비교할 수 있다(회귀 검증)
실제로 일어난 상황에 대한 현실적 입력 이다
반복 가능 하다 — 같은 데이터로 몇 번이든 돌린다

보장하지 못하는 것

일어나지 않은 상황 — 기록에 없는 것은 시험할 수 없다
반응이 바뀌면 이후가 달라지는 경우 — 아래에서 다룬다
센서 원시 데이터 수준이 아니면 전처리의 영향을 못 본다
차량 동역학과 제어 — 기록은 그때의 제어 결과이고, 다른 제어를 시험할 수 없다

두 번째가 데이터 재생의 근본 한계 이고, 이해해야 한다.

[기록된 주행]              [재생]
자차가 직진했다      →     판단이 "차선 변경" 을 선택한다
그래서 기록에는            → 그 뒤의 센서 데이터는 "직진했을 때의 장면"
직진한 장면만 있다           → 실제로 차선 변경했다면 보였을 장면이 없다
                             → 그 이후는 무의미하다

즉 자차의 거동이 기록과 달라지는 순간부터 재생은 유효하지 않다. 이것을 개방 루프(open-loop) 의 한계라고 부르고, 대응은 두 가지다.

인지 단계까지만 검증한다. 인지 출력은 자차 거동과 무관하게 비교 가능하다. 데이터 재생의 가장 정당한 용도다
판단·제어는 시뮬레이션(폐쇄 루프) 으로 넘긴다. 자차 거동이 환경에 반영되는 환경이 필요하다

실무에서 자주 벌어지는 오류 가 이 구분을 넘는 것이다. 데이터 재생으로 판단 로직을 검증했다고 보고하는데, 자차 거동이 바뀐 뒤의 결과는 의미가 없다. 어느 시점까지 유효한지 를 결과에 적어야 한다.

재생 검증의 판정 — 기준 라벨이 있는가

인지 출력을 비교하려면 정답 이 필요하다. 세 가지 방식이 쓰인다.

방식	무엇과 비교	한계
사람이 만든 기준 라벨	사람이 표시한 객체 정보	비용이 크고, 라벨 자체에 오류가 있다
이전 버전 출력	직전 버전의 결과	회귀는 잡지만 둘 다 틀린 경우 를 못 잡는다
다른 센서·사후 처리	더 정확한 수단의 결과	그 수단의 정확도가 전제가 된다

두 번째가 실무에서 가장 많이 쓰이고 가장 오해된다. 이전 버전과 같으면 통과로 보는 방식은 회귀 검증 이고, 정확도 검증이 아니다. 둘 다 틀렸으면 영원히 통과한다. 그래서 기준 라벨이 있는 부분집합 을 따로 유지해 정확도를 확인하고, 나머지는 회귀로 본다.

첫 번째의 라벨 오류 도 중요하다. 라벨이 틀리면 정상 출력이 실패로 나오고, 그것을 추적하는 데 시간이 든다. 라벨 품질 검사 가 필요하고, 모듈 39 레슨 11 의 "기준 결과가 어떻게 검증되었는지 기록" 원칙이 그대로 적용된다.

그리고 차이를 비교하는 방식 을 정해야 한다. 객체 목록 비교는 단순 일치가 아니다 — 같은 객체인지 짝짓는 규칙(겹침 정도 등), 허용 위치 오차, 신뢰도 임계가 필요하다. 이 규칙이 비교 결과를 크게 바꾸므로 보고서에 명시 한다. 모듈 39 레슨 11, 모듈 63 레슨 3 에서 반복한 "설정이 숫자를 바꾼다" 와 같은 문제다.

대량 재생의 실무 — 차분을 좁혀 본다

주행 데이터는 양이 크다. 수백 시간의 기록을 매 변경마다 전부 비교할 수 없다. 모듈 39 레슨 11 의 5단계 비교가 여기 그대로 쓰인다.

메타데이터 — 재생 건수, 구간 길이, 결측
요약 통계 — 객체 검출 수, 분류 분포, 신뢰도 분포, 처리 시간
차분 분포 — 이전 버전과의 차이가 몰린 구간
설계된 표본 — 차이가 큰 구간, 기준 라벨이 있는 구간, 알려진 어려운 장면
시각화 — 영상에 겹쳐 보기. 발견 수단이고 판정 수단은 아니다

네 번째의 "알려진 어려운 장면" 을 모아 두는 것이 이 분야의 핵심 자산이다. 레슨 2 에서 식별한 유발 조건에 해당하는 실제 장면들 — 역광 터널 출입구, 공사 구간, 비정형 장애물. 이것을 기준 장면 집합 으로 관리하면 변경마다 빠르게 확인할 수 있다. 모듈 41 레슨 9 의 기준 사례 집합과 같은 발상이다.

시뮬레이션 결과를 증거로 쓰는 조건

시뮬레이션은 범위를 넓혀 주지만, 결과를 증거로 쓰려면 조건이 있다. 모듈 63 레슨 4 의 환경 적격성, 모듈 62 레슨 3 의 "대체하지 못하는 것" 과 같은 구조다.

조건	적어야 하는 것
모델 식별	차량 동역학 모델, 센서 모델, 환경 모델의 버전
모델 타당성	그 모델이 실제와 맞는지 누가 어떻게 확인했는가
시뮬레이터 식별	제품·버전·설정, 시간 간격(step size)
결정성	같은 시나리오가 같은 결과를 내는가
시험 대상 식별	어느 소프트웨어 버전이 들어갔는가
결합 방식	소프트웨어만인가, 하드웨어가 포함되는가(xIL 계층)

두 번째가 핵심이고 자주 비어 있다. 센서 모델이 실제 센서의 성능 한계를 재현하지 못하면, 시뮬레이션에서는 보이는 것이 실제로는 보이지 않는다. 그러면 시뮬레이션 통과가 아무것도 보장하지 않는다. 모델 타당성을 누가 어떻게 확인했는지가 적혀 있지 않은 시뮬레이션 결과는 증거로 쓰기 어렵다 — 모듈 62 레슨 3 의 "검증되지 않은 모델의 결과는 근거가 아니다" 와 같다.

네 번째(결정성) 도 실무 문제 다. 같은 시나리오가 실행마다 다른 결과를 내면 "통과" 가 무슨 뜻인지 모호해진다. 원인은 보통 난수, 병렬 처리 순서, 시간 간격 변동이다. 대응은 모듈 63 레슨 4 의 세 방법 — 고정·반복·여유 다. 고정할 수 없으면 반복해 분포를 남기고, 판정에 여유를 요구한다.

xIL 계층과의 관계

시나리오 기반 시험은 여러 계층에서 돌 수 있다. 모듈 46 레슨 5 의 구분을 시나리오 관점으로 다시 보면 이렇다.

계층	시나리오가 구동하는 것	적합한 용도
소프트웨어만	인지·판단 로직	대량 실행, 조합 탐색
센서 모델 포함	인지 입력부터	유발 조건 탐색
하드웨어 포함	실제 제어기	타이밍·자원 확인
차량 포함(시험장)	실차	최종 확인. 가장 비싸다

아래 계층에서 조합을 대량으로 돌리고, 위 계층에서 선별된 것만 확인 하는 배분이 이 분야의 표준적 설계다. 그리고 계층이 올라갈수록 결과의 증거력이 올라가지만 수가 줄어든다 — 이 교환을 명시적으로 설계하는 것이 QA 의 일이다.

실무에서 왜 필요한가

자율주행 검증 조직에서 가장 흔한 거짓 안심이 "시나리오 N 건 통과" 다. 그 숫자 안에 의도한 상황을 만들지 못한 시나리오 가 섞여 있고, 그것들은 전부 통과로 집계된다. 전제 조건 검사와 무효 판정을 도입하는 것만으로 그 거짓이 드러나고, 보통 처음 도입하면 무효 비율이 놀랄 만큼 높게 나온다.

두 번째로 흔한 오류가 데이터 재생으로 판단 로직을 검증했다고 보고하는 것 이다. 자차 거동이 기록과 달라지는 순간부터 무의미한데, 그 구분 없이 전 구간을 검증 결과로 쓴다. 개방 루프의 한계를 아는 QA 가 "어느 시점까지 유효한가" 를 결과에 적게 만들면 보고의 품질이 달라진다.

세 번째는 기준 라벨 없는 회귀만 돌리는 것 이다. 이전 버전과 같으면 통과인 방식은 둘 다 틀린 경우를 영원히 못 잡는다. 기준 라벨이 있는 부분집합을 유지하라는 요구는 비용이 들지만, 그것 없이는 정확도를 말할 수 없다.

네 번째는 모델 타당성이 비어 있는 시뮬레이션 결과 다. 센서 모델이 실제 한계를 재현하지 못하면 시뮬레이션 통과가 아무것도 보장하지 않는다. "이 모델이 실제와 맞는지 누가 어떻게 확인했습니까" 라는 질문을 할 수 있는 QA 가 있으면 조직이 그 공백을 메운다.

채용시장에서의 위치

이 영역은 자율주행 검증 공고의 중심 역량 이다. "시나리오 기반 검증", "시뮬레이션 검증", "주행 데이터 분석", "회귀 검증 파이프라인", 그리고 시나리오 기술 표준 이름이 직접 적힌다.

특징은 도구를 다루는 역량과 검증을 설계하는 역량이 모두 요구 된다는 점이다. 도구만 다루는 사람은 많고, "이 결과를 어느 수준의 증거로 쓸 수 있는가" 를 판단하는 사람 은 적다. 후자가 희소하다.

면접에서 가르는 질문은 셋이다. "시나리오가 통과했는데 실제로는 아무것도 시험하지 않은 경우를 어떻게 막습니까"(전제 조건 검사와 무효 판정), "데이터 재생으로 판단 로직을 검증할 수 있습니까"(개방 루프 한계), "시뮬레이션 결과를 증거로 쓰려면 무엇이 필요합니까"(모델 타당성).

시나리오 기반 시험과 주행 데이터 재생 — 상황을 만들고 다시 돌리기

개념

두 가지 수단, 다른 질문

시나리오의 추상 수준 세 단계

정적과 동적을 나눠 기술한다

시나리오를 먼저 검증한다 — 통과가 거짓일 수 있다

주행 데이터 재생 — 보장하는 것과 못 하는 것

재생 검증의 판정 — 기준 라벨이 있는가

대량 재생의 실무 — 차분을 좁혀 본다

시뮬레이션 결과를 증거로 쓰는 조건

xIL 계층과의 관계

실무에서 왜 필요한가

채용시장에서의 위치

실습 과제

과제 1 — 세 추상 수준 변환 (30분)

과제 2 — 정적·동적 분리 설계 (25분)

과제 3 — 전제 조건 검사와 무효 판정 (35분)

과제 4 — 데이터 재생의 유효 범위 (30분)

과제 5 — 판정 기준과 비교 규칙 (30분)

과제 6 — 대량 재생 파이프라인과 기준 장면 집합 (30분)

과제 7 — 시뮬레이션 증거 조건 (25분)

자가 체크리스트

흔한 실수

참고 자료

낯선 말 풀이