[VX] 08. Codex 사용량 소진에 대비한 Antigravity Failover 시도

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

이전 작업에서는 LAST SIGNAL의 M2 Combat과 M3 Enemy까지 개발을 진행하였다. 그 과정에서 Codex 작업의 Timeout이나 Rate Limit이 발생했을 때 이미 실행 중인 작업을 중복으로 요청하지 않도록 실행 상태 복구 관련 하네싱도 추가하였다.

하지만 Project VX를 계속 개발하면서 또 하나 신경 쓰이는 문제가 있었다.

바로 Codex 자체의 사용량 제한이었다.

일시적인 Rate Limit이라면 잠시 기다린 뒤 기존 작업을 계속 진행하면 된다. 하지만 Codex 계정 또는 Plan의 사용량 자체를 모두 소진한 경우에는 이야기가 달라진다.

이 경우에는 해당 사용량이 복구될 때까지 Codex를 통한 개발 자체를 진행할 수 없거나, 매 번 추가 지출이 발생하게 된다. 그래서 처음에는 다음과 같은 구조를 만들어보려고 하였다.

평상시
루미
↓
Codex
↓
Unity

Codex 사용량 소진 시
루미
↓
Antigravity
↓
Unity

즉 Codex를 기본 개발 Agent로 유지하되, Codex의 사용량이 실제로 소진되었을 경우에만 Google Antigravity CLI를 대체 Agent로 사용하는 Failover 구조를 추가하려고 하였다.

결론부터 말하면, 이 기능은 최종적으로 사용하지 않기로 하였다. 하지만 실제로 연결하고 테스트하는 과정에서 Project VX의 Agent 교체 구조에 대해 생각해볼 부분이 꽤 많았기 때문에 해당 과정을 별도로 기록하기로 하였다.

Antigravity를 Failover Agent로 추가

우선 Antigravity CLI를 설치하고 루미가 실행할 수 있도록 설정하였다. 당시 사용한 Antigravity CLI 버전은 1.1.17이었다.

그리고 AGENTS.md에는 Codex를 Antigravity로 전환할 수 있는 Failover 규칙을 추가하였다.

다만 아무 오류가 발생했다고 Antigravity로 전환하도록 만들지는 않았다. 예를 들어 다음 문제들은 Failover 조건에서 제외하였다.

• 일반적인 Timeout
• 일시적인 연결 실패
• Test 실패
• Compile 실패
• 일시적인 Rate Limit

이런 문제들은 Codex 자체의 사용 가능 여부와 관계없는 경우가 많기 때문이다. 따라서 Failover가 발생할 수 있는 조건은 Codex 계정 또는 Plan의 사용량 한도 초과가 명시적으로 확인되었을 때로 제한하였다.

설정을 추가한 뒤 루미에게 Project 파일을 수정하지 않은 상태에서 실제 설정이 적용되었는지 확인하도록 요청하였다.

ゆならん: Antigravity CLI failover 설정이 적용됐는지 확인해줘. 프로젝트는 수정하지 말고, agy 실행 가능 여부와 현재 AGENTS.md의 failover 규칙만 확인해줘.

루미는 다음 항목들을 확인하였다.

• AGENTS.md에 Failover 규칙 존재
• 발동 조건은 명시적인 Codex 사용량 한도 초과
• 일반 Timeout이나 연결 실패 등은 Failover 대상이 아님
• Antigravity 실행 파일 확인
• CLI Version 1.1.17
• agy --help 정상 실행

즉 최소한

Codex를 사용할 수 없을 때 호출할 수 있는 별도의 CLI

까지는 준비할 수 있었다.

하지만 이것만으로는 실제 Project VX 개발을 대신할 수 없다. Codex가 현재 Unity를 어떤 방식으로 제어하고 있는지도 Antigravity에서 재현해야 하기 때문이다.

Codex의 Unity MCP 설정 확인

