Codex는 신입, Claude Code는 시니어다

신입 개발자와 시니어 개발자인 Codex와 Claude Code의 차이를 알아보세요. 각자의 특징과 장단점, 활용 방법을 살펴보면서 개발자로서의 성장을 이끌어보세요.

bamchi 686

천재 같은 신입과 노련한 시니어


Codex와 Claude Code를 함께 써보며 느낀 것


요즘은 “AI로 코딩한다”는 말이 더 이상 특별하지 않다.

나 역시 실제 서비스 개발 과정에서 여러 모델을 함께 쓰고 있고, 그중에서도 **Codex(gpt-5-codex high)**와 **Claude Code(Opus)**는 성향이 극명하게 다른 두 동료처럼 느껴진다.


흥미로운 점은, 이 둘을 단순히 “누가 더 잘 짜느냐”로 비교하면 본질을 놓치게 된다는 것이다.

이건 실력의 우열 문제가 아니라, 개발자를 닮은 성격의 차이에 가깝다.




Codex: 천재적인 신입 개발자


Codex를 처음 쓸 때 가장 인상적인 건 속도였다.

문제를 던지면, 망설임 없이 바로 코드가 튀어나온다. 아이디어를 구조로 바꾸는 능력이 탁월하다.


마치 이런 느낌이다.


“이건 이렇게 풀면 되지 않나요?”

— 막 입사했는데 유독 머리가 잘 돌아가는 신입


특히 다음과 같은 상황에서 Codex는 정말 강하다.


  • 머릿속에 있는 아이디어를 빠르게 코드 형태로 보고 싶을 때

  • 프로토타입, POC, 실험적인 구조를 만들어볼 때

  • 언어나 프레임워크의 문법적 완성도가 중요할 때


다만, 실제 Rails 서비스를 운영하는 입장에서 보면 아쉬운 지점도 분명하다.


예를 들어 migration 파일을 작성할 때,

up / down 메소드의 의도와 Rails가 권장하는 변화 방식(예: reversible migration)을 정확히 이해하지 못하는 경우가 있다.

또 Kamal 같은 배포 도구에 대해서도, “존재는 알고 있지만 맥락은 모르는” 답변을 내놓을 때가 있다.


이건 Codex가 부족해서라기보다는,

Rails를 ‘사용해 본 시간’이 아직 짧은 개발자 같다는 인상에 가깝다.




Claude Code(Opus): Rails를 오래 써 온 시니어


반면 Claude Code(Opus)는 처음부터 느낌이 다르다.

문제를 던지면, 바로 코드부터 쓰지 않는다. 먼저 맥락을 정리한다.


“이건 Rails에서 이런 흐름으로 가는 게 자연스럽습니다.”


이 말투 자체가 이미 시니어다.


Claude Code의 강점은 명확하다.


  • Rails 플랫폼 전반에 대한 이해도

  • migration → 배포 → 운영으로 이어지는 전체 흐름

  • “가능한 코드”보다 “Rails가 의도한 코드”를 선택하는 판단


같은 migration을 작성하더라도,

단순히 동작하는 코드가 아니라 되돌릴 수 있고, 팀이 유지보수하기 쉬운 형태를 먼저 제안한다.


그래서 Claude Code가 내놓는 코드는 화려하지 않다.

하지만 실제 서비스를 굴려본 사람 입장에서는 “아, 이거 현업에서 쓰던 방식이다”라는 느낌이 든다.


나는 이 지점이 굉장히 중요하다고 생각한다.

코드는 결국 _작성_보다 _운용_의 시간이 훨씬 길기 때문이다.




나는 두 모델을 이렇게 쓴다


그래서 요즘 나는 두 모델을 의도적으로 분리해서 쓴다.

같은 질문을 던지고 답을 비교하는 식이 아니라, 역할을 나눠서 함께 일하게 만든다.


보통 개발을 시작할 때 나는 이렇게 세팅한다.


Warp 터미널을 열고

좌우로 두 개의 패널을 만든다.


  • 왼쪽 패널: Claude Code(Opus)

  • 오른쪽 패널: Codex(gpt-5-codex high)


왼쪽에는 늘 Claude Code가 있다.

여기서는 코드를 바로 쓰지 않는다.


먼저 Claude Code에게 플랜을 짜게 한다.


  • 이 기능을 Rails에서는 어떤 구조로 가져가는 게 자연스러운지

  • 모델, 컨트롤러, 서비스 객체의 경계는 어디가 좋은지

  • migration은 어떤 순서로 가야 안전한지

  • 배포와 운영까지 고려했을 때 주의할 점은 무엇인지


Claude Code는 이 단계에서 거의 기술 설계 리뷰어처럼 행동한다.

“이렇게 가는 게 Rails스럽습니다”라는 말이 자연스럽게 나온다.


그 다음, 같은 계획을 오른쪽의 Codex에게 던진다.


“이 플랜에 빠진 게 없는지 봐줘.”

“여기서 더 단순화할 수 있는 부분이 있을까?”


Codex는 이때 정말 좋은 역할을 한다.

구조의 허점을 빠르게 짚거나, 불필요하게 복잡해진 부분을 과감하게 정리해준다.




작성은 Claude, 검토는 Codex


계획이 정리되면, 실제 코드는 다시 Claude Code로 작성한다.


이유는 단순하다.

Rails에서는 “되게 만드는 코드”보다

“오래 살아남는 코드”가 더 중요하기 때문이다.


Claude Code가 쓰는 코드는 속도는 느릴 수 있지만,


  • migration의 되돌림을 고려하고

  • Rails의 관용을 해치지 않고

  • 나중에 내가 다시 봐도 이해할 수 있는 형태로 나온다


코드가 어느 정도 완성되면,

그제서야 Codex를 코드 리뷰어로 쓴다.


  • 이 로직, 더 단순하게 쓸 수 있지 않을까?

  • 쿼리나 반복 처리에서 놓친 부분은 없을까?

  • 테스트하기 애매한 구조는 없는지


Codex는 이 단계에서 정말 유능하다.

마치 눈 밝은 신입이 선배 코드에 거리낌 없이 질문을 던지는 느낌이다.


CleanShot 2026-01-07 at 13.16.22@2x.jpg



두 AI를 동시에 쓰며 느낀 점


이렇게 쓰다 보니 확실해졌다.


Codex와 Claude Code를 비교하는 건 큰 의미가 없다.

중요한 건 어떤 역할로 배치하느냐다.


  • Codex는 발산과 점검에 강하고

  • Claude Code는 축적과 안정에 강하다


Warp의 좌우 패널에 이 둘을 나란히 두고 있으면,

혼자 개발하고 있음에도

팀 안에 서로 다른 성향의 개발자 둘이 있는 것 같은 기분이 든다.


그리고 나는 그 사이에서

결정을 내리는 개발자일 뿐이다.

댓글

댓글 작성

이메일은 공개되지 않으며, 답글 알림에만 사용됩니다.

이어서 읽어보세요

새 글 알림 받기

Bamchi Blog의 새 글이 발행되면 이메일로 알려드립니다.

이메일은 새 글 알림에만 사용됩니다.