이 글의 목적은 AppLocker를 사용하는 환경에서 UWP(스토어) 앱이 의도치 않게 차단되는 문제를 해결하기 위해, Packaged app 규칙을 올바르게 구성하여 필요한 UWP 앱만 허용하고 정책 운영 안정성을 높이는 방법을 실무 기준으로 정리하는 것이다.
1. AppLocker에서 UWP가 막히는 전형적인 원인
AppLocker는 실행 파일 규칙(Executable)만으로 제어가 끝나지 않으며 UWP 앱은 “Packaged app” 범주로 별도 제어가 적용되는 구조이다.
따라서 조직에서 AppLocker를 “강제(Enforced)”로 전환한 뒤 Packaged app 규칙을 만들지 않았거나 기본 규칙을 생성하지 않았을 때, 계산기·사진·설정 같은 기본 UWP 앱까지 함께 차단되는 상황이 발생하기 쉽다.
또한 감사(Audit only)에서 강제로 전환하는 과정에서 이벤트 로그 확인 없이 정책을 배포하면, 현장에서는 “갑자기 스토어 앱이 전부 안 열림”으로 인지되는 장애로 이어지기 쉽다.
주의 : AppLocker는 Windows 에디션·서비스 상태·정책 적용 순서에 따라 결과가 달라질 수 있으므로, “감사(Audit only) → 로그 검증 → 강제(Enforced)” 순서로 전환하는 운영이 안전하다.
2. 적용 전 필수 점검 사항
2.1 지원 에디션 및 역할 확인
AppLocker는 모든 Windows 에디션에서 동일하게 제공되는 기능이 아니며, 통상 Enterprise/Education 및 Windows Server 계열에서 정책 운영이 전제된다.
대상 PC가 AppLocker 정책을 온전히 적용할 수 있는 에디션인지 먼저 확인해야 한다.
2.2 Application Identity(AppIDSvc) 서비스 상태 확인
AppLocker는 “Application Identity” 서비스가 동작해야 정책이 정상적으로 집행되는 구조이다.
해당 서비스가 중지되어 있으면 규칙을 만들어도 실제 차단·허용이 기대와 다르게 나타날 수 있다.
운영 환경에서는 서비스 시작 유형을 자동으로 유지하고, 정책 적용 시점에 서비스가 실행 중인지 점검하는 절차가 필요하다.
2.3 로컬 정책 vs 도메인 GPO 우선순위 확인
로컬 보안 정책(secpol.msc)에서 만든 AppLocker 규칙과 도메인 GPO 규칙이 동시에 존재할 수 있다.
현장에서는 도메인 GPO가 우선 적용되는 경우가 많으므로, 실제 정책 원본이 어디인지부터 명확히 해야 한다.
| 점검 항목 | 확인 방법 | 정상 기준 | 문제 시 영향 |
|---|---|---|---|
| Windows 에디션 | 설정 → 시스템 → 정보 | AppLocker 운영 가능한 에디션 | 정책이 일부/전부 미적용될 수 있다. |
| Application Identity 서비스 | services.msc → Application Identity | 실행 중, 시작 유형 자동 권장 | 규칙이 의도대로 집행되지 않을 수 있다. |
| 정책 출처(GPO/로컬) | gpresult /h 결과 확인 | 정책 적용 경로가 단일·명확 | 현장 수정이 반영되지 않을 수 있다. |
| 적용 모드 | AppLocker 속성에서 Enforcement 확인 | 초기 감사, 검증 후 강제 | 업무 중단 수준의 대량 차단이 발생할 수 있다. |
3. 핵심 개념: UWP는 “Packaged app” 규칙으로 허용해야 한다
UWP(스토어) 앱은 일반 exe처럼 경로(Path) 규칙이나 해시(Hash) 규칙으로 관리하는 방식이 맞지 않는 경우가 많다.
실무에서는 Packaged app 규칙에서 “게시자(Publisher)” 기반으로 허용 범위를 정하는 방식이 가장 유지보수에 유리하다.
게시자 규칙은 앱 업데이트로 파일이 바뀌어도 서명자·패키지 정보 기준으로 계속 허용되는 장점이 있다.
3.1 Packaged app 규칙에서 선택 가능한 조건
Packaged app 규칙은 앱의 패키지 서명 정보와 패키지명, 버전 범위를 기준으로 제어하는 형태이다.
| 조건 유형 | 설명 | 장점 | 주의점 |
|---|---|---|---|
| Publisher(게시자) | 서명자·패키지명·버전 범위 기반 허용 | 업데이트에 강하고 운영이 쉽다. | 범위를 넓히면 과허용이 될 수 있다. |
| Package name(패키지명) | 특정 패키지만 정확히 지정 | 통제가 매우 정밀하다. | 패키지 변경/대체 시 유지보수 부담이 있다. |
| All packaged apps | 모든 UWP 앱 허용/차단 | 구성이 단순하다. | 보안 요구 수준이 높으면 부적합하다. |
주의 : “All packaged apps 허용”은 문제 해결은 빠르지만, 스토어 기반 앱 통제가 사실상 해제되는 결과가 될 수 있으므로 보안 요구사항이 있는 조직에서는 권장되지 않다.
4. 실무 표준 절차: 감사(Audit)로 로그 확인 후 UWP 허용 규칙을 만든다
4.1 정책 모드를 감사(Audit only)로 두고 차단 이벤트를 먼저 수집한다
운영 중인 PC에서 갑자기 강제로 전환하면 생산성 장애가 크게 발생할 수 있으므로, 먼저 감사 모드로 전환하여 실제로 어떤 UWP 패키지가 차단되는지 로그로 확인하는 것이 안전하다.
감사 모드는 “차단은 하지 않되 차단될 항목을 이벤트로 남기는” 방식이므로, 실제 사용자 업무 영향 없이 정책 적합성을 검증할 수 있다.
4.2 AppLocker 이벤트 로그 위치를 정확히 본다
AppLocker 관련 로그는 이벤트 뷰어에서 AppLocker 전용 채널로 기록된다.
Packaged app 관련 이벤트를 확인하여 차단된 패키지명과 게시자 정보를 확보해야 한다.
이 정보가 있어야 “정확히 필요한 앱만” 허용하는 규칙을 구성할 수 있다.
4.3 차단된 UWP 패키지 정보를 PowerShell로 수집한다
현장에서는 특정 앱 이름만 알고 패키지명은 모르는 경우가 많으므로, PowerShell로 패키지 정보를 조회하는 방식이 실무적으로 가장 빠르다.
대표적으로 다음 명령으로 설치된 UWP 패키지를 조회할 수 있다.
Get-AppxPackage | Select-Object Name, PackageFullName, Publisher특정 앱만 찾고 싶다면 다음처럼 필터링할 수 있다.
Get-AppxPackage *WindowsStore* | Select-Object Name, PackageFullName, Publisher주의 : 동일한 “앱 이름”이라도 사용자별 설치(User)인지 시스템 공용(AllUsers)인지에 따라 조회 결과가 달라질 수 있으므로, 장애 재현 사용자 컨텍스트에서 확인하는 것이 안전하다.
5. AppLocker에서 UWP 차단 해제 구성 방법(로컬/그룹정책 공통)
5.1 Packaged app 규칙을 구성하는 기본 방향을 정한다
실무에서 가장 흔한 요구는 “스토어 전체는 막되, 회사에서 승인한 UWP 몇 개만 허용” 또는 “기본 내장 UWP는 허용하되, 스토어 설치는 제한” 같은 형태이다.
이를 위해 먼저 목표 정책을 다음 중 하나로 정리해야 한다.
| 운영 목표 | 권장 구성 | 설명 |
|---|---|---|
| 기본 UWP만 허용 | Microsoft 서명 기본앱 Publisher 허용 + 나머지 차단 | 설정/사진/계산기 등 기본 앱 사용을 보장하는 구성이다. |
| 특정 업무 UWP만 허용 | 업무앱 패키지 Publisher 또는 Package name 허용 | 승인 앱만 열리게 하는 구성이다. |
| 스토어 사용은 막고 배포앱만 허용 | 스토어 자체는 차단, 사내 배포 패키지는 허용 | 사용자 임의 설치를 줄이되 필수 앱은 제공하는 구성이다. |
| 스토어까지 폭넓게 허용 | All packaged apps 허용 또는 범용 Publisher 허용 | 통제가 느슨해지므로 승인 절차가 별도로 필요하다. |
5.2 (권장) 기본 규칙을 먼저 생성한다
AppLocker를 처음 구성하는 환경에서는 “기본 규칙(Create Default Rules)” 생성이 운영 안정성에 유리하다.
기본 규칙은 OS 정상 동작에 필요한 대표 항목을 포함하도록 설계되어 있어, 초기 대량 차단을 줄이는 효과가 있다.
다만 조직 보안 기준상 기본 규칙을 그대로 쓰면 과허용이 되는 경우도 있으므로, 기본 규칙은 출발점으로만 사용하고 반드시 검토해야 한다.
5.3 Packaged app에서 허용 규칙을 만든다(게시자 기반)
UWP 차단 해제의 핵심은 Packaged app 규칙에서 허용(Allow)을 만드는 것이다.
게시자 기반 규칙은 일반적으로 다음 순서로 구성한다.
첫째, 차단된 앱의 패키지 정보를 확인한다.
둘째, Packaged app 규칙 생성 마법사에서 해당 앱을 선택한다.
셋째, Publisher 범위를 “게시자만”, “게시자+패키지명”, “게시자+패키지명+버전 범위” 중 요구 수준에 맞게 결정한다.
넷째, 대상 사용자/그룹을 지정한다.
주의 : “게시자만 허용”은 매우 넓은 허용이 될 수 있으므로, 최소한 “게시자+패키지명”까지 묶어 허용하는 방식이 운영상 안전하다.
5.4 예시: Microsoft Store 자체를 허용해야 하는 경우의 판단
일부 환경에서는 스토어 앱 자체(Microsoft Store)가 막히면 사내에서 제공하는 UWP 앱 업데이트나 라이선스 처리에 문제가 생길 수 있다.
반대로 “스토어를 통한 임의 설치”가 보안 목표와 충돌한다면 스토어는 차단하고, 필요한 앱은 오프라인 배포 또는 관리형 배포로 제공하는 방식이 더 적합하다.
따라서 스토어 허용 여부는 단순 기능 문제가 아니라 운영 정책 문제로 분리하여 결정해야 한다.
6. PowerShell로 AppLocker UWP 허용 정책을 설계·배포하는 방법
다수 PC에 동일 정책을 빠르게 적용해야 한다면, GUI보다 PowerShell 기반 정책 생성과 XML 배포가 재현성과 감사 측면에서 유리하다.
특히 테스트 환경에서 XML을 고정하고 변경 이력을 관리하면, 정책 변경으로 인한 장애를 크게 줄일 수 있다.
6.1 로컬에서 현재 AppLocker 정책을 XML로 내보내기
Get-AppLockerPolicy -Local | Out-File -FilePath "C:\Temp\AppLockerPolicy.xml" -Encoding utf86.2 감사 모드 정책을 로컬에 적용하기
정책 적용 방식은 환경에 따라 다르지만, 로컬 테스트에서는 다음 형태로 적용하는 흐름을 자주 사용한다.
Set-AppLockerPolicy -XmlPolicy "C:\Temp\AppLockerPolicy.xml" -MergeMerge 옵션은 기존 정책과 병합하는 방식이므로, 초기 테스트에서 “최소 변경”을 할 때 유용하다.
6.3 이벤트 로그를 기반으로 규칙 초안을 만드는 접근
감사 모드에서 수집된 이벤트를 기반으로 어떤 Packaged app이 차단 대상인지 목록화한 뒤, 허용 목록만 선별하는 방식이 실무적으로 가장 안전하다.
이 과정에서 “사용자 그룹별 허용 앱 목록”을 별도로 관리하면 부서별 예외를 체계적으로 운영할 수 있다.
7. 운영 품질을 높이는 설계 포인트
7.1 사용자/그룹 범위를 반드시 최소화한다
AppLocker 규칙은 “Everyone”에 적용하면 관리가 쉬워 보이지만, 예외가 쌓일수록 보안 목표가 흐려지기 쉽다.
업무상 필요한 그룹에만 UWP 허용을 주고, 일반 사용자는 더 엄격하게 운영하는 구조가 장기적으로 안정적이다.
7.2 패키지 버전 범위는 업데이트 정책과 함께 정한다
버전 범위를 너무 좁히면 앱 업데이트 후 실행이 막히는 장애가 발생할 수 있다.
반대로 버전 범위를 무제한으로 두면 통제가 느슨해질 수 있다.
조직의 업데이트 방식(스토어 자동 업데이트인지, 관리형 배포인지)에 맞춰 버전 범위를 정해야 한다.
7.3 차단이 아닌 “허용 목록 기반”으로 운영하되, 초기에는 감사 모드를 길게 둔다
실무에서는 허용 목록 기반이 보안적으로 선호되지만, 초기에는 누락이 많아 운영 장애가 잦다.
감사 모드로 충분히 로그를 수집하고, 실제 업무 앱을 모두 커버했는지 확인한 뒤 강제로 전환해야 한다.
| 단계 | 권장 기간 예시 | 목표 | 완료 기준 |
|---|---|---|---|
| 1단계: 감사 | 1~2주 | 차단 후보 이벤트 수집 | 업무 필수 앱이 모두 허용 규칙에 포함되었다. |
| 2단계: 제한적 강제 | 파일럿 부서 | 실사용 검증 | 장애 티켓이 허용 가능 수준으로 수렴하였다. |
| 3단계: 전체 강제 | 전사 | 정책 표준화 | 예외 처리 프로세스가 운영되고 있다. |
8. 자주 발생하는 장애와 해결 체크리스트
8.1 “UWP 앱이 클릭해도 실행이 안 됨” 현상
Packaged app 규칙이 없거나, 강제 모드에서 기본앱까지 차단되는 전형적인 형태이다.
감사 모드 이벤트에서 해당 패키지의 차단 이벤트가 있는지 확인하고, 게시자 기반 허용 규칙을 추가해야 한다.
8.2 “규칙을 만들었는데도 어떤 PC에서는 계속 막힘” 현상
도메인 GPO와 로컬 정책이 충돌하거나, 정책 적용이 지연된 경우가 많다.
gpresult 결과로 실제 적용 중인 GPO를 확인하고, 동일 범주의 규칙이 중복되어 있지 않은지 점검해야 한다.
8.3 “특정 사용자만 UWP가 막힘” 현상
규칙이 특정 그룹에만 적용되도록 설계되어 있는데, 사용자가 그룹에 포함되지 않았거나 로그인 방식에 따라 토큰이 달라지는 경우가 있다.
대상 사용자 그룹 membership과 정책 적용 범위를 함께 확인해야 한다.
주의 : 문제를 빠르게 해결하려고 “All packaged apps 허용”을 임시로 적용하면, 이후 원복 시 더 큰 장애가 발생할 수 있으므로 임시 조치도 원인 기반으로 최소 범위에서 수행해야 한다.
9. 권장 예시 구성: 기본 UWP는 허용하고, 임의 스토어 설치는 통제하는 방향
현장에서 만족도가 높은 구성은 “기본 내장 UWP(설정, 계산기, 사진 등)는 허용하되, 스토어를 통한 임의 설치는 별도 통제로 관리”하는 형태이다.
이 방식은 사용자 경험을 유지하면서도 앱 통제를 유지하기 쉽다.
다만 스토어 설치 통제는 AppLocker만으로 완결되는 문제가 아닐 수 있으므로, 조직 정책(스토어 차단 정책, 관리형 배포, 권한 모델)과 함께 설계해야 한다.
FAQ
AppLocker에서 UWP만 따로 허용할 수 있는 이유가 무엇인가?
UWP는 전통적인 exe 실행 방식과 배포/서명 구조가 다르며, AppLocker에서 이를 “Packaged app” 범주로 분리해 제어하도록 설계되어 있기 때문이다.
게시자 기반 규칙을 쓰면 업데이트 후에도 계속 허용되는가?
게시자 기반 규칙은 파일 해시가 아니라 서명자·패키지 정보 기준으로 매칭되므로, 동일 서명자/패키지 범위 내 업데이트에는 일반적으로 안정적으로 동작하는 구조이다.
감사 모드에서 무엇을 확인해야 강제 전환이 안전한가?
업무 필수 UWP 앱과 관리 도구가 차단 후보로 잡히는지 확인해야 하며, 실제 사용자 시나리오를 최소 1~2주 이상 커버하여 누락을 줄이는 것이 안전하다.
로컬에서 규칙을 만들었는데 도메인 환경에서 효과가 없는 이유는 무엇인가?
도메인 GPO가 동일 범주의 AppLocker 정책을 배포하고 있으면 로컬 변경이 덮이거나 우선순위에서 밀릴 수 있으므로, 실제 적용 원본을 gpresult로 먼저 확인해야 한다.