NVIDIA OSMO 완전 가이드: YAML 하나로 로봇 AI 파이프라인 끝내기
로봇 AI 모델(정책, policy)을 만들려면 보통 세 종류의 컴퓨터가 필요합니다. 데이터센터 GPU에서 학습하고, 워크스테이션급 RTX에서 시뮬레이션한 뒤, 실제 로봇에 들어있는 Jetson에서 마지막 검증을 합니다. 문제는 각 단계마다 도구가 달라진다는 점입니다. NVIDIA가 공개한 OSMO는 이 3대 컴퓨터 문제를 단 하나의 YAML 파일로 묶어주는 오픈소스 오케스트레이터입니다.
1. OSMO란 무엇인가요?
NVIDIA OSMO는 Kubernetes(줄여서 K8s) 위에서 동작하는 워크플로우 오케스트레이터입니다. 쉽게 말해, "여러 컴퓨터에 흩어진 작업을 한 장의 설계도로 자동으로 돌려주는 프로그램"입니다.
💡 한 줄 요약: OSMO는 "단일 YAML, 모든 계층 실행"을 표방합니다. 인프라 코드를 한 줄도 바꾸지 않고 노트북부터 데이터센터, 에어갭(인터넷이 차단된 보안 구역) 클러스터까지 동일한 워크플로우를 실행할 수 있습니다.
대표적인 특징은 다음과 같습니다.
- 오픈소스
Apache-2.0라이선스 (상업적 사용 가능) - Helm 차트를 NGC에서 제공
KIND기반 로컬 퀵스타트 지원 (노트북에서 컨트롤 플레인 즉시 실행)- 최신 안정 버전: 6.3.1 (2026년 6월)
2. 왜 "3대 컴퓨터 문제"라고 부를까요?
NVIDIA는 물리적 AI(physical AI) 개발을 3대 컴퓨터 문제로 정의합니다. 각 계층의 역할과 도구가 완전히 다르기 때문입니다.
① 데이터센터 GPU
학습 대규모 신경망을 수천~수만 시간 돌려서 정책을 만듭니다. 예: GB200, H100.
② 워크스테이션급 RTX
시뮬레이션 사실적인 물리·센서 렌더링으로 정책을 가상에서 시험합니다. 예: RTX PRO 6000.
③ 엣지 디바이스 (Jetson)
배포·HIL 실제 로봇에 올라간 칩에서 HIL 테스트를 합니다. 예: Jetson AGX Thor.
전통적으로 각 계층마다 전용 클러스터, 전용 스케줄러, 전용 연결 스크립트(glue script)가 필요했습니다. 그 경계마다 사용자 정의 코드가 쌓이고, 학습한 모델이 시뮬레이션에서 잘 돌지만 실제 로봇에서는 깨지는 일이 반복됐습니다.
OSMO는 이 세 단을 모두 하나의 컨트롤 플레인의 백엔드로 취급합니다. 워크플로우는 gb200, rtx-pro-6000, jetson-agx-thor 같은 플랫폼 이름만 지정하면, OSMO가 해당 장비를 가진 풀로 작업을 자동으로 보내줍니다.
3. 워크플로우의 모양새
공식 리포지토리에 있는 표준 예제는 데이터로 연결된 3개 태스크입니다.
rtx-pro-6000에서 Isaac Sim 컨테이너를 실행해 시뮬레이션 데이터를 만듭니다.gb200에서 GPU 8장을 쓰는 PyTorch 컨테이너를 돌려 정책을 학습합니다.jetson-agx-thor에서 ROS 앱을 실행, 학습된 정책을 실제 로봇 칩 위에서 검증합니다.디자인 원칙 3가지
- 의존성은
inputs에서 결정 - 영속성(저장)은
outputs에서 결정 - 배치(어디서 돌릴지)는
platform에서 결정
사용자는 직렬/병렬 태스크 그룹, Jinja 템플릿(파라미터화된 워크플로우), 재시도 정책, 그리고 풀 간 선점(preemption)·GPU 차용(borrowing)이 가능한 HIGH/NORMAL/LOW 우선순위를 자유롭게 조합할 수 있습니다.
4. 핵심 기능 6가지
🔁 이식성 (Portability)
동일한 YAML이 노트북의 Docker/KIND뿐 아니라 EKS, AKS, GKE, 온프레미스, 에어갭 클러스터까지 그대로 실행됩니다. deploy-k8s.sh 하나로 어디든 배포하고, MinIO·Azure Blob·AWS S3·S3 호환 스토리지를 연결할 수 있습니다.
🛠️ 인터랙티브 개발 (Interactive Development)
원격 GPU 노드에서 VS Code, Jupyter, SSH 세션을 띄우고, 실행 중인 태스크에 exec로 붙어 디버깅할 수 있습니다. 포트 포워딩과 양방향 rsync로 파일을 실시간 동기화하며, 6.3.0부터 진행률 표시줄이 추가되었습니다.
📅 스케줄링 (Scheduling)
기본 스케줄러는 NVIDIA KAI Scheduler입니다. 6.2.8에서 NVLink 토폴로지를 인식해 멀티 GPU 태스크를 최적의 노드에 배치하는 기능이 들어갔고, 6.3.0에서는 그룹별 exec_timeout/queue_timeout이 분리되어 한 정체 그룹이 다른 형제 그룹을 막지 않습니다.
💾 데이터 (Data)
CAS(Content-Addressable Storage) 기반 데이터셋과 중복 제거로 스토리지를 10~100배 줄일 수 있다고 주장합니다. 단, 독립 실행형 osmo dataset CLI와 /datasets API는 6.3에서 비추천, 6.4에서 제거 예정이니 워크플로우 출력 형태로 마이그레이션을 계획해야 합니다.
🔐 보안과 신원 (Security & Identity)
6.2.8부터 RBAC 권한 사이드카, OAuth2 디바이스 코드 로그인, ID 공급자 매핑을 제공합니다. 6.3.0은 Envoy 게이트웨이 TLS 종료와 클라우드 워크로드 신원(Azure Workload Identity, AWS IRSA/Pod Identity)을 추가해 시크릿에 키를 저장하지 않아도 됩니다. 6.3.1은 기본 osmo-user 역할을 기본 풀로 제한해 보안 기본값을 강화했습니다.
🤖 에이전트 통합 (Agent Integration)
리포지토리는 AGENTS.md, 스킬 디렉터리, MCP 배포 가이드를 함께 제공합니다. GTC 2026에서 NVIDIA는 OSMO가 Claude Code, OpenAI Codex, Cursor와 통합되어, 코딩 에이전트가 파이프라인을 직접 제출·모니터링·디버깅한다고 발표했습니다.
5. AI 코딩 에이전트와 어떻게 연동되나요?
MCP(Model Context Protocol)라는 표준 덕분입니다. OSMO 리포지토리는 MCP 배포 가이드를 함께 제공하므로, Claude Code나 Cursor 같은 AI 코딩 도구가 "이 워크플로우 제출해줘", "GPU가 멈춘 태스크만 다시 돌려줘" 같은 명령을 자연어로 실행할 수 있습니다.
🧩 왜 중요한가: 2026년형 로봇 팀은 AI에게 "데이터 생성 → 학습 → 실로봇 검증" 3단계를 한 문장으로 시키는 것이 표준이 되고 있습니다. OSMO는 그 에이전트 시대의 인프라에 가장 먼저 손을 댄 도구입니다.
6. 어떻게 시작하나요?
가장 쉬운 길은 로컬 퀵스타트입니다. 노트북에서 컨트롤 플레인만 먼저 돌려보고, 익숙해지면 클라우드로 옮기면 됩니다.
# 1) OSMO 컨트롤 플레인을 KIND(K8s in Docker) 위에 띄우기
git clone https://github.com/NVIDIA/OSMO.git
cd OSMO
./quickstart.sh
# 2) 워크플로우 제출
osmo workflow submit examples/three-computer.yaml
# 3) 상태 확인 + AI 에이전트로 디버깅
osmo workflow status <id>
claude # 또는 cursor → "OSMO 워크플로우 디버깅해줘"
운영 환경으로 옮길 때는 deploy-k8s.sh 스크립트가 AKS/EKS/microk8s/기존 클러스터 어디든 배포를 도와줍니다.
| 버전 | 핵심 변경 |
|---|---|
| 6.2.8 | RBAC 사이드카, OAuth2 디바이스 로그인, NVLink 토폴로지 인지 배치 |
| 6.3.0 | 멀티 프로바이더 deploy-k8s.sh, Envoy TLS 종료, 클라우드 워크로드 신원 |
| 6.3.1 | 기본 osmo-user 역할 강화, 기본 풀 제한 |
| 6.4 (예정) | osmo dataset CLI·/datasets API 제거 |
7. 자주 묻는 질문 (FAQ)
Q1. OSMO는 무료인가요?
네. Apache-2.0 라이선스로 누구나 자유롭게 내려받아 사용·수정·상업적 배포가 가능합니다. 다만, GPU나 클라우드 사용 비용은 별도입니다.
Q2. 기존 Airflow, Argo Workflows와 무엇이 다른가요?
OSMO는 물리적 AI 파이프라인에 특화되어 플랫폼 기반 라우팅, GPU 차용/선점, NVLink 인지 배치를 기본 제공합니다. 일반 데이터 파이프라인 도구에는 없는 로봇 워크로드 친화 기능입니다.
Q3. Jetson 같은 엣지 디바이스도 클러스터에 등록할 수 있나요?
가능합니다. osmo compute register로 Jetson AGX Thor를 백엔드로 등록하면 jetson-agx-thor 플랫폼 태스크가 자동으로 그 장비로 라우팅됩니다.
Q4. 보안은 어떻게 처리하나요?
RBAC로 역할을 나누고, OAuth2 디바이스 로그인으로 표준 ID 공급자(Okta, Azure AD 등)를 연결합니다. 6.3.0부터는 클라우드 워크로드 신원으로 시크릿 없이도 안전하게 스토리지에 접근합니다.
Q5. 진짜로 누가 쓰고 있나요?
GR00T, Isaac Lab, Isaac Sim, Isaac ROS 워크로드에서 실전 검증되었으며, Azure 및 Nebius와 통합 사례가 보고되어 있습니다.
8. 핵심 요약
- OSMO는 단일 YAML로 이기종 K8s 클러스터의 학습·시뮬레이션·엣지 HIL 태스크를 오케스트레이션한다.
Apache-2.0, NGC Helm 차트 제공, 로컬 KIND 퀵스타트 지원, 최신 안정판은 6.3.1.- KAI Scheduler, NVLink 인지 배치, 그룹별 타임아웃, 내장 RBAC·OAuth2 기본 제공.
- GR00T, Isaac Lab, Isaac Sim, Isaac ROS 검증 완료. Azure·Nebius 통합 존재.
- 데이터셋 CLI는 6.3에서 비추천, 6.4에서 제거 → 조기 마이그레이션 권장.
🚀 한 줄 결론: "세 컴퓨터를 돌리려면 세 도구"라는 옛 공식이 끝났습니다. OSMO는 로봇 AI 팀이 설계도(YAML) 한 장만 들고 다닐 수 있게 해주는, 2026년 Physical AI 스택의 사실상 표준 오케스트레이터로 자리 잡고 있습니다.