AI 에이전트 시스템 구축(단일 에이전트에서 멀티 에이전트로)
오늘은 3주차 AI 에이전트 엔지니어링(한빛미디어) 인프런 스터디에 Chapter8 단일 에이전트에서 멀티 에이전트로에 대해서 다룹니다.
Chapter8 단일 에이전트에서 멀티 에이전트로
에이전트는 몇 개나 필요할까?
기본 원칙: 단순함에서 출발하여 필요할 때만 복잡성 추가
영향 요인:
- 작업 난이도와 도구 개수(16개 이상이면 성능 저하) 요즘은 더 많이 사용 가능...
- 환경 복잡성과 병렬 처리 필요성
-지연시간(latency) 요구사항
선택 경로:
1) 단일 에이전트로 시작
2) 계층적/시맨틱 도구 선택으로 최적화
3) 필요시만 멀티 에이전트로 전
단일 에이전트 vs 멀티 에이전트
| 구분 | 단일 에이전트 | 멀티 에이전트 |
| 구현 난이도 | 단순 | 복잡 |
| 지연시간 | 낮음 | 높음(조율 오버헤드) |
| 도구 관리 | 도구가 많을 수록 성능 떨어짐 | 전문화로 정확도 높음 |
| 적응성 | 제한점 | 동적 재라우팅 가능 |
| 장애 허용 | 단일 장애점 | 이중화 가능 |
멀티 에이전트의 핵심: 전문화
도구분해: 16개도구를 3개 전문 에이전트로 나누기(예를 들어 3개의 agent에게 5,5,6개로 나누기)
- 재고 관리(재고, 창고, 수요 예측)
- 운송 물류(배송, 배송 최적화, 배송 조정)
- 공급업체 컴플라이언스(평가, 규정)
슈퍼바이저 역할 : 쿼리 분석 -> 전문가 라우팅
이점:
- 각 에이전트의 집중도와 신뢰성 향상
- 병렬 처리로 응답시간 단축
- 혼동(Confusion) 감소
스윔(Swarm) 시스템
정의: 탈중앙화된 단순 에이전트들의 창발적 행동(Emergence)
영감: 새 떼, 개미집단, 물로기 떼
특징:
- 단일 장애점 없음, 높은 확장성
- 국소 상호작용으로 전역 행동 생성
- 실시간 환경 적응
과제: 예측 가능성과 관측 가능성 확보 어려움
적합분야: 대규모 데이터 발견, 분산 의사결정, 엣지 컴퓨팅
에인전트 추가 6대 원칙
| 원칙 | 설명 |
| 작업문해 | 복잡한 작업을 작은 하위 작업으로 나누기 |
| 전문화 | 각 에이전트에 고유한 역할과 강점 부여 |
| 파시모니 | 필요한 최소 에이전트만 추가(비용 고려) |
| 조율 | 견고한 통신 프로토콜과 충돌 해결 |
| 견고성 | 이중화와 장애 허용으로 안정성 보장 |
| 효율성 | 추가 비용 대비 이득 면밀히 평 |
멀티 에이전트 조율 전략
| 전략 | 특징 | 장점 | 단점 |
| 민주적 | 동등한 의사결정 권한 | 견고성 | 통신 오버헤드 높음 |
| 관리자 중심 | 중앙 관리자가 감독 | 빠른 의사결정 | 단일 장애점 |
| 계층형 | 다단계 조직 구조 | 확장성, 장애 허용 | 통신 지연 |
| 액터-크리틱 | 생성-평가 반복 | 품질 향상 | 연산 비용 증가 |
액토-크리틱 패턴
역할 분담
- 액터(Actor): 후보 출력(계획, 답변) 생성
- 크리틱(Critic): 사전 정의된 기준으로 평가 및 선택
프로세스: 품질 임계값 도달할 때까지 반복
- 실행 가능성(Feasibility)(계획인 경우 기준)
- 비용(Cost), 위험도(Risk)
효과적인 경우
- 생성보다 평가가 더 쉬운 작업
- 첫 시도 성능이 낮지만 재랭킹으로 크게 향상되는 경우
- "테스트 시점 연산(Test-Time Compute)"의 예시
ADAS: 에이전틱 시스템 자동 설계
혁신 아이디어: 메타 에이전트가 에이전트를 자동 생성 및 개선
- 메타 에이전트 탐색(MAS) 알고리즘 사용
- 코드로 에이전트 정의(튜링 완전)
반복 사이클: 설계 생성 -> 자기 성찰(Reflexion)-> 평가 -> 아카이브
성과:
- DROP(독해): F1 79.4(기준선 +13.6)
- MMLU(멀티태스킹): 69.6%(기준선 +2%)
- 도메인 간 전이에서도 견고한 성
A2A프로토콜(Agent-to-Agent)
표준화된 통신: 에이전트 간 상호운용 메커니즘
핵심요소:
- 에이전트 카드: 신원, 기능, 엔드포인트 기술 JSON
- JSON-RPC 2.0: HTTP기반 크로스 플랫폼 호출
- 3단계 프로세스: 탐색-> 핸드셰이크-> 작업 조율
장점: 느슨하게 결합된 에이전트 생태계 가능
과제: 초기 단계, 보안(인증/인가) 미완성
메시지 브로커와 이벤트 버스
문제점: 점 대 점 통신(Point-to-Point)의 확장성 한계
해결책: 비동기 메시징 패브릭으로 느슨한 결합
선택지별 특징:
-Apache Kafka: 높은 처리량, 로그 기반 재생 가능
- Redis Streams: 저지연, 경량, 지속성 제한
- RabbitMQ: 가벼운 큐, 배포 간편
- NATS:클라우드 네이티브, 실시간 조율 최적
액터 프레임워크
핵심 개념: 메시징과 연산을 통합한 모델
- 각 에이전트 = 자율적 상태 유지 단위
- 순차 처리 보장 -> 경쟁 상태(Race Condition)제거
주요 프레임워크:
- Ray(python): 간편한 @ray.remote 데코레이터
- Orleans(.NET): 가상 액터, 자동 보구
- Akka(JVM): 높은 성능: 샤딩 지원
적합상황: 에이전트 10~20개 이상, 엄격한 지연시간 요구
오케스트레이션 및 워크플로 엔진
역할: 작업 순서, 재시도, 의존성, 실패 복구 관리
대표도구:
- Teomporal: 지속적 워크플로, 자동 체크포인팅, 결정적 재실행
- Apache Airflow: DAG 기반 배치/일정 워크플로
- Dagger: 로컬 프로토타이핑, 타입 안정성
이점:
- 멱등성(idempotency) 보장
- 장기 실행 작업의 복원력
- 데이터 손실, 중복 작업 방지
상태와 영속성 관리
| 접근 방식 | 장점 | 단점 | 적합 용도 |
| 상태 저장 DB (PostgreSQL/Redis) |
유연, 질의 가능 | 수종 관리 | 맞춤형 시스템 |
| 벡터 스토어 (Pinecone) |
시멘틱 검색 | 높은 비용 | 지식 집약적 에이전트 |
| 오브젝트 스토리지(S3) | 저비용, 고용량 | 느린 접근 | 아카이브용 |
| 상태 저장 프레임워크(Temporal) | 자동 복구 | 프레임워크 종속 | 장시간 워크플 |
에인전트 조율 기법 비교
| 기법 | 개념 | 확장성 | 관측성 | 사용시기 |
| 단일 컨테이너 | 모놀리식, 인메모리 | 낮음 | 높음 | 프로토타입 |
| 메시지 브로커 | 발행/구독 비동기 | 중간 | 중간 | 중규모 시스템 |
| 액터 프레임워크 | 상태 유지 액터 | 높음 | 중간 | 프로덕션 시스템 |
| 워크플로 엔진 | 지속적 상태 관리 | 매우 높음 | 높음 | 엄격한 SLA |
핵심 요약
설계 원칙:
- 단순함에서 출발, 한계에서 확장
- 전문화와 파시모니 추구( 불필요한 가정이나 복잡성을 최소화하고, 가장 단순한 설명이나 구조를 선택하는 원칙 )
- 적절한 조율전략 선택
기술 스택 선택:
- 작은 시스템: 인메모리 + 기본 오케스트레이션
- 중간 규모: 메시지 브로커(Redis/NATS)
- 대규모: 액터 프레임워크 + 워크플로 엔진
미래 방향:
- ADAS를 통한 자동 설계