The Autonomous Driving Stack
🎯 학습 목표
- 자율주행이 Physical AI의 한 갈래인 이유를 설명한다
- DRIVE 스택과 Alpamayo(AV foundation model)의 관계를 안다
- Cosmos가 AV 시뮬/데이터에 쓰이는 방식을 이해한다
- Halos 등 safety 프레임의 위치를 파악한다
- AV와 로봇이 스택을 공유하는 지점을 비교한다
지난 챕터들에서 우리는 휴머노이드와 mobile robot을 관통하는 하나의 구조 — three computers(DGX 학습 / Omniverse·Cosmos 시뮬 / Jetson 배치) — 를 반복해서 만났다. 이 챕터의 핵심 주장은 단순하지만 강력하다. 자율주행차(AV)는 로봇과 쌍둥이 문제이며, 정확히 같은 구조로 풀린다는 것이다.
Jensen Huang은 이를 명시적으로 말했다 — "자율주행차도 로봇이다. 여기에도 3대의 컴퓨터가 필요하다: 모델을 학습시키는 DGX, test drive와 synthetic data를 생성하는 Omniverse, 그리고 차 안에 들어가는 슈퍼컴 DRIVE AGX." 즉 로봇에서 배운 three-computer 렌즈를 그대로 도로 위로 옮기면 AV 스택이 보인다.
이 챕터는 그 매핑을 네 개의 이름으로 채운다 — 차량 내 컴퓨터 DRIVE AGX Thor, AV foundation model Alpamayo, 시뮬·데이터를 강화하는 Cosmos for AV, 그리고 안전을 책임지는 Halos. 이들은 각각 배치·정책·데이터·안전이라는 자리를 차지하며, 앞 챕터의 로봇 스택과 놀랍도록 대응된다.
동시에 이 챕터는 '완전히 같지는 않다'는 지점도 분명히 한다. AV는 로봇과 스택을 공유하지만, 안전·규제 제약이 훨씬 크고 open-road diversity(공공도로의 무한한 상황 다양성)가 문제의 본질이다. 그래서 로봇에는 없는 Halos 같은 safety 프레임이 스택의 정식 구성원으로 등장한다. 이 챕터의 목표는 AV를 Physical AI의 한 갈래로 자리매김하고, 공유하는 부분과 갈라지는 부분을 동시에 그려내는 것이다.
핵심 내용
10.1 자율주행은 왜 '로봇 문제'인가 — three computers의 재등장
자율주행을 별개의 산업으로 보는 습관을 먼저 버려야 한다. Physical AI의 관점에서 AV는 '바퀴 넷 달린 로봇'일 뿐이다.
로봇의 정의를 떠올려 보자 — 센서로 세계를 인식하고(perception), 무엇을 할지 결정하며(policy), 물리적으로 행동하는(actuation) 몸을 가진 기계. 자율주행차는 카메라·radar·lidar로 도로를 보고, 주행 정책으로 판단하며, 조향·가감속으로 움직인다. 정의가 그대로 들어맞는다.
그래서 로봇에서 쓴 도구가 그대로 재사용된다. three computers 프레임 = DGX(모델 학습) / Omniverse+Cosmos(시뮬레이션·synthetic data 생성) / Jetson·DRIVE AGX(실물 배치)라는 세 컴퓨터로 Physical AI 시스템을 만드는 NVIDIA의 공통 아키텍처.
Jensen Huang의 정식화가 이 대응을 못박는다.
-
DGX — 방대한 주행 데이터로 AV 모델을 학습한다(로봇의 policy 학습과 동일한 자리).
-
Omniverse(+Cosmos) — 가상 도로에서 test drive를 돌리고 synthetic sensor data를 생성한다(로봇의 Isaac Sim 시뮬과 동일한 자리).
-
DRIVE AGX — 학습된 모델을 담아 차 안에서 실시간 추론한다(로봇의 Jetson 배치와 동일한 자리).
왜 이 통합이 중요한가? NVIDIA는 로봇과 AV를 위해 두 벌의 스택을 만들지 않는다. 하나의 Physical AI 스택 — Omniverse에서 시뮬하고, Cosmos로 데이터를 늘리고, AGX 계열 칩에 배치 — 을 로봇에도 자동차에도 똑같이 판다. 이것이 이 코스가 로봇과 AV를 한 지도 안에 놓는 이유다. 학습·시뮬·배치라는 세 자리는 대상이 팔이든 바퀴든 변하지 않는다.
10.2 배치의 자리 — NVIDIA DRIVE와 DRIVE AGX Thor
three computers 중 '차 안의 슈퍼컴'을 담당하는 것이 DRIVE다. 로봇에서 Jetson이 앉던 자리에, AV에서는 DRIVE가 앉는다.
NVIDIA DRIVE = 자율주행(AV)을 위한 NVIDIA의 end-to-end 플랫폼. 차량 내 컴퓨터 하드웨어부터 그 위에서 도는 AV 소프트웨어 스택까지를 아우르는 이름이다.
DRIVE AGX Thor = 차량에 실제로 탑재되는 차량 내 컴퓨터(in-vehicle computer)로, NVIDIA의 Blackwell 아키텍처 기반이다. 자율주행에 필요한 대규모 신경망 추론을 차 안에서 실시간으로 감당하는 것이 임무다.
왜 차 '안'에 이만한 컴퓨터가 필요한가? 자율주행의 인식·판단은 클라우드에 맡길 수 없다. 시속 100km로 달리는 차가 판단을 클라우드에 왕복 요청하면, 그 지연(latency)이 곧 사고다. 그래서 무거운 foundation model 추론을 차량 안에서(on-vehicle) 밀리초 단위로 끝내야 하고, 이것이 DRIVE AGX Thor 같은 전용 슈퍼컴을 요구한다. 로봇에서 Jetson이 'edge에서의 실시간 추론'을 맡던 논리와 정확히 같되, 요구되는 연산 규모와 안전 등급이 더 높다.
이름 'Thor'가 세대를 표시한다는 점도 알아두면 좋다. NVIDIA DRIVE의 차량 컴퓨터는 세대를 거치며 이름을 바꿔 왔고, Thor는 Blackwell 세대의 최신 차량 컴퓨터다. 로봇 쪽 최신 배치 칩인 Jetson Thor(Chapter 12)와 이름이 같은 것은 우연이 아니다 — 둘 다 같은 Blackwell 세대의 edge 추론 칩 계열로, 로봇과 AV가 하드웨어 레벨에서도 형제임을 보여준다. 정리하면 DRIVE는 AV 스택의 '배치(deploy)' 꼭짓점이며, three computers의 세 번째 컴퓨터를 물리적으로 구현한다.
10.3 정책의 자리 — Alpamayo, AV foundation model
차 안의 컴퓨터(DRIVE AGX)가 하드웨어라면, 그 위에서 '무엇을 어떻게 운전할지'를 결정하는 두뇌가 필요하다. 그 두뇌가 Alpamayo다.
Alpamayo(알파마요) = NVIDIA의 AV foundation model(GTC 2026 기준 버전 1.5). 주행에 대한 추론(driving reasoning)과 정책(policy)을 담당하는, 자율주행판 foundation model이다.
AV foundation model이라는 개념 자체가 최근 흐름의 핵심이다. 과거 자율주행은 detection·prediction·planning을 각각 손으로 만든 여러 모듈로 쪼개 붙였다. foundation model 접근은 대신 방대한 주행 데이터로 학습한 하나의 큰 모델이 '주행을 통째로 추론'하게 한다 — 로봇에서 GR00T(Chapter 8)가 manipulation의 foundation model이었던 것과 정확히 대응된다. Alpamayo는 AV 스택에서 GR00T가 서던 '정책(policy)' 자리에 앉는다.
'reasoning(추론)'이 강조되는 이유를 짚어야 한다. 도로 위 상황은 규칙표로 다 못 담는다 — 공을 쫓아 튀어나올 것 같은 아이, 애매하게 걸친 공사 표지, 눈짓으로 양보를 주고받는 교차로. 이런 상황을 다루려면 단순 반응이 아니라 '저 상황이 무엇을 의미하고 어떻게 전개될지'를 추론하는 능력이 필요하다. Alpamayo가 driving reasoning을 내세우는 것은, AV의 어려움이 결국 open-road의 무한한 long-tail(희귀하지만 치명적인 상황)에 있기 때문이다.
스택 안에서의 위치로 정리하자. Alpamayo는 DGX에서 학습되고, DRIVE AGX에 배치되어 차 안에서 돈다. 즉 three computers의 학습 꼭짓점(DGX)과 배치 꼭짓점(DRIVE)을 잇는 '정책'이 바로 Alpamayo다. 그리고 이 정책을 학습·검증할 데이터를 대는 것이 다음 절의 Cosmos다.
10.4 데이터·시뮬의 자리 — Cosmos for AV
foundation model은 데이터를 먹고 자란다. 그런데 AV에서 '실제 도로 데이터'만으로는 결코 충분하지 않다 — 사고 직전의 위험 상황을 실물로 수집할 수는 없기 때문이다. 이 간극을 메우는 것이 Cosmos for AV다.
Cosmos for AV = CES 2025에서 강조된, AV의 three-computer 워크플로우를 강화하기 위한 Cosmos WFM(world foundation model)의 활용. 고품질·다양한 센서 데이터를 생성하고 AV 소프트웨어 스택을 검증하는 데 쓰인다.
작동 방식의 핵심은 Omniverse 물리 라이브러리에 conditioning(조건 부여)하는 것이다. 순수 생성 모델은 그럴듯하지만 물리적으로 틀린 장면을 만들 수 있다. 그래서 Omniverse로 만든 물리적으로 정확한 3D 장면(도로 기하·차량 배치·조명 등)을 조건으로 주고, 그 위에서 Cosmos WFM이 고충실도(high-fidelity) 센서 데이터와 현실적인 행동(realistic behavior)을 생성한다. 물리적 정합성은 Omniverse가 보장하고, 다양성·사실성은 Cosmos가 채우는 분업이다.
이것이 왜 결정적인가? 두 가지 문제를 동시에 푼다.
-
다양성(diversity) — 밤·비·눈·역광, 흔치 않은 도로 구조 등을 실제로 몇 년간 주행해 모으는 대신, 시뮬에서 조건만 바꿔 대량 생성한다. open-road의 long-tail을 데이터로 채우는 유일하게 현실적인 방법이다.
-
검증(validation) — 실제로 위험한 시나리오(끼어들기, 무단횡단)를 반복 재현해 AV 소프트웨어 스택이 올바로 반응하는지 안전하게 검증한다.
로봇 스택과의 대응도 명확하다. 로봇에서 Cosmos·synthetic data(Chapter 5·7)가 정책 학습의 데이터 갈증을 풀었듯, AV에서도 같은 Cosmos가 센서 데이터 생성과 스택 검증을 맡는다. three computers의 '시뮬레이션' 꼭짓점(Omniverse+Cosmos)이 AV에서 하는 일이 바로 이것이다 — 실물 test drive로는 불가능한 규모와 위험도의 상황을 가상에서 무한히 만들어 Alpamayo를 먹이고 시험한다.
10.5 안전의 자리 — Halos, 그리고 AV가 로봇과 갈라지는 지점
여기서 AV 스택은 로봇 스택과 결정적으로 갈라진다. 로봇에는 없던 새로운 정식 구성원 — 안전(safety) — 이 등장한다.
Halos(할로스) = NVIDIA의 AV safety 시스템/프레임워크. 자율주행 시스템의 안전을 검증(safety validation)하는 것을 목적으로 하는, 스택 전반을 아우르는 안전 체계다.
왜 AV에는 안전이 별도의 스택 구성원이 되어야 하는가? 창고 로봇이 실수하면 상자를 떨어뜨리지만, 자율주행차가 실수하면 사람이 다친다. 게다가 AV는 규제(regulation) 아래 있다 — 안전을 '잘 되면 좋은 것'이 아니라 '증명해야 하는 것'으로 요구받는다. 그래서 안전은 개발이 끝난 뒤 붙이는 검사가 아니라, 학습·시뮬·배치 전 과정에 스며드는 프레임이 되어야 하고, 그 자리를 Halos가 채운다.
Halos가 앞의 조각들과 어떻게 맞물리는지 보면 스택이 완성된다 — Cosmos for AV가 위험 시나리오를 대량 생성하면, Halos는 그 시나리오들에 대해 AV 소프트웨어(Alpamayo 포함)가 안전하게 반응하는지 체계적으로 검증한다. 즉 데이터 생성(Cosmos)과 안전 검증(Halos)이 짝을 이뤄, open-road의 long-tail을 '만들어내고 → 그에 맞서 안전을 증명'하는 루프를 돈다.
이제 AV와 로봇의 공유와 분기를 정리하자.
| 관점 | 공유하는 것 | AV가 다른 것 |
|---|---|---|
| 아키텍처 | three computers(DGX/Omniverse·Cosmos/AGX) 동일 | — |
| 시뮬 | Omniverse 물리 + Cosmos 데이터 생성 공유 | open-road diversity가 문제의 본질 |
| 배치 | AGX 계열 edge 칩(Thor) 공유 | 실시간·안전 등급 요구가 더 높음 |
| 안전 | — | Halos 같은 safety 프레임이 정식 구성원, 규제 제약 큼 |
이 표가 이 챕터의 결론이다. AV와 로봇은 스택(Omniverse 시뮬·Cosmos 데이터·AGX 배치)을 공유하는 쌍둥이지만, AV 쪽이 안전·규제·도로 다양성이라는 무게를 훨씬 더 진다. 그래서 로봇 스택에 Halos라는 안전 축을 더한 것이 AV 스택이라고 이해하면 된다. 실제로 유럽의 여러 로봇·AV 제조사들이 Isaac·Omniverse와 함께 Halos를 채택하고 있다는 점은, 이 공유 스택이 산업 표준으로 굳어지고 있음을 보여준다.
💡 비유로 이해하기
AV와 로봇의 관계를 이해하려면, 드론 조종사와 여객기 조종사를 같은 학교에서 길러내는 상황을 떠올리면 된다. 두 조종사 모두 같은 커리큘럼으로 배운다 — 계기 읽는 법(perception), 상황 판단(policy), 조종간 다루기(actuation). NVIDIA의 three computers가 바로 이 공용 훈련 커리큘럼이다. 교실에서 이론을 배우고(DGX 학습), 위험 없는 시뮬레이터에서 무한히 연습하며(Omniverse+Cosmos), 실전에서 실시간으로 조종한다(DRIVE AGX). 드론이든 여객기든 이 세 단계는 변하지 않는다.
연습용 시뮬레이터가 특히 중요한 이유는, 실제로는 겪게 하고 싶지 않은 상황을 안전하게 만들어낼 수 있기 때문이다. 엔진 하나가 꺼지는 순간, 폭풍 속 착륙, 활주로에 뛰어든 물체 — 실제 비행으로 이걸 연습시킬 수는 없다. Cosmos for AV가 하는 일이 정확히 이것이다. Omniverse가 물리적으로 정확한 무대(공항·기상)를 세우고, 그 위에서 Cosmos가 온갖 위험 시나리오를 사실적으로 생성해 무한히 연습시킨다. 실제 도로의 희귀하고 치명적인 long-tail을 가상에서 만들어 조종사(Alpamayo)를 단련하는 것이다.
하지만 여기서 여객기 조종사에게는 드론 조종사에게 없는 것이 하나 더 붙는다 — 항공 당국의 엄격한 안전 인증(certification)이다. 드론이 추락하면 장비가 부서지지만, 여객기가 추락하면 승객이 죽는다. 그래서 여객기 조종사는 '잘 날 수 있다'로 끝나지 않고 '안전을 증명해야' 한다. Halos가 바로 이 항공 안전 인증 체계에 해당한다 — 시뮬레이터가 만든 모든 위기 상황에 대해 조종사가 안전하게 대응함을 체계적으로 검증한다.
결국 로봇(드론)과 AV(여객기)는 같은 학교, 같은 시뮬레이터, 같은 조종 훈련을 공유하는 형제다. 다만 여객기 쪽에 안전 인증이라는 무거운 관문이 하나 더 있을 뿐이다. NVIDIA는 두 개의 학교를 짓지 않았다 — 하나의 훈련 체계에 안전 관문(Halos)을 더해 여객기 과정을 만들었다.
💻 코드 예시
AV 스택을 three computers에 매핑하는 개념 코드다. 실제 API가 아니며, 요점은 'AV가 로봇과 같은 DGX(학습)→Omniverse·Cosmos(시뮬·데이터)→DRIVE AGX(배치) 흐름을 따르되, Halos라는 safety 검증 단계가 정식으로 끼어든다'는 점이다.
# AV 스택 = three computers + safety. 로봇 스택과 같되 Halos가 추가된다.
# --- Computer 2: Omniverse + Cosmos for AV (시뮬·데이터 생성) ---
def generate_av_sensor_data(scenarios):
stage = omniverse.build_physical_scene() # 물리적으로 정확한 3D 도로
data = []
for sc in scenarios: # e.g. 비/야간/무단횡단 long-tail
# Omniverse 물리에 conditioning해 고충실 센서 데이터 생성
frames = cosmos_wfm.generate(condition=stage, scenario=sc)
data.append(frames) # camera/radar/lidar 합성
return data
# --- Computer 1: DGX (Alpamayo 학습) ---
def train_av_model(real_logs, synthetic_data):
dataset = real_logs + synthetic_data # 실주행 + 합성으로 다양성 확보
alpamayo = dgx.train(dataset, task="driving_reasoning+policy")
return alpamayo # AV foundation model
# --- Safety: Halos (로봇 스택엔 없는 AV 전용 관문) ---
def validate_safety(alpamayo, hazard_scenarios):
report = halos.verify(alpamayo, hazard_scenarios) # 규제 대응 안전 검증
assert report.passes, "safety not proven — 배치 불가"
return report
# --- Computer 3: DRIVE AGX Thor (차량 내 배치) ---
synthetic = generate_av_sensor_data(long_tail_scenarios)
alpamayo = train_av_model(real_logs, synthetic)
validate_safety(alpamayo, hazard_scenarios) # 통과해야만
drive_agx_thor.deploy(alpamayo) # 차 안 실시간 추론이 코드는 AV 스택이 로봇 스택의 three computers를 그대로 따른다는 것을 보여준다. generate_av_sensor_data는 Computer 2(Omniverse+Cosmos)로, Omniverse가 물리적으로 정확한 무대를 세우고 그에 conditioning해 Cosmos가 long-tail 시나리오의 고충실 센서 데이터를 생성한다 — 실주행으로 못 모으는 위험 상황을 채운다. train_av_model은 Computer 1(DGX)로, 실주행 로그와 합성 데이터를 합쳐 Alpamayo(driving reasoning+policy)를 학습한다 — 로봇의 GR00T 학습과 같은 자리다. 결정적 차이는 validate_safety다. 로봇 스택에는 없던 Halos가 배치 직전 관문으로 끼어들어, 안전이 증명되지 않으면(assert 실패) 배치를 막는다 — AV의 규제·안전 제약이 코드 흐름에 정식으로 박혀 있음을 드러낸다. 마지막 drive_agx_thor.deploy가 Computer 3, 즉 Jetson 자리를 대신하는 차량 내 배치다. 요컨대 'AV 스택 = 로봇 스택(학습·시뮬·배치) + Halos(safety gate)'라는 이 챕터의 결론이 코드 한 장에 담긴다.
🏭 현업에서의 평가
✅ 시니어가 보는 것
- AV를 '바퀴 달린 로봇'으로 규정하고, three computers(DGX 학습 / Omniverse·Cosmos 시뮬·데이터 / DRIVE AGX 배치)에 정확히 매핑하며 Jensen의 정식화를 이해하는가
- Alpamayo를 AV foundation model(driving reasoning+policy)로 규정하고, 로봇의 GR00T와 같은 '정책' 자리임을 대응시키며 왜 reasoning이 open-road long-tail 때문에 중요한지 설명하는가
- Cosmos for AV가 Omniverse 물리에 conditioning해 고충실 센서 데이터를 생성한다는 메커니즘과, 그것이 다양성(long-tail 데이터)과 검증 두 문제를 동시에 푸는 이유를 이해하는가
- Halos를 safety 검증 프레임으로 규정하고, AV에 안전이 별도 구성원이 되어야 하는 이유(사고=인명·규제)와 Cosmos(위험 생성)와 짝을 이루는 루프를 설명하는가
- AV와 로봇이 스택을 공유하되 AV는 안전·규제·open-road diversity가 훨씬 크다는 분기점을 구분하고, Thor가 Jetson과 같은 Blackwell 세대 edge 칩임을 아는가
⚠️ 레드 플래그
- 자율주행을 로봇과 무관한 별개 산업으로 보고 three computers 프레임에 매핑하지 못하는 경우
- Alpamayo를 단순 'NVIDIA 자율주행 소프트웨어'로만 보고 AV foundation model(정책·추론)이자 GR00T와 대응되는 자리임을 놓치는 경우
- Cosmos for AV를 그냥 그래픽 생성으로 보고, Omniverse 물리에 conditioning한다는 점과 long-tail 데이터·검증이라는 목적을 설명하지 못하는 경우
- Halos·safety를 스택의 부수적 요소로 치부하고, AV가 로봇과 갈라지는 핵심(안전·규제 제약)이 여기임을 인식하지 못하는 경우
- DRIVE AGX Thor를 Jetson과 무관한 칩으로 보거나, AV와 로봇이 하드웨어·스택을 공유한다는 큰 그림을 그리지 못하는 경우
🎤 예상 인터뷰 질문
- Q1 (구조): 자율주행차가 왜 '로봇 문제'인지, three computers(DGX/Omniverse·Cosmos/DRIVE AGX)로 설명하라. 각 컴퓨터가 AV에서 무엇을 담당하며 로봇 스택의 어느 자리와 대응되는가?
- Q2 (데이터·정책): Alpamayo가 AV foundation model로서 하는 일과, Cosmos for AV가 그 학습·검증 데이터를 어떻게 대는지 설명하라. Cosmos가 Omniverse 물리에 conditioning하는 이유와, 이것이 open-road long-tail을 어떻게 다루는가?
- Q3 (분기): AV와 로봇이 스택을 공유하는 지점과 갈라지는 지점을 대비하라. Halos 같은 safety 프레임이 왜 AV에는 정식 구성원이어야 하며, Cosmos와 어떻게 짝을 이루는가?
✨ 핵심 요약
자율주행차는 로봇과 쌍둥이 문제다
AV는 센서로 세계를 인식하고 정책으로 판단하며 물리적으로 움직이는 '바퀴 달린 로봇'이다. 그래서 로봇과 정확히 같은 three computers 구조로 풀린다 — NVIDIA는 로봇과 AV를 위해 두 벌의 스택을 만들지 않고 하나의 Physical AI 스택을 공유한다.
three computers 매핑 — DGX / Omniverse·Cosmos / DRIVE AGX
Jensen의 정식화: 모델 학습은 DGX, test drive와 synthetic data 생성은 Omniverse, 차 안 실시간 추론은 DRIVE AGX가 맡는다. 로봇의 DGX·Isaac Sim·Jetson 자리에 그대로 대응된다.
DRIVE와 DRIVE AGX Thor — 배치의 자리
NVIDIA DRIVE는 하드웨어부터 AV 소프트웨어까지 아우르는 AV 플랫폼이고, DRIVE AGX Thor는 Blackwell 기반 차량 내 컴퓨터다. 지연이 곧 사고이므로 무거운 추론을 차 안에서 실시간 처리한다. 로봇의 Jetson Thor와 같은 Blackwell 세대 edge 칩이다.
Alpamayo — AV foundation model(정책의 자리)
GTC 2026 기준 1.5 버전으로, driving reasoning과 policy를 담당한다. 모듈을 손으로 붙이던 과거와 달리 하나의 큰 모델이 주행을 통째로 추론한다. 로봇의 GR00T와 같은 '정책' 자리이며, open-road long-tail 때문에 reasoning이 핵심이다.
Cosmos for AV — 데이터·시뮬의 자리
CES 2025에서 강조된 활용으로, Omniverse 물리 라이브러리에 conditioning해 고충실 센서 데이터와 현실적 행동을 생성한다. 실주행으로 못 모으는 long-tail 다양성을 채우고, 위험 시나리오로 AV 소프트웨어 스택을 안전하게 검증한다.
Halos — 안전의 자리, AV가 로봇과 갈라지는 지점
NVIDIA의 AV safety 시스템/프레임으로 자율주행의 안전을 검증한다. 로봇과 달리 AV는 사고가 인명·규제와 직결되므로 안전이 스택의 정식 구성원이다. Cosmos가 위험을 생성하면 Halos가 그에 맞선 안전을 증명하는 루프를 돈다.
공유하되 갈라진다 — 스택은 같고 안전·규제는 다르다
AV와 로봇은 three computers 아키텍처, Omniverse 시뮬, Cosmos 데이터, AGX 배치를 공유한다. 다만 AV는 안전·규제 제약이 훨씬 크고 open-road diversity가 문제의 본질이라, 로봇 스택에 Halos라는 safety 축을 더한 것이 AV 스택이다.
산업 표준으로 굳는 공유 스택
유럽의 여러 로봇·AV 제조사들이 Isaac·Omniverse와 함께 Halos를 채택하고 있다. 이는 로봇과 AV가 하드웨어(Thor)·시뮬(Omniverse·Cosmos)·안전(Halos)을 공유하는 하나의 Physical AI 스택이 산업 표준으로 자리 잡고 있음을 보여준다.