본문 바로가기
Git/Git Hub 사이트 다루기

[Git-Page]2.서버 없이 브라우저에서 돌리는 로컬 RAG 시스템과 초성 검색 Spotlight 개발기 (Fuse.js + 한글 초성 검색) , RAG를 이용한 LLM 출처 만들기, 깃페이지에 LLM 모델넣기

by 으노으뇨 2026. 6. 13.
728x90
반응형
SMALL

제 포스팅은 AI가 작성한게 아닌 한글자 한글자 타자를 쳐서 작성한 포스팅입니다. 구독 좋아요 댓글은 힘이됩니다.

안녕하세요~~~!!! 

이번에 포스팅을 할 주제는!

지난 포스팅에 이어 이번에는 서버 비용 0원으로 브라우저 내부에서 지식 정보를 탐색하고 이를 언어 모델에 먹여 답변하게 만드는

로컬 RAG(Retrieval-Augmented Generation) 시스템

과, 이를 유저가 시스템 전체에서 편리하게 불러다 쓸 수 있는 IDE 스타일의

Spotlight 검색창(한글 초성 검색 포함)

을 설계하고 구현한 과정을 다룹니다!!! 지난글에 LLM 구현한 걸 보시면 이해됩니다.

제 깃페이지는 AMEVA Neural Fabric — Edge-Native AI Dashboard

 

AMEVA Neural Fabric — Edge-Native AI Dashboard

Your browser does not support WebGPU, which is strictly required for the local LLM engine. We've switched you to Codex Mode so you can explore the network without local AI.

uno-km.github.io

입니다. 이전글은 아래와 같습니다.

2026.06.13-[Git-Page]1.깃페이지에서 LLM을 구현해보자-API사용X, 순수 웹 LLM 기술적으로 구현함! -남들처럼 API안쓰고 힙합으로 해보자~! 깃페이지에 챗봇넣기!

 

[Git-Page]1.깃페이지에서 LLM을 구현해보자-API사용X, 순수 웹 LLM 기술적으로 구현함! -남들처럼 API안

제 포스팅은 AI가 작성한게 아닌 한글자 한글자 타자를 쳐서 작성한 포스팅입니다. 구독 좋아요 댓글은 힘이됩니다. 안녕하세요~~~!!! 이번에 포스팅을 할 주제는!깃 페이지 안에서 LLM 구현하고

uno-kim.tistory.com

아니 무작정 저걸 LLM으로 프롬프트로만 한게 아니고 RAG를 이용해서 그래도 각 리포지토리를 RAG화해서 근거로 챗봇을 만들었었습니다. 굉장하지요?

일단

STT 검색시

초성검색

RAG를 통해 인용된 답변 그리고 출처를 링크로 보내주는 결과

코어 아키텍처: 가볍고 빠른 클라이언트 사이드 RAG & 검색 시스템

브라우저의 리소스는 한정적입니다. 서버에서 구동되는 일반적인 RAG 파이프라인처럼 거대한 벡터 데이터베이스(예: Pinecone, Milvus)와 무거운 임베딩 모델(예: OpenAI Ada)을 사용하게 되면 배보다 배꼽이 더 커지게 됩니다.

우리가 설계한 초경량 에지 네이티브 RAG & 검색 아키텍처는 다음과 같습니다.

Fuse.js 기반 RAG Retriever:

무거운 벡터 연산 대신 메모리에 로드된 데이터셋에 대해 빠르고 정확한 유사도 매칭을 수행하는 퍼지(Fuzzy) 검색 라이브러리를 활용했습니다.

Dynamic Content Fetching & Chunking:

AMEVA 생태계 내 각 GitHub 리포지토리의 README.md 문서를 마크다운 파서를 거쳐 문단 단위로 쪼개고(Chunking), 이를 로컬 RAG 인덱스 풀에 가입시킵니다.

Spotlight UI & 초성 파서:

Ctrl + K (또는 Cmd + K) 단축키로 호출하는 전역 검색 컴포넌트를 설계하고, 한국어 검색의 한계인 자음/초성 검색 처리를 위해 유니코드 코드포인트를 활용한 동적 초성 파서를 탑재했습니다.

난제 1: 한국어 퍼지 검색의 한계와 유니코드 초성 분리법

1) Fuse.js의 맹점: 영문에 편향된 유사도 매칭

Fuse.js는 기본적으로 영문 단어의 오타나 스펠링 거리를 판별(Levenshtein Distance)하는 데 매우 특화되어 있습니다.

그러나 완성형 문자(가, 각, 간...) 체계를 사용하는 한국어 환경에서는 단 한 글자만 틀려도 완전히 다른 유니코드 값으로 매핑되기 때문에 퍼지 검색의 효율이 극단적으로 떨어집니다.

특히 한글 자음/초성 검색(예: ㄱㅅ 입력 시 '기술', '개설' 매칭)은 아예 불가능합니다.

2) 돌파구: Unicode Choseong Parser (유니코드 한글 초성 추출기)

한국어 자음 입력을 정상 판별하기 위해 한글 유니코드 계산법을 응용한 초성 변환 헬퍼 함수를 구현했습니다.

검색 풀에 문서를 등록할 때 원본 텍스트와 초성 변환 텍스트를 동시에 인덱싱하고, 검색어가 들어오면 이를 분석해 우선순위를 동적으로 조정했습니다.

