Codex와 Claude Code를 실제로 나눠 써본 기준

처음에는 Codex와 Claude Code 차이를 잘 몰랐습니다. 둘 다 코드를 고쳐주고, 파일도 읽고, 설명도 그럴듯하게 해주니까요.

그런데 Daejin Lab을 며칠 굴려보니 쓰임새가 갈렸습니다. 블로그 글 몇 개를 고치거나 빌드 에러 하나를 잡을 때는 Codex가 편했습니다. 반대로 프로젝트 구조를 처음 읽고, 어떤 파일을 건드려야 할지 판단하는 일은 Claude Code 쪽이 덜 답답했습니다.

이 글은 기능 비교표가 아닙니다. Daejin Lab을 만들면서 실제로 제가 어떻게 나눠 썼고, 어디서 멈춰야 했는지 남긴 기록입니다.

처음 헷갈렸던 지점

처음에는 큰 요청을 그대로 던졌습니다.

블로그를 AdSense 승인 가능하게 개선해줘.

이렇게 말하면 답은 길게 옵니다. 맞는 말도 많습니다. 문제는 그다음이었습니다. 실제로 어떤 파일을 먼저 열어야 하는지, sitemap은 건드려야 하는지, 글을 새로 써야 하는지, 기존 글을 고쳐야 하는지 판단이 흐려졌습니다.

그래서 요청을 잘랐습니다.

이 글 5개만 먼저 보강한다.
robots와 sitemap은 건드리지 않는다.
npm run build로 확인한다.
git push는 승인 전까지 하지 않는다.

이렇게 잘라놓고 나서야 도구 차이가 보였습니다. 도구가 똑똑한지보다, 제가 일을 얼마나 작게 잘랐는지가 더 중요했습니다.

Codex는 작은 수정을 빨리 끝낼 때 편했습니다

Codex는 범위가 작을 때 좋았습니다. 특히 파일이 정해져 있고, 바꿀 방향도 분명할 때 속도가 났습니다.

예를 들면 이런 일입니다.

Markdown 글 3~5개 보강
반복되는 문장 줄이기
updatedDate 맞추기
내부 링크 2~3개 추가
npm run build 결과 확인

Daejin Lab에서는 짧은 글을 묶어서 보강할 때 Codex를 많이 썼습니다. src/content/blog 안의 Markdown 파일을 열고, 비슷한 문장을 걷어내고, 실제 운영 기준을 조금씩 넣는 작업이었습니다.

다만 여기서도 그냥 맡기면 글이 너무 반듯해졌습니다. 문장마다 같은 말투가 반복되고, 운영 문서처럼 보였습니다. 지금 이 글을 다시 고치는 이유도 그 때문입니다. 구조는 맞는데 운영자 흔적이 부족했습니다.

Claude Code는 처음 길을 잡을 때 편했습니다

Claude Code는 프로젝트 전체를 읽혀야 할 때 편했습니다.

카테고리 페이지를 추가하거나 sitemap 흐름을 볼 때는 파일 하나만 봐서는 부족했습니다. src/pages, src/content, src/layouts, 설정 파일이 서로 물려 있었습니다. 이럴 때는 먼저 구조를 읽고, 어디를 건드리면 위험한지 보는 쪽이 낫습니다.

Daejin Lab에서 특히 헷갈렸던 부분은 Search Console이었습니다. 사이트에서는 /sitemap.xml이 200으로 열리는데, Search Console에서는 가져올 수 없음처럼 보였습니다. 이때 무작정 sitemap을 계속 바꾸면 오히려 더 위험했습니다.

그래서 Claude Code 쪽에는 넓은 질문을 맡기는 편이 나았습니다.

지금 sitemap 문제가 사이트 문제인지, Google 처리 지연인지 분리해줘.
수정해야 할 파일과 건드리면 안 되는 파일을 나눠줘.

이런 식입니다. 코드 수정 전에 멈춰야 할 지점을 찾는 데 더 쓸모가 있었습니다.

둘을 같이 쓸 때는 순서를 정해야 했습니다

지금은 대충 이렇게 씁니다.

1. Claude Code 쪽으로 구조와 위험 지점을 먼저 본다.
2. 할 일을 1~5개 파일 단위로 자른다.
3. Codex로 작은 수정과 검증을 처리한다.
4. npm run build를 돌린다.
5. push와 외부 콘솔 조작은 사람이 결정한다.

이 순서를 정하기 전에는 도구를 바꿔가며 같은 설명을 반복했습니다. 그게 은근히 피곤했습니다. 비용도 늘고, 결과도 흔들렸습니다.

그래서 Daejin Lab에는 운영 규칙을 남겼습니다.

