기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에이전트가 다중 테넌시 충족

에이전트를 특정 도메인 또는 비즈니스 문제의 요구 사항을 지원하기 위해 조합된 일련의 자율 구성 요소로 간주하는 빌딩 블록으로 생각하기 쉽습니다. 더 흥미로운 것은 공급자가 이러한 에이전트를 패키징하고 사용하는 방법을 생각하기 시작하는 것입니다. 대부분의 측면에서 에이전트는 비즈니스 비용 및 수익의 출처가 됩니다. 에이전트 공급자는 서비스를 사용하는 다양한 페르소나, 페르소나의 소비 프로필, 에이전트 공급자가 소비자에 맞는 요금 및 계층화 모델을 생성할 수 있는 수익화 전략을 고려해야 합니다.

에이전트 공급자는 고객 요구 사항에 맞게 에이전트를 배포하기 위한 여러 모델을 지원할 수 있습니다. 다음 다이어그램은 두 가지 주요 에이전트 배포 모델의 개념적 보기를 보여줍니다.

다이어그램의 왼쪽에는 고객 전용 에이전트 모델이 나와 있습니다. 에이전트 공급자는 온보딩된 각 고객에 대해 별도의 에이전트 인스턴스를 배포하여 에이전트를 빌드합니다. 이 접근 방식을 사용하면 에이전트의 기능과 지식을 얻는 능력이 특정 고객의 환경 범위로 제한됩니다. 이는 결국 전용 고객 환경 지원의 일부 복잡성과 이점을 상속하는 고객별 경험을 나타냅니다.

반대로 다이어그램 오른쪽에 있는 다이어그램에는 공급자의 환경에 배포된 단일 에이전트가 있습니다. 에이전트는 여러 고객의 요청을 처리하여 모든 고객의 집단적 경험을 기반으로 진화하고 학습합니다. 추가된 각 신규 고객은 에이전트의 또 다른 유효한 클라이언트를 나타냅니다. 에이전트는 클라이언트의 요구 사항을 지원하기 위해 공유 구문을 사용하여 서비스형 에이전트(AaaS) 모델처럼 실행됩니다. 두 인스턴스 모두에서 에이전트 소비자는 애플리케이션, 시스템 또는 다른 에이전트일 수 있습니다.

AaaS 모델을 보는 방법에는 두 가지가 있습니다. 위의 모델은 모든 고객에게 동일한 경험을 제공합니다. 즉, 에이전트의 내부에는 요청 클라이언트의 컨텍스트를 고려하는 전문화 수준이 포함되지 않습니다. 일반적으로이 모드에서는 에이전트의 범위, 목표 및 가치의 특성이 모든 클라이언트에 보편적으로 적용되는 공유 리소스, 지식 및 결과 집합을 중심으로 한다는 가정이 있습니다. 

AaaS에 대한 대체 접근 방식은 클라이언트의 컨텍스트가 에이전트의 경험과 구현에 영향을 미치는 경우입니다. 다음 다이어그램은이 컨텍스트에서 AaaS 에이전트 공간의 개념적 보기를 제공합니다.

이 AaaS 보기에서 수신 요청의 오리진과 컨텍스트는 에이전트의 발자국에 상당한 영향을 미칩니다. 에이전트의 기본 구현의 일부인 리소스, 작업 및 도구는 수신되는 테넌트 요청마다 다를 수 있습니다. 에이전트의 가치는 테넌트 컨텍스트를 사용하여 테넌트 상태, 지식 및 기타 요인의 영향을 받는 작업과 결과에 도달하는 능력에 연결됩니다. 일부 요청은 고유한 테넌트 결과를 산출할 수 있으며, 다른 요청은 보다 맞춤화된 테넌트별 결과를 산출할 수 있습니다. 이렇게 하면 에이전트의 학습 능력에 새로운 차원이 추가되며, 여기에는 보다 맥락적인 학습과 목표 결과를 개선하는 지식 획득 및 적용이 포함될 수 있습니다.

공급자의 경우 AaaS 모델은 많은 이점을 제공합니다. 여러 고객이 단일 에이전트를 사용하므로 공급자는 규모의 경제를 달성하고, 운영 효율성을 높이고, 비용을 제어하고, 통합 관리 환경을 구축할 수 있는 더 나은 기회를 얻을 수 있습니다. 이로 인해 에이전트 비즈니스의 민첩성, 혁신 및 성장이 향상될 가능성이 있습니다.

