네트워킹

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

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

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

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

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

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

Agent Compute Engine 심층 분석

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

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

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

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

Agent Substrate를 사용한 GKE 기반 빌드

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Google Cloud의 U4 컴퓨팅 소개: 초저지연 트레이딩 지원

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

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

자본 시장에서는 패킷 전송 타이밍의 미세한 차이가 주문 대기열의 우선순위와 거래 체결에 영향을 미치므로 성공적인 운영을 위해서는 예측 가능한 성능과 짧은 지연 시간을 확보해야 합니다. 한편 기존 온프레미스 데이터 센터 환경에서는 거래소와 시장 참여자 모두가 전력 및 물리적 랙 공간의 제약뿐 아니라 하드웨어 조달에 오랜 시간이 걸리는 등 갈수록 심해지는 제약에 직면해 있습니다. 이에 따라 글로벌 자본 시장에서는 물리적 코로케이션의 속도와 결정성을 클라우드의 동적 확장성 및 자동화 기능과 결합하려는 움직임이 늘고 있습니다.

Google Cloud Next '26에서 발표되었던 ULL(Ultra Low Latency) Solution이 이제 정식 버전으로 제공됩니다. 이 솔루션은 클라우드에서 실행되는 고빈도 트레이딩 워크플로에 초저지연 네트워크와 민첩성을 제공합니다. ULL Solution에 새롭게 포함된 U4 머신 계열도 오늘부터 정식 버전으로 제공됩니다.

ULL Solution은 다음과 같은 세 가지 인프라 핵심 요소를 기반으로 합니다.

하드웨어 수준 네트워킹: 안정적인 시장 데이터 피드를 위해 확장 가능한 하드웨어 기반 멀티캐스트 데이터 배포 제공
고급 네트워킹 모니터링 가능성: 하드웨어 수준의 정밀한 타이밍으로 네트워크 트래픽을 동적으로 캡처하여 기본적인 트래픽 성능에 영향을 주지 않고 일관된 감사, 시장 상황 재현, 확실한 거래 검증 지원
결정론적인 고성능 컴퓨팅: 지연 시간에 민감한 트레이딩 실행 계층의 작업을 매번 예측 가능하고 일관된 시간 내에 처리

ULL Solution의 컴퓨팅, 스토리지, 네트워킹, 모니터링 가능성을 종합적으로 활용할 때 금융 거래소와 시장 참여자는 다음과 같은 기술적 역량을 활용할 수 있게 됩니다.

베어메탈 성능: 전용 베어메탈 컴퓨팅을 통해 물리적 호스트 리소스에 직접 액세스할 수 있어 잡음을 최소화하고 시장 데이터 피드와 주문 라우팅에서 예측 가능한 저지연 실행이 가능해집니다.
고성능 스토리지 옵션: 로컬 티타늄 SSD가 호스트에서 실시간 트랜잭션과 틱 로깅을 처리하며, 확장 가능한 Google Cloud Hyperdisk까지 더해져 시장 데이터의 영구 보관과 분석을 지원합니다.
물리적 트래픽 격리: ULL 트레이딩 패브릭의 이중화된 A/B 멀티캐스트 시장 피드는 서로 독립적인 2개의 전용 Titanium 어댑터를 통해 액세스되는 반면, 별도의 세 번째 Titanium 어댑터는 원격 분석과 관리 작업을 오프로드하고 Google Cloud 서비스에 대한 액세스를 제공합니다.
하드웨어 가속 멀티캐스트 배포: ULL 네트워크 아키텍처는 하드웨어 수준에서 멀티캐스트 피드를 수집하는 기능을 지원합니다. 따라서 시장 참여자는 기존 하이퍼바이저 수준의 가상 스위치를 거치지 않고도 처리량이 높은 시장 데이터를 저지연 트레이딩 애플리케이션으로 직접 스트리밍할 수 있습니다.
가속화된 패킷 처리: OpenOnload 및 DPDK를 지원하므로 애플리케이션 코드 변경을 최소화하면서 Linux 사용자 공간 네트워킹을 통해 예측 가능한 유니캐스트 및 멀티캐스트 패킷 처리를 구현할 수 있습니다.
정밀한 타이밍 및 UTC 동기화: Google Cloud의 Firefly 클록 동기화 시스템을 통합하여 네트워크 수준에서 10나노초 미만의 정밀도로 타임스탬프를 일관되게 기록하고 금융 거래소의 규제 요건인 100마이크로초 미만보다 뛰어난 UTC 동기화 정확도를 제공합니다.
기본 제공 원격 분석: 연중무휴로 이루어지는 저지연 패킷 캡처와 원활한 아웃오브밴드 패킷 브로커링을 통해 규정 준수와 실시간 분석을 지원합니다. 이로써 주요 트래픽 성능에 영향을 주지 않으면서 네트워크 상태를 상세하게 파악할 수 있습니다.
연중무휴 시장 지원: 실시간 트레이딩을 위한 프로덕션 워크로드는 전용 기본 영역에 격리하고, 일상적인 클라우드 유지보수와 적격성 테스트는 업데이트 및 테스트를 위한 보조 영역에서 수행하도록 설계되었습니다. 이를 통해 24시간 중단 없는 트레이딩 준비 상태를 유지할 수 있습니다.

ULL Solution의 컴퓨팅은 새로운 U4 머신 계열을 통해 제공되며 이 계열은 예측 가능한 성능과 초저지연 컴퓨팅을 제공하는 세 가지 특화 머신 시리즈로 구성됩니다. U4P와 U4C는 각각 거래소 운영자와 시장 참여자를 위한 듀얼 소켓 베어메탈 인스턴스로, 모두 3개의 물리적 NIC가 장착되어 있습니다. U4S는 운영자, 시장 참여자, 서비스 제공업체를 위한 고성능 VM입니다.

머신 시리즈	CPU 플랫폼	CPU 코어	메모리	NIC	스토리지 옵션
U4P (베어메탈)	Intel 5세대 Xeon(Emerald Rapids)	물리적 코어 120개	512GB 또는 768GB	물리적 NIC 3개(표준 1개 + ULL 2개)	로컬 티타늄 SSD(12TiB), Hyperdisk
U4C (베어메탈)	Intel 5세대 Xeon(Emerald Rapids)	물리적 코어 120개	512GB 또는 768GB	물리적 NIC 3개(표준 1개 + ULL 2개)	로컬 티타늄 SSD(12TiB), Hyperdisk
U4S (VM)	Intel 6세대 Xeon(Granite Rapids)	vCPU 2~288개	최대 2,232GB	멀티 vNIC(최대 200Gbps)	로컬 티타늄 SSD(18TiB), Hyperdisk

Google Cloud는 전 세계에서 기술적 요구사항이 가장 까다로운 금융 시장에서도 클라우드 서비스와 확장성의 이점을 활용하며 운영할 수 있도록 U4 머신 계열을 개발했습니다. 대표적인 사례로 CME Group과의 지속적인 협업을 통해 상장된 파생상품 시장을 Google Cloud로 이전하고 있습니다. 여기서 U4C 및 U4P 베어메탈 인스턴스는 물리적 코로케이션과 동등한 수준의 지연 시간을 보장하며, 예측 가능한 저지연 클록 정밀도와 하드웨어 기반 멀티캐스트 피드의 네이티브 수집 기능을 제공합니다. 이 아키텍처는 금융 시장에서 요구하는 속도, 일관성, 제어 수준을 유지하면서 핵심 거래소 시스템과 트레이딩 전략을 클라우드에서 실행할 수 있음을 보여줍니다.

"세계 최고의 파생상품 시장을 클라우드로 이전하려면 성능, 지연 시간, 안정성 측면에서 결코 타협이 용납되지 않습니다. Google Cloud의 Ultra Low Latency Solution과 U4 인스턴스 계열은 금융 시장 인프라의 획기적인 발전을 의미합니다. 결정론적인 초저지연 네트워킹 및 전용 베어메탈 컴퓨팅에 클라우드의 이점을 결합함으로써 시장 참여자는 기존 코로케이션 환경의 속도와 클라우드의 민첩성을 동시에 활용하여 시장 데이터를 수집하고 거래를 체결할 수 있습니다." - Pearce Peck-Walden, CME Group의 시장 엔지니어링 부문 상무이사

Google Cloud 네이티브 인프라 기반

ULL Solution은 일부 비공개 Google Cloud 리전에서 제공되며, 트레이딩팀은 이러한 환경에서 신속한 자동 리소스 프로비저닝, 주문형 용량 확장, 동적 Fleet 관리와 같은 핵심 클라우드 인프라의 이점을 활용할 수 있습니다. 또한 격리된 전용 ULL 네트워크에서 초저지연 거래를 실행하고, 독립적인 네트워크 인터페이스를 통해 데이터 스트림을 BigQuery, Gemini Enterprise와 같은 Google Cloud 서비스로 오프로드할 수 있습니다.

틱 투 트레이드(tick-to-trade) 워크플로를 관리하거나 실시간 시장 데이터를 처리하는 거래소 참여자에게는 마이크로초 단위의 차이도 매우 중요합니다. U4P 및 U4C 머신 시리즈는 베어메탈 인스턴스이므로 지연 시간에 민감한 실행 계층에 가상화 오버헤드가 추가되지 않습니다. 이러한 베어메탈 인스턴스는 Google Cloud의 Titanium 오프로드 시스템 아키텍처를 활용하여 호스트 리소스에 직접 액세스할 수 있도록 합니다. 사용자는 Compute Engine 인스턴스를 통해 표준 Google Cloud API로 전용 하드웨어를 프로비저닝하고, 코드형 인프라를 사용하여 배포를 조정하고, Cloud Next Generation Firewall(NGFW) 정책을 적용하고, 다양한 원격 분석 데이터를 수집할 수 있습니다.

U4S VM 시리즈는 거래 전 위험 검증, 실시간 분석과 같은 용도로 활용되어 이러한 베어메탈 제품군을 보완합니다. U4P 및 U4C 인스턴스와 함께 이러한 VM을 배포하면 트레이딩 아키텍처 전반에서 데이터가 거치는 네트워크 홉 수를 줄이는 동시에 vCPU를 2개에서 288개까지 탄력적으로 확장하고 최대 100Gbps의 네트워킹을 지원할 수 있습니다.

“U4 인스턴스를 테스트한 결과 Google Cloud가 까다로운 거래소 트레이딩 워크로드에 필요한 짧은 지연 시간과 결정성을 제공한다는 사실을 확인했습니다. 베어메탈과 VM 옵션을 모두 사용하면 가성비를 평가할 수 있어 각 트레이딩 전략에 적합한 인프라를 선택할 수 있습니다.” - Corbin Kidd, Prime Trading의 EVP/CTO

"틱 투 트레이드 성능 테스트에서 U4C 베어메탈 인스턴스는 뛰어난 속도를 보여주었으며, 클라우드 컴퓨팅과 초저지연 네트워킹이 마이크로초 단위의 트레이딩 요구사항을 충분히 충족할 수 있음을 입증했습니다. 하지만 U4 시리즈를 차별화하는 요소는 단순한 처리 속도가 아니라 구조적 결정성입니다. Google Cloud의 U4 베어메탈 제품군에 대한 스트레스 테스트를 실시했을 때 성능 곡선이 거의 평탄하게 유지되었으며, 이는 이러한 클라우드 컴퓨팅 레이아웃이 이제 기관 시장 참여자가 요구하는 엄격한 결정성을 제공할 수 있음을 보여줍니다." - Christopher Wilson, 28Stone의 경험 현대화 부문 글로벌 책임자

향후 이러한 초저지연 아키텍처는 알고리즘 트레이딩의 기반이 되어 기업이 AI 기반 트레이딩 모델에 실시간 시장 데이터를 직접 공급할 수 있도록 지원할 것입니다.

트레이딩 워크로드를 위한 스토리지 및 배치

U4 제품군은 Google Cloud 스토리지 옵션과 배치 정책을 지원하여 트레이딩팀이 거래 내역을 빠르게 기록하고 머신 간 네트워크 지연 시간을 최소화할 수 있도록 돕습니다.

빠른 로깅을 위한 로컬 티타늄 SSD: 실행 속도 저하 없이 실시간 거래 로깅과 데이터 캐싱을 지원하도록 U4P와 U4C는 최대 12TiB의 직접 연결된 NVMe SSD를 제공하며, U4S VM은 최대 18TiB까지 수직 확장할 수 있습니다.
데이터 보관을 위한 Hyperdisk: 과거 시장 데이터, 백테스팅 모델, 규제 제출용 보관 파일을 처리할 수 있도록 모든 U4 시리즈에 Hyperdisk Balanced 및 Hyperdisk Extreme 볼륨을 연결하여 인스턴스당 최대 32개의 볼륨과 512TiB까지 확장할 수 있습니다.
배치 정책: 압축 배치 정책은 물리적 네트워크 홉을 줄이기 위해 데이터 센터에서 관련 머신을 서로 가깝게 배치합니다. 또는 분산 배치 정책은 복원력을 개선하기 위해 별도의 랙에 머신을 배치합니다.

ULL Solution 시작하기

금융 거래소 운영자, 거래소 참여자, 트레이딩 서비스 제공업체는 ULL Solution을 통해 오늘날 요구되는 속도와 안정성을 확보하는 동시에 지속적으로 발전하는 AI 및 인프라 기능을 활용해 미래의 트레이딩 환경에 대비할 수 있습니다. ULL Solution은 일부 Google Cloud 리전에서 지원됩니다. 자세한 내용은 공개 문서를 확인하고 Google팀에 연락하여 액세스를 요청하세요.

AI 추론 모델 서빙을 위한 네트워킹 - GKE 전용 및 기타 모든 백엔드

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

많은 기업과 개별 개발자는 여러 AI 추론 모델을 실행합니다. 적절한 아키텍처를 구축하면 모델 호출 방식을 간소화하면서도 중앙 집중식 거버넌스를 제공할 수 있습니다. 이 게시물에서는 AI 추론 모델 서빙 네트워킹에 중점을 둔 두 가지 참조 아키텍처를 살펴봅니다. 하나는 Google Kubernetes Engine(GKE)용이고, 다른 하나는 그 외의 모든 백엔드 유형용입니다. 나중에 살펴볼 참조 아키텍처 간의 공통점을 먼저 살펴보겠습니다. 그런 다음 GKE 백엔드 아키텍처의 고유한 구성요소를 살펴보고, 마지막에는 모든 백엔드 유형의 아키텍처 요소를 살펴봅니다.

진입점

추론 호출을 위한 프런트엔드 역할을 하는 안정적이고 안전하며 신뢰할 수 있는 진입점을 통해모델 배포를 노출할 수 있습니다. 이 진입점은 정책, 보안, 로직을 적용할 수 있는 제어 영역 역할도 합니다. Cloud Load Balancer와 추론 게이트웨이 모두 진입점 기능을 제공합니다. 이러한 유형의 엔드포인트를 사용하면 TLS를 통해 보안 연결을 종료하고, API 관리 구성요소와 통합하며, 서비스 확장 프로그램을 통해 기능을 확장하고, Model Armor의 기능을 이용해 보안을 강화할 수 있습니다.

설계에 포함되는 일반적인 서비스

두 참조 설계 모두 다음 서비스를 사용합니다.

Private Service Connect 추론 엔드포인트: 소비자 Virtual Private Cloud(VPC) 네트워크 내에 진입점을 고정합니다. 트래픽이 비공개 내부 IP 주소로 전송되기 때문에 추론 호출이 비공개 네트워크를 벗어나지 않습니다.
Apigee API 관리(선택사항): Apigee 확장 프로그램 프로세서 콜아웃을 통해 통합되어, 요청이 컴퓨팅 리소스에 도달하기 전에 클라이언트 본인 인증, 비율 제한과 할당량 적용을 처리합니다.
Model Armor: 인라인 AI 안전 체크포인트 역할을 하여, 프롬프트와 완료된 출력을 검사해 프롬프트 인젝션 및 민감한 정보 유출 여부를 확인합니다.

GKE에서만 서빙되는 설계 패턴

이 섹션에서는 GKE 전용 백엔드 설계를 중점적으로 다룹니다. 전체 엔드 투 엔드 개념을 이해하려면 아키텍처 문서인 GKE에서의 AI 추론 모델 서빙을 위한 네트워킹 전문을 읽어보세요. 설계 패턴은 다음 다이어그램을 기반으로 합니다.

GKE 설계에서는 이전 섹션에서 확인한 공통 서비스 외에 다음 구성요소도 사용합니다.

GKE Inference Gateway: 내부 애플리케이션 부하 분산기(gke-l7-rilb)로 배포됩니다. 이 기능은 수신 요청 페이로드를 파싱하고, HTTPRoute 규칙을 평가하며, 쿼리를 적절한 모델 서빙 대상으로 유도하는 특수한 인그레스 엔진 역할을 합니다.
추론 풀: 동일한 모델의 복제본을 포함하는 논리적 그룹입니다. 게이트웨이가 프롬프트를 수신하면 HTTPRoute 규칙을 평가하여 모델 식별자를 기반으로 적절한 추론 풀을 선택합니다. 풀에는 초기 크기가 있으며, 동적으로 자동 확장되도록 구성할 수 있습니다.
모델 복제본 세트: 단일 노드 또는 다중 노드 GPU나 TPU 노드 풀에 배포된 개별 모델 복제본(추론 서버 인스턴스)입니다. 복제본 세트는 이러한 모델 복제본의 균일한 그룹을 나타냅니다.

트래픽 흐름 GKE 예시

이 GKE 기반 아키텍처를 사용하여 백엔드 모델을 호출하는 클라이언트 애플리케이션은 다음과 같은 흐름을 따르게 됩니다.

인그레스: 소비자 VPC의 클라이언트 애플리케이션이 로컬 Private Service Connect 엔드포인트에 OpenAI 호환 API 호출을 실행하여, 리전 내부 애플리케이션 부하 분산기를 통해 GKE Inference Gateway로 직접 라우팅합니다.
페이로드 검사: 게이트웨이가 요청 본문에 지정된 대상 모델 파라미터를 읽고 이를 HTTP 헤더에 추가합니다.
컨트롤 플레인 검증: Apigee를 사용하는 경우 이 기능이 클라이언트 사용자 인증 정보와 할당량을 확인합니다. Model Armor는 프롬프트에서 정책 위반 또는 데이터 유출 여부를 검사합니다.
백엔드 선택: 게이트웨이는 HTTPRoute 매핑을 평가하여 대상 풀을 식별하고, 공유 접두사 캐시 컨텍스트를 일치시키고, 실시간 Prometheus 데이터를 기반으로 부하가 가장 낮은 GPU 또는 TPU 복제본으로 라우팅합니다.
이그레스: 복제본이 추론 워크로드를 실행합니다. 출력 토큰은 Model Armor를 통과하여 최종 응답 검증을 거친 후 비공개 연결을 통해 다시 스트리밍됩니다.

모든 백엔드에서 서빙되는 설계 패턴

이 섹션에서는 추론에 사용할 수 있는 여러 백엔드 유형을 중점적으로 다루며, 다음 다이어그램을 통해 아키텍처 개요를 제공합니다. 전체 엔드 투 엔드 개념을 이해하려면 아키텍처 문서인 모든 백엔드에서의 AI 추론 모델 서빙을 위한 네트워킹 전문을 읽어보세요.

GKE, Cloud Run, Agent Platform, 온프레미스 데이터 센터 또는 외부 클라우드 같은 혼합 환경에 걸쳐 있는 아키텍처에는 다음과 같은 추가 구성요소가 사용됩니다.

리전 내부 애플리케이션 부하 분산기: 라우팅 로직, SSL 종료, Service Extensions 콜아웃을 관리하는 중앙 레이어 7 라우팅 프록시 역할을 합니다.
추론 페이로드 프로세서(Service Extensions): GKE Inference Gateway에서 사용하는 본문 기반 라우팅과 유사하지만, 애플리케이션 부하 분산기에서 이 기능을 사용 설정하려면 서비스 확장 프로그램이 필요합니다. 가벼운 Cloud Run 콜아웃이 수신되는 OpenAI API 요청의 JSON 본문을 검사하고, 대상 모델 식별자를 추출하고, X-Gateway-Model-Name 헤더를 작성하여 URL 맵 라우팅을 수행합니다.
네트워크 엔드포인트 그룹(NEG): 삽입된 모델 헤더를 기반으로 이기종 백엔드에 대한 유연한 라우팅을 제공합니다.

모든 백엔드 트래픽 흐름 예시

이 아키텍처를 사용하여 백엔드 모델을 호출하는 클라이언트 애플리케이션은 다음과 같은 흐름을 따르게 됩니다.

비공개 인그레스: 클라이언트 애플리케이션은 비공개 IP 주소 공간을 통해 Private Service Connect 엔드포인트를 타겟팅합니다. 리전 내부 애플리케이션 부하 분산기가 요청을 수신합니다.
모델 이름 추출: 부하 분산기가 페이로드를 Cloud Run 본문 기반 라우터 콜아웃으로 전송하면 콜아웃이 JSON 페이로드를 검사하고 X-Gateway-Model-Name 헤더를 삽입합니다.
정책 및 안전 시행: 요청이 Apigee로 전달되어 신원 및 할당량 검증을 거친 후, Model Armor로 전달되어 민감한 정보를 삭제하고 악성 프롬프트를 차단합니다.
NEG 라우팅: 부하 분산기 URL 맵이 모델 헤더를 검사한 후 일치하는 백엔드 NEG(Agent Platform, GKE, Cloud Run, 하이브리드 또는 인터넷)로 요청을 전달합니다.
비공개 전송: 대상 백엔드가 모델 프롬프트를 실행하면 Model Armor가 완성된 결과물을 검사하고, 검사 결과가 인그레스 경로를 통해 비공개로 반환됩니다.

다음 단계

Google Cloud에서 AI 워크로드를 빌드하는 방법을 자세히 알아보세요.

문서 세트: 에이전트 AI 아키텍처 가이드
아키텍처 센터: Google Cloud의 멀티 에이전트 비공개 네트워킹 패턴
문서: Gemini Enterprise Agent Platform 네트워킹 액세스 개요

질문이 있거나, 자세한 내용이 궁금하거나, 의견을 공유하고 싶으신가요? Linkedin을 통해 Google Cloud에 문의하세요.

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

Google Cloud 네트워킹이 AI 워크로드를 위한 유연한 컴퓨팅 선택을 지원하는 방법

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

AI 워크로드에 필요한 리소스, 특히 가속기의 가용성을 확보하는 것은 업계 전반에서 어려운 과제입니다. 특정 유형의 가속기를 기반으로 AI 워크로드를 빌드할 경우, 배포가 지연될 수 있습니다. 유동적인 컴퓨팅이라는 개념을 활용하면 사용 사례에 작힙힌 가용 리소스를 기반으로 다양한 옵션을 고려하여 AI 배포를 설계할 수 있습니다.

이 블로그에서는 Google Cloud 네트워킹이 AI 워크로드를 지원하는 방식을 살펴보고, 가속기(GPU 또는 TPU) 선택 시 고려해야 할 사항을 알아봅니다. 가속기 유형에 따라 백엔드 네트워킹 구성요소의 설정이 달라지기 때문입니다.

리소스 옵션

AI 배포를 통해 수행하려는 작업 유형을 결정하면 이제 다음으로 중요한 요소는 해당 작업을 수행할 때ㅐ 필요한 실제 하드웨어입니다. 이 경우 비공개 LLM에 대한 추론을 실행하려고 하며, 대상은 A4 VM(a4-highgpu-8g)에서 사용할 수 있는 NVIDIA B200 GPU 제품군입니다.

이제 수행하려는 작업과 가능한 컴퓨팅 옵션을 파악했습니다. 하지만 이 옵션을 사용할 수 있을까요?

리소스를 확보하는 방법은 다음과 같은 몇 가지 옵션이 있습니다.

동적 워크로드 스케줄러(Flex-start VM): 필요한 모든 가속기 노드를 동시에 사용할 수 있을 때까지 워크로드를 큐에 추가하고, 일괄적으로 프로비저닝하며, 최대 7일 동안 선점되지 않도록 실행합니다.
동적 워크로드 스케줄러(캘린더 모드): 1~90일 전에 가속기 용량을 예약할 수 있으며, 시작 및 종료 시간이 보장되므로 예약된 사전 학습 실행 및 벤치마킹에 적합합니다.
미래용 예약: 특정 미래 날짜부터 지정된 영역에서 약정된 하드웨어에 대한 액세스를 보장합니다.
Flex 예약: 다년간의 약정 없이도 부족한 가속기 노드를 확보할 수 있도록 단기 약정 기간을 제공합니다.
동적 노드 자동 프로비저닝 및 ComputeClasses: Google Kubernetes Engine(GKE)에서 ComputeClasses 내에 여러 제품군을 대체 목록으로 정의하면 기본 풀에 리전 제약이 발생할 경우 클러스터가 대체 가속기 유형을 자동으로 프로비저닝하도록 시도할 수 있습니다.
스팟 VM: 내결함성을 갖추고 체크포인트가 있는 일괄 작업에 대해 잔여 컴퓨팅 용량을 크게 할인된 가격으로 제공합니다.

자세한 내용은 블로그 게시물 Never Run Out of Compute: A Practical Guide to GKE Resource Obtainability(안정적인 컴퓨팅 리소스 확보: GKE 리소스 확보 가능성을 안정적으로 높이기 위한 실무 가이드)에서 확인하세요.

네트워킹 구성 선택하기

가속기의 네트워킹 구성요소는 선택하는 가속기 유형에 따라 달라집니다. 이 문서에서는 표준 네트워킹, 가속 GPU 네트워킹(TCPX/TCPXO 및 RoCEv2), TPU 네트워킹, Cloud Run의 네 가지 구성을 살펴보겠습니다.

표준 네트워킹

지원되는 가속기: NVIDIA T4(N1 시리즈), NVIDIA L4(G2 시리즈), NVIDIA A100(A2 머신 시리즈 단일 노드 및 멀티 노드), Cloud TPU v3, Cloud TPU v5e(단일 호스트/독립형 슬라이스)
아키텍처: 노드는 표준 TCP/IP 기반의 Google 가상 NIC(gVNIC)를 사용하여 기본 Virtual Private Cloud(VPC) 네트워크를 통해 통신합니다.
워크로드 적합성: Google Cloud 컴퓨팅 환경 전반에서 간단한 이식성을 제공하여 분산 데이터 전처리, 분리된 파이프라인 단계, 독립적인 추론 복제본, 표준 VPC 라우팅 및 네트워크 정책을 사용하는 컴퓨터 비전 워크로드를 지원합니다.

가속 GPU 네트워킹(TCPX/TCPXO 및 RoCEv2)

분산 학습과 멀티 노드 추론에는 대규모 파라미터 교환과 집합 통신을 처리하기 위해 특화된 멀티 레일 네트워크 패브릭이 필요합니다.

GPUDirect-TCPX 및 TCPXO 패브릭

지원되는 가속기: NVIDIA H100(A3 High VM, 레일 4개) 및 NVIDIA H100 Mega(A3 Mega VM, 레일 8개).
아키텍처: 커스텀 GPUDirect-TCPX(전용 VPC 4개) 및 GPUDirect-TCPXO(전용 VPC 8개) 오프로드 엔진을 사용하여 기본 RDMA 하드웨어 없이도 표준 이더넷 인프라에서 높은 처리량의 멀티 레일 GPU 통신을 구현합니다.
배포 청사진: 이러한 멀티 VPC 토폴로지는 Cluster Toolkit의 사전 빌드된 청사진을 사용하는 등 다양한 방법으로 배포할 수 있습니다.

RoCEv2 패브릭(VM 및 베어메탈)

지원되는 가속기: NVIDIA H200(A3 Ultra VM), NVIDIA B200(A4 VM), NVIDIA GB200 NVL72(A4X VM), NVIDIA GB300(A4X Max 베어메탈).
영역 네트워크 프로필: RoCEv2는 특수한 영역 네트워크 프로필에 연결된 전용 RDMA VPC를 통해 작동합니다. VM 인스턴스(A3 Ultra, A4, A4X)는 ZONE-vpc-roce 프로필을 사용하고, 베어메탈 인스턴스(예: A4X Max)는 전용 ZONE-vpc-roce-metal 베어메탈 프로필을 사용합니다.
레일 정렬 패브릭: 이 전용 VPC는 GPU 통신을 위해 엄격하게 격리되어 있으며 가속기 NIC에 직접 매핑된 서브넷을 포함합니다. 백엔드 네트워크는 레일별로 정렬되어 있고 점보 프레임(MTU 8896)을 지원하며, 레일간 간섭을 최소화하면서 가족에게 피해 입히지 않도록 비차단 멀티 테라비트 대역폭을 제공합니다.
GKE를 통한 자동화된 네트워크 구성 영지 동적 리소스 할당 네트워크(DRANET): GKE에 이러한 GPU를 배포할 때 GKE 관리형 DRANET을 사용하여 추가 네트워크를 자동으로 프로비저닝하고 RDMA 네트워크 인터페이스를 GPU에 매핑하는 드라이버를 할당할 수 있습니다. 그런 다음 표준 Kubernetes 리소스 클레임을 사용하여 워크로드 포드에서 직접 할당하고 사용할 수 있습니다.
턴키 배포: Cluster Toolkit의 자동화된 청사진을 사용하여 RDMA VPC, MTU 조정, tooling 포함한 전체 엔드 투 엔드 스택을 배포할 수 있습니다.

TPU 네트워킹

지원되는 가속기: Cloud TPU v4, Cloud TPU v5p, Cloud TPU v5e(멀티 호스트 포드 슬라이스), Cloud TPU v6ee(Trillium), 튜토리얼: TPU7x(Ironwood)
칩 간 상호 연결(ICI): TPU Pod 또는 슬라이스 내부에서 칩은 2D 또는 3D 토러스 메시로 구성된 전용 초저지연 광학 링크를 통해 직접 통신하며 기존 네트워크 스택을 완전히 우회합니다.
광학 회로 스위치(OCS): TPU v4 및 TPU v5p SuperPod에서 소프트웨어로 재구성할 수 있는 OCS 장치를 사용합니다. 물리적 네트워크 토폴로지를 동적으로 변경하고, 결함이 있는 트레이를 우회하며, 케이블을 수동으로 다시 연결하지 않고도 원하는 크기의 가속기 슬라이스를 구성할 수 있도록 합니다.
멀티 NIC 아키텍처(TPU v6e 이상): 이전 TPU 세대가 슬라이스 내부 통신에는 ICI를 사용하고 호스트 트래픽에는 단일 NIC에 의존했던 것과는 달리, Cloud TPU v6e(Trillium) 및 TPU7x는 기본 네이티브 NIC 아키텍처를 도입했습니다. 작업자 노드는 표준 Kubernetes 관리 트래픽을 기본 VPC로 격리하는 동시에 높은 처리량의 TPU 데이터 및 교차 슬라이스 통신을 위해 구성된 별도의 VPC를 사용합니다.
TPUDRANET 배포: GKE에 이러한 TPU를 배포할 때 GKE 관리형 DRANET을 사용하여 추가 네트워크를 자동으로 프로비저닝하고 TPU 통신을 위한 드라이버를 할당할 수 있습니다. 그런 다음 표준 Kubernetes 리소스 클레임을 사용하여 워크로드 포드에서 직접 할당하고 사용할 수 있습니다.
데이터 센터 네트워크(DCN) 멀티슬라이스: 개별 TPU 슬라이스를 넘어 확장헤야 하는 모델의 경우, Cloud TPU 멀티슬라이스가 이러한 전용 멀티 NIC 경로를 활용하여 Google의 고속 Jupiter 데이터 센터 네트워크를 통해 여러 개의 독립적인 ICI 메시를 연결합니다.

Cloud Run

지원되는 가속기: Cloud Run GPU 서비스의 NVIDIA L4(G2 시리즈) 및 NVIDIA RTX PRO 6000(Blackwell)
VPC 직접 연결 이그레스: VPC 직접 연결 이그레스를 통해 1분 이내에 IP를 할당하여 서버리스 컨테이너를 비공개 VPC 네트워크에 직접 바인딩합니다. 이를 통해 공개 인터넷을 거치거나 기존 커넥터 VM을 사용하지 않고도 내부 데이터 레이크, 데이터베이스, 비공개 API에 안전하고 지연 시간이 짧은 액세스를 제공합니다.

요약

Google Cloud 네트워킹 옵션은 다양한 가속기 유형을 지원합니다. 유연한 컴퓨팅을 활용하면 워크로드 성능을 최적화하는 최상의 설계에 맞춰 네트워크 구성을 조정할 수 있습니다.

다음 단계

다음 리소스를 통해 Google Cloud AI 인프라 및 네트워킹 아키텍처를 자세히 살펴보세요.

질문이 있거나, 자세한 내용이 궁금하거나, 의견을 공유하고 싶으신가요? LinkedIn을 통해 저에게 알려주세요.

GPU 실험: GKE 관리형 DRANET 및 Inference Gateway AI 배포

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

인프라에서 모델을 빌드하고 서빙하는 것은 비즈니스에 강력한 사용 사례입니다. Google Cloud에서는 워크로드에 맞게 AI 인프라를 설계할 수 있습니다. 최근에 GKE에서 NVIDIA B200 GPU를 사용하여 추론을 위한 모델을 배포하는 동안 Google Kubernetes Engine (GKE) 관리형 DRANET를 실험해 보았습니다. 이 블로그에서는 따라하기 쉬운 단계로 이 설정을 살펴보겠습니다.

DRANET이란 무엇인가요?

동적 리소스 할당 (DRA)은 포드 간에 리소스를 요청하고 공유할 수 있는 기능입니다. DRANET을 사용하면 TPU 및 원격 직접 메모리 액세스 (RDMA)를 지원하는 네트워크 인터페이스를 포함하여 포드의 네트워킹 리소스를 요청하고 할당할 수 있습니다. 저의 경우 고급 GPU를 사용합니다.

GPU RDMA VPC 작동 방식

RDMA 네트워크는 리전별로 격리된 VPC로 설정되며 네트워크 프로필 유형이 할당됩니다. 이 경우 네트워크 프로필 유형은 RoCEv2입니다. 이 VPC는 GPU 간 통신 전용입니다. GPU VM 제품군에는 RDMA VPC에 연결되는 RDMA 지원 NIC가 있습니다. GPU는 이 저지연 고속 레일 정렬 설정을 통해 여러 노드 간에 통신합니다.

설계 패턴 예시

목표는 8개의 B200 GPU를 지원하는 A4 노드가 있는 GKE 클러스터에 LLM 모델 (Deepseek)을 배포하고 GKE 추론 게이트웨이를 통해 비공개로 서빙하는 것이었습니다. AI Hypercomputer GKE 클러스터를 설정하려면 클러스터 툴킷을 사용할 수 있지만, 저는 GPU 통신을 위한 RDMA를 지원하는 네트워킹의 GKE 관리 DRANET 동적 설정을 테스트하고 싶었습니다.

이 설계는 엔드 투 엔드 솔루션을 제공하기 위해 다음 서비스를 활용합니다.

VPC: 총 3개의 VPC 수동으로 생성된 VPC 1개, GKE 관리 DRANET에서 자동으로 생성된 VPC 2개(표준 1개, RDMA용 1개)
GKE: 워크로드를 배포합니다.
GKE 추론 게이트웨이: 리전 내부 애플리케이션 부하 분산기 유형 gke-l7-rilb를 사용하여 워크로드를 내부적으로 노출합니다.
A4 VM: NVIDIA B200 GPU를 통해 RoCEv2를 지원합니다.

종합

A4 VM에 액세스하기 위해 미래용 예약이 사용되었습니다. 이는 특정 영역에 연결됩니다.

시작: 환경 설정

예약과 동일한 영역에 방화벽 규칙과 서브넷이 있는 표준 VPC를 만듭니다.
GKE 추론 게이트웨이에 연결된 내부 리전 애플리케이션 부하 분산기에 사용될 프록시 전용 서브넷을 만듭니다.

다음: 표준 GKE 클러스터 노드 및 기본 노드 풀 만들기

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create $CLUSTER_NAME \\\r\n --location=$ZONE \\\r\n --num-nodes=1 \\\r\n --machine-type=e2-standard-16 \\\r\n --network=${GVNIC_NETWORK_PREFIX}-main \\\r\n --subnetwork=${GVNIC_NETWORK_PREFIX}-sub \\\r\n --release-channel rapid \\\r\n --enable-dataplane-v2 \\\r\n --enable-ip-alias \\\r\n --addons=HttpLoadBalancing,RayOperator \\\r\n --gateway-api=standard \\\r\n --enable-ray-cluster-logging \\\r\n --enable-ray-cluster-monitoring \\\r\n --enable-managed-prometheus \\\r\n --enable-dataplane-v2-metrics \\\r\n --monitoring=SYSTEM'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663b5307d0>)])]>

완료되면 클러스터에 연결할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE --project $PROJECT'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6639c5ca50>)])]>

GPU 노드 풀을 만듭니다 (이 예에서는 예약이 포함된 A4 VM을 사용함). 추가 플래그:

---accelerator-network-profile=auto (GKE가 노드에 gke.networks.io/accelerator-network-profile: auto 라벨을 자동으로 추가함)

--node-labels=cloud.google.com/gke-networking-dra-driver=true (고성능 네트워킹을 위한 DRA 사용 설정)

code_block: <ListValue: [StructValue([('code', 'gcloud beta container node-pools create $NODE_POOL_NAME \\\r\n --cluster $CLUSTER_NAME \\\r\n --location $ZONE \\\r\n --node-locations $ZONE \\\r\n --machine-type a4-highgpu-8g \\\r\n --accelerator type=nvidia-b200,count=8,gpu-driver-version=latest \\\r\n --enable-autoscaling --num-nodes=1 --total-min-nodes=1 --total-max-nodes=3 \\\r\n --reservation-affinity=specific \\\r\n--reservation=projects/$PROJECT/reservations/$RESERVATION_NAME/reservationBlocks/$BLOCK_NAME \\\r\n --accelerator-network-profile=auto \\\r\n--node-labels=cloud.google.com/gke-networking-dra-driver=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6639c5cc90>)])]>

다음 단계: 네트워킹 리소스를 배포에 연결하는 데 사용될 ResourceClaimTemplate을 만듭니다. deviceClassName: mrdma.google.com 은 GPU 워크로드에 사용됩니다.

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-mrdma\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-mrdma\r\n exactly:\r\n deviceClassName: mrdma.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6639c5e990>)])]>

모델 및 추론 배포

이제 클러스터와 노드 풀이 설정되었으므로 모델을 배포하고 추론 게이트웨이를 통해 제공할 수 있습니다. 실험에서는 DeepSeek를 사용했지만 어떤 모델이든 사용할 수 있습니다.

모델 및 서비스 배포

nodeSelector: gke.networks.io/accelerator-network-profile: auto는 GPU 노드에 할당하는 데 사용됩니다.
resourceClaims: 네트워킹을 위해 정의한 리소스를 연결합니다.

보안 비밀 만들기 (Hugging Face 토큰 사용):

code_block: <ListValue: [StructValue([('code', 'kubectl create secret generic hf-secret \\\r\n --from-literal=hf_token=${HF_TOKEN}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6638cd93d0>)])]>

Deployment

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: deepseek-v3-1-deploy\r\nspec:\r\n replicas: 1\r\n selector:\r\n matchLabels:\r\n app: deepseek-v3-1\r\n template:\r\n metadata:\r\n labels:\r\n app: deepseek-v3-1\r\n ai.gke.io/model: deepseek-v3-1\r\n ai.gke.io/inference-server: vllm\r\n examples.ai.gke.io/source: user-guide\r\n spec:\r\n containers:\r\n - name: vllm-inference\r\n image: us-docker.pkg.dev/vertex-ai/vertex-vision-model-garden-dockers/pytorch-vllm-serve:20250819_0916_RC01\r\n resources:\r\n requests:\r\n cpu: "190"\r\n memory: "1800Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n limits:\r\n cpu: "190"\r\n memory: "1800Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n claims:\r\n - name: rdma-claim\r\n command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]\r\n args:\r\n - --model=$(MODEL_ID)\r\n - --tensor-parallel-size=8\r\n - --host=0.0.0.0\r\n - --port=8000\r\n - --max-model-len=32768\r\n - --max-num-seqs=32\r\n - --gpu-memory-utilization=0.90\r\n - --enable-chunked-prefill\r\n - --enforce-eager\r\n - --trust-remote-code\r\n env:\r\n - name: MODEL_ID\r\n value: deepseek-ai/DeepSeek-V3.1\r\n - name: HUGGING_FACE_HUB_TOKEN\r\n valueFrom:\r\n secretKeyRef:\r\n name: hf-secret\r\n key: hf_token\r\n volumeMounts:\r\n - mountPath: /dev/shm\r\n name: dshm\r\n livenessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n initialDelaySeconds: 1800\r\n periodSeconds: 10\r\n readinessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n initialDelaySeconds: 1800\r\n periodSeconds: 5\r\n volumes:\r\n - name: dshm\r\n emptyDir:\r\n medium: Memory\r\n nodeSelector:\r\n gke.networks.io/accelerator-network-profile: auto\r\n resourceClaims:\r\n - name: rdma-claim\r\n resourceClaimTemplateName: all-mrdma\r\n---\r\napiVersion: v1\r\nkind: Service\r\nmetadata:\r\n name: deepseek-v3-1-service\r\nspec:\r\n selector:\r\n app: deepseek-v3-1\r\n type: ClusterIP\r\n ports:\r\n - protocol: TCP\r\n port: 8000\r\n targetPort: 8000\r\n---\r\napiVersion: monitoring.googleapis.com/v1\r\nkind: PodMonitoring\r\nmetadata:\r\n name: deepseek-v3-1-monitoring\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: deepseek-v3-1\r\n endpoints:\r\n - port: 8000\r\n path: /metrics\r\n interval: 30s'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a3f4790>)])]>

GKE Inference Gateway 배포

GKE 클러스터에 필요한 커스텀 리소스 정의 (CRD)를 설치합니다.

GKE 버전 1.34.0-gke.1626000 이상인 경우 알파 InferenceObjective CRD만 설치합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.0.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a3f7410>)])]>

추론 풀 만들기

code_block: <ListValue: [StructValue([('code', 'helm install deepseek-v3-pool \\\r\n oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool \\\r\n --version v1.0.1 \\\r\n --set inferencePool.modelServers.matchLabels.app=deepseek-v3-1 \\\r\n --set provider.name=gke \\\r\n --set inferenceExtension.monitoring.gke.enabled=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a3f6e90>)])]>

게이트웨이, HTTPRoute, InferenceObjective 만들기

code_block: <ListValue: [StructValue([('code', '# 1. The Regional Internal Gateway (ILB)\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: Gateway\r\nmetadata:\r\n name: deepseek-v3-gateway\r\n namespace: default\r\nspec:\r\n gatewayClassName: gke-l7-rilb\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n allowedRoutes:\r\n namespaces:\r\n from: Same\r\n---\r\n# 2. The HTTPRoute (Routing to the Pool)\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: deepseek-v3-route\r\n namespace: default\r\nspec:\r\n parentRefs:\r\n - name: deepseek-v3-gateway\r\n rules:\r\n - matches:\r\n - path:\r\n type: PathPrefix\r\n value: /\r\n backendRefs:\r\n - group: inference.networking.k8s.io\r\n kind: InferencePool\r\n name: deepseek-v3-pool\r\n---\r\n# 3. The Inference Objective (Performance Logic)\r\napiVersion: inference.networking.x-k8s.io/v1alpha2\r\nkind: InferenceObjective\r\nmetadata:\r\n name: deepseek-v3-objective\r\n namespace: default\r\nspec:\r\n poolRef:\r\n name: deepseek-v3-pool'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a3f52d0>)])]>

완료되면 기본 VPC에서 테스트 VM을 만들고 GKE Inference Gateway의 IP 주소에 대한 호출을 수행할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'curl -N -s -X POST "http://$GATEWAY_IP/v1/chat/completions" \\\r\n -H "Content-Type: application/json" \\\r\n -d \'{\r\n "model": "deepseek-ai/DeepSeek-V3.1",\r\n "messages": [{"role": "user", "content": "Box A: red. Box B: blue. Box C: empty. Move A to C, Move B to A, Swap B and C. Where is red?"}],\r\n "stream": true\r\n }\' | stdbuf -oL grep "data: " | sed -u \'s/^data: //\' | grep -v "\\[DONE\\]" | \\\r\n jq --unbuffered -rj \'.choices[0].delta | (.reasoning_content // .reasoning // .content // empty)\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a3f5290>)])]>

다음 단계

GKE 관리형 DRANET 및 GKE Inference Gateway에 대해 자세히 알아보려면 다음을 검토하세요.

블로그: DRA: 동적 리소스 할당을 통한 Kubernetes 기기 관리의 새로운 시대
문서 세트: DRANET
문서: AI 하이퍼컴퓨터

질문이 있거나, 자세한 내용이 궁금하거나, 의견을 공유하고 싶으신가요? LinkedIn을 통해 저에게 알려주세요.

Uber가 클라우드 마이그레이션을 차단 해제하면서 네트워크 안정성을 개선한 방법

Fri, 04 Sep 2026 06:00:00 +0000

Uber는 서비스를 제공하는 도시와 많은 공통점을 가지고 있습니다. 두 가지 모두 항상 변화하고 성장하며, 혼잡과 확산을 방지하기 위해 결과 트래픽을 신중하게 관리해야 합니다.

Uber는 확장되는 네트워크를 관리하기 위해 기술 전략을 지속적으로 발전시켜 왔으며, 이러한 신중한 계획과 끊임없는 발전 덕분에 플랫폼 전반의 애플리케이션 트래픽이 원활하게 실행될 수 있었습니다. 궁극적으로는 언제든 원활하게 작동하는 안정적인 대규모 플랫폼을 유지하는 것이 사용자 신뢰를 유지하는 데 핵심입니다.

이러한 노력의 중요한 솔루션 중 하나는 Cloud Interconnect의 Application Awareness입니다. 하이브리드 네트워크 전반에서 애플리케이션 우선순위를 지정할 수 있는 업계 최초의 도구인 Cloud Interconnect의 Application Awareness는 Uber가 잠재적인 네트워크 정체 이벤트 중에 비즈니스 연속성을 보장하기 위해 중요한 트래픽의 우선순위를 지정하는 데 도움이 되었습니다.

Uber는 Cloud Interconnect의 Application Awareness에 대한 초기 설계 파트너로 활동하면서 이 기능이 Uber의 글로벌 규모 운영 요구사항을 충족하도록 지원했습니다. 이러한 개선은 Uber의 일상적인 운영을 개선했을 뿐만 아니라 전환 중에 서비스 중단 위험이 적을 것이라는 확신을 주어 Google Cloud 마이그레이션을 추진할 수 있는 자신감을 심어주었습니다.

이 게시물에서는 Uber가 가장 필요로 했던 기능과 그 이유, Cloud Interconnect의 Application Awareness의 내부 작동 방식, 그리고 다른 조직에도 도움이 될 수 있는 방법을 설명합니다.

중요 트래픽 우선순위 지정

분산형, 하이브리드형 또는 멀티 클라우드 애플리케이션을 전 세계 규모로 마이그레이션할 때는 네트워크 안정성이 주요 관심사가 됩니다. 아무리 가치 있는 마이그레이션이라도 진행 중인 서비스를 중단시킨다면 그 가치가 떨어질 수 있습니다. Uber와 같은 조직의 경우 대규모 데이터 분석 워크로드(새로운 AI 사용 사례 포함)를 지원하기 위해 방대한 양의 데이터를 이동하면 네트워크 링크가 포화되어 중요한 애플리케이션 트래픽의 안정성 위험이 증가할 수 있습니다.

표준 클라우드 상호 연결 접근방식을 사용하면 기업은 일반적으로 극심한 인프라 요구사항을 충족하기 위해 간단한 대역폭 오버프로비저닝을 적용합니다. 하지만 오늘날의 하이브리드 클라우드 수요와 Uber와 같은 조직의 규모를 고려할 때, 피크 사용량을 위해 네트워크 용량을 과도하게 프로비저닝하는 것은 비용이 너무 많이 들고 신뢰할 수 없는 경우가 많습니다.

최첨단 AI 혁신을 통합하면 과도한 프로비저닝의 단점이 더욱 커집니다. Uber는 네트워크 정체 없이 대규모 데이터 전송을 처리하고 비즈니스 크리티컬 애플리케이션의 성능을 보호할 수 있는 시스템을 갖춰야 합니다.

트래픽 처리, 정체 응답, 지연 시간 관리, 비용 효율성이라는 4가지 주요 기능을 포함한 Cloud Interconnect의 애플리케이션 인식 기능을 활용하여 Uber는 최신 기술 스택에 필요한 네트워킹 최적화를 달성할 수 있었습니다.

비공개 프리뷰를 시작으로 Uber는 애리조나주 피닉스와 버지니아주 애쉬번의 Google Cloud Interconnect 배포를 시작으로 인프라 전반에 이 기능을 배포했습니다. Cloud Interconnect의 Application Awareness를 통해 Uber는 DSCP 마킹과 구성된 큐잉 프로필을 사용하여 덜 시간에 민감한 데이터보다 최종 사용자 애플리케이션 트래픽을 분류하고 우선순위를 지정할 수 있습니다.

다음 차트에서는 Cloud Interconnect의 Application Awareness의 4가지 주요 기능과 기존 접근방식과의 차이점, Uber와 같은 조직의 운영 연속성을 개선하는 데 어떻게 도움이 되는지 살펴봅니다.

기능	표준 Interconnect 솔루션	Cloud Interconnect의 애플리케이션 인식
트래픽 처리	모든 트래픽을 동일하게 취급 (선입선출)	6개의 고유한 트래픽 클래스로 분류된 트래픽
정체 응답	버스트 중에 우선순위가 높은 애플리케이션 트래픽이 삭제될 수 있음	엄격한 우선순위 또는 대역폭 공유 정책을 통해 비즈니스에 중요한 트래픽을 보호합니다.
지연 시간 관리	우선순위가 높은 애플리케이션의 예측 불가능한 지연 시간	시간에 민감한 워크로드에 대해 예측 가능하고 일관된 낮은 지연 시간
비용 효율성	피크를 흡수하기 위해 값비싼 과잉 프로비저닝이 필요함	효율적인 대역폭 사용 및 TCO 절감

Uber의 핵심 요점

Uber는 Cloud Interconnect에 Application Awareness를 배포하여 네트워크에서 비즈니스에 중요한 트래픽의 우선순위를 즉시 지정할 수 있게 되면서 비즈니스 가치를 실현했습니다. 이 과정에서 Uber는 유사한 하이브리드 클라우드 과제를 안고 있는 다른 기업이 복제할 수 있는 청사진을 만들었습니다. 이 청사진의 핵심 요소는 다음과 같습니다.

비즈니스 연속성 보장: Uber는 트래픽이 많은 주요 이벤트 중에 우선순위를 지정할 애플리케이션 트래픽을 실시간으로 결정할 수 있습니다. 즉, 계획된 이벤트와 계획되지 않은 이벤트 모두 극단적인 상황에서도 미션 크리티컬 애플리케이션이 계속 실행됩니다. Uber 경영진은 Cloud Interconnect의 Application Awareness가 글로벌 운영에 중요하다고 말합니다.
효율적인 대역폭 사용: Uber는 정체를 방지하기 위해 무작정 대역폭을 과도하게 프로비저닝하는 대신 애플리케이션 인식을 통해 예상되는 네트워크 대역폭 요구사항에 맞춰 기존 Cloud Interconnect 용량을 더 잘 활용할 수 있습니다. 그 결과 네트워크 인프라의 총소유비용이 절감됩니다.
워크로드 마이그레이션 차단 해제: Uber는 네트워크 정체로부터 중요한 애플리케이션을 보호하여 상당한 워크로드를 Google Cloud로 마이그레이션할 수 있었고, 이 과정에서 운영 오버헤드를 대폭 줄였습니다.

"Cloud Interconnect의 Application Awareness는 더 많은 전략적 워크로드를 Google Cloud로 마이그레이션할 수 있는 능력을 발휘하는 데 핵심적인 역할을 했으며, 전 세계적으로 수요가 급증하는 기간에도 서비스 안정성을 유지하는 데 매우 중요합니다. 트래픽의 우선순위를 지능적으로 지정할 수 있게 해 주므로 우선순위가 높은 서비스를 보호하고 인프라를 더욱 효율적으로 만들어 총소유비용을 절감할 수 있습니다. 단순한 기능 배포가 아니라 비즈니스에 중요한 솔루션을 제공하는 심도 있는 엔지니어링 파트너십이었습니다." – 해리 류, Uber 엔지니어링 부문 이사

AI 및 그 이상을 위한 네트워크 안정성 확보

더 많은 기업이 클라우드 기반 AI 모델, 분산 애플리케이션, 데이터 분석을 통합함에 따라 대규모 데이터 전송을 처리할 준비를 갖추는 것이 비즈니스에 필수적인 요소가 되고 있습니다. 하지만 이 과정에서 중요한 애플리케이션의 안정성을 절대 훼손해서는 안 됩니다.

Cloud Interconnect의 애플리케이션 인식 기능을 통해 Uber는 비즈니스에 중요한 트래픽을 보호하기 위해 단순한 대역폭 과프로비저닝을 넘어선 조치가 최신 하이브리드 및 멀티 클라우드 전략을 수용하는 데 필요한 안정성을 구축하는 데 필수적인 단계임을 입증했습니다.

업계 전반에서 Cloud Interconnect가 지닌 잠재력에 관한 블로그를 읽고 이 서비스가 조직에 어떤 이점을 가져다줄 수 있는지 자세히 알아보세요. 더 자세히 알아볼 준비가 되었다면 Google Cloud의 네트워킹 및 업계 전문가팀이 도와드리겠습니다.

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 0x7f663b5b1510>)])]>

활용 사례 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 0x7f663aa87650>)])]>

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에게 깊은 감사를 드립니다.

Google Cloud 애플리케이션 로드 밸런서(ALB) 마이그레이션 실전 가이드

Mon, 01 Jun 2026 01:00:00 +0000

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

기존의 온프레미스 하드웨어 솔루션에서 Cloud Load Balancing(로드 밸런싱)으로 애플리케이션 로드 밸런서 인프라를 마이그레이션하면 확장성, 비용 효율성, Google Cloud 에코시스템과의 긴밀한 통합 측면에서 상당한 이점을 얻을 수 있습니다. 하지만 다음과 같은 근본적인 질문이 자주 제기됩니다. "현재 로드 밸런서 구성은 어떻게 해야 할까요?"

기존의 온프레미스 로드 밸런서 구성에는 트래픽 제어를 위한 비즈니스 크리티컬한 로직이 수년간 축적되어 있는 경우가 많습니다. 다행인 점은 기존 기능을 완전히 마이그레이션할 수 있을 뿐만 아니라, 이번 마이그레이션이 트래픽 관리를 현대화하고 단순화할 수 있는 절호의 기회라는 것입니다.

이 실전 가이드에서는 기존 로드 밸런서를 Google Cloud의 Application Load Balancer(애플리케이션 로드 밸런서, ALB)로 마이그레이션하기 위한 실무 지침을 설명합니다. 여기서는 설정 명세형 구성 (Declarative configurations)과 혁신적인 이벤트 기반 (Event-driven) Service Extensions(서비스 익스텐션) 에지 컴퓨팅 기능 (Edge compute capability)을 모두 활용하여 공통적인 기능을 처리하는 방법을 다룹니다.

성공적인 마이그레이션을 위한 단계별 접근 방식

명령형 스크립트 기반 시스템 (Imperative, script-based system)에서 클라우드 네이티브 및 설정 명세형 우선 모델 (Cloud-native, declarative-first model)로 전환하려면 체계적인 계획이 필요합니다. 이를 위해 직관적인 4단계 접근 방식을 권장합니다.

1단계: 현황 파악 및 매핑 (Discovery and mapping)

마이그레이션을 시작하기 전에 현재 시스템의 구성 현황을 명확히 파악해야 합니다. 기존 로드 밸런서 구성을 철저히 분석하고 분류해 보세요. 각 규칙의 궁극적인 목적은 무엇인가요? 단순한 HTTP-HTTPS 리디렉션 (HTTP-to-HTTPS redirect)을 수행하고 있나요? HTTP 헤더 수정 (HTTP header manipulation - 추가 또는 삭제)을 처리하고 있나요? 아니면 복잡한 맞춤형 인증 로직 (Complex, custom authentication logic)을 처리하고 있나요?

대부분의 구성은 일반적으로 다음 두 가지 주요 범주로 나뉩니다.

공통 패턴 (Common patterns): 리디렉션, URL 재작성, 기본 헤더 수정, IP 기반 액세스 제어 목록(ACL) 등 대부분의 웹 애플리케이션에 공통적으로 적용되는 표준 로직입니다.
맞춤형 비즈니스 로직 (Bespoke business logic): 맞춤형 독점 토큰 인증, 고급 헤더 추출 및 교체, HTTP 속성에 따른 동적 백엔드 선택, HTTP 응답 본문 수정 등 해당 애플리케이션에 고유한 복잡한 커스텀 로직입니다.

2단계: 대응하는 Google Cloud 기능 선택

규칙 분류를 마쳤다면 다음 단계는 이를 적절한 Google Cloud 기능에 매핑하는 것입니다. 이는 단순한 1:1 대체가 아니라, 아키텍처를 최적화할 수 있는 전략적인 선택입니다.

옵션 1: 설정 명세형 방식 (Declarative path - 규칙의 약 80%에 해당) 대부분의 공통 패턴의 경우, Application Load Balancer(ALB)의 내장된 설정 명세형 기능을 활용하는 것이 가장 좋은 접근 방식입니다. 복잡한 스크립트를 작성하는 대신, 구성 파일에 원하는 최종 상태를 정의하는 방식입니다. 이 방식이 관리와 버전 제어, 향후 확장성 확보 측면에서 훨씬 유리합니다.

공통 패턴과 설정 명세형 기능의 매핑 예시:

리디렉션/재작성 (Redirects/Rewrites) ➔ Application Load Balancer(ALB) URL 맵 (Application Load Balancer URL maps)
ACL/스로틀링 (ACLs/Throttling) ➔ Google Cloud Armor 보안 정책 (Google Cloud Armor security policies)
세션 지속성 (Session Persistence) ➔ 백엔드 서비스 설정 (Backend service configuration)

옵션 2: 프로그래밍 방식 (Programmatic path - 복잡한 맞춤형 규칙에 해당) 설정 명세형 기능만으로 처리하기 어려운 복잡하고 독특한 비즈니스 로직을 마이그레이션할 때는 프로그래밍 방식으로 대응할 수 있는 Service Extensions가 훌륭한 대안이 됩니다. 이는 개발자가 작성한 맞춤형 코드(Rust, C++ 또는 Go)를 로드 밸런서의 데이터 경로에 직접 삽입할 수 있는 강력한 에지 컴퓨팅 기능입니다. 현대적인 완전관리형 고성능 프레임워크 내에서 비즈니스 요구에 맞는 탁월한 유연성을 제공합니다.

다음 순서도는 각 구성에 적합한 Google Cloud 기능을 결정하는 데 유용한 가이드를 제공합니다.

본 이미지는 Google Nano Banana로 생성되었습니다.

3단계: 테스트 및 검증 (Test and Validate)

구성에 적합한 마이그레이션 경로를 선택했다면, 이제 실제 운영 환경을 모사한 스테이징 환경에 새로운 Application Load Balancer(ALB) 구성을 배포할 차례입니다. 마이그레이션된 로직을 중점적으로 살펴보며 모든 애플리케이션 기능이 정상 작동하는지 철저히 테스트해야 합니다. 자동화된 테스트와 수동 QA (Automated testing and manual QA)를 적절히 결합하여 리디렉션 (Redirects), 보안 정책 (Security policies), 그리고 맞춤형 Service Extensions 로직이 의도한 대로 정확하게 동작하는지 검증하세요.

4단계: 단계적 전환 (Phased Cutover - 카나리아 배포)

한 번에 모든 트래픽을 전환하는 '빅뱅' 방식 대신, 리스크를 최소화할 수 있는 단계적 마이그레이션 전략을 구현해야 합니다. 실제 서비스 트래픽의 일부(예: 5~10%)만 먼저 새로운 Google Cloud 로드 밸런서(ALB)로 라우팅하며 전환 프로세스를 시작하세요. 이 초기 기간 동안 지연 시간 (Latency), 오류율 (Error rates), 애플리케이션 성능 (Application performance) 등의 주요 지표를 면밀히 모니터링해야 합니다. 안정성이 충분히 검증되면 ALB로 라우팅되는 트래픽의 비율을 점진적으로 늘려나갑니다. 만에 하나 심각한 문제가 발생할 경우를 대비하여 기존 인프라 (Legacy infrastructure)로 즉시 되돌릴 수 있는 명확하고 빠른 롤백 계획 (Rollback plan)을 항상 수립해 두어야 합니다.

안전하고 원활한 마이그레이션을 위한 권장사항

실제 마이그레이션 구축 사례와 경험을 바탕으로, 로드 밸런서 마이그레이션 계획 시 반드시 고려해야 할 핵심 권장사항을 정리했습니다.

선 분석, 후 마이그레이션 (Analyze first, migrate second): 기존 구성을 철저히 분석하는 것이 성공의 첫 단추입니다. 현재 사용하지 않거나 불필요한 레거시 로직까지 그대로 마이그레이션(Lift and Shift)하는 것은 지양해야 합니다. 이번 기회에 복잡도를 줄이세요.
설정 명세형 방식 우선 고려 (Prefer declarative): 항상 Google Cloud의 관리형 설정 명세 기능(URL Map, Cloud Armor)을 최우선으로 검토하세요. 이 기능들이 아키텍처를 단순하게 유지하고, 유지 관리 부담을 줄이며, 확장성을 극대화하는 가장 좋은 방법입니다.
Service Extensions의 전략적 활용 (Use Service Extensions strategically): 설정 명세형 기능만으로는 도저히 해결할 수 없는 복잡하고 고유한 맞춤형 비즈니스 로직에 한해서만 Service Extensions를 선택적으로 적용하세요.
철저한 모니터링 (Monitor everything): 마이그레이션이 진행되는 동안 기존 로드 밸런서와 신규 Google Cloud 로드 밸런서 모두를 지속적으로 모니터링해야 합니다. 트래픽 볼륨, 지연 시간, 에러율 등 핵심 지표를 관찰하여 이상 징후를 즉각적으로 감지하고 신속하게 대응할 수 있도록 준비하세요.
팀 역량 강화 (Train your team): 마이그레이션 전후로 운영 팀이 Google Cloud의 Cloud Load Balancing 개념과 작동 방식을 충분히 이해할 수 있도록 교육해야 합니다. 이를 통해 새로운 모던 인프라를 효과적으로 운영하고 안정적으로 유지 관리할 수 있는 역량을 갖출 수 있습니다.

결론

기존 온프레미스 로드 밸런서 인프라를 Google Cloud로 마이그레이션하는 것은 단순한 서버 이전을 넘어, 애플리케이션 서비스 제공(Delivery) 환경을 현대화할 수 있는 최적의 기회입니다. 현재의 로드 밸런싱 구성과 요구 사항을 분석하여 설정 명세형 ALB 기능 또는 프로그래밍 방식의 Service Extensions에 전략적으로 매핑함으로써, 미래의 비즈니스 요구에 신속하게 대응할 수 있는 확장 가능하고 복원력 있으며 비용 효율적인 모던 인프라를 구축할 수 있습니다.

지금 바로 Application Load Balancer 및 Service Extensions의 다양한 기능과 고급 역량을 검토하여 귀사의 애플리케이션에 가장 적합한 설계를 구상해 보세요. 보다 구체적인 가이드나 복잡한 아키텍처 설계가 필요하다면 Google Cloud 팀에 언제든지 문의하여 도움을 받으실 수 있습니다.

에이전트 AI 시대를 위한 Envoy 네트워킹의 필요성

Fri, 24 Apr 2026 06:00:00 +0000

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

오늘날의 에이전트 중심 AI(Agentic AI) 환경에서 네트워크는 새로운 책임을 맡게 되었습니다.

전통적인 애플리케이션 스택에서 네트워크는 주로 서비스 간에 요청을 이동시키는 역할을 했습니다. 하지만 최근 백서인 에이전트 네이티브 시대의 클라우드 인프라에서 논의된 것처럼, 에이전틱 시스템에서 네트워크는 모델 호출, 도구(tool) 호출, 에이전트 간 상호작용, 그리고 에이전트가 수행할 수 있는 작업을 결정하는 정책 결정의 중심에 위치합니다. 다양한 프레임워크로 구축된 에이전트가 급격히 확산됨에 따라, 대규모 환경에서도 모든 에이전틱 경로에 걸쳐 거버넌스와 보안을 일관되게 적용해야 할 필요성이 커졌습니다. 이를 달성하려면 적용 계층(enforcement layer)이 애플리케이션 수준에서 기반이 되는 인프라 수준으로 이동해야 합니다. 이러한 변화는 네트워크가 더 이상 단순한 '블라인드 전송 계층'으로 작동할 수 없음을 의미합니다. 네트워크는 더 많이 이해하고, 더 잘 적용하며, 더 빠르게 적응해야 합니다. 이러한 변화가 바로 Envoy가 필요한 이유입니다.

고성능 분산 프록시이자 범용 데이터 평면(universal data plane)인 Envoy는 대규모 환경을 위해 구축되었습니다. Google Cloud를 포함하여 까다로운 엔터프라이즈 환경에서 신뢰받는 Envoy는 단일 서비스 배포부터 Ingress, Egress, Sidecar 패턴을 사용하는 복잡한 서비스 메시에 이르기까지 모든 것을 지원합니다. 뛰어난 확장성, 강력한 정책 통합 및 운영 성숙도 덕분에 Envoy는 프로토콜의 급격한 진화와 통제 상실에 따른 리스크가 커진 오늘날, 변화를 유연하게 수용하면서도 강력한 거버넌스를 유지할 수 있는 가장 실용적이고 이상적인 솔루션입니다. 에이전틱 AI를 구축하는 팀에게 Envoy는 단순한 개념 그 이상이며, 실용적이고 운영 환경에 바로 적용할 수 있는 기반입니다.

에이전틱 워크로드의 특징과 과제

에이전틱 워크로드는 여전히 전송을 위해 HTTP를 자주 사용하지만, 전통적인 HTTP 중개자가 의존하는 몇 가지 가정을 깨뜨립니다. Model Context Protocol (MCP) 및 Agent2agent (A2A)와 같은 프로토콜은 HTTP를 통한 JSON-RPC 또는 gRPC를 사용하며, 표준 HTTP 요청/응답 의미 체계 위에 클라이언트와 서버가 기능을 교환하는 MCP 초기화와 같은 프로토콜 수준의 단계를 추가합니다. 중개자가 적응해야 하는 에이전틱 시스템의 주요 측면은 다음과 같습니다.

다양한 엔터프라이즈 거버넌스 명령: 주된 과제는 안전, 보안, 데이터 프라이버시 및 규제 준수에 대한 광범위한 비협상적 기업 요구 사항을 충족하는 것입니다. 이러한 요구 사항은 종종 표준 네트워크 정책을 넘어서며, 내부 시스템과의 깊은 통합, 맞춤형 로직, 새로운 조직 규칙이나 외부 규정에 빠르게 적응하는 능력을 요구합니다. 이를 위해서는 기업이 특정 거버넌스 모델을 연결할 수 있는 확장성이 뛰어난 프레임워크가 필요합니다.

정책 속성이 헤더가 아닌 메시지 본문(body)에 위치: 경로 및 헤더와 같은 정책 입력에 쉽게 액세스할 수 있는 기존 웹 트래픽과 달리, 에이전틱 프로토콜은 JSON-RPC 또는 gRPC 페이로드 깊숙이 중요한 속성(예: 모델 이름, 도구 호출, 리소스 ID)을 묻어두는 경우가 많습니다. 이러한 변화로 인해 중개자는 컨텍스트를 고려한 정책을 적용하기 위해 메시지 콘텐츠를 파싱하고 이해하는 능력을 갖춰야 합니다.

다양하고 진화하는 프로토콜 특성 처리: 에이전틱 프로토콜은 균일하지 않습니다. Streamable HTTP를 사용하는 MCP와 같은 일부 프로토콜은 분산 프록시 간에 세션 관리가 필요한 상태 저장(stateful) 상호작용을 도입할 수 있습니다(예: Mcp-Session-Id 사용). 이러한 다양한 동작을 지원하고 미래의 프로토콜 혁신에 대응해야 할 필요성은 본질적으로 적응 가능하고 확장 가능한 네트워킹 기반의 필요성을 강화합니다.

이러한 요소들은 기업에 단순한 연결성 그 이상이 필요함을 의미합니다. 네트워크는 이제 앞서 언급한 중요한 거버넌스 요구 사항을 적용하기 위한 중심점 역할을 해야 합니다. 여기에는 프로토콜과 에이전트 동작의 급격한 진화에 발맞추면서 중앙 집중식 보안, 포괄적인 감사 가능성, 세부적인 정책 적용, 동적 가드레일과 같은 기능을 제공하는 것이 포함됩니다. 간단히 말해, 에이전틱 AI는 네트워크를 단순한 전송 경로에서 중요한 제어 지점으로 변환합니다.

Envoy가 적합한 3가지 이유

Envoy는 다음 세 가지 이유로 에이전틱 AI 네트워킹에 강력하게 부합합니다.

검증됨 (Battle-tested): 기업은 이미 대규모 보안에 민감한 환경에서 Envoy에 의존하고 있으므로 차세대 트래픽 관리 및 정책 적용을 고정할 수 있는 신뢰할 수 있는 플랫폼입니다.
확장 가능 (Extensible): Envoy는 네이티브 필터, Rust 모듈, WebAssembly(Wasm) 모듈 및 외부 처리(external processing) 패턴을 통해 확장될 수 있습니다. 이를 통해 플랫폼 팀은 생태계가 바뀔 때마다 네트워킹 계층을 다시 빌드할 필요 없이 새로운 프로토콜을 채택할 수 있습니다.
바로 운영에 유용함 (Operationally useful today): Envoy는 이미 게이트웨이, 적용 지점, 관찰 가능성 계층 및 제어 평면의 통합 표면 역할을 합니다. 따라서 표준이 정착될 때까지 기다리지 않고 지금 바로 움직여야 하는 조직에 실용적인 선택입니다.

이러한 핵심 강점을 바탕으로 Envoy는 에이전틱 네트워킹의 고유한 요구 사항을 충족하기 위해 특정 아키텍처 발전을 도입했습니다.

1. Envoy는 에이전트 트래픽을 이해합니다.

에이전틱 네트워킹의 첫 번째 요구 사항은 간단합니다. 게이트웨이가 에이전트가 실제로 수행하려는 작업을 이해해야 한다는 것입니다.

하지만 이는 말처럼 쉽지 않습니다. MCP, A2A 및 OpenAI 스타일의 API와 같은 프로토콜에서는 중요한 정책 신호가 요청 본문(body) 내에 있을 수 있습니다. 기존 HTTP 프록시는 본문을 불투명한 바이트 스트림으로 처리하도록 최적화되어 있습니다. 이 설계는 효율적이지만 프록시가 적용할 수 있는 범위를 제한합니다. JSON 메시지를 사용하는 프로토콜의 경우, 프록시는 정책 적용에 필요한 속성 값을 찾기 위해 전체 요청 본문을 버퍼링해야 할 수 있습니다. 특히 해당 속성이 JSON 메시지의 끝에 나타나는 경우 더욱 그렇습니다. 소비된 토큰을 기반으로 하는 속도 제한(rate limiting)과 같은 생성형 AI 프로토콜 고유의 비즈니스 로직도 서버 응답 파싱을 요구할 수 있습니다.

Envoy는 HTTP를 통해 전달되는 프로토콜 메시지를 **디프레이밍(deframing)**하고 유용한 속성을 나머지 필터 체인에 노출함으로써 이 문제를 해결합니다. 생성형 AI 프로토콜의 확장성 모델은 두 가지 목표에 의해 가이드되었습니다.

OAuth 또는 추적기(tracer)와 같이 기본적으로 생성형 AI 프로토콜과 함께 작동하는 기존 HTTP 확장의 손쉬운 재사용.
생성형 AI 전용 확장을 위한 디프레이밍된 메시지에 대한 쉬운 액세스. 이를 통해 개발자는 HTTP나 JSON 봉투(envelope)를 처리할 필요 없이 생성형 AI 비즈니스 로직에 집중할 수 있습니다.

이러한 목표에 따라 생성형 AI 프로토콜용 새 확장은 여전히 HTTP 확장으로 빌드되고 HTTP 필터 체인에 구성됩니다. 이를 통해 OAuth 또는 mTLS 권한 부여와 같은 HTTP 네이티브 비즈니스 로직을 단일 체인에서 생성형 AI 프로토콜 로직과 혼합할 수 있는 유연성을 제공합니다. 디프레이밍 확장은 HTTP로 전달되는 프로토콜 메시지를 파싱하고, 추출된 속성이 포함된 앰비언트 컨텍스트(ambient context) 또는 파싱된 메시지 전체를 잘 알려진 필터 상태 및 메타데이터 값을 통해 다운스트림 확장에 제공합니다.

모든 정책 구성 요소가 자체적으로 JSON 봉투 또는 프로토콜별 메시지 형식을 파싱하도록 강제하는 대신, Envoy는 이러한 속성을 구조화된 메타데이터로 사용할 수 있도록 합니다. 게이트웨이가 프로토콜 메시지를 디프레이밍하면 ext_authz 또는 RBAC과 같은 기존 Envoy 확장이 프로토콜 속성을 읽어 MCP의 도구 이름, A2A의 메시지 속성 또는 OpenAI의 모델 이름과 같은 프로토콜별 속성을 사용하여 정책을 평가할 수 있습니다.

액세스 로그에는 향상된 모니터링 및 감사를 위해 메시지 속성이 포함될 수 있습니다. 프로토콜 속성은 Common Expression Language (CEL) 런타임에서도 사용할 수 있으므로 RBAC 또는 복합 확장에서 복잡한 정책 표현식을 간단하게 생성할 수 있습니다.

버퍼링 및 메모리 관리 Envoy는 HTTP 요청을 프록시할 때 가능한 한 적은 메모리를 사용하도록 설계되었습니다. 그러나 에이전틱 프로토콜을 파싱하려면 임의의 양의 버퍼 공간이 필요할 수 있으며, 특히 확장에 전체 메시지가 메모리에 있어야 하는 경우 더욱 그렇습니다. 확장이 더 큰 버퍼를 사용할 수 있도록 허용하는 유연성은 특히 신뢰할 수 없는 트래픽이 있는 경우 메모리 고갈로부터의 적절한 보호와 균형을 이루어야 합니다.

이를 달성하기 위해 Envoy는 이제 요청당 버퍼 크기 제한을 제공합니다. 요청 데이터를 보유하는 버퍼도 오버로드 관리자(overload manager)와 통합되어 메모리 부족 상황에서 유휴 타임아웃을 줄이거나 장시간 가장 많은 메모리를 소비하는 요청을 재설정하는 등 전방위적인 보호 조치를 취할 수 있습니다. 이러한 변경 사항은 Envoy가 리소스 효율성을 손상시키지 않으면서 생성형 AI 프로토콜의 게이트웨이 및 정책 적용 지점 역할을 할 수 있는 길을 열어줍니다.

2. Envoy는 중요한 요소에 정책을 적용합니다.

트래픽을 이해하는 것은 게이트웨이가 이에 따라 조치를 취할 수 있을 때만 유용합니다.

에이전틱 시스템에서 정책은 단지 에이전트가 도달할 수 있는 서비스에 관한 것이 아닙니다. 에이전트가 어떤 도구를 호출할 수 있는지, 어떤 모델을 사용할 수 있는지, 어떤 ID를 제시하는지, 얼마나 소비할 수 있는지, 어떤 종류의 출력이 추가 통제를 필요로 하는지에 관한 것입니다. 이는 단순한 레이어 4 또는 경로 기반 제어보다 가치가 높은 결정이며, 에이전트가 기업을 대신하여 조치를 취할 수 있도록 허용될 때 기업이 관심을 갖는 종류의 통제입니다.

Envoy는 전송 수준 보안을 애플리케이션 레벨의 정책 적용과 결합할 수 있기 때문에 이 분야에 매우 적합합니다. 팀은 mTLS 및 SPIFFE ID로 워크로드를 인증한 다음 RBAC, 외부 권한 부여, 외부 처리, 액세스 로깅 및 CEL 기반 정책 표현식을 사용하여 프로토콜별 규칙을 적용할 수 있습니다.

이 기능은 플랫폼 팀이 에이전트 개발과 적용을 분리할 수 있게 해주기 때문에 매우 중요합니다. 개발자는 유용한 에이전트를 구축하는 데 집중할 수 있고, 운영자는 도구, 모델 및 프로토콜이 계속 바뀌더라도 네트워크 계층에서 일관된 제로 트러스트 태세를 적용할 수 있습니다. 이러한 제로 트러스트 분리의 대표적인 예는 AI 에이전트가 인간 사용자를 대신하여 작업을 실행해야 하는 중요한 "사용자 위임(user-behind-agent)" 시나리오입니다. 전통적으로 애플리케이션에 사용자 자격 증명을 직접 전달하는 것은 심각한 보안 위험을 초래합니다. 프롬프트 주입을 통해 에이전트가 손상되거나 조작되면 공격자가 해당 자격 증명을 탈취하거나 오용할 수 있습니다. ID 관리를 Envoy로 오프로드함으로써 프록시는 인프라 계층의 아웃바운드 요청에 사용자 위임 토큰을 자동으로 삽입할 수 있습니다. 에이전트는 민감한 자격 증명을 직접 보유하지 않으므로 손상된 에이전트가 토큰을 오용하거나 유출할 위험이 완전히 차단되어 작업이 사용자의 실제 권한으로 엄격하게 제한됩니다.

사례 연구: 특정 GitHub MCP 도구로 에이전트 제한 GitHub 문제를 분류하는 에이전트를 가정해 보겠습니다. GitHub MCP 서버는 수십 개의 도구를 노출할 수 있지만, 에이전트는 list_issues, get_issue, get_issue_comments와 같이 읽기 전용의 작은 하위 집합만 필요할 수 있습니다. 대부분의 기업에서 이 차이는 중요합니다. 유용한 에이전트가 자동으로 제한 없는 에이전트가 되어서는 안 됩니다.

MCP 서버 앞에 Envoy가 있으면 게이트웨이는 mTLS 핸드셰이크 중에 SPIFFE를 사용하여 에이전트 ID를 확인하고, 디프레이밍 필터를 통해 MCP 메시지를 파싱하며, 요청된 메서드와 도구 이름을 추출하고, 해당 특정 에이전트 ID에 승인된 도구 호출만 허용하는 정책을 적용할 수 있습니다. RBAC은 MCP 디프레이밍 필터가 생성한 메타데이터를 사용하여 MCP 메시지의 메서드와 도구 이름을 확인합니다:

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6660bcd0d0>)])]>

이것이 진정한 가치입니다. 정책은 트래픽과 가까운 곳에서 중앙 집중식으로, 에이전트의 실제 동작과 일치하는 방식으로 적용됩니다.

정적 규칙을 넘어서: 외부 권한 부여 (External Authorization) RBAC 규칙을 사용하여 표현할 수 없는 복잡한 규정 준수 정책은 ext_authz 프로토콜을 사용하여 외부 권한 부여 서비스에서 구현할 수 있습니다. Envoy는 ext_authz RPC의 컨텍스트에서 HTTP 헤더와 함께 MCP 메시지 속성을 제공합니다. 피어 인증서의 에이전트 SPIFFE ID를 전달할 수도 있습니다:

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n- name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f66397ab810>)])]>

이를 통해 외부 서비스는 에이전트나 MCP 서버가 정책 계층을 신경 쓰지 않고도 에이전트 ID, MCP 메서드, 도구 이름 및 기타 프로토콜 속성의 전체 조합을 기반으로 권한 부여 결정을 내릴 수 있습니다.

프로토콜 네이티브 에러 응답 Envoy가 요청을 거부할 때 에러는 호출하는 에이전트에게 의미가 있어야 합니다. MCP 트래픽의 경우 Envoy는 local_reply_config를 사용하여 HTTP 에러 코드를 적절한 JSON-RPC 에러 응답에 매핑할 수 있습니다. 예를 들어, 403 Forbidden을 isError: true 및 사람이 읽을 수 있는 메시지가 포함된 JSON-RPC 응답으로 매핑하여 에이전트가 불투명한 HTTP 상태 코드 대신 프로토콜에 적합한 거부를 수신하도록 보장할 수 있습니다.

3. Envoy는 대규모로 상태 저장(stateful) 에이전트 상호작용을 지원합니다.

모든 에이전트 트래픽이 상태 비저장(stateless)은 아닙니다. MCP용 Streamable HTTP를 포함한 일부 프로토콜은 세션 지향 동작에 의존할 수 있습니다. 이는 특히 규모와 복원력을 달성하기 위해 트래픽이 여러 게이트웨이 인스턴스를 통해 흐를 때 중개자에게 새로운 과제를 안겨줍니다. MCP 세션은 효과적으로 에이전트를 세션을 설정한 서버에 바인딩하며, 모든 중개자는 들어오는 MCP 연결을 올바른 서버로 디렉팅하기 위해 이러한 정보를 알아야 합니다.

한 백엔드에서 세션이 설정되면 해당 대화의 나중 요청은 올바른 대상으로 도달해야 합니다. 이는 단일 프록시 배포에서는 간단해 보이지만, 여러 Envoy 인스턴스가 동일한 에이전트의 서로 다른 요청을 처리할 수 있는 수평 확장 시스템에서는 더 복잡해집니다.

패스스루 게이트웨이 (Passthrough gateway) 더 간단한 패스스루 모드에서 Envoy는 각 다운스트림 연결에 대해 하나의 업스트림 연결을 설정합니다. 이 모드의 주요 용도는 외부 MCP 서버에 대한 클라이언트 권한 부여, RBAC, 속도 제한 및 인증과 같은 중앙 집중식 정책을 적용하는 것입니다. 중개자 간에 전송되는 세션 상태에는 초기 HTTP 연결을 통해 세션을 설정한 서버의 주소만 포함하면 되므로 모든 세션 관련 요청이 해당 서버로 전달됩니다.

서로 다른 Envoy 인스턴스 간의 세션 상태 전송은 MCP 서버가 제공한 MCP 세션 ID에 인코딩된 세션 상태를 추가함으로써 달성됩니다. Envoy는 요청을 대상 MCP 서버로 전달하기 전에 세션 ID에서 세션 상태 접미사를 제거합니다. 이 세션 유지(session stickiness)는 Envoy의 envoy.http.stateful_session.envelope 확장을 구성하여 활성화됩니다.

통합 게이트웨이 (Aggregating gateway) 통합 모드에서 Envoy는 여러 백엔드 MCP 서버의 기능, 도구 및 리소스를 통합하여 단일 MCP 서버 역할을 합니다. 정책을 적용하는 것 외에도 이는 에이전트 구성을 단순화하고 여러 MCP 서버에 대한 정책 적용을 통합합니다.

이 모드에서의 세션 관리는 세션 상태에 도구 및 리소스를 이를 광고한 서버 주소 및 세션 ID에 매핑하는 것도 포함해야 하므로 더 복잡합니다. Envoy가 에이전트에게 제공하는 세션 ID는 도구나 리소스가 알려지기 전에 생성되며, 매핑은 나중에 Envoy와 백엔드 MCP 서버 간의 MCP 초기화 단계가 완료된 후에 설정되어야 합니다.

왜 Envoy가 이 변화에 적합한가 현재 Envoy에 구현된 한 가지 접근 방식은 도구 또는 리소스의 이름을 식별자 및 원래 서버의 세션 ID와 결합하는 것입니다. 정확한 도구 또는 리소스 이름은 일반적으로 에이전트에게 의미가 없으며 이 추가 출처 정보를 전달할 수 있습니다. 수정되지 않은 도구 또는 리소스 이름이 바람직한 경우, 또 다른 접근 방식은 매핑이 없는 Envoy 인스턴스를 사용한 다음 특정 도구를 호출하기 전에 tools/list 명령을 실행하여 매핑을 다시 생성하는 것입니다. 이는 MCP 세션의 외부 전역 저장소를 배포하는 복잡성 대신 대기 시간(latency)을 절충하는 방식이며, 현재 사용자 피드백을 기반으로 계획 중입니다.

이것이 중요한 이유는 Envoy를 단순한 트래픽 포워딩 이상으로 발전시키기 때문입니다. 이를 통해 Envoy는 여러 요청, 도구 및 백엔드에 걸친 에이전트 워크플로우를 위한 신뢰할 수 있는 중개자 역할을 수행할 수 있습니다.

4. Envoy는 에이전트 탐색(discovery)을 지원합니다.

Envoy는 잘 알려진 AgentCard 엔드포인트를 통한 A2A 프로토콜 및 에이전트 탐색에 대한 지원을 추가하고 있습니다. 에이전트 기능을 담은 JSON 문서인 AgentCard는 기술, 인증 요구 사항 및 서비스 엔드포인트를 광고하여 탐색 및 다중 에이전트 조정을 가능하게 합니다. AgentCard는 직접 응답 구성을 통해 정적으로 프로비저닝하거나 xDS 또는 ext_proc API를 통해 중앙 집중식 에이전트 레지스트리 서버에서 얻을 수 있습니다. A2A 구현 및 에이전트 탐색에 대한 자세한 설명은 향후 블로그 게시물에서 발표될 예정입니다.

5. Envoy는 에이전틱 네트워킹 과제를 위한 완전한 솔루션입니다.

까다로운 배포 환경에서 MCP 프로토콜에 대한 정책 적용을 가능하게 한 동일한 기반 위에, Envoy는 OpenAI에 대한 지원과 에이전틱 프로토콜을 RESTful HTTP API로 변환하는 트랜스코딩(transcoding) 지원을 추가하고 있습니다. 이 트랜스코딩 기능은 생성형 AI 에이전트와 기존 RESTful 애플리케이션의 통합을 단순화하며, OpenAPI 기반 애플리케이션에 대한 즉각적인 지원과 동적 모듈 또는 Wasm 확장을 통한 맞춤형 옵션을 제공합니다. 트랜스코딩 외에도 Envoy는 쿼터 관리와 같은 고급 정책 적용, 생성형 AI 시스템을 위한 OpenTelemetry 의미 체계 규약을 준수하는 포괄적인 텔레메트리, 안전한 에이전트 운영을 위한 통합 가드레일 등 프로덕션 환경 적용 준비(Production Readiness)를 위한 핵심 영역에서 강화되고 있습니다.

안전한 에이전트를 위한 가드레일 다음으로 중요한 투자 영역은 모든 에이전틱 트래픽에 대한 가드레일의 중앙 집중식 관리 및 적용입니다. 정책 적용 지점을 외부 가드레일과 통합하려면 현재 맞춤형 구현이 필요하며, 이 문제 영역은 표준화가 시급합니다.

제어 평면(Control Plane)이 이를 운영 가능하게 만듭니다.

게이트웨이는 이야기의 일부일 뿐입니다. 이러한 정책 관리 및 롤아웃을 대규모로 달성하려면 유니버설 데이터 평면 API로도 알려진 xDS 프로토콜을 사용하여 데이터 평면을 동적으로 구성하는 별도의 제어 평면이 필요합니다.

여기서 제어 평면이 중요해집니다. Envoy AI Gateway 및 kube-agentic-networking과 같은 오픈 소스 프로젝트와 함께 Cloud Service Mesh는 Envoy를 데이터 평면으로 사용하는 한편, 운영자에게 에이전틱 워크로드에 대한 정책을 정의하고 관리하는 상위 수준의 방법을 제공합니다.

이러한 결합은 강력한 시너지를 냅니다. Envoy는 트래픽 경로에서 적용 및 확장성을 제공하는 반면, 제어 평면은 팀이 해당 기능을 일관되게 배포하는 데 필요한 운영 모델을 제공합니다.

이것이 지금 중요한 이유

에이전틱 시스템 및 MCP, A2A, OpenAI와 같은 생성형 AI 프로토콜로의 전환은 네트워크 중개자의 진화를 필요로 합니다. Envoy가 해결하는 주요 복잡성은 다음과 같습니다.

심층 프로토콜 분석: 프로토콜 디프레이밍 확장은 HTTP 요청 본문에서 정책 관련 속성(도구 이름, 모델 이름, 리소스 경로)을 추출하여 기존 프록시가 불투명한 바이트 스트림만 볼 수 있는 곳에서 정밀한 정책 적용을 가능하게 합니다.
세분화된 정책 적용: 이러한 내부 속성을 노출함으로써 RBAC 및 ext_authz와 같은 기존 Envoy 확장은 프로토콜별 기준에 따라 정책을 평가할 수 있습니다. 이를 통해 네트워크 운영자는 통합된 제로 트러스트 보안 태세를 적용하여 에이전트가 특정 도구 또는 리소스에 대한 액세스 정책을 준수하도록 보장할 수 있습니다.
상태 저장(stateful) 전송 관리: Envoy는 MCP에서 사용하는 Streamable HTTP 전송에 대한 세션 상태 관리를 지원하여 여러 중개자 플릿에서도 패스스루 및 통합 게이트웨이 모드 모두에서 강력한 배포를 가능하게 합니다.

에이전틱 AI 프로토콜은 아직 초기 단계에 있으며 프로토콜 환경은 계속 진화할 것입니다. 이것이 바로 네트워킹 계층이 적응 가능해야 하는 이유입니다. 기업은 새로운 에이전트 프레임워크, 전송 패턴 또는 도구 프로토콜이 주목받을 때마다 보안 및 트래픽 인프라를 다시 빌드할 필요가 없어야 합니다. 통제력을 희생하지 않으면서 변화를 흡수할 수 있는 기반이 필요합니다.

Envoy는 입증된 운영 성숙도, 뛰어난 확장성, 에이전틱 워크로드에 대한 한층 강화된 프로토콜 지원능력을 한 곳에서 모두 제공합니다. Envoy를 에이전트 게이트웨이로 활용함으로써 조직은 에이전트 개발 코드에서 보안 및 정책 적용을 분리할 수 있습니다.

이것이 Envoy를 단순한 AI 트래픽 처리 프록시 그 이상으로 만듭니다. Envoy는 에이전틱 AI 네트워킹을 위한 미래 지향적인 기반입니다.

Next ‘26: AI 시대 보안의 재정의, 구글 클라우드와 Wiz가 함께 그리는 미래

Wed, 22 Apr 2026 12:00:00 +0000

aside_block: <ListValue: [StructValue([('title', "구글 클라우드 Next '26 보안 하이라이트"), ('body', <wagtail.rich_text.RichText object at 0x7f6639f32150>), ('btn_text', ''), ('href', ''), ('image', None)])]>

해당 블로그의 원문은 2026년 4월 23일 Google Cloud 블로그(영문)에 게재되었습니다.

AI 시대는 새로운 보안의 시대를 요구합니다. 조직들은 AI의 잠재력을 활용하는 동시에 악의적인 사용으로부터 방어해야 하는 이중의 과제에 직면해 있으며, Google Cloud는 여러분이 이러한 환경에 적응하고 성공적으로 나아갈 수 있도록 돕습니다.

Google Cloud의 최신 연구에 따르면, 위협 행위자들은 AI를 사용하여 공격의 속도, 규모 및 정교함을 가속화하고 있습니다. 한편, M-Trends 2026 보고서에 따르면, 위협 행위자 간의 공조가 심화됨에 따라 지난 3년 동안 초기 침투(initial access) 후 2차 위협 행위자에게 권한을 넘겨주는(hand-off) 데 걸리는 시간이 8시간에서 단 22초로 급격히 단축된 것으로 나타났습니다.

오늘 Google Cloud Next에서 우리는 Google Cloud가 기계의 속도로 점차 정교해지는 위협을 방어하고, AI 및 멀티클라우드 환경을 보호하며, 대규모 클라우드 워크로드의 보안을 확보하는 데 어떻게 도움을 줄 수 있는지 선보입니다.

에이전틱 방어 (Agentic defense) 제공

칩에서 모델에 이르는 Google의 풀스택(full-stack) AI 접근 방식은 고객을 보호하는 데 있어 더 나은 통합과 속도를 통해 경쟁 우위를 제공합니다. Google은 세계 최대 규모의 위협 관측소(threat observatory)와 Mandiant 일선 전문가들로부터 얻은 인사이트를 실행에 옮길 수 있을 뿐만 아니라, Google DeepMind의 최첨단 인사이트와 혁신 기술을 도입하여 고객의 플랫폼을 더욱 안전하게 만듭니다.

오늘 우리는 여러분이 AI의 속도로 방어할 수 있도록 돕는 Google Security Operations의 세 가지 새로운 에이전트를 소개합니다.

현재 프리뷰 버전으로 제공되는 위협 헌팅 에이전트(Threat Hunting agent)는 보안 팀이 기존의 방어 체계를 우회하는 새로운 공격 패턴과 은밀한 적대적 행위를 선제적으로 탐색(hunt)할 수 있도록 지원합니다.
현재 프리뷰 버전으로 제공되는 탐지 엔지니어링 에이전트(Detection Engineering agent)는 방어 범위의 공백(coverage gaps)을 식별하고 위협 시나리오에 대한 새로운 탐지 규칙을 생성하여, 수고(toil)를 덜고 수작업에 의존하던 탐지 생성을 자동화된 과학의 영역으로 전환합니다.
곧 프리뷰로 제공될 예정인 제3자 컨텍스트 에이전트(Third-Party Context agent)는 제3자 콘텐츠에서 얻은 컨텍스트(문맥) 데이터를 활용하여 분석 워크플로우를 더욱 풍부하게 지원합니다.

위협 헌팅 에이전트(Threat Hunting agent)를 활용한 위협 헌팅 개

당사의 분류 및 조사 에이전트(Triage and Investigation agent)는 지난 한 해 동안 500만 건 이상의 경고(alerts)를 처리했으며, 이는 일반적으로 수동으로 30분이 걸리던 분석 작업을 Gemini를 통해 60초로 단축했습니다.

BBVA의 보안 기술(Security Technology) 책임자인 디에고 마르티네스 블랑코(Diego Martinez Blanco)는 "운영의 탄력성과 사이버 보안은 BBVA 고객 신뢰의 근간입니다. 분류 및 조사 에이전트와 같은 첨단 인공지능을 통합함으로써 우리는 새로운 방식으로 확장할 수 있게 되었습니다."라고 말했습니다.

그는 또한 “이 에이전트는 초기 단계의 복잡하고 무거운 작업을 처리하고 오탐(false positives)을 걸러내 주기 때문에, 우리는 인간의 개입이 필요한 중요한 문제에 우선순위를 둘 수 있습니다. 에이전트의 투명한 설명 덕분에 우리 팀은 권장 사항을 명확히 이해하고, 궁극적으로 더 복잡한 조사에 자원을 집중할 수 있게 되었습니다.”라고 덧붙였습니다.

이제 정식 버전(GA)으로 제공되는 Google Security Operations용 원격 Google Cloud 모델 컨텍스트 프로토콜(MCP) 서버 지원을 통해 여러분만의 보안 에이전트를 구축할 수 있습니다. 이를 더욱 쉽게 활용할 수 있도록, 프리뷰 버전으로 제공되는 Google Security Operations 채팅 인터페이스에서 직접 MCP 서버 클라이언트에 액세스할 수도 있습니다.

Google Cloud의 에이전틱 방어(agentic defense)와 인텔리전스 주도의 AI 증강 보안 운영(AI-augmented security operations)을 활용하는 조직은 높은 투자 수익률(ROI)을 거둘 수 있습니다. Christopher Kissel
IDC 리서치 부문 부사장

위협 헌팅 에이전트(Threat Hunting agent)가 생성한 위협 헌팅 결과 보고서

보안 팀은 또한 Google Security Operations의 에이전틱 자동화(agentic automation)를 통해 대응 조치를 자동화할 수 있습니다. 팀을 수동 분류(triage) 방식에서 에이전틱 방어 체계로 더욱 발전시키기 위해, 현재 프리뷰 버전으로 제공되는 Google Threat Intelligence의 다크웹 인텔리전스(dark web intelligence)를 도입했습니다. 내부 테스트에 따르면, 이 기능은 매일 수백만 건의 외부 이벤트를 98%의 정확도로 분석하여 실제로 중요한 위협을 신속하게 파악할 수 있습니다.

IDC의 리서치 부문 부사장인 크리스토퍼 키셀(Christopher Kissel)은 "IDC 조사에 따르면 AI 기반의 컨텍스트 및 자동화를 도입한 조직들은 탐지 평균 시간(MTTD) 및 대응 평균 시간(MTTR)의 대폭적인 단축, 오탐지 감소, 분석가 생산성 향상 등 가시적인 운영 이점을 경험했습니다. 이러한 운영 개선은 중단 기간 단축, 사고 관련 비용 절감, 보안 태세 및 의사 결정에 대한 경영진의 신뢰 향상과 같은 실질적인 비즈니스 성과(business outcomes)로 이어집니다."라고 말하며, "Google Cloud의 에이전틱 방어를 통해 인텔리전스 주도의 AI 증강 보안 운영 방식을 활용하는 조직은 강력한 투자 수익률(ROI)을 거딜 수 있습니다."라고 강조했습니다.

Google Security Operations를 위한 새로운 파트너 지원 워크플로우

오늘 우리는 Google Security Operations를 위한 강력한 새로운 파트너 통합(new partner integrations) 코호트도 발표합니다. 즉시 사용 가능한(out of the box) 고충실도 보안 워크플로우를 제공하도록 설계된 Google Cloud 보안 통합 에코시스템의 최신 참여 파트너로는 Darktrace, Gigamon, SAP 등이 있습니다.

모든 인프라 환경에서 AI 및 클라우드 애플리케이션 보호

AI와 클라우드 애플리케이션은 다양한 플랫폼과 모델에 걸쳐 구축됩니다. 이를 엔드투엔드로 보호하기 위해, 당사는 고객이 애플리케이션을 어디서 어떻게 구축하든 관계없이 위험을 더 쉽고 빠르게 완화할 수 있도록 지원하고자 합니다. 이러한 지원에는 Amazon Web Services, Google Cloud, Microsoft Azure, Oracle Cloud와 같은 주요 클라우드 환경과 OpenAI와 같은 SaaS(서비스형 소프트웨어) 환경, 그리고 맞춤형 호스팅 환경까지 포함됩니다.

이제 Google Cloud의 일부가 된 Wiz는 고객이 구축하고 실행하는 앱을 보호하는 당사의 역량을 더욱 확장하고 심화시킵니다. Wiz는 고객이 AI를 빠르고 안전하게 도입할 수 있도록 지원하는 동시에, AI 개발 수명 주기를 보호하는 데 도움을 줍니다.

Wiz는 RSA 컨퍼런스에서 AI 애플리케이션 보호 플랫폼(AI-APP)을 발표하여 AI 애플리케이션에 대한 심층적인 가시성, 위험 태세 및 런타임 분석을 제공합니다. 또한, 기계의 속도로 위험과 위협을 식별하고 대응할 수 있도록 돕는 Wiz 보안 에이전트(Wiz Security Agents)와 Wiz 워크플로우(Wiz Workflows)도 함께 발표했습니다.

오늘 우리는 모든 클라우드, 플랫폼 및 AI 환경에서 고객을 안전하게 보호하겠다는 당사의 약속을 한 단계 더 발전시킵니다. 이제 Wiz는 Databricks를 지원할 뿐만 아니라 AWS Agentcore, Gemini Enterprise Agent Platform, Microsoft Azure Copilot Studio, Salesforce Agentforce와 같은 새로운 에이전트 스튜디오도 지원하여, 개발 팀이 어떤 방식을 선택하든 완벽한 가시성을 확보할 수 있게 되었습니다.

아울러 Wiz는 Google Cloud Apigee, Cloudflare AI Security for Apps, Vercel 플랫폼 등 클라우드의 외곽 계층(outer layer)까지 통합을 지원하여 보안 에코시스템을 지속적으로 뒷받침하며 Wiz 보안 그래프(Security Graph)의 강력한 성능을 더욱 확장하고 있습니다. 또한 분석가들이 자동 위협 정보 전달을 보다 쉽게 구성할 수 있도록 Wiz Defend의 보안 탐지 결과를 Google Security Operations 및 Mandiant Threat Defense와 통합하는 방식도 업데이트했습니다.

Wiz는 팀이 보다 빠르고 안전하게 혁신할 수 있도록 AI 네이티브 개발 수명 주기를 보호하기 위해 설계된 다음과 같은 새로운 기능들도 발표했습니다.

바이브 기반 코딩(vibe-coded) 애플리케이션 보호: Wiz는 5월에 정식 출시(GA)될 예정인 새로운 통합 기능을 발표합니다. 이 기능은 Lovable 플랫폼 내에서 직접 Wiz 보안 스캔을 실행하여 Wiz가 포착한 취약점, 보안 비밀(secrets) 및 잘못된 구성(misconfigurations)을 팀이 코드를 작성하는 Lovable의 내장 보안 뷰에 바로 표시해 줍니다.
AI 생성 코드 보호: Wiz는 AI가 생성한 코드가 생성되는 즉시 위험을 제거합니다. 인라인 AI 보안 훅(Inline AI security hooks)이 IDE 및 에이전트 워크플로우에 직접 통합되어 프롬프트를 평가하고 AI 생성 결과물을 즉시 스캔함으로써, 코드가 커밋되기 전에 보안 가드레일을 주입합니다.
에이전트 기반 조치(Agent-based remediation): Wiz Skills는 코딩 에이전트와 AI 네이티브 IDE에 완전한 코드-투-클라우드(code-to-cloud) 컨텍스트와 Wiz 보안 그래프에서 검증된 공격 표면(attack surface) 결과를 제공합니다. 이러한 기능을 통해 팀은 개발자의 개별 IDE에서 로컬로, 또는 버전 관리 시스템 내의 리포지토리 및 풀 리퀘스트(pull request) 수준에서 전역적으로 자동화된 에이전트 주도의 조치 워크플로우를 트리거할 수 있습니다.
섀도우 AI(shadow AI) 제거: Wiz의 동적인 AI 소프트웨어 자재 명세서(AI-BOM)는 환경 내의 모든 AI 프레임워크, 모델 및 IDE 확장 프로그램을 자동으로 인벤토리화합니다. 이를 통해 스택 전반에서 무엇이 코드를 작성하고 있는지에 대한 완벽한 가시성을 제공하며, Gemini Code Assist 및 GitHub Copilot과 같이 승인된 기업용 도구를 추적하는 동시에 승인되지 않은 섀도우 AI 플러그인을 발견할 수 있게 해줍니다.

Wiz 발표 내용에 대한 자세한 정보는 여기에서 확인하실 수 있습니다.

에이전트 및 에이전틱 웹(agentic web) 보안

클라우드 및 AI 워크로드를 보호하는 것 외에도, Google Cloud의 보안 내재화(secure-by-design) 기반은 에이전트부터 사기 방지, 웹에 이르기까지 AI의 속도로 혁신할 수 있도록 지원합니다.

Gemini Enterprise Agent Platform을 통한 에이전트 보안 및 거버넌스에이전트를 구축, 오케스트레이션, 관리 및 최적화하기 위해 오늘 우리는 다음이 포함된 Gemini Enterprise Agent Platform을 발표합니다.

액세스 관리 및 대규모 AI 거버넌스를 가능하게 하는 에이전트 ID(Agent Identity). 당사의 이 새로운 기능은 에이전트가 제한된 범위의 인적 위임(human delegation)과 특정 인증 흐름을 가지고 자율적으로 작동할 수 있도록 고유한 ID를 제공합니다.
모든 에이전트-대-에이전트(agent-to-agent) 및 에이전트-대-도구(agent-to-tool) 연결에 대한 정책 적용을 가능하게 하는 에이전트 게이트웨이(Agent Gateway). 이 기능은 엔터프라이즈 에이전트 트래픽을 관리하고 MCP 및 A2A(Agent2Agent)와 같은 에이전트 프로토콜을 이해하여 모든 에이전트 상호 작용을 검사하고 보호합니다.
모델 및 에이전트 상호 작용을 위한 런타임 보호 기능인 모델 아머(Model Armor)는 이제 에이전트 게이트웨이, 프리뷰로 제공되는 에이전트 런타임 및 Langchain, 그리고 정식 버전(GA)으로 제공되는 Firebase와 통합되어, 개발자가 코드를 변경할 필요 없이 에이전트 트래픽 및 상호 작용에 인라인 검증 및 무해화(sanitization)를 추가할 수 있도록 지원합니다. 이러한 통합은 Google Cloud 서비스 및 당사의 AI 포트폴리오 전반에서 프롬프트 인젝션, 도구 포이즈닝, 민감한 데이터 유출과 같은 런타임 위험에 대한 Model Armor의 보호 기능을 확장합니다.

Google Cloud 사기 방지 및 Chrome Enterprise를 통한 에이전틱 웹 보호오늘 우리는 정식 출시(GA)된 Google Cloud 사기 방지(Google Cloud Fraud Defense) 출시와 함께 reCAPTCHA를 진화시키고 있습니다. 이 포괄적인 플랫폼은 봇, 사람, 에이전트의 정당성과 권한을 식별하도록 설계되었습니다. Google 자체 생태계를 보호하는 것과 동일한 규모와 신호(signals)를 사용하는 사기 방지 기능은 인간 사용자와 AI 에이전트를 위한 에이전트 전용 기능을 곧 프리뷰로 제공할 예정이며, 이를 통해 계정 생성 및 로그인부터 결제 및 체크아웃에 이르는 디지털 상거래 여정을 안전하게 보호할 수 있습니다.

AI를 보호하려는 당사의 의지는 AI와 상호 작용하기 위한 핵심 엔드포인트인 브라우저까지 확장됩니다. Chrome Enterprise는 기업 데이터의 타협 없이 안전하게 AI를 수용하는 데 필요한 가시성과 제어 기능을 갖춘 AI 시대를 위한 포괄적인 데이터 보호를 제공합니다.

현재 프리뷰로 제공되는 AI 인식 확장 프로그램 위협 탐지(AI-aware extension threat detections)는 보안 팀이 비정상적인 AI 에이전트 활동을 탐지하고 대응하는 데 도움이 되는 고급 확장 프로그램 원격 분석 데이터(telemetry)를 표시할 수 있습니다.
곧 정식 출시될 새로운 섀도우 AI 리포팅(shadow AI reporting) 기능은 직원이 승인되지 않은 웹 기반 AI 및 SaaS 애플리케이션을 사용하는 것을 경고(flagging)하여 섀도우 AI 환경에 대한 가시성을 확보하는 데 도움을 줍니다.

신뢰할 수 있는 클라우드 (Trusted Cloud)의 새로운 소식

우리는 고객이 환경을 안전하게 보호할 수 있도록 클라우드 플랫폼의 ID, 데이터, 네트워크 전반에 걸쳐 지속적으로 새로운 보안 제어 기능을 제공하고 역량을 강화하고 있습니다. 오늘 발표하는 업데이트는 다음과 같습니다.

최신 IAM을 통한 권한 간소화최소 권한(least privilege) 원칙을 빠르고 간단하게 달성할 수 있도록, 당사는 IAM 역할 선택기(IAM role picker) 및 민감한 작업 재인증 기능과 같이 사용하기 쉬운 관리자, 편집자, 뷰어 역할을 통해 사전 정의된 역할 카탈로그를 간소화했습니다.

데이터 보안 (Data security)가장 민감한 데이터를 보호하고 AI 혁신을 가속화하기 위해 클라우드 플랫폼 데이터 보안 포트폴리오의 몇 가지 새로운 기능을 발표합니다.

컨피덴셜 컴퓨팅 (Confidential Computing): 오늘 파트너사인 NVIDIA와 함께 전 세계 프리뷰로 제공되는 Google Compute Engine(GCE) Confidential G4 VM에 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU를 탑재한 G4 VM을 위한 컨피덴셜 컴퓨팅(Confidential Computing) 지원을 발표하여, 광범위한 민감한 AI 워크로드의 기밀성과 무결성을 강화합니다. 또한 Intel 파트너십을 통해 6세대 Xeon 프로세서에 Intel TDX를 도입한 C4 Confidential VM의 프리뷰를 소개합니다. 이는 다양하고 복잡한 AI 및 분석 워크로드를 보호하는 동시에 업계 최고의 컴퓨팅 밀도와 성능을 제공합니다.
Cloud KMS (키 관리 서비스): 프리뷰로 제공되는 새로운 기밀 외부 키 관리자(Confidential External Key Manager, cEKM)를 발표합니다. 이를 통해 모든 리전에서 외부 키를 유연하게 호스팅 및 보호하고, 기밀 환경 내에서 검증 가능한 제어 권한을 유지할 수 있습니다.
양자 내성 암호 (Post-quantum cryptography, PQC): 양자 내성 알고리즘을 적용하여 자체 키(BYOK)를 가져올 수 있도록 지원하는 KMS 양자 안전 키 가져오기(KMS Quantum Safe Key Imports) 기능을 프리뷰로 도입합니다.
보안 비밀 관리자 (Secret Manager): 비밀번호 유출을 방지하고 프롬프트 인젝션 위험을 완화하기 위해 당사의 Secret Manager와 에이전트 개발 키트(Agent Development Kit)의 네이티브 통합을 정식 버전(GA)으로 출시합니다.

네트워크 보안 (Network security) Google Cloud의 교차 클라우드(Cross-Cloud) 네트워크 보안 제품은 몇 가지 새로운 기능을 제공합니다.

Cloud NGFW: 고도로 회피적인 제로데이 위협에 대한 방어를 지원하기 위해 올해 말 프리뷰로 제공될 예정인 Cloud NGFW 고급 맬웨어 샌드박스(advanced malware sandbox)를 발표합니다. 이 기능은 70,000명 이상의 Palo Alto Networks 고객의 데이터를 기반으로 학습하여 알려진 및 알려지지 않은 맬웨어의 99%를 차단하는 Palo Alto Networks Advanced Wildfire 기술을 기반으로 합니다.
Cloud Armor: Layer 7 애플리케이션 공격 및 제로데이 CVE(React2Shell 등)를 탐지하기 위해 Thales Imperva를 기반으로 작동하며 프리뷰로 제공되는 새로운 Cloud Armor 관리형 규칙(managed rules)을 출시했습니다.

SCC를 통한 Google Cloud 보안 고도화Google 클라우드 네이티브 보안 솔루션인 Security Command Center(SCC)는 Google Cloud상의 기존 애플리케이션과 AI 애플리케이션을 모두 보호하기 위한 클라우드 보안 기준(baseline)을 확립합니다.

지속적인 탐색(discovery) 및 포괄적인 위험 분석을 제공하여 위협, 취약점 및 잘못된 구성을 식별함으로써 AI 에이전트, 모델 및 MCP 서버를 안전하게 보호합니다.
SCC는 깊이 있는 런타임 가시성을 추가하여 Google Cloud 워크로드에 대한 섀도우 AI를 찾아냅니다. 곧 프리뷰로 제공될 예정인 SCC는 에이전트, Cloud Run이나 GKE에서 호스팅되는 MCP 서버, GKE에서 실행되는 추론 엔드포인트 등 관리되지 않는 에이전틱 워크로드를 자동으로 검색하고 이를 SCC의 태세(posture) 위협 탐지 결과로 표시합니다.
향상된 기능의 Security Command Center Standard 계층은 데이터 보안 태세 관리, 규정 준수, 취약점 관리 및 위험 분석을 제공하여 모든 Google Cloud 고객이 추가 비용 없이 도입 초기부터 강력한 보안, 규정 준수 및 위험 관리 범위를 확립할 수 있도록 지원합니다.

다음 단계로 나아가기

Google을 보안 팀의 일원으로 맞이하면 인텔리전스 중심의 AI 네이티브 방어력, 보안이 내재화(secure-by-design)된 개방형 클라우드의 자유, 그리고 조직의 확장이 되어줄 업계에서 가장 실전 경험이 풍부한 전문가들의 힘을 얻을 수 있습니다.

이러한 새로운 혁신 기술과 다가올 위협으로부터 안전하게 대비하는 방법에 대한 자세한 내용은 보안 스포트라이트(security spotlight) 세션을 시청해 확인해 보시기 바랍니다. 아울러 라이브 및 온디맨드 형태로 제공되는 다양하고 훌륭한 보안 세션(breakout sessions)들을 확인하여 Next '26의 모든 주요 발표 내용에 대해 자세히 알아보십시오.

IP를 넘어 URL까지: Google Cloud NGFW로 웹 보안의 차원을 높이세요.

Tue, 07 Apr 2026 17:30:00 +0000

해당 블로그의 원문은 2026년 4월 8일 Google Cloud 블로그(영문)에 게재되었습니다.

클라우드 퍼스트(Cloud-first) 환경에서 기존의 IP 기반 방어 체계만으로는 더 이상 보안 경계(Perimeter)를 완벽히 보호할 수 없습니다. 서비스가 공유 인프라 및 콘텐츠 전송 네트워크(CDN)로 마이그레이션됨에 따라, 정적 IP 주소와 FQDN(정규화된 도메인 이름)에만 의존하는 방식은 보안 사각지대(Security gaps)를 발생시킬 수 있습니다.

단일 IP 주소가 여러 서비스를 호스팅할 수 있고 IP 주소 자체가 빈번하게 변경되는 환경을 고려하여, Cloud 차세대 방화벽(NGFW) Enterprise에 와일드카드(wildcard) 기능을 갖춘 도메인 필터링을 새롭게 도입합니다. 이 새로운 기능은 한층 강화된 보안과 세분화된 정책 제어(Granular policy controls)를 제공합니다.

도메인 및 SNI 필터링이 중요한 이유

Cloud NGFW URL 필터링 서비스는 퍼블릭 및 내부 네트워크에서 발생하는 위협으로부터 워크로드를 안전하게 보호하기 위해 HTTP 페이로드에 대한 심층 패킷 검사(Deep Inspection)를 수행합니다. 이 서비스는 보안 제어를 애플리케이션 계층(Application Layer)으로 격상시키며, 악성 도메인에 대한 액세스를 효과적으로 제한합니다.

주요 사용 사례는 다음과 같습니다.

세분화된 이그레스 제어 (Granular egress control): 이 기능은 이그레스(아웃바운드) HTTP(S) 메시지에서 발견된 도메인 이름 및 SNI 정보를 기반으로 연결을 정밀하게 허용하거나 차단할 수 있도록 지원합니다. 레이어 7(L7) 헤더를 검사함으로써, 단일 IP가 여러 서비스를 호스팅할 때 비효율적인 기존의 IP 주소 및 FQDN 기반 필터링보다 훨씬 더 세밀한 제어력을 제공합니다.
복호화 없는 액세스 제어 (Control access without decrypting): 트래픽에 대한 전체 TLS 복호화(Decryption)를 수행하지 않으려는 조직의 경우에도, Cloud NGFW는 TLS 핸드셰이크 과정에서 제공되는 SNI 헤더를 기반으로 트래픽을 제어하여 보안 정책을 강제할 수 있습니다. 이를 통해 개인정보 보호 또는 규정 준수(Compliance) 목적으로 엔드투엔드(End-to-End) 암호화를 유지하면서도 효과적인 도메인 수준의 필터링이 가능해집니다.
운영 오버헤드 감소 (Reduced operational overhead): 도메인 기반 필터링을 구현하면 자주 변경되는 IP 주소 및 DNS 레코드를 추적하기 위해 소요되는 지속적인 유지보수 작업을 줄일 수 있습니다. 동적인 네트워크 속성 대신 안정적인 도메인 식별자에 집중함으로써, 보안 팀은 방화벽 룰베이스(Rulebases)를 업데이트하는 데 드는 수동 작업을 최소화할 수 있습니다.
유연한 매칭 (Flexible matching): 이 서비스는 URL 목록 내의 매처(Matcher) 문자열을 활용하며, 도메인 및 하위 도메인에 대한 기준을 정의하기 위해 제한된 와일드카드 도메인을 지원합니다. 예를 들어 *.example.com과 같은 와일드카드를 사용하면 단일 필터로 관련된 모든 하위 도메인을 포괄할 수 있어, 수천 개의 개별 FQDN 항목을 일일이 정의하는 것보다 훨씬 확장성(Scalable) 있는 솔루션을 제공합니다.
보안 강화 (Improved security): URL 필터링은 SNI 헤더 스푸핑(Spoofing)과 같은 정교한 공격 기법으로부터 시스템을 보호하여 전반적인 보안 태세(Security Posture)를 크게 향상시킵니다. 애플리케이션에 대한 액세스를 허용하기 전에 L7 헤더를 평가함으로써, Cloud NGFW는 공격자가 하위 레이어의 식별자를 단순 스푸핑하여 보안 통제를 우회하는 것을 원천적으로 차단합니다.

Cloud NGFW URL 필터링 작동 방식

URL 필터링 서비스는 분산형 아키텍처(Distributed Architecture)를 사용하여 L7에서 트래픽을 검사하는 방식으로 작동합니다.

Cloud NGFW URL 필터링 서비스

세 가지 간단한 단계만으로 URL 필터링을 시작할 수 있습니다.

Cloud NGFW 엔드포인트 배포:
1. 첫 번째 단계는 특정 영역(Zone)에 Cloud NGFW 엔드포인트를 생성하고 배포하는 것입니다. NGFW 엔드포인트는 조직 수준의 리소스입니다. 배포하기 전에 적절한 권한을 보유하고 있는지 확인하십시오.
2. 엔드포인트가 배포되면 원하는 하나 이상의 VPC에 연결(associate)할 수 있습니다.
보안 프로필 및 보안 프로필 그룹 생성:
1. URL 필터링 보안 프로필은 매처(Matcher) 문자열이 포함된 URL 필터와 그에 따른 작업(허용 또는 거부)을 정의합니다.
2. 보안 프로필 그룹은 이러한 보안 프로필들을 담는 컨테이너 역할을 하며, 방화벽 정책 규칙에서 이를 참조합니다. 원하는 URL, 와일드카드 FQDN을 사용하여 URL 필터링 보안 프로필을 생성하고 이를 보안 프로필 그룹에 추가하십시오.
3. 보안 프로필 그룹이 생성되면, 방화벽 정책에서 해당 보안 프로필 그룹을 참조해야 합니다.
정책 강제 적용 (Policy enforcement):
1. apply_security_profile_group 작업을 사용하는 계층적(Hierarchical) 또는 글로벌 네트워크 방화벽 정책 규칙을 구성하고 보안 프로필 그룹의 이름을 지정하여 서비스를 활성화합니다.

방화벽 정책 규칙 구성에 대한 자세한 내용은 다음을 참조하십시오.

시작하기

Cloud NGFW URL 필터링을 시작하려면 문서 및 코드랩(Codelab)을 확인해 보시기 바랍니다.

CVE-2025-55182 보안 취약점, 당신의 React와 Next.js 프로젝트를 직접 겨냥합니다.

Wed, 03 Dec 2025 23:00:00 +0000

해당 블로그의 원문은 2025년 12월 4일 Google Cloud 블로그(영문)에 게재되었습니다.

편집자 주

2025년 12월 7일 오후 9시 10분 (PDT) 업데이트: CVE-2025-55182 악용 시도를 완화하는 데 도움이 되도록 추가 ruleID를 포함하여 권장되는 Cloud Armor WAF 구문을 업데이트했습니다.
2025년 12월 5일 오후 12시 40분 (PDT) 업데이트: CVE-2025-55182의 악용 시도를 탐지하고 완화하는 데 도움이 되도록 Cloud Armor WAF 규칙의 권장 구문을 업데이트했습니다.
2025년 12월 4일 오후 9시 20분 (PDT) 업데이트: React Server Components 및 Next.js의 취약한 버전 목록을 수정하고 Cloud Armor에 대한 구성 가이드를 업데이트했습니다.

오늘 Meta와 Vercel은 널리 사용되는 오픈소스 프레임워크인 React Server Components(CVE-2025-55182) 및 Next.js를 사용하여 구축된 서비스가 일부 서버 측 사용 사례에서 원격 코드 실행 위험에 노출되는 두 가지 취약점을 공개했습니다. Google Cloud는 이러한 취약점의 심각성을 인지하고 있으며, Google의 보안팀은 고객이 애플리케이션 보안을 위해 즉각적이고 결정적인 조치를 취하는 데 도움이 될 권장 사항을 공유했습니다.

취약점 배경

React Server Components 프레임워크는 일반적으로 사용자 인터페이스를 구축하는 데 사용됩니다. 2025년 12월 3일, CVE.org는 이 취약점에 CVE-2025-55182를 할당했습니다. 공식 공통 취약점 등급 시스템(CVSS) 기본 심각도 점수는 10.0점 만점인 '심각(Critical)'으로 결정되었습니다.

취약한 버전: React 19.0, 19.1.0, 19.1.1, 19.2.0
패치된 버전: React 19.2.1
수정 사항(Fix): https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700
공지: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Next.js는 React에 의존하는 웹 개발 프레임워크이며, 역시 사용자 인터페이스 구축에 널리 사용됩니다. (Next.js 취약점은 중복으로 표시되기 전 CVE-2025-66478로 참조되었습니다.)

취약한 버전: Next.js 15.x, Next.js 16.x, Next.js 14.3.0-canary.77 및 이후 canary 릴리스
패치된 버전은 여기에 나열되어 있습니다.
수정 사항(Fix): https://github.com/vercel/next.js/commit/6ef90ef49fd32171150b6f81d14708aa54cd07b2
공지: https://nextjs.org/blog/CVE-2025-66478

React 및 Next.js 프레임워크를 사용하는 환경을 관리하는 조직은 최신 버전으로 업데이트하고 아래에 설명된 완화 조치를 취할 것을 강력히 권장합니다.

CVE-2025-55182 완화 조치

Google은 CVE-2025-55182와 관련된 악용 시도를 탐지하고 차단하도록 설계된 새로운 Cloud Armor 웹 애플리케이션 방화벽(WAF) 규칙을 만들어 배포했습니다. 이 새로운 규칙은 지금 바로 사용 가능하며, 전역 또는 리전별 애플리케이션 부하 분산기를 사용하는 인터넷 연결 애플리케이션 및 서비스를 보호하기 위한 것입니다. 조직의 취약점 관리 프로그램이 환경 내의 모든 취약한 인스턴스를 패치하고 검증하는 동안, 이 규칙을 임시 완화 조치로 배포하는 것을 권장합니다.

Firebase Hosting 또는 Firebase App Hosting을 사용하는 고객의 경우, 커스텀 및 기본 도메인으로의 요청을 통한 CVE-2025-55182 악용을 제한하는 규칙이 이미 적용되어 있습니다. 그 외 모든 워크로드는 영향을 받는 패키지에 대해 고객의 조치와 패치가 필요합니다.

Project Shield 사용자의 경우, 모든 사이트에 WAF 보호 기능을 배포하기 위해 노력하고 있으며 이러한 WAF 규칙을 활성화하기 위한 별도의 조치는 필요하지 않습니다. 장기적인 완화를 위해서는 취약점을 근본적으로 제거하기 위한 필수 단계로 오리진 서버를 패치해야 합니다(아래 추가 지침 참조).

Cloud Armor와 애플리케이션 부하 분산기는 애플리케이션과 서비스가 Google Cloud, 온프레미스 또는 다른 인프라 제공업체 중 어디에 배포되었는지에 관계없이 이를 제공하고 보호하는 데 사용될 수 있습니다. 아직 Cloud Armor와 애플리케이션 부하 분산기를 사용하고 있지 않다면, 아래의 시작하기 가이드를 참조하세요.

Cloud Armor용 cve-canary WAF 규칙 배포하기

CVE-2025-55182로부터 탐지하고 보호하도록 Cloud Armor를 구성하려면, 이 취약점을 위해 추가된 새로운 ruleID를 활용하는 cve-canary 사전 구성된 WAF 규칙을 사용할 수 있습니다.

Cloud Armor 백엔드 보안 정책에서 새 규칙을 만들고 다음 일치 조건을 구성합니다.

code_block: <ListValue: [StructValue([('code', "(has(request.headers['next-action']) || has(request.headers['rsc-action-id']) || request.headers['content-type'].contains('multipart/form-data') || request.headers['content-type'].contains('application/x-www-form-urlencoded')) && evaluatePreconfiguredWaf('cve-canary',{'sensitivity': 0, 'opt_in_rule_ids': ['google-mrs-v202512-id000001-rce','google-mrs-v202512-id000002-rce']})"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6639b3c290>)])]>

이 작업은 Google Cloud 콘솔에서 Cloud Armor로 이동한 후, 기존 정책을 수정하거나 새 정책을 생성하여 수행할 수 있습니다.

Google Cloud 콘솔에서 Cloud Armor 규칙 생성

또는, gcloud CLI를 사용하여 필요한 규칙이 포함된 정책을 생성하거나 수정할 수도 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud compute security-policies rules create PRIORITY_NUMBER \\\r\n --security-policy SECURITY_POLICY_NAME \\\r\n --expression "(has(request.headers[\'next-action\']) || has(request.headers[\'rsc-action-id\']) || request.headers[\'content-type\'].contains(\'multipart/form-data\') || request.headers[\'content-type\'].contains(\'application/x-www-form-urlencoded\')) && evaluatePreconfiguredWaf(\'cve-canary\',{\'sensitivity\': 0, \'opt_in_rule_ids\': [\'google-mrs-v202512-id000001-rce\',\'google-mrs-v202512-id000002-rce\']})" \\\r\n --action=deny-403'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a435850>)])]>

Terraform으로 규칙을 관리하고 있다면, 아래 구문을 사용하여 규칙을 적용할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'rule {\r\n action = "deny(403)"\r\n priority = "PRIORITY_NUMBER"\r\n match {\r\n expr {\r\n expression = "(has(request.headers[\'next-action\']) || has(request.headers[\'rsc-action-id\']) || request.headers[\'content-type\'].contains(\'multipart/form-data\') || request.headers[\'content-type\'].contains(\'application/x-www-form-urlencoded\')) && evaluatePreconfiguredWaf(\'cve-canary\',{\'sensitivity\': 0, \'opt_in_rule_ids\': [\'google-mrs-v202512-id000001-rce\',\'google-mrs-v202512-id000002-rce\']})"\r\n }\r\n }\r\n description = "Applies protection for CVE-2025-55182 (React/Next.JS)"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6639c2ea90>)])]>

애플리케이션을 위한 WAF 규칙 안전성 검증 및 원격 분석 활용

Cloud Armor 규칙은 Cloud Armor가 구성된 작업을 강제로 실행하지 않고, 규칙의 예상 영향을 테스트하거나 모니터링할 수 있는 로깅 전용 모드인 미리보기 모드(preview mode)로 구성할 수 있습니다. 위에서 설명한 새 규칙을 프로덕션 환경에 먼저 미리보기 모드로 배포하여 어떤 트래픽이 차단될지 확인하는 것을 권장합니다.

환경에서 새 규칙이 예상대로 작동하는지 확인한 후에는 미리보기 모드를 비활성화하여 Cloud Armor가 규칙을 능동적으로 적용하도록 할 수 있습니다.

Cloud Armor의 요청별 WAF 로그는 애플리케이션 부하 분산기 로그의 일부로 Cloud Logging에 기록됩니다. 모든 요청에 대한 Cloud Armor의 결정을 확인하려면, 먼저 백엔드 서비스별로 부하 분산기 로깅을 활성화해야 합니다. 활성화되면 이후의 모든 Cloud Armor 결정이 기록되며, 다음 안내에 따라 Cloud Logging에서 해당 내용을 찾을 수 있습니다.

Cloud Armor 규칙과 취약점 스캐닝 도구의 상호 작용

사용자 환경에서 React 및 Next.js의 취약한 인스턴스를 식별하는 데 도움이 되도록 설계된 스캐닝 도구가 급증했습니다. 이러한 스캐너 중 다수는 서버에서 실행 중인 React 및 Next.js의 버전을 탐지하기 위해 합법적인 쿼리를 작성하고 서버의 응답을 검사하여 관련 프레임워크의 버전 번호를 식별하도록 설계되었습니다.

Google의 WAF 규칙은 CVE-2025-55182의 악용 시도를 탐지하고 방지하도록 설계되었습니다. 위에서 설명한 스캐너는 악용을 시도하는 것이 아니라, 소프트웨어 버전 정보를 나타내는 응답을 유도하기 위해 안전한 쿼리를 보내므로, 위의 Cloud Armor 규칙은 이러한 스캐너를 탐지하거나 차단하지 않습니다.

만약 이러한 스캐너의 결과가 Cloud Armor로 보호되는 소프트웨어의 취약한 인스턴스를 나타낸다고 해서, 해당 취약점에 대한 실제 악용 시도가 Cloud Armor 보안 정책을 성공적으로 통과한다는 의미는 아닙니다. 대신, 이러한 결과는 탐지된 React 또는 Next.js 버전이 취약한 것으로 알려져 있으므로 패치해야 함을 의미합니다.

신규 사용자를 위한 Cloud Armor 시작 가이드

워크로드가 이미 애플리케이션 부하 분산기를 사용하여 인터넷에서 트래픽을 받고 있다면, 다음 안내에 따라 Cloud Armor를 구성하여 이 취약점 및 기타 애플리케이션 수준의 취약점(DDoS 공격 포함)으로부터 워크로드를 보호할 수 있습니다.

아직 애플리케이션 부하 분산기와 Cloud Armor를 사용하고 있지 않다면, 외부 애플리케이션 부하 분산기 개요, Cloud Armor 개요, Cloud Armor 권장사항을 참조하여 시작할 수 있습니다.

워크로드가 Cloud Run, Cloud Run functions 또는 App Engine을 사용하고 인터넷에서 트래픽을 받는 경우, 먼저 엔드포인트 앞에 애플리케이션 부하 분산기를 설정해야 Cloud Armor 보안 정책을 활용하여 워크로드를 보호할 수 있습니다. 그런 다음 Cloud Armor와 애플리케이션 부하 분산기가 우회되지 않도록 적절한 제어를 구성해야 합니다.

권장사항 및 추가 위험 완화 조치

Cloud Armor를 구성한 후에는 Google의 권장사항 가이드를 참조하는 것이 좋습니다. 문서에 설명된 제한사항을 반드시 고려하여 워크로드의 안전과 가용성을 보장하면서 위험을 최소화하고 성능을 최적화하세요.

장기적 완화 조치: 필수 프레임워크 업데이트 및 재배포

WAF 규칙이 중요한 최전선 방어를 제공하지만, 가장 포괄적인 장기 해결책은 기본 프레임워크를 패치하는 것입니다.

Google Cloud에서 React 및 Next.js 애플리케이션을 실행하는 모든 고객은 즉시 종속성을 최신 안정 버전(React 19.2.1 또는 여기에 나열된 관련 Next.js 버전)으로 업데이트하고 서비스를 재배포할 것을 강력히 촉구합니다.

이는 특히 다음에 배포된 애플리케이션에 적용됩니다.

Cloud Run, Cloud Run functions 또는 App Engine: 애플리케이션 종속성을 업데이트된 프레임워크 버전으로 업데이트하고 재배포하세요.
Google Kubernetes Engine (GKE): 컨테이너 이미지를 최신 프레임워크 버전으로 업데이트하고 파드를 재배포하세요.
Compute Engine: Google Cloud에서 제공하는 공개 OS 이미지에는 기본적으로 React 또는 Next.js 패키지가 설치되어 있지 않습니다. 영향을 받는 패키지가 포함된 커스텀 OS를 설치한 경우, 최신 프레임워크 버전을 포함하도록 워크로드를 업데이트하고 모든 워크로드 앞에 WAF 규칙을 활성화하세요.
Firebase: Cloud Functions for Firebase, Firebase Hosting 또는 Firebase App Hosting을 사용하는 경우, 애플리케이션 종속성을 업데이트된 프레임워크 버전으로 업데이트하고 재배포하세요. Firebase Hosting 및 App Hosting은 또한 커스텀 및 기본 도메인으로의 요청을 통한 CVE-2025-55182 악용을 제한하는 규칙을 자동으로 적용하고 있습니다.

애플리케이션을 패치하는 것은 근본 원인에서 취약점을 제거하고 서비스의 지속적인 무결성과 보안을 보장하기 위한 필수적인 단계입니다.

Google은 상황을 계속 면밀히 모니터링하고 필요에 따라 추가 업데이트와 지침을 제공할 것입니다. 가장 최신 정보와 자세한 단계는 공식 Google Cloud 보안 권고 사항을를 참조해 주십시오.

엔터프라이즈 생성형 AI를 위한 보안 구성: Private Service Connect와 VPC Service Controls을 사용하여 Gemini API 비공개 접근 구성하기

Mon, 01 Dec 2025 17:00:00 +0000

Google Cloud의 완전 관리형 AI 플랫폼인 Vertex AI는 개발자가 Gemini와 같은 최신 파운데이션 모델을 활용하여 엔터프라이즈급 생성형 AI 애플리케이션을 구축할 수 있도록 지원합니다. 기업들은 Vertex AI Model Garden에서 제공하는 다양한 모델을 자사의 데이터로 안전하게 미세 조정(fine-tuning)하고, 이를 애플리케이션에 통합하여 새로운 가치를 창출하고 있습니다.

Google Cloud Vertex AI서비스는 온프레미스 또는 멀티 클라우드 환경에서 Vertex AI 리소스에 안전하게 액세스하게 도움을 주는 네트워킹 옵션을 제공합니다. Private Service Connect(PSC)와 VPC Service Controls(VPC-SC)를 활용한 강력한 보안 구성을 제공합니다. PSC를 사용하면 고객의 VPC 네트워크와 Vertex AI 서비스 간에 전용 비공개 연결을 설정할 수 있어, 퍼블릭 IP를 사용하지 않아도 엔터프라이즈 내부 리소스나 온프레미스 환경에서 안전하게 API에 접근할 수 있습니다. 아울러 VPC-SC는 퍼블릭 엔드포인트로 접근하는 시도나 비인가 접근을 맥락(Context)기반으로 통제할 수 있습니다.

이 블로그에서는 PSC 기반의 VPC 엔드포인트를 통해 Gemini를 비롯한 Vertex AI API에 대한 비공개 액세스 경로를 확보하고, VPC-SC를 통해 공개 액세스를 원천 차단하여 생성형 AI 애플리케이션을 위한 안전한 심층 방어(Defense-in-Depth) 아키텍처를 구축하는 방법을 설명합니다.

워크플로 예시

제안하는 보안 아키텍처의 데이터 흐름은 다음과 같습니다.

요청 수신: Cloud Run에서 실행 중인 애플리케이션 서비스가 사용자로부터 프롬프트 요청을 수신합니다. 이때 Cloud Run 서비스가 PSC 엔드포인트나 VPC 내 자원으로 비공개 통신을 하게 하기 위해서는 Direct VPC egress나 Serverless VPC connection같은 Cloud Run 비공개 구성이 필요합니다.
컨텍스트 보강: 애플리케이션은 Cloud SQL과 같은 내부 데이터베이스를 호출하여 프롬프트에 필요한 기업 데이터(예: 제품 정보, 고객 이력)를 보강합니다.
비공개 API 호출: 보강된 데이터를 포함하여 Vertex AI API를 호출합니다. 이때 API 요청은 퍼블릭 인터넷이 아닌, VPC 내에 구성된 PSC 엔드포인트로 라우팅됩니다.
안전한 처리: PSC 엔드포인트는 이 요청을 Google 내부 네트워크를 통해 Vertex AI 서비스로 안전하게 전달하며, 처리된 결과 역시 동일한 비공개 경로를 통해 반환됩니다.
보안 경계 적용: VPC-SC는 서비스 주변에 논리적인 보안 경계(Perimeter)를 형성합니다. 이를 통해 승인되지 않은 외부 네트워크나 프로젝트에서 시도하는 Vertex AI API 호출을 차단하여 데이터 유출을 방지합니다.
하이브리드 연결: Cloud Interconnect 또는 Cloud VPN으로 연결된 온프레미스 네트워크에서도 VPC 내의 PSC 엔드포인트를 경유하여 Vertex AI API에 안전하게 접근할 수 있습니다.

Google API용 Private Service Connect (PSC) 솔루션 개요 및 구성

Gemini 모델을 활용한 애플리케이션을 개발할 때, 개발자는 데이터 트래픽이 퍼블릭 인터넷을 경유하는 것을 원치 않을 수 있습니다. Google API용 Private Service Connect는 이러한 요구를 충족시키는 핵심 네트워킹 기능입니다.

PSC를 사용하면 VPC 내부에 비공개 IP를 가진 전역 엔드포인트를 생성하여 Google API에 비공개로 액세스할 수 있습니다. 이는 클라우드 내부의 리소스뿐만 아니라, VPN이나 Interconnect로 연결된 하이브리드 환경의 온프레미스 애플리케이션에서도 퍼블릭 인터넷을 거치지 않고 Google API를 호출할 수 있게 해 줍니다.

대부분의 Google API는 기본적으로 <API NAME>.googleapis.com 도메인을 사용합니다. PSC를 구성하면 <API>-<PSC-ENDPOINT-NAME>.p.googleapis.com 형태의 새로운 도메인을 사용할 수 있게 되며, DNS 설정을 통해 특정 PSC 엔드포인트를 경유하도록 트래픽을 제어할 수 있습니다. 일반적인 엔터프라이즈 보안 패턴은 PSC를 통한 비공개 경로는 허용하되, VPC-SC를 통해 퍼블릭 엔드포인트 접근은 차단하는 것입니다. Gemini API 역시 Vertex AI 제품군의 일부로, Google API용 PSC를 통해 비공개 액세스가 지원됩니다.

PSC 엔드포인트 구성 단계

Google API용 PSC 엔드포인트를 생성하기 위해서는 먼저 예약된 내부 IP 주소가 필요합니다.

1. PSC 전용 전역 IP 주소 예약

Google API용 PSC 엔드포인트는 리전 VPC 서브넷에 없는 전역 IP 주소에서 생성됩니다. 전역 IP 주소는 PRIVATE_SERVICE_CONNECT 목적으로 특별히 예약되어야 합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud compute addresses create psc-ip \\\r\n --global \\\r\n --purpose=PRIVATE_SERVICE_CONNECT \\\r\n --addresses=192.168.100.1 \\\r\n --network=routing-vpc'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663aa27210>)])]>

2. PSC 엔드포인트 연결

예약한 IP 주소를 사용하여 Google API 번들로 트래픽을 전달하는 규칙을 생성합니다. 번들 유형은 all-apis와 vpc-sc 두가지가 있습니다. all-apis를 선택하게 되면 PSC에서 지원되는 모든 Google API에 대한 액세스 권한을 부여합니다. vpc-sc옵션을 선택한 경우 VPC-SC를 지원하는 Google API로 액세스를 한정하여, VPC-SC를 지원하지 않는 API에 대해서 PSC를 통한 접근은 차단되게 합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud compute forwarding-rules create psc4googleapi \\\r\n --global \\\r\n --network=routing-vpc \\\r\n --address=psc-ip \\\r\n --target-google-apis-bundle=vpc-sc \\\r\n --service-directory-registration=projects/PROJECT_ID/locations/REGION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663b56de10>)])]>

3. (선택 사항) 온프레미스 광고를 위한 Cloud Router 설정

온프레미스 환경에서 이 PSC 엔드포인트 IP(예시 상 192.168.100.1)로 접근해야 한다면, Cloud Router를 통해 해당 IP 대역을 온프레미스 네트워크에서 접근할 수 있도록 BGP 광고(Advertise)해야 합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud compute routers update CLOUDROUTER_NAME \\\r\n --project=PROJECT_ID \\\r\n --region=REGION \\\r\n --advertisement-mode custom \\\r\n --set-advertisement-groups=ALL_SUBNETS \\\r\n --set-advertisement-ranges=192.168.100.1/32'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a359290>)])]>

4. DNS 설정

Google API 도메인(*.googleapis.com)에 대한 DNS 쿼리가 앞서 생성한 PSC 엔드포인트의 비공개 IP(위 예시에서는 PSC의 IP주소 - 192.168.100.1)로 해석되도록 Cloud DNS에 비공개 영역(Private Zone)을 설정해야 합니다. 온프레미스나 타 클라우드 DNS구성의 경우, Cloud DNS에서 DNS forwarding Zone을 구성하거나, 직접 해당 PSC 엔드포인트의 비공개 IP에 대한 레코드를 구성하여 Gemini API 접근 시 공개 엔드포인트가 아닌 비공개 엔드포인트로 접근하게 해야 합니다.

엔드포인트 DNS 구성과 관련된 좀더 자세한 내용은 다음 공식 문서를 참고하여 주세요.

https://docs.cloud.google.com/vpc/docs/configure-private-service-connect-apis#using-endpoints

VPC Service Controls(VPC-SC)를 통한 심층방어(Defense-in-Depth) 완성

그럼 이제 퍼블릭 인터넷 경로를 거치지 않고도 생성형 AI를 사용할 수 있는 환경은 만들어졌습니다. 그러나 아직까지는 Google Cloud의 Resource 사이에 내부망 통신을 하도록 별도의 경로를 만든 것일 뿐이지, 퍼블릭 인터넷에서 들어오는 요청을 차단하는 환경을 만든 것은 아닙니다.

따라서 퍼블릭 인터넷에서 인입되는 요청을 차단하기위해 VPC-SC를 활용해야 합니다. VPC-SC는 가상의 경계(perimeter)를 만들고, 이 경계를 넘나드는 모든 Google API호출은 차단하는 서비스입니다. 따라서 VPC-SC를 사용하면 퍼블릭 인터넷 뿐만 아니라 경계 밖에서 안으로 들어가거나, 경계 안에서 밖으로 나가는 API 호출은 차단됩니다. 예를 들면 내부의 승인된 사용자가 모델 학습데이터를 통제되지 않는 Cloud Storage 버킷으로 복사하는 경우와 같은 데이터 무단 반출을 차단하기 위해서 VPC-SC가 활용될 수 있습니다. 즉 VPC-SC는 앞서 설명드린 PSC가 제공하는 '비공개 연결 경로'를 '보안 경계'로 감싸는 심층방어 (Defense-in-Depth)의 핵심 요소입니다.

VPC-SC는 어디서(Where), 어떻게(How) 데이터에 접근할 수 있는지를 제어하는 추가적인 방어 계층 역할을 합니다. 누가(Who) 데이터에 접근할 수 있는지를 제어하는 IAM(Identity and Access Management)에 대한 보완책으로도 볼수 있습니다. 따라서 VPC-SC의 세분화된 통제를 통해 각 기업의 환경에 따른 맞춤형 접근통제를 구현할 수 있습니다.

이러한 강력한 통제력으로 인해 설정에 주의가 필요하여 VPC-SC 적용에 대한 연습실행(Dry-run) 모드를 제공하고 있습니다. 연습실행 모드에서는 VPC-SC 정책이 위반되는 경우에도 차단은 하지 않고 에러만을 남겨서 경계를 적용하기 전에 정책이 운영상황에 미칠 영향을 미리 판단해 볼수 있습니다.

Dry-run 모드와 관련된 좀더 자세한 내용은 다음 공식 문서를 참고하여 주세요.

https://docs.cloud.google.com/vpc-service-controls/docs/dry-run-mode

그럼 AI서비스를 안전하게 운영하기 위한 VPC-SC 구성은 어떻게 할까요? 먼저 Vertex AI 등 보호할 리소스를 포함하고 있는 프로젝트를 선택해야 합니다. 서비스 경계 설정에 대한 자세한 사항은 다음 공식 문서를 참고해 주세요.

https://docs.cloud.google.com/vpc-service-controls/docs/create-service-perimeters#create-perimeter

선별적으로 보호할 서비스를 선택하거나 전체 서비스를 보호대상에 포함할 수도 있습니다. AI 서비스를 Vertex AI를 통해 구현한 상황이라면 일단 먼저 Vertex AI를 VPC-SC 경계 내에 포함해야합니다. 이를 통해 학습데이터 및 모델 아티팩트 저장 뿐만아니라 온라인/배치 추론 결과를 경계 내에서만 이루어지게 할수 있습니다. 학습 데이터를 Cloud Storage에 저장하여 사용한다면, Cloud Storage도 제한된 서비스에 추가해야 합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud access-context-manager perimeters create PERIMETER_NAME \\\r\n --title=TITLE \\\r\n --resources=projects/PROJECT_NUMBER \\\r\n --restricted-services=notebooks.googleapis.com,aiplatform.googleapis.com,storage.googleapis.com \\\r\n --policy=POLICY_NAME'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f663a35b8d0>)])]>

이제 PSC 엔드포인트를 VPN을 통해 호출해보겠습니다. 아래 데모화면에서는 PSC 엔드포인트(asia-northeast3-aiplatform.googleapis.com)의 IP 주소가 192.168.100.1 인 것을 확인할 수 있습니다. 이 상황에서 해당 리전(asia-northeast3)의 유효한 설정정보를 PSC 엔드포인트를 통해 호출해보겠습니다. 에러가 발생하지 않고 정상적으로 정보를 제공받은 것을 알수 있습니다. 이를 통해 VPN 경로를 통해 On-prem에 있는 VM에서 GCP 환경의 AI 관련 서비스를 호출할 수 있는 경로가 성공적으로 생성한 것을 알수 있습니다.

그럼 위에서 테스트한 내용을 퍼블릭 인터넷이 접속 가능한 VM에서 실행해보도록 하겠습니다. 이미 설정한 VPC-SC 서비스 경계로 인하여 호출이 차단 될 텐데 어떻게 에러가 발생하는지 아래 데모화면에서 같이 확인해 보겠습니다. 이번에는 asia-northeast3-aiplatform.googleapis.com의 IP주소를 살펴보면 우리가 이미 설정한 PSC 엔드포인트의 IP주소가 아닌 퍼블릭 IP주소가 반환되는 환경임을 알수 있습니다. 이 환경에서 동일한 호출하면 VPC_SERVICE_CONTROLS 정책 위반 에러가 나오는 것을 확인할 수 있습니다. 즉 인터넷 환경에서의 호출은 모두 차단된 상태입니다.

여기서 VPC-SC의 에러가 어떤 것인지 좀더 확인해보겠습니다. VPC-SC에서 발생하는 보안정책 위반 에러를 손쉽게 확인하고 조치하기 위해 VPC-SC 위반분석도구가 마련되어 있습니다. 로그 탐색기에서 에러에 대한 내용을 확인할 수도 있지만, 위반분석 도구를 사용하면 빠르고 명확하게 정책위반 원인을 파악하고 해결할 수 있습니다. 위 에러화면에서 uid항목을 복사하여 도구에 입력하면 아래와 같이 바로 분석 화면이 제공됩니다.

위반 분석 도구에 대한 자세한 사항은 다음 공식 문서를 참고해 주세요.

https://docs.cloud.google.com/vpc-service-controls/docs/troubleshooter

여기에서는 원본로그와 함께 어떤 리소스를 누가, 어떤 이유에서 보안정책을 위반하였는지 상세하게 알수 있으며, 해당 정책에 따른 위반사항에 대한 교정방법도 한 화면에서 바로 확인 할수 있습니다.

긴 여정을 정리하면 PSC와 VPC-SC가 서로 다른 역할을 수행하면서 안전한 비공개 구성을 구현하였습니다. PSC는 '통신 경로'를 공개 인터넷에서 비공개로 전환하여 공개 인터넷에 노출되지 않는 통신 경로를 구현하였고, VPC-SC를 통해 데이터 보안 경계를 설정하여 공개 인터넷으로 부터 접근을 차단하고, 경계 내외부 사이에 무단 데이터 반출을 원천 차단할 수 있게 되었습니다.

마지막으로 VPC-SC를 비롯한 여러 Security 서비스를 활용하여 Google Cloud에서 엔터프라이즈 AI 서비스를 안전하게 구성하는 참조 아키텍처를 소개하면서 이번 블로그를 마무리 하겠습니다. 아래 다이어그램을 보시면 VPC-SC 서비스 경계 안에 Vertex AI와 App Hosting, Cloud Storage 등의 리소스가 포함된 것을 보실수 있습니다. 이렇게 경계를 구성하면 별도 지정된 Ingress/Egress rule이 없으면 데이터가 경계를 넘어갈 수 없게됩니다. 그외 KMS를 통한 암호키 통제, Model Armor를 활용한 런타임 AI서비스 보호, Cloud Armor를 활용한 네트워크 위협통제 등을 통해 엔터프라이즈 환경에서 안전하게 AI를 사용할 수 있습니다.

참조 아키텍처에 대한 좀더 자세한 사항은 다음 블로그를 참고해 주세요.

https://cloud.google.com/blog/ko/products/identity-security/google-cloud-ai

<참고 자료>

Codelabs: 하이브리드 연결을 통해 Gemini에 액세스하기 위해 Google API용 Private Service Connect 사용

https://codelabs.developers.google.com/cloudnet-psc-hybridGemini

Codelabs: Private Service Connect 엔드포인트가 있는 GCE의 Gemini CLI

https://codelabs.developers.google.com/codelabs/terraform-gemini-cli-gce-psc

Codelabs: Private Service Connect 엔드포인트를 통해 Python SDK로 Vertex AI에서 Anthropic Claude에 액세스

https://codelabs.developers.google.com/codelabs/anthropic-on-vertexai-psc

공식 문서: VPC-SC, Google API 및 서비스로 비공개 연결 설정

https://docs.cloud.google.com/vpc-service-controls/docs/set-up-private-connectivity

Google Cloud에서 네트워크 보안 역량을 확보하세요.

Fri, 10 Oct 2025 16:00:00 +0000

해당 블로그의 원문은 2025년 10월 11일 Google Cloud 블로그(영문)에 게재되었습니다.

조직을 사이버 위협으로부터 보호하는 것은 원활한 운영을 보장하고 규정 준수 요구 사항을 충족하는 데 필수적입니다. 민감한 데이터와 중요 애플리케이션이 클라우드로 마이그레이션됨에 따라, 전문적인 방어의 필요성은 더욱 절실해졌습니다. 이제 보안은 더 이상 경계 방화벽에 국한되지 않고, 동적인 클라우드 네트워크를 보호하는 것을 의미합니다.

숙련된 클라우드 보안 전문가에 대한 증가하는 수요를 인식하여, Google Cloud는 새로운 네트워크 보안 학습 과정(Network Security Learning Path)를 출시합니다. 이 과정은 'Designing Network Security in Google Cloud' 고급 기술 배지(advanced skill badge)를 획득하는 것으로 마무리됩니다. 저희 전문가들이 설계한 이 종합 프로그램은 민감한 데이터와 애플리케이션을 보호하고, 비즈니스 연속성을 보장하며, 성장을 주도하는 데 필요한 검증된 기술을 갖추도록 지원합니다.

'Designing Network Security in Google Cloud' 기술 수료 배지를 획득하는 것은 경력 발전을 위한 강력한 촉매제가 될 수 있습니다. Google Cloud가 의뢰한 Ipsos 연구에 따르면, 학습자의 70%가 클라우드 학습이 승진 목표 달성에 기여했다고 답했으며, 76%가 Google Cloud Learning Services를 사용하기 시작한 이후 소득이 증가했다고 답했습니다.

완전한 학습 여정

이 새로운 학습 경로는 단순한 단일 과정을 넘어, 네트워킹, 인프라 또는 보안 역할에 중점을 둔 솔루션 기반 학습을 위한 완전한 여정입니다. 데이터를 보호하고 애플리케이션을 보호하기 위해 안전한 네트워크를 설계, 구축 및 관리하는 방법을 배우고, 차세대 방화벽 정책 위반이나 데이터 무단 반출과 같은 실제 시나리오를 처리하는 능력을 검증받게 됩니다. 이 경로를 완료하면 'Designing Network Security in Google Cloud' 기술 배지를 받게 됩니다.

이 과정을 통해 다음 내용을 배우게 됩니다.

보안 네트워크 토폴로지 설계 및 구현: 보안 VPC 네트워크 구축부터 Google Kubernetes Engine (GKE) 환경 잠금까지.
Google Cloud Next Generation Firewall (NGFW) 마스터: 정밀한 방화벽 규칙 및 네트워킹 정책을 구성하여 트래픽 흐름을 완벽하게 제어.
Cloud VPN 및 Cloud Interconnect를 사용한 환경 간 보안 연결 설정.
Google Cloud Armor를 활용하여 WAF 및 DDoS 보호를 위한 계층화된 방어 강화.
네트워크 리소스에 대한 세분화된 ID 및 액세스 관리(IAM) 권한 적용.
이러한 원칙을 복잡한 하이브리드 및 멀티클라우드 아키텍처 보안에 확장 적용.

미래의 보안 역량 확보

이 학습 경로는 지속되는 사이버 보안 기술 격차에 대한 해답이 될 수 있습니다. 이는 차세대 네트워크 보안에 필요한 기술을 구축할 수 있도록 역량을 강화해 줄 것입니다.

기술 배지를 획득하기 위해, 학습 경로의 마지막에는 방화벽 정책 위반이나 데이터 무단 반출과 같은 실제 시나리오 처리 능력을 검증하는 실습 중심의 문제 해결 챌린지 랩에 도전하게 됩니다.

조직의 클라우드 네트워크를 자신 있게 보호할 수 있는 역량을 확보하려면, 지금 바로 Google Cloud 네트워크 보안 학습 과정에 등록하세요.

DNS Armor 출시: DNS 위협을 탐지하고 선제적으로 대응하세요.

Tue, 16 Sep 2025 16:00:00 +0000

해당 블로그의 원문은 2025년 9월 17일 Google Cloud 블로그(영문)에 게재되었습니다.

도메인 이름 시스템(DNS)은 인터넷의 전화번호부와 같아서, 웹사이트와 모바일 앱에 대한 요청을 해당 도메인 이름에서 실제로 호스팅하는 컴퓨터의 IP 주소로 자동적으로 거의 즉각 변환해 줍니다. 인터넷의 근간을 이루는 부분으로서, DNS 및 도메인 이름 조회는 또한 위협 행위자들이 사이버 공격을 시작하는 주요 수단이 되므로, DNS 기반 보호 기능은 사이버 공격에 대한 중요한 초기 방어 계층 역할을 할 수 있습니다.

DNS를 사용하여 사이버 공격을 진행하는 것은 심각한 위협이며, Infoblox가 올해 발표한 연구에 따르면 악성코드의 92%가 명령 및 제어(C2) 통신을 위해 DNS를 사용하는 것으로 나타났습니다. 고객의 보안 선택권을 지원하기 위해, 저희는 Infoblox와 협력하여 클라우드 네이티브 DNS 보안 서비스인 DNS Armor를 제공하며, 현재 미리 보기(Preview)로 이용 가능합니다.

DNS Armor는 Google Cloud 워크로드에서 시작된 인터넷 대상 DNS 쿼리에 대한 선제적인 위협 탐지 기능을 제공합니다. 이는 악성 명령 및 제어(C2) 서버에 대한 요청, 민감 데이터 유출을 위한 DNS 터널링, 그리고 DNS 쿼리를 사용하는 악성코드를 포함한 DNS 기반 위협을 식별하는 기초적인 보안 계층을 제공함으로써 기존의 클라우드 우선(cloud-first) 네트워크 보안 제품 포트폴리오를 보완합니다.

DNS Armor는 Infoblox의 선제적 DNS 위협 방어로부터 이점을 얻으며, 이 시스템은 매일 700억 건 이상의 DNS 이벤트를 분석하고 매월 데이터베이스에 400만 개의 새로운 위협 지표를 추가합니다. DNS 이벤트 분석을 사용하는 이러한 선제적 탐지 접근 방식은 보완적인 보안 도구보다 68일 더 일찍 DNS 기반 위협을 식별하는 데 도움을 줍니다.

Sabre Corporation의 클라우드 플랫폼 인프라 부사장인 Alfredo Rodriguez는 다음과 같이 말했습니다. "Infoblox와 Google Cloud의 고객으로서, 저희는 이 협업의 변혁적인 잠재력에 대해 매우 기대하고 있습니다. Infoblox의 기술력이 더해진 Google Cloud의 DNS Armor는 두 회사의 강점을 결합하여 선구적이고 선제적인 위협 방어를 제공하는 사이버 보안 분야의 도약입니다."

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 보안 제품을 경험해 볼 수 있는 $300의 무료 크레딧을 드립니다.'), ('body', <wagtail.rich_text.RichText object at 0x7f66399e88d0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

DNS 인텔리전스로 위협을 조기에 탐지

DNS Armor는 피드 기반(Feed-based) 및 알고리즘 기반(Algorithmic-based)의 두 가지 위협 탐지 기능을 제공합니다.

피드 기반: 알려진 악성 도메인, 고위험 도메인, 그리고 악성 공격에 사용될 가능성이 있는 새롭게 등록된 도메인을 탐지합니다.
알고리즘 기반: 무단 데이터 유출을 방지하기 위한 DNS 터널링 공격 기법과 같은 머신러닝 기반 탐지 기법을 사용하여 공격을 탐지합니다.

DNS Armor는 또한 악성코드 배포 사이트로의 연결을 탐지하는 데 도움을 줄 수 있으며, 악성 및 고위험 도메인으로 향하는 DNS 쿼리를 차단함으로써 잠재적인 악성 다운로드를 선제적으로 방지할 수 있습니다.

많은 정교한 사이버 공격은 해당 명령 및 제어(C2) 환경과 네트워크 연결을 설정합니다. DNS Armor를 사용하면 C2 활동, 악성코드 배포 사이트로의 연결, 그리고 워크로드에서 시작되는 Domain Generation Algorithm(DGA) 트래픽을 탐지하여 의심스럽거나 악성 도메인의 가장 초기 지표를 파악할 수 있습니다.

예를 들어, DNS Armor는 단일 도메인 이름에 연결된 IP 주소를 빠르게 교체하는 패스트 플럭스(fast flux)와 같은 회피 기법을 탐지할 수 있습니다. 이러한 기법은 악성 도메인 탐지를 더욱 어렵게 만들며 종종 기존 보안 도구에서는 간과되기 쉽습니다.

Infoblox의 총괄 부사장 겸 최고 제품 책임자(CPO)인 Mukesh Gupta는 다음과 같이 말했습니다. "사이버 보안의 미래는 사후 대응적이지 않습니다. 그것은 선제적입니다. DNS는 모든 인터넷 연결의 기반에 있으며, 공격이 시작되기 전에 포착할 수 있는 가장 빠르고, 가장 간과하기 쉬운 기회를 제공합니다. Infoblox가 통합된 Google Cloud의 DNS Armor는 위협이 무기화되기 몇 주 전에 이를 탐지합니다. 이는 보안 팀이 노이즈를 제거하고 실질적으로 중요한 것에 집중하도록 도우며, 거의 제로에 가까운 오탐률(false positive rate)을 자랑합니다. '환자 제로(patient zero)'를 기다릴 필요도, 사각지대도 없습니다. 규모에 맞는 실시간 위협 가시성만이 존재할 뿐입니다."

DNS Armor 작동 방식

Google Cloud 워크로드에 DNS Armor를 적용하는 것은 단 몇 번의 클릭만으로 가능합니다. 일단 활성화되면, DNS Armor는 귀하의 Google Cloud 워크로드에서 생성되는 인터넷 대상 DNS 쿼리를 가로채며, 해당 쿼리는 Infoblox Threat Defense 서비스에 의해 실시간으로 자동 검사됩니다.

위협이 탐지될 경우, Infoblox Threat Defense 서비스는 상세한 위협 로그를 생성하여 Cloud Logging에 저장합니다. 귀하는 또한 이러한 위협 로그를 Security Command Center, Google Security Operations 또는 선호하는 SIEM 플랫폼으로 전송하여 추가적인 분석과 인시던트 대응에 활용할 수 있습니다.

DNS Armor 워크플로.

DNS Armor는 턴키 방식의 관리형 서비스이기 때문에 배포 및 관리가 매우 쉽습니다. 관리할 가상 머신(VM)이 전혀 없으며, Cloud DNS의 성능에 영향을 주지 않습니다. 프로젝트 수준에서 가상 PC 전반에 걸쳐 DNS Armor를 활성화할 수 있어, 보호가 필요한 클라우드 워크로드에 대한 세밀한 제어(Granular Control)가 가능합니다.

시작하기

DNS Armor를 시작하려면 문서 페이지를 방문하십시오. DNS 보안에 대해 더 자세히 알아보려면 이 영상을 확인해 보십시오.

Cloud WAN: AI 시대를 위해 구축된 네트워크로 글로벌 엔터프라이즈 연결

Thu, 01 May 2025 18:09:00 +0000

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

Google은 25년 넘게 전 세계 수십억 명의 사용자를 Gmail, YouTube, Google 검색과 같은 필수 서비스에 연결하는 혁신을 통해 네트워크의 범위를 확장했습니다. 그 기반에는 Google의 방대한 백본 네트워크가 있습니다. 202개의 접속 지점(PoP), 33개의 해저 케이블, 321만km(200만 마일) 이상의 광섬유로 연결된 Google의 네트워크는 99.99% 안정성 SLA를 기반으로 강력하고 복원력 있는 글로벌 플랫폼을 제공합니다.

이러한 전 세계적 규모의 네트워크 인프라는 Google Cloud와 크로스 클라우드 네트워크 솔루션을 지원합니다. 그리고 오늘, 모든 기업과 정부가 새로운 Cloud WAN 솔루션을 통해 Google의 글로벌 네트워크를 사용할 수 있게 되었음을 알려드립니다.

Cloud WAN은 엔터프라이즈 광역 통신망(WAN) 아키텍처를 혁신하는 완전 관리형의 안정적이고 안전한 엔터프라이즈 백본입니다. 이 솔루션은 애플리케이션 성능에 맞게 최적화된 전 세계적 규모의 Google 네트워크를 활용합니다. Cloud WAN은 공개 인터넷에 비해 최대 40% 더 빠른 성능을 제공1하며 고객이 관리하는 WAN 솔루션에 비해 총소유비용(TCO)을 최대 40% 절감2합니다.

aside_block: <ListValue: [StructValue([('title', '$300로 Google Cloud 네트워킹을 사용해 보세요'), ('body', <wagtail.rich_text.RichText object at 0x7f6638c940d0>), ('btn_text', '무료 빌드 시작하기'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/products?#networking'), ('image', None)])]>

엔터프라이즈 WAN의 발전

전통적으로 기업들은 안전하고 안정적인 사이트 간 연결을 위해 비용이 많이 드는 다중 프로토콜 라벨 전환(MPLS) 네트워크에 크게 의존했습니다. 그러나 SaaS 및 클라우드 애플리케이션의 급속한 도입으로 인해 변화가 필요해졌고, 그 결과 직접 인터넷 액세스(DIA)를 갖춘 SD-WAN이 등장했습니다. 이 솔루션은 인터넷을 활용하여 비용이 저렴하다는 이점이 있습니다. 이후 기업들은 애플리케이션 성능을 개선하기 위해 코로케이션 기반 클라우드 연결 지점을 구축했습니다. 이를 통해 지연 시간은 개선되었지만 복잡성과 비용이 증가하는 단점이 있었습니다. 이러한 발전 과정에서 보안 서비스 에지(SSE)와 자체 관리형 어플라이언스가 혼합된 보안 스택이 확산되었고, 이에 따라 일관되지 않은 보안 상황이 형성되었습니다.

결과적으로 엔터프라이즈 연결은 본질적으로 복잡하고 관리가 어려워졌습니다. 또한 다양한 네트워크와 분산된 보안 체계 속에서 안정성, 속도, 비용 간 균형을 지속적으로 유지해야 하는 상황에 놓이게 되었습니다.

AI의 급속한 발전으로 인해 엔터프라이즈 네트워크에 대한 추가적인 요구사항이 생겨났습니다. AI 기반 애플리케이션에는 여러 클라우드와 온프레미스 데이터 센터에 분산되어 있는 인프라와 함께 대규모로 확장 가능하고, 강력한 보안과 개인 정보 보호를 제공하며, 리소스를 효율적으로 사용하면서도 비용 효과를 유지할 수 있는 글로벌 네트워크가 필요합니다.

이러한 니즈를 해결하기 위해 Cloud WAN은 모든 기업 사이트, 애플리케이션, 사용자를 안전하고 안정적으로 연결하는 동시에 최적의 성능을 보장하고 비용을 절감하는 통합된 엔터프라이즈 네트워크 솔루션을 제공합니다.

Cloud WAN은 두 가지 주요 사용 사례를 지원합니다. 즉, 지리적으로 분산된 데이터 센터 간에 고성능 연결을 제공하며, 프리미엄 등급 네트워크를 통해 브랜치 및 캠퍼스 환경을 연결합니다.

사용 사례 1: 리전 간 고성능 연결

광범위한 데이터 센터 네트워크를 보유한 대규모 글로벌 고객은 대량의 데이터를 안정적으로 이전할 수 있어야 합니다. Cloud WAN은 지리적으로 분산된 데이터 센터를 연결할 수 있는 유연한 옵션을 제공하며, 용량이 제한적이고 운영 비용이 많이 들며 안정성이 낮은 기존 솔루션을 대신할 수 있는 현대적인 솔루션입니다.

이 사용 사례는 다음과 같은 핵심 기능을 통해 구현됩니다.

Cloud Interconnect 는 Google Cloud 리전과 온프렘 데이터 센터 간에 지연 시간이 짧고, 전용으로 사용할 수 있는 비공개 연결을 제공하므로 전 세계 159곳 이상의 위치에서 데이터 센터를 Google Cloud에 연결할 수 있도록 합니다.

Cross-Cloud Interconnect는 Google Cloud와 AWS, Azure, OCI를 비롯한 다른 퍼블릭 클라우드 환경 간의 멀티 클라우드 연결을 지원하며 21곳에서 사용할 수 있습니다.

그리고 이제 Cross-Site Interconnect를 통해 데이터 센터 간의 애플리케이션 연결에 최적화되었으며 기업, 정부 기관, 통신 사업자를 위해 설계된 전용 지점 간 레이어 2 비공개 10/100G 연결을 지원합니다. Google Cloud는 Cross-Site Interconnect를 통해 자사 네트워크로 투명한 레이어 2 연결을 제공하는 최초의 주요 클라우드 제공업체가 되었습니다. Cross-Site Interconnect는 현재 일부 국가에서 프리뷰 버전으로 제공되고 있으며, 내년에는 추가적인 에지 위치로 확대될 예정입니다.

Cross-Site Interconnect의 주요 이점은 다음과 같습니다.

엔터프라이즈급 성능: Cross-Site Interconnect는 SLA와 기본 제공되는 중복성, Google의 고성능 글로벌 네트워크를 갖춘 고대역폭(10/100G) 데이터 센터 상호 연결 솔루션입니다.
전 세계적인 도달 범위와 용량: Cross-Site Interconnect는 Google Cloud의 글로벌 백본, 즉 321만km(200만 마일) 이상의 광섬유 네트워크를 통해 실행되며 대서양 및 태평양 횡단 네트워크를 위한 국제적인 용량을 제공합니다.
위험 및 비용에 최적화: Cross-Site Interconnect는 중복 광섬유 인프라를 활용하여 물리적 네트워크 및 광섬유 장애와 관련된 네트워크 트래픽의 경로를 동적으로 재설정함으로써 일관된 서비스 가용성을 유지합니다.

참고: Google Cloud는 Network Connectivity Center(NCC)를 통해 확장 가능한 레이어 3 라우팅 솔루션도 지원합니다. 자세한 내용은 다음 섹션을 참고하세요.

“Google Cloud를 기반으로 연구 활동을 지속적으로 확장하고 성능에 민감한 워크로드를 호스팅하려면 확장 가능하고 안정적인 글로벌 네트워크가 필수입니다. Google Cloud WAN의 이미 확인된 안정성과 신뢰성을 바탕으로 하이브리드 네트워크의 증가하는 니즈를 충족할 수 있기를 기대합니다.” - Chris Dee, Citadel Securities 클라우드 플랫폼 엔지니어링 책임자

사용 사례 2: 브랜치 및 캠퍼스 네트워크 마이그레이션

Google의 프리미엄 등급 네트워크는 강력한 클라우드 연결 지점 역할을 하며 브랜치 및 캠퍼스를 퍼블릭 클라우드 리소스, SaaS 애플리케이션, 인터넷에 안전하게 연결할 수 있도록 지원합니다. Cloud WAN은 Google의 신뢰할 수 있는 네트워크의 성능과 안정성을 기업으로 직접 확장하는 완전 관리형 통합 솔루션으로서 모든 환경 간의 연결을 주문형으로 지원하며 내재된 보안과 낮은 TCO를 제공합니다. 또한 기업은 Google의 개방적이면서도 긴밀하게 통합된 생태계에서 동급 최고의 보안 및 네트워크 서비스를 통해 유연성을 강화하고 맞춤화된 솔루션을 활용할 수 있습니다.

최대 40% 향상된 성능을 제공하는 프리미엄 등급 네트워크

이러한 성능의 기반은 애플리케이션을 위한 강력하고 복원력 있는 플랫폼을 제공하는 Google의 독보적인 백본 네트워크입니다.

Google의 프리미엄 등급 네트워크 서비스는 최적의 애플리케이션 성능을 제공하도록 설계되었습니다. 이 서비스는 Cloud WAN을 대상으로 하는 인터넷 기반 트래픽이 지리적으로 가장 가까운 PoP에서 Google의 고성능 네트워크로 송수신되도록 합니다. 이를 통해 네트워크 홉을 최소화하여 지연 시간을 단축하고 사용자 경험을 더욱 일관되게 유지할 수 있습니다.
Google은 5,700개 이상의 다이렉트 피어링 연결을 제공하며 6만 개 이상의 자율 시스템 번호(ASN)에 대한 연결 가능성을 갖추고 있어 클라우드 제공업체 중 해당 부문 1위를 차지하고 있으며 글로벌 피어링 부문에서는 6위를 차지하고 있습니다. 이러한 광범위한 피어링 네트워크는 다른 네트워크와의 효율적인 트래픽 교환을 보장하여 애플리케이션 성능을 더욱 향상합니다.
Google의 Verified Peering Provider 프로그램은 고객이 가용성 극대화를 위해 ISP를 선택할 수 있도록 지원합니다. 이제 전 세계 대부분의 ISP에 개방된 이 프로그램은 중복되고 다양한 연결을 제공합니다.
Lumen Technologies와의 파트너십을 통해 제공되는 전용 광섬유 액세스(2025년 일부 지역에서 제공)를 활용하여 데이터 센터, 브랜치, 창고, 공항 등 고객이 운영하는 위치에서 Cloud WAN으로의 라스트 마일 전달을 지원합니다.
BT는 BT 고객이 Cloud WAN을 사용하여 Google Cloud에 직접 연결할 수 있도록 Global Fabric 서비스형 네트워크(NaaS)를 제공하고 있습니다.

Cloud WAN의 아키텍처는 여러 기업의 다양한 최신 연결 요구사항을 충족하는 유연한 옵션을 제공합니다. Network Connectivity Center는 기업이 Cloud VPN 또는 선호하는 SD-WAN 솔루션을 사용하여 브랜치를 연결할 수 있도록 해주는 중앙 허브 역할을 합니다. 캠퍼스와 데이터 센터는 고대역폭(10G, 100G) 링크에 Cloud Interconnect를 사용할 수 있습니다. 엔터프라이즈 네트워크의 도달 범위와 안정성을 더욱 확장하기 위해 Network Connectivity Center를 사용한 사이트 간 데이터 전송 이 이제 전 세계 20개 국가에서 제공됩니다.

"Cloud WAN은 에지와 클라우드의 격차를 해소하여 애플리케이션 성능을 최대 40% 향상하고, 비용을 절감하며, 엔드 투 엔드 디지털화를 위한 복원력이 뛰어나고 확장 가능한 지원과 기반을 제공합니다." - Ralf Huebenthal, Nestle IT 플랫폼 글로벌 책임자

Cloud WAN은 강력한 네트워크 기능을 결합하여 애플리케이션 경험을 크게 개선하기 때문에 비즈니스에서는 사용자에게 기대하는 수준의 성능을 제공할 수 있습니다.

Cloud WAN으로 TCO 최대 40% 절감Cloud WAN은 고객 관리형 WAN 솔루션과 비교할 때 TCO를 최대 40% 절감2할 수 있습니다. 다양한 니즈에 따라 사용량 기반 옵션과 고정 가격 옵션 중에 유연하게 선택할 수 있어 고정된 선불 비용을 크게 낮춥니다. 고대역폭 인터넷 데이터 전송을 수행하는 조직을 위해 Cloud Interconnect의 고정 가격 모델을 확장하여 이번 분기에 정식 버전으로 출시할 예정입니다. Cloud WAN을 사용하면 많은 기업이 이동통신사 중립 시설 배포를 더 적은 수의 클라우드 리전으로 통합하여 비용을 절감할 수 있습니다.

유연성과 선택권을 위해 긴밀하게 통합된 개방형 생태계Cloud WAN은 개방적이고 유연하고 긴밀하게 통합된 생태계를 갖추고 있어 기업이 강력하고 적응력 있는 네트워크를 구축하는 데 필요한 도구를 제공합니다. Cloud WAN은 광범위한 ISV 생태계의 네트워크 및 보안 서비스를 손쉽게 통합할 수 있도록 지원합니다.

Cisco, Fortinet, Juniper Networks, Netskope, Palo Alto Networks, Velocloud 등의 선도적인 공급업체가 강력한 SD-WAN 파트너 생태계를 구성하고 있습니다. 기업은 자체 관리를 선택하거나 Google의 서비스 파트너를 통한 관리형 오버레이 연결을 이용할 수 있습니다.
NCC Gateway(2분기에 프리뷰 버전으로 출시)를 사용하는 Cloud WAN은 비공개 및 공개 애플리케이션에 액세스하는 사용자를 위해 보안 서비스 에지(SSE)의 관리형 통합을 제공하는 최초의 주요 클라우드 솔루션입니다. SSE 서비스는 Broadcom, Menlo Security, Palo Alto Networks에서 제공됩니다.
Cloud Next Generation Firewall(NGFW)을 사용하거나 네트워크 보안 통합을 통해 Check Point, Fortinet, Palo Alto Networks의 NGFW 가상 어플라이언스를 통합할 수 있는 유연한 보안 옵션이 제공됩니다.

또한 파트너 솔루션으로 Cloud WAN의 이점을 확장하여 민첩하고 안전하고 자동화된 브랜치 네트워크를 구축하고 다음과 같은 서비스를 통해 새로운 브랜치와 서비스를 신속하게 배포할 수 있습니다.

Infoblox Universal DDI는 인프라가 필요 없는 클라우드 기반 도메인 이름 서비스(DNS), 동적 호스트 구성 프로토콜(DHCP), IP 주소 관리(IPAM)를 제공하여 브랜치 네트워크를 현대화하고 단순화합니다. 선택사항인 DNS 보안 구성요소는 피싱 및 멀웨어로부터 보호하여 사용자가 중요한 애플리케이션에 안전하게 연결되도록 보장합니다.
Juniper Networks Mist는 포괄적인 인사이트와 자동화를 포함한 AI 기반 캠퍼스 및 브랜치 혁신을 제공하여 사용자 경험을 최적화합니다. 이 통합에는 Wi-Fi, 유선 액세스, SD-WAN, 네트워크 액세스 제어(NAC), 실내 위치 서비스, IoT 분석과 같은 클라우드에서 제공하는 중요 네트워크 서비스가 포함됩니다.
연결형 구성으로 제공되는 Google Distributed Cloud(GDC) 통합은 지연 시간에 민감한 애플리케이션을 위해 Google Cloud의 컴퓨팅 이점을 에지로 확장합니다. GDC는 컨테이너화된 VM 기반 애플리케이션을 지원하는 완전 관리형 플랫폼으로, Cloud WAN을 사용하여 Google Cloud 리전으로 다시 자동 연결하도록 지원합니다.

파트너 관리형 서비스

이미 엔터프라이즈 백본 니즈를 위해 관리형 서비스 제공업체를 이용하고 있는 기업은 Cloud WAN으로 마이그레이션할 때도 선호하는 파트너와 계속 협력할 수 있습니다. 또한 Cloud WAN으로 마이그레이션하거나, 이를 배포 및 운영하는 과정에서 도움이 필요한 기업은 Google의 글로벌 시스템 통합업체(GSI) 파트너 중 한 곳과 협력할 수 있습니다. 출시 시점에 Cloud WAN 파트너에는 Accenture, HCLTech, Wipro가 포함되며, 이들은 현재 서비스 아키텍처, 설계, 마이그레이션, 지속적인 관리 서비스를 제공하고 있습니다.

자세히 알아보기

Cloud WAN은 기업이 글로벌 인프라를 연결하고 보호하는 방식을 혁신할 것입니다. 기업은 단순성, 고성능, 다양한 연결 및 보안 서비스 선택권은 물론 상당한 비용 절감 이점까지 제공하는 Cloud WAN을 통해 클라우드와 그 너머에서 혁신과 성장에 집중할 수 있습니다.

Next ‘25 및 크로스 클라우드 네트워크 솔루션 페이지에서 Cloud WAN에 대해 자세히 알아볼 수 있습니다. Google Cloud Next 2025의 네트워킹과 관련된 다른 여러 소그룹 세션도 확인해 보세요.

_{1. 테스트에서 크로스 클라우드 네트워크를 통해 전송되는 대상 트래픽의 네트워크 지연 시간은 공개 인터넷을 통해 전송되는 트래픽(동일한 대상 기준)보다 40% 이상 짧았습니다.}

_{2. 아키텍처는 SD-WAN 및 서드 파티 방화벽을 포함하며, 다중 사이트 코로케이션 시설을 사용하는 고객 관리형 WAN을 Google Cloud에서 관리하고 호스팅하는 WAN과 비교합니다.}

데이터 무단 반출 방지를 확장하는 VPC 서비스 제어 내 비공개 IP 주소 지원 발표

Mon, 17 Mar 2025 06:42:00 +0000

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

조직은 Google Cloud의 VPC 서비스 제어를 사용하여 Google Cloud 관리형 서비스에서 데이터가 무단 반출될 리스크를 완화할 수 있습니다. VPC 서비스 제어(VPC-SC)는 Google Cloud 내의 클라우드 리소스 및 네트워크 주변에 격리 경계를 만들어 민감한 정보에 대한 액세스를 제한하는 데 도움이 됩니다.

오늘 Google Cloud가 VPC 서비스 제어 내에서 비공개 IP 주소를 지원하게 되었다는 기쁜 소식을 전해드립니다. 이 새로운 기능은 특정 내부 네트워크의 트래픽이 보호된 리소스에 액세스할 수 있도록 허용합니다.

VPC-SC를 확장하여 비공개 IP 주소 공간의 리소스 보호

VPC-SC는 승인된 사용자와 리소스만 액세스할 수 있는 경계를 정의하여 승인되지 않은 Google Cloud 조직, 폴더, 프로젝트, 리소스로 데이터가 무단 반출되지 않도록 돕습니다. VPC-SC를 배포하는 고객은 포괄적인 액세스 규칙 기능을 사용하여 Google Cloud 관리형 서비스에 최소 권한 액세스를 적용할 수 있습니다. 새로운 기능을 통해 고객은 식별된 온프레미스 환경에서 서비스 경계 내의 리소스에 대한 액세스를 허용할 수 있게 됩니다.

특히, 고객이 기본 액세스 수준을 사용하여 VPC 네트워크용 비공개 IP 주소 범위를 지정할 수 있다는 점에 주목해야 합니다. 이 액세스 수준은 인그레스 및 이그레스 액세스 규칙에 연결되어 Google 서비스를 대상으로 세분화된 액세스 제어를 적용하고 고객이 비공개 주소 공간으로 경계를 확장할 수 있도록 합니다.

Google Cloud의 권장사항에 따라 관리와 확장이 쉬운 매크로 또는 '메가' 경계를 사용하는 것이 좋습니다. 더욱 상세한 세분화가 필요한 특정 사용 사례에 해당하는 고객의 경우 비공개 IP로 더 많은 유연성을 누릴 수 있습니다.

이제부터 VPC-SC 내 비공개 IP 지원으로 더 안전한 아키텍처를 빌드할 수 있는 몇 가지 사용 사례를 소개합니다.

사용 사례: 안전한 클라우드 경계까지 온프레미스 환경 확장하기

VPC-SC는 액세스 목적을 위해 고객의 온프레미스 환경을 하나의 네트워크로 취급합니다. 그 결과 온프레미스 환경 전체에 네트워크 기반 액세스 규칙이 적용됩니다. 이에 따라 일부 고객은 VPC-SC 경계에 특정 온프레미스 클라이언트만 액세스해야 하는 상황에서 액세스 권한을 과도하게 프로비저닝하는 상황을 우려합니다. 온프레미스 환경의 경우 비공개 주소에 기반한 인그레스 및 이그레스 규칙을 사용하여 경계 리소스에 대한 온프렘 워크로드의 액세스 권한을 보다 선택적으로 제공할 수 있습니다. 자세한 내용은 이 동영상을 참조하세요.

온프레미스를 VPC-SC 경계까지 확장하는 샘플 아키텍처 개요

사용 사례: 공유 VPC에서 클라우드 프로젝트 분류하기

VPC-SC는 요청 평가의 일환으로 소스 네트워크가 신뢰할 수 있는 경계 내 프로젝트에 속했는지를 확인합니다. 공유 VPC 환경에서는 호스트 프로젝트가 네트워크를 소유하고 서비스 프로젝트에 공유합니다. 이에 따라 고객은 호스트 및 서비스 프로젝트를 서로 다른 경계로 분리할 수 없었습니다. 비공개 주소에 기반한 인그레스 및 이그레스 규칙을 사용하면 호스트 및 서비스 프로젝트를 서로 다른 경계에 배치하고 규칙에 따라 액세스를 허용할 수 있습니다. 또한 리소스가 승인되지 않은 서비스에 노출되지 않게 제한합니다. 자세한 내용은 이 동영상을 참조하세요.

공유 VPC에서 어떻게 분류하는지 보여주는 샘플 아키텍처 개요

우수사례: MSCI, VPC 서비스 제어로 보안 강화

글로벌 투자 커뮤니티에 중요한 의사 결정 지원 도구 및 서비스를 제공하기로 유명한 MSCI는 클라우드 기술을 단순한 인프라로 사용하지 않습니다. MSCI에 클라우드 기술은 혁신 추진에 필수적인 프레임워크입니다.

MSCI는 2022년부터 Google Cloud와 협력하여 민첩하고 확장 가능하고 안전한 컴퓨팅을 구현하려고 최선을 다해왔습니다. Compute Engine, BigQuery, Kubernetes Engine 등 여러 서비스를 세심하게 조정하여 혼합한 MSCI의 Google Cloud 환경은 첨단 기술에 대한 MSCI의 헌신에서 비롯되었습니다.

민감한 정보를 보호하면서도 클라우드 확장성의 이점을 활용하기 위해 MSCI는 VPC-SC로 전환했습니다. 이러한 결정은 데이터의 민감성뿐만 아니라 여러 수준에서 데이터를 보호하는 심층 방어 구현이 필요하다는 요구사항에 따른 결과였습니다. 엄격한 이그레스 및 인그레스 제어를 통해 VPC-SC는 Google의 클라우드 중심 제어(IAM, 방화벽 등)에 더하여 추가적인 방어 계층을 MSCI에 제공했습니다. 그러나 MSCI의 경우 비공개 IP를 사용해 서브네트워크 수준에서 액세스 권한을 세분화해야 한다는 특별한 요구사항이 있었습니다.

MSCI 클라우드 엔지니어링 부문 전무이사 Sandesh D’Souza는 “새롭게 구현된 VPC 비공개 주소 지원 기능을 통해 MSCI는 정확한 조건을 정의하여 VPC 네트워크 내에서 특정 비공개 IP 범위의 보호된 리소스에만 액세스하도록 허용할 수 있게 되었습니다. 이러한 혁신의 결과, MSCI의 보안 구성을 더욱 상세화했습니다. 이 맞춤 솔루션은 특히 비공개 IP 관리 지원 부분에서 조직 보안 저장소의 핵심적인 추가 기능으로 부상했으며, 계획 및 협업 솔루션 빌드와 부합될 때 클라우드 기술의 잠재력이 얼마나 대단한지 보여 주었습니다."라고 말했습니다.

다음 단계

VPC 서비스 제어는 대부분의 Google Cloud 고객을 위한 기본적인 보안 제어입니다. Google Cloud는 비공개 IP 지원을 통해 보다 세분화된 제어를 제공하여 각 고객의 정확한 니즈를 보다 잘 충족할 수 있습니다. 프로덕션 환경에 배포하기 전에 최근 출시된 VPC-SC 테스트 실행 모드를 사용하여 구성을 확인해 보세요. VPC 서비스 제어를 처음 접하는 고객이라면 제품 문서와 개요 동영상을 검토하시는 것이 좋습니다.

이제 애플리케이션 부하 분산기로 에지에서 커스텀 코드를 실행하세요

Thu, 16 Jan 2025 02:53:00 +0000

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

애플리케이션 부하 분산기는 Google Cloud에서 안정적으로 웹 애플리케이션을 배포하는 데 필수입니다. Google Cloud의 부하 분산기가 폭넓은 맞춤설정을 제공하지만, 때로는 더 큰 프로그래밍 가능성(programmability)이 필요하기도 합니다.

Google Cloud는 최근 발표에서 애플리케이션 부하 분산기용 서비스 익스텐션 프로그램 플러그인 프리뷰 버전을 선보였습니다. 이제 완전 관리형 Google 환경을 사용해 최적의 지연 시간으로 요청/응답 경로에서 직접 자체 커스텀 코드를 실행하여 비즈니스 요구사항에 맞게 부하 분산기를 맞춤설정할 수 있습니다. 코드만 입력하면 나머지는 Google Cloud가 처리합니다. 무거운 컴퓨팅 작업을 직접 관리하고 싶다면 현재 애플리케이션 부하 분산기의 정식 버전으로 제공되는 서비스 익스텐션 프로그램의 개요를 살펴보세요.

서비스 익스텐션 프로그램 플러그인은 다음 사용 사례를 지원합니다.

헤더 추가: 애플리케이션이나 특정 고객에 적합한 새 헤더를 만들거나 요청 및 응답을 위한 새 헤더를 삽입합니다.
헤더 조작: 기존 요청 및 응답 헤더를 재작성합니다. 또는 백엔드로 전달되는 과정이나 클라이언트에게 응답하는 중에 클라이언트 헤더를 재정의합니다.
보안:클라이언트 요청 또는 응답 헤더에 기반한 커스텀 토큰 인증 등의 고급 보안 정책을 작성하고 플러그인 내에서 시행 결정을 내립니다.
커스텀 로깅: 사용자 정의 헤더나 커스텀 데이터를 Cloud Logging에 로깅합니다.
예외 처리: 특정 응답 클래스에 대해 클라이언트를 커스텀 오류 페이지로 리디렉션합니다.

HTML 재작성: Google reCAPTCHA 통합이나 Google 애널리틱스 태그 지정을 위해 원본에서 HTML을 재작성합니다.

aside_block: <ListValue: [StructValue([('title', '$300로 Google Cloud 네트워킹을 사용해 보세요'), ('body', <wagtail.rich_text.RichText object at 0x7f663a452fd0>), ('btn_text', '무료로 빌드 시작하기'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/products?#networking'), ('image', None)])]>

코드를 실행할 수 있는 곳

서비스 익스텐션 프로그램은 전 세계에 분산된 Google 네트워크 에지의 요청 및 응답 경로에서 실행됩니다. 이제 서비스 익스텐션 프로그램 플러그인이 전역 외부 애플리케이션 부하 분산기의 기존 트래픽 익스텐션 프로그램에 포함되어 제공됩니다. 트래픽 익스텐션 프로그램은 Cloud CDN 및 Cloud Armor 다음에 실행되지만 트래픽이 백엔드에 도착하기 전에 실행됩니다. Cloud CDN의 서비스 익스텐션 프로그램 지원도 앞으로 출시될 예정입니다. 또한 서비스 익스텐션 프로그램 플러그인은 리전 간 내부 부하 분산기에서 경로 및 트래픽 익스텐션 프로그램의 일부로 지원됩니다.

서비스 익스텐션 프로그램 아키텍처

서비스 익스텐션 프로그램 플러그인은 애플리케이션 부하 분산기 요청/응답 경로의 일부로 실행되는 가벼운 컴퓨팅 작업을 위해 설계되었습니다. 플러그인은 WebAssembly(Wasm) 기반으로 빌드되어 다음과 같은 장점이 있습니다.

네이티브 수준의 실행 속도, 한 자릿수 밀리초 수준의 시작 시간
Rust와 C++를 비롯해 다양한 프로그래밍 언어 지원
플랫폼 간 이식성으로 다양한 배포에서 같은 플러그인을 실행하거나 로컬에서 실행해 테스트 가능
샌드박스 환경에서 플러그인 로직을 실행하는 등의 보안 기능

서비스 익스텐션 프로그램 플러그인은 Proxy-Wasm을 사용합니다. 이는 Wasm 모듈의 네트워크 프록시 연결을 위한 표준 API를 제공하는 Google 지원 오픈소스 프로젝트입니다.

서비스 익스텐션 프로그램 플러그인을 실행하기 위해 Google Cloud에서는 부하 분산기와 같은 대규모 멀티 테넌트를 지원하면서도 확장성이 유연한 컴퓨팅 플랫폼을 빌드했습니다. 플러그인은 완전 관리형이며 트래픽 수요를 충족하기 위해 동적 샤딩과 자동 확장 기능을 제공합니다. 이 아키텍처는 다음을 지원합니다.

확장성: 필요에 따라 트래픽 패턴의 변동에 맞춰 많은 Wasm 호스트로 수평 확장할 수 있습니다.
짧은 지연 시간: 부하 분산기와 Wasm 호스트 사이에 추가 프록시가 없습니다. 프록시리스이자 서버리스인 이 아키텍처로 경로의 지연 시간을 더욱 최적화할 수 있습니다.

다음 단계

서비스 익스텐션 프로그램 플러그인을 시작하려면 로컬 테스트 툴킷이 있는 샘플 저장소(계속 업데이트 예정)를 확인하고 문서의 빠른 시작 가이드를 따르세요.

속도, 규모, 안정성: 25년간 발전해 온 Google 데이터 센터 네트워킹

Thu, 16 Jan 2025 02:02:00 +0000

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

로마는 하루아침에 이루어지지 않았습니다. Google의 네트워크도 마찬가지입니다. 25년의 세월 동안 Google Cloud는 아주 놀라울 정도로 큰 규모와 기술적인 정교함을 갖춘 네트워크 인프라를 빌드했습니다.

Google 네트워크 인프라가 초기에는 비교적 단순했기 때문에 더욱 놀라운 발전이라고 할 수 있습니다. 하지만 사용자층과 서비스 수요가 급증하면서 전례 없는 규모의 데이터와 트래픽을 처리할 수 있고 시간이 지나면서 변화하는 워크로드에 따라 동적 트래픽 패턴에 적응할 수 있는 네트워크가 필요하다는 걸 깨달았습니다. 이는 수많은 엔지니어링 혁신과 획기적인 발전을 수놓아 온 25년간의 여정의 원동력이 되었으며, 궁극적으로 초당 13페타비트의 바이섹션 대역폭으로 확장할 수 있는 현재의 5세대 Jupiter 데이터 센터 네트워크 아키텍처로 이어지는 성과를 이루었습니다. 이 데이터 속도는 네트워크를 통해 전 세계 인구 80억 명이 동시에 1.5Mbps로 영상 통화를 할 수 있는 수준입니다.

현재 Google Cloud는 전 세계에 수백 개의 Jupiter 패브릭을 배포했으며 동시에 수백 개의 서비스, 수십억 명의 일일 활성 사용자, Google Cloud의 모든 고객, 세계 최대 규모의 머신러닝 학습 및 서빙 인프라를 지원하고 있습니다. 차세대 데이터 센터 네트워크 인프라를 살펴보면서 Google Cloud의 여정에 대해 더 자세히 이야기해 보겠습니다.

aside_block: <ListValue: [StructValue([('title', '$300로 Google Cloud 네트워킹을 사용해 보세요'), ('body', <wagtail.rich_text.RichText object at 0x7f663a084850>), ('btn_text', '무료로 빌드 시작하기'), ('href', 'http://console.cloud.google.com/freetrial?redirectpath=/products?#networking'), ('image', None)])]>

기본 원칙

Google Cloud 네트워크는 다음의 몇 가지 핵심 원칙에 기반하여 진화하였습니다.

어디서나 무엇이든: Google Cloud의 데이터 센터 네트워크는 동일한 네트워크 패브릭 내에서 10만 개 이상의 서버 어디에나 대규모 작업을 배치하고 필요한 스토리지 및 지원 서비스에 빠르게 액세스할 수 있도록 함으로써 효율성과 단순성을 지원합니다. 이러한 규모는 애플리케이션의 내부 및 외부 워크로드 성능을 개선하고 내부 단편화 문제를 해소합니다.
예측 가능하고 짧은 지연 시간: 대역폭 여유 공간을 프로비저닝하고 99.999%의 네트워크 가용성을 유지하며 엔드 호스트와 패브릭 협력을 통해 정체를 사전에 관리하여 일관된 성능을 우선으로 테일(tail) 지연 시간을 최소화합니다.
소프트웨어 정의 및 시스템 중심: 유연성과 민첩성을 제공하는 소프트웨어 정의 네트워킹(SDN)을 활용하여 전역 네트워크에서 격주로 수십 개의 새로운 기능을 검증하고 전 세계적으로 출시합니다.
점진적 진화와 동적 토폴로지: 점진적 진화는 네트워크를 전면적으로 중지하는 대신 세부적으로 수정하는 데 도움이 되며, 동적 토폴로지는 변화하는 워크로드 수요에 지속적으로 적응하는 데 도움이 됩니다. 광회선 교환과 SDN의 조합을 통해 물리적 인플레이스 업그레이드 및 단일 패브릭에서 여러 세대의 하드웨어와 호환되며 끊임없이 진화하는 이종 네트워크를 지원할 수 있습니다.
트래픽 엔지니어링 및 애플리케이션 중심 서비스 품질(QoS): 트래픽 흐름을 최적화하고 서비스 품질을 보장하여 각 애플리케이션의 니즈에 맞게 네트워크를 조정할 수 있습니다.

Google Cloud의 업무는 위의 원칙을 통합하는 데서 시작됩니다. 네트워크는 스토리지에서 AI까지 기타 모든 컴퓨팅 서비스에 안정성을 제공하는 기반입니다. 따라서 네트워크를 최대한 오래 안전하게 보호하고 장애 발생 시 영향을 최소화해야 합니다. 이러한 기본적인 책임을 수행하기 위해 Google Cloud는 전역 네트워크의 수백 개의 클러스터와 수백만 개의 포트에서 발생하는 모든 일시적 오류1를 엄격하게 정의하고 모니터링합니다. 자체 소프트웨어 정의 Jupiter 네트워크가 이전 버전의 데이터 센터 네트워크보다 50배 더 높은 안정성을 제공한다는 사실에서 알 수 있듯 Google Cloud의 안정성은 진화하고 있습니다.

2015년 - Jupiter, 최초의 페타비트 네트워크

Google Cloud는 영향력 있는 논문에서 Jupiter 데이터 센터 네트워크가 상용 스위치 실리콘, Clos 토폴로지 및 소프트웨어 정의 네트워킹(SDN)을 활용하여 총대역폭 1.3Pbps로 확장될 수 있음을 소개했습니다. 이 세대의 Jupiter는 Google 네트워킹팀이 자체 개발한 5세대 데이터 센터 네트워크의 결정체입니다. 연구 당시 Google 데이터 센터 한 곳에서 측정된 이 데이터 전송 속도는 전 세계 인터넷에 대해 추정한 총 IP 트래픽 데이터 속도보다 더 빨랐습니다.

2022년 - 초당 6페타비트 지원

2022년에 Google Cloud는 광회선 교환(OCS), 파장 분할 다중화(WDM), 확장성이 뛰어난 Orion SDN 컨트롤러가 긴밀히 통합되어 Jupiter 네트워크가 6Pbps 이상으로 확장되었다고 발표했습니다. 이 기술 덕분에 점진적인 네트워크 빌드, 성능 향상, 비용 절감, 전력 소비 절감, 동적 트래픽 관리, 원활한 업그레이드 등 다양한 발전을 이룰 수 있었습니다.

2023년 - 초당 13페타비트 네트워크

Google은 네트워크 코어에서 기본 400Gbps의 링크 속도를 지원하도록 Jupiter를 더욱 강화했습니다. Jupiter 네트워크의 기본 빌딩 블록(집계 블록이라고 함)은 현재 엔드 호스트와 데이터 센터의 나머지 부분 모두에 대해 400Gbps로 연결되는 포트 512개로 구성되며 블록당 양방향 비차단 대역폭이 204.8Tbps로 집계됩니다. 이러한 블록을 64개 지원하므로 총 바이섹션 대역폭은 64x204.8Tbps = 13.1Pbps입니다. 이 기술은 1년 넘게 Google 프로덕션 데이터 센터를 구동하는 데 사용되고 있으며 AI, 머신러닝, 웹 검색, 기타 데이터 집약적 애플리케이션의 급속한 발전을 이끌어 왔습니다.

2024년 이후 - AI 시대를 위한 궁극의 네트워킹

20년 이상 이어온 데이터 센터 네트워킹 분야의 혁신을 기념하면서 Google Cloud는 AI 시대를 준비하기 위해 차세대 네트워크 인프라의 방향을 계획하고 있습니다. 일례로, NVIDIA ConnectX-7 네트워킹이 탑재된 A3 Ultra VM의 출시를 앞두고 관련 네트워킹 인프라 요구사항에 대해 작업 중입니다. 이는 RoCE(RDMA over Converged Ethernet)를 통해 GPU 간 트래픽에 대해 서버당 3.2Tbps의 비차단을 지원하고 Google Cloud에서 NVIDIA GB200 NVL72를 기반으로 한 향후 제품을 제공할 수 있게끔 합니다.

Google Cloud는 향후 몇 년 동안 포트 단위 및 네트워크 전반에 걸쳐 네트워크의 규모와 대역폭을 크게 확장할 예정입니다. 또한 전송 및 정체 제어 스택과 같은 엔드 호스트 통합의 경계를 계속해서 확장하고 네트워크 단계를 간소화하여 더욱 엄격하게 테일 지연 시간을 단축하려고 합니다. 실시간 토폴로지 엔지니어링, 컴퓨팅 스택 및 스토리지 스택과의 보다 긴밀한 통합, 호스트 기반 부하 분산 기법의 지속적인 조정을 통해 네트워크 안정성을 더 강화하고 지연 시간을 더 줄일 수 있습니다. 이러한 혁신을 통해 Google Cloud의 네트워크는 전 세계 사용자의 삶을 풍요롭게 하는 혁신적인 애플리케이션 및 서비스의 근간이 되는 동시에 Google Cloud의 내부 서비스와 Google Cloud 제품을 구동하는 획기적인 AI 기능도 지원합니다.

앞으로 25년 동안 Google 네트워킹에 펼쳐질 미래를 기대하며 이러한 도전과제와 기회를 받아들이고자 합니다.

추가 자료

Jupiter의 성공: Google 데이터 센터 네트워크의 Clos 토폴로지와 중앙화된 제어 기술 10년, SIGCOMM ‘15 [자료]

상용 스위치 실리콘, Clos 토폴로지 및 소프트웨어 정의 네트워킹(SDN)을 활용한 첫 번째 Jupiter 데이터 센터 네트워크의 여정
2012년 프로덕션에 처음 배포됨

아폴로 계획: 데이터 센터 규모로 광회선 교환 도입, arxiv.org, 2022년 [자료]

2013년 프로덕션에 처음 배포됨

Orion: Google의 소프트웨어 정의 네트워킹 컨트롤 플레인. NSDI ‘21 [자료]

데이터 센터와 광역 통신망에 사용되는 Google의 확장 가능한 의도 기반 고성능 분산 SDN 플랫폼
2016년 프로덕션에 처음 배포됨

Jupiter의 발전: 광회선 교환과 소프트웨어 정의 네트워킹을 통한 Google의 데이터 센터 네트워크 혁신, SIGCOMM ’22 [자료]

배경 기술: OCS(2013년), Orion SDN(2016년), 200Gbps 네트워킹(2020년), 직접 연결 토폴로지(2017년), 동적 트래픽 엔지니어링(2018년), 동적 토폴로지 엔지니어링(2021년)

Swift: 데이터 센터 정체 제어에 간단하고 효과적인 지연, SIGCOMM ‘20 [자료]

Swift는 하드웨어 타임스탬프와 지연 목표를 갖춘 AIMD 제어를 사용하는 정체 제어 프로토콜로, 짧은 RPC에서는 흐름 완료 시간을 줄이고 긴 RPC에서는 처리량을 증가시켜 Google 데이터 센터에서 뛰어난 성능을 제공함
2017년 프로덕션에 처음 배포됨

PLB: 네트워크 부하 분산에 간단하고 효과적인 정체 신호, SIGCOMM ‘22 [자료]

Protective Load Balancing(PLB)은 네트워크 정체를 줄이고 혼잡한 연결 경로를 무작위로 변경하여 성능을 향상하는 단순하고 효과적인 호스트 기반 부하 분산 설계로, 패킷 재정렬을 최소화하기 위해 유휴 기간 후에 경로 변경을 선호함
2020년 프로덕션에 처음 배포됨

_{1. 데이터 센터 네트워크의 통계적으로 유의미한 상당수의 네트워크 흐름이 정의된 임곗값을 초과하여 완전히 또는 부분적으로 중단되는 시간입니다.}