메인 에이전트는 질문과 답만 본다 — Codex 위임에서 세션 오케스트레이션까지#

2026-10-31

램프가 비추는 나무 책상 위에서 의자에 앉은 작은 로봇이 봉인된 봉투를 생김새가 다른 로봇에게 건네고, 뒤쪽에는 커튼이 달린 작은 작업 칸들이 늘어서 각 칸에서 로봇이 따로 일하고 있으며, 사람의 손이 그중 한 칸의 커튼을 걷어 안을 들여다보는 그림

필자는 Claude Code와 Codex를 둘 다 Team 플랜으로 구독해서 씁니다. 한쪽 한도만 빨리 닳지 않도록 두 도구에 일을 나눠 맡기는데, 이 “나눠 맡기기"를 하려면 결국 사람이 두 앱을 오가야 했습니다. 이 글은 그 왕복을 줄이려고 Claude Code를 메인으로 두고 Codex를 서브에이전트처럼 부리는 방법을 찾아 직접 붙여 본 기록입니다.

결론부터 적으면 이렇습니다. 메인 에이전트가 관심을 두는 것은 무엇을 맡겼고 무엇이 돌아왔는지뿐입니다. 이 원칙에 맞는 공식 도구가 이미 있었고(OpenAI의 codex-plugin-cc), 붙이는 과정에서는 오류 메시지가 가리킨 곳과 실제 원인이 달랐습니다. 2부에서는 같은 원칙을 한 단계 넓혀, 관리자 세션이 작업자 세션을 만들고 서로 소통하는 구조가 여러 코딩 에이전트에서 어디까지 가능한지 정리합니다.

1부. Claude Code에서 Codex를 서브에이전트로#

두 구독, 두 개의 창#

지금까지 두 에이전트 사이의 소통은 저장소에 문서를 하나 두고 양쪽이 함께 읽게 하는 방식이었습니다. 여러 날에 걸친 작업을 넘겨줄 때는 이 방식이 꽤 안정적입니다. 불편한 것은 그보다 잦은 일, 그러니까 “이건 Codex에게 맡기자"고 판단할 때마다 Codex 앱으로 건너가서 맥락을 다시 설명하고 결과를 들고 돌아오는 일이었습니다. 에이전트를 여럿 쓸수록 사람이 그 사이를 오가는 스케줄러가 된다는 이야기는 이전 글에서도 다뤘습니다.

그래서 떠올린 아이디어는 단순했습니다. Claude Code와 Codex는 둘 다 터미널 명령을 실행할 수 있고 둘 다 CLI(Command Line Interface, 명령줄 도구)가 있습니다. 그렇다면 Claude Code 에이전트가 Codex의 CLI를 실행해서 Codex 에이전트에게 일을 시키고 결과를 받아 오는 것도 기술적으로는 가능할 것입니다.

메인 에이전트가 보는 것은 질의와 최종 응답입니다#

Claude Code에서 메인 에이전트가 서브에이전트에게 일을 맡기는 장면을 떠올려 보면, 메인이 신경 쓰는 것은 두 가지뿐입니다. 무엇을 요청했는지, 그리고 최종적으로 무엇이 돌아왔는지입니다. 서브에이전트가 파일을 몇 개 읽었는지, 어떤 가설을 세웠다가 버렸는지, 명령을 몇 번 다시 실행했는지는 서브에이전트 자신의 맥락 안에서 일어나고 끝납니다. 메인의 맥락에는 요약된 결과만 들어옵니다.

필자가 원한 것도 정확히 이 흐름이었습니다. Claude Code 에이전트(메인)가 Codex 에이전트에게 요청을 보내고, Codex는 혼자 일한 뒤 최종 응답만 돌려줍니다. 오래 걸리는 일이라면 메인이 나중에 결과를 가져가면 됩니다. 이 구조에는 두 가지 장점이 있습니다.

  • 메인의 맥락이 가볍게 유지됩니다. Codex가 중간에 읽은 파일과 실행 기록은 메인의 맥락에 쌓이지 않습니다.
  • 사용량이 맡은 쪽에서 나갑니다. 무거운 탐색과 시행착오는 Codex 구독에서 처리되고, Claude 쪽은 요청을 쓰고 결과를 읽는 만큼만 씁니다.

