Windows Administration

Windows Vista 커널 속으로: 2부

Mark Russinovich

한 눈에 보기:

• 메모리 관리
• 시작 및 종료
• 전원 관리

3부로 구성된 이 연재물의 첫 번째 칼럼이 게시되었던 지난 달에는 프로세스와 I/O 영역에서 Windows Vista 커널의 향상된 기능을 살펴봤습니다.

이번 호에는 시스템 시작, 종료 및 전원 관리와 Windows Vista의 메모리 관리 방식에서 어떤 점이 향상되었는지 설명하겠습니다(1부).

Windows®는 새로운 릴리스가 나올 때마다 확장성과 성능이 향상되었으며 Windows Vista™도 예외는 아닙니다. Windows Vista 메모리 관리자에는 멈춤 없는 동기화 기술, 세부적인 잠금, 더 강력해진 데이터 구조 압축, 더 큰 페이징 I/O, 최신 GPU 메모리 아키텍처 지원, 하드웨어 TLB(Translation Lookaside Buffer)의 효율적 활용 등 다양한 향상된 기능이 포함되어 있습니다. 또한 Windows Vista 메모리 관리 기능은 이제 다양한 작업 부하 요구 사항을 충족하는 동적 주소 공간 할당을 제공합니다.

Windows Vista에서는 새로운 4가지 성능 향상 기술인 SuperFetch, ReadyBoost, ReadyBoot 및 ReadyDrive가 새롭게 제공됩니다. 이에 대해서는 뒷부분에서 자세히 살펴보겠습니다.

동적 커널 주소 공간

Windows와 Windows용 응용 프로그램은 32비트 프로세서의 주소 공간 한계에 직면했습니다. 즉, Windows 커널은 기본적으로 2GB 또는 전체 32비트 가상 주소 공간의 절반으로 제한되며 나머지 절반은 CPU에서 현재 실행되고 있는 스레드가 속한 프로세스에 사용하도록 예약됩니다. 커널은 이 절반의 주소 공간에서 자신을 매핑하고, 장치 드라이버, 파일 시스템 캐시, 커널 스택, 세션별 코드 데이터 구조 및 장치 드라이버가 할당하는 비페이징(잠긴 실제 메모리) 버퍼와 페이징 버퍼 모두를 매핑해야 합니다. Windows Vista 이전의 메모리 관리자는 부팅될 때 이러한 여러 용도로 할당할 주소 공간의 크기를 결정했습니다. 즉, 이와 같이 유연하지 못하기 때문에 일부 영역에는 가용 공간이 많이 남고 일부 영역에는 가용 공간이 없는 상황이 발생하기도 합니다. 영역을 모두 사용하게 되면 응용 프로그램 오류가 발생하고 장치 드라이버는 I/O 작업을 마칠 수 없게 됩니다.

32비트 Windows Vista에서는 메모리 관리자가 커널의 주소 공간을 동적으로 관리하여 작업 부하 요구 사항에 따라 공간을 여러 용도에 할당 및 할당 취소합니다. 즉, 장치 드라이버가 더 많은 주소 공간을 요구하면 페이징 버퍼 저장에 사용되는 가상 메모리의 양을 늘릴 수 있으며 드라이버의 요구가 사라지면 가상 메모리의 양을 줄일 수 있습니다. 따라서 Windows Vista는 더 다양한 작업 부하를 처리할 수 있으며, 마찬가지로 향후 발표될 Windows Server®의 32비트 버전인 코드명 "Longhorn"에서는 더 많은 동시 터미널 서버 사용자를 처리할 수 있습니다.

물론 64비트 Windows Vista 시스템의 주소 공간에는 현재 실질적으로 아무런 제약이 없으므로 최대값으로 구성하기 위한 별다른 조치는 필요하지 않습니다.

메모리 우선 순위

지난 호에서 언급했듯이 Windows Vista에서는 I/O 우선 순위를 추가한 것처럼 메모리 우선 순위도 구현합니다. Windows가 메모리 우선 순위를 사용하는 방식을 이해하려면 메모리 관리자가 대기 목록이라고 하는 메모리 캐시를 구현하는 방식을 이해해야 합니다. Windows Vista 이전의 모든 Windows 버전에서는 프로세스가 소유하는 실제 페이지(일반적으로 크기가 4KB)를 시스템이 회수하면 메모리 관리자는 일반적으로 페이지를 대기 목록의 끝에 배치합니다. 프로세스가 페이지에 다시 액세스하려고 하면 메모리 관리자가 대기 목록에서 페이지를 가져와서 프로세스에 다시 할당합니다. 프로세스가 실제 메모리의 새 페이지를 사용하려고 하는데 사용 가능한 메모리가 없으면 메모리 관리자는 대기 목록의 앞에 있는 페이지를 프로세스에 할당합니다. 이러한 구성에서는 대기 목록의 모든 페이지가 기본적으로 동일하게 처리되며 목록에 배치된 시간만 정렬의 기준으로 사용됩니다.

