AI 에이전트 프로필로 비용 구조 재설계 — 모델 라우팅 전략

-

여러 에이전트를 프로필 단위로 축소한 Hermes의 비용 아키텍처

핵심 요약

  • 이 글은 다중 에이전트 시스템에서 역할 기반 프로필 통합과 모델 라우팅 전략이 어떻게 작동하는지 정리한다.
  • 핵심 결론: 오케스트레이터 모델은 고정(최상위), 반복 조회는 무료/저비용 모델, 메모리 처리는 로컬 오프로드.
  • 유료 지출은 ChatGPT Plus 구독 1건(~$20/월)에 수렴하고, Gemini 무료 티어와 oMLX 로컬이 나머지를 메운다.
  • smart routing(오케스트레이터 동적 다운그레이드)은 품질 손실이 비용 절감을 상회하므로 비활성화한다.

이 글에서 가져갈 수 있는 것

  1. 에이전트 다수를 역할 프로필로 묶는 통합 패턴
  2. 프로필별 모델 선정의 판단 기준(판단 깊이 × 호출 빈도 × 비용)
  3. 3단계 Fallback 체인 설계 — 비용 → 품질 → 로컬 오프라인 순
  4. 오케스트레이터에 smart routing을 적용하면 안 되는 이유와 적용 경계

배경: 에이전트 분산 구조의 한계

초기 OpenClaw는 여러 에이전트가 각자 독립 설정으로 돌았다. 에이전트마다 사용 모델이 달랐고, 일부는 역할이 중복됐다. 이 구조의 실제 병목은 비용보다 관리 복잡도였다. 모델 교체 한 번에 설정 변경 지점이 여러 군데로 흩어져 있어, 라우팅 품질을 일관되게 유지하기 어려웠다.

Hermes 재설계의 출발점은 여기다. 에이전트를 줄이는 것이 목적이 아니라, 모델 결정을 한 곳에서 관리할 수 있는 단위로 묶는 것이 목적이었다. 역할 단위로 재분류한 결과 개별 에이전트 설정이 프로필 단위 추상화로 수렴했다.

프로필과 모델 매핑

프로필 모델 역할
default (mir) gpt-5.4 오케스트레이터. 범용 판단, 라우팅 결정
coder gpt-5.3-codex 코드 생성, 디버깅
researcher gemini-3.1-flash-lite 검색, 정보 수집
monitor gemini-3.1-flash-lite 시스템 상태 감시
memory gemini-2.5-flash 메모리 읽기/쓰기, 요약
memory-runner gemma-4-26b (oMLX 로컬) 로컬 메모리 처리

초안 단계에서 더 많은 프로필이 거론됐으나 실제 구현에서는 분리 기준이 약한 프로필을 상위 프로필로 흡수하며 수렴시켰다.

모델 선택 논리

프로필별 모델 선정은 세 축으로 판단한다: 판단 깊이, 호출 빈도, 비용 탄력성.

오케스트레이터: gpt-5.4 고정

오케스트레이터(default/mir)는 최상위 모델을 쓴다. 원칙은 단순하다: 오케스트레이터는 항상 최고 모델.

smart_model_routing을 활성화해서 작업 복잡도에 따라 오케스트레이터 모델을 gpt-4o-mini로 다운그레이드하는 구성을 시험했고, 이후 비활성화했다. 오케스트레이터가 낮은 모델로 내려가면 판단 품질 저하가 전체 파이프라인 하류로 전파된다. 비용 절감폭보다 품질 저하의 영향 범위가 더 넓다는 것이 핵심이다.

Gemini: 반복 조회 작업에 투입

researcher, monitor는 gemini-3.1-flash-lite. 검색·상태 감시처럼 고빈도 · 저판단 작업에 적합하다. 판단 복잡도가 낮으므로 모델 상향에 따른 한계 효용이 작고, 호출 빈도가 높아 무료 티어의 가치가 극대화된다. Gemini 무료 티어 범위 내에서 운영되므로 추가 비용이 붙지 않는다.

memory: gemini-2.5-flash

메모리 요약과 읽기/쓰기는 문맥 이해가 필요하지만 창의적 판단 비중은 낮다. gemini-2.5-flash가 이 구간에 들어맞는다. 컨텍스트 압축에는 openrouter의 gemini-2.5-flash:free 엔드포인트를 활용한다.

memory-runner: gemma-4-26b (로컬)

oMLX 위에서 로컬로 실행. 엔드포인트는 127.0.0.1:8001.

  • 모델: gemma-4-26b-a4b-it-4bit (4bit 양자화)
  • 임베딩: bge-m3-mlx-fp16

