2026.03.26 업데이트
GPT-5.4 / GPT-5.4-mini 기준
Codex 서브에이전트, 병렬 실행이 오히려 비용을 불린 조건
OpenAI Codex에 서브에이전트 기능이 2026년 3월 16일 정식 출시됐습니다. “여러 에이전트가 동시에 일한다”는 말만 들으면 빠르고 저렴할 것 같습니다. 그런데 공식 문서를 직접 읽어보면 조건 하나가 눈에 들어옵니다. “각 서브에이전트는 자체 모델·도구 작업을 수행하므로 단일 에이전트 실행보다 토큰을 더 많이 소비합니다.” 병렬이라서 빠른 건 맞지만, 비용은 별개입니다.
서브에이전트란 — 왜 지금 중요한가
Codex 서브에이전트는 메인 에이전트가 복잡한 작업을 여러 조각으로 나눠 전문화된 하위 에이전트에게 위임하는 기능입니다. 2026년 3월 16일 GA(정식 출시) 됐고, 같은 달 26일 배포된 Codex CLI 0.117.0에서 path-based 주소 체계(/root/agent_a 형식)와 구조화된 에이전트 간 메시지 전달이 추가됐습니다. (출처: OpenAI Codex Changelog, 2026.03.26)
이 기능이 주목받는 핵심 이유는 컨텍스트 오염(Context Pollution)과 컨텍스트 부식(Context Rot) 문제를 해결하기 위해서입니다. 공식 문서에 딱 이렇게 나옵니다. “컨텍스트 오염은 유용한 정보가 노이즈 많은 중간 출력물에 묻혀버리는 현상이고, 컨텍스트 부식은 대화가 덜 관련성 높은 내용으로 채워지면서 성능이 저하되는 현상입니다.” 인증 로직을 리팩토링하는 에이전트가 40개 파일을 읽다 보면, 마지막 파일에 도달했을 때 처음 파일에서 파악한 패턴을 이미 “잊은” 것처럼 행동하는 게 바로 그 현상입니다.
서브에이전트는 각 하위 작업에 독립된 컨텍스트 창을 부여해 이 문제를 구조적으로 차단합니다. 인증 리팩토링 에이전트는 테스트 작성 에이전트와 컨텍스트를 공유하지 않습니다. 각자 집중합니다. 병렬 처리는 속도 이득이고, 컨텍스트 격리는 품질 이득입니다.
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다 — 서브에이전트의 진짜 가치는 “빠름”이 아니라 “긴 세션에서도 품질을 유지하는 것”입니다. Chroma Research의 컨텍스트 부식 연구에서 이 메커니즘을 설명합니다.
3가지 기본 에이전트와 역할 구분
Codex는 기본으로 3종의 내장 에이전트를 제공합니다. 커스텀 에이전트를 만들기 전에 이 3가지를 먼저 이해하는 게 맞습니다. (출처: OpenAI Codex Subagents 공식 문서)
| 에이전트명 | 역할 | 샌드박스 모드 | 적합한 작업 |
|---|---|---|---|
default |
범용 대체 에이전트 | 상속 | 일반 작업 전반 |
worker |
구현·수정 중심 실행 에이전트 | workspace-write | 코드 작성, 버그 수정 |
explorer |
읽기 전용 코드베이스 탐색 에이전트 | read-only | 코드 분석, 문서 조사 |
중요한 포인트는 샌드박스 모드입니다. explorer는 읽기 전용으로 강제되어 있어 코드베이스를 건드리지 않습니다. worker는 파일 쓰기가 가능하지만, 별도로 danger-full-access 모드를 선택하지 않는 한 외부 네트워크 접근은 제한됩니다. 쓰기 권한을 가진 에이전트 여러 개가 동시에 돌면 파일 충돌이 날 수 있습니다. 공식 문서는 이렇게 경고합니다. “병렬 쓰기 중심 워크플로에서는 에이전트 간 충돌과 조정 오버헤드가 증가할 수 있습니다.” 읽기 전용 병렬 실행부터 시작하는 게 안전합니다.
기본 에이전트 이름과 같은 이름으로 커스텀 에이전트 파일을 만들면 커스텀 에이전트가 우선 적용됩니다. 즉, 팀이나 프로젝트에 맞게 explorer의 행동을 완전히 덮어쓸 수 있습니다.
“병렬 = 저렴”이라는 공식이 깨지는 순간
솔직히 말하면, 서브에이전트가 출시된 직후 커뮤니티에서 가장 많이 올라온 게 비용 관련 불만이었습니다. GitHub OpenAI Codex Issue #12488에는 실사용자가 이렇게 올렸습니다. “Pro 플랜 주간 한도를 하루 이틀 만에 $350 이상 초과했다.” (출처: OpenAI Codex GitHub Issue #12488, 2026.02.21) 주간 Pro 한도를 하루 만에 날린 겁니다.
이게 왜 생기냐면, 공식 문서가 명확하게 밝힙니다. “서브에이전트 워크플로는 각 에이전트가 독립적으로 모델·도구 작업을 수행하기 때문에 단일 에이전트 실행보다 토큰을 더 많이 소비합니다.” 동시에 6개 에이전트가 돌면 토큰 소비도 최대 6배입니다. 빠른 건 맞지만, 그 속도가 비용을 분산시켜 주지는 않습니다.
agents.max_threads기본값은 6. 설정 없이 쓰면 동시 6개 스레드 비용 발생agents.max_depth기본값은 1. 이 값을 높이면 재귀적 서브에이전트 팬아웃으로 비용 급증- CSV 배치 처리(
spawn_agents_on_csv)는 행(row) 수만큼 에이전트를 병렬 실행하므로 비용 예측이 어려움 - 에이전트 실행 전 비용 표시 없음 — 계획 단계에서는 얼마가 나올지 미리 알 수 없음
실제로 비교해보면 차이가 뚜렷합니다. 동일한 Figma 플러그인 빌드 작업에서 Claude Code는 Codex보다 4.2배 많은 토큰(6,232,242 vs 1,499,455)을 썼고, 단순 스케줄러 앱에서도 3.2배 차이가 났습니다. (출처: Morph LLM Codex vs Claude Code 비교, 2026) 이 말은 Codex가 “더 저렴하다”는 뜻인데, 서브에이전트를 돌리면 그 이점이 빠르게 줄어듭니다. 토큰이 적게 드는 도구를 여러 개 동시에 실행하면, 총 비용은 결국 비슷하거나 더 높아질 수 있습니다.
현재 서브에이전트별 비용 내역은 실행 후에도 따로 확인할 방법이 없습니다. 이 점은 공식 이슈로 등록된 상태로, 이유는 아직 공개되지 않았습니다.
커스텀 에이전트 설정 — TOML 파일 구조
기본 에이전트 3종으로 충분하지 않을 때 커스텀 에이전트를 만듭니다. 개인용은 ~/.codex/agents/에, 프로젝트 전용은 .codex/agents/에 TOML 파일 하나를 추가합니다. 각 파일이 에이전트 하나를 정의합니다. (출처: OpenAI Codex Subagents 공식 문서)
필수 필드 3가지:
- name — Codex가 에이전트를 식별하는 기준. 파일명이 아니라 이 값이 우선입니다.
- description — Codex가 언제 이 에이전트를 써야 하는지 이해하는 안내문
- developer_instructions — 에이전트 행동 방식을 정의하는 핵심 지침
실제 PR 리뷰 예시 구성:
# .codex/agents/reviewer.toml
name = "reviewer"
description = "PR 리뷰어 — 정확성·보안·누락된 테스트 검토"
model = "gpt-5.4"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
코드 소유자처럼 검토합니다.
정확성, 보안, 동작 회귀, 누락된 테스트 커버리지를 우선합니다.
가능하면 재현 단계를 포함하고, 실제 버그를 숨기는 경우가 아니면
스타일 단독 코멘트는 피합니다.
"""모델 선택도 비용과 직결됩니다. 공식 문서 권장 사항은 이렇습니다. 대부분의 에이전트는 gpt-5.4로 시작하고, 빠른 스캔이나 대용량 파일 리뷰에는 gpt-5.4-mini를 씁니다. ChatGPT Pro가 있다면 텍스트 전용 빠른 반복에 gpt-5.3-codex-spark를 리서치 프리뷰로 사용할 수 있습니다. 탐색용 에이전트에 gpt-5.4를 붙이면 비용이 불필요하게 올라갑니다. 읽기 작업은 gpt-5.4-mini로도 충분합니다.
💡 공식 설정값과 실제 비용 흐름을 나란히 놓고 보니 이게 보였습니다 — agents.max_depth를 기본값 1에서 올리면 자식 에이전트가 손자 에이전트를 다시 생성하는 재귀 팬아웃이 생깁니다. 이 값은 절대로 특별한 이유 없이 올리지 말 것을 공식 문서가 직접 강조합니다. “토큰 사용량, 지연 시간, 로컬 리소스 소비의 비용과 예측 불가능성 위험이 증가합니다.”
Claude Code와 구조가 어떻게 다른가
서브에이전트 패턴 자체는 Codex만의 이야기가 아닙니다. Claude Code도 에이전트 팀(Agent Teams)을 지원하고, Gemini CLI도 서브에이전트를 정식 지원하기 시작했습니다. 업계 표준이 됐다고 해도 과언이 아닙니다. 막상 해보면 구조 차이가 꽤 다릅니다.
| 항목 | Codex (2026.03) | Claude Code (2026.03) |
|---|---|---|
| 격리 모델 | 클라우드 샌드박스 (컨테이너) | Git worktree (로컬) |
| 에이전트 간 통신 | 구조화된 메시지 (0.117.0~) | 직접 메시지 + 브로드캐스트 |
| 컨텍스트 창 | 약 400K 토큰 | 1M 토큰 (베타) |
| 태스크 의존성 추적 | 없음 (수동 조율) | 공유 태스크 목록 |
| 동시 실행 상한 | 기본 6개 (설정 가능) | 팀 크기 기반 |
| $20/월 플랜 메시지 수 | 5시간당 30~150개 | 동등 작업 시 더 빨리 소진 |
| 오픈소스 여부 | Apache-2.0 (Rust 기반) | 독점 CLI |
여기서 생각보다 덜 알려진 수치가 있습니다. SWE-bench Pro 기준 Codex가 56.8%, Claude Code가 55.4%로 Codex가 앞서는데, VS Code 확장 평점은 Codex 3.4/5 vs Claude Code 4.0/5입니다. (출처: Morph LLM Codex vs Claude Code 벤치마크 비교, 2026) 성능 지표가 앞선 도구의 만족도가 더 낮습니다. 개발자들이 도구에서 기대하는 건 벤치마크 점수가 아니라 “지시대로 따라와 주는 일관성”임을 보여주는 데이터입니다.
Codex가 유리한 상황은 독립적인 병렬 작업(탐색, 분석, CSV 배치 처리)이고, Claude Code가 유리한 상황은 서브태스크 간 의존성이 있는 복잡한 리팩토링입니다. 둘을 조합하는 게 실용적입니다. Codex로 빠르게 프로토타입을 만든 다음 Claude Code로 코드 리뷰를 돌리는 식입니다.
서브에이전트를 써야 할 때와 쓰지 말아야 할 때
공식 문서가 직접 제안하는 원칙입니다. “읽기 중심 작업(탐색, 테스트, 분류, 요약)에는 병렬 에이전트를 쓰고, 병렬 쓰기 중심 워크플로에는 주의하라.” 이 기준을 실전에 맞게 풀어보면 이렇습니다.
- PR 리뷰 포인트를 항목별로 병렬 검토
- 대규모 레거시 코드베이스 분석 (읽기 전용)
- 수십~수백 개 파일 보안 감사 (CSV 배치)
- 독립적인 마이크로서비스 여러 개 동시 탐색
- 문서·API 레퍼런스 병렬 조회
- 같은 파일을 여러 에이전트가 동시에 수정
- agents.max_depth를 1 이상으로 올린 경우
- 행 수가 많은 CSV 배치 처리 (비용 예측 어려움)
- 서브에이전트 간 순서 의존성이 있는 작업
- 비용 한도를 별도로 설정하지 않은 상태의 자동 실행
현재로서 가장 현실적인 안전장치는 agents.max_threads = 3으로 낮게 잡고 시작하는 겁니다. 기본값 6은 Pro 플랜 이상에서나 안전하게 쓸 수 있는 수준입니다. ChatGPT Plus($20/월) 사용자라면 서브에이전트 하나를 돌릴 때마다 5시간 메시지 한도가 단일 에이전트 대비 훨씬 빠르게 소진된다는 점을 기억할 필요가 있습니다. 한도 자체는 OpenAI가 공식 수치를 별도로 밝히지 않았습니다.
자주 묻는 질문 Q&A
마치며 — 총평
Codex 서브에이전트는 분명히 실용적입니다. 긴 코드베이스를 병렬로 탐색하거나 PR 리뷰 포인트를 동시에 처리하는 용도로는 기대 이상으로 작동합니다. 공식 문서가 제시한 PR 리뷰 예시처럼 explorer → reviewer → docs_researcher를 각자 독립된 컨텍스트에서 돌리는 구성은 컨텍스트 부식 문제를 실용적으로 해결합니다.
다만, “병렬이니까 빠르고 저렴하다”는 기대는 조건을 붙여야 맞는 말입니다. 각 에이전트가 독립적으로 모델을 호출하는 구조상 토큰 소비는 에이전트 수에 비례합니다. max_threads를 기본값인 6으로 두고 쓰면 단일 에이전트 대비 최대 6배 비용이 발생할 수 있습니다. 비용 내역도 현재는 실행 후 에이전트별로 확인할 수 없으니, 쓰기 전에 스스로 상한을 설정하는 게 필수입니다.
서브에이전트 패턴 자체는 이미 업계 표준이 됐습니다. Claude Code, Gemini CLI 모두 지원합니다. 지금부터는 “서브에이전트를 쓸 것이냐”가 아니라 “언제, 어떤 조건에서 쓸 것이냐”를 결정하는 단계입니다.
💡 개인적으로는 읽기 전용 탐색 작업에 먼저 써보는 걸 권합니다. 파일을 건드리지 않으니 충돌 걱정이 없고, max_threads를 2~3개로 제한하면 비용 예측도 가능해집니다. 여기서 감을 잡은 다음 쓰기 에이전트 조합으로 확장하는 순서가 현실적입니다.
📎 본 포스팅 참고 자료
- OpenAI Codex Subagents 공식 문서 (developers.openai.com)
- OpenAI Codex Subagents Concepts — Context Pollution & Context Rot
- OpenAI Codex Changelog — 2026.03.26 (CLI 0.117.0)
- GitHub Codex Issue #12488 — Sub-agent costs are too high and too opaque (2026.02.21)
- Morph LLM — Codex vs Claude Code 토큰 비용 벤치마크 비교 (2026)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Codex CLI는 빠른 속도로 업데이트되는 제품으로, 본문에 기재된 버전(0.117.0), 가격, 한도, 기능 사양은 이후 변경될 수 있습니다. 최신 정보는 OpenAI Codex Changelog에서 직접 확인하세요.
댓글 남기기