[자율주행] 인지 태스크 지도 — 3DOD·OCC·LMGI·TLD·PSD는 서로 어떻게 얽히는가

인지 스택 문서를 처음 열면 약어가 쏟아진다. , , LD, , , , , FSD. 각각을 낱개로 외우면 스무 개의 단어지만, 운전이 실제로 던지는 질문으로 줄을 세우면 훨씬 적다.

운전자가 매 순간 답하는 질문은 사실 셋뿐이다.

주위에 무엇이 있는가 — 피해야 할 것들
어디가 길인가 — 갈 수 있는 공간과 그 규칙
무엇이 나에게 지시하는가 — 신호, 표지, 노면 표시

인지 태스크는 이 셋을 기계가 답할 수 있는 형태로 쪼갠 것이다.

한 장 지도

약어	풀네임	답하는 질문	출력	라벨 형태
	3D Object Detection	아는 물체가 어디 있나	3D 박스 + 클래스 + 속도
	Occupancy	어느 공간이 차 있나	3D 점유 격자	(대개 자동 생성)
	Drivable area	어디가 비었나	영역	마스크·폴리곤
LD /	Lane Detection / 차선 인식	차선이 어디로 이어지나	폴리라인 + 속성 + 위상	폴리라인
노면 표시	Ground marking	바닥에 어떤 규칙이 쓰여 있나	화살표·정지선·횡단보도	폴리곤·마스크
	Traffic Light Detection	내 차선의 신호는	박스 + 상태 + 차선 연관	2D 박스 + 상태 속성
	Traffic Sign Recognition	무슨 표지판인가	박스 + 종류 + 값	2D 박스 + 클래스
	Parking Slot Detection	어디에 댈 수 있나	슬롯 꼭짓점 + 유형 + 점유	폴리곤 + 속성
	Multi-Object Tracking	방금 그 차가 이 차인가	+ 이력	트랙 id

아래에서 갈래별로 본다.

갈래 1 — 무엇이 있는가

3DOD, 그리고 그 한계

3D 객체 검출은 주변을 위치·크기·방향·속도를 가진 박스로 잡는다. 자율주행 인지의 가장 오래된 축이고, 예측과 계획이 곧바로 소비하는 형태다. 박스에는 가 붙어 추적으로 이어진다.

한계도 분명하다. 정의된 클래스만 잡는다. 도로에 떨어진 사다리, 뒤집힌 카트, 처음 보는 형상의 공사 자재는 박스로 나오지 않는다. 그리고 자율주행 사고의 상당수가 정확히 이 영역에서 난다.

OCC — 클래스를 모르고도 부피를 안다

그래서 점유 예측이 필요해진다. 세상을 작은 3D 칸으로 나눠 "여기에 뭔가 차 있는가" 를 직접 예측한다. 클래스를 몰라도 피할 수 있다.

칸마다 답하는 것은 셋이다 — 차 있음 / 비어 있음 / 관측되지 않음. 세 번째가 중요하다. 코너에 가려 안 보이는 공간을 "비었다"로 표시하면 계획이 그리로 들어간다.

와 는 경쟁 관계가 아니다. 아는 것은 박스로 추적하고, 모르는 것은 점유로 피한다. 실무 스택은 둘을 함께 내보내고, 계획은 둘을 합쳐 본다.

free space

점유의 2D 요약에 가깝다. "차가 물리적으로 지나갈 수 있는 영역"을 위에 표시한다. 계획이 가장 먼저 참조하는 층이고, 여기서도 비어 있음과 관측되지 않음의 구분이 핵심이다.

갈래 2 — 어디가 길인가

물체를 피하는 것만으로는 운전이 안 된다. 빈 공간이라고 다 갈 수 있는 게 아니다 — 반대 차선도 비어 있고, 인도도 비어 있다.

LD / LMGI

차선 검출은 픽셀 분할에서 시작해, 차선을 곡선(폴리라인)으로, 나아가 차선끼리의 연결(위상) 까지 뽑는 방향으로 발전했다. 계획이 요구하는 건 "흰 선이 여기 있다"가 아니라 "이 차선이 저 차선으로 이어진다"이기 때문이다.

조직에 따라 이 태스크를 라고 부른다.

표기 주의 — LMGI 는 공개 문헌에 정착된 표준 약어가 아니라 조직마다 쓰는 내부 명칭이다. 확장형과 정확한 범위는 사내 스펙 문서가 정의한다. 이 글은 공통분모인 차선 인식을 기준으로 쓴다.

이름이 무엇이든 뽑아내는 것은 같다.

기하 — 차선을 폴리라인이나 곡선 파라미터로. 픽셀 마스크가 아니라 선이어야 계획이 쓸 수 있다.
종류 — 실선·점선·이중선
색 — 흰색·노란색·파란색(버스전용)
위상 — 이 차선이 어느 차선으로 이어지는가