// 한글 음절에서 초성(자음)만 추출하는 헬퍼 함수
function getChoseong(str) {
  const choseongs = [
    'ㄱ', 'ㄲ', 'ㄴ', 'ㄷ', 'ㄸ', 'ㄹ', 'ㅁ', 'ㅂ', 'ㅃ', 
    'ㅅ', 'ㅆ', 'ㅇ', 'ㅈ', 'ㅉ', 'ㅊ', 'ㅋ', 'ㅌ', 'ㅍ', 'ㅎ'
  ];
  let result = '';
  for (let i = 0; i < str.length; i++) {
    const code = str.charCodeAt(i) - 0xAC00;
    if (code >= 0 && code < 11172) {
      result += choseongs[Math.floor(code / 588)];
    } else {
      result += str.charAt(i); // 영문, 숫자, 특수문자는 그대로 유지
    }
  }
  return result.toLowerCase();
}

검색 로직(retriever) 내에서 검색 키워드가 자음(예: ㄱ-ㅎ)으로만 이루어져 있다면, 인덱싱된 초성 풀을 기준으로 매칭 점수를 수백 배 가중하여 상단에 노출되도록 튜닝했습니다.

난제 2: 제한된 Context Window 크기와 Hallucination 제어

클라이언트 단에서 돌리는 Qwen 1.5B 모델은 컨텍스트 윈도우(기억력 범위)가 보통 4K 이하로 매우 짧습니다.

만약 수십 개 레포지토리의 README 전체를 아무 가공 없이 프롬프트에 구겨 넣는다면 성능 저하는 물론 답변 생성이 도중에 크래시나며 중단될 것입니다.

해결책: 3단계 RAG 파이프라인

문단 단위 Chunking

각 리포지토리의 원본 마크다운을 더블 개행(\n\n)을 기준으로 분절하고, 20글자 이하의 노이즈성 텍스트는 걸러냅니다.

Top-N Context Filtering

유저가 챗봇에 질문을 던지면 Fuse.js 인덱스를 이용해 가장 관련성이 높은 상위 3개의 문단만 동적으로 추출합니다.

엄격한 RAG System Prompt 부여

LLM이 지식을 지어내는 현상(환각)을 막기 위해 검색된 문서 컨텍스트 외의 생물학적 상식(예: 생물 아메바) 등은 철저히 배제하고, 오직 주입된 코드 및 프로젝트 정보 안에서만 대답하도록 페르소나 역할을 엄격히 한정시켰습니다.

RAG Badge 출처 표기

AI가 참고한 리포지토리의 소스 파일 링크를 실시간 답변 밑에 앵커 태그 배지(RAG Badges)로 자동 매핑해 주어 신뢰성을 시각적으로 입증했습니다.

설계 과정의 트레이드오프 (Trade-offs)

1) 무거운 임베딩 모델(On-Device Embedding) vs 가벼운 키워드 가중치 매칭

고민: Transformers.js를 브라우저 백그라운드(WebWorker)에 올려 MiniLM-L6 같은 실제 임베딩 모델로 완벽한 로컬 벡터 임베딩 코사인 유사도 검색을 할 것인가?

결정: 브라우저 환경에서 임베딩 모델을 추가 다운로드(약 100MB 추가 소모)하고 클라이언트 CPU에서 임베딩 연산을 태우는 것은 초기 로딩 지연을 악화시킨다고 판단했습니다.

대신 자음/초성 변환이 가미된 키워드 가중치 기반 퍼지 인덱스를 채택했습니다. 이로써 네트워크 대역폭을 아끼면서도 키워드 유인 검색에서 벡터 검색 수준의 실용적이고 빠른 조회를 완성했습니다.

2) 전체 실시간 Fetching vs 정적 가입 인덱스 백업

고민: 깃허브 API 호출 제한이 걸린 상황에서 README 실시간 페칭 실패 시 지식 베이스가 어떻게 동작해야 하는가?

결정: 기본적으로 깃허브 API를 이용해 최신 데이터를 페칭하되, API 제한이 감지되면 내부의 정적 graph_index.json 백업 리소스 파일로 즉시 스위칭하여 검색 풀을 채우도록 설계하여 무정전 검색 시스템을 유지했습니다.

우리가 얻은 에센스

서버를 전혀 빌리지 않는 로컬 RAG 설계는 클라이언트 자원의 철저한 효율화가 전부입니다.

자원 제약이 빡빡한 브라우저 샌드박스 내부에서 초경량 키워드 퍼지 인덱스와 자음 파서를 활용하여 수 메가바이트의 도큐먼트들을 실시간으로 지능적 필터링하고 이를 LLM의 두뇌로 적시에 밀어주는 아키텍처는, 클라우드 종속성에서 벗어나 주권적 생태계를 완성하는 Edge-AI 포트폴리오의 든든한 기술적 무기가 될 것입니다.


이것으로 LLM 검색을 좀더 보강하고 또 효율화 할 수 있도록 구현했었습니다.

긴글 읽어주셔서 감사합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

제 포스팅은 AI가 작성한게 아닌 한글자 한글자 타자를 쳐서 작성한 포스팅입니다. 구독 좋아요 댓글은 힘이됩니다.

 

728x90
반응형
LIST

댓글