Claude Code 29개 도구 vs Codex 7개 도구: 정반대의 설계 철학

Claude Code와 Codex 모두 매주 업데이트를 쫓아다니는 것에 지쳐서, 기본 원리부터 다시 살펴보기로 했습니다. 찾을 수 있는 모든 SDK 타입 정의, 시스템 프롬프트, 설정 스키마를 열어봤습니다. 각 도구가 무엇을 하는지뿐만 아니라, 왜 도구 수가 이렇게 극단적으로 다른지를 이해하고 싶었습니다.

Claude Code는 29개의 도구를 제공합니다. Codex는 7개를 제공합니다. 이 비율이 계속 마음에 걸렸는데, 단순한 기능 차이일 수는 없었습니다. 최고의 엔지니어를 보유한 두 팀이 우연히 4:1의 비율에 도달하지는 않습니다. 이 차이는 의도적인 것이며, 그 이유를 살펴보면 AI가 개발 환경과 상호작용하는 방식에 대한 두 가지 진정으로 다른 철학이 드러납니다.

도구 세분화는 보안 결정입니다

가장 눈에 띄는 차이점은 각 도구가 파일 작업을 처리하는 방식입니다. Claude Code는 파일 조작을 Read, Write, Edit, MultiEdit의 네 가지 별도 도구로 분리합니다. 검색도 전용 도구를 갖추고 있어 Grep과 Glob이 Bash와 완전히 독립적으로 작동합니다. 덕분에 settings.json을 설정해 Read는 허용하되 Write는 차단할 수 있습니다. 단 하나의 파일도 수정 권한을 부여하지 않고 에이전트가 코드베이스를 검색하게 할 수 있습니다. 권한 제어는 도구 수준에서 이루어집니다.

Codex는 다른 경로를 택했습니다. shell, apply_patch, file_read를 핵심 기본 요소로 에이전트에게 제공합니다. 그 외 모든 것은 셸을 통해 처리됩니다. 파일을 검색하고 싶으면 셸 명령어를 사용합니다. 디렉토리 목록을 보고 싶어도 셸입니다. 보안은 도구 수준의 권한이 아니라, 특정 셸 명령어를 패턴 매칭해 allow, prompt, block으로 분류하는 execpolicy 규칙에서 나옵니다.

어느 쪽이 틀린 것은 아닙니다. Claude Code의 모델은 세밀한 잠금 장치를 제공하지만 더 큰 도구 표면을 관리해야 합니다. Codex의 모델은 추론하기 더 단순하지만, 보안 적용이 셸 명령어의 문자열 매칭으로 넘어가면서 명령어가 창의적으로 구성될 경우 취약해집니다. 잘 구성된 파이프 체인이 단순한 버전을 위해 작성된 execpolicy 규칙을 우회하는 경우를 여러 번 봤습니다.

전체 분류는 다음과 같습니다.

• Claude Code (29개 도구): 파일 도구 4개 (Read/Write/Edit/MultiEdit), 검색 도구 3개 (Glob/Grep/LS), 웹 도구 2개, cron 도구 3개, MCP 도구 4개, Bash 등
• Codex (7개 도구): shell, apply_patch, file_read, web_search, update_plan, write_stdin, js_repl

스킬 배포 방식이 생태계를 가릅니다

두 도구 모두 단일 SKILL.md 파일로 스킬 동작을 정의하는 Agent Skills 오픈 표준을 채택했습니다. 구조는 동일합니다. 배포 모델은 그렇지 않습니다.

Codex는 중앙화된 배포 시스템을 구축했습니다. $skill-installer를 실행하면 OpenAI의 공식 스킬 저장소에서 엄선된 스킬을 가져옵니다. GitHub URL을 전달하면 서드파티 스킬도 설치할 수 있습니다. 대화를 통해 새로운 스킬을 생성하는 $skill-creator도 있습니다. 경험이 npm과 비슷합니다. 명령어 하나, 레지스트리 하나, 즉시 사용 가능합니다.

Claude Code는 반대 방향을 택했습니다. .claude/skills/에 SKILL.md 파일을 직접 생성하거나, /plugin marketplace add를 통해 git 저장소에서 번들을 설치합니다. 공식 단일 레지스트리는 없습니다. 스킬은 커뮤니티 저장소, 공유 링크, 입소문을 통해 발견됩니다.

