RAG 대표 기술 한눈에 보기: 검색부터 GraphRAG까지

AI 자동화2026년 8월 3일글: 홍서진, Duolabs15분 읽기blog information-retrieval llm model-openai-gpt-5 rag rag-guide technical-note

RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.

하지만 실제 RAG 시스템은 “문서를 벡터 DB에 넣고 검색한다”는 한 문장보다 훨씬 넓습니다. 문서를 어떻게 나눌지, 질문을 어떻게 바꿀지, 키워드와 의미 검색을 어떻게 결합할지, 검색 결과를 다시 평가할지에 따라 품질이 크게 달라집니다.

이 글에서는 대표적인 RAG 기술을 파이프라인 순서로 정리하고, 각각 어떤 문제를 해결하는지 살펴보겠습니다.

RAG의 기본 구조

RAG는 크게 색인 단계와 질의 단계로 나뉩니다.

색인 단계
문서 수집 → 정제 → 청킹 → 임베딩 → 검색 색인 저장

질의 단계
질문 분석 → 검색 → 재정렬 → 근거 정제 → 답변 생성 → 출처 표시

2020년 발표된 초기 RAG 연구는 언어 모델의 파라미터 지식과 외부 벡터 색인을 결합했습니다. 이후 연구와 실무에서는 검색 전·후 단계를 세분화한 Advanced RAG, 필요한 모듈을 선택적으로 조합하는 Modular RAG로 발전했습니다.

단계	대표 기술	해결하려는 문제
문서 처리	구조 기반·의미 기반·Parent–Child 청킹	문맥이 잘리는 문제
검색	벡터, BM25, 하이브리드, ColBERT	관련 근거를 놓치는 문제
질문 개선	Rewrite, Multi-query, HyDE, 질문 분해	검색하기 어려운 질문
재정렬	Cross-encoder, late interaction, MMR	상위 결과의 잡음과 중복
근거 정제	압축, 병합, 최신성·권한 필터	컨텍스트 과다와 충돌
제어 구조	Self-RAG, CRAG, Agentic RAG	검색 실패를 교정하지 못하는 문제
데이터 구조	GraphRAG, SQL RAG, Multimodal RAG	관계·수치·이미지 질문
평가	Recall@K, MRR, Faithfulness, RAGAS	개선 효과를 측정하지 못하는 문제

1. 청킹: 검색 품질의 출발점

청킹은 긴 문서를 검색 가능한 작은 단위로 나누는 과정입니다. 청크가 너무 크면 관련 없는 내용까지 모델에 전달되고, 너무 작으면 제목과 조건이 분리되어 의미를 잃을 수 있습니다.

고정 길이 청킹

일정한 문자나 토큰 수로 나눕니다. 구현이 간단하고 처리량을 예측하기 쉽지만, 문장·표·절의 경계를 자를 수 있습니다. 초기 실험의 기준선으로 적합합니다.

구조 기반 청킹

Markdown 헤딩, HTML 섹션, PDF 페이지, 코드의 함수와 클래스처럼 원문의 구조를 이용합니다. 업무 문서와 기술 문서에는 고정 길이보다 자연스러운 경우가 많습니다.

의미 기반 청킹

문장 임베딩의 변화나 주제 전환을 감지해 의미가 달라지는 지점에서 나눕니다. 구조가 약한 대화 기록이나 긴 서술문에 유용하지만 색인 비용과 구현 복잡도가 높아집니다.

Parent–Child 검색

작은 자식 청크로 정밀하게 검색한 뒤, 답변 모델에는 더 큰 부모 섹션을 전달합니다. 검색 정밀도와 문맥 보존을 동시에 얻을 수 있습니다.

Contextual Retrieval

청크만 떼어내면 “이 회사”, “이번 분기”처럼 대상이 사라질 수 있습니다. 문서 전체를 참고해 짧은 설명을 청크 앞에 붙인 뒤 임베딩과 키워드 색인을 만드는 방식이 Contextual Retrieval입니다. 문서 제목과 헤딩 경로를 청크에 포함하는 실무 방식도 같은 문제를 완화합니다.

2. 검색: 의미와 정확한 단어를 함께 찾습니다

벡터 검색

질문과 문서를 임베딩 벡터로 바꾸고 의미적 유사성을 비교합니다. “로그인이 자꾸 풀립니다”라는 질문으로 세션 만료 문서를 찾는 것처럼 표현이 달라도 의미가 비슷한 자료를 찾는 데 강합니다.

BM25 키워드 검색

정확한 단어나 구문을 찾는 전통적인 전문 검색 방식입니다. 제품명, 오류 코드, 계약 조항 번호와 함수명처럼 문자열 자체가 중요한 질문에 유리합니다.

