품질 지표는 어떻게 AEB 재시뮬레이션 실패율을 73%에서 3%로 낮추었나?

여러분의 팀은 모든 과정을 올바르게 수행하고, 대규모로 차량 플릿 데이터를 기록하며, 정상적으로 로그를 업로드하고 AEB 오픈 루프 재시뮬레이션 작업을 일괄 실행하지만, 그 중 70% 이상이 실패합니다. 이는 가상의 시나리오가 아닙니다. 이는 품질 지표가 도입되기 전, 플릿 데이터 파이프라인에서 반복적으로 발생하는 실제 실패율입니다.

재시뮬레이션 파이프라인에서 불량 데이터가 초래하는 비용

대부분의 데이터 파이프라인은 하나의 단순한 가정 위에 구축되어 있습니다. 로그가 정상적으로 업로드되었다면, 곧바로 시뮬레이션에 사용할 수 있다는 가정하에 파일은 존재하고, 크기가 올바르며, 전송 오류는 없습니다.

하지만 현실은 매우 취약한 환경을 가지고 있습니다. 업로드 검증을 모두 통과한 로그라도 특정 시간 구간에서 핵심 신호 데이터가 누락되어 있을 수 있으며, 이는 GPU 작업이 실행되고 시뮬레이션 스택이 필요한 데이터를 찾지 못해 실패하기 전까지는 드러나지 않습니다. 이는 드물게 발생하는 엣지 케이스가 아니라, 차량 내에서 작동하는 기록 시스템의 구조적인 특성에서 비롯된 문제입니다. 그리고 이러한 불량 데이터는 한 번의 실패로 끝나지 않고, 이후 단계마다 문제를 증폭시킵니다.

• 스토리지: 사용 불가능한 데이터가 유효한 데이터와 구분되지 않은 채 클라우드에 계속 저장됩니다.
• 연산: GPU 작업이 큐를 점유하고 몇 분간 실행되다가 결국 실패합니다.
• 엔지니어링: 개발자는 시뮬레이션 스택의 버그로 보이는 문제를 추적하지만, 실제로는 데이터 문제로 드러납니다.
• 재시도: 데이터 자체에 근본적인 결함이 있어 동일한 과정이 반복됩니다.

플릿 규모로 보면 이러한 연쇄가 상당한 비용으로 이어집니다. 낭비되는 GPU 연산 자원, 중복 저장 비용, 그리고 디버깅에 소요되는 엔지니어링 시간까지 합치면 상당한 연간 비용으로 누적됩니다. 여기에 실제로는 유효하지만 사용할 수 없는 것으로 판단되어 묻혀버린 테스트 데이터의 기회비용까지 고려하면 그 영향은 더욱 큽니다.

재시뮬레이션이 실패하는 세 가지 원인

주행 로그는 조용히 실패합니다. 그 이유는 기록 시스템과 이후의 안전 검증 단계가 완전성을 다르게 정의하기 때문입니다. 기록 시스템은 모든 파일이 정상적으로 저장되고 전송되면 로그가 완전하다고 판단합니다. 반면, 시뮬레이션 스택은 이론적으로 입력 데이터의 일부 결손을 견딜 수 있도록 설계될 수도 있습니다. 하지만 AEB와 같은 안전 핵심 기능에서 이는 잘못된 접근입니다. 결손된 입력을 그대로 둔 채 스택이 이를 보완하길 기대하는 것은, 저하된 입력 품질을 가리는 것에 불과하기 때문입니다. 주행 안전 기능은 원칙이 명확합니다. 입력 데이터의 품질을 보장해야 하며, 결손은 정의 및 검증된 대체 전략이 있는 경우에만 허용해야 합니다 (예: 터널에서 GPS가 끊긴 경우, 신호가 복구될 때까지 오도메트리와 맵 매칭으로 보완). 이와 같은 전략 없이 발생한 데이터 결손은 시뮬레이션 입력으로 허용될 수 없습니다. 이러한 차이는 플릿 데이터 파이프라인에서 세 가지 반복적인 실패 패턴으로 나타납니다.

실패 1: 차량 버스 데이터의 신호 결손

반자동 제어 장치 피드백은 50Hz로 차량 동역학 신호를 제공합니다. 그중 가장 중요한 것은 종방향 속도로, AEB는 이를 통해 충돌까지의 시간을 계산하고 긴급 제동 여부를 판단합니다. 요 레이트(yaw rate)와 조향각과 같은 추가 신호는 목표 선택을 위한 경로 예측에 사용됩니다. 이러한 피드백이 몇 초라도 결손되고 이를 대체할 수단이 없다면, 해당 데이터는 유효한 평가에 사용할 수 없습니다. 제동 판단에 필요한 신호가 없는 상태에서 AEB 동작을 안전하게 평가하는 것은 불가능하기 때문입니다. 실제 플릿 데이터에서는 카메라와 레이더에는 문제가 없어 보이는데도 수십 분에 걸친 CAN 신호 결손이 발생하는 경우가 있습니다. 파일 수준에서는 문제가 없어 보입니다. 하지만 시뮬레이션은 이러한 입력으로 결과를 생성하지 않습니다. 신뢰할 수 없는 평가를 생성하는 대신 타임아웃으로 종료됩니다. 따라서 해당 구간은 신호 결손이 발생한 전체 구간 동안 사용할 수 없게 됩니다.

실패 2: 로그 경계 및 운행 중단 구간의 빈 데이터

메시지가 전혀 없는 구간은 세 가지 상황에서 발생합니다. 로그가 시작될 때 기록이 먼저 시작된 후 센서가 초기화되는 경우, 종료 시 셧다운 과정에서 발생하는 경우, 그리고 주행 간에 차량이 멈춰 있는 동안 기록 시스템은 계속 동작하지만 일부 토픽이 중단되는 경우입니다. 이 세 가지 경우 모두에서 해당 세그먼트에는 의미 있는 주행 시나리오가 포함되어 있지 않습니다. 또한 메시지 간 최대 시간 간격을 측정하는 표준 품질 지표는, 완전히 비어 있는 세그먼트에서도 값이 0.0으로 나타나 대부분의 필터 조건을 통과하게 됩니다. 이렇게 빈 데이터가 재시뮬레이션으로 전달되면 결국 실패로 이어집니다. 따라서 품질 필터링 시스템은 로그 내 위치와 관계없이 이러한 빈 구간을 명시적으로 탐지하고 제외해야 합니다.

실패 3: 필수 토픽 누락

AEB 재시뮬레이션은 일정한 최소 토픽 집합이 동시에 존재하고 연속적으로 유지되어야 합니다. 여기에는 에고 포즈(ego pose), 차량 동역학, 객체 검출, 차선 정보가 포함됩니다. 주행 안전 기능을 위한 센서 구성이 고도화될수록 이 요구 사항은 확장됩니다. 예를 들어, 레이더 채널은 AEB 목표 구성에 포함되는 요소입니다. 파이프라인에 따라 카메라 데이터에 대한 품질 지표는 존재할 수 있지만, AEB에 중요한 차량 버스 데이터나 레이더 신호에 대한 지표는 포함되지 않는 경우도 있습니다. 특정 세그먼트에서 단 하나의 토픽이라도 누락되면, 시뮬레이션은 유효한 결과를 생성할 수 없습니다. 따라서 품질 지표 체계는 새로운 센서 유형이 추가되더라도 인프라 변경 없이 설정만으로 확장 가능해야 합니다. 현재 요구되는 모든 토픽을 포함하는 품질 지표가 없다면, 해당 세그먼트는 재시뮬레이션 실행 전에 걸러낼 수 없습니다.

품질을 고려한 파이프라인의 구조

이러한 실패를 해결하기 위해서는 품질 평가 시점을 재시뮬레이션 실행 시점이 아니라 데이터 적재 단계로 앞당겨야 합니다. 핵심 구조는 다음과 같습니다. 데이터 적재 단계에서 고정 길이(30초)의 세그먼트별로 품질 지표를 계산하고, 이를 조회 가능한 테이블에 저장한 뒤, 모든 후속 워크플로우 실행 전에 해당 지표를 조회합니다.

