에이전트 AI 시스템의 설계 패턴 선택

이 문서에서는 에이전트 AI 시스템의 설계 패턴을 선택하는 데 도움이 되는 안내를 제공합니다. 에이전트 설계 패턴은 에이전트형 애플리케이션을 빌드하는 일반적인 아키텍처 접근 방식입니다. 에이전트 설계 패턴은 시스템의 구성요소를 구성하고, 모델을 통합하고, 단일 에이전트 또는 여러 에이전트를 조정하여 워크플로를 완료하는 명확한 프레임워크를 제공합니다.

AI 에이전트는 자율적인 의사 결정과 복잡한 다단계 워크플로 관리가 필요할 수 있는 개방형 문제를 해결하는 애플리케이션에 효과적입니다. 에이전트는 외부 데이터를 사용하여 실시간으로 문제를 해결하고 지식 집약적인 작업을 자동화하는 데 탁월합니다. AI 에이전트는 AI가 어느 정도의 자율성을 가지고 목표 중심 작업을 완료해야 하는 경우에 적합합니다. 다른 사용 사례의 경우 지원 및 생성형 AI 애플리케이션을 사용할 수 있습니다. AI 에이전트와 에이전트가 아닌 AI 애플리케이션의 차이점을 알아보려면 AI 에이전트, AI 어시스턴트, 봇의 차이점은 무엇인가요?를 참고하세요.

이 가이드에서는 에이전트형 AI 시스템과 그 아키텍처가 직접 모델 추론 또는 검색 증강 생성 (RAG)을 사용하는 시스템과 같은 비에이전트형 시스템과 어떻게 다른지에 대한 기본적인 지식이 있다고 가정합니다.

에이전트 패턴 안내 요약은 이 문서 뒷부분의 설계 패턴 비교 섹션을 참고하세요.

설계 프로세스 개요

다음은 에이전트 AI 시스템의 설계 패턴을 선택하는 대략적인 단계입니다. 이러한 단계는 이 문서의 뒷부분에서 자세히 설명합니다.

1. 요구사항 정의: 작업 복잡성, 지연 시간 및 성능 기대치, 비용 예산, 인적 개입 필요성 등 워크로드의 특성을 평가합니다.
2. 일반적인 에이전트 설계 패턴 검토: 이 가이드에서 싱글 에이전트 시스템과 멀티 에이전트 시스템을 모두 포함하는 일반적인 설계 패턴을 알아봅니다.
3. 패턴 선택: 워크로드 특성에 따라 적절한 디자인 패턴을 선택합니다.

이 과정은 일회성 결정이 아닙니다. 워크로드 특성이 변경되거나 요구사항이 발전하거나 새로운 기능이 제공되면 이러한 단계를 주기적으로 다시 검토하여 아키텍처를 개선해야 합니다. Google Cloud

요구사항 정의

다음 질문은 계획에 완벽한 체크리스트가 아닙니다. 이러한 질문을 시작점으로 사용하여 에이전트 시스템의 기본 목표를 파악하고 최적의 설계 패턴을 선택하세요.

• 작업 특성: 작업이 사전 정의된 워크플로 단계로 완료될 수 있나요? 아니면 작업이 개방형인가요? 작업에서 AI 모델을 사용하여 워크플로를 오케스트레이션해야 하나요?
• 지연 시간 및 성능: 정확도 또는 고품질 응답을 희생하더라도 빠르거나 대화형 응답을 우선시해야 하나요? 또는 더 정확하거나 철저한 결과를 얻기 위해 애플리케이션에서 지연을 허용할 수 있나요?
• 비용: 추론 비용 예산은 얼마인가요? 단일 요청에 대해 모델을 여러 번 호출해야 하는 패턴을 지원할 수 있나요?
• 인간의 개입: 작업에 중요한 결정, 안전이 중요한 작업 또는 인간의 판단이 필요한 주관적인 승인이 포함되나요?

워크로드가 예측 가능하거나 고도로 구조화되어 있거나 AI 모델에 대한 단일 호출로 실행할 수 있는 경우 태스크에 에이전트가 없는 솔루션을 살펴보는 것이 비용 효율적일 수 있습니다. 예를 들어 문서를 요약하거나, 텍스트를 번역하거나, 고객 피드백을 분류하는 작업에는 에이전트 워크플로가 필요하지 않을 수 있습니다. 에이전트 인프라가 필요하지 않은 생성형 AI 애플리케이션의 아키텍처 구성요소를 선택하는 방법에 관한 자세한 내용은 생성형 AI 애플리케이션을 위한 모델 및 인프라 선택을 참고하세요.

다음 섹션에서는 신뢰할 수 있고 효과적인 에이전트 AI 시스템을 구축하기 위한 일반적인 에이전트 설계 패턴을 설명합니다.

단일 에이전트 시스템

단일 에이전트 시스템은 AI 모델, 정의된 도구 집합, 포괄적인 시스템 프롬프트를 사용하여 사용자 요청을 자율적으로 처리하거나 특정 작업을 완료합니다. 이 기본 패턴에서 에이전트는 모델의 추론 기능을 사용하여 사용자의 요청을 해석하고, 일련의 단계를 계획하고, 정의된 집합에서 사용할 도구를 결정합니다. 시스템 프롬프트는 핵심 작업, 페르소나, 작업, 각 도구 사용에 관한 구체적인 조건을 정의하여 에이전트의 동작을 형성합니다.

