(본 게시물의 이미지에는 AI 번역을 사용한 이미지가 포함되어 있습니다.)
(모든 이미지/동영상은 직접 캡쳐한 것입니다.)
앞선 작업에서는 루미(OpenClaw), Codex, Unity를 연결하고 Project VX에서 사용할 Git/GitHub 작업 권한과 루미·Codex의 역할을 정리하였다.
이제 각각의 도구가 연결되어 있다는 사실만 확인하는 것을 넘어, 실제로 작은 게임 하나를 처음부터 만들어보면서 전체 개발 흐름이 제대로 동작하는지 시험해보기로 하였다.
다만 이번 테스트에서는 Project VX의 본편 기획을 사용하지 않았다. 본편 시스템과 섞이지 않는 별도의 미니게임을 현재 Unity Project 안에 만들고, 필요하면 나중에 쉽게 제거할 수 있도록 독립적으로 구성하는 것을 조건으로 두었다.
첫 게임 개발 테스트
테스트용 게임은 간단한 2D 회피 생존 미니게임으로 정하였다.
세부 구조는 직접 설계하지 않고, 필요한 기능과 제약만 루미에게 전달한 뒤 현재 Project 상태를 확인해서 구현 방식을 판단하도록 하였다.
ゆならん: Project VX 본편 기획과는 별개로, 현재 Unity 프로젝트 안에 하나의 검증용 간단한 2D 회피 생존 미니게임을 만들어줘.
플레이어 이동, 랜덤하게 등장하는 위험 요소, 충돌 시 게임오버, 생존 시간 기반 점수, 재시작 기능이 있으면 돼.
구체적인 구현 구조와 세부 설계는 현재 프로젝트 상태를 확인해서 적절하게 판단해줘. 본편 시스템과 강하게 결합하지 말고 나중에 쉽게 제거할 수 있도록 독립적으로 구성해줘. 가능한 범위에서 Unity로 실제 동작까지 검증하고 결과를 보고해줘. Git commit/push는 하지 마.
이번 요청에서 중요한 부분은 단순히 게임 하나를 만들어달라는 것이 아니었다.
나는 이동 방식이나 Class 구조, Scene 구성, 위험 요소 생성 방식 등을 직접 지정하지 않았다. 루미와 Codex가 현재 Unity Project 상태를 읽고 필요한 구현 구조를 스스로 판단하게 하였다.
동시에 본편 작업과 섞이지 않도록 하고, Git Commit과 Push 역시 하지 않도록 제한하였다.
본편과 분리된 테스트용 구조
구현 결과는 Assets/HarnessSurvival/ 아래에 별도의 테스트용 Scene과 Script를 배치하는 형태로 만들어졌다.
주요 파일은 다음과 같았다.
HarnessSurvivalScene.unityHarnessGameController.csHarnessPlayerController.csHarnessHazard.cs
기존 SampleScene과 본편용 파일을 직접 수정하는 대신, 테스트에 필요한 요소를 하나의 폴더 안에 모아 나중에 쉽게 분리하거나 제거할 수 있도록 구성하였다.
Unity에서 Scene을 열었을 때 Hierarchy에는 HarnessSurvivalGame이라는 독립적인 Root Object가 생성되어 있었다.
Edit Mode에서는 Game View에 No cameras rendering이 표시되었지만, 이는 전용 Camera와 게임 요소를 Runtime에 생성하는 구조였기 때문이다.
실제로 Play Mode에 진입하면 미니게임에 필요한 화면이 생성되었다.
구현된 미니게임
완성된 미니게임은 사각형 Arena 안에서 Player가 무작위로 등장하는 위험 요소를 피하며 최대한 오래 살아남는 구조였다.
Player는 WASD 또는 방향키로 이동할 수 있으며 Arena 밖으로 나갈 수 없도록 이동 범위가 제한되었다.
위험 요소는 무작위 위치와 간격으로 생성되고, 화면 안을 이동한다.
Player가 위험 요소와 충돌하면 즉시 Game Over 상태가 된다.
화면에는 현재 생존 시간과 회피한 위험 요소의 수가 표시되며, Game Over 이후에는 R, Enter, Space 가운데 하나를 눌러 다시 시작할 수 있도록 구현되었다.
별도의 Sprite Asset을 준비하지 않았기 때문에 시각 요소는 Runtime Primitive를 이용해 간단하게 표현하였다. 이번 테스트의 목적은 게임의 완성도나 디자인이 아니라, 자연어 요청만으로 독립적인 게임 기능을 구성하고 Unity에서 실제 실행까지 이어갈 수 있는지를 확인하는 것이었기 때문에 이 정도면 충분했다.
Unity에서 실제 동작 검증
구현이 끝난 뒤 루미는 Unity Editor와 Pipeline을 이용해 결과를 검증하였다.
보고된 구현 내용은 다음과 같았다.
WASD/ 방향키 이동 및 Arena 경계 제한- 랜덤 위치·간격의 위험 요소 생성
- 충돌 시 Game Over
- 생존 시간과 위험 요소 회피 수 표시
R/Enter/Space재시작- Runtime Primitive 시각 요소와 전용 Camera 사용
- 기존
SampleScene및 본편 시스템과 분리
Unity 6000.5.7f1 Editor와 Pipeline 연결 및 Compile도 정상적으로 이루어졌다.
Play Mode에서는 실제 게임 요소가 생성되는 것을 확인하였고, 약 4.44초 동안 생존한 상태에서 위험 요소 3개가 활성화되어 있는 것도 확인하였다.
충돌 이후에는 gameOver = true가 되는 것을 확인하였으며, 재시작하면 elapsedTime = 0, gameOver = false 상태로 돌아오는 것도 검증하였다.
Player 이동 역시 테스트 전후의 위치 값이 달라지는 것으로 확인하였다.
검증이 끝난 뒤에는 Scene을 저장하고 Play Mode를 종료한 상태로 남겨두었다.
요청한 대로 Git Commit이나 Push는 수행하지 않았다.
검증 과정에서 Unity의 Audio 장치 변경과 관련된 환경 Warning이 1건 확인되었지만, 미니게임 코드와 관련된 Compile 또는 Runtime Error는 확인되지 않았다.
게임의 주요 설정 확인
미니게임의 여러 값은 HarnessGameController에서 관리하도록 구성되어 있었다.
Inspector에서는 Arena 크기와 Hazard 생성 간격, 이동 속도, 최대 활성화 개수 등을 확인할 수 있었다.
당시 설정은 대략 다음과 같았다.
- Arena Half Width:
8 - Arena Half Height:
4.5 - Hazard Spawn Interval:
0.65 ~ 1.35 - Hazard Speed:
2.4 ~ 4.1 - Maximum Active Hazards:
36
즉 단순히 화면에 Object 몇 개를 배치한 것이 아니라, 게임의 진행을 담당하는 Controller와 Player, Hazard의 역할을 나누어 작은 게임 하나가 독립적으로 돌아갈 수 있는 구조를 만들어둔 상태였다.
직접 실행해보기
자동 검증 결과만 확인하지 않고 Unity Editor에서도 실제 미니게임을 실행해보았다.
위험 요소가 Arena 바깥쪽과 내부에서 등장하고, 시간이 지나면서 화면을 이동하였다.
Player가 위험 요소에 닿으면 Game Over UI가 표시되고, 최종 생존 시간이 기록되었다.
화면이나 게임성 자체는 매우 단순했지만, 이번 테스트에서 보고 싶었던 부분은 충분히 확인할 수 있었다.
처음 요청할 때는 Scene 이름이나 Script 구성조차 정하지 않았지만, 결과적으로 별도의 Scene과 Controller, Player, Hazard Script가 구성되고 실제로 플레이 가능한 상태까지 만들어졌다.
개발 도중 모델 전환도 확인
미니게임 구현과 직접적인 기능은 아니지만, 이번 테스트를 진행하면서 루미의 모델 Routing이 실제로 어떻게 동작하는지도 다시 확인하였다.
당시 Codex의 정확한 잔여 사용량을 직접 조회할 수 있는 상태는 아니었고, OpenClaw에서 확인할 수 있는 최근 사용 기록만 볼 수 있었다.
이 과정에서 루미에게 작업 중간의 모델 전환을 누가 판단하는지 물어보았다.
ゆならん: 루미야 중간중간 모델 바꾸는 건 네가 하는거지?
루미는 일반적인 작업에서는 Luna를 사용하고, 복잡한 설계나 고위험 Debugging처럼 필요하다고 판단한 경우 Sol로 전환하며, 실제 구현을 담당하는 Codex의 모델 Routing은 별도로 관리한다고 설명하였다.
당시 미니게임 구현은 Codex의 Luna 계열 모델로 진행 중이었다.
설명만 듣고 끝내지 않고 실제로 루미의 모델을 잠시 Sol로 전환한 뒤 다시 Luna로 돌아오게 해보았다.
ゆならん: 루미야 한 번 모델을 sol로 바꿨다가 다시 Luna로 돌아와볼래?
루미는 Sol로 잠시 전환한 뒤 다시 Luna로 돌아왔고, 최종적으로 현재 모델이 openai/gpt-5.6-luna라고 보고하였다.
이 부분은 게임 구현 자체와는 별개의 테스트였지만, Project VX에서 생각했던 루미가 작업 성격에 따라 자신의 모델을 선택하고, 실제 구현은 Codex에 별도로 위임하는 구조가 실제 운영에서도 적용될 수 있음을 확인하는 계기가 되었다.
이번 테스트에서 확인한 것
이번 첫 게임 개발 테스트에서는 단순한 기능 하나가 아니라, 아주 작더라도 처음부터 끝까지 플레이 가능한 게임 하나를 만들어보았다.
사용자가 전달한 것은 2D 회피 생존 게임이라는 목적과 필요한 기능, 그리고 본편과 분리해야 한다는 제약 정도였다.
구체적인 Scene 구조와 Script 분리는 루미와 Codex가 현재 Project 상태를 확인한 뒤 결정하였다.
그 결과 본편과 분리된 HarnessSurvival 영역 안에 Player 이동, Hazard 생성, Collision, Game Over, Score, Restart까지 포함된 작은 게임이 만들어졌다.
또한 Unity Editor와 Pipeline을 통해 Compile, Runtime Object 생성, Player 이동, 충돌, Game Over, Restart까지 실제 상태를 검증하였다.
이번 테스트를 통해 최소한 작은 규모에서는 다음과 같은 흐름이 실제로 동작하는 것을 확인할 수 있었다.
사용자 요청 → 루미의 판단 → Codex 구현 → Unity 실행 및 검증 → 루미 결과 보고
그리고 별도로 루미 자신의 Luna / Sol 모델 전환도 실제로 확인하였다.
결론
Test #1 버전 테스트 영상
Project VX의 첫 게임 개발 테스트에서는 본편 기획과 무관한 별도의 2D 회피 생존 미니게임을 제작하였다.
이번에는 사용자가 구현 구조를 세세하게 지시하지 않고 게임의 목적과 필요한 기능만 전달하였다.
그 결과 루미와 Codex가 현재 Unity Project 상태를 기준으로 Assets/HarnessSurvival/이라는 독립적인 영역을 만들고, 별도의 Scene과 Script를 구성하여 실제 플레이 가능한 형태까지 구현하였다.
또한 코드 작성에서 끝나는 것이 아니라 Unity Editor와 Pipeline을 통해 Compile과 Runtime 상태, Player 이동, Collision, Game Over, Restart까지 검증하였다.
아직 매우 작은 테스트였지만, Project VX에서 구상했던 루미 → Codex → Unity 개발 경로를 처음으로 하나의 게임 단위에서 끝까지 사용해본 사례가 되었다.
다음 단계에서는 사용자가 기능을 하나씩 직접 지시하는 방식에서 더 나아가, 루미가 Project VX의 기획 문서를 읽고 현재 개발 상태와 앞으로 해야 할 작업을 스스로 정리할 수 있도록 만드는 방향으로 넘어갈 예정이다.
한국어 본문은 준비 중입니다. 원문은 일본어로 읽을 수 있습니다.