최근 Codex로 개발하면서 작업 방식을 계속 바꿔보고 있습니다.
처음에는 한 채팅에서
구현 → 테스트 → 자체 리뷰 → 수정 → 다시 테스트 → PR
까지 전부 처리하게 했습니다.
그런데 작업이 길어질수록 문제가 생겼습니다.
코드 탐색 내용, 테스트 로그, 오류 로그, 수정 내역이 계속 쌓이면서 채팅 컨텍스트가 너무 무거워졌습니다.
특히 몇 시간씩 이어지는 작업에서는 초반보다 Codex가 둔해지는 느낌도 있었습니다.
그래서 최근에는 작업 단계가 길어지면 아예 새 채팅을 만들어 필요한 현재 상태만 다시 읽게 하는 방식을 사용하고 있었습니다.
그러던 중 계속 눈에 들어오던 기능이 있었습니다.
바로 Subagent, 서브에이전트입니다.
처음에는 저도 개념이 조금 애매했습니다.
에이전트를 여러 개 띄우는 건 알겠는데
그래서 실제 개발에서는 어디에 쓰는 거지?
이번에 실제 개발 사례까지 찾아보면서 이 개념이 꽤 명확해졌습니다.
결론부터 이야기하면,
서브에이전트는 여러 AI에게 무작정 코드를 동시에 작성시키는 기능이 아니었습니다.
복잡한 개발 작업을 역할별로 분리하고, 메인 에이전트는 판단과 조율에 집중하게 만드는 방식에 더 가깝습니다.
1. Codex 서브에이전트란?
일반적으로 Codex에게 작업 하나를 요청하면 하나의 에이전트가 모든 일을 수행합니다.
Main Agent
코드 탐색
↓
설계
↓
구현
↓
테스트
↓
로그 분석
↓
리뷰
↓
수정작은 작업이라면 이 방식이 가장 단순하고 효율적입니다.
문제는 작업 규모가 커졌을 때입니다.
예를 들어 인증 기능 하나를 수정한다고 해보겠습니다.
메인 에이전트가 확인해야 할 것이 많습니다.
Controller
Service
DB
Migration
Security
Session
Frontend
기존 Test
Regression여기에 테스트까지 돌리면 수백 줄, 수천 줄의 로그가 컨텍스트에 들어옵니다.
서브에이전트를 사용하면 이를 나눌 수 있습니다.
Main Agent
Orchestrator
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Explorer Reviewer Test Analyzer
코드 탐색 위험 분석 테스트 분석
│ │ │
└──────────────┼──────────────┘
↓
결과만 요약
↓
Main Agent각 서브에이전트는 독립된 Agent Thread에서 작업하고, 필요한 결과만 메인 에이전트에게 전달합니다.
OpenAI 공식 문서에서는 이렇게 메인 대화에 탐색 기록, 테스트 로그, stack trace 같은 중간 결과가 계속 쌓이는 문제를 Context Pollution, 시간이 갈수록 관련성이 낮은 정보가 늘어 성능이 떨어지는 현상을 Context Rot이라고 설명합니다.
제가 기존 Codex 작업에서 느꼈던 문제가 정확히 이 부분이었습니다.
2. 그렇다면 실제 개발에서는 어떻게 사용할까?
여기서부터가 가장 궁금했습니다.
실제로 사용되는 사례를 찾아보니 몇 가지 패턴이 반복해서 나타났습니다.
3. 실제 사례 1 - 여러 관점으로 PR을 동시에 리뷰한다
가장 이해하기 쉬운 활용법입니다.
PR 하나를 리뷰한다고 해보겠습니다.
기존에는 Reviewer 하나에게 이렇게 요청할 수 있습니다.
이 PR을 리뷰해.
버그, 보안 문제, 테스트 누락까지 모두 찾아줘.서브에이전트를 사용하면 역할을 분리할 수 있습니다.
Main Agent
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Security Reviewer Test Reviewer Code Reviewer
│ │ │
└───────────────┼───────────────┘
↓
결과 통합프롬프트도 어렵지 않습니다.
현재 브랜치를 서브에이전트를 이용해 리뷰해.
Agent 1
보안 취약점과 인증/권한 문제를 검토한다.
Agent 2
누락된 테스트와 회귀 가능성을 검토한다.
Agent 3
코드 correctness와 유지보수성을 검토한다.
세 에이전트는 코드를 수정하지 않는다.
모두 완료될 때까지 기다린 뒤,
발견 사항을 심각도순으로 통합해서 보고한다.OpenAI 공식 문서에서도 거의 같은 형태로 Security / Test Gap / Maintainability를 각각 별도의 Agent에게 맡기는 PR 리뷰 예제를 제공하고 있습니다.
이 방식의 핵심은 단순한 병렬 처리보다 독립적인 시각에 있습니다.
한 Agent에게
구현도 네가 하고 리뷰도 네가 해.
라고 하는 것과,
A가 구현하고
B는 구현 과정을 모른 채 결과만 리뷰해.
라고 하는 것은 꽤 다릅니다.
후자가 처음 구현한 Agent의 판단에 덜 끌려갈 가능성이 있습니다.
4. 실제 사례 2 - OpenAI도 Agent가 Agent를 리뷰한다
흥미로운 사례가 OpenAI 내부 개발 방식입니다.
OpenAI가 공개한 Harness Engineering 사례를 보면 PR을 완료시키는 과정에서 Codex에게 자체 변경사항을 검토하게 한 뒤, 추가적인 전문 Agent Review를 요청하고 피드백을 다시 반영하는 반복 구조를 사용한다고 설명합니다.
대략 이런 흐름입니다.
Codex 구현
↓
자체 리뷰
↓
추가 Agent Review
↓
문제 발견
↓
수정
↓
다시 Agent Review
↓
PASS즉,
Worker
↓
Reviewer
↓
Worker
↓
Reviewer구조입니다.
특히 OpenAI는 시간이 지나면서 상당한 리뷰 작업을 Agent-to-Agent 방식으로 이동시켰다고 설명합니다.
이 사례를 보고 서브에이전트의 용도를 좀 더 명확하게 이해할 수 있었습니다.
사람 한 명을 AI 한 명으로 대체하는 것이 아니라, 개발팀 안에서 역할을 나누듯 Agent 역할도 나누는 것입니다.
5. 실제 사례 3 - 설계부터 구현, 테스트, 리뷰까지 역할을 나눈다
GitHub의 codex-workflows 프로젝트는 이 구조를 조금 더 적극적으로 사용합니다.
메인 Codex가 전체 흐름을 관리하고, 필요할 때 전문 Agent를 호출합니다.
예를 들어 다음과 같은 역할이 존재합니다.
requirement-analyzer
↓
codebase-analyzer
↓
technical-designer
↓
work-planner
↓
task-executor
↓
reviewer단순히
Agent A
Agent B
Agent C가 아니라 실제 개발팀처럼 역할을 구분한 것입니다.
이 프로젝트에서 공개한 실제 workflow 사례도 재미있었습니다.
BytePlus Seedream provider를 추가하는 작업에서
- 18개 파일 변경
- 8개의 계획된 작업
- 외부 API 연동
- Live Evaluation
- 최종 303개 테스트
를 수행했습니다.
그리고 독립된 리뷰 과정에서
- 제한 없는 파일 읽기
- Validation 우회
- Blocking FIFO 경로
- API Key 정규화 불일치
등의 문제가 발견되어 수정됐습니다.
여기서 제가 특히 눈여겨본 부분은 Agent 간 Context 전달 방법이었습니다.
긴 대화를 그대로 다음 Agent에게 넘기지 않습니다.
대신,
Requirement
Design Doc
Work Plan
Task File
Git Diff같은 저장소의 결과물을 읽게 합니다.
Agent A의 긴 대화 전체
↓
Agent B가 아니라
Agent A
↓
Design / Task Artifact
↓
Agent B형태입니다.
이 방식은 제가 기존에 사용하던 "새 Codex 채팅을 만들어 현재 상태만 다시 읽게 하는 방법"과도 비슷한 철학이라고 느꼈습니다.
6. 실제 사례 4 - 장애 원인 분석을 서로 다른 Agent가 검증한다
서브에이전트가 특히 잘 맞는 분야가 장애 분석입니다.
예를 들어 장애가 발생했을 때 하나의 Agent에게 이렇게 요청할 수도 있습니다.
장애 원인을 찾아서 해결해줘.문제는 Agent가 초반에 잘못된 가설을 잡으면 계속 그 가설을 기준으로 분석할 가능성이 있다는 것입니다.
그래서 역할을 이렇게 나눌 수 있습니다.
Main
│
┌─────────┼─────────┐
↓ ↓ ↓
Investigator Verifier SolverInvestigator
로그 분석
호출 경로 추적
문제 발생 지점 조사Verifier
Investigator의 결론을 독립적으로 검증
반대 가설 탐색
다른 Failure Path 확인Solver
검증된 사실만 기준으로
해결 방법과 Trade-off 제시이 패턴의 장점은 명확합니다.
A : 원인이 무엇인지 찾아라.
B : A의 결론이 틀렸다고 가정하고 검증해라.
C : 검증된 사실만 가지고 해결책을 만들어라.이렇게 역할을 분리하면 하나의 Agent가 자신의 결론을 스스로 검증할 때 발생할 수 있는 편향을 줄일 수 있습니다.
7. 실제 사례 5 - 병렬 구현은 Git Worktree와 함께 사용한다
여기서 한 단계 더 나가면 코드 구현 자체도 병렬화할 수 있습니다.
Coordinator
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Worktree A Worktree B Worktree C
│ │ │
Worker A Worker B Worker C각 Agent에게 별도의 Git Worktree와 Branch를 주는 방식입니다.
OpenAI 내부 개발환경 역시 변경사항마다 독립적인 Git Worktree에서 애플리케이션을 실행할 수 있도록 구성했고, Codex가 각 변경 환경에서 앱 실행, 버그 재현, 로그 및 metric 확인 등을 할 수 있도록 만들었습니다.
실제 Codex GitHub Issue에서도 한 사용자가
Coordinator
↓
Task별 Worktree 생성
↓
각 Worker Agent 배정
↓
독립 구현
↓
Coordinator가 결과 검토 및 통합방식으로 Codex를 사용한다고 설명했습니다.
다만 재미있는 문제가 하나 있습니다.
병렬 Worker가 자신의 Worktree가 아닌 Coordinator의 Worktree에서 실수로 파일을 찾거나 수정하는 문제가 발생할 수 있다는 것입니다.
실제로 해당 사용자는 그래서 spawn_agent 단계에서 Worker의 작업 디렉터리를 강제로 지정할 수 있는 기능을 요청했습니다.
이 사례가 병렬 구현을 무조건 사용하면 안 되는 이유도 잘 보여줍니다.
8. 서브에이전트의 장점
실제 사례를 보고 나니 장점도 훨씬 명확해졌습니다.
1) 메인 Context를 깨끗하게 유지할 수 있다
개인적으로 가장 큰 장점이라고 생각합니다.
예를 들어 테스트 Agent가 이런 로그를 분석했다고 해보겠습니다.
10,000 lines test logs
↓
Test Agent
↓
"3 tests failed.
원인은 A와 B이며 영향 범위는 C입니다."
↓
Main Agent메인 Agent에게 필요한 것은 대부분 10,000줄의 로그가 아니라 결론입니다.
OpenAI도 서브에이전트 활용의 주요 이유로 이런 Context Pollution과 Context Rot 감소를 설명합니다.
2) 서로 독립적인 작업을 동시에 처리할 수 있다
예를 들어:
DB 영향 분석 ─┐
Security Review ─┼─ 동시에 실행
Test 분석 ─┤
Frontend 영향 ─┘이 네 작업 사이에 의존성이 없다면 순차 실행할 이유가 없습니다.
OpenAI 역시 Codebase Exploration, Test, Triage, Summarization 같은 read-heavy 작업을 병렬 Agent 활용의 좋은 시작점으로 권장합니다.
3) 리뷰 관점을 분리할 수 있다
Security Reviewer
Test Reviewer
Regression Reviewer
Architecture Reviewer각 Agent에게 보는 관점을 제한할 수 있습니다.
하나의 Agent에게
전체적으로 잘 봐줘.라고 하는 것보다 책임 범위가 명확합니다.
4) 긴 작업을 작은 문제로 나눌 수 있다
복잡한 작업 하나를 통째로 해결하려 하지 않고,
큰 Issue
↓
분석
설계
DB
Backend
Frontend
Test
Review처럼 bounded task로 나눌 수 있습니다.
결과적으로 메인 Agent는 모든 세부사항을 직접 처리하는 Worker라기보다 Orchestrator에 가까워집니다.
9. 서브에이전트의 단점
물론 무조건 좋은 것은 아닙니다.
1) 토큰을 절약하는 기능은 아니다
이 부분은 처음 생각했던 것과 반대였습니다.
각 서브에이전트가 별도의 모델 작업과 Tool 작업을 수행하기 때문에 동일한 작업을 단일 Agent가 처리하는 것보다 더 많은 Token을 사용할 수 있습니다.
즉,
비용을 아끼기 위해 Agent를 나눈다.
가 아니라,
AI 연산을 더 사용해서 사람의 시간과 메인 Context를 아낀다.
에 가깝습니다.
2) 작업을 잘못 나누면 오히려 비효율적이다
예를 들어 이런 작업은 굳이 Agent 세 명이 필요하지 않습니다.
버튼 이름 하나 변경그런데
Agent 1 : 영향도 분석
Agent 2 : 구현
Agent 3 : 테스트
Agent 4 : 리뷰까지 만든다면 배보다 배꼽이 더 커집니다.
잘 정의된 작은 수정이나 일회성 작업에서는 그냥 단일 Codex가 더 빠르고 저렴할 수 있습니다.
3) 여러 Agent가 동시에 코드를 수정하면 충돌할 수 있다
이것도 중요한 부분입니다.
Worker A ─┐
Worker B ─┼─ 같은 파일 수정
Worker C ─┘이렇게 되면 코드 충돌뿐 아니라 Agent 간 조율 비용도 커집니다.
그래서 OpenAI 공식 가이드도 처음에는
Exploration
Test
Triage
Summarization같은 Read-heavy 작업부터 병렬화하고, Write-heavy 병렬 작업은 더 신중하게 사용하라고 안내합니다.
10. 그래서 실제 개발에는 어떻게 적용할까?
여러 사례를 보고 제가 가장 괜찮다고 느낀 구조는 이것입니다.
병렬 분석 + 단일 구현 + 독립 리뷰
Main Codex
Orchestrator
│
┌────────────────┼────────────────┐
↓ ↓ ↓
Code Explorer Test Analyzer Risk Reviewer
READ ONLY READ ONLY READ ONLY
│ │ │
└────────────────┼────────────────┘
↓
결과 통합
↓
Worker
WRITE
↓
Full Test
↓
┌───────────┴───────────┐
↓ ↓
Formal Reviewer Security Reviewer
READ ONLY READ ONLY
│ │
└───────────┬───────────┘
↓
수정
↓
PR이 방식의 가장 큰 장점은 코드를 실제로 수정하는 Agent는 한 명으로 유지하면서 가장 Context를 많이 소모하는 탐색과 검증 작업을 분리할 수 있다는 점입니다.
11. 예를 들어 실제 Java 프로젝트라면
DB Migration, Backend, Frontend가 함께 변경되는 Issue가 있다고 가정해보겠습니다.
메인 Codex에게 이렇게 요청할 수 있습니다.
이번 작업은 서브에이전트를 사용한다.
먼저 구현하지 말고 다음 분석을 병렬 수행해.
Agent 1 - DB Analyzer
- Flyway migration
- schema 영향
- 기존 데이터 호환성
- rollback 위험
을 분석한다.
코드는 수정하지 않는다.
Agent 2 - Backend Explorer
- Controller
- Service
- Transaction
- 호출 경로
- 기존 Contract
영향을 분석한다.
코드는 수정하지 않는다.
Agent 3 - Test Analyzer
- 관련 기존 테스트
- 회귀 가능성
- 누락된 테스트
를 분석한다.
코드는 수정하지 않는다.
Agent 4 - Risk Reviewer
- security
- concurrency
- transaction
- compatibility
위험을 분석한다.
코드는 수정하지 않는다.
모든 Agent가 완료될 때까지 기다린다.
결과를 통합한 뒤 구현 계획을 확정하고,
실제 코드 수정은 Worker 한 명만 수행한다.
구현 및 전체 테스트가 끝나면
새로운 Reviewer Agent를 사용해 독립 리뷰한다.
P0/P1 문제가 발견되면 Worker가 수정하고
다시 Reviewer 검증을 수행한다.이 정도만으로도 기존의
한 Agent가 모든 것을 탐색하고
한 Agent가 모든 것을 기억하고
한 Agent가 자기 코드를 다시 리뷰하는 구조와 꽤 달라집니다.
12. 새 채팅과 서브에이전트는 경쟁 관계가 아니었다
이 부분도 이번에 정리가 됐습니다.
저는 기존에 작업이 길어지면 Codex 새 채팅을 만들었습니다.
그런데 서브에이전트를 사용한다고 이 방법을 버릴 필요는 없습니다.
둘의 역할이 다릅니다.
새 채팅
개발 단계 자체를 분리하는 용도
Chat A
Issue 구현
↓
Chat B
PR Formal Review
↓
Chat C
후속 수정서브에이전트
한 개발 단계 안에서 작업을 분리하는 용도
Chat A
Issue 구현
├ Explorer
├ DB Analyzer
├ Test Analyzer
├ Reviewer
└ Worker그래서 오히려 두 가지를 함께 사용하는 것이 좋아 보입니다.
13. 제가 앞으로 적용해보려는 방식
기존에는 대략 이렇게 작업했습니다.
ChatGPT
↓
Codex 구현
↓
Codex 자체 리뷰
↓
PR
↓
ChatGPT 리뷰
↓
Codex 수정
↓
다시 리뷰완벽하게 검증하려다 보니 제가 중간 단계에 계속 개입해야 했습니다.
앞으로는 조금 다르게 해볼 생각입니다.
ChatGPT
Issue / Acceptance Criteria 설계
↓
Codex Main
↓
┌─────────┼─────────┐
↓ ↓ ↓
Explorer Tester Reviewer
└─────────┼─────────┘
↓
Worker
↓
Full Test
↓
┌─────────┴─────────┐
↓ ↓
Formal Reviewer Security Reviewer
└─────────┬─────────┘
↓
자동 수정 반복
↓
PR
↓
최종 인간 검토사람이 모든 중간 과정을 관리하는 대신,
Codex 내부에서 역할을 나누고 정말 판단이 필요한 지점만 사람이 확인하는 구조입니다.
이 방식이 잘 자리 잡으면 제가 직접 해야 할 일이 꽤 줄어들 것 같습니다.
마무리
서브에이전트를 처음 봤을 때는
AI를 여러 개 동시에 돌리는 기능
정도로 생각했습니다.
그래서 실제 개발에서 어떻게 사용해야 하는지 조금 두루뭉술했습니다.
이번에 실제 사례들을 찾아보고 나니 생각이 바뀌었습니다.
서브에이전트의 핵심은 Agent의 숫자가 아니라 역할 분리였습니다.
탐색하는 Agent
검증하는 Agent
구현하는 Agent
테스트하는 Agent
리뷰하는 Agent를 분리하고,
메인 Agent는
요구사항
의사결정
작업 분배
결과 통합에 집중하게 만드는 것입니다.
특히 제가 가장 중요하게 보는 포인트는 이것입니다.
서브에이전트는 Token을 아끼는 기능이 아니라, Token을 더 사용해서 사람의 시간과 메인 Context를 아끼는 기능이다.
그리고 실제 개발에서는 처음부터 여러 Worker에게 코드를 병렬로 작성시키기보다,
Read-heavy 작업은 병렬화하고, Write는 통제한다.
는 방식부터 시작하는 것이 가장 안전해 보입니다.
저도 다음 개발 작업부터
Explorer → Test Analyzer → Worker → Independent Reviewer
구조를 실제 프로젝트에 적용해볼 생각입니다.
사용해보고 기존 단일 Codex 방식과 작업 속도, 사용량, 리뷰 품질이 어떻게 달라지는지도 따로 기록해보겠습니다.
참고 자료
