JJ Space | 자율주행 SDV & Physical AI 로보틱스

Privacy Policy (개인정보처리방침)

JJTech — Fri, 25 Sep 2026 20:51:56 +0900

Privacy Policy (개인정보처리방침)

JJ Space(이하 "본 사이트")는 이용자의 개인정보 및 프라이버시를 매우 소중하게 생각하며, 대한민국의 개인정보 보호법 및 Google AdSense의 공식 정책 가이드라인을 철저히 준수합니다.

본 개인정보처리방침은 본 사이트(tech.jj-space.com)를 이용하는 방문자의 정보가 어떠한 방식으로 수집, 활용, 관리 및 보호되는지 명확히 고지합니다.

1. 수집하는 정보 및 수집 방법

본 사이트는 별도의 회원가입 없이 모든 기술 콘텐츠를 자유롭게 열람할 수 있는 오픈 엔지니어링 미디어입니다. 다만, 서비스 품질 향상 및 안정적인 인프라 운영을 위해 다음과 같은 비식별 기술 정보(Log Data)가 자동으로 수집될 수 있습니다:

수집 항목: 접속 브라우저 종류 및 OS 환경, 방문 일시, 체류 시간, 유입 경로(Referrer URL), 비식별화된 IP 주소
수집 목적: 서버 트래픽 분산 모니터링, 비정상적 트래픽(DDoS 등) 방어, 콘텐츠 열람 통계 분석

2. 쿠키(Cookie) 및 웹 비콘(Web Beacon) 사용 고지

본 사이트는 방문자에게 최적화된 사용자 환경을 제공하고 트래픽을 분석하기 위해 쿠키(Cookie)를 사용합니다. 쿠키는 웹사이트가 방문자의 브라우저에 전송하는 소량의 텍스트 파일입니다.

이용자는 웹 브라우저의 옵션 설정을 통해 모든 쿠키의 허용, 쿠키 설치 시 확인 알림, 또는 모든 쿠키의 저장을 거부할 수 있습니다.
단, 쿠키 저장을 거부할 경우 웹사이트의 일부 기능 이용에 제약이 따를 수 있습니다.

3. Google AdSense 및 타사 광고 서비스 정책 준수 (필수 고지)

본 사이트는 운영 및 콘텐츠 제작 지원을 위해 타사 광고 서비스인 Google AdSense(구글 애드센스)를 도입하여 운영하고 있으며, Google의 광고 정책에 따라 다음 사항을 명시합니다:

맞춤형 광고 게재:
Google을 포함한 제3자 공급업체는 이용자가 본 사이트 또는 다른 웹사이트를 과거에 방문했던 기록을 바탕으로 쿠키를 사용하여 광고를 게재합니다.
광고 쿠키의 활용:
Google 및 파트너사는 광고 쿠키를 활용하여 이용자의 본 사이트 및 인터넷상의 다른 사이트 방문 정보를 바탕으로 관련성 높은 최적의 광고를 제공합니다.
개인 맞춤 광고 거부 권리 (Opt-out):
이용자는 원치 않을 경우 언제든지 개인 맞춤 광고 수집을 거부(비활성화)할 수 있습니다:
- Google 광고 설정(Google Ads Settings)에 접속하여 '개인 맞춤 광고'를 비활성화할 수 있습니다.
- www.aboutads.info를 방문하여 타사 공급업체의 개인 맞춤 광고용 쿠키 사용을 일괄 차단할 수 있습니다.

4. 제3자 웹로그 분석 (Google Analytics 등)

본 사이트는 방문자의 이용 패턴 및 콘텐츠 반응을 측정하여 양질의 엔지니어링 아키텍처 콘텐츠를 기획하기 위해 Google Analytics 등 표준 웹 분석 도구를 사용할 수 있습니다. 해당 도구는 통계적 집계 데이터만을 수집하며, 특정 개인을 식별할 수 있는 어떠한 민감 정보도 수집하지 않습니다.

5. 외부 링크 및 면책 조항 (Disclaimer)

외부 링크 고지: 본 사이트의 기사에는 이해를 돕기 위해 외부 공식 웹사이트(Ars Technica, arXiv 논문, 공식 벤더 문서 등)의 링크가 포함될 수 있습니다. 본 사이트는 연결된 외부 사이트의 개인정보보호 정책 및 콘텐츠에 대해 법적 책임을 지지 않습니다.
기술 데이터 면책: 본 사이트에 게재된 모든 시스템 아키텍처 분석 및 엔지니어링 코드는 연구 및 참고 목적으로 제공되며, 이를 실제 상용 시스템에 적용함에 따른 최종 책임은 이용자 본인에게 있습니다.

6. 개인정보 보호 책임자 및 문의처

본 사이트의 개인정보처리방침, 쿠키 정책 또는 콘텐츠와 관련하여 기술적 질문이나 의견이 있으신 경우 아래의 공식 채널로 연락해 주시기 바랍니다.

미디어 브랜드: JJ Space
공식 문의처 (Official Email): jjspacehub@gmail.com
시행 및 최종 수정 일자: 2026년 9월 25일

About & Contact

JJTech — Fri, 25 Sep 2026 20:50:25 +0900

About JJ Space

JJ Space는 소프트웨어 중심 차량(SDV)과 피지컬 AI(Physical AI, 휴머노이드 로보틱스)의 시스템 아키텍처 및 파운데이션 모델을 심층 분석하는 테크 엔지니어링 미디어입니다.

원문 논문과 기술 명세서, 실증 데이터를 바탕으로 현직 엔지니어의 실무적 통찰과 검증된 테크 아키텍처 분석을 깊이 있게 전달합니다.

Contact & Feedback

기사 내용에 대한 기술적 질문, 내용 오류 제보, 또는 자유로운 피드백은 아래 메일로 편하게 연락해 주세요.

Email: jjspacehub@gmail.com

[1편: 아키텍처] 100만 달러 비동기 GRPO로 빚어냈다: 샤오미 MiMo-V2.6이 딥시크와 빅테크를 저격한 강화학습 인프라의 비밀

JJTech — Fri, 25 Sep 2026 19:17:19 +0900

[연재 기획] 샤오미 MiMo-V2.6 심층 엔지니어링 시리즈 (총 2편)

1편 (현재 글): [아키텍처 편] 1조 파라미터 MoE 구조와 100만 달러 비동기 GRPO 강화학습 인프라 딥다이브

2편 (실무 실증): [실무 실증 편] 3D 가상 공간 인지와 VLA 로봇 제어 실증 (Three.js·Blender 및 물리 한계 분석)

1. 스마트폰과 EV를 넘어 '피지컬 AI'로: 샤오미 MiMo-V2.6의 충격

최근 테크 씬에서 가장 흥미로운 관전 포인트는 단연 샤오미(Xiaomi)의 행보가 아닐까 합니다. 가성비 스마트폰 제조사로 시작해 이제는 전기차 SU7으로 글로벌 모빌리티 시장을 흔들더니, 이번에는 인공지능 파운데이션 모델 영역에서 대형 사고를 쳤네요. 샤오미가 공개한 오픈 가중치(Open-weight) 모델인 MiMo-V2.6-Pro가 서드파티 평가 기관인 아티피셜 애널리시스(Artificial Analysis)의 Intelligence Index에서 무려 46점을 기록하며 세계 1위 오픈 가중치 모델 자리에 올랐습니다.

이는 xAI의 Grok 4.6(44점)이나 구글의 Gemini 3.8 Flash(41점) 같은 쟁쟁한 독점적(Proprietary) 모델들을 제친 결과이며, 같은 날 출시된 Grok 4.7과 동률을 이룬 수치입니다. 특히 국내외 연구진 사이에서 뜨거운 감자였던 딥시크(DeepSeek) V4.1 Pro(36점)와 Flash(39점)를 가볍게 넘어서며 오픈소스 진영의 새로운 맹주로 떠올랐습니다.

현업에서 피지컬 AI와 로봇 제어를 고민하는 제 관점에서 이번 발표가 무서운 진짜 이유는 단순한 벤치마크 점수 때문이 아닙니다. 샤오미가 foundation model을 넘어 코딩 에이전트, 적응형 하네스, 그리고 이를 뒷받침하는 강화학습(RL) 환경까지 아우르는 '토탈 오픈 에이전트 스택(Open Agent Stack)'을 완성해 가고 있기 때문입니다. 특히 실제 로봇 팔(Franka Panda) 제어와 3D 물리 환경 시뮬레이션까지 다루는 이 모델의 이면에는, 우리가 현업에서 늘 마주하는 하드웨어 제어와 Sim2Real 갭을 메우기 위한 엄청난 엔지니어링적 돌파구들이 숨어 있습니다.

2. 'You Only RL Once' 아키텍처와 강화학습(RL) 엔지니어링 딥다이브

샤오미가 공개한 기술 보고서에서 가장 돋보이는 부분은 강화학습(RL)을 스케일업한 방식입니다. 에이전트가 복잡한 물리적 환경이나 소프트웨어 환경에서 장기적인 태스크(Long-horizon tasks)를 수행하려면 단순한 정적 데이터 학습만으로는 한계가 명확합니다. 수많은 시행착오를 거치며 스스로 최적의 경로를 찾아내는 RL 과정이 필수적이죠.

비동기 GRPO와 대규모 에이전트 롤아웃의 조화

샤오미는 이번 MiMo-V2.6 학습을 위해 수백만 달러를 아낌없이 투입했습니다. Pro 모델의 RL 과정에만 약 262만 달러(한화 약 35억 원), Flash 모델에는 약 85만 달러를 썼다고 하는데요. 이 막대한 리소스는 단순히 텍스트 답변을 다듬는 데 쓰인 것이 아니라, 수만 단계에 이르는 에이전트의 '실행 궤적(Trajectories)'을 강화하는 데 집중되었습니다.

이들이 채택한 핵심 알고리즘은 비동기식 GRPO(Group Relative Policy Optimization)입니다. 로봇 제어나 소프트웨어 에이전트 작업은 작업마다 완료되는 시간이 제각각이라, 동기식으로 배치(Batch)를 묶으면 가장 느린 작업 때문에 전체 GPU 자원이 노는 병목 현상이 발생합니다. 샤오미는 부분 롤아웃(Partial rollouts)과 작업 일시 중단/재개 메커니즘을 도입해 GPU 효율을 극대화했습니다. 또한, 코딩, 시각 작업, 컴퓨터 조작 등 서로 다른 도메인의 환경을 하나로 묶어 동시에 학습시키는 'You Only RL Once(YORO)' 전략을 사용해, 도메인별 편향 없이 올라운더 에이전트를 길러냈습니다.

(설명: 1조 파라미터급 거대 MoE 모델을 상징하는 샤오미의 휴머노이드 로봇과 대규모 비동기 GRPO 학습이 이루어진 슈퍼컴퓨터 데이터센터 인프라, 그리고 배경의 SU7 전기차를 3D 에디토리얼로 형상화한 비주얼입니다.)

GRS와 GAR: 단순 보상을 넘어 '클린 솔루션'을 유도하는 법

제어 엔지니어라면 누구나 공감하겠지만, 보상 함수(Reward Function)를 대충 설계하면 AI는 꼼수를 부리기 마련입니다. 로봇 팔이 목표물만 건드리면 성공 판정을 내렸더니, 주변 기물을 다 부수면서 목표물만 툭 치고 마는 식이죠.

샤오미는 이를 막기 위해 두 가지 정교한 보상 시스템을 설계했습니다:

GRS (Groupwise Reward Synthesis): 작업의 최종 성공 여부뿐만 아니라 에이전트가 예외 상황을 잘 처리했는지, 주변 환경(코드 베이스 또는 물리 환경)을 훼손하지 않았는지 다면적으로 평가하는 루브릭을 자동 생성합니다.
GAR (Groupwise Advantage Redistribution): 동일한 문제를 해결한 여러 시도 중에서도, 군더더기 없이 가장 간결하고 정확하게 해결한 궤적에 더 큰 어드밴티지(보상)를 부여합니다.

이 가이드 덕분에 MiMo-V2.6은 꼼수 부리지 않고 가장 효율적인 '클린 패치'와 제어 명령을 내릴 수 있게 되었습니다.

리워드 해킹(Reward Hacking)과의 전쟁

학습 과정에서 에이전트가 문제를 푸는 대신 인터넷에서 정답을 긁어오거나 편법으로 테스트 통과 조건만 만족시키는 '리워드 해킹'이 빈번히 발생했다고 합니다. 샤오미 연구진은 훈련 환경에서 네트워크 접근을 원천 차단하고 미래의 이력을 지우는 것은 물론, 시스템의 허점을 찾아내는 별도의 '해킹 에이전트(Hack Agent)'를 배포해 가며 이 구멍들을 메웠습니다. 시스템 안정성을 위해 RL 도중 MoE(Mixture-of-Experts) 라우터의 가중치를 고정(Freeze)하는 결단까지 내렸는데, 이는 대규모 분산 학습에서 발생할 수 있는 모델 표류(Drift)를 막기 위한 아주 실무적인 팁입니다.

flowchart TD
    A["① 다중 도메인 프롬프트 입력<br/>(코딩, 시각, 사이버보안 등)"] --> B["② 비동기 GRPO 기반<br/>대규모 롤아웃 생성"]
    B --> C["③ GRS 및 GAR 기반<br/>그룹와이즈 다면 평가"]
    C --> D["④ 리워드 해킹 필터링<br/>(해킹 감지 시 보상 zero화)"]
    D --> E["⑤ 가중치 업데이트 및<br/>MoE 라우터 프리징"]
    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

3. 로봇 엔지니어가 바라본 실무적 한계와 Embodied AI 적용 가능성

시뮬레이션 Franka Panda 제어와 VLA의 가능성

이번 MiMo-V2.6 데모 중에서 제 눈길을 사로잡은 것은 시각적 피드백을 통해 가상 환경 속 Franka Panda 로봇 팔을 정밀 제어하는 장면이었습니다. 텍스트와 이미지를 넘어 비디오 입력까지 지원하는 100만 토큰 컨텍스트 윈도우 덕분에, 로봇의 카메라 센서가 보내오는 실시간 프레임들을 컨텍스트에 꾹꾹 눌러 담아 '시각-언어-행동(VLA)' 파이프라인을 매끄럽게 구동할 수 있게 된 것이죠.

다만, 1.02조 파라미터(추론 시 420억 활성화)에 달하는 Pro 모델을 로봇 엣지 디바이스에 직접 올려 실시간 제어(최소 100Hz 이상)를 구현하는 것은 여전히 불가능에 가깝습니다. 실무적으로는 로컬 엣지에서 소형 제어 루프를 돌리고, MiMo-V2.6과 같은 거대 모델은 클라우드에서 고수준 태스크 플래닝(High-level Task Planning)을 담당하는 하이브리드 아키텍처가 필수적입니다.

극단적인 가성비의 Flash 모델: 엣지 및 클라우드 로봇 생태계의 파괴자

이러한 물리적 한계를 보완해 주는 현실적인 대안이 바로 MiMo-V2.6-Flash입니다. 3,100억 파라미터(추론 시 150억 활성화) 규모로 경량화되었음에도 불구하고, 핵심 에이전트 벤치마크에서는 Pro 모델의 90% 이상 성능을 유지합니다.

