브라우저 내부에서 벌어지는 조용한 AI 전쟁
요약
Google이 Chrome 148 버전에 Gemini Nano와 통신하는 Prompt API를 출시하며 로컬 AI 추론 시대를 열었습니다. 비결정론적 출력에 대한 웹 표준 논란에도 불구하고, 이 API는 저지연, 오프라인 지원, 개인정보 보호가 필요한 특정 작업에서 클라우드 AI의 틈새 시장을 공략할 전망입니다.
핵심 포인트
- Chrome 148의 Prompt API를 통해 로컬 Gemini Nano 모델 활용 가능
- API 키, 서버 비용, 네트워크 지연 시간 없이 AI 추론 수행
- 웹 표준의 결정론적 특성 훼손에 대한 업계의 논쟁 존재
- 클라우드 AI를 대체하기보다 저지연 및 개인정보 보호 작업에 특화
Google은 2026년 5월 5일 Chrome 148 버전에 Prompt API를 출시했습니다. Mozilla는 반대했습니다. Apple의 WebKit 팀도 반대했습니다. W3C TAG도 반대했습니다. Microsoft Edge는 동일한 Chromium 엔진을 사용함에도 불구하고 _이 기능을 완전히 비활성화_했습니다. 이는 어떤 기준으로 보더라도 최근 기억 중 가장 논쟁적인 브라우저 기능 출시 중 하나였습니다.
그리고 그것은 중요하지 않습니다. Google은 이미 이번 싸움에서 승리했습니다.
실제로 일어난 일
Chrome 148은 이제 Chrome이 사용자 기기에 별도의 요청 없이 배포하는 4GB 모델인 Gemini Nano와 통신함으로써, 지구상의 모든 웹사이트가 로컬에서 AI 추론(텍스트 생성, 요약, 분류, 이미지 캡셔닝)을 실행할 수 있는 능력을 조용히 부여했습니다. 이 API는 매우 단순합니다:
const session = await self.ai.languageModel.create({ systemPrompt });
const result = await session.prompt("Your prompt here");
그게 전부입니다. API 키도 필요 없습니다. 지연 시간(Latency)도 없습니다. 서버 비용도 없습니다. 데이터가 기기를 떠나지도 않습니다.
반대 측의 핵심 논거는 타당합니다. fetch()나 addEventListener()와 달리, AI 모델은 결정론적(Deterministic)인 사양(Spec)이 아닙니다. 서로 다른 기반 모델을 사용하여 "동일한 API"를 구현하는 두 브라우저는 매우 다른 출력을 생성할 수 있으며, 이는 웹 표준의 근본적인 약속인 '한 번 작성하여 어디서나 동일하게 실행한다(write once, run identically everywhere)'를 깨뜨릴 수 있습니다.
이는 실제적인 우려입니다. 하지만 실제로는 무의미합니다.
웹은 동일한 출력을 보장한 적이 없습니다
폰트 렌더링(Font rendering)은 브라우저마다 다릅니다. Canvas 픽셀은 GPU 드라이버에 따라 달라집니다. 오디오 처리(Audio processing)는 macOS와 Windows에서 다르게 동작합니다. Math.random()은 정의상 비결정론적(Non-deterministic)입니다. 이 중 그 어느 것도 웹을 무너뜨리지 않았습니다. 개발자들은 적응해 왔으며, 이번에도 적응할 것입니다.
"비결정론적인 출력을 표준화할 수 없다"는 논거는 과도합니다. 만약 이 논리가 일관되게 적용된다면, 현대 웹 플랫폼의 절반은 존재하지 못했을 것입니다.
클라우드가 진정한 기준점입니다: Firefox의 미래 모델이 아니라
비판론자들이 놓치고 있는 사실이 있습니다. 오늘날 진지한 AI 기능을 구축하는 개발자들은 Chrome의 Prompt API와 Firefox의 이론적인 대응 기술 사이에서 고민하는 것이 아닙니다. 그들은 OpenAI, Anthropic, Gemini Cloud와 같은 클라우드 API를 호출하고 있습니다. 품질, 컨텍스트 윈도우 (Context Window), 그리고 유능한 모델들이 있는 곳은 바로 그곳입니다.
Gemini Nano는 작은 모델입니다. 문단 요약, 감성 분류, 문자열에서 날짜 추출과 같이 가볍고 범위가 명확한 작업에는 적합합니다. 하지만 실제로 중요한 그 어떤 작업에서도 GPT-4o나 Claude Sonnet을 대체하지는 못합니다.
따라서 Prompt API는 클라우드 AI와 경쟁하는 것이 아닙니다. 대신 다음과 같은 특정 틈새 시장(Niche)을 채우고 있습니다:
- 즉각적인 반응이 필요한 제로 레이턴시 (Zero latency) 작업
- PWA에서의 오프라인 지원 (Offline-capable) 기능
- 데이터가 기기에 머물러야 하는 개인정보 보호 중심 (Privacy-sensitive) 처리
- 대규모 운영 시 비용 효율성 (Cost-sensitive) 이 필요한 작업 (맞춤법 검사, 자동 태깅, 콘텐츠 필터링)
개발자들은 이를 점진적 향상 (Progressive Enhancement) 계층으로 활용할 것입니다. 즉, Prompt API를 사용할 수 있을 때는 이를 사용하고, 사용할 수 없을 때는 클라우드 호출로 대체(Fall back)하는 방식입니다. 이러한 프레임워크 안에서는 비결정론 (Non-determinism)에 대한 반론이 완전히 무너집니다. 아무도 Chrome과 Firefox가 동일한 토큰을 생성하기를 기대하지 않기 때문입니다. 그들은
PWA (Progressive Web Apps)가 가장 극명한 사례입니다. Apple은 수년간 저항했습니다. 이는 주로 표준의 순수성 때문이 아니라, 네이티브 앱(Native apps)과 App Store가 수십억 달러 규모의 비즈니스이기 때문입니다. 그들은 결국 도입했으며, 처음에는 불완전하게 시작했으나 압박이 거세짐에 따라 점차 더 완전한 형태로 제공하게 되었습니다. Web Components (웹 컴포넌트) 역시 유사하게 우회하는 경로를 거쳤습니다. Google과 Mozilla는 초기에 뜻을 모았고, Apple은 발을 늦게 뺐으며, 오늘날 Custom Elements (커스텀 엘리먼트)와 Shadow DOM (섀도우 DOM)은 보편적으로 지원됩니다.
Prompt API (프롬프트 API)도 동일한 궤적을 따를 것입니다. 유일한 미결 과제는 그 격차가 얼마나 지속될 것인지, 그리고 그 과정에서 어떤 타협이 이루어질 것인지입니다. (제 추측으로는: Firefox와 Safari는 결국 호환 가능한 API 표면(API surface)을 가진 무언가를 출시하겠지만, 그 내부에는 각자의 모델을 탑재할 것입니다. Mozilla는 오픈 소스 기반의 무언가를, Apple은 Core ML에 최적화된 무언가를 내놓을 것입니다. 출력값은 서로 다를 것입니다. 하지만 아무도 신경 쓰지 않을 것입니다.)
아무도 공개적으로 말하지 않는 진짜 우려 사항
Apple의 전략적 고민은 사양 준수(Spec compliance)에 관한 것이 아닙니다. 그것은 바로 이것입니다: Google이 브라우저를 AI 전달 수단으로 정상화(Normalize)했으며, 40억 대 이상의 기기에 자사의 모델을 설치했다는 점입니다. 이것은 웹 표준의 문제가 아닙니다. 이것은 생태계 통제(Ecosystem control)의 문제입니다.
브라우저의 모델 계층(Model layer)을 제어하는 자는 사용자가 웹과 상호작용하는 방식의 상당한 영역을 제어하게 됩니다. 무엇이 요약될지, 콘텐츠가 어떻게 분류될지, 무엇이 노출되고 무엇이 노출되지 않을지를 결정하게 됩니다. Apple은 이를 누구보다 잘 이해하고 있습니다. 이는 그들이 지난 15년 동안 App Store를 통해 구축해 온 바로 그 종류의 영향력(Leverage)입니다.
이는 진지한 대화를 나눌 가치가 있는 정당한 우려입니다. 하지만 이를 표준의 무결성(Standards integrity) 문제로 포장하는 것은 그 본질을 희석시키며, 솔직히 말해 반대론자들이 악의적으로 논쟁하는 것처럼 보이게 만듭니다. 이는 결국 진짜 싸움(모델 거버넌스, 콘텐츠 정책, 온디바이스 데이터 접근)이 닥쳤을 때 그들의 입지를 약화시킬 것입니다.
이것이 여러분에게 의미하는 바
만약 여러분이 오늘날 웹 제품을 만들고 있다면:
개발자: 가볍고 지연 시간(latency)에 민감한 작업을 위해 지금 바로 Prompt API를 사용하여 실험을 시작하세요. 점진적 향상(graceful degradation)을 고려하여 설계해야 합니다. 이 API는 아직 Firefox나 Safari에서 사용할 수 없으므로, 기본 기능(baseline)이 아닌 향상된 기능(enhancement)으로 취급하세요. 더 높은 성능을 요구하는 작업의 경우, WebGPU 기반의 Bring-your-own-model 방식(transformers.js, ONNX Runtime Web 등을 통해)이 여전히 브라우저 간 호환성을 보장하는 방법입니다. 두 방식 모두를 아우르는 통합 추상화 계층을 원한다면 web-ai-sdk.dev를 확인해 보세요.
제품 및 비즈니스: 여기서 흥미로운 돌파구(unlock)는 기존의 클라우드 AI 파이프라인을 대체하는 것이 아닙니다. 이전에는 웹에서 존재할 수 없었던 AI 기능들, 즉 즉각적이고, 오프라인이며, 프라이빗하고, 한계 비용(marginal cost)이 제로인 기능들을 가능하게 하는 것입니다. 클라이언트 측 콘텐츠 중재(content moderation), 온디바이스 개인화(on-device personalization), 로컬 초안 작성 지원 등을 생각해 보세요. 경제성과 프라이버시 측면의 이야기는 진정으로 새롭습니다.
브라우저는 AI 런타임(runtime)이 되어가고 있습니다. Google은 허락을 구하지 않았습니다. 이미 상황은 돌이킬 수 없이 진행되었습니다.
Prompt API는 Chrome 148+ 버전에서 사용할 수 있습니다. WebGPU 기반의 추론(inference)은 현재 Transformers.js와 같은 라이브러리를 통해 브라우저 간 호환이 가능합니다. WebNN은 모든 브라우저에서 여전히 실험적인 단계로 남아 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기