터미널에서 동작하는 AI 코딩 에이전트로서, Anthropic의 Claude Code와 OpenAI의 Codex(Codex CLI)는 현재 가장 많이 비교되는 두 가지라고 생각합니다. 둘 다 단순히 "대화하며 코드를 작성하는" 도구에 그치지 않고, 외부 도구 연동·재사용 가능한 워크플로우·영속적인 지시·라이프사이클 제어까지 갖춘, 확장 가능한 에이전트 실행 기반으로 성장해 왔습니다.

이 기사에서는 두 가지를 다음과 같은 5가지 관점에서 나란히 놓고 분석합니다.

MCP (Model Context Protocol)— 외부 도구·데이터 소스와의 접속 -
Skills— 재사용 가능한 워크플로우의 패키지화 -
메모리/지시 (CLAUDE.md / AGENTS.md / Rules) — 영속적인 컨텍스트와 규칙 -
Subagents— 태스크 특화 서브 에이전트에 의한 병렬·분업 -
Hooks— 라이프사이클에 스크립트 주입 -
Plugins— 위 항목들을 하나로 묶어 배포하는 단위

각 기능에 대해 설계 사상·설정 방법·구체적인 예를 상세히 나열하겠습니다. 단순한 기능의 유무가 아니라, "왜 그런 설계가 되었는지", "어떻게 구분해서 사용해야 효과적인지"까지 깊이 있게 다루고자 하므로 내용이 다소 긴 기사가 되었습니다. 궁금한 장부터 읽으셔도 무방합니다.

참고로, 본 기사의 설정 예시에 등장하는 디렉토리명이나 파일명은 설명을 위해 대체되었습니다. 실제 환경의 경로를 그대로 공개하면 정보 유출로 이어질 수 있으므로, 본인의 환경에 맞춰 적절히 바꾸어 사용하시기 바랍니다. 또한, 두 도구 모두 업데이트 속도가 매우 빠른 영역이므로, 세부 사항은 공식 문서에서 최신 동작을 확인하는 것이 가장 확실합니다. 기사 말미에 참조한 문서 링크를 모아두었습니다.

이 기사는 "어느 쪽이 더 우수한가"를 결정하기 위한 비교가 아닙니다. 설계 사상의 차이를 이해하고, 자신의 워크플로우에 맞는 사용법을 찾기 위한 지도로 활용해 주시면 좋겠습니다.

또한, 두 도구에는 각각 독자적인 세부 기능이 많이 있지만, 이 기사에서는 Claude Code와 Codex가 공통적으로 갖춘 주요 기능(MCP·Skills·메모리/지시·Subagents·Hooks·Plugins)에 집중하여 비교합니다. 기능의 유무를 모두 나열하기보다, 두 가지를 동일한 선상에서 비교할 수 있도록 하기 위함입니다.

개별 기능으로 들어가기에 앞서, 양자의 설정 아키텍처(Architecture) 차이를 파악해 두면 이해가 수월해집니다. 이 부분이 두 도구의 성격을 결정짓는 부분이라고 느낍니다.

Claude Code는 "기능별로 최적의 형식을 선택하는" 스타일입니다. MCP 서버는 .mcp.json, 훅(Hook)이나 권한은 settings.json, 지시는 Markdown과 같이 용도별로 파일이 나뉩니다. 반면 Codex는 "설정은 config.toml에 모은다"는 TOML 중심의 사상을 가지고 있으며, MCP 서버도 서브 에이전트도 훅도 원칙적으로 동일한 설정 체계 안에서 기술할 수 있습니다.

또 하나, Codex를 이해하는 데 중요한 것이 신뢰(trust) 모델입니다. Codex는 프로젝트 하위의 .codex/ 레이어가 trusted 상태인 경우에만 project-local의 MCP·Rules·Hooks를 로드합니다. "리포지토리에 놓여 있는 설정만으로는 무조건 신뢰하지 않는다"는 자세가 곳곳에 일관되게 나타납니다. Claude Code 측에도 .mcp.json

