GPT-5.6 멀티 에이전트 실전 사용법: Codex에서 여러 AI 개발자를 병렬로 일시키는 방법
GPT-5.6 멀티 에이전트 실전 사용법: Codex에서 여러 AI 개발자를 병렬로 일시키는 방법
AI 코딩 Agent를 처음 사용하면 보통 하나의 Agent에게 모든 작업을 맡긴다.
사용자
↓
Codex
↓
Repository 분석
↓
코드 수정
↓
테스트
↓
완료작은 기능이나 버그 수정이라면 이 구조로 충분하다.
하지만 작업이 커지면 문제가 생긴다.
예를 들어 다음 작업을 생각해보자.
로그인 시스템을 전반적으로 개선해줘.
현재 Architecture를 분석하고,
Concurrency 문제를 찾고,
보안 취약점을 확인하고,
관련 테스트를 정리한 다음
개선안을 구현해줘.Agent 하나가 이것을 순서대로 처리하면 꽤 오래 걸린다.
Architecture 분석
↓
Concurrency 분석
↓
Security 분석
↓
Test 분석
↓
구현
↓
검증그런데 앞의 네 작업은 상당 부분 서로 독립적이다.
그렇다면 이렇게 할 수 있다.
Main Agent
│
┌─────────────┼─────────────┐
│ │ │
Architecture Concurrency Security
Agent Agent Agent
│ │ │
└──────────┬──┴───────┬─────┘
│ │
Test Agent │
│ │
└────┬─────┘
│
결과 종합
│
구현이것이 멀티 에이전트를 사용하는 가장 기본적인 이유다.
순차로 할 필요가 없는 일을 병렬로 처리하는 것.
GPT-5.6에서는 이 방식이 Codex의 ultra와 Multi-Agent 기능으로 한 단계 더 들어왔다.
이번 글에서는 API를 직접 만드는 방법이 아니라 Codex를 쓰는 개발자가 실제 Repository에서 멀티 에이전트를 어떻게 활용할 수 있는지부터 시작해본다.
1. 먼저 멀티 에이전트를 어렵게 생각하지 않아도 된다
멀티 에이전트라고 하면 이런 것을 먼저 떠올리기 쉽다.
Agent Framework
Message Queue
A2A
Distributed Runtime
Agent Registry
Task Scheduler물론 큰 시스템에서는 이런 구조가 필요하다.
하지만 Codex에서 멀티 에이전트를 사용하는 데 이런 것을 직접 만들 필요는 없다.
가장 단순한 형태는 이것이다.
큰 작업
↓
서로 독립적인 작은 작업으로 분해
↓
여러 Agent가 동시에 수행
↓
결과를 하나로 합침예를 들어 코드 리뷰라면
Agent A
→ Logic Bug 검토
Agent B
→ Concurrency 검토
Agent C
→ Security 검토
Agent D
→ Test Coverage 검토처럼 나눌 수 있다.
2. Codex에서는 이미 여러 Agent를 병렬로 사용할 수 있다
Codex 앱 자체가 여러 Agent를 동시에 관리하기 위한 방향으로 만들어져 있다.
Codex 앱에서는 각 작업을 별도의 환경에서 실행할 수 있고, 여러 Agent가 서로 다른 작업을 병렬로 수행할 수 있다.
구조는 대략 다음과 같다.
Codex
├── Task A
│ └── Agent
│ └── Worktree A
│
├── Task B
│ └── Agent
│ └── Worktree B
│
└── Task C
└── Agent
└── Worktree C각 Agent가 같은 Working Directory를 동시에 수정하는 것이 아니다.
Codex는 Worktree와 Cloud Environment 같은 격리된 작업 공간을 이용해 Agent들이 병렬로 작업할 수 있게 설계돼 있다.
그래서 개발자가 직접
git clone A
git clone B
git clone C를 만들어 관리할 필요가 크게 줄어든다.
3. Codex부터 기본 세팅해보자
Codex 앱 기준으로는 시작이 어렵지 않다.
1단계
Codex를 실행하고 ChatGPT 계정으로 로그인한다.
API Key를 직접 넣지 않아도 ChatGPT 계정으로 사용할 수 있다.
2단계
작업할 Repository를 선택한다.
예를 들어
~/Projects/MyApp을 선택한다.
Git Repository라면 Codex가 프로젝트 구조를 읽고 작업할 수 있다.
3단계
첫 작업을 입력한다.
예:
이 프로젝트의 로그인 구조를 분석해줘.
코드는 수정하지 말고
- Authentication 흐름
- Token 관리
- Session 갱신
- Error 처리
네 부분을 먼저 정리해줘.이것만으로 기본 Agent 사용은 시작된다.
4. 처음부터 멀티 에이전트를 쓸 필요는 없다
작업이 이것이라면
버튼 텍스트를 변경해줘.Agent를 네 명 사용할 이유가 없다.
Codex
→ 수정
→ 완료면 충분하다.
멀티 에이전트가 가치가 있는 작업은 보통 다음과 같다.
대규모 Repository 분석
Architecture 개선
복잡한 Debugging
Migration
Security Review
여러 Module 변경
대규모 Test 분석
Research + Implementation공통점은 독립적으로 나눌 수 있는 하위 작업이 많다는 것이다.
5. 가장 쉬운 멀티 에이전트 사용법
처음에는 Agent에게 역할을 명확하게 나눠서 요청하는 것으로 시작하면 된다.
예를 들어
이 Repository의 로그인 시스템을 분석해줘.
작업을 병렬로 나눠서 조사해.
1. Authentication Architecture 분석
2. Concurrency / Race Condition 분석
3. Security 문제 분석
4. Test Coverage 분석
각 조사 결과를 독립적으로 만든 뒤
마지막에 하나의 개선 계획으로 합쳐줘.
아직 코드는 수정하지 마.이 Prompt의 핵심은
병렬로 나눠서 조사와
각 결과를 독립적으로 만든다그리고
마지막에 합친다다.
6. 작업을 어떻게 나누는지가 가장 중요하다
멀티 에이전트 성능은 Agent 숫자보다 Task Decomposition에 더 크게 영향을 받는다.
좋은 병렬화는 이런 것이다.
Agent A
→ Networking
Agent B
→ Authentication
Agent C
→ Database
Agent D
→ Tests서로 작업 범위가 겹치지 않는다.
좋지 않은 병렬화는 이렇다.
Agent A
→ 로그인 문제 고쳐
Agent B
→ 로그인 문제 고쳐
Agent C
→ 로그인 문제 고쳐
Agent D
→ 로그인 문제 고쳐네 Agent가 똑같은 문제를 해결하려고 한다.
결과적으로
중복 조사
중복 수정
충돌
Context 낭비
비용 증가가 발생한다.
7. OpenAI의 ultra는 바로 이 문제를 자동화한다
GPT-5.6에서 중요한 기능 중 하나가 ultra다.
OpenAI가 설명하는 ultra는 단순히 reasoning effort를 한 단계 높인 옵션이 아니다.
max
→ 하나의 GPT-5.6이 더 오래 생각함반면
ultra
→ 여러 Agent가 병렬 Workstream을 수행한다.
GPT-5.6 ultra는 기본적으로 4개의 Agent를 병렬 조율한다.
구조를 단순화하면
GPT-5.6
Coordinator
│
┌─────────────┼─────────────┐
│ │ │
Agent Agent Agent
A B C
│ │ │
└─────────────┼─────────────┘
│
Agent D
│
결과 종합정도로 생각할 수 있다.
8. Codex에서 ultra를 사용할 수 있다
중요한 부분이다.
이 기능은 API에서만 사용할 수 있는 것이 아니다.
GPT-5.6 출시 기준으로 Codex에서는 Plus 이상 플랜에서 ultra를 사용할 수 있다.
즉 Codex를 사용하는 개발자는 별도의 Multi-Agent Server를 만들지 않고도 사용할 수 있다.
GPT-5.6을 사용할 수 있는 Codex에서는
Model
GPT-5.6 Sol같은 모델 선택과 함께 Capability / Effort 설정을 사용할 수 있다.
일반적으로
medium
high
xhigh
max처럼 하나의 Agent가 사용하는 reasoning 수준을 올릴 수 있고,
더 복잡한 작업에서는
ultra를 이용해 병렬 Agent 실행을 활용할 수 있다.
9. max와 ultra를 구분해야 한다
이 부분은 꽤 중요하다.
max
한 Agent
↓
더 많은 Reasoning
↓
더 오래 탐색
↓
더 많은 검증ultra
여러 Agent
↓
독립적인 Workstream
↓
병렬 실행
↓
결과 합성즉
max
= 깊게
ultra
= 넓고 동시에라고 이해하면 쉽다.
물론 ultra 내부 Agent들도 충분한 reasoning을 사용할 수 있기 때문에 완전히 독립적인 개념은 아니지만, 사용자 입장에서 중요한 차이는 병렬성이다.
10. 언제 max가 더 나을까
다음 문제를 생각해보자.
FramePublisher.swift에서 발생하는
특정 Race Condition의 원인을 찾아라.핵심 문제가 하나다.
여러 Agent가 나눌 수 있는 부분이 적다.
이런 경우
GPT-5.6 Sol
+
max처럼 한 Agent가 깊게 조사하는 쪽이 나을 수 있다.
11. 언제 ultra가 더 나을까
다음 작업은 다르다.
이 앱의 Authentication 시스템을
전체적으로 개선해줘.
Architecture
Security
Concurrency
Testing
Performance
를 모두 확인해.독립적인 Workstream이 많다.
Architecture
Security
Concurrency
Testing
Performance이런 문제는 멀티 에이전트에 잘 맞는다.
12. 좋은 ultra 요청 예제
Codex에서 다음처럼 요청할 수 있다.
현재 Authentication 모듈을 개선하고 싶어.
먼저 코드를 수정하지 말고
독립적인 분석 Workstream으로 나눠 조사해.
확인할 영역:
1. Architecture와 의존성 방향
2. Token 저장과 보안
3. Session Refresh의 Concurrency
4. Error Handling
5. Unit / Integration Test Coverage
가능한 작업은 병렬로 진행해.
각 Workstream에서
- 발견한 문제
- 근거가 되는 파일
- 위험도
- 수정 필요 여부
를 정리해.
모든 분석이 끝나면
중복된 내용을 제거하고
하나의 구현 계획으로 합쳐줘.
아직 구현은 시작하지 마.이 Prompt는 꽤 좋은 출발점이다.
13. 분석과 구현을 한 번에 시키지 않는 것도 방법이다
대규모 작업에서는
분석
+
구현
+
테스트
+
리뷰를 한 Prompt에 전부 넣는 것보다 Stage를 나누는 것이 좋다.
Stage 1
병렬 조사Stage 2
결과 통합Stage 3
구현 계획Stage 4
코드 수정Stage 5
병렬 검증구조가 훨씬 명확하다.
14. 실전에서는 Planner → Workers → Reviewer 구조가 좋다
가장 이해하기 쉬운 멀티 에이전트 구조다.
Planner
│
┌─────────┼─────────┐
│ │ │
Worker Worker Worker
A B C
│ │ │
└─────────┼─────────┘
│
Reviewer
│
ResultPlanner가 먼저 작업을 나눈다.
Worker들이 독립적으로 수행한다.
Reviewer가 결과를 검증한다.
15. Coding Agent라면 이런 역할이 현실적이다
예를 들어 앱 Migration 작업을 한다고 하자.
Planner
→ 전체 Migration 범위 분석Worker는 Module 단위로 나눈다.
Worker A
→ Auth Module
Worker B
→ Camera Module
Worker C
→ Network Module
Worker D
→ Analytics ModuleReviewer는
Public API 변경 확인
Dependency 방향 확인
Test 결과 확인
Regression 확인을 담당한다.
16. 처음에는 Worker에게 코드 수정까지 맡기지 않아도 된다
멀티 에이전트를 처음 사용할 때는 Read-only 병렬 분석부터 시작하는 것이 좋다.
Agent A
→ 코드 분석
Agent B
→ 테스트 분석
Agent C
→ Security 분석
Agent D
→ Architecture 분석모두 읽기 작업이다.
마지막 Main Agent만 코드를 수정한다.
Workers
Read Only
↓
Findings
↓
Main Agent
↓
Write충돌 가능성이 크게 줄어든다.
17. 그다음 단계에서 수정도 병렬화한다
구조가 안정되면 Worker에게 수정까지 맡길 수 있다.
다만 파일 Ownership을 나눈다.
Worker A
Sources/Auth/*Worker B
Sources/Network/*Worker C
Tests/Auth/*처럼 범위를 나눈다.
18. 같은 파일을 여러 Agent에게 수정시키지 않는다
가장 흔한 실패 패턴이다.
Agent A
→ AuthManager.swift
Agent B
→ AuthManager.swift
Agent C
→ AuthManager.swift세 Agent가 동시에 수정한다.
결과는
Conflict
중복 구현
서로 다른 Architecture
Merge 실패가 될 수 있다.
가능하면
One File
→ One Owner원칙을 적용한다.
19. Codex의 Worktree가 중요한 이유
이 문제 때문에 Codex의 병렬 Agent 구조에서 Worktree가 중요하다.
Git Worktree를 단순화하면
Repository
main
│
├── worktree-auth
│
├── worktree-network
│
└── worktree-tests처럼 같은 Repository에서 독립된 Working Directory를 만든다.
각 Agent가 별도 Worktree에서 작업한다.
Agent A
→ worktree-auth
Agent B
→ worktree-network
Agent C
→ worktree-tests작업 공간 자체가 분리된다.
Codex 앱은 이런 병렬 Worktree 기반 Agent 작업을 제품 차원에서 지원한다.
20. 두 가지 종류의 Codex 멀티 에이전트를 구분하자
여기서 조금 헷갈릴 수 있다.
Codex에서 병렬 Agent를 쓴다는 말에는 사실 두 가지 의미가 있다.
첫 번째
사용자가 여러 작업을 직접 병렬 실행한다.
Codex App
├── Task A
├── Task B
├── Task C
└── Task D각 Task는 별도의 Agent다.
사용자가 업무를 나누는 방식이다.
두 번째
GPT-5.6 ultra가 하나의 큰 Task를 내부적으로 여러 Agent에게 나눈다.
User
↓
하나의 Task
↓
GPT-5.6 ultra
├── Agent A
├── Agent B
├── Agent C
└── Agent D
↓
통합된 Result둘은 비슷하지만 제어 위치가 다르다.
21. 사용자 관리형 병렬 Agent
개발자가 직접 이렇게 한다.
Task A
로그인 Architecture 조사Task B
Authentication Test 조사Task C
Token Security 조사Codex 앱에서 각각 실행한다.
장점은
업무 범위가 명확함
각 Agent를 따로 확인 가능
필요한 작업만 재실행 가능
결과 비교가 쉬움이다.
22. ultra 관리형 멀티 에이전트
사용자는 큰 Goal만 준다.
Authentication 시스템을 전체적으로 검토하고
개선 계획을 만들어줘.ultra가 내부적으로 Workstream을 구성한다.
장점은
Task 분할 부담 감소
병렬 Agent 자동 Coordination
결과 자동 합성
복잡한 작업의 Wall-clock 단축이다.
23. 어느 쪽이 더 좋을까
작업 범위를 개발자가 잘 알고 있다면 직접 나누는 것이 좋다.
예를 들어
iOS 개발자
Auth
Network
Camera
Widget각 Module 구조를 잘 알고 있다.
그렇다면 직접
Agent 1
Auth
Agent 2
Network
Agent 3
Camera
Agent 4
Widget로 나누는 것이 더 예측 가능하다.
반대로
어디서 문제가 발생하는지 모르겠다.
전체 시스템을 조사해라.같은 문제는 ultra 쪽이 편하다.
24. ultra가 빠른 이유
Agent 4개가 있다고 해서 Token 사용량이 줄어드는 것은 아니다.
오히려 늘어날 수 있다.
하지만 Wall-clock Time을 줄일 수 있다.
순차 처리:
Task A
10분
↓
Task B
10분
↓
Task C
10분
↓
Task D
10분
=
40분병렬 처리:
Task A ─┐
Task B ─┤
Task C ─┤ → 동시에 실행
Task D ─┘
≈ 가장 오래 걸린 작업 시간실제 시간은 Coordination과 결과 합성 때문에 이것보다 더 들지만 원리는 같다.
25. 대신 Token 사용은 늘어난다
병렬 Agent는 공짜가 아니다.
Agent A Context
Agent B Context
Agent C Context
Agent D Context각 Agent가 별도의 Context와 Output을 사용한다.
따라서
Parallelism ↑
Wall-clock ↓
Token Usage ↑가 될 가능성이 높다.
OpenAI 역시 ultra를 더 높은 Token 사용량과 맞바꾸어 더 강한 결과와 더 빠른 time-to-result를 얻는 설정으로 설명한다.
26. 모든 작업을 ultra로 돌리면 안 된다
이런 작업은 낭비다.
UIButton 색상 변경
README 문구 수정
함수 이름 변경
간단한 Test 하나 작성하나의 Agent면 충분하다.
추천 기준을 단순화하면
작은 작업
→ Terra / Luna일반 개발
→ Sol medium / high복잡한 단일 문제
→ Sol max여러 독립 Workstream이 있는 대형 작업
→ ultra정도로 생각할 수 있다.
27. Parallelizable한 작업인지 먼저 본다
ultra 사용 여부를 판단하는 가장 좋은 질문이다.
이 작업을 서로 독립적인
3~4개의 Workstream으로 나눌 수 있는가?YES라면 좋은 후보다.
예:
Architecture Review
Security Review
Performance Review
Test ReviewNO라면 굳이 여러 Agent를 사용할 이유가 없다.
28. 이런 문제는 병렬화가 잘 안 된다
예를 들어 특정 Compiler Error가 있다.
Error A를 해결해야
Error B가 나타난다.
Error B를 해결해야
Error C를 확인할 수 있다.구조가
A
↓
B
↓
C다.
Dependency가 강하다.
이런 문제에서 Agent A, B, C를 동시에 실행해도 B와 C는 할 수 있는 일이 거의 없다.
멀티 에이전트보다 하나의 강한 Agent가 더 낫다.
29. 좋은 병렬 작업의 특징
멀티 에이전트가 잘 맞는 작업은 다음 특성이 있다.
Independent
Bounded
Clear Output
Low Shared State
Easy Verification예를 들어
Module별 Migration은 좋은 편이다.
Auth
Network
Camera
Payment각 Module이 비교적 독립적이다.
30. 결과 형식을 미리 정하면 더 좋아진다
여러 Agent 결과를 합쳐야 하기 때문에 Output 형식을 통일하는 것이 좋다.
예를 들어 모든 Worker가 다음 형태로 보고하도록 한다.
Finding
Severity
Evidence
File
Suggested Fix더 구조화하면
{
"findings": [
{
"severity": "high",
"file": "Sources/Auth/SessionManager.swift",
"issue": "Possible refresh race",
"evidence": "Lines 142-171",
"recommendation": "Serialize refresh state"
}
]
}같은 형태가 된다.
Main Agent가 결과를 합치기 쉬워진다.
31. Prompt에도 Result Contract를 넣자
Codex에 다음처럼 줄 수 있다.
각 병렬 Workstream은 아래 형식으로 결과를 반환해.
- finding
- severity
- evidence
- affected files
- recommended action
추측과 확인된 사실을 구분해.
파일 근거가 없는 finding은 별도로 표시해.
마지막 Coordinator는 중복 finding을 제거하고
severity 순으로 정렬해.이 정도만 넣어도 결과 품질이 꽤 달라진다.
32. Coding까지 병렬화할 때는 Ownership을 추가한다
각 Worker는 자신에게 할당된 Module만 수정해.
Agent A:
Sources/Auth/**
Agent B:
Sources/Network/**
Agent C:
Tests/Auth/**
Agent D:
Tests/Network/**
다른 Agent 영역 파일은 수정하지 마.경계를 명확하게 한다.
33. 공통 파일은 Main Agent에게 남긴다
다음 파일은 여러 Module에서 동시에 건드릴 수 있다.
Package.swift
project.pbxproj
AppContainer.swift
DependencyContainer.swift이런 파일은 Worker에게 맡기지 않고 Main Agent가 마지막에 수정하도록 할 수 있다.
Workers
Module 변경
↓
Main Agent
Shared file 통합 변경Conflict가 크게 줄어든다.
34. 검증도 병렬화할 수 있다
구현만 병렬화하는 것이 아니다.
코드가 완성되면 검증도 나눌 수 있다.
Reviewer A
LogicReviewer B
ConcurrencyReviewer C
SecurityReviewer D
Tests그리고 Main Agent가 종합한다.
35. Developer와 Reviewer는 같은 Agent가 아니어도 된다
특히 중요한 변경에서는
Developer Agent
↓
Reviewer Agent를 분리하는 것이 좋다.
Developer는 자신의 구현에 Bias가 생길 수 있다.
Reviewer는 독립 Context에서 Diff를 볼 수 있다.
Reviewer에게 제공
Task
Diff
Test Result
Acceptance Criteria정도만 준다.
Developer의 Reasoning 전체를 전달하지 않는 편이 독립 검토에 유리하다.
36. Claude 쪽은 "Ultra"라는 공식 명칭이 아니다
여기서 하나 바로잡아야 한다.
OpenAI에는 실제로
ultra라는 공식 Capability 설정이 있다.
하지만 Anthropic의 Claude Code에는 현재 같은 이름의 Claude Ultra Mode가 공식 제품 기능으로 존재하는 것은 아니다.
Claude 쪽에서 비교해야 할 것은
Subagents
Agent Teams
Dynamic Workflows
Fable 5의 장시간 Agent 능력이다.
즉 비교를 정확히 하면
Codex GPT-5.6 ultra
VS
Claude Code Dynamic Workflows / Agent Teams가 더 적절하다.
37. Claude Code의 Subagent
Claude Code에서도 Main Agent가 특정 작업을 별도 Agent에게 위임할 수 있다.
구조는
Claude Code
Main Agent
│
├── Research Subagent
├── Review Subagent
└── Test Subagent처럼 볼 수 있다.
각 Subagent가 Focused Context를 갖고 작업한 후 Main Agent에게 결과를 돌려준다.
38. Claude Agent Teams
Anthropic은 여러 Claude Instance가 하나의 프로젝트에서 병렬 작업하는 Agent Teams 패턴도 실험하고 있다.
Anthropic은 실제 실험에서 16개의 Claude Agent를 병렬로 사용해 Rust 기반 C Compiler를 만드는 프로젝트를 수행했다.
각 Agent가 다른 Task를 가져가고 작업한 뒤 Git을 통해 변경을 통합하는 구조였다.
중요한 교훈도 있었다.
Agent 수를 늘린다고 항상 빨라지는 것은 아니었다.
서로 독립적인 실패 Test가 많을 때는 병렬화가 잘 됐다.
하지만 모든 Agent가 같은 Linux Kernel Compile Failure에 막히자 16개 Agent가 있어도 도움이 되지 않았다.
결국 문제 자체를 독립적으로 나눌 수 있게 Test Harness를 다시 설계해야 했다.
이 사례는 멀티 에이전트 설계의 핵심을 잘 보여준다.
Agent 숫자
보다
Task Decomposition이 더 중요하다.
39. Claude Dynamic Workflows
Claude Code에는 더 높은 수준의 자동 병렬 실행 방식인 Dynamic Workflows도 있다.
Anthropic은 이를 Claude가
Task 계획
↓
필요한 Subtask 생성
↓
다수 Subagent 병렬 실행
↓
결과 확인
↓
검증
↓
최종 보고하는 구조로 설명한다.
Research Preview 단계에서는 하나의 Session에서 수백 개의 병렬 Subagent를 실행할 수 있는 형태까지 공개됐다.
대규모 코드베이스 Migration 같은 작업이 주요 예다.
40. GPT-5.6 ultra와 Claude Dynamic Workflows 비교
개념적으로 보면 다음과 같다.
GPT-5.6 ultra
사용자
↓
GPT-5.6 Coordinator
↓
기본 4개 Agent 병렬 실행
↓
결과 합성OpenAI가 제품 수준 Capability로 제공한다.
Codex에서 설정으로 사용할 수 있다.
Claude Dynamic Workflows
사용자
↓
Claude Planner
↓
필요한 Subagent 동적 생성
↓
다수 Workstream 병렬 처리
↓
Verification
↓
Result보다 큰 장기 작업을 동적으로 분할하는 방향이다.
41. 차이를 너무 단순하게 보면 안 된다
Codex = 4개
Claude = 수백 개라고 비교하는 것은 적절하지 않다.
Agent 수가 많다고 성능이 더 좋은 것이 아니기 때문이다.
중요한 것은
Task 분할 능력
Agent 품질
Context 관리
Tool 사용
Worktree
검증
결과 합성
Budget전체 Runtime 구조다.
42. Fable 5가 여기서 중요한 이유
Claude Fable 5는 Anthropic이 장시간 복잡 작업을 위해 만든 최상위 모델이다.
Anthropic은 Fable 5를 Agent Harness에서 사용할 경우
여러 단계 Planning
Subagent Delegation
자체 검증
장시간 실행을 며칠 단위까지 이어갈 수 있는 모델로 설명한다.
따라서 Claude 쪽 대형 멀티 에이전트 구조에서는
Fable 5
→ Planner / Coordinator로 사용하고
Sonnet 5
→ Worker처럼 역할을 분리하는 전략도 가능하다.
43. 꼭 같은 모델만 쓸 필요는 없다
멀티 에이전트의 장점 중 하나다.
모든 Worker가 최고 모델일 필요는 없다.
예:
Fable 5
Planner
│
├── Sonnet 5 Worker
├── Sonnet 5 Worker
├── Haiku Worker
└── Sonnet 5 Worker또는 앞서 다룬 Model Router를 적용할 수 있다.
Complex Planning
→ Frontier Model
General Coding
→ Balanced Model
Simple Inventory
→ Fast Model44. Codex에서도 같은 원칙을 생각할 수 있다
개념적으로
Sol
Planner / Hard ReasoningTerra
일반 WorkerLuna
반복적·단순 Worker처럼 Model Tier를 나눌 수 있다.
다만 Codex의 ultra 내부 병렬 Agent 구성은 제품이 조율하므로 사용자가 항상 각 하위 Agent 모델을 직접 지정한다는 뜻은 아니다.
이 부분은 직접 Agent Runtime을 만드는 경우와 구분해야 한다.
45. Codex 사용자에게는 일단 ultra부터 써보는 것이 쉽다
처음 멀티 에이전트를 사용한다면 직접 Agent Framework를 만들 필요가 없다.
다음 순서가 현실적이다.
1.
Codex 프로젝트 연결
↓
2.
일반 Agent로 작업
↓
3.
큰 Task에서 high / max 사용
↓
4.
독립 Workstream이 많은 작업에서 ultra 사용
↓
5.
결과 품질과 비용 비교이 정도로 시작한다.
46. 제가 처음 테스트한다면 이런 Task를 사용한다
예를 들어 iOS 프로젝트라면
프로젝트 전체의 Networking Layer를 검토해줘.
병렬 Workstream으로 나눠
1. API Client Architecture
2. Error Handling
3. Concurrency
4. Security
5. Unit Test Coverage
를 분석해.
각 결과에는 반드시 파일 근거를 포함해.
분석 결과를 종합해서
P0
P1
P2
우선순위 개선안을 작성해.
코드는 아직 수정하지 마.좋은 멀티 에이전트 테스트다.
47. 다음 단계에서는 구현까지 맡긴다
첫 분석 결과가 괜찮았다면
앞에서 만든 P0 개선안만 구현해.
병렬 수정이 가능한 부분은 병렬로 작업하되
각 Agent의 파일 Ownership이 겹치지 않게 해.
공통 파일은 마지막에 Main Agent가 수정해.
각 Workstream은 관련 테스트를 실행하고
실행하지 않은 테스트를 Passed라고 보고하지 마.
모든 작업이 끝난 뒤
전체 Diff를 다시 Review해.처럼 진행한다.
48. AGENTS.md도 같이 사용하면 좋다
멀티 Agent가 늘어나면 프로젝트 규칙을 반복해서 설명하기 어렵다.
Repository에 AGENTS.md를 둔다.
예:
# Project Rules
## Architecture
- Follow the existing module boundaries.
- Do not introduce new global singletons.
- Do not bypass repository abstractions.
## Scope
- Modify only files required by the assigned workstream.
- Do not modify files owned by another worker.
- Shared configuration files are coordinator-owned.
## Validation
- Run relevant tests after implementation.
- Never report a test as passed unless it actually ran.
## Git
- Never modify main directly.
- Keep changes scoped to the assigned workstream.Main Agent와 Worker 모두 같은 기본 규칙을 참고할 수 있다.
49. 멀티 Agent 전용 규칙도 추가할 수 있다
## Multi-Agent Rules
- Each workstream must have a clear owner.
- Do not modify another worker's files.
- Report findings with file evidence.
- Do not duplicate work already assigned elsewhere.
- Shared files are modified only during integration.
- Return a concise structured handoff to the coordinator.이런 규칙이 병렬 환경에서 특히 유용하다.
50. 충돌 방지의 핵심은 세 가지다
멀티 에이전트 Coding에서는 이것만 기억해도 좋다.
Task Ownership
File Ownership
Worktree IsolationTask Ownership
누가 어떤 문제를 해결하는지.
File Ownership
누가 어떤 파일을 수정하는지.
Worktree Isolation
실제 Git Working Directory를 분리한다.
51. Agent 간 대화보다 Artifact를 공유하는 편이 좋다
Worker A가 Worker B에게 긴 자연어 설명을 계속 보내게 만들기보다 결과를 남긴다.
analysis-auth.json
security-review.json
test-report.jsonMain Agent가 이 Artifact를 읽는다.
구조는
Worker A
↓
Artifact A
Worker B
↓
Artifact B
Worker C
↓
Artifact C
↓
Coordinator
↓
Final Plan이 훨씬 관리하기 쉽다.
52. Handoff Contract도 만들 수 있다
예:
{
"workstream": "auth-concurrency",
"status": "completed",
"findings": [],
"modifiedFiles": [],
"tests": [],
"risks": [],
"blockedBy": []
}모든 Worker가 같은 형식으로 반환한다.
Main Agent의 결과 통합이 쉬워진다.
53. 병렬 실행에는 Budget가 필수다
Agent 하나를 사용할 때보다 비용 증가 속도가 빠르다.
1 Agent
Context
+
Reasoning
+
Tool Calls4 Agent라면
4 × Context
4 × Reasoning
4 × Tool Calls에 가까워질 수 있다.
따라서 대형 작업에서는 미리 경계를 둔다.
최대 Agent
최대 실행 시간
최대 Tool Call
최대 Retry
최대 비용54. 무한 Agent 증식을 막는다
직접 Runtime을 만드는 경우 특히 중요하다.
이런 구조는 위험하다.
Agent A
→ Agent B 생성
→ Agent C 생성
Agent B
→ Agent D 생성
Agent C
→ Agent E 생성계속 증가할 수 있다.
그래서
maxDepth
maxAgents
maxChildrenPerAgent같은 제한을 둔다.
Codex의 제품형 ultra에서는 이런 Coordination을 OpenAI가 관리하지만, 자체 Runtime에서는 반드시 직접 관리해야 한다.
55. Cancellation도 전파돼야 한다
사용자가 작업을 중단했다.
Main Task Cancel그런데 Worker는 계속 실행 중이다.
Agent A
Working
Agent B
Working
Agent C
Working이런 상황을 막아야 한다.
Root Cancel
↓
Child A Cancel
Child B Cancel
Child C Cancel
Child D CancelCancellation Propagation이 필요하다.
56. Timeout도 Worker마다 따로 둔다
예를 들어 Worker 하나가 Test에서 멈췄다.
다른 세 Agent가 끝났는데 전체 작업이 계속 기다릴 수 있다.
따라서
Per-agent timeout
Overall timeout두 개가 필요하다.
제품형 Codex에서는 Runtime이 많은 부분을 관리하지만, 자체 Agent Orchestrator를 만들 때는 반드시 고려해야 한다.
57. 결과 합성이 생각보다 중요하다
Worker 4명이 아주 좋은 결과를 만들었어도 Main Agent가 잘못 합치면 최종 결과는 나빠진다.
예:
Agent A
AuthManager 수정 추천Agent B
AuthManager 수정 금지 추천Conflict가 생긴다.
Coordinator는 단순히 결과를 붙이는 것이 아니라
Conflict Detection
Evidence 비교
Priority 결정
중복 제거를 해야 한다.
58. 그래서 Coordinator는 강한 모델이 좋다
Worker의 작업이 단순해도 Coordinator는 복잡하다.
4개의 Result
↓
중복 판단
↓
충돌 판단
↓
우선순위
↓
최종 Plan그래서 앞서 다룬 Model Router를 적용하면
Coordinator
→ Sol / Fable
Worker
→ Terra / Sonnet
Simple Worker
→ Luna / Haiku같은 구조가 합리적이다.
59. 하지만 제품형 Codex에서는 직접 세부 조합하지 않아도 된다
여기서 다시 중요한 구분이 있다.
Codex에서 ultra를 켜 사용하는 사람은
Coordinator Model
Worker A Model
Worker B Model
Worker C Model을 직접 구현할 필요가 없다.
제품이 Coordination을 담당한다.
직접 Agent Runtime을 개발할 때 이런 설계를 참고하면 된다.
60. Codex ultra와 Claude 쪽을 실사용 관점에서 정리하면
Codex GPT-5.6 ultra
장점:
설정이 간단함
Codex에서 바로 사용
기본 병렬 Coordination 제공
복잡한 Coding Task에 바로 적용
Worktree 기반 개발 환경과 연결추천:
대규모 Code Review
Architecture 조사
복합 Debugging
Migration
여러 Module 분석Claude Code Subagents
장점:
역할별 Agent 분리
Focused Context
Reviewer / Researcher 등 전문 역할 구성
CLI Workflow와 자연스럽게 연결추천:
특정 역할 위임
독립 Review
Research
Test 조사Claude Dynamic Workflows / Agent Teams
장점:
대규모 Task 자동 분할
많은 Subagent 병렬 실행 가능
장기 Autonomous Workflow
Fable 같은 Long-horizon Model과 결합추천:
대규모 Migration
Repository 전체 작업
장시간 프로젝트
여러 독립 Workstream61. 처음 사용하는 개발자에게 추천하는 단계
처음부터 수십 Agent를 운영하지 않는다.
Level 1
Codex Agent 1개일반 개발.
Level 2
Codex App
Task A
Task B두 작업을 직접 병렬 실행한다.
Level 3
GPT-5.6 ultra큰 Task 하나를 내부적으로 병렬 처리한다.
Level 4
Planner
+
Workers
+
Reviewer역할 기반 Workflow를 명시적으로 사용한다.
Level 5
Agent Orchestrator
Model Router
Budget
Trace
Typed Handoff
A2A자체 Agent Platform으로 확장한다.
62. 처음에는 Level 2와 Level 3이면 충분하다
개인 개발자가 당장 사용할 때는
여러 Codex Task
+
ultra만으로도 상당히 많은 병렬 작업이 가능하다.
Agent Framework부터 만들 필요는 없다.
63. 실제 추천 운영 방식
제가 지금 Codex로 iOS 프로젝트를 작업한다면 이렇게 시작할 것 같다.
평소 개발
GPT-5.6 Terra / Sol
medium 또는 high복잡한 Bug
Sol
high → maxRepository 전체 조사
Sol
ultra서로 완전히 다른 작업
Codex 앱에서 따로 실행한다.
Task 1
Widget 개선
Task 2
Camera Bug
Task 3
Networking Refactor이런 작업을 굳이 하나의 ultra Task로 묶지 않는다.
64. 한 작업 안의 병렬성과 여러 작업의 병렬성은 다르다
이것도 기억해두면 좋다.
여러 Task 병렬
Task A
Task B
Task C각 Task가 독립적이다.
Codex App에서 여러 Agent를 띄운다.
하나의 Task 내부 병렬
Big Task
├── Workstream A
├── Workstream B
├── Workstream C
└── Workstream Dultra 같은 Multi-Agent Coordination을 사용한다.
65. 좋은 멀티 에이전트 Prompt 템플릿
처음 사용할 때 아래 정도로 만들어두면 편하다.
이 작업을 먼저 분석하고
서로 독립적으로 수행 가능한 Workstream으로 나눠줘.
병렬화가 가능한 작업만 병렬로 수행해.
각 Workstream은 명확한 책임 범위를 가져야 하며
다른 Workstream과 중복 작업하지 마.
코드를 수정하는 경우
각 Worker의 파일 Ownership이 겹치지 않도록 해.
각 Worker 결과는 다음 형식으로 반환해.
- Workstream
- Findings
- Evidence
- Modified Files
- Tests
- Risks
- Remaining Issues
모든 Worker가 끝나면 Coordinator가
1. 중복 결과 제거
2. 충돌 검토
3. Evidence 확인
4. 전체 Test 확인
5. 최종 결과 정리
를 수행해.
실행하지 않은 테스트를 통과했다고 보고하지 마.대규모 Codex 작업에서 꽤 재사용하기 좋은 형태다.
66. 가장 중요한 원칙
멀티 에이전트의 핵심을
Agent를 많이 띄운다.라고 생각하면 안 된다.
핵심은
독립적인 문제를 찾아낸다.
↓
책임을 분리한다.
↓
동시에 처리한다.
↓
증거가 있는 결과를 만든다.
↓
다시 통합하고 검증한다.이다.
Anthropic의 16-Agent Compiler 실험에서도 같은 문제가 드러났다.
독립 Test가 많을 때는 Agent Team이 매우 잘 작동했다.
반대로 모든 Agent가 같은 Kernel Compile Failure를 해결하려고 할 때는 Agent를 16개 사용해도 병렬화 효과가 거의 없었다.
병렬화 가능한 문제 구조를 만드는 것이 Agent 숫자보다 중요하다.
67. 마무리
GPT-5.6의 등장으로 Codex에서 멀티 에이전트를 사용하는 장벽은 상당히 낮아졌다.
예전에는 개발자가 직접
Agent Manager
Queue
Worker
Result Store
Git Worktree
Merge
Retry같은 시스템을 만들어야 했다.
지금은 Codex에서 여러 Agent 작업을 동시에 실행할 수 있고, GPT-5.6의 ultra를 이용하면 하나의 복잡한 작업 내부에서도 여러 Agent가 병렬 Workstream을 수행하도록 맡길 수 있다.
가장 기본적인 구조는 이것이다.
Coordinator
┌────────┼────────┐
│ │ │
Worker Worker Worker
│ │ │
└────────┼────────┘
Reviewer
│
Result하지만 중요한 것은 Agent 숫자가 아니다.
4 Agent
16 Agent
100 Agent가 중요한 것이 아니라
어디까지 독립적인가?
누가 무엇을 책임지는가?
같은 파일을 동시에 수정하지 않는가?
결과를 어떻게 검증하는가?
실패했을 때 어떻게 복구하는가?가 중요하다.
처음 사용하는 개발자라면 다음 순서로 시작하는 것을 추천한다.
Codex 하나
↓
Codex Task 두 개 병렬 실행
↓
복잡한 Task에서 GPT-5.6 ultra
↓
Planner / Worker / Reviewer 구조
↓
Worktree + Ownership
↓
Typed Handoff
↓
Budget / Trace / EvalClaude Code도 같은 방향으로 발전하고 있다.
다만 Anthropic 쪽에서는 Ultra라는 이름을 쓰는 것이 아니라
Subagents
Agent Teams
Dynamic Workflows
Fable 5 Long-horizon Agents를 통해 병렬 Agent 구조를 확장하고 있다.
한 줄로 정리하면 이렇다.
멀티 에이전트의 핵심은
AI 개발자를 많이 만드는 것이 아니라,
하나의 큰 문제를
동시에 풀 수 있는 독립적인 문제들로
잘 나누는 것이다.GPT-5.6 ultra와 Claude의 Dynamic Workflows가 흥미로운 이유도 여기에 있다.
이제 개발자는 Agent 한 명에게 일을 잘 시키는 것뿐 아니라,
어떤 작업은 혼자 깊게 생각하게 하고, 어떤 작업은 여러 Agent에게 나눠 동시에 처리하게 할지를 설계해야 한다.
참고 자료
-
OpenAI — GPT-5.6: Frontier intelligence that scales with your ambition
GPT-5.6의max와ultra차이, ultra의 기본 4-Agent 병렬 Coordination, Codex에서의 지원 범위를 확인할 수 있는 공식 발표 자료. -
OpenAI — Codex
Codex가 Worktree와 Cloud Environment를 이용해 여러 Coding Agent를 병렬로 실행하는 방식과 Codex 앱의 Multi-Agent Workflow 방향을 설명하는 공식 페이지. -
OpenAI — Introducing the Codex app
Codex 앱이 여러 Agent를 동시에 관리하고 서로 다른 프로젝트와 장시간 작업을 병렬 수행하도록 설계된 배경을 확인할 수 있는 공식 자료. -
Anthropic — Building a C compiler with a team of parallel Claudes
16개의 Claude Agent를 병렬로 운영해 Rust 기반 C Compiler를 구축한 실험과 Task 분할, Git 동기화, Test Harness, Agent 역할 분리에서 얻은 실제 교훈을 설명하는 Anthropic Engineering 글. -
Anthropic — Claude Fable 5
Fable 5가 장시간 Agent Harness에서 Planning, Subagent Delegation, 자체 검증을 수행하는 Long-horizon Model이라는 점을 확인할 수 있는 공식 자료. -
Anthropic — Claude Code Advanced Patterns / Dynamic Workflows
Claude Code의 Subagent, Parallel Agent, Agent Teams와 대규모 작업을 여러 Subagent로 분할하는 Dynamic Workflow 패턴을 확인할 수 있는 공식 자료.
핵심 참고 포인트
GPT-5.6의 ultra는 단순한 최고 reasoning effort가 아니다. OpenAI는 ultra를 여러 Agent가 병렬 Workstream을 수행하도록 Coordination하는 최고 Capability 설정으로 설명하며, 기본 구성에서는 4개 Agent가 병렬로 동작한다.
Codex에서는 GPT-5.6을 사용할 수 있는 Plus 이상 플랜에서 ultra를 이용할 수 있으므로 일반 Codex 사용자가 별도의 Responses API 코드를 작성하지 않아도 Multi-Agent Workflow를 사용할 수 있다.
또한 Codex 자체도 Worktree와 격리된 실행 환경을 이용해 여러 Coding Agent를 동시에 운영할 수 있도록 설계돼 있다. 따라서 여러 독립 Task를 병렬 실행하는 것과 하나의 큰 Task 내부를 ultra가 여러 Agent로 분할하는 것을 구분해서 이해하는 것이 좋다.
Anthropic에는 현재 OpenAI와 동일한 이름의 Claude Ultra Mode가 공식 기능으로 존재하지 않는다. 비교 대상으로는 Claude Code의 Subagents, Agent Teams, Dynamic Workflows가 더 정확하다.
Anthropic의 실제 Parallel Claude 실험 역시 Agent 수 자체보다 Task가 서로 독립적으로 분리될 수 있는지가 병렬 성능을 결정한다는 점을 보여준다.
