어느새 “그래서 뭐가 더 좋냐?”고 물으면, 사실 커뮤니티에는 Codex가 좋다는 말이 많았습니다. 다만, Claude Code에 실망해 넘어간 사람들이 대부분이라 이미 객관성을 잃은 상태였고, 그렇기에 비교 우위를 제대로 짚어보고 싶었습니다. 공식 자료를 1차 소스로 두고 외부 측정과 분석, 여기에 커뮤니티 반응을 얹어 정리했습니다.

결론부터 말하면, 솔직히 둘 중 하나가 압도적으로 낫다는 답은 내릴 수 없습니다. 다만 Codex는 맡겨두고 결과를 받는 작업에, Claude Code는 옆에서 함께 조정해가는 작업에 더 잘 맞는 구도 정도가 보입니다. 토큰 한도는 분명히 Codex에 장점이 있지만, Claude Code는 그 생태계와 안전성에 장점이 있었고요. 같이 보시죠.

지난 한 달 사이 일어난 일

2026년 4월 16일, Anthropic이 Claude Opus 4.7을, 정확히 7일 뒤인 4월 23일에 OpenAI가 GPT-5.5를 발표했습니다. 그런 사이 Codex는 새로운 기능을 차례로 풀었고, 반대편 Claude Code 쪽에서는 성능이 아쉬워졌다는 말이 여기저기 올라왔습니다.

그런 와중에 등장 이래 쉬지 않고 잘 나가며 매일 쓰는 도구로 굳어 가던 Claude Code의 단독 우위가 흔들려 버렸습니다.

codex가 claude code보다 나은 평가를 받은 26년 5월 — <출처: 작가, Gemini로 제작>

균열을 만든 세 가지 원인

균열을 만든 원인을 모으면, 이렇게 세 가지입니다.

1. 토큰 양: GPT 5.5 > Opus 4.7

Opus 4.7의 새 토크나이저는 같은 영문 텍스트를 더 많은 토큰으로 매핑합니다. 공식 가이드는 1.0~1.35배라고 했는데, 외부 측정 결과 영문/코드 기준으로 1.20~1.47배까지 올라갔다고 합니다. 즉, 주간 한도가 더 빨리 찬다는 소리입니다.

반면 OpenAI는 같은 Codex 작업에서 GPT-5.4 대비 더 적은 토큰으로 더 나은 결과를 낸다고 발표했습니다. Vellum에 따르면 약 40% 정도 토큰 효율이 나온다고 합니다. MindStudio의 분석에서는 GPT-5.5가 Opus 4.7 대비 약 72% 적게 쓴다는 수치도 있었어요.

2. Codex가 따라잡은 것들

여기에 더해 Codex CLI에 새로운 기능들이 차례로 들어왔습니다.

4월 30일, 0.128.0: 여러 턴과 세션, 날짜에 걸친 목표를 설정해두는 /goal 워크플로
5월 7일, 0.129.0: /hooks 브라우저, Vim 모드, 플러그인 워크스페이스 공유가 한꺼번에 풀림. Chrome 확장은 같은 시기 별도 경로로 공개
5월 8일, 0.130.0: 모바일·데스크톱 작업을 인계하는 codex remote-control, Bedrock AWS 자격증명, 플러그인 공유 메타데이터

hooks·Vim 모드·Chrome 확장·모바일 연계 등은 Claude Code가 먼저 정착시켜둔 영역을 Codex가 따라잡은 겁니다. 특히, 랄프 루프(ralph Loop) 방법론을 옮겨놓은 기능인 goal은 Codex가 먼저 만들고 Claude Code가 뒤따라 출시했습니다. <참조: Codex Changelog>

3. Claude Code의 아쉬움

이처럼 Codex의 발전과 함께 반대편 Claude Code 쪽에서는 성능이 아쉬워졌다는 이야기가 여기저기서 들리기 시작합니다.

AMD 시니어 디렉터 스텔라 로렌조(Stella Laurenzo)의 측정에 따르면, Opus 4.7 출시 이후 6,852개 세션과 234,760번의 도구 호출을 분석했을 때 사고 깊이 중앙값이 67% 떨어졌고, 편집 한 번당 읽기 파일 수가 6.6에서 2.0으로 줄었다고 합니다. 또, 최근 Claude Code 쪽에는 세 차례 사고가 있었어요. 3월 4일 추론 디폴트 변경, 3월 26일 캐싱 버그, 4월 16일 Opus 4.7 출시 날, 엄격한 텍스트 길이 제한 프롬프트로의 변경 등이죠.

Anthropic - Codex 3~5월 사건사고 — <출처: 작가, Claude로 제작>

