AWS 환경에서 Physical AI 모델 구축하기 – (1) 데이터

Physical AI는 텍스트를 생성하던 AI가 물리 세계에서 직접 인식하고, 추론하고, 행동하는 단계로 넘어가는 흐름을 뜻합니다. 휴머노이드 로봇부터 자율주행까지 응용은 빠르게 늘고 있지만, 실제로 만들어 내려면 대규모 멀티모달 데이터, 막대한 학습 연산, 고정밀 시뮬레이션, 그리고 이 모든 것을 실제 동작으로 잇는 오케스트레이션까지 새로운 파이프라인이 필요합니다.

이 시리즈는 Physical AI를 뒷받침하는 핵심 기술과 그 과정의 챌린지를 먼저 이해하고, 이를 AWS 환경에서 어떤 서비스로 구축할 수 있는지 단계별로 살펴봅니다. 시리즈는

1부 – 데이터
2부 – 학습
3부 – 시뮬레이션
4부 – 에이전트 오케스트레이션

1. 들어가며

1.1 성능을 제한하는 것은 모델이 아니다

OpenVLA 논문에 의하며 7B 파라미터로 970k개 실로봇 데모를 학습해서, 55B 규모의 RT-2-X를 29개 태스크에서 성공률 16.5%p 앞섰습니다. 모델의 파라미터는 8분의 1이 안 됩니다. Xiaomi-Robotics-1는 10만 시간 이상의 manipulation trajectory로 pre-training을 수행했는데, 여기에서 결정적인 요소는 하드웨어가 아니라, trajectory clip에 장면 변화를 자연어로 라벨링 하는 auto-labeling파이프라인이었습니다. 연구를 위한 실험 뿐만 아니라, 실제로 한 로봇 회사에서는 VLA의 학습 분포 밖에서의 성공률(OOD, out-of-distribution)이 8.3%에서 75.0%로 향상되었는데, 이 때 모델 아키텍처는 그대로였고 바뀐 것은 학습 데이터 뿐이었습니다. 기존 학습 데이터에 새로운 조명과 표면 조건으로 재렌더링해서 데이터를 증강시킨 것이 전부입니다.

여기에서 알 수 있는 점은, Physical AI 에서 모델의 성능을 제한하는 것은 모델 아키텍처가 아니라 데이터의 문맥성(contextual grounding)과 그것을 학습시키는 레시피에 있다는 것입니다.

1.2 업계는 이 문제를 어떻게 풀고 있는가

데이터가 성능의 상한을 정한다는 판단은 Physical AI를 이끄는 기업들의 최근 행보에서도 공통으로 확인됩니다. 각 회사가 데이터 문제에 집중하고 있고, 그 접근 방식도 수렴하고 있습니다.

NVIDIA는 휴머노이드 파운데이션 모델 GR00T N1의 학습 데이터를 피라미드로 설명합니다. 웹에서 얻을 수 있는 비디오 영상, 시뮬레이션과 생성 모델이 만든 합성 데이터, 실제 로봇에서 수집한 데이터, 이렇게 세 가지 계층을 나눠 함께 학습에 사용합니다. 실로봇 데이터는 품질이 가장 높지만 양이 가장 적으므로, 합성 데이터나 영상 데이터로 규모를 보완하는 구조입니다.

Figure는 2025년 9월 Project Go-Big을 발표하고, 부동산 자산운용사 Brookfield와의 파트너십으로 주거/상업 공간에서 ego-centric(1인칭 시점) 인간 영상을 대규모로 수집하고 있습니다. 로봇을 조종해서 모으는 데이터만으로는 규모가 나오지 않으니, 사람이 일상적으로 움직이는 영상을 로봇 학습의 사전학습 데이터로 쓰겠다는 접근입니다. Figure의 발표에 따르면, 자사 VLA 모델 Helix는 이 영상 데이터만으로 내비게이션을 학습했습니다.

Google DeepMind의 Gemini Robotics 1.5는 서로 다른 로봇(embodiment) 간에 학습된 동작을 이전하는 motion transfer를 핵심 기능으로 내세웁니다. 로봇 한 기종에서 모은 데이터가 다른 기종의 학습에도 쓰일 수 있게 해서, 기종마다 데이터를 처음부터 다시 모아야 하는 비용을 줄이려는 시도입니다. Physical Intelligence는 1만 시간 이상의 로봇 데이터로 사전학습한 모델 체크포인트를 공개해, 소규모 팀이 사전학습 데이터 수집 없이 파인튜닝부터 시작할 수 있게 제공합니다.

정리하면, 선두 기업들은 실로봇 데이터의 수집 한계를 전제로 받아들이고, 인간 영상/합성 데이터/기종 간 이전/사전학습 공유로 그 한계를 우회하는 데 힘쓰고 있습니다. 이 글에서 다룰 데이터 전략과 파이프라인 설계는 이 흐름을 따라갑니다.

1.3 LLM의 학습 데이터와 다른 점

Physical AI를 처음 클라우드에 올릴 때 흔한 실수가 LLM 파이프라인을 그대로 가져오는 것입니다. 코퍼스를 모아, GPU 클러스터에서 학습하고, 클라우드의 엔드포인트로 서빙하는 그림이죠. 큰 틀은 비슷하지만, 학습 데이터의 성격이 근본적으로 다릅니다.

멀티모달/시간 정렬 데이터: 텍스트 토큰은 순서만 맞으면 되지만, 로봇 데이터는 카메라 영상/힘/토크/관절 상태/언어 지시 등 여러 스트림을 하나의 시간축에 정렬해야 합니다. 스트림 간 100ms 수준의 어긋남만으로도 모델이 잘못된 인과관계를 학습할 수 있습니다.
행동이 라벨링된 데이터: LLM은 다음 텍스트 토큰만 예측하면 되지만, Physical AI 데이터에는 관측과 함께 실제 실행 가능한 행동(연속 제어값/이산 행동 토큰)이 라벨로 붙어야 합니다. 행동 라벨 없는 관측만으로는 정책을 직접 학습할 수 없습니다.
인터넷에서 스크랩 할 수 없는 데이터: 웹 텍스트와 달리 로봇 궤적은 인터넷에 존재하지 않습니다. 타겟 embodiment의 하드웨어에서 직접 수집해야 하고(텔레오퍼레이션은 궤적 하나에 수 분의 숙련 조종 시간이 듭니다), 그래서 데이터 양이 사람의 수집 시간에 선형으로 묶입니다. Physical AI의 병목이 연산이 아니라 데이터인 이유입니다.

바로 이 차이 때문에 LLM 파이프라인을 그대로 가져다 쓸 수 없습니다. 데이터 자체가 다르기 때문에 데이터 수집부터 처리, 학습, 서빙까지, 이후 파이프라인이 달라집니다. 이러한 데이터를 처리하기 위한 특화된 시스템과 기법들이 필요합니다.

2. Physical AI 모델의 구성 요소와 데이터 유형

2.1 Physical AI 모델의 구성 요소

수집할 데이터를 정하려면 먼저 시스템을 이해해야 합니다

그림 1. Physical AI 모델의 네 가지 구성 축

Model (perception → action): 관측을 액션으로 바꾸는 함수 (어떤 모델 계열을 쓰는가)
Embodiment: 액션이 실행되는 몸 (액션 공간, 제어 주기, 센서 구성)
Training: 그 함수를 어떻게 학습시키는가 (pre-training, post-training, RL 단계)
Data & Simulation: 학습 신호가 어디서 오는가 (실측, 합성, 증강)

네 축은 독립적이지 않고 서로 연관되어 있습니다. Embodiment가 정해지면 액션 공간이 따라오고, 액션 공간이 정해지면 데이터 포맷을, 데이터 포맷은 학습 레시피를 제약합니다. 이는 역방향도 마찬가지입니다. embodiment 제어 주기에 따라 모델 크기의 상한을 정하고, 그 상한에 따라 어떤 모델 계열을 쓸 수 있을지 선택을 좁힐 수 있습니다.

특히 데이터 축과 모델 축이 만나는 지점에서 중요한 갈래가 생깁니다. Physical AI가 학습하는 데이터가 두 종류이므로, 모델도 두 갈래로 나뉩니다.

Policy Model — 관측-액션 쌍으로 이뤄진 시연 데이터에서 학습합니다. “어떤 관측에서 어떤 액션을 해야 하는가”를 익히는, 행동 주체(로봇 자신)의 디지털 트윈입니다. 관측을 곧바로 액션으로 매핑하므로 즉각적인 행동 결정에 강합니다.
World Model — 상태-액션-다음 상태 전이(transition)를 학습합니다. “어떤 액션이 세계를 어떻게 바꾸는가”를 예측하는, 환경(세계)의 디지털 트윈입니다. 장기 플래닝과 행동 결과 예측에 강하고, 합성 데이터 생성이나 시뮬레이션 환경으로도 쓰입니다.

이 두 갈래에서 VLA(Vision-Language-Action), WFM(World Foundation Model), WAM(World Action Model) 같은 모델이 파생됩니다. 대체로 VLA는 policy 계열(관측→액션)에, WFM은 world 계열(세계 예측/생성)에 가깝고, WAM은 world model에 액션을 결합해 둘을 잇습니다. (각 모델에 대한 설명은 2편에서 다룹니다.) 어떤 모델을 고르느냐에 따라 모아야 할 데이터가 달라지므로, 데이터 수집에 앞서 이 선택이 먼저입니다.

2.2 Physical AI 모델의 데이터 유형

그림 2. Physical AI 모델을 위한 학습 데이터 피라미드 – 품질과 규모의 트레이드오프

Physical AI 모델을 학습시키는 데이터는 크게 세 종류로 나뉩니다.

실제 데이터(Real-world data): 로봇이 실제 환경에서 수집한 데이터입니다. 액션 라벨이 정확하고 타겟 로봇과의 정합이 완전해서 품질이 가장 높지만, 사람의 조종 시간이 그대로 비용이 되므로 대량으로 확장하기 어렵습니다.
합성 데이터(Synthetic data): 시뮬레이션 또는 월드 모델로 생성한 데이터입니다. 비교적 쉽게 대량 생성할 수 있어 확장성이 뛰어나지만, 실제 데이터와의 분포 차이(sim2real 격차)를 관리해야 하고, 생성과 렌더링에 상당한 GPU 연산이 듭니다.
인터넷 데이터(Internet data): 웹 비디오와 인간 영상입니다. 양이 가장 풍부하고 다양성이 가장 높지만, 텍스트/이미지/영상에는 힘이나 촉각 같은 물리적 접촉 정보와 액션 라벨이 없어서, 로봇의 실제 조작(Manipulation) 능력을 키우는데 직접적인 도움이 되지 않습니다.

접근성과 품질, 확장성이 서로 상충하기 때문에 어느 한 종류만으로는 학습이 완성되지 않습니다. 결국 Physical AI 모델을 제대로 학습시키려면 세 가지 데이터를 목적에 맞게 조합하는 전략이 필요합니다.

2.3 AWS의 dual-path 전략

AWS는 디지털 트윈 구축을 두 개의 루프, 그리고 이 둘을 잇는 데이터 계층으로 정의합니다. 시뮬레이션 루프에서 합성 데이터를 대량 생성해 빠르고 안전하게 정책을 학습하고, 실세계 루프에서 배포된 로봇이 실제 센서 피드백을 수집합니다.

그림 3. AWS의 dual-path 전략 — Physical World와 Digital World의 연결

핵심은 이 두 루프가 단절되지 않는다는 점입니다. 실세계에서 모인 데이터가 시뮬레이션의 물리 파라미터와 렌더링을 보정하고, 보정된 시뮬레이션이 더 현실에 가까운 합성 데이터를 산출합니다. 두 루프가 데이터와 정책을 주고받으며 서로의 품질을 끌어올리는 데이터 플라이휠을 구성합니다.

그림 4. 시뮬레이션 루프 / 실세계 루프 / 데이터 계층의 연결

시뮬레이션 루프: Isaac Sim으로 환경(USD 장면)을 구성하고, Isaac Lab으로 수천 개의 병렬 환경을 통해 RL 정책을 학습하거나, 시뮬레이션 합성 데이터를 대량으로 생성합니다. 학습된 모델은 시뮬레이션 환경에서 평가하고, 평가 데이터를 기반으로 시뮬레이션 시나리오를 보강하며 반복 학습합니다.
실세계 루프: 로봇이 시뮬레이션에서 학습된 정책으로 추론하면서 카메라/자이로스코프/힘/접촉/조인트 엔코더 등 센서 데이터를 수집합니다.
데이터 계층 (큐레이션/증강): 실세계 루프에서 모인 데이터를 데이터 레이크에 메타데이터와 함께 쌓고, 학습용으로 사용하기 위해 정제/라벨링/필터링합니다. 핵심은 실데이터를 그대로 쓰는 데 그치지 않고, 모델로 기존 에피소드를 변형/확장하는 생성형 증강으로 데이터셋을 시뮬레이션 루프의 RL 학습과 엣지 배포용 post-training에 함께 공급합니다. 현장에서 드리프트가 감지되면 다시 이 계층으로 들어와 큐레이션/증강이 반복됩니다.

이 구조에서는 배포 규모가 곧 데이터 수집 규모가 됩니다. 로봇을 한 대 더 배포할수록 실세계 루프로 들어오는 데이터가 늘고, 그 데이터가 다시 시뮬레이션 보정과 재학습 품질을 끌어올립니다.

3. 수집 데이터의 구조와 비용

2장에서 시스템 축과 데이터 유형을 정의했습니다. 이제 실제로 한 에피소드에 어떤 모달리티가 담겨야 하는지, 시간 정렬은 왜 중요한지, 그리고 다양성 확보 비용을 어떻게 통제할 수 있는지를 다룹니다.

3.1 관측값만으로는 학습이 되지 않는다

전통적으로 로봇 데이터는 (관측, 액션) 쌍의 모음이었습니다. 그러나 이 구조만으로는 새로운 환경이나 물체에 일반화하기 어렵고, 분포 밖 상황에서 정책이 급격히 실패합니다.

π₀.₅는 여기에 언어 명령, 객체 탐지, 의미적 하위 태스크 예측을 결합한 co-training으로 이 한계를 넘었습니다. 이때 object detection과 semantic subtask prediction은 부가 정보가 아니라 일반화의 핵심 매개로 작용합니다. 그 결과 π₀.₅는 학습에 없던 완전히 새로운 집에서 주방/침실 청소 같은 long-horizon dexterous 작업을 수행한 첫 사례를 만들었습니다.

그래서 하나의 학습 샘플에는 센서 관측값(RGB, 깊이, 고유감각)과 액션 외에 언어 지시, 객체의 3D bounding box, 의미적 하위 태스크 분해(접근 → 파지 → 이동 → 해제), affordance가 함께 담겨야 합니다.

3.2 수집 대상이 되는 모달리티

가장 보편적으로 사용되는 멀티모달 센서 데이터는 아래와 같습니다 .

RGB 카메라: 가장 보편적인 비전 센서입니다. 다만 현재 VLA 벤치마크가 RGB 입력에 과도하게 편향돼 있다는 비판도 있습니다.
깊이(Depth)/LiDAR: 3D 기하 구조를 파악하게 해줍니다. RGB와 LiDAR를 융합하면 깊이와 텍스처가 결합돼 객체 검출이 크게 좋아집니다.
촉각(Tactile)/힘/토크(Force/Torque): 접촉 상태/슬립/마찰/하중 분배처럼 광학 센서로는 알 수 없는 상호작용 단서를 제공합니다.
고유감각(Proprioception)/IMU: 관절 위치/속도/토크 같은 내부 상태입니다. 텔레오퍼레이션 시 카메라 관측과 반드시 동기화해 기록해야 합니다.
이벤트 카메라(Event Camera): 밝기가 변한 픽셀만 비동기로 출력해, 초고속 동적 장면에서도 모션 블러 없이 동작합니다.

위에서 설명한 것과 같이 이러한 센서 데이터를 포함하여, 인식(perception) 데이터는 제어/의사결정과 긴밀하게 결합된 공동설계(co-designed) 컴포넌트로 자리잡고 있습니다.

모달리티	전형적 주기	왜 필요한가	없으면 생기는 실패
다중 시점 RGB (오버헤드 + 손목 ×2 동기화)	30~60 fps	Occlusion 해소, 뷰 간 3D 정합	뷰 간 불일치로 액션 라벨 무효화
깊이 / metric point cloud	10~30 fps	거리/평면 구조 이해	접근 거리 오판, 배치 실패
고유감각 / joint state	100~1000 Hz	현재 상태 기술, embodiment 정합	액션 공간 불일치, 충돌
힘 / 촉각	100~1000 Hz	시각적으로 모호한 접촉 이벤트 구분	버튼 반복 누름 같은 작은 반복 동작에서 실패
자연어 지시 + 하위 태스크 분해	에피소드당 1~수 회	의미 조건화	지시 일반화 실패
객체 감지 / 3D bbox / pointing / grasp	프레임 단위 (파생)	공간 grounding	새로운 물체 배치에 취약
Affordance (approach direction, contact geometry, dwell time, retreat vector — 클래스당 약 12개 수치값)	에피소드/객체 단위 (파생)	상호작용 사전지식	비현실적 파지, 접촉 실패

한 에피소드에는 카메라(30~60fps), 조인트 엔코더(100~1000Hz), 힘/토크 센서, 언어 지시문까지 서로 다른 데이터가 서로 다른 주기로 들어옵니다. 이 비동기 스트림을 timestamp 기준으로 정렬해야 비로소 하나의 학습 샘플이 됩니다. 정렬이 깨지면 액션 라벨과 관측 사이에 시간 오차가 생겨 학습 데이터가 오염되는데, 타임스탬프 오류는 사후 복구가 어렵기 때문에 엣지에서 수집하는 시점에 정확히 정렬해 기록해야 합니다.

