이 기사에 대하여

연재 「Windows 로컬 AI 실전 입문」의 **제5회(최종회)**입니다. 제1회에서 7개 단어로 기술 지도를 구성하고, 제2회에서 ONNX Runtime의 줄기를 일반적인 ML로 살펴보았으며, 제3회에서 SLM을 얹고, 제4회에서 Windows ML에 EP(Execution Provider) 자체 관리를 맡기며, Phi Silica의 최소 코드까지 도달했습니다.

여기까지 오면서 "4개의 입구"(Windows AI APIs / Foundry Local / Windows ML / ORT 직결)는 단체로서는 갖춰졌습니다. 하지만, 실제 앱에 통합하는 단계가 되면 입구를 하나로 고정할 수 없다는 문제가 남습니다. 동일한 앱에 OCR · 요약 · 독자적 분류 · 음성 받아쓰기가 공존한다면, 그것들을 전부 Phi Silica로만, 혹은 전부 Windows ML로만 몰아넣을 수는 없습니다.

본 기사는 이 "입구를 하나로 고정할 수 없다"는 현실에 정면으로 대응합니다. **주축은 태스크 라우팅(Task Routing)**입니다. 태스크 종류별로 4개의 입구(+클라우드)를 할당하는 설계입니다. 코드는 몇 줄의 스니펫 정도로 제한하고, 판정표와 체크리스트를 중심으로 다룹니다.

대상 독자는 제1회~제4회에서 개별 입구를 이해하고, 현재 실제 앱에 구현하는 단계에서 여러 태스크를 처리하는 방법 때문에 고민하고 있는 개발자입니다. 코드는 C# / Python의 최소 스니펫을 제시하며, 설계 판단을 중심으로 설명합니다.

0. 시작하며: 통합 단계에서 남는 질문

연재를 통해 지금까지 4개의 입구는 단체로서는 갖춰졌습니다.

입구	담당	등장한 회차
Windows AI APIs (Phi Silica 등)	기성 AI 기능 (Copilot+ PC 전제)	제1회 §8 / 제4회 §4
...

통합 단계의 질문은 여기서부터 시작됩니다.

동일한 앱에 OCR · 요약 · 독자적 분류 · 음성 받아쓰기 · 장문 요약이 공존한다면, 각각을 어떤 입구로 흘려보낼 것인가. 전부를 하나의 입구로 몰아넣을 수 있는가.

공식적인 답은 "몰아넣을 수 없다, 조합하라"입니다. 「Microsoft Foundry on Windows overview」 본문은 3단계 우선순위를 제시한 후 다음과 같이 적고 있습니다.

Your app can also use a combination of all three of these technologies.

(일본어 번역: "당신의 앱은 이 세 가지 기술 모두의 조합을 사용할 수도 있습니다.")

하지만 조합 방법에 대한 지침은 3개의 페이지에 흩어져 있습니다. /windows/ai/overview는 3단계 우선순위를, /windows/ai/cloud-ai는 local vs cloud의 트레이드오프(Trade-off)를, /azure/architecture/ai-ml/guide/choose-ai-model은 model routing strategy를 다룹니다. 본 기사는 이것들을 **태스크 라우팅(Task Routing)**이라는 하나의 축으로 묶습니다.

본 기사의 구성은 3부입니다. 제I부(§1~§3)에서 판정 축(태스크 종류 · 3단계 우선순위 · 로컬/클라우드)을 세우고, 제II부(§4~§5)에서 구현상의 전제(Foundry Local/Azure의 "같은 모습", 단말 능력 검출)를 확정하며, 제III부(§6~§8)에서 배포 · 폴백(Fallback) 설계와 최종 판정표로 마무리합니다.

제I부: 판정 축 세우기

제1회의 지도에 「태스크」 축을 더하다

1. 제1회에서는 7개 단어를 층(Layer)으로 나열했습니다. 실제 앱 통합에서는 그 층에 태스크 종류라는 가로축을 하나 추가합니다.

