Claude Code vs Codex CLI 2026: 의사결정 레퍼런스

저는 Claude Code를 주력 개발 도구로 사용합니다. 이 편향을 먼저 밝혀 두는 이유는, 가장 설득력 있는 비교 글은 한 도구를 깊이 알고 다른 도구를 정직하게 시험해 본 데서 나오기 때문입니다. 동일한 작업을 두 도구에 똑같이 돌리고 어느 쪽이 만든 결과물인지 모른 채 채점한 36회의 블라인드 대결¹, 그리고 두 도구로 진행한 수백 번의 작업 끝에, “어느 쪽이 더 나은가?”라는 질문의 답은 진심으로 “작업에 따라 다르다”였습니다.

Claude Code는 심층 리팩터링, 코드 리뷰, 그리고 생애주기 훅 시스템을 통한 프로그래밍 가능한 거버넌스에서 더 낫고, Codex CLI는 커널 수준 샌드박싱과 AGENTS.md를 통한 도구 간 이식성에서 더 낫습니다. Claude Code는 직접 연결하는 두 다스가 넘는 훅 이벤트로 애플리케이션 계층에서 안전성을 강제하고, Codex는 모델이 제약을 우회할 수 없는 OS 커널 계층에서 안전성을 강제합니다. 복잡한 다중 파일 추론과 가장 깊이 있는 맞춤형 작업 흐름이 필요하면 Claude Code를 고르세요. 최대한의 격리와 8개 이상의 도구에서 동작하는 표준화된 에이전트 지침이 필요하면 Codex를 고르세요.

2026년 6월 5일 기준 최신. 두 도구 모두 매주 출시를 거듭하므로 여기 담긴 사실에는 유통기한이 있습니다. 이번 개정 시점 기준으로 Claude Code는 Opus 4.8(CLI v2.1.165)을, Codex는 GPT-5.5(CLI v0.137.0)를 기본값으로 합니다. 봄 이후 가장 큰 변화는 Codex가 제대로 된 생애주기 훅 시스템을 출시하면서, 한때 Claude Code의 가장 분명한 강점이던 부분의 격차를 좁혔다는 점입니다. 그것이 무엇을 바꾸고 무엇을 바꾸지 않는지는 각 도구가 이기는 지점을 참고하세요.

요약

Claude Code와 Codex CLI는 같은 문제(AI 보조 개발)를 근본적으로 다른 아키텍처로 풉니다. Claude Code는 주로 훅을 통해 다스립니다. 두 다스가 넘는 생애주기 이벤트 유형이 애플리케이션 계층에서 정책을 결정론적으로 강제합니다². Codex는 주로 샌드박싱을 통해 다스립니다. 애플리케이션 계층 아래의 OS 수준 커널 제약³에, 이제는 자체 생애주기 훅까지 더해졌습니다. 어느 한쪽 접근이 무조건 우월한 것은 아닙니다.

블라인드 테스트에서 Claude Code는 코드 리뷰와 보안 검증에서 Codex를 일관되게 앞섰습니다. Codex는 샌드박싱, AGENTS.md를 통한 도구 간 이식성, 클라우드 작업 위임에서 진짜 이점을 제공합니다.

빠른 의사결정: 커널 수준 샌드박싱이나 도구 간 AGENTS.md가 필요한가요? → Codex. 가장 성숙한 프로그래밍 가능 거버넌스 훅이나 심층 리팩터링이 필요한가요? → Claude Code. 두 안전성 모델이 모두 필요한가요? → 둘 다 사용하세요.

둘 다 처음이라면? 먼저 Claude Code 가이드나 Codex 가이드부터 시작하세요. 이 글은 적어도 한쪽에 익숙하다고 가정합니다.

두 가지 사고 모델

두 도구 모두 3계층 아키텍처지만, 각 계층이 맡는 목적은 다릅니다.

Claude Code:

1. 추론. Claude Code는 선택된 Claude 모델을 실행합니다. CLI v2.1.154(2026년 5월 28일) 기준으로 Opus 4.8이 기본값이며, 기본적으로 high effort가 적용되고 가장 어려운 작업을 위한 /effort xhigh 레벨도 있습니다. 가벼운 작업을 위해서는 Sonnet 4.6과 Haiku 4.5도 선택할 수 있습니다²
2. 실행. Bash, 파일 작업, git 명령어, MCP 도구 호출
3. 거버넌스. 훅이 두 다스가 넘는 생애주기 지점에서 동작을 가로채고², 권한이 범위를 통제합니다

