AZ-104 네트워킹 도메인(15~20%)의 공식 출제 범위에는 "공용 IP 주소 구성", "내부 또는 공용 부하 분산 장치 구성", "부하 분산 문제 해결"이 따로 적혀 있습니다. 문제은행에서도 공용 IP를 다루는 문항이 30개 가까이, Load Balancer의 SKU·상태 프로브·세션 지속성을 묻는 문항이 20개 넘게 나오고, 보기에는 Application Gateway, Front Door, Traffic Manager가 함께 등장합니다. 이름이 비슷한 네 가지 부하 분산 서비스를 기준 없이 외우면 시험장에서 쉽게 헷갈립니다.
이 글은 공용 IP 주소의 SKU와 할당 방식, 부하 분산 서비스 네 가지를 고르는 두 가지 질문, Azure Load Balancer의 구성 요소와 세션 지속성, 트래픽이 들어오지 않을 때의 문제 해결 순서, 그리고 2026년에 바뀐 VM의 인터넷 아웃바운드 기본 동작까지 다룹니다. 2025년 9월 30일에 Basic SKU 공용 IP와 Basic Load Balancer가 사용 중지되었으므로, 예전 자료의 Basic SKU 설명은 지금 기준으로 다시 읽어야 합니다.
---
공용 IP 주소: 바뀌지 않는 대표 번호 받기
회사 대표 전화번호가 매달 바뀐다면 고객도, 거래처의 방화벽 담당자도 곤란해집니다. 인터넷에서 Azure 리소스에 접근하게 하는 공용 IP 주소도 마찬가지로, 어떤 SKU와 할당 방식을 고르느냐에 따라 주소가 유지되는지와 기본 보안 동작이 달라집니다.
| 항목 | Standard | Basic (2025년 9월 30일 사용 중지) | |------|------|------| | 할당 방식 | 정적만 | IPv4는 동적 또는 정적 | | 기본 보안 | 기본적으로 인바운드 차단, NSG로 허용해야 함 | 기본적으로 열림 | | 가용성 영역 | 영역 중복, 영역별, 비영역 지원 | 지원 안 함 | | 라우팅 기본 설정 | 지원 (Microsoft 네트워크 또는 인터넷 경로) | 지원 안 함 | | 전역 계층 | 지원 (지역 간 부하 분산 장치 프런트엔드) | 지원 안 함 |
정적 할당은 만들 때 주소를 받아 공용 IP 리소스를 지울 때까지 유지하고, 동적 할당은 연결된 리소스를 중지하면 주소를 반납 가용성 영역이 있는 지역에서 영역을 지정하지 않은 Standard 공용 IP는 이제 영역 중복으로 동작 한 번 만든 공용 IP의 가용성 영역은 바꿀 수 없음 연속된 공용 IP 범위가 필요하면 공용 IP 접두사(prefix)를 만들어 그 안에서 주소를 할당 새로 나온 Standard v2 공용 IP는 현재 Standard v2 NAT Gateway에만 연결 가능
시험 팁: "거래처 방화벽에 등록할 주소가 VM을 다시 시작해도 바뀌지 않아야 한다"는 정적 할당입니다. Standard SKU는 정적만 지원하므로 Standard를 고르면 자동으로 해결됩니다. "Standard 공용 IP를 붙였는데 RDP가 안 된다"면 NSG에 인바운드 허용 규칙이 있는지부터 확인하세요.
---
부하 분산 서비스 네 가지는 두 질문으로 고른다
공항의 안내 데스크는 여러 층의 게이트로 사람을 나누고, 항공사 콜센터는 전 세계 지점으로 전화를 돌립니다. 같은 "분배"라도 범위와 다루는 정보가 다릅니다. Microsoft는 Azure의 부하 분산 서비스를 두 가지 기준으로 나눕니다. 전역인가 지역인가, 그리고 HTTP(S) 웹 트래픽인가 아닌가입니다.
!부하 분산 서비스는 범위와 트래픽 종류 두 질문으로 고른다
| 서비스 | 계층 | 범위 | 핵심 기능 | 문제 속 단서 | |------|------|------|------|------| | Azure Load Balancer | 4계층 (TCP·UDP) | 지역 (지역 간 계층도 있음) | 고성능·초저지연, 내부·공용 프런트엔드, 아웃바운드 규칙 | "TCP 포트", "UDP", "내부 부하 분산", "모든 포트(HA 포트)" | | Application Gateway | 7계층 (HTTP·HTTPS 중심) | 지역 | URL 경로 기반 라우팅, TLS 종료, WAF, 쿠키 기반 세션 선호도 | "/images는 풀 A로", "웹 애플리케이션 방화벽", "SSL 오프로드" | | Azure Front Door | 7계층 (HTTP·HTTPS) | 전역 | 전 세계 엣지, 캐싱(CDN), 빠른 장애 조치, WAF | "전 세계 사용자", "가장 가까운 엣지", "정적 콘텐츠 캐싱" | | Traffic Manager | DNS 기반 | 전역 | DNS 응답으로 지역 엔드포인트 선택, 우선순위·성능·지리적 라우팅 | "DNS 수준", "HTTP가 아닌 서비스의 지역 간 장애 조치" |
Traffic Manager는 DNS 단계에서만 방향을 정하기 때문에 클라이언트의 DNS 캐시가 만료되어야 다른 지역으로 넘어갑니다. 그래서 웹 애플리케이션의 빠른 지역 간 장애 조치에는 Front Door가 더 알맞습니다.
시험 팁: AZ-104 출제 범위에 이름이 직접 나오는 것은 Load Balancer뿐이지만, 보기에는 나머지 셋이 오답으로 자주 섞입니다. "URL 경로", "WAF", "쿠키 기반 선호도"가 보이면 7계층 서비스이고, "TCP/UDP", "내부 IP로 분산"이 보이면 Load Balancer입니다.
---
Azure Load Balancer 구성 요소 다시 보기
Load Balancer는 들어오는 연결을 받아 규칙에 따라 백엔드 VM에 나눠 주는 교통 정리원입니다. 공용 Load Balancer는 공용 IP로 인터넷 트래픽을 받고, 내부 Load Balancer는 VNet의 사설 IP로 내부 트래픽을 받습니다.
| 구성 요소 | 역할 | 기억할 점 | |------|------|------| | 프런트엔드 IP 구성 | 클라이언트가 접속하는 주소 | 공용 LB는 Standard 공용 IP 필요 | | 백엔드 풀 | 트래픽을 받을 VM·확장 집합 인스턴스 | NIC 기반 또는 IP 기반으로 구성 | | 상태 프로브 | 백엔드가 정상인지 주기적으로 확인 | TCP, HTTP, HTTPS, 원본 IP는 168.63.129.16 | | 부하 분산 규칙 | 프런트엔드 포트를 백엔드 포트로 분산 | 상태 프로브가 반드시 필요 | | 인바운드 NAT 규칙 | 특정 포트를 특정 VM으로 전달 | 예: 프런트엔드 50001 → VM1의 3389, 상태 프로브 불필요 | | 아웃바운드 규칙 | 백엔드 VM의 인터넷 아웃바운드 SNAT 구성 | 공용 Standard LB에서 사용 |
Standard Load Balancer는 "기본적으로 안전"한 모델입니다. 백엔드 서브넷이나 NIC의 NSG가 허용하지 않으면 인바운드 트래픽이 들어오지 않습니다. 내부 Standard Load Balancer에서 프로토콜을 All, 포트를 0으로 둔 HA 포트 규칙을 만들면 모든 포트의 TCP·UDP 흐름을 한 번에 분산할 수 있어, 방화벽 같은 네트워크 가상 어플라이언스(NVA) 앞에 자주 씁니다.
세션 지속성: 같은 사용자를 같은 VM으로
| 설정 | 해시 기준 | 동작 | |------|------|------| | 없음 (기본값) | 5-튜플 (원본 IP, 원본 포트, 대상 IP, 대상 포트, 프로토콜) | 같은 클라이언트라도 연결마다 다른 VM으로 갈 수 있음 | | 클라이언트 IP | 2-튜플 (원본 IP, 대상 IP) | 같은 클라이언트 IP는 같은 VM으로 | | 클라이언트 IP 및 프로토콜 | 3-튜플 (원본 IP, 대상 IP, 프로토콜) | 같은 클라이언트 IP와 프로토콜 조합은 같은 VM으로 |
시험 팁: "사용자의 세션 데이터가 VM 메모리에 있어 같은 사용자는 계속 같은 VM에 연결되어야 한다"는 세션 지속성을 클라이언트 IP로 바꾸는 것이 정답입니다. 쿠키 기반 선호도는 Load Balancer가 아니라 Application Gateway의 기능입니다.
---
트래픽이 백엔드에 닿지 않을 때
부하 분산 문제는 대부분 "상태 프로브가 실패한다"와 "프로브는 정상인데 데이터가 안 간다" 두 갈래로 나뉩니다. 증상에 따라 확인할 곳을 정리하면 다음과 같습니다.
| 증상 | 흔한 원인 | 확인할 것 | |------|------|------| | 백엔드 VM이 상태 프로브에 응답하지 않음 | 앱이 프로브 포트를 수신하지 않음, VM이 중지됨 | VM 안에서 프로브 포트 수신 여부, VM 상태 | | 상태 프로브가 막힘 | NSG나 VM 방화벽이 168.63.129.16 또는 AzureLoadBalancer 서비스 태그를 차단 | 기본 규칙 AllowAzureLoadBalancerInBound보다 앞선 거부 규칙 | | 프로브는 정상인데 서비스 포트 응답 없음 | 앱이 데이터 포트를 수신하지 않음, NSG가 데이터 포트를 차단 | 부하 분산 규칙의 백엔드 포트, NSG 인바운드 규칙 | | 백엔드 VM에서 내부 LB 프런트엔드로 보낸 요청이 실패 | 백엔드 VM에서 같은 내부 LB 프런트엔드로 나가는 흐름은 지원되지 않음 | 다른 VM에서 테스트하거나 구조 변경 | | Standard로 바꾼 뒤 인바운드가 끊김 | Standard는 기본적으로 인바운드 차단 | 백엔드 서브넷·NIC에 허용 NSG 규칙 추가 |
상태를 숫자로 보려면 Load Balancer 메트릭의 "데이터 경로 가용성"(프런트엔드까지의 경로)과 "상태 프로브 상태"(백엔드 인스턴스별 프로브 결과)를 함께 봅니다. 데이터 경로는 정상인데 프로브 상태만 0이라면 문제는 백엔드 VM 쪽입니다.
시험 팁: "상태 프로브를 HTTP /health로 바꿨더니 모든 VM이 비정상"이라면 앱에 /health 경로가 없거나 200을 돌려주지 않는 경우입니다. HTTP 프로브는 200 응답만 정상으로 봅니다.
---
VM의 인터넷 아웃바운드: 이제는 명시적으로 고른다
지금까지는 공용 IP가 없는 VM도 Azure가 몰래 붙여 주는 "기본 아웃바운드 액세스" 주소로 인터넷에 나갈 수 있었습니다. 하지만 이 주소는 Microsoft 소유라 예고 없이 바뀔 수 있고, 거래처 방화벽에 등록할 수도 없습니다. 그래서 Azure는 기본 동작을 바꾸고 있습니다.
2026년 3월 31일 이후 릴리스된 API로 만든 새 가상 네트워크는 서브넷이 기본으로 프라이빗 서브넷(defaultOutboundAccess = false) Azure 포털은 이미 프라이빗 서브넷을 기본값으로 사용 기존 가상 네트워크와 그 안의 VM은 바뀌지 않음 프라이빗 서브넷의 VM은 아래의 명시적 방법이 있어야 인터넷과 Microsoft 공용 엔드포인트에 접근 가능
| 명시적 아웃바운드 방법 | 특징 | |------|------| | NAT Gateway | 서브넷 단위로 연결, 고정 공용 IP로 나감, 연결하면 새 아웃바운드 연결은 모두 NAT Gateway 사용 | | VM에 직접 연결한 공용 IP | VM 한 대의 인바운드·아웃바운드에 같은 주소 사용 | | Load Balancer 아웃바운드 규칙 | 공용 Standard LB의 백엔드 풀이 프런트엔드 IP로 나감 | | UDR로 방화벽·NVA 경유 | Azure Firewall 같은 장비의 공용 IP로 나가며 검사 가능 |
시험 팁: "공용 IP가 없는 여러 VM이 고정된 공용 IP로 인터넷에 나가야 하고, 인바운드 연결은 허용하지 않는다"는 NAT Gateway입니다. 인바운드까지 필요하면 VM 공용 IP나 공용 Load Balancer가 필요합니다.
---
시험 핵심 정리
시험장 가기 전 마지막으로 확인할 핵심 포인트입니다.
| 구분 | 핵심 암기 사항 | |------|------| | Basic SKU | 공용 IP와 Load Balancer 모두 2025년 9월 30일 사용 중지 | | Standard 공용 IP | 정적만, 기본적으로 인바운드 차단(NSG로 허용), 영역 중복 지원 | | 정적 vs 동적 | 공용 IP를 삭제할 때까지 유지 vs 연결된 리소스를 중지하면 반납 | | 공용 IP 접두사 | 연속된 공용 IP 범위, 확장 집합에 유용 | | Load Balancer | 4계층 TCP·UDP, 지역, 내부·공용 프런트엔드 | | Application Gateway | 7계층, 지역, URL 경로 라우팅·WAF·TLS 종료·쿠키 선호도 | | Front Door | 7계층, 전역, 엣지 캐싱·빠른 장애 조치 | | Traffic Manager | DNS 기반, 전역, DNS 캐시 때문에 장애 조치가 상대적으로 느림 | | 세션 지속성 | 없음(5-튜플) · 클라이언트 IP(2-튜플) · 클라이언트 IP 및 프로토콜(3-튜플) | | 상태 프로브 | 원본 168.63.129.16, NSG에서 AzureLoadBalancer 허용, HTTP는 200만 정상 | | 내부 LB 제약 | 백엔드 VM에서 같은 내부 LB 프런트엔드로 나가는 흐름은 실패 | | 아웃바운드 | 새 VNet은 프라이빗 서브넷 기본, NAT Gateway가 권장 명시적 방법 |
---
다음 단계
부하 분산 장치까지 정리했다면, 트래픽이 아예 VM에 닿지 않을 때 NSG와 경로를 추적하는 방법을 AZ-104 VM 접속이 안 될 때: 네트워크 문제 해결에서 이어서 익히세요. VNet, NSG, DNS의 기본 개념은 초보자도 이해하는 VNet, NSG, DNS, Load Balancer에 있습니다.
부하 분산 문제는 "전역인가, 웹인가" 두 질문으로 보기의 절반이 정리됩니다. AZ-104 모의고사에서 네트워킹 문제를 풀며 이 기준으로 보기를 걸러 보세요.