投稿

[VX] 10. 기존 루미&Codex와 별개의 Independent Review 프로세스 추가 (Test #2-3)

[VX] 10. 기존 루미&Codex와 별개의 Independent Review 프로세스 추가 (Test #2-3)

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

이전 작업에서는 LAST SIGNAL의 M4 Level / Interaction을 구현하였다.

M4에서는 지금까지 개별적으로 구현했던 Player, Combat, Enemy, Interaction, Puzzle을 실제 Level Progression에 연결하였다. 또한 M0부터 M4까지 누적된 변경을 기존 Git Workflow에 따라 정리하고 main에 Merge한 뒤 원격 저장소까지 반영하였다.

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

하지만 바로 다음 구현으로 넘어가기 전에, 지금까지 사용하고 있던 검증 절차를 한 번 더 보강하기로 하였다.

기존 검증 방식

Project VX에서는 Codex가 구현한 결과를 그대로 완료로 처리하지 않는다. 구현 이후 Unity Editor와 Pipeline을 이용하여 Compile 상태, Console Error, Scene 상태, Component Reference, Runtime 동작 등을 확인하고, 필요한 경우 Regression Test까지 수행하도록 구성해두었다. 또한 이전 Test에서 Codex App을 이용해 구현 구조를 별도로 읽기 전용으로 점검한 적도 있었다.

하지만 이러한 검증은 기본적으로 하나의 개발 흐름 안에서 이루어지고 있었다. Codex가 구현을 진행하고, 그 결과를 기반으로 루미가 검증 상태를 확인한 뒤 Development Plan.md에 완료 여부를 기록하는 방식이었다.

프로젝트 규모가 커질수록 단순히 구현 직후의 검증만으로는 부족할 수 있다고 생각하였다. 특히 Milestone이 계속 누적되면 현재 구현이 기획과 일치하는지, 이전 시스템과의 Dependency가 올바른지, 임시 구현이나 기술 부채가 지나치게 쌓이지 않았는지 등을 별도의 관점에서 다시 확인할 필요가 있었다.

그래서 일정한 시점마다 구현 과정과 분리된 Codex Session을 이용해 프로젝트를 다시 검토하는 Independent Review 절차를 추가하였다.

Independent Review 규칙 추가

먼저 AGENTS.md를 수정하여 Independent Review에 대한 기본 운영 규칙을 추가하였다. 수정 이후 루미에게 새 규칙을 읽고 앞으로의 Project VX 작업에 반영하도록 요청하였다.

ゆならん: 새롭게 AGENTS.md를 수정했어. 수정된 내용을 읽고, 앞으로 Project VX 작업에 반영해줘. 기존 규칙과 새로 추가된 Independent Review 절차까지 포함해서 현재 운영 기준으로 적용해줘.

수정된 AGENTS.md와 Independent Review 규칙을 읽도록 요청한 모습

추가한 Independent Review의 기본 구조는 다음과 같다.

  • Review Checkpoint를 Development Plan.md에 계획
  • 기존 구현 Session과 분리된 새로운 Codex Review Session 사용
  • Reviewer는 Sol Medium 사용
  • Review는 읽기 전용으로 진행
  • 실제 코드, Scene, Prefab, Unity Editor 상태를 독립적으로 확인
  • Review 중 프로젝트 파일, Scene, Git 상태를 수정하지 않음
  • 결과를 정해진 상태로 분류
  • 루미가 Review 결과를 다시 판단하여 Development Plan.md에 반영
  • Rework가 필요하면 별도의 Codex 구현 작업으로 진행
  • Blocker가 발견되면 다음 Milestone 진행 중단
  • 프로젝트 최종 완료 전 Final Independent Review 수행

즉 Reviewer의 역할은 문제를 발견한 뒤 직접 수정하는 것이 아니다. 구현 상태를 독립적으로 확인하고 결과를 보고하는 것까지만 담당하며, 실제 수정 여부와 이후 작업 순서는 다시 루미가 결정하도록 역할을 분리하였다.

구현 Session과 Review Session 분리

이번 절차에서 가장 중요하게 본 부분은 구현을 담당한 Codex Session과 Review를 담당하는 Codex Session을 분리하는 것이었다.

기존 구현 Session이 자신이 진행한 작업을 계속 이어서 확인하는 것이 아니라, Review Checkpoint에 도달하면 새로운 Codex Session을 별도로 생성한다. 새 Reviewer는 기존 구현 과정에 직접 참여하지 않은 상태에서 현재 프로젝트를 다시 읽는다.

루미가 확인한 운영 규칙에서도 이 부분을 명확히 구분하였다.

Independent Review 운영 규칙을 확인한 루미의 답변

Review에서는 Project VX Planning.md, Development Plan.md, 실제 Unity 구현 상태를 서로 비교한다. 여기서 Project VX Planning.md는 계속 기획의 Source of Truth로 유지하며, Development Plan.md는 해당 기획을 기반으로 현재 개발 상태와 작업 순서를 기록하는 파생 운영 문서로 취급한다.

따라서 Reviewer는 단순히 코드가 Compile되는지만 확인하는 것이 아니라 다음 세 가지가 실제로 일치하는지를 확인하게 된다.

Planning ↔ Development Plan ↔ 실제 구현

기획에는 존재하지만 구현에서 빠진 항목이 있는지, 반대로 계획되지 않은 기능이 구현되어 있지는 않은지, Development Plan.md의 완료 상태가 실제 Project 상태와 일치하는지 등을 별도의 Session에서 다시 검토한다.

Reviewer는 Sol Medium 사용

Independent Review를 수행하는 Reviewer는 Sol Medium을 사용하도록 정하였다. 일반 구현에서는 작업의 복잡도와 위험도에 따라 모델을 선택하지만, Independent Review는 프로젝트의 여러 시스템과 문서, 현재 Unity 상태를 함께 비교해야 하기 때문에 일정 수준 이상의 추론 능력이 필요하다고 판단하였다.

따라서 Review Checkpoint에서는 별도의 모델 Routing 판단 없이 Sol Medium을 사용하도록 고정하였다. 단순히 오류 하나를 찾는 작업이 아니라 현재 Milestone 전체가 기획 의도와 실제 구현 사이에서 일관성을 유지하고 있는지를 확인하는 역할이기 때문이다.

Review 결과 분류

Independent Review 결과도 일정한 형태로 분류하도록 하였다.

현재 사용하는 분류는 다음과 같다.

  • Passed
  • Follow-up
  • Rework Required
  • Blocker
  • Technical Debt

Passed는 현재 상태에서 다음 단계로 진행해도 문제가 없다고 판단한 경우이다.

Follow-up은 현재 Milestone 진행을 막지는 않지만 이후 다시 확인해야 할 항목이 존재하는 경우다.

Rework Required는 현재 구현에 수정이 필요하다고 판단한 경우다.

Blocker는 현재 문제를 해결하기 전에는 다음 Milestone으로 진행해서는 안 되는 상태를 의미한다.

Technical Debt는 현재 기능 자체는 동작하지만 이후 유지보수나 확장 과정에서 문제가 될 가능성이 있는 구조를 별도로 기록하기 위한 상태다.

다만 Reviewer가 Rework RequiredBlocker를 판정했다고 해서 Reviewer가 직접 코드를 수정하지는 않는다.

Reviewer는 결과를 보고하고 종료하며, 루미가 결과를 다시 검토한다. 수정이 필요하다고 판단하면 새로운 Codex 구현 Session을 이용해 별도 작업으로 처리한다.

이를 통해 Review와 Implementation의 역할이 섞이지 않도록 하였다.

규칙 재확인

AGENTS.md를 한 번 읽힌 뒤에는 실제 운영 과정에서 규칙이 의도한 형태로 적용되는지 다시 확인하였다.

ゆならん: 한 번 더 AGENTS.md 관련 내용을 수정했는데 다시 한 번 확인해줄래?

수정된 Independent Review 규칙을 다시 확인한 모습

재확인 결과 다음 기준이 유지되는 것을 확인하였다.

Review Checkpoint는 Development Plan.md에 계획하고, 해당 시점에 구현 Session과 분리된 새로운 Codex Session을 생성한다.

Reviewer는 Sol Medium을 사용하고 완전한 read-only 방식으로 검증한다.

Review 중에는 구현 파일, 문서, Scene, Git 상태를 수정하지 않는다.

결과는 Reviewer가 보고만 하며, 최종 판단과 Development Plan.md 반영은 루미가 담당한다.

Blocker가 존재하는 경우 다음 Milestone으로 진행하지 않으며, Rework가 필요한 경우 Review 종료 이후 별도의 Codex 구현 작업을 생성한다.

그리고 프로젝트 전체 개발이 완료되기 전에는 Final Independent Review를 반드시 한 번 수행하도록 하였다.

Independent Review 절차 문서 분리

AGENTS.md에는 Project VX 전체 Agent 운영 규칙이 계속 누적되고 있다. 따라서 Independent Review의 세부 수행 절차까지 전부 AGENTS.md 안에 넣기보다는 별도의 문서로 분리하였다.

이를 위해 PROJECT_VX_INDEPENDENT_REVIEW.md를 작성하였다.

이후 루미에게 해당 문서를 읽고 앞으로 Independent Review를 수행할 때 이 절차를 기준으로 사용하도록 요청하였다.

ゆならん: PROJECT_VX_INDEPENDENT_REVIEW.md도 한 번 읽고, 앞으로 Independent Review를 진행할 때 해당 절차를 기준으로 적용해줘. 별도 구현이나 문서 수정은 하지 말고, 현재 규칙만 확인해줘.

Independent Review 전용 절차 문서를 확인하도록 요청한 모습

이 문서는 Independent Review가 실제로 실행될 때 Reviewer가 따라야 하는 Runbook 역할을 한다.

Review Checkpoint에 도달하면 먼저 해당 절차 문서를 확인하고, 구현 Session과 분리된 새로운 Codex Reviewer를 생성한다.

그 다음 Planning, Development Plan, 실제 구현을 독립적으로 비교하고 Unity Editor와 Pipeline 역시 read-only 상태로 확인한다.

Reviewer는 결과를 정해진 분류로 보고한 뒤 종료하며, 프로젝트 수정이나 Git 작업은 수행하지 않는다.

따라서 구조를 단순화하면 다음과 같다.

Milestone 구현 → 일반 Unity 검증 → Review Checkpoint → 새로운 Codex Reviewer → Independent Review → 루미 판단 → 다음 작업 결정

기존 Unity 검증을 Independent Review가 대체하는 것은 아니다. 구현 직후의 Compile, Runtime, Regression Test 등은 기존처럼 계속 수행한다.

Independent Review는 특정 Checkpoint에서 프로젝트 전체 상태를 한 단계 높은 관점에서 다시 확인하는 추가 검증 절차에 가깝다.

왜 별도의 Review 절차를 추가했는가

현재 LAST SIGNAL은 M4까지 진행되었다. M0에서는 Project 구조를 만들었고, M1에서는 Player, M2에서는 Combat, M3에서는 Enemy, M4에서는 Level과 Interaction을 구현하였다.

처음에는 각각의 기능이 비교적 독립적이었지만, M4부터는 이전 Milestone의 결과가 서로 직접 연결되기 시작하였다.

앞으로 진행할 M5 Game State에서는 Generator 상태, Objective, Checkpoint, Respawn까지 연결된다.

M6 이후에는 Boss, Game Flow 등 더 많은 시스템이 기존 구현에 의존하게 된다.

이 상황에서 단순히 현재 기능이 동작한다는 것만 확인하면, 프로젝트 전체 구조의 문제를 늦게 발견할 가능성이 있다. 그래서 일정한 Checkpoint마다 구현 과정과 분리된 Session이 현재 Project를 다시 검토하도록 만들었다.

특히 Reviewer에게 수정 권한을 주지 않은 이유도 여기에 있다. Review 도중 발견한 문제를 그 자리에서 바로 고치기 시작하면 다시 하나의 구현 Session처럼 동작하게 되고, 무엇을 검토했고 무엇을 수정했는지 경계가 불분명해질 수 있다.

따라서 Reviewer는 상태를 판정하는 역할만 담당하고, 실제 수정은 다시 Implementation Workflow로 돌려보내도록 하였다.

현재 Project VX 검증 구조

Independent Review를 추가한 뒤 Project VX의 검증은 크게 두 단계로 나뉘게 되었다.

첫 번째는 각 구현 작업 직후 수행하는 일반 검증이다.

여기에서는 Compile, Console Error, Unity Editor 상태, Runtime 동작, Regression Test 등 해당 구현이 실제로 정상 작동하는지를 확인한다.

두 번째는 계획된 Review Checkpoint에서 수행하는 Independent Review이다.

여기에서는 구현 Session과 분리된 새로운 Reviewer가 현재 기획, Development Plan, 코드와 Unity 상태를 다시 비교한다.

따라서 앞으로의 기본 흐름은 다음과 같은 형태가 된다.

Planning → Development Plan → Codex 구현 → Unity 검증 → Milestone 진행 → Independent Review Checkpoint → 루미 판단 → 다음 Milestone

문제가 없다면 그대로 다음 단계로 진행한다.

Follow-up이나 Technical Debt가 있다면 기록을 남기고 이후 작업에서 다시 확인한다.

Rework가 필요하면 별도의 구현 작업을 생성하며, Blocker가 있다면 해당 문제를 해결하기 전까지 다음 Milestone으로 넘어가지 않는다.

결론

이번에는 새로운 게임 기능을 추가하지 않았다. 대신 Project VX에서 앞으로 사용할 Independent Review 절차를 추가하였다.

지금까지도 Codex 구현 이후 Unity Editor와 Pipeline을 이용한 검증을 수행하고 있었지만, 프로젝트가 복잡해질수록 구현 Session과 분리된 별도의 검토 과정이 필요하다고 판단하였다.

이에 따라 계획된 Review Checkpoint에서는 새로운 Codex Reviewer Session을 생성하고, Sol Medium을 이용해 Planning, Development Plan, 실제 구현 상태를 독립적으로 비교하도록 하였다.

Reviewer는 완전히 read-only로 동작하며 프로젝트 파일이나 Git 상태를 변경하지 않는다.

Review 결과 역시 Reviewer가 직접 해결하지 않고 Passed, Follow-up, Rework Required, Blocker, Technical Debt로 분류해 보고한다.

그 결과를 바탕으로 루미가 이후 작업 방향을 다시 결정한다.

또한 Independent Review의 세부 수행 방식은 PROJECT_VX_INDEPENDENT_REVIEW.md로 분리하여 앞으로 동일한 절차를 반복해서 사용할 수 있도록 하였다.

다음 개발 단계는 다시 LAST SIGNAL의 M5 Game State이다.

앞으로는 Milestone 구현과 Unity 검증뿐만 아니라 계획된 Checkpoint에서 Independent Review까지 수행하면서, Project가 기획과 실제 구현 사이에서 계속 일관성을 유지하는지도 함께 확인해볼 예정이다.

この投稿は投稿者によって CC BY 4.0 の下でライセンスされています。