Arm판 Windows에서 업무 앱은 동작하는가 ── x64 에뮬레이션(Prism)과 네이티브 DLL·COM의 현실

「다음 달부터 쓸 새 PC, Copilot+ PC라는 걸로 하려는데, 우리 업무 시스템은 동작하나요?」── Snapdragon 탑재 PC의 법인 도입이 진행되면서, 이런 질문을 받는 개발 회사·정보시스템 부서가 늘고 있습니다. 카탈로그에는 「기존 앱도 에뮬레이션으로 동작」이라고 적혀 있습니다. 하지만 자사의 업무 앱은 C# 화면 뒤에서 벤더가 제공하는 네이티브 DLL을 P/Invoke하고, 장표는 COM 컴포넌트를 경유하며, 게다가 전용 기기의 드라이버까지 들어 있습니다. 「동작하나요?」에 즉답하지 못하는 것이 솔직한 현실이 아닐까요.

결론부터 말하면, 「앱 본체는 대개 동작한다. 위험한 것은 앱 주변에 있는 녀석들이다」입니다. x86/x64의 사용자 모드 코드는 Windows 11의 에뮬레이션이 상당한 정밀도로 처리해 주는 반면, 드라이버·셸 확장·프로세스 내 아키텍처 혼재라는 「에뮬레이션의 수비 범위 밖」이 분명히 존재합니다. 그리고 이 수비 범위 밖이야말로, 업무 앱이 즐겨 사용해 온 영역입니다.

이 글에서는 Windows on Arm의 에뮬레이션 구조와 한계, x64와 Arm64를 프로세스 내에서 섞을 수 없다는 대원칙, .NET 앱 특유의 조합 문제, 그리고 「자사 앱이 Arm 기기에서 동작하는가」를 확인하는 실무 절차를, Microsoft Learn으로 근거를 확인할 수 있는 범위에서 정리합니다.

1. 먼저 결론

급하신 분은 우선 이 3가지만 보셔도 충분합니다.

1. 앱 본체는 대개 동작합니다. Windows 11 on Arm은 x86/x64 앱을 OS 내장 에뮬레이션으로 실행할 수 있으며, 24H2 이후에는 Prism으로 성능도 개선되었습니다.¹
2. 위험한 것은 「주변」입니다. 커널 모드 드라이버, 셸 확장이나 IME처럼 다른 프로세스에 로드되는 DLL, 그리고 네이티브 DLL·COM의 아키텍처 불일치. 동작 여부는 앱 본체가 아니라 여기서 결정됩니다.²³⁴
3. 확인은 3단계로 충분합니다. 의존물 목록화 → x64 그대로 Arm 기기에서 실기 확인 → 필요하면 Arm64 네이티브화. 절차는 6장에서 다룹니다.

Arm64EC·Arm64X라는 용어는 4장에서 설명합니다. 여기서 외울 필요는 없습니다. 아래는 이 3가지 항목의 세부 내용과 출처입니다. 세부 사항이 필요할 때 다시 돌아와 주세요.