그래서 방법을 고를 때의 기준은 하나였습니다. Codex를 붙인 뒤에도 “질의를 보내고 최종 응답을 받는” 서브에이전트의 흐름을 그대로 유지할 수 있는가입니다.

먼저 해 본 사람들의 방법과 걸림돌#

같은 생각을 먼저 해 본 사람들은 꽤 많았습니다. 방법은 크게 네 갈래였고, 각각 걸림돌이 있었습니다.

방법걸림돌
codex exec를 직접 호출입력 대기로 멈추거나 아무 일 없이 “성공"으로 끝남, macOS에서 샌드박스 중첩 충돌, 환경변수에 API 키가 있으면 종량제로 과금
커뮤니티 MCP 브리지유지보수 수준이 제각각이고, 샌드박스와 승인을 끈 채 Codex를 실행하는 구현도 있음
직접 만든 양방향 대화 시스템잠금 우회, 턴 꼬임 같은 문제를 결국 훅 같은 기계적 장치로 막아야 함
OpenAI 공식 플러그인 codex-plugin-cc선택 기능인 리뷰 게이트를 켜면 Claude가 응답을 마칠 때마다 Codex 리뷰가 돌아, 공식 문서도 사용량이 빨리 닳을 수 있다고 경고함

첫 번째 방법의 함정은 Steve Kinney의 정리가 가장 자세했습니다. 다른 에이전트가 Codex를 실행하면 표준 입력이 닫히지 않아 Codex가 멈추거나, 아무 작업 없이 정상 종료할 수 있습니다. 그래서 입력을 /dev/null로 막고, 결과 파일이 비어 있으면 실패로 봐야 합니다. 출력이 없는 리뷰를 통과로 읽으면 안 된다는 뜻입니다.

세 번째 방법은 Claude Code 두 개와 Codex 하나를 파일 기반 메시지로 대화시킨 dev.to 사례가 인상적이었습니다. 대화는 보통 3–6턴 안에 합의에 도달했고, 역할을 정해 주지 않아도 능력에 따라 일이 나뉘었다고 합니다. 반면 Claude Code 세션이 대화 파일을 편집 도구로 직접 고쳐 잠금을 우회하는 일이 생겨 훅으로 막아야 했고, Codex에는 같은 훅이 없어 규칙 문서에 기대야 했습니다. 저자의 결론은 “말로 정한 규칙보다 기계적 장치가 낫다"였습니다.

사용량 쪽 경고도 있었습니다. 한 Reddit 사용자는 codex-plugin-cc가 아닌 다른 코드 리뷰 플러그인이 서브에이전트를 연쇄로 띄우면서 간단한 수정 하나에 주간 사용량을 15분 만에 소진했다고 보고했습니다. 그리고 여러 글이 공통으로 짚은 점이 하나 있습니다. 두 에이전트가 동의했다고 해서 맞는 것은 아닙니다. 같은 잘못된 요구사항을 받은 두 에이전트는 함께 틀린 답에 동의할 수 있습니다.

반대 방향, 즉 Codex가 claude -p로 Claude를 부르는 방법도 살펴봤지만 이번에는 고려하지 않았습니다. 공식 플러그인이 없고, Codex 샌드박스가 기본으로 네트워크를 막아서 claude -p를 쓰려면 Codex가 실행하는 모든 명령에 네트워크를 열어 줘야 합니다. 무엇보다 필자의 목표가 Claude Code 한 화면에 머무는 것이었으므로, 이 방향은 필요하지 않았습니다.

codex-plugin-cc를 고른 이유#

