Claude Code에서 Codex를 함께 쓰기: 플러그인 비교와 세 가지 활용법

Claude Code로 작업하다 보면 다른 에이전트의 도움이 필요한 순간이 있다. 블로그 커버 이미지를 만들고 싶을 때, 방금 작성한 코드의 빈틈을 다른 관점에서 확인하고 싶을 때, 두 결과물 중 어느 쪽을 채택할지 고민할 때다. Codex를 별도로 열어 작업할 수도 있지만, Claude Code가 필요한 일을 전달하고 결과를 받아오는 흐름으로 묶을 수도 있다.

출발점은 “Claude Code에서 Codex를 쓰는 스킬이 있을까?”라는 질문이었다. 공식 플러그인을 포함해 일곱 개 후보를 조사하고 나니, 먼저 구분해야 할 것은 플러그인의 개수보다 Codex를 호출하는 경로와 결과를 검증하는 방식이었다.

이 글은 두 부분으로 나눈다. 먼저 공식 플러그인과 직접 CLI 호출을 비교한다. 이어 이미지 생성, 적대적 검증, A/B 평가에 어떻게 적용할지 살펴본다. 이미지 생성은 저장된 실행 로그와 PNG까지 확인했고, 나머지 두 활용법은 아직 실행하지 않은 설계안이다.

무엇을 실제로 확인했나

기초 조사는 2026년 9월 6일 Windows 10 환경에서 진행됐다. 보고서에 기록된 버전은 Claude Code 2.1.263과 Codex CLI 0.153.4다. 글을 정리하면서 9월 7일 기준 공식 문서와 플러그인 소스를 다시 대조했다. 아래 구분이 이 글을 읽는 기준이다.

공식 플러그인은 설치하지 않았다. 원자료의 ready: true는 실행에 필요한 환경과 인증을 점검한 결과이며, 플러그인의 모든 기능이 이 PC에서 정상 동작했다는 뜻으로 읽으면 안 된다.

공식 플러그인은 무엇을 연결하나

OpenAI는 Claude Code용으로 openai/codex-plugin-cc를 제공한다. 조사한 플러그인은 v1.0.6이며, 확인한 코드의 커밋은 db52e28이다.

호출 흐름은 다음과 같다.

Claude Code의 /codex:* 명령
  → 플러그인의 Node 스크립트
  → 로컬 codex app-server
  → Codex 작업·리뷰
  → Claude Code로 결과 반환

플러그인 내부에서는 codex app-server 프로세스를 실행해 JSON-RPC 기반으로 요청을 주고받는다. Claude 모델 안에 Codex 모델을 추가하는 설정이라기보다, Claude Code가 별도의 Codex 작업을 호출하는 연결 계층에 가깝다. 실행 코드

주요 명령은 역할에 따라 나뉜다.

리뷰와 수정 위임은 권한이 다르다. 특히 rescue는 파일 수정이 가능한 작업으로 이어질 수 있으므로, 읽기 전용 리뷰와 같은 동작으로 생각하면 안 된다. 리뷰 결과를 받았다는 사실과 수정 내용을 검증했다는 사실도 구분해야 한다.

설치 절차와 Windows에서 확인할 점

공식 README가 안내하는 Claude Code 안의 설치 절차는 다음과 같다. 아래는 공식 설치 방법을 옮긴 것이며, 이번 조사에서 설치를 완료했다는 기록은 아니다.

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

Node와 Codex CLI가 준비되어 있어야 하고, Codex가 사용할 인증도 필요하다. 세부 요구조건과 명령은 설치 시점의 공식 설치 안내를 확인하는 편이 좋다.

Windows에서는 설치 가능 여부 외에 종료·취소·백그라운드 프로세스 동작도 확인할 필요가 있다. 예를 들어 이슈 #530은 특정 Windows 11 환경에서 리뷰 게이트를 꺼도 Stop 훅이 오래 대기했다고 보고한다. 이슈 #525는 Git Bash의 경로 변환 때문에 프로세스 강제 종료가 실패한 사례다. 후자의 신고에는 부드러운 중단 요청이 가능한 조건도 설명되어 있어 “취소가 전혀 작동하지 않는다”고 요약하면 범위를 벗어난다.

이들은 다른 사용자가 올린 신고이며, 이번 PC에서 직접 재현한 결과는 아니다. 확인 시점에 관련 이슈가 열려 있다는 것은 도입 전에 점검할 이유가 되지만, 모든 Windows 환경에서 같은 문제가 생긴다는 근거는 아니다.

2026년 9월 7일 확인 시점에 기본 브랜치의 마지막 커밋은 7월 8일이었다. 커밋 간격만으로 유지보수 중단을 단정할 수는 없다. 도입할 때는 필요한 기능의 이슈와 변경 기록을 함께 살펴봐야 한다.

직접 CLI 호출과는 무엇이 다른가

플러그인을 통하지 않고 Claude Code의 도구나 프로젝트 스킬에서 codex exec를 실행하는 방법도 있다. 반복할 명령, 입력 프롬프트, 결과 저장 위치를 직접 정하는 방식이다.

공식 플러그인이 제공하는 편의 기능이 필요한지, 직접 관리할 부분을 감수하고 입력과 출력을 단순하게 만들 것인지가 선택 기준이다. 직접 호출은 이 플러그인의 훅과 브로커를 거치지 않지만, Codex CLI 자체의 호환성 문제까지 없어지는 것은 아니다.

조사한 커뮤니티 대안도 실행 경로를 읽어야 구분된다. 예를 들어 codex-in-claude는 자체 MCP 서버에서 codex exec를 감싼다. 반면 claude-codex는 Codex 내장 mcp-server를 등록하는 경로를 사용한다. 둘 다 설명에 MCP가 등장하지만 같은 구현은 아니다.

현재 공식 문서가 deprecated로 표시한 것은 codex mcp-server 명령이다. 이를 근거로 MCP를 사용하는 모든 커뮤니티 래퍼가 폐기됐다고 해석해서는 안 된다. 공식 문서는 대안으로 app-server와 Claude Code용 공식 플러그인을 안내한다. MCP 서버 문서

직접 호출의 기본 모양

아래는 Git Bash에서 저장소 안의 변경을 읽고 결과를 파일로 받는 구성 예시다. 이미지 생성 프로브에 사용한 명령을 그대로 복제한 것은 아니다.

mkdir -p review-output
codex exec --sandbox read-only --json \
 --output-last-message review-output/result.md \
 "변경 사항을 읽고 실패 가능성이 있는 지점을 근거와 함께 정리해줘. 파일은 수정하지 마." \
 > review-output/events.jsonl

여기서 --json은 실행 중 이벤트를 JSONL로 남기는 옵션이고, --output-last-message는 마지막 응답을 별도 파일로 저장하는 옵션이다. 자동 처리가 필요하다면 --output-schema로 최종 응답의 구조를 지정할 수 있다. 종료 코드, 실패 이벤트, 결과 파일 유무를 함께 확인해야 한다. JSON 형태가 맞는 것만으로 내용의 정확성까지 보장되지는 않는다. 비대화형 실행 문서

활용 1: 이미지 생성은 로그와 파일까지 확인했다

실제로 실행한 작업은 Claude Code 쪽에서 Codex CLI를 호출해 블로그 커버용 이미지를 만드는 것이었다. 프롬프트는 Codex의 내장 이미지 생성 도구를 사용하고, 결과를 sample-a.png로 저장하도록 요청했다. 측정 대상은 last30days 주제의 커버 구상이었다.

확인된 경로는 codex exec에서 내장 image_gen을 호출한 방식이다. 별도의 Images API 키를 발급받아 API 스크립트를 실행한 실험은 아니다. 다만 내장 도구의 제공 여부는 사용 환경과 계정에 따라 확인해야 한다. Codex 이미지 생성 안내

77초는 이미지 모델만의 추론 시간이 아니다. 작업 시작, 컨텍스트 읽기, 이미지 생성, 파일 확인과 복사 등이 포함된 전체 실행 시간이다. 도구가 보고한 38.4초와 같은 지표로 비교하면 안 된다. 또한 한 번 성공했다는 사실로 평균 속도나 반복 안정성을 말할 수는 없다.

