The Desktop Files64비트 아키텍처

Wes Miller

지난 5년 전부터 Windows XP는 기본적으로 64비트 아키텍처에 사용할 수 있었습니다. Itanium용 Windows XP는 Windows XP와 동시에 출시되었는데, Intel Itanium 프로세서를 초기에 채택한 일부 사용자를 제외하고 대부분의 사용자는 x64 시스템에 Windows XP 및 Windows Server 2003 버전을 사용할 수 있다는 소식을 최근에 와서야 접할 수 있었을 것입니다.

업계에서 x86-64라고도 하는 x64는 AMD의 AMD64 아키텍처와 Intel의 EM64T를 가리키는 일반적인 이름입니다. 또한 작년 즈음에 PC를 새로 구입했다면 대개는 PC가 현재 32비트로 실행되더라도 64비트와 호환될 가능성이 높습니다.

현재 필자는 텍사스 주 오스틴의 작은 신생 회사에서 근무하고 있습니다. Microsoft® Exchange 2007 팀과 마찬가지로 저희 회사도 제품 중 하나의 아키텍처로 인해 x64 아키텍처가 지닌 매우 고유한 몇 가지 이점을 활용하는 데 관심을 가지게 되었으며, 이에 따라 x64 아키텍처 전용 제품 개발에 착수하여 이러한 제품을 제공하기 시작했습니다. 마찬가지로 필자가 관리하는 개발 및 테스트 팀의 개발 워크스테이션, 랩톱, 서버 및 프로덕션 서버에도 x64 버전의 Windows® XP와 Windows Server® 2003만 배포했습니다. 또한 제품을 테스트 및 디버깅하기 위해 필자의 개인용 랩톱에서도 Windows XP Professional x64 Edition을 실행하고 있습니다.

필자가 64비트 Windows를, 특히 모바일 시스템에서 실행한다고 말할 때 사람들의 첫 반응은 다소 당혹스러운 표정이었습니다. 64비트 컴퓨팅에 친숙한 사람들은 64비트 시스템에 맞는 장치 드라이버를 구하기가 매우 어렵다는 선입견 때문에 믿지 못하거나 부정적인 의견과 놀라움이 뒤섞인 반응을 보였습니다. 이번 달에 제공되는 본 칼럼을 통해 필자는 x64 시스템에서 64비트 모드로 Windows XP 및 Windows Server 2003을 사용하는 방법과 그 이유에 대해 설명하고 아울러 이를 통해 얻을 수 있는 배포상의 이점과 직면할 수 있는 난관에 대해 살펴보겠습니다. 또한 Windows Vista™ x64 지원, 마이그레이션 및 배포의 몇 가지 측면에 대해서도 알아보겠습니다.

간단한 역사

앞에서 설명했듯이 Windows의 64비트 지원은 Intel Itanium 프로세서를 지원할 때부터 시작되었습니다. 그 전에도 64비트 Alpha 프로세서에서 Windows를 사용하는 것이 가능하기는 했지만 실제로 Alpha에서 Windows가 64비트로 실행된 적은 없었습니다. Windows XP와 Windows Vista에서는 Itanium이 지원되지 않으므로 현재는 x64 아키텍처가 64비트 Windows 클라이언트 컴퓨팅을 지원하는 역할을 하고 있습니다. 현재는 Itanium에 비해 더 많은 버전의 Windows Server 2003을 x64에서 사용할 수 있게 되었는데 이는 근본적으로 최고급 데이터 센터 작업에 적합하며 이와 같은 추세는 다음 버전의 Windows Server(코드명 "Longhorn")에서도 계속될 것으로 보입니다.

x64 플랫폼에서의 Windows 지원은 Windows Server 2003 SP1(서비스 팩 1)이 제공되었을 때부터 가능해졌습니다. 다소 혼란스러울 수도 있지만 이때는 x64 버전의 Windows XP를 사용할 수 있게 되었을 때이기도 합니다. 즉, Windows XP 32비트 제품과 64비트 제품이 Windows 내의 서로 다른 코드 트리에서 파생되었습니다. Windows XP 32비트 제품의 경우 현재 두 번째 서비스 팩이 제공되고 있지만 64비트 버전의 경우에는 기술적으로 서비스 팩 수준이 하나도 없습니다. 또는 Windows Server 2003 SP1이 64비트 버전에 이미 통합되어 있는 것으로 볼 수도 있습니다.

