Codex와 Claude, 코딩 에이전트 UX가 갈라진다

성능 비교가 아니라 작업 태도 비교다

Lucian Ghinda의 A week of using Codex more than Claude는 거창한 benchmark가 아니다. 오히려 그래서 유용하다. 그는 일주일 동안 Codex를 Claude보다 더 많이 쓰며 느낀 10가지 인상을 적었다. Claude는 요청을 넘어 사용자가 원할 법한 것까지 추측하고, Codex는 지시받은 일을 하고 완료 신호가 보이면 멈춘다는 인상이 핵심이다.

이 차이는 모델 성능 표로 잘 드러나지 않는다. 코딩 에이전트의 실제 품질은 코드 생성 능력뿐 아니라 세션을 나누는 방식, 테스트를 반복하는 끈기, 과도한 추상화를 피하는 성향, Jira나 MCP 로그인 같은 주변 도구 통합에서 결정된다. Claude Code 세션 메시징, 에이전트 협업의 작지만 큰 변화와 Huzzah, 프롬프트를 파일로 남기는 코딩 실험이 보여준 것도 결국 작업 흐름의 문제였다.

절제형 Codex와 적극형 Claude의 장단점

글에서 Codex는 Ruby on Rails 코드에 주석을 덜 달고, 단순한 아키텍처를 만들며, 여러 작은 세션으로 나누고 싶은 도구로 묘사된다. 반면 Claude는 더 친숙하고, 사용자의 의도를 추측하고, Jira 같은 환경 문제에서 더 적극적으로 길을 찾는 느낌을 준다. 하지만 Claude는 추상화, Sorbet signature, type alias 등을 더 많이 만들 수 있고, Codex는 branch target을 잘못 이해해 4000줄 이상 PR을 만들 수 있었다고 한다.

즉 둘 중 하나가 항상 낫다는 이야기가 아니다. 절제형 도구는 명확한 지시와 좋은 검증 루프가 있을 때 빛난다. 적극형 도구는 모호한 문제와 주변 맥락이 많은 환경에서 빠르게 도와줄 수 있지만, 과잉 작업 위험이 있다. Claude Code 비용 절감법, 에이전트 작업도 운영이다는 세션 운영이 비용 문제라고 봤고, Databricks, AI 코딩 비용을 운영 지표로 만들다는 이를 조직 지표로 끌어올렸다.

한국 개발팀은 에이전트별 사용 규칙을 나눠야 한다

많은 팀이 AI 코딩 도구를 개인 취향으로 도입한다. 어떤 개발자는 Claude Code를 열고, 어떤 개발자는 Codex를 쓰고, 어떤 개발자는 IDE 자동완성만 쓴다. 하지만 PR 품질과 배포 위험은 팀 전체가 함께 부담한다. 이제는 도구별 사용 규칙이 필요하다. 예를 들어 Codex에는 작은 이슈, 테스트 보강, 명확한 리팩터링을 맡기고, Claude에는 불명확한 레거시 탐색이나 기획성 구현 초안을 맡기는 식이다.

더 중요한 것은 완료 조건이다. 어떤 에이전트를 쓰든 branch target, 테스트 범위, 변경 금지 파일, 마이그레이션 승인, 배포 영향, 리뷰어 체크리스트를 명시해야 한다. Ghinda가 언급한 code research -> design change -> review change -> implement -> verify 흐름은 좋은 출발점이다. 한국 SI와 B2B SaaS 환경에서는 이 흐름을 이슈 템플릿과 PR 템플릿에 넣는 것이 현실적이다.

경쟁은 모델보다 습관 적합성으로 간다

OpenAI의 Codex와 Anthropic의 Claude Code는 둘 다 코딩 에이전트 시장을 대표한다. 하지만 앞으로의 경쟁은 같은 문제를 누가 더 빨리 푸느냐만으로 끝나지 않는다. 어떤 도구가 팀의 review 문화에 맞는지, 어떤 도구가 사내 인증과 MCP 흐름을 덜 방해하는지, 어떤 도구가 너무 많이 하지 않는지, 어떤 도구가 충분히 알아서 하는지가 구매 결정에 영향을 준다.

Meta Muse Code, 코딩 에이전트 가격전을 열다는 가격 경쟁을 다뤘다. 그러나 실제 현장에서는 가격보다 실패 비용이 더 클 수 있다. 20달러 구독료 차이보다 잘못된 rebase, 과도한 abstraction, 누락된 테스트, 인증 흐름 지연이 더 비싸다. 코딩 에이전트 UX는 이제 개발 생산성 도구가 아니라 변경 관리 도구다.

자주 묻는 질문

Q1: Codex가 Claude보다 낫다는 뜻인가요?

A: 아니다. 글은 개인 사용기이며, 두 도구의 성향 차이를 보여준다. 작업 종류와 팀 규율에 따라 다르다.

Q2: 왜 작은 세션이 중요한가요?

A: 작업 범위가 좁으면 변경 추적, 리뷰, rollback, 병렬 실행이 쉬워진다. 에이전트가 길게 헤매는 위험도 줄어든다.

Q3: 적극적인 에이전트는 위험한가요?

A: 항상 위험하지는 않다. 모호한 문제에서는 도움이 된다. 다만 과잉 추상화와 범위 확대를 막는 완료 조건이 필요하다.

Q4: 팀에서 바로 적용할 규칙은 무엇인가요?

A: branch target, 변경 범위, 테스트 명령, 금지 파일, PR 설명 형식, 실패 시 중단 조건을 프롬프트와 템플릿에 넣는다.

Q5: MCP 통합은 왜 중요하나요?

A: 코딩 에이전트는 코드만 쓰지 않는다. Jira, GitHub, 문서, 배포 도구 인증 흐름이 매끄러워야 실제 작업 시간이 줄어든다.