크롬이 동의 없이 4GB 온디바이스 AI 모델을 깔고 있다는 주장

크롬이 4GB 모델을 몰래 깔았다는 문제 제기

• 작성자의 핵심 주장은 꽤 직설적임. 크롬이 사용자에게 묻지 않고 제미나이 나노 온디바이스 모델을 디스크에 설치했다는 것.

  • 파일 이름은 weights.bin, 위치는 크롬 프로필 아래 OptGuideOnDeviceModel 디렉터리.
  • 크기는 약 4GB이고, 크롬의 글쓰기 보조, 사기 탐지, 페이지 요약 같은 AI 기능에 쓰이는 모델 가중치로 설명됨.

• 더 찝찝한 부분은 “삭제하면 끝”이 아니라는 점임.

  • 여러 윈도우 사용자 보고에서 파일을 지워도 크롬이 다시 내려받는 패턴이 나왔다고 함.
  • 지속적으로 막으려면 chrome://flags나 기업 정책 도구로 AI 기능을 꺼야 하는데, 일반 사용자가 자연스럽게 찾을 만한 경로는 아님.

• 작성자는 이걸 단순한 저장공간 낭비가 아니라 “신뢰 경계 침범”으로 봄.

  • 사용자가 브라우저를 설치한 건 웹페이지를 보기 위해서지, 별도 목적의 대규모 머신러닝 모델을 사전 배치하라고 허락한 건 아니라는 논리.
  • 내부 폴더명도 GeminiNanoLLM처럼 알아보기 쉬운 이름이 아니라 OptGuideOnDeviceModel이라 일반 사용자가 정체를 파악하기 어렵다고 비판함.

맥오에스에서 남은 증거 체인

• 작성자는 윈도우 커뮤니티 제보만으로는 구글이 “특수한 환경의 일화”라고 볼 수 있다고 보고, 새 애플 실리콘 환경에서 직접 흔적을 추적함.

  • 2026년 4월 23일 자동화 감사용 크롬 사용자 데이터 디렉터리를 만들었고, 크롬 개발자 도구 프로토콜로 사이트를 열고 5분씩 머무는 방식만 사용했다고 함.
  • 사람 입력은 없었고, 주소창이나 AI 관련 UI를 클릭한 적도 없었다고 설명함.

• 결정적 로그는 맥오에스의 .fseventsd 파일시스템 이벤트 기록에서 나옴.

  • 2026년 4월 24일 16시 38분 54초에 OptGuideOnDeviceModel 디렉터리가 생성됨.
  • 16시 47분 22초에는 크롬 언패커 프로세스가 임시 디렉터리에 weights.bin, manifest.json, 검증 메타데이터, 실행 설정 파일을 씀.
  • 16시 53분 22초에는 최종 경로 OptGuideOnDeviceModel/2025.8.8.1141/weights.bin으로 이동됨.

• 전체 설치 시간은 14분 28초였고, 그동안 사용자는 아무 행동도 하지 않았다는 게 포인트임.

  • 같은 시간대에 인증서 폐기 목록 업데이트, 브라우저 프리로드 데이터 업데이트도 같이 처리됐다고 함.
  • 작성자는 크롬이 보안 업데이트와 4GB AI 모델 설치를 같은 백그라운드 작업처럼 취급한 셈이라고 꼬집음.

• 크롬 내부 상태 파일도 같은 방향을 가리킨다고 함.

  • Local State에는 모델 검증 결과와 컴포넌트 버전 2025.8.8.1141이 남아 있었고, 파일시스템 로그의 경로 버전과 맞았다고 함.
  • 하드웨어 판정 값으로 performance_class: 6, vram_mb: "36864"도 기록돼 있어, 크롬이 기기 성능을 보고 모델 배포 대상인지 판단했다는 해석을 붙임.

sequenceDiagram
    participant 크롬
    participant 구글업데이터
    participant 구글CDN
    participant 사용자프로필
    participant 맥오에스로그
    구글업데이터->>크롬: 온디바이스 모델 제어 컴포넌트 전달
    크롬->>사용자프로필: OptGuideOnDeviceModel 디렉터리 생성
    크롬->>구글CDN: 모델 가중치 다운로드 요청
    구글CDN-->>크롬: weights.bin 및 메타데이터 전달
    크롬->>사용자프로필: 4GB 모델 파일 최종 배치
    맥오에스로그->>맥오에스로그: 생성·쓰기·이동 이벤트 기록

AI 모드라는 이름이 더 헷갈리게 만든다는 지적

• 글에서 가장 날 선 부분은 크롬의 눈에 보이는 AI 기능과 로컬 모델의 관계임.

  • 크롬 147의 주소창 주변에 뜨는 AI Mode는 사용자가 보기엔 온디바이스 모델을 쓰는 기능처럼 보일 수 있음.
  • 하지만 작성자 설명에 따르면 이 기능은 클라우드 기반 검색 생성 경험으로, 입력이 구글 서버로 전송됨.

• 즉 사용자는 로컬 모델 설치 비용을 부담하지만, 가장 눈에 띄는 AI 표면에서는 그 로컬 모델의 프라이버시 이점을 얻지 못한다는 주장임.

  • 로컬 제미나이 나노는 글쓰기 보조, 탭 그룹 제안, 스마트 붙여넣기, 페이지 요약 같은 덜 눈에 띄는 기능에 쓰인다고 함.
  • 반면 주소창의 AI 모드는 별도 코드 경로로 서버 모델을 사용하니, “내 기기에서 처리되겠지”라는 직관이 틀릴 수 있다는 것.

