Windows에서 관리자 권한이 필요한 때는 언제인가 - UAC, 보호 영역, 설계로 구분하는 방법

Windows 관련 상담에서 자주 섞여 들어오는 이야기가 있습니다.

• 어떤 때에 “관리자 권한으로 실행”이 필요한가
• 관리자 계정인데 왜 아직 UAC가 뜨는가
• 설치는 반드시 관리자인가
• Program Files에 두고 싶은데, 실행 시까지 권한 상승이 필요한가
• HKCU와 HKLM의 차이는 실무에서 무엇에 영향을 주는가
• “일부 처리만” 관리자 권한이 필요한 앱은 어떻게 만들어야 하는가

이 이야기는 단순히 “그 사람이 관리자인가”만으로는 정해지지 않습니다. 실제로는 어디에 쓰는가, 누구에게 영향을 주는 변경인가, OS의 어느 보호 대상에 접근하는가로 상당 부분 정해집니다.

flowchart TB
    accTitle: 관리자 권한의 필요 여부를 정하는 것
    accDescr: 관리자 권한이 필요한지는 그 사람이 관리자인지 여부만으로는 정해지지 않고, 어디에 쓰는가, 누구에게 영향을 주는 변경인가, OS의 어느 보호 대상에 접근하는가로 상당 부분 정해진다는 것을 나타내는 그림.
    a0["그 사람이 관리자인가"] -.-> a1["그것만으로는 정해지지 않는다"]
    b0["실제로 효력이 있는 질문"] --> b1["어디에 쓰는가"]
    b0 --> b2["누구에게 영향을 주는 변경인가"]
    b1 --> b3["OS의 어느 보호 대상에 접근하는가"]

그림 1: 필요 여부를 정하는 것은 사용자가 관리자인지가 아니라, 쓰기 위치·영향 범위·보호 대상.

이 글에서는 Windows에서 관리자 권한이 필요한 상황을 UAC의 전제부터 순서대로 정리하면서, 어디까지가 표준 사용자 권한으로 끝나고, 어디부터가 권한 상승의 이야기가 되는가를 실무용으로 정리합니다. 내용은 2026년 3월 시점에서 확인할 수 있는 Microsoft 공식 정보를 전제로 합니다.¹²³⁴⁵

1. 먼저 결론

실무에서 쓸 결론만 먼저 나열합니다.

• Windows에서 관리자 권한이 필요한지는 “대단한 처리인가”보다 “OS나 머신 전체에 영향을 주는가”로 정해집니다.¹⁴
• 자기 프로필에만 국한된 처리, 예를 들어 %AppData%, %LocalAppData%, HKCU, Documents를 쓰는 처리는 보통 관리자 권한 없이 끝납니다.⁶⁷
• 반대로 머신 전체·모든 사용자·보호 영역에 접근하는 처리, 예를 들어 Program Files, Windows, System32, HKLM, HKCR의 machine-wide 설정, Windows 서비스, 커널 드라이버, 방화벽, 최고 권한 작업 등은 관리자 권한이 필요해지기 쉽습니다.⁴⁶⁸⁹¹⁰
• 여기서 중요한 것은 사용자가 Administrators 그룹에 속해 있는 것과 그 앱이 지금 관리자 access token으로 동작하는 것은 별개라는 점입니다. UAC가 켜져 있으면 관리자 사용자라도 보통 프로세스는 표준 사용자에 해당하는 권한으로 동작하고, 필요할 때만 권한을 올립니다.²⁶
• 설치 = 반드시 관리자가 아닙니다. per-user 설치처럼 %LocalAppData% 아래에 넣는 전제라면, 관리자 권한 없이 배포·업데이트할 수 있는 설계도 있습니다.¹¹¹²
• “왠지 매번 관리자 권한이 필요한 앱”은 실제로는 실행 시 데이터를 보호 영역에 쓰고 있거나, 매니페스트에서 requireAdministrator / highestAvailable을 선언하고 있는 경우가 많습니다.⁴¹³
• 앞으로의 방향성으로도 Windows는 필요한 순간에만 명시적으로 권한을 올리는 쪽으로 기울고 있습니다. Windows 11의 Administrator protection(preview)은 그 흐름을 꽤 분명히 보여 줍니다.⁵

요컨대 “관리자 권한이 필요한가”는 사용자가 관리자인지가 아니라, 앱이 접근하는 경계로 정해진다고 보는 것이 가장 실무적입니다.

flowchart TB
    accTitle: 영향 범위로 나뉘는 권한 상승의 필요 여부
    accDescr: 관리자 권한이 필요한지는 대단한 처리인가가 아니라 OS나 머신 전체에 영향을 주는가로 정해지며, 자기 프로필에 국한된 처리는 불필요하고, 머신 전체·모든 사용자·보호 영역에 접근하는 처리는 필요해지기 쉽다는 것을 나타내는 그림.
    j1{"OS나 머신 전체에 영향을 주는가"}
    j1 -->|"자기 프로필에 국한된다"| r1["관리자 권한 없이 끝나기 쉽다"]
    j1 -->|"머신 전체·모든 사용자·보호 영역에 접근한다"| r2["관리자 권한이 필요해지기 쉽다"]
    r0["대단한 처리인가"] -.-> r3["판단 기준이 아니다"]

그림 2: 갈림길은 처리가 복잡한지가 아니라, 변경의 영향 범위.

이 글의 지식 맵

이 글은 Windows에서 관리자 권한이 필요한 상황을, OS나 머신 전체에 영향을 주는 보호 영역에 쓰기를 하는지라는 관점에서 정리합니다. UAC가 켜진 환경에서는 관리자 사용자가 시작한 프로세스도 기본값으로는 표준 사용자 권한으로 동작하며, Program Files나 HKLM 같은 보호 영역에 손을 대는 작업의 순간에만 권한 상승이 요구됩니다. 설치는 반드시 관리자가 필요한 것은 아니며, per-user 설치라면 관리자 권한 없이 배포·업데이트할 수 있지만, 실행 시 데이터를 보호 영역에 쓰고 있거나 installer detection 조건에 해당하면 관리자가 필요해지기 쉽습니다. 관리자 처리를 분리하는 모델에는 Administrator Broker Model·서비스·최고 권한 작업·권한 상승 COM이 있으며, Windows 11의 Administrator protection(preview)은 필요한 순간에만 권한 상승하는 방향을 한층 더 밀어 나간 것입니다.

