OpenAI가 Claude Code의 플러그인을 만들었다. 경쟁사가 직접. 27,000개가 넘는 별을 받았다. 그리고 이 사실이 우리에게 던지는 질문은 “누가 더 잘하냐”가 아니라, “에이전트들이 서로를 부르기 시작했다”는 거다.

아이러니부터 시작하자

codex-plugin-cc는 Claude Code 안에서 OpenAI Codex를 호출하는 플러그인이다. Claude Code를 쓰는데, 코드 리뷰는 Codex에게 맡기고 싶을 때 쓴다. 또는 “이 버그 좀 봐줘” 하고 Codex에게 태스크를 위임할 때 쓴다. Anthropic의 터미널 안에서 OpenAI의 에이전트가 작동한다.

이게 기술적으로 재미있는 건 당연하다. 하지만 더 중요한 건 메시지에 있다. OpenAI가 “우리 제품만 써라”는 전략을 포기했다. 대신 “어디서든 Codex를 쓸 수 있게 하겠다”는 방향으로 갔다. CLI 플러그인, IDE 확장, GitHub Actions, Slack — Codex는 이미 모든 곳에 있다. 이제 Claude Code도 그중 하나다.

뭘 할 수 있나

플러그인은 7개의 슬래시 커맨드를 제공한다. 각각이 Codex의 다른 능력을 Claude Code 워크플로우에 연결한다:

/codex:review — 현재 브랜치의 변경사항을 Codex에게 코드 리뷰시킨다. 읽기 전용. 멀티파일 리뷰는 시간이 걸리니 –background 플래그를 쓰는 게 낫다. /codex:adversarial-review — 그냥 리뷰가 아니라, “이 설계가 정말 옳은가”를 도전하는 리뷰. 인증, 데이터 손실, 롤백 같은 리스크 영역을 집중적으로 압박한다. /codex:rescue — “이 버그 좀 봐줘”, “이 플래키 테스트 좀 고쳐줘” 하고 Codex에 직접 태스크를 넘긴다. –model gpt-5.4-mini –effort medium 같은 옵션으로 모델 선택도 가능하다. /codex:transfer — Claude Code 세션의 전체 컨텍스트를 Codex로 옮긴다. 디버깅하다가 “아, 이건 Codex한테 맡기는 게 낫겠다” 싶을 때 세션 히스토리를 통째로 가져간다. /codex:status, /codex:result, /codex:cancel — 백그라운드 작업을 관리하는 유틸리티 명령.

그리고 /codex:setup으로 Review Gate라는 재미있는 기능을 켤 수 있다. Claude Code가 답변을 생성한 후, 발행하기 전에 Codex 리뷰가 자동으로 트리거된다. 리뷰에서 문제를 찾으면 Claude가 수정할 때까지 퍼블리시가 블록된다. AI가 AI의 코드를 리뷰하고, 그 리뷰를 또 다른 AI가 수정하는 루프다.

왜 이게 중요하냐면

작년까지만 해도 AI 코딩 도구 시장은 사일로였다. GitHub Copilot은 VS Code에서만, Claude Code는 터미널에서만, Cursor는 자체 IDE에서만. 각자 자기 생태계를 만들고 거기 가둬두려고 했다.

근데 이 패턴이 깨지고 있다. 알지? Google의 agents-cli도 마찬가지고, Agent Skills 오픈 표준도 같은 방향을 가리킨다. 에이전트가 서로를 호출하는 프로토콜이 시장의 승자가 되고 있다. 누가 더 좋은 IDE를 만드느냐가 아니라, 얼마나 많은 도구가 서로 연결될 수 있느냐가 경쟁력이 된 거다.

codex-plugin-cc는 이 흐름의 정점에 있는 사례다. 가장 경쟁적인 관계에 있는 두 회사 — OpenAI와 Anthropic — 의 제품이 하나의 플러그인으로 연결됐다. 경쟁사인데도 “우리도 너희 위에서 돌아갈게”라는 선언이다.