다음 다이어그램은 단일 에이전트 패턴의 대략적인 뷰를 보여줍니다.

단일 에이전트 시스템은 여러 단계와 외부 데이터 액세스가 필요한 작업에 적합합니다. 예를 들어 고객 지원 상담사는 데이터베이스를 쿼리하여 주문 상태를 찾아야 하고, 연구 보조원은 API를 호출하여 최근 뉴스를 요약해야 합니다. 에이전트가 아닌 시스템은 도구를 자율적으로 사용하거나 다단계 계획을 실행하여 최종 답변을 합성할 수 없으므로 이러한 작업을 수행할 수 없습니다.

에이전트 개발 초기 단계인 경우 단일 에이전트로 시작하는 것이 좋습니다. 단일 에이전트 시스템으로 에이전트 개발을 시작하면 더 복잡한 아키텍처 구성요소를 추가하기 전에 에이전트의 핵심 로직, 프롬프트, 도구 정의를 개선하는 데 집중할 수 있습니다.

상담사가 더 많은 도구를 사용하고 작업의 복잡성이 증가하면 상담사의 실적이 떨어질 수 있습니다. 지연 시간 증가, 잘못된 도구 선택 또는 사용, 작업 완료 실패로 관찰될 수 있습니다. Reason and Act (ReAct) 패턴과 같은 기법으로 에이전트의 추론 프로세스를 개선하면 이러한 문제를 완화할 수 있는 경우가 많습니다. 하지만 워크플로에서 상담사가 여러 가지 책임을 관리해야 하는 경우 이러한 기술이 충분하지 않을 수 있습니다. 이러한 경우 전문 에이전트에게 특정 기술을 위임하여 복원력과 성능을 향상시킬 수 있는 멀티 에이전트 시스템을 고려해 보세요.

멀티 에이전트 시스템

멀티 에이전트 시스템은 여러 전문 에이전트를 오케스트레이션하여 단일 에이전트가 쉽게 관리할 수 없는 복잡한 문제를 해결합니다. 핵심 원칙은 큰 목표를 더 작은 하위 작업으로 분해하고 각 하위 작업을 특정 기술이 있는 전담 에이전트에 할당하는 것입니다. 그런 다음 이러한 에이전트는 공동 또는 계층적 워크플로를 통해 상호작용하여 최종 목표를 달성합니다. 멀티 에이전트 패턴은 모놀리식 프롬프트가 있는 단일 에이전트에 비해 전체 시스템의 확장성, 안정성, 유지 관리성을 개선할 수 있는 모듈식 설계를 제공합니다.

다중 에이전트 시스템에서 각 에이전트는 작업을 효과적으로 수행하기 위해 특정 컨텍스트가 필요합니다. 컨텍스트에는 문서, 이전 환경설정, 관련 링크, 대화 기록 또는 운영 제약 조건이 포함될 수 있습니다. 이 정보 흐름을 관리하는 프로세스를 컨텍스트 엔지니어링이라고 합니다. 컨텍스트 엔지니어링에는 특정 에이전트의 컨텍스트 격리, 여러 단계에 걸쳐 정보 유지, 효율성 향상을 위한 대량 데이터 압축과 같은 전략이 포함됩니다.

멀티 에이전트 시스템을 빌드하려면 단일 에이전트 시스템과 비교할 때 추가 평가, 보안, 안정성, 비용 고려사항이 필요합니다. 예를 들어 멀티 에이전트 시스템은 각 전문 에이전트에 대해 정확한 액세스 제어를 구현하고, 에이전트 간 안정적인 통신을 보장하는 강력한 오케스트레이션 시스템을 설계하고, 여러 에이전트 실행의 컴퓨팅 오버헤드로 인한 운영 비용 증가를 관리해야 합니다. 멀티 에이전트 시스템을 빌드하기 위한 참조 아키텍처의 예는 Google Cloud의 멀티 에이전트 AI 시스템을 참고하세요.

순차 패턴

멀티 에이전트 순차 패턴은 한 에이전트의 출력이 다음 에이전트의 직접 입력으로 사용되는 사전 정의된 선형 순서로 일련의 전문 에이전트를 실행합니다. 이 패턴은 하위 에이전트의 오케스트레이션을 위해 AI 모델을 참조하지 않고 사전 정의된 로직에 따라 작동하는 순차적 워크플로 에이전트를 사용합니다.

다음 다이어그램은 다중 에이전트 순차 패턴의 대략적인 뷰를 보여줍니다.

작업 순서가 변경되지 않는 고도로 구조화되고 반복 가능한 프로세스에는 순차적 패턴을 사용합니다. 예를 들어 데이터 처리 파이프라인은 이 패턴을 사용하여 먼저 데이터 추출 에이전트가 원시 데이터를 가져오도록 한 다음 해당 데이터를 데이터 정리 에이전트에 전달하여 형식을 지정하고, 이 에이전트는 정리된 데이터를 데이터 로드 에이전트에 전달하여 데이터베이스에 저장합니다.

순차적 패턴은 AI 모델을 사용하여 작업 워크플로를 오케스트레이션하는 패턴에 비해 지연 시간과 운영 비용을 줄일 수 있습니다. 하지만 이러한 효율성은 유연성을 희생한 결과입니다. 파이프라인의 엄격하고 사전 정의된 구조로 인해 동적 조건에 적응하거나 불필요한 단계를 건너뛰기가 어려우며, 이로 인해 비효율적인 처리가 발생하거나 불필요한 단계가 느린 경우 누적 지연 시간이 길어질 수 있습니다.

