Microsoft Foundry on Windows란 무엇인가? Windows 앱에서 로컬 AI를 다루기 위한 기반 정리

Windows 주변의 AI 기능을 추적하다 보면, Microsoft Foundry on Windows, Windows AI APIs, Foundry Local, Windows ML 등 비슷한 이름의 것들이 여러 개 등장합니다.

이전에는 Windows Copilot Runtime이나 Windows AI Foundry라는 명칭도 사용되었기 때문에, 오래된 기사나 자료에서는 여러 이름을 볼 수 있습니다. 2026년 6월 시점에서, 이 기사에서는 현재의 총칭인 Microsoft Foundry on Windows를 주로 사용합니다.

처음 보면 조금 이해하기 어려울 수 있지만, 대략적으로 파악하자면 Windows 상에서 로컬 AI를 사용하기 위한 개발자용 토대라고 생각하면 정리하기 쉽습니다.

이 기사에서는 개인적인 정리 메모로서, Microsoft Foundry on Windows가 무엇을 가리키는지, 어떤 구성 요소를 어떻게 보면 좋을지를 정리합니다.

참고로, Windows의 AI 기능은 프리뷰(Preview), 실험적(Experimental), 대응 하드웨어 의존적인 요소가 많습니다. 이 기사는 2026년 6월 15일 시점에서 확인한 Microsoft Learn의 정보를 바탕으로 정리한 것입니다.

Microsoft Foundry on Windows는 Windows 앱에 로컬 AI 기능을 통합하기 위한 메커니즘들의 집합입니다.

공식 문서에서는 Microsoft Foundry on Windows라는 이름으로 설명되어 있으며, 주로 다음 세 가지 입구가 있습니다.

Windows AI APIs
Foundry Local
Windows ML

각각 역할이 조금 다릅니다.

입구	대략적인 역할	적합한 케이스
Windows AI APIs	Microsoft가 준비한 로컬 AI 기능을 API로서 사용	Copilot+ PC 등에서 OCR, 이미지 처리, Phi Silica 등을 빠르게 사용하고 싶을 때
...

즉, Microsoft Foundry on Windows를 하나의 단일 SDK로 보기보다는, Windows에서 AI 모델을 구동하기 위한 여러 가지 선택지를 모아놓은 우산이라고 보는 편이 이해하기 쉽습니다.

Microsoft Learn의 Windows AI 페이지에서는 Windows 앱을 더욱 똑똑하게 만들기 위해 로컬 모델, NPU 하드웨어, 원격 API를 활용하는 방법을 안내하고 있습니다.

그중에서 Microsoft Foundry on Windows는 Windows 앱에 로컬 AI 기능을 통합하기 위한 주요 솔루션으로 설명되어 있습니다.

할 수 있는 일을 크게 나누면 다음 세 가지입니다.

• Microsoft가 준비한 AI 기능을 API로 사용: Windows AI APIs
• OSS의 LLM이나 음성 모델을 선택하여 로컬 실행: Foundry Local
• 자체 제작하거나 ONNX 형식으로 변환한 모델을 유연하게 실행: Windows ML

Foundry Local은 단순히 Microsoft가 준비한 내장 API를 호출하는 것이라기보다, OSS 모델을 선택·관리하여 로컬 실행하는 입구로 보면 이해하기 쉽습니다.

Windows AI APIs는 Windows 앱에서 사용할 수 있는 AI 기능의 API 군입니다.

공식 문서에서는 AI 기능을 사용하기 위해 스스로 모델을 찾거나, 실행하거나, 최적화하지 않아도 되는 API로 설명되어 있습니다.

대표적인 예로 다음과 같은 것들이 있습니다.

Phi Silica

• Text Recognition, 즉 OCR
• Speech Recognition
• Image Description
• Image Generation
• Image Super Resolution
• Image Foreground Extractor
• Image Object Extractor / Image Segmentation
• Image Object Erase / Object Erase
• Video Super Resolution
• App Content Search

