멀티 테넌트 에이전트 AI 시스템

Last reviewed 2026-06-18 UTC

이 문서에서는 Google Cloud에서 멀티 테넌트 에이전트형 AI 시스템을 설계하고 배포하는 데 도움이 되는 참조 아키텍처를 제공합니다. 조직에서 생성형 AI 배포를 확장함에 따라 다양한 비즈니스 단위에서 고유한 도구에 액세스하고, 특정 운영 규칙을 따르고, 민감한 정보를 처리하는 전문 AI 에이전트가 필요합니다. 비즈니스 단위는 조직 내에서 파편화된 애플리케이션 사일로를 개발할 수 있으며, 이로 인해 운영 오버헤드가 높아지고, 심각한 거버넌스 격차가 발생하며, 데이터 노출 위험이 발생할 수 있습니다. 이 아키텍처는 통합 보안 및 규정 준수를 유지하면서 분산된 팀에 자율 AI 기능을 제공할 수 있는 중앙 집중식 시스템을 구축하는 방법을 보여줍니다.

이 문서의 주요 대상에는 클라우드에서 엔터프라이즈급 멀티 에이전트 시스템을 빌드하고 관리하는 설계자, 개발자, 관리자가 포함됩니다. 이 문서에서는 AI, ML, LLM 개념과 에이전트형 AI에 대한 기본적인 이해가 있다고 가정합니다.

이 문서의 배포 섹션에서는 멀티 테넌트 에이전트 AI 시스템을 빌드하고 배포하는 데 도움이 되는 구현 전략을 제공합니다.

아키텍처

다음 다이어그램은 허브 앤 스포크 모델을 따르는 멀티 테넌트 에이전트 AI 시스템의 아키텍처를 보여줍니다. 허브 및 스포크 모델은 허브라고 하는 중앙 환경이 스포크라고 하는 여러 격리된 환경에 연결되는 네트워크 설계입니다.

멀티 테넌트 에이전트 AI 시스템을 보여주는 아키텍처

이 아키텍처는 다음 구성요소로 구성됩니다.

구성요소 설명
VPC 서비스 제어 이 아키텍처는 VPC 서비스 제어를 사용하여 조직 수준에서 서비스 경계를 구성합니다. 이 서비스 경계는 엄격한 보안 경계를 제공하며 데이터 무단 반출을 방지합니다.
라우팅 허브

라우팅 허브는 아키텍처의 중앙 진입점 역할을 하며 다음 구성요소를 포함합니다.

  • 외부 애플리케이션 부하 분산기: 외부 또는 내부 사용자의 중앙 인그레스 지점 역할을 합니다. 부하 분산기는 인증되고 안전한 트래픽만 프런트엔드 포털에 도달하도록 합니다.
  • Google Cloud Armor 및 Model Armor: 부하 분산기는 Cloud Armor 및 Model Armor를 통합하여 네트워크 에지에서 악성 프롬프트를 검사하고 삭제합니다. 라우팅 허브는 외부 애플리케이션 부하 분산기에서 Service Extensions를 사용하여 Model Armor를 요청 흐름에 직접 통합합니다.
  • Identity-Aware Proxy (IAP): 요청이 애플리케이션에 도달하기 전에 사용자 ID와 컨텍스트를 확인하기 위해 제로 트러스트 모델을 적용합니다.
  • 프런트엔드 포털: 요청을 적절한 격리된 테넌트 프로젝트로 라우팅하는 라우팅 엔진 역할을 하는 서버리스 Cloud Run 애플리케이션입니다.
중앙 거버넌스 및 보안 허브

중앙 거버넌스 및 보안 허브는 전체 플랫폼에 중앙 집중식 ID 및 액세스 관리 (IAM), 로깅, 모니터링, 보안을 제공하는 전용 Google Cloud 프로젝트입니다. 이 허브에는 다음 구성요소가 포함됩니다.

  • Security Command Center: 전체 멀티 테넌트 에이전트형 AI 시스템에서 보안 위험을 모니터링하는 서비스입니다.
  • IAM: 공유 허브와 테넌트 프로젝트 전반에서 ID와 권한을 관리하는 액세스 제어 프레임워크입니다. 이 구성요소는 모든 인간 및 머신 ID에 대한 중앙 집중식 거버넌스를 제공합니다.
  • Cloud Logging: 공유 허브와 격리된 테넌트 프로젝트의 로그를 중앙 거버넌스 및 보안 허브로 집계하는 시스템입니다.
테넌트 프로젝트

