4GB Gemini Nano 논쟁, 브라우저가 모델 배포자가 된 순간

AI 요약

• 무슨 일: Chrome의 Gemini Nano 온디바이스 모델 다운로드가 4GB 논쟁으로 번졌습니다.
  • 공식 문서는 built-in AI API 호출, 일부 availability() 조건, scam detection 기능과 모델 다운로드 경로를 설명합니다.
• 핵심 쟁점: 서버로 데이터를 보내지 않는 로컬 AI라도 저장공간, 네트워크, 고지, 삭제 정책은 사용자 계약입니다.
• 개발자 영향: Prompt API는 웹 앱에 로컬 LLM을 주지만, 배포 UX와 fallback 설계까지 제품 책임으로 끌어옵니다.
• 주의점: "모든 Chrome이 무조건 4GB를 받았다"로 단순화하면 과장입니다. 트리거 조건과 정책을 분리해 봐야 합니다.

2026년 5월 초 Chrome 사용자를 중심으로 작은 폭발이 있었습니다. 보안 연구자와 사용자들이 Chrome 프로필 안에서 OptGuideOnDeviceModel 디렉터리와 weights.bin 파일을 발견했고, 이것이 Google의 온디바이스 모델인 Gemini Nano와 연결돼 있다는 주장이 퍼졌습니다. 일부 보도는 이 파일을 약 4GB 규모의 로컬 AI 모델로 설명했습니다. 문제 제기는 직관적이었습니다. 사용자가 AI 모델을 설치하겠다고 명시적으로 누른 기억이 없는데, 왜 브라우저가 수 GB급 모델 파일을 저장소에 내려받느냐는 것입니다.

이 사건은 "Chrome이 또 AI 기능을 넣었다" 정도의 기능 뉴스로 보면 작게 보입니다. 하지만 개발자와 AI 제품팀 관점에서는 훨씬 큰 이야기입니다. 브라우저가 웹 런타임을 넘어 모델 런타임과 모델 배포 채널이 되고 있습니다. 사용자가 웹 앱을 열고 버튼을 누르는 순간, 서버 API가 아니라 로컬 브라우저 모델이 응답할 수 있습니다. 그 자체는 매력적입니다. 개인정보를 서버로 보내지 않을 수 있고, 지연시간과 API 비용도 줄일 수 있습니다. 그러나 모델은 코드 번들보다 큽니다. 다운로드, 업데이트, 삭제, 저장공간, 네트워크 과금, 고지 방식이 모두 제품 경험의 일부가 됩니다.

Google의 Chrome Built-in AI 문서는 방향을 분명히 밝힙니다. Chrome에서 브라우저가 foundation model과 expert model을 제공하고 관리하며, 그 안에 Gemini Nano가 포함됩니다. 웹사이트와 웹 앱은 Chrome이 관리하는 모델과 API를 통해 AI 작업을 수행할 수 있습니다. Prompt API, Summarizer, Writer, Rewriter, Proofreader, Translator 같은 API가 이 흐름의 표면입니다.

논쟁의 초점은 "로컬 AI가 가능한가"가 아닙니다. 이미 가능합니다. 진짜 질문은 "브라우저가 로컬 AI를 가능하게 만들기 위해 어떤 비용을 사용자의 장치에 배치해도 되는가"입니다.

Chrome 문서가 말하는 다운로드 조건

먼저 과장과 사실을 분리해야 합니다. Google의 built-in model management 문서는 Gemini Nano의 최초 다운로드가 built-in AI API의 *.create() 호출로 트리거된다고 설명합니다. 예를 들어 Summarizer.create() 같은 호출이 Gemini Nano를 필요로 하면, Chrome은 장치 조건을 확인한 뒤 모델을 내려받습니다. 이 설명만 보면 사용자가 어떤 웹 기능을 실제로 사용하기 전에는 다운로드가 일어나지 않는 구조처럼 보입니다.

하지만 문서는 중요한 예외도 적습니다. 일부 상황에서는 availability() 호출이 다운로드를 트리거할 수 있습니다. 특히 새 사용자 프로필이 막 시작된 직후이고 Gemini Nano 기반 scam detection 기능이 활성화된 경우를 언급합니다. 즉 "개발자가 세션을 만들 때만 다운로드된다"로 끝나지 않습니다. 브라우저 자체 보안 기능, API 가용성 확인, 사용자 프로필 상태가 다운로드 조건에 끼어들 수 있습니다.

이 차이가 이번 논쟁의 핵심입니다. 개발자 문서는 API 사용 흐름을 설명합니다. 사용자는 브라우저 저장공간에서 결과를 봅니다. 그 사이의 관리 계층이 충분히 눈에 보이지 않으면, 사용자는 브라우저가 몰래 뭔가를 설치했다고 느낍니다.

