[VX] 02. 루미 및 Codex Git/Github 작업 권한 관련 지침 수정

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

이전 작업 에서는 루미(OpenClaw), Codex, Unity를 연결하여 이하와 같은 개발 경로가 실제로 동작하는 것을 확인하였다.

ゆならん(私) –> 루미 –> Codex –> Unity Editor –> 검증 결과 –> 루미

루미에게 기능 구현을 요청하면 Codex가 실제 프로젝트를 수정하고, 이후 Unity Editor에서 Recompile, Play Mode, Console 상태 등을 확인하여 다시 루미가 결과를 전달할 수 있었다. 즉, 최소한의 개발 및 검증 루프 자체는 만들어진 셈이다.

하지만 실제 개발을 계속하려면 여기서 한 가지 문제가 더 생긴다.

Codex가 구현을 완료한 이후 Git과 GitHub는 누가 관리할 것인가?

단순한 테스트 프로젝트라면 Codex가 코드 수정부터 commit, push까지 모두 수행하도록 해도 큰 문제가 없을 수 있다. 하지만 Project VX에서는 루미와 Codex의 역할을 명확하게 구분하고 싶었다.

따라서 이번에는 실제 개발을 시작하기 전에 Git 및 GitHub와 관련된 권한과 작업 규칙을 정리하였다.

처음 생각했던 GitHub 작업 규칙

처음 생각했던 구조는 비교적 단순했다.

Codex는 실제 코드 작성과 수정, 테스트를 담당하고, GitHub에 영향을 주는 최종 작업은 루미가 수행하는 방식이었다.

이를 간단하게 표현하면 다음과 같다.

루미	Codex
Git commit	코드 작성
Git merge	코드 수정
Git push	리팩터링
최종 변경 검토	테스트

즉 Codex는 Implementation을 담당하지만,

commit
merge
push

와 같이 Git repository의 최종 상태에 영향을 주는 작업은 루미가 담당하도록 하는 것이다.

이를 위해 처음에는 AGENTS.md에 다음과 같은 원칙을 추가하였다.

GitHub에 대한 최종 commit, merge, push 작업은 반드시 루미가 직접 수행한다.
Codex는 코드 작성, 수정, 리팩터링, 테스트 등의 개발 작업을 수행할 수 있으나 직접 Git commit, merge, push를 수행하지 않는다.
Codex가 작업한 결과 역시 루미가 변경 사항을 확인한 뒤 Git 작업을 수행한다.

이렇게 하면 루미가 Codex의 구현 결과를 검토하고, 문제가 없다고 판단한 이후 Repository에 반영할 수 있다.

처음에는 이 정도면 충분하다고 생각했다.

하지만 규칙을 다시 검토해보니 문제가 하나 있었다.

commit과 push만 막으면 충분한가?

Codex에게 commit, merge, push만 금지한다고 해서 Git repository의 상태를 보호할 수 있는 것은 아니다. Git에는 그 외에도 repository의 상태를 변경하는 명령이 상당히 많다.

예를 들어 Codex가 다음과 같은 작업을 수행할 수 있다고 가정할 수 있다.

git add
git switch
git checkout
git reset
git restore
git stash
git clean
git tag
git rebase
git revert
……

이 중 일부는 GitHub Remote에 직접적인 영향을 주지는 않는다. 하지만 로컬 repository의 상태는 충분히 변경할 수 있다.

특히 다음과 같은 상황이 문제가 될 수 있다고 생각했다.

ゆならん이 직접 작업 중인 변경 사항 –> Codex 작업 시작 –> Codex가 작업과 관련 없다고 판단 –> restore / reset / clean –> 기존 작업 내용이 변경되거나 사라짐

Codex에게 불필요한 변경이라고 해서 프로젝트 전체에서도 불필요한 변경인 것은 아니기에, 단순히 Codex가 Push하지 못하게 하는 것으로는 부족하다고 생각했다.

Git 변경 권한을 루미에게 집중

따라서 Git과 관련된 규칙을 조금 더 강하게 수정하였다. 기본 원칙은 간단하다.

Project VX의 Git 상태를 변경할 수 있는 주체는 루미 하나로 제한한다.

Codex는 Git repository의 현재 상태를 읽을 수는 있지만 직접 변경하지 않는다.

최종적인 역할 구분은 다음과 같이 정하였다.