각 테넌트 프로젝트는 각 비즈니스 단위의 전용 Google Cloud 프로젝트입니다. 개별 테넌트 프로젝트는 다음 구성요소가 포함된 격리된 환경입니다.

  • 보안 주체 액세스 경계 정책 (PAB 정책): PAB 정책은 서로 다른 비즈니스 단위 간에 내부 하드 격리를 제공하며, 보안 주체가 승인된 경계 내의 리소스에만 액세스할 수 있도록 보장합니다.
  • Gemini Enterprise Agent Platform의 에이전트 런타임: 특정 비즈니스 단위 에이전트를 호스팅하고 에이전트 개발 키트 (ADK)를 사용하여 빌드한 맞춤 오케스트레이션 코드를 실행하는 런타임입니다.
  • Model Armor: 악성 프롬프트와 응답을 검사하고 필터링하는 관리형 보안 서비스입니다. 프롬프트 인젝션 공격과 같은 위협으로부터 테넌트의 에이전트 및 컴퓨팅 리소스를 보호합니다.
  • 모델 컨텍스트 프로토콜 (MCP) 서버: MCP 서버는 테넌트 에이전트와 테넌트 데이터 스토어 간의 액세스를 지원합니다.
  • 테넌트 데이터 저장소: 특정 비즈니스 단위 데이터를 저장하는 BigQuery 또는 PostgreSQL용 AlloyDB와 같은 전용 데이터 저장소입니다. 에이전트는 검색 증강 생성 (RAG)을 실행하여 데이터 스토어의 컨텍스트를 기반으로 더 정확한 대답을 생성합니다. 엄격한 데이터 주권을 유지하기 위해 테넌트 에이전트만 이 데이터에 액세스할 수 있습니다.
  • Gemini 모델: 추론 제공을 위해 이 예시 아키텍처의 에이전트는 Gemini Enterprise Agent Platform에서 최신 Gemini 모델을 사용합니다.

에이전트형 흐름

위 아키텍처의 멀티 테넌트 시스템에는 다음과 같은 흐름이 있습니다.

  1. 사용자의 요청은 외부 애플리케이션 부하 분산기를 통해 라우팅됩니다. 라우팅 허브 내에서 이러한 검사가 완료되어 인증되고 안전한 트래픽만 프런트엔드 포털에 도달하도록 지원합니다.
    1. Cloud Armor는 초기 레이어 4 네트워크 프로토콜 기반 분산 서비스 거부 (DDoS) 공격을 흡수하기 위해 보안 정책을 적용합니다. Cloud Armor는 요청을 검사하고 SQL 삽입 (SQLi), 교차 사이트 스크립팅 (XSS), 알려진 봇 서명과 같은 악성 트래픽을 필터링합니다.
    2. Model Armor는 페이로드를 가로채 프롬프트 인젝션 공격이나 악의적인 의도를 감지하고 거부합니다.
    3. 이러한 레이어 중 하나에서 위협이나 무단 액세스를 감지하면 부하 분산기가 네트워크 에지에서 요청을 삭제합니다.
    4. 보안 레이어에서 위협을 감지하지 않고 사용자의 액세스를 검증하면 부하 분산기가 트래픽을 백엔드 서비스로 라우팅합니다.
  2. 요청이 모든 검사를 통과하면 부하 분산기가 요청을 프런트엔드 플랫폼으로 라우팅하며, 프런트엔드 플랫폼은 다음 작업을 실행합니다.
    1. 사용자의 비즈니스 단위 또는 테넌트 ID와 같은 사용자 ID를 추출합니다.
    2. IAP를 사용하여 사용자의 회사 ID와 기기 상태를 확인합니다.
    3. 동적으로 유지관리되는 레지스트리를 사용하여 올바른 타겟 테넌트를 식별합니다.
  3. 프런트엔드 포털은 요청을 테넌트로 라우팅합니다. 에이전트가 다른 테넌트 프로젝트나 승인되지 않은 Google Cloud서비스에 액세스할 수 없도록 하기 위해 Agent Runtime은 보안 주체 액세스 경계 정책을 사용하여 에이전트가 액세스할 수 있는 리소스를 제한합니다.
  4. Model Armor는 Sensitive Data Protection을 사용하여 개인 식별 정보 (PII) 또는 제한된 콘텐츠를 검사하고 동적으로 마스킹합니다. Model Armor는 요청에서 악의적인 프롬프트 인젝션이 있는지 추가로 확인하여 에이전트가 안전한 데이터만 처리하도록 합니다.

  5. Gemini는 대답을 생성하기 위해 다음 작업을 실행합니다.

    1. 사용자의 의도를 파악하기 위해 초기 추론 패스를 실행합니다.
    2. Gemini가 구체적인 사실이 부족하다고 판단하면 테넌트의 특정 데이터 도구를 호출하는 계획을 생성합니다.
      1. 사용자에게 데이터 리소스에 액세스할 권한이 있는지 확인하기 위해 에이전트는 사용자의 ID와 IAM 역할 바인딩을 확인합니다.
      2. 컨텍스트를 가져오기 위해 에이전트는 MCP 서버를 통해 테넌트 데이터 스토어로 도구 호출을 실행합니다.
      3. 에이전트는 내부 로직과 새로 가져온 테넌트별 사실을 결합하여 그라운딩된 대답을 생성합니다.

    Gemini에 추가 사실이 필요하지 않으면 대답을 생성하고 Model Armor에 대답을 보냅니다.

  6. Model Armor는 PII 또는 제한된 콘텐츠를 검사하고 동적으로 마스킹한 후 정리된 응답을 테넌트 에이전트에 전송합니다. 이 최종 검사를 통해 출력에 민감한 정보가 유출되지 않도록 할 수 있습니다.

  7. 응답은 테넌트 에이전트에서 프런트엔드 플랫폼을 거쳐 부하 분산기를 통해 사용자에게 다시 라우팅됩니다.