병렬 패턴

다중 에이전트 병렬 패턴(동시 패턴이라고도 함)에서는 여러 전문 하위 에이전트가 동시에 독립적으로 작업 또는 하위 작업을 실행합니다. 그런 다음 하위 에이전트의 출력을 종합하여 최종 통합 응답을 생성합니다. 순차 패턴과 마찬가지로 병렬 패턴은 병렬 워크플로 에이전트를 사용하여 하위 에이전트를 오케스트레이션하기 위해 AI 모델을 컨설트하지 않고도 다른 에이전트가 실행되는 방식과 시기를 관리합니다.

다음 다이어그램은 다중 에이전트 병렬 패턴의 대략적인 뷰를 보여줍니다.

하위 작업이 동시에 실행되어 지연 시간을 줄이거나 다양한 관점을 수집할 수 있는 경우 병렬 패턴을 사용합니다(예: 서로 다른 소스에서 데이터를 수집하거나 여러 옵션을 한 번에 평가). 예를 들어 고객 의견을 분석하기 위해 병렬 에이전트는 단일 의견 항목을 감정 분석 에이전트, 키워드 추출 에이전트, 분류 에이전트, 긴급성 감지 에이전트 등 4개의 전문 에이전트에게 동시에 전달할 수 있습니다. 최종 에이전트는 이러한 네 가지 출력을 모아 해당 피드백에 대한 포괄적인 분석을 제공합니다.

병렬 패턴은 여러 소스에서 다양한 정보를 동시에 수집할 수 있으므로 순차적 접근 방식에 비해 전체 지연 시간을 줄일 수 있습니다. 하지만 이 접근 방식은 비용과 복잡성 측면에서 절충이 필요합니다. 여러 에이전트를 병렬로 실행하면 즉각적인 리소스 사용량과 토큰 소비량이 증가하여 운영 비용이 높아질 수 있습니다. 또한 수집 단계에서는 잠재적으로 충돌하는 결과를 합성하기 위해 복잡한 로직이 필요하므로 시스템의 개발 및 유지관리 오버헤드가 증가합니다.

루프 패턴

멀티 에이전트 루프 에이전트 패턴은 특정 종료 조건이 충족될 때까지 전문화된 하위 에이전트의 시퀀스를 반복적으로 실행합니다. 이 패턴은 다른 워크플로 에이전트와 마찬가지로 오케스트레이션을 위해 AI 모델을 컨설트하지 않고 사전 정의된 논리에 따라 작동하는 루프 워크플로 에이전트를 사용합니다. 모든 하위 에이전트가 작업을 완료하면 루프 에이전트가 종료 조건이 충족되었는지 평가합니다. 조건은 최대 반복 횟수 또는 맞춤 상태일 수 있습니다. 종료 조건이 충족되지 않으면 루프 에이전트가 하위 에이전트 시퀀스를 다시 시작합니다. 흐름의 어느 시점에서든 종료 조건이 평가되는 루프 패턴을 구현할 수 있습니다. 콘텐츠를 생성하고 품질 표준을 충족할 때까지 비평가 에이전트가 검토하는 등 반복적인 개선이나 자체 수정이 필요한 작업에는 루프 패턴을 사용하세요.

다음 다이어그램은 멀티 에이전트 루프 패턴의 대략적인 뷰를 보여줍니다.

루프 에이전트 패턴은 복잡한 반복 워크플로를 빌드하는 방법을 제공합니다. 이를 통해 에이전트는 자체 작업을 개선하고 특정 품질이나 상태가 달성될 때까지 계속 처리할 수 있습니다. 하지만 이 패턴의 주요 트레이드오프는 무한 루프의 위험입니다. 종료 조건이 올바르게 정의되지 않았거나 하위 에이전트가 중지하는 데 필요한 상태를 생성하지 못하면 루프가 무한정 실행될 수 있습니다. 이로 인해 운영 비용이 과도하게 발생하고 리소스 소비가 많아지며 시스템이 멈출 수 있습니다.

패턴 검토 및 비평

생성기 및 비평가 패턴이라고도 하는 다중 에이전트 검토 및 비평 패턴은 일반적으로 순차적 워크플로에서 두 개의 전문 에이전트를 사용하여 생성된 콘텐츠의 품질과 신뢰성을 개선합니다. 검토 및 비평 패턴은 루프 에이전트 패턴의 구현입니다.

검토 및 비평 패턴에서 생성기 에이전트는 코드 블록이나 문서 요약과 같은 초기 출력을 생성합니다. 그런 다음 비평가 에이전트가 사실에 기반한 정확성, 서식 규칙 준수, 안전 가이드라인과 같은 사전 정의된 기준에 따라 이 출력을 평가합니다. 평가에 따라 비평가는 콘텐츠를 승인하거나 거부하거나 수정 의견과 함께 생성자에게 반환할 수 있습니다.

다음 다이어그램은 다중 에이전트 검토 및 비평 패턴의 대략적인 뷰를 보여줍니다.

