DimOS : 로봇을 위한 “에이전트 운영체제”

AI 에이전트가 브라우저와 코드 실행 환경을 다루는 시대를 지나, 이제는 카메라·라이다·모터·드론까지 다루려는 오픈소스가 나오고 있습니다. DimOS는 바로 그 지점에서 등장한 프로젝트입니다. 단순히 “로봇 제어 라이브러리” 하나를 더 만든 것이 아니라, 로봇을 에이전트가 실행 가능한 소프트웨어 플랫폼으로 재정의하려는 시도에 가깝습니다. 자연어로 명령하고, 여러 하드웨어를 같은 추상화로 다루고, 센서 입력부터 제어 루프까지 하나의 실행 모델 안에 넣겠다는 발상입니다. (GitHub)

 

GitHub - dimensionalOS/dimos: Dimensional is the agentic operating system for physical space. Vibecode humanoids, quadrupeds, dr

 

---

프로젝트 소개

DimOS는 Dimensional 팀이 공개한 범용 로보틱스용 오픈소스 프레임워크입니다. 프로젝트는 스스로를 “physical space를 위한 agentic operating system”이라고 설명하며, ROS 없이도 Python 중심으로 휴머노이드·사족보행 로봇·드론 같은 다양한 하드웨어를 다룰 수 있다고 말합니다. 현재 공개 저장소 기준으로 Unitree Go2, B1, G1, xArm 계열, MAVLink/DJI 계열 장비 등을 예시 하드웨어로 제시하고 있고, 2026년 3월 12일 기준 최신 릴리스는 v0.0.11입니다. (GitHub)

기술 스택도 꽤 분명합니다. 기본 패키지는 Python 3.10+를 기준으로 구성되어 있고, 코어에는 NumPy, SciPy, Pinocchio, ReactiveX, Pydantic이 들어가며, CLI는 Typer와 Textual, 시각화는 Rerun, 에이전트 계층은 LangChain 계열과 Ollama/OpenAI/Anthropic 연동 옵션을 갖고 있습니다. 시뮬레이션은 MuJoCo, 웹 계층은 FastAPI/Uvicorn, 멀티 프로세스/메시징 계층은 LCM과 공유 메모리 계열 전송을 활용합니다. (GitHub)

즉, 이 프로젝트를 한 문장으로 요약하면 이렇습니다.

“로봇 소프트웨어 스택, 에이전트 실행기, 하드웨어 어댑터, 메시지 버스, CLI 운영 도구를 하나로 묶은 범용 로보틱스 런타임”

---

왜 이 프로젝트가 등장했을까

로보틱스 개발은 전통적으로 너무 파편화되어 있었습니다.
하드웨어 제조사마다 SDK가 다르고, 센서 입력 형식도 다르고, 제어 인터페이스도 다르고, 어떤 팀은 ROS 위에 얹고 어떤 팀은 자체 미들웨어를 씁니다. 결국 “로봇 앱”을 만든다기보다 하드웨어마다 새 스택을 다시 조립하는 일이 반복됩니다. DimOS는 이 문제를 정면으로 건드립니다. README에서도 “no ROS required”, “single pip install”, “run on any humanoid, quadruped, or drone” 같은 메시지를 전면에 내세웁니다. (GitHub)

여기에 최근 LLM/에이전트 흐름이 결합됩니다. 웹 에이전트는 툴 호출을 통해 브라우저나 셸을 다루는데, DimOS는 이 개념을 물리 세계로 확장합니다. 카메라 입력을 받고, 공간 기억을 유지하고, 내비게이션 스킬을 노출하고, MCP로 외부 에이전트가 로봇 능력을 호출하도록 만드는 구조입니다. 즉, “에이전트가 현실 세계를 조작할 수 있는 실행 환경”을 만들려는 것입니다. (GitHub)

개발자 관점에서 보면 DimOS가 등장한 배경은 크게 세 가지입니다.

1. 하드웨어 종속성 완화
   로봇별 SDK 차이를 모듈과 블루프린트로 감춥니다. (GitHub)
2. 에이전트 네이티브 실행 모델
   스킬을 MCP 툴처럼 노출해 자연어 명령과 물리 제어를 연결합니다. (GitHub)
3. 실험 가능한 개발 경험
   실제 장비 없이 replay와 simulation으로 먼저 검증할 수 있게 설계했습니다. README에 replay, simulation, webcam demo, MuJoCo 실행 예시가 따로 준비돼 있습니다. (GitHub)

---

핵심 기능

1) 모듈 기반 로봇 소프트웨어 구성