• 순수한 매니지드(.NET) 앱이나 일반적인 x86/x64 데스크톱 앱은, Arm판 Windows 11의 에뮬레이션으로 거의 동작합니다. 에뮬레이션은 OS에 내장되어 있어, 앱 수정도 추가 컴포넌트도 필요하지 않습니다.¹
• 에뮬레이션이 처리해 주는 것은 사용자 모드 코드뿐입니다. 커널 모드 드라이버는 에뮬레이션되지 않으며, Arm64 네이티브가 필수입니다. UMDF 드라이버나 프린터 드라이버도 OS의 아키텍처에 맞춰야 합니다.²³
• 셸 확장·IME·지원 기술 등 「다른 프로세스(Explorer 등)에 로드되는 DLL」도, 시스템과 동일한 Arm64로의 재컴파일이 필요합니다. 에뮬레이션으로는 구제할 수 없습니다.⁴
• 하나의 프로세스 내에서 x64와 Arm64는 혼재할 수 없습니다. x64/Arm64EC 프로세스가 로드할 수 있는 것은 x64와 Arm64EC 바이너리, Arm64 프로세스가 로드할 수 있는 것은 Arm64 바이너리뿐입니다. x64의 exe에서 Arm64의 DLL은 호출할 수 없고, 그 반대도 마찬가지입니다.⁵
• 이 제약을 하나의 파일로 넘어서기 위한 구조가 Arm64EC(x64와 동일 프로세스에서 혼재할 수 있는 네이티브 Arm64 코드)와 Arm64X(Arm64와 Arm64EC를 하나의 PE에 함께 담아, 어느 프로세스에도 로드할 수 있는 바이너리)입니다. 양쪽 아키텍처에서 호출되는 COM 인프로세스 서버나 플러그인은 Arm64X가 나설 차례입니다.⁵⁶
• .NET은 .NET 6 이후로 Windows Arm64를 공식 지원하며(현재 지원 중인 .NET 8/9/10에서는 Windows 11/10의 Arm64가 지원 대상 OS로 명시되어 있습니다), RID win-arm64로 네이티브 발행할 수 있습니다. 반면 AnyCPU 앱을 Arm64의 .NET 런타임으로 실행하면 프로세스는 Arm64로 동작하기 때문에, x64 버전만 있는 네이티브 DLL을 P/Invoke하고 있으면 로드에 실패한다는 조합 문제가 발생합니다.⁷⁸⁵
• 검증 환경은 실기(Copilot+ PC 등) 외에도, Azure의 Windows 11 Arm64 VM, Arm 기기의 Hyper-V나 Apple Silicon Mac에서 사용할 수 있는 Windows 11 Arm64 ISO로 준비할 수 있습니다. ※x64 기기의 Hyper-V에서는 Arm64 VM을 만들 수 없습니다.⁹¹⁰

2. Arm판 Windows란 ── Snapdragon 탑재 PC와 Prism

Arm판 Windows는 Arm64 프로세서 위에서 동작하는 Windows입니다. 2024년 이후 「Copilot+ PC」── 초당 40조 회 이상의 연산(40+ TOPS)이 가능한 NPU를 탑재한 Windows 11 PC의 새로운 카테고리 ── 의 다수가 Arm 기반의 Snapdragon X 시리즈를 채택하면서, 개발자가 의식하지 않을 수 없는 존재가 되었습니다.¹¹¹²

기존 앱과의 호환성을 뒷받침하는 것이 OS 내장 에뮬레이션입니다. 구조의 요점은 다음과 같습니다.¹

• 에뮬레이터는 x86/x64 명령 블록을 Arm64 명령으로 JIT 컴파일하고, 변환 결과를 모듈 단위로 캐시하여 두 번째 이후 실행 속도를 높입니다.
• Windows 11은 x86과 x64 양쪽 모두를 에뮬레이션할 수 있습니다. Windows 10 on Arm이 에뮬레이션할 수 있는 것은 x86뿐이므로, x64 업무 앱 이야기는 사실상 Windows 11을 전제로 합니다.
• Windows 11 24H2에서는 새로운 에뮬레이터 Prism이 도입되어, 기존보다 성능이 향상되고 CPU 사용률이 낮아졌습니다. Prism은 Qualcomm Snapdragon용으로 최적화되어 있습니다.
• 32bit(x86) 앱은 x64판 Windows와 동일한 WOW64 레이어 위에서 동작하며, 파일 시스템·레지스트리 리다이렉션을 받습니다. 반면 x64 앱에는 WOW64 레이어가 없고, 시스템 바이너리가 후술할 Arm64X 형식으로 컴파일되어 있기 때문에, x64 앱은 리다이렉션 없이 OS 전체(파일 시스템도 레지스트리도)에 접근할 수 있습니다.¹

에뮬레이션 하에서 앱에 보이는 CPU 정보는 「에뮬레이트된 가상 프로세서」의 정보입니다. 호환성을 위해 GetNativeSystemInfo조차 에뮬레이트된 값을 반환하므로, 호스트가 Arm64인지 알고 싶다면 IsWow64Process2나 GetMachineTypeAttributes를 사용합니다.¹³

참고로 에뮬레이션에서 문제가 발생한 앱을 위해, exe를 마우스 오른쪽 버튼 클릭 → 속성 → 호환성 탭에서 에뮬레이션 설정(기본/안전/엄격/매우 엄격 프리셋과 개별 세부 설정)을 변경하는 기능이 Windows 쪽에 마련되어 있습니다. 호환성과 맞바꿔 성능이 떨어지는 조정이지만, 「예전 Windows on Arm에서는 동작했는데」라는 경우의 탈출구로 기억해 둘 가치가 있습니다.¹⁴

