GCP VPC란 무엇인가: Subnet, Firewall Rule, Route 개념 정리

GCP VPC는 Google Cloud 안에서 사용자가 논리적으로 격리된 네트워크를 정의하는 서비스입니다. AWS VPC, Azure VNet과 달리 VPC 자체가 글로벌 리소스이고 Subnet이 리전 단위라는 점이 가장 큰 차이입니다.

핵심 요약

• GCP VPC는 프로젝트 안에서 정의하는 가상 네트워크이며, 특정 리전에 묶이지 않는 글로벌 리소스입니다.
• Subnet은 리전(region) 단위 리소스입니다. 하나의 VPC가 여러 리전의 Subnet을 동시에 포함합니다.
• Firewall Rule은 VM 인스턴스 단위로 적용되는 stateful 방화벽이며, VPC 전체에 정의됩니다.
• Route는 트래픽의 다음 홉(next hop)을 결정하며, 시스템 생성 라우트와 사용자 정의 라우트로 나뉩니다.
• 실무에서는 Custom mode VPC로 Subnet을 직접 설계하고, Firewall Rule을 태그/서비스 계정 기반으로 관리하는 것이 기본입니다.

1. 왜 VPC가 필요한가

GCP에서 Compute Engine VM, GKE, Cloud SQL 같은 리소스를 만들면, 이 리소스들은 어떤 네트워크 안에 존재해야 합니다.

VPC가 없다면 모든 리소스가 같은 네트워크에 섞이게 됩니다. 이 경우 다음 문제가 생깁니다.

• 서로 다른 서비스 간 네트워크 격리가 어렵습니다.
• 외부에 노출되면 안 되는 리소스를 보호하기 어렵습니다.
• 온프레미스나 다른 클라우드와 연결할 때 IP 대역 충돌이 발생할 수 있습니다.

VPC는 사용자가 직접 네트워크 경계를 정의하고, 리소스 간 통신 규칙을 설계할 수 있게 해줍니다. AWS, Azure를 써본 엔지니어라면 개념 자체는 익숙하지만, GCP는 구조가 다르므로 차이를 먼저 이해하는 것이 중요합니다.

2. VPC란 무엇인가

GCP VPC(Virtual Private Cloud)는 프로젝트 안에서 정의하는 논리적으로 격리된 가상 네트워크입니다.

핵심 특성:

특성	설명
범위	글로벌 리소스. 특정 리전에 종속되지 않습니다
Subnet	리전 단위. 하나의 VPC가 여러 리전의 Subnet을 가집니다
격리	다른 VPC와 기본적으로 통신이 차단됩니다
제어	Subnet, Firewall Rule, Route 등으로 트래픽을 제어합니다
소속	VPC는 프로젝트(Project)에 속합니다

GCP에서 가장 먼저 이해해야 할 점은 VPC는 글로벌이고 Subnet은 리전 단위라는 것입니다. 서울(asia-northeast3)과 도쿄(asia-northeast1)에 있는 VM이 같은 VPC에 속한다면, 별도 Peering 없이 내부 IP로 통신할 수 있습니다. AWS에서 리전 간 통신에 VPC Peering이나 Transit Gateway가 필요한 것과 대비됩니다.

AWS VPC / Azure VNet과의 주요 차이점

세 클라우드를 비교하면 차이가 명확해집니다.

기준	AWS VPC	Azure VNet	GCP VPC
VPC 범위	리전 단위	리전 단위	글로벌
Subnet 범위	AZ(가용 영역) 단위	리전 전체	리전 단위
리전 간 통신	VPC Peering / Transit Gateway 필요	VNet Peering 필요	같은 VPC면 내부 IP로 직접 통신
방화벽	Security Group + NACL	NSG	Firewall Rule (VM 단위)
방화벽 적용 기준	인스턴스 / Subnet	Subnet / NIC	네트워크 태그 / 서비스 계정
기본 아웃바운드 인터넷	IGW + Route 필요	기본 제공(폐지 예정)	외부 IP 또는 Cloud NAT 필요

