VPC(Virtual Private Cloud) 완전 정복 – 클라우드 안에 내 전용 네트워크 만드는 법 3단계

VPC(Virtual Private Cloud) 완전 정복

VPC(Virtual Private Cloud) 완전 정복 – 클라우드 안에 내 전용 네트워크 만드는 법 3단계

📌 목차

• VPC가 뭔지 모르면 클라우드 쓰는 게 아니다
• VPC의 핵심 구성요소 – 서브넷, 라우팅 테이블, 게이트웨이
• 퍼블릭 서브넷 vs 프라이빗 서브넷, 뭐가 다른가?
• 보안그룹(Security Group)과 NACL – 방화벽 두 겹으로 막는 법
• VPC Peering과 Transit Gateway – 여러 VPC 연결하기
• 실무에서 VPC 설계할 때 흔히 저지르는 실수들
• 정리

---

클라우드 인프라에서 "VPC"를 제대로 설계하면, 외부 침입은 원천 차단하면서도 내부 서비스끼리 빠르게 통신하는 격리된 전용 네트워크 환경을 구축할 수 있다.

솔직히 말하면, 클라우드 처음 쓸 때 VPC 개념을 그냥 넘기는 경우가 많다. EC2 하나 띄우고, 보안그룹 열고, 퍼블릭 IP 붙이면 일단 되니까. 근데 서비스가 조금이라도 커지거나, 보안이 중요한 환경이 되면 VPC 설계를 제대로 못 한 게 그대로 사고로 이어진다. 이 글에서는 "VPC"가 왜 존재하는지, 어떻게 구성하는지, 실무에서 어디서 막히는지를 정리했다.

---

🌐 VPC가 뭔지 모르면 클라우드 쓰는 게 아니다

"VPC"는 Virtual Private Cloud의 줄임말이다. 직역하면 '가상 사설 클라우드'인데, 쉽게 말하면 AWS나 GCP 같은 퍼블릭 클라우드 안에 나만 쓰는 격리된 네트워크 공간을 만드는 것이다.

오피스텔 한 동을 빌렸는데, 건물 안에 내 사무실만 따로 열쇠를 가진 구역이 있는 느낌이라고 보면 된다. 건물 자체는 공용(퍼블릭 클라우드)이지만, 내 구역 안에서는 내가 원하는 대로 방을 나누고 출입 통제를 하는 거다.

AWS 기준으로 보면, "VPC"를 생성할 때 IP 대역(CIDR)을 지정한다. 예를 들어 10.0.0.0/16으로 설정하면 10.0.0.0 ~ 10.0.255.255 범위의 IP를 내 네트워크에서 자유롭게 사용할 수 있다. 약 65,536개의 IP가 생기는 셈이다.

이 공간 안에서 서브넷을 나누고, 라우팅 규칙을 정하고, 인터넷과 연결할지 말지를 결정한다. 이게 VPC의 기본 개념이다.

---

🧱 VPC의 핵심 구성요소 – 서브넷, 라우팅 테이블, 게이트웨이

VPC를 만들었다고 끝이 아니다. 실제로 서버를 올리고 통신하려면 세 가지를 반드시 이해해야 한다.

서브넷(Subnet) VPC 안에서 더 잘게 쪼갠 IP 구역이다. 10.0.1.0/24처럼 특정 범위를 할당하고, 그 안에 EC2 인스턴스나 RDS를 배치한다. 서브넷은 특정 가용영역(AZ)에 묶이는데, 고가용성을 위해 보통 여러 AZ에 걸쳐 서브넷을 만든다.

라우팅 테이블(Route Table) "이 패킷은 어디로 보내야 하나"를 결정하는 규칙표다. 서브넷마다 라우팅 테이블이 붙는다. 예를 들어, 0.0.0.0/0 → Internet Gateway 라는 규칙이 있으면 이 서브넷에서 나가는 모든 트래픽은 인터넷 게이트웨이를 통해 외부로 나간다.

게이트웨이(Gateway) 인터넷과 연결하려면 **인터넷 게이트웨이(IGW)**가 필요하다. 프라이빗 서브넷에서 인터넷에 나가야 할 때는 NAT 게이트웨이를 쓴다. 온프레미스 서버와 연결할 때는 VPN Gateway 또는 Direct Connect를 사용한다.

이 세 가지가 맞물려야 실제로 트래픽이 흐른다. 구성요소 하나만 빠져도 통신이 안 된다는 걸 실수하고 나서야 깨닫는 경우가 많다.

---

🔀 퍼블릭 서브넷 vs 프라이빗 서브넷, 뭐가 다른가?

실무 설계에서 가장 기본이 되는 개념이다.

퍼블릭 서브넷은 인터넷 게이트웨이로 향하는 라우팅이 있고, 내부 리소스에 퍼블릭 IP를 붙일 수 있다. 외부에서 직접 접근이 가능한 구역이다. 주로 로드밸런서(ALB), Bastion Host, NAT Gateway 같은 것들을 여기 올린다.

