Writer·Rewriter엔 폴리필이 생겼다. Proofreader는 빈손.

Chrome은 이제 Google 서버가 아닌 로컬 기기에서 실행되는 생성형 텍스트 기능을 기본 탑재합니다 — 네트워크 왕복 없이 산문 초안 작성, 문구 재작성, 문법 오류 검사를 수행합니다. 그러나 세 가지 Writing Assistance API는 성숙도가 서로 다르며, 2026년 6월 12일 폴리필 출시로 그 격차가 더욱 뚜렷해졌습니다.

Writer, Rewriter, Proofreader — 기능과 구동 방식

Writer, Rewriter, Proofreader는 생성 모델을 온디바이스에서 완전히 실행하는 세 가지 브라우저 네이티브 텍스트 API입니다. Chrome에서는 Google의 온디바이스 모델인 Gemini Nano가, Microsoft Edge에서는 동일한 명세를 기반으로 자체 소형 언어 모델(SLM)이 이를 구동합니다 . 추론이 로컬에서 이루어지기 때문에, 모델을 한 번 다운로드한 이후에는 네트워크 연결이 필요 없으며 Google이나 제3자에게 데이터가 전송되지 않는다고 Chrome은 명시합니다 — 이것이 지연 시간과 개인정보 보호 측면의 핵심 가치입니다 . API 키도, 토큰별 과금도, 최초 다운로드 이후의 데이터 외부 전송도 없습니다.

한눈에 정리: Writer는 새 산문을 생성하고, Rewriter는 기존 텍스트의 어조나 길이를 조정하며, Proofreader는 교정된 텍스트와 인덱스 매핑된 교정 배열을 반환합니다. 세 가지 모두 온디바이스에서 실행됩니다 — Chrome에서는 Gemini Nano, Edge에서는 내장 SLM. 초기 모델 다운로드(여유 저장 공간 22 GB 이상 필요) 후에는 API 키나 네트워크 호출이 불필요합니다.

세 API는 공통된 2단계 생명주기를 따릅니다. 단발성 호출 방식 대신, create()를 호출해 세션을 설정·로드한 뒤 각 동작 메서드를 호출하는 방식입니다. 이 설계 덕분에 수 기가바이트짜리 모델을 효율적으로 로드하고 해제할 수 있습니다 . 각 API는 기능 감지(예: 'Writer' in self), 다운로드 진행 상태 모니터링, 스트리밍 변형, 메모리 정리를 위한 명시적 destroy()를 제공합니다 .

기능적으로는 명확히 구분됩니다. Writer API는 작업 설명으로부터 새 콘텐츠를 생성합니다 — 구조화된 데이터를 산문으로 확장하거나, 게시물 초안을 작성하거나, 약력을 생성하는 식입니다 . Rewriter API는 기존 텍스트의 어조, 길이, 형식을 수정·재구성합니다 . Proofreader API는 교정된 문자열(correctedInput)과 위치 인덱스 및 교체어를 담은 corrections 배열로 구성된 ProofreadResult를 반환합니다 .

이 모든 것이 실행되려면 모델이 미리 준비되어 있어야 합니다. 세 API 모두 availability() 검사를 통해 unavailable, downloadable, downloading, available의 네 가지 상태를 노출하므로, 다운로드가 완료되는 동안 점진적 향상을 위한 훅을 제공합니다 . 아래 표는 세 가지 API를 나란히 비교합니다.

미리 짚어둘 한 가지 주의사항이 있습니다. 이 온디바이스 환경은 그 뒤를 받치는 소형 모델(Chrome의 Gemini Nano, Edge의 SLM)에 의해 제약되며, 이 모델들은 추론 능력과 다국어 지원 폭에서 서버급 모델에 미치지 못합니다. 또한 해당 제안들은 "Chrome에 탑재 승인을 받지 않은" 초기 스케치임이 명시되어 있습니다 . 이어지는 섹션에서는 각 인터페이스, Writer와 Rewriter는 지원하지만 Proofreader는 지원하지 않는 폴리필, 그리고 설계 시 반드시 고려해야 할 트라이얼 만료 및 플랫폼 제약을 차례로 살펴봅니다.

