Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 09. 05:10

Apple의 WWDC가 AI 모델 라우팅(Model Routing)에 대해 우리에게 가르쳐준 것

요약

Apple의 WWDC 발표를 통해 모델 소유보다 적절한 모델을 선택하고 통합하는 '모델 라우팅' 전략의 중요성을 분석합니다. 단일 모델에 의존하는 대신 작업 복잡도에 따라 온디바이스, 서버 측, 외부 모델을 계층적으로 활용하는 효율적인 아키텍처를 제안합니다.

핵심 포인트

  • 모든 작업에 고비용 프런티어 모델을 사용하는 것은 비효율적임
  • 작업의 복잡도에 따라 모델을 배분하는 라우팅 계층 구축 필요
  • 모델 라우팅을 통해 품질 저하 없이 운영 비용을 70% 이상 절감 가능
  • Apple의 전략처럼 온디바이스와 외부 모델의 하이브리드 활용 권장

오늘 WWDC 2026에서 Apple은 올해 AI 전략에서 가장 중요한 신호가 될 수도 있는 것을 발표했습니다. 그리고 그것은 Siri AI도, macOS Golden Gate도, iOS 27도 아니었습니다.

Apple은 자체 파운데이션 모델(Foundation Model)을 구축하지 않기로 선택했습니다.

Apple이 2년 동안 공들여온 근본적인 재구축 작업인 Siri AI는 Google의 Gemini 모델 위에서 작동합니다. 세계에서 가장 가치 있는 이 기업은 모델의 '소유(Ownership)'보다 모델의 '선택과 통합(Selection and Integration)'이 더 중요하다는 결정을 내렸습니다.

이는 모든 개발자가 AI를 생각하는 방식을 바꿔 놓아야 합니다.

"단일 모델(One Model)"의 함정

오늘날 대부분의 팀은 단일 모델을 선택하고 모든 것을 그 모델을 통해 라우팅(Routing)합니다. 코딩에는 Claude, 채팅에는 GPT, 멀티모달(Multimodal)에는 Gemini를 사용합니다. 그러고 나서 왜 비용이 천문학적으로 발생하거나 출력 품질이 일관되지 않은지 의아해합니다.

Microsoft는 Claude Code가 보조해야 할 인간보다 더 많은 비용이 든다는 사실을 깨달은 후, 엔지니어들의 Claude Code 사용을 방금 금지했습니다. 이번 주 여러 Reddit 스레드에 따르면, 개발자들이 API 토큰 비용으로 12만 달러(약 1억 6천만 원) 이상을 청구하거나, 집중적인 사용 10일 만에 인사팀(HR)에 호출되는 사례가 나타나고 있습니다.

문제는 모델이 아닙니다. 하나의 모델이 모든 작업에 적합하다는 가정입니다.

Apple이 옳았던 점

Siri AI에 대한 Apple의 접근 방식은 본질적으로 라우팅 계층(Routing Layer)입니다:

  • 온디바이스 모델(On-device models)은 간단한 쿼리(개인정보 보호, 즉각적 응답)를 처리합니다.
  • Apple 자체의 서버 측 모델(Server-side models)은 중간 단계의 작업을 처리합니다.
  • Gemini는 복잡한 추론(Reasoning)과 생성(Generation)을 처리합니다.

각 쿼리는 작업에 맞는 '적절한 크기(Right-sized)'의 모델로 전달됩니다. 타이머 요청에는 1조 개의 파라미터를 가진 모델이 필요하지 않습니다. 하지만 복잡한 연구 질문에는 필요합니다.

이는 AI 코딩 도구에서 나타나고 있는 것과 동일한 아키텍처 패턴입니다:

작업필요한 것대부분의 사람들이 사용하는 것
계획/설계 (Planning/Architecture)강력한 추론 (Opus/o3-level)모든 것에 Opus 사용
...