이벤트의 최종 사용량에는 입력 110,853토큰, 그중 캐시 입력 90,496토큰, 출력 693토큰이 기록됐다. 이 값은 해당 에이전트 실행의 기록이며, 이미지 한 장의 토큰 비용이나 금액으로 환산한 수치가 아니다. 이미지 생성 도구 호출과 에이전트의 컨텍스트 처리를 함께 고려해야 한다.

실용적인 교훈은 “그림이 나왔다” 이후에도 할 일이 있다는 것이다. 샘플에서는 글자를 넣지 말라는 요청에도 달력 테두리에 숫자처럼 보이는 흔적이 남았다. 파일 생성 성공과 시각적 요구 충족은 별도로 확인해야 한다. 이번 실행의 결과 경로를 확인하고, 파일이 실제로 존재하는지, 크기와 비율이 맞는지, 화면에서 내용이 적절한지 검토해야 한다. 여러 세션이 동시에 실행될 수 있으므로 무조건 가장 최근에 생긴 이미지 파일을 집어오는 방식도 피하는 편이 좋다.

활용 2: 적대적 검증은 반박 가능한 결과를 받도록 설계한다

적대적 검증은 무조건 결함을 많이 찾으라는 요청이 아니다. 구현자가 놓치기 쉬운 가정과 실패 조건을 다른 관점에서 검토하고, 지적을 코드나 테스트로 확인할 수 있게 만드는 과정이다.

이 활용법은 스킬 초안까지 작성됐지만 실제 검증 루프를 실행하지 않았다. 원본 초안에는 수정 후 이 PC에서 재확인해야 할 CLI 옵션 두 곳도 남아 있다. 따라서 초안 파일을 완성된 도구처럼 설치하거나, “이 방법으로 버그를 잡았다”고 소개할 단계는 아니다.

설계의 핵심은 역할을 나누는 것이다.

Claude Code: 요구사항과 변경 범위 정리
  → Codex: 읽기 전용으로 실패 조건·근거 검토
  → Claude Code: 지적을 코드·테스트로 재확인
  → 확인된 지적 수정
  → 테스트와 필요한 재검토

검토자에게는 변경 기준점, 대상 파일, 반드시 유지해야 하는 동작을 준다. 작성자가 “잘 구현했다”고 설명한 결론에만 의존하지 않고, 실제 변경과 요구사항을 읽게 하는 것이 중요하다.

결과에는 최소한 다음 정보가 있으면 좋다.

• 무엇이 잘못될 수 있는가
• 어떤 입력이나 실행 순서에서 발생하는가
• 어느 파일·함수·코드가 근거인가
• 재현이나 반증에 사용할 검증 방법은 무엇인가
• 확인하지 못한 부분은 무엇인가

예를 들어 “예외 처리가 부족하다”보다 “저장 요청이 실패했는데 완료 상태로 바뀌는 분기가 있으며, 실패 응답을 주는 테스트로 확인할 수 있다”가 후속 작업에 도움이 된다.

운영 시에는 내용 판정과 실행 상태도 따로 기록해야 한다. 정상적으로 검토한 뒤 문제를 찾지 못한 결과와, 타임아웃 때문에 결과가 없는 상황을 같은 승인으로 처리하면 안 된다. 실패한 실행은 실패로 남기고, 반복 횟수에 상한을 두며, 실제 수정은 테스트 결과까지 확인한 뒤 채택하는 방식으로 설계했다.

공식 플러그인의 /codex:adversarial-review를 사용할 수도 있고, 직접 codex exec --output-schema로 원하는 결과 형식을 만들 수도 있다. 앞의 기능과 여기서 검토한 자체 스킬 초안은 별도의 구현이다.

활용 3: A/B 평가는 먼저 무엇을 비교할지 정한다

보고서를 정리하면서 “A/B 테스트”라는 말에 서로 다른 일이 섞여 있다는 점도 드러났다.

