ChatGPT를 Planner로, Codex를 Executor로 사용하여 개발 루프를 돌리기

서론

저는 현재 Unity 상에서 AI가 자율적으로 동작하고 발화하는 3D 아바타를 개인 개발하고 있습니다.

이 개발에서는 ChatGPT에게 대략적인 요구사항을 전달하면, ChatGPT가 구현 계획을 세우고, 그 계획을 Codex에 전달하여 구현과 테스트를 수행하는 방법을 채택하고 있습니다.

단순히 "AI에게 코드를 작성하게 하는 것"이 아닙니다.

인간이 목적을 전달
↓
ChatGPT가 구현 계획을 작성
...

본 기사에서는 이 개발 방법을 채택한 이유와, 개발 루프를 제어하는 Python 스크립트의 구조를 소개합니다.

왜 이 방법을 선택했는가

AI 코딩 환경에는 Codex 외에도 Anthropic의 Claude Code 등 유력한 선택지가 있습니다. 기능이나 모델 성능만 비교한다면, 용도에 따라 다른 서비스가 더 적합할 수도 있다고 생각합니다.

그럼에도 이번에 ChatGPT와 Codex를 선택한 가장 큰 이유는 개인 개발 비용을 예측하기 쉽기 때문입니다.

저의 구성에서는 ChatGPT와 Codex 사이를 API로 직접 연결하지 않습니다. ChatGPT Plus 상에서 계획을 세우고, Markdown 파일을 매개로 로컬의 Codex에 전달합니다.

ChatGPT Plus에 포함된 이용 범위 내라면, OpenAI API를 호출할 때마다 발생하는 종량제 토큰 요금을 추가로 지불하지 않고도 개발 루프를 돌릴 수 있습니다.

API로 완전 자동화할 경우
Planner API → 토큰 과금
Executor API → 토큰 과금
...

이번 방법
ChatGPT Plus → 계획 작성
Markdown → 계획 전달
...

물론 "완전 무료"라는 의미는 아닙니다. ChatGPT Plus의 월간 요금은 필요하며, 이용 상한도 있습니다. OpenAI API나 외부 리뷰 API를 추가하면 별도의 요금이 발생합니다. 요금이나 제공 조건도 향후 변경될 가능성이 있습니다.

정확하게는, Plus의 이용 범위 내라면 추가적인 종량제 API 요금을 가급적 발생시키지 않고 운용할 수 있다는 점을 장점으로 파악하고 있습니다.

역할을 나누기

이 방법에서는 인간, ChatGPT, Codex, 자동 평가에 서로 다른 역할을 부여합니다.

담당	역할
인간	목적, 우선순위, 외관의 품질을 판단한다
...

인간이 구현 방법을 한 줄씩 지정하는 것이 아니라, 최종적으로 실현하고 싶은 상태를 전달합니다.

예를 들어, 아바타 개발에서는 다음과 같은 요구사항이 있습니다.

여러 제스처가 지정된 순서대로 실행되었음을 자동 테스트로 확인할 수 있게 하고 싶다.

ChatGPT는 현재의 구현 상황이나 직전의 테스트 결과 등을 바탕으로, 이 요구사항을 Codex가 실행할 수 있는 단위로 분해합니다.

last_plan.md를 작업 지시서로 사용하기

ChatGPT가 만든 계획은 last_plan.md라는 Markdown 파일에 저장합니다.

실제로는 다음과 같은 구조입니다.

## Task Title
복합 제스처 시퀀스의 자동 평가를 추가한다
## Why This Task
...

이것은 단순한 프롬프트가 아니라, AI를 위한 작은 작업 지시서입니다.

특히 중요한 점은 다음과 같습니다.

• 무엇을 실현할 것인가
• 왜 지금 그것을 수행하는가
• 변경 예정인 파일
• 유지해야 할 기존 동작
• 완료를 판단하는 테스트
• 작업을 중단하는 조건

구현 방법을 너무 세세하게 고정하지 않고, 변경 범위와 완료 조건을 명확히 합니다. 이를 통해 Codex의 조사·구현 능력을 활용하면서도, 의도하지 않은 대규모 변경을 억제할 수 있습니다.

run_loop.py는 무엇을 하고 있는가

이 개발 루프의 중심에 있는 것이 직접 제작한 run_loop.py입니다.

