[자율주행] 계획과 제어 — 인지 다음에 실제로 무슨 일이 일어나는가
자율주행/예측
· 2026-09-06
본문의 점선 밑줄 친 전문용어를 누르면 설명이 열립니다.
시리즈 내내 "인지 → 예측 → 계획 → 제어"라고 말해왔다. 그런데 인지는 여러 편이고 예측도 한 편인데, 뒤 절반에는 독립 글이 없었다.
데이터를 다루는 사람에게 계획·제어가 남 일처럼 느껴지는 건 자연스럽다. 라벨을 만드는 것도, 학습 세트를 뽑는 것도 대부분 인지 쪽이니까. 그런데 실제로는 두 지점에서 정면으로 부딪힌다.
- 사고 분석 — "왜 안 피했나"는 인지 로그만으로 절대 답이 안 나온다.
- 모방학습· — 사람이 실제로 한 행동이 정답인데, 그 행동이 CAN과 제어 로그에 있다.
계획은 한 덩어리가 아니다
시간 지평과 추상 수준이 다른 세 층으로 나뉜다.
경로 계획 (route) 수 km · 수 분 "어느 길로 갈 것인가"
↓
행동 계획 (behavior) 수십 m · 수 초 "차선을 바꿀까, 양보할까"
↓
동작 계획 (motion) 수십 m · 수 초 "그 결정을 어떤 궤적으로"
↓
제어 (control) 수십 ms "그 궤적을 조향각·가감속으로"
주기도 다르다. 경로는 몇 초에 한 번, 은 10Hz 안팎, 제어는 100Hz 안팎으로 돈다. 로그에서 이 주기 차이를 보면 어느 단계 출력인지 대충 짐작할 수 있다.
경로 계획
지도를 그래프로 놓고 최단·최적 경로를 찾는다. 내비게이션과 같은 문제고, 자율주행에서 가장 덜 어려운 부분이다.
행동 계획 — 이산 결정
"차선 유지 / 좌측 차선 변경 / 선행차 추종 / 양보 / 정지" 같은 이산적인 선택을 한다. 여기서 나오는 결정이 아래 층의 제약이 된다.
전통적으로는 규칙과 상태 기계로 짰다. 읽기 쉽고 검증하기 쉽지만, 경우의 수가 늘면 규칙이 수천 줄이 되고 서로 충돌한다. 그래서 학습 기반으로 옮기려는 시도가 계속 있는데, 검증 가능성이 발목을 잡는다.
여기서 데이터 쪽이 챙길 것 하나. 결정만 남기지 말고 그 이유를 남겨야 한다. "차선 변경 안 함"만 있으면 사후 분석이 추측이 된다. "후방 차량 TTC 1.8초 < 임계 2.5초"까지 있으면 즉시 답이 나온다.
동작 계획 — 궤적을 고른다
가장 계산이 무거운 층이다. 두 갈래 접근이 있다.
① 샘플링 + 평가
후보 을 여러 개 만들고 각각을 로 채점해 제일 싼 걸 고른다. 여기서 가 나온다.
도로를 따라가는 축 s(진행 거리)와 그 수직 축 d(횡방향 이탈)로 좌표를 다시 잡는 방식이다.
직교 좌표(x, y) 프레네 좌표(s, d)
╭──╮ 구불구불한 도로 ────────────────── 도로를 펴서
╱ ╲ d ↑ 직선으로 본다
╱ ╲ └──────────▶ s
도로가 굽어 있어도 "차선 중앙에서 얼마나 벗어났나(d)"와 "얼마나 나아갔나(s)"로 생각할 수 있다. 곡선 도로에서 궤적을 만드는 문제가 훨씬 단순해진다.
비용 함수는 보통 이런 항들의 가중합이다.
| 비용 항 | 무엇을 벌하나 |
|---|---|
| 충돌 위험 | 다른 주체의 예측 궤적과의 근접 |
| 진행 | 너무 느리게 가는 것 |
| 편안함 | 가속도와 저크(가속도의 변화율) |
| 경로 이탈 | 차선 중앙에서 벗어남 |
| 법규 | 속도 제한, 실선 침범, 정지선 |
가중치를 어떻게 정하느냐가 곧 그 차의 성격이다. 공격적인 차와 소심한 차의 차이가 대부분 여기서 나온다.
② 최적화 기반
비용 함수를 직접 최적화한다. 차량 동역학과 제약(최대 조향, 최대 가속)을 넣고 푼다. 부드럽지만 무겁고, 국소 최적에 빠질 수 있다.
실무는 섞는다 — 샘플링으로 대략의 후보를 만들고, 그중 하나를 최적화로 다듬는다.
제어 — 궤적을 실제 명령으로
계획이 낸 을 조향각·가속·제동으로 바꾼다. 차량의 물리와 직접 맞닿는 층이다.
횡방향(조향)
- Pure Pursuit — 궤적 위 앞쪽 한 점(look-ahead point)을 정하고 그리로 향하는 원호를 그린다. 단순하고 튼튼해서 아직도 많이 쓴다. 속도에 따라 look-ahead 거리를 조절하는 게 요령이다.
- Stanley — 앞바퀴 기준으로 횡방향 오차와 헤딩 오차를 함께 본다.
- LQR / — 차량 모델을 놓고 최적 제어를 푼다.
종방향(가감속)
PID에 피드포워드(경사, 공기저항)를 얹는 게 기본이다.
MPC는 종·횡을 함께 다룬다. 차량 모델로 미래 1~3초를 짧게 시뮬레이션해, 제약을 만족하면서 비용이 최소인 명령열을 구하고 첫 번째 것만 실행한 뒤 다음 주기에 다시 푼다. 계획과 제어의 경계가 흐려지는 지점이기도 하다.
액추에이터
명령이 곧바로 실현되지 않는다는 걸 잊으면 안 된다. 조향 모터에도 제동 유압에도 지연과 응답 특성이 있다. drive-by-wire 시스템의 응답 지연이 100ms라면, 제어기는 그걸 모델에 넣어야 한다.
지연 예산 — 전체를 하나로 보면
각 단계의 지연이 합쳐져 시스템 반응 시간이 된다.
센서 캡처 → 전송 → 인지 → 융합·추적 → 예측 → 계획 → 제어 → 액추에이터
↑ ↑
여기부터 여기까지가 반응 지연
60km/h는 초당 16.7m다. 전체 지연이 300ms면 차는 5m를 더 간 뒤에 반응한다. 그래서 각 단계에 예산이 배정되고, 어느 단계가 예산을 넘겼는지 추적하는 게 상시 과제가 된다.
그리고 이건 로그의 타임스탬프로만 잴 수 있다. 세 개의 시계 이야기가 여기서 값을 한다 — 각 단계 출력에 "내가 소비한 입력의 캡처 시각"이 실려 있어야 단계별 지연이 계산된다.
데이터 관점 — 계획 로그가 가장 밀도 높다
여기가 이 글의 핵심이다.
계획·제어 로그는 용량이 인지 로그의 수천분의 일이다. 하나가 수 MB인데 계획 출력은 수 KB다. 그런데 사후 분석에서의 가치 밀도는 정반대다.
후보와 비용을 남겨라
선택된 만 남기면 "왜 그걸 골랐나"에 답할 수 없다.
/planning/candidates
후보 궤적 N개
각각의 비용 항목별 점수 (충돌 / 진행 / 편안함 / 법규 / 이탈)
탈락 사유
/planning/trajectory
최종 선택
이게 있으면 잘못된 결정의 원인이 인지의 잘못된 입력인지, 비용 가중치인지 즉시 갈린다. 없으면 며칠이 걸린다. 용량은 미미하다.
명령과 실제를 쌍으로
/control/command 목표 조향각 · 목표 가속도
/vehicle/status CAN 피드백 — 실제 조향각 · 실제 속도
둘을 나란히 보면 문제가 계획에 있는지 차량 응답에 있는지 한눈에 갈린다.
개입 이벤트는 최고급 재료다
안전 운전자가 핸들을 잡거나 브레이크를 밟은 순간(disengagement)은 "시스템이 여기서 사람을 만족시키지 못했다"는 라벨이 자동으로 붙은 데이터다. 사람이 라벨링할 필요도 없다.
- 개입 전후 구간을 자동으로 잘라 큐레이션 대상으로 보낸다
- 개입 종류(조향·제동·해제)와 강도를 태그로 굽는다
- (MPI, miles per intervention) 이 가장 흔한 상위 지표다
모방학습과 VLA의 정답이 여기 있다
VLA·E2E에서 말한 "행동은 에 이미 있다"가 이 이야기다. 사람이 실제로 어떻게 조향하고 가감속했는가 — 그게 정답이다. 다만 관측과 행동이 같은 시간축에 정확히 정합돼 있어야 삼중항을 만들 수 있다.
정리
- 계획은 경로 → 행동 → 동작의 세 층이고, 시간 지평과 주기가 다르다.
- 은 에서 후보를 만들고 로 고른다. 가중치가 곧 그 차의 성격이다.
- 제어는 Pure Pursuit·Stanley· 계열이고, 액추에이터 지연을 모델에 넣어야 한다.
- 전체 은 로그의 타임스탬프로만 측정된다.
- 계획 로그는 용량 대비 가치 밀도가 가장 높다. 후보 궤적과 비용 항목별 점수를 남기면 사후 분석이 며칠에서 몇 분이 된다.
- 는 공짜로 라벨이 붙은 데이터다. 자동으로 잘라 으로 보낸다.
- 명령과 실제( 피드백)를 쌍으로 남긴다.
이어서 볼 글: 앞 단계인 궤적 예측, 이 출력들이 어떤 에 담기는지는 MCAP 완전 정복, 로 검증하는 이야기는 시뮬레이션과 리시뮬에서 다룬다.