작업	루미	Codex
git status	O	O
git diff	O	O
git log	O	O
git show	O	O
Branch 생성/삭제/전환	O	X
Staging	O	X
Commit	O	X
Merge	O	X
Rebase	O	X
Revert	O	X
Reset / Restore	△	X
Stash 생성/적용/삭제	△	X
Tag 생성/삭제	O	X
git clean	△	X
Push	O	X
Force Push	△	X
Remote 설정 변경	△	X

즉 Codex에게 허용되는 Git 사용은 기본적으로 읽기 전용 작업이다.

Codex는 이를 이용해

• 자신이 어떤 파일을 수정했는지
• 기존 코드와 무엇이 달라졌는지
• 현재 repository의 상태가 어떤지

등은 확인할 수 있다. 하지만 repository의 상태나 history를 바꾸는 작업은 수행하지 않는다.

Codex에게는 구현을 위한 충분한 정보 접근 권한을 주되, Git 상태를 변경하는 권한은 분리한 것이다. 결과적으로 Project VX에서의 역할은 조금 더 명확해졌다.

ㅤ	루미	ㅤ
ㅤ	↓	ㅤ
↓	<–>	↓
Orchestration	ㅤ	Git Workflow
↓	ㅤ	↓
Codex	ㅤ	Git/Github
↓	(Implementation)	ㅤ
Unity	ㅤ	ㅤ

Codex는 프로젝트 내용의 구현을 담당하고, 루미는 프로젝트 전체 작업과 Git 상태를 관리한다.

왜 Git 작업은 루미가 담당하는가?

굳이 Git 작업을 루미와 Codex 사이에서 분리한 이유는 두 Agent가 바라보는 작업의 범위가 다르기 때문이다.

Codex에게 특정 기능 구현을 맡겼다면 Codex의 주요 관심사는 그 기능이다.

예를 들어,

Player에 Dash 기능을 구현해줘.

라는 작업을 맡겼다면 Codex는 관련 C# 코드와 Scene, Prefab 등을 조사하고 기능을 구현하는 것에 집중하면 된다.

반면 Git 작업에서는 좀 더 넓은 범위를 확인할 필요가 있다.

현재 어떤 Branch에 있는가?
Remote에는 새로운 변경이 있는가?
Codex가 수정한 파일 이외에 기존 변경 사항이 존재하는가?
현재 변경을 하나의 Commit으로 묶는 것이 적절한가?
Merge하기 전에 추가 검증이 필요한가?
현재 변경 사항을 Remote까지 Push해야 하는가?

이런 판단은 하나의 구현 작업보다는 Project VX 전체 상태에 더 가깝다. 그리고 Project VX에서 프로젝트 전체를 관리하는 역할은 루미에게 맡기고 있다.

따라서

Codex = Implementation
루미 = Orchestration + Git Authority

로 역할을 나누는 편이 구조적으로 더 자연스럽다고 판단하였다.

변경 사항의 작성 주체 기록

Git 관련 규칙을 수정하면서 Commit Message에 대한 규칙도 추가하였다. Project VX는 나와 AI Agent가 함께 개발하는 프로젝트이기 때문에, 나중에 Git History를 확인했을 때 해당 변경 사항을 실제로 누가 만들었는지도 구분할 수 있도록 하고 싶었다. 따라서 모든 Commit Message의 앞에 변경 사항의 작성 주체를 표시하도록 하였다.

현재 사용하는 작성 주체는 다음 두 가지이다.

Lumi: ゆならん:

여기서 중요한 점은 누가 git commit 명령을 실행했는지를 표시하는 것이 아니라, 실제 변경 결과물의 작성 주체를 표시한다는 것이다.

예를 들어 내가 직접 파일을 수정했다면 다음과 같이 기록한다.

ゆならん: …

반면 루미가 직접 작성했거나, 루미의 지시에 따라 Codex가 구현한 변경이라면 다음과 같이 기록한다.

Lumi: …

Codex가 직접 코드를 작성했다고 해서

Codex:

라는 별도의 Prefix를 사용하지는 않는다. Project VX에서는 Codex를 독립적인 프로젝트 관리 주체가 아니라 루미가 구현 작업을 위임하는 Coding Agent로 취급하기 때문이다.

