자율주행 성능은 데이터에서 시작된다
자율주행 기술을 이야기할 때 사람들은 보통 인공지능 모델이나 알고리즘을 먼저 떠올린다. 물론 모델은 중요하다. 하지만 같은 알고리즘을 쓰더라도 어떤 데이터를 모았는지, 그 데이터에 어떤 정답을 붙였는지, 어떤 장면으로 평가했는지에 따라 성능은 크게 달라진다. 자율주행과 ADAS의 능력은 알고리즘 자체만이 아니라 데이터를 다루는 방식에 크게 좌우된다는 지적이 나오는 이유도 여기에 있다.1
예를 들어 보행자 탐지 모델을 만든다고 하자. 맑은 낮, 넓은 도로, 정면으로 보이는 보행자 데이터만 많다면 모델은 그 조건에서는 잘 작동할 수 있다. 그러나 비 오는 밤, 우산을 쓴 보행자, 버스 뒤에서 갑자기 나타나는 어린이, 역광 속 횡단보도처럼 어려운 장면에서는 쉽게 흔들릴 수 있다. 모델이 똑똑하지 않아서만은 아니다. 그런 장면을 충분히 보지 못했거나, 잘못 라벨링된 데이터로 배웠거나, 평가 데이터에 포함되지 않았기 때문이다.
그래서 자율주행 개발은 단순히 "AI를 학습한다"로 끝나지 않는다. 차량에서 데이터를 모으고, 필요한 장면을 골라내고, 정답을 붙이고, 학습하고, 검증하고, 차량에 배포한 뒤, 다시 로그를 분석하는 긴 순환 과정이다.
AI 생성 이미지
주행 데이터는 개발 파이프라인을 어떻게 도는가
자율주행 데이터 파이프라인은 보통 다음 흐름으로 움직인다.
수집: 시험 차량이나 상용 차량이 카메라, 라이다, 레이더, GNSS, IMU, 차량 상태 신호를 기록한다.
업로드와 저장: 차량 내부 저장 장치에 쌓인 데이터를 서버나 클라우드 저장소로 옮긴다.
정리와 품질 확인: 파일이 깨지지 않았는지, 센서 시간이 맞는지, 필요한 메타데이터가 있는지 확인한다.
장면 탐색: 급제동, 끼어들기, 보행자 접근, 차선 공사 같은 의미 있는 장면을 찾아낸다.
라벨링: 차량, 보행자, 차선, 신호등, 주행 가능 공간 등에 정답을 붙인다.
학습과 평가: 모델을 훈련시키고, 별도의 검증 데이터로 성능을 확인한다.
통합 테스트와 배포: 차량 소프트웨어와 함께 시험한 뒤, 안전 기준을 통과한 버전을 차량에 배포한다.
운영 모니터링: 실제 운행 중 로그를 다시 수집해 문제 장면을 찾고 다음 개발 사이클에 넣는다.
이 과정에서 중요한 것은 데이터의 양만이 아니라 추적 가능성이다. 어떤 차량에서 언제 수집한 데이터인지, 어떤 센서 설정이었는지, 누가 어떤 기준으로 라벨링했는지, 어떤 학습 버전에 사용했는지 알아야 한다. 대규모 자율주행 데이터 운영에서는 수집 데이터, 메타데이터, 라벨, 장면 정보, 데이터 계보를 함께 관리하는 구조가 필요하다.2
추적이 안 되면 문제가 생겼을 때 원인을 찾기 어렵다. 예를 들어 새 모델이 야간 차선 인식에서 성능이 떨어졌다고 하자. 이때 개발팀은 단순히 "모델이 나빠졌다"고 말할 수 없다. 학습 데이터에서 야간 장면이 줄었는지, 라벨 기준이 바뀌었는지, 카메라 보정값이 달라졌는지, 평가 데이터가 이전과 같은지 확인해야 한다. 데이터 파이프라인은 이런 질문에 답하기 위한 개발 기반이다.
라벨링은 정답을 붙이는 일이지만, 정답은 항상 단순하지 않다
라벨링은 인공지능이 배울 수 있도록 데이터에 정답을 붙이는 작업이다. 영상 속 보행자에 박스를 치고, 라이다 점군에서 차량의 3차원 위치를 표시하고, 신호등 색과 차선 종류를 구분하는 일이 여기에 해당한다.
겉보기에는 반복 작업처럼 보이지만, 실제로는 판단이 많이 들어간다. 멀리 있는 오토바이를 자전거로 볼 것인가, 가려진 보행자의 크기를 어디까지 표시할 것인가, 공사 구간 임시 차선을 기존 차선보다 우선할 것인가 같은 문제가 계속 나온다. 라벨 기준이 흔들리면 모델은 혼란스러운 정답을 배우게 된다.
그래서 좋은 라벨링에는 세 가지가 필요하다.
명확한 기준: 같은 장면을 여러 사람이 보아도 비슷하게 표시할 수 있어야 한다.
검수 절차: 라벨 오류를 자동 검사와 사람 검토로 걸러야 한다.
버전 관리: 라벨 기준이 바뀌면 이전 데이터와 새 데이터를 구분해야 한다.
자동 라벨링도 많이 사용된다. 이미 학습된 모델이나 센서 융합 결과로 1차 라벨을 만들고 사람이 수정하는 방식이다. 비용과 시간을 줄일 수 있지만, 기존 모델의 오류가 새 데이터에 그대로 퍼질 수 있다는 위험이 있다. 따라서 자동화는 필요하지만, 안전과 직결되는 데이터는 검수 체계를 함께 가져가야 한다.
실제 도로 데이터와 시뮬레이션 데이터
자율주행 학습과 검증에는 실제 도로 데이터와 시뮬레이션 데이터가 함께 쓰인다. 둘은 경쟁 관계가 아니라 서로 보완하는 관계다.
실제 도로 데이터의 장점은 현실성이 높다는 점이다. 사람 운전자의 미묘한 행동, 복잡한 도로 표지, 날씨와 조명 변화, 센서 노이즈가 그대로 담긴다. 특히 카메라 렌즈에 묻은 먼지, 라이다 반사 강도의 변화, 레이더의 다중 반사 같은 문제는 실제 데이터에서 잘 드러난다.
하지만 실제 도로 데이터에는 한계도 있다. 위험한 사고 직전 상황을 일부러 만들 수 없고, 매우 드문 장면은 오래 주행해도 충분히 모이지 않는다. 또한 같은 상황을 정확히 반복하기 어렵다. 어제 본 끼어들기 장면을 오늘 같은 위치, 같은 속도, 같은 주변 차량 조건으로 다시 재현하는 것은 사실상 불가능하다.
시뮬레이션 데이터는 이 약점을 보완한다. 가상 도로에서 보행자 출현 위치, 차량 속도, 날씨, 조명, 노면 상태를 바꿔가며 반복 시험할 수 있다. 위험한 장면도 실제 사람을 다치게 하지 않고 만들 수 있다. 디지털 트윈 기반 시뮬레이션은 실제 지리 정보와 가상 환경을 연결해 시험 효율을 높이고 비용을 줄이는 방향으로 활용된다.3
그러나 시뮬레이션도 완전한 답은 아니다. 가상 세계의 센서 모델, 사람 행동 모델, 차량 동역학이 현실과 다르면 모델은 시뮬레이션에만 강해질 수 있다. 이것을 흔히 심투리얼 갭(sim-to-real gap)이라고 한다. 시뮬레이션에서 잘 달리던 기능이 실제 도로에서 흔들리는 이유가 여기에 있다.
따라서 실제 개발에서는 보통 역할을 나누어 생각한다. 실제 도로 데이터는 현실의 복잡성과 센서 특성을 배우는 데 사용하고, 시뮬레이션은 반복성, 위험 장면, 조건 변화 테스트에 사용한다. 중요한 판단은 둘 중 하나만 보고 내리지 않는다.
희귀 상황은 기다리는 것이 아니라 찾아내고 만든다
자율주행에서 어려운 장면은 대부분 자주 나오지 않는다. 고속도로 중앙에 떨어진 적재물, 비보호 좌회전 중 마주 오는 오토바이, 횡단보도 앞 불법 주정차 차량 뒤의 보행자, 눈으로 차선이 가려진 도로 같은 상황은 드물지만 안전에는 매우 중요하다.
이런 장면을 다루기 위해 개발팀은 시나리오 기반 개발을 사용한다. 시나리오는 "어떤 도로에서, 어떤 참여자가, 어떤 속도와 의도로 움직이는가"를 구조화한 시험 단위다. 예를 들어 다음과 같이 표현할 수 있다.
편도 2차로 도로에서 자차는 40km/h로 주행한다.
오른쪽 차로의 버스가 정류장에 정차해 시야를 가린다.
버스 앞에서 보행자가 횡단보도로 진입한다.
노면은 젖어 있고, 시간은 야간이다.
이런 시나리오는 실제 로그에서 찾아낼 수도 있고, 사람이 설계할 수도 있으며, 시뮬레이션에서 조건을 바꿔 여러 변형을 만들 수도 있다. 합성 데이터도 사용된다. 합성 데이터는 실제 촬영이 아니라 가상 환경이나 생성 기법으로 만든 데이터다. 드문 물체, 다양한 날씨, 여러 조명 조건을 빠르게 늘릴 수 있다.
다만 합성 데이터는 "많다"는 이유만으로 좋은 데이터가 되지 않는다. 현실과 너무 다르면 모델이 잘못된 특징을 배울 수 있다. 그래서 합성 데이터는 실제 데이터와 비교해 분포가 지나치게 벗어나지 않는지 확인해야 한다. 희귀 상황 개발의 목표는 사고 장면을 많이 모으는 것이 아니라, 위험을 대표하는 조건을 체계적으로 넓히는 것이다.
모델을 바꾸면 좋아지는 기능과 나빠지는 기능이 함께 생긴다
새 모델을 배포할 때 가장 흔한 착각은 "평균 성능이 좋아졌으니 전체가 좋아졌을 것"이라고 보는 것이다. 실제로는 그렇지 않다. 주간 차량 탐지는 좋아졌지만 야간 보행자 탐지가 나빠질 수 있다. 차선 인식은 좋아졌지만 공사 구간 임시 차선 대응이 나빠질 수 있다.
이를 막기 위해 회귀 테스트를 한다. 회귀 테스트는 새 버전이 기존에 잘하던 기능을 망가뜨리지 않았는지 확인하는 절차다. 자율주행에서는 단순한 소프트웨어 오류뿐 아니라 인공지능 성능 저하까지 함께 본다.
회귀 테스트에는 여러 층이 있다.
단위 테스트: 좌표 변환, 센서 시간 동기화, 거리 계산 같은 작은 기능을 확인한다.
데이터셋 평가: 고정된 검증 데이터에서 탐지율, 오탐, 미탐, 차선 오차 등을 비교한다.
시나리오 테스트: 위험하거나 중요한 장면에서 계획과 제어가 안전하게 반응하는지 본다.
시뮬레이션 반복 시험: 같은 조건을 여러 번 돌려 불안정한 행동이 없는지 확인한다.
차량 실주행 검증: 제한된 조건에서 실제 차량에 올려 센서, 제어, 컴퓨팅 지연까지 확인한다.
여기서 중요한 것은 하나의 점수로 판단하지 않는 것이다. 자율주행 모델은 "전체 정확도 1% 향상"보다 "어떤 상황에서 미탐이 줄었고, 어떤 상황에서 오탐이 늘었는가"가 더 중요하다. 특히 안전 관련 장면은 별도의 기준으로 관리해야 한다.
배포 이후에도 개발은 끝나지 않는다
자율주행 소프트웨어는 차량에 들어간 뒤에도 계속 관찰되어야 한다. 실제 도로에서는 실험실에서 예상하지 못한 조합이 나온다. 새로운 공사 방식, 지역별 표지판 차이, 계절 변화, 센서 오염, 운전자의 개입 패턴이 모두 성능에 영향을 준다.
그래서 운영 중인 차량은 로그를 남긴다. 로그에는 센서 원본 전체가 항상 저장되지는 않는다. 데이터 용량이 너무 크기 때문이다. 대신 특정 조건이 발생했을 때 중요한 구간을 저장한다. 예를 들어 급제동, 운전자 개입, 시스템 경고, 인지 신뢰도 급락, 계획 변경이 잦은 구간을 기록할 수 있다. 이런 로그는 다음 학습 데이터 후보가 된다.
현대적인 자율주행 개발 체계에서는 데이터 운영, 모델 학습, 검증, 배포, 차량 피드백이 하나의 반복 루프로 연결된다. 수집된 데이터는 다시 선별되고, 모델은 다시 학습되며, 검증 결과는 다음 배포 여부를 결정한다.4
OTA, 로그, 버전 관리는 안전 기능이다
OTA(Over-the-Air) 업데이트는 차량을 정비소에 가져가지 않아도 무선으로 소프트웨어를 갱신하는 방식이다. 지도, 인지 모델, 주행 정책, 사용자 기능, 보안 패치를 빠르게 반영할 수 있다는 장점이 있다. 하지만 자율주행에서 OTA는 단순한 편의 기능이 아니라 안전과 직접 연결되는 운영 절차다.
첫째, 무엇이 바뀌었는지 명확해야 한다. 모델 파일 하나, 라벨 기준 하나, 파라미터 하나가 차량 행동을 바꿀 수 있다. 따라서 소프트웨어 버전, 모델 버전, 지도 버전, 설정값 버전을 함께 관리해야 한다.
둘째, 되돌릴 수 있어야 한다. 새 버전에서 문제가 발견되면 이전 안정 버전으로 롤백할 수 있어야 한다. 차량이 업데이트 중 전원이 꺼지거나 통신이 끊겨도 안전한 상태를 유지해야 한다.
셋째, 차량마다 상태를 알아야 한다. 같은 모델이라도 센서 사양, 지역 지도, 하드웨어 세대, 법규 설정에 따라 다르게 동작할 수 있다. 개발사와 운영사는 어떤 차량이 어떤 버전을 쓰는지 정확히 알아야 한다.
넷째, 배포는 단계적으로 해야 한다. 모든 차량에 한 번에 배포하기보다 내부 차량, 제한된 시험 차량, 일부 지역 차량, 전체 차량 순서로 넓히는 방식이 안전하다. 각 단계에서 로그와 성능 지표를 보고 다음 단계로 넘어간다.
결국 자율주행 소프트웨어 개발은 코드를 잘 짜는 일만이 아니다. 데이터가 어디서 왔는지 알고, 모델이 무엇을 배웠는지 확인하고, 새 버전이 기존 기능을 망가뜨리지 않았는지 검증하고, 배포 이후에도 실제 도로의 신호를 계속 듣는 일이다. 자율주행차는 한 번 완성되어 끝나는 제품이 아니라, 데이터와 검증을 통해 조심스럽게 개선되는 움직이는 소프트웨어 시스템이다.
참고
1Mastering the Data Pipeline for Autonomous Driving
2DataOps for autonomous vehicle operations
3A Digital Twin-Driven Simulation Platform for Autonomous Vehicle Testing and Algorithm Validation
4Reference architecture for autonomous vehicle operations (AVOps)
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.