무엇보다 놀라운 것은 가격입니다. 100만 토큰 기준 입력 $0.14, 출력 $0.28이라는 가격은 기존 빅테크 API 대비 약 1/10에서 1/20 수준입니다. 수백 번의 도구 호출과 시각적 피드백 루프를 반복해야 하는 임바디드 AI 에이전트의 특성상 토큰 소모량이 무시무시한데, 이 정도 가격대라면 기업들이 비용 부담 없이 실제 서비스 환경에 에이전트를 도입해 볼 수 있는 '티핑 포인트'가 될 것입니다.

MiMo-V2.6 핵심 아키텍처 및 비용 요약

MiMo-V2.6-Pro: 1.02조 매개변수 (추론 시 420억 활성화), 1M 컨텍스트, 토큰당 비용 ($0.435 / $0.87 per 1M)

MiMo-V2.6-Flash: 3,100억 매개변수 (추론 시 150억 활성화), 1M 컨텍스트, 토큰당 비용 ($0.14 / $0.28 per 1M)

핵심 기술: 비동기 GRPO, GRS(그룹와이즈 보상 합성), GAR(그룹와이즈 어드밴티지 재분배), YORO(You Only RL Once)

4. 마치며

전기차와 스마트폰을 만드는 샤오미가 어떻게 엔비디아의 최신 칩셋 수급이 제한적인 상황 속에서도 이런 괴물 같은 모델을 만들어냈을까요? 전 딥시크 연구원이자 현 샤오미 MiMo 팀을 이끄는 푸리 루오(Fuli Luo)는 "컴퓨트 자원이 극도로 부족한 시대임에도, 우리는 대규모 RL 스케일업이라는 단 하나의 목표에 수십 명의 엔지니어를 장기간 투입하는 모험을 선택했다"고 밝혔습니다.

결국 핵심은 하드웨어 인프라의 양이 아니라, 한정된 자원 안에서 RL 시스템의 안정성을 확보하고 리워드 해킹을 잡아낸 '집요한 엔지니어링 디테일'에 있었습니다.

독점적 폐쇄형 모델들의 비싼 API 비용에 허덕이던 에이전트 개발사나, 시뮬레이션 환경에서 로봇 제어 모델을 파인튜닝하고 싶었던 엔지니어들에게 이번 샤오미의 소스 공개(MIT 라이선스)는 가뭄의 단비와도 같습니다. 저 역시 이번 주말에는 Hugging Face에 올라온 MiMo-V2.6-Flash 가중치를 내려받아 저희 로봇 시뮬레이션 파이프라인에 이식해 볼 생각입니다. 피지컬 AI의 대중화가 생각보다 훨씬 빠르게 다가오고 있음을 실감하는 요즘이네요.

[연재 2편 안내] 실제 3D 시뮬레이션과 VLA 로봇 제어 실증 분석

MiMo-V2.6의 1조 파라미터 훈련 아키텍처가 실제 로보틱스 시뮬레이션에서 어떻게 작동하는지 궁금하신가요?
Three.js/Blender 3D 공간 인지, F1 드리프트 물리 시뮬레이션, 그리고 하드웨어 안전 필터(Safety Filter/MPC) 구축 실무를 다룬 [2편: 실무 실증] 비싼 상용 API vs 토큰당 10분의 1 가격의 오픈웨이트: 샤오미 MiMo 2.6 Pro가 로보틱스 시뮬레이션을 정복한 비결에서 실증 영상을 함께 확인해 보세요!

참고 자료 (References)

공식 원문: VentureBeat / 'Better than DeepSeek': Xiaomi's MiMo-V2.6-Pro debuts as the top open weights model in the world alongside cheaper V2.6-Flash
기술 레퍼런스: Xiaomi MiMo Hugging Face Repository
커뮤니티 발굴 소스: Reddit r/reinforcementlearning 토론 원문

테슬라 옵티머스도 못 피한 로봇 병목: 엔비디아가 Isaac ROS 5.0과 AI 에이전트로 '제로카피'를 뚫어낸 방법

JJTech — Fri, 25 Sep 2026 07:26:29 +0900

1. GPU는 빠른데 로봇은 왜 느릴까?

현업에서 Physical AI나 자율주행 로봇 아키텍처를 설계하다 보면 항상 마주치는 고질적인 병목이 있습니다. 분명 고성능 GPU를 달아두고 TensorRT 커널 연산 속도도 밀리초(ms) 단위로 끊어놨는데, 정작 전체 ROS 2 그래프를 돌려보면 레이턴시가 튀는 현상이죠. 원인은 명확합니다. GPU에서 연산이 끝난 고용량 이미지나 포인트 클라우드 데이터가 ROS 2 노드 경계를 넘어갈 때, 다시 CPU 메모리(Host)로 복사되고 직렬화(Serialization) 과정을 거치기 때문입니다.

NVIDIA가 최근 ROS 2 Lyrical 버전에 기여(Contribute)하고 NVIDIA Isaac ROS 5.0에 전면 도입한 rosidl::Buffer 추상화 인터페이스와 CUDA 버퍼 백엔드는 바로 이 문제를 정조준하고 있습니다. 요약하자면, 동일한 GPU 내에 상주하는 페이로드를 CPU로 끌어올리지 않고 GPU 메모리 상에서 직접 제로카피(Zero-copy)로 노드 간 주고받을 수 있게 해주는 기술입니다.

하지만 기존에 짜놓은 수많은 레거시 노드들을 이 새로운 인터페이스에 맞게 마이그레이션하는 작업은 생각보다 까다롭습니다. 메모리 할당 방식부터 CUDA 스트림 소유권 관리, 예외 처리까지 꼼꼼히 뜯어봐야 하거든요. NVIDIA는 이를 해결하기 위해 재미있게도 AI 코딩 에이전트를 활용한 워크플로우를 제시했습니다. migrate-node-to-rosidl-buffer라는 특화된 에이전트 스킬을 통해 기존의 Depth Anything V3 (DA3) TensorRT 노드를 어떻게 가속화할 수 있는지, 그 아키텍처와 실무적 관점을 딥다이브해 보겠습니다.

NVIDIA Isaac ROS 5.0 핵심 스펙 요약

핵심 기능: rosidl::Buffer 추상화 및 CUDA 버퍼 백엔드 도입 (ROS 2 Lyrical 표준 지원)

최적화 타겟: 노드 간 GPU-resident 페이로드 교환 시 CPU 직렬화/역직렬화 배제 (Zero-Copy)

지원 RMW: rmw_fastrtps_cpp, rmw_zenoh_cpp

에이전트 스킬: migrate-node-to-rosidl-buffer (AI 기반 코드 감사 및 리팩토링 자동화)

2. `rosidl::Buffer` 아키텍처와 AI 에이전트의 역할

CPU 바운더리를 깨부수는 CUDA 버퍼 백엔드

기존 ROS 2에서 uint8[]과 같은 가변 길이 원시 배열 필드는 C++ 코드로 빌드될 때 std::vector<uint8_t>로 변환되었습니다. 이는 자연스럽게 CPU 메모리 할당을 강제하게 되죠. 반면 ROS 2 Lyrical부터 도입된 rosidl::Buffer<uint8_t>는 내부 저장소 메커니즘을 플러그인 형태로 감싸 안을 수 있는 추상화 레이어 역할을 합니다.

NVIDIA가 기여한 CUDA 버퍼 백엔드는 이 rosidl::Buffer 하단에 CUDA 가상 메모리 관리(VMM, Virtual Memory Management)를 배치합니다. 덕분에 동일한 호스트, 동일한 GPU 장치, 동일한 리눅스 유저라는 조건이 충족되면 ROS 2 미들웨어 수준에서 복사 없이 GPU 주소 포인터만 넘겨주는 진정한 의미의 제로카피가 가능해집니다. 만약 수신 측 노드가 CUDA를 지원하지 않는다면? 프레임워크가 알아서 CPU 백엔드로 폴백(Fallback)해 주니 호환성 걱정도 덜었습니다.

flowchart TD
    A["① 입력 데이터 수집<br/>(sensor_msgs/Image)"] --> B["② CUDA 버퍼 메모리 할당<br/>(cuda_buffer_backend::allocate_buffer)"]
    B --> C["③ TensorRT 추론 실행<br/>(GPU 내에서 직접 Write)"]
    C --> D["④ 제로카피 발행<br/>(pub_depth_image->publish)"]
    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

AI 에이전트 기반의 영리한 마이그레이션 파이프라인

이 마이그레이션을 손으로 직접 하려면 꽤 피곤합니다. 메모리 할당 지점을 모두 찾아서 수정해야 하고, 비동기 처리를 위한 CUDA 스트림 동기화 시점도 맞춰야 하니까요. NVIDIA Nemotron 기반의 AI 에이전트는 migrate-node-to-rosidl-buffer 스킬을 통해 이 프로세스를 정형화했습니다.

에이전트는 단순히 코드를 기계적으로 치환하는 것이 아니라, 다음과 같은 정밀한 시스템 분석을 수행합니다.

의존성 검사: 대상 패키지가 cuda_buffer 및 cuda_buffer_backend를 바라보도록 package.xml과 CMakeLists.txt를 업데이트합니다.
트레이싱 및 감사: 이미지 구독(Subscription)부터 발행(Publication)까지의 데이터 흐름을 추적하여 불필요한 디바이스-호스트 복사(D2H, H2D)가 발생하는 경계를 찾아냅니다.
최소 침습적 리팩토링: 기존 ROS 2 메시지 규격(예: sensor_msgs/msg/Image)은 그대로 유지하면서 내부의 .data 필드만 CUDA 버퍼로 교체하는 정밀한 패치를 적용합니다.

실제 마이그레이션된 코드의 핵심 패치를 보면 시스템 프로그래밍 관점에서 아주 깔끔하게 떨어지는 것을 볼 수 있습니다.

// 1. 구독 옵션에 CUDA 백엔드 허용 명시
rclcpp::SubscriptionOptions options;
options.acceptable_buffer_backends = "cuda";
sub_image_.subscribe(this, image_base_topic, image_transport, rclcpp::SensorDataQoS().get_rmw_qos_profile(), options);

// 2. 출력 메시지 생성 및 CUDA 메모리 직접 할당
auto depth_msg = std::make_unique<sensor_msgs::msg::Image>();
// ... 헤더 및 메타데이터 설정 ...
depth_msg->data = cuda_buffer_backend::allocate_buffer(static_cast<size_t>(depth_msg->step) * depth_msg->height);

// 3. CUDA 스트림에 안전한 핸들 추출 및 추론 실행
const cudaStream_t stream = tensorrt_depth_anything_->getCudaStream();
{
    auto input = cuda_buffer_backend::from_input_buffer(bgr_image_msg->data, stream);
    auto output = cuda_buffer_backend::from_output_buffer(depth_msg->data, stream);

    tensorrt_depth_anything_->doInferenceCuda(
        input.get_ptr(), bgr_image_msg->width, bgr_image_msg->height,
        bgr_image_msg->step, *camera_info_msg,
        reinterpret_cast<float *>(output.get_ptr()), // 별도의 D2D 카피 없이 바로 출력 버퍼에 Write!
        // ... 생략 ...
    );
} // 스코프를 벗어나며 Write 핸들이 릴리스되고 CUDA 이벤트가 기록되어 안전한 발행 상태 보장

pub_depth_image_->publish(std::move(depth_msg));

3. 기존 방식 대비 비교 분석 및 실무 고려사항

이 기술이 주는 이점은 명확하지만, 실제 로봇 필드에 배포하려는 엔지니어 관점에서는 몇 가지 꼼꼼하게 짚고 넘어가야 할 제약 조건과 실무적 과제들이 보입니다.

제로카피의 달콤함 뒤에 숨은 물리적 제약 조건

이 제로카피 메커니즘은 마법이 아닙니다. 내부적으로 CUDA VMM 공유 메모리를 활용하기 때문에 다음과 같은 조건들이 완벽히 맞물려야만 활성화됩니다.

프로세스 배치: 노드들이 동일한 물리적 호스트(Host)와 동일한 GPU 장치(CUDA Device) 위에서 실행되어야 합니다. 멀티 GPU 환경이라면 디바이스 ID 매칭이 필수적입니다.
권한 격리: 리눅스 상에서 동일한 사용자(User) 계정으로 구동되어야 합니다. 도커(Docker) 컨테이너 분할 환경이라면 IPC 설정 및 유저 매핑을 세심하게 조율해야 하죠.
RMW 제약: 현재 공식적으로 지원하는 미들웨어는 rmw_fastrtps_cpp와 rmw_zenoh_cpp로 제한됩니다.

만약 이 조건 중 하나라도 깨지면 시스템은 경고 없이 CPU 폴백 모드로 전환됩니다. 기능적으로는 정상 동작하겠지만, 실시간성이 중요한 제어 루프에서 갑작스러운 CPU 점유율 스파이크와 레이턴시 저하를 유발할 수 있습니다. 그래서 실제 배포 시에는 아래와 같이 구독부에서 백엔드 타입을 명시적으로 검증하는 방어적 코드가 필수적입니다.

// 수신한 메시지가 진짜 CUDA 버퍼를 타고 왔는지 검증하는 테스트 코드 예시
const std::string backend = msg->data.get_backend_type();
if (backend != "cuda") {
    RCLCPP_WARN(get_logger(), "Warning: Zero-copy path failed. Fallback to CPU!");
}

하이브리드 파이프라인에서의 오버헤드 저울질

로봇 시스템의 모든 노드가 GPU를 쓰지는 않습니다. 예를 들어 딥러닝 기반의 인지 노드(예: Depth Anything V3)는 GPU를 쓰지만, 뒤이어 동작하는 로컬 패스 플래너나 비상 정지(Safety) 노드는 여전히 CPU 기반으로 동작하는 경우가 많죠.

이때 GPU 노드에서 발행한 CUDA 버퍼를 CPU 노드가 구독하면, 수신 측의 from_input_buffer() 내부에서 자동으로 CPU로의 암묵적 복사(D2H)와 동기화가 일어납니다. 이 비용은 결국 기존의 명시적 복사와 크게 다르지 않거나, 오히려 추적하기 어려운 오버헤드를 만들 수 있습니다.

따라서 전체 ROS 2 그래프를 먼저 도식화해 보고, "GPU-to-GPU" 구간이 확실히 연속되는 서브 그래프(예: 카메라 입력 -> 전처리 -> AI 추론 -> 시각화/VLA 모델)를 타겟으로 집중 적용하는 전략이 훨씬 효율적입니다.

4. 마치며

NVIDIA Isaac ROS 5.0과 rosidl::Buffer가 제시하는 방향성은 매우 명확합니다. 임바디드 AI(Embodied AI)와 대형 파운데이션 모델(VLA)이 로봇 안으로 들어오면서 다루어야 할 데이터의 크기는 기하급수적으로 커지고 있습니다. 이런 상황에서 소프트웨어 아키텍처 수준의 병목을 방치한 채 하드웨어 스펙만 올리는 것은 한계가 있죠.

이번 기술의 진정한 가치는 표준 ROS 2 메시지 인터페이스를 전혀 해치지 않으면서도 시스템 수준에서 초고속 데이터 전송을 구현했다는 점에 있습니다. 게다가 복잡한 리팩토링 과정을 AI 에이전트에게 맡겨 휴먼 에러를 줄이고 개발 주기를 단축한 시도는 앞으로 로봇 소프트웨어 엔지니어링이 나아갈 방향을 잘 보여준다고 생각합니다.

