클로드 코드(약 100시간) vs. 코덱스(약 20시간)
최근 회사에서 툴 개발을 진행하면서 Claude code와 codex를 병행으로 사용해야 할지
아니면 기존과 같이 Claude code만 사용해야 할지 고민이 되는 순간이다.
그래서 해외 사례를 좀 찾아보니 다음과 같은 흥미로운 글이 있더라.
핵심은
사용자가 SWE는 소프트웨어 엔지니어(Software Engineer) 소양이 없는 상태라면 뭘 사용하던 결과가 좋지 못할 것이다.
그렇다면 대부분의 사용자는 아무거나 편한 것을 사용하면 되는 것이 아닐까 싶다.
Claude Code (~100 hours) vs. Codex (~20 hours)
몇몇 분들이 차이점에 대해 계속 물어보셔서, 금요일 아침에 CC 사용 한도에 도달해서 주말 동안 Codex를 사용해 보기로 했습니다. 약 20시간 정도 플레이했는데, 코딩보다는 공동 개발이 더 마음에 드네요.
클로드 경험과 코덱스 경험에 대해서만 알고 싶다면 ‘클로드 경험’과 ‘코덱스 경험’ 부분으로 바로 이동하세요. (수정: 오푸스는 고난이도, 코덱스는 중난이도입니다.)
저는 MAG7에서 근무한 경력이 있는 14년차 엔지니어이며, 현재는 다른 주요 IT 기업에서 근무하고 있습니다. 직급은 수석/스태프 엔지니어 매니저에 준합니다. 모든 플랫폼 수준의 경험을 보유하고 있으며, 특히 분산 시스템 분야에서 풍부한 경험을 쌓았습니다.
VSCode 확장 기능을 사용하여 약 8만 줄의 Python/TypeScript 프로젝트(테스트 약 2,800개 포함)를 개발했습니다. 이 프로젝트는 사용자가 다양한 출처의 PDF/CSV/XML 파일을 업로드하면 해당 파일을 파싱하고 정규화하여 PostgreSQL 기반의 구조화된 데이터 모델로 변환하는 데이터 분석 애플리케이션입니다. 웹소켓을 통해 실시간 데이터를 제공하는 백엔드에 연결하여 데이터를 스트리밍 방식으로 데이터 모델에 입력합니다. 서버 측에서는 데이터 스트림을 기반으로 특정 분석 결과를 업데이트하고 웹 UI에 SSE(Structured System Error)를 표시합니다. 모든 부분이 탄탄하게 설계되었으며, 단순히 ‘느낌’에 그치지 않습니다.
계획 모드는 먼저 상당히 철저하고 범위가 명확한 프롬프트로 시작됩니다. 계획 초안이 작성되면 계획 검토 스킬이 실행되며, 이 스킬은 8개의 하위 에이전트(아키텍처, 코딩 표준, UI 디자인, 성능 등)를 실행합니다. 각 하위 에이전트는 더욱 구체적인 프롬프트와 이전 ‘연구’ 세션에서 가져온 명확한 참조 문서(예: ‘postgres_performance.md’, ‘python_threading.md’, ‘software_architecture.md’)를 제공합니다. 아키텍처 검토 전문가는 SOLID, DRY, KISS, YAGNI 등의 원칙을 검토하도록 요청받으며, 각 개념에 대한 구체적인 참조 자료를 활용합니다.
코딩을 진행합니다. 계획의 각 단계는 별도로 커밋되고, 각 커밋마다 코드 리뷰 스킬(기본적으로 계획 하위 담당자 전문가를 재사용하는 것)이 실행됩니다. 저는 피드백을 수동으로 검토하고 댓글을 추가하며 방향을 제시합니다.
클로드.md 약 100줄 분량입니다. TDD, Git 워크플로, 몇 가지 핵심 DevExpress 규칙 및 Docker 명령어와 같은 일반적인 프로젝트 도구 사용법이 포함되어 있습니다.
시간에 쫓기는 엔지니어가 핵심 아키텍처를 재검토하는 대신, 꼼수나 패치, 도우미 함수들을 마구잡이로 추가하는 데만 급급한 느낌입니다.
상호작용적입니다. 훨씬 더 많은 관리가 필요합니다.
일을 처리하는 속도가 빠릅니다. 시간을 들여 생각하거나 행동하기 전에 고민하는 스타일이 아닙니다.
컨텍스트를 수동으로 적극적으로 관리함에도 불구하고(제 생각에는 1MM 컨텍스트는 초보자 함정이고 그보다 4분의 1 이하로 유지해야 합니다), CLAUDE.md를 노골적으로 무시하는 경우가 빈번합니다. 거의 매 세션마다 적어도 한 번은 이런 현상을 목격합니다.
가끔씩 작업이 완전히 완료되지 않고 끝나는 경우가 있습니다. 예를 들어, 테스트 스위트(저는 8개의 스위트가 있습니다)를 하나의 비동기 패턴에서 다른 비동기 패턴으로 마이그레이션하는 경우, 대부분의 테스트는 마이그레이션되었지만 몇몇 테스트는 이전 패턴에 그대로 남아 있는 것을 발견했습니다.
이상하게도, 새로운 기능을 위해 새 파일을 추가하는 생각을 거의 하지 않아요. 강력한 객체 지향 및 팩토링 원칙을 따르기보다는 기존 파일에 함수를 추가하는 것을 좋아합니다. (저는 C/C++ 출신이라 각 파일의 길이를 600줄 미만으로 유지하는 것을 선호합니다.)
테스트 코드를 작업 목표에 맞춰 마음대로 바꾸는 경향이 있습니다. 저는 ‘변경 사항을 구현한 후 테스트가 실패하면, 맹목적으로 수정하지 말고 중단하고 저에게 알려주세요’라고 지시하는 데 많은 노력을 기울였습니다. 일반적으로 이 프로그램이 작성하는 테스트는 95%가 유용하고 5%는 잘못된 동작을 고정하는 데 그칩니다. 이러한 문제는 시간이 지날수록 더욱 심화됩니다.
경력 5~6년 정도의 주니어급 시니어처럼 느껴집니다. 제가 직접 코드를 수정하지 않아도 자주 멈추고 되돌아가서 더 깔끔하게 코드를 다시 작성해줍니다.
클로드보다 훨씬 느립니다. 같은 작업을 수행하는 데 3~4배는 느린 것 같아요.
훨씬 더 사려 깊고 신중한 방식입니다. 클로드처럼 단순히 ‘신급 클래스’를 확장하는 것이 아니라, 모든 요소를 자동으로 고려하여 훨씬 더 긴밀하게 구성합니다. 또한, 중간에 가정을 재검토하고 필요한 부분을 수정하여 깔끔하게 마무리합니다.
저는 가끔 생각지도 못했던 방식으로 작용하는 것을 본 적이 있는데, 그것들은 모두 누적되는 현상입니다.
AGENTS.md 파일을 무시하는 경우는 본 적이 없습니다. 세션 도중에 지시 사항을 재정의하는 것조차 허용하지 않습니다.
지금은 그냥 작업을 시작하고 완료되면 다시 와서 검토하는 방식으로 진행하고 있습니다. 이미 충분한 역량을 갖춘 것으로 입증되었기 때문에, 오류가 발생할 때까지 출력물을 한 줄씩 지켜볼 필요는 없다고 생각합니다.
Codex Pro x5는 Claude x20과 비슷한 사용 제한을 가지고 있는 것 같습니다.
코덱스는 눈에 띄게 느리고, 상호작용이 적으며, 신중한 반면, 클로드는 더 빠르고, 상호작용이 활발하며 (지켜봐줘야 하지만), 일을 빨리 처리하는 스타일입니다.
클로드와 함께하는 세션에서 더 많은 작업을 처리할 수 있지만, Codex를 사용하는 방식이 더 효율적입니다. 클로드와 함께라면 프로토타입을 만들고 빌드하는 속도가 매우 빠르지만, 며칠마다 리팩토링을 많이 진행해야 합니다. 앱이 발전함에 따라 Codex를 사용할 때도 리팩토링은 여전히 필요하지만, ‘가서 정리해야 할 코드가 있는지 살펴보자’라는 식의 접근 방식에서 벗어나 ‘앱이 성장했으니 리팩토링할 시점이다’라는 식으로 바뀝니다.
난이도가 낮거나 중간 정도인 프로젝트에서 ‘바이브 코드’ 경험을 원한다면 Claude가 훌륭하고 더 빠르게 작업을 완료할 수 있을 겁니다. 하지만 엔터프라이즈급 소프트웨어를 개발해야 한다면 Codex를 더 선호할 것 같습니다.
둘 다 유용하지만, 제 생각에는 Claude는 Codex보다 숙련되고 집중력 있는 운전자가 더 필요합니다. 참고로, SWE를 전혀 모르는 경우 둘 다 형편없는 출력을 보여줄 겁니다.