flowchart LR
    accTitle: Windows에서 관리자 권한이 필요한 상황의 지식 맵
    accDescr: OS의 보호 영역에 쓰기를 하는지라는 기준이, UAC의 권한 상승 요청·per-user/per-machine 설치 선택·installer detection이나 가상화와의 관계·4가지 권한 분리 모델의 용도 구분을 어떻게 좌우하는지를 나타낸 그림.
    admin_rights["관리자 권한"]
    uac["UAC(사용자 계정 컨트롤)"]
    protected_system_location["OS 보호 영역"]
    integrity_level["무결성 수준"]
    installer_detection["installer detection(인스톨러 검색)"]
    file_registry_virtualization["파일/레지스트리 가상화(VirtualStore)"]
    requested_execution_level["requestedExecutionLevel(실행 수준 선언)"]
    runtime_data_storage["런타임 데이터 저장 위치"]
    user_profile_storage_location["사용자 프로필 하위 저장 위치"]
    per_machine_install["per-machine 설치"]
    per_user_install["per-user 설치"]
    administrator_broker_model["Administrator Broker Model"]
    sporadic_admin_operation["산발적인 관리자 작업"]
    os_service_model["Operating System Service Model"]
    continuous_unattended_admin_operation["상시·무인·빈번한 관리자 작업"]
    elevated_task_model["권한 상승 작업 모델"]
    short_scheduled_admin_task["짧고 정형화된 관리자 작업"]
    admin_com_object_model["Administrator COM Object Model"]
    existing_com_integration["기존 COM 전제 통합"]
    administrator_protection["Administrator protection (preview)"]
    windows_service["Windows 서비스"]
    windows_firewall["Windows 방화벽"]
    protected_system_location -->|"전제로 한다"| admin_rights
    uac -->|"이용한다"| integrity_level
    uac -.->|"전제로 한다"| admin_rights
    installer_detection -.->|"원인이 될 수 있다"| uac
    file_registry_virtualization -->|"양립하지 않는다"| requested_execution_level
    protected_system_location -->|"사용은 비권장"| runtime_data_storage
    user_profile_storage_location -->|"권장되는 대응"| runtime_data_storage
    per_machine_install -->|"전제로 한다"| protected_system_location
    per_user_install -->|"전제로 한다"| user_profile_storage_location
    per_machine_install -->|"전제로 한다"| admin_rights
    administrator_broker_model -->|"권장되는 대응"| sporadic_admin_operation
    os_service_model -->|"권장되는 대응"| continuous_unattended_admin_operation
    elevated_task_model -->|"권장되는 대응"| short_scheduled_admin_task
    admin_com_object_model -->|"권장되는 대응"| existing_com_integration
    administrator_protection -.->|"의 후속"| uac
    installer_detection -->|"양립하지 않는다"| requested_execution_level
    windows_service -.->|"전제로 한다"| admin_rights
    windows_firewall -.->|"전제로 한다"| admin_rights
    elevated_task_model -->|"전제로 한다"| admin_rights
    administrator_broker_model -.->|"전제로 한다"| admin_rights
    os_service_model -->|"전제로 한다"| admin_rights
    admin_com_object_model -->|"전제로 한다"| admin_rights

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

2. 애초에 “관리자 권한이 필요”란 무엇인가

이 이야기에서 먼저 정리하고 싶은 것은 사용자와 프로세스를 나누어 생각하는 것입니다.

Windows의 UAC는 OS에 대한 무단 변경을 막기 위한 보안 기능입니다. Microsoft Learn에서도 관리자 수준의 사용 권한이 필요한 변경을 할 때 UAC가 알린다고 설명합니다.¹

나아가 UAC 공식 설명에서는 관리자 access token이 필요한 앱은 최종 사용자에게 동의를 구한다고 되어 있으며, 자식 프로세스는 부모 프로세스의 access token을 상속하고, 부모·자식은 같은 무결성 수준으로 동작한다고 되어 있습니다.²

여기서 알 수 있는 것은 두 가지입니다.

2.1 “관리자 사용자”여도 평소에는 내내 관리자로 동작하는 것은 아니다

Microsoft Learn에서는 UAC가 켜져 있을 때 Administrators 그룹 멤버가 시작한 프로세스도, 특별히 권한을 올리지 않는 한 표준 사용자 권한으로 실행된다고 설명합니다.⁶

이는 관리자 사용자가 로그온할 때 access token이 두 개 만들어지고, 평소에는 제한된 쪽만 쓰이기 때문입니다. 그림으로 그리면 이렇게 됩니다.²

flowchart TD
    L["관리자 사용자가 로그온"] --> S["Windows가 token을 두 개 준비한다"]
    S --> F["필터링된 token<br/>표준 사용자에 해당"]
    S --> A["완전한 관리자 token<br/>권한을 올렸을 때만 쓰인다"]
    F --> N["평소의 앱 시작<br/>탐색기도 이쪽"]
    N --> C["자식 프로세스는 부모의 token을 상속<br/>그래서 자식도 표준 사용자에 해당"]
    N --> Q{"보호 영역이나 서비스에<br/>접근하려 했는가"}
    Q -- "아니요" --> OK["그대로 실행할 수 있다"]
    Q -- "예" --> P["UAC 동의 프롬프트"]
    P --> A
    A --> E["권한을 올린 프로세스만<br/>보호 영역을 변경할 수 있다"]

그림 3: 관리자 사용자가 로그온할 때는 token이 두 개 만들어지고, 평소에는 표준 사용자에 해당하는 쪽으로 동작한다.

“관리자 사용자인데 매번 UAC가 뜬다”는 것은, 필터링된 token으로 시작한 곳에 완전한 관리자 token으로만 할 수 있는 조작이 왔기 때문입니다. token은 시작 시점에 정해지므로, 나중에 추가하려면 새 프로세스를 띄울 수밖에 없다는 점도 여기서 읽힙니다.

바꿔 말하면,

• 자기 Windows 계정은 관리자
• 하지만 지금 더블클릭해서 시작한 앱은 권한을 올리지 않은 상태
• 그래서 관리자 권한이 필요한 조작의 순간에만 UAC가 뜬다

는 것은 평범합니다.

“나는 관리자인데 왜 아직 권한이 부족한가”는 Windows에서는 아주 자연스러운 동작입니다.

2.2 같은 프로세스 안에서 “이 처리만 갑자기 관리자”는 할 수 없다

UAC는 함수 단위의 마법이 아니라, 프로세스가 어느 token으로 동작하는가의 이야기입니다. 부모·자식 프로세스는 token을 상속하므로, 권한을 올리지 않은 UI 프로세스 안에서, 어떤 버튼을 누른 순간에만 같은 프로세스 안의 일부 메서드를 관리자 권한으로 실행한다는 설계는 할 수 없습니다.²

필요하면,

• 별도 EXE로 떼어낸다
• 서비스를 쓴다
• 최고 권한 작업을 쓴다
• 권한을 올린 COM을 쓴다

같은 별도 실행 단위를 써야 합니다.¹⁴

이 전제를 모른 채 설계하면, 대체로 “이 버튼만 관리자로 실행하고 싶은데요”라는, 조금 괴로운 상담이 됩니다.

flowchart TB
    accTitle: 프로세스 안의 일부만 권한을 올릴 수는 없다
    accDescr: UAC는 프로세스가 어느 token으로 동작하는가의 이야기이고 부모·자식 프로세스는 token을 상속하므로, 권한을 올리지 않은 UI 프로세스 안에서 일부 메서드만 관리자 권한으로 실행할 수는 없으며, 필요하면 별도 EXE·서비스·최고 권한 작업·권한을 올린 COM이라는 별도 실행 단위로 나눠야 한다는 것을 나타내는 그림.
    p1["권한을 올리지 않은 UI 프로세스"] -.-> p2["일부 메서드만 관리자 권한으로 실행하는 것은 불가"]
    p1 --> p3["필요하면 별도 실행 단위로"]
    p3 --> q1["별도 EXE로 떼어낸다"]
    p3 --> q2["서비스를 쓴다"]
    q1 --> q3["최고 권한 작업을 쓴다"]
    q2 --> q4["권한을 올린 COM을 쓴다"]

그림 4: 권한 상승은 프로세스 단위이므로, 필요한 처리는 별도 실행 단위로 분리한다.

덧붙여, 여기에 든 두 가지는 오해의 온상이기도 해서, 9장의 “흔한 오해”에서도 Q&A 형태로 다시 다룹니다. 사내에서 설명할 때는 9장이 더 짧고 인용하기 쉬울 것입니다.

3. 무엇으로 정해지는가 - 우선은 구분 방법

가장 알기 쉬운 구분 방법은 다음 세 가지입니다.

1. 어디에 쓰는가
2. 누구에게 영향을 주는 변경인가
3. OS의 보호 대상에 접근하는가

3.1 쓰기에 권한 상승이 필요한 대표 영역

이후 설명의 전제가 되므로, 먼저 “여기에 쓰려고 하면 권한 상승이 필요하다”는 영역을 표로 모아 둡니다. 4장 이후에 나오는 이야기는 거의 모두 이 표의 어디에든 해당합니다.

