RAG 기초 — LLM의 한계를 극복하는 가장 현실적인 방법

들어가며

LLM이 세상을 바꿀 거라고들 하지만, 전 직장에서 데이터 엔지니어로 일하며 느낀 현실은 조금 달랐습니다.

회사 안에는 데이터 파트와 일반 사업부 팀 사이에 보이지 않는 거대한 벽, 이른바 '데이터 사일로(Data Silo)' 현상이 굳건하게 자리 잡고 있었습니다. 사업부 분들은 항상 데이터를 필요로 하지만 직접 접근하기 어려워했고, 데이터 팀은 쏟아지는 요청을 처리하느라 병목이 생기곤 했죠.

챗GPT 같은 뛰어난 AI가 등장했을 때 내심 기대했지만, 현실적인 한계는 명확했습니다. LLM은 엄청나게 똑똑하고 문장력도 뛰어나지만, 정작 가장 중요한 '우리 회사의 내부 데이터'나 '최신 비즈니스 현황'은 전혀 모른다는 것입니다. 사내 데이터에 접근할 수 없으니, 결국 실무자들이 원하는 진짜 팩트 기반의 답변을 내놓지 못하고 그럴듯한 거짓말(할루시네이션)을 하곤 했습니다. 모델 혼자서는 아무리 똑똑해도 사내의 닫힌 문을 열어주진 못했던 거죠.

그러다 RAG(Retrieval-Augmented Generation, 검색 증강 생성)라는 아키텍처를 접하게 되었습니다.

AI가 단순히 자기가 아는 선에서 대답을 지어내는 게 아니라, 사내 데이터베이스나 문서에서 진짜 정보를 찾아서 그 팩트를 기반으로 답변을 만들어준다는 개념. 어쩌면 이 기술이 길고 길었던 부서 간의 데이터 사일로를 허물고, 비개발 직군도 쉽게 데이터에 접근하는 '데이터 민주화'를 앞당길 열쇠가 될 수 있겠다는 강렬한 호기심이 생겼습니다.

그래서 도대체 이 RAG가 무엇이고 어떻게 동작하는 건지, 제가 직접 프로젝트에 적용해 보기 위해 공부하며 이해한 기초적인 내용들을 차근차근 정리해 보려 합니다.

 

1. LLM의 한계를 뛰어넘는 두 갈래 길: Fine-tuning vs RAG

이러한 한계를 극복하기 위해 주로 두 가지 접근법이 사용됩니다. 바로 Fine-tuning(미세 조정)과 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다.

• Fine-tuning: 사전 학습된 모델에 특정 도메인(의료, 법률, 사내 데이터 등)의 데이터를 추가로 학습시키는 방식입니다.
• RAG: 외부 지식 소스(데이터베이스, 웹 문서 등)와 연계하여, 질문이 들어올 때마다 관련 정보를 검색한 뒤 이를 바탕으로 답변을 생성하는 방식입니다.

이 둘의 차이를 쉽게 비유하자면 다음과 같습니다. Fine-tuning은 언어 모델이 특정 분야의 지식을 밤낮으로 '공부하고 암기'하여 전문가로 성장하는 것입니다. 지식은 깊어지지만, 공부하는 데 막대한 시간과 비용이 들고 새로운 지식이 나올 때마다 다시 공부해야 합니다.

반면 RAG는 언어 모델과 '유능한 도서관 사서'가 협업하는 것과 같습니다. 사용자가 질문을 하면, 사서(검색기)가 도서관의 수많은 책 중에서 관련 정보가 담긴 책을 빠르게 찾아냅니다. 그리고 언어 모델은 그 책(출처)을 펴놓고 오픈북 테스트를 보듯 질문에 답변합니다.

이러한 구조 덕분에 RAG는 Fine-tuning 대비 강력한 장점을 가집니다.

1. 비용과 시간 절감: 별도의 모델 추가 학습이 필요 없습니다.
2. 답변의 근거 제시: "이 문서를 참고해서 답변했습니다"라며 정보 출처를 명확히 제공해 신뢰도를 높입니다.
3. 할루시네이션 억제: 모델의 기억력(파라미터)에 의존하지 않고, 주어지는 외부 데이터를 기반으로 답변을 생성하므로 오류를 대폭 줄일 수 있습니다.

 

2. RAG의 작동 방식: 검색(Retrieval), 증강(Augmentation), 생성(Generation)