DimOS의 가장 중요한 추상화는 Module입니다. 각 모듈은 typed stream(In[T], Out[T])으로 데이터를 주고받고, @rpc 메서드로 동작을 노출합니다. 이 구조 덕분에 카메라 입력 모듈, 내비게이션 모듈, LLM 에이전트 모듈, 스킬 컨테이너 모듈을 느슨하게 결합할 수 있습니다. 저장소 문서에 따르면 모듈은 forkserver 기반 워커 프로세스에서 동작하며, 스트림은 메시지 타입과 이름으로 연결됩니다. (GitHub)

예를 들어 README에 나온 가장 단순한 패턴은 아래와 비슷합니다.

import threading, time, numpy as np
from dimos.core.blueprints import autoconnect
from dimos.core.core import rpc
from dimos.core.module import Module
from dimos.core.stream import In, Out
from dimos.msgs.sensor_msgs import Image, ImageFormat

class RobotConnection(Module):
    color_image: Out[Image]

    @rpc
    def start(self):
        threading.Thread(target=self._image_loop, daemon=True).start()

    def _image_loop(self):
        while True:
            img = Image.from_numpy(
                np.zeros((120, 160, 3), np.uint8),
                format=ImageFormat.RGB,
                frame_id="camera_optical",
            )
            self.color_image.publish(img)
            time.sleep(0.2)

class Listener(Module):
    color_image: In[Image]

    @rpc
    def start(self):
        self.color_image.subscribe(
            lambda img: print(f"image {img.width}x{img.height}")
        )

autoconnect(
    RobotConnection.blueprint(),
    Listener.blueprint(),
).build().loop()

이 예제가 의미 있는 이유는, 로봇 소프트웨어의 핵심을 “클래스 + 스트림 입출력”으로 낮춰준다는 점입니다. ROS 노드 그래프처럼 생각할 수도 있지만, Python 애플리케이션 개발자에게는 더 직접적입니다. (GitHub)

2) Blueprint 기반 조립

DimOS는 개별 모듈보다 블루프린트가 더 중요합니다. 블루프린트는 “어떤 모듈들을 어떤 전송 방식으로 어떻게 연결할 것인가”를 선언하는 조립도입니다. autoconnect(...)는 (이름, 타입)이 맞는 스트림끼리 자동 연결하고, 필요하면 remapping과 transport override도 할 수 있습니다. (GitHub)

from dimos.core.blueprints import autoconnect
from dimos.core.transport import LCMTransport
from dimos.msgs.sensor_msgs import Image
from dimos.robot.unitree.go2.connection import go2_connection
from dimos.agents.agent import agent

blueprint = autoconnect(
    go2_connection(),
    agent(),
).transports({
    ("color_image", Image): LCMTransport("/color_image", Image)
})

blueprint.build().loop()

이 방식의 장점은 분명합니다.
로봇 앱을 “코드가 한 덩어리로 엉킨 프로그램”이 아니라 조합 가능한 배선도로 다루게 됩니다. 그래서 replay 환경, 실제 하드웨어, MuJoCo 시뮬레이션을 블루프린트 레벨에서 교체하기 쉬워집니다. (GitHub)

3) Agent CLI와 운영 경험

dimos CLI는 단순 실행기가 아닙니다. run, status, log, stop, restart, list, 그리고 mcp list-tools, mcp call 같은 운영 명령까지 제공합니다. 특히 run 시점에 블루프린트를 로드하고, 포트 충돌을 확인하고, 런 ID와 로그 디렉터리를 만들고, health check 뒤에 daemon 모드로 전환하는 흐름이 구현돼 있습니다. 이건 “실험용 스크립트 모음”이 아니라 실행 중인 로봇 스택을 운영하는 런타임 도구에 가깝습니다. (GitHub)

실제 사용 흐름은 이런 식입니다.

dimos --simulation run unitree-go2-agentic-mcp --daemon
dimos status
dimos log -f
dimos agent-send "explore the room"
dimos mcp list-tools
dimos mcp call relative_move --arg forward=0.5
dimos stop

CLI가 중요한 이유는 로봇 개발이 결국 “한 번 실행하고 끝나는 코드”가 아니라, 계속 돌고 상태를 보고 로그를 보고 다시 제어해야 하는 시스템이기 때문입니다. DimOS는 그 운영 루프를 꽤 신경 써서 설계했습니다. (GitHub)

4) MCP를 통한 에이전트-로봇 연결

DimOS가 요즘 개발자들에게 특히 흥미로운 이유는 MCP 계층입니다. 저장소 문서에 따르면 현재 제공되는 MCP 활성 블루프린트는 unitree-go2-agentic-mcp이며, 이 블루프린트는 unitree_go2_spatial, McpServer, mcp_client(), 공통 agentic 스택을 autoconnect로 묶습니다. 즉, 로봇의 공간 인지/제어 능력 위에 MCP 서버와 LLM 클라이언트를 얹어 에이전트가 로봇 스킬을 툴처럼 호출하게 만듭니다. (GitHub)

MCP 서버 쪽 구현을 보면 introspection용 스킬인 server_status, list_modules, agent_send 등이 실제로 노출되어 있고, 앱 상태의 skill 목록을 바탕으로 모듈과 스킬을 JSON으로 반환합니다. 즉, 단순 HTTP 래퍼가 아니라 현재 배포된 모듈에서 툴 목록을 동적으로 구성하는 런타임입니다. (GitHub)

이 지점이 DimOS의 핵심 차별점입니다.
기존 로봇 프레임워크가 “센서와 액추에이터 연결”에 집중했다면, DimOS는 거기서 한 단계 더 나아가 로봇 능력을 에이전트 친화적인 툴 인터페이스로 재구성합니다. (GitHub)

---

프로젝트 아키텍처 분석

DimOS를 가장 잘 이해하는 방법은 내부를 네 층으로 나눠 보는 것입니다.

1. 하드웨어/시뮬레이션 계층
   실제 로봇, 드론, 카메라, 센서, MuJoCo, replay 데이터
2. 모듈/스트림 계층
   각 기능을 Module로 나누고 typed stream으로 연결
3. 블루프린트/코디네이터 계층
   실행 시 모듈을 워커에 배포하고 transport를 배선
4. 에이전트/운영 계층
   CLI, MCP, 스킬 호출, 로그, 상태 관리

이를 그림으로 그리면 대략 이런 구조입니다.

이 구조에서 특히 눈여겨볼 부분은 세 가지입니다.
첫째, 모듈 간 통신이 스트림 중심이라는 점. 둘째, 실행 단위가 블루프린트라는 점. 셋째, 에이전트도 모듈 중 하나라는 점입니다. 그래서 perception과 planning, agent reasoning, hardware control이 서로 다른 세계가 아니라 같은 조립 모델 안에 들어옵니다. (GitHub)

---

코드 관점에서 본 설계 포인트

1) Module이 ROS 노드와 Python 컴포넌트의 중간쯤에 있다

Module 클래스는 타입 힌트에서 In/Out 스트림을 읽어 인스턴스 속성으로 구성하고, RPC와 skill introspection도 처리합니다. 즉, 선언형 타입 힌트만으로 “이 모듈이 무엇을 입력받고 무엇을 출력하는지”가 런타임 메타데이터가 됩니다. 이런 설계는 대규모 로봇 그래프에서 매우 유리합니다. 모듈 자체가 곧 인터페이스 문서이기 때문입니다. (GitHub)

2) 자동 연결은 편하지만, transport override가 중요하다

autoconnect는 생산성을 높이지만 실제 로봇 시스템에서는 이미지·포인트클라우드처럼 무거운 데이터가 문제입니다. DimOS 문서가 LCMTransport, SHMTransport/pSHMTransport, pLCMTransport를 구분해서 설명하는 이유가 여기에 있습니다. 작은 제어 메시지와 대용량 센서 데이터를 같은 채널 개념으로 다루되, 전송 계층은 상황에 따라 바꾸게 한 겁니다. (GitHub)

3) CLI가 곧 운영 API다

많은 오픈소스가 예제 스크립트는 많지만 운영 도구는 빈약합니다. DimOS는 반대로 status, log, restart, mcp call, show_config처럼 운영 API에 가까운 CLI를 갖고 있습니다. 코드 레벨에서도 run이 블루프린트 빌드, stale entry 정리, 포트 충돌 체크, health check, 로그 경로 설정을 한꺼번에 담당합니다. 실제 서비스형 로봇 운영을 염두에 둔 흔적입니다. (GitHub)

---

실제로 어떻게 사용할 수 있나

시나리오 1) 실제 로봇 없이 먼저 검증하기

가장 현실적인 첫 번째 사용법은 replay 또는 simulation입니다. README에는 recorded quadruped session replay, MuJoCo 시뮬레이션, webcam demo까지 준비돼 있습니다. 즉, 하드웨어 구매 전에도 perception 파이프라인, 에이전트 반응, 툴 호출 흐름을 검증할 수 있습니다. (GitHub)

uv venv --python "3.12"
source .venv/bin/activate
uv pip install 'dimos[base,unitree,sim]'

dimos --replay run unitree-go2
dimos --simulation run unitree-go2-agentic-mcp
dimos run demo-camera

