평소에 Codex랑 Cursor로 작업하는데, 인박스에 요약이 두 개 들어와서 궁금해졌어요. 하나는 Codex 서브에이전트 공식 지원, 하나는 gstack으로 Claude Code 역할 분리 워크플로 쓰기. 둘 다 “AI 코딩을 팀처럼 굴린다”는 얘기인데, 이게 진짜인지 직접 확인해봤습니다.
Quick Answer Codex 서브에이전트는 사용자가 명시적으로 요청할 때만 여러 전문 에이전트를 병렬로 띄우고, gstack은 10개 이상의 역할별 슬래시 명령으로 같은 모델을 상황별 사고 모드로 전환한다. 둘을 조합하면 PR 리뷰 위임, 프론트엔드 디버깅, CSV 배치 작업까지 팀플레이처럼 굴릴 수 있다.
이 글이 필요한 사람
Codex나 Claude Code로 개발하는데 단일 에이전트의 한계를 느낀 분들. PR 리뷰를 여러 관점(보안, 성능, 테스트)으로 나눠서 보고 싶거나, 프론트엔드 버그 디버깅을 재현·추적·수정 단계로 분리하고 싶거나, CSV로 대량 반복 작업(마이그레이션 점검, 컴포넌트 리뷰)을 자동화하려는 분들에게 실전 설정 가이드를 제공합니다.
지금 결론
Codex 서브에이전트는 2026년 3월 OpenAI가 공식 지원하는 기능으로, 복잡한 작업을 여러 전문 에이전트로 병렬 분배하고 결과를 하나의 응답으로 수집한다. 역할 분리형 워크플로가 해결하는 문제는 단일 에이전트가 “설계·구현·리뷰·QA”를 한꺼번에 하다 보니 컨텍스트가 오염되고, 품질 편차가 커지는 것이다. 에이전트 팀은 SWE-bench Verified에서 단일 에이전트 대비 7.2%p 높은 72.2% 해결률을 기록했다(Agyn, 2026). 대신 토큰 비용은 3~7배 수준으로 늘어난다.
쉽게 말하면, 한 사람이 기획·코딩·리뷰·QA 다 하는 게 아니라, 역할별로 다른 “사람”이 맡는 구조다. 근데 그 “사람”이 다 AI라서, 한 터미널에서 팀 회의하는 느낌이 난다.
1. Codex 서브에이전트 핵심 개념
1.1 명시적 호출 vs 자동 난입
Codex 서브에이전트의 첫 번째 특징은 자동으로 안 띄운다는 거예요. 사용자가 “이 작업은 A, B, C 에이전트한테 맡겨줘”라고 명시적으로 요청할 때만 생성된다.
왜 이렇게 만들었을까? 자동으로 에이전트를 마구 띄우면 토큰이 폭발한다. 각 에이전트가 자기 모델 호출과 도구 사용을 하니까, 단일 에이전트 대비 3~7배 수준으로 비용이 늘어난다. 그래서 “진짜 병렬 가치가 있는 작업”에만 쓰라고 공식 문서도 강조한다.
실제로 쓰는 예시는 이렇게 된다.
이 PR을 main과 비교해서 리뷰해줘. 다음 항목별로 에이전트 하나씩 띄우고, 다 끝나면 요약해줘. 1. 보안 이슈 2. 코드 품질 3. 버그 4. 레이스 컨디션 5. 테스트 플레이키니스 6. 유지보수성
이렇게 쓰면 Codex가 6개 에이전트를 병렬로 띄우고, 각자 결과를 내면 하나로 합쳐서 보여준다.
1.2 기본 내장 에이전트 3종
Codex는 기본으로 3가지 에이전트를 제공한다.
| 에이전트 | 역할 | 용도 |
|---|---|---|
default | 범용 | 일반적인 작업, 폴백 |
worker | 실행 중심 | 구현, 수정, 코드 변경 |
explorer | 읽기 중심 | 코드베이스 탐색, 증거 수집 |
explorer는 read-heavy 작업에 맞춰져 있고, worker는 실제 코드를 고치는 쪽이다. default는 뭘 쓸지 모르겠을 때 쓰는 기본값이다.
1.3 커스텀 에이전트 TOML 구조
개인용은 ~/.codex/agents/, 프로젝트용은 .codex/agents/ 아래에 TOML 파일을 두면 된다. 파일 하나당 에이전트 하나.
필수 필드 3개:
name: Codex가 스폰할 때 쓰는 식별자description: 이 에이전트를 언제 쓸지 사람이 읽는 설명developer_instructions: 실제 동작을 정의하는 핵심 지시문
선택 필드: model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config, nickname_candidates 등. 생략하면 부모 세션 설정을 그대로 따른다.
예시는 이렇게다.
name = "reviewer" description = "PR 리뷰에 집중. 정확성, 보안, 누락된 테스트를 찾는다." developer_instructions = """ 코드를 오너처럼 리뷰해라. 정확성, 보안, 동작 회귀, 누락된 테스트 커버리지를 우선한다. 구체적인 발견을 먼저 쓰고, 재현 단계가 있으면 포함한다. 스타일만의 코멘트는 진짜 버그가 숨어있을 때만. """ nickname_candidates = ["Atlas", "Delta", "Echo"]
nickname_candidates는 같은 에이전트를 여러 개 띄울 때 UI에서 구분하기 위한 표시 이름이다. 실제 식별은 name으로 한다.
1.4 컨텍스트 오염·부패(Context Rot) 해결
단일 에이전트가 “설계 + 구현 + 리뷰 + QA”를 한 세션에서 다 하면, 컨텍스트가 섞여서 품질이 떨어진다. 설계할 때 쓰던 가정이 구현 단계에서 바뀌었는데, 리뷰할 때는 또 다른 맥락을 보고 있을 수 있다.
서브에이전트는 역할별로 컨텍스트를 분리한다. pr_explorer는 코드 경로만 추적하고, reviewer는 리스크만 본다. docs_researcher는 문서 MCP로 API 확인만 한다. 각자 자기 일만 하니까 컨텍스트가 덜 오염된다.
2. gstack 역할 분리 워크플로
2.1 gstack이 뭐냐면
gstack은 Y Combinator CEO인 Garry Tan이 2026년 3월 공개한 오픈소스다. Claude Code를 “만능 비서”가 아니라 10개 이상의 역할별 슬래시 명령으로 바꿔주는 스킬 팩이다. GitHub 20,000+ 스타, MIT 라이선스, 무료다.
참고: GitHub README는 “10 opinionated tools”라고 표기하고, 일부 리뷰에서는 13개 specialist로 언급된다. 실제 사용 가능한 명령은
/plan-ceo-review,/plan-eng-review,/plan-design-review,/design-consultation,/review,/ship,/browse,/qa,/retro,/document-release등 10개 이상이다.
핵심은 같은 모델을 상황별 사고 모드로 전환하는 거예요. /plan-ceo-review를 치면 CEO처럼 제품을 재정의하고, /review를 치면 스태프 엔지니어처럼 프로덕션 리스크를 찾는다. /qa를 치면 QA 리드처럼 실제 브라우저를 열고 클릭해본다.
2.2 주요 명령과 역할 페르소나
| 명령 | 역할 | 하는 일 |
|---|---|---|
/plan-ceo-review | CEO/Founder | 문제 재정의, 10스타 제품 찾기, 4모드(확장/선택적 확장/범위 유지/축소) |
/plan-eng-review | 엔지 매니저 | 아키텍처, 데이터 플로우, 다이어그램, 엣지 케이스, 테스트 매트릭스 |
/plan-design-review | 시니어 디자이너 | 80항목 디자인 감사, AI Slop 탐지, 디자인 시스템 추론. 코드 건드리지 않음 |
/design-consultation | 디자인 파트너 | 디자인 시스템 처음부터 구축, 리스크 제안, 실제 제품 목업 생성 |
/review | 스태프 엔지니어 | CI 통과하지만 프로덕션에서 터지는 버그 찾기. 자동 수정 + 플래그 |
/ship | 릴리스 엔지니어 | main 동기화, 테스트, 커버리지 감사, 푸시, PR 오픈. 테스트 프레임워크 없으면 부트스트랩 |
/browse | QA 엔지니어 | 실제 Chromium 브라우저, 실제 클릭, 스크린샷. 명령당 ~100ms |
/qa | QA 리드 | 앱 테스트, 버그 찾기, 원자 커밋으로 수정, 재검증. 수정마다 회귀 테스트 생성 |
/qa-only | QA 리포터 | /qa와 같은 방법론이지만 리포트만. 코드 변경 없음 |
/qa-design-review | 코딩하는 디자이너 | /plan-design-review 감사 후 수정. 원자 커밋, before/after 스크린샷 |
/setup-browser-cookies | 세션 매니저 | Chrome, Arc, Brave, Edge 쿠키를 헤드리스 세션으로 가져옴 |
/retro | 엔지 매니저 | 팀 단위 주간 회고. 인당 분해, 배포 스트릭, 테스트 헬스 트렌드 |
/document-release | 테크 라이터 | 방금 배포한 내용에 맞춰 프로젝트 문서 전부 업데이트 |
2.3 인지 모드 전환(Cognitive Mode Switching)
gstack의 철학은 “한 에이전트가 다 하는 게 아니라, 지금 뭘 하느냐에 따라 다른 머리를 쓰는 것”이다.
기획할 때는 CEO처럼 “이거 진짜 필요한 기능이야?”를 묻고, 구현할 때는 엔지니어처럼 “이 플로우가 맞아?”를 묻고, 리뷰할 때는 “프로덕션에서 터질 부분이 있어?”를 묻는다. QA할 때는 “실제로 브라우저 열어서 눌러봐”를 한다.
이걸 슬래시 명령 하나로 바꾸는 거다. /plan-ceo-review 치면 그 순간부터 CEO 모드.
2.4 6단계 워크플로 패턴
gstack README에 나온 예시 흐름은 이렇다.
- 기획 검토 (
/plan-ceo-review) — “사진 업로드”가 아니라 “셀러가 실제로 팔리는 리스팅을 만드는 것”이 진짜 작업이다 - 설계 검토 (
/plan-design-review) — 80항목 감사, AI Slop 점수, DESIGN.md 추출 - 아키텍처 검토 (
/plan-eng-review) — 데이터 플로우, ASCII 다이어그램, 테스트 매트릭스 - 구현 — “플랜 승인. 플랜 모드 종료” 하면 Claude가 2,400줄 across 11 files 작성 (~8분)
- 리뷰 (
/review) — 고아 S3 클린업, 누락 인덱스 자동 수정, 레이스 컨디션 플래그 - QA (
/qa) — 실제 브라우저로 스테이징 접속, 업로드→분류→enrich→draft 플로우 검증, 버그 발견 시 수정 + 회귀 테스트 생성 - 배포 (
/ship) — 테스트, 커버리지, PR 오픈
한 기능에 명령 7개. 에이전트가 제품을 재정의하고, 80항목 디자인 감사하고, 아키텍처 그리고, 2,400줄 짜고, 레이스 컨디션 찾고, 브라우저로 QA하고, PR 연다. “이건 코파일럿이 아니라 팀”이라고 README에 적혀 있다.
2.5 네이티브 브라우저 자동화 (MCP 아님)
gstack의 /browse, /qa는 MCP가 아니라 자체 바이너리로 Chromium을 띄운다. 장시간 살아있는 헤드리스 Chromium 데몬을 두고, 명령마다 새 브라우저를 띄우지 않는다. 그래서 쿠키, localStorage, 로그인 상태가 유지되고, 콜드 스타트 3~5초 대신 이후 호출은 ~100~200ms 수준이다. 30분 idle 후 자동 종료.
3. 실전 설정 가이드
3.1 설치 단계
Codex 서브에이전트: 2026년 3월 현재 Codex 릴리스에서 기본 활성화돼 있다. 별도 설치 없음.
gstack 설치 (Claude Code 기준):
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack cd ~/.claude/skills/gstack && ./setup
그 다음 CLAUDE.md에 gstack 섹션을 추가한다. 웹 브라우징은 gstack의 /browse를 쓰고, mcp__claude-in-chrome__* 도구는 쓰지 말라고 명시. 사용 가능한 스킬 목록을 적어둔다.
프로젝트에 넣으려면:
cp -Rf ~/.claude/skills/gstack .claude/skills/gstack rm -rf .claude/skills/gstack/.git cd .claude/skills/gstack && ./setup
그리고 해당 프로젝트의 CLAUDE.md에도 gstack 섹션을 추가한다.
3.2 커스텀 에이전트 TOML 예시
reviewer (PR 리뷰):
name = "reviewer" description = "PR 리뷰. 정확성, 보안, 누락 테스트에 집중." model = "gpt-5.4" model_reasoning_effort = "high" sandbox_mode = "read-only" developer_instructions = """ 코드를 오너처럼 리뷰해라. 정확성, 보안, 동작 회귀, 누락된 테스트 커버리지를 우선한다. 구체적인 발견을 먼저 쓰고, 재현 단계가 있으면 포함한다. 스타일만의 코멘트는 진짜 버그가 숨어있을 때만. """
docs_researcher (문서 전문):
name = "docs_researcher" description = "문서 MCP로 API·프레임워크 동작 검증." model = "gpt-5.4-mini" model_reasoning_effort = "medium" sandbox_mode = "read-only" developer_instructions = """ 문서 MCP 서버로 API, 옵션, 버전별 동작을 확인해라. 간결한 답변에 링크나 정확한 참조를 포함한다. 코드 변경은 하지 않는다. """ [mcp_servers.openaiDeveloperDocs] url = "https://developers.openai.com/mcp"
3.3 글로벌 설정
config.toml 또는 .codex/config.toml의 [agents] 섹션:
[agents] max_threads = 6 # 동시 열린 에이전트 스레드 상한 max_depth = 1 # 스폰 깊이 (0=루트, 1=직계 자식만) job_max_runtime_seconds = 1800 # spawn_agents_on_csv 워커당 기본 타임아웃
max_depth = 1이면 자식 에이전트가 또 에이전트를 띄우는 건 막는다. max_threads 기본값은 6이다.
3.4 다중 세션 병렬 운영
gstack README는 “한 세션으로도 강하지만, 10개 세션이면 완전히 다르다”고 한다. Conductor로 여러 Claude Code 세션을 병렬로 돌리면, 각 세션마다 격리된 워크스페이스와 브라우저 상태를 가진다. 한 세션은 스테이징에서 /qa, 다른 세션은 PR에서 /review, 또 다른 세션은 기능 구현. 한 사람이 10개 병렬 에이전트, 각각 맞는 인지 모드. “다른 방식으로 소프트웨어를 만드는 것”이라고 적혀 있다.
4. Codex + gstack 조합 패턴
4.1 PR 리뷰 위임
Codex 서브에이전트로 PR 리뷰를 역할별로 나눌 수 있다.
이 브랜치를 main과 비교해서 리뷰해줘. pr_explorer가 영향 받는 코드 경로를 매핑하고, reviewer가 실제 리스크를 찾고, docs_researcher가 이 패치가 의존하는 프레임워크 API를 문서로 확인해줘.
pr_explorer, reviewer, docs_researcher는 위 TOML 예시처럼 .codex/agents/에 정의해두면 된다. 각자 read-only 샌드박스에서 자기 일만 한다.
gstack의 /review는 “한 에이전트가 리뷰 전부”를 하는 방식이다. Codex 서브에이전트는 “리뷰를 3명이 나눠서” 하는 방식. 복잡한 PR이면 서브에이전트가, 단순한 수정이면 /review가 더 맞을 수 있다.
4.2 프론트엔드 디버깅 패턴
OpenAI 공식 문서에 나온 패턴이다. UI 회귀, 플레이키한 브라우저 플로우, 앱 코드와 실행 중인 제품을 넘나드는 통합 버그에 쓴다.
설정 모달이 저장이 안 돼. 원인 조사해줘. browser_debugger가 브라우저로 재현하고, code_mapper가 관련 프론트/백엔드 코드 경로를 찾고, ui_fixer가 이슈가 명확해지면 최소 수정만 해줘.
browser_debugger는 Chrome DevTools MCP를 쓰고, code_mapper는 read-only로 코드만 추적한다. ui_fixer는 수정만 담당한다. 역할이 분리돼 있어서 “재현”과 “수정”이 한 컨텍스트에 섞이지 않는다.
gstack의 /qa는 “브라우저 열고 클릭해서 버그 찾고, 고치고, 회귀 테스트까지” 한 에이전트가 한다. Codex 서브에이전트는 “재현 / 경로 추적 / 수정”을 3명이 나눈다. 복잡한 버그일수록 분리가 유리하다.
4.3 CSV 배치 워커 패턴
spawn_agents_on_csv는 실험적 기능이다. CSV 각 행을 작업 단위로 삼아, 행마다 워커 에이전트를 띄우고, 결과를 CSV로 내보낸다.
예시:
/tmp/components.csv를 만들어줘. 컬럼은 path, owner고, 프론트엔드 컴포넌트당 한 행.
그 다음 spawn_agents_on_csv 호출해줘:
- csv_path: /tmp/components.csv
- id_column: path
- instruction: "{path}를 {owner}가 소유한 컴포넌트로 리뷰해. report_agent_job_result로 path, risk, summary, follow_up JSON 반환"
- output_csv_path: /tmp/components-review.csv
- output_schema: path, risk, summary, follow_up (string 필수)
대량 리뷰, 마이그레이션 점검, 구조화된 요약 작업에 적합하다. agents.job_max_runtime_seconds로 워커당 타임아웃을 줄 수 있다(기본 1800초).
4.4 토큰 비용 고려
에이전트 팀은 단일 에이전트보다 3~7배 토큰을 쓴다. 각 에이전트가 자기 모델 호출과 도구를 쓰기 때문이다. SWE-bench 72.2% 해결률이 토큰을 아끼고 나온 숫자가 아니다.
그래서 “진짜 병렬 가치가 있는 작업”에만 쓰는 게 맞다. 코드베이스 탐색, PR 리뷰, 다단계 기능 작업처럼 병렬성이 큰 일. 단순한 수정 하나면 단일 에이전트가 더 싸고 빠르다.
5. 실수 TOP 5
5.1 Don’t: 뭐든지 서브에이전트로 돌리기
토큰이 3~7배 나간다. “이거 한 줄 고쳐줘” 수준에 에이전트 6명 띄우면 낭비다. 병렬로 나눌 만한 작업에만 써라.
5.2 Don’t: 품질 게이트 건너뛰기
역할 분리가 있어도, lint/typecheck/test 같은 게이트를 안 두면 품질이 흔들린다. SDD 가이드에서 말하듯, “역할 경계 + 품질 게이트”를 같이 둬야 한다.
5.3 Don’t: 컨텍스트 격리 필요성 무시하기
에이전트 A가 B의 컨텍스트를 오염시키면 의미가 없다. read-only 에이전트는 정말 읽기만 하게 두고, 수정 에이전트는 최소 범위만 건드리게 instructions를 짜라.
5.4 Do: 작은 실험부터 시작하기
처음엔 서브에이전트 2~3개만 정의하고, PR 리뷰 한 번만 돌려보라. gstack도 /plan-ceo-review 하나만 붙여서 써보는 게 좋다. 다 붙이면 부담된다.
5.5 Do: 오케스트레이션 오버헤드 모니터링하기
에이전트가 많아질수록 “누가 뭘 했는지”, “어디서 막혔는지” 추적이 어려워진다. Codex 앱/CLI에서 에이전트 활동이 보이니까, 비용·시간·품질을 같이 보면서 조정하라.
6. 내가 느낀 점
읽으면서 충격받은 건 두 가지였다.
첫째, Garry Tan이 60일 동안 60만 줄 이상 프로덕션 코드를 짰다는 거다. 35%가 테스트고, 하루 1~2만 줄 usable LOC를 CEO 일 하면서 part-time으로 했다고 한다. 2026년 GitHub 기여 1,237개 vs 2013년 Bookface 만들 때 772개. 같은 사람인데 도구가 다르니까 차이가 나는 거다.
둘째, 에이전트 팀이 단일 에이전트보다 7.2%p 더 잘 푼다는 SWE-bench 결과다. 72.2% vs 65% 수준. “역할 나누면 품질이 오른다”가 벤치마크로 나온 거다.
그래서 내가 던진 질문은 이거였다. “나는 어떻게 해야 하지? 지금처럼 Codex 단독으로만 써도 되는 건가?”
결론은 “상황에 따라”다. 작은 범위, 단일 레포, 빠른 프로토타이핑이면 Codex 단독이 맞다. SDD 가이드에서도 “작은 범위/단일 레포: Codex 단독이 가장 빠르다”고 했다. 반대로 PR 리뷰를 여러 관점에서 보고 싶거나, 프론트엔드 버그를 재현·추적·수정으로 나눠서 하고 싶거나, CSV로 대량 작업을 돌리고 싶으면 서브에이전트가 맞다.
gstack은 “역할 전환”을 슬래시 하나로 해주는 거라, Codex 서브에이전트와는 레이어가 다르다. gstack은 Claude Code용이고, Codex는 OpenAI 쪽이다. 둘 다 “팀처럼 굴린다”는 점은 같다.
7. 솔직한 마음과 방향
불안한 점도 있다. 에이전트가 많아지면 “누가 뭘 했는지” 추적이 어렵고, 토큰 비용이 눈에 보이게 늘어난다. 그리고 “이게 맞나?” 싶을 때가 있다. 서브에이전트 6명 띄워서 PR 리뷰하는 게, 그냥 한 번에 리뷰하는 것보다 진짜 나은지?
방향은 이거다. 작은 실험 단위로 검증하는 것. PR 하나만 서브에이전트로 리뷰해보고, 품질이랑 비용을 비교해보라. gstack이면 /plan-ceo-review 한 번만 붙여서, 기획 단계에서 “진짜 필요한 기능이 뭐지?”를 한 번 더 묻게 해보라. 그걸로 충분한지, 더 확장할지 결정하면 된다.
8. 앞으로 내가 할 것들
.codex/agents/에 reviewer, docs_researcher 2개만 만들어서, 다음 PR 하나에 서브에이전트 리뷰를 돌려본다. 품질이랑 토큰 사용량을 메모한다.- **gstack
/plan-ceo-review**를 블로그 파이프라인 기획에 한 번 써본다. “이 글감이 진짜 10스타인가, 3스타인가”를 먼저 묻게 해보는 거다. - spawn_agents_on_csv는 당장은 안 쓴다. 반복 작업이 생기면 그때 CSV로 쪼개서 실험해보겠다.
- 비용 모니터링을 한다. 서브에이전트 쓸 때마다 대략적인 토큰/비용을 적어두고, “이 정도 작업에 이 정도 비용” 패턴을 파악한다.
FAQ
Q: Codex 가격은 어떻게 되나요?
A: Codex는 OpenAI 플랫폼 요금제를 따른다. 2026년 3월 기준 모델별로 다르고, 서브에이전트는 에이전트 수만큼 호출이 늘어나서 단일 에이전트 대비 3~7배 수준으로 비용이 올라갈 수 있다. 정확한 요금은 OpenAI Pricing에서 확인하라.
Q: gstack은 무료인가요?
A: 네. MIT 라이선스 오픈소스로, 무료다. Claude Code와 Bun이 필요하다. Garry Tan이 “프리미엄 티어 없음, 대기자 명단 없음, 조건 없음”이라고 README에 적어뒀다.
Q: Codex 서브에이전트와 gstack을 같이 쓸 수 있나요?
A: Codex는 OpenAI, gstack은 Claude Code용이라 같은 세션에서 “동시에” 쓰는 건 아니다. 다만 워크플로 개념은 통한다. Codex로 서브에이전트 PR 리뷰를 하고, Claude Code + gstack으로 기획·QA를 하는 식으로 툴을 나눠 쓸 수 있다.
Q: spawn_agents_on_csv는 언제 쓰나요?
A: 대량 리뷰(파일/패키지/서비스별), 마이그레이션 점검, 구조화된 요약 작업처럼 “CSV 한 행 = 작업 하나”로 매핑되는 반복 작업에 쓴다. 실험적 기능이라 나중에 API가 바뀔 수 있다.
Q: max_threads, max_depth는 뭔가요?
A: max_threads는 동시에 열 수 있는 에이전트 스레드 상한(기본 6). max_depth는 스폰 깊이로, 1이면 루트의 직계 자식만 허용하고 그 자식이 또 에이전트를 띄우는 건 막는다.
Q: gstack /browse가 MCP가 아니라면 뭔가요?
A: gstack은 자체 바이너리로 Chromium을 띄운다. 장시간 살아있는 헤드리스 데몬을 두고, 명령마다 새 브라우저를 안 띄워서 쿠키·로그인 상태가 유지된다. MCP 브라우저 도구와는 별개다.
Q: 에이전트 팀이 정말 단일 에이전트보다 나은가요?
A: SWE-bench Verified 기준 Agyn 연구(2026)에서 에이전트 팀이 72.2%, 단일 에이전트 베이스라인이 약 65% 수준이었다. 7.2%p 차이. 다만 토큰 비용은 3~7배 수준으로 늘어난다. “품질 vs 비용” 트레이드오프를 보고 선택하면 된다.
Q: Codex와 Claude Code 둘 다 써야 하나요?
A: 아니다. Codex 쓰면 Codex 서브에이전트만 쓰면 되고, Claude Code 쓰면 gstack을 붙이면 된다. 둘 다 “역할 분리”라는 개념은 같다. 팀/프로젝트에서 이미 쓰는 쪽에 맞춰 선택하면 된다.
출처
- OpenAI Codex Subagents — 서브에이전트 개념, 커스텀 에이전트, CSV 배치
- OpenAI Codex Subagent Concepts — 컨텍스트 오염, 모델 선택 가이드
- gstack GitHub — Garry Tan, MIT, 20,000+ stars
- Coding Agent Teams Outperform Solo Agents: 72.2% on SWE-bench Verified — Agyn 연구, 2026
- Garry Tan Releases gstack – MarkTechPost — 600K LOC, 60일, 일부 리뷰는 “13 specialists” 표기