크롬과 제미나이 나노를 둘러싼 논란은 겉으로는 “4GB짜리 AI 모델이 몰래 설치됐느냐”에 집중돼 있다. 하지만 개인정보 관점에서 더 중요한 질문은 따로 있다. 브라우저가 새 AI 계층을 도입할 때, 사용자가 그것을 알 수 있는가. 어떤 기능에 쓰이는지 이해할 수 있는가. 끌 수 있고, 지울 수 있으며, 관리자가 통제할 수 있는가.

먼저 나눠 봐야 할 것: 확인된 사실과 보도된 주장

공식 문서로 확인되는 부분부터 보자. 구글은 크롬을 ‘Built-in AI’ 플랫폼으로 설명한다. 웹사이트와 웹 애플리케이션이 브라우저가 관리하는 AI 모델과 API를 통해 AI 작업을 수행할 수 있다는 설명이며, 관련 크롬 문서에는 제미나이 나노가 명시돼 있다 ^[17][18]. 또 Built-in AI 문서는 애플리케이션이 더 빠르게 시작되도록 모델을 기기 안에 캐시할 수 있다고 설명한다 ^[18]. 구글 개발자 블로그도 LiteRT-LM이 크롬 등 구글 제품에서 온디바이스 제미나이 나노를 가능하게 한다고 소개했다 ^[20].

반면 아직 공식 문서만으로 단정하기 어려운 부분이 있다. 여러 매체와 블로그는 크롬이 사용자 프로필 폴더의 OptGuideOnDeviceModel 안에 약 4GB 크기의 weights.bin 모델 파일을 저장했으며, 명확한 안내 없이 내려받았고, 사용자가 수동으로 삭제해도 다시 다운로드된다고 주장했다 ^{[2][3][7][10][14]}. 그러나 여기서 중요한 차이가 있다. 구글의 크롬 개발자 문서는 Built-in AI와 온디바이스 캐싱 자체는 설명하지만, 이 논란에서 언급되는 정확한 파일 크기, 파일명, 삭제 후 재설치 동작을 해당 문서에서 명확히 확인해 주지는 않는다 ^[17][18].

따라서 이 사안을 곧바로 “입증된 개인정보 스캔들”로 단정하는 것도, 반대로 “그냥 평범한 업데이트”라고 넘기는 것도 성급하다. 핵심은 로컬 AI가 브라우저에 들어올 때 사용자와 관리자가 어떤 통제권을 갖느냐다.

파일 크기보다 투명성이 더 중요하다

4GB라는 숫자는 눈에 띈다. 저장공간이 빠듯한 노트북이나 저가형 PC에서는 결코 작은 용량이 아니다. 하지만 개인정보 보호의 관점에서 큰 파일 자체가 곧바로 문제는 아니다. 진짜 쟁점은 새 구성요소가 설치됐는데도 사용자가 무엇이 들어왔는지, 언제 작동하는지, 어떤 데이터를 다루는지, 어떻게 끌 수 있는지 알기 어렵다면 그때 생긴다.

브라우저 AI는 단순한 내부 최적화가 아니다. 구글은 크롬 Built-in AI를 웹 애플리케이션이 브라우저 관리 모델을 이용해 AI 작업을 수행할 수 있는 API 체계로 설명한다 ^[17][18]. 구글 I/O 자료도 번역, 요약, 글쓰기, 문장 다시 쓰기 같은 기능을 예시로 든다 ^[28]. 즉 AI가 브라우저 내부로 들어온다는 것은 웹페이지와 웹앱이 새로운 방식으로 텍스트와 사용 맥락을 처리할 수 있게 된다는 뜻이다.

그렇다면 사용자에게 필요한 것은 “디스크를 몇 GB 사용합니다”라는 안내에 그치지 않는다. “이 AI 기능이 어떤 목적으로 쓰이는가”, “내가 방문한 사이트가 이 모델을 호출할 수 있는가”, “처리는 정말 내 기기 안에서 끝나는가”, “구글 또는 제3자 서버로 추가 정보가 전송되는가” 같은 질문에 답할 수 있어야 한다.

제미나이 나노는 크롬에서 무엇에 쓰일 수 있나

개인정보 위험은 목적에 따라 크게 달라진다. 로컬 모델이 맞춤법 보정이나 번역, 요약에 쓰이는 경우와 피싱 탐지 같은 보안 기능에 쓰이는 경우는 사용자 기대와 데이터 처리 맥락이 다르다.