Project VX에서 Codex는 단순히 C# 파일만 수정하는 것이 아니라 Unity와 연결하여 Scene과 GameObject를 확인하고 구현 결과를 검증한다.

따라서 Antigravity 역시 실제 대체 Agent로 사용하려면 Unity에 접근할 수 있어야 했다.

먼저 Codex가 사용하고 있는 Unity MCP 설정을 읽기 전용으로 확인하였다.

ゆならん: 현재 Project VX에서 Codex가 사용하는 Unity MCP 설정을 읽기 전용으로 확인해줘. MCP 서버의 이름, transport 방식, executable/command, args, env, cwd가 있다면 알려줘. 설정 파일이나 프로젝트는 수정하지 마.

확인 결과 Codex의 설정은 대략 다음과 같았다.

• MCP Server: unity
• Transport: stdio
• Command: unity
• 실제 실행 경로: /opt/homebrew/bin/unity
• Args: ["mcp"]
• 별도의 Environment 설정 없음
• 별도의 고정 Working Directory 없음

즉 내부적으로는 대략 unity mcp를 stdio 기반 MCP Server로 실행하는 구조였다.

별도의 Project 경로를 MCP 설정에 고정하지 않고, 현재 작업 Directory와 실행 중인 Unity Editor를 기준으로 Project를 찾는 형태였다. 따라서 Antigravity에서도 동일한 Unity MCP를 사용할 수 있도록 연결을 시도하였다.

Antigravity에서 Unity MCP 연결

Antigravity CLI를 Project VX Unity Directory에서 직접 실행하였다. 그 다음 agy를 실행하였다.

CLI 자체는 정상적으로 실행되었다. 당시 Antigravity에서는 Google AI Pro 계정을 사용하고 있었고, 모델은 Gemini 3.7 Flash (High)로 표시되었다.

그리고 Unity MCP Plugin 역시 정상적으로 인식되었다. 화면에서는 unity Plugin 아래에

• add_animator_layer
• add_animator_parameter
• add_animator_state
• add_animator_transition
• add_component

등 Unity 관련 Tool과 추가 Tool들이 등록된 것을 확인할 수 있었다.

즉 적어도

Antigravity
↓
Unity MCP

라는 연결 자체는 만들 수 있었다.

여기까지만 보면 자동 Failover 구조도 생각보다 쉽게 만들 수 있을 것처럼 보였다. 하지만 실제 문제는 그다음부터였다.

단순히 Agent 하나를 바꾸는 문제가 아니었다

처음 생각했던 Failover 구조는 매우 단순했다.

Codex 사용량 확인
↓
사용 가능 → Codex
사용 불가 → Antigravity

정도만 구현하면 될 것이라고 생각하였다. 하지만 실제로 연결해보니 Agent를 교체한다는 것은 단순히 실행할 CLI 이름 하나를 변경하는 문제가 아니었다. Project VX에서 Codex는 이미 다음과 같은 규칙과 상태를 공유하고 있다.

• AGENTS.md
• Project VX Planning
• Development Plan.md
• 현재 Milestone
• 현재까지 구현된 파일
• Unity Editor / Pipeline 상태
• Git 작업 권한
• 구현 검증 규칙
• 실행 상태 복구 규칙
• 기존 Codex Session

만약 개발 도중 Codex의 사용량이 소진되어 Antigravity로 전환된다면,

Codex가 어디까지 작업했는지 확인
↓
현재 Project 상태 확인
↓
현재 Milestone 및 Task 확인
↓
Antigravity에 동일한 규칙 전달
↓
Unity 연결 상태 재확인
↓
기존 구현을 중복하지 않도록 작업 재개
↓
Antigravity의 결과 검증
↓
이후 Codex 사용량 복구 시 다시 상태 동기화

까지 처리해야 한다. 즉 Project VX 입장에서는 새로운 Agent 하나를 추가하는 것이 아니라, 사실상 두 종류의 개발 Runtime 사이에서 상태를 유지하는 기능이 하나 더 생기는 것이었다.