Windows Vista에서는 메모리의 모든 페이지에 0부터 7까지의 우선 순위가 있기 때문에 메모리 관리자는 대기 목록을 특정 우선 순위의 페이지가 저장되는 8개의 목록으로 나눕니다. 메모리 관리자는 대기 목록에서 페이지를 가져올 때 우선 순위가 낮은 목록에서부터 페이지를 가져옵니다. 페이지의 우선 순위에는 일반적으로 해당 페이지를 처음 할당한 스레드의 우선 순위가 반영됩니다. 페이지가 공유된 경우에는 공유 스레드 중 가장 높은 메모리 우선 순위가 반영됩니다. 스레드는 자신이 속한 프로세스에서 페이지 우선 순위 값을 상속합니다. 메모리 관리자는 프로세스의 메모리 액세스를 예측할 때 미리 디스크에서 읽는 페이지에 대해 낮은 우선 순위를 사용합니다.

기본적으로 프로세스의 페이지 우선 순위 값은 5이지만 함수를 사용하면 응용 프로그램과 시스템이 프로세스 및 스레드 페이지 우선 순위 값을 변경할 수 있습니다. 메모리 우선 순위의 진정한 효과는 페이지의 상대적 우선 순위를 전체적인 차원에서 이해할 때만 현실화되는데 이 작업을 바로 SuperFetch가 수행합니다.

SuperFetch

메모리 관리자가 실제 메모리를 관리하는 방식에는 상당한 변화가 있습니다. 이전 버전의 Windows에서 사용되던 대기 목록 관리에는 두 가지 제한이 있습니다. 첫 번째는 페이지의 우선 순위 지정이 프로세스의 최근 동작에만 의존하며 향후의 메모리 요구 사항은 예측하지 않는다는 점입니다. 두 번째는 우선 순위 지정에 사용되는 데이터가 모든 특정 시점에서 프로세스가 소유한 페이지의 목록으로 제한된다는 점입니다. 이러한 단점 때문에 잠시 컴퓨터 앞을 떠나면 바이러스 검사나 디스크 조각 모음과 같이 메모리 사용이 많은 시스템 응용 프로그램이 실행되는 "점심 식사 후 신드롬"과 같은 상황이 발생할 수 있습니다. 이 경우 현재 활성화된 응용 프로그램이 메모리에 캐시한 코드와 데이터를 메모리 사용량이 많은 작업이 덮어쓰게 됩니다. 사용자가 다시 컴퓨터로 돌아오면 응용 프로그램은 데이터와 코드를 디스크에 요청해야 하기 때문에 성능 저하가 발생합니다.

Windows XP에서는 대용량 디스크 I/O를 수행하여 이전의 부팅 및 응용 프로그램 실행을 기준으로 예측되는 코드와 파일 시스템 데이터를 메모리에 미리 로드함으로써 부팅과 응용 프로그램의 시작 성능을 높이는 프리페치(Prefetch)를 지원했습니다. Windows Vista에서는 기록 정보와 예측적인 메모리 관리를 기반으로 "오래 전 액세스(Least-Recently Accessed)" 알고리즘을 향상시키는 메모리 관리 구성인 SuperFetch를 통해 이를 더욱 향상시킵니다.

SuperFetch는 서비스 호스트 프로세스(%SystemRoot%\System32\Svchost.exe) 내에서 실행되는 Windows 서비스로 %SystemRoot%\System32\Sysmain.dll에서 구현됩니다. 이 구성은 메모리 관리자의 지원을 통해 페이지 사용 내역을 검색하며, 메모리 관리자가 디스크의 파일이나 페이징 파일의 데이터와 코드를 대기 목록으로 미리 로드하고 페이지에 우선 순위를 할당하도록 합니다. SuperFetch 서비스는 기본적으로 메모리에 한 번 로드되었지만 새 데이터와 코드를 위한 공간을 마련하기 위해 메모리 관리자에서 다시 사용되는 데이터와 코드에까지 페이지 추적을 확장합니다. 이 정보는 응용 프로그램 실행을 최적화하는 데 사용되는 표준 프리페치 파일과 함께 %SystemRoot%\Prefetch 디렉터리에서 .db 확장명으로 시나리오 파일에 저장됩니다. SuperFetch는 메모리 사용에 대한 이러한 자세한 정보를 통해 실제 메모리를 사용할 수 있게 되었을 때 데이터와 코드를 미리 로드합니다.

