Codex와 Claude Code를 둘 다 써본 개발자 후기: 결국 Codex를 메인으로 고른 이유

1. 몇 달 만에 메인 도구가 바뀌었습니다

불과 몇 달 전까지만 해도 Claude Code를 적극적으로 사용했습니다. 저장소마다 CLAUDE.md를 만들고, 도메인 문서와 팀 규칙을 정리하고, 자주 반복하는 작업은 Skill과 Hook으로 옮겼습니다. 이 구성이 어느 정도 자리를 잡자 직접 코드를 타이핑하는 시간은 눈에 띄게 줄었습니다.

그러다 Codex 업데이트와 사용량 이벤트를 계기로 ChatGPT Pro를 결제해 잠시 써봤습니다. 말 그대로 잠깐 비교해볼 생각이었는데, 그때 옮긴 뒤 지금까지 Codex를 메인으로 사용하고 있습니다.

결론부터 말하면 Claude Code가 부족해서 떠난 것은 아닙니다. Claude Code는 여전히 빠르고, 확장성이 좋고, 개발자가 손에 익히기 쉬운 훌륭한 에이전트입니다. 다만 제 작업에서는 첫 결과가 나오는 속도보다 긴 작업을 끝까지 밀고 가는 안정감과 사용량의 예측 가능성이 더 중요했습니다. 그 기준에서 현재는 Codex가 더 잘 맞았습니다.

이 글은 통제된 벤치마크가 아니라 두 도구를 실제 프로젝트에 사용한 개인 후기입니다. 모델과 요금제, 저장소 크기, 추론 강도에 따라 결과가 크게 달라질 수 있습니다.

2. Sonnet에서 Opus로 넘어갔을 때 받은 충격

처음 Sonnet을 주로 사용할 때만 해도 기능 설계는 제가 직접 했습니다. 여기서 말하는 설계는 거대한 시스템 아키텍처가 아닙니다. 이미 운영 중인 프로젝트에 기능 하나를 추가할 때 어느 모듈을 수정하고, 기존 도메인 규칙을 어떻게 지키며, 어떤 테스트로 검증할지를 정하는 수준의 설계입니다.

대규모 프로젝트에서는 이 과정이 오히려 구현보다 어려울 때가 많습니다. 관련 문서를 한 세션에 충분히 이해시키는 일부터 필요하고, 팀의 코드 스타일과 암묵적인 경계도 알려줘야 합니다. 당시 Sonnet은 규칙 일부를 놓치거나 익숙한 일반 패턴으로 돌아가는 경우가 있어, 저는 작업을 작게 나눠 하나씩 맡기는 방식을 선호했습니다.

Opus를 사용하고 나서는 이 경계가 크게 이동했습니다. 제가 기능의 목표와 제약을 설명하면, 작업을 나누고 계획을 만들고 구현과 검증 순서를 정하는 일까지 맡길 수 있었습니다. “AI가 코드를 대신 쓴다”보다 “개발자가 무엇을 만들지 정하고, 에이전트가 어떻게 만들지 결정한다”는 표현이 더 정확했습니다.

이 체감은 Anthropic이 약 40만 건의 Claude Code 세션을 분석한 연구와도 닮아 있습니다. 연구에서는 일반적인 세션에서 사람이 주로 무엇을 할지 결정하고 Claude가 주로 어떻게 할지 결정했으며, 사용자의 도메인 전문성이 높을수록 한 번의 지시로 Claude가 더 많은 작업을 수행하는 경향을 확인했습니다. 다만 이는 Anthropic 제품 사용 데이터에 기반한 자사 연구이므로 모든 도구와 팀에 그대로 일반화할 수는 없습니다.

중요한 변화는 개발 지식이 덜 필요해졌다는 데 있지 않았습니다. 오히려 도메인을 잘 알수록 더 큰 단위로 맡기고, 잘못된 방향도 더 빨리 발견할 수 있었습니다. 직접 작성하는 코드의 양은 줄어도 무엇이 맞는 코드인지 판단하는 책임은 그대로 남았습니다.

