RAG란? 초보자를 위한 핵심 개념 완전 정리

RAG(Retrieval-Augmented Generation)는 AI가 모르는 정보를 직접 검색해서 답하게 해주는 구조입니다. 검색 증강 생성이라고도 불리는데, LLM이 학습 시점 이후의 데이터나 사내 내부 문서처럼 알 수 없는 정보를 실시간으로 참고하며 답변할 수 있게 만들어줍니다. 이 글에서는 RAG의 작동 원리부터 임베딩, 청킹, 벡터 데이터베이스, 하이브리드 서치까지 3년 RAG 프로젝트 경험을 바탕으로 한 핵심 개념을 단계별로 정리합니다.

 

RAG란 무엇인가? AI가 오픈북 시험을 보는 방법

LLM만으로는 부족한 이유

LLM은 훈련이 끝나는 순간 시간이 멈춥니다. 그 이후에 생긴 최신 뉴스, 우리 회사의 내부 정책, 고객 데이터 같은 건 모델이 알 수가 없습니다. 아무리 성능이 좋은 모델이라도 학습하지 않은 정보에 대해서는 틀린 답을 만들어내거나 아예 모른다고 할 수밖에 없는 구조입니다.

 

이 문제가 특히 뚜렷하게 드러나는 건 기업 환경입니다. 수천 페이지짜리 사내 위키, 매달 업데이트되는 정책 문서, 고객별 계약서 같은 데이터는 공개된 인터넷에 없습니다. RAG는 바로 이 지식 공백을 메우기 위해 등장한 구조입니다.

RAG의 핵심 아이디어, 오픈북 시험

대학교 시험에 비유하면 이해하기 쉽습니다. 닫힌 책 시험은 기억에만 의존합니다. 모르면 끝입니다. 반면 오픈북 시험은 교재를 참고할 수 있습니다. "교재 45페이지에 따르면..." 이런 식으로 근거를 제시하면서 훨씬 정확한 답을 쓸 수 있죠.

 

여기서 LLM은 공교육을 받은 기초 지식이 있는 학생입니다. RAG는 그 학생에게 오픈북 시험을 보게 해주는 구조입니다. 시험 중에 교재를 꺼내 볼 수 있게 만드는 것이죠. 흐름은 단순합니다. 사용자가 질문하면 관련 문서를 검색하고, 그 문서를 참고해서 정확한 답변을 생성합니다. 질문, 검색, 답변 이 세 단계가 RAG의 전부입니다.

 

RAG의 5가지 핵심 부품

RAG를 제대로 이해하려면 그 안에 들어가는 부품들을 하나씩 알아야 합니다. 각 개념이 연결되면서 하나의 파이프라인이 완성됩니다.

1. 임베딩, 텍스트를 숫자로 변환하는 기술

임베딩을 이해하는 가장 쉬운 비유는 마트입니다. 마트에서 만두를 찾으려면 3번 통로, 4번 선반, 1035번이라는 위치 정보가 필요합니다. 냉동 파전은 만두 근처인 864번에 있고, 고양이 장난감은 34번 통로 379,245번으로 전혀 다른 위치입니다. 임베딩도 이와 같습니다. 텍스트의 의미를 숫자로 표현해서 비슷한 의미끼리 가까운 위치에 놓는 것입니다.

 

더 기술적으로 설명하면, "인플레이션의 원인"이라는 문장이 임베딩 모델을 통과하면 [0.1, -0.45, 0.78, ...] 같은 숫자 배열로 변환됩니다. 이 숫자 배열을 벡터라고 부릅니다. 문장의 지문이라고 생각하면 됩니다. 비슷한 의미면 비슷한 숫자, 다른 의미면 다른 숫자가 나옵니다.

2. 벡터, 임베딩이 만들어낸 숫자 배열

벡터의 길이를 차원이라고 부릅니다. 소형 모델은 384차원 또는 768차원이고, 대형 모델은 1,536차원 또는 3,072차원까지 있습니다. 차원이 높을수록 의미를 더 세밀하게 표현할 수 있지만, 그만큼 저장 공간이 늘어나고 검색 속도가 느려집니다. 수백만 개의 문서를 다룰 때 384차원과 3,072차원의 속도 차이는 상당합니다. 실무에서는 정확도와 속도 사이에서 적절한 차원을 선택하는 게 중요한 이유입니다.

 

