[자율주행] Data Flywheel 설계와 운영 — 수집 로그를 검증된 개선으로 연결하기

데이터가 늘었는데 모델은 같은 상황에서 계속 실패한다면, 수집량보다 먼저 실패가 다음 학습과 평가로 이어지는 경로를 살펴볼 필요가 있다. 어떤 상황이 부족한지, 그 상황을 어떻게 찾았는지, 새 데이터를 넣고 무엇이 개선됐는지가 연결되어야 한다.

(Data Flywheel) 은 관찰한 문제를 데이터 수집·선별·학습·검증에 반영하고, 다시 운용 결과를 관찰하는 반복 체계다. 이름처럼 저절로 가속되는 것은 아니다. 편향된 데이터나 잘못된 라벨이 돌아오면 같은 실수를 강화할 수도 있다.

이 글은 데이터 개발자가 그 연결을 어떻게 설계하고 측정할지 정리한다. 기술 설명은 일반적인 설계 제안이며, 특정 회사의 비공개 시스템이나 운영 성과를 설명하지 않는다. 산업 동향은 2026년 10월 3일 확인한 공개 자료를 기준으로 한다.

먼저 문제와 성공 조건을 정한다

“희귀한 장면을 더 모으자”만으로는 다음 일을 정하기 어렵다. 예를 들어 “야간 우천의 공사 구간에서 임시 차선과 기존 차선을 혼동한다”는 관찰을 다음처럼 나눌 수 있다.

대상 조건: 야간·우천·공사 구간·차선 변경. 어떤 도로와 속도 범위에서 문제를 다룰지 명시한다.
확인할 오류: 차선 인식 오류인지, 경로 선택인지, 차량 제어인지 로그로 구분한다.
필요한 데이터: 실패 구간과 전후 맥락, 비슷하지만 성공한 구간, 평상시 성능을 확인할 대조 집합.
성공 조건: 해당 조건의 오류 감소와 기존 조건에서의 회귀 여부. 평균 점수 하나로 끝내지 않는다.

(Operational Design Domain) 는 시스템이 동작하도록 설계된 도로·지역·날씨·속도 등의 조건 범위다. 새로운 데이터가 ODD 안의 성능 개선을 위한 것인지, ODD 확장을 위한 것인지도 구분해야 평가 기준이 선명해진다.

전체 구조 — 단계보다 연결할 산출물이 중요하다

1운용 중 문제 관찰
2  ↓ 문제 정의·수집 캠페인
3차량 기록·업로드
4  ↓ 무결성·권한·시간·캘리브레이션 검증
5정제·파생 신호·검색 인덱스
6  ↓ 목적에 맞는 장면 선별
7자동 라벨링·사람 검수
8  ↓ 품질 검사·데이터셋 버전 확정
9학습·열린 루프 및 닫힌 루프 평가
10  ↓ 배포 판단·관찰 계획
11검증된 범위에서 운용 → 다음 문제 관찰

여기서 클립은 판단에 필요한 전후 맥락을 포함한 시간 구간이다. 모든 시스템이 같은 길이를 써야 하는 것은 아니다. 프레임, 클립, 로그, 데이터셋의 식별자를 구분하고 서로 연결해야 한다. 공개 데이터셋의 scene 역시 의미가 다르므로 씬과 샘플의 정의를 확인한다.

단계	다음 단계에 넘길 것	놓치기 쉬운 조건
수집·업로드	원본 로그, 차량·센서 구성, 트리거 버전, 업로드 상태	선택되지 않은 상황을 관찰할 기준 표본도 필요하다
정제·인덱싱	검증 결과, 시간축·좌표계, 파생 신호와 생성 버전	손상·시간 불일치를 정상 데이터처럼 통과시키지 않는다
선별·라벨링	선택 이유, 작업 명세, 라벨·검수 버전	모델의 낮은 신뢰도만으로 모든 검수 대상을 정하지 않는다
데이터셋 확정	변경 불가능한 파일 목록과 버전 묶음	같은 검색 조건이 나중에 다른 결과를 내는 문제를 막는다
학습·평가	모델·코드·설정·데이터·평가 버전과 결과	목표 조건의 개선과 다른 조건의 회귀를 함께 확인한다
운용·관찰	배포 버전, 관찰 조건, 문제와 대응 기록	배포 후 발견한 문제를 다음 수집과 연결한다

이 연결을 추적하는 것이 리니지(lineage, 데이터와 결과의 생성 이력) 다. “이 모델이 왜 이 장면에서 바뀌었나”라는 질문에 원본·가공·라벨·학습 버전을 거슬러 답할 수 있어야 한다.

무엇을 수집하고 무엇을 라벨링할 것인가

차량의 모든 데이터를 동일한 해상도로 보관·전송·라벨링하는 비용은 크다. 그래서 데이터 트리거 — 특정 조건을 감지해 관련 구간을 보존하거나 업로드하는 규칙 — 와 서버의 선별 작업을 조합한다. 트리거에는 조건뿐 아니라 모델·규칙 버전, 전후 기록 길이, 중복 제거 기준, 전송 우선순위도 필요하다.

선별 점수는 한 가지로 고정하지 않는다.

선별 근거	유용한 경우	함께 확인할 한계
확인된 실패·검토 이벤트	현재 문제를 개선할 사례를 모을 때	개입이나 불일치만으로 실패가 확정되지는 않는다
모델 불확실성·모델 간 불일치	판단이 어려운 후보를 찾을 때	모든 모델이 확신하며 틀리는 사례는 놓칠 수 있다
임베딩의 새로움·다양성	기존 데이터와 다른 분포를 찾을 때	시각적 차이가 학습 가치나 안전 중요성과 같지는 않다
·시나리오 조건	부족한 날씨·지역·기동을 채울 때	태그를 생성한 모델 자체의 오류를 점검해야 한다
무작위 기준 표본	원래 분포와 선별 편향을 추정할 때	드문 상황은 별도 표적 수집으로 보완해야 한다

임베딩은 장면을 비교 가능한 숫자 벡터로 표현한 것이다. 비슷한 실패를 확장 검색하는 데 도움이 되지만, 가까운 벡터가 같은 실패 원인을 보장하지는 않는다. 데이터 선별의 효과는 같은 예산의 무작위 기준과 비교하고, 중복·라벨 비용·목표 조건의 개선을 함께 측정한다.

을 붙일 때도 생성량만 세지 않는다. 라벨 규칙과 버전, 사람 검수와 품질 게이트, 최종 승인된 라벨을 얻기까지의 총시간을 연결한다.

섀도 모드와 개입은 정답을 대신하지 않는다

섀도 모드(shadow mode) 는 후보 모델이 관측을 받아 출력을 계산하되 실제 차량 제어에는 사용하지 않는 운용 방식이다. 실제 운전과 후보의 출력이 다른 구간을 검토 대상으로 찾을 수 있다.

하지만 사람이 감속했고 후보는 감속하지 않았다는 사실만으로 후보가 틀렸다고 확정할 수 없다. 사람의 판단도 오류나 선호를 포함한다. 안전 운전자의 개입 역시 예방적 행동·승차감·시험 절차 때문일 수 있다. 따라서 불일치와 개입은 검토할 신호이고, 실패 판정과 학습 라벨은 후속 분석 결과다.

또 후보가 실제로 조작했다면 이후 관측과 다른 차량의 반응이 달라졌을 것이다. 섀도 모드의 로그만으로 그 반사실적 결과를 직접 관찰할 수는 없다. 기록된 입력에 대한 비교와 닫힌 루프 시뮬레이션, 검증된 범위의 실차 시험을 함께 사용해야 한다.

Data Portal — 검색 결과를 재현 가능한 데이터셋으로

Data Portal은 영상을 찾아보는 화면에서 끝나지 않는다. 사용자가 무엇을 찾았고, 어떤 근거로 골랐으며, 어떤 버전을 학습에 넘겼는지를 남기는 접점이다.

“비 오는 밤의 공사 구간”을 검색했다면 날짜·지역·권한 같은 구조화된 필터와 의미 검색을 함께 사용할 수 있다. 결과에는 해당 태그의 생성 모델·신뢰도, 라벨 유무, 시간 정합 상태, 미리보기와 원본 위치를 보여준다. 검색 결과가 없을 때는 실제로 없는 것인지, 인덱싱이 늦었거나 태그가 놓친 것인지 구분할 단서가 필요하다.

평가도 응답 속도만으로 끝내지 않는다. 검수한 질의 집합에서 상위 결과의 관련성, 알려진 양성 사례를 찾는 비율, 인덱스 최신성, 데이터셋 생성 성공률을 잰다. 전체 정답 집합을 모른다면 검색 재현율을 완전히 측정했다고 주장하지 않는다.

검색 조건을 저장하는 것과 데이터셋을 고정하는 것은 다르다. 데이터가 추가되거나 태그 모델이 바뀌면 같은 질의도 다른 결과를 반환한다. 학습용으로 확정할 때는 매니페스트(manifest, 데이터셋을 구성하는 정확한 항목 목록) 를 남긴다.

1dataset_id / dataset_version
2원본 객체 URI + 객체 버전 또는 콘텐츠 해시
3log_id / clip_id / 센서·시간 범위
4선택 질의 + 검색·태그·임베딩 모델 버전
5캘리브레이션·포즈·전처리 버전
6라벨 명세·라벨 데이터 버전
7split 정책·평가 격리 규칙
8접근 정책·보존 기간·생성 이력

저장소의 객체 버전·보존 정책까지 맞아야 매니페스트가 가리킨 데이터를 다시 읽을 수 있다. 삭제 의무나 접근 제한이 생기면 파생 데이터와 매니페스트의 가용 상태도 갱신해야 한다. 이를 “불변 데이터셋이니 영구 보존”으로 오해하면 안 된다.

Data Pipeline — 다시 실행해도 설명 가능한 결과

파이프라인의 성공은 작업 상태가 초록색이라는 뜻보다 넓다. 정확한 원본과 처리 버전으로 예상한 산출물이 만들어졌고, 늦거나 실패한 데이터가 어디에 있는지 설명할 수 있어야 한다.

운영 문제	설계할 계약
같은 업로드·작업이 반복됨	원본 식별자·콘텐츠 해시·처리 버전을 키로 삼아 확보. 같은 작업을 반복해도 중복 결과가 생기지 않게 한다
로그 일부가 손상되거나 시계가 맞지 않음	검사 결과와 이유를 기록하고 격리. 정상 파티션과 섞지 않으며 재처리 경로를 둔다
늦게 도착한 데이터	캡처 시각과 수신 시각을 구분하고, 완료 판정·추가 반영·평가 세트 편입 정책을 정한다
스키마·이 바뀜	호환성 검사와 영향 범위 추적. 처리 코드만 최신으로 바꿔 과거 결과를 덮어쓰지 않는다
과거 데이터를 다시 처리함	백필(backfill) 의 대상과 버전을 고정하고 새 결과를 검증한 뒤 공개한다
입력이 처리 능력을 넘음	큐 깊이·대기 시간·우선순위·재시도 상한을 관리하고, 한 실패가 전체 지연으로 번지지 않게 한다

특히 시간 정합은 기록 순서만 맞추는 작업이 아니다. 센서 캡처 시각, 포즈 보간, 점별 시각, 캘리브레이션 유효 구간을 처리 계약에 넣는다. MCAP은 기록을 담는 컨테이너이고, 분석용 변환과 플랫폼 운영은 그 위의 별도 책임이다.

데이터 누수 — 좋아진 것처럼 보이는 가장 쉬운 길

데이터 누수(data leakage) 는 학습에 쓰인 정보가 평가에도 섞여 실제보다 좋은 성능을 보이게 하는 문제다. 주행 데이터에서 프레임을 무작위로 나누면 같은 연속 주행의 거의 같은 장면이 학습과 평가에 함께 들어가기 쉽다.

