클라우드 환경에서 서버를 구축할 때 가장 먼저 이해해야 하는 요소 중 하나가 네트워크 구조입니다. 온프레미스 환경에서는 물리적인 스위치와 라우터, 방화벽을 이용해 네트워크를 구성하지만, 클라우드에서는 이러한 기능을 소프트웨어 기반의 가상 네트워크로 구현합니다. 이때 핵심적인 역할을 하는 것이 VPC(Virtual Private Cloud)입니다.
VPC는 클라우드에서 논리적으로 격리된 네트워크 공간을 제공하며, 사용자가 IP 주소 범위와 서브넷, 라우팅 및 접근통제 정책을 직접 설계할 수 있도록 지원합니다. 이번 글에서는 클라우드 네트워크의 기본 구조를 살펴보고, VPC를 구성하는 주요 요소와 보안 관점에서 확인해야 할 사항을 정리하겠습니다.
1. 클라우드 네트워크란?
클라우드 네트워크는 클라우드 사업자가 제공하는 인프라에서 서버와 데이터베이스, 스토리지 등의 리소스가 서로 통신할 수 있도록 구성한 네트워크 환경입니다. 기존의 물리적 네트워크와 달리 클라우드에서는 관리 콘솔이나 API, IaC(Infrastructure as Code)를 통해 네트워크를 생성하고 변경할 수 있습니다.
대표적인 클라우드 네트워크 서비스로는 AWS의 Amazon VPC, Microsoft Azure의 Virtual Network(VNet), Google Cloud의 Virtual Private Cloud(VPC)가 있습니다. 서비스별 구현 방식에는 차이가 있지만, 네트워크를 논리적으로 분리하고 통신 경로와 접근 권한을 관리한다는 공통적인 목적을 가지고 있습니다.
클라우드 네트워크의 주요 특징은 다음과 같습니다.
- 논리적 격리: 서로 다른 네트워크 환경을 분리하여 운영할 수 있습니다.
- 유연한 확장: 서비스 증가에 따라 서브넷과 네트워크 구성을 확장할 수 있습니다.
- 접근통제: 보안 그룹과 네트워크 ACL 등을 통해 통신을 제한할 수 있습니다.
- 자동화: API와 IaC를 활용해 네트워크 구성을 일관되게 배포할 수 있습니다.
다만 가상 네트워크를 사용한다고 해서 보안이 자동으로 보장되는 것은 아닙니다. 잘못된 라우팅이나 접근통제 정책은 외부 노출과 내부 시스템 간 불필요한 통신을 허용할 수 있습니다.
2. VPC의 개념과 역할
VPC는 클라우드 환경에서 사용자가 정의하고 관리하는 논리적으로 격리된 가상 네트워크입니다.
AWS를 기준으로 VPC를 생성할 때는 네트워크에서 사용할 IP 주소 범위를 CIDR(Classless Inter-Domain Routing) 형식으로 지정합니다.
예를 들어 10.0.0.0/16을 VPC의 IPv4 CIDR 블록으로 설정하면 해당 주소 범위를 기반으로 여러 서브넷을 구성할 수 있습니다.
VPC의 핵심 역할은 크게 세 가지입니다.
첫째, 네트워크 격리입니다. 서로 다른 업무 시스템이나 개발·운영 환경을 별도의 VPC로 분리하여 관리할 수 있습니다.
둘째, 통신 경로 관리입니다. 라우팅 테이블과 게이트웨이를 통해 인터넷 및 다른 네트워크와의 연결 경로를 설정합니다.
셋째, 네트워크 접근통제입니다. 보안 그룹과 네트워크 ACL을 사용하여 허용할 트래픽을 제한할 수 있습니다.
VPC 자체는 논리적 격리 환경을 제공하지만, 외부 연결이나 접근통제는 별도의 네트워크 구성 요소를 통해 설정해야 합니다.
3. VPC를 구성하는 주요 요소
VPC 내부에는 여러 네트워크 구성 요소가 존재하며, 각각의 기능을 이해해야 전체 통신 구조를 설계할 수 있습니다.
① 서브넷(Subnet)
서브넷은 VPC의 IP 주소 범위를 더 작은 네트워크 단위로 나눈 것입니다. AWS에서는 서브넷이 하나의 가용 영역(Availability Zone)에 속합니다. 일반적으로 인터넷으로 직접 라우팅할 수 있는 퍼블릭 서브넷과 그렇지 않은 프라이빗 서브넷으로 구분합니다.
예를 들어 웹 서버는 퍼블릭 서브넷에, 애플리케이션 서버와 데이터베이스는 프라이빗 서브넷에 배치할 수 있습니다. 단, 퍼블릭 서브넷에 배치했다는 사실만으로 인스턴스가 인터넷에서 접근 가능한 것은 아닙니다. 퍼블릭 IP 주소, 라우팅 및 보안 정책 등의 조건도 충족해야 합니다.
② 라우팅 테이블(Route Table)
라우팅 테이블은 네트워크 트래픽의 목적지에 따라 다음 전달 경로를 결정하는 규칙의 집합입니다.
예를 들어 인터넷 게이트웨이로 향하는 0.0.0.0/0 경로를 설정하면 해당 라우팅 테이블을 사용하는 서브넷에서 인터넷 방향으로 트래픽을 전달할 수 있습니다.
라우팅 테이블은 통신 경로를 결정하는 요소이며, 트래픽의 허용 여부를 판단하는 보안 그룹이나 네트워크 ACL과는 역할이 다릅니다.
③ 인터넷 게이트웨이(Internet Gateway)
인터넷 게이트웨이는 VPC와 인터넷 사이의 통신을 지원하는 구성 요소입니다. AWS에서는 VPC에 인터넷 게이트웨이를 연결하고, 해당 게이트웨이로 향하는 라우팅을 설정하여 인터넷 연결 경로를 구성합니다.
④ NAT 게이트웨이(NAT Gateway)
NAT 게이트웨이는 프라이빗 서브넷에 있는 리소스가 외부 인터넷으로 연결을 시작할 수 있도록 지원합니다. 대표적인 활용 사례는 프라이빗 서버의 운영체제 업데이트나 외부 API 호출입니다. 일반적인 퍼블릭 NAT 게이트웨이 구성에서는 외부 인터넷에서 프라이빗 인스턴스로 직접 시작하는 연결을 허용하지 않습니다.
⑤ 보안 그룹(Security Group)
보안 그룹은 AWS에서 인스턴스 등의 리소스에 적용하는 상태 저장(Stateful) 방식의 가상 방화벽입니다. 인바운드와 아웃바운드 규칙을 통해 허용할 프로토콜, 포트 및 통신 대상을 설정합니다. 허용된 요청에 대한 응답 트래픽은 상태 추적에 따라 처리되므로, 응답 방향의 규칙을 별도로 추가할 필요가 없는 경우가 일반적입니다.
⑥ 네트워크 ACL(Network ACL)
네트워크 ACL은 AWS 서브넷 수준에서 트래픽을 제어하는 접근통제 기능입니다. 보안 그룹과 달리 상태 비저장(Stateless) 방식으로 동작하며, 허용 규칙과 거부 규칙을 모두 설정할 수 있습니다. 상태 비저장 방식이므로 필요한 응답 트래픽도 별도의 규칙으로 허용해야 합니다.
4. 퍼블릭 서브넷과 프라이빗 서브넷의 차이
클라우드 네트워크를 설계할 때 중요한 원칙 중 하나는 외부 접근이 필요한 시스템과 내부에서만 사용해야 하는 시스템을 구분하는 것입니다. 퍼블릭 서브넷은 인터넷 게이트웨이로 향하는 경로가 존재하는 서브넷입니다. 외부 사용자에게 서비스를 제공하는 웹 서버나 인터넷 연결이 필요한 로드 밸런서 등을 배치할 수 있습니다.
반면 프라이빗 서브넷은 인터넷 게이트웨이로 직접 연결되는 경로가 없는 서브넷입니다. 애플리케이션 서버와 데이터베이스 등 외부에서 직접 접근할 필요가 없는 시스템을 배치하는 데 적합합니다.
예를 들어 3계층 웹 서비스를 구성한다면 다음과 같은 구조를 고려할 수 있습니다.
- 웹 계층: 퍼블릭 서브넷의 인터넷 연결 로드 밸런서
- 애플리케이션 계층: 프라이빗 서브넷의 애플리케이션 서버
- 데이터베이스 계층: 별도의 프라이빗 서브넷에 배치된 데이터베이스
이러한 구조에서는 외부 사용자가 데이터베이스에 직접 접근하지 않고, 정해진 애플리케이션 경로를 통해서만 데이터에 접근하도록 설계할 수 있습니다.
5. VPC 구성 시 고려해야 할 보안 사항
VPC는 클라우드 네트워크의 기본적인 격리 환경이지만, 안전한 운영을 위해서는 세부적인 보안 설정이 필요합니다.
첫째, 최소 권한 원칙을 적용해야 합니다.
보안 그룹에서 0.0.0.0/0을 출발지로 허용하면 모든 IPv4 주소에서 해당 포트로 접근을 시도할 수 있습니다.
따라서 SSH(22), RDP(3389), 데이터베이스 포트 등 관리 및 내부 서비스용 포트는 필요한 출발지에서만 접근하도록 제한해야 합니다.
둘째, 네트워크를 업무별로 분리해야 합니다.
운영 환경과 개발 환경, 외부 서비스와 내부 관리 시스템을 적절하게 분리하면 침해사고 발생 시 공격자의 이동 범위를 줄이는 데 도움이 됩니다.
셋째, 불필요한 인터넷 노출을 최소화해야 합니다.
데이터베이스와 내부 애플리케이션 서버에는 특별한 필요가 없다면 퍼블릭 IP 주소를 부여하지 않는 것이 좋습니다. 외부 서비스 접근이 필요한 경우에도 NAT 게이트웨이나 VPC 엔드포인트 등의 활용 가능성을 검토해야 합니다.
넷째, 네트워크 로그와 설정 변경을 점검해야 합니다.
AWS 환경에서는 VPC Flow Logs를 통해 네트워크 인터페이스 등의 트래픽 메타데이터를 수집할 수 있습니다. 또한 AWS CloudTrail을 활용하면 VPC 및 관련 리소스에 대한 API 작업 이력을 추적할 수 있습니다. 다만 VPC Flow Logs는 패킷 전체 내용을 저장하는 기능이 아니므로, 필요한 가시성 수준에 따라 추가적인 모니터링 수단을 고려해야 합니다.
6. VPC 설계 시 자주 발생하는 실수
클라우드 네트워크를 처음 구성할 때는 다음과 같은 실수가 발생하기 쉽습니다.
첫째, 서브넷의 이름만 보고 퍼블릭 또는 프라이빗 여부를 판단하는 것입니다.
AWS에서는 서브넷 이름이 아니라 연결된 라우팅 테이블의 인터넷 게이트웨이 경로를 기준으로 구분해야 합니다.
둘째, 보안 그룹에서 과도하게 넓은 접근 범위를 허용하는 것입니다.
테스트 목적으로 전체 IP 주소에 접근을 허용한 뒤 이를 운영 환경에 그대로 유지하면 불필요한 공격 표면이 발생할 수 있습니다.
셋째, IP 주소 대역을 충분히 고려하지 않는 것입니다.
VPC와 온프레미스 네트워크 또는 다른 VPC의 CIDR이 중복되면 VPN이나 네트워크 연결을 구성할 때 라우팅 문제가 발생할 수 있습니다.
넷째, 가용 영역을 하나만 사용하는 것입니다.
중요 서비스는 장애 대응을 위해 복수의 가용 영역에 서브넷과 리소스를 분산하는 방안을 검토해야 합니다.
7. 마무리
클라우드 네트워크는 물리적인 네트워크 장비 대신 가상화된 네트워크 기능을 활용하여 서버와 서비스를 연결하는 구조입니다.
VPC는 이러한 클라우드 네트워크의 핵심 요소로, 네트워크 격리와 IP 주소 관리, 통신 경로 및 접근통제 정책을 구성하는 기반이 됩니다.
특히 서브넷, 라우팅 테이블, 인터넷 게이트웨이, NAT 게이트웨이, 보안 그룹의 역할을 정확히 이해하는 것이 중요합니다.
VPC를 안전하게 운영하려면 네트워크를 분리하는 것에 그치지 않고, 실제 통신 경로와 접근 허용 범위를 지속적으로 점검해야 합니다. 클라우드 환경에서는 네트워크 설정이 코드와 API로 쉽게 변경될 수 있으므로, 초기 설계뿐 아니라 운영 단계에서의 설정 변경 관리와 모니터링도 함께 고려해야 합니다.