첫 번째는 LLM을 평가자로 쓰는 방식이다. 블로그 커버 두 장이라면 “주제를 전달하는가”, “작은 화면에서도 읽히는가”, “제목이 겹칠 여백이 있는가”처럼 기준을 먼저 정할 수 있다. 작성자나 생성 모델 이름을 가리고, A/B를 바꿔 다시 제시해 위치에 따라 판단이 달라지는지도 확인한다. 판단이 엇갈리면 억지로 승자를 정하지 않고 사람의 검토 대상으로 남긴다.

모델은 답변 순서나 길이의 영향을 받을 수 있다. 그래서 점수 하나만 받기보다 명확한 기준을 둔 쌍대 비교를 하고, 사람의 판단과 얼마나 일치하는지 확인하는 절차가 필요하다. OpenAI 평가 모범 사례

두 번째는 구현 실험이다. 같은 저장소에서 두 에이전트를 동시에 작업시키면 변경이 섞일 수 있으므로, 동일한 기준 커밋에서 분리한 작업 공간을 사용하는 구상이다. 정답 판정에는 설명의 설득력뿐 아니라 동일한 테스트·빌드·요구사항 검증을 사용해야 한다. 조건이 다르면 모델 차이와 작업 환경 차이를 구분하기 어렵다.

세 번째인 방문자 실험은 별도 계측이 필요한 작업이다. 모델이 커버 B를 선호했다는 결과는 독자가 B를 더 많이 클릭했다는 증거가 아니다. 실제 트래픽에 배정하고 행동을 측정하기 전에는 클릭률·전환율 향상을 주장할 수 없다. 이번 조사에서는 세 종류 모두 설계만 검토했다.

비용과 권한도 작업마다 나눈다

플러그인을 쓴다고 Codex 사용이 무료가 되는 것은 아니다. 로컬 Codex의 인증을 사용하며, ChatGPT 로그인은 해당 플랜의 Codex 사용량을, API 키 로그인은 별도의 OpenAI Platform API 과금을 따른다. 이번 이미지 프로브는 보고서에 기록된 ChatGPT 로그인 환경의 실행이다. Codex 인증, 요금·사용량 안내

Claude Code가 작업을 준비하고 결과를 읽는 과정에도 Claude 쪽 사용량이 든다. 따라서 비교할 것은 결과물의 품질뿐 아니라 호출 횟수, 컨텍스트 크기, 대기 시간, 사람이 검증하는 시간까지 포함한 전체 작업이다.

권한은 역할에 맞춰 정한다. 코드 검토는 읽기 전용으로 시작하고, 파일을 만들어야 하는 작업에는 필요한 범위의 쓰기 권한을 부여한다. 읽기 전용은 Codex가 실행하는 도구의 파일 쓰기 권한을 제한하는 설정이며, 자료가 외부 모델에 전달되지 않는다는 의미는 아니다. 어떤 파일과 컨텍스트가 전달되는지는 별도로 확인해야 한다.

이 블로그에 적용한다면

현재 단계에서 정리한 운영안은 명확하다. 이미지 생성은 검증된 한 번의 경로를 출발점으로 결과 파일·크기·내용을 매번 확인한다. 코드 검증은 읽기 전용으로 범위를 좁히고, 근거를 테스트로 확인할 수 있는 결과를 받는다. 두 결과물의 선택은 평가 기준을 먼저 만들고 사람의 최종 판단을 남긴다.

공식 플러그인은 제공된 리뷰와 작업 관리 명령을 활용하려는 경우에 후보가 된다. 직접 CLI 호출은 이 블로그처럼 입력과 결과 파일을 정해 좁은 작업부터 구성하려는 경우에 검토할 만하다. 어느 경로든 작성·검토·채택의 책임을 구분하고, 실행 결과를 남기는 것이 두 에이전트를 함께 쓰는 출발점이다.

이 글은 2026년 9월 6일의 조사 자료와 이미지 생성 프로브를 바탕으로 작성하고, 9월 7일 공식 문서·플러그인 소스와 대조했다. 이미지 생성 실측은 1회이며, 공식 플러그인 설치·실제 리뷰·A/B 실험의 완료를 주장하지 않는다. 원본 로그에 포함된 로컬 환경 정보는 공개 본문에서 제외하고 필요한 측정값만 정리했다.