3. Claude Code의 가장 큰 장점은 빠른 작업 리듬입니다

제 환경에서 Claude Code의 가장 큰 장점은 속도였습니다. 요청을 해석하고, 파일을 찾고, 수정 방향을 보여주는 첫 호흡이 빠릅니다. 짧은 피드백을 주고받으며 UI를 다듬거나 작은 기능을 반복 수정할 때 특히 편했습니다.

속도는 단순히 응답 시간이 짧다는 뜻이 아닙니다. 개발자가 결과를 보고 다음 판단을 내리기까지의 간격이 짧다는 뜻입니다. 한 번에 완벽한 결과를 기대하기보다 대화를 통해 방향을 좁혀가는 작업에서는 이 리듬 자체가 생산성이 됩니다.

확장 생태계도 강점입니다. Claude Code는 프로젝트 공통 규칙을 담는 CLAUDE.md, 항상 적용하거나 경로에 따라 불러오는 Rules, 호출할 때 전체 내용을 불러오는 Skills, 별도 문맥에서 일하는 Subagent, 실제 명령을 실행하거나 차단하는 Hooks, 이 구성을 묶어 배포하는 Plugin을 제공합니다. 공식 가이드도 이 장치들을 언제 문맥에 들어오는지, 긴 세션에서 유지되는지, 어느 정도의 강제력을 갖는지에 따라 구분합니다.

특히 Hook은 문서 지침과 역할이 다릅니다. “수정 뒤 formatter를 실행하라”는 문장은 모델이 따라야 할 지침이지만, PostToolUse Hook은 파일 수정 이벤트 뒤에 formatter 명령을 실제로 실행할 수 있습니다. “위험한 명령을 사용하지 마라”는 부탁과 PreToolUse Hook에서 해당 호출을 차단하는 것도 같은 수준의 장치가 아닙니다.

이런 도구가 잘 갖춰져 있어 Claude Code를 단순한 챗봇이 아니라 팀의 개발 환경으로 만들기 좋았습니다. 지금도 빠른 탐색, 아이디어 구체화, 짧은 구현 반복에서는 Claude Code가 먼저 떠오를 때가 많습니다.

4. CLAUDE.md는 강력하지만 절대 규칙은 아니었습니다

Claude Code를 쓰며 가장 당황했던 순간은 정성껏 만든 CLAUDE.md가 간혹 지켜지지 않았을 때였습니다.

예를 들어 백엔드 작업에서는 서버 모듈의 도메인 문서를 먼저 읽고, 기존 서비스 계층과 오류 처리 방식을 그대로 따르도록 적어두었습니다. 대부분의 요청에서는 잘 동작했습니다. 하지만 어느 날은 같은 지침이 있는데도 새로운 코드 스타일과 별도 추상화를 만들어냈습니다. 결과만 보면 동작했지만, 이 저장소에서 유지보수할 코드는 아니었습니다.

이 경험을 곧바로 “Claude Code의 버그”라고 단정하기는 어렵습니다. 프롬프트가 모호했을 수 있고, 긴 세션의 문맥이 복잡했을 수 있으며, 당시 버전에서 개선된 문제일 수도 있습니다. 더 근본적으로 CLAUDE.md는 모델 문맥에 들어가는 지침이지 정적 분석기나 정책 엔진이 아닙니다.

Anthropic의 현재 설명에서도 루트 CLAUDE.md는 세션 내내 유지되지만 모든 줄이 항상 토큰을 사용합니다. 반대로 Skill은 관련 작업에서만 자세한 내용을 불러올 수 있습니다. 항상 필요한 저장소 지도와 명령은 CLAUDE.md에 두고, 도메인별 긴 절차는 Skill이나 경로별 Rule로 분리하는 편이 나은 이유입니다.