실무 난제는 인지 알고리즘보다 환경과 스펙이다. 지워지고 겹쳐 칠해진 도색, 눈·물기·역광, 그리고 "끊긴 차선을 어디까지 이어 라벨링할 것인가" 같은 정의 문제.

노면 표시 — 바닥에 쓰인 규칙

차선과 함께 다뤄지는(조직에 따라 같은 태스크군에 묶이는) 것이 노면 표시다. 진행 방향 화살표, 정지선, 횡단보도, 속도 숫자, 유도선, 어린이보호구역 도색. 폴리곤이나 마스크로 라벨링한다.

같이 묶이는 이유는 같은 카메라의 같은 노면 픽셀에서 나오고, 라벨링 도구와 평가 방식이 겹치기 때문이다. 다만 이 범위 차이가 곧 차이라서, 어디까지가 한 태스크인지는 사내 온톨로지에서 확인해야 한다.

노면 표시가 왜 중요한가 — 그것들이 규칙을 말하기 때문이다. 화살표는 "이 차선은 좌회전 전용", 정지선은 "여기서 멈춰라", 횡단보도는 "여기서 보행자를 기대하라"를 뜻한다. 표지판이나 신호등이 주는 정보와 같은 층위인데, 바닥에 그려져 있을 뿐이다.

PSD — 저속·근거리의 세계

주차 슬롯 검출은 같은 "어디가 길인가"이지만 완전히 다른 환경에서 논다.

입력이 다르다. 전방 카메라로는 차 바로 옆 지면의 주차선이 안 보인다. 그래서 카메라 4개를 지면 평면으로 투영해 이어 붙인 AVM(어라운드뷰) 이미지 위에서 도는 게 보통이다.
출력이 다르다. 마킹 포인트(주차선 꼭짓점, 보통 입구 두 점 + 안쪽 두 점), 슬롯 유형(수직·평행·대각), 점유 여부, 부가 속성(장애인·전기차 전용, 기둥에 막힘).
어려움이 다르다. 지하주차장의 낮은 조도와 반사, 지워진 도색, 기둥에 가린 꼭짓점, 어안 왜곡의 잔차. 슬롯이 실제로 비었는지는 카메라만으로 애매해서 초음파·라이다와 융합하는 경우가 많다.

는 자동 주차(APA)와 기억 주차(HPP)의 인지 입력이고, 고속 주행 인지와는 사실상 별도의 파이프라인으로 운영되는 경우가 많다.

갈래 3 — 무엇이 나에게 지시하는가

TLD — 어려운 건 검출이 아니라 연관

신호등 인지는 세 단계가 겹쳐 있다.

검출 — 이미지에서 신호등을 찾는다. 100m 밖이면 몇 픽셀짜리 객체다.
인식 — 색(적·황·녹), 화살표 방향, 점멸 상태를 읽는다.
연관 — 교차로에 신호등이 여섯 개 보일 때 내 차선에 적용되는 건 어느 것인가.

실무에서 진짜 어려운 건 3번이다. 그리고 이건 순수 인지로 풀지 않는다. 에 저장된 신호등의 3D 위치와 그것이 지배하는 차선의 대응 관계를 이용해, 지도의 위치를 현재 카메라에 투영하고 검출과 매칭한다.

즉 의 품질은 지도와 측위 정확도에 묶여 있다. 인지 모델만 좋아져서는 안 올라간다.

센서 쪽 함정도 유별나다.

역광과 블루밍 — 해를 등진 신호등은 실루엣만 남는다.
LED 점멸과 카메라 셔터의 간섭 — LED 신호등은 사람 눈에 안 보이는 주기로 깜빡이는데, 노출이 짧으면 꺼진 순간이 찍힌다. 그래서 신호등용으로 노출을 따로 잡거나 전용 카메라를 두기도 한다.
우천 시 렌즈 물방울, 야간 번짐.

데이터 쪽 함정 하나 — 신호가 바뀌는 전이 프레임의 정답을 스펙에 안 적어두면 라벨이 갈린다.

TSR

TLD 의 형제지만 성격이 다르다. 표지판은 정적이라 HD 맵에 미리 넣어둘 수 있다. 대신 종류가 수백 가지이고 국가마다 다르다. 가변 전광판, 요일·시간대 조건이 붙은 부속 표지, 부분 가림, 낡은 표지가 난제다.

그래서 서로 어떻게 얽히는가

여기가 이 글의 요점이다. 이 태스크들은 각자 다른 모델이 아니라, 하나의 공통 무대를 공유한다.

  카메라 ×N        라이다        레이더
     │              │             │
     └──────┬───────┴─────────────┘
            ▼
     공통 BEV 특징 맵          ← 여기가 무대
            │
   ┌────┬───┴───┬────┬────┬──────┐
   ▼    ▼       ▼    ▼    ▼      ▼
 3DOD  OCC   LD/LMGI  TLD  PSD  free space
   │    │       │      │
   └──┬─┴───────┴──────┘
      ▼
   추적(MOT) → 궤적 예측 → 계획 → 제어