태스크 종류	후보 입구 (후술할 3단계 우선순위에 따라 나열)	근거
OCR	Windows AI APIs (TextRecognizer) / 없을 경우 Foundry Local의 VLM 계열	overview의 태스크 표
이미지 설명 · 전경 추출 · 해상도 향상	Windows AI APIs (Copilot+ PC 필수)	상동
단문 LLM (요약 · 채팅 · 리라이트)	Phi Silica (Copilot+ PC) / Foundry Local / Azure OpenAI	상동 + windows-ai-comparison
음성 받아쓰기 (STT)	Foundry Local (Whisper) / Windows SDK의 SpeechRecognizer	상동
독자적 분류 · 회귀 (자체 ONNX)	Windows ML / ORT 직결	제2회~제4회
장문 요약 · 고도 추론	Foundry Local의 대형 모델 / Azure OpenAI	cloud-ai
시맨틱 검색 (Semantic Search)	Windows AI APIs (App Content Search, Copilot+ PC)	overview의 태스크 표

여기에 제1회의 「층 × 태스크」 구도가 형성됩니다. 입구는 층(Layer)의 이야기이고, 태스크는 가로축의 이야기이며, 양자는 직교합니다. 따라서 「전부를 하나의 입구로」라는 요구는 애초에 층 위의 서로 다른 위치를 한 점으로 뭉개버리라는 요구이며, 무리가 따를 수밖에 없습니다.

2. 공식의 3단계 우선순위를 「라우팅 판단」으로 다시 읽기

/windows/ai/overview

의 3단계 우선순위는 원문(overview)에서 다음과 같이 기술되어 있습니다.

• Check if the built-in Windows AI APIs cover your scenario and you're targeting Copilot+ PCs.
• If Windows AI APIs don't have what you need, or you need to support Windows 10 and later, consider Foundry Local for LLM or voice-to-text scenarios.
• If you need custom models, ..., Windows ML gives you the flexibility ...

(일본어 번역: "1. 내장된 Windows AI APIs가 귀하의 시나리오를 커버하는지, 그리고 Copilot+ PC를 타겟으로 하는지 확인하십시오. 2. Windows AI APIs에 필요한 기능이 없거나 Windows 10 이상을 지원해야 하는 경우, LLM 또는 음성-텍스트 변환 시나리오를 위해 Foundry Local을 검토하십시오. 3. 커스텀 모델이 필요한 경우, Windows ML이 유연성을 제공합니다.")

이는 「앱 전체의 입구 선택」이 아니라, 태스크마다 위에서부터 순서대로 적용되는지 확인하여 가장 먼저 해당되는 입구를 채택한다는 라우팅 (Routing) 판단 절차로 읽을 수 있습니다. 이 절차를 판정 플로우로 바꾸면 다음과 같습니다.

핵심은 이것을 「앱당 1회」가 아니라 「태스크당 1회」 실행하는 것입니다. 동일한 앱에 OCR, 독자적 분류, 장문 요약이 있다면, 3번 실행하여 3개의 서로 다른 입구가 선택되어도 무방합니다.

「Windows ML을 중심으로 세운다」의 의미: 연재 전체에서 Windows ML을 중심으로 불러왔으나, 이는 「자체 ONNX를 다루는 태스크의 중심」이라는 의미입니다. 앱 전체의 입구를 Windows ML로 기울인다는 의미가 아닙니다. 태스크마다 3단계를 실행한 결과, 자체 ONNX 태스크가 많다면 Windows ML 중심이 됩니다. OCR과 기성 LLM만 있는 앱이라면 Windows ML은 애초에 등장하지 않습니다.

3. 로컬/클라우드 축을 겹치기: 판정의 2단계

3단계 우선순위에서 「Foundry Local」이 선택된 태스크에는 추가적인 2단계 질문이 있습니다. 동일한 OpenAI 호환 API 중에서, 로컬에서 구동할 것인지 아니면 클라우드 (Azure OpenAI / Foundry)를 호출할 것인지의 문제입니다.

/windows/ai/cloud-ai

의 트레이드오프 (Trade-off) 표는 이 2단계 판단 재료를 일람화하고 있습니다 (cloud-ai).

축	로컬(Local) 쪽으로 기울이는 이유	클라우드(Cloud) 쪽으로 기울이는 이유
지연 시간 (Latency)	단말기 내에서 완결, 네트워크 왕복 없음	(열세)
...
/windows/ai/windows-ai-comparison

의 "Other" 절은 양자의 관계를 한 문장으로 요약하고 있습니다 (windows-ai-comparison).

Microsoft Foundry — REST API를 통한 클라우드 호스팅 프론티어 모델 (GPT-4o, DALL-E 등).

온디바이스(On-device)/클라우드 폴백(Fallback)을 위해 Foundry Local과 결합하십시오.

(원문: Combine with Foundry Local for on-device/cloud fallback.)