저는 지금 문서 규칙을 세 단계로 나눕니다.

1. 알아야 하는 맥락은 CLAUDE.md나 AGENTS.md에 둡니다.
2. 반복해서 수행할 절차는 Skill로 분리합니다.
3. 반드시 지켜야 하는 금지와 검증은 Hook, lint, test, CI로 강제합니다.

저장소 지침의 효과를 분석한 2026년 연구도 참고할 만합니다. 10개 저장소의 124개 Pull Request를 Codex로 실행한 실험에서는 AGENTS.md가 있을 때 중앙값 실행 시간이 28.64%, 출력 토큰이 16.58% 낮았고 작업 완료 양상은 비슷했습니다. 적절한 지침 파일이 실행 시간과 출력 토큰 감소에 기여할 수 있다는 결과입니다. 다만 이 연구는 Codex와 특정 표본을 대상으로 했고, 개별 규칙을 항상 정확히 준수한다고 증명한 것은 아닙니다.

즉 문서는 에이전트가 덜 추측하게 만들지만, 중요한 규칙의 마지막 방어선이 될 수는 없습니다.

5. 사용량을 예측하기 어려웠던 시기

Claude Code에서 메인 도구를 바꾸게 만든 직접적인 계기는 사용량 문제였습니다. 당시 Max 요금제를 쓰던 일부 사용자 사이에서 사용량이 예상보다 빠르게 줄었다는 경험담이 이어졌습니다. 저도 평소와 같은 작업에서 사용량이 비정상적으로 빠르게 줄어드는 일을 겪었습니다.

초안 단계에서는 이를 단순히 “토큰 버그”라고 적었지만, 사용자 경험만으로 내부 계산의 원인을 확인할 수는 없습니다. 다만 당시 정책이 실제로 변경된 사실은 공식 발표에서 확인할 수 있습니다.

• 2026년 5월 6일, Anthropic은 Pro·Max·Team 등의 Claude Code 5시간 한도를 두 배로 늘리고, Pro와 Max 계정에 적용하던 피크 시간대 한도 축소를 제거했다고 발표했습니다.
• 현재 Claude 도움말은 사용량이 대화 길이와 복잡성, 선택한 모델, effort 수준, 도구 사용에 따라 달라지며 Claude.ai·Claude Code·Desktop 사용량이 같은 한도에 함께 반영된다고 설명합니다.

따라서 “현재도 같은 버그가 계속된다”거나 “모든 사용자의 토큰이 잘못 계산됐다”고 쓰는 것은 정확하지 않습니다. 제가 도구를 옮길 당시에는 빠른 소진 경험과 피크 시간 정책이 겹쳐 작업 가능 시간을 예측하기 어려웠다고 표현하는 편이 맞습니다.

결국 “몇 번 요청할 수 있는가”만으로 요금제 가치를 비교하기는 어렵습니다.

제게 더 큰 문제는 총량 자체보다 예측 가능성이었습니다. 긴 마이그레이션 중간에 멈출지 모르는 도구는 충분히 똑똑하더라도 메인 작업자로 두기 어렵습니다. 그 시점에 Codex의 상대적으로 여유로운 사용량이 전환의 계기가 됐습니다.

6. Codex는 느리지만 끝까지 확인하는 쪽에 가까웠습니다

Codex를 처음 썼을 때 가장 인상적이었던 부분은 한 번에 맡길 수 있는 작업의 크기였습니다. 관련 문서를 읽고, 기존 구현을 찾아 재사용하고, 여러 파일을 수정한 뒤 테스트와 diff까지 확인하는 흐름을 비교적 꾸준히 이어갔습니다.