이 패턴은 출력이 사용자에게 표시되거나 다운스트림 프로세스에서 사용되기 전에 매우 정확해야 하거나 엄격한 제약 조건을 준수해야 하는 작업에 적합합니다. 예를 들어 코드 생성 워크플로에서 생성기 에이전트는 사용자의 요청을 처리하는 함수를 작성할 수 있습니다. 그런 다음 생성된 코드는 보안 감사자 역할을 하는 비평가 에이전트에 전달됩니다. 비평가 에이전트의 역할은 코드가 사용 승인을 받기 전에 보안 취약점을 스캔하거나 모든 단위 테스트를 통과하는지 확인하는 등 일련의 제약 조건에 대해 코드를 확인하는 것입니다.

검토 및 비평 패턴은 전용 검증 단계를 추가하므로 출력 품질, 정확성, 신뢰성을 개선할 수 있습니다. 하지만 이러한 품질 보증에는 지연 시간 증가 및 운영 비용이라는 직접적인 비용이 따릅니다. 워크플로에는 비평가의 평가를 위해 하나 이상의 추가 모델 호출이 필요합니다. 콘텐츠가 개선을 위해 다시 전송되는 수정 루프가 프로세스에 포함된 경우 각 반복마다 지연 시간과 비용이 누적됩니다.

반복적인 개선 패턴

반복적 개선 패턴은 루핑 메커니즘을 사용하여 여러 사이클에 걸쳐 출력을 점진적으로 개선합니다. 반복적 개선 패턴은 루프 에이전트 패턴의 구현입니다.

이 패턴에서는 하나 이상의 에이전트가 루프 내에서 작동하여 각 반복 중에 세션 상태에 저장된 결과를 수정합니다. 이 프로세스는 출력이 미리 정의된 품질 기준을 충족하거나 최대 반복 횟수에 도달할 때까지 계속됩니다. 이렇게 하면 무한 루프를 방지할 수 있습니다.

다음 다이어그램은 다중 에이전트 반복 개선 패턴의 대략적인 뷰를 보여줍니다.

이 패턴은 출력을 단일 단계로 달성하기 어려운 복잡한 생성 작업에 적합합니다. 이러한 작업의 예로는 코드 작성 및 디버깅, 자세한 다중 파트 계획 개발, 긴 형식 문서 초안 작성 및 수정이 있습니다. 예를 들어 창작 워크플로에서 에이전트는 블로그 게시물의 초안을 생성하고, 흐름과 어조에 대해 초안을 비판한 다음, 해당 비판을 기반으로 초안을 다시 작성할 수 있습니다. 이 프로세스는 에이전트의 작업이 미리 정의된 품질 표준을 충족하거나 반복이 최대 반복 횟수에 도달할 때까지 루프에서 반복됩니다.

반복적 개선 패턴은 단일 단계에서는 달성하기 어려운 매우 복잡하거나 세련된 출력을 생성할 수 있습니다. 하지만 루핑 메커니즘은 각 사이클마다 지연 시간과 운영 비용을 직접적으로 증가시킵니다. 이 패턴은 과도한 비용이나 제어되지 않은 실행을 방지하기 위해 품질 평가나 최대 반복 한도와 같은 신중하게 설계된 종료 조건이 필요하므로 아키텍처 복잡성도 추가합니다.

코디네이터 패턴

멀티 에이전트 코디네이터 패턴은 중앙 에이전트인 코디네이터를 사용하여 워크플로를 안내합니다. 코디네이터는 사용자의 요청을 분석하고 하위 작업으로 분해한 다음 각 하위 작업을 실행을 위해 전문 에이전트에 디스패치합니다. 각 전문 에이전트는 데이터베이스 쿼리 또는 API 호출과 같은 특정 기능에 관한 전문가입니다.

코디네이터 패턴의 특징은 AI 모델을 사용하여 작업을 오케스트레이션하고 동적으로 라우팅한다는 점입니다. 반면 병렬 패턴은 AI 모델 오케스트레이션 없이 동시 실행을 위해 작업을 디스패치하는 하드코딩된 워크플로를 사용합니다.

다음 다이어그램은 멀티 에이전트 코디네이터 패턴의 대략적인 뷰를 보여줍니다.

적응형 라우팅이 필요한 구조화된 비즈니스 프로세스를 자동화하려면 코디네이터 패턴을 사용하세요. 예를 들어 고객 서비스 에이전트가 코디네이터 역할을 할 수 있습니다. 코디네이터 상담사는 요청을 분석하여 주문 상태 요청인지, 제품 반품인지, 환불 요청인지 확인합니다. 요청 유형에 따라 코디네이터는 작업을 적절한 전문 에이전트에게 라우팅합니다.

코디네이터 패턴은 더 엄격하고 사전 정의된 워크플로에 비해 유연성을 제공합니다. 모델을 사용하여 작업을 라우팅하면 코디네이터가 더 다양한 입력을 처리하고 런타임에 워크플로를 조정할 수 있습니다. 하지만 이 접근 방식에는 단점도 있습니다. 코디네이터와 각 전문 에이전트는 추론을 위해 모델을 사용하므로 이 패턴은 단일 에이전트 시스템보다 더 많은 모델 호출을 발생시킵니다. 코디네이터 패턴은 추론의 품질을 높일 수 있지만 단일 에이전트 시스템과 비교할 때 토큰 처리량, 운영 비용, 전체 지연 시간도 증가합니다.

계층적 작업 분해 패턴

