Windows 8의 런타임 메모리 사용량 감소

메모리 사용과 같은 기반 기술은 Windows 8 엔지니어링의 핵심 기조를 나타내는 부분입니다. Windows 8 개발 과정에서는 주요 시스템의 전반적인 런타임 메모리 요구 사항을 크게 줄이기 위해 노력했습니다. 이러한 개발 방향은 모든 사용자에게 유용할 뿐 아니라, 요즘같이 많은 앱을 동시에 실행하거나 1GB나 2GB의 메모리만으로 시스템을 실행하려는 실정에서는 꼭 필요한 부분이기도 합니다. 이번 글에서 언급하는 랩톱은 2008년 Windows 7 PDC에서 사용했던 동일한 사양의 1GB 메모리를 탑재한 1세대 상용 ATOM 기반의 넷북입니다. 이 글은 성능(Performance) 팀의 그룹 프로그램 관리자인 Bill Karagounis가 작성했으며, 메모리 사용과 관련된 개발 노력을 자세히 소개합니다. - Steven

Windows 8의 런타임 메모리 사용은 Windows 8 시스템 요구 사항을 결정할 뿐 아니라, 나아가서 Windows 8을 설치할 장치의 범위를 결정하게 될 중요한 요인입니다. 아시다시피 저희는 전력 소모가 적은 SoC 기반 장치에서 완벽한 Windows 8 사용 경험을 제공하고 있습니다. 따라서 동시 실행 중인 여러 앱에 필요한 많은 메모리를 확보하여 장치의 전반적인 응답 속도를 유지하는 일이 더욱 중요합니다.

하지만 전력 소모가 적은 플랫폼에서 메모리 사용을 최소화한다고 해서 배터리 수명이 늘어날 수 있을지는 의문입니다. 어떤 PC에서든 RAM은 지속적으로 전력을 소모하는데, OS의 메모리 사용량이 증가하면 장치 제조업체들은 더 많은 물리적 RAM을 탑재하려고 할 것입니다. 보드의 RAM 용량이 증가할수록 소모하는 전력이 늘어나 결국 배터리 수명은 줄어듭니다. 태블릿 장치의 RAM 용량이 늘어난다는 것은, 쉽게 말해 커피숍에 앉아 태블릿으로 최신 정보를 확인할 수 있는 시간이 줄어드는 것과 같습니다.

메모리 사용량과 관련한 목표

Windows 8에서 애초에 세웠던 목표는 Windows 7 시스템 요구 사항과 동일하게 유지하는 것이었습니다. 또한 공식적인 요구 사항을 동일하게 유지하면서 앱에 더 많은 리소스를 제공하도록 개선할 수 있을 것입니다. 2009년에 출시된 '로우엔드' 하드웨어의 사양을 보거나, 256MB 메모리 모듈을 이제는 찾아볼 수 없다는 사실을 떠올리면 시사하는 바가 큽니다. 저희는 Windows 7 시대의 하드웨어를 실행하는 사용자들이 기존 시스템을 Windows 8로 쉽게 업그레이드하여 최신 기능을 사용할 수 있기를 원했습니다. 성능 테스트 인프라에 보유하고 있는 구형 시스템에서 확인한 테스트 결과, Windows 7 출시 이전의 많은 시스템에서도 Windows 8이 실행될 것으로 예상됩니다.

기존 기능으로 인해 보드에서 소모되는 메모리를 줄이면서 새로운 기능을 구현할 방법을 찾는 것이 Windows 8 개발의 중점 사항이었습니다. Windows 8 개발은 처음에 세웠던 목표에 따라 순조롭게 진행되고 있습니다.

작업 관리자의 메모리 사용량 비교

Windows 8과 Windows 7의 메모리 사용을 대략적으로 비교하는 가장 쉬운 방법은 최소 OS RAM 요구 사항인 1GB RAM 시스템에 두 OS를 모두 설치한 다음, 여러 차례 재부팅하고 잠시 그대로 유지한 상태에서 비교하는 것입니다.

Windows 작업 관리자의 시스템 메모리 보기에는 '사용 중'인 메모리의 통계 정보가 나옵니다. (자세한 내용은 이 문서에서 설명되어 있습니다.) 아래 그림은 3년 이상 된 Steven의 구형 넷북에서 메모리 사용량을 비교한 결과입니다. 이 넷북은 Steven이 최근 //build/ 컨퍼런스에서 기조 연설을 할 때 가지고 나와 유휴(Idle) 상태에서 Windows 7을 실행한 다음, 동일 시스템에서 Windows 8을 실행했던 제품입니다.

Windows 7 작업 관리자. CPU 사용: 5%, 메모리: 404MB그림 1 – Windows 7 SP1의 메모리 사용

Windows 8 작업 관리자. CPU 사용: 1%, 메모리: 281MB그림 2 – Windows 8의 메모리 사용

시스템을 구성하는 특정 하드웨어, 드라이버의 메모리 사용량을 비롯해 작동 시간도 변수로 작용할 수 있기 때문에 메모리 결과는 시스템마다 차이가 있으며 동일 시스템에서도 시간에 따라 다른 결과가 나올 수 있습니다. 여기서 Windows 7에 비해 Windows 8이 효율적으로 개선되었다는 사실을 잘 알 수 있습니다.

