로컬 RAG 시스템의 두뇌 삼형제 — Ollama 모델 3종 역할 분담기

왜 모델이 3개나 필요한가?

"AI 검색 시스템을 만들고 싶은데, 모델 하나로 다 되는 거 아닌가요?"

처음 RAG(Retrieval-Augmented Generation, 문서를 검색해서 AI가 답변하는 시스템)를 만들려고 하면 자연스럽게 드는 의문입니다. 하나의 만능 모델로 모든 걸 처리하면 되지 않을까? 결론부터 말하면, 역할별로 전문 모델을 배치하는 게 성능과 효율 모두에서 훨씬 유리합니다.

마치 병원에서 접수(분류), 진료(판단), 정밀검사(평가)를 한 사람이 다 하지 않는 것처럼, RAG 시스템도 각 단계에 맞는 전문가가 필요합니다. 저는 1,400개가 넘는 Obsidian 노트를 검색하는 개인 지식 금고 RAG 시스템을 구축하면서, 용도에 맞게 3개의 Qwen 모델을 배치했습니다.

가장 좋은 점은? 전부 로컬에서 무료로 돌아갑니다. API 비용 $0입니다.

실제로 이렇게 쓰고 있습니다

시나리오 1 — "지난 EMBA 수업에서 귀인이론 어떻게 설명했더라?"

검색 명령을 입력하면, 첫 번째 모델이 질문을 벡터로 바꾸고(0.3초), 두 번째 모델이 검색된 후보들의 관련도를 판단하고(1~2초), 최종 결과를 보여줍니다. 1,400개 파일에서 3초 안에 정확한 강의노트 섹션을 찾아냅니다.

시나리오 2 — "이 시스템이 정말 잘 작동하는 건 맞아?"

50개 테스트 문제를 세 번째 모델(가장 크고 똑똑한 녀석)에게 채점시킵니다. "검색 결과가 질문과 관련 있는가?", "답변이 검색된 문서에 충실한가?"를 10점 만점으로 평가합니다. 학생이 시험 치르고, 외부 전문가가 채점하는 구조입니다.

파이프라인 전체 그림

RAG 시스템은 크게 인덱싱(문서를 DB에 넣기) → 검색(질문으로 찾기) → 평가(품질 측정)의 3단계로 나뉩니다. 각 단계에 배치된 모델을 순서대로 소개합니다.

---

1번 선수: Qwen3-Embedding-8B — 문서를 숫자로 바꾸는 번역가

어디에 쓰나?

RAG의 가장 기본이 되는 임베딩(embedding, 텍스트를 벡터 숫자 배열로 변환하는 것) 단계에서 사용합니다. 인덱싱할 때는 모든 문서 청크를 벡터로 바꾸고, 검색할 때는 사용자 질문을 벡터로 바꿔서 가장 가까운 문서를 찾습니다.

왜 이 모델인가?

항목	수치
MTEB 다국어 점수	70.58 (오픈소스 1위, 2025년 6월 기준)
MTEB 영어 v2	75.22
C-MTEB (중국어)	73.84
임베딩 차원	4,096 (MRL로 32~4,096 가변)
컨텍스트 길이	32,768 토큰
지원 언어	100개 이상
로컬 크기	4.7 GB

이 모델을 선택한 핵심 이유는 한국어+영어 혼합 환경에서 최고 성능이기 때문입니다.

제 지식 금고는 EMBA 강의노트(한국어), 기술 문서(영어 혼합), 캘린더 회의록(한국어) 등 다국어가 섞여 있습니다. 대부분의 영어 전용 임베딩 모델은 한국어에서 성능이 확 떨어지는데, Qwen3-Embedding은 MTEB 다국어 리더보드 1위입니다.

또 하나 좋은 점은 MRL(Matryoshka Representation Learning)을 지원해서, 기본 4,096차원 벡터를 1,024차원으로 줄여도 성능 저하가 미미합니다. 저장 공간이 부족해지면 이 기능으로 벡터 DB 크기를 75% 줄일 수 있습니다.

실제 성능

1,400 파일 → 4,302 벡터 포인트
전체 인덱싱: 약 23분 (GPU)
단건 임베딩: < 0.3초

---

2번 선수: Qwen3:30b-a3b — 빠르고 똑똑한 현장 감독

어디에 쓰나?

두 가지 핵심 역할을 맡고 있습니다.

역할 A — Contextual Retrieval (맥락 설명 생성)

인덱싱 단계에서 각 문서 청크에 "이 청크가 전체 문서에서 어디에 해당하는지" 50토큰 이하의 맥락 설명을 붙여줍니다. Anthropic이 제안한 Contextual Retrieval 기법입니다.

예를 들어 "합의성, 특이성, 일관성"이라는 청크만 보면 무슨 맥락인지 알기 어렵지만, 이 모델이 "조직행위론 6장에서 귀인이론의 공변량 모델을 설명하는 부분으로, 합의성·특이성·일관성의 세 요소를 다룬다"라는 설명을 붙여주면, 임베딩 품질이 크게 향상됩니다.

역할 B — LLM Reranking (검색 결과 재정렬)

검색 단계에서 벡터 유사도로 뽑은 상위 15개 후보를 이 모델에게 보내서, "이 질문에 대해 각 문서가 1~10점 중 몇 점인가?"를 물어봅니다. 벡터 유사도만으로는 놓치는 의미적 관련성을 LLM이 잡아줍니다.

왜 이 모델인가?

항목	수치
전체 파라미터	30.5B (305억)
활성 파라미터	3.3B (33억, 전체의 11%)
아키텍처	MoE (128 전문가 중 8개 활성)
컨텍스트 길이	32,768 토큰 (YaRN 확장 시 131,072)
로컬 크기	18 GB

이 모델의 핵심 장점은 MoE(Mixture of Experts) 아키텍처입니다. 전체 305억 파라미터 중 매번 33억 개만 활성화되므로, 300억급 모델의 지능을 30억급 모델의 속도로 사용할 수 있습니다.

RAG 시스템에서 이 모델이 처리하는 작업량을 보면 선택 이유가 명확합니다:

• 맥락 생성: 4,300개 청크 × LLM 호출 = 대량 배치 작업
• Reranking: 검색마다 15개 후보 평가 = 실시간 응답 필요

대량이면서 실시간이어야 하는 이 조합에서, 거대 모델은 너무 느리고 소형 모델은 품질이 부족합니다. Qwen3:30b-a3b는 딱 그 스위트 스팟에 위치합니다. Qwen 공식 벤치마크에서 QwQ-32B(320억 파라미터 전부 활성)와 비슷한 성능을 10분의 1 연산량으로 달성한다고 합니다.

실제 성능

맥락 설명 1건: ~3초 (50토큰 생성)
Reranking 15건: ~2초
전체 인덱싱 시 추가 시간: 약 2~3배 (맥락 생성 때문)

---

3번 선수: Qwen3.5-122B-A10B — 최종 심사위원

어디에 쓰나?

RAG 시스템이 실제로 잘 작동하는지 품질을 평가하는 단계에서 사용합니다. RAGAS(RAG Assessment, RAG 평가 프레임워크)의 judge(심사위원) 역할입니다.

50개의 골든 Q&A 쌍(정답이 미리 정해진 테스트 셋)에 대해 RAG 시스템이 검색한 결과와 생성한 답변을 채점합니다.

평가하는 4가지 메트릭:

메트릭	측정 내용	목표
Context Precision	검색된 문서가 관련 있는가?	≥ 0.80
Context Recall	필요한 문서가 모두 검색되었는가?	≥ 0.75
Faithfulness	답변이 검색된 문서에 충실한가?	≥ 0.85
Answer Relevancy	답변이 질문에 적합한가?	≥ 0.80

왜 이 모델인가?

항목	수치
전체 파라미터	122B (1,220억)
활성 파라미터	10B (100억, 전체의 8%)
아키텍처	MoE (256 전문가)
컨텍스트 길이	262,144 토큰 (100만+ 확장 가능)
로컬 크기	81 GB

주요 벤치마크 성적표:

벤치마크	점수
MMLU-Pro (지식 추론)	86.7%
MMLU-Redux	94.0%
GPQA Diamond (전문가급 과학)	86.6
SWE-bench Verified (코드)	72.0%
IFEval (지시 수행)	93.4%
LiveCodeBench v6	78.9

이 모델을 judge로 쓰는 이유는 단순합니다: 채점관은 학생보다 실력이 좋아야 합니다.

2번 모델(Qwen3:30b)이 생성한 맥락 설명과 reranking 결과를, 그보다 훨씬 강력한 모델이 평가해야 공정한 채점이 됩니다. 같은 모델이 만들고 같은 모델이 채점하면 자기 자신의 편향을 발견할 수 없습니다.

81GB로 크지만, MoE 덕분에 실제 추론 시 100억 파라미터만 활성화됩니다. 그리고 평가는 50개 Q&A만 처리하면 되는 일회성 배치 작업이라, 느려도 상관없습니다. 품질만 최고면 됩니다.

실제 성능

50개 Q&A 평가: 약 30~60분 (일회성)
1건 채점: ~30초
실행 전 다른 모델 언로드 권장 (VRAM 81GB 필요)

---

왜 전부 Qwen인가?

세 모델 모두 Qwen(Alibaba Cloud) 시리즈를 선택한 이유가 있습니다:

1. 한국어 성능이 우수합니다. CJK(중국·일본·한국어) 언어에 강한 사전학습 데이터를 가지고 있어, 한국어 EMBA 강의노트와 영어 기술 문서를 모두 잘 처리합니다.
2. Ollama 생태계가 잘 갖춰져 있습니다. ollama pull 한 줄로 설치하고, 같은 API 엔드포인트(/api/embed, /api/generate)로 통일해서 호출할 수 있습니다.
3. MoE 모델이 로컬에 유리합니다. 거대 파라미터의 지능을 소형 모델의 속도로 쓸 수 있어, 개인 서버에서 API 비용 없이 운영 가능합니다.

한눈에 보는 모델 배치표

모델	크기	활성 파라미터	역할	처리량	속도 우선?
Qwen3-Embedding-8B	4.7GB	8B	임베딩 (벡터 변환)	4,300건	속도+품질
Qwen3:30b-a3b	18GB	3.3B	맥락 생성 + Reranking	4,300건 + 매 검색	속도
Qwen3.5-122B-A10B	81GB	10B	RAGAS 평가 (채점)	50건	품질

핵심 원칙: 대량 처리는 작고 빠른 모델, 소량 고품질은 크고 정확한 모델. 이 역할 분담 덕분에 1,400개 파일의 지식 금고를 API 비용 $0으로, 로컬 GPU 하나에서 운영할 수 있습니다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.