AI 에이전트 생태계 최적화: 고부하 워크로드를 위한 비용 인식 LLM 라우터 구축

Originally published on tamiz.pro.

대규모 언어 모델(LLM) 기능이 확장됨에 따라, AI 에이전트와 관련된 재정적 책임도 커지고 있습니다. 현대 소프트웨어 시스템은 단일 모델에 의존하는 경우가 드물며, 대신 거대한 최신 아키텍처부터 가볍고 빠르며 오픈 웨이트 대안까지 다양한 전문 모델들을 오케스트레이션합니다. 하지만 대부분의 현재 구현체는

전통적인 소프트웨어 엔지니어링에서 최적화는 보통 지연 시간(Latency, 속도)이나 정확성(Accuracy, 올바름)을 목표로 합니다. 하지만 LLM 기반 시스템에서는 세 번째의 중요한 축인 **비용(Cost)**이 추가됩니다. 비용 인식 라우터(cost-aware router)는 LLM API를 이질적인 제약 조건(heterogeneous constraints)을 가진 리소스 풀처럼 취급합니다. 단순히 '가장 저렴한' 모델을 선택하는 것이 아니라, 요청의 _복잡성(complexity)_에 맞춰 해결하는 데 필요한 _최소 역량 수준(capability floor)_을 매핑하는 것입니다.

고객 지원 에이전트를 예로 들어보겠습니다. 문의의 80%는

• 분류기 출력 (Classifier Output): 의도 태그(Intent Tags) (예: 요약, 코드 디버깅, 잡담, 수학), 그리고 복잡성 점수 (Complexity Score) (0.0에서 1.0 사이).
• 컨텍스트 길이 (Context Length): 시스템 프롬프트 + 사용자 프롬프트 + 히스토리 컨텍스트의 추정 토큰 수.

레이어 2: 정책 엔진 (Policy Engine)

이것은 라우터의

1. 프롬프트 엔트로피(Prompt Entropy): 무작위적이고 일관성 없는 프롬프트(높은 엔트로피)는 처리하기 어렵습니다. 구조화된 프롬프트(낮은 엔트로피)가 더 쉽습니다.
2. 키워드 휴리스틱스(Keyword Heuristics): "debug", "logic error", "prove", 또는 "architect"와 같은 용어의 존재는 점수를 높입니다. 반면, "hello", "summarize this text", 또는 "rewrite"와 같은 용어는 점수를 낮춥니다.
3. 컨텍스트 볼륨(Context Volume): 토큰 수가 저가 모델의 컨텍스트 창 한계에 가까워질수록, 복잡도 점수(complexity score)를 인위적으로 높여 더 큰 컨텍스트 창을 가진 모델로 라우팅하도록 강제해야 합니다.

이 공식은 가중치 합산입니다:
Complexity Score = 0.4 * Intent_Weight + 0.3 * Context_Volume_Norm + 0.3 * Semantic_Entropy

• Intent_Weight: code_debug/math의 경우 1.0, summarize의 경우 0.2입니다.
• Context_Volume_Norm: Total_Tokens / 4096 (최대 1.0으로 제한).
• Semantic_Entropy: 로컬에서 빠른 n-gram 모델을 사용하여 계산합니다.

4. 코드 예시: 라우팅 엔진(The Routing Engine)

당신의 에이전트와 LLM 제공업체 사이에 위치하는 Python 기반의 라우팅 엔진을 구축해 보겠습니다. 이 예시는 openai, anthropic 및 로컬 ollama 인스턴스를 사용하는 다중 공급자 설정을 가정합니다.

import time
import json
from typing import List, Dict, Optional
...

5. 프로덕션 고려 사항: 캐싱 및 장애 조치(Failover)

순수하게 반응적인 라우터만으로는 프로덕션 환경에 충분하지 않습니다. 두 가지 중요한 구성 요소가 추가되어야 합니다:

시맨틱 캐싱(Semantic Caching)

많은 에이전트 작업은 반복적입니다. 만약 사용자가 "방화벽을 어떻게 설정하나요?"라고 여러 번 묻는다면, 첫 번째 요청은 Standard Model로 라우팅하고 응답을 시맨틱 키를 가진 벡터 데이터베이스에 캐시할 수 있으며, 이후 유사한 쿼리는 캐시에서 가져오기(Return From Cache) 경로(비용: $0)로 라우팅합니다. 이는 비용 소모율(burn rate)을 극적으로 개선합니다.

장애 조치 전략(Failover Strategy)

장애 조치 전략(Failover Strategy)

만약 '가장 저렴한 적격 모델(Cheapest Eligible Model)'이 시간 초과되거나 속도 제한에 걸리면, 라우터는 사전에 정의된 장애 조치 경로를 가져야 합니다. 일반적으로 이는 다음 단계(next tier up)로 격상됩니다. 즉, ModelConfig 객체에는 failover_to: ModelConfig가 저장되어 있거나, 라우터 로직이 레지스트리에서 사용 가능한 다음 단계를 기본값으로 설정해야 할 가능성이 높습니다.

6. 자주 묻는 질문(Frequently Asked Questions)

1. 라우터를 사용하는 것이 요청에 상당한 지연 시간(latency)을 추가하나요?

네, 하지만 LLM 추론 시간과 비교했을 때는 보통 무시할 만합니다. 사전 필터링(Pre-Filter) 또는 점수 매기기(Scoring) 단계는 로컬 휴리스틱이나 매우 작은 로컬 모델을 사용하여 100ms 미만을 목표로 해야 합니다. 복잡성 증가(점수 매기기 + 라우팅)는 값비싼 모델로 전송되는 토큰 감소로 상쇄되며, 이는 프리미엄 모델이 더 높은 대기열 시간(queue times)을 가지기 때문에 전체 시스템 응답 시간을 더 빠르게 만드는 결과를 가져옵니다.

2. 대화 중간에 복잡성이 바뀌는 '하이브리드(Hybrid)' 작업은 어떻게 처리해야 하나요?

에이전트는 반복적입니다. 에이전트 루프의 모든 단계마다 라우터를 재실행해야 합니다. 만약 간단한 '요약(summarize)' 작업이 사용자가

Cost-Aware LLM Router를 구현함으로써, 사용자는 AI 인프라를 정적인 API 호출들의 집합이 아닌 최적화 문제로 다루게 됩니다. 이 접근 방식은 사용자 기반이 성장함에 따라 추론 비용(inference bill)이 API 호출 수에 비례하여 기하급수적으로 폭증하는 것이 아니라, 실제 사용자 가치와 선형적으로 증가하도록 보장합니다.