(본 게시물의 이미지에는 AI 번역을 사용한 이미지가 포함되어 있습니다.)
(모든 이미지/동영상은 직접 캡쳐한 것입니다.)
가장 먼저 루미(Openclaw), Codex, Unity CLI 및 MCP 각각을 설치하였다. (각각의 구현 과정은 일반적인 방법을 따랐기에, 별개의 투고를 작성하지는 않았다.)
그 이후, 루미와 Discord를 연결하여 원격으로 컨트롤이 가능하도록 설정하였다.
이상적인 구현의 형태
궁극적으로 내가 원하던 구조는 다음과 같다:
| ㅤ | ゆならん（나） | ㅤ |
|---|---|---|
| ㅤ | ↓ | ㅤ |
| ㅤ | ルミ(Openclaw) | ㅤ |
| (重い作業) | ↓ | (普通な作業) |
| ↓ | <—> | ↓ |
| GPT 5.6 Sol Medium | ㅤ | GPT 5.6 Luna xHigh |
| —> | >—< | <— |
| ㅤ | ↓ | ㅤ |
| ㅤ | Codex (GPT 5.6 Sol Medium or Luna xHigh) | ㅤ |
- 1. 내가 루미에게 명령을 내린다.
- 2. 루미는 게임 기획에 대한 Obsidian 문서를 읽고, 필요한 작업 계획을 분류한다.
- 3. 루미는 분류한 작업 계획과 명령을 바탕으로 실제 작업을 분류한다. 이 때, 무거운 작업은 Sol Medium을, 일반적인 작업은 Luna xHigh를 사용한다.
- 4. 루미는 Codex의 각각의 에이전트에게 필요한 작업을 분배한다. 이 때, 에이전트는 동시에 3개까지만 만들 수 있다.
- 5. Codex가 작업을 모두 끝내면, 루미는 작업에 대한 검증을 진행한다. 필요한 경우, Codex를 통해 검증할 수 있다.
- 6. 루미는 작업이 완료되면, 검증 결과와 구현 결과를 나에게 전달한다.
즉, 각각의 역할을 다음과 같이 나눌 수 있는 것이다.
| ルミ(Openclaw) | Codex | Unity |
|---|---|---|
| Orchestration | Implementation | Actual Game Development Environment |
위와 같은 구조를 구현하기 위해 가장 먼저, Codex와 Unity CLI, 그리고 루미와 Codex를 먼저 연결하고자 하였다.
Codex와 Unity 프로젝트 연결
처음부터 복잡한 Agent 구조를 만든 것은 아니다. 가장 먼저 확인해야 했던 것은 이것이었다.
Codex가 Project VX의 Unity 프로젝트에 실제로 접근할 수 있는가?
미리 Project VX의 Unity 프로젝트를 Codex의 Workspace로 지정해둔 만큼, Codex는 프로젝트 파일에 정상적으로 접근했고 SampleScene.unity까지 확인할 수 있었다. Unity CLI와 MCP 역시 이후 Editor 연동을 위해 별도로 설정해둔 상태였다.
그래서 정말 수정도 가능한지 알아보기 위해 아주 단순한 테스트를 해봤다.
ゆならん: (0, 0, 0) 위치에 Scale (1, 1, 1)인 Cube를 하나 만들어줘.
그 결과, Codex는 SampleScene.unity를 직접 수정했고 Scene 안에 Cube를 추가했다.
당시 결과는 대략 다음과 같았다.
Position : (0, 0, 0)
Scale : (1, 1, 1)
Mesh Renderer 포함
Box Collider 포함
그리고 실제 Unity Editor로 돌아가 확인해보니, Hierarchy에 Cube가 추가되어 있었다.
이를 통해 최소한 Codex App을 통해 Unity 프로젝트에 접근하고, Scene을 수정할 수 있다는 것을 확인하였다.
ルミ(Openclaw)와 Codex 연결
다만 문제는 Codex가 Unity 프로젝트를 수정할 수 있느냐가 아니었다. 사실 프로젝트 디렉터리에 파일 쓰기 권한만 있다면 C# 파일은 물론이고 Unity의 YAML Scene 파일 역시 수정할 수 있다.
하지만 Project VX에서 최종적으로 원하는 것은 「나 → Codex → Unity」가 아니다. 그래서 다음 단계는 루미가 돌아가는 OpenClaw와 Codex를 연결하는 것이었다.
처음에는 단순히 OpenClaw가 codex exec 같은 CLI 명령을 실행하는 방식이라고 생각했는데, 실제 구조를 확인해보니 조금 달랐다. OpenClaw의 Codex 플러그인은 별도의 Codex app-server harness를 사용하고 있었다.
이를 알게된 계기는 루미에게 간단한 Unity 테스트를 요청한 결과였다.
ゆならん: Project_VX의 Unity 프로젝트에서 SampleScene에 있는 Cube가 Play Mode에서 Y축을 기준으로 계속 회전하도록 구현해줘. 구현 후 Unity에서 정상 작동하는지 확인하고, Console 오류가 있다면 원인을 찾아 수정해줘. 기존 오브젝트나 관련 없는 파일은 불필요하게 수정하지 마.
**ルミ: 확인 완료했어요. VX-cube-y-rotation-retry 는 현재 실행 중인 작업이 없고 실패 종료된 상태라, 추가 재시도하지 않았습니다.
구현 결과:
CubeRotator.cs
Update()에서 Time.deltaTime 기반으로 Y축 회전
• 기본 회전 속도 90°/초
SampleScene. unity
• Cube에 CubeRotator 연결
rotationSpeed: 90 설정
Unity 검증은 코드 문제가 아니라 동일한 환경 문제로 완료되지 않았습니다.
attempt to write a readonly database
• UPM 소켓 생성 실패: listen EPERM
• Unity Licensing Client handshake 및 초기화 timeout
• Pipeline 패키지가 설치된 실행 중 Unity Editor 인스턴스 없음
따라서 실제 Play Mode에서 회전하는 장면과 Console 무오류 상태는 확인하지 못했습니다. 코드 컴파일 오류는 로그에서 발견되지 않았고, 추가 수정은 하지 않았습니다.**
이후 원인을 별도로 조사한 결과, 이 오류들은 Cube 구현 자체에서 발생한 것이 아니라 Unity Licensing Client와 UPM IPC 등 별도의 Unity 실행 환경에서 발생한 문제로 확인되었다. 특히 당시 검증 방식은 실행 중인 Editor를 재사용하는 것이 아니라 별도의 Unity 실행 환경에 의존하고 있었기 때문에 Licensing 및 UPM 초기화 문제의 영향을 그대로 받고 있었다.
큐브 회전 테스트 영상
루미를 통한 자동 검증은 Unity 환경 문제로 완료되지 않았지만, 구현 자체는 완료되어 있었고 내가 Unity Editor에서 직접 실행해본 결과 Cube의 회전은 정상적으로 작동했다. 즉, 구현에는 성공했지만 루미가 그 결과를 직접 관찰하고 검증할 수 없는 상태였다.
확인 당시 프로세스 구조는 대략 다음과 같았다.
OpenClaw Gateway
└─ OpenClaw Codex Plugin
└─ Codex app-server
└─ Codex
즉 루미가 매번 터미널에서
codex exec …
를 실행하는 것이 아니라, OpenClaw와 Codex app-server 사이에 지속적인 통신 경로를 만들어 놓고 그 경로를 통해 작업을 위임하는 구조였다.
따라서, 원래는 Codex App을 통해 연결하고 싶었지만, 그 대신 현재 구조를 활용해 Codex app-server와 OpenClaw를 연결하는 방식으로 구현하기로 하였다.
unity pipeline install
을 통해 Pipeline을 설치하였다. 이를 통해 외부 도구가 현재 실행 중인 Unity Editor를 탐색하고, Scene·Play Mode·Console 등의 상태를 조회할 수 있는 경로를 확보했다. 이후 이를 Codex app-server 기반의 구현 경로와 결합하여, 루미가 Codex를 통해 구현을 맡기고 실행 중인 Unity Editor에서 그 결과를 검증할 수 있도록 구성하였다
그 이후, 루미와 Codex app-server의 연결을 재확인 하였다.
ゆならん: 현재 실행 중인 Project_VX_Unity Editor에 Codex를 통해 연결해 서, 현재 열린 Scene 이름과 Play Mode 상태, Console의 Error/Warning 개수를 확인해줘. 프로젝트 파일은 수정하지 말고 별도 Unity 인스턴스도 실행하지 마
ルミ: 확인 완료했어요, ゆならん님. Codex app-server를 통해 현재 실행 중인 Editor에 읽기 전용으로 연결 했습니다.
• Unity 6000.5.7f1, PID 69496, 상태 ready
• Scene: SampleScene
• Play Mode: 중지됨
Console: Error 0, Warning 0
Scene: 저장되지 않은 변경 없음
• 프로젝트 파일 및 시스템 설정 변경 없음
• 별도 Unity/batch 인스턴스 실행 없음
확인 완료했어요, ゆならん님. Codex app-server를 통해 현재 실행 중인 Editor에 읽기 전용으로 연결했습니다.
• Unity 6000.5.7f1, PID 69496
• 상태: ready
• Scene: SampleScene
Assets/Scenes/SampleScene.unity
• active, not dirty
• Play Mode: stopped
• Console:
• Error: 0
• Warning: 0
프로젝트 파일 변경, Editor 추가 실행.재시작종료는 없었습니다.NO_REPLYNO_REPLY
연결에 성공한 직후, 루미에게 간단한 테스트를 요청하였다.
ゆならん: Project_VX의 SampleScene에 간단한 3D 플레이어 이동 프로토타입을 구현해줘. Capsule을 Player로 사용하고 WASD로 XZ 평면을 이동할 수 있도 록 해줘. 이동 속도는 Inspector에서 조절할 수 있게 해줘. 기존 Cube와 CubeRotator는 유지해줘. 구현이 끝나면 Unity Play Mode에서 정상적으로 실행되는지 확인 하고 Console Error/Warning도 확인해줘. 관련 없는 파일은 수정 하지 마
ルミ: Model Fallback: codex/gpt-5.6-luna (selected openai/gpt-5.6-luna; Rate limit reached for gpt-5.6-luna in organization org-*******************…)
알겠어.여기서 작업을 종료할게
현재까지:
• Player Capsule 및 WASD 이동 구현
• Inspector 조절용 movementSpeed 추가
• 기존 Cube와 CubeRotator 유지
• Play Mode 진입 확인
• Console Error/Warning 0건 확인
더 이상 프로젝트나 Editor는 건드리지 않겠어.
Bash failed: unity status —format json (in ~/Project_VX/Project_VX_Unity)
Usage: 824 in / 84 out • cache 106k cached / 0 new
이어서 추가 요청을 해 보았다.
ゆならん: Project_VX의 기존 Player 이동 기능에 달리기를 추가해줘. Shift를 누르고 있는 동안 이동 속도가 기본 이동 속도의 1.8배가 되 도록 하고, 배율은 Inspector에서 조절할 수 있게 해줘. 구현 후 Unity Play Mode에서 정상 동작하는지 확인하고 Console Error/Warning도 확인해줘. 관련 없는 파일은 수정하지 마.
ルミ: 구현 완료했어.
• PlayerMovement cs 의 기존 Shift 달리기 로직을 유지하고,
SampleScene의 Player에 runMultiplier = 1.8 을 저장
• Inspector에서 달리기 배율 조절 가능
• Cube와 CubeRotator 및 관련 없는 파일은 수정하지 않음
• [SampleScene.unity]
(/Users/jhkim/Project_VX/Project_VX_Unity/Assets/Sce nes/SampleScene.unity:689)
검증 결과:
• Recompile: 성공
• Play Mode: 정상 진입 및 종료
• movementSpeed = 5, runMultiplier = 1.8
• 새 Play Mode 기준 Console Error 0건, Warning 0건
• 실제 키 입력 시뮬레이션은 Pipeline에서 지원되지 않아 자동 테스트는 불가했지만, 좌•우 Shift 입력 코드와 Inspector 값은 확인 했어.
Usage: 365 in / 604 out • cache 134k cached / 0 new
결과적으로 이번 테스트를 통해 루미 → Codex → Unity Editor로 이어지는 핵심 개발 및 검증 경로가 정상적으로 동작한다는 것을 확인할 수 있었다.
다음에는 실제 개발 과정에서 발생하는 Git commit 및 GitHub push까지 고려하여, 관련 권한과 작업 규칙을 AGENTS.md에 추가할 예정이다.
（本投稿の画像には、AI翻訳を使用した画像が含まれています。）
（すべての画像・動画は自分でキャプチャしたものです。）
まず最初に、ルミ（OpenClaw）、Codex、Unity CLI、MCPをそれぞれインストールした。
（それぞれの導入過程は一般的な方法に従ったため、個別の投稿としてはまとめていない。）
その後、ルミとDiscordを接続し、遠隔から操作できるように設定した。
理想的な実装の形
最終的に私が目指していた構成は、次のようなものだった。
| ㅤ | ゆならん（私） | ㅤ |
|---|---|---|
| ㅤ | ↓ | ㅤ |
| ㅤ | ルミ（OpenClaw） | ㅤ |
| （重い作業） | ↓ | （通常の作業） |
| ↓ | <—> | ↓ |
| GPT 5.6 Sol Medium | ㅤ | GPT 5.6 Luna xHigh |
| —> | >—< | <— |
| ㅤ | ↓ | ㅤ |
| ㅤ | Codex （GPT 5.6 Sol Medium or Luna xHigh） | ㅤ |
-
1. 私がルミに指示を出す。
-
2. ルミはゲーム企画に関するObsidianのドキュメントを読み、必要な作業計画を整理する。
-
3. ルミは整理した作業計画と指示をもとに、実際の作業を分類する。この際、重い作業にはSol Mediumを、通常の作業にはLuna xHighを使用する。
-
4. ルミはCodexの各エージェントに必要な作業を割り振る。この際、エージェントは同時に最大3つまで作成できる。
-
5. Codexがすべての作業を終えると、ルミがその作業内容を検証する。必要に応じて、Codexを通して追加検証を行う。
-
6. 作業が完了すると、ルミは検証結果と実装結果を私に報告する。
つまり、それぞれの役割は次のように分けることができる。
| ルミ（OpenClaw） | Codex | Unity |
|---|---|---|
| Orchestration | Implementation | Actual Game Development Environment |
このような構成を実現するため、まずはCodexとUnity CLI、そしてルミとCodexを接続することにした。
CodexとUnityプロジェクトの接続
最初から複雑なAgent構成を作ったわけではない。
まず確認する必要があったのは、次の点だった。
CodexはProject VXのUnityプロジェクトへ実際にアクセスできるのか？
あらかじめProject VXのUnityプロジェクトをCodexのWorkspaceとして指定していたため、Codexはプロジェクトファイルへ正常にアクセスし、SampleScene.unityまで確認することができた。Unity CLIとMCPについても、その後のEditor連携に備えて別途設定していた。
そこで、本当に変更まで可能なのか確認するため、非常に単純なテストを行った。
ゆならん: (0, 0, 0) の位置に、Scale (1, 1, 1) のCubeを一つ作って。
その結果、CodexはSampleScene.unityを直接編集し、Scene内にCubeを追加した。
当時の結果は、おおよそ次の通りだった。
Position : (0, 0, 0)
Scale : (1, 1, 1)
Mesh Rendererを含む
Box Colliderを含む
そして実際にUnity Editorへ戻って確認したところ、HierarchyにCubeが追加されていた。
これによって、少なくともCodex Appを通じてUnityプロジェクトへアクセスし、Sceneを変更できることを確認した。
ルミ（OpenClaw）とCodexの接続
ただし、問題はCodexがUnityプロジェクトを変更できるかどうかではなかった。
実際、プロジェクトディレクトリへの書き込み権限さえあれば、C#ファイルはもちろん、UnityのYAML形式のSceneファイルも変更することができる。
しかし、Project VXで最終的に実現したい構成は「私 → Codex → Unity」ではない。
そこで次の段階として、ルミが動作するOpenClawとCodexを接続することにした。
最初は単純に、OpenClawが codex exec のようなCLIコマンドを実行する仕組みだと思っていた。しかし実際の構成を確認してみると、少し違っていた。
OpenClawのCodexプラグインは、別途Codex app-server harnessを利用していた。
これに気付いたきっかけは、ルミに簡単なUnityテストを依頼した時だった。
ゆならん: Project_VXのUnityプロジェクトで、SampleSceneにあるCubeがPlay Mode中にY軸を基準として回転し続けるよう実装して。実装後、Unity上で正常に動作するか確認して、Consoleにエラーがある場合は原因を調べて修正して。既存のオブジェクトや関係のないファイルは不必要に変更しないで。
**ルミ: 確認完了しました。VX-cube-y-rotation-retry は現在実行中の作業がなく、失敗終了している状態のため、追加の再試行は行いませんでした。
実装結果:
CubeRotator.cs
Update()内でTime.deltaTimeを基準にY軸回転
• デフォルト回転速度 90°/秒
SampleScene.unity
• CubeにCubeRotatorを接続
rotationSpeed: 90 を設定
Unityでの検証は、コード上の問題ではなく同一の環境問題によって完了できませんでした。
attempt to write a readonly database
• UPMソケット生成失敗: listen EPERM
• Unity Licensing Client handshakeおよび初期化 timeout
• Pipelineパッケージがインストールされた実行中のUnity Editorインスタンスなし
そのため、実際にPlay Modeで回転する様子とConsoleがエラーなしであることまでは確認できませんでした。ログ上ではコードのコンパイルエラーは確認されず、追加の変更は行っていません。**
その後、原因を別途調査した結果、これらのエラーはCubeの実装そのものから発生したものではなく、Unity Licensing ClientやUPM IPCなど、別のUnity実行環境に起因する問題であることが分かった。特に当時の検証方法は、実行中のEditorを再利用するのではなく、別のUnity実行環境に依存していたため、LicensingやUPMの初期化問題の影響をそのまま受けていた。
Cube回転テスト動画
ルミによる自動検証はUnity環境上の問題によって完了できなかったものの、実装自体は完了しており、私がUnity Editor上で直接実行してみたところ、Cubeは正常に回転した。
つまり、実装には成功していたものの、ルミ自身がその結果を直接観察して検証することはできない状態だった。
確認時のプロセス構成は、おおよそ次のようになっていた。
OpenClaw Gateway
└─ OpenClaw Codex Plugin
└─ Codex app-server<br>
└─ Codexつまり、ルミが毎回ターミナル上で
codex exec …
を実行しているわけではなく、OpenClawとCodex app-serverの間に持続的な通信経路を作り、その経路を通して作業を委任する構成だった。
そのため、当初はCodex Appを通して接続したいと考えていたが、代わりに現在の構成を活用し、Codex app-serverとOpenClawを接続する方式で実装することにした。
unity pipeline install
を実行し、Pipelineをインストールした。これによって外部ツールから現在実行中のUnity Editorを検出し、Scene・Play Mode・Consoleなどの状態を取得できる経路を確保した。その後、これをCodex app-serverベースの実装経路と組み合わせ、ルミがCodexへ実装を委任し、その結果を実行中のUnity Editor上で検証できるよう構成した。
その後、ルミとCodex app-serverの接続を再確認した。
ゆならん: 現在実行中のProject_VX_Unity EditorにCodex経由で接続して、現在開いているScene名とPlay Modeの状態、ConsoleのError/Warning件数を確認して。プロジェクトファイルは変更せず、別のUnityインスタンスも起動しないで。
ルミ: 確認完了しました、ゆならんさん。Codex app-serverを通じて、現在実行中のEditorへ読み取り専用で接続しました。
• Unity 6000.5.7f1, PID 69496, 状態 ready
• Scene: SampleScene
• Play Mode: 停止中
Console: Error 0, Warning 0
Scene: 未保存の変更なし
• プロジェクトファイルおよびシステム設定の変更なし
• 別のUnity/batchインスタンス起動なし
確認完了しました、ゆならんさん。Codex app-serverを通じて、現在実行中のEditorへ読み取り専用で接続しました。
• Unity 6000.5.7f1, PID 69496
• 状態: ready
• Scene: SampleScene
Assets/Scenes/SampleScene.unity
• active, not dirty
• Play Mode: stopped
• Console:
• Error: 0
• Warning: 0
プロジェクトファイルの変更、Editorの追加起動・再起動・終了はありませんでした。NO_REPLYNO_REPLY
接続に成功した直後、ルミに簡単なテストを依頼した。
ゆならん: Project_VXのSampleSceneに、簡単な3Dプレイヤー移動プロトタイプを実装して。CapsuleをPlayerとして使用し、WASDでXZ平面を移動できるようにして。移動速度はInspectorから調整できるようにして。既存のCubeとCubeRotatorは残して。実装が終わったらUnity Play Modeで正常に実行できるか確認して、Console Error/Warningも確認して。関係のないファイルは変更しないで。
ルミ: Model Fallback: codex/gpt-5.6-luna (selected openai/gpt-5.6-luna; Rate limit reached for gpt-5.6-luna in organization org-****************… )
分かった。ここで作業を終了するね。
現在まで:
• Player CapsuleおよびWASD移動を実装
• Inspector調整用のmovementSpeedを追加
• 既存のCubeとCubeRotatorを維持
• Play Modeへの移行を確認
• Console Error/Warning 0件を確認
これ以上プロジェクトやEditorには手を加えないよ。
Bash failed: unity status —format json (in ~/Project_VX/Project_VX_Unity)
Usage: 824 in / 84 out • cache 106k cached / 0 new
続けて、追加の依頼も行った。
ゆならん: Project_VXの既存Player移動機能にダッシュを追加して。Shiftを押している間、移動速度が基本移動速度の1.8倍になるようにして、倍率はInspectorから調整できるようにして。実装後、Unity Play Modeで正常に動作するか確認して、Console Error/Warningも確認して。関係のないファイルは変更しないで。
ルミ: 実装完了したよ。
• PlayerMovement.cs の既存Shiftダッシュロジックを維持し、
SampleSceneのPlayerに runMultiplier = 1.8 を保存
• Inspectorからダッシュ倍率を調整可能
• Cube、CubeRotator、および関係のないファイルは変更していない
• [SampleScene.unity]
(/Users/jhkim/Project_VX/Project_VX_Unity/Assets/Scenes/SampleScene.unity:689)
検証結果:
• Recompile: 成功
• Play Mode: 正常に開始・終了
• movementSpeed = 5, runMultiplier = 1.8
• 新しいPlay Mode基準でConsole Error 0件、Warning 0件
• 実際のキー入力シミュレーションはPipelineではサポートされていないため自動テストはできなかったが、左右Shift入力コードとInspectorの値は確認したよ。
Usage: 365 in / 604 out • cache 134k cached / 0 new
結果として、今回のテストを通じて、ルミ → Codex → Unity Editorへと続く中核的な開発・検証経路が正常に動作することを確認できた。
次回は、実際の開発過程で発生するGit commitおよびGitHub pushまで考慮し、関連する権限と作業ルールをAGENTS.mdへ追加する予定である。