그림 5. 에피소드 내 다중 스트림의 시간 정렬

주기 차이는 인제스트 설계에도 직결됩니다. 영상은 대역폭을 지배하고, 고빈도 텔레메트리는 요청 수를 지배합니다. 한 경로에 몰면 한쪽에 맞춘 설정이 다른 쪽을 망치므로, 인제스트는 모달리티별로 분리합니다.

3.3 수집 비용은 다양성에 비례한다

텔레오퍼레이션 데이터는 정확한 action 라벨과 타겟 embodiment 정합 덕분에 가장 신뢰도 높은 소스로 여겨지지만, 수집 비용이 비싸고 다양성이 제한적입니다. 대규모 데이터셋을 구축할 때에는 같은 태스크에 대한 데이터를 수집할 때에도, 새로운 표면/조명/물체 조합마다 추가 녹화가 필요합니다. 학술 데이터셋도 사정이 비슷합니다. DROID는76,000개 궤적(약 350시간)을 확보하려고 564개 씬, 86개 태스크, 50명의 수집자, 13개 기관, 3개 대륙에 걸쳐 12개월을 투입했습니다. 실로봇에서 얻는 텔레오퍼레이션 데이터는 사람이 직접 조종해 수집하므로, 수집 시간이 수집량에 비례해 선형으로 늘어납니다.

이 한계 때문에 업계는 데이터를 “수집”하는 것을 넘어 “만들어내는” 방법을 발전시켜 왔습니다. 3.4에서 그 패턴들을 하나씩 살펴봅니다.

3.4 데이터를 만들어내는 다섯 가지 패턴

데이터를 확보하는 방법은 텔레오퍼레이션이 기본이지만 필요에 따라, 액션 라벨의 정밀도, 타겟 로봇과의 정합, 다양성, 비용 등의 트레이드 오프에 따라 데이터를 확보하는 전략을 추가할 수 있습니다.

3.4.1 텔레오퍼레이션: 기본 데이터 수집 방법

그림 6. 컨트롤러를 이용한 텔레오퍼레이션

사람이 컨트롤러나 모션 캡처 장비로 로봇을 직접 조종하고, 그 순간의 관측과 조종 입력을 함께 기록합니다. 사람의 조작이 그대로 액션 라벨이 되므로 라벨은 ground truth이고, 데이터가 타겟 로봇의 하드웨어에서 나오므로 embodiment 정합도 완전합니다. 접촉이 많은 정밀 조작(force/tactile 데이터가 필요한 태스크)에서는 사실상 대체재가 없습니다.

그림 7. VR을 이용한 텔레오퍼레이션

문제는 확장입니다. 궤적 하나에 숙련 조종자의 수 분이 들고, 새로운 조명/표면/물체 조합마다 추가 녹화가 필요하므로 비용이 다양성에 선형으로 비례합니다. 그래서 텔레오퍼레이션으로 모든 데이터를 모으긴 어렵고, 잘 취득된 데이터를 기반으로 다른 패턴의 데이터 품질을 검증하는 기준점이자 최종 post-training 용으로 쓰는 것이 현실적입니다.

3.4.2 시뮬레이션 합성 데이터: 물리 엔진에서 대량 생성

