로컬 AI를 이야기할 때 많은 사람이 챗봇 모델만 봅니다.

하지만 내 문서를 검색하고 답하게 만들려면 챗봇 모델만으로는 부족합니다. RAG가 필요하고, RAG의 핵심에는 embedding model이 있습니다.

초급자 기준으로 한 줄로 말하면 이렇습니다.

로컬 RAG는 내 문서를 조각내고, 벡터로 바꾸고, 관련 조각을 찾아서, 로컬 LLM이 그 조각을 바탕으로 답하게 만드는 구조입니다.

이 글은 EmbeddingGemma, Qwen3 Embedding, Qwen3-VL Embedding을 기준으로 로컬 RAG를 어떻게 봐야 하는지 정리합니다.

바로 보기

RAG가 왜 필요한가

LLM은 질문에 답할 수 있지만, 내 컴퓨터에 있는 파일을 자동으로 알고 있지는 않습니다.

예를 들어 아래 파일이 있다고 해봅시다.

  • PDF 매뉴얼
  • 블로그 초안
  • 회의록
  • 제품 가격표
  • 에러 로그
  • 내부 체크리스트

모델에게 “이 문서에서 백업 절차만 찾아줘”라고 하려면 문서 내용을 모델 입력으로 넣어야 합니다. 그런데 문서가 길면 한 번에 넣기 어렵고, 매번 전체를 붙여넣는 것도 비효율적입니다.

RAG는 이 문제를 이렇게 나눕니다.

  1. 문서를 작은 조각으로 나눕니다.
  2. 각 조각을 embedding vector로 바꿉니다.
  3. 질문도 embedding vector로 바꿉니다.
  4. 질문과 가까운 문서 조각을 찾습니다.
  5. 찾은 조각만 LLM에게 넣어 답하게 합니다.

여기서 embedding model은 “답변하는 모델”이 아니라 “비슷한 의미를 찾는 모델”입니다.

EmbeddingGemma: 작은 온디바이스 embedding 모델

Google의 EmbeddingGemma는 308M parameter multilingual text embedding model입니다.

Google 문서는 이 모델이 Gemma 3 기반이고, phones, laptops, tablets 같은 everyday device에서 쓰기 좋게 최적화됐다고 설명합니다. 용도는 information retrieval, semantic similarity search, classification, clustering입니다.

이 말은 초급자에게 이렇게 바꿔 말할 수 있습니다.

  • 챗봇처럼 답하는 모델이 아니다.
  • 문장과 문서 조각을 숫자 벡터로 바꾸는 모델이다.
  • 내 노트북이나 휴대폰 같은 기기에서 돌리기 좋게 작다.
  • 로컬 문서 검색, 분류, 비슷한 문장 찾기에 맞다.

EmbeddingGemma가 로컬 RAG 글감으로 좋은 이유는 크기입니다.

300M급 embedding model이면 대형 LLM보다 훨씬 가볍습니다. 답변 생성은 Gemma 4, Qwen3, Llama 같은 모델에게 맡기고, 문서 검색은 EmbeddingGemma 같은 embedding model에게 맡기는 구조가 현실적입니다.

Qwen3 Embedding: 다국어와 코드 검색을 같이 볼 때

Qwen3 Embedding도 로컬 RAG에서 볼 만합니다.

Ollama의 qwen3-embedding 설명 기준으로 Qwen3 Embedding은 0.6B, 4B, 8B 크기가 있고, text embedding tasks를 위해 만들어진 모델군입니다.

Ollama 페이지에서 확인되는 크기는 다음과 같습니다.

모델대략적인 크기컨텍스트
qwen3-embedding:0.6b639MB32K
qwen3-embedding:4b2.5GB40K
qwen3-embedding:8b4.7GB40K

Qwen3 Embedding은 100개 이상 언어와 programming languages를 지원한다고 설명됩니다. 그래서 한국어, 영어, 코드가 섞인 문서를 검색하려는 사람에게 특히 관심을 둘 만합니다.

예를 들어 이런 자료입니다.

  • 한국어 회의록 + 영어 기술 문서
  • README + TypeScript 코드
  • 장애 로그 + 운영 문서
  • 블로그 글 초안 + 공식 문서 링크
  • 한글 주석이 섞인 코드베이스

이런 경우에는 단순 영어 embedding model보다 다국어와 코드 검색을 같이 보는 모델이 더 잘 맞을 수 있습니다.

Qwen3-VL Embedding: 이미지와 스크린샷까지 찾고 싶을 때

문서가 텍스트만 있는 것은 아닙니다.

실무 자료에는 이미지와 스크린샷이 자주 섞입니다.

  • UI 스크린샷
  • 에러 화면
  • PDF 안의 표와 그림
  • 제품 사진
  • 영상 프레임
  • 슬라이드 캡처

Qwen3-VL-Embedding은 이런 방향에 가깝습니다.

Hugging Face 모델 카드 기준 Qwen3-VL-Embedding과 Qwen3-VL-Reranker는 text, images, screenshots, videos, mixed modalities를 입력으로 받을 수 있는 multimodal retrieval 모델군입니다. 2B와 8B embedding 모델, 2B와 8B reranker 모델이 제시됩니다.