분명히 “불필요”인 것은 마지막 한 줄뿐이고, C:\ProgramData는 조건부, 나머지는 모두 권한 상승 쪽입니다. 바꿔 말하면 앱이 쓰는 위치를 이 마지막 한 줄과 %ProgramData%로 모을 수 있는가가 권한 상승의 필요 여부를 거의 정합니다.⁴⁶⁷

flowchart TB
    accTitle: 쓰는 위치를 모을 수 있는가로 권한 상승의 필요 여부가 정해진다
    accDescr: 앱이 쓰는 위치를 자기 프로필 아래와 ProgramData로 모을 수 있으면 권한 상승 없는 설계에 가까워지고, 모이지 않고 보호 영역에 쓰면 권한 상승 쪽에 남는다는 것을 나타내는 그림.
    w1["앱이 쓰는 위치를 가려낸다"] --> j1{"프로필 아래와 ProgramData로 모을 수 있는가"}
    j1 -->|"모을 수 있다"| r1["권한 상승 없는 설계에 가까워진다"]
    j1 -->|"보호 영역에 남는다"| r2["권한 상승이 필요한 쪽에 남는다"]

그림 5: 권한 상승의 필요 여부를 거의 정하는 것은, 쓰는 위치를 어디까지 모을 수 있는가.

3.2 하고 싶은 일별 판단 표

이것을 “하고 싶은 일” 쪽에서 찾아볼 수 있게 하면 이렇게 됩니다. 판정은 필수 / 상황에 따라 / 불필요 세 가지로 맞췄습니다.

꽤 거칠게 정리하면 이렇습니다.

• 자기를 위한 변경이면 표준 사용자로 끝나기 쉽다
• 모두를 위한 변경이면 관리자가 얽히기 쉽다
• OS의 안전 쪽 경계에 접근하면 관리자가 필요

이 세 가지를 먼저 보는 것만으로 “왜 UAC가 뜨는가”는 꽤 설명하기 쉬워집니다.

flowchart TB
    accTitle: 누구를 위한 변경인가로 구분한다
    accDescr: 자기를 위한 변경이면 표준 사용자로 끝나기 쉽고, 모두를 위한 변경이면 관리자가 얽히기 쉽고, OS의 안전 쪽 경계에 접근하면 관리자가 필요하다는, 거칠지만 실무에 도움이 되는 구분 방법을 나타내는 그림.
    q1{"누구를 위한 변경인가"}
    q1 -->|"자기를 위해"| r1["표준 사용자로 끝나기 쉽다"]
    q1 -->|"모두를 위해"| r2["관리자가 얽히기 쉽다"]
    q1 -->|"OS의 안전 쪽 경계"| r3["관리자가 필요"]

그림 6: “누구를 위한 변경인가”를 먼저 보는 것만으로, UAC가 뜨는 이유는 설명하기 쉬워진다.

4. 관리자 권한이 필요해지기 쉬운 전형적인 예

4.1 모든 사용자용 설치, 업데이트, 제거

Microsoft Learn의 UAC 아키텍처 설명에서는 많은 설치 프로그램이 시스템 디렉터리나 레지스트리 키에 쓰기 때문에 표준 사용자에게는 충분한 액세스 권한이 없고, Windows는 설치 프로그램을 검출해 권한 상승을 요구한다고 되어 있습니다.³

여기서 핵심은 설치 프로그램이 “설치 프로그램이라서 대단해서”가 아니라, 쓰기 위치가 보호 영역이라서 권한 상승이 필요하다는 점입니다.

전형적으로는 이 부근입니다.

• Program Files에 배치한다
• HKLM에 machine-wide 정보를 쓴다
• 모든 사용자용 COM 등록이나 통합을 한다
• 서비스나 드라이버를 넣는다
• 머신 전체의 업데이트 경로를 가진다

이 부근은 관리자 권한이 필요해지기 쉽습니다.³⁸

flowchart TB
    accTitle: 설치 프로그램이 권한 상승을 요구하는 이유
    accDescr: 설치 프로그램이 대단해서 권한 상승이 필요한 것이 아니라, Program Files나 HKLM 같은 시스템 디렉터리나 레지스트리 키에 쓰기 때문에 표준 사용자에게는 충분한 액세스 권한이 없고, Windows가 설치 프로그램을 검출해 권한 상승을 요구한다는 것을 나타내는 그림.
    i1["많은 설치 프로그램"] --> i2["시스템 디렉터리나 레지스트리 키에 쓴다"]
    i2 --> i3["표준 사용자에게는 충분한 액세스 권한이 없다"]
    i3 --> i4["Windows가 검출해 권한 상승을 요구한다"]
    i1 -.-> i5["설치 프로그램이라서 대단한 것이 아니다"]

그림 7: 권한 상승이 필요한 것은, 설치 프로그램의 쓰기 위치가 보호 영역이기 때문이다.

4.2 실행 시 데이터를 Program Files나 HKLM에 쓴다

이것도 꽤 많습니다. Microsoft의 UAC 설계 가이드에서는 불필요한 권한 상승을 없애야 하며, 많은 오래된 소프트웨어는 HKLM / HKCR이나 Program Files / Windows System folders에 쓰기 때문에 불필요하게 관리자 권한을 필요로 한다고 설명합니다.⁴

나아가 표준 사용자에 대한 설명에서는 Program Files 폴더나 HKEY_LOCAL_MACHINE에는 쓸 수 없고, 시스템을 변경하는 처리도 할 수 없다고 명시되어 있습니다.⁶

즉,

• 설정 파일
• 로그
• 캐시
• 사용자별 상태
• 최근에 사용한 기록

같은 실행 시 바뀌는 데이터를 설치 위치 폴더나 HKLM에 두면, 그것만으로 “이 앱은 관리자로 시작하지 않으면 동작하지 않는다”가 되기 쉽습니다.

그리고 이것은 앱이 정말로 관리자용이라서가 아니라, 저장 위치 선택이 나빠진 것만으로 일어나는 경우가 드물지 않습니다.

flowchart TB
    accTitle: 실행 시 데이터를 보호 영역에 쓰면 어떻게 되는가
    accDescr: 설정 파일·로그·캐시·기록처럼 실행 시 바뀌는 데이터를 설치 위치 폴더나 HKLM에 두면 그것만으로 관리자로 시작하지 않으면 동작하지 않는 앱이 되기 쉽고, 원인은 앱이 관리자용이라서가 아니라 저장 위치 선택이라는 것을 나타내는 그림.
    d1["설정·로그·캐시·기록 등의 실행 시 데이터"] --> d2["설치 위치 폴더나 HKLM에 두어 버린다"]
    d2 --> d3["관리자로 시작하지 않으면 동작하지 않는 앱이 된다"]
    d3 -.-> d4["원인은 저장 위치 선택만인 경우가 많다"]

그림 8: “매번 관리자가 필요”의 정체는, 실행 시 데이터의 두는 위치인 경우가 많다.

4.3 Windows 서비스의 등록이나 구성 변경

서비스는 OS의 관리 대상이므로, 당연히 가볍게 건드릴 수 없습니다.

서비스 제어 관리자의 액세스 권한 공식 문서에서는 CreateService를 호출하려면 SC_MANAGER_CREATE_SERVICE가 필요하며, CreateService에 쓸 수 있는 핸들을 열 수 있는 것은 Administrator privileges를 가진 프로세스뿐이라고 설명합니다.⁸

또한 ChangeServiceConfig / ChangeServiceConfig2에 필요한 SERVICE_CHANGE_CONFIG는 시스템이 실행하는 EXE를 바꿀 수 있게 되므로, 관리자에게만 부여해야 한다고 되어 있습니다.⁸

그래서,

• 서비스를 등록한다
• 서비스의 실행 파일이나 시작 유형를 바꾼다
• 서비스를 삭제한다
• 서비스의 보안 설명자를 바꾼다

같은 처리는 관리자 권한이 전제가 됩니다.