사용 제품

이 참조 아키텍처에서는 서버리스 특성, 확장성, 보안 기능으로 인해 선택된 다음과 같은 Google Cloud 및 오픈소스 제품과 도구를 사용합니다.

사용 사례

멀티 테넌트 에이전트 AI 시스템은 단일 애플리케이션을 넘어 생성형 AI 배포를 확장하려는 엔터프라이즈 조직에 적합합니다. 이 아키텍처에 적합한 사용 사례를 식별하려면 비즈니스 프로세스를 분석하고 고유한 도구와 민감한 정보에 액세스하는 자체 전문 AI 에이전트가 필요한 다양한 팀을 식별하세요. 이 접근 방식을 사용하면 통합 보안 및 기업 규정 준수를 유지하면서 분산된 팀에 자율 AI 기능을 제공할 수 있습니다.

다음은 멀티 테넌트 에이전트형 AI 시스템의 사용 사례입니다.

전사적 고객 서비스

이 참조 아키텍처를 적용하여 여러 비즈니스 부문에서 AI 기반 고객 서비스를 제공할 수 있습니다. 예를 들어 전자제품 부문과 생활용품 부문을 지원하기 위해 전자제품 에이전트와 생활용품 에이전트를 별도의 테넌트 프로젝트에 별도의 에이전트로 배포합니다. 이러한 전문 AI 에이전트는 고유한 기술 사양, 보증 또는 반품 정책에 액세스하여 부서별 지원 문의를 처리하는 지능형 어시스턴트 역할을 합니다. 이 자동화를 통해 인간 지원팀은 더 복잡한 고객 에스컬레이션에 집중할 수 있습니다.

이 사용 사례에서 아키텍처는 다음과 같은 이점을 제공합니다.

  • 엄격한 데이터 격리: 멀티 테넌트 설계는 각 부서의 지원 지식이 엄격하게 격리되도록 합니다. PAB 정책은 한 테넌트의 에이전트 ID가 다른 테넌트의 데이터에 액세스할 수 없도록 하는 가이드라인을 제공합니다.
  • 전문 에이전트 지식: 각 에이전트는 격리된 테넌트 프로젝트에 상주하므로 에이전트는 부서별 Datastore에서만 컨텍스트를 가져옵니다. 이 타겟팅된 검색은 높은 정확도를 보장하고 에이전트가 서로 다른 비즈니스 단위의 정책을 혼동하지 않도록 합니다.
  • 교차 도메인 위험 감소: 이 아키텍처는 비즈니스 단위 간 데이터 노출 위험을 제거하는 데 도움이 됩니다. 에이전트 ID가 도용되더라도 에이전트는 승인되지 않은 Google Cloud 리소스에 액세스할 수 없습니다.

이 아키텍처는 여러 개의 개별 브랜드 또는 사업부를 관리하고 엄격한 데이터 주권이 필요한 대규모 소매 조직 및 기업에 적합합니다.

설계 대안

이 섹션에서는 Google Cloud에서 멀티 테넌트 에이전트 AI 배포에 대해 고려할 수 있는 대체 설계 접근 방식을 보여줍니다.

비공개 액세스 배포

이 문서에서 설명하는 아키텍처에서 사용자는 중앙에 노출된 외부 애플리케이션 부하 분산기를 통해 공개 인터넷을 통해 멀티 테넌트 에이전트 AI 시스템에 액세스합니다. 조직에서 공개 인터넷에서 액세스할 수 없는 시스템이 필요한 경우 다음 비공개 액세스 전략 중 하나를 사용하도록 아키텍처를 조정할 수 있습니다.

에지 보안 정책으로 트래픽 차단