응용 프로그램이 종료되었거나 메모리가 해제된 경우와 같이 메모리가 해제되면 SuperFetch는 최근 지워진 데이터와 코드를 페치하도록 메모리 관리자에게 요청합니다. 이 작업은 매우 낮은 우선 순위 I/O를 통해 초당 몇 페이지의 속도로 수행되므로 미리 로드가 사용자나 기타 활성 응용 프로그램에는 영향을 미치지 않습니다. 따라서 점심 식사를 위해 자리를 비운 동안 메모리 사용이 많은 백그라운드 작업으로 인해 활성 응용 프로그램의 코드와 데이터가 메모리에서 삭제된 경우 SuperFetch는 사용자가 돌아오기 전에 이 코드와 데이터 전부 또는 대부분을 다시 메모리로 로드할 수 있습니다. 또한 SuperFetch는 최대 절전 모드, 대기 모드, FUS(빠른 사용자 전환) 및 응용 프로그램 실행에 대한 몇 가지 시나리오도 지원합니다. 예를 들어 시스템이 최대 절전 모드에 들어가면 SuperFetch는 이전의 최대 절전 모드를 기준으로 하여 이후의 작업 재개 도중 액세스할 것으로 예상되는 데이터와 코드를 최대 절전 모드 파일에 저장합니다. 이와 반대로 Windows XP에서는 작업을 다시 시작하는 경우 이전에 캐시된 데이터가 참조되면 해당 데이터를 디스크에서 다시 읽어야 합니다.

SuperFetch가 사용 가능한 메모리에 영향을 주는 방식에 대해서는 추가 기사 "SuperFetch 살펴보기"를 참조하십시오.

SuperFetch 살펴보기

Windows Vista 시스템을 어느 정도 사용하고 나면 작업 관리자의 성능 페이지에 Free Physical Memory(사용 가능한 실제 메모리) 카운터의 숫자가 낮은 것을 볼 수 있습니다. SuperFetch와 표준 Windows 캐시가 디스크 데이터를 캐시하기 위해 사용 가능한 모든 실제 메모리를 사용하기 때문입니다. 예를 들어 처음 부팅했을 때 즉시 작업 관리자를 실행하면 Cached Memory(캐시된 메모리)의 값이 늘어남에 따라 Free Memory(사용 가능한 메모리) 값이 줄어드는 것을 볼 수 있습니다. 메모리를 많이 사용하는 프로그램을 실행한 후 종료하거나(예: 많은 양의 메모리를 할당했다가 해제하는 프리웨어 "RAM 최적화 프로그램") 매우 큰 파일을 복사한 경우에는 시스템이 할당 해제된 메모리를 회수하기 때문에 사용 가능 숫자는 올라가고 실제 메모리 사용 현황 그래프는 떨어집니다. 하지만 시간이 지나면 SuperFetch는 강제로 메모리에서 해제된 데이터를 캐시에 다시 채우므로 캐시됨 메모리 값은 늘어나고 사용 가능 메모리 값은 줄어듭니다.

Watching memory(더 크게 보려면 이미지를 클릭하십시오.)

ReadyBoost

CPU와 메모리의 속도는 하드 디스크 속도와 비교할 수 없을 정도로 빠르기 때문에 디스크는 흔히 시스템 성능의 병목 지점이 됩니다. 특히 디스크 헤드 검색 시간은 오늘날 많이 사용되는 3GHz 프로세서에 비하면 매우 느린 10밀리초대에 머무르기 때문에 임의 디스크 I/O는 특히 심한 병목 지점이 됩니다. 디스크 데이터의 캐시에는 RAM이 이상적이기는 하지만 RAM은 상대적으로 가격이 높습니다. 그러나 플래시 메모리는 일반적으로 저렴하며 일반 하드 디스크에 비해 최대 10배 빠른 임의 읽기를 제공할 수 있습니다. 따라서 Windows Vista에는 메모리와 디스크 사이에 논리적으로 존재하는 중간 캐시 계층을 플래시 메모리에 만들어서 플래시 메모리 저장 장치의 장점을 활용하는 ReadyBoost라는 기능이 포함되어 있습니다.

ReadyBoost는 서비스 호스트 프로세스에서 실행되는 %SystemRoot%\System32\Emdmgmt.dll에서 구현되는 서비스와 볼륨 필터 드라이버인 %SystemRoot%\System32\Drivers\Ecache.sys로 구성됩니다. Emd는 외부 메모리 장치(Enternal Memory Device)를 의미하며 개발 과정에서는 ReadyBoost의 임시 명칭이었습니다. USB 키 등의 플래시 장치를 시스템에 연결한 경우 ReadyBoost 서비스는 장치의 성능 특성을 검사하고 그 테스트 결과를 그림 1에 표시된 것처럼 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt에 저장합니다.

Figure 1** ReadyBoost device test results in the registry **(더 크게 보려면 이미지를 클릭하십시오.)

아직 장치를 캐시용으로 사용하고 있지 않은 경우 새 장치의 크기가 256MB부터 32GB 사이이고 임의 4KB 읽기에 대한 전송 송도가 2.5MB/s 이상, 임의 512KB 쓰기에 대한 전송 속도가 1.75MB/s 이상이면 ReadyBoost는 저장 장치의 최대 4GB를 디스크 캐시에 사용할 것인지 묻습니다(ReadyBoost는 NTFS를 사용할 수 있지만 FAT32 제한을 수용할 수 있도록 최대 캐시 크기를 4GB로 제한함). 이 질문에 동의하면 서비스는 장치의 루트에 ReadyBoost.sfcache라는 캐시 파일을 만들고 SuperFetch에게 백그라운드에서 캐시를 채우라고 요청합니다.

