자원 최적화를 적용하면 지능형 에이전트가 운영 중에 연산·시간·비용 자원을 실시간으로 모니터링하고 관리할 수 있습니다. 중요한 구분이 하나 있습니다.
이는 주로 동작 순서를 정하는 데 초점을 맞추는 단순한 계획 수립과는 다르다. 자원 최적화에서 에이전트는 지정된 자원 예산 안에서 목표를 달성하거나 효율을 높이기 위해, 동작을 어떻게 실행할지 스스로 결정해야 한다.
6장의 계획 수립이 무엇을 할지의 문제라면, 이 장은 어떻게 할지의 문제입니다.
금융 분석가를 위한 에이전트를 생각해 보면 차이가 분명합니다.
- 분석가에게 예비 보고서가 즉시 필요하다면 → 더 빠르고 저렴한 모델로 핵심 추세를 빠르게 요약
- 분석가가 중요한 투자 의사결정을 위해 매우 정확한 예측을 요구하고 예산과 시간이 충분하다면 → 더 많은 자원을 배정해 강력하지만 느리고 정밀한 모델을 활용
이 범주에서 중요한 전략 하나가 폴백(fallback) 메커니즘입니다. 선호하는 모델이 과부하 상태이거나 호출 제한에 걸려 사용할 수 없을 때 안전장치 역할을 합니다. 성능이 일부 떨어지더라도 서비스를 멈추지 않기 위해 기본 모델이나 더 저렴한 모델로 자동 전환하여, 완전히 멈추는 대신 서비스 연속성을 유지합니다.
실제 적용과 활용 사례
| 사례 | 내용 |
|---|---|
| 비용 최적화 LLM 사용 | 예산 제약에 따라 복잡한 작업에는 크고 비용이 많이 드는 LLM을, 단순한 질의에는 더 작고 저렴한 LLM을 골라 쓴다 |
| 지연 시간에 민감한 작업 | 실시간 시스템에서 적시에 응답하기 위해, 빠르지만 검토 범위가 더 좁을 수 있는 추론 경로를 선택한다 |
| 에너지 효율 | 엣지 디바이스나 전력이 제한된 환경에서 배터리를 절약하도록 처리 방식을 최적화한다 |
| 서비스 신뢰성을 위한 폴백 | 주 모델을 쓸 수 없을 때 백업 모델로 자동 전환해, 품질이 갑자기 무너지는 대신 단계적으로 낮아지면서 계속 동작하게 한다 |
| 데이터 사용량 관리 | 대역폭이나 저장 공간을 절약하려고 전체 데이터셋을 내려받는 대신 요약된 데이터를 가져온다 |
| 적응형 작업 할당 | 멀티 에이전트 시스템에서 에이전트가 현재 연산 부하나 가용 시간에 따라 스스로 작업을 배분한다 |
실습 ① — 여행 플래너로 보는 모델 분리
계층형 에이전트로 구축한 여행 플래너를 생각해 봅니다.
- 상위 수준의 계획 수립(사용자의 복잡한 요청을 이해하고 다단계 일정으로 분해한 뒤 논리적으로 판단) → 제미나이 Pro 같은 정교하고 강력한 LLM
- 항공편 가격 조회, 호텔 빈방 확인, 레스토랑 리뷰 검색 같은 개별 작업 → 본질적으로 단순하고 반복적인 웹 질의이므로 제미나이 Flash 같은 더 빠르고 저렴한 모델
이런 사례는 웹 검색에는 저렴한 모델을 써도 충분하지만, 일관되고 논리적인 여행 계획을 만들어 내야 하는 복잡한 계획 수립 단계에는 왜 고급 모델의 높은 추론 능력이 필요한지 잘 보여준다.
# 개념적으로 파이썬과 유사한 구조일 뿐, 실행 가능한 코드가 아님
from google.adk.agents import Agent
# from google.adk.models.lite_llm import LiteLlm # ADK 기본 Agent가
# 직접 지원하지 않는 모델을 사용할 경우
# 더 비용이 높은 Gemini Pro 2.5를 사용하는 에이전트
gemini_pro_agent = Agent(
name="GeminiProAgent",
model="gemini-2.5-pro",
description="A highly capable agent for complex queries.",
instruction="You are an expert assistant for complex problem-solving."
)
# 더 비용이 낮은 Gemini Flash 2.5를 사용하는 에이전트
gemini_flash_agent = Agent(
name="GeminiFlashAgent",
model="gemini-2.5-flash",
description="A fast and efficient agent for simple queries.",
instruction="You are a quick assistant for straightforward questions."
)
라우터 에이전트 — 단순 지표에서 LLM 라우터로
class QueryRouterAgent(BaseAgent):
name: str = "QueryRouter"
description: str = "Routes user queries to the appropriate LLM agent based on complexity."
async def _run_async_impl(self, context: InvocationContext) -> AsyncGenerator[Event, None]:
user_query = context.current_message.text # 텍스트 입력을 가정
query_length = len(user_query.split()) # 단순 지표: 단어 수
if query_length < 20: # 단순/복잡 판별을 위한 예시 임곗값
print(f"Routing to Gemini Flash Agent for short query (length: {query_length})")
response = await gemini_flash_agent.run_async(context.current_message)
yield Event(author=self.name, content=f"Flash Agent processed: {response}")
else:
print(f"Routing to Gemini Pro Agent for long query (length: {query_length})")
response = await gemini_pro_agent.run_async(context.current_message)
yield Event(author=self.name, content=f"Pro Agent processed: {response}")
질의 길이 같은 단순한 지표로도 나눌 수 있지만, 더 정교한 라우터 에이전트는 LLM이나 ML 모델을 활용해 질의의 뉘앙스와 복잡성을 분석합니다. 사실 정보를 묻는 질의는 Flash로, 심층 분석이 필요한 복잡한 질의는 Pro로 보내는 식입니다.
최적화 기법도 있습니다. 프롬프트 튜닝(라우터 LLM이 더 나은 라우팅 결정을 내리도록 프롬프트를 설계)과, 질의와 최적 모델 선택이 짝을 이룬 데이터셋으로 LLM 라우터를 파인튜닝하는 것입니다.
비평 에이전트 — 간접적인 예산 관리
비평 에이전트는 언어 모델의 응답을 평가하고 피드백을 제공합니다. 역할이 셋입니다.
- 자기 교정: 오류나 불일치를 식별해 응답 에이전트가 출력을 개선하도록 유도한다.
- 성능 모니터링: 응답을 체계적으로 평가해 정확도·관련성 같은 지표를 추적한다.
- 학습 신호: 강화 학습이나 파인튜닝을 위한 신호가 된다. Flash 모델의 응답이 계속 부적절하다고 드러나면, 이를 바탕으로 라우터 에이전트의 로직을 개선할 수 있다.
여기서 이 절의 핵심 통찰이 나옵니다.
비평 에이전트가 예산을 직접 관리하는 것은 아니지만, 단순한 질의를 Pro 모델로 보내거나 복잡한 질의를 Flash 모델로 보내는 등 결과가 좋지 않은 비효율적 라우팅을 찾아내 간접적으로 예산 관리에 기여한다.
비평 에이전트는 응답만 검토하도록 할 수도 있고, 원래 질의와 생성된 텍스트를 함께 검토하도록 할 수도 있습니다. 후자의 경우 응답이 최초 질문에 얼마나 부합하는지 포괄적으로 평가할 수 있습니다.
프롬프트 설계 요령도 명확합니다. 평가자로서의 역할을 명확히 규정하고, 무엇을 중점적으로 비평해야 하는지 지정하며, 단순한 거부가 아니라 건설적인 피드백을 제공하도록 강조하고, 강점과 약점 모두를 식별하도록 유도하며, 피드백을 어떤 구조로 제시할지 안내해야 합니다.
CRITIC_SYSTEM_PROMPT = """
당신은 **비평 에이전트(Critic Agent)** 로서, 협업형 리서치 어시스턴트 시스템의
품질 보증을 담당합니다. 당신의 핵심 역할은 리서처 에이전트(Researcher Agent)가
제시한 정보를 면밀히 검토하고 비판적으로 검증하여 정확성, 완전성,
균형 잡힌 서술을 보장하는 것입니다.
수행해야 할 임무는 다음과 같습니다.
* **리서치 결과 검토**: 사실관계의 정확성, 내용의 충실성, 편향 가능성을 평가합니다.
* **누락 및 결함 식별**: 빠진 데이터나 논리적 모순을 찾아냅니다.
* **핵심 질문 제기**: 현재의 이해를 정교화하거나 확장할 수 있는 중요한 질문을 던집니다.
* **건설적 제안 제시**: 개선 방안을 제안하거나 다른 관점에서의 접근을 모색합니다.
* **최종 결과물 검증**: 산출물이 충분히 포괄적이고 균형 잡혀 있는지 확인합니다.
모든 비평은 건설적이어야 합니다. 당신의 목표는 리서치를 무력화하는 것이 아니라
더욱 견고하게 보강하는 것입니다. 피드백은 명확한 구조로 정리하고, 수정이 필요한
지점을 구체적으로 짚어 주십시오.
"""
11장에서 “작성자와 평가자를 분리하라”고 했던 조언이, 여기서는 비용 최적화를 위한 장치로 다시 쓰입니다.
실습 ② — OpenAI로 세 갈래 분류하기
이 시스템은 각 질의를 세 범주로 분류해 가장 적합하고 비용 효율이 좋은 처리 경로를 결정합니다.
| 범주 | 내용 | 배정 모델 |
|---|---|---|
simple |
복잡한 추론이나 외부 데이터 없이도 바로 답할 수 있는 간단한 질문 | gpt-4o-mini |
reasoning |
논리적 추론이나 다단계 사고 과정이 필요한 질의 | o4-mini |
internet_search |
최신 정보가 필요한 질문. 구글 검색을 자동 실행하여 그 결과를 바탕으로 답한다 | gpt-4o |
# --- 1단계: 프롬프트 분류 ---
def classify_prompt(prompt: str) -> dict:
system_message = {
"role": "system",
"content": (
"You are a classifier that analyzes user prompts and "
"returns one of three categories ONLY:\n\n"
"- simple\n"
"- reasoning\n"
"- internet_search\n\n"
"Rules:\n"
"- Use 'simple' for direct factual questions that need no reasoning or current events.\n"
"- Use 'reasoning' for logic, math, or multi-step inference questions.\n"
"- Use 'internet_search' if the prompt refers to current events, "
"recent data, or things not in your training data.\n\n"
"Respond ONLY with JSON like:\n"
'{ "classification": "simple" }'
),
}
user_message = {"role": "user", "content": prompt}
response = client.chat.completions.create(
model="gpt-4o", messages=[system_message, user_message], temperature=1
)
return json.loads(response.choices[0].message.content)
분류·검색·생성을 거쳐 최종적으로 handle_prompt가 전체 워크플로를 총괄하고, 분류 결과·사용한 모델·생성된 답변을 함께 반환합니다.
# --- 4단계: 통합 라우터 ---
def handle_prompt(prompt: str) -> dict:
classification_result = classify_prompt(prompt)
classification = classification_result["classification"]
search_results = None
if classification == "internet_search":
search_results = google_search(prompt)
answer, model = generate_response(prompt, classification, search_results)
return {"classification": classification, "response": answer, "model": model}
코드는 MIT 라이선스로 깃허브에 공개되어 있습니다.
실습 ③ — OpenRouter의 두 가지 라우팅
OpenRouter는 단일 API 엔드포인트를 통해 수백 개의 AI 모델을 하나의 통합 인터페이스로 다룰 수 있게 해줍니다. 자동 장애 조치와 비용 최적화 기능을 갖추고 있습니다.
import requests, json
response = requests.post(
url="https://openrouter.ai/api/v1/chat/completions",
headers={
"Authorization": "Bearer <OPENROUTER_API_KEY>",
"HTTP-Referer": "<YOUR_SITE_URL>", # 선택. openrouter.ai 순위 집계용
"X-Title": "<YOUR_SITE_NAME>", # 선택. openrouter.ai 순위 집계용
},
data=json.dumps({
"model": "openai/gpt-4o",
"messages": [{"role": "user", "content": "What is the meaning of life?"}]
})
)
요청을 라우팅하고 처리에 사용할 모델을 결정하는 방식이 두 가지입니다.
① 자동 모델 선택
엄선된 가용 모델 집합에서 최적화된 모델을 선택해 요청을 라우팅합니다. 모델 선택은 사용자 프롬프트의 구체적인 내용에 따라 결정되며, 최종적으로 요청을 처리한 모델의 식별자는 응답 메타데이터에 포함되어 반환됩니다.
{ "model": "openrouter/auto", ... }
② 순차적 모델 폴백
사용자가 우선순위가 있는 모델 목록을 지정하면, 시스템은 먼저 첫 번째 모델로 요청 처리를 시도합니다. 서비스 불가, 속도 제한, 콘텐츠 필터링 등으로 해당 모델이 응답에 실패하면 목록의 다음 모델로 자동 전환합니다.
{ "models": ["anthropic/claude-3.5-sonnet", "gryphe/mythomax-l2-13b"], ... }
최종 연산 비용과 응답에 반환되는 모델 식별자는 실제로 연산을 완료한 모델에 해당합니다. 앞서 말한 폴백 메커니즘이 API 수준에서 구현된 형태입니다.
동적 모델 전환을 넘어 — 여덟 가지 기법
| 기법 | 내용 |
|---|---|
| 동적 모델 전환 | 작업 복잡도와 가용 연산 자원을 바탕으로 LLM을 전략적으로 선택하는 핵심 기법 |
| 적응형 도구 사용과 선택 | 여러 도구 가운데 각 세부 작업에 가장 적합하고 효율적인 것을 고르게 한다. API 사용 비용, 지연 시간, 실행 시간을 함께 고려한다 |
| 맥락 가지치기와 요약 | 상호작용 이력에서 관련성 높은 정보만 골라 요약하고 보존하면 프롬프트 토큰 수를 줄이고 추론 비용을 낮춘다 |
| 선제적 자원 예측 | 미래의 워크로드와 시스템 요구사항을 바탕으로 필요한 자원을 미리 가늠해 병목을 방지한다 |
| 비용 민감형 탐색 | 멀티 에이전트 시스템에서 기존 연산 비용뿐 아니라 통신 비용까지 최적화 대상에 포함한다 |
| 에너지 효율적 배포 | 자원 제약이 엄격한 환경에서 운영 시간을 연장하고 에너지 사용량을 최소화한다 |
| 병렬화와 분산 컴퓨팅 인식 | 연산 워크로드를 여러 머신이나 프로세서에 분산해 작업을 더 빨리 완료한다 |
| 학습 기반 자원 할당 정책 | 피드백과 성능 지표를 바탕으로 에이전트가 시간이 지남에 따라 자원 할당 전략을 스스로 조정한다 |
그리고 정상적 성능 저하와 폴백 메커니즘이 이 모두를 떠받칩니다. 자원 제약이 심각할 때에도 성능이 일부 떨어지더라도 단계적으로 수준을 낮추고 대체 전략으로 전환하여 필수 기능을 유지합니다.
정리
자원 최적화란 무엇인가
자원 최적화는 지능형 시스템에서 연산·시간·비용 자원 소비를 관리하는 문제를 다룹니다. LLM 기반 애플리케이션은 비용이 많이 들고 속도가 느릴 수 있으며, 모든 작업에 최적의 모델이나 도구를 선택하는 것은 대체로 비효율적입니다. 이 때문에 시스템 출력 품질과 이를 만드는 데 드는 자원 사이에 근본적인 트레이드오프가 발생합니다.
왜 사용하는가?
표준 해결책은 주어진 작업에 따라 자원을 지능적으로 모니터링하고 할당하는 에이전틱 시스템을 구축하는 것입니다. 보통 라우터 에이전트가 들어오는 요청의 복잡도를 먼저 분류한 다음, 단순한 질의에는 빠르고 저렴한 모델을, 복잡한 추론에는 더 강력한 모델을 사용합니다. 비평 에이전트가 응답 품질을 평가하고 피드백을 제공하면 시간이 지나면서 라우팅 로직을 개선할 수 있습니다.
언제 사용해야 하는가?
API 호출이나 연산 자원에 엄격한 예산 제약이 있을 때, 빠른 응답 시간이 핵심인 지연 시간 민감 애플리케이션을 구축할 때, 배터리 수명이 제한된 엣지 디바이스 같은 자원이 제약된 하드웨어에 에이전트를 배포할 때, 응답 품질과 운영 비용 간 트레이드오프를 프로그래밍 방식으로 조절해야 할 때, 그리고 작업마다 자원 요구사항이 다른 복잡한 다단계 워크플로를 관리할 때 이 패턴을 사용한다.
핵심 정리
- 자원 최적화는 필수다. 지능형 에이전트는 연산·시간·비용 자원을 실시간으로 관리할 수 있으며, 모델 사용과 실행 경로는 실시간 제약 조건과 목표를 바탕으로 결정된다.
- 확장성을 위한 멀티 에이전트 아키텍처: 각기 다른 에이전트(응답 생성, 라우팅, 비평)가 각자 맡은 작업을 처리한다.
- 동적 LLM 기반 라우팅: 라우터 에이전트가 질의 복잡도와 예산에 따라 질의를 언어 모델로 전달한다(단순 질의는 Flash, 복잡한 질의는 Pro).
- 비평 에이전트의 기능: 전담 비평 에이전트가 자기 교정, 성능 모니터링, 라우팅 로직 개선에 필요한 피드백을 제공한다.
- 피드백과 유연성을 통한 최적화: 평가 기능과 모델을 유연하게 통합할 수 있는 구조는 시스템이 적응형으로 동작하고 스스로 개선되도록 돕는다.
마치며
자원 최적화는 지능형 에이전트를 개발할 때 반드시 필요한 패턴으로, 에이전트가 실제 운영 환경의 제약 안에서 효율적으로 운영할 수 있게 합니다. 연산·시간·비용 자원을 관리하면 에이전트가 최적의 성능과 비용 효율을 달성할 수 있습니다.
학습 기반 자원 할당 정책이나 정상적 성능 저하 같은 고급 전략은 다양한 조건에서 에이전트의 적응력과 복원력을 높여 준다. 이러한 최적화 원칙을 에이전트 설계에 녹여 내야 확장 가능하고 견고하며 지속 가능한 AI 시스템을 만들 수 있다.