요약:
Windows 11에는 오랫동안 사용자를 혼란스럽게 했던 설계가 있습니다. 64비트 시스템에서는 C:WindowsSystem32가 실제로 64비트 시스템 파일을 저장하는 반면 이름에 "64"가 포함된 C:WindowsSysWOW64 디렉터리는 32비트 파일을 대신 저장합니다. Windows의 역사를 모르는 사용자에게는 이 명명 체계가 완전히 반대인 것처럼 보일 수 있습니다.
Microsoft 엔지니어들은 최근 이 설계의 이유를 다시 설명했습니다. 대답은 Microsoft가 단순히 디렉토리 이름을 바꾼 것이 아니라 이전 경로에 의존하는 많은 소프트웨어를 손상시키지 않기 위한 것입니다. Windows는 32비트 아키텍처에서 64비트 아키텍처로 마이그레이션할 때 이미 널리 사용되는 System32 디렉터리 이름을 유지하기로 선택한 다음 파일 시스템 리디렉션 메커니즘을 사용하여 32비트 프로그램이 자동으로 다른 시스템 파일 집합에 액세스할 수 있도록 했습니다.
Windows 최신은 2026년 10월 20일에 이 문제를 소개하고 Microsoft의 공식 기술 문서와 관련하여 관련 메커니즘을 설명하는 기사를 게시했습니다. 보고서는 이 디자인이 소프트웨어 호환성에 대한 Windows의 장기적인 주장을 완전히 반영한다고 지적했습니다. 이전 명명 방법이 더 이상 직관적이지 않더라도 성급한 수정으로 인해 많은 프로그램이 실행되지 않을 수 있는 한 Microsoft는 원래 구조를 유지하고 호환성 레이어를 통해 문제를 해결하는 경향이 있습니다.
이 디자인을 이해하려면 Windows 초기로 돌아가야 합니다.
16비트 Windows 시대에는 시스템 파일이 주로 C:WindowsSystem 디렉터리에 저장되었습니다. Microsoft가 32비트 Windows를 출시했을 때 시스템에는 32비트 시스템 파일을 수용할 새 디렉터리가 필요했기 때문에 C:WindowsSystem32가 사용되었습니다. "32"는 실제로 당시 32비트 시스템 아키텍처와 관련이 있습니다.
그러나 64비트 Windows가 출시되자 상황은 복잡해졌습니다. 많은 소프트웨어가 System32를 프로그램 코드로 프로그래밍했으며 Windows에서 제공하는 시스템 인터페이스를 통해 올바른 시스템 디렉터리를 동적으로 얻는 대신 이 경로를 직접 사용하여 시스템 파일에 액세스합니다.
64비트 Windows를 시작할 때 Microsoft가 직접 System32의 이름을 System64로 바꾸는 경우 많은 기존 프로그램, 설치 프로그램 및 배치 스크립트가 필요한 시스템 파일을 찾지 못할 수 있습니다. 개발자가 소프트웨어를 다시 컴파일하더라도 하드 코딩된 모든 경로를 제때 수정하지 못할 수도 있습니다.
더 문제는 일부 소프트웨어가 64비트 버전으로 업그레이드한 후에도 기본적으로 System32에서 해당 시스템 구성 요소를 계속 읽는다는 것입니다. Microsoft가 System32를 32비트 파일만 저장하도록 변경하면 이러한 64비트 프로그램은 필요한 동적 링크 라이브러리를 정상적으로 로드할 수 없습니다.
따라서 Microsoft는 마침내 역사적 이름인 System32를 유지하고 64비트 Windows 운영 체제의 기본 아키텍처와 일치하는 파일을 저장하기로 결정했습니다. Windows 11의 메인스트림 x64 버전의 경우 이는 System32가 64비트 버전의 시스템 구성 요소를 저장하고 32비트 버전은 다른 디렉터리에 저장됨을 의미합니다.
이 디렉터리는 SysWOW64입니다.
WOW64는 "Windows 32-bit on Windows 64-bit"의 약어로, 64비트 Windows에서 32비트 Windows 애플리케이션을 실행하기 위한 호환성 메커니즘입니다. SysWOW64의 "64"는 파일 자체가 64비트라는 의미가 아니라 해당 시스템이 속한 64비트 Windows 환경을 의미합니다. 즉, 이름은 디렉터리에 있는 바이너리의 비트 수가 아니라 호환성 메커니즘이 대상으로 하는 플랫폼을 설명합니다.
Microsoft 수석 엔지니어인 Raymond Chen은 기술 기사에서 System32의 "32"가 일부 브랜드 이름과 마찬가지로 점차적으로 역사적인 레거시 이름이 되었다고 설명했습니다. 더 이상 원래 의미를 완전히 반영하지 못하더라도 장기간 사용으로 인해 여전히 유지될 것입니다.
전체 시스템을 재설계할 수 있다면 현재 시스템 아키텍처와 일치하는 실행 파일을 저장하는 데 사용되는 SysExec과 같은 디렉터리 이름이 더 이상적인 디렉터리 이름일 수 있다고 그는 생각합니다. 그러나 Windows는 수십 년 동안 존재해 왔으며 System32는 오랫동안 수많은 프로그램이 의존하는 고정 경로였으므로 이름 변경으로 인한 잠재적 위험이 이름 지정으로 인한 이점보다 훨씬 큽니다.
디렉터리 이름 지정 외에도 64비트 Windows는 보다 실용적인 문제도 해결해야 합니다. 32비트 프로그램은 64비트 동적 링크 라이브러리를 직접 로드할 수 없고, 64비트 프로그램은 32비트 동적 링크 라이브러리를 직접 로드할 수 없습니다.
예를 들어, kernel32.dll은 Windows의 중요한 시스템 구성 요소입니다. 동일한 이름의 파일은 System32와 SysWOW64에서 찾을 수 있지만 서로 다른 아키텍처용으로 컴파일되어 있어 간단히 교환할 수는 없습니다. Windows 최신에서는 Windows 11 26H2 시스템에서 이 두 디렉터리를 확인했을 때 해당 파일의 크기에도 차이가 있음을 발견했습니다.
32비트 프로그램이 System32에서 64비트 버전을 직접 로드하는 경우 호환되지 않는 바이너리 아키텍처로 인해 실행되지 않을 수 있습니다. 이러한 상황을 방지하기 위해 Windows에서는 WOW64 파일 시스템 리디렉터를 도입했습니다.
64비트 Windows에서 32비트 프로그램이 C:WindowsSystem32에 액세스하려고 하면 시스템은 일반적으로 액세스 요청을 C:WindowsSysWOW64로 자동 리디렉션합니다. 이 프로세스는 기본적으로 프로그램 자체에 투명하며 여전히 System32에 액세스하고 있다고 생각하며 운영 체제는 뒤에서 이에 대한 올바른 32비트 파일을 찾습니다.
Microsoft 공식 문서에는 64비트 Windows의 System32 디렉터리가 64비트 응용 프로그램용으로 예약되어 있으며 WOW64는 32비트 프로그램의 액세스를 일부 시스템 경로에 대한 해당 32비트 디렉터리로 리디렉션하는 역할을 담당한다고 명시되어 있습니다.
이 메커니즘은 시스템 동적 링크 라이브러리뿐만 아니라 일부 시스템 도구에도 영향을 미칩니다. 예를 들어, 32비트 프로그램이 Windows 디렉터리의 특정 도구에 액세스하면 SysWOW64의 해당 버전으로 리디렉션될 수 있습니다. 이렇게 하면 운영 체제 아키텍처가 일치하지 않는 경우 32비트 프로그램이 64비트 도구를 오용하거나 잘못된 작업을 수행하는 것을 방지할 수 있습니다.
WOW64는 레지스트리 액세스, 프로그램 설치 경로 등의 호환성 문제도 처리합니다. 32비트 애플리케이션의 경우 Windows는 별도의 레지스트리 보기를 제공할 수 있으며 일반적인 위치는 HKEY_LOCAL_MACHINESoftwareWow6432Node입니다. 또한 시스템은 일반적으로 32비트 프로그램의 Program Files 경로를 C:Program Files(x86)로 지정하므로 다양한 아키텍처의 소프트웨어를 최대한 별도로 관리할 수 있습니다.
이러한 메커니즘은 함께 Windows 호환성 시스템의 일부를 형성하여 개발자가 각 이전 프로그램에 대한 모든 코드를 다시 작성할 필요 없이 초기 32비트 Windows용으로 작성된 다수의 소프트웨어가 64비트 Windows 11에서 계속 실행될 수 있도록 합니다.
그러나 파일 시스템 리디렉션은 개발자를 쉽게 혼란스럽게 할 수 있는 상황을 초래할 수도 있습니다.
예를 들어 32비트 명령 프롬프트와 64비트 명령 프롬프트는 겉보기에 동일한 경로를 사용하여 C:WindowsSystem32kernel32.dll에 액세스하더라도 실제로 얻는 파일이 다를 수 있습니다. 전자는 일반적으로 SysWOW64로 리디렉션되고 후자는 System32에 직접 액세스합니다.
Microsoft Visual Studio 팀의 전 멤버인 Matt Pitrek은 기술 기사에서 32비트 명령 프롬프트가 두 디렉터리에 동일한 이름을 가진 파일을 나열할 때 혼란스러운 결과를 얻었기 때문에 문제를 해결하는 데에도 시간을 보냈다고 언급했습니다. 이는 파일 시스템 리디렉션이 소프트웨어 호환성을 유지할 수 있지만 시스템 디버깅 및 개발 작업을 더욱 복잡하게 만든다는 것을 보여줍니다.
일부 특별한 상황을 해결하기 위해 Microsoft는 Sysnative라는 가상 경로도 제공합니다. 32비트 프로그램이 실제로 64비트 Windows의 기본 System32 디렉터리에 액세스해야 하는 경우 C:WindowsSysnative를 사용하여 일반적인 파일 시스템 리디렉션을 우회할 수 있습니다.
Sysnative는 디스크의 실제 폴더가 아니라 Windows에서 특별히 제공하는 경로 별칭이라는 점에 유의해야 합니다. 64비트 응용 프로그램은 32비트 프로그램처럼 이 별칭을 사용할 수 없으므로 사용자가 파일 탐색기에서 직접 Sysnative를 검색하면 시스템에서 경로가 존재하지 않는다는 메시지를 표시할 수 있습니다.
Microsoft는 또한 다음을 포함하여 일반 파일 시스템 리디렉션의 영향을 받지 않는 여러 System32 하위 디렉터리를 나열합니다.
C:WindowsSystem32catroot
C:WindowsSystem32catroot2
C:WindowsSystem32driverstore
C:WindowsSystem32driversetc
C:WindowsSystem32로그 파일
C:WindowsSystem32spool
이러한 디렉터리에는 시스템 구성 요소 디렉터리, 드라이버 저장소, 네트워크 구성 파일, 로깅 및 인쇄와 같은 기능이 포함됩니다. Microsoft 설명서에는 이러한 예외 경로가 명확하게 나열되어 있지만 각 예외에 대한 특정 설계 이유에 대한 통일된 설명은 제공하지 않습니다. Windows 최신 버전에서는 이러한 디렉터리 중 일부에 드라이버 등의 호스트 파일과 같이 아키텍처가 다른 프로그램에서 공동으로 액세스해야 하는 데이터가 포함될 수 있다고 생각합니다.
x64 플랫폼 외에도 Arm 아키텍처에 대한 Windows의 호환성 메커니즘도 유사한 다중 디렉터리 디자인을 보여줍니다.
일부 초기 Windows on Arm 시스템에서 32비트 x86 프로그램은 SysWOW64를 사용하는 반면, 32비트 Arm 프로그램은 SysArm32를 통해 해당 시스템 구성 요소에 액세스할 수 있습니다. Arm 플랫폼은 다양한 명령어 세트 아키텍처 간의 호환성 문제를 처리해야 하므로 Windows도 해당 시뮬레이션 및 변환 메커니즘을 사용합니다.
그러나 Microsoft의 최신 Arm 개발 문서에는 Windows on Arm이 더 이상 32비트 Arm 애플리케이션을 지원하지 않으며 관련 시스템 바이너리도 SysArm32 디렉터리에서 제거될 것이라고 명시되어 있습니다. 동시에 일반 x86 응용 프로그램은 여전히 호환성 메커니즘을 통해 실행될 수 있으며 일부 x86 프로그램은 Prism 에뮬레이션 기술로 지원됩니다.
이는 또한 Windows 호환성 시스템이 완전히 정적이지 않음을 보여줍니다. 하드웨어 플랫폼과 소프트웨어 생태계가 변화함에 따라 Microsoft는 일부 오래된 아키텍처에 대한 지원을 단계적으로 중단할 예정이지만, 여전히 널리 사용되는 응용 프로그램에 대해서는 호환성을 최대한 유지하려고 노력할 것입니다.
기술적인 관점에서 보면 System32와 SysWOW64의 이름은 실제로 충분히 직관적이지 않습니다. 일반 사용자라면 "64"라고 보면 해당 디렉토리에 64비트 파일이 저장되어 있다고 생각하는 것이 당연합니다. 그러나 Windows에서 디렉터리 이름은 처음부터 직관을 따르도록 설계된 규칙 집합이 아니라 기록을 반영합니다.
Microsoft가 단순히 두 디렉터리의 이름을 바꾸지 않은 핵심 이유는 호환성이었습니다. Windows는 많은 기록 소프트웨어를 실행해야 하며 이러한 프로그램은 고정 경로, 레거시 시스템 인터페이스 및 특정 바이너리 파일 레이아웃에 의존할 수 있습니다. 이러한 인프라를 무분별하게 수정하면 소프트웨어 설치 오류, 시스템 도구 이상이 발생할 수 있으며 심지어 오래된 구성 요소에 의존하는 비즈니스 프로세스에도 영향을 미칠 수 있습니다.
따라서 Microsoft는 디렉터리 명명 시스템을 완전히 재구성하는 대신 파일 시스템 리디렉션, 레지스트리 리디렉션, 가상 경로 등의 메커니즘을 통해 문제를 해결하기로 결정했습니다.
이 디자인은 완벽하지는 않지만 Windows와 기타 운영 체제의 개발 경로에 있는 중요한 차이점을 반영합니다. 즉, Windows는 항상 지속적인 현대화와 수십 년 된 소프트웨어와의 호환성 사이에서 균형을 찾아야 합니다. System32와 SysWOW64의 겉보기에 반전된 이름은 이러한 장기적인 호환성 전략이 남긴 전형적인 흔적입니다.
댓글