AI는 PC에서 구동되지만, 사고하는 장소는 하나가 아니다 — Windows의 하이브리드 인텔리전스와 HydraFusion

개발자 대상 AI 화제에서는 지금까지 '어떤 모델이 똑똑한지', '어떤 모델을 선택할지'에 초점이 맞춰져 왔다고 생각합니다. 그런데 2026년 10월 7일에 공개된 Windows Experience Blog의 기사를 읽고 나니, 질문 자체가 조금 바뀌게 된 것 같습니다.

모델을 고르는 것뿐만 아니라, 이 작업을 어디서 실행하는 것이 좋을지입니다. 클라우드의 모델일지, PC 안에서 구동되는 모델일지. 아니면 하나의 모델이 아닌 여러 모델을 조합할지 말이죠. Windows의 '하이브리드 인텔리전스(hybrid intelligence)'라는 개념은, 개발자가 매번 그 선택을 의식하지 않아도 되는 환경을 목표로 하는 것처럼 보입니다🧭

이번에 특히 주목한 것은 두 가지 움직임입니다. 하나는 MAI Code 1.1 Flash가 NVIDIA RTX Spark를 탑재한 Windows PC 상에서 로컬 실행된다는 점입니다. 다른 하나는 GitHub의 Project HydraFusion이 기존의 여러 클라우드 모델 오케스트레이션(orchestration)에 더해, Windows상의 디바이스 내 모델에도 처리를 라우팅(routing, 분배)하는 개념을 제시하고 있다는 것입니다.

본 기사에서는 먼저 공식 발표로 확인할 수 있는 사실과 제공 시기를 정리한 후, 개발자에게 무엇이 달라질지 생각해 볼 예정입니다. 벤치마크 비교 기사나 실기 리뷰가 아니라, 로컬 LLM(대규모 언어 모델)과 개발자 대상 AI의 경계가 어떻게 바뀔지에 대한 아이디어(idea) 글입니다. 작성 시점은 2026년 10월 8일입니다.

먼저, 발표 내용과 현시점에서의 이용 가능성을 나누어 살펴보겠습니다.

Microsoft의 발표에 따르면, MAI Code 1.1 Flash는 총 137B(1370억)의 파라미터를 가지며, 그중 6.8B(68억)가 활성화되는 모델로 설명되었습니다. Windows Experience Blog에서는 3-bit 정밀도를 사용하여 모델 크기를 약 80% 가까이 줄였다고 소개했습니다. 또한, 256K의 컨텍스트 윈도우(모델이 한 번에 다룰 수 있는 입력 정보 범위)를 로컬에서 처리할 수 있다고 했습니다. 대상은 NVIDIA RTX Spark를 탑재한 Windows PC입니다.

여기서 6.8B는 추론 시 활성화되는 파라미터 개수이며, 모델 전체가 6.8B로 축소되었다는 의미는 아닙니다. 실제로 Microsoft의 기술 기사가 보여주는 양자화(quantization) 버전의 크기는 53 GB입니다. 추론에 사용되는 계산량과 모델을 로컬에서 다루기 위한 메모리 용량은 분리해서 생각해야 합니다.

여기서 말하는 양자화는 모델의 가중치나 활성값을 나타내는 수치의 정밀도를 낮춰 메모리 사용량을 줄이는 기법입니다. 거대한 모델의 가중치를 그대로 유지하는 것이 아니라, 더 적은 메모리로 추론할 수 있는 형태로 만듦으로써, 지금까지 클라우드 측에서 구동되던 규모의 모델을 손안의 디바이스로 가까이 가져오고 있습니다. Microsoft의 기술 기사에서는 동사가 디바이스에서 사용하는 양자화 버전이 53 GB이며, 이는 원래 BF16(bfloat16) 버전과 비교하여 약 80% 작아졌다고 설명합니다.

또한, 같은 기술 기사에 따르면 NVIDIA RTX Spark를 탑재하는 Surface Laptop Ultra에서는 256K 컨텍스트 시의 피크 메모리 사용량이 75.5 GB로 보고되었습니다. Surface Laptop Ultra는 최대 128 GB의 unified memory(CPU와 GPU가 공유하는 물리 메모리)를 갖춘 구성이지만, 그 전체를 모델만 사용할 수 있는 것은 아닙니다. OS나 애플리케이션, 추론 런타임, 그리고 대화의 문맥을 유지하는 KV cache도 메모리를 사용합니다. 따라서 '256K 컨텍스트를 다룰 수 있다'는 것과 '어떤 PC에서도 여유롭게 구동된다'는 것은 별개의 문제입니다.

