요즘 개발자라면 AI CLI 한두 개쯤은 매일 쓰고 있을 것이다. ChatGPT나 Claude 웹 인터페이스를 넘어 터미널에서 직접 호출 가능한 명령줄 도구들이 생산성의 새로운 표준으로 자리잡았다. 그런데 한참 쓰다 보면 한 가지가 분명해진다. 어떤 모델 하나만 골라 쓰면 결국 어딘가에서 한계에 부딪힌다.
이미지 출처: Unsplash
이 글에서는 Claude Code, Gemini CLI, Codex CLI를 묶어서 멀티 모델 오케스트레이션 환경으로 운영하는 방법을 정리한다. 각 CLI의 설치와 인증부터 실제 호출 명령, 모델 간 컨텍스트 전달 패턴, 자주 쓰는 체이닝 시나리오까지 실무에서 바로 따라할 수 있는 수준으로 풀어본다. 한 번 셋업하는 데 한두 시간이면 충분하지만, 한 번 익숙해지면 작업 효율이 확연히 달라진다.
한 모델만으로는 어디서 막히는가
ChatGPT, Claude, Gemini, Codex 같은 AI 도구가 각자 잘하는 영역이 다르다는 건 더 이상 비밀이 아니다. 추론과 계획에 강한 모델, 긴 문서를 정확하게 읽는 모델, 코드 한 덩어리를 빠르게 뽑는 모델이 따로 있다. 같은 작업을 여러 모델에 나눠 던져보면 결과물의 품질이 한눈에 갈린다.
예를 들어 100페이지짜리 PRD(Product Requirements Document)를 받아 백엔드 API를 구현해야 한다고 해보자. Claude Opus 4.7만 쓰면 문서 전체를 컨텍스트에 올리는 비용이 부담된다. ChatGPT GPT-5.5만 쓰면 코드 생성은 빠르지만 처음에 전체 구조를 파악하는 단계에서 자주 헛다리를 짚는다. Gemini 3.1 Pro만 쓰면 문서 분석은 탁월하지만 긴 코드 작성에서 일관성이 떨어진다. 한 모델에 처음부터 끝까지 맡기면 어느 단계에서든 비용 또는 품질 손실이 발생하는 셈이다.
해결책은 단순하다. 각 단계에 가장 강한 모델을 배치하면 된다. 이게 멀티 모델 오케스트레이션의 핵심 아이디어다. 거창해 보이지만, 사실 적합한 도구를 적합한 자리에 배치하는 작업에 가깝다.
Claude·Gemini·Codex – 누가 무엇을 잘하나
내 셋업에서는 세 모델을 다음과 같이 배치한다.
Claude는 컨트롤 타워다. 작업을 분해하고, 어떤 모델에게 어떤 일을 시킬지 결정하고, 결과물을 리뷰한다. 기획·추론·코드 리뷰가 강점이라 오케스트레이터로 가장 적합하다. 특히 Claude Code는 파일 편집, 도구 사용, 멀티스텝 추론을 동시에 잘 해서 흐름 자체를 관장하는 역할에 자연스럽게 맞는다. 비용은 다른 두 모델보다 높지만, 정밀한 판단이 필요한 자리에만 쓰면 충분히 정당화된다.
Gemini CLI는 긴 문서·대용량 파일 분석을 맡는다. Gemini 3.1 Pro의 컨텍스트 윈도우가 1M(100만) 토큰으로 매우 크고, 문서 파싱·요약·핵심 추출 능력이 좋다. PRD나 설계 문서, 기존 레포 전체를 한 번에 읽혀서 “핵심만 뽑아줘”라고 시키기에 딱이다. 출력 단가도 가장 저렴해서 대량 처리에 부담이 없다.
Codex CLI는 코드 생성과 완성 전문이다. 분석된 스펙을 바탕으로 함수·모듈을 빠르게 찍어내거나 보일러플레이트를 채우는 역할이다. 특히 단편적인 구현 요청에서 응답 속도와 코드 품질이 균형 잡혀 있다. GPT-5.5 Codex 변종 기반으로 작동하며, 코드 컨텍스트 인식 능력이 일반 GPT보다 한 단계 위다.
세 모델을 한 줄로 정리하면 이렇다. Gemini가 “읽고 정리”를, Codex가 “쓰고 채우기”를, Claude가 “판단하고 묶기”를 담당한다.
이미지 출처: Unsplash
세 CLI 모두 설치하고 인증하기
먼저 사전 준비물이 있다. Node.js 18 이상과 Homebrew(macOS) 또는 동등한 패키지 매니저가 필요하다. 셋 모두 명령줄에서 globally 동작한다.
Claude Code 설치는 npm 한 줄이면 끝난다.
npm install -g @anthropic-ai/claude-code
설치 후 첫 실행 시 인증 단계로 넘어간다. 터미널에서 claude를 입력하면 브라우저가 열리며, Anthropic Console에서 발급한 API 키 또는 Claude Pro/Max 구독 계정으로 로그인하라는 안내가 뜬다. 인증이 완료되면 토큰이 로컬 ~/.claude/ 디렉터리에 저장된다. 별도의 환경변수 설정은 필요 없다.
Gemini CLI는 Google 공식 도구다. 마찬가지로 npm으로 설치한다.
npm install -g @google/gemini-cli
설치 후 처음 gemini 명령을 입력하면 브라우저가 열리며 Google 계정 로그인 안내가 뜬다. OAuth 인증이 끝나면 토큰이 로컬에 저장되어 이후로는 별도 설정 없이 바로 사용할 수 있다. CI 환경처럼 브라우저를 띄울 수 없는 자리에서는 Google AI Studio에서 발급한 API 키를 환경변수 GEMINI_API_KEY로 등록하는 대안이 있지만, 개인 개발 환경에서는 직접 로그인이 훨씬 간편하다.
Codex CLI는 OpenAI 공식 도구로, npm 또는 Homebrew로 설치한다.
# npm 사용
npm install -g @openai/codex
# 또는 Homebrew (macOS)
brew install codex
인증 흐름도 Claude Code, Gemini CLI와 동일하다. 첫 실행 시 codex login 또는 codex 명령을 입력하면 ChatGPT 계정으로 로그인하라는 OAuth 흐름이 시작된다. ChatGPT Plus나 Pro 구독이 있으면 별도 API 키 발급 없이 그대로 쓸 수 있다. API 키 방식도 지원하지만, 구독 계정으로 직접 로그인하는 쪽이 사용량 관리와 청구 통합 측면에서 훨씬 단순하다.
세 CLI 모두 같은 패턴이다. 설치 후 첫 실행에서 브라우저 OAuth 한 번이면 끝나고, API 키를 따로 발급받거나 환경변수에 둘 필요가 없다. 키 관리 부담이 사라지고, 구독 기반 요금제(Claude Pro/Max, Gemini Advanced, ChatGPT Plus/Pro)와 자연스럽게 통합된다는 점이 가장 큰 장점이다.
체이닝 – 모델을 이어 붙이는 패턴
체이닝의 핵심은 한 모델의 출력을 다음 모델의 입력 컨텍스트로 명확하게 전달하는 것이다. 모델은 직전 단계의 결과만 알 수 있으므로, 필요한 정보를 명시적으로 포함시켜 넘겨야 한다.
가장 자주 쓰는 패턴은 분석 → 계획 → 구현 → 리뷰의 4단계다. 새 API를 만든다고 가정하면 흐름은 이렇다.
# 1단계: Gemini로 PRD 분석해 스펙 추출
gemini -p "다음 PRD를 분석해 API 엔드포인트, 데이터 모델, 비즈니스 로직을 정리해줘. 결과는 마크다운으로." < prd.md > spec.md
# 2단계: Claude Code로 구현 계획 수립
claude "spec.md를 읽고, 이 API를 구현하기 위한 단계별 계획과 파일 구조를 제안해줘" > plan.md
# 3단계: Codex로 실제 코드 생성
codex --context "$(cat spec.md plan.md)" "위 스펙과 계획에 따라 FastAPI 엔드포인트와 Pydantic 모델을 생성해줘" > implementation.py
# 4단계: Claude Code로 코드 리뷰
claude "@implementation.py 이 코드를 리뷰하고 엣지 케이스나 보안 이슈를 찾아줘"
또 다른 자주 쓰는 패턴은 분석에서 구현으로 직결되는 흐름이다. 계획 단계가 단순할 때는 Claude를 건너뛰고 Gemini와 Codex만 묶어 빠르게 처리한다.
# 레포 전체 구조 파악 후 테스트 코드 자동 생성
find src -name "*.py" | xargs cat | gemini -p "이 코드베이스의 핵심 함수 목록과 시그니처를 추출해줘" > functions.md
codex --context "$(cat functions.md)" "각 함수에 대한 pytest 단위 테스트를 작성해줘" > test_suite.py
리버스 패턴도 유용하다. 코드부터 만든 뒤 문서로 정리하는 흐름이다.
# 구현 후 문서화
codex "GraphQL 서버에 Redis 기반 캐싱 레이어를 추가해줘" > cache_layer.py
gemini -p "이 코드의 동작 원리와 사용법을 한국어 기술 블로그 글로 정리해줘" < cache_layer.py > blog_post.md
세 모델을 모두 거치는 트라이앵글 패턴은 가장 정밀한 결과물이 필요할 때 쓴다. 분석은 Gemini, 설계와 검토는 Claude, 코드 작성은 Codex가 맡고, 마지막에 다시 Claude가 통합 검수를 한다. 시간과 비용이 더 들지만, 프로덕션 코드처럼 품질이 중요한 작업에서는 충분히 가치가 있다.
한 줄 셸 함수로 자동 라우팅 만들기
매번 수동으로 모델을 지정하는 게 번거로우면, 셸 함수나 스크립트로 자동 라우팅 규칙을 만들 수 있다. 작업 유형이나 입력 크기에 따라 적절한 CLI를 자동 선택하는 식이다.
# ~/.zshrc 또는 별도 스크립트에 추가
ai() {
local prompt="$1"
local input="$2"
# 입력이 큰 파일이면 Gemini
if [[ -f "$input" && $(wc -c < "$input") -gt 50000 ]]; then
gemini -p "$prompt" < "$input"
# 코드 생성 키워드면 Codex
elif [[ "$prompt" =~ (작성|구현|만들어|생성|리팩토링) ]]; then
codex "$prompt"
# 기본은 Claude
else
claude "$prompt"
fi
}
이런 셸 함수 한두 개만 있어도 일상적인 작업 흐름이 한층 매끄러워진다. 더 정교하게 만들고 싶다면 jq를 끼워 출력을 JSON으로 받아 후처리하거나, GitHub Actions에 통합해 PR 리뷰 자동화 파이프라인을 만들 수도 있다.
조금 더 발전한 형태로는 Claude Code의 슬래시 커맨드 또는 사용자 정의 스킬을 활용하는 방법이 있다. Claude Code 내부에서 /route 같은 커맨드를 정의해두면, 한 세션 안에서 자연어로 “이 작업은 Gemini로 보내줘”라고 지시할 수 있다. Claude가 알아서 외부 CLI를 호출하고 결과를 받아 다음 단계로 넘긴다.
컨텍스트가 새지 않게 하려면
체이닝의 가장 큰 함정은 컨텍스트 손실이다. 1단계에서 정확하게 추출된 스펙이 3단계 코드 생성 모델에게 제대로 전달되지 않으면, 결과 코드의 정확도가 급격히 떨어진다.
이를 막기 위한 두 가지 원칙이 있다. 첫째, 중간 결과를 항상 파일로 저장한다. 셸 변수에 담아 직접 넘기는 것보다 파일로 저장한 뒤 다음 단계에서 읽는 편이 안정적이다. 셸 변수는 길이 제한이 있고, 특수문자 이스케이프 문제로 깨지기 쉽다.
둘째, 모델에게 넘길 때는 명시적인 구조 표시를 사용한다.
=== 이전 단계 결과 (Gemini의 PRD 분석) ===
{스펙 내용}
=== 다음 단계 지시 ===
위 스펙에 따라 FastAPI 엔드포인트를 작성해줘. 다음 조건을 지킬 것:
- async/await 사용
- Pydantic v2 모델
- 에러 응답은 RFC 7807 형식
이렇게 명시적 구조를 갖춰 넘기면, 모델이 어디까지가 컨텍스트이고 어디서부터가 새 지시인지 헷갈리지 않는다. 특히 여러 단계를 거칠수록 이 구조화가 결과 품질에 미치는 영향이 커진다.
세 번째 팁은 단계별 검증이다. 자동 체이닝을 만들어두면 편하지만, 처음 셋업할 때는 단계마다 출력을 사람이 확인하고 다음 단계로 넘기는 게 안전하다. 어느 단계에서 품질이 떨어지는지 빠르게 파악할 수 있고, 그 단계의 프롬프트만 정밀하게 다듬으면 된다.
비용과 속도까지 챙기기
멀티 CLI를 쓰면 한 작업에 여러 API 호출이 발생하므로 비용이 신경 쓰일 수 있다. 다행히 적절한 모델을 적절한 자리에 배치하면 단일 모델보다 오히려 비용이 낮아지는 경우가 많다.
긴 문서 분석은 Gemini가 출력 단가가 가장 싸고, 코드 한 덩어리 생성은 Codex가 빠르고 효율적이다. 비싼 Claude Opus 4.7은 정말 정밀한 리뷰나 복잡한 추론이 필요한 단계에만 쓰는 식으로 분배하면, 같은 결과물을 더 적은 비용으로 얻을 수 있다. 실제로 동일 작업을 Claude 단독으로 처리할 때 대비 30~50% 비용 절감이 가능하다는 게 셋업 후 6개월간의 체감이다.
속도 면에서도 단일 모델로 모든 단계를 처리하는 것보다 분업이 빠른 경우가 많다. 분석은 Gemini Flash 변종으로 병렬 처리하고, 코드 생성은 Codex로 따로 돌리는 식으로 워크플로우를 짜면 토탈 시간이 줄어든다. 특히 분석과 구현이 명확히 분리되는 작업에서 효과가 크다.
비용 모니터링은 별도 도구를 쓰는 게 안전하다. OpenAI·Anthropic·Google 모두 사용량 대시보드를 제공하지만, 매일 한 번씩만 봐도 의외의 토큰 폭주를 잡을 수 있다. usage tracking 라이브러리(예: helicone, langfuse)를 끼워두면 어떤 단계가 가장 비용을 많이 먹는지 정량적으로 파악할 수 있다.
운영하면서 얻은 작은 팁들
지금까지 정리한 내용을 바탕으로, 실제로 운영하면서 얻은 작은 팁들을 덧붙인다.
API 키 대신 OAuth로 로그인하는 방식을 추천한다. 키를 발급받아 환경변수로 관리할 필요가 없고, 구독 요금제와 청구가 자연스럽게 묶이며, 키가 유출될 위험도 사라진다. CI 환경처럼 브라우저를 띄울 수 없는 자리에서만 키 방식을 쓰면 된다. CI에서도 GitHub Actions Secrets나 AWS Secrets Manager에 키를 저장하고 동적으로 로드하는 편이 안전하다.
각 CLI의 출력은 가능한 한 마크다운 형식으로 받아두는 게 좋다. 다음 단계 모델이 구조를 인식하기 쉽고, 사람이 중간 결과를 검토할 때도 가독성이 좋다. JSON 출력은 후처리할 일이 많을 때만 쓰는 게 낫다.
긴 작업을 돌릴 때는 tmux나 screen 같은 터미널 멀티플렉서 안에서 실행하는 걸 추천한다. SSH 연결이 끊겨도 작업이 중단되지 않고, 백그라운드로 돌리면서 다른 일을 병행할 수 있다.
마지막으로, 멀티 CLI는 모든 작업에 다 쓰는 게 아니다. 간단한 코드 한 줄 짜기나 빠른 질문에는 단일 CLI로 충분하다. 복잡한 멀티스텝 작업이나 큰 컨텍스트가 필요한 작업에서만 오케스트레이션을 발동하는 게 효율적이다. 도구는 어디까지나 도구다.
당분간 AI CLI 생태계는 더 다양해질 것이고, 한 모델만 깊게 파는 시대는 지나가고 있다. 모델별 강점을 이해하고 적절히 배치하는 능력, 그리고 그 흐름을 자동화할 수 있는 셋업을 갖추는 것이 곧 개발자의 새로운 기본기가 될 것 같다. 처음 셋업하는 데 한두 시간이면 충분하지만, 한 번 익숙해지면 작업 효율이 확연히 달라지는 것을 느낄 수 있다. 적합한 도구를 적합한 자리에 배치하는 단순한 원칙이지만, 그 차이가 만들어내는 결과물은 결코 작지 않다.
출처