ReadyBoost 서비스가 캐시를 초기화하고 나면 Ecache.sys 장치 드라이버는 로컬 하드 디스크 볼륨(예: C:\)에 대한 모든 읽기와 쓰기를 가로채고 기록 중인 모든 데이터를 서비스가 만든 캐시 파일에 씁니다. Ecache.sys는 데이터를 압축하며 일반적으로 2:1 압축 비율을 제공하기 때문에 4GB 캐시 파일에는 대개 8GB의 데이터가 포함됩니다. 드라이버는 장치가 시스템에서 제거되었을 때 캐시에 있는 데이터의 보안을 유지하기 위해 AES(고급 암호화 표준) 암호화를 사용하여 임의로 생성된 부팅별 세션 키로 각 블록을 암호화합니다.

ReadyBoost는 캐시에서 사용 가능한 임의 읽기 작업이 있으면 캐시에서 이를 지원합니다. 그러나 하드 디스크는 플래시 메모리보다 순차 읽기 액세스 성능이 더 뛰어나므로 ReadyBoost는 순차 액세스 패턴의 일부인 읽기 작업을 데이터가 캐시에 있더라도 디스크에서 직접 수행할 수 있습니다.

ReadyBoot

Windows Vista는 시스템 메모리가 512MB 미만인 경우에는 Windows XP와 동일하게 부팅 시 프리페치를 사용하지만 시스템 RAM이 700MB 이상인 경우에는 부팅 프로세스를 최적화하기 위해 RAM 내부 캐시를 사용합니다. 캐시의 크기는 사용 가능한 전체 RAM에 따라 다르지만 적절한 캐시를 만들 수 있으면서 시스템이 매끄럽게 부팅될 수 있을 정도가 사용됩니다.

모든 부팅 후 ReadyBoost 서비스(앞서 설명한 ReadyBoost 기능을 구현하는 것과 같은 서비스)는 유휴 CPU 시간을 사용하여 다음 부팅에 대한 부팅 시간 캐시 계획을 계산합니다. 다섯 번의 이전 부팅을 토대로 파일 추적 정보를 분석하여 액세스된 파일의 위치와 디스크에서의 각 파일 위치를 확인합니다. 이렇게 처리된 추적을 %SystemRoot%\Prefetch\Readyboot에 .fx 파일로 저장하고 캐시 계획은 HKLM\System\CurrentControlSet\Services\Ecache\Parameters 아래에서 추적이 참조하는 내부 디스크 볼륨을 따라 이름이 지정된 REG_BINARY 값으로 저장합니다.

캐시는 ReadyBoost 캐시를 구현하는 것과 동일한 장치 드라이버(Ecache.sys)로 구현되지만 캐시를 채우는 작업은 시스템 부팅 시 ReadyBoost 서비스에 의해 진행됩니다. 부팅 캐시는 ReadyBoost 캐시처럼 압축되지만 ReadyBoost와 ReadyBoot 캐시 관리의 또 다른 차이점은 ReadyBoot 모드에서는 ReadyBoost 서비스의 업데이트를 제외하고 부팅 도중 읽거나 쓴 데이터에 따라 캐시가 변경되지 않는다는 점입니다. ReadyBoost 서비스는 부팅 시작 90초 후 또는 다른 메모리에서 이와 같이 요구하는 경우 캐시를 삭제하며 캐시의 통계를 그림 2와 같이 HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats에 기록합니다. Microsoft의 성능 테스트 결과 ReadyBoot는 이전 Windows XP 프리페처에 비해 약 20퍼센트 높은 성능 향상을 제공합니다.

Figure 2** ReadyBoot Performance statistics **(더 크게 보려면 이미지를 클릭하십시오.)

ReadyDrive

ReadyDrive는 H-HDD라고 하는 새로운 혼성 하드 디스크 드라이브를 사용하는 Windows Vista 기능입니다. H-HDD는 NVRAM이라고도 하는 비휘발성 플래시 메모리가 내장된 디스크입니다. 일반적인 H-HDD에는 50MB에서 512MB의 캐시가 포함되지만 Windows Vista의 캐시 제한은 2TB입니다.

Windows Vista는 ATA-8 명령을 사용하여 플래시 메모리에 유지될 디스크 데이터를 정의합니다. 예를 들어 Windows Vista는 더 빠르게 다시 시작할 수 있도록 시스템 종료 시 부팅 데이터를 캐시에 저장합니다. 또한 시스템이 최대 절전 모드에서 더 빠르게 다시 시작할 수 있도록 시스템이 최대 절전 모드에 들어갈 때 최대 절전 모드 파일 일부를 캐시에 저장합니다. 캐시는 디스크가 회전하지 않을 때도 사용할 수 있기 때문에 Windows에서는 배터리 전원으로 시스템을 실행할 때 디스크를 회전시키지 않고 플래시 메모리를 디스크 쓰기 캐시로 사용할 수 있습니다. 디스크가 회전하지 않도록 하면 일반적인 사용 상황에서 디스크 드라이브가 소모하는 전력을 상당히 절약할 수 있습니다.

