Claude Code와 Codex, 결국 뭘 써? 사고 안 나는 '병행'의 현실적 답

“그래서 결국 뭘 쓰면 되는데?”

Claude Code와 OpenAI의 Codex. 둘 다 만져본 사람일수록 이 질문에서 답답해하고 있을 겁니다. 저도 처음엔 “한쪽으로 정해야 해”라고 생각했어요.

그런데 반년 써보니, 답은 싱겁더군요. 둘 중 하나가 아니다. 둘 다 쓴다. 단 맡기는 일을 나눈다. 이게 전부입니다.

문제는 “어느 쪽이 똑똑한가”가 아니에요. 칼과 가위, 뭐가 더 잘났나를 비교하지 않는 것과 같습니다. 채소면 칼, 종이면 가위. 도구에는 잘하는 모양이 있고, 잘못 쓰면 손가락을 벱니다. 오늘은 그 “어느 쪽에 어떤 일을 넘길까”와, 둘을 동시에 돌려도 사고가 안 나는 배치 이야기입니다.

부추기지 않겠습니다. 어느 쪽이 위, 같은 결론도 내지 않아요. 제가 이 사이트를 운영하며 실제로 밟은 지뢰를, 솔직히 늘어놓겠습니다.

먼저, 둘의 성격 차이부터

똑똑함 비교는 제쳐 두고, 성격 이야기를 합니다.

Claude Code는 눈앞의 어질러진 방을, 옆에서 같이 치워 주는 짝꿍입니다. 당신의 저장소를 열어, CLAUDE.md 에 적은 규칙을 읽고, “여기 고치는 김에 이쪽도” 하고 맥락을 이으며 대화식으로 고쳐 나가요. 지금 있는 코드의 사정을 헤아리는 데 능합니다. 그래서 기존 프로젝트의 리팩터링이나, 로컬에서의 세세한 조정에 강해요.

Codex는 딴 방에 있으면서, 부탁한 일을 혼자 진행해 주는 외주처에 가깝습니다. 작업을 툭 넘겨 클라우드 쪽에서 돌리거나, Pull Request를 던져 리뷰에 올리거나 하는 위임 스타일과 궁합이 좋아요. OpenAI도 Codex를, 코드 작업을 맡길 수 있는 짝꿍으로 설명합니다(OpenAI: Introducing Codex). 손을 떼고 맡기는 게 특기인 거죠.

거칠게 말하면, Claude Code는 “옆에서 함께”, Codex는 “맡기고 기다린다”. 이 온도 차를 기억해 두면, 사용 분담이 쑥 들어옵니다.

단, 여기 적은 모델명이나 요금, 할 수 있는 일의 경계는 꽤 금방 바뀝니다. 둘 다 갱신이 빨라요. 그러니 최종적인 강점·약점과 요금은 반드시 공식(OpenAI 문서와 Claude Code 문서)에서 최신을 확인하세요. 이 글은 ‘사고방식의 지도’라고 생각해 주시면 됩니다.

어느 작업을, 어느 쪽에 넘길까?

지도만으로는 쓰기 어려우니, 제 실제 배분을 둡니다. 어디까지나 현시점의 제 감각이고, 절대적인 정답은 아닙니다.

하고 싶은 일	주 담당	왜
기존 저장소의 복잡한 리팩터링	Claude Code	주변 맥락을 읽어 휘말림 사고를 피해 준다
로컬에서 대화하며 설계·조정	Claude Code	”역시 이렇게 해”의 왕복이 빠르다
또렷이 떼어낼 수 있는 독립 작업의 위임	Codex	던져 두고 딴 작업으로 넘어갈 수 있다
PR을 만들어 리뷰에 올리기	Codex	위임 + 리뷰 흐름에 타기 쉽다
프로젝트 고유 규칙 준수	Claude Code	CLAUDE.md 를 읽어 잘 먹인다
여러 작업을 병행으로 돌리기	둘 다	한쪽에 대화, 한쪽에 위임, 으로 안 막힌다