Codex:

1. 모델. GPT-5.5(2026년 4월 23일 출시)가 기본값입니다. Codex에서 400K 컨텍스트, API에서 1M, MTok당 $5 / $30, Terminal-Bench 2.0에서 82.7%(출시 시점 최고 기록). GPT-5.5-pro가 최고 effort 등급을 담당하고, 더 작은 GPT-5.4 mini는 여전히 지연 시간이 낮은 서브에이전트 작업을 처리합니다⁴
2. 샌드박스. OS 수준 커널 강제(macOS에서는 Seatbelt, Linux에서는 Landlock + seccomp)³
3. 승인. 세 가지 정책(untrusted, on-request, never)이 실행 전에 변경을 통제합니다⁵

핵심 차이는 거버넌스가 주로 어디에 자리 잡는가입니다. Claude Code의 무게중심은 애플리케이션 계층에 있습니다. 훅은 특정 이벤트를 가로채도록 여러분이 직접 작성하는 프로그램입니다. Codex의 무게중심은 커널 계층에 있습니다. 모델이 무엇을 시도하든 운영체제가 허용되지 않은 작업을 막습니다. 이제 두 도구 모두 훅을 갖췄지만, 아키텍처는 여전히 서로 다른 기본값을 앞세웁니다.

이 구분이 중요한 이유: 애플리케이션 계층 거버넌스는 프로그래밍이 가능합니다. 비즈니스 로직을 인코딩하고, 린터를 돌리고, 스키마를 검증하는 등 코드로 표현할 수 있는 무엇이든 할 수 있습니다. 커널 계층 거버넌스는 빠져나갈 수 없습니다. OS가 애플리케이션에 도달하기 전에 시스템 호출을 거부하므로 모델이 제약을 우회할 방법이 없습니다. 모든 안전성 아키텍처는 표현력과 견고함 사이에서 절충하며, 이 두 도구는 그 스펙트럼의 양 끝에 자리합니다.

설정 철학

Claude Code는 JSON을 씁니다. Codex는 TOML을 씁니다. 둘 다 계층적 범위 지정을 지원합니다. 철학이 갈리는 지점은 컨텍스트 전환을 어떻게 바라보느냐입니다.

Claude Code: 계층화된 설정

// ~/.claude/settings.json (user-level)
{
  "permissions": {
    "allow": ["Bash(git *)"],
    "deny": ["Bash(rm -rf *)"]
  }
}

// .claude/settings.json (project-level, inherits user)
{
  "permissions": {
    "allow": ["Bash(npm test)"]
  }
}

Claude Code는 여러 계층에서 설정을 해석합니다. 관리형 설정(최우선) → 명령줄 → 로컬 프로젝트 → 공유 프로젝트 → 사용자 기본값 순입니다⁶. 메모리 파일(CLAUDE.md)은 사용자 → 프로젝트 → 로컬이라는 자체 범위 규칙을 따릅니다. 스킬과 훅은 또 다른 계층을 더합니다. 유연함은 강력하지만, 실제로 적용되는 설정은 어느 한 파일만 봐서는 보이지 않습니다. 계층을 읽어 가며 맞춰 봐야 합니다.

Codex: 명시적 전환이 있는 프로파일

# ~/.codex/config.toml
model = "gpt-5.5"
approval_policy = "on-request"

[profiles.deep-review]
model = "gpt-5.5-pro"
approval_policy = "never"

[profiles.careful]
approval_policy = "untrusted"

codex --profile careful "Review this PR"
codex --profile deep-review "Audit this module"

Codex 프로파일은 플래그 하나로 설정을 전환하게 해 줍니다⁷. 따져 볼 계층 해석이 없고, 적용 중인 설정은 항상 명시적입니다. 승인 정책을 표준화하려는 팀이라면 감사하기가 더 간단합니다. 프로파일은 실험적 기능에서 일급 관리형 표면으로 격상되었습니다. 이제 --profile이 CLI, TUI 권한, 샌드박스 흐름 전반에서 주된 선택자이며, 이름 붙은 권한 프로파일은 상속, API 목록 지정, 조직 정책을 위한 관리형 requirements.toml을 지원합니다⁷.

안전성 모델

안전성은 두 도구 사이에서 가장 깊은 아키텍처적 분기점입니다.

Claude Code: 애플리케이션 계층의 결정론적 훅

훅은 동작이 실행되기 전에 가로챕니다. Bash에 걸린 PreToolUse 훅은 모든 명령어를 검사해 위험한 패턴을 차단할 수 있습니다²:

# Hook: git-safety-guardian (PreToolUse:Bash)
if echo "$tool_input" | grep -q "push.*--force.*main"; then
  echo '{"decision": "block", "reason": "Force push to main blocked"}'
fi

강점: 훅은 프로그램입니다. 임의로 복잡한 안전성 로직을 인코딩할 수 있습니다. 파일 경로 확인, JSON 검증, 명명 규칙 강제, 린터 실행 등이 가능합니다. 저는 자격 증명 탐지부터 품질 관문까지 모든 것을 아우르는 95개의 훅을 운영합니다.

약점: 훅은 애플리케이션 계층에서 동작합니다. 2025년에 Check Point Research가 CVE-2025-59536을 공개했는데, 프로젝트 설정 파일에 심어진 악성 훅이 Claude Code 초기화 중에, 사용자가 동의 대화상자를 보기도 전에 셸 명령어를 실행할 수 있음을 보여 준 사례입니다¹⁹. Anthropic는 몇 주 안에 취약점을 패치했지만, 이 공개는 아키텍처상의 우려를 입증합니다. 애플리케이션 계층 강제는 에이전트와 같은 프로세스 경계를 공유합니다. NVIDIA의 AI Red Team 지침도 같은 결론에 이릅니다. “훅과 MCP 초기화 함수는 흔히 샌드박스 환경 바깥에서 실행되어, 샌드박스 통제를 빠져나갈 기회를 제공한다”²⁰.

Codex: 커널 수준 샌드박싱

Codex는 에이전트를 OS 수준에서 제약합니다. macOS에서는 Seatbelt 프로파일이 파일시스템 접근, 네트워크 연결, 프로세스 생성을 제한합니다³. Linux에서는 Landlock + seccomp가 동등한 제약을 제공하며, 설정을 통해 선택적으로 Bubblewrap(bwrap) 파이프라인을 쓸 수 있습니다³.

# Three sandbox modes
codex --sandbox read-only           # Agent can read but not write
codex --sandbox workspace-write     # Agent writes only in project directory (default)
codex --sandbox danger-full-access  # No restrictions (named to signal risk)

강점: 커널 수준 강제는 애플리케이션 아래에 있습니다. 모델은 영리한 명령어를 짜내어 제약을 빠져나갈 수 없습니다. 운영체제가 시스템 호출이 실행되기 전에 거부하기 때문입니다³. 전체 접근 모드에 붙은 danger- 접두사는, 샌드박스 제약을 푸는 것이 일상적인 설정이 아니라 예외적인 행동임을 드러냅니다.

약점: 커널 제약은 이분법적입니다. 파일시스템 쓰기를 허용하거나 거부할 수는 있어도, “src/에는 쓰기를 허용하되 config/에는 변경이 린터를 통과하지 않는 한 쓰기를 막아라”라고 말할 수는 없습니다. 그렇게 세밀한 거버넌스에는 애플리케이션 수준 로직이 필요합니다.

이 절충은 실재합니다. 훅은 세밀하고 프로그래밍 가능한 안전성을 주지만 경계는 더 약합니다. 샌드박싱은 더 강한 경계를 주지만 통제는 더 거칩니다. 빠른 의사결정 기준은 이렇습니다.

• 내부는 신뢰, 코드는 외부: 모르는 기여자가 보낸 PR을 검토할 때는 read-only 샌드박싱과 함께 Codex를 쓰세요. 모델이 무엇을 시도하든 커널이 파일 수정을 막습니다.
• 신뢰하는 코드, 정책 강제: 코드베이스는 신뢰하지만 조직 표준을 강제해야 한다면 Claude Code 훅을 쓰세요. 커밋 메시지 형식, 자격 증명 스캔, 린팅 관문 같은 것들입니다.
• 두 우려 모두: 둘 다 쓰세요. 초기 안전성 경계로는 Codex를, 그다음 거버넌스 비중이 높은 리뷰로는 Claude Code로 전환하세요.

확장성

두 도구 모두 맞춤화를 지원하지만, 메커니즘에 따라 성숙도가 다릅니다.

