AI는 시뮬레이터 개발을 훨씬 더 쉽게 만들고 있습니다.

오늘날 우리는 AI에게 MuJoCo와 같은 고충실도 물리 시뮬레이터 (high-fidelity physics simulators)를 다루도록 요청하거나, 이전에는 상당한 전문 지식이 필요했던 시뮬레이션 환경 구축을 돕기 위해 도구 통합 (tool integrations)을 사용할 수 있습니다.

하지만 실제로 자신의 프로젝트를 위한 시뮬레이터를 구축하려고 하면, 요구 사항은 빠르게 더 구체적으로 변합니다:

"기존의 ROS URDF를 사용하고 싶습니다."

"ROS 2 메시지 정의 (message definitions)를 재사용하고 싶습니다."

"웹 브라우저에서 시각화하고 싶습니다."

"그리고 제 Mac에서 실행되기를 원합니다."

각각의 요구 사항 자체는 특별히 어렵지 않습니다.

어려운 부분은 이 모든 것을 실제로 원하는 시뮬레이션 환경으로 결합하는 것입니다.

그래서 저는 한 가지 실험을 시도했습니다:

AI 코딩 에이전트 (AI coding agent)가 기존의 오픈 소스 구성 요소들을 결합하여 상위 수준의 요구 사항 (high-level requirements)으로부터 작동 가능한 로봇 시뮬레이터를 구축할 수 있을까?

이 실험을 위해, 저는 Hakoniwa를 AI 코딩 에이전트 (Codex)와 함께 사용했습니다.

최신 데모는 다음과 같습니다:

흥미롭게도, 이 기사 자체도 동일한 접근 방식을 따릅니다. 시뮬레이션 작업을 수행한 AI 코딩 에이전트가 기사의 초안 작성을 도왔고, 저는 인간으로서 이를 편집하고 다듬었습니다. 기사 후반부에서는 무엇이 이 개발 프로세스를 성공적으로 만들었는지 AI에게 성찰해 보라고 요청하기도 했습니다.

내가 구축한 것

저는 세 가지 매우 다른 로봇을 대상으로 동일한 AI 주도 개발 (AI-driven development) 접근 방식을 시도했습니다:

• AgileX Tracer — MuJoCo를 위해 ROS URDF에서 파생된 모델로 변환하였으며, ROS 2 Twist 기반의 PDU를 사용하여 제어했습니다.
• FR5 로봇 팔 (robot arm) — 팔을 Hakoniwa 에셋 (asset)으로 변환하였고, JointTrajectory 기반의 PDU를 사용하여 제어했습니다.
• Unitree Go1 — MuJoCo Menagerie 모델을 Hakoniwa 에셋으로 사용하였으며, 12개 관절에 대해 오픈 루프 운동 (open-loop motion)을 실행했습니다.

또한 Three.js 웹 뷰어 (web viewer)가 포함된 기존의 Hakoniwa 드론을 사용했습니다.

실험에 들어가기에 앞서, Hakoniwa가 무엇인지 간단히 설명하겠습니다.

Hakoniwa란 무엇인가?

Hakoniwa는 로봇 시뮬레이터, 제어 애플리케이션, 시각화 도구 및 기타 소프트웨어 구성 요소를 하나의 시뮬레이션 환경으로 구성하기 위한 오픈 소스 (open-source) 플랫폼입니다.

예를 들어, 다음과 같은 요소들을 결합할 수 있습니다:

• MuJoCo와 같은 물리 시뮬레이터 (physics simulator)
• ROS / ROS 2 애플리케이션
• 웹 브라우저에서 실행되는 시각화 애플리케이션
• 커스텀 제어 프로그램

Hakoniwa는 이러한 요소들을 **에셋 (assets)**이라고 불리는 독립적인 구성 요소로 취급합니다.

모든 것을 하나의 거대한 단일 시뮬레이터 (monolithic simulator) 내부에 구현하는 대신, 기본 아이디어는 다음과 같습니다:

원하는 시뮬레이션 환경을 구축하기 위해 필요한 구성 요소들을 결합하십시오.

구성 요소들은 **PDU (Protocol Data Units, 프로토콜 데이터 단위)**라고 불리는 구조를 사용하여 데이터를 교환합니다.

이러한 분리 방식은 AI와 함께 작업할 때 특히 유용하다는 것이 밝혀졌습니다.

개발 환경

저는 평소 개발에 사용하는 Mac에서 이 시뮬레이션들을 구축했습니다.

주요 환경은 다음과 같습니다:

• macOS
• MuJoCo
• Hakoniwa
• AI 코딩 에이전트로서의 Codex

저는 전용 시뮬레이션 워크스테이션이나 특별한 GPU 환경을 사용하지 않았습니다.

또한, 단순히 AI에게 이미 완성된 시뮬레이터를 작동시키라고 요청한 것도 아니었습니다.

목표는 더 야심 찼습니다:

요구 사항에서 시작하여, 필요한 소프트웨어와 로봇 모델을 조사하고, 아키텍처를 설계하며, 이를 구현하여 결과물인 시뮬레이션을 실제로 구동시키는 것.

AI가 Hakoniwa 생태계를 이해하도록 돕기 위해, 저는 Hakoniwa Business Pack이라는 저장소 (repository)를 사용했습니다.

이 저장소에는 인간과 AI 에이전트 모두가 Hakoniwa 구성 요소들을 어떻게 결합할 수 있는지 이해하도록 돕기 위한 카탈로그, 레시피, 런타임 (runtime) 지식 및 기타 정보가 포함되어 있습니다.

첫 번째 실험: AgileX Tracer

제가 처음 시도한 로봇은 AgileX Tracer였습니다.

Tracer를 위한 ROS 저장소가 공개되어 있으며 URDF 모델을 포함하고 있습니다.

저의 요구 사항은 간단했습니다:

• 기존 ROS URDF 재사용
• Gazebo 대신 MuJoCo 사용
• macOS에서 실행
• 공통 ROS 2 Twist 메시지 기반의 제어 인터페이스 사용
• 에셋을 불필요하게 Tracer 전용으로 만들지 말 것
• 우선 MuJoCo에서 작동하게 만든 다음, 이를 Hakoniwa 에셋으로 변환하고, Python으로 제어할 것

다시 말해:

"이 기존 ROS 로봇 모델을 가져와서, 내 Mac의 MuJoCo에서 실행하고, Twist와 유사한 속도 명령을 사용하여 제어하고 싶습니다."

저는 이러한 요구 사항을 AI에게 전달했습니다.

저는 다음과 같이 말하지 않았습니다:

이 파일을 수정하고, 이 C++ 클래스를 생성하고, 이 API를 호출하세요.

대신, 저는 먼저 AI에게 Hakoniwa Business Pack을 이해하도록 요청했습니다.

hakoniwa-business-pack을 이해하세요.

AI는 사용 가능한 컴포넌트, 런타임 컨벤션 (runtime conventions), 그리고 기존 예제들을 이해하기 위해 README, 카탈로그, 레시피(recipes), 그리고 문서를 읽었습니다.

그 다음 저는 다음과 같이 요청했습니다:

AgileX Tracer URDF를 사용하여,
Hakoniwa 시뮬레이션 환경을 구축하기 위한 레시피를 생성하세요.

그 결과 나타난 아키텍처는 대략 다음과 같았습니다:

AgileX Tracer URDF / 로봇 모델
        ↓
hakoniwa-mbody-registry
...

중요한 점은 Python 프로그램이 MuJoCo를 직접 조작하지 않는다는 것입니다.

MuJoCo는 Hakoniwa 에셋으로서 실행됩니다.

컨트롤러는 ROS 2의 geometry_msgs/msg/Twist를 기반으로 한 PDU를 통해 명령을 전송합니다.

이를 통해 우리는 MuJoCo와 Hakoniwa를 사용하여 시뮬레이션 자체를 구성하는 동시에, ROS의 개념과 데이터 정의를 재사용할 수 있습니다.

AI가 실제로 수행한 작업

요구 사항과 기존 Hakoniwa 지식을 바탕으로, AI는 다음과 같은 작업들을 수행했습니다:

• 기존 Tracer URDF 및 변환된 모델 검사 (inspecting)
• MuJoCo에서 모델을 로드하는 데 필요한 최소한의 월드 (world) 확인
• 좌우 바퀴를 위한 액추에이터 (actuators) 추가
• geometry_msgs/Twist에 대응하는 PDU 준비
• Twist 명령을 바퀴 속도로 변환하는 Hakoniwa 에셋 (asset) 구현
• linear.x 및 angular.z를 위한 Python 송신기 (sender) 구현
• 실행 절차 문서화
• 실제로 검증된 내용을 바탕으로 레시피 (recipe) 업데이트

예를 들어, 결과물로 나온 명령 인터페이스 (command interface)는 다음과 같이 사용할 수 있습니다:

python3.12 examples/actuators/agilex_tracer/send_rover_twist.py \
  --linear-x 0.2 \
  --duration-sec 4

