따라서 이 사안을 곧바로 “입증된 개인정보 스캔들”로 단정하는 것도, 반대로 “그냥 평범한 업데이트”라고 넘기는 것도 성급하다. 핵심은 로컬 AI가 브라우저에 들어올 때 사용자와 관리자가 어떤 통제권을 갖느냐다.
4GB라는 숫자는 눈에 띈다. 저장공간이 빠듯한 노트북이나 저가형 PC에서는 결코 작은 용량이 아니다. 하지만 개인정보 보호의 관점에서 큰 파일 자체가 곧바로 문제는 아니다. 진짜 쟁점은 새 구성요소가 설치됐는데도 사용자가 무엇이 들어왔는지, 언제 작동하는지, 어떤 데이터를 다루는지, 어떻게 끌 수 있는지 알기 어렵다면 그때 생긴다.
브라우저 AI는 단순한 내부 최적화가 아니다. 구글은 크롬 Built-in AI를 웹 애플리케이션이 브라우저 관리 모델을 이용해 AI 작업을 수행할 수 있는 API 체계로 설명한다 . 구글 I/O 자료도 번역, 요약, 글쓰기, 문장 다시 쓰기 같은 기능을 예시로 든다
. 즉 AI가 브라우저 내부로 들어온다는 것은 웹페이지와 웹앱이 새로운 방식으로 텍스트와 사용 맥락을 처리할 수 있게 된다는 뜻이다.
그렇다면 사용자에게 필요한 것은 “디스크를 몇 GB 사용합니다”라는 안내에 그치지 않는다. “이 AI 기능이 어떤 목적으로 쓰이는가”, “내가 방문한 사이트가 이 모델을 호출할 수 있는가”, “처리는 정말 내 기기 안에서 끝나는가”, “구글 또는 제3자 서버로 추가 정보가 전송되는가” 같은 질문에 답할 수 있어야 한다.
개인정보 위험은 목적에 따라 크게 달라진다. 로컬 모델이 맞춤법 보정이나 번역, 요약에 쓰이는 경우와 피싱 탐지 같은 보안 기능에 쓰이는 경우는 사용자 기대와 데이터 처리 맥락이 다르다.
구글의 크롬 Built-in AI 문서와 Google I/O 자료는 번역, 요약, 글쓰기, 다시 쓰기 같은 작업을 설명한다 . 한편 Infosecurity Magazine은 구글이 크롬 137에서 세이프 브라우징의 Enhanced Protection 모드에 제미나이 나노를 실험적으로 통합해 스팸, 사기, 피싱에 대한 추가 보호 계층으로 활용한다고 보도했다
.
이런 기능은 분명 유용할 수 있다. 피싱을 더 잘 걸러내거나, 웹앱이 클라우드 호출 없이 요약 기능을 제공한다면 사용자 입장에서도 장점이 있다. 그러나 바로 그렇기 때문에 설정은 더 세분화돼야 한다. 사용자는 로컬 AI를 편의 기능에 쓸지, 보안 기능에만 쓸지, 개발자 API 접근을 허용할지, 아니면 아예 쓰지 않을지 구분해서 선택할 수 있어야 한다. 목적 설명이 흐릿하면 브라우저 업데이트는 금세 ‘조용한 기능 확장’처럼 느껴진다.
구글은 제미나이 나노 관련 온디바이스 문서에서 네트워크 연결이나 클라우드 전송 없이 생성형 AI 경험을 제공할 수 있다고 설명한다 . 이것이 로컬 AI의 가장 큰 개인정보 보호 장점이다. 사용자가 입력한 내용이 실제로 기기 안에 머문다면, 클라우드로 보내지는 데이터 흐름은 줄어들 수 있다.
하지만 “로컬에서 처리된다”는 말만으로 모든 의문이 사라지지는 않는다. 최소한 다음 질문은 남는다.
크롬 문서는 웹 애플리케이션이 Built-in AI API를 통해 브라우저 관리 모델을 사용할 수 있음을 보여준다 . 그래서 개인정보 논의의 대상은 모델 파일 하나가 아니다. 그 모델을 둘러싼 권한 체계, API 접근, 표시 방식, 로그와 진단 데이터까지 함께 봐야 한다.
브라우저는 사용자의 가장 민감한 정보가 지나는 공간이다. 로그인 화면, 결제 양식, 회사 문서, 이메일, 채팅, 고객 상담 기록, 내부 업무 시스템이 모두 브라우저 안에서 열린다. AI 기능이 텍스트를 번역하거나 요약하고, 글을 작성하거나 다시 쓰는 과정에서 이런 내용과 마주칠 수 있다 .
물론 처리가 실제로 로컬에서만 이뤄진다면 자동으로 클라우드에 보내는 방식보다 개인정보 보호에 유리할 수 있다 . 그래도 사용자는 AI가 언제 작동하는지, 어떤 정보가 처리 대상이 되는지 볼 수 있어야 한다. 웹페이지가 모델을 호출하는지, 크롬 자체 기능이 호출하는지, 또는 사용자가 명시적으로 버튼을 눌렀을 때만 작동하는지에 따라 의미가 달라진다.
좋은 구현이라면 웹사이트나 브라우저 기능이 로컬 모델을 사용할 때 이를 명확히 표시해야 한다. 또한 해당 처리가 순수하게 기기 안에서 끝나는지, 아니면 구글이나 다른 서비스로 추가 데이터가 전송되는지 쉽게 확인할 수 있어야 한다. 현재 공개된 크롬 AI 문서는 Built-in AI API의 존재를 설명하지만, 이런 세부적인 통제와 텔레메트리 질문을 모두 해소한다고 보기는 어렵다 .
이번 논란에서 가장 민감한 대목은 단순히 “다운로드됐는가”가 아니다. 사용자가 원하지 않을 때 멈출 수 있는가가 핵심이다. 여러 보도는 문제의 파일을 수동 삭제해도 다시 내려받아지고, 일반 크롬 설정에서 쉽게 찾을 수 있는 옵트아웃이 없다고 주장했다 .
만약 이 주장이 사실이라면 사용자 자율성 측면에서 심각한 문제다. 삭제가 실제 삭제가 아니고, 사용하지 않는다는 선택이 명확한 거부로 처리되지 않는 셈이기 때문이다. 보통의 개인 사용자에게는 저장공간, 데이터 사용량, 신뢰의 문제다. 기업에는 여기에 소프트웨어 자산 관리, 사전 승인 절차, 브라우저 정책, 규제 환경에서의 AI 구성요소 관리가 더해진다. 일부 보도는 이 사안을 벤더 리스크와 컴플라이언스 문제로도 다뤘다 .
현재 공개된 자료만으로 법 위반을 확정하기는 어렵다. 실제 배포 방식, 사용자 안내, 설정 화면, 활성화 조건, 데이터 흐름을 더 정확히 알아야 하기 때문이다. 다만 일부 개인정보 관련 보도는 이 사안이 유럽연합 개인정보보호법인 GDPR, 독일어권에서 흔히 DSGVO라고 부르는 규정의 투명성·개인정보 보호 중심 설계 원칙, 그리고 단말기 저장·접근에 관한 ePrivacy 규정과 관련될 수 있다고 지적했다 .
여기서도 구분이 필요하다. 모델 파일은 크다는 이유만으로 곧장 개인정보 침해가 되지는 않는다. 개인정보법적으로 민감해지는 지점은 크롬이 사용자에게 명확히 알리지 않은 채 사용자 콘텐츠를 처리할 수 있는 구성요소를 설치했는지, 또는 텔레메트리·활성화 정보·사용 데이터가 충분히 설명되지 않은 채 수집되거나 전송되는지다.
브라우저 안의 로컬 AI가 신뢰를 얻으려면 최소한 다음 기준이 필요하다.
이 조건들은 단순한 법적 형식이 아니다. 사용자가 온디바이스 AI를 개인정보 보호의 개선으로 받아들일지, 아니면 잘 보이지 않는 새 브라우저 계층으로 받아들일지를 가르는 기준이다.
크롬 Built-in AI와 제미나이 나노의 연결은 공식 문서로 확인된다 . 그러나
weights.bin이라는 약 4GB 파일이 조용히 다운로드됐고, 삭제 후에도 다시 내려받아졌다는 구체적 주장은 여러 보도로 제기됐지만, 해당 크롬 개발자 문서에서 같은 수준으로 공식 확인되지는 않는다 .