구글의 크롬 Built-in AI 문서와 Google I/O 자료는 번역, 요약, 글쓰기, 다시 쓰기 같은 작업을 설명한다 ^[17][18][28]. 한편 Infosecurity Magazine은 구글이 크롬 137에서 세이프 브라우징의 Enhanced Protection 모드에 제미나이 나노를 실험적으로 통합해 스팸, 사기, 피싱에 대한 추가 보호 계층으로 활용한다고 보도했다 ^[25].

이런 기능은 분명 유용할 수 있다. 피싱을 더 잘 걸러내거나, 웹앱이 클라우드 호출 없이 요약 기능을 제공한다면 사용자 입장에서도 장점이 있다. 그러나 바로 그렇기 때문에 설정은 더 세분화돼야 한다. 사용자는 로컬 AI를 편의 기능에 쓸지, 보안 기능에만 쓸지, 개발자 API 접근을 허용할지, 아니면 아예 쓰지 않을지 구분해서 선택할 수 있어야 한다. 목적 설명이 흐릿하면 브라우저 업데이트는 금세 ‘조용한 기능 확장’처럼 느껴진다.

“기기 내 처리”는 장점이지만, 만능 면죄부는 아니다

구글은 제미나이 나노 관련 온디바이스 문서에서 네트워크 연결이나 클라우드 전송 없이 생성형 AI 경험을 제공할 수 있다고 설명한다 ^[19]. 이것이 로컬 AI의 가장 큰 개인정보 보호 장점이다. 사용자가 입력한 내용이 실제로 기기 안에 머문다면, 클라우드로 보내지는 데이터 흐름은 줄어들 수 있다.

하지만 “로컬에서 처리된다”는 말만으로 모든 의문이 사라지지는 않는다. 최소한 다음 질문은 남는다.

• 어떤 콘텐츠가 로컬 모델에 전달되는가.
• 어떤 크롬 기능이나 웹 애플리케이션이 모델을 호출할 수 있는가.
• 프롬프트, 출력값, 오류, 사용량 통계, 텔레메트리가 저장되거나 전송되는가.
• 모델 업데이트는 어떤 방식으로 배포되는가.
• 사용자가 삭제하거나 비활성화한 모델이 다시 설치되지 않도록 보장되는가.

크롬 문서는 웹 애플리케이션이 Built-in AI API를 통해 브라우저 관리 모델을 사용할 수 있음을 보여준다 ^[17][18]. 그래서 개인정보 논의의 대상은 모델 파일 하나가 아니다. 그 모델을 둘러싼 권한 체계, API 접근, 표시 방식, 로그와 진단 데이터까지 함께 봐야 한다.

민감한 정보가 오가는 브라우저에는 더 분명한 경계가 필요하다

브라우저는 사용자의 가장 민감한 정보가 지나는 공간이다. 로그인 화면, 결제 양식, 회사 문서, 이메일, 채팅, 고객 상담 기록, 내부 업무 시스템이 모두 브라우저 안에서 열린다. AI 기능이 텍스트를 번역하거나 요약하고, 글을 작성하거나 다시 쓰는 과정에서 이런 내용과 마주칠 수 있다 ^[28].

물론 처리가 실제로 로컬에서만 이뤄진다면 자동으로 클라우드에 보내는 방식보다 개인정보 보호에 유리할 수 있다 ^[19]. 그래도 사용자는 AI가 언제 작동하는지, 어떤 정보가 처리 대상이 되는지 볼 수 있어야 한다. 웹페이지가 모델을 호출하는지, 크롬 자체 기능이 호출하는지, 또는 사용자가 명시적으로 버튼을 눌렀을 때만 작동하는지에 따라 의미가 달라진다.

좋은 구현이라면 웹사이트나 브라우저 기능이 로컬 모델을 사용할 때 이를 명확히 표시해야 한다. 또한 해당 처리가 순수하게 기기 안에서 끝나는지, 아니면 구글이나 다른 서비스로 추가 데이터가 전송되는지 쉽게 확인할 수 있어야 한다. 현재 공개된 크롬 AI 문서는 Built-in AI API의 존재를 설명하지만, 이런 세부적인 통제와 텔레메트리 질문을 모두 해소한다고 보기는 어렵다 ^[17][18].

옵트아웃과 삭제 가능성이 신뢰의 시험대다

