TL;DR — "항상 가장 좋은 모델을 쓰면 된다"는 생각은 프로덕션에서 예산을 태웁니다. 자원 인식 최적화는 AI 에이전트가 비용·시간·품질의 트레이드오프를 동적으로 관리하는 패턴입니다. 핵심 흐름은 쿼리 분류 → 모델 라우팅 → 예산 확인 → 품질 평가 → (필요시) Fallback 입니다. 단순 질문은 Flash(저비용)로, 복잡한 추론은 Pro(고성능)로 보내고, 장애 시 폴백 체인으로 서비스를 잇습니다. 같은 트래픽에서 비용을 70%까지 줄이는 것은 모델이 아니라 라우팅 설계의 일입니다.
1. 왜 자원 인식인가 — 똑똑해질수록 비용은 설계의 문제가 된다
지난 편에서 에이전트는 명함을 들고 다른 에이전트와 표준으로 협업하는 법(A2A)을 배웠습니다. 혼자 똑똑한 것을 넘어 팀으로 일하게 됐죠. 그런데 에이전트가 많아지고 호출이 잦아질수록, 누구도 피해 갈 수 없는 청구서가 날아옵니다 — API 비용입니다. 그리고 여기서 주니어 엔지니어가 가장 흔히 하는 선택이 함정이 됩니다. "이왕이면 제일 좋은 모델로 다 처리하자."
교재가 제시하는 숫자는 냉정합니다. 같은 작업을 GPT-4o급으로 처리하면 입력 토큰 100만 개당 $2.50, mini급은 $0.15 — 약 16배 차이입니다. 월 100만 쿼리 기준으로 환산하면 한쪽은 ~$3,750, 다른 쪽은 ~$225죠. 모든 요청에 최고 모델을 쓰는 순간, 트래픽이 늘수록 비용은 선형으로 폭발하고 결국 예산 한계 → 서비스 축소라는 막다른 길에 도달합니다.
핵심 통찰은 한 문장으로 압축됩니다 — "가장 좋은 모델이 항상 최선은 아니다. 상황에 맞는 최적의 선택이 최선이다." 에이전트가 똑똑해질수록, 비용은 더는 인프라팀의 사후 정산 문제가 아니라 아키텍처를 짤 때 함께 설계해야 할 변수가 됩니다. 이번 편은 그 설계 도구들 — Router·Budget·Critique·Fallback — 을 하나씩 조립해 봅니다.
2. 개념과 오해 — 항공사 좌석 등급으로 이해하기
📌 한 줄 정의 — 자원 인식 최적화(Resource-Aware Optimization)는 AI 에이전트가 작업 수행 시 계산 자원·시간·비용을 동적으로 모니터링하고 최적으로 관리하는 설계 패턴입니다. 목표는 단 하나 — 제한된 예산 안에서 최대 성능을 뽑아내는 것.
교재의 비유가 이 패턴의 본질을 정확히 잡아줍니다. 모델 선택은 항공사 좌석 등급 시스템과 같습니다. 모든 승객을 비즈니스석에 태우면 항공사는 파산합니다. 짧은 국내선(간단한 질문)에 비즈니스석은 과잉 투자고, 장거리 출장(복잡한 분석)에는 비즈니스석이 오히려 효율적이죠. 핵심 질문은 늘 같습니다 — "이 승객에게 어떤 좌석을 배정할까?"
시작 전에, 자주 만나는 오해 세 가지를 짚습니다.
gemini-2.0-flash를 씁니다(분류 비용 90% 절감).3. 4대 구성요소 — 한눈에 보는 자원 인식 시스템
자원 인식 시스템은 네 개의 협력 컴포넌트로 이뤄집니다. 각자 한 가지 책임만 지는 단일 책임 원칙(SRP)의 교과서 같은 구조입니다.
이 저장소의 구현은 두 파일로 나뉩니다 — 01_resource_aware_router.py(Router + Budget)와 02_multi_model_fallback.py(Fallback + Critique). 둘 다 순수 Python + Google Gemini API로만 작성돼, 프레임워크 추상화 없이 패턴의 뼈대를 그대로 드러냅니다. 먼저 Router부터 봅니다.
4. Router Agent — 쿼리 복잡도가 좌석을 결정한다
Router Agent는 들어온 쿼리를 분석해 세 가지 카테고리 중 하나로 분류하고, 그 결과에 따라 모델 티어를 정합니다. 분류 자체는 Flash 모델이 JSON 한 장으로 답하는 가벼운 작업입니다.
분류 결과는 pydantic으로 타입을 보장합니다. category(카테고리), confidence(0~1 신뢰도), reasoning(이유)을 받고, 분류가 실패하면 안전하게 simple로 떨어집니다(우아한 성능 저하 — 10절). 라우팅의 실제 결정 트리는 다음과 같습니다.
5. Budget Manager — 비용에 가드레일을 두다
라우팅이 "어디로 보낼까"라면 Budget Manager는 "얼마까지 쓸까"를 책임집니다. 모든 호출의 토큰 사용량을 비용으로 환산해 기록하고, 일·월 예산 대비 소진율을 추적합니다. 비용 계산은 단순한 비례식입니다.
구현의 모델 카탈로그를 보면 티어 간 단가 차이가 드러납니다. Flash는 입력 $0.10 / 출력 $0.40(1M 토큰), Pro는 입력 $1.25 / 출력 $10.00 — 입력 12.5배, 출력 25배 차이입니다. 같은 답을 Flash로 낼 수 있다면, 그게 곧 비용 절감입니다.
| 티어 | 입력 / 1M | 출력 / 1M | 평균 지연 | 역할 |
|---|---|---|---|---|
| FLASH | $0.10 | $0.40 | 500ms | 저비용·빠름 (이코노미) |
| PRO | $1.25 | $10.00 | 2000ms | 고성능·비쌈 (비즈니스) |
| FALLBACK | $0.10 | $0.40 | 500ms | 최소 비용·안정성 (스탠바이) |
MODEL_CATALOG 기준) — 모델 ID·가격은 버전에 따라 변동될 수 있습니다예산 상태는 check_budget()이 매 호출 전에 평가합니다. 일·월 소진율을 계산하고, 경고 임계값(80%)을 넘으면 알림 플래그를 켜고, 일·월 잔액이 모두 남아 있을 때만 can_use_pro = True를 돌려줍니다. 이 한 줄이 4절의 라우터에서 "예산 없으면 무조건 Flash" 가드레일로 작동합니다.
6. 구현 ① Resource-Aware Router — 분류·예산·라우팅의 통합
이제 4·5절의 조각을 하나로 묶습니다. ResourceAwareAgent는 Facade 패턴으로, 외부에는 process(query) 하나만 노출하고 내부에서 분류 → 라우팅 → 응답 → 비용 기록의 4단계를 조율합니다.
코드 안에는 세 가지 고전 디자인 패턴이 녹아 있습니다 — 모델 선택의 Strategy(Flash/Pro 전략 교체), 모델 인스턴스 재사용의 Factory(_get_model 캐싱으로 초기화 오버헤드 제거), 그리고 복잡한 내부를 한 메서드로 감추는 Facade. 실행하면 쿼리마다 분류·선택 모델·비용·지연이 출력됩니다.
단순 질문은 450ms·$0.000012로, 복잡한 분석은 2100ms·$0.000350으로 — 같은 에이전트가 쿼리 성격에 맞춰 비용과 속도를 자동 조절합니다. 이게 Router + Budget이 만드는 1차 절감입니다. 하지만 모델은 가끔 실패하고, 가끔 품질이 부족합니다. 그래서 두 번째 구현이 필요합니다.
7. Fallback 체인 — 죽어도 서비스는 멈추지 않는다
주 모델이 항상 응답하리라는 보장은 없습니다 — Rate Limit 초과, 서비스 장애, 예산 소진. Fallback 메커니즘은 우선순위 체인을 따라 다음 모델로 자동 전환해 서비스 연속성을 지킵니다. 이것은 책임 연쇄(Chain of Responsibility) 패턴의 전형입니다.
각 모델 안에서는 재시도 사이에 지수 백오프(Exponential Backoff)를 둡니다. 실패할 때마다 대기 시간을 늘려 상대 서버에 숨 쉴 틈을 주는 것 — 12편(예외 처리)에서 본 패턴이 폴백 체인 안에 그대로 들어와 있습니다.
엔터프라이즈에서 이 한 조각의 가치는 큽니다. 적용 전략 문서는 폴백 없는 시스템이 1시간 장애로 $10,000~$100,000 손실을 볼 수 있다고 추정하는데, 폴백이 있으면 사용자는 장애를 인지조차 하지 못한 채 다른 모델로 서비스가 이어집니다(12절에서 비즈니스 가치를 다시 다룹니다).
8. Critique Agent — 싸게 시도하고, 부족하면 비싸게 다시
저비용 라우팅의 가장 큰 두려움은 "품질이 떨어지면?"입니다. Critique Agent가 그 안전장치입니다 — 응답을 5개 차원으로 0~10점 채점하고, 평균이 임계값(7.0)을 못 넘기면 개선 루프나 상위 모델 에스컬레이션을 트리거합니다. 4편(리플렉션)의 Producer-Critic 모델이 비용 최적화 맥락으로 들어온 셈입니다.
평가가 임계값을 못 넘기면 ResponseImprover가 피드백을 반영해 응답을 다시 씁니다. 이때 개선된 점수가 이전보다 높을 때만 교체하고, 나아지지 않으면 루프를 멈춥니다 — 무한 개선의 함정을 막는 안전장치입니다.
9. 구현 ② AdaptiveQualitySystem — 4단계 품질 관리
두 번째 구현(02_multi_model_fallback.py)은 Fallback 체인·Critique·Improver를 AdaptiveQualitySystem으로 통합합니다. 처리 흐름은 4단계입니다 — 싸게 시작하고, 평가하고, 개선하고, 그래도 안 되면 비싸게 다시.
FallbackChain.execute(start_from=SECONDARY) — 일부러 중간 티어(Flash)부터 시작해 비용을 아낀다CritiqueAgent.evaluate() — 5차원 채점, overall_score 산출Improver.improve() — 점수가 오를 때만 채택execute(start_from=PRIMARY) — 최고 성능 Pro로 재시도이 시스템은 세 가지 패턴의 합주입니다 — 책임 연쇄(Fallback), 자기 성찰(Critique→Improve), 우아한 성능 저하(Pro→Flash→1.5→8B로 내려가도 서비스 유지). 학습 자료의 통계 예시에 따르면 이 구조로 품질 통과율 약 87%, 평균 점수 7.8/10, Fallback 성공률 약 99%를 달성합니다(시뮬레이션 기준 예시 값).
10. 6가지 최적화 기법 — 모델 선택은 시작일 뿐
모델 라우팅은 자원 최적화의 입구입니다. 교재는 자원 관리자(Resource Manager)를 중심으로 한 여섯 가지 기법을 제시합니다 — 모델·도구·컨텍스트·예측을 종합한 다층 최적화입니다.
특히 Contextual Pruning은 멀티턴 에이전트에서 효과가 큽니다. 대화가 길어질수록 매 호출에 누적된 이력 전체가 입력 토큰으로 청구되는데, 핵심만 요약해 컨텍스트를 압축하면 토큰을 80%까지 줄일 수 있습니다 — 8편(메모리)의 컨텍스트 관리가 비용 관점에서 다시 보이는 지점입니다.
11. OpenRouter — 모델 선택을 외부에 위임하기
직접 라우터를 짜는 대신, OpenRouter 같은 통합 게이트웨이를 쓸 수도 있습니다. 수백 개의 모델을 단일 API 엔드포인트로 묶어, 여러 공급자(OpenAI·Google·Anthropic)를 한 인터페이스로 호출하게 해줍니다. 라우팅 방식은 두 가지입니다.
직접 구현 vs 게이트웨이는 트레이드오프입니다. 직접 짜면 라우팅 로직·예산·품질을 세밀하게 제어할 수 있지만 유지보수 부담이 있고, 게이트웨이는 빠르게 다공급자 폴백을 얻지만 외부 의존과 추가 마진이 붙습니다. 민감 데이터를 온프레미스 모델로 보내야 하는 등 거버넌스 요구가 강하면 직접 라우터가, 빠른 실험·다양성이 우선이면 게이트웨이가 유리합니다.
12. 엔터프라이즈 — CRM·ERP·Groupware에 게이트웨이를 깔다
엔터프라이즈에서는 자원 인식 라우터를 Enterprise AI Gateway 한 곳에 놓고, CRM·ERP·Groupware가 그 게이트웨이를 통해 LLM을 호출하게 합니다. API Gateway 계층에서 인증·Rate Limit·예산 트래킹을 하고, Router 계층에서 분류·모델 선택·폴백을, Quality 계층에서 Critique·사용량 분석을 담당하는 다층 구조입니다.
| 시스템 | 대표 적용 | 라우팅 전략 | 기대 효과 |
|---|---|---|---|
| CRM | 고객 문의 응대 · 리드 스코어링 | FAQ→Flash, 불만·협상·VIP→Pro | 비용 70%↓, 응답속도 3배↑ |
| ERP | 재고 조회 · 수요 예측 · 발주 | 조회→규칙, 표준 리포트→템플릿, 최적화→Pro | 재고 AI 비용 100%↓, 처리 효율↑ |
| Groupware | 이메일 분류 · 문서 요약 · 회의 요약 | 레이턴시 SLA 기반(스팸 50ms, 회의요약 5초 비동기) | 실시간 분류, 회의요약 비용 60%↓ |
ERP의 통찰이 특히 날카롭습니다 — 정형화된 재고 조회는 SQL 한 줄이면 됩니다. "AI를 안 쓰는 것"도 자원 최적화입니다. 모든 모듈을 AI로 처리하려는 충동을 누르고, 규칙·템플릿·AI를 작업 성격에 맞게 섞는 하이브리드 전략이 ERP_PROCESSING_STRATEGY의 본질입니다.
= $300/일 · $9,000/월
연간 $108,000
+ 10% Premium($30) = $77/일 · $2,310/월
연간 $27,720
| 지표 | Before | After | 개선율 |
|---|---|---|---|
| 평균 응답 시간 | 3.5초 | 1.2초 | 66% 단축 |
| 복잡한 질문 정확도 | 75% | 92% | 23% 향상 |
| 시스템 처리량 | 100 QPS | 350 QPS | 250% 향상 |
| 서비스 가용성 | 95% | 99.9% | 폴백으로 강화 |
이 패턴이 충족하는 거버넌스 요구도 분명합니다 — 비용 통제(부서별 예산·실시간 모니터링·자동 강등, CFO), 품질 관리(Critique 기반 임계값 에스컬레이션, COO), 규정 준수(PII는 온프레미스 라우팅·감사 로그, CISO/DPO). 라우터 하나가 재무·운영·보안 세 부서의 요구를 동시에 떠받칩니다.
13. 케이스 스터디 — 여행 플래너의 계층적 모델 활용
"도쿄 3박 4일 여행 계획 짜줘." 이 한 요청 안에는 성격이 다른 작업들이 섞여 있습니다. 교재의 여행 플래너 시나리오는 Planner-Worker 구조로 이를 분리합니다 — 어려운 설계는 Pro에게, 단순 검색은 Flash 여러 개에게.
전부 Pro로 처리했다면 $0.30 — 87% 절약
이 시나리오가 이번 편의 축소판입니다. 고난도 작업에만 비싼 모델을 쓰고(4절 라우팅), 나머지는 저비용으로 병렬 처리하고(3편 병렬화와 결합), 전 과정의 비용이 기록되며(5절 예산), 검색 API가 죽으면 폴백이 받칩니다(7절). 6편(플래닝)의 Planner-Worker가 비용 관점에서 다시 빛나는 순간 — 좋은 계획은 곧 좋은 예산 배분이기도 합니다.
14. 베스트 프랙티스 — 쓸지 말지, 그리고 체크리스트
자원 인식 최적화도 만능은 아닙니다. 교재의 적합성 기준부터 — 핵심은 "다양한 복잡도와 비용 제약이 공존하는가"입니다.
도입을 결정했다면 안티패턴 두 가지를 경계하세요. 라우팅 오버헤드가 절감액을 잡아먹는 경우 — 분류에 고가 모델을 쓰면 본전도 못 찾습니다(반드시 Flash로). 그리고 개선 루프 무한 반복 — 점수가 오를 때만 채택하고 최대 횟수를 두지 않으면, 품질을 좇다 비용이 역전됩니다. 구현이 두 함정을 모두 막아둔 이유입니다.
순서대로 쪼개고(체이닝), 갈래를 나누고(라우팅), 병렬로 돌리고(병렬화), 스스로 비평하고(리플렉션), 도구를 쥐고(도구 사용), 계획하고(플래닝), 팀을 이루고(멀티 에이전트), 기억하고(메모리), 배우고(학습), 표준으로 도구에 연결되고(MCP), 스스로 채점하고(목표 설정), 넘어져도 일어서고(예외 처리), 멈춰야 할 순간 사람을 부르고(휴먼 인 더 루프), 근거로 말하고(RAG), 다른 에이전트와 협업하던(A2A) 에이전트 — 이번엔 비용을 설계하는 법(자원 인식 최적화)을 배웠습니다. 가장 비싼 모델이 아니라 상황에 맞는 모델을 고르고, 예산에 가드레일을 두고, 죽어도 서비스를 잇는 법이죠. 다음 편은 추론 기법(Reasoning): 모델이 답을 내기 전에 생각의 사슬을 펼치고(CoT), 여러 갈래를 탐색하고(ToT), 스스로 교정하는 법입니다. 좋은 좌석을 골랐다면, 이제 그 좌석에서 어떻게 더 깊이 사고하게 할 것인가의 문제입니다.
- Google Gemini API 공식 문서 — 모델 목록·티어·가격
- Gemini API Pricing — 입력·출력 토큰 단가 (버전별 변동)
- OpenRouter Documentation — Auto 라우팅·모델 폴백
- Google ADK 공식 문서 — Agent 개발 키트
- Antonio Gulli, Agentic Design Patterns — Ch.16 Resource-Aware Optimization
'Agentic AI Design Patterns' 카테고리의 다른 글
| CH19-AI 에이전트 평가 3수준과 LLM-as-a-Judge — 정확도부터 Trajectory·드리프트 탐지까지 Python·LangGraph·ADK로 (1) | 2026.06.14 |
|---|---|
| CH17-AI가 답하기 전에 '생각'하게 만드는 법 — 추론 기법 CoT·ToT·ReAct 완전 해부 (0) | 2026.06.13 |
| CH15-내 에이전트가 남의 에이전트와 일하게 하라 — 에이전트의 명함, A2A 프로토콜 (0) | 2026.06.11 |
| CH14-환각 대신 근거로 말하게 하라 — AI 에이전트 검색 증강 생성(RAG) 설계 (0) | 2026.06.10 |
| CH13-AI가 계정을 멋대로 삭제하지 못하게 하는 법 — 위험도 기반 에스컬레이션과 인간 승인(HITL) 패턴 (1) | 2026.06.10 |