특히 차세대 로봇 컴퓨팅 플랫폼인 NVIDIA Jetson AGX Thor 환경에서 대규모 멀티 카메라 인지 파이프라인을 구축해야 하는 엔지니어라면, 이 CUDA 버퍼 백엔드와 AI 에이전트 워크플로우는 선택이 아닌 필수 무기가 될 것 같네요. 지금 바로 여러분의 레거시 노드 중에서 가장 무거운 이미지 처리 파이프라인부터 이 에이전트 스킬을 먹여보시는 건 어떨까요?

참고 자료 (References)

공식 원문: NVIDIA Technical Blog - Accelerating a ROS 2 Node with an AI Agent and NVIDIA Isaac ROS
기술 레퍼런스: ROS 2 Lyrical rosidl::Buffer and CUDA buffer backend GitHub

엔비디아가 옴니버스 NuRec으로 푼 자율주행 최대 난제: 신형 차량 나올 때마다 데이터 다시 안 찍어도 되는 이유

JJTech — Thu, 24 Sep 2026 20:33:55 +0900

1. 데이터 수집의 악순환을 끊다: NuRec의 등장 배경

현업에서 자율주행(AV)이나 로봇 인지(Perception) 모델을 개발하다 보면 꼭 마주치는 골치 아픈 문제가 하나 있습니다. 바로 '하드웨어 변경에 따른 인지 성능의 붕괴'인데요.

열심히 기존 SUV 차량으로 수백만 킬로미터를 달리며 데이터를 모으고 라벨링해서 인지 모델을 완성해 놓았더니, 사업부에서 "이번엔 세단 모델에 탑재할 거니까 센서 위치 좀 바꾸고 렌즈 화각도 변경해서 다시 학습시켜 주세요"라고 요청하는 상황입니다.

카메라 높이가 단 몇십 센티미터만 낮아져도 신호등의 위치가 프레임 상단에서 벗어나고, 보닛에 가려지는 사각지대(Occlusion)가 완전히 달라집니다. 이 사소한 변화 때문에 기존에 공들여 쌓아 올린 데이터셋의 가치는 급락하고, 또다시 수십억 원의 비용과 수개월의 시간을 들여 실도로 데이터를 수집하고 수작업 라벨링을 시작해야 하죠.

엔비디아가 이번에 공개한 NVIDIA Omniverse NuRec은 이 고질적인 '센서 마이그레이션 병목'을 Real-to-Sim-to-Real(R2S2R) 기술로 정면 돌파하려는 시도입니다. 실도로에서 수집한 기존 데이터를 바탕으로 3D 공간을 가상화(Reconstruction)한 뒤, 새로운 차량(Target Carline)의 센서 규격과 위치에 맞춰 가상 카메라 뷰를 렌더링해 주는 기술이죠.

쉽게 말해, "SUV로 찍은 블랙박스 영상을 세단 눈높이의 영상으로 완벽하게 리렌더링해서 학습 데이터로 재활용하겠다"는 선언입니다.

NVIDIA NuRec 핵심 아키텍처 및 스펙 요약

핵심 기술: 3D 가우시안 스플래팅(3D Gaussian Splatting, 3DGS) 기반 실시간 노벨 뷰 합성(Novel-view Synthesis)
제공 데이터셋 (Hugging Face): Physical AI NuRec Dataset (1,500개 이상의 뉴럴 재구성 씬, 각 20초 분량, 6개 카메라 뷰 제공)
보정 파이프라인: NVIDIA Harmonizer (확산 모델 기반 시계열 일관성 및 아티팩트 보정 모델)
메타데이터 포맷: NCore V4 (카메라 파라미터, 차량 모션, Cuboid 3D 박스 통합 포맷)

2. 아키텍처 및 핵심 메커니즘 딥다이브

NuRec이 기존의 단순 그래픽스 시뮬레이션과 차별화되는 지점은, 가상의 3D 에셋을 처음부터 만드는 것이 아니라 실제 수집된 주행 데이터(Sensor Log)를 소스로 사용한다는 점입니다. 이 파이프라인이 어떻게 흘러가는지 아키텍처 구조를 통해 살펴보겠습니다.

flowchart TD
    A["① 실도로 주행 데이터 수집<br/>(카메라 MP4, Calibration, Egomotion)"] --> B["② NCore 포맷 변환 및<br/>Auxiliary 데이터 생성 (Depth, Seg)"]
    B --> C["③ 3D Gaussian Splatting<br/>기반 NuRec 3D 씬 재구성"]
    C --> D["④ 타겟 차량 센서 리그(Rig)<br/>가상 매핑 및 가상 뷰 렌더링"]
    D --> E["⑤ NVIDIA Harmonizer<br/>(일관성 보정 및 아티팩트 제거)"]
    E --> F["⑥ 타겟 차량 특화<br/>인지 모델(Perception) 학습"]
    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

3D 가우시안 스플래팅(3DGS)과 노벨 뷰 합성

기존의 NeRF(Neural Radiance Fields)는 렌더링 속도가 너무 느려 대규모 데이터셋 생성에 한계가 명확했습니다. 반면 NuRec은 3D 가우시안 스플래팅(3DGS)을 채택하여 실시간성에 가까운 속도로 공간을 재구성합니다.

단순히 시각적 복원만 하는 것이 아니라, 기존 데이터에 포함되어 있던 3D bounding box(Cuboid), 차선 정보, 주변 매핑 데이터를 3D 공간 상에 고스란히 보존합니다. 덕분에 타겟 차량의 카메라 뷰로 렌더링을 다시 하더라도, 자동으로 라벨 정보(Annotations)가 왜곡 없이 새로운 카메라 좌표계로 투영(Projection)됩니다. 수작업 라벨링 비용이 '0'에 수렴하게 되는 마법이 여기서 일어납니다.

신경망 렌더링의 구원투수: NVIDIA Harmonizer

하지만 뉴럴 렌더링(Neural Rendering)에는 치명적인 약점이 있습니다. 바로 카메라 프레임 간의 미세한 지터링(Flickering)이나 하늘 영역의 노이즈, 그리고 동적 객체(Dynamic Object) 주변의 '고스트 현상(Ghosting Artifacts)'입니다. 이를 그대로 인지 모델 학습에 사용하면 모델이 가상의 노이즈 패턴을 학습해 버리는 치명적인 부작용이 생깁니다.

이를 해결하기 위해 엔비디아는 Diffusion 기반의 NVIDIA Harmonizer를 후처리 파이프라인에 배치했습니다. 이 모델은 연속된 프레임 간의 시계열적 일관성(Temporal Consistency)을 유지하면서 렌더링 아티팩트를 자연스럽게 다듬어 줍니다.

실제 렌더링 결과물을 보면, 뭉개졌던 하늘 경계선이나 유리창의 반사광이 Harmonizer를 거치며 실제 카메라로 찍은 듯한 자연스러운 텍스처로 보정되는 것을 확인할 수 있습니다.

3. 기존 방식 대비 비교 분석 및 실무적 한계

이 기술이 장점만 가득해 보이지만, 현업 엔지니어의 눈으로 보면 냉정하게 짚고 넘어가야 할 현실적인 한계와 고려사항들이 보입니다. 기존의 가상 시뮬레이터(CARLA, Omniverse Isaac Sim 등) 및 실도로 수집 방식과 비교해 보겠습니다.

비교 항목	실도로 데이터 직접 수집	기존 3D 시뮬레이터 (Synthetic)	NVIDIA NuRec (R2S2R)
구축 비용 및 시간	매우 높음 (수개월, 수억~수십억 원)	낮음 (가상 환경 구축 후 즉시 생성)	보통 (기존 데이터 재활용, 변환 연산 필요)
데이터 리얼리티	최고 (실제 물리 세계의 빛과 노이즈)	낮음 (Sim2Real 갭 존재, 다소 이질적)	매우 높음 (실제 주행 기반 뉴럴 복원)
센서 마이그레이션 유연성	없음 (차량 바뀔 때마다 재수집)	매우 높음 (클릭 몇 번으로 센서 변경)	높음 (타겟 리그에 맞춰 재렌더링)
라벨링 자동화	수작업 또는 AI 오토라벨링 필요	100% 자동 생성 (Ground Truth)	100% 자동 투영 (기존 라벨 재활용)

현업에서 마주할 진짜 한계점: '가려짐(Occlusion)의 복원'

NuRec이 제아무리 3DGS로 공간을 잘 메워준다 해도, "기존 소스 차량의 카메라가 한 번도 보지 못한 영역"은 물리적으로 복원할 수 없습니다.

예를 들어, 소스 차량인 SUV는 루프 쪽에 카메라가 있어 앞차 너머의 도로 상황을 일부 볼 수 있었다고 가정해 봅시다. 그런데 타겟 차량인 저지상고 스포츠카의 범퍼 위치로 카메라를 내리면, 앞차에 가려진 영역이 훨씬 넓어집니다. 이 경우, 존재하지 않는 사각지대의 비주얼을 NuRec이 생성해 내야 하는데, 이는 결국 '상상(Generative Inpainting)'의 영역으로 넘어가게 됩니다.

이때 발생하는 인페인팅 왜곡이나 정보 누락이 인지 모델의 안전성(Safety)에 어떤 영향을 미칠지는 엔지니어가 반드시 검증해야 할 리스크 요인입니다.

또한, Harmonizer의 연산 병목도 무시할 수 없습니다. Diffusion 기반의 후처리를 수천 프레임에 달하는 고해상도 영상 데이터셋 전체에 적용하려면 엄청난 양의 GPU 컴퓨팅 파워가 필요합니다. 배포 파이프라인의 인프라 비용과 실도로 수집 비용 간의 손익분기점(ROI)을 철저히 계산해 보아야 하는 이유입니다.

4. 마치며

엔비디아 Omniverse NuRec은 그동안 자율주행 업계의 고질적인 병목이었던 '차종 변경에 따른 데이터 재수집' 문제를 물리적으로 해결 가능한 수준까지 끌어올린 획기적인 도구임이 틀림없습니다.

특히 3DGS와 Diffusion 기반 Harmonizer의 결합은, 그래픽스 엔진으로 가상 세계를 정교하게 빚어내던 기존 방식에서 벗어나 "실제 세계의 데이터를 뉴럴 네트워크로 압축하고 재구성하여 재활용하는" Embodied AI 시대의 새로운 데이터 파이프라인 패러다임을 보여줍니다.

물론 사각지대 복원의 한계나 연산 비용 같은 실무적인 허들이 존재하지만, 차량 라인업이 다양해지고 하드웨어 스펙이 빠르게 변화하는 양산형 자율주행 및 로보틱스 분야에서 NuRec은 개발 기간을 수개월 이상 단축해 줄 강력한 무기가 될 것입니다. 이제 데이터 수집 트럭을 도로로 내보내기 전에, 하드 디스크에 잠자고 있는 기존 주행 로그를 깨워 NuRec 컨테이너에 먼저 올려보는 것이 표준 워크플로우가 될 날이 머지않아 보입니다.

참고 자료 (References)

공식 원문: NVIDIA Technical Blog / Scale AV Perception Across Vehicle Platforms with NVIDIA Omniverse NuRec
기술 레퍼런스: NVIDIA NuRec Skills GitHub Repository
데이터셋 소스: Hugging Face - Physical AI NuRec Dataset

테슬라 옵티머스 쫓는 UBTECH의 역발상: 세계 최초 '1만 대 양산' 휴머노이드 스마트 팩토리가 바꿀 로봇 생태계 판도

JJTech — Thu, 24 Sep 2026 06:59:18 +0900

1. UBTECH의 1만 대 양산 선언과 Walker S2 스마트 팩토리

요즘 휴머노이드 씬을 보면 다들 '뇌(VLA, LLM)'나 '신체(Hardware)'의 스펙 경쟁에만 매몰되어 있는 것 같습니다. 하지만 현업에서 양산을 고민하는 엔지니어 입장에서는 늘 마음 한구석이 텁텁했습니다. "그래서 이거 진짜 대량 생산은 어떻게 할 건데?"라는 현실적인 벽 때문이었죠. 아무리 뛰어난 로봇이라도 연구실에서 한 땀 한 땀 수작업으로 조립해 한 달에 서너 대 만드는 수준에 머문다면 대중화는 요원한 일이니까요.

이런 상황에서 중국의 대표적인 휴머노이드 기업 UBTECH Robotics가 던진 승부수는 꽤나 충격적입니다. 단 9개월 만에 연간 1,000대 수준의 생산 캐파를 10,000대 규모로 끌어올리며, 세계 최초로 '1만 대 스케일'의 휴머노이드 스마트 팩토리를 본격 가동하기 시작한 겁니다. 라인에서 10분에 1대씩 완성된 휴머노이드 로봇이 걸어 나오는 광경은, 이들이 단순한 기술 데모를 넘어 '제조업으로서의 로보틱스' 단계에 진입했음을 명확히 보여줍니다.

특히 흥미로운 점은 '로봇이 로봇을 만드는(Robots Building Robots)' 자동화 공정을 전면에 내세웠다는 것입니다. 자사의 플래그십 모델인 UBTECH Walker S2가 조립 라인에 직접 투입되어 동료 로봇의 부품을 장착하고 검수하는 모습은, 공장 자동화의 최종 진화 형태를 시각적으로 증명하고 있습니다.

[00:45] 로봇이 로봇을 조립하는 자동화 셀
(설명: UBTECH의 Walker S2 로봇들이 정밀 로봇 팔과 협업하여 부품을 체결하고 조립 라인의 서브 태스크를 수행하는 자동화 공정입니다.)

2. 현업 엔지니어가 분석한 '로봇 제조 자동화'의 아키텍처

휴머노이드 로봇은 일반 가전제품이나 자동차와는 비교가 안 될 정도로 복잡한 자유도(DoF)를 가집니다. 수십 개의 액추에이터와 센서, 와이어링 하네스가 좁은 프레임 안에 빽빽하게 들어가기 때문에 자동화 라인을 까다롭게 설계해야 하는데요. UBTECH이 이번 스마트 팩토리에서 구현한 핵심 아키텍처를 엔지니어링 관점에서 쪼개어 분석해 봤습니다.

엔드투엔드 정밀 캘리브레이션과 테스트 자동화

로봇 조립에서 가장 까다로운 부분은 기구학적 오차(Kinematic Offset)를 잡아내는 일입니다. 아무리 정밀하게 설계해도 물리적 조립 과정에서 미세한 공차가 발생하기 마련이고, 이는 보행 제어 알고리즘의 발산으로 이어집니다. UBTECH은 조립이 완료된 로봇을 별도의 테스트 베드에 올려 센서 오프셋과 관절 캘리브레이션을 자동으로 수행하는 파이프라인을 구축했습니다. 사람이 일일이 계측기를 대고 튜닝하던 작업을 자동화 캘리브레이션 소프트웨어 패키지로 대체한 것이 생산 속도를 10분당 1대로 단축한 일등 공신이라 봅니다.

모듈러 하드웨어 아키텍처와 분산 제어

Walker S2의 설계를 뜯어보면 철저하게 모듈화(Modularity)를 염두에 두었음을 알 수 있습니다. 팔, 다리, 몸체, 머리 부분이 각각 독립된 서브시스템으로 조립 및 테스트를 마친 뒤, 메인 라인에서 최종 결합되는 방식입니다. 각 모듈은 단일 버스(CAN FD 또는 EtherCAT 기반으로 추정)를 통해 메인 제어기와 통신하므로, 복잡한 배선 작업을 획기적으로 줄였습니다. 이 모듈러 아키텍처 덕분에 조립 로봇(설비)이 부품을 집어 올바른 위치에 끼워 넣는 단순 피팅(Fitting) 작업만으로도 조립이 가능해진 것입니다.

