이종 LLM 아키텍처로 에이전트 플릿 비용 90% 절감하기

에이전트 플릿을 운영하는 엔지니어링 팀이라면 누구나 마주하는 현실이 있다. 매일 수천 건의 LLM 호출이 쌓이고, 월말이 되면 예상을 훨씬 초과하는 API 청구서를 받는 것이다. Claude Opus나 GPT-5.3 같은 최상위 모델로 모든 작업을 처리하면 품질은 보장되지만, 비용은 감당하기 어려운 수준이 된다.

하지만 실제로 에이전트 시스템의 모든 작업이 최상위 모델을 필요로 하지는 않는다. 이 글에서는 EM과 CTO가 알아야 할 이종 LLM 아키텍처(Heterogeneous LLM Architecture) 전략을 통해 품질을 유지하면서 비용을 최대 90%까지 절감하는 방법을 다룬다.

왜 단일 모델 전략이 실패하는가

대부분의 팀이 에이전트 시스템을 처음 구축할 때 가장 강력한 모델 하나를 선택해 모든 작업에 사용한다. 이는 이해할 수 있는 접근법이다. 빠르게 프로토타입을 만들고, 품질 걱정 없이 기능을 검증할 수 있다.

문제는 프로덕션 규모에서 시작된다.

예를 들어 하루 10,000건의 에이전트 태스크를 처리하는 시스템을 생각해보자. Claude Opus 4.6으로 모든 작업을 처리하면 일일 비용은 $800〜$1,300 수준이다. 이를 연간으로 환산하면 $300,000〜$500,000에 달한다. 스타트업이나 중소기업에는 상당한 부담이다.

하지만 그 10,000건 중 실제로 최상위 모델의 추론 능력이 필요한 작업은 얼마나 될까? 대부분의 시스템에서 분석해보면, 복잡한 전략적 추론이 필요한 작업은 10〜20%에 불과하다. 나머지 80〜90%는 데이터 포맷팅, 텍스트 분류, 간단한 요약, 라우팅 결정처럼 훨씬 소형 모델로도 충분히 처리할 수 있다.

이종 LLM 아키텍처의 핵심 개념

이종 LLM 아키텍처의 핵심은 작업의 복잡도에 맞는 모델을 선택하는 것이다. 모든 음식을 가장 비싼 식재료로 요리하지 않듯이, 모든 AI 태스크에 가장 강력한 모델을 쓸 필요는 없다.

일반적으로 3계층 모델 구조를 사용한다:

계층 1: 프론티어 모델 (Frontier Model)

• 대상: Claude Opus 4.6, GPT-5.3, Gemini 3.1 Pro
• 사용 사례: 복잡한 전략 수립, 멀티스텝 추론, 코드 아키텍처 설계, 모호한 요구사항 해석
• 비용: 높음 (전체 호출의 10〜20%에만 사용)

계층 2: 미드티어 모델 (Mid-tier Model)

• 대상: Claude Sonnet 4.6, GPT-4o, Gemini 1.5 Flash
• 사용 사례: 문서 요약, 코드 리뷰, 비교적 단순한 데이터 분석, 언어 번역
• 비용: 중간 (전체 호출의 30〜40%에 사용)

계층 3: 소형 모델 (Small Language Model)

• 대상: Claude Haiku 4.5, GPT-4o-mini, Phi-3, Qwen3-Coder
• 사용 사례: 라우팅 결정, 텍스트 분류, 포맷 변환, 키워드 추출, 간단한 Q&A
• 비용: 낮음 (전체 호출의 40〜60%에 사용)

Plan-Execute 패턴: 가장 효과적인 이종 아키텍처

이종 아키텍처 중 가장 임팩트가 큰 것은 Plan-Execute 패턴이다. 이 패턴은 두 단계로 나뉜다:

플래닝 단계 (Planning Phase) 프론티어 모델이 전체 작업을 분석하고, 세부 실행 계획을 수립한다. 어떤 서브 태스크로 나눌지, 각 서브 태스크에 어떤 도구와 데이터가 필요한지, 예상되는 엣지 케이스는 무엇인지를 명세화한다.

