쉬운 설명
LLM은 학습 시점까지의 일반 지식만 알고, 우리 회사 내부 자료나 최근 사실은 모릅니다. RAG는 이 격차를 메우는 가장 표준적인 방법입니다. 사용자의 질문이 들어오면 우리 자료 중 관련된 조각을 골라 모델에 함께 주고, 모델은 그 조각을 보면서 답을 만듭니다.
RAG가 등장한 이유는 단순합니다. ① 회사 내부 문서를 모델에 학습시키는(파인튜닝) 일은 비싸고 위험하다. ② 자료가 자주 바뀌면 모델을 매번 다시 학습시킬 수도 없다. ③ 답에 '어디서 가져왔는지' 출처를 보여 주고 싶다. RAG는 이 세 가지를 한 번에 해결합니다.
흐름은 보통 다섯 단계입니다. ① 자료를 작은 조각(chunk)으로 잘라 임베딩(벡터)으로 바꾸고 벡터 DB에 저장. ② 사용자의 질문도 같은 모델로 임베딩. ③ 벡터 DB에서 질문 벡터와 가장 가까운 자료 조각 5~20개를 검색. ④ 검색된 조각들을 시스템 프롬프트와 함께 LLM에 넣어 줌. ⑤ 모델이 그 조각을 보고 답을 생성하며, 보통 출처도 함께 표시합니다.
RAG의 강점은 신선함과 출처입니다. 자료를 갱신하면 그 변화가 즉시 답에 반영되고, 답 옆에 '이 답은 ___ 문서 ___ 페이지에서 나왔다'를 보여 줄 수 있어 신뢰가 올라갑니다. 모델을 손대지 않아도 되니 도입 비용이 낮고, 데이터가 외부로 학습되지 않아 정보 통제도 쉽습니다.
잘 만드는 일은 의외로 까다롭습니다. ① 자료를 어떻게 자르느냐(chunk 크기·중첩)에 따라 검색 품질이 크게 갈립니다. ② 임베딩 모델·검색 알고리즘 선택. ③ 검색된 조각 중 일부는 무관할 수 있어, 재정렬(re-ranking)·필터를 더하는 일이 흔합니다. ④ 답을 만들 때 모델이 자료를 무시하지 않도록 프롬프트를 단단히 설계해야 합니다. 'RAG는 쉽게 시작하지만 끝까지 다듬으면 깊다'가 실무의 통념입니다.
비유로 보면
RAG는 시험을 보는 학생이 책장에서 필요한 책을 찾아 펴 놓고 답을 쓰는 모습과 비슷합니다. 학생은 일반 지식은 머리에서 끌어오고, 구체적인 사실은 책을 보면서 옮겨 적습니다. 책장이 잘 정리돼 있을수록, 그리고 어느 책을 펴야 할지 빠르게 찾을수록 답이 좋아집니다.
어디에서 만나나
사내 정책 챗봇, 고객지원 도우미(자사 매뉴얼 기반 응대), 학술·법률·의료 자료 검색 보조, 코딩 도우미가 라이브러리 문서를 참고하는 형태, 뉴스 기반 질의응답 — 'LLM에 자기 자료를 붙이고 싶다'는 거의 모든 상황에서 RAG가 첫 번째 선택지입니다.
작은 예시
사내 정책 챗봇을 만들 때, 회사의 위키·정책 PDF 수천 페이지를 잘게 잘라 임베딩해 벡터 DB에 저장합니다. 직원이 '연차 이월 규정이 어떻게 돼?' 하고 물으면 벡터 DB가 의미가 가까운 정책 조각을 찾아 주고, LLM이 그 조각을 보며 답을 만들고, 답 아래에 출처 문서명·페이지를 함께 보여 줍니다.
자주 하는 오해
한 줄 정리
RAG는 LLM을 회사 자료에 연결하는 가장 표준적이고 안전한 방법입니다. 검색을 잘하는 것이 모델보다 결과에 더 큰 영향을 줍니다.