각 토픽에 대해 두 가지 지표만으로 세 가지 실패 유형을 모두 확인할 수 있습니다. 하나는 메시지 개수로 데이터 존재 여부를 확인하는 지표, 다른 하나는 메시지 간 최대 시간 간격으로 데이터의 연속성을 확인하는 지표입니다. 세그먼트 필터링은 이러한 지표를 워크플로우별 기준에 맞춰 조회하는 방식으로 이루어집니다. 예를 들어 AEB 재시뮬레이션의 경우, 네 가지 필수 토픽 모두에서 max_gap ≤ 1.0초이면서 동시에 message_count > 0 조건을 만족해야 합니다. 다른 워크플로우(오브젝트 시뮬레이션, 학습 데이터 추출 등)는 동일한 지표를 사용하되, 서로 다른 토픽 집합과 임계값을 적용합니다. 이 과정에서 별도의 재수집은 필요하지 않습니다.

필터링된 세그먼트를 실제 실행 가능한 일괄 작업으로 만들기 위해서는 추가적인 두 단계가 필요합니다. 먼저 체인 감지(Chain detection)를 통해 품질 기준을 통과한 연속된 세그먼트를 하나의 구간으로 묶고, 지나치게 긴 구간은 작업 타임아웃을 방지하기 위해 분할합니다. 또한 간격 기반 복구(Interval-based recovery)를 통해 전체 로그를 폐기하는 대신, 결손 구간 양쪽에 존재하는 유효 데이터를 식별하여 활용할 수 있도록 합니다.

Applied Intuition이 구현한 데이터 엔진

Applied Intuition의 데이터 엔진은 플릿 데이터 수집 및 적재부터 데이터 강화, 탐색, 시뮬레이션, 검증까지 전 과정을 아우르는 엔드투엔드 플랫폼의 일부로서 이 아키텍처를 구현하고 있습니다. 품질 지표는 업로드 이후 데이터 적재 파이프라인 단계에서 Spark 작업을 통해 계산되며, Trino로 조회 가능한 Hudi 테이블에 저장됩니다. 이는 별도로 추가된 도구가 아니라, 시뮬레이션을 트리거하는 동일한 플랫폼 내에 통합된 구성입니다.

이 사례에서는 단 한 명의 엔지니어가 기존 47개 이상의 센서 지표에 더해 AEB 전용 지표 4개를 추가했습니다. 이 지표들은 기존에 포함되지 않았던 차량 버스 관련 토픽을 보완합니다. 새로운 지표 추가는 인프라 변경이 아니라 설정 수준에서 이루어집니다.

지표가 구축된 이후에는 단일 CLI 명령으로 지표 테이블을 조회하고, 유효한 구간을 식별하며, 실행 가능한 일괄 작업 체인을 구성한 뒤 작업을 제출할 수 있습니다. 이 명령은 임계값 설정, 구간 길이 제한, 드라이런 모드 등을 지원합니다. 새로운 품질 문제가 발생하더라도, 한 명의 엔지니어가 데이터 적재 단계까지 원인을 추적하고, 지표를 추가하며, 과거 데이터를 다시 채운 뒤 며칠 내로 수정 사항을 배포할 수 있습니다. 반면, 일반적인 경우 여러 벤더로 구성된 분산된 툴체인에서는 동일한 작업이 팀 간 협업과 조정을 거치며 수개월이 소요됩니다.

결과

샘플 일괄 실행 결과

핵심 수치는 제한된 수집 구간에서 수행된 대표적인 일괄 실행 결과에 품질 필터링과 구간 기반 복구를 함께 적용한 결과를 반영합니다. 재시뮬레이션 실패율은 70% 이상에서 3% 미만으로 감소했으며, 동일한 주행 데이터에서 활용 가능한 유효 테스트 데이터의 양은 87배 증가했습니다. 추가적인 주행 데이터를 수집한 결과가 아니라, 이미 존재하던 데이터를 정확하게 식별함으로써 효율적으로 개선이 가능했습니다.

단일 차량 기준을 확장 적용한 결과

