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를 통한 자동 설계