8편: 보안과 격리, Agent Sandbox와 Hypercluster
GKE Agent Sandbox와 GKE Hypercluster는 구글 쿠버네티스 엔진(GKE) 위에서 동작하는 두 보안 기능으로, Google Cloud Next 2026에서 한 묶음으로 강조되었습니다. 한쪽은 워크로드 단위로 신뢰되지 않은 코드를 가두고, 다른 한쪽은 클러스터 인프라 자체를 봉인해 가중치와 쿼리를 보호합니다. 본 글은 두 기능의 개념과 구성 요소, 동작 방식을 한 편에 정리해 보안 모델을 설계하는 플랫폼 운영자에게 어떤 선택지가 있는지 살펴봅니다. 본 시리즈는 Next 2026 GKE 신기능을 추론 인프라, 학습 인프라, 보안과 격리, 네트워킹의 4축으로 다루며, 이 글은 보안과 격리 축에 속합니다.
그림 1. 워크로드 격리와 인프라 격리, 두 결의 보안 모델 비교
배경: 두 가지 다른 위협, 두 가지 다른 격리
AI 워크로드가 다루는 위협은 한 가지 결이 아닙니다. 에이전트 런타임은 대규모 언어 모델(LLM)이 생성한 임의 코드를 실행해야 하므로 호스트 커널과 네트워크가 침해될 가능성을 가정해야 합니다. 한편 자체 학습한 모델 가중치와 사용자 쿼리를 다루는 추론 환경은 운영자 본인과 클라우드 제공자 직원까지 잠재 위협 모델에 포함하고 싶을 때가 있습니다. GKE는 이 두 결을 분리해 도구를 제공합니다. 워크로드 단위 격리는 Agent Sandbox가, 인프라 단위 격리는 Hypercluster가 담당합니다.
두 기능은 모두 사용 단계에 제약이 있습니다. Agent Sandbox는 Pre-GA 단계의 add-on으로 제공되고, Hypercluster는 자격 요건을 갖춘 특정 GKE 고객에게만 열려 있어 전용 계정 팀에 액세스를 신청해야 합니다.
워크로드 격리: Agent Sandbox
Agent Sandbox는 격리되고 상태를 갖는 단일 복제 워크로드를 GKE에서 관리하기 위한 add-on입니다. AI 에이전트 런타임처럼 신뢰되지 않은 LLM 생성 코드를 안전한 환경에서 실행하는 것을 주된 사용 사례로 삼습니다. 오픈소스 Agent Sandbox 컨트롤러 프로젝트를 기반으로 하며, 관리형 add-on으로 구글이 컨트롤러 라이프사이클과 보안 패치를 관리합니다.
핵심 가치와 사용 사례
Agent Sandbox는 커널 수준 격리·빠른 프로비저닝·클라우드 네이티브 확장성 세 가지 가치를 묶어 제공하며, AI 에이전트 런타임·개발 환경·Jupyter Notebook·단일 Pod 상태 저장 서비스를 대표 사용 사례로 다룹니다.
그림 2. Agent Sandbox의 세 가지 핵심 가치(커널 수준 격리·빠른 프로비저닝·클라우드 네이티브 확장성)와 네 가지 대표 사용 사례
Claim 모델과 SandboxClaim/SandboxTemplate
Agent Sandbox는 사용자의 요청과 실제 프로비저닝 구현을 분리하는 Claim 모델을 채택합니다. 표준 StatefulSet과 달리 사용자 정의 리소스(CRD)인 SandboxClaim이 SandboxTemplate을 참조해 샌드박스를 요청하면, 컨트롤러가 실제 Sandbox 인스턴스로 매핑합니다. 기존 Sandbox를 재사용하거나 풀에서 할당하는 식의 백엔드 유연성도 이 모델 덕분에 가능합니다.
핵심 리소스를 정리하면 다음과 같습니다.
- Sandbox CRD: 단일 상태 저장 Pod을 표현하는 기본 리소스. 안정 호스트네임, 네트워크 식별자, 영속 스토리지를 관리합니다.
- Sandbox Router: 안정된 엔드포인트를 제공하고 트래픽을 적절한 Sandbox Pod으로 터널링합니다.
- Pod 스냅샷 통합: GKE Pod 스냅샷 기능과 통합되어 컨테이너 상태를 저장·복원함으로써 워크로드 일시 중단과 재개를 지원합니다.
Warm Pool과 동작 흐름
인터랙티브 AI 에이전트는 시작 지연이 곧 사용자 경험입니다. Agent Sandbox는 SandboxWarmPool CRD로 사전 워밍된 Pod 인스턴스를 준비 상태로 유지합니다. SandboxClaim이 들어오면 컨트롤러는 새 Pod이 이미지를 받고 처음부터 시작하기를 기다리지 않고, 풀에서 즉시 Pod을 배정합니다. Pod 스냅샷과 결합하면 사전에 구성된 상태에서 복원되는 “instant-on” 동작이 가능해집니다. 입력 자료는 이 조합으로 1초 미만의 실행 환경 제공을 명시합니다.
네트워크 측면에서 Agent Sandbox는 모든 샌드박스 환경에 대해 Default Deny 보안 자세를 적용합니다. 샌드박스 내부에서 실행되는 신뢰되지 않은 코드가 기본적으로 내부 네트워크나 GKE 컨트롤 플레인에 접근할 수 없습니다. 세부 송수신 규칙은 SandboxTemplate에서 정의합니다.
다음은 입력 자료의 네트워크 모델 비교 다이어그램으로, 격리 모드 네트워크 모델이 외부 통신 경로를 어떻게 좁히는지 보여줍니다. Agent Sandbox의 Default Deny 자세를 이해하는 데 참고가 됩니다.
그림 3. 격리 모드 네트워크 모델의 외부 통신 패턴
프로그래밍 액세스
제공합니다. SDK는 SandboxClaim과 SandboxTemplate 구성을 추상화한 상위 인터페이스를 제공해, LangChain이나 Vertex AI Agentic SDK 같은 Python 기반 에이전트 프레임워크에서 격리 환경을 직접 만들고 다룰 수 있게 합니다.
요구사항과 제한
Agent Sandbox 사용에는 몇 가지 전제가 따릅니다. 스냅샷을 포함한 전체 기능을 사용하려면 GKE 1.35.2-gke.1269000 이상이 필요하고, N2 머신 타입 같은 특정 노드 구성에 최적화되어 있으며, gVisor 같은 보안 강화 런타임과 함께 쓰이는 것이 주된 사용 시나리오입니다. Pod 스냅샷처럼 일부 기반 기능은 Preview 단계이거나 리전별 제공 범위에 제약이 있을 수 있습니다.
인프라 격리: Hypercluster
Hypercluster는 GKE나 AI Hypercomputer의 일반적 한계를 넘는 보안·확장성을 요구하는 고객을 위해 설계된 인프라 아키텍처입니다. 컨테이너를 클러스터 내 노드가 관리하는 원격 인스턴스에서 실행하며, 이 인스턴스들은 여러 리전에 걸쳐 동작할 수 있습니다. 일반 프로덕션 AI/ML 워크로드를 위한 기능은 아니며, 운영상 추가 마찰을 감수하더라도 자체 모델 가중치 같은 민감한 IP를 보호하거나 클러스터 노드 한도 너머의 규모로 확장해야 하는 사용 사례에 초점을 맞춥니다.
Linked Runners: kubelet 없는 경량 인스턴스
표준 GKE 클러스터의 모든 노드는 kubelet, 로깅·메트릭 에이전트, 그 밖의 GKE 시스템 구성 요소를 실행합니다. Hypercluster는 이 구조를 바꿉니다. linked runner라 부르는 인스턴스는 Kubernetes API 서버에 Node 객체로 등록되지 않으며, 다음 특성을 갖습니다.
- Kubernetes 에이전트가 없고 GKE 구성 요소도 최소한만 포함합니다.
- 사용 사례에 맞는 특수 OS 이미지를 사용하며, GKE 노드 이미지를 쓰지 않습니다.
- 별도의 전용 VPC 네트워크를 사용합니다.
linked runner는 클러스터 내 control node가 관리합니다. control node는 kubelet 같은 시스템 구성 요소를 실행하며, 하나의 control node가 여러 runner와 연결될 수 있습니다. linked runner에는 kubelet이 없고 API 서버 트래픽도 발생시키지 않으므로, Kubernetes API는 control node만 관리하면 됩니다. 학습 Job이 클러스터 리전 데이터센터의 용량을 초과하는 경우처럼 매우 큰 규모의 워크로드 실행이 주된 적용 지점입니다.
Default 구성과 Sealed 구성
linked runner 인스턴스는 Default와 Sealed 두 모드로 구성합니다. Default는 Container-Optimized OS 이미지를 실행하는 Compute Engine VM으로 SSH 진단을 허용하고, Sealed는 신뢰 실행 환경(TEE) 위에서 SSH·셸 접근을 차단해 모델 가중치와 쿼리를 운영자·구글 직원의 접근으로부터도 보호합니다. 두 모드의 OS·런타임, 접근·진단, 보안 속성, 용도 비교는 다음 인포그래픽으로 정리합니다.
그림 4. linked runner의 Default 구성과 Sealed 구성을 OS·접근·보안 속성·용도 축으로 비교
Sealed 구성에서는 인스턴스마다 attestation agent가 동작해 펌웨어·워크로드 측정값을 Google Cloud Attestation으로 보내고 검증 가능한 claim 토큰을 반환합니다. 어떤 워크로드를 받을지는 정책으로 정의하며, 서명된 컨테이너 이미지 다이제스트나 특정 Pod 사양 같은 요구를 명시합니다. TPU는 Private AI Compute 플랫폼 일부인 Titanium Intelligence enclave를, GPU는 NVIDIA Confidential Computing을 사용해 사용 중 데이터를 보호합니다.
동작 흐름: 가중치와 쿼리 보호
Sealed 구성으로 인스턴스를 만들면, 승인된 코드만 실행되고 민감 데이터는 하드웨어 기반 보안 enclave에서 처리되는 제한된 환경이 됩니다. 입력 자료는 모델 가중치와 쿼리·응답을 보호하는 두 가지 패턴을 제시합니다.
모델 가중치는 Cloud KMS의 Cloud HSM 키로 암호화한 뒤 Cloud Storage에 저장합니다. 해당 버킷의 읽기 권한과 복호화 키 액세스를 attested 워크로드에만 부여합니다. 쿼리와 응답도 같은 방식으로 Cloud HSM 키로 암호화하고, 복호화 권한을 attested 워크로드에만 부여하며, 워크로드 간 암호화 데이터 전송 시 attestation 증빙을 요구합니다. 즉 데이터의 평문 노출이 인증된 환경 안에서만 일어나도록 강제하는 흐름입니다.
다음은 GKE Inference Gateway가 Model Armor와 연동되는 보안 통합 다이어그램입니다. Hypercluster의 Sealed 인스턴스에서 추론 워크로드를 운영할 때 게이트웨이 계층의 정책 점검과 결합되는 모양을 떠올리는 데 참고가 됩니다.
그림 5. GKE Inference Gateway와 Model Armor 통합 구성
신뢰 모델과 자격 요건
Sealed 인스턴스는 호스트에 대한 관리자·구글 직원 접근을 차단하므로, 장애 시 일반적인 SSH 진단이 불가능합니다. 운영 마찰이 늘어난다는 의미입니다. 또 Hypercluster 자체가 일반 프로덕션 AI/ML 워크로드를 대상으로 한 기능이 아니므로, 적용 시 기존 GKE 관측·문제 해결 기능 일부가 linked runner 인프라에서 제공되지 않는다는 점도 고려해야 합니다. Hypercluster 사용에는 자격 요건이 있으며, 액세스는 전용 계정 팀에 신청해야 합니다.
참고로 GKE 보안 기준선은 컨트롤 플레인과 노드 사이 통신에 mTLS를 적용하고, 클러스터별로 분리된 root CA로 신뢰 루트를 구성합니다. 컨트롤 플레인은 CIS Kubernetes Benchmark에 맞춰 관리되며, 워커 노드와 워크로드 영역의 컴플라이언스는 fleet 단위 보안 자세 대시보드와 kube-bench 같은 도구로 평가합니다. Hypercluster는 이 기준선 위에 인프라 봉인을 더한 별도 트랙으로 보면 됩니다.
두 모델의 결을 비교하면
두 기능을 같은 표 위에 놓으면 차이가 분명해집니다.
| 항목 | Agent Sandbox | Hypercluster |
|---|---|---|
| 격리 단위 | Pod 단위 워크로드 | 인스턴스·인프라 |
| 주요 위협 모델 | 신뢰되지 않은 LLM 생성 코드 | 인사이더, 운영자, 클라우드 직원까지 |
| 격리 수단 | gVisor 등 커널 수준 런타임 | TEE(Titanium Intelligence enclave, NVIDIA Confidential Computing) |
| 핵심 CRD·구성 | SandboxClaim, SandboxTemplate, SandboxWarmPool | linked runner, control node, sealed configuration |
| 네트워크 자세 | Default Deny | 별도 전용 VPC |
| 제공 단계 | Pre-GA add-on | 자격 요건 기반 액세스 |
같은 보안이라는 단어를 쓰지만 보호하려는 대상과 신뢰 모델이 다릅니다. 에이전트가 만든 코드를 가두는 일과, 가중치와 쿼리가 평문으로 노출되는 환경 자체를 봉인하는 일은 별개의 문제입니다.
도입 검토 시 짚을 점
두 기능의 도입 평가는 각자 4개의 출발 질문으로 정리됩니다. Agent Sandbox는 코드 출처와 런타임·노드 호환성, Preview 의존성, 인터랙티브 시나리오 설계가 축이고, Hypercluster는 자격 검토와 위협 모델 정의, 진단 마찰 수용 여부, attestation·키 운영 설계가 축입니다.
그림 6. Agent Sandbox와 Hypercluster의 평가 출발점을 두 트랙 4단계로 정리
본 시리즈와의 연결
Agent Sandbox와 Hypercluster는 본 시리즈의 다른 글들과 다음과 같이 이어집니다.
- 본 시리즈 7편에서 다루는 강화학습 워크로드는 정책 학습 과정에서 LLM이 생성한 도구 호출이나 코드 실행을 포함하는 경우가 많고, 이때 Agent Sandbox가 신뢰되지 않은 코드의 격리된 실행 환경 역할을 합니다.
- 본 시리즈 2편의 GKE Inference Gateway는 라우팅과 Model Armor 정책 적용 지점입니다. Hypercluster Sealed 구성에서 추론 워크로드를 운영할 때 게이트웨이는 attested 워크로드로 가는 트래픽 경로를 통합하는 자리에 놓입니다.
참고 자료
- Google Cloud, “AI infrastructure at Next 26”, https://cloud.google.com/blog/ko/products/compute/ai-infrastructure-at-next26/
- Google Cloud, “Google Cloud Next 2026 wrap-up”, https://cloud.google.com/blog/topics/google-cloud-next/google-cloud-next-2026-wrap-up
- Google Cloud Documentation, “About GKE Agent Sandbox”, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/machine-learning/agent-sandbox
- Google Cloud Documentation, “Cluster trust”, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/cluster-trust
- Google Cloud Documentation, “CIS Benchmarks”, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/cis-benchmarks
- Google Cloud Documentation, “About GKE Hypercluster”, https://docs.cloud.google.com/kubernetes-engine/docs/concepts/hypercluster-overview
- Google Cloud Documentation, “Rotate customer-managed control plane CAs and keys”, https://docs.cloud.google.com/kubernetes-engine/docs/how-to/rotate-control-plane-cas-keys
- Google Cloud Documentation, “Configure fleet-level GKE security posture dashboard features”, https://docs.cloud.google.com/kubernetes-engine/docs/how-to/fleet-security-posture
자세한 내용이 궁금하시다면, 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.
