Human-Governed Dual-Agent Development

GPT–Codex 기반 역할분리형 AI 협업 개발 방법론

1. 개요

본 방법론은 하나의 AI 에이전트에게 요구사항 분석, 설계, 구현, 테스트를 모두 맡기는 방식에서 발생할 수 있는 문제를 줄이기 위해 개발한 역할분리형 AI 협업 개발 방식이다.

기본 구조는 다음과 같다.

사용자(팀장 / 의사결정자)
↓
GPT (PM / PI / 설계·검토)
↕
Codex (개발 / 테스트)

단, GPT가 작성한 개발 지시가 Codex에게 자동으로 전달되는 구조는 아니다.

실제 구현 전에 사용자가 GPT의 작업지시서를 검토하고 필요하면 GPT와 다시 조율한 뒤 Codex에게 전달한다.

따라서 전체 구조는 다음과 같다.

요구사항
→ GPT 분석·설계
→ 작업지시서 작성
→ Human Review & Approval
→ Codex 구현·테스트
→ 결과보고서 작성
→ GPT 검토
→ 필요 시 재작업
→ 마일스톤 완료

핵심 목적은 AI를 많이 사용하는 것이 아니라 설계 오류는 구현 전에 제거하고, 구현 오류는 AI 간 상호검증을 통해 발견하며, 사람은 중요한 의사결정에 집중하도록 하는 것이다.

2. 도입 배경

초기에는 Codex 단독 개발 방식을 사용하였다.

단일 에이전트 방식은 초기 개발 속도가 매우 빠르고 간단한 작업에서는 효율적이었다.

그러나 프로젝트가 장기화되면서 몇 가지 문제가 발생하였다.

2.1 Context Drift

여러 번의 수정이 반복되면서 초기 요구사항과 프로젝트 전체 방향보다 현재 요청을 해결하는 데 집중하는 현상이 발생하였다.

그 결과 수정이 누적될수록 프로젝트 구조가 점차 복잡해졌다.

2.2 Scope Creep

명확한 마일스톤과 작업 범위가 없으면 현재 문제를 해결하는 과정에서 불필요한 영역까지 수정하는 경우가 발생하였다.

작은 변경이 예상보다 넓은 코드 변경으로 확대될 수 있었다.

2.3 Duplicate Implementation

기존에 구현된 모듈이나 함수를 재사용할 수 있음에도 새로운 클래스, 함수 또는 로직을 생성하는 경우가 발생하였다.

이는 결과적으로 코드 중복과 유지보수 비용 증가로 이어졌다.

2.4 Self-Validation Problem

단일 에이전트가

설계
→ 구현
→ 테스트
→ 결과 판단

까지 모두 수행하면 자신이 세운 가정을 자신이 다시 검증하는 구조가 된다.

문제가 발생할 경우 결국 사용자가 직접 코드와 로그를 추적하고 원인을 파악하여 AI에게 다시 수정 지시를 내려야 한다.

즉,

AI가 개발하고 사람이 AI를 감시하는 구조

가 된다.

3. 역할 분리

본 방법론에서는 AI의 역할을 의도적으로 분리한다.

3.1 Human — Team Lead / Decision Maker

사용자는 프로젝트의 최종 의사결정권자다.

주요 역할은 다음과 같다.

- 프로젝트 목표 결정
- 요구사항 및 우선순위 결정
- GPT가 작성한 개발지시 검토
- 중요한 설계 변경 승인
- 마일스톤 승인
- 최종 결과 승인

사용자는 가능하면 코드 구현 세부사항보다 방향과 의사결정에 집중한다.

3.2 GPT — PM / PI / Architect / Reviewer

GPT는 사용자와 개발 에이전트 사이의 관리 계층 역할을 수행한다.

주요 역할은 다음과 같다.

- 요구사항 분석
- 요구사항 구체화
- 기존 시스템 구조 분석
- 아키텍처 및 구현 방향 설계
- 작업 범위 정의
- 마일스톤 관리
- Codex 작업지시서 작성
- Codex 결과보고서 검토
- 요구사항과 구현 결과 대조
- 테스트 결과 검증
- 다음 작업 결정
- 중요 이슈 사용자에게 Escalation

즉 GPT는 직접 구현하는 개발자보다 프로젝트의 사고와 관리 계층에 가깝다.

3.3 Codex — Developer / Tester

Codex는 실행 계층을 담당한다.

주요 역할은 다음과 같다.

- 기존 코드베이스 분석
- 기존 모듈 탐색
- 코드 작성 및 수정
- 빌드 / 컴파일
- 테스트 실행
- 오류 수정
- 변경사항 정리
- 테스트 로그 생성
- 결과보고서 작성

중요한 원칙은 새로운 구현보다 기존 구현의 재사용을 우선하는 것이다.

새로운 모듈이나 구조가 필요하다고 판단되더라도 작업 범위를 크게 변경해야 한다면 임의로 구현하지 않고 GPT에게 이슈로 보고한다.

4. 핵심 개발 사이클

본 방법론의 기본 사이클은 다음과 같다.