OpenAI는 2026년 3월 30일에 Claude Code용 공식 플러그인인 codex-plugin-cc를 오픈소스로 공개했습니다. 명령은 여덟 개인데, 성격으로 나누면 세 묶음입니다.

  • 리뷰: /codex:review는 정해진 형식의 읽기 전용 리뷰이고, /codex:adversarial-review는 설계 결정에 반론을 제기하는 리뷰로 집중할 부분을 자유 문장으로 덧붙일 수 있습니다.
  • 위임: /codex:rescue는 아무 작업이나 자유 문장으로 맡기는 범용 명령입니다. 이전 작업 이어가기(--resume), 백그라운드 실행(--background), 모델과 추론 강도 지정도 됩니다. 명령 없이 “이거 Codex에게 맡겨 줘"라고 말해도 됩니다.
  • 작업 관리: /codex:status, /codex:result, /codex:cancel로 백그라운드 작업을 확인하고 결과를 가져오거나 취소합니다. /codex:transfer는 현재 Claude Code 대화를 Codex 스레드로 옮겨 Codex에서 이어 갈 수 있게 합니다. /codex:setup은 설치와 로그인 상태를 점검합니다.

필자가 이 플러그인을 고른 결정적인 이유는 내부 구조였습니다. /codex:rescue를 실행하면 플러그인은 codex-rescue라는 Claude Code 서브에이전트를 하나 띄웁니다. 이 서브에이전트의 정의를 열어 보면 쓸 수 있는 도구가 Bash 하나뿐이고, 할 일은 “플러그인 스크립트를 한 번 실행해 Codex에 요청을 전달하고, 그 출력을 해설 없이 그대로 돌려주는 것"으로 못 박혀 있습니다. 파일을 읽거나 상태를 확인하는 다른 행동은 금지되어 있습니다.

정리하면 흐름은 이렇습니다.

  1. 메인 에이전트(Claude)가 codex-rescue 서브에이전트에게 일을 맡깁니다.
  2. 서브에이전트(Sonnet 모델)가 플러그인 스크립트를 한 번 실행합니다.
  3. 스크립트가 Codex에 작업을 넘기고, Codex가 실제 작업을 합니다.
  4. Codex의 최종 응답이 손대지 않은 채 메인으로 돌아옵니다.

Claude Code의 서브에이전트 구조를 그대로 쓰면서, 실제 일꾼만 Codex로 바꾼 셈입니다. 앞에서 세운 기준, 즉 질의를 보내고 최종 응답을 받는 흐름에 정확히 들어맞습니다. 중간의 Sonnet 서브에이전트가 Claude 사용량을 조금 쓰지만, 하는 일이 전달 한 번뿐이라 양은 작습니다.

다만 알고 쓸 점이 세 가지 있습니다.

  • /codex:rescue는 기본이 쓰기 모드입니다. 조사만 시키려면 요청에 “읽기 전용으로"라고 적어야 합니다. 플러그인 스크립트 자체는 쓰기 옵션이 없으면 읽기 전용으로 실행되는데, 서브에이전트가 기본으로 쓰기 옵션을 붙입니다.
  • 요청 문장이 다듬어질 수 있습니다. 서브에이전트 정의에는 전달 전에 요청을 GPT 모델에 맞게 다듬어도 된다는 허용이 들어 있습니다. 그래서 Codex가 정확히 무엇을 받았는지는 Codex 쪽 기록에서 확인하는 것이 맞습니다.
  • 리뷰 게이트는 꺼 두는 편이 낫습니다. Claude가 응답을 마치려 할 때마다 Codex가 리뷰하고, 문제가 나오면 종료를 막아 Claude가 먼저 고치게 하는 기능입니다. 기본은 꺼져 있습니다. 공식 README도 Claude와 Codex가 오래 주고받는 루프가 생겨 사용량이 빨리 닳을 수 있다며, 세션을 지켜볼 때만 켜라고 경고합니다.

붙여 보니: 오류 메시지가 가리킨 곳과 원인이 달랐습니다#