멀티 에이전트 계층적 작업 분해 패턴은 광범위한 계획이 필요한 복잡한 문제를 해결하기 위해 에이전트를 다단계 계층 구조로 구성합니다. 계층적 작업 분해 패턴은 코디네이터 패턴의 구현입니다. 최상위 상위 또는 루트 에이전트는 복잡한 작업을 수신하며 작업을 관리 가능한 여러 개의 작은 하위 작업으로 분해하는 역할을 합니다. 루트 에이전트는 각 하위 작업을 하위 수준의 전문 하위 에이전트에게 위임합니다. 이 프로세스는 여러 레이어를 통해 반복될 수 있으며, 에이전트는 최하위 수준의 작업자 에이전트가 직접 실행할 수 있을 만큼 작업이 간단해질 때까지 할당된 작업을 점진적으로 분해합니다.

다음 다이어그램은 멀티 에이전트 계층적 작업 분해 패턴의 대략적인 뷰를 보여줍니다.

연구, 계획, 종합과 같은 다단계 추론이 필요한 모호하고 개방적인 문제에는 계층적 작업 분해 패턴을 사용하세요. 예를 들어 복잡한 조사 프로젝트를 완료하기 위해 코디네이터 에이전트는 정보 수집, 결과 분석, 최종 보고서 합성 등 여러 작업으로 상위 수준 목표를 분해합니다. 그런 다음 코디네이터 에이전트는 이러한 작업을 데이터 수집 에이전트, 분석 에이전트, 보고서 작성 에이전트와 같은 전문 하위 에이전트에게 위임하여 실행하거나 추가로 분해합니다.

계층적 작업 분해 패턴은 매우 복잡하고 모호한 문제를 해결하는 데 이상적입니다. 관리 가능한 하위 작업으로 체계적으로 분해하기 때문입니다. 이 패턴을 사용하면 단순한 패턴보다 더 포괄적이고 고품질의 결과를 얻을 수 있습니다. 하지만 이 고급 기능에는 상당한 절충이 필요합니다. 다단계 구조는 상당한 아키텍처 복잡성을 추가하므로 시스템을 설계, 디버그, 유지관리하기가 더 어려워집니다. 또한 위임과 추론이 여러 계층으로 이루어져 모델 호출 수가 많아지므로 다른 패턴에 비해 전체 지연 시간과 운영 비용이 크게 증가합니다.

스웜 패턴

다중 에이전트 스웜 패턴은 공동작업적인 all-to-all 통신 접근 방식을 사용합니다. 이 패턴에서는 여러 전문 에이전트가 함께 작동하여 복잡한 문제의 솔루션을 반복적으로 개선합니다.

다음 다이어그램은 다중 에이전트 스웜 패턴의 대략적인 뷰를 보여줍니다.

스웜 패턴은 디스패처 에이전트를 사용하여 사용자 요청을 전문 에이전트의 공동작업 그룹으로 라우팅합니다. 디스패처 에이전트는 요청을 해석하고 스웜에서 작업을 시작하는 데 가장 적합한 에이전트를 결정합니다. 이 패턴에서 각 에이전트는 다른 모든 에이전트와 통신할 수 있으므로 발견한 내용을 공유하고, 제안을 비판하고, 서로의 작업을 기반으로 솔루션을 반복적으로 개선할 수 있습니다. 스웜의 모든 상담사는 다음 단계를 처리하는 데 더 적합하다고 판단되는 다른 상담사에게 작업을 인계할 수 있으며, 코디네이터 상담사를 통해 최종 응답을 사용자에게 전달할 수 있습니다.

일반적으로 스웜에는 프로세스를 추적할 중앙 감독자나 코디네이터 에이전트가 없습니다. 디스패처 에이전트는 코디네이터 패턴과 달리 에이전트 워크플로를 오케스트레이션하지 않습니다. 대신 디스패처 에이전트는 스웜 하위 에이전트와 사용자 간의 커뮤니케이션을 지원합니다. 스웜이 결국 중지되고 결과를 반환하도록 하려면 명시적 종료 조건을 정의해야 합니다. 이 조건은 종종 최대 반복 횟수, 시간 제한 또는 합의 도달과 같은 특정 목표 달성입니다.

토론과 반복적인 개선이 필요한 모호하거나 매우 복잡한 문제에는 스웜 패턴을 사용하세요. 예를 들어 신제품 설계에는 시장 조사원 에이전트, 엔지니어링 에이전트, 재무 모델링 에이전트가 필요할 수 있습니다. 에이전트는 초기 아이디어를 공유하고, 기능과 비용 간의 절충안을 논의하고, 경쟁하는 모든 요구사항의 균형을 맞추는 최종 설계 사양에 공동으로 수렴합니다.

스웜 패턴은 전문가로 구성된 협업 팀을 시뮬레이션하므로 매우 높은 품질의 창의적인 솔루션을 생성할 수 있습니다. 하지만 구현하기에 가장 복잡하고 비용이 많이 드는 멀티 에이전트 패턴입니다. AI 모델을 사용하여 오케스트레이션하는 에이전트가 없으면 비생산적인 루프가 발생하거나 솔루션에 수렴하지 못할 위험이 있습니다. 따라서 복잡한 에이전트 간 통신을 관리하고, 반복적인 워크플로를 제어하고, 여러 에이전트 간의 동적인 다중 턴 대화를 실행하는 데 따르는 상당한 운영 비용과 지연 시간을 처리하기 위한 정교한 로직을 설계해야 합니다.

추론 및 행동 (ReAct) 패턴

ReAct 패턴은 AI 모델을 사용하여 사고 과정과 작업을 자연어 상호작용의 시퀀스로 구성하는 접근 방식입니다. 이 패턴에서 에이전트는 종료 조건이 충족될 때까지 생각, 행동, 관찰의 반복 루프에서 작동합니다.

