[VX] 01. 루미-코덱스-유니티 첫 연결 시도

(본 게시물의 이미지에는 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에 추가할 예정이다.