Codex와 Claude Code를 2025년 12월 22일 시점에서 비교하며, 각 도구가 잘 맞는 작업 스타일과 선택 기준을 정리한다.
URL: https://build.ms/2025/12/22/codex-vs-claude-code-today/
2025년 12월 22일 | 5분 읽기
모든 프로그래머에게는 각자 좋아하는 언어가 있다. 어떤 사람은 Python을 선호하고, 다른 사람은 TypeScript1에 목숨을 건다. 어떤 팀은 Postgres 위에 앱을 만들고, 다른 팀은 MySQL을 쓴다. 이런 선택은 강한 의견을 가진 프로그래머들 사이에서 흔히 불꽃 튀는 논쟁거리(플레임 워) 미끼가 되지만, 대부분의 결정은 실용성, 우선순위, 그리고 트레이드오프를 중심으로 내려진다. 이는 도덕적 선언이라기보다 서로 다른 작업 방식의 반영이다.
이 모든 이야기는 사람들이 Claude Code와 Codex 중 무엇을 쓸지 결정할 때도 그대로 적용된다.
계속하기 전에 고지할 점이 하나 있다. 이 글은 2025년 12월 22일 시점의 Claude Code와 Codex에 관한 내용이다. AI는 변화 속도가 너무 빨라서, 1년 뒤는 물론이고 아마 3~6개월 뒤에도 여기 적힌 말들의 타당성이 얼마나 남아 있을지 거의 기대하지 않는다.
또 Codex와 Claude Code 모두 이미 초인적인 개발자라는 점을 강조하고 싶다. 이는 단지 Opus 4.5와 codex-5.2-high의 출력 품질 때문만이 아니라, “일하는 방식” 때문이다. Codex와 Claude Code는 때로 우리가 코딩을 생각하는 방식과는 전혀 다른, 거의 이질적으로 느껴지는 방식으로 해법에 도달하곤 한다. AlphaGo의 37수처럼 말이다.
나는 가능한 모든 AI 도구를 따라잡으려 한다. 그래야 누구에게나 AI를 가르칠 수 있기 때문이다. 하지만 이제는 모든 소프트웨어 개발자에게도 점점 “필수”가 되어가고 있다. 코딩과 관련해서는 나는 대체로 Codex를 “코딩”에 쓰는 쪽으로 정착했다. 따옴표를 친 이유는, 그 과정이 손으로 코드를 작성하는 것과 매우 다르기 때문이다. 나는 Codex를 위한 프롬프트를 쓰고 맥락을 생성하는 데 30분에서 2시간까지 쓰고, 그다음 작업은 15~20분 동안 돌아가는 동안 완전히 다른 일로 컨텍스트 스위칭을 한다. 다시 돌아오면 하루치에서 많게는 일주일치 코드가 나를 기다리고 있다.
하지만 나는 여전히 Claude Code도 많이 쓴다. 그들이 구축한 코딩 환경은 탁월하다. Peter Steinberger가 Claude Code를 자신의 컴퓨터라고 설명했듯이, 나도 온갖 작업을 Claude Code에 위임한다. 예를 들어 Skills로 동영상을 mp3로 전사하거나, 내 웹사이트를 위한 다크 모드 컬러 팔레트를 생성하거나, 블로그 글의 아이디어를 빠르게 프로토타이핑하기도 한다.
무언가를 “제대로” 끝내야 할 때 나는 Codex를 부른다. 이유는 단순하다. 내게는 결과가 믿기지 않을 정도로 좋기 때문이다. 그리고 그건 내 작업 방식 덕분이다. 컨텍스트 엔지니어링과 컨텍스트 플러밍에 시간을 투자하면, 훨씬 더 오래 “키보드에 손을 대지 않은 채”로 있을 수 있다.
오래 돌아가는 작업이 단점처럼 들릴 수도 있지만, 그건 그저 다른 방식의 일하기다. Codex에게 20분 걸리는 작업을 맡기면 나는 완전히 다른 것에 집중한다. Figma를 열어 디자인 작업을 하거나, 뉴스레터를 쓰거나, 혹은 첫 번째 터미널이 클라이언트 작업을 처리하는 동안 다른 터미널을 열어 Codex에 서버 작업을 프롬프트로 던지기도 한다.
나는 모든 것이 더 오래 걸리더라도, 내가 고칠 필요 없는 결과를 얻는 편을 선호한다. AI가 성공하도록 과정에 계속 관여하며 “조종”하는 방식보다는 말이다. 이게 내게 가장 잘 맞는 작업 스타일이다. OpenAI의 최신 모델들은 최신 Claude 모델들보다 내가 루프 안에 덜 있어도 더 좋은 결과를 내준다. 그래서 그 사실이 유지되는 한, 나는 대부분 Codex를 고수할 것이다.
그리고 여기서 내가 왜 많은 엔지니어가 Claude Code를 선호하는지에 대한 가설이 나온다. Claude는 당신이 더 “엔지니어링 일을 하고 있다”는 느낌을 준다 — 그리고 놀랍게도 — 엔지니어들은 엔지니어링 일을 좋아한다. 근거: 나도 엔지니어다.
Claude에는 조절할 수 있는 “노브(knob)”가 많다. CLAUDE.md, Skills, Agents, MCP, 슬래시 커맨드 등등. Codex에도 비슷한 기능이 있지만, 대체로 기본 상태에서도 높은 품질의 결과를 내는 쪽에 가깝다. 반면 Claude는 그 노브들을 정교하게 튜닝할 때 가장 잘 작동하며, Anthropic은 개발자 관계(DevRel)와 마케팅에서도 그런 튜닝을 적극적으로 장려한다.
이는 환경 설정을 좋아하는 엔지니어들과 완벽하게 맞는다. 나는 Xcode의 새 기능을 시험해 보거나, 실제 생산성을 0.05% 올려주는(듯한) VS Code 확장을 조사하느라 내 인생의 온전한 하루를 얼마나 많이 날렸는지 셀 수도 없다.
개인적으로 — 그리고 이게 개인적 선택임을 강조하지만 — 나는 잘 명세된 계획을 써두고 15분 동안 다른 일을 하러 가는 편이 좋다. Claude의 Plan Mode는 탁월하며, 그래서 많은 사람들이 한 번 써보면 Claude에 빠져든다.2
많은 엔지니어들은 개발 과정을 단계별로 직접 만지고(핸즈온) 이끌고 싶어 한다. 이는 몰입 상태(flow state)가 어떤 모습인지 생각해 보면 매우 이해가 간다. Claude는 잘못된 방향으로 가지 않도록 스스로를 더 자주 멈추고 질문을 쏟아낸다. 그게 당신으로 하여금 정말로 고개 숙여 몰입해 엔지니어링 일을 하고 있다는 느낌을 강하게 만든다.
나는 지난 세월 함께 일했던 동료들과 그들의 제각각인 선호를 떠올린다. 어떤 사람은 문제를 풀기 위해 해야 할 일을 전부 체크리스트로 만들기 전에는 코딩을 시작하지 못했다. 또 다른 사람은 바로 뛰어들어 프로토타입을 만들면서, 자신이 활동할 공간을 이해해 나가곤 했다.
우리가 만드는 데 사용하는 도구들은 빠르고 강하게 변하고 있어서 따라잡기 어렵지만, 선택지는 넘쳐난다. 좋은 소식은 AI에 관해서 “틀린 선택”은 없다는 것이다. 그래서 나는 개인적으로 Codex를 선호하더라도, Claude Code 속에서 사는 사람들을 폄하하지 않는다.
당신이 고르는 도구는 당신의 작업 방식에 맞아야지, 그 반대가 되어서는 안 된다. Claude를 쓰고 있다면, 일주일 정도 Codex를 써 보길 권한다. 어쩌면 당신이 Codex 타입인데 몰랐을 수도 있다. Codex를 쓰고 있다면, 일주일 정도 Claude Code를 써 보길 추천한다. 어쩌면 생각보다 당신이 Claude 타입일 수도 있다.
지금의 접근이 당신에게 최선이 아닐 수도 있고, 아닐 수도 있다. 하지만 나는 확신한다. 모든 AI 도구에는 강점과 약점이 있으며, 그것이 무엇인지 알아내는 유일한 방법은 실제로 써보는 것뿐이다.
알고 있듯이 나는 Swift를 주로 쓰는 사람이고, 웹과 맞닿는 부분에는 TypeScript를 약간 곁들인다. ↩
나는 Claude의 Plan Mode가 기본적으로 Codex와 “항상” 함께 일하는 방식과 거의 같다고 주장할 것이다. 그리고 그게 내가 Codex를 선호하는 주요 이유 중 하나다. ↩