공식 문서에서 "combine(결합)과 fallback(폴백)"이라고 명시하고 있는 이상, 로컬/클라우드는 어느 한쪽을 선택하는 것이 아니라 결합하는 것이 기본값입니다. 다만 본 기사의 범위는 로컬 측의 하이브리드 설계이며, 클라우드 측의 구축(인가·과금·배포·모니터링)은 다루지 않습니다. 로컬 측에서 클라우드의 "동일한 인터페이스(Same Face)"를 어떻게 활용할 것인가만을 다음 절에서 다룹니다.

제II부: 구현상의 전제

4. Foundry Local과 Azure OpenAI의 "동일한 인터페이스" 활용하기

로컬/클라우드 전환 비용을 크게 좌우하는 것은 코드 경로(Code path)가 두 계통으로 나뉘는지 여부입니다. LLM/SLM 텍스트 계열에 관해서 Microsoft는 양자를 **OpenAI SDK 서피스(Surface)**로 집약하고 있으며, 코드 경로는 사실상 한 계통으로 충분합니다.

4.1 Foundry Local 측: 앱 내에 OpenAI 호환 REST가 구축됨

Foundry Local architecture overview의 "Optional REST API" 절은 다음과 같이 기술하고 있습니다.

For scenarios that require HTTP-based communication, the Foundry Local SDK can start an optional OpenAI-compatible REST endpoint within your application process.

(번역: "HTTP 기반 통신이 필요한 시나리오의 경우, Foundry Local SDK는 애플리케이션 프로세스 내에서 선택적인 OpenAI 호환 REST 엔드포인트를 시작할 수 있습니다.")

즉, Foundry Local SDK는 앱 내에 OpenAI 호환 REST 엔드포인트를 세울 수 있습니다. HTTP 통신이 필요 없다면 SDK 네이티브 호출로 충분하지만, 필요하다면 동일한 프로세스 내에서 REST 통신이 가능합니다.

또한 해당 페이지의 "Hardware abstraction" 절:

Foundry Local abstracts the underlying hardware so your application code doesn't need to detect devices or select execution providers.

(번역: "Foundry Local은 기반 하드웨어를 추상화하므로, 애플리케이션 코드가 장치를 감지하거나 실행 프로바이더(Execution Provider, EP)를 선택할 필요가 없습니다.")

하드웨어 추상화까지 수행해 줍니다. Windows 상에서는 WinML이 플러그인 획득·등록·드라이버 호환 협상을 대신 처리하며, Linux/macOS에서는 SDK가 EP 플러그인을 동봉합니다. 앱 측에서는 EP를 의식할 필요가 없습니다.

4.2 Azure OpenAI 측: 동일한 OpenAI SDK로 호출 가능

Azure Foundry SDKs and Endpoints는 OpenAI SDK를 Azure 측의 Foundry / OpenAI 모델에 그대로 사용할 수 있다고 명시하고 있습니다.

OpenAI SDK ... Latest OpenAI SDK models and features with the full OpenAI API surface, including embeddings.

즉 "Foundry Local과 Azure OpenAI 모두 OpenAI SDK로 호출할 수 있다"는 점이 성립합니다.

4.3 패키지 구성: Windows용은 Windows ML 통합 버전을 채택

Foundry Local SDK Reference의 설치 섹션에서는 Windows용과 Cross-Platform용으로 패키지를 구분하여 사용합니다.

타겟	C#	Python	JavaScript
Windows(권장)	Microsoft.AI.Foundry.Local.WinML + OpenAI	foundry-local-sdk-winml + openai	foundry-local-sdk-winml + openai
Cross-Platform	Microsoft.AI.Foundry.Local + OpenAI	foundry-local-sdk + openai	foundry-local-sdk + openai

공식 설명은 다음과 같습니다.

The Windows package integrates with the Windows ML runtime — it provides the same API surface area with a wider breadth of hardware acceleration.

(번역: "Windows 패키지는 Windows ML 런타임과 통합되어 있으며, 더 넓은 범위의 하드웨어 가속(Hardware Acceleration)과 함께 동일한 API 서피스(API Surface) 영역을 제공합니다.")

API 서피스는 동일하면서 하드웨어 가속의 폭이 넓어진 버전이 Windows용입니다. Windows 전용 앱이라 하더라도, 하이브리드 설계상 크로스 플랫폼(Cross-Platform) 요구사항이 없는 한 Windows용 패키지를 채택하는 것이 타당합니다.