참고로, 공식 문서 내의 개요 페이지에서도 Image Object Extractor나 Image Object Erase

하드웨어 대응 표에서는 Image Segmentation이나 Object Erase와 같이 유사한 의미의 표기가 병존하고 있습니다. 본문에서는 현재의 개별 API 명칭을 우선시하면서, 큰 틀에서는 "이미지 내 대상 추출", "이미지 내 대상 삭제"로 파악하고 있습니다.

또한, App Content Search는 앱 내의 텍스트와 이미지를 인덱싱(Indexing)하여 키워드 검색 및 의미 기반의 시맨틱 검색(Semantic Search)을 제공하는 기능입니다. 현재 시점에서 AppContentIndexer는 Windows App SDK 2.0 Experimental 4의 Private Preview로 설명되어 있습니다. 따라서 Semantic Search를 독립된 정식 API 명칭처럼 다루기보다는, App Content Search의 기능으로서 설명하는 것이 더 자연스럽습니다.

특히 주의해야 할 점은 대응 하드웨어입니다.

많은 API가 Copilot+ PC의 NPU를 전제로 합니다. 반면, Speech Recognition과 Video Super Resolution은 CPU에서도 이용할 수 있으며, Phi Silica는 일부 GPU도 지원합니다.

단, Phi Silica의 GPU 지원 조건은 구체적입니다. 2026년 6월 기준 공식 정보에 따르면, NVIDIA GeForce RTX 30 시리즈 이후, 6GB 이상의 VRAM, Developer Mode 활성화, Windows Insider Experimental Channel build 26300.8553 이후, Windows App SDK 2.2.2-experimental9 이후, 그리고 GPU 제조사로부터 직접 입수한 최신 드라이버가 필요합니다. AMD GPU 지원은 coming soon 상태입니다.

더불어, Phi Silica API는 Limited Access Feature(LAF)로 제공됩니다. 앱에서 이용하려면 Microsoft에 대한 신청과 LAF의 unlock token이 필요합니다. 대응 하드웨어를 갖추고 있다고 해서 즉시 일반 공개 앱에서 자유롭게 이용할 수 있는 상태가 아니라는 점에도 주의가 필요합니다.

또한, Phi Silica와 Image Description은 중국에서는 이용할 수 없다는 주석이 있습니다. 글로벌 대상 앱에서 사용할 경우, 이러한 지역적 제약도 확인해 두어야 합니다.

2026년 6월 시점에는 Experimental이나 Insider 빌드를 전제로 하는 것도 있으므로, 구현 시에는 반드시 개별 API의 대응 상황을 확인해야 합니다.

Windows AI APIs는 다음과 같은 경우에 적합해 보입니다.

• AI 기능을 짧은 코드로 통합하고 싶을 때
• 모델의 배포나 최적화를 가급적 Microsoft 측에 맡기고 싶을 때
• Copilot+ PC를 위한 앱 경험을 만들고 싶을 때
• OCR, 이미지 가공, 초해상도(Super Resolution), 요약 등 기존 API로 목적을 달성할 수 있을 때

반대로, 독자적인 모델을 세밀하게 제어하고 싶거나 Copilot+ PC 이외의 환경도 폭넓게 지원하고 싶다면, Foundry Local이나 Windows ML도 후보가 될 수 있습니다.

Foundry Local은 로컬 환경에서 LLM 등의 모델을 구동하기 위한 입구입니다.

Microsoft Learn의 정리 내용에 따르면, Foundry Local은 Windows나 macOS 등에서 이용할 수 있는 크로스 플랫폼(Cross-platform) 로컬 모델 실행 환경입니다. OSS LLM이나 음성 받아쓰기(Transcription) 모델을 다루는 선택지로 위치하고 있습니다.

