새벽 두 시에 vLLM 서버가 또 죽었다. Azure GPU 인스턴스 로그를 열어보니 텐서 병렬 설정이 꼬여서 워커 프로세스끼리 서로 못 찾고 있었다. 이런 순간에 손이 가는 도구가 무엇인지가, 그 도구의 진짜 실력을 말해준다고 생각한다. 나는 그날 Claude Code를 켰다. 다음 날 비슷한 유형의 FastAPI 비동기 버그가 났을 때는 Codex를 열었다. 그렇게 3개월을 두 도구를 번갈아 쓰면서 지냈다.
이 글을 쓰게 된 이유는 단순하다. 인터넷에 떠도는 비교 글 대부분이 벤치마크 점수만 나열하고 끝난다. 정작 실무에서 써보면 점수와 체감이 완전히 다른 경우가 많다. 그래서 실제로 두 도구를 나란히 놓고 같은 프로젝트, 같은 버그, 같은 마감 압박 속에서 써본 이야기를 정리해보려 한다.
왜 두 도구를 비교하게 됐나
원래는 Claude Code만 쓰고 있었다. LangGraph 기반 멀티에이전트 시스템을 짜면서 반복적으로 발생하는 리팩터링 작업, RAG 파이프라인의 Qdrant 연동 코드 정리 같은 일에 익숙해져 있었다. 그런데 팀에서 Codex를 도입하자는 이야기가 나왔고, 어느 쪽이 실제로 더 나은지 판단할 근거가 필요했다. 그냥 느낌으로 하나를 고르기보다는, 같은 작업을 두 도구로 각각 돌려보고 결과물과 소요 시간을 비교하는 편이 낫겠다 싶었다.
비교 방식은 단순했다. 같은 저장소를 복제해서 한쪽은 Claude Code로, 다른 쪽은 Codex로 동일한 작업 지시를 내렸다. PyMuPDF를 이용한 PDF 파싱 로직 개선, MCP 서버 연동 코드 작성, PostgreSQL과 pgvector를 쓰는 검색 쿼리 최적화까지 다양한 난이도의 작업을 섞었다.
설치와 첫인상
Claude Code는 터미널에 설치하고 바로 저장소 컨텍스트를 읽어들이는 방식이 인상적이었다. 프로젝트 구조를 스스로 파악하고 관련 파일을 찾아가는 흐름이 자연스러웠다. 특히 여러 파일에 걸친 변경이 필요한 작업에서 어떤 파일을 왜 건드리는지 설명을 먼저 해주는 점이 신뢰를 줬다.
Codex는 처음 켰을 때 속도감이 눈에 띄었다. 짧은 함수 단위 작업이나 명확하게 범위가 정해진 태스크에서는 응답이 빠르고 군더더기가 적었다.다만 대규모 컨텍스트를 요구하는 작업에서는 파일을 놓치거나 관련 없는 부분까지 건드리는 경우가 종종 있었다.
두 도구 모두 사용 초반에는 크게 만족스러웠다. 문제는 실제 복잡한 상황에 들어갔을 때부터 갈렸다.
Claude Code가 강했던 순간
앞서 언급한 vLLM 텐서 병렬 크래시 건이 대표적이다. 로그만 봐서는 원인이 명확하지 않았다. GPU 메모리 부족처럼 보였지만 실제로는 워커 간 통신 설정 문제였다. Claude Code에 로그 파일과 설정 파일을 함께 던져주고 원인 분석을 요청했더니, 단순히 코드를 고치는 게 아니라 왜 이 문제가 생겼는지 단계별로 추론하는 과정을 보여줬다. 텐서 병렬 사이즈와 실제 GPU 개수가 불일치하는 부분을 짚어냈고, 수정 후 재현 테스트까지 같이 짜줬다.
이런 디버깅형 작업에서 Claude Code는 확실히 강했다. 코드를 고치는 것보다 왜 문제가 생겼는지 맥락을 이해하는 능력이 좋았고, 여러 파일에 흩어진 원인을 엮어서 설명하는 능력도 뛰어났다. FastAPI 이벤트 루프가 블로킹되던 버그도 비슷했다. 동기 함수 하나가 비동기 컨텍스트 안에서 실행되며 전체 서버가 멈추는 문제였는데, 단순 코드 수정이 아니라 어느 지점에서 블로킹이 발생하는지 콜스택을 따라가며 짚어주는 과정이 실제 시니어 개발자와 페어 프로그래밍하는 느낌에 가까웠다.
Codex가 강했던 순간
반대로 명확하게 정의된 작업에서는 Codex가 더 효율적이었다. 예를 들어 여러 개의 유사한 API 엔드포인트를 동일한 패턴으로 만들어야 할 때, Codex는 반복 작업을 빠르게 처리했다. 하나의 예시 코드를 주고 나머지 다섯 개를 같은 스타일로 만들어달라고 하면 군더더기 없이 처리했다.
테스트 코드 작성도 Codex가 손이 덜 갔다. pytest 기반 테스트 케이스를 짤 때 엣지 케이스를 스스로 찾아서 추가하는 경우가 많았고, 실행 결과를 바로 확인해서 실패한 테스트를 스스로 고치는 루프가 빨랐다. 짧은 스크립트 성격의 자동화 작업, 예를 들어 PostgreSQL과 Qdrant 사이에 데이터 동기화가 틀어져서 고아 문서가 남는 문제를 찾아내는 검증 스크립트를 짤 때도 Codex 쪽이 빠르게 결과물을 냈다.
다만 이 작업들의 공통점은 범위가 명확했다는 점이다. 문제 정의가 애매하거나 여러 시스템에 걸쳐 있는 작업에서는 Codex도 Claude Code만큼의 깊이를 보여주지는 못했다.
가격과 사용 제한 비교
실무에서는 성능만큼 비용도 중요하다. 두 도구 모두 사용량 기반 요금제를 쓰고 있는데, 장시간 디버깅 세션처럼 컨텍스트를 많이 쓰는 작업에서는 비용 체감이 커진다. 개인적으로는 복잡한 디버깅은 Claude Code로, 반복적인 코드 생성이나 짧은 스크립트 작업은 Codex로 나눠 쓰는 방식이 비용 대비 효율이 가장 좋았다. 한 도구에 모든 작업을 몰아넣기보다는 작업 성격에 따라 분산하는 편이 결과적으로 시간도 비용도 아꼈다.
가격 정책은 계속 바뀌고 있어서 이 글에서 구체적인 금액을 못 박기보다는, 도구를 선택할 때 요금제 페이지를 직접 확인하고 자신의 작업 패턴에 맞춰 판단하시길 권한다. 중요한 건 절대 금액보다 어떤 작업에 얼마나 쓰느냐다.
어떤 사람에게 어떤 도구가 맞을까
3개월 써보고 내린 결론은 생각보다 단순하다. 인프라 트러블슈팅, 여러 서비스에 걸친 아키텍처 문제, 원인이 불분명한 버그를 다루는 일이 많다면 Claude Code 쪽 손을 들어주고 싶다. 문제를 맥락 속에서 이해하고 설명하는 능력이 이런 작업에서 확실히 차이를 만든다.
반대로 정해진 스펙대로 빠르게 코드를 뽑아내야 하는 작업, 반복적인 CRUD 엔드포인트나 테스트 코드 작성이 많은 팀이라면 Codex의 속도감이 더 잘 맞을 수 있다. 특히 코드 리뷰 전 단계에서 빠르게 초안을 만들어야 하는 상황에서는 Codex가 시간을 많이 아껴줬다.
물론 이건 어디까지나 개인 경험이다. 팀 규모, 프로젝트 성격, 기존에 쓰던 개발 환경에 따라 체감은 달라질 수 있다. 다만 확실한 건, 둘 중 하나만 정답이라고 말하기는 어렵다는 점이다. 실제로 나는 지금도 두 도구를 병행해서 쓰고 있고, 작업 성격에 따라 도구를 바꿔가며 쓰는 방식이 결과적으로 가장 생산적이었다.
결론
세 달 동안 두 도구를 나란히 써본 결과를 한 문장으로 정리하면, Claude Code는 문제를 이해하는 도구고 Codex는 코드를 뽑아내는 도구에 가깝다. 복잡하고 원인이 불분명한 문제일수록 Claude Code가 진가를 발휘했고, 범위가 명확하고 반복적인 작업일수록 Codex가 시간을 아껴줬다.
둘 중 하나를 골라야 한다는 강박에서 벗어나는 게 오히려 실무에 더 도움이 됐다. 새벽에 서버가 죽었을 때는 Claude Code를, 오후에 밀린 테스트 코드를 쳐낼 때는 Codex를 켜는 식으로 역할을 나누고 나니 두 도구 모두 각자의 자리에서 제 몫을 했다. AI 코딩 도구를 고민 중이라면 어느 쪽이 더 우월한지보다, 본인이 주로 부딪히는 문제 유형이 무엇인지부터 돌아보는 게 먼저일 것 같다.