의 프로젝트 스코프 승인이나 워크스페이스 트러스트(Workspace Trust)와 같은 유사한 메커니즘이 있지만, Codex는 이 trust(신뢰) 개념을 더욱 전면에 내세우고 있다는 인상을 줍니다.

흥미로운 점은 Codex의 플러그인 기구(Plugin mechanism)가 호환성을 목적으로 CLAUDE_PLUGIN_ROOT / CLAUDE_PLUGIN_DATA라는 환경 변수를 제공하고 있다는 점입니다. Agent Skills의 오픈 표준(agentskills.io)을 양측이 공유하고 있기도 하여, 에코시스템(Ecosystem) 측면에서는 완만하게 상호 운용성을 의식한 구조로 만들어지고 있다고 읽을 수 있습니다.

에이전트에게 "매번 동일한 전제 조건으로 동작해 주길" 바랄 때 가장 먼저 접하게 되는 영역이 바로 이곳입니다. 새로운 세션은 기본적으로 빈 컨텍스트(Context)에서 시작되므로, 영구적으로 적용되는 지시 사항을 어디에 작성하느냐가 작업 효율을 크게 좌우합니다.

Claude Code는 두 가지 메커니즘으로 지식을 유지합니다.

• CLAUDE.md — 사용자가 작성하는 영구적인 지시 사항
• 자동 메모리 (Automatic Memory) — Claude가 학습 내용이나 패턴을 스스로 기록하는 메모 (v2.1.59 이후 기본 활성화)

CLAUDE.md에는 4가지 스코프(Scope)가 있으며, 우선순위(읽기 순서)가 정해져 있습니다.

읽기 메커니즘이 다소 독특합니다. Claude Code는 현재 디렉토리(Current directory)에서 파일 시스템의 루트(Root)를 향해 상위로 거슬러 올라가며, 각 계층의 CLAUDE.md를 찾아 **모두 연결(Concatenate)**합니다. 순서는 루트 쪽에서 시작 지점 쪽으로 나열되므로, 시작 지점에 가까운 지시 사항이 나중에 읽힙니다. 하위 디렉토리 내의 파일은 Claude가 해당 디렉토리의 파일을 읽는 시점에 온디맨드(On-demand)로 읽어옵니다. 모노레포(Monorepo)에서 계층마다 규칙을 바꾸고 싶을 때 유용한 설계입니다.

파일을 분할하고 싶을 때는 @path/to/import 구문을 사용하여 임포트(Import)할 수 있습니다. 재귀적 임포트(Recursive import)는 최대 4홉(Hop)까지 가능합니다.

프로젝트 개요는 @README를 참조하세요.
# 추가 지시 사항
- git 워크플로우는 @docs/git-instructions.md를 따르세요

규칙을 정리하고 싶을 때는 .claude/rules/ 디렉토리를 사용할 수 있습니다. 하위의 .md 파일은 재귀적으로 발견되며, paths 프런트매터(Frontmatter)를 사용하면 특정 파일을 읽을 때만 적용되는 경로 전용 규칙을 작성할 수 있습니다.

이 paths 지정은 브레이스 확장(Brace expansion)이나 다중 패턴에도 대응하며, src/**/*.{ts,tsx}와 같이 묶어서 작성할 수 있습니다. paths를 지정하지 않은 규칙은 .claude/CLAUDE.md와 동일한 우선순위로 실행 시에 읽힙니다. 또한, 사용자 레벨의 ~/.claude/rules/도 사용할 수 있습니다. 여기에 배치한 규칙은 프로젝트 규칙보다 먼저 읽히기 때문에, 결과적으로 프로젝트 측의 규칙이 덮어쓰기(높은 우선순위)가 됩니다. 팀 전체에서 공유하고 싶다면 ln -s ~/shared-rules .claude/rules/shared와 같이 심볼릭 링크(Symbolic link)를 거는 방법도 있습니다.

---
paths:
- "src/api/**/*.ts"
...