조직의 인증된 회사 IP 주소에서만 트래픽을 허용하려면 다른 트래픽을 거부하도록 Cloud Armor 보안 정책을 구성하면 됩니다. 이 우선순위가 높은 보안 규칙은 네트워크 에지에서 모든 승인되지 않은 요청을 차단합니다. 보안을 한층 강화하려면 IAP를 사용하여 유효한 회사 ID 세션을 요구하고 모든 사용자에 대해 IAM 권한을 구성하면 됩니다.

이 방식을 사용하면 Cloud Armor 에지 보안 정책을 활용하여 DDoS 완화 및 WAF 필터링(예: SQLi 및 XSS)을 오프로드하고 제로 트러스트 환경을 제공할 수 있습니다. 하지만 외부 애플리케이션 부하 분산기의 프런트엔드 IP 주소는 공개 상태로 유지되므로 일부 조직의 규정 준수 요구사항을 충족하지 못할 수 있습니다.

내부 애플리케이션 부하 분산기를 통해 트래픽 라우팅

이 문서의 아키텍처에서는 외부 애플리케이션 부하 분산기를 사용합니다. 외부 애플리케이션 부하 분산기는 내부 부하 분산기에 비해 강력한 Cloud Armor 정책, 고급 보안 기능, 낮은 운영 복잡성을 제공합니다. 하지만 외부 부하 분산기를 사용하면 트래픽이 공개 인터넷을 통과합니다.

트래픽을 비공개 Google 네트워크 내에 완전히 유지하려면 내부 애플리케이션 부하 분산기를 사용하면 됩니다. 내부 애플리케이션 부하 분산기를 사용하면 본인 인증을 위한 IAP가 지원됩니다. 전역 외부 애플리케이션 부하 분산기는 에지 레이어에서 IAP 정책을 평가합니다. 반면 내부 애플리케이션 부하 분산기는 내부 네트워크 레이어에서 정책을 평가합니다. 트래픽이 공개 인터넷을 통과하지 않으므로 내부 애플리케이션 부하 분산기를 사용하면 엄격한 데이터 주권 및 공개 IP 주소 제로 요구사항을 충족할 수 있습니다.

지연 시간을 낮게 유지하고 리전 데이터 레지던시 요구사항을 준수하려면 각 기본 리전에 리전 내부 애플리케이션 부하 분산기를 배포하세요. 리전 내부 애플리케이션 부하 분산기를 사용하면 Cloud Interconnect 또는 Cloud VPN을 통해 온프레미스 환경의 트래픽을 부하 분산기의 내부 IP 주소로 직접 라우팅할 수 있습니다. 리전별 내부 애플리케이션 부하 분산기는 내부 WAF 보호를 위해 리전별 Cloud Armor를 지원합니다. 하지만 외부 애플리케이션 부하 분산기와 비교할 때 리전 내부 애플리케이션 부하 분산기는 제한된 Cloud Armor 보안 정책을 지원하고 고급 보안 기능이 없으며 운영 복잡성이 증가합니다.

지연 시간을 더욱 최소화하고 재해 복구 요구사항을 충족하는 고가용성을 보장하려면 교차 리전 내부 애플리케이션 부하 분산기를 배포하면 됩니다. 리전 간 내부 애플리케이션 부하 분산기를 사용하면 위치정보 라우팅 정책과 함께 Cloud DNS를 사용하여 애플리케이션의 내부 URL을 사용자와 가장 가까운Google Cloud 리전의 리전 간 내부 애플리케이션 부하 분산기로 확인합니다. 하지만 교차 리전 구성은 Cloud Armor 통합을 지원하지 않습니다.

컴퓨팅 인프라

관리 용이성과 낮은 운영 오버헤드를 제공하는 서버리스 우선 접근 방식을 우선시하기 위해 이 문서의 아키텍처에서는 컴퓨팅 인프라에 Cloud Run을 사용합니다. GKE 클러스터에서 컨테이너화된 애플리케이션을 실행할 수도 있습니다. Google Kubernetes Engine (GKE)은 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 컨테이너 조정 엔진입니다. GKE는 내부 및 외부 애플리케이션 부하 분산기를 모두 완벽하게 지원합니다. Google Cloud의 워크로드에 적합한 컴퓨팅 서비스를 선택하는 방법에 대한 자세한 내용은 Google Cloud에서 애플리케이션 호스팅을 참고하세요.

모델 컨텍스트 프로토콜(MCP) 서버

에이전트 시스템의 구성요소가 상호작용할 수 있도록 하려면 명확한 커뮤니케이션 프로토콜을 설정해야 합니다. MCP는 에이전트가 필요한 도구, 데이터, 기타 서비스에 액세스하고 이를 사용할 수 있는 표준화된 인터페이스를 제공하는 개방형 프로토콜입니다.

