🌐 GCP VPC 의 기본개념과 베스트 프랙티스

GCP(Goolg Cloud Platform) 에서 VPC는 네트워크의 “뼈대”라서, 한 번 잘 설계해 두면 서비스 운영이 정말 편해집니다.  개념 + 베스트 프랙티스 중심으로 정리해 드릴게요 😊

 

---

1. GCP VPC란 무엇인가?

 

1-1. VPC의 기본 개념

 

VPC(Virtual Private Cloud)는 Google Cloud 안에 만들어 쓰는 논리적인 사설 네트워크입니다. 온프레미스에서 스위치·라우터·방화벽으로 구성하던 네트워크를, GCP에서는 VPC 하나가 대신해 준다고 보면 됩니다. GCP VPC의 핵심 특징은 다음과 같습니다.

• 글로벌 리소스: 하나의 VPC가 여러 리전에 걸쳐 존재할 수 있습니다. (AWS의 리전별 VPC와 개념이 조금 다름)
• Subnet 기반 IP 할당: 각 리전마다 10.0.0.0/24 같은 CIDR로 서브넷을 만들고, VM에 내부 IP를 할당합니다.
• 라우팅(Routes): 서브넷 간 통신, 인터넷/온프레미스와의 통신 경로를 라우트로 제어합니다.
• 방화벽(Firewall Rules): VPC 레벨에서 L3/L4 방화벽 규칙을 정의해서, VM 인스턴스 인·아웃바운드 트래픽을 제어합니다.
• 연결 기능: VPC Peering, Cloud VPN, Cloud Interconnect 등으로 다른 VPC·온프레미스 네트워크와 연결할 수 있습니다.

---

 

2. VPC를 구성하는 주요 요소

 

2-1. VPC Network

 

• VPC Network = 네트워크의 컨테이너
  • 서브넷, 라우트, 방화벽, 피어링 등이 모두 VPC 네트워크 단위로 묶입니다.
  • 하나의 프로젝트 안에 여러 개의 VPC 네트워크를 만들 수도 있습니다.

실무 팁 ✅
초기에는 프로젝트당 1개 VPC로 시작하고, 보안/조직/규모 요구사항이 복잡해지면 VPC를 나누는 방식이 관리에 유리합니다.

 

---

 

2-2. Subnet (서브네트워크)

 

서브넷은 특정 리전에 속하는 IP 대역 조각입니다. 예: 10.10.0.0/24 (서울), 10.10.1.0/24 (도쿄) 같이 리전별로 잘라서 사용하는 구조입니다. 하나의 VPC 안에 여러 서브넷을 만들어서, 프런트엔드, 백엔드, DB 운영(Production), 스테이징(Staging), 개발(Development) 등을 논리적으로 분리할 수 있습니다.

 

---

 

2-3. Routes (라우트)

 

어떤 트래픽을 어디로 보내야 하는지 정의하는 규칙입니다.

• 기본 라우트: 서브넷 간 내부 통신, 인터넷 향 기본 경로 등은 자동으로 생성됩니다.
• 커스텀 라우트: 특정 CIDR은 온프레미스(Cloud VPN/Interconnect)로 보내는 식으로 별도 정의할 수 있습니다.

 

---

 

2-4. Firewall Rules (방화벽 규칙)

 

VPC 수준에서 IP/포트/프로토콜 기반으로 인스턴스 트래픽을 허용/차단합니다.

• 특징:
  • 기본적으로 거부(Deny)가 기본, 필요한 트래픽만 허용하는 것이 권장됩니다.
  • 태그/서비스 계정을 기준으로 방화벽을 걸 수 있어서, 역할 별로 네트워크 접근 제어를 구현할 수 있습니다.

 

---

 

2-5. VPC Peering & Shared VPC

 

• VPC Peering:  서로 다른 프로젝트/조직의 VPC 네트워크를 사설 IP로 연결하는 기능입니다.
• Shared VPC
  • 하나의 “호스트 프로젝트”에 공통 VPC를 만들고, 여러 “서비스 프로젝트”가 이 VPC를 같이 사용하는 구조입니다.
  • 네트워크 팀은 중앙에서 VPC/방화벽을 관리하고, 각 서비스 팀은 자신들의 프로젝트 안에서 VM만 생성/관리하는 패턴입니다.

---

 

3. GCP VPC 설계 시 대표적인 패턴

 

3-1. 단일 프로젝트, 단일 VPC

 

• 스타트업이나 소규모 서비스에서 가장 흔한 패턴입니다.
• 하나의 프로젝트 안에 하나의 VPC + 여러 서브넷(Prod/Stage/Dev, FE/BE/DB) 구조로 시작합니다.
• 장점: 단순하고 관리가 쉽고, 의사결정 속도가 빠름.

 

---

 

3-2. Shared VPC 패턴

 

• 조직이 커지면, 네트워크(보안) 팀과 서비스 팀을 분리하는 것이 일반적입니다.
• Shared VPC를 쓰면:
  • 공통 네트워크(서브넷, 라우트, VPN 등)는 호스트 프로젝트에서 통합 관리
  • 각 서비스 팀은 서비스 프로젝트에서 VM, GKE, Cloud Run 등 리소스만 관리
• 장점:
  • 네트워크 정책의 일관성
  • 권한 분리(least privilege)
  • 비용·쿼터 분리(프로젝트별 청구, 리소스 한도 관리)

 

---

 

3-3. 다중 VPC + Peering / VPN 패턴

 

규제·보안 요구사항이 강한 경우,