Get started 문서는 요구 조건도 꽤 구체적으로 제시합니다. Prompt API, Summarizer, Writer, Rewriter, Proofreader는 Windows 10/11, macOS 13 이상, Linux, 일부 ChromeOS 환경에서 동작합니다. Chrome for Android, iOS, Chromebook Plus가 아닌 ChromeOS 장치에서는 Gemini Nano를 쓰는 API가 아직 지원되지 않습니다. 저장공간은 Chrome 프로필이 있는 볼륨에 최소 22GB 여유 공간이 필요합니다. GPU는 4GB를 초과하는 VRAM이 필요하거나, CPU 경로에서는 16GB RAM과 4코어 이상 조건이 붙습니다. 네트워크는 초기 다운로드를 위해 unmetered connection이어야 합니다.

여기서 "22GB"는 모델 파일 크기 자체가 아니라 모델 사용을 허용하기 위한 여유 공간 조건입니다. 모델 크기는 업데이트와 장치 조건에 따라 달라질 수 있고, Chrome은 chrome://on-device-internals에서 현재 설치 상태와 크기를 확인하라고 안내합니다. 따라서 4GB라는 숫자는 실제 사용자가 본 파일 크기와 보도에서 나온 강한 상징이지만, Chrome의 설계상 모델 변형과 업데이트에 따라 고정값으로 취급하면 안 됩니다.

왜 온디바이스 AI가 오히려 불신을 만들었나

아이러니하게도 Gemini Nano의 기본 명분은 프라이버시에 가깝습니다. 로컬 모델을 쓰면 텍스트를 매번 서버로 보내지 않아도 됩니다. Prompt API 데모 사이트도 Chrome의 Gemini Nano가 장치에서 실행되며 외부 서버로 데이터를 보내지 않는다고 설명합니다. 웹 앱 입장에서는 매력적인 구조입니다. 간단한 요약, 문장 다듬기, 리뷰 정리, 언어 감지, 번역, 로컬 확장 기능을 서버 비용 없이 처리할 수 있습니다.

그런데 프라이버시가 서버 전송만의 문제가 아니라는 점이 드러났습니다. 사용자의 장치에 대형 모델을 저장하는 것도 동의의 대상입니다. 저장공간은 사용자의 자원입니다. 네트워크 대역폭도 사용자의 자원입니다. 노트북 배터리와 발열도 사용자의 경험입니다. 기업 환경에서는 더 복잡합니다. 관리자는 어떤 모델이 내려받아졌는지, 어떤 기능이 그 모델을 호출하는지, 로그와 정책으로 통제할 수 있는지 알아야 합니다.

Chrome 문서에는 이 긴장이 이미 숨어 있습니다. Built-in AI 페이지의 best practices에는 "모델 다운로드 사실을 사용자에게 알려라"는 항목이 있습니다. 이것은 웹 개발자를 향한 UX 조언이지만, 플랫폼 자체에도 같은 원칙이 적용됩니다. 사용자가 어떤 사이트의 요약 버튼을 누른 뒤 "지금 로컬 AI 모델을 내려받습니다"라는 안내를 받는 것과, 며칠 뒤 디스크 정리 중 4GB 파일을 발견하는 것은 완전히 다른 경험입니다.

개발자에게도 이 문제는 남의 일이 아닙니다. Built-in AI API를 쓰면 모델 배포를 직접 하지 않아도 됩니다. 하지만 그 대신 브라우저의 모델 상태, 다운로드 상태, 가용성 상태를 제품 흐름에 포함해야 합니다. availability()가 "downloadable", "downloading", "available", "unavailable" 같은 상태를 돌려주는 이유가 여기에 있습니다. 사용자는 "요약" 버튼을 눌렀는데, 제품은 실제로 "모델을 받을 수 있는가", "사용자 활성화가 있는가", "저장공간이 충분한가", "언어가 지원되는가", "다운로드가 끝났는가"를 다뤄야 합니다.

4B와 2B, 브라우저가 모델 라우터가 되는 순간

Chrome의 모델 관리 문서에서 가장 흥미로운 부분은 모델 선택입니다. Chrome은 GPU 성능을 추정하기 위해 대표 shader를 실행한 뒤, 더 큰 Gemini Nano 변형, 더 작은 변형, 또는 CPU inference fallback을 선택합니다. 문서는 큰 변형의 예로 4B parameters, 작은 변형의 예로 2B parameters를 듭니다. 이것은 단순 다운로드가 아닙니다. 브라우저가 장치 상태를 보고 모델 변형을 라우팅하는 구조입니다.

