Windows의 관리자 특권이 필요해지는 것은 언제인가 - UAC, 보호 영역, 설계상의 구분 방법

Windows 주변의 상담에서 꽤 자주 섞이는 이야기가 있습니다.

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

이 이야기는 단순히 「그 사람이 관리자인가 아닌가」만으로는 정해지지 않습니다.
실제로는 어디에 쓰는가, 누구에게 영향을 주는 변경인가, OS의 어느 보호 대상에 건드리는가로 꽤 정해집니다.

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

1. 먼저 결론

먼저 결론만 나열하면 실무에서는 대체로 다음입니다.

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

요컨대 「관리자 특권이 필요한가」는 이용자의 직함이 아니라 앱이 건드리는 경계로 정해진다고 보는 것이 가장 실무적입니다.

2. 애초에 「관리자 특권이 필요」란 무엇인가

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

Windows의 UAC는 OS에 대한 부정한 변경을 막기 위한 보안 기능입니다. Microsoft Learn에서도 관리자 수준의 액세스 허가가 필요한 변경을 할 때 UAC가 통지한다고 설명되어 있습니다.¹

또한 UAC의 공식 설명에서는 관리자 액세스 토큰이 필요한 앱은 엔드유저에게 동의를 요구한다고 되어 있으며, 자식 프로세스는 부모 프로세스의 액세스 토큰을 상속하고, 부모-자식은 같은 무결성 레벨로 돈다고 되어 있습니다.²

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

2.1 「관리자 사용자」여도 평소에는 계속 관리자로 돌고 있는 것은 아니다

Microsoft Learn에서는 UAC 유효 시에는 Administrators 그룹의 멤버가 기동한 프로세스도 특별히 승격하지 않는 한 표준 사용자 권한으로 실행된다고 설명되어 있습니다.⁶

즉,

• 자기 Windows 계정은 관리자
• 하지만 지금 더블 클릭해 기동한 앱은 비승격
• 그래서 관리자 특권이 필요한 조작의 순간에만 UAC가 나온다

는 것은 평범합니다.

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

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

UAC는 함수 단위의 마법이 아니라 프로세스가 어느 토큰으로 돌고 있는가의 이야기입니다.
부모·자식 프로세스는 토큰을 상속하므로 비승격의 UI 프로세스 안에서 어떤 버튼을 누른 순간에만 같은 프로세스 내의 일부 메서드를 관리자화하는 설계는 할 수 없습니다.²

필요하다면,

• 별도 EXE로 떼어낸다
• 서비스를 쓴다
• 최고 권한 태스크를 쓴다
• 승격 COM을 쓴다

같은 별도의 실행 단위를 쓸 필요가 있습니다.¹⁴

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

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

가장 이해하기 쉬운 구분 방법은 다음 3가지입니다.

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

대략 판단표로 만들면 이런 느낌입니다.

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

• 자기를 위한 변경이라면 표준 사용자로 끝나기 쉽다
• 전원을 위한 변경이라면 관리자가 얽히기 쉽다
• OS의 안전 쪽 경계에 건드린다면 관리자가 필요

이 3가지를 먼저 보는 것만으로도 「왜 UAC가 나오는가」는 꽤 설명하기 쉬워집니다.

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

4.1 전 사용자용의 인스톨, 갱신, 언인스톨

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

여기서 포인트는 인스톨러가 「인스톨러라서 대단한」 것이 아니라 쓰기 대상이 보호 영역이어서 승격이 필요하다는 것입니다.

예를 들어 다음 같은 경우입니다.

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

이쯤은 관리자 특권이 필요해지기 쉽습니다.³⁸

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

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

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

즉,

• 설정 파일
• 로그
• 캐시
• 사용자별 상태
• 최근 사용한 이력

같은 실행 시에 변하는 데이터를 인스톨 대상 폴더나 HKLM에 두면, 그것만으로 「이 앱은 관리자로 기동하지 않으면 동작하지 않는다」가 되기 쉽습니다.

그리고 이것은 앱이 정말로 관리자용이라서가 아니라 저장 장소의 선택이 나빠서 일어나는 경우가 꽤 있습니다.

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

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

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

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

그래서,

• 서비스를 등록한다
• 서비스의 실행 파일이나 기동 종별을 바꾼다
• 서비스를 삭제한다
• 서비스의 보안 기술자를 바꾼다

같은 처리는 관리자 특권이 필요해지기 쉽습니다.

4.4 커널 드라이버를 넣는다

Microsoft Learn에서는 표준 사용자는 kernel-mode driver의 인스톨 같은, 시스템을 변경하는 태스크를 실행할 수 없다고 설명되어 있습니다.⁶

이것은 꽤 이해하기 쉬운 경계입니다.
드라이버는 커널 쪽에서 돌므로 평범한 「사용자 앱의 설정 저장」과 동렬로 다룰 수 없습니다.

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

