Azure에 NGINX 서버 구축 실무 함정 완벽 해부

Azure NGINX 서버 구축, 실무자가 겪는 4가지 예상 밖의 함정

Azure에서 가상 머신(VM)을 만들고 NGINX 웹 서버를 설치하는 과정은 간단해 보입니다.

몇 번의 클릭과 명령어 몇 줄이면 끝날 것 같죠. 하지만 많은 실무자들이 벽에 부딪히며,

"분명히 가이드대로 다 설정했는데 왜 브라우저에서 접속이 안 되지?"라는 막막한 문제를 해결하느라

몇 시간, 심지어 며칠을 허비하곤 합니다.

이것은 단순한 실수가 아니라, 성공적인 구축과 실패를 가르는 결정적인 지식의 격차입니다.

이 글은 단순히 NGINX 설치 과정을 나열하지 않습니다.

대신, 실제 클라우드 운영 환경(MSP 운영 실무 기준)에서 빈번하게 발생하는 예상치 못한 문제와 그 근본적인 원인을 파헤칩니다. 이것은 단순한 이론이 아닙니다.

다운타임은 용납되지 않고 예측 가능성이 무엇보다 중요한, 수백 개의 고객사 환경을 관리하며 얻은 값비싼 교훈의 집합입니다.

방화벽이 사실 두 개였다는 점, Public IP가 만능이 아니라는 사실 등,

당신이 놓치고 있을지 모를 결정적인 함정들을 지금부터 알아보겠습니다.

1. 첫 번째 함정: 방화벽이 두 개라고? NSG와 UFW의 이중 잠금

가장 흔한 실수의 원인은 Azure의 방화벽 구조를 단편적으로 이해하는 데 있습니다.

Azure에는 두 종류의 방화벽이 존재하며, 이들은 서로 다른 계층에서 작동합니다.

• 네트워크 보안 그룹 (NSG): Azure 포털에서 설정하는 클라우드 계층 방화벽입니다. VM으로 들어오는 모든 트래픽을 가장 먼저 검사하는 외부 경비원과 같습니다.
• UFW (Uncomplicated Firewall): Ubuntu VM 내부에 기본적으로 설치된 OS 내부 방화벽입니다. 외부 경비원을 통과한 트래픽을 최종적으로 검문하는 내부 경비원 역할을 합니다.

문제는 이 두 방화벽이 독립적으로 작동한다는 점입니다.

예를 들어, NSG에서 80번(HTTP), 443번(HTTPS) 포트를 허용했더라도,

VM 내부의 UFW에서 해당 포트가 닫혀 있다면 외부 트래픽은 최종적으로 차단됩니다.

제 실무 경험상, 운영 환경에서 발생하는 접속 실패의 8할 이상은 바로 이 '이중 잠금' 상태가 원인입니다.

Azure NSG는 클라우드 계층 방화벽 UFW는 OS 내부 방화벽 둘 중 하나라도 닫혀 있으면 접속 불가

 

2. 두 번째 함정: 공인 IP만 있으면 끝? 진짜 관문은 NSG

외부 접속을 위해 VM에 Public IP(공인 IP)를 할당하면

인터넷의 모든 트래픽이 VM으로 바로 전달될 것이라고 생각하기 쉽습니다.

하지만 이는 Azure의 네트워크 동작 방식에 대한 큰 오해입니다.

Azure에서 Public IP는 단순히 VM을 찾아올 수 있는 '주소'일 뿐, 트래픽을 통과시켜주는 '허가증'이 아닙니다.

실제 문지기 역할은 바로 네트워크 보안 그룹(NSG)이 담당합니다.

NSG는 기본적으로 '모든 것 거부(Deny All)' 정책을 따르며,

명시적으로 허용한 포트를 제외한 모든 트래픽을 차단합니다.

따라서 NGINX 서버를 운영하려면 SSH(22번), HTTP(80번), HTTPS(443번) 포트를

NSG의 인바운드 규칙에 명시적으로 추가해야만 합니다.

이 규칙을 설정하지 않으면 Public IP가 있어도 NGINX는 외부에서 절대 접속할 수 없는 '유령 서버'가 됩니다.

Azure에서는 Public IP만 있다고 해서 트래픽이 VM에 바로 도달하지 않음

 

3. 세 번째 함정: 숨겨진 규칙 충돌, Subnet과 NIC의 NSG

1번 함정에서 보았던 NSG와 UFW의 관계처럼,

Azure 네트워크 보안에는 종종 간과되는 또 다른 복잡성의 계층이 존재합니다.

바로 Subnet과 개별 머신의 네트워크 카드(NIC)에 적용되는 규칙입니다.

NSG 규칙을 분명히 올바르게 설정했는데도 접속이 안 되는, 더 까다로운 상황이 있습니다.

Azure에서는 NSG를 Subnet 전체에 적용할 수도 있고, 개별 VM의 NIC에 적용할 수도 있습니다.

만약 Subnet과 NIC에 각각 다른 NSG가 연결되어 있다면, 트래픽은 두 개의 필터를 모두 통과해야 합니다.

이것을 빌딩 보안에 비유해 봅시다. Subnet NSG는 빌딩 정문의 보안 요원처럼 건물에 들어오는 모든 사람을 검사합니다.

NIC NSG는 특정 층의 안내 데스크 직원처럼, 그 층의 사무실에 들어가기 전에 방문객을 다시 한번 확인합니다.

목적지에 도달하려면 두 곳 모두의 허가를 받아야 합니다.

제가 원인을 알 수 없는 포트 접속 불가 문의를 받으면 가장 먼저 확인하는 곳이

바로 이 "Subnet NSG vs NIC NSG 충돌" 여부입니다.

문제가 발생하면 VM의 'Networking' 메뉴에서 Subnet과 NIC에 어떤 NSG가 연결되어 있는지

반드시 확인하여 규칙 충돌이 없는지 점검해야 합니다.

 

4. 네 번째 함정: 무심코 넘긴 IP 주소와 네트워크 설계의 비밀

VM을 생성할 때 VNet(가상 네트워크)과 Subnet의 IP 주소 범위를 기본값으로 두고 넘어가는 경우가 많습니다.

하지만 이 숫자들에는 향후 인프라의 확장성과 관리 효율을 결정하는 중요한 설계 의도가 담겨 있습니다.

여기서 진짜 함정은 단기적인 편의를 위해 기본값을 수락했다가 장기적인 구조적 경직성을 초래하는 것입니다.

지금의 안일한 선택이 미래에 비용과 시간이 많이 드는 복잡한 네트워크 마이그레이션 프로젝트로 이어질 수 있습니다.

예를 들어, VNet을 10.0.0.0/16으로, Subnet을 10.0.1.0/24로 설정하는 데에는 이유가 있습니다.

• VNet: 10.0.0.0/16: /16은 약 65,000개의 IP 주소를 포함하는 넓은 대역입니다. 이렇게 넓게 잡는 이유는 당장은 아니더라도 추후에 다양한 목적의 Subnet(DB용, WAS용 등)을 자유롭게 추가할 수 있는 확장성을 확보하기 위함입니다.

• Subnet: 10.0.1.0/24: /24는 약 250개의 IP를 할당할 수 있는 크기로, 수백 대의 VM을 관리하기에 적절한 규모입니다. 너무 크지도, 작지도 않은 단위로 네트워크를 분리하여 관리 효율을 높입니다.

또한, Public IP를 설정할 때는 'Static(고정)' 할당을 사용하는 것이 좋습니다.

기본값인 'Dynamic(동적)'을 사용하면 VM을 재부팅할 때마다 IP 주소가 변경될 수 있어,

DNS 설정이나 외부 연동에 심각한 문제를 일으킬 수 있습니다.

 

결론: 보이는 서비스와 보이지 않는 규칙

이 글에서 다룬 4가지 함정은 결국 하나의 중요한 교훈을 가리킵니다.

"클라우드 인프라는 눈에 보이는 서비스(VM, NGINX)와

보이지 않는 규칙(네트워크, 보안)의 정교한 조합으로 이루어져 있다"는 것입니다.

우리가 살펴본 네 가지 함정은 이 원칙의 완벽한 증거입니다.

보이지 않는 '이중 방화벽 잠금(NSG/UFW)',

Public IP 위에 군림하는 'NSG의 숨은 권한',

'Subnet과 NIC 간의 미묘한 규칙 충돌',

그리고 IP 주소 계획 뒤에 감춰진 '전략적 중요성'까지.

이 모든 보이지 않는 규칙들이 당신의 NGINX 서버라는 보이는 서비스의 성공을 좌우합니다.

단순히 서비스를 설치하고 실행하는 것을 넘어,

그 서비스가 동작하는 기반이 되는 네트워크 흐름과 보안 정책을 이해할 때 비로소 안정적인 인프라를 구축할 수 있습니다.

당신의 다음 프로젝트에서는 어떤 '보이지 않는 규칙'을 가장 먼저 점검하시겠습니까?