결국 도구를 쓰는 입장에서는 어제까지 잘 쓰던 게 오늘부터 별로라면, 배신감을 느낍니다. 이렇게 한 번 신뢰를 잃고 난 다음에는 여러 일들도 영 시원찮고 미덥잖아지죠.

다만 이건 흐름일 뿐 정말로 뭐가 더 나은지에 대한 답은 아닙니다. 이제 좀 더 본격적으로 차이를 정리해 보겠습니다.

Claude Code vs Codex; 성능 편

비교 글 여러 편과 커뮤니티 후기, 1차 벤치마크 수치를 한 자리에 모아 작업 유형별로 다시 정리해 봤습니다.

Codex vs Claude code, 작업 유형별 우세 도구 — <출처: 작가>

당연히 절대 우열이 아닙니다. 2026년 5월 시점 기준이고, 사례에 따라 반대 결과도 나오니까요. 부연 설명을 더해볼텐데요, 생각이 다르면 의견 남겨주시면 더 좋겠습니다.

1. Codex가 나은 영역

1-1. 일상 코딩. 특히, 명확한 스펙이 있을 때

Reddit 등 커뮤니티 댓글을 500개 이상 모아 정리한 dev.to 메타분석을 보면 65%가 데일리 코딩에는 Codex를 더 쓴다고 합니다. 이유는 결국 “토큰” 때문이죠. 조금 과장 같지만, “Claude한테 복잡한 프롬프트 하나 던지면 5시간 한도 절반이 그 자리에서 빠진다, Codex Plus $20는 종일 돌려도 막히지 않더라.”는 말이 나온 이유죠. 두 도구를 비교하고 측정한 글은 같은 작업에 Claude Code가 토큰을 4배 더 쓴다고 정리했습니다.

스펙이 또렷하기만 하면, 사람이 매 단계 확인할 이유가 없다는 것도 도움을 줍니다. “Codex는 권한 묻느라 멈추는 일 없이 끝까지 가는데, Claude는 자꾸 묻다가 멈춘다.”는 평가도 많고요. 애초에 한 번 권한 잡으면 끝까지 가는 Codex의 설계가 빛을 발하는 영역입니다.

1-2. 구조적 수정 (상위 모듈 패턴 인식)

특히, 구조가 잘 잡힌 코드베이스, 타입과 테스트가 가드레일로 채워진 환경에서는 Codex가 여러 파일을 한 번에 자율로 변환할 때 잘 굴러간다고도 합니다. “Codex는 잘 구조화된 코드베이스, 충분한 타입 체크와 테스트가 갖춰진 환경에서 다중 파일 변경을 자율적으로 잘 처리한다(sitepoint).”

1-3. PR 리뷰, 샌드박스 격리

“Codex PR 리뷰어는 어느 도구보다 낫지만, 실제 코딩은 Claude Code가 데일리 드라이버다(dev.to).” 출처를 알기 어려운 PR을 검토하는 상황이라면 커널 레벨 격리(Seatbelt + Landlock/seccomp)에 Codex Cloud 격리 컨테이너까지 더한 이 쪽이 기본값에서 안전하다고 합니다.

2. Claude Code가 나은 영역

2-1. 다중 파일·8시간 이상 장기 리팩터

모델 단위 분석 기준으로, mindstudio는 “Opus 4.7은 다중 파일 리팩터링과 버그 재현에서 특히 강한데, 실제 코드베이스에서 정말 중요한 게 이 영역이다.”라고 말했습니다. SWE-bench Pro에서 Opus 4.7이 64.3% 대 GPT-5.4 57.7%, SWE-bench Verified는 87.6% 대 74.9%로 Opus 쪽이 크게 앞서는 것도 이를 뒷받침하겠죠.

두 모델을 직접 비교한 ticnote는 “지저분한 요구사항을 끌고 가는 장기 작업은 Opus 4.7 쪽이 답을 보여주고, Codex는 빠르고 도구가 많이 도는 짧은 루프에서 빛난다”고 정리했고요. 컨텍스트도 Claude Code는 1M까지 추가 요금 없이 정식으로 지원하는데요, Codex는 아직 1M 컨텍스트를 지원하지 않습니다. 그러니 오히려 한참 끌고 가야 하는 작업이면 Claude Code 쪽이 자연스럽겠죠.

2-2. 테스트 작성·실행·자기 수정

Reddit 500+ 메타분석 리뷰에서는 Claude Code가 만든 코드가 “더 깔끔하고, 관용적이고, 구조가 잘 잡혀 있다”는 평가도 있습니다. Opus 4.7이 테스트 통과 기반 벤치마크에서 우세한 것도 이 흐름과 맞물리고요. 단, 수정 루프 속도 자체는 Codex가 빠르다는 보고도 있어요. 이런저런 작업이 모두 끝난 다음의 결과물 품질을 우선하면 Claude, 속도를 우선하면 Codex 쪽으로 볼 수도 있습니다.