Astro 기반이다.
배포는 Cloudflare Pages다.
출력 폴더는 dist다.
현재 production 기준은 daejinlab.com이다.
API 키와 토큰은 커밋하지 않는다.
자동 발행은 하지 않는다.
git push는 승인 후 진행한다.

별것 아닌 규칙인데, 이걸 적어두니 매번 처음부터 설명하지 않아도 됐습니다. AI 도구를 잘 쓰는 일은 프롬프트를 멋지게 쓰는 일보다, 반복 설명을 줄이는 일에 더 가까웠습니다.

빌드가 깨지면 말이 다 소용없었습니다

글을 고치든 레이아웃을 바꾸든 마지막에는 이걸 돌렸습니다.

npm run build

설명이 아무리 그럴듯해도 빌드가 깨지면 운영 가능한 결과가 아닙니다. Daejin Lab에서는 배포 전에 적어도 아래를 직접 봤습니다.

/blog/
/categories/
/sitemap.xml
robots.txt
canonical URL

이 부분은 조금 지루하지만, 덕분에 마음이 편했습니다. 도구가 만든 변경은 겉으로는 멀쩡해 보여도 작은 경로 하나가 틀어질 수 있습니다. 그래서 저는 “좋은 답변”보다 “빌드 통과한 변경”을 더 믿게 됐습니다.

직접 봐야 하는 부분

Codex든 Claude Code든 그냥 두면 글이 너무 깨끗해집니다. 문단이 반듯하고, 결론도 얌전하고, 실패한 느낌이 잘 안 납니다.

그런데 실제 작업은 그렇지 않았습니다. Search Console 상태를 보면서 괜히 sitemap을 더 만져야 하나 고민했고, 준비 글을 늘리다가 “이러면 실제 운영 기록이 아니라 외형만 갖춘 사이트처럼 보이는 거 아닌가?” 하는 생각도 들었습니다. 짧은 글을 보강했는데도 다시 읽어보니 너무 깔끔하게 정리한 회의록 같았습니다.

이런 판단은 도구가 대신하기 어렵습니다. 도구는 문장을 매끈하게 만들지만, 어떤 찝찝함을 남겨야 글이 믿을 만해지는지는 사람이 봐야 했습니다.

그래서 지금은 역할을 이렇게 나눕니다.

사람: 방향, 공개 여부, 찝찝한 부분 판단
Claude Code: 구조 파악, 위험 지점 정리
Codex: 작은 수정, 반복 작업, 빌드 확인

이 원칙은 발행 버튼을 자동화하지 않기로 한 이유와도 이어집니다. 작업 규칙은 개인 프로젝트에 AGENTS.md를 두는 이유에, 작은 구현 흐름은 Cursor로 작은 웹앱을 빠르게 만드는 흐름에 따로 적었습니다.

지금 기준으로 다시 고른다면

저는 둘 중 하나만 고르지 않을 것 같습니다.

작은 Markdown 수정, 반복 보강, 빌드 확인은 Codex가 편합니다. 프로젝트 전체 구조를 읽고 위험한 지점을 나눌 때는 Claude Code가 편합니다. 둘 다 못 맡길 일도 있습니다. AdSense 신청, Search Console 콘솔 조작, git push, 실제 이메일 공개 같은 건 사람이 눌러야 합니다.

결국 기준은 간단합니다.

파일과 목표가 분명하다면 Codex
구조와 판단이 먼저라면 Claude Code
공개와 책임이 걸려 있으면 사람

이렇게 적고 보니 대단한 결론은 아닙니다. 그래도 이 기준 하나가 생긴 뒤로는 작업이 덜 흔들렸습니다. 다음 블로그를 만들 때도 저는 아마 이 순서로 시작할 겁니다.

신청 전 다시 본 이 글의 역할

AdSense 신청 전에 이 글을 대표 글로 보는 이유는 단순합니다. Daejin Lab이 AI 도구 이름만 모아둔 블로그가 아니라, 실제 프로젝트에서 어떤 판단을 했는지 보여주는 글이기 때문입니다.

검색으로 들어온 사람은 “Codex가 좋아요, Claude Code가 좋아요?”를 궁금해할 수 있습니다. 그런데 제가 보여주고 싶은 건 한쪽 추천이 아닙니다. 작은 수정은 빠르게 맡기되, 구조 판단과 공개 배포는 사람이 잡아야 합니다. 이 선이 보여야 블로그 전체가 운영자 목소리 없는 글 묶음처럼 보이지 않습니다.

둘 중 뭐가 더 좋으냐보다, 제가 어떤 상태로 일을 넘겼느냐가 결과를 더 많이 갈랐습니다. 범위가 작은 일은 Codex가 빨랐고, 길을 먼저 잡아야 하는 일은 Claude Code가 편했습니다. 하지만 둘 다 제가 멈춤선을 안 정하면, 그럴듯한 방향으로 너무 멀리 가버릴 수 있었습니다.