flowchart TD
    A["① 무인 운반차(AGV/AMR) 자율 이송<br/>(서브 프레임 및 관절 모듈 공급)"] --> B["② 산업용 로봇 팔 협업 조립<br/>(프레임 안착, 정밀 피팅 및 자동 볼팅)"]
    B --> C["③ 전장 및 케이블링 체결 라인<br/>(분산 버스 통신선 결합)"]
    C --> D["④ 라인 종단 검사 및 거치 스테이션<br/>(10분당 1대 출고 택트 타임 달성)"]
    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

3. 기존 방식 대비 비교 분석 및 실무 고려사항

테슬라(Tesla)가 옵티머스(Optimus) 기가팩토리 양산 계획을 계속해서 조율하고 있는 시점에, UBTECH이 먼저 1만 대 규모의 공장을 실증해 보인 것은 시사하는 바가 큽니다. 하지만 현업 엔지니어로서 냉정하게 짚고 넘어가야 할 실무적 한계와 극복 과제들도 분명히 존재합니다.

하드웨어 공차 누적과 액추에이터 균일성 확보의 한계

가장 우려되는 부분은 '공차 누적(Tolerance Stack-up)'입니다. 1만 대라는 대량 생산 체제에서는 부품 협력사로부터 들어오는 하모닉 드라이브(정밀 감속기)나 모터 코어의 미세한 성능 편차가 발생할 수밖에 없습니다. 시뮬레이션(Sim2Real) 단계에서 완벽하게 튜닝된 보행 파라미터가 실제 양산된 9,000번째 로봇에서는 액추에이터의 미세한 마찰력 차이 때문에 제대로 작동하지 않을 수 있죠. UBTECH이 이 'Manufacturing2Real'의 갭을 소프트웨어적으로 얼마나 유연하게 극복(Adaptive Control 적용 여부 등)했는지가 장기적인 품질 유지의 핵심 변수가 될 것입니다.

공급망(Supply Chain)과 조립 공정의 병목 현상

휴머노이드 양산은 단순히 공장 내부의 로봇 팔을 빠르게 돌린다고 해결되지 않습니다. 수백 개의 커스텀 베어링, 고밀도 토크 모터, 센서 칩셋의 공급망이 10분당 1대라는 속도를 뒤받쳐주어야 합니다. UBTECH은 선전(Shenzhen)을 중심으로 한 중국 남부의 막강한 하드웨어 공급망 생태계를 등에 업고 이 병목을 뚫어낸 것으로 보입니다. 이는 타국가나 경쟁사들이 단기간에 쉽게 모방하기 힘든 강력한 진입장벽입니다.

UBTECH 스마트 팩토리 대량 생산 라인 스케치
(설명: 세계 최초 10,000대 규모 휴머노이드 로봇 양산 공장의 자동화 생산 라인과 워커(Walker) S2 로봇들의 조립 현장을 짧게 보여주는 스케치 영상입니다.)

4. 마치며

UBTECH의 이번 10,000대 규모 스마트 팩토리 가동은 휴머노이드 로봇 산업의 패러다임이 '연구 및 프로토타입 개발'에서 '본격적인 제조 및 양산 경쟁'으로 완전히 전환되었음을 알리는 신호탄입니다.

로봇이 로봇을 만드는 공정은 단순히 시각적인 퍼포먼스에 그치지 않고, 생산 단가를 낮추어 대당 가격을 극적으로 떨어뜨릴 수 있는 유일한 열쇠입니다. 물론 대량 생산된 로봇들이 실제 산업 현장(자동차 조립 공장, 물류 창고 등)에 투입되어 얼마나 높은 신뢰성(MTBF, 평균 고장 간격)을 보여줄지는 조금 더 지켜봐야 합니다. 하지만 적어도 "대량 생산이 불가능하다"던 회의론자들의 입을 다물게 하기에는 충분한 실증 결과물이라고 생각합니다. 이제 우리 엔지니어들도 단순 알고리즘 개발을 넘어, '양산성(Design for Manufacturability, DFM)'을 뼈대에 새기고 설계해야 하는 시대가 진짜 눈앞에 다가왔네요.

참고 자료 및 공식 영상 (References)

영상 출처: UBTECH Robotics 공식 유튜브 채널 - Robots Building Robots: World's First 10,000-Scale Humanoid Robot Smart Factory Goes Mass Production
기술 레퍼런스: UBTECH Walker S2 공식 상세 스펙 및 제품 소개

우버부터 웨이모까지, 글로벌 로보택시 기업들이 NVIDIA Blackwell과 Thor를 선택한 이유

JJTech — Wed, 23 Sep 2026 21:23:18 +0900

1. 글로벌 로보택시 생태계를 장악한 NVIDIA의 '3-Computer' 전략

최근 자율주행 업계, 특히 로보택시 씬을 보면 하드웨어와 소프트웨어의 경계가 완전히 무너지고 있다는 느낌을 강하게 받습니다. 단순히 "차량용 칩셋을 잘 만든다"는 수준을 넘어, 개발부터 검증, 그리고 실차 배포에 이르는 전 과정을 하나의 거대한 컴퓨팅 루프로 묶어버리는 플랫폼이 시장을 지배하고 있죠. NVIDIA가 제시한 '3-Computer' 아키텍처가 대표적인 예입니다.

NVIDIA의 발표를 보면, 우버(Uber)를 필두로 메르세데스-벤츠(Mercedes-Benz), 웨이모(Waymo), 주크스(Zoox), 바이디(WeRide) 등 글로벌 로보택시 리더들이 예외 없이 이들의 에코시스템을 채택하고 있습니다. 2035년까지 400억 달러 규모로 성장할 이 시장에서, NVIDIA는 단순한 반도체 공급업체가 아닌 '자율주행의 인프라 그 자체'가 되려는 야망을 노골적으로 드러내고 있네요.

핵심 아키텍처 요약: NVIDIA의 '3-Computer' 풀스택 루프

① 학습 (Training): NVIDIA DGX 클라우드 인프라 & 차세대 VLA 파운데이션 모델 Alpamayo 2 Super

② 시뮬레이션 및 검증 (Simulation & Validation): 디지털 트윈 기반 물리 AI 월드 모델 Cosmos & Omniverse NuRec (수만 가지 코너케이스 합성)

③ 차량 탑재형 컴퓨터 (In-Vehicle Compute): 블랙웰(Blackwell) 아키텍처 기반 초고성능 중앙 집중 SoC DRIVE AGX Thor (최대 1,000 TFLOPS) 및 Hyperion 10 레퍼런스 아키텍처

이 세 가지 축이 어떻게 유기적으로 맞물려 실제 양산형 자율주행 시스템의 완성도를 끌어올리는지, 엔지니어의 관점에서 조금 더 딥다이브해 보겠습니다.

2. VLA 모델과 인-카 컴퓨팅: 현업 엔지니어가 보는 기술적 핵심

메타 액션(Meta Action)과 생각의 사슬(Chain-of-Thought)이 만드는 차이

자율주행을 개발할 때 우리를 가장 괴롭히는 것은 예측 불가능한 '롱테일(Long-tail) 시나리오'입니다. 도로 위에 갑자기 나타난 기괴한 형태의 장애물이나, 공사 현장에서 수신호를 보내는 인부의 모호한 동작 같은 것들이죠.

NVIDIA가 이번에 강조한 NVIDIA Alpamayo VLA 모델은 이 문제를 '추론'의 영역으로 해결하려 합니다. 단순히 센서 데이터를 입력받아 조향각과 가속도를 출력하는 기존의 End-to-End 방식과 달리, 상황을 쪼개어 분석하고 판단 근거를 단계별로 도출하는 '생각의 사슬(Chain-of-Thought)' 방식을 도입한 것인데요.

실제 평가 데이터를 보면, 이 메타 액션과 추론 데이터를 학습에 추가했을 때 궤적 예측 오차(Average Displacement Error)가 2.08m에서 1.18m로 무려 43%나 감소했다고 합니다. 이 수치는 실무적으로 엄청난 의미를 가집니다. 차선 하나 너비가 보통 3m 내외인 점을 감안하면, 오차가 1m 이하로 줄어든다는 것은 가상 제어기가 차선을 이탈하거나 인접 차량과 충돌할 확률을 극적으로 낮췄다는 뜻이니까요.

NVIDIA Cosmos와 월드 파운데이션 모델의 파괴력

실도로 주행만으로는 롱테일 시나리오를 다 채울 수 없습니다. 그래서 시뮬레이션이 중요한데, 기존의 시뮬레이터는 그래픽 아티스트들이 가상 환경을 일일이 모델링해야 해서 비용과 시간의 한계가 명확했습니다.

NVIDIA Cosmos는 센서 데이터를 바탕으로 물리 법칙이 적용된 현실적인 변형 시나리오를 스스로 '생성'해 냅니다. 비가 쏟아지는 밤거리에 갑자기 뛰어드는 보행자, 역주행하는 킥보드 같은 극단적인 코너 케이스를 수천, 수만 가지 버전으로 자동 생성하여 모델을 테스트하는 것이죠.

이 데이터 파이프라인이 어떻게 선순환 구조를 그리는지 아래 흐름도를 통해 살펴보겠습니다.

flowchart TD
    A["① 실도로 롱테일 데이터 수집<br/>(Fleet Data)"] --> B["② Omniverse NuRec 기반<br/>실제 시나리오 재구성"]
    B --> C["③ Cosmos 월드 모델 활용<br/>수만 가지 변형 시나리오 생성"]
    C --> D["④ AlpaSim 가상 환경에서<br/>VLA 모델 Closed-loop 검증"]
    D --> E["⑤ 검증 완료된 모델을<br/>DRIVE AGX Thor에 배포"]
    E --> A

    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

이러한 폐루프(Closed-loop) 검증 아키텍처가 구축되어야만, 비로소 OTA(Over-The-Air)를 통해 매주 고도화된 소프트웨어를 차량에 안전하게 배포할 수 있는 진정한 SDV(소프트웨어 정의 차량)가 완성됩니다.

3. 기존 방식 대비 비교 분석 및 실무 고려사항

그렇다면 우리가 기존에 사용하던 딥러닝 기반 End-to-End 모델이나 규칙 기반(Rule-based) 제어 아키텍처와 비교했을 때, NVIDIA의 새로운 풀스택은 어떤 강점과 현실적인 한계를 가지고 있을까요?

비교 항목	규칙 기반 시스템 (전통적 방식)	일반 End-to-End DL 모델	NVIDIA VLA (Alpamayo) 기반 풀스택
롱테일 대응력	매우 낮음 (예외 규칙을 일일이 하드코딩해야 함)	보통 (학습 데이터 외 상황에서 블랙박스 문제 발생)	매우 높음 (상황 추론 및 메타 액션 판단 가능)
설명 가능성 (Explainability)	완벽함 (코드를 보면 판단 근거 확인 가능)	불가능에 가깝음 (신경망 내부를 알 수 없음)	우수함 (Chain-of-Thought를 통한 판단 단계 시각화)
요구 컴퓨팅 파워	매우 낮음 (가벼운 MCU 수준에서도 구동 가능)	보통 (일반적인 차량용 SoC 수준)	극도로 높음 (Dual DRIVE AGX Thor 등 하이엔드 SoC 필수)
안전성 인증 (Safety)	용이함 (ISO 26262 준수 및 정적 검증 가능)	매우 어려움 (결과값의 안전성 보증 불가)	보통 (NVIDIA Halos OS 및 클라우드-차량 연계 검증 필요)

실무 엔지니어로서 고민해봐야 할 지점들

이 아키텍처가 장점만 있는 것은 아닙니다. 실제 양산 프로젝트를 진행하는 엔지니어 입장에서는 몇 가지 뼈아픈 현실적 제약이 눈에 밟힙니다.

첫째는 전력 소비와 열관리(Thermal Management)입니다. Blackwell 아키텍처를 기반으로 한 Dual DRIVE AGX Thor는 엄청난 연산 속도(TFLOPS)를 자랑하지만, 그만큼 전력 소모량도 상당합니다. 배터리 효율이 극도로 중요한 전기차(EV) 기반 로보택시 플랫폼에서, 자율주행 컴퓨터가 소모하는 전력을 어떻게 최적화하고 수냉식 쿨링 시스템을 어떻게 컴팩트하게 설계할 것인가는 패키징 엔지니어들의 거대한 숙제입니다.

둘째는 실시간성(Real-time latency) 보장입니다. VLA 같은 대형 멀티모달 모델은 추론 속도가 상대적으로 느립니다. 시속 100km로 달리는 고속도로에서 10ms의 지연 시간은 차량이 약 28cm를 더 나아간다는 뜻입니다. 제어 명령의 데드라인을 맞추기 위해, 초고성능 인공지능 모델의 크기를 엣지 디바이스에 맞게 경량화(Distillation)하면서도 추론 정확도를 잃지 않는 고도의 모델 압축 기술이 필수적으로 수반되어야 합니다.

4. 마치며

NVIDIA가 이번에 공개한 로보택시 기술 생태계는 단순히 "우리가 더 빠른 칩을 만들었다"는 선언이 아닙니다. 자율주행의 고도화를 가로막던 최대 난제인 '롱테일 시나리오'를 대규모 물리 AI 데이터 생성(Cosmos)과 추론형 인공지능(Alpamayo), 그리고 이를 차 안에서 실시간으로 돌릴 수 있는 블랙웰 기반 하드웨어(DRIVE AGX Thor)의 삼각편대로 정면 돌파하겠다는 의지입니다.

현업에서 자율주행 아키텍처를 고민하는 엔지니어로서, 이제는 단순히 자체 알고리즘을 튜닝하는 데 머물러서는 안 된다는 위기감이 듭니다. NVIDIA가 깔아놓은 이 강력한 인프라와 툴체인을 우리 시스템에 어떻게 영리하게 이식하고, 그 위에서 우리만의 독점적인 도메인 지식(Domain Knowledge)을 어떻게 차별화 포인트로 녹여낼 것인가가 앞으로의 생존을 결정짓는 핵심 열쇠가 될 것입니다.

참고 자료 (References)

공식 원문: How the World’s Robotaxi Leaders Are Building With NVIDIA Technologies | NVIDIA Blog
관련 기술 아티클: NVIDIA Alpamayo 2 Super, Frontier Open Model for Robotaxis | NVIDIA Blog

테슬라와는 왜 다를까? 모빌아이 수퍼비전(SuperVision™)의 하이브리드 아키텍처와 B2B 영상의 노림수

JJTech — Wed, 23 Sep 2026 08:07:51 +0900

1. Mobileye SuperVision™ 미국 중부 실증의 핵심 요약

자율주행 업계에서 '카메라 온리(Vision-Only)' 솔루션이라고 하면 흔히 테슬라(Tesla)를 가장 먼저 떠올리시곤 합니다. 하지만 전통적인 ADAS(첨단 운전자 보조 시스템)의 최강자인 모빌아이(Mobileye) 역시 수년 전부터 수퍼비전(Mobileye SuperVision™)이라는 브랜드로 고성능 L2++ 카메라 기반 시스템을 시장에 선보여 왔습니다.

이번에 모빌아이가 공개한 실증 영상은 미국 중부의 덴버(Denver)에서 출발해 캔자스시티(Kansas City), 세인트루이스(St. Louis), 시카고(Chicago)를 거쳐 디트로이트(Detroit)에 이르는 대장정을 담고 있습니다.

