왜 2026년에도 Gemini Enterprise·Agent Platform 분할이 반복 주제인가

Google Cloud Next를 비롯해 클라우드 행사에서 강조되는 Gemini Enterprise와 Agent Platform(계측·오케스트레이션 UI가 붙은 에이전트 스택)은 기업 계정·조직 프로젝트·리전 쿼터와 맞물려 흐름이 소비자용 AI Studio보다 복잡합니다. 화면은 열리는데 API 타임아웃만 반복되거나, SSO 이후 콘솔 일부 탭이 빈 상태로 멈추는 현상은 대개 “한 호스트만 다른 정책으로 새어 나갔다”거나 “리전 전용 *.googleapis.com이 예상과 다른 회선을 탄다”는 패턴으로 설명되는 경우가 많습니다.

이 글은 우회를 조장하지 않으며, 직장·계약·현지 법규와 Google Cloud 약관을 지키는 전제에서, 이미 합법적으로 프록시를 쓸 수 있는 환경에서 Clash·Mihomo의 분할 규칙·전략 그룹·DNS를 정돈하는 기술 절차를 다룹니다.

참고: Google은 엣지·내부 별칭·리전 호스트를 수시로 조정합니다. 아래 도메인 표는 출발점이며, 실패한 요청의 FQDN을 개발자 도구·gcloud 로그·애플리케이션 스택 트레이스에서 확인한 뒤 한 줄씩 보강하는 것이 가장 정확합니다.

소비자 Gemini 규칙과 무엇이 다른가

동일 저장소의 Gemini·AI Studio 분할 가이드는 gemini.google.com·generativelanguage.googleapis.com 같은 개발자·소비자 축을 중심으로 합니다. 반면 Gemini Enterprise·Vertex AI·에이전트 빌더류 워크로는 console.cloud.google.com을 거쳐 cloudresourcemanager.googleapis.com·serviceusage.googleapis.com으로 API 활성화를 확인하고, 모델 호출은 aiplatform.googleapis.com 또는 리전 접두가 붙은 호스트로 이어지는 경우가 잦습니다. 로그인·동의는 accounts.google.com·oauth2.googleapis.com·필요 시 www.googleapis.com 메타 요청이 함께 묶이므로, 이 축을 서로 다른 프록시 그룹으로 쪼갠 프로필에서는 세션 쿠키 흐름이 끊기기 쉽습니다.

또한 조직에서 Identity-Aware Proxy·내부 게이트웨이·제로 트러스트 클라이언트를 병행하면 브라우저와 백엔드 SDK가 서로 다른 SNI·인증서 체인을 보게 됩니다. 이때도 1차로는 “어떤 호스트가 어떤 Clash 정책에 매칭됐는지”를 로그에 박아 두고 역추적하는 편이 빠릅니다.

복사 전에 꼭 대조할 도메인·API 축

조직마다 활성화된 제품·리전이 다르므로 표 전체를 무비판적으로 붙여 넣지 마세요. 다만 초기 탐색을 줄이기 위해 자주 등장하는 후보를 묶었습니다.

  • 웹 콘솔·문서: cloud.google.com, console.cloud.google.com, 필요 시 developers.google.com
  • Vertex·에이전트·통합 예측 API: aiplatform.googleapis.com 및 조직에서 관측한 <region>-aiplatform.googleapis.com류 FQDN
  • 리소스·과금·서비스 활성화: cloudresourcemanager.googleapis.com, serviceusage.googleapis.com, 일부 환경에서 cloudbilling.googleapis.com
  • 스토리지·아티팩트 다운로드: 작업 특성에 따라 storage.googleapis.com·*.gcr.io·pkg.dev 관련 호스트
  • OAuth·계정: accounts.google.com, oauth2.googleapis.com, 필요 시 www.googleapis.com
  • 정적 자산: www.gstatic.com, fonts.gstatic.com — UI는 뜨는데 스크립트만 실패할 때 우선 확인

