클라이언트 사이드 웹 AI: 내장 AI API, 라이브러리, 런타임

두 가지 방식

클라이언트 사이드 AI는 서버 없이 사용자 기기에서 추론한다. 방법은 둘이다. 어느 쪽을 클라이언트에 둘지, 서버와 어떻게 나눌지는 웹 AI 플랫폼 고르기에서 다룬다.

flowchart LR
  app["웹 앱"]
  builtin["내장 AI API"]
  lib["라이브러리<br/>(Transformers.js 등)"]
  rt["런타임<br/>(Wasm / WebGPU / WebNN)"]
  bm["브라우저가 관리하는 모델"]
  am["앱이 내려받은 모델"]
  hw["사용자 하드웨어 (CPU / GPU / NPU)"]
  app --> builtin --> bm --> hw
  app --> lib --> rt --> am --> hw

내장 AI (Built-in AI)

브라우저가 작은 기반 모델을 들고 있고, 과제별 고수준 API로 노출한다. Chrome은 Gemini Nano와 과제별 전문 모델을, Microsoft Edge는 자체 모델을 쓴다. 개발자 입장에서는 다른 브라우저 기능처럼 부르고 결과를 받으면 끝이다.

Chrome 내장 AI API 상태 (2026년 10월 기준)

• Writer·Rewriter는 Chrome 137148, Proofreader는 Chrome 141145에 오리진 트라이얼을 거쳤고, 지금은 chrome://flags(#writer-api, #rewriter-api, #proofreader-api)로 시험한다.
• MDN 기준으로 이 API들은 실험적(Experimental)이고 Baseline이 아니다. 사실상 Chromium 계열 전용이므로 대체 경로가 필수다.
• 상태는 자주 바뀐다. 쓰기 전에 Built-in AI API 상태표를 다시 확인한다.

하드웨어 요건 (Chrome)

• 데스크톱 전용. Windows 10·11, macOS 13 이상, Linux, Chromebook Plus의 ChromeOS. Android·iOS의 Chrome은 지원하지 않는다.
• 모델을 받을 볼륨에 22GB 이상 여유 공간. 내려받은 뒤 여유 공간이 10GB 아래로 떨어지면 모델이 지워지고, 조건이 회복되면 다시 받는다.
• GPU는 VRAM 4GB 초과, 또는 CPU는 RAM 16GB 이상·4코어 이상.
• 첫 다운로드에만 비종량제 네트워크가 필요하다. 이후 추론은 오프라인으로 되고, 데이터는 Google이나 제3자에게 가지 않는다.
• 모델 현재 크기와 상태는 chrome://on-device-internals에서 본다.

쓰는 순서: 확인 → 사용자 활성화 → 생성 → 실행

// 1. 기능 감지와 가용성 확인
if (!('Summarizer' in self)) return showFallback();
const availability = await Summarizer.availability();
// "unavailable" | "downloadable" | "downloading" | "available"
if (availability === 'unavailable') return showFallback();
 
// 2. 모델을 받아야 하면 사용자 활성화(클릭·키 입력) 뒤에만 create() 가능
if (availability !== 'available' && !navigator.userActivation.isActive) return;
 
// 3. 생성: 다운로드 진행률을 사용자에게 알린다
const summarizer = await Summarizer.create({
  type: 'key-points', format: 'markdown', length: 'short',
  monitor(m) {
    m.addEventListener('downloadprogress', (e) => updateProgress(e.loaded));
  },
});
 
// 4. 실행
const summary = await summarizer.summarize(reviewsText);

• availability()에는 prompt()에 쓸 옵션(언어, 모달리티)을 똑같이 넘긴다. 모델마다 지원 언어·모달리티가 다르기 때문이다.
• create()에 AbortSignal을 넘기면 세션을 정리할 수 있다. 옵션은 생성 후 못 바꾸니, 바꾸려면 새로 만든다.
• 기본적으로 최상위 창과 같은 출처 iframe에서만 쓸 수 있다. 다른 출처 iframe은 Permissions Policy로 허용한다(<iframe allow="summarizer">).
• TypeScript 타입은 @types/dom-chromium-ai 패키지에 있다.

Prompt API: 세션과 구조화 출력

const session = await LanguageModel.create({
  initialPrompts: [{ role: 'system', content: '블로그 제목 도우미다. 제목 3개를 JSON으로 낸다.' }],
});
 
const schema = { type: 'object', properties: { titles: { type: 'array', items: { type: 'string' } } } };
const result = await session.prompt(blogContent, { responseConstraint: schema });
const { titles } = JSON.parse(result);

• responseConstraint에 JSON 스키마나 정규식을 넘기면 출력 모양을 강제한다. 스키마도 컨텍스트 창을 쓰며, session.measureContextUsage()로 잴 수 있다.
• 웹에서는 temperature·topK를 기본으로 노출하지 않는다. 숫자 파라미터가 모델마다 같은 뜻을 갖지 않기 때문이다. 오리진 트라이얼의 samplingMode(most-predictable ~ most-creative)가 그 대안이다.
• 시스템·사용자 프롬프트 나누는 법은 시스템 프롬프트 설계 패턴에 있다.

내장 AI의 한계

RAG, 에이전트, 복잡한 워크플로가 필요하면 라이브러리 런타임이나 서버 추론으로 간다.

라이브러리로 커스텀 모델 돌리기

• Transformers.js: 감성 분석·개체명 인식·요약·임베딩 같은 익숙한 pipeline으로 Hub의 모델을 바꿔 끼우며 실험한다.
• TensorFlow.js: 이미지 분류·객체 탐지·포즈 추정의 사전 학습 모델이 많고 API가 안정적이다. Node.js에서도 돈다.
• WebLLM: OpenAI 호환 형태의 API라 서버 모델과 하이브리드로 바꾸기 쉽다. 클라이언트에서 대화형·에이전트 기능을 원할 때 고른다.
• MediaPipe: 전처리 → 추론 → 후처리를 다 맡고 중급 기기에서도 실시간으로 돈다. 자체 C++ 런타임을 쓴다.
• ONNX Runtime Web: PyTorch·TensorFlow·scikit-learn에서 ONNX로 내보낸 모델을 그대로 올린다.

이 분야의 추천 라이브러리는 빨리 바뀐다. 고를 때마다 유지 상태를 확인한다.

런타임

라이브러리는 브라우저의 저수준 실행 백엔드로 연산을 하드웨어에 매핑한다. 런타임은 성능, 메모리, 수치 안정성, 기기 호환성을 좌우한다.

정리

• 내장 AI는 설정 없이 공짜로 좁은 기능을 붙이는 길이고, 라이브러리는 모델을 고르는 대신 운영을 떠안는 길이다.
• Chrome에서 번역·언어 감지·요약은 138부터, Prompt API는 148 전후로 웹 정식 전환이 진행 중이다. 쓰기·고쳐 쓰기·교정은 아직 플래그 단계다.
• 내장 AI는 데스크톱 전용이고 Baseline이 아니다. 기능 감지 → availability() → 사용자 활성화 → create() 순서와 서버·비AI 대체 경로를 항상 갖춘다.
• 런타임은 WebGPU를 우선하되 Wasm으로 떨어질 수 있게 만든다.

관련 노트: 웹 AI 플랫폼 고르기, AI 기능의 UX 패턴, 시스템 프롬프트 설계 패턴, WebGL과 셰이더: 브라우저가 GPU로 그리는 방식