Claude Code vs Codex 비교(클로드 코드 vs 코덱스 차이): 둘 다 매일 쓰며 일을 나누는 법

카테고리 없음

Claude Code vs Codex 비교(클로드 코드 vs 코덱스 차이): 둘 다 매일 쓰며 일을 나누는 법

코드짜는아빠 2026. 10. 4. 21:46

같은 저장소, 에이전트 둘

Claude Code는 코드를 직접 고치지 않는다. 2026년 8월 29일부터 지키는 규칙. 설계와 검토는 Claude Code가 하고, 코드는 Codex CLI가 쓴다. 두 에이전트는 같은 저장소에서 일하고, 9월 30일 기준 --version 으로 보면 Claude Code 2.1.285, Codex CLI 0.159.2였다.

공식 문서의 소개 문장만 놓고 보면 두 도구가 하는 일은 거의 겹친다(2026-09-30 조회).

	Claude Code	Codex CLI
공식 소개	코드베이스를 읽고, 파일을 고치고, 명령을 실행하는 에이전트형 코딩 도구	터미널을 떠나지 않고 코드를 살피고, 고치고, 명령을 실행하고, 반복 작업을 자동화
설치(공식 스크립트)	`curl -fsSL https://claude.ai/install.sh \| bash`	`curl -fsSL https://chatgpt.com/codex/install.sh \| sh`
대화 없이 부르기	`claude -p`	`codex exec`
저장소 규칙 파일	`CLAUDE.md`. `AGENTS.md` 도 읽을 수 있음	`AGENTS.md`