Writer 인터페이스 한눈에: create(), 톤, 포맷, 스트리밍

Writer API는 작업 설명을 바탕으로 새 글을 생성하며, 모든 상호작용은 Writer.create()에서 시작됩니다. 이 단계에서 온디바이스 모델을 한 번 로드해 두면 여러 초안에 걸쳐 재사용할 수 있습니다. 옵션 객체를 전달해 출력 형태를 고정한 뒤, 쓰기 메서드를 호출하면 됩니다. 인터페이스 문서는 Chrome의 Writer API 페이지에서 확인할 수 있으며, 2025년 10월 22일 공개되었습니다. 현재 Chrome에 내장된 Gemini Nano를 기반으로 Chrome 137~148에 걸친 오리진 트라이얼로 운영 중입니다.

결과를 제어하는 옵션은 네 가지입니다:

• tone — formal, neutral(기본값), casual 중 선택.
• format — markdown(기본값) 또는 plain-text.
• length — short(기본값), medium, long 중 선택.
• sharedContext — 반복적으로 관련 초안을 작성할 때 공통 맥락을 한 번 설정해 두면, 매 호출마다 같은 배경 설명을 되풀이하지 않아도 됩니다.

출력 방식은 두 가지입니다. write()는 완성된 문자열을 한 번에 반환하고, writeStreaming()은 텍스트를 점진적으로 내보내는 ReadableStream을 반환합니다. 문장 하나를 넘는 분량이라면 스트리밍 방식을 권장합니다. 소형 온디바이스 모델 특성상 write()의 전체 지연이 체감될 수 있으며, 스트리밍을 사용하면 스피너를 기다리는 대신 토큰이 도착하는 즉시 에디터에 렌더링할 수 있습니다. 최소 호출 예시는 다음과 같습니다:

const writer = await Writer.create({
  tone: 'casual',
  format: 'plain-text',
  length: 'medium',
  sharedContext: 'Product changelog entries for a developer audience.',
});

const stream = writer.writeStreaming('Announce on-device text APIs.', {
  signal: controller.signal,
});
for await (const chunk of stream) render(chunk);

어디에든 적용하기 전에 반드시 확인해야 할 제약이 두 가지 있습니다. 첫째, Writer API는 Permission-Policy 토큰(writer)을 노출하며, Web Workers에서는 사용할 수 없습니다 Chrome 공식 문서 기준. 서드파티 위젯이나 임베디드 에디터처럼 크로스 오리진 iframe 내에서 실행할 계획이라면, 호스트 페이지가 Permission-Policy를 통해 해당 토큰을 위임해야 합니다. 그렇지 않으면 create()가 실행되지 않습니다. 다른 페이지에 삽입하기 전에 iframe 동작을 반드시 확인하세요.

둘째, 리소스 정리는 선택이 아니라 필수입니다. AbortController를 통한 AbortSignal로 진행 중인 생성을 취소할 수 있으며, 사용자가 프롬프트를 수정하거나 스트리밍 중 페이지를 이탈할 때 꼭 필요합니다. destroy()는 수 기가바이트에 달하는 모델 세션을 메모리에서 명시적으로 해제합니다 Writing Assistance APIs 설명서 정의 기준. destroy()를 생략하면 오래 열린 탭이 모델을 계속 메모리에 올려 두고, abort 처리를 생략하면 사용자가 이미 원하지 않는 토큰을 계속 스트리밍합니다. 프로덕션에서는 두 가지 모두 기본 생명주기의 일부이며, 다음에 다룰 Rewriter API도 이와 동일한 두 단계(중단 가능, 소멸 가능) 패턴을 따릅니다.

Rewriter 동작 원리: 톤 조정, 길이 축소, 스트리밍 변형

