[자율주행] 어노테이션 데이터 — 정답은 어떻게 만들어지고, 어떻게 썩는가

씬 데이터에서 씬의 구성 요소를 세면서 "(선택)"이라고 한 줄 적고 넘어갔다. 실제로는 그 한 줄이 자율주행 데이터 조직 인력의 절반과 예산의 상당 부분을 쓴다.

센서 데이터가 "세상이 어떻게 보였는가"라면, 어노테이션은 "그 안에 무엇이 있었는가" 다. 학습의 교사이자 평가의 자다. 그리고 자가 틀리면 잰 값이 전부 틀린다.

라벨의 형태 지도

태스크마다 정답의 모양이 다르다. 먼저 전체를 한 판에 놓는다.

형태	무엇을 적나	주로 쓰는 곳
2D 박스	이미지 위 사각형 + 클래스	신호등·표지판 검출, 이미지 단계
3D	중심·크기·yaw + 클래스	, 추적,
폴리라인	이어진 점들의 선	차선, 도로 경계
폴리곤	닫힌 다각형	노면 표시, 주차 슬롯
마스크	픽셀·점마다 클래스	, 노면, 파놉틱
점유	3D 칸마다 점유/클래스
궤적	시각별 위치의 나열	예측, 계획 모방학습
속성	가려짐·잘림·신호 색·차선 종류	위 전부에 부착
	프레임을 넘는 동일성	추적, 속도 유도

한 씬에는 이 여러 형태가 동시에 붙는다. 그래서 데이터는 단일 테이블이 아니라 여러 스키마의 묶음이고, 이 묶음을 어떻게 버전 관리하느냐가 실무의 절반이다.

무엇을 라벨링할지가 먼저다

전부 라벨링할 수는 없다. 20Hz 로 도는 라이다에 사람이 다 붙을 수 없으니 보통 2Hz 정도의 키프레임만 고른다. 그런데 진짜 결정은 그 앞이다 — 수만 시간 중 어느 구간을 대상으로 삼을 것인가.

무작위로 고르면 데이터가 고속도로 직진으로 채워진다. 그래서 골라야 한다.

실패 기반 — 모델이 틀렸거나 사람이 개입한 장면
불확실성 기반 — 신뢰도가 낮거나 앙상블이 갈리는 장면
희소성 기반 — 임베딩 공간에서 기존 데이터와 먼 장면
조건 기반 — 조합(야간 + 우천 + 좌회전)으로 뽑기

이게 돌아가려면 로그가 질의 가능해야 한다. 그래서 라벨링 예산의 효율은 라벨링 팀이 아니라 데이터 파이프라인 설계가 결정한다. 이 안 되는 조직은 같은 돈으로 훨씬 나쁜 데이터셋을 만든다.

온톨로지 — 데이터셋의 헌법

은 클래스 목록이 아니다. 경계 사례에 대한 결정의 모음이다.

자전거를 끌고 걷는 사람은 보행자인가 자전거인가.
트레일러 트럭은 한 박스인가 두 박스인가.
80m 밖, 라이다 점 4개짜리 차도 라벨링하는가.
반쯤 가려진 차의 박스는 보이는 부분만인가 추정된 전체인가.
신호가 바뀌는 순간의 프레임은 무슨 색으로 적는가.

이 결정들이 문서에 없으면 라벨러마다 다르게 해석하고, 그 불일치가 그대로 라벨 노이즈가 된다. 모델은 서로 모순되는 정답을 배우고, 성능은 이유 없이 정체된다.

문서가 있어도 부족하다. 경계 사례마다 실제 예시 이미지가 붙은 스펙이 훨씬 낫다. 글로 쓴 규칙은 해석되지만 그림은 덜 해석된다.

그리고 스펙에는 버전이 있어야 한다. 6개월 전 규칙으로 만든 라벨과 지금 규칙으로 만든 라벨이 같은 테이블에 섞이면, 성능이 떨어졌을 때 원인을 영영 못 찾는다. label_spec_version 은 모든 라벨 행에 붙는 컬럼이어야 한다.

어느 좌표계, 어느 이미지 위인가

라벨 사고 중 가장 자주 나오면서 가장 늦게 발견되는 종류다.