설치와 점검까지는 순조로웠습니다. 터미널의 claude plugin 명령으로 마켓플레이스를 추가하고 플러그인을 유저 범위로 설치한 뒤, /codex:setup과 같은 점검을 돌리니 Node, Codex CLI, 로그인 상태가 모두 정상으로 나왔습니다.

첫 위임은 “ARCHITECTURE.md를 읽고 최상위 디렉터리별 역할을 다섯 줄 이내로 요약하되 파일은 수정하지 말 것"이라는 작은 읽기 전용 작업이었습니다. 이 작업은 4초 만에 실패했습니다.

The 'gpt-6.1-sol' model is not supported when using Codex with a ChatGPT account.

Codex 설정 파일의 기본 모델이 ChatGPT 계정에서 지원되지 않는다는 메시지였습니다. 그런데 기록을 보니 같은 모델이 Codex 데스크톱 앱에서는 전날까지 정상적으로 쓰이고 있었습니다. 실제로 CLI가 들고 있는 모델 목록에도 그 모델이 없었기 때문에, CLI 버전이 앱보다 오래되어 최신 모델을 모르는 것이라고 추정했습니다.

CLI를 0.155.0에서 0.166.0으로 올리고 다시 돌렸지만, 똑같이 실패했습니다. 이번에는 플러그인을 거치지 않고 codex exec를 직접 실행해 봤는데, 같은 기본 모델로 성공했습니다. CLI 자체에는 문제가 없다는 뜻입니다.

단서는 Codex가 남기는 세션 기록에 있었습니다. 각 세션 기록에는 그 세션을 실행한 CLI 버전이 적혀 있는데, codex exec로 만든 세션은 0.166.0이었고 플러그인을 거친 세션은 업데이트 후에도 0.155.0이었습니다. 플러그인은 처음 실행될 때 Codex 서버 프로세스(codex app-server)를 백그라운드에 띄워 두고 계속 재사용하는데, 그 프로세스가 옛 버전 그대로 살아 있었던 것입니다. 플러그인이 띄운 프로세스만 종료하고 다시 실행하니, 0.166.0과 기본 모델로 17초 만에 요약이 돌아왔고 저장소 파일은 하나도 바뀌지 않았습니다.

돌아보면 오류 메시지는 계정과 모델을 가리켰지만, 원인은 프로세스의 수명이었습니다. 메시지만 믿고 설정 파일의 기본 모델을 바꿨다면 데스크톱 앱의 기본값까지 건드리는 엉뚱한 우회로에 빠졌을 것입니다. CLI를 업데이트한 뒤 플러그인에서 모델 오류가 나면, 설정을 고치기 전에 세션 기록의 CLI 버전부터 확인하는 것이 순서입니다.

맡긴 일은 다시 열어 볼 수 있습니다#

위임 구조에서 사람이 불안해지는 지점은 “Codex에게 실제로 무엇이 전달됐고, Codex가 어떻게 일했는가"를 볼 수 있느냐입니다. 확인할 곳은 세 군데였고, 아래로 갈수록 자세합니다.

  1. Claude Code의 도구 실행 내역: 서브에이전트가 실행한 명령을 펼치면 Codex에 넘긴 요청 문장과 돌아온 출력이 보입니다.
  2. /codex:result: 최종 응답과 Codex 세션 ID를 보여 줍니다.
  3. Codex 세션 자체: 세션 ID로 codex resume <SESSION_ID>를 실행하면 Codex 화면에서 전체 대화가 열리고, 그대로 이어서 작업할 수 있습니다. 원본 기록은 ~/.codex/sessions/ 아래에 받은 요청, 실행한 명령, 최종 응답까지 모두 남습니다.

Codex 데스크톱 앱에서도 볼 수 있었습니다. 플러그인으로 만든 세션은 처음에는 앱 사이드바에 보이지 않았는데, 앱을 재시작하니 나타났습니다. 외부에서 만든 세션이 실행 중인 앱에 바로 반영되지 않는다는 보고는 Codex 저장소의 이슈에도 있습니다.

같은 확인을 Claude Code 쪽에서도 해 봤습니다. Cursor의 Claude Code 확장 안에서 에이전트가 claude -p로 짧은 세션을 하나 실행하게 했더니, 그 세션이 확장의 세션 기록 목록에 나타났습니다. 터미널 CLI의 세션 목록은 -p로 만든 세션을 일부러 빼도록 문서화되어 있어서 의외였습니다. 기록 파일을 열어 보니 실행 출처가 확장으로 기록되어 있었는데, 확장 안에서 실행되면서 확장의 환경을 물려받은 것으로 보입니다. 이 부분은 필자의 추정입니다.

이 확인을 하면서 한 가지가 분명해졌습니다. 플러그인이 만든 Codex 세션은 메인 에이전트에게는 “질의 하나와 응답 하나"였지만, 사람에게는 나중에 열어서 이어서 대화할 수 있는 독립된 세션이었습니다. 이 성질이 2부의 출발점입니다.

2부. 세션이 세션을 만들 수 있다면#

한 세션 안의 역할 분담이 가진 한계#

큰 프로젝트를 할 때 필자가 그려 온 구조가 있습니다. 전체 계획을 세우고 진행을 관리하는 세션이 하나 있고, 이 세션이 구현 작업을 다른 세션들에 나눠 맡기는 구조입니다.

한 세션 안에서 에이전트를 역할별로 나누는 것은 이미 가능하고, 필자도 그렇게 쓰고 있습니다. 문제는 사람이 개입할 때 생깁니다. 여러 에이전트의 동작이 한 세션 안에서 일어나면, 특정 에이전트가 무엇을 했는지 파악하고 그 에이전트에게 추가로 질문하는 것 자체가 어렵습니다. 어렵사리 그렇게 하더라도, 그 에이전트에 대한 지시와 대화가 같은 세션을 쓰는 다른 에이전트의 맥락에 섞여 들어갑니다.

1부에서 만든 Codex 세션은 이 문제를 비켜 갑니다. 일은 독립된 세션에서 일어나고, 메인은 결과만 받으며, 사람은 필요할 때 그 세션에 직접 들어가 따로 물어볼 수 있습니다. 그렇다면 이 구조를 Claude Code 세션끼리, 또는 다른 코딩 에이전트에서도 만들 수 있을까요. 이를 확인하려고 네 가지 기준을 세웠습니다.

  • 별도 세션 생성: 한 세션이 다른 독립 세션을 만들 수 있는가
  • 세션 간 소통: 실행 중인 세션끼리 메시지를 주고받을 수 있는가
  • 사람의 개입: 사람이 작업자 세션에 직접 들어가 이어서 대화할 수 있는가
  • 맥락 분리: 한 작업자에 대한 지시가 다른 작업자의 맥락을 오염시키지 않는가

Claude Code: 부품은 거의 갖춰져 있습니다#

2026년 10월 말 기준 Claude Code 공식 문서를 보면, 이 구조에 필요한 부품이 기능별로 흩어져 있습니다.

세션 간 메시징. v2.1.224부터 기본으로 켜져 있는 기능입니다. 같은 컴퓨터에서 실행 중인 내 Claude Code 세션끼리, Claude가 ListAgents로 상대 세션을 찾고 SendMessage로 메시지를 보냅니다. 메시지는 Anthropic 서버를 거치지 않고 컴퓨터 안의 세션별 소켓으로 전달됩니다. 오래 걸리는 작업을 하는 세션에 “다음에 작업을 마치면 한 번 알려 달라"고 구독해 둘 수도 있습니다. claude -p로 띄운 세션도 메시지를 받을 수 있습니다.

안전장치도 설계에 들어 있습니다. 다른 세션에서 온 메시지는 사용자의 지시가 아니라고 표시되므로, 권한 요청을 대신 승인하거나 설정을 바꾸게 할 수 없습니다. 메시지 속의 슬래시 명령은 실행되지 않습니다. 두 세션이 끝없이 메시지를 주고받는 상황은 수신 쪽에서 속도 제한과 중복 제거로 저절로 멈춥니다. 1부에서 본 직접 만든 대화 시스템이 훅으로 하나씩 막아야 했던 문제들을 제품이 기본으로 처리하는 셈입니다.

