멀티에이전트는 이렇게 시작하면 된다 《3》
멀티에이전트는 이렇게 시작하면 된다
Codex와 Claude Code로 만드는 가장 단순한 구조
멀티에이전트를 처음 적용하려고 하면 구조부터 크게 그리기 쉽습니다.
Main Agent
├─ Coding Agent
├─ Test Agent
├─ Review Agent
├─ Security Agent
└─ Research Agent여기에 MCP Server를 붙이고 Skill을 만들고 Agent마다 Model과 권한까지 따로 설정합니다.
그런데 실제 Codex와 Claude Code에서는 처음부터 이렇게 만들 필요가 없습니다.
두 도구 모두 기본 Agent 자체가 이미
Repository 탐색
파일 수정
Shell 실행
Test
Git
Tool 호출을 처리할 수 있습니다.
멀티에이전트의 시작점은 Agent를 여러 개 만드는 것이 아닙니다.
하나의 Agent로 시작하고, Main Context가 불필요하게 커지거나 독립적으로 처리할 작업이 생길 때만 Subagent를 분리하는 것이 훨씬 자연스럽습니다.
전체 흐름을 먼저 보면 이렇습니다.
Single Agent
↓
Project Instructions
↓
Skills
↓
Subagents
↓
MCP
↓
독립 Runtime이 필요하면 A2ACodex와 Claude Code 모두 이 방향으로 구성할 수 있습니다.
1. 먼저 Single Agent로 시작한다
Codex라면 Repository에서 Codex를 시작하는 것만으로 기본적인 Agent 환경이 만들어집니다.
Codex
├─ 파일 읽기
├─ 코드 검색
├─ 파일 수정
├─ Shell 실행
├─ Build
└─ TestClaude Code도 비슷합니다.
cd MyProject
claude기본 구조는 다음과 같습니다.
Developer
↓
Coding Agent
↓
Repository
↓
Build / Test / Git처음부터 Test Agent나 Review Agent를 만들 이유가 없습니다.
우선 Main Agent 하나에게 실제 작업을 맡겨봅니다.
이 프로젝트의 인증 구조를 분석하고
로그아웃 시 Token이 제대로 삭제되는지 확인해줘.또는:
Swift 6 Concurrency Error를 확인하고
수정한 뒤 Test까지 실행해줘.이 상태에서 잘 처리된다면 Agent를 더 추가할 필요가 없습니다.
2. 프로젝트 공통 규칙부터 Agent에게 알려준다
Agent를 추가하기 전에 먼저 해야 할 일이 있습니다.
프로젝트 규칙을 명확하게 만드는 것입니다.
Codex에서는 AGENTS.md를 사용할 수 있습니다.
예를 들어 Repository Root에:
AGENTS.md를 두고 다음과 같은 규칙을 작성합니다.
# Project Rules
- Swift 6 strict concurrency를 유지한다.
- UI 변경은 SwiftUI를 우선한다.
- 새로운 Dependency 추가 전 반드시 확인한다.
- 수정 후 관련 Unit Test를 실행한다.
- UIKit 코드는 기존 모듈에서만 유지한다.Codex는 작업을 시작하면서 이 파일을 읽고 프로젝트 지침으로 사용합니다.
Claude Code에는 같은 역할을 하는 CLAUDE.md가 있습니다.
CLAUDE.md예를 들어:
# Development Rules
- 새로운 View는 SwiftUI로 작성한다.
- ViewModel은 @MainActor를 기본으로 한다.
- Repository Protocol은 Domain Module에 둔다.
- Test 없이 Business Logic을 변경하지 않는다.이렇게 하면 Agent에게 매번 긴 Prompt를 반복할 필요가 없습니다.
Developer
↓
짧은 요청
↓
AGENTS.md / CLAUDE.md
↓
프로젝트 규칙 반영멀티에이전트를 만들기 전에 먼저 이 단계부터 정리하는 것이 좋습니다.
3. 반복되는 작업은 Agent가 아니라 Skill로 만든다
개발하다 보면 계속 반복되는 요청이 생깁니다.
예를 들어:
Swift 6 Migration
Feature Module 생성
PR Review
Release 준비
Dependency Update같은 작업입니다.
매번 Prompt로 절차를 설명할 필요는 없습니다.
Codex와 Claude Code 모두 SKILL.md 기반의 Custom Skill을 지원합니다.
예를 들어 Swift 6 Migration Skill을 만든다고 해보겠습니다.
swift6-migration/
└─ SKILL.md내용은 다음 정도가 될 수 있습니다.
---
name: swift6-migration
description: Swift 6 concurrency 오류를 분석하고 수정할 때 사용한다.
---
# Workflow
1. 먼저 프로젝트를 Build한다.
2. Concurrency Diagnostic을 수집한다.
3. Sendable 문제를 분류한다.
4. Actor Isolation을 확인한다.
5. @MainActor 적용 여부를 검토한다.
6. 최소 범위만 수정한다.
7. Build한다.
8. 관련 Test를 실행한다.이제:
Swift 6 오류 고쳐줘.라고 요청하면 Agent가 해당 Skill을 선택할 수 있습니다.
구조가:
Main Agent
↓
Swift 6 Migration Skill
↓
Build / Search / Edit / Test이 됩니다.
별도의 SwiftMigrationAgent를 만들 필요가 없습니다.
4. Codex에서는 Skill을 프로젝트에 둘 수 있다
Codex는 Repository에서 Skill을 자동으로 찾을 수 있습니다.
프로젝트 전용 Skill이라면:
.agents/
└─ skills/
└─ swift6-migration/
└─ SKILL.md같은 식으로 둘 수 있습니다.
개인적으로 여러 프로젝트에서 사용하는 Skill이라면 사용자 범위에 둘 수도 있습니다.
Codex는 처음부터 모든 SKILL.md 내용을 Context에 넣지 않습니다.
먼저:
Skill Name
+
Description정도만 확인하고,
실제 작업과 관련 있다고 판단되면 전체 Skill을 읽습니다.
즉:
100개의 Skill이 있다고 해서 100개의 전체 Prompt가 모두 Context에 들어가는 구조는 아닙니다.
이 Progressive Disclosure가 Skill이 중요한 이유 중 하나입니다.
OpenAI 공식 문서에서도 Skill을 Codex와 ChatGPT에서 사용하는 재사용 가능한 Workflow 단위로 정의하고 있습니다.
5. Claude Code에서도 같은 방식으로 Skill을 만들 수 있다
Claude Code도 Custom Skill을 지원합니다.
프로젝트에서만 사용할 Skill은:
.claude/
└─ skills/
└─ ios-release/
└─ SKILL.md형태로 둘 수 있습니다.
사용자 전체에서 사용할 Skill은:
~/.claude/skills/에 둘 수 있습니다.
예를 들어 Release Skill이라면:
---
name: ios-release
description: TestFlight 배포를 준비할 때 사용한다.
---
1. working tree가 clean인지 확인한다.
2. release branch인지 확인한다.
3. test를 실행한다.
4. version과 build number를 확인한다.
5. archive를 생성한다.
6. TestFlight upload 전 사용자 승인을 받는다.구조는:
Claude Code
↓
Release Skill
↓
Git / Xcodebuild / Fastlane정도가 됩니다.
여기까지는 아직 멀티에이전트가 아닙니다.
하지만 대부분의 반복적인 개발 업무는 여기까지만으로도 상당 부분 처리할 수 있습니다.
6. 언제 Subagent를 추가해야 할까
Agent를 추가하는 기준은 역할 이름이 아닙니다.
Main Agent의 Context에서 분리했을 때 이득이 있는가가 더 중요합니다.
예를 들어 이런 요청이 있다고 해보겠습니다.
이번 PR을 검토하고
Architecture 문제와
테스트 누락,
최신 Apple API 사용 여부까지 확인해줘.Main Agent 하나가 전부 하면:
Repository 탐색
+
Architecture 분석
+
Test 분석
+
Apple 문서 조사
+
PR Diff가 모두 하나의 Context에 쌓입니다.
이럴 때 작업을 나누는 것이 좋습니다.
Main Agent
│
├─ Explorer
│ └─ 코드 구조 조사
│
├─ Test Reviewer
│ └─ 테스트 누락 조사
│
└─ Docs Researcher
└─ 최신 API 확인각 Subagent는 자기 Context만 사용하고 결과만 Main Agent에게 돌려줍니다.
7. Codex는 이미 Subagent Workflow를 기본 지원한다
현재 Codex에서는 Subagent Workflow가 기본적으로 활성화되어 있습니다.
기본 Agent도 제공됩니다.
대표적으로:
default
worker
explorer가 있습니다.
explorer는 읽기 중심 탐색에 적합하고,
worker는 구현과 수정 작업에 적합합니다.
예를 들어 이런 식으로 요청할 수 있습니다.
explorer agent를 사용해서
이 프로젝트의 인증 구조를 먼저 조사해줘.
동시에 다른 agent에게
관련 Unit Test가 어디까지 작성되어 있는지 확인시켜줘.
결과를 합쳐서 수정 계획만 만들어줘.그러면:
Main Codex
│
├─ Explorer #1
│ └─ Auth Architecture
│
└─ Explorer #2
└─ Tests형태로 병렬 작업을 수행하고 Main Agent가 결과를 합칩니다.
8. Codex의 Custom Agent도 프로젝트 단위로 만들 수 있다
자주 사용하는 Specialist가 있다면 직접 정의할 수도 있습니다.
프로젝트 범위에서는:
.codex/
└─ agents/
└─ security-reviewer.toml처럼 만듭니다.
개념적으로는:
name = "security_reviewer"
description = "Reviews code changes for security risks."
developer_instructions = """
Focus only on security issues.
Do not modify source files.
Inspect authentication, authorization,
secret handling, and network code.
Return evidence with file paths.
"""
sandbox_mode = "read-only"같이 구성할 수 있습니다.
이게 중요한 이유는 단순히 Prompt를 따로 저장할 수 있어서가 아닙니다.
Agent별로:
Model
Reasoning Effort
Sandbox
MCP Servers
Skills
Permissions를 다르게 구성할 수 있기 때문입니다.
9. Claude Code도 Custom Subagent를 만들 수 있다
Claude Code에서도 비슷한 구조를 사용할 수 있습니다.
가장 간단한 방법은:
/agents명령을 사용하는 것입니다.
여기서 Project-level 또는 User-level Custom Agent를 생성할 수 있습니다.
예를 들어:
security-reviewerAgent를 만들어:
Security 관련 코드만 분석한다.
Source Code는 수정하지 않는다.
Authentication
Authorization
Secret
Network Security
Dependency 위험만 확인한다.같은 역할을 줄 수 있습니다.
Claude의 Subagent는 Main Session과 별도의 Context Window를 사용합니다.
즉:
Main Context
│
├─ 구현 내용
├─ Conversation
└─ Planning
Security Agent Context
│
├─ Diff
├─ Security Files
└─ Security Rules처럼 Context를 분리할 수 있습니다.
Anthropic도 Subagent가 특히 유용한 영역으로 탐색, 코드 조사, 병렬 작업, Context Isolation을 강조하고 있습니다.
10. Subagent는 읽기 작업부터 병렬화하는 것이 좋다
처음 멀티에이전트를 쓰면서 흔히 하는 실수가 있습니다.
Agent 여러 개에게 동시에 코드를 수정시키는 것입니다.
Agent A
→ UserService.swift 수정
Agent B
→ UserService.swift 수정
Agent C
→ UserServiceTests.swift와
UserService.swift 수정이렇게 하면:
Merge Conflict
Context Mismatch
중복 구현
서로 다른 설계가 발생하기 쉽습니다.
Codex 공식 문서도 병렬 Subagent는 우선
Exploration
Test 분석
Triage
Summary같은 read-heavy 작업부터 사용하는 것을 권장합니다.
좋은 첫 번째 구조는:
Main Agent
│
├─ Explorer
├─ Test Analyzer
└─ Dependency Analyzer입니다.
그 결과를 Main Agent가 받은 뒤 실제 수정은 하나의 Worker가 담당합니다.
Explore in Parallel
↓
Main Agent Plan
↓
Single Writer구조가 충돌을 줄이기 쉽습니다.
11. Claude Code에서도 같은 원칙이 적용된다
Claude Code 역시 Subagent는 독립 Context를 사용합니다.
Anthropic은 큰 작업 중 발생하는 Side Task를 Subagent에게 보내는 방식을 대표적인 사용 사례로 설명합니다.
예를 들어 Main Claude가 Feature를 구현하고 있는데:
이 프로젝트에서 기존 OAuth Token Refresh는
어디서 처리하고 있지?라는 조사가 필요해졌다고 해보겠습니다.
Main Context에서 직접 탐색하면 수십 개 파일을 읽은 내용까지 Context에 쌓입니다.
대신 Explorer Agent에게 맡깁니다.
Main Claude
↓
Explore Agent
"OAuth Refresh 흐름만 조사해줘."Explorer는 독립적으로 파일을 읽고 최종적으로:
AuthService.swift
TokenRepository.swift
SessionManager.swift
Refresh 흐름은 ...정도만 돌려줍니다.
Main Context에는 탐색 과정 전체가 아니라 결론만 남게 됩니다.
이게 Subagent를 쓰는 가장 큰 장점 중 하나입니다.
12. Skill과 Subagent는 역할이 다르다
둘을 혼동하기 쉽습니다.
Skill은:
이 작업을 어떻게 해야 하는가를 정의합니다.
Subagent는:
이 작업을 누가 독립적으로 처리할 것인가를 정의합니다.
예를 들어:
Swift 6 Migration Skill은 절차입니다.
Swift 6 Migration Reviewer는 독립적인 Reasoning Worker입니다.
그래서:
Main Agent
↓
Migration Skill
↓
Tools로 충분하면 Agent를 추가하지 않습니다.
반대로 대규모 Repository를 먼저 분석해야 한다면:
Main Agent
↓
Migration Explorer Subagent
↓
Migration Skill처럼 둘을 같이 사용할 수도 있습니다.
13. Codex에서 외부 Tool은 MCP로 연결한다
Repository 밖의 시스템을 Agent가 사용하기 시작하면 MCP가 유용합니다.
예를 들어:
GitHub
Linear
Figma
사내 API
문서 검색
Database같은 시스템입니다.
Codex는 MCP Server를 직접 연결할 수 있습니다.
CLI에서는:
codex mcp를 이용해 관리할 수 있습니다.
개념적인 구조는:
Codex
│
├─ Local Tools
│
├─ Skills
│
└─ MCP
│
├─ GitHub
├─ Figma
└─ Internal Docs입니다.
MCP Server는 Tool뿐 아니라 Resource와 Prompt도 제공할 수 있습니다.
14. Claude Code 역시 MCP를 기본 지원한다
Claude Code에서도:
claude mcp명령을 통해 MCP Server를 구성할 수 있습니다.
구조는 동일합니다.
Claude Code
↓
MCP
↓
GitHub
Slack
Database
Browser
Internal API중요한 점은 Agent에게 외부 시스템 접근 권한을 줄 때 권한 범위를 명확하게 나누는 것입니다.
예를 들어:
GitHub Read
→ 자동 허용
PR Comment
→ 허용
Merge
→ 승인 필요
Production Deploy
→ 승인 필요같은 방식입니다.
Claude Code는 Tool별 Allow / Deny 규칙과 Permission Mode를 제공합니다.
Codex 역시 Sandbox와 Approval 설정을 통해 작업 범위를 제한할 수 있습니다.
멀티에이전트에서는 Agent마다 이 권한을 다르게 주는 것이 중요합니다.
15. Agent마다 같은 권한을 줄 필요는 없다
예를 들어 다음 구조가 있다고 해보겠습니다.
Main Coding Agent
Explorer Agent
Security Reviewer
Implementation Worker권한은 이렇게 나눌 수 있습니다.
Explorer
Read ⭕
Search ⭕
Edit ❌
Shell 제한Security Reviewer
Read ⭕
Scanner ⭕
Edit ❌Implementation Worker
Read ⭕
Edit ⭕
Build ⭕
Test ⭕Main Agent가 모든 권한을 가진다고 Subagent까지 전부 같은 권한을 가져야 하는 것은 아닙니다.
오히려 Agent 역할이 좁아질수록 권한도 좁히는 것이 좋습니다.
16. 실제 iOS 프로젝트라면 이런 구조부터 시작하면 된다
예를 들어 Swift 프로젝트가 있다고 해보겠습니다.
처음에는:
Codex / Claude Code
↓
Repository
↓
Build / Test / Git만 사용합니다.
반복적인 Swift 6 Migration이 생기면:
Main Agent
↓
Swift 6 Migration Skill을 추가합니다.
코드베이스 탐색이 Main Context를 너무 많이 사용하기 시작하면:
Main Agent
│
└─ Explorer Subagent를 추가합니다.
보안 리뷰를 독립적으로 하고 싶다면:
Main Agent
│
├─ Explorer
└─ Security Reviewer가 됩니다.
GitHub나 사내 CI가 필요하면:
Main Agent
│
├─ Skills
├─ Subagents
└─ MCP
├─ GitHub
└─ CI까지 확장합니다.
이 정도면 대부분의 개발팀에서 충분히 강력한 Multi-Agent 구조입니다.
17. Codex와 Claude Code에서 추천하는 첫 Multi-Agent 구조
처음부터 Agent를 다섯 개 만들기보다 이 정도가 좋습니다.
Main Coding Agent
│
┌─────────────┴─────────────┐
│ │
Explorer Security Reviewer
Read Only Read Only
│ │
└─────────────┬─────────────┘
↓
Main Agent
↓
Worker / Edit
↓
Build + Test핵심은:
탐색
→ 병렬
판단
→ Main
수정
→ 가능한 한 한 곳
검증
→ Build / Test입니다.
이 구조가 생각보다 중요합니다.
멀티에이전트의 목적은 동시에 많이 수정하는 것이 아니라 Main Context에서 독립적인 사고를 분리하는 것에 더 가깝기 때문입니다.
18. Agent를 더 만들기 전에 Skill인지 확인한다
다음과 같은 작업은 대부분 Agent가 필요하지 않습니다.
Release 준비
Swift 6 Migration 절차
Dependency Update
Lint Fix
Feature Module 생성
PR Checklist반복되는 절차가 있다면:
SKILL.md부터 만드는 것이 좋습니다.
반대로:
Repository Architecture 분석
대규모 코드 탐색
보안 위험 조사
장애 원인 탐색
기술 조사처럼 결과에 따라 다음 행동이 달라지는 작업은 Subagent 후보입니다.
기준은 간단합니다.
Procedure
↓
SkillIndependent Reasoning
↓
Subagent19. 같은 Runtime을 넘어서면 그때 A2A를 생각한다
Codex 내부 Subagent와 Claude Code Subagent는 기본적으로 같은 Agent 환경 안의 분업입니다.
하지만 이런 구조라면 이야기가 달라집니다.
개발팀
Codex Coding Agent
↓
???
↓
보안팀
Claude Security Agent보안팀 Agent는:
별도 Server
별도 Model
별도 Context
별도 Permission
별도 Deployment를 가지고 있을 수 있습니다.
이 경우 Main Codex의 Subagent로 볼 수 없습니다.
독립된 Agent System입니다.
여기서 A2A 같은 Agent-to-Agent Protocol이 의미를 갖습니다.
Codex Agent
↓
A2A
↓
Claude Security Agent처럼 서로 다른 Agent Runtime을 연결할 수 있습니다.
즉:
Codex Subagent
Claude Subagent
→ 같은 Runtime 내부의 분업과
A2A
→ 서로 독립된 Agent System 사이의 통신은 다른 문제입니다.
20. 처음부터 A2A까지 넣지 않는 게 좋다
처음 Agent 시스템을 만들면서:
Skills
MCP
Subagents
A2A
Workflow Engine
Vector DB
Long-term Memory를 모두 세팅하면 Architecture 자체가 개발 대상이 됩니다.
실제 Feature보다 Agent Infrastructure를 관리하는 일이 더 커질 수 있습니다.
그래서 다음 순서가 현실적입니다.
STEP 1
Codex / Claude Code
Single Agent↓
STEP 2
AGENTS.md / CLAUDE.md↓
STEP 3
반복 절차
→ Skills↓
STEP 4
Context 분리 필요
→ Subagents↓
STEP 5
외부 시스템
→ MCP↓
STEP 6
독립 Runtime
→ A2A이 순서면 필요하지 않은 복잡도를 미리 만들지 않아도 됩니다.
21. Codex와 Claude Code를 같이 쓰는 팀이라면 더 재미있어진다
실제 개발팀에서는 Codex와 Claude Code를 동시에 사용하는 경우도 있습니다.
예를 들면:
Codex
구현
Build
Test에 강하게 사용하고,
Claude Code
Repository 조사
Architecture Review
Documentation에 사용한다고 해보겠습니다.
처음에는 서로 독립적으로 써도 됩니다.
Developer
├─ Codex
└─ Claude Code굳이 둘을 서로 연결할 필요는 없습니다.
하지만 팀 수준에서 자동화를 만들기 시작하면:
Main Coding Workflow
│
├─ Codex Worker
│
└─ Claude Reviewer같은 구조가 생길 수 있습니다.
이 경우 중요한 것은 어떤 모델이 더 좋은가가 아닙니다.
각 Agent에게 어떤 Context와 권한, 역할을 줄 것인가가 중요합니다.
22. 멀티에이전트에서 가장 중요한 것은 Context 관리다
Agent가 하나일 때는 Context 문제가 덜 보입니다.
하지만 Subagent가 늘어나면 설계의 중심이 달라집니다.
나쁜 구조는:
Main Context
↓
Agent A 전체 전달
Agent B 전체 전달
Agent C 전체 전달입니다.
좋은 구조는:
Main Context
│
├─ Explorer
│ → 탐색에 필요한 정보만
│
├─ Reviewer
│ → Diff + 관련 코드만
│
└─ Worker
→ 수정 대상 + 계획만입니다.
그리고 Subagent가 돌아올 때도 전체 작업 로그를 반환하기보다:
결론
근거
파일 위치
추천 Action정도만 Main Agent에 전달하는 편이 좋습니다.
Codex 공식 문서에서도 Subagent가 중간 출력 전체보다 요약 결과를 Parent에 반환하도록 하는 방식을 권장합니다.
23. 멀티에이전트를 쓰면 Observability도 필요해진다
Agent가 하나일 때는 실패 원인을 찾기 쉽습니다.
Agent가 여러 개가 되면:
Main
↓
Explorer
↓
Main
↓
Reviewer
↓
Main
↓
Worker중 어디에서 문제가 생겼는지 확인해야 합니다.
최소한 다음 정보는 남기는 것이 좋습니다.
Agent
Task
Model
Duration
Tool Calls
Token
Result
Failure그리고 가능하면 전체 작업을 하나의 Trace로 봅니다.
Task #123
├─ Main
├─ Explorer
├─ Docs Research
├─ Worker
└─ TestAgent 수가 늘어날수록 Model 성능보다 운영 가능성이 중요해집니다.
24. 결국 설치보다 중요한 것은 어디서 나누느냐이다
Codex에서 Custom Agent를 만드는 것도 어렵지 않고,
Claude Code에서 /agents로 Subagent를 만드는 것도 어렵지 않습니다.
Skill 역시 SKILL.md 파일 하나로 시작할 수 있습니다.
MCP도 CLI에서 연결할 수 있습니다.
기술적인 설치 자체는 점점 쉬워지고 있습니다.
문제는 Architecture입니다.
왜 이 Agent가 따로 있어야 하는가?
왜 이 Context를 분리해야 하는가?
왜 이 Tool을 이 Agent만 사용해야 하는가?
왜 이 작업을 병렬로 실행해야 하는가?에 답할 수 있어야 합니다.
답이 없다면 Agent를 분리하지 않는 편이 나을 가능성이 높습니다.
25. 처음 구성한다면 이 정도면 충분하다
Codex든 Claude Code든 처음에는 이 구조 정도면 충분합니다.
Main Coding Agent
│
┌─────────────┴─────────────┐
│ │
Explorer Reviewer
Read Only Read Only
│ │
└─────────────┬─────────────┘
↓
Main
↓
Edit
↓
Build + Test여기에 프로젝트 규칙:
AGENTS.md
or
CLAUDE.md를 둡니다.
반복 절차는:
SKILL.md로 만듭니다.
외부 시스템이 필요해지면:
MCP를 추가합니다.
Agent 자체가 독립 서비스가 될 때만:
A2A를 고민합니다.
이 정도만 해도 상당히 탄탄한 멀티에이전트 환경을 만들 수 있습니다.
마치며
멀티에이전트를 시작한다고 해서 새로운 Agent Framework부터 설치할 필요는 없습니다.
이미 Codex나 Claude Code를 사용하고 있다면 그 환경에서 바로 시작할 수 있습니다.
처음에는:
1 Agent
+
Project Rules
+
Build / Test면 충분합니다.
반복되는 작업이 생기면 Skill을 추가합니다.
1 Agent
+
SkillsMain Context가 커지기 시작하면 Subagent를 추가합니다.
Main
+
Explorer
+
Reviewer외부 시스템이 필요하면 MCP를 연결합니다.
Agent
+
MCP그리고 서로 다른 팀이나 Runtime의 Agent가 실제로 독립된 서비스가 됐을 때 A2A를 고려합니다.
Agent
↓
A2A
↓
Independent Agent그래서 멀티에이전트 Architecture를 가장 단순하게 정리하면 다음과 같습니다.
Project Rules
↓
Single Agent
↓
Skills
↓
Subagents
↓
MCP
↓
A2A복잡도를 한꺼번에 넣는 것이 아니라 문제가 생기는 순서대로 하나씩 추가하는 것입니다.
Codex와 Claude Code 모두 이미 이 흐름을 상당 부분 지원하고 있습니다.
결국 좋은 멀티에이전트 환경은 Agent가 많은 환경이 아닙니다.
Main Context에는 중요한 판단만 남기고, 반복 절차는 Skill로, 독립적인 탐색은 Subagent로, 외부 기능은 MCP로 분리한 환경에 가깝습니다.
그리고 마지막 경계가 생겼을 때 A2A가 들어옵니다.
앞선 두 글까지 연결하면 구조도 깔끔하게 정리됩니다.
1편
Agent를 꼭 만들어야 하나?
→ Skill + MCP2편
Agent를 정말 분리해야 할 때는?
→ A2A3편
실제로 어떻게 시작할까?
→ Codex / Claude Code
→ Skill + Subagent + MCP이 세 편 정도면 멀티에이전트를 처음 구성할 때 필요한 개념부터 실제 운영 방향까지 한 번에 연결할 수 있습니다.
참고자료
-
OpenAI — Codex Subagents
Codex의 기본worker,explorerAgent, Custom Agent 설정, 병렬 Subagent Workflow, Agent별 Model·Sandbox·MCP·Skill 설정 방법을 확인할 수 있습니다.
Codex Subagents 공식 문서 -
OpenAI — Agent Skills
Codex의SKILL.md, Progressive Disclosure, 프로젝트 및 사용자 범위 Skill 설정 구조를 확인할 수 있습니다.
Codex Agent Skills 공식 문서 -
OpenAI — AGENTS.md
Repository와 사용자 범위에서 Codex에 지속적인 개발 규칙을 전달하는 방법을 확인할 수 있습니다.
Codex AGENTS.md 공식 문서 -
OpenAI — Codex MCP
Codex CLI·IDE·데스크톱에서 STDIO 및 Remote MCP Server를 연결하고 외부 Tool과 Context를 사용하는 방법을 확인할 수 있습니다.
Codex MCP 공식 문서 -
Anthropic — Claude Code Subagents
독립 Context를 사용하는 Claude Code Subagent의 사용 기준과 병렬 탐색, Context Isolation 전략을 확인할 수 있습니다.
Claude Code Subagent 공식 가이드 -
Anthropic — Claude Code Skills
.claude/skills/와~/.claude/skills/에 Custom Skill을 구성하는 방법을 확인할 수 있습니다.
Claude Agent Skills 공식 문서 -
Anthropic — Claude Code MCP
Claude Code와 외부 Tool 및 Data Source를 MCP로 연결하는 공식 구조를 확인할 수 있습니다.
Claude MCP 공식 문서
OpenAI 공식 문서 기준으로 보면, 현재 Codex는 Subagent Workflow가 기본 활성화되어 있으며 default, worker, explorer 같은 기본 Agent와 .codex/agents/ 기반 Custom Agent를 지원합니다. OpenAI는 특히 코드베이스 탐색, 테스트 분석, triage, summary처럼 읽기 비중이 높은 작업을 병렬 Subagent로 먼저 분리하고, 여러 Agent가 같은 코드를 동시에 수정하는 write-heavy 병렬 작업은 신중하게 사용할 것을 권장하고 있습니다.
Anthropic 역시 비슷한 기준을 제시합니다. Claude Code의 Subagent는 별도의 Context Window에서 작업하고 결과만 Main Conversation에 반환하기 때문에 코드 탐색이나 독립적인 조사 작업에서 특히 유용합니다. 반대로 단순하거나 Context 공유가 중요한 작업에서는 Subagent 생성 비용이 더 클 수 있습니다.
두 환경 모두 결국 같은 방향을 보여줍니다. 반복 절차는 Skill, 외부 기능은 MCP, 독립적인 Context가 필요한 작업은 Subagent로 분리하고, 서로 다른 Runtime과 조직 경계까지 넘어가는 순간에만 A2A 같은 분산 Agent Protocol을 고려하는 구조가 현재 가장 현실적인 멀티에이전트 시작점입니다.