Windows XP, Windows Server 2003, Windows Vista 또는 Windows Server "Longhorn" 등의 64비트 Windows를 실행하려는 경우 요구 사항은 모두 같습니다. 먼저 64비트 호환 프로세서가 있어야 합니다. AMD 프로세서를 사용하는 경우에는 AMD64 호환성을 갖춘 단일, 이중 또는 사중 코어 시스템이 있어야 합니다. 자세한 내용은 amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html을 참조하십시오. Intel 프로세서를 사용하는 경우에는 EM64T를 지원하거나 Intel 64 아키텍처를 갖춘 단일, 이중 또는 사중 코어 시스템이 있어야 합니다. 자세한 내용은 intel.com/technology/intel64를 참조하십시오. 이제 이러한 시스템을 찾는 어려움에 대해 자세히 설명하겠습니다. 예를 들어 Intel Core Duo 시스템은 64비트와 호환되지 않지만, Intel Core 2 Duo 시스템은 64비트와 호환됩니다. 이 시스템은 제 랩톱에서처럼 단순히 Centrino Duo라고도 합니다.

x64의 세계

시스템에서 기본적으로 64비트 버전의 Windows를 지원하는지 여부를 확인하고 나면 장치 지원 문제를 처리해야 합니다. Microsoft는 적어도 2년 동안의 WinHEC 세션에서 공급업체와 OEM에 자사 장치 및 시스템에 사용할 64비트 드라이버를 만들어 인증할 것을 권장해 온 만큼 Windows x64를 사용할 때 직면하게 되는 가장 큰 과제는 하드웨어 장치 또는 소프트웨어에 적합한 드라이버를 찾는 일일 것입니다. 필자의 경험에 비추어 봤을 때, 필요한 장치 지원이 제한되어 있고 x64를 통해 얻을 수 있는 이점이 가장 분명히 나타나는 서버에서 x64를 실행할 경우에 가장 성공적입니다.

데스크톱과 모바일 시스템용 드라이버를 찾는 것이 가장 어렵습니다. 일반적으로 주요 OEM 공급업체나 엔터프라이즈급 구성 요소에서 만들어진 시스템을 사용할 경우에는 비즈니스 용도로 공급업체나 OEM에서 x64 호환 드라이버를 만들고 서명했을 가능성이 높으므로 운이 좋다고 할 수 있습니다.

Windows Vista에서는 상황이 훨씬 낫습니다. 즉, x86 아키텍처가 선호되고 x64 아키텍처는 대부분의 하드웨어에 사용할 수 있는 드라이버가 제한된다는 점으로 인해 무시되는 현실과는 정반대의 상황이 Windows Vista에서 펼쳐집니다. Windows Vista의 경우에는 장치 공급업체가 호환성 테스트를 위해 반드시 x64 드라이버를 제출해야 합니다. 사실 x86 드라이버는 포함될 필요가 없지만 포함될 가능성은 있습니다. 개념적으로 보면 이는 일부 하드웨어, 특히 새로운 Windows Vista 기능을 이용하는 장치가 실제로 x64 Windows 지원만 제공하고 x86 지원은 제공하지 않을 수도 있음을 의미합니다.

사실 기본적으로 64비트 Windows를 실행하려고 할 때는 드라이버 문제만 나타나는데, 드라이버를 찾은 후나 마이그레이션할 때에 더 큰 문제가 시작됩니다. 이에 대해서는 나중에 설명하겠습니다.

왜 64비트인가?

AMD, Intel 및 Microsoft가 64비트 아키텍처로 전환한 데에는 그만한 이유가 있습니다. 64비트로 전환하면 몇 가지 중요한 이점을 얻을 수 있습니다. 그림 1에서 볼 수 있듯이 x64 아키텍처에서 가장 탁월하게 개선된 점은 처리할 수 있는 메모리의 양이 32비트 Windows의 4GB에 비해 최대 16TB로 크게 늘어났다는 점입니다. 단, 64비트 포인터는 최대 16TB의 메모리를 처리할 수는 있지만 응용 프로그램에서는 최대 8TB 가량의 메모리만 액세스할 수 있다는 점에 유의하십시오.

Figure 1 메모리 주소 공간 제한

주소 공간 64비트 Windows 32비트 Windows
가상 메모리 16TB 4GB
페이징 파일 512TB 16TB
페이징 풀 128GB 470MB
비페이징 풀 128GB 256MB
시스템 캐시 1TB 1GB

뿐만 아니라 x64 버전 Windows에서는 하드웨어 기반 DEP(데이터 실행 방지)를 제공하는데 이 기능은 NX(No eXecute)가 지원되는 x86 시스템에서도 사용할 수 있습니다. 이는 Windows에서 버퍼 오버플로를 방지하기 위해 활용하는 하드웨어 기반 솔루션을 가능하게 해 줍니다. 하드웨어 기반 DEP는 메모리의 데이터 페이지에서 코드가 실행되는 것을 방지합니다. 이에 대한 자세한 내용은 support.microsoft.com/kb/875352를 참조하십시오.

x64 버전 Windows에서는 x86 버전 Windows와 마찬가지로 다중 프로세서 또는 다중 코어 CPU가 기본적으로 지원됩니다. 그러나 설치된 모든 Windows x64에서 단일 HAL(하드웨어 추상화 계층)을 사용할 경우 Windows XP 시스템의 이미지를 만드는 데 따르는 가장 복잡한 문제 중 하나가 없어지므로 비 ACPI 또는 단일 CPU 시스템에서 사용 중인 HAL을 식별하기 위해 더 이상 고생할 필요가 없습니다.

기본적으로 Windows x64 아키텍처에서는 크게 향상된 메모리 액세스 기능을 사용하여 64비트 소프트웨어뿐 아니라 에뮬레이션을 통해 기존의 관리 인프라 및 기존의 32비트 소프트웨어도 사용할 수 있습니다. 사실 Windows x64로 전환하는 데 따르는 단점은 16비트 설치 관리자를 사용하는 32비트 응용 프로그램을 비롯하여 16비트 응용 프로그램에 대한 지원이 전무하다는 점, 프로세스 단위로 DEP를 해제할 수도 있고 Windows 응용 프로그램 호환성 팀에서 DEP가 설정된 상태에서 올바르게 실행되지 않는 일부 응용 프로그램을 보완하고 있기도 하지만 하드웨어 DEP가 설정되어 있을 경우 응용 프로그램이 안정적으로 실행되지 않는다는 점, 마지막으로 64비트 Windows Vista에서는 모든 드라이버가 디지털 서명되어야 한다는 점뿐입니다.

마지막에 언급한 드라이버의 디지털 서명은 rootkit에서 흔히 사용하는 기술인 메모리의 Windows 커널 훼손을 방지하기 위해 추가된 것입니다. 그런데 x64는 Microsoft에서 Windows 하드웨어 품질 테스트를 통해 최적의 드라이버를 얻을 수 있도록 공급업체에 최우선으로 드라이버를 개발하도록 권장하고 있는 아키텍처이므로 이러한 요구 사항이 과거와 같이 만족하기 힘든 요구 사항은 아닙니다.

x64 시스템용 Windows를 고려할 때 유의해야 할 몇 가지 사항이 또 있습니다. x64 시스템용 Windows XP 버전에는 Windows Media® Center Edition 또는 Windows Tablet PC Edition에 포함된 기능이 포함되어 있지 않습니다. 그러나 Windows Vista에서는 이 문제가 해결되어 x64 버전과 x86 버전에서 기능이 동일합니다.

가상화

한 가지 언급하지 않은 것이 있는데 바로 가상화입니다. 여기서 말하는 가상화는 Microsoft Virtual PC나 VMWare PC 가상화 제품과 관련된 것이 아니라 32비트 실행 파일을 위한 운영 체제 가상화를 의미합니다. 32비트 버전 Windows에서는 모든 16비트 응용 프로그램이 Virtual MS-DOS® Machine인 NTVDM의 컨텍스트 내에서 실행됩니다. 앞에서도 설명했듯이 64비트 버전 Windows에서는 16비트 응용 프로그램이 전혀 지원되지 않습니다. 대신 대부분의 Windows 통합 구성 요소가 기본적으로 64비트 바이너리로 실행되고 일부 구성 요소와 대부분의 타사 프로그램은 32비트 응용 프로그램으로 실행됩니다.