또한 이 Prefix는 Git의 Author 정보와는 별개의 Project VX 내부 기록 규칙이다. Git 작업 자체는 여전히 Lumi가 수행하지만, Git History를 확인했을 때 인간이 직접 작성한 변경과 Agent Workflow를 통해 만들어진 변경을 쉽게 구분할 수 있도록 한 것이다.

Project VX 자체가 AI Agent를 이용한 게임 개발 Workflow를 실험하는 프로젝트인 만큼, 이런 기록도 이후 개발 과정을 분석할 때 의미가 있을 것이라고 생각하였다.

Commit Message 형식 정리

작성 주체만 표시하면 Commit Message의 형태가 제각각이 될 수 있기 때문에 간단한 Type 규칙도 함께 추가하였다. 기본 Commit Message 형식은 다음과 같다.

<작성주체>: <타입>/<설명>

예를 들면 다음과 같다.

Lumi: feat/Add Player Dash System
Lumi: fix/Fix Skill Cooldown Issue
ゆならん: docs/Update Project VX Planning

사용하는 타입은 다음과 같이 정하였다.

feat/
fix/
set/
docs/
refactor/
test/
perf/
build/
revert/
asset/

이를 통해 Git History만 보더라도 대략 어떤 종류의 변경인지 파악할 수 있도록 하였다. 다만 이 규칙의 목적은 Commit Message 자체를 복잡하게 만드는 것이 아니라, 사람이 직접 작성한 변경과 AI Agent Workflow에서 발생한 변경을 추적하기 쉽게 만드는 데 있다.

main Branch에서 직접 작업하지 않기

Git Workflow 자체도 조금 더 정리하였다.

Project VX에서는 기본적으로 main Branch에서 직접 Commit하지 않는다. 또한 새로운 작업을 시작할 때는 별도의 Work Branch를 만든다.

작명 규칙은 Commit Message와 같은 규칙을 따른다.

Merge는 기본적으로 –no-ff 방식을 사용하도록 하였다. 이를 통해 작업 Branch에서 이루어진 변경이 하나의 작업 단위였다는 흔적을 History에 남길 수 있다.

또한 Work Branch는 특별한 이유가 없다면 Remote에 Push하지 않고 로컬에서 유지한다. 즉 GitHub에 불필요한 임시 Branch를 계속 생성하기보다는, 작업이 완료된 결과를 main에 통합한 이후 필요한 결과만 Remote에 반영하는 방식이다.

AGENTS.md와 Git Workflow 문서 분리

Git 규칙을 계속 추가하다 보니 또 하나의 문제가 생겼다. Git Workflow의 세부 절차까지 모두 AGENTS.md에 넣으면 문서가 지나치게 길어질 수 있었다.

AGENTS.md에는 Git뿐만 아니라 루미와 Codex의 역할, 모델 선택, 검증 방식 등 Project VX 개발 전반의 규칙이 들어갈 예정이기 때문이다. 따라서 Git의 권한과 실제 작업 절차를 분리하기로 하였다.

이를 위해 별도의 PROJECT_VX_GIT_WORKFLOW.md 문서를 만들었다.

이 문서에는 다음과 같은 실제 Git 작업 절차를 기록하였다.

Remote 상태 확인
main 직접 Commit 금지
Work Branch 생성 규칙
Commit Message 규칙
Merge 방식
Push 방식
Work Branch 관리
Remote 결과 검증
위험 Git 작업 제한

루미는 Git repository의 상태, history, branch, tag, remote 등을 변경하기 전에 이 문서를 기준으로 작업하도록 하였다.

Git 관련 기타 수정 사항

• git reset –hard / git clean -f 과 같이 위험한 Git 명령을 제한했다.
• Git 변경 권한을 가지고 있는 루미도 기존 작업물이 손실될 가능성이 있다면 이러한 작업을 임의로 수행하지 않도록 했다.
• Remote와의 동기화에서도 단순히 git pull을 실행하지 않도록 하였다. 먼저 fetch를 수행하고 local main과 origin/main의 상태를 비교한 뒤, 양쪽에 서로 다른 Commit이 존재하는 diverged 상태라면 Lumi가 임의로 Merge 또는 Rebase하지 않고 나에게 보고하도록 하였다.
• Git 작업을 시작하기 전에는 반드시 git status와 staged/unstaged diff를 확인하도록 하였다. 이미 존재하는 변경사항은 현재 작업과 무관하더라도 임의로 Commit, Stash, 삭제 또는 덮어쓰지 않는다.

