키오스크 모드로 업무 단말을 고정한다 ── 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 기능과 앱 설계는 한 세트입니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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 고르기 ── 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 cmdlet으로 만든다(UWP 한정)

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

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

# 해제
Clear-AssignedAccess

인수로 넘기는 AUMID(AppUserModelID)는 Get-StartApps로 조사합니다. 설치된 앱의 이름과 AppID를 나열하는 cmdlet으로, 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 네 종류입니다. 종료 코드가 매핑에 없고 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회 연속 입력)가 Welcome 화면으로의 마지막 경로가 됩니다.⁸ 참고로 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 고르기 ── IoT Enterprise LTSC 실천 가이드
• Windows 앱의 다중 기동 방지
• Windows의 세션 분리를 어떻게 이해할 것인가
• 절전·최대 절전·Modern Standby와 장시간 가동 앱
• 작업 스케줄러의 안전한 운영 설계
• 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회 연속 입력)로 Welcome 화면으로 돌아가는 경로를 남겨 둘 수 있습니다. 키오스크 경험 자체는 콘솔 전용이지만, 관리자 계정으로의 원격 데스크톱 보수는 별도 세션으로 함께 쓸 수 있습니다. 탈출 경로를 전부 막아 현장 작업으로만 복구할 수 있는 단말이 되지 않게 하는 것이 중요합니다.

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

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

저자 프로필

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

Go Komura

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

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