실행 단계 (Execution Phase) 플래닝 단계에서 생성된 명세에 따라 각 서브 태스크를 소형 모델이 실행한다. 이미 무엇을 해야 하는지 명확히 정의되어 있으므로, 소형 모델도 충분히 정확하게 수행할 수 있다.

이 패턴의 비용 절감 효과는 극적이다. 프론티어 모델 사용을 전체 작업의 5〜10%로 줄이고, 나머지 90〜95%를 소형 모델로 처리하면 비용을 최대 90% 절감할 수 있다는 연구 결과가 있다.

# Plan-Execute 패턴 구현 예시
import anthropic

class HeterogeneousAgentFleet:
    def __init__(self):
        self.client = anthropic.Anthropic()
        # 비용 계층별 모델 정의
        self.planner_model = "claude-opus-4-6"      # 프론티어: 복잡한 계획
        self.executor_model = "claude-haiku-4-5-20251001"  # 소형: 실행
        self.reviewer_model = "claude-sonnet-4-6"   # 미드티어: 검증

    def plan_task(self, task: str) -> dict:
        """프론티어 모델로 실행 계획 수립"""
        response = self.client.messages.create(
            model=self.planner_model,
            max_tokens=1024,
            messages=[{
                "role": "user",
                "content": f"""다음 작업을 작은 서브태스크로 분해하고,
                각 서브태스크의 실행 명세를 JSON으로 반환하라.
                작업: {task}

                형식: {{"subtasks": [{{"id": 1, "instruction": "...", "expected_output": "..."}}]}}
                """
            }]
        )
        return self._parse_plan(response.content[0].text)

    def execute_subtask(self, subtask: dict) -> str:
        """소형 모델로 개별 서브태스크 실행"""
        response = self.client.messages.create(
            model=self.executor_model,
            max_tokens=512,
            messages=[{
                "role": "user",
                "content": f"""지시사항: {subtask['instruction']}
                기대 출력 형식: {subtask['expected_output']}"""
            }]
        )
        return response.content[0].text

    def run(self, task: str) -> list:
        """전체 Plan-Execute 파이프라인 실행"""
        plan = self.plan_task(task)  # 비용: ~$0.015 (Opus 1회)
        results = []
        for subtask in plan["subtasks"]:
            result = self.execute_subtask(subtask)  # 비용: ~$0.0003 (Haiku 1회)
            results.append(result)
        return results

라우팅 레이어: 올바른 모델을 선택하는 자동화

이종 아키텍처에서 핵심적인 또 다른 컴포넌트는 라우팅 레이어다. 모든 요청을 올바른 계층으로 자동 분류하는 시스템이 없으면, 결국 개발자가 수동으로 모델을 선택해야 하는 오버헤드가 발생한다.

효과적인 라우팅 레이어는 다음 기준을 자동으로 판단한다:

1. 복잡도 판단: 요청이 멀티스텝 추론을 필요로 하는가?
2. 도메인 특수성: 특화된 지식이나 세밀한 판단이 필요한가?
3. 컨텍스트 길이: 긴 컨텍스트 처리가 필요한가?
4. 정확도 요구: 실수가 허용되지 않는 고위험 작업인가?

재미있는 점은 라우팅 판단 자체도 소형 모델로 처리할 수 있다는 것이다. 단순한 분류 작업이기 때문이다.

def route_request(self, request: str) -> str:
    """소형 모델로 라우팅 결정 — 비용 최소화"""
    routing_response = self.client.messages.create(
        model=self.executor_model,  # Haiku 사용
        max_tokens=50,
        messages=[{
            "role": "user",
            "content": f"""다음 요청의 복잡도를 분류하라.
            응답은 반드시 "frontier", "mid", "small" 중 하나만.

            요청: {request}

            분류 기준:
            - frontier: 전략 수립, 복잡한 코드 설계, 모호한 요구사항 분석
            - mid: 문서 작성, 코드 리뷰, 데이터 분석
            - small: 분류, 포맷 변환, 키워드 추출, 간단한 Q&A"""
        }]
    )
    tier = routing_response.content[0].text.strip().lower()
    return {"frontier": self.planner_model,
            "mid": self.reviewer_model,
            "small": self.executor_model}.get(tier, self.reviewer_model)