포인트는 마지막 행입니다. 양자택일이 아니라 역할 분담. 저는 Claude Code와 화면 앞에서 설계를 다지면서, 떼어낸 잡무는 Codex에 던져 딴 방에서 진행시키는 쌍칼 운용에 정착했습니다.

그리고 여기가 본론. 어느 쪽을 쓰든, 안전장치의 사고방식은 같다는 겁니다. 똑똑한 AI를 고르기보다, 넘어져도 안 다치는 배치를 먼저 만든다. 이걸 저는 “하네스(harness) = AI의 발판·생명줄”이라고 부릅니다. 개념부터 알고 싶은 분은 하네스 엔지니어링 완전 가이드를 보세요.

발판은 4개 층으로 생각하면 정리가 쉽습니다. 어렵지 않아요.

당신의 의뢰
  ↓
AI(Claude Code / Codex)
  ↓
[1] 허가의 층   무엇을 시키고, 무엇을 멈출까
[2] 단계의 층   어떤 순서로 할까
[3] 검증의 층   끝난 뒤 무엇으로 'OK'를 확인할까
[4] 복구의 층   실패하면 어떻게 되돌릴까
  ↓
파일 / 셸 / 외부 서비스 / 배포

이 4가지가 빠지면, Claude Code든 Codex든 대개 같은 자리에서 넘어집니다.

이런 장면에서 ‘병행’이 효과를 본다 (3가지)

1. 설계는 Claude Code, 양산은 Codex

새 기능의 데이터 설계처럼 “갔다 왔다”가 필요한 작업은, Claude Code와 화면 앞에서 다집니다. 정해진 뒤의 “같은 형태의 파일을 8개 더” 같은 단순 작업은, Codex에 떼어 던져요. 머리 쓰는 시간과 기다리기만 하는 시간이 깔끔하게 나뉘었습니다.

2. 본체는 Claude Code, 리뷰는 Codex

Claude Code와 쓴 코드를, 다른 눈으로 봐줬으면 할 때 있잖아요. 그때 Codex에 PR 리뷰를 돌립니다. 같은 AI가 쓰고 리뷰하는 것보다 시점이 어긋나서, 지적이 늘어요. 사람 리뷰 전의 ‘1차 거르기’로 나쁘지 않습니다.

3. 위험한 조작은, 어느 쪽이든 사람이 마지막에 누른다

이게 가장 중요합니다. 배포, 운영 DB 갱신, 메일 전송, git push, npm publish. 이런 ‘되돌릴 수 없는 조작’만은, Claude Code든 Codex든, 마지막은 사람이 버튼을 누르는 설계로 합니다. 생성이나 초안은 자동으로 해도 돼요. 그런데 바깥으로 날아가는 조작은 멈춘다. 발판 쪽에서 강제해 두면, 한밤중에 사고 안 납니다.

허가의 선 긋기는, 이렇게 파일로 들고 있으면 안 헷갈립니다. Claude Code라면 .claude/settings.json 에 적을 수 있어요.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm run test *)",
      "Bash(node scripts/content-trend-report.mjs *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(wrangler pages deploy *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

요령은, 금지를 “왠지 위험해 보여서”로 쓰지 않는 것. rm -rf, git reset --hard, .env 읽기, 운영 배포 계열. 구체적인 명령어 이름으로 적습니다. 자세한 짜는 법은 Claude Code settings가 입구예요. Approval / Sandbox 실전은 Approval / Sandbox 설정 가이드에 정리했습니다.

Codex 쪽에도 같은 발상이 있습니다. 샌드박스(격리된 작업장)와 승인(approval)으로 “여기까지는 알아서 해도 된다, 여기서부터는 사람에게 묻는다”를 가른다. 설정 이름은 달라도, 하고 싶은 건 같아요. 한번 하네스 사고방식을 몸에 익히면, 도구가 바뀌어도 응용이 됩니다.