2026-05-23 기준으로 다시 그린 역할 분리

이 글을 보강하면서 가장 먼저 바꾼 것은 “둘 중 뭐가 더 좋다”는 식의 비교를 피하는 일이었습니다. 제 실제 사용 기준은 제품 순위가 아니라 역할 분리였습니다.

사람, Claude Code, Codex, 검증, 사람의 push 판단으로 이어지는 AI 도구 역할 분리 다이어그램

Daejin Lab에서는 구조 파악, 작은 수정, 검증, 공개 판단을 나눠 봅니다. 어느 도구가 더 좋다는 결론보다 어디까지 맡기는지가 더 중요했습니다.

참고한 공식 문서는 아래입니다.

같은 작업을 맡겼을 때 달랐던 점

실제로 차이가 보인 것은 거창한 벤치마크가 아니라 작은 작업이었습니다.

작업	Codex 쪽이 편했던 점	Claude Code 쪽이 편했던 점	사람이 본 것
Markdown 글 보강	파일 범위가 작으면 빠르게 수정	전체 톤과 중복 구조를 먼저 보는 데 유리	AI 문체가 남는지
sitemap/robots 판단	명령 실행과 diff 확인이 빠름	원인 분리와 위험 파일 식별이 편함	Search Console을 더 만질지
배포 전 검증	build/test 루틴 수행	검증 범위 설계	push 승인 여부
글 방향성	문장 단위 보강	글의 역할과 독자 의도 정리	과장/전문가 행세 여부

사람이 누르는 단계는 남겨둔다

도구를 섞어 쓰다 보면 마지막 버튼까지 맡기고 싶어집니다. 하지만 Daejin Lab에서는 아래 단계는 사람 승인으로 남깁니다.

git push, Search Console, AdSense console, 공개 발행은 승인 후 진행하는 사람 승인 게이트 카드

자동화가 편해도 공개와 계정 조작은 다른 문제입니다. 글쓰기 보조와 발행 권한을 분리해야 사이트가 안전하게 유지됩니다.

업데이트가 필요한 조건

이 글은 제품 비교 글이라 시간이 지나면 낡습니다. 그래서 결론을 고정하지 않고, 업데이트 조건을 남깁니다.

도구의 권한 모델이 바뀔 때
가격/사용량 정책이 크게 바뀔 때
내 작업 환경이 달라질 때
Daejin Lab의 배포/검수 흐름이 바뀔 때

그전까지 이 글의 결론은 “Codex가 낫다” 또는 “Claude Code가 낫다”가 아닙니다. 작은 수정은 작게 맡기고, 구조 판단은 넓게 보고, 공개 책임은 사람이 잡는다는 기준입니다.

확인한 자료와 기록

이 글은 제품 기능표가 아니라 Daejin Lab 작업에서 역할을 나눠 본 기록입니다. 기능과 문서 기준은 아래 자료를 참고했습니다.

OpenAI Developers — Codex
Claude Code Docs — Overview
Google Search Central — Creating helpful, reliable, people-first content
2026-05-23 Daejin Lab 작업 기록: 작은 수정, 구조 설계, 공개 전 검증 단계에서 도구 역할을 분리해 사용

공식 문서는 기능을 확인하는 자료이고, 이 글의 결론은 제 repo 작업에서 어떤 단계에 어떤 도구가 덜 위험했는지를 정리한 운영 기준입니다.

자주 묻는 질문

둘 중 하나만 써도 되나요?

가능합니다. 다만 어떤 도구를 쓰든 작업 범위를 작게 자르고, 공개 전 검증과 승인 단계를 남기는 것이 더 중요했습니다.

AI 도구 비교 글은 빨리 낡지 않나요?

맞습니다. 그래서 이 글은 기능 목록보다 “내 작업에서 어떻게 나눠 썼는지”를 중심으로 둡니다. 제품 기능은 바뀌어도 작업 경계는 비교적 오래 남습니다.

FAQ

Codex와 Claude Code 중 하나만 고르면 되나요?

그렇게 보지 않습니다. 도구별 강점보다 작업 범위, 검증 가능성, 승인선이 더 중요했습니다. 같은 프로젝트에서도 역할을 나눠 쓸 수 있습니다.

AI 코딩 도구 비교에서 가장 조심할 점은 무엇인가요?

절대 순위처럼 말하지 않는 것입니다. 제품은 빠르게 바뀌고, 결과는 repo 구조와 요청 방식에 따라 달라집니다.

Daejin Lab에서는 어떤 기준으로 봤나요?

작은 수정, 반복 검증, 발행 안전, 사람이 마지막에 판단할 수 있는지를 기준으로 봤습니다.