Google PCNE: VPC 아키텍처, 서브넷 및 주소 계획 — 학습 가이드

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Cloud Network Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Virtual Private Cloud(VPC)는 모든 Google Cloud 리전을 포괄하는 전역적이고 논리적으로 격리된 네트워크입니다. 서브넷은 VPC 내의 리전별 구성 요소이며 Compute Engine, GKE 및 기타 리소스를 지원하는 IP 범위를 호스팅합니다. 견고한 VPC 아키텍처는 주소 효율성, 확장성, 운영 제어 간의 균형을 맞추면서 프로젝트 내부 및 프로젝트 간 워크로드와 Google API에 대한 저지연의 비용 효율적인 연결을 보장합니다.

VPC 범위, 서브넷 아키텍처 및 모드

전역 VPC, 리전 서브넷
- 단일 VPC는 모든 리전에 걸쳐 있습니다. 서브넷은 리전별로 생성되며 기본 IPv4 CIDR과 선택적 보조 범위를 정의합니다. 인스턴스는 리전 서브넷에서 IP를 할당받지만, 기본적으로 동일한 VPC 내에서는 리전 간에 비공개로 통신할 수 있습니다.
- 동적 라우팅 모드
  - 리전(Regional): Cloud Router는 해당 리전의 서브넷과만 경로를 교환합니다.
  - 전역(Global): 한 리전의 Cloud Router는 학습된 경로를 모든 리전에 공지합니다. 다중 리전 워크로드 또는 HA 이그레스(egress)가 필요한 경우 전역 모드를 선호합니다.
자동 모드 vs 사용자 정의 모드
- 자동 모드는 사전 할당된 CIDR을 사용하여 리전당 하나의 서브넷을 생성합니다. 빠른 시작에는 편리하지만 대규모 환경에서는 유연성이 떨어집니다. 사용자 정의 모드로 변환할 수 있으며, 이 변환은 단방향입니다.
- 사용자 정의 모드는 서브넷 생성 및 CIDR 선택에 대한 완전한 제어권을 제공합니다. 이는 프로덕션 환경의 주소 계획, Shared VPC, 피어링 및 확장을 위해 권장되는 패턴입니다.
- 마이그레이션 참고: 자동 모드를 사용자 정의 모드로 변환한 후, 자동 서브넷을 가정했던 아티팩트나 템플릿은 사용자 정의 서브넷을 참조하도록 명시적으로 업데이트될 때까지 실패하는 경우가 많습니다.
서브넷 불변성 및 확장
- 서브넷 리전은 변경할 수 없습니다. 즉, 서브넷을 리전 간에 이동할 수 없습니다.
- 기본 IPv4 범위는 현재 위치에서 확장(프리픽스 확장)할 수 있지만 축소할 수는 없으며, VPC 및 연결된 모든 네트워크에서 겹치지 않아야 합니다.
- 보조 범위는 추가하거나 제거할 수 있지만(사용 여부에 따라 다름), 이 역시 겹치지 않아야 합니다.

주소 계획: 기본/보조 범위, 별칭 IP, IPv6 및 비공개 공간

기본 및 보조 IPv4 범위
- 기본 범위: VM 인터페이스 주소(기본값 nic0)를 할당합니다. 시스템에서 생성된 서브넷 경로를 만들고 대부분의 내부 통신에 사용됩니다.
- 보조 범위: 서브넷에 추가 CIDR을 연결하며 VPC 네이티브 GKE 클러스터에 필요합니다. 보조 범위에 대해 시스템에서 생성된 경로는 Pod와 Service 간의 이스트-웨스트(east-west) 연결을 허용합니다.
별칭 IP
- 별칭 IP를 사용하면 VM NIC가 서브넷의 기본 또는 보조 범위에서 여러 IP를 소유할 수 있으므로, 엄격한 IP 기반 정책, VPC 네이티브 GKE를 위한 Pod IP, 효율적인 IP 활용이 가능해집니다.
- GKE의 경우, 단편화를 최소화하고 향후 크기 조정을 용이하게 하려면 크고 연속적인 보조 CIDR을 계획하십시오. 예: 200개의 Pod/노드를 갖춘 100개의 노드와 1500개의 Service가 있는 경우, Pod 보조 범위에 최소 /17, Service 범위에 /21을 할당하여 여유 공간을 확보합니다.
비공개 RFC 1918 설계 및 IP 관리
- 현재 및 계획된 모든 VPC, 온프레미스, 파트너 네트워크에서 겹치지 않는 블록을 선택하십시오. 각 환경에 대해 큰 상위 블록을 예약한 다음, 리전별 및 기능별로 예측 가능한 하위 블록을 분할하여 사용합니다.
- 확장, 보조 범위, 마이그레이션 버퍼(임시 듀얼 스택/이중 NAT), 인프라 엔드포인트(ILB VIP, PSC 엔드포인트)를 위한 용량을 예약하십시오.
- 파트너 연결 가능성이 있는 경우 가장 일반적인 엔터프라이즈 블록 사용을 피하거나, NAT로 세분화하여 충돌을 방지하십시오.
IPv6 계획
- 외부 IPv6: 클라이언트 액세스 및 애니캐스트(anycast) 연결을 위해 전역 부하 분산기에서 전역 외부 IPv6 주소를 사용합니다.
- 내부 IPv6: 사용 가능한 경우, 듀얼 스택 서브넷을 활성화하여 VM에 내부 IPv6를 할당하고 그에 따라 방화벽 규칙을 조정합니다. DNS AAAA 레코드를 계획하고 IPv4 정책과의 동등성을 보장합니다.
- 클라우드 내부 제어 및 서드파티 통합을 위해 IPv4를 유지하고, 부하 분산기와 듀얼 스택 서브넷을 통해 점진적으로 IPv6를 도입합니다.

운영: 확장, HA, 비공개 액세스, 검증 및 문제 해결

서브넷 확장 및 마이그레이션 제약 조건
- 서브넷 용량이 거의 다 차면 현재 위치에서 확장하고, 연결된 모든 네트워크가 겹치지 않는지 확인하며, 종속된 GKE 보조 범위가 계속 적절한지 확인합니다.
- 조직이나 파트너 간에 범위가 겹치는 경우 NAT 또는 단계적 IP 재할당을 사용합니다. 겹치는 VPC를 피어링하거나 겹치는 동적 경로를 설치할 수 없습니다.
리전 배치 및 고가용성
- 사용자 및 데이터와 가장 가까운 리전에 서브넷을 배치합니다. 미주와 유럽에 걸친 사용자 기반의 경우, us-east1 및 europe-west1에 리전 서브넷이 있는 단일 VPC는 VPC 내에서 최적의 지연 시간과 이그레스 비용 없이 직접적인 비공개 연결을 제공합니다.
- 여러 영역에 워크로드를 분산하고, 리전 관리형 인스턴스 그룹과 리전 내부/외부 부하 분산기를 사용하여 영역 장애에 대한 내결함성을 확보합니다.
- 하이브리드 환경의 경우, 리전 또는 엣지 로케이션별로 이중 Cloud Router와 연결(attachment)을 배포하고, 지원되는 경우 BFD를 활성화하며, 장애 조치를 위해 전역 동적 라우팅을 사용합니다.
비공개 Google 액세스 및 제한된 엔드포인트
- 외부 IP가 없는 인스턴스를 호스팅하는 서브넷에서 PGA를 활성화합니다.
- 일반적인 인터넷 이그레스를 방지하면서 Google API를 허용하려면:
  - 기본 트래픽을 NGFW로 라우팅합니다.
  - Google API VIP에 대한 더 구체적인 정적 경로를 기본 인터넷 게이트웨이로 추가하거나, Google API에 대한 PSC 엔드포인트를 배포합니다.
- 예시:

undefined

토폴로지 검증 및 문제 해결
- Network Intelligence Center 사용:
  - Connectivity Tests를 사용하여 연결 가능성을 검증하고 라우팅, 방화벽, 게이트웨이 결정을 시뮬레이션합니다.
  - Performance Dashboard 및 Topology를 사용하여 경로와 상태를 시각화합니다.
- 로그 및 원격 측정:
  - VPC Flow Logs를 사용하여 인터페이스별 허용/거부 및 지연 시간을 관찰합니다.
  - Firewall Rules Logging을 사용하여 규칙 일치를 확인합니다.
  - 외부 IP 없는 이그레스 문제에 대해 Cloud NAT 로그 및 상태를 확인합니다.
  - 백엔드 준비 상태에 대해 부하 분산기 및 상태 확인 로그를 확인합니다.
- CLI 확인:

undefined

및

undefined

를 사용하여 유효 정책을 확인합니다. - 테스트 VM에서 traceroute 및 curl을 사용하고, 필요 시 심층 분석을 위해 패킷 미러링을 사용합니다.

실제 문제 시나리오

Acme Retail Group은 중앙 집중식 제어가 가능하고, 비공개 인스턴스에서 인터넷 없이 Google API에 액세스할 수 있으며, 통신할 필요가 없는 부서 간에 엄격한 격리가 적용되는 다중 리전, 저지연 Google Cloud 네트워크가 필요합니다. 일부 팀은 Pod 밀도가 높은 GKE를 실행합니다. 또한 Acme는 일반적인 이그레스를 서드파티 방화벽을 통해 보내지만, Google API 트래픽은 이 방화벽을 우회하기를 원합니다.

호스트 프로젝트에 전역 동적 라우팅을 사용하는 맞춤형 모드로 단일 Shared VPC를 구축하고, us-east1 및 europe-west1에 GKE용으로 예약된 보조 범위를 갖는 리전 서브넷을 생성합니다.

근거: 하나의 VPC는 RFC1918 주소를 통해 비공개, 비용 없는 리전 간 연결을 제공하여 최적의 효율성을 보장합니다. 맞춤형 모드와 전역 동적 라우팅은 정밀한 IP 계획과 다중 리전 경로 전파를 지원합니다.

각 부서의 서비스 프로젝트와 필요한 특정 서브넷만 공유합니다. 세 개의 서비스 프로젝트(Sales, Finance, Marketing)를 만들고 각각에 필요한 서브넷만 노출합니다.

근거: 서브넷별 공유는 영향 반경과 경로 노출을 제한하여 격리를 강제하는 동시에 중앙 운영을 가능하게 합니다. 위임된 IAM을 통해 중앙 네트워크 관리자는 방화벽과 경로를 관리하고, 앱 팀은 독립적으로 워크로드를 배포할 수 있습니다.

통신해야 하는 부서의 경우, 전용 VPC를 피어링하거나 동일한 Shared VPC 서브넷에 배치합니다. 격리된 부서의 경우, 피어링을 삼가고 겹치는 서브넷을 공유하지 않습니다.

근거: 피어링은 최소한의 운영 오버헤드로 저지연 비공개 연결을 제공합니다. 비전이성(Non-transitivity)으로 인해 필요한 곳에만 명시적인 메시 연결이 필요하며, 이는 기본적으로 격리를 유지합니다.

모든 공유 서브넷에서 Private Google Access를 활성화하고 Google API에 대한 Private Service Connect 엔드포인트를 배포합니다. 서드파티 방화벽으로 가는 기본 경로는 유지하고, Google API VIP에 대한 더 구체적인 정적 경로를 기본 인터넷 게이트웨이로 추가합니다.

근거: PGA와 PSC는 비공개 VM에서 인터넷 없이 API를 사용할 수 있게 합니다. 더 구체적인 경로는 API 트래픽이 NGFW를 우회하도록 보장하는 동시에, Google이 아닌 인터넷 이그레스는 검사 경로를 계속 통과하도록 합니다.

성장 여유 공간을 두고 기본 및 보조 CIDR을 할당합니다. GKE의 경우, 사용량이 많은 리전별로 Pod 보조 범위(예: /17)와 Services 보조 범위(/21)의 크기를 정합니다. Pod와 Service에 별칭 IP를 사용하고 해당 범위에 바인딩된 VPC 네이티브 클러스터를 생성합니다.

근거: 보조 범위와 별칭 IP는 노드 IP 고갈을 방지하고 고밀도 스케줄링을 가능하게 합니다. 미래 수요에 맞춰 크기를 조정하면 장애를 유발할 수 있는 크기 조정 및 보조 범위 IP 재할당을 피할 수 있습니다.

하이브리드 및 어플라이언스 트래픽에 대한 HA를 구현합니다. 필요에 따라 이중 Cloud Routers와 HA VPN 또는 Interconnect를 배포합니다. 가상 어플라이언스를 통해 트래픽을 보내야 하는 경우, 다음 홉을 리전 내부 부하 분산기 또는 IP 전달이 활성화된 인스턴스로 설정하고 태그 범위 적용이 가능한 더 구체적인 커스텀 경로를 사용합니다.

근거: 엣지에서의 HA는 장애 발생 시 연속성을 보장합니다. 태그를 사용한 경로 범위 지정은 의도치 않은 트래픽 헤어피닝을 방지하고 선택된 인스턴스만 어플라이언스 경로를 통과하도록 합니다.

Network Intelligence Center Connectivity Tests, VPC Flow Logs, Firewall Rules Logging으로 검증하고 운영합니다. 서비스 계정을 사용하여 ID 기반 방화벽 정책을 적용하고, 리전 및 기능별로 예약된 버퍼를 포함하여 IPAM 레코드를 유지 관리합니다.