[VX] 07. 복잡한 기획안을 불러와 스스로 게임 구현(Test #2-2)

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

이전 작업에서는 Test #2를 위한 LAST SIGNAL의 기획을 기반으로 M0 Project Bootstrap과 M1 Player까지 구현하였다. 이 과정에서 Planning Document에서 시작해

Development Plan
↓
현재 Milestone 판단
↓
루미
↓
Codex
↓
Unity 구현 및 검증
↓
Development Plan 갱신

으로 이어지는 개발 Cycle이 실제로 동작하는 것을 확인할 수 있었다. 하지만 동시에 새로운 문제도 발견하였다.

M1 작업 도중 Codex 호출이 길어지면서 Tool Timeout과 Rate Limit이 발생했고, 단순히 같은 작업을 다시 실행하면 이미 구현된 기능을 중복 생성하거나 정상적인 Project 상태를 훼손할 가능성이 있었다. 따라서 이후 개발에서는 작업이 중단되었을 때

현재 Project 상태 확인
↓
기존 Codex Session 확인
↓
이미 구현된 작업과 미완료 작업 구분
↓
필요한 부분만 이어서 실행

할 수 있도록 관련 하네싱을 보완하였다.

이번 Test #2-2에서는 해당 보완 이후 실제로 다음 Milestone을 계속 진행하면서, 단순한 Player 구현을 넘어 Combat과 Enemy처럼 여러 시스템이 서로 연결되기 시작했을 때도 현재 구조가 정상적으로 동작하는지 확인하였다.

M2 시작 전 — 실행 상태 복구 하네싱 보완

M2 개발을 시작하기 전, 먼저 이전 M1 작업에서 발견했던 문제를 바탕으로 Project VX의 하네싱을 일부 수정하였다.

6편에서 M1을 개발하던 중 Tool Timeout과 Rate Limit이 발생했을 때 가장 큰 문제는 Agent의 응답이 끊겼다는 것과 실제 구현 작업이 실패했다는 것을 구분하기 어렵다는 점이었다.

Codex가 이미 Script나 Scene을 수정했거나 Unity 검증까지 일부 진행한 상태에서도 OpenClaw 측의 최종 응답만 돌아오지 않을 수 있었다. 이 상황에서 단순히 동일한 작업을 처음부터 다시 요청하면,

• 이미 생성된 Script나 Component를 중복 생성
• 기존 Scene을 다시 수정
• 이미 성공한 구현을 불필요하게 덮어쓰기
• Unity의 실제 상태와 Development Plan의 기록이 어긋남

등의 문제가 발생할 가능성이 있었다.

따라서 AGENTS.md에 Execution State Persistence and Recovery 규칙을 추가하였다.

먼저 Milestone의 완료 기준부터 조금 더 명확하게 정하였다. 이제 Project VX에서는 단순히 구현 파일이 존재한다고 해서 Milestone을 완료한 것으로 처리하지 않는다.

Milestone이 완료되기 위해서는

필요한 구현이 존재함
↓
필요한 검증이 완료되었거나 남은 검증 제한이 명시됨
↓
실제 검증 결과가 Development Plan에 반영됨

까지 완료되어야 한다.

즉 Development Plan을 단순한 작업 예정표가 아니라 현재 검증된 개발 상태를 유지하기 위한 지속적인 상태 기록으로 사용하도록 하였다.

그리고 Rate Limit, Timeout, Pipeline 연결 실패 등의 일시적인 문제가 발생했을 경우에는 다음 순서로 처리하도록 변경하였다.

전체 구현을 즉시 다시 실행하지 않음
↓
실제 Project 파일 상태 확인
↓
Unity Editor / Pipeline 상태 확인
↓
기존 Codex Session 확인
↓
이미 구현됨 / 이미 검증됨 / 구현됐지만 미검증 / 실제 미완료 항목 구분
↓
정상적으로 완료된 작업 보존
↓
가장 처음 남아 있는 미완료 또는 미검증 단계부터 재개

가능하다면 새로운 Codex Session을 만드는 대신 기존 구현 Session을 그대로 이어서 사용하도록 하였다. 또한

Timeout이나 Rate Limit, 최종 응답의 누락만으로 구현 실패라고 판단하지 않는다.

는 규칙도 추가하였다. Agent의 응답보다 실제 Project 파일, Unity 상태, 직접 수행한 검증 결과를 우선하여 판단하도록 한 것이다. 같은 일시적인 오류에 대한 재시도 역시 무한히 반복하지 않도록 제한하였다. 동일한 경로를 계속 반복하는 대신, 제한된 횟수 안에서 해결되지 않으면 성공한 작업은 그대로 보존한 채 다른 안전한 검증 방법을 사용하거나 검증 제한을 기록하도록 하였다. 완료 여부를 안전하게 판단할 수 없는 경우에는 해당 Task를 PARTIAL 또는 BLOCKED 상태로 남기도록 하였다. 그리고 복구가 완료된 뒤에는 반드시 실제 확인된 상태를 기준으로 Development Plan.md를 갱신한 후 다음 Milestone으로 넘어가도록 하였다.

이 하네싱 수정의 목적은 단순히 오류가 발생했을 때 다시 시도하는 것이 아니었다. 핵심은

일시적인 인프라 문제로 인해 이미 완료된 구현을 중복 실행하거나, 성공한 작업을 잃거나, Unity Project와 Development Plan의 상태가 서로 달라지는 것을 방지하는 것

이었다.

즉 작업을 처음부터 다시 시작하는 방식이 아니라, 현재까지 성공한 상태를 보존하면서 이어서 실행할 수 있는 구조를 만들고자 하였다. 이렇게 실행 상태 복구 관련 규칙을 추가한 뒤, 다음 Milestone인 M2 Combat 개발을 시작하였다.

M2 Combat 시작

M1의 구현과 검증이 끝난 시점에서 Development Plan은 M0과 M1을 완료 상태로 기록하고 있었으며, 다음 Current Milestone은 M2 Combat으로 설정되어 있었다. 나는 다시 세부 구현 내용을 직접 전달하지 않고,

ゆならん: 그 다음 단계 진행해줘.

라고만 요청하였다.

루미는 Development Plan의 현재 상태를 기준으로 다음 단계가 M2 Combat이라는 것을 확인하고 구현을 시작하였다.

M2에서는 Player와 Enemy 사이의 실제 전투가 가능하도록 다음 요소들이 필요했다.

• 공통 Damage 처리
• Hit Detection
• Skill 1
• Skill 2
• Cooldown
• Enemy Damage Reaction

이전 M1이 Player 자체의 조작과 상태를 만드는 단계였다면, M2부터는 Player의 공격이 다른 Object의 상태를 실제로 변경하는 시스템 간 연결이 시작된다.

모델 Rate Limit 문제

그런데 M2 작업을 시작한 직후, 모델 Rate Limit까지 발생하였다.

Rate-limited — ready in ~30s.

따라서 다음과 같이 요청하였다.

ゆならん: M2 작업이 중단된 것 같아. 현재 Project VX의 실제 상태와 기존 Codex 세션을 확인하고, 이미 완료된 조사·구현·검증은 반복하지 말고 중단된 지점부터 이어서 진행해줘.

6편에서 발견했던 실행 상태 복구 문제가 바로 다음 Milestone에서도 다시 발생한 셈이다. 작업이 반복적으로 Rate Limit에 걸리면서 API의 Usage Tier 상태도 함께 확인하였다.

당시 계정은 Tier 1 상태였다. OpenAI API에서는 조직의 사용량과 결제 이력 등에 따라 Usage Tier가 적용되며, Tier가 올라가면 일반적으로 대부분의 Model에서 더 높은 Rate Limit이 적용된다.

(2026년 8월 21일 나의 Limits 화면 기준)

Tier	Model	Token limits	Request and other limits	Batch queue limits
Tier 1	gpt-5.6-luna	200,000 TPM	500 RPM	2,000,000 TPD
Tier 1	gpt-5.6-sol	500,000 TPM	500 RPM	900,000 TPD
Tier 2	gpt-5.6-luna	2,000,000 TPM	5,000 RPM	20,000,000 TPD
Tier 2	gpt-5.6-sol	1,000,000 TPM	5,000 RPM	1,350,000 TPD

다만 Usage Tier가 낮았다는 사실만으로 이번 Rate Limit의 정확한 원인을 단정할 수는 없다. Rate Limit은 짧은 시간에 요청이 집중되거나 하나의 요청이 큰 Token Budget을 요구하는 경우에도 발생할 수 있기 때문이다.

일단은 원인으로 추정되는 Tier 문제를 해결하기 위해, 추가 결제를 진행해 Tier 2로 업그레이드를 진행하였다.

Tier 2로 업그레이드한 이후에는 이 글을 작성하는 시점까지 같은 Rate Limit이 다시 발생하지 않았다.

기존 M2 작업을 재실행하지 않고 확인

잠시 뒤 루미는 현재 실행 중인 M2 관련 Codex 작업의 상태를 확인하였다. 확인 결과 project_vx_m2_combat 작업은 이미 실행 중이었다. 따라서 루미는 별도의 재실행이나 추가 구현 명령을 보내지 않고 기존 세션의 결과를 기다렸다.

이 부분은 이전 Test와 비교했을 때 꽤 중요한 변화였다. Agent의 응답이 늦거나 중간 Tool Call이 실패했다는 이유만으로 같은 Task를 다시 생성하지 않고,

실제로 작업이 살아 있는지 먼저 확인한 뒤 기다린다.

는 방식으로 동작했기 때문이다. 즉 6편 이후 추가했던 실행 상태 복구 하네싱 가운데, 기존 작업의 상태 확인과 중복 실행 방지 절차가 실제 상황에서 처음으로 의미 있게 사용되었다.

M2 Combat 구현 및 검증 완료

기존 Codex 세션의 작업이 종료된 뒤 M2 Combat의 구현 및 검증 결과를 확인할 수 있었다. 구현된 주요 내용은 다음과 같았다.

• 공통 Damage / Hit 구조
• 기본 공격 Hit Detection
• 3타 Finisher Knockback
• Skill 1 Pulse
• Skill 2 Dash Strike
• Skill Cooldown
• HP 감소
• 피격 반응
• Stagger
• 사망 처리
• 테스트용 Enemy 3개

Pulse

Q 키를 사용하는 Pulse는 Player 주변의 여러 Enemy를 동시에 공격하며 밀어내는 Skill로 구현되었다. Cooldown은 기획에 따라 약 5초로 설정하였다.

Dash Strike

R 키를 사용하는 Dash Strike는 Player가 전방으로 돌진하면서 Enemy를 공격하고 밀어내는 방식으로 구현되었다. Cooldown은 약 8초로 설정하였다.

Combat 검증

Unity에서는 단순히 Compile 여부만 확인하지 않고 실제 Play Mode에서 다음 내용까지 검증하였다.

• Player → Enemy Damage
• 기본 공격 Hit Detection
• Combo 마지막 공격의 Knockback
• Pulse
• Dash Strike
• Skill Cooldown
• Enemy HP 감소
• Enemy 사망
• 사망 후 Collider 비활성화

재컴파일 역시 정상적으로 완료되었으며 새로운 Compile Error는 발생하지 않았다.

M2가 완료된 이후 Development Plan.md 역시 현재 상태에 맞게 갱신되었다. 다음 Current Milestone은 M3 Enemy로 변경되었다.

M3 Enemy 진행

M2가 정상적으로 완료된 것을 확인한 뒤 다시 다음 단계 진행을 요청하였다.

ゆならん: 그 다음 단계 진행해줘.

내가 Guard와 Drone의 구현 방법이나 Script 구조를 새로 지정한 것은 아니었다. 루미는 현재 Development Plan을 기준으로 다음 Milestone인 M3 Enemy의 구현을 Codex에게 위임하였다.

M3에서는 기존 M2에서 만든 Damage / Hit 구조 위에 실제 Enemy 행동을 연결하는 것이 핵심이었다. 그 결과 두 종류의 Enemy가 구현되었다.

Guard

근거리 Enemy인 Guard에는 다음 State 흐름이 적용되었다.

Idle → Detect → Chase → Attack → Recover → Dead

Player를 감지하면 추적하고, 공격 가능한 거리까지 접근하면 공격한 뒤 Recover 상태를 거치는 구조다.

Drone

Drone은 원거리 Enemy로 구현하였다. Player와 일정 거리를 유지하면서 추적하고, Projectile을 발사하여 공격한다. 또한 M2에서 구현한 공통 Damage 구조와 연결하여 Player와 Enemy 사이의 양방향 공격이 가능하도록 하였다.

M3 구현 및 검증 완료

M3 구현 이후에는 다음 내용을 실제 Unity에서 검증하였다.

• Enemy 공통 HP
• 피격
• Knockback
• 사망
• Guard State 전환
• Guard의 Player 공격
• Player가 Guard에게 주는 Damage
• Drone 거리 유지
• Drone Projectile
• Projectile Damage
• 기존 M2 Combat Dummy

즉 M3를 구현한 뒤에도 이전 M2 기능이 정상적으로 유지되는지를 함께 확인하였다. 재컴파일 결과 역시 정상적이었으며 새로운 Console Error나 Warning은 발생하지 않았다. 기존 M0~M2 구현과 SampleScene도 그대로 보존되었다.

Development Plan.md 역시 M3를 완료 상태로 기록하고 다음 단계인 M4 Level / Interaction 착수 준비 상태로 변경되었다.

바로 M4로 넘어가기 전에 Codex App을 통한 구조 리뷰

여기서 바로 M4 개발을 시작하지는 않았다. M0부터 M3까지 Player, Combat, Damage / Hit, Skill, Guard, Drone 등 여러 시스템이 빠르게 추가되었기 때문이다. 기능 자체는 정상적으로 동작하고 있었지만, 이후 M4~M8까지 계속 시스템을 추가할 경우 지금까지 만들어진 구조의 문제가 뒤늦게 크게 드러날 가능성도 있었다.

그래서 현재 Assets/LAST_SIGNAL 구현을 Codex App에서 별도로 읽기 전용으로 리뷰하였다.

리뷰에서는 다음 항목을 중점적으로 확인하도록 하였다.

• Class / Component 책임 분리
• Player ↔ Combat ↔ Enemy 의존성
• Damage / Hit 구조의 확장성
• Guard / Drone의 공통 구조 재사용 정도
• Scene / Prefab 참조 구조
• M4~M8 확장 시 문제가 될 가능성이 있는 부분
• 과도한 추상화
• 임시 구현
• 중복 코드
• 책임 과다

단, 이번 리뷰에서는 파일 수정이나 Git 작업, Unity 변경을 하지 않도록 제한하였다.

목적은 현재 구조를 대규모로 다시 설계하는 것이 아니었다. Test Game의 규모를 고려하면 지금 시점에서 과도한 리팩터링을 하는 것 역시 Project VX의 목적과 맞지 않기 때문이다. 따라서 실제 플레이나 이후 Milestone에서 문제가 될 가능성이 높은 부분만 골라 최소한으로 보완하기로 하였다.

M4 진입 전 최소 보완

구조 리뷰 결과를 바탕으로 M4를 시작하기 전에 네 가지 항목만 보완하도록 요청하였다.

ゆならん: 방금 Codex 앱에서 진행한 M0~M3 구조 리뷰 결과를 기준으로, M4 착수 전에 필요한 최소 보강 작업을 진행해줘.

이번 작업 범위는 다음 네 가지로 제한하였다.

1. Enemy 이동이 M4의 벽·문·구역 Collider를 무시하지 않도록 최소한의 환경 충돌 처리 추가
2. Guard가 공격 판정 시점에도 Player가 유효 사거리 안에 있는지 다시 확인하고, 필요하다면 간단한 시야 차단 확인
3. Drone Projectile이 벽 등 환경 Collider에 막히도록 충돌 판정 추가
4. 기본 공격과 Pulse가 하나의 Damageable에 여러 Collider가 있을 때 한 번의 공격으로 중복 Damage를 주지 않도록 수정

여기에서도 범위를 의도적으로 제한하였다.

• M0~M3의 정상 동작 최대한 보존
• 대규모 Refactoring 금지
• 범용 AI / NavMesh / Hurtbox / Ability Framework 등을 새로 만들지 않음
• M4 Level / Interaction 자체는 아직 구현하지 않음
• 이후 Milestone에서 다룰 구조까지 미리 확장하지 않음
• 실제 구현 변경은 Codex에게 위임
• 수정 후 M2 / M3 Regression Test 수행
• 결과만 Development Plan에 기록

즉 구조 리뷰에서 문제가 보였다고 해서 곧바로 전체 시스템을 다시 만들지는 않았다. 현재 Test 범위에서 실제로 문제가 될 가능성이 높은 부분만 수정하는 방향을 유지하였다.

최소 보완 및 Regression Test

보완 작업 결과 다음 내용이 추가되었다.

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

그리고 수정 이후 기존 M2와 M3 기능을 다시 검증하였다.

검증 결과:

• Recompile 성공
• 새로운 Compile Error 없음
• Guard 벽 충돌 정상
• Guard 사거리 이탈 시 공격 차단
• Guard 시야 차단 정상
• Drone Projectile 벽 충돌 정상
• 기존 Combat 기능 정상
• Pulse 정상
• Dash Strike 정상
• Guard / Drone 피격 및 사망 정상
• 새로운 Console Error / Warning 없음

이번 작업에서도 M4 Level / Interaction 자체의 구현은 시작하지 않았다. 즉 현재 상태는

M0 완료
↓
M1 완료
↓
M2 완료
↓
M3 완료
↓
구조 리뷰
↓
필요한 최소 보완
↓
Regression Test
↓
M4 착수 준비

까지 진행된 상태다.

Git 상태 확인

M0부터 M3까지 실제 Unity 구현이 계속 누적되면서 Project에는 상당수의 Local Change가 존재하는 상태가 되었다.

Unity 구현으로 인해 Working Tree에는 Local Changes가 누적되었지만, Codex가 직접 Commit·Merge·Push를 수행하지는 않았다. 이전 글에서 정한 Git / GitHub 작업 권한 규칙을 유지하면서 Unity 구현 작업과 Git 이력 관리 작업의 책임을 분리한 것이다.

Test #2-2에서 확인한 것

6편의 Test #2-1에서는

Planning을 실제 Implementation으로 연결할 수 있는가?

를 확인하였다. 이번 Test #2-2에서는 그보다 한 단계 더 나아가 다음 항목들을 확인할 수 있었다.

1. 이전 Milestone의 결과를 기반으로 다음 작업을 계속 진행할 수 있는가

M1 완료 이후 나는 다시 세부 구현 내용을 입력하지 않았다.

그 다음 단계 진행해줘.

라는 요청만으로 M2 Combat과 M3 Enemy가 순차적으로 진행되었다. 즉 Development Plan이 단순한 기록 문서가 아니라 실제 다음 작업을 결정하기 위한 상태로 사용되었다.

2. 시스템 간 Dependency가 발생해도 구현을 이어갈 수 있는가

M2부터는 Player와 Enemy 사이에 Damage / Hit가 연결되었고, M3에서는 Combat System 위에 Guard와 Drone의 행동이 추가되었다.

즉 하나의 독립적인 기능이 아니라 기존 시스템 위에 새로운 기능을 계속 연결하는 단계로 넘어갔다.

3. Agent 작업이 중단되어도 중복 구현 없이 복구할 수 있는가

M2 시작 직후 Rate Limit이 다시 발생하였다. 하지만 기존 Codex Session의 상태를 먼저 확인하여 이미 실행 중이던 작업을 다시 생성하지 않았다. 6편에서 발견했던 문제를 바탕으로 보완한 실행 상태 복구 방식이 실제 개발에서도 동작한 것이다.

4. 새로운 Milestone 전에 기존 구조를 다시 검토할 수 있는가

M3가 끝난 뒤 바로 M4로 넘어가지 않고 현재 구조를 읽기 전용으로 리뷰하였다. 그리고 리뷰 결과 전체를 대규모 리팩터링하는 대신, 이후 Level 구현에서 실제 문제가 될 가능성이 높은 네 가지 항목만 수정하였다.

5. 수정 이후 기존 기능의 Regression을 확인할 수 있는가

M4 준비를 위한 보완 작업 이후 M2 Combat과 M3 Enemy를 다시 테스트하였다. 새로운 기능을 추가하거나 기존 구조를 수정했을 때 이전 Milestone의 기능이 깨지지 않았는지 확인하는 Regression Test가 실제 Workflow 안에 포함되기 시작한 것이다.

결론

이번 Test #2-2에서는 M2 Combat과 M3 Enemy까지 개발을 이어서 진행하였다.

M2에서는 공통 Damage / Hit 구조와 Skill, Cooldown, Enemy Reaction을 구현하여 Player와 테스트 Enemy 사이의 실제 전투가 가능하도록 만들었다. M3에서는 Guard와 Drone을 추가하여 Enemy State와 공격 구조를 연결하였다.

M2를 시작하자마자 모델 Rate Limit이 발생하면서 작업이 중단된 것처럼 보였지만,

현재 Project 상태 확인
↓
기존 Codex Session 확인
↓
실행 중인 작업 확인
↓
중복 실행 방지
↓
기존 작업의 완료 대기

라는 방식으로 대응할 수 있었다.

실제로 project_vx_m2_combat 작업은 중단된 것이 아니라 계속 실행 중이었다. 따라서 동일한 구현을 다시 요청하지 않고 기존 작업이 완료될 때까지 기다렸으며, 이후 M2 구현 및 검증 결과를 정상적으로 확인할 수 있었다. 또한 M3가 완료된 이후에는 다음 Milestone을 무조건 진행하는 대신 현재 구현 구조를 한 번 검토하고, 필요한 부분만 최소한으로 보완한 뒤 기존 M2와 M3에 대한 Regression Test까지 진행하였다.

따라서 현재 Project VX의 개발 흐름은 단순히

다음 기능을 만든다.

에서 끝나는 것이 아니라,

현재 상태를 확인한다.
↓
다음 작업을 판단한다.
↓
Codex에게 구현을 위임한다.
↓
Unity에서 검증한다.
↓
필요한 경우 기존 구조를 다시 검토한다.
↓
최소한의 보완을 수행한다.
↓
Regression Test를 수행한다.
↓
Development Plan을 갱신한다.

에 가까운 형태로 조금씩 확장되고 있다.

번외로 이번 Test #2-2에서는 Rate Limit에 대응한 경우를 제외하면 테스트용 MacBook의 디스플레이를 끈 상태로 개발을 진행하였다. 이는 사용자가 Unity Editor나 Codex의 진행 상황을 지속적으로 확인하지 않아도, 루미가 현재 개발 상태를 기준으로 다음 작업을 판단하고 구현·검증 과정을 이어갈 수 있는지를 확인하기 위한 것이었다.

결과적으로 사용자가 화면을 켜지 않은 상태에서도 루미는 현재 Project 상태를 파악하고 다음 작업을 판단하여, Codex에게 구현을 위임하고 Unity에서 검증까지 수행할 수 있었다. 즉, 사용자의 지속적인 관찰 없이도 현재의 개발 Cycle을 일정 수준 자율적으로 진행할 수 있음을 확인하였다.

현재 다음 Milestone은 M4 Level / Interaction이다. M4부터는 기존 Player, Combat, Enemy 시스템에 실제 Level 구조와 Interaction, Generator, Puzzle 등이 연결되기 시작한다. 즉 지금까지 구현한 시스템들이 실제 게임 진행 구조 안에서 서로 연결되기 시작하는 단계다.

다음 Test에서는 이 상태에서 M4 이후 개발을 계속 진행하면서, 현재의 Planning 기반 개발 Workflow가 시스템 간 Dependency가 더 커진 상황에서도 정상적으로 유지되는지 확인해볼 예정이다.