이 스크립트는 단순히 Codex를 실행하는 것만이 아닙니다. Planner, Executor, 테스트, Reviewer, Git 사이를 잇는 오케스트레이터(Orchestrator)로서 동작합니다.

프로젝트 고유의 정보를 제외하고 요약하면, 다음과 같은 처리를 수행합니다.

• Git 상태나 이전 평가 결과로부터 Planner용 자료를 생성한다

• last_plan.md

• last_plan.md의 필수 항목을 검증한다 - 계획을 Codex용 프롬프트로 변환한다

• Codex를 로컬 리포지토리 (Local Repository) 상에서 실행한다

• 실행 전후의 Git 워크트리 (Git Worktree)를 비교한다

• 예정된 파일과 실제로 변경된 파일을 대조한다

• Python 테스트와 Unity 테스트를 실행한다

• Unity의 변경 전과 변경 후를 동일한 시나리오로 평가한다

• 평가 결과를 Reviewer용 입력으로 정리한다

• 커밋 (Commit), 롤백 (Rollback), 수동 확인 중 무엇을 진행할지 판정한다

• 필요에 따라 다음 계획 후보를 생성한다

• 동일한 실패가 반복될 경우 루프를 정지한다

처리 이미지를 의사 코드 (Pseudo-code)로 나타내면 다음과 같습니다.

def run_loop():
policy = load_policy()
if baseline_first:
...

실제 코드는 3,000행을 넘지만, 기사에서는 내부의 평가 임계값(Threshold)이나 프로젝트 고유의 규칙을 공개하지 않고, 책임(Responsibility)을 알 수 있는 수준으로 추상화하였습니다.

Codex는 어떻게 호출하고 있는가

run_loop.py는 계획을 템플릿에 채워 넣은 후, 표준 입력 (Standard Input)을 통해 Codex로 전달합니다.

개념적으로는 다음과 같은 커맨드 (Command)입니다.

codex exec --cd <PROJECT_ROOT> --sandbox <SANDBOX_MODE> --json -

Python에서는 subprocess.run()을 사용하여 종료 코드 (Exit Code), 표준 출력 (Standard Output), 표준 에러 (Standard Error)를 회수합니다.

proc = subprocess.run(
command,
input=codex_prompt,
...

Codex의 종료 코드뿐만 아니라, 컴파일러 에러나 예외를 나타내는 출력도 확인합니다. AI가 마지막에 "완료했습니다"라고 답변하더라도, 기계적인 검증 결과를 우선합니다.

변경 예정 파일과 실제 차분을 대조한다

AI에게 리포지토리를 변경하게 할 때, 테스트 성공만큼 중요한 것이 변경 범위의 감시입니다.

루프 실행 전후로 Git 워크트리 (Git Worktree)의 상태와 파일 해시 (File Hash)를 취득하여 차분을 비교합니다.

last_plan.md에서 지정한 파일
├─ 실제로 변경됨 → expected
├─ 변경되지 않음 → missing
...

지정 외의 파일이 변경된 경우, 내용이 올바르게 보이더라도 자동 승인하지 않습니다. Unity가 자동 생성하는 일부 파일 등은 명시된 정책 (Policy)에 따라 별도로 취급합니다.

이 메커니즘을 통해 "테스트를 통과하기 위해 AI가 예상치 못한 곳까지 변경했다"는 문제를 검출할 수 있습니다.

baseline과 candidate를 비교한다

Unity 아바타와 같이 실행 시 동작을 가진 소프트웨어에서는 컴파일 성공만으로는 품질을 판단할 수 없습니다.

따라서 변경 전을 baseline, 변경 후를 candidate로 하여 동일한 시나리오를 실행합니다.

python .\orchestrator\run_loop.py --run-unity-eval --baseline-first

평가 대상에는 예를 들어 다음과 같은 정보가 포함됩니다.

• 의도한 액션 (Action)이 실행된 비율
• 동일한 동작의 과도한 반복
• 동작의 실패 이유
• 이동이나 회전의 이상
• 긴급 정지 발생
• 변경 전후의 평가 차이

결과는 JSON과 Markdown으로 저장하며, accept, review 등의 판정 재료로 사용합니다.

수치 평가가 좋아도 인간이 보기에 동작이 부자연스러운 경우가 있습니다. 따라서 최종적인 외관 확인은 인간이 담당합니다.

자동화에 정지 조건을 넣는다

AI에 의한 개선 루프는 횟수를 늘린다고 해서 반드시 좋아지는 것은 아닙니다. 동일한 문제에 대해 유사한 수정을 반복하기도 합니다.

따라서 다음과 같은 경우에는 자동으로 정지합니다.

• 동일한 실패 이유가 연속됨
• 변경 없는 실행이 연속됨
• 수동 리뷰가 필요한 상태에서 개선되지 않음
• 최대 반복 횟수에 도달함
• 필수 테스트가 실패함
• 계획에 필요한 섹션이 없음

정지는 실패가 아니라, 인간에게 판단을 돌려주기 위한 안전 장치입니다.

또한, 보호 대상 브랜치 (Branch)에서는 자동 커밋이나 자동 롤백을 수행하지 않도록 하고 있습니다. 자동화의 범위를 브랜치와 정책에 따라 변경할 수 있는 설계입니다.

실제로 일어난 실패

이 메커니즘이 처음부터 깔끔하게 작동한 것은 아닙니다.

개발 중에는 다음과 같은 문제가 있었습니다.

• Unity 시나리오가 타임아웃됨
• Unity의 컴파일 에러 (Compile Error)를 정상 종료로 처리할 뻔함
• 예정하지 않은 보조 파일이 변경됨
• 자동 평가 스코어는 높지만, 실제 기기에서는 보행으로 전이되지 않음
• 시선 제어와 다른 컴포넌트 (Component)가 충돌함
• 동일한 실패에 대한 수정이 반복됨

이러한 문제들을 바탕으로 컴파일러 출력 (Compiler Output) 분석, 변경 파일 대조, 변경 전후 비교, 반복 정지 조건 등을 추가했습니다.

중요했던 점은, 실패를 인간만이 읽는 로그로 끝내지 않고, 다음 계획에 재사용할 수 있는 구조화된 데이터 (Structured Data)로 남기는 것이었습니다.

완전 자동화를 하지 않는 것에도 의미가 있다

현시점에서는 ChatGPT가 만든 계획을 인간이 확인하고, last_plan.md로 넘기는 공정을 남겨두고 있습니다.

API로 연결하면 계획 생성부터 구현까지 완전 자동화할 수 있습니다. 하지만 수동으로 전달하는 방식에는 다음과 같은 장점이 있습니다.

• 추가적인 API 이용료를 억제할 수 있음
• 구현 전에 계획과 변경 범위를 확인할 수 있음
• 대규모 변경을 중단시킬 수 있음
• 인간이 목적을 수정할 타이밍을 가질 수 있음
• AI끼리 잘못된 전제를 계속 강화하는 것을 방지할 수 있음

목표는 인간을 루프 (Loop)에서 완전히 배제하는 것이 아니라, 인간이 코드의 세부 사항이 아닌 목적과 품질 판단에 집중할 수 있는 상태를 만드는 것입니다.

이 방법이 적합한 케이스

이 방식은 다음과 같은 개인 개발이나 검증 프로젝트와 궁합이 좋다고 생각합니다.

• ChatGPT Plus와 Codex를 이미 이용하고 있다
• API 종량제 과금을 억제하고 싶다
• 로컬 (Local)에서 자동 테스트를 실행할 수 있다
• 한 번의 변경을 작게 분할할 수 있다
• AI의 변경 범위를 Git으로 감시하고 싶다
• 최종 품질에 인간의 육안 확인이 필요하다

반면, 대량의 태스크를 무인으로 상시 처리하고 싶거나, 여러 명이 승인 플로우 (Approval Flow)를 운용하는 경우에는 API, CI/CD, 전용 에이전트 (Agent) 기반을 사용하는 것이 더 적합할 가능성이 있습니다.

요약

이 개발 방법에서 중시하는 것은 뛰어난 프롬프트 (Prompt)를 단 한 번 만드는 것이 아닙니다.

요구사항
→ 계획
→ 구현
...

이 순환을 실패 시의 정지 조건과 Git을 통한 변경 관리를 포함하여 재현 가능하게 만드는 것입니다.

ChatGPT를 Planner, Codex를 Executor로 역할 분담하고, Markdown을 경계로 삼음으로써 추가적인 종량제 API 비용을 억제하면서도 개인으로서 지속 가능한 AI 개발 루프를 구축할 수 있었습니다.

향후에는 Reviewer의 정밀도 향상, 계획 후보의 안전한 자동 승격, Unity 상의 외관을 평가하는 메커니즘을 개선해 나갈 예정입니다.

Discussion