[자율주행] 시뮬레이션과 리시뮬 — 실차를 대체하는 게 아니라 증폭한다

시리즈를 여기까지 오면 자연스럽게 드는 질문이 있다. 실차를 굴리는 건 비싸다. 시뮬레이터를 24시간 돌려서 온갖 시나리오를 다 겪게 하면 더 싸고 빠르지 않나?

좋은 질문인데, 전제를 하나 뒤집는 것이 답의 출발점이다. 이미 시뮬레이션이 주력이다. 공개된 수치 기준으로 Waymo는 실주행이 수천만 마일일 때 시뮬 주행이 수백억 마일 규모였다. 비율로 1000배쯤 된다. 업계가 시뮬을 안 쓰고 있는 게 아니라, 시뮬이 압도적인데도 실차가 없어지지 않는 상황이다.

그러니 진짜 질문은 이것이다. 왜 안 없어지는가.

시뮬은 자기가 모르는 걸 못 만든다

시나리오를 만들려면 "무슨 일이 일어날 수 있는가"를 먼저 알아야 한다. 그런데 도로의 롱테일은 책상에서 나오지 않는다.

고속도로에 떨어진 매트리스. 신호등을 가린 채 정차한 대형 트럭. 공사 유도원의 애매한 수신호. 폭우에 반사돼 두 겹으로 보이는 차선. 날아가는 비닐봉지와 굴러오는 돌덩이의 구분.

실차 fleet을 굴리는 가장 큰 이유는 데이터 수집 그 자체가 아니라 "시나리오로 적을 생각조차 못 했던 상황의 발견" 이다. 시뮬은 알려진 위험을 1만 번 반복시키는 데 강하지, 새로운 위험을 발명하지는 못한다. 이건 도구의 성능 문제가 아니라 논리적 한계다.

센서가 세상을 잘못 보는 방식 (sim-to-real gap)

두 번째 이유는 인지 입장에서 더 아프다.

라이다 하나만 봐도 현실은 이렇게 지저분하다.

• 반사강도(intensity) 가 재질·입사각·습도에 따라 달라진다.
• 젖은 아스팔트는 거울처럼 반사하고, 검은 차량은 반사율이 낮아 점이 성기며, 유리·크롬은 엉뚱한 반환을 만든다.
• 눈·비·안개는 빔을 산란시키고, 배기가스와 흙먼지는 존재하지 않는 점을 만든다.
• 하나의 빔이 여러 번 되돌아오는 멀티에코, 스윕 도중 차가 움직여 생기는 모션 디스큐, 주변 차량 라이다와의 간섭.

카메라도 마찬가지다. 렌즈 플레어, 롤링 셔터, 자동노출의 반응 지연, ISP 파이프라인(디베이어·노이즈 리덕션·톤매핑)이 만드는 아티팩트. 터널에 진입하는 순간 노출이 못 따라가 화면이 통째로 날아가는 몇 프레임.

여기가 핵심이다. 인지 모델이 무너지는 지점은 정확히 "센서가 세상을 잘못 보는 방식"이다. 시뮬이 깨끗한 점 구름과 깨끗한 이미지를 주면, 모델은 깨끗한 세상에만 최적화되고 실차에서 붕괴한다. 시뮬을 잘 만들수록 좋아지는 게 아니라, 틀리는 방식까지 닮아야 쓸모가 있다.

이 간극을 좁히는 대표적인 갈래가 둘이다.

• 도메인 랜덤화(domain randomization) — 조명·재질·노이즈를 과하게 흔들어서, 실제 분포가 그 안에 들어오길 노린다. 거칠지만 값싸다.
• 도메인 적응(domain adaptation) — 시뮬 이미지를 실사처럼 변환하거나, 특징 공간에서 두 도메인을 정렬한다.

시뮬 속 다른 차는 누가 움직이나

세 번째 이유에는 순환 논리가 숨어 있다.

시뮬 안의 다른 차·보행자·자전거를 규칙 기반으로 움직이면, 그들은 우리가 가정한 대로만 움직인다. 모델은 그 가정에 과적합된다. 그렇다고 학습 기반으로 움직이면, 그 학습 데이터가 결국 실주행 로그다.

게다가 자차가 끼어들면 상대도 반응한다(reactive agents). 그 반응이 현실적인지는 무엇으로 검증하나. 다시 로그다. "현실적인 행동"의 근거는 어느 경로로 가든 실차에서 온다.

열린 루프와 닫힌 루프

여기가 시뮬레이션 이야기의 중심 개념이다.

열린 루프의 함정을 구체적으로 보자. 로그에서 자차는 A 지점에서 브레이크를 밟았다. 새 모델은 그 자리에서 조금 더 갔다고 하자. 그러면 그 다음 프레임의 세상은 로그와 더 이상 같지 않다. 상대 차와의 거리도, 시야에 들어오는 것도 달라진다. 그런데 열린 루프는 계속 원래 로그를 먹인다. 시간이 갈수록 평가가 현실과 멀어진다. 이걸 공변량 이동(covariate shift) 이라 부르고, 오차가 누적되는 성질 때문에 열린 루프 지표가 좋다고 실주행이 좋다는 보장이 없다.