연속 로그·클립을 같은 그룹으로 묶고, 평가 목적에 맞게 경로·지역·날짜·차량의 겹침을 통제한다. 모든 축을 무조건 분리하기보다 무엇에 대한 일반화 성능을 주장할지 정한다.
이미지·의 근접 중복뿐 아니라 같은 원본에서 만든 합성 변형, 재라벨링본, 재처리본의 부모 이력도 추적한다.
모델 선택에 반복 사용하는 개발용 검증 세트와, 최종 성능 확인에 사용하는 잠금 평가 세트를 구분한다.
평가에서 발견한 실패를 학습에 넣었다면, 그 사례는 회귀 확인용으로 남길 수 있다. 다만 이후 그 점수를 미관측 데이터에 대한 일반화 성능처럼 보고하지 않는다.
자동 라벨러나 태그 모델이 평가 데이터에 접근하는 경로도 점검한다. 평가용 정답의 독립성과 검수 기준을 별도로 관리한다.

어제의 실패를 오늘 학습시키는 것 자체는 의 목적에 맞는다. 문제는 그렇게 학습한 장면의 점수 상승을 새로운 상황에 대한 성능으로 해석하는 것이다.

무엇을 재야 루프가 나아졌다고 말할 수 있나

다음은 조직별 기준을 정할 때 사용할 지표 제안이다. 아래 수치를 업계 표준이나 특정 회사의 실적으로 제시하는 것은 아니다.

지표	정의할 분모·범위	읽을 때 주의할 점
문제 발견 → 학습 준비 시간	동일한 시작·완료 조건으로 P50·P95 측정	라벨 대기·재처리·사람 승인 시간을 나눠 본다
유효 클립 수율	검수상 목적에 맞는 클립 / 검토한 클립	중복 제거 기준과 목적을 함께 고정한다
커버리지 증가	필요한 시나리오 구간 중 새로 충족한 범위	쉬운 구간을 많이 채워 평균을 높이지 않는다
유효 클립당 총비용	수집·처리·저장·라벨·검수 비용 / 승인 클립	자동 라벨의 수정 비용과 실패 작업도 포함한다
데이터 추가의 개선 효과	고정 평가 조건에서 기준 대비 변화	코드·연산량·데이터량을 통제하고 반복 실행 변동을 본다
회귀·안전 관련 지표	별 충돌·위반·불편 행동 등과 노출량	MPI나 단일 평균 점수만으로 안전성을 결론 내리지 않는다
재현·운영 품질	데이터셋 복원 성공, 산출물 누락, 인덱스 지연	속도를 위해 시간 정합과 품질 검사를 생략하지 않는다

P95는 관측한 처리 시간의 95%가 그 값 이하라는 뜻이다. 평균이 짧아져도 특정 센서나 라벨 유형이 계속 지연된다면 루프의 병목은 남아 있다. 지표는 차량·센서·지역·태스크별로 나눠 확인하는 편이 좋다.

2026년 산업 흐름 — 공개된 사실과 해석을 나눠 읽기

아래는 시장 전체의 점유율 비교가 아니라, 데이터 개발 업무와 직접 연결되는 공식 발표 네 가지다. 발표일과 확인 범위를 표시했으며, 기업의 설명을 독립적인 성능 검증 결과로 취급하지 않는다.

현대차그룹·42dot: 수집에서 검증까지 연결하는 개발 체계

공개된 사실 · 2026-09-13. 현대차그룹은 데이터 수집 전용 차량 약 40대 운영, 하드 이그잼플 마이닝, 반복 학습, 실차 로그 기반 가상 검증을 소개했다. 센서 체계의 단계적 표준화 방향도 발표했다. 공식 발표 원문

데이터 개발 관점의 해석. 수집 차량이 늘어날수록 센서·스키마·시간· 계약과 재처리 체계의 중요성이 커진다. 발표만으로 내부 처리 지연, 데이터 선별 수율이나 비용 개선 폭까지 알 수는 없다. 따라서 “데이터가 많아진다”와 “검증된 개선을 더 빨리 만든다”를 구분해서 읽어야 한다.

NVIDIA: 큐레이션·생성·평가를 묶는 도구 공급