• 생각: 모델이 작업에 대해 추론하고 다음에 할 일을 결정합니다. 모델은 수집된 모든 정보를 평가하여 사용자의 요청에 완전히 답변했는지 확인합니다.
• 조치: 모델은 사고 과정에 따라 다음 두 가지 조치 중 하나를 취합니다.
  • 작업이 완료되지 않으면 도구를 선택한 다음 추가 정보를 수집하기 위한 쿼리를 구성합니다.
  • 작업이 완료되면 사용자에게 보낼 최종 답변을 구성하여 루프를 종료합니다.
• 관찰: 모델이 도구의 출력을 수신하고 관련 정보를 메모리에 저장합니다. 모델은 관련 출력을 저장하므로 이전 관찰을 기반으로 빌드할 수 있어 모델이 반복되거나 컨텍스트를 잃는 것을 방지할 수 있습니다.

에이전트가 결정적인 답변을 찾거나, 사전 설정된 최대 반복 횟수에 도달하거나, 계속 진행할 수 없는 오류가 발생하면 반복 루프가 종료됩니다. 이 반복 루프를 통해 에이전트는 최종 답변을 향해 작업하면서 계획을 동적으로 빌드하고, 증거를 수집하고, 접근 방식을 조정할 수 있습니다.

다음 다이어그램은 ReAct 패턴의 대략적인 뷰를 보여줍니다.

지속적인 계획과 적응이 필요한 복잡하고 동적인 작업에는 ReAct 패턴을 사용하세요. 예를 들어 초기 상태에서 목표 상태로 전환하는 경로를 생성해야 하는 로봇 에이전트를 생각해 보세요.

• 생각: 모델이 현재 상태에서 목표 상태로 전환하는 최적의 경로에 대해 추론합니다. 사고 과정에서 모델은 시간이나 에너지와 같은 측정항목을 최적화합니다.
• 작업: 모델은 계산된 경로 세그먼트를 따라 이동하여 계획의 다음 단계를 실행합니다.
• 관찰: 모델이 환경의 새로운 상태를 관찰하고 저장합니다. 모델은 새로운 위치와 인식한 환경의 변경사항을 저장합니다.

이 루프를 통해 에이전트는 새로운 장애물을 피하거나 교통 규정을 준수하는 등 동적 제약 조건을 준수할 수 있습니다. 새로운 관찰을 기반으로 계획을 지속적으로 업데이트하기 때문입니다. 에이전트는 목표에 도달하거나 오류가 발생할 때까지 반복 루프를 계속합니다.

단일 ReAct 에이전트는 복잡한 멀티 에이전트 시스템보다 구현하고 유지하는 것이 더 간단하고 비용 효율적일 수 있습니다. 모델 사고는 모델의 추론에 관한 스크립트를 제공하여 디버깅에 도움이 됩니다. 하지만 이러한 유연성에는 절충이 필요합니다. 루프의 반복적인 다단계 특성으로 인해 단일 쿼리에 비해 엔드 투 엔드 지연 시간이 길어질 수 있습니다. 또한 에이전트의 효과는 AI 모델의 추론 품질에 크게 좌우됩니다. 따라서 한 관찰 단계에서 도구의 오류나 잘못된 결과가 전파되어 최종 답변이 잘못될 수 있습니다.

인간 참여형(Human-In-The-Loop) 패턴

인간 참여형 패턴은 인간의 개입 지점을 에이전트의 워크플로에 직접 통합합니다. 사전 정의된 체크포인트에서 에이전트는 실행을 일시중지하고 외부 시스템을 호출하여 사람이 작업을 검토하기를 기다립니다. 이 패턴을 사용하면 에이전트가 계속하기 전에 사람이 결정을 승인하거나, 오류를 수정하거나, 필요한 입력을 제공할 수 있습니다.

다음 다이어그램은 사람 참여형 패턴의 대략적인 모습을 보여줍니다.

인간의 감독, 주관적인 판단 또는 중요한 작업에 대한 최종 승인이 필요한 작업에는 인간 참여형 패턴을 사용하세요. 이러한 작업에는 대규모 금융 거래 승인, 민감한 문서의 요약 확인, 생성된 광고 소재 콘텐츠에 대한 주관적인 의견 제공이 포함됩니다. 예를 들어 에이전트에게 연구를 위해 환자 데이터 세트를 익명 처리하는 작업이 주어질 수 있습니다. 에이전트는 모든 보호 건강 정보를 자동으로 식별하고 수정하지만 최종 체크포인트에서 일시중지됩니다. 그런 다음 인적 규정 준수 담당자가 데이터 세트를 수동으로 검증하고 출시를 승인할 때까지 기다리므로 민감한 정보가 노출되지 않습니다.

인간 참여형 패턴은 워크플로 내의 중요한 결정 지점에 인간의 판단을 삽입하여 안전성과 신뢰성을 향상합니다. 이 패턴은 사용자 상호작용을 위한 외부 시스템을 빌드하고 유지관리해야 하므로 아키텍처가 매우 복잡해질 수 있습니다.

맞춤 로직 패턴

맞춤 로직 패턴은 워크플로 설계에서 최대 유연성을 제공합니다. 이 접근 방식을 사용하면 조건문과 같은 코드를 사용하여 여러 분기 경로가 있는 복잡한 워크플로를 만드는 특정 오케스트레이션 로직을 구현할 수 있습니다.