초급자에게는 이렇게 이해하면 됩니다.

  • 텍스트 문서 검색: EmbeddingGemma, Qwen3 Embedding
  • 이미지/스크린샷/영상까지 섞인 검색: Qwen3-VL Embedding
  • 검색 결과를 다시 정밀하게 줄이기: reranker

처음부터 멀티모달 RAG를 만들 필요는 없습니다. 하지만 PDF, 스크린샷, UI 자료가 많다면 텍스트 embedding만으로는 부족할 수 있다는 점은 알아두는 편이 좋습니다.

로컬 RAG의 기본 구조

가장 단순한 로컬 RAG는 아래처럼 생각하면 됩니다.

문서 폴더
  -> 텍스트 추출
  -> chunk 분리
  -> embedding 생성
  -> vector index 저장
  -> 질문 embedding
  -> 관련 chunk 검색
  -> 로컬 LLM 답변

여기서 각각의 역할이 다릅니다.

역할예시
embedding modelEmbeddingGemma, Qwen3 Embedding
vector indexFAISS, SQLite vector 확장, Chroma, Qdrant 등
answer modelGemma 4, Qwen3.6, Llama 계열
실행 도구Ollama, llama.cpp, LM Studio, Python 스크립트

초급자는 처음부터 서버형 vector DB를 설치할 필요가 없습니다.

문서가 수십 개 수준이면 로컬 파일 기반 index나 가벼운 SQLite 계열로도 충분히 실험할 수 있습니다. 중요한 것은 아키텍처보다 검색 품질을 눈으로 확인하는 것입니다.

어떤 모델부터 고르면 좋을까

목적별로는 이렇게 나누면 쉽습니다.

목적먼저 볼 모델
개인 메모, 블로그 초안, 짧은 문서 검색EmbeddingGemma
한국어/영어/코드가 섞인 문서 검색Qwen3 Embedding 0.6B 또는 4B
대량 문서, 더 높은 검색 품질 실험Qwen3 Embedding 8B
스크린샷과 이미지가 섞인 자료 검색Qwen3-VL Embedding
검색 결과 정밀 재정렬Qwen3 reranker 또는 Qwen3-VL reranker

처음에는 작은 모델이 좋습니다.

embedding은 한 번만 돌리는 것이 아니라 문서를 추가할 때마다 계속 생성합니다. 모델이 너무 크면 indexing 시간이 길어지고, 실험 속도가 떨어집니다.

로컬 RAG에서 자주 하는 실수

첫째, embedding model과 chat model을 구분하지 않습니다.

EmbeddingGemma나 Qwen3 Embedding은 답변을 생성하는 모델이 아닙니다. 문서를 찾는 모델입니다. 답변은 별도의 LLM이 합니다.

둘째, chunk를 너무 크게 자릅니다.

문서 조각이 너무 크면 검색 결과가 뭉뚱그려지고, 답변 모델이 불필요한 내용을 많이 받습니다. 반대로 너무 작으면 문맥이 사라집니다. 처음에는 제목, 문단, 목록 단위로 나누고 직접 결과를 확인하는 편이 낫습니다.

셋째, 출처 표시를 빼먹습니다.

RAG 답변은 “어떤 문서 조각을 보고 답했는가”가 중요합니다. 파일명, 제목, 위치를 같이 저장해야 나중에 확인할 수 있습니다.

넷째, 로컬이라고 무조건 안전하다고 생각합니다.

로컬 실행은 외부 API 전송을 줄이는 데 유리합니다. 하지만 모델 파일 출처, 플러그인, 로그 저장 위치, 문서 index 저장 위치를 잘못 관리하면 민감한 정보가 남을 수 있습니다.

초급자용 실험 순서

처음에는 아래처럼 작게 시작하면 됩니다.

  1. 문서 10개만 고릅니다.
  2. 각 문서에서 텍스트만 추출합니다.
  3. 문단 단위로 chunk를 나눕니다.
  4. EmbeddingGemma 또는 Qwen3 Embedding 0.6B로 벡터를 만듭니다.
  5. 질문 10개를 직접 만들어 검색 결과를 확인합니다.
  6. 검색 결과가 맞으면 로컬 LLM 답변을 붙입니다.
  7. 답변에는 파일명과 문단 출처를 같이 표시합니다.

이렇게 해야 RAG가 실제로 작동하는지 확인할 수 있습니다.

처음부터 “내 모든 PDF를 넣어서 완벽한 개인 비서 만들기”로 시작하면 실패하기 쉽습니다.

이 글의 결론

로컬 RAG의 핵심은 LLM이 아니라 검색입니다.

EmbeddingGemma는 가볍고 온디바이스에 맞는 embedding 모델이고, Qwen3 Embedding은 다국어와 코드 검색 쪽에서 강한 선택지입니다. Qwen3-VL Embedding은 이미지와 스크린샷까지 검색하려는 사람에게 필요한 다음 단계입니다.

처음 시작할 때는 작은 문서 묶음으로 충분합니다.

문서 10개, 질문 10개, 검색 결과 확인, 출처 표시까지만 제대로 해도 로컬 RAG의 감을 잡을 수 있습니다.

클라우드 API를 쓰지 않는다는 것보다 중요한 것은, 내 문서에서 어떤 조각을 찾아 답했는지 사람이 확인할 수 있게 만드는 것입니다.

같이 보면 좋은 글

출처