하이브리드 검색

벡터 검색과 BM25 결과를 합칩니다. 의미 검색이 놓친 고유명사를 키워드 검색이 보완하고, 키워드 검색이 놓친 우회 표현을 벡터 검색이 보완합니다.

벡터 검색 순위 ─┐
                ├→ RRF·가중치 융합 → 검색 후보
키워드 검색 순위 ─┘

RRF(Reciprocal Rank Fusion)는 서로 단위가 다른 점수를 직접 더하지 않고 각 검색 결과의 순위를 이용해 결합합니다. 문서와 질문 유형이 다양할 때 안정적인 출발점이 됩니다.

ColBERT와 Late Interaction

일반 벡터 검색은 질문과 문서를 각각 하나의 벡터로 압축합니다. ColBERT 계열은 토큰별 표현을 유지한 뒤 검색 시점에 세밀하게 비교합니다. 단일 벡터 검색보다 표현력이 높고, 모든 질문–문서 쌍을 처음부터 거대한 모델에 넣는 방식보다 효율적인 중간 지점입니다.

3. 질문 변환: 검색하기 좋은 질문으로 바꿉니다

사용자의 질문이 언제나 검색에 적합한 것은 아닙니다. “그건 얼마인가요?”처럼 이전 대화가 없으면 의미를 알 수 없거나, 하나의 질문에 여러 조건이 섞일 수 있습니다.

Query Rewrite

대화 맥락과 생략된 대상을 보완해 독립적인 검색 문장으로 바꿉니다. 원래 의도를 바꾸지 않는 것이 중요합니다.

Multi-query

질문을 여러 표현으로 만들어 각각 검색하고 결과를 합칩니다. 동의어가 많거나 사용자의 표현과 문서 용어가 다른 경우 재현율을 높일 수 있지만 검색량과 지연 시간이 늘어납니다.

질문 분해

복합 질문을 작은 하위 질문으로 나눕니다. 예를 들어 “두 정책의 비용과 지원 범위를 비교해 주세요”를 정책별 비용·범위 검색으로 분리한 뒤 결과를 합칩니다.

HyDE

HyDE(Hypothetical Document Embeddings)는 질문에 대한 가상의 답변 문서를 먼저 만들고, 그 문서를 임베딩해 실제 자료를 검색합니다. 질문보다 답변 형식의 문장이 실제 문서와 더 가까운 경우 검색 성능을 높일 수 있습니다. 다만 가상 문서의 사실을 그대로 근거로 사용해서는 안 되며, 실제 검색 결과로 반드시 다시 grounding해야 합니다.

4. 재정렬: 많이 찾은 뒤 정확하게 줄입니다

1차 검색은 빠르게 후보를 넓게 찾고, reranker가 질문과 각 후보의 관련성을 더 정교하게 평가합니다.

1차 검색 50~150개 → reranking → 상위 5~20개 → 답변 모델

Cross-encoder는 질문과 문서를 함께 읽어 관련성 점수를 계산하므로 정확도가 높지만 후보가 많을수록 비용과 지연 시간이 늘어납니다. ColBERT 같은 late interaction 모델이나 전용 reranker를 상황에 맞게 사용할 수 있습니다.

MMR(Maximal Marginal Relevance)은 관련성뿐 아니라 결과 사이의 다양성을 고려합니다. 같은 문서의 비슷한 청크가 상위 결과를 독점하는 문제를 줄이는 데 유용합니다.

5. 근거 정제: LLM에 많이 넣는 것이 항상 좋지는 않습니다

검색 결과를 모두 프롬프트에 넣으면 컨텍스트가 길어지고 서로 충돌하는 정보가 섞일 수 있습니다.

관련 문장만 남기는 Contextual Compression
같은 문서의 인접 청크 병합
중복 청크 제거
문서별 근거 수 제한
최신 문서와 유효 상태 우선
사용자 권한에 따른 필터링
표의 헤더와 행을 함께 유지

근거 압축은 단순 요약과 다릅니다. 답변에 필요한 조건, 예외와 수치를 잃지 않아야 하므로 원문과 대조하는 평가가 필요합니다.

6. 고급 RAG 구조

Corrective RAG

CRAG(Corrective Retrieval-Augmented Generation)는 검색 결과의 품질을 평가하고, 근거가 약하면 검색을 보완하거나 다른 경로를 사용합니다. 처음 검색한 결과를 무조건 믿지 않는 구조입니다.

Self-RAG

Self-RAG는 모델이 검색이 필요한지 판단하고, 가져온 근거와 자신의 답변을 스스로 비평하도록 학습한 방식입니다. 모든 질문에서 고정된 수의 문서를 검색하는 대신 필요에 따라 검색과 반성을 수행합니다.

Adaptive RAG