2-3. 막연한 UI·디자인·사람 손맛 카피

mindstudio에 따르면, “Claude는 프론트엔드와 UI 작업에 강한데, 특히 코드베이스 전체를 따지면서 여러 파일을 손대고 시각적으로 다듬어야 할 때 그렇다. UI나 디자인 시스템처럼 사람이 직접 마주하는 영역이면 Claude Code가 자연스러운 선택이다.”라고 합니다. 좀 더 자세히, 한국 개발자 sean_kk가 클린 환경에서 비교한 후기를 보면, “Codex 결과물은 디자인이 훨씬 세련됐는데, 오류가 나거나 동작이 어긋났다.”라는 말도 있었습니다. 즉, 디자인 발상은 Codex가 더 좋게 나올 수 있지만, 동작·세부 조정까지 한 번에 잡히는 영역은 Claude Code 쪽이 낫다는 거죠.

주요 참고 글

Codex vs Claude Code: 위임 vs 검증 — <출처: 작가, Gemini로 제작>

한도 기준과 컨텍스트, 접근성

도구는 한 번 쓰고 마는 게 아니니까요. 한도와 컨텍스트가 마찬가지로 또 중요하겠죠.

1. 5시간 세션 기준 한도

Claude Code: Max 5x 약 88K 토큰, Max 20x 약 220K 토큰 (Anthropic 정확 수치 미공시.TokenMix등 헤비 유저 측정 기반 추정입니다.)
Codex: Plus 20달러 15~80개 메시지, Pro 100달러 80~400개 메시지, Pro 200달러 300~1,600개 메시지 (OpenAI Help Center rate card 기준. 메시지 한 개가 작업 한 건은 아닙니다. 작업 복잡도에 따라 가중치가 달라지거든요.)

2. 도구 안의 모델 컨텍스트 한계

Claude Code 1M 정식 출시, 추가 요금 없음
Codex 400K, 1M은 opt-in 요청 단계

3. 외부 도구 접근성

마지막으로, Claude Code를 외부 세션으로 여는 claude -p 명령어가 “월간 크레딧” 기반으로 바뀔 예정이라는 발표가 있었습니다. 슬랙이나 텔레그램에서 봇을 호출해 세션과 직접 소통하는 구조라면 꽤 영향을 줄만한 업데이트로, 이러한 외부 도구 접근성이 사용의 새로운 제한이 될 지도 모르겠습니다. 실제로 Anthropic이 OpenClaw 연결을 일시 차단하기도 했던 만큼, 이러한 접근성이 어떠한 영향을 미칠지 지켜볼 필요가 있습니다.

Claude Code vs Codex; 철학 편

그런데 보다 보니 궁금증이 생기더군요. 이런 도구의 차이는 어디에서 온 걸까요?

그래서 이 도구를 만든 기업들을 봤습니다. 그러니 어느 정도 기업의 정체성이 도구 디자인에 그대로 들어 있다는 느낌이 왔습니다. 결국 ‘누가’ 만드는지에 달렸다는 거죠. (철학과 설계는 관심이 없다면, 바로 결론으로 가도 좋습니다)

OpenAI vs Antrophic: AGI vs 안전 — <출처: 작가, Gemini로 제작>

두 회사의 정체성

Anthropic은 AI 안전 연구소이자 공익 법인으로 자기를 정의합니다. ‘헌법적 AI(Constitutional AI)’, 인간이 모델 안을 들여다볼 수 있어야 한다는 ‘해석 가능성(Interpretability)’, 모델의 능력이 올라가기 전에 단계별로 안전 인증을 받아야 한다는 ‘책임 있는 확장 정책(Responsible Scaling Policy)’ 등이 핵심. 정리하면, AI를 인간 옆에 안전하게 안착시키자는 비전을 가진 회사입니다.

반면 OpenAI는 스스로를 AGI를 만드는 회사로 정의합니다. 미션은 ‘AGI가 인류 전체에 이로움을 준다’. ‘AI 노동력(AI workforce)’, ‘일의 미래(future of work)’ 같은 어휘가 자주 등장하고, AI가 대규모 자율 노동력으로 인간을 반복 작업에서 해방시키는 사회가 있죠.

두 회사의 설계

이런 정체성은 도구의 동작과 설계를 결정하는 데도 분명 영향을 끼친 것 같았어요.

