Google Virgo Network + Agent Sandbox 해설: 에이전트 시대 인프라는 GPU보다 동서 트래픽과 비신뢰 코드 실행 계층부터 분리해야 하는 이유

발행일: 2026-04-28 | 카테고리: 개발정보

1) 한 줄 문제 정의

핵심 요약: 에이전트 시스템은 모델 정확도보다 먼저 동서 트래픽 폭증과 비신뢰 코드 실행 때문에 운영이 흔들립니다.

대상 독자는 사내 AI 플랫폼, MLOps, 클라우드 인프라를 맡는 리드 개발자와 플랫폼 엔지니어입니다. 단일 챗봇 수준을 넘어서, 도구 호출·코드 실행·다중 에이전트 협업이 섞인 워크로드를 운영하려는 팀을 기준으로 설명합니다.

이 글의 범위는 Google Cloud Next '26에서 공개된 Virgo Network, Axion N4A, GKE Agent Sandbox를 바탕으로 에이전트 인프라를 어떻게 계층 분리해서 설계할지를 해설하는 것입니다. 개별 모델 품질 비교나 특정 벤더의 가격표 세부 계산은 범위에서 제외합니다.

2) 먼저 결론

핵심 요약: 에이전트 운영팀은 GPU를 더 사기 전에 네트워크 패브릭과 실행 격리 계층을 먼저 분리해야 합니다.

제가 내리는 결론은 단순합니다. 사용자가 한 번 요청할 때 수십~수백 개의 하위 작업이 동시에 터지는 에이전트 환경에서는, 모델 서빙과 일반 애플리케이션, 비신뢰 코드 실행을 같은 네트워크·같은 노드 정책으로 굴리면 곧 병목이 납니다.

Google이 이번에 강조한 포인트도 여기입니다. Virgo Network는 가속기끼리 오가는 동서 트래픽을 별도 스케일아웃 패브릭으로 분리하고, GKE Agent Sandbox는 도구 호출과 코드 실행을 격리된 샌드박스에 넣습니다. 즉, 에이전트 인프라의 핵심은 더 큰 모델보다 무엇을 어디서 분리할 것인가입니다.

반대로 아직 팀이 단일 추론 API 호출 중심이고 코드 실행이 거의 없다면, 이런 설계는 과합니다. 그 단계에서는 일반 Kubernetes + 추론 게이트웨이 + 관측성 강화만으로도 충분합니다.

3) 핵심 구조 분해

핵심 요약: 에이전트 인프라는 최소한 세 층으로 나눠 봐야 판단이 쉬워집니다.

• 가속기 계층: TPU/GPU가 모델 학습·추론을 담당합니다. 여기서는 대역폭, 집합 통신, KV 캐시, RDMA 효율이 핵심입니다.
• 스케일아웃 네트워크 계층: 가속기 간 동서 트래픽을 처리합니다. Google은 Virgo Network에서 최대 134,000개 TPU 8t 칩과 47Pb/s 비차단 대역폭, 이전 세대 대비 가속기당 최대 4배 대역폭, 40% 낮은 무부하 지연을 강조했습니다.
• 에이전트 실행 계층: 계획 수립, 툴 호출, 비신뢰 코드 실행, 피드백 루프를 맡습니다. Google은 이 영역에서 Axion N4A와 GKE Agent Sandbox를 묶어 설명했습니다.

중요한 점은 이 세 계층이 모두 필요하지만, 같은 방식으로 확장하면 안 된다는 것입니다. GPU는 처리량 중심, 패브릭은 지연·집합통신 중심, 샌드박스는 격리·폭주 제어 중심으로 봐야 합니다.

4) 설계 의도 해설

핵심 요약: Google의 설계 의도는 모든 것을 한 클러스터에서 돌리자가 아니라, 충돌하는 성격의 부하를 분리하자에 가깝습니다.

Virgo Network는 북-남 트래픽용 Jupiter와 분리된 동서 패브릭을 둡니다. 이 선택은 일반 서비스 네트워크와 AI 집합통신을 같은 규칙으로 다루지 않겠다는 선언입니다. 이유는 간단합니다. AI 학습·대규모 추론은 순간적인 버스트와 straggler 하나에 전체 goodput이 무너질 정도로 민감하기 때문입니다.

Agent Sandbox도 같은 맥락입니다. 에이전트가 생성한 코드나 툴 호출은 기능적으로는 애플리케이션 일부 같지만, 보안 관점에서는 잠재적으로 비신뢰 입력입니다. 그래서 일반 워커에 바로 실행하지 않고 샌드박스로 분리하는 편이 운영 안정성에 유리합니다.