3. 에뮬레이션으로 동작하는 것·동작하지 않는 것

「동작하나요?」에 대한 답은 앱 본체가 아니라 의존물의 종류로 결정됩니다. 세부 사항으로 들어가기 전에, 에뮬레이션의 수비 범위가 어디서 끊기는지를 계층별로 짚어 두면 이후의 판단이 빨라집니다.

경계는 「자신의 프로세스 안인가 밖인가」, 그리고 「사용자 모드인가 커널 모드인가」라는 2가지입니다. 이 2가지 경계 밖에 있는 의존물을 하나하나 헤아리는 작업이 사실상 Arm 대응 조사의 전부라고 해도 과언이 아닙니다. 아래는 같은 내용을 실제 검토 대상이 되는 단위로 나열한 판단표입니다.

업무 앱의 맥락으로 다시 말하면, 위험 신호는 다음과 같은 것들입니다.

• VPN 클라이언트, 자산 관리 에이전트, 보안 제품 ── 커널 드라이버 덩어리입니다. Arm64 대응판의 유무를 벤더에 확인해야 합니다.
• USB 동글 인증, 전용 기기(계측기·결제 단말 등) ── 디바이스 드라이버가 Arm64로 제공되는지가 생명선입니다.
• 「탐색기에 기능을 추가하는」계열 도구 ── 셸 확장은 Arm64의 탐색기에 로드되기 때문에, x64 그대로는 작동하지 않습니다.
• 앱 본체가 여기에 해당하지 않더라도, 설치 프로그램이 드라이버를 동봉하고 있는 경우(가상 프린터 드라이버 방식의 PDF 출력 등)는 같은 문제를 겪습니다.

4. 프로세스 내 아키텍처 혼재는 불가능하다 ── P/Invoke와 COM의 현실

32bit 시대부터 「64bit 프로세스는 32bit DLL을 로드할 수 없다」는 철칙이 있었습니다¹⁶. Arm판 Windows에도 같은 구조의 철칙이 있습니다. 로드 가능 여부의 규칙은 공식적으로 다음과 같이 정리되어 있습니다.⁵

여기서 등장하는 2가지 구조가 Arm 대응 설계를 고민할 때의 핵심입니다.

• Arm64EC(Emulation Compatible)는 x64의 호출 규약·스택 사용·데이터 레이아웃을 따름으로써, 동일 프로세스 내에서 에뮬레이션 실행되는 x64 코드와 혼재할 수 있는 네이티브 Arm64 코드의 ABI입니다. x64 앱이 Windows 11 on Arm에서 동작할 때, 그 프로세스에 로드되는 OS 코드의 대부분은 Arm64EC로 컴파일되어 있으며, 앱이 알아채지 못한 채 네이티브 속도로 실행되고 있습니다. 의존 DLL이 x64 그대로라도, 자신의 코드부터 순서대로 Arm64EC화하여 성능을 높여 가는 단계적 이행에 사용할 수 있습니다.⁵
• Arm64X는 기존의 Arm64 코드와 Arm64EC 코드를 하나의 PE 파일에 함께 담은 바이너리 형식입니다. 로드하는 프로세스가 x64라면 x64의 DLL로, Arm64라면 Arm64의 DLL로 동작하기 때문에, 양쪽 아키텍처의 프로세스에서 호출될 가능성이 있는 DLL에 적합합니다. 공식 문서는 Arm64X가 필요한 상황으로 「x64와 Arm64 양쪽 앱에서 호출되는 64bit COM 서버」, 「x64/Arm64 어느 쪽 앱에도 로드되는 플러그인」, 「x64/Arm64 프로세스에 주입되는 단일 바이너리」를 들고 있습니다.⁶

업무 앱에서의 실질적인 피해를 구체화해 봅시다.

케이스 1: x64의 exe + x64의 네이티브 DLL(P/Invoke). 프로세스 전체가 x64로 통일되어 있다면, 통째로 에뮬레이션 안에서 동작합니다. 「일부만 빠르게 하고 싶다」며 Arm64의 DLL을 섞을 수는 없습니다(위 표대로 불가능합니다).

케이스 2: COM 인프로세스 서버. COM의 in-proc 서버는 그냥 DLL이므로, 위 표의 규칙이 그대로 적용됩니다. x64 클라이언트에서는 x64(또는 Arm64EC/Arm64X)의 COM DLL만 사용할 수 있으며, 앱을 Arm64 네이티브화하는 순간 x64의 COM DLL은 로드할 수 없게 됩니다. 양쪽 모두 지원해야 한다면, DLL을 Arm64X화하거나, 32bit↔64bit에서 실적이 있는 아웃프로세스 COM/IPC 분리(프로세스를 나누어 프로세스 간 통신으로 연결) 정석을 적용합니다. 아키텍처의 벽은 프로세스 경계에서 넘는 것이 예로부터의 기본형입니다.¹⁶⁶

케이스 3: 자신이 플러그인을 호스팅하거나, 호스팅되는 경우. Excel 애드인, 업무 패키지의 플러그인, 인쇄 미들웨어 등 「상대 프로세스에 자신의 DLL이 로드되는」형태는 상대의 아키텍처에 맞춰야 합니다. 반대로 자사 앱이 플러그인을 호스팅하고 있다면, 자사 앱을 Arm64화하면 x64의 서드파티 플러그인이 전멸한다는 영향 범위를 미리 파악해 둘 필요가 있습니다.

참고로 수중의 바이너리가 어느 것인지는 개발자 명령 프롬프트에서 확인할 수 있습니다.⁵

link /dump /headers MyLibrary.dll

확인할 것은 FILE HEADER VALUES 바로 다음 1줄뿐입니다. 공식 문서에는 다음과 같은 형태의 출력이 제시되어 있습니다.⁵

File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
    8664 machine (x64) (ARM64X)

이 machine 행을 구분해서 읽습니다.

출력이 길기 때문에, link /dump /headers MyLibrary.dll | findstr machine처럼 연결해서 이 1줄만 추출하는 것이 실무적입니다. 참고로 빌드 도중의 OBJ/LIB를 같은 명령으로 조사하면 A641 machine (ARM64EC)로 표시되지만, 이는 MSVC 내부 식별자이며 최종 EXE/DLL의 machine 값은 아닙니다.⁵

이미 실행 중인 앱만 조사하고 싶다면, 작업 관리자의 「자세히」탭에 「아키텍처」열을 표시하는 방법도 있습니다. 실행 파일이 Arm64EC로 컴파일된 앱은 ARM64 (x64 compatible)로 표시됩니다.⁵

5. .NET 앱의 경우 ── AnyCPU의 함정과 아키텍처 판정

.NET(Core 계열)은 .NET 6 이후로 Windows Arm64를 공식 지원하며, 현재 지원 중인 .NET 8/9/10에서는 Windows 11/10의 Arm64가 지원 대상 OS로 명시되어 있습니다. 발행은 RID에 win-arm64를 지정하기만 하면 됩니다.¹⁷⁷

<!-- csproj: Arm64 네이티브용으로 발행 -->
<PropertyGroup>
  <TargetFramework>net8.0-windows</TargetFramework>
  <RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>

dotnet publish -r win-arm64 -c Release

순수하게 매니지드 코드만으로 이루어진 앱이라면, 이것으로 Arm64 네이티브화는 거의 완료입니다. JIT가 Arm64 코드를 생성할 뿐, 소스 수정은 기본적으로 필요하지 않습니다. .NET Framework 앱의 경우에는 .NET Framework 4.8.1이 Arm64 네이티브 지원을 추가했습니다(Windows 11의 Arm64 기기용. 4.8.1 런타임은 Windows 10의 Arm 기기에서는 네이티브 Arm64 앱을 지원하지 않습니다). x64 빌드 그대로의 Framework 앱은 에뮬레이션으로 동작하는 취급입니다.¹⁸¹⁹

문제는 네이티브 DLL을 P/Invoke하고 있는 경우의 조합입니다. Arm 기기에서는 「.NET 앱이니까 AnyCPU로 어디서든 동작한다」는 오랜 감각이 배신당합니다.

• Arm64의 .NET SDK/런타임으로 실행하면, 앱은 기본값으로 Arm64 프로세스로 실행됩니다.⁸
• Arm64 프로세스는 x64의 DLL을 로드할 수 없습니다(4장의 표). 즉 AnyCPU인 자사 코드는 멀쩡해도, DllImport하고 있는 x64 네이티브 DLL을 로드하는 부분에서 실패합니다.⁵
• 반대로 win-x64로 발행한 앱은 프로세스 전체가 x64가 되어, 에뮬레이션 안에서(x64 네이티브 DLL까지 포함해) 동작합니다. 이 경우 Arm64 네이티브의 성능은 얻을 수 없지만, 동작 호환성은 가장 높은 구성입니다.¹²

「동작하기도 하고 안 하기도 하는」것처럼 보이는 정체는, 대부분 프로세스의 아키텍처와 네이티브 의존물의 아키텍처 불일치입니다. 원인 분리의 첫걸음으로, 실행 중인 프로세스가 무엇으로 동작하고 있는지를 코드로 확인할 수 있게 해 두면 조사가 단숨에 편해집니다.

using System.Runtime.InteropServices;

// 프로세스 자체의 아키텍처(x64 에뮬레이션 하에서라면 X64)
Console.WriteLine($"Process: {RuntimeInformation.ProcessArchitecture}");

// OS 본래의 아키텍처(Arm 기기라면 Arm64)
Console.WriteLine($"OS: {RuntimeInformation.OSArchitecture}");

주의할 점으로, OSArchitecture가 「에뮬레이션을 걷어낸 본래의 OS 아키텍처」를 반환하게 된 것은 .NET 7부터입니다. 그 이전에는 에뮬레이션 하에서 X64를 반환했기 때문에, .NET 6 이전에서 「Arm 기기인지 여부」를 이 API로 판정하는 코드는 기대한 대로 동작하지 않습니다.²⁰²¹

.NET 고유의 체크포인트를 정리합니다.

• NuGet 패키지의 네이티브 자산: runtimes/win-x64/native만 가진 패키지는 win-arm64 발행 시 의지할 것이 없습니다. 패키지 내용(또는 리포지토리)에서 win-arm64 자산의 유무를 확인합니다. RID는 바로 이 「플랫폼 고유 자산의 분류」를 위한 구조입니다.⁷
• 개발 기기의 SDK 구성: Arm 기기에서는 Arm64판 .NET이 일반적인 C:\Program Files\dotnet\에, x64판 SDK는 C:\Program Files\dotnet\x64\에 설치되어 공존할 수 있습니다. PATH나 DOTNET_ROOT가 어느 쪽을 가리키는지에 따라 dotnet run의 실행 아키텍처가 달라지므로, 검증 시에는 유의하시기 바랍니다.¹⁷
• 예외를 읽는 법: 매니지드 어셈블리의 아키텍처 불일치는 BadImageFormatException으로 나타납니다(공식 레퍼런스에도 「다른 플랫폼을 대상으로 하는 컴포넌트의 로드」가 발생 조건으로 명시되어 있습니다).²²

6. 자사 앱의 Arm 대응 체크리스트

실무에서는 다음 3단계로 확인하는 것이 효율적입니다.

4장에서 살펴본 케이스가 어느 단계에서 영향을 미치는지도 대응시켜 둡니다.

②③을 위한 검증 환경은 다음과 같은 선택지가 있습니다.

• 실기: Copilot+ PC 등의 Snapdragon 탑재 기기. 1대 있으면 트러블 조사까지 포함해 가장 확실합니다.¹²
• Azure VM: Azure 포털에서 이미지를 Arm64로 필터링하여, Windows 11의 Arm64 VM(권장 크기 D2ps_v5 등, Ampere Altra 기반)을 만들 수 있습니다. 수중에 Arm 기기가 한 대도 없어도 검증을 시작할 수 있다는 것이 장점입니다.⁹
• 로컬 VM: Windows 11 Arm64의 ISO가 공식 배포되고 있어, Arm 기기의 Hyper-V나 Arm 기반 Apple Silicon Mac 위에서 VM을 만들 수 있습니다. x64 기기의 Hyper-V에서는 Arm64 VM을 만들 수 없다는 점에 주의하시기 바랍니다.¹⁰

서드파티 제품의 대응 현황은 Microsoft가 안내하는 대응 현황 사이트(Windows on Arm Ready Software)에서 확인할 수 있습니다. 그 위에서, 자사 개발 업무 앱(LOB)이나 ISV 제작 앱의 호환성 문제에 대해서는 App Assure라는 공식 지원 창구가 있습니다. 「동작하지 않아서 사면초가」에 빠지기 전에 이용할 수 있는 창구가 있다는 것은, 정보시스템 부서에 대한 설명 자료로서도 유효합니다.¹²¹⁵

자사가 대상인지 판단하는 재료를 정리하면 다음과 같습니다.²⁴²⁵

자사의 라이선스 구성이 대상인지는, 위의 플랜 이름을 정보시스템·조달 부서의 계약 내용과 대조하는 것이 가장 빠릅니다. 라이선스 수 조건이나 대상 플랜 목록은 변경될 수 있으므로, 실제로 신청하기 전에 FastTrack의 대상 조건 페이지에서 최신 내용을 확인하시기 바랍니다.

7. 당장의 현실적 해법 ── 3가지 선택지의 구분 사용

Arm 대응은 「전부 네이티브화」 한 가지 방법만 있는 것이 아닙니다. 오히려 많은 업무 앱에서는 단계적인 구분 사용이 현실적인 해법입니다.

C++ 자산이 큰 경우에는 (a)와 (c)의 중간으로 Arm64EC가 있습니다. x64의 의존 DLL은 그대로 둔 채, 자신의 코드만 단계적으로 네이티브화할 수 있기 때문에, 「거대한 x64 앱을 한 번에 이행할 수 없다」는 경우를 위한 공식 경로입니다.⁵²³

개발 환경 측면에서는 Visual Studio에 Arm64 네이티브판이 있어, Arm 기기 위에서 Arm64/x64/x86 모두를 타깃으로 할 수 있는 컴파일러 툴셋이 갖춰져 있습니다. CI용 빌드는 기존의 x64 빌드 머신에서의 크로스 컴파일로도 만들 수 있으므로, 「테스트 실행만 Arm 실기/VM으로 몰아주는」구성을 짜기 쉬워졌습니다.²⁶²³

8. 정리

• Arm판 Windows 11은 x86/x64 앱을 OS 내장 에뮬레이션으로 실행할 수 있으며, 24H2 이후에는 Prism으로 성능도 개선되었습니다. x64 에뮬레이션은 Windows 11부터이며, Windows 10 on Arm은 x86뿐입니다.
• 에뮬레이션의 수비 범위는 사용자 모드뿐입니다. 커널 모드/UMDF/프린터 각 드라이버, 셸 확장·IME·지원 기술 같은 「다른 프로세스에 로드되는 DLL」은 Arm64 네이티브가 필수입니다. 업무 앱의 동작 가능 여부는 앱 본체가 아니라 이러한 주변 의존물로 결정됩니다.
• 프로세스 내에서 x64와 Arm64는 혼재할 수 없습니다. x64/Arm64EC 프로세스는 x64+Arm64EC를, Arm64 프로세스는 Arm64만을 로드할 수 있습니다. COM 인프로세스 서버도 플러그인도 같은 규칙을 따르며, 양쪽 모두 지원하려면 Arm64X, 프로세스 경계를 넘으려면 아웃프로세스 COM/IPC가 정석입니다.
• .NET은 win-arm64로 네이티브 발행할 수 있지만, Arm64 런타임 상의 AnyCPU 앱은 Arm64 프로세스로 동작하기 때문에, x64 전용 네이티브 DLL을 P/Invoke하고 있으면 실패합니다. RuntimeInformation.ProcessArchitecture / OSArchitecture(.NET 7 이후)로 원인을 구분합니다.
• 확인 절차는 「의존물 목록화 → x64 그대로 에뮬레이션으로 실기 확인 → 필요하면 Arm64 네이티브화」의 3단계입니다. 검증 환경은 Azure의 Arm64 VM이나 Arm64 ISO로 준비할 수 있으며, 법인은 App Assure의 지원도 받을 수 있습니다.
• 당장은 「에뮬레이션으로 동작하면 그대로」「드라이버·DLL 벤더의 대응 확인」「요건에 따라 Arm64 네이티브화(C++는 Arm64EC의 단계적 이행도)」라는 구분 사용이 현실적인 해법입니다.

관련 글