BEV 로 수렴한 이유가 여기 있다. 조감도 격자는 거리·크기를 왜곡 없이 보존하고, 여러 센서를 한 판에 얹기 쉽고, 다운스트림 태스크를 통일한다. 그래서 최근 인지 스택은 "센서 입력 → 공통 BEV 특징 → 태스크별 헤드"라는 모양으로 정렬됐다.

한 백본을 공유하면 좋은 점이 실무적으로 크다.

연산이 한 번이다. 태스크마다 별도 네트워크를 돌리면 차량 컴퓨트가 감당 못 한다.
표현이 공유된다. 차선을 배우면 객체 위치 추정도 좋아진다(도로 위에 있어야 하니까).
출력이 이미 같은 좌표계에 있다. 박스와 점유와 차선을 합칠 때 변환이 필요 없다.

대신 대가도 있다.

태스크 간섭. 한 태스크의 성능을 올리는 학습이 다른 태스크를 떨어뜨린다. 손실 가중치 튜닝이 영원한 숙제가 된다.
배포 결합. 신호등만 고치고 싶어도 모델 전체를 다시 검증해야 한다.

그래서 실무는 대개 절충한다 — 고속 주행의 주요 태스크(3DOD·OCC·LD)는 공유 백본으로 묶고, 성질이 다른 것(TLD 의 원거리 소형 객체, PSD 의 BEV)은 별도 파이프라인으로 뺀다.

하류로 어떻게 흘러가는가

인지 출력은 그 자체로 목적이 아니다.

3DOD + → 의 입력. 가 없으면 속도도 미래도 없다.
LD/LMGI + → 예측과 계획의 좌표계. 차선 위상이 있어야 "갈 수 있는 경로"가 한정된다.
TLD/ + 노면 표시 → 계획의 제약 조건. "여기서 멈춰야 한다", "이 차선은 좌회전만".
OCC + → 계획의 안전 여유. 박스로 안 잡힌 것을 피하는 마지막 그물.

그러니까 이 지도의 화살표는 결국 하나로 모인다. 계획이 하나를 고르기 위해 필요한 정보를 각 태스크가 나눠 만든다.

데이터 관점 — 한 씬이 여러 정답을 진다

인지 태스크가 여럿이라는 사실은 어노테이션 설계에 그대로 걸린다.

한 에 여러 형태의 라벨이 동시에 붙는다. , 폴리라인, 폴리곤, 마스크, . 단일 테이블로 안 되고 태스크별 스키마의 묶음이 된다.
태스크마다 라벨 비용이 다르다. 3DOD 큐보이드는 비싸고, 점유 복셀은 누적 에서 자동 생성하는 게 보통이고, TLD 는 프레임당 대상이 적어 상대적으로 싸다. 그래서 키프레임 주기와 라벨 대상 선정을 태스크마다 다르게 가져가는 게 합리적이다.
평가도 태스크마다 다른 자를 쓴다. 3DOD 는 /NDS, 은 mIoU, 차선은 위상까지 보는 별도 지표, TLD 는 색 정확도와 연관 정확도를 나눠 본다.
그래서 로그 스키마에서도 인지 출력 을 태스크별로 나눠 두는 게 낫다. MCAP 의 /perception/* 토픽 설계가 그 이야기다.

정리

인지 태스크는 운전의 세 질문으로 묶인다 — 무엇이 있는가 / 어디가 길인가 / 무엇이 지시하는가.
3DOD 는 아는 것을, OCC 는 모르는 것을 다룬다. 배타적이지 않고 함께 쓴다.
차선 인식(조직에 따라 LMGI)이 내놓아야 하는 건 픽셀이 아니라 속성과 위상이 붙은 선이다. 노면 표시는 그 옆에서 규칙을 말한다. (약어의 확장형·범위는 조직마다 다르니 사내 스펙 확인.)
TLD 의 난점은 검출이 아니라 연관이고, 그래서 지도·측위 품질에 묶여 있다.
PSD 는 AVM BEV 위에서 도는 별도 세계다.
이 전부가 최근에는 공통 BEV 백본 + 태스크별 헤드로 정렬됐고, 그 덕에 연산과 좌표계가 통일된다. 대신 태스크 간섭과 배포 결합을 감수한다.

다음으로 읽을 글: 각 태스크의 정답을 만드는 법은 어노테이션 데이터, 카메라 태스크의 좌표 함정은 카메라 이미지의 실제, 이 출력들이 어떤 으로 로그에 남는지는 MCAP 완전 정복에서 이어진다.