[자율주행] 장면 검색과 시나리오 마이닝 — '많은 데이터'가 아니라 '맞는 데이터'

들어가며

세 편에 걸쳐 데이터의 '바닥'을 깔았다. 로그를 프레임으로 정규화하고(1편), 시간을 맞추고(2편), 컬럼형 레이크하우스에 쌓았다(3편). 이제 그 위에서 실제로 돌아가는 도구를 이야기할 차례다.

랜딩 페이지의 히어로 카피는 "raw sensor and driving logs → clean, queryable data — and builds the tools people explore it with"이다. 그 '탐색 도구' 중 가장 먼저 오는 것이 장면 검색(scene search) 이다. 이번 글의 질문은 하나다. 수 페타바이트의 주행 중에서, 지금 필요한 그 장면을 어떻게 찾아내는가.

데이터가 많다고 좋은 게 아니다

먼저 자율주행 데이터의 본질을 하나 짚자. 가치는 데이터의 양이 아니라 분포에 있다.

고속도로 직진 프레임은 이미 수백만 장이 있다. 한 장 더 있어도 모델은 눈 하나 깜짝 안 한다. 정작 필요한 건 희귀한 순간들이다 — 갑자기 끼어드는 차, 우산 쓴 보행자, 역광 속 신호등, 눈길 위 급제동. 이런 롱테일(long-tail) 장면이 안전을 가른다. 그런데 이런 장면은 페타바이트 속에 극소량 흩어져 있다.

그래서 자율주행 데이터 엔지니어링의 진짜 레버는 "데이터를 더 모으기"가 아니라 "이미 가진 데이터에서 맞는 장면을 골라내기" 다. 학습 데이터를 무작정 키우는 게 아니라, 큐레이션하는 것. 장면 검색은 그 큐레이션의 엔진이다.

규칙 기반 검색: 아는 것을 찾는다

첫 번째 도구는 이미 1·3편에서 절반쯤 만들어 뒀다. 카탈로그의 메타데이터 컬럼에 SQL을 거는 구조적 검색이다.

1-- '앞차 컷인(cut-in) 직후 급제동' 장면을 찾는다
2SELECT scene_id, frame_id
3FROM   drive_frames
4WHERE  maneuver          = 'cut_in'
5  AND  ego_accel_long    < -3.0      -- 강한 감속
6  AND  lead_gap_m        < 8         -- 앞차와 가까움
7  AND  data_quality      = 'ok'
8ORDER BY timestamp;

빠르고, 정확하고, 설명 가능하다. 조건을 명시했으니 결과가 왜 나왔는지도 안다. 회귀 테스트셋을 구성하거나, 특정 규정 시나리오를 모을 때 최고의 도구다.

그런데 이 방식엔 한계가 하나 있다. 미리 태그해 둔 것만 찾을 수 있다.

규칙의 한계: 모르는 것은 못 찾는다

maneuver = 'cut_in' 으로 검색하려면, 애초에 파이프라인이 컷인을 컷인이라고 태깅해 뒀어야 한다. 그렇다면 아직 이름조차 붙이지 못한 상황은? "본 적 없는 이상한 장면"은 규칙으로 못 찾는다. 규칙 기반 검색은 알려진 미지(known unknowns) 에 강하지만, 알려지지 않은 미지(unknown unknowns) 앞에선 무력하다.

그런데 자율주행에서 사고를 내는 건 대개 후자다. 그래서 두 번째 도구가 필요하다.

임베딩 검색: 비슷한 것을 찾는다

핵심 발상은 이렇다. 장면을 벡터로 바꾼다. 카메라 이미지나 라이다 스캔, 혹은 둘을 합친 멀티모달 표현을 신경망에 통과시켜 하나의 임베딩(embedding) 벡터로 만든다. 의미적으로 비슷한 장면은 벡터 공간에서 가까이 모인다.

그러면 검색이 이렇게 바뀐다. "컷인이라고 태그된 것"이 아니라, "이 장면과 비슷한 것" 을 찾는다. 예제 하나(모델이 틀린 그 프레임)를 던지면, 벡터 유사도로 닮은 장면들을 끌어온다 — query-by-example.

1-- 3편에서 만든 벡터 컬럼에 유사도 검색 (예: pgvector/Lance 계열)
2SELECT scene_id, frame_id
3FROM   drive_frames
4ORDER BY scene_embedding <-> :query_vector   -- 쿼리 장면과의 거리
5LIMIT  200;

이름을 붙이지 않았어도 된다. "이런 느낌의 장면"이라는 예시만 있으면, 태그가 없는 롱테일도 발굴된다. 규칙이 못 잡던 unknown unknowns 를 끌어내는 통로가 바로 이 임베딩 검색이다.

둘을 합친다: 하이브리드 검색

실전에선 둘 중 하나만 쓰지 않는다. 구조적 필터로 범위를 좁히고, 그 안에서 벡터 유사도로 정렬하는 하이브리드가 가장 강하다.

