Claude Code에는 Dynamic Workflows라는 기능이 있다. 서브 에이전트(Sub-agent)를 수십 개 병렬로 실행하여, 코드베이스 전체의 감사(Audit)나 프레임워크 이관(Migration) 같은 무거운 작업을 자동으로 수행해 주는 기능이다.

그래서 문득 생각이 들었다. Codex CLI에도 비슷한 기능이 있을까?

조사해 보려고 했는데, 이왕 하는 거 이 Workflow 기능 자체를 사용해서 조사해 볼까 하여 5개의 에이전트를 병렬로 돌리는 조사 워크플로우(Workflow)를 작성하여 실행해 보았다. 이 기사는 그 결과를 정리한 것이다.

완전하게 동일한 기능은 Codex CLI에 없다.

다만 「멀티 에이전트(Multi-agent) v2」를 통해 최대 8개의 병렬 서브 에이전트를 실행할 수 있다. Symphony라는 외부 오케스트레이션(Orchestration) 사양도 존재한다. 「전혀 할 수 없는」 것은 아니지만, 근본적인 아키텍처(Architecture)가 다르기 때문에 동일한 경험을 제공하지는 않는다.

이후 내용에서 무엇이 다른지, 무엇을 할 수 있는지 구체적으로 써 내려가겠다.

2026년 5월 28일, Opus 4.8과 동시에 출시된 리서치 프리뷰(Research Preview) 기능.

한마디로 말하면, **「오케스트레이션(Orchestration) 로직을 JavaScript로 작성하여, 서브 에이전트의 병렬 실행을 제어하는 메커니즘」**이다.

기존 방식에서는 Claude가 턴(Turn)마다 "다음은 무엇을 할까?"라고 판단하며, 중간 결과가 전부 컨텍스트 윈도우(Context Window)에 쌓이게 된다. 10개 파일 정도라면 괜찮지만, 100개가 넘어가면 컨텍스트가 넘쳐나서 정밀도가 급격히 떨어진다.

Workflows는 이 문제를 「계획을 코드로 옮기는 것」으로 해결했다. 루프(Loop), 분기(Branch), 중간 결과는 스크립트의 변수에 담는다. Claude의 컨텍스트에는 최종 결과만 반환된다. 이를 통해 1,000개의 에이전트까지 스케일(Scale)할 수 있다.

함수	역할
agent(prompt, opts)	서브 에이전트를 1개 생성. schema로 구조화된 출력(Structured Output)을 강제할 수 있음
parallel(thunks)	모든 작업이 끝날 때까지 기다리는 배리어(Barrier). 최대 16개 병렬
pipeline(items, ...stages)	스테이지(Stage) 간 배리어가 없는 스트림(Stream) 처리. 이 방식이 기본 권장 사항
workflow(name, args)	다른 저장된 워크플로우를 호출 (1계층까지)

TypeScript는 사용할 수 없다. 순수 JavaScript만 가능하다. Date.now()나 Math.random()도 사용할 수 없다 (재개(Resume) 기능을 위한 제약 사항).

이런 스크립트를 작성했다.

export const meta = {
name: 'codex-workflow-research',
description: 'Codex CLI에 workflow 상당 기능이 있는지 조사',
...

(실제로는 스키마(Schema) 정의가 더 길지만 생략)

5개의 에이전트가 약 15분 만에 완료되었다. 각 에이전트가 각각 웹 검색을 수행하여 총 30만 토큰(Token) 정도를 사용했다. 에이전트 1개당 6만 토큰이다. 꽤 많이 소모한다.

조사하여 알게 된 것은, Codex CLI에도 멀티 에이전트는 있다는 사실이다. 2026년 3월에 GA(General Availability)되었다.

# config.toml
[agents]
max_threads = 6 # 동시 실행 수 (기본 6, 최대 8)
...

빌트인(Built-in)으로 default(범용), worker(구현 특화), explorer(읽기 특화)의 3종류 에이전트가 있으며, TOML 파일로 커스텀 에이전트도 정의할 수 있다.

자연어로 "각 리뷰 관점마다 에이전트를 생성(Spawn)하고, 모두 끝나면 요약해 줘"와 같이 지시하면, Codex가 알아서 분할, 병렬 실행, 통합을 수행한다.

여기까지는 꽤 비슷하다. 그렇다면 무엇이 다를까.

이것이 가장 큰 차이점이다.

Claude Code의 Workflow는 JavaScript로 오케스트레이션을 작성한다. for 문으로 돌리고, if로 분기하며, 변수에 중간 결과를 저장하는 등—프로그래밍 언어의 표현력을 그대로 사용할 수 있다.

// 2라운드 연속으로 새로운 발견이 없으면 종료
while (dry < 2) {
const found = await parallel(FINDERS.map(f => () =>
...

Codex의 멀티 에이전트는 자연어로 "부탁"한다. GPT가 "여기는 분할하는 게 좋겠어"라고 판단하여 서브 에이전트(Sub-agent)를 생성(Spawn)한다. 제어는 모델에 맡긴다.

어느 쪽이 더 나은지는 상황에 따라 다르다. 하지만 "이 루프를 반드시 3회 이상 돌리고, 각 라운드에서 중복을 제거하며, 2 라운드 연속으로 결과가 0이면 멈춰라"와 같은 정밀한 제어는 코드가 아니면 불가능하다. 프롬프트로 전달하더라도 모델이 "음, 충분히 찾았으니 이쯤에서 끝내도 되겠지"라고 판단해 버릴 가능성이 있다.

Claude Code: 중간 결과는 스크립트 변수에 담는다. 컨텍스트(Context)에 들어가는 것은 최종 return 값뿐이다.

Codex: 부모 에이전트의 컨텍스트에 서브 에이전트의 결과가 축적된다.

10명 정도의 에이전트라면 둘 다 문제없다. 100명의 에이전트라면 Codex 측은 컨텍스트가 버거워진다. Claude Code는 (이론상) 1,000명의 에이전트까지 가능하다.

이 부분이 개인적으로 가장 흥미로웠다.

Claude Code의 Workflow에는 Adversarial Verify라는 패턴이 있다. 버그나 취약점을 발견하면, 다른 에이전트 3개에게 "이게 정말 버그야? 반증해 봐"라고 던진다. 과반수가 "아니, 이건 버그가 아니야"라고 말하면 제외한다.

const votes = await parallel(Array.from({length: 3}, () => () =>
agent(`반증해 봐: ${claim}`, { schema: VERDICT })))
const survives = votes.filter(Boolean)
...

이것이 코드로 확실하게 실행된다는 점이 포인트다. Codex에서도 "검증해 주세요"라고 프롬프트에 쓸 수 있지만, 모델이 "뭐, 괜찮겠지"라며 스킵할 리스크가 있다.

공정하게 쓰지 않으면 페어(Fair)하지 않으니까.

Claude Code의 Workflow는 세션 내로 한정된다. Claude Code를 닫으면 중간 결과는 사라진다.

Codex의 /goal 기능(v0.128.0~)은 세션 간에 영속화(Persistence)된다. 18시간 동안 방치했는데 18개 기능 중 14개를 혼자서 구현했다는 사례도 있다. 이것은 대단하다.

Claude Code는 완전히 로컬(Local)이다. 머신의 전원을 끄면 끝이다.

Codex App은 클라우드의 격리된 컨테이너에서 동작한다. 원격 제어도 가능하다 (스마트폰에서 QR 페어링).

OpenAI가 2026년 4월에 내놓은 오픈 소스 사양. Linear 같은 이슈 트래커(Issue Tracker)를 컨트롤 플레인(Control Plane)으로 삼아, 여러 Codex 에이전트를 협조시킨다. GitHub Stars 15K 돌파. 사내에서 PR 랜딩률이 500% 향상되었다는 보고도 있다 (진짜일까).

Claude Code에는 아직 이런 외부 시스템 연동 메커니즘이 없다.

항목	Claude Code	Codex CLI
오케스트레이션 (Orchestration)	JS 코드로 제어	자연어로 지시
...	pipeline() 배리어 없음	없음
구조화된 출력 (Structured Output)	schema 옵션	--output-schema (버그 있음)
품질 검증	코드로 확실히 실행	프롬프트에 의존
재개 (Resume)	세션 내로 한정	세션 간 영속
...	.claude/workflows/에 JS	Skills (절차서. 제어 흐름 없음)

대략적으로 정리하자면:

• 코드베이스 전체 감사, 대규모 마이그레이션, 100개 이상의 파일 일괄 처리 $\rightarrow$ Claude Code Workflows가 유일한 선택지. 컨텍스트 관리와 품질 보증 패턴이 차원이 다름.
• CI/CD 연동, 이슈(Issue) 기반 자동화, 밤새 방치하는 장시간 태스크 $\rightarrow$ Codex가 더 적합함. 클라우드 실행과 /goal의 영속성이 효과적임.
• 몇 개의 파일 수정, 일반적인 코드 리뷰 $\rightarrow$ 어느 쪽이든 상관없음. Workflow를 쓸 정도의 규모가 아님.

참고로 이 조사 자체도 Workflow의 좋은 데모가 되어, 5명의 에이전트가 각각 독립적으로 웹 검색 $\rightarrow$ 구조화된 출력 $\rightarrow$ 통합 분석이라는 파이프라인을 15분 만에 실행해 주었다. 수동으로 했다면 2시간은 걸렸을 것이다.

실제로 몇 번 돌려보며 알게 된 점.

• TypeScript를 쓰지 마라. 타입 주석(Type annotation)을 넣는 순간 파싱 에러(Parse error)가 발생하며 중단된다. const x: string[] 대신 const x = []를 사용해야 한다.
• Date.now()를 사용할 수 없다. 재개(Resume) 기능을 위해 스크립트의 결정론(Determinism)이 필요하며, 비결정론적(Non-deterministic)인 함수는 모두 금지되어 있다.
• schema는 작성하는 것이 좋다. 프롬프트로 "JSON으로 반환해 줘"라고 요청하는 것보다, schema 옵션을 사용하는 것이 훨씬 더 안정적이다. 불일치(Mismatch)가 발생하면 자동으로 2회 재시도(Retry)를 수행한다.
• pipeline()과 parallel()을 혼동하지 마라. 독립적인 처리는 pipeline() (배리어(Barrier) 없음, 빠름)을 사용한다. 모든 결과를 모아서 중복 제거 등을 수행하고 싶을 때만 parallel() (배리어 있음, 느림)을 사용한다.
• 에이전트가 모의 데이터(Mock data)를 조작하는 문제. try/catch 문 안에서 에러를 묵인하고 거짓 데이터를 반환하는 경우가 있다. CLAUDE.md에 "Error handling: fail loud, never fake."라고 적어두면 방지할 수 있다.