테넌트 에이전트를 데이터 스토어에 연결하려면 애플리케이션 요구사항을 고려하여 다음 MCP 서버 배포 옵션 중에서 선택하세요. 로컬 MCP 배포와 공유 MCP 배포 중에서 선택할 때는 데이터 격리와 운영 효율성 간의 절충점을 고려하세요.

  • 로컬 MCP 서버: 로컬 MCP 서버 또는 테넌트별 MCP 서버는 각 테넌트 프로젝트 내에 배포되고 에이전트가 해당 비즈니스 단위에 특정한 데이터 저장소 및 도구에 액세스할 수 있도록 지원하는 MCP 서버입니다.

    다음은 로컬 MCP 서버의 주요 기능 및 고려사항입니다.

    • 네트워크: 프로젝트 수준 VPC 서비스 제어 경계 및 PAB 정책은 내재된 보안 및 격리를 제공하여 교차 테넌트 액세스를 방지합니다.
    • 관리: 개별 개발자 및 운영팀이 테넌트 프로젝트를 독립적으로 관리합니다. 이러한 격리를 통해 각 비즈니스 단위는 자율성을 확보할 수 있습니다.
    • 보안: 테넌트 프로젝트의 고정된 IAM 경계는 측면 위험 표면을 최소화하는 데 도움이 되며 복잡한 ID 매핑이 필요하지 않습니다.

    로컬 MCP 서버는 최대한의 격리를 제공하며 매우 민감하거나 규제 대상 데이터 액세스를 처리할 수 있습니다. 하지만 로컬 MCP 서버를 여러 개 배포하면 운영 부하가 증가합니다. 민감한 정보가 포함될 수 있는 데이터 스토어에 대한 제한적인 액세스가 필요한 애플리케이션에는 로컬 MCP 서버를 사용하는 것이 좋습니다.

  • 공유 MCP 서버: 공유 MCP 서버 또는 전역 MCP 서버는 공유 서비스 프로젝트에 배포하는 MCP 서버입니다. 공유 MCP 서버는 여러 테넌트에서 공통으로 사용하는 도구와 시스템에 대한 액세스를 제공합니다.

    다음은 공유 MCP 서버의 주요 기능과 고려사항입니다.

    • 네트워크: 트래픽이 공개 인터넷을 통과하지 않도록 하려면 공유 MCP 서버에 Private Service Connect 또는 VPC 네트워크 피어링과 같은 비공개 연결이 필요합니다.
    • 관리: 중앙 집중식 운영팀에서 전체 시스템의 구현을 관리합니다. 이 통합 관리로 운영 효율성이 최적화되고 여러 테넌트에서 로컬 구현을 중복할 필요가 없습니다.
    • 보안: 테넌트 프로젝트의 에이전트에서 공유 MCP 서버로 최종 사용자 ID를 안전하게 전파합니다. 사용자가 허용된 데이터에만 액세스하거나 수정할 수 있도록 공유 MCP 서버는 전파된 사용자 ID를 사용하여 백엔드 시스템에서 세분화된 액세스 제어를 적용합니다.

    공유 MCP 서버는 일반적인 도구의 관리를 중앙 집중화하여 중복을 줄이고 운영 효율성을 최적화합니다. 공유 MCP 서버는 관리 오버헤드를 줄이지만 안전한 액세스를 유지하려면 강력한 ID 전파 및 승인 로직이 필요합니다. 비용 보고 도구, 인사 관리 (HR) 시스템, 전사적 기술 자료 또는 출석 관리자와 같은 일반적인 회사 시스템 및 도구와의 상호작용에는 공유 MCP 서버를 사용하는 것이 좋습니다.

이 아키텍처에서는 MCP 서버를 사용하여 테넌트 에이전트와 데이터 스토어 간의 연결을 표준화합니다. 워크로드 요구사항에 따라 다른 유형의 에이전트 도구를 사용하여 에이전트를 특정 외부 API 및 시스템에 연결할 수 있습니다. 에이전트 도구 상호작용에 대한 자세한 내용은 에이전트 도구를 참고하세요.

설계 고려사항

다음 섹션에서는 이 참조 아키텍처를 사용하여 보안, 안정성, 비용, 성능 관련 특정 요구사항을 충족하는 토폴로지를 개발할 때 고려해야 하는 설계 요소, 권장사항, 권장사항을 설명합니다. 이 섹션의 안내는 일부일 뿐 모든 내용을 포함하지는 않습니다. 워크로드의 요구사항과 사용하는 제품 및 기능에 따라 추가로 고려해야 할 설계 요소와 장단점이 있을 수 있습니다.

보안, 개인 정보 보호, 규정 준수

이 섹션에서는 Google Cloud 에서 워크로드의 보안, 개인 정보 보호, 규정 준수 요구사항을 충족하는 토폴로지를 설계하기 위한 설계 고려사항과 권장사항을 설명합니다.

