콘텐츠로 이동

29. 멀티 모델 협업 — 세 가지 시선으로 보기

모델 하나만 쓰면 한쪽 시각에 갇히기 쉬워요. 여러 모델을 함께 쓰면 같은 문제를 다른 각도에서 볼 수 있어요.

"중요한 결정일수록, 다른 관점이 필요합니다"

왜 여러 모델을 함께 쓰나?

코드 리뷰를 혼자 하면 자기 편향에 빠지기 쉬워요. AI도 마찬가지예요. 각 모델은 학습 데이터와 아키텍처가 달라서 같은 코드를 보고도 다른 점을 지적해요.

실제로 이 온보딩 사이트의 v1.8.0 개편 계획도 Gemini의 리뷰를 거쳐 7가지 개선사항이 추가되었어요.

모델별 특성

모델 강점 적합한 작업
Claude 오케스트레이션, 코드 생성, 복잡한 맥락 이해, 긴 코드 처리 구현, 리팩토링, 종합 판단
Codex 한 관점에서의 깊은 분석, 엣지 케이스 탐지 코드 리뷰, 버그 찾기, 보안 분석
Gemini 다양한 관점, 넓은 탐색, 대안 제시, 최신 정보 아키텍처 리뷰, 기술 조사, 문서 검토

각 모델의 강점은 고정된 게 아니라 계속 변해요. 중요한 건 여러 시선으로 교차 검증하는 습관입니다.

/ask로 다른 모델에게 질문하기

Claude Code 안에서 다른 모델에게 바로 질문할 수 있어요. /ask는 oh-my-claudecode(OMC)가 제공하는 스킬이에요.

/ask codex "이 함수에서 빠진 엣지 케이스 찾아줘"

/ask gemini "이 아키텍처 설계의 장단점을 분석해줘"

실전 예제: 코드 리뷰

# 1. Codex에게 엣지 케이스 분석 요청
/ask codex "src/auth/token.ts의 refreshToken 함수를 리뷰해줘.
특히 race condition, 타임아웃, 에러 핸들링 빠진 부분 찾아줘"

# 2. Gemini에게 설계 관점 리뷰 요청
/ask gemini "현재 토큰 갱신 로직이 인메모리 캐시를 쓰고 있어.
분산 환경으로 확장할 때 어떤 문제가 생길 수 있고, 대안은 뭐가 있어?"

# 3. Claude가 두 리뷰를 종합해서 최종 판단
"Codex와 Gemini 리뷰 결과를 종합해서 우선순위를 정하고,
가장 중요한 것부터 수정해줘"

네이티브 CLI 연동

oh-my-claudecode의 /ask 외에도 각 모델 CLI를 직접 사용할 수 있어요.

Codex CLI (OpenAI)

# 설치 — 공식 문서에서 최신 설치 방법을 확인하세요
# https://github.com/openai/codex
npm install -g @openai/codex

# 파이프로 코드 전달
cat src/auth/token.ts | codex -q "이 코드의 엣지 케이스를 찾아줘"

Gemini CLI (Google)

# 설치 — Google 공식 패키지입니다
npm install -g @google/gemini-cli

# 파이프로 코드 전달
cat src/auth/token.ts | gemini -p "이 코드의 아키텍처를 리뷰해줘"

CLI를 직접 사용하면 더 세밀한 제어가 가능하지만, Claude Code 컨텍스트가 전달되지 않아요. 프로젝트 맥락이 필요하면 /ask를 사용하세요.

주의: CLI 도구들은 자주 업데이트됩니다. 설치 전에 각 도구의 공식 저장소에서 최신 설치 방법을 확인하세요.

/ccg — 트라이 모델 오케스트레이션

/ccg는 Claude, Codex, Gemini 세 모델에 동시에 질문해서 결과를 종합하는 oh-my-claudecode 스킬이에요.

/ccg "이 인증 미들웨어의 보안 취약점을 찾아줘"

동작 원리

           ┌─→ Claude ─→ 분석 결과 A ─┐
질문 ───────┼─→ Codex  ─→ 분석 결과 B ─┼─→ Claude가 종합 → 최종 답변
           └─→ Gemini ─→ 분석 결과 C ─┘
  1. 같은 질문을 세 모델에 병렬로 전송
  2. 각 모델 응답 수집
  3. Claude가 세 응답을 종합해 최종 답변 생성

언제 사용하나?

상황 /ccg 사용 단일 모델 사용
중요 아키텍처 결정 ✅
보안 리뷰 ✅
기술 스택 선택 ✅
간단한 버그 수정 ✅
일상적인 코드 작성 ✅
단순 리팩토링 ✅

합의 기반 의사결정 패턴

멀티 모델 협업에서 중요한 건 합의(consensus)예요.

패턴: 질문 → 비교 → 종합

# Step 1: 각 모델에게 같은 질문
/ask codex "Redis vs Memcached, 우리 프로젝트에 뭐가 맞아?"
/ask gemini "Redis vs Memcached, 우리 프로젝트에 뭐가 맞아?"

# Step 2: Claude에게 종합 요청
"Codex는 Redis를, Gemini는 Memcached를 추천했어.
각각의 근거를 비교하고, 우리 상황에 맞는 최종 추천을 해줘.
우리는 단일 서버, 10만 DAU, 세션 캐싱 용도야."

의견이 갈릴 때

세 모델이 모두 같은 답을 하면 확신이 높아지고, 갈리면 더 깊이 파야 한다는 신호예요.

합의 수준 해석 행동
3/3 동의 높은 확신 바로 진행
2/1 분리 중간 확신 소수 의견의 근거 검토
모두 다름 낮은 확신 더 구체적인 컨텍스트 제공 후 재질문

비용과 한계

멀티 모델은 유용하지만 공짜가 아니에요.

항목 주의사항
API 비용 3모델 동시 호출 시 비용 3배 이상
Rate Limit Codex/Gemini CLI 무료 티어는 호출 한도가 있음
토큰 한도 긴 코드를 보낼 때 각 모델의 컨텍스트 윈도우 차이에 주의
프롬프트 호환성 Claude에 통하는 프롬프트가 다른 모델에선 다르게 작동할 수 있음
응답 시간 3모델 병렬이라도 가장 느린 모델이 병목

프롬프트 호환성 팁

각 모델은 프롬프트 스타일에 반응하는 방식이 달라요:

# Claude에 최적화된 프롬프트
"다음 코드를 리뷰해줘. 특히 보안 취약점과 성능 이슈에 집중해줘."

# Codex에 최적화
"Review the following code. Focus on: 1) Security vulnerabilities 2) Performance issues"

# Gemini에 최적화
"Analyze this code from multiple perspectives: security, performance, maintainability."

중요한 리뷰에서는 각 모델의 강점에 맞게 프롬프트를 조정하면 더 좋은 결과를 얻을 수 있어요.

언제 단일 모델이면 충분한가

모든 작업에 멀티 모델이 필요하진 않아요.

단일 모델이 적합한 경우: - 명확한 구현 작업 (함수 작성, 버그 수정) - 반복적인 작업 (테스트 추가, 리팩토링) - 빠른 답변이 필요한 경우

멀티 모델이 적합한 경우: - 되돌리기 어려운 결정 (아키텍처, 기술 스택) - 보안이 중요한 코드 - 팀에 영향을 미치는 설계 변경

경험칙: "이 결정이 틀리면 며칠 이상 되돌리기 어려운가?" 그렇다면 멀티 모델을 고려하세요.

다음 단계