내가 저지른 실패 3가지

솔직하게 적습니다. 병행, 처음엔 꽤 사고 났어요.

첫째. 둘에게 같은 일을 맡겨, 덮어쓰기 싸움이 났다. Claude Code로 고치던 파일을, Codex에도 “여기 고쳐”라고 던져 버렸습니다. 당연히 한쪽 변경이 다른 쪽에 덮어써져서, 뭐가 맞는지 알 수 없게 돼요. 지금은 “이 파일은 지금 Claude Code 쪽”이라고 건드리는 범위를 나눕니다. 같은 도마를 둘이 동시에 쓰지 않는다. 당연한 건데도 말이죠.

둘째. Codex에 넘기는 작업이 너무 모호했다. “알아서 잘 고쳐줘” 같은 맥락 의존 의뢰를 위임 쪽에 던지면, 변변한 결과가 안 나옵니다. 위임은 외주라서, 독립적으로 완결되는 형태로 떼어낸 뒤 넘기는 게 철칙이었어요. 반대로 맥락이 필요한 작업은, 무리해서 위임하지 말고 Claude Code와 대화로 진행한다. 의뢰의 형태가, 도구 선택을 결정하는 겁니다.

셋째. “나중에 내가 확인하면 되지”로 돌렸더니, 바쁜 날에 무너졌다. 공개 URL이 404인 채로, 광고 태그가 사라진 채로, 모르고 진행된 적이 있습니다. 눈 점검은 바쁘면 반드시 건너뛰어요. 그래서 기계가 알 수 있는 확인은, 기계에 시킨다. 예를 들어 공개 페이지가 살아 있는지를, 이런 작은 스크립트로 두드리게 했습니다.

// scripts/verify-published-page.mjs
const url = process.argv[2];

if (!url) {
  throw new Error("Usage: node scripts/verify-published-page.mjs <url>");
}

const response = await fetch(url, { redirect: "follow" });
if (!response.ok) {
  throw new Error(`Page returned ${response.status}: ${url}`);
}

const html = await response.text();
const checks = [
  ["title", /<title>.+<\/title>/i],
  ["description", /<meta name="description"/i],
  ["main content", /<article|data-pagefind-body|blog-post/i],
];

for (const [name, pattern] of checks) {
  if (!pattern.test(html)) {
    throw new Error(`Missing ${name} on ${url}`);
  }
}

console.log(`OK: ${url}`);

완벽한 검증은 아닙니다. 그래도 “공개한 줄 알았는데 404” “중요한 태그가 사라졌다” 정도의 어이없는 사고는 이걸로 멈춰요. AI는 실패 로그의 마지막 줄만 보고 엉뚱한 데를 고치기 일쑤라서, 무엇을 가지고 OK로 칠지를 먼저 코드로 정해 두면 효과가 있습니다.

시작한다면, 여기서부터

다짜고짜 완전 자동의 쌍칼을 짜지 마세요. 순서가 있습니다.

먼저, 오늘의 작업을 하나, 머리 쓰는 쪽과 기다릴 수 있는 쪽으로 가른다. 판단이 필요한 부분은 Claude Code와 대화로. 떼어낸 단순 작업은 Codex에 위임. 이것만으로 체감 속도가 달라집니다.

다음으로, 위험한 조작을 전부 “사람에게 묻기(ask)“로 기울인다. 배포·push·전송·운영 DB는, 처음엔 무조건 승인 대기. 안전하다고 확인된 것만 나중에 자동으로 승격합니다. 넓히는 건 나중에 해도 됩니다. 처음엔 좁게.

그리고, 그대로 넘길 수 있는 의뢰 양식을 하나 들고 있으면 매번 안 흔들려요. Codex에 위임할 때의 제 템플릿입니다. 복붙하고 내용만 채우면 됩니다.

