# Windows Server 2025는 ARM에서 더 잘 실행됨 > Clean Markdown view of GeekNews topic #28782. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28782](https://news.hada.io/topic?id=28782) - GeekNews Markdown: [https://news.hada.io/topic/28782.md](https://news.hada.io/topic/28782.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-22T23:01:58+09:00 - Updated: 2026-04-22T23:01:58+09:00 - Original source: [jasoneckert.github.io](https://jasoneckert.github.io/myblog/server-2025-arm64/) - Points: 1 - Comments: 1 ## Topic Body - 가상화된 **Windows Server 2025** 비교에서 ARM64 호스트 위 ARM64 게스트 구성이 안정적으로 동작했고, 서비스 시작과 관리 콘솔 실행, 실습 작업 처리에서도 더 빠른 체감 반응 확인 - 두 VM은 **메모리·가상 프로세서·역할 구성**을 동일하게 맞췄고, 측정에서는 Snapdragon 시스템이 CPU 사용률 변동 폭이 작고 `Processor Queue Length` 0 유지와 **CPU Wait Time Per Dispatch**의 일관된 값 기록 - IIS, DNS, Active Directory 조회, 도메인 인증, 파일 I/O 반복 측정에서도 **Snapdragon X Elite**가 거의 매번 재현 가능한 시간값을 보였고, Intel은 일부 실행에서 더 빨랐지만 전반적으로 편차가 더 큼 - 차이를 CPU 아키텍처 하나로 단정하지 않았으며, 저장장치·메모리·전력 관리·발열 특성과 함께 **지연 시간의 일관성**과 예측 가능한 스케줄링이 가상화된 서버 부하에 더 중요하게 작용 - 최대 처리량 중심 워크로드에서는 x64 장점이 남아 있지만, **소규모 지연 민감 작업**이 많은 전형적 Windows Server 배포에서는 ARM64 매력 확대, 다만 교육용 표준 플랫폼은 ARM64의 중첩 가상화 미지원으로 x64 유지 --- ### 테스트 환경과 비교 기준 - **Windows Server 2025** 가상 환경을 두 시스템에 각각 구축해 비교 진행 - Windows 11 기반 **14세대 Intel Core i9** 시스템에서 Hyper-V 가상 머신 다수 운영 - Windows 11 on ARM 기반 **Snapdragon X Elite** 시스템에도 동일한 Windows Server 2025 환경 구성 - Microsoft 웹사이트에서 **Windows Server 2025 ARM** 공식 설치 ISO를 제공하지 않아, **UUP dump**로 Microsoft 업데이트 서버 기반 이미지를 생성해 설치 - 두 Hyper-V VM은 **메모리**, **가상 프로세서**, **설치 역할**을 동일하게 맞춘 구성 - Snapdragon X Elite는 **ARM64 guest on ARM64 host** - Intel Core i9는 **x64 guest on x64 host** ### 초기 관찰과 해석 범위 - ARM 시스템의 Windows Server 2025 환경이 **안정적**이고 **정상 동작**했으며, **실사용 가능** 수준으로 체감상 전반적인 속도도 더 빠름 - 서비스 시작 속도 향상 - 관리 콘솔 실행 속도 향상 - 교재 집필용 실습 작업 수행 시간 단축 - 다만 성능 차이를 **CPU 아키텍처 하나만의 결과**로 단정하지 않음 - 저장장치, 메모리, 전력 관리, 발열 특성도 결과에 영향 가능 - “ARM이 더 빠르다”는 단정 대신 **전체 시스템 특성** 기준 해석 필요 - Windows Server의 일반적 서비스 부하는 **스레드 비중이 높고**, **작지만 빈번한 CPU 및 I/O 작업** 중심 특징 - Active Directory, DNS, DHCP, IIS, SMB/NFS/DFS 파일 서비스, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS 등 포함 - 이런 유형은 **지연 시간**과 **문맥 전환**에 민감하며, 지속적으로 일관된 성능의 이점 존재 ### 성능 차이에 대한 관찰 - Snapdragon 계열 ARM 시스템은 **높은 부스트 클록 추구보다 지속적이고 안정적인 성능** 제공 경향 - 최신 Intel CPU는 **주파수 가속과 동적 스로틀링** 특성으로 높은 최대 성능 제공 가능 - 대신 지속 부하나 혼합 부하에서는 스케줄링과 지연 시간의 변동성 증가 가능 - 가상화 환경에서는 이런 변동성이 더 중요하게 작용 - **Hyper-V** 같은 하이퍼바이저는 사실상 하드웨어 스케줄러 역할 수행 - 하드웨어 실행 타이밍이 더 예측 가능할수록 하이퍼바이저 스케줄링도 더 일관된 결과로 이어짐 - 그 효과가 VM과 VM 내부 서비스 응답성에 반영됨 - **Windows Server ARM64 빌드** 자체 차이 가능성도 언급됨 - 온라인에서 확인한 여러 릴리스 노트 기준, ARM64 버전은 일부 **레거시 호환 계층**을 피하고 더 현대적이고 최적화된 바이너리 사용 가능성 존재 - x64 버전보다 더 **정리된 빌드**일 수 있다는 관찰 포함 - 구체적 내부 구현 근거는 추가로 제시되지 않음 ### Performance Monitor 측정 - 두 Windows 11 호스트에서 **Performance Monitor** 카운터를 추가해 측정 진행 - `\Processor(_Total)\% Processor Time` - 전체 코어 기준 **CPU 사용률** - `\System\Processor Queue Length` - CPU 시간을 기다리는 스레드 수 - 최적이라면 **0 유지**가 바람직함 - `\Hyper-V Hypervisor Virtual Processor(*)\CPU Wait Time Per Dispatch` - 가상 프로세서가 CPU에 스케줄되기까지 기다리는 평균 시간 - 각 VM 내부 PowerShell에서 부하를 생성한 뒤 결과 관찰 - `Get-Process` 결과를 CPU 사용량 기준 정렬하고 상위 5개를 반복 조회하는 무한 루프를 8개 실행 - 측정 결과에서 Snapdragon은 **지속적이고 안정적인 성능 패턴** 확인 - `% Processor Time` 변동 폭이 훨씬 작음 - `Processor Queue Length`가 0 유지 - `CPU Wait Time Per Dispatch`도 평탄하고 일관된 값 유지 - Intel 시스템은 **부스트/스로틀 변동성**이 지표에 반영됨 - `% Processor Time` 변동 폭이 더 큼 - `Processor Queue Length`가 주기적으로 급증 - `CPU Wait Time Per Dispatch`도 유의미한 변동 발생 ### 서비스 응답성 측정 - 각 VM의 PowerShell에서 **Measure-Command**를 사용해 일반적 서비스 작업 시간을 측정 - IIS 웹 서버 대상 테스트 수행 - `Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null`를 1000회 반복 - 같은 방식으로 다른 서비스도 반복 측정 - DNS - `Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null` - Active Directory 조회 - `Get-ADUser -Filter * -ResultSetSize 1 | Out-Null` - 도메인 인증 지연 - `Test-ComputerSecureChannel -Verbose:$false` - 파일 I/O - `C:\TestFiles` 디렉터리 생성 - 2000회 반복하며 파일 생성, 내용 기록, 읽기, 삭제 수행 - 여러 차례 반복 실행한 결과, Snapdragon 시스템은 **일관되고 재현 가능한 시간값**을 거의 매번 기록 - Intel 시스템은 결과 편차가 더 큼 - 일부 실행에서는 Snapdragon보다 더 빠를 때도 있음 - 그러나 대부분의 경우 뒤처짐 - 전체적으로는 **모든 테스트에서 Snapdragon 우세**라는 결론 ### 핵심 결론 - 여러 결과를 관통하는 공통 요소는 **지연 시간의 일관성** - 가상화된 Windows Server 부하는 **작고 빈번한 작업에 대한 빠른 응답**과 **예측 가능한 스케줄링**의 중요성 큼 - **최대 처리량**이 중요한 워크로드에서는 x64 시스템이 여전히 분명한 장점 보유 - 반대로 전형적인 Windows Server 배포처럼 **많은 소규모 지연 민감 작업**이 가상화 아래에서 함께 실행되는 환경에서는 **순수 최고 속도보다 일관성**이 더 중요함 - 그런 맥락에서 **ARM64의 매력** 확대 - ARM64는 이미 클라우드 환경에서 널리 사용 중이며, **성능 대비 비용 비율**이 x64보다 더 좋다는 언급 포함 - Microsoft가 Windows Server의 미래에서 **ARM64 비중 확대**를 검토할 필요 제기 - 현재 Microsoft는 **Windows Server on ARM64**를 완전 지원하지 않음 - 그러나 지난 해 신규 **Microsoft Azure VM 인스턴스의 33%** 가 ARM64였고, **Amazon AWS는 50%** 가 ARM64였다는 수치 제시 ### 교육용 표준 플랫폼 선택 - 교재용 실습 환경은 여전히 **x64 표준화** 유지 - 이유는 실습 구성에 **중첩 가상화**가 포함되기 때문 - Hyper-V의 **ARM64에서 중첩 가상화 미지원**으로 인해 ARM64는 현재 교육용 기본 환경으로 채택되지 않음 - 학생이 실습을 우회 구성하는 것은 가능하나, 교재 목표 중 하나가 **재현성**이므로 단계별로 동일하게 동작하는 환경 우선 - 현재 시점에서는 교육 목적상 **x64가 실용적 선택지**로 유지 ## Comments ### Comment 56085 - Author: neo - Created: 2026-04-22T23:01:59+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47821801) - 테스트 재현에 필요한 설정, 추측, 코드까지는 다 공개했는데 **체감 결과값** 자체가 빠져 있어서 조금 의심스러웠음. ARM이 실제로 얼마나 빠른지 수치가 궁금했음 - 출력 스크린샷을 일부러 뺐던 이유가 있었음. **벤치마크 글**로 흐리는 걸 피하고 싶었고, ARM 하드웨어나 Snapdragon X Elite 세부 모델에 따라 결과가 달라져 오해를 부를 수 있다고 봤음. 대신 누구나 재현할 수 있게 PowerShell 스니펫을 넣었음. 대략적인 결과는 Snapdragon VM이 Intel VM보다 테스트별로 약 20~80% 빨랐고, DNS는 약 20%, IIS는 약 50%, 나머지는 대체로 80%에 가까웠음 - Windows 개발자 관점에서 보면 이건 **segment heap** 영향일 가능성이 커 보였음. Windows 힙 구현에는 오래된 NT heap과 2010년대의 segment heap이라는 서로 독립적인 두 계열이 있고, segment heap이 메모리 단편화와 작은 할당 재사용 면에서 더 효율적이었음. 다만 Windows는 레거시 호환성을 극도로 중시해서, 오래된 앱들이 use-after-free 같은 위험한 동작이나 내부 NT heap 구조체에 의존할 수 있었기 때문에 기본값을 일괄 전환하지 않았음. 그래서 packaged 실행 파일에는 segment heap을 기본 적용하고, unpackaged 쪽은 그대로 두는 절충을 택했음. 그런데 UWP 전환이 실패하면서 Windows 생태계는 더 쪼개졌고, 중요한 소프트웨어 대부분은 여전히 unpackaged x64로 남았음. 반면 arm64 바이너리는 오래된 레거시 코드일 가능성이 낮아서 arm에서는 segment heap이 기본 활성화됨. 사용자가 arm Windows가 더 반응성 좋다고 느끼는 이유 중 적지 않은 부분이 여기에 있다고 봄. x64에서 segment heap을 강제로 켜고 이 테스트를 다시 해보면 흥미로울 것 같았음. 실행 파일별로는 `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe` 아래 `FrontEndHeapDebugOptions` DWORD를 8로 주면 되고, 전역으로는 `HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap` 아래 `Enabled` DWORD를 3으로 주면 됨. 내 개발 머신에서는 전역 활성화 후 문제를 못 봤고, 메모리 사용량은 테스트 기준 약 15% 절감됐음 - 내 **RAM/CPU 집약 워크로드**에서는 NT Heap 대비 Segment Heap으로 전체 성능이 안정적으로 약 7% 좋아졌음. 합쳐진 작업이 7% 더 빨리 끝났음. 예전의 "Compatible with Windows XXX" 같은 인증이 Windows 10/11에도 있었다면, 여기에 segment heap 체크 항목을 넣어 더 많은 앱과 사용자에게 성능, 전력 효율, 친환경성 이점을 줄 수 있었을 것 같음. 그리고 UWP의 문제는 기술 자체보다 패키징과 Store 결합을 고집한 점이었고, 그건 Windows라는 OS의 존재 방식과 충돌했다고 봤음 - 관심 있는 사람이라면 자기 실행 파일의 **application manifest**에서 `heapType`을 `SegmentHeap`으로 설정해 이 동작을 opt-in할 수 있음. [문서](https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests)에 설명이 있음 - 이런 식의 **실전 팁**이야말로 HN의 가치라고 느낌. 전역 레지스트리 키는 재부팅이 필요한지, 아니면 실행 파일 시작 시점부터 바로 적용되는지가 궁금했음 - 이 내용은 포럼 댓글보다 **블로그 글**로 남아야 할 수준으로 흥미로웠음 - 예전에 이 전역 설정은 0 대 non-zero로 설명된 걸 봤는데, 값이 왜 하필 **3**인지 궁금했음. 2는 어떤 의미인지, 이런 값들의 뜻을 스스로 어디서 확인할 수 있는지도 알고 싶었음 - 글의 "ARM은 높은 boost clock을 쫓지 않고 꾸준한 성능을 낸다"는 표현은 조금 과장처럼 느껴졌음. 내가 써본 ARM 시스템도 전부 **주파수 스케일링**을 했고, 그 점에서는 x86과 비슷하게 동작했음. 결국 차이는 얼마나 높이 올라가느냐 정도로 보였음 - 워크로드 의존성은 있겠지만, 내가 일한 여러 조직의 클라우드 환경에서는 x86에서 **ARM 전환**만으로도 비용 절감 효과가 꽤 컸음. 인스턴스 가격이 더 낮은 데다 효율도 더 좋았기 때문임. 특히 한 조직에서는 수백 개의 Kubernetes 노드를 동적 오토스케일링하는 환경에서 추가 변경 없이 x86 -> ARM만으로 보수적으로도 약 15% 절감 효과를 예상했고 실제로 달성했음. CPU 바운드이면서 x86 특화 기능에 덜 묶인 워크로드라면 15%보다 훨씬 더 클 수도 있다고 봤음 - ARM CPU의 덜 흔들리고 더 예측 가능한 성능이 핵심이었다면, 데스크톱 CPU 대신 **Epyc 같은 서버 CPU**를 써도 비슷한 이점을 볼 수 있다고 생각했음. 서버 CPU는 클럭 변동 폭이 더 작고 boost 정책도 덜 공격적이기 때문임. 심지어 지금 있는 데스크톱 하드웨어에서도 BIOS에서 Turbo를 꺼서 Intel CPU를 기본 클럭으로 고정하면, 낮더라도 안정적이고 예측 가능한 성능을 만들어 비교해볼 수 있다고 봤음 - 전원 관리 계획에서도 **turbo 동작**을 끌 수 있었음. 다만 그 설정이 GUI에 기본으로 보이지 않을 수도 있었음 - Windows on ARM이 **VBS**나 Virtualization Based Security를 쓰는지, 그리고 VM 안에서도 nested virtualization으로 그걸 지원하는지가 궁금했음. 또 CPU 취약점 완화가 VM에서 이중으로 걸려 성능에 영향을 주는지 여부도 중요해 보였음. 요즘 Windows를 VM에 넣었을 때 흔히 보는 성능 문제 상당수가 여기서 오기 때문임. 그런데 글에서는 이 부분을 언급하지 않아 아쉬웠음 - 두 시스템의 RAM과 스토리지 구성이 궁금했음. Snapdragon 쪽이 **패키지드 RAM**이라 인터커넥트가 더 빠를 수도 있고, x86 쪽은 DIMM이라 트레이스가 더 길 수도 있다고 봤음. 스토리지나 CPU 모델도 성능 차이를 크게 좌우할 수 있음. 벤치마크는 시스템 한 부분만 과하게 자극하는 경우가 많아서, 진짜 차이가 ARM 아키텍처 자체보다 RAM, syscall, SSD 같은 다른 요소에서 오는 것일 수도 있다고 생각했음 - 두 시스템 모두 메인보드에 납땜된 **DDR5**와 NVMe SSD를 사용했음. 오히려 Intel 쪽 SSD가 Snapdragon 쪽 Foresee보다 더 빠른 Samsung 모델이었음 - Linux에서는 전부 더 잘 돌아가고, **감시 오버헤드**로 사이클을 낭비하지 않는다고 느꼈음 - 글이 Intel 프로세서가 뭔지 일부러 말을 피하는 것처럼 보여서, 내가 뭘 놓친 건지 궁금했음 - 사용한 CPU는 **14th Gen Intel Core i9**였음 - HV 서버에서는 보통 **C States 비활성화**, 전원 관리 high 설정 같은 방식으로 x86이 다운클럭하지 않게 막는 편임. CPU가 위아래로 흔들리지 않게 하면 성능이 크게 좋아질 수 있음. 다만 이런 건 보통 개인용이나 실험실 장비에서는 잘 하지 않음 - 아니면 그냥 **turbo boost 비활성화**만 해도 됨 - 글을 읽고 나니 핵심은 두 가지로 보였음. 첫째, ARM64는 x64보다 덜 "똑똑"해서, Core i9처럼 공격적으로 부스트와 스로틀링을 반복하기보다 **일정한 성능**을 내고, 그 덕분에 OS 스케줄링이 쉬워진다는 점임. 둘째, Windows가 ARM에서는 x64보다 역사적 짐이 덜해서 ARM 빌드 자체가 더 효율적일 가능성도 있어 보였음. 결국 CPU 스로틀링이 너무 영리해져서 오히려 해가 되는 지점에 온 건지 궁금했음 - 다만 이건 **서버 OS**를 데스크톱 x86 CPU에서 테스트한 사례라는 점을 같이 봐야 했음. AMD Epyc나 Intel Xeon 같은 x86 서버 CPU는 클럭 변동 범위가 더 작고 정책도 덜 공격적이라, 데스크톱 CPU보다 더 일정하고 예측 가능한 성능을 냄. 이런 특성은 멀티스레드 워크로드에 유리하고, 데스크톱 CPU는 단일 스레드 최고 성능을 위해 조정되다 보니 멀티스레드에는 오히려 손해가 날 수 있다고 봤음