그래서 인지는 열린 루프로도 상당 부분 검증되지만, 계획·제어는 닫힌 루프가 아니면 의미가 약하다. nuPlan처럼 닫힌 루프 점수를 명시적으로 재는 벤치마크가 나온 이유가 이것이다.

로그 리시뮬 — 실차 한 번을 1000번으로

닫힌 루프를 하려면 "바뀐 세상"을 그려야 한다. 여기서 두 갈래가 갈린다.

게임엔진 기반 합성 시뮬. CARLA(Unreal 기반 오픈소스), NVIDIA DRIVE Sim 계열. 세상을 처음부터 만들기 때문에 무엇이든 배치할 수 있다. 물리·조명·교통을 자유롭게 통제하고, 정답(ground truth)이 공짜다. 대신 그 세상은 우리가 만든 세상이라 앞서 말한 두 문제(모르는 시나리오, 센서 충실도)를 그대로 안고 있다.

로그 기반 리시뮬(resimulation). 실제 주행 로그로 장면을 재구성한 뒤, 그 안에서 자차를 다르게 움직여 본다. 최근 이 갈래가 빠르게 좋아진 이유는 뉴럴 재구성 덕이다. NeRF·3D Gaussian Splatting 계열로 주행 로그에서 장면을 복원하면, 원래 카메라가 지나가지 않은 시점에서도 그럴듯한 뷰를 뽑을 수 있다. 자율주행 로그를 겨냥한 연구(UniSim, NeuRAD 등)가 이 방향이다.

둘은 대체재가 아니라 역할이 다르다.

• 합성 시뮬 = 실제로 겪게 하기 위험하거나 드문 것(어린이 무단횡단, 역주행 진입)을 의도적으로 만든다.
• 로그 리시뮬 = 실제로 겪은 것을 변주해서 짜낸다.

그리고 여기서 리시뮬의 진짜 값어치가 나온다. 로그 한 장면을 놓고 파라미터를 흔든다. 그 보행자가 0.5초 빨랐다면? 옆 차가 30cm 더 붙었다면? 같은 상황이 젖은 노면이었다면? 한 장면이 수천 개의 변형이 된다.

시뮬의 역할은 실차 대체가 아니라, 실차 한 번의 가치를 1000배로 증폭하는 것이다.

시나리오와 커버리지의 착시

시나리오를 글이 아니라 기계가 읽는 형식으로 적어야 자동 실행·자동 변주가 된다. 업계 표준은 ASAM 계열이다.

• OpenDRIVE — 도로망(차선·연결·표지)의 정적 기술.
• OpenSCENARIO — 그 위에서 누가 언제 무엇을 하는지, 동적 시나리오의 기술.

이렇게 적어두면 하나의 시나리오에 파라미터 범위를 걸어 퍼징할 수 있다. 상대 속도 3070km/h, 진입 각도 1545°, 노면 마찰 0.3~0.9. 조합을 쓸어 담고, 실패하는 구석을 탐색적으로 좁혀 들어간다.

여기서 ODD(운행 설계 영역) 이야기가 붙는다. "우리 시스템은 어떤 조건에서 동작한다고 보장하는가"를 정의하고, 그 경계를 시나리오로 덮는 것이 검증의 뼈대다.

다만 반드시 붙여야 할 단서가 있다. 시뮬 커버리지 100%가 현실 커버리지 100%는 아니다. 우리가 정의한 파라미터 공간을 100% 덮었다는 뜻일 뿐이다. 파라미터 목록에 "유도원의 수신호"라는 축이 없으면, 그 축에서의 커버리지는 영원히 0이면서 대시보드는 초록색이다. 커버리지 숫자는 우리가 무엇을 셀 줄 아는가의 반영이지 안전의 증명이 아니다.

그래서 안전은 무엇으로 말하나

개발은 시뮬로 되지만, "안전하다"고 말하려면 실차 근거가 필요하다. 이유가 두 겹이다.

제도적으로. 국내 자율주행 임시운행허가, 미국 NHTSA 보고, UN ECE 계열 인증 모두 실도로 주행거리와 개입(disengagement) 기록을 본다.

논리적으로. 시뮬에서 성능이 좋다는 건 시뮬에서 좋다는 뜻이다. 그 시뮬이 현실을 대표한다는 것을 따로 증명해야 하는데, 그 증명이 다시 실차 데이터다. RAND의 유명한 계산(2016)은 인간 운전자 대비 안전성을 통계적으로 입증하려면 수억 마일 규모의 무사고 주행이 필요하다고 봤다. 실차만으로는 도달할 수 없는 숫자라 시뮬이 필수인데, 동시에 그 시뮬의 타당성은 실차로 앵커링해야 한다. 이 두 문장이 모순이 아니라 역할 분담이라는 점이 요지다.

