컨테이너 및 Kubernetes

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의 데모를 살펴보세요.

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를 통해 개발에 참여하세요.

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

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

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

오늘 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 팀을 만나보세요. 세션에 대해 자세히 알아보세요.

GKE용 Wiz 런타임 센서 부가기능 출시: Kubernetes를 위한 턴키 방식의 위협 감지 기능

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

AI 시대에는 모든 것이 더 빠르게 변화하고 있으며, 보안 위협 또한 예외는 아닙니다. 과거에는 공격자가 취약점을 악용하는 데 몇 주가 걸렸지만 이제는 단 몇 분 만에 가능합니다.

저장된 아티팩트를 대상으로 하는 표준 취약점 스캔은 기본적인 설정 문제를 파악하는 데 유용하지만, 현재 진행 중인 공격을 감지하려면 실시간 런타임 보호가 필요합니다.

오늘 Google Kubernetes Engine(GKE)용 Wiz 런타임 센서 부가기능을 프리뷰 버전으로 새롭게 선보입니다. 이 기본 제공 통합을 통해 Wiz의 업계 선도적인 eBPF 런타임 위협 감지 기능을 Standard 및 Autopilot GKE 클러스터 모두에서 사용할 수 있으며, 간단한 배포, 자동화된 수명 주기 관리, 엔터프라이즈 사용자 인증 정보 보안, Fleet 전체 거버넌스 등의 혜택을 누릴 수 있습니다.

런타임 보안의 운영상 번거로움

보안 및 플랫폼 엔지니어링팀은 클러스터 내 런타임 방어 체계를 배포할 때 다음과 같은 공통적인 딜레마에 직면하곤 합니다.

배포 및 수명 주기 관리의 번거로움: 런타임 에이전트를 배포하려면 수십 또는 수백 개의 클러스터에서 서드 파티 소스의 설치를 관리해야 하는 경우가 많습니다.
사용자 인증 정보의 무분별한 확산 및 보안 위험: API 키를 Kubernetes 보안 비밀로 전달하고 순환하는 방식은 관리 오버헤드를 가중시키고 보안 위험을 초래합니다.
Fleet 전체 보안 적용 공백: 플랫폼팀에는 워크로드가 배포되고 트래픽을 수신하기 전에 모든 새 클러스터에 런타임 센서가 사용 설정되어 있는지 확인하는 기본 제공 정책 컨트롤러 기능이 없습니다.
성능 및 운영 오버헤드: 명시적이고 전략적인 리소스 제한이 없으면 런타임 에이전트가 워크로드 및 시스템 기능에 필요한 CPU와 메모리 가용량에 영향을 줄 수 있습니다.

Google Cloud와 Wiz는 GKE용 Wiz 런타임 센서를 통해 이러한 운영 장벽을 최소화했습니다. 이제 GKE에서 런타임 센서를 퍼스트 파티 관리형 플랫폼 부가기능으로 사용할 수 있습니다.

GKE용 Wiz 런타임 센서로 보안 공백 해결

GKE용 Wiz 런타임 센서는 센서 수명 주기를 간소화하고 자동화하여 중앙 보안 및 플랫폼 엔지니어링 워크플로를 연결합니다.

그림 1: 사용자 인증 정보 동기화, 센서 배포, 위협 원격 분석을 보여주는 대략적인 아키텍처

부가기능을 사용하면 GKE가 센서 배포, 사용자 인증 정보 삽입, 수명 주기 업데이트를 관리합니다. 런타임 보호를 플랫폼에 직접 빌드하면 관리 오버헤드가 줄어들고 Kubernetes Fleet에 다음과 같은 이점이 제공됩니다.

기본 Secret Manager 통합: 보안팀은 더 이상 클러스터 네임스페이스에 Wiz API 키를 배포할 필요가 없습니다. 이 부가기능은 GKE의 Secret Manager 보안 비밀 동기화 통합을 사용하여 전용 서비스 계정만 액세스할 수 있는 클러스터 외부의 중앙 집중식 사용자 인증 정보 저장소에 Wiz 사용자 인증 정보를 저장합니다.

GKE는 사용자 인증 정보를 자동으로 검색하여 런타임 센서 포드에 직접 삽입합니다. Secret Manager에서 키를 업데이트하면 클러스터를 다시 시작하거나 수동으로 개입하지 않아도 센서에 자동으로 동기화됩니다.

간소화된 사용 설정: Secret Manager에 Wiz 사용자 인증 정보를 추가한 후 플랫폼 운영자는 gcloud CLI 또는 GKE API를 사용하여 런타임 센서 부가기능을 사용 설정할 수 있습니다. GKE 컨트롤 플레인은 센서 구성요소 배포, 포드 수명 주기 관리, 노드 구성을 처리합니다.
보안 이그레스 및 프록시 지원: 공개 인터넷 액세스를 제한하는 환경의 경우 관리형 센서는 표준 HTTP 및 mTLS 프록시 구성을 지원합니다. 원격 분석은 이그레스 방화벽 정책을 위반하지 않고 Wiz로 다시 라우팅됩니다.
조직 정책을 통한 Fleet 전체 거버넌스: 플랫폼 보안 책임자는 커스텀 조직 정책 제약 조건을 사용하여 조직 전체에 규정 준수를 적용할 수 있습니다. 제약 조건을 사용하여 런타임 센서 부가기능을 사용 설정하지 않는 클러스터를 만들려는 시도를 거부할 수 있습니다. 이렇게 하면 악의적인 행위자가 런타임 감지를 피하기 위해 악성 인프라를 가동하는 것을 방지할 수 있습니다.
오버헤드를 최소화하는 커널 수준의 모니터링 가능성: Wiz 런타임 센서는 시스템 호출, 실행 중인 프로세스, 네트워크 연결, 파일 액세스를 지속적으로 모니터링합니다. 리버스 셸, 승인되지 않은 권한 에스컬레이션, 컨테이너 이스케이프, 안전하지 않은 아웃바운드 연결을 포함한 의심스러운 활동을 포착하는 동시에 워크로드 활동이 많은 경우에도 CPU 사용량을 낮게 유지합니다. 센서는 각 노드에서 고정된 메모리 한도를 사용하여 워크로드 밀도가 변경되더라도 일관된 성능을 보장합니다. 이는 애플리케이션 활동이 수시로 변동될 수 있는 AI 워크로드와 웹 서비스에서 특히 유용합니다.
별도의 자동 업데이트: 보안 위협과 제로데이 취약점은 정기적인 인프라 유지보수 기간을 기다려 주지 않습니다. GKE용 Wiz 센서 부가기능의 수명 주기는 GKE 클러스터 및 노드의 수명 주기와 별개로 운영됩니다. 센서는 Wiz에서 게시한 새로운 센서 버전의 업데이트를 주기적으로 출시하여 GKE 버전 업그레이드, 노드 풀 재생성 또는 워크로드 중단 없이 클러스터에 항상 최신 감지 규칙이 적용되도록 합니다.

작동 방식: 센서 배포 및 적용

Wiz 센서 부가기능을 사용 설정하는 과정은 플랫폼 관리자가 이미 GKE에서 익숙하게 사용하는 프로세스와 동일합니다. 표준 gcloud 명령어를 사용하면 클러스터 생성 중에 런타임 보호를 활성화하고, 기존 클러스터에 대해 사용 설정하고, Fleet 전반에 적용하는 동시에 Secret Manager에서 사용자 인증 정보를 안전하게 관리할 수 있습니다.

GKE에 Secret Manager에 대한 액세스 권한을 부여하는 등의 기본 요건은 설정 문서를 참조하세요.

Wiz Sensor 부가기능을 사용하여 클러스터 프로비저닝

Secret Manager에 저장된 사용자 인증 정보를 사용하여 관리형 Wiz 센서가 사용 설정된 새 GKE 클러스터를 프로비저닝하려면 다음 안내를 따르세요.

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create production-ai-cluster \\\r\n --zone=us-central1-a \\\r\n --release-channel=regular \\\r\n --workload-pool=${PROJECT_ID}.svc.id.goog \\\r\n --enable-secret-sync \\\r\n --enable-secret-sync-rotation \\\r\n --addons=WizSensor=ENABLED \\\r\n --wiz-sensor-registry-secret-uri=projects/${PROJECT_ID}/secrets/wiz-registry-secret/versions/latest \\\r\n --wiz-sensor-api-key-secret-uri=projects/${PROJECT_ID}/secrets/wiz-api-key-secret/versions/latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc060178d0>)])]>

GKE용 워크로드 아이덴티티 제휴 및 Secret Manager 보안 비밀 동기화가 사용 설정된 기존 실행 중인 클러스터에서 센서를 사용 설정하려면 다음 명령어를 실행합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters update production-ai-cluster \\\r\n --zone=us-central1-a \\\r\n --update-addons=WizSensor=ENABLED \\\r\n --wiz-sensor-registry-secret-uri=projects/${PROJECT_ID}/secrets/wiz-registry-secret/versions/latest \\\r\n --wiz-sensor-api-key-secret-uri=projects/${PROJECT_ID}/secrets/wiz-api-key-secret/versions/latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05f7e7d0>)])]>

조직 정책을 통한 Fleet 전체 보호 시행

커스텀 제약조건을 배포하여 조직 전체의 모든 새 GKE 클러스터에 런타임 센서를 설치하도록 요구할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'name: organizations/123456789012/customConstraints/custom.GKEWizSensorEnforced\r\nresource_types:\r\n - container.googleapis.com/Cluster\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition: resource.addonsConfig.wizSensorConfig.enabled == true\r\naction_type: ALLOW\r\ndisplay_name: Enforce Wiz Sensor on All GKE Clusters\r\ndescription: Mandates that all GKE clusters enable the managed Wiz Runtime Sensor backed by the corporate Secret Manager vault.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc0602ad90>)])]>

AI 보안을 위한 지능형 위협 상관관계 분석

이 통합의 진정한 힘은 관리형 센서가 더 광범위한 Wiz AI 애플리케이션 보호 플랫폼(AI-APP)에 연결될 때 발휘됩니다. GKE 런타임 원격 분석을 Wiz 보안 그래프에 입력하면 정적 알림을 뛰어넘는 보안 툴킷을 활용할 수 있습니다.

실시간 위험 평가 및 위협 검증: 백그라운드 보안 스캔과 실시간 활동 모니터링을 결합하여 실제 위험을 명확하게 파악할 수 있습니다. 센서는 취약한 코드가 실제로 메모리에서 실행 중인지 확인하므로 활성 보안 위협에 집중하고 비활성 위협은 무시할 수 있습니다.
실시간 위협 감지 및 대응: 멀웨어, 무단 액세스 시도, 소프트웨어 취약점과 같은 의심스러운 활동을 실시간으로 식별합니다. 보안팀은 위협이 확산되기 전에 자동으로 차단하거나 중지하는 규칙을 설정할 수 있습니다.
네트워크 활동 및 상세한 보안 인사이트: 시스템 활동, 네트워크 연결, 데이터 흐름을 추적하여 숨겨진 위험과 무단 소프트웨어 사용을 발견합니다. 위협이 감지되면 센서가 자동으로 진단 데이터를 수집하여 팀이 발생한 상황을 신속하게 조사할 수 있도록 지원합니다.

이러한 기능을 통해 GKE에 배포된 미션 크리티컬 애플리케이션과 AI 에이전트가 개발자 속도를 저해하지 않으면서 공격과 데이터 무단 반출을 모니터링할 수 있습니다.

지금 시작하기

GKE용 Wiz 런타임 센서 부가기능은 운영의 복잡성이나 배포의 번거로움 없이 심층적인 커널 수준의 eBPF 보호를 구현하여 컨테이너 보안의 표준을 제시합니다.

GKE의 관리형 플랫폼 자동화와 Wiz의 포괄적인 보안 인텔리전스를 결합하면, 플랫폼 및 보안팀은 강력한 런타임 방어 체계를 유지하면서도 클라우드 환경에 걸맞은 빠른 속도로 혁신을 추진할 수 있습니다. 자세한 내용은 GKE용 Wiz 센서 문서를 확인하세요.

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억 개 이상의 이미지와 동영상을 제공합니다.

GKE CPU 시작 부스트: 과도한 프로비저닝 없는 앱 시작 가속화

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

갑작스러운 트래픽 급증에 대응하여 마이크로서비스를 시작하거나, 새로운 소프트웨어 버전을 배포하거나, 애플리케이션 복제본을 확장하는 등의 경우, Google Kubernetes Engine(GKE)에서 실행 중인 애플리케이션에 신속하고 반응성이 뛰어난 사용자 환경을 제공하려면 포드 시작 시간이 중요합니다.

하지만 플랫폼 엔지니어와 개발자는 애플리케이션이 안정 상태에서 작동할 때보다 시작 시 훨씬 더 많은 CPU 성능을 요구할 때가 많다는 고질적인 딜레마에 직면해 있습니다. 안정 상태의 일반적인 사용량에 맞춰 CPU 요청량을 설정하면 실행 시 CPU 제한이 발생하여 콜드 스타트가 느려지고 준비 여부 프로브에서 제한 시간 초과가 발생할 수 있습니다. 반대로, 단기적인 시작 버스트를 충족하기 위해 기본 CPU 요청을 과도하게 프로비저닝하면 귀중한 컴퓨팅 리소스가 낭비되고 인프라 비용이 증가합니다.

오늘 GKE용 CPU 시작 부스트 프리뷰 버전을 발표하게 되어 기쁩니다. CPU 시작 부스트는 GKE의 수직형 포드 자동 확장 처리(VPA)에 바로 통합되어 초기 설정 중에는 컨테이너의 CPU 할당량을 동적으로 높이고 애플리케이션이 준비되면 기준이 되는 안정 상태 수준으로 원활하게 다시 축소합니다. 이 모든 과정에서 컨테이너를 다시 시작할 필요는 없습니다.

현대화된 애플리케이션 부팅 시 추가 CPU가 필요한 이유

새 컨테이너가 시작되면 사용자 요청을 처리하기 전에 리소스 집약적인 초기 설정 작업을 수행하는 경우가 있습니다. 사용하는 기술 스택에 따라 다르지만 다음과 같은 시작 워크로드에는 상당한 CPU 주기가 필요합니다.

Java JVM 애플리케이션: Spring Boot와 같은 프레임워크는 클래스 로드, 클래스 경로 스캔, 종속 항목 삽입 컨테이너 인스턴스화, 적시(Just-In-Time) 컴파일 실행을 위해 높은 CPU 버스트 용량이 필요합니다.
Node.js 서버: 앱은 초기 실행 시 JavaScript 파일을 파싱하고 복잡한 모듈 종속 항목 트리(require/import)를 빌드하며 V8 엔진 최적화 및 JIT 컴파일 패스를 실행합니다.
Python 및 AI/ML 마이크로서비스: 이러한 서비스는 초기 주기를 사용하여 PyTorch, NumPy, LangChain과 같은 대규모 라이브러리를 가져오고, .pyc 바이트 코드를 컴파일하고, ORM 데이터베이스 스키마를 설정하고, 캐시 구조를 사전 로드합니다.

CPU 요청 규모를 안정 상태의 성능에만 맞춰 설정하면 이러한 초기 설정 워크로드가 시작 시 CPU 제한을 겪게 되어 준비 여부 프로브가 지연됩니다. 느린 콜드 스타트를 방지하기 위해 팀에서는 CPU 요청을 과도하게 프로비저닝하는 경우가 많습니다. 하지만 애플리케이션이 안정화된 후에는 추가 CPU 리소스가 유휴 상태가 되어 아무런 가치도 창출하지 못한 채 클라우드 비용만 증가시킵니다.

CPU 시작 부스트의 작동 방식

CPU 시작 부스트는 워크로드 시작 중에 일시적으로 vCPU를 '부스트'하고 초기 설정이 완료되면 자동으로 기본 수준으로 되돌려 이 문제를 해결합니다.

주요 이점:

콜드 스타트 속도 향상: 애플리케이션 초기 설정 시간을 최대 2배 단축하여 예상치 못한 트래픽 급증 시 자동 확장 반응 속도를 높입니다.
클라우드 지출 최적화: 시작 시에만 필요해 유휴 상태에 있는 용량에 비용을 지불하는 대신 실제 런타임 니즈에 맞게 안정 상태의 CPU 요청을 적정 규모로 설정할 수 있습니다.
포드 재시작 불필요: 실행 중인 컨테이너 내에서 리소스 크기가 동적으로 조정됩니다.
유연한 정책 제어: 간단한 포드 수준의 배수(예: 시작 시 CPU 2배)를 적용하거나 복잡한 멀티 컨테이너 포드에 컨테이너별로 세분화된 규칙을 정의할 수 있습니다.

내부 작동 방식: Kubernetes 인플레이스 포드 크기 조절

기존에는 포드의 리소스 요청이나 한도를 변경하려면 포드를 삭제하고 다시 생성해야 했습니다. 이 과정에서 컨테이너가 다시 시작되고 캐시가 무효화되며 노드 재스케줄링에 따른 오버헤드가 발생했습니다.

이 문제를 해결하기 위해 CPU 시작 부스트는 Kubernetes 인플레이스 포드 크기 조절(IPPR)을 기반으로 합니다.

KEP-1287을 통해 추적되는 IPPR은 동적인 인플레이스 리소스 변환 기능을 도입했습니다. IPPR은 Kubernetes 1.27에서 알파 버전으로 처음 도입되고 v1.33에서 베타로 승격되었으며 v1.35에서 정식 버전(GA)으로 전환되었습니다. 이 기능을 사용하면 Kubernetes 컨트롤 플레인과 kubelet이 컨테이너 프로세스를 다시 시작하지 않고도 실행 중인 포드의 컨테이너 CPU와 메모리 요청을 업데이트할 수 있습니다.

GKE는 VPA 내에서 IPPR을 활용하여 포드 승인 시 시작 CPU 부스트를 적용하고 준비 후에는 원활하게 단계적으로 축소합니다.

CPU 시작 부스트 작동 방식(포드 수명 주기 개요)

CPU 시작 부스트는 세 가지 단계로 작동합니다.

승인 단계: 포드를 배포하면 VPA 승인 웹훅이 생성 요청을 가로챕니다. 정책(예: 2배수 또는 +2 vCPU)에 따라 상향 조정된 CPU 요청을 계산하고 추적용 주석과 함께 이 상향된 CPU 요청을 포드 사양에 삽입합니다.
시작 단계: 부스트된 CPU 할당량으로 포드가 예약되고 초기 설정됩니다. 애플리케이션은 CPU 제한 없이 최대 속도로 클래스 로딩, JIT 컴파일, 모듈 파싱을 완료합니다.
부스트 해제 단계: 포드의 readinessProbe를 통과하고 설정된 durationSeconds 대기 시간이 경과되는 즉시 VPA 업데이터가 인플레이스 크기 조절 요청을 실행합니다. CPU 요청이 기본 수준으로 다시 낮아지며 그와 동시에 컨테이너는 중단 없이 계속 실행됩니다.

기본 요건 및 가용성

CPU 시작 부스트는 현재 GKE에서 프리뷰 버전으로 제공됩니다.

GKE 버전: Standard 및 Autopilot 클러스터의 1.36.0-gke.4447000 버전 이상
클러스터 모드: GKE Autopilot에서 기본적으로 사용 설정됩니다(VPA는 기본적으로 활성화됨). GKE Standard에서는 수직형 포드 자동 확장(VPA)이 사용 설정되어 있는지만 확인하면 됩니다.
워크로드 지원: Deployments 및 StatefulSet를 비롯한 표준 Kubernetes 컨트롤러에서 작동합니다.

시작하기: CPU 시작 부스트 구성

CPU 시작 부스트를 구성하려면 VerticalPodAutoscaler 매니페스트에 startupBoost 섹션을 추가하기만 하면 됩니다.

예시 1: 고정된 안정 상태를 사용하는 포드 수준 부스트(`updateMode: "Off"`)

안정 상태 CPU 요청은 매니페스트 정의에 고정한 상태로 VPA를 시작 부스트 용도로만 사용하려면 updateMode를 "Off"로 설정하세요.

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: java-app-startup-boost\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: java-app\r\n updatePolicy:\r\n updateMode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 2\r\n durationSeconds: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05c2fa10>)])]>

이 예시에서 GKE는 시작 중에 컨테이너의 CPU 요청을 2배 늘리고, 준비 여부 프로브 통과 후 10초간 부스트된 할당량을 유지한 다음 기본 수준으로 다시 줄입니다.

예시 2: 시작 부스트와 지속적인 VPA 자동 확장의 결합

GKE가 시작 중에 CPU를 부스트하고 시작 후에도 안정 상태의 리소스를 지속적으로 최적화하도록 하려면 updateMode를 "InPlaceOrRecreate"로 설정하세요.

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: nodejs-app-vpa\r\n namespace: default\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: nodejs-service\r\n updatePolicy:\r\n updateMode: "InPlaceOrRecreate"\r\n startupBoost:\r\n cpu:\r\n type: "Factor"\r\n factor: 3\r\n durationSeconds: 15'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05c2f550>)])]>

예시 3: 세분화된 컨테이너 수준 부스트

부팅 시 추가 CPU가 필요하지 않은 사이드카(예: Logging 에이전트 또는 서비스 메시 프록시)를 실행하는 포드의 경우 특정 앱 컨테이너를 타겟팅할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.k8s.io/v1"\r\nkind: VerticalPodAutoscaler\r\nmetadata:\r\n name: app-container-boost\r\nspec:\r\n targetRef:\r\n apiVersion: "apps/v1"\r\n kind: Deployment\r\n name: API-gateway\r\n updatePolicy:\r\n updateMode: "Off"\r\n resourcePolicy:\r\n containerPolicies:\r\n - containerName: "web-app"\r\n mode: "Off"\r\n startupBoost:\r\n cpu:\r\n type: "Quantity"\r\n quantity: "2"\r\n durationSeconds: 5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05c2e550>)])]>

클러스터에서 시작 부스트 확인

kubectl을 사용하여 GKE가 시작 부스트를 적용한 후 다시 축소했는지 확인할 수 있습니다.

1. 포드 주석 검사: vpaCpuStartupBoost 추적 주석을 확인합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl get pod <POD_NAME> -o yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05c2c990>)])]>

기본 CPU 요청과 부스트된 CPU 요청을 나타내는 주석을 찾습니다.

2. 인플레이스 크기 조절 이벤트 모니터링: GKE가 준비 상태가 된 후 CPU 요청을 다시 기본 수준으로 축소했는지 확인합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl get events --field-selector reason=InPlaceResizedByVPA'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05c2d1d0>)])]>

프로덕션 워크로드 권장사항

수평형 포드 자동 확장 처리(HPA)와 함께 사용: CPU 시작 부스트와 함께 HPA를 사용하는 경우 안정적인 readinessProbe를 정의하고 durationSeconds를 짧게 유지하세요(예: 0초~10초). 이렇게 하면 HPA가 초기 설정 중 발생하는 CPU 급증을 안정 상태의 높은 부하로 오인하는 것을 방지할 수 있습니다.
GKE Capacity Buffers API로 트래픽 급증 처리: 대규모 환경에서 시작에 따른 리소스 부담을 줄이면 더 적은 수의 노드에서 더 높은 워크로드 밀도를 달성하여 전반적인 활용률을 높일 수 있습니다. 엄격한 SLO를 유지하면서 운영 오버헤드를 최소화하고 갑작스러운 트래픽 급증을 흡수하려면 GKE capacity buffers API 도입을 고려해 보세요.
GKE Autopilot 리소스 비율: GKE Autopilot에서는 포드가 유효한 CPU 대 메모리 비율을 유지해야 합니다. 기본 메모리 할당량이 시작 시 부스트된 CPU 비율을 수용할 수 있는지 확인하세요.

지금 시작하기

CPU 시작 부스트를 사용하는 GKE 사용자는 Java, Node.js, Python과 같은 CPU 집약적인 워크로드에서 매우 빠른 콜드 스타트를 구현하는 동시에 리소스 효율성을 극대화하고 클라우드 비용을 절감할 수 있다는 두 가지 이점을 모두 누릴 수 있습니다.

GKE 워크로드의 시작 속도를 높일 준비가 되셨나요?

GKE CPU 시작 부스트 문서를 살펴보세요.
GKE의 수직형 포드 자동 확장에 대해 자세히 알아보세요.
GKE 1.36.0-gke.4447000 이상을 실행하는 GKE Standard 또는 Autopilot 클러스터에서 CPU 시작 부스트를 사용해 보세요.

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: Scale-to-zero, 비용 절감, 워크로드 응답성 유지

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

진정한 탄력성은 오랫동안 클라우드 네이티브 엔지니어링의 궁극적인 목표였습니다. Kubernetes가 리소스 관리에 혁신을 가져온 것은 맞지만 일괄 프로세서, 이벤트 기반 작업자, 개발 환경과 같이 산발적으로 실행되는 워크로드의 경우 작업을 기다리는 동안에도 컴퓨팅 리소스를 소비하여 비용이 늘어납니다.

Google은 Google Kubernetes Engine(GKE) 1.37에서 이 과제에 정면으로 맞서 0으로 축소하고 0에서 확장할 수 있는 네이티브 방식을 채택했습니다. 새로운 기능 모음을 사용하면 워크로드를 복제본 0개로 완전히 축소하여 리소스 소비를 멈출 수 있습니다. 수요가 다시 발생할 경우 GKE 용량 버퍼에서 이러한 워크로드를 쉽고 빠르게 다시 시작할 수 있어 인프라 낭비를 줄일 수 있습니다. 이는 단순히 비용을 절감하는 것이 아니라 워크로드 준비 상태에서 상시 가동 인프라의 비용을 분리한다는 의미가 있습니다.

진화: HPA 기반 Scale-to-zero와 KEDA 비교

수년 동안 선택적 Kubernetes 구성요소인 Kubernetes Event-Driven Autoscaling(KEDA)이 Scale-to-zero를 위한 솔루션으로 사용되었습니다. KEDA는 강력하지만 환경에 복잡성을 더합니다.

기능	GKE Scale-to-zero	KEDA 기반 설정
운영 반복 업무	관리형 서비스, 추가 구성요소 없음	`ScaledObject` CRD 및 오퍼레이터 관리 필요
구성	네이티브 HPA 및 CRD(최소한의 YAML)	대규모 Fleet의 경우 YAML이 10,000줄을 초과할 수 있음
지연 시간	내부 신호 경로에서 반응 시간 단축	폴링 간격과 홉 수로 인해 콜드 스타트 지연 증가

GKE 컨트롤 플레인에 Scale-to-zero 기능을 직접 내장하여 부가기능 오퍼레이터와 수천 줄의 구성이 필요하지 않습니다. 로직이 '사이드카 관리'에서 워크로드의 네이티브 속성으로 전환됩니다.

작동 방식: AutoscalingMetric 및 KEP-2021을 사용한 HPA

GKE 내 Scale-to-zero 구현은 2가지 중요한 구성요소의 통합으로 가능해졌습니다.

AutoscalingMetric을 사용한 HPA: Google Cloud Managed Service for Prometheus에서 외부 신호를 직접 읽을 수 있도록 지원하는 관리형 측정항목 신호 파이프라인입니다. AutoscalingMetric이 포함된 HorizontalPodAutoscaler(HPA)는 어댑터의 복잡성 없이 Pub/Sub, Cloud Monitoring 또는 부하 분산기 신호의 측정항목이 자동 확장 처리에 도달할 수 있는 통합된 고성능 경로를 제공합니다.
KEP-2021: HPA에서 minReplicas: 0을 지원하는 Kubernetes Enhancement Proposal을 기반으로 하는 이 메커니즘을 통해 측정항목이 기준점 아래로 떨어지면 HPA가 모든 포드를 중지할 수 있습니다. 또한 측정항목이 대기 중인 작업을 나타내는 즉시 HPA가 배포를 재가동할 수 있습니다.

첫 번째 Scale-to-zero 워크로드 구성

네이티브 Scale-to-zero를 구현하려면 측정항목 정의와 HPA라는 두 가지 기본 객체가 필요합니다. 다음 예시에서는 Pub/Sub 구독에서 전송되지 않은 메시지 수를 기준으로 워커를 확장합니다.

측정항목 소스 정의

AutoscalingMetric CRD를 사용하여 외부 Cloud Monitoring 측정항목을 클러스터에 매핑합니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: my-autoscalingmetric\r\nspec:\r\n metrics:\r\n - promql:\r\n name: pubsub-undelivered\r\n query: >\r\n {\r\n "pubsub.googleapis.com/subscription/num_undelivered_messages",\r\n subscription_id="my-subscription"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05ef0b10>)])]>

minReplicas: 0으로 HPA 구성

HPA에서 측정항목을 참조하고 최소 복제본을 명시적으로 0으로 설정합니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling/v2\r\nkind: HorizontalPodAutoscaler\r\nmetadata:\r\n name: worker-hpa\r\nspec:\r\n scaleTargetRef:\r\n apiVersion: apps/v1\r\n kind: Deployment\r\n name: worker-deployment\r\n minReplicas: 0\r\n maxReplicas: 50\r\n metrics:\r\n - type: External\r\n pods:\r\n metric:\r\n name: autoscaling.gke.io|my-autoscalingmetric|pubsub-undelivered\r\n target:\r\n type: AverageValue\r\n averageValue: 10'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05c2c050>)])]>

이제 외부 측정항목을 기반으로 워크로드를 0으로 축소하거나 0에서 확장할 수 있습니다.

Scale-to-zero 기능의 구현은 GKE에서 Cloud Monitoring의 외부 측정항목을 지원하면서 가능해졌습니다. AutoscalingMetric 커스텀 리소스를 확장하면 복잡한 서드 파티 어댑터 없이도 Google Managed Service for Prometheus에서 측정항목을 쿼리할 수 있습니다. 지연 시간이 줄고 보안이 간소화되며 네이티브 Scale-to-zero 워크로드를 구성하기 위한 핵심 기반이 제공됩니다. 이 통합에 대해 자세히 알아보려면 GKE의 외부 측정항목에 대한 기본 지원에 관한 블로그 게시물을 읽어보세요.

용량 버퍼를 사용한 시작 지연 시간 관리

0에서 확장할 때 가장 큰 문제는 콜드 스타트입니다. 콜드 스타트란 GKE가 노드를 프로비저닝하고 컨테이너가 이를 가져와 시작하기까지 걸리는 시간을 의미합니다. 이때 GKE 용량 버퍼가 유용합니다.

용량 버퍼는 풀링된 웜 용량 역할을 합니다. 모두 0으로 축소될 수 있는 여러 워크로드에서 공유 가능한 소량의 웜 컴퓨팅 리소스를 유지함으로써 GKE는 HPA가 0에서 1로 증가하는 즉시 포드가 리소스를 확보할 수 있도록 보장합니다. 이렇게 하면 새로운 GKE 노드가 가동될 때까지 60~90초 동안 기다릴 필요가 없으므로 분 단위의 지연 시간 없이 즉시 시작할 수 있으며 워크로드 비용도 전혀 발생하지 않습니다.

용량 버퍼에는 활성 및 대기라는 두 가지 유형이 있습니다. 작은 활성 버퍼로 0으로 축소된 수백 개의 워크로드를 처리할 수 있습니다. 각 워크로드가 복제본을 유지하는 대신, 활성 버퍼가 전체 클러스터를 처리하는 와일드 카드 용량 역할을 합니다. 규모가 더 크지만 활성 버퍼보다 저렴한 대기 버퍼는 클러스터에서 지속적인 부하가 발생할 때 활성 버퍼를 빠르게 다시 채워줍니다. 이 두 가지를 함께 사용하면 즉각적인 확장과 낮은 비용 유지 모두를 달성할 수 있습니다.

향후 계획

Google은 GKE 탄력성을 위한 로드맵을 계속 확장하고 있습니다. 예를 들어 개발 환경을 오후 8시에 0으로 축소했다가 오전 7시에 다시 확장하고 싶다면 반복되는 확장을 더 세밀하게 제어하여 선제적으로 Scale-to-zero 기간을 정의할 수 있는 방법을 찾아보세요.

지금 바로 Scale-to-zero 시작하기

유휴 리소스에 비용을 지불하는 시대는 끝났습니다. 이벤트 기반 워크로드와 산발적인 워크로드를 위해 GKE의 네이티브 Scale-to-zero 기능을 사용 설정하면 시작 성능을 저하시키지 않으면서 비용을 절감할 수 있습니다. Scale-to-zero를 시작하려면 다음 단계를 따르세요.

수요가 변동하고 유휴 기간이 있는 워크로드를 식별합니다.
AutoscalingMetric을 구성하고 minReplicas를 0으로 설정합니다.
클러스터 또는 워크로드에 용량 버퍼를 추가하여 빠른 응답 시간을 유지합니다.

자세한 내용은 HPA를 사용하여 GKE 워크로드를 0으로 축소하고 0에서 확장하기 문서를 확인하세요.

거버넌스가 기본 제공되는 AI 지원 EKS에서 GKE로의 마이그레이션을 위한 GKE 에이전트형 마이그레이션 소개

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

많은 기업이 가장 중요한 워크로드와 AI 기반 워크로드를 실행하기 위해 Google Kubernetes Engine(GKE)을 표준 플랫폼으로 채택하는 추세입니다. 높은 처리량의 데이터 액세스를 위한 Cloud Storage FUSE부터 커스텀 컴퓨팅 클래스(CCC)와 고급 GPU 슬라이싱에 이르기까지 GKE는 최신 애플리케이션에 필요한 확장성과 효율성을 제공합니다.

하지만 복잡한 Kubernetes 환경을 AWS EKS에서 GKE로 마이그레이션하는 작업은 그동안 엔지니어들에게 매우 까다롭고 고된 여정이었습니다. 플랫폼팀은 무분별하게 뻗어 있는 코드형 인프라(IaC)를 수동으로 분석하고, 클라우드마다 다른 아키텍처의 차이를 직접 파악하며, 커스텀 변환 스크립트까지 빌드해야 합니다.

엔지니어링 팀에서 변환 초안을 작성하기 위해 범용 LLM을 실험적으로 사용하는 경우가 많지만, 체계적이지 않은 임시 프롬프팅은 순식간에 운영상의 함정이 될 수 있습니다. 원시 모델은 존재하지 않는 리소스 속성을 할루시네이션하고, 중요한 네트워크 또는 ID 구성을 누락하며, 상호 의존적인 파일 간의 컨텍스트를 상실합니다. 플랫폼 엔지니어가 모델 오류를 감사하고, 해결하고, 디버깅하는 데 시간을 소비하면 결국 초기 속도 향상 효과가 상쇄되고 수동 반복 업무와 예측 불가능성이 발생합니다.

오늘 Google Cloud는 GKE 에이전트형 마이그레이션의 오픈소스 출시 소식을 발표하게 되어 기쁩니다. 이 도구는 불안정하고 일시적인 프롬프팅 방식 대신, 결정론적 가드레일로 보호되는 AI 지원 마이그레이션 파이프라인을 제공하는 전용 에이전트 플러그인입니다.

“대기업 고객의 경우 클라우드 현대화의 가장 큰 장벽은 실행 위험과 예측 불가능성입니다. 컨텍스트를 잃고 구성을 할루시네이션하는 원시 채팅 프롬프트와 달리, Google의 GKE 에이전트형 마이그레이션은 생성형 AI의 속도와 기업에 필요한 결정론적 가드레일(정형 상태 지속성, 플랫폼팀과 앱팀 간의 멀티 페르소나 경계, 타협할 수 없는 인간 승인 게이트)을 결합합니다. 이를 통해 글로벌 엔지니어링 실무에 검증 가능하고 컴파일러 수준의 정교함을 갖춘 마이그레이션 팩토리를 제공하여, 배포 위험을 줄일 수 있습니다.- 라훌 슈리바스타바, Persistent 부사장

인프라 마이그레이션의 과제

인프라 마이그레이션 여정에 대해 고객과 이야기를 나누다 보면, 공통적으로 몇 가지 거버넌스 관련 어려움을 듣게 됩니다.

자동화 신뢰 격차: Kubernetes 구성을 수동으로 리팩터링하는 작업은 고통스러울 정도로 느릴 수 있습니다. 그러나 일반적인 AI 코딩 어시스턴트를 사용하면 감당할 수 없는 위험이 발생합니다. 표준 LLM은 인프라 코드에 할루시네이션을 일으키거나, 지원 중단된 API 필드를 사용하거나, 중요한 보안 규칙을 누락할 수 있습니다. '거의 정확한' 코드를 생성하는 것은 코드 작성의 병목 현상을 디버깅 단계로 옮기는 것에 불과합니다.
라이브 클러스터 변경 가능성의 위험(ClickOps): 기존 마이그레이션 도구는 라이브 클러스터에 직접 연결하고 API 호출을 통해 배포하는 경우가 많습니다. 이는 조직의 Git 저장소(신뢰할 수 있는 정보 소스)를 우회하고, CI/CD 파이프라인을 중단하며, 롤백을 매우 어렵게 만듭니다.
사일로화된 핸드오프 병목 현상: 마이그레이션은 몇 주에 걸쳐 장기적으로 진행되는 경우가 많습니다. 플랫폼 엔지니어가 시작 영역을 빌드하면 애플리케이션 개발자가 워크로드를 마이그레이션합니다. 표준 AI 도구는 핸드오프 과정에서 맥락을 잃습니다.
분산된 도구 모음: Velero와 같은 백업 도구는 재해 복구에 탁월하지만, AWS 관련 구성(예: ALB)을 Google Cloud에 맞게 변환하지 못하고 그대로 캡처합니다. 반면 리버스 엔지니어링 도구는 개발자의 원래 논리적 의도를 무시한 채 플랫 구성을 생성합니다.

GKE 에이전트형 마이그레이션 소개

GKE 에이전트형 마이그레이션은 LLM의 추론 기능과 엄격하고 결정론적인 도구를 결합하여 이러한 과제를 해결합니다. 에이전트 스킬과 로컬 모델 컨텍스트 프로토콜(MCP) 서버의 결합으로 설계된 이 도구는 AI를 활용하여 복잡한 AWS EKS IaC 및 Kubernetes 매니페스트를 GKE 시작 영역으로 직접 변환하며, 이 모든 과정은 자동화된 pull 요청을 통해 이루어집니다.

GKE 에이전트형 마이그레이션의 차별화된 주요 기능은 다음과 같습니다.

1. 하이브리드 검증 — LLM에서 생성하고 결정론적으로 검증합니다. 위험한 IaC 할루시네이션에 대응하기 위해 LLM 작업자는 Terraform 및 Kubernetes YAML의 복잡한 작성을 처리하고, 서버는 워크로드 아이덴티티 주석 및 이미지 레지스트리와 같은 정확한 매핑을 위해 결정론적 변환을 실행합니다. 무엇보다 중요한 점은, 이렇게 AI가 생성한 변환 결과가 사용자에게 전달되기 전에 엄격한 결정론적 검증(예: terraform validate, Kubernetes 매니페스트 계약)을 반드시 거친다는 사실입니다. 이러한 접근 방식은 할루시네이션으로부터 안전성을 유지하는 동시에, 모든 과정을 휴먼인더루프(HITL) 승인 절차를 거치도록 제한하여 보안을 강화합니다.

2. GitOps 기반 PR 워크플로: 플러그인은 변경사항을 라이브 클러스터에 직접 적용하지 않습니다. 대신 정보 소스를 읽고 대상 상태를 생성한 후 pull 요청을 엽니다. 이렇게 하면 모든 변경사항이 표준 휴먼인더루프(HITL) CI/CD 검토 프로세스를 거치게 됩니다. 더 이상 "ClickOps"는 필요 없습니다.

3. 변환과 전송의 안전한 분리: 플러그인은 아키텍처 변환의 지루한 로직을 자동화하지만, 의도적으로 스테이트풀(Stateful) 데이터를 전송하지는 않습니다. 가장 민감한 애셋을 보호하기 위해 플러그인은 Google Cloud의 Database Migration Service 또는 Storage Transfer Service와 같이 SLA가 지원되는 목적에 맞게 빌드된 도구를 사용하는 방법을 팀에 안내하는 컨텍스트 기반 런북을 생성합니다.

4. 멀티 페르소나 상태 관리: 마이그레이션은 팀의 노력으로 이루어집니다. 플러그인은 장기적으로 진행되는 마이그레이션 상태를 유지합니다. 이를 통해 안전한 비동기식 핸드오프가 가능해집니다. 플랫폼 엔지니어가 기초가 되는 기준 시작 영역을 설정하면, 앱 개발자는 각자의 로컬 머신에서 독립적으로 작업공간에 참여하여 권한이 격리된 폴더 내에서 개별 워크로드를 자유롭게 변환할 수 있습니다.

작동 방식: 마이그레이션 수명 주기

GKE 에이전트형 마이그레이션의 내부 작동 방식을 살펴보면, 실행 가능한 함수로 구성된 마이그레이션 상태 그래프를 활용해 체인을 따라 컨텍스트를 체계적으로 전달합니다. 오픈소스 에이전트 플러그인으로 패키징되어 설치할 커스텀 CLI 바이너리나 관리할 중앙 컨트롤 플레인이 없습니다. 팀은 기존 개발 하네스를 통해 협업하여 검증된 pull 요청과 실행 가능한 런북을 소스 저장소에 직접 제공할 수 있습니다. 다음과 같은 이점을 제공합니다.

심층 EKS 저장소 탐색: 플러그인이 소스 Git 저장소를 클론하거나 EKS 클러스터의 실시간 스캔을 수행하고, 소스 매니페스트를 프로그래매틱 방식으로 색인 생성하고, 종속 항목을 매핑하고, 인벤토리를 빌드합니다.
평가 및 차단 요소 거버넌스: 아키텍처 비호환성을 식별하는 준비 보고서를 생성합니다. 설계를 진행하려면 모든 차단 요소에 담당자와 목표 해결 날짜가 지정되어야 합니다. 플랫폼 엔지니어는 변환이 시작되기 전에 마이그레이션 경계를 승인합니다.
시작 영역 설계: 플러그인은 명시적인 플랫폼 결정(예: GKE Autopilot과 GKE Standard 비교)을 기반으로 기본 Google Cloud Terraform 모듈(VPC, 서브넷, GKE 클러스터, 조직 정책)을 스캐폴딩합니다.
AI 지원 클라우드 변환: 플러그인은 AWS IRSA를 워크로드 아이덴티티로 변환하고, ALB 인그레스를 게이트웨이 API에 매핑하며, Karpenter 노드 클레임을 GKE 노드 자동 프로비저닝(NAP) 또는 커스텀 컴퓨팅 클래스(CCC)로 전환하는 등 클라우드별 특화된 전환 작업을 처리합니다.
오프라인 검증: 생성된 모듈과 매니페스트는 오프라인에서 컴파일되고 검증됩니다(terraform validate, 매니페스트 구조 검사, 출력 계약).
pull 요청을 통한 배포: 최종 구성이 로컬에서 검증되면 검토를 위한 PR이 생성됩니다.

시작하기

GKE 에이전트형 마이그레이션은 분리된 리팩터링 작업에 불과했던 클라우드 마이그레이션을 예측 가능하고 AI 지원을 받으며 검토까지 가능한 GitOps 워크플로로 혁신합니다. GKE로의 여정을 가속화할 준비가 되셨나요?

GitHub의 GKE 에이전트형 마이그레이션 저장소에 별표표시하고 클론해 보세요.
온보딩 가이드를 참고하여 샘플 EKS 저장소에서 플러그인을 직접 실행해 보세요.
Google Cloud 커뮤니티에 가입하여 의견을 나누고 궁금한 점을 질문하며 함께 참여해 보세요.

멀티 클러스터 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 소개
이 게시물에서 다룬 리전 간 스필오버 동작에 대해 자세히 알아보기: 탄력적인 리전 간 고가용성 소개 및 탄력적인 리전 간 고가용성 구성

GKE 포드 스냅샷으로 AI 워크로드를 더 빠르고 효율적으로 확장하세요

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

최신 AI 워크로드를 실행할 때는 성능과 비용 문제가 자주 충돌하곤 합니다. 대규모 언어 모델(LLM) 같은 워크로드는 방대한 파일을 로드하며, 코드를 즉시 실행해야 하는 AI 에이전트 수천 개를 제공하기도 합니다. 각 구성요소가 전체 데이터 로드 프로세스를 통해 '콜드' 상태로 시작하는 경우, 이 모든 프로비저닝에 작업을 수행하는데 시간이 오래 걸립니다. 따라서 많은 조직은 확장 요구사항을 충족하기 위해 인프라를 과도하게 프로비저닝해야 합니다.

이 문제를 해결하기 위해 Google Cloud에서는 CPU 및 GPU 메모리를 포함한 워크로드의 실행 상태를 저장하고 필요에 따라 복원할 수 있는 새로운 기능인 Google Kubernetes Engine(GKE) 포드 스냅샷을 도입했습니다.

GKE 포드 스냅샷을 사용하면 AI 추론 시작 시간을 최대 89% 단축하여 파라미터 모델 700억 개를 단 37초 만에, 80억 개를 단 15초 만에 로드할 수 있습니다. 이러한 빠른 속도 덕분에 인프라를 수요 증가 속도에 맞춰 신속하게 확장하여, 과도한 프로비저닝의 필요성을 크게 줄일 수 있습니다.

콜드 스타트가 유발하는 높은 비용 — 다시 시작하는 대신 재개하기

콜드 스타트 문제는 AI에만 국한되지 않습니다. 게임 서버부터 복잡한 Java 모놀리식 애플리케이션에 이르는, 상당한 초기화 시간이 필요한 모든 애플리케이션에서 발생하는 문제입니다. 하지만 AI 워크로드에서는 콜드 스타트 문제가 특히 심각합니다. 추론 서버는 먼저 초기화를 수행한 다음 기가바이트 단위의 모델 가중치를 다운로드하여 GPU 메모리에 로드해야 하는데, 이 프로세스는 몇 분 정도 걸릴 수 있습니다. 또한 코드 실행 및 컴퓨터 사용 도구를 비롯한 많은 에이전트 AI 워크로드에는 요청별로 격리된 샌드박스를 사용해야 하며, 이러한 샌드박스는 신속하게 시작되어야 하고 유휴 상태일 때는 일시 중지되어야 합니다.

두 시나리오 모두에서 시작 지연 시간이 발생하면 사용자 경험이 훼손되고 트래픽 급증 시 빠른 자동 확장 기능이 제대로 작동하지 않게 됩니다. 따라서 많은 엔지니어는 애플리케이션 수준에서 상태를 신속하게 복구하기 위해 값비싼 인프라를 과도하게 구축하거나 정교한 커스텀 시스템을 구축해야 합니다.

대기 시간 없는 AI 추론 확장

생성형 AI의 경우, GKE 포드 스냅샷은 모델 로딩 시 발생하는 선형 확장성 문제를 해결합니다. 일반적으로 클러스터에 새로 추가하는 모든 복제본은 모델 가중치를 개별적으로 다운로드하여 가속기 메모리에 로드해야 합니다. 수백억 개의 파라미터가 있는 많은 모델에서는 이 단계가 시작 시간의 대부분을 차지합니다.

포드 스냅샷을 사용하면 초기 스냅샷을 생성할 때 이 초기화를 한 번만 수행하면 됩니다. GKE는 CPU 및 GPU 메모리를 포함하여 완전히 로드된 상태를 캡처하여 이를 처리량이 높은 Cloud Storage에 유지합니다. 워크로드를 수직 확장해야 하는 경우에는 새 복제본이 이 상태에서 직접 복원되므로 초기화 단계를 완전히 건너뛸 수 있습니다. 당사의 벤치마크에서 이 접근 방식은 llama3-70b와 같은 대규모 모델의 시작 지연 시간을 최대 89%까지 줄였습니다. 이러한 속도를 활용하면 플랫폼팀은 비용이 많이 드는 오버프로비저닝 전략에서 주문형 자동 확장으로 전환하여, 서비스 수준 목표를 달성하면서도 유휴 GPU 비용을 크게 줄일 수 있습니다.

에이전트형 워크플로 및 샌드박스 최적화

GKE 포드 스냅샷은 에이전트가 코드 실행과 컴퓨터 사용을 격리된 샌드박스에 위임하는 에이전트형 워크플로에도 뚜렷한 이점을 제공합니다. 신뢰할 수 없는 LLM 생성 코드와 명령어를 격리한다는 것은 사용자 또는 개별 워크플로당 하나의 샌드박스를 사용한다는 의미입니다. 이러한 시나리오에서는 시작 지연 시간과 유휴 샌드박스 모두로 인해 상당한 오버프로비저닝과 사용률 저하가 발생할 수 있습니다.

포드 스냅샷은 이러한 두 가지 문제를 모두 해결합니다.

시작 지연 시간을 개선하고 싶다면, 초기 에이전트 샌드박스 환경의 스냅샷을 한 번 캡처한 다음 나중에 새 샌드박스를 빠르게 초기화하는 데 사용하면 됩니다.
유휴 샌드박스를 줄이고 싶다면, 유휴 상태일 때 샌드박스를 정지하여 전체 컴퓨팅 리소스를 캡처하면 됩니다. 나중에 환경이 필요하면 거의 즉시 재개할 수 있습니다.

이 접근 방식은 당사 고객에게 막대한 성공을 가져다주고 있습니다. 예를 들어 Codeway에서 빌드한 AI 기반 사진 편집 플랫폼인 Retake는 GPU 워크로드에서 심각한 성능 병목 현상을 겪었습니다. 하지만 포드 스냅샷을 도입한 덕분에 복잡한 커스텀 캐싱 레이어를 대체하고 시작 시간을 몇 초로 수준으로 단축할 수 있었습니다.

"수백만 명의 사용자에게 맞춤형 모델을 제공하려면, Retake에는 A3 H100 GPU에서 미세 조정 학습과 실시간 추론을 모두 수행할 수 있는 대규모 통합 파이프라인이 필요합니다.” 처음에는 컴파일된 아티팩트를 위해 복잡한 커스텀 캐싱 레이어를 설계했는데, 이를 통해 시작 시간을 1분으로 단축할 수 있었습니다. 하지만 이 솔루션은 상당한 유지보수 오버헤드를 추가했을 뿐만 아니라, 자동 확장을 적극적으로 수행하는 기능은 여전히 제한되었습니다. 우리는 이러한 복잡성을 GKE 포드 스냅샷으로 대체하여 시작 지연 시간을 단 8초로 단축했습니다. 초기화 페널티가 제거됨에 따라, 이제 특정 미세 조정 또는 추론 작업을 위해 H100을 즉시 동적으로 가동하고 작업이 끝나면 바로 종료하여 유휴 GPU 비용을 대폭 줄이고 코드베이스를 간소화할 수 있게 되었습니다." - 아흐메트 푸르칸 초마크, Codeway 리드 DevOps 엔지니어

어떤 워크로드도 처리할 수 있는 유연한 구성

Google Cloud는 시작 성능을 개선하고 기존 Kubernetes 워크플로에 자연스럽게 통합되도록 포드 스냅샷을 설계했습니다. 포드 스냅샷 CRD를 사용하여 새로운 선언적 정책을 정의하기만 하면 포드 스냅샷을 워크로드에 쉽게 적용할 수 있습니다. 이 정책을 사용하면 스냅샷을 생성할 포드와 데이터를 저장할 위치를 정의하고, 엔드 투 엔드 스토리지 수명 주기와 관리를 처리할 수 있습니다.

워크로드의 어느 단계에서든 스냅샷을 생성할 수 있습니다. 워크로드 시작 시 워크로드 신호를 사용하거나 포드의 수명 주기 중에 온디맨드 트리거를 사용하여 스냅샷을 생성하면 됩니다. 스토리지 및 복원 동작을 더욱 세밀하게 제어하고, 비용 최적화를 위해 스냅샷 보존 기간을 설정하고, 마지막으로 생성된 스냅샷에서 복원하는 기본 동작을 선택하거나, 새 포드 배포 중에 명시적 스냅샷을 지정할 수 있습니다.

GKE 포드 스냅샷의 주요 사용 사례는 AI 추론과 에이전트 샌드박스이지만, 이 기능은 워크로드에 구애받지 않습니다. 이 기능을 활용하면 복잡한 Java 애플리케이션, 게임 서버, 레거시 모놀리식 애플리케이션 같이 초기화 단계가 긴 모든 애플리케이션의 실행 속도를 높일 수 있습니다.

시작하기

지금 바로 GKE 포드 스냅샷을 이용해 시작 지연 시간을 최적화할 수 있습니다. 문서를 확인하여 시작하는 방법을 확인하세요. 여러분의 의견을 기다리겠습니다.

GKE에서 PromQL 측정항목 쿼리를 기본적으로 지원하는 HPA를 사용하여 원하는 방식으로 확장

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

올해 초 Google Cloud는 Google Kubernetes Engine(GKE) 커스텀 측정항목에 대한 기본 지원을 발표했습니다. 이 마일스톤을 통해 외부 어댑터를 폐기하고 대신 포드에서 직접 자동 확장 측정항목을 수집할 수 있게 되었습니다. 이러한 측정항목을 수평형 포드 자동 확장 처리(HPA)로 바로 라우팅하여 측정항목 읽기 지연 시간을 5초로 단축했습니다.

이제 Prometheus 측정항목 처리를 위한 기본 지원이 도입됩니다. 이를 통해 표현력이 뛰어난 PromQL 쿼리를 사용하여 자동 확장 트리거를 맞춤설정할 수 있습니다. 이번 업데이트를 통해 HPA는 이제 Google Managed Service for Prometheus를 사용하여 Cloud Monitoring에 있는 자동 확장 측정항목을 직접 처리할 수 있습니다. 이러한 백엔드에서 측정항목을 읽을 때는 서드 파티 어댑터가 필요하지 않으며, 포드 수준 측정항목을 지원하는 데 사용되는 AutoscalingMetric 통합을 활용합니다. 프리뷰 후 정식 버전으로 전환하면서 자체 호스팅 Prometheus 서버를 지원할 계획입니다.

과제: Cloud Monitoring 측정항목 설정

포드 수준의 커스텀 측정항목을 지원하면서 자동 확장이 더 간단해졌지만, 프로덕션 워크로드는 여러 가지 복잡한 인프라 측정항목을 기준으로 확장해야 하는 경우가 많습니다. 일반적인 예로는 다음과 같은 확장이 있습니다.

Pub/Sub 주제에서 확인되지 않은 메시지 수를 기반으로 하는 작업자 풀 확장
Cloud Monitoring/Prometheus에 저장된 초당 쿼리 수(QPS) 측정항목을 기반으로 하는 추론 서비스 확장
측정된 응답 시간의 95번째 백분위수를 기준으로 웹 서버 팜 확장

이를 위해서 Stackdriver 커스텀 측정항목 어댑터 또는 Prometheus 어댑터와 같은 외부 어댑터를 배포하여 외부 로깅 환경에서 측정항목을 검색해야 했습니다. 이 방식이 처음에는 간단해 보이지만 이러한 어댑터는 많은 운영상의 마찰을 야기합니다.

관리 오버헤드: 플랫폼팀은 이러한 서드 파티 구성요소를 설치, 구성, 패치, 모니터링해야 합니다.
안정성 및 비효율성: 외부 시스템에서 읽는 중간 어댑터 포드가 중요한 자동 확장 루프에서 장애점을 유발합니다.
IAM 복잡성: 안전한 구성요소 간 통신을 사용 설정하려면 권한을 포함하여 Cloud 서비스 계정에 Kubernetes 서비스 계정을 매핑하도록 설정해야 합니다.

이 시스템을 설정하고 유지하는 것이 불가능하지는 않지만 복잡하고 아키텍처가 까다롭습니다.

GKE에서 Prometheus 측정항목을 처리하는 것이 도움이 되는 이유

AutoscalingMetric 객체를 확장하면 이 설정이 크게 간소화됩니다. 이제 PromQL을 통해 측정항목을 모니터링에서 직접 읽고 지연 시간이 짧은 고성능 자동 확장 파이프라인을 통해 HPA에 제공할 수 있으므로 환경이 간소화됩니다.

비효율성이 발생하는 것을 막기 위해 Google은 리소스 소비를 최소화하는 것을 염두에 두고 이 기능을 빌드했습니다. 컨트롤러는 GKE 컨트롤 플레인에서 실행됩니다. AutoscalingMetric 커스텀 리소스를 모니터링하고 PromQL 측정항목이 활발하게 요청될 때만 사용자 노드에 시스템 포드를 배포합니다. Prometheus 측정항목이 구성되지 않으면 컨트롤러가 종료되므로 리소스 오버헤드가 발생하지 않습니다.

기본 Prometheus 측정항목 구성

PromQL 측정항목을 사용하도록 GKE를 구성하는 것은 간단합니다. 다음은 Pub/Sub 메시지 큐 깊이를 확장 측정항목으로 제공하는 샘플 구성 파일입니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: gmp-metric\r\nspec:\r\n metrics:\r\n - promql:\r\n name: pubsub-queue-depth\r\n query: |\r\n {\r\n "pubsub.googleapis.com/subscription/num_undelivered_messages",\r\n subscription_id="my-subscription"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05cb8190>)])]>

Prometheus 측정항목을 HPA에 연결

측정항목이 AutoscalingMetric 리소스에 한 번 정의되면 원시 커스텀 측정항목(예: autoscaling.gke.io|<custom-resource-name>|<metric-name>)과 동일한 직관적인 형식을 사용하여 표준 HorizontalPodAutoscaler에서 측정항목을 참조할 수 있습니다.

전역 확장(Prometheus 측정항목)

단일 집계 값을 반환하는 큐 크기와 같은 전역 측정항목의 경우:

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling/v2\r\nkind: HorizontalPodAutoscaler\r\nmetadata:\r\n name: worker-hpa\r\nspec:\r\n scaleTargetRef:\r\n apiVersion: apps/v1\r\n kind: Deployment\r\n name: worker-deployment\r\n maxReplicas: 10\r\n metrics:\r\n - type: External\r\n external:\r\n metric:\r\n name: autoscaling.gke.io|gmp-metric|pubsub-queue-depth\r\n target:\r\n type: AverageValue\r\n averageValue: 100 # maintain queue size at ~100 per pod'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05709b10>)])]>

Cloud Monitoring 포드별 측정항목을 기준으로 확장

GKE는 최신 게이지 측정항목 값 기반의 확장을 기본적으로 지원하지만, PromQL은 더 높은 유연성을 제공하여 시간대별로 확장하고 비율 또는 히스토그램 백분위수를 계산할 수 있습니다.

이 기능을 사용하려면 포드 이름의 라벨을 포함하도록 PromQL 측정항목을 구성한 다음 AutoscalingMetric 매니페스트 내에서 type: Pods를 할당합니다. 다음은 5분 롤링 기간 동안 포드의 평균 메모리 사용량을 계산하는 예시입니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: autoscaling.gke.io/v1beta1\r\nkind: AutoscalingMetric\r\nmetadata:\r\n name: per-pod-stored-metric\r\nspec:\r\n metrics:\r\n - promql:\r\n name: container-memory-metric\r\n query: |\r\n sum by ("pod")\r\n (avg_over_time({"container_memory_working_set_bytes"}[5m]))\r\n type: Pods # The promql query returns per-pod metrics'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc0570a590>)])]>

주요 이점

어댑터 유지보수 불필요: 설치, 구성 또는 업그레이드할 포드가 없습니다. 전체 수명 주기가 GKE 내에서 완전히 관리됩니다.
간소화된 보안: Kubernetes 기본 노드 서비스 에이전트는 기본적으로 동일한 프로젝트의 Cloud Monitoring 및 Google Managed Prometheus에 대한 읽기 권한을 가집니다. 추가 IAM 서비스 계정, 키 또는 통합 파라미터가 필요하지 않습니다.
짧은 지연 시간 및 빠른 확장성: 새로운 자동 확장 측정항목 시스템은 15초마다 백엔드를 폴링하여 빠른 확장 반응을 보장합니다.
풍부한 쿼리 기능: PromQL의 모든 기능(비율 계산, 평균, 백분위수 포함)을 활용하여 상위 수준의 비즈니스 및 사용자 환경 목표를 확장으로 직접 변환합니다.
새로운 HPA Scale-to-zero 기능 지원: 수요가 0이 되면(예: Pub/Sub 큐 크기) 워크로드 복제본을 0으로 축소하는 데 활용할 수 있습니다. 더 중요한 것은 CapacityBuffers API를 사용하여 복제본이 0개인 상태에서도 빠르게 백업할 수 있습니다.

지금 사용해 보기

GKE는 커스텀 컨테이너 측정항목과 Prometheus 측정항목을 모두 기본적으로 지원하여 더욱 강력하고 성능이 뛰어나며 원활한 자동 확장 환경을 제공합니다. Prometheus 측정항목에 대한 기본 지원은 현재 프리뷰 버전입니다. 첫 번째 AutoscalingMetric 리소스를 설정하는 방법을 자세히 알아보려면 최신 GKE 자동 확장 문서를 참고하세요.

SeaVerse, GKE 에이전트 샌드박스로 인프라 비용 60% 절감

Sun, 27 Sep 2026 22:00:00 +0000

편집자 주: 오늘은 SeaArt 산하의 게임 스타트업인 SeaVerse의 이야기를 들어보겠습니다. SeaVerse는 사용자가 가벼운 게임, 캐릭터 채팅, 대화형 앱을 실행하거나 프롬프트를 통해 자신만의 경험을 직접 만들 수 있는 플레이 가능한 AI 경험을 위한 플랫폼을 구축하고 있습니다. 이러한 창작 루프를 지원하기 위해 SeaVerse에는 강력한 격리, 짧은 지연 시간, 더 나은 관측 가능성, 더 유연한 비용 구조를 갖춘 동적인 멀티 테넌트 샌드박스 워크로드를 실행할 수 있는 인프라가 필요했습니다. Google Kubernetes Engine(GKE)과 GKE Agent Sandbox는 SeaVerse에 이러한 AI 워크로드를 실행할 수 있는 관리형 기반을 제공하여 팀이 인프라 비용을 최대 60%까지 절감하는 동시에 크리에이터가 아이디어를 실제 플레이 가능한 경험으로 구현하는 데 걸리는 시간을 단축할 수 있도록 지원했습니다. 자세한 내용을 알아보려면 계속 읽어보세요.

AI가 놀이터라면 어떨까요? 플레이 가능한 AI 경험을 위한 창작 중심 플랫폼인 SeaVerse에 오신 것을 환영합니다. 이곳에서 AI 창작물은 뱀이 따라갈 길을 그리는 것처럼 평화로울 수도 있고, 음악이 배경으로 흐르는 졸라맨 시뮬레이션처럼 혼란스러울 수도 있습니다. 가벼운 게임을 즐기러 오는 사람도 있고, AI 캐릭터와 채팅하거나, 대화형 앱을 사용해 보거나, 시각적 패턴을 만들거나, 만든 것을 공유하거나, 아이디어를 재구성해 새로운 것을 만들려는 사람도 있습니다.

SeaVerse는 모든 경험이 즉각적이고 공유하기 쉬워야 한다는 단순한 약속을 바탕으로 구축되었습니다. 크리에이터는 기존의 코딩 워크플로 없이도 일상 언어로 아이디어를 설명하고 결과를 다듬은 후 순식간에 게시할 수 있어야 합니다.

이러한 단순성을 실현하려면 강력한 인프라가 필요합니다. 사용자가 만드는 모든 창작물은 생성, 실행, 미리보기, 디버그, 게시, 리믹스라는 동일한 과정을 거칩니다. 이 과정 중 어느 한 부분이라도 느리거나 불안정하거나 제대로 격리되지 않으면 사용자는 즉시 그 영향을 느끼게 됩니다. 바로 이러한 이유로 GKE와 GKE 에이전트 샌드박스를 선택했습니다.

즉각적인 상호작용을 위한 인프라 과제

사용자에게는 간편해 보이지만, 실제로는 그렇지 않습니다. SeaVerse의 모든 창작물은 별개의 워크로드로 실행되며 첫 번째 상호작용부터 안정적으로 작동해야 합니다.

각 워크로드가 자체 환경에서 실행되기 때문에 사용자, 창작물, 샌드박스 간에 명확한 보안 경계가 필요했습니다. 하지만 지나치게 엄격한 격리는 보호하려는 창의적인 작업 흐름을 저해할 수 있으며, 문제가 발생했을 때 진단하는 데 비용이 많이 들었습니다. 엔지니어들은 환경 내부에서 무슨 일이 일어나고 있는지 거의 파악하지 못한 채 실행 체인의 여러 부분에서 문제를 추적해야 했습니다.

기존 샌드박스 접근 방식을 살펴보았지만, 멀티 테넌트 환경 전반에서 빠른 진단을 지원하려면 더 심층적인 커널 수준의 격리와 대규모 네이티브 관측 가능성이 필요했습니다. 뭔가 변화가 필요했습니다.

GKE 및 GKE 에이전트 샌드박스 기반의 빌드

엔지니어링팀을 클러스터 유지보수팀으로 전환하지 않고도 Kubernetes를 안정적이고 안전하게 운영할 수 있는 방법이 필요했기 때문에 GKE를 선택했습니다. GKE는 우리가 필요로 했던 검증된 생태계와 운영 도구를 제공하여 인프라 관리보다는 플랫폼 구축에 집중할 수 있도록 지원했습니다.

에이전트 코드 실행 및 컴퓨터 사용을 위해 설계된 Kubernetes 프리미티브인 GKE 에이전트 샌드박스는 강력한 격리에 대한 요구사항을 충족하여 생성 경험을 저해하지 않으면서 강력한 보안 경계를 적용했습니다. Kata Containers+Cloudhypervisor(microVM)와 함께 GKE 에이전트 샌드박스를 활용하여 멀티 클라우드 유연성과 강력한 보안의 완벽한 균형을 달성하고, microVM과 gVisor 간에 격리 런타임을 전환할 수 있는 옵션을 통해 AI 샌드박스를 안전하게 실행하고 있습니다. GKE는 100만 개 이상의 샌드박스를 지원한다는 장기적 비전을 실현하기 위해 필요한 확장성을 제공합니다. gVisor를 기반으로 빌드된 이 기능은 Kubernetes 조정 모델을 유지하면서 동적 샌드박스 워크로드에 커널 수준 격리를 제공하므로 클러스터의 나머지 부분과 동일한 스케줄링, 모니터링, 작업을 통해 관리할 수 있습니다.

SeaVerse를 사용하면 단일 프롬프트만으로 대화형 환경을 생성할 수 있습니다. 경험이 생성되면 GKE Agent Sandbox는 미리보기, 미세 조정, 게시를 준비하는 데 필요한 실행, 테스트, 통합, 검증 단계를 지원합니다. 정식 버전에서는 클러스터당 초당 최대 300개의 샌드박스를 할당할 수 있으며, 할당의 90%가 200밀리초 이내에 완료됩니다. GKE와 GKE Agent Sandbox는 AI 생성 대화형 워크로드를 위한 안정적인 기반을 제공하여 팀이 제품 경험에 집중할 수 있도록 지원했습니다.

블랙박스에서 글라스박스로

GKE 에이전트 샌드박스가 도입되기 전에는 샌드박스 워크로드에 장애가 발생하면 원인을 파악하기가 어려웠습니다. 뭔가 잘못되었다는 사실은 알 수 있었지만, 그 원인을 파악하는 데 필요한 런타임 상태 정보, 측정항목 또는 오류 신호가 부족했습니다.

이제 Google Cloud의 기반 로깅 및 모니터링이 이러한 샌드박스 환경에 직접 적용되어 워크로드 동작을 더 명확하게 파악하고, 문제를 더 빠르게 해결하며, 멀티 테넌트 워크로드를 관리하기 위한 더 강력한 기반을 제공합니다.

이러한 가시성은 개발자뿐만 아니라 플랫폼 사용자에게도 중요합니다. 크리에이터는 로그, 클러스터 또는 조정 레이어를 볼 수 없습니다. 사용자는 경험이 빠르게 열리는지, 그림을 그리거나 클릭하거나 채팅하거나 공유할 때 반응하는지, 원활하게 계속 빌드할 수 있는지 확인합니다.

비용 절감으로 이어지는 유연성

GKE 에이전트 샌드박스는 비용에 대한 관점도 바꿔 놓았습니다. 이전에는 안전한 샌드박스 환경을 운영하려면 특정 서버 유형에 대한 종속성이 더 강해져 각 워크로드에 리소스를 정확하게 매칭하는 데 한계가 있었습니다. GKE 에이전트 샌드박스를 사용하면 적절한 규모의 클라우드 VM에서 안전하고 격리된 워크로드를 실행할 수 있습니다. 이를 통해 리소스 할당의 유연성이 향상되었으며 인프라 비용을 최대 60%까지 절감할 수 있었습니다.

이러한 유연성은 스토리지 분야로도 확대되었습니다. 모든 SeaVerse 창작물이 단일 세션에서 완성되는 것은 아닙니다. 크리에이터가 다시 돌아와 작품을 다듬고, 이전 아이디어를 발전시키고, 다른 사람을 초대해 자신의 작품을 리믹스하면서 시간이 지남에 따라 발전하는 작품도 있습니다. 기존 아키텍처는 이러한 복잡한 사용 사례에 필요한 영구 파일 시스템 기능을 지원하지 못했지만 이제는 그 한계가 사라졌습니다. 워크로드에 필요한 경우 영구 스토리지를 연결하는 동시에 멀티 테넌트 AI 환경에 필요한 격리 경계를 유지할 수 있습니다. 크리에이터는 빠르게 열 수 있을 뿐만 아니라, 시간이 지남에 따라 더 쉽게 다듬고, 다시 살펴보고, 발전시켜 나갈 수 있게 되었습니다.

다음 리믹스

진화하고 깊이를 더해갈 수 있는 창작물을 지원하는 것이 Google이 구축하고 있는 것의 핵심입니다. 플레이 가능한 AI의 발전은 아직 초기 단계에 있습니다. 플랫폼이 성장함에 따라 가장 중요한 요소인 안정성, 관측 가능성, 탄력적 확장, 비용 효율성을 지속적으로 강화해야 합니다. 이 모든 것은 빠르고, 안정적이며, 표현력이 풍부한 크리에이터 경험을 제공하기 위함입니다.

또한 더 스마트한 분석과 창작 지원을 위해 추가적인 Google Cloud 도구를 살펴보고 있습니다. Gemini와 에이전트 모델은 운영자와 크리에이터가 경험의 성과를 더 잘 이해하는 데 도움이 될 수 있습니다. BigQuery AI 및 ML 기능은 이탈 예측, LTV 및 ROI 예측, 사용자 세분화와 같은 사용 사례를 지원할 수 있습니다. Gemini Enterprise Agent Platform의 Imagen 및 Veo와 같은 멀티모달 도구는 소재 분석, 창의적 콘텐츠 생성, AI 대화형 콘텐츠 제작의 새로운 가능성을 열어줍니다.

Google의 목표는 AI 경험을 즉각적이고 표현력이 풍부하며 연결된 느낌을 주도록 만드는 것입니다. GKE와 GKE Agent Sandbox를 통해 차세대 플레이 가능한 AI를 위한 더욱 강력한 기반을 갖추게 되었습니다.

Agent Substrate: GKE에 확장 가능하고 신뢰할 수 있는 고밀도 인프라 제공

Sun, 27 Sep 2026 22:00:00 +0000

이제 Google Kubernetes Engine(GKE)에서 Agent Substrate를 사용할 수 있게 되었다는 소식을 전해드립니다. Agent Substrate는 표준 컨테이너 런타임보다 10배 더 높은 밀도로 수백만 개의 샌드박스를 실행하도록 설계된 오픈소스, 보안 우선 에이전트 실행 런타임입니다. 자율 에이전트 시대에 맞게 특별히 설계된 Substrate는 네이티브 제로 트러스트 커널 및 네트워크 격리 기능을 바탕으로 초당 500회 이상의 일시중지/재개 활성화 요청 처리 시에도 500ms 미만의 재개 성능을 제공합니다.

Agent Substrate는 모든 Kubernetes 인프라에서 실행되며 GKE에 최적화된 오픈소스 솔루션으로 제공됩니다. 앞서 나가는 AI팀은 이미 이 프레임워크를 활용하고 있습니다. Hermes Agent를 개발한 Nous Research팀은 Agent Substrate를 기반으로 활발하게 개발을 이어가고 있습니다. Hermes는 현재 생산성, 코딩, CLI, 개인 에이전트 전반에서 OpenRouter 사용량 기준 전 세계 1위 AI 에이전트로 선정되었습니다.

로컬 규모에서 100만 에이전트 규모로 확장

개발자들은 이미 Antigravity, Claude Code, Codex, OpenClaw, Hermes를 비롯한 여러 하네스를 로컬에서 실행하고 있지만, 이는 코드를 생성하고, 도구와 상호작용하고, 자동화된 실행을 주도하는 수십만 개의 장기 실행 에이전트를 동시 실행하는 것과는 근본적으로 다릅니다. 기존 아키텍처로는 이러한 과제를 해결하기 어려운 경우가 많습니다.

에이전트 플랫폼을 로컬 프로토타입에서 대규모 실행 에이전트로 확장하면 인프라 제약 조건에 근본적인 변화가 생기며, 여기에는 다음이 포함될 수 있습니다.

불투명한 신뢰 경계: 모델이 임의의 코드를 즉석에서 생성하고 실행할 수 있습니다. 커널 수준의 격리 및 동적 네트워크 제어 기능이 없으면 사람이 한 번도 검토한 적 없는 신뢰할 수 없는 코드를 실행할 때 호스트 이스케이프, 사용자 인증 정보 도용, 데이터 무단 반출의 위험에 노출됩니다.
도구 액세스 마찰: 에이전트가 명령줄 도구, 헤드리스 브라우저, 파일 시스템 작업공간을 호출하려면 완전한 컴퓨터 환경이 필요하며, 이러한 워크로드를 안전하게 실행하는 과정은 빠르고 쉬워야 합니다.
대규모 버스트: 에이전트 하네스, 벤치마크, 강화 학습 출시는 분당 수천 개의 샌드박스를 생성할 수 있습니다. 범용 스케줄러는 이러한 변동에 어려움을 겪으며, 컨테이너 이미지를 반복적으로 압축 해제하면 심각한 디스크 경합이 발생할 수 있습니다.
유휴 컴퓨팅: 자율 에이전트는 모델 추론, 도구 응답 또는 인간 피드백을 기다리는 동안 대부분의 시간을 휴면 상태로 보냅니다. 유휴 컨테이너에 전용 CPU와 RAM을 예약해 두는 것은 귀중한 리소스를 낭비하는 일입니다.

에이전트를 위해 특별히 빌드된 Substrate

이러한 문제가 발생하면 플랫폼팀이 어려운 선택의 기로에 놓이게 됩니다. 제어와 격리를 희생하거나, 아니면 VM의 높은 지연 시간과 비효율성을 감수해야 합니다. 이제 팀에서 더 이상 이 문제로 고민하지 않아도 됩니다.

Agent Substrate는 에이전트 실행을 머신 관리에서 분리하여 이러한 문제를 해결합니다. 클라우드 네이티브 Kubernetes 인프라를 기반으로 빌드된 Agent Substrate는 에이전트형 워크로드에 맞게 특별히 설계된 새로운 실행 레이어를 제공합니다.

여기에서 실행 레이어는 다음을 통해 샌드박스 에이전트 환경의 수명 주기를 직접 관리합니다.

보안을 우선으로 하는 기본 설정: 하드웨어 격리 Cloud Hypervisor microVM 또는 gVisor 샌드박스가 세분화된 네트워크 정책을 적용하고 에이전트 자체의 접근 범위를 벗어난 위치에 사용자 인증 정보를 삽입하는 이그레스 프록시와 함께 사용되어 사용자 인증 정보 도용을 방지합니다.
1초 미만의 활성화: 컨테이너 부팅 지연 없이, 필요에 따라 사전 준비된 작업자에 활성화된 에이전트를 밀리초 단위로 디스패치합니다.
높은 효율성: 유휴 액터가 수백 밀리초 내에 정지되고 예약 해제되어 컴퓨팅 리소스를 확보합니다.
오픈소스 및 이식성: 모든 컴퓨팅 환경의 모든 Kubernetes 클러스터에서 실행되며 Claude Code, OpenClaw, Hermes를 비롯한 모든 에이전트 프레임워크 또는 하네스와 호환됩니다.

핵심 아키텍처 원칙

Google은 Agent Substrate가 이러한 과제를 해결하는 방식의 기준이 되는 네 가지 핵심 아키텍처 원칙을 준수합니다.

1. 커널 및 네트워크에서 보안을 우선으로 하는 기본 설정

AI 에이전트의 핵심 기능은 신뢰할 수 없는 코드와 터미널 명령어를 생성하고 실행하는 것입니다. 신뢰할 수 없는 코드를 공유 서버에서 실행하면 공유 커널 또는 네트워크 수준에서 침입이나 의도치 않은 데이터 유출이 발생할 심각한 위험이 있습니다.

Agent Substrate는 호스트 커널과 네트워크 레이어 모두에 대해 보안을 우선으로 하는 기본 설정을 취합니다. 팀은 전체 Linux 커널 호환성을 제공하는 하드웨어 격리 Cloud Hypervisor microVM 또는 오버헤드가 더 낮은 커널 격리를 제공하는 gVisor 샌드박스 중에서 선택할 수 있습니다. Agent Substrate의 통합 게이트웨이는 모든 이그레스 및 인그레스 요청을 관리하여 네트워크 액세스에 대한 세분화되고 확장 가능한 제어를 지원합니다.

2. 지연 시간이 짧은 활성화를 위해 빌드된 컨트롤 플레인 및 데이터 플레인

격리된 장기 실행 에이전트 워크로드의 밀도를 최적화하려면 가능한 한 가장 낮은 지연 시간과 가장 높은 일시중지 및 재개 작업 속도를 지원하는 전용 컨트롤 플레인과 데이터 플레인이 필요합니다. Agent Substrate는 최소한의 지연 시간으로 데이터 인식 스케줄링을 처리하는 전용 컨트롤 플레인을 도입합니다. 한편 데이터 플레인은 사전 준비된 작업자에서 초당 수백 건의 일시중지/재개 작업을 직접 처리하여 환경 준비에 따른 오버헤드를 줄입니다. 스냅샷은 상태 지속성을 유지하기 위해 로컬 디스크와 Google Cloud Storage에 기록됩니다. 샌드박스 환경은 500밀리초 이내에 이전 상태로 재개될 수 있으며, 유휴 상태가 되면 즉시 다시 일시중지될 수 있습니다.

3. 고밀도 및 활성 전용 컴퓨팅 경제성

에이전트는 대부분의 시간을 모델 추론, 도구 응답 또는 사용자 입력을 기다리는 데 사용합니다. 유휴 컨테이너를 위해 물리적 CPU와 RAM을 예약하면 비용이 많이 들면서도 한정되어 있는 용량이 묶여 버릴 수 있으며, 대규모로 에이전트 Fleet을 실행하는 것이 지속 불가능해질 수 있습니다.

Agent Substrate는 에이전트가 일시중지되는 순간 리소스를 해제할 수 있습니다. 게스트 하이퍼바이저의 상태를 로컬 디스크와 Cloud Storage에 스냅샷으로 저장하여 RAM과 CPU를 확보하고 다른 에이전트를 실행하는 동시에 상태를 그대로 유지합니다. 다음 턴 또는 도구 호출이 들어오면 Agent Substrate는 스냅샷이 생성된 세션을 밀리초 단위로 재개합니다. 이 제로 유휴 모델은 호스트당 1,000개 이상의 휴면 에이전트를 패킹하여 기존 컴퓨팅보다 10배 더 높은 컴퓨팅 밀도를 제공할 수 있습니다. 턴 간에 공유 파일 시스템이 필요한 워크로드의 경우, 선택적 Filestore 에이전트 볼륨 컨트롤러가 영구 NFS 스토리지를 제공합니다. 자세한 내용은 아래를 참고하세요.

4. 기반으로서의 Kubernetes: 확장성과 안정성

표준 VM에서 커스텀 샌드박스 조정자를 빌드하면 팀은 노드 복구, 자동 확장, 멀티 영역 스케줄링, 네트워크 정책과 같은 지루한 운영 도구를 유지해야 합니다. 하지만 표준 Kubernetes 포드 수명 주기를 통해 1초 미만의 도구 호출을 각각 라우팅하면 각 요청에 몇 초의 지연 시간이 추가됩니다.

Agent Substrate는 두 가지 접근 방식을 결합합니다. 고빈도 일시중지-재개 작업은 전용 데이터 플레인을 통해 로컬 작업자에서 직접 실행됩니다. 한편 Kubernetes는 머신을 관리하고, 자체 복구 노드, Fleet 자동 확장, 클러스터 안정성을 처리하며, 작업자 포드 자체의 수명 주기도 관리합니다. 표준 포드 시맨틱스가 필요한 워크로드의 경우 에이전트 샌드박스 및 커널 격리 포드와 같은 기존의 기본 요소가 계속 함께 작동합니다.

Google Cloud 인프라에 최적화

100만 개의 에이전트 규모를 달성할 수 있는 에이전트 플랫폼을 빌드하려면 적절한 기본 컴퓨팅 및 스토리지 인프라가 필요합니다. GKE의 Agent Substrate는 커스텀 ComputeClass를 통해 스팟 및 주문형 풀을 포함한 다양한 형태와 제품군의 머신 풀을 동적으로 관리함으로써 머신 가용성과 유연성을 극대화합니다. 여기에는 Google의 커스텀 Arm 기반 프로세서인 Google Axion에 대한 기본 지원이 포함되며, 이는 샌드박스 워크로드에 대해 경쟁 클라우드 제품 대비 최대 30% 더 나은 가격 대비 성능을 제공합니다. 스테이트풀(Stateful) 작업공간의 경우, GKE의 Agent Substrate를 Filestore 에이전트 볼륨과 선택적으로 통합할 수 있습니다. 이 새로운 제품은 NFS 마운트를 밀리초 단위로 연결 및 분리하여 에이전트가 거의 즉시 작업을 시작/재개할 수 있도록 하며, 기본 Read-Write-Many(RWX) 액세스 및 POSIX 호환 파일 잠금을 통해 쓰기 충돌 없이 안전한 멀티 에이전트 협업을 지원합니다.

확장 가능한 기반에서 에이전트 플랫폼 빌드

프로덕션 에이전트 애플리케이션을 빌드할 때 강력한 보안, 짧은 지연 시간, 운영 규모 중 어느 하나도 포기할 필요가 없습니다.

Nous Research는 OpenRouter 기준 사용량 세계 1위 AI 에이전트인 Hermes를 개발했으며, Hermes는 생산성, 코딩, 개인용 및 CLI 에이전트 부문에서도 1위를 차지하고 있습니다. Nous Research는 Agent Substrate의 초기 설계 파트너로서 런타임이 에이전트 워크로드에서 발생하는 격리 및 ID 요구사항을 어떻게 처리하는지 평가했습니다.

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

Agent Substrate는 머신 복원력, 자가 복구 노드, 선언적 관리가 가능한 Kubernetes와 커널 격리, 활성 전용 컴퓨팅, 1초 미만의 실행을 위해 빌드된 에이전트 네이티브 데이터 플레인을 결합하여 엔지니어링팀이 확장성을 확보할 수 있는 명확한 경로를 제공합니다.

Agent Substrate는 오픈소스이며 모든 GKE 고객이 비프로덕션 워크로드에 사용할 수 있습니다. 프로덕션에 대한 정식 버전 지원은 허용 목록을 통해 제공됩니다. GKE 클러스터에 Agent Substrate를 배포하려면 GKE의 Agent Substrate 문서를 참고하세요. 자세한 내용은 Agent Substrate 정보를 참고하거나 오픈소스 저장소를 방문하세요.

분산된 Ray 클러스터에 gVisor 샌드박스 도입

Thu, 03 Sep 2026 21:00:00 +0000

강화 학습 (RL) 생태계는 복잡한 학습 후 워크플로를 위한 통합 컴퓨팅 런타임으로 Ray를 빠르게 채택하고 있습니다. Google Cloud 전반에서 고객은 멀티모달 데이터 파이프라인부터 최첨단 RL에 이르는 다양한 워크로드에 Ray를 사용하고 있습니다. 그러나 에이전트 및 추론 모델이 발전함에 따라 중요한 병목 현상이 발생했습니다. 바로 동적 출시, 코드 생성, 멀티턴 도구 상호작용을 안전하게 실행하기 위해 격리된 안전한 샌드박스를 대규모로 조정하는 것입니다. 오늘 Google Cloud는 Anyscale과의 파트너십을 통해 Google에서 개발 중인 에이전트 AI 기술을 활용하여 분산된 Ray 클러스터에 기본 제공되는 고성능 샌드박스를 제공하는 Ray용 실험 라이브러리를 소개하게 되어 기쁩니다.

Ray 기본 요소로서의 샌드박스

Ray는 학습 후 워크로드를 조정하는 데 널리 사용되는 런타임이 되었습니다. veRL, NeMo-RL, SLIME, MILES, SkyRL 등의 프레임워크는 이미 Ray를 사용하여 분산된 학습자, 추론 엔진, 롤아웃 작업자 및 기타 구성요소를 조정하고 있습니다.

Ray 샌드박스를 설계할 때 중요한 목표는 격리된 실행을 위한 별도의 추상화를 도입하는 대신 기존 Ray 프로그래밍 모델에 자연스럽게 맞도록 만드는 것이었습니다. 샌드박스는 Ray가 관리하는 다른 리소스와 동일한 속성을 많이 가지고 있습니다. 즉, 머신에 배치되고, 리소스가 할당되고, 생성 및 소멸되고, 장애로부터 복구되고, 주변 워크로드에 따라 확장되어야 합니다. 이로 인해 각 상위 샌드박스를 Ray Actor를 통해 표현하게 되었습니다.

Ray 스케줄러는 샌드박스를 실행할 노드를 결정하고 해당 CPU 및 메모리 리소스를 예약합니다. 샌드박스 행위자는 수명 주기를 관리하고 gVisor는 해당 노드에서 격리된 실행 환경을 제공합니다.

Ray 2.58부터 프레임워크 작성자와 연구자는 나머지 워크로드에 이미 사용 중인 동일한 Ray API와 패턴을 사용하여 샌드박스 환경을 관리할 수 있습니다. 예를 들면 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental import sandbox\r\n\r\nray.init()\r\n# Create a gVisor sandbox environment and return an actor handle for a proxy actor\r\nsb = sandbox.create(\r\n cpu=1.0,\r\n memory="512Mi",\r\n image="python:3.12-slim"\r\n)\r\n# Execute code inside the sandbox\r\nresult = ray.get(sb.exec.remote("python -c \'import sys; print(sys.version)\'"))\r\nprint(result.stdout)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc061e83d0>)])]>

이렇게 하면 OCI 호환 이미지에서 gVisor 샌드박스가 생성되고 Ray Actor 핸들이 반환됩니다. exec에 대한 호출은 일반적인 Ray Actor 호출이므로 샌드박스는 클러스터의 어디에나 있을 수 있습니다. 생성된 행위자는 gVisor로 작업을 전달하는 프록시입니다.

샌드박스 API는 에이전트형 워크로드에 필요한 기본 수명 주기를 다룹니다.

OCI 컨테이너 이미지에서 환경 만들기
CPU 및 메모리 한도 설정
환경 변수, 작업 디렉터리, 네트워킹 구성
명령어 실행
파일 읽기, 쓰기, 업로드, 다운로드
샌드박스 상태 검사
환경을 종료하거나 삭제합니다.

하위 수준의 사용 사례의 경우 SandboxRuntime은 로컬 gVisor 샌드박스에 대한 직접 액세스를 제공하며 사용자가 OCI 사양을 gVisor에 전달하기 전에 수정할 수 있도록 합니다. 이 API를 사용하여 액터 내부에 로컬 샌드박스 풀을 빌드하는 방법의 예시는 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'import ray\r\nfrom ray.experimental.sandbox.runtime import SandboxRuntime\r\n\r\n@ray.remote\r\nclass SandboxPool:\r\n def __init__(self, size: int = 3, image: str = "python:3.10-slim"):\r\n self.runtime = SandboxRuntime()\r\n self.sandboxes = [\r\n self.runtime.create(image=image, memory="512Mi")\r\n for _ in range(size)\r\n ]\r\n\r\n def run_command(self, index: int, command: str):\r\n return self.runtime.exec(self.sandboxes[index], command)\r\n\r\n def close(self):\r\n for sb_id in self.sandboxes:\r\n self.runtime.delete(sb_id)\r\n\r\n# Deploy an actor managing a pool of local sandboxes\r\npool = SandboxPool.remote(size=3)\r\nresult = ray.get(pool.run_command.remote(0, "python3 -c \'print(\\"Hello from pool!\\")\'"))\r\nprint(result.stdout)\r\nray.get(pool.close.remote())'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc06293b50>)])]>

gVisor를 사용해야 하는 이유

모델에서 생성된 코드를 실행한다는 것은 환경 내의 코드를 신뢰할 수 없는 것으로 취급한다는 의미입니다. Ray 샌드박싱은 Google의 오픈소스 애플리케이션 커널인 gVisor를 초기 샌드박스 런타임으로 사용합니다. gVisor는 사용자 공간에서 Linux 시스템 호출 인터페이스의 상당 부분을 구현하여 워크로드와 호스트 커널 사이에 추가적인 격리 경계를 설정합니다. OCI와 호환되며 표준 컨테이너 이미지로 작동하고 Docker 데몬이나 호스트 Docker 소켓을 샌드박스에 노출할 필요가 없습니다.

이 조합은 에이전트 워크로드에 특히 유용합니다. 환경은 동적으로 생성할 수 있을 만큼 가볍게 유지되면서도 생성된 코드를 일반 컨테이너에서 직접 실행하는 것보다 더 강력한 격리를 제공합니다. 또한 gVisor는 1초 미만의 샌드박스 시작 시간과 샌드박스당 낮은 메모리 오버헤드를 제공하므로 샌드박스를 비교적 세분화된 분산 리소스로 사용할 수 있습니다.

Ray의 향후 버전에서는 Agent Substrate 또는 Kata Containers와 같은 다른 샌드박싱 런타임으로 지원을 확장할 계획입니다.

GKE에서 Ray 샌드박싱 사용해 보기

Ray 샌드박스에 대해 자세히 알아보려면 Ray 문서를 참고하세요. GKE에서 이러한 샌드박싱 기능을 사용해 보려면 Ray 샌드박싱 사용자 가이드로 이동하세요. 의견이나 아이디어가 있으신가요? GitHub 문제에 대한 토론에 참여하여 강화 학습을 위한 Ray의 미래에 대해 공동작업하세요.

GKE에서 AI 공급망 보호: 자동화된 AI BOM을 위한 k8s-aibom 소개

Mon, 31 Aug 2026 22:00:00 +0000

보안팀은 섀도우 AI를 어떻게 관리해야 할까요? 개발자가 정식 등록 없이 배포한 워크로드는 조직에서 권한이 있는 Daemonset, 커널 수준 액세스, 수동 포드 사양 편집을 요구하여 개발 속도를 늦추고 안정성을 저해하는 것을 꺼리기 때문에 기존 보안 스캐너를 피하는 경우가 많습니다.

이러한 교착 상태를 타개하기 위해 Google은 오늘 k8s-aibom을 오픈소스화합니다. 이 경량의 권한 없는 Kubernetes 컨트롤러는 클러스터 API와 컨테이너 환경을 지속적으로 모니터링하여 실행 중인 AI 런타임 (예: vLLM 및 Triton)을 자동으로 감지하고 표준 CycloneDX Machine Learning Bill of Materials (ML-BOM)를 생성합니다.

워크로드가 공식적으로 등록되었는지 여부와 관계없이 런타임 실행에서 직접 자동화된 감사 등급 가시성을 제공함으로써 k8s-aibom은 개발자 통합 마찰 없이 팀이 AI 프로젝트를 파일럿에서 프로덕션으로 안전하게 이동하도록 도울 수 있습니다.

마찰 없는 아키텍처

k8s-aibom은 처음부터 완전한 가시성을 위한 CISO의 요구사항과 클러스터 안정성을 위한 SRE의 요구사항을 모두 충족하도록 설계되었습니다. k8s-aibom-system 네임스페이스에 권한이 없는 단일 배포로 배포됩니다. 개발자 마찰이 전혀 없습니다. 사이드카, eBPF 커널 모듈, 권한이 있는 DaemonSet이 필요하지 않으며 기존 개발자 포드 사양을 수정할 필요도 없습니다.

k8s-aibom은 AI 워크로드를 감시하고 BOM을 생성합니다.

검색 파이프라인은 다음 네 가지 명확한 단계를 거쳐 실행됩니다.

클러스터 워크로드 스크랩: 컨트롤러는 클러스터 전반에서 KServe 리소스, 배포, 스테이트풀셋, 데몬셋, 작업을 지속적으로 모니터링합니다.
AI 스택 식별: 고급 패턴 매칭은 컨테이너 이미지, 환경 변수, 명령줄 인수를 검사하여 서빙 런타임 (vLLM, Triton Inference Server, TGI, Ollama), 자율 에이전트 프레임워크 (LangChain, AutoGen, CrewAI), 벡터 데이터베이스 및 RAG 스토어 (Milvus, Qdrant, pgvector), 분산 학습 작업 및 평가 하네스를 감지합니다.
표준 매니페스트 생성: 컨트롤러는 발견된 아티팩트를 공식 OWASP CycloneDX 1.6 머신러닝 BOM (ML-BOM) 문서로 컴파일합니다.
싱크로 내보내기: 컨트롤러는 결과 ML-BOM을 클러스터 내 AIBOM 커스텀 리소스 (CR)의 커스텀 리소스 상태 (status.bomDocument)에 직접 연결하고 Google Cloud Storage 버킷 및 외부 웹훅 엔드포인트를 포함한 선택적 외부 싱크로 라우팅합니다.

애플리케이션팀은 포드 사양을 수정하거나, 사이드카 컨테이너를 삽입하거나, 지속적 통합 및 지속적 배포 (CI/CD) 파이프라인을 변경할 필요가 없습니다. 또한 k8s-aibom은 Kubernetes 클러스터 상태를 순수한 함수형 입력으로 취급합니다. 동일한 클러스터 입력은 바이트가 동일한 ML-BOM 문서를 생성합니다. 이 결정론적 속성 덕분에 k8s-aibom은 GitOps 워크플로에 이상적이며, 사이트 안정성 엔지니어 (SRE)는 AI 종속 항목이 드리프트될 때 정확한 차이를 수행하고 정확한 변경 감지 알림을 트리거할 수 있습니다.

기존 AIBOM 도구의 단점

많은 AI BOM 솔루션은 빌드 타임 스캐너를 제공하여 유휴 상태의 아티팩트에서 BOM을 생성합니다. 이러한 도구를 사용하면 배포할 코드를 추적할 수 있습니다.

상용 AI 보안 플랫폼은 클라우드 네이티브 보안 상황 관리로 그림을 확장하지만, 일반적으로 공급업체별 데이터 모델을 중심으로 형성된 외부 스캔을 통해 확장합니다. 이러한 도구 중 규정 준수 검토자, 보안 운영 (SecOps)팀, 플랫폼 엔지니어가 현재 실행 중인 항목, 연결된 항목, 이러한 주장을 검증하는 방법을 이해하는 데 도움이 되는 도구는 거의 없습니다.

이러한 격차를 해소하기 위해 k8s-aibom을 맞춤형으로 빌드했습니다. 이 도구는 아티팩트 스캔이 아닌 라이브 클러스터 관찰에서 BOM을 생성하고, 공급업체 독점 형식이 아닌 더 광범위한 OWASP 및 Open Source Security Foundation (OpenSSF) 공급망 생태계와 통합되는 표준 준수 CycloneDX 1.6 ML-BOM을 내보내며, 모든 준수 Kubernetes 클러스터에서 권한이 없는 컨트롤러로 실행됩니다. 따라서 기존 빌드 시간 및 상황 관리 도구를 대체하는 것이 아니라 보완하는 역할을 합니다.

신뢰 모델: 인텐트와 추론 분리

규정 준수 감사자와 SecOps 엔지니어에게 원시 원격 분석은 노이즈인 경우가 많습니다. 표준 모니터링 도구는 컨테이너가 실행 중임을 나타내지만 플랫폼 엔지니어가 AI 모델을 명시적으로 구성했는지 아니면 런타임에 자율 스크립트가 동적으로 가져왔는지 증명할 수는 없습니다. k8s-aibom은 결정론적 신뢰 모델을 통해 이러한 모호성을 해결하고 발견된 애셋을 고유한 등급으로 분류합니다.

선언됨: 고객 또는 개발자가 워크로드 구성에서 명시적으로 정의함 (예: --model meta-llama/Llama-2-7b와 같은 컨테이너 인수를 명시적으로 전달) '선언된' 신뢰도 감지는 명확한 인간의 의도를 나타냅니다.
추론됨: 컨트롤러의 패턴 매칭 엔진이 컨테이너 이미지, 환경 변수, 실행 프로필을 심층 검사하여 자율적으로 도출합니다. (예: ^vllm/.* 컨테이너 서명 식별)
해결되지 않음: 활성 AI가 감지되었지만 정확한 모델 파라미터, 가중치, 버전을 결정론적으로 설정할 수 없는 워크로드에 적용됩니다. '해결되지 않음' 신뢰 감지는 즉시 워크로드에 플래그를 지정하여 표적 보안 검토를 수행합니다.

이러한 구조화된 분류 체계를 통해 규정 준수 검토자는 명시적인 엔지니어링 의도와 머신 추론을 즉시 분리하여 감사 중에 반박할 수 없는 신뢰 체인을 구축할 수 있습니다.

불변성과 최소 권한: 감사 등급 보안 모델 빌드

감사자는 로그와 측정항목이 보안 침해된 노드나 권한이 상승된 관리자에 의해 수정, 삭제, 조작될 수 있기 때문에 표준 관측 가능성 원격 분석에 대해 여전히 깊은 회의감을 가지고 있습니다. k8s-aibom은 엄격한 최소 권한 격리 및 데이터 불변성을 기반으로 구축된 감사 등급 증거 추적을 설정합니다.

컨트롤러는 최소한의 Identity and Access Management (IAM) 워크로드 아이덴티티에 바인딩된 전용 Kubernetes 서비스 계정으로 작동합니다. BOM 레코드를 외부 스토리지 싱크에 쓸 수 있는 유일한 ID로 작동하며 roles/storage.objectCreator 권한만 필요합니다.

가장 엄격한 감사 및 증거 표준을 충족하기 위해 Google Cloud Storage 외부 싱크 구현은 객체 생성 시 DoesNotExist 선행 조건을 적용합니다. ML-BOM이 Cloud Storage 버킷에 작성되면 객체는 암호화 방식으로 불변이 됩니다.

보안 침해된 클러스터 행위자나 악성 워크로드에 의해 무단으로 덮어쓰거나 수정되거나 소급하여 조작될 수 없습니다. SecOps팀은 규제 기관에 제시된 이전 감사 로그가 클러스터 실행의 변경 불가능한 기록임을 절대적으로 확신할 수 있습니다.

거버넌스 준비 가속화: 글로벌 규제 프레임워크에 매핑

표준화된 CycloneDX 1.6 ML-BOM 생성을 자동화함으로써 k8s-aibom은 저수준 Kubernetes 런타임 상태와 고수준 거버넌스 프레임워크 사이의 격차를 직접적으로 해소합니다. 주요 글로벌 표준에 필수적인 실증적 기반 데이터를 제공하여 지연된 GKE AI 배포를 차단 해제합니다.

EU AI 법: 조직이 제12조 (지속적인 추적 가능성을 위한 자동화된 로깅 및 기록 보관) 및 제50조 (AI 시스템의 투명성 의무)를 준수하도록 지원하기 위해 설계되었습니다. 이 도구는 서빙 런타임과 에이전트 스택을 자동으로 분류하여 규정 준수 감사 중에 필요할 수 있는 기술적 증거를 간편하게 수집할 수 있도록 도와줍니다.
NIST AI 위험 관리 프레임워크 (AI RMF): 거버넌스, 매핑, 측정, 관리 기능을 지원하는 데 도움이 되는 지속적이고 경험적인 애셋 가시성을 제공하여 규정 준수 워크플로를 순전히 수동적인 검사에서 보다 자동화된 애셋 인벤토리 추적으로 전환하는 데 도움이 됩니다.
ISO/IEC 42001:AI 관리 시스템 애셋 검색 및 추적에 대한 규정 준수 노력을 지원하여 인벤토리 검증을 위해 수동 스프레드시트나 정기적인 스냅샷 감사에 의존하는 방식을 줄입니다.

시작하기

k8s-aibom과 같은 기술 솔루션이 CISO, 거버넌스, 위험 및 규정 준수팀, SecOps팀, 플랫폼 엔지니어, 개발자에게 영향을 미치는 섀도우 AI의 다각적인 문제를 완화하는 데 도움이 되는 경우는 드뭅니다.

컨트롤러를 검사하고 CRD 정의를 검토하며 오픈소스 k8s-aibom 프로젝트에 참여하려면 k8s-aibom GitHub 저장소를 방문하세요.

GKE 인퍼런스 게이트웨이(Inference Gateway), 프리픽스 캐싱으로 AI 추론 가속화

Wed, 01 Jul 2026 00:00:00 +0000

*본 아티클의 원문은 2026년 6월 10일 Google Cloud 블로그(영문)에 게재되었습니다.

생성형 AI가 실험적인 파일럿 단계를 넘어 대규모 운영 환경으로 확장되면서, 이제 인프라의 효율성이 핵심 경쟁력으로 자리 잡고 있습니다. 인프라 활용도를 극대화하고 리소스 소모가 큰 액셀러레이터의 대기 시간을 줄이는 가장 효과적인 방법 중 하나는, 실시간 모델 서버 메트릭을 기반으로 생성형 AI 워크로드를 지능적으로 분산하는 GKE 인퍼런스 게이트웨이(GKE Inference Gateway)를 도입하는 것입니다.

기존의 단순한 라운드 로빈(Round-robin) 로드 밸런싱은 액셀러레이터의 불필요한 재연산(Recomputation)을 자주 유발하고 사용자 지연 시간을 늘리는 단점이 있습니다. 반면, GKE 게이트웨이(GKE Gateway)의 자체 확장 기능은 프리픽스 캐싱(Prefix caching)과 모델 기반 라우팅(Model-aware routing) 같은 고급 기술을 제공합니다. 이 기능을 활용하면 대기 중인 액셀러레이터로 요청이 즉시 매핑되므로, 우수한 하드웨어 효율성(Hardware utilization)과 빠른 응답 속도로 대규모 언어 모델(LLM) 서비스를 구현할 수 있습니다.

실제로 발표된 독립 벤치마크 보고서에 따르면, GKE 인퍼런스 게이트웨이는 타사 관리형 쿠버네티스 서비스와 비교했을 때 처리량(Throughput)은 15.7% 높고, 첫 번째 토큰 대기 시간은 92.8% 짧으며, 토큰 간 지연 시간(Inter-token latency)은 62.6% 더 낮아 압도적인 성능 우위를 보였습니다. 덕분에 지연 시간이 길고 운영 비용이 부담스럽던 기존 LLM 기반 애플리케이션을 즉각적인 응답 속도를 갖춘 운영 수준(Production-grade)으로 향상시킬 수 있습니다.

이와 같은 뛰어난 성능은 Snap이 GKE 인퍼런스 게이트웨이를 도입한 실무 사례에서도 확인됩니다.

“Snap에서는 대규모 고성능 추론 환경을 안정적으로 구축하고자 llm-d를 프로덕션 AI 인프라에 통합하여 운영 중입니다. 프리픽스 캐시 기반 라우팅(Prefix-cache-aware routing)을 적용한 결과, 프리픽스 캐시 적중률(Prefix cache hit rates)을 최대 75~80%까지 끌어올렸습니다. 특히 llm-d의 유연한 오픈소스 특성 덕분에 Envoy 기반의 서비스 메시(Service Mesh) 환경과도 매끄럽게 통합되었습니다.” - Vinay Kola, Snap Inc. 소프트웨어 엔지니어링 부문 시니어 매니저

본 블로그에서는 구체적인 활용 사례와 함께 GKE 인퍼런스 게이트웨이의 프리픽스 캐싱 작동 원리를 살펴보고, 최근 진행된 벤치마크 평가 결과를 상세히 공유해 드립니다.

지연 시간 단축의 핵심: 프리픽스 캐싱 (Prefix caching)

프리픽스 캐싱은 자주 반복되는 프롬프트 앞부분(Prefix)의 KV 캐시(활성화 상태, KV cache)를 메모리에 미리 저장하여 LLM 성능을 최적화하는 기술입니다. 여러 사용자 요청이 동일한 시스템 지침(System instructions)이나 기본 컨텍스트, 문서 데이터를 공유할 때, 모델은 해당 영역의 토큰 연산을 완전히 생략하고 바로 다음 단계로 넘어갑니다. GKE 인퍼런스 게이트웨이는 유입되는 요청의 프리픽스를 분석해 해당 데이터를 이미 캐싱해 둔 특정 포드(Pod)로 연결해 줍니다. 따라서 GPU와 TPU의 불필요한 중복 연산 비용(Thinking tax)을 없애고, 무거운 추론 과정을 실시간에 가까운 응답 속도로 전환합니다.

활용 사례 1: 검색 증강 생성(RAG) 기반 문서 및 코드베이스 Q&A

RAG 패턴으로 방대한 엔터프라이즈 코드 저장소나 문서를 조회할 때, 전체 데이터셋을 정적 캐시 프리픽스로 고정해 두면 지연 시간 없이 정확한 실시간 응답을 생성(Grounding)할 수 있습니다.

사용자가 질문을 보낼 때마다 LLM이 매번 수천 줄에 달하는 API 레퍼런스나 사내 위키 문서를 처음부터 다시 분석할 필요가 없습니다. GKE 인퍼런스 게이트웨이가 관련 컨텍스트를 이미 KV 캐시에 로드(Warm-up)해 둔 포드로 사용자의 질문을 즉시 라우팅하기 때문입니다. LLM은 사용자가 새로 입력한 질문 내용만 연산하므로, 불필요한 문서 재연산 프로세스를 완전히 우회합니다.

code_block: <ListValue: [StructValue([('code', '[STATIC PREFIX - STAYS IN CACHE (캐시에 유지되는 정적 프리픽스)]\r\nYou are an expert AI assistant specializing in technical documentation. Below is the complete API documentation for our software platform. Use this context to answer the user\'s questions accurately. If the answer cannot be found in the documentation, say "I cannot find that in the provided context."\r\n\r\n<documentation>\r\n[10,000+ words of API reference documentation, endpoints, error codes, etc. (10,000자 이상의 API 참조 문서, 엔드포인트, 에러 코드 등)]\r\n</documentation>\r\n\r\n[DYNAMIC SUFFIX - CHANGES PER REQUEST (요청마다 변경되는 동적 접미사)]\r\nUser Question: How do I handle a 429 rate limit error using the Python SDK?\r\n(사용자 질문: Python SDK를 사용하여 429 rate limit 에러를 처리하려면 어떻게 해야 하나요?)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc06a57750>)])]>

활용 사례 2: 다중 대화형 챗봇 (Multi-turn chat)

프리픽스 캐싱을 이용하면 트래픽이 집중되더라도 컴퓨팅 인프라 비용 부담 없이 수천 명의 사용자와 동시에 매끄러운 상담 세션을 유지할 수 있습니다. 고정된 챗봇 페르소나 및 핵심 비즈니스 로직 설정을 LLM 서버 내에 영구적으로 캐싱하는 방식을 사용합니다.

기업용 고객 상담 서비스에서 사용되는 기본 시스템 프롬프트와 안내 정보는 수백만 명의 사용자가 유입되어도 완전히 동일합니다. GKE 인퍼런스 게이트웨이는 컨텍스트 기반 라우팅(Context-aware routing)으로 다중 대화 세션을 관리하여 반복적인 기본 토큰 연산을 최소화하므로, 동시 접속자가 급증해도 지연 없는 대화 환경을 지원합니다.

code_block: <ListValue: [StructValue([('code', '[STATIC PREFIX - STAYS IN CACHE (캐시에 유지되는 정적 프리픽스)]\r\n-System Persona: You are "FinBot", a helpful, empathetic, and compliant virtual assistant for ABC Banking Solutions. You must strictly adhere to the following rules:\r\n1. Never provide concrete investment advice.\r\n2. Always verify if the user is asking about checking or savings.\r\n3. Keep your answers under 3 sentences.\r\n4. If a user is angry, offer to connect them to a human manager.\r\n\r\nHere is the current interest rate table for May 2026:\r\n- Savings: 4.2% APR\r\n- Checking: 0.5% APR\r\n- CD (12-month): 5.1% APR\r\n\r\n[DYNAMIC SUFFIX - CHANGES PER REQUEST (요청마다 변경되는 동적 접미사)]\r\nUser: Hi, I\'m trying to figure out how much I\'d make if I locked away $10,000 for a year?\r\n(사용자: 안녕하세요, 1만 달러를 1년 동안 묶어두면 얼마를 벌 수 있는지 알고 싶어요.)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fcc05dd7f10>)])]>

GKE, 타사 관리형 쿠버네티스 대비 뛰어난 성능 우위 입증

이와 같은 아키텍처 관점의 강점을 객관적으로 확인하고자, Principled Technologies에서는 최근 GKE 인퍼런스 게이트웨이를 적용한 GKE 환경과 기존의 라운드 로빈 HTTP 로드 밸런싱을 쓰는 표준 타사 관리형 쿠버네티스 서비스를 비교 검증한 독립 벤치마크 평가 결과를 발표했습니다.

두 서비스 모두 동일한 하드웨어(NVIDIA A100 40GB GPU 8개)와 Llama 3.1 8B Instruct 공유 프리픽스 워크로드를 사용해 공정하게 테스트되었습니다. 측정 결과 GKE는 단순히 우위를 점하는 수준을 넘어, 아래의 3대 핵심 메트릭에서 압도적인 격차로 인프라 성능 차이를 입증했습니다.

높은 처리량(Throughput): 초당 토큰 처리량이 15.7% 증가하여 동일 규모의 인프라에서 더 많은 동시 요청을 소화하거나 하드웨어 투자 비용을 대폭 아낄 수 있습니다.
첫 번째 토큰 생성 시간(TTFT) 단축: 첫 토큰 출력 대기 시간이 무려 92.8% 줄어들어 사용자가 느끼는 체감 반응 시작 속도가 비약적으로 향상됩니다.
낮은 토큰 간 지연 시간(ITL): 62.6% 더 낮아져 첫 토큰이 출력된 이후 실시간 스트리밍이 끊김 없이 매끄럽게 흐릅니다.

Figure 3: 공유 프리픽스 테스트 환경에서 Llama 3.1-8B Instruct LLM을 구동했을 때 GKE 인퍼런스 게이트웨이를 적용한 GKE와 타사 관리형 쿠버네티스 서비스의 평균 지연 시간(출력 토큰당 정규화된 시간) 비교. 동일 사양의 하드웨어 기준. 출처: Principled Technologies

성능 측정 메트릭	GKE	타사 관리형 쿠버네티스 서비스	GKE 적용 효과
평균 출력 토큰 처리량	초당 7,169.21 토큰	초당 6,042.05 토큰	15.7% 처리량 향상
평균 첫 번째 토큰 생성 시간 (TTFT)	188.36 ms	2624.73 ms	92.8% 대기 시간 단축
평균 토큰 간 지연 시간 (ITL)	30.20 ms	81.03 ms	62.6% 지연 감소

Figure 4: 일반 HTTP 로드 밸런싱 방식의 타사 관리형 쿠버네티스 대비 GKE 인퍼런스 게이트웨이를 활성화한 GKE의 AI 추론 효율성 비교.

실무 환경에서 생성형 AI 추론 서비스 가속화하기

실시간 챗봇 상담 에이전트, 실시간 코드 작성 도구, 고성능 금융 사기 방지 필터링 등의 워크로드를 운영할 때 인프라의 응답 속도는 곧 사용자 경험의 만족도를 결정하는 핵심 요인입니다. GKE 인퍼런스 게이트웨이는 공유 프롬프트 프리픽스 캐시의 적중률을 사실상 100%에 가깝게 유지해 줍니다. 이로 인해 반응이 더디고 고비용 구조를 가졌던 기존 LLM 시스템을 고효율, 초저지연의 운영급 시스템으로 즉시 업그레이드시켜 줍니다.

GKE 인퍼런스 게이트웨이가 보유한 성능상의 메리트를 직접 실무 워크로드에 적용해 보세요. 상세 분석 자료가 포함된 벤치마크 보고서 원본은 여기(영문)에서, 시연을 담은 설명 영상은 유튜브에서 확인하실 수 있습니다.

벤치마크 평가를 면밀하게 진행해 주신 Principled Technologies의 시니어 성능 분석 설계자 Dan Sullivan에게 깊은 감사를 드립니다.

컨테이너 및 Kubernetes

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

Agent Compute Engine 심층 분석

Agent Substrate를 사용한 GKE 기반 빌드

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

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

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

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

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

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

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

ZenteiQ의 물리적 AI의 다음 단계

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

1.0에서 제공하는 기능

llm-d 내부 작동 방식

Google Cloud에서 llm-d 1.0 실행

프로덕션 환경에서의 성과

시작하기

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

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

모델 수준 효율성: Reflection의 Beam

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

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

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

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

GKE용 Wiz 런타임 센서 부가기능 출시: Kubernetes를 위한 턴키 방식의 위협 감지 기능

런타임 보안의 운영상 번거로움

GKE용 Wiz 런타임 센서로 보안 공백 해결

작동 방식: 센서 배포 및 적용

Wiz Sensor 부가기능을 사용하여 클러스터 프로비저닝

조직 정책을 통한 Fleet 전체 보호 시행

AI 보안을 위한 지능형 위협 상관관계 분석

지금 시작하기

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

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

실무자 가이드 및 방법

고객 및 파트너 업데이트

연구, 보고서, 심층 분석

2026년 8월

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

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

고객 및 파트너 업데이트

2026년 7월

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

실무자 가이드 및 방법

연구, 보고서, 심층 분석

2026년 6월

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

실무자 가이드 및 방법

연구, 보고서, 심층 분석

고객 및 파트너 업데이트

2026년 5월

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

연구, 보고서, 심층 분석

고객 및 파트너 업데이트

GKE CPU 시작 부스트: 과도한 프로비저닝 없는 앱 시작 가속화

현대화된 애플리케이션 부팅 시 추가 CPU가 필요한 이유

CPU 시작 부스트의 작동 방식

내부 작동 방식: Kubernetes 인플레이스 포드 크기 조절

CPU 시작 부스트 작동 방식(포드 수명 주기 개요)

기본 요건 및 가용성

시작하기: CPU 시작 부스트 구성

예시 1: 고정된 안정 상태를 사용하는 포드 수준 부스트(updateMode: "Off")

예시 2: 시작 부스트와 지속적인 VPA 자동 확장의 결합

예시 3: 세분화된 컨테이너 수준 부스트

클러스터에서 시작 부스트 확인

프로덕션 워크로드 권장사항

지금 시작하기

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

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

적절한 스케줄러 선택

오픈소스로 루프 닫기

동일한 Fleet, 더 적은 불편

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

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

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

인프라 계층

조정 SDK 및 RL 도구 통합

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

절충점

예시 1: 고정된 안정 상태를 사용하는 포드 수준 부스트(`updateMode: "Off"`)