Claude는 '작은 가재' (OpenClaw)보다 먼저 등장했으며, Grok Build와 Codex 모두 그 이후에 나왔습니다. 결과적으로 Grok과 Codex는 쿼리 처리 및 세션 관리 방식에서 OpenClaw 설계와 더 가깝습니다. (OpenClaw 아키텍처의 별도 상세 분석을 참조하십시오.) 근본적으로 이 세 가지 에이전트는 plan, loop, react, 그리고 spawn-agent를 종합한 형태입니다.
공통점
세 에이전트 모두 '터미널 우선 코딩 에이전트(terminal-first coding agents)'라는 공통점을 가집니다. 이들은 코드를 읽고, 파일을 편집하며, 명령을 실행하고, 도구를 호출하며, MCP에 연결하고, 세션을 관리합니다. 차이점은 이러한 기능의 존재 여부가 아니라 어느 계층에서 위치하는가입니다.
- Grok Build: 다중 크레이트 액터/ACP 아키텍처입니다. 백엔드 샘플링(Sampling backends)은 Sampler에 수렴합니다. '정말로 완료되었는지'를 검증하는 과정은 하네스(harness)가 강제하는 다중 회의론자 흐름(multi-skeptic flow)을 통해 처리됩니다. 편집 기능을 위해 hashline 앵커를 사용하여 '어떤 줄을 변경했는지'를 검증 가능한 사실로 만듭니다.
- Codex: 제출 큐와 이벤트 스트림 (Op → EventMsg)으로 구성되어 있습니다. 승인, 샌드박스 선택, 실행, 거부 후 에스컬레이션된 재시도는 모두 오케스트레이터(orchestrator)에 중앙 집중화되어 있습니다. 완료 여부는 주로 모델에게 자체 감사(self-audit)를 요청하여 판단하며, 액션 안전성(action safety)은 Guardian에 의해 별도로 처리됩니다.
- OpenClaude: 단일 프로세스 비동기 생성기인 queryLoop입니다. 내부적으로 Anthropic 메시지 형식을 표준으로 사용하고 다른 벤더들을 위한 심(shims)을 작성합니다. 계획 수립(Planning)에는 명시적인 Plan Mode 상태 기계가 있으며, 완료 여부는 경량 평가자(lightweight evaluator)에 의해 판단되고, 검증 에이전트는 모델이 호출하기로 선택했을 때만 실행됩니다.
제품 기능 목록에서 중복도는 매우 높습니다:
세 가지 아키텍처 비교
| 기능 | 세 가지 모두 수행하는 것 |
|---|
| 상호작용 모드 (Interaction modes) | 전체 화면 또는 스트리밍 터미널 UI, 슬래시 명령어(slash commands), 헤드리스/스크립트 모드 |
| ... | |
따라서 선택할 때, 기능 표만으로는 거의 동률입니다. 진정으로 차별화되는 지점은 다음과 같습니다. 누가 완료를 판단하는지, 샌드박스가 프로세스 전체를 감싸는지 아니면 각 도구 호출(tool call)을 감싸는지, 모델 적응(model adaptation)이 샘플링 계층(sampling layer)에 있는지 또는 심 계층(shim layer)에 있는지, 그리고 편집 기능이 잘못된 라인 변경을 어떻게 방지하는지입니다.
기본 비교 (Basic Comparison)
| 차원 | Grok Build | Codex | OpenClaude |
| :--- | :--- | :--- |
| 저장소 (Repository) | xai-org/grok-build | openai/codex | Twigpine/openclaude |
| ... |
세 모델의 구조적 차이점 (Architectural Differences Among the Three)
5.1 아키텍처 스타일 (Architectural Style)
Codex는 “제출 큐(submission queue)와 이벤트 스트림(event stream)”입니다. 프런트 엔드는 세션에 Op를 제출하기만 하고, 세션은 EventMsg를 반환합니다. 세션 측면에서 submission_loop가 진입점이며, 이후 run_turn이 샘플링을 시작합니다. UI, 실행기(exec), 앱 서버(app-server), SDK는 모두 이 버스(bus)의 클라이언트입니다. 장점은 안정적인 프로토콜, 감사 가능성(auditability), 그리고 동일한 세션 모델을 재사용할 수 있는 IDE/클라우드 서비스가 가능하다는 점입니다.
Grok Build는 액터(actors)와 ACP를 사용합니다. 샘플링은 독립적인 SamplerActor (원시 스트림, 이벤트 변환, 재시도 및 취소 기능이 포함된 핸들, 둠 루프 감지)로 분리됩니다. 세션 자체는 ACP의 에이전트 측면입니다. leader/relay가 여러 클라이언트와 원격 세션을 처리합니다. 장점은 TUI, 편집기, 헤드리스 모드가 동일한 에이전트를 공유할 수 있으며, 백엔드의 차이가 세션 로직에 누출되지 않는다는 것입니다.
OpenClaude는 단일 프로세스 생성기(single-process generator)입니다. query()는 모든 단계에 걸쳐 메시지를 산출하며, UI, 도구, 압축(compaction), 권한 관리가 모두 이 루프에 의존합니다. 기능 변경이 빠르고 호출 스택(call stack)이 직관적이지만, 프로세스 경계(process boundaries)와 타입 격리(type isolation)는 다른 두 모델보다 약합니다.
2. 모델 적응이 존재하는 곳 (Where Model Adaptation Lives)
- Codex: Responses API를 중심으로 설계되었습니다. 일부 OpenAI 기능(원격 압축(remote compact), Realtime 등)이 코어에 내장되어 있습니다. 이전에 설정에서 존재했던 채팅 와이어 API(chat wire API)는 제거되었습니다. 로컬 모델은 내부 표준 형식이 아닌 추가 클라이언트입니다.
- Grok Build: ApiBackend는 세 가지 열거형(enum) 변형을 가집니다. 차이점은 샘플링 계층(sampling layer)에서 발생하며, 세션은 통합된 이벤트(unified events)만 소비합니다. 이는 퍼스트 파티 API와 호환 가능한 프로토콜을 동시에 연결하는 데 적합합니다.
- OpenClaude: 내부 표준으로 Anthropic Messages를 유지하며, 다른 벤더들은 번역 계층(translation layer)을 통해 접근합니다 (think 태그 제거, 도구 매개변수 정규화, 스키마 정리). 가장 넓은 커버리지를 가지며 패치도 가장 많습니다. 압축(compaction) 및 평가(evaluation)와 같은 내부 "작은 호출"은 동일한 슁(shim)을 거치므로, 비(非)-Anthropic 백엔드에서의 안정성은 번역 품질에 달려 있습니다.
3. Sandboxing 및 권한 관리 위치 (Where Sandboxing and Permissions Live)
- Codex: 도구 실행 시점에 결정됩니다. 오케스트레이터의 순서는 승인(approval), 샌드박스 선택, 실행, 거부 후 에스컬레이션된 재시도이며, 이 과정에서 다시 승인을 요청하지 않습니다. 또한, execpolicy와 Guardian은 사용자의 권한이 특정 페이로드(payload)를 포함하는지 검토합니다.
- Grok Build: Landlock/Seatbelt가 시작 시 전체 프로세스를 감싸고, 자식 프로세스는 더 엄격한 네트워크 제한을 받습니다. 세션 내에는 또한 권한 규칙 및 샌드박스 프로필(Workspace / Devbox / Custom)이 있으며, hooks의 pre_tool_use는 입력을 허용/요청/거부하고 재작성할 수 있게 합니다.
- OpenClaude: 상위 계층 명령어 분석 및 권한 규칙이 먼저 오며, 샌드박스 런타임은 외부 패키지입니다. 유연하지만, 격리 강도는 의존성과 규칙이 완전히 작성되었는지 여부에 따라 달라집니다.
| 레이어 | Grok Build | Codex | OpenClaude |
|---|
| 1 (최상위) | TUI / ACP / leader | TUI / exec / app-server | Ink UI / SDK / gRPC |
| ... | | | |
Grok Build 모듈 맵
- Entry: xai-grok-pager-bin은 TUI를 조립하며; headless/CI는 셸을 거칩니다.
- UI: xai-grok-pager, render, diff, status-line.
- Runtime: xai-grok-shell (세션(session), 압축(compaction), 목표(goal), 메모리(memory)) 및 xai-grok-agent (정의 파싱(definition parsing), 프롬프트 조립(prompt assembly), 서브 에이전트(subagent), 플러그인(plugins)).
- Sampling: xai-grok-sampler.
- Tools: xai-tool-runtime의 Tool 트레이트와, 포팅된 구현을 포함하는 xai-grok-tools.
- Environment: xai-grok-workspace (파일 시스템(filesystem), VCS, 체크포인트(checkpoints)), xai-grok-sandbox, xai-grok-mcp.
- Agent definitions: Markdown + YAML 프런트매터(.grok/agents). permissionMode는 default / acceptEdits / dontAsk / plan을 포함하며; completionRequirement는 턴이 끝날 수 있도록 특정 도구 호출(tool call)을 강제할 수 있습니다.
그림: grok-build (간소화된)
그림: grok-build (크레이트 레벨)
ClientSpace
├─ grok (바이너리 / main CLI)
└─ IDE 또는 외부 애플리케이션
...
그림: grok-build (상세 모듈 맵, 파트 1)
[Clients]
Editor / IDE (ACP client) | headless / CI | xai-grok-pager-bin (TUI 메인 프로그램)
↓
...
그림: grok-build (상세 모듈 맵, 파트 2, 레이어별)
[Entry & Product layer]
xai-grok-pager-bin
├─ Headless / stdio / ACP
...
Grok Build 플로우: 클라이언트(TUI / ACP 에디터 / headless) → leader/relay → Session actor → 권한 및 훅(permissions and hooks) → SamplerActor → ApiBackend; Session → Tool runtime → tools / MCP / workspace → sandbox.
Codex 모듈 맵
- 패키징(Packaging): codex-cli는 npm 런처이며, 실제 바이너리는 codex-rs/cli에 있습니다.
- 인터페이스(Interfaces): tui, exec (비대화형), app-server (JSON-RPC/데몬).
- 핵심 로직(Core): core의 ThreadManager/Session, 프로토콜(protocol), 상태(state), 히스토리(history), 롤아웃(rollout).
- 모델(Models): model-provider, codex-api (응답 및 SSE).
- 도구(Tools): tools/router + registry; 핸들러에는 apply_patch와 unified_exec가 포함되며; 또한 mcp, multi-agent, code-mode (V8)도 있습니다.
- 보안(Security): sandboxing::SandboxManager, linux-sandbox, windows sandbox, network-proxy, execpolicy, guardian.
- 확장 디렉토리 ext/: goal, memories, web-search, skills 등은 core에 확장 기능으로 부착됩니다.
그림: codex (단순화)
TUI / exec / SDK
↓
app-server JSON-RPC
...
그림: codex (진입점 및 핵심 엔진)
Entry Points
codex binary (cli/src/main.rs)
├─ MCP Server (mcp-server/src/main.rs)
...
그림: codex (설치 및 명령어)
Installation Commands (cli/src/main.rs) Core Runtime (core/src/lib.rs)
npm install -g @openai/codex ┐ codex (TUI) ┐
brew install --cask codex ├──→ codex exec 'task' (비대화형) │
...
그림: codex (상세 모듈 맵, 파트 1)
[Entry]
codex-cli: npm 런처 (codex.js) | codex-rs/cli: 서브 커맨드 디스패치 | sdk/typescript · sdk/python
codex-tui | codex-exec: 비대화형 | app-server: JSON-RPC / 데몬
...
그림: codex (상세 모듈 맵, 파트 2)
[Clients & Entry] codex-tui ⇄ codex-app-server / codex-cli
[Business core] codex-api / codex-client / codex-core / codex-tools / Tool Orchestration / Skills / MCP / Multi-Agent
[Execution & Security] Approval / Permission Policy → codex-sandboxing → Unified Exec / PTY / Apply Patch / Filesystem
...
**Codex 흐름**: cli / tui / exec / app-server / SDK → Session submission_loop → run_turn → model-provider / Responses; 같은 턴(turn) 내에서 tools router → orchestrator → sandbox/network-proxy를 가진 handlers가 작동합니다. Guardian과 execpolicy는 실행 전에 삽입됩니다.
## OpenClaude 모듈 맵 (OpenClaude Module Map)
* **진입점 (Entry)**: bin/openclaude → main/cli entrypoints; 빌드 출력은 dist/cli.mjs입니다.
* **사용자 인터페이스 (UI)**: src/ink, components, screens, commands.
* **엔진 (Engine)**: src/query.ts는 매우 크며(100K 바이트 이상 규모), compact, stopHooks, tokenBudget, toolFailureLoopGuard, agentStepLimit와 함께 제공됩니다.
* **도구 (Tools)**: src/tools/*Tool; 각 도구는 자체 권한과 일부 UI를 가집니다.
* **모델 (Models)**: src/services/api 및 src/integrations (vendors, gateways, registry).
* **권한 (Permissions)**: bash 분류기(classifier)를 포함하여 src/utils/permissions.
* **주변 장치 (Periphery)**: memdir, repo map, gRPC, 데몬/백그라운드 세션, vscode-extension.
### 그림: openclaude (단순화)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Ink UI / SDK / gRPC
↓
QueryEngine
...
### 그림: openclaude (코드 엔티티 공간 및 자연어 공간)
Code Entity Space
bin/openclaude → dist/cli.mjs
→ src/entrypoints/init.ts / src/bootstrap/state.ts
...
### 그림: openclaude (Query Engine 및 도구 실행)
자연어 공간: 사용자의 자연어 입력
↓ parses /commands
Command Registry (src/commands): 명령 로직을 실행합니다.
...
### 그림: openclaude (상세 모듈 맵, 파트 1)
[Entry (Bun 빌드 → dist/cli.mjs, Node에서 실행)]
bin/openclaude / main.tsx · entrypoints/cli.tsx / SDK · MCP server · gRPC · VS Code extension · bridge
↓
...
### 그림: openclaude (상세 모듈 맵, 파트 2)
[Model adaptation layer] 제공업체/모델 설정 → Anthropic 호환 / OpenAI 호환 / Ollama (로컬 모델) / 기타 제공업체
[Interaction & product entry] VS Code 확장 프로그램 / 헤드리스 gRPC / 슬래시 명령어 / CLI / REPL
[Agent Runtime] 대화/메시지 관리 → 컨텍스트 레포 맵 → 모델 응답 및 도구 호출 루프 → 에이전트 라우팅 / 작업(Tasks)
...
**OpenClaude 흐름**: bin/CLI 또는 SDK/gRPC/VS Code → Ink UI → QueryEngine.queryLoop → 도구 및 권한 → 샌드박스 어댑터; 병렬 분기는 services/api shims → 각 제공업체로 들어갑니다. 압축(Compaction), 목표 평가, 중지 후크는 모두 동일 루프의 yield 사이에 걸쳐 있습니다.
## 출처 및 역사에 대한 참고 사항 (Notes on Provenance and History)
- Grok Build의 THIRD-PARTY-NOTICES는 apply_patch, grep_files, list_dir, read_file 등은 openai/codex에서 포팅되었으며, bash, edit, glob, grep, read, skill, todowrite, write 등은 sst/opencode에서 왔음을 보여줍니다. 따라서 "네 세트의 편집 도구가 공존하는 것"은 우발적인 중복이 아니라 역사적 계층화입니다.
- xai-grok-shell에는 claude_import와 external-agent-migration이 포함되어 있어 Claude 계열 구성으로부터의 마이그레이션을 제공합니다.
- OpenClaude의 QueryEngine, Tool.buildTool, BashTool, AgentTool 명명 규칙은 Claude 코드 구조와 일치하며, 그 위에 다중 제공업체 지원이 추가되었습니다. 일부 도구 파일(초기 노트의 VerifyPlanExecution, REPL, SuggestBackgroundPR 등)은 한때 거의 빈 껍데기였습니다. 통합할 때는 파일의 실제 현재 라인 수를 따르고, 모든 도구 이름에 완전한 구현이 있다고 가정하지 마십시오.
## 세 가지 간의 설계 차이점 (Design Differences Among the Three)
### 계획(Planning), 완성 판단(Completion Judgment), 및 행동 위험(Action Risk)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20