Rewriter API는 텍스트를 처음부터 생성하는 대신 기존 텍스트를 수정하며, Rewriter.create()에 세 가지 옵션을 전달해 설정합니다: tone(more-formal / 기본값 as-is / more-casual), length(shorter / 기본값 as-is / longer), format(기본값 as-is / markdown / plain-text) . 핵심은 모든 기본값이 as-is라는 점입니다. 즉, 명시적으로 변경할 항목을 지정하지 않으면 원본 입력을 그대로 유지합니다. 옵션 없이 호출하면 사실상 아무 변화도 없이 입력과 거의 동일한 텍스트가 반환됩니다. 최소한 하나의 축을 재정의해야 동작이 달라집니다.

const rewriter = await Rewriter.create({
  tone: 'more-casual',
  length: 'shorter',
  format: 'plain-text',
  sharedContext: 'Customer support replies for a SaaS dashboard',
});
const revised = await rewriter.rewrite(draft);

메서드 구성은 Writer API의 두 단계 생명주기를 그대로 따릅니다. rewrite()는 완성된 문자열을 반환하고, rewriteStreaming()은 반응형 에디터를 위해 토큰을 점진적으로 내보냅니다 . Writing Assistance APIs 설명서에 정의된 AbortController/AbortSignal 취소, 가용성 확인, destroy() 정리 방식도 동일하게 적용됩니다 . 리소스 관리 원칙도 동일합니다. abort 처리 없이 긴 텍스트를 스트리밍하면, 사용자가 이미 다음으로 넘어간 후에도 토큰이 계속 전달됩니다.

실제 활용 사례는 세 가지 축에서 자연스럽게 도출됩니다:

• 길이 축소 — length: 'shorter'로 설정해 메타 설명이나 채팅 말풍선 같은 글자 수 제한에 맞게 응답을 줄입니다.
• 격식 조정 — tone: 'more-formal' 또는 more-casual로 설정해, 자동 생성된 고객 지원 답변을 손으로 다시 쓰지 않고도 대상 독자에 맞게 조정합니다.
• 형식 변환 — format: 'markdown'으로 일반 산문을 CMS 입력용 마크다운으로 변환하거나, plain-text로 서식을 제거합니다.

여러 관련 단락을 연속으로 재작성하는 세션에서는 rewrite()에 호출별 선택적 컨텍스트 문자열을 전달할 수 있습니다: rewrite(input, { context }). 이를 통해 특정 문장이 법적 고지 사항에 속하는지 마케팅 문구에 속하는지를 모델에 알려 단편적인 문장을 더 넓은 문서 맥락 안에서 정확히 처리할 수 있습니다. 세션 생성 시 설정한 sharedContext는 모든 호출에 걸쳐 변하지 않는 공통 맥락을 담당합니다 . 하나의 Rewriter 객체를 배치 전체에 재사용할 때, 호출별 컨텍스트는 단락마다 모델을 새로 로드하는 비용 없이 일관성을 유지하는 핵심 수단입니다.

모든 Gemini Nano 태스크 API와 마찬가지로, 출력 품질은 온디바이스 모델 수준에 따라 제한되며, 이 제안은 아직 Chrome 정식 출시가 승인되지 않은 초기 설계 단계입니다 . 적용 범위는 Chrome과 Edge로 한정하고, Rewriter 사용 전에 반드시 availability()를 확인하세요.

실험 트라이얼의 Proofreader: 교정, 인덱스 오프셋, 그리고 누락된 레이블

Proofreader API는 웹 앱과 확장 프로그램에 온디바이스 문법·맞춤법·구두점 교정 기능을 제공하지만, 현재 사용할 수 있는 버전은 제안서에 기술된 것보다 적은 기능을 반환합니다. expectedInputLanguages 옵션을 지정해 Proofreader.create()를 호출한 뒤 proofread()를 호출하면, 완전히 교정된 문자열이 담긴 correctedInput과 원문 텍스트의 위치 인덱스 및 해당 범위의 교체 문자열을 포함하는 corrections 배열을 가진 ProofreadResult로 resolve됩니다 . 이 오프셋+교체 구조 덕분에 필드 전체를 교체하는 대신 편집 내용을 인라인으로 강조 표시할 수 있습니다.

