품앗이(Pumasi)로 Claude와 Codex를 나눠 쓰는 법 — 계획은 Claude, 구현은 Codex

1. 영상의 요지: Claude가 모든 코드를 쓰지 않게 만든다

쇼츠의 핵심 문장은 간단하다. “Claude는 코드를 쓰지 않고 계획만 짜고 리뷰한다. Codex가 구현한다.” Pumasi는 이 구조를 Claude Code 안에서 실행하기 위한 플러그인이다. 영상에서는 “Claude가 계획자고 Codex가 구현하고 다시 Claude가 리뷰하는 구조”라고 설명한다.

이 말은 Claude가 더 똑똑하고 Codex가 더 싸다는 단순 비교가 아니다. 실제 개발 작업에서는 모델 하나가 처음부터 끝까지 모든 일을 하는 방식이 항상 효율적이지 않다. 요구사항을 정리하고, 모듈 경계를 나누고, 어떤 파일을 만들지 결정하는 일과 실제 구현 코드를 작성하는 일은 성격이 다르다. Pumasi는 이 둘을 나눠서 Claude의 강점은 설계와 판단에, Codex의 강점은 구현과 반복 작업에 배치한다.

공식 README도 같은 방향을 말한다. Pumasi는 “Claude as PM + Codex CLI as parallel outsource developers”를 표방한다. 여기서 PM은 프로젝트 매니저에 가깝다. Claude가 요구사항, 데이터 모델, 함수 시그니처, 검증 게이트를 정하고 Codex가 각 모듈의 실제 구현을 맡는 식이다.

2. Pumasi가 노리는 문제: 토큰보다 비싼 것은 ‘한 모델이 모든 맥락을 들고 가는 방식’이다

AI 코딩 도구를 오래 쓰다 보면 비용 문제보다 먼저 체감되는 것이 맥락 관리다. 하나의 세션에서 설계, 구현, 수정, 테스트, 리뷰를 계속 이어가면 대화가 길어진다. 모델은 이전 판단을 유지하려 하고, 사용자는 어느 순간부터 “왜 이렇게 돌아가는지” 다시 설명해야 한다. 비용은 누적되고, 속도는 떨어지고, 작은 수정이 전체 설계를 흔드는 일도 생긴다.

Pumasi의 접근은 이 문제를 역할 분리로 푼다. Claude는 전체 맥락을 길게 들고 있지만 실제 코드 본문까지 모두 작성하지 않는다. 대신 “이 파일에는 이런 함수가 필요하고, 입력과 출력은 이렇고, 이 테스트를 통과해야 한다”는 수준의 작업 지시를 만든다. Codex는 그 지시를 받아 구현한다. 구현이 끝나면 타입 검사, 빌드, 테스트 같은 게이트로 먼저 걸러낸 뒤 Claude가 필요한 부분만 읽는다.

이 구조가 잘 맞으면 두 가지 이득이 생긴다. 첫째, Claude의 긴 사고를 설계와 판단에 남겨 둘 수 있다. 둘째, Codex를 여러 개 띄워 독립 모듈을 동시에 만들 수 있다. 단순히 AI를 하나 더 켜는 것이 아니라, 사람이 여러 개발자에게 일을 나눠 맡기듯이 모델 간 업무 분장을 하는 것이다.

3. 공식 Codex 플러그인과 Pumasi의 차이: 리뷰·외주·병렬화의 깊이가 다르다

OpenAI도 Claude Code 안에서 Codex를 쓰는 공식 플러그인을 공개했다. 공식 README 기준으로 이 플러그인은 Claude Code 안에서 /codex:review, /codex:adversarial-review, /codex:rescue 같은 명령을 제공한다. 현재 작업 변경분을 Codex가 읽고 리뷰하거나, 특정 문제를 Codex에게 맡기는 방식이다.

Pumasi는 같은 생태계에 있지만 초점이 조금 다르다. OpenAI의 Codex 플러그인이 “Claude Code 작업 흐름 안에서 Codex를 호출하는 공식 통로”라면, Pumasi는 “Claude를 프로젝트 매니저로 두고 Codex를 여러 구현자로 병렬 배치하는 운영 방식”에 가깝다. 즉 공식 플러그인은 리뷰와 개별 위임에 강하고, Pumasi는 독립 모듈이 많은 신기능 구현에 더 선명한 색깔을 가진다.

4. 언제 쓰면 좋은가: “큰 작업”이 아니라 “나눌 수 있는 작업”이어야 한다

영상에서도 중요한 단서가 나온다. “복잡한 태스크, 어느 정도 규모가 클 때 같이 협업하는 게 의미가 있고, 태스크 규모가 작을 때는 그냥 Claude 단독으로 작업하는 게 낫다.” 이 말이 핵심이다. Pumasi는 큰 작업이면 무조건 좋은 도구가 아니다. 나눌 수 있는 작업이어야 한다.

예를 들어 새 서비스의 초기 뼈대를 만든다고 하자. 인증 모듈, 사용자 프로필, 결제 웹훅, 관리자 화면, 알림 큐, 테스트 헬퍼가 비교적 독립적으로 나뉜다면 Pumasi가 맞을 수 있다. Claude가 공통 타입과 인터페이스를 잡고 Codex가 각 모듈을 병렬로 구현하면 시간이 줄어든다. 반대로 기존 레거시 코드의 미묘한 버그를 고치는 일이라면 이야기가 다르다. 이때는 전체 맥락과 작은 부작용을 읽는 능력이 더 중요하므로 한 모델이 천천히 추적하는 편이 안전할 수 있다.

5. 도입 전 체크리스트: 설치보다 먼저 운영 기준을 정해야 한다

Pumasi README 기준으로 사용에는 Claude Code CLI, Codex CLI, Node.js 18 이상, Codex 사용을 위한 계정 또는 키가 필요하다. 설치 명령 자체는 어렵지 않다. 그러나 실무에서는 설치보다 운영 기준이 먼저다. AI 코딩 에이전트는 파일을 읽고, 코드를 만들고, 명령을 실행한다. 역할을 나누는 순간 실행 주체가 늘어나므로 보안과 변경 관리가 더 중요해진다.

특히 Codex 여러 인스턴스가 같은 작업 디렉터리에서 병렬로 움직이는 구조라면 파일 충돌, 의존성 설치, 테스트 실행 순서, 임시 파일 정리 같은 운영 문제가 생길 수 있다. Pumasi는 라운드 기반 의존성 처리와 게이트 검증을 강조하지만, 그 게이트를 얼마나 잘 설계하느냐는 결국 사용자 몫이다.

• 작업을 독립 모듈로 나눌 수 있는가. 나눌 수 없다면 병렬화 이득보다 전달 비용이 커진다.
• 자동 확인 기준이 있는가. 타입 검사, 빌드, 테스트, 린트가 없으면 결과 판단이 사람에게 몰린다.
• 비밀값 접근을 제한했는가. 여러 에이전트가 움직일 때는 환경변수, 인증 파일, 배포 키를 더 엄격히 봐야 한다.
• 작업 전후 diff를 사람이 확인하는가. AI가 통과시킨 테스트와 실제 의도는 다를 수 있다.
• 작업 크기가 충분한가. 1~2개 작은 수정이면 Claude 단독 또는 Codex 단독이 더 빠를 수 있다.

6. 비용 관점: “Claude 토큰 절약”만 보면 절반만 본 것이다

영상 제목은 “Claude가 Codex한테 외주 줘서 토큰 아끼는 방법”에 가깝다. 실제로 Pumasi README도 Claude가 코드 본문을 쓰지 않는 구조를 강조한다. 하지만 비용을 토큰 단가만으로 보면 위험하다. AI 개발 비용에는 모델 사용량, 대기 시간, 실패한 작업의 재시도, 사람이 diff를 읽는 시간, 잘못된 코드가 들어갔을 때의 복구 비용이 모두 포함된다.

따라서 Pumasi의 경제성은 “Codex가 더 싸다”가 아니라 “작업을 나눴을 때 전체 왕복 횟수와 사람의 감시 시간이 줄어드는가”로 판단해야 한다. 좋은 게이트가 있으면 Codex 결과를 모두 자세히 읽지 않아도 된다. 반대로 게이트가 약하면 여러 결과를 사람이 일일이 검토해야 하므로 Claude 단독보다 더 피곤해질 수 있다.

7. 실무 결론: AI 코딩은 모델 선택보다 작업 운영 설계가 중요해지고 있다

Claude Code, Codex, Cursor, OpenCode 같은 도구가 경쟁하면서 사용자는 “어느 모델이 더 코딩을 잘하나”에 관심을 갖기 쉽다. 하지만 Pumasi가 보여주는 방향은 조금 다르다. 앞으로의 생산성 차이는 모델 하나의 점수보다, 여러 모델과 도구를 어떤 순서와 권한으로 묶느냐에서 나올 가능성이 크다.

Claude가 전체 설계를 잘 잡고, Codex가 빠르게 구현하고, 자동 게이트가 결과를 걸러내고, 마지막에 사람이 중요한 diff만 보는 구조가 만들어지면 작은 팀도 꽤 큰 기능을 다룰 수 있다. 반대로 역할 분리 없이 “AI에게 다 맡기기”로 접근하면 도구가 늘어날수록 로그와 결과물이 흩어진다.

따라서 Pumasi를 바로 주력 도구로 쓰기보다는 샘플 저장소에서 작은 실험을 먼저 해보는 편이 좋다. 인증·API·화면 세 모듈 정도를 나눠 만들고, 결과 diff, 테스트 통과율, 사람의 수정 시간을 기록해 보면 된다. 그 실험에서 병렬 이득이 분명하면 실무에 넓히고, 아니면 Claude Code 단독이나 공식 Codex 플러그인만으로도 충분하다.