도서관 비유를 조금 더 기술적인 관점으로 끌고 와, RAG의 세 가지 핵심 단계를 살펴보겠습니다.

 

1단계: 데이터 임베딩 및 벡터 DB 구축 (수많은 책을 보관한 도서관)

가장 먼저 자체 보유한 텍스트 데이터(문서, DB 스키마 등)를 잘게 쪼개어 임베딩 모델을 통해 수학적인 벡터 형식으로 변환합니다. 변환된 정보는 벡터 데이터베이스(Vector DB)에 저장됩니다.

• 이 과정은 사서가 방대한 양의 책을 주제와 내용에 따라 꼼꼼하게 분류표를 붙여 도서관 서고에 정리해 두는 것과 같습니다.

2단계: 쿼리 벡터화 및 정보 검색 (사용자에게 딱 맞는 책 추천)

사용자가 질문(쿼리)을 입력하면, 이 질문 역시 동일한 임베딩 모델을 거쳐 벡터로 변환됩니다. 그리고 벡터 DB에서 사용자의 질문 벡터와 가장 '의미가 비슷한' 상위 K개의 문서를 추출합니다. (Retrieval)

• 도서관에 온 사용자가 질문을 던지면, 사서가 질문의 의도를 파악하고 가장 관련성이 높은 책의 요약본을 서고에서 뽑아오는 단계입니다.

3단계: LLM을 통한 답변 생성 (사용자를 위한 지식 활용)

추출된 관련 정보(컨텍스트)는 사용자의 원래 질문과 함께(Augmentation) LLM에 전달됩니다. LLM은 오직 전달받은 정보를 근거로 삼아 최종 답변을 작성합니다. (Generation)

• 사서가 찾아준 책을 바탕으로, 언어 모델이 글솜씨를 발휘해 사용자가 이해하기 쉽게 새로운 지식으로 엮어내어 설명해 주는 것과 같습니다.

3. 사서는 어떻게 '의도'를 파악할까? (임베딩과 벡터 검색)

그렇다면 2단계에서 시스템(사서)은 어떻게 텍스트의 연관성을 찾아낼까요? 일반적인 RDBMS의 검색(LIKE 검색)은 "사과"라고 치면 "애플"을 찾지 못합니다. 글자가 다르기 때문입니다.

하지만 임베딩은 텍스트를 '의미가 보존된 고정 길이의 벡터 공간'으로 맵핑합니다. 임베딩 공간 안에서는 "캐릭터 장비 정보"와 "착용 중인 무기 아이템"이라는 문장이 글자는 전혀 다르더라도 아주 가까운 거리에 위치하게 됩니다.

이 두 벡터가 얼마나 가까운지를 계산하는 표준 수학 공식이 바로 코사인 유사도(Cosine Similarity)입니다.

문장 A	문장 B	의미 공간에서의 거리
"캐릭터 장비 정보"	"프로필에서 착용 중인 무기·방어구"	가깝다 (유사도 높음)
"캐릭터 장비 정보"	"오늘 점심 메뉴 추천"	멀다 (유사도 낮음)

 

수십만 건의 데이터 속에서 이 유사도를 일일이 계산하면 속도가 너무 느려지기 때문에, 상용 벡터 DB들은 ANN(Approximate Nearest Neighbor) 인덱스(예: HNSW, IVFFlat)를 사용하여 약간의 오차를 허용하는 대신 수십~수백 배 빠른 검색 속도를 보장합니다.

 

정리하며

RAG는 단순히 LLM에 검색 기능을 붙인 것이 아닙니다. 검색(Retrieval)으로 최신 정보를 찾고, 그 정보로 프롬프트를 증강(Augmentation)하여, 근거 기반의 답변을 생성(Generation)하는, 현재 AI 산업에서 가장 현실적이고 효율적인 아키텍처입니다.

RAG는 범용 LLM의 똑똑한 추론 능력은 그대로 살리면서, 기업의 보안 데이터나 최신 정보를 유연하게 엮어낼 수 있는 무한한 잠재력을 가지고 있습니다.

다음 포스팅에서는 이 RAG 기술을 단순한 '텍스트 문서 검색'이 아닌, 게임 챗봇의 'Text-to-SQL 스키마 검색'에 어떻게 적용했는지, 그리고 pgvector를 도입하여 Cold Start 지연 문제를 어떻게 0초로 단축했는지 실제 프로젝트 트러블슈팅 사례를 통해 자세히 다뤄보겠습니다.