콘텐츠로 이동

Physical AI (피지컬 AI)

문서 기준: 2026년 8월 | 이 문서는 변동이 빠른 영역으로 분기별 리뷰 대상입니다.

Physical AI(피지컬 AI)는 텍스트·이미지 같은 디지털 데이터에 머무르던 AI를 센서·로봇·차량·설비 등 물리 세계와 연결해, 인식하고 판단하고 물리적으로 행동하게 하는 흐름을 가리킵니다. 챗봇이나 문서 처리 같은 디지털 AI와 달리, Physical AI는 지연(latency)·안전(safety)·실시간성이 실패하면 사람이나 장비에 직접적인 위험이 될 수 있다는 점이 근본적으로 다릅니다.

Physical AI는 하나의 제품이 아니라 여러 계층이 맞물린 파이프라인입니다. 데이터가 물리 세계에서 들어와, 학습·시뮬레이션을 거쳐, 다시 물리 세계로 행동을 내보냅니다.

flowchart LR
    S[센서·카메라·IoT] --> E[엣지 추론]
    E -->|텔레메트리| C[클라우드 학습·모델 관리]
    C -->|합성 데이터| SIM[시뮬레이션·디지털 트윈]
    SIM -->|정책·모델| C
    C -->|배포| E
    E --> A[액추에이터·로봇·차량]
    A -.피드백.-> S

물리 세계의 데이터는 대량이고 실시간이라, 모두 클라우드로 보내 처리하기 어렵습니다. 현장(엣지)에서 먼저 추론하고, 필요한 데이터만 클라우드로 올리는 구조가 기본입니다.

항목 AWS Azure Google Cloud OCI
엣지 런타임 IoT Greengrass Azure IoT Operations / IoT Edge Google Distributed Cloud (Edge) Roving Edge Infrastructure
엣지 ML 추론 Greengrass ML 컴포넌트 (SageMaker AI 모델 배포) IoT Edge 모듈 + Azure AI 서비스 Edge TPU / Coral RED 상의 컴퓨트로 자체 구성
산업 데이터 수집 IoT SiteWise (OPC UA) IoT Operations (OPC UA) — (파트너·자체 구성) — (자체 구성)

계층 2 — 디지털 트윈과 시뮬레이션

섹션 제목: “계층 2 — 디지털 트윈과 시뮬레이션”

로봇·차량을 실제 세계에서만 학습시키면 비용·위험·시간이 큽니다. 그래서 물리 환경을 가상으로 복제한 디지털 트윈시뮬레이션에서 대량의 시나리오를 생성·학습한 뒤 현실로 옮기는 sim-to-real 접근이 자리 잡았습니다.

항목 AWS Azure Google Cloud OCI 크로스벤더
디지털 트윈 IoT TwinMaker Azure Digital Twins — (Spanner Graph·BigQuery 등으로 자체 구성) NVIDIA Omniverse
로봇·물리 시뮬레이션 — (RoboMaker 지원 종료, 자체 구성) — (파트너·자체 구성) — (파트너·자체 구성) NVIDIA Isaac Sim / Isaac Lab

계층 3 — 로보틱스 파운데이션 모델

섹션 제목: “계층 3 — 로보틱스 파운데이션 모델”

LLM이 언어를 일반화했듯, 로봇의 인식·계획·동작을 일반화하려는 로봇 파운데이션 모델이 부상하고 있습니다. 자연어 지시를 받아 시각(Vision)·언어(Language)·행동(Action)을 연결하는 VLA(Vision-Language-Action) 방식이 대표적입니다.

항목 현황
대표 스택 NVIDIA Isaac GR00T — 로봇용 오픈 파운데이션 모델(VLA), Omniverse·Cosmos 기반 시뮬레이션·합성 데이터, Jetson Thor 온디바이스 추론
클라우드 3사 자체 범용 로봇 파운데이션 모델은 아직 제한적 — 대체로 NVIDIA 스택을 GPU 인프라 위에서 실행하거나 파트너십으로 제공
국가 정책 일본은 GENIAC에서 로보틱스 파운데이션 모델 개발을 국책 과제로 채택 (일본 AI 지형 참고)

안전 레이어 — 자율주행과 로보틱스

섹션 제목: “안전 레이어 — 자율주행과 로보틱스”

물리 세계에서 움직이는 AI는 인명·설비와 직결되어 기능 안전(functional safety) 인증이 핵심입니다. NVIDIA는 이 영역에서 안전 시스템 Halos를 제공합니다.

  • 자율주행(AV): DRIVE 플랫폼(AGX·Hyperion)과 Halos 안전 시스템(클라우드-차량 전 구간, ISO 26262 지향), 시뮬레이션은 Omniverse·Cosmos.
  • 로보틱스: NVIDIA는 2026년 6월 자율주행 안전 기반을 산업용 로봇·휴머노이드·AMR로 확장한 Halos for Robotics(IGX Thor·Holoscan Sensor Bridge·Halos OS·AI Systems Inspection Lab)를 발표했습니다.

멀티클라우드·엣지 아키텍처 고려사항

섹션 제목: “멀티클라우드·엣지 아키텍처 고려사항”
  • 데이터 중력과 지연 — 센서 데이터는 대량이고 지연에 민감해, 현장 엣지 추론과 클라우드 학습을 분담하는 설계가 기본입니다. 무엇을 엣지에서 처리하고 무엇을 올릴지 먼저 정하세요.
  • 시뮬레이터 이식성 — 디지털 트윈·시뮬레이션이 특정 클라우드의 전용 서비스에 묶이면 이식이 어렵습니다. NVIDIA Omniverse·Isaac처럼 GPU만 있으면 어디서든 실행 가능한 스택을 우선 검토하면 락인이 줄어듭니다.
  • 온디바이스 vs 클라우드 학습 분담 — 학습·합성 데이터 생성은 클라우드 GPU, 실시간 추론은 온디바이스(예: Jetson류)로 나누는 것이 일반적입니다.
  • 안전·규제 — 자율주행·산업 로봇은 기능 안전 인증과 규제가 별도로 적용됩니다. 아키텍처 초기에 인증 요건을 반영하세요.
  • 제품 수명주기 확인 — 이 영역은 은퇴(EOL)된 제품이 많습니다(예: Azure Percept, AWS RoboMaker). 설계 전 각 서비스의 현행 지원 상태를 반드시 확인하세요.
  • 모든 데이터를 클라우드로 보내기 — 지연·대역폭·비용을 무시한 설계는 실시간 제어에서 실패합니다. 엣지 추론 분담이 먼저입니다.
  • EOL 제품을 신규 설계에 사용 — RoboMaker·Percept처럼 지원 종료된 서비스를 오래된 자료만 보고 채택하지 마세요.
  • 단일 벤더 시뮬레이터에 종속 — 특정 클라우드 전용 시뮬레이션에 학습 파이프라인을 묶으면 이식·비교가 어려워집니다.
  • 안전을 나중에 붙이기 — 자율주행·로봇은 안전을 아키텍처 초기부터 설계해야 합니다(“bolt-on”이 아니라 “built-in”).
  • 엣지에서 처리할 추론과 클라우드로 올릴 데이터를 구분했는가?
  • 디지털 트윈·시뮬레이션 스택이 다른 클라우드로 이식 가능한가(락인 점검)?
  • 사용하려는 IoT·로보틱스 서비스가 현행 지원 상태인가(EOL 확인)?
  • 자율주행·산업 로봇이라면 기능 안전 인증 요건을 설계에 반영했는가?
  • 온디바이스 추론과 클라우드 학습의 역할 분담이 명확한가?