- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Microsoft Defender Application Guard에서 격리 브라우저 창이 열리지 않거나 즉시 종료되는 문제를 원인별로 진단하고, 운영체제 버전 제한과 가상화 요구사항까지 포함해 현장에서 바로 적용 가능한 복구 절차를 정리하는 것이다.
1. 증상부터 분류해야 하는 이유
Application Guard의 “브라우저 열림 실패”는 한 가지 오류가 아니라 운영체제 버전 제한, 기능 미설치, 가상화 미충족, 정책 충돌, 네트워크 격리 설정 오류가 같은 형태로 보이는 현상이다.
따라서 화면에 보이는 증상만 보고 재설치를 반복하면 시간이 낭비되는 구조이다.
2. 가장 먼저 확인할 항목은 Windows 11 24H2 여부이다
Windows 11 24H2부터는 Microsoft Defender Application Guard가 더 이상 제공되지 않는 구조이다.
이 상태에서는 기능을 켜려 해도 항목이 보이지 않거나 실행 트리거가 동작하지 않는 형태가 정상이다.
2-1. Windows 버전과 빌드 확인 절차이다
가장 빠른 확인은 winver 확인 방식이다.
winver 자동화 확인은 PowerShell 확인 방식이다.
# PowerShell(관리자)에서 실행하는 방식이다 (Get-ComputerInfo).WindowsProductName (Get-ComputerInfo).WindowsVersion (Get-ComputerInfo).OsBuildNumber Windows 11 24H2라면 아래 “대체 방안”으로 전환하는 것이 합리적인 접근이다.
3. 지원 에디션과 동작 모드를 먼저 정리하는 방식이다
Application Guard는 운영체제 에디션과 모드에 따라 지원 범위가 달라지는 구조이다.
특히 Windows Pro에서는 단독 모드만 지원하는 구성이 일반적이다.
| 구분 | 지원 범위 | 현장에서 자주 발생하는 오해 | 정리 포인트 |
|---|---|---|---|
| Windows 10 Pro | 단독 모드 중심 구성이다 | 엔터프라이즈 정책 기능까지 기대하는 오해가 흔하다 | 정책 기반 자동 리디렉션은 기대하지 않는 것이 안전하다 |
| Windows 10 Enterprise/Education | 단독 모드 및 관리형 모드 구성이 가능하다 | 가상화 요구사항을 간과하는 오해가 흔하다 | 하드웨어 가상화 충족이 최우선 전제이다 |
| Windows 11 Pro | 단독 모드 중심 구성이다 | 설치만 하면 바로 열릴 것이라는 오해가 흔하다 | SLAT, VT-x/AMD-V, 메모리 요구사항을 확인해야 한다 |
| Windows 11 Enterprise/Education | 단독 모드 및 관리형 모드 구성이 가능하다 | 정책 충돌을 기능 장애로 오해하는 경우가 흔하다 | GPO/Intune 설정을 함께 점검해야 한다 |
| Windows 11 24H2 | 기능 미제공 상태이다 | 재설치로 해결 가능하다고 오해하기 쉽다 | 대체 보안 설계로 전환해야 한다 |
4. “열리지 않음”의 핵심 원인은 가상화 요구사항 미충족인 경우가 많다
Application Guard는 하이퍼바이저 기반 격리 컨테이너를 사용하는 구조이다.
따라서 CPU 가상화, SLAT, 메모리, 디스크 여유가 충족되지 않으면 창이 뜨지 않거나 생성 중 종료되는 현상이 발생하는 형태이다.
4-1. 하드웨어 요구사항 점검 체크리스트이다
현장 기준으로는 아래 조건을 먼저 확인하는 방식이 효율적이다.
| 점검 항목 | 기준 | 확인 방법 | 미충족 시 대표 증상 |
|---|---|---|---|
| CPU 64비트 및 코어 | 최소 4 논리 프로세서 권장 구조이다 | 작업 관리자 또는 PowerShell 확인 방식이다 | 창 생성 실패 또는 즉시 종료 형태이다 |
| SLAT | 필수 전제이다 | systeminfo 출력 확인 방식이다 | 기능은 켜지나 실행이 안 되는 형태이다 |
| VT-x 또는 AMD-V | 필수 전제이다 | BIOS/UEFI 설정 확인 방식이다 | 가상화 기반 기능이 전반적으로 실패하는 형태이다 |
| RAM | 최소 8GB 권장 구조이다 | 시스템 정보 확인 방식이다 | 컨테이너 생성 중 멈춤 형태이다 |
| 디스크 여유 | 최소 5GB 여유 권장 구조이다 | 드라이브 여유 확인 방식이다 | 생성 단계에서 실패하는 형태이다 |
4-2. systeminfo로 가상화 상태를 확인하는 방식이다
systeminfo 출력 하단의 Hyper-V 요구사항 항목이 “예”로 충족되는 형태여야 정상이다.
5. Windows 기능이 ‘켜짐’이 아니면 창이 열리지 않는 구조이다
Application Guard는 Windows 기능 구성 요소가 실제로 설치되어 있어야 동작하는 구조이다.
제어판에서 체크 표시만 보이고 내부 구성 요소가 손상된 상태라면 실행이 실패하는 형태가 나타나기 쉽다.
5-1. Windows 기능 설치 상태를 PowerShell로 확인하는 방식이다
# PowerShell(관리자)에서 실행하는 방식이다 Get-WindowsOptionalFeature -Online -FeatureName Windows-Defender-ApplicationGuard 5-2. 기능을 재설치하는 표준 절차이다
가장 재현성이 좋은 절차는 “비활성화 → 재부팅 → 활성화 → 재부팅” 순서로 수행하는 방식이다.
# 1) 기능 비활성화 방식이다 Disable-WindowsOptionalFeature -Online -FeatureName Windows-Defender-ApplicationGuard -NoRestart
2) 재부팅 수행 방식이다
재부팅 후 아래 활성화 명령을 수행하는 방식이다
3) 기능 활성화 방식이다
Enable-WindowsOptionalFeature -Online -FeatureName Windows-Defender-ApplicationGuard -All -NoRestart
마지막으로 재부팅을 수행해야 구성 요소 등록이 완료되는 구조이다.
6. BIOS 가상화가 꺼져 있으면 설치는 되나 실행은 실패하는 형태이다
장치 관리자나 Windows 기능에서 체크가 되어 있어도 BIOS에서 VT-x 또는 AMD-V가 꺼져 있으면 컨테이너가 생성되지 않는 구조이다.
이 경우 “클릭하면 아무 반응이 없음” 또는 “잠깐 뜨고 사라짐” 형태가 흔하다.
BIOS에서 Intel Virtualization Technology 또는 SVM Mode를 활성화하는 것이 핵심이다.
7. Hyper-V 계열과 서드파티 가상화 소프트웨어 충돌을 점검하는 방식이다
Application Guard는 하이퍼바이저 계층을 사용하므로, VMware Workstation이나 VirtualBox 같은 다른 가상화 솔루션과 충돌하거나 성능 저하를 유발하는 구조이다.
충돌 상황에서는 Application Guard 컨테이너가 시작되지 않는 형태가 발생할 수 있다.
7-1. 현재 하이퍼바이저 동작 여부를 확인하는 방식이다
# PowerShell에서 확인하는 방식이다 bcdedit /enum {current} | findstr -i hypervisorlaunchtype hypervisorlaunchtype가 Auto라면 하이퍼바이저가 활성화되는 구조이다.
8. 네트워크가 막혀 “열렸으나 로딩이 안 됨”으로 오인하는 경우도 흔하다
창 자체는 열리지만 내부 페이지가 로딩되지 않아 사용자가 “안 열린다”로 표현하는 경우가 흔하다.
프록시, SSL 가시화 장비, 인증 프록시, 방화벽 정책이 컨테이너 트래픽을 차단하면 이런 형태가 나타나다.
8-1. 네트워크 증상을 구분하는 체크 방식이다
창이 열렸다면 우선 주소창 입력이 가능한지 확인하는 방식이다.
주소창 입력이 가능하나 어떤 사이트도 로딩이 안 된다면 네트워크 격리 설정 또는 프록시 이슈 가능성이 높아지는 구조이다.
8-2. 프록시 자동 구성 스크립트 영향도 점검 방식이다
환경에 PAC 스크립트나 강제 프록시가 있다면 컨테이너에서 동일 적용 여부가 문제 포인트가 되기 쉽다.
진단 단계에서는 일시적으로 프록시를 우회하는 테스트를 수행하는 방식이 일반적이다.
9. 로그 기반으로 원인을 좁히는 방법이 가장 빠르다
Application Guard는 내부적으로 컨테이너 생성, 네트워크 가상화, 브라우저 프로세스 실행 단계를 거치는 구조이다.
따라서 이벤트 로그에서 “컨테이너 생성 실패”인지 “정책 차단”인지 구분하는 것이 핵심이다.
9-1. 기본 이벤트 뷰어 진입 방식이다
eventvwr.msc 이후 응용 프로그램 및 서비스 로그에서 Microsoft 관련 로그를 중심으로 오류 시점을 확인하는 방식이다.
오류가 발생한 시각에 “가상화”, “컨테이너”, “격리” 키워드로 필터링하는 방식이 실무적이다.
10. 원인-해결을 한 번에 매칭하는 현장용 표이다
| 사용자 표현 | 실제 상태 | 우선 의심 원인 | 우선 조치 |
|---|---|---|---|
| 버튼 눌러도 아무 반응이 없다 | 기능이 호출되나 컨테이너가 생성되지 않는 상태이다 | Windows 11 24H2 또는 기능 미설치 가능성이 높다 | OS 버전 확인 후 기능 설치 상태를 재점검한다 |
| 잠깐 뜨고 바로 닫힌다 | 초기화 단계에서 종료되는 상태이다 | BIOS 가상화 비활성 또는 SLAT 미충족 가능성이 높다 | systeminfo로 Hyper-V 요구사항을 확인한다 |
| 흰 화면만 보이고 사이트가 안 열린다 | 창은 열렸으나 네트워크가 막힌 상태이다 | 프록시/방화벽/인증 네트워크 이슈 가능성이 높다 | 프록시 구성과 격리 네트워크 정책을 점검한다 |
| 회사 정책 적용 후부터 안 된다 | 정책 기반 차단이 발생한 상태이다 | GPO/Intune 설정 충돌 가능성이 높다 | 정책을 최소화한 테스트 OU로 분리 적용한다 |
| 재설치해도 계속 동일하다 | 전제 조건 미충족 또는 기능 미제공 상태이다 | Windows 11 24H2 또는 하드웨어 요건 미충족 가능성이 높다 | 버전과 요건을 먼저 확정하고 대체 설계를 검토한다 |
11. “정상 환경”으로 되돌리는 표준 복구 시나리오이다
현장에서 가장 성공률이 높은 시나리오는 아래 순서로 정리하는 방식이다.
11-1. 1단계: Windows 버전과 지원 여부를 확정하는 방식이다
Windows 11 24H2라면 기능 복구가 아니라 대체 기능으로 전환하는 것이 정답이다.
11-2. 2단계: 요구사항을 충족시키는 방식이다
BIOS 가상화와 SLAT 충족이 확인되어야 다음 단계가 의미가 있다.
11-3. 3단계: 기능을 비활성화 후 재활성화하는 방식이다
기능 손상 가능성이 있으면 “비활성화→재부팅→활성화→재부팅” 방식이 표준이다.
11-4. 4단계: 정책과 네트워크를 최소 구성으로 시험하는 방식이다
관리형 모드에서는 신뢰 도메인 목록, 프록시, 인증 흐름이 맞지 않으면 차단되는 구조이다.
따라서 최소 정책으로 창이 열리는지 확인한 뒤 정책을 단계적으로 추가하는 방식이 안전하다.
12. Windows 11 24H2 환경에서의 대체 방안이다
Windows 11 24H2에서는 Application Guard 자체가 제공되지 않는 구조이므로, “격리 브라우징” 요구사항을 다른 통제로 충족해야 한다.
대표적인 접근은 브라우저 보안 강화, 공격 표면 감소 규칙, 응용 프로그램 제어를 조합하는 방식이다.
12-1. 브라우저 보안 강화 중심 전환 방식이다
업무 표준 브라우저를 Microsoft Edge로 통일하고 보안 강화 정책을 적용하는 방식이 일반적이다.
다운로드 제어, SmartScreen, 네트워크 보호 같은 통제를 함께 설계하는 방식이 실무적이다.
12-2. 문서 기반 격리 요구는 Protected View와 정책 조합으로 대응하는 방식이다
Office 파일 격리 요구는 Protected View와 공격 표면 감소 정책을 결합하는 방식이 일반적이다.
FAQ
Application Guard 메뉴가 Windows 기능 목록에 보이지 않는 이유는 무엇인가?
Windows 11 24H2에서는 기능이 제공되지 않는 구조일 수 있다.
또는 Windows Home 에디션처럼 애초에 지원되지 않는 에디션일 수 있다.
기능은 켰는데 “창이 잠깐 떴다가 사라지는” 형태는 무엇을 의미하는가?
컨테이너 생성 단계에서 실패하는 형태를 의미하는 경우가 많다.
BIOS 가상화 비활성, SLAT 미충족, 메모리 부족, 디스크 여유 부족을 우선 점검하는 것이 정석이다.
회사 프록시 환경에서 창은 열리는데 인터넷이 안 되는 형태는 어떻게 접근하는가?
컨테이너 네트워크가 프록시 인증을 통과하지 못하는 형태일 가능성이 높다.
진단 단계에서는 프록시 우회 테스트로 네트워크 원인인지 확정하고, 이후 정책 설계를 조정하는 방식이 효율적이다.
재설치만 반복해도 해결이 안 되는 경우의 핵심 체크 포인트는 무엇인가?
Windows 11 24H2 여부 확정이 최우선이다.
그 다음은 systeminfo 기반 Hyper-V 요구사항 충족 여부 확정이 핵심이다.