지난글에 Claude, Gemini, Codex CLI를 멀티 모델 오케스트레이션 환경으로 묶는 방법을 정리한 적이 있다. 다시 읽어보니 실제 쓰는 방식과 많이 다르다. 그 글은 터미널에서 bash 파이프라인을 손으로 연결하는 접근이었는데, 실제로는 Claude Code에 목표만 말하면 나머지는 알아서 돌아간다. 뒤에서 어떤 CLI가 돌아가는지 신경 쓸 필요가 없다. 그 구조를 실제에 맞게 다시 정리한다.
실제 사용 방식
내가 Claude Code를 열고 하는 일은 단순하다. 작업 목표를 자연어로 입력한다. “이 레포지터리에서 테스트 커버리지가 낮은 모듈을 찾아서 단위 테스트 작성해줘”라든가, “PRD 문서 분석해서 FastAPI 엔드포인트 구현해줘” 같은 식이다. 터미널에서 직접 gemini 명령을 치거나 codex exec 를 입력하는 일은 없다. 명령을 받은 Claude가 어떤 작업에 어떤 CLI를 쓸지 결정하고, 스킬을 통해 실행하고, 결과를 받아 다음 단계를 이어간다.
이게 가능한 구조가 세 층으로 나뉜다.
첫째, 사용자가 Claude Code에 명령을 입력한다. 어떤 CLI를 쓸지는 언급하지 않아도 된다.
둘째, Claude가 멀티오케스트레이션 스킬을 참조해서 이 작업에 어떤 CLI 스킬을 어떤 순서로 쓸지 결정한다. 이 판단 과정은 백단에서 일어나고, 사용자 눈에는 보이지 않는다.
셋째, 결정된 스킬(codex-delegate, gemini-delegate 등)을 통해 외부 CLI가 실행된다. 결과는 Claude Code 세션으로 돌아와서 다음 단계 판단에 쓰인다.
멀티오케스트레이션 스킬이 하는 일
멀티오케스트레이션 스킬은 라우팅 레이어다. “어떤 작업이면 어떤 CLI 스킬을 써라”는 판단 기준을 정의한 SKILL.md 파일이다. Claude는 사용자 명령을 받으면 이 스킬을 참조해서 작업의 성격을 분류하고, 그에 맞는 실행 스킬을 선택한다.
예를 들어 새 파일을 여러 개 만들어야 하는 코드 생성 작업이라면 codex-delegate, 문서나 레포지터리 전체를 분석해야 하는 작업이라면 gemini-delegate로 라우팅한다. 두 가지가 섞인 복잡한 작업은 순서를 정해 연달아 호출한다. 독립적으로 처리할 수 있는 부분이 있으면 병렬로 디스패치한다. 이 모든 판단이 스킬 파일 안에 지침으로 담겨 있어서, Claude는 매번 새로 생각하는 게 아니라 정해진 기준대로 작동한다.
codex-delegate — 코드 생성 실행 스킬
멀티오케스트레이션 스킬이 “코드 생성” 작업으로 분류하면 codex-delegate 스킬이 호출된다. 이 스킬이 실제로 하는 일은 Codex CLI에 작업을 위임하는 것이다.
스킬은 OpenAI의 Codex CLI 공식 문서를 기반으로 만들었다. 명령 옵션 구조, --full-auto 플래그 동작 방식, stdin을 통한 프롬프트 전달 패턴 등 실제 동작에 필요한 내용을 문서에서 확인하고 SKILL.md에 지침으로 정리했다.
스킬 내부에서 Codex 호출은 이런 형태로 이뤄진다.
codex exec --full-auto -C /path/to/project "
다음 파일들을 생성해줘:
1. src/hooks/useSpinState.ts
- 슬롯 스핀 상태 관리 (idle/spinning/stopping)
- @slotflix/types에서 SpinResult 타입 사용
2. src/hooks/useWalletBalance.ts
- 잔액 조회 및 갱신
- API: GET /api/wallet/balance
"
사용자는 이 명령을 직접 치지 않는다. Claude가 스킬 지침을 따라 작업 내용을 정리하고 --full-auto 플래그와 함께 Codex에 넘긴다. Codex가 파일을 쓰고 나면 결과가 Claude Code 세션으로 돌아온다. 그 결과를 Claude가 검토하고 다음 단계로 이어간다.
codex-delegate 스킬에는 자주 발생하는 오류 대응도 정의되어 있다. --full-auto가 없으면 Codex가 매 파일마다 확인을 요구하며 멈추고, -C로 프로젝트 루트를 지정하지 않으면 파일이 엉뚱한 경로에 생긴다. 이런 주의사항이 스킬 파일에 담겨 있어서 Claude가 Codex를 호출할 때마다 자동으로 반영된다.
이미지 출처: Unsplash
gemini-delegate — 분석 실행 스킬
멀티오케스트레이션 스킬이 “대용량 문서 분석”이나 “레포지터리 전체 파악” 작업으로 분류하면 gemini-delegate 스킬이 호출된다. Gemini CLI의 100만 토큰 컨텍스트 윈도우를 활용해서, Claude가 직접 처리하면 컨텍스트를 많이 잡아먹는 작업을 위임한다.
이 스킬도 마찬가지로 Gemini CLI 공식 문서를 참조해서 만들었다. -p 플래그로 프롬프트를 전달하는 방식, stdin 파이프를 통해 대용량 파일을 넘기는 패턴, 출력 포맷 지정 방법 등을 문서에서 확인하고 스킬 파일에 녹여넣었다.
내부적으로는 gemini -p "분석 지시" < 대용량_파일.md 형태로 호출하고, 결과를 다시 Claude Code 세션으로 받는다. 사용자는 이 과정을 볼 필요가 없다. Claude가 분석 결과를 받아 검토한 뒤, “이 결과를 바탕으로 다음은 codex-delegate로 구현한다”는 식으로 이어간다.
사용자 입장에서 실제 흐름
구체적인 예를 들어보면 이해가 빠르다. “이 레포지터리 전체를 분석해서 테스트가 없는 함수들을 찾고, 각 함수에 단위 테스트 작성해줘”라는 명령을 Claude Code에 입력한다고 가정하자.
Claude는 멀티오케스트레이션 스킬을 참조해서 이렇게 판단한다. 레포지터리 전체 분석은 Gemini에 위임, 그 결과를 받아 테스트 작성은 Codex에 위임. 독립적인 함수들은 병렬 처리 가능하다고 판단하면 Codex 세션을 여러 개 띄워 동시에 처리한다.
사용자가 보는 건 Claude Code 창에서 작업이 진행되는 상황뿐이다. 어느 단계에서 Gemini가 돌고 있는지, Codex가 몇 파일을 쓰고 있는지는 백단에서 처리되며 결과만 돌아온다. 최종적으로 Claude가 생성된 테스트 파일들을 리뷰하고, 추가 수정이 필요하면 다시 Codex로 위임한다.
이게 원래 글에서 설명한 bash 파이프라인 방식과 근본적으로 다른 점이다. 파이프라인 방식은 사용자가 매 단계마다 어떤 CLI를 어떻게 연결할지 직접 설계해야 했다. 스킬 기반 방식에서 사용자는 목표만 말한다. 라우팅과 실행은 스킬을 참조한 Claude의 몫이다.
스킬 파일 자체를 만들고 다듬는 데 처음에 시간이 들지만, 한 번 셋업하면 반복 작업에서 계속 재사용된다. 스킬이 정교해질수록 Claude의 라우팅 판단도 정확해지고, 위임 결과물의 품질도 올라간다. 멀티 CLI를 운영하는 부담이 거의 사라지고, 실제 목표에 집중하는 시간이 늘어나는 것이 가장 큰 차이다.
한 가지 더 짚어둘 점이 있다. 허브 역할이 꼭 Claude Code일 필요는 없다. Codex에도 스킬 시스템이 있어서, Codex를 중심에 두고 Claude와 Gemini에 명령을 내리는 구성도 가능하다. Gemini CLI가 오케스트레이터가 되어 나머지 두 CLI를 서브로 쓰는 방식도 마찬가지다. 어떤 CLI를 허브로 삼을지는 결국 어떤 판단을 가장 믿느냐의 문제다. 지금은 Claude Code를 허브로 쓰는 게 추론과 컨텍스트 관리 면에서 가장 자연스럽다고 느끼지만, 스킬 생태계가 각 CLI마다 성숙해지면 허브를 바꾸거나 상황별로 다르게 가져가는 것도 현실적인 선택지가 된다.
출처