[VX] 09. 루미의 레벨 디자인 구현(Test #2-3)

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

이전 작업에서는 Codex 사용량 소진에 대비해 Antigravity CLI를 대체 Agent로 연결하는 Failover 구조를 시험하였다.

Unity MCP 연결 자체는 가능했지만, 서로 다른 Agent 사이에서 Context와 실행 상태, 검증 결과를 안전하게 넘기기 위해 필요한 추가 하네싱의 복잡성이 지나치게 커질 수 있다고 판단하여 최종적으로 자동 Failover는 사용하지 않기로 하였다.

따라서 Project VX는 다시 기존의 ゆならん → 루미 → Codex → Unity 구조로 돌아왔다.

그리고 이번에는 다시 LAST SIGNAL 개발을 이어서 진행하였다. 7편까지의 실제 개발 상태는 M0 Project Bootstrap, M1 Player, M2 Combat, M3 Enemy까지 완료된 상태였다. M3 이후에는 바로 다음 Milestone으로 넘어가지 않고 구조 리뷰와 최소 보완 작업을 수행하였다.

이 과정에서 다음 내용을 추가로 보완하였다.

• Enemy의 환경 Collider 충돌
• Guard 공격 시 사거리 및 간단한 시야 재확인
• Drone Projectile의 환경 충돌
• 기본 공격과 Pulse의 다중 Collider 중복 Damage 방지

이후 M2와 M3에 대한 Regression Test도 다시 수행하였다. 즉 M0부터 M3까지 구현과 검증을 완료한 뒤 구조 리뷰, 최소 보완, Regression Test까지 마친 상태였고, 다음 단계는 M4 Level / Interaction이었다. 이번 Test #2-3에서는 여기서부터 M4 Level / Interaction을 실제로 구현한다.

M4 Level / Interaction 개발 시작

M4의 목적은 지금까지 각각 구현했던 Player, Combat, Enemy를 실제 Level 구조와 Interaction에 연결하는 것이다.

기획 단계에서 M4에는 다음 항목이 정의되어 있었다.

• Level Blockout
• Interaction System
• Generator A
• Generator B
• Puzzle

완료 조건은 플레이어가 두 Generator를 모두 활성화할 수 있는 상태를 만드는 것이었다.

이전 M0~M3이 개별적인 Player와 Combat System을 만드는 단계였다면, M4부터는 지금까지 만들어둔 시스템들이 실제 Game Flow의 일부로 사용되기 시작한다. 나는 루미에게 세부 구현을 다시 설명하지 않고 기존 Development Plan을 기준으로 작업을 이어가도록 요청하였다. 다만 당시 Codex의 사용 가능량이 얼마 남지 않은 상태였기 때문에, 한도 때문에 작업이 중단될 경우 이를 알려달라는 조건만 추가하였다.

ゆならん: 이어서 작업을 진행해줘. 코덱스 한도가 얼마 안 남아서 도중에 멈출 수 있어. 한도로 인해 멈춘 경우 나한테 말해줘.

이전 글들에서 추가한 실행 상태 복구 규칙이 있었기 때문에, 실제로 Codex 한도가 소진되어 작업이 중단되더라도 이미 완료한 구현을 처음부터 다시 실행하지 않고 현재 상태를 기준으로 이어갈 수 있도록 한 상태였다.

M4 구현 완료

이번에는 다행히 Codex 한도가 소진되기 전에 M4 전체 구현과 검증이 완료되었다.

루미가 보고한 주요 구현 결과는 다음과 같았다.

• M4 시설 Blockout
• 공통 E Interaction 구현
• Generator A 구현
• Generator B 구현
• Puzzle 구현
• 두 Generator 완료 이후 Transmission Room 잠금 해제
• Development Plan.md 갱신

Level Blockout

먼저 LAST SIGNAL의 실제 진행 구조를 사용할 수 있도록 M4 시설 Blockout이 추가되었다.

앞서 M0에서 만들어둔 Bootstrap Scene을 기반으로 M4에서 필요한 Generator 구역과 Transmission Room을 실제 진행 조건과 연결할 수 있는 구조로 확장하였다. M4의 목적은 완성된 Level Art를 제작하는 것이 아니라 이후 Game State와 전체 Game Flow를 연결할 수 있는 기능적 Level 구조를 만드는 것이므로, 이번 단계에서는 Blockout 형태를 유지하였다.

공통 Interaction

Player가 Level의 Object와 상호작용할 수 있도록 공통 E Interaction이 구현되었다. 이 Interaction을 기반으로 Generator A와 Generator B를 활성화할 수 있도록 연결하였다.

이전까지 Player의 입력은 Movement, Attack, Dodge, Skill 등 전투 중심이었다. M4에서는 여기에 Level Object와 상호작용하는 입력이 실제 Gameplay에 처음 사용되기 시작한 것이다.

Generator A

Generator A는 전투 조건과 연결하였다. 해당 구역의 Guard와 Drone을 모두 처치한 뒤 Generator와 상호작용하면 활성화할 수 있도록 구현하였다.

즉 기존 M2 Combat과 M3 Enemy의 결과가 M4 Level 조건으로 직접 사용되기 시작하였다. 흐름은 Player Combat → Guard / Drone 처치 → Generator A 활성화 형태다.

Generator B

Generator B는 Puzzle을 해결한 뒤 활성화할 수 있도록 구현하였다. Puzzle의 정답 순서는 A → C → B로 구성하였다. 잘못된 순서로 입력했을 경우 Puzzle 상태를 초기화하며, 이미 완료된 Puzzle이나 Generator가 중복으로 다시 활성화되는 것도 방지하였다.

즉 Generator A가 Combat System과 연결되는 구역이라면, Generator B는 Interaction과 Puzzle을 중심으로 동작하도록 구성되었다.

Transmission Room

두 Generator가 모두 활성화되면 Transmission Room의 잠금이 해제되도록 연결하였다. Generator A와 Generator B의 완료 상태가 모두 충족되면 Transmission Room이 Unlock되는 구조다.

이로써 LAST SIGNAL의 핵심 진행 구조 가운데 전투 또는 Puzzle을 해결하고 Generator를 복구한 뒤 다음 구역을 개방하는 흐름까지 실제 Unity Project에서 연결되기 시작하였다.

M4 검증

M4 구현 이후 Unity에서 다음 항목들을 검증하였다.

• Unity Recompile 성공
• M4 Hierarchy 및 Component Reference 확인
• Generator A 활성화 조건 확인
• Generator B Puzzle 조건 확인
• 잘못된 Puzzle 입력 시 초기화 확인
• 중복 활성화 방지 확인
• 두 Generator 활성화 이후 Transmission Room Unlock 확인
• Console Error 0
• Console Warning 0
• Scene dirty=false
• Editor / Pipeline ready

다만 이번 검증에도 자동화 환경의 제한은 하나 남았다. 현재 Pipeline을 통해 실제 Keyboard의 E 입력 이벤트 자체를 직접 주입하는 것은 검증하지 못했다. 대신 Input Action 연결 상태, Interaction 호출 경로, TriggerInteract() 동작을 사용하여 동일한 Interaction Logic이 정상적으로 실행되는지를 검증하였다.

따라서 M4의 기능적 조건은 통과하였지만, 실제 사용자가 키보드에서 E 키를 눌렀을 때의 입력 자체는 이후 수동 Play Test에서도 함께 확인할 필요가 있다. 그래도 다행히 이번 작업이 Codex 한도 때문에 중단되지는 않았다는 것이다.

M4 구현과 검증이 모두 완료되었고, Development Plan.md 역시 M4 완료 및 M5 준비 상태로 갱신되었다.

M4에서 확인한 시스템 연결

M4에서 개인적으로 중요했던 부분은 새 기능의 개수보다 기존 Milestone의 결과가 실제 Game Flow의 조건으로 사용되기 시작했다는 점이었다.

M0~M3에서는 각 시스템이 비교적 독립적으로 구현되었다. M1은 Player, M2는 Combat, M3는 Enemy를 중심으로 진행되었다. 하지만 M4에서는 Player Interaction, Combat, Enemy State, Puzzle이 Generator State와 연결되고, 그 결과가 다시 Transmission Room Unlock이라는 다음 진행 조건으로 이어졌다.

즉 Test #2의 목적이었던 여러 시스템 간 Dependency가 발생한 상태에서도 Planning 기반 개발을 계속할 수 있는지를 본격적으로 확인하기 시작한 단계라고 볼 수 있다.

M4까지 완료됨으로써 LAST SIGNAL은 단순한 기능 Test Scene에서 조금씩 실제 게임 진행 구조를 가진 형태로 바뀌기 시작하였다.

지금까지의 변경을 Git에 반영

M4까지 완료한 뒤에는 잠시 다음 Milestone으로 넘어가지 않고, 지금까지 누적된 변경을 Git에 정리하기로 하였다. M0부터 M4까지 상당한 양의 Unity 구현과 Planning 관련 변경이 누적되어 있었기 때문이다.

이전까지 Codex는 Git 상태를 읽고 구현 작업에 활용할 수는 있었지만, Commit·Merge·Push와 같은 Git 상태 변경은 수행하지 않도록 제한되어 있었다. 따라서 이번에는 루미에게 지금까지의 변경 사항을 충분히 검토한 뒤 기존에 정해둔 Git Workflow에 따라 정리하도록 요청하였다.

ゆならん: 일단 지금까지 진행한 작업 변경분에 대해 Git 작업을 진행해줘.
기존에 정해둔 Git 작업 규칙을 준수하고, 현재 변경 사항을 충분히 검토한 뒤 적절한 단위로 Git 작업을 완료해줘. 원격 저장소 반영이 필요한 경우 그것까지 진행해줘.
작업 중 문제가 발생하거나 판단이 필요한 상황이 생기면 임의로 위험한 작업을 하지 말고 나한테 알려줘.

루미는 Working Tree의 변경을 하나의 거대한 Commit으로 처리하지 않고 기능, 의존성, 문서 단위로 분리하였다.

그 결과 다음과 같은 종류의 변경이 각각 Commit되었다.

• LAST SIGNAL Core System 구현
• Unity Pipeline Dependency
• LAST SIGNAL Planning
• M4 Development Progress
• Unity Project Rule
• LAST SIGNAL Folder Metadata

이후 작업 Branch를 main에 --no-ff 방식으로 Merge하고 origin/main까지 Push하였다. 최종적으로 Local main과 Remote origin/main의 Hash가 64e5b68로 일치하는 것도 확인하였다. 사용했던 작업 Branch인 feat/harness-survival-mini-game 역시 Merge가 끝난 뒤 안전하게 삭제하였다.

Git 작업 이후에도 Unity 상태는 다시 확인하였다.

• Compile 성공
• Console Error 0
• Editor / Pipeline ready

상태를 유지하였다.

모든 Local Change를 무조건 Commit하지 않기

이번 Git 작업에서 한 가지 눈에 띄는 부분이 있었다. Git 작업이 끝났다고 해서 Working Tree의 모든 변경을 무조건 Commit한 것은 아니었다.

루미는 현재 Project VX 개발과 목적이 명확하게 연결되는 변경만 Commit하고, 성격이 불분명하거나 Local 환경에서 만들어진 변경은 그대로 보존하였다.

예를 들면 다음과 같은 항목이다.

• .DS_Store
• Obsidian의 .obsidian 관련 변경
• Unity 기본 Tutorial 관련 삭제분
• 일부 ProjectSettings 변경
• 기존 Idea / Plot 문서

이런 변경들은 현재 LAST SIGNAL 개발 과정에서 의도적으로 수정한 것인지 확실하지 않았기 때문에 임의로 Commit하거나 삭제하지 않았다.

따라서 Git Client에는 여전히 일부 Local Changes가 남아 있었다. 이것은 Git 작업이 실패해서 남아 있는 변경이 아니라, 목적이 불명확한 변경을 억지로 처리하지 않고 보존한 결과이다.

Git History에서는 구현과 문서 변경이 역할별 Commit으로 나뉘어 있는 것을 확인할 수 있었다. 또한 실제 구현을 수행한 Codex가 직접 Commit한 것이 아니라, 기존에 정한 규칙대로 루미가 변경 사항을 검토하고 Git 작업을 수행하였다.

M0~M4 중간 Checkpoint

이번 Git 작업은 단순히 코드를 Remote에 Push하기 위한 작업만은 아니었다. Project VX Test #2를 시작한 뒤 처음으로 M0부터 M4까지의 결과를 하나의 안정적인 중간 지점으로 정리한 것에 가깝다. 현재까지 M0 Project Bootstrap, M1 Player, M2 Combat, M3 Enemy, M4 Level / Interaction을 순서대로 완료하였다. 그리고 M3 이후에는 구조 리뷰, 최소 보완, Regression Test도 추가로 수행하였다.

즉 지금까지의 결과는 단순히 여러 기능이 존재하는 상태가 아니라, 각 Milestone의 구현과 검증 결과가 Development Plan에 기록되고 Git History에도 하나의 개발 이력으로 남은 상태가 되었다.

현재 다음 Milestone은 M5 Game State이다.

M5에서는 다음 내용이 추가될 예정이다.

• Game State 관리
• Objective
• Checkpoint
• Respawn
• Generator 상태 유지

특히 M4에서 만들어진 두 Generator의 활성화 상태를 Player 사망과 Respawn 이후에도 유지해야 하므로, 지금까지 구현한 Level 진행 상태를 실제 Game State로 관리하기 시작하는 단계가 된다.

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

이번 단계에서는 크게 두 가지를 확인할 수 있었다.

1. 기존 시스템을 실제 Level 진행 구조에 연결할 수 있는가

M4에서는 Player, Combat, Enemy, Interaction, Puzzle이 처음으로 하나의 Level Progression에 연결되었다. Generator A는 M2와 M3의 Combat / Enemy System에 의존하고, Generator B는 새로 구현한 Puzzle과 Interaction에 의존한다. 그리고 두 Generator의 상태가 Transmission Room Unlock이라는 다음 진행 조건에 사용된다.

따라서 단순히 여러 시스템을 각각 구현하는 단계에서 벗어나, 시스템 간 Dependency를 기반으로 실제 Game Flow를 만드는 단계에 들어갔다.

2. 누적된 Agent 작업을 안전하게 Git History로 정리할 수 있는가

M0~M4 개발 과정에서는 많은 파일과 문서 변경이 누적되었다. 하지만 이를 하나의 Commit으로 밀어 넣거나 Working Tree 전체를 무조건 처리하지 않고 기능, 의존성, 문서, Asset Metadata 단위로 나누어 Commit하였다. 또한 목적이 불명확한 Local Changes는 그대로 보존하였다.

즉 Project VX에서 Codex 구현 → Unity 검증 → Development Plan 갱신 → 루미 변경 검토 → Git Commit / Merge / Push로 이어지는 Git Workflow 역시 실제 장기간 개발 과정에서 사용할 수 있음을 확인하였다.

결론

M4 버전 테스트 영상

이번 Test #2-3에서는 LAST SIGNAL의 M4 Level / Interaction을 구현하였다.

M4를 통해 기능적인 Level Blockout, 공통 Interaction, Generator A, Generator B, Puzzle, Transmission Room Unlock을 실제 Unity Project에 연결하였다. 특히 지금까지 별도로 구현했던 Combat과 Enemy System이 Generator A의 진행 조건으로 사용되었고, 새로 구현한 Puzzle은 Generator B의 진행 조건으로 사용되었다.

즉 M4부터는 여러 개별 시스템이 실제 게임 진행 구조 안에서 서로 연결되기 시작하였다.

구현 이후에는 루미가 Unity Recompile, Runtime 조건, Component Reference, Scene 상태, Console 상태 등을 검증하였으며 M4를 완료 상태로 기록하였다. 또한 M0부터 M4까지 누적된 변경 사항을 기존 Git Workflow에 따라 정리하였다.

관련 변경을 기능·의존성·문서 단위로 Commit하고 main에 --no-ff Merge한 뒤 origin/main에 Push하였으며, Local과 Remote의 Hash가 동일한 것도 확인하였다. 반면 목적이 불명확하거나 Local 환경에 가까운 변경은 억지로 Commit하지 않고 그대로 보존하였다.

이번 단계까지 진행하면서 Project VX의 흐름은 Planning, Milestone 판단, Codex 구현, Unity 검증, Development Plan 갱신, Git History 정리까지 이어지는 형태가 되었다.

현재 다음 단계는 M5・M6 Game State이다. M5부터는 M4에서 만들어진 Level 진행 상태와 Generator 상태를 저장하고, Checkpoint와 Respawn 이후에도 이를 유지하는 시스템이 필요하다.

다음 Test에서는 이 상태에서 Game State를 추가하면서 현재까지 만들어진 Level Progression을 Player의 사망과 Respawn 이후에도 지속적으로 유지할 수 있는지 확인해볼 예정이다.