flowchart TB
    accTitle: 서비스 조작과 관리자 권한
    accDescr: CreateService를 호출하려면 SC_MANAGER_CREATE_SERVICE가 필요하고, 그 핸들을 열 수 있는 것은 Administrator privileges를 가진 프로세스뿐이며, 구성 변경에 필요한 SERVICE_CHANGE_CONFIG도 시스템이 실행하는 EXE를 바꿀 수 있게 되므로 관리자에게만 부여해야 한다고 되어 있음을 나타내는 그림.
    s1["서비스 등록"] --> s2["SC_MANAGER_CREATE_SERVICE가 필요"]
    s2 --> s3["핸들을 열 수 있는 것은 관리자 프로세스뿐"]
    t1["서비스 구성 변경"] --> t2["SERVICE_CHANGE_CONFIG가 필요"]
    t2 --> t3["관리자에게만 부여해야 한다고 되어 있다"]

그림 9: 서비스는 OS의 관리 대상이며, 등록도 구성 변경도 관리자 권한이 전제.

4.4 커널 드라이버를 넣는다

Microsoft Learn에서는 표준 사용자는 kernel-mode driver 설치처럼 시스템을 변경하는 작업을 실행할 수 없다고 설명합니다.⁶

이것은 꽤 알기 쉬운 경계입니다. 드라이버는 커널 쪽에서 동작하므로, 평범한 “사용자 앱의 설정 저장”과 같은 줄에 둘 수 없습니다.

• 디바이스 드라이버를 도입한다
• 가상 드라이버나 필터 드라이버를 넣는다
• 부트나 I/O에 관련된 부품을 바꾼다

이런 처리는 관리자 권한이 필요하다고 보면 됩니다.

flowchart TB
    accTitle: 커널 드라이버라는 알기 쉬운 경계
    accDescr: 드라이버는 커널 쪽에서 동작하므로 평범한 사용자 앱의 설정 저장과 같은 줄에 둘 수 없고, kernel-mode driver 설치처럼 시스템을 변경하는 작업은 표준 사용자로는 실행할 수 없다는 것을 나타내는 그림.
    k1["드라이버 도입"] --> k2["커널 쪽에서 동작하는 부품을 시스템에 넣는다"]
    k2 --> k3["시스템을 변경하는 작업"]
    k3 --> k4["표준 사용자로는 실행할 수 없다"]
    k1 -.-> k5["사용자 앱의 설정 저장과는 같은 줄에 둘 수 없다"]

그림 10: 커널에 접근하는 것은, 가장 알기 쉽게 관리자 쪽 경계에 있다.

4.5 방화벽이나 높은 권한 작업의 설정

방화벽도 OS 보안 경계의 일부입니다. Microsoft Learn의 방화벽 설정 절차에서는 단일 디바이스에서 Windows Firewall with Advanced Security를 조작하려면, 그 디바이스상의 administrative rights가 필요하다고 명시되어 있습니다.⁹

또한 작업 스케줄러에 대해서는 TASK_RUNLEVEL_LUA는 최소 권한, TASK_RUNLEVEL_HIGHEST는 최고 권한으로 실행이라고 정의되어 있으며, schtasks 문서에서도 로컬 컴퓨터상의 모든 작업을 schedule / view / change하려면 Administrators 그룹 멤버여야 한다고 되어 있습니다.¹⁰

정리하면,

• Windows Firewall 규칙을 추가·변경한다
• 특정 처리를 최고 권한 작업으로 등록한다
• 다른 사용자나 SYSTEM으로 작업을 돌린다

같은 구성은 관리자 권한이 필요한 쪽에 있습니다.

flowchart TB
    accTitle: 방화벽과 높은 권한 작업
    accDescr: 방화벽 규칙 변경은 그 디바이스상의 administrative rights가 필요하고, 작업 스케줄러의 최고 권한 실행이나 모든 작업 변경도 Administrators 그룹 멤버인 것이 전제이며, 둘 다 관리자 권한이 필요한 쪽에 있다는 것을 나타내는 그림.
    f1["방화벽 규칙을 변경한다"] --> f2["그 디바이스상의 administrative rights가 필요"]
    g1["작업을 최고 권한으로 등록·실행한다"] --> g2["등록도 실행도 권한 상승이 전제"]
    f2 --> h1["OS 보안 경계의 일부로서 관리자 쪽"]
    g2 --> h1

그림 11: 방화벽도 높은 권한 작업도, OS 보안 경계로서 관리자 쪽.

5. 실은 관리자 권한 없이 끝나는 경우가 많은 전형적인 예

“Windows는 바로 관리자를 요구한다”고 보이기 쉽지만, 실제로는 관리자 권한이 필요 없는 설계로 만들 수 있는 부분이 생각보다 많습니다.

5.1 자기용 설정, 캐시, 로그

Microsoft Learn에서는 호환성을 위한 가상화에 의지하지 말고, 앱은 per-user location이거나, ACL을 올바르게 설정한 %alluserprofile% 안의 computer location에 저장해야 한다고 설명합니다.⁷

실무에서는 다음처럼 나누면 정리하기 쉽습니다.

• 사용자 고유: %AppData%, %LocalAppData%, HKCU
• 공유이지만 실행 시 갱신된다: %ProgramData% + ACL 설계
• 실행 파일 자체: Program Files 같은 보호 영역

이 분리가 되어 있으면 앱 설치는 관리자여도, 평소 이용은 비관리자로 할 수 있습니다.

flowchart TB
    accTitle: 데이터의 3분리
    accDescr: 사용자 고유 데이터는 AppData나 HKCU로, 공유이지만 실행 시 갱신되는 데이터는 ProgramData와 ACL 설계로, 실행 파일 자체는 Program Files 같은 보호 영역으로 분리되어 있으면, 설치는 관리자여도 평소 이용은 비관리자로 할 수 있다는 것을 나타내는 그림.
    z0["앱이 다루는 것"] --> z1["사용자 고유 데이터"]
    z0 --> z2["공유이지만 실행 시 갱신되는 데이터"]
    z0 --> z3["실행 파일 자체"]
    z1 --> y1["AppData / HKCU"]
    z2 --> y2["ProgramData + ACL 설계"]
    z3 --> y3["Program Files 등 보호 영역"]
    y2 -.-> y4["평소 이용은 비관리자로 할 수 있다"]

그림 12: 이 3분리가 되면, 권한 상승이 필요한 것은 설치 순간만이 된다.

5.2 per-user 설치와 업데이트

Microsoft 공식 문서에도 per-user 배치 예는 평범하게 나옵니다.

예를 들어 Remote Desktop client 문서에서는 per-user 설치는 각 사용자 프로필의 LocalAppData 아래에 설치하고, 사용자가 관리자 권한 없이 업데이트할 수 있다고 설명합니다.¹¹

또한 OneDrive 문서에서는 기본값은 per-user 설치이며, per-machine 설치는 /allusers를 붙여 명령을 실행하고, 그 결과 UAC 프롬프트가 뜬다고 되어 있습니다. 나아가 per-user는 %localappdata%, per-machine은 Program Files 아래에 들어갑니다.¹²

여기서 알 수 있는 것은 “설치”라는 단어만으로는 관리자 권한의 필요 여부가 정해지지 않는다는 점입니다.

• 각 사용자가 자기 영역에 넣으면 비관리자로 끝나는 경우가 있다
• 모든 사용자 공통 영역에 넣으면 관리자가 필요해지기 쉽다

중요한 것은 per-user인가 per-machine인가를 먼저 정하는 것입니다.

flowchart TB
    accTitle: 설치라는 말만으로는 필요 여부가 정해지지 않는다
    accDescr: 각 사용자가 자기 영역에 넣는 per-user 설치라면 비관리자로 끝나는 경우가 있고, 모든 사용자 공통 영역에 넣는 per-machine 설치라면 관리자가 필요해지기 쉬우므로, 설치라는 단어만으로는 관리자 권한의 필요 여부가 정해지지 않는다는 것을 나타내는 그림.
    i0{"어느 넣는 방식인가"}
    i0 -->|"per-user"| i1["각 사용자가 자기 영역에 넣는다"]
    i0 -->|"per-machine"| i2["모든 사용자 공통 영역에 넣는다"]
    i1 --> i3["비관리자로 끝나는 경우가 있다"]
    i2 --> i4["관리자가 필요해지기 쉽다"]