AGENTS.md를 직접 읽지는 않지만, CLAUDE.md에서 임포트하거나 심볼릭 링크를 걸어 포함할 수 있습니다.

@AGENTS.md
## Claude Code 고유 지시 사항
`src/billing/` 하위의 변경에는 Plan Mode를 사용하세요

여기서 설계 사상으로서 강조되는 점은, "CLAUDE.md는 컨텍스트이지 강제 설정이 아니다"라는 점입니다. CLAUDE.md는 시스템 프롬프트(System prompt)가 아니라 후속 사용자 메시지(User message)로서 전달되기 때문에, 엄격한 준수는 보장되지 않습니다. 구체적이고 검증 가능한 지시(예: "커밋 전에 npm test를 실행하라")

실행하라" 등)와 같이 구체적일수록 따를 확률이 높아집니다. 확실하게 액션을 차단하고 싶다면, 후술할 PreToolUse 훅(Hook)을 사용하는 것이 공식적인 일관된 지침입니다.

CLAUDE.md가 "당신이 작성하는 지시"라면, 자동 메모리(Automatic Memory)는 "Claude가 스스로 남기는 기억"입니다. 버전 2.1.59 이후부터 기본적으로 활성화되어 있습니다. 당신이 수정이나 피드백을 주면, Claude는 거기서 학습한 패턴을 스스로 메모로 남기고, 다음 세션부터 이를 참조합니다.

저장 위치는 리포지토리(Repository)마다 준비되는 메모리용 디렉토리이며, 다음과 같은 구성이 됩니다 (경로는 설명을 위해 간략화되었습니다).

~/.claude/projects/<project>/memory/
├── MEMORY.md # 간결한 인덱스. 모든 세션에서 읽힘
├── debugging.md # 토픽별 상세 메모
...

여기서 중심이 되는 것이 MEMORY.md입니다. 이는 기억 전체의 목차에 해당하는 파일로, 각 세션 시작 시 상위 200행(또는 25KB 중 먼저 도달하는 쪽)이 읽힙니다. debugging.md와 같은 토픽별 파일은 목차로부터 필요에 따라 온디맨드(On-demand)로 읽히는 구조입니다. 이를 통해 기억이 늘어나더라도 세션 시작 시의 컨텍스트(Context) 소비를 일정하게 억제할 수 있습니다. CLAUDE.md가 길이에 상관없이 전체가 읽히는 것과는 대조적인 설계입니다.

저장 장소는 리포지토리 단위이므로, 동일한 리포지토리의 다른 워킹 트리(Working Tree)나 서브 디렉토리에서도 기억이 공유됩니다. 반면, 머신 로컬(Machine Local)에 저장되기 때문에 머신을 넘나드는 공유는 되지 않습니다.

주요 조작은 다음과 같습니다.

• /memory 명령어로 현재 읽히고 있는 CLAUDE.md나 규칙, 자동 메모리의 상태를 확인하고 온/오프(On/Off)를 전환할 수 있습니다.
• 비활성화하고 싶다면 설정에서 autoMemoryEnabled: false를 사용하거나, 환경 변수 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1을 사용합니다.
• 저장 위치를 바꾸고 싶다면 autoMemoryDirectory로 지정합니다.

서브 에이전트(Subagent)에게도 독자적인 자동 메모리를 갖게 할 수 있으며, 프런트매터(Frontmatter)에서 memory: user / project / local 중 하나를 지정합니다. 역할이 정해진 서브 에이전트에게 해당 역할 고유의 학습을 축적시키고 싶을 때 유용합니다.

자동 메모리는 어디까지나 "Claude가 학습한 메모"이며, 작성된 시점의 상황을 반영합니다. 파일명이나 절차가 바뀌면 오래된 정보가 될 수 있으므로, 확실히 지켜주길 바라는 전제 조건은 CLAUDE.md 측에 명시해 두는 것이 안정적입니다.

Codex는 작업 시작 전에 AGENTS.md를 읽습니다. 우선순위는 다음과 같습니다.

