Claude는 팀장, GPT는 개발자

#GPT Pro Plan, 그냥 썩히기엔 아깝잖아

카카오대란 때 카카오가 GPT Pro Plan을 싼 가격에 풀었다. 나도 그때 하나 질렀다.

그런데 솔직히, 잘 안 썼다. Claude Code가 나온 뒤로는 개발 작업 대부분을 Claude로 하고 있었으니까. 싸게 산 GPT Pro Plan이 그냥 놀고 있는 걸 볼 때마다 아까웠다.

그러다 생각이 바뀌었다. 둘 다 쓰면 안 되나?

#혼자 다 하는 AI는 없다

Claude Code로 작업하다 보면, 하나의 AI가 설계도 하고 구현도 하고 리뷰도 한다. 편하긴 한데, 현실 세계의 개발 팀은 그렇게 돌아가지 않는다. 팀장이 설계하고, 개발자가 구현하고, 시니어가 리뷰한다. 역할이 나뉘어야 견제가 되고, 견제가 돼야 품질이 올라간다.

AI도 마찬가지다. 하나의 모델이 자기가 짠 코드를 자기가 리뷰하면, 자기 실수를 못 잡는다. 다른 모델이 봐야 새로운 시각이 생긴다.

그래서 팀을 짰다.

#Codex CLI, 꽤 쓸만하다

OpenAI의 Codex CLI는 터미널에서 바로 쓸 수 있다. codex라고 치면 된다. 모델은 gpt-5.3-codex-spark를 쓰고 있다.

# 모델 지정해서 호출
codex --model gpt-5.3-codex-spark "UserService에 소프트 딜리트 메서드를 추가해줘. deleted_at 컬럼 사용."

왜 spark냐면, 토큰 생성 속도가 미친 듯이 빠르다. 구현 코드를 뽑아내는 데는 깊은 추론보다 속도가 중요하다. 설계는 이미 Claude가 해놨으니까, Codex는 그 설계대로 빠르게 코드를 찍어내기만 하면 된다. spark 모델이 딱 그 역할이다.

CLI라서 좋은 점이 있다. Claude Code 안에서 Bash로 호출할 수 있다. 즉, Claude가 Codex에게 일을 시킬 수 있다.

#실제 워크플로우

이렇게 쓰고 있다. Claude Code에 전체 작업을 지시하되, 구현은 Codex에게 위임하라고 말한다.

프롬프트:

댓글 신고 기능을 구현해야 해.

1. 먼저 아키텍처를 설계해줘 (서비스 구조, 인터페이스, 데이터 모델)
2. 설계가 끝나면, 각 파일의 구현을 codex CLI로 위임해줘
3. codex가 생성한 코드를 리뷰하고, 문제가 있으면 직접 수정해줘
4. 테스트 코드는 네가 직접 작성해줘

그러면 Claude는 이런 흐름으로 움직인다.

#1단계: 설계 (Claude)

[Claude의 설계 결과]

── ReportService
│   ├── createReport(userId, contentId, type)
│   ├── checkDuplicate(userId, contentId)
│   └── processAutoBlind(contentId)
│
── ContentModerationService
│   ├── blindContent(contentId, reason)
│   └── getReportCount(contentId)
│
── 데이터 모델
│   └── Report { id, userId, contentId, type, createdAt }

#2단계: 구현 위임 (Claude → Codex)

Claude가 Bash를 통해 Codex CLI를 호출한다.

codex --model gpt-5.3-codex-spark "다음 인터페이스에 맞춰 ReportService를 구현해줘.
 
- createReport: 중복 체크 후 신고 생성, 3회 이상이면 자동 블라인드
- checkDuplicate: 동일 유저+동일 콘텐츠 조합 확인
- processAutoBlind: ContentModerationService 호출
 
파일 경로: src/services/report.service.ts
기존 서비스 패턴은 src/services/user.service.ts를 참고해."

spark 모델이라 코드 생성이 체감될 정도로 빠르다. 파일 하나 구현하는 데 몇 초면 끝난다.

#3단계: 코드 리뷰 (Claude)

Claude가 Codex가 생성한 코드를 읽고 리뷰한다.

[Claude의 리뷰]

1. ✅ 중복 체크 로직 정상
2. ⚠️ processAutoBlind에서 트랜잭션 처리 누락
   → 신고 카운트 증가와 블라인드 처리가 원자적이어야 함
