아래 문장을 Claude Code 채팅창에 붙여넣어 Codex 설치와 로그인 상태만 확인합니다. 이 단계에서는 파일을 고치거나 이미지를 만들지 않습니다.
이 컴퓨터에서 Codex CLI를 Claude Code의 두 번째 실행 도구로 쓰고 싶어. `codex --version`과 `codex login status`로 설치와 ChatGPT 로그인 상태를 확인해 줘. 설치되지 않았다면 OpenAI 공식 Codex 설치 문서를 먼저 확인한 뒤 설치해 줘. 로그인이 필요하면 `codex login`을 실행하고 브라우저 로그인 단계에서 멈춰 줘. 설치와 로그인 확인만 하고 프로젝트 파일은 고치지 마.
확인Codex 버전과 로그인 상태가 나오고, 설치나 로그인이 필요하면 다음 한 단계가 안내됩니다. 프로젝트 파일은 바뀌지 않습니다.
프로젝트 폴더에 규칙 파일이 하나만 있게 정리합니다. Codex는 AGENTS.md를 읽고 Claude Code는 CLAUDE.md를 읽으므로, 규칙 본문은 AGENTS.md에 두고 CLAUDE.md에서는 그 파일을 불러옵니다.
이 프로젝트에 AGENTS.md와 CLAUDE.md가 각각 있는지 확인해 줘. 규칙 본문은 AGENTS.md 한 곳에만 두고, CLAUDE.md에서는 @AGENTS.md 로 그 내용을 불러오도록 정리해 줘. 지금 두 파일에 내용이 겹쳐 있으면 어느 쪽을 남길지 먼저 물어봐 줘.
확인두 파일의 현재 상태가 정리돼 나오고, 규칙 본문이 AGENTS.md 한 곳으로 모이며 CLAUDE.md는 그것을 불러오는 형태로 바뀝니다. 내용이 겹치면 먼저 확인 질문이 나옵니다.
두 도구가 같은 규칙을 실제로 읽는지 확인합니다. Claude Code와 Codex 양쪽에 같은 질문을 보내 답이 맞는지 확인합니다.
이 프로젝트의 규칙 파일에 적힌 내용 중, 네가 코드를 고칠 때 반드시 지켜야 하는 항목 세 가지를 그대로 인용해서 알려 줘.
확인규칙 파일에 실제로 적힌 문장 세 개가 인용됩니다. 두 도구에 같은 질문을 보냈을 때 같은 항목이 나오면 규칙이 공유된 것입니다.
판단은 Claude Code에 두고 실행을 Codex에 넘깁니다. 무엇을 어떻게 고칠지 계획을 먼저 세운 다음, 손이 많이 가는 부분만 넘깁니다.
지금 하려는 작업의 계획을 먼저 세워 줘. 그다음 그 계획을 다른 도구에게 그대로 전달할 수 있는 지시문 하나로 정리해 줘. 지시문에는 바꿀 파일 범위, 지켜야 할 규칙, 완료 조건을 넣어 줘. 지시문만 만들고 파일은 아직 고치지 마.
확인작업 계획과 함께, 파일 범위·규칙·완료 조건이 들어간 위임 지시문 한 덩어리가 나옵니다. 이 시점에는 파일이 바뀌지 않습니다.
정리한 지시문을 Codex에 넘겨 실행합니다. 대화창을 열지 않고 명령 한 줄로 맡기는 방식입니다.
명령어로 직접 하기
Claude Code가 프로젝트 폴더 안에서 이 명령을 실행할 수 있습니다. codex exec는 기본이 읽기 전용이라 파일을 고치게 하려면 --sandbox workspace-write를 붙입니다. 마지막의 `< /dev/null`은 입력 대기를 끝내 실행이 멈춰 있는 일을 막습니다.
Codex가 바꾼 내용을 Claude Code로 돌아와 검수합니다. 넘길 때 정한 완료 조건에 맞는지 확인합니다.
방금 다른 도구가 이 폴더의 파일을 고쳤어. 무엇이 바뀌었는지 diff로 확인하고, 내가 처음에 정한 완료 조건에 맞는지 항목별로 통과·미달로 판정해 줘. 미달이면 어디를 어떻게 고쳐야 하는지도 알려 줘.
확인바뀐 파일의 diff 요약과 함께, 완료 조건 항목마다 통과·미달 판정이 나옵니다.
이 단계의 실제 화면
화면에서 확인할 것실행을 넘긴 뒤 Claude Code에서 변경 내용과 완료 조건을 다시 확인합니다. Codex CLI · 2026-07-27
중요한 변경은 반대쪽에도 검토를 요청합니다. Codex의 리뷰 기능은 작업 트리를 건드리지 않고 지적만 합니다.
명령어로 직접 하기
일반 터미널에서 프로젝트 폴더 안으로 이동해 실행하면 대화창이 열립니다. 그곳에서 /review를 입력합니다. 어느 범위를 볼지 고르는 목록에서 커밋하지 않은 변경, 특정 커밋, 기준 브랜치 대비 가운데 하나를 고릅니다. 검토 결과만 나오고 파일은 바뀌지 않습니다.
codex
직접 해보기
대괄호 안은 실제 값으로 바꿔서 붙여넣습니다.
내 상황에 맞춰
지금 내가 하는 일은 [여기에 한 줄로 설명]이야. 이 일에서 내가 직접 판단해야 하는 부분과 다른 도구에 넘겨도 되는 부분을 나눠 주고, 넘길 부분에 대한 위임 지시문을 파일 범위·규칙·완료 조건까지 넣어 만들어 줘.
한 단계 더
같은 문제에 대해 나와 다른 도구가 서로 다른 답을 내놨어. 두 답을 붙여 줄 테니, 어느 쪽이 이 프로젝트 규칙에 더 맞는지 근거를 들어 판정하고 두 답의 좋은 부분만 합친 안을 만들어 줘.
---
답 A: [붙여넣기]
답 B: [붙여넣기]
손이 많이 가는 작업의 계획은 Claude Code에서 세우고 실행만 Codex에 넘깁니다. 돌아와서 diff로 검수하는 단계까지 진행합니다.
헷갈리기 쉬운 것
규칙을 두 파일에 각각 복사해 두면 한쪽만 고쳐진 채로 두 도구가 다른 기준으로 작업합니다. 본문은 한 곳에만 두고 다른 쪽은 불러옵니다. 위임할 때 완료 조건을 빼면 돌아온 결과를 판정할 기준이 없으므로, 지시문에 파일 범위와 완료 조건을 넣습니다. 독립된 의견이 필요하면 한쪽 답을 다른 쪽에 보여 주지 않고 각자에게 따로 요청한 뒤 합칩니다.
왜 이렇게 작동하나요
한 사람이 작업하고 다른 사람이 검수할 때처럼, 계획·실행·검수를 서로 다른 단계로 나눕니다.
같은 폴더와 같은 규칙을 읽게 하면 도구마다 기준이 갈리는 일을 줄일 수 있습니다. 완료 조건을 넘기기 전에 적어야 돌아온 변경을 항목별로 판정할 수 있습니다.
더 알고 싶다면
왜 두 도구의 규칙 파일을 복사하지 않습니까?
복사본은 만든 날에만 같습니다. 이후 한쪽만 고쳐지는 순간 두 도구가 서로 다른 규칙으로 작업하고, 어느 쪽 결과가 맞는지 대조하는 일이 새로 생깁니다.
본문을 AGENTS.md 한 곳에 두고 CLAUDE.md 첫 줄에서 @AGENTS.md로 불러오면, 규칙 수정이 한 파일로 끝나고 두 도구가 항상 같은 판을 읽습니다.
공유가 실제로 되는지는 두 도구에 같은 질문을 보내 확인합니다. 규칙에서 지킬 항목 세 가지를 인용해 달라고 했을 때 같은 문장이 나오면 연결이 맞습니다.
왜 판단보다 실행을 넘깁니까?
반복 수정처럼 답이 정해진 일은 파일 범위와 완료 조건만 적으면 돌아온 결과를 항목별로 검수할 수 있습니다. 넘겨도 품질을 판정할 수단이 남습니다.
방향을 정하는 판단은 검수 기준 자체를 만드는 일이라, 넘기면 결과가 틀렸는지조차 알 수 없게 됩니다. 무엇을 만들지와 어긋난 요구를 좁히는 일은 결과를 책임지는 사람이 유지합니다.
안내문 40개의 날짜 표기를 한 형식으로 통일하는 일은 넘기기 좋은 일이고, 그 안내문의 톤을 어느 쪽으로 갈지 정하는 일은 직접 할 일입니다.