Microsoft의 기술 기사는 KV cache가 처리된 토큰의 attention state(주의 메커니즘의 내부 상태)를 유지한다고 설명합니다. 에이전트가 파일이나 도구의 결과를 읽어와 컨텍스트가 늘어나면, 메모리 사용량과 다음 요청을 처리하는 부하도 높아진다고 합니다. 즉, 긴 컨텍스트를 다룰 수 있다는 것과 항상 경쾌하게 응답할 수 있는 것은 같지 않습니다.

GitHub의 Project HydraFusion은 여러 모델을 조합하여 작업을 해결하는 GitHub Copilot의 오케스트레이션 기능입니다. 공식 문서에서는 HydraFusion이 research preview(연구 프리뷰)로 소개되며, 작업별로 모델이나 실행 패턴을 선택할 수 있는 메커니즘이 설명되어 있습니다.

로컬 모델 활용에 대해서는 수동으로 모델을 선택하는 기능과 Copilot이 로컬/클라우드 실행 환경을 결정하는 **자동 라우팅(automatic routing)**을 구분하여 이해해야 합니다.

GitHub Changelog에 따르면, GitHub Copilot CLI v1.0.94-0 이후 버전부터는 /model로 현재 구동 중인 Ollama가 제공하는 지원 모델을 찾을 수 있습니다. 이 작업을 통해 모델이나 Ollama 자체를 설치하는 것이 아니라, 사전에 Ollama와 모델을 준비해 두어야 합니다. 사용자는 provider와 endpoint를 확인한 후, 현재 세션에서 사용할지 아니면 추가만 할지를 선택합니다. 대상 모델에는 tool calling과 streaming 지원도 필요합니다. 이는 사용자가 모델을 선택하는 메커니즘이며, Copilot이 작업별로 자동으로 분배하는 기능은 아닙니다.

반면, GitHub Changelog에서는 로컬 모델을 사용하는 지능형 라우팅(intelligent routing)도 발표했지만, 같은 공지에서는 제공 시기를 '후속 공지를 기다려 달라'고 했습니다. Microsoft Command Line의 기사에서는 Copilot의 Auto가 작업의 context나 cache state를 고려하여 로컬과 클라우드를 분배하는 구상을 설명하며, 10월 말까지 제공 예정임을 언급했습니다. Windows Experience Blog는 Copilot 앱, CLI, Visual Studio Code용 하이브리드 인텔리전스를 10월 후반에 experimental preview(실험적 프리뷰)로 제공할 예정이라고 했습니다.

따라서, 2026년 10월 8일 시점에서는 CLI에서 로컬 Ollama 모델을 수동으로 선택하는 경로는 이용 가능하지만, Copilot이 로컬/클라우드를 자동으로 분배하는 기능은 향후 제공 예정입니다. 이들은 별개의 기능입니다. 또한, 로컬 모델을 선택했다고 해서 자동으로 오프라인이 되거나 telemetry이 비활성화되는 것은 아닙니다. 이곳을 구분한 후, HydraFusion에 의한 자동 라우팅이 무엇을 바꿀지 생각해 보겠습니다.

HydraFusion의 공식 설명에서는 하나의 작업에 대한 실행 패턴으로 Single, Cascade, Critique 세 가지가 제시되어 있습니다.

GitHub는 평가 기사에서 TerminalBench 2.1, DeepSWE, 사내 CheckpointBench를 사용한 오프라인 평가 결과도 보여주었습니다. 하지만 이것들은 평가 당시의 모델 구성, 워크플로우, 벤치마크, 가격 가정에 의존하는 결과입니다. 특정 개발자의 작업에서도 같은 품질이나 비용 절감이 된다고 해석해서는 안 됩니다. GitHub 자체도 연구 프리뷰를 통해 실제 개발자 워크로드에서의 검증을 진행한다는 입장을 보이고 있습니다.

여기에 디바이스 내 모델이 추가되면, 오케스트레이션의 선택지는 '어떤 모델을 사용할지'에만 국한되지 않습니다. 어떤 모델을, 어떤 컴퓨팅 환경에서, 어떤 순서로 사용할지가 설계 대상이 되는 것입니다.

지금까지도 로컬 LLM을 시험해 볼 수는 있었습니다. 하지만 로컬 모델은 많은 경우에 '개발자가 직접 실행 환경을 준비하고, 모델을 선택하여 애플리케이션과 연결하는 것'이라는 인상이 강했습니다. 이번 발표를 통해 크게 느낀 점은 모델의 성능뿐만 아니라, GitHub Copilot 같은 개발자 도구가 실행 위치까지 판단하는 구상까지 나왔다는 것입니다.

이것이 잘 구현된다면, PC는 단순히 클라우드 AI의 클라이언트가 아니라, 개발 워크플로우의 일부를 담당하는 추론 거점이 될 수 있습니다. 예를 들어, 즉시 응답받고 싶은 작은 작업이나 데이터를 장치 외부로 내보내지 않고 처리하고 싶은 작업은 로컬에서, 더 복잡한 추론이나 높은 성공률이 필요한 작업은 클라우드에서 분담할 수 있습니다.