# 작업(독립적으로 완결되는 단위로)
<예: src/utils/ 아래 날짜 포맷 함수에 단위 테스트를 추가한다>

# 건드려도 되는 범위
- 건드림: <예: src/utils/date.ts 와 tests/date.test.ts 만>
- 안 건드림: <예: 위 외의 파일. 설정 파일이나 .env 는 읽지 않는다>

# 완료 조건(여기를 가지고 OK로 친다)
- npm run test 가 전부 통과
- 기존 함수의 시그니처를 바꾸지 않는다
- 신규 파일 외에는 변경점을 최소로

# 해서는 안 되는 것
- git push 하지 않는다(PR/변경점 제시까지)
- 의존 패키지를 멋대로 추가하지 않는다
- 운영·배포·전송 계열 조작은 일절 하지 않는다

“안 건드리는 범위”와 “해서는 안 되는 것”을 명문화해 두는 게 핵심입니다. 위임 쪽 AI는 눈치껏 쓸데없는 데까지 건드리러 갈 때가 있어서, 처음부터 울타리를 쳐 둔다. 이건 외부 문서의 지시를 작업 명령으로 오해하는 사고(Prompt Injection) 대책도 됩니다. 이쪽의 위험한 의뢰 피하는 법은 위험한 프롬프트를 피하는 실무 체크에 자세히 적었습니다.

실제로 해본 결과

이 사이트를 반년 운영하며, 둘을 병행해 본 결론입니다.

효과가 가장 컸던 건, 의외로 “금지 규칙”보다 **“ask로 남긴 경계”**였습니다. 글 초안이나 번역, 리팩터링 안 내기는, Claude Code든 Codex든 자동화해도 문제가 잘 안 일어나요. 그런데 배포, git push, 메일 전송, 운영 URL 갱신만은 사람의 확인을 남긴다. 여기를 사수한 것만으로, 가슴 철렁한 횟수가 뚝 줄었습니다.

반대로 확실한 실패였던 건, 긴 프롬프트에 전 절차를 쑤셔 넣는 방식입니다. 한 방에 전부 시키려고 욕심부렸더니, 세션이 무거워지고, 도중에 멈추기 쉬워졌어요. 짧은 지시로 하고, 실행 규칙은 발판(settings나 승인 라인) 쪽으로 옮긴다. 이쪽이 압도적으로 재현성이 있습니다.

그리고 사용 분담의 실감. “한쪽으로 정하기”를 놓은 게 가장 효과적이었다. 칼과 가위를 둘 다 들듯, Claude Code로 옆을, Codex로 딴 방을 동시에 돌린다. 뇌는 하나여도 일이 두 배 진행되는 감각은, 한번 맛보면 못 돌아갑니다. 다만 거듭 말하지만, 둘의 강점·요금·모델은 갱신이 빠르니, 본격적으로 투자하기 전에 공식에서 최신을 확인하세요.

정리

“Claude Code와 Codex, 뭘 써?”에 대한 제 답은, **“둘 다. 단 맡기는 일과, 멈추는 조작을 나눈다”**입니다.

• 옆에서 함께 고치면 Claude Code, 맡기고 기다리면 Codex
• 맥락이 필요한 작업은 대화, 떼어낼 수 있는 작업은 위임
• 어느 쪽을 쓰든, 안전장치(허가·단계·검증·복구)의 사고방식은 같다
• 위험한 조작(배포·전송·운영 DB)은, 마지막은 사람이 누른다

도구 고르기로 고민하는 시간을, 발판 하나 만드는 시간으로 바꿔 보세요. 일의 질은, 어느 AI가 똑똑한가보다 그 바깥쪽 배치가 결정합니다.

권한 설계나 CI, 팀 운용 규칙까지 함께 갖추고 싶다면, 바로 쓸 수 있는 템플릿을 교재 목록에 정리해 뒀습니다. 자사 저장소에 맞춰 함께 달려줬으면 할 때는 연수·상담에서 연락 주세요.