다음 다이어그램은 환불 프로세스를 포착하기 위해 맞춤 로직 패턴을 사용하는 예를 보여줍니다.

위 다이어그램에서 예시 고객 환불 상담사의 에이전트 워크플로는 다음과 같습니다.

1. 사용자가 코디네이터 에이전트 역할을 하는 고객 환불 에이전트에게 질문을 보냅니다.
2. 코디네이터의 맞춤 로직은 먼저 병렬 검증 도구 에이전트를 호출합니다. 이 에이전트는 구매자 검증 도구 에이전트와 환불 자격 요건 에이전트라는 두 개의 하위 에이전트를 동시에 디스패치합니다.
3. 결과가 수집되면 코디네이터 에이전트가 도구를 실행하여 요청이 환불 대상인지 확인합니다.
   1. 사용자가 자격 요건을 충족하는 경우 코디네이터는 작업을 환불 처리 상담사에게 라우팅하고, 상담사는 process_refund 도구를 호출합니다.
   2. 사용자가 자격 요건을 충족하지 않으면 코디네이터는 스토어 크레딧 상담사와 프로세스 크레딧 결정 상담사로 시작하는 별도의 순차적 흐름으로 작업을 라우팅합니다.
4. 어떤 경로를 선택하든 그 결과는 최종 응답 에이전트에게 전송되어 사용자를 위한 답변을 구성합니다.

고객 환불 에이전트 예시에는 다른 패턴에서 제공하는 구조화된 접근 방식을 넘어선 논리 수준 오케스트레이션을 위한 고유한 솔루션이 필요합니다. 이 워크플로는 병렬 검사를 실행한 다음 완전히 다른 두 다운스트림 프로세스로 라우팅되는 맞춤 조건부 분기를 실행하므로 패턴이 혼합됩니다. 이러한 복잡한 혼합 패턴 워크플로는 맞춤 로직 패턴에 이상적인 사용 사례입니다.

에이전트의 실행을 세부적으로 제어해야 하거나 워크플로가 이 문서에 설명된 다른 패턴 중 하나에 맞지 않는 경우 맞춤 로직 패턴을 사용합니다. 하지만 이 접근 방식은 개발 및 유지관리 복잡성을 증가시킵니다. 전체 오케스트레이션 흐름을 설계, 구현, 디버깅해야 하므로 에이전트 개발 키트 (ADK)와 같은 에이전트 개발 도구에서 지원하는 사전 정의된 패턴을 사용하는 것보다 개발 노력이 더 많이 필요하고 오류가 발생하기 쉽습니다.

맞춤 에이전트 및 ADK를 사용하여 맞춤 로직을 구현하는 방법에 관한 자세한 내용은 맞춤 에이전트를 참고하세요.

디자인 패턴 비교

에이전트 패턴을 선택하는 것은 기본적인 아키텍처 결정입니다. 각 패턴은 유연성, 복잡성, 성능 면에서 서로 다른 절충안을 제공합니다. 워크로드에 적합한 패턴을 확인하려면 다음 섹션의 설계 패턴을 고려하세요.

결정론적 워크플로

결정적인 워크플로에는 예측 가능하고 순차적이며 시작부터 종료까지 명확하게 정의된 워크플로 경로가 있는 작업이 포함됩니다. 작업의 단계는 미리 알려져 있으며 프로세스는 한 실행에서 다음 실행으로 크게 변경되지 않습니다. 다음은 결정적인 워크플로의 에이전트 설계 패턴입니다.

워크로드 특성	에이전트 설계 패턴
미리 정의된 엄격한 워크플로를 따르는 다단계 작업 모델 오케스트레이션이 필요하지 않습니다. 고정된 작업 순서 한 에이전트의 출력은 시퀀스에 있는 다음 에이전트의 직접 입력입니다.	멀티 에이전트 순차 패턴
동시에 실행할 수 있는 독립적인 작업입니다. 모델 오케스트레이션이 필요하지 않습니다. 하위 작업을 동시에 실행하여 전체 지연 시간을 줄입니다.	다중 에이전트 병렬 패턴
한 번에 완료하기 어려운 개방형 또는 복잡한 생성 작업 상담사가 여러 주기에 걸쳐 출력을 점진적으로 개선해야 합니다. 모델 오케스트레이션이 필요하지 않습니다. 지연 시간보다 출력 품질을 우선시합니다.	다중 에이전트 반복 개선 패턴

동적 오케스트레이션이 필요한 워크플로

동적 오케스트레이션이 필요한 워크플로에는 상담사가 진행하는 가장 좋은 방법을 결정해야 하는 복잡한 문제가 포함됩니다. 에이전트형 AI 시스템은 사전 정의된 스크립트 없이 작업을 동적으로 계획하고, 위임하고, 조정해야 합니다. 자율적이고 동적인 오케스트레이션이 필요한 워크플로의 에이전트 설계 패턴은 다음과 같습니다.