그림 13: “설치=반드시 관리자”가 아니라, per-user인가 per-machine인가로 정해진다.

5.3 보통의 UI 조작이나 업무 로직

반대로 말하면, 다음 같은 처리는 그 자체로는 관리자 권한이 필요하지 않습니다.

• 문서나 이미지를 연다
• 자기 프로필 아래의 파일을 편집한다
• HTTP 통신이나 DB 통신을 한다
• 업무 로직을 실행한다
• 화면에 결과를 표시한다
• 자기용 설정을 읽고 쓴다

그런데도 “앱 전체를 관리자 권한으로 실행”이 필요해지고 있다면, 원인은 앱의 핵심 기능이 아니라 일부 주변 처리가 보호 영역에 접근하고 있는 경우가 많습니다.

flowchart TB
    accTitle: 핵심 기능이 아니라 주변 처리가 원인
    accDescr: 문서를 열기, 업무 로직 실행, 자기용 설정 읽기·쓰기 같은 처리는 그 자체로는 관리자 권한이 필요하지 않으며, 그래도 앱 전체에 관리자 실행이 필요하면 일부 주변 처리가 보호 영역에 접근하고 있는 것이 원인인 경우가 많다는 것을 나타내는 그림.
    m1["문서를 연다·통신한다·업무 로직을 실행한다"] --> m2["그 자체는 관리자 권한이 불필요"]
    m3["그래도 앱 전체가 관리자 실행을 요구"] --> m4["일부 주변 처리가 보호 영역에 접근한다"]
    m4 -.-> m5["원인은 핵심 기능이 아니다"]

그림 14: 핵심은 평범한 처리인데 관리자가 필요하면, 의심할 것은 주변 처리의 쓰기 위치.

6. 왜 “이 앱은 관리자로”라고 말하는가

6.1 매니페스트에서 requireAdministrator를 선언하고 있다

애플리케이션 매니페스트에서는 requestedExecutionLevel로 필요한 권한 수준을 선언할 수 있습니다. Microsoft Learn에서는 다음 세 가지가 정의되어 있습니다.¹³

• asInvoker: 시작한 쪽 프로세스와 같은 권한으로 동작한다
• highestAvailable: 가능한 한 높은 권한으로 동작한다
• requireAdministrator: 관리자 권한으로 동작한다

앱이 requireAdministrator이면 시작할 때마다 권한 상승이 전제가 됩니다. highestAvailable이어도 환경에 따라서는 권한 상승이 얽힙니다.¹³

그래서 “왜 매번 UAC가 뜨는가”의 가장 솔직한 답은 그 앱이 그렇게 선언하고 있기 때문입니다.

flowchart TB
    accTitle: requestedExecutionLevel의 세 가지 선언
    accDescr: 애플리케이션 매니페스트의 requestedExecutionLevel에는 asInvoker·highestAvailable·requireAdministrator 세 가지가 있고, requireAdministrator이면 시작할 때마다 권한 상승이 전제가 되며, highestAvailable이어도 환경에 따라서는 권한 상승이 얽힌다는 것을 나타내는 그림.
    a1["매니페스트의 requestedExecutionLevel"] --> b1["asInvoker"]
    a1 --> b2["highestAvailable"]
    a1 --> b3["requireAdministrator"]
    b1 --> c1["시작한 쪽과 같은 권한"]
    b2 --> c2["환경에 따라서는 권한 상승이 얽힌다"]
    b3 --> c3["시작할 때마다 권한 상승이 전제"]

그림 15: 매번 UAC가 뜨는 가장 솔직한 이유는 매니페스트의 선언.

6.2 Windows의 installer detection에 걸려 있다

UAC 아키텍처 설명에서는 Windows에 installer detection technology가 있고, 많은 설치 프로그램은 protected system locations에 쓰기 때문에 권한 상승이 필요해진다고 설명합니다.³

게다가 이것은 단순히 setup.exe라는 이름 때문이 아니라, Windows가 어느 정도 휴리스틱으로 “이것은 설치 프로그램 같다”고 판정하고 있습니다. 공식 문서에서는 다음 조건이 나와 있습니다.³

• 32-bit 실행 파일
• requestedExecutionLevel 속성이 없음
• UAC가 켜진 표준 사용자에 의한 대화형 프로세스
• 파일 이름에 install, setup, update 같은 말을 포함, 등

그래서 SetupLauncher.exe나 Updater.exe가 갑자기 권한 상승을 요구하는 것은 Windows 쪽 설계로서 이상하지 않습니다.

flowchart TB
    accTitle: installer detection에 해당하는 조건
    accDescr: Windows의 installer detection은 32-bit 실행 파일이고 requestedExecutionLevel 속성이 없으며, UAC가 켜진 표준 사용자에 의한 대화형 프로세스이고, 파일 이름에 install이나 setup이나 update 같은 말을 포함하는 등의 조건에서 설치 프로그램 같다고 휴리스틱으로 판정해 권한 상승을 요구한다는 것을 나타내는 그림.
    c1["32-bit 실행 파일"] --> e1["설치 프로그램 같다고 판정된다"]
    c2["requestedExecutionLevel 속성이 없다"] --> e1
    c3["파일 이름에 install / setup / update 등을 포함한다"] --> e1
    e1 --> e2["권한 상승이 요구된다"]

그림 16: 이름과 속성의 조합만으로 설치 프로그램 취급을 받아 권한 상승이 요구된다.

6.3 기존 앱이 가상화로 “우연히 동작하고 있었다”

여기는 꽤 오해되기 쉽습니다.

Microsoft Learn에서는 UAC는 보호 영역에 쓰려는 비준수 앱을 위해 파일과 레지스트리 가상화를 제공한다고 설명합니다. 한편 이것은 단기적인 호환성 대책이며, 장기적인 해결책이 아니다라고도 명시되어 있습니다.³⁷

또한 가상화에는 제한이 있습니다.

• 권한을 올린 앱에는 적용되지 않는다
• 32-bit 앱에만 적용된다
• requestedExecutionLevel을 포함한 매니페스트가 있으면 무효
• 앱은 본래 올바른 저장 위치에 쓰도록 수정해야 한다

라는 조건입니다.³⁷

즉 옛 32-bit 앱이 “관리자 없이도 Program Files에 쓸 수 있었던 것처럼 보이는” 경우가 있지만, 그것은 올바르게 쓰고 있던 것이 아니라 VirtualStore로 피해 갔을 뿐일지도 모릅니다.

그래서,

• 64-bit화했다
• 매니페스트를 추가했다
• 빌드 방법을 바꿨다
• UAC 준수를 진행했다

같은 타이밍에, 이전에는 겉으로 나오지 않았던 “저장 위치 설계 실수”가 갑자기 보일 수 있습니다.

flowchart TB
    accTitle: 가상화로 "우연히 동작하고 있었다"가 겉으로 나오는 흐름
    accDescr: 보호 영역에 쓰려는 비준수 32-bit 앱은 파일과 레지스트리 가상화로 VirtualStore에 피해 가며 동작하는 것처럼 보이지만, 이것은 단기적인 호환성 대책이며, 64-bit화나 매니페스트 추가 타이밍에 가상화가 통하지 않게 되어 저장 위치 설계 실수가 갑자기 겉으로 나온다는 것을 나타내는 그림.
    v1["비준수 32-bit 앱이 보호 영역에 쓰려 한다"] --> v2["가상화가 VirtualStore로 피하게 한다"]
    v2 --> v3["올바르게 쓰지 않았는데 동작하는 것처럼 보인다"]
    v3 --> v4["64-bit화나 매니페스트 추가로 가상화가 통하지 않게 된다"]
    v4 --> v5["저장 위치 설계 실수가 갑자기 겉으로 나온다"]