• 글로벌 (Global) — Codex 홈 (기본값 ~/.codex, CODEX_HOME으로 변경 가능). AGENTS.override.md가 있으면 그것을 사용하고, 없으면 AGENTS.md를 사용합니다. 이 레벨에서는 첫 번째로 발견된 비어 있지 않은 파일 하나만 사용합니다.
• 프로젝트 (Project) — 프로젝트 루트(보통 Git 루트)부터 CWD(현재 작업 디렉토리)까지 내려가며, 각 디렉토리에서 AGENTS.override.md → AGENTS.md → 폴백(Fallback) 명 순으로 체크합니다. 디렉토리당 파일은 하나까지입니다.
• 병합 (Merge) — 루트에서 아래로 연결합니다. CWD에 가까운 파일일수록 나중에 오므로, 나중에 오는 파일이 우선권을 갖습니다 (Last-one-wins).

합계 크기가 project_doc_max_bytes (기본값 32 KiB)에 도달하면 추가를 중단합니다. 상한에 도달하면 값을 높이거나, 중첩된 디렉토리로 분할하십시오.

글로벌 가이드라인의 예시입니다.

# ~/.codex/AGENTS.md
## Working agreements
- Always run `npm test` after modifying JavaScript files.
...

읽히고 있는지 확인하는 명령어도 준비되어 있습니다.

codex --ask-for-approval never "Summarize the current instructions."

기존의 다른 별칭 파일(예: TEAM_GUIDE.md)을 지시 파일로 취급하고 싶을 때는 폴백 명을 설정할 수 있습니다.

~/.codex/config.toml

project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]
project_doc_max_bytes = 65536

Codex의 Rules (experimental, 실험적 기능)는 Claude Code의 CLAUDE.md와는 성격이 조금 다릅니다. 이는 "샌드박스(Sandbox) 외부에서 Codex가 실행할 수 있는 명령어를 제어"하는 메커니즘으로, 권한 및 가드레일(Guardrails) 영역에 가깝습니다. 규칙은 Starlark 형식(Python과 유사하며, 부작용 없이 안전하게 실행할 수 있는 구문)으로 작성합니다.