Phase 1 — Requirement

사용자가 목표와 요구사항을 GPT에게 전달한다.

Phase 2 — Planning & Design

GPT가 요구사항을 분석한다.

필요한 경우 사용자와 질의응답을 통해 요구사항을 구체화하고 구현 방향을 설계한다.

Phase 3 — Pre-Implementation Review

GPT가 Codex용 작업지시서를 작성한다.

하지만 즉시 실행하지 않는다.

사용자가 작업지시서를 먼저 검토한다.

이 과정에서

- 요구사항 오해
- 불필요한 기능
- 과도한 설계
- 수정 범위 확대
- 기존 기능과의 충돌 가능성

등을 확인한다.

필요하면 사용자와 GPT가 다시 설계를 조정한다.

이 단계의 핵심 원칙은 다음과 같다.

코드를 수정하기 전에 설계를 수정하는 것이 훨씬 싸다.

Phase 4 — Implementation

승인된 작업지시서를 Codex에게 전달한다.

Codex는 지정된 범위 안에서 구현을 수행한다.

Phase 5 — Verification

Codex는 구현 완료 후

- 변경 파일
- 구현 내용
- 테스트 내용
- 테스트 결과
- 발견된 문제
- 계획과 다르게 처리한 사항

등을 결과보고서로 작성한다.

Phase 6 — Independent Review

Codex 결과보고서와 테스트 결과를 GPT가 다시 검토한다.

GPT는 단순히 "테스트 성공" 여부만 확인하지 않는다.

최초 요구사항
↔ 설계
↔ 실제 구현
↔ 테스트 결과

를 다시 대조한다.

Phase 7 — Feedback Loop

문제가 발견되면 GPT가 수정 작업지시서를 작성한다.

사용자가 이를 검토한 후 다시 Codex에게 전달한다.

따라서

GPT ↔ Codex

사이에 반복적인 Feedback Loop가 형성된다.

Phase 8 — Milestone Closure

완료 조건을 만족하면 해당 마일스톤을 종료하고 다음 단계로 진행한다.

5. Human-in-the-Loop Approval Gate

본 방법론에서 가장 중요한 특징 중 하나는 GPT와 Codex를 완전히 자동 연결하지 않는 것이다.

GPT가 작성한 개발 지시는 반드시 사용자 검토를 거친다.

구조적으로는 다음과 같다.

GPT Proposal
↓
Human Approval Gate
↓
Codex Execution

이를 통해 GPT의 잘못된 가정이나 과도한 설계가 실제 코드 변경으로 이어지기 전에 차단할 수 있다.

즉 사람의 검토 위치를

코드 작성 이후

에서

코드 작성 이전

으로 이동시킨다.

이는 불필요한 코드 수정과 재작업을 줄이는 중요한 장치다.

6. Mutual Verification

본 방법론에서는 GPT와 Codex가 단순한 상하관계가 아니라 서로 다른 관점에서 상호검증한다.

GPT → Codex

GPT는

- 요구사항
- 설계
- 작업범위
- 제약조건
- 테스트 조건
- 완료조건

을 정의한다.

Codex → GPT

Codex는 실제 코드베이스와 실행환경을 기반으로

- 기존 설계의 구현 가능성
- 기존 모듈과의 충돌
- 예상하지 못한 의존성
- 테스트 실패
- 기존 구조 재사용 가능성

등을 피드백한다.

따라서 GPT의 설계가 현실과 맞지 않는 경우 Codex가 이를 발견할 수 있다.

반대로 Codex가 구현을 완료했다고 판단하더라도 GPT가 최초 요구사항과 비교하여 누락사항을 발견할 수 있다.

즉,

설계는 구현으로 검증되고
구현은 설계와 요구사항으로 검증된다.

7. Evidence-Based Verification

AI끼리 서로 동의했다고 해서 구현이 올바르다고 판단하지 않는다.

검증은 가능한 한 실행 가능한 증거를 기반으로 한다.

예를 들어

- 컴파일 결과
- 테스트 결과
- 실행 로그
- DB 조회 결과
- 예상값과 실제값 비교

등을 사용한다.

따라서 검증 구조는

Codex가 성공했다고 주장
→ GPT가 동의
→ 완료

가 아니라,

Codex 구현
→ 테스트 증거 제출
→ GPT가 요구사항과 증거 대조
→ 완료 판정

을 기본으로 한다.

8. Documentation as Development Memory

GPT와 Codex 사이에서 생성되는 문서는 단순한 임시 프롬프트가 아니다.

이 문서들은 프로젝트의 Decision Log 및 Development Memory 역할을 한다.

대표적으로 다음 자료가 남는다.

GPT 작업지시서

- 왜 이 작업을 수행하는가
- 무엇을 수정해야 하는가
- 무엇을 수정하면 안 되는가
- 기존 구조를 어떻게 활용하는가
- 완료 조건은 무엇인가

Codex 결과보고서

- 실제 무엇을 수정했는가
- 어떤 문제가 발생했는가
- 어떤 방식으로 해결했는가
- 어떤 테스트를 수행했는가
- 테스트 결과는 무엇인가