여기서 주목해야 할 격차가 있습니다. W3C 설명서는 더 풍부한 인터페이스를 정의합니다: spelling, punctuation, capitalization, preposition, missing-words, grammar를 아우르는 교정 레이블과 각 수정 사항에 대한 사람이 읽을 수 있는 설명이 포함됩니다 . 하지만 Chrome의 현재 공식 트라이얼에서는 이를 노출하는 두 플래그인 includeCorrectionTypes와 includeCorrectionExplanation이 명시적으로 지원되지 않습니다 . 따라서 이것들은 제안서의 일부로만 남아 있고, 출시된 트라이얼에는 포함되지 않습니다.

실제로 얻을 수 있는 것은 교정된 텍스트와 위치 오프셋뿐이며, 그 외 구조화된 정보는 없습니다. "their"가 특정 인덱스에서 "there"로 바뀌어야 한다는 것은 사용자에게 보여줄 수 있지만, API는 해당 변경이 맞춤법 수정인지 문법 수정인지 알려주지 않으며, UI에 표시할 평문 이유도 제공하지 않습니다. 편집기에 분류된 오류 배지나 설명 툴팁이 필요하다면 직접 카테고리를 추론하거나, 제안서가 성숙해지고 플래그가 안정 릴리스에 포함될 때까지 기다려야 합니다.

타이밍도 또 다른 제약입니다. Proofreader 오리진 트라이얼은 Chrome 141–145에서만 실행되며 , 다른 구현체인 Microsoft Edge 147은 Proofreader를 활성 오리진 트라이얼 목록에 올렸지만 만료일이 2026년 5월 19일로 — 이미 지난 날짜입니다. 설명서들은 이 위험성에 대해 솔직하게 언급합니다:

"이 제안은 문제를 설명하고 피드백을 수렴하기 위한 초기 설계 스케치입니다 ... Chrome에 탑재 승인을 받은 것이 아닙니다," — Writing Assistance APIs 설명서, Web Machine Learning Community Group (source: webmachinelearning/writing-assistance-apis).

Proofreader 통합을 배포하기 전에 트라이얼 만료일과 대상 브라우저 버전을 반드시 확인하고, 새 오리진 트라이얼 토큰을 등록하세요. 그리고 런타임에 availability()를 확인해 엔진이 없을 때 교정 텍스트 기능이 자연스럽게 저하되도록 만드세요.

폴리필 동작 원리: Writer와 Rewriter 브라우저 전역 객체 살펴보기

여기서 폴리필이란 내장 AI 작업 API를 브라우저 전역으로 설치하는 JavaScript 심으로, 브라우저에 네이티브 구현이 없을 때도 코드에서 이를 호출할 수 있게 합니다. 2026년 6월 12일, Chrome은 Summarizer, Writer, Rewriter, Translator, Language Detector API에 대한 실험적 폴리필을 소개하는 포스트를 게시했으며, 내부적으로는 실험적 Prompt API 폴리필을 기반으로 합니다 . 네이티브 지원이 없을 경우 폴리필은 window.Writer, window.Rewriter와 같은 전역으로 작업 인터페이스를 노출하므로, 'Writer' in self와 같은 기능 감지 패턴이 계속 작동하고 create() 호출이 실패하는 대신 심을 통해 라우팅됩니다.