부팅 구성 데이터베이스

Windows Vista에서는 시작 및 종료의 여러 측면이 향상되었습니다. 시스템 및 OS 시작 구성을 저장하기 위한 BCD(부팅 구성 데이터베이스), 시스템 시작 프로세스의 새로운 흐름 및 구성, 새로운 로그온 아키텍처, 지연된 자동 시작 서비스 지원 등을 통해 시작 기능이 향상되었습니다. Windows Vista 종료 기능은 Windows 서비스의 사전 종료 알림, Windows 서비스 종료 순서 지정 및 OS의 전원 상태 전환 관리 방법을 비롯하여 상당히 변경되었습니다.

시작 프로세스에서 가장 눈에 띄는 변화는 시스템 볼륨의 루트에 Boot.ini가 없다는 점입니다. 이전 버전의 Windows에서 Boot.ini 텍스트 파일에 저장되던 부팅 구성이 Windows Vista에서는 BCD에 저장되기 때문입니다. Windows Vista에서 BCD를 사용하는 이유 중 하나는 BCD를 통해 Windows가 지원하는 두 가지의 최신 부팅 아키텍처인 MBR(마스터 부트 레코드)과 EFI(Extensible Firmware Interface)를 통합할 수 있기 때문입니다. MBR은 일반적으로 x86 및 x64 데스크톱 시스템에 사용되며 EFI는 Itanium 기반 시스템에 사용됩니다. 그러나 조만간 데스크톱 PC에도 EFI 지원이 적용될 것으로 예상됩니다. BCD는 펌웨어를 추상화하며 유니코드 문자열 지원 또는 대체 부팅 전 실행 파일 지원과 같이 Boot.ini에 비해 여러 가지 장점을 갖고 있습니다.

BCD는 실제로 Windows 레지스트리로 로드되어 레지스트리 API를 통해 액세스할 수 있는 레지스트리 하이브에 저장됩니다. PC의 경우 BCD는 시스템 볼륨의 \Boot\Bcd에 저장되고 EFI 시스템의 경우에는 EFI 시스템 파티션에 저장됩니다. 하이브는 로드된 경우 HKLM\Bcd00000000 아래에 나타나지만 내부 형식은 문서화되지 않으므로 하이브를 편집하려면 %SystemRoot%\System32\Bcdedit.exe와 같은 도구를 사용해야 합니다. 또한 BCD를 조작하기 위한 인터페이스를 WMI(Windows Management Instrumentation)를 통해 사용자 정의 편집기 및 스크립트에서도 사용할 수 있으며, Windows 시스템 구성 유틸리티(%SystemRoot%\System32\Msconfig.exe)를 사용하여 커널 디버깅 옵션과 같은 기본 매개 변수를 편집하거나 추가할 수 있습니다.

BCD는 기본 OS 선택 및 부팅 메뉴 시간 제한과 같은 플랫폼 전체의 부팅 설정을 OS 부팅 옵션 및 OS 부팅 로더의 경로와 같은 OS별 설정과 분리합니다. 예를 들어 그림 3에서 Bcdedit를 명령줄 옵션 없이 실행하면 출력 상단의 Windows 부팅 관리자 섹션에 플랫폼 설정이 표시되고 그 뒤의 Windows 부팅 로더 섹션에 OS별 설정이 표시되는 것을 볼 수 있습니다.

Figure 3** Settings displayed in BCDEdit **(더 크게 보려면 이미지를 클릭하십시오.)

설치된 Windows Vista를 부팅하면 이러한 새로운 구성에 따라 이전 버전의 Windows에서 운영 체제 로더(Ntldr)로 처리되던 작업이 서로 다른 두 실행 파일인 \BootMgr 및 %SystemRoot%\System32\Winload.exe로 분리됩니다. Bootmgr은 BCD를 읽고 OS 부팅 메뉴를 표시하며, Winload.exe는 운영 체제 로드를 처리합니다. 클린 부팅을 수행하면 Winload.exe는 부팅 시작 장치 드라이버와 Ntoskrnl.exe를 포함한 운영 체제 핵심 파일을 로드하고 제어 권한을 운영 체제에게 넘깁니다. 시스템이 최대 절전 모드에서 다시 시작하는 경우에는 %SystemRoot%\System32\Winresume.exe를 실행하여 최대 절전 모드 데이터를 메모리로 로드하고 OS를 다시 시작합니다.

Bootmgr은 추가적인 부팅 전 실행 파일도 지원합니다. Windows Vista에서는 RAM의 상태를 검사하기 위한 옵션으로 미리 구성된 Windows 메모리 진단 도구(\Boot\Memtest.exe)를 제공하지만 타사의 부팅 전 실행 파일을 옵션으로 추가하여 Bootmgr의 부팅 메뉴에 표시할 수도 있습니다.