그림 7. 시뮬레이션 환경 내의 합성 데이터 증강 (Source: OpenAI, https://openai.com/index/solving-rubiks-cube)

실세계 씬을 3D로 재구성해 시뮬레이션에 옮긴 뒤, 그 안에서 합성 데이터를 대량 생산합니다. 시뮬레이터는 모든 상태를 알고 있으므로 액션 라벨과 물체 위치, 접촉 여부까지 완전한 ground truth를 얻을 수 있습니다. 물체 배치/조명/마찰계수를 코드로 구현할 수 있어서 다양성도 프로그래밍 영역만큼 확장됩니다(domain randomization). 초기에는 디지털 트윈 구축에 많은 시간이 발생하지만, 구축된 이후에는 빠르게 데이터를 대량 생성할 수 있다는 점이 이 패턴의 강점입니다.

여기에서 고려할 점은 Sim-to-Real 갭입니다. 시뮬레이터의 물리와 렌더링이 실세계와 다른 만큼, 시뮬레이션에서 잘 되던 정책이 실세계에서는 실패할 수 있습니다. 그래서 이 패턴은 2.3의 dual-path 구조처럼 실측 데이터로 시뮬레이터를 계속 보정하는 루프와 함께 운영해야 합니다. NVIDIA의 Isaac Sim/Isaac Lab이 이 패턴의 대표 솔루션이고, 병렬 환경 수천 개를 GPU에서 동시에 실행하는 방식으로 규모를 확장할 수 있습니다.

3.4.3 생성형 AI를 활용한 합성 데이터: 기존 데이터 증강

그림 8. 생성형 AI로 재생성한 합성 데이터 (월드모델 fine-tuning 전)

시뮬레이터를 만들지 않고, 이미 수집한 실로봇 에피소드를 생성 모델(월드 모델)로 재렌더링해 관측 분포를 넓힙니다. 새로운 조명/표면/배경으로 영상을 다시 생성하되 액션 라벨과 물체 배치는 원본 그대로 두므로, 라벨 정합과 embodiment 정합을 유지한 채 다양성만 삽니다. 추가 로봇 운용이 없어 비용 대비 효율이 가장 좋습니다.

그림 9. 생성형 AI로 재생성한 합성 데이터 (월드모델 fine-tuning 후)

문제는 일관성 입니다. 다중 카메라 에피소드에서 뷰를 따로 생성하면 서로 어긋나므로, 세 뷰를 하나의 모델이 동시에 생성하도록 생성 모델(예: NVIDIA Cosmos)을 멀티뷰로 파인튜닝하고 cross-view attention으로 뷰 간 합의를 강제합니다. 무엇을 바꾸고 무엇을 고정하느냐가 품질을 결정하며, 액션 라벨은 렌더링 단계에서 절대 건드리지 않고 물체 위치는 edge 추출로 고정하는 방식을 사용합니다. 최근에는 이미지로부터 영상을 생성하고 (image-to-video), 영상 프레임 시퀀스로부터 액션 궤적을 추정하여 액션 데이터를 라벨링(pseudo action label) 하는 모델도 발표되었습니다. 다만 합성 데이터 생성을 위해 월드 모델의 성능이 떨어지면 이는 데이터 품질 저하로 즉각적으로 이어집니다.

3.4.3 Egocentric Human Video (1인칭 사람 시점 영상): 사람의 시각을 데이터로 변환

헤드마운트 카메라로 촬영한 1인칭 사람 작업 영상을 로봇 학습에 씁니다. 사람은 로봇보다 압도적으로 빠르고 자연스럽게 움직이므로, 같은 시간에 수집되는 행동의 다양성이 텔레오퍼레이션과 비교가 되지 않습니다. Figure의 Project Go-Big이 이 전략의 대표 사례로, 인간 영상을 대규모 수집하여 인간 영상만으로 로봇 내비게이션을 학습시켰습니다.

한계는 두 가지입니다. 사람 손과 로봇 그리퍼는 구조가 다르므로 사람의 동작을 로봇 액션 공간으로 옮기는 retargeting(동작 재대상화)이 필요하고, 힘/촉각 정보가 없으므로 접촉 정밀도가 중요한 태스크에는 부족합니다. 그래서 이 패턴은 사전학습(다양한 상황에 대한 시각-행동 상식)에 쓰고, 정밀 조작은 소량의 텔레오퍼레이션 데이터로 post-training하는 조합이 일반적입니다.

3.4.5 웹 비디오: 라벨이 없는 최대 규모의 데이터

유튜브 같은 인터넷의 3인칭 영상입니다. 규모와 다양성은 비교 대상이 없지만, 액션 라벨도 없고 촬영 주체가 로봇도 아니므로, 다섯 패턴 중 가장 학습 품질이 낮은 데이터 유형입니다. 영상의 프레임 변화에서 “어떤 행동이 있었는지”를 잠재 변수로 추론하는 latent action 기법으로 학습 신호를 만들어야 합니다. 세계에 대한 시각적 상식을 넓히는 사전학습 용도로 씁니다.

3.5 데이터 소스 선택 기준

데이터 소스	액션 감독 정밀도	Embodiment 정합	다양성	비용 구조
텔레오퍼레이션 실로봇 (기준선)	최고 (ground truth)	최고 (동일 로봇)	낮음	다양성에 선형
시뮬레이션 합성 데이터	합성 ground truth (완전)	조정 가능	조정 가능	초선형 스케일 가능
생성형AI 합성 데이터	원본 유지 (라벨 보존)	높음 (원본 로봇 그대로)	중 (관측 분포만 확장)	낮음 (추가 로봇 불필요)
에고센트릭 인간 영상	낮음 (retargeting 필요)	낮음	높음	매우 낮음
액션 라벨 없는 웹 비디오	없음 (latent action 필요)	없음	최고	최저

각 데이터 소스 간 최적 비율은 아직 정답이 없는 영역이므로, 비율을 바꿔가며 소량으로 검증하는 절차를 학습 파이프라인에 넣어야 합니다. 태스크별로 비율을 조율하며 활용해야 합니다.

그림 8. 데이터 소스 선택 — embodiment 고정 여부와 라벨 자동화 가능성

패턴 선택의 축은 두 가지입니다. embodiment가 고정인가(고정이면 그 로봇에 특화된 데이터의 가치가 크고, 다양하면 embodiment에 덜 묶이는 소스가 유리합니다), 그리고 액션 정밀도와 실물 접근성이 어느 정도인가입니다. 접촉이 많아 정밀도가 임계적이면 힘/촉각을 갖춘 텔레오퍼레이션으로, 근사가 허용되고 실물 씬에 접근할 수 있으면 Real2Sim으로, 접근이 어려우면 생성형 증강으로 내려갑니다. embodiment가 다양한 경우에는 라벨 자동화가 가능하면 웹 비디오(latent action)로, 어려우면 에고센트릭 인간 영상(retargeting)으로 갈립니다.

각 데이터 소스 간 최적 비율은 아직 정답이 없는 영역으로, 단일 소스로 해결하기보다 태스크마다 여러 소스를 섞고, 비율을 바꿔가며 소량으로 검증하는 절차를 학습 파이프라인에 넣어야 합니다.

4. 데이터 파이프라인 구축

3장까지가 “어떤 데이터를 모을 것인가”였다면, 4장은 “모은 데이터를 어떻게 학습에 사용하는가”입니다. 로봇에서 GPU까지 데이터가 지나는 경로는 여섯 단계로 나뉘고, 단계마다 성격이 다른 문제에 부딪힙니다. 이 장은 각 단계에서 무엇이 왜 어려운지를 먼저 보고, 그 문제를 푸는 AWS 서비스 조합을 결정 기준과 함께 정리합니다.

그림 9. 데이터 경로 6단계

4.1 엣지 수집

로봇은 학습된 정책으로 추론하면서 동시에 다음 학습을 위한 센서 데이터를 수집해야 합니다. 두 작업이 같은 컴퓨트와 네트워크를 나눠 쓰는데, 추론은 실시간성이 깨지면 안 되고 수집은 데이터가 유실되면 안 됩니다. 게다가 3.2에서 본 것처럼 타임스탬프 정렬은 사후 복구가 어려우므로 수집 시점에 엣지에서 끝내야 하고, 현장 네트워크는 자주 끊긴다는 전제로 설계해야 합니다.

이 요구사항을 만족시키는 AWS 서비스가 AWS IoT Greengrass입니다. 모델/런타임/추론 코드를 컴포넌트로 묶어 로봇에 배포하고, 엣지에서 필터링/전처리를 거쳐 전송량을 줄이며, 네트워크 단절 시에는 Stream Manager가 로컬에 버퍼링했다가 재전송합니다. 카메라, 자이로스코프, 힘, 가속도계, 접촉, 조인트 엔코더 등 주요 센서를 다룰 수 있고, Greengrass v2에서는 ROS 2 노드를 실행해 rosbag을 S3로 올리는 패턴도 가능합니다.

Greengrass 특화 기능	내용
컴포넌트 모델	모델/런타임/추론 코드를 컴포넌트로 묶어 배포
로컬 처리	엣지에서 필터링/전처리 후 클라우드 전송 (대역폭 절감)
Stream Manager	네트워크 단절 시 로컬 버퍼링 후 재전송
처리 가능 센서	카메라, 오디오, 자이로스코프, 힘, 가속도계, 접촉, 조인트 엔코더, 위치, 압력
ROS 2	Greengrass v2에서 ROS 2 노드 실행 가능, rosbag → S3 패턴

다만 모든 경우에 Greengrass가 필요한 것은 아닙니다. 엣지 연산 없이 단순 텔레메트리만 보낸다면 AWS IoT Core 디바이스 SDK 직결이 더 가볍고, 컨테이너 워크로드를 엣지에서 오케스트레이션해야 한다면 Amazon ECS Anywhere/Amazon EKS Anywhere/Amazon EKS Hybrid Nodes를 고려해 볼 수 있습니다.

4.2 실시간 스트리밍

로봇에서 클라우드로 데이터를 올릴 때에는, 영상과 텔레메트리는 서로 다른 경로로 보내야 합니다. 30~60fps 영상은 초당 수십 MB의 대역폭을 요구하고, 100~1000Hz 조인트 상태는 개별 크기는 작지만 초당 수백~수천 건의 요청 수를 만듭니다. 하나의 파이프라인에 통합하면 비용과 지연 측면에서 문제가 발생합니다.

그래서 데이터의 성격에 따라 영상은 Amazon Kinesis Video Streams, 고빈도 센서는 Kinesis Data Streams, 저빈도 상태값은 IoT Core Basic Ingest로 3분할하고 모두 최종적으로 Amazon Simple Storage Service (Amazon S3)로 저장하는 구성이 학습 파이프라인과 가장 잘 맞습니다.

실시간 스트리밍 서비스 선택 기준

경로	서비스	이 경로를 쓰는 이유	더 단순한 대안
영상	Kinesis Video Streams	다중 카메라 피드를 시간 인덱스와 함께 보관, 저지연 원격조작은 WebRTC 모드	단순 스냅샷만 필요하면 S3 직접 업로드
고빈도 텔레메트리	Kinesis Data Streams	재생(replay)/순서 보장/다중 컨슈머가 필요한 조인트·IMU·힘 센서 스트림	단방향 적재만 필요하면 IoT Core
저빈도 상태값	IoT Core Basic Ingest	MQTT 메시지를 브로커를 거치지 않고 규칙 엔진으로 직접 라우팅하는 저비용 경로	재생/다중 컨슈머가 필요해지면 Kinesis로 상향
(선택) 적재 변환	Amazon Data Firehose	스트림을 버퍼링해 Parquet 등 학습용 컬럼 포맷으로 변환하며 S3 적재	초저지연 스트림 처리에는 부적합

실시간 스트리밍 서비스 구성

그림 10. 실시간 스트리밍 경로 — 영상과 텔레메트리를 분리

정리하면, 엣지에서는 IoT Greengrass를 통해 다양한 센서 데이터를 수집하고, 센서 데이터의 전송 주기/용량에 따라 각기 다른 서비스를 활용해, 서비스 병목이 발생하지 않도록 유지하며 클라우드로 안전하게 전송합니다.

4.3 온프레미스 데이터를 Bulk로 업로드

4.2절이 실시간으로 데이터를 올리는 경로였다면, 4.3 절은 이미 쌓인 데이터를 배치로 올리는 경로입니다. 카메라/LiDAR 원본은 실시간으로 올리기에는 너무 커서 대체로 온프레미스 엣지 컴퓨터에 하루/주 단위로 쌓이는데, 수집 규모가 커지면 데이터가 쌓이는 속도가 회선이 소화하는 속도를 넘어섭니다. 주로 embodiment 쪽에 직접 세팅되기 보다는 온프레미스에 위치한 엣지 컴퓨터에서 처리됩니다. 주당 반입해야 할 TB와 데이터가 학습에 쓰이기까지 허용되는 지연에 따라 선택할 수 있는 서비스가 달라집니다.

AWS DataSync: 온프레미스 스토리지와 AWS 사이에서 데이터를 자동/반복 전송하는 관리형 동기화 서비스입니다. NAS/랩 스토리지를 S3로 주기적으로 동기화하며 에이전트 배포가 필요합니다. 회선이 이미 있고 정기 동기화가 필요할 때의 기본 선택입니다.
AWS Direct Connect: 온프레미스와 AWS를 잇는 전용 네트워크 회선 서비스입니다. 인터넷을 우회한 전용선으로 지속적 대용량 전송에 쓰며, 반입이 상시화돼 인터넷 경로의 변동성이 문제가 될 때 적합합니다(회선 리드타임을 일정에 반영).
AWS Data Transfer Terminal: AWS의 물리 업로드 시설에 저장 장치를 직접 가져가 고속 반입하는 서비스입니다. 최대 400 Gbps로 S3/EFS 등 임의 엔드포인트에 시간당 예약 과금으로 올립니다. 데이터가 이동체에 실려 오고 회선 증설이 비합리적일 때 적합합니다 (Enterprise 고객 한정).
Amazon File Cache: 분산된 온프레미스 NFS나 S3를 단일 네임스페이스로 묶는 고속 임시 캐시 서비스입니다. 최대 8개 소스를 하나로 제시하며 Direct Connect/VPN을 경유합니다. 원본을 클라우드로 옮길 수 없지만 클라우드 컴퓨트로 처리해야 할 때 씁니다.
Amazon S3 File Gateway: 온프레미스에 NFS/SMB 파일 인터페이스를 제공하고 뒤에서 S3에 저장하는 하이브리드 스토리지 게이트웨이입니다. 기존 파일 기반 워크플로를 수정하지 않고 S3로 흘려야 할 때 적합합니다.
S3 Transfer Acceleration: S3 업로드를 엣지 로케이션을 경유해 가속하는 S3 기능입니다. 반입 지점이 대상 리전에서 지리적으로 멀 때 씁니다.

그림 11. 온프레미스 반입 경로 선택

4.4 데이터 레이크

반입된 데이터는 S3 데이터 레이크에 모읍니다. 데이터를 쌓는 것 자체는 어렵지 않지만, 3만 개 에피소드 중에서 “접촉에 실패한 에피소드만”, “특정 조명 조건의 실패 사례만” 골라내지 못하면 큐레이션도 재학습도 시작할 수 없습니다.

그래서 에피소드 원본 바이너리는 S3 객체로, 메타데이터/문맥 라벨은 카탈로그 테이블로 분리하면 위와 같은 질의를 SQL로 처리할 수 있습니다. 스토리지 비용은 Amazon S3 Intelligent-Tiering을 기본값으로 두면 접근 패턴에 따라 자동 최적화됩니다. 로봇 데이터는 최근 데이터의 중요도가 높고 과거 데이터의 중요도가 빠르게 낮아지므로 이 특성과 잘 맞습니다.

AWS Glue Data Catalog:데이터의 스키마/위치를 중앙에서 관리하는 메타데이터 카탈로그입니다. 에피소드 메타데이터를 자동으로 카탈로그화해 SQL로 질의 가능하게 만듭니다.
Amazon Athena: S3 데이터를 서버 없이 표준 SQL로 조회합니다. 큐레이션 질의를 인프라 없이 바로 실행할 수 있습니다.
AWS Lake Formation: Glue 카탈로그 위에서 테이블/컬럼 단위 권한을 관리합니다. 팀/프로젝트별로 데이터 접근을 분리해야 할 때 씁니다.

4.5 큐레이션/라벨링/증강

다섯 번째 문제는 데이터 레이크에 쌓인 원시 데이터의 상태입니다. 로봇에서 온 데이터는 연속적이고, 라벨이 없으며, 대부분은 학습에 새로운 정보를 주지 않는 평범한 장면입니다. 학습에 필요한 것은 그 반대입니다. 유의미한 장면 단위로 잘려 있고, 무엇이 담겼는지 검색할 수 있고, 부족한 시나리오가 채워진 데이터셋입니다. 원시 데이터를 이 상태로 바꾸는 작업이 큐레이션·라벨링·증강인데, 수만 개 에피소드에 사람이 일일이 라벨을 붙이는 것은 비용과 속도 모두 규모가 나오지 않습니다.

여기서 중요한 것은 세 작업이 별개가 아니라 하나의 순환이라는 점입니다. 라벨링이 되어야 검색할 수 있고, 검색이 되어야 어떤 데이터가 부족한지 알 수 있으며, 부족한 것을 알아야 증강으로 무엇을 만들지 정할 수 있습니다. 만들어진 데이터는 다시 라벨링되어 데이터셋에 들어갑니다.

그림 12. 큐레이션/라벨링/증강의 순환 구조

순서대로 보면 다음과 같습니다.

1단계 — 선별과 의미 부여 (큐레이션 + 라벨링)

원시 영상을 장면 단위 클립으로 분할하고, VLM(Vision-Language Model, 영상을 이해하는 언어 모델)으로 각 클립에 자연어 캡션을 붙이고, 클립을 벡터 임베딩으로 변환합니다. 분할 → 트랜스코딩 → 캡셔닝→ 임베딩의 4단계를 거칩니다. 캡셔닝을 위한 VLM 모델이나 임베딩 모델은 Amazon Bedrock 에서 자유롭게 선택할 수 있습니다.

2단계 — 검색과 갭 파악

모델이 약한 시나리오를 골라 학습 데이터셋을 재조립하고, 데이터가 아예 부족한 시나리오를 식별하는 단계입니다. 1단계의 캡션과 임베딩을 인덱싱하면 자연어로 의미 검색이 가능해집니다. 예를 들어, “이 실패 장면과 비슷한 클립”을 벡터 유사도로 찾을 수 있습니다. Amazon OpenSearch Service에 임베딩을 인덱싱해 자연어 + 벡터 하이브리드 질의를 구성할 수 있습니다. 모델이 약한 시나리오를 골라 학습 데이터셋을 재조립하고, 데이터가 아예 부족한 시나리오를 식별합니다.

3단계 — 부족한 시나리오 생성 (증강)

2단계에서 찾은 희소 시나리오를 합성 데이터로 채웁니다. 월드 모델(3.4의 패턴 참고)을 통해 생성형 AI로 합성 데이터를 생성합니다. 여기서 액션 라벨은 재생성 되지 않기 때문에, 원본의 액션 라벨은 그대로 보존했다가 마지막에 생성된 합성 영상과 다시 결합합니다.

참고로 이 파이프라인을 구성하는 모델 계열은 빠르게 통합되는 중입니다. NVIDIA는 2026년 6월 Cosmos 3를 발표했는데, 지금까지 캡셔닝(Reason)/생성(Transfer/Predict)으로 나뉘어 있던 기능을 시각 추론/세계 생성/액션 예측을 하나의 아키텍처로 합친 오픈 옴니모델로 묶었습니다. 위의 순환 구조 자체는 유지되면서, 각 단계에 들어가는 모델이 세대 교체되는 방향입니다.

인프라 관점에서 1단계 큐레이션과 3단계 생성은 모두 GPU 연산과 고속 스토리지 I/O를 동시에 요구하므로 HyperPod + FSx for Lustre 조합이 기본이고, 에피소드 단위로 팬아웃하는 배치 구조라서 Amazon SageMaker Processing / Amazon Elastic Kubernetes Service (Amazon EKS) / AWS Batch 같은 병렬 컴퓨트와 오케스트레이션을 공유할 수 있습니다.

4.6 저장된 데이터를 학습에 연결

큐레이션이 끝난 데이터셋을 GPU 인스턴스에 연결할 때, DataLoader의 읽기 속도가 느리면 GPU 사용률이 떨어지고 가장 비싼 자원이 대기 상태가 됩니다. 그래서 스토리지는 용량이 아니라 학습 I/O 패턴(순차 vs 랜덤, 스몰파일 비중, 반복 epoch 여부)으로 선택합니다. 참고로 File/Fast File 같은 입력 모드는 Amazon SageMaker 학습 잡에서만 의미가 있고, HyperPod나 Amazon Elastic Compute Cloud (Amazon EC2)로 직접 대규모 학습을 돌릴 때는 아래의 파일시스템을 특성에 맞게 선택하여 직접 마운트합니다.

각 스토리지별 특성 요약

Mountpoint for Amazon S3: S3 버킷을 파일시스템처럼 마운트해 직접 읽게 해주는 클라이언트입니다. 읽기 중심·단일 노드 쓰기·기존 객체 미수정이 전제이며, 대량 순차 읽기에 최적화돼 있습니다. 파일시스템을 따로 운영하지 않고 S3를 그대로 읽어 PB급 자율주행 시뮬레이션/ML 학습에 쓸 때 적합합니다.
Amazon FSx for Lustre: S3와 링크되는 고성능 병렬 파일시스템입니다. 첫 접근 시 lazy load하고, Epoch 수행이나 Job 수행시 지연시간 최소화됩니다. 사전 프리로드로 콜드스타트를 없애고 여러 학습 잡이 같은 파일시스템을 공유합니다. 같은 데이터셋으로 반복 실험하는 다노드 학습에 적합하며, 사실상 대규모 학습의 기본값입니다.
Amazon S3 Express One Zone: 고성능 S3 스토리지 클래스입니다. S3 Standard 대비 접근이 최대 10배 빠르고 요청 비용이 최대 80% 낮으며, 디렉터리 버킷당 초당 200만 요청까지 확장됩니다. SageMaker 학습의 입력/체크포인트/출력 위치로 직접 지정할 수 있어, 스몰파일 랜덤 읽기가 많거나 체크포인트 쓰기가 학습 시간을 지배할 때 적합합니다.
Amazon EFS: 여러 노드가 동시에 마운트, 쓰기 가능한 POSIX 공유 파일시스템입니다. 용량 프로비저닝이 필요 없고 처리량은 Lustre보다 낮습니다. 멀티 노드/멀티-AZ 학습에서 체크포인트/아티팩트를 공유할 때, 특히 분산 RL에 적합합니다.
인스턴스 로컬 NVMe: EC2 인스턴스에 직접 물린 로컬 SSD입니다. 최대 성능을 내지만 인스턴스가 삭제되면 사라집니다. 체크포인트 스테이징이나 한 epoch 안에서 반복 접근하는 핫 데이터에 적합합니다.

스토리지 선택 가이드라인

그림 13. 학습 데이터 접속 경로 선택 — IO 패턴별 스토리지 선택

5. 정리

결국 Physical AI에서 성능의 상한을 정하는 것은 모델이 아니라 데이터입니다. 이 글에서 다룬 내용은 대부분 파이프라인을 구성하기 이전에 고려해야 하는 사항으로, 데이터를 어떻게 설계하고 어떤 AWS 서비스와 연결할지에 대해 초기 설계가 필요합니다. 데이터 파이프라인을 구축하는 것이 모든 학습의 출발점입니다.

스테이지	주 서비스	핵심 결정
① 엣지 수집	AWS IoT Greengrass	추론과 센서 수집 동시 실행, 이중 역할
② 실시간 텔레메트리	Kinesis Video Streams / Data Streams / IoT Core	영상/고빈도/저빈도 경로 3분할
③ 벌크 반입	DataSync / Direct Connect / File Cache	데이터 샤딩을 통한 효율적인 온프레미스 데이터 클라우드 이관
④ 데이터 레이크	S3 Intelligent-Tiering	바이너리와 메타데이터 분리
⑤ 큐레이션/라벨링/증강	Bedrock VLM / SageMaker Processing / HyperPod	라벨링→검색→증강의 순환 구성
⑥ 학습에 연결	FSx for Lustre + EFS	I/O 패턴으로 스토리지 선택

Embodiment와 제어 주기를 먼저 정의합니다. 액션 공간, 목표 제어 주기, 온보드 전력/메모리 예산이 나오면 쓸 수 있는 모델 계열의 범위가 정해집니다. 여러 embodiment를 다룰 예정이면 통합 액션 공간과 embodiment별 마스킹을 처음부터 설계에 넣습니다.
수집하고자 하는 데이터 스키마를 확정합니다. 모달리티 목록, 데이터셋 포맷, 문맥 정보(object detection, semantic subtask, affordance) 등 학습에 사용할 데이터를 정의합니다. 데이터셋 포맷은 LeRobot 같은 공개 표준을 기준으로 잡으면 공개 데이터셋·도구 생태계와의 호환을 확보할 수 있습니다.
무엇을, 어떤 주기로 수집할지 먼저 정합니다. 수많은 센서 스트림에서 유의미한 데이터를 큐레이션하는 것도 리소스가 드는 작업이므로, 수집 대상과 모달리티별 수집 주기를 앞단에서 결정해 둡니다.
큐레이션을 자동화합니다: 에피소드 포맷 표준화 → 성공/실패 판정 → 품질 필터링 → 증강을 하나의 파이프라인을 묶어, 데이터 수집 및 선별을 자동화합니다.
데이터 다양성은 무작정 늘리지 말고 종류를 구분해 관리합니다: 배경/조명/물체와 같은 관측 다양성(observation diversity)은 다양할 수록 좋지만, 행동 다양성(action diversity)은 적정선을 넘기면 오히려 정책이 모호해집니다(mode ambiguity). 한 상황에 서로 다른 행위가 섞여 있으면 모델이 이를 종합하여 평균을 계산하기에 실현 불가능한 동작으로 이어지는 경우가 있습니다.

다음 편

2편 — 학습에서는 이 데이터로 무엇을 어떻게 학습시킬지 다룹니다. VLM/VLA/WFM/WAM/Omni-model에 대해 구분하고, pre-training과 post-training과 RL의 세 단계 학습을 설명합니다.

AWS 기술 블로그