이 벡터 덕분에 시맨틱 서치(Semantic Search)가 가능해집니다. "과일 알레르기 정책"으로 검색해도 문서에 "과일"이라는 단어가 없더라도 "사과, 복숭아 관련 식품 안전 규정" 문서를 찾아낼 수 있습니다. 단어가 아니라 의미로 검색하는 것입니다.

3. 청킹, 문서를 적당한 크기로 나누는 작업

100페이지짜리 문서를 통째로 임베딩할 수는 없습니다. 임베딩 모델에는 처리 가능한 텍스트 길이 제한이 있고, 문서가 너무 길면 의미가 희석됩니다. 그래서 문서를 적당한 크기의 조각, 즉 청크로 나누는 작업이 필요합니다.

 

청킹 전략은 크게 두 가지입니다.

방식	장점	단점
길이 기반 청킹	구현이 쉽다	문장 중간 절단, 정보 손실 발생
의미 기반 청킹	의미 보존 가능	구현 어렵고 속도 느림

현실의 문서는 순수 텍스트만으로 이루어진 경우가 드뭅니다. 표가 있고 이미지가 있고 OCR로 스캔한 문서는 정렬이 깨지기도 합니다. 문서를 깔끔하게 텍스트로 변환하는 파서(Parser) 작업이 청킹 품질의 첫 번째 관문인 이유입니다. 업스테이지(Upstage)의 도큐먼트 파싱 모델이 현재 좋은 성능을 보여주고 있고, 비용이 부담된다면 오픈소스 대안도 있습니다.

 

"RAG가 워킹을 안 하는 대부분의 경우 원인은 단 하나입니다. 여러분의 청크가 정크(junk)라서입니다."

청크 자체의 품질이 나쁘면 아무리 좋은 임베딩 모델을 써도 검색이 안 됩니다. 이 한 문장이 RAG 성능 최적화의 핵심을 담고 있습니다.

4. 벡터 데이터베이스, 벡터를 저장하고 검색하는 저장소

청크를 임베딩해서 숫자 배열로 만들었다면 어딘가에 저장해야 합니다. 일반 데이터베이스는 "이름이 홍길동인 사람 찾아줘"처럼 정확한 조건으로 검색합니다. 벡터 데이터베이스는 다릅니다. "이 숫자 묶음이랑 가장 비슷한 숫자 묶음 찾아줘"라는 유사도 검색에 특화되어 있습니다.

 

마트 비유를 다시 가져오면, 일반 데이터베이스는 "3번 통로, 4번 선반, 1035번 상품 가져와"처럼 정확한 주소로 찾는 것이고, 벡터 데이터베이스는 "만두랑 비슷한 상품 뭐 있어?"라고 물었을 때 냉동 파전이나 냉동 교자를 추천해 주는 방식입니다.

구분	일반 데이터베이스	벡터 데이터베이스
검색 방식	정확한 조건 검색	유사도 기반 검색
검색 예시	이름이 홍길동인 사람 찾아줘	이 숫자 묶음과 가장 비슷한 것 찾아줘
적합한 데이터	정형 데이터	비정형 텍스트, 의미 기반 검색

5. 검색과 생성, RAG가 실제로 답변하는 방법

여기까지 정리하면 RAG 파이프라인의 전체 흐름이 보입니다.

1. 문서를 청크로 분할한다
2. 각 청크를 임베딩으로 벡터화한다
3. 벡터를 데이터베이스에 저장한다
4. 사용자가 질문하면 그 질문도 임베딩으로 변환한다
5. 벡터 데이터베이스에서 유사한 청크를 찾아온다
6. 검색된 청크를 LLM의 컨텍스트로 넘긴다
7. LLM이 그 청크를 참고해서 답변을 생성한다

자르고, 숫자로 바꾸고, 비슷한 숫자를 찾는다. 이 세 문장이 RAG의 본질입니다.

 

검색 품질을 높이는 고급 기법 3가지

기본 구조만으로 RAG를 돌리면 문제가 생깁니다. 검색 대상 문서가 수백, 수천 개로 늘어나는 순간 검색 품질이 급격히 떨어집니다. 3년간의 프로젝트 경험에서 반복해서 마주친 지점도 바로 이 부분입니다. 모델이 답변을 못 만드는 게 아니라, 엉뚱한 청크가 올라와서 엉뚱한 답변이 나오는 것입니다.

Dense 임베딩 vs Sparse 임베딩

