멀티모델 오케스트레이션: 각 작업에 최적 AI
E3 두 검토자 사각지대의 일반화 — 비교 우위 이론을 AI 모델에 적용
📑 이 챕터에서 다룰 내용
새 27장 (Managed Agents 정정렬)까지 끝났습니다. 이 장은 5확장 E3 (두 검토자 사각지대)의 일반화입니다. 새 8장에서 SPEC 검토에 Claude + Gemini 두 모델을 사용했는데, 이 장에서 그 사상을 모든 작업에 확장합니다.
| 📚 사전 지식 체크 | 🎯 이 장의 목적 | ✅ 완료 후 결과물 |
|---|---|---|
| OpenRouter 계정 / Claude Code 기본 / 새 8장 E3 두 검토자 패턴 인지 | 비교 우위 이론을 AI 모델에 적용 + Opus·Sonnet·Gemini·GPT-4o 전환 기준 + E3의 일반화로 멀티모델 정체성 박음 | OpenRouter 설정 + 작업별 모델 선택 기준 + /model 전환 실습 |
경제학자 리카도: "각 나라가 상대적으로 잘하는 것에 특화해 교역하면 모두가 이익을 본다."
포르투갈은 와인·직물 모두 영국보다 잘 만들지만, 와인에만 집중하고 직물은 영국에서 수입하면 두 나라 모두 이익입니다. 절대적으로 잘하는 것보다 상대적으로 더 잘하는 것에 집중하는 원리입니다.
AI 모델도 마찬가지입니다. Claude Opus가 모든 면에서 가장 뛰어나도, 단순 번역에 Opus를 쓰는 것은 낭비입니다.
세계 최고 골키퍼만으로 11명을 채우면 이길 수 없습니다. 골키퍼 1명, 나머지는 수비·미드·공격. 각자 포지션의 선수가 자기 역할을 할 때 팀이 강합니다.
- Opus = 전략가 (Spec·복잡 설계)
- Sonnet = 미드필더 (일반 BUILD·코드 구현)
- Gemini = 스카우터 (외부 검토·문서 분석)
- GPT-4o = 수비수 (버그 탐지·보안 검토)
- Haiku = 풋워크 (단순 반복·빠른 응답)
| 도구 | 멀티모델 방식 |
|---|---|
| fabriqa | 다중 에이전트 오케스트레이션 — Claude Code + Codex + Gemini CLI 결합 (이 영역의 전문) |
| specs.md | 3 flows (Simple / FIRE / AI-DLC) — 복잡도 따라 모델 선택 |
| Spec-Kit | agent-agnostic — Copilot · Claude · Gemini · Cursor 모두 |
| OpenRouter | API 통합 — 단일 키로 수십 모델 (이 장의 자리) |
| GSD | 86 skills + subagent마다 모델 전환 가능 |
5파일+의 멀티모델 = OpenRouter + Claude Code 직접 전환. 학습용 단순화입니다.
Claude Code만으로 프로젝트를 진행할 때 두 가지 불만이 생깁니다.
이유 1 — 비용
모든 작업에 Opus를 쓰면 비용이 빠르게 쌓입니다. 단순 코드 포맷 변환·주석 추가에도 복잡 설계와 같은 요금이 부과됩니다. 멀티모델 전략 적용 시 총비용 40~60% 절감이 가능합니다.
이유 2 — 맹점 (E3 본질)
Claude가 아무리 뛰어나도 Anthropic의 한 회사 AI입니다. 같은 방식으로 학습 = 같은 종류의 실수 가능성. 새 8장에서 다룬 E3 두 검토자 사각지대 패턴 — Claude만 / Gemini만 / 둘 다 (4+6+2)가 데이터로 입증됐습니다.
멀티모델 = E3의 일반화입니다. SPEC 검토뿐 아니라 모든 작업에 "한 모델 사각지대 회피"를 적용합니다.
비교 우위에 의한 비용 절감 (40~60%) + 사각지대 회피 (E3 일반화)
→ "비교 우위 + 두 검토자" — 멀티모델 정체성
이 정체성이 9개 표준 도구 중 fabriqa·specs.md만 집중 다루는 영역이고, 5파일+는 OpenRouter + Claude Code로 단순화해서 학습용으로 흡수합니다.
| 모델 | 비교 우위 (잘함) | 덜 적합 (약함) | 비용 (Opus 대비) |
|---|---|---|---|
| Claude Opus 4.6 | 복잡한 비즈니스 로직 · 장기 계획 · 일관성 · DB 설계 | 단순 포맷 변환 · 짧은 번역 (낭비) | 100% (기준) |
| Claude Sonnet 4.6 | 일반 기능 구현 · 버그 수정 · 리팩토링 | 복잡 멀티스텝 설계 (Opus보다 실수) | 20% |
| Claude Haiku 4.5 | 단순 질문 · 포맷 변환 · 빠른 응답 반복 | 복잡 추론 · 장문 코드 생성 어려움 | 5% |
| Gemini 3.1 Pro | 대용량 문서 분석 · 멀티모달 · 다른 회사 사각지대 | 응답 일관성 부족 · 코드 품질 들쭉날쭉 | 25% |
| GPT-4o | 코드 버그 패턴 탐지 · 보안 취약점 발견 | 깊은 아키텍처 설계 어려움 | 30% |
Gemini의 비교 우위 = 다른 회사 사각지대 (E3 본질).
GPT-4o의 비교 우위 = 보안·버그 패턴 탐지 (E3 보강).
Claude만 사용하면 두 회사의 사각지대를 모두 놓칠 가능성이 있습니다.
| 단계 | 작업 | 추천 모델 | 이유 |
|---|---|---|---|
| ① SPEC v1 | 작성 | Opus 4.6 | 복잡 비즈니스 로직 + 장기 일관성 |
| ② 외부 검토 1차 | Gemini 검토 | Gemini 3.1 | E3 다른 회사 사각지대 |
| ③ SPEC v2 | 패치 | Sonnet 4.6 | 단순 수정 작업 |
| ④ 사용자 직관 | 사용자 + Claude | Sonnet 4.6 | 대화 위주 |
| ⑤ 두 검토자 | Claude 시뮬 + Gemini | Opus + Gemini | E3 적용 |
| ⑥ PLAN v1→v2 | 작성 | Opus 4.6 | 복잡 의존성 + 시간 산식 |
| ⑦ REVIEW | 15가지 체크 | Opus 4.6 | 보안·아키텍처 |
| BUILD 일반 | 코드 구현 | Sonnet 4.6 | -80% 비용, 품질 충분 |
| BUILD DB 설계 | 스키마·RLS·인덱스 | Opus 4.6 | 보안 사고 100배 비용 |
| BUILD 보안 검토 | 코드 리뷰 | GPT-4o | 비교 우위 |
| BUILD 단순 작업 | 포맷·주석·번역 | Haiku 4.5 | -95% 비용 |
| BUILD 페르소나 (E5) | 콘텐츠 생성 | Sonnet 4.6 + cache | E5 cache_control |
비용 시뮬레이션 — 줍줍 Phase 1
[전부 Opus 사용 가정] SPEC + PLAN + REVIEW + BUILD 25개 기능 누적 토큰: 약 3,000만 토큰 Opus 비용: $300 (가정) [멀티모델 전략 적용] SPEC + PLAN + REVIEW (Opus): $80 일반 BUILD 70% (Sonnet): $50 DB 설계·보안 (Opus): $30 보안 검토 (GPT-4o): $15 단순 작업 30% (Haiku): $5 검토 (Gemini): $20 합계: $200 → 33% 절감 + E3 일반화
## 모델 사용 정책 ### SPEC·PLAN·REVIEW (Opus 4.6) - /model claude-opus-4-6 + /effort high - 복잡 비즈니스 로직 (정부 지원금 카테고리 분류·매칭 알고리즘) - DB 설계 (4 테이블 + 트리거 + UNIQUE 제약) - 회색지대 결정 (E1 두 결정) ### Gemini 1차 + 두 검토자 (Gemini 3.1) - 외부 검토 (E3 첫 라운드 + 두 번째 라운드) - "다른 회사 사각지대" 가치 활용 ### BUILD 일반 (Sonnet 4.6) - /model claude-sonnet-4-6 + /effort medium - LLM 분류 프롬프트 작성 - React Native 컴포넌트 (목록·카드·필터) - Edge Functions (cron 스케줄링) ### BUILD 보안 검토 (GPT-4o) - /model openai/gpt-4o - Stripe 결제 통합 검토 (Phase 2) - RLS 정책 검토 - API 키 노출 검사 ### BUILD 단순 작업 (Haiku 4.5) - /model claude-haiku-4-5 + /effort low - 행정구역 코드 JSON 가공 - 약관·개인정보처리방침 마크다운 정렬 - 시딩 데이터 fixture 생성 ### LLM 분류 파이프라인 (Sonnet 또는 Haiku) - 공공데이터 API 응답 → JSON 분류 - confidence 0.7 임계값 검증 - 일일 50건 처리 — Haiku로 비용 최소화
TSV의 다중 페르소나 시스템 (E5)은 페르소나마다 다른 모델 사용이 가능합니다.
## Persona Model Policy ### STAT (통계학자) — Sonnet 4.6 - 정량 분석 위주, 일반 패턴 매칭 - cache_control 적용 (system prompt 캐시) - 비용: 일 $1.5 (5리그 × 1글) ### OBSERVER (신중한 관찰자) — Sonnet 4.6 - 균형 어법, 일반 분석 - cache_control 적용 - 비용: 일 $1.5 ### COACH (전술 분석, Phase 1.1+) — Opus 4.6 - 복잡 전술·내러티브 — 비교 우위 - 깊은 분석 가치 → Opus 정당화 - 비용: 일 $3 (5리그 × 1글) ### INSIDER (트레이딩·이적, Phase 1.2+) — Opus 4.6 - 복합 정보 합성 (다중 소스) - Opus 정당화 ### 자동 일관성 테스트 — GPT-4o - 5 페르소나 간 사실 일치 검증 - 보안·일관성 패턴 탐지 비교 우위 - 일주일 1회 실행 (정기 점검) ### Day 14 가설 검증 (CRITICAL 게이트) — Opus + Gemini - E3 두 검토자 적용 - 다관점 클릭률 데이터 + 사용자 행동 분석 - Opus = 비즈니스 메타 분석 - Gemini = 다른 회사 사각지대 (사용자 패턴 다른 시각)
페르소나마다 다른 모델 = E5 콘텐츠 SSOT 시스템의 자연스러운 멀티모델 적용입니다. SSOT 인터페이스는 단일이지만 출력 품질·비용은 페르소나 가치에 비례해 분배됩니다.
OpenRouter는 하나의 API 키로 Claude·Gemini·GPT 등 수십 모델을 통합합니다. 각 회사 API를 따로 계약·관리할 필요가 없습니다.
설정
# openrouter.ai → 가입 → API Keys → 충전 export OPENROUTER_API_KEY='sk-or-v1-...' # Claude Code 세션 중 즉시 전환 /model claude-opus-4-6 # SPEC·DB·복잡 알고리즘 /model claude-sonnet-4-6 # 일반 BUILD (기본) /model claude-haiku-4-5 # 단순 반복 /model google/gemini-pro-1.5 # SPEC 외부 검토 /model openai/gpt-4o # 보안·버그 검토
CLAUDE.md §7 Common Commands에 추가
## 7. Common Commands ### 모델 전환 - /model claude-opus-4-6 + /effort high (SPEC·PLAN·REVIEW) - /model claude-sonnet-4-6 + /effort medium (BUILD 일반) - /model claude-haiku-4-5 + /effort low (단순 반복) - /model google/gemini-pro-1.5 (외부 검토 - E3) - /model openai/gpt-4o (보안·버그 검토)
매 세션 자동 입력하면 Claude가 "어느 작업에 어느 모델"을 자동 추천합니다.
[질문 1] 복잡한 설계 / 비즈니스 로직 / 보안 코드? YES → 질문 2 NO → 질문 3 [질문 2] 외부 검토가 필요한가? YES → Gemini 사용 (E3 사각지대) NO → 질문 2-1 [질문 2-1] 보안 / 버그 패턴 검토가 핵심인가? YES → GPT-4o (비교 우위) NO → Opus 4.6 [질문 3] 단순 반복 / 포맷 변환 / 짧은 번역? YES → Haiku 4.5 (-95% 비용) NO → 질문 4 [질문 4] 일반 기능 구현 / 코드 리팩토링? YES → Sonnet 4.6 (-80% 비용) NO → Opus 4.6 (기본값)
이 트리를 CLAUDE.md §7에 박아두면 매 작업마다 Claude가 자동 추천합니다.
Phase 1 첫 BUILD 단계라면 Sonnet 단일로 충분합니다. 멀티모델은 학습 부담을 추가합니다 — 1인 운영자에게 처음부터 적용하는 것은 과도합니다.
도입 신호:
- SPEC 검토 시 "맹점을 확인하고 싶다" (E3) → Gemini 시작
- 보안 코드 리뷰 필요 → GPT-4o 시작
- 비용 최적화 압박 → Haiku 시작
- Phase 2+ 앱 복잡도 증가 → 자연 도입
Phase 1 안정 가동 후 (Day 30~33+) 단계적으로 확장하세요. E2 1인 페이스 보호 = 처음부터 모든 모델 도입 금지.
줍줍·TSV 도입 타이밍
| 프로젝트 | Phase 1 | Phase 1.1 | Phase 2 |
|---|---|---|---|
| 줍줍 (10주) | Sonnet 단일 | + Gemini (외부 검토 위주) | + GPT-4o (Stripe 보안) + Haiku |
| TSV (33일) | Opus + Sonnet 2개 | + Gemini (Day 14 가설 검증) | + GPT-4o (자동 일관성) |
TSV는 처음부터 2개 모델 (페르소나 시스템 정체성)로 시작합니다. 줍줍은 단일 시작 후 점진 확장합니다.
📌 새 28장 정리
- 핵심 한 줄: 멀티모델 = 비교 우위 + E3 사각지대 회피. 모든 작업에 Opus는 낭비. OpenRouter + /model 전환.
- 5확장 E3의 일반화: 새 8장 SPEC 검토 12건 (4+6+2 패턴)이 데이터 입증. 이 장은 모든 작업에 두 모델 사상 확장.
- 5명 모델 비교 우위: Opus (복잡 비즈니스·DB, 100%) / Sonnet (일반 BUILD, 20%) / Haiku (단순 반복, 5%) / Gemini (다른 회사 사각지대, 25%) / GPT-4o (보안·버그, 30%)
- 5파일+ 사이클의 모델 매핑: SPEC·PLAN·REVIEW (Opus) / 외부 검토 (Gemini) / BUILD 일반 (Sonnet) / DB·보안 (Opus) / 보안 검토 (GPT-4o) / 단순 작업 (Haiku)
- 비용 절감: 멀티모델 적용 시 총비용 40~60% 절감.
- E2 1인 페이스 보호: Phase 1 처음엔 Sonnet 단일. 점진 확장.
- 다음 장: 새 33장 — 자유 창작 준비