그림 17: 가상화는 잠정 대책이므로, 환경이 바뀐 순간에 설계 실수가 보인다.

6.4 애초에 실행 시 접근하는 위치가 좋지 않다

실무에서는 결국 이것이 가장 많습니다.

• 설정을 EXE 옆에 저장한다
• 로그를 설치 위치에 기록한다
• 임시 파일을 Program Files 아래에 만든다
• 사용자별 상태를 HKLM에 쓴다

이런 구성으로 하면 앱은 평범한 UI인데 시작에 관리자 권한이 필요하다는, 꽤 다루기 어려운 형태가 됩니다.⁴⁶

“그 처리가 복잡해서 관리자”가 아니라 저장 위치가 나빠서 관리자인 경우는 정말 많습니다.

6.5 자기 앱이 어디에 해당하는지를 조사하는 절차

6.1부터 6.4는 “원인의 형”이지만, 실제 조사에서는 자기 앱이 어디에 해당하는가를 확인할 필요가 있습니다. 순서는 이 두 가지면 충분합니다.

절차 1: 매니페스트의 requestedExecutionLevel을 본다

먼저 그 앱이 스스로 권한 상승을 선언하지 않았는지를 확인합니다. EXE에 임베드된 매니페스트는 Windows SDK의 mt.exe로 꺼낼 수 있습니다.

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1은 실행 파일에 임베드되는 매니페스트의 리소스 ID입니다. 꺼낸 XML 안에 다음 같은 행이 있는지를 봅니다.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

requireAdministrator이면 원인은 6.1로 확정입니다. asInvoker이면 선언에서 온 것이 아니므로 절차 2로 갑니다. 매니페스트 자체가 임베드되어 있지 않은 경우도 있습니다. 이것도 중요한 정보이며, requestedExecutionLevel이 없는 32bit 실행 파일은 6.2의 installer detection과 6.3의 가상화 양쪽에 해당할 수 있습니다.³

절차 2: VirtualStore에 복제가 생기지 않았는지를 본다

다음으로, 보호 영역에 썼다고 생각한 파일이 실은 가상화되지 않았는지를 봅니다. 리디렉트 위치는 정해져 있습니다.

dir /s /a "%LocalAppData%\VirtualStore"

여기에 자기 앱의 설정 파일이나 로그가 늘어서 있으면, 그 앱은 Program Files에 쓰고 있던 것이 아니라, 사용자별 복제로 피해 가고 있던 것입니다. 예를 들어 C:\Program Files\Contoso\Settings.ini에 대한 쓰기는 %LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini로 바뀝니다.³

레지스트리 쪽 가상화 위치도 같으며, HKEY_LOCAL_MACHINE\Software에 대한 쓰기는 HKEY_USERS\<사용자의 SID>_Classes\VirtualStore\Machine\Software로 바뀝니다. 현재 사용자에서 보려면 레지스트리 편집기에서 HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software를 열면 같은 것이 보입니다.⁷

이 두 가지를 보면 “관리자 권한이 필요”의 원인이 선언인가, 저장 위치인가가 분명해집니다. 원인이 저장 위치이면 7.3대로 두는 위치를 고치는 것이 정석이고, 권한 상승을 추가하는 것은 해결책이 되지 않습니다.

flowchart TB
    accTitle: 원인을 확인하는 두 절차
    accDescr: 먼저 mt.exe로 EXE에 임베드된 매니페스트를 꺼내 requestedExecutionLevel을 보고, requireAdministrator이면 선언에서 온 것으로 확정하며, asInvoker이면 VirtualStore에 자기 앱의 복제가 생겼는지를 확인하고, 복제가 있으면 저장 위치 문제이므로 두는 위치를 고치는 것이 정석이라는 것을 나타내는 그림.
    s1["절차 1: 매니페스트의 requestedExecutionLevel을 본다"] --> j1{"무엇이 선언되어 있는가"}
    j1 -->|"requireAdministrator"| r1["원인은 선언으로 확정"]
    j1 -->|"asInvoker나 선언 없음"| s2["절차 2: VirtualStore의 복제를 확인한다"]
    s2 -->|"복제가 있다"| r2["원인은 저장 위치"]
    r2 --> r3["두는 위치를 고치는 것이 정석 (권한 상승을 추가하는 것은 해결책이 아니다)"]

그림 18: 선언인가 저장 위치인가, 두 절차의 확인으로 원인은 분명히 갈린다.

7. 어떻게 설계하면 불필요한 권한 상승을 줄일 수 있는가

7.1 기본은 asInvoker

앱 전체가 정말로 시스템 관리 도구가 아닌 한, 기본은 보통의 UI 앱을 권한을 올리지 않은 채로 동작시키는 것입니다. 매니페스트의 의미로도 asInvoker는 “시작한 쪽과 같은 권한으로 동작한다”는 선언입니다.¹³

평소의 화면 조작, 업무 로직, 사용자별 설정 저장까지 전부 관리자로 돌리면,

• 공격 표면이 넓어진다
• 운영 설명이 어렵다
• 매번 UAC가 뜬다
• “정말은 어느 처리에 관리자가 필요한가”가 안 보이게 된다

는 문제가 늘어납니다. Microsoft의 UAC 설계 가이드도 불필요한 권한 상승을 없애고, 관리자 권한이 필요한 것은 정말로 필요한 작업만으로 해야 한다고 설명합니다.⁴

flowchart TB
    accTitle: 전부를 관리자로 돌리면 늘어나는 문제
    accDescr: 평소의 화면 조작이나 업무 로직까지 전부를 관리자로 돌리면 공격 표면이 넓어지고, 운영 설명이 어려워지며, 매번 UAC가 뜨고, 정말은 어느 처리에 관리자가 필요한지가 안 보이게 되므로, 기본은 보통의 UI 앱을 권한을 올리지 않은 채로 동작시키는 것임을 나타내는 그림.
    a1["전부를 관리자로 돌린다"] --> b1["공격 표면이 넓어진다"]
    a1 --> b2["매번 UAC가 뜬다"]
    b1 --> b3["운영 설명이 어렵다"]
    b2 --> b4["정말로 필요한 처리가 안 보이게 된다"]
    b3 --> c1["기본은 asInvoker로 권한을 올리지 않은 채 유지한다"]
    b4 --> c1

그림 19: 기본은 asInvoker로, 권한 상승은 정말로 필요한 작업에만 좁힌다.

7.2 관리자가 필요한 처리만 별도 실행 단위로 나눈다

Microsoft Learn에는 관리자 권한이 필요한 처리를 가진 앱이어도, 표준 사용자 앱으로 동작시키면서 필요 부분만 분리하는 모델이 명시되어 있습니다.¹⁴

대표적으로는 다음 네 가지입니다.

• Administrator Broker Model 표준 사용자의 UI 앱 + 관리자 helper EXE
• Operating System Service Model 표준 사용자 UI + 상주 service
• Elevated Task Model 표준 사용자 UI + 최고 권한의 예약된 작업
• Administrator COM Object Model 표준 사용자 UI + 권한을 올린 COM

대략적인 쓰임새는 이렇습니다.

• 가끔만 관리자 조작이 필요하면 helper EXE
• 상시·무인·빈번이면 service
• 짧은 반복 작업이면 highest task
• 기존 COM 전제이면 권한을 올린 COM

Windows 앱에서 이 설계를 구체화하는 이야기는 별도 글의 Windows 앱에서 “관리자 권한이 필요한 처리만”을 분리하는 구체적인 작성법 에서도 자세히 다룹니다.

