Vector RAG 기초 — 검색이 어떻게 작동하는가

초보자들을 위한 RAG 개념 20분 마스터클래스 (3년 RAG 프로젝트 압축 경험을 곁들인)

youtube.com

RAG 시스템의 성능은 Generation이 아니라 Retrieval에서 결정된다. 내용은 위 YouTube 영상을 참고했으며, 이 글에서는 Embedding, Chunking, 검색 전략을 중심으로 실제 검색 품질을 좌우하는 요소들을 정리한다.

RAG란?

Retrieval(검색) + Augmented(강화된) + Generation(생성)

검색한 자료로 LLM의 답변을 보강하는 기술이다.

LLM이 오픈북 시험을 볼 수 있도록 하는 것에 비유할 수 있다.
질문 → 검색 → 컨텍스트 구성 → 답변 생성의 파이프라인으로 동작한다.
LLM은 학습이 끝난 시점에 멈추지만, 외부 자료를 끌어오는 역할을 RAG가 담당한다.

RAG의 전체 흐름은 아래와 같다. RAG Architecture

이 구조에서 핵심은 Retrieval 이후 Context 구성 단계다.

Embedding과 Vector

텍스트를 숫자로 바꾸는 핵심 원리다.

사용자 Input이 Embedding 모델이라는 의미 분석 엔진을 통과하면 수백~수천 차원의 배열로 변환된다.
비슷한 의미일수록 숫자 공간에서 가까운 위치에 놓인다 — 시맨틱 서치의 원리 : '단어가 아닌, 의미로 검색'
- 마트에서 비슷한 상품을 가까이 배치하듯이, 텍스트의 의미를 숫자로 표현해서 비슷한 의미끼리 가까운 위치에 놓는 것에 비유할 수 있다.
차원이 높을수록 의미를 세밀하게 표현하지만, 저장 공간과 속도가 trade-off 관계다.

Chunking과 Parsing

문서를 어떻게 잘라야 검색이 잘 될까?

텍스트가 방대할수록 의미가 희석되므로 통째로 임베딩할 수 없다
청크(chunk): LLM에게 전달되기 전 검색되는 정보 조각

청킹 전략 비교

전략	장점	단점
길이 기반 청킹	구현 단순, 실험 변수 다양	정보가 쪼개져 검색 품질 저하 가능
의미/문단 레벨 청킹	의미 보존	문단 경계 정의 어려움, 처리 속도 느림

청킹은 Retrieval 품질을 거의 결정하는 요소다. 잘못 나눈 청크는 아무리 좋은 모델을 써도 복구되지 않는다. 테이블, OCR 스캔, 이미지 등 다양한 문서 형태가 존재하고, 청킹을 예쁘게 하는 것이 쉽지 않아 청킹 자체가 RAG 성능의 병목이 되는 경우가 많다.

Parser 선택이 청킹 품질을 결정짓는 관문이다. 좋은 Parser = 좋은 청킹의 시작이다.

Vector Database

'숫자들(청킹한 것들)을 어디에 저장하고 어떻게 검색하는지?'에 대한 해답이다.

벡터 DB는 일반 DB와 달리 조건 매칭이 아닌 유사도 기반 검색을 지원한다
사용자가 질문하면 → 질문을 임베딩으로 변환 → 벡터 DB에서 가장 유사한 청크를 검색 → LLM에 컨텍스트로 전달 → 답변 생성

청크들은 개별 임베딩되어 독립적으로 처리되며, 이로 인해 문맥이 단절되는 문제가 발생한다. (앞뒤 맥락을 모르는 상태)

대부분 RAG의 문제가 되는 지점

Generation(답변 생성) << Retrieval(검색)

실무에서 대부분의 문제는 Generation이 아니라 Retrieval에서 발생한다.

검색 대상 문서가 수백~수천 개로 늘어나는 순간 검색 품질이 급격히 떨어진다. LLM이 틀리는 이유는 모델 성능에 의해 답변을 못 만드는 게 아니라, 엉뚱한 청크가 올라가서 엉뚱한 답변이 나오는 것이다. 즉, 청크 자체의 품질을 높이는 게 가장 중요하다.

초기 디버깅 루틴

질문 선정: 실제 필드에서 자주 받는 질문 5~10개 선정
청크 확인: 질문별 벡터 검색 결과 1위~20위를 직접 눈으로 확인

이상한 청크가 올라와 있거나 있어야 할 정보가 누락되어 있는지 확인하며 감 잡기! RAG 문제의 80%는 이 단계에서 발견된다.