현재 주로 사용하는 GPT-5.6 Sol은 OpenAI가 복잡한 코딩과 리서치에 권장하는 주력 모델입니다. Codex도 AGENTS.md를 루트부터 현재 디렉터리까지 계층적으로 읽고, 필요한 Skill의 전체 지침을 그때 불러오는 구조를 제공합니다. 이 점만 놓고 보면 Claude Code와 방향이 완전히 다르지는 않습니다.

제가 느낀 차이는 기능 목록보다 기본 작업 태도에 가깝습니다. Claude Code가 빠르게 초안을 만들고 대화를 통해 맞춰가는 느낌이라면, Codex는 답을 내기 전에 더 오래 탐색하고 스스로 검증하는 경우가 많았습니다. 대규모 변경에서 누락된 파일이나 테스트를 다시 찾는 횟수가 줄었고, 그 결과 제가 후처리하는 시간도 줄었습니다.

물론 이는 동일한 모델, 동일한 프롬프트, 동일한 저장소를 반복 측정한 결과가 아닙니다. Claude Code의 모델과 effort를 높이거나 Codex의 설정을 낮추면 차이는 달라질 수 있습니다. 제가 Codex를 선택한 이유는 “항상 더 좋은 코드를 만든다”가 아니라, 현재 제 업무와 설정에서 총 수정 시간까지 포함한 결과가 더 안정적이었다는 데 있습니다.

7. Codex의 가장 큰 단점도 분명합니다

Codex의 단점은 속도입니다. 작은 수정은 큰 문제가 없지만 GPT-5.6 Sol에 Extra High나 Max를 선택하고, 읽어야 할 도메인 문서가 많고, 테스트까지 오래 걸리면 한 작업이 20분을 넘기는 경우도 있었습니다. 화면이 멈춘 것은 아니어도 개발자 입장에서는 기다림이 길게 느껴집니다.

여기서 설정 이름은 구분할 필요가 있습니다. Extra High와 Max는 한 모델이 더 깊게 추론하도록 하는 effort이고, Ultra는 복잡한 작업을 Subagent에 나눠 병렬로 진행하는 모드입니다. OpenAI 공식 문서도 높은 effort가 복잡한 작업의 결과를 개선할 수 있지만 더 오래 걸리고 더 많은 토큰을 사용한다고 설명합니다. Max는 속도보다 깊이가 중요할 때, Ultra는 독립적으로 나눌 수 있는 복잡한 작업에서 사용하도록 권합니다.

따라서 모든 작업에 Sol과 가장 높은 설정을 쓰는 것은 좋은 기본값이 아닙니다. 저는 다음처럼 나누는 편이 효율적이었습니다.

• 범위가 좁고 완료 조건이 분명한 수정은 Luna 또는 낮은 effort를 사용합니다.
• 일반적인 기능 개발과 리팩터링은 Terra나 Sol의 Medium부터 시작합니다.
• 여러 도메인이 얽힌 변경, 깊은 리뷰, 실패 비용이 큰 작업에서만 Sol의 High·Extra High·Max를 올립니다.
• Ultra는 하위 작업이 실제로 독립적일 때만 사용합니다. 한 파일을 여러 에이전트가 동시에 만지는 작업에는 이점이 작을 수 있습니다.

가장 강한 모델을 선택하는 것이 가장 빠른 개발을 보장하지는 않습니다. 모델의 실행 시간뿐 아니라 내가 다시 읽고 고치는 시간까지 합쳐야 합니다. Codex를 메인으로 쓰게 된 것도 바로 이 총시간이 제 작업에서는 더 짧았기 때문입니다.

8. 그래서 지금은 이렇게 나눠 씁니다

현재 제 기본 도구는 Codex입니다. 도메인 문서가 많은 기능 개발, 여러 파일을 건드리는 리팩터링, 리뷰와 검증까지 한 흐름으로 끝내야 하는 작업에 주로 사용합니다. 오래 걸리더라도 작업이 끝났을 때 제가 다시 찾아야 할 누락이 적다는 점을 더 높게 평가합니다.