설계: 로컬 Codex CLI를 그대로 쓴다

이 플러그인의 기술적 설계는 단순해서 오히려 좋다. 별도의 Codex 런타임을 띄우지 않는다. 로컬에 설치된 Codex CLI와 Codex app server를 그대로 사용한다. 같은 인증 상태, 같은 설정 파일, 같은 저장소 체크아웃을 공유한다.

즉, Claude Code에서 /codex:review를 실행하면 내 로컬 머신의 codex review 명령이 실행되는 거랑 똑같다. 심지어 Codex의 codex resume 명령으로 같은 세션을 Codex 앱에서 이어받을 수도 있다.

이 설계가 주는 교훈은 간단하다. “로컬 우선이 플러그인 아키텍처의 기본이 되어야 한다.” Codex는 이미 CLI가 있었고, app server가 있었다. OpenAI는 새 API나 새 SDK를 만들 필요 없이, 기존 인터페이스를 Claude Code의 플러그인 시스템에 연결하기만 하면 됐다. 이게 MCP의 정신이기도 하다 — 프로토콜을 맞추면 모든 게 연결된다.

레버리지: 이 플러그인이 해결하는 문제

codex-plugin-cc가 없었다면, Claude Code 유저가 Codex를 쓰려면 이렇게 해야 했다:

터미널을 하나 더 열고 codex review 실행 리뷰 결과를 수동으로 Claude Code에 붙여넣기 세션 컨텍스트를 공유할 방법이 없어서 같은 설명을 두 번 하기 “/codex:rescue” 같은 원스텝 워크플로우는 불가능

이 플러그인 하나가 저 네 가지 문제를 제거한다. 컨텍스트 공유, 명령 통합, 결과 전달, 심지어 Review Gate라는 자동화 루프까지. 이게 레버리지 스코어가 높은 작업이다 — 하나의 설계가 여러 문제를 한 번에 없앤다.

Review Gate: 위험한 만큼 강력한

Review Gate는 플러그인의 숨겨진 진짜 기능이다. Claude Code가 코드를 생성하면, 그 응답이 사용자에게 도착하기 전에 Codex가 리뷰를 실행한다. 리뷰에서 문제를 찾으면 Claude가 그 문제를 해결할 때까지 Stop Hook이 블록된다.

이건 분명 강력하다. 하지만 공식 문서에서도 경고한다: “리뷰 게이트는 오래 실행되는 Claude/Codex 루프를 만들 수 있고, 사용량 제한을 빠르게 소진할 수 있다.” 세션을 적극적으로 모니터링할 수 있을 때만 켜라고 한다.

이 경고가 중요한 이유는, AI-AI 루프의 비용이 아직 예측 불가능하기 때문이다. 내 경험으로도 그렇다 — Drewgent에서 content-manager가 실수로 자기 출력을 다시 입력으로 먹는 루프에 빠졌을 때 토큰 사용량이 3배로 뛰었다. AI-AI 피드백 루프는 설계하기 전에 반드시 타임아웃과 예산 가드레일을 먼저 설치해야 한다.

결국은 연결의 문제

codex-plugin-cc가 27K 스타를 받은 이유는 성능 때문이 아니다. 연결의 가치 때문이다. AI 코딩 도구 시장은 이미 “누가 더 똑똑한 모델을 가졌느냐”에서 “누가 더 많은 도구와 연결될 수 있느냐”로 축이 이동했다.

내가 지난 몇 달간 Drewgent에서 해온 일도 다르지 않다. 14개 에이전트를 6개로 줄인 것도, n8n을 launchd cron으로 바꾼 것도, MCP로 모든 도구를 연결한 것도 결국 같은 방향이다: 덜어내고 연결하라.

OpenAI가 Claude Code를 위해 Codex 플러그인을 만든 건 이 방향의 가장 강력한 신호다. 경쟁사인데도 연결을 선택했다. 더하기보다 연결하기를 선택했다. 그 선택이 27K 스타로 증명됐다.

너도 같은 선택을 하고 있는지 한번 돌아보길.