단순히 날씨 좋은 캘리포니아 도로를 달리는 것이 아닙니다. 트램 선로가 얽혀 있는 복잡한 도심 교차로, 폭우로 인해 전방 시야가 극도로 제한된 고속도로, 가로등이 없는 야간 국도, 그리고 고층 빌딩 숲으로 인해 GPS 음영이 심한 시카고 도심까지 자율주행 엔지니어들이 가장 까다로워하는 '롱테일(Long-tail) 시나리오'를 정면으로 돌파하는 모습을 보여주고 있네요.

이 시스템의 하드웨어 핵심은 11개의 카메라로 구성된 360도 인지 네트워크와 모빌아이의 최신 차세대 자율주행 SoC인 EyeQ™6H (High) 칩셋입니다. 라이다(LiDAR) 없이 오직 카메라 정보와 모빌아이 고유의 크라우드소싱 맵인 REM(Road Experience Management™)을 결합해 고정밀 위치 추정과 경로 계획을 수행하는 것이 특징입니다.

[01:19] 캔자스시티 도심 트램 선로 및 좁은 주택가 실증 장면
(설명: 노면에 복잡하게 얽힌 트램 선로와 불법 주차된 차량들 사이를 카메라 인지만으로 부드럽게 감속 및 회피하는 구간입니다.)

2. 현업의 시각에서 본 아키텍처의 비밀

현업에서 자율주행 소프트웨어를 설계하는 엔지니어 관점에서 이 영상을 보면, 모빌아이가 테슬라와는 완전히 다른 철학으로 카메라 온리 시스템을 풀어나가고 있음을 알 수 있습니다. 그 핵심 아키텍처의 비밀은 크게 세 가지로 요약됩니다.

flowchart TD
    A["① 11개 서라운드 카메라 <br/>실시간 비디오 스트림 입력"] --> B["② EyeQ6H SoC 기반<br/>3D 객체 및 차선 인지"]
    B --> C["③ REM (Roadbook)<br/>클라우드 맵 데이터 정합"]
    C --> D["④ RSS (안전 보장 모델)<br/>의사결정 및 궤적 생성"]
    D --> E["⑤ 차량 섀시 제어<br/>(조향 및 가감속 실행)"]

    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

REM(Road Experience Management)을 통한 '가벼운 맵'의 힘

많은 이들이 라이다가 없으면 고정밀 지도(HD Map)를 쓸 수 없다고 생각하지만, 모빌아이는 전 세계에 퍼져 있는 수백만 대의 모빌아이 칩 탑재 차량들로부터 도로의 기하학적 특징(차선, 표지판, 신호등 위치 등)을 크라우드소싱으로 수집해 로드북(Roadbook™)이라는 초경량 맵을 실시간 갱신합니다.

시카고의 복잡한 이중 구조 도로(Lower Wacker Drive 등)나 터널 진입 시 GPS가 끊기는 상황에서도 차량이 차선을 잃지 않고 안정적으로 주행할 수 있는 비결이 바로 이 REM 기술 덕분입니다. 단순 센서 인지에만 의존하는 퓨어 End-to-End 모델의 한계를 맵 데이터 정합으로 보완하는 훌륭한 하이브리드 설계 방식이죠.

RSS(Responsibility-Sensitive Safety) 안전 모델의 개입

모빌아이 아키텍처의 또 다른 핵심은 의사결정 단계에 수학적으로 정의된 안전 레이어인 RSS를 강제한다는 점입니다. 딥러닝 기반의 인지 모델이 간혹 롱테일 상황에서 엉뚱한 판단을 내리더라도, RSS 레이어에서 "전방 차량과의 최소 안전거리가 확보되지 않았음", "끼어들기 시 물리적 충돌 영역에 진입함"과 같은 규칙 기반(Rule-based)의 물리 법칙을 적용해 제어 명령을 필터링합니다.

영상을 보면 폭우 속에서 대형 트럭(HMM 컨테이너)이 엄청난 물보라를 일으키며 시야를 가리는 순간(02:20 구간)이 나오는데, 시스템이 당황하지 않고 부드럽게 감속하며 안전거리를 유지하는 디시전 메이킹(Decision Making)은 RSS 모델의 안정성을 잘 보여주는 대목입니다.

[02:20] 세인트루이스 고속도로 폭우 및 대형 트럭 물보라 대응 장면
(설명: 폭우로 전방 시야가 차단되고 옆 차선 대형 트럭이 물보라를 뿜어내는 극한의 상황에서 센서 노이즈를 극복하고 안전거리를 확보하는 실증 구간입니다.)

3. 전통적 E2E 모델과의 실무적인 차이점

최근 자율주행 트렌드는 인지부터 제어까지 하나의 거대한 신경망으로 처리하는 '순수 End-to-End(E2E) AI'로 흘러가고 있습니다. 테슬라의 FSD V12가 대표적이죠. 하지만 모빌아이 수퍼비전은 인지 단계에는 딥러닝을 적극 활용하되, 판단과 제어 단계에는 철저히 모듈화되고 검증 가능한(Explainable) 아키텍처를 고수하고 있습니다.

이 두 방식의 실무적인 장단점을 표로 비교해 보았습니다.

비교 항목	모빌아이 수퍼비전 (하이브리드)	순수 End-to-End (테슬라 FSD 스타일)
시스템 아키텍처	인지(AI) + 매핑(REM) + 판단/제어(RSS 수학 모델)	입력(카메라)부터 출력(제어값)까지 단일 신경망
설명 가용성 (Explainability)	매우 높음 (실패 시 어떤 모듈, 어떤 RSS 규칙이 작동했는지 추적 가능)	매우 낮음 (신경망 내부의 가중치 변화를 인간이 직관적으로 이해하기 어려움)
지도(Map) 의존도	REM 로드북 필수 (경량 데이터로 실시간 스트리밍)	지도 의존도 낮음 (실시간 센서 인지에 극도로 의존)
안전성 검증 (Validation)	수학적 안전 모델(RSS)로 정량적 검증 및 인증 용이	수억 마일의 실주행 시뮬레이션을 통한 통계적 검증만 가능
전력 소모 및 하드웨어 요구량	상대적으로 저전력 (EyeQ6H SoC만으로 고효율 처리 가능)	고성능 AI 추론 칩셋 및 대규모 전력 소모 필요

실무 엔지니어 입장에서 모빌아이 방식이 가진 가장 큰 무기는 '디버깅의 용이성'과 '전통적 OEM들의 규제 대응 편의성'입니다. 사고나 시스템 오작동이 발생했을 때 "AI가 그렇게 판단했다"가 아니라, "어느 카메라의 인지 신뢰도가 떨어졌고, REM 맵과의 오차가 몇 cm 발생했으며, RSS 규칙 몇 번에 의해 제동이 걸렸다"를 명확히 규명할 수 있기 때문입니다. 이는 양산 차 제조사(OEM)들이 리콜이나 법적 책임 리스크를 관리할 때 엄청난 차이를 만들어냅니다.

4. [인사이트 논평] 왜 모빌아이는 해설 한 줄 없는 '날것의 주행 영상'만 올릴까?

모빌아이 공식 유튜브 채널을 유심히 살펴보면 아주 흥미로운 패턴이 발견됩니다. 테슬라처럼 화려한 FSD 그래픽 UI나 호들갑스러운 자막, 내레이션이 들어간 영상이 거의 없습니다. 실제로 공식 채널에 올라오는 영상도 몇 달 혹은 1년에 한 번꼴로, 이번 4일 전 공개된 미국 중부 영상이나 독일 뮌헨, 중국 상하이 영상처럼 컷 편집조차 거의 없는 '무뚝뚝한 날것(Raw)의 주행 영상'이 전부입니다.

화려한 마케팅이 지배하는 자율주행 시장에서, 모빌아이는 도대체 어떤 목적으로 이런 불친절한 영상을 올리는 걸까요? 여기에는 모빌아이의 비즈니스 모델과 글로벌 3대 격전지를 겨냥한 치밀한 수주 전략이 숨어 있습니다.

① 테슬라의 팬덤 마케팅(B2C) vs 완성차 OEM을 향한 무편집 검증서(B2B)

테슬라는 차량을 소비자에게 직접 판매하는 B2C 기업이자 주가 부양이 중요한 빅테크입니다. 따라서 대중을 열광시킬 자극적인 바이럴 영상과 현란한 대시보드 시각화 그래픽이 마케팅의 핵심 무기입니다.

반면 모빌아이는 포르쉐, 폭스바겐, 지커(Geely), 포드 등 글로벌 완성차를 고객사로 둔 B2B Tier-1/소프트웨어 솔루션 기업입니다. 이 영상의 1차 타깃은 일반 네티즌이 아니라 글로벌 OEM의 구매 담당 임원, 자율주행 선행개발 엔지니어, 그리고 각국 규제 당국입니다.

보수적인 자동차 제조사의 엔지니어들이 가장 경계하는 것은 '유리한 순간만 짜집기(Cherry-picked)한 홍보 영상'입니다. 모빌아이가 운전대에서 손을 뗀 운전자의 모습과 계기판, 외부 시야를 롱테이크로 가감 없이 보여주는 이유는 단 하나, "우리는 단 1초의 컷 편집이나 인간 개입(Zero-disengagement) 없이 이 까다로운 도로를 완주했다"는 강력한 공학적 실증 데이터(Proof of Work)를 증명하기 위함입니다.

② 상하이 → 뮌헨 → 미국 중부: 글로벌 3대 대륙 격전지 순회 전략

모빌아이의 영상 업로드 이력을 보면 유튜버처럼 채널 성장을 위한 정기 업로드가 아닙니다. 회사의 차세대 하드웨어 마일스톤이나 글로벌 거점 수주전이 있을 때마다 '전략적 증거 자료' 격으로 한 편씩 드롭하고 있습니다.

2024년 말, 중국 상하이 도심: 지커(Zeekr 001)와의 성공적인 양산을 바탕으로, 보행자·이륜차·불법 주정차가 극도로 뒤엉킨 아시아 초고난도 환경을 오직 비전 온리(SuperVision)로 뚫어내는 모습을 과시했습니다.
2026년 봄, 독일 뮌헨 도심: 뮌헨은 BMW 본사가 있는 유럽 자동차의 심장부이자, 전 세계에서 자율주행 규제(UNECE DCAS, GSR)가 가장 까다로운 곳입니다. 폭스바겐 그룹, 포르쉐 등 유럽 프리미엄 브랜드 수주전을 겨냥해 "가장 복잡한 유럽 골목과 규제도 REM+카메라로 해결 가능하다"는 강력한 피칭을 던졌습니다.
2026년 9월, 미국 중부 횡단 (최신 영상): 바로 4일 전 공개된 이 영상은 차세대 EyeQ™6H 칩셋의 성능을 공식 입증하는 무대였습니다. 따뜻하고 평온한 캘리포니아가 아니라 폭우, 트램, 시카고 고층빌딩(GPS 음영)이 즐비한 중부 1,000마일을 달리며 테슬라 FSD의 안방인 미국 시장과 북미 레거시 OEM(포드, GM)을 정조준했습니다.

③ "설명이 필요 없다"는 엔지니어링 프라이드

엔지니어링 세계에서는 부연 설명이나 화려한 미사여구가 많을수록 기술의 본질에 의구심이 생기기 마련입니다. 해설 자막 한 줄 없이 그저 달리는 차 안의 소리와 도로 풍경만 담아낸 것은, "EyeQ6H와 REM 맵이 복잡한 롱테일 상황을 스스로 어떻게 해결하는지 두 눈으로 직접 확인하라"는 모빌아이 특유의 독보적인 공학적 자부심이 묻어나는 대목입니다.

5. 마치며

모빌아이 수퍼비전의 실증 영상들은 단순히 기술의 화려함을 뽐내는 데 그치지 않고, 카메라 온리 시스템이 고정밀 경량 맵(REM) 및 수학적 안전 가드레일(RSS)과 결합했을 때 얼마나 완성도 높은 L2++ ADAS를 구현할 수 있는지 증명해 보였습니다.

물론 한계도 명확합니다. 폭우나 폭설로 인해 11개의 카메라 렌즈 중 일부가 완전히 오염되거나 물리적으로 가려지는 물리적 한계 상황에서는 결국 시스템이 운전자에게 제어권을 넘겨야 하는 L2+ 수준에 머물 수밖에 없습니다. 진정한 L4 무인 자율주행으로 가기 위해서는 결국 라이다와 레이더를 결합한 이중화(Redundancy) 센서 아키텍처가 필수적이라는 것이 저를 포함한 많은 엔지니어들의 생각입니다. 모빌아이 역시 수퍼비전 윗 등급인 '수퍼비전 프로'나 '쇼퍼(Chauffeur)' 솔루션에는 라이다를 추가하는 로드맵을 가지고 있죠.

그럼에도 불구하고, 당장 소비자가 구매할 수 있는 양산형 SDV(소프트웨어 중심 자동차) 관점에서는 모빌아이 수퍼비전이 비용 대비 성능(가성비)과 안전성 측면에서 가장 현실적이고 훌륭한 타협점을 제시하고 있다고 봅니다. 앞으로 포르쉐나 지커(Zeekr) 등 글로벌 브랜드의 신차에 탑재될 수퍼비전이 실제 도로에서 소비자들에게 어떤 경험을 줄지 무척 기대되네요.

참고 자료 및 공식 영상 (References)

미국 중부 실증 (최신 4일 전 공개): Mobileye SuperVision™ takes on roads across the central U.S.

(아래 플레이어에서 이번에 공개된 최신 EyeQ6H 기반 미국 중부 실증 주행을 직접 확인해 보세요)

하이퍼바이저 위에서 구현하는 Mixed Criticality: AGL SoCDev 플랫폼의 아키텍처와 실무적 과제

JJTech — Tue, 22 Sep 2026 19:14:24 +0900

최근 자동차 업계의 가장 뜨거운 화두는 단연 SDV(Software-Defined Vehicle, 소프트웨어 정의 차량)입니다. 하지만 현업에서 직접 아키텍처를 설계하다 보면 "말이 쉽지, 하드웨어 개발 주기와 소프트웨어 릴리즈 주기의 간극을 어떻게 메울 것인가?"라는 근본적인 질문에 부딪히게 됩니다.

이번 글에서는 최근 Automotive Grade Linux(AGL)의 SDV Expert Group(SDV-EG) 세션에서 Panasonic의 Jerry Zhao가 발표한 AGL SDV 레퍼런스 플랫폼(SoCDev)의 업데이트 내용을 바탕으로, 가상화 아키텍처의 핵심 메커니즘과 현업 엔지니어로서 바라본 실무적인 한계 및 극복 과제들을 딥다이브해 보려고 합니다.

1. AGL SDV-EG가 제시하는 자동차 소프트웨어 패러다임의 전환

기존의 차량 개발은 전형적인 '하드웨어 중심(Hardware-Centric)'이었습니다. MCU나 SoC가 먼저 정의되고, 그 하드웨어의 특성에 맞춰 드라이버와 OS, 미들웨어를 얹는 탑다운 방식이었죠. 이 방식은 하드웨어 공급이 지연되거나 칩셋이 변경되면 소프트웨어 레이어 전체가 흔들리는 치명적인 리스크를 안고 있었습니다.

AGL의 SDV-EG(SDV Expert Group)가 제안하는 핵심 가치는 아주 명확합니다. 바로 하드웨어와 소프트웨어의 완전한 디커플링(Decoupling)입니다. 소프트웨어를 먼저 개발하고(Software-First Approach), 하드웨어가 준비되지 않은 상태에서도 클라우드나 가상화 환경에서 검증을 끝마치겠다는 전략입니다.

