이 페이지에서는 에이전트 게이트웨이를 통해 에이전트 런타임 트래픽을 라우팅하는 방법을 설명합니다. 에이전트 게이트웨이는 Gemini Enterprise Agent Platform 생태계의 중앙 네트워킹 및 보안 구성요소입니다. 사용자와 에이전트 간, 에이전트와 도구 간 또는 에이전트 간에 발생하는 모든 에이전트 상호작용을 위한 안전하고 관리되는 연결을 제공합니다.
시작하기 전에
Agent Runtime에 에이전트를 배포하는 방법을 숙지해야 합니다.
Agent Gateway에 대해 알아봅니다. Agent-to-Anywhere (egress) 모드에서 에이전트 게이트웨이를 사용하여 도구, 모델, API, 기타 에이전트로의 아웃바운드 트래픽을 포함한 모든 아웃바운드 통신을 보호하고 관리할 수 있습니다. 클라이언트-에이전트(수신) 모드에서 게이트웨이를 사용하여 에이전트에 액세스할 수 있는 클라이언트를 제어합니다. 게이트웨이를 사용하면 이러한 상호작용에 적용해야 하는 IAP 정책과 Model Armor 템플릿을 선택할 수 있습니다.
단일 런타임 인스턴스는 에이전트-어디서나(이그레스) 게이트웨이와 클라이언트-에이전트 (인그레스) 게이트웨이에 동시에 바인딩할 수 있습니다.
제한사항
- 에이전트 게이트웨이는 2026년 4월 29일 이전에 생성된 런타임 추론 엔진에 바인딩할 수 없습니다.
단일 프로젝트 및 리전에서 여러 Agent-to-Anywhere (이그레스) 및 Client-to-Agent (인그레스) 에이전트 게이트웨이 인스턴스를 호스팅할 수 있지만 동일한 프로젝트 및 리전 내에 배포된 모든 에이전트 런타임 에이전트는 동일한 특정 이그레스 및 인그레스 에이전트 게이트웨이 인스턴스에 바인딩되어야 합니다.
예를 들어 프로젝트와 리전에
egress-gateway-X및egress-gateway-Y이 포함된 경우 해당 프로젝트와 리전의 모든 에이전트는 이그레스를 위해 동일한 게이트웨이를 사용하도록 구성해야 합니다. 즉, 모든 에이전트가egress-gateway-X를 사용하거나 모든 에이전트가egress-gateway-Y를 사용합니다.egress-gateway-X를 사용하도록agent-A를 구성하고egress-gateway-Y를 사용하도록agent-B를 구성할 수는 없습니다.이 동일한 바인딩 규칙은 프로젝트 및 리전 내의 인그레스 게이트웨이에도 적용됩니다.
Security Command Center Agent Engine Threat Detection 서비스는 에이전트에 대해 에이전트 게이트웨이가 사용 설정된 경우 사용할 수 없습니다.
클라이언트-에이전트 (인그레스) 모드에서 에이전트 게이트웨이는 에이전트 런타임의
query및streamQuery메서드만 관리할 수 있습니다. 지원되지 않는 다른 메서드 (예:asyncQuery)를 보호하려면 애플리케이션이나 에이전트에서 직접 Model Armor 템플릿을 적용하면 됩니다. 프롬프트 및 대답 정리 또는 Model Armor를 사용하여 보안 에이전트 시스템 빌드에 관한 이 Codelab을 참고하세요.
Agent Gateway를 통해 Agent Runtime 트래픽 라우팅
Agent Gateway를 통해 Agent Runtime 트래픽을 라우팅하려면 다음 단계를 수행하세요.
에이전트 게이트웨이 리소스를 만들고 필요에 따라 승인 정책을 연결합니다. 에이전트-어디로든 (이그레스) 모드 또는 클라이언트-에이전트 (인그레스) 모드에서 게이트웨이를 만들 수 있습니다. 에이전트와 게이트웨이는 동일한 프로젝트와 리전에서 생성해야 합니다. 자세한 내용은 에이전트 게이트웨이 설정을 참고하세요.
게이트웨이가 배포 요구사항을 충족하도록 구성되어 있는지 확인합니다. 예를 들어 에이전트에 LLM 액세스가 필요한 경우 잠재적인 에이전트 런타임 배포 실패를 방지하기 위해 이 액세스를 허용하도록 게이트웨이를 구성합니다.
Agent Gateway를 통해 트래픽을 라우팅하도록 에이전트를 구성합니다.
신규 상담사
에이전트를 배포하는 동안 게이트웨이 리소스를 지정합니다. 예를 들어 Agent Runtime에 에이전트를 배포하려면
client.agent_engines.create를 사용하여local_agent객체를 선택적 구성과 함께 전달합니다.이 에이전트와 함께 Model Armor 또는 Semantic Governance Policies와 같은 게이트웨이 중재 플랫폼 기능을 사용하려면 이 예와 같이 생성 호출에서
agent_gateway_config와identity_type=AGENT_IDENTITY를 모두 설정하세요.identity_type=AGENT_IDENTITY가 없으면 런타임 인스턴스의effectiveIdentity이 기본 Vertex AI 서비스 계정으로 대체되고 시맨틱 거버넌스 정책이 정책 생성 선택기에서 에이전트를 자동으로 필터링합니다.remote_agent = client.agent_engines.create( agent=local_agent, config={ "agent_gateway_config": { "agent_to_anywhere_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME}, # "client_to_agent_config": {"agent_gateway": projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME} }, "identity_type": types.IdentityType.AGENT_IDENTITY, # Other optional configuration ... # "requirements": requirements, # "gcs_dir_name": gcs_dir_name, # https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/agent-identity#opt-out-caa "env_vars": { "GOOGLE_API_PREVENT_AGENT_TOKEN_SHARING_FOR_GCP_SERVICES": False, } }, )
AGENT_GATEWAY_TO_ANYWHERE_NAME을 에이전트-투-애니웨어(egress) 모드에서 만든 에이전트 게이트웨이의 이름으로 바꿉니다.클라이언트-에이전트 (인그레스) 모드에서 게이트웨이를 만든 경우 대신
client_to_agent_config필드를 사용하고AGENT_GATEWAY_CLIENT_TO_AGENT_NAME을 인그레스를 위해 만든 에이전트 게이트웨이의 이름으로 바꿉니다.기존 상담사의 경우
Agent-to-Anywhere
다음 REST API 요청을 사용하여 기존 상담사를 출구용 Agent-to-Anywhere 게이트웨이와 연결합니다.
curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ -d '{ "spec": { "deploymentSpec": { "agentGatewayConfig": { "agentToAnywhereConfig": { "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_TO_ANYWHERE_NAME" } } } } }' \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.REGION: 에이전트가 배포된 리전AGENT_GATEWAY_TO_ANYWHERE_NAME: 에이전트에서 모든 위치로(이그레스) 모드에서 만든 에이전트 게이트웨이의 이름RESOURCE_ID: 에이전트의 리소스 ID
클라이언트에서 에이전트로
다음 REST API 요청을 사용하여 기존 상담사를 인그레스용 Client-to-Agent gateway와 연결합니다.
curl -X PATCH \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ -d '{ "spec": { "deploymentSpec": { "agentGatewayConfig": { "clientToAgentConfig": { "agentGateway": "projects/PROJECT_ID/locations/REGION/agentGateways/AGENT_GATEWAY_CLIENT_TO_AGENT_NAME" } } } } }' \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID?updateMask=spec.deploymentSpec.agentGatewayConfig"
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.REGION: 에이전트가 배포된 리전AGENT_GATEWAY_CLIENT_TO_AGENT_NAME: 클라이언트에서 에이전트로(인그레스)에서 만든 에이전트 게이트웨이의 이름RESOURCE_ID: 에이전트의 리소스 ID
에이전트 및 게이트웨이와 동일한 프로젝트 및 리전의 에이전트 레지스트리 인스턴스에 등록합니다.
gcloud agent-registry services create SERVICE_NAME \ --project=PROJECT_ID \ --location=REGION \ --display-name="DISPLAY_NAME" \ --endpoint-spec-type=no-spec \ --interfaces='[{url="https://REGION-aiplatform.mtls.googleapis.com",protocolBinding="jsonrpc"}]' \ --format="value(registryResource)"다음을 바꿉니다.
SERVICE_NAME: 리소스에 지정할 이름(예:allow-aiplatform-region-eu3)PROJECT_ID: 프로젝트 ID입니다.REGION: 레지스트리 리전입니다.DISPLAY_NAME: 엔드포인트의 사람이 읽을 수 있는 이름입니다.
자세한 내용은 에이전트 등록을 참고하세요.
에이전트에 대한 에이전트-레지스트리 IAM 정책 바인딩을 만듭니다.
gcloud iap web add-iam-policy-binding \ --resource-type=agent-registry \ --endpoint=ENDPOINT_ID \ --region=REGION \ --project=PROJECT_ID \ --member=MEMBER \ --role=roles/iap.egressor
다음을 바꿉니다.
ENDPOINT_ID: 등록된 에이전트의 서비스 엔드포인트 ID입니다. 이 값은 이전 단계의 출력에서 가져옵니다.MEMBER: 역할을 부여할 에이전트 ID 주 구성원입니다. 일반적으로 형식은principal://TRUST_DOMAIN/resources/aiplatform/projects/PROJECT_ID/locations/REGION/reasoningEngines/ENGINE_ID입니다.
이제 에이전트 트래픽이 에이전트 게이트웨이를 통해 라우팅됩니다. 하지만 에이전트 게이트웨이는 기본 거부 정책을 채택합니다. 특정 Agent Platform 기능을 사용 설정하려면 에이전트가 다음 엔드포인트와 통신할 수 있어야 합니다.
Cloud Trace가 사용 설정된 경우 에이전트 게이트웨이는 엔드포인트
https://telemetry.googleapis.com/로의 트래픽을 허용해야 합니다.GOOGLE_API_USE_CLIENT_CERTIFICATE및GOOGLE_API_USE_MTLS_ENDPOINT환경 변수가 설정된 경우https://telemetry.mtls.googleapis.com/로의 트래픽도 허용되는지 확인합니다.Cloud Logging이 사용 설정된 경우 에이전트 게이트웨이는 엔드포인트
https://logging.googleapis.com/로의 트래픽을 허용해야 합니다.GOOGLE_API_USE_CLIENT_CERTIFICATE및GOOGLE_API_USE_MTLS_ENDPOINT환경 변수가 설정된 경우https://logging.mtls.googleapis.com/로의 트래픽도 허용되는지 확인합니다.
또한 에이전트가 LLM을 호출하거나 세션 및 메모리 뱅크와 같은 기능을 사용하는 경우 에이전트가 이러한 서비스에서 사용하는 엔드포인트와 통신할 수 있는지 확인해야 합니다. 예를 들면 다음과 같습니다.
- 세션:
https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/sessions - 메모리 뱅크:
https://REGION-aiplatform.googleapis.com/API_VERSION/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID/memories
보안상의 이유로 에이전트가 액세스하는 특정 URI만 등록하고 허용 목록에 추가하는 것이 좋습니다. 게이트웨이는 호스트 이름을 직접 일치시키므로 에이전트 SDK가 사용하는 모든 변형을 등록해야 합니다. 예를 들어 SDK 버전, 리전 클라이언트 구성 또는 mTLS 사용에 따라 Google API는 다음 엔드포인트 호스트 이름을 통해 확인할 수 있습니다.
https://REGION-aiplatform.googleapis.comhttps://REGION-aiplatform.mtls.googleapis.comhttps://aiplatform.REGION.rep.googleapis.com
엔드포인트를 등록하는 방법을 알아보려면 엔드포인트 등록을 참고하세요. 또한 에이전트에 이러한 엔드포인트에 대한 IAP Egressor 역할이 있는지 확인해야 합니다. 자세한 내용은 에이전트-엔드포인트 이그레스 정책 만들기를 참고하세요.
에이전트 구성을 확인합니다.
콘솔
- Google Cloud 콘솔에서 에이전트 플랫폼 배포 페이지로 이동합니다.
배포한 에이전트의 이름을 클릭합니다.
서비스 구성을 클릭합니다. 에이전트의 관측 가능성 창이 열립니다.
배포 세부정보를 클릭합니다. 에이전트 게이트웨이 인그레스 및 이그레스 구성은 배포 사양 필드에서 확인할 수 있습니다.
gcloud
다음 REST API 요청을 사용하여 에이전트가 이제 게이트웨이와 연결되었는지 확인합니다. 반환된 출력이
null이면 런타임이 게이트웨이에 바인딩되지 않은 것입니다.curl -s -X GET \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT_ID/locations/REGION/reasoningEngines/RESOURCE_ID" \ | jq '.spec.deploymentSpec.agentGatewayConfig'
다음을 바꿉니다.
PROJECT_ID: 프로젝트 ID입니다.REGION: 에이전트가 배포된 리전RESOURCE_ID: 에이전트의 리소스 ID
- Google Cloud 콘솔에서 에이전트 플랫폼 배포 페이지로 이동합니다.
승인된 에이전트 게이트웨이로 에이전트 런타임 제한
에이전트를 배포하는 동안 사용할 수 있는 적격한 에이전트 게이트웨이 리소스 집합을 정의하는 맞춤 조직 정책 제약 조건을 만들 수 있습니다.
커스텀 조직 정책 제약조건 만들기
이 예시에서는 사전 승인된 게이트웨이 목록으로 오가는 트래픽만 허용하는 맞춤 제약 조건을 만듭니다.
Agent-to-Anywhere
에이전트-임의 위치 모드 (이그레스)의 맞춤 제약 조건을 정의하려면
constraint-agent-gateway-egress.yaml라는 파일을 만듭니다.다음 예에서
condition필드는 에이전트 게이트웨이 리소스가 지정된 경우(필드가 있고 비어 있지 않음) 지정된 게이트웨이가 사전 승인된 목록에 있는 경우에만 작업이 허용됨을 지정합니다.name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedEgressAgentGatewaysForAgentEngine resource_types: - aiplatform.googleapis.com/ReasoningEngine condition: >- has(resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway) && resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway != '' && (resource.spec.deploymentSpec.agentGatewayConfig.agentToAnywhereConfig.agentGateway in [ 'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1', 'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2', ]) method_types: - CREATE - UPDATE action_type: ALLOW display_name: Restrict Reasoning Engine Egress to Approved Agent Gateways description: Reasoning Engines can only be bound to a pre-approved list of Agent Gateway instances. Binding to any other gateway is denied.다음을 바꿉니다.
- ORGANIZATION_ID: 조직 ID입니다.
- AGENT_PROJECT_ID: 프로젝트 ID입니다.
- REGION: 게이트웨이가 생성된 리전입니다.
- AGENT_GATEWAY_ID: 게이트웨이 ID입니다.
커스텀 제약 조건을 적용합니다.
gcloud org-policies set-custom-constraint EGRESS_CONSTRAINT_PATH
EGRESS_CONSTRAINT_PATH을 이전 단계에서 만든 맞춤 제약 조건 파일의 전체 경로로 바꿉니다.
제약 조건을 적용하는 조직 정책을 만듭니다. 조직 정책을 정의하려면
policy-agent-gateway-egress.yaml이라는 정책 YAML 파일을 만듭니다. 이 예시에서는 프로젝트 수준에서 이 제약조건을 적용하지만 조직 또는 폴더 수준에서 이를 설정할 수도 있습니다.name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedEgressAgentGatewaysForAgentEngine spec: rules: - enforce: trueAGENT_PROJECT_ID를 프로젝트 ID로 바꿉니다.조직 정책을 적용합니다.
gcloud org-policies set-policy EGRESS_POLICY_PATH
EGRESS_POLICY_PATH을 이전 단계에서 만든 조직 정책 YAML 파일의 전체 경로로 바꿉니다. 정책이 적용되는 데 최대 15분이 소요됩니다.
클라이언트에서 에이전트로
클라이언트-에이전트 모드 (인그레스)의 맞춤 제약 조건을 정의하려면
constraint-agent-gateway-ingress.yaml라는 파일을 만듭니다.다음 예에서
condition필드는 에이전트 게이트웨이 리소스가 지정된 경우(필드가 있고 비어 있지 않음) 지정된 게이트웨이가 사전 승인된 목록에 있는 경우에만 작업이 허용됨을 지정합니다.name: organizations/ORGANIZATION_ID/customConstraints/custom.allowlistedIngressAgentGatewaysForAgentEngine resource_types: - aiplatform.googleapis.com/ReasoningEngine condition: >- has(resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway) && resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway != '' && (resource.spec.deploymentSpec.agentGatewayConfig.clientToAgentConfig.agentGateway in [ 'projects/AGENT_PROJECT_ID_1/locations/REGION_1/agentGateways/AGENT_GATEWAY_ID_1', 'projects/AGENT_PROJECT_ID_2/locations/REGION_2/agentGateways/AGENT_GATEWAY_ID_2', ]) method_types: - CREATE - UPDATE action_type: ALLOW display_name: Restrict Reasoning Engine Ingress to Approved Agent Gateways description: Reasoning Engines can only be bound to a pre-approved list of Agent Gateway instances. Binding to any other gateway is denied.다음을 바꿉니다.
- ORGANIZATION_ID: 조직 ID입니다.
- AGENT_PROJECT_ID: 프로젝트 ID입니다.
- REGION: 게이트웨이가 생성된 리전입니다.
- AGENT_GATEWAY_ID: 게이트웨이 ID입니다.
커스텀 제약 조건을 적용합니다.
gcloud org-policies set-custom-constraint INGRESS_CONSTRAINT_PATH
INGRESS_CONSTRAINT_PATH을 이전 단계에서 만든 맞춤 제약 조건 파일의 전체 경로로 바꿉니다.
제약 조건을 적용하는 조직 정책을 만듭니다. 조직 정책을 정의하려면
policy-agent-gateway-ingress.yaml이라는 정책 YAML 파일을 만듭니다. 이 예시에서는 프로젝트 수준에서 이 제약조건을 적용하지만 조직 또는 폴더 수준에서 이를 설정할 수도 있습니다.name: projects/AGENT_PROJECT_ID/policies/custom.allowlistedIngressAgentGatewaysForAgentEngine spec: rules: - enforce: trueAGENT_PROJECT_ID를 프로젝트 ID로 바꿉니다.조직 정책을 적용합니다.
gcloud org-policies set-policy INGRESS_POLICY_PATH
INGRESS_POLICY_PATH을 이전 단계에서 만든 조직 정책 YAML 파일의 전체 경로로 바꿉니다. 정책이 적용되는 데 최대 15분이 소요됩니다.
커스텀 조직 정책 제약 조건을 사용하는 방법에 대한 자세한 내용은 커스텀 제약 조건 만들기를 참고하세요.
다음 단계
Codelab: Govern agentic workloads with Agent Platform
Gemini Enterprise Agent Platform에서 Agent Gateway를 사용하여 에이전트형 워크로드를 관리하는 방법을 알아보세요.