지금까지 설명한 임베딩, 즉 텍스트를 숫자 배열로 바꿔서 의미 유사도로 검색하는 방식을 Dense 임베딩(밀집 임베딩)이라고 부릅니다. 수백에서 수천 차원의 숫자가 빽빽하게 채워져 있어서 "밀도가 높다"는 뜻입니다.

 

Sparse 임베딩(희소 임베딩)은 접근 방식이 다릅니다. BM25 같은 키워드 기반 검색이 대표적인데, 문서에서 특정 단어가 몇 번 등장하는지, 그 단어가 얼마나 희귀한지를 기반으로 점수를 매깁니다. 대부분의 차원이 0이고 특정 단어가 있는 자리만 숫자가 채워져 있어서 "희소하다"고 부릅니다.

 

쉽게 구분하면 이렇습니다. Dense 임베딩은 "이 문장이 무슨 뜻이야?"를 이해하는 검색이고, Sparse 임베딩은 "이 단어가 어디 있어?"를 찾는 검색입니다. 반도체 공정 문서에서 "CBD 챔버 온도 이상" 관련 내용을 찾는다고 해보겠습니다. Dense 임베딩은 온도 관련 공정 이슈라는 의미는 이해하지만, CBD라는 특수 공정 약어를 정확히 매칭하는 데는 약할 수 있습니다. Sparse 임베딩은 CBD라는 키워드가 정확히 들어간 문서를 바로 집어냅니다. 도메인 특수성이 강한 제조, 금융 업종에서는 오히려 의미 기반 시맨틱 검색보다 전문 용어의 정확한 매칭이 검색 기여도가 더 높은 경우가 꽤 많습니다.

하이브리드 서치, Dense와 Sparse를 함께 쓰는 방법

두 방식을 동시에 돌려서 양쪽 결과를 합쳐 최종 검색 결과를 만드는 것이 하이브리드 서치입니다. 의미도 잡고 키워드도 잡는 방식입니다. 실무에서는 두 검색의 가중치를 조절하는 것이 핵심입니다. 범용 문서라면 Dense 비중을 높이고, 전문 용어가 많은 도메인이라면 Sparse 비중을 높이는 식으로 튜닝합니다. 이 가중치 하나를 잘 잡는 것만으로도 검색 품질이 확 달라집니다.

리랭커, 검색 후보를 정밀하게 재평가하는 단계

하이브리드 서치로 1차 검색 품질을 올려도 후보군 안에 노이즈가 섞여 있을 수 있습니다. 리랭커는 1차로 가져온 후보 청크들을 다시 한번 정밀하게 점수 매겨 순서를 재배열합니다.

 

소개팅으로 비유해보겠습니다. 1차 검색은 소개팅 주선자가 나이, 지역, 직업을 기준으로 후보 10명을 추려주는 단계입니다. 프로필 사진과 기본 스펙만 본 것이죠. 리랭커는 그 10명을 실제로 만나보며 성격, 대화, 가치관까지 꼼꼼히 평가해서 진짜 잘 맞는 3명으로 압축하는 것입니다. 그래서 검색 정확도는 확실히 올라갑니다.

 

다만 속도가 느려진다는 단점이 있습니다. 상황에 따라 적용 방식을 달리해야 합니다. 개인 용도 RAG처럼 신뢰도가 중요하고 속도가 상대적으로 덜 중요한 상황이라면 리랭커 사용을 추천합니다. 반면 동시에 수백 명이 질문을 던지는 서비스라면 리랭커 때문에 응답이 몇 초씩 늦어질 수 있어 신중하게 고려해야 합니다.

 

Anthropic 공식 블로그 성능 데이터

• 컨텍스추얼 임베딩만 적용: 검색 실패율 35% 감소
• + BM25 결합: 49% 감소
• + 리랭킹까지 추가: 67% 감소

 

RAG 고급 기법, 컨텍스추얼 리트리벌과 레이트 청킹

컨텍스추얼 리트리벌, 청크에 맥락을 추가하는 기법

기본 RAG에는 큰 약점이 하나 있습니다. 청킹할 때 맥락이 잘려나간다는 것입니다. 재무보고서를 청킹했는데 어떤 청크에 "전 분기 대비 매출이 3% 성장했습니다"라는 문장이 들어있다고 해보겠습니다. 이 청크만 보면 어느 회사인지, 어느 시점인지 알 수가 없습니다. 원래 문서에는 "삼성전자의 2024년 2분기 실적"이라는 맥락이 앞에 있었는데, 청킹하면서 그게 잘려나간 것입니다.

 