3D 박스 — 센서 좌표계인가, 차량 좌표계인가, 월드 좌표계인가. yaw 의 0도는 어느 축인가. 크기는 (w, l, h) 순인가 (l, w, h) 순인가. 데이터셋마다 다르고, 여러 소스를 한 파이프라인에 섞는 순간 첫 번째로 부딪히는 벽이다. (3D 기하 기초에서 이 바닥을 다룬다.)

2D 박스 — 이보다 더 조용한 함정이 있다. 위에 그렸는가, 된 이미지 위에 그렸는가. 두 좌표는 다르다. 화면 중앙에서는 차이가 작아서 눈으로 검수해도 통과하고, 가장자리에서만 수십 픽셀이 어긋난다.

라벨링 도구를 바꿨거나, 전처리 파이프라인이 리사이즈·크롭을 추가했거나, 어떤 배치만 다른 업체에서 왔을 때 이 불일치가 생긴다. 그리고 모델은 조용히 조금 나빠질 뿐 에러를 내지 않는다.

막는 법은 하나다. 라벨 레코드에 좌표 공간을 명시적으로 적는다.

image_space: "distorted" | "undistorted"
camera_info_ref: "calib_v7"       # 어떤 K, D 기준인가
resolution: [1920, 1080]          # 그 좌표가 유효한 해상도
frame_id: "camera_front"

자세한 이유와 왜곡 모델 자체는 카메라 이미지의 실제에서 판다.

오토라벨링 — 오프라인은 반칙이다

사람이 다 그리는 시대는 지났다. 지금의 표준은 모델이 먼저 만들고 사람이 고치는 방식이다.

핵심 통찰은 이것이다. 오프라인 라벨러는 온라인 모델보다 유리하다.

실시간 제약이 없다. 10배 무거운 모델을 써도 된다.
미래 프레임을 볼 수 있다. 지금 가려진 차가 3초 뒤 드러나면, 그 정보를 지금 프레임의 라벨에 소급 반영할 수 있다.
앞뒤 수십 프레임의 을 누적해 훨씬 조밀한 형상 위에서 박스를 맞춘다.
을 시간축 전체에서 매끄럽게 다듬을 수 있다.

그래서 잘 만든 자동 라벨러는 사람보다 일관되고 사람보다 싸다. 사람의 역할은 그리는 사람에서 판정하는 사람으로 옮겨간다.

위험은 자기 확증이다. 자동 라벨이 모델의 편향을 그대로 물려주면, 모델은 자기가 이미 잘하는 것만 더 잘하게 되고 못 보던 것은 계속 못 본다. 그리고 그 편향은 평가 세트까지 오염시키면 측정으로도 안 잡힌다.

그래서 두 가지를 지킨다.

사람 검수 대상에 신뢰도 낮은 것만 넣지 말고 무작위 표본도 섞는다.
평가 세트는 사람이 만든 것으로 따로 유지한다. 학습 라벨은 자동화해도, 자를 자동화하면 안 된다.

품질을 숫자로 잰다

"라벨은 정답이니까 맞다"는 가정이 가장 비싼 실수다. 측정 수단이 있어야 관리가 된다.

합의도(IAA) — 같은 장면을 두 사람이 라벨링해 얼마나 일치하는지. 낮게 나오는 클래스가 곧 스펙이 모호한 지점이다. 사람을 탓하기 전에 스펙을 고칠 신호다.
골든셋 — 전문가가 만든 소량의 정밀 정답. 라벨러도 자동 라벨러도 이걸로 채점한다.
감사 샘플링 — 납품 배치에서 무작위로 뽑아 검수하고, 통과 기준을 미리 정해둔다.
자동 일관성 검사 — 사람 없이 잡히는 것들이 의외로 많다.
- 가 갑자기 끊기거나 바뀜
- 프레임 사이 박스 크기가 튐(같은 차가 갑자기 커짐)
- 도로 밖·건물 안에 차량 박스
- 물리적으로 불가능한 속도
- 박스 안 라이다 점이 0개

마지막 항목은 CI 로 돌릴 수 있다. 라벨 납품에 테스트를 붙이는 조직과 안 붙이는 조직의 차이는 6개월 뒤에 크게 벌어진다.