AI 앱 개발자는 지금까지 이런 결정을 서버 쪽에서 했습니다. 요청이 쉽다면 작은 모델, 어렵다면 큰 모델, 비용이 민감하면 저가 모델, 품질이 중요하면 고가 모델로 보냈습니다. Chrome built-in AI는 이 라우팅 일부를 클라이언트 플랫폼 안으로 옮깁니다. 같은 API를 호출해도 어떤 사용자는 4B급 변형을 받고, 어떤 사용자는 2B급 변형을 받고, 어떤 사용자는 지원되지 않을 수 있습니다. 제품 품질은 더 이상 "우리 서버 모델 버전" 하나로 고정되지 않습니다.

이것은 웹 앱에 새로운 테스트 매트릭스를 만듭니다. 온디바이스 모델은 비용이 0에 가까워 보일 수 있지만, 모델 품질과 가용성이 장치별로 갈립니다. 사용자의 GPU, RAM, 저장공간, 네트워크, Chrome 버전, 지역, 언어 지원 상태가 모두 영향을 줄 수 있습니다. 개발자가 fallback을 준비하지 않으면 어떤 사용자에게는 빠르고 사적인 AI 기능이, 다른 사용자에게는 계속 비활성화된 버튼이 됩니다.

서버 모델과 로컬 모델을 섞는 하이브리드 전략도 필요합니다. Chrome 문서는 Firebase AI Logic을 이용한 hybrid prompt 흐름도 소개합니다. 이것은 로컬 모델이 실패하거나 기능이 부족할 때 클라우드 모델로 넘어가는 방향을 암시합니다. 하지만 이때도 사용자의 기대를 맞춰야 합니다. "이 작업은 장치에서 처리됩니다"라고 말한 뒤 실패 시 서버로 보내면 안 됩니다. 로컬 처리와 클라우드 fallback 사이에는 명확한 권한과 고지가 필요합니다.

업데이트는 더 민감하다

다운로드보다 더 까다로운 것은 업데이트입니다. Chrome의 모델 관리 문서는 Gemini Nano 업데이트가 정기적으로 배포되고, Chrome이 시작될 때 업데이트를 확인한다고 설명합니다. 보조 리소스는 매일 확인됩니다. 새 모델을 받는 동안 기존 모델로 계속 동작하고, 다운로드가 끝나면 hot swap됩니다. 이 과정은 사용 중단 시간을 줄이는 데 유리합니다.

하지만 문서는 또 다른 중요한 사실을 말합니다. 모델 업데이트는 부분 패치가 아니라 새 모델 전체 다운로드입니다. 모델 weight는 버전 간 차이가 클 수 있어 delta를 계산하고 적용하는 방식이 느릴 수 있기 때문입니다. 사용자 관점에서는 "AI 모델 하나가 이미 있는데 왜 또 큰 파일을 받는가"라는 질문이 나옵니다. 브라우저 관점에서는 안전하고 일관된 모델 업데이트를 위해 전체 파일 교체가 합리적일 수 있습니다. 두 관점 사이에 필요한 것은 설명입니다.

삭제 정책도 마찬가지입니다. Chrome은 저장공간이 특정 임계값 아래로 떨어지면 모델을 자동 삭제할 수 있고, 엔터프라이즈 정책이 기능을 비활성화하거나 사용자가 30일 동안 조건을 충족하지 않는 경우에도 purge가 일어날 수 있다고 설명합니다. 삭제된 뒤에는 자동 재다운로드가 아니라 새 *.create() 호출 같은 트리거가 필요하다고 문서는 말합니다. 다만 사용자 경험에서는 "지웠는데 다시 생겼다"는 보고가 나옵니다. 이는 사용자가 모델을 지운 뒤, Chrome이나 웹 앱이 다시 다운로드 조건을 만족시킨 경우와 섞여 보일 수 있습니다.

여기서 중요한 것은 기술적으로 누가 맞느냐만이 아닙니다. 사용자가 파일을 삭제했는데 브라우저가 나중에 다시 모델을 받는다면, 사용자는 자신이 거부권을 행사했다고 느끼지 못합니다. AI 모델 다운로드는 캐시와 다르게 인식됩니다. 캐시는 웹의 오래된 비용입니다. LLM weight는 사용자의 눈에 제품 결정처럼 보입니다.

개발자는 무엇을 배워야 하나

이번 논쟁을 Google만의 PR 문제로 처리하면 배울 것이 줄어듭니다. 앞으로 OS, 브라우저, IDE, 메신저, 문서 편집기, 데이터베이스 클라이언트가 모두 로컬 또는 하이브리드 AI 모델을 품게 됩니다. 모델 파일은 앱의 일부가 되고, 모델 업데이트는 제품 업데이트와 분리되며, 정책은 기능 단위가 아니라 모델 실행 단위로 내려올 가능성이 큽니다.