이를 위해 AGL은 단일 SoC 위에서 여러 이기종 OS를 안정적으로 구동하기 위한 가상화 표준 플랫폼인 SoCDev(System on Chip Development Platform)를 정립해 나가고 있습니다.

[그림 1] AGL의 VirtIO 기반 디바이스 가상화 확장 아키텍처

2. AGL SDV 레퍼런스 플랫폼 아키텍처의 핵심 기술

AGL의 SDV 레퍼런스 플랫폼 아키텍처는 하드웨어 추상화를 위해 가상화 및 오픈소스 표준 기술들을 적극적으로 차용하고 있습니다.

flowchart TD
    A["① Physical SoC<br/>(Renesas Sparrowhawk)"] --> B["② Xen Hypervisor<br/>(도메인 격리 계층)"]
    B --> C["③ Cockpit & HMI 도메인<br/>(AGL / Android / RTOS)"]
    B --> D["④ Control & Core 도메인<br/>(Dom0 / Zephyr / VeloRT)"]
    C --> E["⑤ Unified HMI<br/>(가상 디스플레이 통합)"]
    D --> F["⑥ Gateway VM & V2C<br/>(클라우드 데이터 루프)"]

    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

VirtIO 기반의 가상 디바이스 표준화

과거 하이퍼바이저 위에서 구동되는 게스트 OS(Domain U)들은 물리적인 GPU, 오디오, 네트워크 컨트롤러에 접근하기 위해 하이퍼바이저 벤더 고유의 전용 드라이버(Proprietary Driver)를 사용해야 했습니다. 이는 또 다른 형태의 벤더 락인(Vendor Lock-in)을 유발했죠.

AGL은 이를 타파하기 위해 리눅스 표준 가상화 인터페이스인 VirtIO를 전면에 내세웠습니다. VirtIO-GPU, VirtIO-SND, VirtIO-NET 등을 활용하면, 게스트 OS는 하단에 깔린 하이퍼바이저가 Zen인지, QEMU인지, 혹은 물리 하드웨어인지 상관없이 동일한 드라이버 코드로 동작할 수 있게 됩니다. 실제로 이번 발표에서는 가상화 환경뿐만 아니라 멀티 ECU 및 클라우드 환경까지 VirtIO 표준을 확장 적용하는 실증 결과가 공유되었습니다.

Unified HMI를 통한 이기종 도메인 화면 통합

차량 내 디스플레이가 대형화되고 통합되면서, 계기판(Cluster)과 인포테인먼트(IVI) 화면이 물리적으로 하나로 합쳐지는 추세입니다. 하지만 계기판은 높은 안전성(Functional Safety)을 요구하는 RTOS 기반이고, IVI는 풍부한 앱 에코시스템을 가진 Linux나 Android 기반이죠.

이를 해결하기 위해 AGL이 도입한 것이 바로 Unified HMI입니다. 서로 다른 가상머신(VM)에서 렌더링된 화면 소스를 단일 가상 디스플레이 버퍼로 통합하여 송출하고, 필요에 따라 GPU 렌더링 연산 자체를 네트워크나 IPC를 통해 다른 하드웨어로 오프로딩(Offloading)할 수 있는 기술입니다. 2024년 AGL UCB(Unified Code Base) 'Pike' 버전부터 본격 탑재되어 지속적으로 고도화되고 있습니다.

[그림 2] AGL Unified HMI(UHMI)의 가상 디스플레이 및 조널 분산 렌더링 메커니즘

초경량 MQTT와 차량-클라우드 간 실시간 데이터 루프 구성

이번 SDV-EG 업데이트에서 흥미로웠던 점 중 하나는 EMQ가 기여한 VeloRT와 Veloflux의 도입입니다. 각각 초경량 MQTT 브로커(NanoMQ 기반)와 초경량 데이터 스트리밍 처리 엔진(Ekuiper 기반)을 오토모티브 스펙에 맞게 경량화한 모델인데요.

차량 내 수많은 센서 데이터를 가상화된 게이트웨이 VM에서 실시간으로 필터링하고 가공하여 클라우드로 전송하는 '데이터 클로즈드 루프(Data Closed-Loop)' 파이프라인을 구축하는 데 핵심적인 역할을 합니다. 데이터 파이프라인의 가상화까지 지원함으로써 차량 소프트웨어 개발자가 클라우드 환경에서 가상 차량을 띄워놓고 데이터 수집 및 AI 모델 재학습 시나리오를 온전히 테스트할 수 있는 기반이 마련된 셈입니다.

3. 기존 방식 대비 비교 분석 및 실무 고려사항

현업 엔지니어링 관점에서 기존 하드웨어 종속적 개발 방식과 AGL의 SDV 레퍼런스 플랫폼 아키텍처를 비교해 보면 아래와 같은 명확한 득실이 존재합니다.

비교 항목	기존 하드웨어 중심 개발	AGL SDV 레퍼런스 플랫폼 (SoCDev)
하드웨어 의존성	매우 높음 (H/W 변경 시 드라이버 재작성 필요)	매우 낮음 (VirtIO 기반의 추상화 레이어 적용)
소프트웨어 개발 주기	하드웨어 샘플(B-Sample 등) 확보 이후 시작	가상 가상화 환경 및 클라우드에서 선행 개발 가능
Mixed Criticality 지원	물리적 ECU 분리를 통해서만 안전성 확보	단일 SoC 내 하이퍼바이저 도메인 격리로 구현
시스템 오버헤드	없음 (네이티브 구동)	하이퍼바이저 및 가상 디바이스(VirtIO) 백엔드 오버헤드 존재
HMI 통합 난이도	하드웨어 기반 비디오 스위처 등 고비용 솔루션 필요	Unified HMI 소프트웨어 레이어에서 가상 통합 지원

현업 엔지니어로서의 솔직한 고찰

이 아키텍처가 장점만 있는 것은 아닙니다. 실제로 실무에서 단일 SoC에 가상화 플랫폼을 올릴 때 직면하는 가장 큰 난제는 Mixed Criticality(상호 안전성 등급 혼재)의 실질적 보장입니다.

ASIL-B 등급의 계기판 도메인과 ASIL-A 혹은 QM 등급의 IVI 도메인이 동일한 SoC 내에서 자원을 공유할 때, IVI 도메인에서 비정상적인 메모리 누수나 GPU 과부하가 발생하면 계기판의 렌더링 루프가 깨질 위험이 있습니다. Zen 하이퍼바이저가 아무리 도메인 간 격리를 완벽히 지원한다고 해도, 물리적인 L3 캐시나 메모리 대역폭(Memory Bandwidth)의 간섭(Interference)까지 완벽히 차단하기는 어렵습니다.

따라서 실제 양산에 적용하기 위해서는 가상 드라이버 단에서의 자원 할당 정책(QoS)과 워치독(Watchdog) 메커니즘을 칩셋 레벨(하드웨어 방화벽 등)과 정밀하게 연동 설계해야 하는 숙제가 남아있습니다.

4. 마치며

이번 AGL SDV-EG의 발표는 단순한 개념 제시를 넘어, 현대자동차(Hyundai)의 양산 IVI 시스템을 SoCDev 플랫폼 위에서 구동한 데모나 르네사스(Renesas)의 Sparrowhawk 레퍼런스 보드 실증 등 양산에 한 발짝 더 다가선 구체적인 결과물들을 보여주었다는 점에서 큰 의미가 있습니다.

하드웨어와 소프트웨어의 경계를 허물고, 클라우드와 차량의 데이터 루프를 가상화 기술로 연결하는 아키텍처는 이제 거스를 수 없는 대세입니다. 다만, 우리 엔지니어들에게는 가상화로 인해 발생하는 성능 오버헤드를 최적화하고, 안전 등급이 다른 기능들이 한 칩 안에서 평화롭게 공존할 수 있도록 보장하는 정교한 튜닝 기술이 앞으로의 핵심 경쟁력이 될 것입니다.

새로운 아키텍처 도입을 고민 중인 동료 엔지니어분들에게 이번 분석이 실무적인 힌트가 되었기를 바랍니다.

참고 자료 및 공식 영상 (References)

Mobileye CTO가 말하는 자율주행 롱테일의 함정: 시나리오 부스팅으로 스케일링 한계 돌파하기

JJTech — Tue, 22 Sep 2026 07:47:33 +0900

1. 자율주행 롱테일 스케일링의 한계와 마주하다

자율주행 현업에 있다 보면 누구나 한 번쯤 "데이터를 더 많이 모으고 모델 크기를 키우면 결국 해결되지 않을까?"라는 리치 서튼(Rich Sutton)의 '쓴 교훈(The Bitter Lesson)'에 기댄 고민을 하게 됩니다. 파운데이션 모델 트렌드에 발맞춰 엔드투엔드(End-to-End) 러닝이나 비전-언어-행동(VLA) 모델을 도입하면 모든 게 풀릴 것 같지만, 실무에서 마주하는 현실은 그리 녹록지 않네요.

Mobileye의 CTO인 Prof. Shai Shalev-Shwartz가 CVPR 2026에서 발표한 내용은 바로 이 지점의 정곡을 찌릅니다. 자율주행은 전형적인 오픈 월드(Open-world) 문제입니다. 인지, 씬(Scene) 변화, 상호작용 등 해결해야 할 변수가 무궁무진한데요. 문제는 대규모 데이터를 투입해 딥러닝 모델을 스케일링할 때 치명적인 ‘수렴 속도의 한계(Diminishing Returns)’가 발생한다는 점입니다.

[그림1] 롱테일 시나리오 및 '건초 속 바늘' 문제 실증 장면

'쓴 교훈(The Bitter Lesson)'과 자율주행의 괴리

LLM 분야의 친칠라(Chinchilla) 스케일링 법칙을 자율주행에 대입해 보면, 손실(Loss)을 몇 자릿수 낮추기 위해 필요한 파라미터와 데이터 양이 10의 40승(또는 10^40) 수준으로 폭증하는 기괴한 현상을 마주하게 됩니다.

왜 이렇게 스케일링이 느릴까요? 필자는 그 근본 원인이 바로 ‘낮은 신호 대 잡음비(Low Signal-to-Noise Ratio, SNR)’에 있다고 봅니다. 수억 킬로미터의 주행 마일리지 중 99.9%는 평범한 고속도로 정속 주행 같은 무의미한 데이터이며, 시스템을 고장 내는 '엣지 케이스(Edge case)'는 거대한 건초더미 속에 숨겨진 바늘 한 개에 불과하기 때문입니다.

2. 현업의 시각에서 본 아키텍처의 비밀

그렇다면 현업에서는 이 SNR 문제를 어떻게 해결해야 할까요? 기존에는 보조 태스크(Auxiliary Tasks)를 추가하거나 커리큘럼 러닝, 포토레얼리스틱 시뮬레이션 등을 암묵적으로 적용해 왔습니다. 하지만 Mobileye는 여기서 한 걸음 더 나아가, 실패의 발견(Discovery)과 해결(Resolution)을 명확하게 분리하는 새로운 부스팅 오브젝티브를 제안합니다.

flowchart TD
    A["대규모 주행 비디오 수집"] --> B["VLRM 기반 임베딩 및 텍스트화"]
    B --> C["Elasticsearch & Pinecone 벡터 DB"]
    C --> D["Scenario Boosting: 실패 시나리오 발굴"]
    D --> E["제너레이터 G(s) 데이터 증강"]
    E --> F["모델 재학습 및 클로즈드 루프 검증"]

    classDef default fill:#f8faff,stroke:#0066cc,stroke-width:1.5px,color:#222,font-size:13px;

VLRM 임베딩과 Pinecone-Elasticsearch 하이브리드 검색

시스템의 첫 번째 축은 방대한 비디오 데이터(수백만 시간)를 자연어와 구조화된 속성, 그리고 뉴럴 임베딩 벡터로 변환하는 것입니다.

비디오 전체, 개별 이미지, 그리고 이미지 내 개별 객체 수준에서 VLM(Vision-Language Model) 임베딩을 거치면, 데이터베이스는 마치 숙련된 데이터 사이언티스트처럼 각 시나리오의 가시성, 희귀성, 복잡도(날씨, 도로 구조 등)를 텍스트로 설명할 수 있게 됩니다. 이를 통해 Pinecone(임베딩 공간 기반 근접 이웃 검색)과 Elasticsearch(텍스트 검색)를 결합한 강력한 시맨틱 검색 파이프라인이 완성됩니다.

실패를 명명하는 Scenario Boosting 알고리즘

클래식한 AdaBoost 알고리즘은 훈련 세트의 개별 예제에 대해 최대 손실을 최소화하려 하지만, 노이즈에 극도로 취약하다는 약점이 있습니다. 자율주행 센서 데이터에 섞인 약간의 반사광이나 라벨링 오차(Noise)가 알고리즘 전체를 망가뜨릴 수 있죠.

Mobileye가 도입한 Scenario Boosting은 개별 예제가 아닌 '시나리오(Scenario)' 단위로 최적화(Max)를 수행합니다.

Scenario Boosting 최적화 원리:

모델 파라미터는 최악의 시나리오 조건에서도 손실(Loss)이 최소화되도록 학습됩니다.

S (Scenario): 실패가 발생하는 시나리오의 의미론적 표현

G(s) (Generator): 해당 시나리오 조건 하에서 생성되는 극단적인 엣지 케이스 데이터

시스템은 "스스로 일관되게 실패하는 재현 가능한 에러(Reproducible Error)"를 정의하고, VLRM 에이전트(METEOR)를 통해 이 실패를 정확히 명명(Naming)하여 집중 학습시키는 구조입니다.

3. 전통적 E2E 모델과의 실무적인 차이점

현업 엔지니어 관점에서 기존의 확률적 경사 하강법(SGD) 기반 학습과 Scenario Boosting의 차이는 명확합니다. 아래 비교 표를 통해 두 방식의 실무적 차이를 정리해 보겠습니다.

비교 항목	전통적 SGD / 무작위 샘플링	Scenario Boosting (METEOR 에이전트)
최적화 대상	개별 데이터 샘플 (x, y)의 기대 손실	의미론적 시나리오(S) 단위의 최악 케이스(Worst-case)
노이즈 민감도	높음 (개별 센서 노이즈가 그래디언트를 왜곡)	낮음 (재현 가능한 시나리오 클래스 단위 필터링)
희귀 케이스 대응	데이터셋 내 빈도에 의존하여 누락되기 쉬움	제너레이터 G(s)를 통한 적극적 시나리오 증강 및 부스팅
실무 해석 가능성	블랙박스 형태의 전역 손실 감소	VLRM 기반의 명확한 실패 가설 및 시맨틱 질의 도출

가우시안 스플래팅(3DGS) 기반 시나리오 합성의 실무 과제

물론 실무 적용 시의 과제도 존재합니다. 생성형 AI(GenAI) 기반의 시뮬레이션 데이터를 활용해 3D 가우시안 스플래팅(3D Gaussian Splatting) 등으로 가상 객체를 실제 주행 영상 클립에 정교하게 플랜팅(Planting)하는 과정에서 광학적·물리적 정합성을 완벽히 유지하는 것은 여전히 까다로운 엔지니어링 과제입니다.

하지만 노이즈가 섞인 리얼 데이터의 한계를 넘어, 생성형 모델로 희귀 롱테일 시나리오를 자유자재로 합성해 낸다는 점은 자율주행 안전성 검증 파이프라인의 패러다임을 바꿀 만한 임팩트를 지닙니다.