Tip
GCP VPC가 글로벌이라는 점은 멀티 리전 아키텍처에서 큰 장점입니다. 다만 "글로벌 VPC = 보안 경계가 넓다"는 의미이기도 하므로, Firewall Rule과 Subnet 설계로 트래픽을 명확히 분리하는 것이 중요합니다.

3. 핵심 구성 요소

VPC를 구성하는 핵심 요소는 다음과 같습니다.

구성 요소	역할
Subnet	리전 단위로 IP 대역을 정의하는 네트워크 구획
Firewall Rule	VM 인스턴스로의 인바운드/아웃바운드 트래픽을 제어하는 stateful 방화벽
Route	트래픽의 다음 홉을 결정하는 라우팅 규칙
Cloud Router	BGP 기반 동적 라우팅을 처리하는 관리형 라우터
Cloud NAT	외부 IP 없는 VM의 아웃바운드 인터넷 접근 경로
VPC Peering	서로 다른 VPC를 내부 IP로 연결

이 글에서는 Subnet, Firewall Rule, Route를 중심으로 설명합니다. Cloud NAT와 Peering은 관련 맥락에서만 다루고, 자세한 내용은 별도 글에서 정리합니다.

4. Subnet

gcp-vpc-structure

4.1 Subnet이란

Subnet은 VPC 안에서 리전 단위로 정의하는 IP 주소 범위입니다. AWS는 Subnet이 AZ 단위지만, GCP Subnet은 리전 전체에 걸쳐 있습니다. 하나의 Subnet이 그 리전의 여러 영역(zone)에 있는 VM에 IP를 할당합니다.

예를 들어 하나의 VPC 안에서:

Subnet	리전	Primary CIDR	용도
subnet-seoul	asia-northeast3	10.10.0.0/20	서울 리전 웹/앱 VM
subnet-tokyo	asia-northeast1	10.20.0.0/20	도쿄 리전 워크로드
subnet-us	us-central1	10.30.0.0/20	미국 리전 분석 워크로드

같은 VPC에 속하므로 위 세 리전의 VM은 별도 Peering 없이 내부 IP로 통신할 수 있습니다.

4.2 Auto mode VPC와 Custom mode VPC

GCP VPC를 만들 때 두 가지 모드를 선택합니다.

구분	Auto mode	Custom mode
Subnet 생성	모든 리전에 자동 생성	사용자가 직접 생성
IP 대역	10.128.0.0/9 내에서 자동 할당	사용자가 직접 지정
신규 리전	리전 추가 시 Subnet 자동 추가	자동 추가되지 않음
적합한 환경	학습, 테스트, 빠른 시작	운영 환경, IP 대역 통제 필요

새 프로젝트의 default 네트워크는 Auto mode VPC입니다. 다만 운영 환경에서는 IP 대역을 직접 통제할 수 있는 Custom mode를 권장합니다. Auto mode는 모든 리전에 10.128.0.0/9 대역의 Subnet을 자동 생성하므로, 온프레미스나 다른 VPC와 IP 대역이 충돌할 가능성이 있습니다.

# Custom mode VPC 생성
gcloud compute networks create my-vpc \
  --subnet-mode=custom

# Subnet 생성 (리전 지정)
gcloud compute networks subnets create subnet-seoul \
  --network=my-vpc \
  --region=asia-northeast3 \
  --range=10.10.0.0/20

주의
Auto mode에서 Custom mode로 전환은 가능하지만, 반대(Custom → Auto)는 불가능합니다. 운영용 VPC는 처음부터 Custom mode로 생성하는 것이 안전합니다.

4.3 Subnet의 예약 IP

GCP는 각 Subnet의 Primary IPv4 범위에서 IP 4개를 예약합니다.

예약 IP	용도
첫 번째 주소	네트워크 주소
두 번째 주소	기본 게이트웨이
마지막에서 두 번째	향후 사용을 위한 예약
마지막 주소	브로드캐스트 주소

