문서에서 에이전트까지,
RAG + MCP 파이프라인 설계의 전체 그림
청킹에서 임베딩, LLM 탑재, MCP 도구 확장까지.
RAG 파이프라인의 전체 흐름을
벤치마크 데이터와 함께 설계합니다.
RAG를 만들었습니다. 그 다음은?
문서를 넣고 검색하고 답변을 생성하는 것까지는
RAG의 절반입니다.
나머지 절반은 이 파이프라인을
에이전트가 도구로 활용할 수 있게 만드는 것입니다.
전체 파이프라인
문서가 에이전트의 도구가 되기까지
7개의 단계를 거칩니다.
문서 수집
PDF, 문서, 웹페이지, DB에서 원본 텍스트를 추출합니다.
청킹
원본을 검색에 적합한 크기로 분할합니다. 정확도를 결정하는 가장 중요한 단계.
임베딩
텍스트 청크를 벡터(숫자 배열)로 변환합니다. 의미적 유사도 검색의 기반.
벡터 저장
임베딩 벡터를 벡터 DB에 저장합니다. 메타데이터(출처, 날짜 등) 함께 저장.
검색 + 리랭킹
사용자 질문을 임베딩하여 유사 벡터를 검색하고, 관련도 순으로 재정렬합니다.
LLM 생성
검색된 컨텍스트와 질문을 LLM에 전달하여 답변을 생성합니다.
MCP 도구로 노출
RAG 파이프라인을 MCP 도구로 감싸면 에이전트가 자율적으로 호출합니다.
1단계. 청킹, 정확도를 결정하는 가장 중요한 단계
Vectara의 NAACL 2025 연구에 따르면
청킹 설정이 임베딩 모델 선택만큼
검색 품질에 영향을 미칩니다.
청킹을 잘못 설정하면
컨텍스트 정밀도가 15~30% 떨어집니다.
청킹 전략별 정확도 (Vecta 2026, 50개 학술 논문 대상)
가장 높은 정확도. 범용 기본값으로 권장
오버랩 없음. 경계에서 문맥 손실
짧은 청크. 개별 검색은 잘 되지만 LLM 컨텍스트 부족
평균 43토큰의 너무 작은 단편. 검색은 좋지만 답변 품질 낮음
PDF 등 페이지 구조가 명확한 문서에서만 유효
실무 기본값
512 토큰, 재귀 분할, 10~20% 오버랩으로 시작하세요.
팩트 기반 짧은 질문 → 256~512 토큰.
분석/멀티홉 질문 → 512~1,024 토큰.
기본값에서 시작해서 실제 질의 패턴으로 튜닝합니다.
시맨틱 청킹은 만능이 아니다
“의미 단위로 나누면 당연히 좋겠지”는
벤치마크에서 부정됐습니다.
시맨틱 청킹은 청크가 너무 작아져서(평균 43토큰)
LLM에 충분한 컨텍스트를 주지 못합니다.
검색 정밀도(recall)는 높지만 답변 정확도(accuracy)는 낮습니다.
2단계. 임베딩, 의미를 숫자로 바꾸다
청크를 벡터로 변환하는 단계입니다.
임베딩 모델의 선택이
검색의 정확도와 비용을 결정합니다.
| 모델 | 파라미터 | 다국어 | 특징 |
|---|---|---|---|
| BGE-M3 | 568M | 100+ | Dense + Sparse + ColBERT. 8K 컨텍스트. 한국어 우수 |
| Qwen3-Embedding-0.6B | 596M | 90+ | MMTEB 상위. 가격 대비 성능 우수 |
| Kanana-Nano-2.1B | 2.1B | 한국어 특화 | 카카오 개발. 한국어 문서 검색에 경쟁력 |
| Qwen3-Embedding-8B | 7.6B | 90+ | MMTEB 최상위. GPU 필요. 최고 정확도 |
| OpenAI text-embedding-3-large | 비공개 | 다국어 | API 기반. 인프라 불필요. 데이터 외부 전송 |
선택 기준
· 한국어 문서 중심 → BGE-M3 또는 Kanana-Nano-2.1B
· 다국어 + 가격 대비 성능 → Qwen3-Embedding-0.6B
· 최고 정확도 (GPU 여유) → Qwen3-Embedding-8B
· 인프라 없이 빠르게 → OpenAI API (데이터 외부 전송 주의)
임베딩 모델 크기와 정확도의 트레이드오프
모델이 클수록 정확도가 올라가지만
VRAM 사용량, 추론 시간, 비용도 함께 올라갑니다.
0.6B 모델로 시작해서 정확도가 부족하면
단계적으로 올리는 것을 권장합니다.
3단계. 벡터 저장
임베딩 벡터를 저장하고 검색하는 저장소입니다.
2026년 트렌드는 전용 벡터 DB보다
기존 RDBMS의 벡터 확장(pgvector 등)으로
흡수되는 방향입니다.
저장 시 반드시 포함할 메타데이터
· 출처 (파일명, URL, 문서 ID)
· 날짜 (문서 작성일, 인제스트 일시)
· 테넌트 ID (멀티테넌트 환경일 경우 필수)
· 청크 위치 (원본에서의 위치, 이전/다음 청크 참조)
4단계. 검색과 리랭킹
벡터 검색(시맨틱)만으로는 부족합니다.
2026년 현재 프로덕션 RAG의 표준은
하이브리드 검색 + 리랭킹입니다.
검색 방식별 성능 비교
프로덕션 표준. 2026 Q1 도입 의향 33%로 3배 증가
키워드 정확 매칭이 필요 없는 경우
키워드 매칭 누락. 고유명사, 코드명 등에서 실패
의미적 유사도 없음. 유의어, 의역에 실패
하이브리드 검색의 원리
· 벡터 검색: “서버가 느려요” → 성능 관련 문서 검색 (의미)
· 키워드 검색(BM25): “CVE-2026-78948” → 정확한 코드 매칭
· 리랭킹: 두 결과를 합치고 질문과의 관련도 순으로 재정렬
5단계. LLM 탑재
검색된 컨텍스트와 사용자 질문을
LLM에 전달하여 답변을 생성합니다.
이 단계에서 자주 발생하는 문제가 있습니다.
컨텍스트 윈도우 관리
검색 결과를 많이 넣을수록 좋은 것이 아닙니다.
Chroma의 2025년 연구에 따르면
컨텍스트가 길어질수록 검색 성능이 떨어집니다.
상위 3~5개 청크만 전달하는 것이 일반적입니다.
출처 표시
답변에 출처를 포함하도록 프롬프트에 지시합니다.
사용자가 원본 문서를 확인할 수 있어야
답변에 대한 신뢰가 생깁니다.
환각 방지
“검색된 컨텍스트에 없는 내용은 답하지 마라”를
시스템 프롬프트에 명시합니다.
RAG는 환각을 70~90% 줄이지만 완전히 없애지는 못합니다.
6단계. MCP로 확장, RAG를 도구로 만들다
여기까지가 “일반적인 RAG”입니다.
그런데 이 RAG를 웹 UI에서만 쓸 건가요?
RAG 파이프라인을 MCP 도구로 감싸면
에이전트가 자율적으로 호출할 수 있게 됩니다.
메신저에서, IDE에서, 다른 에이전트에서
같은 RAG를 호출합니다.
MCP 도구로 감싸면 달라지는 것
· 자동 디스커버리: 에이전트가 RAG 도구를 알아서 발견하고 사용
· 멀티 클라이언트: 웹, 메신저, IDE, CLI에서 같은 RAG 호출
· 보안 정책 일괄 적용: 인증, 레이트 리밋, 감사 로그가 MCP 레이어에서 처리
· 도구 조합: 에이전트가 RAG + 웹검색 + DB조회를 상황에 맞게 조합
MCP 도구 정의 예시 (개념)
name: search_docs
description: 사내 문서에서 관련 정보를 검색하여 답변합니다.
input: query (검색할 질문), top_k (반환할 결과 수, 기본 5)
output: 답변 텍스트 + 출처 목록
이 구조에서 RAG 파이프라인 내부를 수정해도
에이전트 쪽 코드는 바뀌지 않습니다.
청킹 전략을 바꾸든, 임베딩 모델을 교체하든,
MCP 인터페이스만 유지하면 됩니다.
보안 고려사항
RAG 파이프라인은 새로운 공격 표면을 만듭니다.
특히 코퍼스 포이즈닝과 테넌트 교차 누출에 주의해야 합니다.
RAG 보안 위협 성공률
USENIX Security 2025. 악성 문서 5개로 답변 조작
벡터에서 원문 텍스트 80% 복원
논리적 격리만으로는 교차 접근 가능
필수 보안 조치
· 문서 인제스트 시 출처 검증 + 해시 기록
· 멀티테넌트 환경은 물리적 격리(Silo 패턴)
· 벡터 DB 접근에 인증/인가 필수
· 답변 생성 시 출처 문서의 신뢰도 점수 표시
RAG 보안에 대한 상세 분석은
RAG가 속고 있다, 코퍼스 포이즈닝과 LLM 오염의 실제를 참고하세요.
리원에이스 제품으로 구축하기
이 파이프라인의 각 단계는
리원에이스의 자체 제품에 매핑됩니다.
의미 단위 문서 분할. 문서 타입별 최적 전략 자동 선택.
경량 벡터 임베딩 모델. 한국어 최적화.
자동 인제스트 파이프라인. 문서 수집부터 벡터 저장까지.
MonolithDB 기반 벡터 엔진. 접근 제어, 테넌트 격리 내장.
검색, 리랭킹, LLM 생성을 통합한 엔드투엔드 파이프라인.
RAG를 MCP 도구로 감싸는 프레임워크. 보안, 감사 내장.
RAG는 검색과 생성으로 끝나지 않습니다.
MCP로 도구화해야 에이전트 시대의 인프라가 됩니다.
문서를 넣고 답변을 받는 것은 1세대 RAG이고,
에이전트가 상황에 맞게 자율적으로 검색하는 것이
2026년의 RAG입니다.
청킹은 512 토큰으로 시작하고,
검색은 하이브리드로 가고,
MCP로 감싸서 어디서든 쓸 수 있게 만드세요.
나머지는 데이터와 사용 패턴이 알려줍니다.
본 글에서 인용한 벤치마크는 Vecta (2026), Vectara NAACL (2025), NVIDIA RAG Benchmark, Chroma Context Rot Research (2025), MMTEB Multilingual Benchmark 자료에 기반합니다.
본 글은 리원에이스 기술개발본부가 작성한 기술 콘텐츠입니다. 외부 공유 시 출처를 명시해 주세요.
2026년 8월 19일
리원에이스 기술개발본부