처음에는 Codex의 중앙화된 모델을 선호했는데, 검색성이 더 뛰어나기 때문입니다. 하지만 몇 주간 두 도구를 모두 사용해본 후, 탈중앙화 방식에는 진정한 장점이 있음을 알았습니다. 세션 도중 스킬 파일을 편집하면 재시작 없이 즉시 변경 사항이 적용됩니다. Codex의 설치된 스킬은 변경 시 재설치가 필요합니다. 커스텀 워크플로를 반복적으로 개선할 때, 이 차이는 예상보다 훨씬 중요하게 느껴졌습니다.

한눈에 보는 비교입니다.

• 호출 방식: Claude Code는 /skill-name, Codex는 $skill-name
• 저장 위치: .claude/skills/ vs .agents/skills/
• 내장 스킬: Claude Code는 /simplify, /batch, /loop, /claude-api를 제공하고, Codex는 $skill-installer, $skill-creator를 제공합니다
• 배포: 탈중앙화 마켓플레이스 vs 중앙화 저장소

세션 진단 기능에서 차이가 두드러집니다

두 도구 모두 /model, /plan, /review, /clear, /fast 같은 기본 명령어를 공유합니다. 차이는 세션 내부 상태 파악 기능에서 나타납니다.

Claude Code는 세션 내부에서 일어나는 일을 파악하는 데 많은 투자를 했습니다. /compact는 컨텍스트 압축을 수동으로 트리거합니다. /context는 로드된 내용을 보여줍니다. /cost는 실시간으로 토큰 소비를 추적합니다. /doctor는 설정 문제를 진단합니다. /rewind는 이전 대화 상태로 되돌아갑니다. /insights는 한 달간의 사용 패턴을 분석하고 개선 사항을 제안합니다. /usage는 세션 전반에 걸친 누적 소비량을 보여줍니다. 세션 상태를 이해하고 관리하는 데만 전념하는 명령어가 일곱 개입니다.

Codex는 다른 방향에 집중했습니다. /personality는 에이전트의 커뮤니케이션 스타일을 조정합니다. /theme은 시각적 외관을 변경합니다. /apps는 연결된 애플리케이션을 관리합니다. 이것들은 진단 도구가 아닌 UX 커스터마이징 기능입니다.

이것은 더 깊은 철학적 분열을 반영합니다. Claude Code는 세션을 능동적으로 모니터링하고 조종해야 하는 대상으로 취급합니다. Codex는 경험을 커스터마이징하는 데 집중하는 동안 백그라운드에서 알아서 작동해야 하는 것으로 취급합니다. 몇 달간 사용해본 후, 두 가지 모두 원하게 됐습니다. 진단 기능은 세션이 잘못될 때 구해주지만, 상세한 아키텍처 작업과 빠른 버그 수정 사이를 오갈 때 성격을 조정할 수 있는 것도 마음에 듭니다.

• Claude Code (약 35개 명령어 + 4개 번들 스킬): /compact, /context, /cost, /doctor, /rewind, /insights, /usage 같은 세션 진단 기능이 풍부합니다
• Codex (약 19개 명령어): /personality, /theme, /copy, /apps, /skills, /agent, /tools로 UX 커스터마이징이 더 강력합니다

팀 아키텍처는 서로 다른 전제에서 출발합니다

각 도구가 멀티 에이전트 협업을 처리하는 방식에서 아마도 가장 깊은 설계 차이가 드러납니다.

Claude Code의 Agent Teams는 P2P 통신을 사용합니다. 팀원들이 리드 에이전트를 통하지 않고 서로 직접 메시지를 주고받습니다. 공유 작업 목록을 갖추고 자율적으로 조율합니다. 2개에서 16개 에이전트를 실행할 수 있으며, 에이전트들이 서로 협의해 작업을 분담합니다. 리팩터링 작업에서 세 개의 에이전트로 테스트해봤는데, 토큰 소비가 같은 작업을 단일 세션으로 진행할 때보다 3배에서 7배 높았습니다. 조율 오버헤드는 실재합니다. 하지만 작업이 병렬 탐색에서 진정한 이점을 얻을 때(서로 다른 가설을 동시에 검증하는 에이전트들로 레이스 컨디션을 디버깅하는 경우처럼), P2P 모델은 더 빠르게 답을 찾아냅니다.

