Browser Agent
서버 API 중심 구조 대신, 브라우저 안에서 Gemma 4를 직접 실행하고 그 위에 툴 호출형 에이전트 경험을 어떻게 얹는지 구현 관점에서 해부한 자료입니다.
핵심 모델
Gemma 4 + WebGPU
실행 환경
Chrome Extension
핵심 포인트
온디바이스 브라우저 에이전트
Overview
왜 이 구조가 눈여겨볼 만한가
많은 팀이 AI 기능을 붙일 때 먼저 서버 API 호출 구조부터 떠올립니다. 하지만 브라우저 확장, 내부 도구, 개인정보 민감 서비스, 오프라인 환경처럼 데이터를 밖으로 보내기 어려운 제품에서는 완전히 다른 접근이 필요합니다.
Gemma-gem은 그 대안을 보여줍니다. 모델 추론을 로컬로 처리하면서도, 현재 페이지를 읽고 클릭하고 입력하는 실제 브라우저 에이전트까지 연결합니다.
Who It Helps
이 글이 특히 유용한 팀
- 브라우저 확장 기반 AI 제품을 기획하거나 검증 중인 팀
- WebGPU 기반 온디바이스 추론을 실제 제품 구조에 녹이고 싶은 개발자
- DOM 조작, 페이지 컨텍스트, 툴 호출을 결합한 에이전트 UX를 설계하는 팀
- API 비용, 응답 속도, 개인정보 처리 측면에서 로컬 추론 대안을 검토하는 팀
Architecture
자료에서 다루는 핵심 포인트
- 브라우저 안에서 Gemma 4를 실행하기 위한 WebGPU 추론 파이프라인
- Content Script, Service Worker, Offscreen Document의 3분할 아키텍처
- 현재 탭의 DOM과 snapshot을 모델 컨텍스트로 연결하는 방식
tool call, message routing, timeout, abort 처리 같은 런타임 설계- 왜 이 구조가 서버 없는 브라우저 네이티브 AI 제품의 출발점이 되는지
Takeaway
실무 관점에서 보면
이 분석의 가치는 단순히 “Gemma 4를 돌렸다”에 있지 않습니다. 중요한 건 브라우저의 제약을 받아들이면서도 에이전트 경험을 성립시킨 설계입니다. 무거운 추론은 offscreen에 격리하고, 권한 API는 service worker에서 처리하고, 페이지 밀착 UI는 content script가 맡는 패턴은 이후 브라우저 네이티브 AI 제품을 설계할 때 그대로 참고할 수 있습니다.
Attachment
원문 PDF 안내
전체 발표 자료는 하단 첨부 파일에서 바로 다운로드할 수 있습니다. 브라우저 네이티브 AI, 온디바이스 추론, 확장 프로그램 기반 에이전트 제품을 고민하고 있다면 좋은 출발점이 될 자료입니다.