따라서 /24 Subnet이면 256개 중 4개를 제외한 252개를 VM에 할당할 수 있습니다.

4.4 Subnet 설계 시 고려사항

• Subnet은 생성 후 Primary 범위를 확장할 수 있지만 축소(un-expand)는 불가능합니다. 처음부터 여유 있게 잡되 충돌 없는 대역을 선택합니다.
• GKE를 사용한다면 Pod와 Service용 Secondary IP 범위(alias IP)를 별도로 계획해야 합니다.
• 온프레미스나 다른 클라우드와 연결할 경우 IP 대역 충돌을 피해야 합니다.
• VPC가 글로벌이므로, 리전별 Subnet 대역을 체계적으로 분리하면 운영과 감사가 쉬워집니다.

5. Firewall Rule

5.1 Firewall Rule이란

GCP Firewall Rule은 VM 인스턴스로 들어오고 나가는 트래픽을 제어하는 방화벽입니다. VPC 네트워크 수준에서 정의하지만, 실제 적용과 평가는 VM 인스턴스 단위로 이뤄집니다. 모든 VPC 네트워크는 분산 방화벽으로 동작합니다.

AWS는 Security Group(인스턴스)과 NACL(Subnet)이 분리되어 있고, Azure는 NSG가 Subnet/NIC에 붙습니다. GCP는 Firewall Rule이 네트워크 태그나 서비스 계정을 기준으로 VM에 적용된다는 점이 다릅니다.

gcp-vpc-firewall

5.2 Firewall Rule의 구성 요소

요소	설명
Direction	Ingress(인바운드) 또는 Egress(아웃바운드)
Action	allow 또는 deny
Priority	0~65535. 낮을수록 먼저 평가 (기본값 1000)
Target	적용 대상. 네트워크 태그, 서비스 계정, 또는 전체
Source / Destination	IP 범위, 태그, 서비스 계정
Protocol / Port	tcp, udp, icmp 등과 포트

GCP Firewall Rule은 stateful입니다. 인바운드를 허용하면 그에 대한 응답(return traffic)은 별도 규칙 없이 자동으로 허용됩니다.

5.3 암시적 규칙(Implied Rules)

모든 VPC에는 두 개의 암시적 규칙이 있습니다. 우선순위가 가장 낮으며(65535), 삭제할 수 없습니다.

규칙	Direction	Action	설명
Implied allow egress	Egress	allow	모든 아웃바운드 트래픽 허용
Implied deny ingress	Ingress	deny	모든 인바운드 트래픽 차단

즉 GCP VPC는 기본적으로 아웃바운드는 모두 허용, 인바운드는 모두 차단입니다. 따라서 외부에서 VM에 접근하려면 명시적인 ingress allow 규칙을 추가해야 합니다.

Security Note
암시적 allow egress 규칙은 모든 아웃바운드를 허용합니다. 데이터 유출(exfiltration) 위험을 줄이려면, 더 높은 우선순위(낮은 숫자)로 egress deny 규칙을 추가하고 필요한 목적지만 명시적으로 허용하는 방식을 검토할 수 있습니다.

5.4 태그 / 서비스 계정 기반 제어

GCP Firewall Rule의 강점은 IP가 아니라 네트워크 태그나 서비스 계정을 기준으로 적용 대상을 지정할 수 있다는 점입니다.

# web 태그가 붙은 VM에 HTTPS(443) 인바운드 허용
gcloud compute firewall-rules create allow-https \
  --network=my-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web

이렇게 하면 IP 대신 역할(role) 기반으로 방화벽을 관리할 수 있습니다. 예를 들어 web 태그가 붙은 VM에는 443만 열고, db 태그가 붙은 VM에는 app 서비스 계정에서 오는 트래픽만 허용하는 식으로 설계할 수 있습니다.