구성요소 설계 고려사항 및 권장사항
Virtual Private Cloud(VPC) 테넌트 격리: 이 아키텍처에서는 각 테넌트를 전용 Google Cloud 프로젝트에 배포합니다. 엄격한 보안 경계를 만들려면 조직 수준에서 테넌트 프로젝트 수준 격리를 PAB 정책 및 VPC 서비스 제어와 결합하세요.
IAM 액세스 제어: 최소 권한의 원칙을 구현하려면 페르소나 기반 액세스 모델을 사용하세요. 예를 들어 한 테넌트에서 에이전트를 빌드하는 개발자가 다른 테넌트의 데이터에 액세스할 수 없도록 커스텀 IAM 역할을 정의할 수 있습니다.
Cloud Armor

에지 및 내부 WAF 보호: Cloud Armor는 DDoS 공격 및 웹 취약점으로부터 프런트엔드 포털을 보호하기 위한 보안 및 WAF 보호를 제공합니다. 전역 외부 애플리케이션 부하 분산기는 봇 관리, Google Cloud Armor 적응형 보호와 같은 고급 에지 기능의 전체 모음을 지원합니다.

리전 내부 애플리케이션 부하 분산기를 배포하면 Cloud Armor가 제한된 표준 WAF 정책 집합으로 작동합니다. 제한된 정책 집합은 내부 네트워크 경계에 맞게 조정되며 SQLi 및 XSS 보호와 같은 정책이 포함됩니다. 자세한 내용은 Cloud Armor를 다른 Google 제품과 통합을 참고하세요.
Agent Platform

공유 모델 엔드포인트: 공유 모델 엔드포인트의 악용을 방지하고 공정한 사용을 보장하려면 다음 전략 중 하나를 구현하세요.

  • 테넌트 수준 비율 제한: 요청이 공유 엔드포인트에 도달하기 전에 각 테넌트의 프런트엔드 포털에서 할당량을 적용합니다. 다음을 실행하여 할당량을 적용합니다.
    1. IAP 컨텍스트에서 테넌트 ID를 추출합니다.
    2. Memorystore for Redis와 같은 외부 저장소를 사용하여 각 테넌트의 사전 정의된 한도에 대한 사용량을 추적합니다.
    3. 테넌트의 한도를 초과하는 요청을 거부합니다.
  • API 게이트웨이: API 키와 사용 계획을 사용하여 테넌트별 할당량을 적용하려면 공유 엔드포인트 앞에 API 게이트웨이를 구현하세요.
Cloud Run

콘텐츠 렌더링: 프런트엔드 포털의 보안 상태를 개선하려면 클라이언트 측 렌더링 (CSR)보다 서버 측 렌더링 (SSR)을 우선적으로 사용하세요. SSR은 CSR에 비해 다음과 같은 이점을 제공합니다.

  • 통제된 Google Cloud 환경 내에서 애플리케이션 로직을 실행하고 비밀을 관리합니다.
  • 클라이언트 측 공격 표면을 줄이고 민감한 정보가 사용자의 신뢰할 수 없는 브라우저로 유출되는 것을 방지합니다.
  • 필요한 HTML만 클라이언트에 전송하여 데이터 노출을 제한합니다.
  • 교차 사이트 스크립팅 (XSS) 공격을 방어하기 위한 중앙 집중식 출력 인코딩을 제공합니다.
Security Command Center 중앙화된 보안 모니터링: 위협을 모니터링하고 다단계 인증 (MFA) 및 데이터 암호화와 같은 보안 정책을 시행하려면 Security Command Center의 도구를 사용하세요.

기타 보안 권장사항

안정성

이 섹션에서는 Google Cloud에서 배포를 위한 안정적인 인프라를 빌드하고 운영하기 위한 설계 고려사항 및 권장사항을 설명합니다.

구성요소 설계 고려사항 및 권장사항
Cloud Load Balancing 전역 라우팅: 전역 외부 애플리케이션 부하 분산기는 사용자 트래픽을 가장 가까운 지리적 Google 에지로 자동 라우팅하는 단일 애니캐스트 IP 주소를 제공합니다. 이 구성은 에지 보안 소켓 레이어(SSL) 종료를 통해 지연 시간을 줄입니다. 또한 정상적인 리전 백엔드로 트래픽을 지능적으로 리라우팅하므로 리전에 서비스 중단이 발생할 경우 고가용성을 보장합니다.
테넌트 내결함성: 에이전트 수준 오류를 허용하거나 처리하려면 격리된 테넌트 프로젝트에 에이전트를 배포하세요. 이렇게 격리하면 운영 문제나 보안 사고가 단일 비즈니스 단위 내에 머물러 다른 리소스나 비즈니스 단위에 영향을 주지 않습니다.
Agent Platform 용량 계획: 모델에 대한 요청 수가 할당된 용량을 초과하면 모델에서 오류 코드 429를 반환합니다. 비즈니스 관련 중요도가 높고 지속적으로 높은 처리량이 필요한 워크로드의 경우 프로비저닝된 처리량을 사용하여 처리량을 예약할 수 있습니다.
Agent Runtime