• 작성자는 이 구성이 동의 문제를 두 겹으로 만든다고 봄.

  • 하나는 4GB 모델을 사용자 동의 없이 설치한 문제.
  • 다른 하나는 눈에 보이는 AI 기능이 로컬 처리처럼 오해될 수 있는데 실제로는 클라우드로 간다는 투명성 문제.

법적·환경적 쟁점까지 번짐

• 작성자는 유럽 전자프라이버시 지침과 개인정보보호 규정을 근거로 법적 문제가 있다고 주장함.

  • 사용자 단말에 정보를 저장하려면 사전 동의가 필요하다는 전자프라이버시 지침 조항을 끌어옴.
  • 기기 성능을 읽고 배포 대상을 판단한 점, 모델 설치와 사용 상태가 기록되는 점은 개인정보 처리의 투명성 문제로 연결함.

• 환경 비용 계산도 꽤 구체적임.

  • 모델 1회 다운로드는 4GB 전송이고, 네트워크 전송 에너지 강도를 1GB당 0.06kWh로 잡으면 기기당 0.24kWh.
  • 전력 배출계수를 1kWh당 0.25kg 이산화탄소 환산으로 잡으면 기기당 0.06kg 이산화탄소 환산 배출.

• 배포 규모에 따라 숫자가 확 커짐.

  • 1억 대면 400페타바이트, 24GWh, 6천 톤 이산화탄소 환산.
  • 5억 대면 2엑사바이트, 120GWh, 3만 톤 이산화탄소 환산.
  • 10억 대면 4엑사바이트, 240GWh, 6만 톤 이산화탄소 환산.

• 이 계산에는 빠진 것도 많다고 함.

  • 사용자가 지웠는데 다시 내려받는 재다운로드 비용은 별도.
  • 모델 업데이트 때마다 반복되는 전송 비용도 별도.
  • 실제 추론을 돌릴 때의 기기 에너지 사용량도 빠져 있음.
  • SSD에 4GB씩 장기간 점유되는 저장공간의 제조 탄소까지 따지면 더 복잡해짐.

그래서 뭘 했어야 했나

• 작성자가 제안하는 해법은 의외로 단순함. 먼저 물어보라는 것.

  • “크롬이 다음 기능을 위해 4GB AI 모델을 다운로드하려고 함. 허용할래, 나중에 할래?” 정도의 명시적 선택지만 있어도 많은 문제가 줄어든다는 주장.
  • 사용자가 처음 AI 기능을 실행할 때 모델을 받는 pull 방식이면 사전 배치 논란도 훨씬 약해짐.

• 설정 화면에서 모델 파일을 투명하게 보여줘야 한다는 요구도 나옴.

  • 어떤 모델이 몇 GB인지, 어떤 기능에 쓰이는지, 지우면 다시 받지 않게 할 수 있는지 보여줘야 한다는 것.
  • 사용자가 파일을 삭제했다면 그건 임시 오류가 아니라 의사 표현으로 존중해야 한다는 얘기임.

• 개발자 관점에서 이 이슈는 브라우저 하나의 문제가 아니라 제품 설계 철학 문제에 가까움.

  • 사용자의 기기를 벤더 로드맵을 위한 배포 표면으로 볼 것인가.
  • 아니면 사용자가 최종 통제권을 가진 개인 장비로 볼 것인가.
  • AI 기능이 기본 탑재되는 시대에는 이 질문이 앞으로 더 자주 튀어나올 가능성이 큼.

기술 맥락

• 여기서 기술적으로 중요한 선택은 모델을 “기능 실행 시 다운로드”가 아니라 “지원 기기에 미리 배포”했다는 점이에요. 미리 깔아두면 사용자가 기능을 눌렀을 때 바로 반응할 수 있지만, 그 대가로 4GB 저장공간과 네트워크 비용을 사용자가 먼저 부담하게 되거든요.

• 크롬은 기기의 성능 등급과 메모리 정보를 보고 모델 배포 가능 여부를 판단한 것으로 설명돼요. 이 방식은 제품 품질 관점에서는 자연스러워요. 낮은 사양 기기에서 모델을 돌리면 느리거나 실패할 수 있으니까요. 다만 그 판단이 사용자에게 보이지 않는 상태에서 설치까지 이어지면 개인정보 처리와 동의 문제가 같이 따라와요.

• 또 하나의 설계 포인트는 설정 UI와 다운로드 트리거가 같은 롤아웃 플래그에 묶였다는 부분이에요. 작성자 해석대로라면 사용자가 설정에서 거부할 기회를 보기 전에 설치가 시작될 수 있어요. 기능 플래그는 실험과 배포에는 편하지만, 사용자 동의가 필요한 동작까지 같이 묶으면 제품 제어와 권리 행사가 뒤섞여요.

• 온디바이스 AI 자체는 나쁜 선택이 아니에요. 서버 왕복 없이 빠르게 처리하고, 입력을 기기 밖으로 덜 보내는 장점이 있으니까요. 문제는 로컬 모델이 깔렸다는 사실과 실제로 어떤 AI 기능이 로컬 또는 클라우드에서 도는지가 명확히 연결되지 않았다는 점이에요.