멀티에이전트 시스템 설계 Designing Multi-Agent Systems
Chapter 11 · 최적화

다중 에이전트 시스템 최적화

측정하고, 분석하고, 수정하고, 검증한다 — 최적화 루프 자체는 단순하다. 진짜 어려운 일은 어떤 파라미터를 건드려야 가장 큰 효과를 얻을지 아는 것이다.

2단계 최적화 10가지 실패 모드 에이전트 시스템 파라미터 모델 수준 파라미터 파인튜닝

Section 1최적화 루프

최적화는 내연 기관을 손보던 일과 같다 — 먼저 엔진을 돌아가게 만들어 기준선을 잡고, 그다음 신호를 관찰하며 파라미터를 조금씩 매만진다.

에이전트도 마찬가지다 — 측정할 신호(10장의 평가 지표)가 있고, 조정할 파라미터(지시문·툴·오케스트레이션 패턴)가 있다.

Optimization Loop
측정 → 분석 → 수정 → 검증 → 반복
측정 평가 실행 · 분석 실패 파악 · 수정 파라미터 조정 · 검증 평가 재실행. 루프 자체는 단순하다 — 어려운 것은 어떤 파라미터를 건드릴지 아는 것이다.

Section 2무엇을·언제 최적화하나 — 2단계 프레임워크

표 · 두 가지 차원의 최적화 영역
층위파라미터특성
에이전트 시스템 (애플리케이션)지시문·툴·메모리·모델 선택·오케스트레이션 패턴·종료 조건·휴먼 위임가장 적은 노력으로 가장 큰 레버리지
모델 수준 (가장 낮은 층위)가중치·아키텍처·하이퍼파라미터·학습 데이터깊은 ML 전문성과 상당한 연산 자원 요구
최적화 우선순위

1. 에이전트 시스템 파라미터부터. 지시문과 툴이 행동에 가장 직접적인 영향을 미친다. 모델·오케스트레이션 복잡도를 끌어올리기 전에 이런 단순한 손질이 종종 의미 있는 향상을 가져온다. 2. 모델 수준은 가장 마지막. 비용·지연을 크게 줄여야 할 때, 프라이버시·컴플라이언스 문제, 또는 에이전트 시스템 최적화가 수확 체감에 들어섰을 때만 — 흔히 프런티어 모델 기준 95% 이상 도달 후.

함정 · 추론 모델의 역설

프런티어 모델은 지시 이행이 우수하지만, 추론(reasoning) 모델은 다중 에이전트 시스템에서 도리어 성능을 떨어뜨릴 때가 있다 — 자신에게 주어진 역할 이상을 떠맡으려 하기 때문이다(오케스트레이터 역할까지 가로채는 식).

Section 3열 가지 프로덕션 실패 모드

AutoGen을 2년간 만들고 프로덕션 배포를 지원한 경험에서, 다중 에이전트 시스템은 일정하고 예측 가능한 방식으로 실패한다. 각 실패 모드는 최적화의 기회다.

Motion · 실패 모드를 최적화 기회로 STEP 01 / 5
측정 → 분석 → 수정 → 검증
표 · 열 가지 실패 모드 → 최적화 전략
실패 모드최적화 전략
불충분한 지시문실패 분석에 기반해 반복적으로 확장 — 살아 있는 문서로 다룬다
부족한 모델 역량전략적 모델 선택 — 작은 모델은 최적화 없이 쓰지 마라
지시문-모델 불일치모델별 프롬프트 엔지니어링 — 모델 종속 자산으로 다룬다
빈약한 툴 품질검증된 툴 카탈로그 큐레이션
모호한 종료 조건데이터 기반 임계값 보정 — TaskStatusTool
잘못된 패턴 선택경험적 패턴 비교 — 평가로 검증
메모리·학습 부재전략적 메모리 구현
메타인지 결여성찰 루프 설계
평가 인프라 부재모든 최적화의 기반
불분명한 인간 위임위험 기반 승인 전략

Section 4파인튜닝은 언제 정당화되나

에이전트 시스템 파라미터를 최적화한 뒤, 남은 실패를 분석하라. 모델 수준 최적화를 정당화하는 두 시나리오.

  • 시나리오 1 · 파라미터로 고칠 수 없는 잔여 실패 — 분포 밖 문제(학습 데이터에 드문 지식), 직관에 어긋나는 비즈니스 로직, 롱테일 엣지 케이스. 모델이 영역 특화 추론 패턴을 갖추지 못했다는 신호.
  • 시나리오 2 · 최고 성능에서의 효율 최적화 — 정확도 100%라도 비용·지연·프라이버시 때문에 정당화될 수 있다. 7B 모델이 특정 과제에 파인튜닝되면 70B 일반화 모델과 견줄 수 있다.
모델 최적화 기법

라우팅 — 단순 질의는 작은 모델로, 복잡한 것은 큰 모델로(비용 15%로 성능 90%). 증류 — 프런티어 모델의 출력으로 작은 모델을 학습. 계단식 처리 — 먼저 작은 모델로, 실패 시만 큰 모델로 에스컬레이션. 작은 모델은 프런티어 모델의 20~30배 저렴하다.

Motion · 라우팅 · 증류 · 계단식 처리 STEP 01 / 4
비용 15%로 성능 90%를 노린다

Section 5사실 다중 에이전트가 필요 없을 수도 있다

다중 에이전트 아키텍처는 복잡성을 더한다. 구현하기 전에 정직하게 평가하라 — 다음 조건을 갖춘 작업에 한해서만 쓴다.

  • 분해 가능성 — 별개의 단계들로 분해할 수 있는가
  • 다양한 관점 — 각 단계가 서로 다른 도메인에 대응되는가
  • 광범위한 컨텍스트 — 단계가 상당량의 정보 처리를 수반하는가
  • 적응적 요구사항 — 행동 전까지 해법을 알 수 없는가
최적화 원칙

작동 가능한 가장 단순한 아키텍처에서 시작하라. 복잡성은 평가가 명백한 이점을 입증할 때에만 추가하라. 잘 설계된 단일 에이전트는 흔히 부실하게 설계된 다중 에이전트 시스템을 능가한다. "Translate this text to French"나 "Summarize this 10-page document"에는 다중 에이전트가 필요 없다.

멀티에이전트 시스템 설계 제11장 · 다중 에이전트 시스템 최적화