주의
source-ranges를 0.0.0.0/0으로 열면 인터넷 전체에 노출됩니다. 관리 포트(SSH 22, RDP 3389)는 0.0.0.0/0으로 열지 말고, IAP(Identity-Aware Proxy) 또는 특정 IP 대역으로 제한하는 것이 안전합니다.

6. Route

6.1 Route란

Route는 VM에서 나가는 트래픽이 어디로 가야 하는지(next hop)를 결정하는 규칙입니다. GCP의 Route는 크게 세 종류로 나뉩니다.

종류	생성 방식	설명
System-generated route	자동	Subnet 대역에 대한 내부 라우트, 기본 인터넷 라우트
Static route	사용자 정의	특정 목적지를 지정한 next hop으로 라우팅
Dynamic route	Cloud Router(BGP)	VPN/Interconnect로 연결된 온프레미스 경로를 자동 학습

6.2 시스템 생성 라우트

VPC를 만들면 GCP가 자동으로 두 종류의 라우트를 생성합니다.

라우트	Destination	Next hop	설명
Subnet route	각 Subnet의 CIDR	VPC 내부	VPC 내 통신 (삭제 불가)
Default route	0.0.0.0/0	기본 인터넷 게이트웨이	외부로 나가는 기본 경로

여기서 주의할 점이 있습니다. default route(0.0.0.0/0)가 있다고 해서 모든 VM이 인터넷에 나갈 수 있는 것은 아닙니다. VM이 외부로 트래픽을 보내려면 다음 중 하나가 필요합니다.

• VM에 외부 IP(External IP)가 있거나
• Subnet에 Cloud NAT가 구성되어 있어야 합니다.

즉 라우트는 "경로"만 정의하고, 실제 인터넷 통신 가능 여부는 외부 IP 또는 Cloud NAT 유무로 결정됩니다.

6.3 Static Route와 Cloud NAT

외부 IP 없이 아웃바운드 인터넷 접근이 필요한 경우(예: 패키지 업데이트, 외부 API 호출), Cloud NAT를 사용합니다. Cloud NAT는 Cloud Router와 함께 동작하는 리전 단위 서비스입니다.

# Cloud Router 생성 (Cloud NAT의 전제)
gcloud compute routers create my-router \
  --network=my-vpc \
  --region=asia-northeast3

# Cloud NAT 구성
gcloud compute routers nats create my-nat \
  --router=my-router \
  --region=asia-northeast3 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips

Static route는 모든 트래픽을 방화벽 역할을 하는 NVA(Network Virtual Appliance)로 보내거나, 특정 대역을 VPN 터널로 보내는 등의 상황에서 사용합니다.

Tip
Cloud Router 자체는 무료입니다. 비용은 Cloud NAT(게이트웨이 시간당 요금 + 처리 데이터 GiB당 요금)와 외부 IP에서 발생합니다. 아웃바운드만 필요하다면 외부 IP를 모든 VM에 붙이는 대신 Cloud NAT 하나로 묶는 편이 보안과 비용 모두에서 유리한 경우가 많습니다.

7. 전체 구조 예시

일반적인 3-Tier 아키텍처에서 GCP VPC 구조는 다음과 같습니다. VPC가 글로벌이므로 단일 리전 안에서 Subnet을 용도별로 나눕니다.

gcp-vpc-traffic-flow

 

VPC (글로벌, Custom mode)
├── subnet-web   (asia-northeast3, 10.10.0.0/20)  - 태그: web
│   └── 웹/프론트엔드 VM (외부 IP 또는 LB 뒤)
├── subnet-app   (asia-northeast3, 10.10.16.0/20) - 태그: app
│   ├── 애플리케이션 VM (외부 IP 없음)
│   └── Cloud NAT (아웃바운드)
├── subnet-db    (asia-northeast3, 10.10.32.0/20) - 태그: db
│   └── Cloud SQL (Private IP)
└── Firewall Rules
    ├── allow-https : 0.0.0.0/0 → tcp:443 → target: web
    ├── allow-app   : tag:web   → tcp:8080 → target: app
    └── allow-db    : tag:app   → tcp:5432 → target: db