이 설계가 포기하는 것도 있습니다. 운영 단순성, 벤더 중립성, 초기 학습 비용입니다. 대신 얻는 것은 장애 반경 축소, 비용 예측 가능성, 에이전트 폭주 시 복구 속도입니다. 저는 이 교환이 에이전트 운영 단계에 들어간 팀에게는 충분히 합리적이라고 봅니다.

5) 근거 및 비교

핵심 요약: 비교 기준은 GPU 숫자가 아니라 격리 수준, 네트워크 확장성, 운영 복구력입니다.

• 비용: 샌드박스를 두면 표면상 자원이 더 드는 것처럼 보이지만, 폭주한 에이전트가 비싼 GPU 추론 경로를 붙잡아 먹는 상황을 줄이면 총비용이 내려갈 수 있습니다.
• 시간: Google은 Agent Sandbox를 네이티브 서비스로 내세웠고, Axion N4A는 일반 x86 VM 대비 최대 2배 가격 대비 성능을, Agent Sandbox 조합은 다음 경쟁 하이퍼스케일러 대비 최대 30% 가격 대비 성능을 주장했습니다. 다만 이 수치는 반드시 파일럿으로 재검증해야 합니다.
• 정확도: 모델 정확도 자체는 변하지 않지만, straggler·지연 편차를 줄이면 에이전트 전체 성공률은 올라갑니다. 에이전트는 단일 토큰 속도보다 전체 체인 완주율이 더 중요하기 때문입니다.
• 운영성: AWS EFA는 강력하지만 문서상 Huge Pages, VPC CNI, 인스턴스/가용영역 제약까지 같이 관리해야 합니다. 반면 Google 접근은 네트워크와 샌드박스 계층을 함께 제품화한 점이 차별점입니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 처음부터 전면 전환하지 말고, 추론·실행·관측을 세 갈래로 쪼개는 파일럿부터 시작해야 합니다.

1. 1주차: 호출 체인 측정
   사용자 요청 1건이 내부적으로 몇 개의 모델 호출, 툴 호출, 코드 실행을 만드는지 계측합니다. 이 수치가 없으면 분리 우선순위를 정할 수 없습니다.
2. 2주차: 추론 경로와 실행 경로 분리
   모델 서빙은 기존 GPU/TPU 워크로드로 두고, 코드 실행·툴 래퍼는 별도 샌드박스 노드풀 또는 격리 런타임으로 이동합니다.
3. 3주차: 네트워크 병목 지표 고정
   P95 지연, job straggler 비율, sandbox 실패율, 요청 1건당 평균 툴 실행 수를 대시보드로 묶습니다.
4. 4주차: 제한 정책 추가
   에이전트별 동시 실행 수, CPU 상한, 네트워크 egress 정책, 타임아웃, 재시도 횟수를 선언적으로 고정합니다.
5. 5주차 이후: GPU 최적화는 그 다음
   격리 계층이 안정화된 뒤에야 KV 캐시, RDMA, 고성능 패브릭 튜닝을 붙입니다. 순서를 거꾸로 하면 장애 원인이 섞입니다.

# Agent Sandbox 예시 준비 변수 (Google 공식 문서 기준)
export PROJECT_ID=$(gcloud config get project)
export CLUSTER_NAME="agent-sandbox-cluster"
export LOCATION="us-central1"
export CLUSTER_VERSION="1.35.2-gke.1269000"

# 새 Autopilot 클러스터 생성 시 Agent Sandbox 활성화 예시
gcloud beta container clusters create-auto "$CLUSTER_NAME" \
  --project "$PROJECT_ID" \
  --location "$LOCATION" \
  --cluster-version "$CLUSTER_VERSION" \
  --enable-agent-sandbox

# 에이전트 실행 계층에서 먼저 모아야 할 운영 지표 예시
metrics:
  - agent_request_total
  - tool_execution_total
  - sandbox_startup_p95_ms
  - sandbox_timeout_total
  - model_inference_p95_ms
  - straggler_detection_total

7) 실수/함정(Pitfalls)

핵심 요약: 실패는 기술 부족보다 분리 안 함에서 더 자주 생깁니다.

1. 함정: 에이전트 툴 실행을 일반 앱 노드에 같이 배치
   예방: 샌드박스 전용 노드풀 또는 격리 런타임을 기본값으로 둡니다.
   복구: 툴 실행 워크로드를 긴급 격리하고 동시성 제한을 1차로 낮춥니다.
2. 함정: GPU 사용률만 보고 인프라가 건강하다고 판단
   예방: 요청 완주율, straggler 비율, sandbox 실패율을 함께 봅니다.
   복구: 모델 지연이 아니라 실행 체인 병목인지 대시보드에서 먼저 분해합니다.
3. 함정: 벤더 벤치마크를 그대로 예산안에 반영
   예방: 2주 파일럿에서 실제 워크로드 기준 P50/P95와 요청당 비용을 재측정합니다.
   복구: GPU·CPU·샌드박스 자원 할당을 별도 cost center로 나눠 재산정합니다.

8) 강점과 한계

핵심 요약: 이 구조는 대규모 에이전트 운영에 강하지만, 모든 팀에 바로 맞는 만능 해법은 아닙니다.

• 강점: 장애 반경 축소, 도구 실행 격리, 동서 트래픽 최적화, 추론과 실행 계층의 비용 분리.
• 강점: AI Hypercomputer 계층과 GKE 에이전트 운영 계층이 같은 이야기로 연결되어 있어 아키텍처 설명이 쉽습니다.
• 한계: 벤더 락인이 커집니다. 특히 Virgo Network는 설계 철학은 배울 수 있어도 그대로 이식되지는 않습니다.
• 한계: 공개된 수치 상당수가 공급자 발표이므로, 성능·가격효율은 반드시 자체 검증이 필요합니다.
• 한계: 아직 코드 실행이 거의 없는 팀에게는 오히려 운영 복잡도만 늘 수 있습니다.

9) 더 깊게 공부할 포인트

핵심 요약: 이 주제는 GPU보다 goodput, straggler, sandbox isolation 세 개념부터 파고드는 편이 낫습니다.

• Virgo Network가 왜 Jupiter와 분리됐는지 보려면 Google의 east-west / north-south 분리 설명을 먼저 읽어야 합니다.
• 에이전트 운영 관점에서는 GKE Agent Sandbox와 코드 실행 격리 문서를 함께 봐야 합니다.
• AWS 대안을 검토하는 팀은 EFA 문서의 Availability Zone, Huge Pages, VPC CNI 제약부터 확인해야 합니다.
• 학습/추론 생산성을 보려면 raw FLOPS보다 goodput과 MTTR, straggler 탐지 자동화를 함께 봐야 합니다.

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 도입 판단 기준은 우리 팀 에이전트가 코드를 실행하는가입니다.

• 사용자 요청 1건당 평균 모델 호출 수와 툴 실행 수를 계측했다
• 비신뢰 코드 실행 워크로드를 일반 앱 노드와 분리했다
• 추론 지연과 sandbox 지연을 별개 지표로 본다
• 에이전트 동시 실행 수와 타임아웃 기본값을 선언적으로 고정했다
• 벤더 성능 수치를 파일럿으로 재검증할 계획이 있다
• 장애 시 GPU 계층, 네트워크 계층, 샌드박스 계층 중 어디가 병목인지 10분 안에 판별할 수 있다

Definition of Done: 에이전트 파일럿에서 2주 연속으로 요청 완주율, sandbox 실패율, 추론 P95, 요청당 비용을 분리 측정하고, 장애 원인을 세 계층 중 하나로 즉시 분류할 수 있으면 도입 판단에 필요한 최소 운영 기준이 갖춰진 것입니다.

작성자 관점: 저는 멀티에이전트나 코드 실행형 제품을 운영하는 팀이라면 이 방향을 적극 추천합니다. 특히 GPU 사용률은 높은데 사용자가 느끼는 품질이 낮은 팀이라면, 문제는 모델이 아니라 패브릭과 실행 계층 섞임일 가능성이 큽니다. 반대로 단순 RAG나 단일 챗봇 단계라면 Virgo 같은 설계 철학은 참고만 하고, 지금은 관측성과 추론 게이트웨이부터 정리하는 편이 더 현실적입니다.

참고자료

• Google Cloud Blog - What’s next in Google AI infrastructure: Scaling for the agentic era (확인일: 2026-04-28)
• Google Cloud Blog - Introducing Virgo Network, Google’s scale-out AI data center fabric (확인일: 2026-04-28)
• Google Cloud Blog - What’s new with compute: Scaling core and agentic workloads (확인일: 2026-04-28)
• Google Cloud Docs - About GKE Agent Sandbox (확인일: 2026-04-28)
• Google Cloud Docs - Enable Agent Sandbox on GKE (확인일: 2026-04-28)
• AWS Docs - Run machine learning training on Amazon EKS with Elastic Fabric Adapter (확인일: 2026-04-28)