GPT 검토 결과

- 요구사항 충족 여부
- 발견된 문제
- 추가 수정 필요 여부
- 다음 마일스톤

이를 Git과 결합하면 다음과 같은 기록 구조가 만들어진다.

Git
= What changed

GPT 작업지시서
= Why / What / Constraints

Codex 결과보고서
= How / Evidence

GPT Review
= Verification / Decision

따라서 시간이 지난 뒤에도

"이 코드를 왜 이렇게 만들었는가?"

라는 질문에 당시의 의사결정 과정까지 복원할 수 있다.

9. Direct Command Exception

원칙적으로 Codex에 대한 개발 업무 지시는 GPT를 통해 이루어진다.

Human → GPT → Codex

그러나 단순 확인, 로그 출력, 작은 테스트 등 경미한 작업은 사용자가 Codex에게 직접 요청할 수 있다.

이 경우 결과보고서에

작업지시 출처: 사용자 직접 지시

임을 명시한다.

이 결과를 다시 GPT에게 전달하여 프로젝트 상태를 동기화한다.

즉,

Human Direct Command
→ Codex
→ Result Documentation
→ GPT Synchronization

구조를 사용한다.

이를 통해 빠른 직접 작업을 허용하면서도 GPT가 모르는 상태 변경이 발생하는 것을 방지한다.

10. 단일 에이전트 방식과의 차이

단일 에이전트 방식은 구조가 단순하다.

Human → AI → Implementation

빠르고 관리가 편하지만 문제가 발생하면 사용자가 직접 원인을 추적해야 한다.

본 방법론은 다음과 같다.

Human
→ GPT Planning
→ Human Approval
→ Codex Implementation
→ Codex Testing
→ GPT Verification
→ Human Decision

따라서 사용자가 직접 수행해야 하는 AI 감독 업무의 상당 부분을 GPT와 Codex 사이의 상호검증 과정으로 이전한다.

11. 장점

본 방식의 주요 장점은 다음과 같다.

- 구현 전 요구사항 오류 발견
- 불필요한 코드 수정 감소
- 기존 모듈 재사용 증가
- 중복 구현 억제
- Scope Creep 방지
- 명확한 마일스톤 관리
- 설계와 구현 역할 분리
- AI 간 상호검증
- 테스트 기반 검증
- 작업 이력 자동 축적
- 과거 의사결정 복원 가능
- 사용자의 코드 수준 관리 부담 감소

결국 사람의 역할을

AI가 작성한 코드를 계속 감시하는 사람

에서

AI 개발팀의 방향과 중요한 결정을 관리하는 사람

으로 이동시키는 것이 목적이다.

12. 한계

본 방식 역시 완벽하지 않다.

GPT와 Codex가 동일한 잘못된 가정을 공유할 가능성이 있으며 AI 간 상호검증이 인간의 최종 검증을 완전히 대체할 수는 없다.

또한 매우 작은 작업에서는 작업지시서와 검토 과정 자체가 오버헤드가 될 수 있다.

따라서 간단하고 위험도가 낮은 작업은 Codex 직접 작업을 허용하고, 프로젝트 구조에 영향을 주는 개발은 정식 프로세스를 사용하는 것이 효율적이다.

13. 핵심 원칙

본 방법론은 다음 원칙으로 요약할 수 있다.

1. 사람은 방향을 결정한다.

2. GPT는 요구사항을 실행 가능한 계획으로 만든다.

3. 구현 전에 사람이 계획을 검토한다.

4. Codex는 승인된 범위 안에서 구현하고 테스트한다.

5. 기존 구현을 우선 재사용하고 불필요한 신규 구현을 억제한다.

6. Codex의 결과는 GPT가 다시 요구사항과 대조한다.

7. AI의 주장보다 테스트와 실행 결과를 신뢰한다.

8. 중요한 결정만 사용자에게 Escalation한다.

9. 모든 주요 작업의 이유와 결과를 문서로 남긴다.

10. AI의 수를 늘리는 것보다 명확한 책임과 의사결정 구조를 유지한다.

14. 결론

이 방법론의 핵심은 AI 모델을 여러 개 사용하는 데 있지 않다.

핵심은 역할 분리, 사전 검토, 상호검증, 증거 기반 테스트, 마일스톤 관리 및 의사결정 기록이다.

단일 AI 개발 방식이

"AI에게 개발을 맡기고 사람이 결과를 감시하는 방식"

이라면,

본 방식은

"사람이 방향을 통제하고, GPT가 개발 프로세스를 관리하며, Codex가 구현과 테스트를 수행하고, 두 AI가 서로의 결과를 검증하는 방식"

이라고 정의할 수 있다.

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

«설계 오류는 코드가 되기 전에 제거하고,
구현 오류는 팀장에게 올라오기 전에 발견한다.»

그리고 조직 운영 관점에서는 다음 한 문장으로 요약할 수 있다.

«나는 GPT를 관리하고, GPT는 프로젝트를 관리하며, Codex는 코드와 테스트 결과로 증명한다.»