(본 게시물의 이미지에는 AI 번역을 사용한 이미지가 포함되어 있습니다.)
(모든 이미지/동영상은 직접 캡쳐한 것입니다.)
이전 작업에서는 지금까지 구성한 루미(OpenClaw)-Codex-Unity 개발 환경을 이용하여 실제로 간단한 게임 개발을 진행해보았다. 이를 통해 루미에게 개발 내용을 전달하면 Codex가 실제 구현을 진행하고, Unity Editor에서 결과를 검증한 뒤 다시 루미가 결과를 전달하는 기본적인 개발 Workflow가 동작한다는 것을 확인할 수 있었다.
하지만 실제 Project VX의 개발을 시작하려면 아직 해결해야 할 문제가 하나 있었다.
지금까지는 내가 루미에게 직접
어떤 기능을 구현해야 하는가?
어떤 방식으로 동작해야 하는가?
현재 기획은 어떻게 되어 있는가?
를 설명하고 있었다.
간단한 테스트에서는 큰 문제가 없지만, 실제 게임의 규모가 커질수록 이러한 방식은 비효율적이다. Project VX의 게임 시스템, 캐릭터, 스토리, 전투 구조 등 대부분의 기획 내용은 이미 Obsidian에 작성하고 있기 때문이다.
그렇다면 내가 매번 기획을 다시 설명할 필요 없이,
루미가 Obsidian의 Project VX 기획 문서를 직접 읽고 이를 개발에 활용하도록 만들 수 있지 않을까?
이번에는 이를 구현해보기로 하였다.
기존 구조의 문제
지금까지 만들어둔 개발 구조를 단순하게 표현하면 다음과 같다.
ゆならん(私) → 루미 → Codex → Unity → 검증 → 루미
루미는 Project VX 전체 개발을 관리하고, Codex는 실제 Implementation을 담당한다. 이 구조 자체는 잘 동작했다. 하지만 개발을 시작하기 위해서는 여전히 내가 루미에게 구체적인 정보를 제공해야 했다.
예를 들어 새로운 전투 시스템을 구현한다고 가정하면,
이 시스템은 어떤 목적으로 존재하는가?
어떤 입력을 사용하는가?
기존 시스템과 어떤 관계가 있는가?
현재 기획에서 변경된 내용은 무엇인가?
등을 다시 설명해야 한다.
하지만 이러한 정보는 이미 Obsidian에 존재한다. 따라서 내가 원한 구조는 다음에 더 가까웠다.
| ㅤ | Obsidian | ㅤ |
|---|---|---|
| ㅤ | ↓ | ㅤ |
| ゆならん | → 루미 ← | Project VX 기획 |
| ㅤ | ↓ | ㅤ |
| ㅤ | Codex | ㅤ |
| ㅤ | ↓ | ㅤ |
| ㅤ | Unity | ㅤ |
즉, 루미가 내가 내리는 명령뿐만 아니라 Project VX의 기획 자체를 Context로 사용할 수 있도록 하는 것이다.
Obsidian을 Project VX의 기획 원본으로 사용
나는 원래 게임 기획을 Obsidian에서 작성하고 있다.
Project VX 역시 별도의 Vault인 Project_VX_Planning에서 기획을 관리하고 있었기 때문에, 새로운 기획 시스템을 따로 만드는 것보다 기존 Obsidian 문서를 그대로 활용하는 것이 가장 자연스럽다고 판단하였다.
여기서 중요한 것은 Obsidian을 단순한 참고자료로 사용하는 것이 아니었다. Project VX의 기획과 관련된 판단에서는 Obsidian의 기획 문서를 기준점으로 사용하도록 하였다.
즉,
내가 루미에게 이전 대화에서 설명했던 내용
보다
현재 Obsidian에 기록되어 있는 Project VX의 최신 기획
을 우선하도록 하는 것이다.
이를 통해 오래된 Conversation Context 때문에 이미 수정된 기획을 잘못 사용하는 문제를 줄일 수 있다.
구조적으로는 다음과 같다.
Obsidian
↓
Project VX Planning
↓
루미
↓
현재 기획을 기준으로 판단
이렇게 하면 Obsidian은 단순한 노트 프로그램이 아니라 Project VX 개발의 Single Source of Truth 역할을 하게 된다.
루미의 Obsidian 접근 테스트
먼저 루미가 실제로 Obsidian Vault에 접근할 수 있는지 확인해야 했다.
단순히 문서를 읽을 수 있다는 것만 확인하는 것보다, 실제로 특정 문서를 수정하고 그 결과를 Obsidian에서 직접 확인하는 것이 확실하다고 생각했다.
그래서 이후 개발 계획 문서로 사용할 예정이었던 Development Plan.md를 이용해 먼저 간단한 작성 테스트를 진행하였다.
ゆならん: 루미야 Obsidian에서 Development Plan.md라는 파일에 한번 테스트 내용 아무거나 써볼래?
루미는 Obsidian을 통해 해당 문서를 수정한 뒤 다시 읽어 저장 여부까지 확인하였다.
ルミ: 작성했어요, ゆならん님~ ✨
Project_VX_Planning/Development Plan.md에 Obsidian 작성 테스트 내용을 추가했고, 다시 읽어서 저장된 것도 확인했어요.
실제 Obsidian을 확인해보니 Development Plan.md에 테스트 내용이 정상적으로 추가되어 있었다.
이것으로 최소한 루미가 Project VX의 Obsidian Vault에 접근하여 문서를 읽고 수정할 수 있다는 것을 확인하였다.
특히 위 이미지에서는 왼쪽에 이후 루미가 관리하게 될 Development Plan, 오른쪽에는 내가 작성하고 있던 Project VX Planning 문서가 동시에 존재한다.
이후 두 문서는 서로 다른 역할을 담당하도록 구성할 예정이다.
기존 문서를 유지한 상태에서 수정할 수 있는가?
단순히 파일에 새로운 내용을 작성할 수 있다는 것만으로는 충분하지 않았다.
앞으로 Development Plan.md는 개발 과정에서 지속적으로 사용될 문서이기 때문이다.
따라서 기존 문서 구조를 유지하면서 필요한 부분만 수정할 수 있는지도 확인해보았다.
방금 루미가 추가했던 테스트 내용만 다시 삭제하도록 요청하였다.
ゆならん: 한 번 방금 쓴 내용을 삭제해줄래?
루미는 테스트로 추가했던 내용만 제거하고 기존 Front Matter는 그대로 유지했다고 답변하였다.
ルミ: 삭제했어요, ゆならん님~
방금 추가했던 테스트 내용만 지우고, 기존 frontmatter는 그대로 남겨뒀어요.
실제 Obsidian에서도 테스트 내용만 삭제되고 기존 문서 자체는 그대로 유지되어 있었다.
이를 통해 루미가 단순히 Obsidian 파일 전체를 새로운 내용으로 덮어쓰는 것이 아니라, 기존 내용을 유지한 상태에서 필요한 부분을 수정하는 것도 가능하다는 것을 확인하였다. 이 테스트를 통해 Obsidian과 루미 사이의 기본적인 읽기·쓰기 경로 자체는 확보할 수 있었다.
하지만 실제 Project VX 개발에 이를 사용하기 위해서는 단순한 파일 접근 이상의 규칙이 필요했다.
기획 문서와 Development Plan의 역할 분리
Obsidian에 접근할 수 있게 된 이후에는 또 다른 문제가 생겼다.
Project VX의 기획을 루미가 읽을 수 있다고 해도,
게임의 기획과 현재 개발 상태는 같은 정보가 아니다.
예를 들어 Project VX의 기획 문서에는 다음과 같은 내용이 존재한다.
- 게임 시스템
- 캐릭터
- 전투 구조
- 스토리
- UI
- 연출
- 각종 세부 규칙
이러한 내용은
게임이 최종적으로 어떤 형태여야 하는가?
를 정의한다.
반면 실제 개발에서는 다음과 같은 정보도 필요하다.
- 현재 어느 단계까지 개발했는가?
- 다음 작업은 무엇인가?
- 현재 어떤 작업이 막혀 있는가?
- 어떤 작업을 먼저 구현해야 하는가?
- 기획 변경으로 인해 다시 구현해야 하는 부분이 있는가?
- 현재 Milestone은 무엇인가?
이것은 기획 자체와는 다른 종류의 정보다.
그래서 두 문서의 역할을 명확하게 분리하기로 하였다.
| Project VX Planning | Development Plan |
|---|---|
| 게임의 기획 원본 | 현재 개발 계획 및 상태 |
| ゆならん이 작성 | 루미가 관리 |
| 게임이 무엇이어야 하는지 정의 | 지금 무엇을 해야 하는지 정의 |
| 캐릭터 / 시스템 / 스토리 | Milestone / Task / Priority |
| Authoritative Design Source | Persistent Orchestration State |
즉,
Project VX Planning = 게임의 기획 원본
이고,
Development Plan = 그 기획을 실제 게임으로 만들기 위한 현재 개발 계획
이라고 볼 수 있다.
여기서 Development Plan은 Project VX Planning을 대체하지 않는다.
기획 자체를 변경해야 하는 경우에는 내가 Project VX Planning을 수정하고, 루미는 그 내용을 읽어 개발 계획에 반영한다.
이렇게 하면 사람이 관리해야 하는 Design Source와 AI Agent가 관리하는 Development State를 서로 섞지 않을 수 있다.
Development Plan은 루미가 직접 관리
Project VX에서는 기본적으로 실제 프로젝트 구현을 Codex에게 맡기고 있다.
하지만 Development Plan.md는 예외적으로 루미가 직접 관리하도록 하였다.
이는 Development Plan.md는 게임의 실제 구현물이 아니라 루미가 Project VX 전체 개발을 조율하기 위해 사용하는 상태 문서이기 때문이다.
따라서 다음과 같은 작업은 루미가 담당한다.
Project VX Planning 읽기
↓
현재 기획 분석
↓
현재 개발 상태 확인
↓
Milestone 및 Task 정리
↓
Development Plan 갱신
Codex가 하나의 기능을 실제로 구현하는 Implementation Agent라면, Development Plan을 관리하는 것은 Project VX 전체 상태를 관리하는 Orchestrator인 루미의 역할에 더 가깝다고 판단하였다. 이 구조는 이전에 Git/GitHub 권한을 나누었던 이유와도 비슷하다.
Codex와 루미를 단순히
더 강한 AI / 더 약한 AI
로 나누는 것이 아니라,
각자 책임지는 범위
에 따라 역할을 나누는 방식이다.
기획이 도중에 변경된다면?
게임 개발 과정에서 기획은 계속 바뀐다. 오늘 작성한 시스템이 한 달 뒤에도 완전히 동일하게 유지된다는 보장은 없다. 만약 루미가 한 번 읽었던 기획만 기억하고 계속 개발한다면 문제가 발생한다.
예를 들어 Obsidian에서는 이미
기존 시스템 A 삭제
새로운 시스템 B로 교체
라고 수정했는데,
루미가 이전 Context를 기준으로 계속 시스템 A를 개발할 수도 있다. 따라서 실제 개발을 시작하기 전에 기획 변경 여부를 먼저 확인하도록 하는 과정이 필요하다고 생각했다.
이를 Planning Sync라고 이름붙였다.
기본적인 흐름은 다음과 같다.
Project VX Planning
↓
기획 변경 확인
↓
루미
↓
변경 내용 분석
↓
영향 범위 분석
↓
Milestone / Task 재조정
↓
Development Plan 갱신
예를 들어 전투 시스템에 대한 기획이 변경되었다면 단순히
전투 시스템이 변경되었습니다.
라고 기록하는 것으로 끝내지 않는다.
해당 변경이
- 현재 구현 중인 기능에 영향을 주는지
- 이미 구현한 기능을 다시 수정해야 하는지
- 다른 시스템과 Dependency가 존재하는지
- 현재 Milestone의 우선순위를 변경해야 하는지
등을 확인한 뒤 Development Plan에 반영하도록 하는 것이다. 이미 구현된 내용과 새로운 기획이 충돌한다면 이를 바로 임의로 수정하는 대신, 우선 개발 계획에 Rework가 필요한 작업으로 기록한 뒤 별도의 개발 과정에서 처리하도록 하였다. 즉 Planning 단계와 Implementation 단계를 명확하게 분리한다.
매번 전체 기획을 읽는 것은 비효율적이지 않을까?
여기서 또 하나의 문제가 있었다. Project VX Planning 문서는 앞으로 계속 길어질 예정이다. 캐릭터, 전투 시스템, 스토리, UI, 세계관 등이 계속 추가된다면 개발을 시작할 때마다 전체 기획 문서를 처음부터 다시 읽는 것은 비효율적이다. 기획이 전혀 바뀌지 않은 날에도 매번 같은 문서를 다시 읽고 분석하게 되면,
- 불필요한 Token 사용
- Planning 시간 증가
- 불필요한 고성능 모델 호출
이 발생할 수 있다.
그래서 기획 내용을 읽기 전에 문서 자체가 변경되었는지 먼저 확인하는 방식을 사용하기로 하였다.
기본적인 구조는 다음과 같다.
Project VX Planning.md
↓
현재 문서 Hash 계산
↓
이전 Planning Source Hash와 비교
이후 결과에 따라 두 가지로 나뉜다.
| Hash 동일 | Hash 변경 |
|---|---|
| 전체 기획 재분석 생략 | 최신 기획 다시 읽기 |
| Development Plan 유지 | 변경점 분석 |
| Planning Sync 종료 | 영향 범위 분석 |
| Development Plan 재구성 |
즉 문서 내용이 이전 개발 시점과 동일하다면 전체 기획을 다시 읽지 않는다.
반대로 Hash가 달라졌다면 그때 Project VX Planning을 다시 읽고, 실제로 무엇이 바뀌었는지 분석하여 Development Plan을 재구성한다.
구조적으로는 다음과 같다.
Project VX Planning.md
↓
SHA-256 계산
↓
이전 Hash와 비교
↓
변경 없음 → Planning Sync 종료
변경 있음 → Planning 문서 분석 → Replanning
이를 통해 매 개발 시작마다 거대한 기획 문서를 무조건 다시 읽는 대신,
변경 여부를 먼저 확인하고, 필요한 경우에만 Replanning을 수행하는 구조를 만들 수 있었다.
Planning과 Implementation을 분리
여기서 중요하게 정한 규칙이 하나 더 있다.
Planning Sync가 끝났다고 바로 게임을 수정하지 않는다.
Planning Sync의 역할은 어디까지나
최신 기획과 현재 개발 계획을 맞추는 것
이다.
예를 들어 새 기획을 확인한 결과 기존 구현을 대규모로 수정해야 한다는 결론이 나왔다고 해도, Planning 과정에서 Codex를 바로 호출해 해당 코드를 수정하지 않는다.
우선 Development Plan에 작업을 정리한다.
그 이후 실제 Development Workflow가 시작될 때,
Development Plan 확인
↓
작업 선정
↓
루미가 Codex에 작업 분배
↓
구현
↓
Unity 검증
↓
Git 반영
순서로 진행한다.
즉 Project VX에는 크게 두 개의 Workflow가 존재하게 된다.
Planning Workflow
Obsidian
↓
Project VX Planning
↓
Planning Sync
↓
루미
↓
Development Plan
Development Workflow
Development Plan
↓
루미
↓
Codex
↓
Unity
↓
Verification
↓
Git/GitHub
기획 변경을 발견했다고 그 자리에서 바로 프로젝트를 수정하게 만들면 Planning과 Implementation의 경계가 흐려질 수 있기 때문에 두 과정을 분리하였다.
최종적으로 만들고 싶은 개발 시작 과정
이번 작업을 통해 내가 최종적으로 만들고 싶은 Project VX의 개발 시작 과정도 어느 정도 정리되었다.
앞으로는 매번 루미에게
오늘은 플레이어 시스템 만들자.
이동 방식은 이렇고 공격 방식은 이렇고…
처럼 모든 내용을 직접 설명하는 것이 아니라, 단순히
Project VX 개발 시작해줘.
라고 요청하는 것에 가까운 형태를 목표로 하고 있다.
그러면 루미가 먼저 다음 과정을 수행한다.
- Project VX Planning 변경 여부 확인
- 변경이 존재한다면 최신 기획 분석
- Development Plan과 현재 기획 동기화
- 현재 Milestone과 Task 확인
- 개발해야 할 작업 선정
- 필요한 작업을 Codex에 분배
- Unity에서 구현 및 검증
- 결과를 Git/GitHub에 반영
- Development Plan 갱신
- 최종 결과를 나에게 보고
이전까지는
ゆならん → 루미 → Codex → Unity
라는 구조였다면,
이번 작업 이후에는 조금 더 다음과 같은 형태에 가까워졌다.
| ㅤ | Obsidian | ㅤ |
|---|---|---|
| ㅤ | Project VX Planning | ㅤ |
| ㅤ | ↓ | ㅤ |
| ゆならん | → 루미 | ← Development Plan |
| ㅤ | ↓ | ㅤ |
| ㅤ | Codex | ㅤ |
| ㅤ | ↓ | ㅤ |
| ㅤ | Unity | ㅤ |
| ㅤ | ↓ | ㅤ |
| ㅤ | Verification | ㅤ |
| ㅤ | ↓ | ㅤ |
| ㅤ | Git/GitHub | ㅤ |
루미에게 단순히 개발 명령을 전달하는 것뿐만 아니라,
“Project VX가 어떤 게임이어야 하는지”와 “현재 어디까지 개발되어 있는지”를 함께 제공할 수 있는 구조가 만들어진 셈이다.
결론
처음에는 단순히
루미가 Obsidian 파일을 읽을 수 있으면 편하지 않을까?
정도에서 시작했다.
하지만 실제로 연결하고 나니 단순히 문서를 읽을 수 있는 것만으로는 부족했다.
Project VX의 기획 원본과 현재 개발 상태를 구분해야 했고, 기획이 변경되었을 때 Development Plan을 어떻게 동기화할지도 정해야 했다.
또한 매번 거대한 기획 문서를 다시 읽는 것을 피하기 위해 변경 여부를 먼저 확인하는 과정도 필요했다.
결과적으로 이번 작업에서는 다음 구조를 만들었다.
Obsidian
↓
Project VX Planning
↓
Planning Sync
↓
루미
↓
Development Plan
이를 통해 Obsidian을 단순한 기획 노트가 아니라 Project VX 개발 Workflow의 일부로 사용할 수 있게 되었다.
다만 아직 한 가지 중요한 것은 확인하지 않았다. 루미가 이 기획과 Development Plan을 실제 게임 개발에 제대로 활용할 수 있는가?
지금까지 확인한 것은 어디까지나
- Obsidian 접근
- 문서 읽기 및 수정
- Planning 문서와 Development Plan의 역할 분리
- 기획 변경을 반영하기 위한 Planning Workflow
까지다.
실제로 Project VX의 기획을 읽고, 루미가 개발 작업을 판단하고, Codex에게 구현을 맡기고, Unity에서 하나의 게임을 만들어낼 수 있는지는 아직 테스트하지 않았다.
따라서 다음에는 이번에 구성한 Obsidian 기반 Planning Workflow를 실제 개발에 사용하여, Project VX의 기획 문서를 기반으로 게임 하나를 직접 개발시켜볼 예정이다.
한국어 본문은 준비 중입니다. 원문은 일본어로 읽을 수 있습니다.