이건 스타트업이나 연구팀 입장에서 꽤 중요합니다.
로보틱스는 하드웨어 접근 비용이 크기 때문에, “데이터 replay → 시뮬레이션 → 실제 장비”의 단계적 접근을 기본 제공하는 프레임워크가 훨씬 도입하기 쉽습니다. (GitHub)

시나리오 2) 자연어 기반 로봇 제어 실험

에이전트 실험을 하고 싶다면 MCP 활성 블루프린트가 가장 흥미롭습니다.

dimos --replay run unitree-go2-agentic-mcp --daemon
dimos mcp list-tools
dimos agent-send "walk forward 2 meters then wave"

이 흐름은 사실상 “웹 브라우저 툴 대신 로봇 스킬을 가진 에이전트”를 만드는 방식입니다. MCP 기반 AI 앱이나 에이전트 프레임워크와 연결해서 물리 스킬을 호출하는 실험을 하기에 좋습니다. (GitHub)

시나리오 3) 특정 하드웨어 벤더 의존성을 줄인 앱 구조 만들기

로봇 스타트업 팀이 가장 자주 겪는 문제는 “처음엔 Go2로 만들었는데, 나중엔 G1이나 드론으로 옮겨야 하는 상황”입니다. DimOS는 블루프린트와 모듈 조립을 통해 이 전환 비용을 줄이려는 방향을 갖고 있습니다. 물론 완전한 write-once-run-anywhere까지는 현실적으로 어렵겠지만, 적어도 앱 로직과 하드웨어 연결부를 분리하는 구조는 잘 보입니다. (GitHub)

---

언제 쓰면 좋은가

DimOS는 모든 로봇 프로젝트에 무조건 맞는 도구는 아닙니다. 하지만 아래 상황에서는 상당히 매력적입니다.

잘 맞는 경우

• 에이전트와 물리 하드웨어를 연결하는 실험이 필요할 때
• 여러 종류의 로봇을 하나의 개발 모델로 묶고 싶을 때
• 시뮬레이션, replay, 실제 장비를 같은 실행 방식으로 다루고 싶을 때
• ROS 중심 팀이 아니지만 Python으로 빠르게 프로토타입을 만들고 싶을 때 (GitHub)

조심해야 하는 경우

• 이미 ROS 2 기반 대규모 운영 체계가 굳어져 있고, 기존 생태계와 강하게 결합돼 있는 팀
• 안전성 검증, 실시간 제약, 인증 체계가 매우 중요한 산업용 시스템
• 오픈소스가 아직 pre-release beta 단계인 점을 감안해야 하는 팀 (GitHub)

즉, 지금 DimOS는 “완전히 검증된 표준 운영체제”라기보다 차세대 로봇 개발 경험을 제안하는 빠른 프레임워크로 보는 것이 정확합니다.

---

이 프로젝트의 진짜 포인트

DimOS를 보면서 가장 인상적인 부분은 로봇을 “하드웨어 제어 대상”이 아니라 에이전트 런타임이 붙는 컴퓨팅 플랫폼으로 본다는 점입니다.

전통적인 로봇 스택은 보통 이렇게 생각합니다.

• 센서 처리
• 위치 추정
• 경로 계획
• 제어

반면 DimOS는 여기에 다음 계층을 얹습니다.

• 자연어 명령
• 공간 기억
• 스킬 호출
• MCP 툴 인터페이스
• 운영형 CLI

이 차이는 큽니다.
왜냐하면 앞으로의 로봇 앱은 “정해진 상태기계”보다 “상황에 따라 reasoning하고 툴을 호출하는 에이전트형 프로그램”이 많아질 가능성이 크기 때문입니다. DimOS는 바로 그 변화를 코드 구조 차원에서 받아들이고 있습니다. (GitHub)

---

마무리

DimOS는 아직 초기 단계의 오픈소스이지만, 방향성만큼은 아주 선명합니다.

로봇을 위한 범용 소프트웨어 플랫폼을 만들고, 그 위에 에이전트가 자연스럽게 올라가도록 하겠다.

이 프로젝트가 흥미로운 이유는 단순히 로봇을 움직이게 해서가 아닙니다.
개발자가 로봇 애플리케이션을 만드는 방식을 “하드웨어별 커스텀 개발”에서 “조립 가능한 런타임 개발”로 바꾸려 하기 때문입니다. 모듈, 블루프린트, typed stream, MCP, CLI 운영 도구까지 이어지는 설계는 꽤 일관성이 있습니다. (GitHub)

한마디로 정리하면 이렇습니다.

DimOS는 로봇용 Python SDK가 아니라,
에이전트 시대의 로봇 운영체제를 지향하는 실험적인 실행 플랫폼이다. (GitHub)