Azure Virtual Network

클라우드에 VM 몇 대를 올리고 나면 곧 이 질문이 생깁니다. 이 VM들이 서로 어떻게 통신해야 하고, 외부에서는 어디까지 접근할 수 있어야 하는가. 네트워크 경계가 없으면 모든 리소스가 같은 평면에 놓입니다. 데이터베이스가 인터넷에 직접 열려 있거나, 개발 서버와 프로덕션 서버가 같은 네트워크에 섞이는 상황이 생깁니다. 방화벽 규칙만으로 통제하려 해도 리소스가 어느 네트워크에 속하는지 구분이 없으면 규칙이 쌓이고 실수가 반복됩니다. 온프레미스에서는 물리 스위치와 VLAN으로 이 문제를 다뤘지만, 클라우드에서는 물리 장비를 직접 만질 수 없습니다. 주소 공간을 정의하고 서브넷을 나누고 통신 경로를 소프트웨어로 설계할 수 있는 가상 네트워크가 필요해진 배경입니다.

클라우드 초기에는 VM을 만들면 플랫폼이 알아서 네트워크를 배정해 주었습니다. 규모가 작을 때는 문제가 없었지만, 리소스가 늘고 팀이 나뉘면서 운영 문제가 반복됐습니다. 이 서버는 저 서버와 통신하면 안 되는데 같은 네트워크에 있고, 개발 환경과 프로덕션이 분리되지 않으며, 온프레미스 데이터센터와 안전하게 연결할 방법도 없었습니다. 물리 네트워크에서는 스위치, 라우터, VLAN으로 이런 문제를 풀었지만 클라우드에서는 그 방식이 통하지 않습니다. 주소 공간부터 보안 경계까지 사용자가 직접 설계할 수 있는 소프트웨어 정의 네트워크가 필요했고, VNet은 그 요구에 대한 응답으로 자리를 잡았습니다.

VNet은 사용자가 지정한 CIDR 블록(예: 10.0.0.0/16)으로 주소 공간을 확보하는 데서 시작합니다. 그 안에서 서브넷(예: 10.0.1.0/24, 10.0.2.0/24)을 나눠 역할별로 리소스를 배치합니다. 같은 VNet 안의 서브넷끼리는 기본적으로 통신이 가능하지만, NSG(네트워크 보안 그룹)를 서브넷이나 NIC에 붙이면 포트와 프로토콜 단위로 허용·차단을 세밀하게 지정할 수 있습니다. 외부와의 연결은 방향에 따라 다릅니다. 인터넷에서 들어오는 트래픽은 퍼블릭 IP나 로드 밸런서를 거치고, 프라이빗 서브넷의 리소스가 밖으로 나가야 할 때는 NAT Gateway를 통합니다. 다른 VNet과는 VNet 피어링으로 Azure 사설 백본을 통해 연결하고, 온프레미스와는 VPN Gateway나 ExpressRoute로 이어 붙입니다. 결국 VNet은 주소 설계, 보안 규칙, 라우팅 경로를 하나의 단위로 묶어서 네트워크의 경계와 흐름을 제어하는 구조입니다.

VNet과 AWS VPC는 둘 다 클라우드 안에 사설 주소 공간을 만들고, 서브넷으로 나누고, 보안 규칙과 라우팅을 제어한다는 점에서 같은 문제를 다룹니다. 차이는 구현 방식의 세부에 있습니다. AWS VPC는 서브넷이 가용 영역(AZ)에 귀속되고, 보안 그룹은 상태 기반(stateful)이며, 네트워크 ACL은 서브넷 단위 무상태(stateless) 필터입니다. VNet의 서브넷은 특정 AZ에 묶이지 않고 리전 전체에 걸치며, NSG가 상태 기반 필터 역할을 서브넷과 NIC 모두에서 담당합니다. 어떤 플랫폼을 쓰느냐에 따라 선택이 결정되지만, '사설 주소 공간 정의 → 서브넷 분할 → 보안 규칙 → 라우팅 제어'라는 흐름은 동일합니다. 하나를 이해하면 다른 쪽으로 전환하는 데 드는 학습 비용이 크지 않습니다.

Azure에서 VM이나 컨테이너 워크로드를 사설 주소 공간 안에 배치해야 하는 팀이라면 VNet 설계가 출발점이 됩니다. 새 프로젝트를 시작할 때 주소 공간을 정하고 서브넷을 나누는 작업이 먼저 오는 경우가 많습니다. 웹 계층은 퍼블릭 서브넷에, 데이터 계층은 프라이빗 서브넷에 두고 NSG로 443 포트만 여는 구성이 가장 기본적인 패턴입니다. 팀이 커지면 환경별(개발/스테이징/프로덕션) 네트워크를 분리하거나 피어링으로 연결하는 구조로 확장합니다. 주소 공간을 처음에 너무 좁게 잡으면 피어링이나 VPN 연결 시 주소가 겹쳐 나중에 고치기 어렵습니다. 초기 설계 단계에서 여유 있게 잡는 것이 중요한 신호입니다. VNet 자체는 애플리케이션 로직을 처리하지 않으므로, 네트워크 토폴로지를 설계하는 도구로 보는 것이 적절합니다.