단일 모델의 시대는 끝났다: Claude와 Codex가 만드는 오케스트라
서론: 슈퍼 코더(Super Coder) 환상에서 벗어나기
우리는 종종 "모든 것을 다 해주는 만능 AI"를 꿈꿉니다. 기획부터 구현, 테스트까지 완벽하게 수행하는 단 하나의 에이전트. 하지만 현실은 냉혹합니다. LLM의 컨텍스트 윈도우는 제한적이고, 토큰 비용은 기하급수적으로 늘어나며, 복잡한 추론 과정에서 모델은 길을 잃기도 합니다.
이제는 '슈퍼 코더' 한 명에게 의지하는 것이 아니라, 각자 전문 분야를 가진 **'팀'**을 꾸려야 할 때입니다. 그 중심에 **Claude Code(오케스트레이터)**와 **Codex(실행가)**가 있습니다.
이번 포스팅에서는 Claude Code의 강력한 서브에이전트(Sub-agent) 기능을 활용하여, Codex CLI를 마치 손발처럼 부리는 에이전틱 워크플로우(Agentic Workflow)를 소개합니다.
1. 왜 Claude 혼자서는 안 되는가?
구조적 한계와 비용의 늪
Claude Code는 훌륭한 도구이지만, 모든 작업을 혼자 처리하려고 할 때 문제가 발생합니다.
┌─────────────────────────────────┐
│ Claude Code 세션 (오케스트레이터) │ ← Claude API 사용량 폭발 🔥
│ │
│ ┌───────────┐ ┌────────────┐ │
│ │ Read/Edit │ │ Codex MCP │ │ ← 도구 호출 비용 + 알파
│ └───────────┘ └────────────┘ │
└─────────────────────────────────┘
- 토큰 소모: 요청 이해, 도구 선택, 결과 종합 등 모든 과정에서 Claude API를 소비합니다. 단순한 구현 작업까지 Claude에게 맡기기엔 비용이 너무 비쌉니다.
- 단일 실패 지점(SPOF): Claude 사용량이 소진되거나 세션이 멈추면, 전체 작업이 중단됩니다.
- 전문성 부족: 때로는 특정 언어(Python, JS 등)에 특화된 모델이 범용 모델보다 더 나은 performance를 보여줍니다.
해결책: 역할을 나누자
오케스트레이션은 똑똑한 Claude에게 맡기고, 단순 반복적인 코딩이나 대규모 생성 작업은 빠르고 저렴한 Codex에게 위임하는 것. 이것이 바로 에이전틱 워크플로우의 핵심입니다.
2. 서브에이전트(Sub-agent): 나만의 작은 코딩 팀
Claude Code에는 Task 도구라는 강력한 기능이 있습니다. 이를 통해 메인 에이전트와는 별도로 동작하는 독립적인 에이전트 프로세스를 생성할 수 있습니다.
Task(
subagent_type="general-purpose",
prompt="runner.py의 보안 취약점만 집중적으로 분석해줘",
name="security-analyzer"
)
서브에이전트의 3가지 특징
- 독립성: 메인 에이전트의 컨텍스트를 오염시키지 않고 별도 프로세스에서 실행됩니다.
- 병렬성: 여러 서브에이전트를 동시에 실행시켜 시간을 단축할 수 있습니다.
- 전문성: 특정 작업(보안 분석, 테스트 생성 등)에만 집중하도록 프롬프트를 튜닝할 수 있습니다.
3. 실전 활용 패턴: 어떻게 조합할 것인가?
우리는 이 강력한 도구들을 어떻게 조합해야 할까요? 3가지 주요 패턴을 제안합니다.
패턴 1: 생성 → 검토 파이프라인 (The Pipeline)
가장 기본적인 형태입니다. Codex가 초안을 잡고, Claude가 검수합니다.
Claude (메인)
├─ Read (소스 코드 읽기)
├─ consult_codex_with_stdin (Codex에게 "이거 구현해봐" 위임)
└─ Edit (Codex의 결과물을 Claude가 검토 후 적용)
- 장점: Claude의 비싼 토큰을 아끼면서 고품질 코드를 얻을 수 있습니다.
- 단점: 순차적으로 진행되므로 시간이 조금 더 걸릴 수 있습니다.
패턴 2: 병렬 분석 (Parallel Analysis)
난해한 버그를 잡아야 할 때 유용합니다.
Claude (메인)
├─ Task(서브에이전트) → "네가 보기엔 이 코드 어디가 문제야?"
└─ consult_codex → "너는 이 함수 로직 좀 분석해봐"
│
└─ (두 천재의 의견을 종합하여 결론 도출)
- 장점: 다양한 관점(Perspective)을 통해 문제 해결 확률을 높입니다.
패턴 3: 테스트/보일러플레이트 대량 생산 (The Factory)
지루한 반복 작업은 Codex에게 던져버리세요.
Claude → 기존 테스트 코드 읽기
→ Codex에게 "나머지 엣지 케이스 테스트 100개 짜와" 위임
→ 생성된 테스트 실행 (pytest)
→ 실패한 것만 Claude가 수정
- 장점: 생산성이 폭발적으로 증가합니다. 인간 개발자는 기획과 검수에만 집중하면 됩니다.
4. 컨텍스트 격리: 서브에이전트의 진짜 가치
서브에이전트의 진정한 가치는 단순히 "작업을 나누는 것"이 아니라, 메인 에이전트의 컨텍스트를 깨끗하게 유지하는 것입니다.
"오염"의 정확한 의미
서브에이전트 없이 메인 에이전트가 직접 탐색하면 어떻게 될까요?
서브에이전트 없이 직접 탐색:
메인 컨텍스트에 쌓이는 것:
├─ Grep 결과 1 (200줄) ← 메인 컨텍스트 소비
├─ Grep 결과 2 (150줄) ← 메인 컨텍스트 소비
├─ 파일 읽기 1 (400줄) ← 메인 컨텍스트 소비
└─ ... 탐색할수록 계속 쌓임
→ 정작 중요한 작업을 할 때 컨텍스트 공간 부족 😱
서브에이전트에 위임:
서브에이전트 내부 (격리됨):
├─ Grep 결과, 파일 읽기 등 전부 처리
└─ 작업 끝나면 전부 버려짐
메인 컨텍스트에 돌아오는 것:
└─ "분석 결과: 3가지 취약점 발견..." ← 요약만!
핵심은 이겁니다: 서브에이전트는 새로운 빈 컨텍스트에서 시작합니다. 메인의 이전 대화나 파일 내용을 자동으로 알지 못합니다. 필요한 맥락은 prompt에 직접 넣어줘야 합니다.
5. 순차 vs 병렬: 언제 어떻게?
"서브에이전트는 병렬로 실행된다"는 말을 자주 듣지만, 실제로는 순차 실행이 기본입니다.
순차 (기본, 가장 흔함):
메인 ─── 위임 ──→ 서브에이전트 A
(대기 중...) 작업 수행 중...
메인 ←── 결과 반환 ─── 완료
메인 ─── 위임 ──→ 서브에이전트 B ← A 결과를 바탕으로
병렬 (특수한 경우):
메인 ─┬─ Task A (파일 A 분석) ──→ 결과 A ─┐
├─ Task B (파일 B 분석) ──→ 결과 B ─┼─→ 종합
└─ Task C (파일 C 분석) ──→ 결과 C ─┘
병렬 실행은 서로 의존성이 없는 독립 작업이 여러 개일 때만 가능합니다. 대부분의 실제 작업은 이전 결과에 따라 다음 단계가 달라지므로 순차가 맞습니다.
재미있는 점은, 사용자가 "병렬로 해"라고 지시할 필요가 없다는 것입니다. Claude Code든 OpenCode든, 모델이 작업의 의존성을 스스로 판단하여 순차/병렬을 자동 결정합니다.
6. 기술적 비교: 서브에이전트 춘추전국시대
현재 시장에 나와 있는 다른 에이전트들과 비교해 보았습니다.
| 도구 | 서브에이전트 지원 | 특징 |
|---|---|---|
| Claude Code | O | Task 도구로 네이티브 지원. 5개 타입, 중첩 가능 |
| OpenCode | O | 10개 내장 에이전트 + Sisyphus-Junior (카테고리별 동적 생성) |
| Codex CLI | X | 미구현 (GitHub 이슈에서 많은 요청 중) |
| Aider | X | Architect/Editor 모드만 존재 (순차 실행) |
| Cline | △ | 기본 CLI 서브프로세스만 가능 |
Claude Code vs OpenCode: 아키텍처 차이
두 도구 모두 사용자 경험은 비슷합니다 — 자연어로 지시하면 모델이 알아서 에이전트를 선택합니다. 하지만 내부 구조는 다릅니다:
Claude Code:
에이전트: 5개 타입 (general, explore, plan, bash, guide)
오케스트레이션: Claude 모델 하나가 모든 판단
서브에이전트 중첩: general-purpose만 가능
모델: Claude 전용
OpenCode (oh-my-opencode):
에이전트: 10개 내장 + Sisyphus-Junior (동적 생성)
오케스트레이션: Sisyphus가 Delegation Table 기반
서브에이전트 중첩: 불가 (재귀 방지)
모델: 75+ 프로바이더, 에이전트별 다른 모델 바인딩 가능
구성 요소가 많다고 해서 사용자가 더 많이 개입해야 하는 것은 아닙니다. 두 시스템 모두 "가능하면 병렬로 실행하라"고 모델에게 안내하고, 모델이 의존성을 판단해서 자동 결정합니다.
7. 딥 다이브: codex-mcp-bridge의 작동 원리
그렇다면 이 마법 같은 다리는 어떻게 만들어졌을까요? codex-mcp-bridge의 소스코드를 살펴보면, 복잡해 보이는 기능 뒤에 숨겨진 우아한 단순함을 발견할 수 있습니다.
아키텍처: FastMCP와 Subprocess의 만남
이 프로젝트의 핵심은 FastMCP 라이브러리와 파이썬의 subprocess 모듈의 결합입니다.
- FastMCP 서버:
server.py는FastMCP를 사용하여consult_codex와consult_codex_with_stdin이라는 두 가지 도구를 정의합니다. 이들은 Claude가 이해할 수 있는 명확한 스키마(Pydantic 모델)를 제공합니다. - 서브프로세스 래퍼:
runner.py는 실제로 Codex CLI를 실행하는 엔진입니다. 여기서 흥미로운 점은codex exec -명령어를 사용하여 표준 입력(stdin)으로 프롬프트를 주입한다는 점입니다.
핵심 트릭: 출력 캡처의 비밀
CLI 도구를 연동할 때 가장 골치 아픈 문제는 **'출력 캡처'**입니다. Codex CLI는 실행 중 다양한 로그를 쏟아내는데, 이를 그대로 Claude에게 보내면 문맥이 오염될 수 있습니다.
이 브리지는 **임시 파일(Tempfile)**을 사용하여 이 문제를 해결했습니다.
# runner.py의 핵심 로직 요약
with tempfile.NamedTemporaryFile() as output_file:
cmd = [
"codex", "exec", "-", # 표준 입력으로 프롬프트 받기
"--output-last-message", # 최종 답변만 별도 파일로 저장
str(output_file.name)
]
subprocess.run(cmd, input=query, ...)
# 깨끗한 최종 결과만 읽어서 반환
return output_file.read_text()
이 방식 덕분에 Claude는 지저분한 디버그 로그 없이 오로지 **'순수한 코드 결과물'**만을 받아볼 수 있습니다. 마치 주방의 소란스러움은 감추고 완성된 요리만 손님에게 내놓는 고급 레스토랑의 서빙 방식과 같습니다.
8. 직접 구현해보고 싶다면? (DIY Agent)
만약 Claude Code가 아닌 환경에서 서브에이전트를 구현하고 싶다면, 파이썬으로 간단한 오케스트레이터를 만들 수 있습니다.
# 400줄 미만으로 구현 가능한 미니 오케스트레이터 예시
class SubAgent:
def __init__(self, name, allowed_tools):
self.name = name
self.tools = allowed_tools
# ...
class Orchestrator:
def spawn_parallel(self, tasks):
# ThreadPoolExecutor로 에이전트 병렬 실행
# ...
LangGraph나 CrewAI 같은 프레임워크를 사용하면 더 복잡한 워크플로우도 쉽게 구현할 수 있습니다. 하지만 Claude Code에 내장된 기능을 쓰는 것이 정신 건강에 가장 이롭습니다.
결론: 바이브(Vibe)를 넘어 오케스트라로
"바이브 코딩"이 개발자의 감각을 중시했다면, **"에이전틱 코딩"**은 개발자의 지휘 능력을 중시합니다.
Claude라는 훌륭한 지휘자와 Codex라는 기민한 연주자를 활용하여, 여러분만의 소프트웨어 심포니를 완성해 보세요. 이제 코딩은 '타이핑'이 아니라 '위임'과 '조율'의 예술이 되었습니다.