3. ⚠️ Report 엔티티에 index 누락
   → (userId, contentId) 복합 인덱스 필요
4. ❌ 에러 타입이 generic Error 사용
   → 커스텀 에러 클래스 사용해야 함

그리고 직접 수정한다. 혹은 수정 사항이 크면 다시 Codex에게 위임한다.

#4단계: 테스트 (Claude)

테스트는 Claude가 직접 짠다. 설계를 본인이 했으니 엣지 케이스를 가장 잘 안다.

#왜 이 조합이 잘 되는가

Claude는 숲을 본다. 전체 아키텍처, 서비스 간 의존성, 정책과 코드의 정합성. 긴 컨텍스트를 유지하면서 큰 그림을 그리는 데 강하다.

Codex는 나무를 깎는다. "이 인터페이스에 맞는 구현체를 만들어"라는 명확한 지시를 받으면 빠르게 코드를 뽑아낸다. CLI라서 자동화하기도 좋다.

이 조합의 핵심은 다른 모델이 견제한다는 점이다.

• Claude가 설계한 것을 Codex가 구현하면 → 설계의 모호한 부분이 드러남
• Codex가 구현한 것을 Claude가 리뷰하면 → 구현의 빈틈이 드러남
• 같은 모델이 셀프 리뷰할 때보다 품질이 올라감

사람 팀에서 코드 리뷰가 중요한 이유와 똑같다.

#실전 팁

#CLAUDE.md에 워크플로우를 정의해라

## AI Team Workflow
 
구현 작업은 codex CLI로 위임할 것.
위임 시 반드시 다음을 포함:
- 구현할 인터페이스/타입 정의
- 참고할 기존 파일 경로
- 프로젝트의 코딩 컨벤션 요약
 
codex가 생성한 코드는 반드시 리뷰 후 커밋할 것.

이렇게 해두면 매번 프롬프트에 쓸 필요 없이 Claude가 알아서 패턴을 따른다.

#작업 단위를 작게 나눠라

Codex에게 "전체 서비스를 구현해"라고 하면 결과가 들쑥날쑥하다. "이 메서드 하나를 구현해"라고 하면 정확도가 올라간다. 팀장이 주니어한테 일 시키는 것과 같다. 작업 단위가 작을수록 결과물이 예측 가능하다.

#테스트는 설계자가 짜라

구현을 위임했더라도 테스트는 Claude가 직접 짜는 게 낫다. 설계 의도를 가장 잘 아는 쪽이 테스트를 짜야 엣지 케이스를 빠뜨리지 않는다.

#GPT Pro Plan, 이제 아깝지 않다

카카오대란 때 싸게 산 GPT Pro Plan, 사놓고 제대로 안 쓰고 있었다. Claude가 메인이 되면서 GPT는 가끔 채팅용으로만 쓰는 신세가 됐다.

그런데 이 워크플로우를 쓰면서 달라졌다. Codex CLI가 꽤 빠르고, Claude와 역할 분담이 깔끔하게 된다. 한 달 구독료가 아깝지 않아졌다.

결국 도구를 하나만 쓸 이유가 없다. 각각 잘하는 게 다르니까. 팀장은 팀장답게, 개발자는 개발자답게. AI도 역할을 나누면 결과물이 달라진다.

#정리

AI를 팀으로 구성하는 게 과하다고 느낄 수 있다. 하지만 실제로 해보면, 혼자 다 하는 것보다 역할을 나눈 게 결과물이 더 좋다. 사람 팀이 그런 것처럼.

참고로, 이 글이 "Claude 무새"처럼 보일 수 있는데 — GPT만으로도 충분히 좋은 워크플로우를 만들 수 있다. 나는 현재 이 조합이 잘 맞아서 쓰는 거지, Claude가 무조건 우월하다는 얘기가 아니다. GPT 메인으로 쓰면서 Claude를 보조로 쓰는 사람도 있고, Gemini나 다른 모델을 섞는 사람도 있다. 중요한 건 역할을 나누는 구조 자체지, 어떤 모델이 어떤 역할을 맡느냐는 각자 취향이다. 취존.

카카오대란 때 싸게 산 GPT Pro, 이제야 제대로 쓰고 있다.