Claude Code가 앞서는 곳: 훅의 깊이. 이 생애주기 시스템은 PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, SessionEnd, Stop, StopFailure, SubagentStart, SubagentStop, PreCompact, PermissionRequest, PermissionDenied, TaskCreated, TaskCompleted, CwdChanged, FileChanged, MessageDisplay 등을 아우릅니다. 두 다스가 넘는 이벤트이며 지금도 늘어나고 있습니다². 이제 Codex에도 훅이 있지만, Claude Code의 목록이 더 폭넓고 더 검증되어 있으며, 방향을 잡아 주는 Stop 훅의 additionalContext, 그리고 대규모 에이전트 확산을 위한 동적 /workflows와 짝을 이룹니다. 품질 관문을 강제하거나, 커밋 전에 자격 증명 유출을 탐지하거나, 여러 이벤트 유형에 걸쳐 자동으로 컨텍스트를 주입해야 한다면 Claude Code의 훅 아키텍처가 더 성숙한 선택지입니다.

Codex가 격차를 좁힌 곳: 훅은 더 이상 Claude Code만의 것이 아닙니다. 커뮤니티는 2025년 내내 확장된 훅 이벤트를 요청해 왔고¹⁸, Codex는 이를 내놓았습니다. AfterAgent와 AfterToolUse 이벤트를 갖춘 제대로 된 생애주기 훅 시스템, 작업 중간에 훅을 발견하고 켜고 끌 수 있는 /hooks TUI, 그리고 확장이 서브에이전트 시작/종료, 도구 실행, 턴 메타데이터를 비동기 승인과 함께 관찰하는 확장 API입니다⁹. 예전 구도(Claude Code에는 훅이 있고 Codex에는 사후에 한 번 울리는 알림만 있다)는 더 이상 유효하지 않습니다. 2026년의 정직한 표현은 이렇습니다. 두 도구 모두 프로그래밍 가능한 거버넌스 훅을 갖췄으며, Claude Code의 것이 더 폭넓고 성숙한 반면, Codex의 것은 이 분야에서 가장 강력한 샌드박스와 나란히 동작합니다.

Codex가 앞서는 곳: 도구 간 이식성과 표면. AGENTS.md는 Linux Foundation 산하 Agentic AI Foundation이 관리하는 개방형 표준으로¹³, 6만 개 이상의 프로젝트가 채택했습니다⁸. 같은 지침 파일이 Codex, Cursor, GitHub Copilot, Amp, Windsurf, Gemini CLI(설정을 거쳐)에서 동작합니다¹⁴. CLAUDE.md는 강력하지만 Claude Code에 묶여 있습니다. Codex는 또한 다섯 가지 표면에서 동작하며(CLI, 데스크톱 앱, IDE 확장, 클라우드, 그리고 일반 브라우징 곁에서 함께 도는 Chrome 확장¹⁶), codex cloud exec는 오래 걸리는 작업을 OpenAI 인프라로 넘기고 diff를 돌려줍니다¹². Claude Code가 네이티브로는 제공하지 않는 작업 흐름입니다.

각 도구가 이기는 지점

36회의 블라인드 대결—동일한 프롬프트를 두 도구에 보내고 어느 쪽인지 모른 채 결과물을 채점—과 매일의 실무 사용을 토대로 정리하면 이렇습니다.

전체 방법론과 대결별 채점은 블라인드 심판에 있습니다. 이 결과들은 Opus 4.8과 GPT-5.5 이전이므로, 현재의 최종 점수표라기보다 방향을 가리키는 지표로 받아들이세요. 이 결과는 각 도구의 형태(Claude Code는 리뷰와 추론에서, Codex는 DevOps와 격리에서 더 강함)를 담고 있으며, 그 형태는 모델 업그레이드를 거쳐도 유지되어 왔습니다. 정확한 격차 수치는 오늘의 모델에 그대로 적용되지 않습니다. 현재 기본값으로 대결을 다시 돌려 볼 생각입니다. 그때까지는 분류별 경향성이 변치 않는 신호입니다.

Claude Code가 이기는 경우

