왜 Codex 가 내 프로덕션 모놀리식 시스템에서 Claude Code 보다 더 잘 작동하는가

지난 1 년 동안 주로 Codex 를 사용했지만, 지난 한 달간 Opus 4.6 과 4.7 버전의 Claude Code 를 시도했습니다. 이것이 저의 기록입니다.

이것은 벤치마크가 아닙니다. 이는 단일 프로덕션 코드베이스에서의 일일 사용 경험을 바탕으로 한 것입니다. 일부 중간 복잡도의 작업에 대해서는 동일한 프롬프트로 두 도구를 모두 실행해 보았지만, 이를 통제된 평가로 만들기 위해 노력하지는 않았습니다.

TL;DR: 저의 프로덕션 Python 모놀리식 시스템에서는 여전히 Codex 를 선호합니다.

코드베이스는 수년 전부터 존재하는 Python 백엔드입니다. 여러 시기의 다른 아키텍처 계층을 가지고 있습니다: 새로운 실험적인 DDD 스타일, 오래되었지만 여전히 잘 구조화된 레거시 코드, 그리고 매우 오래되고 취약한 스파게티 코드입니다.

우리는 보통 재작성이 필요하지 않는 한 오래된 부분을 다시 작성하지 않습니다. 선호하는 전략은 자연스럽게 대체되거나 제거될 때까지 그대로 두는 것입니다. 이는 단순한 CRUD 웹 서버가 아닙니다. 많은 A/B 테스트와 모퉁이마다 매우 구체적인 비즈니스 로직을 가진 복잡하고 때로는 지나치게 복잡한 애플리케이션입니다.

왜 이 코드베이스에 대해 Codex 를 선호하는가:

1. Codex 가 저에게 더 잘 harness-engineering 원칙을 따릅니다. 참조: https://openai.com/index/harness-engineering/
   Claude 는 AGENTS.md 에 매우 명시적인 짧은 지침 (예: "exec_plan.md 를 읽고 이를 따르십시오.") 이 포함되지 않는 한 이 워크플로우를 신뢰할 수 있게 따르지 않습니다.

2. Claude 는 기존 도구를 먼저 검색하는 대신 새로운 도구를 더 자주 생성합니다.
   이러한 종류의 코드베이스에서는 기존 프로젝트 특정 도구와 패턴을 재사용하는 것이 매우 중요합니다.

3. Claude 는 새 기능을 배치할 위치를 결정하기 전에 너무 적은 코드나 문서를 읽는 경우가 많습니다.
   저는 같은 작업에서 여러 번의 수정 라운드를 거치는 경우가 많았습니다:

   • "이 기능을 컨트롤러 대신 모듈 A 에 넣으십시오. 그곳이 맞는 곳입니다."
   • "요청에 보낸 상태들을 사용하여 응답 객체를 구성하지 마십시오. API 는 이미 업데이트된 객체를 반환합니다 — 해당 응답을 사용하고 결과에 포함시키며, 우리가 예상하는 상태와 일치하는지 유효성을 검사하십시오."
   • "아니요, 이 경계를 소유한 동일한 모듈에서 유효성을 검사하십시오."
     이러한 종류의 왕복은 지치게 만들었습니다. Codex 는 이 유형의 작업에 대해 더 나은 계획 모드를 가지고 있는 것 같습니다. 아키텍처 변경을 하기 전에 프롬프트의 누락된 컨텍스트를 더 자주 인지하고 명확화 질문을 묻습니다.

4. 저는 테스트하는 동안 새로운 버전이 출시되었기 때문에 여러 Codex/GPT 모델 버전을 통해 이주했습니다. 저는 아직 UI 집중 작업에서 GPT-5.5 를 테스트하지 않았습니다.
   그러나 경험상 Opus 4.6 은 Codex 5.3 과 GPT-5.4 보다 프론트엔드 작업에 훨씬 더 좋았습니다. UI 작업의 경우 현재 Claude 를 선호합니다.

기술 및 MCP:

저는 두 LLM 모두에 대해 하나의 공유된 기술만 사용합니다: Docker Compose 환경 시작/중지 명령과 그 내부에서 테스트 실행 명령입니다.