Anthropic이 2024년 9월에 발표한 컨텍스추얼 리트리벌(Contextual Retrieval)이 이 문제를 정면으로 해결합니다. 각 청크를 임베딩하기 전에 LLM을 사용해서 그 청크가 전체 문서에서 어디에 위치하는지 설명하는 짧은 맥락 텍스트를 앞에 붙여주는 방식입니다. "이 청크는 삼성전자의 2024년 2분기 실적 보고서에서 발췌한 것으로 전 분기 매출은 N조 원이었습니다"처럼요. 이렇게 하면 "삼성전자 2분기 매출"이라는 질문에 이 청크가 정확히 매칭됩니다.

 

비용 문제가 있습니다. 각 청크마다 LLM을 한 번씩 호출해야 하기 때문에, 청크가 1만 개면 LLM 호출이 1만 번입니다. 실제 프로젝트에서 이 기법을 적용할 때 효과적인 방법이 있습니다. 모든 청크에 바로 적용하는 대신, 먼저 "이 청크가 의미 있는 정보를 담고 있는가"를 판별하는 로직을 앞단에 배치하는 것입니다. 목차만 있는 페이지나 빈 서식 같은 쓸모없는 청크를 걸러낸 후 실제 정보가 담긴 청크에만 적용하면 비용이 상당히 절감됩니다.

레이트 청킹, 문서 전체를 먼저 임베딩하고 나중에 분할

컨텍스추얼 리트리벌이 청크의 맥락을 붙여주는 방식이라면, 레이트 청킹(Late Chunking)은 아예 순서를 뒤집는 방식입니다. 보통 RAG는 문서를 먼저 청크로 자르고 각 청크를 따로따로 임베딩합니다. 이러면 각 청크가 독립적으로 처리되니까 앞뒤 맥락을 모릅니다.

 

레이트 청킹은 문서 전체를 먼저 긴 컨텍스트 임베딩 모델에 넣어서 전체 맥락이 반영된 임베딩을 만든 후에 청크로 자릅니다. 영화 비유를 들면 이렇습니다. 일반 청킹은 영화를 장면별로 잘라서 각 장면의 줄거리를 따로따로 요약하는 것입니다. 앞뒤 장면을 모르니 "그가 울었다"에서 그가 누군지 알 수가 없습니다. 레이트 청킹은 영화를 처음부터 끝까지 한번 다 본 다음에 장면별로 요약하는 것입니다. 전체 스토리를 알고 있으니 각 장면의 맥락이 자연스럽게 반영됩니다.

 

긴 문서를 한 번에 처리해야 하니 연산 비용이 더 들지만, 한번 잘 구축해 두면 검색 품질이 안정됩니다. 초기 투자 비용은 있지만 이후 운영이 수월해지는 구조입니다.

 

RAG는 정말 죽었을까?

링크드인이나 X 타임라인에서 "RAG is Dead"라는 문장을 한 번쯤 보셨을 겁니다. 이 논쟁의 맥락을 정확히 짚어보겠습니다.

"RAG is Dead" 논쟁의 배경

Claude Code를 만든 Anthropic의 Boris Cherny가 Latent Space 팟캐스트와 해커 뉴스에서 이런 이야기를 했습니다. 초기 Claude Code에 RAG를 적용해 봤는데, 에이전틱 서치, 즉 grep이나 glob 같은 터미널 도구로 직접 탐색하는 방식이 압도적으로 성능이 좋았다는 것입니다. 코드베이스를 인덱싱해서 벡터 검색을 쓰는 대신, 모델이 직접 파일 구조를 탐색하면서 필요한 코드를 찾아가는 방식이 정확성, 보안, 신선도 측면에서 더 낫다는 판단이었습니다. 이 이야기가 퍼지면서 RAG 자체가 죽었다는 식으로 확대 해석된 것입니다.

코드 vs 비정형 문서, 결정적인 차이

여기서 맥락을 정확하게 짚어야 합니다. 코드는 구조화된 데이터입니다. 함수명, 변수명, 파일 경로 같은 정확한 매칭이 의미 기반 검색보다 중요한 영역이죠. grep으로 정확한 문자열을 찾는 것이 임베딩으로 비슷한 코드를 찾는 것보다 효과적인 건 당연한 결과입니다.

 