패턴이 보이시나요? 상용구(Boilerplate) 코드를 작성하는 데 프런티어 모델(Frontier Model)을 사용하는 것은 식료품을 사러 가기 위해 Ferrari를 사용하는 것과 같습니다. 작동은 하겠지만, 경제성이 떨어집니다.

내 워크플로우를 바꾼 수학적 계산

저는 10개 이상의 앱을 운영하고 있으며, 작업의 복잡도에 따라 라우팅(Routing)을 시작하기 전에는 Claude Code에 매달 약 10,000달러를 지출하고 있었습니다:

  • 기획 단계 (Planning phase): Opus (아키텍처 결정에는 비용을 들일 가치가 있음)
  • 구현 (Implementation): Sonnet 4 (Opus 품질의 90%를 20%의 비용으로 구현)
  • 테스트 작성 (Test writing): Flash/Haiku (이것들은 패턴 매칭 (Pattern-matching) 작업임)
  • 디버깅 (Debugging): 복잡도에 따라 결정 — Flash로 시작하여 필요 시 단계적으로 격상

결과: 출력 품질의 측정 가능한 저하 없이 월 $10,000 → 약 $3,000로 감소했습니다. 절감액은 전적으로 _필요하지 않은 작업에 가장 비싼 모델을 사용하지 않음_으로써 발생했습니다.

이를 구현하는 방법

특별한 도구는 필요하지 않습니다. 필요한 것은 절제력입니다:

1. 프롬프트를 작성하기 전에 분류하세요

AI 코딩 도구에 작업을 보내기 전에 스스로에게 물으세요: "이 작업에 최첨단 지능 (Frontier intelligence)이 필요한가, 아니면 단순히 예측 가능한 코드를 생성하는 것인가?"

대부분의 작업은 "예측 가능한" 범주에 속합니다 — CRUD 엔드포인트, 테스트 스캐폴딩 (Test scaffolding), 설정 파일 (Config files), 마이그레이션 스크립트 등입니다.

2. 모델 계층 (Model Tiers)을 사용하세요

최소 두 개의 모델 계층으로 환경을 설정하세요:

# .env 또는 도구 설정
PLANNING_MODEL=claude-opus-4
IMPLEMENTATION_MODEL=claude-sonnet-4
...

처음에는 수동으로 라우팅하세요. 패턴은 빠르게 명확해집니다.

3. 최적화하기 전에 측정하세요

일주일 동안 작업 유형별 사용량을 추적하세요. 대부분의 개발자는 토큰의 60-70%가 더 저렴한 모델로도 충분히 처리할 수 있는 작업에 소비된다는 사실을 발견하게 됩니다.

4. 기본값이 아닌 격상 (Escalation) 방식

모든 작업을 합리적으로 가능한 가장 낮은 계층에서 시작하세요. 만약 Flash가 처리하지 못한다면 Sonnet으로 격상하세요. Sonnet이 어려워한다면 Opus를 투입하세요. 이 "격상 사다리 (Escalation ladder)\

매주 새로운 모델들이 등장합니다. DeepSeek, MiMo, Gemini, Claude, GPT — 지형은 끊임없이 변화합니다. 단 하나의 모델에 베팅하는 것은 패배하는 전략입니다. 지형이 진화함에 따라 모델을 교체할 수 있는 오케스트레이션 레이어 (Orchestration layer)를 구축하는 것? 그것이 바로 해자 (Moat)입니다.

세계에서 가장 가치 있는 기업이 모델 소유 (Model ownership)보다 모델 라우팅 (Model routing)이 더 낫다고 결정했다면, 어쩌면 여러분의 AI 스택 (AI stack)을 재고해야 할 시점일지도 모릅니다.

멀티 모델 워크플로 (Multi-model workflows)에 대한 여러분의 경험은 어떠신가요? 작업을 서로 다른 모델로 라우팅하고 계신가요, 아니면 여전히 모든 것에 하나의 모델을 사용하고 계신가요? 여러분의 방식을 댓글로 남겨주세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0