JKH

Essay · 7분

AI 코딩 도구 6개월 — Claude Code, Codex, Cursor 세 도구를 같이 쓴 후

6개월 전에는 Cursor만 썼다. 지금은 Claude Code + Codex CLI + Cursor 세 도구를 같이 쓴다. 각 도구의 자리가 어떻게 다른지, 도구 셋이 만드는 새로운 워크플로우는 무엇인지의 관찰.

6개월 전 vs 지금

6개월 전 IDE는 Cursor였다. AI 도구는 Cursor 안에서 chat 또는 inline edit으로 끝났다. 단일 도구, 단일 자리.

지금은 다르다. 세 도구를 같이 쓴다.

  • Claude Code (CLI + IDE 확장) — 메인 작업 환경
  • Codex CLI — 병렬 검증·경쟁
  • Cursor — 가벼운 chat·시안 탐색

세 도구가 같은 문제를 푸는 게 아니라 다른 자리를 차지한다. 6개월 전엔 안 보였던 그림이 이제 보인다.

Claude Code — 작업의 메인 자리

Claude Code가 메인이 된 이유는 명확하다.

  • CLI: terminal에서 직접 호출. 단축키 + 자동화 가능
  • 스킬 시스템: 본인이 만든 워크플로우(dispatch·quality-gate·personas)를 도구 안에 박을 수 있음
  • 메모리/세션: 컨텍스트가 turn 단위가 아닌 세션 단위
  • multi-edit: 한 번에 여러 파일 수정 (Cursor의 inline edit보다 큰 단위)
  • 에이전트 스폰: 서브에이전트로 병렬 작업 가능

"매번 chat에 컨텍스트 적기"가 사라졌다. CLAUDE.md에 원칙을 박고, memory에 자산을 누적하고, 스킬에 워크플로우를 박는다. 한 번 만든 게 다음 호출에 그대로 적용된다.

가장 큰 변화는 본인 도구를 만들 수 있다는 것. Cursor에서는 도구의 동작을 바꾸기 어려웠다. Claude Code에서는 dispatch 같은 라우터를 직접 짜고 모든 메시지가 그 라우터를 거치게 만들 수 있다.

Codex CLI — 검증과 경쟁의 자리

Codex는 메인이 아니라 두 번째 의견의 자리다.

  • Claude가 만든 코드를 Codex가 리뷰
  • Claude가 분석한 결과를 Codex가 교차 검증
  • 같은 작업을 둘 다 굴려서 두 결과 비교

가장 큰 가치는 사각지대 발견. 같은 모델이 만들고 같은 모델이 리뷰하면 같은 사각지대를 공유한다. 다른 모델 백엔드(GPT 계열)인 Codex는 다른 사각지대를 가진다. 한쪽만 발견한 엣지 케이스가 거의 항상 진짜다. 이 Codex 경쟁 패턴은 본인 워크플로우의 기본값이 됐다.

비용은 토큰 2배. 시간도 직렬이면 2배(병렬이면 max). 이 비용이 가치를 넘는가? 설계 결정·복잡한 리팩토링·보안 리뷰에서는 명확히 가치 > 비용. 단순 한 줄 수정에서는 가치 < 비용.

CLAUDE.md에 "모든 작업에서 Codex 경쟁 기본"이라고 박아뒀다. 단독 진행은 사용자가 "코덱스 없이"라고 명시한 경우만. 강제 기본값이 그게 더 안전해서다.

Cursor — 가벼운 chat의 자리

Cursor를 안 버린 이유는 하나다. 가볍게 물어볼 자리가 필요해서.

  • "이거 어떻게 동작하지?" 같은 단문 질문
  • 코드 한 조각의 의미 파악
  • 잠깐 시안 탐색 ("이거 React 19에서 어떻게 쓰지?")

Claude Code는 메인 작업 환경이라 묵직하다. Cursor는 IDE 안에 박혀있어서 inline으로 빠르게 물어볼 수 있다. 두 도구의 자리가 다르다.

다만 Cursor의 비중이 6개월 전 100%에서 지금 15-20% 정도로 줄었다. 진짜 작업은 Claude Code, 가볍게는 Cursor.

셋이 만드는 새로운 워크플로우

이 세 도구가 각자 도는 게 아니라 체인을 이룬다. 며칠 써본 패턴은 이렇다.