테스트 시스템에서 알게 된 흥미로운 점이 또 하나 있는데, 먼저 장치 관리자로 이동한 후 디스플레이 어댑터의 사용을 해제하여 그래픽 드라이버를 언로드해 보십시오. 시스템을 이런 식으로 실행하는 경우는 없겠지만 Windows 자체의 메모리 사용량을 대략 파악할 수 있을 것입니다. 그래픽 드라이버 사용을 해제한 상태에서 잠시 유휴 상태로 두면 시스템 메모리 사용량이 200MB 이하로 떨어집니다.

참고: Windows 8을 새로 설치할 경우에는 확장된 Windows Defender 기술이 포함되며, 이 기술은 최초로 완전한 맬웨어 방지 기능을 제공합니다. 또한 맬웨어로부터 사용자 보호(Jason의 블로그)의 내용과 같이 이 기능은 메모리와 리소스 사용에 최적화되어 있습니다. 단, Windows 7은 새로 설치해도 이 기능이 제공되지 않으므로 보안 소프트웨어를 추가하는 것이 좋습니다.

Windows 8의 메모리 사용량 감소

Windows 8에서는 OS 메모리 사용을 최소화하기 위해 수많은 변화를 시도했는데, 여기서 실질적으로 메모리 감소에 기여한 몇 가지 내용을 소개합니다.

메모리 결합

일반적으로 실행되는 PC에서 RAM 내용을 분석해 보면 메모리의 많은 부분에 동일한 내용이 들어 있습니다. 시스템 RAM 전체에서 중복되는 데이터 복사본이 존재한다는 사실은 곧 서비스와 OS 구성 요소에 대해서도 메모리 사용을 줄일 수 있는 기회를 뜻합니다.

그렇다면 어떤 방법으로 줄일 수 있을까요? 때때로 응용 프로그램은 예비용으로 메모리를 할당해 두고 해당 메모리를 모두 동일한 값으로 초기화합니다. 응용 프로그램은 어떤 기능이 사용될 것을 예상하여 메모리를 미리 할당하지만, 사용자가 이 기능을 실행하지 않으면 이 메모리는 실제로 사용되지 않습니다. 실행 중인 여러 응용 프로그램에서 이러한 상황이 동시에 발생하면 시스템에 중복된 메모리 복사본이 여러 개 존재하게 됩니다.

메모리 결합이란 Windows가 정상 작업 중 시스템 RAM의 내용을 효율적으로 평가하여 모든 시스템 메모리에서 중복된 내용을 찾아내는 기술입니다. Windows는 복사본을 하나만 남기고 중복된 메모리를 모두 회수합니다. 응용 프로그램이 나중에 메모리에 기록하려고 하면 Windows가 개별 복사본을 제공합니다. 이 모든 과정은 응용 프로그램에 영향을 미치지 않고 메모리 관리자에서 자동으로 처리됩니다. 이 방법을 통해 동시에 실행하는 응용 프로그램 개수에 따라 수십 메가바이트에서 수백 메가바이트에 이르는 메모리를 절약할 수 있습니다.

서비스 변경 및 축소

장치 시작 후 항상 실행되도록 구성된 OS 서비스는 메모리를 지속적으로 사용합니다. Windows 8을 기획할 당시 OS 서비스 평가를 통해 이 중 13개 서비스를 없애고, 일부 서비스는 '수동' 시작으로 전환하고 '항상 실행되는' 서비스 중 일부는 '필요에 따라 시작하는' 모델로 전환하기로 결정했습니다. 예를 들어 장치가 발견되거나 네트워크 주소가 제공되는 경우와 같이 OS에서 '트리거'가 발생하면 다음 단계가 진행됩니다.

  1. 서비스가 시작됩니다.
  2. 서비스가 해당 기능을 수행합니다.
  3. 더 처리할 사항이 없는지 확인하기 위해 잠시 그대로 유지됩니다.
  4. 서비스가 중단됩니다.

Windows 8에서는 플러그 앤 플레이, Windows Update 및 사용자 모드 드라이버 프레임워크 서비스가 모두 트리거 방식으로 시작됩니다. 반면, Windows 7에서는 이러한 서비스가 항상 실행되고 있었습니다.

물론 Windows 8에 새롭게 도입된 기능과 새로운 코드도 무수히 많습니다. 새 기능 중 일부는 새로운 서비스 형태로 구성되며, 이러한 서비스 중 두 가지는 자동으로 시작되고 나머지는 모두 수동으로 시작되거나 트리거 방식으로 시작됩니다.

더 적은 메모리로 동일한 작업 처리 가능