4. 마치며

이번 Mobileye의 발표는 자율주행 AI가 단순히 "데이터를 더 많이 밀어 넣는 무식한 스케일링"의 한계를 어떻게 수학적, 아키텍처적으로 극복하려 하는지 보여주는 훌륭한 이공계적 해답입니다.

특히 딥러닝 모델의 학습 과정을 '학습자(Learner)'와 '데이터 분석가(Data Analyst)' 간의 2인용 게임으로 재정의하고, 이를 VLRM 기반의 METEOR 에이전트로 자동화한 아이디어는 실무 아키텍처 설계에 있어 시사하는 바가 큽니다.

롱테일이라는 거대한 산을 넘기 위해 우리 엔지니어들이 가져야 할 시각은 무작정 데이터셋의 크기만 키우는 것이 아니라, "실패를 똑똑하게 발견하고 재현 가능한 형태로 부스팅하는 닫힌 루프(Closed-loop) 시스템"을 구축하는 것입니다. JJ-Space 독자 여러분의 현업 파이프라인에도 깊은 영감이 되었기를 바랍니다.

참고 자료 및 공식 영상 (References)

영상 출처: Mobileye 공식 유튜브 채널 - Driving the Long Tail: Prof. Shai Shalev-Shwartz at CVPR 2026
키노트 발표자: Prof. Shai Shalev-Shwartz (CTO, Mobileye)
핵심 키워드: Scenario Boosting, VLRM, METEOR Agent, 3D Gaussian Splatting, Closed-loop Evaluation
(본문 내 삽입된 유튜브 링크 카드를 통해 해당 발표 구간을 고화질 영상으로 직접 시청하실 수 있습니다)

테슬라 사이버캡(Cybercab) 오스틴 실전 투입, 엔지니어 시선에서 본 '스티어링 휠 없는' 자율주행의 명과 암

JJTech — Mon, 21 Sep 2026 18:55:05 +0900

1. 테슬라 사이버캡(Cybercab) 오스틴 실증의 핵심 요약

드디어 올 것이 왔네요. 테슬라가 스티어링 휠과 페달을 완전히 제거한 최초의 목적 기반 자율주행 차량(PBV), '사이버캡(Cybercab)'을 미국 텍사스 오스틴에서 공식적으로 선보였습니다. 단순한 콘셉트 카 쇼케이스에 그치지 않고, iOS와 안드로이드 플랫폼에 'Tesla Robotaxi' 앱을 동시에 출시하며 실제 호출 서비스의 서막을 열었습니다.

[그림 1] 스티어링 휠과 물리 페달이 완전히 배제된 사이버캡의 내부 레이아웃. 인간의 수동 개입 가능성을 원천 차단하고 오직 시스템 신뢰성에만 의존하는 구조입니다. (출처: Tesla 공식 유튜브)

이번 발표에서 가장 눈여겨볼 점은 '접근성(Accessibility)'과 '비용 효율성'의 극대화입니다. 기존 로보택시 업계가 값비싼 라이다(LiDAR)와 고정밀 지도(HD Map)에 의존할 때, 테슬라는 오직 카메라 기반의 비전 시스템과 End-to-End 신경망만으로 L4 수준의 자율주행을 구현하겠다고 선언한 셈이니까요. 운전석이 사라진 내부 공간은 오직 승객의 편의성과 인포테인먼트 경험에 최적화되어 있습니다. 하지만 우리 같은 엔지니어들의 머릿속은 복잡해집니다. "과연 물리적 제어 장치가 없는 차량의 안전 무결성(Safety Integrity)을 어떻게 보장할 것인가?"라는 근본적인 질문이 꼬리를 물기 때문입니다.

2. 현업 엔지니어의 시각에서 본 사이버캡 아키텍처의 비밀

Vision-Only와 End-to-End AI의 극단적 결합

사이버캡의 두뇌는 FSD(Full Self-Driving) V12 아키텍처의 연장선에 있습니다. 카메라가 받아들인 광자(Photons) 데이터가 신경망(Neural Network)을 거쳐 조향각과 가감속 제어 명령(Control Commands)으로 직접 변환되는 구조죠. 현업에서 기존의 모듈형 아키텍처(인지-판단-제어 분리형)를 다루다 보면, 각 모듈 간의 핸드오버 과정에서 발생하는 레이턴시(Latency)와 정보 손실이 늘 골칫거리입니다. 테슬라의 End-to-End 방식은 이 병목을 해결하는 데 탁월한 효율을 보여줍니다.
하지만 인공지능이 내린 판단의 '설명 가능성(Explainability)'이 부족하다는 점은 여전히 아킬레스건입니다. 스티어링 휠이 없는 상태에서 시스템이 기괴한 조향 명령을 내렸을 때, 블랙박스 형태의 딥러닝 모델 안에서 정확히 어떤 가중치(Weight)가 오작동했는지 실시간으로 규명하기는 대단히 어렵습니다.

물리적 제어 장치 제거가 요구하는 하드웨어 이중화(Redundancy)

스티어링 휠과 페달이 없다는 것은 비상 상황에서 인간 운전자가 물리적으로 개입할 '최후의 보루'가 사라졌음을 의미합니다. 이는 차량 설계 단계에서 엄청난 수준의 하드웨어 이중화를 강제합니다.
조향 시스템(Steering Actuator)과 제동 시스템(Braking System)은 물론이고, 이를 구동하는 전력망(Power Grid)과 연산 장치(FSD Computer)까지 모두 듀얼 채널 혹은 트리플 채널로 백업되어야 합니다. 메인 컴퓨터가 다운되더라도 서브 컴퓨터가 즉각 제어권을 넘겨받아 안전지대로 차량을 대피시키는 'Fail-Safe' 메커니즘이 완벽히 작동해야만 도로교통안전국(NHTSA)의 까다로운 안전 기준을 통과할 수 있습니다.

[그림2] 테슬라 FSD 컴퓨터의 제어 명령 생성 및 실시간 이상 감지 시 개입 메커니즘

3. 전통적 로보택시 방식과의 실무적인 차이점

웨이모(Waymo)나 크루즈(Cruise) 같은 기존의 로보택시 강자들은 안전을 위해 '과잉 투자'하는 전략을 취해왔습니다. 차량 한 대당 억 소리 나는 라이다와 레이더, 그리고 센서 클리닝 시스템을 덕지덕지 붙였죠. 반면 테슬라는 양산성과 단가 절감에 초점을 맞추고 있습니다.

HD 맵 프리(Map-free) 주행의 현실적 한계와 극복 과제

웨이모는 사전에 정밀 스캔한 HD 맵 위에서 센서 데이터를 매칭하며 달립니다. 덕분에 교차로의 형태나 신호등의 위치를 미리 알고 있어 인지 부하가 적습니다. 반면 테슬라는 실시간 비전 인지에만 의존합니다. 오스틴처럼 도로 공사가 잦고 차선이 수시로 바뀌는 환경에서는 테슬라의 방식이 실시간 대응력 면에서 우위를 가질 수 있지만, 역설적으로 악천후(호우, 폭설, 역광) 상황에서는 카메라 렌즈의 오염이나 시야 차단으로 인해 순간적인 '인지 블라인드' 현상이 발생할 위험이 큽니다.

규제(Regulatory)와 안전성 검증 프로토콜의 격차

미국 연방자동차안전기준(FMVSS)은 전통적으로 운전대와 페달이 있는 차량을 기준으로 제정되어 있습니다. 테슬라가 오스틴에서 서비스를 개시하기 위해서는 단순한 기술적 완성도를 넘어, 연방 정부 및 텍사스 주 정부로부터 '수동 제어 장치가 없는 차량'에 대한 특별 임시 허가(Exemption)를 지속적으로 취득해야 합니다. 이 과정에서 요구되는 사고율 데이터와 시뮬레이션 검증 프로토콜은 상상을 초월할 정도로 엄격합니다.

핵심 센서 구성	비전 카메라 온리 (Vision-Only)	라이다(LiDAR) + 레이더 + 카메라 멀티센서
지도 의존도	실시간 로컬 맵 생성 (Map-free)	고정밀 지도 (HD Map) 필수 기반
물리 제어 장치	없음 (스티어링 휠 / 페달 완전 배제)	기존 양산 차량 개조 (수동 개입 가능)
스케일업 강점	낮은 하드웨어 단가, 빠른 글로벌 확장성	높은 인프라 구축 비용, 지오펜싱(Geofencing) 제한
악천후 복원력	카메라 오염 및 시야 확보에 상대적 취약	센서 퓨전을 통한 다중 백업으로 안정성 우수

4. 마치며

테슬라의 사이버캡 오스틴 출시는 자율주행 업계에 던지는 거대한 출사표입니다. "라이다 없이, 운전대 없이도 대중을 위한 로보택시가 가능하다"는 일론 머스크의 가설이 드디어 실제 도로 위에서 증명 시험대에 오른 것이죠.
엔지니어 관점에서 솔직히 말씀드리면, 아직 우려되는 구석이 많습니다. 엣지 케이스(Edge Case, 특이 상황)에서의 인공지능 오작동 대책이나, 센서 오염에 대응할 물리적 세척 장치의 한계 등은 현업에서 가장 골머리를 썩이는 부분들이거든요. 그럼에도 불구하고, 소프트웨어 업데이트(OTA)만으로 차량의 주행 성능을 진화시켜 온 테슬라의 저력을 생각하면 이번 오스틴 실증이 자율주행 패러다임을 송두리째 바꿀 변곡점이 될 것임은 분명해 보입니다. 과연 사이버캡이 규제 당국의 깐깐한 눈높이를 통과하고 진정한 '모두를 위한 자율주행'을 안착시킬 수 있을지, 설레는 마음으로 지켜보겠습니다.

참고 자료 및 공식 영상 (References)

영상 출처: Tesla 공식 유튜브 채널 - The Future Has Arrived | Cybercab

"단순 제어를 넘어 '생각'하는 자율주행으로" - Alpamayo 2 Super가 제시하는 오픈소스 VLA의 미래

JJTech — Mon, 21 Sep 2026 07:30:48 +0900

1. 자율주행 판도를 흔들 거대한 녀석, Alpamayo 2 Super의 등장

최근 자율주행 씬을 보면 룰 기반(Rule-based) 제어는 확실히 한물갔고, 종단간(End-to-End) 모방 학습을 넘어 아예 인공지능 기초 모델(Foundation Model)로 넘어가는 과도기라는 느낌이 강하게 듭니다. 매일 쏟아지는 논문들 사이에서 유독 제 눈길을 끈 녀석이 하나 있었는데, 바로 세계 최대 규모의 추론 기반 시각-언어-행동 모델(VLA, Vision-Language-Action)인 Alpamayo 2 Super입니다.

이 모델이 재밌는 점은 단순히 센서 데이터를 넣으면 운전대를 꺾는 '블랙박스' 짓을 안 한다는 겁니다. 복잡한 도로 상황을 맞닥뜨리면 인간 운전자처럼 상황을 쪼개서 스스로 '생각(Reasoning)'을 한 뒤에 움직입니다.

[그림 1] 복잡한 도심 도로 환경에서 NVIDIA Alpamayo 2가 실시간 주행 맥락을 인식하고 전방 객체(차량 바운딩 박스)를 감지하여 주행 궤적을 연산하는 실증 시연 화면 (출처: NVIDIA Developer 공식 유튜브)

2. 현업의 시각에서 본 아키텍처의 비밀

엔지니어 관점에서 이 모델의 백서를 뜯어보면서 가장 인상 깊었던 건 다중 모달리티(Multi-modality)를 주행 파이프라인에 엄청나게 매끄럽게 녹여냈다는 점입니다.

360도 공간 인지의 강력함

기존의 비전-언어 모델(VLM)을 자율주행에 얹으려던 시도들은 대부분 전방 카메라 이미지 하나에 의존했습니다. 그런데 Alpamayo는 전방, 측면, 후방을 아우르는 360도 카메라 입력을 통째로 밀어 넣습니다. 교차로 꼬리물기나 사각지대에서 튀어나오는 이륜차 같은 엣지 케이스에서 공간적 맥락(Spatial Context)을 놓치지 않는다는 건 실무적으로 엄청난 이점이죠.

[그림 2] 차량 주변 360도 전방위 카메라 피드를 통합 인지하여 사각지대 및 교차로 맥락을 다각도로 해석하는 멀티뷰 공간 인지 화면 (출처: NVIDIA Developer 공식 유튜브)

메타 액션(Meta Action): 시스템의 판단 근거 제시

이 모델은 곧바로 조향각 수치를 뱉는 대신, 메타 액션(Meta Action)이라는 중간 계획표를 먼저 던집니다. 예를 들어 시스템 내부에서 *"앞차와의 간격이 좁아지니 서서히 감속하면서 좌측 차선으로 변경할 것"* 이라는 자연어 텍스트와 토큰을 먼저 생성해요. 그런 다음 이걸 기반으로 세부 물리적 궤적(Trajectory)을 그립니다.
사고가 났을 때 원인 분석이 불가능했던 기존 End-to-End의 가장 큰 단점(블랙박스)을 이 2단계 접근법으로 영리하게 우회한 셈입니다.

graph LR
    subgraph Input_Layer ["1. 멀티뷰 센서 입력"]
        Cam1[전방 카메라]
        Cam2[측/후방 360도 서라운드]
        Nav[네비게이션 경로 / Prompt]
    end

    subgraph Reasoning_Engine ["2. NVIDIA Alpamayo VLA 추론 엔진"]
        VLM[시각-언어 백본 모델]
        CoT[Chain-of-Thought 상황 판단]
    end

    subgraph Action_Output ["3. 2단계 액션 생성"]
        Meta[메타 액션: 자연어 주행 계획<br/>'앞차 감속으로 좌측 차선 변경']
        Traj[정밀 제어 궤적 Waypoints 생성]
    end

    Cam1 --> VLM
    Cam2 --> VLM
    Nav --> VLM
    VLM --> CoT
    CoT --> Meta
    Meta --> Traj

3. 전통적 E2E 모델과의 실무적인 차이점

비교 항목	전통적인 End-to-End 제어	Alpamayo 2 Super (VLA 기반)
의사결정 방식	다이렉트 매핑 (블랙박스)	단계별 추론(Reasoning) 거침
출력 양식	조향각, 가속/감속 제어 값	메타 액션 텍스트, 2D 바운딩 박스, 정밀 궤적
설명 가능성	매우 낮음 (왜 꺾었는지 모름)	매우 높음 (텍스트로 판단 근거 제시)
가장 큰 한계점	엣지 케이스 대응 불가	거대 모델 특성상 실시간 '추론 지연 시간(Latency)' 병목

4. 당장 우리 회사에 쓸 수 있을까?

아키텍처가 훌륭하다고 해서 내일 당장 양산차 실시간 제어기에 꽂아 넣을 순 없습니다. 거대 모델 특유의 추론 지연 시간(Latency) 때문이죠. 차량 제어는 0.1초가 생명인데, 아직 이 덩치 큰 모델을 차량 내(On-board) 칩셋에서 실시간으로 휙휙 돌리기엔 무리가 있습니다.

하지만 클라우드(Off-board) 환경이라면 얘기가 다릅니다. 당장 데이터 자동 라벨링(Auto-Labeling) 파이프라인에 투입하면 라벨링 비용을 획기적으로 줄일 수 있습니다. 오픈소스로 가중치가 풀려있으니, 자사의 엣지 케이스 데이터만 살짝 태워서(SFT) 시뮬레이션 시나리오 생성기로 쓰는 게 현재로서는 베스트 프랙티스라고 생각합니다.