# 접두사(Prefix)가 `gh pr view`인 명령어를 샌드박스 외부에서 실행하기 전에 확인합니다
prefix_rule(
pattern = ["gh", "pr", "view"],
...

decision은 allow / prompt / forbidden 세 종류가 있으며, 여러 개가 매칭될 경우 가장 제한적인 것(forbidden > prompt > allow)이 적용됩니다. match / not_match는 규칙을 불러올 때 검증되는 "인라인 유닛 테스트(Inline Unit Test)"로, 의도대로 매칭되는지 그 자리에서 확인할 수 있는 세심한 기능입니다. codex execpolicy check 명령어로 사전 테스트도 가능합니다.

codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- gh pr view 7888 --json title,body,comments

그렇다면 Codex 측은 어떨까요? Codex에도 **Memories (메모리)**라는 공식 자동 메모리 기능이 있습니다. 과거 스레드로부터 유용한 컨텍스트(Context)를 다음 작업으로 이어주는 메커니즘으로, Claude Code의 자동 메모리에 대응한다고 생각하면 됩니다. 안정적인 선호도, 반복되는 워크플로우(Workflow), 기술 스택, 프로젝트 규약, 이미 알려진 함정(Pitfalls) 등을 Codex가 스스로 축적합니다.

활성화는 설정 앱의 토글 또는 ~/.codex/config.toml에 기재하여 수행합니다. 작성 시점 기준으로 기본값은 비활성화(Disabled) 상태이며, 지역에 따라 이용이 불가능할 수 있습니다 (공식적으로 EEA, UK, 스위스는 초기에 제공되지 않는다고 명시되어 있습니다).

[features]
memories = true

동작은 [memories] 섹션에서 세부적으로 제어할 수 있습니다. 주요 키(Key)는 다음과 같습니다.

저장 위치는 ~/.codex/memories/이며, 마크다운(Markdown) 기반 파일로 축적됩니다. 메모리 생성은 턴(Turn) 내부가 아닌 백그라운드에서 수행되며, 스레드가 충분히 안정된 후에 요약되도록 설계되었습니다. 스레드 단위의 제어에는 /memories 명령어가 있어, 해당 스레드에 대해서만 "기존 메모리를 사용할지" 또는 "메모리를 생성할지"를 전환할 수 있습니다. 화면 컨텍스트로부터 메모리를 구축하는 Chronicle이라는 확장 기능도 있지만, 이는 옵트인(Opt-in) 방식의 리서치 프리뷰(Research Preview)이며 작성 시점 기준으로는 macOS의 ChatGPT Pro 사용자에게만 한정되어 있습니다.

한 가지 짚고 넘어갈 점은, Claude의 MEMORY.md

와 같은 '단일 목차 파일'이 Codex 측에 있는지는 공식 문서의 기술만으로는 명확하게 확인할 수 없었습니다. 공식 문서에서는 '요약·영구 엔트리·최근 입력·뒷받침 증거'와 같은 내용의 분류를 언급하는 데 그칩니다. 실제 구성은 사용 중인 환경에서 ~/.codex/memories/를 확인하는 것이 확실합니다.

혼동하기 쉬운 것이 'rules'라는 이름입니다. Codex에도 ~/.codex/rules/가 있지만, 이는 Claude의 .claude/rules/ (지시·컨텍스트 정리)와는 역할이 다릅니다. Codex의 Rules는 앞서 언급했듯이 Starlark로 작성하는 '샌드박스 외부 명령 실행 가능 여부 제어'로, AI에 대한 지시가 아니라 실행 레이어의 가드레일 (Guardrail)입니다. 이름은 같더라도 대응하는 기능이 아니라는 점에 주의하십시오.

Claude의 .claude/rules/와 역할이 가까운 것은 Codex의 AGENTS.md 중첩 배치입니다. Claude가 paths 글로브 (Glob) 패턴을 통해 '어떤 파일을 다루는지'에 따라 규칙을 나누어 적용하는 반면, Codex는 '어떤 디렉토리에서 작업하고 있는지'에 따라 각 계층의 AGENTS.md / AGENTS.override.md를 연결합니다. 전자는 파일 단위로 동적이며, 후자는 디렉토리 단위로 정적이라는 차이가 있습니다.

repo/
├── AGENTS.md # 리포지토리 전체의 규칙
└── services/
...

양쪽 모두 "지시 파일은 어디까지나 컨텍스트이며, 확실한 강제는 별도의 레이어에서 수행한다"는 생각은 공통적입니다. 차이점은 Claude Code가 자동 메모리라는 '에이전트가 스스로 학습하는' 방향으로 나아가고 있는 반면, Codex는 Rules를 통해 명령 실행의 가드레일을 선언적으로 작성할 수 있다는 점입니다. 어느 쪽이 더 좋다기보다는, 원하는 제어의 종류에 따라 선택하는 상황이 많을 것으로 보입니다.

MCP (Model Context Protocol)는 AI를 도구 및 데이터 소스에 연결하기 위한 오픈 표준입니다. 이슈 트래킹 시스템이나 데이터베이스, 디자인 도구 등에 직접 연결하여, 복사 및 붙여넣기를 거치지 않고 에이전트가 읽고 쓸 수 있도록 합니다. 두 도구 모두 이 표준을 지원합니다.

Claude Code는 HTTP (권장)·SSE (비권장)·stdio·WebSocket 트랜스포트 (Transport)를 지원합니다. 추가는 명령어 한 줄로 가능합니다.

# HTTP (권장)
claude mcp add --transport http notion https://mcp.notion.com/mcp
# 인증 헤더 포함
...

옵션은 모두 서버 이름의 앞에 두어야 하며, --를 사용하여 서버 이름과 명령어를 분리해야 한다는 점에 주의가 필요합니다.

스코프 (Scope)는 3가지 종류가 있으며, 우선순위가 정해져 있습니다.

팀에서 공유하고 싶은 서버는 .mcp.json에 project 스코프로 작성합니다.

{
"mcpServers": {
"shared-server": {
...

.mcp.json

내에서는 ${VAR}

나 ${VAR:-default}

형식을 사용하여 환경 변수 (Environment Variable)를 확장할 수 있습니다. 인증은 /mcp 명령어를 통한 OAuth 브라우저 로그인을 지원하며, 401/403 응답 시 인증이 필요한 서버로 자동 감지합니다.

Claude Code에서 특징적인 것은 **툴 검색 (Tool Search)**입니다. MCP 서버가 많아지면 툴 정의 (Tool Definition)만으로도 컨텍스트 (Context)가 압박을 받을 수 있지만, 툴 정의를 지연 로드 (Lazy Load)함으로써 소비를 억제합니다. ENABLE_TOOL_SEARCH 환경 변수로 동작을 제어할 수 있습니다.

MCP 툴의 출력이 너무 클 경우를 대비하여, 10,000 토큰을 초과하면 경고를 표시하며 MAX_MCP_OUTPUT_TOKENS로 상한을 조정할 수 있습니다. 리소스를 @server:protocol://resource/path 형식으로 참조하거나, MCP 프롬프트 (Prompt)를 /mcp__servername__promptname 슬래시 명령어로 호출할 수 있는 등 대화로의 통합도 세밀하게 설계되어 있습니다.

Codex는 stdio 서버와 Streamable HTTP 서버를 지원합니다. 추가 명령어는 다음과 같습니다.

codex mcp add context7 -- npx -y @upstash/context7-mcp

설정은 config.toml에 [mcp_servers.<server-name>] 테이블로 작성합니다. stdio의 예시입니다.

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
...

Streamable HTTP의 예시입니다. Bearer 토큰이나 OAuth를 지원합니다.

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
...

Codex의 MCP 설정에서 눈에 띄는 점은 **툴 단위의 승인 제어 (Approval Control)**입니다. 서버나 툴마다 승인 동작을 세밀하게 결정할 수 있습니다.

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
...

default_tools_approval_mode에서 auto/prompt/approve를 지정하고, 특정 툴만 tools.<tool>.approval_mode로 덮어쓸 수 있습니다. enabled = false로 삭제하지 않고 무효화하거나, required = true로 초기화에 실패하면 구동 자체를 중단하는 등의 운영 플래그도 갖추고 있습니다. 타임아웃은 startup_timeout_sec (기본 10초)와 tool_timeout_sec (기본 60초)로 조정할 수 있으며, 그 외에도 작업 디렉토리를 지정하는 cwd, 환경 변수에서 헤더를 제공하는 env_http_headers, OAuth 콜백을 고정하는 mcp_oauth_callback_port/mcp_oauth_callback_url 등의 키가 있습니다. CLI에서는 codex mcp add <name> --env KEY=VALUE -- <command> 형태로 환경 변수를 전달할 수 있습니다.

또 다른 Codex다운 특징은, MCP 서버가 초기화 시에 반환하는 instructions 필드를 Codex가 읽어 서버 전체의 가이드라인으로 활용하는 메커니즘입니다. 서버 제작자는 도구 선택 시 중요한 가이드라인이 확실히 보이도록 초기 512자를 self-contained(독립적)하게 작성할 것을 권장받습니다. OAuth 대응 서버로의 로그인은

codex mcp login <server-name>

으로 수행합니다.

Claude Code는 "도구가 늘어나도 컨텍스트를 점유하지 않는" 방향(도구 검색)에 투자하고 있으며, Codex는 "어떤 도구를 어떻게 승인할지"를 선언적으로 작성할 수 있는 방향으로 구축되어 있다는 색깔의 차이가 느껴집니다. 다수의 MCP 서버를 상용한다면 Claude Code의 지연 로딩이 효과적일 것이고, 도구 단위로 가드레일(Guardrail)을 설정하고 싶다면 Codex의 승인 모드가 적합해 보입니다.