데이터 플라이휠

지금까지의 이야기를 하나의 순환으로 그리면 이렇게 된다.

실차 fleet 주행  (대부분은 지루하다)
        ↓  자동 트리거로 흥미로운 구간만 추출
           급제동 · 운전자 개입 · 모델 불확실성 급증 · 인지↔예측 불일치
        ↓  그 장면을 리시뮬로 재구성
        ↓  파라미터 변주 — 한 장면 → 수천 변형
        ↓  실패 사례를 라벨링 큐로
        ↓  학습 → 배포 → 다시 수집

로그 데이터와 포맷에서 말한 '데이터 플라이휠'의 엔진이 정확히 이 자리다. 그리고 이 순환에서 실차의 역할은 "데이터를 모으는 곳"이 아니라 "모르던 것을 발견하고, 시뮬이 맞다는 것을 증명하는 곳" 으로 바뀐다.

비용 구조도 직관과 조금 다르다. 실차 운영이 비싼 건 맞지만, 큰 덩어리는 차량보다 라벨링과 스토리지다. 그리고 시뮬도 싸지 않다. 고충실도 센서 시뮬은 GPU 렌더팜이고 뉴럴 재구성은 학습 비용이 붙는다. 시뮬의 진짜 경제성은 다른 데 있다 — 정답을 이미 알고 있으니 라벨이 공짜다. 그래서 최적점은 "실차 최소화"가 아니라 "실차는 발견과 검증에, 시뮬은 증폭과 회귀 테스트에" 로 갈린다.

데이터 엔지니어의 시선

이 구조에서 데이터 쪽 일이 어디에 있는지가 분명하다.

• 트리거 설계. 페타바이트에서 무엇을 '흥미롭다'고 볼 것인가. 급감속·개입 같은 명시적 신호부터, 모델 불확실성이나 인지와 예측의 불일치 같은 내부 신호까지. 이 정의가 곧 플라이휠의 입구 크기다.
• 재현 가능한 로그. 리시뮬은 로그를 그대로 되살릴 수 있어야 성립한다. 시간 동기화·좌표계 규약·캘리브레이션 버전이 로그에 함께 박혀 있지 않으면, 몇 달 뒤 그 장면은 재현되지 않는다.
• 시나리오 DB와 커버리지 측정. 시나리오를 자산으로 쌓고, 어떤 축을 얼마나 덮었는지를 셀 수 있게 만드는 일. 그리고 못 세는 축이 무엇인지를 같이 적어두는 일.
• 결정론. 같은 입력에 같은 결과가 나와야 "이 변경이 이 회귀를 만들었다"고 말할 수 있다. 시드·부동소수점·실행 순서가 흔들리면 시뮬 결과는 증거가 되지 못한다.
• 버저닝. "모델 v7 = 데이터 스냅샷 2026-07-01 + 캘리브레이션 버전 x + 시나리오 세트 y". 셋 중 하나라도 빠지면 성능 회귀의 원인을 영영 못 찾는다.

정리

• 업계는 이미 시뮬이 주력이다. 질문은 "왜 시뮬을 안 쓰나"가 아니라 "왜 실차가 안 없어지나" 다.
• 실차가 남는 이유는 셋이다. 모르는 시나리오는 만들 수 없고, 센서가 틀리는 방식은 재현이 어렵고, 시뮬 속 상대의 행동은 결국 실주행 로그에서 온다.
• 열린 루프는 싸고 대량이지만 자차가 다르게 움직이는 순간 공변량 이동으로 무너진다. 계획·제어는 닫힌 루프여야 의미가 있다.
• 합성 시뮬(CARLA 등)은 위험한 것을 의도적으로 만들고, 로그 리시뮬은 겪은 것을 변주해 짜낸다. 역할이 다르다.
• 시나리오는 OpenDRIVE·OpenSCENARIO로 기계가 읽게 적어야 퍼징이 된다. 단 커버리지 숫자는 우리가 셀 줄 아는 축만 반영한다.
• 시뮬은 실차의 대체재가 아니라 증폭기다. 실차는 발견과 검증에, 시뮬은 증폭과 회귀 테스트에.

열한 편에 걸쳐 자율주행을 데이터의 눈으로 훑었다. 센서가 세상을 기록하는 법에서 시작해 좌표를 맞추고, 표현을 고르고, 길과 물체와 빈 공간과 미래를 읽고, 그 전부를 눈으로 보고, 파일로 쌓고, 마지막으로 그것을 다시 돌려 검증하는 데까지 왔다. 관통하는 문장은 처음과 같다. 자율주행은 모델 이전에 데이터의 문제이고, 데이터는 결국 좌표·시간·구조의 문제다.