이러한 품질은 서비스형 소프트웨어(SaaS) 모델 채택을 주도하는 동일한 원칙과 겹칩니다. 기본적으로 AaaS 모델은 SaaS 환경에서 발견되는 동일한 규모, 복원력, 격리, 온보딩 및 운영 속성을 많이 상속하는 다중 테넌트 서비스로 구축됩니다. 많은 측면에서 AaaS 경험은 SaaS 공급자가 사용하는 전략과 관행에서 크게 차용되지만 이러한 용어를 구분하는 것이 합리적입니다. 이를 위해 주로 멀티테넌트 지원이 필요한 에이전트 구축 및 운영에 따른 영향에 중점을 둡니다.

모든 사용자를 동등하게 취급할 수 있고 영구적, 민감한 또는 고객별 데이터 관리가 필요하지 않은 시스템의 경우 테넌시 개념은 에이전트에 거의 영향을 미치지 않습니다. 데이터 격리, 사용자 지정 및 컨텍스트 인식을 유지하면서 여러 고객에게 서비스를 제공할 것으로 예상되는 시스템의 경우 여러 테넌트를 지원하는 것이 에이전트의 설계, 전략 및 목표의 필수 요소일 수 있습니다. 다음 다이어그램은 에이전트 환경에서 다중 테넌시를 사용하는 방법을 보여줍니다.

이 다이어그램의 왼쪽에는 클래식 멀티 테넌트 아키텍처가 있습니다. 여기에는 웹 애플리케이션과 비즈니스 로직을 구현하는 일련의 마이크로서비스가 포함됩니다. 여러 테넌트가이 환경의 공유 인프라를 사용하여 진화하는 테넌트 인구의 변화하는 워크로드에 맞게 확장합니다. 환경은 모든 테넌트에 대해 단일 창을 통해 운영 및 관리됩니다.

이 멘탈 모델이이 다이어그램의 오른쪽에 있는 에이전트에 매핑되는 방식을 상상해 보세요. 한 에이전트는 하나 이상의 테넌트가 사용하는 AaaS 모델을 실행합니다. 한 에이전트의 단일 인스턴스가 여러 테넌트의 요청을 처리해야 하기 때문에 에이전트 간에 테넌트 컨텍스트가 흐르는 여러 공급자의 에이전트일 수 있습니다.

이 다이어그램의 중간에 있는 예제는 에이전트가 전체 SaaS 경험의 일부인 하이브리드 모델입니다. 시스템의 일부 부분은 보다 전통적인 모델로 구현되며 시스템의 다른 부분은 에이전트를 사용합니다. 이 패턴은 많은 SaaS 제품, 특히 에이전트 경험으로 전환하는 조직에 공통적일 수 있습니다. 모든 시스템이 순수 AaaS로 제공되는 것은 아니므로이 모델은 일반적으로 유지됩니다. 또한 다중 테넌시는 모델의 에이전트에도 계속 적용됩니다. 에이전트는 시스템 내에 포함될 수 있지만 여전히 여러 테넌트의 요청을 처리할 수 있습니다.

다중 테넌시가 실제로 중요한지 묻는 것은 당연합니다. 에이전트가 요청을 처리한다고 주장할 수 있으므로 테넌시 지원은 거의 효과가 없을 수 있습니다. 그러나 다중 테넌트 에이전트의 영향을 자세히 살펴보면서 테넌시는 개별 테넌트를 지원하도록 도구, 메모리, 데이터 및 기타 에이전트 부분에 액세스, 배포 및 구성하는 방법에 에이전트가 영향을 미치는 방식에 직접적인 영향을 미칠 수 있습니다. 테넌시는 조정, 제한, 요금, 계층화 및 기타 비즈니스 측면이 에이전트의 아키텍처에 적용되는 방식에도 영향을 미칩니다.

한 가지 단점은 다중 테넌시 지원이 필요한 에이전트 사용 사례가 있다는 것입니다. 문제는 다중 테넌시가 에이전트 경험의 전반적인 설계와 아키텍처를 어떻게 형성하는지 결정하는 것입니다. 일부 에이전트의 경우 다중 테넌트 지원은 차별화 기능을 나타내며, 이를 통해 에이전트는 대상 결과를 제공하는 에이전트에 테넌트별 컨텍스트를 적용할 수 있습니다.