백그라운드 세션. 연구 프리뷰(research preview) 단계의 기능으로, claude --bg "작업 내용"을 실행하면 터미널 없이 돌아가는 완전한 Claude Code 세션이 하나 생깁니다. claude agents 화면에서 무엇이 실행 중이고 무엇이 입력을 기다리는지 보고, 원하는 세션에 들어가(attach) 직접 대화한 뒤 다시 빠져나올 수 있습니다. git 저장소라면 세션마다 별도 워크트리에서 작업해서 서로의 파일 수정이 섞이지 않습니다. 세션마다 구독 사용량을 각자 씁니다.

다만 에이전트가 이 세션을 직접 띄우는 전용 도구는 문서에 없습니다. 세션이 Bash로 claude --bg를 실행하는 방식은 기술적으로 가능해 보이지만, 문서에 나온 공식 패턴이 아니라 필자의 추론입니다. 1부에서 에이전트가 실행한 claude -p 세션이 사람의 세션 목록에 나타났다는 관찰은 이 방식이 실제로 쓸 만하다는 작은 근거 정도입니다.

Agent Teams. 실험 기능이라 환경변수로 켜야 합니다. 리더 세션이 팀원을 띄우고, 각 팀원은 자기 맥락을 가진 독립된 Claude Code 인스턴스입니다. 팀원끼리 메시지를 주고받고 공유 작업 목록에서 일을 가져가며, 사람은 리더를 거치지 않고 특정 팀원을 골라 직접 지시할 수 있습니다. 네 가지 기준을 거의 다 만족하지만 제약도 뚜렷합니다. 세션을 다시 열면 팀원이 복원되지 않고, 팀원이 또 팀을 만들 수 없으며, 팀은 리더 세션이 살아 있는 동안만 유지됩니다. 작업자 세션을 오래 두고 나중에 다시 열어 보려는 필자의 목적과는 거리가 있습니다.

Projects. 필자가 그린 구조와 가장 가까운 기능입니다. 관리자 대화 하나가 작업마다 스레드를 만들고, 각 스레드는 자기 맥락을 가진 별도 세션으로 일한 뒤 결과를 보고합니다. 문서는 관리자가 “스레드가 보고한 것만 보고, 스레드가 밟은 모든 단계는 보지 않는다"고 설명합니다. 1부의 원칙과 같은 말입니다. 사람은 스레드를 열어 그 스레드의 입력창에 직접 지시할 수 있습니다. 다만 스레드는 기본적으로 클라우드에서 실행되고, 아직 공개 베타이며, Team과 Enterprise 플랜에는 아직 제공되지 않습니다. 필자의 Team 플랜에서는 쓸 수 없습니다.

다른 코딩 에이전트들#

같은 기준으로 다른 코딩 에이전트도 살펴봤습니다. 공식 문서와 소스를 중심으로 확인했지만, 기능이 빠르게 바뀌는 영역이라 2026년 10월 말 시점의 정리입니다.

에이전트별도 세션 생성세션 간 소통사람의 개입
Claude Codeclaude --bg (에이전트가 띄우는 것은 셸 우회), Agent Teams공식 지원 (세션 간 메시징)백그라운드 세션에 직접 들어감
Codex하위 에이전트가 별도 스레드, 독립 세션은 codex exec나 서버 API독립 세션 간 공식 기능은 찾지 못함CLI·앱에서 하위 스레드를 열어 봄, 지시는 메인을 거침
Gemini CLI하위 에이전트는 세션 내부, 별도 세션은 gemini -p 스크립트원격 에이전트용 A2A만 있음하위 에이전트에는 불가
Hermes Agent하위 에이전트는 세션 내부, 별도 세션은 tmux로 띄우는 공식 스킬하위 에이전트 조종(steer), 별도 세션은 tmux 입출력tmux로 붙거나 나중에 이어 열기
OpenCode 2하위 에이전트가 실제 하위 세션으로 저장, 서버 API로 독립 세션 생성부모가 자기 하위 세션에 후속 지시하위 세션은 화면에서 읽기 전용

Codex는 하위 에이전트를 각자의 스레드에서 돌리고, CLI에서는 /subagents로 스레드를 오가며 들여다볼 수 있으며 앱도 하위 에이전트 스레드를 보여 줍니다. 다만 공식 문서상 하위 에이전트를 조종하거나 멈추는 것은 메인 대화를 통해서 합니다. 독립된 세션을 만드는 것은 codex exec나 내부 서버 API로 가능하고, 1부의 플러그인이 바로 그 방식으로 사람이 열어 볼 수 있는 세션을 만들었습니다. 다만 이미 실행 중인 독립 세션끼리 메시지를 주고받는 공식 기능은 찾지 못했습니다.

Gemini CLI의 하위 에이전트는 별도의 맥락에서 일하고 메인에 결과를 보고하지만, 하위 에이전트끼리 서로 부를 수는 없습니다. 별도 세션은 gemini -p를 스크립트로 실행하는 방법뿐입니다. A2A(Agent2Agent, 에이전트 간 통신 프로토콜)는 외부 원격 에이전트를 부르는 용도입니다. 덧붙여, Google AI Pro·Ultra 같은 개인 구독 사용자 대상으로는 2026년 6월 18일부터 Gemini CLI가 Antigravity CLI로 넘어갔고, Gemini CLI는 기업 라이선스나 유료 API 키로 계속 쓸 수 있습니다.

Hermes Agent의 delegate_task는 새 대화와 제한된 도구를 가진 하위 에이전트를 띄우고, 실행 중인 하위 에이전트의 방향을 바꾸거나(steer) 멈출 수 있습니다. 완전히 독립된 세션은 번들 스킬이 tmux 안에서 Hermes를 하나 더 실행하는 방식으로 만듭니다. 사람은 그 tmux 세션에 붙을 수 있지만, 세션 사이의 소통은 화면에 키 입력을 보내고 출력을 긁어 오는 수준입니다.

OpenCode 2는 오픈소스 중 가장 가깝습니다. 하위 에이전트를 부를 때마다 부모 ID를 가진 실제 세션이 저장되고, 부모는 자기 하위 세션에 후속 지시를 보낼 수 있습니다. 문서에 따르면 서버 API로 만든 세션도 터미널, 웹, 데스크톱 화면에 모두 나타납니다. 다만 조사 시점의 소스 기준으로 하위 세션은 화면에서 읽기 전용이라 사람이 직접 입력할 수 없습니다. 하위 세션 대신 API로 독립 세션을 만들어 맡기면 사람이 들어갈 수 있는 작업자 세션이 되는데, 이것도 에이전트 내장 도구가 아니라 스크립트로 해야 합니다.

표 밖의 사례로, 상용 코딩 에이전트인 Amp는 에이전트가 별도 스레드에서 다른 에이전트를 띄우고 지시를 보내며 결과를 보고받는 기능을 공식으로 제공합니다. 각 스레드가 자기 대화, 맥락, 작업 사본을 갖는다는 점에서 이번 조사에서 가장 완성된 형태였습니다.

정리하면, “관리자 세션 + 사람이 들어갈 수 있는 작업자 세션"을 제품 기능으로 완성한 곳은 Claude Code의 Projects와 Amp 정도이고, 나머지는 부품을 직접 조립해야 합니다. 그 조립 재료가 가장 많이 갖춰진 곳이 Claude Code였습니다.

필자가 그려 보는 구조#

