에이전트마다 microVM, 그런데 비밀은 샌드박스 밖에: Google Agent Compute Engine 해설

샌드박스의 root 권한이 필요한 코딩 에이전트에게 백엔드 API 키까지 주어야 할까요. Google Cloud의 Agent Compute Engine은 실행 권한과 백엔드 자격증명을 다른 경계에 둡니다. 작업 파일과 단기 워크로드 신원은 내부에 남지만, 백엔드 토큰 교환은 외부 게이트웨이에서 수행한다는 설계입니다.

Agent Compute Engine은 아직 일반 제공이 아닙니다. Google은 10월 22일 발표에서 "향후 몇 달 안에 preview"라고 밝혔고, 현재는 Gemini와 내부 평가·강화학습 워크로드에 쓰인다고 설명합니다. 아래 구조는 공식 기술 설명을 재구성한 것입니다. 원문 재확인은 10월 26일이며 실제 Google 런타임이나 비용은 측정하지 않았습니다.

지금 쓸 수 있는 기능과 발표된 설계를 구분한다

10월 22일 발표는 Agent Compute Engine의 preview를 향후 몇 달 안에 제공할 예정이라고 설명합니다. Google 내부에서 사용한다는 사실과 외부 고객이 지금 사용할 수 있다는 사실은 다릅니다.

GKE에서 실행하는 Agent Sandbox는 별도 문서와 운영 조건을 가진 기능입니다. 관련 런타임의 밀도·기동 시간 수치를 Agent Compute Engine의 서비스 보장으로 옮겨 쓰지 마세요. 이 글에서 확인한 발표에는 ACE의 확정 가격·리전·할당량·SLA가 없습니다.

구조: 뇌는 밖에, 손은 안에

Google의 설명은 에이전트를 두 부분으로 나눕니다. 하네스(뇌)는 모델을 호출하고 다음 행동을 결정합니다. 샌드박스(손)는 코드, 셸, 브라우저를 실행합니다. 중요한 것은 하네스가 샌드박스 밖에서 실행되고, 샌드박스는 하네스가 명시적으로 보낸 명령만 실행한다는 점입니다.

harness (outside, trusted)
   │  explicit tool call
   ▼
microVM (inside, untrusted)
   ├─ own guest kernel, root access
   ├─ no NIC, no metadata route
   └─ virtio-vsock → local unprivileged proxy
                        │ mTLS
                        ▼
                 Agent Gateway (off-node)
                   ├─ verify user delegation
                   ├─ verify SPIFFE workload identity
                   ├─ policy / DLP
                   └─ in-flight token swap → backend

이 구조에서 눈여겨볼 것은 네 가지입니다.

1. 네트워크 인터페이스가 없다. microVM은 표준 NIC 없이 부팅하고, 모든 통신이 vsock과 로컬 프록시를 거칩니다. 직접 VPC에 붙지 않습니다.
2. 메타데이터 서버에 접근할 수 없다. 클라우드 자격증명을 얻는 고전적인 SSRF 경로를 없앱니다.
3. 백엔드 장기 자격증명이 없다. 사용자 토큰, OAuth refresh token, 서비스 계정 키가 게스트 메모리나 디스크에 없습니다. 게스트에는 세션 범위의 짧은 SPIFFE 인증서와 단기 토큰만 있습니다.
4. 토큰 교환은 밖에서 일어난다. Agent Gateway가 사용자 위임, 에이전트 아이덴티티, 노드 아이덴티티를 검증한 뒤, 요청이 게이트웨이를 떠날 때 백엔드 자격증명을 끼워 넣습니다.

Google은 이를 네 개의 아이덴티티로 설명합니다. 사용자 아이덴티티, 사용자를 대신하는 위임 아이덴티티, microVM에 부여되는 워크로드 아이덴티티, 에이전트 자체의 인력 아이덴티티입니다. 샌드박스에서 실제로 쓰이는 것은 세 번째뿐이고, 이 인증서는 밖으로 유출돼도 백엔드 API를 직접 호출할 수 없습니다. "어느 샌드박스가 패킷을 보냈는가"를 증명하는 용도이기 때문입니다.

"자격증명이 없다"가 의미하는 것

이 설계가 줄이는 위협은 분명합니다.

• 프롬프트 인젝션으로 환경 변수나 홈 디렉터리의 키를 읽어 외부로 보내는 공격
• 샌드박스 root 권한을 얻은 뒤 클라우드 메타데이터에서 토큰을 훔치는 공격
• 게스트 메모리 덤프나 스냅샷에서 장기 자격증명을 꺼내는 공격

하지만 "비밀이 없다"가 "권한이 없다"는 뜻은 아닙니다. 샌드박스는 여전히 하네스가 요청한 작업을 수행하고, 게이트웨이는 정책이 허용한 범위에서 백엔드 토큰을 주입합니다. 공격자가 게스트를 완전히 장악하면 다음이 가능합니다.

핵심은 마지막 줄입니다. 자격증명을 밖으로 빼면 샌드박스는 덜 매력적인 표적이 되지만, 게이트웨이가 더 매력적인 표적이 됩니다. "비밀이 없다"는 보안의 끝이 아니라, 신뢰 경계를 한 곳으로 모으는 설계입니다.

이식 가능한 샌드박스 점검표

