AI 인프라

Agent Compute Engine 및 확장된 에이전트 거버넌스 소개

Fri, 30 Oct 2026 04:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

블로그 작성자: 제품 관리 부문 VP Nirav Mehta, VP/GM Michael Bachman, 제품 관리 부문 VP Kevin Hutchins

Gemini를 전 세계 규모로 확장하는 과정에서, 자율 에이전트를 안전하게 실행하는 것은 근본적으로 인프라와 관련된 과제라는 것을 직접 배울 수 있었습니다. 단일 턴 프롬프팅에서 대화형 에이전트로 전환하려면 실행 및 제어 측면에서 새로운 패러다임이 필요합니다. 대규모 동시 에이전트 세션을 지원하기 위해 Google은 이러한 과제를 해결할 수 있도록 Gemini를 위한 새로운 컴퓨팅 및 거버넌스 솔루션을 설계했습니다.

오늘 AGNTCon + MCPCon에서 Google은 업무용 에이전트로서 이미 Gemini에서 활약하고 있는, 특수 설계된 Agent Compute Engine을 공개하여 고객에게 이러한 역량을 제공하려 합니다. 앞으로 몇 달 내에 프리뷰 버전이 제공될 예정이며, 하드웨어 격리 런타임 샌드박스 보안을 지원합니다. 또한 비즈니스를 위한 Gemini의 에이전트 거버넌스 기능을 확장하여 에이전트가 작동하는 위치에 관계없이 지원하고자 합니다. 이러한 기능이 한데 모여 사용자가 에이전트를 실행, 관리, 확장하는 데 필요한 제어 역량을 제공합니다.

Agent Compute Engine 심층 분석

Agent Compute Engine은 코드를 작성 및 실행하고, 도구를 실행하고, 브라우저를 구동하고, 엔터프라이즈 워크플로를 조정하고, 작업을 대규모로 빠르게 반복해야 하는 Google의 방대한 에이전트형 워크로드를 처리하기 위해 탄생했습니다. 기존의 컴퓨팅 프리미티브는 표준 워크로드에는 적합하지만, AI 에이전트의 고유하고 반복적인 특성에는 최적화되어 있지 않았습니다.

에이전트를 위해 특별히 설계된 Agent Compute Engine은 모든 Gemini 에이전트에 자체적인 고성능 보안 컴퓨터를 제공하여 Gemini의 동적이고 이탈률이 높은 세션을 지원합니다. Agent Compute Engine은 AI 에이전트의 고유한 수명 주기 패턴에 맞게 최적화되어 있으며, 곧 이 서비스를 사용하여 자체 커스텀 에이전트를 구동할 수 있게 됩니다. 주요 특징은 다음과 같습니다.

효율적인 속도: 에이전트는 시작, 일시중지, 재개를 반복하므로 규모에 맞는 속도를 제공하는 아키텍처가 필요하며, 이 모든 과정에서 높은 효율성이 필요합니다. Agent Compute Engine은 빠르게 부팅되는 microVM을 제공하므로 에이전트 루프나 평가 스윕 작업이 인프라를 기다릴 필요가 없습니다. 나아가 여러 에이전트로 Google 사용자를 지원하려면 물리적 머신을 최대한 활용할 수 있는 비용 효율적인 솔루션이 필요합니다. Agent Compute Engine은 Copy-On-Write(COW) 메모리 공유를 사용하여 단일 운영체제 템플릿에서 여러 에이전트를 실행하고, 빠른 체크포인트 및 복원을 통해 유휴 microVM을 일시중지함으로써 이러한 효율성을 달성합니다. 에이전트가 도구 호출 실행을 완료하고 에이전트 루프의 '사고' 단계에 진입하면, microVM은 자신이 유휴 상태임을 알리고 호스트는 이 microVM을 활성 상태에서 유휴 상태로 전환합니다. 다시 말해, 에이전트가 사람이나 외부 시스템을 기다리는 동안 실행 중인 microVM을 일시중지하고 스냅샷에서 빠르게 재개할 수 있습니다.
보안, 격리, 거버넌스 강화: 에이전트가 더 복잡한 작업을 수행하게 되면서, 샌드박스 내에서 신뢰할 수 없거나 적대적인 코드 실행이 발생할 위험이 항상 존재하게 되었습니다. Agent Compute Engine을 Google의 오프로드 인프라 처리 장치(IPU)인 Titanium과 함께 실행하면 신뢰할 수 없는 AI 에이전트에 대응하기 위해 하드웨어 단계부터 고안된 심층 방어를 제공할 수 있습니다. Agent Compute Engine은 자체 게스트 커널과 루트 액세스 권한이 있는 하드웨어 격리 Cloud Hypervisor 경계를 통해 강력한 격리를 제공합니다. (Agent Compute Engine의 microVM 아키텍처와 보안에 대해 자세히 알아보려면 기술 심층 분석을 읽어보세요.) 각 microVM은 단기 사용자 인증 정보를 사용하여 에이전트의 자체 ID를 실행합니다. 또한 모든 microVM은 자체적인 암호화 방식으로 확인된 ID를 가지며, 서비스 사용자 인증 정보는 microVM 외부의 이그레스에 삽입됩니다. Agent Gateway와 통합된 Agent Compute Engine은 포괄적인 모니터링 가능성, 정책, 보안 평가를 제공합니다.
지속성 및 엔터프라이즈 통합: 에이전트는 장기 실행되는 여러 세션에서 에이전트 데이터를 유지할 수 있어야 합니다. 이를 위해 각 Agent Compute Engine microVM은 자체 Hyperdisk를 갖추고 있어 실행 작업공간과 에이전트 컨텍스트를 유지할 수 있습니다. 이에 더해, 의미 있는 작업을 수행하려면 기업 데이터를 이동시키지 않고도 microVM이 기업 데이터를 사용할 수 있어야 합니다. Agent Compute Engine을 Google의 클라우드 및 ID 패브릭에 직접 통합함으로써, 엔터프라이즈 연결이 microVM 자체를 보호하는 것과 동일한 보안 및 ID 모델에 의해 제어되므로 통합된 ID 모델과 감사 가능성을 구현할 수 있습니다.

"Gemini 에이전트를 전 세계 규모로 확장하려면 빠르게 가동되고 극도로 효율적으로 작동하는 컴퓨팅이 필요합니다. Agent Compute Engine microVM은 전 세계 사용자에게 대화형 에이전트 샌드박스를 제공하는 데 필요한 응답성, 하드웨어 격리, 워크로드 밀도를 갖추고 있습니다." - Gautham Thambidorai, Gemini 부사장 겸 Google 펠로우

Agent Substrate를 사용한 GKE 기반 빌드

맞춤설정과 멀티 클라우드 이식성이 필요하거나 이미 Kubernetes를 표준으로 도입한 플랫폼팀을 대상으로 하는 Google Kubernetes Engine(GKE) 기반의 Agent Substrate는 Kubernetes 환경에서도 에이전트 중심 설계를 지원하는 오픈소스 실행 런타임입니다. Agent Substrate는 에이전트 실행을 머신 관리에서 완전히 분리하는 제로 트러스트 아키텍처를 기반으로 빌드되었습니다. 에이전트가 유휴 상태가 되면 Agent Substrate는 에이전트의 활성 메모리 스냅샷을 생성하고 머신을 풀로 반환한 다음, 에이전트가 다시 필요해지는 순간에 에이전트를 재개합니다. 오픈소스이자 Kubernetes 기반이므로 맞춤설정하고 확장하여 기존 워크로드와 함께 실행할 수 있습니다. Agent Substrate의 주요 특징은 다음과 같습니다.

고밀도: Agent Substrate는 모든 에이전트에 대해 완전한 커널 격리와 ID 기반 네트워크 보안을 유지하면서 기존 컴퓨팅에 비해 최대 10배 더 높은 컴퓨팅 밀도를 제공합니다.
1초 미만의 활성화: 200,000개의 에이전트를 실행하는 벤치마크 검증에서 Agent Substrate는 500ms 미만의 일시중지 및 재개 지연 시간으로 초당 500회의 활성화를 유지했습니다.
보안을 우선으로 하는 기본 설정: Agent Substrate는 에이전트를 위한 제로 트러스트라고 생각하면 됩니다. 각 샌드박스에는 microVM 또는 gVisor를 선택하여 사용할 수 있는 강력한 하드웨어 격리 기능이 내장되어 있습니다. 모든 에이전트는 암호화 방식으로 보호되는 자체 ID를 부여받으며, 세분화된 네트워크 정책을 적용하고 에이전트 자체의 접근 범위를 벗어난 사용자 인증 정보를 삽입하는 이그레스 프록시와 함께 사용됩니다. 앞으로 Agent Substrate 런타임 아키텍처를 확장하여 비즈니스 거버넌스 프레임워크를 위한 더 광범위한 Gemini와 통합할 예정입니다.
오픈소스 이식성: 모든 컴퓨팅 환경의 모든 Kubernetes 클러스터에서 실행되며 Claude Code, OpenClaw, Hermes를 비롯한 모든 에이전트 프레임워크 또는 하네스와 호환됩니다.
동적 스토리지: 1초 미만의 재개 지연 시간으로 Filestore 에이전트 볼륨과 통합되어 활성 컴퓨팅과 함께 확장되며, 멀티 에이전트 워크플로를 위한 단일 공유 작업공간을 제공합니다.

Nous Research 같은 선도적인 AI팀은 이미 이 안정적인 아키텍처를 사용하여 멀티 테넌트 에이전트를 기존 고객 인프라에 바로 배포하여 효율성을 실현하고 있습니다.

“Hermes Enterprise는 고객이 기존 인프라에 배포할 수 있도록 빌드되었으며, 에이전트별 격리와 확장 가능한 액세스 제어를 처리할 수 있습니다. Agent Substrate는 플랫폼 레이어에서 이 두 가지 작업을 모두 처리하는 동시에, 귀중한 컴퓨팅 리소스도 보존합니다. Agent Substrate를 직접 사용해 본 경험 덕분에, 에이전트 워크로드가 증가하더라도 아키텍처를 효율적으로 확장할 수 있다는 확신을 갖게 되었습니다.” - Hervé Bizira, Nous Research 최고 비즈니스 책임자

모든 에이전트를 위한 거버넌스 기능 확장

조직이 자율 에이전트를 격리된 파일럿에서 멀티 런타임 프로덕션 Fleet로 전환함에 따라, 기존 보안 프레임워크를 강화하고 발전시켜야 합니다. 고객은 세 가지 과제에 직면해 있습니다. 1) 에이전트, 도구, 모델, 기술, 그리고 데이터 전반에서 동적이고 비결정론적인 상호작용 경로를 보호하는 것, 2) 최소 권한 액세스 분산 런타임을 통해 보안 상황을 기본 거부 상태로 유지하는 것, 3) 비동기 에이전트 작업을 감사할 수 있도록 보장해야 하는 것입니다. 강력한 에이전트 거버넌스가 없으면 에이전트의 무분별한 확산으로 인해 섀도 AI, 데이터 무단 반출, 추적 및 감사가 어려운 에이전트 작업 등의 위험이 빠르게 발생합니다.

이러한 과제를 해결하기 위해 Google은 Gemini 플랫폼에 다음과 같은 강력한 에이전트 거버넌스 기능을 구축했습니다.

Agent Gateway: 항공 관제사처럼 클라이언트와 에이전트 간 트래픽, 에이전트와 외부 위치 간 트래픽을 관리합니다. 또한 민감한 정보 보호, 에이전트 공격 보호, 시맨틱 거버넌스, 자체 정책 가져오기 기능을 포함한 광범위한 거버넌스 및 보안 정책을 통합합니다.
Agent Registry: 승인된 모든 실행 중인 에이전트, 도구, MCP 서버, 스킬, 모델, 엔드포인트의 정보 소스 역할을 하는 중앙 저장소를 제공하며, 적용된 정책을 통해 런타임 액세스를 제어합니다.
에이전트 아이덴티티: 개방형 표준 기반의 SPIFFE를 사용하여 각 에이전트에 고유한 보안 ID를 할당하며, 인증, 액세스 제어, 감사를 위한 디지털 서명 역할을 합니다.
에이전트 모니터링 가능성: 에이전트형 시맨틱 규칙을 채택하는 OpenTelemetry(OTel) 규정 준수 원격 분석을 제공하여 Agent Gateway 전반에서 모든 모델 호출, 도구 호출, 에이전트 홉에 대한 표준화된 측정항목, 로그, 분산 트레이스를 내보냅니다.

다양한 환경에서 에이전트 Fleet이 지속적으로 급격하게 증가하고 있는 요즘, Google은 Google Cloud 런타임, 크로스 클라우드, 온프렘, 클라이언트 기기 전반에서 비즈니스 에이전트 거버넌스 기능을 지원하도록 Gemini의 범위를 확장하여 에이전트가 실행되는 모든 곳에서 에이전트를 관리하고 보호하고 있습니다. 여기에는 다음과 같은 기능이 포함됩니다.

광범위한 Google Cloud 런타임 지원: Agent Runtime, Cloud Run, Gemini 플랫폼의 Agent Sandbox, GKE, Agent Compute Engine(프리뷰) 전반에서 포괄적인 에이전트 거버넌스를 확장합니다.
일관된 크로스 클라우드 도달범위: 경량의 Envoy 프록시 기반 정책 적용 지점을 배포하여 멀티 클라우드 및 하이브리드 환경으로 거버넌스를 확장합니다(곧 프리뷰 버전 제공 예정).
엔드포인트의 로컬 에이전트에 대한 거버넌스: 관리 대상 기기에서 OS 수준 샌드박스 및 로컬 거버넌스 서비스를 통해 Claude Code 및 Antigravity CLI 같은 코딩 에이전트까지 거버넌스를 확장합니다(곧 프리뷰 버전 제공 예정).

이 외에도 세분화된 비용 관리, 지능형 모델 라우팅, 간소화된 맞춤설정 및 통합을 지원하는 Agent Gateway의 새로운 에이전트 거버넌스 기능이 공개됩니다. 이번 분기에 프리뷰 버전으로 제공되는 주요 기능은 다음과 같습니다.

세분화된 토큰 및 비용 거버넌스: 토큰 관리를 통해 에이전트와 모델 전반에서 토큰 소비를 제어할 수 있습니다. 이를 통해 비용을 할당하고, 예산 가드레일을 적용하고, 토큰 측정항목에 대한 단일 정보 소스를 제공할 수 있습니다.
적절한 모델로 요청 라우팅: 모델 라우팅 정책은 사용자 및 에이전트 요청을 적절한 모델로 라우팅하여 비용을 제어하고 성능을 개선합니다.
확장 가능한 정책: Service Extensions 바인딩을 통해 인라인 프로그래밍 가능성 및 확장성에 대한 간소화된 지원이 가능해집니다. Google 서비스, 고객의 맞춤형 함수, 파트너 서비스를 데이터 경로에 바로 긴밀하게 통합할 수 있습니다.
확장된 보안 파트너 생태계: 에이전트 아이덴티티 인증 관리자를 사용한 안전한 OAuth 지원과 더불어, 서드 파티 ID 공급업체인 Ping Identity, SailPoint, Saviynt를 통해 위임된 사용자 승인을 제공합니다. 통합 파트너의 전체 목록은 여기에서 확인할 수 있습니다.
간소화되고 안전한 에이전트-도구 연결: Cloud Run용 빠른 연결을 사용하면 에이전트가 도달해야 하는 대상을 선언할 수 있으며, ID 토큰 삽입을 포함하여 구성요소 간에 안전하고 인증된 연결을 설정할 수 있습니다.

"L’Oréal의 목표는 팀에 에이전트 AI를 제공하여 새로운 아이디어를 실현하고 뷰티의 미래를 만들어 나갈 수 있도록 지원하는 것입니다. AI 에이전트는 L’Oréal의 뷰티 테크 에이전트형 플랫폼을 통해 일상 업무에 자연스럽게 녹아들고 있습니다. Google Cloud의 에이전트 거버넌스는 Cloud Run과 같은 런타임 전반에서 ID, 정책, 모니터링 가능성을 통합해 주므로 회사의 포부를 자신 있게 확장할 수 있는 기반이 됩니다. 개발자는 더 빠르게 혁신할 수 있고, 엔지니어는 각 에이전트가 액세스할 수 있는 항목을 명확하게 제어할 수 있습니다.” - Alexandre Frizzo, L’Oreal AI 수석 엔지니어

복원력 있는 에이전트 인프라를 기반으로 빌드

에이전트 시대에는 인프라를 확장하는 방식에도 진화가 필요합니다. Google은 Agent Compute Engine 및 Agent Substrate의 고성능 실행과, 지금은 크로스 클라우드 영역까지 확장된 비즈니스용 Gemini의 에이전트 거버넌스 기능을 결합하여 안전하게 보호되는 고밀도 AI 에이전트를 위한 탄력적인 기반을 구축하고 있습니다.

Agent Compute Engine에 대해 자세히 알아보고 Agent Compute Engine에 대한 관심 여부를 보여주세요.
커뮤니티와 함께 공개적으로 빌드되는 Agent Substrate를 만들어 나가는 데 힘을 보태주세요. 지금 바로 오픈소스 저장소를 방문하여 GKE에서 Agent Substrate를 사용해 보세요.
에이전트 거버넌스에 대해 자세히 알아보고 관심 여부를 알려주세요.
AGNTCon+MCPCon에서 전문가와 이야기를 나누고 Google의 데모를 살펴보세요.

Google Cloud와 NVIDIA, 에이전트 시대에 맞춰 인프라를 확장하기 위한 공동 엔지니어링 협력 강화

Fri, 30 Oct 2026 04:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

기업이 지속적인 다단계 에이전트형 워크플로로 전환함에 따라 기존 인프라는 한계에 직면하고 있습니다. 하지만 성능만으로는 충분하지 않습니다. 에이전트 AI를 본격적으로 확장하려면 기업은 각 작업에 적합한 모델을 유연하게 실행할 수 있어야 합니다. 또한 민감한 지식 재산과 기본 인프라에 대한 검증 가능한 제어를 유지하는 데 필요한 데이터 주권과 운영 주권도 확보해야 합니다.

오늘 NVIDIA GTC Berlin 2026에서 Google Cloud는 이러한 기반을 제공하기 위해 스택 전반에 걸친 새로운 기술 발전을 발표합니다. 여기에는 병목 현상을 최소화하고, 생태계 선택권을 확대하며, 하드웨어 기반 보안을 통해 가장 민감한 워크로드를 보호하는 새로운 소버린 AI 및 컨피덴셜 컴퓨팅 기능을 도입하는 것이 포함됩니다.

에이전트 시대를 위한 아키텍처 설계

고객이 모델을 대규모로 학습, 서빙, 운영할 수 있도록 Google Cloud의 AI 하이퍼컴퓨터는 Google Cloud가 단일 시스템으로 공동 설계한 컴퓨팅, 스토리지, 네트워킹, 소프트웨어를 기반으로 빌드되었습니다. 오늘 Google Cloud는 NVIDIA와 협력하여 이 에이전트 네이티브 인프라의 새로운 업데이트를 발표합니다.

NVIDIA Vera Rubin 플랫폼 기반 A5X 인스턴스를 통한 가속화된 컴퓨팅: 이러한 베어메탈 GPU 가속 인스턴스는 최신 NVIDIA Vera Rubin NVL72 플랫폼을 탑재하여 대규모 환경에서도 높은 성능을 제공합니다. 다음 달에 정식 버전이 출시되면 새로운 현지 리전에서도 서비스를 제공하여 EMEA 지역의 데이터 상주 및 주권 요구사항을 지원할 수 있도록 인프라 규모를 확장할 예정입니다.
Virgo Network를 통한 수평 확장 A5X 네트워킹: Virgo Network는 메시 토폴로지를 통해 건물 내부 및 건물 간 비차단 수평 확장 패브릭을 지원합니다. 이 새로운 기능을 통해 엄청난 규모의 수평 확장이 가능해져 단일 사이트에서는 최대 80,000개의 Rubin GPU로, 멀티 사이트 배포에서는 최대 960,000개의 Rubin GPU로 클러스터를 확장할 수 있습니다.
Managed Lustre 및 NVIDIA GPUDirect Storage를 사용한 스토리지: Google Cloud Managed Lustre는 A5X 인스턴스에서 NVIDIA GPUDirect Storage를 지원할 예정입니다. 이를 통해 학습 및 추론 데이터가 CPU 및 시스템 메모리를 우회하고 병렬 파일 시스템에서 GPU 메모리로 직접 전송되는 RDMA 경로를 사용할 수 있습니다.
KV 캐싱을 통한 긴 컨텍스트 메모리: A5X 인스턴스는 긴 컨텍스트 및 멀티턴 에이전트형 워크로드를 위해 GPU 고대역폭 메모리(HBM)를 넘어 컨텍스트 메모리를 확장하도록 설계된 고급 KV 캐싱 기능도 지원합니다. 이 고속 캐싱 레이어는 스토리지 계층 전반에서 컨텍스트를 오프로드 및 재사용하여 중복 계산을 줄이고, 첫 토큰 생성 시간을 단축하며, 비용 대비 추론 처리량을 개선합니다.
Google Kubernetes Engine(GKE)의 A5X 인스턴스를 통한 워크로드 조정: GKE는 분산 AI 워크로드를 위한 다양한 기능을 제공합니다. 예를 들어 GKE 관리형 DRANET은 네트워크 인터페이스 카드를 일급 네이티브 Kubernetes 리소스로 만들어 RDMA 관리를 간소화하고, Kueue는 토폴로지 인식 스케줄링 및 리소스 관리를 통해 분산 워크로드의 성능을 향상합니다. 이러한 특성 덕분에 GKE와 A5X 인스턴스는 에이전트형 워크로드 조정을 위한 강력한 조합이 됩니다.

“에이전트 AI의 진정한 가치는 속도에만 있는 것이 아닙니다. 현대적인 제작 파이프라인의 마찰로부터 인간의 창의성을 해방하는 데 있습니다. NVIDIA Vera Rubin NVL72로 가속화된 Google Cloud의 A5X 인스턴스를 통해 WPP의 크리에이티브 및 프로덕션팀은 프레임 단위로 정확한 품질 검사를 수행하고 브랜드 애셋을 원활하게 조정하는 지능형 에이전트를 지휘할 수 있습니다. Google Cloud는 고객의 가장 야심 찬 창작 요구사항을 충족하는 데 필요한 안정성, 확장성, 주권 보안을 제공합니다.” - Stephan Pretorius, WPP 최고 기술 책임자

개방형 모델 및 생태계 혁신 확대

에이전트형 워크플로에서 단일 모델에만 의존하는 경우는 드뭅니다. 대신 작업을 가장 효율적으로 수행할 수 있는 모델로 라우팅합니다. 인프라는 로드맵을 제한하는 것이 아니라 선택의 폭을 넓혀 주어야 합니다. Google Cloud를 사용하면 멀티 클라우드, 하이브리드, 규제가 엄격한 환경에서 원하는 소프트웨어와 NVIDIA AI 인프라를 선택하여 인프라를 배포할 수 있습니다. 오늘 Google Cloud는 자유롭게 빌드하고 빠르게 적응할 수 있도록 지원하는 몇 가지 업데이트를 발표했습니다.

개방형 모델: Google Cloud는 Gemma, Mistral, NVIDIA Nemotron 등의 모델에 대한 지원을 Sovereign Cloud 포트폴리오에 추가하고 있습니다. 이를 통해 모델 가중치와 런타임을 완전히 제어하면서 개방형 가중치 모델을 실행하고 관리할 수 있으며, 종속을 방지하면서 고성능 가속을 유지할 수 있습니다.
Gemini에서 NVIDIA NeMo와 함께 NVIDIA Cosmos 3 및 NVIDIA Nemotron 3.5 SuperVL 제공: 이제 관리형 학습 클러스터를 사용하여 새로운 NVIDIA Nemotron 3.5 SuperVL 모델을 맞춤설정할 수 있습니다.MTC에 최적화된 학습 레시피를 사용하여 Google Cloud에서 NVIDIA NeMo RL 및 NVIDIA NeMo Gym을 활용한 Nemotron 사후 학습 작업을 빠르게 시작할 수 있습니다. NVIDIA Cosmos 3를 사용하면 로봇과 자율 주행 차량이 실제 환경에 배포되기 전에 시행착오를 거치며 성능을 개선할 수 있는 가상 세계를 생성하여 시뮬레이션에서 현실로 이어지는 워크플로를 지원할 수 있습니다.

소버린 AI 및 컨피덴셜 컴퓨팅으로 배포 보안 강화

에이전트가 자율적으로 수행하는 미션 크리티컬 작업이 늘어나면서 처리하는 데이터의 민감도도 점점 높아지고 있습니다. 이러한 고급 워크로드를 배포하는 조직에는 혁신을 저해하지 않는 하드웨어 기반 보호와 운영 제어가 필요합니다. 클라우드에서 모델을 학습시키는 동안 지식 재산을 보호하거나 완전히 에어 갭이 적용된 환경에서 미션 크리티컬 워크로드를 실행하는 경우 Google Cloud와 NVIDIA는 검증 가능한 보안과 로컬 관리 기능을 제공합니다.

오늘 Google Cloud는 온프레미스 환경을 위한 새로운 소버린 AI 기능과 함께 퍼블릭 클라우드를 위한 컨피덴셜 컴퓨팅의 개선 사항을 발표합니다.

Google Distributed Cloud를 통한 온프레미스 소버린 AI

인터넷에서 완전히 격리된 상태를 유지해야 하는 미션 크리티컬 워크로드의 경우 Google Distributed Cloud(GDC)는 관리형 클라우드 스택을 고객의 데이터 센터 또는 에지 시설에 직접 제공합니다. 소버린 AI 이니셔티브를 발전시키기 위해 Google Cloud는 GDC 에어 갭 적용 배포 환경 전반에 걸쳐 새로운 컴퓨팅 가속기, 멀티모달 모델, 턴키 검색 기능을 제공하고 있습니다.

GDC의 NVIDIA Blackwell Ultra GPU: 올해 초 발표된 프리뷰 버전에 이어 최신 NVIDIA HGX B300 시스템이 이제 GDC에서 정식 버전(GA)으로 제공됩니다. 이를 통해 업계 최고 수준의 컴퓨팅 밀도와 에너지 효율을 온프레미스에 제공하여 까다로운 로컬 추론 워크로드에 필요한 높은 처리량의 플랫폼 기반을 마련합니다.
GDC의 Gemini Flash 모델: NVIDIA HGX B300으로 가속화된 GDC의 Gemini 3.5 Flash를 통해 주권 모델 카탈로그를 확장하고 있습니다. 이제 조직은 에어 갭 경계 내에서 텍스트, 오디오, 동영상, 이미지를 아우르는 빠르고 처리량이 높은 멀티모달 추론을 실행할 수 있습니다.
GDC의 엔터프라이즈 검색 기능: 프리뷰 버전으로 제공되는 GDC 에어 갭 환경의 Gemini 기반 엔터프라이즈 검색 기능은 멀티모달 검색 증강 생성(RAG)을 기반으로 하는 즉시 사용 가능한 대화형 인터페이스를 제공합니다. 이러한 기능은 NVIDIA HGX B300을 사용하는 GDC 에어 갭 기반 Gemini를 통해 제공됩니다. 이제 분석가와 지식 노동자는 커스텀 엔지니어링 없이도 독점 문서, 미디어, 비정형 아카이브를 즉시 쿼리, 요약, 교차 검토할 수 있으며, 모든 색인 생성, 임베딩, 상호작용을 주권 보안 경계 내에서 엄격하게 유지할 수 있습니다.

에어 갭 적용 온프레미스 배포 외에도 NVIDIA AI 인프라에서 소버린 AI 워크로드를 실행할 수 있습니다. 이때 Google Cloud 데이터 경계를 사용하여 퍼블릭 클라우드에서 리전별 데이터 상주와 같은 제어를 적용하거나 Google Cloud 전용 환경을 사용하여 프랑스의 S3NS 또는 독일의 Thales와 같은 현지 독립 파트너가 운영하는 격리된 클라우드를 실행할 수 있습니다.

퍼블릭 클라우드의 컨피덴셜 컴퓨팅

엔터프라이즈 워크로드가 확장됨에 따라 학습이 진행되는 동안 민감도가 매우 높은 지식 재산을 보호하고, 실시간 추론 중에는 사용자 컨텍스트와 모델 IP를 보호하는 것이 안전한 AI 아키텍처를 유지하는 데 매우 중요합니다. 조직은 Google Cloud의 고급 보안 런타임과 NVIDIA 컨피덴셜 컴퓨팅을 결합하여 처리 속도를 저하시키지 않고도 검증되고 신뢰할 수 있는 실행 환경에 고성능 생성형 AI 모델을 배포할 수 있습니다.

컨피덴셜 컴퓨팅을 지원하는 G4 인스턴스 정식 버전 출시: NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU를 기반으로 하는 컨피덴셜 G4 인스턴스를 통해 개인 정보 보호 AI에 대한 접근성을 확대하고 있습니다. NVIDIA 컨피덴셜 컴퓨팅을 지원하는 G4 컨피덴셜 GPU는 성능 저하 없이 업그레이드된 보안을 제공합니다.
컨피덴셜 컴퓨팅은 현재 NVIDIA HGX B200 및 Intel TDX 기반 A4 인스턴스에서 일부 고객에게 제공되고 있습니다.
Google Cloud는 프런티어 모델 AI 서빙을 위한 단일 테넌트 베어메탈 성능과 격리가 중요하다는 점을 고려하여 컨피덴셜 베어메탈을 도입합니다. 이러한 혁신은 NVIDIA Confidential Bare Metal을 사용하는 A4X Max 인스턴스(NVIDIA GB300 NVL72 기반)로 이어집니다. 암호화된 DDR 및 NVLink 상호 연결을 통해 하드웨어 기반 보안 부팅 및 증명을 확장함으로써 베어메탈 AI 워크로드는 이러한 신뢰할 수 있는 실행 경계를 활용하여 추론 및 학습 중에 사용자 프롬프트와 모델을 보호합니다.

Google Cloud의 이점

Google Cloud는 NVIDIA와의 공동 엔지니어링 협업을 통해 NVIDIA의 풀 스택 가속 컴퓨팅 플랫폼을 AI 하이퍼컴퓨터에 직접 통합합니다. 이를 통해 모델을 대규모로 학습, 서빙, 운영하는 데 필요한 에이전트 네이티브 인프라를 확보할 수 있습니다. 오늘 발표한 새로운 기능은 NVIDIA Vera Rubin 플랫폼과 높은 처리량의 네트워킹을 개방형 모델에 대한 확장된 지원과 결합하여 이러한 통합 기반을 제공합니다.

또한 데이터에 대한 검증 가능한 제어 기능을 제공합니다. NVIDIA 인프라 전반에 걸친 새로운 소버린 AI 배포와 컨피덴셜 컴퓨팅을 통해 하드웨어 기반 보안과 로컬 데이터 레지던시를 사용하여 가장 민감한 워크로드를 보호할 수 있습니다.

Google Cloud는 하드웨어와 소프트웨어를 하나의 시스템으로 함께 설계하므로 고객은 코드를 다시 작성하지 않고도 다양한 아키텍처에서 모델을 실행할 수 있습니다. 따라서 컴퓨팅 주기가 워크로드에 집중되므로 AI 제품을 더 빠르게 출시할 수 있습니다.

이러한 새로운 기능을 시작하려면 Google Cloud 영업 담당자에게 문의하세요.

ZenteiQ, llm-d 기반 GKE Inference Gateway로 배치 추론을 4배 확장

Wed, 28 Oct 2026 19:00:00 +0000

오늘은 Indian Institute of Science(IISc)에서 분사한 인공지능 스타트업인 ZenteiQ의 이야기를 들어보겠습니다. ZenteiQ는 IndiaAI Mission의 선정 기업으로 주권 과학용 파운데이션 모델을 처음부터 빌드하는 것을 목표로 하고 있습니다. 물리 법칙, 지배 방정식, 수치 솔버를 이해하는 모델을 사전 학습시키기 위해 ZenteiQ는 여러 모델 제품군에서 실행되고 검증된 데이터 세트를 학습 실행에 제공하는 대규모 합성 데이터 배치 생성 파이프라인을 설계하고 빌드했습니다.Google Kubernetes Engine(GKE)과 GKE Inference Gateway를 통해 ZenteiQ는 파이프라인 내에 추론 라우팅 레이어를 제공하여 집계 추론 처리량을 4.07배 확장하고 가속기 1,000개당 일일 토큰 생성량을 14억 7천만 개에서 59억 7천만 개로 늘릴 수 있었습니다. - Fisayo Feyisetan, Google Cloud 제품 관리자

주로 웹 텍스트와 코드를 학습하는 범용 언어 모델과 달리, 과학용 파운데이션 모델은 열역학, 전산 유체 역학, 전자기학과 같은 분야 전반에서 복잡한 물리 시스템, 수학적 지배 방정식, 수치 솔버를 이해해야 합니다. ZenteiQ는 시뮬레이션 결과를 해석하고, 방정식 공식을 평가하고, 물리 법칙을 따르는 단계별 수학적 유도 과정을 수행하는 주권 과학용 파운데이션 모델을 처음부터 빌드하고 있습니다.

대규모 지배 방정식 데이터 세트로 모델을 사전 학습시키려면 수천억 개의 추론 토큰이 필요합니다. 선별된 과학 문헌 및 시뮬레이션 데이터 세트와 더불어, ZenteiQ는 독립적으로 설계하고 구현한 합성 데이터 배치 생성 파이프라인을 사용하여 후보 유도 과정과 솔버 검증 문제를 생성, 평가, 필터링한 후 MaxText 사전 학습 작업에 입력합니다.

ZenteiQ는 고정된 컴퓨팅 할당량으로 운영되기 때문에 가속기가 학습 데이터를 생성하고 검증하는 데 소비하는 시간은 사전 학습에서 차감됩니다. 데이터 생성이 늦어지면 사전 학습용으로 할당된 멀티 호스트 가속기 클러스터가 데이터 세트를 기다리느라 아무런 작업도 하지 못하는 유휴 상태가 됩니다.

데이터 생성으로 인해 사전 학습이 지연되는 문제

데이터 생성 속도를 극대화하기 위해, 당사의 파이프라인은 워커 포드에서 진행되는 프롬프트 준비 작업과 다중 노드 가속기 풀 전반의 vLLM 모델 서빙을 분리하여 운영합니다. 각 배치는 4가지 단계를 거칩니다. 먼저 과학적 시드 개념을 프롬프트 배치로 확장하고, 생성기 모델을 통해 후보 추론 트레이스를 생성합니다. 그다음 평가자 모델을 사용하여 응답에 점수를 매기고, 별도의 모델 제품군을 통해 가드레일 검사를 실행한 뒤 검증된 데이터 세트를 패키징하여 사전 학습에 투입합니다.

처음에는 추론 엔드포인트 전반에 표준 ClusterIP 라운드 로빈 부하 분산을 사용하여 Kubernetes에서 이러한 모델 풀을 실행했습니다. 90억 및 350억 파라미터 모델 일정에 맞게 파이프라인을 확장하면서 두 가지 라우팅 병목 현상이 발생해 데이터 세트 생성 속도가 느려지기 시작했습니다.

불균일한 엔진 큐: 업스트림 워커 포드는 시드 개념을 복잡성과 응답 길이가 매우 다양한 프롬프트로 확장합니다. 표준 라운드 로빈 부하 분산 방식은 vLLM 엔진 큐의 상태를 파악할 수 없었기 때문에, 인접 노드에 여유 용량이 있는데도 이미 긴 추론 트레이스를 처리하느라 바쁜 서빙 포드에 계속해서 새로운 요청을 보내는 문제가 있었습니다.
중복 프리픽스 계산: 생성 배치 내의 프롬프트는 지시 컨텍스트와 작업 사양의 약 70%~80%를 공유합니다. 라운드 로빈 라우팅은 동일한 요청 사항을 여러 서빙 인스턴스에 분산시켰고, 이로 인해 각 포드는 가속기 메모리의 웜 캐시를 재사용하는 대신 동일한 공유 프롬프트 프리픽스를 처음부터 다시 계산해야 했습니다.

불균형한 큐와 중복된 프리필 작업이 겹치면서, 생성 처리량이 단일 실행 내에서 최대 절반까지 변동되어 데이터 세트 생성이 지연되고 예정된 사전 학습 실행의 시작이 지연되었습니다. 연구원들이 커스텀 추론 스케줄러를 직접 빌드하고 관리하느라 모델 개발에 소홀해지는 일 없이 실시간 vLLM 큐 깊이와 프롬프트 캐시를 파악할 수 있는 라우팅 기능이 필요했습니다.

llm-d 기반의 GKE Inference Gateway를 활용한 빌드 사례

이미 GKE에서 데이터 준비 및 MaxText 사전 학습 작업을 실행하고 있으므로 팀에서 동일한 Kubernetes 플랫폼에서 데이터 생성과 모델 학습을 관리할 수 있습니다. 기본적인 과학적 방법론이나 파이프라인 설계를 변경하지 않고도 라우팅 병목 현상을 해결할 수 있다는 Google Cloud의 권장사항에 따라, vLLM 가속기 풀 앞에 오픈소스 llm-d 분산 추론 프레임워크를 기반으로 하는 GKE Inference Gateway를 배포했습니다.

파이프라인에서 작업자 포드는 Cloud Storage에서 과학 시드 문서와 도메인 분류를 가져와 여러 단계의 프롬프트 배치로 확장합니다. 이러한 배치는 모든 모델 제품군과 서빙 노드 전반의 트래픽을 관리하는 단일 GKE Inference Gateway 배포를 통해 처리됩니다.

모델 등급별로 라우팅을 분리하여 관리하는 대신, 동일한 게이트웨이를 통해 각 모델 풀 전반의 생성 요청, 평가 쿼리, 가드레일 검사를 통합적으로 라우팅합니다. 후보 대답이 평가 및 가드레일 검사를 통과하면 작업자 포드가 확인된 데이터 세트를 중복 삭제하고 패키징하여 GKE의 다운스트림 MaxText 사전 학습 작업에서 직접 사용할 수 있도록 합니다.

GKE Inference Gateway는 검증된 데이터 세트가 MaxText 사전 학습에 입력되기 전에 vLLM을 실행하는 멀티 노드 가속기 풀에서 배치 생성, 평가, 가드레일 요청을 라우팅합니다.

라운드 로빈에서 부하 및 캐시 인식 라우팅으로 전환

GKE Inference Gateway와 llm-d를 사용하면 정적 라운드 로빈 순환 대신 vLLM 인스턴스의 실시간 서빙 신호를 사용하여 라우팅 결정을 내립니다. GKE Inference Gateway는 vLLM 엔드포인트 전반에서 실시간 큐 깊이와 키-값(KV) 캐시 사용률을 지속적으로 모니터링합니다. 서빙 노드가 긴 수식 유도 과정을 디코딩하느라 바쁠 때 게이트웨이는 수신 요청을 여유 용량이 있는 노드로 라우팅하므로, 인접 노드가 유휴 상태인데도 바쁜 작업자 노드에 과중한 프롬프트가 더 이상 쌓이지 않습니다.

동시에 게이트웨이는 일치하는 과학적 요청 사항이 포함된 요청을 해당 프리픽스의 KV 캐시가 이미 가속기 메모리에 준비되어 있는 서빙 노드로 라우팅합니다. 각 프롬프트의 70~80%는 공유된 지시 컨텍스트인 반면, 생성된 추론 경로는 요청마다 다르기 때문에 프리픽스 캐시 지역성과 실시간 큐 분산을 결합하면 포드가 단일 복제본에 과부하를 주지 않고 반복적인 프리필 작업을 건너뛸 수 있습니다.

처리량 향상 및 예측 가능한 학습 실행

llm-d 기반 GKE Inference Gateway를 도입하면서 데이터 생성 파이프라인의 속도와 예측 가능성이 혁신적으로 개선되었습니다. 프로덕션 클러스터 전반에서 지능형 라우팅을 통해 다음과 같은 성과를 거두었습니다.

Fleet 처리량 4배 향상: 가속기 1,000개당 합산 처리량이 초당 16,964개에서 69,114개 토큰으로 급증하여 일일 토큰 생성량이 14억 7천만 개에서 약 60억 개로 늘어났습니다.
개별 모델 풀에서 3.5~5.5배의 성능 향상: 실시간 큐 분산으로 각 실행 전반에서 서빙 노드의 부하를 균등하게 유지하여 긴 추론 유도로 인한 실행 중 속도 저하를 방지했습니다.
프리픽스 캐시 적중률 14% 포인트 향상 일치하는 과학적 요청 사항이 있는 프롬프트를 웜 캐시로 라우팅하여 각 요청이 개별 유도 과정으로 분기되기 전에 발생하는 중복 프리필 작업을 방지했습니다.

연구 및 인프라 팀에게 가장 중요한 성과는 일정의 예측 가능성을 확보한 것이었습니다. 일일 출력량이 4배로 늘어남에 따라 검증된 데이터 세트를 제때 준비할 수 있게 되었고, 그 결과 데이터 생성을 기다릴 필요 없이 멀티 호스트 사전 학습 실행을 예정된 일정대로 시작할 수 있었습니다.

ZenteiQ의 물리적 AI의 다음 단계

과학용 파운데이션 모델을 90억 개에서 350억 개 이상의 파라미터로 확장함에 따라, 사후 학습 강화 학습(RL)과 자동화된 수치 솔버 평가 루프에 동일한 GKE Inference Gateway 및 llm-d 라우팅 설정을 사용할 계획입니다. 이러한 멀티턴 출시의 각 턴은 이전 턴의 컨텍스트를 기반으로 하므로 실시간 큐 분산과 웜 프리픽스 캐시에 더 많이 의존합니다.

자체 워크로드에서 이러한 기능을 사용해 보려면 GKE Inference Gateway 문서를 살펴보고 오픈소스 llm-d 프로젝트를 확인해 보세요. Gemini 플랫폼팀이 GKE Inference Gateway를 통해 지연 시간을 35% 단축한 방법도 확인해 보세요.

llm-d 1.0 발표: Google Cloud TPU 및 GPU의 에이전트를 위한 개방형 분산 추론

Wed, 28 Oct 2026 13:00:00 +0000

캐시 인식 라우팅, 멀티 테넌트 트래픽 제어, 계층형 KV 캐시, 고가용성을 갖추어 Google Cloud에서 프로덕션에 즉시 사용 가능한 개방형 Kubernetes 네이티브 서빙 스택

오늘 PyTorch 컨퍼런스에서 Google은 분산형 LLM 추론을 위한 오픈소스 Kubernetes 네이티브 스택인 llm-d 1.0을 발표했습니다. Google이 Red Hat, IBM 등과 공동으로 설립한 Cloud Native Computing Foundation(CNCF) 샌드박스 프로젝트에는 25개 이상의 조직에서 500명이 넘는 인원이 참여했습니다. 이 프로젝트에서는 vLLM과 SGLang이 모델을 서빙하는 PyTorch와 분산 시스템이 프로덕션에서 실행되고 확장되는 Kubernetes라는 중요한 두 커뮤니티를 하나로 통합합니다.

llm-d 1.0은 에이전트가 추론의 본질을 바꾸고 있는 시점에 출시되었습니다. 1년 전만 해도 대부분의 추론 트래픽은 프롬프트 하나를 입력하면 대답 하나를 출력하는 채팅이었습니다. 오늘날 워크로드는 여러 도구로 분산되고, 긴 프리픽스를 공유하며, 갑자기 급증하는 다단계 에이전트 및 강화 학습(RL) 롤아웃으로 전환되고 있습니다. 단일 머신에서 또는 일반적인 라운드 로빈 부하 분산기 뒤에서 이를 서빙하면 금방 서비스가 중단되고 맙니다. 복제본은 동일한 프롬프트를 다시 계산하고, 가속기 메모리는 중복 상태로 가득 차며, 갑자기 급증한 에이전트 루프 하나가 대화형 사용자의 서비스를 지연시킬 수 있습니다.

llm-d는 모델 서버 클러스터를 조정된 서빙 풀로 전환하여 자체 모델을 서빙하는 팀에서 이러한 문제를 해결하도록 도와줍니다. PyTorch Conference 기조연설에서 Google은 GKE의 Agent Substrate에서 1,000개의 샌드박스 처리된 에이전트가 vLLM, SGLang, Google Cloud TPU 및 GPU가 혼합된 Fleet 전반의 단일 llm-d 엔드포인트에 접속하는 과정을 시연했습니다. 아래 3단계에 걸쳐 트래픽이 확장됨에 따라 캐시 인식 라우팅과 계층형 KV 캐시를 통해 각 에이전트의 단계가 컨텍스트를 가진 복제본에서 계속 처리되도록 했고, 흐름 제어로 급증한 에이전트 루프를 큐에 추가하여 대화형 요청의 속도를 빠르게 유지했습니다.

그림 1: 라운드 로빈 부하 분산에서 캐시 인식 라우팅, 계층형 KV 캐시, llm-d 1.0의 우선순위 흐름 제어로 진화한 분산 추론

1.0에서 제공하는 기능

llm-d는 이미 Google Cloud TPU 및 GPU 전반에 걸쳐 프리픽스 및 부하 인식 라우팅, KV 캐시 오프로드, 사전 입력/디코딩 분리, 광범위한 전문가 병렬 처리, 일괄 추론을 제공하고 있습니다. 이러한 기능으로 얻는 이점은 다음과 같습니다.

멀티 테넌트 서비스 품질. llm-d 흐름 제어를 통한 우선순위 및 공정성 인식 라우팅 덕분에 지연 시간에 민감한 요청과 급증한 에이전트 워크로드가 리소스 고갈 없이 Fleet을 공유하여 SLO를 충족할 수 있습니다.
안정적인 기반. 여러 클라우드 및 가속기 유형에서 검증된 v1 API와 강화된 요청 경로가 지원됩니다.
더욱 안전한 업그레이드. 라우터 고가용성 및 다운타임 없는 업데이트가 지원될 뿐만 아니라 DisaggregatedSet를 통해 컨텍스트 손실이나 활성 세션 중단 없이 사전 입력/디코딩 인식 순차적 업데이트를 조정합니다.
에이전트 인식 서빙. 세션 인식 라우팅, 턴 우선순위 스케줄링, 네이티브 Responses API 상태를 통해 에이전트가 턴 전반에서 컨텍스트를 재사용할 수 있습니다.
확장된 TPU 통합. TorchTPU 협력적 타임 슬라이싱을 이용한 네이티브 PyTorch 모델 서빙으로 Google Cloud TPU Fleet 전반의 처리량과 사용률을 높입니다.

이 구성요소는 자체 맞춤 프로덕션 환경으로 구성할 수 있도록 설계되었습니다. 엔진, 모델, 클러스터를 유지한 채 필요한 서빙 구성요소와 구성만 적용하면 됩니다.

llm-d 내부 작동 방식

Google 엔지니어들은 아래 영역 전반에서 llm-d 커뮤니티와 협력하여 업스트림 Kubernetes 기본 요소, PyTorch 서빙 엔진, 가속기 인식 스케줄링을 구성 가능한 스택으로 통합했습니다.

그림 2: Google Kubernetes Engine 및 Google TPU의 멀티 노드 llm-d 조정 및 단일 노드 TorchTPU 모델 엔진

하나의 엔드포인트에서 다양한 가속기 지원

에이전트 Fleet은 하나의 워크로드로 정의할 수 없습니다. 대화형 턴에는 짧은 지연 시간이 필요하고, 백그라운드 루프와 강화 학습(RL) 롤아웃에는 높은 처리량이 요구되며, 수요는 분 단위로 변동합니다. llm-d는 전체 Fleet 전면에 하나의 라우터, 하나의 KV 캐시 색인, 하나의 흐름 제어 정책을 두고 가속기 풀을 단일 엔드포인트 뒤에 배치합니다. 에이전트는 하나의 API를 호출하며, 라우터가 각 단계의 복제본을 선택하고 이미 컨텍스트를 보유한 복제본으로 세션 컨텍스트를 유지합니다. 에이전트를 재작성하지 않고 플랫폼을 변경하는 것만으로 용량을 추가하고, 여러 세대의 가속기를 혼용하고, 모델을 다른 풀로 이동할 수 있습니다. TorchTPU는 이러한 Fleet에 Google Cloud TPU를 도입하여 모델 재작성 없이 업스트림 vLLM 및 SGLang 내에서 기본적으로 PyTorch 모델을 실행합니다. 자세한 내용은 Google Kubernetes Engine(GKE) TPU의 llm-d 가이드를 참고하세요.

컨텍스트를 기억하는 라우팅

llm-d 라우터는 Google에서 추론 최적화 라우팅을 위해 출시한 Kubernetes 프로젝트인 Gateway API Inference를 기반으로 합니다. GKE에서 GKE Inference Gateway는 llm-d 라우터를 관리형 서비스로 실행하여 설치 및 관리를 간소화하고 리전 간 라우팅을 확장합니다. 이 라우터는 캐시된 각 프리픽스를 보유한 복제본을 추적하고, 복제본을 선택할 때 부하와 예상 지연 시간을 고려합니다. 가속기 메모리가 가득 차면 llm-d는 이를 삭제하는 대신 vLLM의 OffloadingConnector, Mooncake 또는 SGLang의 HiCache를 사용하여 KV 캐시를 호스트 메모리로 옮긴 후 SSD 또는 Google Cloud Managed Lustre로 이동시킵니다. 이 설정은 TPU와 GPU가 혼합된 Fleet에서 긴 컨텍스트의 멀티턴 대화 부하가 대규모로 발생할 때 프리픽스 제거 폭풍을 방지하는 데 도움이 됩니다.

Ironwood TPU(TPU 7x)에서 에이전트형 코딩 워크로드를 실행할 때 프리픽스 인식 라우팅과 호스트 메모리 오프로드를 함께 사용하면 일반 Kubernetes 서비스에 비해 첫 번째 토큰까지의 시간(TTFT) 중앙값이 85% 넘게 단축되고 총 처리량이 2.4배 증가했습니다(출처, 2026년 10월 기준).

안전한 업그레이드를 위한 분리

사전 입력은 컴퓨팅 집약적이고 디코딩은 메모리 제한이 있기 때문에 동일한 복제본에서 두 작업을 모두 실행하면 서로 대기하는 상황이 발생합니다. llm-d는 사전 입력, 디코딩, 멀티모달 인코딩을 별도의 풀로 실행하며, 광범위한 전문가 병렬 처리를 통해 대규모 전문가 혼합 모델을 여러 노드에 분산합니다. 1.0에서는 Google이 최초로 개발한 멀티 호스트 추론용 Kubernetes API인 LeaderWorkerSet를 기반으로 빌드된 DisaggregatedSet가 이러한 풀을 하나의 단위로 관리합니다. 순차적 업데이트에서 사전 입력과 디코딩이 일치 버전으로 함께 전환되며 각 단계는 독립적으로 확장됩니다. 자세한 내용은 분리형 서빙 가이드를 참고하세요.

실시간 추론과 함께 실행되는 비동기 추론

지연 시간에 민감하지 않은 트래픽을 위해 llm-d 1.0에서는 Google Cloud Pub/Sub 또는 Redis와 같은 큐에서 요청을 가져와 실시간 트래픽과 함께 라우팅해주는 llm-d-async-processor를 도입합니다. 이 프로세서는 큐 및 풀-디스패치 게이트를 사용하여 가용 용량을 확인하고 엄격한 우선순위 레인과 할당량을 적용합니다. 덕분에 백그라운드 작업이 대화형 사용자의 리소스를 고갈시키지 않으면서 여유 용량 내에서 실행됩니다.

타임 슬라이싱을 통해 유휴 RL 용량 활용

RL 학습 중에는 롤아웃 생성 또는 가중치 업데이트가 진행될 때 가속기가 전체 시간의 40%~60% 동안 유휴 상태로 있는 경우가 많습니다. llm-d는 Google Cloud TPU 및 GPU 타임 슬라이싱을 지원하여 이러한 유휴 주기에 비동기 추론을 인터리브 처리하여 최대 40%(기준)인 총 가속기 가동 주기를 70% 이상으로 향상시킵니다(출처).

신뢰할 수 있는 벤치마크

라우터, KV 캐시 계층, 사전 입력/디코딩 풀 전반에서 분산 추론 스택을 조정하려면 현실적인 멀티턴 부하 환경에서 반복 가능한 측정이 필요합니다. Prism은 llm-d에서 검증한 경로 전반의 공개 벤치마크를 탐색할 수 있는 llm-d의 오픈소스 분석 대시보드로, 표준화된 llm-d-benchmark 레시피와 inference-perf 워크로드를 기반으로 작동합니다. 수치 뒤에 숨겨진 정확한 구성을 검사하거나 자체 클러스터의 실행 결과를 업로드하여 처리량, 지연 시간, 비용 곡선을 나란히 비교할 수 있습니다.

Google Cloud에서 llm-d 1.0 실행

llm-d는 Gateway API, LeaderWorkerSet, 동적 리소스 할당, Prometheus, OpenTelemetry 등 이미 많이 실행되고 있는 Kubernetes 구성요소를 기반으로 빌드됩니다. Google Cloud에서 llm-d를 실행하면 다음과 같은 요소를 관리형 인프라와 함께 통합할 수 있습니다.

GKE Inference Gateway는 게이트웨이 모드에서 작동하는 llm-d 라우터로, L7 프록시 및 부하 분산을 처리하고 요청마다 llm-d 엔드포인트 선택기를 호출하는 관리형 GKE 게이트웨이입니다. 설치 및 관리를 간소화하므로 프록시를 직접 실행할 필요가 없습니다. 무엇보다도 GKE Inference Gateway를 사용하면 전역 장애 조치와 Model Armor 안전 확인을 통해 클러스터와 리전 전반에서 llm-d를 확장할 수 있습니다.
추론 신호 기반 자동 확장. KEDA와 수평형 포드 자동 확장 처리(HPA)는 큐 깊이, 포화도, 예측 지연 시간을 기준으로 풀을 확장하고, Kueue는 공유 가속기에 모델별 할당량을 적용합니다.
혼합 가속기 노드 풀. Google Cloud TPU 및 GPU 풀은 동일한 llm-d 엔드포인트 뒤에서 실행되며 검증된 Helm 차트를 사용하여 배포됩니다.
레이어 전반의 KV 캐시 오프로드. Google Cloud Managed Lustre는 로컬 TPU 및 GPU HBM과 호스트 CPU RAM 아래에 공유 원격 계층을 제공하므로 긴 컨텍스트 워크로드가 가속기 메모리를 소진하지 않고 실행됩니다.

프로덕션 환경에서의 성과

이 GKE llm-d 스택은 프로덕션 트래픽을 전달하며 Fleet 규모의 테스트를 마쳤습니다.

Gemini 플랫폼(이전 명칭: Vertex AI)은 GKE Inference Gateway를 통해 프로덕션 트래픽을 처리하여 프리픽스 캐시 적중률을 35%에서 70%로 두 배 향상시키고, 코딩 에이전트의 TTFT를 35% 넘게 단축하며, 급증하는 채팅 트래픽에서 P95 TTFT를 50% 이상 줄입니다(출처).
미국과 유럽에서 전문가 혼합 모델을 서빙하는 17,000개 노드 규모의 멀티 리전 GKE 배포를 대상으로 한 공개 벤치마크에서 멀티 클러스터 GKE Inference Gateway와 llm-d 라우터는 3개 클러스터에서 99.9%의 성공률과 1% 미만의 라우팅 오버헤드를 유지하며 처리량을 2.9배 확장시켰습니다(출처).
700억 개의 파라미터 모델을 서빙하는 A3 Mega 클러스터에서 진행된 공개 벤치마크에서, 호스트 CPU RAM 외에도 Google Cloud Managed Lustre에 대한 멀티 커넥터 KV 캐시 오프로드를 사용하는 llm-d는 CPU RAM 오프로드만 사용하는 경우에 비해 TTFT를 약 40% 개선하고 토큰 50,000개 규모의 프롬프트에 응답하는 엔드 투 엔드 지연 시간을 30% 단축하는 동시에 GPU-시간 요구사항을 거의 60%나 줄였습니다(출처).

Google Cloud에서 llm-d를 실행하는 조직은 캐시 적중률을 높이기 위한 프리픽스 인식 라우팅, 기존 서비스 메시와 호환되는 개방형 인터페이스, 트래픽 급증 시 우선순위 등급의 지연 시간을 유지하기 위한 흐름 제어 등 다양한 방식으로 이러한 기능을 활용하고 있습니다.

"Snap은 대규모 고성능 추론을 촉진하기 위해 llm-d를 프로덕션 AI 인프라에 통합하고 있습니다. 프리픽스 캐시 인식 라우팅을 사용한 결과 최대 75~80%에 달하는 프리픽스 캐시 적중률을 얻었습니다. llm-d의 오픈소스 특성 덕분에 Envoy 기반 서비스 메시와 원활하게 통합할 수 있었습니다." - Vinay Kola, Snap Inc. 소프트웨어 엔지니어링 부문 선임 관리자

"ZenteiQ에서는 llm-d 기반의 GKE Inference Gateway를 사용하여 자체 주권 과학용 파운데이션 모델을 위한 합성 데이터 생성을 가속화하고 있습니다. 부하 인식 및 프리픽스 캐시 인식 라우팅을 활용하여 총 추론 처리량을 4배 이상 높였으며, 일일 생성 토큰 용량을 TPU v6e 가속기 1,000개당 14억 7천만 개에서 59억 7천만 개로 늘렸습니다. GKE와 통합된 llm-d의 오픈소스 기반 덕분에 커스텀 추론 스케줄러를 개발하고 유지보수할 필요 없이 대규모의 여러 모델 제품군을 효율적으로 서빙할 수 있게 되었습니다.” - Sashikumaar Ganesan 교수, Zenteiq.ai 설립자

“대화형 애플리케이션과 대용량 API 전반에서 프런티어 모델을 서빙한다는 것은 갑자기 몰리는 워크로드로 인해 우선순위 고객의 지연 시간이 저하되지 않도록 하면서 급증하는 트래픽을 처리해야 한다는 것을 의미합니다. llm-d의 프리픽스 캐시 인식 라우팅, 흐름 제어, 분리형 서빙 지원을 사용하면 상용 등급 전반에 엄격한 우선순위 대역을 적용하고, 풀이 포화 상태가 되었을 때 우선순위가 낮은 요청을 자동으로 보류하거나 차단하여 유료 트래픽이 지연 시간 SLO를 충족하도록 할 수 있습니다. Mistral은 오픈소스 소프트웨어를 적극 지원하며, 앞으로도 llm-d 및 DisaggregatedSet 프로젝트에 계속 참여할 것입니다.” - Mathis Felardos, Lucas Fernandes-Martins, Nikhil Thomas, Mistral, 추론 엔지니어 겸 llm-d 참여자

자체 모델을 서빙하는 여러 팀에서 프로덕션에 필요한 캐시 인식 라우팅, 트래픽 제어, 업그레이드 제어 기능을 포함하고, 분해하여 자체 인프라에 맞게 조정할 수 있는 개방형 스택을 요청해 왔습니다. llm-d 1.0은 이러한 니즈를 충족함은 물론 공동 개발을 위한 커뮤니티도 제공합니다.

시작하기

PyTorch Conference가 진행되는 동안 Google Cloud 부스에서 TPU 기반의 llm-d에 대한 전체 데모를 확인하세요.
검증된 Helm 차트를 사용하여 GKE에 llm-d 1.0을 배포하세요. GKE의 llm-d 문서를 참고하세요.
먼저 기존 vLLM 배포 앞에 프리픽스 인식 라우팅을 적용한 다음 흐름 제어, KV 캐시 오프로드(SGlang, vLLM), 분리를 추가하세요.
Prism에서 결과를 비교하고 GitHub를 통해 개발에 참여하세요.

오픈소스로 제공되는 TorchTPU: TPU에서 네이티브 PyTorch 실행

Tue, 27 Oct 2026 19:00:00 +0000

오늘 PyTorch Conference 2026에서는 PyTorch를 Google Cloud 또는 자체 인프라에서 효과적으로 실행할 수 있도록 설계된 여러 신제품과 통합 소식이 발표되었습니다. 특히 Google TPU용 네이티브 PyTorch 스택인 TorchTPU가 이제 GitHub에서 오픈소스로 제공됩니다. TorchTPU를 통해 TPU도 GPU 및 CPU처럼 PyTorch에서 네이티브 옵션으로 제공됩니다. 이제 vLLM, SGLang, llm-d, TorchTitan, Ray, TorchRec, Hugging Face, LiteRT와 같은 기존 도구를 사용하여 TPU에서 모델을 학습, 서빙, 배포할 수 있습니다. 궁극적으로 이를 통해 고객은 전체 포트폴리오에서 일관되고 개방적인 소프트웨어 및 운영 모델을 사용하며 TPU, GPU, CPU 등 다양한 워크로드 최적화 컴퓨팅 옵션을 선택할 수 있습니다.

TPU에서 PyTorch 코드를 기본적으로 실행

Meta의 PyTorch팀과 공동 개발한 TorchTPU에서는 익숙한 API를 사용하여 최소한의 코드 변경으로 TPU에서 기존 PyTorch 워크로드를 실행할 수 있습니다. TorchTPU를 사용하면 즉시 실행 모드로 모델을 디버그한 다음 torch.compile을 통해 프로덕션 수준의 성능으로 전환하여 TPU 사용률을 최적화하고 메모리 오버헤드를 줄일 수 있습니다. TorchTPU는 표준 PyTorch API, 고급 진단, 네이티브 분산 기본 요소를 즉시 지원하여 도입 첫날부터 높은 성능과 운영 효율성을 제공합니다.

"Meta에서 AI의 한계를 뛰어넘기 위해서는 엄청난 규모의 컴퓨팅과 깊이 있고 다양한 하드웨어가 필수적입니다. 단일 하드웨어 아키텍처로 제한되어서는 안 됩니다. TorchTPU라는 획기적인 발전 덕분에 핵심 머신러닝 시스템팀과 함께 하드웨어를 유연하게 공동 개발하는 동시에 주요 프로덕션 사용 사례에서 주요 LLM, 광고, 추천 시스템 워크로드를 지원할 수 있게 되었습니다. PyTorch 워크로드를 Google TPU에 배포하고, 엔지니어링팀에 직접 피드백을 제공하며, 모두에게 필요한 유연한 생태계를 구축할 수 있게 된 것입니다."- Jana van Greunen, Meta PyTorch 엔지니어링 부문 이사

Hugging Face Hub의 인기 있는 개방형 가중치 모델이 TorchTPU에서 기본적으로 실행되도록 Hugging Face와도 협력했습니다. Transformers v5에서는 device_map="tpu"만 전달하면 모델을 TPU에 배포할 수 있습니다. 여러 가속기에서 대규모 생성 모델을 확장할 수 있도록 Diffusers 라이브러리가 TPU에서 기본적으로 실행되며 즉시 실행 모드, torch.compile, 텐서 병렬 처리를 지원합니다. 일관된 안정성을 유지하기 위해 TPU 인프라에서 Hugging Face Transformers 제품군의 지속적인 야간 테스트를 수행하기 위한 전용 CI/CD 파이프라인도 구축했습니다.

“Hugging Face는 AI 빌더가 자신에게 가장 적합한 모델, 프레임워크, 하드웨어를 선택할 수 있는 개방적이고 중립적인 플랫폼이 되고자 노력하고 있습니다. 누구나 오픈소스 AI를 이용할 수 있으려면 하드웨어 다양성이 필수적입니다. Hugging Face에서는 Google과의 협업을 통해 Transformer를 비롯한 핵심 라이브러리에 네이티브 TorchTPU 지원을 제공함으로써 이를 실현하고 있습니다. Google과 Hugging Face는 개발자 커뮤니티가 익숙한 PyTorch 워크플로를 사용해 Hub의 인기 모델을 Google Cloud TPU에서 효율적으로 실행할 수 있도록 협력하고 있습니다. 빌드 방법과 인프라에 대한 더 많은 선택권을 개발자에게 제공하면 전체 오픈소스 생태계가 성장하는 데 도움이 됩니다.” - Jeff Boudier, Hugging Face 제품 부문 부사장

추론 최적화

추론 및 에이전트형 모델의 규모가 커짐에 따라 추론 비용과 지연 시간이 프로덕션의 주요 병목 현상이 되고 있습니다. Google Cloud는 TorchTPU를 널리 사용되는 오픈소스 서빙 엔진에 통합하고 TPU 및 GPU 전반에서 Kubernetes 네이티브 Fleet 라우팅과 페어링하여 비용 대비 처리량을 최적화할 수 있도록 지원합니다.

이를 토대로 개발자는 번거로운 플랫폼별 조정을 최소화하면서 다양한 하드웨어에서 워크로드를 확장할 수 있습니다. 이러한 프레임워크 수준의 개선사항을 프로덕션에 적용하기 위해 Google은 주요 오픈소스 커뮤니티 및 업계 파트너와 협력해 왔습니다. 아래 섹션에서는 이러한 파트너십이 vLLM을 통한 높은 처리량의 서빙, SGLang을 통한 구조화된 에이전트형 실행, llm-d를 통한 대규모 분산 Fleet 조정 전반에서 어떻게 획기적인 효율성을 이끌어내고 있는지 살펴봅니다.

vLLM: 높은 처리량의 서빙 및 메모리 효율성

Inferact와의 협업을 통해 개발된 TorchTPU의 네이티브 PyTorch vLLM 백엔드를 사용하면 개발자가 최적화된 프로덕션 레디 서빙 기능과 커스텀 Pallas 커널을 통해 TPU에 직접 개방형 가중치 모델을 배포할 수 있습니다. 이 통합은 TPU 하드웨어에서 연속 일괄 처리, 양자화, 멀티 칩 병렬 처리를 지원하는 한편, 업스트림 작업자 모델, 스케줄러, API 서버를 보존하여 기존 추론 스택을 변경할 필요 없이 가격 대비 성능을 개선합니다.

"Inferact는 항상 전체 AI 생태계에서 고성능 추론을 접근 가능하고 안정적이며 비용 효율적으로 만드는 것을 사명으로 삼아왔습니다. TorchTPU 출시를 위해 협력하고 TPU에 vLLM을 위한 최고 수준의 지원을 제공하게 되어 기쁩니다. PyTorch의 최적화된 TPU 기능을 vLLM에 직접 연결함으로써 개발자가 Inferact 스택에 기대하는 높은 처리량, 짧은 지연 시간, 메모리 효율성을 갖춘 TPU에서 프로덕션 워크로드를 즉시 실행할 수 있습니다." - Simon Mo, Inferact CEO 겸 공동 설립자

SGLang: 구조화된 에이전트형 워크로드 가속화

RadixArk와의 협업을 통해 개발된 SGLang용 네이티브 PyTorch 백엔드는 TPU에서 고도로 구조화된 에이전트형 워크로드를 가속화합니다. SGLang은 RadixAttention을 사용하여 요청 간에 KV 캐시를 재사용하므로 반복되는 프롬프트 프리픽스의 재계산을 완전히 건너뛸 수 있습니다. SGLang-TorchTPU는 업스트림 작업자 모델, 스케줄러, API 서버를 보존하며, HiCache의 I/O 백엔드 역할도 하는 분리형 전송 백엔드를 사용하여 복잡한 다단계 생성의 지연 시간과 처리량을 최적화합니다.

"RadixArk는 다양한 실리콘 칩에 SGLang 지원을 출시하는 과정에서 TorchTPU를 통해 개발 속도를 크게 높였습니다. 덕분에 네이티브 TPU 가속화로 원활하게 전환하여 대폭 향상된 효율성과 유연한 컴퓨팅 옵션을 고객에게 직접 제공할 수 있게 되었습니다." - Banghua Zhu, RadixArk CTO 겸 공동 설립자

분산 LLM 추론을 위한 llm-d

대규모 Fleet에서 추론 엔진을 실행할 수 있도록 Red Hat, IBM과 500명이 넘는 참여자 및 25개 조직으로 이루어진 커뮤니티와 함께 llm-d 1.0을 출시합니다. Cloud Native Computing Foundation(CNCF) 샌드박스 프로젝트인 llm-d는 두 오픈소스 커뮤니티, 즉 vLLM과 SGLang이 모델을 서빙하는 PyTorch와 분산 시스템이 프로덕션에서 실행되고 확장되는 Kubernetes를 연결합니다. llm-d 라우터는 프리픽스 캐시 인식 라우팅을 사용하여 각 요청을 이미 컨텍스트를 가진 복제본으로 전송합니다. 또한 컴퓨팅 집약적인 사전 입력을 메모리 집약적인 디코딩에서 분리합니다. llm-d 1.0은 멀티 테넌트 흐름 제어, 라우터 고가용성, 안정적인 v1 API, 에이전트를 위한 세션 인식 라우팅을 지원하여 이러한 기술을 프로덕션에서 바로 사용할 수 있습니다. Google Kubernetes Engine(GKE)에서 공통 llm-d 엔드포인트를 사용하여 GPU 또는 Google TPU에서 실행할 수 있으며 각 워크로드에 적합한 하드웨어를 선택할 수 있습니다.

"Zenteiq에서는 llm-d 기반의 GKE Inference Gateway를 사용하여 자체 주권 과학용 파운데이션 모델을 위한 합성 데이터 생성을 가속화하고 있습니다. 부하 인식 및 프리픽스 캐시 인식 라우팅을 활용하여 총 추론 처리량을 4배 이상 높였으며, 일일 생성 토큰 용량을 TPU v6e 가속기 1,000개당 14억 7천만 개에서 59억 7천만 개로 늘렸습니다. GKE와 통합된 llm-d의 오픈소스 기반 덕분에 커스텀 추론 스케줄러를 개발하고 유지보수할 필요 없이 대규모의 여러 모델 제품군을 효율적으로 서빙할 수 있게 되었습니다." - Sashikumaar Ganesan 교수, Zenteiq.ai 설립자

대규모 학습

수천 개의 가속기에서 PyTorch 학습을 확장하려면 내결함성이 있고 컴파일을 인식하는 분산 프레임워크가 필요합니다. Google은 TorchTPU를 PyTorch 커뮤니티의 핵심 학습, 강화 학습(RL), 조정 프레임워크에 통합했습니다.

TorchTitan: 대규모 분산 고성능 학습

TorchTitan은 확장 가능한 분산 학습을 위한 PyTorch 네이티브 참조 구현으로, TorchTPU와의 프로덕션급 통합을 제공합니다. 개발자는 PyTorch의 torch.compile과 TorchTitan의 컴파일 친화적인 SimpleFSDP, 특화된 Pallas 커널, 그래프 수준 최적화를 연결하여 TPU에서 대규모 모델을 효율적으로 빌드하고 학습시킬 수 있습니다.

TorchTitan은 대규모 밀집형 모델(예: Llama 3 70B/405B, Qwen 3 8B/32B, MuseGlimmer 30B), 전문가 혼합(MoE)(예: Qwen 3 235B), DiT(Diffusion Transformer)(예: FLUX.1 12B)의 사전 학습을 위한 레시피를 제공하며, 최대 8,000개의 Ironwood TPU(TPU v7x)에서 실행되는 것으로 검증되었습니다. 초기 사전 학습 외에도 TorchTitan은 GRPO(Group Relative Policy Optimization) 및 RL 정렬을 지원하는 VeRL과 같은 사후 학습 파이프라인 내에서 확장 가능한 트레이너 역할을 합니다. 까다로운 개방형 아키텍처에서 대규모 효율성을 테스트하는 과정에서 TorchTitan을 통한 TorchTPU의 학습 경로는 Qwen 3 8B에서 최대 52%의 모델 FLOPS 사용률(MFU)을 달성했으며, 최대 8,192개의 Ironwood TPU에서 선형에 가까운 확장성과 안정성을 입증했습니다.

VeRL: 확장 가능한 사후 학습 및 강화 학습(프리뷰)

RL은 모델 기능을 강화하는 최첨단 연구소와 분야별 작업에 맞게 모델을 맞춤설정하는 기업에게 중요한 기반 기술입니다. 그러나 분산된 RL 워크로드를 조정하는 것은 여전히 현대 AI 인프라에서 가장 복잡한 과제 중 하나입니다. 이러한 공백을 메우는 VeRL은 검증 가능한 수학 및 코딩 보상부터 대규모 멀티턴 에이전트형 도구 사용에 이르기까지 모든 것을 지원하며 가장 인기 있는 RL 프레임워크 중 하나로 빠르게 자리 잡았습니다.

이 활발한 커뮤니티의 하드웨어 선택 폭을 넓히기 위해 Google에서는 TPU 백엔드 및 엔드 투 엔드 참조 레시피를 VeRL에 업스트림했습니다. 학습 효율성을 극대화하도록 설계된 분리형 트레이너-샘플러 아키텍처를 기반으로 구축된 수학적 추론 데이터 세트에 대한 GRPO 참조 레시피는 하드웨어 제약이 없는 기존 모델 및 알고리즘 코드를 보존하면서 TPU에 VeRL 워크로드를 배포하는 방법을 보여줍니다.

Ray: 이기종 컴퓨팅 조정

또한 Ray에 네이티브 TorchTPU 지원을 추가하여 단일 워크플로 내에서 CPU, GPU, TPU 전반의 PyTorch 데이터 처리, 학습, RL, 서빙을 조정할 수 있게 되었습니다. 이제 몇 줄의 리소스 구성만으로 이기종 AI 파이프라인의 각 단계를 작업에 가장 적합한 가속기에 스케줄링할 수 있습니다.

“Ray Summit에서 PARK 스택, PyTorch, AI 모델, Ray, Kubernetes에 대해 다룬 이유는 오늘날 프로덕션 AI를 빌드하는 데 사용되는 기술이기 때문입니다. TorchTPU는 Google TPU를 업계 표준 스택에 직접 임베딩합니다. 또한 Google팀과 긴밀히 협력하여 Ray에서 TPU를 최고 수준의 가속기로 지원했습니다. 네이티브 PyTorch 지원까지 더해져 이제 TPU에서 워크로드를 원활하게 개발, 확장, 모니터링할 수 있습니다." - Edward Oakes, Anyscale 수석 설계자

배포 유연성 및 운영 효율성

진정한 이동성을 위해서는 에지 기기와 클라우드 가속기를 비롯한 다양한 하드웨어 프로필에서 배포 도구를 표준화해야 합니다.

PyTorch 생태계에 합류한 LiteRT

대부분의 PyTorch 모델은 휴대전화, 노트북, 브라우저, 임베디드 기기에서 실행되어야 합니다. 오늘, Google의 고성능 온디바이스 AI 추론인 LiteRT(이전 명칭: TensorFlow Lite)가 PyTorch 생태계에 합류합니다.

LiteRT-Torch를 사용하면 단일 litert-torch.convert() 호출로 PyTorch 모델을 변환할 수 있습니다. torch.export() 및 Core ATen 연산자를 기반으로 빌드되어 모델 코드가 PyTorch에 유지됩니다. LLM의 경우 LiteRT Torch는 Hugging Face Transformer 모델을 내보내 LiteRT-LM으로 실행합니다. 변환된 모델은 Android, iOS, macOS, Windows, Linux, 웹, IoT 기기에서 실행되며, 단일 API를 통해 제공되는 주요 칩셋의 CPU(XNNPack 이용), GPU(오픈소스 ML Drift 이용), NPU 전반에서 하드웨어 가속을 지원합니다.

초기 프리뷰 버전의 TPU Agent Suite 출시

TPU에의 PyTorch 도입을 확대하기 위해 TPU Agent Suite가 GitHub에서 프리뷰 버전으로 제공된다는 소식을 알려드립니다. 여러 코딩 하네스 모델 조합과 플러그인을 통해 통합되는 TPU Agent Suite는 많은 PyTorch 모델의 온보딩, 진단, 사용자 질문, 추론 성능 조정을 자동화하는 데 도움이 됩니다.

Google Cloud에서 PyTorch 시작하기

이러한 출시는 Google TPU 소프트웨어 생태계를 PyTorch 커뮤니티를 위한 개방적이고 개발자 친화적인 환경으로 만들겠다는 Google의 약속이 실현된 결과물입니다. Google은 TorchTPU, Hugging Face, vLLM, SGLang, llm-d, TorchTitan, VeRL, Ray 전반의 PyTorch 스택 업스트림으로 네이티브 TPU 지원을 통합하고 PyTorch 생태계에 LiteRT를 포함시킴으로써 사용자가 원하는 방식으로 AI를 빌드, 조정, 확장할 수 있는 유연성을 제공하고 있습니다.

Google Cloud 문서를 방문하여 지금 바로 TPU에서 PyTorch를 실행해 보세요.

글로벌 규모의 하드웨어 기반 보안: NVIDIA Blackwell을 탑재한 컨피덴셜 G4 정식 버전 출시

Tue, 27 Oct 2026 19:00:00 +0000

자율 에이전트를 프로덕션에 도입하려면 민감한 데이터와 가치 있는 지식 재산을 실시간으로 처리해야 합니다. 독점 모델 가중치, 사용자 프롬프트, 생성된 출력을 보호하기 위해서는 데이터가 실제로 처리되는 동안 데이터를 안전하게 보호하는 보안 기능이 필요합니다.

기업의 보안 강화를 지원하기 위해 오늘 Google은 NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU로 구동되는 Google Cloud G4 인스턴스의 컨피덴셜 컴퓨팅을 정식 버전으로 출시한다고 발표했습니다. 이번 출시를 통해 NVIDIA 컨피덴셜 컴퓨팅을 Google Cloud의 AI 하이퍼컴퓨터에 직접 통합하여 개인 정보 보호를 저해하지 않으면서 확장하는 데 필요한 동적 성능을 제공합니다.

올해 초 컨피덴셜 G4 프리뷰 버전을 발표하면서 전 세계적인 입지와 규모에 대해 말씀드렸습니다. 이제 이러한 인스턴스는 36개 영역에서 여러 가격 모델을 통해 Compute Engine VM 및 GKE 노드에 정식 버전으로 제공됩니다.

또한 안전한 다자간 데이터 공유를 지원하는 Confidential Space도 앞으로 몇 주 내에 정식 버전으로 출시될 예정입니다.

짧은 지연 시간으로 민감한 데이터와 모델 보호

사용 중인 데이터를 보호하기 위해 GPU 처리량이나 운영 민첩성을 희생할 필요는 없습니다. 컨피덴셜 G4는 내보낼 수 없는 하드웨어 키, 검증 가능한 원격 증명, 투명한 메모리 암호화를 결합하여 조직이 에이전트 워크로드와 추론 워크로드에 대한 투자를 극대화할 수 있도록 지원합니다. 기업은 엄격한 규제 및 규정 준수 요구사항을 충족하면서도 비용을 낮게 유지할 수 있습니다.

"조직이 점점 더 복잡해지는 클라우드, 온프레미스, 에이전트 환경 전반에 AI를 배포함에 따라 민감한 데이터를 보호하는 것이 중요해졌습니다. 또한 기업은 AI 시스템이 안전하고 일관되게 정책에 따라 작동하도록 보장해야 합니다. NVIDIA RTX PRO 6000 Blackwell GPU로 구동되는 Google Cloud의 컨피덴셜 G4 VM은 개인 정보를 보호하는 AI와 AI 운영을 위한 강력한 기반을 제공합니다. Confidential Core AI는 Google Cloud를 기반으로 엔터프라이즈 원칙, 정책, 운영 요구사항을 AI 에이전트, 모델, 데이터, 도구를 모니터링하고 제어하는 실시간 보호 장치로 전환합니다. 이러한 기능이 결합되어 조직은 제어, 기밀성, 책임성을 유지하면서 Google Cloud에서 신뢰할 수 있는 AI를 확장할 수 있습니다." - Taher Behbehani, Confidential Core AI 설립자 겸 CEO

엔터프라이즈 AI 워크로드를 위한 추가적인 이점은 다음과 같습니다.

엔드 투 엔드 기밀성 및 격리: 하드웨어 적용 실행 환경에서 데이터와 모델 파라미터를 암호화하여 호스트 시스템 관리자, 하이퍼바이저, 클라우드 제공업체의 액세스로부터 지식 재산과 고객 입력 데이터를 보호합니다.
검증 가능한 암호화 신뢰: 하드웨어 기반 원격 증명을 사용하여 민감한 데이터 세트를 공개하고 워크로드를 실행하기 전에 코드, 플랫폼 구성, 환경 무결성을 검증합니다.
코드 리팩터링 불필요: 애플리케이션 변경이나 커스텀 빌드 없이 표준 Ubuntu OS 이미지, NVIDIA 드라이버, NVIDIA CUDA-X 라이브러리를 사용하여 즉시 모델을 배포할 수 있습니다.

Polaris Cloud에는 이러한 간편한 배포 방식이 획기적인 변화를 가져왔습니다.

“Polaris는 AI 에이전트를 위한 작업공간을 빌드하며, 고객은 에이전트의 작업이 실제로 어디에서 실행되었는지, 그리고 그 과정에서 암호화 방식으로 격리되었는지 확인할 수 있어야 합니다. Google Cloud의 컨피덴셜 G4는 이러한 상황을 완전히 바꿔 놓았습니다. 당사는 NVIDIA RTX PRO 6000 Blackwell GPU에서 하드웨어 기반의 출처를 확보하고 이를 고객이 결과와 함께 받는 영수증에 바인딩합니다. 그 외에는 사실상 아무것도 바뀌지 않았습니다. 동일한 G4 이미지, 동일한 NVIDIA 드라이버, 동일한 컨테이너 런타임을 사용하며 실행 시 플래그 하나만 추가하면 동일한 성능을 유지할 수 있습니다. 이를 통해 '고객의 에이전트를 실행해 드립니다'라는 고객과의 약속을 '고객이 당사와 함께 실행하는 모든 워크로드는 검증 가능합니다'로 하룻밤 사이에 업그레이드할 수 있었습니다.” - Fred Esere, Polaris Cloud 설립자 겸 CEO

다자간 데이터 공동작업: Confidential Space를 사용하여 공동 분석 및 공동 모델 학습을 안전하게 실행합니다. 여러 당사자가 서로에게 비공개 데이터를 공개하지 않고도 민감한 데이터 세트를 결합할 수 있습니다.

“기업은 가장 가치 있는 데이터를 AI에 활용하는 동시에 처리 과정에서 데이터를 보호해야 합니다. NVIDIA 컨피덴셜 컴퓨팅은 GPU 가속 워크로드에 하드웨어 기반 보호 기능을 제공하여 민감한 정보와 독점 모델이 사용되는 동안에도 안전하게 보호할 수 있도록 지원합니다. Google Cloud와 함께 NVIDIA Blackwell의 성능과 이러한 보안 기능을 컨피덴셜 G4 VM에 도입하여 조직이 높은 성능과 검증 가능한 보호 기능을 바탕으로 프로덕션 AI를 확장할 수 있도록 지원하고 있습니다.” - Dave Salvator, NVIDIA 가속 컴퓨팅 제품 부문 책임자

성능 테스트

메모리 암호화가 운영에 미치는 영향을 이해하기 위해 g4-standard-48 머신 유형에서 컨피덴셜 G4 인스턴스와 표준 비컨피덴셜 G4 인스턴스를 비교 분석했습니다. 이번 테스트는 널리 채택되어 여러 고객이 자체 추론 파이프라인을 위해 단일 GPU 인스턴스에 자주 사용하기도 하는 개방형 가중치 모델에 중점을 두었습니다.

Llama 3, Llama 3.3, Resnet-50, SDXL 등 널리 사용되는 모델에 대한 벤치마킹 결과, 컨피덴셜 G4는 AI 추론 워크로드에 대해 표준 G4 인스턴스와 동등한 수준의 성능을 제공하며, 처리량 저하는 3.5% 미만(초당 토큰 또는 이미지 수로 측정)인 것으로 나타났습니다.

참고: 성능 결과는 특정 테스트 조건 및 구성을 기반으로 합니다. 개별 워크로드 성능은 시스템 설정, 하드웨어 선택, 소프트웨어 환경에 따라 달라질 수 있습니다.

이번 분석은 민감한 데이터를 보호하고 규정 준수 요구사항을 충족하면서도 신속하게 작업을 진행할 수 있음을 보여줍니다. 실제 배포 환경에서도 이러한 절충 방식이 검증되었습니다.

"Google Cloud의 컨피덴셜 G4와 당사 워크로드에서 동일한 소프트웨어를 실행하는 표준 G4의 성능을 벤치마킹해봤습니다. 그 결과, 엔드 투 엔드 지연 시간이 5.2% 증가하는 정도의 작은 성능 저하만으로도 사용자의 증명된 환경 외부에 있는 권한 없는 사용자가 대화를 도청할 수 없도록 하는 하드웨어 수준의 보증을 확보할 수 있다는 사실을 발견했습니다. 우리는 언제나 이러한 선택을 할 것입니다. 사용자는 온프레미스의 개인 정보 보호 기능과 함께 클라우드의 편리함을 누릴 수 있기 때문입니다." - Andy Qin, Vertebrae CEO

컨피덴셜 G4 시작하기

컨피덴셜 G4를 사용하면 모델 실행 및 에이전트형 워크로드 처리 과정에서 성능, 유연성 또는 운영 단순성을 희생하지 않고도 엔터프라이즈 보안을 강화할 수 있습니다. 처리량 저하가 거의 없으면서도 검증 가능한 신뢰와 강력한 하드웨어 격리를 제공하므로 조직은 클라우드 규모에서 가치가 높은 모델을 안전하게 배포하고 중요한 데이터 자산을 보호할 수 있습니다.

GPU를 사용하는 컨피덴셜 VM 문서를 참고하여 지금 바로 시작해 보세요.

Google Cloud 피지컬 AI로 로봇 시뮬레이션부터 학습, 운영까지 구현하세요

Mon, 26 Oct 2026 19:00:00 +0000

로봇이 창고에서 안전하게 상자를 집어 올리거나 제조 현장에서 작업하려면 먼저 학습해야 합니다. 이를 위해 엔지니어링 팀은 방대한 양의 합성 데이터를 생성하고, 대규모 비전 및 이동 모델을 학습시키며, 로컬 하드웨어에서 매우 빠른 반응 속도로 해당 모델을 실행할 수 있어야 합니다. 물리적 머신에서 직접 테스트하는 방식은 하드웨어 파손, 막대한 비용을 초래하는 다운타임, 그리고 안전사고의 위험이 따릅니다.

오늘은 Google Cloud 피지컬 AI가 어떻게 시뮬레이션, 모델 학습, 실제 배포를 하나의 플랫폼으로 통합하여 로봇 개발자와 엔지니어링 팀을 지원하는지 소개합니다.

물리 시뮬레이션, 동영상 라벨링, GPU 학습, 에지 컴퓨팅을 위해 여러 도구를 번거롭게 병합할 필요 없이, 이제 Google Cloud에서 전체 로보틱스 파이프라인을 실행할 수 있습니다.

단계	워크로드	Google 제품
시뮬레이션	NVIDIA Isaac Sim , Mujoco,	G4
학습	동영상 시퀀스 자동 라벨링 및 VLA/WMA 학습	NVIDIA로 가속화된 A3, A4, A5 머신(Cluster Director, GKE, Gemini 플랫폼의 클러스터 학습), Managed Lustre를 갖춘 AI 하이퍼컴퓨터
운영	멀티 카메라 스트리밍, 센서 데이터, Google 모델 활용	GCS, Pub/Sub, BigQuery, Gemini Live, Gemma 4, GDM ER 2

각 단계는 다음 단계와 직접 연결되어, 가상 환경의 학습 데이터를 생산 로봇으로 전달하고 실제 세계의 센서 로그를 향후 학습 실행에 다시 반영합니다.

1. 시뮬레이션: 하드웨어를 건드리기 전에 가상 환경에서 로봇 테스트

개발자는 새로운 로봇 동작 테스트를 가속화하기 위해 NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU 기반의 그래픽 최적화 G4 VM을 사용하여 Google Kubernetes Engine(GKE)에서 수천 개의 가상 환경을 병렬로 실행할 수 있습니다. 이 설정은 NVIDIA Isaac Sim 개방형 시뮬레이션 프레임워크, NVIDIA Cosmos 오픈 월드 파운데이션 모델, Google DeepMind의 가속화된 물리 엔진인 MuJoCo Warp를 포함한 물리 및 시뮬레이션 도구를 지원합니다.

이러한 가상 환경에서 엔지니어링팀은 대규모 강화 학습 테스트를 실행하고, 멀티 카메라 뷰가 각도에 따라 일관되게 유지되는지 확인하고, 로봇이 보고 듣는 것을 움직이는 방식과 연결하는 비전 언어 행동(VLA) 모델을 벤치마킹할 수 있습니다. 다운타임, 하드웨어 비용, 물리적 시행착오로 인한 안전 위험 없이 사용 사례를 더 쉽게 시뮬레이션할 수 있습니다.

2. 학습: 동영상 데이터 자동 라벨 지정 및 대규모 로보틱스 모델 학습

로봇이 물리적 세계의 작동 원리를 학습하기 위해서는 일반적으로 라벨이 지정된 방대한 양의 동영상 데이터가 필요합니다. Google Cloud는 Gemini 모델 제품군과 NVIDIA Cosmos를 결합하여 동영상을 자동으로 분석하고 라벨을 지정합니다. Gemini는 긴 녹화물에서 동영상, 오디오, 공간 컨텍스트를 처리하므로 도구 모음은 경계 상자를 자동으로 만들고, 장면의 객체에 라벨을 지정하고, VLA 학습 주석을 생성할 수 있습니다.

데이터에 라벨이 지정되면 Google Cloud의 AI 하이퍼컴퓨터에서 분산 학습으로 바로 이동하여 대규모 VLA 및 세계 모델 아키텍처(WMA) 네트워크를 빌드하고 미세 조정할 수 있습니다.

빠른 데이터 스토리지: 멀티 카메라 동영상 및 움직임 데이터 세트는 밀리초 미만의 지연 시간과 초당 테라바이트 속도를 제공하는 완전 관리형 병렬 파일 시스템인 Google Cloud Managed Lustre에 저장됩니다. 이를 통해 GPU에 데이터를 끊김 없이 공급하고, 빈번하게 발생하는 모델 체크포인트 생성 속도를 높일 수 있습니다.
GPU 직접 제어: A3, A4, A5 VM에서 베어메탈급 GPU 성능을 구현하려는 팀은 Cluster Director(GCE 또는 GKE 기반 관리형 Slurm용) 또는 GKE(기본 제공 기능 또는 Slinky Slurm Operator 부가기능 활용)를 사용할 수 있습니다. Google의 Jupiter 네트워크 패브릭 전반에서 작업을 예약하여 대규모 강화 학습 실행 중에도 높은 대역폭을 유지합니다.
관리형 학습: DIY 클러스터 배관을 빌드하고 유지관리하는 것을 선호하지 않는 팀은 Gemini 플랫폼의 Vertex AI/학습 클러스터를 사용할 수 있습니다. 이 클러스터는 관리형 Slurm 조정, 자동화된 하드웨어 장애 복구, 즉시 사용 가능한 분산 SFT 및 RL용 레시피 또는 미세 조정을 위한 서버리스 커스텀 학습 작업을 제공합니다.

3. 운영: 현장에서 모델을 실행하고 실제 데이터에서 학습

공장과 창고에서 로봇을 실행하려면 클라우드 규모의 계획과 빠른 로컬 실행이 모두 필요합니다. Google Cloud는 팀이 클라우드, 하이브리드, 오프라인 환경 전반에 세계 모델과 자체 커스텀 에이전트를 배포할 수 있도록 지원합니다.

작업 계획 및 음성 상호작용: Gemini Robotics ER 2(Embodied Reasoning, 현재 Model Garden 및 Google AI Studio의 Gemini API에서 프리뷰로 제공)는 공간 및 물리적 이해를 단계별 작업 계획과 하위 수준 로봇 제어를 위한 멀티 로봇 조정으로 전환합니다.
이와 함께 Gemini Live는 70개 이상의 언어로 시각 지능과 지연 시간이 짧은 음성 대화를 지원하므로 로봇이 눈앞의 상황을 이해하는 동시에 음성 지시에 반응할 수 있습니다.
온프레미스 및 오프라인 실행: Google Distributed Cloud(GDC)는 공장 및 창고 현장에서 직접 관리형 컴퓨팅과 컨테이너를 실행하여 저지연 카메라 처리와 Fleet 관리를 지원합니다. 네트워크 연결 없이 작동하는 로봇의 경우 경량형 Gemma 4 개방형 모델이 로컬 하드웨어에서 실행되어 10밀리초 이내에 비전, 오디오, 도구 호출을 처리합니다.
지속적인 개선: 페타바이트 규모의 차량 로그와 센서 스트림이 Cloud Storage 및 Pub/Sub를 통해 BigQuery로 유입됩니다. 팀은 이 데이터를 사용하여 장비 문제를 조기에 발견하고 실제 결과를 다음 모델 학습에 반영할 수 있습니다.

Google Cloud 피지컬 AI 시작하기

첫 번째 물리 시뮬레이션을 실행하는 단계이든, 대규모 창고 로봇을 관리하는 단계이든, 지금 바로 Google Cloud에서 개발을 시작할 수 있습니다.

시뮬레이션: Google Kubernetes Engine에서 그래픽에 최적화된 G4 VM을 가동하여 NVIDIA Isaac Sim과 MuJoCo-Warp를 실행합니다.
학습: AI 하이퍼컴퓨터 학습 레시피를 Gemini 플랫폼에서 살펴보거나 Cluster Director를 Google Cloud Managed Lustre와 함께 설정합니다.
운영: 프리뷰 버전의 Gemini Robotics ER 2를 사용해 보거나 Google Cloud팀에 문의하여 피지컬 AI 워크숍을 설정하세요.

자율성 설계: 생명공학 분야의 고성능 컴퓨팅, 거버넌스형 에이전트를 위한 설계 패턴

Sun, 25 Oct 2026 19:00:00 +0000

오늘날 프로덕션 시스템에서 대부분의 AI 에이전트는 경량 디스패처로 작동합니다. AI 에이전트는 프롬프트를 파싱하여 API 호출을 수행하고, 레코드를 검색 후, 제어권을 다시 넘겨줍니다. 또한 실행 속도가 빠르고, 스테이트리스(Stateless)이며, 비용이 저렴합니다. 하지만 생명공학 분야에서는 이런 방식으로 작동하지 않습니다.

단백질 표적 접힘 구조를 예측하고, 50,000개의 화합물 리간드 라이브러리를 스크리닝하거나, 구조-활성 관계(SAR)를 평가하는 것은 빠른 API 조회로 해결할 수 있는 일이 아닙니다. 이러한 워크로드는 특화 실리콘 칩에서 몇 분 또는 몇 시간 동안 실행되는 지속적이고 스테이트풀(Stateful)한 GPU 집약적 시뮬레이션입니다. 범용 대규모 언어 모델(LLM) 엔드포인트에 복잡한 신약 개발 워크플로를 조정하도록 요청하면 표준 패러다임이 깨집니다. 타임아웃이 발생하고, 컨텍스트 윈도우가 원자 좌표로 넘쳐나며, 독점적인 화학 지식 재산(IP)이 외부 네트워크에 노출될 위험이 있습니다.

엔터프라이즈급 연구 개발(R&D) 에이전트를 빌드하려면 모놀리식 어시스턴트 모델을 넘어서야 합니다. 이 블로그 게시물에서는 인지 조정(두뇌)과 연산 실행(근육)을 분리하고, 두 가지를 모두 엔터프라이즈 거버넌스 플레인 내에 통합하여 생명공학 분야의 신약 개발 사용 사례에 활용할 수 있는 확장 가능한 에이전트를 빌드하는 3계층 아키텍처 활용법을 다룹니다.

3계층 패턴

아래의 참조 아키텍처는 생명공학, 특히 신약 개발 분야에서 고성능 컴퓨팅 자율 에이전트를 설계, 최적화, 거버넌스를 적용하는 방법을 보여줍니다.

그림 1 — 3계층 패턴: 인지 조정자(두뇌), 확장 가능한 GPU 실행 계층(근육), 엔터프라이즈 거버넌스 플레인

실행 계층: 근육 확장 - 고성능 컴퓨팅 실행

실행 계층은 고부하 과학 계산을 담당합니다. 첫 번째 아키텍처 결정은 워크로드를 실행할 위치를 정하는 것입니다.

전략적 독점 파이프라인에는 보안 경계 내에 전용 GPU 인프라가 필요합니다.
일상적이거나 표준화된 워크로드는 관리형 클라우드 엔드포인트에 안전하게 맡길 수 있습니다.

이 아키텍처에서 단백질 접힘은 ESMFold가, 생성형 설계는 GenMol이 주도합니다. 두 모델 모두 NVIDIA Inference Microservices(NIM)로 실행됩니다. NIM은 NVIDIA RTX PRO 6000 Blackwell GPU 기반 G4 VM을 사용하여 Google Kubernetes Engine(GKE)에 배포됩니다.

컨테이너화된 GPU 워크로드의 주요 걸림돌은 콜드 스타트 페널티, 즉 이미지 레지스트리에서 수 기가바이트의 모델 가중치를 가져와 GPU 메모리(VRAM)에 스테이징하는 데 걸리는 지연 시간입니다.

짧은 지연 시간의 응답성을 보장하기 위해 다음 권장사항을 참조 아키텍처에 반영했습니다.

웜 풀 유지: GKE 노드 풀을 최소 하나의 활성 노드에 고정합니다.
가중치 미리 로드: 포드 초기화 시 모델 가중치가 VRAM에 직접 로드되므로 컨테이너에서 즉시 추론이 가능합니다.
복원력 있는 스케줄링: GKE는 기본 VM 인프라를 해체하지 않고도 포드 수명 주기를 관리하고 실패한 인스턴스를 다시 시작합니다.

이 접근방식은 커스텀 수동 CUDA 커널 조정 대신 NVIDIA의 사전 컴파일하여 컨테이너화된 런타임을 활용하여 인프라 엔지니어링 오버헤드를 크게 줄이면서 결정론적 처리량을 보장합니다.

생명공학 분야에서 화학 구조는 수백만 달러의 가치를 지닌 독점적 지식 재산에 해당합니다. 도킹 요청은 회사 외부로 절대 유출되어서는 안 되는 SMILE 문자열 또는 3D 좌표 행렬을 전송합니다.

컨테이너화된 NIM은 빠른 프로토타입 제작과 엄격한 데이터 격리 사이의 마찰을 해결합니다. 초기 탐색 분석 단계에서 연구원은 NVIDIA 호스팅 엔드포인트를 쿼리할 수 있습니다. 독점적인 리드 후보 물질로 전환할 때 정확히 동일한 컨테이너가 비공개 VPC 내의 GKE에 배포됩니다. 에이전트의 조정 로직은 동일하게 유지되며, 대상 URI만 외부 프록시에서 내부 VPC 엔드포인트로 업데이트됩니다. 분자 구조 데이터는 기업 경계 외부로 유출되지 않습니다.

인지 계층: 멀티 에이전트 추론

컴퓨팅 실행이 격리된 상태에서 인지 계층은 에이전트형 워크플로 시퀀싱을 관리합니다. Gemini 플랫폼 내의 Agent Runtime을 기반으로 빌드된 이 참조 아키텍처는 계층적 멀티 에이전트 구조, 하나의 리드 조정자, 두 개의 전문 도메인 하위 에이전트(리드 최적화 및 안전성 스크리닝)를 배포하는 시스템을 보여줍니다. 멀티 에이전트 설계는 당면한 사용 사례에 맞게 수정할 수 있습니다.

이 설계를 기반으로 최종 사용자가 '표적 X에 대해 후보 4b를 분석하고 SAR 보고서 작성'과 같은 상위 수준의 작업을 제출하면, 시스템은 아래에서 설명하는 4가지 핵심 조정 패턴을 적용합니다.

인 프로세스 네이티브 에이전트 핸드오프: 리드 조정자는 네트워크 직렬화 방식의 에이전트 간 HTTP 프로토콜이 아닌 Agent Runtime의 네이티브 SDK를 사용하여 전문 하위 에이전트에 작업을 위임합니다. 이렇게 하면 중간 네트워크 홉이 제거되어 내부 핸드오프가 즉각적으로 처리됩니다. 가장 바깥쪽 경계만 Gemini 에이전트와 같은 사용자 대상 인터페이스로 외부와 통신합니다.
참조를 통한 대용량 페이로드 전달: LLM이 대규모 3D 공간 좌표 배열을 직접 처리해야 할 때 빠르게 성능이 저하됩니다. 이 아키텍처에서는 원시 구조 데이터(PDB 파일, 도킹 포즈, 궤적 로그)가 Cloud Storage에 직접 기록됩니다. 에이전트는 서명된 경량 객체 URI와 상위 수준의 구조적 요약을 전달하여 컨텍스트 윈도우를 간결하게 유지하고 추론 비용을 절감합니다.
생화학적 추론과 워크플로 로직 분리: 범용 LLM은 작업 계획 및 합성에 탁월하지만 생화학적 세부정보에서 할루시네이션 현상이 발생하는 경향이 있습니다. 이러한 동작을 제어하기 위해 이 아키텍처는 관심사의 분리를 엄격하게 유지합니다. 즉, Gemini가 워크플로와 작업 분해를 처리합니다. 도메인 화학 및 약리학적 추론은 전용 GPU 노드에서 호스팅되는 특화된 Nemotron 모델에서 처리됩니다.
엄격한 기준 대신 맥락 중심으로 평가: 기존의 계산 스크리닝 방식은 임의의 수치 기준을 적용합니다(예: 결합 친화도가 -7.5kcal/mol 미만인 경우 폐기). 그러나 치료적 맥락 방식은 위험 허용 범위를 근본적으로 변경합니다. 건강한 일반인이 매일 복용하는 예방적 심혈관 치료제에는 매우 엄격한 안전성 마진이 필요한 반면, 난치성 암을 표적으로 하는 새로운 항암제 후보 물질은 효능이 입증되면 더 높은 독성을 수용할 수도 있습니다.

질환 맥락 정보를 전문 추론 모델에 직접 전달하면 약물 후보를 정적 기준이 아닌 동적인 표적에 특화된 프로필에 따라 평가하게 되므로, 유효한 리드 물질이 조기에 배제하는 것을 방지할 수 있습니다.

고성능 컴퓨팅 파이프라인의 성능 권장사항

대규모 GPU 컴퓨팅과 연동하는 에이전트형 시스템을 최적화하려면 일반적인 엔지니어링 통념에서 벗어날 필요가 있습니다.

일반적인 가정	실제 아키텍처	권장사항
'더 빠른 드라이버 모델로 교체하여 지연 시간을 줄입니다.'	기본 조정자의 토큰 생성은 다단계 R&D 파이프라인에서 병목 현상이 발생하는 경우가 거의 없습니다.	토큰 속도가 아닌 I/O 최적화: 조정자 추론 깊이를 타협하기보다는 페이로드 크기와 중간 네트워크 홉을 줄이는 데 집중합니다.
'작업자 간에 도구 호출을 병렬화합니다.'	외부 과학 서비스와 컨테이너화된 모델은 전용 하드웨어에서 내부적으로 요청을 순차 처리하는 경우가 많습니다.	실행 토폴로지 준수: 클라이언트 측 동시 실행을 백엔드 큐 메커니즘과 일치시켜 파이프라인 잠김 및 연결 시간 초과를 방지합니다.
'도구 간에 전체 시뮬레이션 상태를 전달합니다.'	대규모 JSON 본문은 스키마 검증 실패, 프롬프트 잘림, 토큰 비대화를 유발합니다.	참조로 대용량 페이로드 전달: 원시 좌표를 객체 스토리지에 저장하고 에이전트 경계 간에 경량 URI를 전달합니다.
'파이프라인이 완료된 경우에만 출력을 반환합니다.'	실행 시간이 몇 분 이상 걸리는 경우 과학자는 작업이 진행 중인지 아니면 중단되었는지 파악하기 어렵습니다.	중간 단계 완료 스트리밍: 각 마일스톤이 완료될 때마다 진행 상황 업데이트를 전송하여(예: 폴딩 완료, 도킹 실행 중) 실시간 정보를 파악합니다.
'세분화된 여러 마이크로 도구를 연결합니다.'	도구 체인이 깊어지면 할루시네이션 인수와 스키마 불일치가 발생할 가능성이 높아집니다.	컴퓨팅 파이프라인 축소: 명확한 파라미터를 사용하고 통합 객체를 반환하는 깔끔한 단일 도구 인터페이스로 엔드 투 엔드 시뮬레이션 파이프라인을 래핑합니다.

엔터프라이즈 거버넌스와 비대칭적 자율성

엔터프라이즈 환경에 고성능 컴퓨팅 에이전트를 배포하려면 강력한 데이터 주권, 감사 추적, 프로세스 제어가 필요합니다. Gemini 플랫폼은 다음 구성요소를 통해 이러한 보호 수단을 기본 기능으로 제공합니다.

에이전트 아이덴티티: 모든 자율 에이전트는 암호화 방식으로 검증 가능한 ID로 작동합니다. 따라서 생명공학 분야의 사용 사례에서 후보 분자가 채택되거나 거부되면 해당 이벤트가 특정 에이전트 보안 주체에 영구적으로 로깅됩니다.
Agent Gateway: 이 구성요소는 경계 내의 모든 상호작용에 대한 단일 인그레스/이그레스 지점 역할을 합니다. 중앙 집중식 IAM과 리전별 저장 위치 규칙은 민감한 분자 데이터가 지정된 클라우드 리전 내에 유지되도록 보장합니다.
Agent Registry: 이 기능은 승인된 에이전트, 검증된 도구 스키마, 승인된 모델 컨텍스트 프로토콜(MCP) 서버의 선별된 카탈로그를 유지하여 프로덕션에서 악성 도구가 실행되는 것을 방지합니다.
Model Armor: 이 기능은 수신 프롬프트와 발신 페이로드를 실시간으로 검사하여 프롬프트 인젝션과 데이터 무단 반출을 방지합니다.

성과는 명확합니다. ID, RBAC, 감사, 저장 위치, 데이터 보호는 Gemini 플랫폼의 기본 속성입니다. 이를 통해 기업 고객은 프로젝트마다 규정 준수 스택을 일일이 구축할 필요 없이 과학 연구 개발에 집중할 수 있습니다.

중요한 연구 개발에서 완전한 자율성은 감당하기 어려운 책임을 초래하는 반면, 사소한 단계까지 승인을 요구하면 불편함이 발생할 수 있습니다. 이 문제를 해결하기 위해 다음과 같은 방식으로 비대칭 게이팅을 적용합니다.

되돌릴 수 있는 작업 자동화: 예를 들어 에이전트가 연구원의 개입 없이 자율적으로 화학 명명 동의어를 해결하고, PDB 구조 데이터를 가져오며, 예비 리핀스키 스크리닝을 실행할 수 있도록 허용합니다.

되돌릴 수 없는 작업 제어: 예를 들어 멀티 GPU 도킹 작업을 시작하거나, 리드 물질을 습식 실험실 합성 단계로 진행하거나, 치료 프로그램을 보관처리하는 작업에는 담당자의 명시적인 승인이 필요합니다.

패턴과 앞으로 나아갈 방향

고성능 컴퓨팅 자율 에이전트는 인지 계획, 수치 계산, 시스템 거버넌스 간의 경계가 다음과 같은 방식으로 명확할 때 성공합니다.

조정자는 분해와 합성에 집중하고, 집약적인 생물물리학적 시뮬레이션은 컨테이너화된 전문 마이크로서비스와 모델에 맡깁니다.
클라우드 스토리지를 통해 복잡한 화학 데이터를 참조로 전달하여 컨텍스트 비대화를 제거합니다.
암호화 에이전트 ID와 비대칭적 담당자 감독을 결합하여 엔터프라이즈 거버넌스에 워크플로의 기반을 둡니다.

생성형 및 구조 생물학 모델이 전체 세포 모델링과 복잡한 동적 시뮬레이션으로 확장됨에 따라, 이 분리된 아키텍처는 독점 IP를 안전하고 감사 가능하게 유지하는 동시에 연구 시스템을 효율적으로 확장할 수 있도록 보장합니다.

이와 같은 사용 사례를 구축하기 위한 요구사항이 있는 경우 Google 영업 담당자에게 문의해 주세요. Google Cloud에서 에이전트 개발 여정을 함께 논의하고 지원해 드리겠습니다.

Google Cloud, Reflection의 Beam 출시와 동시에 지원: llm-d 및 NVIDIA Dynamo를 5배 빠른 성능 제공

Sun, 25 Oct 2026 19:00:00 +0000

오늘 Reflection은 개발자, 연구원, 기업이 첨단 소프트웨어 엔지니어링과 장기 에이전트 작업을 자유롭게 제어하고 맞춤설정할 수 있도록 설계된 최초의 개방형 가중치 모델인 Beam을 출시했습니다. 출시 시점에 BF16, FP8, NVFP4 체크포인트를 사용할 수 있는 허용적인 Apache 2.0 라이선스에 따라 출시된 Beam은 유사한 오픈 모델보다 3~4배 더 높은 추론 컴퓨팅 효율로 복잡한 추론 및 코딩 문제를 해결함으로써 5,000억 개의 파라미터 클래스에서 추론 효율성의 새로운 표준을 제시합니다.

오늘 출시에 맞춰 Google Cloud는 Google Cloud AI 하이퍼컴퓨터 및 NVIDIA AI 인프라에서 Beam을 서빙할 수 있도록 당일부터 지원하고 즉시 실행 가능한 배포 레시피를 발표합니다.

개발자가 프로덕션에서 Beam의 토큰 효율성을 최대한 활용할 수 있도록 Google은 Reflection과 협력하여 Google Cloud에서 llm-d(vLLM 사용) 및 NVIDIA Dynamo(SGLang 사용)를 사용해 기본 서빙 스택의 성능을 최적화했습니다.

"Google Cloud에 Beam 모델을 배포하여 최대 5배 더 높은 성능과 8배 더 짧은 지연 시간을 달성하여 에이전트형 워크로드의 서빙을 최적화했습니다." - Joe Spisak, Reflection 제품 부문 부사장 겸 오픈소스 책임자

오늘 Google Cloud에서 출시와 동시에 지원을 시작함에 따라 개발자는 다음과 같은 이점을 누릴 수 있습니다.

모델 및 시스템 효율성 결합: Beam의 3~4배 향상된 추론 컴퓨팅 효율과 시스템 수준 최적화를 결합하여 A4X Max 인스턴스(NVIDIA GB300 NVL72)에서는 최대 5배 더 높은 처리량과 8배 더 낮은 지연 시간*을, G4 VM(NVIDIA RTX PRO 6000)에서는 최대 2배 더 높은 처리량과 8배 더 낮은 지연 시간*을 달성합니다.
고효율 멀티턴 서빙: KV 캐시 인식 라우팅, 프리필/디코딩 분리, 추측 디코딩, 호스트 DRAM 및 로컬 SSD로의 계층적 KV 캐시 오프로딩을 통해 긴 코딩 세션에서 중복되는 프롬프트 재계산을 줄입니다.
턴키 최적화 배포: llm-d 및 NVIDIA Dynamo를 사용하는 에이전트 워크로드에 대해 Google Cloud가 권장하는 성능 최적화 레시피는 AI-Hypercomputer/gpu-recipes, llm-d 저장소, Gemini 플랫폼의 Model Garden에서 클릭 몇 번으로 사용할 수 있습니다.

*고객 벤치마킹 기준

추론을 확장하려면 시스템 수준의 최적화가 필요

에이전트 코딩 및 도구 사용을 위한 모델을 평가할 때 추론 효율성은 두 가지 고유한 계층에서 결정됩니다. 첫 번째는 모델이 얼마나 효율적으로 추론하는지, 두 번째는 서빙 시스템이 멀티턴 루프를 얼마나 효율적으로 실행하는지입니다.

모델 수준 효율성: Reflection의 Beam

Reflection은 텍스트 네이티브 소프트웨어 엔지니어링과 다단계 도구 사용에 특화된 Beam을 설계했습니다. Beam은 총 약 5, 010억 개의 파라미터를 갖추고 있으며, 토큰당 약 230억 개의 파라미터를 활성화하고 약 100만 개의 토큰 컨텍스트 윈도우를 지원합니다. Beam은 Reflection의 Mirror CLI, Claude Code, Hermes, OpenCode 등 개발자가 이미 사용 중인 코딩 하네스에 직접 통합되어 GitHub 문제를 해결하고, CLI 및 DevOps 워크플로를 실행하고, 장기 작업을 완료할 수 있습니다.

Beam은 토큰당 230억 개의 파라미터만 활성화하고 다른 유사한 개방형 가중치 모델보다 3~4배 적은 추론 토큰을 사용하여 솔루션에 도달하므로 각 추론 단계에 필요한 추론 시간 컴퓨팅을 크게 줄입니다.

시스템 수준 효율성: AI 하이퍼컴퓨터 최적화 서빙

개발자가 에이전트를 프로덕션에 배포하면 서빙 레이어에서 또 다른 병목 현상이 나타날 수 있습니다. 에이전트형 코딩 루프에서는 단일 세션에서 모델이 수십 번 호출됩니다. 코딩 하네스는 매 턴마다 새로운 파일 읽기, 코드 차이, 컴파일러 로그, 도구 출력을 공유 대화 기록에 추가하며, 이 기록은 수만 또는 수십만 개의 토큰으로 빠르게 증가합니다.

모델 자체가 각 턴에서 3~4배 더 적은 추론 토큰을 생성하더라도 턴 전반에 걸쳐 누적된 컨텍스트 윈도우로 인해 두 가지 주요 인프라 문제가 발생합니다.

첫째, 프리필 컴퓨팅이 병목 현상을 일으킵니다. 표준 Kubernetes 부하 분산기는 스테이트리스(Stateless) 라운드 로빈 라우팅을 사용하여 요청을 분산합니다. 코딩 하네스가 세션의 15번째 턴을 전송하면 14번째 턴과는 다른 복제본에 도달하는 경우가 많습니다. 이 복제본은 이전 프롬프트 전체를 처음부터 다시 계산해야 하므로 GPU 컴퓨팅이 낭비되고 긴 프리필 큐가 생성되어 다른 사용자까지 지연시킵니다.

둘째, 디코딩은 KV 캐시 용량으로 인해 병목 현상이 발생합니다. 수십 개의 동시 에이전트 세션에 대해 긴 컨텍스트 KV 캐시를 유지하면 GPU 고대역폭 메모리(HBM)가 빠르게 가득 찹니다. HBM이 가득 차면 서빙 엔진은 오래된 KV 블록을 제거해야 합니다. 이러한 블록이 제거되는 즉시 캐시 적중률이 떨어지고 GPU 처리량이 정체됩니다.

클러스터 규모에서 Beam의 모델 수준 효율성을 유지하려면 서빙 스택을 분산 시스템으로 최적화해야 합니다. 이러한 이유로 Google Cloud의 레시피는 Beam을 llm-d(vLLM 사용) 및 NVIDIA Dynamo(SGLang 사용)와 결합합니다.

AI 하이퍼컴퓨터 추론 아키텍처 내부

Beam의 BF16, FP8, NVFP4 체크포인트를 출시 첫날부터 최대 효율로 실행할 수 있도록 Google Cloud는 AI 하이퍼컴퓨터에 수직 통합 아키텍처를 설계했습니다. 이 아키텍처에서는 각 계층이 에이전트형 서빙 수명 주기의 특정 부분을 처리합니다.

에이전트 트래픽 서빙을 위한 시스템 최적화 아키텍처

추론 포드를 스테이트리스(Stateless) 엔드포인트로 취급하는 대신 스택의 각 레이어는 멀티턴 에이전트 수명 주기를 중심으로 공동 설계됩니다.

프리픽스 및 부하 인식 라우팅(GKE + llm-d EPP/Dynamo 라우터): 작업자 포드 전반에서 캐시된 프리픽스와 큐 깊이를 추적하여 코딩 하네스의 각 후속 턴을 웜 KV 프리픽스를 보유한 복제본으로 유도하는 동시에 턴 우선순위 흐름 제어를 통해 큐 포화를 방지합니다.
분산 컴퓨팅 및 추측 디코딩(A4X Max 및 G4 인스턴스): 기본 Blackwell NVFP4, Beam의 230억 개 활성 전문가를 위한 전문가 병렬 처리(EP), 데이터 병렬 어텐션, DFlash2 추측 디코딩을 통해 vLLM 및 SGLang을 실행합니다. 프리필 및 디코딩 (P/D)풀을 분리하면 대량의 프롬프트가 급증해도 활성 토큰 생성이 중단되지 않습니다.
계층형 KV 캐시(GPU 메모리 -> DRAM 및 로컬 SSD): 활성 KV 블록은 고대역폭 GPU 메모리(Tier 1)에 유지되는 반면, 장기 세션 중에 제거된 웜 KV 블록은 vLLM의 OffloadingConnector 또는 SGLang의 HiCache를 통해 호스트 CPU DRAM 및 로컬 NVMe SSD(Tier 2)로 오버플로됩니다. 이를 통해 과거 컨텍스트를 처음부터 다시 계산하는 대신 밀리초 단위로 가져올 수 있습니다.

멀티턴 에이전트형 워크로드를 위한 시스템 최적화

동시 실행 수준이 증가하는 상황에서 AgentX 궤적 데이터 세트와 같은 멀티턴 코딩 및 도구 사용 워크로드를 서빙할 때, 서빙 스택의 각 레이어는 에이전트 워크로드의 멀티턴, 긴 컨텍스트 트래픽 패턴에 대한 성능 향상 및 지연 시간 개선에 기여합니다.

차트를 읽을 때 유의할 점이 있습니다. 두 구성은 서로 직접 비교할 수 없습니다. NVIDIA Dynamo는 NVIDIA GB300 NVL72 GPU 32개가 탑재된 A4X Max 인스턴스에서 실행되었고, llm-d는 NVIDIA RTX PRO 6000 GPU 8개가 탑재된 G4 VM에서 실행되었습니다. 각 차트는 동일한 하드웨어에서 기준 구성 대비 성능이 얼마나 향상되었는지 보여줍니다. 복제본이 많을수록 라우터가 적중할 수 있는 웜 KV 캐시가 많아지고 디코딩에서 프리필을 분할할 수 있는 공간이 늘어나므로 배포 규모가 커질수록 개선 효과가 커집니다. llm-d와 NVIDIA Dynamo는 모두 기본 인프라에 맞게 확장 및 축소됩니다.

NVIDIA Dynamo 최적화 성능과 Reflection Beam의 기준 배포 비교

llm-d 최적화 성능과 Reflection Beam의 기준 배포 비교

두 플랫폼 모두에서 이러한 최적화를 계층화하면 파레토 프런티어가 개선되어 더 높은 출력 처리량과 더 빠른 사용자당 상호작용 속도를 동시에 달성할 수 있습니다.

기준 배포(스테이트리스(Stateless) 라운드 로빈 라우팅): 접두사를 인식하지 않는 표준 Kubernetes 배포에서는 동일한 코딩 세션의 연속적인 턴이 서로 다른 복제본에 전달됩니다. 이로 인해 이전 컨텍스트에 대한 프리필 재계산이 지속적으로 이루어지고 동시 실행이 확장됨에 따라 처리량이 정체됩니다.
KV 캐시 인식 및 흐름 제어 라우팅: NVIDIA Dynamo 또는 llm-d의 Sticky EPP에서 턴 우선순위 흐름 제어와 함께 프리픽스 인식 라우팅을 사용 설정하면 멀티턴 에이전트 궤적이 웜 KV 캐시를 보유한 복제본에 고정되어 최초 토큰 생성 시간(TTFT) 지연 시간이 즉시 단축되고 GPU 컴퓨팅이 확보되어 토큰 처리량이 크게 증가합니다.
호스트 DRAM 및 로컬 SSD(LSSD) KV 오프로드: 제거된 KV 블록을 GPU 메모리에서 호스트 DRAM 및 로컬 NVMe SSD로 오프로드하면 수십 개의 긴 컨텍스트 코딩 세션이 기기 내 GPU 메모리 용량을 초과하더라도 캐시 스래싱을 방지할 수 있습니다.
분할 서빙, 추측 디코딩, KV 풀 조정: 하이브리드 KV 캐시 메모리 할당을 조정하고, 추측 디코딩을 사용 설정하고, 프리필 및 디코딩 작업자를 분리하면 토큰 생성이 과도한 프롬프트 버스트로부터 격리되는 한편, 드래프트 모델이 출력 처리량을 크게 높여 에이전트당 토큰 상호작용 속도를 빠르게 유지합니다.

PyTorchCon 및 GTC Berlin에 참석하여 시작해 보세요

이 블로그에서는 시스템 수준 최적화를 활용하여 에이전트 워크로드에 Reflection의 Beam 모델 제품군을 서빙할 때 성능을 확장하는 방법을 살펴봤습니다. 이 게시물에서 소개한 모든 Kubernetes 매니페스트, 라우터 구성, 벤치마킹 스크립트는 오픈소스이며 자체 GKE 클러스터에서 바로 실행할 수 있습니다.

최적화된 스택 배포: AI-Hypercomputer/gpu-recipes 저장소에서 A4X Max 및 G4에 llm-d 및 NVIDIA Dynamo를 사용하여 Reflection의 Beam을 실행하는 출시 당일 지원 가이드와 Gemini 플랫폼의 Model Garden을 살펴보세요.
가중치 다운로드: Reflection의 Hugging Face 페이지에서 Apache 2.0 BF16, FP8, NVFP4 체크포인트를 다운로드하세요.
산호세에서 열리는 llm-d 및 PyTorch Conference 참석: 올해 10월 산호세에서 열리는 PyTorch Conference North America에 참석하신다면 llm-d 커뮤니티 세션과 Google Cloud 부스 #에 방문해 보세요. 에이전트 워크로드를 위한 KV 캐시 인식 라우팅, P/D 분리, KV 캐시 계층화에 대한 라이브 데모를 선보일 예정입니다.
NVIDIA GTC Berlin 참석: NVIDIA GTC Berlin에 참석하신다면 부스 3026 또는 행사장으로부터 도보로 5분 거리에 있는 w3.hub의 Google Cloud Hub에서 Google Cloud 팀을 만나보세요. 세션에 대해 자세히 알아보세요.

Cloud Run의 Temporal 서버리스 작업자: 수요에 앞서 작업자 확장

Thu, 22 Oct 2026 17:00:00 +0000

오픈소스 Temporal 실행 플랫폼은 최신 소프트웨어 인프라의 기반 레이어로 빠르게 자리 잡고 있으며, 특히 분산 시스템과 AI 에이전트 워크로드의 조정에 많이 사용되고 있습니다. 하지만 Temporal에서 작업자를 배포하고 확장하는 데는 고유한 어려움이 따릅니다. 작업자는 요청을 처리하는 대신 작업을 폴링하므로 요청 기반 서버리스 플랫폼과 잘 맞지 않을 수 있습니다. 이로 인해 Kubernetes 또는 VM에서 작업자 Fleet을 실행해야 하는 경우가 많으며, 이는 지속적 관리와 비용 지불을 필요로 합니다. 측정항목 파이프라인을 빌드하고 자동 확장 트리거를 조정해도 측정항목 지연으로 인해 확장이 버스트를 따라가지 못합니다. 배포할 때마다 업그레이드와 버전을 관리해야 하며, 큐에 작업이 있든 없든 컴퓨팅 비용을 지불해야 합니다.

Google Cloud는 바로 이러한 풀 기반 작업을 위해 Cloud Run 작업자 풀을 빌드했습니다. 인스턴스가 큐 또는 스트림에 연결하고 다음 항목을 가져와 처리합니다. 오늘부터 Temporal 오픈소스 플랫폼의 완전 관리형 버전인 Temporal Cloud가 이를 대신 확장해 드립니다. 현재 프리뷰 버전으로 제공되는 Cloud Run의 Temporal 서버리스 작업자를 사용하면 작업자를 작업자 풀로 배포할 수 있으며, Temporal은 태스크 큐의 작업에 맞게 풀의 크기를 조정합니다. 작업이 없을 때는 풀을 0으로 축소할 수 있습니다. 실행할 클러스터나 자동 확장 처리가 없으며, 작업자 코드는 동일하게 유지됩니다.

Cloud Run 작업자 풀이 Temporal과 연동되는 방식

작업자 풀은 지속적인 백그라운드 작업을 위한 Cloud Run의 리소스입니다. 공개 엔드포인트가 없으며 각 인스턴스에는 전체 수명 기간에 걸쳐 CPU가 할당되므로 Temporal 작업자가 실행되는 방식과 일치합니다. Temporal은 다음과 같이 Cloud Run 작업자 풀을 관리합니다.

Temporal 작업자는 프로젝트에서 Cloud Run 작업자 풀 인스턴스로 실행되며 Temporal Cloud에서 작업을 폴링합니다.
Temporal Cloud는 태스크 큐를 추적하고 사용자가 부여한 IAM 권한을 사용하여 Cloud Run Admin API를 통해 작업자 풀의 인스턴스 수를 설정합니다. Temporal은 어떤 경우에도 인스턴스에 대한 연결을 열지 않으므로 포트를 열거나 방화벽 규칙을 추가할 필요가 없습니다.
각 빌드 버전을 자체 Cloud Run 작업자 풀로 실행합니다. 이전 빌드의 작업자 풀은 해당 빌드에서 시작된 워크플로에 다시 필요할 때까지 인스턴스 없이 유지될 수 있습니다.

Temporal 작업자는 프로젝트, 서비스 계정, 네트워크에서 실행되며, 실행할 작업자 수는 Temporal이 결정합니다.

Temporal 서버리스 작업자로 빌드할 수 있는 항목

Cloud Run 작업자 풀과 Temporal 서버리스 작업자를 결합하면 다음과 같은 다양한 흥미로운 사용 사례를 실현할 수 있습니다.

자동 확장되는 에이전트 작업자: AI 에이전트는 LLM 추론 및 도구 호출의 다단계 체인을 실행합니다. 여기서 Temporal의 내구성 있는 실행과 Cloud Run 작업자 풀이 함께 작동합니다. Temporal 작업자는 즉시 가동되어 LLM 단계, 임베딩 또는 API 호출의 급증을 처리한 다음 큐가 비면 0으로 축소됩니다. 작업자는 키 없이 Google Cloud AI API에 액세스할 수 있습니다. 추론을 위해 GPU를 연결할 수도 있으며, GPU에 연결된 작업자 역시 0으로 확장됩니다. Temporal은 각 모델 및 도구 호출을 내구성 있는 활동으로 실행합니다. 작업자가 단계 중간에 사라지면 활동이 다른 작업자에서 재시도되고 워크플로는 계속됩니다.

장기 실행 워크플로: Temporal 워크플로는 무기한 실행될 수 있으므로 장기간에 걸쳐 실제 리소스의 상태를 추적하는 애플리케이션을 빌드할 수 있습니다. 이 패턴은 일반적으로 '항목 패턴'이라고 합니다. 워크플로가 일부 항목의 상태를 나타내기 때문입니다. 하지만 이러한 장기 실행 워크플로는 일반적으로 일관된 컴퓨팅 요구사항이 없습니다. 개별 단계 중 일부는 짧고 일부는 길며, 워크플로가 절전 모드 상태에서 사람이나 다른 시스템과 같은 외부 입력을 기다리는 경우도 있습니다. Cloud Run 작업자 풀은 이 패턴을 지원하는 유연한 컴퓨팅을 제공합니다. 개별 단계는 필요한 시간만큼 실행될 수 있으며, Temporal은 수행할 작업이 없을 때 작업자 풀을 자동으로 축소합니다.

버스트 일괄 작업: 작업자 풀은 인스턴스가 실행되는 동안에만 비용을 청구하므로 일괄 실행 사이에 유휴 상태인 작업자 풀은 인스턴스가 0개인 동안 비용이 발생하지 않습니다. 결제 실행이나 미디어 트랜스코딩과 같은 작업의 경우, Temporal은 배치가 도착하면 풀을 확장하고 큐가 비워지면 다시 축소합니다. 최대 인스턴스 수는 비용을 지불하는 인스턴스 수를 제한합니다. 이 용량을 초과하는 작업은 삭제되지 않고 큐에서 대기합니다.

Temporal 작업자에 Cloud Run 작업자 풀을 사용해야 하는 이유

이전에는 Cloud Run 서비스에서 Temporal 작업자를 실행하려면 몇 가지 우회적 방법을 사용해야 했습니다.

컨테이너가 포트에서 리슨할 것으로 서비스가 예상하기 때문에 HTTP 리스너 필요
인스턴스 기반 결제 방식으로 작업자가 요청 간에 CPU를 유지
최소 인스턴스 수가 필요해 서비스가 0으로 축소되지 않음

Cloud Run 작업자 풀에서 Temporal 작업자를 실행하면 더 이상 이러한 우회적 방법이 필요하지 않으며 다음과 같은 이점을 누릴 수 있습니다.

관리할 엔드포인트가 없습니다. 잠글 공개 URL이나 부하 분산기가 없으며 구현할 상태 점검 포트도 없습니다.
더 저렴한 가격으로 안정적인 CPU 사용량을 확보할 수 있습니다. 인스턴스가 유휴 상태가 되거나 제한되지 않습니다. Cloud Run은 인스턴스가 유휴 상태로 보인다고 해서 인스턴스를 삭제하지 않으므로 Temporal이 단독으로 풀 축소 시점을 결정합니다. 작업자 풀은 인스턴스 기반 결제 방식의 Cloud Run 서비스보다 vCPU 시간 및 GB 시간당 약 40% 저렴합니다.
버전 변동 없이 확장할 수 있습니다. 인스턴스 수를 변경해도 새 버전이 생성되지 않으므로 Temporal은 부하가 변경될 때마다 풀의 크기를 조절할 수 있습니다.

Temporal이 작업자 풀의 확장 및 버전 관리를 처리하는 방식

Temporal은 작업이 태스크 큐 백로그에 도착하는 시점과 작업자가 이를 처리하기 시작하는 시점 사이의 지연이라는 하나의 주요 신호를 사용하여 용량 추가 시점을 결정합니다. 이 지연 시간이 늘어나면 사용 가능한 작업자가 포화 상태에 이른 것입니다. 확장은 다음과 같이 이루어집니다.

서버 측 감지: Temporal 서버는 각 태스크 큐의 백로그-작업자 지연 시간을 추적합니다.
푸시 알림: 지연 시간이 트리거 조건을 초과하면 서버가 작업자 컨트롤러 인스턴스에 푸시 알림을 보냅니다.
프로비저닝: 작업자 컨트롤러가 작업자 풀에 용량을 추가합니다. 새 인스턴스는 작업을 폴링하기 전에 시작하고 연결하는 데 시간이 걸리므로 용량이 신호보다 지연됩니다.

Temporal은 여유 용량을 유지하므로 작업이 쌓인 후가 아니라 수요가 발생하기 전에 한발 앞서 풀이 확장됩니다. 수평 축소는 좀 더 보수적입니다. Temporal은 마지막으로 작업에서 사용 가능한 작업자를 찾지 못한 시점 이후 안정화 기간(기본값: 90초) 동안 대기하며, 연속적인 축소 사이에 일시중지합니다. Cloud Run의 구성 가능한 단계적 종료는 종료 시간을 10초에서 10분으로 연장합니다. 이렇게 하면 SIGTERM 인식 작업자가 작업을 완료하거나 체크포인트를 생성할 시간을 확보할 수 있습니다. 인스턴스 수는 사용자가 설정한 최솟값과 최댓값 사이로 유지됩니다. 유휴 기간 후 첫 번째 작업이 인스턴스가 시작될 때까지 기다릴 수 없는 경우 최솟값을 0보다 크게 설정합니다.

실행 중인 작업을 중단하지 않고 새로운 워크플로 코드를 배포하는 것은 어려운 일입니다. Temporal 워크플로는 스테이트풀(Stateful)이며 결정론적이기 때문에 실행 중에 코드를 교체하면 비결정론적 오류가 발생합니다. Cloud Run의 서버리스 작업자는 Temporal 작업자 버전 관리를 필수 적용하여 이 문제를 해결합니다. 조건부 분기를 사용하여 코드를 패치해서는 안 됩니다. 대신 각 작업자 배포 버전을 deploymentName 및 buildId로 식별되는 자체 작업자 풀 배포로 배포합니다. 별도의 작업자 풀을 사용하면 두 가지 문제가 해결됩니다.

특정 작업자 배포 버전에서 시작된 워크플로는 해당 버전에서 계속 실행되고 완료됩니다.
각 작업자 배포 버전은 개별적으로 확장 및 소모되어 컴퓨팅 지출과 사용률을 애플리케이션의 요구사항에 맞게 조정합니다. 기존 워크플로가 이전 작업자 배포 버전에서 완료되고 소모되면 기본 작업자 풀은 결국 자동으로 0으로 축소됩니다.

각 워크플로 유형에 대한 버전 관리 동작을 설정하거나 작업자 수준 기본값을 설정하세요.

PINNED: 워크플로가 시작된 작업자 버전(빌드 ID)을 유지하고 해당 버전에서 완료됩니다. 단기 실행 워크플로, 주문 처리, 다단계 API에 가장 적합합니다.
AUTO_UPGRADE: 워크플로를 출시하면 새로운 '현재' 또는 '대상' 작업자 배포 버전으로 이동합니다. 구독 결제 또는 몇 주에 걸쳐 실행되는 작업과 같은 장기 실행 워크플로에 가장 적합합니다.

작업자 버전 관리 구성에 대해 자세히 알아보려면 여기를 참고하세요.

시작하기

설정은 세 단계로 진행됩니다.

Temporal 작업자를 컨테이너화하고 컨테이너를 Cloud Run 작업자 풀로 배포합니다. 이때 풀 이름에 빌드 ID를 포함합니다. Temporal API 키와 같은 사용자 인증 정보를 Secret Manager에 보관합니다.
Temporal Cloud에 작업자 풀을 관리할 수 있는 권한을 부여하여 Temporal을 작업자 풀에 연결하면 작업자 풀을 확장할 수 있습니다.
Temporal에서 풀의 프로젝트, 리전, 이름을 가리키는 작업자 배포 버전을 만듭니다.

Cloud Run의 Temporal 서버리스 작업자는 프리뷰 버전이므로 안정화 버전 출시 전에 API 및 구성이 변경될 수 있습니다. 시작하려면 다음 단계를 따르세요.

Cloud Run의 서버리스 작업자가 어떻게 버전을 확장하고 처리하는지 알아보세요.
설정 가이드를 참고하여 첫 번째 작업자를 배포하세요.
CPU, 메모리, GPU, 네트워킹 옵션은 Cloud Run 작업자 풀을 참고하세요.
구성 가능한 단계적 종료 미리보기 버전을 신청하여 사용해 보세요.

9월 AI 인프라 및 조정 기능에 관한 새로운 소식

Tue, 13 Oct 2026 11:00:00 +0000

9월은 확장성의 달입니다. 전 세계가 에이전트형 Fleet의 급증에 대비하고 있는 가운데, Google Cloud는 이러한 수요에 원활하고 신속하게 대응하기 위해 AI 인프라 및 조정 제품을 강화하는 동시에 워크로드 격리와 보안을 유지하고 비용을 관리하고 있습니다. 이러한 개선사항이 Google Cloud의 컴퓨팅, 네트워크, 스토리지, 조정 제품 전반에 어떻게 반영되는지, 고객이 Google Cloud AI 인프라를 사용하는 새로운 방법, Google 전략에 대한 서드 파티 업계 검증에 대해 자세히 알아보세요.

제품, 기술, 도구 업데이트

Google Kubernetes Engine 업데이트: GKE팀은 플랫폼의 확장성을 개선하는 데 주력하고 있으며, 9월에는 다양한 형태와 규모의 개선사항이 적용되었습니다.

새로운 기능: 에이전트 워크로드에 더 높은 밀도의 실행 런타임이 필요하신가요? Google Cloud는 표준 컨테이너 런타임보다 10배 더 높은 밀도로 수백만 개의 샌드박스를 실행할 수 있도록 새로운 오픈소스 GKE Agent Substrate를 설계했습니다. 또한 Agent Substrate는 네이티브 제로 트러스트 커널 및 네트워크 격리 기능을 바탕으로 초당 500회 이상의 일시중지/재개 활성화 요청 처리 시에도 500ms 미만의 재개 성능을 제공합니다.
제품 업데이트: 이제 GKE에 Scale-to-zero 기능이 기본 제공됩니다. 자동 확장 측정항목이 포함된 HPA와 KEP-2021 지원 덕분에 워크로드를 축소하는 데 복잡한 구성요소를 구성할 필요가 없습니다. 블로그를 읽고 자세히 알아보세요.
제품 업데이트: 또한 GKE HPA(위에서 언급한 자동 확장 측정항목 사용)를 사용하면 이제 표준 측정항목 외에도 커스텀 PromQL 측정항목을 기반으로 확장 및 축소할 수 있으므로 비즈니스에 의미 있고 고유한 조건에 따라 워크로드를 트리거할 수 있습니다. 여기에서 자세히 알아보세요.
새로운 기능: 또 다른 확장성 기능은 GKE 포드 스냅샷으로, 이를 통해 CPU 및 GPU 메모리를 포함한 워크로드의 실행 상태를 저장하고 필요에 따라 복원할 수 있습니다. 내부 테스트에 따르면 GKE 포드 스냅샷 사용 시 AI 추론 시작 시간을 최대 89% 단축할 수 있습니다. 여기에서 자세히 알아보세요.
새로운 마이그레이션 도구: 마지막으로, AWS EKS에서 GKE로 컨테이너 워크로드를 마이그레이션하고 싶었지만 까다롭고 번거로운 엔지니어링 작업이 두려웠다면, Google Cloud가 최근 출시한 GKE 에이전트형 마이그레이션을 사용해 보세요. 이 도구는 불안정하고 임시적인 프롬프팅을 결정론적 가드레일로 보호되는 AI 지원 마이그레이션 파이프라인으로 대체하는 전용 에이전트 플러그인입니다. 에이전트 스킬과 로컬 모델 컨텍스트 프로토콜(MCP) 서버의 컴파일로 설계된 이 도구는 AI를 사용하여 복잡한 AWS EKS IaC 및 Kubernetes 매니페스트를 GKE 시작 영역으로 직접 변환합니다. 온보딩 가이드를 참고하여 시작하세요.
기능 업데이트: 강화 학습(RL) 및 평가 워크로드는 매우 까다롭습니다. 표준 에이전트형 RL 루프에서 LLM 정책은 GPU에서 코드 스니펫과 같은 작업을 생성하고 이를 격리된 CPU 샌드박스 내에서 실행하여 보상 신호를 관찰합니다. 그러나 수만 개의 동시 배포를 지원하도록 이 루프를 확장하면 유휴 상태의 가속기, 이미지 카디널리티, 포화 상태의 컨트롤 플레인과 같은 인프라 병목 현상이 발생합니다. 이를 위해 RL에 최적화된 GKE Agent Sandbox와 Agent Sandbox RL 조정 SDK, 인기 있는 RL Gym 및 하네스를 위한 기본 통합을 개발했습니다. 모두 정식 버전으로 제공되고 있으며 자세한 내용은 여기에서 확인할 수 있습니다.

스토리지 업데이트: AI는 많은 데이터를 학습하고 생성하며, 이러한 데이터는 블록 스토리지 시스템, 파일 시스템, 객체 스토어, 데이터베이스 등 어딘가에 저장되어야 합니다. Google Cloud는 이 중요한 레이어가 에이전트형 워크로드의 요구사항을 충족할 수 있도록 스토리지 포트폴리오의 개선사항을 발표했습니다.

제품 업데이트: Filestore 에이전트 볼륨은 에이전트형 워크로드를 위한 고성능의 탄력적인 영구 파일 스토리지를 제공합니다. GKE Agent Substrate 및 GKE 에이전트 샌드박스와의 긴밀한 통합 덕분에 Filestore 에이전트 볼륨은 전용 격리 파일 작업공간을 GKE 에이전트 샌드박스에 밀리초 단위로 자동 할당하고 연결합니다. 여기에서 프리뷰 액세스를 요청하세요.
새로운 제품: 생성형 AI 및 RAG 데이터 레이어(예: Milvus, Pinecone, Qdrant, Vespa, Redis, 인메모리 컨텍스트 캐싱)를 실행하는 경우, 주요 하이퍼스케일러 중 코어당 가장 높은 IOPS와 처리량을 제공하는 M4N VM 제품군(현재 정식 버전 출시됨)을 살펴보세요. Google Cloud의 커스텀 Titanium 오프로드 아키텍처 및 Hyperdisk Extreme과 결합된 M4N 인스턴스는 최대 25,000MiB/s(25GiB/s)의 집계 호스트 스토리지 성능과 최대 100만 IOPS를 제공합니다.
새로운 제품: 또 다른 새로운 Compute Engine 제품인 Z4D가 정식 버전으로 출시되었으며, 이는 AI/ML 학습 및 추론 워크로드를 위한 강력한 스토리지 솔루션입니다. 베어메탈 인스턴스로 구성된 Z4D는 에이전트형 마이크로 VM에 필요한 높은 로컬 SSD(LSSD) 용량과 짧은 지연 시간을 모두 제공하므로 호스트당 수천 개의 격리된 샌드박스를 기본 성능과 효율성으로 실행할 수 있습니다. 여기에서 Z4D 머신에 대해 자세히 알아보세요.
제품 업데이트: 오늘날의 AI 학습 및 추론 파이프라인은 대부분의 스토리지 관리 시스템이 대응할 수 있는 속도보다 더 빠르게 데이터를 생성하므로 스토리지 자산을 파악하려는 팀에 어려움을 초래합니다. 새로운 버전의 Storage Intelligence Advisor를 사용하면 '버킷에 무엇이 들어 있는지'에 대한 질문에 더 쉽게 답하고 예상치 못한 변경사항을 빠르게 식별할 수 있습니다. 또한 향상된 일괄 작업을 통해 버킷 전반에서 대량 변경사항을 자동화할 수 있습니다. 예를 들어 스토리지 클래스를 이동하거나, 오래되었거나 임시 데이터를 일괄 삭제하거나, 메타데이터, 태그 지정, 보관, 암호화 변경사항을 적용할 수 있습니다. 여기에서 Storage Intelligence Advisor의 최신 소식을 알아보세요.
새로운 제품: 마지막으로, 새로운 버전의 PostgreSQL용 AlloyDB는 선구적인 Google 인프라인 Colossus 분산 파일 시스템과 Jupiter 네트워크를 결합하여 에이전트 시대를 위한 타협 없는 새로운 데이터베이스 아키텍처를 지원합니다.

실무자 가이드 및 방법

방법: 전 세계에 흩어져 있는 GPU와 TPU를 단일 진입점 뒤에서 단일 풀로 작동하게 하고 싶으신가요? 이 블로그에서 그 방법을 알려드립니다. 에지에서는 멀티 클러스터 GKE Inference Gateway가 전역, 멀티 리전 트래픽 분산 및 고가용성에 중점을 둡니다. 그 아래에서는 LLM-d 라우터가 사용률을 높게 유지하는 복잡한 메모리 인식 예약 알고리즘을 처리합니다. 이 아키텍처는 의도적으로 런타임, 모델, 가속기와 무관하게 설계되었으며, 테스트에서는 멀티 클러스터 GKE Inference Gateway를 통해 트래픽을 라우팅할 때 추가된 오버헤드가 1% 미만이었습니다.
가이드: AI 모델 학습 또는 추론을 위해 TPU에서 GKE를 사용 중이거나 사용할 계획이신가요? 대규모 언어 모델(LLM)을 학습시키거나 높은 처리량의 추론 서빙을 실행하려면 Cloud TPU 및 GPU와 같은 특화된 AI 하드웨어에 상당한 투자가 필요합니다. 지출 비용을 최대한 활용하려면 GKE의 워크로드 수명 주기 측정항목을 이해해야 합니다. 이 상세 가이드에서는 불투명한 클러스터 동작을 활용 가능한 원격 분석으로 전환하는 방법을 설명합니다.

고객 및 파트너 업데이트

GKE 고객: 게임 스타트업 SeaVerse가 멀티 테넌트 워크로드에 GKE 에이전트 샌드박스를 사용하는 이유와 이 플랫폼을 통해 인프라 비용을 60% 절감한 방법을 알아보세요.

연구, 보고서, 심층 분석

혹시 놓치셨을까 봐 알려드리자면, Google은 Gartner와 Forrester의 주요 분석 보고서 3개에서 제품 또는 전략 부문 최고 점수를 획득하는 등 리더로 선정되었습니다.

Google, The Forrester Wave™: 2026년 3분기 퍼블릭 클라우드 플랫폼 부문 리더로 선정: 모든 클라우드 제공업체 중 가장 높은 종합 점수 획득
Google, 2026년 Gartner® Magic Quadrant™의 전략적 클라우드 플랫폼 서비스 부문에서 리더로 선정: 평가 대상 공급업체 중 '비전의 완전성' 부문에서 가장 선도적인 업체로 선정되었습니다.
Google, 2026년 Gartner Magic Quadrant의 컨테이너 관리 부문에서 리더로 선정: 평가 대상 공급업체 중 '실행 능력' 면에서 가장 높은 순위를 차지했습니다.
Google Cloud는 전 세계 GPU 제공업체의 안정성, 성능, 지원, 가격, 보안을 평가하는 최신 SemiAnalysis ClusterMax 3.0 보고서에서 골드 등급을 받았습니다. 자세한 내용은 보고서 전문을 참고하세요.

2026년 8월

제품, 기술, 도구 업데이트

제품 변경사항: Google Cloud의 퍼스트 파티 보안 확장형 NFS 파일 서비스인 Filestore는 AI 및 에이전트 워크플로를 위한 인기 스토리지 플랫폼으로 부상했으며, 이제 Google의 기본 분산 스토리지 시스템인 Colossus를 기반으로 직접 빌드된 새로운 백엔드 스토리지 계층을 통해 이 작업에 더욱 최적화된 성능을 제공합니다. 이 새로운 백엔드를 사용하면 스토리지 용량과 독립적으로 IOPS를 프로비저닝할 수 있으며 GKE와 긴밀하게 통합됩니다. AI 환경에서는 공통 데이터 세트를 읽고 써야 하는 대규모 에이전트 그룹인 이른바 에이전트형 스웜을 성능 저하 없이 서비스하는 데 도움이 될 수 있습니다. 자세한 내용은 블로그 게시물을 참고하세요.
새로운 기능: 이제 GKE의 분산 Ray 클러스터에서 gVisor 샌드박스를 사용할 수 있습니다. Google은 Anyscale과의 파트너십을 통해 Google의 오픈소스 애플리케이션 커널인 gVisor를 분산 Ray 클러스터에 직접 통합할 수 있는 Ray용 실험용 라이브러리를 선보였습니다. gVisor는 일반 컨테이너보다 강력한 격리 기능을 제공하면서도, 가벼운 환경 덕분에 빠른 시작 시간과 낮은 메모리 오버헤드라는 장점까지 모두 갖추고 있습니다. GKE에서 이러한 샌드박싱 기능을 사용해 보려면 Ray 샌드박싱 사용자 가이드를 참고하세요.
제품 변경사항: 개인용 AI 에이전트를 실행할 고성능의 사용하기 쉬운 인프라를 찾고 계신가요? 하지만 비용 부담은 줄이고 싶으시다면 주목해 주세요. 새로운 Cloud Run 인스턴스는 Cloud Run의 전용 싱글톤 컴퓨팅 런타임으로, 에이전트가 유휴 상태일 때도 종료되지 않습니다. 더욱 놀라운 점은 1개의 vCPU와 1GiB 메모리 사양의 Cloud Run 인스턴스를 30일 내내 중단 없이 실행해도 비용이 단돈 $5.70에 불과하다는 것입니다.

실무자 가이드, 문서, 방법

안내 가이드: 모델 컨텍스트 프로토콜(MCP) 분야의 중요한 소식입니다. 2026년 7월 28일 사양을 기준으로 프로토콜 코어는 '완전히 스테이트리스(Stateless)입니다. 핸드셰이크는 이제 필요 없습니다. 초기화 / 초기화 완료 핸드셰이크(SEP-2575)와 논리적 Mcp-Session-Id 헤더(SEP-2567)가 완전히 사라졌습니다. 대신 이제 모든 요청이 자체 설명적이고 독립적으로 이루어집니다.' 정말 놀랍지 않은가요? Google Developers 블로그에서 최신 MCP 사양의 변경사항과 구현 방법을 자세히 알아보세요.
가이드: 실시간 AI 시스템은 기존 네트워크 부하 분산 기법을 무력화합니다. '백엔드는 고립된 요청을 처리하는 대신 지속적으로 실시간 양방향 스트림을 관리해야 합니다. 오디오 청크, 스크립트, 모델 출력, 합성 음성이 동시에 끊임없이 오가기 때문입니다.' 사용자가 개입하면 상황은 더 복잡해집니다. '서버는 현재 진행 중인 음성 생성을 즉시 중단하고, 컨텍스트를 업데이트하도록 전환하고, 새로운 도구를 트리거하고, 다른 대답을 작성하기 시작해야 합니다. 이 모든 작업은 연결을 끊지 않고 수행되어야 합니다.' AI 시대에 부하를 관리하는 새로운 접근 방식에 대해 알아보려면 세션 인식 부하 분산으로 실시간 AI 에이전트 확장하기를 읽어보세요.
방법: 다양한 GPU 가속기를 혼합하여 사용하더라도 GKE에서 탄력적이고 확장 가능한 LLM 추론 플랫폼을 빌드하는 방법을 알아봅니다. 제안된 아키텍처는 Capacity Advisor와 Compute Advisor 외에도 RunAI:model streamer나 병렬 다운로드를 지원하는 GCPFuse와 같은 고성능 스토리지를 결합합니다. 자세한 내용은 여기에서 확인하세요.
문서: GPU 또는 TPU가 있는 호스트의 경우 라이브 마이그레이션을 사용하여 업데이트할 수 없으므로 유지보수 문제가 발생합니다. 이 새로운 문서 페이지에서 학습 및 추론 워크로드의 다운타임 허용 범위에 따라 가속기가 장착된 호스트를 업데이트하는 방법을 알아보세요.
문서: Advanced Compute Images(ACI)는 AI/ML 및 HPC 인프라를 위한 표준화된 이미지 스택이므로 커스텀 이미지를 수동으로 빌드할 필요가 없습니다. 이 새로운 문서 페이지에서 Google Cloud CLI, 콘솔 또는 SchedMD의 Slurm 워크로드 관리자를 사용하여 ACI 이미지를 만드는 방법을 알아보세요.
가이드: AI 워크로드는 설계하기가 어렵고, 리소스 집약적이며, 버스트가 발생하기 쉬운 것으로 알려져 있습니다. 이로 인해 확장 병목 현상이 발생하고 활용도가 낮거나 잘못 활용되는 컴퓨팅 리소스가 대량으로 발생할 수 있습니다. 새로운 블로그에서는 Google Cloud에서 동적 용량 관리를 달성하는 세 가지 주요 방법을 간략하게 설명합니다. 1) 계획된 다운타임에 대한 용량 예약, 2) 계획되지 않은 다운타임에 대한 자동화된 대체 용량 유지, 3) GKE의 핵심 조정 기능을 활용한 리소스 할당 자동화입니다.

고객 및 파트너 업데이트

비즈니스 조정 소프트웨어 제공업체인 UiPath는 급증하는 워크로드를 처리하고 있었으며, 비용을 더 예측 가능하게 만들고 싶었습니다. 이를 위해 인프라를 재설계하여 고립된 클러스터에서 공유 Google Cloud GPU Fleet으로 전환했습니다. 여기에는 학습을 위한 A3 VM 인스턴스(NVIDIA H100 GPU)와 추론을 위한 G4 VM 인스턴스(NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU)가 모두 포함되었습니다. 아키텍처에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
AI 개발 가속화에 주력하는 첨단 AI 연구소인 Mirendil은 모델 사전 학습 및 사후 학습 애플리케이션을 지원하기 위해 TPU와 NVIDIA GPU를 모두 갖춘 AI 하이퍼컴퓨터를 사용하고 있다고 발표했습니다.
소매 CRM 제공업체인 Replenit은 BigQuery, Gemini Enterprise Agent Platform, Cloud TPU에서 실행되는 오픈소스 Gemma 모델을 사용하여 Google Cloud에서 AI 의사 결정 엔진을 빌드했습니다. Replenit의 발표에 따르면, 이 조합을 통해 이전 클라우드 제공업체 대비 파이프라인 비용을 90%나 절감할 수 있었습니다. 자세한 내용은 우수사례 전문을 읽어보세요.
Malachyte는 Bigtable, Managed Service for Apache Kafka, Pub/Sub, Compute Engine, GKE를 기반으로 AI 기반 이커머스 추천 플랫폼을 설계했습니다. 이 블로그에서 이 모든 것이 어떻게 결합되는지 확인해 보세요.

2026년 7월

제품, 기술, 도구 업데이트

제품 변경사항: Google Cloud Managed Lustre가 정식 버전(GA)으로 출시되었습니다. 이제 용량 TiB당 125MB/s부터 250MB/s, 500MB/s, 최대 1,000MB/s까지 네 가지 성능 등급의 처리량을 선택할 수 있으며, 스토리지 용량을 최대 8PB까지 확장할 수 있습니다. Managed Lustre 솔루션은 DDN의 EXAScaler를 기반으로 하며, 고성능 스토리지 분야에서 수십 년간 쌓아온 DDN의 리더십과 Google Cloud의 클라우드 인프라 전문성이 결합된 결과물입니다.
제품 변경사항: C4N 네트워크 및 스토리지 최적화 VM 정식 버전 출시. C4N은 데이터 전송 병목 현상을 제거하기 위해 빌드된 Google Cloud 최초의 네트워크 및 블록 스토리지 최적화 VM 시리즈입니다. 5세대 Intel Xeon 확장 가능 프로세서로 구동되고 Google의 Titanium 오프로딩 하드웨어를 기반으로 빌드된 이 제품은 Hyperdisk Extreme과 함께 사용할 때 400Gbps의 네트워크 대역폭, 초당 9,500만 패킷(MPPS), 최대 25GiB/s의 블록 스토리지 처리량을 구현합니다.
새로운 기능: 네트워크 정책이 적용된 최대 15,000개 노드 규모의 GKE Dataplane V2(GA). 이 기능을 사용하면 표준 GKE 클러스터를 최대 15,000개 노드까지 확장하면서도 전체 활성 네트워크 정책 적용을 유지할 수 있어 대기업 및 AI/ML 고객의 대규모 인프라 요구사항을 지원할 수 있습니다.
새로운 기능: llm-d의 협력적 타임 슬라이싱. 강화 학습(RL) 워크로드를 실행하는 경우, 이제 독립적인 RL 작업을 공유 물리적 하드웨어에 인터리브 처리할 수 있어 모델 수렴이나 정확도에 영향을 주지 않으면서 가속기의 총 가동 주기를 기준치인 약 40%에서 최대 70%까지 늘릴 수 있습니다.
새로운 AI 보안 도구: GKE에서 AI 공급망을 보호하고, AI 워크로드를 안전하게 배포하고, 섀도 AI를 줄이고 싶으신가요? Google은 컨테이너 클러스터를 지속적으로 모니터링하여 실행 중인 AI 런타임(예: vLLM 및 Triton)을 자동으로 감지하고 표준 CycloneDX 머신러닝 자재 명세서(ML-BOM)를 생성하는 가볍고 권한이 없는 Kubernetes 컨트롤러인 k8s-aibom을 오픈소스로 공개했습니다. k8s-aibom 프로젝트를 확인하고 참여해 보세요.

실무자 가이드 및 방법

안내 가이드: 7월 27일, Google은 2.8조 파라미터를 가진 개방형 가중치 모델인 Moonshot AI의 Kimi K3에 대해 가중치가 공개된 당일부터 즉각적인 지원을 시작한다고 발표했습니다. Model Garden, 커스텀 조정, llm-d 레시피가 포함된 GKE 등 선호하는 배포 경로에 관계없이 이 가이드에서는 Google Cloud에서 Kimi K3를 평가하고 파일럿하는 데 도움이 되는 자세한 단계별 안내를 제공합니다.
안내 가이드: Google Kubernetes Engine(GKE) 관리형 DRANET은 GPU와 TPU를 모두 지원합니다. 이 구현을 활용하는 방법은 여러 가지가 있습니다. 사용자가 모든 권한을 갖는 표준 클러스터 방식과 Google이 복잡한 설정을 대신 처리해 주는 Autopilot 클러스터 방식 중에서 선택할 수 있습니다. 실무형 실습인 TPU, GKE 관리형 DRANET, Gemma 4를 사용하는 GKE Autopilot 클러스터에서 자세히 알아보세요.
안내 가이드: GPU가 아닌 TPU에서 Ray를 실행하는 방법을 알아봅니다. 이 2부작 시리즈의 1부에서는 TPU 슬라이스에 대해 설명하고(힌트: Ray는 이를 일정 예약이 가능한 또 다른 가속기로 간주함), Ray의 다양한 AI 라이브러리를 살펴봅니다 (2부).
안내 가이드: 기기가 이론적인 성능 사양을 달성하는지 정확하게 평가하고 특정 성능 격차 또는 아키텍처별 병목 현상을 식별하는 데 도움이 되는 새로운 마이크로벤치마크 제품군을 사용하여 샘플 워크로드에 대한 TPU를 평가합니다. 여기에서 자세히 알아보세요.
안내 가이드: 예산에 부담을 주지 않고 에이전트를 확장하세요. GKE 에이전트 샌드박스와 포드 스냅샷을 통해 GKE 조정을 사용하여 고정된 컴퓨팅 공간에 더 많은 에이전트를 안전하게 패킹하는 방법을 알아보세요. 성능 최적화와 비용 최적화 중 무엇을 목표로 하든, 에이전트 효율성을 극대화하기 위해 어떤 설정을 어떻게 조정해야 하는지 알려드립니다.
기술적 청사진: Ironwood 기반 Mistral 3 Large 추론 최적화 자세히 알아보기. 이 블로그에서는 Google의 한 팀이 Google Ironwood(TPU v7x)에서 Mistral 3 대규모 MoE 모델의 추론을 최적화하여, 1.5배의 성능 향상을 이끌어낸 과정을 개략적으로 소개합니다. 이 팀은 하이브리드 샤딩을 적용하고, 선형 VPU 합산을 트리 축소 방식으로 대체했으며, GMM/MLA 커널 최적화와 비동기 스케줄링 도입을 통해 이를 실현했습니다. 그 결과, 벤치마크 정확도에는 영향을 주지 않으면서도 처리량을 최대 48%까지 끌어올리는 성과를 거두었습니다. 블로그 전체 내용은 여기에서 확인하세요.

연구, 보고서, 심층 분석

보고서: Google은 최초로 발표된 GartnerⓇ Magic Quadrant™ AI 인프라 부문에서 리더로 선정되었으며, '실행 능력'에서 가장 높은 평가를 받고 '비전의 완전성'에서 가장 앞선 위치를 차지했습니다. Gartner는 Google의 독점적인 확장형 컴퓨팅, 통합 AI 하이퍼컴퓨터 아키텍처, AI 컴퓨팅 용량의 규모를 주요 강점으로 꼽았습니다. 여기에서 사본을 다운로드하세요.
보고서: Google Cloud는 최근 1,400명 이상의 수석 IT 리더를 대상으로 AI 인프라 현황 보고서를 위한 설문조사를 실시했으며, 그 결과 AI 활용 포부와 인프라 현실 간의 격차가 점점 더 벌어지고 있다는 분명한 패턴이 나타났습니다. 실제로 조직의 83%는 프로덕션급 에이전트 AI를 지원하려면 인프라를 업그레이드해야 한다고 답했습니다. 함께 제공되는 블로그를 읽고 에이전트형 애플리케이션이 시스템에 요구하는 사항을 충족하도록 인프라를 조정하면 파일럿 단계에서 프로덕션으로 전환하는 데 어떤 도움이 되는지 알아보세요.

2026년 6월

제품, 기술, 도구 업데이트

제품 변경사항: AI에 사용되는 민감한 정보를 보호하는 것은 안전한 고급 클라우드 인프라의 핵심입니다. 컨피덴셜 컴퓨팅은 하드웨어 기반의 신뢰할 수 있는 실행 환경(TEE) 내에서 사용 중인 데이터를 암호화하여 보호하고 검증 가능한 데이터 무결성을 제공합니다. 이 기능은 이제 NVIDIA RTX PRO 6000 Blackwell 서버 에디션 GPU가 탑재된 가속기 최적화 G4 머신 시리즈에서 이용 가능합니다. 컨피덴셜 G4 VM 및 컨피덴셜 G4 GKE 노드를 지금 바로 이용해 보세요.
개발자 리소스: 새로운 TPU 개발자 허브는 모델 빌더, 최적화 전문가, 개발자가 Google Cloud TPU의 성능을 최대한 활용하는 방법을 배울 수 있는 공간입니다. 자세한 내용은 이 블로그를 참고하세요.
새로운 제품: 새로운 OpenTelemetry 기반 TPU AI 원격 분석 수집기 에이전트를 사용하여 AI 워크로드를 확장하세요. 이제 사상 처음으로 정밀한 TPU 하드웨어 원격 분석 데이터를 Google Cloud Monitoring, Google Managed Prometheus 또는 자체 호스팅 Grafana 스택으로 바로 전송할 수 있습니다.

실무자 가이드 및 방법

안내 가이드: TPU, Cloud Storage FUSE, 동적 리소스 할당(DRA)을 사용하여 GKE Inference Gateway에서 실행되는 AI 추론 워크로드에 고가용성을 빌드하는 방법을 알아봅니다. 이 블로그에서 전반적인 내용을 살펴보거나, 실습 Codelab을 통해 모든 기술적 세부정보를 직접 익혀볼 수 있습니다.
안내 가이드: 모델 컨텍스트 프로토콜(MCP)을 통해 AI 에이전트를 Cloud Storage의 비정형 데이터에 연결할 수 있다는 사실을 알고 계셨나요? 이 블로그에서는 세 가지 고객 사례를 통해 왜 이러한 연결이 필요한지 살펴보고, 완전 관리형 서비스나 제어 및 맞춤설정의 폭이 넓은 자체 관리형 로컬 서버 중 나에게 맞는 방식을 선택해 구현하는 방법을 알아봅니다.

연구, 보고서, 심층 분석

보고서: 독립적인 벤치마크 보고서에 따르면, GKE Inference Gateway는 업계 선두의 다른 관리형 Kubernetes 서비스와 비교해 처리량은 15.7% 더 높고, 대기 시간은 92.8% 더 짧으며, 토큰 간 지연 시간은 62.6% 더 낮은 압도적인 성능을 기록했습니다. 이러한 압도적인 성능은 프리픽스 캐싱 기술 덕분입니다. 이 기술은 길고 반복되는 프롬프트 프리픽스의 KV 캐시(활성화 상태)를 저장함으로써 LLM 성능을 획기적으로 최적화합니다. 블로그에서 자세히 알아보세요.
아키텍처 심층 분석: TPU 및 GKE의 콜드 스타트 문제를 자세히 살펴보고 Run:ai Model Streamer가 어떻게 상황을 바꿀 수 있는지 알아봅니다.

고객 및 파트너 업데이트

고객 성공사례: Pager Health는 GKE, BigQuery, Cloud SQL, Gemini Enterprise Agent Platform을 활용하여 운영 단편화를 제거하고 간소화된 맞춤형 미국 의료 경험을 제공하여 삶을 변화시키고 있습니다.
고객 성공사례: 고객 리뷰 플랫폼인 Trustpilot은 Dataflow와 Gemini Enterprise Agent Platform을 통해 파인 튜닝된 Gemma 모델을 사용하여 대용량 스트리밍 파이프라인을 구축했습니다. 이 파이프라인은 비용 최적화된 A2 VM에서 A100 GPU를 사용해 실행되며, Gemini Enterprise Agent Platform에서 유지관리하는 최적화된 버전의 vLLM도 활용합니다.

2026년 5월

제품, 기술, 도구 업데이트

제품 변경사항: 이제 GKE Agent Sandbox가 정식 버전으로 제공됩니다.
새로운 오픈소스 프로젝트: Agent Substrate는 에이전트 인프라 밀도의 한계를 뛰어넘기 위해 새롭게 공개된 오픈소스 프로젝트입니다.
새로운 기능: 온디바이스 머신러닝(ML)을 대규모로 테스트하고 벤치마킹할 수 있는 솔루션인 Google AI Edge Portal이 이제 온디바이스 LLM의 벤치마킹과 디버깅을 지원합니다. 자세한 내용은 여기를 참고하세요.
제품 심층 분석: AI 워크로드를 위한 새로운 고성능 스토리지 제품군인 Cloud Storage Rapid를 심층적으로 살펴보았습니다. 출시 시점에는 고성능 영역 객체 스토리지 제품인 Rapid Bucket(이전 명칭: Rapid Storage)과 주문형 읽기를 가속화하고 기존 버킷의 워크로드를 위해 컴퓨팅과 데이터를 함께 배치하는 Rapid Cache(이전 명칭: Anywhere Cache)가 제공됩니다.

연구, 보고서, 심층 분석

아키텍처 심층 분석: Google 글로벌 인프라 부문 부사장 비카시 콜리와 엔지니어링 연구원 아르준 싱이 AI 워크로드가 네트워크 인프라에 미치는 영향을 개괄적으로 설명하고, 이를 더 효과적으로 지원하기 위해 데이터 센터 패브릭, WAN, 글로벌 네트워크에 적용한 심층적인 개선사항을 논의합니다.
아키텍처 심층 분석: 인스턴스 수준의 안정성 방식에서 벗어나, TPU 기반 프런티어 AI 모델 개발을 위한 새로운 클러스터 수준 안정성 모델을 공개했습니다.

고객 및 파트너 업데이트

고객 성공사례: 시각 미디어 제공업체인 Imgix는 NVIDIA RTX PRO 6000 Blackwell GPU 기반 G4 VM이 탑재된 AI 하이퍼컴퓨터에서 80억 개 이상의 이미지와 동영상을 제공합니다.

AI21, AI 하이퍼컴퓨터로 AI 워크로드 시작 시간 83% 단축

Mon, 12 Oct 2026 17:00:00 +0000

편집자 주: AI21 Labs는 Jamba 제품군을 비롯한 파운데이션 모델 개발에 오랜 실적을 보유한 선도적인 글로벌 AI 연구소로, 현재는 전문화된 LLM과 에이전트 최적화 기술에 주력하고 있습니다. AI21은 Google Cloud AI 하이퍼컴퓨터를 도입하여 우선순위가 높은 작업의 대기 시간을 72시간에서 12시간으로 단축하고, 수동 스케줄링 개입을 주당 20회에서 0회로 줄였습니다.

AI21은 기업이 최첨단 품질의 에이전트를 효율적으로 실행할 수 있도록 지원하는 파운데이션 모델과 에이전트 최적화 제품을 개발합니다. Jamba 제품군을 비롯한 언어 모델과 에이전트 최적화 제품군은 까다로운 프로덕션 워크로드를 실행하며, 여기에는 AI21 자체 워크로드도 포함됩니다. AI21은 대규모 지원을 위해 Google Cloud AI 하이퍼컴퓨터를 선택했습니다.

모델 학습 실행의 사용률을 높게 유지하려면 인프라, 조정, 가격 모델 전반에서 공동 설계된 확장 가능한 고성능 환경이 필요했습니다. AI21의 모델 학습은 공유 Google Kubernetes Engine(GKE) 클러스터 중 하나에서 실행되며, 수천 개의 Google Cloud A3(NVIDIA H100 Tensor Core GPU 기반) 및 A3 Ultra(NVIDIA H200 Tensor Core GPU 기반) 인스턴스를 풀링하므로 모든 팀이 자체 슬라이스에 갇히지 않고 Fleet의 전체 용량을 활용할 수 있습니다. 이 클러스터는 Jamba 제품군 외에도 모델 및 에이전트 최적화 워크로드를 학습시킵니다. 이 접근 방식은 사용률을 높게 유지하고 스케줄링을 어렵게 만듭니다.

사용률이 높은 클러스터의 교착 상태

조정에 GKE를 활용하기 전에는 Slack을 통해 직접 용량을 조율하곤 했습니다. 학습 실행을 위한 용량이 필요하면 #gpu-resources 채널에 글을 올리고 잘되기를 바라는 수밖에 없었습니다.

클러스터에 여유 공간이 있을 때는 이 방법이 효과적이었습니다. 하지만 예약된 컴퓨팅 Fleet의 목표인 사용률 100%에 가까워지자, 이 방법이 더 이상 통하지 않았습니다.

시간이 지나면서 모든 요청이 조율 대상이 되었고, 팀장은 컴퓨팅 리소스를 둘러싼 분쟁을 중재하는 데 시간을 보내야 했습니다. 우선순위가 높은 작업, 이를테면 한 번에 클러스터의 절반 이상이 필요하고 모델 프로젝트의 중요한 경로 역할을 하는 대규모 멀티 노드 학습 실행 작업도 충분한 연속 처리 용량이 확보될 때까지 최대 72시간 동안 차단된 상태로 대기해야 했습니다.

그림 1: #gpu-resources 채널의 일상적인 모습 — 수동 요청, 임시 조정, 답변을 기다리는 연구원

용량 부족은 두 가지 문제를 야기했고, 이 두 가지를 별개의 문제로 인식하기까지는 꽤 오랜 시간이 걸렸습니다. 첫 번째는 경합 문제, 즉 다음에 누가 컴퓨팅 리소스를 사용할 것인지 결정하는 문제였는데, 이는 협상을 통해 해결했습니다. 두 번째는 단편화 문제였습니다. 기술적으로는 사용 가능한 용량이 남아 있지만 대규모 작업에 사용하기에는 너무 작은 단위로 흩어져 있어 아무리 협상해도 해결할 수 없는 빈 패킹 문제와 같은 상황이 생겼습니다.

그림 2: GPU 단편화. 4개의 노드에 1+1+4+2로 분산된 8개의 무료 GPU는 8-GPU 워크로드에 적합하지 않습니다.

수치상으로는 용량이 충분히 남아 있는 것처럼 보이지만, 실제로는 여러 머신에 너무 작은 단위로 분산되어 있어 더 큰 작업을 처리하기에는 부족한 경우가 있었습니다. 양자택일 방식의 작업 승인이 없다 보니, 관리자가 수동으로 개입할 때까지 머신이 실제 작업은 수행하지 않으면서 리소스만 점유한 채 클러스터가 교착 상태에 빠지곤 했습니다.

기존 방식이 더 이상 효과적이지 않으며, 더 나은 방식이 필요하다는 점이 분명해졌습니다.

적절한 스케줄러 선택

AI21은 Apache YuniKorn, Volcano, Kueue를 비롯한 몇 가지 오픈소스 일괄 스케줄러를 살펴보았습니다. YuniKorn은 AI21의 모든 사용 사례를 포괄하지 못했습니다. Volcano는 더 많은 기능을 제공하지만, 이를 우리 환경에 통합하려면 핵심 Kubernetes 스케줄러 구성요소를 교체해야 했습니다.

Kueue가 단순성과 통합 측면에서 우수했습니다. 표준 Kubernetes와 호환되고, 핵심 구성요소를 교체할 필요가 없으며, 작업 사양을 다시 작성할 필요도 없었습니다.

GKE를 통해 AI 하이퍼컴퓨터의 유연하고 개방적인 운영 방식과 Kueue를 결합한 것도 성공에 기여한 요인이었습니다. GKE는 컴퓨팅 집약적인 AI 작업에 적합한 수준의 제어 기능을 제공합니다. 즉, 원시 인스턴스를 직접 관리하는 데 따른 오버헤드 없이도 GPU 하드웨어와 드라이버에 긴밀하게 액세스할 수 있습니다. Kueue는 Spot VM 및 동적 워크로드 스케줄러와 같은 Google Cloud 용량 유형을 포함하여 GKE와 기본적으로 통합되므로, 예약된 용량이 가득 차면 작업이 대기 상태로 멈춰 있는 대신 동일한 스케줄링 로직이 탄력적 용량을 자동으로 활용할 수 있게 해 줍니다.

오픈소스로 루프 닫기

Kueue를 도입하면서 단순한 프로세스 변경 이상의 큰 변화가 일어났습니다. AI21은 Google Cloud와 파트너 관계를 맺고 있기 때문에 기술계정 관리자와 직접 소통할 수 있었고, 이 관리자는 AI21을 Kueue팀의 설계 파트너로 만들 수 있는 기회를 발견했습니다. 이를 통해 AI21은 단순한 사용자가 아니라 도구의 발전 방향을 형성하는 데 도움이 되도록 실질적인 프로덕션 요구사항을 제시하는 주체가 될 수 있었습니다.

이 파트너십의 첫 번째 결과물 중 하나는 Kueue팀과 공유한 요구사항 문서였습니다. 이 문서에는 우리에게 필요했지만 아직 존재하지 않았던 동작, 즉 공정성에 보통 따라오는 선점 없이도 여러 팀의 멀티 노드 작업을 공정하게 순서대로 승인하는 동작이 설명되어 있었습니다. Kueue팀은 이 동작을 구현해냈습니다. Admission Fair Sharing(AFS)은 이미 실행 중인 작업을 중단하지 않고 이전에 용량을 적게 사용한 팀에 유리하도록 승인 대기열의 순서를 재조정합니다. 비슷한 시기에 AI21에서는 토폴로지 인식 스케줄링도 사용하기 시작했습니다. 기존의 이 기능 덕분에 Kueue가 물리적 클러스터 레이아웃을 인식할 수 있게 되었으며, 단일 노드에 맞지 않는 작업을 실행할 수 없는 위치에 배치하는 대신 해당 작업의 승인을 거부할 수 있었습니다.

AI21에게 있어 최상의 오픈소스 피드백 루프는 프로덕션에서의 사용을 통해 드러난 실제 요구사항이 Kueue에 직접적으로 다시 반영되는 것입니다.

동일한 Fleet, 더 적은 불편

이제 Slack #gpu-resources 채널은 보관처리되었습니다. 디버그 포드, 멀티 노드 학습 실행, 추론 배포 등 모든 워크로드는 자동으로 큐에 추가되고, 우선순위가 지정되고, 스케줄링됩니다. 효과는 즉각적이었습니다. 수동 개입이 주당 약 20회에서 0회로 줄었습니다. 이전에는 최대 72시간을 기다려야 했던 높은 우선순위 작업의 대기 시간이 이제 12시간으로 줄었습니다. 클러스터 전반의 단편화는 15%에서 8%로 감소했으며, 실행할 곳이 없는 상태에서 부분적으로 허용되는 워크로드가 발생하는 '좀비 작업' 문제가 사라졌습니다.

이러한 변화로 인해 총비용이 달라진 것은 아닙니다. 예약된 Fleet을 의도적으로 100%에 가까운 사용률로 실행하므로 원시 지출은 애초에 최적화하려는 변수가 아니었습니다. 달라진 점은 직원들이 시간을 쓰는 방식이었습니다. 이제 팀장은 더 이상 컴퓨팅 리소스 분쟁을 중재할 필요가 없으며, 연구원들은 Slack에서 답장을 기다리지 않아도 됩니다. 모두가 더 많은 실험을 실행하고 더 빠르게 반복 작업을 진행할 수 있게 된 것입니다.

45배 더 빠른 GKE 에이전트 샌드박스로 에이전트형 RL 및 평가 연구 가속화

Wed, 07 Oct 2026 17:00:00 +0000

대규모 병렬 롤아웃에서 에이전트형 강화 학습(RL)과 평가를 수직 확장할 때 첨단 AI 연구소는 필연적으로 병목 현상에 직면하게 됩니다. 고가의 GPU 클러스터가 유휴 상태로 CPU 샌드박스 콜드 스타트를 몇 분 동안 기다리고, 수 기가바이트에 달하는 SWE-bench 스타일 이미지를 수천 개 가져와야 하고, 스케줄링 백로그가 발생하기 때문입니다. 이는 연구 속도를 늦추고 학습 예산을 낭비하게 만드는 샌드박스 인프라 문제입니다.

이러한 근본적인 인프라 병목 현상을 해결하기 위해 오늘 Google Cloud는 RL에 최적화된 GKE 에이전트 샌드박스, 에이전트 샌드박스 RL 조정 SDK, 널리 사용되는 RL 짐 및 하네스를 위한 기본 통합 기능을 정식 출시합니다.

최신 AI를 위한 운영체제인 Kubernetes는 대규모 GPU/TPU 학습 클러스터와 분산 추론을 지원하도록 발전해 왔습니다. 이제 Kubernetes는 AI 컴퓨팅의 다음 개척 분야인 에이전트를 주도하기 위해 확장하고 있습니다. 하지만 정적 워크로드와 달리 에이전트형 워크로드는 빠르게 진화하므로 인프라도 그만큼 빠르게 진화해야 합니다. RL 연구자가 무엇을 필요로 할지 추측하는 대신 Kubernetes 자체를 성능 벤치마크 및 평가를 기반으로 하는 자동 연구 및 검증 루프에 넣었습니다. 그리고 SWE-bench와 같은 강력한 에이전트형 벤치마크를 사용하여 의도적으로 자체 클러스터를 스트레스 테스트하고 오류를 발생시켰습니다. etcd 타임아웃부터 GPU 유휴 상태 급증에 이르기까지 드러난 모든 병목 현상이 개발 주기에 다시 반영되어 GKE의 핵심 기본 요소를 개선하는 데 사용되었습니다.

그 결과, 에이전트형 RL 및 평가 워크로드를 위해 특별히 설계된 샌드박스 레이어가 탄생했습니다. 이 샌드박스 레이어는 다음과 같은 특징을 가집니다.

10~45배 빠른 첫 번째 명령어 실행까지 소요 시간: GKE는 샌드박스 환경을 45~85초가 아닌 1~9초 만에 가동할 수 있어 고가의 GPU를 최대한 활용할 수 있습니다.
꼬리 지연 시간 감소: 최악의 경우 샌드박스 대기 시간이 7.5분에서 10초 미만으로 단축되었습니다.
3배 적은 컨트롤 플레인 변동: 각 RL 학습 단계에서 롤아웃 버스트가 발생하며, 이때 수천 개의 샌드박스가 한꺼번에 요청됩니다. 이 SDK에는 포드를 삭제하고 다시 만드는 대신 롤아웃 전반에서 포드를 재사용하는 인플레이스 재활용 전략이 적용되어 있습니다. 즉, 생성되는 포드가 3분의 1로 줄어들어 변동이 발생해도 Kubernetes API 서버가 안정적으로 유지됩니다.

이 새로운 기본 요소를 통해 AI 연구소와 에이전트 네이티브 스타트업은 이제 대규모 에이전트형 RL 궤적과 평가를 동시에 안정적으로 실행하여 가속기 유휴 시간을 최소화하고 연구 속도를 획기적으로 높일 수 있습니다.

에이전트형 RL 인프라가 직면한 현실적인 과제

해결책을 논하기에 앞서 에이전트형 RL이 인프라 측면에서 왜 그토록 까다로운지 정확히 알아보겠습니다. 표준 에이전트형 RL 루프에서 LLM 정책은 GPU에서 코드 스니펫과 같은 작업을 생성하고 이를 격리된 CPU 샌드박스 내에서 실행하여 보상 신호를 관찰합니다. 그러나 수만 건의 병렬 롤아웃을 지원하기 위해 이 루프를 수직 확장하면 다음과 같은 세 가지 중요 기반 시설 병목 현상이 발생합니다.

가속기 유휴 비용, 즉 첫 번째 명령어 실행까지 소요 시간(TTFC) 및 꼬리 지연 시간의 함정: 에이전트형 RL은 배치 워크로드이며, 동기식 RL 단계에서는 배치에서 가장 느린 샌드박스가 준비될 때까지 학습을 진행할 수 없습니다. CPU 샌드박스를 구축하는 데 프로비저닝, 이미지 가져오기, 초기 시작 스크립트 실행에 몇 분이 걸린다면 값비싼 가속기 용량이 낭비됩니다.
대규모 이미지 카디널리티: 표준 컨테이너 캐싱은 소수의 정적 기본 이미지를 전제로 합니다. 그러나 에이전트형 RL에서는 모든 단일 작업(예: SWE-bench 또는 R2E-Gym의 수천 개 GitHub 저장소)에 완전히 별개의 OCI 컨테이너 이미지가 필요한 경우가 많습니다. 실행당 수천 개의 고유한 대규모 이미지를 관리하면 심각한 이미지 가져오기 병목 현상과 스토리지 마찰이 발생할 수 있습니다.
컨트롤 플레인 포화: 버스트 배치 워크로드인 에이전트형 RL은 일반적으로 배치 크기의 이미지 작업과 작업당 여러 번의 롤아웃(예: 작업당 4, 8, 16번의 롤아웃)을 실행하므로 이미 많은 수의 이미지가 극한까지 증가하게 됩니다. 예를 들어 테스트에 사용된 한 공개 데이터 세트에는 4,578개의 R2E 이미지가 포함되어 있습니다. 이미지당 4번의 롤아웃을 가정하면 18,312개의 작업이 발생하며, 이를 위해서는 18,312개의 샌드박스가 동시에 필요합니다. 표준 Kubernetes 컨트롤 플레인은 이러한 버스트 부하에서 성능이 현저히 저하됩니다. 분당 수만 개의 임시 포드 변경 과정에서 API 서버 큐 병목 현상과 포드 상태 오류가 발생하고 잘못된 노드 상태 제거가 트리거됩니다.

이는 가상의 문제가 아닙니다. 최첨단 에이전트를 학습시키는 선도적인 AI 연구소에서 매일 마주하는 현실입니다.

RL에 최적화된 GKE 에이전트 샌드박스

코드 실행 샌드박스를 팬아웃하기 위해 비교적 소규모 클러스터를 구축했습니다. 이 클러스터는 GKE 이미지 스트리밍이 사용 설정된 10노드 gVisor 샌드박스 풀, 에이전트 샌드박스 컨트롤러, 웜 포드 확보를 위한 클러스터 내 SDK 드라이버로 구성되었습니다. 많은 수의 이미지와 높은 카디널리티를 포함한 다양한 전략과 설정을 테스트했습니다.

인프라 계층

GKE 에이전트 샌드박스는 안전한 에이전트 실행을 위한 개방형 Kubernetes 기본 요소로, 사전 초기화된 정상 환경을 유지하여 콜드 스타트 오버헤드를 제거하는 기본 제공 SandboxWarmPool 기능을 갖추고 있습니다. SandboxWarmPool을 GKE 이미지 스트리밍과 통합함으로써 1.2GB가 넘는 대용량 이미지 수천 개와 함께 높은 이미지 카디널리티를 요구하는 RL 및 평가 워크로드를 효과적으로 지원하는 동시에 반응성이 뛰어난 에이전트형 학습에 필요한 매우 짧은 TTFC를 제공합니다. 스냅샷, 일시중지, 재개 기능을 통해 오류 복구를 위한 체크포인트 설정을 지원하며 샌드박스 포킹으로 병렬 에이전트 분기 로직을 구현하여 여러 경로를 탐색할 수 있습니다.

이 GKE 기본 요소는 이미 선도적인 AI 연구소인 Mistral AI의 에이전트형 RL 학습 인프라를 뒷받침하고 있습니다.

“강화 학습의 한계를 뛰어넘으려면 예측 불가능한 수요를 감당할 수 있도록 즉각적으로 확장 가능한 인프라가 필요합니다. RL을 위한 GKE의 고성능 에이전트 샌드박스를 활용하면 클러스터 전반에서 수십만 개의 안전한 환경을 원활하게 조정하고 단일 클러스터에서 30,000개가 넘는 샌드박스의 급증을 처리할 수 있습니다. 이는 모델 학습 및 반복 주기를 가속화하는 데 필요한 안정적인 기반을 제공합니다.” - 장 말로 델리뇽, Mistral AI 연구 엔지니어

조정 SDK 및 RL 도구 통합

연구자가 Kubernetes YAML을 작성하거나 컨테이너 이미지에 커스텀 데몬을 삽입하지 않고도 이러한 기능을 활용할 수 있도록 에이전트 샌드박스 RL 조정 SDK를 개발했습니다. 이 SDK는 특정 평가 또는 RL 학습 패턴에 맞게 조정된 플러그형 웜 풀링 전략을 통해 깔끔한 비동기 Python API를 제공합니다. 또한 Gymnasium, NVIDIA NeMo Gym, OpenHands와 같은 RL 도구를 위한 기본 통합을 구축했으며, 향후 더 많은 도구가 추가될 예정입니다.

벤치마크: 유휴 가속기로 인한 낭비 감소

Google은 10노드 gVisor 샌드박스 풀에서 두 가지 워크로드, 즉 500개 이미지로 구성된 SWE-bench 환경과 로컬 디스크 용량을 초과하는 4,578개 이미지로 구성된 R2E 코퍼스를 대상으로 이 테스트를 수행했습니다.

1.TTFC 및 테일 지연 시간: 속도 10~45배 개선

핵심 측정항목	중요한 이유	원시 K8s 포드 기준	GKE 에이전트 샌드박스 SDK	벤치마크 이점
TTFC, 평균	GPU 유휴 시간 결정	44~85초(평균)	1.1~8.8초(평균)	속도 10배 개선
꼬리 지연 시간 - 최대 TTFC(최악의 경우)	배치 병목 현상	7.5분(450초)	10초 미만	속도 45배 개선

동시 실행은 500개의 동시 작업 및 샌드박스부터 최대 18,312개(R2E 이미지 4,578개 × 롤아웃 4번)까지 다양했습니다. 모든 설정에서 성능 향상이 유지되었습니다.

이 결과에 도달하기까지의 과정: 컨트롤러, SDK, RL Fleet를 계측한 후 고정된 10노드 예산 범위 내에서 수백 번의 비교 실행을 수행했습니다. 성능 향상의 대부분은 다음 두 가지 변경 사항에서 비롯되었습니다.

이미지 하이드레이션이 중요 경로에서 제외되었습니다. 카디널리티가 높은 코퍼스는 로컬 디스크 용량을 훨씬 초과하므로 학습 도중에 콜드 이미지를 가져오면 I/O 경합과 수 분에 달하는 지연이 발생합니다. SDK는 노드 간 이미지 배치를 계획하고, GKE Image Streaming과 사전 웜 풀링이 나머지 작업을 처리합니다. 즉, 롤아웃에서 요청하기 전에 하이드레이션이 완료됩니다.
컨트롤 플레인의 속도가 조절됩니다. 동시성이 높은 롤아웃은 API 서버의 Thundering Herd를 트리거합니다. 에이전트 샌드박스 컨트롤러 v1.0.0은 웜 풀이 다시 채워지는 속도를 제한하는 속도 제어 기능을 추가하여 버스트 중에도 etcd와 API 서버를 안정적으로 유지합니다.

이러한 수치의 근거가 되는 튜닝 노브, 벤치마크 하네스, 부하 테스트는 모두 agent-sandbox-rl 예에 포함되어 있습니다. 이 예는 사람이 읽을 수 있는 JSON 보고서를 생성하므로 사용자의 클러스터에서 직접 비교를 재현할 수 있습니다.

2. 다중 궤적 롤아웃 중 컨트롤 플레인 및 포드 수명 주기 변동 3배 감소

핵심 측정항목	중요한 이유	원시 K8s 포드 기준	GKE 에이전트 샌드박스 SDK	벤치마크 이점
컨트롤 플레인 변동(이미지 4,578개 × 롤아웃 실행 4번)	컨트롤 플레인 포화	18,312	5,869	변동 3.1배 감소

원시 Kubernetes는 각 궤적 단계마다 포드를 다시 만듭니다. 18,312개의 작업은 스케줄링 오버헤드를 늘리고 디스크 I/O를 낭비하며 대규모 테스트에서는 무제한 가비지 컬렉션 루프를 트리거했습니다. 반면 SDK의 인플레이스 재활용 전략은 포드를 활성 상태로 유지하면서 롤아웃 에피소드 사이에 포드 내에서 git reset과 저장소 체크아웃을 실행합니다. 그 결과, 포드 생성은 3.1배 감소하고 버스트 중에도 컨트롤 플레인의 부하는 안정적으로 유지됩니다.

절충점

환경을 미리 준비하면 저렴한 CPU와 백그라운드 클러스터 시간이 소요되므로 이미지 스트리밍 및 준비 확인이 중요 경로에 포함되지 않습니다. RL Fleet의 경우 이는 명백한 절충점입니다. 가속기 유휴 시간은 비용이 많이 드는 리소스인데, 이 접근 방식은 이를 제거합니다.

학습 규모에서는 한 가지 세부 사항이 중요합니다. SDK는 실패한 모든 샌드박스를 자동으로 삭제하지 않고, 재시도 가능한 것으로 집계하여 표시합니다. 추적되지 않는 삭제는 단순한 롤아웃 손실이 아니라 보상 편향으로 이어집니다.

시작하기

지금 빌드하기: Python SDK를 위한 에이전트 샌드박스 저장소 또는 에이전트 샌드박스 RL 저장소를 살펴보고 Gymnasium, NVIDIA NeMo Gym, OpenHands 등의 RL 도구를 위한 기본 통합을 확인하세요.
가속기 사용률 더욱 높이기: llm-d 협력적 타임 슬라이싱 저장소와 스냅샷 에이전트 가이드를 살펴보고 독립적인 RL 작업을 공유 물리적 하드웨어에 동적으로 인터리브 처리하세요.
자세히 알아보기: GKE 에이전트 샌드박스를 사용하여 안전한 실행 환경을 배포하는 방법에 대한 공식 문서를 읽어보세요.

Google, 2026년 Gartner Magic Quadrant의 컨테이너 관리 부문에서 리더로 선정

Wed, 07 Oct 2026 04:00:00 +0000

Gartner에서 비전 완성도와 실행 능력을 기준으로 Google을 2026년 Gartner® Magic Quadrant™ 컨테이너 관리 부문에서 4년 연속 리더로 선정했다는 반가운 소식을 전해드립니다. Google은 평가 대상 공급업체 중 실행 능력(Ability to Execute) 면에서 가장 높은 평가를 받았으며 이는 Google이 성능과 효율성 모두에 고도로 최적화된 컨테이너 플랫폼을 제공하겠다는 사명을 다하는 데 성공했음을 입증하는 결과라고 생각합니다. Google은 전 세계 고객이 차세대 AI 및 에이전트형 애플리케이션을 비롯해 가장 까다롭고 복잡한 워크로드를 대규모로 빌드하고 실행할 수 있도록 지원합니다.

함께 발표된 2026 Gartner Critical Capabilities for Container Management 보고서에서도 Google Cloud가 신규 클라우드 네이티브 애플리케이션, 컨테이너화된 기존 애플리케이션, AI 학습, AI 추론, 에지 애플리케이션, 하이브리드 애플리케이션 같은 모든 사용 사례에서 1위를 차지했습니다.

Gartner는 '2025년 30% 미만이었던 신규 AI 배포의 Kubernetes 도입률이 2028년에는 95%까지 급증할 것'으로 전망합니다.1 오늘날 가장 혁신적인 앱과 비즈니스는 컨테이너를 기반으로 운영되고 있으며, 컨테이너는 고객이 에이전트 시대에 비즈니스를 혁신하는 데 필요한 인프라를 제공합니다.

Google Cloud는 2014년에 Kubernetes를 선보이고 2015년 세계 최초의 관리형 Kubernetes 서비스인 Google Kubernetes Engine(GKE)을 출시하면서 업계 전반의 클라우드 네이티브 혁명을 주도했습니다. 이후 컨테이너 플랫폼과 역동적이고 혁신적인 Kubernetes 생태계를 발전시키기 위한 Google의 노력은 깊이를 더해가고 있습니다. 서버리스 컨테이너 플랫폼인 GKE Autopilot과 Cloud Run은 GKE와 함께 운영 비용을 크게 절감하고 개발자가 뛰어난 컨테이너화 앱을 그 어느 때보다 신속하게 제공할 수 있도록 지원합니다.

엔터프라이즈 AI의 폭발적인 성장과 함께 Google은 AI 시대에 맞게 인프라 관리 방식을 재편하고 있습니다. 2026년 현재까지 Google은 GKE와 Cloud Run을 자율형 AI 시스템, 대규모 추론 워크로드, 안전한 런타임 격리에 최적화된 에이전트 네이티브 고성능 플랫폼으로 전환하기 위해 광범위한 기반 개선사항을 도입해 왔습니다. 최첨단 AI 모델 학습, AI 스타트업 시작, 기업의 AI 전환 중 어떤 단계에 있든 필요한 컨테이너 플랫폼을 찾을 수 있습니다. 주요 내용은 다음과 같습니다.

AI 인프라를 위한 업계 최고 수준의 성능 및 효율성 제공

GKE 예측 지연 시간 단축: GKE Inference Gateway에 기본 제공되는 이 ML 기반 기능은 정적 구성 대신 용량을 고려한 라우팅을 사용하여 첫 번째 토큰까지의 시간(TTFT)을 최대 70% 단축합니다.
GKE 자동 KV 캐시 스토리지 계층화: KV 캐시 데이터를 RAM, Local SSD, Cloud Storage 간에 자동으로 이동합니다. 이를 통해 메모리 병목 현상을 줄이고, RAM 오프로딩으로 TTFT를 40% 개선하며, 프롬프트 컨텍스트가 큰 경우 Local SSD를 사용하여 처리량을 70% 늘릴 수 있습니다. [1]
GKE 컨테이너 및 모델 시작 가속화: GKE 노드 시작 시간이 최대 4배 빨라졌으며 포드 시작 속도도 최대 80% 향상되었습니다. 또한 기본 제공되는 run:AI Model Streamer 통합을 통해 대용량 모델을 Cloud Storage에서 5배 더 신속하게 가져올 수 있습니다.
Cloud Run 주문형 서버리스 GPU Scale-to-zero: Cloud Run은 NVIDIA RTX PRO 6000 Blackwell GPU를 지원하여 700억 개 이상의 파라미터를 사용하는 모델을 주문형으로 서빙할 수 있습니다. 모든 드라이버가 사전 설치되고 5초 이내에 0에서 완전히 프로비저닝된 GPU를 바로 시작하여 서비스를 가동할 수 있습니다. 활성 추론이나 미세 조정 실행이 완료되면 Cloud Run이 인스턴스를 자동으로 0까지 축소하여 유휴 인프라 비용을 없애줍니다.

에이전트형 인프라의 보안 및 확장을 위한 Kubernetes의 진화

GKE Agent Substrate: Agent Substrate는 오픈소스이자 보안 강화를 기본으로 설정한 에이전트 실행 런타임으로, 표준 컨테이너 런타임보다 10배 더 높은 밀도로 수백만 개의 샌드박스를 실행하도록 설계되었습니다. 자율 에이전트 시대에 맞게 특별히 설계된 Substrate는 네이티브 제로 트러스트 커널 및 네트워크 격리 기능을 바탕으로 초당 500회 이상의 일시중지/재개 활성화 요청을 처리하면서도 500ms 미만의 재개 성능을 제공합니다. Agent Substrate는 모든 Kubernetes 인프라에서 실행되며 GKE에 최적화된 오픈소스 솔루션으로 제공됩니다.
GKE 에이전트 샌드박스: gVisor 커널 격리 기술을 기반으로 빌드된 에이전트 샌드박스는 신뢰할 수 없는 멀티 에이전트 AI 코드 실행으로부터 호스트 환경을 격리합니다. 또한 1초 미만의 지연 시간으로 초당 최대 300개의 샌드박스를 처리하는 대규모 보안 실행 환경을 제공하며, Axion 프로세서에서 실행 시 유사한 하이퍼스케일러 클라우드 제공업체보다 최대 30% 향상된 가격 대비 성능을 실현합니다.
GKE Dataplane V2 확장성 한도: 활성 NetworkPolicy를 구현하는 GKE 클러스터의 아키텍처 용량 한도가 7,500개 노드에서 클러스터당 15,000개 노드로 두 배 증가하여 대기업 및 AI 고객의 대규모 인프라 요구사항을 지원합니다.
GKE 인텐트 기반 자동 확장: GKE가 기본 하드웨어 측정항목 외에도 애플리케이션 인텐트와 커스텀 측정항목을 사용하여 기본적으로 수평으로 자동 확장함에 따라 리소스 할당 반응 시간이 25초에서 단 5초로 단축됩니다.
Filestore 에이전트 볼륨: 이 새로운 솔루션은 NFS 마운트를 밀리초 단위로 연결 및 분리하여 에이전트가 거의 즉각적으로 작업을 시작/재개할 수 있도록 하며, 기본 Read-Write-Many(RWX) 액세스 및 POSIX 호환 파일 잠금을 통해 쓰기 충돌 없이 안전한 멀티 에이전트 협업을 지원합니다.

서버리스 컨테이너로 실현하는 차세대 개발자 경험

표준 웹 API를 호스팅하거나, 대규모 배치 데이터 작업을 실행하거나, 비동기 메시지 큐를 처리하거나, 복잡한 AI 에이전트를 배포하는 모든 경우에서 Cloud Run의 단일 통합 서버리스 모델로 처리함에 따라 탁월한 개발자 경험과 최대한의 엔지니어링 속도가 실현됩니다.

Google AI Studio에서 원클릭 프로토타입 제작: Google AI Studio 내에서 직접 풀 스택 애플리케이션을 빌드하고 배포할 수 있어 신속한 프로토타입 제작과 실험에 매우 적합한 환경을 제공합니다. 클릭 한 번으로 바이브 코딩한 애플리케이션을 즉시 패키징하여 Cloud Run에 게시할 수 있습니다.
Cloud Run 인스턴스: 이 새로운 기본 요소를 사용하면 Cloud Storage 볼륨 마운트가 통합된 개별 주소 지정 가능 장기 실행 싱글톤 리소스를 관리할 수 있어 OpenClaw와 같이 지속적으로 실행되는 백그라운드 에이전트를 비용 효율적으로 배포할 수 있습니다. 월 약 5.70달러(1 vCPU 및 1 GiB RAM 기준)라는 예측 가능한 고정 요금으로 시작하는 공유 CPU 기본 구성을 통해, Cloud Run 인스턴스는 기존 VM의 불필요한 대기 비용과 운영 오버헤드 없이 상시 작동하는 VM급 환경을 제공합니다.
Cloud Run 샌드박스: 500밀리초 미만의 빠른 속도로 구동되는 강력한 격리 환경을 통해, 모델이 생성한 신뢰할 수 없는 코드도 안전하게 실행하며 무단 액세스로부터 호스트 시스템을 철저히 보호합니다.

다음 단계 수행

Google은 컨테이너 플랫폼의 성능, 보안, 확장성을 새로운 수준으로 끌어올리는 동시에 개방형 생태계에서 미래를 계속 만들어 나가고 있습니다. 지금 바로 에이전트 샌드박스와 Agent Substrate를 살펴보세요. Google은 고객 및 파트너 여러분과 함께 에이전트 인프라의 미래를 만들어 나가고 있습니다. 학습 여정을 계속하려면 다음 리소스를 확인하세요.

2026년 Gartner® Magic Quadrant™의 컨테이너 관리 부문 보고서 사본을 무료로 다운로드하세요.
GKE에서 에이전트 샌드박스를 사용해 보세요.
참여: 에이전트 샌드박스 오픈소스 커뮤니티에 참여하세요.
Agent Substrate를 살펴보세요.
11월 9~12일 솔트레이크시티에서 열리는 KubeCon North America 2026에 참여하세요. 더 다양한 프로그램을 경험하려면 하루 일찍 열리는 GKE Day(11월 9일)에 참석하세요.
Google이 2026년 Gartner® Magic Quadrant™의 클라우드 네이티브 애플리케이션 플랫폼 부문에서 리더로 선정된 이유를 알아보세요.
지금 바로 cloud.run에서 서버리스 애플리케이션의 미래를 만들어 보세요.

^{1. Gartner 보고서: Critical Capabilities for Container Management, 2026년 9월 8일}

^{Gartner, Gartner Magic Quadrant의 컨테이너 관리 부문, Dennis Smith 외, 2026년 9월 2일Gartner, Critical Capabilities for Container Management, Tony Iams, Wataru Katsurashima, Lucas Albuquerque, Dennis Smith, Bhuvie Chhabra, 2026년 9월 8일. Gartner 및 Magic Quadrant는 Gartner, Inc. 및/또는 그 계열사의 상표입니다.면책 조항: Gartner는 자사 간행물에 설명된 어떤 회사, 공급업체, 제품 또는 서비스도 보증하지 않으며 기술 사용자에게 최고 등급의 공급업체 또는 기타 지정된 공급업체만 선택하도록 권장하지 않습니다. Gartner 간행물은 Gartner의 비즈니스 및 기술 인사이트 조직의 의견을 담고 있으며, 사실을 진술하는 것으로 해석해서는 안 됩니다. Gartner는 이 간행물과 관련하여 상품성 또는 특정 목적에 대한 적합성 보증을 비롯한 모든 명시적, 묵시적 보증을 부인합니다.}

멀티 클러스터 GKE Inference Gateway를 통한 오버헤드 1% 미만의 전역 AI 라우팅

Mon, 05 Oct 2026 22:00:00 +0000

AI 인프라에 대한 수요가 역대 최고 수준입니다. 전 세계적인 가속기 부족으로 인해 엔지니어링팀은 단 하나의 데이터 센터에서 필요한 모든 컴퓨팅 용량을 확보할 수 있는 경우가 거의 없습니다. 컴퓨팅 용량은 여기저기 흩어져 있는 클러스터에서 조달해야 하며, 종종 대양을 사이에 두고 멀리 떨어져 있는 경우도 있습니다. 동시에 워크로드의 요구사항도 점점 더 커지고 있습니다. 즉, 오늘날 장기간 실행되는 에이전트형 워크로드는 대개 10만~80만 개 이상의 토큰으로 구성된 컨텍스트 윈도우를 가지며, 이는 이전 세대의 AI 트래픽보다 더 빠르게 가속기 메모리를 사용합니다.

이러한 환경에서는 '비용 대비 인텔리전스'를 극대화하는 것이 목표입니다. 하지만 단편화되고 균형이 맞지 않는 인프라는 이러한 작업을 수행하기에 적합하지 않은 경우가 많습니다. 이로 인해 고가의 가속기가 유휴 상태로 방치되는 반면, 다른 곳에서는 요청이 큐에서 대기하는 상황이 발생하기 때문입니다.

이러한 격차를 해소하기 위해 전 세계에 분산되어 있는 컴퓨팅 용량이 단일 진입점 뒤에서 단일 풀처럼 작동하도록 하는 계층화된 라우팅 아키텍처를 빌드했습니다. 에지에서는 멀티 클러스터 GKE Inference Gateway가 전역, 멀티 리전 트래픽 분산 및 고가용성에 중점을 둡니다. 그 아래에서는 LLM-d 라우터가 사용률을 높게 유지하는 복잡한 메모리 인식 예약 알고리즘을 처리합니다.

이 아키텍처는 의도적으로 런타임, 모델, 가속기에 구애받지 않도록 설계되어 서빙 프레임워크, 모델 제품군, GPU 또는 TPU 하드웨어 전반에서 작동합니다. 추상적인 결과가 아닌 구체적인 결과를 얻기 위해 최근에 미국과 유럽에 분산되어 있는 17,000개의 컴퓨팅 노드로 구성된 멀티 리전 GKE 배포 환경에서 프로덕션 수준의 전역 요청 라우팅을 대규모로 관리하는 작업을 벤치마킹했습니다. 이 배포 환경에서는 SGLang을 사용하여 선도적인 전문가 혼합(MoE) 파운데이션 모델을 제공했습니다.

그 결과 3개의 클러스터로 확장하자 과중한 멀티 클라이언트 동시 실행 상황에서도 99.9%의 성공률을 유지하면서 처리량이 선형에 가깝게 증가했습니다. 또한 멀티 클러스터 GKE Inference Gateway를 통해 트래픽을 라우팅했을 때 발생하는 오버헤드가 1% 미만으로 줄어 로컬 클러스터를 직접 호출할 때와 비교하여 99.5%의 처리량을 달성했습니다.

이 기능의 작동 방식, 벤치마크 결과에 대한 자세한 내용, 분산형 추론 배포 환경에 미치는 영향에 대해 알아보려면 계속 읽어보세요.

3개 리전, 1개 엔드포인트

배포는 us-east5(구성 클러스터), us-west8, europe-west4 등 지리적 리전 세 곳에 있는 3개의 GKE 클러스터에 걸쳐 이루어졌습니다. 하지만 클라이언트의 입장에서는 이러한 지역이 전혀 존재하지 않습니다. 요청은 단일 전역 가상 IP에 전달되며, Gateway가 각 요청을 처리할 클러스터를 실시간으로 결정합니다.

이러한 결정이 무작위로 이루어지지 않고 스마트하게 이루어지도록 하려면 원격 분석이 필요합니다. 멀티 클러스터 부하 분산기는 네트워크 계층에서 기존의 라운드 로빈 라우팅 방식 대신 실시간 애플리케이션 신호를 기반으로 트래픽을 라우팅하도록 구성됩니다. 구체적으로 살펴보면 엔드포인트 선택 도구 프록시(EPP)가 기본 추론 엔진에 의해 노출되는 KV 캐시 토큰 사용률을 읽고 이를 부하 분산기의 측정항목으로 내보냅니다. 부하 분산기는 이 측정항목을 기반으로 과부하 상태인 리전이 확인되면 트래픽을 다음 정상 리전으로 분산시킵니다.

멀티 클러스터 GKE Inference Gateway 토폴로지. 구성 클러스터는 라우팅 구성을 보유하지만 요청 경로 외부에 위치하고, 각 대상 클러스터는 자체 EPP를 실행하고 KV 캐시 사용률을 부하 분산기에 다시 보고합니다.

분산형 LLM 엔진은 표준 웹 앱과 다르게 작동합니다. 일반적인 추론 엔진의 분산 모드(예: 여러 노드에 걸친 텐서 병렬 처리)에서는 마스터(rank-0) Pod만 API를 제공합니다. GKE는 트래픽을 리더 Pod로만 전달하도록 이미 표준 서비스 선택기와 LeaderWorkerSet(LWS)를 사용하여 로컬 라우팅을 처리합니다. 멀티 클러스터 GKE Inference Gateway 또한 이 파운데이션 모델과 통합됩니다. 즉, 전역 트래픽을 올바른 리전별 서비스로 라우팅하여 별도의 추가 설정 없이도 리전 간 부하 분산이 기본 멀티 노드 토폴로지를 유지하도록 지원합니다.

그 결과 서로 격리되어 있는 3개의 리전별 데이터 센터가 하나의 통합된 전역 가속기 Fleet처럼 작동하기 시작하며, 모델이 실제로 수행하는 작업에 따라 장애 조치와 부하 분산이 이루어집니다.

라우팅 오버헤드 측정

전역 라우팅 등급에 대해 모든 팀이 가장 먼저 던지는 질문은 거의 항상 '리전 간 기능을 위해 처리량을 어느 정도 포기해야 하는가?'입니다.

벤치마크 결과는 이에 대한 명확한 답을 제시합니다. 즉, 멀티 클러스터 GKE Inference Gateway를 배포하여 가속기 Fleet을 극대화한다고 해서 반드시 처리량을 포기해야 하는 것은 아닙니다. Gateway를 통해 트래픽을 라우팅했을 때 발생하는 오버헤드가 1% 미만으로 줄어 로컬 클러스터를 직접 호출할 때와 비교하여 99.5%의 처리량을 달성했습니다.

이것이 바로 전체적인 균형입니다. 전역 부하 분산의 모든 이점을 사실상 비용 부담 없이 누릴 수 있습니다.

리전 간 선형 확장

더 큰 시험대는 규모입니다. 모든 클라이언트 요청이 단일 리전(us-east5)에서 발생했음에도 불구하고 미국과 유럽에 걸쳐 클러스터를 1개에서 3개로 늘리자 Gateway에 상당한 부담이 가해졌습니다. Gateway가 이러한 거리적 제약으로 인해 부하를 효율적으로 분산하지 못한다면 하드웨어가 추가되더라도 처리량은 정체될 것입니다.

그러나 실제로는 처리량이 컴퓨팅 용량에 거의 정확히 비례하여 증가했습니다.

Fleet 토폴로지	요청 처리량	토큰 처리량	성공률
클러스터 1개(us-east5-a)	0.72 req/s	2,898 tok/s	99.87%
클러스터 2개(+ us-west8-a)	1.40 req/s	6,380 tok/s	99.95%
클러스터 3개(+ europe-west4- b)	2.10 req/s	8,457 tok/s	99.90%

3개의 클러스터로 확장하자 과중한 멀티 클라이언트 동시 실행 상황에서도 99.9%의 성공률을 유지하면서 처리량이 선형에 가깝게 증가했습니다.

메모리 인식 라우팅의 실제 작동 방식

라운드 로빈 부하 분산은 모든 요청을 동일하게 처리하므로 LLM 요청에는 적합하지 않습니다. 모든 요청은 동일하지 않기 때문입니다. 과중한 프롬프트는 GPU 컴퓨팅 코어를 포화 상태로 만들고, 긴 생성 작업은 메모리 대역폭에 부담을 주며, 긴 컨텍스트 대화는 엔진이 새로운 작업을 예약할 수 없을 때까지 VRAM을 서서히 소모합니다.

여기서 메모리 대역폭에 대한 부담은 이 배포 환경을 위해 선택된 라우팅 신호에서 비롯되었습니다. 라우팅 플레인은 추론 엔진의 기본 토큰 사용량 측정항목을 Gateway의 KV 캐시 신호에 매핑하여 17,000개에 달하는 전체 Fleet에서 메모리 부족을 실시간으로 파악할 수 있게 되었습니다. (워크로드에 따라 Gateway는 큐 깊이 또는 실행 중인 동시 실행 상태와 같은 다른 신호를 기반으로 라우팅할 수도 있습니다.)

실제 프로덕션 부하 상황에서 기본 리전이 고대역폭 메모리(HBM) 한도에 가까워지자 Gateway는 클러스터가 40% KV 캐시 사용률 기준을 넘는 순간 포화도를 감지한 후, 자동으로 오버플로를 다음 정상 리전으로 라우팅하기 시작했습니다. 운영자의 개입은 전혀 필요하지 않았습니다. 여러 리전에서 실행하는 데 따르는 복잡성이 사용자에게 전혀 영향을 미치지 않았습니다.

성과

이 GKE Inference Gateway 설정은 실시간 KV 캐시 사용률을 기반으로 트래픽을 라우팅하여 전 세계에 분산되어 있는 컴퓨팅 용량을 하나의 통합 엔진으로 효과적으로 풀링합니다. 이 배포 환경에서는 라우팅 오버헤드가 거의 발생하지 않는 상태에서 리전 세 곳에서 처리량이 선형에 가깝게 증가하는 결과가 나타났습니다.

이는 곧 '비용 대비 인텔리전스'를 극대화하는 결과로 이어집니다. 즉, 자본을 낭비하지 않고 Fleet에 추가하는 모든 가속기에서 거의 완벽하게 비례하는 성능을 이끌어내는 것입니다.

팀에 미치는 영향

분산형 추론 배포 환경을 자체적으로 빌드할 계획이라면 이 작업에서 얻은 5가지 교훈을 주목해야 합니다.

더 스마트한 부하 분산은 투자 대비 효과를 충분히 발휘합니다. 라운드 로빈 라우팅은 메모리 또는 컴퓨팅 부족을 확인할 수 없기 때문에 고가의 GPU 용량을 낭비합니다. 실시간 애플리케이션 신호를 기반으로 라우팅하면 단편화된 리전별 클러스터를 하나의 효율적인 Fleet으로 전환할 수 있습니다. 이는 하드웨어가 활용되지 못한 채 방치되는 것과 부족한 컴퓨팅 용량을 90% 이상 활용하는 것의 차이입니다.
에이전트형 워크로드는 병목 현상을 변화시킵니다. 컨텍스트 윈도우가 매우 큰 장기 실행 에이전트는 컴퓨팅 용량이 고갈되기 훨씬 전에 메모리를 소진합니다. 라우팅 계층에서 메모리 부족을 감지하지 못하면 VRAM이 가득 찬 상태에서도 컴퓨팅 용량이 활용되지 못한 채 방치됩니다. KV 캐시 사용률을 퍼스트 클래스 라우팅 신호로 활용해야 합니다.
AI 트래픽은 웹 시대의 가정을 무너뜨립니다. 기존의 부하 분산기는 1초 미만의 트랜잭션에 맞게 조정되어 있지만 LLM 요청은 몇 분 동안 실행될 수 있습니다. AI 규모의 지연 시간을 고려하여 연결 한도와 제한 시간을 미리 계획하지 않으면 프로덕션 환경에서 연결이 중단될 수 있습니다.
라우팅 계층은 네이티브 서빙 패턴과 통합되어야 합니다. 분산형 LLM 엔진은 마스터-워커 토폴로지를 채택하고 있어 특정 Pod만 트래픽을 처리할 수 있습니다. Gateway를 LeaderWorkerSet(LWS)과 같은 네이티브 Kubernetes 구성과 페어링하면 별도의 추가 설정 없이도 전역 라우팅이 로컬 Pod 토폴로지를 유지하므로 팀에서 커스텀 프록시 인프라를 빌드할 필요가 없습니다.
대규모 파운데이션 모델 빌더의 경우 개방형의 이식 가능한 스택을 선택해야 합니다. 최첨단 규모로 운영되는 팀의 경우 가장 심각한 용량 단편화 문제에 직면하게 되므로 가용 용량이 있는 리전이라면 어디서든 컴퓨팅 리소스를 찾아야 합니다. GKE의 LLM-d와 같은 개방형의 이식 가능한 추론 스택을 사용하면 서빙 아키텍처를 단일 클러스터, 리전 또는 맞춤형 인프라에 고정할 필요 없이 컴퓨팅 용량이 있는 곳이라면 어디서나 활용할 수 있습니다.

다음 단계

멀티 클러스터 GKE Inference Gateway를 통해 분산형 가속기 효율성을 극대화하고 전역적인 리전 간 부하 분산을 설정할 준비가 되셨나요?

직접 배포하기: 멀티 클러스터 GKE Inference Gateway 설정
아키텍처 이해하기: 멀티 클러스터 GKE Inference Gateway 소개
이 게시물에서 다룬 리전 간 스필오버 동작에 대해 자세히 알아보기: 탄력적인 리전 간 고가용성 소개 및 탄력적인 리전 간 고가용성 구성

AI 인프라를 위한 동적 용량 관리

Fri, 02 Oct 2026 04:00:00 +0000

인터넷은 수십억 명의 사람과 모바일 기기를 연결하여 모든 사람의 손에 컴퓨터를 쥐여주었습니다. 이제 우리는 다음 번의 큰 기술 변화의 한가운데에 있으며, 수백만 개의 자율 AI 에이전트를 배포하여 직원 및 최종 사용자와 함께 작업하고 있습니다. 오늘 Google Cloud는 조직이 프로젝트 수준의 AI 지출을 관리하고 토큰 쇼크를 없앨 수 있도록 돕는 Gemini Enterprise용 새로운 FinOps 제어 기능을 발표했습니다. 하지만 에이전트 시대의 엄청난 규모로 인해 인프라를 포함한 스택의 모든 레이어에 새로운 제약이 가해지고 있습니다. AI 워크로드는 아키텍처를 설계하기가 어렵고 리소스 집약적이며 버스트가 잦은 것으로 악명이 높습니다. 이로 인해 확장 병목 현상이 발생하고 활용도가 낮거나 잘못 활용된 컴퓨팅 리소스가 대량으로 발생할 수 있습니다.

조직은 인프라 투자에서 더 많은 가치를 추출하는 데 도움이 되는 인사이트가 필요합니다. 이 블로그에서는 예측 가능한 비용과 성능으로 단일의 유연한 기반에서 엔터프라이즈 및 AI 애플리케이션을 실행하는 데 도움이 되는 동적 용량 관리 , 즉 예약 및 활용 전략에 대한 권장사항을 소개합니다. 이러한 기능은 워크로드에 유연한 가격 책정 및 할인을 제공하는 주문형, 스팟, 약정 사용 할인 (CUD) 소비 모델을 보강하도록 설계되었습니다. 그럼 시작하겠습니다.

간단한 요약

동적 용량 관리를 구현하는 세 가지 방법:

계획된 이벤트의 용량을 예약합니다. 캘린더 모드를 사용하여 계획된 이벤트에 앞서 미션 크리티컬 리소스 (GPU, TPU, 일부 VM 제품군)를 예약하거나, 동적 워크로드 스케줄러의 flex-start 모드를 사용하여 시작 시간이 유연한 일괄 작업의 비용을 최적화할 수 있습니다. 용량을 확보하면 해당 리소스는 지정된 기간 동안 보장됩니다.
모든 애플리케이션에 대한 대체 계획을 수립하여 서비스 연속성을 유지합니다. 관리형 인스턴스 그룹 (MIG)을 사용하여 자동화된 우선순위 지정 하드웨어 대체 목록을 정의하면 선호하는 옵션을 사용할 수 없을 때 앱이 자동으로 다음 승인된 컴퓨팅 옵션으로 전환됩니다.
단일 적응형 컨트롤 플레인에서 전체 용량 관리 수명 주기를 자동화합니다. Google Kubernetes Engine (GKE)은 커스텀 컴퓨팅 클래스를 사용하는 폴백 목록부터 동적 리소스 할당을 통한 세분화된 하드웨어 슬라이싱에 이르기까지 전체 프로세스를 조정하는 에이전트 네이티브 환경을 제공하므로 에이전트는 안전한 샌드박스와 컨테이너에서 빠르게 스핀업할 수 있으며, GKE는 즉시 리소스를 동적으로 재할당합니다.

아키텍처 유연성이 중요한 이유

기업의 90%가 향후 3년 내에 에이전트를 배포하기를 원하지만, 현재 IT 설정으로 부하를 처리할 수 있다고 확신하는 IT 리더는 17%에 불과합니다. 이러한 워크로드에는 고유한 성능 요구사항이 있으므로 조직에서는 가속기 (GPU, TPU)와 맞춤형 컴퓨팅, 메모리, 스토리지 비율을 갖춘 CPU를 포함한 특수 인프라를 도입하기 위해 경쟁하고 있습니다. 그러나 에이전트는 엔터프라이즈 애플리케이션과 데이터베이스에 액세스해야 하며, 그 양과 규모는 일반적인 인간 사용량을 훨씬 초과하는 경우가 많습니다. 에이전트와 에이전트가 상호작용하는 애플리케이션의 높은 수요를 처리하려면 동적 인프라가 필요합니다. 인프라팀은 이러한 요구사항을 충족하기 위해 Google의 Axion과 같은 맞춤 설계된 프로세서를 활용할 수 있지만 하드웨어만으로는 완전한 솔루션이 될 수 없습니다. 또한 인프라를 현명하게 사용하고 실행 비효율성을 해결하여 스택 전반에 걸쳐 더 많은 유연성을 확보할 수 있는 방법도 필요합니다.

인프라 제약 극복 방법

이러한 유연성을 확보하려면 예측 가능한 수요에 대한 리소스를 확보하고 예측할 수 없는 수요에 대응하기 위한 자동화를 구축하는 두 가지 접근방식이 필요합니다. 이 두 가지를 결합하면 계획된 이벤트에 대한 용량을 미리 예약할 수 있으며 인프라가 수동 개입 없이 예상치 못한 변경사항에 적응할 수 있습니다.

1. 예정된 이벤트의 용량 예약

동적 워크로드 스케줄러를 사용하면 예정된 마일스톤, 오프라인 학습 또는 예상되는 수요 급증에 앞서 미션 크리티컬 용량을 확보할 수 있습니다. 필요한 리소스를 미리 예약하면 지출을 최적화하고 필요한 컴퓨팅 리소스에 액세스할 수 있습니다. 동적 워크로드 스케줄러는 하드웨어 가속기 (TPU 및 GPU)와 일부 CPU를 두 가지 모드로 지원합니다.

Flex-start 모드: 일괄 처리, 모델 학습, 오프라인 미세 조정과 같이 지연 시간에 덜 민감한 워크로드에 사용합니다. 리소스를 즉시 요청하는 대신 정의된 기간 요청을 제출하면 시스템이 작업을 지능적으로 큐에 추가하고 용량이 확보되는 즉시 리소스를 프로비저닝합니다. 이를 통해 비용 효율성을 극대화하고 수요가 높은 가속기를 확보할 수 있는 능력을 크게 향상할 수 있습니다.
캘린더 모드: 주요 제품 출시, 예정된 마이그레이션, 계절적 트래픽 급증과 같이 시간 제약이 있는 미션 크리티컬 이벤트에 사용합니다. 이벤트의 정확한 시작일과 종료일을 지정하면 미래용 예약이 생성됩니다. 이렇게 하면 이벤트가 시작될 때 요청된 용량을 사용할 수 있습니다.

2. 모든 애플리케이션에 대한 대체 계획을 수립하여 서비스 연속성 유지

모든 트래픽 급증을 예측할 수 있는 것은 아닙니다. 또한 속보나 갑작스러운 시장 변화로 인해 사용자 활동이 급증하는 등 예상치 못한 트래픽에 대비한 계획도 세워야 합니다. 서비스가 중단 없이 필요한 리소스를 확보하려면 허용 가능한 하드웨어 구성의 자동화된 우선순위 시퀀스인 대체 계획이 필요합니다. 이 전략은 다음과 같은 이점이 있습니다.

단일 VM 유형, 크기 또는 구성에서 워크로드를 분리합니다. 이러한 광고는 선호하는 옵션을 사용할 수 없는 경우 수동 개입 없이 실행할 수 있습니다.
최신 VM 세대를 기본 선택으로 채택하고 이전 세대를 자동 폴백 옵션으로 유지하여 점진적인 기술 새로고침을 실행할 수 있습니다.

Google Compute Engine에서 컨테이너화되지 않은 워크로드를 실행하는 경우 관리형 인스턴스 그룹 (MIG)의 인스턴스 유연성 과 대량 VM 생성을 통해 용량을 동적으로 관리할 수 있습니다. 인스턴스 유연성을 사용하면 단일 머신 유형으로 제한되지 않고 VM 인스턴스에 여러 머신 유형을 지정할 수 있습니다.

작동 방식: 선호하는 머신 유형을 일시적으로 사용할 수 없는 경우 MIG는 실시간 용량을 기반으로 목록에서 호환되는 대체 머신 유형을 자동으로 프로비저닝합니다. 리전 내에서 MIG가 검색할 수 있는 여러 영역을 지정하여 위치 유연성과 결합하면 프로비저닝 성공률을 크게 개선할 수 있습니다. MIG에서 스팟 VM을 사용하는 경우 Compute Engine은 스팟 용량 신호와 자동으로 통합되어 예상 가동 시간이 더 길고 선점 위험이 낮은 머신 유형의 우선순위를 지정합니다.

또한 기준 디스크 기본값을 설정하고 디스크 재정의를 구성하여 인스턴스 유연성을 블록 스토리지 계층으로 확장 할 수 있습니다. 이렇게 하면 VM이 다른 머신 유형으로 폴백될 때 스토리지가 이에 맞게 조정됩니다.

작동 방식: 대부분의 경우 인스턴스 템플릿에서 '디스크 유형'을 완전히 생략하고 기본 옵션을 사용하면 됩니다. 하지만 연결된 VM보다 수명이 긴 데이터 디스크의 경우 여러 VM 세대에 걸쳐 빠르고 내구성이 뛰어난 Hyperdisk를 사용 설정할 수 있습니다.

Compute Engine은 가상 머신을 사용하는 조직에 인스턴스 유연성을 제공하는 반면, GKE는 한 단계 더 나아가 단일 컨트롤 플레인에서 전체 용량 수명 주기를 자동화합니다. GKE 커스텀 ComputeClasses를 사용하면 플랫폼팀은 다차원 대체 목록을 설계하고, 다양한 VM 머신 계열, 크기, 비율을 자동으로 결합하고, 여러 영역에 걸쳐 확장하고, 주문형 VM과 스팟 VM 간에 전환할 수 있습니다. 동적 워크로드 스케줄러를 용량 타겟으로 사용하고 커스텀 ComputeClass를 사용하여 정책과 우선순위를 정의하면 용량 관리 수명 주기를 완전히 자동화할 수 있습니다.

작동 방식: ComputeClass를 설정하면 GKE가 선호하는 노드 구성을 사용할 수 없는 경우 자동으로 감지하고 우선순위에 따라 사전 승인된 대체 옵션으로 대체합니다. 활성 마이그레이션을 사용 설정하면 용량이 확보되는 즉시 GKE가 워크로드를 우선순위가 더 높은 노드 구성으로 정상적으로 마이그레이션합니다. 부팅 디스크와 같은 수명이 짧은 디스크의 경우 GKE는 인스턴스 계열에 따라 적절한 기본값을 동적으로 선택합니다. 하지만 VM보다 수명이 긴 장기 디스크의 경우 Hyperdisk를 사용할 수 있습니다.

또 다른 GKE 기능인 동적 리소스 할당은 개발자가 리소스 소비 방식을 결정하는 고급 규칙을 정의할 수 있도록 하여 낭비적인 전부 또는 전무 하드웨어 할당을 없애는 데 도움이 됩니다.

작동 방식: 애플리케이션이 전체 GPU 또는 TPU를 요청하는 대신 총 메모리 또는 코어 수와 같은 정확한 파라미터를 지정하면 시스템이 완벽한 하드웨어 슬라이스를 할당하여 사용률을 극대화하고 비용을 절감할 수 있습니다.

동적 인프라를 향한 다음 단계로 나아가세요

AI를 확장한다고 해서 인프라 예산을 선형적으로 확장하거나 기술 부채를 더 많이 축적해야 하는 것은 아닙니다. 이러한 예시에서 볼 수 있듯이 적절한 도구를 사용하면 제약사항을 극복하고 컴퓨팅 투자에서 얻는 가치를 획기적으로 바꿀 수 있습니다. 시작하는 방법은 다음과 같습니다.

워크로드를 감사하여 즉각적인 비용 절감 효과를 얻으세요. 현재 단일 VM 계열, 머신 유형 또는 가용성 영역에 긴밀하게 결합된 애플리케이션을 식별하고 실행 가능한 대체 하드웨어 구성을 매핑합니다. 기존 구성을 넘어 워크로드 수준의 목표에 따라 더 나은 서비스를 제공하거나 대안으로 작용할 수 있는 새로운 컴퓨팅 옵션을 평가합니다. 그런 다음 Compute Engine MIG, 대량 VM 생성 또는 GKE Custom ComputeClasses를 사용하여 자동으로 채택하고 장애 조치 목록에 통합합니다.
최소 지출 약정으로 대폭 할인된 가격 이용: 지속 사용 할인이 자동으로 적용되거나 Compute의 유연한 약정 사용 할인 가입 시 최대 63% 가 할인됩니다. 이 할인은 특정 머신 유형이나 위치와 관계없이 사용한 리소스에 따라 적용됩니다.
계정팀과 협력: Google Cloud 계정팀에 문의하여 맞춤형 용량 관리 전략을 수립하고 자동화된 대체 목록을 구성하세요.

고급 보안 거버넌스를 통한 자율 에이전트 역량 강화

Thu, 01 Oct 2026 21:00:00 +0000

AI 에이전트는 최고의 내부자입니다. 에이전트에게 이메일을 읽고, 데이터베이스를 쿼리하고, API 호출을 트리거할 수 있는 권한을 부여합니다. 정보를 검색하는 데 그치지 않고 조치를 취합니다.

에이전트는 생산성 향상과 고객 경험 개선에 엄청난 잠재력을 제공하지만 새로운 보안 문제도 야기합니다. 최신 AI 인프라 현황 보고서에 따르면 기술 리더의 79% 가 추론 확장 시 가장 큰 과제로 보안, 거버넌스 또는 운영을 꼽았습니다.

기존 보안 도구의 역할은 여전히 중요하지만 위협 모델은 근본적으로 바뀌었습니다. 자율 워크플로는 엔터프라이즈 위험을 재정의했으므로 보안을 저해하지 않으면서 에이전트에게 필요한 액세스 권한을 제공하는 것이 중요합니다.

에이전트형 역설

성공의 길은 거버넌스를 혁신의 동인으로 보는 것에서 시작됩니다. 에이전트가 유용성과 보안을 모두 갖추려면 액세스 권한뿐만 아니라 가드레일도 필요합니다. 하지만 IT 의사 결정권자의 35% 는 에이전트 도입을 가로막는 주요 문제로 다중 시스템 액세스에 대한 보안 부족을 지적하고 있습니다.

에이전트는 방어자가 보호해야 하는 표면 영역을 확장하고, 공격자가 에이전트가 처리하는 데이터를 통해 에이전트의 로직을 하이재킹할 수 있는 도구 포이즈닝 및 간접 프롬프트 인젝션을 포함한 새로운 위협을 도입할 수 있습니다. 에이전트가 작업을 성공적으로 수행하는 데 필요한 동적 권한을 관리하는 것도 특히 레거시 보안이 오늘날의 자동화된 위협에 맞게 설계되지 않았다는 점을 고려할 때 상당한 과제가 될 수 있습니다.

생각의 사슬 보호

더 많은 ID 및 액세스 문제를 해결하는 것과 함께 방어자는 네트워크 계층과 모델을 모두 보호하는 것이 중요합니다.

보안 리더는 점점 더 초점을 보안 침해 방지에서 출처 확인으로 옮겨 간접적인 프롬프트 인젝션을 포함한 오용을 방지하고 있습니다.

인프라 관점에서 AI와 관련된 가장 큰 보안 우려사항은 무엇인가요?

차단에서 관리로

에이전트 AI가 제기하는 새로운 보안 과제를 살펴보았습니다. 시스템을 단순히 잠그는 것으로는 문제를 해결할 수 없습니다. 이는 자율 에이전트의 목적에 어긋나기 때문입니다.

많은 조직이 더 나은 감독을 위해 통합된 풀 스택 클라우드 플랫폼으로 전환하고 있습니다. 설문에 참여한 경영진 중 69% 는 풀 스택 플랫폼을 필수 요건으로 평가하고 있으며, 80% 는 데이터 규정 준수가 플랫폼 선택을 결정하는 가장 중요한 요소라고 말합니다.

안전한 AI 프레임워크 (SAIF)와 같은 프레임워크를 도입하고 Gemini Enterprise Agent Platform과 같은 목적에 맞게 빌드된 플랫폼으로 중앙 컨트롤 플레인을 이전함으로써 조직은 세 가지 주요 영역에서 위험을 관리할 수 있습니다.

보안을 우선으로 하는 기본 설정: AI 개발 프로세스에 보안을 직접 내장하여 프롬프트 인젝션을 포함한 위협에 선제적으로 대응합니다.
에이전트 거버넌스 및 감독: 에이전트에 맞게 빌드된 권한 및 ID 관리를 도입하여 에이전트 상호작용을 더 효과적으로 제어하고, 사각지대를 노출하며, 위험 도구를 제한합니다.
인간 참여형 제어: 에이전트가 중요한 작업을 진행하기 전에 인간의 승인이 필요한 경우 자동으로 플래그를 지정하는 명확한 규칙을 적용합니다.

거버넌스가 성공으로 이끄는 길잡이가 되어 줍니다

최신 보안 기반의 진정한 가치는 혁신을 장려하는 능력에 있습니다. 조직은 강력한 거버넌스를 통합 기반에 직접 포함함으로써 가장 민감한 비즈니스 핵심 워크로드 전반에 에이전트를 안심하고 배포할 수 있습니다.

에이전트 시대의 리더들은 보안을 발판으로 삼아 안전하게 혁신하고 경쟁사보다 빠르게 확장할 수 있도록 스택을 재설계하고 있습니다.

AI 인프라 현황 보고서에서 엔터프라이즈 리더들이 에이전트 시대에 맞게 보안을 어떻게 재고하고 있는지 자세히 알아보세요.

AI 에이전트가 준비되었습니다. 그렇다면 데이터는 어떤가요?

Thu, 01 Oct 2026 21:00:00 +0000

조직이 AI 이니셔티브를 확장하는 데 있어 가장 큰 병목 현상 중 하나는 무엇일까요? 오늘날 모델의 기능이 아니라 비즈니스 컨텍스트와 시맨틱 의미에 대한 액세스 권한이 문제입니다.

에이전트 시대에 기업은 단순히 데이터를 저장하는 것을 넘어 신뢰할 수 있는 컨텍스트로 데이터를 활성화하여 수동적인 기록 시스템에서 선제적인 행동 시스템으로 전환해야 합니다.

하지만 AI 에이전트는 비선형 속도로 작동합니다. 예를 들어 단일 프롬프트로 에이전트가 여러 시스템에서 독립적으로 탐색, 쿼리, 실행을 수행하도록 트리거할 수 있어 기본 인프라에 부담을 줄 수 있습니다. 컴퓨팅, 네트워킹, 스토리지 레이어가 에이전트 AI에 최적화되어 있지 않으면 그 위에 있는 데이터 플랫폼이 제대로 작동하지 않습니다.

Google Cloud의 인프라 현황 보고서 에 따르면 조직의 83% 가 프로덕션급 에이전트 AI 시스템을 지원하려면 인프라를 업그레이드해야 한다고 생각하는 것은 당연한 일입니다.

이 문제를 해결하기 위해 Google Cloud는 2026년 Google Cloud Next에서 데이터, AI 모델, 운영 데이터베이스를 단일 작업 시스템으로 통합하는 에이전트형 데이터 클라우드를 도입했습니다. 에이전트형 데이터 클라우드가 작동하려면 칩에서 모델에 이르기까지 AI 네이티브여야 합니다. 기본 인프라는 에이전트 부하를 수용할 수 있어야 합니다.

Google의 에이전트형 데이터 클라우드

적절한 인프라 기반이 에이전트형 데이터 클라우드에 어떤 힘을 실어주어 오늘날 조직이 직면한 가장 큰 데이터 문제를 해결할 수 있는지 살펴보겠습니다.

컨텍스트 부족 극복

에이전트형 시스템이 효과적으로 작동하려면 분산된 데이터 시스템과 기존 아키텍처에서 자주 발견되는 컨텍스트에 액세스할 수 있어야 합니다. 이로 인해 에이전트가 이러한 컨텍스트를 파악하기 어려워 불완전하고 부정확한 결과가 나올 수 있습니다. 실제로 Google Cloud 보고서에 따르면 IT 리더의 43% 가 '레거시 API 및 데이터 소스와의 통합이 어려움'을 에이전트 AI 인프라의 가장 큰 허점으로 꼽았습니다.

하지만 조직은 복잡성과 비용을 늘리지 않고는 대규모 데이터 세트를 이동하여 AI에 연결할 수 없습니다.

Google의 에이전트형 데이터 클라우드는 개방적이고 유연한 인프라에서 실행되는 경계 없는 레이크하우스 를 활용하여 이 문제를 해결합니다. 에이전트는 개방형 표준 (Apache Spark, Apache Iceberg)을 통해 BigQuery 및 Spanner와 같은 강력한 기본 엔진에 액세스하여 마치 로컬 데이터인 것처럼 환경 전반에서 데이터를 읽고, 추론하고, 활성화할 수 있으므로 기존 설정의 지연 시간과 비용을 우회할 수 있습니다.

불필요한 수동 작업에서 벗어나기

연결되지 않은 시스템의 패치워크에서 에이전트를 확장하면 상당한 병목 현상이 발생할 수 있습니다. Google Cloud의 연구에 따르면 리더의 81% 가 AI를 확장할 때 예상치 못한 비용이 발생하는 주요 원인으로 운영 복잡성과 엔지니어링 오버헤드를 꼽았습니다 . 서로 다른 시스템 전반에 걸쳐 AI 에이전트를 연결하기 위해 엔지니어가 수동으로 작업하는 데 드는 시간을 그 이유로 들었습니다.

생각에서 행동으로 옮기려면 에이전트는 분석 소스와 운영 소스 모두에서 실시간 데이터를 연결할 수 있어야 합니다. 이를 위해서는 수직적 통합이 필요합니다. 모델, 데이터 시스템, 기본 가속기가 공동 설계된 AI 네이티브 인프라를 기반으로 에이전트형 데이터 클라우드를 빌드하면 네트워크 홉이 줄어들고 도구가 더 잘 통합됩니다. 이 통합 시스템을 사용하면 에이전트가 일반적인 엔지니어링 오버헤드 없이도 인사이트에 도달하고 안전한 트랜잭션을 트리거할 수 있습니다.

데이터에 신뢰와 지식 제공

에이전트가 데이터를 발견하고 쿼리하는 것만으로는 충분하지 않습니다. 안전하고 정확한 조치를 취하려면 에이전트에게 풍부한 컨텍스트와 비즈니스 로직도 필요합니다. 그러나 AI 모델 그라운딩에 사용되는 특화된 고처리량 벡터 데이터베이스가 부족하다는 점을 주요 인프라 격차로 꼽은 리더가 36% 에 달하며, 이는 에이전트에게 컨텍스트를 제공하는 능력을 저해하는 요인으로 작용합니다.

에이전트가 잠재력을 최대한 발휘하려면 기존 ERP와 서드 파티 CRM을 포함한 데이터 시스템을 실시간으로 읽고 쓸 수 있도록 빌드된 기반이 필요합니다. 또한 3주 전에 사용자가 설정한 선호도를 기억한 상태로 현재 복잡한 작업을 수행할 수 있는 장기 기억 능력이 필요합니다. 이러한 실시간 자동화가 없으면 에이전트는 모든 쿼리에 대해 데이터를 다시 처리해야 합니다.

AI에 컨텍스트를 제공하기 위해 조직은 Knowledge Catalog를 사용하여 데이터 레이크의 데이터를 집계하고 보강하며 에이전트형 검색을 지원하고 있습니다. 비정형 데이터에서 의미를 추출하고 시맨틱스를 자동으로 생성하는 카탈로그는 활성 추론 레이어 역할을 합니다. 에이전트가 올바른 컨텍스트를 검색할 수 있도록 이 카탈로그는 처리량이 높은 인프라로 뒷받침되어야 합니다.

앞으로의 방향

AI를 진정한 경쟁 우위로 전환하려면 연결된 활성 데이터 생태계를 구축해야 합니다. 파일럿에서 프로덕션으로 전환하려면 에이전트가 모든 데이터에 원활하게 액세스할 수 있어야 하며, 이를 위해서는 에이전트 시대의 요구사항을 처리할 수 있는 인프라가 지원되어야 합니다. 2026년 이후의 승자는 반드시 가장 스마트한 에이전트를 보유한 기업이 아닐 것입니다. 이들은 에이전트에 적절한 지식을 안전하고 비용 효율적으로 대규모로 제공할 수 있는 사람들입니다. 데이터는 에이전트 시대에 맞게 준비되어 있나요?

에이전트 AI 시대의 인프라 현황 보고서에서 리더들이 AI에 최적화된 아키텍처 접근방식을 어떻게 취하고 있는지 확인해 보세요.

판도를 바꾸는 기술: 인프라 코드 보호를 위한 에이전트 AI 사용

Wed, 30 Sep 2026 22:00:00 +0000

AI는 전례 없는 속도로 소프트웨어 개발을 가속화하고 있습니다. 하지만 코드 생성 규모가 커지면서 코드 보안 문제도 증가하고 있으며, 특히 AI를 기반으로 한 새로운 취약점 악용 방식이 등장하고 있습니다. Google의 AI 및 인프라팀은 이러한 과제에 대응하기 위해 보안 접근방식을 혁신하고 있습니다. 이 글에서는 Google에서 새롭게 개발한 AI 네이티브 에이전트 방식을 소개합니다. 이 방식은 정밀하고 광범위한 취약점 스캔 및 패치를 Google의 소프트웨어 개발 수명 주기에 체계적으로 통합합니다. Google은 Google 인프라에 배포되는 수억 줄의 코드에서 모든 코드 변경사항을 상시 스캔하여 매달 수백 건의 취약점이 코드베이스나 프로덕션 환경에 도달하기 전에 차단하는 방식으로 Google의 글로벌 네트워크와 AI 인프라, 사용자를 보호하고 있습니다.

솔루션 아키텍처 및 구현

광범위한 제출 전 에이전트형 스캔: 진행 중인 소프트웨어 개발 과정에 보안 통합

전통적으로 기술 업계는 대규모 일회성 보안 스캔에 의존하는 경우가 많았습니다. 하지만 이러한 스캔은 속도가 느리고 충분한 컨텍스트를 제공하지 못해 취약점이 너무 늦게 발견되는 경우가 많습니다. Google은 이와 달리 제출 전 스캔에 중점을 두고, AI 에이전트를 사용하여 스택의 모든 레이어에서 발생하는 각 코드 체크인을 실시간으로 평가합니다. 개발자가 이미 사용 중인 도구에 제출 전 스캔을 통합하면 보안 검사도 규칙 검사, 가독성 검토 같은 여타 소프트웨어 개발 도구처럼 지속적이고 일상적인 프로세스의 일부가 됩니다. 또한 AI의 관점에서도 대규모로 일회성 스캔을 수행하는 것보다 각각의 코드 변경사항을 개별적으로 스캔하는 편이 훨씬 적은 컨텍스트를 필요로 하므로 스캔 효과를 크게 높일 수 있습니다.

국소적 위협 모델의 중요성

Google은 이 이니셔티브를 위해 오픈소스 멀티 에이전트 검토 하네스인 Mantis를 발전시켜 강력한 국소적 위협 모델 집단과 연결하는 방식으로 보안 에이전트의 정밀도를 높였습니다. 이 위협 모델은 정적이고 분리된 문서에 의존하는 대신 실제 코드베이스 메타데이터를 활용합니다. 스캔 에이전트는 패키지와 라이브러리 전반의 종속 항목 호출 그래프를 활용해 위협 모델 컨텍스트를 확장하고 미세 조정함으로써 정확도를 한층 더 끌어올립니다. 위협 모델을 상시 취약점 스캔 프로세스에 통합하여 개발자가 위협 요소와 종속 항목을 꾸준히 업데이트하도록 유도함에 따라 모델이 최신 상태로 유지됩니다. 국소적이면서 정밀한 위협 모델 데이터를 활용하면 정확도를 크게 높일 수 있으며, 일부 사례에서는 거짓양성률을 3%까지 낮출 수 있었습니다.

전문 분류 에이전트로 개발 속도 향상

코드 체크인의 일환으로 수행되는 취약점 스캔은 엔지니어링 생산성을 저해하지 않도록 코드를 작성하는 개발자나 에이전트에게 신속하게 결과를 제공할 수 있어야 합니다. 응답 지연 시간을 단축하기 위해 Google은 2단계 검증 프로세스를 실행합니다. 먼저 신속한 경량형 스캔을 실행한 후 전문 분류 에이전트를 통해 그 결과를 검증합니다. 이 에이전트는 추상 구문 트리 파싱, 호출 그래프 순회, 사전 색인된 도메인 안전 규칙을 활용해 실제 코드 구조를 프로그래매틱 방식으로 검사하여 공격자가 취약한 경로에 실제로 도달할 수 있는지 입증합니다. 이 에이전트의 정밀도는 92%에 달하며 작업 완료 시간은 1분 미만입니다. 그런 다음 야간 통합 테스트에 통합된 제출 후 스캔이 두 번째 방어 계층 역할을 하면서 사용량이 적은 시간대의 컴퓨팅 리소스를 활용해 여러 변경 과정에서 새로 도입되었을 수 있는 취약점을 검사합니다.

전체 과정을 완성하는 버그 수정 에이전트

취약점을 찾는 것은 문제 해결의 절반에 불과합니다. Google 솔루션의 마지막 구성요소는 자동화된 버그 수정 에이전트입니다. 이 에이전트는 스캔 결과와 생성된 증명(취약점이 어떻게 실행되는지를 보여주는 코드 스니펫)을 활용하여 Google의 내부 코딩 표준에 부합하는 정밀한 수정사항을 자율적으로 생성합니다. 에이전트는 기존 변경 요청 검토 과정의 일환으로 수정사항을 제출하여 사람의 검토를 받게 하며, 이를 통해 취약점 탐지부터 해결까지 걸리는 시간을 한층 더 단축합니다.

교훈 및 권장사항

소프트웨어 개발 수명 주기에 상시 스캔을 바로 통합한 것은 Google에 혁신적인 변화를 가져왔습니다. 에이전트의 제안은 널리 채택되며 수많은 취약점이 코드베이스에 유입되는 것을 방지하고 있습니다. 보안을 강화하고자 하는 조직이라면 다음 원칙에 따라 유사한 AI 네이티브 접근방식을 도입할 수 있습니다.

시스템 분리: 편향을 방지하기 위해 개발, 스캔, 분류 에이전트별로 하네스, 규칙, 컨텍스트를 서로 분리합니다. 경량 AI 스캔과 결정론적인 구조 검증을 함께 사용하면 지연 시간을 줄이고 정확도를 높일 수 있습니다.
현명한 컨텍스트 사용: 기존 위협 모델을 에이전트에 제공합니다. 정밀한 컨텍스트야말로 거짓양성률을 줄이는 핵심입니다. 최신 상태의 위협 모델은 제출 전 스캔의 참양성률을 높여 팀이 기본적으로 높은 수준의 보안 상황을 갖추도록 해줍니다.
우수한 하네스 구축: 기본 모델 선택도 중요하지만 멀티 에이전트 하네스를 사용하면 모델 선택에 따른 편차를 보완하여 상당한 효과를 얻을 수 있습니다.
수정 자동화: 휴먼인더루프 방식으로 수정사항까지 제안하는 에이전트를 통해 해결 시간을 더욱 단축합니다.

자체적인 AI 네이티브 보안 혁신을 시작하고 싶다면 오픈소스로 제공되는 Mantis를 활용해 보세요. 또한 사이버 보안의 기본 원리와 이 에이전트형 파이프라인을 구동하는 다른 플랫폼인 Google Cloud, Gemini Enterprise는 물론, Trillium 및 Ironwood TPU에서 실행되는 Gemini 모델에 대해서도 자세히 알아볼 수 있습니다. 아울러 에이전트형 취약점 스캔 및 해결 방식이 Google Cloud의 보안 소프트웨어 개발 수명 주기(SDLC) 활동의 핵심 요소로서 Google Cloud 고객을 어떻게 보호하고 있는지도 참고할 수 있습니다.

_{이 솔루션을 제공하는 데 핵심적인 역할을 한 Stella Voutsina(수석 프로그램 관리자), Yulong Zhang(Mantis 선임 스태프 보안 엔지니어), Nick Galloway(스태프 보안 엔지니어, Mantis)에게 특별한 감사를 전합니다.}

AI 시대의 디지털 주권: 제어와 혁신 중 하나만 선택할 필요가 없습니다

Mon, 28 Sep 2026 10:00:00 +0000

엄격한 규정 준수 및 주권 요구사항이 있는 기업과 정부의 경우 민감한 정보를 온프레미스에 보관하면 최신 AI를 활용하지 못하는 경우가 많습니다. 이러한 조직은 세 가지 주요 위험을 관리하고 있습니다.

관할권 위험: 현지 규정의 변화, 지식 재산 보호의 필요성, 해외 데이터 액세스 요청의 가능성으로 인해 현지 데이터 처리가 필수적입니다.
경제적 독립: 해외 인프라 제공업체에 의존하면 중요한 서비스가 취약해질 수 있습니다.
지정학적 위험: 예측할 수 없는 글로벌 서비스 중단으로부터 중요한 지역 서비스를 보호해야 할 필요성

최근 1,400명 이상의 수석 IT 리더를 대상으로 AI 인프라 현황 보고서를 위한 설문조사를 실시한 결과, 48% 의 리더가 현지 데이터 보안 규정을 준수하기 위해 데이터 레지던시, 제어, 규정 준수를 지원하는 인프라를 우선적으로 고려하고 있다고 답했습니다.

하지만 온프레미스에 머무른다고 해서 최신 혁신 기술을 활용할 수 없는 것은 아닙니다. 조직은 이러한 격차를 해소하기 위해 하이브리드 (온프레미스 및 멀티 클라우드 솔루션)를 점점 더 많이 배포하고 있습니다. Google Cloud의 연구에 따르면 현재 조직의 52% 가 AI에 하이브리드 클라우드 접근 방식을 사용하고 있습니다.

이 접근방식을 사용하면 기업은 퍼블릭 클라우드의 막강한 원시 성능과 로컬 환경의 주권 및 규정 준수 이점을 균형 있게 활용하여 데이터가 상주하는 위치와 데이터에 액세스할 수 있는 사용자를 제어할 수 있습니다. 과거에는 이처럼 엄격한 데이터 규칙을 준수하는 조직이 고급 AI에 쉽게 액세스할 수 없었습니다. 자체 AI 시스템을 빌드하는 것도 너무 느리고 비용이 많이 들었습니다.

이러한 이유로 Google Cloud는 Google Distributed Cloud (GDC)를 도입했습니다. 자체 데이터 센터 또는 에지 등 사용자에게 필요한 곳이면 어디서나 GDC가 Google Cloud를 제공합니다. AI 워크로드 주권 요구사항을 충족하기 위해 두 가지 배포 모델로 제공됩니다.

에어 갭: Google Cloud 또는 공개 인터넷에 연결할 필요가 없는 완전한 오프라인 솔루션입니다. Google에서 원격으로 종료할 수 없습니다.
연결성: 기존 하드웨어에서 직접 실행되는 Google 관리형 통합 소프트웨어 수명 주기

GDC는 AI 워크로드에 최적화된 인프라, Gemini 또는 개방형 모델 옵션, 비용 효율적인 추론 서비스 등 완전한 온프레미스 AI 솔루션을 제공합니다. 이를 기반으로 데이터를 완전히 제어하면서 안전한 AI 에이전트를 빌드하고 실행할 수 있습니다.

온프레미스에서 소버린 AI 요구사항 충족

더 이상 데이터 제어와 AI 혁신 사이에서 선택할 필요가 없습니다. Google Distributed Cloud를 사용하면 세계 최고의 AI를 환경에 직접 도입하여 데이터를 완전히 사용자의 소유로 유지할 수 있습니다.

AI 인프라 현황 보고서에서 선도적인 기업의 하이브리드 전략을 살펴보세요.