VPC

클라우드 안에 우리만의 동네 만들기

강영민

2026년 07월 01일 · 0 분 소요

들어가며

최근 웹 서비스, 클라우드, 그리고 AI 애플리케이션 개발에서 인프라 구조를 이해하는 일은 점점 더 중요해지고 있습니다. 예전에는 서버 한 대에 웹 서버와 데이터베이스를 함께 올려 운영하는 경우도 많았지만, 요즘은 서비스 규모가 커지고 구조가 복잡해지면서 네트워크 설계 역시 중요한 요소가 되었습니다.

AWS를 사용하다 보면 EC2, RDS, Load Balancer, NAT Gateway 같은 여러 서비스를 만나게 됩니다. 그리고 이 서비스들을 구성할 때 거의 항상 함께 등장하는 개념이 있습니다. 바로 VPC입니다.

처음에는 VPC라는 용어가 낯설 수 있습니다. Virtual Private Cloud라는 이름도 어렵게 느껴지고, Subnet, CIDR, Route Table, Internet Gateway, Security Group 같은 용어들이 한꺼번에 나오기 때문에 더 헷갈릴 수 있습니다.

하지만 VPC는 어렵게만 볼 개념은 아닙니다.

조금 쉽게 말하면, VPC는 클라우드 안에 만드는 우리 서비스만의 네트워크 공간입니다.

이번 포스팅에서는 VPC를 이해하기 위해 필요한 기본 개념들을 일상의 예시와 함께 정리해보려 합니다.

VPC란?

VPC

정의: VPC는 Virtual Private Cloud의 약자로, 클라우드 안에 논리적으로 분리해서 만드는 나만의 가상 네트워크 공간입니다.

일상 비유: AWS라는 거대한 도시 안에 우리 회사만 사용할 수 있는 독립된 동네를 만드는 것

특징: 이 공간 안에 서버, 데이터베이스, 로드 밸런서 같은 리소스들을 배치하고, 외부 인터넷과 어떻게 연결할지, 내부 리소스끼리는 어떻게 통신할지 정할 수 있습니다.

AWS 전체를 하나의 거대한 도시라고 생각해보면, VPC는 그 도시 안에 있는 우리 회사의 독립된 구역이라고 볼 수 있습니다.

그 안에는 여러 건물이 있을 수 있습니다.

웹 서버 = 사용자가 방문하는 매장
API 서버 = 실제 업무를 처리하는 사무실
데이터베이스 = 중요한 정보를 보관하는 금고
로드 밸런서 = 방문객을 적절한 창구로 안내하는 안내 데스크

이 리소스들을 아무 곳에나 배치하는 것이 아니라, 어떤 리소스는 외부에서 접근 가능하게 하고, 어떤 리소스는 내부에서만 접근 가능하게 나누어야 합니다.

이런 구조를 만들기 위한 기본 공간이 바로 VPC입니다.

왜 VPC가 필요할까?

웹 서비스를 하나 만든다고 생각해보겠습니다.

사용자는 브라우저를 통해 서비스에 접속합니다.

서비스는 API 서버에 요청을 보내고, API 서버는 데이터베이스에서 데이터를 가져옵니다.

흐름만 보면 단순합니다.

사용자 → 웹 서버 → API 서버 → 데이터베이스

하지만 실제 운영 환경에서는 모든 서버가 외부 인터넷에 그대로 노출되면 안 됩니다.

웹 서버나 로드 밸런서는 외부 사용자의 요청을 받아야 합니다.

하지만 데이터베이스는 외부 사용자가 직접 접근하면 안 됩니다.

API 서버도 가능하다면 외부에 직접 노출하기보다는 로드 밸런서를 통해서만 접근하게 하는 것이 좋습니다.

즉 리소스마다 공개 범위가 달라야 합니다.

로드 밸런서: 외부 사용자 접근 가능
API 서버: 로드 밸런서를 통해서만 접근
데이터베이스: API 서버에서만 접근
내부 배치 서버: 외부 접근 불필요

일상적으로 비유하면 회사 건물과 비슷합니다.

회사 1층 로비는 외부 방문객이 들어올 수 있습니다.

하지만 사무실 내부, 서버실, 문서 보관실은 아무나 들어가면 안 됩니다.

클라우드에서도 마찬가지입니다.

외부에 열어야 하는 공간과 내부에 숨겨야 하는 공간을 구분해야 합니다.

VPC는 이 구분을 가능하게 해주는 기본 틀입니다.

CIDR

정의: VPC 안에서 사용할 IP 주소 범위를 정하는 방식입니다.