DOMAIN-SUFFIX,googleapis.com 한 줄로 모든 Google API를 한 그룹에 넣으면 관리는 쉬워지지만, 이미 사내에서 다른 Google 서비스를 국내 회선으로 두고 싶은 팀과 충돌합니다. Agent Platform 전용으로는 우선 aiplatform.googleapis.com처럼 관측된 FQDN을 DOMAIN으로 두고, 빈 구간이 생길 때만 접미사를 넓히는 편이 안전합니다.

전략 그룹·rules: 개념 예시

아래는 이해를 돕기 위한 축약 YAML입니다. 그룹 이름·프록시 목록·헬스 체크 URL은 구독과 회사 방화벽 정책에 맞게 바꾸고, 실제 프로덕션에서는 주석에 적어 둔 순서 제약을 지켜 주세요.

YAMLproxy-groups:
  - name: "GCP-Gemini-Agent"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - DIRECT
      # 지연·안정 요구에 맞는 해외/전용 노드

  - name: "Proxy"
    type: select
    proxies:
      - DIRECT
      # 일반 구독 노드

rules:
  - DOMAIN-SUFFIX,console.cloud.google.com,GCP-Gemini-Agent
  - DOMAIN-SUFFIX,cloud.google.com,GCP-Gemini-Agent
  - DOMAIN,aiplatform.googleapis.com,GCP-Gemini-Agent
  - DOMAIN,cloudresourcemanager.googleapis.com,GCP-Gemini-Agent
  - DOMAIN,serviceusage.googleapis.com,GCP-Gemini-Agent
  - DOMAIN,oauth2.googleapis.com,GCP-Gemini-Agent
  - DOMAIN,accounts.google.com,GCP-Gemini-Agent
  - DOMAIN-SUFFIX,gstatic.com,GCP-Gemini-Agent
  # 리전별 aiplatform 호스트는 로그로 확인 후 DOMAIN 행 추가
  # GEOIP·광범위 MATCH·RULE-SET보다 위에 둘 것

url-test/fallback 선택은 팀마다 다릅니다. Gemini Enterprise 데모와 배치 잡을 같은 프로필에서 돌린다면, 장기 스트림만 별도 그룹으로 쪼개 latency와 tolerance를 다르게 두는 편이 API 타임아웃 체감을 줄이는 데 도움이 됩니다.

API 타임아웃을 좁히는 역추적 순서

동일 증상이라도 원인은 TLS·HTTP/2·gRPC·DNS·중간 프록시·클라이언트 데드라인이 한꺼번에 겹칩니다. 아래 순서로 좁히면 재현 비용이 줄어듭니다.

  1. 대시보드 로그에서 실패한 연결의 매칭 규칙 이름과 policy group을 먼저 저장합니다. 예상과 다른 그룹이면 규칙 분할 가이드의 순서 원리를 적용해 상단에 예외를 올립니다.
  2. 브라우저 네트워크 탭과 curl -v를 병행해 SNI·해결된 IP를 비교합니다. 앱만 실패할 때는 시스템 DNS나 프록시 우회를 의심하고 TUN 적용 여부를 확인합니다.
  3. gRPC·스트리밍 호출은 TCP 세션이 길어져 패킷 손실에 민감합니다. 헬스 체크는 통과하는데 생성 요청만 지연된다면 노드 리전을 바꿔 재측정합니다.
  4. 클라이언트 SDK의 타임아웃·재시도 정책이 너무 짧으면 일시적 지연에도 DEADLINE_EXCEEDED 류로 보일 수 있으니 애플리케이션 설정도 함께 봅니다.

DNS fake-ip와 RULE-SET·GEOIP 상호작용

