'우리 회사 문서를 다 아는 AI 챗봇을 만들고 싶어요'라는 요구의 표준 답안이 바로 RAG입니다. 그리고 RAG를 이해하려면 먼저 임베딩(embedding)이라는 개념이 필요합니다. 둘 다 이름만 어렵지, 비유로 보면 간단합니다.
임베딩: 의미를 좌표로 바꾸기
임베딩은 텍스트를 수백~수천 개의 숫자 목록(벡터)으로 변환하는 기술입니다. 핵심은 '의미가 비슷한 텍스트는 가까운 좌표를 갖는다'는 점입니다. 지도에 비유하면, '강아지'와 '반려견'은 바로 옆 동네에 찍히고, '냉장고'는 멀리 떨어진 도시에 찍히는 의미의 지도인 셈입니다.
이것이 왜 강력할까요? 기존 키워드 검색은 '환불'로 검색하면 '환불'이라는 글자가 들어간 문서만 찾습니다. 하지만 임베딩 기반 의미 검색은 '돈 돌려받고 싶어요'라고 검색해도 환불 규정 문서를 찾아냅니다. 표현이 달라도 의미가 가까우면 좌표가 가깝기 때문입니다.
벡터DB는 뭔가요?
벡터 데이터베이스(vector database)는 이 좌표들을 대량으로 저장하고, '이 좌표에서 가장 가까운 문서 5개를 찾아줘' 같은 검색을 빠르게 처리하는 전용 창고입니다. Pinecone, Chroma 같은 전문 제품도 있고, 기존 데이터베이스에 벡터 기능을 얹은 것(PostgreSQL의 pgvector 등)도 널리 쓰입니다.
RAG: AI에게 오픈북 시험 보게 하기
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이름 그대로 '검색으로 보강한 답변 생성'입니다. 비유하자면, 암기한 내용만으로 시험을 보던 AI(클로즈드북)에게 교과서를 찾아볼 수 있게 해주는 것(오픈북)입니다. 답하기 전에 관련 자료를 먼저 찾아서 건네주면, 3강에서 배운 할루시네이션이 크게 줄고 최신·사내 정보에도 답할 수 있게 됩니다.
RAG가 동작하는 4단계
- 준비: 사내 문서를 적당한 크기의 조각(청크)으로 나누고, 각 조각을 임베딩해 벡터DB에 저장합니다. (책의 페이지마다 좌표 태그를 붙여 서가에 꽂는 과정)
- 검색: 사용자가 질문하면 질문도 임베딩한 뒤, 벡터DB에서 좌표가 가장 가까운 조각들을 찾습니다. (질문과 의미가 통하는 페이지를 뽑아오기)
- 증강: 찾은 조각들을 '이 자료를 참고해서 답하세요'라는 지시와 함께 질문 앞에 붙입니다. (시험지 옆에 참고 자료를 펼쳐두기)
- 생성: LLM이 그 자료에 근거해 답변하고, 어느 문서를 참고했는지 출처도 달 수 있습니다.
왜 그냥 다 붙여넣지 않고 RAG를 쓸까요?
- 용량: 회사 문서 전체는 수백만~수억 토큰이라 컨텍스트 윈도우(2강)에 다 들어가지 않습니다.
- 비용: 매 질문마다 문서 전체를 읽히면 토큰 비용이 폭발합니다. 관련 조각만 넣으면 수백 분의 일로 줄어듭니다.
- 정확도: 관련 없는 내용이 잔뜩 섞이면 오히려 답변 품질이 떨어집니다. 필요한 것만 골라 주는 편이 낫습니다.
- 최신성: 문서가 바뀌면 벡터DB만 갱신하면 됩니다. 모델을 다시 학습시킬 필요가 없습니다.
사실 여러분은 이미 RAG를 쓰고 계실 가능성이 높습니다. 챗 서비스의 웹 검색 모드, PDF 업로드 후 질문하기, ChatGPT의 GPTs나 Claude 프로젝트에 문서를 올려두는 기능이 모두 RAG 계열 기술입니다. NotebookLM처럼 아예 RAG를 전면에 내세운 서비스도 있습니다.
RAG 챗봇의 품질은 LLM보다 '검색이 좋은 조각을 찾아왔는가'에서 갈리는 경우가 많습니다. 답변이 이상하면 모델 탓을 하기 전에, 원본 문서가 잘 정리되어 있는지(최신인지, 중복이 없는지, 제목이 명확한지)부터 점검해 보세요. 쓰레기가 들어가면 쓰레기가 나옵니다.
RAG도 만능은 아닙니다. 찾아온 자료가 틀렸거나 오래됐으면 답도 틀립니다. 또 '문서 전체를 요약해줘'처럼 전체를 봐야 하는 작업에는 조각 검색 방식인 RAG가 약합니다. 이런 경우는 문서를 통째로 컨텍스트에 넣는 편이 낫습니다.