서버리스 확장성: Agent Runtime에 배포된 에이전트는 수요에 따라 독립적으로 확장됩니다. 한 테넌트의 사용량이 갑자기 급증해도 컴퓨팅 리소스가 소진되지 않으며 다른 테넌트 프로젝트의 에이전트 가용성에도 영향을 미치지 않습니다.

오류 처리: 오류 코드 429 비율 제한과 같은 일시적인 오류를 처리하기 위해 에이전트 오케스트레이션 로직은 지수 백오프를 사용합니다. 컨텍스트 기한이 초과되면 에이전트는 단계적 종료를 실행하고 부분 진행 상황을 사용자에게 다시 보고합니다. 예를 들어 느린 도구 호출, 서드 파티 API 지연 시간, 대규모 데이터 세트 처리 또는 컴퓨팅 집약적 처리로 인해 컨텍스트 기한이 초과될 수 있습니다.

AI 및 ML 워크로드와 관련된 안정성 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 안정성을 참조하세요.

운영 효율성

이 섹션에서는 이 참조 아키텍처를 사용하여 효율적으로 운영할 수 있는 Google Cloud 토폴로지를 설계할 때 고려해야 하는 요소를 설명합니다.

구성요소 설계 고려사항 및 권장사항
Google Cloud Observability 중앙 집중식 모니터링: 로깅 및 모니터링을 사용하면 전체 플랫폼의 상태와 성능을 모니터링할 수 있습니다. 민감한 정보에 대한 액세스를 허용하지 않고도 문제를 선제적으로 감지하고 해결할 수 있도록 알림을 설정할 수 있습니다.
아키텍처의 모든 제품 표준화된 배포: 표준화된 테넌트 아키텍처 패턴 내에서 Agent Platform을 사용하면 새 테넌트를 온보딩할 때 일관된 기준을 설정할 수 있습니다. 운영 부담을 줄이려면 Terraform과 같은 코드형 인프라 (IaC) 도구를 사용하여 배포 프로세스를 자동화하세요. 멀티 테넌트 에이전트 AI 시스템을 빌드하고 배포하는 데 사용할 수 있는 Terraform 코드는 이 문서의 배포 섹션을 참고하세요.

AI 및 ML 워크로드와 관련된 운영 우수성 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 운영 우수성을 참고하세요.

비용 최적화

이 섹션에서는 이 참조 아키텍처를 사용하여 빌드하는 Google Cloud 토폴로지의 설정 및 운영 비용을 최적화하는 방법을 안내합니다.

구성요소 설계 고려사항 및 권장사항
Agent Platform

토큰 사용량: 비용을 관리하고 AI 모델이 컨텍스트 윈도우를 초과하지 않도록 하려면 다음 전략을 사용하여 AI 모델의 컨텍스트를 관리하세요.

  • 컨텍스트 요약: 전체 세션 대화를 컨텍스트로 저장하는 대신 AI 모델을 사용하여 이전 대화와 중요도가 낮은 정보를 요약합니다.
  • 출력 가지치기: 도구 출력 또는 검색된 컨텍스트에서 관련성이 떨어지거나 장황한 부분을 식별하고 삭제합니다. 예를 들어 데이터의 열 이름만 필요한 경우 데이터베이스 스키마 가져오기에서 과도한 메타데이터를 삭제할 수 있습니다. 이 전략에는 휴리스틱, 필터링 또는 소규모 언어 모델 (SLM)을 사용하여 가장 중요한 정보를 추출하는 맞춤 로직이 필요합니다.
  • 최대 토큰 한도: 무한 루프를 방지하고 비용을 관리하기 위해 세션 최대 토큰 한도를 적용합니다.

