Chrome 140 기준
IT/AI
크롬 내장 AI, 무료라서 쓸 만할까요?
크롬에 AI가 탑재됐다는 소식은 들었을 겁니다. 근데 실제로 써보면 서버 API보다 6배 느리고, 사용자의 59.3%는 아예 쓰지도 못합니다. 그런데도 구글은 계속 밀어붙이고 있고, 이 방향이 결국 중요한 이유가 있습니다.
크롬 내장 AI가 뭔지부터 짚고 가겠습니다
크롬에 AI가 들어온 지는 사실 꽤 됐습니다
구글은 크롬 브라우저 안에 Gemini Nano라는 소형 AI 모델을 직접 탑재하기 시작했습니다. 단순히 ‘검색창 옆에 AI 버튼 추가’가 아니라, 브라우저 자체가 로컬 AI 추론을 실행하는 구조입니다. Chrome 138부터 Translator API, Summarizer API, Language Detector API, Prompt API 등이 정식 지원되기 시작했습니다. (출처: Chrome Built-in AI API 공식 문서)
Chrome 140에서 무슨 일이 생겼냐면
2025년 10월부터 구글은 Gemini Nano의 CPU 지원을 Chrome 140에서 정식 출시했습니다. 기존에는 GPU가 있는 기기에서만 작동했는데, 이제 Linux·macOS·Windows 환경의 CPU만으로도 돌아갑니다. 이론상으로는 더 많은 기기에서 쓸 수 있게 된 겁니다. (출처: Chrome for Developers 공식 블로그, 2025.10.01)
사용자가 체감하는 모습은 이렇습니다
특정 웹사이트가 크롬 내장 AI에 요청을 보내면, 브라우저가 자체적으로 약 1.5~2GB 크기의 모델 파일을 사용자 기기에 백그라운드로 내려받습니다. 서버에 데이터를 보내지 않고 로컬에서 처리하기 때문에 ‘프라이버시 친화적’이라는 게 구글의 설명입니다. 다운로드가 진행되는 동안 아무런 알림도 없습니다.
무료인데 왜 서버 API보다 6배 더 느릴까요?
💡 공식 발표는 ‘로컬 처리라서 빠르다’고 했지만, 실측 데이터를 같이 놓고 보니 정반대 결과가 나왔습니다.
실측 수치를 보면 충격적입니다
이메일 마케팅 툴 SendCheckIt이 12,524회의 AI 생성 작업을 836명의 사용자에게 실측한 결과, Gemini Nano(온디바이스)의 중앙값 응답 시간은 7.7초였습니다. 반면 OpenRouter를 통한 서버 기반 Gemma 3N 모델의 중앙값은 1.3초였습니다. 즉 네트워크 왕복 시간이 발생하는 서버 API가 오히려 5.9배 더 빠릅니다. (출처: SendCheckIt 실측 보고서, 2026.01)
| 모델 | 중앙값(p50) | p99 (상위 1%) | 최악의 경우 |
|---|---|---|---|
| Gemini Nano (온디바이스) | 7.7초 | 52.9초 | 9분+ |
| Gemma 3N (서버 API) | 1.3초 | 2.4초 | 31초 |
※ 출처: SendCheckIt 실측 (2026년 1월 기준, 12,524회 AI 생성 기록)
왜 이런 결과가 나왔을까요?
‘로컬 처리 = 네트워크 지연 없음 = 빠름’이라는 공식이 성립하지 않는 이유는 간단합니다. 데이터센터 GPU의 연산 속도가 일반 노트북 GPU를 압도하기 때문입니다. 네트워크 왕복 시간으로 손해 보는 것보다, 로컬 하드웨어가 처리를 느리게 해서 잃는 시간이 훨씬 큽니다. 이 수치가 중요한 이유는, 응답이 7.7초 이상 걸리는 서비스에서 사용자 이탈이 시작된다는 점에서입니다. UX 관점에서 Gemini Nano는 현재 상태로는 프로덕션에서 쓰기 어렵습니다.
40.7%만 쓸 수 있다는 게 무슨 뜻인가요?
조건이 생각보다 까다롭습니다
Gemini Nano를 실제로 실행하려면 단순히 ‘최신 크롬 버전’이면 되는 게 아닙니다. Chrome 138 이상 + 데스크톱 + 영어 언어 설정이 기본 조건이고, 여기에 CPU·GPU·운영체제별 하드웨어 벤치마크를 통과해야 합니다. 구글은 이 기준을 공개하지 않습니다. 836명의 실사용자를 대상으로 한 측정에서 Gemini Nano를 실제로 사용할 수 있었던 비율은 40.7%(340명)였습니다. (출처: SendCheckIt, 2026.01)
📊 사용자 퍼널 (실측)
전체 방문자 100% → Gemini Nano 적격자 40.7% → 모델 이미 다운로드 완료 ~25%
전체 방문자 중 실시간으로 Nano를 쓸 수 있는 사람은 약 10% 수준이었습니다.
한국 사용자라면 조건이 하나 더 있습니다
현재 Gemini Nano의 내장 AI 기능은 영어 환경에서만 동작하는 항목이 많습니다. Translator API·Language Detector API는 Chrome 138부터 정식 지원되어 한국어 번역은 가능하지만, Prompt API(직접 언어 모델에 질의하는 기능)는 여전히 영어 크롬 환경 기준입니다. 한국어 설정으로 크롬을 쓰는 사람에게는 40.7%라는 수치도 실제로는 더 낮아질 수 있습니다.
1.9분 다운로드, 사용자는 알까요?
모델 파일은 약 1.5GB, 중앙값 기준 다운로드 시간은 1.9분입니다. 그리고 이 과정에서 아무런 알림이 없습니다. 확인 창도 없고, 진행 표시줄도 없이 백그라운드에서 대용량 파일이 기기에 설치됩니다. 기술적으로는 매끄럽지만, 사용자 동의 측면에서는 논란이 있을 수 있는 방식입니다.
Chrome 140 CPU 지원 확대, 이게 좋은 소식만은 아닙니다
💡 확대 발표만 보면 ‘더 많은 기기에서 쓸 수 있게 됐다’는 걸로 읽히지만, 실제 수치와 함께 보면 이야기가 달라집니다.
GPU 없이도 된다는 건, 느린 기기에서도 돌린다는 뜻입니다
Chrome 140에서 CPU 지원이 추가된 것은 사실입니다. 이전에는 GPU가 장착된 일부 기기에서만 Nano가 실행됐습니다. 이제 GPU 없이도 Linux·macOS·Windows에서 CPU만으로 실행할 수 있습니다. (출처: Chrome for Developers 공식 블로그, 2025.10.01) 그런데 이미 GPU 환경에서도 7.7초가 나오는 모델이, CPU로만 돌아간다면 어떨까요? 공식 문서 자체도 “CPU는 GPU보다 느릴 수 있다”고 명시하고 있습니다.
실제로는 어떤 차이를 만드냐면
SendCheckIt 실측 데이터에서 Nano의 p99(상위 1% 느린 케이스) 응답 시간은 52.9초였고, 최악의 경우는 9분이 넘었습니다. 이 극단적 수치의 원인으로 지목된 것이 ‘실제로 처리하기 어려운 하드웨어에서 실행된 케이스’였습니다. CPU 지원 확대는 이런 하드웨어 폭을 더 넓히는 방향입니다. 사용 가능한 사람이 늘어나는 동시에, 느린 사람도 더 늘어납니다.
Gemma 3N과 Nano의 성능 격차도 확인할 필요가 있습니다
서버 기반 대체재로 사용된 Gemma 3N은 파라미터 수 6B, 컨텍스트 창 32K입니다. Nano는 파라미터 1.8B, 컨텍스트 6K입니다. 즉 무료 서버 API가 온디바이스 모델보다 규모도 크고 빠릅니다. 이 수치가 의미하는 건, 현재 시점에서 크롬 내장 AI는 ‘비용 이점’이 아니라 ‘프라이버시 이점’을 위해 택해야 한다는 겁니다.
무료라도 이 경우엔 쓰지 않는 게 낫습니다
서비스 응답 시간이 핵심인 경우
검색 결과 즉시 표시, 실시간 추천, 챗봇 응답처럼 응답 속도가 UX의 핵심인 기능에는 현재 크롬 내장 AI를 그대로 쓰는 건 무리입니다. 중앙값 7.7초는 사용자가 ‘느리다’고 이탈하기 충분한 시간입니다. 이 경우엔 서버 API 폴백을 기본으로 두고, Nano는 보조 수단으로 다뤄야 합니다.
모든 사용자에게 동일한 경험을 줘야 할 때
사용자의 59.3%는 Nano를 실행하지 못합니다. 이 상태에서 Nano만 쓰면 10명 중 6명은 기능 자체를 못 씁니다. 특히 모바일 사용자, 한국어 환경 사용자, Chrome 138 미만 사용자는 아예 대상 밖입니다. 일관된 서비스 경험이 필요하다면 서버 기반 AI와의 혼용 전략이 필수입니다.
반대로, 이런 경우엔 지금도 의미 있습니다
사용자 데이터를 서버에 전송하지 않아야 하는 경우, 즉 민감한 개인 정보·의료 정보·법률 문서 처리처럼 프라이버시가 최우선인 상황에서는 Nano의 로컬 처리 방식이 진짜 가치를 발휘합니다. 속도보다 데이터 보호가 중요한 B2B 인트라넷 환경이나 기업 내부 툴에서의 활용이 현시점에서 가장 현실적인 적용 사례입니다.
그런데 왜 구글은 계속 밀어붙일까요?
💡 성능이 현재 좋지 않은데도 구글이 크롬 내장 AI에 투자를 늘리는 이유를, 공식 로드맵과 WebMCP 방향성을 같이 놓고 보니 윤곽이 잡혔습니다.
WebMCP와 연결될 때 그림이 달라집니다
2026년 3월 11일 구글은 WebMCP에 관한 공식 가이드를 업데이트했습니다. WebMCP는 AI 에이전트가 웹 페이지의 DOM에 직접 접근하게 해주는 표준입니다. 기존 MCP(Model Context Protocol)가 서버 사이드 데이터와 외부 도구에 연결됐다면, WebMCP는 브라우저 안의 UI 요소 자체를 AI의 도구로 만듭니다. (출처: Chrome for Developers WebMCP 공식 블로그, 2026.03.11)
이 방향이 완성되면 어떻게 됩니까
크롬 내장 AI + WebMCP가 맞물리면, 브라우저 안에서 AI가 로컬로 판단하고 직접 버튼을 클릭하거나 양식을 채우는 흐름이 만들어집니다. 서버에 아무것도 보내지 않고 기기 안에서 자율적으로 작동하는 에이전트입니다. 지금의 7.7초짜리 느린 Nano는 이 생태계를 위한 기반 작업에 가깝습니다. 하드웨어와 최적화가 따라오면 속도 문제는 결국 해결됩니다.
현재 개발자에게 실질적으로 남는 것
지금 크롬 내장 AI를 프로덕션에 그냥 쓰는 건 이릅니다. 다만 Summarizer API, Translator API처럼 이미 Chrome 138에서 정식화된 기능은 폴백 구조와 함께 써볼 수 있는 단계입니다. Nano를 단독으로 믿지 말고, 서버 API와 병렬 구성하되 데이터가 외부로 나가지 않아야 하는 맥락에서 Nano를 우선 호출하는 방식이 현실적입니다.
자주 묻는 질문
Q. 크롬 내장 AI를 쓰려면 따로 설치하거나 신청해야 하나요?
Q. 내 기기에서 Gemini Nano가 실행 가능한지 어떻게 확인하나요?
chrome://flags에서 관련 플래그 확인이 가능하지만, 공식 API를 통해 window.ai.languageModel.capabilities()를 호출해 지원 여부를 확인하는 방법이 더 정확합니다. 하드웨어 벤치마크 기준 자체는 구글이 공개하지 않습니다.
Q. 다운로드된 1.5GB 모델 파일은 어디에 저장되나요?
Q. 크롬 내장 AI로 한국어 처리도 되나요?
Q. WebMCP는 지금 바로 사용할 수 있나요?
마치며 — 지금 당장은 아니어도 방향은 맞습니다
솔직히 말하면, 크롬 내장 AI를 지금 프로덕션에 그냥 투입하면 UX가 망가질 가능성이 높습니다. 6배 느린 속도와 60% 사용자 제외라는 현실은 냉정합니다. 구글 공식 발표에서 ‘더 많은 기기 지원’이라는 표현은 사실이지만, 그게 ‘더 좋은 성능’을 뜻하지는 않습니다.
그런데도 이 흐름을 무시하기 어렵습니다. WebMCP, CPU 지원 확대, Summarizer·Translator API 정식화 같은 움직임들은 하나의 방향을 가리킵니다. 브라우저가 AI의 실행 환경이 되는 세계입니다. 지금은 기반을 닦는 시기이고, 하드웨어가 최적화를 따라잡으면 7.7초는 1초 이하로 줄어들 겁니다.
개인적인 판단으로는, 크롬 내장 AI를 지금 당장 메인으로 쓸 이유는 없습니다. 대신 폴백 구조와 함께 테스트를 시작하고, WebMCP가 정식화될 때 빠르게 올라탈 수 있는 준비를 해두는 게 현실적입니다. 이게 바로 지금 시점에 알아둬야 하는 이유입니다.
📌 본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 크롬 내장 AI 관련 기능은 Chrome 버전 업데이트에 따라 지원 범위가 빠르게 변경됩니다. 최신 정보는 Chrome for Developers 공식 문서에서 직접 확인하세요.
댓글 남기기