첫째, AI 기능은 "서버 호출"이 아니라 "자원 배치"입니다. 서버 AI는 사용자의 데이터를 외부로 보낼 수 있습니다. 로컬 AI는 사용자의 저장공간과 연산 자원을 씁니다. 둘 다 설명이 필요합니다. 제품 문구가 "더 사적인 AI"에만 머물면 부족합니다. 얼마나 내려받는지, 언제 내려받는지, 어떻게 멈추는지, 어떤 기능이 모델을 쓰는지를 알려야 합니다.

둘째, built-in AI API를 쓰는 웹 앱은 다운로드 상태를 UX의 1급 상태로 다뤄야 합니다. 사용자가 클릭했을 때 모델이 없으면 그때부터 설치가 시작될 수 있습니다. 이때 단순 spinner는 부족합니다. 모델 다운로드가 수 GB급일 수 있고, 네트워크와 저장공간 조건 때문에 실패할 수 있습니다. 제품은 "지금 장치에 모델을 준비 중입니다", "이 기능은 로컬에서 실행됩니다", "클라우드 fallback을 사용할까요" 같은 명확한 흐름을 가져야 합니다.

셋째, 조직은 브라우저를 AI 인프라로 봐야 합니다. 지금까지 브라우저 관리는 확장 프로그램, 쿠키, DLP, 업데이트 채널, 인증 정책 중심이었습니다. 이제는 내장 모델, Prompt API, GeminiSettings, 엔터프라이즈 정책, 로컬 inference 허용 여부가 들어옵니다. 보안팀은 "데이터가 서버로 나가지 않는다"는 말만으로 안심할 수 없습니다. 로컬 모델이 어떤 입력을 처리하고, 결과가 어떤 웹 앱으로 전달되며, 어떤 로그가 남는지 봐야 합니다.

넷째, 표준화 논의가 중요합니다. Chrome 문서는 W3C Web Incubator Community Group으로 API를 제안하고 있다고 설명합니다. 브라우저별로 로컬 AI API가 다르게 움직이면 개발자는 결국 Chrome 전용 기능을 만들거나, Transformers.js/WebGPU 같은 자체 런타임을 유지하거나, 서버 fallback으로 돌아가야 합니다. 로컬 AI가 진짜 웹 기능이 되려면 API뿐 아니라 동의, 다운로드, 상태 표시, 정책 제어도 표준화 논의의 일부가 돼야 합니다.

과장도, 축소도 피해야 합니다

이번 사건은 자극적인 제목으로 번지기 쉬웠습니다. "Chrome이 몰래 4GB AI를 설치했다"는 표현은 사용자 경험의 불신을 정확히 찌릅니다. 동시에 기술적으로는 조건과 예외가 있습니다. Chrome 문서는 최초 다운로드가 built-in AI API의 create() 호출로 트리거된다고 설명하고, 장치가 조건을 만족하지 않으면 모델을 받지 않는다고 말합니다. 또한 Gemini Nano는 모바일 Chrome 전체에 배포되는 구조가 아닙니다. 따라서 모든 사용자가 같은 시점에 같은 4GB 파일을 받았다고 단정하면 안 됩니다.

하지만 "문서에 있으니 문제없다"도 부족합니다. 사용자가 제품 문서를 읽고 브라우저를 쓰지는 않습니다. 파일 시스템에서 갑자기 큰 모델 파일을 발견한 경험은 충분히 불편할 수 있습니다. 특히 Chrome처럼 수십억 사용자의 기본 브라우저에 가까운 제품에서는 기본값이 정책입니다. AI 기능을 켜는 순간만이 아니라, AI 기능을 준비하기 위해 장치에 무엇을 배치하는지도 사용자와의 계약입니다.

그래서 이 논쟁의 결론은 Chrome을 지우라는 단순한 조언이 아닙니다. 더 중요한 변화는 브라우저의 역할입니다. 브라우저는 이제 HTML, CSS, JavaScript를 실행하는 창이 아니라, 모델을 선택하고 내려받고 업데이트하고 삭제하는 AI 런타임이 되고 있습니다. 개발자에게는 새로운 기회입니다. 웹 앱이 서버 비용 없이 로컬 요약과 작성 보조를 제공할 수 있습니다. 사용자에게는 새로운 부담입니다. 저장공간과 네트워크, 동의와 통제권이 제품 경험 안으로 들어옵니다.

Gemini Nano 논쟁은 온디바이스 AI의 실패가 아닙니다. 오히려 온디바이스 AI가 실제 배포 단계에 들어왔다는 신호에 가깝습니다. 연구 데모일 때는 "로컬에서 돌아간다"가 장점으로 충분했습니다. 플랫폼 기능이 되면 "언제 받고, 어디에 저장하고, 어떻게 지우고, 누가 설명하는가"가 같은 무게의 질문이 됩니다. Chrome이 이번에 드러낸 것은 모델 성능의 문제가 아니라 모델 배포의 UX입니다. AI가 브라우저 안으로 들어오는 순간, 브라우저도 앱스토어처럼 배포 책임을 져야 합니다.