나는 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가 그 코드가 실제로 돌아가는지 검증한다.
실제로 어떻게 도는가
이 블로그를 만든 과정이 정확히 그 예다.
- Claude로 계획을 받는다. 무엇을 만들지, 어떤 파일이 필요한지, 기존 코드의 어떤 패턴을 재사용할지 설계한다.
- Claude가 명세를 적는다. "이 파일을 이렇게 만들어라. 이 패턴을 따르고, 이 제약을 지켜라"를 구체적으로 적는다.
- codex가 구현한다. 그 명세를 받아 실제 코드를 생성한다.
- Claude가 검증한다. 빌드와 타입 체크를 돌려서 진짜 돌아가는지 확인하고, 안 맞으면 고친다.
글의 사실 검증도 따로 돈다. 이 글에 적은 내용도 codex가 독립적으로 한 번 더 확인한다. 내가 그럴듯하게 써놓은 게 실제로 맞는지, 다른 엔진의 눈으로 보는 것이다.
분업할 때 지키는 것
- 모델을 명시한다. 어떤 모델로 돌릴지 정확히 지정한다. 내 경험상 기본값에 맡겼다가 엉뚱한 모델이 붙어 느려지거나 멈춘 적이 있다.
- 명세를 구체적으로 적는다. codex는 명세대로 짠다. 명세가 두루뭉술하면 결과도 두루뭉술하다. 따라야 할 패턴, 지켜야 할 제약, 건드리면 안 되는 것을 분명히 적는다.
- 검증은 끝까지 사람이 책임진다. 두 AI가 서로 검증해도, 마지막에 "이게 맞나"를 판단하는 건 나다. 교차검증은 사고를 줄이는 장치지, 책임을 넘기는 도구가 아니다.
혼자서도 팀처럼
이 방식의 핵심은 "AI 두 개 쓰니 두 배 빠르다"가 아니다. 혼자라도 역할이 다른 둘을 부린다는 것이다.
설계하는 사람, 구현하는 사람, 검증하는 사람이 한 팀에 있으면 결과물이 더 단단하다. 그 구조를 혼자서도 만들 수 있다. Claude에게 머리를, codex에게 손을 맡기고, 둘이 서로 검증하게 하면 된다.
혼자 일한다고 해서 한 명의 시야로만 일할 필요는 없다.