검색, 태깅, 추천 기능을 클라우드 외부로 이전한 이유

대부분의 "AI 기반" 브라우저 확장 프로그램은 AI와 전혀 무관한 부분까지 포함하여 모든 데이터를 서버로 전송합니다. 검색, 태그 정리, "유사 항목 찾기" 등은 수십 년간 검증된 잘 알려진 기술입니다. 이러한 작업에는 언어 모델이 필요하지 않으며, 네트워크 왕복 통신 또한 전혀 불필요합니다. 저희는 AI Summary Helper의 기능을 하나씩 검토하며 자문했습니다. "이 기능에 정말 클라우드가 필요한가, 아니면 단순히 구현하기 쉬운 아키텍처라는 이유로 기본값처럼 채택한 것은 아닌가?"

대부분의 기능에는 클라우드가 필요하지 않았습니다.

온디바이스로 이전된 실제 기능들

검색. 본 확장 프로그램은 원래 글의 제목과 태그만 매칭했습니다. 처리는 빨랐지만 본문 내용은 전혀 파악하지 못했습니다. 키 입력마다 전체 텍스트를 무차별 스캔하거나 모든 쿼리를 서버로 전송하는 대신, 사용자가 저장한 아카이브로부터 소형 TF-IDF 인덱스를 구축했습니다. 제목이나 태그처럼 리소스 소모가 적은 필드는 기존처럼 즉시 먼저 확인됩니다. 더 긴 쿼리는 세션당 한 번 빌드되고 점진적으로 업데이트되는 인덱스를 기반으로 확장 검색되며, 키 입력마다 재스캔되지 않습니다.

중복 감지. 저장이 완료되기 전 단계별 검사가 실행됩니다. 우선 정규화된 정확한 URL 매칭(저비용, O(1))을 먼저 수행하고, 해당 필터를 통과한 소수의 후보에 대해서만 제목 유사도를 검사하며, 마지막으로 남은 극소수의 후보에 대해서만 전체 TF-IDF 코사인 유사도 비교를 진행합니다. 대부분의 저장은 저비용 단계에서 이미 처리되므로 리소스 소모가 큰 단계까지 도달하지 않습니다.

태그 정규화. 시간이 지나면서 태그에는 표기 불일치가 누적됩니다. 사람에게는 "ML", "Machine Learning", "machine-learning"이 모두 같은 의미이지만, 필터에게는 완전히 다르게 인식됩니다. 간단한 별칭 테이블로 명백한 사례를 처리하고, 전체 태그 어휘에 대한 퍼지 편집 거리 병합으로 나머지 항목을 포착합니다. 이때 특정 표기를 강제하기보다 사용자가 실제로 가장 자주 사용한 표기를 표준 형태로 채택합니다.

가독성 및 톤 분석. 플레시-킨케이드(Flesch–Kincaid) 학년 수준 지수는 문장과 음절 수에 대한 단순 산술 연산일 뿐이며 별도의 모델이 필요하지 않습니다. 감성 분석은 번들로 제공되는 AFINN 단어 목록과 앞선 두 토큰에 대한 간단한 부정어 검사로 구성됩니다. 두 기능 모두 브라우저 외부로 데이터를 전송할 필요가 없습니다.

"유사한 글" 및 다이제스트. 두 기능 모두 검색에서 이미 구축한 동일한 TF-IDF 벡터를 그대로 재사용합니다. 3가지 개별 기능에 대해 3개의 서로 다른 유사도 시스템을 구축하는 것도 가능했겠지만, 단일 인덱스를 구축하여 검색, 추천, 다이제스트 큐레이션이 모두 이를 참조하도록 구성함으로써 전체 시스템 크기를 줄일 수 있었고, 인덱스를 한 번 개선하면 3가지 기능 모두가 동시에 향상되는 구조를 만들었습니다.

의도적으로 클라우드에 유지한 기능

실제 요약 단계, 즉 언어 모델이 실질적으로 필요한 영역은 여전히 네트워크 호출이 필요합니다. 클라우드 수준 모델의 출력 품질을 확보하려면 현재의 온디바이스 모델 크기로는 한계가 있습니다. 사용자는 이 단계를 위해 자체 API 키(OpenAI, Gemini, Mistral, DeepSeek)를 등록하거나, 확장 프로그램이 로컬 Ollama 인스턴스를 바라보도록 설정하여 네트워크 통신을 완전히 생략할 수 있습니다. 이 부분만큼은 온디바이스가 기본값이 아니며 선택 사항(opt-in)으로 제공됩니다. 로컬 모델은 호스팅 모델보다 느리고 품질이 낮다는 명확한 트레이드오프가 존재하기 때문입니다.

단순한 개인정보 보호 마케팅을 넘어선 엔지니어링적 가치

개인정보 보호 측면은 중요합니다. 광범위한 호스트 권한을 가진 확장 프로그램이 불필요한 작업에까지 페이지 콘텐츠를 서버로 전송하는 것은 단순한 대외적 이미지가 아니라 실질적인 신뢰 문제입니다. 하지만 이 방식을 택한 보다 본질적인 이유는 엔지니어링 관점에서 이것이 올바른 결정이기 때문입니다. TF-IDF 검색에는 200ms의 네트워크 지연 시간이 필요하지 않으며, 태그 중복 제거에 API 비용이 발생할 이유도 없습니다. 모든 것을 무조건 "클라우드 호출"로 처리하는 대신 작업에 적합한 도구를 매칭하면 더 빠르고, 운영 비용이 절감되며, 오프라인 환경에서도 안정적인 결과물이 완성됩니다. 개인정보 보호는 이러한 최적화 과정에서 자연스럽게 수반되는 이점입니다.