Dense / Sparse Embedding과 Hybrid Search

시맨틱 서치만으로는 못 잡는 영역이 존재한다.

Dense Embedding: 의미 기반 검색. 유사 의미를 찾는 데 강하다
Sparse Embedding: 키워드 기반 검색(BM25 등). 특정 단어 빈도와 희귀도 기반으로 점수를 매기며 희소 벡터 형태다
Hybrid Search: 두 방식을 동시에 돌리고 합쳐서 최종 결과를 만드는 방식

Hybrid Search에서 Dense와 Sparse의 가중치 조절이 검색 품질을 직접적으로 결정한다. 도메인 전문 용어가 많은 산업군에서는 Sparse 가중치를 높게 잡는 것이 효과적인 경우가 많다고 한다.

Reranker

검색 결과를 다시 정밀하게 평가하는 기법이다.

1차 검색(기본 유사도) → 정밀 비교(청크와 질문을 나란히 놓고 해당 청크가 질문에 정확히 답하는지 평가)

Reranker는 정확도를 높이는 대신 latency를 증가시키므로, 서비스 특성에 따라 선택적으로 적용해야 한다.

개인용, 신뢰도가 중요한 상황, 속도가 느려도 된다면 Reranker 사용을 권장한다.
다수 사용자 서비스라면 사용자 경험까지 고려해서 도입 여부를 판단하는 것이 좋다.

Contextual Retrieval과 Late Chunking (고급)

기본 RAG의 가장 큰 약점은 청킹 시 맥락이 잘린다는 점이다.

Contextual Retrieval

Anthropic Engineering — 청크마다 전체 문서 맥락을 붙여 검색 품질을 높이는 방법

anthropic.com

각 청크를 임베딩하기 전에 LLM을 사용해서 그 청크가 전체 문서에서 어디에 위치하는지 설명하는 짧은 맥락을 붙이는 방식이다. 청크마다 LLM을 호출하므로 비용이 크게 증가하지만, 청크가 의미 있는 경우에만 맥락을 붙이는 바이너리 판별 로직으로 비용을 절감할 수 있다.

검색 품질이 확보되면 이후 프롬프트 튜닝, 모델 교체 시에도 안정적인 베이스라인을 유지할 수 있다.

Late Chunking

순서를 뒤집는 새로운 접근 방식이다. 문서 전체를 긴 컨텍스트 임베딩 모델에 먼저 넣어 토큰 단위 임베딩을 한 번에 만든 후, 이후에 청크로 자른다. 긴 컨텍스트를 처리할 수 있는 임베딩 모델이 필요하다는 제약이 있지만, Contextual Retrieval 대비 비용이 낮다.

RAG는 정말 죽었을까?

"RAG is dead"라는 말이 커뮤니티에 떠돌면서 화제가 되었는데, 이는 에이전틱 서치가 등장한 이후에 RAG의 효용성이 낮아졌다는 주장이 나왔기 때문이다.

에이전틱 서치란 AI 에이전트가 검색과 추론을 반복하며 정보를 탐색하는 방식이다. grep, glob은 그 구현 수단 중 하나다.

grep: 함수명, 변수명, 파일 경로 등 정확한 문자열을 찾는 데 특화
embedding: 유사 코드 탐색, 의미 기반 검색, 자연어 질의에 특화

코드 검색에서는 정확한 매칭이 우선되므로 grep이 유리한 경우가 많다. 반면 비정형 텍스트에서는 의미적 연결 탐색을 위해 RAG가 여전히 유효하다.

RAG의 본질은 검색에 있으며, 검색 방식이 에이전트 안에 녹아드는 방향으로 진화하고 있는 것이다. 컨텍스트 엔지니어링이라는 이름으로 리브랜딩되었다는 시각도 있다 — 요구사항이 더 정교해지고 구현이 복잡해진 것이다. 결국 성능은 얼마나 “정확한 컨텍스트를 가져오느냐”에 달려 있다.

핵심 요약

RAG의 성능은 Generation이 아니라 Retrieval이 결정한다
Retrieval 품질은 Chunking + Embedding + Search 전략에서 결정된다
특히 Chunking과 검색 전략(Hybrid, Reranker)이 실제 성능의 대부분을 좌우한다

이어지는 포스트에서는 Vector RAG의 한계점과 이를 개선하고자 등장한 Graph RAG에 대해 학습하였다.