DAYLAB
2026-06-08 · 3분 읽기

나는 Claude Code를 혼자 안 쓴다 — codex와 분업하는 법

Claude는 설계와 검증, codex는 구현. 두 AI를 분업시키면 한 모델이 쓰고 같은 모델이 검증하는 함정을 피할 수 있다. 1인 메이커의 실제 워크플로우.

대부분 Claude Code 하나로 코딩의 모든 걸 한다고 생각한다. 나는 그렇게 안 쓴다. Claude Code와 codex, 두 AI를 나눠서 부린다. Claude는 설계하고 검증하는 머리, codex는 코드를 짜는 손이다.

처음엔 그냥 하나로 다 했다. 그런데 혼자 여러 개를 만들수록 한 가지 문제가 반복됐다. 한 모델이 코드를 쓰고, 같은 모델이 "잘 됐다"고 하면, 틀린 걸 못 잡는다. 사람이 자기 글 오타 못 보는 것과 같다. 그래서 역할을 나눴다.

왜 두 개로 나누나

두 가지 이유다.

1. 역할 분리. 설계하는 일과 구현하는 일은 머리 쓰는 방식이 다르다. 한 흐름에서 둘을 같이 하면, 설계가 대충 되거나 구현이 산만해진다. "무엇을 어떻게 만들지"는 Claude가 정하고, "그걸 실제 코드로 옮기는 건" codex가 한다. 손과 머리를 분리하니 양쪽 다 깔끔해졌다.

2. 독립 교차검증. 이게 더 중요하다. codex가 쓴 코드를 Claude가 빌드와 타입 체크로 검증한다. 글의 사실관계도 마찬가지다. Claude가 쓴 글을 codex가 다른 엔진으로 다시 확인한다. 서로 다른 모델이 한쪽의 결과를 검증하는 구조라, 한 모델만 쓸 때 놓치는 걸 잡는다.

실제 분업표

누가
계획·설계 (plan mode) Claude
구현 명세 작성 Claude
실제 코드 생성 codex
빌드·타입 체크 검증 Claude
코드 통합 Claude
글·콘텐츠 사실 검증 codex (독립 교차)

핵심은 구현 코드 자체는 codex가 쓴다는 것이다. Claude는 "이렇게 만들어라"는 명세를 정확히 적고, codex가 그걸 코드로 옮기고, 다시 Claude가 그 코드가 실제로 돌아가는지 검증한다.

실제로 어떻게 도는가

이 블로그를 만든 과정이 정확히 그 예다.

  1. Claude로 계획을 받는다. 무엇을 만들지, 어떤 파일이 필요한지, 기존 코드의 어떤 패턴을 재사용할지 설계한다.
  2. Claude가 명세를 적는다. "이 파일을 이렇게 만들어라. 이 패턴을 따르고, 이 제약을 지켜라"를 구체적으로 적는다.
  3. codex가 구현한다. 그 명세를 받아 실제 코드를 생성한다.
  4. Claude가 검증한다. 빌드와 타입 체크를 돌려서 진짜 돌아가는지 확인하고, 안 맞으면 고친다.

글의 사실 검증도 따로 돈다. 이 글에 적은 내용도 codex가 독립적으로 한 번 더 확인한다. 내가 그럴듯하게 써놓은 게 실제로 맞는지, 다른 엔진의 눈으로 보는 것이다.

분업할 때 지키는 것

  • 모델을 명시한다. 어떤 모델로 돌릴지 정확히 지정한다. 내 경험상 기본값에 맡겼다가 엉뚱한 모델이 붙어 느려지거나 멈춘 적이 있다.
  • 명세를 구체적으로 적는다. codex는 명세대로 짠다. 명세가 두루뭉술하면 결과도 두루뭉술하다. 따라야 할 패턴, 지켜야 할 제약, 건드리면 안 되는 것을 분명히 적는다.
  • 검증은 끝까지 사람이 책임진다. 두 AI가 서로 검증해도, 마지막에 "이게 맞나"를 판단하는 건 나다. 교차검증은 사고를 줄이는 장치지, 책임을 넘기는 도구가 아니다.

혼자서도 팀처럼

이 방식의 핵심은 "AI 두 개 쓰니 두 배 빠르다"가 아니다. 혼자라도 역할이 다른 둘을 부린다는 것이다.

설계하는 사람, 구현하는 사람, 검증하는 사람이 한 팀에 있으면 결과물이 더 단단하다. 그 구조를 혼자서도 만들 수 있다. Claude에게 머리를, codex에게 손을 맡기고, 둘이 서로 검증하게 하면 된다.

혼자 일한다고 해서 한 명의 시야로만 일할 필요는 없다.