라벨을 어디에 저장할 것인가

MCAP 같은 로그 안에 을 함께 넣고 싶은 유혹이 크다. 한 파일에 다 있으면 편하니까. 하지만 성질이 다르다.

로그는 불변이다. 그때 그 순간 센서가 본 것과 스택이 낸 출력은 바뀌지 않는다. 라벨은 계속 바뀐다. 스펙이 개정되고, 오류가 발견되고, 자동 라벨러가 재학습되어 전체를 다시 만든다.

바뀌는 것을 안 바뀌는 것 안에 넣으면, 라벨 갱신 한 번에 페타바이트를 다시 써야 한다. 그래서 라벨은 로그 밖 사이드카에 둔다. (Parquet/Delta)이면 질의도 붙는다.

조인 키를 정확히 정하는 게 계약의 전부다.

log_id        어느 로그 파일인가
t_ns          어느 순간인가 — 캡처 시각 기준 (log_time 아님)
topic/sensor  어느 센서의 관측에 붙은 라벨인가

t_ns 를 으로 잡으면 나중에 로그를 재기록하거나 병합할 때 라벨이 통째로 어긋난다. 센서 캡처 시각이 유일하게 안정적인 앵커다.

그리고 라벨 테이블에는 항상 이 셋이 붙어야 한다.

label_spec_version   어떤 규칙으로 만들었나
source               human | auto:v3 | auto+human
created_at           언제

라벨이 썩는 방식

한 번 만들면 끝나는 자산이 아니다. 시간이 지나면 이런 식으로 망가진다.

스펙이 바뀌었는데 과거 라벨을 재작업하지 않는다 → 같은 테이블에 다른 규칙이 섞인다.
이 갱신됐는데 라벨은 옛 좌표 기준으로 남는다 → 3D 박스가 미세하게 밀린다.
센서 구성이 바뀌었는데(카메라 교체, 위치 이동) 라벨 메타에 안 적힌다 → 어느 배치가 어느 하드웨어인지 모른다.
라벨 업체를 바꿨는데 스타일이 다르다 → 배치 경계에서 분포가 튄다.
평가 세트가 학습 세트에 새어든다 → 성능이 좋아 보이는데 실차에서는 아니다.

전부 메타데이터를 안 남겨서 생기는 문제다. 라벨 자체보다 라벨에 붙은 맥락이 오래 산다.

데이터 엔지니어의 시선

라벨링 예산의 효율은 라벨링 팀이 아니라 파이프라인이 정한다.
의 상한은 스펙의 명확함이, 그다음은 와 정확도가 정한다. 포즈가 흔들리면 누적 이 두 겹으로 보이고 사람이 그 위에 그린 박스에 오차가 그대로 박힌다.
라벨은 버전 달린 테이블이지 파일 더미가 아니다.
로그와 라벨을 잇는 건 파일 경로가 아니라 (log_id, 캡처 시각, 센서) 라는 계약이다.

정리

어노테이션은 형태가 여럿(박스·폴리라인·마스크··)이고, 한 씬에 동시에 붙는다.
진짜 결정은 "어떻게 그리나"가 아니라 "무엇을 그릴지 고르는 것" 이다.
는 클래스 목록이 아니라 경계 사례 결정의 모음이고, 버전이 있어야 한다.
2D 라벨은 위인지 보정 이미지 위인지를 반드시 명시한다. 안 적으면 조용히 섞인다.
은 오프라인의 이점(미래 프레임·누적 ) 때문에 사람보다 나을 수 있다. 대신 평가 세트는 사람 손을 남긴다.
품질은 IAA·골든셋·감사 샘플링·자동 일관성 검사로 잰다. 라벨 납품에도 테스트를 붙인다.
라벨은 불변 로그 밖에 두고 (log_id, t_ns, sensor) 로 조인한다.

다음으로 읽을 글: 이 라벨들이 어느 태스크에 어떻게 쓰이는지는 인지 태스크 지도, 2D 라벨의 좌표 함정은 카메라 이미지의 실제, 저장·질의 층은 MCAP 완전 정복에서 이어진다.