키오스크 모드로 업무 단말을 지키다 ── Assigned Access・Shell Launcher 선택법과 운영 설계

「접수 단말이어야 할 PC에서 방문객이 작업 표시줄로 Excel을 열고 있었다」「장비 조작 화면 뒤에서 YouTube가 재생되고 있었고, 터치패널 반응이 나쁘다는 불만의 원인이 바로 그것이었다」「전시회 데모기가 아침에 가 보니 바탕화면이 훤히 보이는 채로 화면 보호기 설정 화면이 되어 있었다」── 특정 앱 전용이어야 할 Windows 단말은 그대로 방치하면 반드시 「그냥 PC」로 사용됩니다.

흔히 쓰는 대책이 「자동 로그온으로 설정하고 시작 프로그램에 업무 앱을 등록한다」이지만, 이것은 아무것도 지키지 못합니다. Explorer 셸이 통째로 살아 있기 때문에 Alt+Tab이든 Win 키든 순식간에 바탕화면으로 나갈 수 있습니다. 그렇다고 해서 Windows에는 키오스크를 위한 Assigned Access・Shell Launcher・멀티 앱 키오스크라는 여러 방식이 있고, 어느 것을 쓸 수 있는지는 에디션과 Windows 버전에 따라 달라지기 때문에, 「Pro 단말에서 구성하려 했더니 Shell Launcher가 없었다」는 재작업도 자주 발생합니다.

이 글에서는 접수 단말・공장의 조작 단말・검사 장비의 조작 화면・전시용 단말 등 「하나의 앱만 동작시키는 PC」를 구성하고 싶은 개발자・정보시스템 담당자를 대상으로, 방식의 전체상과 에디션 요건, PowerShell/XML 설정 예시, 그리고 자동 로그온・비정상 종료로부터의 복구・Windows Update・보수 경로와 같은 운영 설계까지를 공식 문서를 근거로 정리합니다.

1. 먼저 결론

• 「자동 로그온 + 시작 프로그램 실행」은 키오스크가 아닙니다. Explorer 셸이 살아 있는 한 사용자는 무엇이든 할 수 있습니다. 지키고 싶다면 전용 메커니즘을 사용해야 합니다.
• Assigned Access의 싱글 앱 키오스크는 UWP 앱 또는 Microsoft Edge를 잠금 화면 위에서 전체 화면으로 실행하고, 앱이 닫히면 자동으로 재시작합니다. Pro 이상의 에디션에서 사용할 수 있습니다.¹
• Windows 11에서는 Assigned Access로 Win32(데스크톱) 앱도 키오스크로 만들 수 있습니다. Windows 11(21H2) 이후 스키마에서 추가된 v4:ClassicAppPath에 EXE 경로를 지정합니다. Windows 10의 키오스크는 UWP/Edge로 한정됩니다.²
• Shell Launcher는 Explorer.exe 자체를 업무 앱(Win32/UWP)으로 교체하는 메커니즘으로, Enterprise / Education / IoT Enterprise 계열 에디션 한정입니다. Pro에서는 사용할 수 없습니다. 셸 종료 시 동작(재시작・단말 재시작 등)을 선언적으로 구성할 수 있습니다.³⁴
• 멀티 앱 키오스크(제한된 사용자 환경)는 허용 앱 목록과 전용 시작 메뉴로 「몇 개의 앱만 사용할 수 있는 공유 단말」을 만드는 방식입니다. AppLocker 규칙이 자동으로 생성되어, 허용되지 않은 앱은 실행할 수 없습니다.²
• 구성 방법은 통합이 진행되고 있습니다. 싱글 앱・멀티 앱・Shell Launcher 모두 현재는 AssignedAccess CSP(Intune 등의 MDM), 또는 같은 CSP를 로컬에서 호출하는 WMI 브리지 + PowerShell로 구성하는 것이 표준 절차입니다.⁵⁶
• 키오스크 환경에서 빠져나오는 기본 방법은 Ctrl+Alt+Del입니다. Windows 11에서는 BreakoutSequence로 변경할 수 있습니다. 보수 담당자가 사인인할 수 있는 경로를 반드시 설계에 남겨 두십시오.²
• 단말을 고정해도, 업무 앱 쪽 설계(전체 화면 UI・종료 버튼을 두지 않음・예외 시 자체 복구)가 되어 있지 않으면 구멍이 됩니다. OS의 메커니즘과 앱의 설계는 세트입니다.

2. 선택지의 전체상 ── 네 가지 방식은 「무엇을 지킬 수 있는가」가 다르다

먼저 방식을 나란히 놓고 비교해 봅니다. 중요한 것은 겉모습이 아니라 Explorer 셸이 어떻게 되어 있는가와 허용되지 않은 조작을 누가 막는가입니다.

구분해서 쓰는 감각은 다음과 같습니다.

• 방문객이나 불특정 다수가 만지는 단말(접수・전시・공공 브라우징)은 싱글 앱 키오스크. 노출되는 접점이 최소가 됩니다.
• 정해진 몇 개의 앱을 사용하는 공유 단말(현장 라인 단말, 교육용)은 멀티 앱 키오스크.
• Win32 업무 앱 하나를 장비 조작 화면으로 동작시키는 산업용도는 Shell Launcher. Explorer 유래의 UI(알림, 작업 표시줄, 가장자리 스와이프로 나오는 UI)가 애초에 존재하지 않는 것이 강점이며, 종료 코드에 따른 복구 동작을 구성할 수 있는 점도 장비에 적합합니다.⁴
• 자동 로그온 + 시작 프로그램은 위 방식들 중 어느 하나의 부품(사인인 자동화)으로는 사용하지만, 그 자체만으로는 키오스크가 아닙니다.

참고로 같은 단말에 KioskModeApp(싱글 앱 키오스크)과 Shell Launcher를 동시에 설정할 수는 없습니다.² 둘 중 하나를 선택해야 합니다.

3. 에디션 요건 ── Pro로 할 수 있는 것, Enterprise가 필요한 것

방식을 선정하기 전에 우선 사용 중인 단말의 에디션을 확인하십시오. 이 확인을 뒤로 미루면 설계 자체를 다시 해야 하는 상황이 됩니다.

• Assigned Access(싱글 앱/멀티 앱): Pro / Enterprise / Education / IoT Enterprise(각 LTSC 포함).¹
• Shell Launcher: Enterprise / Enterprise LTSC / Education / IoT Enterprise / IoT Enterprise LTSC. Pro 불가.³
• Keyboard Filter(키 억제): Enterprise / Education / IoT Enterprise 계열만. Pro 불가.⁸

즉 「Pro 단말에서 Win32 앱을 하나만 동작시키고 싶다」는 흔한 요구는,

• Windows 11이라면 Assigned Access의 v4:ClassicAppPath로 그대로 실현할 수 있습니다.²
• Windows 10 Pro라면 선택지가 없어, UWP화하거나 멀티 앱 키오스크 + 자동 실행(rs5:AutoLaunch)으로 근접시키거나, 에디션을 올리는 방법뿐입니다.²

장비 내장이나 산업용 PC에서 새로 단말을 선정할 수 있다면, Shell Launcher・Keyboard Filter까지 모두 갖추고 있고 기능 업데이트가 강제되지도 않는 IoT Enterprise LTSC가 유력한 후보입니다. 에디션 선정에 관한 사고방식은 같은 날 공개한 「산업용 PC에는 어떤 Windows를 넣어야 하는가 ── Windows IoT Enterprise / LTSC 실전 가이드」에서 자세히 다루고 있습니다.

또 하나의 전제로, 키오스크 환경은 UAC가 활성화되어 있어야 하고 콘솔에서의 사인인이 필요합니다. 원격 데스크톱 연결로는 키오스크 환경이 동작하지 않습니다.¹ 「RDP로 접속해서 동작을 확인해 보자」라고 시도했다가 동작하지 않아 당황하는 것이 처음 접했을 때 흔히 걸리는 함정입니다. 콘솔 세션과 RDP 세션의 관계는 「Windows의 세션 분리를 어떻게 이해할까」를 참조하십시오.

4. Assigned Access로 싱글 앱 키오스크 만들기

설정 경로는 세 가지가 있습니다. 간단한 순서대로 4.1~4.3에서 살펴보고, 그중 핵심인 구성 XML에 대해서는 실제로 단말에 적용하는 절차(4.4)와 적용되었는지 확인하는 방법(4.5)까지 이어서 다룹니다.

4.1 설정 앱으로 만들기(한 대뿐이거나 Edge/UWP라면 가장 빠름)

키오스크용 로컬 계정 생성과 대상 앱 선택을 마법사로 진행할 수 있습니다. 절차는 다음과 같습니다.⁵

1. 설정 > 계정 > 기타 사용자를 엽니다
2. 「키오스크 모드 설정」(Set up a kiosk)의 「시작」(Get Started)을 누릅니다
3. 「계정 만들기」 대화 상자에서 계정 이름을 입력하고 「다음」을 누릅니다(이미 로컬 표준 사용자가 있는 경우 「기존 계정 선택」도 선택할 수 있습니다)
4. 키오스크 계정 사인인 시 실행할 앱을 선택합니다. Microsoft Edge를 선택한 경우에는 이어서 다음을 설정합니다
   • 전체 화면 표시(디지털 사이니지)로 할지, 일부 브라우저 조작을 남길지(퍼블릭 브라우저)
   • 사인인 시 열 URL
   • 퍼블릭 브라우저를 선택한 경우, 조작이 없는 상태가 계속될 때 Edge를 재시작할 때까지의 시간
5. 「닫기」를 누릅니다

설정 후 단말을 재시작하면 생성된 로컬 계정이 자동으로 사인인하고 지정한 앱이 실행됩니다.⁵ 한 대뿐이거나 Edge 또는 단순한 UWP 앱이라면 이것으로 충분합니다.

4.2 PowerShell 명령으로 만들기(UWP 한정)

Set-AssignedAccess는 「이 로컬 표준 사용자는 이 UWP 앱만」이라는 최소 구성을 한 줄로 만들 수 있습니다(UWP 한정・로컬 표준 사용자 한정・관리자 계정 불가).⁹

# 로컬 표준 사용자 KioskUser를 UWP 앱 전용으로 설정
Set-AssignedAccess -UserName 'KioskUser' -AppUserModelId 'Contoso.KenkiPanel_abc123!App'

# 해제
Clear-AssignedAccess

인수로 전달하는 AUMID(AppUserModelID)는 Get-StartApps로 조사합니다. 설치된 앱의 이름과 AppID를 나열하는 명령으로, Name과 AppID 두 열이 반환됩니다.¹⁰

# 목록에서 눈으로 확인하며 찾기
Get-StartApps

# 이름의 일부로 좁히기(와일드카드 가능). AppID 열의 값이 그대로 AUMID
Get-StartApps -Name '*KenkiPanel*' | Format-Table Name, AppID -AutoSize

출력은 다음과 같은 형태가 됩니다(값은 환경마다 다릅니다).¹⁰

Name              AppID
----              -----
KenkiPanel        Contoso.KenkiPanel_abc123!App

중요한 주의 사항으로, Get-StartApps는 「실행 중인 사용자」의 설치된 앱을 반환합니다. 키오스크 계정용으로 프로비저닝한 앱을 조사하고 싶다면 그 계정으로 사인인해서 실행하십시오. 관리자 계정으로 실행했더니 나오지 않는다는 것이 흔한 착오입니다. 아울러 UWP 앱 업데이트로 AUMID가 바뀔 수 있다는 점에도 주의하십시오(그 경우 구성을 다시 만들어야 합니다).⁷

4.3 구성 XML + AssignedAccess CSP(핵심 방법)

Win32 앱 지정, 자동 로그온, 탈출 키 변경까지 포함하는 핵심 방법입니다. Intune 등의 MDM에서는 ./Vendor/MSFT/AssignedAccess/Configuration에, 독립형 단말에서는 WMI 브리지를 통해 SYSTEM 권한의 PowerShell에서 같은 XML을 흘려 넣습니다.⁵ XML의 요점은 다음과 같습니다.

<AssignedAccessConfiguration
    xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
    xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config"
    xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <!-- Windows 11: Win32 앱을 키오스크로 만들기(인수도 전달 가능) -->
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe"
                    v4:ClassicAppArguments="--line 3" />
      <!-- 탈출 키를 기본값인 Ctrl+Alt+Del에서 변경 -->
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <!-- Windows가 전용 로컬 표준 사용자를 생성・관리하여 자동 사인인 -->
      <AutoLogonAccount rs5:DisplayName="접수 단말" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>

UWP 앱이라면 KioskModeApp에 AppUserModelId(AUMID)를 지정합니다. 주의할 점으로, UWP 앱 업데이트로 AUMID가 바뀔 수 있으며, 그 경우 구성을 갱신해야 합니다.⁷ 또한 키오스크 프로필은 사용자에게만 할당할 수 있으며 그룹에는 할당할 수 없습니다.²

4.4 WMI 브리지로 실제로 적용하기

MDM이 없는 단말에서는 MDM 브리지 WMI 공급자를 통해 같은 CSP를 호출합니다. 이 부분이 절차상 가장 막히기 쉬운 곳이므로 순서대로 적어 둡니다.⁵

절차 1: SYSTEM으로 PowerShell을 실행한다. 디바이스 설정의 WMI 브리지는 SYSTEM(LocalSystem) 계정으로 실행되고 있어야 합니다. 관리자 권한 PowerShell로는 부족합니다.⁵ Sysinternals의 PsExec를 사용하는 것이 공식적으로 안내되는 방법입니다.

:: 관리자 권한으로 명령 프롬프트를 열고, SYSTEM 권한의 대화형 PowerShell을 실행
psexec.exe -i -s powershell.exe

절차 2: 실행한 PowerShell이 SYSTEM인지 확인한다. 이 확인을 건너뛰고 진행했다가 「오류는 나지 않는데 적용되지 않는다」가 되는 것이 흔한 패턴입니다.

# NT AUTHORITY\SYSTEM 이 표시되면 OK
[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

절차 3: XML을 HTML 인코딩해서 흘려 넣는다. 해당 SYSTEM 권한의 PowerShell 세션에서 실행합니다.

$assignedAccessConfiguration = @"
<?xml version="1.0" encoding="utf-8"?>
<AssignedAccessConfiguration xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config" xmlns:rs5="http://schemas.microsoft.com/AssignedAccess/201810/config" xmlns:v4="http://schemas.microsoft.com/AssignedAccess/2021/config">
  <Profiles>
    <Profile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}">
      <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Contoso\KenkiPanel.exe" v4:ClassicAppArguments="--line 3" />
      <v4:BreakoutSequence Key="Ctrl+Alt+K" />
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount rs5:DisplayName="접수 단말" />
      <DefaultProfile Id="{EDB3036B-780D-487D-A375-69369D8A8F78}" />
    </Config>
  </Configs>
</AssignedAccessConfiguration>
"@

$namespaceName = "root\cimv2\mdm\dmmap"
$className     = "MDM_AssignedAccess"

$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
# XML은 그대로가 아니라 HTML 인코딩해서 전달한다
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($assignedAccessConfiguration)
Set-CimInstance -CimInstance $obj

절차 4: 단말을 재시작한다. 설정은 재시작 후의 사인인부터 적용됩니다. 재시작하면 AutoLogonAccount로 만들어진 로컬 계정이 자동으로 사인인하고 지정한 앱이 실행됩니다.⁵

해제하려면 마찬가지로 SYSTEM 권한의 PowerShell에서 Configuration에 $null을 설정하고 재시작합니다.⁵

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration = $null
Set-CimInstance -CimInstance $obj

4.5 적용되었는지 어떻게 확인할 것인가

「오류는 나지 않는데 적용되지 않는다」를 가려내기 위해 확인 수단을 세 가지 준비해 둡니다.

(a) 이벤트 로그를 활성화해서 확인한다. 공식적으로 안내되는 확인 대상은 이 채널입니다.⁷ 구성 XML의 검증 오류나 실행 시 실패는 여기에 나타납니다.

이벤트 뷰어
  > 응용 프로그램 및 서비스 로그
    > Microsoft
      > Windows
        > AssignedAccess
          > Operational

기본적으로 비활성화되어 있는 경우가 있으므로, 채널을 선택하고 오른쪽 창의 「로그 사용」을 누른 뒤 재현시키십시오.

(b) 기록된 구성을 레지스트리에서 확인한다. Assigned Access의 구성은 다음 키에 기록됩니다.⁷

(c) CSP에서 다시 읽어 온다. 흘려 넣은 직후에 같은 SYSTEM 권한의 PowerShell로 다시 읽어 보면, 값이 들어갔는지를 그 자리에서 확인할 수 있습니다.

$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration

# 인코딩된 상태로 반환되어 읽기 어려운 경우 디코딩해서 눈으로 확인한다
[System.Net.WebUtility]::HtmlDecode($obj.Configuration)

이 결과가 비어 있으면 적용 자체가 실패한 것이고, 값은 들어갔는데 동작하지 않는다면 XML 내용(앱 경로, 프로필과 Config의 GUID 불일치, 에디션 요건)을 의심해 보면 됩니다. 절차 3에서 오류가 발생한 경우에는 먼저 절차 2의 SYSTEM 확인으로 돌아가십시오.

5. Shell Launcher로 Win32 앱을 셸로 만들기

Enterprise 계열 에디션을 사용할 수 있다면, 장비 조작 화면처럼 「Explorer의 존재 자체가 방해」가 되는 단말에는 Shell Launcher가 가장 유력합니다. Shell Launcher v2(Windows 10 1809 이후)는 Explorer.exe 대신 CustomShellHost.exe가 업무 앱을 실행・감시하며, Win32든 UWP든 셸로 만들 수 있습니다.³

구성은 전용 XML로 이루어지며, 앱이 종료되었을 때의 복구 동작을 종료 코드별로 선언할 수 있는 것이 가장 큰 특징입니다.⁴

<ShellLauncherConfiguration
    xmlns="http://schemas.microsoft.com/ShellLauncher/2018/Configuration"
    xmlns:V2="http://schemas.microsoft.com/ShellLauncher/2019/Configuration">
  <Profiles>
    <DefaultProfile>
      <!-- 보수 담당자 등 프로필이 할당되지 않은 사용자는 일반 Explorer -->
      <Shell Shell="%SystemRoot%\explorer.exe" />
    </DefaultProfile>
    <Profile Id="{직접 채번한 GUID}">
      <Shell Shell="%ProgramFiles%\Contoso\KensaPanel.exe" V2:AppType="Desktop"
             V2:AllAppsFullScreen="true">
        <ReturnCodeActions>
          <ReturnCodeAction ReturnCode="0"  Action="RestartShell"/>   <!-- 정상 종료 → 재시작 -->
          <ReturnCodeAction ReturnCode="10" Action="RestartDevice"/>  <!-- 재시작 필요 요청 -->
        </ReturnCodeActions>
        <DefaultAction Action="RestartShell"/>
      </Shell>
    </Profile>
  </Profiles>
  <Configs>
    <Config>
      <AutoLogonAccount/>  <!-- 로컬 표준 사용자 「Kiosk」를 자동 생성・자동 사인인 -->
      <Profile Id="{직접 채번한 GUID}"/>
    </Config>
  </Configs>
</ShellLauncherConfiguration>

Profile Id의 GUID는 어딘가에 신청해서 발급받는 값이 아닙니다. XML 내에서 고유하기만 하면 되는, 직접 채번하는 값으로, PowerShell의 New-Guid로 생성할 수 있습니다.⁴

# 중괄호가 포함된 형태로 하나 생성한다. 이 문자열을 XML에 붙여 넣는다
"{$((New-Guid).Guid.ToUpper())}"

생성한 값을 Profiles 쪽과 Configs 쪽 양쪽에 같은 형태(중괄호 포함)로 적어 넣으십시오. 위 예시를 그대로 복사해서는 동작하지 않는 것은 이 치환이 필요하기 때문입니다. 4장의 Assigned Access 구성 XML에 나오는 Profile Id / DefaultProfile Id도 같은 성질의 값입니다.

액션은 RestartShell / RestartDevice / ShutdownDevice / DoNothing의 4종류입니다. 종료 코드가 매핑에 없고 DefaultAction도 정의되어 있지 않으면 「아무 일도 일어나지 않습니다」, 즉 검은 화면인 채로 멈춥니다. DefaultAction은 반드시 정의하십시오.⁴ 적용은 MDM이라면 ./Vendor/MSFT/AssignedAccess/ShellLauncher에, 로컬이라면 Assigned Access와 같은 WMI 브리지로 MDM_AssignedAccess의 ShellLauncher 속성에 XML을 설정합니다.⁶ 환경에 따라서는 사전에 「Windows 기능 켜기/끄기」에서 디바이스 잠금 아래에 있는 Shell Launcher 기능(Client-EmbeddedShellLauncher)을 활성화해 두어야 하는 경우가 있습니다.

Shell Launcher 고유의 함정을 세 가지 들어 봅니다.³

• 별도 프로세스를 실행하고 자신은 종료하는 유형의 앱은 셸로 만들 수 없습니다. Shell Launcher는 지정한 프로세스의 종료를 감시하므로, 런처형 EXE(공식 문서의 예시로는 write.exe)를 지정하면 즉시 「종료되었다」로 판정됩니다.
• 셸은 사인인한 사용자의 권한으로 동작합니다. 관리자 계정에 셸을 할당하면 그 권한으로 무엇이든 할 수 있게 되며, 셸 앱 자체가 관리자 상승을 요구하는 경우에는 UAC를 비활성화하지 않으면 실행할 수 없습니다. 그렇게 되기 전에 앱을 상승이 필요 없도록 설계해야 합니다.
• Shell Launcher는 다른 앱의 실행을 막지 않습니다. 셸을 교체할 뿐이므로, 업무 앱 내부의 파일 대화 상자를 통해 EXE를 실행하는 등의 경로는 남아 있습니다. 사용하는 사람을 신뢰할 수 없는 단말에서는 AppLocker나 Keyboard Filter를 병용하십시오.

6. 운영 설계 ── 자동 로그온・복구・Update・보수 경로

방식을 선택해서 설정하는 것으로 끝이 아닙니다. 무인으로 계속 돌아가도록 하는 설계야말로 키오스크의 본체입니다.

자동 로그온은 구성 XML의 AutoLogonAccount를 첫 번째 후보로 삼습니다. Windows가 전용 로컬 표준 사용자를 생성・관리하기 때문에 암호를 보관할 필요가 없습니다.²⁴ 기존의 Winlogon 레지스트리 방식(AutoAdminLogon/DefaultUserName/DefaultPassword)도 사용할 수 있지만, 암호가 평문으로 남습니다. 또한 EAS 암호 제한이 적용된 단말에서는 자동 로그온이 동작하지 않는 사양이므로, MDM 정책과 충돌하고 있지는 않은지 확인하십시오.⁷

앱이 다운되었을 때의 1차 복구는 OS 쪽에 맡깁니다. Assigned Access 키오스크는 앱이 닫히면 자동으로 재시작됩니다.¹ Shell Launcher는 DefaultAction/ReturnCodeActions로 복구 동작을 구성합니다.⁴ 그 위에, 「재시작해도 같은 예외로 계속 다운되는」 경우에 대비해 야간의 정기 재시작 작업을 넣어 두면 복구력이 높아집니다(작업을 구성하는 방법은 「작업 스케줄러의 안전한 운영 설계」 참조).

Windows Update는 멈추는 것이 아니라 시간을 제어합니다. 활성 시간을 영업 시간에 맞추고, 자동 다운로드 + 야간 예약 설치로 하며, 재시작 경고를 포함한 알림을 끄는 것이 공식 권장 구성입니다.⁷ 재시작 후에는 「자동 로그온 → 키오스크 복구」까지 자동으로 이어지는지를 실제 기기에서 확인해 둡니다. 전원 설정도 마찬가지로, 절전이나 디스플레이 끄기의 시간 제한을 0(사용 안 함)으로 하고 전원 버튼을 비활성화합니다.⁷ 노트북 전용 단말이나 Modern Standby 기기는 특히 동작에 특이점이 있으므로, 「슬립・최대 절전 모드・Modern Standby와 장시간 가동 앱」도 함께 확인하십시오.

키보드와 터치의 구멍은 방식마다 다릅니다. 멀티 앱 키오스크(제한된 사용자 환경)에서는 Alt+F4・Alt+Tab・Ctrl+Alt+Del이 기본적으로 차단되지 않습니다.⁷ 이를 막는 것이 Keyboard Filter로, 물리・화면 키보드 양쪽의 키 조합을 억제할 수 있습니다(Dism /online /Enable-Feature /FeatureName:Client-KeyboardFilter로 활성화, Enterprise 계열 한정).⁸ 태블릿형 단말에서는 화면 가장자리에서의 스와이프로 시스템 UI가 나타나지 않도록 LockDown/AllowEdgeSwipe 정책을 사용 안 함(0)으로 설정합니다.

보수 경로 확보는 막는 것 못지않게 중요합니다. Assigned Access 키오스크의 탈출은 기본적으로 Ctrl+Alt+Del(Windows 11에서는 BreakoutSequence로 변경 가능)이며, 그곳에서 관리자 계정으로 사인인합니다.² Keyboard Filter로 Ctrl+Alt+Del을 막는 경우에는 Keyboard Filter 쪽의 브레이크아웃 키(기본값은 왼쪽 Windows 키 5회 연타)가 시작 화면으로 가는 마지막 경로가 됩니다.⁸ 참고로 Keyboard Filter는 세이프 모드에서는 작동하지 않으며, 관리자 계정에는 적용 대상에서 제외할 수 있습니다.⁸ 키오스크 환경은 콘솔 전용이지만 관리자의 RDP 보수는 병행할 수 있으므로, 원격 경로도 남겨 두면 현장 출동이 줄어듭니다. 문제가 발생했을 때는 이벤트 로그의 「AssignedAccess > Operational」 채널이 구성 오류에 대한 1차 정보가 됩니다.⁷

7. 업무 앱 쪽의 설계와 실무 정석(판단표)

OS 쪽을 아무리 단단히 고정해도 앱이 「평범한 데스크톱 앱」인 채로 남아 있으면 구멍이 남습니다. 키오스크에 올릴 앱의 설계 요건을 들어 봅니다.

• 전체 화면・테두리 없음을 스스로 유지한다. Shell Launcher의 V2:AllAppsFullScreen이 있기는 하지만, 기본적으로는 앱 스스로 최대화・최상위・제목 표시줄 없음을 유지하고, 포커스를 잃었을 때 자신을 다시 앞으로 가져오도록 설계합니다.
• 종료 버튼을 두지 않는다. 닫는 수단을 화면에 두지 않는 대신, 보수 담당자만 아는 숨겨진 조작(예: 화면의 네 모서리를 순서대로 탭 + 암호)으로 보수 메뉴를 표시합니다. 종료 코드를 구분해 두면 Shell Launcher의 ReturnCodeActions로 「보수 메뉴에서의 종료 → Explorer 복귀를 위해 아무것도 하지 않음」「업데이트 후 종료 → 단말 재시작」과 같은 연계를 할 수 있습니다.⁴
• 예외 발생 시 스스로 복구한다. 처리되지 않은 예외를 삼켜 버려 조작 불능 상태로 화면이 남는 것이 최악입니다. 로그를 남기고 신속하게 자신의 프로세스를 종료해, OS 쪽의 재시작 메커니즘(키오스크의 자동 재시작・Shell Launcher의 RestartShell)이 받아 처리하도록 합니다.
• 중복 실행을 방지한다. 자동 재시작 계열 메커니즘과 자체 재시작 처리가 겹치면 이중 실행이 일어나기 쉽습니다. Mutex를 이용한 중복 실행 방지를 넣어 둡니다(「Windows 앱의 중복 실행 방지」).
• 상승을 요구하지 않는다. 키오스크 계정은 표준 사용자가 원칙이며, Shell Launcher에서는 상승이 필요한 셸의 경우 UAC 비활성화를 강요받게 됩니다.³ 관리자 권한이 필요한 처리는 분리해 둡니다(「Windows 앱에서 「관리자 권한이 필요한 처리만」을 분리하는 구체적인 방법」).

마지막으로 판단표입니다.

8. 정리

• 「자동 로그온 + 시작 프로그램 실행」은 키오스크가 아닙니다. Explorer가 살아 있는 한 아무것도 지킬 수 없으므로 Assigned Access나 Shell Launcher를 사용합니다.
• Assigned Access는 Pro 이상에서 사용할 수 있으며, 싱글 앱 키오스크(UWP/Edge, Windows 11은 Win32도)와 멀티 앱의 제한된 사용자 환경을 구성할 수 있습니다.
• Shell Launcher는 Explorer.exe를 업무 앱으로 교체하는 Enterprise / Education / IoT Enterprise 계열 한정 메커니즘으로, 종료 코드별 복구 동작(RestartShell 등)을 선언할 수 있습니다.
• 구성은 AssignedAccess CSP로 통합되어 있으며, MDM이 없어도 WMI 브리지 + PowerShell(SYSTEM 권한)로 같은 XML을 적용할 수 있습니다.
• 운영 설계의 골자는 AutoLogonAccount에 의한 자동 사인인, OS 재시작 메커니즘 + 정기 재시작에 의한 복구, Windows Update의 시간 제어, 그리고 BreakoutSequence・브레이크아웃 키・원격 보수라는 탈출 경로의 확보입니다.
• 마지막 보루는 업무 앱의 설계입니다. 전체 화면 유지・종료 버튼 없음・예외 시 자체 복구・중복 실행 방지・상승 불필요를 충족해야 비로소 「하나의 앱만 동작시키는 PC」가 완성됩니다.

관련 글

• 산업용 PC에는 어떤 Windows를 넣어야 하는가 ── Windows IoT Enterprise / LTSC 실전 가이드
• Windows 앱의 중복 실행 방지 ── 네임드 Mutex와 재실행 시 창 활성화
• Windows의 세션 분리를 어떻게 이해할까 ── Session 0・RDP・다중 사용자 동시 실행
• 슬립・최대 절전 모드・Modern Standby와 장시간 가동 앱 ── ‘한밤중에 멈춰 있었다’를 설계로 막는다
• 작업 스케줄러 작업이 실행되지 않는다・0x1로 끝난다 ── 원인 분리와 안전한 운영 설계
• Windows 앱에서 「관리자 권한이 필요한 처리만」을 분리하는 구체적인 방법

관련 상담 영역

합동회사 코무라소프트에서는 접수 단말・공장의 조작 단말・검사 장비의 조작 화면과 같은 키오스크 단말의 방식 선정과 구성, 키오스크에 견디는 업무 앱(전체 화면 UI・자체 복구・권한 분리)의 설계・개발, 기존 단말의 「재고정」을 다루고 있습니다.

• Windows 업무 앱 개발
• 장치 연동・소프트 리얼타임 제어 앱 개발
• 기술 상담・설계 리뷰
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Assigned Access는 Windows Pro에서도 사용할 수 있나요?

사용할 수 있습니다. Assigned Access(싱글 앱 키오스크와 멀티 앱의 제한된 사용자 환경)는 Pro / Enterprise / Education / IoT Enterprise(각각의 LTSC 포함)에서 지원됩니다. 반면 Explorer.exe 자체를 업무 앱으로 교체하는 Shell Launcher는 Enterprise / Education / IoT Enterprise 계열에서만 사용할 수 있으며, Pro에서는 사용할 수 없습니다. 또한 키오스크 환경은 UAC가 활성화되어 있어야 하고 콘솔에서의 사인인이 필요하며, 원격 데스크톱 연결을 통한 키오스크 환경은 지원되지 않습니다.

Win32(데스크톱) 앱을 키오스크로 만들려면 Shell Launcher가 반드시 필요한가요?

Windows 11에서는 반드시 필요하지는 않게 되었습니다. Windows 11(21H2 이후 스키마)의 Assigned Access는 KioskModeApp 요소의 v4:ClassicAppPath 속성으로 데스크톱 앱의 실행 파일 경로를 지정할 수 있어, Pro 단말에서도 Win32 앱의 싱글 앱 키오스크를 구성할 수 있습니다. Windows 10의 Assigned Access 키오스크는 UWP 앱과 Microsoft Edge로 한정되어 있으므로, Win32 앱을 하나만 동작시키려면 Shell Launcher(Enterprise 계열 한정)나 멀티 앱 구성에서 AutoLaunch를 사용하는 방법이 현실적인 대안이 됩니다. 에디션과 방식의 대응 관계를 먼저 확인한 뒤 설계하십시오.

키오스크 앱이 비정상 종료되면 자동으로 복구되나요?

방식에 따라 동작이 다릅니다. Assigned Access의 싱글 앱 키오스크는 앱이 닫히면 자동으로 재시작되는 사양입니다. Shell Launcher에서는 셸로 지정한 앱이 종료될 때의 동작을 DefaultAction과 ReturnCodeActions로 선언적으로 구성할 수 있으며, RestartShell(셸 재시작)・RestartDevice(단말 재시작)・ShutdownDevice・DoNothing 중에서 선택할 수 있습니다. 종료 코드에 대응하는 액션이 정의되어 있지 않고 DefaultAction도 없는 경우에는 아무 일도 일어나지 않고 검은 화면인 채로 멈추므로, DefaultAction은 반드시 정의해야 합니다. 앱 쪽에도 처리되지 않은 예외가 발생했을 때 스스로를 종료시켜 복구 동작으로 이어지도록 하는 설계가 필요합니다.

보수 담당자는 어떻게 관리자로 로그인해야 하나요?

Assigned Access의 키오스크 환경은 기본적으로 Ctrl+Alt+Del로 사인인 화면으로 빠져나갈 수 있으며, Windows 11에서는 BreakoutSequence 요소로 이 키 조합을 변경할 수 있습니다. Keyboard Filter로 Ctrl+Alt+Del까지 막는 구성에서는 Keyboard Filter 쪽의 브레이크아웃 키(기본값은 왼쪽 Windows 키를 5회 연타)로 시작 화면으로 돌아가는 경로를 남겨 둘 수 있습니다. 키오스크 환경 자체는 콘솔 전용이지만, 관리자 계정에 의한 원격 데스크톱 보수는 별도 세션으로 병행할 수 있습니다. 탈출 경로를 전부 막아 버려서 현장 작업으로만 복구할 수 있는 단말이 되지 않도록 하는 것이 중요합니다.

자동 로그온용 암호를 레지스트리에 적어 두는 것은 안전한가요?

권장하지 않습니다. Winlogon의 AutoAdminLogon 방식은 DefaultPassword가 레지스트리에 평문으로 남습니다. Assigned Access와 Shell Launcher의 구성 XML에는 AutoLogonAccount 요소가 있으며, 이를 사용하면 Windows가 전용 로컬 표준 사용자를 스스로 생성・관리하여 자동으로 사인인하므로 암호를 직접 보관할 필요가 없습니다. 키오스크용 계정은 최소 권한의 로컬 표준 사용자로 하고, 도메인 계정을 그대로 사용하는 것은 피하는 것이 원칙입니다. 또한 Exchange ActiveSync의 암호 제한 정책이 적용된 단말에서는 자동 로그온이 동작하지 않는다는 점에도 주의하십시오.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.