시작 프로세스

이전 버전의 Windows에서는 여러 시스템 프로세스 간의 관계가 간단하지 않았습니다. 예를 들어 시스템이 부팅될 때 대화형 로그온 관리자(%SystemRoot%\System32\Winlogon.exe)는 로컬 보안 기관 하위 시스템 서비스(Lsass.exe) 및 서비스 제어 관리자(Services.exe)를 실행합니다. 또한 Windows는 세션이라고 하는 네임스페이스 컨테이너를 사용하여 서로 다른 로그온 세션에서 실행되고 있는 프로세스를 격리합니다. 그러나 Windows Vista 이전에는 사용자가 세션 0을 공유하는 콘솔로 로그인했으며 이 세션은 시스템 프로세스에 사용되었기 때문에 잠재적인 보안 문제가 있었습니다. 예를 들어 잘못 작성된 Windows 서비스가 세션 0에서 실행되어 대화형 콘솔에 사용자 인터페이스를 표시하면 맬웨어가 파편 공격(Shatter Attack)과 같은 방법을 통해 Windows를 공격하고 관리 권한을 획득할 가능성이 있습니다.

이러한 문제를 해결하기 위해 Windows Vista에서는 몇 가지 시스템 프로세스의 아키텍처가 재구성되었습니다. 세션 관리자(Smss.exe)는 이전 버전의 Windows와 마찬가지로 부팅 도중 만들어지는 첫 번째 사용자 모드 프로세스이지만 Windows Vista에서는 세션 관리자가 자신의 두 번째 인스턴스를 실행하여 시스템 프로세스 전용으로 사용되는 세션 0을 구성합니다. 세션 0의 세션 관리자 프로세스는 세션 0에 대한 Windows 하위 시스템 프로세스(Csrss.exe)인 Windows 시작 응용 프로그램(Wininit.exe)을 실행한 다음 종료됩니다. Windows 시작 응용 프로그램은 계속해서 서비스 제어 관리자, 로컬 보안 기관 하위 시스템과 시스템에 대한 터미널 서버 연결을 관리하는 로컬 세션 관리자(Lsm.exe)를 시작합니다.

사용자가 시스템에 로그온하면 최초 세션 관리자는 자신의 인스턴스를 새로 만들어서 새 세션을 구성합니다. 새 Smss.exe 프로세스는 새 세션에 대한 Winlogon 프로세스와 Windows 하위 시스템 프로세스를 시작합니다. 기본 세션 관리자가 자신의 복사본을 사용하여 새 세션을 초기화하는 것이 클라이언트 시스템에는 이점이 되지 않지만, 터미널 서버 역할을 하는 Windows Server "Longhorn" 시스템에서는 여러 개의 복사본을 동시에 실행하여 여러 사용자의 로그온 속도를 높일 수 있습니다.

이와 같은 새로운 아키텍처를 통해 Windows 서비스를 비롯한 시스템 프로세스는 세션 0으로 격리됩니다. 세션 0에서 실행되는 Windows 서비스가 사용자 인터페이스를 표시하면 대화형 서비스 감지 서비스(%SystemRoot%\System32\UI0Detect.exe)가 사용자의 보안 컨텍스트에 자신의 인스턴스를 실행하고 그림 4의 메시지를 표시하여 로그온한 모든 관리자에게 이를 알립니다. 사용자가 "메시지 표시" 단추를 선택하면 이 서비스는 바탕 화면을 Windows 서비스 바탕 화면으로 변경합니다. 사용자는 이 바탕 화면에서 서비스의 사용자 인터페이스와 상호 작용한 다음 다시 자신의 바탕 화면으로 전환할 수 있습니다. 시작 시 수행되는 작업에 대한 자세한 내용은 추가 기사 "시작 프로세스 관계 보기"를 참조하십시오.

Figure 4** Service has displayed a window **(더 크게 보려면 이미지를 클릭하십시오.)

시작 프로세스 관계 보기

Sysinternals의 Process Explorer(microsoft.com/technet/sysinternals)를 사용하면 Windows Vista의 프로세스 시작 트리를 볼 수 있습니다.

스크린 샷에는 Process Explorer의 열 대화 상자를 통해 추가할 수 있는 세션 열이 포함되어 있습니다. 강조 표시된 프로세스는 최초 Smss.exe입니다. 그 아래에는 세션 0 Csrss.exe 및 Wininit.exe가 있습니다. 세션 0을 구성한 Smss.exe의 인스턴스인 상위 프로세스가 종료되었기 때문에 이 두 프로세스는 왼쪽으로 정렬되어 있습니다. Wininit의 세 가지 하위 프로세스는 Services.exe, Lsass.exe 및 Lsm.exe입니다.