구체적인 결과물도 있습니다. GoogleChromeLabs의 built-in-ai-task-apis-polyfills 패키지는 버전 1.14.0으로 writer와 rewriter를 내보내며, prompt-api-polyfill ^1.19.0에 의존합니다 — 이 범용 Prompt API 심이 상위 수준 작업 API가 기반으로 삼는 실제 모델 작업을 수행합니다 . 이 의존성 구조는 설계 의도를 잘 보여줍니다: 각 작업을 별도로 재구현하는 대신, 폴리필은 Writer와 Rewriter를 Prompt API 폴리필이 접근할 수 있는 생성형 모델에 대한 제한된 프롬프트로 표현합니다.

이 글의 핵심은 출시되지 않은 것입니다. 해당 패키지에는 proofreader 내보내기가 없습니다 . Proofreader의 부재는 우연이 아니라 일관된 결과입니다. 오리진 트라이얼 기간이 Writer와 Rewriter 트라이얼보다 좁고, Chrome의 현재 트라이얼에서 인터랙티브 교정 인터페이스도 불완전합니다: includeCorrectionTypes와 includeCorrectionExplanation이 지원되지 않는 것으로 문서화되어 있어, 제안서의 교정 레이블과 평문 설명 부분이 아직 노출되지 않습니다 . 폴리필이 뒷받침할 완전하고 안정적인 API 계약이 없으며 — 아직 형태가 변화 중인 인터페이스를 충실하게 심으로 만들 수는 없습니다.

Chrome이 직접 부르는 대로, 이것들은 실험적인 것으로 취급하세요. 공지문은 이 폴리필을 코드 경로와 점진적 향상을 테스트하는 수단으로 정의하며, 프로덕션급 크로스 브라우저 호환성 레이어로 제시하지 않습니다 . 출력 품질, 지연 시간, 메모리 동작은 Prompt API 폴리필이 해석하는 기반 모델에 따라 달라지며, 이는 기기·OS 버전·사용 가능한 하드웨어에 따라 차이가 납니다. 배포 코드에서 폴리필된 Writer나 Rewriter에 의존하기 전에 실제 지원 대상인 기기·OS 조합에서 테스트하고, 런타임에 availability() 확인을 유지하며, 네이티브 트라이얼 API에 적용하는 것과 동일한 원칙으로 기능이 자연스럽게 저하되도록 설계하세요.

Origin Trial 만료일과 Chrome·Edge가 갈라지는 지점

Writer, Rewriter, Proofreader API는 안정적인 플랫폼 API가 아닌 origin trial 기능입니다. 즉, 각 API는 Chrome 버전 구간을 가지며, 프로덕션 환경에서 API가 플래그 게이트를 벗어나려면 HTTP 헤더(또는 동등한 meta 태그)로 등록된 origin trial 토큰을 전송해야 합니다. Chrome에서 Writer와 Rewriter 트라이얼은 버전 137~148 구간에서 운영되며 , Proofreader 트라이얼은 더 좁은 141~145 구간입니다 . 유효한 토큰 없이 접근하면 최종 사용자는 플래그로 잠긴 API를 마주치게 되며, API는 조용히 사용 불가 상태로 보고됩니다.

Edge는 같은 explainer를 따르지만 Gemini Nano 대신 자체 소형 언어 모델 위에서 동작하며, 트라이얼 일정은 독립적이고 더 촉박합니다. 2026년 4월 9일 출시된 Edge 147은 네 가지 API 모두를 만료일이 정해진 활성 origin trial로 나열했습니다. Writer와 Rewriter 트라이얼은 2026년 4월 21일, Proofreader 트라이얼은 2026년 5월 19일, Prompt API 트라이얼은 2026년 6월 16일에 만료됩니다 . 이 글이 작성된 2026-06-13 현재, Edge의 Writer·Rewriter·Proofreader 트라이얼은 이미 만료되었으며 Edge Prompt API 트라이얼도 수일 내 종료됩니다. 토큰으로 잠긴 기능은 안정적인 대안 없이 분기 중간에 사라질 수 있다는 점을 다시금 상기시켜 줍니다.

