지금까지 웹 앱에서 “의미 기반 검색”을 구현하려면 두 가지 선택지밖에 없었습니다. 서버에 텍스트를 보내 클라우드 임베딩 API를 호출하거나, 수백 MB짜리 모델을 사이트마다 직접 다운로드해 WASM으로 돌리거나. Chrome Built-in AI 팀이 이 구조 자체를 바꾸겠다는 제안을 공개했습니다.
출처: Explainer: Built-in Embedding API – Chrome Built-in AI Team (GitHub Explainer)
기존 방식의 딜레마
임베딩(Embedding)은 텍스트를 숫자 벡터로 변환하는 기술입니다. “케이크 레시피”와 “케이크 굽는 방법”이 같은 의미임을 수치로 표현할 수 있게 해주죠. 이를 활용하면 키워드가 아닌 의미 단위로 검색하거나, 로컬 문서를 기반으로 답변하는 RAG(Retrieval-Augmented Generation) 시스템을 만들 수 있습니다.
문제는 비용이었습니다.
클라우드 API는 텍스트를 서버로 전송해야 하므로 개인 데이터가 외부로 나가고, 응답 지연과 비용이 발생합니다. 직접 모델을 번들로 넣는 DIY 방식은 사이트마다 같은 모델을 중복 다운로드해야 해서, 사용자의 저장 공간과 대역폭을 낭비합니다. 10개 사이트가 같은 모델을 쓴다면 10번 다운로드가 일어나는 셈이죠.
제안: 브라우저가 임베딩 모델을 공유
Chrome Built-in AI 팀이 제안하는 Embedding API (현재 SemanticEmbedder라는 이름으로 개발자 트라이얼 준비 중)는 브라우저 자체에 임베딩 모델을 내장하는 방식입니다. 브라우저가 하나의 모델을 다운로드해 모든 사이트가 공유하는 구조여서, 모델 저장 비용이 모든 출처에 걸쳐 분산됩니다.
작동 흐름은 다음과 같습니다.
- 브라우저가 모델 가용 여부를 확인합니다 (
SemanticEmbedder.availability()) - 개발자가 임베더 인스턴스를 생성합니다 (
SemanticEmbedder.create()) - 텍스트를 넣으면 고차원 벡터(Float32Array)를 반환합니다
- 반환된 벡터를 코사인 유사도 계산이나 벡터 DB에 활용합니다
- 사용 후 메모리를 해제합니다 (
semanticEmbedder.destroy())
텍스트는 기기 밖으로 나가지 않습니다. 임베딩 생성 전 과정이 온디바이스에서 완결됩니다.
어떤 상황에서 유용한가
Chrome 팀이 제시하는 활용 시나리오는 세 가지입니다.
노트 앱의 시맨틱 서치, 즉 “비슷한 내용의 노트 찾기”를 키워드 없이도 구현할 수 있습니다. 문서 기반 Q&A 봇(RAG)을 오프라인에서도 동작하도록 만들 수 있죠. 커뮤니티 포럼이라면 사용자가 입력하는 동안 실시간으로 콘텐츠를 분석해 유해성 힌트를 제공하는 것도 가능합니다. 이 모든 과정에서 텍스트가 서버로 전송되지 않아도 됩니다.
단, 벡터 DB는 API가 직접 제공하지 않습니다. 생성된 Float32Array를 IndexedDB나 OPFS 같은 기존 웹 저장소에 개발자가 직접 관리해야 합니다.
아직 해결되지 않은 문제들
이 제안이 흥미로운 동시에 복잡한 이유는, Chrome 팀 스스로 미해결 과제를 솔직하게 열거하고 있기 때문입니다.
가장 핵심적인 문제는 벡터 공간의 호환성입니다. 임베딩 벡터는 그것을 생성한 모델에 수학적으로 결합되어 있어서, 다른 모델이 만든 벡터끼리는 직접 비교할 수 없습니다. Chrome과 다른 브라우저가 서로 다른 모델을 사용하면 크로스 브라우저 호환성이 깨집니다. 서버 측 임베딩과 클라이언트 임베딩을 함께 써야 하는 하이브리드 RAG 시스템은 이 문제에 더 민감합니다.
브라우저 모델이 업데이트되면 기존에 저장해둔 벡터가 무효화될 수 있다는 점도 과제입니다. API는 이를 위해 EmbedderMetadata로 모델 버전 정보를 노출할 계획이지만, 구체적인 표준화 방식은 아직 논의 중입니다.
초기 프로토타입에는 EmbeddingGemma(300M)나 Qwen3Embedding(0.6B) 같은 오픈 웨이트 모델을 활용할 예정입니다. 개발자가 직접 모델을 선택하거나 교체할 수 있는지 여부는 표준화 논의에서 다른 브라우저 벤더들과 함께 결정해야 할 사안입니다.
웹 플랫폼 AI의 흐름 속에서
이 제안은 Chrome의 기존 Built-in AI API들, 즉 Summarizer, Translation, Prompt API와 같은 설계 패턴을 따릅니다. 브라우저가 모델 실행 환경을 직접 책임지고, 개발자는 고수준 JS 인터페이스만 쓰면 되는 방향입니다.
아직 Chrome에 탑재가 승인된 상태는 아니고 초기 설계 스케치 단계입니다. Chrome 팀은 blink-dev 메일링 리스트에 프로토타입 개발 의향(Intent to Prototype)을 공개하고, Web Machine Learning 커뮤니티 그룹(WebML CG)을 통해 다른 브라우저 벤더들의 의견을 구하고 있습니다. 벡터 공간 표준화, 모델 버전 관리, 청킹 유틸리티 내장 여부 등 여러 설계 질문들이 열려 있는 만큼, 제안 자체의 논의 과정도 흥미롭게 지켜볼 만합니다.
참고자료:
- Intent to Prototype: Embedding API – Chromium blink-dev
- Built-in Embedding API Proposal – WebML Community Group
답글 남기기