Codex는 허브-스포크 모델을 사용합니다. 자식 에이전트는 부모에게만 보고합니다. 수평 통신은 없습니다. spawn_agents_on_csv 명령어는 CSV 파일에서 에이전트를 대량 생성하는데, 각 작업 단위가 독립적인 병렬 처리에 최적화되어 있습니다. “이 마이그레이션을 200개 파일에 적용하라” 또는 “이 목록의 모든 엔드포인트에 대해 이 점검을 실행하라” 같은 작업에 적합합니다.

P2P가 항상 더 나은 것은 아닙니다. 단순한 배치 작업에서 Claude Code의 에이전트들이 서로 겹치는 작업을 계속 논의하느라 상당한 토큰을 낭비했습니다. 그 특정 작업에는 Codex의 허브-스포크가 올바른 선택이었을 것입니다.

• Claude Code: 공유 작업 목록을 통한 P2P 메시징, 2개에서 16개 에이전트, tmux 분할 창 지원
• Codex: 허브-스포크 아키텍처, spawn_agents_on_csv를 통한 CSV 기반 대량 에이전트 생성

훅 세분화가 자동화 깊이를 결정합니다

Claude Code는 도구 실행의 여러 수명 주기 지점에서 개입할 수 있습니다. PreToolUse는 도구가 실행되기 전에 발동해 호출을 검증하거나 수정할 수 있습니다. PostToolUse는 실행 후에 발동하므로 모든 파일 저장 시 자동으로 실행되는 포매터를 연결할 수 있습니다. Notification 훅은 에이전트 통신을 캡처합니다. PreCompact는 컨텍스트 압축 전에 발동해 중요한 정보를 보존할 기회를 제공합니다. HTTP Hooks는 외부 URL에 JSON을 POST할 수 있어 Claude Code를 CI 파이프라인, Slack, 또는 커스텀 대시보드에 연결합니다.

Codex는 단순하게 유지합니다. 셸 명령어에 적용되는 allow/prompt/block 규칙이 담긴 하나의 execpolicy 파일이 에이전트 동작을 제어하는 전체 확장성 표면입니다.

모든 Write 작업 후 Prettier를 실행하는 PostToolUse 훅을 설정했습니다. 5분이 걸렸고 포매팅 관련 후속 프롬프트 유형 하나를 완전히 없앴습니다. 이런 종류의 정밀한 자동화는 Codex 모델에서는 불가능한데, 거기서는 모든 프롬프트에 “작성 후 prettier를 실행하라”고 포함하거나 스킬에 내장해야 합니다.

하지만 Codex의 단순함도 가치가 있습니다. 잘못 구성된 훅으로 Codex 설정을 실수로 망가뜨린 적은 한 번도 없습니다. Claude Code에서는 두 번 그런 일이 있었는데, 한 번은 정상적인 파일 읽기를 조용히 차단해 20분간 혼란스러운 디버깅을 유발한 PreToolUse 훅 때문이었습니다.

• Claude Code: PreToolUse, PostToolUse, Notification, PreCompact, HTTP Hooks
• Codex: allow/prompt/block 세 가지 수준의 execpolicy 규칙 파일

기능 목록이 아닌 아키텍처를 선택하세요

29 대 7 비교는 한 도구가 다른 도구보다 더 뛰어나다는 것이 아닙니다. 동일한 설계 질문에 대한 두 가지 다른 답변입니다. AI 코딩 에이전트는 자신의 기능을 개별적으로 제어 가능한 단위로 얼마나 세분화해야 할까요?

Claude Code는 “모든 것”이라고 답합니다. 모든 작업이 자체 도구, 자체 권한 표면, 자체 훅 포인트를 갖습니다. 설정 복잡성이 높아지는 대신 최대한의 제어권을 제공합니다. Codex는 “핵심만”이라고 답합니다. 핵심 작업에는 전용 도구를 제공하고 나머지는 정책 기반 가드레일이 적용된 셸을 통해 처리합니다. 세분화를 포기하는 대신 단순함을 제공합니다.

특정 프로젝트에 어느 도구를 사용할지 선택할 때, 기능 목록은 거의 중요하지 않습니다. 중요한 것은 해당 프로젝트에 세밀한 권한 제어(규제 코드베이스, 서로 다른 접근 수준을 가진 여러 기여자)가 필요한지, 아니면 가벼운 단순함(개인 프로젝트, 빠른 반복, 최소한의 설정)이 필요한지입니다. 그 위에 구축하는 아키텍처가 이후의 모든 워크플로 결정을 형성합니다.