Claude Code 터미널 안에 Codex가 실행 역할로 붙고, 계획과 실행 리뷰가 나뉘는 그림

Claude Code 한쪽에 계획을 잡고, Codex 한쪽에 리뷰나 수정을 맡기려다 보면 창이 둘로 갈린다.

프롬프트를 복사하고, 같은 파일을 다시 설명하고, “지금 누가 주인이지?”가 흐려진다. 그러다 피드에서 “Claude Code 안에서 Codex를 쓴다”는 말이 보이면 더 헷갈린다. 제품 기능인지, 임시 핵인지, 그냥 두 에이전트를 나란히 켠 건지 한 문장으로 안 들어온다.

이 글은 그 말을 OpenAI가 공개한 Claude Code용 Codex 플러그인(codex-plugin-cc) 기준으로 짧게 잡는다. 읽고 나면 한 터미널에서 계획과 실행·리뷰를 어떻게 나눌지, 언제는 굳이 안 붙여도 되는지 판단할 수 있다. 아래 제품 사실의 확인 기준일은 2026-07-28이다.

한 줄로 보면 이것이다

Claude Code 안에서 Codex를 쓸 때는, 보통 세션을 벗어나지 않고 로컬 Codex에 코드 리뷰를 맡기거나 작업을 위임한다.

기준 문서는 OpenAI 저장소 codex-plugin-cc README다. 플러그인은 별도 Codex 런타임을 새로 만들지 않고, 이미 깔린 Codex CLI와 Codex app server를 그대로 쓴다고 적혀 있다. 같은 인증, 같은 설정, 같은 로컬 환경을 이어 받는다.

Claude Code  = 지금 앉아 있는 작업 표면 (대화, 계획, 진행)
codex-plugin-cc = Claude Code에서 Codex를 부르는 연결
Codex CLI    = 실제로 리뷰·조사·수정 작업을 도는 에이전트

즉 “두 회사가 한 제품으로 합쳐졌다”가 아니라, Claude Code의 플러그인 자리에 Codex를 붙인 것이다. Claude Code 쪽도 플러그인 문서에서 스킬·에이전트·훅을 묶어 마켓플레이스로 나누는 구조를 안내한다. 이 플러그인은 그 확장 경로 위에 올라간다.

왜 탭 전환 이야기가 먼저 나오나

헷갈림의 출발점은 도구 이름보다 작업이 끊기는 지점이다.

  • Claude Code에서 방향을 잡고 파일을 고친 뒤, 다른 창의 Codex에 같은 맥락을 다시 설명한다.
  • 리뷰만 Codex에 맡기고 싶은데, 변경 범위와 기준을 매번 손으로 옮긴다.
  • “한 터미널에 두 에이전트”라는 문장이 멋있어 보여도, 그게 공식 연결인지 화면 녹화 연출인지 구분이 안 된다.

2026-07-26~27 전후 X에도 같은 장면이 반복됐다. 예를 들어 PrakashS720의 글과 HeyAnjula의 글은 탭 전환·복사 없이 Claude 계획과 Codex 실행을 한 터미널에서 나눈다고 소개하고, GitHub README 링크를 붙였다. 이런 글은 신호로는 유용하지만, 문구 그대로 받아들이기보다 공식 README가 허용하는 범위로 읽는 편이 안전하다.

역할 분담 자체는 새 개념이 아니다. 서브에이전트와 병렬 에이전트를 나눌 때도 “누가 계획하고 누가 검증하는가”가 먼저다. 그 구분은 서브에이전트와 병렬 에이전트, 뭐가 다를까에서도 같은 축이다. 이번 글은 그 축을 서로 다른 제품 두 개에 붙였을 때 무엇이 달라지는지만 본다.

무엇을 할 수 있나

README가 강조하는 쓰임은 세 갈래다.

1. 읽기 전용 리뷰

/codex:review는 현재 작업이나 기준 브랜치 대비 변경을 Codex에 맡기는 일반 리뷰다. README는 이 명령을 읽기 전용이라고 명시한다. 코드를 고치지 않는다. 멀티 파일 변경은 시간이 걸릴 수 있어 백그라운드 실행을 권한다.

/codex:adversarial-review는 더 공격적인 리뷰다. 구현 디테일만이 아니라 설계 선택, 가정, 대안을 밀고 당긴다. 배포 직전 “이 방향이 맞나?”를 물을 때 맞다. 이것도 읽기 전용이다.

2. 작업 위임

/codex:rescue는 버그 조사, 작은 수정, 이전 Codex 작업 이어하기처럼 손붙이 작업을 Codex 쪽 서브에이전트에 넘긴다. 자연어로 “Ask Codex to …”처럼 맡겨도 된다고 README에 적혀 있다. 오래 걸릴 수 있어 백그라운드 실행을 권한다.

3. 진행 관리와 세션 이동

백그라운드로 돌린 뒤에는 /codex:status, /codex:result, /codex:cancel로 진행을 본다. /codex:transfer는 Claude Code에서 이어 온 맥락을 Codex 스레드로 옮겨, 나중에 Codex 쪽에서 이어 받게 돕는다.

리뷰만 필요    → /codex:review 또는 /codex:adversarial-review
손붙이 위임    → /codex:rescue
오래 걸리는 일 → --background 후 status / result
Codex로 자리 이동 → /codex:transfer 또는 result에 나온 resume

설치 자체는 Claude Code에서 마켓플레이스를 추가하고 플러그인을 깐 뒤 /codex:setup으로 Codex 준비 상태를 확인하는 흐름이다. README 기준 설치 예시는 다음과 같다.

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