물론, 어떤 입력을 어떤 모델에 넣을지, 모델 전환을 사용자가 어느 정도 제어할 수 있는지, 라우팅 판단 이유를 어떻게 관찰할 수 있는지는 실제 프리뷰에서 확인해야 합니다. 이번 발표만으로는 개별 작업의 라우팅 조건이나 실패 시 어떻게 폴백(fallback, 대체 경로로 전환)할지까지 확정되었다고는 할 수 없습니다. 여기부터는 공개된 구상을 읽고 제가 고안한 추론입니다.

로컬 모델에 대해 이야기하자면, '클라우드에 보내지 않으니 안심', '로컬이라 무료'와 같은 단순한 기대를 품게 될 때가 있습니다. 하지만 실제로는 조금 복잡합니다.

로컬 추론에도 하드웨어, 메모리, 전력 및 냉각, 모델 다운로드나 업데이트에 필요한 비용이 발생합니다. 게다가 모델이 PC 안에서 돌아가더라도, 에이전트가 필요로 하는 파일 조작이나 셸 명령어, 외부 서비스 연결까지 자동으로 로컬로 제한되지는 않습니다. 추론을 어디서 할지, 도구를 어디서 실행할지, 무엇에 접근하게 할지는 별개의 경계입니다.

Microsoft의 기술 기사에서는 모델 선택, 추론, 도구 실행에는 서로 다른 경계가 있으며, 로컬 추론을 사용해도 세션 전체가 오프라인이 되는 것은 아니라고 설명합니다. 에이전트가 네트워크를 사용할 가능성도 남아있기 때문에, 모델 실행과 도구 실행을 분리해서 생각하고 파일, 네트워크, 자격 증명(credential)에 대한 접근을 별도로 제어해야 합니다.

즉, 로컬인지 클라우드인지라는 라벨만으로 데이터 보호나 보안이 결정되는 것은 아닙니다. 중요한 것은 어떤 데이터가, 어떤 처리 경로를 거쳐, 어떤 권한으로 도구를 작동시키는지 설명할 수 있는 것입니다. Windows Experience Blog는 에이전트가 접근할 수 있는 파일이나 네트워크를 제어하는 메커니즘으로 Microsoft Execution Containers (MXC)를 소개했습니다. 모델의 실행 장소와 도구의 접근 제어는 별개로 생각해야 한다는 것이 이번 발표를 읽고 제가 받은 인상입니다.

양자화(Quantization)를 통해 모델의 풋프린트(footprint, 저장 공간 점유율)를 작게 만들 수 있지만, 크기의 숫자만으로 개발자의 경험을 평가할 수는 없습니다. 코드베이스를 읽게 했을 때 얼마나 기다리는지, 도구 호출을 올바르게 구성할 수 있는지, 작업을 끝까지 완료할 수 있는지가 중요합니다.

컨텍스트 길이(Context length)나 메모리 제약을 포함하여, 개발자 자신의 작업에서 어떻게 작동하는지 확인해야 합니다. '256K 지원'은 긴 문맥을 처리할 수 있음을 보여주지만, 항상 경쾌하게 응답할 것이라는 보장은 아닙니다.

이 때문에 개발자용 AI에서는 모델 크기뿐만 아니라, 작업 완료율, 응답 시간, 최대 메모리 사용량, 도구 활용 성공률도 확인하고 싶습니다. 특히 에이전트형 작업의 경우, 첫 답변이 빨라도 실패 후 다시 시도하면 전체 경험이나 비용은 나빠질 수 있습니다. 로컬 모델을 '작동했다'로 끝내는 것이 아니라, 우리 자신의 작업에 어떻게 도움이 되는지 평가해야 합니다.

라우팅이 자동화될수록, 모델 단독의 벤치마크뿐만 아니라 라우터가 포함된 시스템 전체의 평가가 필요합니다. 이것은 저에게 이번 발표에서 가장 큰 설계상의 변화입니다.

예를 들어, 동일한 수정 작업을 로컬 모델, 클라우드 모델, HydraFusion 같은 오케스트레이션(orchestration)을 거쳐 시도한다고 가정해 봅시다. 비교하고 싶은 것은 실제로 선택된 경로, 모델 호출 횟수, 리뷰나 재시도에 걸린 시간입니다. 게다가 답변 품질 외에도 차이점의 타당성이나 테스트 성공 여부, 불필요한 변경 사항의 유무도 확인하고 싶습니다. 사용자가 수정을 받아들였는지 여부까지 추적하고 싶습니다.

