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

「다음 달부터 쓰는 새 PC를 Copilot+ PC로 하려는데, 우리 업무 시스템은 동작합니까?」── Snapdragon을 탑재한 PC의 기업 도입이 늘면서, 이런 질문을 받는 개발사와 사내 IT가 많아지고 있습니다. 카탈로그에는 「기존 앱도 에뮬레이션으로 동작」이라고 적혀 있습니다. 하지만 자사 업무 앱은 C# 화면 뒤에서 벤더가 제공한 네이티브 DLL을 P/Invoke하고, 리포트는 COM 컴포넌트를 거치며, 전용 장비 드라이버까지 들어가 있습니다. 「동작합니까?」에 바로 답하기 어려운 것이 솔직한 심정이 아닐까요.

결론부터 말하면 「앱 자체는 대체로 동작한다. 위험한 것은 앱 주변에 있는 것들이다」입니다. x86/x64 사용자 모드 코드는 Windows 11 에뮬레이션이 꽤 정확하게 처리해 줍니다. 반면 드라이버·셸 확장·프로세스 안에서의 아키텍처 혼용처럼, 에뮬레이션이 다루지 않는 영역이 분명히 있습니다. 그리고 바로 그 영역이야말로 업무 앱이 자주 사용해 온 부분입니다.

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

1. 먼저 결론

시간이 없다면 우선 이 세 가지만 보시면 됩니다.

1. 앱 자체는 대체로 동작합니다. Windows 11 on Arm은 x86/x64 앱을 OS에 들어 있는 에뮬레이션으로 실행할 수 있으며, 24H2부터는 Prism으로 성능도 좋아졌습니다.¹
2. 문제는 「주변」입니다. 커널 모드 드라이버, 셸 확장이나 IME처럼 다른 프로세스에 로드되는 DLL, 그리고 네이티브 DLL·COM의 아키텍처 불일치. 동작 여부는 앱 자체가 아니라 여기서 갈립니다.²³⁴
3. 확인은 3단계면 됩니다. 종속성 파악 → x64 그대로 Arm 기기에서 실제 확인 → 필요하면 Arm64 네이티브로 전환. 절차는 6장입니다.

Arm64EC·Arm64X라는 용어는 4장에서 설명합니다. 여기서 외울 필요는 없습니다. 아래는 이 세 가지의 세부 내용과 출처입니다. 더 필요할 때 다시 보시면 됩니다.

• 순수 관리 코드(.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을 만들 수 없습니다.⁹¹⁰

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 20건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

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. 에뮬레이션으로 동작하는 것·동작하지 않는 것

「동작합니까?」에 대한 답은 앱 자체가 아니라 종속성의 종류로 갈립니다. 세부 사항으로 들어가기 전에, 에뮬레이션이 다루는 범위가 어디서 끝나는지를 계층으로 잡아 두면 이후 판단이 빨라집니다.

경계는 「자기 프로세스 안인가 밖인가」, 그리고 「사용자 모드인가 커널 모드인가」 두 가지입니다. 이 두 경계 밖에 있는 종속성을 세는 작업이, 사실상 Arm 대응 조사의 전부라고 해도 지나치지 않습니다. 아래는 같은 내용을 실제로 검토할 단위로 늘어놓은 판단표입니다.

업무 앱 맥락으로 다시 말하면, 위험 신호는 다음과 같습니다.

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

4. 프로세스 안에서 아키텍처를 섞을 수 없다 ── P/Invoke와 COM의 현실

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

여기서 등장하는 두 가지 장치가 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 바로 다음 한 줄뿐입니다. 공식 문서에는 다음과 같은 형태의 출력이 나와 있습니다.⁵

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

이 machine 줄을 구분해 읽습니다.

출력이 길므로, link /dump /headers MyLibrary.dll | findstr machine처럼 이어 이 한 줄만 꺼내는 것이 실무적입니다. 참고로 빌드 도중의 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 탑재 기기. 한 대 있으면 문제 조사까지 포함해 가장 확실합니다.¹²
• 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라는 공식 지원 창구가 있습니다. 「동작하지 않아 손쓸 방법이 없다」고 하기 전에 쓸 수 있는 창구가 있다는 점은, 사내 IT에 설명할 재료로도 유효합니다.¹²¹⁵

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

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

7. 당장의 현실적인 해법 ── 세 가지 선택지를 나눠 쓰기

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 앱 개발
• 기술 상담·설계 리뷰
• 결함 조사·원인 분석
• 문의하기

참고 링크

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

Windows on Arm에서 일반적인 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 네이티브 실행을 지원합니다.

Windows on Arm에서 동작하지 않는 소프트웨어는 무엇입니까?

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

저자 프로필

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

Go Komura

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

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