모델 엔드포인트: API 할당량 및 리소스 사용률을 관리하려면 전용 구성 또는 공유 구성에 Agent Platform 엔드포인트를 배포하면 됩니다.

  • 전용 엔드포인트: 각 테넌트 프로젝트 내에 엔드포인트를 배포하면 고유한 할당량 격리가 제공됩니다. 각 테넌트의 사용량은 자체 프로젝트 할당량에 포함되므로 테넌트 간 영향을 방지할 수 있습니다. 전용 엔드포인트는 공유 엔드포인트에 비해 할당량 관리가 더 간단합니다. 하지만 전용 엔드포인트는 공유 엔드포인트의 잠재적인 비용 절감 효과를 활용하지 못하게 합니다.
  • 공유 엔드포인트: 비용을 최적화하려면 중앙 거버넌스 및 보안 허브에서 공유 엔드포인트를 호스팅하면 됩니다. 모든 테넌트가 동일한 할당량 풀을 공유하므로 악의적인 공격을 방지하려면 API 게이트웨이를 사용하여 테넌트 수준 속도 제한 또는 할당량 적용과 같은 완화 전략을 구현해야 합니다. 전용 엔드포인트에 비해 공유 엔드포인트가 비용 효율성이 더 높습니다. 하지만 공유 엔드포인트에는 추가 엔지니어링 작업이 필요하며 지연 시간과 관리 오버헤드가 발생할 수 있습니다.

Agent Platform의 비용에 대한 자세한 내용은 Agent Platform에서 AI 모델을 빌드하고 배포하는 데 드는 비용을 참고하세요.
Cloud Run 계측: 계측을 사용하면 각 테넌트의 성능을 모니터링하고, 문제를 해결하고, 리소스 사용량을 추적할 수 있습니다. 각 요청의 테넌트를 식별하려면 IAP에서 제공하는 컨텍스트에서 사용자 ID를 추출합니다. 애플리케이션을 계측하는 방법은 계측 방법 선택을 참고하세요.
Model Armor 중앙 집중식 프롬프트 필터링: 엄격한 거버넌스와 제로 트러스트 태도를 적용하기 위해 이 아키텍처는 라우팅 허브와 각 테넌트 프로젝트의 두 레이어에 Model Armor를 배포합니다. 이 2계층 접근 방식은 데이터 주권을 보장하는 데 도움이 되지만 지연 시간과 운영 비용이 증가합니다. 비용과 시스템 복잡성을 줄이려면 라우팅 허브에만 Model Armor를 배포하여 모든 프롬프트와 응답을 필터링하세요.
아키텍처의 모든 제품

공유 인프라: 프런트엔드 포털, 중앙 거버넌스 및 보안 허브, Agent Platform과 같은 공유 핵심 인프라 구성요소를 사용하면 각 에이전트에 대해 별도의 맞춤 스택을 빌드할 때보다 비용을 절감할 수 있습니다.

플랫폼 오버헤드: 중앙 거버넌스 및 보안 허브의 공유 비용을 분배하려면 추적 기능 및 사용 패턴에 적합한 할당 모델을 사용하세요. 다음 비용 할당 모델 중 하나를 사용하는 것이 좋습니다.

  • 균등 분할 할당: 균등 분할 모델은 공유 비용을 모든 테넌트에 균등하게 할당합니다. 플랫폼이 기준 유틸리티이거나 세부 추적의 오버헤드가 비용 이점보다 큰 경우 이 모델을 사용합니다.
  • 비례 할당: 비례 모델 또는 지불 거절 프로세스는 각 테넌트가 발생하는 직접 비용의 비율에 따라 공유 비용을 할당합니다. 테넌트 소비량이 크게 달라지고 Resource Manager 라벨 및 로그 파싱과 같은 강력한 원격 분석을 사용하여 비용을 정확하게 귀속시킬 수 있는 경우 이 모델을 사용하세요.
  • 고정 할당: 고정 또는 계층화된 모델은 비즈니스에서 정의한 계수에 따라 공유 비용을 할당합니다. 테넌트마다 다른 서비스수준계약(SLA)이 필요한 경우 이 모델을 사용합니다. 고정 모델 할당을 사용하면 표준 공유 기능과 비교하여 프리미엄 전용 기능에 대해 고정 요금을 청구할 수 있습니다.

공유 서비스 비용을 할당하는 방법에 대한 자세한 내용은 Cloud FinOps: 공유 서비스 비용 할당을 참고하세요.

중앙 집중식 비용 관리: 에이전트형 AI 시스템의 총소유비용 (TCO)을 정확하게 추적하고 비용을 개별 비즈니스 단위에 귀속시키려면 라벨과 Cloud Billing 내보내기 데이터를 사용하세요. 라벨을 사용하여 비용 인식을 높이는 방법에 대한 자세한 내용은 비용 인식 문화 조성을 참고하세요.

Google Cloud 리소스의 비용을 추정하려면 Google Cloud 가격 계산기를 사용하세요.

AI 및 ML 워크로드와 관련된 비용 최적화 원칙 및 권장사항은 Well-Architected Framework의 AI 및 ML 관점: 비용 최적화를 참조하세요.

배포

이 참조 아키텍처를 배포하려면 GitHub에서 제공되는 멀티 테넌트 에이전트 AI Terraform 예시를 사용하세요.

다음 단계

참여자

저자:

기타 참여자: