네트워킹

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

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

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

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

정적 규칙을 넘어서: 외부 권한 부여 (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 0x7f515fc15a60>)])]>

이를 통해 외부 서비스는 에이전트나 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 0x7f5164305af0>), ('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 0x7f5165a633a0>)])]>

이 작업은 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 0x7f5165a63940>)])]>

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

애플리케이션을 위한 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 0x7f51640918e0>)])]>

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

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

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

이제 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 0x7f5167570640>), ('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 0x7f51650f51c0>), ('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 0x7f515edada90>), ('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 0x7f51646bc730>), ('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. 데이터 센터 네트워크의 통계적으로 유의미한 상당수의 네트워크 흐름이 정의된 임곗값을 초과하여 완전히 또는 부분적으로 중단되는 시간입니다.}

업계 최초 Cloud Interconnect의 Application Awareness 도입

Wed, 15 Jan 2025 17:26:00 +0000

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

비즈니스 크리티컬 애플리케이션의 클라우드 이전이 늘어나면서 멀티 클라우드 아키텍처가 보편화되고 있습니다. 지난해 Google Cloud에서는 하이브리드 및 멀티 클라우드 연결을 혁신, 간소화하고 조직이 분산 애플리케이션을 쉽게 빌드할 수 있도록 지원하는 크로스 클라우드 네트워크를 선보였습니다. 조직들은 AI/ML 및 기타 관리형 서비스를 활용하여 인프라를 현대화하는 상황에서 운영 복잡성을 줄이고 총소유비용(TCO)을 절감하기 위해 크로스 클라우드 네트워크를 도입했습니다.

SLA가 보장하는 더 나은 애플리케이션 경험을 제공하고 정확한 예산 책정과 리스크 완화를 위해 지출 예측 가능성을 확고히 해달라는 요구가 높아지고 있습니다. 오늘 Google Cloud는 이러한 변화하는 요구를 해결하고 분산 애플리케이션에 가장 적합한 네트워크 환경을 제공하는 데 도움이 되는 크로스 클라우드 네트워크의 새로운 혁신 기능을 발표하게 되어 매우 기쁩니다. 새로운 혁신 기능은 다음과 같습니다.

업계 최초 Cloud Interconnect의 Application Awareness를 통해 트래픽 우선순위 지정
Cloud Interconnect의 예측 가능한 가격으로 TCO 절감
VPC 흐름 로그로 Cloud Interconnect의 모니터링 가능성 통합
프로그래밍 가능성과 새로운 프로듀서를 기반으로 서비스 네트워킹을 개선하는 기타 혁신 기능

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

업계 최초 Cloud Interconnect의 Application Awareness를 통해 트래픽 우선순위 지정

Cloud Interconnect는 Google Cloud에 대해 SLA에서 보장하는 강력한 고대역폭 연결을 지원합니다. Cross-Cloud Interconnect를 통해 Google과 다른 클라우드 제공업체 사이의 전용 비공개 연결을 구현합니다. 이러한 기능은 하이브리드 멀티 클라우드 분산 애플리케이션을 빌드하는 기반이 됩니다.

Cloud Interconnect를 통해 트래픽 우선순위를 지정하는 기능의 부족은 예전부터 고객들의 고질적인 문제였으며 이 때문에 대역폭을 과도하게 초과 프로비저닝하거나 정체 기간 동안 성능이 저하될 리스크가 존재합니다. 이로 인해 비용 증가, 비효율적인 리소스 사용률, 잠재적인 비즈니스 운영 중단이 발생할 수 있습니다.

이러한 트래픽 우선순위 지정의 필요성을 해결하기 위해 Google Cloud에서는 Cloud Interconnect의 Application Awareness를 프리뷰 버전으로 선보이고 있습니다. Google Cloud는 Cloud Interconnect를 통해 트래픽 우선순위 지정이라는 중요한 문제를 해결할 수 있도록 관리형 트래픽 차별화 솔루션을 제공하는 최초의 주요 클라우드 서비스 제공업체입니다. Application Awareness는 트래픽 클래스별 엄격한 우선순위와 트래픽 클래스 기준 대역폭 공유라는 두 가지 정책 중에서 유연하게 선택할 수 있도록 지원합니다.

Application Awareness를 지원하는 Cloud Interconnect를 통한 트래픽 처리

Cloud Interconnect의 Application Awareness는 다음과 같은 다양한 비즈니스 이점을 제공합니다.

비즈니스에 중요한 트래픽의 우선순위 지정: Cloud Interconnect를 통해 연결된 상태에서 정체 기간 동안 Google Cloud에서 이그레스되는 낮은 우선순위 트래픽이 높은 우선순위 트래픽에 악영향을 주지 않도록 합니다.
저렴한 총소유비용(TCO): Cloud Interconnect 대역폭을 효율적으로 사용하고 적절한 용량 계획에 따라 사용 시 링크의 과도한 초과 프로비저닝을 방지할 수 있습니다.
완전 관리형 SLA 지원 솔루션: Cloud Interconnect SLA에서 보장하는 Google 관리형 솔루션으로 안심하고 사용할 수 있습니다. 복잡성, 수작업 오버헤드, 높은 운영 비용을 가중하는 네트워크 어플라이언스를 포함한 값비싼 자체 관리형 해결 방법에 비해 이점이 많습니다.

Cloud Interconnect의 Application Awareness에 대한 모든 정보는 이 솔루션 요약에서 확인할 수 있습니다.

"하이브리드 및 멀티 클라우드 아키텍처가 보편화되면서 기업들은 디지털 인프라 전반에서 데이터 흐름과 애플리케이션 성능을 최적화해 줄 지능형 연결 솔루션을 찾고 있습니다. Google Cloud에서 지원하는 Cloud Interconnect의 Application Awareness는 패킷 분류와 우선순위 지정 기능을 기반으로 비즈니스에 중요한 교환을 최적화할 수 있습니다. 이 기능을 다양한 데이터 트래픽 유형에 폭넓게 적용할 수 있으므로 기업은 더욱 세부적인 제어와 인프라 복원력, 비용 절감 효과를 얻을 수 있게 됩니다." - Taranvir Singh, IDC Cloud Networking Services 연구 관리자

Cloud Interconnect의 예측 가능한 비용으로 TCO 절감

클라우드로 마이그레이션하는 조직에는 예측 가능한 데이터 전송 비용이 중요합니다. 클라우드 도입 여정을 시작하거나 여러 환경에 걸친 분산 애플리케이션을 수용하려는 고객은 하이브리드 및 멀티 클라우드 환경 간 데이터 전송과 관련된 비용을 예상하는 데 어려움을 겪을 수 있습니다. 특히 측정된 사용량에 따른 가격 변동성이 이러한 예측 불가의 주요 원인입니다.

Google Cloud에서는 Dedicated Interconnect 및 Cross-Cloud Interconnect의 고정 가격 옵션을 제공합니다. 고정 가격을 선택한 고객에게는 전송된 트래픽 양이 아닌 포트별 시간당 고정 가격으로 비용이 부과되므로 데이터 전송 비용의 변동성이 사라집니다. 예측 가능한 월별 비용 덕분에 조직은 쇼백 또는 차지백을 더욱 쉽게 구현하여 운영 효율성을 높일 수 있습니다.

VPC 흐름 로그로 Cloud Interconnect의 모니터링 가능성 통합

VPC 흐름 로그는 Google Cloud 내 네트워크 트래픽을 흐름 수준에서 파악할 수 있게 해줍니다. 가상 머신에 송수신되는 패킷을 기록한 이 VPC 흐름 로그를 사용하면 성능 모니터링과 문제 해결뿐 아니라 네트워크 포렌식, 보안 및 규정 준수, 비용 최적화를 목적으로 네트워크 트래픽을 분석할 수 있습니다.

Google Cloud는 일관되고 사용하기 쉬운 모니터링 가능 환경을 제공하고자 VPC 흐름 로그의 범위를 Dedicated Interconnect, Partner Interconnect, Cross-Cloud Interconnect, Cloud VPN을 통한 네트워크 트래픽까지 확장했습니다. 이제 서브넷뿐 아니라 VLAN 연결, VPN 터널에 관한 흐름 로그를 생성하고 Google Cloud 내 트래픽과 마찬가지로 5튜플(소스 IP, 대상 IP, 소스 포트, 목적지 포트, 프로토콜) 세부사항을 수신할 수 있습니다. 서브넷에 대한 VPC 흐름 로그를 이미 사용 설정했다면 이 서브넷과 온프렘 또는 크로스 클라우드 환경 간의 모든 트래픽에는 관련 하이브리드 연결 메타데이터가 주석으로 달립니다.

또한 VPC 흐름 로그를 사용하면 Cloud Interconnect에 Application Awareness 정책을 구성하거나 미세 조정할 때 우선순위를 적용할 특정 트래픽 유형을 더 쉽게 식별할 수 있고 트래픽 패턴, 대역폭 사용률, 트래픽 클래스 성능을 지속적으로 파악할 수 있습니다.

Cloud Interconnect의 VPC 흐름 로그를 Flow Analyzer로 시각화한 화면

Flow Analyzer는 모든 VPC 흐름 로그 고객에게 제공되며 복잡한 SQL 쿼리를 작성하지 않고도 상위 사용자를 포함한 네트워크 트래픽 흐름을 쉽게 식별하고 시각화할 수 있습니다. 또한 모든 VPC 흐름 로그를 원하는 모니터링 가능성 파트너의 서비스 또는 Cloud Logging, BigQuery와 같은 Google Cloud 서비스와 통합하고 분석할 수도 있습니다.

하이브리드 연결의 VPC 흐름 로그 및 Flow Analyzer는 모두 프리뷰 버전으로 제공됩니다.

프로그래밍 가능성과 새로운 프로듀서를 기반으로 서비스 네트워킹 개선

크로스 클라우드 네트워크의 핵심 원리는 DevOps, NetOps, SecOps팀이 다른 팀에 지원을 요청하지 않고도 애플리케이션을 효율적으로 제공할 수 있도록 하는 것입니다. 대부분의 애플리케이션에는 보안, 모니터링, 로깅 등을 위한 특정 커스텀 기능이 필요하지만 이러한 기능은 바로 사용 가능한 형태로 제공되지 않으며, SaaS, 서드 파티 또는 고객 관리형 등 유형에 상관없이 최고의 서비스를 환경 전반에 통합하는 일은 운영 측면에서 복잡할 수 있습니다. 현재 Google Cloud는 서비스 중심 접근방식을 개선하고 비즈니스 민첩성을 높이기 위해 혁신 기능과 파트너십을 확장하고 있습니다.

Cloud Load Balancing을 위한 서비스 확장 프로그램 플러그인 소개

애플리케이션 부하 분산기를 위한 서비스 익스텐션 프로그램 플러그인의 프리뷰 버전을 소개합니다. 이 기능은 WebAssembly(Wasm)를 사용해 네트워킹 요청/응답에 다양한 맞춤설정을 추가할 수 있도록 지원합니다. 서비스 확장 프로그램은 워크로드의 데이터 경로에 SaaS 솔루션이나 자체 맞춤설정 솔루션을 삽입할 수 있는 프로그래밍 가능한 개방형 데이터 영역을 제공합니다.

부하 분산기를 위한 서비스 확장 프로그램 플러그인은 커스텀 로직으로 애플리케이션을 보호하거나, http 헤더 또는 URL을 재작성하여 백엔드로의 트래픽을 최적화하거나, 트래픽 모니터링에 도움이 되는 커스텀 로깅, 규정 준수 사용 사례를 위한 감사 로깅 등 다양한 사용 사례를 지원합니다. Google Cloud에서는 이러한 많은 운영 사례에 유용한 여러 예시 플러그인도 출시했습니다(여기 참조).

Private Service Connect를 위한 새 프로듀서로 서비스 중심 여정 가속화

관리형 서비스를 통한 애플리케이션 현대화가 활발히 진행되는 상황에서 Private Service Connect를 사용하면 자체 VPC에서 Google, 기업 자체 서비스 또는 다양한 서드 파티 파트너 서비스 포트폴리오를 잇는 비공개 보안 연결을 손쉽게 구축할 수 있습니다.

Private Service Connect 엔드포인트 및 인터페이스를 위한 새로운 데이터 및 AI 프로듀서를 소개합니다. 구체적으로 다음과 같습니다.

Vertex AI Prediction(정식 버전)
Vertex AI Search(정식 버전)
Vertex AI Training(프리뷰 버전)
Apache Kafka용 관리형 서비스(정식 버전)
Apache Flink용 BigQuery(프리뷰 버전)
Datastream(프리뷰 버전)
Cloud Composer 3(정식 버전)

이러한 AI 및 분석 서비스를 위한 새로운 프로듀서 덕분에 이제는 네트워크 연결을 간소화하고 일관된 보안 정책을 애플리케이션에 적용할 수 있습니다.

“디지털 결제 업계 리더인 PayPal은 전 세계 200개 이상의 시장에서 상거래를 혁신하고 있습니다. PayPal 서비스를 사용하는 수많은 고객과 판매자에게 최고의 서비스를 제공하기 위해 PayPal 네트워크는 높은 안정성, 보안, 성능을 제공해야 합니다.

크로스 클라우드 네트워크 솔루션의 일부로서 자사 데이터 분석과 AI 서비스를 안전하게 연결해 주는 Private Service Connect를 이용하면서 PayPal은 혁신적이고 새로운 PayPal 서비스를 고객에게 제공하는 일에 주력할 수 있게 되었습니다.” - Saikrishna Kotha, PayPal 인프라 플랫폼 부문 책임자 겸 전무이사

자세히 알아보기

Google Cloud는 크로스 클라우드 네트워크를 통해 하이브리드 및 멀티 클라우드 네트워크에서 워크로드, 데이터, 사용자를 간소화하고 보호할 수 있도록 지원하고 있습니다. 크로스 클라우드 네트워크에 대한 모든 정보는 여기에서 확인할 수 있으며, Google Cloud의 혁신적인 기술에 대해 자세히 알고 싶다면 Google Cloud App Dev and Infrastructure Summit에 참석하시기 바랍니다.

Google Cloud 네트워크 보안의 핵심 - Cloud NGFW

Tue, 20 Aug 2024 00:00:00 +0000

최근 Generative AI 의 기술이 크게 주목 받으면서 클라우드 환경으로의 전환이 더욱 가속화 되고 있으며 다양한 워크로드와 애플리케이션을 안전하게 보호하고 사이버 위협으로부터 방어하기 위한 차세대 방화벽 (NGFW) 솔루션에 대한 요구사항도 증가하고 있습니다.

Google Cloud 는 이러한 요구에 부응하기 위해 기존 VPC firewall 에서 제공되던 보안 기능에 보다 다양한 차세대 보안 기능이 추가 된 클라우드 네이티브 NGFW 서비스인 Google Cloud NGFW 을 제공하고 있습니다.

Cloud NGFW 은 다음과 같은 장점을 제공합니다.

Distributed Firewall : Cloud NGFW 은 분산 방화벽 서비스 기반으로 동작합니다. NGFW 의 보안 규칙은 각 워크로드에서 호스트 기반으로 동작하여 보다 정확하고 세분화 된 트래픽 보호를 수행합니다.
Micro Segmentation : 방화벽 정책과 IAM 기반 태그의 조합은 VPC 네트워크와 조직에서 단일 가상 머신까지 East-West 및 North-South 트래픽을 모두 세밀하게 제어할 수 있습니다.
차세대 고급 방화벽 기능 : L3, L4 기반의 기본 방화벽 정책 뿐만 아니라 Geolocation, FQDN, Threat Intelligence, Intrusion Prevention, TLS decryption 등 다양한 차세대 방화벽 기능을 클라우드 환경에서 구현할 수 있습니다.

Cloud NGFW Policy (정책) & Rule (규칙)

Google Cloud NGFW 을 사용하기 위해서는 정책 (Policy) 와 규칙 (Rule), 그리고 이러한 것들이 어떻게 구성되고 동작되는지에 대해 먼저 이해하는 것이 필요합니다.

먼저 Firewall Policy 는 여러 Firewall Rule 들을 그룹화한 하나의 정책 묶음입니다. 이러한 Policy 는 IAM Role 에 따라 아래 그림과 같이 단일 프로젝트 내의 리소스뿐만 아니라 특정 프로젝트들을 그룹화 한 폴더 및 전체 조직에도 한번에 모두 방화벽 정책을 업데이트하고 관리할 수 있는 기능을 제공 합니다. 이를 계층적 정책 (Hierarchical Firewall Policy) 라고 합니다.

Hierarchical Firewall Policy 를 사용할 경우 특정 프로젝트 혹은 폴더, 또는 전체 조직의 리소스에서 필수로 사용해야 할 방화벽 정책과 규칙을 조직의 관리자가 중앙에서 생성하여 배포하고 관리할 수 있습니다.

예를 들어 특정 폴더나 프로젝트에 포함되어 있는 리소스들은 온프레미스와 같은 특정 네트워크와의 통신이나 특정 애플리케이션 통신만 사용하여야 하는 경우, 혹은 L7 inspection 과 같은 고급 기능을 적용해야 할 경우 관리자가 이러한 규칙을 강제하기 위해 Hierarchical Firewall Policy 정책을 사용할 수 있습니다. 그리고 그 외의 트래픽들에 대한 규칙에 대해서는 Allow, Deny 외에 Goto_next 옵션을 통해 하위 정책에서 평가될 수 있도록 규정할 수 있습니다.

Rule 은 방화벽 정책에 의해 평가되어야 할 트래픽의 조건과 이에 대한 조치 방법을 정의합니다. Ingress, Egress 등 트래픽의 방향성과 IP, Protocol, Port number 등의 트래픽 조건을 정의하며 이러한 트래픽에 대한 차단 혹은 허용 여부를 결정하는 규칙입니다.

Rule 은 기존의 VPC Firewall Rule 을 사용하여 L3, L4 기반의 제어를 개별 VPC 단위로 구현할 수 있으나 만약 L7 inspection 등과 같은 NGFW Rule 을 사용하기 위해서는 Firewall Policy 를 사용하여야 합니다.

Cloud NGFW 은 다음과 같은 Service Tier 별로 차별화 된 방화벽 기능을 제공합니다. Cloud NGFW Pricing 페이지에서 보다 자세한 가격 정책을 확인할 수 있습니다.

Cloud Next Generation Firewall Essentials
Cloud Next Generation Firewall Standard
Cloud Next Generation Firewall Enterprise

Cloud NGFW Essentials

Cloud NGFW Essentials 는 Google Cloud 에서 제공하는 기본 방화벽 서비스와 기능들을 제공합니다. 여기에는 다음과 같은 기능들을 포함합니다 :

VPC Firewall Rule 기능을 이용하여 개별 VPC 단위의 송수신 트래픽을 허용하거나 차단할 수 있으며 Network Tag 및 Service account 기반의 제어를 제공 합니다.
Global Network Firewall Policy 와 Regional Network Firewall Policy 를 통해 모든 지역 또는 특정 지역에 적용되는 Firewall Policy 를 구분하고 Rule 을 그룹화 할 수 있습니다.
IAM 관리 태그 (IAM-Governed Tag) 를 사용하여 Google Cloud 의 리소스에 대한 마이크로 세그멘테이션 및 컨트롤을 제공합니다. 기존의 Network Tag 를 대신하여 IAM-Governed Tag 를 사용할 경우 특정 권한을 가진 사용자 (ID) 에서 엄격히 관리됩니다. 네트워크 방화벽 정책 규칙에서 이러한 태그를 참조하여 지역 및 네트워크 전반에서 보다 엄격하고 세분화 된 액세스 제어를 수행할 수 있습니다.

Address Group 기능을 이용하여 다수의 IP Address 혹은 IP Range 를 하나의 오브젝트처럼 사용할 수 있습니다. 기업에서 자체적으로 보유하고 있는 IP 데이터베이스도 Address Group 을 이용하여 방화벽 규칙에 사용할 수 있습니다.

Cloud NGFW Standard

Cloud NGFW Standard 는 악의적인 공격으로부터 Google Cloud 인프라를 보호하는 보다 향상 된 기능을 제공하기 위해 Cloud NGFW Essentials 에서 다음과 같은 기능을 추가로 제공 합니다.

FQDN (Fully Qualified Domain Name) Object 기반의 방화벽 정책을 제공 합니다. 특정 도메인에 대한 방화벽 규칙을 설정하면 Cloud NGFW 은 해당 도메인에 대한 DNS 쿼리를 수행하여 IP 정보를 획득하여 정책을 평가하므로 보다 간편한 방화벽 정책 설정과 운영을 제공 합니다.
Threat Intelligence 정책을 제공합니다. 공격에 사용 된 최신의 공격자 IP 리스트를 포함하는 다양한 최신의 IP 데이터베이스를 기반으로 한 차단 정책을 사용하여 인프라를 보호할 수 있습니다.

Geolocation 오브젝트를 이용하여 특정 국가와의 통신을 허용하거나 차단할 수 있습니다.

Cloud NGFW Enterprise

Cloud NGFW Enterprise 는 위협 및 악의적인 공격으로부터 워크로드를 보호하는 고급 Layer 7 보안 기능을 제공합니다. Malware, Spyware 그리고 C2 공격으로 부터의 보호 기능을 제공하는 침입탐지 (IDS) 및 침입 방지 (IPS) 서비스 - Threat Prevention (powered by Palo Alto Networks) 을 암호화 된 트래픽을 복호화 하는 TLS decryption 기능과 함께 제공 합니다.

Threat Prevention 기능을 사용하면 위협 트래픽을 분석하는 Firewall Endpoint 가 자동으로 배포되며 Cloud Native 형태로 동작하게 됩니다. 이는 별도의 토폴로지 구성이나 트래픽 경로 조정을 위한 설정 변경이 필요하지 않으며 간단한 설정을 통해 손쉬운 구성을 제공되며, 워크로드로 전달되는 트래픽을 자동으로 Firewall Endpoint 로 전달하여 공격 트래픽에 대한 탐지와 방어를 제공합니다.

What’s Next?

Cloud NGFW Document - Cloud NGFW 과 관련된 보다 상세한 정보를 확인해 볼 수 있습니다.
Cloud NGFW Demo - Cloud NGFW 의 데모 동영상을 확인할 수 있습니다.
Codelabs - Cloud NGFW 을 직접 배포하고 설정 해 보시기 바랍니다.

신규 인시던트에 빠르게 대응하도록 도와주는 Personalized Service Health

Mon, 18 Mar 2024 01:00:00 +0000

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

조직에서는 애플리케이션의 상태와 성능을 모니터링하기 위해 다양한 서드 파티 도구를 사용하는 경우가 많습니다. 그러나 서비스 품질 저하가 발생할 때 문제의 원인이 항상 명확하지는 않습니다. 클라우드 제공업체와 관련된 문제인지, 애플리케이션 환경의 문제인지 파악하기 쉽지 않습니다. 최근 Google Cloud에서 발표한 Personalized Service Health 정식 버전에는 Cloud 네트워킹 인시던트에 대한 알림을 고객에게 신속하게 제공하는 신규 인시던트(emerging incident)라는 새로운 기능이 포함되어 있습니다.

신규 인시던트는 머신 기반 알림으로 사용자와 내부 Google SRE팀에 동시에 전달되며, 인시던트에 관한 중요한 첫 게시물이 게시되기까지 걸리는 시간을 크게 단축해 줍니다. Google SRE팀에서 문제를 조사하고 그 영향을 평가하는 중에도 Google Cloud 인시던트가 발생하면 그와 동시에 고객에게 알림이 전송됩니다. 신규 인시던트 알림을 받으려면 지원되는 Cloud 네트워킹 제품에서 Personalized Service Health를 사용 설정하고, 알림을 설정하면 됩니다.

신규 인시던트 관련 커뮤니케이션은 프로젝트 맞춤형으로 실시간 전송되므로, 운영 중단을 해결하고 비즈니스에 미치는 영향을 완화할 조치를 구현하는 데 도움이 됩니다. 물론 Personalized Service Health는 활성 인시던트(Active Incident)에 대한 업데이트를 적시에 전송하므로, 모든 인시던트 정보를 확인할 수 있는 리소스로도 활용할 수 있습니다. 조치를 빨리 취할수록 평균 해결 시간(MTTR)을 더 많이 단축하고 애플리케이션 안정성을 개선할 수 있습니다. 이처럼 실시간으로 맞춤화된 커뮤니케이션은 아래와 같습니다.

Google Cloud 네트워킹 제품의 상태는 다양한 프로브를 사용하여 지속적으로 모니터링됩니다. 시스템에서 성능 저하 또는 서비스 중단을 감지하면 평가된 영향에 따라 고객에게 전달되는 내부 알림을 자동으로 생성하고 대시보드, 로그, 알림, API를 포함한 모든 Personalized Service Health 채널을 통해 전송합니다.

그 후 이벤트가 확인되면 신규 인시던트는 종료되어 확인된 인시던트에 연결됩니다. 네트워크 경로 변경으로 고객에게 미치는 영향이 완화되는 등 이벤트가 단기적으로 발생한 경우에는 확인된 이벤트가 생성되기도 전에 이벤트가 종료될 수 있습니다. 이러한 초기 알림은 고객에게 문제의 근원에 대한 명확한 정보를 제공합니다. 이제 인시던트가 활성화되어 있는 한, 고객은 Google Cloud의 인시던트 대응 프로세스에서 신규(emerging) 및 확인된(confirmed) 인시던트에 대한 업데이트를 모두 적시에 받게 됩니다.

지금 시작하기

Personalized Service Health가 사용 설정되어 있다면 지원되는 제품에 대한 신규 인시던트는 해당 제품을 사용하는 모든 프로젝트에서 기본적으로 사용할 수 있습니다. 신규 인시던트 관리에 관한 자세한 내용은 여기에서 알아볼 수 있습니다. 신규 인시던트 알림 정책은 Service Health 대시보드 내에서 구성할 수 있습니다.

자세한 내용은 Personalized Service Health 문서 및 시작 가이드를 참조하세요. 시작하려면 프로젝트 또는 조직 전반에서 Personalized Service Health를 사용 설정하세요.

지금 바로 클라우드 네트워킹 여정을 시작하세요

Fri, 08 Mar 2024 01:00:00 +0000

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

클라우드 네트워킹은 정말 흥미롭습니다. 눈에 보이지는 않지만 클라우드 네트워킹 없이는 통신이 아예 불가능합니다. Google Cloud의 이 핵심 서비스에 대한 대략적인 개요가 필요하다면 새로 나온 Tour of Cloud Networking 실습을 추천해 드립니다. 이 유용한 실습에 대해 자세히 알려드리겠습니다.

규모

이 실습은 Google의 글로벌 네트워크에 대해 소개합니다. Google Cloud에서 워크로드를 실행하면 얻을 수 있는 주요 이점 중 하나는 수십억 명의 사용자와 고객에게 Google 검색, 지도, YouTube, Google Cloud 등의 서비스를 제공하는 세계적인 규모의 Google 백본 지원 서비스를 활용할 수 있다는 것입니다. 이 실습에서는 리전, 영역, 접속 지점에 대해서도 다룹니다.

핵심 영역

클라우드 네트워킹의 개념을 이해하는 데 도움이 되도록 6개의 빌딩 블록으로 나누어 생각해 보겠습니다. 각 블록은 네트워크 연결, 네트워킹 보안, 서비스 네트워킹, 서비스 보안, 콘텐츠 전송, 관측 가능성(observility)을 나타내며 그룹 네트워킹 기능의 그룹화를 단순화하는 데 도움을 줍니다.

이 실습에서는 각 영역과 관련된 일부 핵심 서비스를 살펴보기 위해 다음 영역을 소개합니다.

가상 프라이빗 클라우드(VPC) 네트워크
네트워크 서비스
네트워크 연결
네트워킹 보안
네트워크 인텔리전스(즉, 관측 가능성)
네트워크 서비스 등급

네트워킹 여정을 시작하세요

지금 시작하려면 Cloud Skills Boost 포털에 로그인하여 Tour of Cloud Networking Lab으로 이동하세요.

다음 리소스에서도 네트워킹에 대해 자세히 알아볼 수 있습니다.

제품: Google Cloud 네트워킹 제품
eBook: Cross-Cloud Network
YouTube: 멀티 클라우드 환경에 맞는 안전한 엔터프라이즈 네트워크 설계
스킬북: 네트워크 엔지니어 학습 과정

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

[Cloud Armor 시리즈 3] Cloud Armor 의 보안 이벤트 확인하기

더 쉬워진 클라우드 전환: Google Cloud에서 마이그레이션 시 데이터 전송 비용 무료

Wed, 07 Feb 2024 01:00:00 +0000

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

Google Cloud는 상호 운용 가능하고 안전하며 개방적인 클라우드 생태계의 번영을 지원하기 위해 최선을 다하고 있습니다. 고객의 비즈니스 니즈가 변화하면 클라우드 또한 유연하게 이러한 변화를 수용할 수 있어야 합니다.

오늘부터 Google Cloud의 사용을 중단하고 다른 클라우드 제공업체나 온프레미스로 데이터를 마이그레이션하기를 원하는 고객은 무료 네트워크 데이터 전송을 통해 Google Cloud 외부로 데이터를 마이그레이션할 수 있습니다. 이 변경사항은 전 세계 모든 고객에게 적용됩니다. 자세한 내용은 여기를 참조하세요.

클라우드 제공업체 변경 시 데이터 전송 비용이 발생하지 않으면 고객이 클라우드 제공업체를 더 쉽게 변경할 수 있게 됩니다. 하지만 이 방법만으로는 근본적인 문제가 해결되지 않습니다. 애당초 많은 고객이 각자가 선호하는 클라우드 제공업체와 협력하지 못하도록 가로막는 것은 불공정하고 제한적인 라이선스 관행입니다.

일부 기존 제공업체는 온프레미스 소프트웨어 독점을 발판으로 클라우드를 독점하고 제한적인 라이선스 관행을 통해 고객을 궁지에 몰아넣으며 경쟁을 훼방하고 있습니다.

라이선스 제한이라는 복잡한 그물망 안에는 고객이 협력할 수 있는 대상과 방법을 선별 및 제한하고, 고객이 특정 경쟁업체의 클라우드를 사용하려 할 경우 비용의 5배를 청구하며, 경쟁업체의 클라우드 인프라 및 필수 소프트웨어의 상호 운용성을 제한하는 행위 등이 포함되어 있습니다. 하지만 이같이 제한하는 관행에는 기술적인 근거도 없을 뿐더러, 고객에게 300%의 비용 증가를 야기할 수 있습니다. 반면, 고객이 클라우드 제공업체 외부로 데이터를 마이그레이션할 때는 최소한의 비용밖에 들지 않습니다.

그러나 고객이 한 제공업체에서 다른 제공업체로 더 쉽게 이동할 수 있게 되더라도 제한적인 라이선스에 매여 있다면, 고객의 선택권을 개선하는 데는 큰 도움이 되지 않습니다. 고객은 기존 제공업체의 지나치게 제한적인 약관이나 징벌적인 라이선스 관행에 얽매이지 않고 비즈니스에 적합한 클라우드 제공업체를 선택할 수 있어야 합니다.

정부와 기업이 기술 사용을 원활하게 확장할 수 있도록 지원할 때 클라우드의 전망이 밝아집니다. 오늘의 발표는 Google Cloud에서 워크로드를 실행하는 크고 작은 조직을 위해 더 많은 가치를 제공하고 데이터 전송을 개선하기 위해 지난 몇 달 동안 취한 여러 가지 조치의 연장선 위에 있습니다.

클라우드 시장의 경쟁과 고객의 선택을 가로막는 제한적인 라이선스 관행을 종식하려면 아직도 넘어야 할 산이 많습니다. 많은 클라우드 고객이 기존 제공업체의 라이선스 제한에 대한 우려를 Google Cloud에 직접 표명해 주고 계십니다. Google Cloud는 클라우드 고객을 대변하여 목소리를 내기 위해 앞으로도 변함없는 노력을 기울이겠습니다.

Duet AI로 클라우드 네트워킹 맞춤설정하기

Fri, 26 Jan 2024 01:00:00 +0000

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

클라우드 네트워킹은 급속히 복잡해질 수 있습니다. 클라우드 네트워크를 온프렘 네트워크 구조와 상호연결해야 하고, 이 둘을 정확하게 연결하는 창의적인 방법을 찾아야 하는 경우에 특히 그렇습니다. Duet AI를 사용하면 네트워크 엔지니어가 이런 작업을 처리하는 데 도움이 됩니다. 가상 프라이빗 클라우드(VPC) 및 관련 비공개 연결을 설정하는 데 Duet AI가 어떻게 도움을 줄 수 있는지 살펴보겠습니다.

콘솔 내 도움말

Google의 Cloud Shell을 사용하여 네트워크를 만들어 본 적이 없다면 Duet AI의 통합 채팅 지원을 통해 기본 사항을 안내받고 유용한 명령어를 알아보세요. 기술 작동 방식, 사용 방법, 시작하는 데 필요한 사항에 대해 질문할 수도 있습니다. 또한 시작하기 위한 명령어 및 구현에 관한 조언도 얻을 수 있습니다.

예를 들어 다음과 같이 질문할 수 있습니다.

Google Cloud에서 첫 번째 VPC 네트워크를 만들려면 gcloud를 어떻게 사용해야 하나요? (How can I use gcloud to create my first VPC network in Google Cloud?)

Duet AI는 아래와 비슷하게 답변합니다.

후속 쿼리 또는 프롬프트를 사용하여 대화를 이어갈 수도 있습니다. Duet AI는 Google Cloud 아키텍처, 문서, 권장사항을 전문적으로 학습했으므로 VPC, DNS, IP 주소 공간 등에 대해 알아보고자 할 때 도움을 줄 수 있는 유용한 도구입니다.

작업 속도 향상하기

서브넷, 마스킹, IP 공간, v4와 v6의 차이가 혼동될 때가 종종 있습니다. 이때 언제나 도움을 받을 수 있는 전문가를 옆에 두면 참조 자료를 찾기 위해 작업을 멈출 필요 없이 빠르게 작업을 완수할 수 있습니다.

Duet AI를 직접 사용해 보고 어떤 도움을 받을 수 있을지 자세히 알아보세요. 또 Duet AI를 사용해 작업을 더 빠르게 완수하는 방법에 관한 더 많은 팁을 확인하여 핵심 목표에 쏟을 시간을 확보해 보세요.