공개된 사실 · 2026-03-16. NVIDIA는 Physical AI Data Factory Blueprint를 발표하며 데이터 정제·검색, 합성 데이터 증강, 평가·필터링을 연결하는 참조 아키텍처를 설명했다. 공식 발표 원문

데이터 개발 관점의 해석. 외부 도구로 대체할 수 있는 처리 단계가 늘어도, 원본과 생성 데이터의 계보·품질 기준·라이선스·총비용은 플랫폼에서 관리해야 한다. 발표의 자동화·비용 절감 주장을 자체 데이터에서의 효과로 바로 바꿔 읽을 수는 없다. 생성량보다 승인된 유효 데이터와 평가 개선을 비교해야 한다.

Waymo: 로그 재현을 넘어 생성형 시나리오로

공개된 사실 · 2026-02-06. Waymo는 World Model이 언어, 주행 입력, 장면 배치로 시뮬레이션을 제어하고 카메라·라이다 출력을 생성하는 방식을 공개했다. 차량에서 직접 관찰하지 못한 희귀 상황을 시험하는 사례도 제시했다. 공식 발표 원문

데이터 개발 관점의 해석. 생성된 장면은 원본 로그·생성 모델·조건·시드·평가 버전까지 연결해 관리할 필요가 있다. 시각적으로 그럴듯한 것, 물리적으로 타당한 것, 학습과 안전 평가에 유효한 것은 각각 다른 기준이다. 데모 영상만으로 모든 조건의 시뮬레이션 타당성이 입증되지는 않는다.

AWS: 공간·고정밀 시간 데이터를 테이블에서 다루기

공개된 사실 · 2026-09-30. AWS는 S3 Tables에서 Iceberg V3의 geometry·geography·나노초 타임스탬프 등 데이터 타입과 컬럼 기본값을 지원한다고 발표했다. 공식 발표 원문

데이터 개발 관점의 해석. 위치·주행 구간·이벤트 시각을 카탈로그에 표현할 선택지가 넓어진다. 다만 나노초를 저장할 수 있다는 사실이 센서의 시계 정확도나 동기화를 보장하지는 않는다. 실제 채택 전에는 사용하는 쿼리 엔진·SDK의 지원, 파티션·인덱스 설계, 마이그레이션을 확인해야 한다.

네 발표에서 공통으로 읽을 수 있는 방향은 데이터 확보뿐 아니라 선별·생성·평가·재사용의 연결이 제품과 도구의 경쟁 지점이 되고 있다는 것이다. 이는 공개 자료에 대한 해석이며, 네 회사의 주행 성능이나 사업 우위를 순위로 매긴 결론은 아니다.

기존 글을 한 흐름으로 읽는 법

처음이라면 씬 데이터로 시간 단위를 구분한 뒤 로그 데이터와 포맷 → MCAP → AV 데이터 플랫폼 순서로 읽으면 된다.

그다음 어노테이션 데이터와 자동 라벨링 루프로 품질 관리에 들어가고, VLA·VQA와 파운데이션 모델에서 검색·태깅의 확장을, 시뮬레이션과 리시뮬에서 평가의 범위와 한계를 확인할 수 있다.

Data Flywheel의 시작은 거대한 도구 목록이 아니라 반복되는 문제 하나를 선택하고, 그 문제의 데이터·처리·라벨·모델·평가 이력을 끝까지 연결하는 것이다. 그 연결이 확인되면 병목을 측정하고 다음 조건으로 범위를 넓힐 수 있다.

참고 자료

산업 발표는 각 절의 원문 링크에서 발표 시점과 주장 범위를 확인할 수 있다. 아래는 데이터셋과 평가 구조를 더 읽을 때 참고할 기술 자료다.

Apache Iceberg 사양 — 테이블 스냅샷과 스키마·파티션 진화. 테이블 버전만으로 외부 원본·라벨·모델의 전체 재현성이 자동 보장되지는 않는다.
nuPlan 논문 — 계획 평가에서 지표의 한계와 닫힌 루프 평가의 필요성.
nuScenes 데이터 스키마 — ·sample·센서 데이터·포즈·라벨을 연결하는 공개 사례.