Microsoft Windows

Windows 제품군은 하나의 연속된 운영체제 계보로만 구성되지 않는다. 초기 개인용 컴퓨터용 Windows는 MS-DOS 위에서 실행되는 그래픽 운영 환경으로 시작했으며, 이후 Windows 9x 계열로 발전했다. 이와 별도로 Microsoft는 기업용·서버용 운영체제로 Windows NT를 개발했고, Windows XP 이후 개인용 컴퓨터용 Windows도 NT 계열로 통합했다.

소형 컴퓨터와 임베디드 장치를 위해서는 데스크톱 Windows와 별개의 Windows CE 계열이 개발되었다. 휴대기기용 Windows Mobile과 초기 Windows Phone은 Windows CE를 기반으로 했지만, Windows Phone 8부터는 Windows NT 계열의 커널과 구성 요소를 사용했다. 따라서 제품의 용도만이 아니라 기반 운영체제와 계보를 함께 기준으로 구분해야 한다.

Windows 제품군

MS-DOSMS-DOS 커널	Windows 1.0 · Windows 2.0 · Windows 2.1x · Windows 3.0 · Windows 3.1x
	Windows 9x	Windows 95 · Windows 98 · Windows Me
Windows NTNT 커널	Windows NT 3.1 · Windows NT 3.5 · Windows NT 3.51 · Windows NT 4.0 · Windows 2000
	클라이언트 Windows	Windows XP · Windows Vista · Windows 7 · Windows 8 · Windows 8.1 · Windows 10 · Windows 11
	Windows Server	Windows NT Server · Windows 2000 Server · Windows Server 2003 · Windows Server 2008 · Windows Server 2012 · Windows Server 2016 · Windows Server 2019 · Windows Server 2022 · Windows Server 2025
	NT 기반 임베디드 Windows	Windows NT Embedded · Windows XP Embedded · Windows Embedded Standard · Windows Embedded Industry · Windows IoT
	NT 기반 모바일 Windows	Windows Phone 8 · Windows Phone 8.1 · Windows 10 Mobile
	특수 장치용 Windows	Windows Holographic · Windows Team
Windows CECE 커널	Windows CE 1.0 · Windows CE 2.0 · Windows CE 3.0 · Windows CE 4.0 · Windows CE 5.0 · Windows Embedded CE 6.0 · Windows Embedded Compact 7 · Windows Embedded Compact 2013
	휴대용 장치 플랫폼	Handheld PC · Palm-size PC · Pocket PC · Windows Mobile
	CE 기반 Windows Phone	Windows Phone 7 · Windows Phone 7.5
기타 Windows 파생 환경	Windows PE · Windows Recovery Environment · Windows Preinstallation Environment · Windows Sandbox

이 분류에서 Windows PE와 Windows 복구 환경은 독립적인 범용 운영체제 제품군이라기보다 Windows를 설치하고 복구하기 위한 경량 실행 환경이다. Windows Sandbox 역시 별도의 계보가 아니라 Windows NT 기반 클라이언트 안에서 격리된 일회용 환경을 제공하는 기능이다. 따라서 이들은 역사적 계보와 구별하여 보조·파생 환경으로 분류한다.

Windows는 Microsoft가 개발한 운영체제와 그 제품군을 가리키는 명칭이다. 정식 브랜드명은 Microsoft Windows이지만, 일반적으로는 회사명을 생략한 Windows가 사용된다. 개별 제품은 Windows 95, Windows XP, Windows 10, Windows 11, Windows Server 2025처럼 Windows 뒤에 버전명, 출시 연도, 용도 또는 제품군 이름을 붙여 구분한다.

Windows라는 이름은 응용 프로그램을 화면 위의 여러 창으로 표시하고 조작하는 그래픽 사용자 환경을 나타낸다. Microsoft는 1983년 Windows를 발표하면서 이를 여러 응용 프로그램을 동시에 화면에 표시하고 응용 프로그램 사이에서 자료를 전달할 수 있는 MS-DOS의 확장 그래픽 환경으로 소개했다.^[8] 첫 상용판인 Windows 1.0은 1985년에 출시되었으며, 창, 메뉴, 아이콘과 대화 상자를 이용하는 그래픽 사용자 인터페이스를 제공했다.^[9]

초기에는 Windows가 MS-DOS 위에서 실행되는 그래픽 운영 환경을 뜻했지만, 이후 명칭의 범위가 독립적인 운영체제 제품군 전체로 확장되었다. Windows 1.x부터 Windows 3.x까지는 MS-DOS에 의존하여 실행되었고, Windows 95부터 Windows Me까지의 Windows 9x 계열도 부팅과 일부 시스템 기능에서 MS-DOS 계통을 이어받았다. 이와 별도로 개발된 Windows NT는 자체 커널과 시스템 구조를 가진 운영체제였으며, Windows XP 이후 개인용 컴퓨터용 Windows의 주 계보도 Windows NT로 통합되었다.

현대의 Windows는 하나의 특정 운영체제만을 의미하지 않는다. 좁은 의미로는 개인용 컴퓨터에서 사용되는 Windows 클라이언트 운영체제를 가리키며, 일상적으로 “Windows를 사용한다”라고 할 때에는 대개 이 의미가 사용된다. Microsoft의 기술 문서에서는 Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10과 Windows 11을 Windows Client 제품군으로 분류한다.^[10]

넓은 의미의 Windows 제품군에는 다음 범위가 포함된다.

• 개인용 컴퓨터와 워크스테이션을 위한 Windows 클라이언트
• 서버와 데이터센터를 위한 Windows Server
• 임베디드 장치와 전용 시스템을 위한 Windows Embedded와 Windows IoT
• 휴대용 정보 단말기와 스마트폰을 위한 Pocket PC, Windows Mobile, Windows Phone과 Windows 10 Mobile
• 설치, 배포와 복구를 위한 Windows PE와 Windows Recovery Environment
• 특정 장치와 용도에 맞게 구성된 Windows Holographic, Windows Team과 그 밖의 파생 환경

Windows Server는 Windows라는 공통 이름과 NT 기반 구조를 사용하지만, 개인용 컴퓨터용 Windows의 단순한 에디션이 아니라 서버 응용 프로그램, 서비스와 작업 부하를 실행하기 위한 별도의 제품군이다. Microsoft는 Windows Server를 온프레미스, 하이브리드 및 클라우드 환경에서 응용 프로그램과 서비스를 실행하고 보호하는 기업용 서버 플랫폼으로 정의한다.^[11]

Windows Embedded와 Windows IoT 역시 Windows 제품군에 포함된다. 이 계열은 일반적인 개인용 컴퓨터가 아니라 키오스크, 산업용 제어 장치, 의료 장비, 판매 시점 관리 단말기와 그 밖의 고정 목적 장치를 대상으로 한다. Windows for IoT는 과거 Windows Embedded로 불렸던 임베디드 시스템용 운영체제 제품군이며, 현재의 Windows IoT Enterprise는 데스크톱 Windows와 공통 기반을 사용하면서 장치 잠금과 장기 지원 기능을 추가한다.^[12][13]

반면 Windows에서 실행되는 모든 Microsoft 제품이 Windows 운영체제 제품군에 포함되는 것은 아니다. Microsoft Office, Microsoft Edge, Visual Studio, DirectX와 .NET은 Windows와 밀접하게 연관되어 있지만 운영체제가 아니라 응용 프로그램, 개발 환경, API 또는 실행 플랫폼이다. Windows API, Win32, WinRT와 같은 인터페이스도 Windows의 구성 요소이거나 프로그래밍 환경이지 독립적인 Windows 제품 계열은 아니다.

Xbox에서 사용하는 시스템 소프트웨어는 Windows NT 계열의 기술과 여러 구성 요소를 공유하지만, 일반적으로 Microsoft가 Windows 클라이언트나 Windows Server라는 이름으로 판매하는 제품에는 포함되지 않는다. Xbox 운영체제는 콘솔 하드웨어와 게임 실행을 위해 구성된 별도의 플랫폼으로 다루며, Windows 문서에서는 NT 기술의 파생 및 공유 사례로만 언급한다.

Microsoft가 다른 운영체제용으로 출시한 제품 이름에 Windows가 포함되는 경우도 문맥에 따라 구별해야 한다. 예를 들어 과거의 Windows Services for UNIX와 Windows Subsystem for Linux는 Windows 위에서 다른 운영체제의 인터페이스나 실행 환경을 제공하는 호환성 구성 요소이지, UNIX 또는 Linux가 Windows 제품군에 편입되었다는 의미는 아니다.

따라서 이 문서에서 Windows는 MS-DOS 기반의 초기 Windows, Windows 9x, Windows NT 기반 클라이언트와 서버, Windows CE 및 임베디드·모바일 파생 제품을 포함하는 Microsoft의 운영체제 계보 전체를 뜻한다. 개별 버전에만 해당하는 기능, 화면 구성, 지원 정책과 에디션 차이는 Windows 11, Windows Server, Windows NT와 같은 각각의 문서에서 별도로 다룬다.

Windows의 역사는 하나의 운영체제가 순차적으로 교체된 과정이라기보다, 서로 다른 목적과 기술 기반을 가진 여러 계열이 병행 발전하다가 Windows NT를 중심으로 통합된 과정이다. 1980년대와 1990년대 초의 Windows는 MS-DOS 위에서 동작하는 그래픽 환경으로 출발했으며, 이후 Windows 9x 계열로 이어졌다. 이와 별도로 Microsoft는 기업과 서버 시장을 위해 Windows NT를 개발했다. 두 계열은 2000년대 초까지 병존했지만, Windows XP부터 개인용 Windows도 NT 계열로 통합되었다.

Windows 이전의 Microsoft 운영체제

Microsoft는 Windows 이전부터 개인용 컴퓨터용 운영체제 시장에 참여하고 있었다. 회사는 1980년 IBM이 개발하던 IBM PC에 사용할 운영체제 공급을 맡았고, Seattle Computer Products의 QDOS를 인수하여 수정한 뒤 IBM에는 PC DOS, 다른 컴퓨터 제조사에는 MS-DOS라는 이름으로 공급했다.

1981년 IBM PC와 함께 출시된 PC DOS는 문자 기반 명령줄 인터페이스를 사용했으며, 응용 프로그램이 하드웨어와 메모리를 직접 다루는 단일 사용자·단일 작업 중심의 환경이었다. MS-DOS는 IBM PC 호환 기종의 확산과 함께 널리 보급되었고, Microsoft가 개인용 컴퓨터 운영체제 시장에서 영향력을 확대하는 기반이 되었다.

당시 개인용 컴퓨터의 그래픽 사용자 인터페이스는 Xerox Alto와 Xerox Star에서 발전한 개념을 바탕으로 Apple Lisa, Macintosh System Software, Visi On과 GEM 같은 제품에 적용되고 있었다. Microsoft 역시 문자 기반 MS-DOS 위에 마우스와 창을 사용하는 그래픽 환경을 제공하는 프로젝트를 진행했다.

Microsoft는 1983년 11월 10일 이 프로젝트를 Windows라는 이름으로 발표했다. 초기에는 Interface Manager라는 내부 명칭이 사용되었으나, 화면에 여러 창을 표시한다는 특징을 직접 나타내는 Windows가 제품명으로 채택되었다. 당시 Windows는 독립된 운영체제라기보다 MS-DOS를 확장하는 그래픽 운영 환경으로 소개되었다.^[14]

Microsoft는 Windows와 별개로 IBM과 함께 차세대 운영체제 OS/2도 개발했다. OS/2는 MS-DOS보다 강력한 멀티태스킹과 보호 모드를 제공하는 운영체제로 기획되었으나, Microsoft와 IBM의 전략 차이로 공동 개발 관계가 약화되었다. Microsoft는 이후 OS/2보다 자체적으로 개발하던 Windows와 Windows NT에 역량을 집중했다.

Windows 1.0과 Windows 2.x

Windows 1.0은 여러 차례 연기된 뒤 1985년 11월 20일 출시되었다. Windows 1.0은 MS-DOS에서 실행되는 16비트 그래픽 환경으로, 마우스 입력, 메뉴, 아이콘, 대화 상자와 여러 응용 프로그램을 화면에 표시하는 기능을 제공했다.

초기 Windows의 창은 서로 겹칠 수 없었으며 화면을 나누어 배치하는 타일 방식이 중심이었다. MS-DOS Executive가 파일과 프로그램을 관리하는 셸 역할을 맡았고, 계산기, 달력, 메모장, 그림판의 전신인 Paint, 시계와 간단한 워드 프로세서인 Write 등이 포함되었다.

Windows 1.0은 새로운 그래픽 인터페이스를 제공했지만, 높은 하드웨어 요구 사항과 적은 전용 응용 프로그램, 기존 MS-DOS 프로그램과 비교해 제한적인 성능 때문에 널리 보급되지는 못했다. Microsoft의 자체 역사 자료도 Windows 1.0이 본격적인 대중적 성공을 거두지 못했으며, Windows 3.0에 이르러 사용자가 크게 증가했다고 설명한다.^[15]

Windows 2.0은 1987년 출시되었다. 창을 서로 겹쳐 배치하고 크기를 조절할 수 있게 되었으며, 바탕 화면 아이콘, 키보드 단축키와 개선된 메모리 관리가 도입되었다. Microsoft Word와 Microsoft Excel의 Windows 버전도 이 시기에 등장하며 Windows 전용 응용 프로그램 생태계가 형성되기 시작했다.

1988년에는 Intel 80286과 80386 프로세서의 기능을 활용하는 Windows/286 2.1과 Windows/386 2.1이 출시되었다. 특히 Windows/386은 80386의 가상 8086 모드를 이용하여 여러 MS-DOS 프로그램을 각각의 가상 머신에서 실행할 수 있었다. 이러한 기능은 이후 Windows의 멀티태스킹과 호환성 구조로 이어졌다.

Windows 3.x의 대중화

Windows 3.0은 1990년 5월 출시되었다. 그래픽 인터페이스와 아이콘이 크게 개선되었고, 프로그램 관리자와 파일 관리자가 도입되었다. 또한 80286과 80386 프로세서의 보호 모드를 활용하여 이전 버전보다 많은 메모리를 사용할 수 있었으며, 여러 MS-DOS 프로그램을 동시에 실행하는 기능도 향상되었다.

Windows 3.0은 성능과 사용성뿐 아니라 소프트웨어 개발 환경에서도 이전 버전보다 큰 발전을 이루었다. Microsoft는 소프트웨어 개발사들이 Windows용 응용 프로그램을 제작하도록 적극적으로 지원했고, 워드 프로세서, 스프레드시트, 데이터베이스와 그래픽 프로그램이 Windows 환경으로 이동하기 시작했다. 이 버전을 계기로 Windows는 제한적인 그래픽 셸에서 개인용 컴퓨터의 주요 응용 프로그램 플랫폼으로 성장했다.

Windows 3.1은 1992년 출시되었다. TrueType 글꼴, 멀티미디어 기능, OLE 개선, 네트워크 기능과 안정성 향상이 이루어졌으며, 실질적으로 80286 이상의 보호 모드 환경을 기본으로 삼았다. 기업 네트워크를 위한 Windows for Workgroups 3.1과 3.11은 파일 및 프린터 공유, 작업 그룹 네트워크와 내장 네트워크 기능을 제공했다.

Windows 3.x는 여전히 MS-DOS 위에서 시작되고 16비트 구성 요소를 광범위하게 사용했지만, 사용자 입장에서는 부팅 후 대부분의 작업을 그래픽 환경에서 수행할 수 있었다. Windows의 대중화는 개인용 컴퓨터 소프트웨어가 DOS 응용 프로그램 중심에서 그래픽 응용 프로그램 중심으로 전환되는 계기가 되었다.

Windows NT의 개발

Microsoft는 1988년 기존 MS-DOS와 Windows 계열의 제약을 벗어난 새로운 운영체제를 개발하기 위해 Windows NT 프로젝트를 시작했다. 개발 조직은 Digital Equipment Corporation에서 VMS를 개발했던 Dave Cutler를 중심으로 구성되었다. 목표는 완전한 32비트 구조, 선점형 멀티태스킹, 가상 메모리, 메모리 보호, 다중 사용자 보안, 네트워크 기능과 여러 프로세서 아키텍처를 지원하는 범용 운영체제를 만드는 것이었다.

Windows NT는 기존 Windows를 단순히 확장한 구조가 아니었다. 커널 모드와 사용자 모드를 분리하고, 하드웨어 추상화 계층을 통해 프로세서와 시스템 하드웨어의 차이를 감추며, 객체 관리자와 보안 참조 모니터, 입출력 관리자, 프로세스 관리자와 가상 메모리 관리자 같은 실행부 구성 요소를 갖춘 새로운 시스템으로 설계되었다.

초기 설계에서는 Win32뿐 아니라 OS/2와 POSIX 응용 프로그램 환경도 사용자 모드 하위 시스템으로 지원했다. 이를 통해 하나의 커널 위에서 여러 응용 프로그램 인터페이스를 제공하려 했으나, 이후 Win32가 사실상 중심 환경으로 자리 잡았다.

Microsoft는 1992년 개발자 회의에서 Windows NT와 Win32 API를 공개 시연했고, Windows NT 3.1과 Windows NT Advanced Server 3.1을 1993년 7월 출시했다. 버전 번호 3.1은 기존 Windows 3.1과의 API 및 브랜드 연속성을 강조하기 위해 사용되었다. Microsoft는 Windows NT 개발 조직이 1988년 구성되었으며, 최초 제품인 Windows NT 3.1과 Windows NT Advanced Server 3.1이 1993년 7월 출시되었다고 설명한다.^[16]

Windows NT 3.1은 x86뿐 아니라 MIPS와 DEC Alpha를 지원했고, 이후 PowerPC도 지원 대상에 포함되었다. NTFS, 도메인 기반 네트워크, 사용자별 접근 제어와 장기 실행에 적합한 시스템 구조를 제공했지만, 높은 메모리와 저장 공간 요구 사항, 제한적인 하드웨어 드라이버와 기존 DOS·Windows 프로그램 호환성 때문에 초기에는 주로 워크스테이션과 서버 시장에서 사용되었다.

Windows NT 3.5와 3.51은 성능과 네트워크 기능, 하드웨어 지원을 개선했다. Windows NT 4.0은 1996년 출시되어 Windows 95와 유사한 셸을 도입했고, 그래픽 장치 인터페이스의 많은 부분을 커널 모드로 이동하여 그래픽 성능을 높였다. 대신 그래픽 드라이버 결함이 시스템 전체에 미치는 영향도 커졌다.

Windows 95와 Windows 9x 계열

Windows 95는 1995년 8월 24일 출시되었다. Microsoft는 대규모 광고와 심야 판매 행사를 진행했으며, 출시 당일 전 세계 매장에 구매자가 몰릴 정도로 높은 관심을 받았다.^[17]

Windows 95는 MS-DOS와 Windows 3.x 계열을 하나의 소비자용 제품으로 통합했다. 부팅 과정과 일부 하위 계층은 여전히 MS-DOS에 의존했지만, 32비트 응용 프로그램을 위한 Win32 API, 선점형 멀티태스킹, 긴 파일 이름, 플러그 앤 플레이와 개선된 가상 메모리를 지원했다. 기존 16비트 Windows와 MS-DOS 프로그램을 실행할 수 있도록 상당한 호환성 계층도 유지했다.

사용자 인터페이스에서는 시작 메뉴, 작업 표시줄, 알림 영역, 바탕 화면과 Windows 탐색기가 도입되었다. 이러한 구조는 이후 Windows 데스크톱 인터페이스의 기본 형태가 되었다. 창을 최소화한 상태를 작업 표시줄에서 관리하고, 시작 버튼을 통해 프로그램과 시스템 기능에 접근하는 방식은 개인용 컴퓨터의 대표적인 인터페이스로 자리 잡았다.

Windows 95의 후기 OEM 버전에는 FAT32, USB 지원과 Internet Explorer가 추가되었다. 웹 브라우저와 운영체제의 결합은 인터넷 사용 확산에 기여했지만, Microsoft의 시장 지배력과 Internet Explorer 통합을 둘러싼 반독점 분쟁의 원인이 되기도 했다.

Windows 98은 1998년 출시되었다. USB, ACPI, 다중 모니터, DVD와 새로운 하드웨어 규격 지원을 확대했고, 웹 콘텐츠와 데스크톱 셸을 결합한 Active Desktop과 Internet Explorer 통합을 강화했다. 1999년의 Windows 98 Second Edition은 네트워크 공유, USB와 하드웨어 지원을 개선했다.

Windows Me는 2000년 출시된 마지막 Windows 9x 계열 운영체제였다. 가정용 멀티미디어 기능, 시스템 복원, Windows Movie Maker와 자동 업데이트 기능을 도입했지만, 실모드 DOS 접근을 제한하면서도 내부적으로는 기존 9x 구조를 유지했다. Windows Me를 끝으로 Microsoft는 소비자용 Windows에서도 DOS 기반 계열을 종료했다.

Microsoft의 Windows 명령줄 역사 자료는 Windows 1.x, 2.x, 3.x, Windows 95와 Windows 98이 모두 MS-DOS 기반 위에서 실행되었으며 그 기반에 크게 의존했다고 설명한다.^[18]

Windows 2000과 Windows Me

Windows 2000은 Windows NT 5.0으로 개발되다가 제품명이 변경되어 2000년 2월 출시되었다. Microsoft는 NT 기술을 기업용 워크스테이션과 서버뿐 아니라 일반적인 비즈니스 컴퓨팅 환경으로 확대한다는 의미에서 Windows 2000이라는 이름을 채택했다.

Windows 2000은 Windows NT 4.0을 기반으로 플러그 앤 플레이, USB, 전원 관리, DirectX와 노트북 지원을 강화했다. 개인용 컴퓨터에서 사용하기 쉬운 기능을 도입하면서도 NTFS, 사용자 권한, 보호된 메모리와 선점형 멀티태스킹 같은 NT 계열의 구조를 유지했다.

서버 제품에는 Active Directory, 그룹 정책, Kerberos 인증, DNS 통합과 향상된 분산 파일 시스템이 도입되었다. 이 구조는 이후 Windows 기반 기업 네트워크의 핵심이 되었다.

같은 해 출시된 Windows Me는 가정용 사용자에게 제공되었고 Windows 2000은 기업과 전문 사용자를 대상으로 했다. 두 제품은 비슷한 사용자 인터페이스를 사용했지만 내부 구조는 달랐다. Windows Me는 Windows 9x와 MS-DOS 계통의 마지막 제품이었고, Windows 2000은 NT 계열이었다.

이 시기는 Microsoft가 소비자용 DOS 기반 Windows와 기업용 NT 기반 Windows를 마지막으로 병행 판매한 시기였다. 다음 세대인 Windows XP에서는 두 시장이 하나의 NT 기반 제품군으로 통합되었다.

Windows XP와 제품 계열의 통합

Windows XP는 2001년 10월 25일 전 세계에 출시되었다.^[19] Windows XP는 가정용 Windows와 기업용 Windows를 모두 Windows NT 계열로 통합한 첫 주요 클라이언트 제품이었다.

가정용 사용자를 위한 Windows XP Home Edition과 기업·전문 사용자를 위한 Windows XP Professional이 제공되었다. 두 에디션은 기능과 관리 능력에서 차이가 있었지만, 모두 Windows 2000을 계승한 NT 커널과 드라이버 모델, 보안 및 메모리 관리 구조를 사용했다.

Windows XP는 Luna라는 새로운 시각 디자인, 시작 메뉴 개편, 빠른 사용자 전환, 원격 데스크톱, 시스템 복원, 향상된 무선 네트워크와 멀티미디어 기능을 제공했다. 기존 Windows 9x와 Windows 2000 응용 프로그램을 실행하기 위한 호환성 기능도 광범위하게 포함되었다.

이후 Tablet PC Edition, Media Center Edition, Professional x64 Edition과 임베디드 시스템용 Windows XP Embedded 같은 파생판이 출시되었다. Windows XP는 장기간 사용되며 개인용 컴퓨터의 대표적인 Windows 버전이 되었지만, 긴 사용 기간 동안 악성 코드와 네트워크 공격의 주요 대상이 되었다.

Microsoft는 Windows XP Service Pack 2에서 방화벽 기본 활성화, 보안 센터, 실행 방지와 브라우저 보안 강화를 적용했다. 이는 Windows 개발에서 기능과 호환성뿐 아니라 기본 보안 구성을 중심에 두게 된 중요한 전환이었다.

Windows XP의 성공으로 NT 계열은 개인용 컴퓨터, 워크스테이션, 서버와 임베디드 장치를 포괄하는 Windows의 공통 기반이 되었다. 이후 클라이언트 Windows는 더 이상 DOS 기반 계열로 개발되지 않았다.

Windows Vista와 Windows 7

Windows Vista는 오랜 개발 기간을 거쳐 기업용으로 2006년 11월, 일반 소비자용으로 2007년 1월 출시되었다. 개발 과정에서는 보안, 드라이버, 그래픽, 검색과 배포 구조가 대대적으로 변경되었다.

Windows Vista는 Windows Aero 인터페이스와 Desktop Window Manager를 도입해 각 창을 합성하는 그래픽 환경을 구현했다. 사용자 계정 컨트롤, Windows Defender, BitLocker, 주소 공간 배치 난수화, 서비스 격리와 드라이버 서명 등 보안 기능도 강화했다.

새로운 Windows Display Driver Model, 오디오 스택, 네트워크 스택, 검색 인덱스와 설치 이미지 기반 배포가 도입되었다. 그러나 높은 하드웨어 요구 사항, 초기 드라이버와 응용 프로그램 호환성 문제, 잦은 사용자 계정 컨트롤 확인과 상대적으로 낮은 성능 때문에 부정적인 평가도 받았다.

Windows 7은 2009년 10월 출시되었다. Vista에서 도입된 NT 6.x 기반 구조와 보안·드라이버 모델을 유지하면서 성능, 호환성, 전원 관리와 사용자 인터페이스를 개선했다. 작업 표시줄은 실행 중인 창과 고정된 프로그램 실행기를 통합하는 형태로 개편되었고, 라이브러리, 점프 목록, 창 스냅 기능이 추가되었다.

Windows 7은 Vista의 기술적 기반을 안정화하고 기존 PC와 응용 프로그램에서 더 일관된 사용 경험을 제공하면서 기업과 개인 사용자에게 빠르게 보급되었다. 이후 오랜 기간 Windows XP와 함께 주요 데스크톱 Windows로 사용되었다.

서버 계열에서는 Windows Vista와 공통 기반을 사용하는 Windows Server 2008, Windows 7과 공통 기반을 사용하는 Windows Server 2008 R2가 출시되었다. 특히 Windows Server 2008 R2부터 서버 제품은 x86-64 전용으로 전환되었다.

Windows 8과 Windows 8.1

Windows 8은 2012년 10월 출시되었다. Microsoft는 터치스크린 태블릿과 전통적인 키보드·마우스 PC를 하나의 운영체제에서 지원하기 위해 사용자 인터페이스와 응용 프로그램 모델을 크게 변경했다.

기존 시작 메뉴는 전체 화면 시작 화면으로 대체되었고, 타일 기반의 새로운 인터페이스가 도입되었다. Metro 스타일 앱으로 불렸던 새로운 응용 프로그램은 이후 Windows Store 앱으로 명칭이 바뀌었으며, Windows Runtime과 Windows Store를 통해 배포되었다.

Windows 8은 빠른 시작, 개선된 작업 관리자, 파일 복사 인터페이스, 기본 USB 3.0 지원, Microsoft 계정 연동, Windows Store, Hyper-V와 ARM용 Windows RT를 도입했다. Secure Boot와 새로운 복구 기능도 강화되었다.

그러나 데스크톱 PC에서도 시작 화면과 화면 모서리 제스처를 중심으로 사용하도록 설계된 인터페이스는 기존 사용자에게 큰 변화를 요구했다. 데스크톱과 새로운 전체 화면 환경이 분리되어 있다는 인상을 주었고, 시작 버튼과 전통적인 시작 메뉴가 사라진 점도 강한 반발을 불러왔다.

Windows 8.1은 2013년 무료 업데이트로 출시되었다. 시작 버튼을 복원하고, 바탕 화면으로 직접 부팅하는 기능, 창 크기 조절과 여러 앱 동시 표시, 검색, 설정과 클라우드 연동을 개선했다. 그러나 시작 메뉴 자체는 복원되지 않았으며, Windows 8에서 시작된 터치 중심 인터페이스의 기본 방향은 유지되었다.

Windows 8 계열은 상업적으로 Windows 7만큼 널리 정착하지 못했지만, Microsoft Store, Microsoft 계정 중심의 동기화, Windows Runtime, 보안 부팅과 태블릿·PC 통합이라는 방향은 Windows 10과 Windows 11로 이어졌다.

Windows 10

Windows 10은 2014년 9월 발표되었으며, 2015년 7월 29일 전 세계에 출시되었다. Microsoft는 Windows 7과 Windows 8.1 사용자에게 일정 기간 무료 업그레이드를 제공했다.^[20]

Windows 10은 Windows 8의 터치 및 Store 응용 프로그램 구조를 유지하면서 데스크톱 사용자 경험을 다시 강화했다. 시작 메뉴가 복원되었고, 기존 프로그램 목록과 라이브 타일을 결합했다. Store 앱은 전체 화면뿐 아니라 일반 데스크톱 창에서도 실행할 수 있게 되었다.

새 웹 브라우저 Microsoft Edge, 가상 데스크톱, 작업 보기, 알림 센터, Windows Hello, DirectX 12와 음성 비서 Cortana가 도입되었다. 장치 형태에 따라 인터페이스를 변경하는 Continuum도 제공되었다.

Windows 10은 PC, 태블릿, 스마트폰, Xbox One, Surface Hub, HoloLens와 사물 인터넷 장치에 공통된 Windows 기반과 응용 프로그램 플랫폼을 제공하려는 전략으로 개발되었다. Microsoft는 출시 당시 Windows 10이 PC와 태블릿뿐 아니라 Windows Phone, IoT, Surface Hub, Xbox One과 HoloLens를 포함하는 폭넓은 장치 제품군을 대상으로 설계되었다고 설명했다.^[21]

개발 과정에는 Windows Insider Program이 도입되어 일반 사용자가 시험판 빌드를 설치하고 의견을 제공할 수 있게 되었다. 이 프로그램은 이후 Windows 11에서도 계속 사용되었다.

Windows 10부터 Microsoft는 몇 년마다 완전히 새로운 버전을 출시하는 방식 대신, 동일한 제품명 아래 정기적인 기능 업데이트를 배포하는 서비스형 Windows 모델을 확대했다. 초기에는 연간 두 차례 기능 업데이트가 제공되었고, 이후 연간 한 차례 중심으로 변경되었다.

여러 업데이트를 통해 Windows Subsystem for Linux, Windows Sandbox, 개선된 가상 데스크톱, 보안 기능과 새로운 설정 앱 기능이 추가되었다. 반면 강제성 있는 업데이트, 원격 측정, 기본 응용 프로그램 변경과 업데이트 과정의 품질 문제는 지속적인 논쟁 대상이 되었다.

Windows 10의 최종 일반 버전은 2022년 공개된 버전 22H2였다. Home, Pro와 일반 Enterprise·Education 에디션에 대한 지원은 2025년 10월 14일 종료되었으며, 특정 LTSC와 IoT Enterprise 제품은 각 제품의 별도 수명 주기에 따라 이후에도 지원된다.^[22]

Windows 11

Windows 11은 2021년 6월 24일 발표되었고, 같은 해 10월 5일부터 호환되는 Windows 10 PC의 무료 업그레이드와 Windows 11이 설치된 신형 PC 형태로 제공되었다.^[23]

Windows 11은 Windows 10의 NT 기반과 응용 프로그램 호환성을 계승하면서 사용자 인터페이스를 크게 수정했다. 시작 버튼과 작업 표시줄 아이콘은 기본적으로 화면 중앙에 배치되었고, 시작 메뉴에서는 라이브 타일이 제거되었다. 창 모서리, 아이콘, 애니메이션, 시스템 소리와 설정 화면도 새로운 디자인 체계에 맞게 변경되었다.

창을 미리 정의된 영역에 배치하는 스냅 레이아웃과 스냅 그룹, 여러 데스크톱 관리, 위젯, 개선된 터치·펜·음성 입력과 새로운 Microsoft Store가 도입되었다. Microsoft Teams 기반 채팅 기능이 초기 버전에 통합되었지만 이후 제거되거나 별도 응용 프로그램 중심으로 변경되었다.

Windows 11은 64비트 프로세서, UEFI Secure Boot와 TPM 2.0을 공식 최소 요구 사항으로 정했다. 지원 프로세서 목록도 제한되어 Windows 10을 실행할 수 있는 상당수 기존 PC가 공식 업그레이드 대상에서 제외되었다. Microsoft는 이를 신뢰성, 보안과 최신 드라이버 모델을 강화하기 위한 기준으로 설명했지만, 사용자와 기업에서는 하드웨어 교체 비용과 전자 폐기물 증가 가능성을 문제로 제기했다.

초기 Windows 11은 Android 응용 프로그램 실행 계획을 포함했다. 이후 Windows Subsystem for Android와 Amazon Appstore가 일부 지역에서 제공되었으나, Microsoft는 해당 기능의 지원을 종료하는 방향으로 전환했다.

Windows 11은 연간 기능 업데이트를 중심으로 서비스된다. 22H2, 23H2, 24H2와 25H2 같은 버전이 순차적으로 제공되었으며, 각 버전에는 별도의 지원 기간이 적용된다. Microsoft는 Windows 11의 월별 보안 및 비보안 업데이트와 각 기능 버전의 상태를 Windows 릴리스 상태 문서에서 관리한다.^[24]

2024년 이후 Microsoft는 Windows 11에 Copilot, 자연어 기반 검색, 신경망 처리 장치를 이용하는 로컬 AI 기능과 Copilot+ PC라는 하드웨어 범주를 도입했다. 일부 기능은 특정 NPU 성능과 최신 프로세서를 요구하며, 기존 Windows 기능과 별개의 단계적 배포 방식으로 제공된다.

Windows 11에서도 Win32 응용 프로그램 호환성과 기존 Windows 관리 체계가 유지되지만, 사용자 인터페이스와 기본 응용 프로그램 일부는 웹 기술, Windows App SDK와 새 프레임워크를 함께 사용하는 방향으로 변화했다.

Windows Server의 발전

Windows의 서버 계열은 Windows NT의 최초 출시부터 존재했다. 1993년 7월 27일 출시된 Windows NT Advanced Server 3.1은 최초의 Windows NT 서버 제품이었다. Microsoft는 이를 32비트 구조와 프로세서 독립성을 갖춘 Windows Server 계보의 시작으로 설명한다.^[25]

Windows NT Server 3.5와 3.51은 네트워크 성능과 TCP/IP 기능, NetWare와 UNIX 환경과의 상호 운용성을 개선했다. Windows NT Server 4.0은 Windows 95와 유사한 사용자 인터페이스, Internet Information Server, 도메인 관리와 기업용 네트워크 기능을 확대했다.

Windows 2000 Server 계열에서는 Active Directory가 도입되었다. 기존 Windows NT 도메인 모델은 계층적 디렉터리, DNS 기반 이름 체계, 조직 단위, 그룹 정책과 Kerberos 인증을 사용하는 구조로 확장되었다. 이 변화는 이후 Windows 기업 네트워크 관리의 기반이 되었다.

Windows Server 2003은 Windows XP와 공통 기반을 사용하면서 보안 기본값, Active Directory, IIS, 클러스터링과 64비트 지원을 강화했다. 이후 R2 버전에서는 지사 관리, 파일 복제와 UNIX 상호 운용 기능이 확대되었다.

Windows Server 2008은 Server Core 설치 옵션, Hyper-V, 새로운 방화벽과 네트워크 스택을 도입했다. Windows Server 2008 R2는 Windows 7과 공통 기반을 사용했으며, x86-64 전용 서버 운영체제로 전환되었다.

Windows Server 2012와 2012 R2는 클라우드 및 대규모 가상화 환경을 중심으로 개발되었다. Hyper-V, 저장 공간, PowerShell 기반 관리, 네트워크 가상화와 서버 관리자 기능이 크게 확장되었다. 사용자 인터페이스는 Windows 8 계열과 유사한 형태를 사용했다.

Windows Server 2016은 Windows 10 기반으로 전환되었으며, Windows 컨테이너, Hyper-V 컨테이너, Nano Server, 보호된 가상 머신과 가상화 기반 보안 기능을 도입했다. 이 시기부터 Windows Server는 전통적인 장기 서비스 채널과 더 빠른 업데이트 채널을 병행하기 시작했다.

Windows Server 2019는 하이브리드 클라우드, Windows Admin Center, 컨테이너와 보안 기능을 개선했다. Windows Server 2022는 보안 코어 서버, TLS 1.3, SMB 암호화와 Azure 통합을 강화했다.

Windows Server 2025는 Windows Server의 장기 서비스 채널 제품으로, Hyper-V 확장성, 저장 장치, Active Directory, SMB, 보안과 하이브리드 클라우드 기능을 개선했다. Microsoft는 Windows Server 2025를 현재 장기 서비스 채널 제품으로 분류하며, 별도로 컨테이너와 마이크로서비스에 더 빠른 기능을 제공하는 연간 채널을 운영한다.^[26]

Windows Server는 클라이언트 Windows와 NT 커널, 드라이버 모델, 네트워크 스택과 여러 관리 기술을 공유한다. 그러나 서버 역할, Active Directory, 클러스터링, 원격 관리, 가상화, 컨테이너와 장기 지원을 중심으로 별도의 제품 수명 주기와 에디션 체계를 유지한다.

Windows의 전체 역사는 결과적으로 세 단계의 변화로 정리할 수 있다. 첫 단계는 MS-DOS 위에 그래픽 환경을 구축하고 Windows 응용 프로그램 생태계를 형성한 시기다. 두 번째 단계는 DOS 기반 소비자용 Windows와 NT 기반 기업·서버용 Windows가 병행 발전한 시기다. 세 번째 단계는 Windows XP 이후 NT가 모든 주요 Windows 제품의 공통 기반이 되고, 클라이언트·서버·임베디드와 특수 장치용 제품이 그 위에서 분화한 시기다.

Windows는 공통된 이름과 기술을 공유하면서도 대상 장치와 운영 목적에 따라 여러 제품군으로 나뉜다. 개인용 컴퓨터에서는 그래픽 사용자 환경과 응용 프로그램 호환성이 중심이 되고, 서버에서는 네트워크 서비스와 중앙 관리, 임베디드 장치에서는 장기 지원과 기능 제한, 특수 목적 장치에서는 특정 하드웨어와 작업에 맞춘 구성이 강조된다.

앞에서 다룬 Windows 제품군 둘러보기 상자가 DOS, Windows NT와 Windows CE 같은 기술적 계보를 보여준다면, 이 절은 각 제품이 실제로 사용된 환경을 기준으로 Windows의 범위를 설명한다.

개인용 컴퓨터용 Windows

개인용 컴퓨터용 Windows는 데스크톱 컴퓨터, 노트북, 태블릿과 2-in-1 장치를 위한 범용 운영체제 제품군이다. 일반적으로 별도의 수식어 없이 Windows라고 할 때에는 이 클라이언트 제품군을 가리킨다.

초기의 Windows 1.x부터 Windows 3.x까지는 MS-DOS에서 실행되는 그래픽 환경이었고, Windows 95부터 Windows Me까지는 소비자용 Windows 9x 계열로 발전했다. Windows XP부터는 개인용 컴퓨터용 Windows도 Windows NT 계열로 통합되었다.

현대의 클라이언트 Windows는 다음과 같은 용도를 함께 지원한다.

• 웹 이용과 개인용 응용 프로그램
• 문서 작성과 업무
• 소프트웨어 개발
• 그래픽, 영상과 음악 제작
• 컴퓨터 게임
• 교육과 공공 단말기
• 기업용 클라이언트와 원격 업무
• 태블릿과 터치 기반 컴퓨팅

개인용 Windows는 Home, Pro, Enterprise와 Education 같은 에디션으로 나뉜다. 이 에디션은 기본 운영체제 구조와 응용 프로그램 환경을 공유하지만, 도메인 가입, 가상화, 장치 관리, 암호화와 기업용 보안 정책 같은 기능에서 차이가 있다.

Microsoft는 Windows를 노트북, 데스크톱, 게임용 PC와 2-in-1을 포함한 여러 형태의 개인용 컴퓨터에서 사용하는 운영체제로 제공한다.^[27]

Windows Server

Windows Server는 서버 컴퓨터와 데이터센터, 기업 네트워크 및 클라우드 환경을 위한 Windows 제품군이다. 개인용 Windows와 Windows NT 기반 구조, 드라이버 모델, 파일 시스템과 여러 관리 기술을 공유하지만, 서버 역할과 장기간의 안정적인 서비스 운영에 맞게 구성된다.

Windows Server는 다음과 같은 용도로 사용된다.

• 파일과 프린터 공유
• 웹과 응용 프로그램 서버
• Active Directory 도메인 서비스
• DNS와 DHCP 같은 네트워크 기반 서비스
• 데이터베이스와 기업용 업무 시스템
• 원격 데스크톱 서비스
• 장애 조치 클러스터
• Hyper-V 기반 가상화
• Windows 컨테이너
• 온프레미스와 Microsoft Azure의 하이브리드 환경

Windows Server에는 그래픽 사용자 인터페이스를 포함한 Desktop Experience와 최소한의 사용자 인터페이스만 제공하는 Server Core 같은 설치 옵션이 사용되어 왔다. Server Core는 일반적인 데스크톱 사용보다 원격 관리와 서버 역할 실행에 초점을 맞추며, 설치되는 구성 요소와 공격 표면을 줄인다.

클라이언트 Windows가 한 사용자의 대화형 작업을 중심으로 구성되는 것과 달리, Windows Server는 여러 사용자와 컴퓨터에 지속적으로 서비스를 제공하고 중앙에서 인증, 정책, 저장소와 네트워크 자원을 관리하는 데 중점을 둔다. Microsoft는 Windows Server를 응용 프로그램, 네트워크와 웹 서비스를 실행하는 플랫폼이며 온프레미스 환경과 Azure를 연결하는 기반으로 설명한다.^[28]

워크스테이션용 Windows

워크스테이션용 Windows는 일반적인 개인용 컴퓨터보다 높은 연산 성능, 대용량 메모리, 여러 프로세서와 전문 저장 장치를 사용하는 시스템을 대상으로 한다. 독립된 운영체제 계보라기보다 클라이언트 Windows의 고급 에디션 또는 Windows NT Workstation 제품으로 제공되었다.

초기의 Windows NT Workstation은 업무용 데스크톱, 소프트웨어 개발, 공학, 그래픽과 과학 계산 환경을 대상으로 했다. Windows 2000 Professional과 Windows XP Professional 이후에는 일반 기업용 클라이언트와 워크스테이션 제품의 경계가 상당 부분 통합되었다.

현대에는 Windows Pro for Workstations가 고성능 워크스테이션용 에디션 역할을 한다. 이 에디션은 고성능 하드웨어와 대규모 작업 부하를 고려하며, 버전에 따라 다음과 같은 기능을 제공한다.

• 다중 프로세서와 대용량 메모리 지원
• ReFS 사용
• 고속 네트워크 파일 전송
• 비휘발성 메모리와 고성능 저장 장치
• 원격 직접 메모리 접근을 이용하는 SMB Direct
• 고성능 컴퓨팅과 전문 제작 프로그램 실행

워크스테이션용 Windows는 서버와 유사한 고급 하드웨어를 사용할 수 있지만, 서버 역할을 지속적으로 제공하기보다 한 사용자의 전문 작업과 대화형 응용 프로그램 실행을 중심으로 한다.

모바일과 휴대용 장치용 Windows

Microsoft는 데스크톱 Windows와 별도로 휴대용 정보 단말기, 스마트폰과 소형 컴퓨터를 위한 여러 Windows 제품을 개발했다.

초기의 Handheld PC와 Palm-size PC는 Windows CE를 기반으로 했으며, 작은 화면, 제한된 메모리, 배터리와 터치 또는 스타일러스 입력에 맞게 구성되었다. 이후 Pocket PC와 Windows Mobile로 발전하여 개인 정보 관리, 전화, 메시지, 모바일 인터넷과 업무용 응용 프로그램을 지원했다.

Windows Phone 7은 Windows CE 계열의 기반을 사용하면서 새로운 타일 기반 사용자 인터페이스를 도입했다. Windows Phone 8부터는 Windows NT 계열의 커널과 여러 구성 요소를 사용하여 데스크톱 Windows와 기술적 기반을 확대해 공유했다. 이후 Windows 10 Mobile은 Windows 10의 범용 응용 프로그램 플랫폼과 서비스 체계에 통합되었다.

휴대용 Windows 제품군은 다음 장치를 대상으로 했다.

• 전자수첩과 휴대용 정보 단말기
• 산업용 휴대 단말기
• 스마트폰
• 터치스크린 기반 소형 컴퓨터
• 기업용 데이터 수집 장치
• 차량용 정보 시스템

Microsoft는 모바일 운영체제 시장에서 Windows 10 Mobile의 개발과 지원을 종료했다. 다만 휴대폰과 PC를 연동하는 Phone Link 같은 기능을 통해 Android와 iOS 장치를 Windows PC에 연결하는 방향은 계속 유지되고 있다.

임베디드와 IoT용 Windows

임베디드 Windows는 일반 사용자가 자유롭게 프로그램을 설치하는 범용 PC보다, 정해진 기능을 지속적으로 수행하는 장치를 대상으로 한다. Microsoft는 Windows CE, Windows Embedded와 Windows IoT라는 이름으로 여러 임베디드 운영체제 제품을 제공해 왔다.

Windows CE는 데스크톱 Windows와 별도로 설계된 소형 운영체제였다. 제조사가 장치에 필요한 구성 요소만 선택하여 운영체제 이미지를 만들 수 있었으며, 제한된 메모리와 저장 공간을 가진 장치에 사용되었다.

Windows CE와 Windows Embedded Compact는 다음과 같은 장치에 사용되었다.

• 산업용 제어 장치
• 바코드와 재고 관리 단말기
• 차량 내비게이션과 정보 시스템
• 의료 장비
• 휴대용 데이터 수집기
• 판매 시점 관리 단말기
• 셋톱박스와 소비자 전자제품

한편 Windows NT 기반 임베디드 제품도 존재했다. Windows XP Embedded, Windows Embedded Standard와 Windows Embedded Industry는 일반 Windows의 구성 요소와 Win32 응용 프로그램 호환성을 활용하면서 특정 장치에 필요한 기능만 선택하거나 시스템 변경을 제한할 수 있도록 구성되었다.

현재의 Windows IoT 제품군은 크게 Windows IoT Enterprise와 소형 장치용 제품 계열로 구분되어 왔다. Windows IoT Enterprise는 일반 데스크톱 Windows와 같은 기반을 사용하지만, 키오스크, 산업용 컴퓨터와 고정 목적 장치에 필요한 잠금 기능과 장기 서비스 옵션을 제공한다.

Microsoft는 Windows for IoT를 고정 목적 장치를 위한 Windows 제품군으로 설명하며, 의료, 소매, 제조와 산업 환경에서 사용되는 장치를 주요 대상으로 제시한다.^[29]

특수 목적 제품군

Windows 기술은 일반 PC, 서버와 임베디드 장치 외에도 특정한 하드웨어나 작업을 위한 운영 환경에 사용되었다. 이들 중 일부는 독립된 Windows 제품으로 제공되었고, 일부는 다른 Microsoft 플랫폼 안에서 Windows NT의 커널과 구성 요소를 공유한다.

Windows PE는 Windows를 설치, 배포하고 복구하기 위한 경량 운영 환경이다. 일반 데스크톱 운영체제로 지속적으로 사용하는 용도가 아니라, 설치 프로그램 실행, 디스크 구성, 시스템 이미지 적용과 장애 복구에 사용된다.

Windows Recovery Environment는 Windows가 정상적으로 부팅되지 않을 때 시작 복구, 시스템 복원, 업데이트 제거, 명령 프롬프트와 초기화 기능을 제공한다. Windows PE를 기반으로 구성되며 설치된 Windows와 별도의 복구 환경으로 실행된다.

Windows Holographic은 Microsoft HoloLens와 혼합 현실 장치를 위한 운영 환경이다. Windows NT 계열의 구성 요소와 범용 Windows 플랫폼을 사용하지만, 공간 인식, 시선, 손 동작과 홀로그램 인터페이스에 맞게 구성된다.

Windows Team은 Surface Hub와 같은 회의실 장치를 위한 제품으로, 공동 작업, 화상 회의, 화이트보드와 대형 터치스크린 사용에 초점을 맞췄다.

Xbox 계열의 시스템 소프트웨어도 Windows NT에서 발전한 커널과 가상화 기술을 활용한다. 그러나 Xbox 운영체제는 일반 Windows 클라이언트나 Windows Server로 판매되지 않으며, 게임 콘솔의 보안과 게임 실행을 위해 별도로 구성된 플랫폼으로 다룬다.

이 밖에도 키오스크, 현금 자동 입출금기, 자동차, 공장 장비, 대형 전광판과 군사·항공 시스템에 맞게 조정된 Windows 제품과 파생 구성이 존재한다. 이러한 제품은 범용 Windows의 구성 요소를 사용하면서 장치의 용도에 따라 사용자 인터페이스, 업데이트, 저장 장치 접근과 응용 프로그램 실행 범위를 제한한다.

현대 Windows의 핵심 구조는 Windows NT에서 발전했다. Windows NT는 응용 프로그램, 시스템 서비스와 운영체제의 핵심 구성 요소를 서로 다른 권한 영역에 배치하고, 하드웨어 차이를 추상화하며, 여러 시스템 자원을 객체와 핸들로 관리하는 구조를 사용한다.

Windows NT의 구조는 버전이 발전하면서 크게 확장되었지만, 사용자 모드와 커널 모드의 분리, 실행부 관리자, 하드웨어 추상화 계층, 환경 하위 시스템과 객체 기반 자원 관리라는 기본 원리는 계속 유지되고 있다.

Windows NT 아키텍처

Windows NT는 처음부터 32비트 가상 메모리, 선점형 멀티태스킹, 다중 프로세서, 사용자별 보안과 여러 하드웨어 아키텍처를 지원하는 운영체제로 설계되었다. 기존 MS-DOS 기반 Windows와 달리 응용 프로그램이 운영체제의 핵심 메모리나 하드웨어를 직접 제어하는 것을 기본 실행 방식으로 사용하지 않는다.

전체 시스템은 크게 사용자 모드와 커널 모드로 나뉜다.

Windows NT의 주요 실행 구조

• 사용자 모드
  • 일반 응용 프로그램
  • Windows API와 런타임 라이브러리
  • 환경 하위 시스템
  • 시스템 프로세스와 서비스
• 커널 모드
  • 시스템 서비스 디스패처
  • Windows 실행부
    • 객체 관리자
    • 프로세스 및 스레드 관리자
    • 가상 메모리 관리자
    • 입출력 관리자
    • 보안 참조 모니터
    • 구성 관리자
  • 커널
  • 장치 드라이버
  • 하드웨어 추상화 계층
• 하드웨어
  • 프로세서
  • 메모리
  • 인터럽트 제어기
  • 타이머
  • 입출력 장치

Windows NT는 여러 구성 요소를 모듈로 구분하지만, 커널, 실행부와 다수의 장치 드라이버가 하나의 커널 주소 공간에서 동작한다. 일반적으로는 모놀리식 커널의 성능 특성과 마이크로커널식 구성 요소 분리를 함께 사용한다는 의미에서 하이브리드 커널로 분류된다.

사용자 모드와 커널 모드

Windows가 실행되는 프로세서는 코드의 권한에 따라 사용자 모드와 커널 모드를 전환한다. 일반 응용 프로그램은 사용자 모드에서 실행되고, 운영체제의 핵심 구성 요소와 다수의 장치 드라이버는 커널 모드에서 실행된다.^[30]

사용자 모드 프로세스는 각각 분리된 가상 주소 공간을 가진다. 한 응용 프로그램이 잘못된 메모리에 접근하거나 충돌하더라도 일반적으로 다른 프로세스와 운영체제 전체의 메모리를 직접 손상시키지는 않는다.

커널 모드 코드는 시스템 전체의 메모리와 하드웨어 자원에 접근할 수 있다. 따라서 커널 모드 드라이버나 운영체제 구성 요소에서 복구할 수 없는 오류가 발생하면 시스템 전체가 중지될 수 있다. Windows는 이 경우 버그 검사와 정지 오류 화면을 통해 손상이 계속되는 것을 막는다.

응용 프로그램이 파일을 열거나 메모리를 할당하고, 프로세스를 생성하거나 장치에 접근할 때에는 사용자 모드 라이브러리와 시스템 호출을 거쳐 커널 모드의 운영체제 서비스에 요청한다.

커널과 실행부

Windows NT에서 커널과 실행부는 밀접하게 연결되어 있지만 서로 다른 역할을 담당한다.

좁은 의미의 Windows 커널은 다음과 같은 저수준 기능을 담당한다.

• 스레드 스케줄링과 문맥 전환
• 인터럽트와 예외 처리
• 다중 프로세서 동기화
• 커널 디스패처 객체
• 저수준 시간과 타이머 관리
• 프로세서별 실행 상태 관리

실행부는 커널 위에서 더 높은 수준의 운영체제 서비스를 제공한다. 실행부에는 객체 관리자, 메모리 관리자, 프로세스 및 스레드 관리자, 입출력 관리자, 보안 참조 모니터, 플러그 앤 플레이 관리자, 전원 관리자와 구성 관리자 등이 포함된다.

Microsoft의 커널 모드 문서에서는 객체 관리, 메모리 관리, 프로세스와 스레드 관리, 입출력 관리, 전원 관리, 구성 관리와 보안 참조 모니터를 주요 커널 모드 관리자 체계로 구분한다.^[31]

하드웨어 추상화 계층

하드웨어 추상화 계층은 커널과 장치 드라이버가 시스템 보드와 프로세서 플랫폼의 세부 구현에 직접 의존하지 않도록 공통 인터페이스를 제공한다.

하드웨어 추상화 계층은 다음과 같은 차이를 처리한다.

• 인터럽트 제어기
• 시스템 타이머
• 다중 프로세서 구성
• 입출력 버스
• 직접 메모리 접근
• 펌웨어와 플랫폼별 초기화
• 캐시와 메모리 매핑 방식

이 구조를 통해 Windows의 상위 커널 구성 요소는 같은 프로세서 계열 안에서 서로 다른 메인보드와 하드웨어 구성을 공통된 방식으로 다룰 수 있다. 초기 Windows NT에서는 플랫폼별 HAL 파일의 구분이 더 뚜렷했으며, 현대 Windows에서는 하드웨어 표준화와 운영체제 통합에 따라 상당 부분이 공통 구성으로 합쳐졌다.

HAL은 모든 장치를 일반화하는 범용 장치 드라이버 계층은 아니다. 그래픽 카드, 저장 장치와 네트워크 장치 같은 개별 하드웨어는 각 장치용 드라이버가 담당하며, HAL은 커널이 의존하는 기본 플랫폼 하드웨어를 추상화한다.

환경 하위 시스템

Windows NT는 하나의 커널 위에서 여러 응용 프로그램 환경을 지원할 수 있도록 환경 하위 시스템 구조를 사용했다. 초기 Windows NT에는 Win32, OS/2와 POSIX 하위 시스템이 포함되었으며, 각 하위 시스템은 해당 응용 프로그램 환경의 API와 실행 규칙을 제공했다.

Win32 하위 시스템은 이후 Windows의 주 응용 프로그램 환경이 되었다. 사용자 인터페이스, 콘솔, 프로세스 생성과 여러 Windows API 기능은 사용자 모드 라이브러리와 하위 시스템 프로세스, 커널 모드 구성 요소가 함께 처리한다.

OS/2와 초기 POSIX 하위 시스템은 이후 제거되었다. UNIX 호환 기능은 Services for UNIX와 Subsystem for UNIX-based Applications 같은 별도 구성으로 이어졌으며, 현대에는 Windows Subsystem for Linux가 Linux 바이너리와 사용자 공간을 실행하는 환경을 제공한다.

환경 하위 시스템은 운영체제 커널 자체와 응용 프로그램 API를 분리한다. 응용 프로그램은 일반적으로 커널 내부 함수를 직접 호출하지 않고 Win32, .NET, WinRT 또는 다른 사용자 모드 실행 환경을 통해 운영체제 기능을 사용한다.

시스템 프로세스와 서비스

Windows는 운영체제 기능의 상당 부분을 사용자 모드 시스템 프로세스와 서비스로 실행한다. 이 구조는 모든 기능을 커널 내부에 넣지 않고, 필요한 권한과 수명 주기에 따라 별도의 프로세스로 분리할 수 있게 한다.

주요 시스템 프로세스에는 세션과 사용자 환경을 초기화하는 프로세스, 보안 인증을 처리하는 프로세스, Windows 서비스들을 실행하는 서비스 호스트와 사용자 셸을 실행하는 프로세스 등이 있다.

Windows 서비스는 사용자가 로그인하지 않은 상태에서도 백그라운드에서 실행될 수 있다. 서비스 제어 관리자가 서비스의 시작, 중지, 종속 관계와 복구 동작을 관리하며, 네트워크, 업데이트, 인쇄, 보안, 원격 관리와 장치 지원 기능이 서비스 형태로 제공된다.

과거에는 여러 서비스가 하나의 서비스 호스트 프로세스에 함께 들어가는 경우가 많았다. 현대 Windows는 충분한 메모리가 있는 시스템에서 서비스를 더 많은 프로세스로 분리하여, 한 서비스의 오류가 다른 서비스에 미치는 영향을 줄이고 상태와 자원 사용량을 쉽게 구분하는 방향으로 발전했다.

객체 관리자와 핸들

Windows NT는 프로세스, 스레드, 파일, 장치, 이벤트, 세마포어, 뮤텍스, 레지스트리 키와 접근 토큰 같은 여러 운영체제 자원을 객체로 표현한다.

객체 관리자는 다음 기능을 담당한다.

• 객체 생성과 삭제
• 객체 이름과 이름 공간 관리
• 객체 참조 횟수 관리
• 핸들 생성과 해석
• 접근 권한 검사 연결
• 프로세스 간 객체 공유

사용자 모드 프로그램은 대부분 커널 객체의 실제 메모리 주소를 직접 받지 않는다. 대신 프로세스별 핸들 테이블에 저장된 핸들을 사용한다. 핸들은 해당 프로세스가 객체에 접근하기 위한 간접 식별자이며, 읽기, 쓰기, 수정과 삭제 같은 허용된 접근 권한도 함께 관리된다.

같은 숫자의 핸들이 서로 다른 프로세스에서 다른 객체를 나타낼 수 있다. 프로세스가 다른 프로세스와 객체를 공유하려면 핸들을 상속하거나 복제하고, 이름이 있는 객체를 다시 열거나 운영체제가 제공하는 프로세스 간 전달 방식을 사용한다.

객체와 핸들 구조는 Windows의 자원 관리와 보안 모델을 연결한다. 운영체제는 프로그램이 객체를 열 때 접근 토큰과 객체의 보안 설명자를 비교하여 요청된 권한을 허용할지 결정한다.

시스템 호출

시스템 호출은 사용자 모드 프로그램이 커널 모드의 운영체제 서비스를 요청하는 경계다. 응용 프로그램은 일반적으로 시스템 호출 번호나 프로세서 명령을 직접 사용하지 않고 Windows API를 호출한다.

파일을 읽는 요청은 대체로 다음과 같은 흐름으로 처리된다.

Windows의 시스템 서비스 요청 흐름

1. 응용 프로그램이 Windows API 호출
   ↓
2. 사용자 모드 시스템 라이브러리가 요청 변환
   ↓
3. 시스템 호출 명령으로 커널 모드 진입
   ↓
4. 시스템 서비스 디스패처가 대상 서비스 선택
   ↓
5. 실행부 관리자와 장치 드라이버가 요청 처리
   ↓
6. 결과와 상태 값을 사용자 모드로 반환

Win32 API 함수와 커널 시스템 서비스는 일대일로 대응하지 않는다. 하나의 Windows API 함수가 여러 시스템 호출과 사용자 모드 처리를 조합할 수 있고, 반대로 여러 API가 같은 내부 서비스를 사용할 수도 있다.

시스템 호출 인터페이스는 운영체제 내부 구현에 속하며 버전 사이에서 변경될 수 있다. 일반 응용 프로그램은 문서화된 Windows API를 사용해야 하며, 장치 드라이버는 Windows Driver Kit에서 제공하는 커널 모드 인터페이스와 지원 루틴을 사용한다.

이러한 경계를 통해 Windows는 응용 프로그램의 요청을 검사하고, 프로세스의 접근 권한을 적용하며, 사용자 모드 코드가 커널 메모리와 하드웨어를 직접 조작하는 것을 제한한다.

Windows는 실행 중인 프로그램을 프로세스와 스레드로 나누어 관리한다. 프로세스는 가상 주소 공간, 보안 문맥, 열린 핸들과 그 밖의 시스템 자원을 보유하는 컨테이너이며, 스레드는 프로세스 안에서 프로세서 시간을 할당받아 실제 명령을 실행하는 단위다.

여러 프로세스는 기본적으로 서로 분리된 주소 공간에서 실행되지만, 같은 프로세스의 스레드는 코드와 전역 데이터, 힙, 열린 핸들과 주소 공간을 공유한다. Windows는 스레드 우선순위와 실행 상태를 기준으로 프로세서 시간을 배분하고, 대기 객체와 비동기 입출력을 이용해 실행을 조정한다.

프로세스 여러 개를 하나의 단위로 제한하거나 종료할 때에는 작업 객체를 사용하며, 여러 사용자가 로그인할 수 있는 환경에서는 세션을 통해 사용자별 대화형 환경을 구분한다. 예외와 인터럽트는 정상적인 순차 실행을 중단하여 오류나 하드웨어 사건을 처리하고, 동적 연결 라이브러리는 여러 프로그램이 공통 코드와 데이터를 사용할 수 있게 한다.

프로세스와 스레드

프로세스는 실행 중인 프로그램의 자원과 실행 환경을 나타낸다. Windows 프로세스는 일반적으로 다음 요소를 가진다.

• 고유한 프로세스 식별자
• 사적인 가상 주소 공간
• 실행 파일과 매핑된 모듈
• 열린 커널 객체 핸들
• 보안 액세스 토큰
• 환경 변수와 현재 디렉터리
• 우선순위 클래스
• 최소·최대 작업 집합 크기
• 하나 이상의 스레드

실행 파일 하나가 항상 프로세스 하나에만 대응하는 것은 아니다. 같은 응용 프로그램의 인스턴스가 여러 프로세스로 실행될 수 있고, 하나의 응용 프로그램이 안정성과 보안을 위해 여러 보조 프로세스를 생성할 수도 있다. 웹 브라우저는 탭, 확장 기능과 그래픽 작업을 별도 프로세스로 분리할 수 있으며, 서비스 호스트는 하나 이상의 시스템 서비스를 프로세스 안에서 실행할 수 있다.

프로세스가 생성되면 Windows는 프로세스 객체와 초기 주소 공간을 만들고 실행 파일과 필요한 DLL을 매핑한 뒤, 최소 하나의 기본 스레드를 생성한다. 기본 스레드가 실행 파일의 시작 코드로 진입하면서 프로그램 실행이 시작된다.

스레드는 Windows 스케줄러가 프로세서에 배치하는 기본 실행 단위다. 프로세서가 직접 실행하는 대상은 프로세스 전체가 아니라 준비 상태에 있는 스레드다. 같은 프로세스에 속한 스레드는 프로세스의 가상 주소 공간과 시스템 자원을 공유하지만, 각각 다음과 같은 독립된 실행 상태를 가진다.

• 스레드 식별자
• 레지스터와 명령 포인터
• 사용자 모드 스택과 커널 모드 스택
• 스케줄링 우선순위
• 스레드 로컬 저장소
• 예외 처리 상태
• 보류 중인 비동기 프로시저 호출
• 가장과 보안 관련 상태

Microsoft의 프로세스·스레드 문서에서도 프로세스를 가상 주소 공간과 시스템 자원을 가진 실행 환경으로, 스레드를 운영체제가 프로세서 시간을 할당하는 기본 단위로 정의한다.^[32]

한 프로세스에 스레드가 여러 개 있으면 사용자 인터페이스, 입출력, 계산과 백그라운드 작업을 동시에 진행할 수 있다. 그러나 같은 주소 공간을 공유하므로 여러 스레드가 같은 데이터에 동시에 접근하면 경쟁 상태가 발생할 수 있다. 따라서 공유 상태를 변경하는 코드에는 적절한 동기화가 필요하다.

스레드는 일반적으로 다음 상태 사이를 이동한다.

스레드 실행 상태의 기본 흐름

1. 스레드 생성
   ↓
2. 준비 상태에서 프로세서 할당 대기
   ↓
3. 프로세서에서 실행
   ↓
4. 시간 할당량 만료, 선점 또는 대기 발생
   ↓
5. 준비 상태나 대기 상태로 이동
   ↓
6. 대기 조건이 충족되면 다시 준비
   ↓
7. 실행 완료 후 종료

스레드가 입출력이나 동기화 객체를 기다리는 동안에는 프로세서를 사용하지 않는다. 기다리던 조건이 충족되면 준비 상태가 되고, 스케줄러가 적절한 프로세서에 배치할 때 다시 실행된다.

Windows는 응용 프로그램이 직접 생성하는 스레드 외에도 스레드 풀을 제공한다. 스레드 풀은 작업마다 새 스레드를 반복적으로 생성하는 비용을 줄이고, 비동기 콜백, 타이머, 대기와 입출력 완료 작업을 제한된 수의 작업자 스레드에서 처리한다.

파이버는 응용 프로그램이 직접 전환하는 사용자 모드 실행 단위다. 파이버 자체는 커널 스케줄러의 독립된 스케줄링 대상이 아니며, 자신을 실행하는 스레드의 문맥 안에서 동작한다. Microsoft는 일반적인 다중 스레드 프로그램에서는 파이버가 특별한 이점을 제공하지 않으며, 자체 스케줄링 구조를 가진 기존 프로그램을 이식하는 용도로 주로 사용된다고 설명한다.^[33]

작업과 세션

Windows에서 작업은 일반적인 실행 과제를 뜻하는 표현이 아니라, 여러 프로세스를 하나의 단위로 관리하는 작업 객체를 의미한다. 작업 객체는 이름을 가질 수 있고 보안과 공유가 가능한 커널 객체이며, 연결된 프로세스 전체에 공통 제한과 관리 동작을 적용한다.

작업 객체에는 다음과 같은 정책을 설정할 수 있다.

• 프로세스 수 제한
• 프로세스별 또는 작업 전체 CPU 시간 제한
• 프로세스 우선순위 제한
• 작업 집합과 메모리 사용 제한
• CPU 사용률 제한
• 사용자 인터페이스 접근 제한
• 프로세서 선호도 제한
• 입출력과 네트워크 사용량 추적
• 모든 연결 프로세스의 일괄 종료
• 프로세스 생성과 종료 알림

프로세스를 작업 객체에 연결하면 해당 프로세스와 그 하위 프로세스 트리를 하나의 응용 프로그램 단위처럼 다룰 수 있다. 브라우저, 빌드 도구, 서버 작업자, 샌드박스와 컨테이너처럼 여러 프로세스로 구성된 프로그램의 자원 사용량을 통제하는 데 적합하다.

Windows 8과 Windows Server 2012 이후에는 작업 객체를 중첩할 수 있다. 이 구조에서는 프로세스가 직접 연결된 작업뿐 아니라 상위 작업의 제한도 적용받는다. 서로 다른 관리 계층이 각자의 정책을 추가하는 구조를 만들 수 있다.^[34]

세션은 로그인한 사용자와 그 사용자의 대화형 실행 환경을 격리하는 단위다. 각 세션에는 고유한 세션 식별자가 부여되며, 세션마다 사용자 프로세스와 창 스테이션, 데스크톱, 입력 및 표시 환경을 가질 수 있다.

로컬 콘솔에서 로그인한 사용자와 원격 데스크톱으로 로그인한 사용자는 서로 다른 세션에서 실행될 수 있다. Windows Server의 원격 데스크톱 세션 호스트나 Windows 다중 세션 환경에서는 여러 사용자가 같은 운영체제 인스턴스에 동시에 로그인하면서도 각자 독립된 바탕 화면과 응용 프로그램을 사용한다.

각 대화형 세션에는 일반적으로 WinSta0이라는 대화형 창 스테이션이 있으며, 그 안에 로그인 화면, 화면 보호기와 사용자의 대화형 데스크톱이 구성된다. 같은 이름의 창 스테이션이라도 세션이 다르면 서로 다른 객체다.^[35]

세션에서 연결을 끊는 것과 로그오프하는 것은 다르다.

• 연결 끊기는 화면과 입력 연결을 종료하지만 세션과 응용 프로그램을 계속 실행할 수 있다.
• 로그오프는 해당 사용자 세션의 응용 프로그램과 사용자 환경을 종료한다.
• 다시 연결하면 실행 중이던 세션의 바탕 화면과 프로그램으로 돌아갈 수 있다.

현대 Windows에서는 시스템 서비스가 주로 세션 0에서 실행되고, 사용자 대화형 세션과 분리된다. 이 분리는 높은 권한으로 실행되는 서비스가 사용자 화면과 직접 상호 작용하면서 발생할 수 있는 보안 문제를 줄인다. 사용자에게 화면을 제공해야 하는 서비스는 별도의 사용자 모드 응용 프로그램과 프로세스 간 통신을 사용하는 구조로 구현한다.

작업 객체와 세션은 서로 다른 차원의 분류다. 작업 객체는 프로세스들의 자원과 수명 주기를 묶고, 세션은 로그인 환경과 대화형 객체를 구분한다. 하나의 세션에는 여러 작업 객체가 존재할 수 있으며, 하나의 응용 프로그램이 생성한 프로세스들은 특정 작업 객체와 특정 세션에 동시에 속할 수 있다.

스케줄링

Windows는 선점형 우선순위 기반 스케줄링을 사용한다. 실행 가능한 스레드 가운데 우선순위가 높은 스레드가 먼저 프로세서를 사용하며, 현재 실행 중인 스레드보다 높은 우선순위의 스레드가 준비 상태가 되면 현재 스레드를 선점할 수 있다.

Windows의 스케줄링 우선순위는 0부터 31까지의 단계로 표현된다. 우선순위 0은 시스템의 특별한 제로 페이지 스레드에 사용되며, 일반 스레드는 1부터 31 사이에서 실행된다. 일반적으로 다음과 같이 구분된다.

• 1~15: 가변 우선순위 범위
• 16~31: 실시간 우선순위 범위

일반 응용 프로그램의 스레드 우선순위는 프로세스의 우선순위 클래스와 스레드의 상대 우선순위를 조합하여 결정된다. 프로세스 우선순위 클래스에는 Idle, Below Normal, Normal, Above Normal, High와 Realtime 등이 있다.

실시간 우선순위는 오디오·영상 처리나 장치 제어처럼 매우 낮은 지연이 필요한 일부 작업에 사용할 수 있다. 그러나 높은 우선순위 스레드가 계속 실행되면 사용자 입력, 디스크 캐시와 시스템 관리 스레드가 프로세서 시간을 얻지 못할 수 있으므로 일반 응용 프로그램에서 무분별하게 사용하지 않는다.

Microsoft 문서에 따르면 Windows 스레드는 스케줄링 우선순위를 기준으로 실행되며, 우선순위 수준은 0부터 31까지 구성된다.^[36]

같은 우선순위에 준비된 스레드가 여러 개 있으면 일정한 시간 할당량인 퀀텀을 기준으로 프로세서 시간을 나누어 사용한다. 다음 상황에서는 문맥 전환이 일어날 수 있다.

• 실행 중인 스레드의 퀀텀이 만료됨
• 더 높은 우선순위의 스레드가 준비됨
• 실행 중인 스레드가 대기 상태로 들어감
• 스레드가 자발적으로 실행을 양보함
• 인터럽트나 커널 동작으로 재스케줄링이 필요해짐

스레드가 동기화 객체나 입출력을 기다리면 남은 퀀텀을 포기하고 대기 상태가 된다. 기다리던 조건이 충족되기 전까지는 우선순위가 높더라도 프로세서 시간을 받지 않는다.^[37]

대기 상태의 스레드가 사용자 입력이나 입출력 완료로 깨어날 때에는 일시적인 우선순위 상승이 적용될 수 있다. 이는 대화형 응답성을 높이고, 장치를 기다린 스레드가 빠르게 후속 처리를 마치도록 돕는다. 일정 시간이 지나면 우선순위는 기본 수준으로 감소한다.

다중 프로세서 시스템에서는 스케줄러가 우선순위뿐 아니라 다음 정보도 고려한다.

• 스레드의 프로세서 선호도
• 이상적인 프로세서
• 직전에 실행된 프로세서
• 프로세서 캐시 지역성
• NUMA 노드
• 프로세서 그룹
• 효율 코어와 성능 코어의 특성
• 전원 및 에너지 정책

프로세서 선호도를 지정하면 스레드가 실행될 수 있는 논리 프로세서 집합을 제한할 수 있다. 다만 일반 응용 프로그램이 지나치게 좁은 선호도를 고정하면 시스템 스케줄러의 부하 분산과 전력 관리 능력을 방해할 수 있다.

Windows의 디스패처는 스레드 우선순위, 상태, 퀀텀, 선호도와 이상적인 프로세서를 바탕으로 문맥 전환과 실행 대상을 결정한다.^[38]

동기화

여러 스레드가 같은 메모리와 객체를 공유하면 실행 순서에 따라 결과가 달라지는 경쟁 상태가 발생할 수 있다. Windows는 공유 자원 접근을 직렬화하거나 스레드 사이의 사건 발생 순서를 전달하기 위해 여러 동기화 수단을 제공한다.

Windows의 대기 가능한 동기화 객체는 신호 상태와 비신호 상태를 가진다. 스레드는 하나 이상의 객체가 신호 상태가 될 때까지 기다릴 수 있으며, 조건이 충족되면 다시 준비 상태로 전환된다.^[39]

주요 동기화 객체는 다음과 같다.

이벤트는 수동 재설정과 자동 재설정 방식으로 나뉜다. 자동 재설정 이벤트는 일반적으로 대기 중인 스레드 하나를 깨운 뒤 자동으로 비신호 상태로 돌아간다. 수동 재설정 이벤트는 명시적으로 재설정할 때까지 신호 상태를 유지하여 여러 스레드를 깨울 수 있다.

뮤텍스는 특정 스레드가 소유권을 가진다. 소유한 스레드만 정상적으로 해제할 수 있으며, 소유 스레드가 뮤텍스를 해제하지 않고 종료되면 대기 중인 다른 스레드는 포기된 뮤텍스 상태를 감지할 수 있다.

세마포어는 현재 사용 가능한 자원의 개수를 나타내는 계수를 가진다. 스레드가 자원을 획득하면 계수가 감소하고, 반환하면 증가한다. 연결 풀이나 제한된 수의 작업 슬롯처럼 같은 종류의 자원이 여러 개 있을 때 사용한다.

이러한 객체는 여러 프로세스가 같은 객체 핸들을 공유하거나 이름으로 열 수 있으므로 프로세스 간 동기화에도 사용할 수 있다.^[40]

같은 프로세스 안의 스레드만 동기화할 때에는 임계 구역을 사용할 수 있다. 임계 구역은 일반적으로 커널 객체를 사용하는 뮤텍스보다 가볍고, 경합이 없을 때 대부분 사용자 모드에서 빠르게 진입할 수 있다. 다만 다른 프로세스와 공유할 수 없다.

Slim Reader/Writer Lock은 여러 읽기 스레드의 동시 접근을 허용하면서 쓰기 작업에는 배타적 접근을 제공한다. 조건 변수는 특정 조건이 만족될 때까지 임계 구역이나 SRW 잠금을 해제한 상태로 기다렸다가 다시 잠금을 획득하도록 한다.

커널 내부에서는 스핀 락, 디스패처 객체, 빠른 뮤텍스, 푸시 락과 인터록 연산 등이 사용된다. 스핀 락은 잠금이 풀릴 때까지 프로세서를 양보하지 않고 반복 확인하므로, 매우 짧은 커널 임계 구역에서 사용한다.

동기화 설계에서는 교착 상태도 고려해야 한다. 여러 스레드가 서로 상대방이 소유한 자원을 기다리면 아무도 진행하지 못한다. 잠금 획득 순서를 일관되게 유지하고, 잠금 안에서 장시간 대기나 외부 코드를 호출하지 않으며, 필요한 경우 시간 제한 대기를 사용해 위험을 줄인다.

예외와 인터럽트

예외와 인터럽트는 현재 실행 흐름을 중단하고 운영체제의 처리 루틴으로 제어를 넘긴다. 두 개념은 모두 프로세서의 정상 실행 순서를 바꾸지만 발생 원인이 다르다.

예외는 현재 실행 중인 명령과 직접 관련된 동기적 사건이다. 대표적인 예는 다음과 같다.

• 존재하지 않거나 허용되지 않은 메모리 접근
• 0으로 나누기
• 잘못된 명령 실행
• 정렬 조건 위반
• 중단점과 단일 단계 디버깅
• 페이지 폴트
• 스택 오버플로
• 프로그램이 명시적으로 발생시킨 소프트웨어 예외

페이지 폴트가 항상 오류를 의미하지는 않는다. 접근한 가상 메모리 페이지가 아직 물리 메모리에 없으면 메모리 관리자가 저장 장치나 파일 매핑에서 페이지를 가져온 뒤 명령 실행을 계속할 수 있다. 접근 자체가 허용되지 않는 경우에는 접근 위반 예외가 된다.

Windows 사용자 모드 프로그램은 구조적 예외 처리를 통해 하드웨어 및 소프트웨어 예외를 처리할 수 있다. 예외가 발생하면 시스템은 등록된 예외 처리기를 탐색하며, 처리기가 예외를 처리하면 실행을 복구하거나 정리 작업을 수행할 수 있다.

디버거가 연결되어 있으면 예외는 먼저 디버거에 첫 번째 기회로 전달될 수 있다. 디버거가 처리하지 않으면 프로그램의 예외 처리기가 실행된다. 처리되지 않은 사용자 모드 예외는 일반적으로 해당 프로세스의 종료로 이어진다.

커널 모드 예외는 시스템 전체에 영향을 줄 수 있다. 커널이나 드라이버가 예외를 적절히 처리하지 못하면 Windows는 손상된 상태에서 실행을 계속하지 않고 버그 검사를 수행하여 시스템을 중지할 수 있다. Microsoft 문서도 커널 모드 예외가 사용자 모드 예외보다 시스템에 더 심각한 영향을 줄 수 있다고 설명한다.^[41]

인터럽트는 주로 프로세서 외부의 하드웨어나 타이머가 발생시키는 비동기적 사건이다. 저장 장치 작업 완료, 네트워크 패킷 수신, 키보드 입력과 시스템 타이머 등이 인터럽트를 발생시킬 수 있다.

Windows는 선 기반 인터럽트와 메시지 신호 인터럽트를 지원한다. 선 기반 인터럽트는 물리적 인터럽트 신호를 사용하고, 메시지 신호 인터럽트는 장치가 특정 메모리 주소에 메시지를 기록하여 인터럽트를 전달한다.^[42]

인터럽트 처리는 일반적으로 다음 흐름을 따른다.

장치 인터럽트 처리 흐름

1. 장치가 작업 완료 또는 상태 변화를 알림
   ↓
2. 프로세서가 현재 실행을 잠시 중단
   ↓
3. 커널이 등록된 인터럽트 서비스 루틴 호출
   ↓
4. 인터럽트 서비스 루틴이 최소한의 긴급 작업 수행
   ↓
5. 나머지 처리를 지연 프로시저 호출로 예약
   ↓
6. 낮아진 우선순위에서 장치 요청과 입출력 완료 처리
   ↓
7. 대기 중인 스레드를 준비 상태로 전환

인터럽트 서비스 루틴은 높은 인터럽트 요청 수준에서 실행되므로 가능한 짧게 동작해야 한다. 긴 계산이나 블로킹 작업은 보통 지연 프로시저 호출이나 별도 작업 항목으로 넘긴다.

Windows 커널은 인터럽트 요청 수준을 사용해 현재 프로세서에서 실행할 수 있는 커널 작업과 차단되는 인터럽트 범위를 제어한다. 높은 수준의 인터럽트가 낮은 수준의 작업을 선점할 수 있으며, 같은 수준 이하의 인터럽트는 일시적으로 가려질 수 있다.

동적 연결 라이브러리

동적 연결 라이브러리 또는 DLL은 다른 실행 파일이나 DLL에서 사용할 수 있는 함수와 데이터를 포함한 모듈이다. Windows API 자체도 여러 DLL로 구현되므로, Windows 응용 프로그램 대부분은 동적 연결을 사용한다.^[43]

정적 연결에서는 라이브러리 코드가 각 실행 파일에 복사된다. 동적 연결에서는 실행 파일이 DLL의 내보낸 함수와 데이터를 참조하고, Windows 로더가 실행 시 필요한 DLL을 프로세스 주소 공간에 매핑한다.

DLL을 사용하는 방식은 크게 두 가지다.

• 로드 시간 동적 연결은 실행 파일의 가져오기 테이블에 DLL과 함수 정보가 기록된다. 프로세스가 시작될 때 로더가 필요한 DLL을 찾아 매핑하고 가져오기 주소를 해결한다.
• 실행 시간 동적 연결은 프로그램이 LoadLibrary 또는 LoadLibraryEx로 DLL을 직접 불러오고, GetProcAddress로 내보낸 함수 주소를 얻는다.

Microsoft 문서에서는 로드 시간 연결과 실행 시간 연결을 DLL 함수 사용의 두 기본 방식으로 구분한다.^[44]

DLL은 다음 목적으로 사용된다.

• 여러 실행 파일이 공통 코드를 공유
• 응용 프로그램 크기 감소
• 선택적 기능과 플러그인 구현
• 운영체제 API 모듈화
• 언어 리소스와 테마 분리
• 장치와 구성에 따른 구현 선택
• 실행 중 기능 확장

같은 DLL의 코드 페이지는 여러 프로세스의 주소 공간에 매핑되더라도 물리 메모리에서 공유될 수 있다. 반면 DLL의 쓰기 가능한 전역 데이터는 일반적으로 프로세스마다 사적인 복사본을 가진다.

DLL이 프로세스에 처음 연결되거나 분리되고, 스레드가 생성되거나 종료될 때에는 DLL 진입점에 알림이 전달될 수 있다. 그러나 DLL 로더는 이 과정에서 내부 로더 잠금을 보유하므로 진입점에서 다른 DLL을 불러오거나 스레드를 기다리는 등 복잡한 작업을 수행하면 교착 상태가 발생할 수 있다. 초기화가 복잡한 DLL은 진입점에서 최소한의 작업만 하고 실제 초기화는 별도 함수나 지연 초기화로 수행한다.

로더는 DLL 이름과 검색 규칙에 따라 불러올 파일을 결정한다. 프로그램이 신뢰할 수 없는 디렉터리에서 같은 이름의 DLL을 불러오면 DLL 검색 순서 하이재킹이 발생할 수 있다. 따라서 응용 프로그램은 가능한 경우 절대 경로, 안전한 DLL 검색 설정과 패키지 의존성을 사용해야 한다. Microsoft 역시 경로를 완전히 지정하지 않은 DLL 로딩에서는 정해진 디렉터리 검색 순서가 적용되므로 보안에 주의해야 한다고 설명한다.^[45]

Windows는 시스템 DLL의 호환성을 유지하기 위해 전달 DLL, API 세트, 병렬 어셈블리와 리디렉션 같은 구조를 사용해 왔다. 응용 프로그램이 참조하는 논리적 API 이름과 실제 구현 DLL이 항상 일치하지 않을 수 있으며, 운영체제 버전과 프로세서 아키텍처에 따라 적절한 구현으로 연결될 수 있다.

32비트 Windows 응용 프로그램과 64비트 응용 프로그램은 서로 다른 주소 공간과 모듈 형식을 사용한다. 32비트 프로세스는 32비트 DLL만 직접 로드할 수 있고, 64비트 프로세스는 64비트 DLL만 직접 로드할 수 있다. 서로 다른 비트 수의 구성 요소를 연결하려면 별도 프로세스와 프로세스 간 통신, COM 서버 또는 그 밖의 중개 구조가 필요하다.

Windows의 저장 장치 계층은 응용 프로그램이 사용하는 파일과 디렉터리에서 시작하여 파일 시스템, 볼륨, 파티션, 가상 디스크, 저장 장치 드라이버와 실제 하드웨어로 이어진다. 응용 프로그램은 일반적으로 물리 디스크의 섹터를 직접 다루지 않고, Windows API를 통해 파일이나 볼륨에 대한 입출력을 요청한다.

입출력 관리자는 이 요청을 파일 시스템 드라이버와 저장 장치 드라이버로 전달한다. 파일 시스템은 파일 이름, 디렉터리, 접근 권한과 파일 데이터를 논리적인 구조로 관리하고, 볼륨 관리 계층과 장치 드라이버는 이를 실제 디스크의 블록 요청으로 변환한다.

Windows 저장 장치 계층

• 응용 프로그램
  • Windows 파일 및 저장 장치 API
    • 입출력 관리자
      • 캐시 관리자와 메모리 관리자
      • 파일 시스템 드라이버
        • NTFS
        • ReFS
        • FAT32
        • exFAT
          • 볼륨 관리자
            • 기본 디스크의 파티션
            • 동적 볼륨
            • 저장 공간 가상 디스크
            • 가상 하드 디스크
              • 저장 장치 드라이버 스택
                • 디스크 클래스 드라이버
                • 포트 및 미니포트 드라이버
                • 버스 드라이버
                  • HDD, SSD, NVMe, USB와 SAN 장치

Windows는 내부 저장 장치뿐 아니라 USB 플래시 드라이브, 메모리 카드, 광학 디스크, 네트워크 공유, 가상 하드 디스크와 원격 저장 장치도 파일과 볼륨이라는 공통 인터페이스를 통해 다룬다. 다만 장치의 특성과 파일 시스템에 따라 지원되는 접근 제어, 암호화, 저널링, 복구와 최대 용량이 달라진다.

입출력 관리자

입출력 관리자는 Windows 실행부의 구성 요소로, 응용 프로그램과 장치 드라이버 사이의 입출력 요청을 관리한다. 응용 프로그램이 파일을 열거나 데이터를 읽고 쓰면 사용자 모드의 Windows API 호출이 시스템 호출로 변환되고, 입출력 관리자가 요청에 맞는 파일 시스템과 장치 드라이버 스택으로 전달한다.

Windows의 장치는 장치 객체로 표현된다. 하나의 물리 장치에는 여러 장치 객체와 드라이버가 계층적으로 연결될 수 있으며, 이 연결을 드라이버 스택이라고 한다. 예를 들어 USB 저장 장치 요청은 파일 시스템 드라이버, 볼륨 드라이버, 디스크 클래스 드라이버, USB 저장 장치 드라이버, USB 허브와 호스트 컨트롤러 드라이버를 차례로 통과할 수 있다.

입출력 관리자는 대부분의 커널 모드 입출력 요청을 입출력 요청 패킷 또는 IRP로 표현한다. IRP에는 요청 종류, 대상 장치, 버퍼, 파일 위치, 완료 상태와 각 드라이버가 사용할 스택 위치가 포함된다. Microsoft는 Windows의 모든 드라이버가 일관된 입출력 모델을 사용하고, 드라이버에 전달되는 요청이 주로 IRP 형태로 구성된다고 설명한다.^[46]

파일 읽기 요청의 기본 흐름

1. 응용 프로그램이 파일 읽기 API 호출
   ↓
2. 객체 관리자가 파일 핸들 확인
   ↓
3. 입출력 관리자가 읽기 요청 생성
   ↓
4. 파일 시스템 드라이버가 파일 위치를 볼륨 블록으로 변환
   ↓
5. 볼륨과 저장 장치 드라이버 스택으로 요청 전달
   ↓
6. 저장 장치가 데이터를 메모리로 전송
   ↓
7. 드라이버가 요청 완료
   ↓
8. 입출력 관리자가 결과를 응용 프로그램에 반환

IRP는 하나의 드라이버에서 처리가 끝날 수도 있고 여러 드라이버를 차례로 통과할 수도 있다. 상위 드라이버는 요청을 해석하거나 필터링한 뒤 하위 드라이버에 전달하고, 하위 장치가 처리를 완료하면 완료 루틴이 역순으로 실행될 수 있다.

Windows는 장치의 기능을 계층적으로 구성하기 위해 다음과 같은 드라이버를 사용한다.

• 버스 드라이버는 PCI, USB와 같은 버스를 검색하고 연결된 장치를 열거한다.
• 기능 드라이버는 특정 장치의 주요 기능을 구현한다.
• 필터 드라이버는 기존 요청을 관찰하거나 수정하여 암호화, 보안 검사, 가상화와 추가 기능을 제공한다.
• 파일 시스템 드라이버는 파일과 디렉터리를 볼륨의 저장 블록에 대응시킨다.
• 파일 시스템 미니필터는 파일 작업을 감시하거나 변경하며 백신, 백업, 암호화와 데이터 손실 방지 프로그램에서 사용된다.

입출력은 동기 또는 비동기 방식으로 수행할 수 있다. 동기 입출력에서는 호출한 스레드가 작업 완료를 기다리지만, 비동기 입출력에서는 요청을 제출한 뒤 다른 작업을 계속할 수 있다. 완료 상태는 이벤트, 콜백, 비동기 프로시저 호출 또는 입출력 완료 포트를 통해 전달된다.

입출력 완료 포트는 많은 동시 연결과 비동기 요청을 처리하는 서버 프로그램에서 사용된다. 여러 파일이나 네트워크 요청의 완료 알림을 제한된 수의 작업자 스레드에 분배하여, 요청마다 별도의 스레드를 유지하는 비용을 줄인다.

Windows의 파일 입출력에는 캐시 관리자와 메모리 관리자도 관여한다. 캐시된 파일 읽기는 데이터가 이미 시스템 파일 캐시에 있으면 저장 장치에 접근하지 않고 메모리에서 처리될 수 있다. 파일 매핑은 파일 내용을 프로세스의 가상 주소 공간에 연결하고, 페이지 폴트를 통해 필요한 부분을 불러온다.

쓰기 요청도 즉시 물리 장치에 기록되지 않고 캐시에 머물 수 있다. 지연 쓰기 기능은 여러 작은 쓰기를 모아 효율적으로 저장 장치에 기록하지만, 응용 프로그램이 데이터의 영구 기록을 보장해야 할 때에는 버퍼를 명시적으로 플러시하거나 쓰기 통과 옵션을 사용할 수 있다.

입출력 관리자는 플러그 앤 플레이 관리자와 전원 관리자와도 협력한다. 장치가 연결·분리되거나 절전 상태로 전환될 때 드라이버 스택에 관련 요청을 전달하고, 처리 중인 입출력을 중지하거나 다시 시작한다.

NTFS

NTFS는 Windows NT와 현대 Windows에서 주로 사용하는 범용 파일 시스템이다. 최초의 Windows NT부터 사용되었으며, 현재 Windows 시스템 볼륨과 일반 내부 저장 장치의 기본 파일 시스템으로 사용된다.

NTFS는 파일과 디렉터리의 정보를 마스터 파일 테이블 또는 MFT에 저장한다. 볼륨에 존재하는 각 파일과 디렉터리는 하나 이상의 MFT 레코드를 가지며, 레코드에는 이름, 시간 정보, 보안 정보와 파일 데이터의 위치를 나타내는 특성이 기록된다. 크기가 매우 작은 파일은 데이터 일부 또는 전체가 MFT 레코드 안에 직접 저장될 수도 있다.^[47]

NTFS의 파일과 디렉터리는 단순한 연속 블록이 아니라 여러 특성의 집합으로 구성된다. 파일 이름, 표준 정보, 보안 설명자와 실제 데이터도 각각 특성으로 표현된다. 기본 데이터 스트림 외에 이름이 붙은 추가 데이터 스트림을 저장할 수 있으며, 이를 대체 데이터 스트림이라고 한다.

NTFS의 주요 기능은 다음과 같다.

• 파일과 디렉터리별 접근 제어 목록
• 소유자와 보안 설명자
• 메타데이터 저널링
• 변경 저널
• 파일 압축
• EFS 파일 암호화
• 사용자별 디스크 할당량
• 하드 링크와 심볼릭 링크
• 재분석 지점
• 볼륨 섀도 복사본 연동
• 희소 파일
• 트랜잭션과 복구 기능
• 대체 데이터 스트림
• 큰 파일과 대용량 볼륨 지원

NTFS의 접근 제어는 Windows 보안 모델과 결합된다. 파일과 디렉터리의 보안 설명자에는 소유자, 사용자와 그룹별 허용·거부 항목, 감사 정책이 포함된다. 프로세스가 파일을 열 때 Windows는 프로세스의 액세스 토큰과 파일의 접근 제어 목록을 비교해 요청된 읽기, 쓰기, 실행, 삭제와 권한 변경을 허용할지 결정한다.

디렉터리의 권한은 하위 파일과 디렉터리에 상속될 수 있다. 명시적으로 설정된 권한과 부모로부터 상속된 권한은 함께 평가되며, 관리자는 상속을 중단하거나 개별 항목을 수정할 수 있다.

NTFS는 메타데이터 변경을 로그 파일에 기록하는 저널링 파일 시스템이다. 시스템이 예기치 않게 중단되면 로그를 재생하여 파일 시스템 메타데이터를 일관된 상태로 복구한다. 저널링은 최근 수정한 사용자 파일의 모든 내용을 반드시 복구하는 기능은 아니며, 주로 파일 시스템 구조가 손상되지 않도록 보호한다.

변경 저널은 볼륨에서 발생한 파일과 디렉터리 변경을 기록한다. 검색 인덱서, 백업 프로그램과 파일 동기화 도구는 전체 볼륨을 반복해서 검사하는 대신 변경 저널을 이용해 수정된 항목을 확인할 수 있다.

NTFS 압축은 파일과 디렉터리 단위로 적용할 수 있다. 압축된 파일은 읽을 때 자동으로 해제되고 쓸 때 다시 압축되므로 응용 프로그램은 일반 파일처럼 접근한다. 다만 압축과 EFS 암호화는 같은 파일에 동시에 적용할 수 없다.

희소 파일은 실제 데이터가 없는 긴 영역에 물리 저장 공간을 할당하지 않는다. 가상 디스크, 데이터베이스와 대형 이미지처럼 파일의 논리적 크기에 비해 실제 데이터가 적은 경우 저장 공간을 줄일 수 있다.

재분석 지점은 파일 시스템 동작을 다른 드라이버나 필터로 넘기기 위한 메타데이터다. 디렉터리 접합점, 볼륨 탑재 지점, 심볼릭 링크, OneDrive의 온라인 전용 파일과 여러 계층형 저장 기능이 재분석 지점을 사용한다.

NTFS는 Windows의 가장 폭넓은 기능을 지원하지만, 이동식 저장 장치와 여러 운영체제 사이의 단순한 데이터 교환에는 exFAT이 더 적합할 수 있다. NTFS의 접근 권한, 저널링과 부가 특성을 완전하게 지원하지 않는 운영체제나 장치에서는 읽기·쓰기 호환성이 제한될 수 있다.

ReFS

ReFS 또는 Resilient File System은 데이터 무결성, 가용성, 대규모 저장소와 손상 복원력을 중시하여 Microsoft가 개발한 파일 시스템이다. Windows Server의 파일 서버, 가상화 저장소와 대용량 데이터 환경을 주요 대상으로 하며, 일부 Windows 클라이언트 에디션에서도 제한된 용도로 지원된다.

ReFS는 NTFS를 그대로 확장한 버전이 아니라 별도로 설계된 파일 시스템이다. Windows의 파일 API와 보안 모델을 공유하고 여러 NTFS 기능과 호환되지만, 내부 디스크 구조와 메타데이터 관리 방식은 다르다.

ReFS는 메타데이터를 갱신할 때 기존 블록을 직접 덮어쓰기보다 새 위치에 변경 내용을 기록하고 참조를 전환하는 할당 시 쓰기 방식을 사용한다. 이를 통해 수정 도중 전원 장애가 발생해도 기존의 유효한 메타데이터 구조를 보존하도록 설계되었다.

ReFS의 주요 목표는 다음과 같다.

• 메타데이터와 선택적 파일 데이터의 무결성 검사
• 손상된 데이터 감지
• 중복 사본을 이용한 자동 복구
• 대용량 볼륨과 매우 많은 파일 처리
• 장시간 파일 시스템 검사 없이 온라인 상태 유지
• 가상화와 대규모 저장 작업의 성능 향상
• Storage Spaces와의 통합

ReFS는 메타데이터에 체크섬을 사용한다. 파일 데이터에도 무결성 스트림을 설정하면 데이터 체크섬을 유지할 수 있다. 읽기 과정에서 체크섬이 일치하지 않으면 손상을 감지하고, 미러 또는 패리티 Storage Spaces에 정상 사본이 존재하는 경우 해당 사본을 이용해 자동 복구할 수 있다.^[48][49]

무결성 스크러버는 저장된 데이터를 주기적으로 검사하여 일반적인 읽기 작업에서 발견되지 않은 잠재적 손상을 찾는다. Storage Spaces의 중복 데이터와 결합하면 손상된 사본을 정상 사본으로 교체할 수 있다.

ReFS에는 가상화 작업을 위한 기능도 포함된다. 블록 복제는 파일의 큰 영역을 실제로 복사하지 않고 기존 블록을 새 파일 범위에 참조하도록 하여 가상 하드 디스크 병합과 복제 작업을 빠르게 처리한다. 희소 VDL은 대형 고정 크기 가상 하드 디스크 생성과 확장을 효율적으로 수행한다.

ReFS는 NTFS가 제공하는 모든 기능을 지원하지 않는다. 버전과 제품에 따라 다음과 같은 기능이 제한되거나 제공되지 않을 수 있다.

• Windows 시스템 부팅 볼륨
• EFS 파일 암호화
• NTFS 파일 압축
• 디스크 할당량
• 일부 재분석 지점과 레거시 응용 프로그램 기능
• 일부 이동식 미디어와 외부 장치 환경

따라서 ReFS는 NTFS를 모든 용도에서 대체하기보다, 데이터 가용성, 규모와 복원력이 중요한 특정 저장 작업을 보완한다. Windows 운영체제 부팅과 일반 데스크톱 파일 저장에는 NTFS가 중심이고, 대규모 파일 서버, Hyper-V 가상 디스크와 Storage Spaces 기반 저장소에는 ReFS가 선택될 수 있다.

FAT와 exFAT

FAT 계열은 파일 할당 테이블을 이용해 파일이 저장된 클러스터의 연결 관계를 관리하는 비교적 단순한 파일 시스템이다. 초기 MS-DOS와 Windows에서 사용되었으며, 구조가 단순하고 여러 운영체제와 전자 장치에서 구현하기 쉬워 이동식 저장 장치와 호환성 중심 환경에서 계속 사용된다.

FAT 계열에는 FAT12, FAT16과 FAT32가 있다.

• FAT12는 플로피 디스크와 매우 작은 볼륨에 사용되었다.
• FAT16은 초기 하드 디스크와 MS-DOS, 초기 Windows에서 널리 사용되었다.
• FAT32는 더 큰 볼륨과 작은 클러스터를 지원하기 위해 Windows 95 OSR2에서 도입되었다.

FAT 파일 시스템은 볼륨의 파일 할당 테이블에 각 클러스터의 사용 상태와 다음 클러스터 위치를 기록한다. 디렉터리 항목에는 파일 이름, 속성, 시간 정보, 시작 클러스터와 크기가 저장된다.

FAT32는 구조가 단순하고 UEFI 펌웨어, 카메라, 게임기, 차량 장치와 여러 운영체제에서 폭넓게 지원된다. UEFI 시스템 파티션도 일반적으로 FAT 계열 파일 시스템을 사용한다.

그러나 FAT32에는 현대적인 범용 파일 시스템으로서 여러 제약이 있다.

• 단일 파일 크기가 4GiB보다 작아야 함
• Windows식 접근 제어 목록을 지원하지 않음
• 메타데이터 저널링을 지원하지 않음
• EFS와 파일 시스템 수준 암호화를 지원하지 않음
• 파일 압축과 사용자별 할당량을 지원하지 않음
• 대체 데이터 스트림을 지원하지 않음

exFAT은 FAT32의 이동식 저장 장치 호환성을 유지하면서 대용량 플래시 저장 장치와 큰 파일을 지원하기 위해 개발되었다. Microsoft는 exFAT을 FAT32의 후속 파일 시스템으로 정의하며, 64비트 파일 크기 필드를 사용해 FAT32의 4GiB 파일 제한을 제거했다.^[50]

exFAT은 주로 다음과 같은 환경에 사용된다.

• 대용량 USB 플래시 드라이브
• SDXC와 대용량 메모리 카드
• 외장 SSD와 이동식 디스크
• Windows와 macOS 사이의 파일 교환
• 카메라와 영상 녹화 장치
• 4GiB를 넘는 미디어 파일 저장

exFAT은 파일의 연속 영역을 효율적으로 표현하고 여유 공간 비트맵을 사용해 빈 클러스터를 빠르게 찾을 수 있다. FAT32보다 큰 파일과 볼륨을 지원하지만, NTFS와 같은 접근 제어, 메타데이터 저널링, 압축, 사용자 할당량과 EFS는 제공하지 않는다.

Windows의 파일 시스템 기능 비교에서 NTFS는 메타데이터 저널링, 접근 제어 목록, 파일 시스템 암호화와 압축을 지원하지만, FAT32와 exFAT은 이러한 기능을 제공하지 않는다.^[51]

따라서 일반적인 Windows 내부 시스템 디스크에는 NTFS가 사용되고, 대규모 서버 저장소에는 ReFS가 선택될 수 있으며, 이동식 저장 장치와 운영체제 간 교환에는 FAT32 또는 exFAT이 주로 사용된다.

볼륨과 파티션

물리 디스크, 파티션, 볼륨과 파일 시스템은 서로 관련되지만 같은 개념은 아니다.

• 물리 디스크는 HDD, SSD, NVMe 장치나 가상 디스크와 같은 저장 매체다.
• 파티션은 한 디스크의 주소 범위를 나눈 영역이다.
• 볼륨은 Windows가 하나의 저장 단위로 탑재하고 관리하는 논리적 공간이다.
• 파일 시스템은 볼륨 안에서 파일과 디렉터리를 구성하는 형식이다.

기본 디스크에서는 대체로 파티션 하나가 볼륨 하나에 대응한다. 그러나 저장 공간, 동적 디스크, SAN과 가상 디스크를 사용하면 볼륨이 하나 이상의 물리 장치나 논리 장치 위에 구성될 수 있다.

새 디스크는 사용하기 전에 파티션 스타일을 선택하여 초기화한다. Windows는 주로 MBR과 GPT를 지원한다.

MBR은 전통적인 PC BIOS 환경에서 사용되던 파티션 형식이다. 디스크 첫 섹터에 부트 코드와 파티션 테이블을 저장하며, 일반적으로 약 2TiB 크기 제한과 네 개의 기본 파티션 제한을 가진다. 확장 파티션과 논리 드라이브를 사용하면 더 많은 구획을 만들 수 있다.

GPT는 UEFI와 함께 사용하는 현대적인 파티션 형식이다. 64비트 논리 블록 주소, 각 파티션의 GUID, 파티션 테이블 복사본과 CRC 검사를 사용한다. MBR보다 큰 디스크와 더 많은 파티션을 지원하며, 현대 Windows에서는 새 디스크의 기본 파티션 스타일로 사용된다.^[52]

UEFI 기반 Windows 시스템 디스크에는 일반적으로 다음과 같은 파티션이 존재한다.

• EFI 시스템 파티션
• Microsoft 예약 파티션
• Windows가 설치된 기본 데이터 파티션
• Windows 복구 환경 파티션
• 제조사에서 추가한 복구 또는 진단 파티션

EFI 시스템 파티션은 UEFI 펌웨어가 읽을 수 있는 FAT 계열 파일 시스템으로 포맷되며 Windows 부팅 관리자를 포함한다. Microsoft 예약 파티션은 GPT 디스크에서 Windows가 내부 디스크 관리 작업에 사용할 공간을 확보한다.

Windows는 볼륨에 C:, D:와 같은 드라이브 문자를 할당할 수 있다. 드라이브 문자는 볼륨의 고정된 물리적 위치가 아니라 DOS 장치 이름 공간에서 볼륨을 가리키는 연결이다.

NTFS 디렉터리 아래에 다른 볼륨을 탑재하는 볼륨 탑재 지점도 사용할 수 있다. 이를 이용하면 드라이브 문자를 소모하지 않고 C:\Data 같은 경로에 별도 볼륨을 연결할 수 있다.

Windows는 VHD와 VHDX 파일을 가상 디스크로 연결할 수 있다. 연결된 가상 디스크는 물리 디스크처럼 파티션을 만들고 파일 시스템으로 포맷할 수 있으며, Hyper-V 가상 머신, 부팅, 테스트와 백업 환경에 사용된다.

Disk Management와 PowerShell의 Storage 모듈은 디스크 초기화, 파티션 생성, 볼륨 포맷, 드라이브 문자 지정, 확장과 축소를 관리한다. 모든 작업이 모든 파일 시스템과 볼륨 형식에서 가능한 것은 아니며, 볼륨의 위치와 뒤따르는 할당되지 않은 공간에 따라 확장·축소 가능 여부가 달라진다.^[53]

저장 공간

저장 공간 또는 Storage Spaces는 여러 물리 저장 장치를 하나의 저장소 풀로 묶고, 그 위에 가상 디스크를 만드는 Windows의 소프트웨어 정의 저장 기술이다. 전용 하드웨어 RAID 컨트롤러 없이 운영체제가 디스크 집합, 데이터 배치와 복원력을 관리한다.

저장 공간의 기본 계층은 다음과 같다.

저장 공간 구성 흐름

1. 물리 디스크 여러 개 준비
   ↓
2. 저장소 풀 생성
   ↓
3. 풀의 용량으로 가상 디스크 생성
   ↓
4. 단순, 미러 또는 패리티 복원력 선택
   ↓
5. 가상 디스크에 파티션과 볼륨 생성
   ↓
6. NTFS 또는 ReFS로 포맷
   ↓
7. 드라이브 문자나 탑재 지점으로 사용

저장소 풀에는 SATA, SAS, USB와 일부 NVMe 장치를 포함할 수 있다. 서버 환경에서는 JBOD 인클로저나 인증된 저장 장치를 사용하며, 지원되는 구성은 Windows 버전과 배포 방식에 따라 달라진다.

저장 공간의 주요 복원력 유형은 다음과 같다.

단순 공간은 디스크 하나가 고장 나도 데이터를 잃을 수 있다. 미러와 패리티 공간은 요구되는 최소 디스크 수와 장애 허용 범위가 다르며, 성능 특성도 다르다.

저장 공간은 씬 프로비저닝과 고정 프로비저닝을 지원할 수 있다. 씬 프로비저닝은 현재 풀의 물리 용량보다 큰 논리적 가상 디스크를 만들고 실제 데이터가 기록될 때 공간을 할당한다. 관리자는 풀이 가득 차기 전에 물리 디스크를 추가해야 한다.

Microsoft는 Storage Spaces를 여러 물리 드라이브를 논리적 저장소 풀로 모으고, 그 위에 복원력 옵션을 가진 가상 디스크를 생성하는 저장 가상화 기술로 설명한다.^[54]

Storage Spaces Direct는 여러 서버의 로컬 저장 장치를 클러스터 전체의 소프트웨어 정의 저장소로 결합한다. 각 서버의 NVMe, SSD와 HDD가 고속 네트워크를 통해 하나의 저장 패브릭으로 구성되며, Hyper-V 가상 머신과 확장 가능한 파일 서버에 사용된다.

Storage Spaces Direct는 일반 Storage Spaces와 개념을 공유하지만 여러 서버에 걸친 장애 도메인, 자동 데이터 재배치, 캐시 계층과 클러스터 관리를 제공한다. 서버 또는 장치 장애가 발생하면 남은 노드와 디스크를 이용해 데이터의 복원력을 유지하고 복구 작업을 수행한다.^[55]

Storage Spaces는 파일 백업을 대체하지 않는다. 미러와 패리티는 디스크 고장에는 대응할 수 있지만, 사용자 실수, 악성 코드, 응용 프로그램 오류나 전체 시스템 손상으로부터 이전 데이터를 복구하려면 별도의 백업이나 복제 체계가 필요하다.

암호화 파일 시스템과 BitLocker

Windows는 저장 데이터를 보호하기 위해 암호화 파일 시스템과 BitLocker를 제공한다. 두 기술 모두 저장된 데이터를 암호화하지만 보호 단위와 키 관리 방식이 다르다.

EFS 또는 Encrypting File System은 NTFS 볼륨의 개별 파일과 디렉터리를 사용자 단위로 암호화한다. 사용자가 파일을 암호화하면 Windows는 임의의 파일 암호화 키로 파일 데이터를 암호화하고, 그 키를 사용자의 EFS 인증서에 포함된 공개 키로 보호한다.

권한이 있는 사용자가 로그인해 파일에 접근하면 해당 사용자의 개인 키를 이용해 파일 암호화 키를 해제하고 데이터를 투명하게 복호화한다. 응용 프로그램은 일반 파일처럼 읽고 쓸 수 있지만, 저장 장치에는 암호화된 데이터가 기록된다.

EFS의 특징은 다음과 같다.

• NTFS 파일과 디렉터리 단위 암호화
• 사용자 계정과 인증서 기반 접근
• 여러 사용자의 인증서를 한 파일에 등록 가능
• 데이터 복구 에이전트 구성 가능
• 파일 복사와 이동에 따른 암호화 상태 관리
• 일반 응용 프로그램에서 투명한 암호화와 복호화

Microsoft는 EFS를 공개 키 체계를 사용해 NTFS 볼륨의 개별 파일에 암호화 보호를 제공하는 기능으로 설명한다.^[56]

EFS 파일을 다른 파일 시스템으로 복사하면 대상 파일 시스템이 EFS를 지원하지 않기 때문에 일반적으로 복호화된 형태로 저장될 수 있다. 또한 EFS 개인 키와 인증서가 손실되면 파일을 복구하지 못할 수 있으므로 인증서와 복구 키를 별도로 백업해야 한다.

BitLocker는 개별 파일이 아니라 운영체제 볼륨이나 데이터 볼륨 전체를 암호화한다. 디스크가 분리되거나 다른 운영체제로 부팅되더라도 암호화 키가 없으면 볼륨의 파일 시스템과 데이터를 읽기 어렵게 만든다.

BitLocker는 다음과 같은 상황을 주요 대상으로 한다.

• 노트북이나 이동식 컴퓨터 분실
• 저장 장치 도난
• 폐기된 디스크에서 데이터 복구 시도
• 다른 운영체제로 부팅한 오프라인 접근
• 장치를 분해하여 디스크를 직접 읽는 공격

BitLocker는 AES 기반 볼륨 암호화를 사용하며, TPM과 결합해 정상적인 부팅 구성에서 자동으로 볼륨을 해제할 수 있다. TPM은 부팅 관리자, Secure Boot와 초기 시스템 구성의 측정값을 확인하고, 예상된 상태일 때만 키 사용을 허용한다.

BitLocker의 잠금 해제 방식에는 다음과 같은 구성이 사용될 수 있다.

• TPM만 사용
• TPM과 PIN
• TPM과 시작 키
• 암호
• 스마트 카드
• 복구 암호
• 복구 키
• 네트워크 잠금 해제
• Microsoft 계정, Active Directory 또는 Microsoft Entra ID에 저장된 복구 정보

BitLocker To Go는 USB 플래시 드라이브와 이동식 데이터 볼륨에 BitLocker 암호화를 적용한다. 이동식 드라이브는 암호, 스마트 카드 또는 복구 키로 잠금을 해제할 수 있다.

Microsoft는 BitLocker를 분실, 도난 또는 부적절하게 폐기된 장치에서 발생하는 데이터 노출을 줄이기 위해 전체 볼륨을 암호화하는 Windows 보안 기능으로 정의한다.^[57]

EFS와 BitLocker의 차이는 다음과 같이 정리할 수 있다.

BitLocker로 암호화된 볼륨이 잠금 해제되면 운영체제와 로그인한 사용자는 일반 디스크처럼 볼륨에 접근한다. 따라서 BitLocker 자체는 같은 Windows 세션 안에서 권한을 가진 사용자끼리 파일을 구분하지 않는다. 이 구분은 NTFS 접근 제어와 EFS가 담당한다.

EFS는 사용자별 파일 보호를 제공하지만 디스크 전체를 오프라인 공격으로부터 보호하지 않는다. 시스템 파일, 임시 파일, 페이지 파일과 암호화하지 않은 파일은 EFS의 보호 대상이 아닐 수 있다. 두 기술은 경쟁 관계가 아니라 서로 다른 계층을 보호하며 함께 사용할 수 있다. Microsoft의 BitLocker 문서도 BitLocker가 전체 운영체제 볼륨의 오프라인 공격을 방어하고, EFS가 같은 컴퓨터의 여러 사용자 사이에서 파일 단위 보호를 추가할 수 있다고 설명한다.^[58]

Windows의 저장 보호는 암호화만으로 완성되지 않는다. NTFS 권한, Secure Boot, TPM, 사용자 인증, 복구 키 보관, 백업과 장치 관리 정책이 함께 구성되어야 한다. 암호화는 저장 장치를 읽기 어렵게 하지만 파일 삭제, 랜섬웨어, 관리자 권한을 획득한 프로그램이나 이미 로그인된 사용자 세션에서 발생하는 변경까지 자동으로 방지하지는 않는다.

Windows는 프로세서, 저장 장치, 그래픽 처리 장치, 네트워크 어댑터와 USB 주변 장치 같은 하드웨어를 장치 객체와 드라이버 스택으로 관리한다. 응용 프로그램과 운영체제 구성 요소는 일반적으로 하드웨어의 레지스터나 버스를 직접 조작하지 않고, Windows API와 입출력 관리자를 통해 장치 드라이버에 작업을 요청한다.

장치 드라이버는 운영체제의 입출력 요청을 특정 장치나 장치 종류가 이해할 수 있는 동작으로 변환하는 소프트웨어다. 드라이버는 물리 장치뿐 아니라 파일 시스템, 네트워크 프로토콜, 가상 디스크, 암호화 계층과 소프트웨어 전용 가상 장치도 구현할 수 있다.

하나의 장치를 하나의 드라이버만 담당하는 것은 아니다. Windows는 장치마다 여러 드라이버와 장치 객체를 계층적으로 연결한 장치 스택을 구성한다.

Windows 장치 드라이버 스택의 기본 구조

• 응용 프로그램과 시스템 서비스
  • Windows API
    • 입출력 관리자
      • 상위 필터 드라이버
        • 기능 드라이버
          • 하위 필터 드라이버
            • 버스 드라이버
              • 물리 장치

버스 드라이버는 버스에 연결된 장치를 발견하고 열거한다. 기능 드라이버는 장치의 핵심 기능을 구현하며, 필터 드라이버는 기존 요청을 관찰하거나 변경하여 추가 기능을 제공한다. 실제 장치 스택의 구성은 장치 종류와 사용되는 드라이버 모델에 따라 달라진다.

드라이버는 운영체제의 신뢰 경계 안에서 실행되므로 안정성과 보안에 직접적인 영향을 준다. 특히 커널 모드 드라이버의 잘못된 메모리 접근이나 동기화 오류는 해당 프로그램뿐 아니라 운영체제 전체를 중지시킬 수 있다. Windows는 이를 줄이기 위해 사용자 모드 드라이버, 드라이버 프레임워크, 코드 서명, 자동 복구와 검증 도구를 제공한다.

Windows 드라이버 모델

Windows에는 시대와 장치 종류에 따라 여러 드라이버 모델이 존재한다. Windows Driver Model 또는 WDM은 Windows 98과 Windows 2000 시기에 도입된 범용 커널 모드 드라이버 모델로, 공통된 입출력 요청 패킷과 플러그 앤 플레이, 전원 관리 규칙을 사용한다.

WDM 드라이버는 운영체제의 입출력 관리자와 직접 상호 작용한다. 드라이버는 장치 객체를 생성하고, 입출력 요청 패킷을 처리하며, 플러그 앤 플레이와 전원 상태 변경, 취소, 동기화와 장치 제거를 직접 관리해야 한다.

Microsoft는 WDM을 여러 Windows 운영체제에서 소스 수준 호환이 가능한 장치 드라이버를 작성하기 위해 도입된 모델로 설명한다. 다만 현재는 새 드라이버에 WDM을 직접 사용하는 방식보다 장치 종류별 미니포트 모델이나 Windows Driver Frameworks를 우선적으로 선택하도록 안내한다.^[59]

현대적인 범용 드라이버 개발에는 Windows Driver Frameworks 또는 WDF가 사용된다. WDF는 WDM 위에 공통적인 드라이버 수명 주기와 입출력 처리 구조를 제공하며, 다음 두 프레임워크로 구성된다.

• KMDF는 커널 모드 드라이버를 위한 프레임워크다.
• UMDF는 사용자 모드 드라이버를 위한 프레임워크다.

WDF는 입출력 요청 큐, 장치 생성, 플러그 앤 플레이, 전원 관리, 취소, 동기화와 객체 수명 관리에 필요한 반복 코드를 프레임워크 내부에서 처리한다. 드라이버 개발자는 장치별 동작과 필요한 이벤트 콜백을 구현한다.

Microsoft는 WDF를 Windows 드라이버 작성에 필요한 공통 코드를 제공하는 추상화 계층으로 정의하며, KMDF와 UMDF를 WDF의 두 드라이버 프레임워크로 제공한다.^[60]

WDM과 WDF의 기본적인 차이는 운영체제와 상호 작용하는 책임의 위치에 있다. WDM 드라이버는 많은 시스템 구조와 요청을 직접 관리하지만, WDF 드라이버는 프레임워크 객체와 이벤트 콜백을 이용한다. Microsoft는 WDM이 운영체제 서비스와 구조에 직접 연결되는 반면 WDF는 공통 운영체제 상호 작용의 상당 부분을 프레임워크가 처리한다고 설명한다.^[61]

Windows는 범용 WDM·WDF 외에도 장치 종류에 특화된 모델을 제공한다.

• WDDM은 디스플레이와 그래픽 처리 장치를 위한 드라이버 모델이다.
• NDIS는 네트워크 인터페이스와 네트워크 필터 드라이버를 위한 모델이다.
• AVStream은 오디오와 영상 스트리밍 장치를 위한 커널 스트리밍 모델이다.
• PortCls는 오디오 어댑터용 포트·미니포트 구조를 제공한다.
• Storport는 고성능 저장 장치 어댑터용 포트 드라이버 모델이다.
• USB 드라이버 스택은 USB 호스트 컨트롤러, 허브와 장치 클래스 드라이버를 관리한다.
• HID 클래스 드라이버는 키보드, 마우스, 게임 컨트롤러와 여러 입력 장치를 지원한다.
• 프린터 드라이버 모델은 인쇄 스풀러와 그래픽 출력 체계에 연결된다.
• MCDM은 화면 출력 없이 계산 기능만 제공하는 장치를 위한 계산 드라이버 모델이다.

버스 드라이버, 기능 드라이버와 필터 드라이버는 드라이버가 장치 스택에서 담당하는 역할을 기준으로 한 분류다.

버스 드라이버는 PCI, USB, ACPI와 같은 버스를 제어하고 하위 장치를 발견한다. 발견한 각 장치에 물리 장치 객체를 만들고 장치 식별자, 자원과 기능 정보를 플러그 앤 플레이 관리자에 제공한다.

기능 드라이버는 장치의 주된 동작을 구현한다. 저장 장치 읽기·쓰기, 네트워크 프레임 전송, 센서 값 획득처럼 장치가 제공하는 핵심 기능을 담당한다.

필터 드라이버는 기능 드라이버의 위나 아래에 연결되어 요청을 관찰하거나 변경한다. 암호화, 입력 변환, 장치 감시, 보안 검사와 호환성 보완 기능을 추가할 수 있다. Microsoft는 Windows 장치 드라이버를 버스, 기능과 필터 드라이버로 구분하며, 이들이 하나의 장치 스택을 구성한다고 설명한다.^[62]

커널 모드와 사용자 모드 드라이버

Windows 드라이버는 실행 권한에 따라 커널 모드 드라이버와 사용자 모드 드라이버로 나뉜다.

커널 모드 드라이버는 Windows 커널과 같은 커널 주소 공간에서 실행된다. 시스템 메모리, 장치 레지스터, 인터럽트, 직접 메모리 접근과 커널 내부 인터페이스를 사용할 수 있으며, 높은 성능과 낮은 지연이 필요한 장치에 적합하다.

커널 모드 드라이버는 다음 영역에서 주로 사용된다.

• 버스와 장치 열거
• 저장 장치와 파일 시스템
• 네트워크 데이터 경로
• 그래픽 커널과 디스플레이 미니포트
• 인터럽트 처리
• 직접 메모리 접근
• 커널 보안과 필터링
• 가상화와 저수준 시스템 장치

커널 모드 드라이버가 잘못된 포인터를 사용하거나 해제된 메모리에 접근하면 운영체제 전체의 주소 공간이 손상될 수 있다. 처리되지 않은 커널 예외, 잘못된 인터럽트 수준, 교착 상태와 입출력 요청의 이중 완료는 버그 검사와 시스템 중지로 이어질 수 있다.

사용자 모드 드라이버는 제한된 사용자 모드 프로세스에서 실행된다. 사용자 모드 주소 공간의 보호를 받으므로 드라이버가 충돌하더라도 일반적으로 운영체제 전체가 아니라 해당 드라이버 호스트 프로세스에 영향이 제한된다.

UMDF 드라이버는 프레임워크가 제공하는 사용자 모드 호스트에서 실행되며, 운영체제와 장치 요청은 프레임워크와 커널 구성 요소를 통해 전달된다. 장치와 시스템에 직접 접근할 수 있는 범위는 커널 모드보다 제한된다.

사용자 모드 드라이버는 다음과 같은 장치에 사용할 수 있다.

• 일부 USB 장치
• 센서와 위치 장치
• 휴대용 장치
• 카메라와 미디어 장치의 일부 기능
• 소프트웨어 장치
• 저속 또는 메시지 기반 주변 장치
• 커널 모드 접근이 필요하지 않은 장치 클래스

커널 모드와 사용자 모드 가운데 어느 하나가 모든 장치에 적합한 것은 아니다. 인터럽트 지연, DMA, 커널 데이터 경로와 높은 처리량이 필요한 장치는 커널 모드가 필요할 수 있다. 반면 장치의 기능을 사용자 모드에서 충분히 구현할 수 있다면 UMDF를 사용하여 오류 격리와 보안을 강화할 수 있다.

KMDF와 UMDF는 유사한 객체 기반 개념을 사용한다. 두 프레임워크 모두 장치, 드라이버, 파일 객체, 입출력 큐, 요청, 인터럽트와 타이머 같은 프레임워크 객체를 제공하지만, 지원되는 기능과 실행 환경은 다르다.

WDF 드라이버 실행 위치

• 응용 프로그램
  • 일반 Windows API
  • 장치 인터페이스 호출
    • UMDF 드라이버
      • 사용자 모드 드라이버 호스트
        • UMDF 및 커널 중개 구성 요소
    • KMDF 드라이버
      • 커널 모드 장치 스택
        • 버스와 물리 장치

일부 장치는 사용자 모드와 커널 모드 구성 요소를 함께 사용한다. 그래픽 드라이버는 사용자 모드 디스플레이 드라이버와 커널 모드 디스플레이 미니포트 드라이버를 조합하며, 사용자 모드 구성 요소는 그래픽 API 명령을 처리하고 커널 모드 구성 요소는 GPU 메모리, 스케줄링과 하드웨어 제어에 참여한다.

Windows는 드라이버가 사용자 모드에 있더라도 모든 오류를 자동으로 방지하지는 않는다. 사용자 모드 드라이버도 장치를 잘못 구성하거나 민감한 데이터를 노출할 수 있으며, 드라이버 호스트의 반복적인 충돌은 장치 사용을 중단시킬 수 있다. 사용자 모드는 주로 운영체제 커널에 대한 직접적인 손상 범위를 제한한다.

플러그 앤 플레이

플러그 앤 플레이 또는 PnP는 장치가 추가, 제거되거나 구성이 변경될 때 Windows가 장치를 자동으로 발견하고 적절한 드라이버와 자원을 연결하는 체계다. 사용자는 대부분의 장치를 연결한 뒤 수동으로 주소, 인터럽트와 포트를 설정하지 않고 사용할 수 있다.

Microsoft는 Plug and Play를 사용자의 개입을 거의 요구하지 않으면서 시스템이 하드웨어 변경에 적응하도록 하는 Windows 기능으로 정의한다.^[63]

PnP 관리자는 다음 작업을 담당한다.

• 부팅 과정의 장치 감지와 열거
• 실행 중 연결된 장치 추가
• 제거된 장치 처리
• 장치 식별자와 드라이버 패키지 일치
• 장치 노드와 장치 스택 생성
• 하드웨어 자원 할당
• 장치 시작, 중지와 제거
• 사용자 모드 장치 설치 구성 요소와의 통신
• 장치 인터페이스 등록과 알림

Microsoft의 PnP 관리자 문서는 장치 부팅 열거, 실행 중 추가·제거 처리와 일치하는 드라이버 패키지 설치를 주요 역할로 설명한다.^[64]

PnP 장치는 버스 드라이버가 발견한다. PCI 버스 드라이버는 PCI 구성 공간을 조사하고, USB 허브 드라이버는 포트 연결 상태와 USB 설명자를 읽으며, ACPI 드라이버는 펌웨어가 기술한 장치를 열거한다.

발견된 각 장치는 장치 노드로 장치 트리에 등록된다. 장치 노드는 부모 버스, 자식 장치, 현재 상태, 드라이버, 자원과 문제 정보를 나타낸다.

장치에는 하나 이상의 하드웨어 ID와 호환 ID가 있다. Windows는 드라이버 저장소의 INF 파일을 검사하고 ID, 등급, 서명과 날짜 같은 조건을 바탕으로 가장 적합한 드라이버 패키지를 선택한다.

새 장치가 연결될 때의 기본 흐름

1. 버스가 새 장치 감지
   ↓
2. 버스 드라이버가 장치 식별자와 기능 보고
   ↓
3. PnP 관리자가 장치 노드 생성
   ↓
4. 일치하는 드라이버 패키지 검색
   ↓
5. 필요한 드라이버 패키지를 드라이버 저장소에 준비
   ↓
6. 기능 및 필터 드라이버 적재
   ↓
7. 장치 스택 생성
   ↓
8. 자원 할당과 장치 시작
   ↓
9. 장치 인터페이스를 응용 프로그램에 공개

장치 스택에 참여하는 드라이버는 장치 시작, 중지, 제거와 자원 재조정에 대응해야 한다. WDM 드라이버에서는 PnP IRP를 직접 처리하고, WDF 드라이버에서는 프레임워크가 요청을 해석한 뒤 해당 이벤트 콜백을 호출한다.

장치를 물리적으로 분리할 수 있다고 해서 항상 즉시 제거해도 되는 것은 아니다. 저장 장치에는 아직 기록되지 않은 캐시 데이터가 있을 수 있고, 응용 프로그램이나 드라이버가 장치 핸들을 사용 중일 수 있다. Windows는 제거 요청과 제거 확정 단계를 구분하여 드라이버가 사용 중인 작업을 정리할 기회를 제공한다.

갑작스러운 제거는 사전 통지 없이 장치가 사라지는 상황이다. USB 장치 분리, 무선 연결 상실과 외부 장치 전원 차단이 이에 해당할 수 있다. 드라이버는 하드웨어에 더 이상 접근하지 않고 보류 중인 요청을 적절한 오류로 완료해야 한다.

PnP는 하드웨어뿐 아니라 소프트웨어 장치에도 사용된다. 가상 네트워크 어댑터, 가상 오디오 장치, 파일 시스템 기반 장치와 가상 버스에서 생성한 자식 장치도 장치 노드와 드라이버 패키지를 이용할 수 있다.

기업 관리자는 그룹 정책을 통해 특정 장치 설치를 허용하거나 차단할 수 있다. 정책은 장치 인스턴스 ID, 장치 설정 클래스와 이동식 장치 여부 등을 기준으로 적용할 수 있다. Microsoft는 장치 인스턴스 ID 목록을 사용하여 특정 PnP 장치 설치를 금지하는 정책을 제공한다.^[65]

전원 관리

Windows의 장치 전원 관리는 사용하지 않는 하드웨어의 소비 전력을 줄이면서 필요할 때 장치를 다시 사용할 수 있도록 시스템과 장치의 전원 상태를 조정한다.

전원 관리는 플러그 앤 플레이와 밀접하게 연결된다. 장치를 중지하거나 다시 시작하고, 시스템 절전 과정에서 장치의 상태를 저장·복원하며, 장치가 시스템을 깨울 수 있는지를 결정하려면 장치 스택과 수명 주기 정보를 알아야 한다. Microsoft는 전원 관리를 지원하는 드라이버가 PnP도 지원해야 하며, PnP 쿼리를 통해 장치의 전원 기능을 보고한다고 설명한다.^[66]

Windows는 시스템 전원 상태와 장치 전원 상태를 구분한다.

시스템 전원 상태는 시스템 전체의 작동 정도를 나타내며 실행, 절전과 최대 절전 같은 상태를 포함한다. 장치 전원 상태는 개별 장치가 소비하는 전력과 현재 작동 가능 여부를 나타낸다.

전통적인 장치 전원 상태는 다음과 같이 구분된다.

모든 장치가 D1과 D2를 지원하는 것은 아니다. 각 버스와 장치는 지원하는 전원 상태, 상태 전환 시간, 문맥 보존 여부와 시스템 깨우기 기능을 보고한다.

Windows는 시스템 상태와 장치 기능을 바탕으로 각 장치를 적절한 전원 상태에 배치한다. 시스템이 절전 상태로 진입할 때에는 드라이버가 새 입출력을 중단하고, 보류 중인 요청을 완료하거나 취소하며, 필요한 장치 문맥을 저장한 뒤 하드웨어 전원을 낮춘다.

시스템이 다시 활성화되면 버스와 장치가 전원을 회복하고, 드라이버가 하드웨어 상태를 복원하며, 중단했던 입출력을 다시 시작한다.

장치는 특정 사건이 발생했을 때 시스템을 깨울 수 있다.

• 키보드나 마우스 입력
• 네트워크의 Wake-on-LAN 패킷
• USB 장치 활동
• 모뎀이나 통신 장치 신호
• 타이머와 알람
• 덮개 또는 전원 버튼 상태 변경

깨우기 기능을 사용하려면 장치, 버스, 펌웨어와 드라이버가 모두 필요한 전원 및 신호 전달 기능을 지원해야 한다.

현대 Windows는 프레임워크 기반의 전원 관리도 제공한다. WDF는 장치가 사용 중인지 추적하고 일정 시간 유휴 상태가 되면 저전력 상태로 전환하는 기능을 제공한다. 드라이버는 유휴 시간 제한, 장치가 깨어날 조건과 전원 전환 콜백을 구성할 수 있다.

SoC와 모바일형 장치에서는 개별 구성 요소가 짧은 유휴 구간에도 독립적으로 저전력 상태에 들어가는 세밀한 전원 관리가 중요하다. Windows의 전원 관리 프레임워크는 장치와 플랫폼의 전원 구성 요소를 조정하여 시스템 전체가 실행 상태에 있더라도 사용하지 않는 장치의 전력을 줄일 수 있게 한다.

드라이버가 전원 요청을 잘못 처리하면 절전 진입 실패, 복귀 후 장치 미작동, 배터리 소모, 장치 제거 오류와 시스템 중지가 발생할 수 있다. 따라서 드라이버는 전원 전환 중 새 입출력과 기존 요청의 순서를 일관되게 관리해야 한다.

그래픽 드라이버

Windows의 현대 그래픽 드라이버는 Windows Display Driver Model 또는 WDDM을 사용한다. WDDM은 Windows Vista에서 처음 도입되었으며, 이전의 Windows 2000 Display Driver Model인 XDDM을 대체했다.

Microsoft는 WDDM을 Windows의 디스플레이 및 그래픽 드라이버 아키텍처로 정의한다. WDDM은 Desktop Window Manager를 이용한 합성 데스크톱, 그래픽 메모리 가상화, GPU 작업 스케줄링과 오류 복구를 지원하며 Windows 릴리스와 함께 계속 발전해 왔다.^[67]

WDDM 드라이버는 하나의 커널 모드 드라이버만으로 구성되지 않는다. 그래픽 하드웨어 공급사는 일반적으로 사용자 모드 디스플레이 드라이버와 커널 모드 디스플레이 미니포트 드라이버를 함께 제공한다.^[68]

WDDM의 주요 구성

• 그래픽 응용 프로그램
  • Direct3D
  • Direct2D
  • OpenGL 또는 Vulkan 런타임
  • 미디어와 계산 API
    • 사용자 모드 그래픽 런타임
      • 사용자 모드 디스플레이 드라이버
        • DirectX 그래픽 커널
          • GPU 스케줄러
          • 비디오 메모리 관리자
          • 커널 모드 디스플레이 미니포트 드라이버
            • GPU와 디스플레이 하드웨어

사용자 모드 디스플레이 드라이버는 Direct3D 같은 그래픽 API에서 전달된 명령을 장치별 명령과 자원 형식으로 변환한다. 사용자 모드에서 실행되므로 셰이더 컴파일이나 명령 생성 과정의 오류가 발생했을 때 커널 전체에 미치는 영향을 줄일 수 있다.

커널 모드 디스플레이 미니포트 드라이버는 GPU 초기화, 메모리 매핑, 인터럽트, 명령 제출, 화면 출력 경로와 전원 관리를 담당한다. Windows의 DirectX 그래픽 커널과 협력하여 여러 프로세스의 GPU 작업을 관리한다.

Microsoft의 WDDM 아키텍처 문서는 WDDM이 사용자 모드와 커널 모드 구성 요소를 함께 사용하는 구조임을 명시한다.^[69]

WDDM은 각 프로세스가 그래픽 메모리를 직접 독점하는 대신, 비디오 메모리 관리자가 GPU 메모리와 시스템 메모리 사이의 자원 배치를 관리하도록 한다. 그래픽 메모리가 부족하면 사용 빈도가 낮은 자원을 시스템 메모리로 이동하고, 다시 필요할 때 GPU 메모리로 가져올 수 있다.

GPU 스케줄러는 여러 응용 프로그램과 시스템 구성 요소의 명령 버퍼를 GPU에 배치한다. 이를 통해 데스크톱 합성, 게임, 영상 처리와 계산 작업이 하나의 GPU를 공유할 수 있다.

WDDM은 GPU 작업이 일정 시간 동안 완료되지 않을 때 시스템 전체를 즉시 중지하는 대신 GPU와 드라이버를 재설정하는 시간 제한 감지 및 복구를 지원한다. 복구가 성공하면 화면이 잠시 깜박인 뒤 데스크톱 실행이 계속될 수 있으며, 영향을 받은 그래픽 응용 프로그램은 장치 손실을 처리해야 할 수 있다.

Desktop Window Manager는 각 창의 화면을 별도 표면으로 합성한다. 응용 프로그램이 화면 프레임버퍼를 직접 소유하는 대신 DWM과 WDDM이 최종 화면 구성을 관리하므로 투명 효과, 애니메이션, 고해상도 배율, 여러 모니터와 창 미리 보기를 일관되게 구현할 수 있다.

WDDM의 버전이 올라가면서 다음과 같은 기능이 확장되었다.

• 세밀한 GPU 선점
• GPU 가상 주소 공간
• 하드웨어 가속 GPU 스케줄링
• 다중 GPU와 연결된 디스플레이 어댑터
• 가상 머신의 GPU 공유와 분할
• DirectX 12
• 광선 추적
• 영상 인코딩과 디코딩
• 기계 학습과 범용 GPU 계산
• GPU 장애 격리와 진단
• 가변 주사율과 고급 디스플레이 출력

화면 출력을 제공하지 않고 계산만 수행하는 장치에는 Microsoft Compute Driver Model을 사용할 수 있다. Microsoft는 MCDM을 계산 전용 기능을 가진 장치용 드라이버 모델로 제공한다.^[70]

과거의 XDDM 드라이버는 Windows 2000부터 사용된 레거시 그래픽 모델이다. Windows Vista와 Windows 7에서는 제한적으로 사용할 수 있었으나, 현대 Windows 그래픽 기능과 합성 데스크톱은 WDDM을 전제로 한다. Microsoft의 그래픽 드라이버 문서는 XDDM을 Windows 2000부터 Windows Vista 및 Windows 7 시기까지 사용된 레거시 모델로 구분한다.^[71]

드라이버 서명과 배포

Windows 드라이버는 드라이버 바이너리 하나만으로 배포되지 않는다. 일반적인 드라이버 패키지는 장치와 설치 방법을 기술하는 INF 파일, 하나 이상의 드라이버 바이너리, 카탈로그 파일과 추가 구성 요소로 이루어진다.

INF 파일은 실행 가능한 설치 스크립트가 아니라 선언형 설치 정보다. 장치의 하드웨어 ID와 호환 ID, 드라이버 서비스, 파일 복사 위치, 장치 설정 클래스와 대상 Windows 버전을 기술한다.

드라이버 패키지는 설치 전에 드라이버 저장소에 준비된다. Windows는 패키지의 구조와 서명을 검증한 뒤 드라이버 저장소에 추가하고, 장치에 가장 적합한 패키지를 선택하여 설치한다. 저장소에 준비된 패키지는 장치가 나중에 다시 연결될 때에도 사용할 수 있다.

디지털 서명은 드라이버 패키지의 게시자를 식별하고, 서명 이후 패키지가 변경되지 않았는지 확인한다. 서명은 드라이버가 기능적으로 완전하거나 오류가 없다는 보증 자체는 아니지만, 출처와 무결성을 검증하는 기반이 된다.

64비트 현대 Windows는 일반적인 커널 모드 드라이버에 신뢰할 수 있는 서명을 요구한다. Secure Boot가 활성화된 시스템과 최신 Windows에서는 Microsoft의 하드웨어 개발자 프로그램을 통한 서명과 정책 검증이 중요한 배포 절차가 된다.

드라이버 개발과 배포에는 다음과 같은 서명 단계가 사용된다.

• 개발 중 테스트 서명
• 사내 또는 제한된 환경의 배포 서명
• Microsoft 증명 서명
• HLK 시험을 통과한 WHQL 릴리스 서명
• Windows Update 배포를 위한 하드웨어 제출

테스트 서명은 개발 중인 드라이버를 시험 시스템에서 적재하기 위해 사용한다. 시험 시스템에는 테스트 인증서를 신뢰하도록 설정하고 테스트 서명 모드를 활성화할 수 있다. 이는 일반 사용자의 공개 배포 방식이 아니다.

증명 서명은 개발사가 Partner Center에 드라이버 패키지를 제출하고 Microsoft 서명을 받는 방식이다. 제출자는 요구되는 인증서로 CAB 패키지에 서명하고 하드웨어 대시보드를 통해 업로드한다. Microsoft의 2026년 문서는 증명 서명을 위해 EV로 서명한 CAB 파일을 Partner Center에 제출하는 절차를 설명한다.^[72]

WHQL 릴리스 서명은 드라이버와 장치가 Windows Hardware Lab Kit 시험을 통과한 뒤 Microsoft의 서명을 받는 방식이다. Microsoft는 HLK 시험을 통과한 WHQL 서명 드라이버 패키지를 Windows Update를 통해 배포할 수 있다고 설명한다.^[73]

Microsoft는 하드웨어 개발자 센터에서 여러 드라이버 서명 방식을 제공하며, 제품과 배포 목적에 맞는 서명 방식을 선택하도록 안내한다.^[74]

일반적인 공개 드라이버 배포 흐름은 다음과 같다.

Windows 드라이버 공개 배포 흐름

1. 드라이버와 INF 패키지 개발
   ↓
2. 정적 분석과 Driver Verifier 시험
   ↓
3. 지원할 Windows 버전과 장치에서 기능 시험
   ↓
4. 카탈로그 생성과 패키지 서명
   ↓
5. 필요한 HLK 시험 수행
   ↓
6. Partner Center에 하드웨어 제출
   ↓
7. Microsoft 서명된 패키지 획득
   ↓
8. 제조사 설치 프로그램 또는 Windows Update로 배포
   ↓
9. 장치 설치 결과와 오류 원격 분석 확인
   ↓
10. 새 패키지를 통한 갱신 또는 롤백

Windows Hardware Lab Kit는 장치와 드라이버가 Windows의 기능, 안정성, 전원, 보안과 호환성 요구 사항을 충족하는지 시험하는 도구 모음이다. 시험 결과는 제출 패키지에 포함되며, 제품 종류에 따라 필요한 시험 항목이 달라진다.

Driver Verifier는 커널 모드 드라이버의 잘못된 동작을 적극적으로 감지하는 진단 기능이다. 메모리 사용, 입출력 요청 처리, 동기화, DMA와 보안 관련 규칙을 엄격하게 검사하며, 오류가 발견되면 문제 지점에 가까운 시점에서 시스템을 중지시켜 디버깅을 돕는다. 일반 사용 환경에서 모든 드라이버에 항상 활성화하는 기능은 아니며 개발과 문제 분석에 사용한다.

드라이버는 여러 경로로 설치될 수 있다.

• Windows 설치 이미지에 기본 포함
• Windows Update와 선택적 업데이트
• 컴퓨터 또는 장치 제조사의 업데이트 프로그램
• Microsoft Store와 연결된 구성 요소
• 관리자가 드라이버 저장소에 직접 추가
• 장치 설치 프로그램
• 기업용 배포 및 관리 도구
• Windows 배포 이미지에 오프라인 통합

Windows Update로 배포되는 드라이버는 장치의 하드웨어 ID, 운영체제 버전, 아키텍처, 기존 드라이버와 배포 대상 조건에 따라 제공된다. 제조사는 단계적 배포와 대상 지정 정책을 사용하여 특정 장치 모델이나 시스템 구성에 먼저 배포할 수 있다.

Windows는 여러 후보 가운데 드라이버 순위를 계산해 설치할 패키지를 선택한다. 하드웨어 ID의 일치 정도, 서명, 드라이버 날짜, 버전과 장치별 메타데이터가 선택에 사용된다. 단순히 버전 번호가 가장 큰 패키지가 항상 선택되는 것은 아니다.

드라이버 업데이트가 장치 작동을 방해하는 경우 Windows는 이전 드라이버로 되돌릴 수 있다. 시스템 복원, 장치 관리자, 복구 환경과 업데이트 제거 기능도 복구에 사용될 수 있다. 다만 부팅에 필수적인 저장 장치나 보안 드라이버의 문제는 운영체제 부팅 자체에 영향을 줄 수 있다.

드라이버 패키지는 가능한 한 장치 기능에 필요한 최소 권한과 구성 요소만 포함하는 것이 적절하다. 드라이버와 함께 설치되는 높은 권한의 서비스, 업데이트 프로그램과 사용자 모드 관리 도구도 전체 공격 표면에 포함된다.

Windows의 드라이버 보안은 코드 서명만으로 구성되지 않는다. Secure Boot, 커널 코드 무결성, 가상화 기반 보안, 취약 드라이버 차단 목록, 메모리 무결성, 사용자 모드 격리와 장치 설치 정책이 함께 드라이버의 적재와 동작을 제한한다. 서명된 드라이버에서도 보안 취약점이 발견될 수 있으므로 제조사는 취약한 버전을 갱신하고 이전 버전의 사용을 차단할 수 있는 배포 체계를 유지해야 한다.

Windows의 사용자 인터페이스는 데스크톱 셸, 창 관리 체계, 파일 탐색기, 설정 도구와 명령줄 환경으로 구성된다. 일반 사용자는 시작 메뉴, 작업 표시줄과 파일 탐색기를 통해 프로그램과 문서에 접근하고, 설정 앱과 제어판을 통해 운영체제와 장치를 구성한다. 관리 작업과 자동화에는 명령 프롬프트와 PowerShell이 사용되며, Windows Terminal은 여러 명령줄 셸을 하나의 현대적인 터미널 환경에서 실행한다.

Windows의 그래픽 사용자 인터페이스는 운영체제 전체와 동일한 단일 프로그램이 아니다. 바탕 화면과 파일 탐색을 담당하는 셸, 응용 프로그램의 창을 관리하는 창 관리자, 창의 화면을 합성하는 Desktop Window Manager, 시작 메뉴와 작업 표시줄을 구현하는 구성 요소가 협력하여 사용자 환경을 만든다.

데스크톱과 셸

Windows 셸은 파일, 디렉터리, 응용 프로그램과 시스템 기능을 사용자가 탐색하고 실행할 수 있도록 제공하는 그래픽 사용자 환경이다. 현대 Windows에서 셸은 바탕 화면, 작업 표시줄, 시작 메뉴, 파일 탐색기, 알림 영역과 파일 연결 체계를 포함한다.

Microsoft는 Windows Shell을 데스크톱, 작업 표시줄, 시작 메뉴와 Windows 탐색기를 포함하는 사용자 인터페이스 환경으로 다루며, 응용 프로그램과 파일 형식이 이러한 구성 요소에서 적절하게 표시되고 작동하도록 셸 인터페이스를 제공한다.^[75]

바탕 화면은 단순한 배경 화면이 아니라 Windows 셸 이름 공간의 루트에 해당하는 사용자 인터페이스다. 사용자는 바탕 화면에 파일, 디렉터리, 바로 가기와 일부 시스템 개체를 표시할 수 있다. 휴지통, 내 PC와 네트워크 같은 항목은 실제 파일 시스템 디렉터리와 완전히 같은 형태로 저장되지 않더라도 셸 이름 공간 안에서 파일과 유사한 개체로 표현된다.

Windows 셸 이름 공간에는 다음과 같은 항목이 함께 포함될 수 있다.

• 로컬 파일과 디렉터리
• 드라이브와 탑재된 볼륨
• 네트워크 위치
• 휴지통
• 검색 결과
• 압축 디렉터리
• 제어판 항목
• 클라우드 저장소
• 휴대용 장치
• 셸 확장이 제공하는 가상 항목

셸 이름 공간은 실제 파일 시스템의 디렉터리 트리보다 넓은 개념이다. Windows 탐색기는 셸 이름 공간을 그래픽으로 표시하고 사용자가 그 안의 개체를 탐색하고 조작할 수 있도록 한다.^[76]

초기의 Windows 셸은 버전에 따라 서로 다른 프로그램과 인터페이스를 사용했다. Windows 1.x와 2.x에서는 MS-DOS Executive가 파일과 프로그램 실행을 담당했고, Windows 3.x에서는 Program Manager와 File Manager가 사용되었다. Windows 95에서는 바탕 화면, 시작 메뉴, 작업 표시줄과 Windows Explorer가 결합된 새로운 셸이 도입되었다.

Windows 95 이후 explorer.exe는 오랫동안 파일 탐색기와 데스크톱 셸의 중심 프로세스로 사용되었다. 다만 현대 Windows에서는 시작 메뉴, 검색, 작업 표시줄과 셸 경험 일부가 별도 프로세스와 패키지로 분리되어, 모든 셸 기능이 하나의 Explorer 프로세스 안에서만 실행되는 것은 아니다.

셸은 파일 확장자와 등록된 파일 형식을 기반으로 파일을 열 응용 프로그램을 선택한다. 파일을 두 번 누르거나 문맥 메뉴의 동작을 선택하면 셸은 등록된 동사와 파일 연결 정보를 확인하여 대상 응용 프로그램을 실행한다. 셸의 문맥 메뉴는 파일과 폴더에 등록된 열기, 편집, 인쇄, 공유와 사용자 정의 명령을 제공한다.^[77]

응용 프로그램은 셸 확장을 통해 Windows 사용자 환경에 기능을 추가할 수 있다.

• 파일 형식별 아이콘과 미리 보기
• 파일 속성 처리기
• 축소판 그림
• 문맥 메뉴 명령
• 탐색 창 항목
• 검색 필터
• 클라우드 파일 상태
• 사용자 정의 셸 이름 공간

셸 확장 가운데 일부는 Explorer 프로세스 안에서 실행되므로 오류나 지연이 파일 탐색기와 바탕 화면의 안정성에 영향을 줄 수 있다. 현대 Windows는 일부 기능을 별도 프로세스나 응용 프로그램으로 분리하여 이러한 영향을 줄이는 방향으로 발전하고 있다.

Windows는 일반적인 Explorer 셸 대신 지정한 응용 프로그램을 실행하는 사용자 정의 셸 구성도 지원한다. 키오스크, 산업용 장치와 전용 단말기에서는 Shell Launcher나 할당된 액세스를 사용해 일반 데스크톱을 숨기고 특정 응용 프로그램만 제공할 수 있다.

창 관리자

Windows의 창 관리자는 응용 프로그램의 최상위 창과 자식 창, 위치, 크기, 포커스, 입력과 겹침 순서를 관리한다. Win32 응용 프로그램은 창을 생성하고 메시지를 수신하며, 창 관리 체계는 사용자 입력과 시스템 상태 변화를 해당 창에 전달한다.

전통적인 Win32 창은 운영체제에 등록된 창 클래스와 창 프로시저를 가진다. 창 프로시저는 이동, 크기 변경, 키보드와 마우스 입력, 그리기, 활성화와 종료 같은 메시지를 처리한다.

Windows의 창 관리에는 다음 요소가 포함된다.

• 창 생성과 제거
• 부모·자식 창 관계
• 활성 창과 입력 포커스
• 전경·배경 창
• 창의 위치와 크기
• 최소화, 최대화와 복원
• 창 겹침 순서
• 여러 모니터 배치
• 가상 데스크톱
• 창 스냅과 레이아웃

현대 Windows에서는 창의 최종 화면 출력을 Desktop Window Manager 또는 DWM이 합성한다. 응용 프로그램은 자신의 창 내용을 화면에 직접 최종 출력하기보다, 각 창에 대응하는 표면에 렌더링한다. DWM은 이러한 표면을 모아 바탕 화면의 최종 프레임을 만든다.

Microsoft는 DWM이 데스크톱 합성을 수행하며, 창 프레임 효과, 전환 애니메이션, 창 축소판과 고해상도 화면 지원 같은 기능을 제공한다고 설명한다.^[78]

Windows 창 합성의 기본 흐름

1. 응용 프로그램이 창 내용 렌더링
   ↓
2. 창별 화면 표면에 결과 저장
   ↓
3. DWM이 각 창의 위치, 크기와 겹침 순서 확인
   ↓
4. 그림자, 투명도, 애니메이션과 배율 적용
   ↓
5. 여러 창과 바탕 화면을 하나의 화면으로 합성
   ↓
6. WDDM 그래픽 드라이버를 통해 모니터에 출력

DWM 기반 합성은 한 창이 다른 창에 가려지거나 이동하더라도 응용 프로그램이 모든 영역을 매번 다시 그리지 않고 기존 표면을 사용할 수 있게 한다. 운영체제는 창 축소판, 작업 전환 화면, 애니메이션과 고해상도 배율을 일관되게 적용할 수 있다.

Windows Vista에서 DWM이 처음 도입되었을 때 일부 시각 효과를 끄거나 합성을 비활성화할 수 있었지만, Windows 8 이후의 현대 Windows에서는 DWM 합성이 데스크톱 표시 체계의 기본 구성 요소가 되었다.

창의 콘텐츠 렌더링과 창 장식은 반드시 같은 기술을 사용하지 않는다. 응용 프로그램은 GDI, Direct2D, Direct3D, OpenGL, Vulkan, XAML과 웹 렌더링 기술을 사용할 수 있으며, 최종 결과는 DWM이 다른 창과 함께 합성한다.

Windows 7에서는 화면 가장자리로 창을 끌어 최대화하거나 절반 크기로 배치하는 Aero Snap이 도입되었다. Windows 11에서는 이를 확장한 스냅 레이아웃과 스냅 그룹이 제공된다. 사용자는 미리 정의된 화면 영역에 여러 창을 배치하고, 함께 구성된 창 집합을 작업 표시줄에서 복원할 수 있다.

가상 데스크톱은 하나의 로그인 세션 안에서 창을 여러 작업 공간으로 구분한다. 각 가상 데스크톱은 별도의 창 집합을 표시하지만 같은 사용자 세션, 프로세스와 파일 시스템을 공유한다. 이는 원격 데스크톱 세션이나 별도의 사용자 로그인 세션과는 다른 기능이다.

시작 메뉴와 작업 표시줄

시작 메뉴와 작업 표시줄은 Windows에서 프로그램 실행, 창 전환, 검색과 시스템 상태 확인을 담당하는 핵심 셸 구성 요소다.

시작 메뉴와 작업 표시줄은 Windows 95에서 처음 도입되었다. 시작 버튼은 프로그램, 문서, 설정, 검색과 시스템 종료 기능에 접근하는 공통 진입점이 되었고, 작업 표시줄은 실행 중인 창과 시스템 상태를 한곳에 표시했다.

Windows XP에서는 시작 메뉴가 두 열 구조로 바뀌어 자주 사용하는 프로그램과 사용자 디렉터리, 시스템 위치를 함께 표시했다. Windows Vista와 Windows 7에서는 시작 메뉴에 통합 검색이 추가되어 프로그램과 파일을 이름으로 찾을 수 있게 되었다.

Windows 8은 시작 메뉴를 제거하고 타일 기반의 전체 화면 시작 화면을 도입했다. 데스크톱과 새로운 응용 프로그램 환경 사이의 전환이 커지면서 기존 PC 사용자에게 혼란을 일으켰고, Windows 8.1에서는 시작 버튼이 복원되었다.

Windows 10은 전통적인 프로그램 목록과 라이브 타일을 결합한 시작 메뉴를 다시 도입했다. Windows 11에서는 시작 메뉴가 화면 중앙을 기본 위치로 사용하고, 고정된 응용 프로그램과 추천 파일을 중심으로 재구성되었다. 라이브 타일은 제거되었으며 모든 응용 프로그램 목록은 별도 화면으로 분리되었다.

현대 Windows의 시작 메뉴는 다음 기능을 제공한다.

• 고정된 응용 프로그램 실행
• 설치된 모든 응용 프로그램 목록
• 최근 또는 추천 파일
• 사용자 계정 전환과 잠금
• 절전, 종료와 다시 시작
• 검색 인터페이스 접근
• 일부 시스템 위치와 설정으로 이동

시작 메뉴에 표시되는 응용 프로그램은 전통적인 시작 메뉴 디렉터리의 바로 가기, 설치된 패키지 응용 프로그램과 시스템 등록 정보를 조합하여 구성된다. 따라서 모든 항목이 하나의 실제 디렉터리에만 저장되는 것은 아니다.

작업 표시줄은 실행 중이거나 고정된 응용 프로그램을 표시한다. 같은 응용 프로그램의 여러 창은 하나의 작업 표시줄 항목으로 묶일 수 있으며, 항목 위에 포인터를 올리면 DWM이 생성한 창 미리 보기가 표시된다.

작업 표시줄에는 다음 요소가 포함될 수 있다.

• 시작 버튼
• 검색
• 작업 보기
• 고정 및 실행 중인 응용 프로그램
• 창 미리 보기
• 점프 목록
• 알림 영역
• 빠른 설정
• 시계와 달력
• 입력 언어와 키보드 상태
• 네트워크, 음량과 전원 상태

점프 목록은 응용 프로그램별 최근 파일, 고정 항목과 자주 사용하는 명령을 작업 표시줄 또는 시작 메뉴의 문맥 메뉴에 표시한다. 응용 프로그램은 자체 작업과 파일 목록을 점프 목록에 등록할 수 있다.

알림 영역은 백그라운드 프로그램과 시스템 기능의 상태 아이콘을 표시한다. 네트워크, 전원, 음량, 입력 방식과 보안 상태가 대표적이다. Windows 11에서는 일부 상태와 제어가 빠른 설정 패널로 통합되었다.

작업 표시줄과 시작 메뉴는 Explorer 및 여러 셸 구성 요소와 연결되지만 현대 Windows에서는 기능별 프로세스가 분리되어 있다. 시작 메뉴나 검색 구성 요소가 실패하더라도 파일 탐색기 전체를 항상 종료하지 않고 해당 구성 요소만 다시 시작할 수 있는 구조로 발전했다.

기업 환경에서는 그룹 정책과 모바일 장치 관리 정책을 통해 시작 메뉴 구성, 고정 항목, 작업 표시줄, 검색과 사용자 변경 가능 범위를 제어할 수 있다.

파일 탐색기

파일 탐색기는 Windows의 파일, 디렉터리, 드라이브, 네트워크 위치와 셸 개체를 탐색하고 관리하는 그래픽 응용 프로그램이다. 과거에는 Windows Explorer라는 이름이 사용되었으며, Windows 8 이후 사용자 인터페이스에서는 File Explorer라는 이름이 일반적으로 사용된다.

파일 탐색기는 단순히 NTFS 디렉터리만 표시하지 않는다. Windows 셸 이름 공간의 그래픽 표현으로 작동하므로 내 PC, 네트워크, 휴지통, 라이브러리, 검색 결과, 압축 디렉터리와 클라우드 저장소도 파일과 유사한 방식으로 표시한다.

Microsoft는 Windows Explorer가 셸 이름 공간을 그래픽으로 표시하고 사용자가 셸 개체와 상호 작용할 수 있는 도구를 제공한다고 설명한다.^[79]

파일 탐색기의 주요 구성 요소는 다음과 같다.

• 주소 표시줄
• 검색 상자
• 탐색 창
• 파일과 폴더 목록
• 세부 정보 창
• 미리 보기 창
• 도구 모음 또는 명령 모음
• 탭
• 상태 표시줄
• 문맥 메뉴

주소 표시줄은 현재 위치를 계층적으로 보여주고 사용자가 경로를 직접 입력할 수 있게 한다. 파일 시스템 경로뿐 아니라 일부 셸 경로, 네트워크 공유와 URI도 처리할 수 있다.

탐색 창은 빠른 접근, 사용자 폴더, OneDrive, 내 PC, 네트워크와 연결된 장치를 표시한다. 실제 구성은 Windows 버전, 설치된 셸 확장과 조직 정책에 따라 달라질 수 있다.

파일 탐색기는 아이콘, 목록, 세부 정보, 타일과 콘텐츠 보기 같은 여러 표시 방식을 제공한다. 파일 종류에 따라 이름, 수정 시각, 크기, 작성자, 길이, 해상도와 태그 같은 속성을 표시할 수 있다.

셸 속성 체계는 파일의 메타데이터를 공통된 이름으로 제공한다. 속성 처리기는 문서, 사진, 음악과 영상 파일에서 형식별 메타데이터를 읽어 파일 탐색기와 검색 인덱서에 전달한다.

파일 탐색기의 검색은 현재 디렉터리와 하위 위치를 대상으로 수행할 수 있다. Windows Search 인덱스가 포함된 위치에서는 미리 수집된 파일 이름, 속성과 내용 정보를 사용해 빠르게 결과를 찾고, 인덱스되지 않은 위치에서는 직접 파일을 검사할 수 있다.

파일 작업에는 복사, 이동, 이름 변경, 삭제와 속성 변경이 포함된다. 같은 볼륨 안의 이동은 파일 데이터 자체를 다시 복사하지 않고 디렉터리 정보를 변경하는 방식으로 처리될 수 있지만, 다른 볼륨으로 이동할 때에는 복사 후 원본 삭제 과정이 필요하다.

파일 탐색기는 휴지통을 통해 일반적인 로컬 파일 삭제를 복구 가능한 작업으로 처리한다. 네트워크 공유, 이동식 장치, 지나치게 큰 파일과 일부 특수 위치에서는 휴지통을 사용하지 않고 바로 삭제될 수 있다.

Windows 11의 파일 탐색기에는 여러 위치를 하나의 창에서 다룰 수 있는 탭 인터페이스와 새 명령 모음이 도입되었다. 이전의 리본 인터페이스보다 단순화되었지만, 일부 고급 명령은 문맥 메뉴나 추가 옵션 안에 배치된다.

파일 탐색기는 확장 가능한 구조를 가진다. 응용 프로그램은 셸 확장을 설치하여 다음 기능을 추가할 수 있다.

• 문맥 메뉴
• 아이콘 오버레이
• 미리 보기
• 축소판 그림
• 파일 속성
• 검색 기능
• 클라우드 파일 상태
• 가상 폴더와 장치 위치

Microsoft는 응용 프로그램이 Windows Explorer 창을 발견하거나 새 탐색기 창을 만들고 셸 개체와 상호 작용할 수 있는 인터페이스를 제공한다.^[80]

설정과 제어판

Windows의 그래픽 시스템 구성 도구는 현대적인 설정 앱과 전통적인 제어판으로 나뉜다. 두 도구는 일부 기능이 겹치지만 내부 구조와 설계 시기가 다르다.

제어판은 Windows의 시스템 수준 기능을 구성하기 위해 오래전부터 제공된 구성 도구다. 하드웨어, 프로그램, 보안, 유지 관리, 사용자 계정, 네트워크와 접근성 관련 항목을 범주 또는 아이콘 형태로 제공한다.

Microsoft는 제어판을 사용자가 시스템 수준 기능을 구성하고 관련 작업을 수행하는 Windows 환경으로 정의한다.^[81]

제어판 항목은 DLL 또는 실행 파일로 구현될 수 있으며, 각 항목은 특정 시스템 기능의 구성 인터페이스를 제공한다. Windows Vista 이후에는 제어판 항목에 언어에 독립적인 정식 이름을 부여하여 명령줄, API와 그룹 정책에서 실행하거나 제한할 수 있다.^[82]

전통적인 제어판에는 다음과 같은 영역이 포함된다.

• 프로그램과 기능
• 장치와 프린터
• 네트워크 및 공유 센터
• 전원 옵션
• 사용자 계정
• 파일 탐색기 옵션
• 글꼴
• 국가 또는 지역
• 소리
• 시스템 속성
• 관리 도구

설정 앱은 Windows 8에서 PC 설정이라는 형태로 시작되었고 Windows 10부터 운영체제의 기본 구성 인터페이스로 확대되었다. 터치, 고해상도 화면과 현대적인 Windows 디자인 체계를 고려하여 만들어졌으며, Windows 11에서는 대부분의 일반적인 설정이 이 앱에 배치된다.

설정 앱은 다음 영역을 다룬다.

• 시스템과 디스플레이
• Bluetooth와 장치
• 네트워크와 인터넷
• 개인 설정
• 응용 프로그램
• 계정
• 시간과 언어
• 게임
• 접근성
• 개인정보 및 보안
• Windows Update

응용 프로그램은 ms-settings: URI를 사용하여 설정 앱의 특정 페이지를 열 수 있다. 예를 들어 카메라 권한이나 네트워크 설정처럼 사용자가 직접 변경해야 하는 설정 위치로 연결할 수 있다. Microsoft는 Windows 응용 프로그램이 ms-settings: URI 체계를 사용해 특정 설정 페이지를 실행할 수 있도록 문서화하고 있다.^[83]

Windows는 여러 버전에 걸쳐 제어판 기능을 설정 앱으로 이동해 왔다. 디스플레이, 네트워크, 저장소, Bluetooth, 응용 프로그램 제거와 Windows Update 같은 기능은 설정 앱이 기본 인터페이스가 되었다.

그러나 모든 기능이 완전히 이전된 것은 아니다. 고급 전원 구성, 일부 네트워크 어댑터 속성, 파일 형식별 도구와 레거시 관리 기능은 제어판, Microsoft Management Console 또는 별도 관리 도구를 계속 사용할 수 있다.

일부 설정 앱 페이지는 내부적으로 기존 제어판이나 Win32 대화 상자를 실행하기도 한다. 반대로 제어판의 링크가 설정 앱으로 사용자를 전환하기도 한다. 따라서 두 인터페이스는 일정 기간 병행되는 전환 구조를 가진다.

기업 관리자는 그룹 정책과 모바일 장치 관리 정책을 사용해 설정 페이지를 숨기거나 표시할 수 있다. Microsoft는 Settings Page Visibility 정책을 통해 사용자와 컴퓨터별로 설정 앱 페이지 접근을 제한하는 기능을 제공한다.^[84]

설정 앱과 제어판은 사용자 인터페이스일 뿐이며 실제 시스템 구성은 레지스트리, 서비스, 장치 설정, 정책 저장소와 여러 시스템 데이터베이스에 분산되어 있다. 같은 설정이라도 적용 범위에 따라 현재 사용자, 컴퓨터 전체, 특정 장치 또는 조직 정책으로 저장될 수 있다.

명령 프롬프트

명령 프롬프트는 Windows의 전통적인 명령줄 인터페이스로, cmd.exe 명령 인터프리터를 사용한다. MS-DOS의 COMMAND.COM과 유사한 명령 문법을 계승했지만, 현대 Windows에서는 Win32 콘솔 응용 프로그램으로 실행되며 Windows NT의 파일 시스템과 프로세스 모델 위에서 동작한다.

Microsoft는 cmd를 Windows 명령 인터프리터의 새 인스턴스를 시작하는 명령으로 정의하며, Windows와 Windows Server에 기본 제공되는 Win32 콘솔 명령들을 실행할 수 있도록 한다.^[85][86]

명령 프롬프트는 다음과 같은 작업에 사용된다.

• 파일과 디렉터리 관리
• 프로그램 실행
• 환경 변수 설정
• 네트워크 상태 확인
• 디스크와 시스템 진단
• 서비스와 프로세스 관리
• 배치 파일 실행
• 다른 명령줄 도구 호출
• 복구 환경 작업

명령 프롬프트에는 내부 명령과 외부 명령이 있다. 내부 명령은 cmd.exe 자체가 처리하며, 외부 명령은 별도의 실행 파일로 제공된다.

대표적인 내부 명령은 다음과 같다.

• cd
• dir
• copy
• del
• set
• echo
• if
• for
• call
• setlocal
• endlocal

외부 명령에는 ipconfig.exe, robocopy.exe, tasklist.exe, sc.exe, diskpart.exe와 같은 시스템 도구가 포함된다.

명령 프롬프트는 파이프와 입출력 리디렉션을 지원한다.

• >는 출력을 파일에 새로 기록한다.
• >>는 출력을 파일 뒤에 추가한다.
• <는 파일을 표준 입력으로 사용한다.
• |는 앞 명령의 출력을 다음 명령의 입력으로 전달한다.
• 2>는 표준 오류를 별도로 리디렉션한다.

배치 파일은 일반적으로 .bat 또는 .cmd 확장자를 사용하며, 여러 명령을 순서대로 실행한다. 조건문, 반복문, 서브루틴과 환경 변수를 이용해 설치, 빌드와 관리 작업을 자동화할 수 있다.

명령 프롬프트의 파이프는 기본적으로 프로그램 사이에 텍스트 스트림을 전달한다. 명령의 출력 형식이 사람에게 읽기 좋게 설계된 경우 다른 명령이나 스크립트가 안정적으로 분석하기 어려울 수 있다. PowerShell은 이 한계를 보완하기 위해 명령 사이에 구조화된 객체를 전달한다.

cmd.exe는 오랜 호환성을 유지해야 하므로 오래된 배치 파일과 명령 문법을 계속 지원한다. 이 때문에 인용 부호, 특수 문자, 변수 확장과 명령 연결 규칙이 복잡하게 동작할 수 있다.

명령 프롬프트와 콘솔 창은 같은 개념이 아니다. cmd.exe는 명령을 해석하는 셸이고, 콘솔 호스트나 Windows Terminal은 셸의 텍스트 입력과 출력을 표시하는 터미널 역할을 한다. 같은 명령 프롬프트를 전통적인 콘솔 창이나 Windows Terminal 탭 안에서 실행할 수 있다.

PowerShell과 Windows Terminal

PowerShell은 명령줄 셸, 스크립트 언어와 자동화 프레임워크를 결합한 관리 환경이다. 명령 프롬프트가 주로 텍스트 기반 명령과 배치 파일을 사용하는 것과 달리, PowerShell은 명령 사이에 .NET 객체를 전달한다.

Microsoft는 PowerShell을 명령줄 셸, 스크립트 언어와 구성 관리 프레임워크로 이루어진 크로스 플랫폼 작업 자동화 솔루션으로 정의한다.^[87]

PowerShell 명령은 주로 cmdlet이라는 작은 단위로 구성된다. cmdlet은 일반적으로 동사-명사 형태의 이름을 사용한다.

• Get-Process
• Get-Service
• Set-Location
• Copy-Item
• Get-ChildItem
• Start-Process
• Stop-Service

PowerShell 파이프라인은 앞 명령이 출력한 객체를 다음 명령에 전달한다. 다음 명령은 문자열의 특정 위치를 분석하는 대신 객체의 속성과 형식을 직접 사용할 수 있다.

PowerShell 객체 파이프라인

1. 명령이 프로세스 객체 생성
   ↓
2. 파이프라인으로 객체 전달
   ↓
3. 다음 명령이 객체의 CPU 또는 메모리 속성 검사
   ↓
4. 조건과 일치하는 객체 선택
   ↓
5. 필요한 속성만 출력하거나 후속 작업 실행

PowerShell은 다음과 같은 명령 유형을 실행할 수 있다.

• cmdlet
• PowerShell 함수
• 스크립트
• 별칭
• 외부 실행 파일
• 전통적인 Windows 명령
• .NET 메서드
• 원격 컴퓨터의 명령

PowerShell 스크립트는 일반적으로 .ps1 확장자를 사용한다. 변수, 함수, 클래스, 조건문, 반복문, 예외 처리와 모듈을 지원하며, Windows 관리 도구와 Microsoft 제품이 제공하는 관리 API를 호출할 수 있다.

PowerShell Remoting은 WinRM 또는 SSH를 통해 원격 컴퓨터에서 명령을 실행할 수 있다. 관리자는 한 컴퓨터에서 여러 서버와 클라이언트의 서비스, 파일, 레지스트리, 역할과 설정을 자동화할 수 있다.

Windows에는 Windows PowerShell과 현대적인 PowerShell이 구분되어 존재한다. Windows PowerShell 5.1은 Windows와 .NET Framework에 포함된 기존 제품이며, Windows 호환 모듈을 위해 계속 제공된다. 현대 PowerShell은 .NET을 기반으로 Windows, Linux와 macOS에서 실행되는 오픈 소스·크로스 플랫폼 제품이다. Microsoft는 Windows PowerShell에 새로운 기능을 더 이상 추가하지 않는다고 설명한다.^[88]

Windows Terminal은 명령을 해석하는 셸이 아니라 여러 명령줄 응용 프로그램을 실행하고 표시하는 터미널 응용 프로그램이다. Command Prompt, PowerShell, Windows Subsystem for Linux와 SSH 세션을 각각 프로필과 탭으로 실행할 수 있다.

Windows Terminal은 다음 기능을 제공한다.

• 여러 탭과 창 분할
• Command Prompt, PowerShell와 WSL 프로필
• Unicode와 UTF-8
• GPU 가속 텍스트 렌더링
• 글꼴과 색 구성표
• 배경과 투명 효과
• 키 바인딩
• 명령 팔레트
• 검색과 선택
• 사용자 정의 시작 디렉터리
• JSON 및 그래픽 설정 인터페이스

Microsoft는 Windows Terminal이 Unicode와 UTF-8 문자를 지원하고 GPU를 이용해 텍스트를 렌더링한다고 설명한다.^[89]

Windows Terminal의 프로필은 실행할 셸, 시작 디렉터리, 아이콘, 글꼴, 색 구성표와 명령줄을 정의한다. 사용자는 PowerShell, Command Prompt와 여러 Linux 배포판을 하나의 터미널 안에서 전환할 수 있다.

Windows Terminal은 기존 콘솔 응용 프로그램과의 호환성을 유지하면서 현대적인 터미널 기능을 제공한다. 응용 프로그램이 콘솔 API 또는 가상 터미널 시퀀스를 사용해 출력하면 Windows Terminal이 이를 화면에 표시한다.

PowerShell과 Windows Terminal은 서로 대체 관계가 아니다.

• PowerShell은 명령을 해석하고 스크립트를 실행하는 셸이다.
• Windows Terminal은 PowerShell과 다른 셸의 화면 입출력을 제공하는 터미널이다.
• Command Prompt도 Windows Terminal 안에서 실행할 수 있다.
• WSL의 Bash와 다른 UNIX 셸도 Windows Terminal 프로필로 사용할 수 있다.

접근성

Windows는 시각, 청각, 이동, 언어와 인지 능력에 따른 사용 장벽을 줄이기 위해 운영체제 수준의 접근성 기능을 제공한다. 이러한 기능은 별도 응용 프로그램뿐 아니라 로그인 화면, 바탕 화면, 설정과 기본 시스템 인터페이스에서도 사용할 수 있다.

Windows의 주요 접근성 기능은 다음과 같다.

• Narrator 화면 읽기 프로그램
• 돋보기
• 고대비 및 대비 테마
• 색 필터
• 텍스트 크기와 화면 배율
• 음성 접근
• 음성 입력
• 실시간 캡션
• 모노 오디오
• 알림 시각화
• 고정 키
• 필터 키
• 토글 키
• 화상 키보드
• 눈 제어
• 마우스 키
• 포인터 크기와 색상 변경
• 자막과 청각 보조 장치 설정

Microsoft는 Windows 접근성 기능으로 Narrator, 돋보기, 음성 접근, 화면 읽기, 키보드와 마우스 보조 기능 등을 제공한다.^[90]

Narrator는 Windows에 기본 포함된 화면 읽기 프로그램이다. 화면의 텍스트와 사용자 인터페이스 요소를 음성 또는 점자 디스플레이로 전달하고, 키보드와 터치 명령으로 창, 문서와 웹 콘텐츠를 탐색할 수 있다.

Narrator는 로그인 전 접근성 메뉴에서도 실행할 수 있으므로 사용자가 별도의 화면 읽기 프로그램을 설치하지 않고 Windows 설치와 로그인 과정에 접근할 수 있다. 음성 속도, 음높이, 자세한 읽기 수준, 문장 부호와 키보드 피드백을 조정할 수 있다.^[91]

돋보기는 화면 일부 또는 전체를 확대한다. 전체 화면, 렌즈와 도킹 보기 방식을 지원하며, 포인터와 키보드 포커스를 따라 이동할 수 있다. 확대된 화면의 텍스트를 읽어 주는 기능도 제공될 수 있다.

대비 테마와 색 필터는 화면 요소를 구분하기 어려운 사용자를 지원한다. 대비 테마는 배경과 텍스트, 링크와 선택 항목의 색상 차이를 크게 만들고, 색 필터는 색각 특성에 맞게 화면 색상을 변환한다.

텍스트 크기 설정은 화면 전체 배율을 바꾸지 않고 지원되는 인터페이스의 글자 크기를 확대한다. 디스플레이 배율은 응용 프로그램, 창과 다른 화면 요소 전체의 논리적 크기를 조정한다.

음성 접근은 Windows 11에서 음성만으로 컴퓨터와 응용 프로그램을 제어하고 텍스트를 작성할 수 있게 한다. 응용 프로그램 실행, 창 전환, 버튼 선택, 화면의 위치 지정과 받아쓰기를 지원하며, Microsoft는 인터넷 연결 없이도 사용할 수 있는 기능으로 설명한다.^[92]

실시간 캡션은 시스템에서 재생되는 오디오의 음성을 화면에 자막으로 표시한다. 지원되는 하드웨어와 언어에서는 번역이나 추가 처리 기능이 제공될 수 있으며, 회의, 영상과 직접 대화를 이해하는 데 사용된다.

고정 키는 Shift, Ctrl, Alt와 Windows 키 같은 보조 키를 동시에 누르지 않고 순서대로 사용할 수 있게 한다. 필터 키는 짧거나 반복되는 키 입력을 무시하거나 반복 속도를 조절하며, 토글 키는 Caps Lock과 Num Lock 상태 변화를 소리로 알린다.

화상 키보드는 물리 키보드 없이 포인터, 터치 또는 보조 입력 장치로 문자를 입력할 수 있게 한다. 눈 제어는 지원되는 시선 추적 장치를 이용해 포인터 이동, 클릭, 스크롤과 텍스트 입력을 수행한다.

Windows의 접근성은 내장 기능에만 한정되지 않는다. Microsoft UI Automation과 기존 접근성 API는 화면 읽기 프로그램, 음성 제어 도구와 자동화 도구가 응용 프로그램의 버튼, 메뉴, 문서 구조와 상태를 인식하도록 한다.

접근 가능한 Windows 응용 프로그램은 다음 정보를 보조 기술에 제공해야 한다.

• 요소의 이름과 역할
• 현재 값과 상태
• 키보드 포커스
• 사용 가능한 동작
• 부모·자식 관계
• 선택과 확장 상태
• 변경 알림
• 텍스트 구조와 읽기 순서

Win32, Windows App SDK, WPF, Windows Forms, 웹 기술과 다른 UI 프레임워크는 서로 다른 방식으로 접근성 API에 연결된다. 사용자 정의 컨트롤을 만드는 개발자는 기본 컨트롤이 자동으로 제공하는 접근성 정보를 직접 구현해야 할 수 있다.

접근성 설정은 Windows 설정 앱의 접근성 영역에 모여 있지만, 일부 기능은 로그인 화면의 접근성 메뉴와 키보드 바로 가기로도 실행할 수 있다. 이는 사용자가 로그인하거나 설정 앱을 탐색하기 전에도 필요한 보조 기능을 켤 수 있도록 한다.

Windows는 오랜 기간 서로 다른 시대에 만들어진 응용 프로그램 모델을 함께 지원해 왔다. 저수준에서는 Windows API와 Win32가 프로세스, 창, 파일, 네트워크와 장치 기능을 제공하고, 그 위에는 COM, OLE, .NET, Windows Runtime과 여러 사용자 인터페이스 프레임워크가 구축된다.

Windows 응용 프로그램은 반드시 하나의 기술만 사용하지 않는다. 하나의 프로그램이 Win32로 창과 프로세스를 관리하고, COM으로 시스템 구성 요소를 호출하며, .NET 런타임에서 업무 논리를 실행하고, MSIX로 패키징될 수 있다. 현대 Windows는 기존 데스크톱 응용 프로그램과 패키지 기반 응용 프로그램을 모두 지원하며, Windows App SDK를 통해 기존 Win32 프로그램에서도 최신 Windows 기능을 사용할 수 있도록 한다.

Windows 응용 프로그램 환경의 주요 계층

• Windows 응용 프로그램
  • 네이티브 데스크톱 응용 프로그램
    • Windows API와 Win32
    • COM과 OLE
    • MFC
    • Windows App SDK와 WinUI
  • 관리형 응용 프로그램
    • .NET Framework
    • 현대 .NET
    • Windows Forms
    • WPF
  • Windows Runtime 응용 프로그램
    • WinRT
    • UWP
    • Windows Runtime 구성 요소
  • 다른 실행 환경
    • 웹 응용 프로그램
    • Java와 그 밖의 가상 머신
    • Windows Subsystem for Linux
    • 가상화 및 컨테이너 환경

Windows의 응용 프로그램 호환성은 API 유지, 명령어 집합 변환, 파일과 레지스트리 리디렉션, 응용 프로그램별 호환성 수정과 오래된 런타임 유지에 의해 제공된다. 이러한 계층은 이전 프로그램을 계속 실행할 수 있게 하지만, 모든 과거 응용 프로그램과 드라이버가 현대 Windows에서 완전히 같은 방식으로 동작한다는 의미는 아니다.

Windows API

Windows API는 응용 프로그램이 Windows 운영체제의 기능을 사용하는 데 필요한 함수, 인터페이스, 데이터 형식, 메시지와 규약의 집합이다. 프로세스와 스레드 생성, 파일 입출력, 창과 사용자 입력, 네트워크, 보안, 서비스, 그래픽, 오디오와 장치 접근 기능을 제공한다.

Microsoft는 Windows API를 과거 Win32 API라고 불렀던 Windows 데스크톱 및 서버 응용 프로그램용 인터페이스로 설명한다. Windows API라는 이름은 이 인터페이스가 16비트 Windows에서 기원하고 32비트와 64비트 Windows까지 이어졌다는 점을 더 정확히 나타낸다.^[93]

Windows API는 하나의 단일 라이브러리 파일이 아니다. 기능별 헤더, 가져오기 라이브러리와 시스템 DLL로 나뉘며, 응용 프로그램은 필요한 인터페이스를 조합하여 사용한다.

대표적인 기능 영역은 다음과 같다.

• 프로세스와 스레드
• 가상 메모리와 힙
• 파일과 디렉터리
• 장치와 입출력
• 창과 사용자 입력
• 그래픽과 글꼴
• 네트워크와 소켓
• 서비스와 시스템 관리
• 사용자 계정과 보안
• 레지스트리
• 동기화
• 콘솔
• COM
• 멀티미디어
• 인쇄
• 암호화와 인증
• 디버깅과 성능 분석

C와 C++ 프로그램은 Windows SDK에 포함된 헤더를 통해 함수와 자료형을 선언하고, 가져오기 라이브러리를 연결하여 시스템 DLL의 내보낸 함수를 호출한다. 실행 시 Windows 로더가 DLL을 프로세스 주소 공간에 매핑하고 가져오기 주소를 해결한다.

응용 프로그램이 호출하는 Windows API가 항상 커널 시스템 호출과 일대일로 대응하는 것은 아니다. 상당수 함수는 사용자 모드에서 처리되거나 여러 내부 요청으로 나뉘며, 일부는 COM 서비스, 시스템 프로세스 또는 장치 드라이버와 통신한다.

Windows API 호출의 일반적인 흐름

1. 응용 프로그램이 문서화된 Windows API 호출
   ↓
2. 사용자 모드 시스템 DLL이 인수 검사와 변환 수행
   ↓
3. 필요하면 COM, 시스템 서비스 또는 커널 서비스 요청
   ↓
4. Windows 실행부나 대상 시스템 구성 요소가 작업 처리
   ↓
5. 상태 코드와 결과를 사용자 모드로 반환
   ↓
6. API가 응용 프로그램 형식으로 결과 전달

Windows API는 C 기반 인터페이스가 많지만 C++뿐 아니라 Rust, Zig, Pascal, Python과 그 밖의 언어에서도 외부 함수 인터페이스를 통해 사용할 수 있다. .NET과 Java 같은 관리형 환경도 내부적으로 Windows 기능이 필요할 때 네이티브 API를 호출한다.

Windows API의 주요 자료형 가운데 HANDLE, HWND, HINSTANCE, HKEY와 같은 형식은 운영체제 객체나 사용자 인터페이스 객체에 대한 간접 식별자를 나타낸다. 응용 프로그램은 내부 구조에 직접 접근하지 않고 이러한 핸들과 전용 API를 사용한다.

Windows API는 넓은 호환성을 위해 오래된 함수와 규칙을 상당 부분 유지한다. 다만 모든 API가 모든 Windows 버전과 응용 프로그램 모델에서 허용되는 것은 아니다. 특정 함수는 Windows 버전, 제품군, 보안 문맥이나 패키지 권한에 따라 제한될 수 있다.

Windows는 내부 구현 DLL과 응용 프로그램이 참조하는 논리적 API를 분리하기 위해 API 세트를 사용한다. 응용 프로그램이 논리적인 API 세트 이름을 참조하면 로더가 현재 Windows 버전에서 실제 구현을 제공하는 호스트 모듈로 연결한다. 이를 통해 내부 DLL 구성을 변경하면서도 외부 응용 프로그램 인터페이스를 유지할 수 있다.

Win32

Win32는 Windows NT와 Windows 95 이후 Windows 응용 프로그램의 중심이 된 네이티브 32비트 응용 프로그램 인터페이스와 실행 모델이다. 명칭에는 32비트가 포함되어 있지만, 현대에는 같은 API 계열이 64비트 Windows 데스크톱 프로그램에도 사용되므로 Win32는 단순한 프로세서 비트 수보다 Windows의 전통적인 네이티브 데스크톱 플랫폼을 뜻한다.

Microsoft는 Win32 API를 Windows 응용 프로그램의 네이티브 플랫폼으로 정의하며, 시스템 기능과 하드웨어에 직접 접근해야 하는 데스크톱 응용 프로그램에 적합하다고 설명한다.^[94]

Win32는 다음과 같은 요소로 구성된다.

• PE 형식의 실행 파일과 DLL
• Windows API 함수
• 창과 메시지 기반 사용자 인터페이스
• 프로세스와 스레드 모델
• 핸들 기반 객체 접근
• COM 구성 요소
• 레지스트리와 서비스
• 동적 연결 라이브러리
• Windows 보안과 액세스 토큰
• 파일과 장치 입출력
• 설치 프로그램 또는 패키지 기반 배포

전통적인 Win32 GUI 프로그램은 창 클래스를 등록하고 창을 생성한 뒤 메시지 루프를 실행한다. Windows는 키보드, 마우스, 창 크기 변경, 다시 그리기와 시스템 상태 변화를 메시지 형태로 전달하고, 응용 프로그램의 창 프로시저가 이를 처리한다.

전통적인 Win32 GUI 프로그램의 실행 흐름

1. 프로세스 시작과 런타임 초기화
   ↓
2. 창 클래스 등록
   ↓
3. 주 창 생성
   ↓
4. 창 표시
   ↓
5. 메시지 큐에서 메시지 획득
   ↓
6. 메시지 번역과 창 프로시저 전달
   ↓
7. 사용자 입력과 창 동작 처리
   ↓
8. 종료 메시지를 받을 때까지 반복

Win32 프로그램은 반드시 C나 C++로 작성할 필요는 없지만, API 자체가 C ABI를 중심으로 설계되었기 때문에 C와 C++에서 가장 직접적으로 사용할 수 있다. MFC, ATL, Qt, wxWidgets, SDL과 여러 게임 엔진은 Win32 위에 더 높은 수준의 추상화를 제공한다.

Win32는 비교적 자유로운 실행 모델을 가진다. 일반 데스크톱 프로그램은 사용자의 권한 범위 안에서 파일 시스템, 레지스트리, 창, 프로세스, 네트워크와 장치 인터페이스를 직접 사용할 수 있다. UWP처럼 기능 선언과 응용 프로그램 컨테이너를 기본 전제로 하지 않는다.

이 자유도는 기존 프로그램과 복잡한 전문 도구를 구현하는 데 유리하지만, 설치 과정에서 시스템 전체의 파일과 레지스트리를 변경하거나 높은 권한의 서비스와 셸 확장을 추가할 수도 있다. 따라서 응용 프로그램의 보안과 제거 품질은 프로그램 및 설치 기술의 구현에 크게 좌우된다.

32비트와 64비트 Win32 프로그램은 같은 핵심 API 개념을 사용하지만 포인터와 일부 자료형의 크기가 다르다. Windows 헤더는 포인터 크기에 따라 달라지는 LONG_PTR, UINT_PTR, WPARAM, LPARAM 같은 형식을 제공한다.

64비트 Windows에서도 Win32라는 명칭은 계속 사용된다. Microsoft의 Windows API 문서는 같은 함수들이 일반적으로 32비트와 64비트 Windows에서 지원된다고 설명한다.^[95]

현대 Windows의 새 데스크톱 응용 프로그램도 Win32 프로세스 모델을 사용할 수 있다. Windows App SDK와 WinUI 3은 전통적인 데스크톱 응용 프로그램에 최신 Windows UI와 수명 주기, 알림, 창 관리와 패키지 기능을 제공하며 기존 Win32, WPF와 Windows Forms 프로그램에 점진적으로 추가할 수도 있다.^[96]

COM과 OLE

Component Object Model 또는 COM은 서로 다른 언어와 실행 파일에서 구현된 소프트웨어 구성 요소가 바이너리 인터페이스를 통해 상호 작용하도록 하는 Windows의 구성 요소 모델이다.

Microsoft는 COM을 상호 작용 가능한 바이너리 소프트웨어 구성 요소를 만들기 위한 분산 객체 지향 체계로 정의하며, OLE와 ActiveX를 비롯한 여러 Microsoft 기술의 기반이라고 설명한다.^[97]

COM은 특정 프로그래밍 언어의 클래스 구현 방식보다 바이너리 인터페이스 계약을 정의한다. 구성 요소가 규정된 메모리 배치와 호출 규약을 따르면 C++, Delphi, Visual Basic과 다른 언어에서 작성한 구성 요소끼리 사용할 수 있다.

COM 객체는 하나 이상의 인터페이스를 구현한다. 각 인터페이스는 변경되지 않는 메서드 집합과 고유한 인터페이스 식별자를 가진다. 모든 기본 COM 객체는 IUnknown 인터페이스를 통해 다음 기능을 제공한다.

• 지원하는 다른 인터페이스 질의
• 객체 참조 횟수 증가
• 객체 참조 횟수 감소

QueryInterface는 같은 객체가 제공하는 다른 인터페이스 포인터를 얻고, AddRef와 Release는 참조 횟수 기반 수명 관리를 수행한다. 마지막 참조가 해제되면 객체가 자신을 제거할 수 있다.

COM 클래스는 클래스 식별자 또는 CLSID로 구분된다. 응용 프로그램은 COM 런타임에 CLSID와 원하는 인터페이스를 전달해 객체 생성을 요청하고, 런타임은 등록 정보나 패키지 메타데이터를 이용해 구현을 찾는다.

COM 구성 요소는 다음 형태로 실행될 수 있다.

• 호출한 프로세스 안에 적재되는 DLL 서버
• 별도 프로세스에서 실행되는 로컬 서버
• 서비스 형태의 구성 요소
• 다른 컴퓨터에서 실행되는 분산 COM 서버
• 등록 없이 응용 프로그램 매니페스트로 활성화되는 구성 요소
• 패키지 정체성을 사용해 등록되는 구성 요소

프로세스가 다른 COM 객체를 호출할 때 COM은 프록시와 스텁을 사용해 매개변수를 프로세스 경계 너머로 전달할 수 있다. 호출자는 원격 또는 별도 프로세스 객체를 같은 인터페이스 형태로 다루지만, 실제 호출 비용과 실패 조건은 프로세스 내부 호출과 다르다.

COM은 Windows의 여러 기능에 사용된다.

• 셸 확장
• 파일 탐색기와 문맥 메뉴
• DirectShow와 미디어 구성 요소
• Windows Management Instrumentation
• Office 자동화
• ActiveX 컨트롤
• 드래그 앤 드롭과 클립보드
• Windows Runtime의 기반
• 시스템 관리와 서비스 인터페이스

OLE는 COM을 기반으로 응용 프로그램 사이의 문서 개체 연결, 포함과 편집을 제공하는 기술이다. 이름은 Object Linking and Embedding에서 유래했으며, 한 응용 프로그램에서 만든 표, 그림, 문서와 다른 개체를 다른 문서 안에 연결하거나 포함할 수 있게 한다.

Microsoft는 OLE를 여러 응용 프로그램에서 만든 개체를 포함하는 복합 문서를 생성하고 편집하는 메커니즘으로 설명한다.^[98]

포함된 개체는 컨테이너 문서 안에 자체 데이터 복사본이 저장된다. 원본 파일이 없어도 개체를 표시할 수 있지만 컨테이너 파일의 크기가 커질 수 있다.

연결된 개체는 원본 파일이나 데이터 원본에 대한 참조를 저장한다. 원본이 바뀌면 연결된 문서에서 변경을 반영할 수 있지만, 원본 파일이 이동되거나 접근할 수 없으면 연결이 끊어질 수 있다.

OLE는 다음 기능과 연결된다.

• 문서 안의 개체 포함
• 연결된 데이터 갱신
• 제자리 편집
• 클립보드 데이터 형식
• 드래그 앤 드롭
• 구조화 저장소
• 응용 프로그램 자동화

OLE Automation 또는 Automation은 응용 프로그램이 자체 객체와 기능을 스크립트나 다른 프로그램에 공개할 수 있게 한다. Microsoft Office 응용 프로그램을 Visual Basic, PowerShell, C#이나 다른 COM 클라이언트에서 제어하는 방식이 대표적이다.^[99]

COM과 OLE는 오래된 기술이지만 Windows와 업무용 소프트웨어에 깊게 통합되어 있다. 현대 응용 프로그램에서도 파일 탐색기, Office, DirectX의 일부 구성 요소와 WinRT 연결 과정에서 COM을 사용할 수 있다.

.NET

.NET은 관리형 코드 실행 환경, 기본 클래스 라이브러리, 언어와 개발 도구를 제공하는 응용 프로그램 플랫폼이다. Windows에서는 데스크톱 응용 프로그램, 웹 서비스, 서버 프로그램, 명령줄 도구와 게임을 개발하는 데 사용된다.

.NET 프로그램의 소스 코드는 일반적으로 C#, F# 또는 Visual Basic으로 작성된다. 컴파일 결과는 특정 프로세서의 완전한 기계어만이 아니라 공통 중간 언어와 메타데이터를 포함하는 관리형 어셈블리로 만들어질 수 있다.

실행 시 .NET 런타임은 다음 기능을 제공한다.

• 어셈블리와 형식 적재
• 중간 언어의 기계어 변환
• 가비지 컬렉션
• 예외 처리
• 스레드와 비동기 작업
• 형식 안전성
• 리플렉션
• 네이티브 코드와 상호 운용
• 기본 클래스 라이브러리
• 진단과 디버깅 지원

Windows에는 역사적으로 .NET Framework가 널리 사용되었다. .NET Framework는 Windows 응용 프로그램과 웹 서비스를 구축하고 실행하기 위한 Windows 중심 플랫폼이며, 공용 언어 런타임과 Framework Class Library를 제공한다.^[100]

.NET Framework의 주요 Windows 데스크톱 UI 기술에는 Windows Forms와 Windows Presentation Foundation이 있다.

Windows Forms는 Win32 창과 컨트롤을 관리형 객체로 감싸고, Visual Studio의 시각적 디자이너를 중심으로 데스크톱 응용 프로그램을 만들 수 있게 한다. Microsoft는 Windows Forms를 Windows 데스크톱 응용 프로그램을 구축하기 위한 .NET UI 프레임워크로 정의한다.^[101]

Windows Presentation Foundation 또는 WPF는 XAML, 벡터 그래픽, 데이터 바인딩, 스타일, 템플릿과 합성 기반 렌더링을 사용하는 Windows 전용 UI 프레임워크다. 현대 .NET에서도 계속 지원된다.^[102]

.NET Framework는 Windows에 포함되거나 Windows 기능으로 설치되는 방식이 사용되며, 여러 기존 기업용 프로그램과 관리 도구가 의존한다. .NET Framework 4.x는 같은 계열 안에서 기존 버전을 대체하는 방식으로 갱신되어 왔다.

현대의 .NET은 .NET Core에서 이어진 오픈 소스·크로스 플랫폼 제품이다. Windows, Linux와 macOS에서 실행될 수 있으며, 데스크톱, 웹, 클라우드, 모바일과 명령줄 응용 프로그램 개발을 지원한다.^[103]

현대 .NET은 Windows에서 다음 방식으로 배포할 수 있다.

• 컴퓨터에 설치된 공유 .NET 런타임 사용
• 응용 프로그램과 필요한 런타임을 함께 배포
• 단일 파일 배포
• 사용하지 않는 구성 요소를 제거한 트리밍 배포
• 미리 기계어로 컴파일한 Native AOT 배포
• MSIX와 다른 패키지 형식 사용

공유 런타임을 사용하는 프로그램은 대상 .NET 버전이 컴퓨터에 설치되어 있어야 한다. 자체 포함 배포는 응용 프로그램에 필요한 런타임을 함께 제공하므로 컴퓨터의 전역 런타임 설치에 덜 의존하지만 배포 크기가 커질 수 있다.

.NET 관리형 코드는 필요할 때 Windows API와 COM을 호출할 수 있다. 플랫폼 호출 또는 P/Invoke는 네이티브 DLL 함수를 호출하고, COM Interop은 COM 인터페이스를 관리형 객체처럼 사용할 수 있게 한다. 반대로 COM이나 네이티브 프로그램이 .NET 구성 요소를 호출하는 구조도 만들 수 있다.

.NET Framework와 현대 .NET은 이름과 상당수 API 개념을 공유하지만 같은 제품의 단순한 버전 차이는 아니다. 런타임, 배포 방식, 지원 플랫폼과 일부 라이브러리가 다르며, 기존 .NET Framework 프로그램을 현대 .NET으로 옮길 때에는 프로젝트와 의존성의 호환성을 확인해야 한다.

WinRT와 Universal Windows Platform

Windows Runtime 또는 WinRT는 Windows 8에서 도입된 현대적인 Windows API와 구성 요소 모델이다. 언어에 독립적인 형식 체계, 메타데이터와 비동기 API를 제공하며 C++, C#, Visual Basic과 JavaScript 같은 여러 언어에서 사용할 수 있도록 설계되었다.

Microsoft는 WinRT를 Windows 응용 프로그램을 만들기 위한 언어 독립적인 API 집합으로 설명하며, COM을 기반으로 현대적인 객체 지향 인터페이스를 제공한다고 설명한다.^[104]

WinRT는 COM의 바이너리 구성 요소 개념을 계승하지만, 다음 요소를 표준화한다.

• 런타임 클래스
• 인터페이스와 메타데이터
• 속성, 이벤트와 대리자
• 비동기 작업
• 언어별 프로젝션
• 버전 관리
• 활성화
• 제한된 공통 형식 체계

WinRT API는 Windows 메타데이터 파일에 기술된다. 각 프로그래밍 언어의 프로젝션은 같은 WinRT 형식을 해당 언어에서 자연스러운 클래스, 메서드, 속성과 비동기 문법으로 표시한다.

C++에서는 C++/WinRT를 사용해 WinRT API를 호출하거나 런타임 클래스를 구현할 수 있다. Microsoft는 C++/WinRT를 표준 C++17 기반의 헤더 전용 WinRT 언어 프로젝션으로 설명한다.^[105]

Universal Windows Platform 또는 UWP는 Windows 10 계열 장치에서 공통 API, 응용 프로그램 수명 주기, 보안 모델과 패키지 형식을 사용하는 응용 프로그램 플랫폼이다. PC, 태블릿, Xbox, HoloLens와 과거의 Windows Phone 등 서로 다른 장치 계열에서 공통 코드와 WinRT API를 사용할 수 있도록 설계되었다.

Microsoft는 UWP를 Windows 10과 Windows 11 장치에서 실행되는 응용 프로그램을 만드는 선택지 중 하나로 설명한다. UWP 응용 프로그램은 WinRT API뿐 아니라 허용된 Win32 API와 .NET 클래스 일부도 사용할 수 있다.^[106]

UWP 응용 프로그램은 일반적으로 다음 특징을 가진다.

• AppX 또는 MSIX 패키지
• 고유한 패키지 정체성
• 응용 프로그램 매니페스트
• 기능과 장치 접근 선언
• 응용 프로그램 컨테이너
• 설치와 제거의 일관성
• Microsoft Store 배포
• 일시 중단과 재개 수명 주기
• 여러 장치 계열을 위한 API 계약
• WinRT와 XAML 기반 사용자 인터페이스

UWP 응용 프로그램은 기본적으로 응용 프로그램 컨테이너에서 실행되어 파일, 레지스트리와 장치 접근이 제한된다. 카메라, 마이크, 위치, 네트워크 서비스와 사용자 파일에 접근할 때에는 매니페스트 기능 선언이나 사용자의 명시적인 파일 선택이 필요할 수 있다.

패키지 매니페스트에는 응용 프로그램의 식별자, 실행 진입점, 로고, 기능, 파일 연결, 프로토콜, 백그라운드 작업과 대상 장치 계열이 기록된다.

UWP는 하나의 실행 파일이 모든 Windows 장치에서 동일한 사용자 인터페이스와 기능을 반드시 제공한다는 뜻은 아니다. 응용 프로그램은 장치 계열, 화면 크기와 사용 가능한 API 계약을 감지하고 기능과 화면을 조정할 수 있다.

UWP는 계속 지원되지만 현대 Windows의 새 응용 프로그램 개발에서는 WinUI 3와 Windows App SDK가 우선적인 방향으로 안내된다. Microsoft는 기존 UWP 응용 프로그램이 계속 작동하지만, 최신 WinUI와 Windows App SDK 기능을 사용하려면 마이그레이션을 고려하도록 설명한다.^[107][108]

Windows App SDK는 운영체제에 결합된 UWP 플랫폼을 완전히 대체하는 새 운영체제 API 자체라기보다, 현대 Windows 기능을 기존 데스크톱 응용 프로그램 모델에서도 사용할 수 있게 제공하는 개발 구성 요소다. Win32, WPF와 Windows Forms 프로그램에 추가할 수 있으며 WinUI 3, 창 관리, 알림, 응용 프로그램 수명 주기와 배포 기능을 제공한다.^[109]

패키지와 설치 기술

Windows 응용 프로그램은 단순한 파일 복사, 전용 설치 프로그램, Windows Installer, ClickOnce, AppX, MSIX와 Microsoft Store 등 여러 방식으로 배포된다. 설치 기술은 파일 배치뿐 아니라 레지스트리, 서비스, 바로 가기, 런타임 의존성, 업데이트와 제거를 관리한다.

가장 단순한 프로그램은 실행 파일과 필요한 DLL을 하나의 디렉터리에 복사하는 방식으로 사용할 수 있다. 이러한 포터블 응용 프로그램은 시스템 전체 설치가 필요하지 않을 수 있지만, 파일 연결, 서비스, 공유 구성 요소와 자동 업데이트가 필요하면 별도 등록 과정이 추가된다.

전통적인 Windows 프로그램은 setup.exe 같은 전용 설치 프로그램을 사용한다. 설치 프로그램은 파일 복사, 압축 해제, 런타임 설치, 관리자 권한 상승과 여러 패키지 연결을 담당할 수 있다. 실행 파일 형식 자체가 특정 설치 체계를 의미하지는 않으며 내부적으로 MSI나 다른 배포 기술을 호출할 수도 있다.

Windows Installer는 Windows에 포함된 설치와 구성 서비스다. 일반적으로 .msi 파일을 사용하며, 제품의 파일, 구성 요소, 기능, 레지스트리와 설치 동작을 관계형 데이터베이스 형태로 기술한다.

Microsoft는 Windows Installer를 응용 프로그램 설치와 구성을 효율적으로 관리하는 Windows 서비스로 설명한다.^[110]

MSI 패키지는 일반적으로 다음 기능을 제공한다.

• 제품과 구성 요소 등록
• 사용자별 또는 컴퓨터별 설치
• 기능 선택 설치
• 복구
• 롤백
• 패치 적용
• 업그레이드
• 자동화된 무인 설치
• 조직 정책에 따른 배포
• 제거
• 공유 구성 요소의 참조 관리

MSI 파일에는 Windows Installer가 제품을 설치하고 제거하는 데 필요한 설치 데이터베이스와 요약 정보, 데이터 스트림이 포함된다.^[111]

컴퓨터별 설치는 일반적으로 모든 사용자에게 프로그램을 제공하고 관리자 권한을 요구할 수 있다. 사용자별 설치는 특정 사용자 프로필을 대상으로 하며, Windows Installer는 두 설치 문맥을 구분한다.^[112]

ClickOnce는 Windows Forms, WPF와 일부 .NET 응용 프로그램을 웹 또는 네트워크 위치에서 간단하게 설치하고 자동 업데이트할 수 있도록 만든 배포 기술이다. 응용 프로그램과 배포 매니페스트를 사용하며 사용자별 설치와 버전 업데이트에 초점을 둔다.

AppX는 Windows 8과 UWP 응용 프로그램을 위해 도입된 패키지 형식이다. 패키지 매니페스트, 정체성, 디지털 서명, 선언된 기능과 일관된 설치·제거 구조를 사용한다.

MSIX는 AppX 계열을 확장하고 MSI, App-V와 ClickOnce에서 사용되던 기능을 결합한 현대 Windows 응용 프로그램 패키지 형식이다. Microsoft는 MSIX를 안정적인 설치와 깨끗한 제거, 자동 업데이트와 패키지 정체성을 제공하는 현대 Windows 패키징 형식으로 설명한다.^[113]

MSIX 패키지는 다음 특징을 가진다.

• 고유한 패키지 정체성
• 선언형 매니페스트
• 디지털 서명
• 블록 단위 파일 무결성
• 예측 가능한 설치 위치
• 깨끗한 제거
• 차등 업데이트
• 사용자별 또는 프로비저닝된 설치
• Microsoft Store 및 기업 배포
• 패키지 기반 파일·레지스트리 가상화
• Windows 알림과 확장 기능 연결

패키지 정체성은 게시자, 패키지 이름과 버전 등을 이용해 응용 프로그램을 고유하게 식별한다. 일부 Windows 기능은 패키지 정체성을 가진 응용 프로그램만 사용할 수 있다.

기존 Win32 데스크톱 프로그램도 MSIX로 패키징할 수 있다. MSIX Packaging Tool은 소스 코드가 없는 기존 설치 프로그램의 변경 동작을 추적하여 MSIX 패키지로 변환하는 기능을 제공한다.^[114]

MSIX 패키지를 사용하는 Win32 프로그램이 반드시 UWP 응용 프로그램이 되는 것은 아니다. 실행 모델과 API 접근 범위는 기존 데스크톱 프로그램으로 유지하면서 설치, 정체성과 업데이트만 MSIX를 사용할 수 있다.

Microsoft Store는 UWP뿐 아니라 Win32, PWA와 여러 패키지 형태의 응용 프로그램을 배포할 수 있다. Store는 검색, 라이선스, 업데이트, 서명과 사용자 계정 기반 설치를 제공하지만, Store 밖에서 MSIX나 전통적인 설치 프로그램을 직접 배포하는 것도 가능하다.

기업 환경에서는 Microsoft Intune, Configuration Manager, 그룹 정책, PowerShell과 패키지 관리 도구를 통해 응용 프로그램을 배포할 수 있다. Windows Package Manager는 명령줄에서 응용 프로그램 패키지를 검색하고 설치·업데이트하는 환경을 제공하며, 실제 설치에는 각 프로그램의 MSI, MSIX 또는 전용 설치 프로그램을 사용할 수 있다.

하위 호환성

Windows는 오래된 응용 프로그램을 새 운영체제에서 계속 실행하기 위해 광범위한 하위 호환성을 제공한다. 이 호환성은 하나의 에뮬레이터가 모든 차이를 처리하는 방식이 아니라, 안정적인 API 유지, 레거시 구성 요소, 리디렉션, 응용 프로그램별 수정과 프로세서 아키텍처 변환을 조합하여 구현된다.

Windows의 하위 호환성은 다음 계층에서 제공된다.

• 오래된 Windows API 유지
• 이전 파일 형식과 실행 파일 로더
• 기존 COM 인터페이스와 클래스 유지
• 32비트 응용 프로그램 실행 환경
• 파일 시스템과 레지스트리 리디렉션
• 응용 프로그램 호환성 데이터베이스
• 호환성 수정 또는 shim
• 버전 확인 동작 조정
• 관리자 권한 및 쓰기 가상화
• DirectX와 미디어 런타임의 이전 구성 요소
• 이전 .NET Framework 버전
• 응용 프로그램별 호환성 모드

Microsoft는 새 Windows가 이전 Windows용 응용 프로그램과 높은 호환성을 유지하는 것을 목표로 하지만, 보안 강화와 시스템 신뢰성 변화 때문에 일부 호환성 중단은 발생할 수 있다고 설명한다.^[115]

Windows의 응용 프로그램 호환성 데이터베이스는 알려진 프로그램과 호환성 문제, 적용할 수정 정보를 저장한다. 데이터베이스는 .sdb 형식을 사용하며, 실행 파일 이름, 버전, 해시와 파일 특성 등을 이용해 프로그램을 식별할 수 있다.^[116]

Shim은 프로그램과 Windows API 사이에 개입해 특정 함수의 결과나 동작을 변경하는 작은 호환성 계층이다. 예를 들어 응용 프로그램이 오래된 Windows 버전 번호를 요구하거나, 보호된 시스템 위치에 파일을 쓰려고 하거나, 이전의 창 동작을 기대할 때 제한적인 수정이 적용될 수 있다.

하나의 호환성 모드는 여러 shim과 플래그의 묶음으로 구성될 수 있다. 사용자가 실행 파일 속성에서 이전 Windows 버전 호환 모드를 선택하면 운영체제는 해당 프로그램에 맞는 호환성 설정을 적용한다.

응용 프로그램 매니페스트는 프로그램이 어떤 Windows 버전과 권한 모델을 대상으로 만들어졌는지 알린다. 매니페스트의 호환성 정보가 없으면 Windows는 오래된 프로그램으로 추정하여 일부 레거시 동작을 제공할 수 있다. Microsoft는 실행 파일 매니페스트의 호환성 섹션이 프로그램이 대상으로 한 Windows 버전을 판단하는 데 사용된다고 설명한다.^[117]

Windows Vista에서 사용자 계정 컨트롤이 도입된 뒤, 관리자 권한 없이 실행되는 오래된 프로그램이 보호된 Program Files나 시스템 레지스트리 위치에 쓰려고 하면 사용자별 가상 위치로 리디렉션하는 기능이 사용되었다. 이 기능은 매니페스트가 없는 일부 32비트 레거시 프로그램을 위한 호환성 보조 수단이며 현대 응용 프로그램 설계 방식으로 권장되지는 않는다.

파일 경로, 문자 인코딩과 화면 배율도 호환성 문제를 일으킬 수 있다. Windows는 ANSI 코드 페이지 API와 Unicode API를 함께 유지하고, DPI 인식 정보가 없는 응용 프로그램의 창을 확대하여 표시하는 DPI 가상화를 제공할 수 있다.

오래된 DirectDraw, DirectSound, DirectInput과 Direct3D 응용 프로그램을 위해 이전 DirectX 인터페이스가 상당 부분 유지된다. 그러나 제거된 하드웨어 기능, 16비트 구성 요소, 커널 드라이버, 복사 방지 기술과 특정 미디어 코덱에 의존하는 프로그램은 별도 패치나 가상 머신이 필요할 수 있다.

호환성은 프로그램의 실행 가능성과 완전한 동작을 구분해야 한다. 프로그램이 시작되더라도 보안 기능, 온라인 서비스, 외부 장치, 플러그인이나 라이선스 서버가 더 이상 지원되지 않으면 원래 기능을 모두 사용할 수 없을 수 있다.

Windows on Windows

Windows on Windows는 다른 Windows 아키텍처나 실행 환경을 대상으로 만들어진 응용 프로그램을 현재 Windows에서 실행하기 위한 호환성 계층을 가리킨다. 현대 Windows에서는 주로 WOW64가 사용되며, 과거에는 16비트 Windows 응용 프로그램을 실행하는 WOW와 NTVDM도 존재했다.

WOW64는 64비트 Windows에서 32비트 Windows 응용 프로그램을 실행하는 환경이다. 이름은 Windows 32-bit on Windows 64-bit에서 유래한다.

Microsoft는 WOW64를 32비트 Windows 응용 프로그램이 64비트 Windows에서 실행될 수 있게 하는 x86 호환 환경으로 설명한다.^[118]

x64 Windows에서 WOW64는 사용자 모드에서 32비트 응용 프로그램의 시스템 호출을 64비트 커널 인터페이스로 연결한다. 32비트 프로그램은 자체 32비트 ntdll.dll과 시스템 DLL을 사용하며, WOW64 구성 요소가 호출과 자료 구조를 변환한다.

Microsoft의 구현 문서는 WOW64 에뮬레이터가 사용자 모드에서 실행되며 32비트 ntdll.dll과 커널 사이의 인터페이스를 제공하고 커널 호출을 가로챈다고 설명한다.^[119]

x64 Windows의 응용 프로그램 실행 구조

• 64비트 Windows 커널
  • 64비트 응용 프로그램
    • 64비트 시스템 DLL
  • WOW64
    • 32비트 응용 프로그램
      • 32비트 시스템 DLL
      • 시스템 호출 변환
      • 파일 시스템 리디렉션
      • 레지스트리 보기 분리

32비트와 64비트 프로세스는 서로 다른 주소 공간과 DLL 형식을 사용한다. 32비트 프로세스는 64비트 DLL을 직접 적재할 수 없고, 64비트 프로세스도 32비트 DLL을 직접 적재할 수 없다. 서로 통신하려면 별도 프로세스, RPC, COM, 파이프, 소켓이나 다른 프로세스 간 통신 수단을 사용한다.

WOW64는 시스템 디렉터리 접근을 리디렉션한다. 64비트 시스템 파일과 32비트 시스템 파일이 같은 이름을 가질 수 있기 때문에 논리적 경로와 실제 디렉터리 이름이 다르게 처리될 수 있다.

일반적으로 다음 디렉터리가 사용된다.

• System32에는 64비트 시스템 구성 요소가 저장된다.
• SysWOW64에는 32비트 시스템 구성 요소가 저장된다.
• 특정 상황에서는 Sysnative 별칭으로 32비트 프로세스가 실제 64비트 시스템 디렉터리에 접근할 수 있다.

이 명칭은 역사적 호환성 때문에 직관과 반대로 보일 수 있다. 기존 프로그램이 System32 경로를 하드코딩한 상태에서도 계속 작동하도록 64비트 시스템 디렉터리 이름을 유지한 결과다.

레지스트리의 일부 영역도 32비트와 64비트 보기를 구분한다. 응용 프로그램 등록, COM 클래스와 소프트웨어 설정이 아키텍처별로 다른 경우 WOW64가 적절한 보기를 제공한다.

ARM64 Windows에서는 네이티브 ARM64 응용 프로그램 외에 ARM32, x86과 지원되는 환경의 x64 응용 프로그램을 실행하기 위한 변환 및 에뮬레이션 계층이 사용된다. 각 형식의 지원 여부와 구현은 Windows 버전과 장치에 따라 달라진다.

초기 32비트 Windows와 32비트 Windows NT에서는 16비트 Windows 프로그램을 실행하기 위한 WOW 환경이 사용되었다. Windows NT 계열의 NTVDM은 16비트 DOS와 Windows 프로그램을 가상 8086 모드 또는 에뮬레이션 환경에서 실행했다.

64비트 Windows에는 일반적인 NTVDM이 포함되지 않기 때문에 16비트 Windows 및 DOS 프로그램은 직접 실행할 수 없다. 이러한 프로그램에는 DOSBox, 별도 에뮬레이터, 32비트 Windows 가상 머신이나 원래 하드웨어 환경이 사용될 수 있다.

WOW64는 32비트 프로그램을 가상 머신 안의 별도 Windows에서 실행하는 것이 아니다. 같은 Windows 커널과 사용자 세션 위에서 프로세스를 실행하며, 필요한 호출과 자원 보기를 변환한다. 따라서 가상 머신보다 시스템 통합과 실행 비용이 낮지만, 제거된 API나 오래된 드라이버까지 모두 복원하지는 않는다.

Linux 응용 프로그램 지원

Windows는 Windows Subsystem for Linux 또는 WSL을 통해 GNU/Linux 사용자 공간과 Linux 응용 프로그램을 Windows 안에서 실행할 수 있다. WSL은 전통적인 Windows API 프로그램을 Linux 프로그램으로 변환하는 일반 호환 계층이 아니라, Linux 배포판과 실행 환경을 제공하는 하위 시스템이다.

Microsoft는 WSL을 전통적인 가상 머신이나 이중 부팅의 관리 부담 없이 Windows에서 수정되지 않은 GNU/Linux 환경과 대부분의 명령줄 도구, 유틸리티와 응용 프로그램을 실행할 수 있게 하는 기능으로 설명한다.^[120]

WSL에서는 여러 Linux 배포판을 설치할 수 있다. 각 배포판은 독립된 사용자 공간, 패키지 관리자, 사용자 계정과 파일 시스템을 가지며, 동일한 Windows 사용자 계정에서 여러 배포판을 함께 사용할 수 있다.

일반적으로 다음과 같은 Linux 구성 요소를 사용할 수 있다.

• Bash와 다른 셸
• GNU 명령줄 도구
• Linux 패키지 관리자
• 컴파일러와 빌드 도구
• Git와 SSH
• Python, Ruby, Node.js와 여러 런타임
• 데이터베이스와 웹 서버
• 컨테이너 개발 도구
• Linux GUI 응용 프로그램
• GPU 계산 작업
• systemd 기반 서비스

WSL에는 서로 다른 구조를 사용하는 WSL 1과 WSL 2가 있다.

WSL 1은 Linux 시스템 호출을 Windows NT 커널 동작으로 변환하는 방식으로 구현되었다. 별도의 Linux 커널을 실행하지 않으며 Windows 파일 시스템과의 접근이 빠르고 메모리 사용이 비교적 작을 수 있다. 그러나 모든 Linux 커널 기능과 시스템 호출을 완전하게 제공하지는 않는다.

WSL 2는 경량 관리 가상 머신 안에서 실제 Linux 커널을 실행한다. Microsoft가 유지하는 Linux 커널을 사용하며, WSL 1보다 높은 시스템 호출 호환성과 Linux 파일 시스템 성능을 제공한다.

Microsoft는 WSL 2가 관리되는 가상 머신 안에서 실제 Linux 커널을 사용하고, WSL 1보다 완전한 시스템 호출 호환성과 향상된 Linux 파일 시스템 성능을 제공한다고 설명한다.^[121]

WSL 1과 WSL 2의 실행 구조

• Windows
  • WSL 1 배포판
    • Linux 사용자 공간
    • Linux 시스템 호출을 Windows 커널 동작으로 변환
  • WSL 2 배포판
    • Linux 사용자 공간
    • 실제 Linux 커널
    • 경량 관리 가상 머신

WSL 2가 실제 Linux 커널을 사용하더라도 일반적인 Hyper-V 가상 머신처럼 사용자가 가상 하드웨어와 운영체제 설치를 직접 관리할 필요는 없다. Windows가 가상 머신의 시작, 종료, 메모리와 네트워크 통합을 관리한다.

WSL 1과 WSL 2는 배포판별로 선택할 수 있다. 같은 컴퓨터에서 한 배포판은 WSL 1, 다른 배포판은 WSL 2로 실행할 수 있으며 변환 명령으로 버전을 변경할 수 있다.^[122]

Windows와 WSL은 파일 시스템을 서로 접근할 수 있다. Linux에서는 /mnt/c 같은 경로로 Windows 드라이브에 접근할 수 있고, Windows에서는 \\wsl$ 또는 WSL 파일 시스템 통합 경로를 통해 Linux 배포판의 파일에 접근할 수 있다.

성능과 파일 메타데이터 특성은 파일이 저장된 위치에 따라 달라진다. Linux 도구가 많은 작은 파일을 반복 처리하는 프로젝트는 일반적으로 WSL 2의 Linux 파일 시스템에 저장하는 편이 적합하고, Windows 응용 프로그램과 자주 공유해야 하는 파일은 Windows 파일 시스템에 둘 수 있다.

WSL은 Windows 프로세스와 Linux 프로세스 사이의 명령 실행을 지원한다. Linux 셸에서 Windows 실행 파일을 호출하거나 Windows 명령줄에서 wsl 명령을 사용해 Linux 프로그램을 실행할 수 있다. 경로, 환경 변수와 표준 입출력도 일정 범위에서 연결된다.

WSLg는 WSL 2에서 Linux GUI 응용 프로그램을 Windows 데스크톱 창처럼 실행할 수 있게 한다. 그래픽, 오디오, 클립보드와 입력 통합을 제공하며 Linux 응용 프로그램 창을 Windows 작업 표시줄과 시작 메뉴에 표시할 수 있다.

GPU 지원은 Linux 응용 프로그램이 Windows 그래픽 드라이버와 가상화 인터페이스를 통해 GPU 계산 기능을 사용할 수 있게 한다. 기계 학습, 과학 계산과 일부 그래픽 작업에 활용된다.

WSL은 Linux 커널 모듈과 물리 장치에 대한 완전한 직접 접근을 항상 제공하지 않는다. USB, 네트워크, 파일 시스템, 커널 보안 모듈과 저수준 가상화 기능은 Windows와 WSL 버전의 지원 범위에 따라 제한되거나 별도 연결 절차가 필요할 수 있다.

WSL 2는 실제 Linux 커널을 사용하므로 Docker와 여러 Linux 컨테이너 도구의 기반으로 사용할 수 있다. 다만 WSL 자체가 Windows 컨테이너와 동일한 기술은 아니며, Linux 컨테이너는 Linux 커널을 공유하고 Windows 컨테이너는 Windows 커널 인터페이스를 사용한다.

WSL의 목적은 Linux 응용 프로그램을 Windows 응용 프로그램 형식으로 바꾸는 것이 아니라 두 환경을 같은 개발 컴퓨터에서 긴밀하게 연결하는 것이다. 사용자는 Windows의 데스크톱, 편집기와 브라우저를 사용하면서 빌드, 서버 실행과 배포 도구는 Linux 환경에서 실행할 수 있다.

Windows는 한 대의 개인용 컴퓨터부터 수많은 클라이언트와 서버로 구성된 기업 네트워크까지 관리할 수 있는 계정, 정책, 서비스와 장치 관리 체계를 제공한다.

개별 컴퓨터에서는 로컬 사용자 계정, 설정 앱, 제어판, 작업 관리자, 장치 관리자와 PowerShell을 이용해 시스템을 관리한다. 조직 환경에서는 Active Directory Domain Services, 그룹 정책, Microsoft Entra ID, 모바일 장치 관리와 배포 도구를 이용해 여러 컴퓨터의 사용자, 보안 정책, 응용 프로그램과 업데이트를 중앙에서 관리한다.

Windows의 관리 정보는 하나의 파일이나 데이터베이스에 집중되어 있지 않다. 사용자와 장치 정보는 로컬 보안 데이터베이스나 디렉터리 서비스에 저장되고, 운영체제와 응용 프로그램 설정은 레지스트리와 구성 파일에 분산된다. 서비스 제어 관리자, 플러그 앤 플레이 관리자, Windows Update와 복구 환경은 각각 실행 중인 서비스, 장치, 운영체제 구성 요소와 장애 복구를 담당한다.

Windows 시스템 관리의 주요 범위

• 개별 컴퓨터 관리
  • 로컬 사용자와 그룹
  • 설정과 제어판
  • 레지스트리
  • 서비스
  • 장치 관리자
  • 로컬 그룹 정책
  • Windows Update
  • Windows 복구 환경
• 조직 단위 관리
  • Active Directory Domain Services
  • 그룹 정책
  • Microsoft Entra ID
  • Microsoft Intune
  • Windows Autopilot
  • Configuration Manager
  • Windows Server Update Services
  • 원격 PowerShell과 관리 도구

사용자 계정

Windows 사용자 계정은 사용자를 식별하고 해당 사용자의 보안 권한, 프로필, 파일, 설정과 응용 프로그램 환경을 구분한다. 사용자가 로그인하면 Windows는 계정의 자격 증명을 확인하고, 사용자와 그룹 정보가 포함된 액세스 토큰을 만든 뒤 사용자 세션과 프로필을 시작한다.

Windows에서 사용되는 주요 계정 유형은 다음과 같다.

• 로컬 계정
• Microsoft 계정
• Active Directory 도메인 계정
• Microsoft Entra ID 계정
• 서비스 계정
• 기본 제공 시스템 계정
• 관리 서비스 계정

로컬 계정은 특정 컴퓨터의 로컬 보안 데이터베이스에 저장된다. 해당 컴퓨터에서만 직접 인증되며, 다른 컴퓨터에 같은 이름과 암호의 계정이 존재하더라도 별개의 보안 주체로 취급된다.

로컬 계정 정보는 일반적으로 보안 계정 관리자 또는 SAM 데이터베이스에서 관리된다. 각 계정과 그룹에는 이름과 별도로 고유한 보안 식별자 또는 SID가 부여된다. Windows의 접근 제어 목록은 표시 이름보다 SID를 이용해 사용자를 식별한다.

Microsoft 계정은 Microsoft가 운영하는 온라인 소비자 계정이다. Windows에 Microsoft 계정으로 로그인하면 사용자 설정, Microsoft Store, OneDrive와 여러 Microsoft 서비스가 계정에 연결될 수 있다. Windows 내부에서는 온라인 계정과 연결된 로컬 사용자 프로필이 만들어진다.

Active Directory 도메인 계정은 조직의 도메인 컨트롤러가 관리한다. 사용자는 같은 도메인 또는 신뢰 관계가 설정된 환경의 여러 컴퓨터에서 동일한 계정으로 인증할 수 있다. 계정과 그룹, 컴퓨터, 정책 정보는 Active Directory에 저장된다.

Microsoft Entra ID 계정은 클라우드 기반 조직 계정이다. Microsoft Entra에 가입된 Windows 장치는 조직 계정을 기본 로그인 계정으로 사용할 수 있으며, Microsoft 365, Azure와 조직의 클라우드 응용 프로그램에 통합 인증을 제공한다.

Microsoft Entra에 등록된 장치와 가입된 장치는 다르다. 등록된 장치는 로컬 계정이나 Microsoft 계정으로 Windows에 로그인하면서 조직 계정을 업무 리소스 접근에 연결할 수 있다. 가입된 장치는 Microsoft Entra 계정을 Windows의 기본 조직 로그인과 장치 정체성에 사용한다.^[123][124]

Windows의 계정은 권한 수준에 따라 일반 사용자와 관리자로 구분될 수 있다.

• 표준 사용자는 자신의 파일과 사용자별 설정을 관리하고 허용된 응용 프로그램을 실행할 수 있다.
• 관리자는 시스템 전체 설정, 다른 사용자, 서비스, 드라이버와 보호된 파일을 변경할 수 있다.
• 게스트 및 제한 계정은 버전과 환경에 따라 제한된 임시 접근에 사용될 수 있다.

관리자 그룹의 구성원이더라도 대화형 프로그램은 일반적으로 제한된 권한의 토큰으로 실행된다. 시스템 수준 변경이 필요하면 사용자 계정 컨트롤이 권한 상승을 요청하고, 승인된 프로세스에 관리자 권한 토큰을 제공한다.

Windows에는 여러 기본 제공 계정이 있다.

기본 제공 Administrator 계정은 일반적인 사용자 관리자 계정과 구분되는 고정 SID를 가진다. 현대 Windows에서는 보안을 위해 기본적으로 비활성화되거나 설치 과정에서 생성한 다른 관리자 계정이 사용되는 경우가 많다.

서비스 계정은 사람이 대화형으로 사용하는 계정보다 백그라운드 서비스와 자동화 작업을 실행하기 위한 계정이다. 로컬 서비스와 네트워크 서비스 같은 기본 계정, 도메인 사용자 계정, 가상 계정과 관리 서비스 계정을 사용할 수 있다.

Active Directory의 그룹 관리 서비스 계정은 여러 서버에서 실행되는 서비스의 암호를 도메인이 자동으로 관리하도록 한다. 관리자가 서비스 암호를 직접 주기적으로 변경하지 않아도 되며, 여러 호스트가 같은 관리 서비스 계정을 사용할 수 있다.

사용자 프로필은 계정별 데스크톱, 문서, 응용 프로그램 데이터와 레지스트리 설정을 저장한다. 일반적으로 사용자 디렉터리는 C:\Users 아래에 위치하며, 사용자별 레지스트리 하이브는 프로필 안의 파일에서 적재된다.

프로필에는 다음과 같은 데이터가 포함될 수 있다.

• 바탕 화면과 사용자 문서
• 다운로드와 사진
• 응용 프로그램 설정
• 시작 메뉴와 바로 가기
• 사용자별 인증서
• 사용자 레지스트리 설정
• 브라우저와 응용 프로그램 데이터
• 클라우드 동기화 정보

도메인 환경에서는 로밍 사용자 프로필, 폴더 리디렉션과 OneDrive 알려진 폴더 이동을 이용해 사용자 데이터를 중앙 저장소나 클라우드에 배치할 수 있다.

Windows Hello는 암호 대신 PIN, 지문, 얼굴 인식과 보안 키를 사용해 로그인할 수 있게 한다. Windows Hello PIN은 일반적인 온라인 계정 암호와 달리 장치에 연결되며, TPM과 결합해 자격 증명을 보호할 수 있다.

레지스트리

Windows 레지스트리는 운영체제, 사용자, 서비스, 장치와 응용 프로그램의 구성 정보를 저장하는 계층형 데이터베이스다. 초기 Windows에서는 여러 INI 파일에 설정을 저장했지만, Windows 3.x와 Windows NT 계열을 거치며 중앙화된 레지스트리 구조가 확대되었다.

레지스트리는 파일 시스템과 유사한 계층을 사용한다.

• 키는 디렉터리와 유사한 컨테이너다.
• 하위 키는 키 아래의 계층을 만든다.
• 값은 이름, 자료형과 데이터를 가진 설정 항목이다.

레지스트리의 주요 루트 키는 다음과 같다.

HKEY_CURRENT_USER는 독립된 물리 데이터베이스라기보다 현재 사용자의 HKEY_USERS 하위 키를 가리키는 논리적 보기다. HKEY_CLASSES_ROOT도 컴퓨터 전체와 사용자별 클래스 등록을 병합하여 제공한다.

레지스트리는 여러 하이브로 나뉘어 디스크 파일에 저장된다. 시스템 하이브에는 SYSTEM, SOFTWARE, SAM, SECURITY와 DEFAULT 등이 있으며, 부팅 과정에서 커널과 구성 관리자가 이를 적재한다.

사용자별 레지스트리는 일반적으로 사용자 프로필의 NTUSER.DAT와 관련 파일에 저장된다. 사용자가 로그인하면 해당 하이브가 HKEY_USERS 아래에 적재되고 HKEY_CURRENT_USER로 연결된다.

레지스트리 값은 여러 자료형을 사용할 수 있다.

• 문자열
• 확장 가능한 문자열
• 여러 문자열
• 32비트 정수
• 64비트 정수
• 이진 데이터
• 자원 목록과 장치 정보

레지스트리는 다음과 같은 용도로 사용된다.

• 서비스와 드라이버 시작 설정
• 설치된 응용 프로그램 정보
• 파일 형식 연결
• COM 클래스 등록
• 사용자 인터페이스 설정
• 장치 구성
• 네트워크와 보안 설정
• 그룹 정책 적용 결과
• 운영체제 기능과 구성 요소 상태

레지스트리 설정은 regedit.exe, 명령줄의 reg.exe, PowerShell 레지스트리 공급자, Windows API와 관리 도구를 통해 읽고 변경할 수 있다.

PowerShell은 레지스트리 키를 파일 시스템 경로와 비슷하게 다룰 수 있다. HKLM:과 HKCU: 드라이브를 통해 키를 탐색하고 값을 생성하거나 수정한다.

레지스트리는 시스템 작동에 직접 영향을 주므로 잘못된 변경은 응용 프로그램 오류, 서비스 시작 실패와 부팅 문제를 일으킬 수 있다. 설정을 변경할 때에는 관련 응용 프로그램이나 관리 인터페이스를 우선 사용하고, 직접 수정해야 할 경우 대상 키와 데이터 형식을 확인해야 한다.

레지스트리는 모든 Windows 설정을 저장하지 않는다. 현대 응용 프로그램은 XML, JSON, SQLite와 자체 데이터베이스를 사용할 수 있고, 그룹 정책은 파일과 Active Directory에도 저장된다. 장치와 보안 정보도 여러 전용 데이터베이스와 시스템 파일에 분산된다.

64비트 Windows에서는 일부 소프트웨어와 COM 등록 영역에 32비트와 64비트 레지스트리 보기가 존재한다. WOW64는 프로그램의 아키텍처에 따라 적절한 보기를 제공하며, 관리 API를 사용하면 원하는 보기를 명시적으로 열 수 있다.

서비스 관리

Windows 서비스는 사용자와 직접 상호 작용하지 않고 백그라운드에서 장기간 실행되는 프로그램이다. 서비스는 사용자가 로그인하기 전부터 시작될 수 있고, 사용자가 로그오프한 뒤에도 계속 실행될 수 있다.

서비스는 네트워크, 업데이트, 인쇄, 보안, 원격 관리, 데이터베이스와 응용 프로그램 서버 같은 기능을 제공한다.

서비스의 등록과 수명 주기는 서비스 제어 관리자 또는 SCM이 관리한다. SCM은 부팅 과정에서 시작되고, 설치된 서비스의 정보와 상태를 유지하며, 서비스 시작·중지 요청을 전달한다.

서비스 구성에는 다음 정보가 포함된다.

• 서비스 이름과 표시 이름
• 실행 파일 경로
• 시작 유형
• 실행 계정
• 종속 서비스
• 오류 복구 동작
• 서비스 권한
• 설명과 그룹
• 트리거 시작 조건

서비스의 주요 시작 유형은 다음과 같다.

서비스 프로그램은 SCM에 서비스 제어 처리기를 등록하고 시작, 중지, 일시 중지, 계속과 시스템 종료 요청에 대응한다. 시작 중, 실행 중, 중지 중과 중지됨 같은 상태를 SCM에 보고한다.

여러 Windows 서비스는 svchost.exe 서비스 호스트 프로세스 안에서 실행된다. 서비스 구현 DLL을 공통 호스트 프로세스에 적재하면 프로세스 수와 메모리 사용을 줄일 수 있다.

과거에는 여러 서비스가 한 서비스 호스트를 공유하는 경우가 많았지만, 현대 Windows는 메모리가 충분한 시스템에서 서비스를 더 많은 독립 프로세스로 분리한다. 이는 한 서비스의 충돌이나 메모리 손상이 다른 서비스에 미치는 영향을 줄이고 작업 관리자에서 자원 사용량을 구분하기 쉽게 한다.

서비스는 다음 도구로 관리할 수 있다.

• 서비스 관리 콘솔
• 작업 관리자
• sc.exe
• PowerShell 서비스 cmdlet
• Windows Management Instrumentation
• 그룹 정책
• 서버 관리자와 원격 관리 도구

서비스 관리 콘솔은 서비스 상태, 시작 유형, 실행 계정과 복구 설정을 보여준다. PowerShell의 Get-Service, Start-Service, Stop-Service와 Set-Service 등을 사용하면 여러 컴퓨터의 서비스를 자동으로 관리할 수 있다.

서비스가 사용할 계정은 필요한 최소 권한을 기준으로 선택한다. 모든 서비스가 LocalSystem으로 실행되면 시스템 전체 권한이 불필요하게 확대된다. 제한된 기본 계정, 가상 계정, 관리 서비스 계정이나 전용 사용자 계정을 사용할 수 있다.

서비스에는 보안 설명자가 있어 시작, 중지, 설정 변경과 삭제 권한을 사용자와 그룹별로 제한한다. 서비스 실행 파일과 로드하는 DLL의 파일 권한도 보호되어야 한다.

서비스가 반복적으로 실패할 경우 SCM은 다음과 같은 복구 동작을 수행할 수 있다.

• 서비스 다시 시작
• 지정한 프로그램 실행
• 컴퓨터 다시 시작
• 후속 실패에서는 다른 동작 적용

서비스는 사용자 세션과 분리된 세션 0에서 실행된다. Windows Vista 이후 서비스가 사용자 바탕 화면에 직접 창을 표시하는 방식은 제한되었으며, 대화형 인터페이스가 필요하면 사용자 세션의 별도 응용 프로그램과 프로세스 간 통신을 사용한다.

그룹 정책

그룹 정책은 Windows 컴퓨터와 사용자 설정을 중앙 또는 로컬에서 관리하는 정책 기반 구성 체계다. 운영체제 설정, 보안 규칙, 응용 프로그램, 스크립트, 방화벽과 사용자 환경을 일관되게 적용할 수 있다.

그룹 정책은 개별 컴퓨터에서 로컬 정책으로 사용할 수 있고, Active Directory 환경에서는 여러 컴퓨터와 사용자에게 중앙에서 배포할 수 있다. Microsoft는 그룹 정책을 운영체제, 응용 프로그램과 사용자 설정의 중앙 관리 및 구성을 제공하는 Windows 기능으로 정의한다.^[125]

그룹 정책 설정은 그룹 정책 객체 또는 GPO에 저장된다. GPO에는 컴퓨터 구성과 사용자 구성이 구분되어 있다.

• 컴퓨터 구성은 컴퓨터가 시작될 때와 주기적 갱신 시 적용된다.
• 사용자 구성은 사용자가 로그인할 때와 주기적 갱신 시 적용된다.

GPO는 Active Directory의 다음 범위에 연결할 수 있다.

• 사이트
• 도메인
• 조직 단위

로컬 컴퓨터에는 Active Directory와 무관한 로컬 그룹 정책 객체가 존재한다. 도메인에 가입된 컴퓨터에서는 로컬 정책과 도메인 정책이 함께 적용될 수 있다.

그룹 정책의 기본 처리 순서는 일반적으로 다음과 같다.

그룹 정책의 기본 적용 순서

1. 로컬 그룹 정책
   ↓
2. Active Directory 사이트에 연결된 GPO
   ↓
3. 도메인에 연결된 GPO
   ↓
4. 상위 조직 단위의 GPO
   ↓
5. 하위 조직 단위의 GPO
   ↓
6. 상속, 우선순위와 필터를 계산하여 최종 설정 적용

뒤에 처리된 설정이 같은 항목의 앞선 설정을 덮어쓸 수 있지만, 상속 차단, 강제 적용, 보안 필터와 정책 자체의 동작에 따라 결과가 달라진다.

GPO는 Active Directory와 SYSVOL 양쪽에 정보를 저장한다. Active Directory에는 GPO의 식별자, 버전과 연결 정보가 저장되고, 도메인 컨트롤러의 SYSVOL에는 관리 템플릿, 스크립트와 파일 기반 정책 데이터가 저장된다.

그룹 정책으로 관리할 수 있는 주요 영역은 다음과 같다.

• 암호와 계정 잠금 정책
• 사용자 권한 할당
• 감사와 보안 옵션
• Windows Defender와 방화벽
• BitLocker
• Windows Update
• 응용 프로그램 제한
• 브라우저와 Office 설정
• 시작 및 로그온 스크립트
• 드라이브와 프린터 연결
• 파일과 레지스트리 설정
• 장치 설치 제한
• 데스크톱과 시작 메뉴
• 원격 데스크톱
• 서비스와 예약 작업

관리 템플릿은 레지스트리 기반 정책 설정을 정의한다. ADMX 파일에는 정책 항목과 해당 레지스트리 위치가 기술되고, ADML 파일은 언어별 표시 문자열을 제공한다.

조직은 도메인의 중앙 저장소에 ADMX·ADML 파일을 배치하여 관리자가 같은 정책 정의를 사용하도록 할 수 있다.

그룹 정책 기본 설정은 반드시 강제되는 정책뿐 아니라 초기 설정과 편의 구성을 배포하는 데 사용된다. 파일, 디렉터리, 레지스트리, 드라이브 매핑, 프린터, 로컬 사용자와 예약 작업 등을 만들거나 수정할 수 있다.

기본 설정은 사용자가 나중에 변경할 수 있는 값을 배포할 수 있다는 점에서 일반 정책과 다르다. 다만 설정에 따라 다시 적용하거나 사용자의 변경을 덮어쓰도록 구성할 수도 있다.

GPO는 보안 그룹을 이용해 적용 대상을 필터링할 수 있으며, WMI 필터로 운영체제 버전, 하드웨어와 시스템 속성을 기준으로 적용 여부를 결정할 수 있다.

그룹 정책 결과는 gpresult, Resultant Set of Policy와 그룹 정책 관리 콘솔을 이용해 확인한다. gpupdate는 정책 갱신을 요청하며, 일부 정책은 로그오프나 다시 시작 뒤에 완전히 적용된다.

Microsoft Entra ID에만 가입된 장치는 전통적인 Active Directory 그룹 정책보다 모바일 장치 관리 정책과 구성 서비스 공급자를 중심으로 관리한다. 일부 설정은 그룹 정책과 MDM에서 모두 제공되지만 저장과 적용 체계는 서로 다르다.

도메인과 Active Directory

도메인은 사용자, 컴퓨터와 네트워크 자원을 공통된 디렉터리와 보안 정책 아래 관리하는 논리적 관리 영역이다. Windows Server의 Active Directory Domain Services 또는 AD DS가 도메인 계정, 컴퓨터, 그룹, 조직 단위와 정책 정보를 저장하고 인증 서비스를 제공한다.

Microsoft는 AD DS를 네트워크 객체에 관한 디렉터리 데이터를 저장하고, 허가된 사용자와 관리자가 해당 데이터를 사용할 수 있도록 하는 디렉터리 서비스로 정의한다.^[126]

Active Directory가 관리하는 주요 객체는 다음과 같다.

• 사용자
• 컴퓨터
• 보안 및 배포 그룹
• 연락처
• 프린터
• 공유 디렉터리
• 조직 단위
• 그룹 정책 객체
• 서비스 계정
• 도메인 컨트롤러
• 사이트와 서브넷

Active Directory의 데이터는 도메인 컨트롤러에 저장된다. 도메인 컨트롤러는 사용자 인증, 디렉터리 검색, 그룹 정책과 도메인 복제를 제공하는 Windows Server다.

하나의 도메인에는 여러 도메인 컨트롤러를 둘 수 있다. 대부분의 디렉터리 변경은 여러 도메인 컨트롤러에서 수행할 수 있고, 변경 사항은 복제를 통해 다른 컨트롤러로 전달된다.

도메인 로그인은 일반적으로 Kerberos를 기본 인증 프로토콜로 사용하며, 호환성이 필요한 상황에서는 NTLM이 사용될 수 있다. 클라이언트는 DNS를 통해 적절한 도메인 컨트롤러와 서비스를 찾는다.

도메인 사용자 로그인 흐름

1. 사용자가 도메인 계정으로 로그인 시도
   ↓
2. 클라이언트가 DNS로 도메인 컨트롤러 검색
   ↓
3. 도메인 컨트롤러가 자격 증명 확인
   ↓
4. 사용자와 그룹 정보를 기반으로 인증 티켓 발급
   ↓
5. 클라이언트가 사용자 액세스 토큰 생성
   ↓
6. 도메인 및 로컬 그룹 정책 적용
   ↓
7. 사용자 프로필과 데스크톱 세션 시작

Active Directory의 논리 구조는 도메인, 트리와 포리스트로 구성된다.

• 도메인은 공통 디렉터리 파티션과 DNS 이름을 사용하는 관리 영역이다.
• 트리는 연속된 DNS 이름 공간을 가진 하나 이상의 도메인으로 구성된다.
• 포리스트는 공통 스키마, 구성 정보와 전역 카탈로그를 공유하는 하나 이상의 도메인 트리다.

포리스트는 Active Directory의 주요 보안 경계다. 같은 포리스트의 도메인은 자동으로 전이적 신뢰 관계를 형성하며, 포리스트 사이에는 별도의 신뢰를 구성할 수 있다.

조직 단위 또는 OU는 도메인 안의 객체를 계층적으로 정리하고 관리 권한과 그룹 정책을 위임하는 컨테이너다. 조직 구조, 지역, 장치 유형과 관리 책임에 따라 사용자와 컴퓨터를 나눌 수 있다.

조직 단위는 보안 그룹을 대체하지 않는다. OU는 관리 위임과 정책 적용 범위에 사용되고, 보안 그룹은 리소스 접근 권한과 사용자 집합을 표현하는 데 사용된다.

Active Directory 사이트는 네트워크 연결 구조를 나타낸다. IP 서브넷을 사이트에 연결하여 클라이언트가 가까운 도메인 컨트롤러를 찾고, 사이트 사이의 복제 빈도와 경로를 조정할 수 있다.

전역 카탈로그는 포리스트의 모든 객체에 대한 일부 속성을 보유하여 포리스트 전체 검색과 범용 그룹 로그인을 지원한다.

Active Directory 스키마는 디렉터리에 저장할 수 있는 객체 클래스와 속성을 정의한다. Exchange Server와 일부 기업용 제품은 자체 객체와 속성을 추가하기 위해 스키마를 확장할 수 있다.

AD DS와 Microsoft Entra ID는 서로 다른 디렉터리 기술이다.

조직은 두 환경을 함께 사용하는 하이브리드 구성을 만들 수 있다. 온프레미스 Active Directory의 사용자와 그룹을 Microsoft Entra ID에 동기화하고, 도메인 가입과 Entra 등록 또는 하이브리드 가입을 결합한다.

장치 관리

Windows의 장치 관리는 한 컴퓨터의 하드웨어 상태를 확인하는 로컬 관리와 여러 컴퓨터의 구성·보안·응용 프로그램을 통제하는 조직 관리로 나뉜다.

장치 관리자는 컴퓨터에 설치된 장치와 드라이버를 계층적으로 표시하는 그래픽 관리 도구다. 사용자는 장치 상태, 하드웨어 ID, 드라이버 버전, 자원, 전원 관리와 오류 코드를 확인할 수 있다.

장치 관리자에서 수행할 수 있는 주요 작업은 다음과 같다.

• 장치 상태 확인
• 드라이버 업데이트
• 이전 드라이버로 롤백
• 장치 사용 또는 사용 안 함
• 장치 제거
• 하드웨어 변경 사항 검색
• 장치 속성과 이벤트 확인
• 숨겨진 장치 표시
• 드라이버 파일과 서명 확인

장치 관리자는 플러그 앤 플레이 관리자와 구성 관리자가 유지하는 장치 트리와 상태 정보를 표시한다. 장치에 문제가 있으면 문제 코드와 설명이 제공되며, 드라이버 누락, 시작 실패, 자원 충돌과 장치 분리 상태를 확인할 수 있다.

로컬 장치 관리는 다음 도구로도 수행할 수 있다.

• 설정 앱의 Bluetooth 및 장치
• 프린터 관리
• 디스크 관리
• 장치 및 프린터
• pnputil
• PowerShell PnPDevice cmdlet
• Windows Management Instrumentation
• Windows Driver Kit 도구

pnputil은 드라이버 저장소에 패키지를 추가하고, 장치를 열거하거나 드라이버를 설치·제거하는 명령줄 도구다.

조직 단위 장치 관리에는 다음 환경이 사용된다.

• Active Directory와 그룹 정책
• Microsoft Intune
• Configuration Manager
• Windows Autopilot
• Windows Update for Business
• Microsoft Defender for Endpoint
• 원격 PowerShell
• Windows Admin Center

Microsoft Intune은 클라우드 기반 엔드포인트 관리 서비스다. Windows뿐 아니라 다른 운영체제의 장치 등록, 구성, 보안 정책, 응용 프로그램과 규정 준수 상태를 관리한다.

Intune의 Windows 관리에는 MDM 프로토콜과 구성 서비스 공급자 또는 CSP가 사용된다. CSP는 정책, 인증서, VPN, Wi-Fi, 업데이트와 장치 기능을 읽거나 변경하는 관리 인터페이스다.

조직은 장치가 암호, 암호화, 운영체제 버전과 보안 설정 요구 사항을 충족하는지 규정 준수 정책으로 평가할 수 있다. 결과는 Microsoft Entra 조건부 액세스와 연결되어 규정을 준수하는 장치만 조직 리소스에 접근하도록 제한할 수 있다.

Windows Autopilot은 제조사나 공급업체가 등록한 장치를 조직의 사용자에게 직접 전달하고, 첫 부팅 과정에서 Microsoft Entra 가입, Intune 등록, 정책과 응용 프로그램 배포를 수행하도록 한다. 전통적인 사용자 정의 운영체제 이미지를 모든 장치에 직접 적용하는 방식의 일부를 대체한다.

Active Directory 그룹 정책과 Intune MDM은 함께 사용할 수 있다. 기존 도메인 가입 컴퓨터를 공동 관리하거나, 일부 정책을 그룹 정책에서 MDM으로 단계적으로 이전할 수 있다.

업데이트와 서비스 모델

Windows의 업데이트 체계는 보안 취약점 수정, 안정성 개선, 드라이버, 기능 추가와 새로운 Windows 버전 배포를 담당한다. 현대 Windows는 운영체제 출시 후 정기적인 누적 업데이트를 계속 제공하는 서비스 모델을 사용한다.

Windows 업데이트는 크게 다음 유형으로 구분된다.

• 월별 보안 업데이트
• 비보안 미리 보기 업데이트
• 대역 외 업데이트
• 기능 업데이트
• 드라이버와 펌웨어 업데이트
• Microsoft Defender 보안 인텔리전스
• .NET과 다른 Microsoft 구성 요소 업데이트
• Windows 복구 환경과 서비스 스택 업데이트

월별 보안 업데이트는 일반적으로 매월 두 번째 화요일에 배포된다. 보안 수정뿐 아니라 이전에 공개된 품질 개선을 포함하는 누적 패키지로 제공된다.

누적 업데이트는 최신 패키지에 이전 수정 사항이 포함되는 방식이다. 장치가 몇 달 동안 업데이트되지 않았더라도 각 달의 패키지를 모두 순서대로 설치하지 않고 최신 누적 업데이트를 적용해 필요한 수정 사항을 받을 수 있다.

비보안 미리 보기 업데이트는 다음 달 정기 누적 업데이트에 포함될 비보안 수정과 개선을 미리 제공한다. 조직과 사용자는 일반 배포 전에 변경 사항을 시험할 수 있다.

대역 외 업데이트는 정기 일정까지 기다리기 어려운 심각한 보안 문제나 광범위한 장애를 해결하기 위해 별도로 배포된다.

Microsoft의 Windows 메시지 센터는 월별 보안 업데이트, 비보안 미리 보기, 대역 외 업데이트와 새로운 기능이 서로 어떻게 결합되는지 설명하고 릴리스 상태와 알려진 문제를 제공한다.^[127]

기능 업데이트는 Windows의 새 버전과 기능 집합을 설치한다. Windows 11은 기본적으로 연간 기능 업데이트 주기를 사용하며, 각 버전에는 에디션별 지원 기간이 적용된다.

기능 업데이트는 기존 운영체제 위에 새 운영체제 이미지를 적용하는 인플레이스 업그레이드 방식으로 진행될 수 있다. 응용 프로그램, 파일과 설정을 유지하면서 시스템 구성 요소를 새 버전으로 교체한다.

Windows의 서비스는 다음 구성 요소가 협력한다.

• Windows Update 클라이언트
• 서비스 스택
• 구성 요소 기반 서비스
• Windows 이미지와 구성 요소 저장소
• 배포 이미지 서비스 및 관리
• 재시작과 보류 작업 처리
• 호환성 평가
• 업데이트 상태와 롤백 정보

서비스 스택은 Windows 업데이트를 설치하는 운영체제 구성 요소다. 서비스 스택 업데이트는 업데이트 설치 자체의 신뢰성과 호환성을 개선하며, 현대 누적 업데이트에는 서비스 스택 수정이 결합될 수 있다.

Windows의 구성 요소 저장소는 운영체제 기능, 업데이트와 복구에 필요한 구성 요소를 유지한다. DISM과 시스템 파일 검사기는 이 저장소를 이용해 손상된 시스템 구성 요소를 검사하고 복원할 수 있다.

업데이트가 적용되는 동안 Windows는 실행 중인 파일을 즉시 교체할 수 없는 경우 재시작 뒤 부팅 단계에서 작업을 완료한다. 재시작 요구를 줄이기 위해 일부 구성 요소와 서비스는 실행 중 갱신되거나 단계적으로 다시 시작될 수 있다.

업데이트 설치 뒤 문제가 발생하면 Windows는 일정 조건에서 이전 상태로 롤백할 수 있다. 기능 업데이트는 이전 Windows 설치를 제한된 기간 유지하여 이전 버전으로 돌아가는 기능을 제공할 수 있다.

Windows Update는 업데이트 전에 장치의 하드웨어, 드라이버, 응용 프로그램과 차단 조건을 평가한다. 알려진 호환성 문제가 있는 장치에는 보호 보류를 적용해 기능 업데이트 제공을 늦출 수 있다.

개인용 Windows에서는 설정 앱을 통해 업데이트 확인, 일시 중지, 활성 시간과 재시작 일정을 관리한다. 보안과 지원 상태를 유지하기 위해 일부 업데이트는 장기간 무기한 거부할 수 없도록 설계된다.

조직은 다음 수단으로 업데이트를 관리할 수 있다.

• Windows Update for Business
• Microsoft Intune
• 그룹 정책
• Windows Server Update Services
• Configuration Manager
• 배포 링
• 기능 및 품질 업데이트 정책
• 드라이버 업데이트 정책
• Autopatch

배포 링은 장치를 시험, 초기 배포와 광범위 배포 그룹으로 나누어 업데이트 시점과 지연 기간을 다르게 적용하는 방식이다. 문제가 발견되면 전체 조직에 확산되기 전에 배포를 중지할 수 있다.

Windows Server는 장기 서비스 채널과 일부 버전의 연간 채널을 사용한다. 서버 역할과 기업 응용 프로그램의 안정성을 고려하여 클라이언트 Windows와 다른 제품 수명 주기와 기능 배포 정책이 적용될 수 있다.

Windows 버전의 지원이 종료되면 일반적인 보안 업데이트와 기술 지원도 끝난다. 특정 기업과 장치는 확장 보안 업데이트 프로그램이나 LTSC·IoT 제품의 별도 수명 주기를 사용할 수 있다.

복구 환경

Windows는 부팅 실패, 손상된 시스템 파일, 잘못된 업데이트와 사용자 설정 문제를 복구하기 위한 여러 도구를 제공한다. 복구 기능은 실행 중인 Windows 안에서 사용할 수 있는 도구와 별도의 복구 운영체제에서 실행되는 도구로 나뉜다.

Windows Recovery Environment 또는 WinRE는 부팅할 수 없는 Windows를 진단하고 복구하기 위한 별도의 경량 운영 환경이다. Windows PE를 기반으로 하며, Windows 10·Windows 11과 현대 Windows Server 설치에 포함될 수 있다.

Microsoft는 WinRE를 부팅할 수 없는 운영체제의 일반적인 원인을 복구하기 위한 Windows PE 기반 복구 환경으로 정의한다.^[128]

WinRE는 다음 상황에서 시작할 수 있다.

• 부팅 실패가 반복되어 자동으로 진입
• Windows 설정 앱의 고급 시작
• Shift 키를 누른 채 다시 시작
• 복구 드라이브나 설치 미디어
• 부팅 메뉴의 복구 항목
• 관리자가 원격 또는 로컬로 복구 시작 요청

WinRE의 주요 도구는 다음과 같다.

• 시작 복구
• 업데이트 제거
• 시스템 복원
• 시스템 이미지 복구
• 시작 설정
• 안전 모드
• 명령 프롬프트
• UEFI 펌웨어 설정
• 이 PC 초기화
• 제조사 또는 관리자 추가 복구 도구

시작 복구는 부팅 구성 데이터, 시스템 파일, 디스크 메타데이터와 부팅에 필요한 구성 요소를 검사하여 자동으로 수정한다.

업데이트 제거는 최근 설치한 품질 업데이트나 기능 업데이트가 부팅 실패를 일으킨 경우 해당 업데이트를 제거한다.

시스템 복원은 복원 지점에 기록된 시스템 파일, 레지스트리, 드라이버와 설치 상태를 이전 시점으로 되돌린다. 일반 사용자 문서 전체를 백업하고 복원하는 기능은 아니다.

시스템 이미지 복구는 이전에 만든 전체 시스템 이미지에서 디스크와 운영체제를 복원한다. 기존 볼륨의 내용을 덮어쓸 수 있으므로 일반 파일 복구와는 구분된다.

안전 모드는 최소한의 드라이버와 서비스로 Windows를 시작하여 정상 부팅을 방해하는 드라이버, 서비스와 응용 프로그램을 진단한다.

이 PC 초기화는 Windows를 다시 설치하면서 사용자 파일 유지 여부를 선택할 수 있게 한다.

• 파일 유지는 개인 파일을 보존하면서 응용 프로그램과 대부분의 설정을 제거한다.
• 모두 제거는 사용자 파일, 응용 프로그램과 설정을 제거한다.
• 로컬 다시 설치는 장치의 기존 복구 구성 요소를 사용한다.
• 클라우드 다운로드는 Microsoft에서 새 Windows 이미지를 내려받는다.

초기화는 완전한 디스크 백업 복원과 동일하지 않다. 사용자 파일 유지 옵션도 모든 응용 프로그램 데이터와 사용자 정의 구성을 보장하지 않으므로 중요한 데이터는 별도로 백업해야 한다.

복구 드라이브는 USB 저장 장치에 Windows 복구 도구와 선택적인 시스템 파일을 저장한다. 내부 복구 파티션을 사용할 수 없을 때 부팅하여 문제 해결이나 Windows 재설치를 수행할 수 있다.

명령줄 복구에는 다음 도구가 사용된다.

• DISM
• sfc
• chkdsk
• bootrec
• bcdboot
• diskpart
• reagentc

DISM은 Windows 이미지와 구성 요소 저장소를 검사하고 복구한다. 시스템 파일 검사기는 보호된 시스템 파일을 검사하고 손상된 파일을 정상 사본으로 교체한다.

bcdboot는 Windows 부팅 파일과 BCD 저장소를 생성하거나 복구하고, reagentc는 WinRE의 활성화 상태와 이미지 위치를 관리한다.

BitLocker로 암호화된 장치가 WinRE에 진입하면 운영체제 볼륨을 열기 위해 복구 키를 요구할 수 있다. TPM 측정값이나 부팅 구성이 변경되면 정상적인 자동 잠금 해제가 이루어지지 않을 수 있다.

Windows 11의 Quick Machine Recovery는 광범위한 부팅 장애가 발생한 장치가 WinRE에서 네트워크에 연결하고 Microsoft가 제공하는 복구 조치를 검색·적용할 수 있도록 한다. Microsoft는 이 기능을 부팅을 막는 중대한 오류에서 Windows 장치를 복구하고, 다수 장치에 발생한 장애에 대한 관리 부담을 줄이는 기능으로 설명한다.^[129]

Quick Machine Recovery의 기본 흐름은 다음과 같다.

Quick Machine Recovery의 복구 흐름

1. Windows가 반복적으로 부팅에 실패
   ↓
2. Windows 복구 환경 시작
   ↓
3. 네트워크 연결
   ↓
4. Windows Update 기반 복구 서비스에 해결책 조회
   ↓
5. 장치에 적용 가능한 복구 조치 다운로드
   ↓
6. 오프라인 Windows 설치에 수정 적용
   ↓
7. 컴퓨터를 다시 시작하여 정상 부팅 시도

복구 환경은 백업을 대체하지 않는다. 운영체제 구성 손상은 복구할 수 있지만, 저장 장치의 물리적 고장, 랜섬웨어, 삭제된 사용자 데이터와 복구 파티션 자체의 손상까지 항상 해결하지는 못한다.

Windows의 복구 전략은 일반적으로 다음 순서로 구성된다.

• 정상 부팅 상태에서 설정과 응용 프로그램 복구
• 안전 모드와 시스템 파일 검사
• 최근 업데이트나 드라이버 제거
• 시스템 복원
• WinRE 자동 복구
• 이 PC 초기화
• 시스템 이미지 복원
• 설치 미디어를 이용한 복구 설치 또는 새 설치
• 별도 백업에서 사용자 데이터 복원

조직 환경에서는 BitLocker 복구 키, 로컬 관리자 자격 증명, WinRE 접근 정책, 장치 재프로비저닝과 사용자 데이터 백업을 중앙에서 관리한다. Microsoft Entra ID, Active Directory, Intune과 관리 도구에 복구 키와 장치 정보를 저장하여 현장에 직접 접근하지 않고도 복구를 지원할 수 있다.

Windows의 보안은 사용자 인증, 객체 접근 제어, 권한 분리, 네트워크 필터링, 악성 코드 방어, 부팅 무결성, 코드 검증과 가상화 기반 격리를 여러 계층에 적용하는 방식으로 구성된다.

사용자가 로그인하면 Windows는 계정과 그룹을 나타내는 접근 토큰을 생성한다. 프로세스가 파일, 레지스트리 키, 프로세스와 서비스 같은 보호 가능한 객체에 접근하려 하면, 운영체제는 토큰의 보안 식별자와 권한을 객체의 보안 설명자와 비교한다. 관리자 계정도 일반 작업에서는 제한된 토큰을 사용하며, 시스템 변경이 필요할 때 사용자 계정 컨트롤을 통해 권한을 상승한다.

부팅 단계에서는 Secure Boot와 Trusted Boot가 펌웨어에서 Windows 커널까지 이어지는 실행 구성 요소를 검증한다. 운영체제가 시작된 뒤에는 코드 무결성, 드라이버 서명과 가상화 기반 보안이 커널과 보안 구성 요소를 보호한다. Microsoft Defender Antivirus와 Windows 방화벽은 악성 코드와 네트워크 공격에 대응하고, Credential Guard와 Windows Hello는 인증 정보가 탈취되는 범위를 줄인다.

Windows 보안의 주요 계층

• 하드웨어와 펌웨어
  • UEFI Secure Boot
  • TPM
  • 하드웨어 보안 기능
    • 부팅 신뢰
      • Windows Boot Manager
      • Trusted Boot
      • Early Launch Antimalware
      • 측정된 부팅
        • 운영체제 보호
          • 커널 코드 무결성
          • 가상화 기반 보안
          • 메모리 무결성
          • 취약 드라이버 차단
            • 사용자와 응용 프로그램
              • 접근 토큰과 ACL
              • 사용자 계정 컨트롤
              • Microsoft Defender Antivirus
              • Windows 방화벽
              • Credential Guard
              • AppContainer
              • Windows Sandbox

이러한 계층 가운데 하나가 모든 공격을 차단하는 것은 아니다. Windows는 한 계층이 우회되거나 취약해지더라도 다른 계층이 공격자의 권한, 실행 범위, 네트워크 접근과 자격 증명 획득을 제한하도록 설계된다.

보안 모델

Windows NT의 보안 모델은 보안 주체, 접근 토큰, 보호 가능한 객체, 보안 설명자와 접근 검사를 중심으로 구성된다.

보안 주체는 운영체제에서 인증되고 권한을 부여받을 수 있는 개체다. 다음 항목이 대표적인 보안 주체다.

• 사용자 계정
• 컴퓨터 계정
• 보안 그룹
• 서비스 계정
• 응용 프로그램 패키지
• AppContainer
• 로그인 세션
• 일부 가상 계정과 관리 서비스 계정

각 사용자, 그룹과 컴퓨터 계정에는 보안 식별자 또는 SID가 부여된다. SID는 표시 이름과 별개인 고유 식별자로, 계정 이름이 바뀌어도 접근 제어 항목에서 동일한 주체를 나타낸다.

Windows가 보호하는 자원은 보호 가능한 객체로 표현된다. 파일, 디렉터리, 레지스트리 키, 프로세스, 스레드, 서비스, 이벤트, 뮤텍스, 공유 메모리, 작업 객체와 Active Directory 객체 등이 이에 포함된다.

보호 가능한 객체에는 보안 설명자가 연결된다. 보안 설명자는 다음 정보를 포함할 수 있다.

• 객체 소유자
• 주 그룹
• 임의 접근 제어 목록
• 시스템 접근 제어 목록
• 상속과 보호 상태
• 무결성 레이블

임의 접근 제어 목록 또는 DACL은 어떤 보안 주체에 어떤 접근을 허용하거나 거부할지를 결정한다. DACL은 여러 접근 제어 항목으로 구성되며 각 항목에는 SID, 허용 또는 거부 형식과 접근 권한 비트가 기록된다.

시스템 접근 제어 목록 또는 SACL은 접근 성공과 실패를 감사할 조건을 정의한다. 감사가 활성화되어 있으면 해당 조건에 맞는 접근 사건이 Windows 보안 이벤트 로그에 기록될 수 있다.

Microsoft는 Windows 접근 제어 모델의 두 기본 요소를 로그인한 사용자의 정보를 가진 접근 토큰과 보호 가능한 객체의 보안 정보를 가진 보안 설명자로 정의한다.^[130]

접근 검사는 일반적으로 다음 흐름으로 수행된다.

Windows 객체 접근 검사

1. 스레드가 객체에 특정 접근 권한 요청
   ↓
2. 운영체제가 프로세스 또는 스레드의 접근 토큰 확인
   ↓
3. 토큰의 사용자 SID와 그룹 SID 수집
   ↓
4. 객체의 보안 설명자와 DACL 확인
   ↓
5. 거부 및 허용 접근 제어 항목 평가
   ↓
6. 요청한 권한이 모두 허용되면 객체 핸들 생성
   ↓
7. 허용된 접근 권한을 핸들에 기록

프로그램이 객체를 연 뒤에는 핸들에 허용된 접근 권한이 기록된다. 이후 프로그램이 그 핸들로 작업을 요청하면 운영체제는 핸들에 부여된 권한 범위에서 요청을 처리한다.

Windows는 객체별로 서로 다른 접근 권한을 정의한다. 파일에는 읽기, 쓰기, 실행, 삭제와 속성 변경이 있고, 프로세스에는 메모리 읽기, 스레드 생성, 종료와 토큰 접근 같은 권한이 있다.

소유자는 일반적으로 객체의 DACL을 변경할 수 있다. 따라서 파일 데이터에 직접 접근할 권한이 없더라도 소유권을 가진 보안 주체가 접근 제어 구성을 바꿀 수 있다. 소유권 가져오기 자체는 별도의 권한과 정책에 의해 제한된다.

Windows는 ACL 외에도 권한, 무결성 수준, 응용 프로그램 기능, 격리 경계를 함께 사용한다. 파일 접근이 ACL에서 허용되더라도 프로세스의 무결성 수준, AppContainer 기능 또는 보호 프로세스 정책이 작업을 제한할 수 있다.

필수 무결성 제어는 프로세스와 객체에 무결성 수준을 지정한다. 대표적으로 낮음, 중간, 높음과 시스템 수준이 있으며, 낮은 무결성 프로세스가 더 높은 무결성 객체를 수정하는 작업을 제한한다.

인터넷에서 받은 콘텐츠나 샌드박스 프로세스는 낮은 무결성 수준을 사용할 수 있고, 일반 사용자 프로그램은 보통 중간 수준에서 실행된다. 관리자 권한으로 상승한 프로세스는 높은 무결성 수준을 사용한다.

접근 토큰과 권한

접근 토큰은 프로세스나 스레드의 보안 문맥을 나타내는 커널 객체다. 사용자 로그인에 성공하면 Windows는 사용자의 SID, 그룹, 권한과 로그인 정보를 포함한 토큰을 생성한다.

Microsoft는 접근 토큰을 프로세스나 스레드의 보안 문맥을 설명하는 객체로 정의한다. 토큰에는 사용자 계정의 SID, 그룹 SID와 사용자가 보유한 권한이 포함된다.^[131]

접근 토큰에는 다음 정보가 포함될 수 있다.

• 사용자 SID
• 그룹 SID
• 로그인 SID
• 제한된 SID
• 권한 목록
• 기본 소유자
• 기본 DACL
• 토큰 원본
• 인증 식별자
• 무결성 수준
• 세션 식별자
• 응용 프로그램 패키지 SID
• AppContainer SID와 기능
• 가상화 상태
• 토큰 상승 상태

프로세스는 기본적으로 주 토큰을 가진다. 프로세스가 생성하는 스레드는 특별한 설정이 없으면 프로세스의 주 토큰을 이용해 보안 검사를 받는다.

스레드는 일시적으로 가장 토큰을 사용할 수 있다. 서버 프로세스가 클라이언트의 요청을 처리할 때 클라이언트의 보안 문맥을 가장하면, 서버 자체 계정이 아니라 요청한 사용자의 권한으로 파일이나 다른 자원에 접근할 수 있다.

가장 수준은 서버가 클라이언트의 정보를 확인하거나 실제 권한으로 동작할 수 있는 범위를 결정한다. 원격 서버에 자격 증명을 다시 전달할 수 있는 위임은 가장 강한 수준이며, 인증 방식과 조직 정책에 의해 제한된다.

권한은 객체의 ACL을 통한 일반 접근과 다른 시스템 수준 능력이다. 시스템 종료, 시간 변경, 드라이버 적재, 토큰 생성, 디버깅과 파일 백업처럼 운영체제 전체에 영향을 미치는 작업에 사용된다.

대표적인 Windows 권한은 다음과 같다.

토큰에 권한이 존재한다고 해서 항상 활성화되어 있는 것은 아니다. 많은 권한은 기본적으로 비활성화되고, 필요한 작업을 수행하기 직전에 프로세스가 명시적으로 활성화한다.

관리자 그룹에 포함된 계정은 로그인 시 더 많은 SID와 권한을 가진 토큰을 받을 수 있지만, 사용자 계정 컨트롤이 활성화되어 있으면 일반 작업에는 필터링된 제한 토큰이 사용된다.

제한 토큰은 일부 SID를 사용하지 않도록 만들고, 권한을 제거하며, 제한 SID를 추가해 프로세스의 접근 범위를 줄인다. 샌드박스와 제한 실행 환경은 제한 토큰, 무결성 수준과 작업 객체를 조합할 수 있다.

사용자 계정 컨트롤

사용자 계정 컨트롤 또는 UAC는 프로그램이 관리자 권한을 사용해 시스템을 변경하기 전에 사용자에게 알리고 승인이나 관리자 자격 증명을 요구하는 Windows 보안 기능이다.

Microsoft는 UAC를 운영체제를 허가되지 않은 변경으로부터 보호하도록 설계된 Windows 보안 기능으로 정의한다.^[132]

UAC는 관리자 계정의 일상적인 작업과 시스템 관리 작업을 분리한다. 관리자 그룹에 속한 사용자가 로그인하면 Windows는 일반적으로 두 개의 연결된 토큰을 만든다.

• 필터링된 표준 사용자 수준 토큰
• 관리자 SID와 권한을 가진 상승 토큰

Explorer와 일반 응용 프로그램은 기본적으로 필터링된 토큰으로 실행된다. 프로그램이 관리자 권한을 요구하면 Windows는 상승 요청을 표시하고 승인된 경우 높은 권한의 새 프로세스를 시작한다.

표준 사용자에게는 관리자 계정의 자격 증명을 입력하는 창이 표시될 수 있고, 관리자 사용자에게는 요청을 허용하거나 거부하는 동의 창이 표시된다.

UAC 권한 상승 흐름

1. 프로그램이 관리자 권한이 필요한 작업 요청
   ↓
2. 응용 프로그램 매니페스트와 실행 조건 확인
   ↓
3. 응용 프로그램 정보 서비스가 상승 요청 처리
   ↓
4. 보안 데스크톱에 UAC 확인 창 표시
   ↓
5. 사용자가 동의하거나 관리자 자격 증명 입력
   ↓
6. 높은 무결성 수준과 관리자 토큰으로 새 프로세스 생성
   ↓
7. 상승된 프로세스가 시스템 변경 수행

UAC 확인 창은 기본적으로 보안 데스크톱에 표시된다. 보안 데스크톱에서는 일반 사용자 프로그램이 확인 창의 입력을 흉내 내거나 내용을 변경하기 어렵도록 다른 창과 입력 경로를 분리한다.

실행 파일의 매니페스트는 필요한 실행 수준을 선언할 수 있다.

• 현재 사용자와 같은 권한으로 실행
• 가능한 가장 높은 권한으로 실행
• 반드시 관리자 권한으로 실행

매니페스트가 없는 오래된 설치 프로그램은 파일 이름, 버전 정보와 실행 동작을 바탕으로 설치 프로그램으로 감지되어 상승을 요청할 수 있다.

UAC는 권한 상승 경계이지만 사용자의 신뢰 판단을 완전히 대신하지 않는다. 사용자가 악성 프로그램의 상승을 승인하면 해당 프로그램은 높은 권한으로 시스템을 변경할 수 있다.

UAC는 관리자 계정을 표준 사용자 계정으로 바꾸는 기능도 아니다. 관리자 계정은 승인 후 높은 권한을 사용할 수 있고, 표준 사용자는 관리자 자격 증명을 제공해야 한다.

오래된 응용 프로그램이 보호된 시스템 위치에 파일이나 레지스트리 값을 쓰려고 할 때 Windows는 일부 32비트 프로그램에 파일 및 레지스트리 가상화를 적용할 수 있다. 쓰기 요청을 사용자 프로필 아래의 가상 위치로 리디렉션하여 프로그램이 제한된 권한에서도 동작하도록 돕는다.

가상화는 호환성 기능이며 현대 응용 프로그램의 저장 방식으로 사용되지 않는다. 매니페스트가 있거나 64비트이거나 관리자 권한으로 실행되는 프로그램에는 적용되지 않을 수 있다.

조직은 그룹 정책과 MDM으로 UAC의 확인 방식, 보안 데스크톱 사용, 설치 프로그램 감지와 관리자 승인 모드를 구성할 수 있다. UAC를 완전히 비활성화하면 일부 보안 경계와 현대 Windows 기능의 동작에도 영향을 줄 수 있다.

Windows Defender

Microsoft Defender는 Microsoft의 여러 보안 제품과 서비스를 포괄하는 브랜드다. Windows에 기본 포함된 악성 코드 방지 구성 요소의 정식 명칭은 Microsoft Defender Antivirus다.

과거에는 Windows Defender가 별도의 스파이웨어 방지 프로그램을 가리켰으나, Windows 8 이후 기본 백신 기능과 통합되었고 이후 Microsoft Defender Antivirus로 이름이 바뀌었다.

Microsoft Defender Antivirus는 Windows에 기본 포함되며 파일, 프로세스, 다운로드와 시스템 동작을 검사한다. Microsoft Defender for Endpoint와 결합하면 조직의 엔드포인트 탐지, 조사와 대응 기능에 연결된다.^[133]

Microsoft Defender Antivirus의 주요 기능은 다음과 같다.

• 실시간 악성 코드 검사
• 수동 및 예약 검사
• 동작 기반 탐지
• 클라우드 제공 보호
• 보안 인텔리전스 기반 탐지
• 다운로드와 첨부 파일 검사
• 스크립트 검사
• 네트워크 파일 검사
• 자동 샘플 제출
• 변조 방지
• 격리와 위협 제거
• 오프라인 검사
• 공격 표면 감소 규칙 연동
• 랜섬웨어 보호 기능 연동

실시간 보호는 파일이 열리거나 생성되고 프로그램이 실행될 때 콘텐츠와 동작을 검사한다. 서명 기반 탐지뿐 아니라 휴리스틱, 동작 감시, 기계 학습과 클라우드 분석이 함께 사용될 수 있다.

클라우드 제공 보호는 장치에서 확인된 파일과 동작 정보를 Microsoft의 클라우드 보호 서비스와 비교해 새롭거나 빠르게 확산되는 위협에 대응한다. 의심스러운 파일은 정책과 개인정보 설정에 따라 분석용 샘플로 제출될 수 있다.

보안 인텔리전스 업데이트에는 악성 코드 탐지 정보가 포함된다. 엔진과 플랫폼 업데이트는 검사 기능과 운영체제 통합을 갱신한다.

Microsoft Defender Antivirus는 다음과 같은 검사 유형을 제공한다.

• 빠른 검사는 악성 코드가 흔히 존재하는 위치와 실행 중인 영역을 검사한다.
• 전체 검사는 연결된 파일과 실행 환경을 폭넓게 검사한다.
• 사용자 지정 검사는 선택한 파일과 위치를 검사한다.
• 오프라인 검사는 Windows가 정상 실행 중이지 않은 별도 환경에서 검사한다.

오프라인 검사는 실행 중인 운영체제 안에서 자신을 숨기거나 보안 프로그램을 방해하는 악성 코드 분석에 사용될 수 있다.

Windows Security 앱은 Microsoft Defender Antivirus만을 뜻하지 않는다. 바이러스 및 위협 방지, 방화벽, 계정 보호, 앱 및 브라우저 제어, 장치 보안과 다른 공급사의 보안 제품 상태를 보여주는 통합 사용자 인터페이스다.

Microsoft는 Windows Security 앱에서 Defender Antivirus의 상태, 실시간 보호, 업데이트, 검사 결과와 제외 항목을 관리할 수 있도록 한다.^[134]

다른 백신 제품이 설치되면 Microsoft Defender Antivirus의 실행 모드는 Windows 버전, 제품 종류와 Defender for Endpoint 등록 여부에 따라 활성, 수동 또는 비활성 상태로 변경될 수 있다.^[135]

Microsoft Defender for Endpoint는 조직용 엔드포인트 보안 플랫폼이다. 예방 보호뿐 아니라 공격 탐지, 엔드포인트 원격 측정, 자동 조사, 위협 사냥과 대응 기능을 제공한다. Windows에 기본 포함된 백신 엔진과 연동되지만 동일한 제품 범위는 아니다.^[136]

Microsoft Defender SmartScreen은 웹사이트, 다운로드와 평판이 낮은 응용 프로그램을 검사한다. Microsoft Edge와 Windows 셸은 파일의 출처, 서명과 평판 정보를 이용해 경고하거나 실행을 차단할 수 있다.

Smart App Control은 지원되는 Windows 환경에서 코드 서명, 응용 프로그램 평판과 클라우드 보안 정보를 이용해 신뢰할 수 없거나 잠재적으로 위험한 응용 프로그램 실행을 제한한다.

공격 표면 감소 규칙은 Office 문서, 스크립트, 자격 증명 탈취와 프로세스 생성에서 자주 악용되는 동작을 정책으로 제한한다. 기업에서는 Defender for Endpoint, Intune, 그룹 정책과 PowerShell로 배포할 수 있다.

방화벽과 네트워크 보호

Windows 방화벽은 장치에 들어오고 나가는 네트워크 트래픽을 규칙에 따라 허용하거나 차단하는 호스트 기반 상태 저장 방화벽이다. 모든 Windows 에디션에 포함되며 기본적으로 활성화된다.

Microsoft는 Windows 방화벽이 출발지와 목적지 주소, 프로토콜, 포트, 응용 프로그램과 서비스 등의 조건에 따라 인바운드·아웃바운드 트래픽을 필터링한다고 설명한다.^[137]

방화벽은 네트워크 연결을 다음 프로필로 구분한다.

• 도메인 프로필
• 개인 프로필
• 공용 프로필

도메인 프로필은 컴퓨터가 인증된 Active Directory 도메인 네트워크를 감지했을 때 사용된다. 개인 프로필은 신뢰하는 가정 또는 내부 네트워크에 사용되고, 공용 프로필은 카페와 공항처럼 신뢰하지 않는 네트워크에서 더 제한적인 규칙을 적용하는 데 사용된다.

각 프로필은 독립적인 활성화 상태, 기본 동작과 규칙 집합을 가질 수 있다. 네트워크가 여러 개 연결되면 각 인터페이스에 다른 프로필이 적용될 수 있다.

기본 구성에서는 일반적으로 요청하지 않은 인바운드 연결을 차단하고, 명시적인 차단 규칙이 없는 아웃바운드 연결은 허용한다. 조직은 아웃바운드도 기본 차단 방식으로 구성할 수 있다.^[138]

방화벽 규칙은 다음 조건을 조합할 수 있다.

• 프로그램 경로
• Windows 서비스
• 응용 프로그램 패키지
• 로컬 및 원격 주소
• 로컬 및 원격 포트
• TCP, UDP와 다른 IP 프로토콜
• 네트워크 인터페이스
• 사용자와 컴퓨터
• 네트워크 프로필
• IPsec 인증 상태
• 규칙 적용 방향

상태 저장 방화벽은 허용된 연결의 상태를 추적한다. 내부에서 시작한 TCP 연결에 대한 응답 트래픽은 별도의 인바운드 허용 규칙 없이 연결 상태에 따라 허용될 수 있다.

Windows 방화벽은 IPsec 연결 보안 규칙도 지원한다. 컴퓨터 사이의 네트워크 트래픽을 인증하거나 암호화하고, 특정 사용자나 장치만 서비스에 연결하도록 제한할 수 있다.

관리 도구에는 다음이 포함된다.

• Windows Security 앱
• 제어판 방화벽 인터페이스
• 고급 보안이 포함된 Windows 방화벽
• PowerShell NetSecurity 모듈
• netsh advfirewall
• 그룹 정책
• Microsoft Intune
• Windows Filtering Platform API

Windows Filtering Platform은 네트워크 스택의 여러 계층에서 트래픽을 검사하고 수정할 수 있는 플랫폼이다. Windows 방화벽, IPsec, 보안 제품과 네트워크 필터 프로그램이 이 플랫폼을 사용한다.

방화벽 서비스를 단순히 중지하는 방식은 필터링 외의 서비스 강화, IPsec와 부팅 시 필터에도 영향을 줄 수 있다. 필요한 통신은 방화벽 전체를 끄기보다 범위를 제한한 허용 규칙으로 구성하는 것이 기본 방식이다.

Windows Security의 방화벽 및 네트워크 보호 화면은 현재 네트워크 프로필과 Windows 방화벽 또는 다른 방화벽 공급자의 상태를 표시한다.^[139]

Secure Boot와 TPM

Secure Boot는 UEFI 펌웨어가 신뢰하는 디지털 서명을 가진 부팅 소프트웨어만 실행하도록 검사하는 보안 표준이다. 부팅 키트와 변조된 부트 로더가 Windows 커널보다 먼저 실행되는 것을 방지하는 데 사용된다.

컴퓨터가 시작되면 UEFI 펌웨어는 UEFI 드라이버, 옵션 ROM, EFI 응용 프로그램과 운영체제 부트 로더의 서명을 검사한다. 서명이 신뢰 데이터베이스에 연결되고 차단 목록에 포함되지 않은 경우 다음 단계로 제어를 넘긴다.

Microsoft는 Secure Boot를 장치가 OEM이 신뢰하는 소프트웨어만 이용해 부팅하도록 하는 업계 보안 표준으로 설명한다.^[140]

Windows의 부팅 보호는 다음과 같이 이어진다.

Windows의 부팅 신뢰 흐름

1. UEFI 펌웨어 시작
   ↓
2. Secure Boot가 펌웨어 드라이버와 부트 로더 서명 검증
   ↓
3. Windows Boot Manager 실행
   ↓
4. Trusted Boot가 Windows 커널과 부팅 드라이버 검증
   ↓
5. Early Launch Antimalware가 부팅 초기 드라이버 분류
   ↓
6. 커널 코드 무결성과 보안 정책 적용
   ↓
7. 운영체제 서비스와 사용자 세션 시작

Trusted Boot는 Secure Boot 이후 Windows 부트 로더가 커널, 부팅 시작 드라이버와 초기 시스템 구성 요소의 무결성을 검사하는 과정이다. Microsoft는 Secure Boot와 Trusted Boot가 Windows 11 시작 과정에서 손상되거나 악성인 구성 요소의 적재를 막는다고 설명한다.^[141]

Early Launch Antimalware 또는 ELAM은 다른 비Microsoft 부팅 시작 드라이버보다 먼저 실행되는 악성 코드 방지 드라이버다. 부팅 드라이버를 신뢰 상태에 따라 분류하고 운영체제 정책이 적재 여부를 결정하도록 돕는다.

측정된 부팅은 부팅 구성 요소를 단순히 허용하거나 차단하는 대신 각 단계의 측정값을 TPM에 기록한다. 장치 상태 증명 서비스는 이 측정값을 이용해 장치가 요구되는 부팅 상태로 시작했는지 평가할 수 있다.

Trusted Platform Module 또는 TPM은 암호화 키 생성, 보관과 측정값 보호 같은 보안 기능을 제공하는 하드웨어 또는 펌웨어 기반 구성 요소다. 키를 일반 시스템 메모리와 분리하고 특정 장치와 부팅 상태에 연결하는 데 사용된다.

Microsoft는 TPM을 주로 암호화 키와 관련된 기본 보안 기능을 제공하도록 설계된 마이크로칩으로 설명한다.^[142]

Windows는 TPM을 다음 기능에 사용할 수 있다.

• BitLocker 키 보호
• Windows Hello와 Windows Hello for Business
• 장치 상태 증명
• Credential Guard
• 가상화 기반 보안
• 인증서와 개인 키 보호
• Secure Boot 측정값 저장
• 장치 정체성
• 플랫폼 무결성 확인

TPM의 플랫폼 구성 레지스터는 부팅 과정에서 측정된 값을 누적한다. 암호화 키를 특정 PCR 값에 봉인하면 장치가 예상된 부팅 구성으로 시작된 경우에만 키를 사용할 수 있게 만들 수 있다.

BitLocker는 TPM에 보호된 키를 이용해 정상 부팅에서는 운영체제 볼륨을 자동으로 잠금 해제하고, 펌웨어나 부팅 구성이 예상과 다르면 복구 키를 요구할 수 있다.

Windows Hello는 장치에 생성된 키를 TPM으로 보호하고, PIN이나 생체 정보로 키 사용을 승인한다. 계정 암호 자체를 매번 원격 서비스로 보내는 대신 장치에 연결된 비대칭 키로 인증할 수 있다.

Microsoft는 TPM이 Windows Hello, BitLocker, Credential Guard와 장치 상태 증명에 하드웨어 기반 키 보호와 장치 바인딩을 제공한다고 설명한다.^[143]

Secure Boot와 TPM은 같은 기능이 아니다. Secure Boot는 부팅 소프트웨어의 서명과 신뢰 체인을 검사하고, TPM은 키와 측정값을 안전하게 보관한다. 둘을 결합하면 검증된 부팅 상태에 암호화 키와 자격 증명을 연결할 수 있다.

코드 무결성과 드라이버 서명

코드 무결성은 Windows에서 실행되는 커널 코드와 정책 대상 사용자 모드 코드가 허용된 서명과 보안 정책을 충족하는지 확인하는 체계다.

커널 모드 코드는 시스템 전체 메모리와 하드웨어에 접근할 수 있으므로, Windows는 일반 응용 프로그램보다 강한 적재 조건을 적용한다. 드라이버 패키지의 디지털 서명은 게시자와 패키지 무결성을 확인하며, 커널 코드 서명 정책은 운영체제가 드라이버를 적재할 수 있는지 결정한다.

현대 64비트 Windows에서는 일반적인 커널 모드 드라이버에 유효한 서명이 필요하다. Windows 10 버전 1607 이후 새 커널 모드 드라이버는 원칙적으로 Microsoft 하드웨어 개발자 포털을 통해 서명되어야 한다.^[144]

드라이버 서명은 다음 정보를 검증한다.

• 패키지를 제출한 게시자
• 드라이버 파일과 INF의 무결성
• 카탈로그에 기록된 파일 해시
• 인증서의 신뢰 체인
• 서명 시각과 폐기 상태
• Microsoft 서명 정책 충족 여부

서명되었다고 해서 드라이버에 취약점이나 기능 오류가 없다는 의미는 아니다. 서명은 출처와 변조 여부를 검증하며, 호환성과 품질은 HLK 시험, 배포 검증과 제조사의 유지 관리가 추가로 담당한다.

Microsoft는 증명 서명, HLK·WHQL 서명과 Windows Update 배포에 사용되는 여러 드라이버 서명 방식을 제공한다.^[145]

개발 중에는 테스트 서명된 드라이버를 시험 장치에서 적재할 수 있다. 테스트 서명 모드는 일반 공개 시스템의 기본 운용 상태가 아니며 관리자와 개발자가 지정한 시험 인증서를 신뢰하도록 구성한다.^[146]

가상화 기반 보안 또는 VBS는 Hyper-V 하이퍼바이저를 이용해 일반 Windows 커널과 분리된 가상 신뢰 수준을 만든다. 보안에 민감한 코드와 데이터를 이 격리 영역에서 처리해 커널이 손상되더라도 직접 접근하기 어렵게 한다.

하이퍼바이저로 보호되는 코드 무결성 또는 HVCI는 코드 무결성 검사를 가상화 기반 보안 영역으로 분리한다. Windows Security에서는 메모리 무결성이라는 이름으로 표시된다.

메모리 무결성은 커널에 적재할 코드가 신뢰 정책을 충족하는지 격리된 환경에서 검증한다. 실행 가능한 커널 메모리와 쓰기 가능한 메모리를 분리하고, 검증되지 않은 코드가 커널 권한으로 실행되는 것을 제한한다.

Microsoft는 메모리 무결성을 가상화 기반 보안으로 보호되는 코드 무결성 기능으로 설명하며 Windows Security의 코어 격리 설정에서 관리할 수 있도록 한다.^[147]

일부 오래된 드라이버는 메모리 무결성이 요구하는 메모리와 코드 규칙을 충족하지 않아 차단될 수 있다. 이 경우 드라이버 제조사의 호환 버전으로 갱신하는 방식이 사용된다.

Windows는 알려진 취약 드라이버의 적재를 막기 위한 Microsoft 취약 드라이버 차단 목록도 제공한다. 유효한 서명이 있더라도 공개된 취약점이 커널 공격에 이용될 수 있는 드라이버를 차단 정책에 포함한다.^[148]

App Control for Business는 조직이 허용된 실행 파일, 스크립트, 설치 프로그램과 드라이버를 정책으로 정의하는 응용 프로그램 제어 기능이다. 게시자 서명, 파일 특성, 해시와 관리형 설치 출처를 기준으로 허용 정책을 구성할 수 있다.

자격 증명 보호

Windows에서 자격 증명은 암호만을 뜻하지 않는다. Kerberos 티켓, NTLM 해시, 인증서 개인 키, 웹 토큰, Windows Hello 키와 원격 접속 자격 증명도 공격자가 사용자나 컴퓨터를 가장하는 데 사용할 수 있다.

Windows는 자격 증명 입력, 저장, 인증과 원격 전달 과정에 여러 보호 계층을 사용한다.

• 보안 데스크톱
• Local Security Authority
• DPAPI
• TPM 키 보호
• Windows Hello
• Credential Guard
• Remote Credential Guard
• 보호된 프로세스
• 자격 증명 관리자
• Kerberos와 인증 정책
• 피싱 방지 보안 키

Local Security Authority Subsystem Service 또는 LSASS는 사용자 로그인, 로컬 보안 정책, 액세스 토큰 생성과 인증 패키지를 관리한다. 도메인 로그인과 네트워크 인증 과정에서 필요한 자격 증명 자료 일부도 이 프로세스에 존재할 수 있다.

관리자 권한이나 커널 취약점을 확보한 공격자가 LSASS 메모리를 읽으면 암호 해시와 Kerberos 자격 증명을 탈취해 다른 시스템으로 이동할 수 있다.

Credential Guard는 가상화 기반 보안을 사용하여 NTLM 해시와 Kerberos 티켓 부여 티켓 같은 비밀을 일반 Windows 커널과 분리된 격리 환경에 보관한다. LSASS는 격리된 비밀을 직접 읽는 대신 제한된 인증 작업을 요청한다.

Microsoft는 Credential Guard가 VBS를 사용해 비밀을 격리함으로써 권한 있는 시스템 소프트웨어만 해당 정보에 접근하도록 제한한다고 설명한다.^[149]

Credential Guard의 기본 구조

• 일반 Windows 실행 환경
  • 사용자 응용 프로그램
  • LSASS
  • Windows 커널
    • 하이퍼바이저 경계
      • 가상 보안 모드
        • LSA 격리 구성 요소
        • NTLM 및 Kerberos 비밀
        • TPM으로 보호되는 VSM 키

Credential Guard는 모든 자격 증명을 보호하지 않는다. 로컬 계정, Microsoft 계정, 응용 프로그램이 자체적으로 관리하는 암호, 인증서 일부와 사용자가 직접 입력한 평문 자격 증명은 별도의 보호가 필요하다.

Microsoft는 Credential Guard가 보호하는 비밀과 보호하지 않는 자격 증명 유형을 구분하며, 암호 없는 인증과 다른 보안 계층을 함께 사용하도록 안내한다.^[150]

LSA 보호는 LSASS를 보호된 프로세스로 실행하여 신뢰되지 않은 코드가 프로세스에 삽입되거나 메모리를 읽는 것을 제한한다. 적절한 서명 수준을 가진 보안 패키지와 플러그인만 로드할 수 있도록 한다.

Windows Hello와 Windows Hello for Business는 사용자가 PIN, 생체 정보나 보안 키로 장치의 비대칭 키 사용을 승인하는 인증 방식이다. PIN은 장치에 연결되며 원격 서비스의 재사용 가능한 암호와 같은 방식으로 전송되지 않는다.

TPM이 있는 장치에서는 Windows Hello 개인 키를 TPM 안에서 생성하거나 보호할 수 있다. 사용자의 얼굴, 지문과 PIN은 키를 사용하는 로컬 동작을 승인하며 생체 템플릿 자체가 원격 서버의 일반 암호로 사용되지는 않는다.

Remote Credential Guard는 원격 데스크톱 연결에서 사용자의 재사용 가능한 자격 증명을 원격 호스트에 직접 보내지 않고, 원본 장치가 인증 요청을 대신 처리하도록 한다. 원격 호스트가 침해되어도 사용자의 도메인 자격 증명이 해당 호스트에 남는 범위를 줄인다.

Windows Defender Credential Guard와 이름이 비슷하지만 Remote Credential Guard는 원격 데스크톱 인증 전달을 보호하는 별도 기능이다.

DPAPI는 응용 프로그램과 Windows 구성 요소가 데이터를 사용자 또는 컴퓨터 자격 증명에 연결해 암호화할 수 있도록 한다. 브라우저, 자격 증명 관리자와 응용 프로그램이 저장한 비밀 보호에 사용될 수 있다.

자격 증명 관리자는 Windows 자격 증명과 웹 자격 증명을 저장하고 관리한다. 저장된 자격 증명은 사용자 문맥과 DPAPI에 연결되지만, 사용자의 세션이나 계정이 손상되면 악용될 가능성이 있으므로 필요한 항목만 유지한다.

샌드박스와 응용 프로그램 격리

Windows는 신뢰 수준이 다른 응용 프로그램을 서로 분리하기 위해 프로세스 주소 공간, 사용자 계정, 무결성 수준, AppContainer, 작업 객체, 가상 머신과 응용 프로그램 제어를 조합한다.

가장 기본적인 격리는 프로세스별 가상 주소 공간이다. 한 사용자 모드 프로세스는 다른 프로세스의 메모리를 일반 포인터로 직접 읽거나 쓸 수 없다. 다른 프로세스에 접근하려면 운영체제가 검사하는 프로세스 핸들과 적절한 접근 권한이 필요하다.

그러나 같은 사용자 권한으로 실행되는 일반 데스크톱 응용 프로그램끼리는 사용자의 파일과 여러 자원에 폭넓게 접근할 수 있다. 더 강한 격리가 필요한 응용 프로그램에는 AppContainer와 가상화 기반 환경을 사용할 수 있다.

AppContainer는 응용 프로그램을 최소 권한의 보안 문맥에서 실행하는 격리 환경이다. AppContainer 프로세스는 고유한 SID와 제한된 토큰을 사용하며, 명시적으로 부여된 기능과 ACL이 없는 자원에는 기본적으로 접근하지 못한다.

Microsoft는 AppContainer가 프로세스, 창, 장치, 파일과 디렉터리, 레지스트리, 네트워크와 자격 증명에 대한 접근을 격리한다고 설명한다.^[151]

AppContainer의 주요 격리 범위는 다음과 같다.

• 다른 응용 프로그램의 프로세스와 창
• 사용자 파일과 시스템 파일
• 레지스트리
• 네트워크
• 카메라, 마이크와 위치 장치
• 자격 증명
• 커널 객체
• COM과 시스템 서비스
• 클립보드와 사용자 인터페이스 일부

응용 프로그램은 카메라, 마이크, 인터넷 클라이언트와 사용자 라이브러리 같은 기능을 선언할 수 있다. 운영체제는 패키지 매니페스트, 사용자 동의와 정책을 바탕으로 필요한 자원에 제한된 접근을 허용한다.

UWP 응용 프로그램은 기본적으로 AppContainer에서 실행된다. MSIX로 패키징된 Win32 프로그램도 구성에 따라 AppContainer를 사용할 수 있지만, 단순히 MSIX 패키지로 만들었다고 모든 데스크톱 프로그램이 자동으로 AppContainer에 들어가는 것은 아니다.

Windows Sandbox는 신뢰하지 않는 Win32 프로그램을 별도의 경량 Windows 데스크톱 환경에서 실행하는 기능이다. Hyper-V 기반 가상화를 사용하며 호스트와 분리된 커널, 프로세스, 파일 시스템과 사용자 환경을 제공한다.

Microsoft는 Windows Sandbox를 신뢰하지 않는 Win32 응용 프로그램을 격리하여 실행하기 위한 경량 데스크톱 환경으로 설명한다.^[152]

Windows Sandbox의 기본 특성은 다음과 같다.

• 실행할 때 깨끗한 Windows 환경 생성
• 호스트와 분리된 프로세스와 커널 경계
• 종료하면 샌드박스 내부 변경 제거
• 호스트 Windows 이미지의 구성 요소를 효율적으로 공유
• 가상 GPU와 네트워크 지원
• 클립보드, 오디오, 비디오와 디렉터리 공유 구성
• 구성 파일을 통한 시작 명령과 자원 설정

샌드박스는 호스트 Windows의 시스템 파일 일부를 변경 불가능한 형태로 공유하고, 변경된 블록은 별도 차이 디스크에 기록해 전체 운영체제 이미지를 복사하는 비용을 줄인다.

Windows Sandbox의 네트워크와 클립보드는 기본 구성에서 호스트 또는 외부 환경과 통신 경로가 될 수 있다. 신뢰하지 않는 프로그램을 분석할 때에는 필요하지 않은 네트워크, 클립보드, 프린터, 오디오 입력과 디렉터리 공유를 비활성화할 수 있다.

Protected Client 모드는 Windows Sandbox 자체를 추가 AppContainer 격리 환경 안에서 실행하여 자격 증명, 장치, 파일, 네트워크, 프로세스와 창 격리를 강화한다.^[153]

Microsoft Defender Application Guard는 과거 Microsoft Edge와 Office의 신뢰하지 않는 콘텐츠를 Hyper-V 기반 격리 컨테이너에서 여는 기능으로 제공되었다. 이후 제품 전략 변화에 따라 지원 범위가 축소되거나 종료된 환경이 있으므로 현재 배포에서는 AppContainer, Windows Sandbox, Microsoft Edge 보안 기능과 조직의 응용 프로그램 제어 정책을 중심으로 구성한다.

Windows Sandbox와 AppContainer는 격리 수준과 용도가 다르다.

Windows Defender Application Control 또는 App Control for Business는 샌드박스가 아니라 실행 허용 정책이다. 승인된 코드만 실행하도록 제한하여 신뢰하지 않는 프로그램이 격리 환경 밖에서 시작되는 것을 방지한다.

Windows Sandbox, AppContainer와 응용 프로그램 제어는 함께 사용할 수 있다. 응용 프로그램 제어가 실행 가능한 코드의 범위를 제한하고, AppContainer가 프로그램의 자원 접근을 제한하며, Windows Sandbox가 별도의 운영체제 경계가 필요한 프로그램을 격리한다.

샌드박스도 완전한 보안 보장은 아니다. 하이퍼바이저, 공유 장치, 클립보드, 네트워크나 사용자가 연결한 디렉터리에 취약점이 존재할 수 있다. 격리 환경은 공격의 영향 범위를 줄이는 계층이며, 운영체제 업데이트, 최소한의 공유 설정과 신뢰 정책을 함께 사용해야 한다.

Windows는 개인용 컴퓨터의 인터넷 연결부터 기업 도메인, 파일 서버, 원격 데스크톱과 데이터센터 네트워크까지 지원하는 네트워크 체계를 제공한다. 응용 프로그램은 Winsock과 더 높은 수준의 API를 통해 통신하고, 커널의 TCP/IP 스택과 네트워크 드라이버가 데이터를 실제 네트워크 어댑터로 전달한다.

Windows의 네트워크 기능은 하나의 프로토콜이나 서비스로 구성되지 않는다. Ethernet, Wi-Fi와 셀룰러 같은 링크 기술 위에 IPv4·IPv6, TCP·UDP, DNS, DHCP와 IPsec이 동작하고, 그 위에서 SMB, HTTP, 원격 데스크톱, Active Directory와 여러 응용 프로그램 프로토콜이 사용된다.

Windows 네트워크 기능의 주요 계층

• 응용 프로그램과 서비스
  • 웹 브라우저와 인터넷 응용 프로그램
  • 파일과 프린터 공유
  • 원격 데스크톱
  • Active Directory
  • 사용자 정의 네트워크 프로그램
    • 응용 프로그램 인터페이스
      • Winsock
      • WinHTTP와 WinINet
      • .NET 네트워크 API
      • Windows Runtime 네트워크 API
        • 전송 및 인터넷 계층
          • TCP
          • UDP
          • IPv4와 IPv6
          • ICMP
          • IPsec
            • 네트워크 필터와 드라이버
              • Windows Filtering Platform
              • NDIS
              • 가상 네트워크 어댑터
              • 네트워크 인터페이스 드라이버
                • Ethernet, Wi-Fi, 셀룰러와 가상 네트워크

Windows는 동일한 네트워크 스택을 로컬 응용 프로그램, 서버 역할, Hyper-V 가상 스위치, VPN, 컨테이너와 WSL 같은 환경에서도 활용한다. 다만 각 환경은 별도의 가상 인터페이스, 라우팅, NAT와 방화벽 규칙을 사용할 수 있다.

Windows 네트워크 스택

Windows의 네트워크 스택은 응용 프로그램의 소켓 요청을 네트워크 프로토콜과 장치 드라이버를 거쳐 실제 프레임과 패킷으로 변환한다. 수신 데이터는 반대 방향으로 처리되어 대상 응용 프로그램의 소켓이나 시스템 서비스로 전달된다.

사용자 모드 응용 프로그램은 일반적으로 Windows Sockets 또는 Winsock을 사용한다. Winsock은 Berkeley sockets와 유사한 소켓 모델을 Windows에 제공하며 TCP, UDP와 다른 네트워크 프로토콜을 사용할 수 있게 한다.

응용 프로그램은 다음과 같은 순서로 통신할 수 있다.

Windows의 일반적인 TCP 통신 흐름

1. 응용 프로그램이 Winsock 소켓 생성
   ↓
2. DNS를 통해 대상 이름을 IP 주소로 해석
   ↓
3. 대상 주소와 포트로 연결 요청
   ↓
4. TCP/IP 스택이 연결 상태와 패킷 구성
   ↓
5. Windows Filtering Platform에서 정책과 필터 적용
   ↓
6. NDIS와 네트워크 어댑터 드라이버로 패킷 전달
   ↓
7. 네트워크 어댑터가 프레임 송신
   ↓
8. 응답 패킷을 역순으로 처리하여 응용 프로그램에 전달

Winsock은 동기 및 비동기 소켓 입출력을 지원한다. 작은 클라이언트 프로그램은 호출한 스레드가 결과를 기다리는 방식으로 구현할 수 있고, 대규모 서버는 겹친 입출력과 입출력 완료 포트를 이용해 많은 연결을 제한된 수의 스레드로 처리할 수 있다.

Windows에는 용도별로 더 높은 수준의 네트워크 API도 제공된다.

• WinHTTP는 서버와 서비스 중심의 HTTP 클라이언트 기능을 제공한다.
• WinINet은 대화형 데스크톱 응용 프로그램의 인터넷 기능을 위해 설계되었다.
• HTTP Server API는 응용 프로그램이 커널 HTTP 구성 요소를 이용해 HTTP 요청을 받을 수 있게 한다.
• .NET 네트워크 API는 소켓, HTTP, DNS와 TLS를 관리형 인터페이스로 제공한다.
• WinRT 네트워크 API는 패키지 응용 프로그램과 현대 Windows 응용 프로그램에서 사용할 수 있다.

Windows의 TCP/IP 스택은 IPv4와 IPv6를 함께 지원한다. 하나의 인터페이스에 두 프로토콜을 동시에 구성할 수 있고, 응용 프로그램은 대상 이름의 DNS 결과와 연결 정책에 따라 적절한 주소를 사용한다.

IP 계층은 다음 기능을 담당한다.

• 주소 지정
• 패킷 라우팅
• 인터페이스 선택
• 조각화와 재조립
• 이웃 검색
• 멀티캐스트
• 터널링
• 경로 MTU 처리
• IPsec 연결
• 패킷 전달

TCP는 연결 지향적인 신뢰성 있는 바이트 스트림을 제공한다. 순서 제어, 재전송, 흐름 제어와 혼잡 제어를 수행하며 SMB, 원격 데스크톱과 대부분의 웹 통신에서 사용된다.

UDP는 연결 설정과 신뢰성 보장 없이 데이터그램을 전달한다. DNS, 실시간 미디어, 일부 VPN과 검색 프로토콜처럼 낮은 지연 또는 응용 프로그램 자체의 전송 제어가 필요한 환경에서 사용된다.

Windows의 네트워크 어댑터 드라이버는 주로 Network Driver Interface Specification 또는 NDIS를 사용한다. NDIS는 네트워크 프로토콜 드라이버와 실제 네트워크 인터페이스 드라이버 사이의 공통 인터페이스를 제공한다.

NDIS 계층에는 다음 구성 요소가 참여할 수 있다.

• 프로토콜 드라이버
• 미니포트 드라이버
• 필터 드라이버
• 중간 드라이버
• 가상 네트워크 어댑터
• 네트워크 인터페이스 카드 하드웨어

미니포트 드라이버는 특정 네트워크 어댑터의 송수신, 인터럽트, DMA와 전원 관리를 구현한다. NDIS 필터 드라이버는 패킷을 관찰하거나 변경하며 보안, 가상화, 트래픽 분석과 네트워크 기능 확장에 사용된다.

Microsoft의 네트워크 드라이버 문서는 Windows 네트워크 장치 드라이버가 사용하는 함수, 콜백과 자료 구조를 NDIS 기반 인터페이스로 제공한다.^[154]

Windows Filtering Platform 또는 WFP는 네트워크 스택의 여러 계층에서 트래픽을 검사, 허용, 차단하거나 수정할 수 있는 API와 시스템 서비스 집합이다. Windows 방화벽, IPsec, 보안 제품과 네트워크 필터 프로그램이 사용한다.

WFP는 다음 지점에서 필터링할 수 있다.

• 응용 프로그램 연결 승인
• 전송 계층
• 네트워크 계층
• 패킷 전달
• 스트림
• 데이터그램
• IPsec
• 이름 해석과 일부 응용 프로그램 계층

Microsoft는 WFP가 운영체제 네트워크 스택의 여러 계층에서 패킷 처리를 검사하고 수정할 수 있는 플랫폼이라고 설명한다.^[155]

Windows는 네트워크 위치를 도메인, 개인과 공용 프로필로 분류한다. 이 프로필은 방화벽 규칙, 네트워크 검색과 공유 설정에 영향을 준다.

가상화 환경에서는 Hyper-V 가상 스위치, NAT, 가상 네트워크 어댑터와 가상 필터가 같은 네트워크 체계에 연결된다. WSL 2, Windows Sandbox, 컨테이너와 가상 머신은 각자의 가상 인터페이스와 주소를 사용할 수 있으며 호스트가 라우팅이나 NAT를 제공한다.

파일과 프린터 공유

Windows의 파일과 프린터 공유는 네트워크의 다른 사용자와 컴퓨터가 로컬 디렉터리와 프린터를 사용할 수 있게 한다. 파일 공유는 주로 SMB를 사용하고, 프린터 공유는 인쇄 스풀러와 SMB 또는 다른 인쇄 프로토콜을 결합한다.

공유되는 파일 자원에는 다음 요소가 적용된다.

• 공유 이름
• 로컬 파일 시스템 경로
• 공유 권한
• NTFS 권한
• 동시 연결과 사용 제한
• 오프라인 파일 정책
• 캐싱 정책
• SMB 암호화와 서명
• 접근 기반 열거

네트워크 사용자는 일반적으로 UNC 경로로 공유에 접근한다.

\\서버이름\공유이름

공유 아래의 파일은 다음과 같은 형식으로 나타낼 수 있다.

\\서버이름\공유이름\디렉터리\파일

UNC 경로는 로컬 드라이브 문자에 의존하지 않고 서버와 공유 이름을 사용한다. 사용자는 네트워크 공유를 드라이브 문자에 연결하여 로컬 디스크처럼 사용할 수도 있다.

파일 공유 접근에는 공유 권한과 파일 시스템 권한이 함께 적용될 수 있다. SMB를 통해 NTFS 볼륨의 파일에 접근하면 공유 수준에서 허용된 권한과 NTFS ACL에서 허용된 권한을 모두 충족해야 한다.

공유 권한은 일반적으로 다음 수준으로 구성된다.

• 읽기
• 변경
• 모든 권한

NTFS 권한은 파일과 디렉터리별로 더 세밀한 읽기, 쓰기, 실행, 삭제, 소유권과 권한 변경을 제어한다. 로컬에서 파일에 접근할 때에는 공유 권한이 적용되지 않고 NTFS 권한이 적용된다.

관리 공유는 시스템 관리 목적으로 자동 생성되는 숨김 공유다. 대표적으로 C$, ADMIN$와 IPC$가 있다. 공유 이름 끝의 $는 일반적인 네트워크 검색 목록에서 숨겨지는 공유를 나타내지만, 이름을 아는 사용자의 접근을 자체적으로 막는 보안 기능은 아니다.

관리 공유에 접근하려면 적절한 관리자 권한과 네트워크 인증이 필요하다. 조직은 정책이나 서비스 구성을 통해 자동 관리 공유의 사용 범위를 조정할 수 있다.

네트워크 검색은 같은 네트워크의 컴퓨터, 장치와 공유 자원을 찾을 수 있게 한다. 공용 네트워크에서는 보안을 위해 검색과 공유가 기본적으로 제한될 수 있고, 개인 또는 도메인 네트워크에서는 정책에 따라 활성화할 수 있다.

Windows의 검색 체계는 시대에 따라 NetBIOS, 컴퓨터 브라우저 서비스, SSDP, WS-Discovery, DNS와 Active Directory를 사용해 왔다. 현대 Windows의 네트워크 검색은 WS-Discovery 기반 서비스와 DNS를 주로 활용하며, 오래된 SMB1 컴퓨터 브라우저 체계는 기본 구성에서 사용되지 않는다.

오프라인 파일은 네트워크 공유의 파일을 로컬에 캐시하여 서버에 연결할 수 없을 때도 사용할 수 있게 한다. 다시 연결되면 변경 내용을 서버와 동기화한다.

오프라인 파일은 이동식 업무용 컴퓨터와 지사 환경에서 사용되지만, 같은 파일이 서버와 클라이언트에서 동시에 변경되면 충돌 해결이 필요할 수 있다. 현대 조직에서는 OneDrive, SharePoint와 다른 동기화 서비스가 일부 사용 사례를 대체한다.

분산 파일 시스템 또는 DFS는 여러 파일 서버의 공유를 하나의 논리적 이름 공간으로 구성한다. 사용자는 실제 서버 위치와 별개인 공통 경로로 접근하고, DFS 복제나 외부 저장 복제 기술을 통해 여러 서버에 데이터를 배치할 수 있다.

프린터 공유에서는 한 컴퓨터나 Windows Server가 인쇄 서버 역할을 한다. 클라이언트는 공유 프린터에 인쇄 작업을 보내고, 서버의 인쇄 스풀러가 작업을 대기열에 저장해 실제 프린터로 전달한다.

인쇄 서버는 다음 기능을 제공한다.

• 공유 프린터 검색
• 인쇄 대기열
• 작업 우선순위
• 사용자별 인쇄 권한
• 드라이버 배포
• 용지와 장치 설정
• 인쇄 작업 감사
• 여러 프린터 중앙 관리

네트워크 프린터는 반드시 Windows 컴퓨터에 공유되어야 하는 것은 아니다. 프린터가 직접 IPP, Mopria, LPR 또는 제조사 프로토콜을 제공하면 Windows 클라이언트가 네트워크 장치에 직접 연결할 수 있다.

파일과 프린터 공유는 Windows 방화벽의 파일 및 프린터 공유 규칙과 연결된다. 필요한 포트와 서비스가 방화벽에서 차단되어 있으면 공유가 구성되어 있어도 원격 컴퓨터에서 접근할 수 없다.

SMB

Server Message Block 또는 SMB는 Windows에서 파일, 디렉터리, 프린터와 이름 있는 파이프 같은 네트워크 자원에 접근하는 핵심 프로토콜이다. Windows 클라이언트는 SMB 클라이언트 역할을 하고, 공유를 제공하는 Windows 또는 Windows Server는 SMB 서버 역할을 한다.

Microsoft는 SMB를 네트워크 파일 공유 프로토콜로 설명하며 응용 프로그램이 원격 서버의 파일을 읽고 쓰고 서비스와 통신하도록 한다.^[156]

SMB는 파일 데이터만 전송하지 않는다. 다음 기능을 제공한다.

• 파일과 디렉터리 열기
• 읽기와 쓰기
• 파일 잠금
• 변경 알림
• 공유 열거
• 사용자 인증
• 세션 관리
• 프린터 공유
• 이름 있는 파이프
• 분산 파일 시스템
• 서버 장애 조치
• 암호화와 서명

SMB 연결은 일반적으로 TCP 포트 445를 사용한다. 오래된 Windows 네트워크에서는 NetBIOS over TCP/IP의 포트도 사용되었지만 현대 SMB는 직접 호스팅된 TCP 연결을 중심으로 한다.

SMB의 주요 세대는 다음과 같이 구분된다.

SMB 1.0은 많은 오래된 명령과 브로드캐스트 기반 검색 체계를 포함하며 보안과 성능 면에서 현대 SMB보다 불리하다. 현대 Windows에서는 기본 설치에서 제거되거나 비활성화되어 있고, 오래된 장치와 프로그램을 위해 선택적으로만 설치할 수 있다.

SMB 클라이언트와 서버는 연결할 때 서로 지원하는 프로토콜 버전을 협상한다. 양쪽이 지원하는 가장 적합한 방언을 선택하고, 이후 기능과 보안 요구 사항을 교환한다.

SMB 세션은 일반적으로 다음 순서로 만들어진다.

SMB 공유 연결 흐름

1. 클라이언트가 서버 이름을 DNS로 해석
   ↓
2. TCP 445번 포트로 연결
   ↓
3. 지원되는 SMB 버전과 기능 협상
   ↓
4. Kerberos 또는 NTLM로 사용자 인증
   ↓
5. SMB 세션 생성
   ↓
6. 대상 공유에 트리 연결
   ↓
7. 파일 열기와 접근 권한 검사
   ↓
8. 읽기, 쓰기와 잠금 요청 처리

도메인 환경에서는 클라이언트와 서버가 조건을 충족하면 Kerberos 인증이 사용된다. 서버 이름, 서비스 사용자와 Active Directory의 서비스 사용자 이름 등록이 올바르지 않으면 NTLM로 대체되거나 인증이 실패할 수 있다.

SMB 서명은 SMB 메시지에 암호학적 서명을 추가해 전송 중 변조와 중간자 공격을 탐지한다. 클라이언트와 서버는 정책에 따라 서명을 지원하거나 필수로 요구할 수 있다.

SMB 암호화는 SMB 데이터 전체를 암호화하여 신뢰할 수 없는 네트워크에서 도청과 변조를 방지한다. 공유별, 서버 전체 또는 클라이언트 연결별로 요구할 수 있다.

Microsoft는 SMB 암호화가 SMB 데이터에 종단 간 암호화를 제공하며 공유별, 파일 서버 전체 또는 매핑된 드라이브별로 구성할 수 있다고 설명한다.^[157]

SMB 암호화는 IPsec이나 VPN과 별개로 SMB 프로토콜 자체에서 적용된다. VPN과 함께 사용할 수도 있지만, 암호화에 따른 CPU와 처리 비용을 고려해야 한다.

SMB Multichannel은 클라이언트와 서버 사이에 여러 네트워크 연결을 동시에 사용한다. 여러 어댑터, RSS 큐와 고속 네트워크 경로를 활용하여 처리량과 장애 복원력을 높일 수 있다.

하나의 네트워크 경로가 끊어져도 다른 연결을 통해 SMB 세션을 유지할 수 있으며, 여러 경로에 데이터를 분산하여 대역폭을 합칠 수 있다.

SMB Direct는 RDMA를 지원하는 네트워크 어댑터를 이용해 낮은 CPU 사용량과 낮은 지연으로 메모리 사이에 데이터를 전송한다. Hyper-V, Storage Spaces Direct와 고성능 파일 서버에서 사용된다.

지속적 가용성 공유는 장애 조치 클러스터의 노드나 네트워크 경로가 바뀌더라도 응용 프로그램의 파일 핸들을 유지하도록 한다. Hyper-V 가상 디스크와 데이터베이스처럼 연결 중단에 민감한 작업에 사용된다.

SMB 압축은 파일을 전송하기 전에 압축하여 네트워크 사용량을 줄일 수 있다. 압축 가능한 큰 파일을 상대적으로 느린 네트워크로 전송할 때 유용하며, 파일을 별도 압축 형식으로 저장하지 않고 전송 과정에만 적용한다.

SMB 서버는 접근 기반 열거를 사용해 사용자가 접근할 수 없는 공유 또는 디렉터리 항목을 목록에서 숨길 수 있다. 이는 ACL 자체를 대체하지 않으며, 실제 접근 권한 검사는 별도로 수행된다.

SMB는 Windows 외의 운영체제에서도 구현된다. Samba는 Linux와 UNIX 계열에서 SMB 클라이언트와 서버 기능을 제공하며 Windows 파일 공유와 Active Directory 환경에 통합될 수 있다.

원격 데스크톱

원격 데스크톱 프로토콜 또는 RDP는 원격 컴퓨터의 Windows 세션 화면, 입력, 오디오와 일부 장치를 네트워크를 통해 전달하는 프로토콜이다. 사용자는 다른 컴퓨터에서 Windows 데스크톱에 로그인하고 해당 컴퓨터의 응용 프로그램과 파일을 직접 사용하는 것처럼 조작할 수 있다.

원격 데스크톱은 화면을 영상으로 단순 전송하는 방식만 사용하지 않는다. 운영체제와 클라이언트는 그래픽 명령, 화면 영역, 입력, 오디오와 장치 채널을 협상하여 네트워크 상태에 맞게 전달한다.

Windows 클라이언트 에디션에서는 지원되는 에디션의 PC가 원격 데스크톱 호스트가 될 수 있다. 다른 장치에서는 Windows App이나 Microsoft Remote Desktop 계열 클라이언트를 사용해 연결한다.

Microsoft는 원격 데스크톱을 원격 장치에서 Windows PC에 연결하고 제어하는 기능으로 설명한다.^[158]

RDP는 기본적으로 TCP와 UDP 3389번 포트를 사용할 수 있다. TCP는 연결과 신뢰성 있는 전송을 제공하고, 지원되는 환경에서는 UDP를 함께 사용해 화면과 입력의 지연을 줄인다.

원격 데스크톱 연결은 다음 기능을 전달할 수 있다.

• 화면과 그래픽
• 키보드와 마우스
• 오디오 재생과 녹음
• 클립보드
• 로컬 드라이브
• 프린터
• 스마트 카드
• USB와 일부 장치
• 시간대
• 카메라와 마이크
• 다중 모니터
• 원격 세션의 해상도와 배율

장치와 자원 리디렉션은 편의성을 높이지만 원격 호스트와 로컬 컴퓨터 사이의 데이터 이동 경로가 된다. 조직은 그룹 정책으로 클립보드, 드라이브, 프린터와 장치 리디렉션을 제한할 수 있다.

네트워크 수준 인증 또는 NLA는 전체 원격 데스크톱 세션을 만들기 전에 사용자를 인증한다. 인증되지 않은 연결이 로그인 화면과 세션 자원을 소비하는 범위를 줄이고 일부 공격을 완화한다.

원격 데스크톱은 TLS와 CredSSP를 이용해 연결과 자격 증명 전달을 보호할 수 있다. 도메인 환경에서는 Kerberos가 사용될 수 있고, 인증서 구성이 올바르지 않으면 서버 신원을 완전히 검증하지 못한다는 경고가 표시될 수 있다.

Remote Credential Guard는 도메인 자격 증명을 원격 컴퓨터에 직접 보내지 않고 원본 장치가 인증 요청을 대신 처리하도록 한다. 원격 컴퓨터가 침해되었을 때 재사용 가능한 자격 증명이 탈취되는 범위를 줄인다.

Windows Server의 Remote Desktop Services 또는 RDS는 여러 사용자에게 중앙의 Windows 데스크톱과 응용 프로그램을 제공하는 서버 플랫폼이다. Microsoft는 RDS를 관리되는 데스크톱과 응용 프로그램을 사용자에게 안전하게 제공하는 Windows Server 내장 플랫폼으로 설명한다.^[159]

RDS는 다음 배포 모델을 지원한다.

• 여러 사용자가 한 서버를 공유하는 세션 기반 데스크톱
• 개인 또는 풀 방식 가상 데스크톱
• 전체 데스크톱
• 개별 응용 프로그램만 표시하는 RemoteApp
• 내부망과 인터넷을 연결하는 게이트웨이
• 웹 기반 응용 프로그램 및 데스크톱 게시

주요 RDS 역할은 다음과 같다.

RD Gateway는 RDP 트래픽을 HTTPS 기반 터널로 전달하여 내부 서버의 3389번 포트를 인터넷에 직접 공개하지 않고 원격 연결을 제공한다. 연결 정책과 자원 권한 정책을 이용해 사용자와 접근 가능한 내부 컴퓨터를 제한한다.

RDS 환경에서는 사용자 세션이 서버에서 실행되고 화면과 입력만 네트워크를 통해 전달된다. 응용 프로그램과 데이터 처리가 데이터센터에 남으므로 중앙 관리와 데이터 보호에 유리하지만, 서버 용량과 네트워크 품질에 따라 사용자 경험이 달라진다.

원격 데스크톱 포트를 인터넷에 직접 공개하면 암호 추측, 취약점 공격과 계정 탈취의 대상이 될 수 있다. 조직 환경에서는 VPN, RD Gateway, 다단계 인증, 계정 잠금 정책과 접근 제어를 함께 사용한다.

도메인 네트워크

Windows의 도메인 네트워크는 Active Directory의 사용자, 컴퓨터와 서비스 정체성을 DNS, Kerberos, LDAP, SMB와 그룹 정책에 연결한다. 도메인에 가입된 컴퓨터는 독립된 로컬 계정만 사용하는 작업 그룹 컴퓨터와 달리 중앙 디렉터리에서 인증과 정책을 받을 수 있다.

컴퓨터를 Active Directory 도메인에 가입하면 디렉터리에 컴퓨터 계정이 만들어지고, 컴퓨터와 도메인 사이에 보안 채널을 형성하기 위한 암호가 설정된다. 이 컴퓨터 계정은 사용자 계정과 별개의 보안 주체다.

Microsoft는 도메인 가입을 컴퓨터를 Active Directory 도메인에 추가하여 중앙 관리와 인증을 사용할 수 있게 하는 과정으로 설명한다.^[160]

도메인 가입 컴퓨터는 부팅과 로그인 과정에서 다음 서비스를 사용한다.

• DNS
• Kerberos
• LDAP
• Netlogon
• SMB
• 그룹 정책
• 시간 동기화
• 도메인 컨트롤러 검색
• 인증서와 공개 키 기반 서비스

DNS는 Active Directory에서 단순한 이름 해석보다 중요한 역할을 한다. 도메인 컨트롤러는 LDAP, Kerberos와 전역 카탈로그 같은 서비스 위치를 DNS SRV 레코드로 등록하고, 클라이언트는 이를 조회해 가까운 도메인 컨트롤러를 찾는다.

도메인 이름을 인터넷의 공개 DNS 서버로만 조회하도록 구성하면 도메인 컨트롤러 서비스 레코드를 찾지 못해 로그인, 도메인 가입과 그룹 정책이 실패할 수 있다. 도메인 클라이언트는 일반적으로 Active Directory DNS 영역을 제공하는 내부 DNS 서버를 사용한다.

Kerberos는 Windows 도메인의 기본 인증 프로토콜이다. 사용자가 로그인하면 도메인 컨트롤러의 키 배포 센터에서 티켓 부여 티켓을 받고, 이후 파일 서버나 응용 프로그램에 접근할 때 해당 서비스용 티켓을 요청한다.

Kerberos는 사용자의 암호를 각 서비스에 반복해서 보내지 않고 티켓을 사용한다. 클라이언트와 서비스가 서로의 정체성을 확인하는 상호 인증과 위임을 지원한다.

서비스는 서비스 사용자 이름 또는 SPN으로 식별된다. SPN은 특정 서비스 인스턴스를 실행하는 계정과 연결된다. 잘못되거나 중복된 SPN은 Kerberos 인증을 방해하고 NTLM 대체 또는 연결 실패를 일으킬 수 있다.

Active Directory는 Windows 도메인에서 Kerberos 키 배포 센터 역할을 한다.^[161]

도메인 인증에는 시간 동기화가 중요하다. Kerberos는 재전송 공격을 막기 위해 티켓과 인증 메시지의 시각을 검사하므로 클라이언트, 서버와 도메인 컨트롤러의 시간이 허용 범위를 크게 벗어나면 인증이 실패할 수 있다.

NTLM은 Kerberos를 사용할 수 없는 일부 상황과 오래된 프로그램을 위한 인증 프로토콜로 남아 있다. IP 주소로 서버에 접근하거나 SPN이 없고, 도메인 신뢰 조건을 충족하지 못하면 NTLM이 사용될 수 있다.

조직은 NTLM 사용을 감사하고 제한하며 가능한 서비스에서 Kerberos, 인증서, Windows Hello for Business와 현대적인 인증 방식을 우선할 수 있다.

도메인에 가입된 컴퓨터는 보안 채널을 통해 도메인 컨트롤러와 통신한다. 컴퓨터 계정 암호는 주기적으로 갱신되며, 컴퓨터와 Active Directory의 암호 상태가 달라지면 신뢰 관계 오류가 발생할 수 있다.

도메인 사용자가 로그인하면 다음 과정이 수행된다.

Windows 도메인 로그인과 네트워크 접근

1. 컴퓨터가 DNS로 도메인 컨트롤러 검색
   ↓
2. 사용자가 도메인 자격 증명 제출
   ↓
3. 도메인 컨트롤러가 Kerberos 인증 수행
   ↓
4. 사용자 그룹과 정책 정보 확인
   ↓
5. 로컬 컴퓨터가 사용자 접근 토큰 생성
   ↓
6. 컴퓨터 및 사용자 그룹 정책 적용
   ↓
7. 사용자가 SMB와 다른 도메인 서비스에 티켓으로 접근

도메인 컨트롤러에 연결할 수 없을 때 Windows는 이전에 성공한 도메인 로그인의 캐시된 자격 증명을 이용해 제한적으로 로그인할 수 있다. 이 경우 새 암호, 그룹 변경과 네트워크 서비스 인증은 도메인 컨트롤러에 다시 연결될 때까지 반영되지 않을 수 있다.

도메인 네트워크는 Active Directory 사이트와 서브넷을 사용해 물리적 네트워크 구조를 표현한다. 클라이언트는 같은 사이트의 가까운 도메인 컨트롤러를 우선 사용하고, 도메인 컨트롤러 복제도 사이트 연결과 비용을 기준으로 조정된다.

Windows 방화벽의 도메인 프로필은 컴퓨터가 신뢰할 수 있는 도메인 네트워크를 인증했을 때 적용된다. 단순히 네트워크 이름이 같거나 내부 IP 주소를 사용한다는 이유만으로 도메인 프로필이 적용되는 것은 아니다.

도메인 네트워크에는 반드시 모든 장치가 같은 로컬 네트워크에 있을 필요는 없다. 지사, VPN, 광역망과 클라우드 네트워크를 통해 도메인 컨트롤러에 연결할 수 있으며, 네트워크 지연과 방화벽 정책을 고려해 사이트와 서비스를 배치한다.

무선과 모바일 네트워크

Windows는 Wi-Fi, Wi-Fi Direct, Bluetooth 네트워크, 셀룰러 광대역과 모바일 핫스폿을 지원한다. 사용자는 설정 앱과 빠른 설정에서 네트워크를 검색하고 연결하며, 조직은 그룹 정책과 MDM을 통해 프로필과 인증 정보를 배포할 수 있다.

Wi-Fi 연결은 무선 네트워크 어댑터와 WLAN AutoConfig 서비스를 통해 관리된다. 서비스는 무선 네트워크 검색, 프로필, 인증, 연결, 로밍과 보안 설정을 처리한다.

Wi-Fi 프로필에는 다음 정보가 포함될 수 있다.

• SSID
• 자동 연결 여부
• 네트워크 보안 방식
• 암호화 방식
• 사전 공유 키
• 802.1X 인증 정보
• 사용자 또는 컴퓨터 인증 방식
• 임의 하드웨어 주소 정책
• 네트워크 비용과 사용 정책

Windows는 개방형 네트워크, WPA2와 WPA3 같은 무선 보안 방식을 지원한다. 실제 사용 가능한 규격은 네트워크 어댑터, 드라이버, Windows 버전과 액세스 포인트에 따라 달라진다.

가정과 소규모 환경에서는 일반적으로 사전 공유 키를 사용하는 개인용 보안 방식이 사용된다. 기업 환경에서는 802.1X와 EAP를 이용해 사용자, 컴퓨터, 인증서 또는 스마트 카드를 인증할 수 있다.

기업용 무선 연결은 다음 구성 요소와 결합될 수 있다.

• Active Directory
• RADIUS와 Network Policy Server
• 사용자 또는 컴퓨터 인증서
• EAP-TLS
• PEAP
• 그룹 정책 무선 프로필
• Microsoft Intune Wi-Fi 정책
• 조건부 액세스와 장치 규정 준수

사용자는 무선 네트워크를 공용 또는 개인 네트워크로 지정할 수 있다. 공용 프로필은 네트워크 검색, 공유와 인바운드 연결을 더 제한하는 방화벽 정책을 사용한다.

Windows는 저장된 Wi-Fi 네트워크 프로필을 바탕으로 자동 연결할 수 있다. 여러 네트워크가 사용 가능하면 연결 우선순위, 신호 품질, 사용자 선택과 정책을 고려한다.

임의 하드웨어 주소는 네트워크 검색 또는 연결 과정에서 무선 어댑터의 실제 MAC 주소 대신 임시 주소를 사용하여 여러 장소에서 장치를 추적하기 어렵게 만든다. 지원 여부는 어댑터와 드라이버에 따라 달라진다.

Wi-Fi Direct는 기존 무선 액세스 포인트 없이 장치끼리 직접 무선 연결을 만드는 기술이다. 무선 디스플레이, 프린터, 주변 장치 연결과 모바일 핫스폿의 일부 기능에 사용된다.

Microsoft는 Windows가 Wi-Fi Direct 기반 장치 연결을 지원하며 모바일 핫스폿이 Windows 10 버전 1607부터 지원된다고 설명한다.^[162]

모바일 핫스폿은 Windows 컴퓨터의 인터넷 연결을 Wi-Fi 또는 지원되는 방식으로 다른 장치에 공유한다. Ethernet, Wi-Fi 또는 셀룰러 연결을 원본으로 사용할 수 있으며, Windows가 가상 무선 네트워크와 NAT를 구성한다.

모바일 핫스폿과 기존 Wi-Fi Direct 그룹 소유자 기능은 같은 무선 어댑터 자원을 공유하므로 동시에 사용할 수 있는 범위가 제한될 수 있다. Microsoft 문서에서는 모바일 핫스폿이 다른 Wi-Fi Direct 시나리오보다 우선한다고 설명한다.^[163]

셀룰러 네트워크는 내장 또는 외장 모뎀과 SIM 또는 eSIM을 통해 이동통신망에 연결한다. Windows는 모바일 광대역 인터페이스를 이용해 연결 상태, 통신사, 신호, 데이터 사용량과 로밍을 관리한다.

셀룰러 연결은 다음 기능을 포함할 수 있다.

• SIM과 eSIM 관리
• PIN 잠금
• 통신사 프로필
• APN 설정
• 로밍
• 데이터 사용량 추적
• 종량제 연결
• 자동 또는 수동 연결
• 이동통신사 응용 프로그램
• SMS와 통신사 알림
• 4G와 5G 연결

Windows는 Wi-Fi를 사용할 수 없을 때 셀룰러 네트워크를 자동으로 사용할 수 있고, 셀룰러 연결의 데이터 비용을 고려해 종량제 네트워크로 분류할 수 있다.

종량제 연결은 데이터 사용량에 제한이나 비용이 있는 네트워크임을 Windows와 응용 프로그램에 알린다. Windows Update, Microsoft Store, 클라우드 동기화와 백그라운드 다운로드는 종량제 상태에 따라 데이터 사용을 줄이거나 사용자의 확인을 요구할 수 있다.

응용 프로그램은 Windows 네트워크 비용 API를 통해 현재 연결이 무제한, 고정 한도, 가변 비용 또는 로밍 연결인지 확인하고 대용량 전송을 조정할 수 있다.

Windows는 Ethernet, Wi-Fi와 셀룰러가 동시에 연결된 경우 인터페이스 메트릭, 경로, 정책과 연결 상태를 이용해 트래픽을 보낼 인터페이스를 선택한다. 특정 VPN이나 응용 프로그램은 별도의 경로와 인터페이스를 사용할 수 있다.

VPN은 공용 네트워크 위에 조직 또는 사설 네트워크로 이어지는 논리적 터널을 만든다. Windows는 IKEv2, SSTP, L2TP/IPsec와 일부 환경의 PPTP를 포함한 VPN 프로토콜을 지원해 왔으며, 타사 VPN 플러그인과 클라이언트도 사용할 수 있다.

조직은 VPN 프로필, 인증서, DNS, 라우팅과 자동 연결 조건을 그룹 정책이나 MDM으로 배포할 수 있다. 특정 응용 프로그램이나 도메인 접근 시 자동으로 연결되는 Always On VPN 구성도 사용할 수 있다.

무선과 모바일 연결은 편리하지만 신뢰할 수 없는 네트워크에서 사용될 가능성이 높다. Windows는 공용 방화벽 프로필, HTTPS, VPN, SMB 암호화와 임의 하드웨어 주소를 제공하며, 사용자는 공개 네트워크에서 불필요한 검색과 파일 공유를 비활성화할 수 있다.

Windows의 그래픽과 멀티미디어 체계는 전통적인 2차원 업무용 화면 출력부터 합성 데스크톱, 실시간 3차원 그래픽, 저지연 오디오, 영상 재생·인코딩과 게임 실행까지 여러 세대의 기술을 함께 포함한다.

초기의 Windows 응용 프로그램은 주로 Graphics Device Interface를 통해 화면과 프린터에 텍스트와 도형을 출력했다. 이후 DirectX가 게임과 고성능 멀티미디어를 위한 하드웨어 가속 인터페이스를 제공했고, Windows Vista부터는 Desktop Window Manager가 각 창의 결과를 GPU로 합성하는 구조가 기본이 되었다.

오디오에서는 Core Audio, WASAPI와 XAudio2가 장치 접근, 응용 프로그램별 음량, 믹싱과 게임 음향을 담당한다. 영상과 미디어 처리에는 Media Foundation, Windows Imaging Component와 여러 코덱 및 하드웨어 가속 인터페이스가 사용된다.

Windows 그래픽과 멀티미디어의 주요 구성

• 응용 프로그램
  • 업무용 및 데스크톱 응용 프로그램
    • GDI와 GDI+
    • Direct2D
    • DirectWrite
  • 게임과 실시간 그래픽
    • Direct3D
    • DXGI
    • DirectML
    • XAudio2
    • XInput
  • 오디오 응용 프로그램
    • Core Audio
    • WASAPI
    • Media Foundation
    • MIDI와 공간 음향
  • 영상과 미디어 응용 프로그램
    • Media Foundation
    • Windows Imaging Component
    • 하드웨어 영상 가속
    • 코덱과 미디어 변환
      • Windows 그래픽 및 미디어 계층
        • Desktop Window Manager
        • Windows Audio Engine
        • 미디어 파이프라인
        • WDDM 드라이버
          • GPU, 디스플레이, 오디오와 미디어 하드웨어

이 기술들은 완전히 분리되어 있지 않다. 게임은 Direct3D로 화면을 만들고 XAudio2로 소리를 재생하며 Media Foundation으로 영상을 디코딩할 수 있다. 데스크톱 응용 프로그램도 GDI로 일부 인터페이스를 그리고 Direct3D로 고성능 콘텐츠를 렌더링한 뒤 DWM을 통해 최종 화면에 합성할 수 있다.

Graphics Device Interface

Graphics Device Interface 또는 GDI는 초기 Windows부터 제공된 2차원 그래픽 출력 인터페이스다. 응용 프로그램이 특정 그래픽 카드나 프린터의 명령 형식을 직접 구현하지 않고, 공통된 도형과 텍스트 출력 명령을 사용하도록 한다.

Microsoft는 GDI가 응용 프로그램에서 화면과 프린터 모두에 그래픽과 서식 있는 텍스트를 출력할 수 있게 한다고 설명한다.^[164]

GDI는 다음과 같은 출력 기능을 제공한다.

• 선과 곡선
• 사각형, 타원과 다각형
• 비트맵
• 텍스트와 글꼴
• 채우기 패턴과 브러시
• 펜과 선 스타일
• 클리핑 영역
• 색상 변환
• 프린터 출력
• 메타파일

GDI의 핵심 추상화는 장치 컨텍스트 또는 DC다. 장치 컨텍스트는 출력 대상과 현재 그래픽 상태를 나타내는 객체이며, 화면의 창, 메모리 비트맵이나 프린터를 대상으로 할 수 있다.

장치 컨텍스트에는 다음과 같은 상태가 저장된다.

• 현재 펜
• 브러시
• 글꼴
• 텍스트 색
• 배경 모드
• 클리핑 영역
• 좌표 변환
• 그리기 모드
• 출력 장치의 해상도와 기능

응용 프로그램은 동일하거나 유사한 GDI 호출을 사용해 화면과 프린터에 출력할 수 있다. 실제 장치의 해상도, 색상과 출력 능력은 장치 컨텍스트와 드라이버가 처리한다.

GDI 출력의 기본 흐름

1. 응용 프로그램이 장치 컨텍스트 획득
   ↓
2. 펜, 브러시, 글꼴과 클리핑 상태 선택
   ↓
3. 선, 텍스트, 비트맵 등의 GDI 함수 호출
   ↓
4. GDI가 논리 좌표와 장치 특성을 변환
   ↓
5. 화면 또는 프린터 드라이버로 출력 전달
   ↓
6. 대상 장치에 결과 표시

전통적인 Win32 창은 다시 그리기가 필요할 때 WM_PAINT 메시지를 받는다. 응용 프로그램은 유효하지 않은 영역의 장치 컨텍스트를 얻고 해당 영역을 다시 그린다.

GDI는 즉시 모드 인터페이스다. 운영체제가 응용 프로그램의 전체 장면 구조를 보관하기보다, 응용 프로그램이 화면을 다시 그릴 때 출력 명령을 다시 실행한다.

GDI 비트맵 작업에는 BitBlt와 StretchBlt 같은 비트 블록 전송 함수가 사용된다. 메모리 장치 컨텍스트에 먼저 화면을 그리고 한 번에 창으로 복사하면 깜빡임을 줄이는 이중 버퍼링을 구현할 수 있다.

GDI는 장치 독립성을 중요한 목표로 삼았지만 모든 장치가 같은 출력 품질과 기능을 제공하는 것은 아니다. 프린터와 화면은 색상, 해상도와 래스터 연산 지원이 다르며, 응용 프로그램은 장치 기능을 확인해 출력 방식을 조정할 수 있다.

GDI+는 Windows XP 시기에 도입된 GDI의 후속 2차원 그래픽 API다. 부동소수점 좌표, 알파 블렌딩, 안티앨리어싱, 이미지 디코딩, 경로와 더 발전된 색상 처리를 제공한다.

Microsoft는 GDI+를 2차원 벡터 그래픽, 영상 처리와 타이포그래피를 제공하는 Windows 구성 요소로 설명한다.^[165]

현대 Windows에서 GDI는 다음 분야에 계속 사용된다.

• 기존 Win32 응용 프로그램
• 업무용 사용자 인터페이스
• 일부 시스템 관리 도구
• 프린터 출력
• 호환성이 중요한 응용 프로그램
• 오래된 게임과 도구
• 다른 UI 프레임워크의 일부 내부 처리

그러나 GDI는 현대적인 고성능 3차원 그래픽이나 대규모 애니메이션에 적합한 API가 아니다. Direct2D와 DirectWrite는 GPU 가속 2차원 그래픽과 고품질 텍스트를 제공하고, Direct3D는 게임과 실시간 3차원 렌더링에 사용된다.

DirectX

DirectX는 Windows와 Xbox에서 그래픽, 오디오, 입력, 미디어와 게임 관련 하드웨어 기능을 제공하는 API 계열이다. 하나의 단일 라이브러리가 아니라 여러 기술과 런타임을 포괄하는 이름이다.

Microsoft의 DirectX 문서는 Direct3D가 게임과 과학 응용 프로그램을 위한 3차원 그래픽을 제공하고, Direct2D가 고성능 2차원 그래픽을 제공한다고 설명한다.^[166]

DirectX의 주요 구성 요소는 다음과 같다.

과거 DirectX에는 DirectDraw, DirectSound, DirectInput, DirectPlay와 DirectShow 같은 구성 요소가 포함되었다. 이 가운데 여러 기술은 유지 보수 또는 호환성 상태가 되었고, 새로운 응용 프로그램에는 Direct3D, XAudio2, XInput, Windows 네트워크 API와 Media Foundation 같은 후속 기술이 사용된다.

Direct3D는 게임 엔진이 GPU에 렌더링 명령, 셰이더, 텍스처와 버퍼를 전달하는 핵심 그래픽 API다. Direct3D 11은 드라이버가 상당한 자원 관리와 상태 처리를 담당하는 높은 수준의 모델을 제공하고, Direct3D 12는 명령 큐, 명령 목록, 자원 상태와 동기화를 개발자가 더 직접 제어한다.

Microsoft는 Direct3D 11을 게임, 과학 및 데스크톱 응용 프로그램에서 3차원 그래픽을 만드는 API로 설명한다.^[167]

Direct3D의 일반적인 렌더링 흐름은 다음과 같다.

Direct3D 게임 프레임의 기본 흐름

1. 게임이 입력과 시뮬레이션 상태 갱신
   ↓
2. CPU가 렌더링 명령과 자원 상태 준비
   ↓
3. 셰이더, 정점, 텍스처와 상수 데이터 설정
   ↓
4. 명령 목록 또는 그래픽 컨텍스트에 그리기 요청 기록
   ↓
5. GPU 명령 큐로 제출
   ↓
6. GPU가 셰이더와 래스터화 수행
   ↓
7. 스왑 체인의 후면 버퍼에 프레임 생성
   ↓
8. DXGI가 화면 표시를 위해 프레임 제출

DXGI는 그래픽 어댑터와 모니터 열거, 화면 형식, 스왑 체인, 전체 화면 전환과 프레임 표시를 관리한다. Direct3D 런타임과 실제 화면 출력 사이에서 공통 인프라 역할을 한다.^[168]

DirectX는 Microsoft가 Windows 게임 플랫폼을 확장하는 핵심 수단이었다. 1990년대 초반의 Windows는 업무용 그래픽 환경으로는 성장했지만, 게임은 여전히 MS-DOS에서 하드웨어에 직접 접근하는 방식을 선호했다. 초기 Windows의 보호된 실행 환경, 창 시스템과 장치 추상화는 당시 게임에서 요구하던 낮은 지연과 직접적인 화면·오디오·입력 제어에 불리하게 인식되었다.

DirectX는 게임이 각 그래픽 카드, 사운드 카드와 입력 장치의 전용 인터페이스를 직접 구현하지 않고 공통 API를 사용하도록 했다. 하드웨어 제조사는 Windows 드라이버를 제공하고, 게임 개발사는 DirectX를 대상으로 개발하는 구조가 만들어졌다.

이 구조는 다음과 같은 선순환을 형성했다.

• Windows PC 사용자가 증가했다.
• 그래픽 카드와 사운드 카드 제조사가 Windows 드라이버를 우선 제공했다.
• 게임 개발사가 DirectX를 주요 대상으로 삼았다.
• 엔진과 미들웨어가 DirectX 지원을 기본 기능으로 제공했다.
• 더 많은 게임이 Windows로 출시되었다.
• 게임 사용자가 Windows를 선택할 이유가 커졌다.

Windows는 개방된 PC 하드웨어 시장의 다양한 장치를 지원하면서도 DirectX라는 비교적 일관된 게임 API를 제공했다. 개발사는 특정 제조사의 PC 전체를 대상으로 별도의 그래픽 체계를 구현하지 않고 NVIDIA, AMD, Intel과 다른 공급사의 드라이버를 통해 같은 Direct3D 인터페이스를 사용할 수 있었다.

DirectX가 모든 하드웨어 차이를 완전히 제거한 것은 아니다. 그래픽 기능 수준, 드라이버 품질, 셰이더 컴파일, 성능과 제조사별 확장 차이는 계속 존재한다. 그러나 Windows와 GPU 제조사가 공통 API, 인증, 개발 도구와 디버깅 환경을 제공하면서 상용 PC 게임 개발의 기준점이 되었다.

DirectX는 Xbox와 Windows 사이의 기술 공유에도 사용된다. XAudio2와 여러 DirectX 구성 요소는 Windows와 Xbox 계열에서 함께 사용되었으며, Microsoft Game Development Kit는 PC와 Xbox 게임 개발에 공통된 도구와 API를 제공한다. Microsoft는 Windows 커널 계열이 데이터센터와 PC뿐 아니라 Xbox와 여러 장치 제품군에도 사용된다고 설명한다.^[169]

Desktop Window Manager

Desktop Window Manager 또는 DWM은 Windows 데스크톱의 창들을 합성하여 최종 화면을 만드는 시스템 구성 요소다. Windows Vista에서 도입되었으며, Windows 8 이후에는 데스크톱 합성이 항상 활성화되는 기본 화면 출력 체계가 되었다.

Microsoft는 Windows Vista가 DWM을 도입하면서 창을 그리는 방식을 근본적으로 변경했다고 설명한다.^[170]

DWM 이전의 전통적인 창 환경에서는 응용 프로그램이 자신의 창 영역을 화면에 직접 그리는 성격이 강했다. 창이 다른 창에 가려졌다가 다시 노출되면 응용 프로그램은 해당 영역을 다시 그려야 했다.

DWM 환경에서는 각 응용 프로그램이 자신의 창에 대응하는 오프스크린 표면에 내용을 렌더링한다. DWM은 이 표면들을 GPU를 이용해 하나의 데스크톱 화면으로 합성한다.

DWM 데스크톱 합성

1. 각 응용 프로그램이 창 표면에 내용 렌더링
   ↓
2. DWM이 모든 창의 표면 수집
   ↓
3. 위치, 크기, Z 순서와 불투명도 계산
   ↓
4. 그림자, 애니메이션, 배율과 시각 효과 적용
   ↓
5. 바탕 화면과 창을 하나의 프레임으로 합성
   ↓
6. WDDM과 GPU를 통해 모니터에 출력

DWM은 다음 기능의 기반이 된다.

• 창 투명도와 그림자
• 창 열기와 전환 애니메이션
• 작업 표시줄의 창 미리 보기
• Flip 3D와 작업 보기
• 고해상도 화면 배율
• 여러 모니터
• 창 축소판
• 창 스냅
• 화면 캡처의 일부 경로
• 고주사율과 가변 주사율 지원
• HDR 데스크톱 구성

Microsoft는 DWM이 Windows 서비스로 실행되며, 창 축소판과 합성 효과에 필요한 기능을 제공한다고 설명한다.^[171]

일반 창 모드 게임은 DWM의 데스크톱 합성 경로를 통과한다. 과거에는 전체 화면 독점 모드가 창 모드보다 지연과 성능에서 유리한 경우가 많았지만, 현대 Windows는 전체 화면 최적화와 플립 모델 스왑 체인을 통해 테두리 없는 창 모드에서도 낮은 지연과 효율적인 화면 표시를 제공할 수 있다.

DWM이 모든 게임 프레임을 단순히 복사하는 것은 아니다. 스왑 체인 형식, 화면 모드와 Windows 버전에 따라 프레임을 직접 스캔아웃에 가깝게 전달하거나 합성 과정의 복사를 줄일 수 있다.

DWM은 운영체제 셸과 동일한 구성 요소가 아니다. Explorer가 바탕 화면, 작업 표시줄과 파일 탐색기 사용자 인터페이스를 제공하고, DWM은 각 창의 최종 시각 출력을 합성한다.

오디오 시스템

Windows 오디오 시스템은 응용 프로그램의 오디오 스트림을 장치에 전달하고, 여러 프로그램의 소리를 혼합하며, 음량, 형식 변환, 효과, 공간 음향과 장치 전환을 관리한다.

현대 Windows의 기본 오디오 구조는 사용자 모드의 오디오 서비스와 엔진, 커널 스트리밍 계층, 오디오 드라이버와 실제 장치로 구성된다.

Windows 오디오의 기본 구조

• 오디오 응용 프로그램
  • WASAPI
  • XAudio2
  • Media Foundation
  • Windows Runtime 오디오 API
  • 레거시 오디오 API
    • Windows 오디오 서비스와 오디오 엔진
      • 응용 프로그램별 오디오 세션
      • 믹싱
      • 형식 변환
      • 음량과 음소거
      • 오디오 효과
        • 오디오 드라이버
          • WaveRT
          • 포트·미니포트
          • 하드웨어 오프로드
            • 스피커, 헤드폰, HDMI, USB와 Bluetooth 장치

Windows Audio Session API 또는 WASAPI는 응용 프로그램이 오디오 장치와 스트림을 낮은 수준에서 제어할 수 있게 한다. Microsoft는 WASAPI를 Windows Core Audio API의 핵심 구성 요소로 제공한다.^[172]

WASAPI 스트림은 공유 모드 또는 독점 모드로 실행할 수 있다.

• 공유 모드에서는 여러 응용 프로그램의 스트림을 Windows 오디오 엔진이 혼합한다.
• 독점 모드에서는 하나의 응용 프로그램이 장치를 직접 점유하고 장치 형식과 버퍼를 더 세밀하게 제어한다.

공유 모드는 일반적인 데스크톱 응용 프로그램, 브라우저와 게임에 편리하다. 사용자는 프로그램별 음량을 조정하고 여러 응용 프로그램의 소리를 동시에 들을 수 있다.

독점 모드는 전문 오디오, 측정과 매우 낮은 지연이 필요한 환경에서 사용될 수 있지만, 다른 응용 프로그램이 같은 장치를 사용하지 못할 수 있다.

Windows는 응용 프로그램별 오디오 세션을 관리한다. 세션마다 음량, 음소거, 표시 이름과 상태를 가질 수 있으며, 같은 응용 프로그램의 여러 스트림을 하나의 세션으로 묶을 수 있다.

XAudio2는 게임과 실시간 응용 프로그램을 위한 저수준 오디오 믹싱 API다. 소스 음성, 서브믹스 음성과 마스터링 음성을 연결한 오디오 그래프를 구성하고, 효과와 필터를 적용한다.

Microsoft는 XAudio2를 게임의 음향 효과와 배경 음악을 위한 저지연 오디오 그래프 및 믹싱 엔진으로 설명한다.^[173]

XAudio2의 기본 처리 구조는 다음과 같다.

XAudio2 오디오 처리 흐름

1. 게임이 오디오 데이터를 소스 음성에 제출
   ↓
2. 음량, 속도와 음성별 필터 적용
   ↓
3. 필요한 서브믹스와 DSP 효과 처리
   ↓
4. 여러 음성을 마스터링 음성에 혼합
   ↓
5. Windows 오디오 장치로 출력

XAudio2는 DirectSound의 후속 역할을 하며 다음 기능을 제공한다.

• 여러 음원의 동시 재생
• 저지연 버퍼 제출
• 음량과 피치 변경
• 소스별 필터
• 서브믹스
• DSP 효과
• 3차원 오디오와 연동
• 스트리밍 오디오
• 장치 변경 대응

X3DAudio는 청취자와 음원의 위치, 방향, 거리와 속도를 바탕으로 채널 음량, 도플러 효과와 거리 감쇠 계산을 지원한다.

Windows의 공간 음향은 헤드폰, 스피커와 홈시어터 환경에서 3차원 위치 기반 오디오를 제공한다. Windows Sonic, Dolby Atmos와 DTS 계열 공간 음향 구현을 선택할 수 있으며, 게임은 공간 오디오 API를 사용해 동적인 오디오 객체를 제출할 수 있다.

Bluetooth 오디오는 사용 목적에 따라 고품질 재생 프로필과 마이크를 사용하는 통화 프로필 사이에서 동작 특성이 달라질 수 있다. 장치와 Windows 버전에 따라 코덱, 지연과 동시 입력·출력 품질이 달라진다.

전문 오디오 응용 프로그램은 제조사 전용 ASIO 드라이버를 사용할 수 있다. ASIO는 Windows의 표준 오디오 API가 아니라 Steinberg가 정의한 별도 드라이버 모델이며, 낮은 지연과 직접적인 다중 채널 장치 접근을 위해 음악 제작 프로그램에서 널리 사용된다.

미디어 프레임워크

Windows는 음성, 음악, 사진과 영상을 재생·캡처·변환하기 위해 여러 미디어 기술을 제공해 왔다. 현대적인 영상과 오디오 파이프라인의 중심은 Media Foundation이다.

Microsoft는 Media Foundation을 높은 품질과 상호 운용성으로 디지털 미디어 콘텐츠를 처리하기 위한 Windows 멀티미디어 플랫폼으로 설명한다.^[174]

Media Foundation은 다음 기능을 지원한다.

• 미디어 파일 재생
• 카메라와 마이크 캡처
• 음성과 영상 인코딩
• 디코딩
• 형식 변환
• 스트리밍
• 보호된 미디어
• 하드웨어 가속
• 음성과 영상 효과
• 실시간 미디어 처리
• 미디어 메타데이터

Media Foundation의 파이프라인은 미디어 소스, 변환과 출력 대상으로 구성된다.

Media Foundation 재생 파이프라인

1. 파일, 네트워크 또는 캡처 장치에서 미디어 입력
   ↓
2. 미디어 소스가 압축된 스트림 생성
   ↓
3. 디코더 MFT가 영상과 오디오 디코딩
   ↓
4. 필요한 색상, 크기와 오디오 형식 변환
   ↓
5. 영상은 화면 출력기로 전달
   ↓
6. 오디오는 Windows 오디오 시스템으로 전달
   ↓
7. 시계에 맞춰 영상과 음성을 동기화하여 재생

Media Foundation Transform 또는 MFT는 미디어 데이터를 입력받아 변환된 데이터를 출력하는 구성 요소다. 디코더, 인코더, 색상 변환기, 크기 조정기와 오디오 효과를 구현할 수 있다.

Microsoft는 MFT를 Media Foundation의 미디어 처리 모델로 제공하며, 많은 응용 프로그램에서는 파이프라인이 적절한 MFT를 자동으로 선택할 수 있다고 설명한다.^[175]

Media Foundation은 하드웨어 영상 디코더와 인코더를 사용할 수 있다. GPU나 전용 미디어 엔진이 H.264, HEVC, AV1과 다른 형식을 지원하면 CPU 사용량과 전력 소비를 줄일 수 있다.

실제 코덱 지원은 Windows 에디션, 장치 하드웨어와 설치된 확장 기능에 따라 달라질 수 있다. 일부 코덱은 Microsoft Store의 미디어 확장 패키지나 장치 제조사의 구성 요소로 제공된다.

Media Foundation 이전에는 DirectShow가 Windows 멀티미디어 처리의 중심 기술이었다. DirectShow는 필터 그래프를 이용해 소스, 디코더, 변환기와 렌더러를 연결한다.

DirectShow는 많은 기존 카메라, 캡처 카드, 코덱과 미디어 프로그램에서 계속 사용되지만, 새로운 Windows 미디어 응용 프로그램에는 Media Foundation이 일반적인 선택이다.

Windows Media Foundation과 Windows Media Format SDK는 이름이 비슷하지만 같은 범위가 아니다. Windows Media Format SDK는 주로 Windows Media Audio와 Video 및 ASF 형식에 초점을 맞췄고, Media Foundation은 더 넓은 현대 미디어 파이프라인이다.

Windows Imaging Component 또는 WIC는 정지 영상의 디코딩, 인코딩, 픽셀 형식 변환과 메타데이터를 제공한다. JPEG, PNG, TIFF와 여러 이미지 형식을 응용 프로그램에서 공통 인터페이스로 처리하게 한다.

게임은 Media Foundation이나 자체 코덱 라이브러리를 이용해 시작 영상, 컷신, 음성 스트리밍과 실시간 캡처를 처리할 수 있다. Xbox Game Bar와 캡처 기능도 그래픽과 미디어 인코딩 계층을 이용해 게임 화면을 녹화한다.

게임 지원

Windows는 범용 개인용 컴퓨터 운영체제이지만, PC 게임 시장에서는 오랫동안 가장 중요한 플랫폼으로 자리 잡았다. 그 원인은 단순히 DirectX 하나에 있지 않으며, 운영체제 점유율, 하드웨어 공급망, 개발 도구, 배포 플랫폼, 엔진, 미들웨어와 과거 호환성이 결합된 결과다.

Steam의 하드웨어 및 소프트웨어 조사는 현재도 Windows, macOS와 Linux 사용 비율을 월별로 집계하며, Windows가 Steam PC 환경의 압도적인 주류임을 보여준다.^[176]

Windows가 PC 게임 플랫폼의 중심이 된 주요 원인은 다음과 같다.

기존 사용자 기반

1990년대 이후 가정과 업무용 PC에서 Windows가 대규모 사용자 기반을 확보했다. 게임 개발사 입장에서는 별도의 게임 전용 컴퓨터를 판매하지 않고 이미 보급된 Windows PC를 대상으로 게임을 출시할 수 있었다.

Windows PC는 여러 제조사가 생산했으므로 저가형 컴퓨터부터 고성능 게임용 PC까지 넓은 가격대가 형성되었다. 사용자는 같은 운영체제에서 업무, 인터넷과 게임을 함께 사용할 수 있었다.

DirectX와 드라이버 생태계

DirectX는 그래픽, 입력과 오디오를 공통 API로 제공했고, GPU와 주변 장치 제조사는 Windows용 드라이버를 우선 개발했다. 새로운 그래픽 기능이 등장하면 Microsoft, GPU 제조사, 게임 엔진과 게임 개발사가 Direct3D를 중심으로 기능을 통합했다.

DirectX는 API뿐 아니라 다음 요소를 함께 제공했다.

• 셰이더 컴파일러
• 디버그 계층
• 그래픽 진단 도구
• GPU 제조사 개발 도구와의 연동
• 기능 수준과 장치 기능 조회
• Xbox와 Windows의 기술 공유
• Visual Studio와 Windows SDK
• 장기적인 이전 API 호환성

Direct3D 12 Agility SDK는 일부 최신 Direct3D 기능을 Windows 전체 기능 업데이트와 분리하여 게임에 배포할 수 있게 한다. 이를 통해 게임 개발사는 지원되는 Windows 버전을 유지하면서 새로운 그래픽 기능을 더 빠르게 사용할 수 있다.

상용 게임 엔진과 미들웨어

Unreal Engine, Unity와 여러 자체 엔진은 Windows를 주요 편집기 및 실행 대상으로 지원했다. 물리, 오디오, 영상, 입력, 네트워크, 복사 방지와 분석 도구도 Windows용 구현을 우선 제공하는 경우가 많았다.

게임 개발 과정 자체가 Windows 중심으로 구성된 경우도 많았다. 아트 도구, 디버거, 콘솔 SDK, 빌드 시스템과 테스트 장비 관리 프로그램이 Windows를 기본 환경으로 사용하면서 결과물도 Windows를 우선 대상으로 삼게 되었다.

배포와 상업 생태계

광학 디스크와 패키지 게임 시대에는 Windows PC용 설치 프로그램과 DirectX 런타임이 표준적인 배포 형태로 자리 잡았다. 이후 Steam, Epic Games Store, GOG, Microsoft Store와 각 퍼블리셔의 런처가 Windows 게임 시장을 확대했다.

Windows는 여러 상점과 독립적인 배포를 모두 허용한다. 개발사는 특정 단일 상점만 사용하지 않고 자체 웹사이트, 패키지, 여러 디지털 상점과 구독 서비스를 선택할 수 있다.

하위 호환성

Windows는 오래된 Win32, DirectX와 x86 응용 프로그램을 장기간 실행할 수 있도록 유지했다. 일부 게임은 추가 수정이 필요하지만, 수십 년 전의 게임이 현대 Windows에서 직접 또는 호환성 설정과 커뮤니티 패치로 실행되는 경우가 많다.

사용자는 새 컴퓨터와 Windows 버전에서도 기존 게임 라이브러리를 유지할 수 있었고, 게임 상점은 오래된 Windows 게임을 다시 판매할 수 있었다.

게임 전용 시스템 기능

Windows에는 게임 실행과 관련된 다음 기능이 추가되어 왔다.

• Game Mode
• Xbox Game Bar
• 게임 캡처와 방송
• HDR와 Auto HDR
• 가변 주사율
• 하드웨어 가속 GPU 스케줄링
• DirectStorage
• 공간 음향
• Xbox 컨트롤러 지원
• Xbox 네트워크와 계정 연동
• PC Game Pass
• 창 모드 게임 최적화
• 그래픽 성능 기본 설정

Game Mode는 게임 실행 중 시스템 자원을 게임에 더 안정적으로 제공하도록 조정하며, Microsoft는 대부분의 Windows 게임에 기본적으로 적용된다고 설명한다.^[177]

DirectStorage는 NVMe SSD 같은 고속 저장 장치에서 많은 작은 자원을 낮은 CPU 부하로 읽도록 설계되었다. 대규모 게임의 텍스처와 모델 스트리밍 시간을 줄이는 데 사용될 수 있다.^[178]

UNIX와 Linux가 PC 게임 시장을 먼저 장악하지 못한 이유

UNIX 계열 운영체제가 게임에 기술적으로 부적합해서 PC 게임 시장을 잡지 못한 것은 아니다. PlayStation과 Nintendo 기기처럼 UNIX·BSD 계열 코드나 구조를 사용하는 게임기가 존재하고, Linux는 서버, 임베디드 시스템과 게임 전용 장치에서 높은 성능을 제공할 수 있다.

PC 게임 시장에서 Linux와 전통적인 UNIX가 Windows보다 뒤처진 것은 주로 생태계의 형성 시점과 상업적 우선순위 때문이었다.

1990년대 상용 UNIX 워크스테이션은 그래픽 성능이 높았지만 가격이 비쌌고, 서로 다른 제조사와 하드웨어 플랫폼으로 나뉘어 있었다. 일반 가정용 x86 PC 게임 시장과는 대상 고객과 유통 구조가 달랐다.

초기 Linux는 서버, 개발과 자유 소프트웨어 환경을 중심으로 성장했다. 가정용 PC에서의 점유율이 작았기 때문에 상용 게임 개발사는 Windows용 게임을 먼저 제작했고, GPU 제조사는 Windows 드라이버에 더 많은 자원을 투입했다.

이 과정에서 다음과 같은 순환이 만들어졌다.

Windows 중심 PC 게임 생태계의 고착

1. Windows 사용자가 많음
   ↓
2. 게임사가 Windows를 우선 지원
   ↓
3. GPU와 주변 장치 제조사가 Windows 드라이버를 우선 개발
   ↓
4. 엔진과 미들웨어가 Windows 기능을 기준으로 발전
   ↓
5. Windows에서 게임 호환성과 성능이 가장 안정적이 됨
   ↓
6. 게임 사용자가 Windows를 계속 선택

Linux에서는 배포판마다 라이브러리 버전, 패키지, 데스크톱 환경과 시스템 구성이 달랐다. 게임 실행 파일을 장기간 배포하려면 배포판 간 ABI 차이와 의존성 문제를 처리해야 했다.

Windows도 하드웨어와 드라이버 조합이 다양하지만, Win32와 DirectX라는 공통 응용 프로그램 및 그래픽 인터페이스가 있었다. Linux에서는 OpenGL과 이후 Vulkan이 공통 그래픽 API를 제공했지만, 게임 전체에 필요한 오디오, 입력, 창 시스템, 설치, 복사 방지와 상용 지원은 별도의 기술을 조합해야 했다.

Linux 그래픽 환경은 X11과 Wayland, 여러 창 관리자, GPU 드라이버와 배포판 조합을 지원해야 했다. 특히 과거에는 독점 GPU 드라이버와 오픈 소스 드라이버의 기능 및 품질 차이가 컸다.

상용 게임에 사용되는 일부 복사 방지, 안티치트, 런처와 미들웨어가 Windows 커널 드라이버나 특정 Win32 동작에 의존한 것도 Linux 지원을 어렵게 했다. 게임 본체가 Wine이나 Proton에서 실행되더라도 안티치트와 런처가 지원하지 않으면 온라인 게임 전체를 사용할 수 없었다.

게임사가 Linux 네이티브 버전을 만들더라도 사용자 수가 작으면 별도 빌드, 시험, 고객 지원과 장기 유지 비용을 회수하기 어려웠다. Linux 사용자가 적어서 지원이 줄고, 지원 게임이 적어서 사용자가 늘지 않는 구조가 지속되었다.

Proton과 Linux 게임 환경의 확대

Valve는 Steam Play와 Proton을 통해 Windows 게임을 Linux에서 실행하는 방식을 확대했다. Proton은 수정된 Wine과 고성능 그래픽 변환 기술을 결합하여 Windows API와 DirectX 호출을 Linux 환경에 연결한다.

Valve는 Proton을 Windows 게임을 Linux에서 실행하기 위한 호환성 계층으로 설명하며, 수정된 Wine과 고성능 그래픽 구성 요소를 사용한다고 밝히고 있다.^[179]

Proton 환경에서는 일반적으로 다음과 같은 변환이 이루어진다.

• Win32 API를 Wine 구현으로 처리
• Direct3D 9·10·11을 Vulkan 기반 DXVK로 변환
• Direct3D 12를 Vulkan 기반 vkd3d-proton으로 변환
• Windows 오디오와 입력 API를 Linux 환경에 연결
• 게임별 호환성 패치 적용
• Steam 런타임으로 공통 라이브러리 환경 제공

Steam Deck은 Linux 기반 SteamOS와 Proton을 사용하면서 Linux 네이티브 게임만으로 제한되지 않는 게임 장치를 만들었다. 이는 게임사가 별도 Linux 빌드를 제공하지 않더라도 기존 Windows 버전을 실행할 수 있게 하여 Linux 게임 생태계의 가장 큰 장벽 가운데 하나를 줄였다.

그러나 Proton은 Windows 게임을 Linux 네이티브 프로그램으로 바꾸는 것이 아니다. Windows 동작을 재현하는 호환성 계층이므로 게임 업데이트, 안티치트, DRM, 영상 코덱과 드라이버 동작에 따라 호환성이 달라질 수 있다.

Linux 게임 지원이 크게 개선되었어도 게임 개발과 출시의 기준점은 여전히 Windows인 경우가 많다. Proton이 필요한 이유 자체가 대부분의 PC 게임이 Windows 실행 파일과 DirectX를 기준으로 만들어졌기 때문이다.

콘솔 운영체제와 UNIX 계열의 사용

콘솔 게임기는 PC와 달리 제조사가 하드웨어, 운영체제, 상점, 개발 키트와 인증 정책을 하나의 플랫폼으로 통제한다. 따라서 운영체제가 Windows인지 UNIX 계열인지보다, 제조사가 개발사에 얼마나 안정적인 전용 API와 SDK를 제공하는지가 중요하다.

콘솔에서는 다음 조건이 고정된다.

• CPU와 GPU
• 메모리 구조
• 저장 장치
• 운영체제 버전
• 그래픽과 오디오 API
• 입력 장치
• 상점과 패키지 형식
• 인증과 업데이트 체계

이 때문에 UNIX 또는 BSD 계열 기반을 사용하더라도 PC Linux처럼 수많은 배포판과 드라이버 조합을 지원할 필요가 없다. 게임은 제조사가 지정한 SDK와 하드웨어 한 종류 또는 소수의 모델을 대상으로 최적화된다.

PlayStation 4는 FreeBSD 커널과 BSD 계열 구성 요소를 사용하는 시스템 소프트웨어를 탑재한다. Sony Interactive Entertainment의 공식 오픈 소스 목록에는 PlayStation 4에서 사용된 FreeBSD Kernel, BSD libc와 FreeBSD 파일 시스템 도구가 명시되어 있다.^[180]

이 사실은 FreeBSD에서 일반 PC용 PlayStation 게임을 그대로 실행할 수 있다는 뜻은 아니다. PlayStation 시스템 소프트웨어는 Sony가 FreeBSD 계열 코드를 바탕으로 콘솔 하드웨어, 보안, 그래픽 API와 게임 실행 환경에 맞게 만든 전용 플랫폼이다.

PlayStation 게임은 일반 FreeBSD 데스크톱 API를 대상으로 개발되지 않고, Sony가 제공하는 비공개 개발 키트, 그래픽 인터페이스, 도구와 인증 절차를 사용한다.

Nintendo Switch와 Nintendo Switch 2 역시 전용 시스템 소프트웨어와 개발 환경을 사용한다. Nintendo의 공식 지식재산권 고지는 기기에 FreeBSD 프로젝트에서 유래한 코드를 포함한 여러 오픈 소스 구성 요소가 사용됨을 보여준다.^[181][182]

그러나 오픈 소스 고지에 FreeBSD 코드가 포함되었다는 사실만으로 Nintendo Switch의 운영체제 전체를 FreeBSD라고 분류할 수는 없다. Nintendo는 자체 전용 운영체제, API와 보안 환경을 제공하며, FreeBSD를 비롯한 여러 프로젝트의 구성 요소를 그 안에서 사용한다.

Xbox One과 Xbox Series X·S는 Windows NT 계열 기술과 하이퍼바이저, DirectX 및 Microsoft 게임 플랫폼을 공유한다. Xbox 역시 일반 Windows 데스크톱을 실행하는 PC가 아니라 콘솔 게임과 보안 요구에 맞게 제한된 전용 운영 환경이다.

Xbox에서 Windows 계열 기술을 사용한다는 사실은 PC Windows 게임을 수정 없이 모두 실행할 수 있다는 뜻이 아니다. Xbox용 게임은 GDK, 콘솔 패키지, 인증, 저장소와 보안 규칙을 따라 별도로 제작된다.

콘솔 사례는 게임 플랫폼의 성공이 운영체제 계보만으로 결정되지 않는다는 점을 보여준다.

Windows가 PC 게임 시장에서 강한 이유는 Windows 커널 자체가 게임에 유일하게 적합해서가 아니다. 이미 형성된 사용자 기반, DirectX, 그래픽 드라이버, 개발 도구, 상점, 엔진, 미들웨어와 하위 호환성이 서로 강화되었기 때문이다.

반대로 콘솔에서는 제조사가 전체 플랫폼을 통제하므로 FreeBSD, Linux나 Windows 계열 가운데 어떤 기반을 선택하더라도 일관된 게임 API와 하드웨어를 제공할 수 있다. 일반 PC의 Linux 게임 환경은 콘솔처럼 고정된 플랫폼이 아니기 때문에 하드웨어와 배포판 다양성을 처리해야 하지만, Proton과 SteamOS는 그 차이를 줄이는 방향으로 발전하고 있다.

Windows는 하나의 물리 컴퓨터에서 여러 운영체제와 격리된 실행 환경을 운용하기 위해 하드웨어 가상화, 운영체제 수준 가상화와 응용 프로그램 호환 계층을 제공한다.

Hyper-V는 Windows의 하드웨어 가상화 기반을 제공하고, 가상화 기반 보안은 같은 하이퍼바이저를 이용해 운영체제의 보안 구성 요소를 일반 커널과 분리한다. Windows Sandbox는 일회성 Windows 환경을 만들고, Windows 컨테이너는 응용 프로그램과 그 실행 환경을 프로세스 또는 Hyper-V 단위로 격리한다.

Windows Subsystem for Linux는 Windows 안에서 Linux 사용자 공간과 Linux 응용 프로그램을 실행한다. WSL 1은 Linux 시스템 호출을 Windows NT 기능으로 변환하고, WSL 2는 경량 가상 머신에서 실제 Linux 커널을 실행한다. 과거 제공되었던 Windows Subsystem for Android는 유사한 가상화 기술을 사용해 Android 응용 프로그램을 실행했으나 2025년 3월 5일 지원이 종료되었다.

Windows 가상화 기술의 주요 관계

• Windows 하이퍼바이저
  • Hyper-V 가상 머신
    • Windows 게스트
    • Linux 게스트
    • 가상 장치와 가상 스위치
  • 가상화 기반 보안
    • 가상 보안 모드
    • Credential Guard
    • 메모리 무결성
    • VBS Enclave
  • 경량 격리 환경
    • Windows Sandbox
    • Hyper-V 격리 Windows 컨테이너
    • WSL 2
  • 지원이 종료된 환경
    • Windows Subsystem for Android
• 운영체제 수준 가상화
  • 프로세스 격리 Windows 컨테이너
  • 작업 객체와 네임스페이스
  • 파일 시스템 및 레지스트리 격리
  • 응용 프로그램별 자원 제한
• 호환성 및 변환 환경
  • WSL 1
  • WOW64
  • 응용 프로그램 호환성 계층

가상 머신과 컨테이너는 모두 실행 환경을 격리하지만 경계가 다르다. 가상 머신은 일반적으로 각자 운영체제 커널을 실행하고, 프로세스 격리 컨테이너는 호스트의 Windows 커널을 공유한다. Hyper-V 격리 컨테이너는 컨테이너 인터페이스를 유지하면서 각 컨테이너에 경량 가상 머신과 별도의 Windows 커널을 제공한다.

Hyper-V

Hyper-V는 Microsoft가 개발한 하드웨어 가상화 플랫폼이다. 물리 컴퓨터의 프로세서, 메모리, 저장 장치와 네트워크를 여러 가상 머신에 분배하며, 각 가상 머신은 독립적인 게스트 운영체제를 실행한다.

Hyper-V는 Windows Server에서 서버 역할로 제공되며, 지원되는 Windows 클라이언트 에디션에서는 선택적 기능으로 제공된다. Windows Server의 Hyper-V는 데이터센터와 기업용 가상화에 필요한 라이브 마이그레이션, 장애 조치 클러스터, 복제와 대규모 관리 기능을 제공한다. 클라이언트 Windows의 Hyper-V는 개발, 시험, 보안 분석과 로컬 가상 머신 실행에 주로 사용된다.^[183]

Hyper-V는 일반적으로 제1형 하이퍼바이저로 분류된다. Hyper-V가 활성화되면 Windows 호스트 운영체제도 하드웨어를 직접 독점하는 일반 운영체제처럼 실행되지 않고, 하이퍼바이저가 관리하는 루트 파티션에서 동작한다.

Hyper-V의 기본 구조

• 물리 하드웨어
  • Windows 하이퍼바이저
    • 루트 파티션
      • Windows 호스트
      • 가상 머신 관리 서비스
      • 물리 장치 드라이버
      • 가상 스위치
      • 가상화 서비스 공급자
    • 자식 파티션
      • 가상 머신 A
        • 게스트 운영체제
        • 가상화 서비스 클라이언트
        • 응용 프로그램
    • 자식 파티션
      • 가상 머신 B
        • 게스트 운영체제
        • 에뮬레이션 또는 합성 장치
        • 응용 프로그램

루트 파티션은 Hyper-V를 관리하는 특수 파티션이다. 물리 장치 드라이버, 가상 머신 관리 서비스와 가상 스위치가 루트 파티션의 Windows 환경에서 동작한다.

각 게스트 가상 머신은 자식 파티션에서 실행된다. 자식 파티션은 다른 가상 머신과 분리된 가상 프로세서, 메모리와 장치 인터페이스를 가진다.

Hyper-V의 주요 구성 요소에는 다음이 포함된다.

• Windows 하이퍼바이저
• 가상 머신 관리 서비스
• 가상 머신 작업자 프로세스
• 가상화 서비스 공급자와 클라이언트
• 가상 머신 버스
• Hyper-V 가상 스위치
• 가상 하드 디스크
• 체크포인트와 저장 상태
• 통합 서비스
• 관리 API와 PowerShell 모듈

하이퍼바이저는 가상 프로세서 스케줄링, 메모리 격리, 인터럽트 전달과 파티션 경계를 관리한다. 장치 에뮬레이션과 대부분의 고수준 가상 머신 관리는 루트 파티션의 Windows 구성 요소가 담당한다.

Hyper-V는 Intel VT-x, AMD-V와 같은 하드웨어 가상화 확장과 2단계 주소 변환 기능을 사용한다. 현대 Windows에서 Hyper-V를 사용하려면 프로세서 가상화, 데이터 실행 방지와 필요한 펌웨어 설정이 활성화되어야 한다.^[184]

Hyper-V 가상 머신은 세대 1과 세대 2로 나뉜다.

새로운 Windows와 현대 Linux 배포판에는 일반적으로 세대 2 가상 머신이 사용된다. 세대 1은 BIOS 부팅과 오래된 운영체제 호환성이 필요한 경우 사용된다.

가상 머신 저장 장치는 주로 VHD와 VHDX 파일로 제공된다. VHDX는 더 큰 용량, 전원 장애 복원력, 큰 논리 섹터와 메타데이터 기능을 지원하는 현대 형식이다.

가상 디스크는 다음 방식으로 만들 수 있다.

• 고정 크기
• 동적 확장
• 차이점 보관
• 물리 디스크 직접 연결
• 공유 가상 디스크
• 가상 파이버 채널 또는 원격 저장소

고정 크기 디스크는 생성 시 전체 공간을 할당하고, 동적 확장 디스크는 데이터가 기록될 때 파일이 커진다. 차이점 보관 디스크는 부모 디스크를 변경하지 않고 변경된 블록만 별도 파일에 저장한다.

체크포인트는 가상 머신의 디스크와 선택적인 메모리 상태를 특정 시점으로 기록한다. 시험 중 변경을 되돌리거나 업데이트 전 상태를 보존하는 데 사용할 수 있다.

표준 체크포인트는 실행 중인 메모리와 장치 상태까지 보존할 수 있다. 프로덕션 체크포인트는 게스트 운영체제의 백업 기술을 사용해 응용 프로그램과 파일 시스템이 일관된 상태의 디스크 체크포인트를 만든다.

체크포인트는 장기 백업을 대체하지 않는다. 부모 디스크와 체크포인트 체인이 함께 손상될 수 있고, 도메인 컨트롤러나 데이터베이스에서는 상태 복원에 별도의 일관성 고려가 필요하다.

Hyper-V의 메모리 관리에는 고정 메모리와 동적 메모리가 있다. 동적 메모리는 가상 머신의 수요와 설정된 최소·시작·최대 용량을 바탕으로 메모리 할당을 조정한다.

Hyper-V 가상 스위치는 가상 머신, 호스트와 물리 네트워크를 연결하는 소프트웨어 기반 Ethernet 스위치다.

가상 스위치는 다음 유형으로 구성할 수 있다.

• 외부 스위치는 물리 네트워크 어댑터에 연결된다.
• 내부 스위치는 호스트와 가상 머신 사이의 통신을 제공한다.
• 개인 스위치는 같은 호스트의 가상 머신끼리만 통신하게 한다.
• NAT와 관리형 가상 네트워크는 내부 스위치 위에 주소 변환을 추가할 수 있다.

가상 스위치는 VLAN, ACL, 대역폭 관리, 포트 미러링, 확장 필터와 SR-IOV 같은 기능을 지원할 수 있다.

Windows Server의 Hyper-V는 다음과 같은 기업용 기능을 제공한다.

• 라이브 마이그레이션
• 저장소 마이그레이션
• 장애 조치 클러스터
• Hyper-V Replica
• 공유 저장소
• 가상 머신 부하 분산
• 중첩 가상화
• 가상 머신 보호
• 가상 TPM
• 장치 직접 할당
• GPU 분할
• 대규모 메모리와 가상 프로세서 지원

Windows Server 2025의 Hyper-V는 호스트당 최대 4PB 메모리와 2,048개의 논리 프로세서, 세대 2 가상 머신당 최대 240TB 메모리와 2,048개의 가상 프로세서를 지원하는 방향으로 확장되었다.^[185]

라이브 마이그레이션은 실행 중인 가상 머신을 중지하지 않거나 짧은 전환 시간만으로 다른 Hyper-V 호스트로 이동한다. 메모리 내용이 네트워크로 복사되고 마지막 변경분과 실행 상태가 대상 호스트로 전환된다.

Hyper-V Replica는 가상 머신의 디스크 변경 내용을 다른 Hyper-V 서버로 비동기 복제하여 재해 복구 복사본을 유지한다. 공유 저장소가 없어도 구성할 수 있지만 실시간 동기 복제와는 목적과 복구 지점이 다르다.

중첩 가상화는 Hyper-V 가상 머신 안에서 다시 Hyper-V나 가상화 기능을 사용할 수 있게 한다. 가상화 시험, 컨테이너 호스트와 교육 환경에 사용되지만 물리 호스트에서 직접 실행할 때보다 추가 비용이 발생할 수 있다.

가상화 기반 보안

가상화 기반 보안 또는 VBS는 Windows 하이퍼바이저를 이용해 일반 Windows 커널과 분리된 보안 실행 환경을 만드는 기능이다.

Microsoft는 VBS를 하드웨어 가상화와 Windows 하이퍼바이저를 이용해 격리된 가상 환경을 만들고, 이 환경을 운영체제의 신뢰 기반으로 사용하는 기술로 설명한다.^[186]

전통적인 운영체제 보안에서는 커널이 시스템의 가장 높은 소프트웨어 권한을 가진다. 커널이 완전히 침해되면 커널 안에서 실행되는 보안 구성 요소와 메모리도 공격자가 조작할 수 있다.

VBS는 하이퍼바이저가 커널보다 높은 격리 경계를 제공하도록 한다. 일반 Windows 커널이 실행되는 가상 신뢰 수준 0과 보안 구성 요소가 실행되는 가상 신뢰 수준 1을 분리하며, 일반 커널이 보안 영역의 메모리를 직접 읽거나 수정하지 못하도록 제한한다.

가상화 기반 보안의 신뢰 영역

• Windows 하이퍼바이저
  • 가상 신뢰 수준 0
    • 일반 Windows 커널
    • 장치 드라이버
    • 시스템 서비스
    • 사용자 응용 프로그램
  • 가상 신뢰 수준 1
    • 보안 커널
    • 격리 사용자 모드
    • Credential Guard 비밀
    • 코드 무결성 정책
    • VBS Enclave

VBS 자체는 사용자에게 하나의 독립된 가상 머신을 제공하는 기능이 아니다. 운영체제 내부의 보안 구성 요소가 사용하는 격리 기반이며, Hyper-V 관리자에 일반 가상 머신처럼 표시되지 않는다.

VBS를 사용하는 주요 Windows 기능은 다음과 같다.

• Credential Guard
• 메모리 무결성
• 보호된 자격 증명
• 가상 TPM과 보호된 가상 머신
• App Control for Business
• 커널 코드 무결성 보호
• VBS Enclave
• 일부 생체 인증과 키 보호
• 보호된 프로세스와 보안 서비스

메모리 무결성은 하이퍼바이저로 보호되는 코드 무결성 또는 HVCI의 사용자-facing 명칭이다. 커널 모드 코드가 실행되기 전에 격리된 보안 환경에서 서명과 정책을 검사하고, 쓰기 가능한 커널 메모리가 동시에 실행 가능해지는 것을 제한한다.^[187]

메모리 무결성이 활성화된 환경에서는 드라이버가 다음 규칙을 충족해야 한다.

• 실행 코드가 신뢰되는 서명을 가져야 한다.
• 실행 가능한 메모리 페이지를 임의로 수정하지 않아야 한다.
• 쓰기 가능하고 실행 가능한 메모리를 동시에 사용하지 않아야 한다.
• 커널 코드 무결성 정책과 호환되어야 한다.
• 차단 목록에 포함된 취약 드라이버가 아니어야 한다.

오래된 드라이버나 커널 수준 프로그램은 이러한 규칙과 호환되지 않을 수 있다. Windows는 기능을 활성화하기 전에 알려진 비호환 드라이버를 확인하거나 사용자에게 경고할 수 있다.

Credential Guard는 NTLM 해시와 Kerberos 티켓 같은 인증 비밀을 VBS 영역으로 분리한다. 일반 커널과 LSASS가 침해되더라도 공격자가 해당 비밀을 직접 읽기 어렵게 만든다.

VBS Enclave는 응용 프로그램의 주소 공간 안에 보안에 민감한 코드와 데이터를 위한 격리 영역을 제공한다. 호스트 응용 프로그램과 일반 운영체제 영역에서도 직접 접근할 수 없는 소프트웨어 기반 신뢰 실행 환경으로 사용된다.^[188]

VBS는 Hyper-V 가상 머신을 실행하지 않더라도 Windows 하이퍼바이저를 활성화할 수 있다. 이 경우 다른 가상화 프로그램도 하드웨어 가상화 기능을 직접 독점하지 않고 Windows 하이퍼바이저 플랫폼을 통해 동작해야 할 수 있다.

현대 VMware Workstation, VirtualBox와 Android 에뮬레이터는 Windows Hypervisor Platform과의 공존 기능을 제공할 수 있지만, 사용되는 경로와 성능은 제품 버전과 호스트 구성에 따라 달라진다.

VBS는 격리를 강화하지만 가상화 전환, 메모리 보호와 추가 검증 비용이 발생할 수 있다. 일반적인 업무 환경에서는 영향이 작을 수 있지만, 높은 입출력 빈도, 오래된 드라이버와 특정 게임 또는 실시간 작업에서는 성능과 호환성을 확인할 수 있다.

Windows Sandbox

Windows Sandbox는 신뢰하기 어려운 프로그램과 파일을 일시적인 Windows 데스크톱 환경에서 실행하기 위한 경량 가상화 기능이다.

Sandbox를 시작할 때 깨끗한 Windows 환경이 만들어지고, 창을 닫으면 내부에 설치한 프로그램, 파일과 시스템 변경이 기본적으로 모두 삭제된다. 호스트 Windows와 별도의 커널 및 사용자 공간을 사용하므로 일반적인 AppContainer나 제한 토큰보다 강한 격리 경계를 제공한다.

Microsoft는 Windows Sandbox를 신뢰할 수 없는 응용 프로그램을 안전하게 실행하기 위한 경량 데스크톱 환경으로 설명한다.^[189]

Windows Sandbox의 주요 특성은 다음과 같다.

• Windows에 포함된 선택적 기능
• 실행할 때 깨끗한 환경 생성
• 종료 시 기본적으로 모든 변경 제거
• Hyper-V 기반 격리
• 호스트 운영체제 파일의 효율적인 공유
• 동적 메모리 관리
• 가상 GPU 지원
• 네트워크 연결
• 클립보드와 폴더 공유
• 설정 파일을 이용한 사용자 정의

Sandbox는 완전한 Windows 이미지를 매번 별도로 복사하지 않는다. 호스트의 변경되지 않는 시스템 파일을 공유하고, Sandbox 안에서 변경된 내용은 별도의 가상 디스크 계층에 저장한다.

Windows Sandbox의 저장 구조

• 호스트 Windows 시스템 파일
  • 변경할 수 없는 공유 기반 이미지
  • Windows Sandbox
    • 차이 디스크
      • Sandbox 안에서 생성한 파일
      • 레지스트리 변경
      • 설치한 프로그램
    • 임시 사용자 프로필
    • 종료 시 폐기

Sandbox는 통합 커널 스케줄러와 메모리 관리 기능을 사용하여 일반적인 독립 가상 머신보다 호스트 자원을 유연하게 공유한다. 유휴 상태에서는 메모리 사용량을 줄이고, 작업량에 따라 필요한 메모리를 할당할 수 있다.

Windows Sandbox는 다음과 같은 용도에 적합하다.

• 출처가 불분명한 실행 파일 시험
• 의심스러운 문서와 설치 프로그램 확인
• 응용 프로그램 설치 과정 관찰
• 일회성 개발 및 시험 환경
• 시스템 설정 변경 시험
• 브라우저나 웹 콘텐츠 격리
• 짧은 소프트웨어 데모

Sandbox는 영구적인 개발 가상 머신이나 서버를 대체하지 않는다. 기본적으로 종료 시 상태가 폐기되며, 장기 저장과 반복적인 복잡한 환경에는 일반 Hyper-V 가상 머신이나 컨테이너가 더 적합할 수 있다.

.wsb 확장자의 XML 설정 파일을 사용하면 Sandbox 동작을 사용자 정의할 수 있다. Microsoft는 설정 파일을 통해 네트워크, 가상 GPU, 오디오·영상 입력, 클립보드, 프린터, 보호된 클라이언트, 메모리, 공유 디렉터리와 시작 명령을 구성할 수 있도록 한다.^[190]

설정 가능한 주요 항목은 다음과 같다.

• 네트워크 활성화 여부
• 가상 GPU 사용
• 클립보드 공유
• 오디오 입력
• 영상 입력
• 프린터 리디렉션
• 호스트 디렉터리 매핑
• 읽기 전용 공유
• Sandbox 시작 시 실행할 명령
• 메모리 크기
• 보호된 클라이언트 모드

Windows Sandbox는 기본적으로 네트워크를 사용할 수 있다. 악성 프로그램 분석이나 신뢰하지 않는 파일 시험에서는 외부 통신, 공격 서버 연결과 내부망 접근을 줄이기 위해 네트워크를 비활성화할 수 있다.^[191]

호스트 디렉터리를 Sandbox에 공유하면 그 디렉터리는 격리 경계를 통과하는 데이터 통로가 된다. 쓰기 가능한 공유 디렉터리에서는 Sandbox 안의 프로그램이 호스트 파일을 수정할 수 있으므로, 분석 대상 전달에는 읽기 전용 매핑을 사용할 수 있다.

클립보드 공유도 호스트와 Sandbox 사이에 데이터를 전달한다. 민감한 작업에서는 네트워크, 클립보드, 장치와 디렉터리 공유를 모두 제한할 수 있다.

Windows Sandbox는 Hyper-V 기반 격리를 사용하지만 모든 보안 위험을 제거하지 않는다. 하이퍼바이저, 가상 장치나 공유 통로의 취약점이 존재할 수 있으므로 Windows 업데이트와 최소 공유 정책을 함께 적용한다.

Windows 컨테이너

Windows 컨테이너는 Windows 응용 프로그램과 필요한 사용자 공간 구성 요소를 이미지로 묶고, 격리된 파일 시스템·레지스트리·프로세스 환경에서 실행하는 기술이다.

가상 머신이 전체 운영체제 인스턴스를 실행하는 것과 달리, 프로세스 격리 컨테이너는 호스트 Windows 커널을 공유한다. 이 때문에 시작이 빠르고 가상 머신보다 적은 메모리와 저장 공간을 사용할 수 있다.

Windows 컨테이너는 다음과 같은 요소로 구성된다.

• 컨테이너 이미지
• 읽기 전용 이미지 계층
• 컨테이너별 쓰기 계층
• 격리된 프로세스
• 파일 시스템과 레지스트리 보기
• 네트워크 네임스페이스
• 가상 네트워크 어댑터
• 자원 제한
• 컨테이너 런타임
• 이미지 저장소와 레지스트리

Windows 컨테이너 이미지는 여러 읽기 전용 계층으로 구성될 수 있다. 컨테이너가 실행되면 최상단에 쓰기 가능한 계층이 추가되고, 컨테이너 안에서 발생한 파일과 레지스트리 변경은 이 계층에 기록된다.

Windows 컨테이너 이미지와 실행 계층

• 기본 운영체제 이미지
  • Windows Server Core 또는 Nano Server 계층
    • 런타임과 프레임워크 계층
      • 응용 프로그램 계층
        • 실행 중인 컨테이너
          • 쓰기 가능한 임시 계층
          • 컨테이너 프로세스
          • 네트워크 인터페이스
          • 연결된 볼륨

Windows 컨테이너에는 두 가지 주요 격리 모드가 있다.

• 프로세스 격리
• Hyper-V 격리

Microsoft는 두 격리 모드가 같은 컨테이너 이미지와 관리 인터페이스를 사용하지만, 호스트와 컨테이너 사이에 만들어지는 보안 경계의 강도가 다르다고 설명한다.^[192]

프로세스 격리에서는 컨테이너가 호스트와 같은 Windows 커널을 공유한다. 컨테이너별 프로세스, 파일 시스템, 레지스트리, 네트워크와 객체 이름 공간이 분리되지만, 커널 자체는 공통으로 사용된다.

프로세스 격리의 특징은 다음과 같다.

• 빠른 시작
• 낮은 메모리 사용
• 높은 컨테이너 밀도
• 호스트 커널 공유
• 호스트와 이미지 버전 호환성 요구
• 커널 취약점에 대한 공통 영향 가능성

프로세스 격리 컨테이너의 관리자 권한은 컨테이너 환경 안에서는 강한 권한을 가지지만, 일반적으로 호스트 전체의 관리자와 같지 않다. 다만 커널을 공유하므로 보안 경계는 독립 가상 머신보다 약하다.

Hyper-V 격리에서는 각 컨테이너가 최적화된 경량 가상 머신에서 별도의 Windows 커널을 실행한다. 컨테이너 관리 방식과 이미지는 유지하면서 호스트와 커널 경계를 분리한다.

Microsoft는 Hyper-V 격리 컨테이너가 각자 Windows 커널 인스턴스를 가지며 호스트와 이미지의 운영체제 버전 차이를 더 유연하게 처리할 수 있다고 설명한다.^[193]

Windows 10과 Windows 11에서 Windows Server 컨테이너 이미지를 개발용으로 실행할 때에는 호스트와 생산 서버의 커널 차이를 줄이기 위해 Hyper-V 격리가 사용될 수 있다.^[194]

Windows 컨테이너의 대표적인 기본 이미지는 다음과 같다.

• Nano Server
• Server Core
• Windows
• Windows Server

Nano Server 이미지는 작은 크기와 클라우드 네이티브 응용 프로그램을 목표로 하며, 전체 Win32 호환성이 필요하지 않은 .NET과 서버 응용 프로그램에 사용된다.

Server Core 이미지는 더 넓은 Windows API와 서버 구성 요소를 제공하며, 기존 Windows Server 응용 프로그램을 컨테이너로 이전할 때 사용된다.

전체 Windows 계열 이미지는 더 많은 구성 요소와 API를 제공하지만 이미지 크기와 공격 표면도 커진다. 필요한 API와 런타임을 기준으로 가장 작은 적합한 이미지를 선택한다.

컨테이너는 상태 없는 응용 프로그램에 적합하지만 데이터베이스와 상태 저장 서비스도 외부 볼륨과 적절한 종료·백업 체계를 사용하면 실행할 수 있다.

컨테이너 내부의 쓰기 계층은 컨테이너가 삭제되면 함께 제거될 수 있다. 영구 데이터는 다음 위치에 저장한다.

• 바인드 마운트
• 명명된 볼륨
• SMB 공유
• 클라우드 저장소
• 외부 데이터베이스
• 컨테이너 오케스트레이터의 영구 볼륨

Windows 컨테이너는 여러 네트워크 드라이버를 사용할 수 있다.

• NAT
• 투명 네트워크
• 오버레이 네트워크
• L2 브리지
• 격리된 네트워크

NAT 네트워크에서는 컨테이너가 사설 IP 주소를 사용하고 호스트가 외부 통신을 변환한다. 투명 네트워크에서는 컨테이너가 물리 네트워크에 직접 연결된 것과 유사한 주소를 받을 수 있다.

Windows 컨테이너는 Docker 호환 도구, containerd, Mirantis Container Runtime, Kubernetes와 Windows Server 관리 도구를 통해 실행할 수 있다. 지원되는 런타임과 배포 구성은 Windows Server 버전과 Microsoft 지원 정책에 따라 달라진다.^[195]

Linux 컨테이너와 Windows 컨테이너는 같은 컨테이너 이미지 형식과 관리 도구를 사용할 수 있지만 실행 시 요구하는 커널 인터페이스가 다르다.

• Linux 컨테이너는 Linux 커널을 공유한다.
• Windows 컨테이너는 Windows 커널을 공유하거나 별도 Windows 커널을 실행한다.
• Windows 호스트에서 Linux 컨테이너를 실행하려면 Linux 커널을 제공하는 가상 머신이나 WSL 2 환경이 필요하다.
• Linux 호스트에서 Windows 컨테이너를 일반적인 Linux 컨테이너처럼 직접 실행할 수는 없다.

Windows Subsystem for Linux

Windows Subsystem for Linux 또는 WSL은 Windows에서 GNU/Linux 사용자 공간, 명령줄 도구와 응용 프로그램을 실행하기 위한 하위 시스템이다.

WSL은 개발자가 Windows 데스크톱과 응용 프로그램을 유지하면서 Linux 빌드 도구, 서버, 패키지 관리자와 셸을 함께 사용할 수 있도록 한다.

Microsoft는 WSL을 전통적인 가상 머신이나 이중 부팅의 관리 부담 없이 Windows에서 수정되지 않은 GNU/Linux 환경을 실행하는 기능으로 설명한다.^[196]

WSL에는 구조가 다른 WSL 1과 WSL 2가 있다.

WSL 1은 Linux ELF 실행 파일을 적재하고 Linux 시스템 호출을 Windows NT 커널 기능으로 변환한다. 별도의 Linux 커널을 실행하지 않는다.

WSL 1의 실행 흐름

1. Linux ELF 실행 파일 시작
   ↓
2. WSL 사용자 공간과 시스템 호출 인터페이스 사용
   ↓
3. Linux 시스템 호출을 Windows NT 동작으로 변환
   ↓
4. Windows 파일, 프로세스와 네트워크 기능 사용
   ↓
5. 결과를 Linux 응용 프로그램 형식으로 반환

WSL 1은 가상 머신 시작 비용이 없고 Windows 파일 시스템과 긴밀하게 연결된다. 그러나 Linux 커널의 모든 시스템 호출과 장치 동작을 Windows NT 기능으로 완전히 재현하기 어렵다.

WSL 2는 아키텍처를 변경하여 경량 가상 머신 안에 실제 Linux 커널을 실행한다. Microsoft는 WSL 2의 주요 목표를 파일 시스템 성능 향상과 완전한 시스템 호출 호환성 제공으로 설명한다.^[197]

WSL 2의 기본 구조

• Windows
  • Windows 응용 프로그램
  • WSL 관리 서비스
  • Windows 파일 시스템
  • WSL 2 경량 가상 머신
    • Microsoft가 유지하는 Linux 커널
    • 배포판 A 사용자 공간
      • systemd
      • 셸과 명령줄 도구
      • 응용 프로그램
    • 배포판 B 사용자 공간
    • 가상 디스크
    • 가상 네트워크

WSL 2의 가상 머신은 일반 Hyper-V 가상 머신과 달리 사용자가 가상 CPU, 펌웨어, 가상 디스크와 부팅 절차를 직접 관리할 필요가 없다. Windows가 시작, 종료, 메모리 회수와 배포판 연결을 자동으로 관리한다.

WSL 배포판은 Microsoft Store, 명령줄 설치, 사용자 정의 배포 패키지와 가져오기 기능을 통해 설치할 수 있다. Ubuntu, Debian, Kali Linux, SUSE와 다른 배포판을 사용할 수 있으며, 사용자가 직접 만든 루트 파일 시스템도 가져올 수 있다.

각 배포판은 독립적인 다음 요소를 가진다.

• 루트 파일 시스템
• 패키지 데이터베이스
• 사용자 계정
• 기본 셸
• 설정 파일
• 설치된 응용 프로그램
• 배포판별 systemd 서비스
• 환경 변수와 개발 도구

WSL 2 배포판은 일반적으로 VHDX 파일에 Linux 파일 시스템을 저장한다. Linux에서 많은 작은 파일을 처리하는 빌드와 패키지 작업은 Linux 파일 시스템 안에 프로젝트를 둘 때 더 빠를 수 있다.

Windows 파일은 Linux에서 /mnt/c, /mnt/d 같은 경로로 접근할 수 있다. Windows에서는 \\wsl.localhost 계열 경로를 통해 Linux 파일 시스템에 접근할 수 있다.

Windows와 Linux 환경은 서로 프로그램을 호출할 수 있다.

• Linux 셸에서 .exe Windows 프로그램 실행
• Windows에서 wsl.exe를 통해 Linux 명령 실행
• 표준 입력과 출력 연결
• Windows 경로와 Linux 경로 변환
• Visual Studio Code와 개발 도구 연동
• 같은 로컬 네트워크 포트 접근

WSL 2는 가상화된 네트워크를 사용한다. 전통적인 NAT 방식에서는 Linux 환경이 Windows 호스트와 다른 내부 IP 주소를 가질 수 있다. 현대 WSL은 미러링 네트워크와 추가 통합 모드를 제공하여 VPN, IPv6, 로컬 네트워크와 방화벽의 상호 운용성을 개선할 수 있다.

Microsoft는 WSL 2가 가상화 네트워크 구성 요소를 사용하며 일반적인 가상 머신과 유사한 네트워크 특성을 가질 수 있다고 설명한다.^[198]

WSLg는 Linux GUI 응용 프로그램을 Windows 데스크톱에 통합한다. Wayland, X11, PulseAudio와 원격 데스크톱 기반 구성 요소를 이용해 Linux 창, 오디오와 입력을 Windows에 표시한다.

WSLg는 다음 기능을 제공한다.

• Linux GUI 창 표시
• Windows 작업 표시줄 통합
• 시작 메뉴 바로 가기
• 클립보드 공유
• 오디오 입력과 출력
• 여러 모니터
• GPU 가속
• DPI와 창 크기 조절

WSL 2의 GPU 계산 지원은 Linux 응용 프로그램이 Windows GPU 드라이버와 가상 GPU 인터페이스를 통해 CUDA, DirectML, OpenCL과 일부 그래픽·계산 기능을 사용할 수 있게 한다.

Linux 컨테이너 도구는 WSL 2의 실제 Linux 커널을 사용할 수 있다. Docker Desktop과 다른 개발 환경은 WSL 2 배포판 또는 전용 WSL 가상 머신에서 컨테이너 데몬을 실행하고 Windows 개발 도구와 통합한다.

WSL은 2025년에 핵심 코드가 오픈 소스로 공개되었다. Microsoft는 WSL 프로젝트의 소스 코드를 GitHub에서 제공하고 빌드와 기여 절차를 공개한다.^[199]

WSL은 독립적인 Linux 서버 가상 머신을 완전히 대체하지 않는다. 다음과 같은 작업에서는 별도 Linux 시스템이나 일반 가상 머신이 필요할 수 있다.

• 사용자 정의 커널과 부팅 과정 시험
• 하드웨어 장치의 완전한 직접 제어
• 커널 드라이버 개발
• 네트워크 장비와 라우터 역할
• 완전한 시스템 격리
• 실제 Linux 배포 환경과 동일한 초기화·스토리지 구성
• 지속적인 생산 서버 운영

WSL은 Windows와 Linux 개발 환경을 결합하는 것이 중심 목적이며, Windows 데스크톱 위에서 Linux 도구를 자연스럽게 사용하는 데 최적화되어 있다.

Windows Subsystem for Android

Windows Subsystem for Android 또는 WSA는 Windows 11에서 Android 응용 프로그램을 실행하기 위해 제공되었던 가상화 기반 하위 시스템이다.

WSA는 Android Open Source Project를 기반으로 한 Android 사용자 공간과 커널 환경을 경량 가상 머신 안에서 실행하고, Android 응용 프로그램 창을 Windows 데스크톱과 통합했다.

Windows 11의 Android 응용 프로그램 지원은 Amazon Appstore와 연결되어 제공되었다. 사용자는 Microsoft Store에서 Amazon Appstore를 설치하고, Amazon 계정을 통해 지원되는 Android 응용 프로그램을 받을 수 있었다.

Windows Subsystem for Android의 기본 구조

• Windows 11
  • Windows 셸과 작업 표시줄
  • Microsoft Store
  • Amazon Appstore
  • Windows Subsystem for Android
    • 관리형 경량 가상 머신
    • Android 커널 환경
    • Android Framework
    • Android 응용 프로그램
    • 가상 GPU와 오디오
    • 네트워크
    • Windows 창 및 입력 통합

WSA는 Android 응용 프로그램을 Windows 실행 파일로 변환하지 않았다. Android 운영 환경 전체를 가상화하고, 각 Android 활동을 Windows 창처럼 표시하는 방식이었다.

WSA는 다음과 같은 통합 기능을 제공했다.

• Android 앱 창을 Windows 데스크톱에 표시
• 시작 메뉴와 작업 표시줄 등록
• 키보드, 마우스와 터치 입력
• 클립보드
• 오디오
• 카메라와 일부 장치
• 네트워크
• Windows 파일과 Android 파일의 제한적 공유
• GPU 가속
• 창 크기 변경
• 알림

WSA 설정 앱에서는 하위 시스템의 메모리, 그래픽, 네트워크, 파일 공유, 개발자 모드와 종료 동작을 관리할 수 있었다.

개발자 모드를 활성화하면 Android Debug Bridge를 통해 WSA에 연결하고 개발 중인 APK를 설치할 수 있었다. 이는 Microsoft Store와 Amazon Appstore의 일반 사용자 배포 경로와 별개의 개발 기능이었다.

WSA는 Google Play 서비스가 기본 포함된 일반 Android 장치와 같지 않았다. Google Play 서비스에 의존하는 응용 프로그램은 해당 서비스가 없으면 로그인, 알림, 지도, 결제와 다른 기능이 동작하지 않을 수 있었다.

Windows와 Android의 프로세서 아키텍처가 다를 경우 응용 프로그램 바이너리 변환이 필요할 수 있었다. x86 Windows 장치에서 ARM 전용 Android 네이티브 라이브러리를 실행하기 위한 변환 기술이 사용되었지만 모든 응용 프로그램과 저수준 기능을 완전하게 지원하지는 않았다.

Microsoft는 2024년 WSA와 Amazon Appstore의 지원 종료를 발표했고, 2025년 3월 5일 이후 Microsoft Store에서 Windows Subsystem for Android와 Amazon Appstore의 일반 제공 및 지원을 종료했다.

따라서 WSA는 현대 Windows의 현재 배포 기능이 아니라 Windows 11에서 한시적으로 제공되었던 역사적 응용 프로그램 호환 환경으로 분류된다.

지원 종료 이후에는 다음 사항이 적용된다.

• Microsoft가 WSA 기능 업데이트와 기술 지원을 제공하지 않는다.
• Microsoft Store에서 신규 사용자를 위한 공식 배포가 종료되었다.
• Amazon Appstore의 Windows 지원도 종료되었다.
• 기존 설치 환경은 시스템 상태에 따라 남아 있을 수 있지만 공식 지원 대상이 아니다.
• 향후 Windows 업데이트와 응용 프로그램 변화에 대한 호환성이 보장되지 않는다.
• Android 응용 프로그램 실행에는 별도의 에뮬레이터, 가상 머신 또는 다른 솔루션이 사용될 수 있다.

지원 종료 뒤에도 기존 설치 파일이나 비공식 수정판을 이용해 WSA를 유지하려는 프로젝트가 존재하지만, 이는 Microsoft가 제공하는 공식 Windows 기능과 구분해야 한다. 보안 업데이트, Android 패치 수준, 서명과 배포 출처를 별도로 검토해야 한다.

WSA의 종료는 Windows가 Android 응용 프로그램을 기술적으로 실행할 수 없어서라기보다 제품 배포와 상점 전략이 종료된 결과다. WSL은 개발 도구와 서버 환경을 중심으로 독립적인 수요와 생태계를 확보한 반면, WSA는 Amazon Appstore의 제한된 응용 프로그램 목록과 모바일 앱을 PC에서 사용할 필요성 사이에서 충분한 플랫폼 규모를 만들지 못했다.

WSA는 Hyper-V, WSL 2와 비슷한 경량 가상화 기반을 사용했지만 목적은 달랐다.

Windows의 가상화 체계는 결과적으로 하나의 기술을 여러 목적으로 사용하는 구조다. Hyper-V는 완전한 가상 머신을 제공하고, VBS는 하이퍼바이저를 운영체제 보안 경계로 사용한다. Sandbox와 Hyper-V 격리 컨테이너는 경량 가상 머신을 일회성 실행 및 응용 프로그램 배포에 적용하고, WSL 2는 같은 기반에서 Linux 커널을 Windows 개발 환경에 통합한다.

Windows는 소비자용 데스크톱 운영체제로 널리 알려져 있지만, 동시에 Windows 응용 프로그램, 장치 드라이버, 게임, 기업용 소프트웨어, 웹 서비스와 다른 운영체제용 프로그램을 개발하는 주요 개발 플랫폼이다.

Windows 자체를 대상으로 하는 개발에서는 Windows SDK, Windows Driver Kit, Visual Studio, WinDbg와 Windows Performance Toolkit이 운영체제 API부터 커널 드라이버와 시스템 전체 성능까지 연결된 도구 체계를 제공한다. .NET, C++, Rust, Python, Java, JavaScript와 여러 언어의 컴파일러와 런타임도 Windows를 지원한다.

Windows는 전통적으로 그래픽 통합 개발 환경과 Microsoft 기술을 중심으로 강점을 형성했다. 반면 UNIX와 Linux는 운영체제에 기본 포함된 셸, 컴파일러, 스크립트 도구, 패키지 관리자와 서버 소프트웨어를 중심으로 개발 문화를 형성했다. 이러한 출발점 차이 때문에 Windows가 개발에 적합하지 않거나 개발 환경이 빈약하다는 인식이 생겼다.

현대 Windows에서는 PowerShell, Windows Terminal, WinGet, OpenSSH, Git, WSL, 컨테이너와 CMake 지원이 추가되면서 전통적인 Windows 네이티브 개발과 UNIX 계열 개발 흐름을 한 시스템에서 함께 사용할 수 있다. Visual Studio는 Windows 프로그램뿐 아니라 WSL과 원격 Linux 시스템을 대상으로 같은 CMake 프로젝트를 빌드하고 디버그할 수 있다.^[200][201]

Windows 개발 환경의 주요 구성

• Windows 네이티브 개발
  • Windows SDK
    • Windows API
    • Win32
    • COM과 WinRT
    • DirectX
    • 빌드 및 리소스 도구
  • Windows App SDK
    • WinUI 3
    • 최신 창과 수명 주기 API
    • WPF, Windows Forms와 Win32 연동
  • Windows Driver Kit
    • KMDF와 UMDF
    • 드라이버 헤더와 라이브러리
    • 드라이버 시험 도구
    • 배포와 서명 도구
• 개발 도구
  • Visual Studio
  • MSBuild
  • MSVC
  • .NET SDK
  • PowerShell
  • Windows Terminal
  • WinGet
  • Git
  • CMake와 Ninja
  • Visual Studio Code
• 다른 운영체제 대상 개발
  • Windows Subsystem for Linux
  • 원격 Linux 빌드와 디버깅
  • Docker와 컨테이너
  • Android 개발 도구
  • 크로스 컴파일러
  • 클라우드 및 웹 개발
• 디버깅과 분석
  • Visual Studio Debugger
  • WinDbg
  • Windows Performance Recorder
  • Windows Performance Analyzer
  • Event Tracing for Windows
  • Process Monitor
  • 드라이버 및 커널 검증 도구

Windows 개발 환경의 특징은 하나의 표준 도구만 강제하지 않는다는 점이다. Microsoft의 통합 도구를 사용할 수도 있고, GCC·Clang·LLVM·CMake·Ninja·Meson·Bazel과 UNIX 계열 도구를 Windows 네이티브 또는 WSL 환경에서 사용할 수도 있다.

Windows SDK

Windows Software Development Kit 또는 Windows SDK는 Windows 응용 프로그램을 개발하는 데 필요한 헤더, 라이브러리, 메타데이터, 컴파일 도구와 진단 도구를 제공하는 개발 키트다.

Windows SDK는 Windows API, Win32, COM, DirectX, 보안, 네트워크, 그래픽, 멀티미디어와 시스템 관리 인터페이스를 직접 사용할 수 있게 한다. Microsoft는 Windows SDK가 Windows 운영체제 API 전체에 접근하는 데 필요한 플랫폼 헤더, 라이브러리와 도구를 제공한다고 설명한다.^[202]

Windows SDK에는 일반적으로 다음 구성 요소가 포함된다.

• Windows API 헤더
• 가져오기 라이브러리
• Windows 메타데이터
• 리소스 컴파일러
• 매니페스트 도구
• 메시지 컴파일러
• 형식 라이브러리 도구
• 인증서와 서명 도구
• 디버깅 도구
• 성능 분석 도구
• 응용 프로그램 검증 도구
• 배포와 패키지 도구
• 코드 및 API 예제

C와 C++ 응용 프로그램은 Windows SDK의 헤더에서 API 함수, 구조체, 상수와 COM 인터페이스 선언을 가져온다. 가져오기 라이브러리는 실행 시 해당 시스템 DLL의 함수를 호출할 수 있도록 링커 정보를 제공한다.

Windows SDK를 사용하는 네이티브 빌드 흐름

1. 소스 코드에서 Windows API 헤더 포함
   ↓
2. MSVC, Clang 또는 다른 호환 컴파일러로 컴파일
   ↓
3. Windows SDK 가져오기 라이브러리와 연결
   ↓
4. PE 실행 파일 또는 DLL 생성
   ↓
5. 실행 시 Windows 시스템 DLL과 API 세트 연결
   ↓
6. Windows 운영체제 기능 호출

Windows SDK는 컴파일러 자체와 같은 제품은 아니다. Visual Studio의 C++ 워크로드는 일반적으로 MSVC 컴파일러와 Windows SDK를 함께 설치하지만, Windows SDK는 다른 빌드 시스템과 컴파일러에서도 사용할 수 있다.

Windows SDK 버전은 대상 운영체제의 최소 버전과 동일한 개념이 아니다. 새 SDK를 사용하면서도 응용 프로그램의 최소 지원 Windows 버전을 더 낮게 설정할 수 있다. 다만 새 API를 호출할 때에는 실제 실행 중인 Windows 버전에서 해당 API가 제공되는지 확인해야 한다.

응용 프로그램은 다음 방식으로 버전 차이를 처리할 수 있다.

• 최소 대상 Windows 버전 설정
• 컴파일 시 기능 매크로 사용
• 런타임 API 존재 여부 확인
• 동적 함수 로딩
• API 계약 확인
• 대체 구현 제공
• Windows App SDK의 버전 독립 구성 요소 사용

Windows SDK는 안정 버전과 미리 보기 버전으로 제공된다. 안정 SDK는 실제 제품 개발을 대상으로 하고, 미리 보기 SDK는 Windows Insider 빌드의 새로운 API와 실험 기능을 먼저 제공한다.^[203]

Windows App SDK는 Windows SDK를 대체하지 않고 그 위에서 동작한다. Windows 운영체제 버전에 직접 결합된 API 외에, NuGet 패키지와 재배포 가능한 런타임을 통해 최신 Windows 기능을 기존 Win32, WPF와 Windows Forms 응용 프로그램에도 제공한다.

Microsoft는 Windows App SDK가 WinUI 3뿐 아니라 WPF, Windows Forms와 Win32 같은 기존 데스크톱 프레임워크에 최신 Windows 기능을 제공한다고 설명한다.^[204]

Windows App SDK는 다음 기능을 포함한다.

• WinUI 3
• 현대적인 창 관리
• 응용 프로그램 수명 주기
• 알림
• 패키지 및 비패키지 응용 프로그램 지원
• 동적 종속성
• 최신 텍스트와 입력 기능
• Windows AI와 장치 기능
• 여러 Windows 버전에서 일관된 API 제공

Windows 응용 프로그램 개발자는 전통적인 Win32, Windows Forms, WPF, WinUI 3와 웹 기반 데스크톱 프레임워크 가운데 프로젝트 요구에 맞는 기술을 선택할 수 있다. Microsoft는 새 네이티브 Windows 응용 프로그램에는 Windows App SDK와 WinUI 3을 권장하면서도 WPF와 Windows Forms를 계속 지원한다.^[205]

Windows Driver Kit

Windows Driver Kit 또는 WDK는 Windows 장치 드라이버를 개발, 시험하고 배포하는 데 필요한 헤더, 라이브러리, 빌드 대상, 예제와 도구를 제공한다.

Microsoft는 WDK를 Windows 드라이버의 개발, 시험과 배포에 사용하는 소프트웨어 도구 집합으로 정의한다.^[206]

WDK는 다음 드라이버 개발 환경을 지원한다.

• Windows Driver Model
• Kernel-Mode Driver Framework
• User-Mode Driver Framework
• 파일 시스템 드라이버
• 네트워크 드라이버
• 저장 장치 드라이버
• 오디오 드라이버
• 그래픽 드라이버
• USB와 HID 장치
• 센서와 카메라
• 가상 장치
• 소프트웨어 전용 드라이버

WDK에는 일반적으로 다음 구성 요소가 포함된다.

• 커널과 드라이버 API 헤더
• KMDF와 UMDF 라이브러리
• 드라이버용 MSBuild 대상
• INF 검증 도구
• 카탈로그 생성 도구
• 드라이버 서명 도구
• 추적과 진단 도구
• 장치 설치 도구
• 정적 분석 규칙
• 드라이버 시험 도구
• 디버깅 확장
• 예제와 템플릿

WDK는 Windows SDK와 함께 사용된다. Windows SDK가 일반 응용 프로그램과 운영체제 API를 제공한다면, WDK는 커널 모드 인터페이스, 장치 드라이버 프레임워크와 드라이버별 빌드·시험 기능을 추가한다.

Windows 드라이버 개발 도구의 관계

• Visual Studio 또는 명령줄 빌드
  • MSVC 또는 Clang
  • MSBuild
  • Windows SDK
  • Windows Driver Kit
    • WDM
    • KMDF
    • UMDF
    • 드라이버 클래스 확장
    • INF와 패키지 도구
    • 시험 및 검증 도구
      • Driver Verifier
      • Static Driver Verifier
      • Code Analysis
      • WinDbg
      • Windows Hardware Lab Kit

Visual Studio와 WDK를 통합하면 드라이버 프로젝트 생성, 빌드, 대상 컴퓨터 배포, 테스트와 커널 디버깅을 하나의 개발 환경에서 수행할 수 있다. Microsoft의 WDK API 문서는 WDK가 Visual Studio와 Windows용 디버깅 도구에 통합된다고 설명한다.^[207]

드라이버 개발은 일반 사용자 모드 프로그램보다 운영체제 버전, 하드웨어, 동시성, 전원 관리와 보안 요구의 영향을 크게 받는다. WDK는 이러한 규칙을 직접 구현하는 부담을 줄이기 위해 KMDF, UMDF와 장치 종류별 클래스 확장을 제공한다.

드라이버 시험에는 다음 도구가 사용된다.

• Driver Verifier는 실행 중인 드라이버에 엄격한 메모리와 입출력 검사를 적용한다.
• Static Driver Verifier는 소스와 호출 경로를 분석해 드라이버 규칙 위반을 찾는다.
• Code Analysis는 C와 C++ 코드의 결함과 보안 문제를 검사한다.
• WinDbg는 커널 중지와 드라이버 상태를 분석한다.
• HLK는 Windows 하드웨어 호환성과 배포 인증 시험을 수행한다.

드라이버를 공개 배포하려면 INF와 바이너리로 드라이버 패키지를 만들고, 카탈로그를 생성하며, 요구되는 디지털 서명과 하드웨어 시험 절차를 거쳐야 한다.

WDK는 Visual Studio를 설치하지 않은 빌드 서버를 위한 Enterprise WDK와 NuGet 기반 구성도 제공한다. 이를 통해 자동화된 빌드와 지속적 통합 환경에서 드라이버를 재현 가능하게 빌드할 수 있다.

Visual Studio

Microsoft Visual Studio는 Windows를 중심으로 C++, C#, Visual Basic, .NET, 웹, 클라우드, 게임과 여러 플랫폼의 응용 프로그램을 개발하는 통합 개발 환경이다.

Visual Studio는 소스 코드 편집기만 제공하는 것이 아니라 컴파일러, 빌드 시스템, 디버거, 프로파일러, 테스트 실행기, UI 디자이너와 배포 도구를 하나의 프로젝트 및 솔루션 체계로 통합한다.

Visual Studio의 주요 구성 요소는 다음과 같다.

• 코드 편집기와 IntelliSense
• 프로젝트와 솔루션 관리
• MSBuild
• MSVC 컴파일러와 링커
• .NET SDK 통합
• 디버거
• 단위 시험 도구
• 프로파일러
• Git 통합
• NuGet 패키지 관리
• 코드 분석
• UI 디자이너
• 데이터베이스 도구
• Azure와 컨테이너 도구
• 원격 및 WSL 개발
• 확장 기능

Visual Studio Installer는 필요한 개발 분야를 워크로드 단위로 선택하도록 한다.

대표적인 워크로드는 다음과 같다.

• C++를 사용한 데스크톱 개발
• .NET 데스크톱 개발
• ASP.NET과 웹 개발
• Universal Windows Platform 개발
• Windows 응용 프로그램 개발
• 게임 개발
• Linux와 임베디드 C++ 개발
• 데이터 과학
• Azure 개발
• Python 개발
• Node.js 개발
• 모바일 개발

C++ 워크로드에는 MSVC, Windows SDK, CMake, Ninja, 테스트 도구와 선택적인 Clang 도구가 포함될 수 있다. Microsoft는 Visual Studio의 C++ 환경이 Windows 데스크톱뿐 아니라 모바일, Linux와 게임 개발 구성 요소도 제공한다고 설명한다.^[208]

MSBuild는 Visual Studio와 .NET 프로젝트에서 사용하는 빌드 엔진이다. 프로젝트 파일에 소스, 의존성, 컴파일 옵션, 대상과 작업을 선언하며 명령줄에서도 실행할 수 있다.

Visual Studio 솔루션은 여러 프로젝트를 하나의 작업 단위로 묶는다. 네이티브 라이브러리, .NET 응용 프로그램, 설치 패키지, 시험 프로젝트와 서버 구성 요소를 같은 솔루션 안에서 관리할 수 있다.

IntelliSense는 코드 완성, 매개변수 정보, 형식 추론, 오류 표시, 정의 이동과 참조 검색을 제공한다. C++에서는 실제 컴파일러 설정, 헤더와 전처리 조건을 바탕으로 코드를 분석한다.

Visual Studio는 CMake 프로젝트를 별도의 Visual Studio 프로젝트 파일로 변환하지 않고 직접 열 수 있다. CMakeLists.txt와 CMakePresets.json을 읽어 구성, 빌드, 시험과 디버깅을 수행한다.

같은 CMake 소스 트리를 다음 대상으로 구성할 수 있다.

• 로컬 Windows와 MSVC
• 로컬 Windows와 Clang
• WSL의 GCC 또는 Clang
• 원격 Linux 시스템
• 컨테이너
• 여러 프로세서 아키텍처

Microsoft는 Visual Studio의 CMake 지원이 같은 IDE에서 Windows, WSL과 원격 시스템을 대상으로 편집, 빌드와 디버깅을 제공한다고 설명한다.^[209]

Visual Studio의 강점은 Windows 전용 응용 프로그램에만 국한되지 않는다. Windows에서 소스를 편집하면서 실제 컴파일과 실행은 WSL 또는 원격 Linux에서 수행할 수 있고, Linux 시스템의 헤더를 가져와 IntelliSense와 디버깅에 사용한다.^[210]

게임 개발에서는 Visual Studio가 Unreal Engine, Unity, DirectX, Xbox GDK와 여러 네이티브 엔진의 주요 개발 환경으로 사용된다. GPU 디버깅, 메모리 분석과 게임 콘솔용 도구는 별도의 공급사 SDK와 결합될 수 있다.

Visual Studio Code는 Visual Studio와 별개의 제품이다. Visual Studio가 프로젝트, 디버거와 디자이너가 통합된 대형 IDE라면, Visual Studio Code는 확장 기능과 언어 서버를 중심으로 구성되는 경량 편집기다.

Windows 개발자는 Visual Studio만 사용해야 하는 것은 아니다. Visual Studio Code, JetBrains Rider와 CLion, Qt Creator, Eclipse, Neovim, Emacs와 여러 편집기를 사용할 수 있다. 컴파일러와 SDK가 설치되어 있다면 명령줄이나 다른 IDE에서도 Windows 프로그램을 빌드할 수 있다.

명령줄 개발 도구

Windows의 명령줄 개발 환경은 오랫동안 명령 프롬프트, 배치 파일과 Visual Studio 전용 개발자 셸을 중심으로 구성되었다. 현대 Windows에서는 PowerShell, Windows Terminal, WinGet, OpenSSH, WSL과 다양한 패키지 관리자가 추가되면서 UNIX 계열과 유사한 터미널 중심 작업 흐름도 사용할 수 있다.

Windows에서 사용할 수 있는 주요 셸과 터미널은 다음과 같다.

• Command Prompt
• PowerShell
• 현대 PowerShell
• Windows Terminal
• Developer Command Prompt
• Developer PowerShell
• WSL의 Bash와 다른 UNIX 셸
• Git Bash
• MSYS2와 Cygwin 셸

Developer Command Prompt와 Developer PowerShell은 MSVC, MSBuild, Windows SDK와 Visual Studio 도구의 경로와 환경 변수를 설정한 셸이다. 일반 명령 프롬프트에서 직접 환경 설정 스크립트를 실행해 같은 환경을 만들 수도 있다.

대표적인 Windows 네이티브 개발 명령은 다음과 같다.

Windows에서는 CMake, Ninja, Meson, Bazel과 GNU Make 같은 외부 빌드 도구도 사용할 수 있다. MSVC뿐 아니라 LLVM의 Clang, MinGW-w64의 GCC와 여러 언어별 컴파일러를 설치할 수 있다.

WinGet은 명령줄에서 개발 도구와 응용 프로그램을 검색, 설치, 업그레이드, 제거하고 구성할 수 있게 한다. Microsoft는 WinGet을 Windows Package Manager 서비스의 명령줄 클라이언트로 설명한다.^[211]

WinGet은 다음 작업에 사용할 수 있다.

• Git 설치
• 언어 런타임 설치
• IDE와 편집기 설치
• CMake와 빌드 도구 설치
• 패키지 일괄 업그레이드
• 개발 환경 구성 파일 적용
• 새 컴퓨터의 도구 재설치

Windows에는 WinGet 외에도 다음 패키지 관리 체계가 사용된다.

• NuGet
• vcpkg
• Chocolatey
• Scoop
• MSYS2의 pacman
• Python의 pip
• Rust의 Cargo
• Node.js의 npm과 pnpm
• .NET 도구
• WSL 배포판의 APT, DNF와 pacman

vcpkg는 C와 C++ 라이브러리의 소스 빌드와 의존성 관리를 제공하며 Visual Studio, CMake와 여러 운영체제에서 사용할 수 있다. NuGet은 .NET뿐 아니라 네이티브 라이브러리와 Windows SDK·WDK 구성 요소 배포에도 사용될 수 있다.

Windows Terminal은 PowerShell, Command Prompt, WSL과 SSH 셸을 탭과 창 분할로 실행한다. 하나의 터미널에서 Windows 네이티브 빌드와 Linux 빌드를 오갈 수 있다.

OpenSSH 클라이언트와 서버를 사용하면 Git 저장소, 원격 Linux 서버, 빌드 시스템과 Windows 컴퓨터에 표준 SSH 방식으로 연결할 수 있다.

Windows Subsystem for Linux는 Windows 개발 환경의 성격을 크게 바꿨다. 개발자는 Windows의 그래픽 응용 프로그램과 드라이버를 사용하면서 동일한 컴퓨터에서 실제 Linux 커널, Bash, GNU 도구, 패키지 관리자와 서버 프로그램을 실행할 수 있다.

Microsoft는 WSL이 Ubuntu, Debian, Kali Linux와 다른 배포판의 Linux 파일 시스템, 명령줄 도구와 GUI 응용 프로그램을 Windows에서 직접 실행하도록 한다고 설명한다.^[212]

Windows와 WSL은 서로 실행 파일을 호출할 수 있다.

• PowerShell에서 Linux 명령 실행
• Bash에서 Windows 실행 파일 실행
• 같은 프로젝트를 Windows와 Linux 도구로 빌드
• Windows 편집기에서 WSL 파일 편집
• WSL 서버를 Windows 브라우저에서 접속
• Docker와 Linux 컨테이너 사용

Windows 11에는 새 개발 장치를 명령 하나로 구성하기 위한 Windows Dev Config도 제공된다. Microsoft는 이를 새 Windows 11 설치를 개발용 워크스테이션으로 구성하는 단일 구성 방식으로 설명한다.^[213]

디버깅과 성능 분석

Windows는 사용자 모드 응용 프로그램, 서비스, 커널, 장치 드라이버, 네트워크와 시스템 전체 성능을 서로 다른 수준에서 분석할 수 있는 도구를 제공한다.

주요 디버깅과 분석 도구는 다음과 같다.

• Visual Studio Debugger
• WinDbg
• CDB와 KD
• Windows Performance Recorder
• Windows Performance Analyzer
• Event Tracing for Windows
• Visual Studio Profiler
• Performance Monitor
• Process Explorer
• Process Monitor
• Resource Monitor
• Driver Verifier
• Application Verifier
• PIX
• GPU 제조사 분석 도구

Visual Studio Debugger는 C++, C#, Visual Basic, JavaScript와 여러 언어의 로컬 및 원격 디버깅을 지원한다. 중단점, 단계 실행, 호출 스택, 변수, 메모리, 레지스터, 스레드와 모듈 상태를 확인할 수 있다.

혼합 모드 디버깅을 사용하면 같은 프로세스의 관리형 .NET 코드와 네이티브 코드를 함께 분석할 수 있다. 자식 프로세스, 원격 컴퓨터, WSL과 Linux 프로그램도 프로젝트 구성에 따라 디버깅할 수 있다.

Visual Studio의 진단 도구는 디버깅 중 CPU 사용량, 메모리, 이벤트와 실행 시간을 표시한다. 별도의 Performance Profiler에서는 디버거 없이 다음 항목을 더 정밀하게 수집할 수 있다.

• CPU 샘플링
• .NET 객체 할당
• 메모리 사용
• 파일 입출력
• 데이터베이스
• 비동기 작업
• 이벤트
• GPU 사용량
• 계측 기반 실행 시간

Microsoft는 Visual Studio가 CPU와 메모리 사용량을 비롯한 응용 프로그램 수준 문제를 분석하는 여러 프로파일링 및 진단 도구를 제공한다고 설명한다.^[214]

WinDbg는 Windows 사용자 모드와 커널 모드 디버깅을 위한 전문 디버거다. 실행 중인 프로세스와 커널에 연결하거나, 충돌 덤프와 메모리 덤프를 사후 분석할 수 있다.

WinDbg는 다음 작업에 사용된다.

• 사용자 모드 충돌 분석
• 블루스크린 덤프 분석
• 커널과 드라이버 디버깅
• 교착 상태와 잠금 분석
• 메모리 손상 조사
• 프로세스와 스레드 구조 분석
• 핸들, 객체와 가상 메모리 확인
• PnP와 전원 문제 분석
• 확장 명령과 스크립트 실행

Windows가 버그 검사를 수행하면 메모리 덤프를 생성할 수 있다. WinDbg는 버그 검사 코드, 호출 스택, 문제 드라이버, 예외 기록과 커널 객체를 조사한다.

심볼은 함수명, 소스 위치, 자료형과 전역 변수 정보를 디버거에 제공한다. Microsoft Symbol Server에서 Windows 공개 심볼을 내려받고, 자체 프로그램의 PDB 파일을 함께 사용하면 호출 스택과 메모리를 더 정확하게 분석할 수 있다.

Event Tracing for Windows 또는 ETW는 커널, 드라이버와 사용자 모드 구성 요소가 낮은 비용으로 이벤트를 기록하는 추적 기반 시설이다. 공급자가 이벤트를 생성하고, 세션이 이를 수집하며, 분석 도구가 시간순으로 해석한다.

ETW는 다음 정보를 수집할 수 있다.

• CPU 스케줄링
• 문맥 전환
• 디스크와 파일 입출력
• 네트워크
• 메모리와 페이지 폴트
• 프로세스와 스레드
• 전원
• 그래픽과 GPU
• 오디오와 미디어
• 응용 프로그램별 사용자 이벤트

Windows Performance Toolkit은 Windows Performance Recorder와 Windows Performance Analyzer로 구성된다. WPR은 ETW 기반 추적을 기록하고, WPA는 수집된 데이터를 시간축, 표와 그래프로 분석한다.^[215]

WPR과 WPA를 이용한 성능 분석

1. 분석할 문제와 기록 프로필 선택
   ↓
2. Windows Performance Recorder로 ETW 추적 시작
   ↓
3. 느린 시작, 끊김이나 높은 CPU 문제 재현
   ↓
4. 추적 종료 후 ETL 파일 저장
   ↓
5. Windows Performance Analyzer에서 파일 열기
   ↓
6. CPU, 디스크, 메모리, GPU와 스레드 데이터 비교
   ↓
7. 호출 스택과 시간 구간으로 병목 원인 확인

WPA는 응용 프로그램 하나뿐 아니라 운영체제 전체의 상호 작용을 분석한다. 예를 들어 게임의 프레임 끊김이 게임 스레드, 그래픽 드라이버, 저장 장치, 백그라운드 서비스나 전원 정책 가운데 어디에서 발생했는지 같은 시간축에서 비교할 수 있다.

Performance Monitor는 성능 카운터를 실시간으로 표시하고 장기간 기록한다. CPU, 메모리, 디스크, 네트워크, 프로세스와 서버 역할별 카운터를 조합할 수 있다.

Process Monitor는 파일 시스템, 레지스트리, 프로세스와 스레드 활동을 실시간으로 추적한다. 설치 프로그램 오류, 접근 거부, 누락된 파일과 레지스트리 설정 문제를 분석하는 데 사용된다.

Process Explorer는 프로세스 트리, 핸들, DLL, 토큰, 서명과 자원 사용량을 작업 관리자보다 상세하게 보여준다.

DirectX 게임과 그래픽 응용 프로그램에는 Visual Studio Graphics Diagnostics, PIX와 GPU 제조사의 Nsight·Radeon GPU Profiler 같은 도구가 사용된다. CPU 명령 제출, GPU 이벤트, 자원, 셰이더와 프레임 시간을 분석한다.

Windows의 분석 도구가 강력함에도 불구하고 종류가 많고 목적이 분산되어 있다는 점은 진입 장벽이 될 수 있다. 간단한 응용 프로그램 오류는 Visual Studio로 분석하지만, 커널은 WinDbg, 시스템 전체 성능은 WPA, 파일과 레지스트리는 Process Monitor를 사용해야 한다.

응용 프로그램 배포

Windows 응용 프로그램 배포는 단순한 실행 파일 복사부터 MSI, MSIX, Microsoft Store, 자체 설치 프로그램, 기업 관리와 포터블 패키지까지 여러 방식으로 이루어진다.

주요 배포 방식은 다음과 같다.

• 실행 파일과 DLL 직접 복사
• 압축 파일 또는 포터블 배포
• 자체 설치 프로그램
• Windows Installer 패키지
• MSIX
• Microsoft Store
• ClickOnce
• NuGet과 언어별 패키지
• WinGet 매니페스트
• 기업용 Intune과 Configuration Manager
• 웹 기반 설치
• 컨테이너 이미지

전통적인 Win32 프로그램은 setup.exe 형태의 설치 프로그램이나 MSI를 사용해 파일, 레지스트리, 서비스, 드라이버와 런타임을 설치한다.

Windows Installer 또는 MSI는 제품, 기능과 구성 요소를 선언하고 설치, 복구, 패치와 제거를 관리한다. 기업 환경에서는 무인 설치, 변환 파일과 중앙 배포에 널리 사용된다.

MSI는 성숙하고 다양한 시스템 변경을 지원하지만 작성 체계가 복잡하고, 설치 프로그램이 임의의 사용자 정의 작업을 수행하면 일관된 롤백과 제거가 어려워질 수 있다.

MSIX는 Windows의 현대적인 패키지 형식이다. 패키지 정체성, 디지털 서명, 선언형 매니페스트, 파일 무결성, 차등 업데이트와 정리 가능한 제거를 제공한다.

Microsoft는 MSIX를 Windows 응용 프로그램에 안정적인 설치와 제거 환경을 제공하는 현대적인 패키징 형식으로 설명한다.^[216]

MSIX 패키지는 다음 항목을 포함한다.

• 응용 프로그램 파일
• 패키지 매니페스트
• 아이콘과 리소스
• 파일 해시
• 디지털 서명
• 의존성 정보
• 파일 연결과 프로토콜
• 응용 프로그램 서비스와 확장
• 대상 아키텍처와 버전

MSIX는 설치 파일을 예측 가능한 위치에 배치하고 패키지의 파일과 일부 레지스트리 변경을 추적하므로 제거 후 시스템에 남는 항목을 줄일 수 있다.

MSIX는 다음 경로로 배포할 수 있다.

• Microsoft Store
• App Installer
• 웹 서버
• PowerShell
• WinGet
• Microsoft Intune
• Configuration Manager
• DISM을 통한 이미지 프로비저닝
• 기업 내부 배포 서버

App Installer는 Microsoft Store에 게시하지 않은 MSIX 패키지도 사용자가 설치하고 업데이트하도록 할 수 있다.^[217]

Windows App SDK 응용 프로그램은 패키지형 또는 비패키지형으로 배포할 수 있다. 패키지형 응용 프로그램은 MSIX 정체성과 설치 기능을 사용하고, 비패키지형 응용 프로그램은 기존 MSI나 자체 설치 프로그램을 유지하면서 Windows App SDK 런타임을 사용할 수 있다.

Windows App SDK는 다음 배포 모델을 제공한다.

• 프레임워크 종속 패키지
• 자체 포함 패키지
• 외부 위치를 사용하는 패키지
• 비패키지 응용 프로그램

프레임워크 종속 응용 프로그램은 공유 Windows App SDK 런타임을 사용해 설치 크기를 줄이고, 자체 포함 응용 프로그램은 필요한 런타임을 함께 배포하여 외부 설치 의존성을 줄인다.^[218]

.NET 응용 프로그램도 프레임워크 종속과 자체 포함 배포를 선택할 수 있다. 자체 포함 배포는 대상 컴퓨터에 해당 .NET 런타임이 설치되어 있지 않아도 실행할 수 있지만 배포 크기가 커진다.

네이티브 C와 C++ 프로그램은 정적 또는 동적 런타임 연결을 선택할 수 있다. 동적 MSVC 런타임을 사용하면 대상 컴퓨터에 Visual C++ Redistributable을 설치해야 할 수 있고, 정적 연결은 각 프로그램에 런타임 코드를 포함한다.

게임과 대형 응용 프로그램은 전용 런처와 콘텐츠 전달망을 사용해 기본 실행 파일, 대용량 자원, 선택적 언어 팩과 패치를 배포한다. Steam, Microsoft Store와 다른 상점은 설치, 라이선스, 업데이트와 복구 기능을 제공한다.

기업 환경에서는 응용 프로그램 패키지를 사용자, 장치 그룹, 운영체제 버전과 규정 준수 상태에 따라 배포한다. Intune은 서명된 MSIX와 여러 Win32 설치 프로그램을 관리 장치에 자동으로 설치할 수 있다.^[219]

응용 프로그램 배포에는 설치뿐 아니라 다음 요소가 포함된다.

• 코드 서명
• 업데이트 채널
• 자동 업데이트
• 데이터 이전
• 설정 호환성
• 의존성 설치
• 충돌 복구
• 롤백
• 제거
• 사용자 데이터 보존
• 보안 취약점 대응
• 지원 수명 주기

Windows 실행 파일 자체에는 코드 서명을 적용할 수 있다. Authenticode 서명은 게시자와 파일 무결성을 확인하고, SmartScreen과 조직의 응용 프로그램 제어 정책이 신뢰를 판단하는 데 사용된다.

개발 플랫폼으로서 Windows

Windows가 소비자용 운영체제라는 사실과 개발 플랫폼이라는 사실은 서로 충돌하지 않는다. Windows는 세계적으로 널리 보급된 데스크톱 운영체제였기 때문에 Windows 자체를 대상으로 하는 소프트웨어 산업이 매우 커졌고, 이를 지원하는 개발 도구도 함께 발전했다.

Windows에서 전통적으로 강했던 개발 분야는 다음과 같다.

• 데스크톱 응용 프로그램
• 기업용 업무 프로그램
• 장치 드라이버
• 게임과 그래픽 소프트웨어
• .NET 응용 프로그램
• Microsoft Office 확장
• Active Directory와 Windows Server 관리
• 산업용 장비와 임베디드 시스템
• 상용 설계 및 제작 도구
• 데이터베이스 클라이언트와 서버
• Xbox와 Windows 게임

Windows는 특히 IDE 기반 개발에서 강한 환경을 제공했다. Visual Studio는 컴파일, UI 설계, 디버깅, 프로파일링, 시험과 배포를 일찍부터 하나의 제품 안에 통합했다.

네이티브 디버거, 커널 디버거와 성능 분석 도구의 깊이도 Windows 개발 환경의 중요한 특징이다. Windows 자체의 비공개 내부 구현이 존재하지만, 공개 심볼, ETW, WinDbg와 WDK를 통해 응용 프로그램과 드라이버가 운영체제와 상호 작용하는 과정을 상세하게 분석할 수 있다.

개발에 뒤처졌다는 인식의 형성

Windows가 개발에 뒤처졌다거나 개발 환경이 빈약하다는 평가는 모든 개발 분야를 대상으로 한 사실이라기보다, 주로 UNIX식 서버·오픈 소스 개발 경험과 비교하면서 형성되었다.

초기의 UNIX와 이후 Linux에서는 운영체제 자체가 개발 환경에 가까웠다. 셸, 파이프, 텍스트 처리 도구, 컴파일러, Make, SSH, 패키지 관리자와 서버 프로그램을 같은 명령줄 체계에서 사용할 수 있었다.

전통적인 UNIX 개발 흐름은 다음과 같이 단순하게 연결되었다.

전통적인 UNIX 계열 개발 흐름

1. 패키지 관리자로 컴파일러와 라이브러리 설치
   ↓
2. 셸에서 소스와 빌드 스크립트 편집
   ↓
3. Make 또는 다른 명령줄 빌드 실행
   ↓
4. 프로그램과 서버를 같은 환경에서 시험
   ↓
5. SSH와 셸 스크립트로 원격 시스템 배포
   ↓
6. 생산 서버도 유사한 UNIX 환경에서 실행

반면 과거 Windows에서는 개발 도구가 운영체제 기본 설치에 포함되지 않았다. Visual Studio, Windows SDK, 컴파일러와 여러 런타임을 별도로 설치해야 했고, 프로젝트 설정은 IDE와 전용 프로젝트 파일에 강하게 연결되는 경우가 많았다.

Windows의 초기 명령 프롬프트와 배치 언어는 UNIX 셸에 비해 다음 영역에서 불편하다는 평가를 받았다.

• 구조화된 파이프라인 부족
• 제한적인 문자열과 배열 처리
• 복잡한 인용과 이스케이프 규칙
• 표준 명령줄 도구의 부족
• 일관된 패키지 관리자 부재
• 셸 스크립트의 재사용성
• 원격 관리와 SSH의 기본 통합 부족
• 개발 도구 설치 자동화 부족

Windows에서 개발 도구와 라이브러리를 설치하는 방식도 통일되지 않았다. 각 언어와 프로그램의 설치 프로그램을 웹사이트에서 직접 받아야 했고, 시스템 환경 변수와 경로를 수동으로 설정하는 경우가 많았다.

C와 C++ 생태계에서는 Visual Studio 프로젝트, MSBuild, MSVC ABI와 Windows SDK가 강력했지만, 오픈 소스 프로젝트가 사용하는 Autotools, Makefile, POSIX 셸 스크립트와 UNIX API를 그대로 사용하기 어려웠다.

오픈 소스 프로젝트를 Windows로 이식하려면 다음 차이를 처리해야 했다.

• POSIX와 Win32 API 차이
• 파일 경로와 드라이브 문자
• 경로 구분자
• 프로세스 생성 방식
• 신호와 터미널
• 파일 권한
• 심볼릭 링크
• 소켓과 파일 기술자
• 동적 라이브러리 형식
• 컴파일러 ABI
• 문자 인코딩
• 줄바꿈 관례
• 대소문자를 구분하지 않는 기본 파일 시스템

Linux 서버가 웹, 클라우드, 컨테이너와 오픈 소스 인프라의 중심이 되면서 개발 환경과 배포 환경을 같게 유지하려는 개발자에게 Linux가 자연스러운 선택이 되었다.

Ruby on Rails, Python, Node.js, PHP, Docker와 여러 DevOps 도구는 UNIX 계열을 우선 대상으로 발전한 경우가 많았다. Windows에서도 사용할 수 있었지만, 문서와 커뮤니티 예제가 Bash, APT, GNU 도구와 POSIX 경로를 기본으로 가정하는 경우가 많았다.

또한 Windows는 오랫동안 사유 운영체제와 Microsoft 중심 생태계라는 인상을 가졌다. 자유 소프트웨어 개발자에게는 GCC, GNU 도구와 패키지 관리자가 기본 제공되는 Linux가 더 개방적이고 수정 가능한 환경으로 받아들여졌다.

실제 Windows 개발 환경의 강점과 약점

Windows의 전통적인 개발 환경은 빈약했다기보다 UNIX와 다른 방향으로 발전했다.

Windows가 강했던 영역은 다음과 같다.

• 높은 수준의 통합 IDE
• 데스크톱 GUI 개발
• 네이티브 코드 디버깅
• 커널과 드라이버 개발
• .NET과 기업용 개발
• DirectX와 게임 개발
• 상용 도구와 기술 지원
• Windows API와 COM
• 데이터베이스와 Office 통합
• 하드웨어 공급사 SDK

UNIX와 Linux가 강했던 영역은 다음과 같다.

• 셸 중심 자동화
• 운영체제에 통합된 개발 도구
• 패키지 관리자
• 서버와 생산 환경의 일치
• POSIX 호환성
• 원격 개발과 SSH
• 오픈 소스 라이브러리 빌드
• 컨테이너와 클라우드 인프라
• 작은 도구의 조합
• 개발 환경의 스크립트화

Visual Studio는 그래픽 IDE를 선호하는 개발자에게 매우 생산적인 환경이었지만, 단순한 텍스트 편집기와 셸 도구를 조합하는 개발자에게는 무겁고 폐쇄적으로 느껴질 수 있었다.

Windows SDK와 Visual Studio 프로젝트는 Windows 응용 프로그램을 개발할 때 강력했지만, 운영체제와 무관한 소프트웨어를 개발하려는 경우 Microsoft 전용 프로젝트 구조가 불필요한 종속성처럼 보일 수 있었다.

현대 Windows 개발 환경의 변화

현대 Windows는 UNIX 계열 개발 흐름과의 차이를 줄이는 방향으로 발전했다.

주요 변화는 다음과 같다.

• PowerShell 도입
• Windows Terminal 제공
• WinGet 패키지 관리자
• OpenSSH 기본 제공
• Git와 CMake의 공식 통합
• WSL과 실제 Linux 커널
• Docker와 컨테이너 지원
• Visual Studio의 Linux 원격 개발
• Visual Studio Code와 원격 확장
• 오픈 소스 .NET
• Clang과 LLVM 지원
• Windows App SDK의 공개 개발
• 개발 환경 구성 자동화

PowerShell은 문자열만 전달하는 전통적인 셸 파이프라인 대신 .NET 객체를 전달하고, Windows 관리 API와 원격 관리에 직접 연결된다. PowerShell 자체도 오픈 소스·크로스 플랫폼 제품으로 발전했다.

WSL은 Windows와 Linux 가운데 하나만 선택해야 했던 구조를 바꿨다. 개발자는 Windows의 GPU 드라이버, 게임, Office, Adobe 도구와 Visual Studio를 유지하면서 Linux 셸, 서버와 빌드 환경을 같은 컴퓨터에서 사용할 수 있다.

Visual Studio와 Visual Studio Code는 WSL 환경의 소스를 직접 편집하고, 컴파일러와 디버거는 Linux 안에서 실행할 수 있다. Microsoft는 WSL 개발 환경을 Windows 개발 도구의 정식 구성으로 제공한다.^[220]

CMake와 CMakePresets.json은 IDE, 명령줄, Windows, Linux와 지속적 통합 환경에서 같은 프로젝트 구성을 공유할 수 있게 한다.

WinGet과 개발 구성 파일은 새 컴퓨터에 필요한 도구를 선언적으로 설치하는 기반을 제공한다. 언어별 패키지 관리자와 WSL의 Linux 패키지 관리자를 함께 사용할 수 있다.

따라서 현대 Windows는 Windows 네이티브 응용 프로그램을 만드는 폐쇄적인 전용 환경에만 머물지 않는다. 하나의 장치에서 다음 작업을 함께 수행할 수 있는 혼합 개발 플랫폼으로 발전했다.

• Win32와 Windows App SDK 개발
• .NET 데스크톱과 서버 개발
• DirectX 게임 개발
• Windows 드라이버 개발
• Linux 서버와 명령줄 프로그램 개발
• 웹과 클라우드 개발
• Android와 모바일 개발
• Linux와 Windows 컨테이너 개발
• 원격 시스템과 임베디드 장치 개발

Windows가 Linux를 완전히 대체하거나 Linux가 Windows 개발 도구의 강점을 없앤 것은 아니다. Windows는 강력한 네이티브 IDE, 디버거, 상용 도구와 데스크톱 생태계를 제공하고, WSL은 UNIX 계열 도구와 생산 서버 환경을 연결한다.

현대 Windows 개발 환경의 특징은 두 계열 가운데 하나를 모방하는 데 있지 않고, Windows 네이티브 도구와 Linux 사용자 공간을 같은 워크스테이션에서 조합할 수 있다는 데 있다.

Windows는 개인용 컴퓨터에서 널리 사용되는 x86과 x86-64를 중심으로 발전했지만, Windows NT는 처음부터 특정 프로세서 하나에만 종속되지 않는 운영체제로 설계되었다. 초기 Windows NT는 x86뿐 아니라 MIPS와 DEC Alpha에서 실행되었고, 이후 PowerPC, Itanium, ARM과 ARM64로 이식되었다.

하드웨어 추상화 계층, 프로세서별 커널 코드, 이식 가능한 C 기반 실행부와 Portable Executable 형식은 하나의 Windows 계열을 서로 다른 명령어 집합에서 구현하는 기반이 되었다. Microsoft는 Windows NT 계열이 과거 Itanium, PowerPC, DEC Alpha와 MIPS를 지원했고, 이후 x86, x64, ARM과 ARM64로 이어졌다고 설명한다.^[221]

현대의 개인용 Windows는 x86-64와 ARM64를 주요 하드웨어 플랫폼으로 사용한다. Windows 11은 64비트 프로세서 또는 시스템 온 칩을 요구하며 32비트 운영체제판을 제공하지 않는다.^[222] 다만 x86-64 Windows는 WOW64를 통해 기존 32비트 x86 응용 프로그램을 실행하며, ARM64 Windows는 네이티브 ARM64 응용 프로그램과 에뮬레이션된 x86·x64 응용 프로그램을 함께 지원한다.

Windows의 주요 프로세서 계보

• 초기 소비자용 Windows
  • Intel 8086 계열
    • 16비트 x86
    • 32비트 x86
    • x86-64
• Windows NT
  • x86
  • MIPS
  • DEC Alpha
  • PowerPC
  • Itanium
  • x86-64
  • ARM
  • ARM64
• 현대 Windows 클라이언트
  • x86-64
    • 네이티브 x64 응용 프로그램
    • WOW64 기반 x86 응용 프로그램
  • ARM64
  • 네이티브 ARM64 응용 프로그램
  • Arm64EC 혼합 응용 프로그램
  • Prism 기반 x86 응용 프로그램
  • Prism 기반 x64 응용 프로그램

Windows 실행 파일은 일반적으로 PE 형식을 사용한다. PE 형식은 프로세서 아키텍처를 나타내는 기계 유형, 코드와 데이터 섹션, 가져오기·내보내기 정보, 재배치와 예외 처리 정보를 포함한다. 같은 기본 파일 형식을 사용하더라도 x86, x64와 ARM64 실행 파일의 명령어와 ABI는 서로 다르다.

Microsoft는 Portable Executable이라는 명칭이 이 형식이 하나의 프로세서 아키텍처에만 한정되지 않는다는 의미에서 붙었다고 설명한다.^[223]

x86

x86은 Intel 8086에서 시작되어 80286, 80386과 이후의 IA-32 프로세서로 확장된 명령어 집합 계열이다. Windows는 초창기부터 IBM PC 호환 컴퓨터의 x86 하드웨어와 함께 성장했다.

Windows 1.x부터 Windows 3.x까지는 16비트 x86과 MS-DOS를 기반으로 했다. 초기에는 8086의 실모드를 사용했지만, Windows/286과 Windows/386 및 Windows 3.x는 80286과 80386의 보호 모드, 확장 메모리와 가상 8086 모드를 활용했다.

Windows 3.x는 실행 환경에 따라 다음 모드를 사용했다.

• 실모드
• 표준 모드
• 386 확장 모드

실모드는 초기 x86과 호환되는 실행 환경이었고, 표준 모드는 80286 보호 모드를 사용했다. 386 확장 모드는 80386의 페이징과 가상 8086 모드를 이용해 여러 DOS 가상 머신과 더 넓은 메모리 공간을 제공했다.

Windows 95, Windows 98와 Windows Me는 32비트 x86 기능을 크게 확대했지만 16비트 Windows와 MS-DOS 구성 요소도 함께 사용했다. 따라서 완전한 순수 32비트 운영체제라기보다 16비트와 32비트 구성 요소가 혼합된 구조였다.

Windows NT는 처음부터 32비트 보호 모드 운영체제로 x86을 지원했다. 응용 프로그램마다 분리된 가상 주소 공간, 사용자 모드와 커널 모드, 선점형 멀티태스킹과 메모리 보호를 제공했다.

32비트 x86 Windows는 일반적으로 하나의 프로세스에 4GiB 크기의 가상 주소 공간을 제공한다. 기본적인 클라이언트 구성에서는 이를 사용자 공간과 커널 공간으로 나누며, 실제 사용할 수 있는 물리 메모리와 주소 공간은 Windows 에디션, 부팅 설정과 하드웨어에 따라 달라진다.

x86 Windows가 오랫동안 사용된 이유는 다음과 같다.

• IBM PC 호환 하드웨어의 대규모 보급
• DOS와 16비트 Windows 응용 프로그램 호환성
• Intel과 AMD 프로세서의 성능 향상
• PC 제조사와 주변 장치 공급사의 드라이버 지원
• Win32 응용 프로그램 생태계
• DirectX와 PC 게임
• 기업용 x86 프로그램과 관리 도구
• 낮은 가격의 범용 하드웨어

32비트 Windows NT는 16비트 Windows 프로그램과 DOS 응용 프로그램을 실행하기 위해 Windows on Windows와 NT Virtual DOS Machine을 제공했다. x86 프로세서의 가상 8086 모드를 이용해 기존 프로그램을 별도의 환경에서 실행할 수 있었다.

그러나 32비트 주소 공간은 대용량 메모리, 고성능 작업과 현대 보안 기능에서 제약이 되었다. 물리 주소 확장을 이용하면 일부 서버 에디션에서 4GiB 이상의 물리 메모리를 관리할 수 있었지만, 개별 32비트 프로세스의 주소 공간과 포인터 크기는 그대로 유지되었다.

Windows 10은 32비트 x86판과 64비트판을 함께 제공한 마지막 주요 클라이언트 Windows 계열이다. Microsoft는 Windows 10 버전 2004부터 새 OEM 시스템에 64비트 빌드를 요구했지만 기존 장치와 이전 설치를 위한 32비트 Windows 10 업데이트는 계속 제공했다.

Windows 11은 32비트 x86 운영체제판을 제공하지 않는다. 다만 x86-64판의 WOW64와 ARM64판의 에뮬레이션을 통해 많은 32비트 x86 응용 프로그램은 계속 실행할 수 있다.

32비트 운영체제 지원 종료와 32비트 응용 프로그램 지원 종료는 같은 의미가 아니다. 현대 Windows의 운영체제와 커널은 64비트로 실행되지만, 사용자 모드의 기존 x86 응용 프로그램에는 별도의 호환 환경을 제공한다.

x86-64

x86-64는 x86 명령어 집합을 64비트 주소와 레지스터로 확장한 아키텍처다. AMD가 AMD64라는 이름으로 처음 구현했고, Intel도 호환되는 Intel 64를 도입했다. Windows와 Microsoft 개발 도구에서는 일반적으로 x64라고 부른다.

Microsoft는 초기에는 Itanium을 위한 64비트 Windows를 개발했지만, 범용 PC와 서버 시장에서는 기존 x86 응용 프로그램과 높은 호환성을 가진 x86-64가 주류가 되었다.

x86-64는 기존 x86에 다음과 같은 기능을 추가한다.

• 64비트 범용 레지스터
• 더 많은 범용 레지스터
• 확장된 가상·물리 주소 공간
• 64비트 정수 연산
• 개선된 함수 호출 규약
• 추가 SIMD 명령어
• 하드웨어 기반 실행 방지
• 32비트 호환 실행 모드

Windows XP Professional x64 Edition과 Windows Server 2003 x64 Editions는 Microsoft의 초기 주요 x64 Windows 제품이었다. 이후 Windows Vista, Windows 7과 Windows Server는 x86과 x64판을 병행했고, x64 하드웨어와 응용 프로그램의 보급에 따라 64비트판이 기본이 되었다.

x64 Windows는 다음과 같은 주요 구성 요소를 모두 64비트로 실행한다.

• Windows 커널
• 실행부
• 커널 모드 드라이버
• 시스템 서비스의 대부분
• 64비트 시스템 DLL
• 64비트 셸과 관리 도구
• 64비트 응용 프로그램

커널 모드에서는 32비트와 64비트 드라이버를 혼합할 수 없다. x64 Windows에는 x64용으로 컴파일되고 적절히 서명된 커널 드라이버가 필요하다. 오래된 32비트 드라이버만 제공되는 장치는 64비트 Windows에서 사용할 수 없다.

사용자 모드에서는 WOW64가 32비트 x86 응용 프로그램을 실행한다. WOW64는 x86 명령어를 x64 프로세서의 호환 모드에서 직접 실행하고, 32비트 시스템 호출과 자료 구조를 64비트 커널 환경에 연결한다.

x64 Windows의 실행 환경

• x64 Windows 커널
  • x64 시스템 서비스
  • x64 장치 드라이버
  • 네이티브 x64 프로세스
    • 64비트 시스템 DLL
  • WOW64 프로세스
    • 32비트 x86 실행 코드
    • 32비트 시스템 DLL
    • 시스템 호출 변환
    • 파일 시스템 리디렉션
    • 레지스트리 보기 분리

Microsoft는 WOW64를 32비트 Windows 응용 프로그램이 64비트 Windows에서 실행될 수 있게 하는 x86 호환 환경으로 설명한다.^[224]

x64 프로세스와 x86 프로세스는 서로 다른 DLL 형식을 사용한다. x64 프로세스는 32비트 DLL을 직접 적재할 수 없고, x86 프로세스도 64비트 DLL을 직접 적재할 수 없다. 서로 다른 아키텍처의 구성 요소는 별도 프로세스와 COM, RPC, 파이프나 다른 프로세스 간 통신으로 연결한다.

x64 Windows의 주요 장점은 넓은 주소 공간이다. 대규모 데이터베이스, 그래픽 제작, 과학 계산, 게임과 가상 머신은 32비트 프로세스의 주소 공간 한계를 넘어 더 많은 메모리를 직접 사용할 수 있다.

Windows가 실제로 지원하는 최대 메모리와 프로세서 수는 아키텍처의 이론적 한계보다 작으며 다음 요소에 따라 결정된다.

• Windows 제품과 에디션
• 프로세서와 칩셋
• 페이지 테이블 구현
• 펌웨어 메모리 지도
• 장치 메모리 영역
• 라이선스와 제품 정책
• 가상 머신 구성

x64 Windows는 하드웨어 실행 방지, 커널 패치 보호, 강한 드라이버 서명 정책과 더 넓은 주소 공간 배치 난수화 같은 보안 기능의 기반이 되었다.

x64는 현재 Windows PC, 워크스테이션과 Windows Server의 주류 아키텍처다. Intel과 AMD 프로세서뿐 아니라 x86-64 호환 프로세서를 사용하는 가상 머신과 클라우드 인스턴스에서도 실행된다.

ARM과 ARM64

ARM은 낮은 전력 소비와 높은 집적도를 중심으로 발전한 RISC 계열 프로세서 아키텍처다. 스마트폰, 태블릿, 임베디드 장치에서 널리 사용되었으며, 이후 노트북과 데스크톱급 시스템 온 칩으로 영역을 확장했다.

Microsoft는 Windows CE, Windows Mobile과 Windows Phone 계열에서 오랫동안 32비트 ARM을 지원했다. 이 제품들은 데스크톱 Windows와 이름 및 일부 API를 공유했지만, 서로 다른 커널 계열이나 제한된 응용 프로그램 모델을 사용한 경우가 많았다.

Windows 8 시대의 Windows RT는 ARM 기반 태블릿을 위한 Windows NT 제품이었다. Windows 8과 유사한 사용자 인터페이스를 제공했지만, 일반적인 서드파티 x86 데스크톱 응용 프로그램을 실행하지 못했고 Windows Store 응용 프로그램과 Microsoft가 제공한 ARM용 데스크톱 구성 요소를 중심으로 사용했다.

Windows RT가 제한적인 생태계를 형성한 주요 이유는 다음과 같다.

• 기존 x86 데스크톱 프로그램을 실행할 수 없음
• Windows Store 응용 프로그램 수가 제한적이었음
• 제품 이름과 화면이 일반 Windows와 유사해 호환성에 혼동이 있었음
• ARM 네이티브 데스크톱 응용 프로그램 배포가 제한됨
• 태블릿 시장에서 iPad와 Android가 이미 강한 생태계를 가짐

Windows 10 on Arm은 ARM64 기반 Windows에서 기존 32비트 x86 응용 프로그램을 에뮬레이션하는 기능을 도입했다. Windows 11 on Arm은 이를 확장하여 x86과 x64 응용 프로그램을 모두 에뮬레이션할 수 있다.

Microsoft는 Windows 10 on Arm이 수정되지 않은 x86 응용 프로그램을 실행하고, Windows 11 on Arm은 수정되지 않은 x64 응용 프로그램까지 지원한다고 설명한다.^[225]

현대 ARM64 Windows의 실행 환경은 다음과 같이 구성된다.

ARM64 Windows의 응용 프로그램 실행

• ARM64 Windows 커널
  • ARM64 장치 드라이버
  • 네이티브 ARM64 응용 프로그램
  • Arm64EC 응용 프로그램
    • 네이티브 ARM64EC 코드
    • 에뮬레이션된 x64 플러그인과 라이브러리
  • 에뮬레이션된 x64 응용 프로그램
  • 에뮬레이션된 x86 응용 프로그램

네이티브 ARM64 응용 프로그램은 ARM64 명령어로 직접 실행되며 일반적으로 가장 높은 성능과 전력 효율을 제공한다. 브라우저, 개발 도구, 미디어 프로그램과 업무용 소프트웨어 가운데 ARM64 네이티브 버전을 제공하는 제품이 증가했다.

Windows 11 24H2는 Prism이라는 새로운 x86·x64 에뮬레이션 기술을 도입했다. Prism은 기존 에뮬레이션보다 명령 변환과 실행 효율을 개선하고, 에뮬레이션되는 응용 프로그램의 CPU 사용량과 성능을 개선하는 방향으로 설계되었다.^[226]

에뮬레이션은 사용자 모드 응용 프로그램을 대상으로 한다. x86이나 x64용 커널 드라이버를 ARM64에서 에뮬레이션하여 적재할 수는 없다. 장치, 백신, 가상화 프로그램, 안티치트와 시스템 확장 기능에는 ARM64 네이티브 드라이버가 필요하다.

이 때문에 일반 응용 프로그램이 에뮬레이션으로 실행되더라도 다음 구성 요소가 ARM64를 지원하지 않으면 전체 기능이 제한될 수 있다.

• 커널 드라이버
• 셸 확장
• 가상화 드라이버
• 파일 시스템 필터
• 안티치트
• VPN과 네트워크 필터
• 하드웨어 장치 드라이버
• 오래된 플러그인
• 특정 JIT 컴파일러

Arm64EC는 기존 x64 응용 프로그램을 점진적으로 ARM64로 이전하기 위한 ABI다. 하나의 프로세스 안에서 ARM64EC로 컴파일된 네이티브 코드와 에뮬레이션되는 x64 코드를 함께 사용할 수 있다.

Microsoft는 Arm64EC 코드가 네이티브 성능으로 실행되고, 같은 프로세스의 기존 x64 코드가 Windows의 에뮬레이션을 통해 실행된다고 설명한다.^[227]

이를 이용하면 대형 응용 프로그램의 핵심 코드부터 ARM64로 전환하면서 아직 ARM64판이 없는 플러그인이나 라이브러리를 유지할 수 있다.

Visual Studio도 ARM64 네이티브 버전을 제공한다. Microsoft는 Visual Studio 2022 17.4부터 ARM64 Windows 장치에서 네이티브로 실행하고 ARM64 응용 프로그램을 빌드·디버깅할 수 있도록 지원한다.^[228]

ARM64 Windows의 장점은 다음과 같다.

• 높은 전력 효율
• 긴 배터리 사용 시간
• 시스템 온 칩 통합
• 대기 상태에서 빠른 복귀
• 셀룰러 모뎀과 NPU 통합
• 낮은 발열과 얇은 장치 설계
• ARM64 네이티브 응용 프로그램의 높은 효율

반면 호환성은 응용 프로그램 본체뿐 아니라 드라이버와 플러그인 생태계에 영향을 받는다. x86-64 Windows가 수십 년 동안 형성한 하드웨어와 소프트웨어 생태계를 ARM64에서 완전히 재현하려면 각 공급사의 네이티브 지원이 필요하다.

지원이 종료된 플랫폼

Windows NT는 이식 가능한 운영체제라는 설계를 실제 제품에서 입증하기 위해 x86 외에도 여러 프로세서 아키텍처를 지원했다. 그러나 각 플랫폼의 시장 규모, 하드웨어 공급, 응용 프로그램과 드라이버 생태계에 따라 지원 기간은 달랐다.

Microsoft는 Windows NT가 초기 Intel i860을 목표로 시작한 뒤 MIPS, x86, DEC Alpha와 PowerPC를 지원했고, 이후 Itanium, x64와 ARM 계열로 확장되었다고 설명한다.^[229]

MIPS

초기 Windows NT는 MIPS RISC 프로세서를 지원했다. Windows NT 3.1, 3.5와 3.51은 MIPS 기반 워크스테이션에서 실행될 수 있었다.

MIPS 지원은 Windows NT가 x86 전용 구조가 아님을 보여주는 초기 플랫폼 가운데 하나였다. 프로세서별 어셈블리 코드, 예외 처리, 페이지 테이블과 부팅 계층을 분리하고, 상위 실행부와 Win32 환경을 공통 코드로 유지했다.

그러나 MIPS 기반 Windows NT 시스템의 시장 규모는 작았고, 하드웨어 공급사와 응용 프로그램 지원도 x86보다 제한적이었다. Microsoft는 Windows NT 4.0 개발 과정에서 MIPS 지원을 종료했다.

DEC Alpha

DEC Alpha는 64비트 RISC 프로세서 아키텍처였으며 높은 정수 및 부동소수점 성능을 제공했다. Windows NT는 Alpha AXP를 지원했고, 일부 고성능 워크스테이션과 서버에서 사용되었다.

초기 Alpha용 Windows NT는 운영체제와 응용 프로그램 인터페이스에서 32비트 환경을 중심으로 제공되었으며, 프로세서의 64비트 기능 전체를 일반 Windows 응용 프로그램 모델에 그대로 노출하지는 않았다.

Alpha판 Windows NT는 FX!32와 같은 변환 기술을 통해 일부 x86 응용 프로그램을 실행할 수 있었다. FX!32는 x86 명령을 Alpha 명령으로 변환하고 반복 실행되는 코드를 최적화했다.

Windows 2000의 Alpha판도 개발되었지만 일반 제품 출시 전에 취소되었다. DEC가 Compaq에 인수되고 Alpha 플랫폼의 장기적 시장 전망이 약화되면서 Windows의 공식 Alpha 지원도 종료되었다.

PowerPC

PowerPC는 IBM POWER 계열에서 발전한 RISC 아키텍처다. Windows NT 3.51에서 PowerPC 지원이 도입되었고 Windows NT 4.0까지 제공되었다.

Microsoft는 Windows NT의 PowerPC 지원이 Windows NT 3.51에서 시작되었으며 마지막 지원 버전이 Windows NT 4.0이었다고 설명한다.^[230]

PowerPC판 Windows NT는 IBM과 Motorola의 일부 워크스테이션 및 서버를 대상으로 했지만, x86 PC에 비해 하드웨어와 응용 프로그램 생태계가 작았다. Microsoft는 Windows 2000 출시 이전에 PowerPC 데스크톱 및 서버 지원을 종료했다.

PowerPC 자체는 이후에도 Windows CE와 Xbox 360 같은 Microsoft 제품에서 사용되었다. 특정 Windows NT 클라이언트 지원이 끝났다고 해서 Microsoft 제품 전체에서 해당 아키텍처가 즉시 사라진 것은 아니다.

Itanium

Itanium 또는 IA-64는 Intel과 Hewlett-Packard가 서버와 고성능 컴퓨팅을 위해 개발한 64비트 아키텍처다. 기존 x86을 단순히 확장한 x86-64와 달리 별도의 명령어 집합과 실행 모델을 사용했다.

Microsoft는 Windows XP 64-Bit Edition과 Windows Server의 Itanium판을 제공했다. Itanium Windows는 대용량 메모리, 데이터베이스와 기업용 서버를 대상으로 했다.

그러나 Itanium은 일반 x86 응용 프로그램과 높은 네이티브 호환성을 제공하지 않았고, 하드웨어 가격과 소프트웨어 이식 비용이 높았다. AMD64가 기존 x86 프로그램과 호환되는 64비트 확장으로 빠르게 보급되면서 Windows의 주류 64비트 플랫폼은 x64로 이동했다.

Windows Server 2008 R2는 Itanium판이 제공된 마지막 Windows Server 계열이다. Microsoft의 수명 주기 문서는 Windows Server 2008과 2008 R2의 Itanium-Based Systems 에디션 지원이 종료되었음을 명시한다.^[231]

32비트 ARM

32비트 ARM은 Windows CE, Windows Mobile, Windows Phone, Windows RT와 초기 Windows 10 장치에서 사용되었다.

Windows Phone과 Windows RT 제품군이 종료되고 범용 ARM 장치가 ARM64로 전환되면서 현대 Windows 클라이언트의 주 ARM 대상도 ARM64가 되었다.

32비트 ARM 응용 프로그램과 운영체제 지원은 제품군마다 다르게 종료되었다. Windows CE와 Windows Embedded Compact 기반 장치는 각 제품의 별도 수명 주기를 따르며, Windows 11은 ARM64 하드웨어를 중심으로 한다.

16비트 x86와 32비트 운영체제판

16비트 Windows 응용 프로그램은 32비트 x86 Windows의 WOW와 NTVDM에서 실행될 수 있었지만, x64 Windows에는 일반적인 16비트 Windows 실행 환경이 포함되지 않는다.

Microsoft는 64비트 Windows가 16비트 Windows 응용 프로그램을 지원하지 않는다고 설명한다.^[232]

이러한 프로그램에는 다음 방식이 사용될 수 있다.

• 32비트 Windows 가상 머신
• DOSBox와 DOSBox-X
• WineVDM과 호환 계층
• 원래 운영체제와 하드웨어
• 응용 프로그램의 현대판
• 소스 코드 재빌드

Windows 11은 x86-64와 ARM64 같은 64비트 플랫폼만 대상으로 한다. 32비트 x86 응용 프로그램 호환성은 유지되지만 32비트 Windows 커널과 운영체제 이미지는 제공하지 않는다.

지원 종료된 플랫폼은 Windows NT의 다중 아키텍처 설계가 실패했다는 의미는 아니다. 같은 실행부, Win32 API, PE 형식과 개발 모델을 여러 프로세서에 이식할 수 있음을 보여주었지만, 운영체제 지원을 지속하려면 CPU뿐 아니라 컴파일러, 장치, 응용 프로그램, 드라이버와 제조사 생태계가 함께 유지되어야 했다.

펌웨어와 부팅 환경

Windows의 부팅 환경은 초기 IBM PC의 BIOS와 MBR 방식에서 현대적인 UEFI, GPT, Secure Boot와 TPM 기반 구조로 발전했다.

펌웨어는 운영체제보다 먼저 실행되어 프로세서, 메모리와 기본 장치를 초기화하고 부팅 가능한 운영체제를 찾는다. Windows 부팅 관리자는 펌웨어가 전달한 제어를 받아 부팅 구성 데이터에서 대상 Windows 설치를 선택하고 운영체제 로더를 실행한다.

Windows는 전통적으로 다음 두 펌웨어 부팅 방식을 사용해 왔다.

• 레거시 BIOS와 MBR
• UEFI와 GPT

BIOS와 MBR 부팅

전통적인 BIOS 기반 PC에서는 펌웨어가 부팅 순서에 지정된 디스크의 첫 번째 섹터를 읽는다. 이 섹터에는 마스터 부트 레코드와 파티션 테이블이 저장된다.

일반적인 BIOS Windows 부팅 흐름은 다음과 같다.

BIOS 기반 Windows 부팅

1. 시스템 전원 켜짐
   ↓
2. BIOS가 하드웨어 초기화와 POST 수행
   ↓
3. 부팅 디스크의 MBR을 메모리에 적재
   ↓
4. MBR 코드가 활성 파티션의 부트 섹터 실행
   ↓
5. Windows Boot Manager 시작
   ↓
6. BCD에서 부팅 항목과 설정 확인
   ↓
7. Windows OS Loader 실행
   ↓
8. 커널, HAL과 부팅 시작 드라이버 적재
   ↓
9. Windows 커널 초기화
   ↓
10. 시스템 서비스와 로그인 환경 시작

초기 Windows NT에서는 NTLDR, boot.ini와 NTDETECT.COM이 부팅에 사용되었다. Windows Vista부터는 Windows Boot Manager, Windows OS Loader와 Boot Configuration Data가 이를 대체했다.

MBR은 디스크 시작 부분에 부트 코드와 제한된 파티션 테이블을 저장한다. 일반적인 512바이트 논리 섹터 환경에서는 약 2TiB 디스크 크기와 네 개의 기본 파티션이라는 제약이 있다.

UEFI와 GPT 부팅

Unified Extensible Firmware Interface 또는 UEFI는 BIOS를 대체하는 현대적인 펌웨어 인터페이스다. 운영체제 로더를 디스크 섹터의 짧은 부트 코드로만 실행하지 않고, EFI 시스템 파티션의 파일 시스템에서 EFI 응용 프로그램으로 적재한다.

Microsoft는 Windows 설치에서 가능한 경우 레거시 BIOS보다 보안 기능이 많은 UEFI 모드를 사용하도록 안내한다.^[233]

UEFI Windows 시스템은 일반적으로 GPT 파티션 형식을 사용한다. GPT는 각 파티션을 GUID로 식별하고, 디스크 앞뒤에 파티션 테이블 사본을 저장하며 CRC를 이용해 메타데이터 손상을 확인한다.

일반적인 UEFI Windows 시스템 디스크에는 다음 파티션이 존재한다.

• EFI 시스템 파티션
• Microsoft 예약 파티션
• Windows 기본 데이터 파티션
• Windows 복구 환경 파티션
• 제조사 복구 또는 진단 파티션

EFI 시스템 파티션 또는 ESP는 FAT 계열 파일 시스템을 사용하며 Windows Boot Manager EFI 응용 프로그램, BCD 저장소와 다른 부팅 파일을 포함한다.

UEFI 기반 Windows 부팅 흐름은 다음과 같다.

UEFI 기반 Windows 부팅

1. 시스템 전원 켜짐
   ↓
2. UEFI 펌웨어가 하드웨어와 펌웨어 드라이버 초기화
   ↓
3. NVRAM의 부팅 항목 확인
   ↓
4. EFI 시스템 파티션에서 Windows Boot Manager 적재
   ↓
5. Secure Boot가 EFI 파일 서명 검증
   ↓
6. Windows Boot Manager가 BCD 읽기
   ↓
7. Windows OS Loader 실행
   ↓
8. 커널과 부팅 시작 드라이버 검증·적재
   ↓
9. Windows 커널과 시스템 서비스 시작

Microsoft는 UEFI 시스템에서 펌웨어가 NVRAM 부팅 변수에 따라 Bootmgfw.efi를 실행하고, Windows Boot Manager가 전체 부팅 과정을 관리한다고 설명한다.^[234]

Boot Configuration Data 또는 BCD는 Windows 부팅 항목과 설정을 저장하는 데이터베이스다. Windows 설치 선택, 복구 환경, 디버깅, 하이퍼바이저, 커널 옵션과 안전 모드 같은 설정을 포함할 수 있다.

BCD는 레지스트리와 유사한 객체·요소 구조를 사용한다. bcdedit, bcdboot, Windows Setup과 복구 도구가 BCD를 관리한다.

BCDBoot는 Windows 디렉터리에서 부팅 파일을 시스템 파티션으로 복사하고 BCD 저장소를 생성하거나 복구한다. UEFI 시스템에서는 펌웨어 NVRAM에 Windows Boot Manager 항목을 등록할 수도 있다.^[235]

Secure Boot

Secure Boot는 UEFI 펌웨어가 신뢰하는 서명을 가진 펌웨어 드라이버, EFI 응용 프로그램과 운영체제 로더만 실행하도록 하는 보안 체계다.

Microsoft는 Secure Boot를 장치가 OEM이 신뢰하는 소프트웨어만 사용해 부팅하도록 보장하는 업계 표준으로 설명한다.^[236]

Secure Boot 데이터베이스에는 다음 정보가 포함될 수 있다.

• 플랫폼 키
• 키 교환 키
• 신뢰되는 서명 데이터베이스
• 폐기된 서명과 해시 데이터베이스

부팅 파일의 서명이 신뢰되는 인증서에 연결되며 폐기 목록에 포함되지 않으면 실행이 허용된다. 취약하거나 침해된 부트 로더의 서명 또는 해시는 UEFI DBX 차단 목록에 추가될 수 있다.

Secure Boot는 Microsoft Windows만 실행하도록 고정하는 기술은 아니다. 펌웨어가 신뢰하도록 등록된 서명과 키를 가진 다른 운영체제 로더도 실행할 수 있다. 장치 소유자와 제조사가 키 관리 방식을 제공하는 경우 사용자 정의 키를 등록할 수도 있다.

Windows 11은 지원되는 시스템에서 UEFI, Secure Boot 가능 상태와 TPM 2.0을 하드웨어 요구 사항으로 사용한다. 실제 Secure Boot 활성화 요구와 설치 가능 여부는 Windows 에디션, 배포 방식과 정책에 따라 구분될 수 있다.

Trusted Boot와 측정된 부팅

Secure Boot가 펌웨어와 Windows Boot Manager 이전 단계를 보호한다면, Trusted Boot는 Windows Boot Manager 이후 커널과 초기 부팅 구성 요소의 서명과 무결성을 확인한다.

부팅 초기에는 다음 구성 요소가 순차적으로 검증된다.

• Windows Boot Manager
• Windows OS Loader
• Windows 커널
• HAL
• 부팅 시작 드라이버
• Early Launch Antimalware
• 초기 시스템 서비스

측정된 부팅은 각 부팅 구성 요소의 측정값을 TPM 플랫폼 구성 레지스터에 기록한다. 장치 상태 증명 서비스는 이 값을 이용해 장치가 요구되는 펌웨어, Secure Boot와 보안 정책으로 시작되었는지 평가할 수 있다.

Microsoft는 Windows가 Secure Boot, Trusted Boot, Early Launch Antimalware와 측정된 부팅을 조합해 루트킷과 부트킷의 초기 실행을 제한한다고 설명한다.^[237]

ACPI와 장치 초기화

Windows는 펌웨어가 제공하는 Advanced Configuration and Power Interface 또는 ACPI 정보를 사용해 장치 열거, 전원 관리, 절전 상태, 배터리와 열 관리를 수행한다.

ACPI 테이블은 다음과 같은 플랫폼 정보를 제공한다.

• 프로세서와 NUMA 구조
• 인터럽트 컨트롤러
• 전원 버튼과 덮개
• 배터리와 충전 상태
• 절전과 복귀
• 내장 장치
• 시스템 타이머
• 열 영역과 팬
• PCI 루트 브리지
• 보안 장치와 TPM
• 시스템 전원 상태

Windows의 ACPI 드라이버는 펌웨어의 ACPI Machine Language 코드를 실행하고, 장치를 플러그 앤 플레이 트리에 연결한다. 펌웨어의 ACPI 구현 오류는 장치 인식, 절전, 배터리, 성능과 시스템 안정성 문제를 일으킬 수 있다.

펌웨어 모드 전환

Windows는 설치될 때 사용한 펌웨어 모드와 디스크 파티션 구조에 맞춰 부팅 파일을 구성한다. BIOS 모드로 설치된 Windows는 일반적으로 MBR 디스크에서 부팅하고, UEFI 모드로 설치된 Windows는 GPT와 EFI 시스템 파티션을 사용한다.

펌웨어 설정에서 BIOS와 UEFI 모드만 바꾸면 기존 Windows가 부팅되지 않을 수 있다. 부팅 모드, 파티션 형식, 부팅 파일과 BCD가 함께 일치해야 한다.

Microsoft는 Windows 설치 후 펌웨어 모드를 바꾸려면 일부 시스템에서 MBR2GPT를 이용해 시스템 디스크를 MBR에서 GPT로 변환하고 UEFI 부팅 파일을 구성할 수 있다고 설명한다.^[238]

가상 머신도 BIOS 또는 UEFI 펌웨어를 사용할 수 있다. Hyper-V 세대 1 가상 머신은 레거시 BIOS를 사용하고, 세대 2 가상 머신은 UEFI와 Secure Boot를 지원한다.

현대 Windows에서 UEFI는 단순히 BIOS보다 화면이 발전한 펌웨어가 아니다. 대용량 GPT 디스크, Secure Boot, 빠른 부팅, 표준화된 부팅 파일, 펌웨어 변수와 현대적인 전원·보안 기능을 운영체제와 연결하는 기반이다.

Windows는 같은 운영체제 기반을 사용하면서 대상 사용자, 관리 규모, 보안 요구와 하드웨어 용도에 따라 여러 에디션으로 제공된다. 클라이언트 Windows에서는 Home, Pro, Enterprise와 Education이 중심이며, 고성능 워크스테이션과 고정 목적 장치를 위한 파생 에디션도 존재한다. 서버 제품군은 Standard, Datacenter와 Datacenter: Azure Edition을 중심으로 구성된다.

에디션은 단순히 포함된 응용 프로그램의 차이를 뜻하지 않는다. 다음 요소가 에디션에 따라 달라질 수 있다.

• 도메인 가입과 그룹 정책
• BitLocker와 장치 암호화
• Hyper-V와 Windows Sandbox
• 원격 데스크톱 호스트
• 기업용 응용 프로그램 제어
• 자격 증명과 가상화 기반 보안
• 장치 및 업데이트 관리
• 지원 가능한 메모리와 프로세서
• 가상 머신과 컨테이너 실행 권리
• 장기 서비스 채널 사용 가능 여부
• 조직용 구독과 클라우드 관리 권리

Microsoft가 같은 에디션 이름을 여러 Windows 세대에서 사용하더라도 기능과 라이선스 조건이 항상 동일한 것은 아니다. Windows XP Home Edition과 Windows 11 Home은 같은 Home 계열이지만 시스템 구조와 기능 범위가 다르며, Windows Server Standard의 가상화 권리도 제품 버전과 라이선스 정책에 따라 해석해야 한다.

현대 Windows의 주요 에디션 체계

• Windows 클라이언트
  • Home
    • 개인 및 가정용 PC
  • Pro
    • 소규모 기업
    • 전문 사용자
    • 관리되는 업무용 PC
  • Enterprise
    • 대규모 조직
    • 고급 보안과 관리
    • Enterprise LTSC
  • Education
    • 학교와 교육기관
    • Pro Education
    • Education
  • Pro for Workstations
    • 고성능 워크스테이션
  • IoT Enterprise
    • 고정 목적 장치
• Windows Server
  • Standard
    • 물리 서버와 제한된 가상화
  • Datacenter
    • 고밀도 가상화와 데이터센터
  • Datacenter: Azure Edition
    • Azure와 Azure Local 최적화
  • Essentials
  • 일부 공급 경로의 소규모 조직용 구성

Windows의 에디션, 라이선스와 정품 인증은 서로 관련되지만 같은 개념이 아니다.

• 에디션은 설치된 Windows가 제공하는 기능 집합이다.
• 라이선스는 사용자가 해당 소프트웨어를 어떤 장치와 조건에서 사용할 권리를 취득했는지를 나타낸다.
• 정품 인증은 설치된 Windows와 제품 키 또는 디지털 권리를 Microsoft의 정품 인증 체계에서 확인하는 기술적 과정이다.

Windows가 정품 인증되었다고 표시되더라도 조직의 실제 사용 방식이 계약상의 라이선스 조건을 충족하는지는 별도로 확인해야 한다. 반대로 적법한 라이선스를 가지고 있더라도 네트워크 단절, 하드웨어 교체, 키 설정 오류나 정품 인증 서버 문제로 일시적으로 인증 상태가 정상 표시되지 않을 수 있다.

Home

Windows Home은 가정과 일반 소비자용 개인용 컴퓨터를 대상으로 하는 에디션이다. Windows의 기본적인 데스크톱 환경, 응용 프로그램 호환성, 게임, 멀티미디어와 일반 보안 기능을 제공한다.

Home 에디션은 다음과 같은 사용 환경을 대상으로 한다.

• 가정용 데스크톱과 노트북
• 웹과 문서 작업
• 미디어 감상과 제작
• 일반 소프트웨어 개발
• PC 게임
• 온라인 학습
• 개인용 클라우드 서비스
• 터치스크린과 2-in-1 장치

Windows 11 Home은 Windows 11의 핵심 사용자 환경을 제공한다.

• 시작 메뉴와 작업 표시줄
• 파일 탐색기
• Windows 보안
• Microsoft Defender Antivirus
• Windows 방화벽
• Windows Hello
• 장치 암호화가 지원되는 하드웨어
• Microsoft Store
• DirectX와 게임 기능
• Windows Terminal
• PowerShell
• Windows Subsystem for Linux
• 접근성 기능
• 기본 네트워크와 파일 공유

Home 에디션이라고 해서 업무나 개발에 사용할 수 없는 것은 아니다. Visual Studio, Visual Studio Code, WSL, Git, Docker Desktop의 지원 조건을 충족하는 구성, CMake와 여러 언어 도구를 설치할 수 있다. Win32, .NET, 웹, Linux와 게임 개발도 가능하다.

Home과 Pro의 차이는 일반 응용 프로그램 실행 성능보다 조직 관리와 고급 시스템 기능에서 크게 나타난다. Microsoft의 Windows 11 비교 자료는 Pro가 Home의 기능을 포함하면서 BitLocker 드라이브 암호화, 원격 데스크톱 호스트, 도메인 가입, 그룹 정책과 기업용 관리 기능을 추가한다고 설명한다.^[239]

Home에서 일반적으로 제공되지 않거나 제한되는 대표 기능은 다음과 같다.

• Active Directory 도메인 가입
• Microsoft Entra ID 조직 가입의 전체 업무용 구성
• 로컬 그룹 정책 편집기의 공식 사용자 인터페이스
• BitLocker 관리 기능 전체
• 원격 데스크톱 세션 호스트
• Hyper-V 관리 및 가상 머신 기능
• Windows Sandbox
• 일부 기업용 응용 프로그램 제어
• 키오스크와 업무용 장치 관리 기능 일부
• 비즈니스용 업데이트 정책의 전체 범위

Home 컴퓨터도 원격 데스크톱 클라이언트로 다른 컴퓨터에 연결할 수 있다. 제한되는 것은 일반적으로 다른 장치가 해당 Home 컴퓨터에 RDP로 로그인하도록 하는 원격 데스크톱 호스트 기능이다.

Home에서도 타사 가상화 프로그램과 원격 제어 프로그램을 사용할 수 있다. 에디션에 Hyper-V나 RDP 호스트가 포함되지 않았다는 사실은 모든 가상화나 원격 접속 자체가 불가능하다는 의미가 아니다.

현대 Windows Home은 설치와 초기 설정에서 Microsoft 계정과 인터넷 연결을 중심으로 구성된다. 실제 요구 사항과 로컬 계정 구성 가능 범위는 Windows 버전, 국가, 설치 방식과 조직 정책에 따라 달라질 수 있다.

Home 라이선스는 완제품 PC에 OEM 형태로 사전 설치되거나, 소비자가 소매 제품과 Microsoft Store를 통해 취득할 수 있다. Home에서 Pro로 업그레이드하면 같은 Windows 설치를 유지하면서 Pro 기능이 활성화될 수 있다.

Pro

Windows Pro는 전문 사용자, 소규모 기업, 개발자와 조직에서 관리하는 업무용 컴퓨터를 대상으로 한다. Home의 소비자 기능을 포함하면서 네트워크 관리, 암호화, 가상화와 원격 업무 기능을 추가한다.

Pro의 주요 용도는 다음과 같다.

• 기업과 조직의 업무용 PC
• 소규모 사무실
• 소프트웨어 개발 워크스테이션
• 원격 업무
• Active Directory 기반 네트워크
• Hyper-V 시험 환경
• BitLocker로 보호되는 노트북
• 키오스크와 전용 업무 장치
• 전문 제작과 관리 작업

Windows 11 Pro에 포함되는 대표적인 추가 기능은 다음과 같다.

• BitLocker 드라이브 암호화
• Active Directory 도메인 가입
• Microsoft Entra ID 가입
• 그룹 정책
• 원격 데스크톱 호스트
• Hyper-V
• Windows Sandbox
• Windows Update for Business 정책
• 모바일 장치 관리
• 할당된 액세스
• 기업용 Microsoft Store와 응용 프로그램 배포 기능
• 더 높은 하드웨어 자원 한도

Microsoft의 업무용 Windows 비교 자료는 Windows 11 Pro가 Active Directory 도메인 가입과 그룹 정책, BitLocker, 원격 데스크톱과 조직 관리 기능을 제공한다고 설명한다.^[240]

Pro는 대규모 조직에서 사용할 수도 있지만, Enterprise에 포함되는 일부 고급 보안과 운영 제어 기능은 제공되지 않는다. 조직은 Pro 장치를 기본 자격 운영체제로 구매한 뒤 사용자 또는 장치에 Enterprise 구독을 할당하여 Enterprise 기능으로 전환할 수 있다.

Windows Pro for Workstations는 Pro의 파생 에디션으로, 고성능 워크스테이션을 대상으로 한다. 일반 Pro 기능에 다음과 같은 워크스테이션 중심 기능을 추가한다.

• 더 많은 프로세서와 메모리 지원
• ReFS
• SMB Direct
• 비휘발성 메모리 지원
• 고성능 파일 공유
• 서버급 하드웨어를 위한 구성

Microsoft는 Pro for Workstations를 높은 연산량과 고속 저장·네트워크 작업을 수행하는 워크스테이션에 맞춘 에디션으로 구분한다.^[241]

Pro for Workstations는 Windows Server를 대체하지 않는다. 대화형 전문 응용 프로그램과 한 명 또는 소수 사용자의 워크스테이션 작업을 중심으로 하며, Windows Server의 서버 역할, 가상화 권리와 CAL 체계를 제공하지 않는다.

Pro는 개발자에게도 실용적인 에디션이다. Home에서도 대부분의 사용자 모드 개발이 가능하지만 Pro는 다음 환경을 운영체제 자체 기능으로 구성할 수 있다.

• Hyper-V 가상 머신
• Windows Sandbox
• 원격 데스크톱 접속
• 그룹 정책 시험
• 도메인 가입 클라이언트
• BitLocker 관리
• Windows 컨테이너 개발의 일부 구성
• 기업 배포 및 관리 시험

Windows Pro는 일반적으로 장치 단위의 영구 라이선스로 OEM 또는 소매 형태로 취득할 수 있다. Microsoft 365 Business Premium과 일부 조직용 구독은 자격을 갖춘 장치에 Home에서 Pro로의 업그레이드 또는 Pro 기반 관리 권리를 포함할 수 있으며, 구체적인 조건은 해당 계약과 Microsoft Product Terms를 따른다.^[242]

Enterprise

Windows Enterprise는 대규모 조직, 강한 보안 통제, 복잡한 장치 관리와 장기간의 배포 안정성이 필요한 환경을 위한 에디션이다. Pro의 기능을 기반으로 조직 전체에 적용할 수 있는 고급 보안, 응용 프로그램 제어와 사용자 환경 관리 기능을 추가한다.

Enterprise의 주요 대상은 다음과 같다.

• 대기업과 공공기관
• 금융과 의료 기관
• 대규모 학교와 연구기관
• 규제 산업
• 다수의 관리 장치
• 가상 데스크톱
• 고정 목적 업무 장치
• 장기 서비스가 필요한 특수 시스템

Enterprise에서 제공되거나 Enterprise 라이선스와 연결되는 대표 기능은 다음과 같다.

• App Control for Business
• Credential Guard와 고급 자격 증명 보호
• DirectAccess 계열의 기업 네트워크 기능
• 고급 배포와 사용자 환경 제어
• 구독 기반 에디션 활성화
• Enterprise LTSC 사용 권리
• Microsoft Defender for Endpoint와 결합된 고급 보안
• 가상 데스크톱과 원격 접근 권리
• 조직 단위의 응용 프로그램 및 장치 제어

Windows Enterprise는 일반 소비자에게 완제품 형태로 판매되는 Home이나 Pro와 달리 주로 Commercial Licensing, Microsoft 365와 조직용 구독을 통해 제공된다.

Microsoft의 Windows 상업용 라이선스 개요는 Windows Enterprise E3가 일반적으로 Pro를 기반으로 하는 업그레이드 라이선스이며, Commercial Licensing 프로그램을 통해 제공된다고 설명한다.^[243]

따라서 조직이 Enterprise를 사용하려면 일반적으로 장치에 Windows Pro와 같은 자격 운영체제 라이선스가 먼저 필요하다. Enterprise 라이선스만 구매한다고 항상 운영체제의 완전한 기초 라이선스가 새로 생기는 것은 아니다. 예외와 가상 데스크톱 권리는 라이선스 프로그램과 사용자 구독에 따라 달라진다.

Microsoft는 Windows 11 Enterprise를 다음 방식으로 라이선스할 수 있다고 설명한다.

• 장치별 Windows Enterprise 라이선스
• 사용자별 Windows Enterprise E3
• 사용자별 Windows Enterprise E5

Enterprise E5는 Enterprise E3 기능에 Microsoft Defender for Endpoint의 고급 엔드포인트 탐지 및 대응 기능을 추가한다.^[244]

Enterprise 구독이 사용자에게 할당된 환경에서는 구독 정품 인증을 이용할 수 있다. 자격을 갖춘 Windows Pro 장치에서 사용자가 조직의 Microsoft Entra 계정으로 로그인하면 운영체제를 다시 설치하지 않고 Enterprise 기능이 활성화될 수 있다.

Windows Enterprise 구독 활성화

1. 장치에 정품 인증된 자격 Windows Pro 설치
   ↓
2. 조직이 사용자에게 Enterprise E3 또는 E5 라이선스 할당
   ↓
3. 사용자가 Microsoft Entra 계정으로 Windows에 로그인
   ↓
4. Windows가 구독과 장치 자격 확인
   ↓
5. 설치된 에디션이 Enterprise 기능으로 전환
   ↓
6. 구독이 유지되는 동안 Enterprise 권리 사용

Microsoft는 Enterprise E3 또는 E5가 할당된 사용자가 Microsoft Entra 계정으로 로그인하면 해당 장치에서 Enterprise 기능이 활성화될 수 있다고 설명한다.^[245]

구독 활성화는 운영체제 파일 전체를 다른 이미지로 교체하는 일반적인 인플레이스 업그레이드와 다르다. Windows 이미지에 존재하는 Enterprise 기능이 라이선스 상태와 정책에 따라 활성화된다.

구독이 만료되거나 사용자의 라이선스가 제거되면 장치는 일반적으로 기반이 되는 Pro 에디션으로 돌아갈 수 있다. 사용자 데이터와 설치된 응용 프로그램을 삭제하는 초기화와는 다르지만, Enterprise 전용 정책과 기능은 더 이상 사용할 수 없게 된다.

Windows Enterprise LTSC는 장기간 동일한 기능 기반을 유지해야 하는 특수 장치를 위한 장기 서비스 채널 제품이다. 일반적인 사무용 PC 전체에 최신 기능을 늦게 받기 위한 목적으로 설계된 에디션이 아니라, 의료 장비, 공장 제어, 키오스크와 같이 기능 변화보다 안정성과 장기 지원이 중요한 고정 목적 장치를 대상으로 한다.

Enterprise LTSC는 일반 채널 Windows와 비교해 일부 기본 응용 프로그램, Microsoft Store와 지속적으로 변화하는 사용자 기능이 제한될 수 있다. Microsoft는 일반 채널을 대상으로 만들어진 앱과 도구가 LTSC에서 제한적으로 지원될 수 있다고 설명한다.^[246]

일반 Windows 11 Enterprise와 Education 기능 업데이트는 Home과 Pro보다 긴 지원 기간을 갖는다. Microsoft의 Windows 11 릴리스 정보는 Home과 Pro 계열 기능 버전에 24개월, Enterprise와 Education에 36개월 지원 기간을 적용한다고 설명한다.^[247]

Education

Windows Education은 학교, 대학과 교육기관의 교직원·학생·공용 장치를 대상으로 하는 에디션이다. 기능적으로는 Enterprise와 가까운 구성을 제공하면서 교육기관을 위한 라이선스와 기본 정책을 적용한다.

교육용 Windows 제품에는 다음 에디션이 사용될 수 있다.

• Windows Pro Education
• Windows Education
• Windows Education 구독
• Microsoft 365 Education에 포함된 Windows 권리

Windows Pro Education은 Pro를 기반으로 교육 환경에 맞는 기본 설정과 관리 기능을 제공한다. 학교가 교실과 학생용 장치를 관리하면서 일반 Pro 기반 호환성을 유지하는 데 사용된다.

Microsoft는 Windows 11 Pro Education을 교육기관에 맞게 조정하여 학습 환경과 관리 작업을 지원하는 제품으로 설명한다.^[248]

Windows Education은 Enterprise와 유사한 고급 보안과 관리 기능을 제공한다. 대규모 학교, 대학과 교육 행정기관은 그룹 정책, 장치 관리, 응용 프로그램 제어, 가상 데스크톱과 장기 서비스 옵션을 활용할 수 있다.

Education 에디션의 주요 사용 환경은 다음과 같다.

• 학생 개인용 장치
• 교직원 업무용 컴퓨터
• 교실과 실습실
• 도서관 공용 컴퓨터
• 시험용 잠금 장치
• 연구실 워크스테이션
• 학교 행정 시스템
• 원격 수업과 가상 데스크톱
• 키오스크와 안내 단말기

교육기관은 Windows Education을 장치별 또는 사용자별 라이선스, Microsoft 365 Education A3·A5와 교육기관용 계약을 통해 취득할 수 있다. 기관이 모든 자격 사용자를 기준으로 라이선스를 구매하면 학생 사용 혜택과 공유 장치 권리가 제공되는 프로그램도 존재한다.

Microsoft의 Education Solutions 등록 안내는 Windows Education E3·E5와 Microsoft 365 Education A3·A5를 교육기관용 제품으로 제공한다.^[249]

Education 라이선스는 일반적인 소매용 할인판과 동일하게 해석하면 안 된다. 학교에서 제공한 라이선스는 재학·재직 상태, 기관의 계약 유지, 장치 소유권과 사용자 자격에 따라 사용 권리가 달라질 수 있다.

일부 교육기관은 학생에게 소프트웨어를 내려받을 수 있는 권리를 제공하지만, 해당 제품 키가 졸업 이후 영구적으로 이전 가능한 소매 라이선스라는 의미는 아니다. 실제 권리는 학교와 Microsoft 사이의 계약과 배포 프로그램을 따른다.

Education 에디션은 일반 Windows 프로그램과 게임을 실행할 수 있다. 기능적으로 소비자용이 아니라는 이유로 일반 응용 프로그램 호환성이 사라지는 것은 아니다. 다만 학교가 그룹 정책과 응용 프로그램 제어를 적용하면 설치, 게임, Microsoft Store와 외부 장치 사용이 제한될 수 있다.

Windows Server 에디션

Windows Server는 서버 규모, 가상화 밀도와 클라우드 배포 환경에 따라 여러 에디션으로 제공된다. Windows Server 2025의 주요 범용 에디션은 다음과 같다.

• Standard
• Datacenter
• Datacenter: Azure Edition

Microsoft는 Standard를 물리 서버 또는 제한된 가상화 환경에, Datacenter를 높은 가상화 밀도와 클라우드 환경에 적합한 에디션으로 설명한다.^[250]

Standard

Windows Server Standard는 물리 서버 또는 가상 머신 수가 많지 않은 환경을 대상으로 한다. 파일 서버, 도메인 컨트롤러, 응용 프로그램 서버, 웹 서버와 소규모 Hyper-V 호스트에 사용할 수 있다.

Standard에는 Windows Server의 대부분 기본 역할이 포함된다.

• Active Directory Domain Services
• DNS와 DHCP
• 파일과 저장소 서비스
• Hyper-V
• Windows Server 컨테이너
• IIS
• 원격 데스크톱 서비스
• 장애 조치 클러스터
• PowerShell과 원격 관리
• Windows Defender
• 네트워크와 보안 역할

Standard와 Datacenter는 커널과 주요 서버 API를 공유한다. 차이는 단순히 Standard가 기본 서버이고 Datacenter가 더 빠른 서버라는 식의 성능 등급이 아니다. 주요 차이는 가상화 권리와 일부 데이터센터 전용 기능에 있다.

서버의 모든 물리 코어가 필요한 라이선스로 완전히 덮인 경우 Standard는 일반적으로 두 개의 Windows Server 가상 운영체제 환경 또는 Hyper-V 격리 컨테이너를 실행할 권리를 제공한다. 물리 인스턴스가 Hyper-V 호스트 관리만 담당하는 경우 호스트 인스턴스를 추가로 사용할 수 있다.

Microsoft의 Windows Server 제한 비교 자료는 Standard에 라이선스당 두 개의 가상 머신과 하나의 Hyper-V 호스트 권리를, Datacenter에는 제한 없는 가상 머신과 하나의 Hyper-V 호스트 권리를 표시한다.^[251]

Standard에서 더 많은 Windows Server 가상 머신을 실행하려면 서버의 모든 물리 코어를 다시 한 세트씩 라이선스하는 라이선스 스태킹을 사용할 수 있다. 각 완전한 추가 라이선스 세트가 두 개의 추가 가상 운영체제 환경 권리를 제공한다.

Linux 가상 머신 자체는 Windows Server 게스트 라이선스를 소비하지 않지만, Hyper-V 호스트로 사용하는 물리 Windows Server의 라이선스와 관리 제품의 조건은 별도로 적용된다.

Datacenter

Windows Server Datacenter는 높은 가상화 밀도, 소프트웨어 정의 데이터센터, 대규모 저장소와 클라우드 환경을 대상으로 한다.

서버의 모든 물리 코어가 Datacenter로 완전히 라이선스되면 해당 서버에서 Windows Server 가상 운영체제 환경을 제한 없이 실행할 수 있는 권리가 제공된다. 실제 가상 머신 수는 하드웨어 자원과 제품 한계의 영향을 받지만, Standard처럼 두 대 단위로 Windows Server 게스트 라이선스를 추가할 필요는 없다.

Datacenter는 Standard의 기능에 다음과 같은 고급 기능을 추가하거나 제한을 완화한다.

• 제한 없는 Windows Server 가상화 권리
• 제한 없는 Hyper-V 격리 컨테이너 권리
• 소프트웨어 정의 네트워크
• 보호된 가상 머신
• Host Guardian Service
• Storage Spaces Direct
• Storage Replica의 확장된 구성
• 데이터센터와 클라우드 중심 기능

Microsoft의 에디션 비교 자료는 Standard, Datacenter와 Datacenter: Azure Edition의 가상화, Storage Spaces Direct, Storage Replica와 보호된 가상 머신 기능 차이를 제공한다.^[252]

Datacenter는 물리 서버 한 대의 가격이 Standard보다 높지만, Windows Server 가상 머신을 많이 실행하는 호스트에서는 Standard 라이선스를 반복해서 쌓는 것보다 단순하고 경제적일 수 있다.

Datacenter: Azure Edition

Windows Server Datacenter: Azure Edition은 Azure와 Azure Local의 가상 머신을 위해 최적화된 에디션이다. 일반적인 온프레미스 물리 서버에 설치하는 Datacenter의 단순 상위판이 아니라, 지원되는 Azure 환경에서 실행되는 클라우드 중심 제품이다.

Azure Edition은 다음과 같은 기능을 제공하거나 더 빠르게 도입한다.

• Hotpatch
• Azure 기반 관리
• SMB over QUIC
• Azure 네트워크 통합
• 가상 머신 중심 배포
• 연간 제품 업데이트
• Azure와 Azure Local에 맞춘 최적화

Microsoft는 Datacenter: Azure Edition을 Azure에서 실행하도록 최적화된 가상화 중심 에디션으로 설명하며, Standard와 일반 Datacenter보다 새로운 기능을 더 빠르게 제공한다고 설명한다.^[253]

Hotpatch는 일부 보안 업데이트를 재부팅 없이 적용하여 유지보수에 따른 서비스 중단을 줄인다. 모든 업데이트와 상황에서 재부팅이 사라지는 것은 아니며, 정기적인 기준 이미지 갱신과 특정 업데이트에는 다시 시작이 필요할 수 있다.

Essentials와 특수 제품

Windows Server Essentials는 일부 제품 버전과 OEM 공급 경로에서 소규모 조직을 위한 제품으로 제공되어 왔다. 사용자, 장치, 가상화와 역할에 별도 제한이 적용될 수 있으며 일반적인 Standard·Datacenter 계약과 같은 방식으로 해석해서는 안 된다.

Windows Server 2025의 수명 주기 목록에는 Standard, Datacenter, Datacenter: Azure Edition과 Essentials가 포함된다.^[254]

과거에는 다음과 같은 별도 서버 제품과 에디션도 존재했다.

• Enterprise
• Web Server
• Foundation
• Small Business Server
• Windows Storage Server
• HPC Server
• Hyper-V Server
• Itanium 기반 에디션
• Multipoint Server

이들 제품 가운데 일부 기능은 Standard와 Datacenter에 통합되었고, 일부는 Azure 서비스나 다른 제품으로 전환되었으며, 일부는 지원이 종료되었다.

서버 라이선스 단위

현대 Windows Server Standard와 Datacenter는 일반적으로 물리 코어 기반으로 라이선스된다. 물리 서버에 설치된 프로세서의 코어 수를 기준으로 필요한 코어 라이선스를 할당하며, 서버와 프로세서당 최소 라이선스 수가 적용된다.

가상 머신에 가상 CPU가 몇 개 설정되었는지만 보고 물리 호스트 라이선스를 계산하는 방식과는 다르다. 가상화 권리를 얻으려면 해당 물리 서버의 모든 필요한 코어가 적절한 에디션으로 라이선스되어야 한다.

Windows Server 자체의 코어 라이선스 외에 서버 서비스에 접근하는 사용자 또는 장치에는 일반적으로 Client Access License 또는 CAL이 필요하다.

CAL은 다음과 같이 나뉜다.

• 사용자 CAL은 지정된 사용자가 여러 장치에서 서버에 접근할 수 있게 한다.
• 장치 CAL은 지정된 장치를 여러 사용자가 공유하여 서버에 접근할 수 있게 한다.

Windows Server CAL은 서버 소프트웨어를 설치하는 제품 키가 아니다. 서버에 접근할 법적 권리를 나타내며, 일반적으로 Windows에 입력하여 기술적으로 정품 인증하지 않는다.

원격 데스크톱 서비스, 권한 관리와 일부 서버 제품에는 기본 Windows Server CAL 외에 추가 CAL이 필요할 수 있다. 예를 들어 여러 사용자에게 Remote Desktop Session Host를 제공하려면 Windows Server CAL과 별도로 RDS CAL이 필요하다.

인터넷의 익명 사용자가 공개 웹사이트에 접근하는 경우와 내부 직원이 인증된 파일 서버에 접근하는 경우의 라이선스 조건도 다를 수 있다. 서버 역할, 사용자 인증 방식과 외부 커넥터 라이선스를 포함한 실제 조건은 Microsoft Product Terms와 계약을 기준으로 확인해야 한다.

OEM과 볼륨 라이선스

Windows는 구매 경로와 사용 조직에 따라 OEM, 소매, Commercial Licensing과 구독 방식으로 제공된다.

OEM 라이선스

OEM 라이선스는 컴퓨터 제조사나 시스템 빌더가 새 컴퓨터에 Windows를 사전 설치하여 제공하는 방식이다.

대부분의 완제품 노트북과 데스크톱은 OEM Windows를 포함한다. 제조사는 Windows 이미지, 드라이버, 복구 환경과 자체 응용 프로그램을 구성하고 장치와 함께 라이선스를 공급한다.

OEM 라이선스의 주요 특징은 다음과 같다.

• 새 컴퓨터와 함께 공급
• 해당 장치에 연결
• 제조사가 초기 지원을 담당
• 펌웨어에 제품 키가 기록될 수 있음
• 제조사 복구 이미지 사용 가능
• 동일 장치 재설치 시 자동 인증 가능
• 다른 컴퓨터로의 이전 권리가 일반적으로 제한됨

현대 OEM PC는 UEFI 펌웨어의 ACPI MSDM 테이블에 OA3 디지털 제품 키를 저장할 수 있다. Windows 설치 프로그램과 정품 인증 서비스는 이 키를 읽어 장치에 맞는 에디션을 설치하거나 인증한다.

OEM 라이선스가 저장 장치에 묶이는 것은 아니다. SSD나 HDD를 교체하고 같은 장치에 Windows를 다시 설치할 수 있다. 핵심 연결 대상은 일반적으로 컴퓨터 전체이며, 특히 메인보드 변경은 새 장치로 판단될 수 있다.

제조사의 보증 교체처럼 정당한 메인보드 교체가 이루어진 경우에는 OEM 또는 Microsoft 지원 절차를 통해 다시 인증할 수 있다. 임의로 다른 PC에 OEM 키를 옮기는 것과는 구분된다.

Microsoft의 볼륨 정품 인증 안내는 OEM 정품 인증이 OEM 경로에서 Windows가 사전 설치된 컴퓨터에 제공된다고 설명한다.^[255]

System Builder OEM은 소규모 시스템 제조사가 조립한 컴퓨터에 Windows를 설치하여 최종 사용자에게 공급하는 경로로 사용되어 왔다. 패키지 판매 방식과 최종 사용권 조건은 제품 세대와 지역에 따라 달라질 수 있다.

소매 라이선스

소매 라이선스는 사용자가 Windows를 독립된 제품으로 구매하는 방식이다. Microsoft Store나 공인 판매자의 디지털 제품 또는 패키지 제품으로 제공될 수 있다.

소매 라이선스는 일반적으로 사용 중인 이전 컴퓨터에서 제거한다는 조건으로 다른 컴퓨터에 이전할 수 있는 권리를 제공한다. 동시에 여러 장치에서 하나의 라이선스를 사용하는 권리를 주는 것은 아니다.

소매 제품은 다음 용도로 사용될 수 있다.

• 운영체제가 없는 조립 PC
• Home에서 Pro로 업그레이드
• 새 컴퓨터의 별도 Windows 라이선스
• 기존 장치의 에디션 변경
• 가상 머신을 위한 개별 라이선스

제품 키를 다른 장치로 옮길 수 있는지와 가상 머신에서 사용할 수 있는지는 구매한 제품의 사용 조건을 따라야 한다. 단순히 정품 인증 서버가 키를 받아들였다는 사실만으로 이전 권리가 자동으로 보장되는 것은 아니다.

볼륨 라이선스

과거의 Volume Licensing은 현재 Microsoft 문서에서 Commercial Licensing이라는 표현으로도 사용된다. 기업, 학교, 정부와 비영리 조직이 많은 장치와 사용자를 일관된 계약 아래 관리하기 위한 라이선스 방식이다.

볼륨 또는 상업용 라이선스는 단순히 같은 제품 키로 여러 컴퓨터를 인증하는 상품이 아니다. 다음 요소를 포함하는 조직용 계약 체계다.

• 사용자 또는 장치 단위 라이선스
• Enterprise와 Education 사용 권리
• 업그레이드 권리
• 이전 버전 사용 권리
• 가상 데스크톱 접근 권리
• 다국어 사용
• Software Assurance 혜택
• 구독 라이선스
• KMS, MAK와 Active Directory 기반 인증
• 중앙 라이선스 및 장치 관리

Windows 데스크톱의 상업용 라이선스는 일반적으로 업그레이드 라이선스다. 장치에 자격을 갖춘 기본 운영체제 라이선스가 있어야 Enterprise 또는 Education 업그레이드 권리를 적용할 수 있다.

Microsoft의 Windows 11 자격 운영체제 안내는 Commercial Licensing을 통한 Windows 11 업그레이드 라이선스에 기본 자격 운영체제가 필요하다고 설명한다.^[256]

따라서 운영체제가 없는 PC에 Enterprise 볼륨 키만 입력하는 방식은 일반적으로 완전한 라이선스 취득 방법이 아니다. PC에는 OEM 또는 소매 Windows Pro와 같은 자격 라이선스가 필요할 수 있다.

조직용 Windows는 다음 방식으로 라이선스될 수 있다.

• 장치별 영구 라이선스
• 사용자별 구독 라이선스
• Microsoft 365에 포함된 권리
• 교육기관 사용자 또는 장치 라이선스
• 가상 데스크톱 접근 라이선스
• Software Assurance가 포함된 계약

사용자별 라이선스는 한 사용자가 여러 장치와 가상 환경에서 Windows에 접근하는 경우에 유리할 수 있다. 장치별 라이선스는 교대 근무나 공용 장치처럼 여러 사용자가 한 컴퓨터를 공유하는 환경에 적합할 수 있다.

실제 사용 권리는 계약 프로그램과 Product Terms에 따라 달라지며, 같은 Enterprise E3이라는 이름이라도 구매 채널과 포함 제품에 따라 부가 권리가 다를 수 있다.

영구 라이선스와 구독

영구 라이선스는 특정 제품 버전을 계속 사용할 권리를 제공한다. 지원 종료 이후에도 설치된 제품을 사용할 수는 있지만 새로운 보안 업데이트, 기능과 기술 지원이 제공되지 않을 수 있다.

구독 라이선스는 계약이 활성화된 기간 동안 제품과 관련 서비스를 사용할 권리를 제공한다. Enterprise E3·E5, Education A3·A5와 Microsoft 365에 포함된 Windows 권리가 대표적이다.

구독이 끝나면 해당 구독으로 제공된 Enterprise 또는 Education 기능과 가상 데스크톱 접근 권리도 종료될 수 있다. 장치에 별도로 존재하는 OEM 또는 Pro 라이선스는 그 자체의 조건에 따라 남는다.

다운그레이드 권리

일부 Pro, Enterprise, Education와 Windows Server 라이선스는 이전 버전을 사용할 수 있는 다운그레이드 권리를 제공한다. 이는 새 버전 라이선스를 취득하면서 호환성 때문에 이전 Windows 버전을 설치해 사용하는 권리다.

다운그레이드 권리는 다음과 구분해야 한다.

• 새 버전에서 이전 버전으로 실제 시스템을 되돌리는 복구 기능
• 설치 미디어를 구하는 권리
• 이전 버전의 지원 연장
• 여러 버전을 동시에 사용하는 권리

다운그레이드 권리가 있어도 이전 버전의 설치 미디어와 정품 인증 키를 별도로 준비해야 할 수 있으며, 해당 버전의 기술 지원이 이미 종료되었다면 보안 업데이트가 제공되지 않을 수 있다.

정품 인증

Windows 정품 인증은 설치된 Windows가 유효한 제품 키나 디지털 라이선스와 연결되어 있는지를 확인하는 기술적 절차다.

정품 인증은 불법 복제를 제한하고 하나의 라이선스가 허용된 범위를 넘어 사용되는 것을 줄이기 위해 도입되었다. Windows XP부터 일반 소비자용 Windows에 널리 적용되었으며, 이후 OEM 펌웨어 키, 디지털 라이선스, 조직용 KMS와 구독 인증으로 확장되었다.

Windows는 다음 방법 가운데 하나로 인증될 수 있다.

• 제품 키
• 디지털 라이선스
• OEM 펌웨어 키
• Microsoft 계정에 연결된 디지털 라이선스
• KMS
• MAK
• Active Directory 기반 정품 인증
• Microsoft Entra 기반 구독 정품 인증
• Azure와 가상 머신의 자동 활성화
• 전화 또는 제품 정품 인증 포털

Microsoft는 Windows 11과 Windows 10이 25자리 제품 키 또는 디지털 라이선스를 통해 정품 인증될 수 있다고 설명한다.^[257]

제품 키

Windows 제품 키는 일반적으로 다음 형식의 25자리 문자로 구성된다.

XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

제품 키는 Windows 에디션과 배포 채널에 연결된다. Home 제품 키로 Pro를 인증하거나, 일반 소매 키로 볼륨 라이선스 에디션을 자동 인증할 수 있는 것은 아니다.

키는 다음 위치에서 제공될 수 있다.

• 제품 패키지
• 디지털 구매 내역
• Microsoft 계정 주문 기록
• PC의 UEFI 펌웨어
• 조직의 라이선스 관리 포털
• 제품 키 카드
• Microsoft Store의 에디션 업그레이드

제품 키를 입력하면 Windows는 키 형식과 에디션을 확인하고, Microsoft 정품 인증 서버 또는 조직의 인증 인프라와 통신하여 장치의 인증 상태를 설정한다.

디지털 라이선스

디지털 라이선스는 사용자가 매번 제품 키를 입력하지 않아도 특정 장치와 Windows 에디션의 인증 권리를 Microsoft 정품 인증 서버에 기록하는 방식이다. 과거에는 디지털 권리라는 표현도 사용되었다.

디지털 라이선스는 다음 과정에서 만들어질 수 있다.

• 정품 Windows의 무료 업그레이드
• Microsoft Store에서 에디션 업그레이드 구매
• 디지털 방식의 Windows 구매
• OEM 사전 설치
• 기존 제품 키로 성공적으로 인증된 장치
• 조직의 구독 정품 인증

같은 장치에 같은 에디션의 Windows를 다시 설치하면 설치 과정에서 제품 키 입력을 건너뛰더라도 인터넷에 연결된 뒤 하드웨어 정보와 디지털 라이선스를 확인해 자동으로 인증될 수 있다.

Microsoft 계정과 디지털 라이선스를 연결하면 중요한 하드웨어 변경 후 정품 인증 문제 해결사를 이용할 수 있다. 그러나 계정 연결이 모든 OEM 라이선스를 자유롭게 다른 장치로 이전할 수 있게 만드는 것은 아니다. 이전 권리는 원래 취득한 라이선스 조건을 따른다.

하드웨어 변경

Windows 정품 인증은 장치의 하드웨어 구성에서 생성한 식별 정보를 사용한다. 메모리, 저장 장치나 그래픽 카드 일부를 교체해도 일반적으로 같은 장치로 판단되지만, 메인보드 교체는 중요한 하드웨어 변경으로 인식될 수 있다.

소매 라이선스는 이전 장치에서 제거한 뒤 새 장치에서 다시 인증할 수 있는 경우가 있지만, OEM 라이선스는 원래 장치에 연결되는 것이 일반적이다.

정품 인증 문제 해결사는 Microsoft 계정에 연결된 장치 목록에서 현재 컴퓨터를 선택하여 재인증을 시도할 수 있다. 자동 처리가 되지 않으면 제품 정품 인증 포털이나 Microsoft 지원 절차를 사용할 수 있다.

KMS

Key Management Service 또는 KMS는 조직 내부에 정품 인증 서버를 운영하고 클라이언트가 주기적으로 해당 서버에 접속하여 인증받는 방식이다.

KMS 클라이언트에는 일반 볼륨 라이선스 키 또는 GVLK가 설치된다. GVLK는 Microsoft의 공개 인터넷 정품 인증 서버에서 독립적인 영구 라이선스로 인증하는 키가 아니라, 조직의 KMS 호스트나 Active Directory 기반 인증을 찾도록 하는 설정 키다.

KMS의 일반적인 흐름은 다음과 같다.

KMS 정품 인증 흐름

1. 조직이 KMS 호스트에 고객별 호스트 키 설치
   ↓
2. KMS 호스트가 Microsoft에서 한 번 활성화
   ↓
3. DNS에 KMS 서비스 위치 등록
   ↓
4. 클라이언트에 GVLK 설치
   ↓
5. 클라이언트가 DNS로 KMS 호스트 검색
   ↓
6. KMS 호스트가 조직 내부 인증 제공
   ↓
7. 클라이언트가 주기적으로 인증을 갱신

KMS는 일정 수 이상의 클라이언트가 존재하는 조직을 대상으로 한다. 인증된 클라이언트는 주기적으로 KMS 호스트에 다시 연결해야 하며, 장기간 연결하지 못하면 인증 유예 상태가 끝날 수 있다.

KMS는 키 하나를 인터넷에 공개하여 무제한 장치를 영구 인증하는 체계가 아니다. 조직 내부 서비스, 최소 활성화 임계값, 갱신 주기와 볼륨 라이선스 계약을 전제로 한다.

MAK

Multiple Activation Key 또는 MAK는 하나의 조직용 키에 정해진 수의 인증 횟수를 부여하고, 각 장치가 Microsoft 정품 인증 서버 또는 프록시를 통해 영구적으로 인증받는 방식이다.

MAK는 다음 환경에 적합할 수 있다.

• KMS 임계값보다 장치가 적은 조직
• 조직 네트워크에 자주 연결하지 않는 컴퓨터
• 격리된 네트워크
• 장기간 독립적으로 운용하는 장치
• 단순한 인증 구조를 원하는 환경

Microsoft는 MAK가 KMS를 운영할 조건을 충족하지 못하는 소규모·중간 규모 조직이나 격리된 컴퓨터에 사용할 수 있다고 설명한다.^[258]

MAK 인증은 KMS처럼 정기적으로 조직 서버에 연결하여 갱신하지 않는다. 다만 운영체제 재설치, 가상 머신 복제와 큰 하드웨어 변경은 추가 인증 횟수를 사용할 수 있다.

조직은 Volume Activation Management Tool을 이용해 여러 장치의 MAK 인증을 중앙에서 수행하고, 인터넷에 직접 연결되지 않은 컴퓨터의 인증을 프록시 방식으로 처리할 수 있다.

Active Directory 기반 정품 인증

Active Directory-Based Activation 또는 ADBA는 도메인에 가입한 Windows 장치가 Active Directory에 저장된 활성화 객체를 통해 자동으로 인증되는 방식이다.

도메인 컴퓨터에 GVLK가 설치되어 있고 지원되는 Windows 에디션을 사용하면, 컴퓨터가 도메인에 연결될 때 별도의 KMS 서버 검색 과정 없이 Active Directory 인증 객체를 발견해 정품 인증될 수 있다.

Microsoft는 ADBA가 도메인 가입 컴퓨터를 자동으로 인증하며, 클라이언트에는 GVLK가 설치되어 있어야 한다고 설명한다.^[259]

ADBA의 장점은 다음과 같다.

• 별도 KMS 서버 주소를 관리할 필요가 적음
• 도메인 가입 과정과 자동 통합
• 원격 지사 장치가 도메인에 접속하면 인증 가능
• 기존 Active Directory 복제를 이용
• 사용자 개입이 거의 없음

ADBA는 Active Directory 도메인에 가입하지 않는 작업 그룹 컴퓨터에는 직접 적용되지 않는다. Microsoft Entra ID 가입과 Active Directory 도메인 가입도 서로 다른 체계이므로 구분해야 한다.

구독 정품 인증

구독 정품 인증은 조직 사용자의 클라우드 구독을 확인하여 Windows Pro 장치에서 Enterprise 또는 Education 기능을 활성화한다.

Microsoft Entra ID, Enterprise E3·E5 또는 Education 구독과 정품 인증된 자격 운영체제가 결합된다. 사용자가 라이선스가 할당된 조직 계정으로 로그인하면 Windows는 클라우드 라이선스를 확인하고 에디션을 전환한다.

Microsoft는 구독 정품 인증을 통해 기존 KMS나 MAK 기반 이미지 변경 없이 Enterprise와 Education 에디션을 사용자에게 제공할 수 있다고 설명한다.^[260]

이 방식은 사용자 단위 라이선스와 잘 맞는다. 사용자가 다른 자격 장치에 로그인하면 계약이 허용하는 범위에서 Enterprise 기능을 사용할 수 있다.

구독 인증에는 주기적인 인터넷 또는 조직 서비스 연결이 필요하다. 라이선스를 장기간 확인할 수 없거나 구독이 제거되면 장치가 기반 Pro 에디션으로 돌아갈 수 있다.

정품 인증 상태와 라이선스 준수

Windows 설정의 정품 인증 화면은 다음과 같은 상태를 표시할 수 있다.

• 디지털 라이선스로 정품 인증됨
• Microsoft 계정에 연결된 디지털 라이선스로 인증됨
• 조직의 정품 인증 서비스를 통해 인증됨
• 정품 인증되지 않음
• 구독이 활성화됨
• 제품 키나 에디션 불일치

이 상태는 기술적 인증 결과를 보여준다. 다음 항목까지 자동으로 보증하지는 않는다.

• 제품 키의 합법적인 구매 출처
• OEM 라이선스의 장치 이전 권리
• Enterprise 업그레이드의 기본 Pro 라이선스 존재
• 서버의 모든 물리 코어 라이선스
• 필요한 사용자 또는 장치 CAL
• 가상 머신의 실행 권리
• 조직의 구독 사용자 수
• 교육용 라이선스의 사용자 자격
• Software Assurance와 다운그레이드 권리
• 계약 만료 이후의 사용 권리

인터넷에서 매우 낮은 가격으로 판매되는 제품 키는 정품 인증에 성공하더라도 다른 조직의 볼륨 키, 개발자용 키, 교육용 키, 지역 제한 키나 부정한 결제로 취득한 키일 수 있다. 이후 차단되거나 계약상 사용 권리가 인정되지 않을 수 있다.

Windows 라이선스의 최종 조건은 제품 키의 모양이나 정품 인증 메시지가 아니라 Microsoft Software License Terms, Microsoft Product Terms와 구매 계약을 기준으로 판단한다.

정품 인증은 라이선스 준수를 돕는 기술이지만 라이선스 자체를 대체하지 않는다. 개인 사용자는 구매 증빙과 제품 종류를 보관하고, 조직은 장치·사용자·가상 머신·서버 코어와 CAL을 별도의 자산 관리 체계에서 추적해야 한다.