flowchart TB
    accTitle: 네 가지 분리 모델의 쓰임새
    accDescr: 표준 사용자 앱으로 동작시키면서 관리자 처리만 분리하는 모델로서, 가끔만 관리자 조작이 필요하면 Administrator Broker Model의 helper EXE, 상시·무인·빈번이면 서비스, 짧은 반복 작업이면 최고 권한 작업, 기존 COM 전제이면 권한을 올린 COM이라는 쓰임새를 나타내는 그림.
    q1{"관리자 조작의 성질은"}
    q1 -->|"가끔만"| m1["helper EXE (Broker Model)"]
    q1 -->|"상시·무인·빈번"| m2["서비스"]
    m1 --> m3["짧은 반복 작업이면 최고 권한 작업"]
    m2 --> m4["기존 COM 전제이면 권한을 올린 COM"]

그림 20: 분리 모델은 네 가지가 있으며, 관리자 조작의 빈도와 형태로 고른다.

7.3 실행 시 데이터의 두는 위치를 바로잡는다

저장 위치의 원칙은 꽤 단순합니다.

• 사용자 고유 데이터는 HKCU나 %AppData%
• 로컬 전용 캐시는 %LocalAppData%
• 공유이지만 실행 시 바뀌는 데이터는 %ProgramData% + ACL
• 실행 파일 자체는 Program Files

Microsoft Learn에서도 앱은 per-user location이거나, ACL을 올바르게 설정한 %alluserprofile%(실체는 ProgramData)에 저장해야 한다고 설명합니다.⁷

이 정리를 하면 설치 프로그램만 권한을 올리고, 실행 중 앱은 권한을 올리지 않은 채로 두기 쉬워집니다.

flowchart TB
    accTitle: 두는 위치를 바로잡으면 권한 상승을 좁힐 수 있다
    accDescr: 사용자 고유 데이터는 HKCU나 AppData로, 로컬 전용 캐시는 LocalAppData로, 공유이지만 실행 시 바뀌는 데이터는 ProgramData와 ACL로, 실행 파일 자체는 Program Files로라는 원칙으로 정리하면, 설치 프로그램만 권한을 올리고 실행 중 앱은 권한을 올리지 않은 채로 두기 쉬워진다는 것을 나타내는 그림.
    p1["실행 시 데이터의 두는 위치를 원칙대로 정리한다"] --> p2["권한 상승이 필요한 것은 실행 파일 배치뿐"]
    p2 --> p3["설치 프로그램만 권한을 올린다"]
    p2 --> p4["실행 중 앱은 권한을 올리지 않는다"]

그림 21: 두는 위치의 정리는, 권한 상승을 설치 순간에 가두기 위한 토대.

7.4 per-user와 per-machine을 먼저 정한다

의외로 놓치기 쉬운 곳이 여기입니다.

• 그 앱은 각 사용자가 스스로 넣을 수 있어야 하는가
• 모든 사용자 공통의 한곳에 넣어야 하는가
• 업데이트는 누가 책임을 지는가
• 실행 파일을 사용자 프로필에서 돌려도 되는가

이 판단이 애매하면 나중에,

• 설치만 관리자
• 실행도 관리자
• 업데이트도 관리자
• 일부만 user context

처럼 뒤섞이기 쉽습니다.

per-user / per-machine의 차이는 단순히 배포 방식의 이야기가 아니라 권한 설계 그 자체입니다.

flowchart TB
    accTitle: per-user / per-machine을 먼저 정한다
    accDescr: 각 사용자가 스스로 넣을 수 있어야 하는가, 모든 사용자 공통의 한곳에 넣어야 하는가, 업데이트는 누가 책임을 지는가라는 판단을 먼저 하지 않으면 설치·실행·업데이트의 권한이 제각각이 되기 쉽고, per-user와 per-machine의 차이는 배포 방식이 아니라 권한 설계 그 자체임을 나타내는 그림.
    d1["per-user / per-machine을 먼저 정한다"] -->|"정한 경우"| d2["설치·실행·업데이트의 권한이 맞춰진다"]
    d1 -.->|"애매한 채로 가면"| d3["일부만 관리자·일부만 user context로 뒤섞인다"]
    d2 --> d4["배포 방식이 아니라 권한 설계 그 자체"]

그림 22: per-user / per-machine 판단은, 처음에 정하는 권한 설계.

8. 앞으로의 Windows는 어디로 향하고 있는가

2026년 3월 시점에 Windows 11에는 Administrator protection (preview)이라는 기능이 있습니다. Microsoft Learn에서는 이 기능을 평소에는 deprivileged state를 유지하고, 필요할 때만 just-in-time으로 admin rights를 준다고 설명합니다.⁵

나아가 Microsoft는 소프트웨어 설치, 시각이나 레지스트리 같은 시스템 설정 변경, 민감 데이터에 대한 액세스 같은 관리자 권한이 필요한 조작 전에 명시적 인증을 요구한다고 설명합니다.⁵

이 기능 자체는 아직 preview이고, 일반 제공도 단계적입니다.⁵

여기서 preview인 것의 실무상 의미도 잡아 두고 싶습니다. preview 표기가 붙은 기능은 일반 제공까지 동작이나 설정 항목이 바뀔 수 있고, 애초에 모든 환경에서 켤 수 있다고는 할 수 없습니다. 따라서 현시점에서는 다음 같은 쓰임은 피하는 편이 안전합니다.

• 운영의 표준 구성으로 전사에 배포한다
• 이 기능이 켜져 있다는 전제로 앱 쪽 권한 상승 설계를 생략한다
• 고객 환경의 동작 요건으로 이 기능을 필수로 한다

현실적인 위치는 검증 환경에서 동작을 확인해 두고, “장차 이쪽으로 기운다”는 전제로 설계만 맞춰 두는 것입니다. 바꿔 말하면, 지금 asInvoker를 기본으로 권한 상승을 최소화해 두면, 이 기능이 일반 제공이 되었을 때 허둥대지 않아도 됩니다.

flowchart TB
    accTitle: preview 기능에 대한 현실적인 위치
    accDescr: preview 표기 기능은 일반 제공까지 동작이나 설정이 바뀔 수 있으므로, 운영 표준 구성으로 배포하거나, 켜져 있다는 전제로 권한 상승 설계를 생략하거나, 고객 환경의 동작 요건으로 삼는 것은 피하고, 검증 환경에서 동작을 확인하면서 장차 이쪽으로 기운다는 전제로 설계만 맞춰 두는 것이 현실적이라는 것을 나타내는 그림.
    p1["Administrator protection은 preview"] -.-> p2["운영 표준 구성으로 전사에 배포하거나 필수로 지정하는 것은 피한다"]
    p1 --> p3["검증 환경에서 동작을 확인해 둔다"]
    p3 --> p4["장차 이쪽으로 기운다는 전제로 설계만 맞춘다"]
    p4 --> p5["asInvoker 기본으로 권한 상승을 최소화해 두면 허둥대지 않는다"]

그림 23: preview 기능은 전제로 두지 않고, 설계의 방향만 맞춰 둔다.

다만 방향성으로는 꽤 분명합니다.

• 상시 관리자 token을 들고 있지 않는다
• 필요한 순간에만 권한을 올린다
• 권한을 올린 세션을 분리한다
• “언제, 어느 앱이, 왜 관리자가 됐는가”를 더 분명히 한다

즉 “일단 전부를 관리자로 돌리는” 설계는 앞으로 점점 궁합이 나빠진다고 봐도 됩니다.

flowchart TB
    accTitle: Windows가 향하고 있는 방향
    accDescr: 상시 관리자 token을 들고 있지 않고, 필요한 순간에만 권한을 올리며, 권한을 올린 세션을 분리하고, 언제 어느 앱이 왜 관리자가 됐는가를 더 분명히 하는 방향으로 Windows는 기울고 있으며, 일단 전부를 관리자로 돌리는 설계는 앞으로 점점 궁합이 나빠진다는 것을 나타내는 그림.
    w1["상시 관리자 token을 들고 있지 않는다"] --> w2["필요한 순간에만 권한을 올린다"]
    w2 --> w3["권한을 올린 세션을 분리한다"]
    w3 --> w4["언제·어느 앱이·왜 관리자인가를 분명히 한다"]
    w4 -.-> w5["전부를 관리자로 돌리는 설계는 궁합이 나빠진다"]