Hakoniwa에서는 실행 순서 또한 중요합니다.

먼저, MuJoCo 에셋 (asset)을 시작합니다:

./src/cmake-build/examples/actuators/agilex_tracer/rover-twist-hakoniwa-asset

에셋이 스스로를 등록하고 대기합니다:

hako_asset_register :RoverTwistAsset
asset(RoverTwistAsset) is registered.
WAIT START

그 다음 Python 송신기 (sender)를 시작합니다:

python3.12 examples/actuators/agilex_tracer/send_rover_twist.py \
  --linear-x 0.2 \
  --duration-sec 4

이 또한 대기합니다:

Rover Twist sender is registered.
WAIT START

에셋들이 준비되면, 시뮬레이션 (simulation)을 시작합니다:

/usr/local/hakoniwa/bin/hako-cmd start

그러면 Python 송신기가 Twist PDU를 발행 (publish)하고, MuJoCo에서 Tracer가 앞으로 이동합니다.

에셋 로그에는 명령과 변화하는 베이스 (base) 위치가 표시되었습니다:

Rover Twist Hakoniwa asset started.
time=0.502 base=(0.017, 0.000, 0.142) cmd=(0.200, 0.000)
time=1.002 base=(0.055, 0.000, 0.142) cmd=(0.200, 0.000)
...

따라서 전체 경로는 다음과 같았습니다:

ROS URDF
  → MuJoCo 모델 (model)
  → Hakoniwa 에셋 (asset)
...

그리고 이 모든 과정은 제 Mac에서 실행되었습니다.

실패 또한 유용했습니다

AI가 첫 시도에 모든 것을 완벽하게 해낸 것은 아닙니다.

예를 들어, 로봇 모델을 변환한 후 로봇 중앙 근처에 커다란 바퀴 모양의 프리미티브 (primitive)가 나타나 자세 (posture)에 영향을 주기도 했습니다.

이는 유용한 교훈으로 이어졌습니다: URDF/MJCF 변환 과정에서 프리미티브 (primitive)나 충돌 기하 구조 (collision geometry)가 추가될 때, 시각화 (visualization)와 접촉 동작 (contact behavior) 모두에 영향을 줄 수 있다는 점입니다.

우리는 이를 일회성 수정으로 처리하는 대신, 해당 지식을 Hakoniwa Business Pack에 다시 피드백했습니다.

이는 실험 과정에서 중요한 패턴이 되었습니다:

개발 루프 (The development loop)

1. AI가 기존 지식을 읽습니다.
2. AI가 무언가를 구축하고 실행합니다.
3. 실패나 누락된 가정이 나타납니다.
4. 인간과 AI가 함께 이를 조사합니다.
5. 결과가 재사용 가능한 지식으로 전환됩니다.
6. 다음 AI 세션은 더 나은 베이스라인 (baseline)에서 시작됩니다.

이 피드백 루프는 시뮬레이터 자체만큼이나 저에게 흥미롭게 다가왔습니다.

로봇 팔에 동일한 접근 방식 적용하기

다음으로, 저는 동일한 패턴이 완전히 다른 유형의 로봇에도 작동하는지 확인하고 싶었습니다.

저는 **FR5 로봇 팔 (robot arm)**을 시도했습니다.

Twist와 같은 속도 명령 (velocity commands) 대신, 로봇 팔에는 조율된 관절 운동 (coordinated joint motion)이 필요합니다.

따라서 우리는 ROS의 trajectory_msgs/JointTrajectory를 기반으로 한 PDU를 사용했습니다.

다시 한번, 저는 AI에게 아키텍처 수준의 요구 사항을 전달했습니다:

FR5 팔을 Hakoniwa 에셋 (asset)으로 실행하고 싶습니다.
인터페이스는 JointTrajectory를 기반으로 해야 합니다.
먼저 미리 정의된 궤적 (trajectory)을 재생하는 것부터 시작합시다.

결과적으로 만들어진 구조는 다음과 같습니다:

FR5 URDF / MuJoCo 모델
        ↓
Hakoniwa 팔 에셋
...

데모에서 Python 송신기는 9개 지점의 관절 궤적을 전송했습니다.

에셋은 다음과 같이 보고했습니다:

Accepted JointTrajectory: joints=6 points=9

그리고 로봇 팔은 홈 포즈 (home pose)로 돌아가기 전 MuJoCo 뷰어에서 해당 궤적을 재생했습니다.

로봇은 Tracer와 완전히 달랐지만, Hakoniwa 런타임 (runtime) 패턴은 거의 동일하게 유지되었습니다:

에셋 등록 (register asset) → 시작 대기 (wait for start) → PDU 교환 (exchange PDUs) → 시뮬레이션 실행 (run simulation)

그다음은 4족 보행 로봇: Unitree Go1

세 번째 실험은 Unitree Go1이었습니다.

이 로봇은 4개의 다리와 12개의 제어 가능한 관절을 가지고 있어, 로버 (rover)나 로봇 팔과는 상당히 다릅니다.

이 실험을 위해 저는 MuJoCo Menagerie의 Go1 모델을 사용했습니다.

제어 인터페이스는 12개의 요소를 가진 std_msgs/Float64MultiArray를 기반으로 했습니다:

Go1 MuJoCo Menagerie 모델
        ↓
Hakoniwa 사족 보행 관절 에셋 (quadruped joint asset)
...

여기서 얻은 중요한 교훈 중 하나는 12개 관절 값의 순서가 중요하다는 점이었습니다. 순서가 잘못되면 개별 다리가 예상치 못한 방식으로 움직입니다.

또 다른 중요한 차이점은 용어입니다.

우리가 구현한 것은 **개루프 동작 재생 (open-loop motion playback)**이었습니다.

이는 지형이나 외란에 맞서 로봇의 균형을 동적으로 잡는 보행 제어기 (walking controller)가 아니었습니다.

우리는 향후 AI 세션에서 이 데모를 보행 제어기로 잘못 설명하지 않도록, Business Pack 지식에 이 차이점을 명시적으로 기록했습니다.

세 대의 로봇, 하나의 개발 패턴

로봇들과 그 제어 인터페이스는 상당히 달랐습니다:

하지만 AI가 따르는 프로세스는 놀라울 정도로 유사했습니다.

AI는 다음과 같은 질문들에 반복적으로 답해야 했습니다:

• 기존의 어떤 에셋을 재사용할 수 있는가?
• 어떤 Hakoniwa 구성 요소가 필요한가?
• 제어 PDU는 어떤 형태여야 하는가?
• 먼저 검증할 수 있는 가장 작은 유용한 시뮬레이션은 무엇인가?
• 결과가 실제로 작동한다는 것을 어떻게 알 수 있는가?

이 지점에서 Hakoniwa Business Pack이 중요해졌습니다.

두 번째 데모: 세 로봇 실험의 통합

이 기사 서두에 있는 첫 번째 영상은 최신 결과를 보여줍니다.

저는 또한 위에서 설명한 세 가지 로봇 실험 — AgileX Tracer, FR5, 그리고 Unitree Go1 — 에 특화된 이전 데모도 기록했습니다.

이 세 대의 매우 다른 로봇을 나란히 보는 것은 중요한 사실 하나를 확인시켜 주었습니다. 로봇별 제어 인터페이스는 바뀌지만, 전반적인 개발 패턴은 놀라울 정도로 일관되게 유지된다는 점입니다.

Hakoniwa Business Pack이 중요한 이유

Hakoniwa 자체도 많은 구성 요소(components)를 제공하지만, AI 에이전트의 관점에서는 거대한 생태계를 탐색하는 것이 어려울 수 있습니다.

어떤 리포지토리(repository)를 조사해야 할까요?

PDU Registry를 사용해야 할까요, 아니면 MBody Registry를 사용해야 할까요?

Conductor는 누가 시작해야 하나요?

hako-cmd start는 언제 실행되어야 할까요?

README에 있는 명령어가 단순히 독립적인 예시인가요, 아니면 검증된 워크플로우 (workflow)의 일부인가요?

Hakoniwa Business Pack은 지도 역할을 합니다.

개념적으로, 이는 정보를 다음과 같은 것들로 정리합니다:

Catalog
  → 어떤 구성 요소들이 존재하는가?

...

이는 AI가 생태계에 접근하는 방식을 변화시킵니다.

무작위로 리포지토리를 열고 소스 코드 (source code)로부터 모든 것을 추론하려고 시도하는 대신, 사용자의 목표에서 시작하여 역으로 추적할 수 있습니다.

AI에게 의견을 물어보았습니다

실험을 마친 후, 저는 AI 코딩 에이전트에게 질문을 던졌습니다:

Hakoniwa가 무엇을 가능하게 만들었으며, AI 에이전트의 관점에서 Hakoniwa Business Pack의 유용한 점은 무엇이었나요?

그 답변은 흥미로웠습니다.

AI는 Hakoniwa가 없다면 자연스럽게 다음 두 가지 접근 방식 중 하나로 기울었을 것이라고 설명했습니다: