일주일 동안 Claude보다 Codex를 더 많이 써본 인상

이번 주에는 Claude보다 Codex를 더 많이 사용했다. 아주 개인적인 첫인상을 간단히 정리해 본다. 주말에는 시간을 내서 전체 분석도 해볼 생각이다.

(1) 올해 Claude와 Codex에 같은 플러그인과 스킬 등을 넣어 최대한 동등하게 맞추려고 했다. 하지만 일부 세션에서 스킬을 만들고도 전부 Codex로 옮기지는 않아서 Claude에 스킬이 더 많았다. 해결 방법은 간단하다. Codex에 Claude의 스킬 폴더를 알려주고 Claude용으로 변환해 달라고 요청하면 된다.

(2) 급할 때는, 예를 들어 긴급해 보이는 문제를 디버깅할 때는 여전히 Claude를 열었다. 왠지 Claude가 더 익숙하고 편했기 때문이다. Claude가 더 낫다는 뜻은 아니다. 다만 익숙했고, 디버깅할 때는 내가 잘 아는 도구를 쓰는 것이 중요하다.

(3) Codex가 Ruby/Ruby on Rails 코드를 수정할 때는 주석을 더 적게 만들었다. 이 점이 정말 마음에 들었다. 조만간 이와 관련해 진행한 몇 가지 실험도 공유할 예정이다.

(4) Codex 에이전트 하네스의 출력은 Claude보다 훨씬 더 ‘기술적’이다. Claude는 Tuple 세션에서 함께 작업하며 메시지를 보내는 동료 같다면, Codex는 『스타트렉』의 Data를 변형한 캐릭터처럼 느껴진다.

(5) 예전처럼 Claude에서 큰 세션 하나를 운영하기보다, Codex에서는 훨씬 많은 세션을 열고 각각 한 가지 작업에 집중하게 하고 싶어진다. Codex만의 특징은 아닐 수도 있지만, Codex로 작업하면서 이런 차이를 느꼈다.

(6) Codex가 Claude보다 코드를 더 빠르게 수정한다는 인상을 받았다. 하지만 핵심 수정을 마친 뒤 pull request를 완성하기까지는 시간이 많이 걸렸다. 여러 테스트를 다시 실행하고 리뷰하는 등의 작업이 이어졌다. 이런 철저함은 마음에 들지만, 결국 전체 소요 시간에서는 이득이 없었다.

(7) 코드 아키텍처 면에서는 Codex가 Claude보다 훨씬 단순한 해법을 만들었다고 느꼈다. Claude는 대개 추상화, 개념, Sorbet 시그니처, 타입 별칭 등을 많이 만들어 나간다. Codex는 작업 범위를 좀 더 제한했고, 만들어 내는 것도 적었다. 이번 주에는 code research -> design change -> review change -> implement -> verify라는 개선된 작업 방식도 시험했다. 같은 문서를 주고 같은 요구사항을 구현하게 했는데, Claude의 코드는 조금 더 복잡한 대신 여러 경우를 처리했다.

(8) Codex도 실수했다. Claude는 다른 작업에서 브랜치를 분기하고 두 작업을 계속 동기화하려는 내 의도를 이해할 수 있었다. 반면 Codex는 branch A targets branch B that targets main,처럼 좋지 않은 구조를 만들었다. rebase를 요청하자 main,을 기준으로 rebase해서 추가 코드가 4000줄이 넘는 PR이 생기기도 했다. 대상 브랜치만 기준으로 rebase하라고 명확하게 지시해야 했다.

(9) MCP가 아닌 CLI 도구를 쓰는 내 환경에서 Codex로 Jira와 Atlassian을 다루기는 번거로웠다. Codex는 로그인을 요청하려고 JIRA를 열었다가 CLI로 전환하고, 다시 브라우저로 돌아갔다. 이 경우 Claude는 이전 세션을 바탕으로 내가 원하는 것을 파악하고 원하는 방식대로 처리하려는 의지가 훨씬 강했다.

(10) MCP를 사용할 때는 Codex CLI의 접근 방식이 더 마음에 든다. codex mcp login을 실행하라고 요청하고, 실행할 때마다 올바른 인증 및 권한 부여 절차를 연다. Claude는 가끔 한 차례의 작업 안에서 이를 자동으로 실행하려다가 멈추기도 한다.

내가 느끼는 Claude와 Codex의 가장 큰 차이는 이렇다. Claude는 요청받은 범위를 넘어 사용자가 무엇을 원할지 추측한 뒤 곧바로 처리하려고 한다. 반면 Codex는 지시한 일을 수행하되 지나치게 확장하지 않는 동료에 가깝다. 작업이 끝났을 가능성이 처음 보이는 순간 멈춘다.

^{source https://allaboutcoding.ghinda.com/a-week-of-using-codex-more-than-claude/}

HN에서는 Codex와 Claude 중 하나를 승자로 고르기보다, 모델과 실행 도구를 구분하지 않은 비교부터 경계해야 한다는 반응이 두드러졌다. 같은 제품명 아래에서도 모델, 추론 강도, CLI나 데스크톱 환경의 조합에 따라 결과가 달라진다. 작업 종류와 언어, 지시 방식까지 빠진 체험담만으로 일반적인 우열을 정하기 어렵다는 지적이다.

Codex를 선호한 개발자들은 빠르고 직접적인 응답, 범위가 명확한 작업을 끝까지 밀어붙이는 능력, 불필요한 설명이 적은 코드를 장점으로 꼽았다. 반복적인 소규모 변경이나 성능 최적화처럼 목표와 검증 기준이 뚜렷한 문제에서 특히 만족도가 높았다. 반면 요구가 덜 정리된 UI나 설계 작업에서는 Claude가 의도를 더 잘 짐작하고 빠진 맥락을 보완한다는 경험도 나왔다.

복잡성에 대한 평가는 정반대로 갈렸다. Codex가 단순한 해법을 만든다는 사례가 있는가 하면, 위협 가능성을 과도하게 상정해 검증 계층과 상태 모델, 방대한 테스트를 추가한다는 불만도 이어졌다. Claude 역시 추상화를 늘리고 장황한 주석을 남긴다는 비판을 받았다. 특히 구현 과정의 시행착오나 이전 상태를 코드 주석에 기록하면, 현재 코드를 설명하기보다 저장소에 잡음을 남긴다는 우려가 컸다.

결국 선택 기준은 브랜드보다 작업의 명확성, 모델과 도구의 조합, 추론 강도, 비용과 감독 방식에 가깝다. 작은 변경은 범위와 중단 조건을 먼저 고정하고, 모호한 과제는 의도 추론 능력을 확인해야 한다. 장시간 맡길 때는 계획에서 벗어나지 않는지 중간에 검토하고, 모델을 바꿀 때도 같은 요구사항과 자체 검증 기준으로 비교해야 한다.