워크로드 특성	에이전트 설계 패턴
외부 도구를 사용해야 하는 구조화된 다단계 작업 개념 증명으로 솔루션의 프로토타입을 빠르게 개발해야 합니다.	단일 에이전트 패턴
다양한 입력이 있는 구조화된 작업을 위해 적절한 전문 하위 에이전트로의 동적 라우팅이 필요합니다. 작업을 적절한 하위 에이전트로 안내할 수 있도록 코디네이터 AI 모델을 여러 번 호출하여 지연 시간이 길어집니다. 코디네이터 에이전트에 대한 여러 호출로 인해 높은 비용이 발생할 수 있습니다.	다중 에이전트 코디네이터 패턴
복잡하고, 개방적이며, 모호한 작업을 위해서는 다단계 모델 오케스트레이션이 필요합니다. 모호성을 분해하는 것이 주요 과제인 경우 포괄적이고 고품질의 결과가 필요합니다. 추론을 위해 AI 모델을 여러 번 호출하는 중첩된 다단계 분해로 인한 높은 지연 시간	멀티 에이전트 계층적 작업 분해 패턴
매우 복잡하거나, 개방형이거나, 모호한 작업에는 여러 전문 상담사의 공동 토론과 반복적인 개선이 필요합니다. 포괄적이거나 창의적인 솔루션을 만들기 위해 다양한 관점을 종합하는 것을 우선시합니다. 에이전트 간의 동적 전체 통신으로 인해 지연 시간과 운영 비용이 높습니다.	다중 에이전트 스웜 패턴

반복이 포함된 워크플로

반복이 포함된 워크플로에는 개선, 피드백, 향상 주기를 통해 최종 결과물을 달성하는 작업이 포함됩니다. 다음은 반복이 포함된 워크플로의 에이전트 설계 패턴입니다.

워크로드 특성	에이전트 설계 패턴
에이전트가 복잡하고, 개방적이며, 동적인 작업을 위한 계획을 빌드하거나 적응시키기 위해 반복적으로 추론하고, 행동하고, 관찰해야 합니다. 지연 시간보다 더 정확하고 철저한 결과를 우선시합니다.	ReAct 패턴
에이전트가 종료 조건을 충족할 때까지 자동 검사와 같은 사전 정의된 작업을 반복하는 모니터링 또는 폴링 작업이 필요합니다. 종료 조건이 충족되기를 기다리는 동안 예측할 수 없거나 장기 실행되는 지연 시간	다중 에이전트 루프 패턴
태스크를 완료하기 전에 별도의 유효성 검사 단계가 필요합니다.	다중 에이전트 검토 및 비평 패턴
한 번에 완료하기 어려운 개방형 또는 복잡한 생성 작업 상담사가 여러 주기에 걸쳐 출력을 점진적으로 개선해야 합니다. 모델 오케스트레이션이 필요하지 않습니다. 지연 시간보다 출력 품질을 우선시합니다.	다중 에이전트 반복 개선 패턴

특별한 요구사항이 있는 워크플로

특별한 요구사항이 있는 워크플로에는 일반적인 에이전트 패턴을 따르지 않는 작업이 포함됩니다. 작업에 고유한 비즈니스 로직이 포함될 수도 있고, 중요한 시점에 사람의 판단과 개입이 필요할 수도 있습니다. 에이전트형 AI 시스템은 단일한 특정 목적으로 설계된 맞춤형 머신입니다. 다음은 특별한 요구사항이 있는 워크플로의 에이전트 설계 패턴입니다.

워크로드 특성	에이전트 설계 패턴
안전, 신뢰성, 규정 준수 요구사항이 포함될 수 있는 고위험 또는 주관적인 작업으로 인해 사람의 감독이 필요합니다.	인간 참여형(Human-In-The-Loop) 패턴
직접적인 선형 시퀀스를 넘어선 복잡한 분기 로직 미리 정의된 규칙과 모델 추론을 혼합하려면 최대한의 제어가 필요합니다. 표준 템플릿에 맞지 않는 워크플로에 세부적인 프로세스 제어가 필요합니다.	맞춤 로직 패턴

다음 단계

• ADK 기본 요소를 사용하여 멀티 에이전트 시스템을 구성하고 관리하는 방법을 자세히 알아보세요.
• Cloud Run에서 AI 앱 및 에이전트를 호스팅하는 방법을 알아봅니다.
• Agentic Design Patterns: A Hands-On Guide to Building Intelligent Systems에 대해 자세히 알아보세요.
• 에이전트 개발 키트로 에이전트를 빌드하는 방법을 알아봅니다.
• Google Cloud에서 멀티 에이전트 AI 시스템을 빌드하는 방법을 자세히 알아보세요.
• 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.

참여자

저자: 사만다 헤 | 테크니컬 라이터

기타 참여자:

• 압둘 살레 | 소프트웨어 엔지니어
• Amina Mansour | Cloud Platform 평가팀 책임자
• Amit Maraj | 개발자 관계 엔지니어
• 케이시 웨스트 | 아키텍처 애드보킷, Google Cloud
• 잭 워더스푼 | Developer Advocate
• 조 페르난데스 | 직원 테크니컬 라이터
• 조 샤이리 | Cloud Developer Relations Manager
• 칼 바인마이스터 | Cloud 제품 개발자 관계 책임자
• 저자: 쿠마르 다나고팔 | 크로스 프로덕트 솔루션 개발자
• 리사 셴 | 선임 아웃바운드 제품 관리자, Google Cloud
• 맨디 그로버 | 아키텍처 센터 책임자
• 마크 루 | 테크니컬 라이터
• 메건 오키프 | Developer Advocate
• 올리비에 부르주아 | 개발자 관계 엔지니어
• 시르 메이르 라도르 | 개발자 관계 엔지니어링 관리자
• 블라드 콜레스니코프 | 개발자 관계팀 엔지니어