외부 API를 쓰지 않으므로 추가 비용이 없다. 레이턴시는 존재하지만, 메모리 처리는 실시간 응답이 강제되지 않는 비동기 작업이라 이 트레이드오프가 성립한다.

Fallback 체인

단일 모델 의존은 API 장애 시 전체 정지로 직결된다. Hermes는 3단계 폴백 체인을 구성한다.

gemini-pro → claude-sonnet-4-6 → omlx/gemma-4
  • 1차: gemini-pro (비용 효율, 빠른 응답)
  • 2차: claude-sonnet-4-6 (품질 보장)
  • 3차: omlx/gemma-4 (완전 로컬, 외부 의존 없음, 최후 보루)

폴백은 API 오류 또는 응답 타임아웃 시 자동 트리거된다. 체인의 순서는 비용 → 품질 → 가용성 축으로 정렬된다. 끝단에 로컬 모델을 두면 네트워크 장애 시에도 최소 기능이 유지된다.

월 지출 구조

항목 비용
ChatGPT Plus (mir + coder) ~$20/월
Gemini (researcher, monitor, memory) $0 (무료 티어)
oMLX 로컬 (memory-runner) $0
합계 ~$20/월

OpenClaw 시절과의 직접 비용 비교는 문서화된 수치가 없다. 초기 논의에서 "90% 절감"이라는 표현이 등장했지만 검증된 데이터가 없으므로 기재하지 않는다.

현재 구조에서 확인 가능한 사실은 하나: 유료 지출은 ChatGPT Plus 구독 한 줄에 수렴한다.

통합이 가져온 구조적 효과

숫자 자체는 표면적 지표에 불과하다. 실제 효과는 두 지점에서 발생한다.

1. 라우팅 결정의 명확화

에이전트가 많을수록 "어떤 에이전트가 이 작업을 처리하는가"를 오케스트레이터가 매번 판단해야 한다. 프로필 단위로 묶으면 역할 경계가 뚜렷해서 라우팅 모호성이 줄고, 잘못된 프로필로 분기되는 빈도가 감소한다.

2. 모델 교체의 지역성 확보

특정 프로필에 연결된 모델을 교체할 때 해당 프로필 설정 한 곳만 바꾸면 된다. 이전 구조에서는 에이전트별 모델 설정이 분산돼 있어, 동일한 모델 교체 작업이 다수 지점의 동기화 문제로 번졌다.

smart_model_routing의 적용 경계

smart_model_routing은 작업 복잡도를 감지해 투입 모델을 동적으로 선택하는 기능이다. 단순 조회는 저가 모델, 복잡한 판단은 상위 모델로 자동 전환한다.

오케스트레이터에 적용했을 때의 관찰:

  • 오케스트레이터가 낮은 모델로 내려가면 라우팅 판단 품질이 눈에 띄게 저하
  • 판단 오류는 하류 에이전트로 전파되므로, 절감액 대비 복구 비용이 커짐
  • 원칙 복원: 오케스트레이터는 gpt-5.4 고정

결론: smart_model_routing은 에이전트 내부 작업(researcher, memory 등 단일 역할)에는 유효하지만, 전체 흐름을 결정하는 오케스트레이터에는 적합하지 않다. 판단 품질이 하류로 전파되는 계층에는 고정 모델이 정답이다.

요약표

항목 결정
프로필 구성 default, coder, researcher, monitor, memory, memory-runner
오케스트레이터 모델 gpt-5.4 고정
무료 활용 Gemini 무료 티어, oMLX 로컬
월 지출 ~$20 (ChatGPT Plus)
폴백 체인 gemini-pro → claude-sonnet-4-6 → omlx/gemma-4
smart routing 오케스트레이터 비활성화, 하위 에이전트에만 선택 적용

적용 가능 범위와 열린 질문

적용 가능 범위

  • 다중 LLM 에이전트를 운영하는 개인/소규모 시스템
  • 유료 API와 무료 티어, 로컬 모델을 혼합해 비용 곡선을 평탄화하려는 구성
  • 오케스트레이터–워커 구조에서 판단 품질이 하류로 전파되는 파이프라인

열린 질문

  • 하위 에이전트의 smart routing은 어떤 임계치로 분기할 때 안정적인가
  • 폴백 체인이 2차 → 3차로 내려갔을 때 품질 저하를 사용자에게 어떻게 시그널할 것인가
  • 프로필을 더 줄일 때 역할 경계가 다시 모호해지는 지점은 어디인가

이 세 질문이 다음 반복의 설계 축이 된다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »