GCP-ACE 시험에서 네트워킹 도메인은 단순 암기를 넘어 설계 판단력을 요구합니다. Shared VPC와 VPC Peering 중 어느 쪽을 써야 하는지, 글로벌 사용자에게 HTTPS를 전달할 때 왜 Network Load Balancer가 오답인지, 비용 추정과 실제 청구를 구분하는 도구가 무엇인지 — 이런 판단 기준이 핵심입니다. GCP 네트워크 차별점부터 로드 밸런서 선택, 보조 서비스, Pricing Calculator, 비용 함정까지 정리합니다.
---
GCP 네트워크는 다른 클라우드와 무엇이 다른가
GCP 네트워크를 처음 접하는 엔지니어가 가장 먼저 놀라는 부분은 VPC가 글로벌 리소스라는 점입니다. AWS나 Azure에서 VPC·VNet은 특정 리전에 귀속됩니다. 서울 VPC와 미국 VPC를 연결하려면 별도의 피어링이나 Transit Gateway가 필요합니다.
GCP는 다릅니다. VPC 자체가 리전 개념이 없는 글로벌 리소스입니다. 하나의 VPC 안에 서울(asia-northeast3), 미국 동부(us-east1), 유럽(europe-west1) 서브넷을 함께 넣을 수 있고, 속한 VM들은 추가 구성 없이 사설 IP로 자유롭게 통신합니다.
GCP 네트워크의 또 다른 강점은 Google의 글로벌 프라이빗 백본입니다. 글로벌 로드 밸런서 트래픽은 사용자와 가장 가까운 Google PoP에서 수신된 후, 공용 인터넷을 거치지 않고 Google 프라이빗 네트워크를 통해 백엔드 리전으로 전달됩니다. 단일 글로벌 IP로 전 세계 저지연을 실현하는 기반입니다.
| 항목 | GCP | AWS | Azure | |------|-----|-----|-------| | VPC 범위 | 글로벌 (리전 무관) | 리전 단위 | 리전 단위 | | 서브넷 범위 | 리전 단위 | 가용 영역 단위 | 리전 단위 | | 글로벌 LB | 단일 Anycast IP | 별도 구성 필요 | 별도 구성 필요 | | 글로벌 백본 | Google 프라이빗 네트워크 | AWS 내부망 | Microsoft 내부망 |
---
VPC와 서브넷: 글로벌 VPC라는 발상
GCP에서 VPC는 리전을 선택하지 않고 만드는 글로벌 네트워크 컨테이너입니다. 서브넷을 만들 때 리전을 지정하며, 해당 리전의 모든 가용 영역에 자동으로 분산됩니다. 서울 서브넷과 미국 서브넷이 같은 VPC 안에 있으면 VM들은 추가 구성 없이 사설 IP로 통신합니다.
GCP 서브넷에는 기본 IP 범위 외에 보조 IP 범위(Secondary IP range)를 추가할 수 있습니다. GKE 파드·서비스 IP를 여기서 할당하며, 기본 VM IP와 충돌 없는 독립 주소 공간을 확보합니다.
방화벽 규칙은 VPC 수준에서 동작하며, 특정 대상에만 적용하려면 네트워크 태그나 서비스 계정을 사용합니다. AWS 보안 그룹과 달리 VPC 전체에 적용된 후 태그로 범위를 좁히는 방식입니다.
| 항목 | 설명 | 주의 사항 | |------|------|----------| | VPC | 글로벌 리소스, 리전 무관 | 프로젝트당 기본 5개 VPC 한도 | | 서브넷 | 리전 단위, 모든 가용 영역 포괄 | CIDR 겹침 불가 | | 보조 IP 범위 | GKE 파드/서비스용 추가 IP 풀 | 서브넷당 최대 30개 | | 방화벽 규칙 | VPC 수준 적용, 태그로 타겟 지정 | 스테이트풀(상태 기반) 처리 |
---
자동 모드 vs 커스텀 모드 VPC, 그리고 IP 계획
VPC 생성 시 자동 모드(Auto mode)와 커스텀 모드(Custom mode) 중 하나를 선택합니다. 자동 → 커스텀 전환은 가능하지만 반대는 불가하므로 처음 선택이 중요합니다.
자동 모드는 각 리전에 /20 서브넷을 자동 생성하며 주소 범위는 10.128.0.0/9 블록에서 할당합니다. 빠른 시작이 필요한 개발·테스트 환경에 적합합니다. 커스텀 모드는 서브넷을 직접 정의합니다. 프로덕션, 기업 IP 체계 연동, 온프레미스 VPN/Interconnect 연결이 예상되는 환경에서는 반드시 커스텀 모드를 사용해야 합니다.
자동 모드가 프로덕션에 부적합한 핵심 이유는 IP 충돌 위험입니다. 10.128.0.0/9 블록은 온프레미스 네트워크에서도 자주 사용됩니다. Cloud Interconnect나 VPN 연결 시 충돌이 발생하면 재설계가 불가피합니다.
| 항목 | 자동 모드 | 커스텀 모드 | |------|----------|------------| | 서브넷 생성 | 자동 (리전별 /20) | 수동 (직접 정의) | | IP 범위 | 10.128.0.0/9 고정 | 사용자 지정 | | 추천 환경 | 개발/테스트, 학습 | 프로덕션, 엔터프라이즈 | | 온프레미스 연동 | IP 충돌 위험 높음 | 충돌 회피 가능 | | 전환 | 자동 → 커스텀 가능 | 커스텀 → 자동 불가 |
!Auto Mode vs Custom Mode VPC
Shared VPC와 VPC Peering: 두 가지 연결 모델
GCP에서 여러 프로젝트 간 네트워크 연결을 구성할 때 두 가지 방식이 있습니다. 시험에서 가장 자주 혼동하는 주제입니다.
Shared VPC는 호스트 프로젝트가 VPC를 소유·관리하고, 여러 서비스 프로젝트가 서브넷을 공유하는 구조입니다. 서비스 프로젝트 VM들은 공유 서브넷에 배포되어 사설 IP로 직접 통신하며, 네트워크 관리자(호스트)와 리소스 관리자(서비스 프로젝트)의 역할이 명확히 분리됩니다.
VPC Peering은 두 VPC를 점대점으로 연결합니다. 각 VPC는 독립적으로 관리되며 피어링을 통해 사설 IP로 통신합니다. 반드시 기억해야 할 특성이 비전이성(Non-transitivity)입니다. A↔B, B↔C 피어링이 있어도 A↔C는 통신 불가합니다. A와 C가 통신하려면 A↔C 피어링을 별도로 설정해야 합니다. Shared VPC에서는 모든 서비스 프로젝트가 동일 VPC를 공유하므로 이 문제가 없습니다.
| 항목 | Shared VPC | VPC Peering | |------|-----------|-------------| | 네트워크 소유 | 호스트 프로젝트 단일 소유 | 각 VPC 독립 소유 | | 관리 방식 | 중앙 집중 (호스트 프로젝트) | 분산 (각 VPC 팀) | | 서비스 프로젝트 수 | 최대 1,000개 | N:N 피어링 필요 | | 비전이성 | 해당 없음 (같은 VPC) | 있음 (A-B-C 불통) | | 조직 간 연결 | 불가 (같은 조직 한정) | 가능 | | 주요 선택 기준 | 중앙 네트워크 거버넌스 | 독립적 네트워크 유지 |
시험 함정: 여러 프로젝트 VM의 사설 IP 통신 + 중앙 관리 → Shared VPC. 두 독립 VPC 연결 → VPC Peering.
---
GCP 로드 밸런서 종류와 결정 기준
GCP-ACE에서 로드 밸런서 선택 문제는 빈출입니다. 범위(글로벌/리전), 방향(외부/내부), 계층(L7 애플리케이션/L4 네트워크) 세 축으로 분류됩니다.
글로벌 외부 Application Load Balancer(구 Global HTTP(S) LB)는 단일 Anycast IP로 전 세계 트래픽을 수신하고, URL 경로·호스트 헤더 기반으로 다른 백엔드로 라우팅하며, Google-managed SSL 인증서로 인증서 관리 부담을 없앱니다. Layer 7에서 동작합니다. /api/orders와 /api/users를 각각 다른 서비스로 보내야 한다면 이 로드 밸런서가 답입니다.
내부 Application Load Balancer는 VPC 내부 HTTP 트래픽을 처리합니다. 마이크로서비스 간 사설 통신, 프라이빗 API 게이트웨이 역할을 하며 공인 IP가 없습니다.
Network Load Balancer는 Layer 4에서 TCP/UDP를 처리합니다. URL 경로 라우팅은 불가하며, 초저지연 게임 서버나 UDP 실시간 통신에 적합합니다.
| 로드 밸런서 종류 | 범위 | 계층 | 주요 기능 | 선택 기준 | |----------------|------|------|----------|----------| | 글로벌 외부 Application LB | 글로벌 | L7 | URL 라우팅, 글로벌 Anycast, SSL 오프로드 | 전 세계 HTTPS, URL 경로 라우팅 | | 리전 외부 Application LB | 리전 | L7 | URL 라우팅, SSL 오프로드 | 단일 리전 HTTPS | | 내부 Application LB | 리전 | L7 | VPC 내부 HTTP 트래픽 분산 | 마이크로서비스 내부 통신 | | 외부 Network LB (패스스루) | 리전 | L4 | TCP/UDP, 초저지연 | 게임, 스트리밍, 레거시 | | 내부 Network LB (패스스루) | 리전 | L4 | VPC 내부 TCP/UDP | 내부 고성능 워크로드 | | 프록시 Network LB | 글로벌/리전 | L4 | TCP 프록시 | TCP + 글로벌 분산 필요 시 |
판단 기준: 글로벌 HTTPS + URL 경로 라우팅 → 글로벌 외부 Application LB. 마이크로서비스 내부 HTTP → 내부 Application LB. UDP + 초저지연 → Network LB. 리전 장애 자동 페일오버 → 글로벌 Application LB.
---
Cloud DNS, Cloud CDN, Cloud NAT의 역할 분담
네트워크 보조 서비스들도 시험에 등장합니다. 역할 경계를 명확히 구분해 두어야 합니다.
Cloud DNS는 Public zone으로 외부 도메인을 관리하거나, Private zone으로 VPC 전용 내부 DNS를 구성합니다. 99.99% SLA를 제공하며 VPC 안 VM들이 내부 서비스명으로 서로를 찾을 때 Private zone을 VPC에 연결합니다. 외부에서는 Private zone을 조회할 수 없습니다.
Cloud CDN은 정적 콘텐츠를 Google 엣지 캐시에 저장해 사용자 근처에서 전달합니다. 글로벌 외부 Application Load Balancer와 함께 동작하며, 캐시 히트 시 백엔드 부하와 이그레스 비용이 감소합니다. 이미지, 동영상, CSS, JS처럼 자주 바뀌지 않는 자산에 효과적입니다.
Cloud NAT는 공인 IP 없는 사설 VM이 인터넷으로 아웃바운드 연결하도록 허용합니다. 패키지 업데이트, 서드파티 API 호출에 활용하며, 인바운드는 차단하므로 보안상 유리합니다.
| 서비스 | 역할 | 주요 사용 사례 | 함께 쓰는 서비스 | |--------|------|--------------|----------------| | Cloud DNS | DNS 레코드 관리 | 도메인 → IP 변환, VPC 내부 DNS | Cloud Load Balancing | | Cloud CDN | 정적 콘텐츠 엣지 캐시 | 이미지, 동영상, 정적 자산 | 글로벌 Application LB | | Cloud NAT | 사설 VM 아웃바운드 인터넷 | 패키지 업데이트, 외부 API 호출 | Cloud Router | | Cloud Armor | DDoS 방어, WAF | 외부 공격 차단, 지역 기반 차단 | 글로벌 Application LB |
시험 함정: Cloud CDN은 정적 자산 전용입니다. 동적 데이터를 전 세계에 빠르게 제공해야 하면 CDN이 아니라 글로벌 로드 밸런서 + 멀티리전 배포가 답입니다.
---
Pricing Calculator로 안전하게 비용 추정하기
Google Cloud Pricing Calculator는 실제 리소스를 배포하지 않고 월간 예상 비용을 시뮬레이션하는 도구입니다. 클라우드 전환 전 경영진 보고, 새 아키텍처 비용 비교에 활용합니다. 계정 없이 무료로 사용할 수 있고 결과를 URL 또는 PDF로 공유할 수 있습니다.
입력 변수: VM 수·머신 타입·리전, Storage 용량·클래스, 네트워크 이그레스(리전별·인터넷 방향), 로드 밸런서 유형·처리량, Cloud NAT 처리량.
사전 예측에는 Pricing Calculator, 사후 실제 청구 분석에는 Cloud Billing입니다.
| 도구 | 역할 | 사용 시점 | 계정 필요 | |------|------|----------|----------| | Pricing Calculator | 사전 비용 시뮬레이션 | 설계 단계, 경영진 보고 | 불필요 | | Cloud Billing | 실사용 청구 내역 분석 | 운영 단계, 청구서 검토 | 필요 | | Cost Table Reports | 프로젝트/서비스별 비용 분석 | 운영 최적화 | 필요 | | Committed Use Discounts | 1~3년 약정 할인 | 예측 가능한 워크로드 | 필요 |
---
정리: 네트워크 비용 함정과 시험 빈출 패턴
GCP 네트워크 청구서에서 가장 자주 놀라는 항목은 이그레스 비용입니다. 인그레스는 무료이지만 이그레스는 방향에 따라 요금이 다릅니다.
| 트래픽 방향 | 비용 | |------------|------| | 인터넷 → GCP (인그레스) | 무료 | | 동일 리전 VM 간 (사설 IP) | 무료 | | GCP 리전 간 | GB당 요금 발생 | | GCP → 인터넷 (이그레스) | 목적지별 단가, 월 1GB 무료 | | 같은 리전 Cloud Storage 접근 | 무료 | | Cloud CDN → 사용자 (캐시 히트) | 백엔드 이그레스보다 저렴 |
비용 절감 팁 세 가지입니다. 첫째, 같은 리전 통신은 사설 IP를 사용합니다. 공인 IP 사용 시 이그레스로 처리되어 요금이 발생합니다. 둘째, 대규모 정적 콘텐츠는 Cloud CDN을 활용합니다. 캐시 히트율이 높을수록 백엔드 이그레스가 줄어듭니다. 셋째, 예측 가능한 워크로드에는 Committed Use Discounts를 검토합니다. 1년 약정 최대 37%, 3년 약정 최대 55% 할인이 적용됩니다.