• C#에서 네이티브 DLL을 쓴다면 C++/CLI 래퍼가 유력한 이유 - P/Invoke와 비교해 정리
• C#에서 Win32 API를 안전하게 호출하기 — P/Invoke 실무 가이드(DllImport / LibraryImport / CsWin32)
• C#을 Native AOT로 네이티브 DLL로 만드는 방법 - UnmanagedCallersOnly로 C/C++에서 호출하기
• Windows에서 어디까지 싱글 바이너리로 만들 수 있는가 - 1 EXE로 가능한 범위, Windows 의존이 남는 곳, 배포 전 판단표
• 32bit 앱에서 64bit DLL을 호출하는 방법 - COM 브리지가 도움이 되는 케이스 스터디

관련 상담 영역

합동회사 코무라소프트에서는 기존 업무 앱의 Arm판 Windows 대응 가능 여부 조사, 네이티브 DLL·COM 연계를 포함한 앱의 아키텍처 이행 설계, 「Arm 기기에서만 동작하지 않는」결함의 원인 분석을 다루고 있습니다.

• Windows 앱 개발
• 기술 상담·설계 리뷰
• 결함 조사·원인 분석
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

Arm판 Windows에서 일반적인 x64 업무 앱은 동작합니까?

대부분의 경우 동작합니다. Windows 11 on Arm에는 x86/x64 앱을 수정 없이 실행하는 에뮬레이션 기능이 내장되어 있으며, Windows 11 24H2 이후로는 Prism이라는 새로운 에뮬레이터로 성능도 개선되었습니다. 다만 에뮬레이션이 처리해 주는 것은 사용자 모드 코드뿐이며, 커널 모드 드라이버나 Explorer 등 다른 프로세스에 로드되는 셸 확장·IME 같은 것들은 Arm64 네이티브가 필수입니다. 앱 본체보다 주변 의존물이 결정한다고 생각하시면 됩니다.

x64의 exe에서 Arm64의 DLL을 호출할 수 있습니까?

호출할 수 없습니다. 하나의 프로세스 안에서 x64와 Arm64 바이너리를 혼재시킬 수 없으며, x64(또는 Arm64EC) 프로세스가 로드할 수 있는 것은 x64와 Arm64EC 바이너리, Arm64 프로세스가 로드할 수 있는 것은 Arm64 바이너리뿐입니다. 반대 방향(Arm64의 exe에서 x64의 DLL)도 마찬가지로 불가능합니다. 아무래도 양쪽 모두를 지원하는 하나의 DLL이 필요하다면, Arm64와 Arm64EC 코드를 하나의 파일에 함께 담는 Arm64X라는 형식을 쓰거나, 프로세스를 나누어 IPC로 연계하는 구성을 사용합니다.

.NET 앱을 Arm64에 대응시키려면 무엇이 필요합니까?

.NET 6 이후는 Windows Arm64를 공식 지원하며, 현재 지원 중인 .NET 8/9/10에서는 Windows 11/10의 Arm64가 지원 대상 OS로 명시되어 있습니다. RID(런타임 식별자) win-arm64를 지정해 publish하기만 하면 Arm64 네이티브 실행 파일을 만들 수 있습니다. 순수한 매니지드 코드만으로 이루어진 앱이라면 이것으로 거의 완료지만, P/Invoke하고 있는 네이티브 DLL이나 네이티브 자산을 포함한 NuGet 패키지가 있다면 각각의 Arm64 버전이 존재하는지 확인이 필요합니다. .NET Framework 앱의 경우에는 4.8.1이 Windows 11 상에서의 Arm64 네이티브 실행을 지원합니다.

Arm판 Windows에서 동작하지 않는 것은 어떤 소프트웨어입니까?

커널 모드 드라이버를 포함한 소프트웨어가 대표적입니다. 드라이버는 에뮬레이션되지 않기 때문에, VPN 클라이언트, 보안 제품, 가상 디바이스, USB 동글 인증 등은 Arm64 드라이버가 없으면 동작하지 않습니다. 다음으로 셸 확장·IME·지원 기술처럼 OS 쪽 프로세스에 DLL을 로드시키는 소프트웨어, 동적 코드 생성을 금지한 앱, 오래된 OpenGL이나 안티치트 드라이버에 의존하는 게임 등이 해당합니다. 주변기기도 Arm64 드라이버의 유무에 따라 사용 가능 여부가 결정됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.