• 코드 리뷰와 보안 검증. Claude Code는 리뷰 작업에서 승부가 가려진 12회 중 8회를 이겼습니다¹. 품질 철학 시스템과 증거 관문이, Codex의 더 절차적인 접근이 놓치는 문제를 잡아냅니다.
• 거버넌스 비중이 높은 작업 흐름. 작업 흐름에 커밋 전 검사, 자격 증명 스캔, 출력 검증, 또는 실행 전에 차단하는 품질 관문이 필요하다면 Claude Code의 PreToolUse 훅이 그 메커니즘입니다. 이제 Codex에도 자체 생애주기 훅(AfterAgent, AfterToolUse)이 있지만⁹, 이들은 사후에 관찰합니다. 실행 전 차단의 경우 Codex는 프로그래밍 가능한 사전 훅 대신 샌드박스와 승인 정책에 기댑니다. 이벤트 유형의 폭과 인라인 차단 로직 면에서는 Claude Code의 목록이 여전히 더 완성도 높은 거버넌스 도구 모음입니다.
• 복잡한 다중 에이전트 편성. Task 도구를 통한 명시적 서브에이전트 위임¹⁰에, 수십에서 수백 개의 에이전트를 백그라운드에서 확산시키는 동적 /workflows와 심의 시스템이 결합하면, 여러 전문 에이전트가 격리된 컨텍스트로 협업하는 작업 흐름이 가능합니다.
• 심층 코드베이스 리팩터링. Opus는 긴 작업에 걸쳐 아키텍처 컨텍스트를 붙잡고 있는 데 뛰어납니다. Claude Code의 훅/스킬/규칙 위계를 다스리는 컨텍스트 엔지니어링 패턴은, 모델이 대규모 코드베이스를 추론하는 방식으로 그대로 이어집니다.

Codex가 이기는 경우

• 샌드박스가 결정적인 환경. 신뢰할 수 없는 코드에 AI 에이전트를 돌리거나, 외부 PR을 처리하거나, 파일시스템과 네트워크 접근에 대한 강한 보장이 필요한 CI/CD 파이프라인에서 작업한다면 Codex의 커널 수준 샌드박싱이 알맞은 도구입니다³. 애플리케이션 수준 훅은 같은 보장을 제공할 수 없습니다.
• 도구를 넘나드는 팀. 팀이 여러 AI 코딩 도구를 쓴다면, AGENTS.md는 Codex, Cursor, Copilot, Amp, Windsurf 등에서 동작하는 단일 지침 파일을 줍니다¹⁴. CLAUDE.md, .cursor/rules, Copilot 지침을 따로 유지보수할 필요가 없습니다.
• 클라우드 비동기 작업 흐름. codex cloud exec는 작업을 클라우드 인프라로 위임하고 diff를 돌려줍니다¹². CI/CD 연동이나 일괄 처리에서는 Claude Code가 네이티브로 제공하지 않는 작업 흐름입니다.
• 실시간 방향 조정. Codex의 steer 모드는 Enter로 작업 도중에 지침을 즉시 끼워 넣거나, Tab으로 후속 지침을 다음 턴에 대기시키게 해 줍니다¹⁵. Claude Code는 후속 메시지를 지원하지만 턴 중간 삽입은 지원하지 않습니다.
• 표면 커버리지. Codex는 다섯 가지 표면을 아우릅니다. CLI, 데스크톱 앱(병렬 worktree와 떠 있는 창을 넘나드는 macOS 멀티태스킹), IDE 확장(VS Code, Cursor, Windsurf), 클라우드 작업, 그리고 브라우징을 가로채지 않고 곁에서 함께 동작하는 Chrome 확장입니다¹⁶. Claude Code는 VS Code, JetBrains와 연동되지만¹⁷ CLI를 우선합니다. 터미널에서 에디터로, 브라우저로, 클라우드로 여러분을 따라다니는 하나의 에이전트를 원한다면 Codex가 더 넓은 영역을 덮습니다.

둘 다 사용하기

두 도구는 충돌하지 않습니다. CLAUDE.md와 AGENTS.md는 같은 저장소에서 공존합니다. 제 설정은 이렇습니다.

my-project/
├── .claude/
│   └── settings.json     # Claude Code project config
├── CLAUDE.md              # Claude Code instructions
├── AGENTS.md              # Codex + Cursor + Copilot instructions
└── codex.md               # Codex project config (optional)

구체적인 두 도구 작업 흐름: 저는 매일의 개발—기능 구현, 코드 리뷰, 훅이 모든 단계에서 품질 관문을 강제하는 다중 파일 리팩터—에는 Claude Code를 씁니다. 외부 기여자가 PR을 열면 --sandbox read-only와 함께 Codex로 전환해 신뢰할 수 없는 코드를 상대로 변경을 검토합니다. 아키텍처 결정에 두 번째 의견이 필요하면, 같은 프롬프트를 두 도구에 보내고 블라인드 심판 방식으로 결과물을 모른 채 비교합니다.