enhanced-mode: fake-ip를 쓰면 대부분 호스트 단계에서 DOMAIN 규칙이 먼저 적용되지만, Clash 밖에서 이미 IP로 소켓을 연 앱은 도메인 규칙을 건너뜁니다. IDE 플러그인·에이전트 런타임·컨테이너 내부 NO_PROXY 설정이 얽히면 증상이 갈라지므로, 한 번에 한 축만 바꿔 테스트하세요.

구독 템플릿이 자동으로 넣은 RULE-SET이 Google 호스트를 다른 정책으로 보내는 경우도 흔합니다. 로컬 예외 블록을 provider보다 위에 두거나, 신뢰할 수 있는 소스만 쓰도록 정리하세요. 출처 불명 rule-set은 악성 항목이 섞일 수 있으니 기업 데이터를 다루는 프로필일수록 주의합니다.

주의: Google Cloud API 키·워크로드 아이덴티티·에이전트 오케스트레이션 토큰이 로그에 노출되지 않게 다루고, 규칙 테스트는 스테이징 프로젝트에서 먼저 수행하세요.

운영 체크리스트

  1. 조직 SSO 이후에도 accounts.google.com과 API 콜이 같은 GCP-Gemini-Agent류 그룹으로 나가는지 확인합니다.
  2. 리전을 옮긴 뒤에는 aiplatform FQDN이 바뀌었는지 네트워크 탭에서 다시 적습니다.
  3. 배치 파이프라인이 storage.googleapis.com 대역을 크게 쓴다면 다운로드용 별도 그룹을 고려해 대역폭 경합을 줄입니다.
  4. 문제 재현 시각의 대시보드 로그를 스크린샷·텍스트로 남겨 팀과 공유하면 이후 분할 규칙 리뷰가 빨라집니다.

자주 묻는 질문

소비자용 AI Studio 규칙만으로 부족이면 무엇을 더하나요?

콘솔·조직 IAM·서비스 활성화·리전별 aiplatform 호스트가 추가됩니다. 최소한 console.cloud.google.com과 cloudresourcemanager.googleapis.com·serviceusage.googleapis.com 줄을 같은 운영 그룹에 넣고 관측을 이어 가세요.

규칙은 맞는데 타임아웃이 남습니다

노드 품질·리전 정책·클라이언트 데드라인·서버 측률 제한을 분리해 봅니다. 헬스 체크와 실제 Agent Platform 호출 경로가 다르면 url-test가 속일 수 있습니다.

넓은 googleapis.com 접미사를 써도 되나요?

팀 전체가 동의하고 다른 Google API와의 경로 충돌이 없을 때만 권장합니다. 그렇지 않으면 DOMAIN 단위로 쪼개는 편이 안전합니다.

마무리

Gemini Enterprise와 Agent Platform은 Google Cloud 콘솔·IAM·리전 API·OAuth·정적 자산이 한꺼번에 얽혀, 소비자용 Gemini 분할 패턴만으로는 빈틈이 생기기 쉽습니다. 필요한 FQDN을 전용 전략 그룹으로 묶고 DNS·규칙 순서·노드를 함께 맞추면 API 타임아웃 분석이 단순해집니다.

일체형 상용 VPN은 클릭 몇 번이면 켜지지만, 클라우드 콘솔처럼 호스트가 잘게 갈라진 시나리오에서는 “어떤 도메인을 어떤 노드로”를 세밀히 고정하기 어렵고 로그도 제한적인 경우가 많습니다. Clash·Mihomo 계열은 표현력이 높아 기업 개발자가 스스로 경로를 설계하기에 맞습니다. 반면 프로필 유지·로그 해석 책임도 함께 따라옵니다. Clash 공식 사이트는 구독 반영·테스트 워크플로를 문서화해 두어, 반복 튜닝 시간을 줄이는 데 초점을 맞춥니다.

설치·프로필 반영 흐름은 문서를 참고하시고, 규칙을 적용할 준비가 되었다면 Clash를 무료로 다운로드하여 본문 예시의 proxy-groups와 rules만 조직 표준에 맞게 조정해 보시길 바랍니다.