트래픽 흐름:

1. 사용자 → External Load Balancer → 웹 VM (subnet-web, 443만 허용)
2. 웹 VM → 앱 VM (subnet-app, web 태그 소스만 8080 허용)
3. 앱 VM → Cloud SQL (subnet-db, app 태그 소스만 5432 허용)
4. 앱 VM → 외부 API: Cloud NAT를 통해 아웃바운드 (외부 IP 없이)

8. 실무 사용 사례

사례 1: 스타트업 웹 서비스 (단일 VPC, 단일 리전)

팀원 5명의 스타트업에서 웹 서비스를 운영한다고 가정합니다.

• subnet-web: 외부 노출이 필요한 프론트엔드 VM 또는 Load Balancer 백엔드
• subnet-app: 애플리케이션 VM, 외부 IP 없이 Cloud NAT로 아웃바운드만 허용
• subnet-db: Cloud SQL을 Private IP로 연결

이 구조를 선택한 이유: - Firewall Rule을 태그 기반(web/app/db)으로 설계하면 IP를 일일이 관리하지 않아도 역할별 접근을 제어할 수 있습니다. - 앱/DB 계층에 외부 IP를 부여하지 않고 Cloud NAT로 묶으면 외부 인바운드 노출을 줄이면서 비용도 절감됩니다. - 관리 접근(SSH)은 IAP를 통해 처리하면 22번 포트를 인터넷에 열지 않아도 됩니다.

사례 2: 멀티 리전 글로벌 서비스

VPC가 글로벌이라는 특성을 활용하는 대표 사례입니다.

• subnet-seoul / subnet-tokyo / subnet-us: 각 리전에 Subnet을 두고 같은 VPC에 소속
• 리전 간 VM 통신은 별도 Peering 없이 내부 IP로 처리
• Global External Load Balancer로 단일 Anycast IP에서 가장 가까운 리전으로 트래픽 분산

이 구조는 멀티 리전 가용성을 우선하는 환경에 적합합니다. 다만 글로벌 VPC는 보안 경계가 넓으므로, 리전 간 통신도 Firewall Rule로 필요한 것만 허용해야 합니다.

사례 3: 하이브리드 연결

• Cloud VPN 또는 Cloud Interconnect로 온프레미스 연결
• Cloud Router의 BGP 동적 라우팅으로 온프레미스 경로를 자동 학습
• 온프레미스와 IP 대역이 겹치지 않도록 Custom mode VPC로 대역 통제

9. 보안 고려사항

Security Note
GCP VPC 설계 시 보안은 네트워크 계층에서 시작됩니다. 아래 원칙을 기본으로 적용하는 것이 좋습니다.

• 외부 IP 최소화: 외부 인바운드가 필요 없는 VM에는 외부 IP를 부여하지 않고, 아웃바운드는 Cloud NAT로 처리합니다.
• 태그/서비스 계정 기반 방화벽: IP가 아닌 역할 기반으로 Firewall Rule을 설계해 lateral movement를 제한합니다.
• 관리 포트 보호: SSH(22), RDP(3389)는 0.0.0.0/0으로 열지 말고 IAP 또는 제한된 IP만 허용합니다.
• Egress 통제: 데이터 유출 방지를 위해 필요한 목적지만 허용하는 egress deny 규칙을 검토합니다.
• VPC Flow Logs: Subnet 단위로 활성화해 트래픽을 기록하고 이상 패턴을 탐지합니다.
• Private Google Access: 외부 IP 없이 Google API(Cloud Storage 등)에 접근할 수 있게 해 인터넷 경유를 줄입니다.

10. 비용/운영 고려사항

주의
VPC, Subnet, Firewall Rule, Route 자체는 무료이지만, 외부 연결과 관련된 일부 리소스는 비용이 발생합니다.