두 도구 접근법은 제 테스트 너머의 실증적 근거도 있습니다. Milvus의 연구에 따르면 여러 AI 모델 간의 적대적 리뷰가 버그 탐지율을 53%에서 80%로 끌어올렸습니다²³. 별도의 한 연구는 Claude-Codex 반복 리뷰 루프가 3라운드에 걸쳐 어느 한 도구도 단독으로는 찾지 못한 14개의 문제를 잡아냈음을 발견했습니다²⁴. 어느 도구도 다른 쪽을 대체하지 않습니다. 둘은 서로 다른 위협 모델과 작업 프로파일을 덮습니다.

핵심 정리

도구를 고르는 중이라면:

• 안전성 요구사항에서 출발하세요. 커널 수준 샌드박싱이 필요한가요? Codex. 프로그래밍 가능한 거버넌스 훅이 필요한가요? Claude Code.
• 팀을 고려하세요. AI 도구를 여러 개 쓰고 있나요? AGENTS.md는 도구마다 지침을 중복 유지하는 일을 피하게 해 줍니다¹⁴.
• 결정하기 전에 실제 작업으로 둘 다 시험해 보세요. 블라인드 심판 방법론은 개인 평가에도 통합니다.

이미 한쪽에 투자했다면:

• Claude Code 사용자: 그래도 AGENTS.md를 작성하세요. 20분이면 되고, 프로젝트를 Codex, Cursor, Copilot 사용자도 쓸 수 있게 만듭니다.
• Codex 사용자: 훅 시스템이 도착했습니다. /hooks로 둘러보고, AfterAgent/AfterToolUse를 연결하고, 실행 전 통제를 위해 권한 프로파일과 샌드박스에 기대세요⁹. 2026년 초부터 품고 있을지 모를 “Codex에는 훅이 없다”는 가정은 더 이상 유효하지 않습니다.
• 두 도구 모두 빠르게 나아지고 있습니다. 이 글의 비교는 유통기한이 연 단위가 아니라 주 단위로 측정되며, 바로 그래서 날짜가 적힌 개정 줄을 달고 있습니다.

FAQ

같은 프로젝트에서 두 도구를 함께 쓸 수 있나요?

네. CLAUDE.md와 AGENTS.md는 충돌 없는 별개의 파일입니다. 각 도구는 자기 지침 파일을 읽고 다른 쪽은 무시합니다. 저는 진행 중인 프로젝트들에서 둘 다 유지합니다.

초보자에게는 어느 도구가 더 나은가요?

Codex는 설정 장벽이 더 낮습니다. 세 가지 샌드박스 모드와 세 가지 승인 정책이 대부분의 사용 사례를 덮습니다⁵. Claude Code의 힘은 훅과 스킬에서 나오는데, 이는 설정에 투자가 필요합니다. 이미 익숙한 모델(Claude 또는 GPT)이 있는 쪽부터 시작하세요.

비용은 어떻게 비교되나요?

둘 다 각자의 API를 통한 토큰 기반 요금제를 씁니다. Claude Code는 Anthropic의 요금 체계로, Codex는 OpenAI의 크레딧 체계로 동작합니다. Composio의 독립 벤치마킹에 따르면 Codex는 비슷한 결과를 내는 데 2~4배 적은 토큰을 소비했습니다. Figma 플러그인 작업에서 Claude Code는 620만 토큰을, Codex는 150만 토큰을 썼습니다²². 토큰 효율이 곧바로 비용으로 환산되지는 않지만(토큰당 단가가 다릅니다), Codex의 더 낮은 토큰 소비는 예산이 빠듯한 작업 흐름에서 측정 가능한 이점입니다.

AGENTS.md가 Claude Code에서 동작하나요?

현재는 아닙니다. Claude Code는 CLAUDE.md를, Codex는 AGENTS.md를 읽습니다. 두 형식은 내용을 서로 옮기기 쉬울 만큼 비슷하지만, 자동으로 교차 읽기를 하지는 않습니다. 내용이 겹치므로 양쪽을 다 쓰는 데 드는 수고는 미미합니다.

IDE 연동은 어느 쪽이 더 낫나요?

Codex의 표면이 더 넓습니다. 멀티태스킹과 떠 있는 창을 갖춘 macOS 데스크톱 앱, VS Code·Cursor·Windsurf용 IDE 확장, 그리고 Chrome 확장이 모두 하나의 세션 모델을 공유합니다¹⁶. Claude Code는 확장을 통한 VS Code, 플러그인(베타)을 통한 JetBrains와 연동됩니다¹⁷. 둘 다 잘 동작합니다. 선택은 CLI 우선(Claude Code)을 선호하느냐, GUI/멀티 표면 발자국(Codex)을 선호하느냐에 달려 있습니다.

참고 문헌