자격증명 점검 자체가 유출 경로가 되지 않도록 로그에는 값 대신 이름만 남겨야 합니다. env 전체를 출력하면 비밀키가 터미널 기록과 CI 아티팩트에 들어갑니다. 다음 예제는 실제 환경 변수를 읽지 않고 가상 객체만 검사합니다. Node 18 이상에서 env-audit-demo.mjs로 저장해 실행했으며 외부 설치나 네트워크 호출은 없습니다.

// env-audit-demo.mjs — Node 18+, synthetic fixture only
function credentialNames(environment) {
  return Object.keys(environment)
    .filter(name => /key|token|secret|password|credential/i.test(name))
    .sort();
}
const fixture = { PATH: "/usr/bin", API_KEY: "fictional", SESSION_TOKEN: "fictional" };
console.log(JSON.stringify(credentialNames(fixture)));

["API_KEY","SESSION_TOKEN"]

이는 이름 기반 탐색일 뿐 비밀 검사기가 아닙니다. 이름에 key가 있는 일반 설정은 오탐하고 AUTH 같은 이름의 비밀은 놓칠 수 있습니다. 실제 적용 시 값 출력 금지, 허용된 단기 신원과 금지된 장기 키의 구분, 파일·메모리·로그에 남는 토큰까지 별도 검토해야 합니다. 위 출력은 가상 데이터의 결과이며 어떤 실제 샌드박스가 안전하다는 판정이 아닙니다.

점검표를 운영 규칙으로 바꾸면 다음과 같습니다.

유휴 비용: 체크포인트가 언제 이득인가

Google의 설명 중 실무적으로 중요한 부분은 "대부분의 에이전트는 대기한다"입니다. 모델 응답을 기다리고, 사용자 입력을 기다립니다. 이때 CPU와 메모리를 예약해 두면 비용이 낭비됩니다. Agent Compute Engine은 애플리케이션 수준에서 유휴를 감지해 체크포인트하고, 다음 도구 호출 때 복원합니다.

비용을 비교하려면 비율과 금액의 단위를 맞춰야 합니다. 관측 기간 H시간, 활성 비율 r, 활성 단가 a달러/시간, 스냅샷 보관 단가 s달러/시간, 복원 횟수 n, 회당 복원 비용 w달러라 두면 단순 모델은 다음과 같습니다.

always_on_usd = H * a
checkpoint_usd = H * r * a + H * s + n * w

이 표는 Google 가격표나 실측이 아니라 단위를 명시한 자체 산술 예제입니다. 같은 기간 동안 스냅샷을 보관한다고 가정하며 네트워크·디스크 I/O·최소 과금·체크포인트 생성 비용은 생략했습니다. 낮은 활성 비율만으로는 절약을 보장하지 않습니다. 자주 깨어나거나 매번 상태를 크게 저장하면 비용이 뒤집힙니다. 복원 지연도 별도 지표입니다. 비용이 손익분기를 넘지 않더라도 사용자에게 보이는 p95 대기 시간을 충족해야 합니다.

남는 위험과 확인할 것

• preview 상태: 가격, 리전, 할당량, SLA, 데이터 보관 정책이 공개되지 않았습니다. 계약 전에 확인해야 합니다.
• 측채널: Google은 CPU 측채널 완화를 적용한다고 밝혔지만, 같은 호스트를 공유하는 이상 캐시 타이밍 채널은 이론적으로 남습니다. OpenAI가 별도 글에서 공유 호스트의 캐시 타이밍 통신을 공개한 사례가 이를 보여줍니다.
• 게이트웨이 집중: 자격증명 교환이 한 지점에 모이므로, 게이트웨이의 가용성과 권한 검증이 전체 보안의 단일 실패점이 될 수 있습니다.
• 정책의 넓이: "허용된 egress"가 곧 데이터 유출 경로입니다. DLP와 목적지 allowlist를 함께 봐야 합니다.

결론: microVM보다 신뢰 경계의 위치가 중요하다

Agent Compute Engine의 진짜 메시지는 "에이전트마다 VM을 준다"가 아닙니다. 하네스를 샌드박스 밖에 두고, 자격증명을 게스트 밖에 두고, 모든 통신을 정책이 있는 게이트웨이로 모으고, 세션마다 짧은 아이덴티티를 준다는 것입니다. microVM은 이 원칙을 구현하는 수단입니다.

당장 Google의 서비스를 쓸 수 없더라도 네 가지는 오늘 적용할 수 있습니다. 샌드박스에 장기 키를 넣지 않기, 메타데이터와 DNS를 별도로 막기, egress를 프록시 한 곳으로 모으기, 유휴 세션을 체크포인트하기. microVM 경계와 별개로 이 항목들을 검증해야 합니다. 체크포인트는 비용·수명주기 최적화이며 그 자체가 보안 통제는 아닙니다.

말미의 유료 강의 홍보는 하네스·루프·그래프를 이용한 에이전트 실행 구조를 다룹니다. 이 글의 실행 경계 설계와 연결되며 Google Cloud 서비스 사용 교육이나 보안 인증 과정으로 소개하지 않습니다.

함께 읽으면 좋은 글

• AI 에이전트 보안 입문: 권한 없이 실행하면 안 되는 이유
• Firecracker 학습 샌드박스의 p99 지연
• 에이전트가 DNS로 빠져나간 2시간 44분

참고 자료

• Google Cloud: Introducing Agent Compute Engine and expanded agent governance
• Google Cloud: Inside Agent Compute Engine
• Google Cloud: Isolate AI code execution with Agent Sandbox on GKE