그래서 필자는 Projects를 쓸 수 없는 Team 플랜에서 다음 구조를 시험해 볼 생각입니다. 아직 돌려 보지 않은 설계안입니다.

  1. 관리자 세션은 계획과 진행 관리만 맡고, 구현 작업은 직접 하지 않습니다.
  2. 구현 작업마다 관리자 세션이 claude --bg로 작업자 세션을 띄웁니다. 작업자는 각자 워크트리에서 일합니다.
  3. 관리자는 작업자에게 “끝나면 알려 달라"고 구독해 두고, 결과는 SendMessage로 받습니다. 관리자의 맥락에는 요청과 결과만 쌓입니다.
  4. 사람은 claude agents에서 특정 작업자 세션에 들어가 따로 질문하고 지시합니다. 그 대화는 관리자나 다른 작업자의 맥락에 섞이지 않습니다.
  5. Codex에 맡길 일은 관리자나 작업자가 1부의 플러그인으로 넘깁니다. 이 경우 작업자는 Codex 세션이 되고, 사람은 codex resume이나 Codex 앱으로 들어갑니다.

확인해야 할 것도 남아 있습니다. 에이전트가 셸로 띄운 백그라운드 세션이 사람이 띄운 세션과 똑같이 다뤄지는지, 필자가 주로 쓰는 Cursor 확장에서 이 세션들이 어떻게 보이는지, 작업자가 늘어날 때 구독 사용량이 감당할 만한지입니다.

맺으며#

처음 질문은 “Claude Code 에이전트가 Codex 에이전트와 소통할 수 있을까"였습니다. 조사하고 붙여 보니, 필요한 소통은 생각보다 단순했습니다. 메인 에이전트는 질의를 보내고 최종 응답을 받으면 되고, 그 사이의 과정은 작업을 맡은 쪽의 독립된 공간에 남겨 두면 됩니다. 그 과정이 궁금할 때는 사람이 그 공간에 직접 들어가 보면 됩니다.

1부의 codex-plugin-cc는 이 원칙을 Claude Code와 Codex 사이에서 구현한 도구였고, 2부에서 살펴본 세션 단위의 기능들은 같은 원칙을 세션과 세션 사이로 넓히는 재료였습니다. 필자는 당분간 Claude Code를 메인으로 두고 넘길 수 있는 일은 플러그인으로 Codex에 맡기면서, 위의 관리자·작업자 세션 구조를 작은 프로젝트에서 시험해 볼 계획입니다. 그 결과는 따로 정리하겠습니다.

부록: 설치와 점검#

Claude Code 안에서 플러그인을 설치하는 명령입니다.

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

터미널에서는 같은 일을 이렇게 할 수 있습니다.

claude plugin marketplace add openai/codex-plugin-cc
claude plugin install codex@openai-codex

위임할 때의 예시입니다.

/codex:rescue 읽기 전용으로 content 아래 front matter 누락 항목을 조사해 줘
/codex:rescue --background 테스트가 실패하는 원인을 찾아 줘
/codex:status
/codex:result

Codex CLI를 업데이트한 뒤 플러그인에서 모델 오류가 나면, 플러그인이 띄운 옛 버전 서버가 남아 있는지 확인합니다.

# 최근 Codex 세션이 어떤 CLI 버전으로 실행됐는지 확인
grep -m1 -o '"cli_version":"[^"]*"' "$(ls -t ~/.codex/sessions/*/*/*/*.jsonl | head -1)"

# 플러그인이 띄운 브로커와 app-server 프로세스 확인
ps -axo pid,lstart,command | grep -E 'app-server-broker|codex app-server' | grep -v grep

옛 버전으로 떠 있는 플러그인 프로세스만 종료하거나 Claude Code 세션을 새로 열면, 다음 위임에서 새 버전으로 다시 뜹니다. Codex 앱이나 다른 편집기 확장이 띄운 codex app-server 프로세스는 건드리지 않도록 경로를 확인합니다.

이 글에서 확인한 버전은 Claude Code 2.1.310, Codex CLI 0.155.0과 0.166.0, codex-plugin-cc 1.0.6입니다.

참고 자료#