이 차이가 중요한 이유는, 2026년 6월 기준 세 가지 Writing API 모두 어떤 브라우저에서도 안정 버전으로 제공되지 않기 때문입니다. 반면 Summarizer, Translator, Language Detector API는 Chrome 138에서 안정 버전으로 출시 되었기 때문에 나머지 API도 마찬가지로 안정됐다고 착각하기 쉽지만, 실상은 그렇지 않습니다. Writing Assistance explainer는 해당 제안들이 "Chrome 출하 승인을 받지 않았으며", 안정 버전이 나오기 전까지 API 영역·옵션·동작 방식이 변경될 수 있다고 명시합니다 .

실무적으로는 의존 범위를 Chrome과 Edge로 한정하고, 토큰 기간을 출시일이 아닌 만료일로 인식하며, 모든 호출 앞에 런타임 availability() 확인을 두어 트라이얼이 만료됐을 때 예외를 던지는 대신 폴백 경로로 자연스럽게 전환되도록 하십시오.

Android·iOS와 대부분의 비(非)Chrome 브라우저가 차단되는 이유

Gemini Nano Writing API는 설계상 데스크톱·ChromeOS 전용입니다. Windows 10/11, macOS 13 (Ventura) 이상, Linux, 또는 플랫폼 16389.0.0 이상의 Chromebook Plus 기기에서 동작합니다 . Android용 Chrome, iOS용 Chrome, Chromebook Plus 미지원 ChromeOS는 Gemini Nano API에서 명시적으로 제외되므로, 모바일 중심 사용자층은 Writer·Rewriter·Proofreader를 기본 탑재 기능으로 전혀 사용할 수 없습니다 . 이 제외는 일시적인 공백이 아니라 모델의 운영 범위 자체에서 비롯된 것입니다.

하드웨어 최저 요건도 대상 범위를 더욱 좁힙니다. 온디바이스 모델은 프로필 볼륨에 최소 22 GB의 여유 공간과 4 GB를 초과하는 VRAM을 갖춘 GPU가 필요하며, GPU 요건을 충족하지 못할 경우 최소 16 GB RAM과 4코어 CPU, 초기 수 기가바이트 다운로드를 위한 무제한 연결이 요구됩니다 . 이러한 요건은 상당수의 소비자용 노트북, 저용량 RAM 기기, 종량제 또는 데이터 한도 연결 환경을 차단합니다. 네 가지 요건을 모두 충족한 사용자도 첫 번째 create() 호출이 성공하기 전에 최초 다운로드를 기다려야 합니다.

크로스 엔진 지원도 또 하나의 장벽입니다. Firefox (Gecko)와 Safari (WebKit)는 이 제안들에 대해 공개 표준 입장 이슈만 제기한 상태로, 구현에 대한 공개적 약속은 없습니다 . W3C explainer는 브라우저가 언어 모델을 탑재할 의무가 없다고 단호히 명시하므로, 표준을 준수하는 브라우저도 스펙 위반 없이 전체 기능을 지원하지 않을 수 있습니다 . Safari와 Firefox의 동등 지원은 임박한 것이 아닌 미검증 상태로 보고, 해당 엔진에서는 폴리필이나 서버 폴백이 유일한 경로라고 가정하십시오.

언어 지원 범위도 한정적입니다. Chrome 149부터 Gemini Nano는 입출력 텍스트 모두에 영어·스페인어·일본어·독일어·프랑스어를 지원하며, create() 호출 시 전달하는 expected input, context, output 파라미터로 세션별 활성 언어를 선택합니다 . 이 다섯 가지 언어 이외의 언어는 현재 온디바이스에서 지원되지 않습니다. 개발자에게 주는 실질적인 교훈은 이 제약들을 능력 매트릭스로 읽어야 한다는 점입니다. 적절한 하드웨어를 갖추고 지원 언어를 사용하는 데스크톱 Chrome 또는 Edge 사용자가 실제 지원 대상이며, 그 외의 모든 사용자는 폴백으로 라우팅됩니다 — 이는 마지막 섹션에서 다룹니다.

할당량 오류, destroy(), 그리고 온디바이스 엔진 부재 시 폴백

이러한 API를 프로덕션에 배포한다면, 온디바이스 엔진을 보장된 함수 호출이 아닌 실패 가능한 공유 자원으로 다뤄야 합니다. 입력이 너무 크면 QuotaExceededError가 발생하고, 인스턴스는 명시적으로 해제해야 하며, 가용성은 페이지 로드마다 재확인해야 합니다. 또한 특정 사용자에게는 전체 경로가 unavailable을 반환할 수 있으므로, 서버 측 경로는 선택 사항이 아닙니다. Writing Assistance와 Proofreader 제안은 초기 설계 초안으로, explainer 문서에 "Chrome 배포가 승인되지 않았다"고 명시되어 있으며, 출력 품질·안정성·크로스브라우저 상호운용성은 명시적으로 보장되지 않습니다 . 방어적으로 구현하세요.

할당량. 세션마다 처리할 수 있는 입력 용량이 정해져 있습니다. 프로덕션 경로에서 write(), rewrite(), proofread()를 호출하기 전에, 페이로드가 세션 할당량을 초과하는지 확인하세요. 입력이 너무 크면 자동으로 잘리는 대신 QuotaExceededError가 발생합니다 . 이 오류를 캐치해 텍스트를 청크 단위로 나누거나 다른 경로로 라우팅하세요 — 에디터나 댓글 폼에서 처리되지 않은 rejection으로 노출되어서는 안 됩니다.

정리. Writer, Rewriter, Proofreader 객체를 다 사용했다면 반드시 destroy()를 호출하세요. 수 기가바이트에 달하는 모델은 온디바이스 공유 자원이며, create() 후 메서드를 호출하는 두 단계 생명주기는 바로 엔진을 효율적으로 로드·언로드하기 위한 구조입니다 . Chrome은 메모리를 대신 회수해 주지 않으며, 인스턴스가 누수되면 해당 메모리는 계속 점유됩니다.

가용성은 로드마다 재확인. API는 네 가지 상태를 노출합니다 — unavailable, downloadable, downloading, available . 세션 간에 디바이스 상태는 변할 수 있습니다. 다운로드가 시작되거나, 프로파일 볼륨이 22 GB 여유 저장 공간 요건 아래로 줄거나, OS 정책이 바뀔 수 있습니다 . availability()는 앱 초기화 시 한 번이 아니라, 페이지 로드마다 런타임에 호출하세요.

"브라우저는 이러한 API를 지원하거나 특정 언어 모델을 다운로드할 의무가 없습니다" — Writing Assistance APIs explainer, W3C Web Machine Learning Community Group (source: webmachinelearning/writing-assistance-apis).

점진적 성능 저하 대응. availability()가 unavailable을 반환하면, 조용히 실패하거나 사용자를 막지 말고 서버 측 LLM 호출로 라우팅하세요. 온디바이스 경로가 항상 활성 상태라고 가정하지 마세요. Android·iOS용 Chrome, Chromebook Plus가 아닌 ChromeOS, GPU/VRAM 또는 16 GB RAM 요건을 충족하지 못하는 기기에서는 사용할 수 없습니다 .

핵심 결론: 각 API를 네 가지 상태 가드로 감싸고, QuotaExceededError를 캐치하며, 완료 시 destroy()를 호출하고, 서버 측 경로를 항상 준비해 두세요. 온디바이스 엔진은 자격 요건을 갖춘 일부 사용자에게만 제공되는 지연 시간 및 비용 최적화 수단입니다 — 유일한 경로가 아닌 점진적 향상으로 다루어야 합니다.

자주 묻는 질문

Chrome의 Writer 및 Rewriter API를 사용하려면 인터넷 연결이나 API 키가 필요한가요?

아닙니다. API 키도 없고, 토큰당 과금도 없으며, 사용 중 서버 왕복도 발생하지 않습니다. 최초 한 번의 모델 다운로드(무제한 연결 필요)가 끝나면 모든 추론은 Gemini Nano를 통해 로컬에서 실행되며, Chrome은 모델 사용 시 Google이나 제3자에게 데이터가 전송되지 않는다고 밝히고 있습니다 . 온디바이스 실행이야말로 이 API의 핵심 프라이버시·지연 시간 장점입니다. 실용적인 주의 사항: availability()가 available을 반환할 때까지 첫 번째 호출이 다운로드로 인해 지연될 수 있으므로, 네 가지 가용성 상태를 기반으로 기능을 조건부로 제공하세요 .

Chrome의 온디바이스 작성 기능을 활성화하려면 어떤 하드웨어가 필요한가요?

Gemini Nano API를 사용하려면 Windows 10/11, macOS 13+(Ventura 이상), Linux, 또는 Chromebook Plus 기기(플랫폼 16389.0.0 이상)의 ChromeOS가 필요하며, 프로필 볼륨에 최소 22GB의 여유 저장 공간, 그리고 4GB VRAM 초과의 GPU 또는 16GB 이상 RAM과 4코어 이상의 CPU가 필요합니다 . Android용 Chrome, iOS용 Chrome, Chromebook Plus가 아닌 ChromeOS는 완전히 지원 대상에서 제외됩니다 . 기기가 임계값을 하나라도 충족하지 못하면 availability()가 unavailable을 반환하므로, 서버 경로로 폴백해야 합니다.

Chrome Writer, Rewriter, Proofreader 오리진 트라이얼은 언제 만료되나요?

Chrome에서 Writer 및 Rewriter 오리진 트라이얼은 Chrome 137~148, Proofreader 트라이얼은 Chrome 141~145에 걸쳐 진행됩니다 . 2026년 4월 9일 출시된 Edge 147에서는 동등한 트라이얼에 명확한 만료일이 적용됩니다: Writer 및 Rewriter는 2026년 4월 21일, Proofreader는 2026년 5월 19일에 만료되었습니다 . 트라이얼 API를 프로덕션에서 사용하려면 오리진 트라이얼 토큰을 등록하고 HTTP 응답 헤더에 포함해야 하며, 이 API들이 안정 버전에 도달하기 전까지 동작이 변경될 수 있습니다.

6월 12일 폴리필 패키지에 Proofreader가 없는 이유는 무엇인가요?

GoogleChromeLabs의 built-in-ai-task-apis-polyfills 패키지 버전 1.14.0은 Writer 및 Rewriter(Summarizer, Translator, Language Detector 포함)를 내보내지만, Proofreader는 내보내지 않습니다 . Proofreader는 오리진 트라이얼 기간이 더 짧고 범위가 좁으며, 수정 유형 레이블과 설명(includeCorrectionTypes, includeCorrectionExplanation)은 Chrome 현재 트라이얼에 아직 노출되어 있지 않습니다 . 인터페이스가 불완전하고 불안정한 상태에서는 폴리필이 뒷받침할 견고한 기반이 없기 때문에, "Web-AI-SDK 0.5가 Proofreader를 추가한다"는 주장은 실제 아티팩트로 뒷받침되지 않습니다.

이 브라우저 작성 기능이 Firefox나 Safari에서도 작동할 수 있나요?

현재 어느 공급업체도 약속하지 않고 있습니다. Gecko(Firefox)와 WebKit(Safari)는 표준 포지션 이슈만 열려 있을 뿐 구현 약속이 없으며, W3C Writing Assistance 익스플레이너는 브라우저가 언어 모델을 반드시 제공할 의무가 없다고 명시하고 있습니다 . 현재로서는 프로덕션 지원 범위를 구현이 실행 중인 유일한 엔진인 Chrome과 Edge로 한정하고, 크로스 브라우저 동등성은 당연한 전제가 아닌 미검증 사항으로 다루세요.