“Gemini가 내 탭 내용을 읽는다”는 말을 들었을 때, 막연하게 느껴지는 사람이 많다. 어떻게 읽는다는 건지, 어디로 보내는 건지, 내 데이터는 어디서 처리되는지. 사용자 입장에서는 그냥 사이드바에 물어보면 답이 온다는 사실만 보이고, 그 사이에 무슨 일이 일어나는지는 완전히 블랙박스다.
개발자라면 이 블랙박스가 불편하다. Chrome에 Gemini를 활용한 기능을 만들어보려고 했을 때, 처음 맞닥뜨리는 질문이 “Prompt API가 뭐고, 탭 컨텍스트는 어떻게 주입되며, 온디바이스와 클라우드 중 어디서 처리되는 건지”다. 공식 문서는 각 API 사용법은 알려주지만, 전체 흐름이 어떻게 연결되는지를 한눈에 보여주지는 않는다.
Chrome이 브라우저를 AI 플랫폼으로 바꾸는 전략의 핵심에 이 내부 구조가 있다. 이 글은 그 구조를 개발자 관점에서 파고든다. 사용자가 Gemini 사이드바에 메시지를 입력하는 순간부터 응답이 돌아올 때까지, Prompt가 어떤 경로로 라우팅되는지를 레이어별로 분해한다.
Chrome + Gemini의 두 가지 실행 경로
먼저 가장 중요한 개념 하나를 짚고 가야 한다. Chrome 안의 Gemini는 단일 시스템이 아니다. 두 가지 완전히 다른 실행 경로가 병존하고, 요청의 성격에 따라 어느 경로로 갈지가 결정된다.
첫 번째는 온디바이스 경로다. Gemini Nano가 사용자 기기 안에서 직접 실행된다. 네트워크 요청이 없고, 데이터가 기기 밖으로 나가지 않는다. Prompt API를 통해 웹 개발자와 확장 프로그램 개발자가 직접 호출할 수 있는 경로다.
두 번째는 클라우드 경로다. Gemini in Chrome의 사이드바가 이 경로를 사용한다. 사용자가 사이드바에서 탭 내용을 공유하면서 질문하는 경우, 해당 컨텍스트가 Google 서버로 전달되고 Gemini 3 모델이 처리한 뒤 응답이 돌아온다. 이 경로가 멀티탭 분석, 앱 통합, auto browse 같은 고급 기능을 담당한다.
이 두 경로는 서로를 대체하는 게 아니라 목적이 다르다. 개인 데이터를 다루는 가벼운 언어 처리는 Nano가 로컬에서, 복잡한 추론과 멀티탭 분석은 클라우드 Gemini가 처리하는 역할 분담이다. 이 구분을 먼저 머릿속에 잡아두어야 이후 구조가 명확해진다.
온디바이스 경로 : Prompt API의 실제 작동 방식
Prompt API는 Chrome에 내장된 Gemini Nano에 직접 접근하는 JavaScript API다. 웹 페이지와 Chrome 익스텐션에서 사용할 수 있으며, 외부 API 키도, 서버 라운드트립도 없이 LLM을 호출한다.
기본 사용 흐름은 이렇다. 먼저 모델이 사용 가능한 상태인지 확인하고, 세션을 생성한 뒤, 프롬프트를 전송한다.
// 모델 가용성 체크
const availability = await LanguageModel.availability();
// availability: 'readily' | 'after-download' | 'no'
if (availability === 'readily') {
// 세션 생성 — system prompt로 모델 행동 정의
const session = await LanguageModel.create({
systemPrompt: '당신은 웹 페이지 요약 전문가입니다. 핵심 내용만 3문장으로 요약하세요.'
});
// 현재 페이지 텍스트를 수동으로 추출해서 프롬프트에 주입
const pageText = document.body.innerText.slice(0, 4000);
const result = await session.prompt(`다음 내용을 요약해줘:\n${pageText}`);
console.log(result);
}
여기서 중요한 점이 있다. Prompt API는 탭 컨텍스트를 자동으로 읽지 않는다. 개발자가 직접 페이지 텍스트를 추출해서 프롬프트에 포함시켜야 한다. 자동 컨텍스트 주입은 Gemini in Chrome 사이드바(클라우드 경로)의 기능이지, Prompt API의 기능이 아니다. 이 차이를 모르면 개발 중에 혼란이 생긴다.
Prompt API에서 주의할 제약 조건도 있다. 모델을 처음 사용할 때 1.5GB에서 2.4GB 크기의 Gemini Nano 모델이 자동으로 다운로드된다. 디스크 공간 최소 22GB, VRAM 4GB 이상 또는 RAM 16GB 이상의 CPU가 요구된다. 한번 다운로드된 모델은 같은 기기의 모든 오리진이 공유해서 사용하므로 중복 다운로드는 없다. 그리고 GPU가 있으면 GPU 추론이 기본이지만, Chrome 140 버전부터는 CPU 추론도 지원하면서 더 넓은 기기에서 사용 가능해졌다.
스트리밍 응답이 필요하면 promptStreaming()을 쓰면 된다. 토큰이 생성되는 대로 스트림으로 받아서 사용자에게 실시간으로 보여줄 수 있다.
const stream = session.promptStreaming('이 계약서의 핵심 조항을 분석해줘');
for await (const chunk of stream) {
resultElement.textContent += chunk;
}
탭 컨텍스트 주입 구조 — 사이드바는 어떻게 탭을 읽나
클라우드 경로, 즉 Gemini in Chrome 사이드바의 동작 방식은 다르다. 사용자가 탭 공유를 허용하면, Chrome이 해당 탭의 내용을 읽어서 Gemini에게 컨텍스트로 제공한다.
내부적으로 이 과정은 여러 단계를 거친다. Chrome은 현재 탭의 DOM에서 의미 있는 텍스트 콘텐츠를 추출한다. 단순히 document.body.innerText를 가져오는 수준이 아니라, 광고나 네비게이션 메뉴 같은 노이즈를 걸러내고 본문 콘텐츠 중심으로 정제한다. 이미지가 있으면 Gemini의 멀티모달 능력을 활용해 이미지 내용도 이해한다.
여러 탭을 동시에 참조할 때는 최대 10개 탭까지 컨텍스트 그룹으로 묶을 수 있다. 2026년 1월 업데이트에서 사이드바가 영구적으로 고정되면서, 사용자가 탭을 전환해도 대화 스레드가 유지되는 구조로 개선됐다. 특정 탭 하나만 참조하거나, 탭 그룹 전체를 컨텍스트에 포함시키는 선택이 가능하다.
같은 페이지에서 열린 여러 탭은 컨텍스트 그룹으로 자동 인식된다. 예를 들어 같은 쇼핑몰에서 여러 상품 페이지를 탭으로 열었다면, Gemini가 이 탭들을 연관된 컨텍스트 그룹으로 이해하고 비교 분석에 활용한다.
이 탭 콘텐츠가 Google 서버로 전달되는 시점은 사용자가 명시적으로 탭 공유를 활성화한 이후다. 기본적으로 Gemini in Chrome은 탭에 접근하지 않으며, 사용자가 컨트롤을 통해 허용해야 공유가 시작된다. 기업 사용자의 경우 이 데이터는 Vertex AI 엔터프라이즈 환경에서 격리되어 처리된다.
클라우드 라우팅 경로 — Gemini 서버까지 이어지는 구조
사이드바 요청이 Google 서버로 향하는 경로를 조금 더 구체적으로 보자. Chrome 브라우저가 탭 컨텍스트를 수집한 뒤, 이 데이터는 Google의 AI 서비스 엔드포인트로 전달된다. 일반 소비자는 Gemini 앱 서비스 인프라를 통하고, 기업 Workspace 사용자는 Vertex AI 엔드포인트로 라우팅된다.
이 구분이 중요한 이유는 데이터 처리 방식이 다르기 때문이다. 소비자 경로에서는 Google의 일반 Gemini 서비스 약관이 적용된다. Workspace 경로에서는 기업 계약 조건과 엔터프라이즈 데이터 보호가 적용되며, 사용자 데이터가 일반 모델 학습에 사용되지 않는다는 보장이 있다.
서버 측에서 요청을 받으면, Gemini 3 Flash 또는 Gemini 3 Pro 중 어떤 모델로 처리할지가 결정된다. 단순한 요약이나 빠른 응답이 필요한 경우는 Flash, 복잡한 멀티스텝 추론이나 긴 문서 분석은 Pro가 처리한다. 이 라우팅은 요청 내용의 복잡도와 응답 속도 요건을 기반으로 자동으로 결정된다. 이 처리가 실제로 어떤 하드웨어 위에서 이루어지는지는 Gemini 실행 인프라 — Google TPU와 Vertex AI 구조에서 자세히 다뤘다. TPU 클러스터와 JetStream 추론 엔진이 이 경로의 물리적 기반이다.
Chrome DevTools AI — ReAct 패턴이 실제로 어떻게 구현됐나
Chrome DevTools에 추가된 AI 어시스턴트는 Gemini in Chrome 사이드바와는 구조가 다르다. Google이 공식 블로그에서 내부 구현을 공개했는데, 개발자라면 읽어볼 가치가 충분히 있는 내용이다.
DevTools AI는 단순한 Q&A가 아니라 ReAct(Reasoning and Acting) 패턴으로 동작한다. AI가 질문을 받으면 바로 답을 생성하는 게 아니라, 현재 페이지에 대한 JavaScript를 실행해서 필요한 정보를 능동적으로 수집한다. Thought → Action → Observation 사이클을 반복하면서 답변에 필요한 정보를 좁혀가는 방식이다.
예를 들어 “이 요소의 margin이 왜 이상하게 적용됐지?”라고 물으면, AI는 먼저 해당 요소의 computed styles를 JavaScript로 읽는 액션을 실행하고, 그 결과를 관찰하고, 다음에 부모 요소의 스타일을 확인하는 액션을 실행하는 식으로 반복한다. 미리 모든 페이지 정보를 Gemini에게 던져주는 방식이 아니라, Gemini가 필요한 정보를 그때그때 능동적으로 조회하는 방식이다. 이 접근이 정확도, 응답 속도, 토큰 비용 세 가지를 동시에 개선한다.
Gemini에게 주어진 도구는 단 하나다. 페이지에서 JavaScript를 실행하는 권한이다. 이 하나의 도구로 DOM 탐색, computed styles 조회, 거리와 크기 계산 등 CSS 디버깅에 필요한 대부분의 정보를 커버한다. 제한된 도구로 범용성을 확보한 설계가 인상적인 부분이다.
보안 측면에서도 중요한 설계가 있다. Gemini가 생성한 JavaScript는 격리된 “world”에서 실행된다. 확장 프로그램의 샌드박스 스크립트와 비슷한 방식으로, DOM과 Web API에는 접근할 수 있지만 페이지의 JavaScript 코드나 상태에는 접근할 수 없다. 악성 페이지가 AI 실행 컨텍스트에 접근하는 것을 구조적으로 차단한다.
Prompt Injection 방어 구조 — 신뢰 경계가 어떻게 설계됐나
Chrome 안에 AI를 심는 것은 새로운 보안 위협을 만든다. 2026년 초, 실제로 이 문제가 수면 위로 올라왔다.
CVE-2026-0628이라는 취약점이 발견됐는데, Gemini Live 사이드 패널이 WebView 태그를 통해 구현된 방식에서 정책 적용이 미흡했다. 낮은 권한의 악성 확장 프로그램이 Gemini 패널 안으로 스크립트를 주입해서, Gemini 패널이 가진 높은 권한(로컬 파일 접근, 스크린샷, 카메라/마이크)을 탈취할 수 있는 취약점이었다. 2026년 1월 Chrome 143.0.7499.192 버전에서 패치됐다.
이 사건이 보여주는 건, AI가 브라우저에 native component로 통합될 때 기존의 보안 경계가 흔들린다는 사실이다. Gemini 패널은 일반 탭이 아닌 브라우저 특권 영역에서 동작하기 때문에, 그 안으로 코드가 주입되면 일반 XSS와는 차원이 다른 권한 에스컬레이션이 가능해진다.
이에 대응해서 Google은 5레이어 보안 체계를 발표했다. 가장 핵심적인 것은 Origin Sets 개념이다. Gemini 사이드바가 어떤 오리진의 콘텐츠에 접근할 수 있는지를 명시적으로 정의하고, 그 경계를 벗어나는 접근을 차단한다. 또한 User Alignment Critic이라는 레이어가 AI의 출력이 사용자의 의도에서 벗어나는 방향으로 조작됐는지를 실시간으로 감지한다. auto browse가 결제나 SNS 게시처럼 민감한 액션 전에 반드시 사용자 확인을 요구하는 것도 같은 맥락의 설계다.
개발자 관점에서의 시사점은 명확하다. Chrome 확장 프로그램이나 Gemini API를 활용한 기능을 만들 때, 외부 페이지에서 주입될 수 있는 콘텐츠가 프롬프트에 그대로 들어가는 구조는 Prompt Injection 취약점이 된다. 사용자 입력과 외부 페이지 콘텐츠는 프롬프트 안에서 역할을 명시적으로 구분해야 하고, 외부 콘텐츠가 시스템 프롬프트의 지시를 덮어쓸 수 없도록 설계해야 한다.
개발자를 위한 Built-in AI API 전체 지도
Chrome의 Built-in AI API는 Prompt API 하나가 아니다. 2025~2026년 기준으로 제공되거나 실험 중인 API 전체를 파악해두면 기능 설계에 도움이 된다.
Prompt API는 가장 범용적인 API로, Gemini Nano에 자유로운 자연어 요청을 보낼 수 있다. Chrome 138 Stable부터 확장 프로그램에서 사용 가능하다. Summarizer API는 텍스트 요약에 특화된 API로, 문서 길이와 요약 형식을 옵션으로 지정할 수 있다. Writer API와 Rewriter API는 텍스트 생성과 텍스트 개선에 각각 특화된 API다. Translator API는 다국어 번역을 처리하며, Proofreader API는 문법 교정에 특화됐다. 이들은 모두 온디바이스에서 실행되기 때문에 서버 비용이 없고 개인정보가 기기 밖으로 나가지 않는다.
이미지 입력도 Prompt API 안에서 지원되기 시작했다. promptStreaming() 호출 시 이미지를 포함한 멀티모달 프롬프트를 보낼 수 있다. 단, 이미지는 base64로 인코딩해서 전달한다.
const session = await LanguageModel.create();
const imgResponse = await fetch(imageUrl);
const imgBlob = await imgResponse.blob();
const result = await session.prompt([
{ type: 'image', value: imgBlob },
{ type: 'text', value: '이 이미지에 있는 제품의 특징을 설명해줘' }
]);
마무리 : 구조를 알면 더 잘 만든다
Chrome + Gemini의 내부 구조를 이해하고 나면 접근 방식이 달라진다. Prompt API와 클라우드 Gemini를 무분별하게 섞는 게 아니라, 각 레이어의 특성에 맞게 역할을 나눌 수 있다.
개인 정보를 다루는 로컬 텍스트 처리, 오프라인에서도 동작해야 하는 기능, API 비용 없이 고빈도로 실행해야 하는 작업은 Prompt API를 통해 Gemini Nano로 처리하는 것이 맞다. 반면 복잡한 추론, 멀티탭 분석, Google 서비스 통합이 필요한 경우는 클라우드 Gemini가 적합하다. 하이브리드 전략을 짜면 비용과 성능과 개인정보 보호를 동시에 잡을 수 있다.
DevTools AI에서 ReAct 패턴을 도입한 것처럼, 좋은 AI 기능은 전체 페이지를 한번에 던져주기보다 필요한 정보를 능동적으로 조회하는 방식이 응답 품질과 비용 양쪽에서 유리하다. 그리고 Prompt Injection 방어를 설계 초기부터 고려해야 한다. 외부 콘텐츠가 프롬프트에 섞이는 모든 지점이 잠재적인 취약점이다.
브라우저에 AI가 통합된다는 것은 단순히 새로운 API가 하나 생긴 게 아니다. 브라우저의 신뢰 모델 자체가 재설계되는 과정이다. 그 재설계의 구체적인 모습이 Prompt API, Origin Sets, ReAct 기반 DevTools AI, 그리고 하이브리드 추론 구조 안에 담겨 있다.