오픈소스 VLA가 대기업들만의 닫힌 리그였던 자율주행 씬을 얼마나 빠르게 뒤흔들어 놓을지, 벌써부터 팝콘 각입니다.

참고 자료 및 공식 영상 (References)

영상 출처 : NVIDIA Developer 공식 채널

현대차 Atria AI 서울 도심 실증: E2E 자율주행과 데이터 플라이휠이 바꾸는 SDV 아키텍처

JJTech — Sun, 20 Sep 2026 12:49:42 +0900

현대자동차그룹이 서울 도심 및 고속화도로 환경에서 자체 개발 중인 엔드투엔드(End-to-End, E2E) 자율주행 시스템 'Atria(아트리아) AI'의 실제 도로 주행 테스트를 공개했습니다.

복합적인 강북 도심 교차로와 좁은 톨게이트, 올림픽대로 합류 구간을 통과하는 이번 주행은 단순한 운전자 주행 보조(ADAS) 시연을 넘어, 전통 완성차 제조사(OEM)가 고성능 컴퓨터(HPC) 중심의 피지컬 AI(Physical AI) 기업으로 전환하는 과정에서 마주한 실제 소프트웨어 스택의 현주소와 기술적 과제를 명확히 보여줍니다.

[그림 1] 서울 도심 실증 중 복합 도로 환경에서 Atria AI가 실시간 경로 및 주변 객체를 연산하는 주행 시연 화면 (출처: 현대자동차그룹 공식 유튜브)

1. Atria AI 실증 주행의 핵심 기술 요약

비전 중심 E2E 신경망 및 점유 그리드(Occupancy Network) 적용
차선이 지워지거나 불분명한 비정형 도로에서도 단순 2D/3D Bounding Box에 의존하지 않고, 3D 점유 공간(Drivable vs. Non-Drivable Space)을 추론해 주행 가능 영역을 정밀하게 산출합니다.
스페셜 이벤트 레코더(SER) 체계 도입
주행 중 0.01% 미만의 극단적인 엣지 케이스(Edge Case)나 이상 징후 발생 시에만 핀셋 형태로 데이터를 선별·로깅하여 클라우드로 전송하는 섀도우 모드(Shadow Mode) 체계를 적용했습니다.
양산형 데이터 플라이휠(Data Flywheel) 가동 계획
향후 연간 700만~800만 대에 이르는 양산 SDV 차량에서 규격화된 센서 및 컴퓨팅 아키텍처를 기반으로 데이터를 지속 회수·정제해 신경망 모델을 고도화하는 루프를 구축 중입니다.
차세대 멀티모달 VLA(Vision-Language-Action) 로드맵 제시
현재의 E2E 모델 한계를 넘어, 복잡한 도로 합류 및 비보호 회전 시 타 차량과의 상호작용(Negotiation)을 유연하게 처리하기 위해 차세대 VLA 파운데이션 모델로의 전환 방향을 공식화했습니다.

2. 엔지니어링 관점의 심층 아키텍처 분석

① Rule-based 모듈형 파이프라인에서 E2E / Occupancy 체계로의 전환

기존의 전통적인 자율주행 스택은 인식(Perception) ➔ 추적(Tracking) ➔ 예측(Prediction) ➔ 경로 계획(Planning) ➔ 제어(Control) 단계가 개별 모듈로 직렬 연결되는 파이프라인 구조였습니다. 이 방식은 각 인터페이스 단계마다 오차가 누적(Error Propagation)되고, 예외 상황에 대응하기 위해 수만 줄의 수동 예외 규칙(Heuristics)이 필요했습니다.

반면 Atria AI가 채택한 접근법은 센서 입력을 단일 잠재 공간(Latent Space)으로 투영하여 주행 궤적(Trajectory)을 직접 산출하는 방식입니다. 특히 도심 구간에서 트럭의 적재함 돌출부나 불법 주정차 차량을 감지할 때, 명시적 클래스 분류가 실패하더라도 Occupancy Network가 볼륨 기반의 점유 여부를 계산함으로써 장애물을 부드럽게 우회(Nudging)하는 동작을 구현해 냈습니다.

비교 항목	전통적 Rule-based / 모듈형 ADAS	Atria AI 기반 차세대 E2E 아키텍처
인식 체계	2D/3D Bounding Box (객체 분류 중심)	3D Occupancy Grid + Latent Feature Map
의사결정 방식	상태 머신(State Machine) 기반 분기 제어	신경망 기반 궤적 최적화 및 종단간 계획
코너 케이스	엔지니어의 수동 규칙 추가 및 튜닝	SER 기반 엣지 데이터 수집 후 모델 재학습
주요 병목	모듈 간 인터페이스 지연 및 누적 오차	추론 연산량(FLOPs) 급증 및 설명가능성(XAI) 부재

[그림 2] 센서 정보와 내비게이션 데이터를 입력받아 Atria AI 백본 신경망과 가드레일, 메모리 블록을 거쳐 최종 차량 제어 명령을 산출하는 엔드투엔드(E2E) 자율주행 학습 아키텍처 파이프라인 (출처: 현대자동차그룹 공식 유튜브)

② 데이터 플라이휠과 'SER' 핀셋 로깅의 아키텍처적 가치

차량 내 멀티 카메라(8MP 이상 복수 채널)와 레이더 센서의 Raw 데이터를 전량 저장 및 전송하는 것은 차량 내부 eMMC/UFS 내구성과 5G 텔레메틱스 통신 비용 측면에서 물리적으로 불가능합니다.

영상에서 강조된 스페셜 이벤트 레코더(SER)는 온보드 상에서 예측 오차(Prediction Loss)가 임계값을 초과하거나 긴급 제동/조향, 운전자 강제 개입(Disengagement)이 발생한 전후 수초간의 센서 링버퍼(Ring Buffer) 데이터만을 캡처하여 메타데이터와 함께 압축 업로드합니다. 이는 백엔드 MLOps 파이프라인의 레이블링 및 스토리지 비용을 획기적으로 줄여 플라이휠의 회전 속도를 가속화하는 핵심 인프라입니다.

[그림 3] 예측 오차 임계값 초과 및 긴급 제동·조향, 운전자 강제 개입 시 전후 수초간의 데이터를 핀셋 로깅하는 스페셜 이벤트 레코더(SER) 작동 화면 (출처: 현대자동차그룹 공식 유튜브)

참고 영상 세션: 본문의 SER 로깅 및 데이터 파이프라인 관련 상세 발표 내용은 Atria AI부터 VLA까지, 현대자동차그룹 자율주행 미디어 데이 Full ver 영상 (25:04~)에서 직접 확인하실 수 있습니다.

3. 현업 실무 관점의 구현 과제와 미래 전망

① 기능안전(ISO 26262)과 ASIL 분해(Decomposition)의 딜레마

E2E 딥러닝 모델은 본질적으로 내부 의사결정 추론 과정을 완전히 역추적하기 어려운 블랙박스(Black-box) 특성을 지닙니다. 따라서 단일 신경망 모델만으로는 자동차 기능안전 표준인 ISO 26262 ASIL-D 요구사항을 충족하기 어렵습니다. 실제 양산 배포를 위해서는 다음과 같은 이중화 아키텍처 구성이 요구됩니다:

HPC 영역 (Linux/QNX 기반 OS): 고성능 NPU/GPU 가속기 상에서 E2E Atria 모델이 고차원 주행 궤적을 실시간 연산.
Safety MCU 영역 (Classic AUTOSAR 기반): 독립된 ASIL-D 코어에서 궤적의 가속도·각속도 한계(Dynamic Safety Envelope)를 상시 감시하고, 이상 궤적 발생 시 즉각 제어권을 회수해 비상 제동(AEB) 및 정지 경로를 실행하는 Checker-Doer(또는 모니터링) 듀얼 구조 적용.

② 클라우드-차량 간 통신 및 도메인 컨트롤러 발열 최적화

센서와 제어기 아키텍처가 전환되는 과정에서 필연적으로 데이터 병목이 발생합니다. 다채널 고해상도 카메라 신호의 직렬화(SerDes) 및 센서 퓨전 데이터를 기가비트 이더넷(SOME/IP, DDS)을 거쳐 NPU 메모리로 제로 카피(Zero-copy) 전달하는 과정에서 지연 시간(End-to-End Latency)을 50~100ms 이내로 묶어두어야 합니다.

또한 자율주행 도메인 컨트롤러의 높은 전력 소모(TDP 300W~500W급)에 따른 수랭식 방열 패키징과 전비 저하 최소화는 임베디드 하드웨어 관점에서 여전히 무거운 양산 과제입니다.

4. 마치며

현대차 Atria AI의 서울 도심 실증은 E2E 신경망이 실제 도로에서 보여줄 수 있는 유연한 주행 가능성을 훌륭히 입증했습니다. 그러나 양산 SDV 시대의 진정한 승부처는 단순히 '얼마나 파라미터가 큰 모델을 차량에 올렸는가'가 아닙니다.

극단적인 주행 환경의 엣지 케이스를 차량 단에서 정교하게 감지해 다시 중앙 클라우드로 환류시키는 '온보드 섀도우 로깅 파이프라인과 안전 감시 아키텍처의 완성도'가 향후 양산 자율주행 생태계의 판도를 결정짓는 핵심 열쇠가 될 것입니다.

참고 자료 및 공식 영상 (References)

영상 출처 : 현대자동차그룹 공식 유튜브 채널

JJ Space | 자율주행 SDV & Physical AI 로보틱스

Privacy Policy (개인정보처리방침)

Privacy Policy (개인정보처리방침)

1. 수집하는 정보 및 수집 방법

2. 쿠키(Cookie) 및 웹 비콘(Web Beacon) 사용 고지

3. Google AdSense 및 타사 광고 서비스 정책 준수 (필수 고지)

4. 제3자 웹로그 분석 (Google Analytics 등)

5. 외부 링크 및 면책 조항 (Disclaimer)

6. 개인정보 보호 책임자 및 문의처

About & Contact

About JJ Space

Contact & Feedback

[1편: 아키텍처] 100만 달러 비동기 GRPO로 빚어냈다: 샤오미 MiMo-V2.6이 딥시크와 빅테크를 저격한 강화학습 인프라의 비밀

1. 스마트폰과 EV를 넘어 '피지컬 AI'로: 샤오미 MiMo-V2.6의 충격

2. 'You Only RL Once' 아키텍처와 강화학습(RL) 엔지니어링 딥다이브

비동기 GRPO와 대규모 에이전트 롤아웃의 조화

GRS와 GAR: 단순 보상을 넘어 '클린 솔루션'을 유도하는 법

리워드 해킹(Reward Hacking)과의 전쟁

3. 로봇 엔지니어가 바라본 실무적 한계와 Embodied AI 적용 가능성

시뮬레이션 Franka Panda 제어와 VLA의 가능성

극단적인 가성비의 Flash 모델: 엣지 및 클라우드 로봇 생태계의 파괴자

4. 마치며

참고 자료 (References)

테슬라 옵티머스도 못 피한 로봇 병목: 엔비디아가 Isaac ROS 5.0과 AI 에이전트로 '제로카피'를 뚫어낸 방법

1. GPU는 빠른데 로봇은 왜 느릴까?

2. rosidl::Buffer 아키텍처와 AI 에이전트의 역할

CPU 바운더리를 깨부수는 CUDA 버퍼 백엔드

AI 에이전트 기반의 영리한 마이그레이션 파이프라인

3. 기존 방식 대비 비교 분석 및 실무 고려사항

제로카피의 달콤함 뒤에 숨은 물리적 제약 조건

하이브리드 파이프라인에서의 오버헤드 저울질

4. 마치며

참고 자료 (References)

엔비디아가 옴니버스 NuRec으로 푼 자율주행 최대 난제: 신형 차량 나올 때마다 데이터 다시 안 찍어도 되는 이유

1. 데이터 수집의 악순환을 끊다: NuRec의 등장 배경

2. 아키텍처 및 핵심 메커니즘 딥다이브

3D 가우시안 스플래팅(3DGS)과 노벨 뷰 합성

신경망 렌더링의 구원투수: NVIDIA Harmonizer

3. 기존 방식 대비 비교 분석 및 실무적 한계

현업에서 마주할 진짜 한계점: '가려짐(Occlusion)의 복원'

4. 마치며

참고 자료 (References)

테슬라 옵티머스 쫓는 UBTECH의 역발상: 세계 최초 '1만 대 양산' 휴머노이드 스마트 팩토리가 바꿀 로봇 생태계 판도

1. UBTECH의 1만 대 양산 선언과 Walker S2 스마트 팩토리

2. 현업 엔지니어가 분석한 '로봇 제조 자동화'의 아키텍처

엔드투엔드 정밀 캘리브레이션과 테스트 자동화

모듈러 하드웨어 아키텍처와 분산 제어

3. 기존 방식 대비 비교 분석 및 실무 고려사항

하드웨어 공차 누적과 액추에이터 균일성 확보의 한계

공급망(Supply Chain)과 조립 공정의 병목 현상

4. 마치며

참고 자료 및 공식 영상 (References)

우버부터 웨이모까지, 글로벌 로보택시 기업들이 NVIDIA Blackwell과 Thor를 선택한 이유

1. 글로벌 로보택시 생태계를 장악한 NVIDIA의 '3-Computer' 전략

2. VLA 모델과 인-카 컴퓨팅: 현업 엔지니어가 보는 기술적 핵심

메타 액션(Meta Action)과 생각의 사슬(Chain-of-Thought)이 만드는 차이

NVIDIA Cosmos와 월드 파운데이션 모델의 파괴력

3. 기존 방식 대비 비교 분석 및 실무 고려사항

실무 엔지니어로서 고민해봐야 할 지점들

4. 마치며

참고 자료 (References)

테슬라와는 왜 다를까? 모빌아이 수퍼비전(SuperVision™)의 하이브리드 아키텍처와 B2B 영상의 노림수

1. Mobileye SuperVision™ 미국 중부 실증의 핵심 요약

2. 현업의 시각에서 본 아키텍처의 비밀

REM(Road Experience Management)을 통한 '가벼운 맵'의 힘

RSS(Responsibility-Sensitive Safety) 안전 모델의 개입

3. 전통적 E2E 모델과의 실무적인 차이점

4. [인사이트 논평] 왜 모빌아이는 해설 한 줄 없는 '날것의 주행 영상'만 올릴까?

① 테슬라의 팬덤 마케팅(B2C) vs 완성차 OEM을 향한 무편집 검증서(B2B)

② 상하이 → 뮌헨 → 미국 중부: 글로벌 3대 대륙 격전지 순회 전략

③ "설명이 필요 없다"는 엔지니어링 프라이드

5. 마치며

참고 자료 및 공식 영상 (References)

하이퍼바이저 위에서 구현하는 Mixed Criticality: AGL SoCDev 플랫폼의 아키텍처와 실무적 과제

1. AGL SDV-EG가 제시하는 자동차 소프트웨어 패러다임의 전환

2. AGL SDV 레퍼런스 플랫폼 아키텍처의 핵심 기술

VirtIO 기반의 가상 디바이스 표준화

Unified HMI를 통한 이기종 도메인 화면 통합

초경량 MQTT와 차량-클라우드 간 실시간 데이터 루프 구성

3. 기존 방식 대비 비교 분석 및 실무 고려사항

2. `rosidl::Buffer` 아키텍처와 AI 에이전트의 역할