그림 24: 방향성은 분명하고, 권한 상승은 “필요한 순간에만·명시적으로”로 기울고 있다.

9. 흔한 오해

9.1 “나는 관리자 사용자니까 UAC는 안 뜰 것이다”

뜹니다. UAC가 켜져 있으면 Administrators 그룹 멤버여도 보통 프로세스는 권한을 올리지 않은 채로 동작하고, 필요할 때만 권한을 올립니다.⁶²

9.2 “설치라면 반드시 관리자”

반드시는 아닙니다. %LocalAppData%에 넣는 per-user 설치처럼, 관리자 권한 없이 배포할 수 있는 설계가 있습니다.¹¹¹²

9.3 “Program Files에 두니까 설정도 거기에 저장해도 된다”

안 됩니다. 실행 파일의 배치 위치와 실행 시 바뀌는 데이터의 저장 위치는 나눠야 합니다. Microsoft도 Program Files나 HKLM에 대한 실행 시 쓰기를 불필요한 권한 상승의 전형적인 예로 듭니다.⁴⁷

9.4 “관리자 권한으로 실행하기만 하면 설계 문제는 전부 해결된다”

해결되지 않습니다. 일시적으로 동작하는 경우는 있어도 공격 표면, 운영성, 배포, 지원의 용이성은 나빠지기 쉽습니다. 게다가 같은 프로세스 안의 일부만 편리하게 권한을 올릴 수도 없습니다.²¹⁴

9.5 “예전에는 동작했으니까 지금도 올바르다”

그렇다고는 할 수 없습니다. 기존의 32-bit 앱이 가상화로 “우연히 동작하고 있었을” 뿐이라면, 64-bit화나 매니페스트 추가로 문제가 겉으로 나옵니다. 가상화는 호환성을 위한 잠정 대책이며 장기 해답이 아닙니다.³⁷

10. 정리

Windows의 관리자 권한이 필요한지는 한 마디로 “어디에 무엇을 바꾸러 가는가”로 정해집니다.

• 자기를 위한 변경이면 표준 사용자로 끝나기 쉽다
• 모든 사용자·머신 전체의 변경이면 관리자가 필요해지기 쉽다
• OS의 보호 영역이나 보안 경계에 접근하면 관리자 권한이 필요

그리고 실무에서 정말로 중요한 것은 정말로 관리자 권한이 필요한 처리와 단지 저장 위치 사정으로 관리자가 필요해져 있는 처리를 나누는 것입니다.

특히 Windows 앱 개발에서는 다음 선이 꽤 유효합니다.

• UI는 권한을 올리지 않은 것을 기본으로 한다
• 관리자 처리는 별도 EXE / service / task로 자른다
• 실행 시 데이터는 AppData / HKCU / ProgramData 쪽으로 모은다
• per-user / per-machine을 처음에 정한다

flowchart TB
    accTitle: Windows 앱 개발에서 유효한 선 긋기
    accDescr: UI는 권한을 올리지 않은 것을 기본으로 하고, 관리자 처리는 별도 EXE나 서비스나 작업으로 자르며, 실행 시 데이터는 AppData나 HKCU나 ProgramData 쪽으로 모으고, per-user인가 per-machine인가를 처음에 정한다는, 실무에서 유효한 선 긋기를 나타내는 그림.
    g1["UI는 권한을 올리지 않은 것을 기본으로 한다"] --> g2["관리자 처리는 별도 EXE / 서비스 / 작업으로 자른다"]
    g2 --> g3["실행 시 데이터는 AppData / HKCU / ProgramData로 모은다"]
    g3 --> g4["per-user / per-machine을 처음에 정한다"]

그림 25: 이 네 줄을 처음에 그어 두면, UAC도 배포도 설계도 전망이 좋아진다.

“관리자 권한이 필요한가”는 앱이 훌륭한가의 이야기가 아닙니다. OS의 어느 경계에 접근하고 있는가의 이야기입니다.

이 관점을 먼저 가지고 있으면 UAC의 동작도, 설치 방식의 선정도, 앱 설계도 한결 정리하기 쉬워집니다.

11. 관련 글

• Windows 앱에서 “관리자 권한이 필요한 처리만”을 분리하는 구체적인 작성법
• Windows 앱 개발에서 최소한의 보안을 지키기 위한 체크리스트
• Windows 앱 배포 방식 고르기 - MSI/MSIX/ClickOnce/xcopy/자체 updater

12. 참고 자료

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

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

"요청한 작업에는 관리자 권한이 필요합니다"라고 표시되는 이유는 무엇인가요?

그 앱이 OS나 머신 전체에 영향을 주는 경계에 접근하려 하기 때문입니다. 전형적으로는 Program Files, Windows, System32, HKLM 같은 보호 영역에 쓰기, Windows 서비스 등록·구성 변경, 커널 드라이버 도입, 방화벽 규칙 변경 등입니다. 앱 매니페스트에서 requireAdministrator를 선언한 경우나, 파일 이름에 install / setup / update 등을 포함해 Windows의 installer detection에 걸린 경우에도 권한 상승이 요구됩니다. 처리가 복잡해서가 아니라, 설정이나 로그 저장 위치가 보호 영역인 것만으로 일어나는 경우도 매우 많습니다.

관리자 계정인데도 UAC가 뜨는 이유는 무엇인가요?

UAC가 켜져 있으면 Administrators 그룹 멤버가 시작한 프로세스도, 특별히 권한을 올리지 않는 한 표준 사용자 권한으로 실행되기 때문입니다. Windows 계정이 관리자여도 지금 시작한 앱은 권한을 올리지 않은 채 동작하며, 관리자 권한이 필요한 조작의 순간에만 UAC가 뜨는 것은 Windows에서는 아주 자연스러운 동작입니다. 사용자가 Administrators 그룹에 속해 있는 것과, 그 앱이 관리자 access token으로 동작하는 것은 별개로 생각해야 합니다.

앱 설치에는 반드시 관리자 권한이 필요한가요?

반드시는 아닙니다. %LocalAppData% 아래에 넣는 per-user 설치라면, 관리자 권한 없이 배포·업데이트할 수 있는 설계가 있습니다. 실례로 Remote Desktop client의 per-user 설치는 각 사용자 프로필의 LocalAppData 아래에 들어가 관리자 권한 없이 업데이트할 수 있고, OneDrive도 기본값은 per-user 설치입니다. 관리자가 필요해지기 쉬운 것은 Program Files나 HKLM에 쓰는 모든 사용자용(per-machine) 설치입니다. per-user인지 per-machine인지는 배포 방식의 이야기가 아니라 권한 설계 그 자체이므로, 먼저 정해야 합니다.

앱의 일부 처리만 관리자 권한으로 실행할 수 있나요?

같은 프로세스 안에서 "이 버튼을 누른 순간에만 일부 메서드를 관리자 권한으로 실행한다"는 일은 할 수 없습니다. UAC는 프로세스가 어느 token으로 동작하는가의 이야기이고, 부모·자식 프로세스는 token을 상속하기 때문입니다. 필요하면 별도 실행 단위로 분리합니다. 대표적인 모델은 표준 사용자 UI와 관리자 helper EXE를 조합하는 Administrator Broker Model, 상주 서비스를 쓰는 Operating System Service Model, 최고 권한의 예약된 작업을 쓰는 Elevated Task Model, 권한을 올린 COM을 쓰는 Administrator COM Object Model 네 가지입니다.

저자 프로필

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

Go Komura

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

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