Claude Code에서는 안전을 외부 가드레일이 아니라 모델 내부에 두려 합니다. 학습 단계부터 공을 들이죠. 메모리 단위에서도 사용자가 쓰는 CLAUDE.md와 모델이 스스로 쓰는 자동 메모리(Auto memory)가 함께 작동하는 구조를 짰는데요, 인간과 모델이 시스템을 공동 관리하는 흐름이죠.

반면 Codex Cloud 페이지는 제목부터 ‘클라우드의 Codex에게 위임하라(Delegate to Codex in the cloud)’입니다. 인간은 매니저(manager), Codex는 일꾼(worker)이라는 노동 분업의 메타포가 여기저기 보이죠.

결국, Anthropic은 ‘함께 가는(companion) 동료’를, OpenAI는 ‘위임받는 작업자(delegated worker)’을 만든다는 인상이 들었습니다. 어쩌면 모델의 차이보다 더 극적인 차이라고요.

맡기느냐, 옆에 두느냐

그런 구조 아래에서 Claude Code는 사용자가 옆에서 같이 작업하는 흐름을 웬만하면 가져가는 편입니다. 작동 단계의 거의 모든 지점에 훅(hooks)을 걸어 손을 댈 수 있고, CLAUDE.md와 자동 메모리에 합의한 구조를 쌓으며, 슬래시 커맨드로 묶은 팀 워크플로를 스킬(skills)로 공유하고요. 문서에서 자주 쓰는 단어도 팀 동료, 프로그래밍 지원, 엔진 쪽입니다.

반면 Codex는 사용자가 권한 경계만 잡아두고 맡기는 흐름으로 설계됐어요. Auto·Read-only·Full Access 세 단계 권한 프로파일이 처음부터 들어가 있었고, 클라우드 환경에서 격리된 채 병렬로 굴러갑니다. 자주 쓰는 단어는 위임, 자동 운항, 사전 설정, 인계 쪽이에요.

조금 더 재미있는 차이도 있었는데요. Claude Code의 Agent Teams 공식 문서는 “팀 동료가 각자 자신의 컨텍스트 안에서 독립적으로 일하면서 서로 직접 소통한다”고 적었습니다. 에이전트끼리도 상호작용하는 방식을 추구하는 셈이죠. 반면 Codex의 Subagents는 각 지점에 한 명씩 보내고 다 끝날 때까지 기다린 다음 결과를 모아 요약하는 구조입니다.

함께 가는 모델과 위임받는 모델이 도구의 운영 단계에서 한 번 더 갈리는 셈입니다. 그렇게 우리가 본 작업의 특성 차이가 나타난 걸지도요.

싸우지 말고 같이 씁니다

그래서 어느 쪽을 골라야 하냐고요? 이런 답이 나와서 죄송하지만, “둘 다 쓰세요”라고 하겠습니다.

꽤 많은 문서와 의견을 볼수록 든 생각이 있습니다. 두 도구는 대결 구도가 아니라 역할이 다른 짝에 가깝다는 거죠. AI 도구가 빨라질수록, 어떤 도구를 쓰느냐보다 여러 도구의 사각지대를 어떻게 겹치고 덮어내는지가 중요해집니다. 도구를 쓰기 위해 일을 하는 게 아니라, 내 일의 문제를 풀기 위해 도구를 쓰는 거니까요.

그간 쌓은 컨텍스트와 하네스가 아쉬운데다 문제를 풀어내느라 정신없이 바쁘다면 Claude Code만 써도 좋겠습니다. 반면 불안정함에 휘둘리기도 싫고 매 세션마다 토큰이 턱턱 차서 불편하다면 Codex도 좋습니다. 직접 써보며 와우 포인트를 발견해 보는 거죠. 별다른 제약이 없을 때, 가장 추천하는 것은 둘을 함께 쓰는 겁니다. 하나의 작업물에 대해 서로 다른 의견을 내며 발전 시킬 수도 있고, 작업 단위로 더 나은 결과물을 내는 도구에게 위임할 수도 있죠.

2026년 5월 시점 코딩 에이전트 시장의 답은 이렇습니다. 기습으로 Opus 5.0이나 GPT-5.6이 나오면 어느 한쪽이 다시 쥐고 흔들 수도 있고요. Cursor 같은 도구들도 어딘가에 끼어들 거고요. 아참, 첫 등장은 조금 아쉬운 평을 받았다지만, 구글의 Antigravity 2.0이 어떻게 나아갈지 지켜봐야 합니다. 분명 Claude Code, Codex와 유사한 방향성을 잡았거든요. 도구의 균형추가 기울거나 새로운 구도가 나오면, 그때 다시 성능을 비교해 보겠습니다. 또 그때 따라잡은 만큼요.