[자율주행] AV 데이터 플랫폼 — 스토리지·레이크하우스·시각화가 맞물리는 자리

로그 데이터와 포맷에서 "record 는 , analytics 는 "이라는 2층 구조를 이야기했다. 이 글은 그 2층이 실제로 어떤 인프라 위에 놓이는지를 본다. 저장소, 처리 엔진, 카탈로그, , 시각화가 어디서 맞물리는가.

먼저 문제부터 정확히 놓는다.

자율주행이 스토리지에 거는 두 부하

일반적인 데이터 플랫폼과 다른 점이 여기 있다. 성격이 정반대인 두 부하가 같은 데이터 위에 걸린다.

부하 A — 거대한 순차 읽기 수십 GB 짜리 로그를 리플레이하고, 변환하고, 시뮬레이션에 흘려 넣는다. 처음부터 끝까지 순서대로 훑는다. 대역폭이 전부다.

부하 B — 수십억 개의 작은 무작위 읽기 학습 배치는 이미지 조각과 프레임을 무작위 순서로 집는다. 한 스텝에 수백 개 파일, 초당 수천 개. 지연이 전부다.

전통적인 HDD 기반 데이터 레이크는 A 는 잘하고 B 에서 무너진다. 디스크 탐색 시간이 쌓이면서 GPU 가 데이터를 기다리며 논다. "GPU 사용률 40%"라는 증상은 대부분 모델이 아니라 여기서 온다.

전체 그림

 차량
  │  기록 (MCAP)
  ▼
 인제스트 ─── 무결성 검사(mcap doctor) · 메타 추출 · 개인정보 마스킹
  │
  ▼
┌──────────────── 저장 계층 ────────────────────────────┐
│  핫  : 올플래시 공유 스토리지 (VAST 등)               │  최근·학습 중
│  웜  : 오브젝트 스토리지 (S3 계열)                     │  일반 아카이브
│  콜드: 아카이브 티어                                  │  법적 보존
└───────────────────────────────────────────────────────┘
  │                          │
  │ 대규모 변환 (Spark)      │ 리플레이·시뮬
  ▼                          ▼
┌── 레이크하우스 (Delta/Parquet) ──┐        시뮬레이션 · 회귀 테스트
│  frames / objects / labels /     │
│  scene_tags / calib_versions     │
└──────────────────────────────────┘
  │ SQL 큐레이션
  ▼
 학습 세트 → 학습 클러스터 (샤드·캐시·GPU 디코딩)
  │
  ▼
 모델 → 배포 → 실패 로그 → (다시 위로)

 ─── 옆으로 항상 붙어 있는 층 ───
 Foxglove (로그 열어보기·공유)   Rerun (개발 중 파이프라인 관찰)

이제 층별로 본다.

저장 계층화 — 전부 플래시에 둘 수는 없다

올플래시 공유 스토리지는 부하 B 를 정면으로 겨냥한다. 모든 노드가 모든 데이터를 균일한 지연으로 읽는 구조라, 학습 노드가 늘어도 특정 디스크에 몰리지 않는다. 같은 플랫폼이 자율주행·AI 데이터 레이크에서 자주 거론되는 이유가 이것이다.

여기서 나오는 실무적 값어치는 성능만이 아니다. 복사본이 줄어든다.

NFS 로도 S3 로도 같은 데이터가 보이면, 기록·변환·학습·시각화가 각자의 프로토콜로 같은 원본을 본다. 파이프라인 단계마다 페타바이트를 옮겨 붙이는 일이 사라진다. 자율주행 데이터 인프라에서 가장 큰 낭비가 대개 이 복사다.

다만 비싸다. 그래서 설계는 계층화로 간다.

계층	무엇을	왜
핫 (플래시)	최근 N주 로그, 학습 중인 데이터셋, 골든 평가셋	무작위 읽기가 걸린다
웜 (오브젝트)	일반 아카이브, 과거 로그	가끔 순차로만 읽는다
콜드 (아카이브)	법적 보존, 사고 관련	거의 안 읽는다

계층 이동을 자동화하는 정책이 실제 비용을 정한다. "90일 안 읽힌 로그는 웜으로" 같은 규칙이 없으면 핫 계층이 계속 부풀고, 결국 사람이 손으로 지우다가 필요한 걸 지운다.

작은 파일 문제

에는 별도의 함정이 있다.

요청당 지연이 크다. 작은 파일 수백만 개를 하나씩 가져오면 학습이 I/O 에 묶인다.
리스팅이 느리다. 디렉터리 개념이 없어 접두사 스캔이 비싸다. 파일 목록 자체를 카탈로그 테이블로 관리해야 한다.