단, 이용하는 SDK나 패키지에 따라 요구 사항이 다릅니다. Foundry Local 전체 문서에서는 Windows 10 x64, Windows 11 x64 / ARM, Windows Server 2025, macOS 등이 지원 대상으로 안내되고 있습니다. 참고로 Foundry Local은 현재 시점에서 프리뷰(Preview)로 제공되고 있습니다.

한편, Microsoft.AI.Foundry.Local.WinML 패키지를 사용하는 Windows용 .NET 퀵스타트에서는 build 26100 이후(즉, 실질적으로는 Windows 11 24H2 상당 이후), .NET 9.0 SDK 이후, DirectX 12 대응 GPU가 전제 조건으로 명시되어 있습니다. GPU 패스스루(Pass-through)가 없는 가상 머신도 대상에서 제외됩니다.

따라서 "Windows 10 이후라면 어떤 환경에서든 동일하게 동작한다"라고 해석하지 않는 것이 좋습니다.

Windows AI APIs가 "준비된 AI 기능을 API로 사용하는" 이미지라면, Foundry Local은 "로컬 LLM을 선택하여 구동하는" 방향에 가깝습니다.

예를 들어, 다음과 같은 용도를 생각할 수 있습니다.

• 앱 내에서 문장 요약
• 자연어 입력을 구조화된 데이터(Structured Data)로 변환
• 로컬에서 채팅이나 보조 기능 제공
• 음성을 텍스트로 변환 (STT)

클라우드 API에만 의존하는 것이 아니라, 단말기 상에서 처리할 수 있는 선택지를 가질 수 있다는 점이 포인트입니다.

Windows ML은 더 낮은 레이어에서 모델을 구동하기 위한 메커니즘입니다.

이 기사에서 다루는 Windows ML은 현재 개발이 진행 중인 ONNX Runtime 기반의 새로운 Windows ML입니다. Windows 10 시대부터 존재했던 기존 Windows ML API와는 구분해서 생각해야 합니다.

공식 문서에서는 Hugging Face 등의 외부 모델, 직접 학습시킨 모델, 기타 모델을 Windows 10 이후의 PC에서 로컬로 실행하는 선택지로 설명되어 있습니다.

Windows ML은 ONNX Runtime 기반의 맥락에서 이야기되며, 모델의 호환성이나 성능은 하드웨어에 의존합니다.

OS 요구 사항도 실행 경로에 따라 달라집니다. CPU 및 DirectML을 통한 GPU 실행은 Windows App SDK가 지원하는 Windows에서 이용할 수 있습니다. 반면, NPU나 특정 GPU를 위한 벤더 최적화 실행 제공자(Execution Provider)에는 Windows 11 version 24H2, 즉 build 26100 이후가 필요합니다.

Windows AI APIs나 Foundry Local로 충분하다면 그쪽이 지름길이지만, 다음과 같은 경우에는 Windows ML을 검토하게 됩니다.

• 자체 ONNX 모델을 사용하고 싶을 때
• Hugging Face 등에서 가져와 ONNX 형식으로 변환한 모델을 사용하고 싶을 때
• 특정 도메인에 맞춰 학습시킨 모델을 사용하고 싶을 때
• 모델 배포나 추론 제어를 앱 측에서 직접 관리하고 싶을 때
• Windows 10을 포함하여 대응 범위를 설계하고 싶을 때
• 단, NPU나 특정 GPU를 위한 벤더 최적화 Execution Provider를 사용할 경우 Windows 11 24H2 이후가 필요

공식 문서의 관점에 따르면, 선택 방법은 다음 순서로 생각하면 이해하기 쉽습니다.

• 목적 기능이 Windows AI APIs에 있고, Copilot+ PC용이면 우선 Windows AI APIs를 확인한다.
• LLM이나 음성 받아쓰기를 로컬에서 다루고 싶다면 Foundry Local을 확인한다.
• 독자 모델이나 기존 모델을 유연하게 다루고 싶다면 Windows ML을 확인한다.