Process Explorer를 통해 여러 프로세스가 세션 1에서 실행되고 있음을 확인할 수 있습니다. 이러한 세션은 필자가 원격 데스크톱 연결을 통해 로그인한 세션입니다. Process Explorer에서 동일한 계정으로 실행되고 있는 프로세스는 파란색으로 강조 표시되어 있습니다. 마지막으로, 세션 2가 초기화되어 사용자의 콘솔 로그인 및 새 로그온 세션 생성을 준비합니다. 이 세션에서 Winlogon이 실행되며 LogonUI가 새 콘솔 사용자에게 "로그온하려면 <Ctrl+Alt+Del> 을 누르십시오."를 표시하고 Logonui.exe가 사용자에게 자격 증명을 요청합니다.

Startup process and session information(더 크게 보려면 이미지를 클릭하십시오.)

자격 증명 공급자

Windows Vista에서는 로그온 아키텍처도 변경되었습니다. 이전 버전의 Windows에서는 Winlogon 프로세스가 레지스트리에 지정된 GINA(Graphical Identification and Authentication) DLL을 로드하여 사용자에게 자격 증명을 요청하는 로그온 UI를 표시했습니다. 그러나 GINA 모델에는 몇 가지 제약이 있습니다. 즉, 하나의 GINA만 구성할 수 있고, 타사에서 완벽한 GINA를 작성하는 것이 어렵고, 비표준 사용자 인터페이스가 있는 사용자 지정 GINA가 Windows 사용자 환경을 변경하는 것 등이 있습니다.

Windows Vista에서는 GINA 대신 새로운 자격 증명 공급자 아키텍처를 사용합니다. Winlogon은 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers에 구성된 자격 증명 공급자를 로드하는 로그온 사용자 인터페이스 호스트(Logonui.exe)라는 별도의 프로세스를 실행합니다. Logonui는 여러 개의 자격 증명 공급자를 동시에 호스트할 수 있습니다. 실제로 Windows Vista에서는 대화형 공급자(Authui.dll) 및 스마트 카드 공급자(Smart-cardcredentialprovider.dll)를 모두 제공합니다. 일관된 사용자 환경을 제공하기 위해 LogonUI는 최종 사용자에게 표시되는 사용자 인터페이스를 관리하며, 자격 증명 공급자는 LogonUI를 통해 텍스트, 아이콘 및 편집 컨트롤 등의 사용자 지정 요소를 지정할 수 있습니다.

지연된 자동 시작 서비스

Windows 시스템을 시작한 후 바로 로그인한 적이 있다면 데스크톱이 완전히 구성되고 셸 및 기타 응용 프로그램을 사용할 수 있을 때까지 약간의 시간이 지연되는 것을 경험했을 수 있습니다. 사용자가 로그온하는 동안 서비스 제어 관리자는 자동 시작 서비스로 구성되어 부팅할 때 활성화되는 여러 Windows 서비스를 시작합니다. CPU 및 디스크 사용량이 많은 초기화를 수행하는 서비스는 많이 있으며 이러한 서비스는 사용자의 로그온 작업과 경쟁하게 됩니다. 이러한 상황을 해결하기 위해 Windows Vista에서는 Windows 부팅 후 즉시 활성화할 필요가 없는 서비스에 사용할 수 있는 지연된 자동 시작이라고 하는 새로운 서비스 시작 유형을 제공합니다.

서비스 제어 관리자는 자동 시작 서비스의 시작이 완료된 후에 지연된 자동 시작으로 구성된 서비스를 시작하고 이러한 서비스의 초기 스레드 우선 순위를 THREAD_PRIORITY_LOWEST로 설정합니다. 이 우선 순위 수준으로 인해 스레드가 수행하는 모든 디스크 I/O는 매우 낮음 I/O 우선 순위가 됩니다. 서비스의 초기화가 완료되면 서비스 제어 관리자는 해당 우선 순위를 보통으로 설정합니다. 지연된 시작, 낮은 CPU 및 메모리 우선 순위, 백그라운드 디스크 우선 순위가 결합되어 사용자의 로그온에 미치는 영향이 크게 줄어듭니다. 부팅 후의 로그온 성능을 높이기 위해 BIT(Background Intelligent Transfer), Windows Update 클라이언트 및 Windows Media® Center를 포함한 많은 Windows 서비스가 이러한 새로운 시작 유형을 사용합니다.

종료

Windows 서비스 개발자를 괴롭히는 문제 중 하나는 Windows 종료 시 정리를 수행하기 위한 시간이 기본적으로 최대 20초라는 점입니다. Windows Vista 이전 버전의 Windows에서는 버그가 있는 서비스로 인해 종료가 완료되지 못할 수 있기 때문에 모든 서비스가 종료될 때까지 기다리는 "완전한 종료(Clean Shutdown)"를 지원하지 않았습니다. 하지만 네트워크 관련 종료 작업이 있거나 많은 데이터를 디스크에 저장해야 하는 일부 서비스의 경우에는 시간이 더 필요할 수 있기 때문에 Windows Vista에서는 서비스가 사전 종료 알림을 요청할 수 있습니다.