그런데 여러분이 다루는 데이터가 코드인가요? 대부분은 아닐 것입니다. 고객 문의, 사내 위키, 계약서, 의료 기록, 마케팅 리포트 같은 비정형 텍스트 데이터에서 "이 계약서에서 손해 배상 관련 조항 찾아줘"라고 했을 때 grep으로는 답이 나오지 않습니다. "손해 배상"이라는 정확한 단어가 아니라 "배상 책임, 면책 사유, 위약금" 같은 의미적으로 연결된 내용을 찾아야 하기 때문입니다. 이건 시맨틱 서치, 즉 RAG의 영역입니다.

전문가들이 말하는 RAG의 현재

RAG 논문 원저자이자 Context AI CEO 나오키 켈라는 이렇게 말했습니다. 컨텍스트 윈도우가 아무리 커져도 기업의 지식 베이스는 테라바이트 단위이고, 모든 것을 컨텍스트에 넣는 건 비용과 성능 면에서 비현실적이라는 것입니다. 실제로 RAG가 롱 컨텍스트 접근 대비 비용이 8배에서 82배까지 저렴하다는 연구 결과도 있습니다.

 

Chroma CEO Jeff Huber는 Latent Space 팟캐스트에서 비슷한 맥락의 이야기를 했습니다. RAG라는 용어 자체가 세 가지 개념을 하나로 묶어놔서 혼란을 준다는 것입니다. 본질은 검색이고, 검색이 죽을 일은 없습니다. 단지 검색 방식이 더 정교해지고 에이전트 안에 녹아들어가는 방향으로 진화하고 있을 뿐입니다. The New Stack의 2026년 1월 기사에서도 "RAG가 죽은 게 아니라 컨텍스트 엔지니어링이라는 이름으로 리브랜딩된 것"이라고 정리했습니다.

 

"죽은 건 RAG가 아니라 RAG를 단순하게 쓰던 시절입니다."

코딩 에이전트처럼 구조화된 데이터를 다루는 영역에서는 에이전틱 서치가 RAG를 대체할 수 있습니다. 하지만 비정형 문서 기반의 대부분 산업 케이스에서 RAG는 여전히 대체 불가능한 핵심 인프라입니다. 지금 RAG를 제대로 익혀두면 단순 벡터 검색을 넘어 검색 아키텍처를 설계하는 눈이 생깁니다. 이 눈이 있으면 상황에 따라 시맨틱 서치, 키워드 검색, 에이전틱 서치 중 어떤 것이 맞는지 판단할 수 있게 됩니다.

 

마무리, RAG 핵심 용어 한눈에 정리

지금까지 다룬 개념들이 머릿속에서 하나의 파이프라인으로 연결되었다면 이 글의 목적은 달성된 것입니다. 아래 표로 핵심 용어들을 다시 한번 정리합니다.

용어	개념
RAG	검색으로 LLM 답변 품질을 높이는 구조 (오픈북 시험 비유)
임베딩	텍스트를 의미 기반 숫자 배열로 변환하는 과정
벡터	임베딩 결과인 숫자 배열
청킹	문서를 적당한 크기로 분할 (길이 기반 / 의미 기반)
벡터 데이터베이스	벡터를 저장하고 유사도 검색하는 저장소
Dense 임베딩	의미 기반 시맨틱 검색
Sparse 임베딩	키워드 기반 검색 (BM25 등)
하이브리드 서치	Dense + Sparse 결합 검색
리랭커	검색 후보군을 정밀 재평가하여 재정렬
컨텍스추얼 리트리벌	청크에 맥락 정보를 추가하는 기법 (Anthropic 발표)
레이트 청킹	전체 문서 임베딩 후 나중에 청크로 분할하는 기법

 

3년 경험에서 나온 핵심 인사이트

• 대부분의 RAG 문제는 Generation이 아니라 Retrieval에서 발생한다
• 청크 품질이 나쁘면 아무리 좋은 임베딩 모델을 써도 소용없다
• 프로덕션 수준에는 하이브리드 서치 + 리랭킹 + 메타데이터 필터링 조합이 필요하다

처음에는 단순 벡터 검색만으로도 동작하지만, 문서가 늘어나고 요구 수준이 높아지면 자연스럽게 고급 기법이 필요해집니다. 죽은 것이 아니라 진화하고 있는 것입니다. RAG 개념이 처음이셨다면 이 글을 바탕으로 각 단계를 직접 구현해보시는 것을 권합니다. 직접 청크를 들여다보고 "이 청크가 왜 3위에 올라와 있지?"라는 감이 잡히기 시작하는 순간이 RAG를 정말 이해하게 되는 시점입니다.