물론 실제 앱에서는 이들을 조합하여 사용할 수도 있습니다.

예를 들어, 이미지 전처리는 Windows AI APIs, 문장 생성 및 정형화는 Foundry Local, 업무 고유의 분류 모델은 Windows ML과 같은 구성도 가능합니다.

이름이 비슷하기 때문에 클라우드 측의 Microsoft Foundry와 혼동하기 쉽습니다. 이전에는 Azure AI Foundry라는 명칭도 사용되었으나, 현재 공식 문서에서는 Microsoft Foundry로 정리되어 있습니다.

매우 대략적으로 나누면 다음과 같이 구분하면 좋습니다.

이름	주요 위치	대략적인 역할
Microsoft Foundry (구 Azure AI Foundry)	Azure / 클라우드	클라우드 상에서 AI 앱이나 에이전트를 구축 및 운용함
Microsoft Foundry on Windows	Windows / 로컬 단말	Windows 앱에 로컬 AI를 통합함

둘 다 "AI 앱을 만들기 위한 Foundry"이지만, 중심이 되는 실행 장소가 다릅니다.

클라우드 측의 Microsoft Foundry는 모델, 에이전트, 도구, 평가, 모니터링 등을 Azure 상에서 다루는 AI 앱·에이전트 개발 기반으로 보면 이해하기 쉽고, Microsoft Foundry on Windows는 Windows 단말 상의 로컬 AI 기반으로 보면 이해하기 쉽습니다.

Microsoft Foundry on Windows와 함께 자주 언급되는 것으로 MCP on Windows가 있습니다.

MCP (Model Context Protocol)는 AI 애플리케이션과 외부 도구 및 데이터 소스를 연결하기 위한 프로토콜입니다.

Microsoft Learn에서는 MCP on Windows를 Windows On-device Agent Registry (ODR)를 제공하며, AI 앱이나 에이전트가 로컬 앱 또는 원격 서버의 MCP 서버를 발견하고 이용하기 위한 메커니즘으로 설명하고 있습니다.

이 부분은 다음과 같이 나누어 이해하면 쉽습니다.

• Microsoft Foundry on Windows: 모델 및 AI 기능을 Windows 상에서 실행 및 이용하기 위한 기반
• MCP on Windows: AI 앱이나 에이전트가 외부 기능, 데이터, 도구에 접속하기 위한 기반

예를 들어, 로컬 LLM이 Foundry Local에서 동작하고, 해당 AI 앱이 MCP on Windows를 통해 File Explorer 커넥터에 액세스하는 식의 방향성을 생각해 볼 수 있습니다.

다만, MCP는 편리한 한편, 권한, 사용자 동의, 감사(Audit), 프롬프트 인젝션(Prompt Injection) 대책 등의 설계가 중요해집니다. 공식 문서에서도 MCP에 관한 정보에는 프리릴리스(Pre-release) 제품에 관한 주의 사항이 붙어 있습니다.

Microsoft Foundry on Windows의 가치는 단순히 "AI를 사용할 수 있다"는 것이 아니라, Windows 앱 안에서 로컬 AI를 다루기 쉽게 만든다는 점에 있다고 생각합니다.

구체적으로는 다음과 같은 장점을 기대할 수 있습니다.

• 네트워크에 의존하지 않는 AI 기능을 만들 수 있음
• 레이턴시(Latency)를 낮추기 쉬움
• 사용자 데이터를 단말기 내에 머물게 하기 쉬움
• NPU나 GPU 등 로컬 하드웨어를 활용할 수 있음
• 모델 배포 및 런타임(Runtime) 주변의 복잡성을 일부 흡수할 수 있음

물론 모든 것을 로컬에서 완결해야 하는 것은 아닙니다.

무거운 추론, 대규모 검색, 업무 데이터 연동, 운영 모니터링 등은 클라우드 측이 더 적합한 케이스도 있습니다. 따라서 실제로는 로컬 AI와 클라우드 AI를 어떻게 나눌지가 설계의 핵심 포인트가 될 것입니다.

