브라우저 내장 AI 지도 — Gemini Nano, 지금 뭘 쓸 수 있나

안녕하세요, 천상나타입니다.

지난 글에서 브라우저 내장 AI(Gemini Nano)를 실제 기능에 붙인 삽질기를 썼는데요, 그 뒤로 "이게 지금 어디까지 쓸 수 있는 상태인가"를 제대로 정리해둘 필요가 있어서 조사했습니다. 스펙이 빠르게 바뀌는 분야라, 2026년 11월 현재 기준으로 정리합니다 — 어떤 API가 쓸 수 있는지, 성능은 어느 정도인지, 그리고 실전에서 뭘 고르면 되는지까지요.

현재 지도: 쓸 수 있는 것 4개, 기다리는 것 3개

핵심부터: 본격적으로 쓸 수 있는 건 사실상 Chrome뿐입니다.

• Stable (웹, Chrome 데스크톱): Translator(번역), Language Detector(언어 감지), Summarizer(요약)는 Chrome 138부터, 자유 프롬프트를 던지는 Prompt API(LanguageModel)는 올해 Chrome 148부터 정식입니다
• Developer trial: Writer(문장 생성), Rewriter(다듬기), Proofreader(교정) — 아직 API가 바뀔 수 있어서 프로덕션에 넣으면 안 됩니다
• Edge: Prompt API가 개발자 프리뷰(Phi-4-mini 모델 사용). Canary/Dev 채널에서만
• Firefox·Safari: 미지원. Mozilla는 부정적(상호운용성 우려), WebKit은 반대(프라이버시·이식성) 입장입니다 — 크로스 브라우저 표준까지는 갈 길이 멉니다

주의할 함정 하나: 요즘 문서의 API는 LanguageModel 전역 객체입니다. 2024년 무렵 예제에 나오는 window.ai 모양은 옛 규격이라 그대로 복사하면 동작 안 해요(저도 이걸로 헤맸습니다).

const ok = await LanguageModel.availability();
if (ok === 'available') {
  const s = await LanguageModel.create();
  const out = await s.prompt('이 문단을 한 줄로 요약해줘: ...');
}

성능과 요구사항 — 22GB가 진짜 장벽

내부 모델은 Gemini Nano로, Chrome이 한 번 내려받아 모든 사이트가 공유합니다. API 키도 없고 과금도 없고, 다운만 끝나면 오프라인에서도 돌아요.

다만 요구사항이 꽤 까다롭습니다:

• 데스크톱 전용 — Windows 10/11, macOS 13+, Linux, Chromebook Plus. Android·iOS는 아예 안 됩니다
• 여유 디스크 22GB (모델 자체는 ~4GB인데 Chrome이 요구하는 헤드룸). 디스크 부족하면 조용히 다운이 안 됩니다 — 제가 지난번에 겪은 "0%에서 멈춤"이 이것과 무관하지 않을 겁니다
• GPU 4GB+ VRAM 또는 16GB RAM + 4코어 CPU (Chrome 140부터 CPU 추론 지원)
• 무제한 네트워크 (최초 다운로드용)

체감 성능은 중급 PC 기준 초당 수십 토큰 — 짧은 작업은 1초 안팎으로 끝납니다. 다만 공식·비공식 후기가 공통으로 말하는 경계가 뚜렷해요:

• 잘하는 것: 페이지에 이미 있는 텍스트의 요약·분류·추출·다듬기·번역
• 못하는 것: 지식 질문("~의 역사를 설명해줘" 같은), 긴 문서, 정확도가 목숨인 작업

그리고 제가 직접 삽질로 확인한 제약 — 워커에서 호출하면 사용자 제스처가 안 전달돼 영구 멈춥니다. 내장 API는 메인 스레드에서만 쓴다고 보시면 됩니다(자체 모델을 돌리는 transformers.js는 워커에서 돌려야 하고, 저희 사이트도 그렇게 하고 있어요).

대안 지도 — 내장이 안 되면 뭘 쓰나

내장 API가 안 되는 경우(Firefox/Safari/모바일/스펙 미달)는 오히려 다수입니다. 선택지는 크게 둘:

transformers.js (WebGPU) — 지금 버전 4.x까지 와서 WebGPU 런타임을 C++로 갈아엎고 Safari 26에서도 WebGPU가 켜집니다. 모델 아키텍처 ~200종, 양자화된 소형 모델은 수백 MB로 돌아가고, 워커에서 스트리밍까지 됩니다. 대신 모델 다운로드는 내 사이트가 부담하고, 기기별 성능 편차가 큽니다(WebGPU 없으면 WASM/CPU로 폴백).

서버 API — 모든 기기에서 동일 품질이 필요하면 결국 이쪽. 대신 비용·지연·개인정보 전송이 따라옵니다.

제 추천 — 이렇게 조합하세요

실제로 써보고 정리한 실전 설계입니다:

1. 기능 감지 먼저 — LanguageModel.availability()로 내장 AI 가능 여부 확인. 가능하면 무료·오프라인 추론을 쓰고, 안 되면 다음 단계로
2. 내장 AI는 "보너스"로 설계 — 없어도 기능이 도는 게 전제. 방문자 다수가 스펙 미달이라 이게 기본 경로가 되면 안 됩니다
3. 폴백은 목적에 따라 — 번역·요약·분류는 transformers.js 소형 모델로 커버 가능. 정확도가 중요하면 처음부터 서버 API
4. 초기 다운로드를 앞당기기 — 내가 쓴 패턴은 "미리 만들어두기"입니다. 사용자가 버튼 누르기 전에 세션을 예열(prefetch)해두면 체감 대기가 사라져요 — 자세한 삽질은 610편에

정리

2026년 11월 현재 브라우저 내장 AI는 "Chrome 데스크톱에서 쓸 수 있는 진짜 옵션"까지는 왔습니다 — Translator·Summarizer·Prompt API가 Stable이라 프로덕션에 넣어도 됩니다. 다만 Firefox·Safari 미지원이라 단독으로는 못 쓰고, 내장(무료) → transformers.js(범용) → 서버(정확도) 3단 폴백으로 설계하는 게 지금의 정답인 것 같습니다.

모바일 지원, Writer/Rewriter 안정화가 나오면 다시 정리하겠습니다 — 이 판은 반년이면 또 바뀌거든요.