[가벼운 탐색] Cursor — "이 API 뭐지?"
    ↓
[설계 결정] Claude Code + personas — 트레이드오프 비교
    ↓
[구현] Claude Code + ship — 코드 작성
    ↓
[검증] Codex CLI — 같은 작업 다시 굴려서 비교
    ↓
[리뷰] Claude Code + review-changes — 6관점 병렬 리뷰
    ↓
[PR] Claude Code + create-pr — PR 생성
    ↓
[CI 대응] Claude Code + pr-shepherd — 머지까지

각 단계가 적합한 도구를 골랐다. 단일 도구에 모든 단계를 떠넘기지 않는다.

토큰 사용량

도구 셋을 같이 쓰니 토큰 사용량이 6개월 전 대비 4-5배다. Claude Pro 외에 Codex 별도 결제도 있다. 그런데 결과 품질의 차이가 토큰 비용을 뛰어넘는다.

비용 정당성:

  • 사각지대 감소 → 프로덕션 버그 비용 회피 (1개 버그가 며칠 비용)
  • 의사결정 품질 → 재설계 비용 회피
  • 매번 처음부터 안 함 → 시간 비용 회피

토큰을 아끼는 게 미덕이 아니다. 결과 품질이 토큰 비용을 회수하면 토큰을 더 쓰는 게 합리적이다.

6개월 후 무엇이 달라질까

추측해본다.

  • 도구 통합: 셋이 점점 통합될 가능성. Cursor가 CLI를 강화하거나, Claude Code가 IDE 통합을 강화하거나, Codex가 자체 워크플로우를 갖거나.
  • 에이전트 자율성 증가: 지금은 사람이 도구를 호출하는데, 곧 도구가 도구를 호출하는 비중이 늘어난다 (이미 dispatch가 그렇다).
  • 본인 시스템 가치 ↑: 도구가 통합되든 자율성이 늘어나든 본인이 자기 워크플로우를 시스템으로 만들었는지가 격차의 핵심이 된다. 도구 좋아진다고 시스템 없는 사람이 따라잡지 못한다.

가장 큰 위험은 도구에 종속되는 것이다. 본인 시스템이 도구별 lock-in이면 도구 교체 비용이 커진다. dispatch·quality-gate 같은 패턴은 도구가 바뀌어도 옮길 수 있게 추상화해야 한다.

함정

  • 도구를 늘리기만 함: 도구 셋이 자리가 다른지 확인 안 하고 그냥 셋 다 쓰면 노이즈. 각 도구의 자리를 명확히.
  • 모든 작업에 모든 도구: 단순 한 줄 수정에 도구 셋을 다 굴리면 시간 낭비. 작업 크기 대비 도구 수를 조절.
  • 본인 시스템 없이 도구만: 도구가 좋아져도 본인 워크플로우 시스템이 없으면 매번 처음부터. CLAUDE.md·memory·skill에 시스템 박기.
  • 도구 lock-in: 본인 시스템을 도구 specific하게 만들면 도구 교체 비용 ↑. 추상화 가능한 패턴으로.
  • 검증의 자기 confirmation: Claude만 쓰면 Claude의 사각지대를 공유. 같은 모델에 반복 위임하면 출력이 한 점으로 수렴하기도 한다. 다른 모델로 교차 검증 필수.

결론

AI 코딩 도구의 가치는 단일 도구 잘 쓰는 게 아니다. 각 도구의 자리를 알고 셋을 체인으로 엮는 것이다.

Claude Code가 메인, Codex가 검증, Cursor가 가벼운 chat. 이 셋이 따로 도는 게 아니라 dispatch → personas → ship → review-changes → create-pr → pr-shepherd 같은 워크플로우로 엮인다.

6개월 전 단일 도구 100%에서 지금 셋이 자리가 다른 시스템으로 바뀌었다. 6개월 후엔 다섯 도구가 될 수도 있다. 도구 수가 늘어나도 본인 시스템의 형태가 같으면 자연스럽게 흡수할 수 있다.

도구는 매년 바뀐다. 본인 워크플로우를 시스템으로 만들어둔 사람과 매번 새 도구 하나씩 다시 배우는 사람의 6개월 후, 1년 후, 5년 후 격차는 비선형이다.