현시점에서 다룰 때는 다음 사항에 주의하는 것이 좋습니다.

Windows AI APIs에는 Copilot+ PC의 NPU를 전제로 한 것들이 있습니다.

또한, GPU나 CPU를 지원하는 API라 하더라도 지원 GPU, 드라이버, Developer Mode, Windows App SDK 버전 등의 조건이 있을 수 있습니다.

"Windows 11이라면 전부 동작한다"고 생각하면 위험하므로, API별로 대응 표를 확인하는 것이 좋습니다.

Windows AI APIs의 일부 모델은 최초 이용 시 EnsureReadyAsync 등을 통해 다운로드됩니다. 예를 들어 Phi Silica, AI Image Generation, CPU 버전 Speech Recognition 등은 모델이 단말기에 없는 경우 다운로드가 발생할 가능성이 있습니다.

모델에 따라 수 GB 규모가 될 수도 있으므로, 다운로드 전에 크기나 통신 발생 여부를 안내하고 사용자의 동의를 얻는 UX가 중요합니다.

한편, Foundry Local 측에서는 모델 취득 및 캐시 관리를 Windows AI APIs와는 별도의 SDK나 CLI로 다룹니다. EnsureReadyAsync는 주로 Windows AI APIs 측의 문맥으로 구분해 두면 양자를 혼동하지 않기 쉽습니다.

AI 모델의 출력은 사용자의 의도와 다를 수 있습니다.

특히 MCP처럼 외부 도구나 파일 조작으로 이어지는 경우에는 권한, 확인, 감사 로그, 관리자 제어를 포함한 설계가 중요해집니다.

Windows AI 주변은 업데이트가 빠르며, Experimental(실험적) 또는 Insider용 정보도 있습니다.

기사나 구현 메모를 작성할 때는 날짜와 참조한 문서를 남겨두면 나중에 다시 검토하기 쉽습니다.

Microsoft Foundry on Windows는 Windows 앱에서 로컬 AI를 다루기 위한 개발자용 기반입니다.

정리하면 다음과 같습니다.

• Windows AI APIs는 Microsoft가 준비한 AI 기능을 빠르게 사용하는 입구
• Foundry Local은 OSS LLM이나 음성 받아쓰기 모델을 로컬에서 다루는 입구
• Windows ML은 자체 모델이나 기존 모델을 유연하게 구동하는 입구
• MCP on Windows

는 AI 앱이나 에이전트가 외부 기능에 연결하기 위한 메커니즘입니다. 지원 하드웨어, 모델 배포, 사용자 동의, Responsible AI (책임감 있는 AI) 설계는 반드시 확인해야 합니다.

개인적으로 Microsoft Foundry on Windows는 "Windows 앱에 AI 버튼을 달기 위한 기능"이라기보다, Windows를 로컬 AI 앱의 실행 환경으로 정비해 나가는 흐름으로 이해하는 것이 더 쉽다고 느꼈습니다.

우선 Windows AI APIs, Foundry Local, Windows ML 이 세 가지를 구분해서 읽는 것부터 시작하면 전체적인 모습을 파악하기 쉬울 것입니다.

• Windows AI | Microsoft Learn
• Use local AI with Microsoft Foundry on Windows | Microsoft Learn
• What are Windows AI APIs? | Microsoft Learn
• Get started with Phi Silica | Microsoft Learn
• App Content Search Overview | Microsoft Learn
• Get started with Foundry Local | Microsoft Learn
• Foundry Local documentation | Microsoft Learn
• Get started with Foundry Local - Foundry Local | Microsoft Learn
• What is Windows ML? | Microsoft Learn
• Microsoft Foundry documentation | Microsoft Learn
• Model Context Protocol (MCP) on Windows overview | Microsoft Learn