Windows Vista를 종료하면 서비스 제어 관리자는 먼저 사전 종료 알림을 요청하는 서비스에 Windows Vista 종료를 알립니다. 이러한 서비스가 종료될 때까지 무기한 대기하지만 버그가 있어서 쿼리에 응답하지 않는 서비스가 있는 경우 서비스 제어 관리자는 3분간 기다린 후 포기하고 다음 단계를 진행합니다. 이러한 서비스가 모두 종료되었거나 시간 제한이 만료되면 서비스 제어 관리자는 나머지 서비스에 대해 기존 방식의 서비스 종료를 진행합니다. 그룹 정책 및 Windows Update 서비스는 새로 설치된 Windows Vista의 사전 종료 알림을 등록합니다.

그룹 정책 및 Windows Update 서비스는 또한 다른 Windows Vista 서비스인 종료 순서 지정 기능도 사용합니다. Windows Vista 이전 버전의 Windows에서 서비스는 서비스 제어 관리자가 각 서비스에 맞는 순서로 서비스를 시작하도록 허용하는 시작 종속성을 지정할 수 있었지만 종료 종속성은 지정할 수 없었습니다. 이제는 사전 종료 알림에 등록한 서비스가 HKLM\System\CurrentControlSet\Control\PreshutdownOrder에 저장된 목록에 해당 서비스를 삽입할 수 있으며 이 경우 서비스 제어 관리자는 이 순서에 따라 해당 서비스를 종료합니다. 이러한 서비스에 대한 자세한 내용은 "지연된 자동 시작 및 사전 종료 서비스 확인" 추가 기사를 참조하십시오.

전원 관리

절전 모드 및 최대 절전 모드는 종료의 한 형태입니다. Windows 2000의 전원 관리 기능을 Windows NT® 기반 Windows 운영 체제 제품군에 적용한 이후로 드라이버와 응용 프로그램에서 발생하는 전원 관리 버그는 이동이 잦은 사용자에게 문제가 되곤 했습니다. 출장을 떠나기 전에 랩톱 시스템이 일시 중단 또는 최대 절전 모드로 들어갈 것으로 예상하고 랩톱 시스템을 닫았지만 목적지에 도착해 보니 랩톱 시스템이 계속 실행되고 있거나 배터리가 방전되었거나 데이터가 손실된 것을 경험한 사용자가 많습니다. 이러한 문제의 원인은 Windows가 항상 장치 드라이버와 응용 프로그램에게 전원 상태 변경에 대한 동의를 요청하며 응답하지 않는 드라이버나 응용 프로그램이 하나라도 있으면 전원 모드를 전환하지 않는다는 데 있습니다.

Windows Vista의 경우 커널의 전원 관리자는 드라이버와 응용 프로그램에게 전원 상태 변경을 알려 미리 준비할 수 있도록 하지만 이에 대해 동의를 구하지는 않습니다. 또한 전원 관리자는 이전 버전의 Windows에서처럼 2분씩 기다리는 것이 아니라 응용 프로그램이 변경 알림에 응답할 때까지 최대 20초만 기다립니다. 결과적으로 Windows Vista 사용자는 시스템의 최대 절전 모드 또는 일시 중단 모드로의 전환에 대해 안심할 수 있습니다.

다음 호에서 다룰 내용

앞서 설명했듯이 이 문서는 3부로 구성된 연재물 중 두 번째입니다. 1부에서는 I/O 및 프로세스 영역에서 Windows Vista 커널의 향상된 기능을 살펴봤습니다. 이번 호에서는 메모리 관리, 시작 및 종료 부분에서 Windows Vista의 향상된 기능에 대해 다루었습니다. 다음 호에서는 안정성 및 보안 측면에서 커널의 변경 사항을 설명하여 이 연재물을 마무리하려고 합니다.

지연된 자동 시작 및 사전 종료 서비스 확인

Windows Vista에서는 기본 제공 SC 명령이 업데이트되어 다음과 같이 지연된 자동 시작 서비스로 구성된 서비스가 표시됩니다.

Using SC to display start type(더 크게 보려면 이미지를 클릭하십시오.)

그러나 SC 명령은 사전 종료 알림을 요청한 서비스를 보고하지 않습니다. 대신 Sysinternals의 PsService 유틸리티를 사용하면 서비스가 사전 종료 알림을 수용하는지 확인할 수 있습니다.

Viewing pre-shutdown status(더 크게 보려면 이미지를 클릭하십시오.)

Mark Russinovich는 Microsoft의 플랫폼 및 서비스(Platform and Services) 부서에서 근무하는 기술 연구원으로, Microsoft Windows Internals(Microsoft Press, 2004)의 공동 저자이자 IT와 개발자 회의에 자주 서는 연설자이며 최근 Microsoft에서 인수한 Winternals Software의 공동 설립자이기도 합니다. 그는 자신이 설립한 Sysinternals에서 Process Explorer, Filemon 및 Regmon 유틸리티를 개발하기도 했습니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..