64비트 Windows에서는 이러한 32비트 응용 프로그램이 운영 체제를 다르게 인식하여 사실상 32비트 버전의 Windows에서 실행되도록 하는 WOW(Windows On Windows)라는 완전히 새로운 에뮬레이션 계층을 제공합니다. WOW에서는 x86 응용 프로그램이 Program Files(X86)를 단순히 Program Files로 인식합니다. 마찬가지로 x86 응용 프로그램에서는 %WINDIR%\SysWOW64가 %WINDIR%\System32로 나타나고 레지스트리 키 HKLM\SOFTWARE\Wow6432Node는 HKLM\SOFTWARE 노드로 나타납니다.

Process Explorer 도구를 사용하면 가상화의 다른 측면을 자세히 살펴볼 수 있습니다. 대부분의 32비트 응용 프로그램은 통합 32비트 Windows 바이너리와 상호 작용할 것으로 예상되므로 이러한 바이너리의 대부분이 64비트 및 32비트 버전 모두로 제공됩니다. Process Explorer에 열을 하나 추가하면 이를 쉽게 확인할 수 있습니다. 그림 2에서는 cmd.exe의 32비트와 64비트 버전 인스턴스를 보여 줍니다. 그림에서 강조 표시된 32비트 인스턴스를 보면 프로세스에 여러 개의 wow64* DLL이 로드되었음을 알 수 있습니다. 이는 32비트 응용 프로그램이 64비트 Windows에서 작동할 수 있도록 가상화가 일어나고 있음을 보여 줍니다. cmd.exe의 64비트 및 32비트 버전에서 사용 중인 작업 디렉터리, 즉 Path(경로)도 눈 여겨 보십시오.

그림 2 Process Explorer에 표시된 32비트 및 64비트 버전 cmd.exe

그림 2** Process Explorer에 표시된 32비트 및 64비트 버전 cmd.exe **(더 크게 보려면 이미지를 클릭하십시오.)

가상화와 관련해서 주목해야 할 사항이 한 가지 더 있습니다. Windows에서는 explorer.exe가 기본 64비트 응용 프로그램으로 실행되는데 여기에는 몇 가지 장점과 단점이 있습니다. 가장 큰 단점은 Explorer 셸 확장은 제대로 작동하기 위해 x64용으로 다시 컴파일되어야 하는데 대부분은 다시 컴파일되지 않았다는 것입니다.

Internet Explorer®는 그 반대로 기본적으로 32비트 버전에서 실행되는데, 이는 현재 인터넷에서 사용되고 있는 많은 ActiveX® 컨트롤이 현재 상태 그대로 올바르게 작동하도록 하기 위한 것입니다. 그렇지 않으면 64비트 응용 프로그램에서는 처리 중 32비트 DLL이나 드라이버를 로드할 수 없으므로 현재 사용되는 ActiveX 컨트롤의 거의 대부분을 차지하는 32비트 ActiveX 컨트롤을 64비트 브라우저에서 로드할 수 없게 되며 그 결과 상당량의 인터넷 콘텐츠에 액세스할 수 없게 됩니다. 이에 대한 예를 들어 보도록 하겠습니다. 64비트 Windows 시스템에서 C:\Program Files\Internet Explorer\iexplore.exe를 로드한 다음 Windows Update를 비롯하여 ActiveX 컨트롤 콘텐츠를 로드하는 아무 사이트나 방문해 보십시오. 정도의 차이는 있지만 ActiveX 컨트롤이 제대로 실행되지 않을 것입니다. 현재는 이와 같은 상황에서 32비트 Internet Explorer 인스턴스를 열도록 Windows Update가 업데이트되었습니다(그림 3 참조). 앞으로 64비트 Internet Explorer를 사용하도록 일부 ActiveX 컨트롤 콘텐츠가 업데이트될 예정입니다. 그러나 현재 32비트 Windows만 실행하는 대부분의 Windows 시스템의 경우에는 ActiveX 컨트롤 콘텐츠의 업데이트가 크게 필요하지 않으며 이러한 추세는 당분간 계속될 것으로 예상됩니다.

그림 3 64비트 Internet Explorer에서 실행되지 않는 32비트 ActiveX 컨트롤

그림 3** 64비트 Internet Explorer에서 실행되지 않는 32비트 ActiveX 컨트롤 **(더 크게 보려면 이미지를 클릭하십시오.)

Pluck의 x64 Windows

이 문서의 앞 부분에서 언급했듯이 Pluck에서는 x64 Windows로의 전환을 이미 시작했으며 Windows의 세 가지 버전, 즉 Windows XP Professional x64 Edition, Windows Server 2003 Enterprise Edition x64 및 Windows Vista x64를 사용했습니다.

Pluck의 경우 회사 규모가 그다지 크지 않아서 최신 제품을 개발하기 시작했을 때 x64의 장점을 활용하기 위해 x64용 Windows로의 마이그레이션을 비교적 수월하게 시작할 수 있었습니다. 마이그레이션한다는 것은 새로 주문하는 모든 하드웨어가 x64와 호환되어야 함을 의미했습니다. 사실 현재와 같은 방식으로 제품을 실행할 수 있게 해 준 것은 바로 x64의 확장된 메모리 기능과 가상화였습니다. Pluck의 모든 실제 서버는 64비트 호스트 서버에서 64비트 가상 서버로 실행됩니다. 각 호스트 서버에는 16GB의 RAM이 있으며 이 RAM은 서버에서 호스팅되는 가상 서버들 간에 고르게 나뉘어 사용됩니다. 일반적으로 준비 단계의 VM(가상 컴퓨터)에는 2GB의 RAM이, 각 프로덕션 VM에는 3GB의 RAM이 각각 할당됩니다.

계층 1 시스템과 가상화된 하드웨어를 함께 사용함으로써 장치를 거의 완벽하게 지원할 수 있게 되었습니다. 예를 들어 필자의 랩톱에는 사용 가능한 x64 드라이버가 없는 장치가 세 개 있습니다. 이들은 모두 중요하지 않은 백플레인 유형의 장치로 나타나며 없어도 시스템이 문제 없이 작동합니다. 흥미롭게도 Windows Vista RC1 x64를 설치한 결과 장치 지원이 정확히 동일했습니다. 단, 필자의 시스템에서는 Windows Vista Capable 로고가 표시되기는 했지만 현재 없는 드라이버도 조만간 공급업체로부터 제공될 것입니다.

사용하는 시스템이 주로 Microsoft Office, Visual Studio®, 그리고 개발 및 빌드 프로세스에서 사용되는 몇 가지 추가 도구로 제한되므로 마이그레이션 중 호환성 문제를 야기할 만한 레거시 응용 프로그램이 많지 않았습니다. 회사의 극히 일부에서만 32비트 버전 Windows를 사용했으므로 새로운 하드웨어를 사용하여 64비트로의 마이그레이션을 시작할 수 있었으며 작업이 비교적 수월했습니다.

x64 배포 및 마이그레이션

배포와 관련하여 몇 가지 고려해야 할 사항이 있습니다. Microsoft는 x64 아키텍처 전용의 Windows PE(Pre-installation Environment) 버전을 제공합니다. 그러나 x64 시스템에 x86 패리티가 있으므로 특히 이미징 솔루션을 사용하는 경우에는 x86 Windows PE를 사용하여 배포하기를 원할 수 있습니다. 무인 설치로 Windows XP를 배포하려는 경우에는 아키텍처별로 Windows PE를 준비해야 하는데 이는 winnt32.exe가 배포되는 것과 동일한 아키텍처에서 실행되어야 하기 때문입니다. Windows PE에는 32비트 호환성 계층이 없으며 x64에서는 winnt32.exe가 64비트 응용 프로그램이므로 32비트 Windows의 경우 32비트 Windows PE가 필요합니다. 이는 64비트 버전 Windows에도 동일하게 적용되어 64비트 버전 Windows에는 64비트 Windows PE가 필요합니다.

RIS(원격 설치 서비스)의 경우는 사정이 다르므로 이 때문에 Pluck에서는 RIS를 사용했습니다. Windows Server 2003 SP1부터는 RIS로 x64 및 x86 또는 Itanium 아키텍처에 Windows를 배포할 수 있습니다. x64 시스템이 RIS 서버에 연결되면 서버가 기본 구성일 경우 x86 및 x64 RISetup 또는 RIPrep 이미지를 제공합니다. x64 클라이언트에 x86 이미지만 또는 x64 이미지만 제공하도록 RIS를 구성할 수도 있습니다. 이 옵션은 x64 하드웨어에 최상의 경험을 제공하기 위해 기본적으로 제공됩니다.

아직 업그레이드에 대해서는 설명하지 않았는데 여기에는 나름의 이유가 있습니다. 안타깝게도 전체 OS를 x86에서 x64로 업그레이드하는 것은 어마어마한 작업입니다. 이러한 이유와 Windows XP Pro x64 Edition이라는 제한된 배포 환경으로 인해 x86 버전에서 Windows XP x64로 업그레이드할 수 없으며 x86이든 x64든 어떤 버전의 Windows XP에서도 Windows Vista x64로 업그레이드할 수 없습니다. x64 시스템의 Windows Vista는 Windows XP Pro x64 Edition과 마찬가지로 새로 설치만 가능한 제품입니다. 이러한 이유로 대부분의 조직에서는 하드웨어 교체 시기가 다가올 때에만 x64로의 마이그레이션을 고려합니다. 이는 대부분의 조직에서 일거양득의 효과를 얻기 위해 Windows Vista에서도 채택할 것으로 예상되는 전략입니다.

그러나 이것이 x86 Windows에서 x64 Windows로 전환하는 조직이나 사용자가 손쉽게 사용할 수 있는 도구가 없다는 의미는 아닙니다. 도구는 분명히 있습니다. Windows XP 및 Windows Vista용 USMT(사용자 상태 마이그레이션 도구) 버전은 모두 한 버전의 Windows에서 다른 버전으로의 마이그레이션을 지원할 수 있도록 확장되었습니다. 이때의 마이그레이션은 같은 OS 내 업그레이드와는 상반되는 개념입니다. USMT는 동일한 PC에서 Windows를 제거하고 다시 로드하든지에 관계없이 대부분의 조직에서 Windows를 배포하는 데 가장 많이 사용하는 방법이므로 동일한 메커니즘을 사용하여 완전히 새로운 아키텍처의 Windows로 전환하는 것이 이전보다 상당히 수월해졌습니다.

결론

Pluck과 같은 소규모 조직에서 x64로 점진적으로 마이그레이션하는 것은 대규모 조직의 광범위한 마이그레이션 프로세스보다 훨씬 간단해 보일 수 있습니다. 그러나 아무리 어렵다고 해도 IT 전문가라면 누구든지 결국 x64 아키텍처로 전환하는 것에 대해 고려해야 할 것입니다. 향후 10년간은 x86 아키텍처와 x86 기본 버전 Windows가 계속 사용되겠지만 그 이후에는 x64 아키텍처가 엔터프라이즈 컴퓨팅의 대세를 이룰 것입니다. Microsoft는 Exchange Server 및 이외 다른 제품을 통해 완전히 x64 기능으로 전환하고 있습니다. 이제 여러분도 x64 시스템이 사용 중인 아키텍처에 적합한지, Windows Vista 마이그레이션 계획에서 x64 시스템으로의 전환이 의미가 있는지, 그리고 현재 x64 시스템에서 기본적으로 Windows XP 또는 Windows Server 2003을 활용하고 있는지 등을 파악하기 위해 노력을 기울여야 할 것입니다.

Wes Miller는 텍사스 주 오스틴에 있는 Pluck(www.pluck.com)의 개발 관리자입니다. 이전에는 Winternals Software와 Microsoft에서 Windows 프로그램 관리자 겸 제품 관리자로 근무했습니다. 문의 사항이 있으면 technet@getwired.com으로 연락하시면 됩니다.

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