해법은 샤딩이다. 작은 파일을 순차 읽기 가능한 큰 샤드로 묶는다(WebDataset 형식의 tar, 또는 안에 바이너리로). 학습 로더는 샤드를 순차로 읽고 셔플은 버퍼 안에서 한다.

반대로 좋은 소식 하나 — 은 Range 요청과 궁합이 좋다. 파일 끝의 인덱스만 당겨 목차를 읽고, 필요한 만 부분 요청으로 가져올 수 있다. 페타바이트를 옮기지 않고 3초짜리 조각을 꺼내는 게 이래서 가능하다.

질의 층 — 레이크하우스

원본만 있으면 "비 오는 밤 좌회전 중 보행자"를 찾을 수 없다. 로그를 훑어 파생 신호를 컬럼으로 구워야 비로소 질의가 된다.

이 층에서 같은 플랫폼이 맡는 자리는 넷이다.

대규모 변환 — 수만 개 로그 파일을 로 병렬로 열어 요약 행을 뽑는다. 여기서 주의할 점 하나: 로그 하나는 순차 스트림이라 파일 안을 쪼개 병렬화하기 어렵다. 병렬성 단위가 파일 개수이므로, 로그 분할 정책이 곧 처리 성능이 된다.
질의· — 위 SQL.
거버넌스 — 누가 어떤 주행 데이터에 접근했는지, 어떤 테이블이 어디서 파생됐는지(리니지). 얼굴과 번호판이 찍힌 영상이 섞이는 도메인이라 선택이 아니다.
실험 추적 — 데이터 스냅샷 버전과 모델 실험을 묶는다.

그리고 하지 말아야 할 것 하나. 원본 센서 데이터를 플랫폼 안으로 다 밀어 넣지 않는다. ·영상은 스토리지에 두고, 에는 메타·파생 신호와 포인터를 둔다. 원본을 테이블에 밀어 넣으면 비용이 폭발하고 이점은 없다.

무엇을 컬럼으로 굽는가

이 스키마 설계가 큐레이션 능력을 그대로 결정한다. 실무에서 대체로 이런 테이블들이 생긴다.

logs           log_id, vehicle_id, start_ns, end_ns, path, size,
               stack_sha, calib_version, weather, time_of_day, road_type

frames         log_id, t_ns, ego_speed, ego_yaw_rate, accel,
               n_objects, nearest_obj_dist, occlusion_ratio,
               maneuver(직진/좌회전/차선변경/급제동), is_keyframe

objects        log_id, t_ns, track_id, class, x, y, z, yaw, w, l, h,
               velocity, confidence, n_points, source(auto|human)

labels         log_id, t_ns, sensor, task, geometry, attributes,
               label_spec_version, source, created_at

events         log_id, t_ns, kind(개입|급제동|경고|모델불일치), detail

그러면 질의가 이렇게 된다.

1-- 야간 · 우천 · 좌회전 중 · 보행자가 8m 안에 있던 장면
2SELECT f.log_id, f.t_ns
3FROM frames f
4JOIN logs l USING (log_id)
5JOIN objects o ON o.log_id = f.log_id AND o.t_ns = f.t_ns
6WHERE l.time_of_day = 'night'
7  AND l.weather = 'rain'
8  AND f.maneuver = 'left_turn'
9  AND o.class = 'pedestrian'
10  AND o.x*o.x + o.y*o.y < 64
11ORDER BY f.t_ns;

여기서 요령 하나. t_ns 는 센서 캡처 시각으로 통일한다. 으로 잡으면 나중에 로그를 재기록하거나 병합할 때 라벨·파생 신호가 통째로 어긋난다.

그리고 파티셔닝은 보통 log_id 또는 날짜로 잡는다. 위치 기반 조회가 잦으면(이 교차로를 지난 모든 주행) 공간 타일 컬럼을 하나 더 굽는다.

학습 I/O — GPU 를 굶기지 않기

으로 학습 세트를 골라도 마지막 관문이 남는다. 멀티모달 AV 모델 한 스텝은 카메라 6~12장 + + 라벨을 요구하고, 배치를 곱하면 초당 수 GB 다.

순서대로 손을 댄다.

샤딩 — 작은 파일을 순차 읽기 가능한 샤드로 묶는다.
전처리 굽기 — 매 스텝 원본을 디코딩하지 말고, · 텐서로 미리 구워 둔다. 저장 용량과 CPU 시간을 맞바꾸는 것이다.
로컬 캐시 — 학습 노드의 NVMe 에 에폭 단위로 미리 내린다.
디코딩 오프로드 — JPEG· 디코딩을 GPU 로 넘긴다.