후속 섹션에서는 다중 테넌트 SaaS 아키텍처를 설명하기 위해 생성하는 용어 및 설계 패턴이 어떻게 유용한지 알아봅니다. 이러한 개념은 AaaS 모델에서 유용한 측면을 빌려 채택할 수 있으며, 필요한 경우 새로운 에이전트별 개념을 도입합니다.

자격 증명, 테넌트 컨텍스트 및 에이전트 시스템

개별 에이전트에 테넌트 컨텍스트를 추가하는 것은 그리 어렵지 않습니다. 대부분의 경우 팀은 사용자와 시스템을 테넌트에 바인딩하고 테넌트 인식 토큰을 에이전트에 전달하는 일반적인 메커니즘에 의존할 수 있습니다. 이는 테넌트 컨텍스트 및 자격 증명이 여러 에이전트를 지원하는 방법을 고려할 때 관련이 있습니다. 이 모델에서 테넌트는 모든 공동 작업 에이전트에 걸쳐 있는 자격 증명에 바인딩되어야 합니다.

일반적으로 에이전트 도메인에는 에이전트 시스템의 현재 및 새로운 요구 사항에 맞는 더 교차적인 자격 증명 모델이 필요합니다. 에이전트 공급자에게는 운영 에이전트 시스템과 함께 제공되는 고유한 보안, 규정 준수 및 권한 부여 모델을 지원하는 자격 증명 메커니즘이 필요합니다. 이는 고객 또는 다른 에이전트가 시스템을 구성하는 환경에서 특히 어렵습니다. 온보딩된 각 에이전트는 자격 증명과 테넌트 컨텍스트를 에이전트 상호 작용에 연결해야 합니다. 다음 다이어그램은 agent-to-agent(a2a) 상호 작용의 일부인 잠재적 ID 및 테넌트 컨텍스트 문제를 강조합니다.

이 다이어그램은 살펴본 에이전트 시스템의 일부로 상호 작용하는 일련의 공급자 구축 에이전트를 보여줍니다. 이제 자격 증명 및 테넌트 컨텍스트로 개량되었습니다. 이 시나리오는 여러 진입점을 지원하는 에이전트 시스템의 예입니다. 이 시스템의 각 에이전트는 시스템 또는 사용자를 지정된 테넌트로 해결하기 위해 자체 인증 메커니즘이 필요하다고 가정합니다. 이러한 에이전트가 상호 작용하면 테넌트 컨텍스트가 JSON 웹 토큰(JWT)으로 전달되어 액세스를 승인하고 테넌트 컨텍스트를 에이전트에 주입하는 데 사용됩니다.

개념적으로이 시나리오의 주요 차이점은 에이전트가 독립적으로 배포하고 운영한다는 것입니다. 즉, 각 에이전트는 ID를 확인하고 액세스를 승인할 수 있어야 합니다. 핵심은 ID에 광범위한 에이전트 시스템의 요구 사항을 처리할 수 있는 분산 기능이 있어야 한다는 것입니다. 또한 에이전트가 테넌트 컨텍스트를 공유하는 방식에도 조정이 있어야 합니다.

AaaS에 SaaS 비즈니스 가치 적용

일반적으로 as-a-service 모델에서 시스템을 실행하는 방법을 살펴볼 때 경험의 특성과 기술 및 운영 공간이 비즈니스 성과를 어떻게 주도하는지 고려합니다. 예를 들어 SaaS를 채택할 때 조직은 규모의 경제, 운영 효율성, 비용 프로필 및 민첩성을 사용하여 성장, 마진 및 혁신을 주도합니다.

AaaS로 제공되는 에이전트는 유사한 비즈니스 성과를 목표로 할 가능성이 높습니다. 에이전트는 여러 테넌트를 지원하여 리소스 소비를 테넌트 활동에 맞게 조정할 수 있습니다. 이를 통해 기존 SaaS 환경과 함께 제공되는 규모의 경제를 실현할 수 있습니다. 또한 AaaS를 통해 조직은 에이전트를 자주 릴리스하고 에이전트 공급자의 민첩성을 높이는 방식으로 에이전트를 관리, 운영 및 배포할 수 있습니다. 핵심은 AaaS 모델이 기술에 의존하지 않는다는 것입니다. 성장을 촉진하고, 채택을 간소화하고, 운영을 간소화하는 비즈니스 전략을 생성하고 추진합니다.