클로드 코드에서 코덱스 부르기: 직접 연결한 경로와 설치 명령

클로드가 정리한 요청을 복사해서 코덱스에 붙이고, 돌아온 결과를 다시 클로드에 옮겼습니다. 여러 앱과 홈페이지 일을 함께 하다 보니 그 전달 과정도 일이 됐습니다. 2026년 9월에는 Claude Code 안에서 Codex를 부르는 연결을 사용하기 시작했습니다.

연결한 뒤에도 작업 범위를 쓰는 일은 남았습니다. 코덱스가 이전 대화를 전부 아는 상태로 시작하는 것은 아니었기 때문입니다. 어느 저장소를 읽을지, 수정해도 되는지, 결과를 어디에 남길지 요청에 넣었습니다.

이 글은 그 연결을 처음 설정할 때 필요한 명령을 입력 장소별로 정리한 기록입니다. 설치 부분은 2026년 10월 13일 OpenAI 공식 플러그인 README와 다시 대조했습니다. 화면 모양이나 사용할 수 있는 명령은 설치 버전에 따라 달라질 수 있습니다.

두 채팅을 합친 것이 아니라 일을 보내는 통로를 붙였다

사용한 구성은 Claude Code, OpenAI의 Codex 플러그인, Codex CLI입니다. CLI는 터미널에서 명령으로 실행하는 도구를 말합니다. 플러그인은 Claude Code에서 그 작업을 쉽게 호출하게 해 줍니다.

두 서비스의 로그인과 이용 한도는 별도로 확인해야 합니다. Claude Code에 로그인했다고 Codex 인증까지 끝나는 것은 아닙니다. 이 구분을 해 두면 ‘연결이 안 된다’는 상황에서도 설치 문제인지 인증 문제인지 나눠 볼 수 있습니다.

Claude Code 입력창에서 플러그인 설치하기

먼저 Claude Code에서 작업할 프로젝트 폴더를 엽니다. 아래 네 줄은 PowerShell에 붙이는 터미널 명령이 아니라 Claude Code 입력창에서 순서대로 실행하는 명령입니다.

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

마지막 setup의 결과에서 준비 상태와 로그인을 확인합니다. 명령을 입력했다는 사실보다 결과에 무엇이 나왔는지가 중요합니다. 공식 안내의 실행 요건에는 Node.js 18.18 이상과 Codex를 사용할 수 있는 계정 또는 API 키가 포함돼 있습니다. API 사용에는 별도 비용이 생길 수 있으므로 이용 방식을 먼저 확인합니다.

마켓플레이스 추가와 설치, setup과 로그인, 읽기 전용 검토로 이어지는 연결 순서
설치된 플러그인의 공식 README와 대조한 연결 순서입니다. (누르면 크게 볼 수 있습니다.)

Codex가 없거나 로그인되지 않았다고 나오면

setup 안내에 따라 진행할 수 있습니다. 직접 설치하려면 별도 터미널에서 다음 명령을 실행합니다. 이번에는 Claude Code의 슬래시 명령이 아니라 PowerShell 같은 터미널에 입력하는 명령입니다.

npm install -g @openai/codex
codex login

로그인이 끝나면 Claude Code로 돌아와 /codex:setup을 다시 실행합니다. 준비됐다는 결과를 확인한 뒤 첫 작업을 보냅니다. 오류 내용을 다른 사람이나 AI에게 보여줄 때는 비밀번호나 토큰을 포함하지 않고, 실행한 명령과 오류 문구를 남깁니다.

첫 연결은 작은 검토로 확인하기

연결을 확인할 때는 범위가 작은 코드 검토부터 시작하기 좋습니다. 공식 플러그인의 review는 읽기 전용 검토이며 코드를 수정하는 요청과 구분됩니다. 검토할 변경이 있는 프로젝트에서 아래처럼 실행합니다.

/codex:review --background
/codex:status
/codex:result

첫 줄은 검토를 백그라운드로 시작하고, 다음 명령으로 진행 상태와 결과를 봅니다. result에 나온 의견을 읽고 실제 코드와 대조합니다. 연결이 됐다는 확인과 검토 내용이 맞다는 확인은 각각 필요합니다.

명령이 보이지 않으면 플러그인 설치·활성 상태를 보고 reload와 setup을 확인합니다. Codex가 없다는 응답이라면 설치 단계로, 인증 실패라면 로그인 단계로 돌아갑니다. 결과가 늦을 때 같은 수정 요청을 여러 번 보내지는 않습니다. 먼저 status에서 진행 중인 작업을 찾습니다.

명령이 없으면 설치 상태, 인증 실패면 로그인 상태, 결과가 늦으면 진행 중인 작업을 확인
연결 문제를 같은 오류로 묶지 않고, 어느 단계에서 멈췄는지 나눠 보는 그림입니다. 그림을 누르면 크게 볼 수 있습니다.

수정을 맡길 때는 요청 안에 기준을 넣었다

코드 조사나 수정을 맡기는 명령은 /codex:rescue입니다. 아래는 소개 화면의 작은 수정을 맡기는 설명용 예제입니다. 실제 경로와 확인 항목으로 바꿔 써야 합니다.

/codex:rescue --wait [프로젝트 경로]의 모바일 소개 화면에서
제목이 잘리는 원인을 확인하고 해당 화면만 수정해 줘.
기준은 [커밋 또는 파일 버전]이야.
다른 화면과 배포 설정은 그대로 두고,
수정한 파일과 확인 결과를 [결과 경로]에 남겨 줘.
확인 못 한 환경은 확인 못 함으로 적어 줘.

새 작업에 필요한 배경까지 요청에 넣습니다. 이전 대화에서 합의한 내용을 상대가 알고 있을 것이라고 가정하지 않는 방식입니다. 결과가 오면 변경 파일과 테스트 결과를 열고, 웹 화면이라면 실제 표시도 확인합니다.

우리 홈페이지는 Git에 파일을 올리는 것만으로 운영 화면이 바뀌지 않는 구간이 있습니다. 그래서 ‘코드 수정’, ‘배포’, ‘공개 화면 확인’을 나눠 적습니다. 연결 도구가 전달을 대신해 줘도 마지막 확인은 생략할 수 없었습니다.

연결 다음에는 담당을 정했다

서로 일을 주고받을 수 있어도 같은 원본을 동시에 고치면 충돌할 수 있습니다. 한쪽이 작성하고 다른 쪽이 검토하도록 범위를 적은 이유입니다. 연결 자체보다 그 뒤의 작업 규칙이 오래 쓰는 데 더 필요했습니다.

이제 설치가 끝났다면 업무 분장 MD 파일에 담당 범위를 남기고, 진행 중인 일을 옮길 때는 인계서 예시를 사용할 수 있습니다.

연습용 업무 분장·인계서·연결 점검표 받기 — MD 파일 9개를 묶었습니다. 빈 연습 폴더에 풀어 쓰는 양식이며, 실제 작업이 완료됐다는 기록은 아닙니다.

댓글 남기기