여기서 저장 계층의 선택이 다시 걸린다. 3번(로컬 캐시)이 필요 없을 만큼 공유 스토리지가 빠르면 파이프라인이 훨씬 단순해진다. 올플래시가 비싼 값을 하는 지점이 이 단순함이다.

시각화 층 — Foxglove 와 Rerun 의 역할 분담

자율주행 시각화에서 도구들을 훑었는데, 플랫폼 관점에서 보면 둘의 자리가 명확히 갈린다.


성격	저장된 로그를 여는 뷰어·플랫폼	코드에 심는 관찰 SDK
입력	·, 실시간 WebSocket	코드에서 직접 로깅
강점	팀 공유, 레이아웃, 표준 스키마 자동 렌더	파이프라인 중간값·전처리 결과
자리	아카이브·리뷰·사후 분석	개발 루프·디버깅

경쟁이라기보다 아카이브용 / 개발 루프용으로 나눠 쓰는 게 자연스럽다. Foxglove 는 MCAP 을 만든 곳이라 로그 계층과 궁합이 좋고, 표준 스키마로 적어두면 뷰어를 새로 만들 필요가 없다. Rerun 은 "이 프레임에서 모델이 실제로 뭘 봤나"를 몇 줄로 띄우는 데 강하다.

플랫폼 설계에서 챙길 것은 시각화가 원본을 복사하지 않고 열리게 하는 것이다. 뷰어가 링크 하나로 저장소의 로그를 부분 요청으로 읽을 수 있어야 한다. 로그를 로컬로 내려받아야 볼 수 있으면 아무도 안 본다.

거버넌스와 비용

기술 외의 두 축인데, 실제로는 플랫폼 설계를 크게 바꾼다.

개인정보 — 주행 영상에는 얼굴과 번호판이 찍힌다. 인제스트 단계에서 마스킹할 것인지, 원본을 보존하고 접근을 통제할 것인지가 갈린다. 마스킹하면 되돌릴 수 없고 일부 인지 태스크에 영향이 있다. 통제로 가면 접근 감사가 필수가 된다. 이 결정은 인제스트 파이프라인을 짜기 전에 내려야 한다.

비용 — 페타바이트급에서는 저장 자체보다 이동이 비싼 경우가 많다. 클라우드 리전 간 전송, 온프렘과 클라우드 사이 전송이 조용히 쌓인다. 그래서 "데이터를 옮기지 말고 계산을 데이터 쪽으로 보낸다"가 기본 원칙이 된다.

보존 정책 — 모든 로그를 영원히 둘 필요는 없다. 다만 무엇을 지울지는 자동 규칙으로 정해야 하고, 사고·개입이 있던 로그는 예외로 뺀다.

조립하면

층마다 결정해야 할 것을 한 줄로 줄이면 이렇다.

기록 — 포맷과 규약. (MCAP)
저장 — 핫/웜/콜드 계층과 자동 이동 정책. 작은 파일은 샤딩.
변환 — 파일 단위 병렬. 파생 신호만 컬럼으로.
질의 — 무엇을 컬럼으로 굽느냐가 능력을 정한다.
학습 — 샤딩·굽기·캐시·GPU 디코딩. GPU 사용률을 지표로 본다.
시각화 — 복사 없이 열리게.
거버넌스 — 인제스트 전에 정한다.

정리

AV 데이터는 순차 대용량 + 무작위 소량이라는 상반된 두 부하를 동시에 건다. 두 번째가 대부분의 병목이다.
올플래시 공유 스토리지( 등)의 값어치는 속도만이 아니라 복사본 제거에 있다. 대신 비싸므로 계층화가 필수.
(/Delta)는 원본을 담는 곳이 아니라 메타·파생 신호를 담아 질의를 만드는 곳이다.
큐레이션 능력은 무엇을 컬럼으로 구웠는가로 결정된다. 스키마 설계가 곧 능력이다.
는 샤딩·전처리 굽기·캐시·GPU 디코딩으로 푼다.
시각화는 (아카이브)와 (개발 루프)으로 나눠 쓰고, 원본 복사 없이 열려야 실제로 쓰인다.

이어서 볼 글: 기록 층은 MCAP 완전 정복, 이 위에 올라가는 정답 데이터는 어노테이션 데이터, 이 데이터로 무엇을 학습하는지는 VLA·VQA와 파운데이션 모델에서 이어진다.