1SELECT scene_id, frame_id
2FROM   drive_frames
3WHERE  weather = 'rain' AND time_of_day = 'night'   -- 구조적 필터(빠른 프루닝)
4ORDER BY scene_embedding <-> :query_vector           -- 그 안에서 의미적 유사도
5LIMIT  200;

"비 오는 밤 중에서, 이 사고 장면과 비슷한 것" — 정확한 조건과 흐릿한 유사성을 한 번에 건다. 3편의 파티션 프루닝(구조적 필터)과 벡터 인덱스(유사도)가 여기서 만난다.

시나리오 마이닝 루프: 데이터 플라이휠

장면 검색이 진짜 위력을 내는 건, 이게 닫힌 루프로 돌 때다.

1[ 모델 배포·평가 ]
2      ↓  실패 케이스 수집 (오검출·미검출·불확실도 높은 프레임)
3[ 실패 장면을 쿼리로 ]
4      ↓  임베딩 검색으로 "비슷한 장면" 대량 발굴
5[ 후보 장면 큐레이션 ]
6      ↓  중복 제거 · 균형 맞춤 · 라벨링
7[ 학습셋에 추가 → 재학습 ]
8      ↺  다시 배포 (다음 바퀴)

모델이 어디서 틀리는지 보고, 그와 닮은 장면을 검색으로 모아, 라벨을 붙여 다시 학습시킨다. 이 바퀴가 돌수록 모델의 약점이 메워진다. 흔히 말하는 데이터 엔진 / 데이터 플라이휠이다. 여기서 장면 검색은 바퀴를 돌리는 축이다 — 검색이 없으면 "실패와 닮은 장면"을 사람이 눈으로 찾아야 하고, 그건 페타바이트에서 불가능하다.

중복과 균형 — 검색만큼 중요한 것

검색으로 10만 장을 끌어왔다고 다 쓰면 안 된다. 자율주행 데이터는 연속적이라, 10Hz로 찍힌 앞뒤 프레임은 거의 똑같다. 이걸 그대로 학습셋에 넣으면 사실상 같은 장면을 수만 번 보여주는 꼴이다.

근접 중복 제거(near-dup): 임베딩 거리가 임계값 이내면 하나만 남긴다.
시나리오 균형: 특정 상황이 과대표집되지 않게 샘플링한다. 고속도로 직진이 데이터셋을 잠식하지 않도록.

즉, 좋은 큐레이션은 "많이 찾기"가 아니라 "찾은 것을 잘 솎기" 까지다.

엔지니어링: 검색을 '제품'으로

이 모든 걸 팀의 엔지니어가 쓸 수 있는 도구로 만들려면, 몇 가지 실제 문제를 넘어야 한다.

ANN 인덱스: 수억 벡터에서 완전탐색은 불가능하다. HNSW·IVF 같은 근사 최근접(approximate nearest neighbor) 인덱스로 밀리초 안에 후보를 좁힌다.
인덱스 신선도: 매일 드라이브가 추가되므로 임베딩·인덱스도 증분 갱신되어야 한다. 3편의 테이블 스냅샷과 발을 맞춘다.
하이브리드 실행: 구조적 필터를 먼저 걸어 벡터 검색 대상을 줄일지, 벡터로 좁힌 뒤 필터할지 — 질의 계획이 성능을 가른다.
UI: 결국 사람이 조건을 걸고, 결과 장면을 라이다·카메라로 겹쳐 보고, 학습셋에 담는 화면이 필요하다. 랜딩의 그 프레임 뷰어가 이 검색 결과의 마지막 표현이다.

이 지점에서 파이프라인이 비로소 제품이 된다. 1~3편이 데이터를 '만드는' 이야기였다면, 장면 검색은 그 데이터를 사람이 쓰게 만드는 첫 도구다.

마치며

정리하면 이렇다. 자율주행의 승부처는 데이터의 양이 아니라 분포이고, 그 분포를 다루는 도구가 장면 검색이다. 규칙으로 아는 것을 찾고, 임베딩으로 모르는 것을 끌어내고, 둘을 하이브리드로 합치고, 그것을 데이터 플라이휠로 돌린다. 그리고 찾은 것을 잘 솎아내는 것까지가 큐레이션의 전부다.

랜딩 페이지의 라이다 뷰어를 "사람이 데이터를 들여다보는 도구"라고 불렀던 이유가 여기서 완결된다. 데이터를 만드는 것(1~3편)과 그 데이터에서 맞는 장면을 찾는 것(이번 편)이 만나야, 비로소 "데이터를 질의 가능하게, 그리고 쓸모 있게 만든다"는 말이 성립한다. 다음엔 이 큐레이션된 데이터가 실제로 GPU까지 흘러가는 길 — 학습 데이터로더와 처리량 — 을 다뤄볼 생각이다.