같은 도구를 연결해도 같은 Agent가 되는 것은 아니다

Unity MCP를 연결하는 것까지는 가능했다. 하지만 Codex와 Antigravity는 동일한 Agent가 아니다.

각각의

• Context 처리 방식
• Tool 사용 방식
• Session 구조
• CLI 동작
• Headless 실행 방식
• 지침을 받아들이는 방식
• 오류 처리 방식

이 서로 다르다. 따라서 Codex에서 잘 작동하던 하네싱을 Antigravity에서도 그대로 사용할 수 있다고 가정하기 어려웠다. 특히 Project VX에서는 루미가 단순히

Unity 코드를 작성해줘.

라고 요청하는 것이 아니라,

현재 상태 확인
↓
현재 Milestone 판단
↓
기존 구현 보존
↓
필요한 Task만 구현
↓
Unity 검증
↓
Regression 확인
↓
Development Plan 갱신

과 같은 비교적 엄격한 개발 Workflow를 유지하고 있다. 따라서 Antigravity까지 안정적으로 지원하려면 기존 Codex용 규칙을 단순히 복사하는 수준을 넘어 Antigravity의 특성에 맞는 별도의 하네싱과 검증 과정이 추가로 필요해졌다.

Headless Failover의 문제

수동으로 Terminal에서 Antigravity를 실행하는 것과, 루미가 작업 도중 자동으로 Antigravity를 호출하는 것은 또 다른 문제였다.

수동 Interactive 환경에서는 사람이 현재 상태를 직접 보고 문제가 발생하면 바로 수정할 수 있다. 하지만 Failover의 목표는

Codex 사용량이 소진되면 루미가 알아서 Antigravity로 전환해 기존 작업을 이어서 진행

하는 것이었다.

그러려면 Antigravity를 Headless 형태로 안정적으로 실행하고,

• 명령 전달
• Context 전달
• MCP 연결
• 작업 결과 수집
• 오류 판별
• 현재 Task 완료 여부 판단

까지 자동화해야 한다. 이 단계부터는 단순한 Backup Agent 추가가 아니라 새로운 실행 Backend 하나를 Project VX에 추가하는 것에 가까워졌다. 그리고 Failover를 위한 예외 처리가 늘어날수록 오히려 루미의 Orchestration 구조가 복잡해졌다.

Failover를 포기하기로 결정

처음 Failover를 추가하려 했던 이유는 단순했다.

Codex 사용량을 모두 사용하더라도 Project VX 개발을 계속하고 싶다.

하지만 실제로 구현을 검토해보니 얻을 수 있는 이점보다 추가해야 할 복잡성이 상당히 컸다.

자동 Failover를 제대로 유지하려면 최소한

• Codex 사용량 상태 판별
• Codex 작업 중단 지점 확인
• Antigravity Session 생성
• Context / Rule 동기화
• Unity MCP 상태 확인
• 구현 상태 재검증
• Agent별 차이 처리
• Antigravity 오류 복구
• Codex 복귀 시 다시 상태 동기화

등을 별도로 관리해야 한다.

이는 현재 Project VX의 핵심 목적인

루미가 Project 전체 상태를 관리하고 Codex가 실제 구현을 담당하는 단순한 역할 분리

를 오히려 복잡하게 만들 가능성이 있었다.

특히 Failover는 평상시에는 거의 사용하지 않지만, 실제로 필요한 순간에는 기존 Agent를 사용할 수 없는 비정상 상황이다. 즉 가장 안정적으로 작동해야 하는 기능이면서 동시에 평소에는 테스트하기 가장 어려운 기능이 되는 셈이다.

결국 현재 단계에서는 이 정도의 복잡성을 추가할 이유가 크지 않다고 판단하였다. 따라서 Antigravity 자동 Failover 기능은 사용하지 않기로 하였다.

최종 구조