개인적으로 시도한다면, 먼저 작은 작업 몇 가지를 골라 로컬 단독과 클라우드 이용으로 결과를 비교하는 것만으로도 충분한 배움이 있습니다. 조직에 도입한다면, 기밀 정보 처리나 네트워크 접근, 사용 비용을 평가합니다. 장치 메모리 조건이나 장애 시 대체 경로, 감사 로그(audit log)도 확인합니다.

자동 라우팅이 똑똑해질수록 사용자에게 보이지 않는 판단도 늘어납니다. 그 판단을 블랙박스로 두지 않고, 필요한 범위에서 설명하고 관측할 수 있는지가 도입 후의 신뢰를 좌우한다고 생각합니다.

이러한 변화는 AI 기능을 만드는 개발자와, AI를 매일 사용하는 개발자 모두에게 영향을 미칠 것 같습니다.

애플리케이션에 AI를 통합할 경우, 특정 클라우드 모델 API만을 전제로 하기보다는 추론(inference) 위치를 바꿀 수 있는 경계(boundary)를 의식하는 기회가 늘어날 것 같습니다. 모든 것을 추상화하여 범용화할 필요는 없지만, 프롬프트, 툴, 데이터 처리, 모델 호출, 결과 평가를 분리해 두면 로컬 모델을 추가했을 때 재검토하기 쉬워집니다.

또한, 모델 선택을 애플리케이션 외부에 맡긴다면 '모델에 무엇을 전달해야 하는지', '로컬에서 클라우드로 전환되는 조건을 어떻게 처리할 것인지'라는 요구사항도 설계에 포함됩니다. 프라이버시 요구가 강한 처리는 단순히 로컬 모델을 고르는 것을 넘어, 클라우드 폴백(fallback)을 허용할지, 사용자에게 확인할지까지 결정해야 할 것입니다.

개발자 입장에서는 앞으로 '어떤 모델이 사용 가능한가'뿐만 아니라, '내 PC에서 어느 정도의 로컬 처리가 가능한가'도 작업 환경의 일부로 의식하게 될 것 같습니다. 다만, 모든 개발자가 RTX Spark와 같은 하드웨어를 가지고 있는 것은 아닙니다. 이번 데모나 발표를 일반적인 Windows PC에서도 동일한 경험이 이미 가능하다는 의미로 확대해서 해석해서는 안 됩니다.

실제로 이용할 때는 대응하는 하드웨어 및 소프트웨어 요구사항, 모델 획득 방법 등을 확인하고 싶습니다. 라우팅 제어나 데이터가 클라우드로 전송되는 조건, 샌드박스 설정 외에도 사용 가능한 지역이나 플랜도 확인합니다. 기능이나 대상 범위는 변경될 수 있으므로, 업무 데이터를 다룰 때는 조직의 규칙과 제품의 최신 문서를 참조해야 합니다.

지금 당장 할 수 있는 것은 특별한 GPU를 사는 것이 아니라, 손안의 개발 환경과 업무상의 제약을 정리하는 것입니다. 단말기의 메모리에 얼마나 여유가 있는지, 기밀 데이터를 어떤 경로로 보낼 수 있는지 파악해 두면, 선택지가 늘어났을 때 적용 가능 여부를 판단하기 쉬워집니다.

MAI Code 1.1 Flash의 로컬 실행과 HydraFusion의 Windows 장치 내 모델 지원은 AI를 '클라우드에 있는 모델을 호출하는 기능'에서 '태스크에 따라 실행 위치나 모델 조합을 선택하는 메커니즘'으로 확장되는 움직임이라 흥미롭습니다.

다만, 작성 시점인 2026년 10월 8일 기준으로 HydraFusion과 Windows 상의 로컬 모델을 결합한 경험은 발표된 예정과 실제 제공 상황을 구분해서 이해할 필요가 있습니다. 또한, 로컬 모델 사용이 항상 오프라인이라는 것을 의미하거나 데이터가 전혀 클라우드로 전송되지 않는다는 것을 의미하지는 않습니다.

그럼에도 불구하고, 개발자가 고민해야 할 질문은 확실히 늘어나고 있습니다. 모델의 성능뿐만 아니라 실행 위치나 메모리, 레이턴시(latency), 비용도 평가 축이 됩니다. 데이터의 경계나 툴의 권한, 실패 시 경로, 자신의 업무에서의 품질까지 고려하고 싶습니다. AI에게 어디서 생각하게 할지가 아키텍처와 개발 경험의 일부가 되어갈 것이라고 생각합니다.

저는 로컬과 클라우드 중 어느 한쪽을 정답으로 하고 싶은 것이 아닙니다. 태스크의 성격이나 제약에 맞춰 사용하는 장소를 다시 선택할 수 있다는 것에 가치가 있습니다. 우선 발표된 프리뷰의 세부 내용을 기다리면서, 모델 자체보다는 모델과 실행 환경을 결합한 시스템으로서 평가하는 시각을 가지고 싶습니다🧭