4.4 코드 경로(Code Path): 엔드포인트 교체로 전환 가능

위 내용을 바탕으로, LLM 텍스트 계열의 로컬/클라우드(local/cloud) 전환은 다음과 같이 작성할 수 있습니다 (Python 최소 예시).

from openai import OpenAI
# 로컬(Foundry Local이 구축한 OpenAI 호환 REST)
local_client = OpenAI(
...

use_cloud 전환 조건은 §6의 폴백(Fallback) 설계에서 다룹니다. 중요한 점은 summarize 함수의 본체가 하나뿐이라는 것입니다. 두 가지 코드 경로를 가질 필요가 없습니다.

4.5 "동일한 모습"이 성립하는 범위

단, "동일한 모습"은 OpenAI 호환 API의 범위 내에서만 성립합니다. 이를 도식화하면 다음과 같습니다.

즉, 동일한 애플리케이션 내에 최소한 다음 두 가지 계통이 남게 됩니다.

• OpenAI 호환 존(Zone): Foundry Local ↔ Azure OpenAI 전환만으로 해결 가능 (1개 함수)
• WinRT / Windows ML 존(Zone): Windows AI APIs와 자체 ONNX는 별도의 API로 작성

하이브리드 설계 관점에서는, LLM 텍스트 계열을 최대한 OpenAI 호환 존에 맞추고, OCR·이미지 계열·자체 ONNX는 별도의 레인(Lane)으로 관리한다는 정리로 이어집니다.

ExecutionProviderCatalog로 라우팅 조건 획득

5. 단말 능력 탐지: §2의 3단계 우선순위는 정적인 판정이었으나, 실제 애플리케이션에서는 동적인 단말 능력을 확인할 필요가 있습니다. Copilot+ PC가 아니라면 Phi Silica를 사용할 수 없으며, NPU 계열 EP(Execution Provider)를 사용할 수 없다면 자체 ONNX를 CPU EP로 흘려보낼 수밖에 없습니다.

Microsoft는 이를 프로그래밍 방식으로 가져올 수 있는 API를 제공합니다.

ReadyState

5.1 EP 목록 및 Install Windows ML execution providers는, ExecutionProviderCatalog.FindAllProviders()를 통해 호환 가능한 EP의 전체 열거와 ReadyState 획득이 가능하다고 명시되어 있습니다.

var catalog = ExecutionProviderCatalog.GetDefault();
foreach (var provider in catalog.FindAllProviders())
{
...

ReadyState는 "설치됨(Installed)", "미설치(Uninstalled, 다운로드 필요)" 등을 반환합니다. 이를 시작 시점에 한 번 가져와서 라우팅(Routing) 조건으로 유지합니다.

5.2 설치된 EP의 버전 획득

Check execution provider versions에 따르면, PackageId.Version이 null이면 미설치 상태이며, null이 아니면 버전을 가져올 수 있습니다.

if (provider.PackageId != null) {
var v = provider.PackageId.Version;
Debug.WriteLine($"Version: {v.Major}.{v.Minor}.{v.Build}.{v.Revision}");
...

각 EP에는 최소 드라이버 요구 사항이 있으며(제1회 §7에서 언급), 예상 하한선 미만일 경우 폴백(Fallback) 대상이 됩니다.

5.3 Copilot+ PC 판정의 실용적 대체

Microsoft는 "Copilot+ PC 여부"를 직접 판정하는 단일 API를 강조하고 있지는 않지만, accelerate-ai-models의 Silicon-to-EP 매핑을 통해, NPU 계열 EP(QNN / OpenVINO / VitisAI) 중 어느 하나라도 ReadyState에서 사용 가능한지를 실용적인 대체 수단으로 사용할 수 있습니다.

bool hasNpuEp = catalog.FindAllProviders()
.Where(p => p.Name == "QNNExecutionProvider"
|| p.Name == "OpenVINOExecutionProvider"
...

단, Phi Silica 등 Windows AI APIs 측의 기능은 각 API가 독자적으로 "사용 가능 여부"를 반환합니다(§6.1). EP 검출은 자체 ONNX 경로의 능력 판정이며, Windows AI APIs의 능력 판정은 API 측에서 수행하는 것이 올바른 방향입니다.

5.4 ORT 측의 디바이스 정책 지정

EP를 하나씩 수동으로 지정하는 대신, ORT 측의 "디바이스 정책(Device Policy)"을 통해 목표 지향적으로 작성할 수 있습니다. Select execution providers의 예시(Python)를 보면 다음과 같습니다.

import onnxruntime as ort
options = ort.SessionOptions()
options.set_provider_selection_policy(
...

정책 값으로는 MAX_PERFORMANCE / MAX_EFFICIENCY / PREFER_NPU / MIN_OVERALL_POWER 등이 있습니다. 이는 "NPU가 있으면 NPU, 없으면 CPU 폴백"과 같은 자동 선택을 ORT에 위임하는 API입니다.

함의: 애플리케이션에서 EP를 명시적으로 지정하지 않더라도, 정책을 선언하는 것만으로 단말 성능에 따른 자동 전환이 성립합니다. 태스크 라우팅(Task Routing)과 조합한다면, "자체 ONNX 태스크에서 저전력 지향 시 → MAX_EFFICIENCY, 성능 지향 시 → MAX_PERFORMANCE"와 같이 태스크별로 정책을 나누어 사용할 수 있습니다.

제III부: 배포·폴백 설계와 최종 판정표

6. 폴백 설계: Microsoft 공식 참조 체인

하이브리드 설계의 핵심은 타겟 입구를 사용할 수 없을 때 무엇으로 전환(Fallback)할 것인가입니다. Microsoft는 이를 "개발자의 책임"이라고 명시하고 있습니다(accelerate-ai-models).

Windows ML handles execution provider distribution, not model optimization.
(Windows ML은 실행 제공자(EP)의 배포를 처리하며, 모델 최적화를 처리하지는 않습니다.)

You're still responsible for optimizing your models for different hardware.
(다양한 하드웨어에 맞춰 모델을 최적화하는 것은 여전히 개발자의 책임입니다.)

（일본어 번역: "Windows ML은 실행 프로바이더(Execution Provider)의 배포를 처리하지만, 모델의 최적화는 처리하지 않습니다. 서로 다른 하드웨어에 맞춰 모델을 최적화할 책임은 여전히 당신에게 있습니다.")

하지만 폴백 체인(Fallback Chain)의 참조 코드만은 공식 측에서 /windows/ai/windows-ai-comparison에 제공하고 있습니다. 이것이 그대로 최소 구현의 템플릿이 됩니다.

6.1 공식 폴백 체인 (LLM 텍스트 계열)

windows-ai-comparison의 참조 코드는 다음 순서로 나열되어 있습니다 (C#, 요약 인용).

// 1. Try Windows AI APIs (fastest — Copilot+ only)
var readyState = LanguageModel.GetReadyState();
if (readyState == AIFeatureReadyState.EnsureNeeded) {
...

3단계의 의미는 다음과 같습니다.

• Phi Silica 시도: GetReadyState로 능력 감지 → EnsureNeeded라면 설치, 그래도 NotSupportedOnCurrentSystem이라면 (= Copilot+ PC가 아니라면) 다음 단계로
• Foundry Local로 전환: 임의의 Windows 하드웨어에서 동작
• Azure OpenAI로 전환: OpenAI 호환 SDK의 엔드포인트(Endpoint) 전환을 통해, 단일 함수 상태를 유지

중요한 관찰: 이 폴백 체인은 §2의 3단계 우선순위와 동일한 순서입니다. 우선순위와 폴백 순서는 동일하며, 한쪽은 "채택 순서", 다른 한쪽은 "실패 시 대체 순서"로 읽히도록 설계되어 있습니다.

6.2 Phi Silica 고유 제약 사항 (Windows AI APIs 추가 주의 사항)

Phi Silica 튜토리얼에서 폴백 설계에 유효한 제약 사항 3가지를 추출합니다.

• Limited Access Feature (LAF): Phi Silica API는 LAF입니다. 언락 토큰을 획득해야 합니다 (LimitedAccessFeatures 클래스)
• 중국 내 이용 불가: Phi Silica features are not available in China.
• Windows 11 build 26100 (25H2) 이후

즉, "Copilot+ PC를 가지고 있더라도 Phi Silica를 사용할 수 없는 지역이나 빌드가 존재한다"는 상태가 존재합니다. 폴백 1단계에서 NotSupportedOnCurrentSystem이 반환될 수 있는 케이스는 NPU 미탑재 때문만은 아니다라는 뜻입니다. 설계상으로는 "GetReadyState의 반환값을 신뢰하고 그대로 다음 단계로 전환"하는 것만으로 충분하며, 원인 특정은 텔레메트리(Telemetry) 측에 맡기는 것이 현실적입니다.

6.3 Windows ML 시작 시퀀스 (자체 ONNX 경로)

LLM 텍스트 계열의 폴백이 §6.1이라면, 자체 ONNX 경로의 시작 시퀀스는 이와 병행하여 필요합니다. 제4회 §3에서 도입한 RegisterCertifiedAsync와 EnsureAndRegisterCertifiedAsync의 차이가 여기서 작용합니다 (initialize-execution-providers).

API	역할	사용 사례
RegisterCertifiedAsync()	이미 설치된 EP만을 등록 (다운로드 없음)	앱 시작 시의 고속 경로 · 오프라인 허용
EnsureAndRegisterCertifiedAsync()	필요 시 다운로드 후 등록 (시간 소요)	사용자 동의 후 초기 설정

권장 시퀀스는 2단계입니다.

6.4 배포 방식과 시작 시퀀스의 조합

제4회 §2에서 도입한 framework-dependent / self-contained는 시작 시퀀스와 조합하면 다음 표와 같습니다.

배포 방식	기동 시 확정되는 사항	권장 기동 시퀀스
framework-dependent	시스템 공유 ORT/동봉된 EP는 존재. 벤더 EP는 단말기에 따라 다름	RegisterCertifiedAsync로 가볍게 기동 → 필요 시에만 EnsureAndRegisterCertifiedAsync
self-contained	동봉된 EP(CPU / DirectML)는 확실히 동작함	DirectML을 초기 목표로 설정하고, 벤더 EP의 DL은 임의로 결정

self-contained 방식이라도 DirectML.dll이 동봉되어 있으므로 "GPU 추론이 항상 성립한다"고 생각하기 쉽지만, DirectML은 보수적 모드(제1회 §5)이며, 벤더 EP(Vendor EP)가 더 고성능인 경우가 많다는 점은 변하지 않습니다. self-contained는 "최소 보증 라인"을 높이는 선택이지, "최선을 취하는" 선택이 아닙니다.

7. 품질 평가의 위치 설정 (짧게)

제3회 §5/§7에서 "수치 일치에서 품질 평가로"라는 내용을 보류했습니다. 하이브리드 설계상, 여기에는 한 가지 위치 설정이 필요합니다.

태스크 라우팅(Task Routing)은 "동일한 품질 기준을 만족하는 입구를 선택하는" 설계가 아닙니다. 태스크마다 허용되는 품질의 폭은 다릅니다.

• OCR은 정답 판정을 엄격하게 내릴 수 있음 (문자 일치율)
• 요약·채팅은 확률적이며, 평가는 LLM-as-judge / golden set / 주관적 평가 중 하나를 사용
• 독자적 분류는 통상 ML 메트릭(정밀도·재현율)으로 측정 가능
• 장문 요약·추론은 수동 평가를 포함

즉, 폴백 체인(Fallback Chain)을 Phi Silica → Foundry Local → Azure OpenAI 순으로 구성할 경우, 이 3자는 품질이 동일하지 않다는 전제하에 설계해야 합니다. Azure 측이 프론티어 모델(Frontier Model, GPT-4 계열)로서 품질이 높고, 로컬 측은 소형 모델로서 품질이 낮은 비대칭 상황이 상시 존재합니다.

평가 설계 자체(LLM-as-judge를 만드는 법, golden set 유지, 메트릭 측정법)는 본 기사의 범위를 벗어나지만, 하이브리드 설계상으로는 "태스크마다 평가 기준을 별도로 가지고, 폴백 전후로 품질 요구사항을 완화할 수 있는가"를 가장 먼저 결정하는 것이 정석입니다. 이를 결정하지 않고 자동 폴백(Automatic Fallback)을 작성하면, "로컬에서 실패하여 클라우드로 넘어가는 순간 비용이 폭발하거나, 반대로 품질 저하를 감지하지 못하는" 사고가 발생하게 됩니다.

8. 요약: 태스크 라우팅을 하나의 판정표로

지금까지의 내용을 하나의 판정 플로우로 압축합니다.

이 5가지 질문을 앱에 탑재된 모든 태스크에 대해 적용하면, "어떤 태스크를 어떤 입구로 흘려보내고, 무엇으로 폴백시킬 것인가"가 일의적으로 결정되는 설계가 됩니다.