(위 이미지를 클릭하면 이 수업의 동영상을 볼 수 있습니다)
다중 에이전트가 포함된 프로젝트를 시작하면 다중 에이전트 디자인 패턴을 고려해야 합니다. 그러나 언제 다중 에이전트로 전환해야 하는지와 그 장점이 무엇인지 즉시 명확하지 않을 수 있습니다.
이 수업에서는 다음 질문에 답하려고 합니다:
- 다중 에이전트가 적합한 시나리오는 무엇인가요?
- 여러 작업을 수행하는 단일 에이전트 대신 다중 에이전트를 사용할 때의 장점은 무엇인가요?
- 다중 에이전트 디자인 패턴을 구현하는 구성 요소는 무엇인가요?
- 여러 에이전트들이 서로 어떻게 상호작용하는지 어떻게 가시성을 확보할 수 있나요?
이 수업 후에 당신은 다음을 할 수 있어야 합니다:
- 다중 에이전트가 적합한 시나리오를 식별할 수 있다.
- 단일 에이전트보다 다중 에이전트를 사용하는 장점을 인식할 수 있다.
- 다중 에이전트 디자인 패턴을 구현하는 구성 요소를 이해할 수 있다.
더 큰 그림은 무엇인가요?
다중 에이전트는 여러 에이전트가 함께 협력하여 공통 목표를 달성할 수 있게 하는 디자인 패턴입니다.
이 패턴은 로봇 공학, 자율 시스템, 분산 컴퓨팅 등 다양한 분야에서 널리 사용됩니다.
그렇다면 다중 에이전트를 사용하는 좋은 사례는 어떤 것일까요? 다중 에이전트를 사용하는 것이 유리한 많은 시나리오가 있으며 특히 다음과 같은 경우입니다:
- 대규모 작업 부하: 대규모 작업 부하는 더 작은 작업으로 나누어 각기 다른 에이전트에 할당할 수 있어 병렬 처리와 빠른 완료가 가능합니다. 예를 들어 대용량 데이터 처리 작업이 있습니다.
- 복잡한 작업: 복잡한 작업은 대규모 작업 부하처럼 더 작은 하위 작업으로 나눌 수 있으며, 각기 다른 에이전트는 작업의 특정 측면에 전문화됩니다. 예를 들어 자율 주행 차량에서 내비게이션, 장애물 감지, 차량 간 통신을 각각 관리하는 에이전트가 있습니다.
- 다양한 전문성: 각기 다른 에이전트가 다양한 전문성을 가질 수 있어서 단일 에이전트보다 작업의 여러 측면을 더 효과적으로 처리할 수 있습니다. 예를 들어 의료 분야에서 진단, 치료 계획, 환자 모니터링을 각각 담당하는 에이전트가 있습니다.
단일 에이전트 시스템은 간단한 작업에 적합할 수 있지만, 더 복잡한 작업에는 여러 에이전트를 사용하는 것이 여러 면에서 유리할 수 있습니다:
- 전문화: 각 에이전트가 특정 작업에 전문화될 수 있습니다. 단일 에이전트는 모든 것을 할 수 있지만 복잡한 작업에서는 혼란스러워할 수 있습니다. 예를 들어 자신에게 가장 적합하지 않은 작업을 수행할 수 있습니다.
- 확장성: 시스템을 확장할 때 단일 에이전트에 부담을 주기보다 에이전트를 추가하여 더 쉽게 확장할 수 있습니다.
- 내결함성: 한 에이전트에 문제가 생겨도 다른 에이전트들이 계속 작동하여 시스템 신뢰성을 보장할 수 있습니다.
예를 들어 사용자의 여행 예약을 한다고 가정합시다. 단일 에이전트 시스템은 비행기 찾기부터 호텔과 렌터카 예약까지 모든 과정을 처리해야 합니다. 단일 에이전트가 이 모든 작업을 처리하려면 각 작업별 도구가 필요해서 복잡하고 유지보수와 확장이 어려운 단일체가 될 수 있습니다. 반면 다중 에이전트 시스템은 비행기 검색, 호텔 예약, 렌터카 예약을 각각 전문적으로 처리하는 에이전트를 갖고 있어 더 모듈화되고 유지보수 및 확장이 용이합니다.
이를 동네 여행사와 프랜차이즈 여행사와 비교할 수 있습니다. 동네 여행사는 하나의 에이전트가 모든 예약 업무를 처리하는 반면, 프랜차이즈는 각기 다른 에이전트가 여행 예약 각 부분을 담당합니다.
다중 에이전트 디자인 패턴을 구현하려면 패턴을 구성하는 요소를 이해해야 합니다.
다시 여행 예약 예를 구체적으로 봅시다. 이 경우 구성 요소는 다음과 같습니다:
- 에이전트 간 통신: 비행기 찾기, 호텔 예약, 렌터카 예약 에이전트는 사용자의 선호와 제약 정보를 공유해야 합니다. 이 통신을 위한 프로토콜과 방법을 결정해야 합니다. 구체적으로 비행기 찾기 에이전트는 호텔 예약 에이전트와 여행 날짜를 공유해야 하므로 어떤 에이전트가 정보를 공유하고 어떻게 공유하는지 결정해야 합니다.
- 조정 메커니즘: 에이전트는 사용자의 선호와 제약 조건을 충족하도록 행동을 조정해야 합니다. 예를 들어 사용자가 공항 근처 호텔을 선호하지만 렌터카는 공항에서만 가능하다면 호텔 예약 에이전트와 렌터카 예약 에이전트가 조정해야 합니다. 이처럼 에이전트들이 어떻게 행동을 조정할지 결정해야 합니다.
- 에이전트 아키텍처: 에이전트는 사용자와의 상호작용으로부터 학습하고 의사결정하는 내부 구조가 필요합니다. 예를 들어 비행기 찾기 에이전트는 과거 사용자 선호 기반으로 추천할 비행기를 결정할 수 있어야 합니다. 즉, 에이전트들이 어떻게 의사결정을 하고 학습할지 결정해야 합니다.
- 다중 에이전트 상호작용 가시성: 에이전트들이 서로 어떻게 상호작용하는지 볼 수 있어야 합니다. 이를 위해 활동 추적 도구, 시각화 도구, 성능 지표 등이 필요합니다.
- 다중 에이전트 패턴: 중앙 집중형, 분산형, 하이브리드 구조 등 다중 에이전트 시스템 구현 패턴이 다양합니다. 사용 사례에 맞는 패턴을 선택해야 합니다.
- 휴먼 인 더 루프: 대부분의 경우 사람이 개입할 수 있는데, 언제 인간 개입을 요청할지 에이전트에 지시해야 합니다. 예를 들어 에이전트가 추천하지 않은 특정 호텔이나 비행기를 사용자가 요청하거나 예약 전에 확인을 요구할 수 있습니다.
여러 에이전트들이 어떻게 상호작용하는지 가시성 확보는 매우 중요합니다. 이는 디버깅, 최적화, 시스템 전반의 효율성 확보에 꼭 필요합니다. 이를 위해 활동 추적, 모니터링, 시각화 도구와 성능 지표 등이 필요합니다.
예를 들어 여행 예약의 경우 각 에이전트 상태, 사용자 선호 및 제약 조건, 에이전트 간 상호작용을 보여주는 대시보드가 있을 수 있습니다. 대시보드는 사용자 여행 날짜, 비행기 에이전트 추천 항공편, 호텔 에이전트 추천 호텔, 렌터카 에이전트 추천 차량을 표시해 에이전트 상호작용과 사용자 요구 충족 여부를 명확히 보여줍니다.
각 요소들을 좀 더 자세히 살펴봅시다.
-
로깅 및 모니터링 도구: 각 에이전트 행동을 기록하는 로깅이 필요합니다. 로그는 행동을 수행한 에이전트, 행동 내용, 시간, 결과를 포함해 디버깅 및 최적화에 활용됩니다.
-
시각화 도구: 에이전트 간 상호작용을 직관적으로 보여줄 수 있습니다. 예를 들어, 정보를 주고받는 흐름을 그래프로 표현하여 병목 현상, 비효율성 등의 문제를 파악할 수 있습니다.
-
성능 지표: 다중 에이전트 시스템의 효과를 추적합니다. 작업 완료 시간, 시간당 작업 수, 에이전트 추천 정확도 등을 측정해 개선점을 찾고 최적화할 수 있습니다.
다중 에이전트 앱을 만들 수 있는 몇 가지 구체적인 패턴을 살펴봅시다. 고려할 만한 흥미로운 패턴은 다음과 같습니다:
여러 에이전트가 서로 소통하는 그룹 채팅 애플리케이션을 만들 때 유용한 패턴입니다. 팀 협업, 고객 지원, 소셜 네트워킹에서 일반적으로 사용됩니다.
각 에이전트는 그룹 채팅 내 사용자 역할을 하며, 메시징 프로토콜로 메시지를 주고받습니다. 에이전트들은 그룹 채팅에 메시지를 보내고, 받으며, 다른 에이전트 메시지에 응답합니다.
중앙 서버를 통한 중앙집중형 아키텍처 또는 에이전트 간 직접 메시지 교환하는 분산형 아키텍처로 구현할 수 있습니다.
여러 에이전트가 작업을 서로에게 인계하는 애플리케이션에 유용합니다.
고객 지원, 작업 관리, 워크플로 자동화 등에 일반적으로 사용됩니다.
각 에이전트는 작업이나 워크플로 단계 역할을 하며, 미리 정해진 규칙에 따라 작업을 다른 에이전트에 인계할 수 있습니다.
여러 에이전트가 협력해 사용자에게 추천을 제공할 애플리케이션에 유용합니다.
여러 에이전트가 협력하는 이유는 각 에이전트가 서로 다른 전문성을 갖고 있어 추천 과정에 다양한 방식으로 기여할 수 있기 때문입니다.
예를 들어, 사용자가 주식 시장에서 살 최고의 주식을 추천받고자 할 때를 봅시다.
- 산업 전문가: 한 에이전트는 특정 산업에 전문가일 수 있습니다.
- 기술적 분석: 또 다른 에이전트는 기술적 분석 전문가일 수 있습니다.
- 기본적 분석: 또 다른 에이전트는 기본적 분석 전문가일 수 있습니다. 협력하여 사용자가받는 추천을 더욱 포괄적으로 만들어줍니다.
고객이 제품 환불을 시도하는 경우를 생각해 봅시다. 이 과정에는 여러 에이전트가 관여할 수 있지만, 이 과정을 위한 특정 에이전트와 다른 프로세스에서도 사용할 수 있는 일반 에이전트로 나누어 보겠습니다.
환불 과정에 특정한 에이전트:
환불 과정에 관여할 수 있는 에이전트는 다음과 같습니다:
- 고객 에이전트: 고객을 대표하며 환불 과정을 시작합니다.
- 판매자 에이전트: 판매자를 대표하며 환불을 처리합니다.
- 결제 에이전트: 결제 과정을 대표하며 고객에게 환불을 실행합니다.
- 해결 에이전트: 환불 과정 중 발생하는 문제를 처리합니다.
- 준수 에이전트: 환불 과정이 규정과 정책을 준수하는지 확인합니다.
일반 에이전트:
이 에이전트들은 사업의 다른 부분에서도 사용할 수 있습니다.
- 배송 에이전트: 제품을 판매자에게 반송하는 배송 과정을 담당합니다. 환불 과정뿐 아니라 구매 시 일반 배송에도 사용될 수 있습니다.
- 피드백 에이전트: 고객 피드백을 수집합니다. 환불 과정이 아니더라도 언제든 활용될 수 있습니다.
- 에스컬레이션 에이전트: 문제를 상위 지원 단계로 이관합니다. 어떤 프로세스에서든 필요 시 사용할 수 있습니다.
- 알림 에이전트: 환불 과정 여러 단계에서 고객에게 알림을 보냅니다.
- 분석 에이전트: 환불 관련 데이터를 분석합니다.
- 감사 에이전트: 환불 과정이 올바르게 수행되는지 감사합니다.
- 보고 에이전트: 환불 과정에 관한 보고서를 생성합니다.
- 지식 에이전트: 환불 관련 정보와 사업의 다른 부분 지식을 관리하는 지식 기반을 유지합니다.
- 보안 에이전트: 환불 과정의 보안을 담당합니다.
- 품질 에이전트: 환불 과정의 품질을 보장합니다.
앞서 나열한 에이전트는 환불 과정에 특화된 것들과 사업의 다른 부분에도 사용되는 일반 에이전트를 포함합니다. 이것이 다중 에이전트 시스템에서 어떤 에이전트를 사용할지 결정하는 데 도움이 되길 바랍니다.
고객 지원 프로세스를 위한 다중 에이전트 시스템을 설계하세요. 과정에 관여하는 에이전트들, 그 역할과 책임, 그리고 서로 어떻게 상호작용하는지 식별하세요. 고객 지원 프로세스에 특화된 에이전트와 사업의 다른 부분에서도 사용할 수 있는 일반 에이전트를 모두 고려하세요.
다음 해결책을 읽기 전에 잠시 생각해 보세요. 생각보다 더 많은 에이전트가 필요할 수 있습니다.
TIP: 고객 지원 프로세스의 다양한 단계를 생각해 보고, 모든 시스템에 필요한 에이전트도 고려해 보세요.
다중 에이전트 시스템에 가장 적합한 시나리오는 무엇인가요?
- A1: 한 가지 지식 기반과 소수의 도구를 사용하는 지원 봇이 일반적인 질문에 답합니다.
- A2: 환불 워크플로우는 각각 자체 도구를 가진 별도의 사기, 결제, 준수 역할이 필요하며, 그 결과가 조정되어야 합니다.
- A3: 동일한 간단한 분류 요청이 시간당 수천 번 도착합니다.
단일 에이전트가 보통 더 나은 선택인 경우는 언제인가요?
- A1: 작업이 전문적인 인계 없이 한 세트의 지침과 도구로 처리될 수 있습니다.
- A2: 에이전트가 두 개 이상의 도구에 접근할 수 있습니다.
- A3: 워크플로우는 다른 권한과 독립적인 감사 기록을 가진 별도의 역할을 요구합니다.
이번 강의에서는 다중 에이전트 설계 패턴을 살펴보았으며, 다중 에이전트가 적용되는 시나리오, 단일 에이전트 대비 다중 에이전트 사용의 장점, 다중 에이전트 설계 패턴 구현의 구성 요소, 그리고 여러 에이전트가 어떻게 상호작용하는지 가시성을 확보하는 방법을 다뤘습니다.
Microsoft Foundry Discord에 참여하여 다른 학습자들과 만나고, 오피스 아워에 참석하며, AI 에이전트 질문에 대한 답변을 받아보세요.
면책 조항: 이 문서는 AI 번역 서비스 Co-op Translator를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역은 오류나 부정확한 부분이 있을 수 있음을 유의하시기 바랍니다. 원본 문서의 원어본이 권위 있는 자료로 간주되어야 합니다. 중요한 정보의 경우, 전문가의 인간 번역을 권장합니다. 이 번역 사용으로 인해 발생하는 오해나 잘못된 해석에 대해 당사는 책임을 지지 않습니다.