일상 비유: 우리 회사 동네에서 사용할 주소 체계를 정하는 것

특징: VPC를 만들 때 가장 먼저 정하는 값 중 하나이며, 이 범위 안에서 Subnet을 나누고 서버들의 내부 IP가 할당됩니다.

VPC를 만들 때 보통 이런 값을 보게 됩니다.

10.0.0.0/16

처음 보면 숫자와 슬래시 때문에 어렵게 느껴질 수 있습니다.

하지만 처음에는 이렇게 이해하면 충분합니다.

이 VPC 안에서는 10.0으로 시작하는 주소 범위를 사용하겠다.

예를 들어 VPC 주소 범위를 10.0.0.0/16으로 정했다면, 그 안에 있는 서버들은 이런 내부 주소를 가질 수 있습니다.

10.0.1.10 → 웹 서버
10.0.2.20 → API 서버
10.0.3.30 → 데이터베이스

CIDR은 결국 VPC 안에서 사용할 내부 주소 범위를 정하는 개념입니다.

Subnet

정의: VPC라는 큰 네트워크 공간을 더 작은 구역으로 나눈 것입니다.

일상 비유: 회사 부지를 사무동, 연구동, 창고, 보안 구역처럼 나누는 상황

특징: EC2, RDS 같은 리소스는 보통 특정 Subnet 안에 배치됩니다.

예를 들어 VPC 전체 주소 범위를 이렇게 잡았다고 해보겠습니다.

VPC: 10.0.0.0/16

이 VPC 안을 여러 Subnet으로 나눌 수 있습니다.

Public Subnet A:  10.0.1.0/24
Private Subnet A: 10.0.2.0/24
Public Subnet B:  10.0.3.0/24
Private Subnet B: 10.0.4.0/24

Subnet을 나누는 이유는 역할이 다른 리소스를 같은 공간에 섞어두지 않기 위해서입니다.

현실에서도 도시를 만들 때 상가 지역, 주거 지역, 공장 지역, 보안 구역을 나누듯이 클라우드에서도 역할에 따라 공간을 나눕니다.

외부 사용자가 접근해야 하는 로드 밸런서 → Public Subnet
외부에서 직접 접근하면 안 되는 API 서버 → Private Subnet
중요한 데이터를 저장하는 데이터베이스 → Private Subnet

즉 Subnet은 VPC 안에서 리소스의 위치와 역할을 나누기 위한 구역입니다.

Public Subnet과 Private Subnet

Public Subnet

정의: 인터넷과 직접 연결될 수 있는 Subnet입니다.

일상 비유: 외부 손님이 들어올 수 있는 회사 로비나 매장 입구

특징: 보통 Internet Gateway로 향하는 경로가 Route Table에 설정되어 있습니다.

Public Subnet에는 보통 외부 요청을 받아야 하는 리소스를 둡니다.

Load Balancer
Bastion Host
외부 공개용 웹 서버

다만 Public Subnet에 있다고 해서 모든 리소스가 자동으로 인터넷에 공개되는 것은 아닙니다.

외부에서 접근하려면 보통 다음 조건들이 함께 필요합니다.

VPC에 Internet Gateway가 연결되어 있어야 함
Subnet의 Route Table에 Internet Gateway 경로가 있어야 함
리소스에 Public IP가 있어야 함
Security Group에서 필요한 포트가 열려 있어야 함

즉 Public Subnet은 “외부와 연결될 수 있는 길이 있는 구역”이지, 무조건 모두에게 공개된 구역은 아닙니다.

Private Subnet

정의: 인터넷에서 직접 접근할 수 없도록 내부에 숨겨둔 Subnet입니다.

일상 비유: 회사 내부 사무실, 서버실, 금고방처럼 외부 손님이 직접 들어올 수 없는 공간

특징: 외부에서 직접 들어오는 길은 막고, 필요한 경우 NAT Gateway를 통해 내부에서 외부로 나가는 요청만 가능하게 구성합니다.

Private Subnet에는 보통 중요한 리소스를 둡니다.

Application Server
Database
Cache Server
Batch Server
Worker Server

데이터베이스를 예로 들어보겠습니다.

사용자가 웹사이트를 이용한다고 해서 데이터베이스에 직접 접속할 필요는 없습니다.

사용자는 웹 서버나 API 서버에 요청을 보내고, API 서버가 데이터베이스와 통신하면 됩니다.

사용자 → Load Balancer → API Server → Database

이 구조에서 사용자는 Load Balancer까지만 접근합니다.

API 서버와 데이터베이스는 내부에 숨겨둘 수 있습니다.

이렇게 구성하면 보안 측면에서 훨씬 안전합니다.

Route Table

정의: 네트워크 트래픽이 어디로 가야 하는지 알려주는 경로 규칙입니다.

일상 비유: 동네 안에 설치된 도로 표지판 또는 내비게이션

특징: Subnet과 연결되어 있으며, 어떤 목적지로 가는 트래픽을 어디로 보낼지 결정합니다.

VPC 안에 서버를 만들었다고 해서 트래픽이 자동으로 원하는 곳으로 이동하는 것은 아닙니다.

트래픽도 길을 알아야 합니다.

예를 들어 이런 Route Table이 있다고 해보겠습니다.

10.0.0.0/16 → local
0.0.0.0/0   → Internet Gateway

이걸 말로 풀면 이렇게 볼 수 있습니다.

10.0.0.0/16 범위의 주소는 VPC 내부에서 처리한다.
그 외 모든 목적지는 Internet Gateway로 보낸다.

여기서 0.0.0.0/0은 쉽게 말해 “나머지 모든 곳” 정도로 이해하면 됩니다.

Route Table이 중요한 이유는 길이 없으면 트래픽이 갈 수 없기 때문입니다.

서버가 켜져 있고 Security Group이 열려 있어도, Route Table에 경로가 없으면 통신이 되지 않을 수 있습니다.

현실에서도 건물이 아무리 잘 지어져 있어도, 그 건물로 가는 도로가 끊겨 있으면 갈 수 없습니다.

VPC에서도 마찬가지입니다.

Internet Gateway

정의: VPC가 외부 인터넷과 통신할 수 있게 해주는 출입구입니다.

일상 비유: 우리 회사 동네와 외부 도로를 연결하는 정문

특징: Public Subnet에서 인터넷으로 나가거나, 인터넷에서 Public Subnet의 리소스로 들어오기 위해 사용됩니다.

VPC는 기본적으로 독립된 네트워크 공간입니다.

그 공간이 외부 인터넷과 통신하려면 출입구가 필요합니다.

그 역할을 하는 것이 Internet Gateway입니다.

하지만 Internet Gateway를 VPC에 연결했다고 해서 모든 리소스가 바로 인터넷과 연결되는 것은 아닙니다.

Internet Gateway 연결
Route Table 경로 설정
Public IP 할당
Security Group 포트 허용

이 조건들이 함께 맞아야 외부에서 접근할 수 있습니다.

Internet Gateway는 정문입니다.

하지만 정문이 있다고 해서 모든 방의 문이 열려 있는 것은 아닙니다.

NAT Gateway

정의: Private Subnet 안에 있는 리소스가 외부 인터넷으로 요청을 보낼 수 있게 도와주는 서비스입니다.

일상 비유: 외부에 직접 나갈 수 없는 내부 직원 대신 심부름을 다녀오는 담당자

특징: Private Subnet의 리소스가 외부로 나갈 수는 있게 하지만, 외부에서 Private Subnet으로 직접 들어오게 하지는 않습니다.

Private Subnet의 서버도 가끔 외부 인터넷이 필요할 때가 있습니다.

OS 패키지 업데이트
Docker 이미지 다운로드
외부 API 호출
라이브러리 설치
보안 패치 다운로드

하지만 이런 이유로 Private Subnet의 서버를 인터넷에 직접 노출하는 것은 좋지 않습니다.

이때 사용하는 것이 NAT Gateway입니다.

흐름은 대략 이렇습니다.

Private Subnet의 서버
  ↓
NAT Gateway
  ↓
Internet

즉 서버가 직접 밖으로 나가는 것이 아니라, NAT Gateway가 외부 요청을 대신 처리해주는 방식입니다.

중요한 점은 NAT Gateway가 외부에서 Private Subnet으로 들어오기 위한 문은 아니라는 것입니다.

NAT Gateway는 내부 리소스가 외부로 나가기 위한 통로입니다.

Security Group

정의: EC2, RDS, Load Balancer 같은 리소스 단위에 적용하는 가상 방화벽입니다.

일상 비유: 각 건물 출입문 앞에 있는 보안 담당자

특징: 어떤 IP 또는 어떤 리소스가 어떤 포트로 들어올 수 있는지 제어합니다.

예를 들어 웹 서버의 Security Group은 이렇게 설정할 수 있습니다.

80번 포트  → 전체 허용
443번 포트 → 전체 허용
22번 포트  → 내 사무실 IP에서만 허용

데이터베이스의 Security Group은 더 엄격하게 설정할 수 있습니다.

3306번 포트 → API 서버에서만 허용
외부 인터넷 → 직접 접근 불가

이렇게 하면 사용자는 웹 서버에는 접근할 수 있지만, 데이터베이스에는 직접 접근할 수 없습니다.

Security Group의 중요한 특징은 stateful이라는 점입니다.

쉽게 말하면 요청과 응답의 관계를 기억한다는 뜻입니다.

서버가 외부 API에 요청을 보냈다면, 그 요청에 대한 응답은 자연스럽게 다시 서버로 돌아올 수 있습니다.

요청과 응답의 흐름을 기억하기 때문입니다.

Network ACL

정의: Subnet 단위로 적용하는 네트워크 접근 제어 규칙입니다.

일상 비유: 동네 입구에 있는 검문소

특징: Security Group보다 더 넓은 범위인 Subnet 단위에서 인바운드, 아웃바운드 트래픽을 허용하거나 차단합니다.

Security Group이 각 건물의 출입문 보안이라면, Network ACL은 동네 입구의 검문소에 가깝습니다.

Security Group = 건물 출입문 보안
Network ACL    = 동네 입구 검문소

Network ACL의 중요한 특징은 stateless라는 점입니다.

Security Group은 요청과 응답의 관계를 기억하지만, Network ACL은 기억하지 않습니다.

그래서 들어오는 규칙과 나가는 규칙을 각각 따로 봐야 합니다.

처음에는 이렇게 기억하면 좋습니다.

Security Group은 리소스 단위의 방화벽
Network ACL은 Subnet 단위의 방화벽
Security Group은 stateful
Network ACL은 stateless

Availability Zone

정의: 하나의 리전 안에 있는 물리적으로 분리된 데이터센터 구역입니다.

일상 비유: 같은 도시 안에 있지만 서로 떨어져 있는 여러 지점의 사무실 또는 창고

특징: 장애에 대비하기 위해 리소스를 여러 Availability Zone에 나눠 배치할 수 있습니다.

AWS에서 VPC는 특정 리전 안에 생성됩니다.

예를 들어 서울 리전을 사용한다면, VPC는 서울 리전 안에 만들어집니다.

그리고 그 리전 안에는 여러 Availability Zone이 있습니다.

운영 환경에서는 보통 Public Subnet과 Private Subnet을 여러 AZ에 나눠 구성합니다.

AZ A
- Public Subnet A
- Private Subnet A

AZ C
- Public Subnet C
- Private Subnet C

이렇게 구성하는 이유는 장애에 대비하기 위해서입니다.

모든 서버를 하나의 구역에만 배치했는데 그 구역에 문제가 생기면 서비스 전체가 영향을 받을 수 있습니다.

반대로 여러 AZ에 나눠두면 한쪽에 문제가 생겨도 다른 쪽에서 서비스를 계속할 가능성이 높아집니다.

전체 흐름 예시

간단한 웹 서비스를 하나 만든다고 가정해보겠습니다.

요구사항은 다음과 같습니다.

사용자는 웹사이트에 접속할 수 있어야 함
외부 요청은 Load Balancer가 받아야 함
Application Server는 외부에 직접 노출하지 않음
Database는 Application Server에서만 접근 가능해야 함
Application Server는 외부 API 호출이나 패키지 업데이트가 가능해야 함

이 구조를 VPC로 표현하면 대략 이렇게 볼 수 있습니다.

VPC: 10.0.0.0/16

Public Subnet
- Load Balancer
- NAT Gateway

Private Subnet
- Application Server
- Database

사용자의 요청 흐름은 이렇게 됩니다.

사용자
  ↓
Internet
  ↓
Internet Gateway
  ↓
Load Balancer
  ↓
Application Server
  ↓
Database

Private Subnet의 Application Server가 외부 인터넷으로 나가야 할 때는 이렇게 됩니다.

Application Server
  ↓
NAT Gateway
  ↓
Internet

보안 규칙은 대략 이런 식으로 잡을 수 있습니다.

Load Balancer
- 80, 443 포트: 전체 인터넷에서 허용

Application Server
- 애플리케이션 포트: Load Balancer에서만 허용

Database
- DB 포트: Application Server에서만 허용

이 구조의 핵심은 단순합니다.

외부 사용자는 Load Balancer까지만 접근합니다.

Application Server와 Database는 외부에 직접 노출하지 않습니다.

Private Subnet의 서버가 외부로 나갈 필요가 있을 때는 NAT Gateway를 사용합니다.

핵심 구분

VPC를 처음 공부할 때는 여러 용어가 한꺼번에 나오기 때문에 헷갈리기 쉽습니다.

그래서 각 개념을 역할 중심으로 구분해보면 이해가 조금 쉬워집니다.

VPC
→ 클라우드 안에 만드는 우리 서비스의 독립된 네트워크 공간

CIDR
→ VPC 안에서 사용할 주소 범위

Subnet
→ VPC 안을 역할별로 나눈 구역

Public Subnet
→ 인터넷과 직접 연결될 수 있는 구역

Private Subnet
→ 외부에서 직접 접근하지 못하게 숨겨둔 구역

Route Table
→ 트래픽이 어디로 가야 하는지 알려주는 경로 규칙

Internet Gateway
→ VPC와 인터넷을 연결하는 정문

NAT Gateway
→ Private Subnet의 리소스가 외부로 나가도록 도와주는 대리인

Security Group
→ 리소스 단위의 방화벽

Network ACL
→ Subnet 단위의 방화벽

Availability Zone
→ 장애에 대비하기 위해 나눠진 데이터센터 구역

실무에서의 고려사항

1) 데이터베이스는 가능하면 Private Subnet에 두기

데이터베이스는 외부 사용자에게 직접 노출될 이유가 거의 없습니다.

일반적으로는 Application Server만 데이터베이스에 접근하도록 구성하는 것이 좋습니다.

사용자 → Load Balancer → Application Server → Database

2) Public Subnet에는 꼭 필요한 리소스만 두기

Public Subnet은 인터넷과 직접 연결될 수 있는 구역입니다.

따라서 아무 리소스나 Public Subnet에 두는 것은 좋지 않습니다.

보통 외부 요청을 받아야 하는 Load Balancer나 Bastion Host 정도를 Public Subnet에 두고, 실제 Application Server는 Private Subnet에 두는 구성이 많이 사용됩니다.

3) Private Subnet의 외부 통신은 NAT Gateway로 처리하기

Private Subnet의 서버도 외부 API 호출이나 패키지 업데이트가 필요할 수 있습니다.

이때 서버를 Public Subnet으로 옮기기보다는 NAT Gateway를 통해 외부로 나가게 구성하는 것이 좋습니다.

4) Security Group은 최소한으로 열기

Security Group은 필요한 포트만 열어야 합니다.

나쁜 예시:
3306 포트를 전체 인터넷에 허용

좋은 예시:
3306 포트를 Application Server에서만 허용

특히 SSH, DB 포트처럼 민감한 포트는 전체 인터넷에 열어두지 않는 것이 좋습니다.

마치며

정리해보면, VPC는 클라우드 안에 만드는 우리 서비스만의 독립된 네트워크 공간이라고 볼 수 있습니다. 처음에는 CIDR, Subnet, Route Table, Internet Gateway, NAT Gateway, Security Group, Network ACL 같은 용어들이 한꺼번에 나와 어렵게 느껴질 수 있지만, 각각의 역할을 일상적인 비유로 이해하면 훨씬 덜 복잡하게 느껴집니다.

VPC는 회사의 사유지와 비슷합니다.

CIDR은 그 사유지 안에서 사용할 주소 체계이고, Subnet은 역할별로 나눈 구역입니다.

Route Table은 길 안내 표지판이고, Internet Gateway는 외부로 나가는 정문입니다.

NAT Gateway는 내부 리소스를 대신해 외부 요청을 처리하는 심부름 담당자이며, Security Group은 각 건물의 출입문 보안, Network ACL은 동네 입구의 검문소라고 볼 수 있습니다.

결국 VPC를 이해한다는 것은 단순히 서버를 어디에 둘지 정하는 문제가 아닙니다.

외부에 어떤 문을 열어둘지, 어떤 리소스는 내부에 숨길지, 어떤 길로 트래픽을 보내야 할지, 누가 어떤 포트로 접근할 수 있는지를 설계하는 일입니다.

처음부터 모든 네트워크 이론을 완벽하게 이해할 필요는 없다고 생각합니다.

다만 VPC를 볼 때마다 다음 질문을 던져보면 좋을 것 같습니다.

외부에서 직접 접근이 가능해야 할까? 내부에서만 접근하면 될까? 인터넷으로 나가는 길이 필요할까? 누가 어떤 포트로 접근할 수 있어야 할까?

이러한 질문들에 답하다 보면 VPC는 막연하게 어려운 네트워크 용어 묶음이 아니라, 서비스를 안전하고 안정적으로 운영하기 위한 기본 설계 도구로 보이기 시작할 것입니다.

읽어주셔서 감사합니다.