질문의 복잡도와 유형에 따라 전략을 선택합니다. 일반 대화는 검색 없이 처리하고, 단순한 문서 질문은 한 번 검색하며, 복잡한 비교 질문은 분해와 반복 검색을 수행할 수 있습니다.

Agentic RAG

에이전트가 문서 검색, SQL, 웹 검색과 파일 탐색 같은 도구 중 필요한 것을 선택합니다. 결과가 부족하면 질문을 수정해 다시 검색하고 여러 데이터 소스의 결과를 합칩니다. 유연한 대신 실행 경로와 비용을 예측하기 어렵기 때문에 단계 수, 권한과 종료 조건이 필요합니다.

GraphRAG

GraphRAG는 문서에서 인물, 조직, 제품과 사건 등의 엔터티와 관계를 추출해 지식 그래프를 구성합니다. 특정 문장을 찾는 질문보다 “전체 자료의 주요 주제는 무엇인가요?”처럼 문서 집합 전체를 이해해야 하는 질문에 유리합니다.

그래프 생성과 커뮤니티 요약에는 추가 비용이 들기 때문에 단순 FAQ 검색에 무조건 적용할 기술은 아닙니다. 관계 추적과 전체 경향 분석이 중요한 데이터에서 검토하는 편이 좋습니다.

SQL RAG와 Multimodal RAG

정확한 주문 수, 매출 합계처럼 구조화된 값은 문서 검색보다 SQL 조회가 적합합니다. 문서에는 정책과 설명을 묻고 DB에는 실제 수치를 묻는 식으로 도구를 분리할 수 있습니다.

Multimodal RAG는 텍스트뿐 아니라 PDF 페이지, 표, 이미지, 음성과 영상을 함께 색인하고 검색합니다. OCR만으로 의미가 손실되는 도표나 화면 자료는 이미지 임베딩과 원본 페이지 참조를 함께 사용해야 합니다.

7. 평가와 보안도 RAG 기술입니다

검색 결과가 그럴듯해 보인다는 인상만으로 품질을 판단해서는 안 됩니다. 검색과 답변을 분리해 평가해야 합니다.

평가 대상	대표 지표·질문
검색	Recall@K, Precision@K, MRR, nDCG
근거	필요한 문서가 포함됐는가, 잡음이 적은가
답변	근거 충실도, 관련성, 인용 정확도
실패	답이 없을 때 추측하지 않는가
운영	응답 시간, 비용, 동시 요청, 색인 지연

RAGAS는 검색된 컨텍스트의 품질, 답변의 근거 충실도와 관련성 등을 나누어 평가하려는 대표적인 프레임워크입니다. 자동 평가 결과만 믿기보다 실제 질문과 사람이 확인한 정답 세트를 함께 운영하는 편이 안전합니다.

보안에서는 답변을 만든 뒤 민감한 문장을 지우는 것보다 검색 전에 권한을 적용해야 합니다. 공개·내부·고객별 색인을 분리하고, 삭제나 비공개 전환이 검색 색인에도 반영되는지 확인해야 합니다.

어떤 순서로 도입하면 좋을까요?

모든 고급 기법을 처음부터 적용할 필요는 없습니다.

구조 기반 청킹과 벡터 검색으로 기준선을 만듭니다.
BM25와 하이브리드 검색을 추가합니다.
실제 질문 평가 세트로 실패 유형을 찾습니다.
검색 잡음이 문제라면 reranker를 추가합니다.
문맥 손실이 문제라면 Parent–Child 또는 Contextual Retrieval을 적용합니다.
복합 질문이 많다면 질문 분해와 Agentic RAG를 검토합니다.
전체 문서의 관계와 경향이 중요할 때 GraphRAG를 검토합니다.

기술의 수보다 현재 실패 원인을 설명할 수 있는 것이 중요합니다. 검색에서 문서를 놓쳤는지, 찾았지만 순위가 낮았는지, 모델이 근거를 무시했는지를 구분해야 다음 개선 기술을 고를 수 있습니다.

듀오랩스가 보는 관점

RAG는 하나의 제품이나 라이브러리가 아니라 검색과 생성 사이의 여러 판단을 설계하는 방법입니다. 큰 모델과 복잡한 에이전트를 먼저 붙이는 것보다 문서 구조, 검색 평가, 최신성·권한 필터와 출처 확인을 먼저 갖추는 편이 안정적입니다.

좋은 RAG 시스템은 모든 질문에 답하지 않습니다. 관련 근거를 찾았을 때는 출처와 함께 답하고, 근거가 약하거나 권한이 없을 때는 안전하게 멈춥니다. 고급 RAG 기술의 목적도 결국 이 판단을 더 정확하게 만드는 데 있습니다.