Windows에서 응용 프로그램을 실행하고 자체 시스템 관리를 수행하는 동안 프로그램 파일과 데이터는 디스크에서 기본 메모리로 로드됩니다. 현재까지 Windows 7과 Windows 8 개발을 진행해 오면서 정상 작동 중에 메모리 조각(페이지)을 분석하고 이러한 조각이 참조된 빈도를 분석했습니다. 여기서 중요한 개념은 메모리 조각 할당에 대해 일종의 비용을 지불한다면 이 메모리 조각을 자주 사용(참조)하는 것이 좋다는 점입니다. 이 메모리가 필요하긴 하지만 자주 참조하지 않으면 다른 메모리와 합쳐집니다.

Windows 7을 출시한 후 곧바로, 초창기 NT 시절(1990년대 초기)까지 거슬러 올라가는 Windows의 하위 수준 구성 요소 몇 가지에 비슷한 기술을 적용했습니다. 이를 위해 코드 아키텍처를 재구성하는 한편, 메모리에서 자주 참조되는 '활성' 부분을 '비활성' 부분으로부터 완전히 분리하는 데이터 구조의 변화를 꾀했습니다. 활성 항목을 밀도 있게 통합함으로써 전체적인 런타임 메모리 사용량을 줄일 수 있었습니다.

하위 수준 OS라는 변화의 특성을 감안하여 변경에 따라 충분한 런타임을 확보하도록 최대한 빠른 시일 내에 작업을 마무리하려고 했습니다. 현재까지 이러한 변경은 거의 2년 동안 Windows 8에 적용되고 있으며 수천 명의 Microsoft 직원들이 이 제품을 사용하여 일일 업무를 처리하고 있습니다. 결과적으로 일반적인 시스템에서 메모리 사용량이 수십 메가바이트 줄어든 효과를 지속적으로 확인할 수 있습니다.

'데스크톱' vs. '메트로 스타일'

아시다시피 지난 6월, Steven과 Julie가 메트로 스타일 UI를 처음으로 소개했으며, 태블릿을 사용하는 많은 사람들이 이 환경에서 메트로 스타일 앱을 활발하게 사용할 것으로 기대하고 있습니다. 데모를 통해 Windows 8에서는 기존의 응용 프로그램을 아주 익숙한 데스크톱 환경에서 그대로 사용할 수 있다는 내용도 소개해 드렸습니다.

메모리 측면에서 볼 때 일부 장치 사용자들은 몰입감이 뛰어난 메트로 스타일 UI를 주로 사용할 것이라는 점에 착안했습니다. Windows 8에서 데스크톱 환경 고유의 OS 구성 요소는 필요할 경우에만 실행하게 될 것입니다. 이것만으로도 메모리 사용량이 23MB 정도 줄어드는 효과를 얻을 수 있습니다. 작업 관리자는 데스크톱에서 실행되므로 위에 표시한 메모리 수치에는 이 부분이 포함됩니다.

세부적인 메모리 할당 우선 순위 지정

Windows 8에서는 응용 프로그램과 시스템 구성 요소가 메모리 할당의 우선 순위를 더 체계적으로 지정합니다. 즉, Windows는 계속 유지해야 할 메모리와 조기에 회수해야 할 메모리를 보다 효율적으로 결정할 수 있습니다.

예를 들어, 다른 프로그램에 의해 바이러스 백신 프로그램(AV)이 열리면 파일에 대해 다양한 검사를 합니다. AV 프로그램이 바이러스 서명 확인을 위해 할당하는 메모리는 일반적으로 일회성이므로, 특정 메모리가 다시 필요하게 될 가능성은 적습니다. Windows 7에서는 시스템에서 특정 메모리의 우선 순위가 다른 메모리(예: Microsoft Excel의 실행 인스턴스에 의해 할당되는 메모리)와 동일한 것으로 취급됩니다. 메모리가 부족해지면 Windows 7은 Excel과 같이 실행 중인 다른 응용 프로그램의 메모리를 회수하게 되고 결국 이러한 응용 프로그램의 응답 속도가 떨어지게 됩니다. 이는 시스템 응답성을 고려할 때 최선의 선택이라 할 수 없습니다.

Windows 8에서는 어떤 프로그램이든 메모리를 '낮은 우선 순위'로 할당할 수 있습니다. 그러면 메모리가 부족할 경우 Windows에서 우선 순위가 낮은 메모리를 회수하여 가용 공간을 늘림으로써 시스템의 응답 속도를 유지하는 데 필요한 다른 메모리를 그대로 유지할 수 있습니다.

지금까지 Windows 8에서 메모리 사용을 줄이기 위한 접근 방식과 기본 원리를 소개했습니다. 몇 가지 샘플 결과도 보여 드렸으며 메모리에 관해 지금까지 수행된 엔지니어링 측면의 노력도 간단하게 알아보았습니다. 이 글에서는 Window 8의 응용 프로그램 모델과 새로운 Windows 8 앱을 더욱 '메모리 친화적'으로 만들어주는 프로세스 주기의 변화에 대해서 논의하지 않았습니다만, 이 부분도 Windows를 새롭게 상상하는 과정에서 매우 중요하므로 //build/ 컨퍼런스 콘텐츠와 향후 블로그에서 해당 내용을 참조하시기 바랍니다.

지금까지 해 온 것처럼 앞으로도 편리하고 효율적인 제품 개발을 위해 계속 노력하겠습니다.

- Bill Karagounis