RAG 입문 총정리 — 검색증강생성, 임베딩·벡터DB·청킹과 프로덕션 운영

핵심 메시지

• RAG(검색 증강 생성)는 LLM이 모르는 사적·최신 정보를 실시간으로 찾아(검색) 프롬프트에 더해(증강) 더 정확한 답을 생성하는 기법이다.
• 규칙·제한은 프롬프트 엔지니어링, 말투·문체는 파인튜닝, 자주 바뀌는 사실 정보는 RAG로 해결하는 것이 적합하다.
• 정확한 단어를 찾는 키워드 검색(TF-IDF, BM25)의 한계를, 의미로 찾는 시맨틱 검색이 임베딩 벡터로 보완한다.
• 문서를 벡터로 바꿔 벡터DB(Chroma, Pinecone 등)에 HNSW 같은 색인으로 저장하고, 큰 문서는 청킹으로 잘게 나눠 정밀하게 검색한다.
• 실제 운영에서는 캐싱(속도), 모니터링(상태 파악), 우아한 장애 대응(폴백)이 RAG 시스템을 빠르고 안정적으로 유지한다.

쉽게 이해하기

강의는 사전 지식 없이도 이해할 수 있게 RAG를 시각적으로 설명합니다. 가장 단순한 예로, 회사 내부 정책을 챗GPT에 물으면 그 문서를 모르기 때문에 일반적이거나 틀린 답(환각)을 내놓습니다. 그래서 사용자가 직접 정책 문서에서 관련 부분을 찾아 프롬프트에 붙여주면 정확한 답이 나오는데, 바로 이것이 RAG의 본질입니다. 관련 정보를 찾는 것이 검색(Retrieval), 그것으로 프롬프트를 보강하는 것이 증강(Augmentation), LLM이 답을 만드는 것이 생성(Generation)입니다. 실제 RAG 시스템은 이 과정을 사용자 대신 자동으로 수행합니다.

RAG가 만능은 아니라는 점도 분명히 합니다. 더 나은 답을 얻는 방법에는 프롬프트 엔지니어링, 파인튜닝, RAG가 있고 상황에 맞게 골라야 합니다. 사내 "정책 코파일럿" 사례에서, 민감 주제를 HR로 돌리는 등의 규칙·제한은 프롬프트 엔지니어링으로, 특정 CEO의 말투·문체를 흉내내는 것은 과거 연설·글로 모델을 파인튜닝해 해결합니다. 반면 자주 바뀌는 정책 같은 사실 정보는, 매번 재학습이 비싸고 느리며 출처를 댈 수 없는 파인튜닝 대신, 질의 시점에 정보를 동적으로 가져오는 RAG가 최선입니다.

검색의 기초로 두 방식이 비교됩니다. 키워드 검색은 정확히 일치하는 단어를 찾아 빈도로 순위를 매기는 방식으로, TF-IDF와 BM25가 대표적이며 scikit-learn, rank_bm25 같은 라이브러리로 구현합니다. 하지만 "reimbursement" 대신 "allowance", "home office" 대신 "work from home"처럼 다른 단어를 쓰면 못 찾는 한계가 있습니다. 이를 의미 기반으로 찾는 것이 시맨틱 검색이며, 텍스트를 의미를 담은 벡터(임베딩)로 바꿔 의미가 비슷한 문서끼리 가깝게 배치해 검색합니다.

임베딩 모델로는 sentence-transformers의 all-MiniLM-L6-v2가 소개됩니다. 문장을 384차원 벡터로 매핑하는 2,200만 파라미터·약 90MB 모델로, 로컬에서 무료로 돌릴 수 있어 임베딩 용도에 적합합니다(텍스트 생성·추론용인 GPT 계열과 용도가 다름). 벡터 간 유사도는 내적(dot product)으로 0~1 사이 점수로 계산합니다. 문서가 수백·수천 개로 늘면 매번 전부 비교하기 어렵기에, HNSW·IVF·LSH 같은 색인으로 벡터를 미리 "이웃"으로 묶어두는 벡터DB가 필요합니다. 학습엔 오픈소스 Chroma, 프로덕션엔 관리형 Pinecone 등이 권장됩니다.

큰 문서를 그대로 넣으면 질문에 50페이지 핸드북 전체가 반환되는 정밀도 문제가 생기므로, 청킹으로 문서를 잘게 나눕니다. 고정 크기(200~500자) 청크에 50~100자 겹침(overlap)을 둬 문장이 중간에 잘려도 맥락이 보존되게 하며, 문장·문단 단위 청킹도 있습니다. 너무 작으면 맥락을 잃고 너무 크면 정밀도가 떨어지므로 균형이 중요합니다. 마지막으로 RAG 파이프라인(사전에 청킹·임베딩·벡터DB 적재 → 질의 시 검색·증강·생성)을 정리하고, 프로덕션 운영을 위한 캐싱(Redis, 쿼리·임베딩·검색·LLM 응답 캐시와 TTL), 모니터링(응답시간·처리량·오류율, Prometheus·Grafana 등), 그리고 단계적 폴백으로 우아하게 실패하는 장애 처리까지 다룹니다.

주요 인사이트

• RAG의 본질은 단순하다 — LLM이 모르는 정보를 질의 시점에 찾아 프롬프트에 붙여주는 것이며, 우리가 정책 문서를 복사해 붙여넣던 행동을 자동화한 것이다.
• 파인튜닝은 말투·문체처럼 안 바뀌는 패턴엔 좋지만, 자주 바뀌고 출처가 필요한 사실 정보엔 재학습 비용·지식 단절 때문에 부적합하다.
• 키워드 검색은 단어가 정확히 일치해야 찾지만, 시맨틱 검색은 임베딩으로 의미가 비슷한 문서를 찾아 "allowance"로 "reimbursement"를 찾아낸다.
• 임베딩 모델은 작고(2,200만 파라미터, 약 90MB) 로컬에서 무료로 돌릴 수 있어, 거대한 텍스트 생성 모델과 역할이 분명히 다르다.
• 청크 크기는 정밀도와 맥락의 절충이며, 겹침(overlap)을 두면 문장이 경계에서 잘려도 중요한 맥락이 양쪽 청크에 남아 검색 품질이 유지된다.

자주 묻는 질문

관련 AI 소식