[VX] 06. 複雑な企画を読み込み、ルミが自らゲームを実装する (Test #2-1)

(본 게시물의 이미지에는 AI 번역을 사용한 이미지가 포함되어 있습니다.)
(모든 이미지/동영상은 직접 캡쳐한 것입니다.)

이전 작업에서는 루미가 Obsidian에 작성된 Project VX의 기획 문서를 읽고, 이를 기반으로 별도의 Development Plan을 관리할 수 있도록 구성하였다.

이를 통해 다음과 같은 Planning Workflow를 만들 수 있었다.

Obsidian
↓
Project VX Planning
↓
Planning Sync
↓
루미
↓
Development Plan

하지만 아직 실제 게임 개발에는 이를 사용하지 않았다.

루미가 복잡한 기획 문서를 읽고 개발 계획을 세우는 것뿐만 아니라, 그 계획을 실제 Unity 프로젝트 구현까지 연결할 수 있는가?

를 확인할 필요가 있었다. 따라서 이번에는 이전 Test보다 훨씬 복잡한 게임 기획을 작성한 뒤, 내가 세부 구현 과정을 하나씩 지시하지 않고 루미가 기획을 읽어 실제 개발을 진행하도록 테스트해보기로 하였다.

Test Game 02 — LAST SIGNAL

이번 테스트를 위해 LAST SIGNAL이라는 별도의 게임 기획을 작성하였다. 장르는 2.5D 액션 / 탐색 / 퍼즐이며, 예상 플레이타임은 약 10~15분 정도로 설정하였다.

게임의 기본적인 흐름은 다음과 같다.

게임 시작
↓
시작 구역
↓
중앙 Hub
↓
Generator A / Generator B
↓
중앙 송신실 개방
↓
Transmission Sequence
↓
Boss
↓
Game Clear

플레이어는 연구시설 내부의 발전기를 복구하고 중앙 송신기를 재가동해야 한다. Generator A는 전투, Generator B는 Puzzle을 중심으로 구성하고, 두 발전기를 모두 활성화하면 중앙 송신실이 열린다. 그 이후 송신기를 가동하고 방어전과 Boss 전투를 거쳐 구조 신호 송신을 완료하면 게임이 끝나는 구조다.

하지만 이번 테스트의 핵심은 게임 콘텐츠 자체가 아니었다. 기획에서 가장 중요하게 잡은 목적은 여러 시스템이 서로 의존하는 상황에서 Project VX의 개발 Workflow가 정상적으로 동작하는지 확인하는 것이었다. 따라서 게임에는 다음과 같은 시스템을 포함하였다.

• Player Movement / Camera
• 3타 Basic Attack
• Dodge
• Skill 2개
• Damage System
• Enemy 2종
• Enemy State Machine
• Interaction
• Generator
• Puzzle
• Checkpoint
• Game State
• Transmission Sequence
• Boss
• UI
• 전체 Game Flow

첫 번째 Test가

루미 → Codex → Unity

라는 기본적인 게임 제작 파이프라인 자체가 가능한지를 확인하는 실험이었다면, 이번 Test에서는

Planning Document
↓
Development Plan
↓
Milestone
↓
Task 분할
↓
루미 작업 판단
↓
Codex 작업 위임
↓
Unity 구현
↓
기능 검증
↓
Development Plan 갱신

이라는 보다 긴 개발 Cycle이 실제로 유지되는지를 확인하는 것이 목적이었다.

새 테스트를 위해 기존 구현 정리

본격적인 Test #2를 시작하기 전에 먼저 기존 Unity 프로젝트를 정리하였다. 이전 연결 테스트와 Test #1 과정에서 작성했던 테스트용 Script, Scene 구성, GameObject 등이 그대로 남아 있었기 때문이다.

새로운 게임을 구현하는 과정에서 이들이 영향을 주지 않도록, 루미에게 이전 테스트 전용 구현만 제거하도록 요청하였다. 다만 다음 항목은 반드시 보존하도록 하였다.

• .git
• .gitignore
• Git 관련 설정과 이력
• Packages/
• ProjectSettings/
• Unity 자체의 기본 설정
• 이전 테스트와 관련 있는지 확실하지 않은 파일
• Unity 기본 Object

ゆならん: 루미야 Project VX Unity 프로젝트에서 지금까지 테스트 목적으로 작성한 코드, Scene, Prefab, 이전 피하기 게임 관련 Asset 및 GameObject를 모두 제거해줘.

목표는 새 게임 구현을 시작할 수 있는 깨끗한 Unity 프로젝트 상태로 만드는 거야.

단, .git, .gitignore 및 Git 관련 설정/이력은 절대 수정하지 말 것.
Packages/, ProjectSettings/ 등 Unity 프로젝트 자체의 기본 설정은 임의로 초기화하거나 삭제하지 말 것.
내가 추가한 파일인지 Unity 기본 파일인지 불확실한 경우 임의로 삭제하지 말 것.
이전 피하기 게임 및 테스트 구현에 해당하는 파일과 Scene 구성만 제거할 것.

루미는 삭제 작업 이후 실제로 제거한 항목과 유지한 항목을 구분하여 보고하였다. 이전 테스트에서 사용했던 Script와 GameObject 등은 제거하되,

• SampleScene 자체
• Main Camera
• Directional Light
• Global Volume
• Unity 기본 설정
• Git 관련 파일

등은 그대로 유지하였다. 또한 삭제 이후 Unity Editor와 Pipeline 연결 상태, Compile 상태, Console Error까지 다시 확인하였다.

결과적으로 이전 테스트 결과물만 제거한 채 새 게임 구현을 시작할 수 있는 상태를 만들 수 있었다.

LAST SIGNAL 기획을 Planning에 반영

프로젝트를 정리한 이후 Project VX Planning에 LAST SIGNAL의 상세 기획을 추가하였다. 그 다음 루미에게 Planning Sync를 요청하였다. 본래 매일 오전 10시에 cron을 통해 자동적으로 Sync가 필요한지 확인하게 되어있지만, 이번에는 직접 요청하였다.

ゆならん: Project VX Planning Sync를 지금 진행해줄래?

Planning Sync 결과, 이전에 저장되어 있던 Planning Source Hash와 현재 기획 문서의 Hash가 달라진 것이 감지되었다. 따라서 루미는 최신 Project VX Planning을 다시 읽고 새로운 기획 내용을 분석하였다. 그 결과 Development Plan.md 역시 새로운 Test Game에 맞게 갱신되었다.

주요 결과는 다음과 같았다.

• Planning Source 변경 감지
• Test Game 02 — LAST SIGNAL 상세 기획 반영
• 기획의 기능 및 Dependency 분석
• M0~M8의 개발 Milestone 구성
• 현재 Milestone 설정
• 각 Milestone의 Task 및 완료 조건 정리
• Planning Changes 갱신
• Deferred / Unconfirmed 항목 갱신
• Planning Revision 증가
• Rework Required 확인
• 새로운 Planning Source Hash 저장

여기서 중요한 점은 내가 개발을 M0, M1 등의 단계로 직접 나누어 하나씩 지시한 것이 아니라는 점이다. 현재 기획 문서에 포함된 M0~M8 Milestone은 최초 기획안에 있던 내용이 아니라, 이번 Planning Sync 과정에서 루미가 개발 계획으로 정리한 내용을 이후 반영한 것이다.

내가 제공한 것은 LAST SIGNAL이라는 게임의 전체 기획이었다. 루미가 해당 기획을 분석하고 실제 개발을 수행할 수 있도록 Development Plan을 구성하면서 개발 순서와 Milestone을 정리하였다. 그 결과 가장 먼저 진행해야 하는 단계는 M0. Project Bootstrap으로 정리되었다.

Planning Sync 중에는 실제 Unity Project나 Git에는 변경을 가하지 않았다. 이는 이전에 정한

Planning과 Implementation을 분리한다.

는 규칙을 그대로 적용한 것이다. Planning이 완료된 것을 확인한 뒤, 별도의 명령으로 실제 개발을 시작하였다.

ゆならん: Project VX 개발을 시작해줘.

내가 구체적인 구현 내용을 다시 설명한 것은 아니었다. 루미가 Development Plan에서 현재 해야 할 작업을 확인하고 실제 구현을 시작하도록 하였다.

M0 — Project Bootstrap

루미가 Planning을 통해 가장 먼저 정리한 단계는 M0. Project Bootstrap이었다. M0는 본격적인 게임 시스템 구현 이전에 LAST SIGNAL을 개발하기 위한 기본적인 Unity 환경을 만드는 단계였다. 루미는 해당 작업을 Codex에게 위임하였다. 그 결과 다음 내용이 구현되었다.

• Assets/LAST_SIGNAL 전용 Folder 구조
• Input Action 구성
• LAST SIGNAL 전용 Bootstrap Scene
• 기본 Level Blockout
• Player Spawn
• Generator 관련 위치 구성
• Transmission Room 구성
• Camera / Lighting
• 이후 게임 구현에 사용할 기본 테스트 환경

Input 역시 전체 기획에 작성된 조작 체계를 기준으로 설정하였다.

• 이동
• 시점
• 공격
• 회피
• 상호작용
• Skill 1
• Skill 2

구현 이후 루미는 Unity Editor를 통해 결과를 다시 검증하였다.

• Unity Editor 연결 상태 ready
• Scene 저장 여부 확인
• isDirty: false
• Input Asset Compile 확인
• 기존 SampleScene 보존
• Project Settings 보존
• Planning 문서 보존

여기서 흥미로웠던 점은 내가

어떤 Folder를 만들 것인지
어떤 Scene Object를 배치할 것인지
Input Action을 어떤 식으로 구성할 것인지

를 하나씩 지정하지 않았다는 것이다. 상위 기획에서 필요한 요구사항을 읽고, 현재 Milestone에서 필요한 실제 Unity 작업으로 구체화한 뒤 구현했다. 즉,

기획 → 개발 계획 → 실제 구현

사이의 변환을 처음으로 실제 프로젝트에서 확인할 수 있었다.

다음 단계로 이동

M0의 구현과 검증이 완료된 이후 루미는 다음 개발 단계로 넘어갔다. 다음으로 정리된 Milestone은 M1. Player였다. M1에서는 플레이어를 구성하기 위한 다음 기능들이 필요했다.

• Player Movement
• Camera
• Basic Attack
• HP
• Dodge

여기에서도 내가 각 기능의 Script 구조나 구현 방법을 따로 지정하지 않았다. 루미가 현재 기획과 Development Plan을 기준으로 작업 범위를 확인한 뒤 Codex에게 구현을 위임하였다. 또한 이후 단계에서 구현할 Combat System이나 Skill 등의 범위를 불필요하게 앞당겨 구현하지 않도록 하였다.

LAST SIGNAL 기획 자체에서도

Milestone 완료 전 다음 Milestone의 기능을 불필요하게 구현하지 않는다.

는 원칙을 명시해두었기 때문이다.

M1 작업 도중 발생한 Timeout

M0은 비교적 빠르게 완료되었지만 M1은 예상보다 시간이 오래 걸렸다. Movement, Camera, 3타 Basic Attack, HP, Dodge를 서로 연결해야 했고, Unity 내부에서 실제 동작 여부까지 검증해야 했기 때문이다. Codex의 구현 세션이 계속 진행되던 중 OpenClaw의 Tool Call이 10분 제한을 넘기면서 timeout이 발생하였다.

OpenClaw dynamic tool call timed out after 600000ms while running tool sessions_send.

처음에는 단순히 작업이 실패했다고 볼 수도 있다. 하지만 Agent 기반 개발에서는 이것이 조금 복잡하다. OpenClaw의 Tool Call이 timeout되었다고 해서 Codex가 실제로 아무 작업도 하지 않았다는 의미는 아니기 때문이다.

이미

• Script를 작성했을 수도 있고
• Scene에 Component를 연결했을 수도 있고
• Unity Compile까지 완료했을 수도 있으며
• 단순히 최종 응답만 돌아오지 않았을 수도 있다.

따라서 같은 작업을 그대로 다시 실행하면 이미 존재하는 구현을 중복 생성하거나 정상적인 상태를 다시 수정할 가능성이 있었다. 루미 역시 곧바로 같은 작업을 다시 위임하지 않고 현재 Codex 세션과 Unity Project의 상태를 확인하였다.

Rate Limit 이후 중단 지점부터 복구

이후 모델 Rate Limit까지 발생하면서 작업이 한 번 더 중단되었다. 하지만 이미 M0은 완료된 상태였고, M1 역시 일부 또는 대부분 구현되었을 가능성이 있었다.

따라서 단순히 다시

M0부터 개발해줘.

라고 요청하지 않았다. 대신 다음과 같이 요청하였다.

ゆならん: 방금 작업이 rate limit 이후 중단된 것 같아. 현재 Project VX 상태를 확인하고, 이미 완료된 작업은 다시 실행하지 말고 중단된 지점부터 이어서 진행해줘.

루미는 기존 작업 결과와 현재 Unity Project를 다시 확인하였다. 그리고 완료된 M0을 처음부터 다시 실행하지 않았다. M1 역시 이미 존재하는 구현을 새로 재생성하지 않고 현재 상태를 검사한 뒤 필요한 검증을 이어서 수행하였다.

이번 과정에서 처음으로

Agent 작업이 중단되었을 때 전체 작업을 재실행하지 않고 현재 프로젝트 상태를 기준으로 복구하는 과정

을 실제로 테스트하게 되었다.

M1 Player 검증 완료

상태를 복구한 뒤 M1 Player에 대한 검증을 진행하였다. 최종적으로 확인된 내용은 다음과 같았다.

Player Movement

WASD 입력을 통해 실제 Player 이동이 정상적으로 이루어지는 것을 확인하였다.

Camera

Mouse Delta 입력을 사용한 시점 조작이 정상적으로 동작하는 것을 확인하였다.

Basic Attack

기본 공격은 기획에 따라

Attack 1 → Attack 2 → Attack 3

형태의 3타 Combo로 구현되었다. 여러 번 반복 입력하여 Combo가 정상적으로 동작하는 것도 확인하였다.

HP

Player HP 상태를 구현하고, HP가 0이 되었을 때 사망 처리 및 이후 Game Over 시스템과 연결하기 위한 Hook이 정상적으로 동작하는 것을 확인하였다.

Dodge

기획에 정의한 초기 기준값을 바탕으로 회피 기능도 구현하였다.

• 전체 회피 시간 약 0.35초
• 일정 구간 무적
• 회피 중 즉시 재입력 차단
• 약 1초 Cooldown

Unity 측에서도 다음 사항을 검증하였다.

• Compile 상태 up_to_date
• Compile Error 0
• Scene isDirty=false
• Editor/Pipeline 정상
• Play Mode에서 Movement·Camera·Attack·HP·Dodge의 동작 검증 완료

또한 기존 M1 구현이 이미 존재하는 경우 해당 파일을 새로 생성하지 않고 기존 구현을 유지하였다. Git 변경 작업 역시 수행하지 않았다.

결과적으로 M0과 M1의 구현 및 검증을 완료할 수 있었다.

그리고 다음 개발 대상은 M2 Combat으로 이동하였다. 다만 M2는 아직 실제 구현 테스트를 진행하지 않았기 때문에 이번 글에서는 다루지 않는다.

Development Plan에도 실제 진행 상태 반영

M0과 M1이 끝난 이후에는 Obsidian의 Development Plan.md 역시 현재 개발 상태에 맞게 갱신되었다.

Development Plan에서는 M0의 주요 Task와 M1의 주요 Task가 완료 상태로 기록되어 있었다.

즉 이번 개발 흐름은 단순히 Codex가 Unity 프로젝트에 코드를 작성하고 끝나는 구조가 아니었다.

기획 확인
↓
개발 계획 수립
↓
현재 Milestone 선택
↓
Codex 구현
↓
Unity 검증
↓
Development Plan 갱신
↓
다음 Milestone

까지 하나의 Cycle로 연결되었다. 이것이 5편에서 Development Plan을 따로 만들었던 가장 큰 이유이기도 하다.

Test #1과의 차이

이전 Test에서는 내가 루미에게 비교적 구체적인 개발 내용을 직접 전달하였다. 예를 들면

이동 기능을 구현해줘.
달리기를 추가해줘.
Unity에서 검증해줘.

와 같은 방식이었다. 따라서 당시의 구조는 사실상 다음에 가까웠다.

ゆならん
↓
구체적인 구현 요청
↓
루미
↓
Codex
↓
Unity

반면 이번 Test #2에서는 구조가 달라졌다.

ゆならん
↓
전체 게임 기획 작성
↓
Obsidian
↓
Planning Sync
↓
Development Plan
↓
루미
↓
Codex
↓
Unity

나는 LAST SIGNAL이 어떤 게임인지와 어떤 시스템이 필요한지를 기획하였다. 하지만 실제 개발에서

지금 무엇부터 만들어야 하는가?
현재 단계에서 어떤 작업이 필요한가?
어떤 작업을 Codex에게 맡겨야 하는가?

를 매번 하나씩 지정하지 않았다. 이 판단을 루미와 Development Plan 쪽으로 옮기는 것이 이번 Test의 핵심이었다.

예상하지 못했던 문제 — 실행 상태 복구

이번 Test에서 새롭게 발견한 문제도 있었다. 게임 개발은 하나의 짧은 요청으로 완료되는 작업이 아니다. 하나의 Milestone에서도

• 기존 코드 조사
• 새로운 구현
• Scene 수정
• Compile
• Play Mode
• 기능 검증
• 회귀 확인
• 결과 정리

등 여러 단계가 필요하다. 따라서 작업이 길어질수록

• Rate Limit
• Tool Timeout
• Codex app-server 응답 지연
• Unity Pipeline 문제

등으로 중간에 연결이 끊길 가능성도 높아진다. 이번 M1에서는 실제로 Timeout과 Rate Limit이 발생하였다. 그런데 이런 상황에서 전체 작업을 처음부터 다시 실행하는 것은 적절하지 않았다. 따라서 앞으로는 Agent의 작업 상태를 단순히

성공 / 실패

두 가지로만 볼 것이 아니라,

구현 및 검증 완료
구현 완료 / 검증 미완료
일부 구현
미구현

등 실제 프로젝트의 상태를 기준으로 판단할 필요가 있다고 생각하였다. 또한 작업이 중단되었을 경우에는 가능한 한 기존 Codex Session과 실제 Unity Project를 먼저 확인하고,

이미 끝난 부분은 건드리지 않고 실제 중단된 지점부터 이어서 개발

하도록 하는 구조가 필요했다. 이번 Test를 통해 이 문제를 실제 상황에서 처음 확인할 수 있었다.

이번 Test #2-1에서 확인한 것

이번 글에서는 LAST SIGNAL 전체를 완성하지 않았다. 이번 단계에서 실제로 확인한 것은 다음 두 단계이다.

M0 — Project Bootstrap
M1 — Player

하지만 이 두 단계만으로도 5편에서 만들었던 Planning Workflow가 실제 Implementation으로 연결되는지는 확인할 수 있었다. 이번에 실제로 동작한 전체 흐름은 다음과 같다.

Project VX Planning
↓
Planning Source 변경 감지
↓
Planning Sync
↓
Development Plan 생성 / 갱신
↓
현재 Milestone 판단
↓
루미
↓
Codex 작업 위임
↓
Unity 구현
↓
기능 검증
↓
Development Plan 진행 상태 갱신
↓
다음 Milestone

즉 5편에서

기획 문서를 읽고 개발 계획을 세울 수 있는가?

를 확인했다면,

이번에는

그 개발 계획을 실제 게임 구현으로 이어갈 수 있는가?

를 처음으로 확인한 것이다.

결론

M1 버전 테스트 영상

이번 Test #2-1에서는 비교적 복잡한 LAST SIGNAL 기획안을 Obsidian의 Project VX Planning에 추가한 뒤 실제 개발을 진행해보았다. 루미는 새로운 기획 변경을 감지하고 Planning Sync를 수행하였다. 그 과정에서 기획을 실제 개발 순서와 Task로 정리하고 Development Plan을 구성하였다. 이후 내가

Project VX 개발을 시작해줘.

라고 요청하자 현재 개발 단계에 따라 M0 Project Bootstrap부터 구현을 시작하였다. M0 구현 및 검증을 완료한 뒤에는 M1 Player로 넘어갔고, Movement, Camera, Basic Attack, HP, Dodge까지 실제 Unity Project에 구현하고 검증할 수 있었다.

특히 내가 이번에 확인하고 싶었던 것은 AI가 각각의 기능을 구현할 수 있는지 자체가 아니었다. 궁극적으로 확인하고 싶은 것은 다음과 같은 구조였다.

기획을 읽는다.
↓
현재 무엇을 해야 하는지 판단한다.
↓
구현 작업을 Codex에게 맡긴다.
↓
Unity에서 실제 결과를 확인한다.
↓
개발 상태를 다시 기록한다.

이번 Test에서는 최소한 M0과 M1까지 이 Cycle이 실제로 동작한다는 것을 확인할 수 있었다. 동시에 Timeout과 Rate Limit 때문에 Agent 작업이 중간에 끊기는 상황도 경험하면서, 장시간 개발에서 실행 상태를 어떻게 유지하고 복구할 것인가라는 새로운 문제도 확인하였다.

현재 Development Plan상 다음 단계는 M2 Combat이다. 하지만 M2 이후는 아직 실제 구현 및 검증을 진행하지 않았다.

따라서 Test #2의 다음 단계에서는 Combat부터 여러 시스템 간 Dependency가 본격적으로 발생하기 시작한 이후에도, 현재의 Planning 기반 개발 Workflow가 정상적으로 유지되는지 계속 확인해볼 예정이다.

또한 이번 테스트에서 드러난 Timeout, Rate Limit 이후의 실행 상태 복구 등 몇 가지 문제를 바탕으로, 다음 개발을 진행하기 전에 관련 하네싱도 일부 수정할 예정이다.

한국어 본문은 준비 중입니다. 원문은 일본어로 읽을 수 있습니다.