결론

처음에는 단순히

Codex가 구현했으면 그대로 Commit하고 Push하게 만들면 편하지 않을까?

라고 생각할 수도 있다. 기술적으로 구현 자체는 어렵지 않다.

하지만 Project VX에서 중요한 것은 가능한 작업을 전부 자동화하는 것 자체가 아니다. 어떤 Agent가 어떤 책임을 가지고 행동하는지 명확하게 정의한 상태에서 자동화하는 것이 더 중요하다고 생각한다.

특히 Git은 한 번 잘못된 작업을 수행하면 코드 몇 줄의 오류와 달리 기존 작업물이나 History 전체에 영향을 줄 수 있다. 그래서 이번에는 자동화 범위를 넓히기 전에 먼저

Codex는 어디까지 할 수 있는가?
Lumi는 무엇을 책임지는가?
Git History의 변경 주체는 어떻게 기록하는가?
기존 작업물은 어떻게 보호하는가?

를 정리하였다.

01편에서 Lumi와 Codex, Unity 사이의 기술적인 연결을 만들었다면, 이번 작업에서는 그 연결 위에서 실제 개발을 진행하기 위한 권한과 책임의 경계를 하나 더 만들었다고 볼 수 있다.

그리고 다음으로 남은 문제는 이것이다.

Lumi와 Codex에게 각각 어떤 작업을 맡길 것인가?

모든 작업에 같은 모델을 사용할 필요는 없다. 단순한 파일 수정과 복잡한 아키텍처 설계는 필요한 추론 수준이 다르고, Codex에게 여러 Sub-agent를 무제한으로 생성하게 하는 것 역시 효율적이라고 보기 어렵다.

따라서 다음에는 Lumi와 Codex의 역할을 조금 더 세분화하고, 어떤 작업을 Lumi가 직접 수행할지, 어떤 작업을 Codex에게 위임할지, Luna XHigh와 Sol Medium을 어떤 기준으로 선택할지, Codex의 Sub-agent를 언제 사용할지, 실패한 작업을 언제 상위 모델로 승격할지 등을 정리하기 위해 관련 AGENTS.md 지침을 수정할 예정이다.

(루미의 Git 권한에 대한 답변 전체)
ゆならん님, 확인해봤어요. GitHub/Git 관련 지침이 꽤 구체적으로 추가되어 있네요.

• Project VX Git 작업은 루미가 전담
  • Codex는 코드·프로젝트 구현만 담당
  • Codex의 Git 변경 작업은 금지
  • 브랜치 생성, 스테이징, 커밋, 머지, 리베이스, 푸시 등은 루미가 수행
• main 직접 커밋 금지
  • 별도 작업 브랜치 사용
  • 브랜치 형식: feat/add-movement-system
  • 작업 후 main에 기본적으로 --no-ff 머지
• 커밋 메시지 규칙
  • 형식: <Author>: <type>/<English Description>
  • 예: Lumi: feat/Add Movement System
  • 타입: feat, fix, set, docs, refactor, test, perf, build, revert, asset
• 기존 작업 보호
  • Git 작업 전 반드시 status, staged/unstaged diff 확인
  • 기존 변경사항을 임의로 커밋·stash·삭제·덮어쓰기 금지
  • reset --hard, clean, force push 등은 명시적 승인 필요
• main 동기화
  • git pull 무조건 실행 금지
  • 먼저 fetch 후 local main과 origin/main 비교
  • diverged 상태면 임의로 merge/rebase하지 않고 보고
• Remote/GitHub
  • 작업 브랜치는 기본적으로 로컬에만 유지
  • PR·협업 등 명확한 이유가 있을 때만 작업 브랜치 push
  • GitHub에 push하거나 PR을 만드는 외부 작업은 사용자 의도가 명확해야 함
  • 완료 보고 시 실제 Remote 상태까지 확인

그리고 /opt/homebrew/.../github/SKILL.md에는 GitHub CLI 사용 시 gh를 쓰고, PR·Issue·CI·GitHub API는 gh로 처리하라는 지침도 있어요.

참고로 현재 workspace Git 저장소는 아직 커밋이 하나도 없고 모든 지침 파일이 untracked 상태라서, “이전 버전과 비교해 무엇이 추가됐는지”는 Git diff로 확인할 수 없었어요. 현재 적용된 지침 자체는 정상적으로 확인했습니다.