출처: Claude Code 개요(https://code.claude.com/docs/en/overview), Codex CLI(https://learn.chatgpt.com/docs/codex/cli), 2026-09-30 조회.

나는 Codex를 npm으로 설치했고(npm i -g @openai/codex), 모델은 설정 파일(~/.codex/config.toml)에 고정해 뒀다. codex exec 의 기본 샌드박스와 옵션은 지난 글에 표로 정리했다.

둘 다 코드를 읽고 고치고 실행할 수 있다. 그래서 누가 무엇을 할지는 저장소 규칙에 적어 뒀다. 저장소 맨 위의 AGENTS.md 첫머리에 「Codex CLI, Claude Code, 그 밖의 코딩·운영 에이전트 모두에게 적용」이라고 적혀 있고, CLAUDE.md 는 「작업 전에 AGENTS.md 부터 읽어라」로 시작한다. 두 에이전트가 같은 규칙집을 읽는 셈이다.

클로드 코드와 코덱스 차이: 지금 분담표

지금은 이렇게 나눈다.

일	맡는 쪽
요구사항 정리, 설계 문서, 작업 명세	Claude Code
코드 작성·수정, 명세에 적힌 로컬 테스트	Codex CLI (`codex exec`)
`git diff` 확인, 샌드박스 밖 테스트 재실행, 실측 dry-run	Claude Code
독립 코드 리뷰	Claude Code의 리뷰 에이전트
배포 여부 결정	나

규칙은 먼저 있었고, 지켜지지 않았다

역할 경계는 2026년 7월 17일에 승인한 도구 경계 문서에 이미 있었다.

Claude: 전략, 요구사항 문서, 카피, 설계 판단, QA·코드 리뷰 판단, 위험 분류
Codex: 저장소 조사, 파일 수정, 코드 구현, 로컬 테스트·빌드, 로컬 검증 증거, 승인된 경우의 Git 작업

8월 27일, 내가 물었다. 「… codex 담당이지 않나?」 맞는 말. 그날 Claude Code는 스크립트 4개와, 이미지 중계 기능과 그 테스트를 직접 짰다. 둘 다 Codex 몫인데.

당시에는 Codex에 넘기는 일 자체가 따로 승인받는 단계였고, 내가 터미널에서 codex exec 를 대신 돌려야 한다고 문서에 적혀 있었다. 이유는 Claude Code 세션에서는 codex exec 가 막힌다는 것. 같은 날 직접 돌려 보니 막히지 않았다. 그날 분류기에 막힌 건 다른 스크립트의 작성과 실행이었는데, 그 관찰을 codex exec 에 옮겨 적은 거다.

8월 29일에 또 어겼다. 폰트 파일을 필요한 글자만 남기게 자르는 코드, 앱 화면의 아래 시트를 끌어올리는 높이 계산, CSS 겹침 순서와 포커스 테두리를 Claude Code가 직접 고쳤다. 세션 시작 브리핑에 「구현은 Codex, Claude는 전략·카피·설계·리뷰 판단」이 적혀 있던 상태에서. 그날 내가 한 말은 이랬다. 「우리 개발 프로세스를 제대로 안 지키는 클로드 CLI가 문제다.」

그날부터 규칙이 바뀌었다.

구현 요청이 오면 Claude Code는 코드를 만지지 않고 작업 명세(task spec)를 쓴다.
Codex에 넘기는 일은 더 이상 따로 승인받는 단계가 아니다. Claude Code가 codex exec 를 직접 돌린다.
나에게 「이 명령을 실행하세요」라고 넘기지 않는다.
Codex가 자주 멈춘다는 사실은 Claude Code가 대신 구현할 이유가 되지 않는다. 멈추면 다시 돌리거나 보고한다.

개발 역할 파일에는 「구현한 에이전트는 자기 결과물에 QA·코드 리뷰 판정을 내리지 않는다」는 멈춤 규칙도 있다. Codex가 쓰고 Claude Code가 확인하면 짠 쪽과 보는 쪽이 처음부터 다르다.

일을 넘기는 방법: 작업 명세 한 장

넘길 때는 작업 명세 파일 하나를 쓴다. 9월 30일에 실제로 넘긴 명세의 앞부분(경로 일부 생략).

---
id: build_claude_stack_watch_mcp_source_and_real_dryrun_2026_09_30
type: task_spec
status: approved
agent: development_agent
dry_run: false
approved_by: Human CEO
approved_at: 2026-09-30
external_actions: false
---

Tool route: Codex CLI hand-off

본문에는 목표, 바꿀 파일, 테스트 기준과 함께 할 수 있는 일(Allowed Actions)과 하면 안 되는 일(Forbidden Actions)을 적는다. 아래는 같은 명세의 일부.

## Allowed Actions
- 위 파일과 `ops/claude_stack/*.test.mjs` 수정 (Codex CLI)
- `node --test ops/claude_stack/*.test.mjs` 로컬 실행
- `node ops/claude_stack_watch.mjs --dry-run` 로컬 실행(읽기 전용 npm · GitHub 조회 포함, 상태 쓰기 없음)
- 수정 후 git 커밋 · 푸시(이 변경분 경로만, Claude 가 QA 뒤)

## Forbidden Actions
- 배포 — `~/services/ai-cos-ops/current` 전환은 QA 뒤 Human CEO 확인을 받고 따로 한다
- `~/.claude.json` · `~/.claude/settings.json` 수정, MCP · 플러그인 · CLI 설치 · 업그레이드

그다음 Claude Code가 이 명세를 가리키는 프롬프트 파일을 만들고, 아래 모양으로 Codex를 부른다.

codex exec --approve-for-me -o last_message.txt "$(cat prompt.md)" < /dev/null > codex.log 2>&1
echo "CODEX_EXIT=$?"

codex exec --help 의 --approve-for-me 설명은 「승인 요청을 workspace-write 샌드박스의 자동 검토로 넘긴다」. 이 옵션만으로 파일을 고칠 수 있어서 --sandbox 는 따로 주지 않는다. < /dev/null 을 붙이는 이유, 종료 코드를 codex 바로 뒤에서 받는 이유, Codex의 「완료」 보고를 그대로 믿지 않는 이유는 지난 글에 적었다.

Codex가 착수를 거부한 날들

명세에서 실행 권한의 기준은 frontmatter(맨 위 --- 사이)다. CLAUDE.md 의 첫 번째 규칙이고, AGENTS.md 에도 「task spec을 읽어라. 그 frontmatter가 실행의 기준이다」라고 적혀 있어 Codex도 같은 규칙을 읽는다. 명세에 틀리거나 빠진 곳이 있어서 Codex가 코드를 한 줄도 건드리지 않고 돌아온 일이 여러 번 있었다.

날짜	명세에 있던 것	Codex의 반응
9월 21일	frontmatter는 `external_actions: false` 인데, Allowed Actions에 `systemctl` 실행과 릴리스 전환이 있음	`[APPROVAL_REQUIRED]` 로 아무것도 하지 않고 반환
9월 26일	`approved_by: human_ceo` (정해진 값은 `Human CEO`)	종료 코드 0으로 끝났지만 착수는 거부
9월 28일	구현 명세에 「Codex CLI로 넘기는 작업인지」가 적혀 있지 않음	역할 파일의 멈춤 규칙으로 코드 없이 반환

9월 21일에는 Codex로 넘기는 작업인지가 빠진 명세 두 개도 연달아 넘겼다. 첫 번째는 Codex가 그대로 수행, 두 번째는 거부. 기록에는 「거부한 쪽이 옳다」고 적었다.

이 네 번 모두 고쳐야 할 쪽은 명세를 쓴 Claude Code였다. 거부될 때마다 왕복 한 번이 통째로 버려지고. 그래서 지금은 명세를 쓸 때 세 가지를 한 번에 맞춘다.

Allowed Actions에 유닛 재시작, 릴리스 전환, 외부 호출, 커밋·푸시가 들어가면 그 자리에서 external_actions 도 같이 고친다.
approved_by 는 정확히 Human CEO.
구현 명세에는 Tool route: Codex CLI hand-off 줄을 넣는다. 명세 생성 스크립트의 틀에는 이 줄이 없어서 손으로 챙긴다.

이 줄은 9월 28일 거부 이후 명세에 들어가기 시작했다. 저장소를 검색하면 9월 28일부터 30일 사이에 만든 명세 22개에 이 줄이 있다.

앞에서 보여 준 9월 30일 명세도 첫 번째 규칙을 어겼다. Allowed Actions 마지막 줄에 「수정 후 git 커밋 · 푸시」가 있는데 frontmatter는 external_actions: false 다. 그 줄은 QA 뒤 Claude Code가 할 일로 적혀 있었고, Codex는 이 명세를 거부하지 않았다. 이 글을 검토하다가 찾은 것. 커밋 · 푸시가 이 규칙에 들어간 것부터가 9월 27일에 같은 누락이 한 번 있었기 때문이다.

설계 문장 하나가 코드 75줄이 됐다

9월 30일, 감시 스크립트가 ~/.claude.json 에서 MCP 서버 목록을 읽게 하는 작업을 넘겼다. 이 파일에는 계정 정보와 MCP 서버에 넘기는 환경 변수 값(env)도 들어 있다. 설계 문서에는 env 를 「변수에 담지도 않는다」고 썼다.

Codex는 그 문장을 지키는 코드를 짰다. JSON 스캐너를 직접 만들어 넣은 거다. 독립 코드 리뷰 기록에는 약 75줄로 남아 있다. 리뷰 판정은 「보안 이점 없이 유지 부담만 크다」. 파일 원문은 어느 방법으로 읽든 메모리에 올라온다. 스캐너가 막아 주는 것은 없었다.

설계 문서를 고쳤다. 읽는 방법은 JSON.parse 로, 규칙은 아래처럼. 「인벤토리는 command · args · type 만 새 객체로 복사해 꺼내고, 파싱한 원본 객체는 버린다. env · headers 값은 인벤토리 결과 · 상태 · 로그 · 알림 어디에도 나가지 않는다. 테스트로 env 값이 인벤토리 결과에 없음을 확인한다.」 Codex 2차 실행이 스캐너를 이렇게 바꿨다.

const parsed = JSON.parse(readFile(path, "utf8"));
// Copy only these three fields into new objects before leaving the parsed config behind.
servers = [parsed?.mcpServers, parsed?.projects?.[PROJECT_PATH]?.mcpServers]
  .flatMap((scope) => objectEntries(scope).map(([, server]) => ({
    type: /* … */,
    command: typeof server?.command === "string" ? server.command : undefined,
    args: Array.isArray(server?.args) ? server.args.filter((arg) => typeof arg === "string") : []
  })));

그날 세션 기록에 남긴 한 줄은 「설계 문구가 과하면 구현이 과해진다」. 고친 문장에는 결과 어디에 무엇이 없어야 하는지와, 그걸 테스트로 확인한다는 것까지 들어 있다.

샌드박스 밖에서 한 번 더

같은 작업의 1차 실행에서 Codex는 스스로 이렇게 보고했다. 샌드박스 안에서는 stdin을 쓰는 테스트 2개와 네트워크가 필요한 --dry-run 실측을 돌리지 못했다. OpenAI 문서는 --approve-for-me 가 쓰는 workspace-write 샌드박스를 인터넷을 쓰거나 작업 폴더 밖으로 나가기 전에 승인을 묻는 모드로 설명한다(2026-09-30 조회).

그래서 Codex가 돌려준 뒤에는 Claude Code가 샌드박스 밖에서 다시 돌린다. 이날 기록.

1차 뒤 테스트를 밖에서 다시 실행: 50/50 통과
2차(스캐너 교체) 뒤: node --test ops/claude_stack/*.test.mjs 52/52 통과
실측 --dry-run 종료 코드 0, 감시 대상 9개, MCP 3개가 모두 「변경 있음(delta)」으로 나옴
~/.claude.json 의 env · headers 값 노출 0건, 상태 파일 수정 시각 그대로

배포는 그다음, 내가 결과를 보고 배포하라고 한 뒤에.

예외가 열려 있던 나흘

9월 23일부터 26일까지는 Claude Code가 코드를 직접 짰다. Codex 사용 한도에 걸려 있던 기간이라, 그동안은 Claude Code가 짜라고 내가 지시해 둔 거다. 그때도 넘겨받은 명세가 허락하지 않은 배포 · 푸시 · 실서비스 쓰기는 하지 않았다. 한도 해제 시각이 지난 9월 27일에 예외를 닫았고, 지금은 다시 Codex가 먼저다. 같은 예외가 또 필요하면 내가 새로 말해야 한다. 한도 이야기는 3편에 따로 적었다.

같이 쓰기 시작한다면 먼저 권하는 세 가지

두 도구를 같이 쓰기 시작한다면 세 가지부터 권한다. 첫째, 넘기는 문서 한 곳에 해도 되는 일과 하면 안 되는 일을 적고, 그 문서의 다른 부분과 어긋나지 않게 할 것. 둘째, 설계 문장은 결과로 확인할 수 있게 쓴다. 셋째, 돌아온 결과는 받은 쪽이 다시 돌려 본다.

다음 글에서는 바이브코딩으로 자동화를 만들다 터진 사고 세 가지를 적는다. 같은 작업이 두 번 돌고, 없는 프로세스를 있다고 판정했던 일들.

이 블로그에 쓴 글들을 바탕으로 전자책과 템플릿 묶음을 만들어 볼까 고민하고 있어요. 낼지, 낸다면 언제일지는 아직 미정.

나오면 알림을 받고 싶은 분은 제목을 [출시 알림]으로 해서 codenara.contact@gmail.com 으로 메일 주세요.

개인정보 안내: 받은 메일 주소는 출시 알림 한 번 보내는 데만 쓰고, 보내고 나면 지워요. 내지 않기로 하면 그때 지우고, 요청하시면 그 전에라도 바로 지웁니다.

두 에이전트의 분담이나 작업 명세 틀을 팀 환경에 맞게 세팅해 보고 싶다면 codenara.contact@gmail.com 으로 연락 주세요. 교육·세팅 문의는 따로 받고 있어요.