결국 Project VX의 기본 개발 구조는 이전과 동일하게 유지하기로 하였다.

ゆならん
↓
루미
↓
Codex
↓
Unity

Codex는 계속 Project VX의 기본 구현 Agent로 사용한다.

Antigravity가 기술적으로 Unity에 접근할 수 있다는 점은 확인했지만, 이를 Codex의 자동 대체재로 넣지는 않는다. 필요하다면 Antigravity를 별개의 수동 도구로 사용할 수는 있지만, Project VX의 기본 Workflow에는 포함하지 않기로 하였다.

결과적으로 몇 시간 동안

CLI 설치
↓
Failover 규칙 작성
↓
Codex Unity 설정 분석
↓
Unity MCP 연결
↓
자동 전환 구조 검토
↓
사용하지 않기로 결정

이라는 과정을 거쳤다. 시간만 놓고 보면 상당한 시간이 소요되었다. 다만 이번 시도를 통해 한 가지는 확실히 알 수 있었다.

Agent를 추가한다고 항상 Harness가 좋아지는 것은 아니다

Project VX를 만들면서 지금까지는 필요한 기능을 계속 추가하는 방향으로 하네싱을 발전시켜왔다.

• Model Routing
• Git 권한 분리
• Planning Sync
• Development Plan
• 실행 상태 복구
• Regression Test

등이 대표적이다.

하지만 이번에는 처음으로

구현 자체는 가능하지만 넣지 않는 편이 낫다.

는 결론을 내렸다.

Agent가 하나 더 있으면 언뜻 더 강력한 구조처럼 보일 수 있다. 하지만 Agent가 늘어날수록

• 상태 동기화
• Context 관리
• Tool 차이
• 오류 처리
• 검증 방법
• 작업 Ownership

역시 함께 늘어난다.

따라서 중요한 것은 연결 가능한 Agent의 숫자가 아니라,

현재 구조에서 실제로 안정적으로 관리할 수 있는 Agent가 몇 개인가

라고 생각하게 되었다.

특히 현재 Project VX에서 Codex는 이미 Unity와의 연결, 구현 Workflow, Session 복구, Git 권한 등의 규칙이 상당 부분 안정화되어 있다. 이 상황에서 드물게 발생할 사용량 소진을 대비하기 위해 동일한 수준의 하네싱을 Antigravity에도 하나 더 만드는 것은 현재 단계에서는 과도한 복잡성이라고 판단하였다.

결론

이번에는 Codex의 사용량 소진에 대비하여 Google Antigravity CLI를 Project VX의 Failover Agent로 추가해보려고 하였다.

CLI 실행과 Unity MCP 연결 자체는 가능했다. 따라서 기술적으로

루미 → Antigravity → Unity

라는 경로를 만드는 것 자체가 불가능한 것은 아니었다.

하지만 Project VX에서 필요한 것은 단순히 Unity Tool을 사용할 수 있는 Agent가 아니다. 기존 Codex가 가지고 있던

• 개발 상태
• Milestone
• Context
• 작업 범위
• 검증 결과
• Session
• Recovery 상태

를 다른 Agent로 안전하게 넘겨서 중복이나 상태 손실 없이 같은 개발을 계속할 수 있어야 한다.

이를 위해 필요한 추가 하네싱과 예외 처리를 고려했을 때, 현재 Project VX 규모에서는 자동 Failover가 가져오는 이점보다 구조적 복잡성이 더 크다고 판단하였다. 따라서 이번 기능은 최종적으로 채택하지 않았다.

Project VX는 당분간 기존의

루미 → Codex → Unity

구조를 유지할 예정이다.

개인적으로 생각하기에, 이번 테스트는 기능 하나가 추가된 것이 아니라, 추가하지 않을 기능 하나를 결정한 테스트에 가까웠다는 생각이 든다.

다음에는 다시 LAST SIGNAL의 #Test 2의 M4 개발로 돌아갈 예정이다.