이 페이지에서는 Agent Gateway를 통해 Agent Runtime 트래픽을 라우팅하는 방법을 설명합니다. Agent Gateway는 Gemini Enterprise Agent Platform 생태계의 중앙 네트워킹 및 보안 구성요소입니다. 사용자와 에이전트 간, 에이전트와 도구 간 또는 에이전트 간에 발생하는 모든 에이전트 상호작용에 대해 안전하고 관리되는 연결을 제공합니다.
시작하기 전에
Agent Runtime에 에이전트를 배포하는 방법을 숙지해야 합니다.
Agent Gateway 에 대해 알아봅니다. Agent-to-Anywhere (이그레스) 모드에서 Agent Gateway를 사용하여 도구, 모델, API, 기타 에이전트로의 아웃바운드 트래픽을 포함한 모든 아웃바운드 통신을 보호하고 관리할 수 있습니다. 클라이언트-에이전트(인그레스) 모드에서 게이트웨이를 사용하여 에이전트에 액세스할 수 있는 클라이언트를 제어합니다. 게이트웨이를 사용하면 이러한 상호작용에 적용해야 하는 IAP 정책 및 Model Armor 템플릿을 선택할 수 있습니다.
단일 Runtime 인스턴스는 Agent-to-Anywhere(이그레스) 게이트웨이와 클라이언트-에이전트 (인그레스) 게이트웨이에 동시에 결합될 수 있습니다.
제한사항
- Agent Gateway는 2026년 4월 29일 이전에 생성된 Runtime 추론 엔진에 결합될 수 없습니다.
단일 프로젝트 및 리전에서 여러 Agent-to-Anywhere (이그레스) 및 클라이언트-에이전트 (인그레스) Agent Gateway 인스턴스를 호스팅할 수 있지만 동일한 프로젝트 및 리전에 배포된 모든 Agent Runtime 에이전트는 동일한 특정 이그레스 및 인그레스 Agent Gateway 인스턴스에 결합되어야 합니다.
예를 들어 프로젝트 및 리전에
egress-gateway-X및egress-gateway-Y가 포함되어 있는 경우 해당 프로젝트 및 리전의 모든 에이전트는 이그레스에 동일한 게이트웨이를 사용하도록 구성되어야 합니다. 즉, 모든 에이전트가egress-gateway-X를 사용하거나 모든 에이전트가egress-gateway-Y를 사용합니다.agent-A가egress-gateway-X를 사용하고agent-B가egress-gateway-Y를 사용하도록 구성할 수는 없습니다.이 동일한 결합 규칙은 프로젝트 및 리전 내의 인그레스 게이트웨이에도 적용됩니다.
에이전트에 Agent Gateway가 사용 설정된 경우 Security Command Center Agent Engine Threat Detection 서비스 를 사용할 수 없습니다.
클라이언트-에이전트 (인그레스) 모드에서 Agent Gateway는 Agent Runtime의
query및streamQuery메서드만 관리할 수 있습니다. 지원되지 않는 다른 메서드 (예:asyncQuery)를 보호하려면 애플리케이션 또는 에이전트에서 직접 Model Armor 템플릿을 적용하면 됩니다. 프롬프트 및 응답 삭제 또는 Model Armor를 통해 보안 에이전트 시스템 빌드하기의 이 Codelab을 참조하세요.
Agent Gateway를 통해 Agent Runtime 트래픽 라우팅
Agent Gateway를 통해 Agent Runtime 트래픽을 라우팅하려면 다음 단계를 수행하세요.
Agent Gateway 리소스를 만들고 필요한 승인 정책을 연결합니다. Agent-to-Anywhere (이그레스) 모드 또는 클라이언트-에이전트 (인그레스) 모드에서 게이트웨이를 만들 수 있습니다. 에이전트와 게이트웨이는 동일한 프로젝트 및 리전에서 만들어야 합니다. 자세한 내용은 Agent Gateway 설정을 참조하세요.
게이트웨이가 배포 요구사항을 충족하도록 구성되어 있는지 확인합니다. 예를 들어 에이전트에 LLM 액세스가 필요한 경우 잠재적인 Agent Runtime 배포 실패를 방지하기 위해 이 액세스를 허용하도록 게이트웨이를 구성합니다.
Agent Gateway를 통해 트래픽을 라우팅하도록 에이전트를 구성합니다.
새 에이전트의 경우
에이전트를 배포하는 동안 게이트웨이 리소스를 지정합니다. 예를 들어 Agent Runtime에 에이전트를 배포하려면
client.agent_engines.create를 사용하여 선택적 구성과 함께local_agent객체를 전달합니다.이 에이전트와 함께 Model Armor 또는 시맨틱 거버넌스 정책 과 같은 게이트웨이 중재 플랫폼 기능을 사용하려면 이 예와 같이 만들기 호출에서
agent_gateway_config와identity_type=AGENT_IDENTITY를 모두 설정합니다.identity_type=AGENT_IDENTITY가 없으면 Runtime 인스턴스의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을 Agent-to-Anywhere(이그레스) 모드에서 만든 Agent Gateway의 이름으로 바꿉니다.클라이언트-에이전트 (인그레스) 모드에서 게이트웨이를 만든 경우
client_to_agent_config필드를 대신 사용하고AGENT_GATEWAY_CLIENT_TO_AGENT_NAME을 인그레스를 위해 만든 Agent Gateway의 이름으로 바꿉니다.기존 에이전트의 경우
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: Agent-to-Anywhere(이그레스) 모드에서 만든 Agent Gateway의 이름입니다.RESOURCE_ID: 에이전트의 리소스 ID 입니다.
클라이언트-에이전트
다음 REST API 요청을 사용하여 기존 에이전트를 인그레스용 클라이언트-에이전트 게이트웨이 와 연결합니다.
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: 클라이언트-에이전트(인그레스)에서 만든 Agent Gateway의 이름입니다.RESOURCE_ID: 에이전트의 리소스 ID입니다.
에이전트 및 게이트웨이와 동일한 프로젝트 및 리전의 Agent Registry 인스턴스에 등록합니다.
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 Gateway를 통해 전달됩니다. 하지만 Agent Gateway는 기본 거부 정책을 채택합니다. 특정 Agent Platform 기능을 사용 설정하려면 에이전트가 다음 엔드포인트와 통신할 수 있는지 확인해야 합니다.
Cloud Trace가 사용 설정된 경우 Agent Gateway는 엔드포인트
https://telemetry.googleapis.com/로의 트래픽을 허용해야 합니다.GOOGLE_API_USE_CLIENT_CERTIFICATE및GOOGLE_API_USE_MTLS_ENDPOINT환경 변수가 설정된 경우https://telemetry.mtls.googleapis.com/로의 트래픽도 허용되는지 확인합니다.Cloud Logging이 사용 설정된 경우 Agent Gateway는 엔드포인트
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 이그레스 권한 부여자 역할이 있어야 합니다. 자세한 내용은 에이전트-엔드포인트 이그레스 정책 만들기를 참조하세요.
에이전트 구성을 확인합니다.
콘솔
- 콘솔에서 Agent Platform 배포 페이지로 이동합니다.
Google Cloud 배포한 에이전트의 이름을 클릭합니다.
서비스 구성 을 클릭합니다. 에이전트의 관찰 가능성 창이 열립니다.
배포 세부정보 를 클릭합니다. Agent Gateway 인그레스 및 이그레스 구성은 배포 사양 필드에서 확인할 수 있습니다.
gcloud
다음 REST API 요청을 사용하여 에이전트가 이제 게이트웨이와 연결되어 있는지 확인합니다. 반환된 출력이
null이면 Runtime이 게이트웨이에 결합되지 않은 것입니다.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입니다.
- 콘솔에서 Agent Platform 배포 페이지로 이동합니다.
승인된 Agent Gateway로 Agent Runtime 제한
커스텀 조직 정책 제약조건을 만들어 에이전트를 배포하는 동안 사용할 수 있는 적격 Agent Gateway 리소스 집합을 정의할 수 있습니다.
커스텀 조직 정책 제약조건 만들기
이 예에서는 사전 승인된 게이트웨이 목록으로의 트래픽만 허용하는 커스텀 제약조건을 만듭니다.
Agent-to-Anywhere
Agent-to-Anywhere 모드 (이그레스)의 커스텀 제약조건을 정의하려면
constraint-agent-gateway-egress.yaml이라는 파일을 만듭니다.다음 예에서
condition필드는 Agent Gateway 리소스가 지정된 경우(필드가 있고 비어 있지 않음) 그리고 지정된 게이트웨이가 사전 승인된 목록에 있는 경우에만 작업이 허용되도록 지정합니다.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필드는 Agent Gateway 리소스가 지정된 경우(필드가 있고 비어 있지 않음) 그리고 지정된 게이트웨이가 사전 승인된 목록에 있는 경우에만 작업이 허용되도록 지정합니다.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: Agent Platform으로 에이전트 워크로드 관리
Gemini Enterprise Agent Platform에서 Agent Gateway를 사용하여 에이전트 워크로드를 관리하는 방법을 알아봅니다.