리소스	비용 발생 여부
VPC 네트워크	무료
Subnet	무료
Firewall Rule	무료
Route	무료
Cloud Router	무료
Cloud NAT	게이트웨이 시간당 요금 + 처리 데이터 GiB당 요금 + 외부 IP 요금
외부 IP (External IP)	사용/미사용 외부 IP에 시간당 요금
VPC Peering	같은 리전 무료, 리전 간/외부로 나가는 트래픽은 데이터 전송 요금
Cloud VPN / Interconnect	게이트웨이/연결 시간당 요금 + 트래픽 요금

정확한 단가는 리전과 시점에 따라 다르므로 Google Cloud 공식 Pricing 페이지에서 확인하는 것이 좋습니다.

운영 관점:

• Subnet은 Primary 범위 확장은 가능하지만 축소는 불가능하므로 초기 설계가 중요합니다.
• Cloud NAT 요금은 게이트웨이를 사용하는 VM 인스턴스 수와 처리 데이터량에 따라 증가합니다. (인스턴스당 시간당 요금은 게이트웨이당 32개까지만 과금)
• 글로벌 VPC는 리전 간 통신이 편리하지만, 데이터 전송 비용과 보안 경계를 함께 고려해야 합니다.
• 외부 IP는 미사용 상태로 예약만 해두어도 요금이 발생할 수 있으므로 정리합니다.

11. 자주 하는 실수

1. VPC를 리전 단위로 생각하는 것: GCP VPC는 글로벌입니다. AWS 감각으로 리전마다 VPC를 만들면 불필요하게 복잡해집니다. 대부분 하나의 VPC에 리전별 Subnet을 두는 것으로 충분합니다.
2. 운영 환경에 Auto mode VPC를 쓰는 것: Auto mode는 10.128.0.0/9 대역을 모든 리전에 자동 할당하므로, 온프레미스나 다른 VPC와 충돌하기 쉽습니다. 운영은 Custom mode를 권장합니다.
3. default route만 있으면 인터넷이 된다고 오해하는 것: 외부 IP 또는 Cloud NAT가 없으면 default route가 있어도 VM은 인터넷에 나가지 못합니다.
4. 관리 포트를 0.0.0.0/0으로 여는 것: SSH/RDP를 전체 인터넷에 열면 공격 표면이 커집니다. IAP나 제한된 IP를 사용합니다.
5. 모든 VM에 외부 IP를 붙이는 것: 외부 IP는 비용이 발생하고 노출 위험도 커집니다. 아웃바운드만 필요하면 Cloud NAT로 묶습니다.
6. Firewall Rule의 priority를 고려하지 않는 것: 숫자가 낮을수록 먼저 평가됩니다. allow와 deny 규칙이 겹칠 때 우선순위를 잘못 설정하면 의도와 다르게 동작합니다.

12. 정리

• GCP VPC는 글로벌 리소스이고 Subnet은 리전 단위라는 점이 AWS/Azure와의 핵심 차이입니다.
• 같은 VPC에 속한 리전 간 VM은 별도 Peering 없이 내부 IP로 통신할 수 있습니다.
• Firewall Rule은 VM 단위 stateful 방화벽이며, 태그나 서비스 계정 기반으로 설계하는 것이 강점입니다.
• 기본 동작은 아웃바운드 허용, 인바운드 차단(암시적 규칙)입니다.
• Route는 경로만 정의하며, 실제 인터넷 통신은 외부 IP 또는 Cloud NAT가 결정합니다.
• 운영 환경에서는 Custom mode VPC + 태그 기반 Firewall Rule + Cloud NAT + 외부 IP 최소화가 기본 설계입니다.

참고 문서

• Google Cloud 공식 문서: VPC 네트워크 개요
• Google Cloud 공식 문서: Subnet
• Google Cloud 공식 문서: VPC firewall rules
• Google Cloud 공식 문서: Routes
• Google Cloud 공식 문서: Cloud NAT