• 민감한 서비스용 VPC
• 일반 서비스용 VPC
• DMZ / 외부 공개용 VPC 등으로 VPC를 분리하고, Peering/VPN으로 필요한 것만 연결하는 구조를 사용합니다.

 

---

4. GCP VPC Best Practices (베스트 프랙티스)

 

이제 실무에서 자주 언급되는 VPC 설계·운영 베스트 프랙티스를 정리해 보겠습니다.

 

---

 

4-1. VPC 개수 & 프로젝트 구조 설계

1. 단순하게 시작하기 – “한 프로젝트, 한 VPC”
   • 초기에는 한 프로젝트 안에 한 개의 VPC만 두고, 서브넷으로 환경/역할을 구분하는 것이 좋습니다.
2. 조직이 커지면 Shared VPC 고려
   • 여러 팀·서비스가 공통 네트워크에 올라가는 구조라면 Shared VPC로 네트워크를 중앙 관리합니다.
3. 팀/보안 경계를 VPC/프로젝트 단위로 맵핑
   • 서로 완전히 다른 보안 정책을 써야 하는 팀이나 시스템은 별도의 프로젝트+VPC로 분리하는 게 좋습니다.

 

---

 

4-2. IP 및 Subnet 설계

 

1. 충분히 넉넉한 CIDR 계획 세우기
   • 온프레/타 클라우드 연결을 고려해 중복 없는 IP 대역을 초기에 잘 잡는 것이 중요합니다.
   • 예:
     • Prod: 10.0.0.0/16
     • Stage: 10.1.0.0/16
     • Dev: 10.2.0.0/16
2. 기능/보안 영역별 Subnet 분리
   • Public(인터넷 노출), Private(내부 서비스), DB(가장 민감한 영역) 같은 식으로 서브넷을 나눕니다.
3. 리전별 서브넷 구조 통일
   • 서울/도쿄/싱가포르 리전에 동일한 패턴의 CIDR을 쓰면 운영·모니터링이 훨씬 편합니다.

---

 

4-3. 네트워크 보안 & 방화벽

 

1. 최소 권한(Least Privilege) 원칙
   • 기본 방화벽 규칙은 최대한 폐쇄적으로 두고, 서비스에 꼭 필요한 포트만 허용합니다.
2. 태그/서비스 계정 기반 규칙 활용
   • role=frontend, role=backend 같은 네트워크 태그 또는
   • sa-backend@... 같은 서비스 계정 기준으로 방화벽을 걸면, IP가 바뀌어도 정책을 유지할 수 있습니다.
3. 조직·폴더 레벨의 Hierarchical Firewall 고려
   • 여러 프로젝트에 공통으로 적용해야 하는 정책(예: “DB 포트는 특정 VPC에서만 접근 가능”)은 조직/폴더 레벨 방화벽 정책으로 관리합니다.
4. VPC Service Controls 연계
   • BigQuery, Cloud Storage 같은 관리형 서비스에 대한 데이터 유출 방지가 필요하면 VPC Service Controls로 서비스 경계를 강화하는 것도 좋은 패턴입니다.

 

---

 

4-4. 네트워크 분리(세그멘테이션) 전략

 

1. 환경별 분리: Prod / Stage / Dev
   • 최소한 Prod는 다른 환경과 VPC 또는 서브넷을 분리하고, 방화벽·IAM도 별도로 관리하는 것이 안전합니다.
2. 보안 레벨별 분리: Public / App / Data
   • 인터넷과 직접 맞닿는 레이어(Public)는 별도 서브넷/VPC에 두고, App·DB 영역은 Private 서브넷으로 둡니다.
3. 규제/컴플라이언스용 네트워크 분리
   • 금융/헬스케어 등 규제 산업에서는, 규제 데이터가 있는 VPC를 별도 프로젝트+VPC로 완전히 분리해서 설계하는 경우가 많습니다.

 

---

 

4-5. 운영·관리 Best Practice

 

1. 기본 VPC(default network)는 가급적 사용하지 않기
   • 자동으로 열린 방화벽 규칙 등으로 인해 보안상 리스크가 생길 수 있어, 실무에서는 기본 VPC를 삭제하고 직접 정의한 VPC를 쓰는 패턴이 일반적입니다.
2. 네이밍 컨벤션 통일
   • vpc-prod-core, subnet-prod-seoul-public, fw-allow-ssh-admin 이런 식으로 이름만 봐도 역할이 드러나게 규칙을 정해두면 팀이 커져도 유지보수가 쉽습니다.
3. 라우트/방화벽 변경은 IaC(Terraform 등)로 관리
   • 수동으로 콘솔에서 수정하기보다는, Terraform 등으로 버전 관리하면
     • 변경 이력 추적
     • 롤백
     • 리뷰 프로세스(Git PR)
4. 모니터링 & 로깅
   • VPC Flow Logs, 방화벽 로그를 Cloud Logging/Cloud Monitoring과 연계해 비정상 접근 탐지, 성능 병목 구간 분석

 

---

 

5. 마무리: VPC는 “처음 설계”가 중요하다

 

GCP VPC는 단순히 VM이 인터넷에 나가는 통로가 아니라,

• 서비스의 보안 경계
• 조직과 팀 구조를 반영한 아키텍처의 프레임
• 비용과 운영 효율성까지 좌우하는 핵심 인프라 자산

처음에는 “한 프로젝트, 한 VPC, 환경·역할별 서브넷 분리” 정도로 시작하고, 조직 규모와 보안 요구사항이 커질수록

• Shared VPC
• 다중 VPC + Peering/VPN
• VPC Service Controls

같은 고급 기능을 도입하는 전략이 유지보수와 확장성 두 가지를 모두 잡는 방법입니다.