자동차에서 차선을 따라가던 모델을 IRON의 손가락 motor에 연결하거나 플라잉카의 flight controller에 그대로 넣을 수는 없다. XPeng이 말하는 ‘동일한 피지컬 AI’의 재사용 단위는 제품 전체가 아니라 Turing AI chip, 표현학습, training infrastructure와 일부 VLA 계층이다.
성공 데모는 공통 stack의 가능성을 보여 준다. 실제 배치에서는 센서 좌표, 행동주기, actuator, 위험의 크기와 data 권리가 몸체마다 달라진다. 공유층이 넓을수록 transfer speed는 빨라지지만, 잘못된 assumption이 여러 제품으로 동시에 번지는 common-mode failure도 커진다.
네 몸체가 같은 무대에 선 장면
XPeng의 2025 Physical AI 발표는 2세대 VLA, Robotaxi, 새 IRON과 flying car를 한 제품체계로 소개했다. 자동차·Robotaxi에는 주행용 perception·decision이, IRON에는 VLT·VLA·VLM 조합과 Turing chip이, flying car에는 별도 aviation system이 등장한다. 회사가 한 ecosystem으로 부른다는 사실과 실제 software binary가 같다는 주장은 다르다.
2026년 공식 update는 Robotaxi의 도로시험·양산 prototype, IRON 생산기지와 flying car 생산 계획을 서로 다른 일정으로 전한다. 어느 한 제품의 ‘양산’ 표현을 다른 제품의 고객 인도 증거로 옮기지 않는다. stack map에는 product, version, current deployment와 roadmap을 각각 기록한다.
공통층 후보는 chip ISA·toolchain, training compute, data engine, large model backbone, simulation과 developer SDK다. product-specific 층은 sensor head, state estimator, planner constraints, real-time controller, safety monitor와 certification evidence다.
센서가 같지 않으면 세계 표현도 달라진다
자동차 camera는 차선·신호·차량을 긴 거리에서 보고 vehicle ego-motion을 추정한다. humanoid는 손목 camera, joint encoder, force·tactile과 근거리 가림을 다룬다. flying car는 고도·airspeed·attitude, GNSS·IMU와 aviation weather가 중요하다. 공통 vision backbone이 있어도 observation schema와 calibration은 새로 닫아야 한다.
Robotaxi와 일반 승용차도 동일하지 않다. 무인 fleet는 redundant hardware, remote operation, rider support가 추가되고 주행 ODD가 다르다. XPeng은 GX 기반 Robotaxi 공식 발표에서 4개 Turing chip, 3,000 TOPS, 2세대 VLA와 공개도로 L4 시험을 밝혔다. 이 사양은 IRON의 3-chip 2,250 TOPS와 섞지 않는다.
sensor uncertainty의 공통 interface는 confidence 하나가 아니다. timestamp, coordinate frame, missing-data flag, calibration version과 OOD indicator가 필요하다. 자동차의 confidence threshold를 robot hand의 contact uncertainty로 복사하면 숫자 범위만 같고 의미는 다를 수 있다.
모델 전이는 행동공간에서 먼저 깨진다
VLA는 observation과 language goal을 action에 연결하지만 action token의 의미는 몸체마다 다르다. steering·acceleration, footstep·joint trajectory, rotor thrust는 update rate와 stability margin이 다르다. shared backbone 위에 embodiment adapter와 skill library를 두고, output constraint를 product-specific safety layer가 제한한다.
IRON에 소개된 VLT는 robot task와 motion을 위한 별도 계층으로 설명된다. 이는 cross-product stack이 완전히 하나가 아니라는 단서다. language·vision representation은 공유하더라도 locomotion·manipulation model과 actuator control은 humanoid data로 학습·검증한다.
model error가 공통 backbone에서 나왔는지 adapter·controller에서 나왔는지 알려면 trace가 필요하다. input frame, model hash, intermediate state, proposed action, safety clamp와 actual motion을 보존한다. 제품 간 data를 섞을 때 source license와 고객 consent도 label로 붙인다.
제어 응답은 몸체의 시간상수에 맞춰야 한다
차량은 수십 m 앞 경로를 계획해 steering·brake로 따르고, humanoid는 수 ms 단위 balance와 contact를 유지해야 한다. 비행체는 attitude loop 안정성을 잃으면 즉시 큰 위험이 생긴다. large model의 출력 지연과 jitter budget을 outer-loop goal, mid-level planner, inner deterministic controller에 배분한다.
XPeng이 Robotaxi의 VLA latency를 80ms 이하라고 회사 자료에서 밝힌 것은 road decision pipeline에 관한 사양이다. IRON balance loop나 flying control loop의 허용 지연으로 사용할 수 없다. TOPS도 effective workload, memory bandwidth와 thermal limit가 다르면 직접 성능 비교가 되지 않는다.
shared SDK는 skill request와 telemetry schema를 통일할 수 있다. 그러나 stop, degraded mode와 human takeover의 의미는 제품별로 정의한다. 자동차의 minimal risk stop, humanoid의 stable sit·power isolation, flying car의 contingency landing은 같은 API 이름 아래 다른 acceptance test를 가져야 한다.
공통 chip도 하드웨어 한계는 다르게 만난다
Turing chip을 여러 제품에 쓰면 compiler, model optimization과 procurement를 재사용할 수 있다. 동시에 온도, 진동, 전력, cooling, redundancy와 lifecycle 요구가 달라 package·board·qualification이 분기된다. 자동차-grade 주장이 aviation certification이나 robot human-contact safety를 자동 충족하지 않는다.
IRON 전 체인 생산기지 발표는 onboard compute와 3개 Turing chip 구성을 제시하고, Robotaxi 발표는 네 개 chip의 redundancy와 큰 compute를 강조한다. flying car는 mass·power와 airworthiness가 더 강한 constraint가 될 수 있다. 같은 silicon 이름보다 board topology, failover, watchdog와 validated software configuration을 확인한다.
공급망 변경도 common-mode risk다. chip revision이나 compiler bug가 여러 body에 퍼지면 동시에 회귀시험해야 한다. product별 release calendar와 공통 component impact board를 운영해 하나의 update가 어디까지 배치됐는지 추적한다.
안전정지는 제품마다 다른 물리 행동이다
cross-product model이 모르는 장면을 만났을 때 행동을 멈추는 것은 필요하지만 ‘멈춤’ 자체가 항상 안전하지는 않다. 도로 한가운데 급정지, humanoid의 불안정 자세 정지, 비행체의 thrust cut은 위험을 키울 수 있다. uncertainty 신호를 각 몸체의 controlled safe state로 변환한다.
| 몸체 | 모르는 상태 | 안전 반응 후보 | 합격 증거 |
|---|---|---|---|
| 승용차·Robotaxi | 도로·object·localization OOD | 감속·안전한 위치 정지·지원 | 충돌회피·정지거리·승객 안내 |
| IRON | contact·balance·task ambiguity | 하중 해제·안정자세·power 제한 | 낙상·협착 방지와 사람 인계 |
| 플라잉카 | navigation·weather·propulsion anomaly | contingency route·착륙 절차 | airworthiness 범위의 flight test |
| 공통 cloud·model | bad update·data drift | roll back·deployment freeze | 제품별 known-good version 복구 |
표의 안전반응은 설계 예시이지 XPeng의 공개 인증 결과가 아니다. 실제 vehicle manual, aviation approval와 robot risk assessment에서 target state와 책임자를 확인해야 한다. 공통 model이 같은 OOD flag를 내더라도 final actuator command는 independent safety controller가 제한한다.
재시험은 공유층과 몸체층을 교차한다
공통 model을 바꾸면 모든 제품의 representation·reasoning regression을 돌리고, 각 body adapter·controller의 실물 anchor test를 수행한다. IRON hand만 바꾸면 automobile 전체 주행시험을 반복할 필요는 없지만 shared compiler·model interface가 바뀌지 않았다는 evidence가 필요하다.
- chip·compiler·foundation model·cloud·SDK 중 실제 공통 component를 version으로 식별한다.
- sensor·coordinate·action schema와 safety controller는 body별 contract로 둔다.
- shared update에 대해 자동차·Robotaxi·IRON·flying car 영향 matrix를 만든다.
- product data의 license·privacy·quality와 cross-use 허용 범위를 기록한다.
- TOPS·latency·양산 표현은 제품별 사양과 배치 상태로 분리한다.
- OOD에서 몸체별 controlled safe state와 human escalation을 실물 시험한다.
- roadmap 기능은 해당 제품의 고객 배치가 확인될 때까지 현재 기능으로 쓰지 않는다.
공통 피지컬 AI의 성과는 네 제품이 같은 이름을 쓴다는 데 있지 않다. 검증된 shared component가 개발시간을 얼마나 줄였고, 몸체별 failure가 다른 제품으로 전파되지 않도록 interface와 safety case를 얼마나 잘 분리했는지가 더 강한 증거다.
현장에서 다시 확인할 질문
자동차 모델을 humanoid에 재사용할 때 가장 먼저 깨지는 것은 무엇인가요?
대개 행동공간과 시간주기다. 도로의 steering·brake token은 joint·contact action과 의미가 다르고 balance loop는 훨씬 빠르다. vision·language representation과 training infrastructure는 재사용할 수 있어도 embodiment adapter, controller, sensor calibration과 safety test는 새로 필요하다.
공통 모델이 잘못된 판단을 하면 네 제품을 모두 멈춰야 하나요?
영향범위를 먼저 확인한다. shared model·compiler defect이면 관련 product release를 동결하고 known-good version으로 되돌린다. body-specific adapter 문제라면 해당 제품만 격리할 수 있다. 다만 공통 component가 영향 없다는 판단도 hash·interface·regression 증거로 남겨야 한다.
자료 마지막 확인: 2026년 8월 26일