이런 처리는 관리자 특권이 필요하다고 생각해도 됩니다.

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에서 잡을 돌린다

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

5. 실은 관리자 특권이 불필요로 끝나는 전형 예

「Windows는 바로 관리자를 요구한다」고 보이기 쉽지만, 실제로는 관리자 특권이 불필요한 설계로 할 수 있는 부분도 꽤 많습니다.

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

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

실무적으로는 다음처럼 나누면 정리하기 쉽습니다.

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

이 분리가 되어 있으면 앱 본체의 인스톨은 관리자여도 평소의 이용은 비관리자로 할 수 있습니다.

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인가를 먼저 정하는 것입니다.

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

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

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

그런데도 「앱 전체를 관리자로서 실행」이 필요해지고 있다면, 원인은 앱의 본체 기능이 아니라 일부 주변 처리가 보호 영역에 건드리고 있는 경우가 많습니다.

6. 왜 「이 앱은 관리자로」라고 말해지는가

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

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

• asInvoker: 기동 원 프로세스와 같은 권한으로 돈다
• highestAvailable: 가능한 한 높은 권한으로 돈다
• requireAdministrator: 관리자 권한으로 돈다

만약 앱이 requireAdministrator로 되어 있다면, 기동할 때마다 승격이 전제가 됩니다.
highestAvailable이어도 환경에 따라서는 승격이 얽힙니다.¹³

그래서 「왜 매번 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 쪽의 설계로서 이상하지 않습니다.

6.3 구래 앱이 가상화로 「우연히 동작하고 있었다」

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

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

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

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

라는 조건입니다.³⁷

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

그래서,

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

같은 타이밍에 이전에는 표면화되지 않았던 「저장 대상의 설계 실수」가 갑자기 보일 수 있습니다.

6.4 애초에 실행 시에 건드리는 장소가 좋지 않다

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

• 설정을 EXE의 옆에 저장한다
• 로그를 인스톨 대상에 뱉는다
• 임시 파일을 Program Files 아래에 만든다
• 사용자별 상태를 HKLM에 쓴다

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

「그 처리가 고도여서 관리자」가 아니라 저장 대상이 나빠서 관리자인 경우는 정말 많습니다.

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

7.1 기본은 asInvoker

앱 전체가 정말로 시스템 관리 도구가 아닌 한, 기본선은 통상의 UI 앱을 비승격으로 돌리는 것입니다.
매니페스트의 의미로서도 asInvoker는 「기동 원과 같은 권한으로 돈다」는 선언입니다.¹³

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

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

는 문제가 늘어납니다. Microsoft의 UAC 설계 가이드도 불필요한 승격을 없애고, 관리자 특권이 필요한 것은 정말로 필요한 태스크만으로 해야 한다고 설명하고 있습니다.⁴

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

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

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

• 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 앱에서 「관리자 권한이 필요한 처리만」을 분리하는 구체적인 작성 방법
에서도 자세히 다루고 있습니다.

7.3 실행 시 데이터의 둘 장소를 바로잡는다

저장 대상의 원칙은 꽤 단순합니다.

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

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

이 정리를 하면 인스톨러만 승격하고 실행 중 앱은 비승격으로 하기 쉬워집니다.

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

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

• 그 앱은 각 사용자가 스스로 넣을 수 있어야 하는가
• 전 사용자 공통의 1곳에 넣어야 하는가
• 갱신은 누가 책임을 지는가
• 실행 파일을 사용자 프로파일에서 움직여도 되는가

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

• 인스톨만 관리자
• 실행도 관리자
• 갱신도 관리자
• 일부만 user context

처럼 엉망이 되기 쉽습니다.

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

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

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

또한 Microsoft는 소프트웨어의 인스톨, 시각이나 레지스트리 같은 시스템 설정의 변경, 기미 데이터에의 액세스 같은 관리자 특권이 필요한 조작 전에 명시적인 인증을 요구한다고 설명하고 있습니다.⁵

이 기능 자체는 아직 preview이고, 일반 전개도 단계적입니다.⁵
다만 방향성으로는 꽤 분명합니다.

• 상시 관리자 토큰을 가지고 있지 않는다
• 필요한 순간에만 승격한다
• 승격한 세션을 분리한다
• 「언제, 어느 앱이, 왜 관리자가 됐는가」를 보다 분명히 한다

즉, 「일단 전부 관리자로 돌리는」 설계는 앞으로 점점 상성이 나빠진다고 봐도 됩니다.

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을 먼저 정한다

「관리자 특권이 필요한가」는 앱이 훌륭한가 아닌가의 이야기가 아닙니다.
OS의 어느 경계에 건드리고 있는가의 이야기입니다.

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

11. 관련 기사

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

12. 참고 자료

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

저자 프로필

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

Go Komura

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

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