동일한 품질 기반 워크플로우를 특정 수집 구간에서 단일 차량 기준으로 전체 데이터에 적용해보면, 이 접근방식이 어떻게 확장되는지를 확인할 수 있습니다. 결과적으로 데이터 활용률은 74%에 도달했습니다. 즉 수집된 전체 시간의 약 4분의 3이 품질 필터링 이후 AEB 재시뮬레이션에 직접 활용 가능한 것입니다.

지속적인 모니터링: 피드백 루프 완성

한 번 실행되는 품질 필터링 워크플로우는 당장의 문제를 해결할 수 있습니다. 하지만 지속적으로 동작하는 모니터링 레이어는 다음에 발생할 문제 자체를 시뮬레이션 단계에 도달하지 못하도록 막아줍니다.

데이터 엔진은 이 워크플로우를 위해 목적에 맞게 설계된 두 가지 대시보드를 제공합니다. AEB 테스팅 로그 품질 모니터링 대시보드는 플릿 로그 전반에 걸친 토픽별 커버리지 히트맵, 신호 결손 탐지, 그리고 데이터 적재 시점 기준으로 업데이트되는 전체 품질 현황을 제공합니다. AEB 오탐지 모니터링 대시보드는 재시뮬레이션 결과를 기반으로 1,000km당 오탐률(FP rate)을 추적하며, 데이터 품질이 실제 주행 기능의 신뢰도에 어떻게 연결되는지를 보여줍니다.

중요한 점은 이러한 품질 지표가 GPU 작업이 실행된 이후가 아니라, 실행되기 전에 주행 데이터 수집 팀과 스택 성능 팀에 전달된다는 것입니다. 즉, 동일한 인프라를 활용해 실패율을 개선하고, 이후 문제까지 사전에 차단하는 것이 가능합니다.

툴체인 사각지대에서 단일 엔지니어 해결까지

재시뮬레이션 실패율이 70%를 넘으면, 보통 시뮬레이션 자체의 문제처럼 보입니다. 하지만 실제 원인은 달랐습니다. 문제는 툴체인 사각지대, 즉 데이터 적재 단계와 시뮬레이션 실행 사이에서 데이터가 워크플로우 요구사항을 충족하는지 아무도 검증하지 않는 부분에 있었습니다. 여러 벤더로 구성된 분산된 툴체인에서는 이 사각지대를 메우는 데 몇 주에 걸친 협업이 필요합니다. 하지만 통합된 플랫폼에서는 단 한 명의 엔지니어가 며칠 만에 이를 해결할 수 있습니다.

이 개선을 통해 플릿에 이미 존재하던 AEB 테스트 데이터 중 87배 더 많은 유효 데이터를 확보할 수 있었습니다. 또한 이를 전체 차량 설정 기준 수집 구간에 적용했을 때, 기록된 전체 시간의 74%가 AEB 오픈 루프 재시뮬레이션에 직접 활용 가능한 것으로 나타났습니다. 대규모로 신뢰할 수 있는 재시뮬레이션을 구현한다는 것은 단순히 실패율을 낮추는 것을 의미하지 않습니다. 이미 확보된 데이터를 기반으로 통계적으로 의미 있는 ADAS 검증을 가능하게 하는 것입니다.

이러한 흐름은 계속 이어지고 있습니다. 현재 AEB가 적용된 모든 주행 데이터에 동일한 워크플로우가 운영되고 있으며, LDW 오탐지 모니터링 역시 같은 방식으로 확장되고 있습니다. 다음 단계에서는 동일한 엔지니어와 동일한 파이프라인에 추가 인프라 없이 ODD 범주까지 적용 범위가 확장될 예정입니다. 한 명의 엔지니어가 시스템을 구성하고, 데이터 적재부터 결과까지 주행 안전 기능의 오탐지 모니터링 전체 과정을 책임지는 구조입니다.

만일 현재 재시뮬레이션 실패율이 높거나, 기존 주행 데이터에 포함된 유효한 테스트 데이터가 제대로 선별되지 않는다고 느끼신다면, 데이터 엔진의 품질 지표와 모니터링을 꼭 살펴보시기 바랍니다. 데모를 요청하거나 Applied Intuition 팀에 문의하여, 이 글에서 제시한 수치와 비교해 현재 파이프라인을 점검해 보실 수 있습니다.