Claude Code를 쓰지 않는 것은 아닙니다. 빠른 아이디어 탐색, 요구사항을 대화로 좁히는 일, 작은 UI 반복, 즉시 피드백이 중요한 작업에서는 여전히 매력적입니다. Claude Code의 Skill·Hook·Plugin 생태계에서 배울 점도 많습니다.

두 도구를 함께 쓸 때는 한쪽이 만든 코드를 다른 쪽에 무작정 다시 리뷰시키지 않습니다. 먼저 작업의 성공 조건을 고정하고 역할을 나눕니다.

사람  목표, 도메인 제약, 완료 조건, 최종 판단빠른 탐색 에이전트  대안 제시, 범위 축소, 짧은 프로토타입구현 에이전트  저장소 탐색, 코드 변경, 테스트, diff 검토강제 경계  Hook, lint, typecheck, test, CI, 사람의 리뷰

가장 중요한 규칙은 에이전트 이름과 무관합니다. 문서에는 맥락을, Skill에는 절차를, 자동화에는 강제할 규칙을 둡니다. 그리고 빠른 응답과 좋은 결과를 같은 지표로 착각하지 않습니다.

9. 결론: 더 좋은 도구보다 내 작업에 맞는 실패 방식

제가 사용해본 범위에서 Claude Code와 Codex는 모두 몇 달 전보다 훨씬 큰 단위의 일을 맡을 수 있게 됐습니다. 그래서 비교 기준도 코드 한 줄의 완성도에서 바뀌어야 합니다. 관련 문서를 제대로 찾는지, 팀 규칙을 얼마나 꾸준히 따르는지, 실패한 뒤 복구하는지, 사용량과 시간을 예측할 수 있는지까지 봐야 합니다.

Claude Code는 빠른 호흡과 풍부한 확장 생태계가 강점이었습니다. 반면 제 사용에서는 간헐적인 지침 이탈과 당시의 사용량 문제가 큰 마찰이 됐습니다. Codex는 훨씬 느릴 때가 있지만, 높은 effort에서 더 오래 탐색하고 검증하는 방식이 제 작업과 잘 맞았습니다.

그래서 현재의 선택은 Codex입니다. 하지만 이것은 영구적인 우승 선언이 아닙니다. 모델과 한도, 에이전트 기능은 빠르게 달라질 수 있습니다.

결국 중요한 질문은 “Claude Code와 Codex 중 누가 더 좋은가?”가 아닙니다. 내 작업에서 어느 쪽의 실패를 더 빨리 발견하고, 더 싸게 복구할 수 있는가? 지금 제 답은 Codex이지만, 빠른 상호작용이 더 중요한 개발자라면 충분히 Claude Code가 답일 수 있습니다.

참고한 공식 문서·연구

제품 기능과 현재 동작은 공식 문서를 우선했고, 개인 체감은 공식 문서 및 연구 내용과 구분해 작성했습니다.

• OpenAI 공식 문서 — Codex 모델과 reasoning effort, AGENTS.md 탐색과 우선순위, Codex Skills의 점진적 로딩
• Anthropic 공식 문서 — Claude Code를 조정하는 일곱 가지 방법, Hooks 실행과 차단 동작, 사용량과 대화 길이 한도
• Anthropic 연구·발표 — 약 40만 건의 Claude Code 세션에서 본 도메인 전문성, 2026년 5월 Claude Code 한도 확대 발표
• 독립 연구 프리프린트 — On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents. Codex와 10개 저장소, 124개 PR을 대상으로 한 연구이므로 Claude Code나 모든 프로젝트에 일반화할 수 없습니다.

이 글은 각 회사의 공식 입장을 대신하지 않습니다. 요금제별 사용량과 모델 제공 범위는 계정과 시점에 따라 달라질 수 있으며, 공개 자료로 확인할 수 없는 내부 계산 방식은 추정하지 않았습니다.