실전 비용 비교: Before vs After

실제 프로덕션 시스템에서 이종 아키텍처 적용 전후를 비교해보면:

[Before: 단일 모델 전략]

• 일일 API 호출: 10,000건
• 모두 Claude Opus 4.6 사용
• 평균 입력 1,000 토큰, 출력 500 토큰
• 일일 비용: ~$900

[After: 이종 모델 아키텍처]

• Frontier (Opus) 10%: 1,000건 × $0.09 = $90
• Mid-tier (Sonnet) 35%: 3,500건 × $0.009 = $31.5
• Small (Haiku) 55%: 5,500건 × $0.00063 = $3.5
• 일일 총 비용: ~$125

결과: 86% 비용 절감, 월 $23,000 절약

물론 실제 수치는 작업 분포와 토큰 사용량에 따라 다르다. 하지만 대부분의 에이전트 시스템에서 50〜90%의 비용 절감은 충분히 현실적인 목표다.

EM/CTO가 실행해야 할 3단계 전환 전략

이론은 알겠지만, 어떻게 현재 시스템을 이종 아키텍처로 전환할까? 다음 3단계를 권장한다:

1단계: 현재 사용 패턴 분석 (1주)

• API 로그에서 호출 유형별 분류 (어떤 종류의 요청이 가장 많은가?)
• 복잡도별 분포 파악 (단순 vs 복잡 비율)
• 현재 비용의 병목 지점 식별

2단계: 파일럿 라우팅 구현 (2〜3주)

• 가장 단순한 20%의 작업을 소형 모델로 마이그레이션
• 품질 지표(정확도, 사용자 피드백) 모니터링
• 점진적으로 범위 확대

3단계: 완전한 이종 아키텍처 구축 (1〜2개월)

• 자동 라우팅 레이어 구현
• Plan-Execute 패턴 적용
• 비용 대시보드 구축 및 지속적 최적화

품질을 지키면서 비용을 줄이는 핵심 원칙

비용 절감에만 집중하다가 품질이 떨어지면 의미가 없다. 품질을 유지하는 핵심 원칙은 다음과 같다:

명세의 명확성이 모델 능력을 대체한다: 소형 모델이 실패하는 이유는 대개 모델 능력의 한계가 아니라 불명확한 지시사항 때문이다. 플래닝 단계에서 충분히 구체적인 명세를 만들면, 소형 모델도 고품질 결과를 낼 수 있다.

폴백 메커니즘을 구현하라: 소형 모델이 명세를 만족하는 결과를 내지 못하면, 자동으로 상위 계층 모델로 재시도하는 로직을 추가한다. 전체 호출의 5〜10%만 폴백이 발생해도 비용 절감 효과는 여전히 크다.

비용과 품질의 트레이드오프를 모니터링하라: 이종 아키텍처 도입 후 품질 지표를 기존 대비 측정하고, 비용 절감 대비 품질 손실이 수용 가능한 수준인지 지속적으로 검증한다.

마무리

에이전트 플릿 운영의 경제성은 팀이 AI를 얼마나 전략적으로 활용할 수 있는지를 결정짓는다. 무한정 비용을 쏟아부을 수 없다면, 이종 LLM 아키텍처는 선택이 아닌 필수가 되어가고 있다.

모든 작업에 최상위 모델을 사용하는 것은 모든 이메일을 전문 작가에게 맡기는 것과 같다. 중요한 제안서나 계약서는 전문가에게, 일상적인 업무 소통은 직접 처리하는 것처럼, AI 에이전트 시스템도 작업의 중요도와 복잡도에 맞게 모델을 선택해야 한다.

2026년의 엔지니어링 리더는 “어떤 모델을 쓸까?”가 아니라 “어떤 작업에 어떤 모델을 최적으로 배치할까?”를 고민하는 아키텍트여야 한다.