프라이빗 서브넷은 인터넷 게이트웨이로의 직접 경로가 없다. 외부에서 직접 접근이 불가능하고, 내부에서만 통신한다. 실제 애플리케이션 서버(WAS), 데이터베이스(RDS), 캐시 서버(ElastiCache) 등은 여기 배치한다.

왜 굳이 나누냐고? 보안 때문이다. DB 서버가 퍼블릭에 노출되면 공격 표면이 그만큼 넓어진다. 프라이빗 서브넷에 두면 직접 접근 자체가 불가능하다.

실무에서 흔히 쓰는 패턴은 이렇다:

• ALB → 퍼블릭 서브넷
• WAS(Web Application Server) → 프라이빗 서브넷
• DB → 프라이빗 서브넷 (DB 전용으로 별도 구성)

이 구조만 잡아도 기본적인 보안 설계는 된다.

---

🛡️ 보안그룹(Security Group)과 NACL – 방화벽 두 겹으로 막는 법

"VPC" 안에서 트래픽을 통제하는 방법은 두 가지다.

**보안그룹(Security Group)**은 인스턴스 레벨에서 동작하는 가상 방화벽이다. 상태 저장(Stateful) 방식이라, 인바운드를 허용하면 응답 트래픽은 자동으로 허용된다. 규칙은 허용만 있고 거부는 없다. 명시적으로 허용하지 않은 건 전부 막힌다.

예시를 들면, 웹 서버 보안그룹에 80(HTTP), 443(HTTPS) 인바운드 허용을 설정하고, DB 보안그룹에는 웹 서버 보안그룹으로부터의 3306 허용만 열어놓는 식이다. 이렇게 보안그룹끼리 연결해서 참조하는 게 깔끔하다.

**NACL(Network Access Control List)**은 서브넷 레벨에서 동작한다. 상태 비저장(Stateless) 방식이라, 인바운드·아웃바운드를 각각 따로 설정해야 한다. 허용/거부 둘 다 설정 가능하다. 특정 IP를 아예 차단해야 할 때 유용하다.

두 개를 같이 쓰면 방어선이 이중으로 생긴다. 보안그룹이 뚫려도 NACL에서 한 번 더 걸러주는 구조다.

---

🔗 VPC Peering과 Transit Gateway – 여러 VPC 연결하기

서비스가 커지면 VPC를 여러 개 만들게 된다. 개발용 VPC, 운영용 VPC, 보안 감사용 VPC처럼. 근데 이 VPC들끼리 통신이 필요한 경우가 생긴다.

VPC Peering은 두 VPC를 1:1로 연결하는 방식이다. 설정이 간단하고 지연시간도 낮다. 단점은 전이적 라우팅이 안 된다는 거다. A-B, B-C가 Peering이어도 A에서 C로 직접 못 간다. VPC가 3개만 넘어도 관리가 복잡해진다.

Transit Gateway는 허브 역할을 하는 중앙 라우터다. 여러 VPC를 하나의 Transit Gateway에 연결하면 모든 VPC가 서로 통신할 수 있다. 수십 개의 VPC를 연결해야 하는 대규모 환경에서는 Transit Gateway가 답이다. 비용이 좀 더 들지만, 관리 편의성이 압도적이다.

---

⚠️ 실무에서 VPC 설계할 때 흔히 저지르는 실수들

경험상 자주 보는 실수들을 정리하면 이렇다.

첫 번째, CIDR 대역을 너무 좁게 잡는 것이다. 처음에 /24로 잡았다가 나중에 서버가 늘어나면 IP가 부족해진다. VPC CIDR은 한번 정하면 변경이 복잡하니까, 처음부터 충분히 넓게 잡는 게 좋다. 보통 /16 정도로 시작한다.

두 번째, 보안그룹에 0.0.0.0/0 오픈하는 것이다. 빠르게 테스트한다고 전체 오픈해놓고 그냥 운영에 올라가는 경우가 있다. 운영 환경에서는 절대 하면 안 된다.

세 번째, AZ를 하나만 쓰는 것이다. 가용영역 하나가 장애 나면 전체 서비스가 다운된다. 최소 2개 이상의 AZ에 서브넷을 분산시켜야 한다.

네 번째, NAT Gateway를 AZ별로 만들지 않는 것이다. NAT Gateway도 AZ 종속이라, 특정 AZ 장애 시 다른 AZ의 프라이빗 서브넷 트래픽이 막힐 수 있다. 각 AZ마다 NAT Gateway를 두는 게 맞다.

---

"VPC"는 클라우드 인프라의 기초 중의 기초다. 이걸 제대로 이해하고 설계해두면 나중에 서비스가 커져도 확장이 편하고, 보안 사고 가능성도 훨씬 줄어든다. 처음에 귀찮더라도 퍼블릭/프라이빗 서브넷 분리, 보안그룹 최소 권한 원칙, 멀티 AZ 구성은 기본으로 잡고 가자.

---

출처 및 참고

• AWS 공식 문서: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
• AWS Well-Architected Framework: https://aws.amazon.com/architecture/well-architected/
• Google Cloud VPC 문서: https://cloud.google.com/vpc/docs/overview