명령 표기나 패키지 이름은 시간이 지나면 바뀔 수 있다. 설치 직전에는 항상 저장소 README를 다시 본다.

공식 연결과 커뮤니티 핵을 구분한다

X 소개 글은 종종 “핵이 아니다”, “첫 멀티 에이전트 워크플로”처럼 크게 말한다. 여기서 남길 사실과 버릴 과장을 나눈다.

남길 사실

  • 저장소 소유자가 openai/codex-plugin-cc인 OpenAI 공개 플러그인이다.
  • OpenAI 개발자 커뮤니티에도 Codex Plugin for Claude Code 소개 글이 있다. 로컬 Codex CLI와 app server로 위임한다고 같은 구조를 설명한다.
  • Claude Code의 플러그인·마켓플레이스 모델 위에 설치하는 형태다. Anthropic이 Claude Code 본체에 Codex를 내장했다는 뜻은 아니다.

버릴 과장

  • “항상 두 모델을 같이 써야 생산성이 폭발한다”는 단정. 플러그인은 필요할 때 Codex를 부르는 선택지다.
  • “API 키가 전혀 필요 없다”를 절대 규칙처럼 말하기. README는 ChatGPT 구독(Free 포함) 또는 OpenAI API 키를 요구하고, 사용량은 Codex 사용 한도에 합산된다고 적는다.
  • “한 터미널이면 권한 문제가 사라진다”는 기대. 실제 실행은 로컬 Codex와 같은 권한·설정을 물려받는다. 경계는 그대로다.

반대 방향 연결도 있다. 커뮤니티에는 Codex 쪽에서 Claude Code를 부르는 플러그인 논의가 따로 있다. 이름만 비슷해도 호스트가 누구인지가 다르다. 이 글의 기준은 Claude Code가 호스트이고 Codex가 손님인 쪽이다.

실패 조건도 공식 문서 안에 이미 있다. README는 선택적 review gate를 켜면 Claude 응답 뒤에 Codex 리뷰를 돌리고, 이슈가 있으면 종료를 막을 수 있다고 설명한다. 동시에 긴 Claude/Codex 루프가 생겨 사용 한도를 빨리 소모할 수 있으니, 지켜볼 준비가 있을 때만 쓰라고 경고한다. 저장소 이슈에는 포그라운드 작업이 시간 제한에 걸리거나, 백그라운드 작업 상태가 어긋나는 보고도 있다. “설치만 하면 항상 매끄럽다”로 읽으면 안 된다.

코딩 하네스가 끈적하다는 이야기도 같은 맥락이다. Hamel Husain의 글처럼, 모델만 바꿔 끼우면 될 것 같아도 닫힌 작업대·도구 호출 습관이 남는다. 플러그인도 그 습관을 지우지 않는다. 이미 쓰는 Claude Code 표면 위에 Codex 작업만 얹는다. 하네스 경계를 더 보려면 하네스 엔지니어링은 자동화보다 경계를 먼저 만든다를 이어서 읽으면 된다.

언제 붙이고, 언제 안 붙여도 되나

내 기준으로 보면 판단은 단순하다.

붙여 볼 만할 때

  • 이미 Claude Code에 손이 가 있고, 커밋 전 다른 에이전트 리뷰만 필요할 때.
  • 긴 조사나 수정을 백그라운드로 넘기고, 지금 창에서는 계획·확인을 이어갈 때.
  • 설계 선택에 일부러 반론이 필요할 때. adversarial review가 여기 맞다.
  • 로컬 Codex 로그인과 설정이 이미 있어 새 런타임을 따로 키울 필요가 없을 때.

안 붙여도 될 때

  • 한 에이전트로 끝까지 보고, diff와 테스트만 직접 확인하면 충분한 작은 작업이다.
  • Codex 인증·사용 한도·Node 환경을 아직 맞추기 싫다. 플러그인은 그 준비 위에서 돈다.
  • “두 회사 에이전트를 동시에 켜야 프로 같다”는 분위기만 보고 붙이려 한다. 역할이 없으면 비용만 늘다.
  • 리뷰 gate를 상시 자동으로 켜 두고 싶다. README 경고대로 루프와 한도 소모 위험이 있다.

계획과 실행을 나누는 습관 자체는 플러그인 없이도 가능하다. Codex 쪽에서 코드 쓰기 전 멈추는 습관은 Codex Plan Mode는 코드 쓰기 전 멈추는 습관이다에 가깝고, 목표를 붙이고 반복하는 방식 비교는 Codex /goal과 Claude Ralph Loop는 어디가 다를까에 정리돼 있다. 플러그인은 그 습관을 Claude Code 화면 밖으로 나가지 않고 실행하는 연결일 뿐이다.

독자가 가져갈 기준

한 문장으로 줄이면 이렇다.

Claude Code 안에서 Codex를 쓴다는 말은, 보통 OpenAI의 codex-plugin-cc로 로컬 Codex에 리뷰·위임·백그라운드 작업을 넘긴다는 뜻이다. 한 터미널은 편리함이지만, 역할·권한·사용량 경계는 사라지지 않는다.

다음에 피드에서 같은 말을 보면 세 가지만 확인하면 된다.

  1. 호스트가 Claude Code인가, 반대 방향 연결인가.
  2. 지금 필요한 게 읽기 전용 리뷰인가, 손붙이 위임인가.
  3. 로컬 Codex 인증과 사용 한도를 감수할 만큼, 두 번째 관점이 필요한 작업인가.

필요하면 붙이고, 없으면 하나만 깊게 쓰면 된다. 연결은 수단이고, 기준은 여전히 “누가 무엇을 검증하는가”다.

참고 자료