이번 논란에서 가장 민감한 대목은 단순히 “다운로드됐는가”가 아니다. 사용자가 원하지 않을 때 멈출 수 있는가가 핵심이다. 여러 보도는 문제의 파일을 수동 삭제해도 다시 내려받아지고, 일반 크롬 설정에서 쉽게 찾을 수 있는 옵트아웃이 없다고 주장했다 ^{[3][7][10][14]}.

만약 이 주장이 사실이라면 사용자 자율성 측면에서 심각한 문제다. 삭제가 실제 삭제가 아니고, 사용하지 않는다는 선택이 명확한 거부로 처리되지 않는 셈이기 때문이다. 보통의 개인 사용자에게는 저장공간, 데이터 사용량, 신뢰의 문제다. 기업에는 여기에 소프트웨어 자산 관리, 사전 승인 절차, 브라우저 정책, 규제 환경에서의 AI 구성요소 관리가 더해진다. 일부 보도는 이 사안을 벤더 리스크와 컴플라이언스 문제로도 다뤘다 ^[1][12].

GDPR·ePrivacy 관점: 가능성은 있지만 위반 단정은 이르다

현재 공개된 자료만으로 법 위반을 확정하기는 어렵다. 실제 배포 방식, 사용자 안내, 설정 화면, 활성화 조건, 데이터 흐름을 더 정확히 알아야 하기 때문이다. 다만 일부 개인정보 관련 보도는 이 사안이 유럽연합 개인정보보호법인 GDPR, 독일어권에서 흔히 DSGVO라고 부르는 규정의 투명성·개인정보 보호 중심 설계 원칙, 그리고 단말기 저장·접근에 관한 ePrivacy 규정과 관련될 수 있다고 지적했다 ^[12][13].

여기서도 구분이 필요하다. 모델 파일은 크다는 이유만으로 곧장 개인정보 침해가 되지는 않는다. 개인정보법적으로 민감해지는 지점은 크롬이 사용자에게 명확히 알리지 않은 채 사용자 콘텐츠를 처리할 수 있는 구성요소를 설치했는지, 또는 텔레메트리·활성화 정보·사용 데이터가 충분히 설명되지 않은 채 수집되거나 전송되는지다.

개인정보 친화적인 브라우저 AI라면 갖춰야 할 조건

브라우저 안의 로컬 AI가 신뢰를 얻으려면 최소한 다음 기준이 필요하다.

• 대형 AI 구성요소를 설치하기 전 이해하기 쉬운 업데이트 안내를 제공할 것.
• 모델을 켜고, 끄고, 제거할 수 있는 명확한 설정을 제공할 것.
• 삭제한 모델이 언제, 어떤 조건에서 다시 내려받아지는지 설명할 것.
• 편의 기능, 보안 기능, 개발자 API를 별도 스위치로 구분할 것.
• 로컬 처리 범위, 가능한 클라우드 호출, 텔레메트리를 문서화할 것.
• 기업과 공공기관 관리자를 위한 정책 제어 수단을 제공할 것.
• 웹사이트나 크롬 기능이 로컬 모델을 사용할 때 눈에 보이는 표시를 제공할 것.

이 조건들은 단순한 법적 형식이 아니다. 사용자가 온디바이스 AI를 개인정보 보호의 개선으로 받아들일지, 아니면 잘 보이지 않는 새 브라우저 계층으로 받아들일지를 가르는 기준이다.

결론: 로컬 AI 자체보다 설명과 선택권이 관건

크롬 Built-in AI와 제미나이 나노의 연결은 공식 문서로 확인된다 ^[17][18]. 그러나 weights.bin이라는 약 4GB 파일이 조용히 다운로드됐고, 삭제 후에도 다시 내려받아졌다는 구체적 주장은 여러 보도로 제기됐지만, 해당 크롬 개발자 문서에서 같은 수준으로 공식 확인되지는 않는다 ^{[2][3][7][10][14][17][18]}.

따라서 지금 필요한 평가는 차분해야 한다. 로컬 AI의 존재 자체가 곧 문제는 아니다. 입력과 출력이 실제로 기기 안에 머문다면 온디바이스 AI는 개인정보 보호에 도움이 될 수 있다 ^[19]. 하지만 크롬이 어떤 AI 구성요소를 설치하는지, 그 목적이 무엇인지, 어떤 데이터 흐름이 생기는지, 사용자와 관리자가 이를 실질적으로 끄거나 제거할 수 있는지를 명확히 설명하지 못한다면 논란은 계속될 수밖에 없다.