RAG(검색 증강 생성)란? 원리부터 실무까지, 환각을 줄이는 검색 결합 기법

RAG(검색 증강 생성, Retrieval-Augmented Generation)는 대규모 언어 모델(LLM, 방대한 글을 읽고 다음에 올 말을 이어 쓰도록 학습한 AI)이 답을 생성하기 전에 외부 지식 저장소에서 관련 문서를 먼저 검색하고, 그 문서를 근거로 삼아 답을 짓게 만드는 기법입니다. 이름 그대로 '검색(retrieval)'으로 '생성(generation)'을 '증강(augmented)'합니다. 모델 혼자 기억을 더듬어 답하는 대신, 시험 중에 교재를 펴 놓고 답을 쓰는 오픈북 시험과 같습니다.

한눈에 보기

• RAG는 AI가 답하기 전에 회사 문서 같은 자료를 먼저 찾아 읽고, 그 내용을 근거로 답하게 하는 방법입니다.
• 모델을 다시 학습시키지 않고 문서만 바꾸면 최신 정보로 답하고, 어느 문서를 보고 답했는지 출처도 보여 줄 수 있습니다.
• 다만 엉뚱한 문서를 찾아오면 틀린 답을 그럴듯하게 내므로, 문서 정리와 검색 품질 관리가 성패를 가릅니다.

규정집을 먼저 펼쳐 보는 AI

이런 상황을 떠올려 보세요. 작은 온라인 쇼핑몰을 운영하는데, 고객이 "지난주에 산 신발, 한 번 신었는데 반품되나요?"라고 묻습니다. ChatGPT에 그대로 물으면 흔한 쇼핑몰 규정을 짐작해 "보통 7일 안에는 가능합니다"라고 자신 있게 답합니다. 그런데 우리 가게 규정은 "착용한 상품은 반품 불가"일 수 있습니다. AI는 우리 가게 반품 규정을 읽은 적이 없으니 모를 수밖에 없습니다. 사람 직원이라면 규정집을 펼쳐 해당 조항을 찾아보고 답할 것입니다. RAG는 AI에게 바로 이 '규정집을 먼저 펼쳐 보는 습관'을 붙여 주는 방법입니다.

여기서 핵심은 부품이 둘로 나뉜다는 점입니다. 하나는 질문과 연관된 문서 조각을 찾아오는 검색기(retriever), 다른 하나는 찾아온 조각을 읽고 자연스러운 문장으로 답을 짓는 생성기(generator), 즉 LLM입니다. ChatGPT 안에서 답을 쓰는 엔진이 여기에 해당합니다. 이 둘을 파이프라인(앞 단계의 결과가 다음 단계로 넘어가는 작업 줄)으로 잇는 구조가 RAG입니다.

이 이름은 2020년 5월 페이스북 AI 연구진의 루이스(Patrick Lewis) 등이 공개한 논문에서 자리를 잡았습니다. 이 논문은 검색을 붙인 모델이 기억만 쓰는 모델보다 "더 구체적이고 사실에 맞는" 문장을 만든다고 보고했습니다. 그 뒤로 RAG는 사내 문서 검색, 고객 응대 챗봇, 법률·의료 문서 질의응답 같은 지식 집약적 과제에서 사실상 표준에 가까운 설계가 됐습니다. LLM을 실제 업무에 붙일 때 가장 먼저 검토하는 구조라고 봐도 무리가 없습니다.

왜 모델 혼자로는 부족한가: 환각과 지식의 유통기한

LLM은 다음에 올 단어를 확률 분포에서 골라 문장을 잇는 기계입니다. 방대한 글로 학습하면서 세상의 지식을 파라미터(가중치, 학습 결과가 담긴 수많은 숫자) 안에 녹여 넣었지만, 그 지식은 '통계적으로 어울리는 조각'으로 압축돼 있을 뿐 사실을 대조하는 창구가 아닙니다. 그래서 그 자리에 올 법한 그럴듯한 내용을 지어내는 환각(hallucination)이 원리적으로 새어 나옵니다. 없는 논문을 제목과 저자까지 붙여 만들어 내거나, 일어난 적 없는 사건을 날짜까지 확신에 차 답하는 장면이 대표적입니다. 환각이 왜 생기고 어떻게 줄이는지는 AI 환각 글에서 따로 다뤘습니다.

문제는 이것이 코드를 잘못 짜서 생긴 버그가 아니라, 확률로 문장을 짓는 방식에 딸린 부작용이라는 데 있습니다. 완전히 없앨 수 없다면 관리해야 합니다. 관리의 한 축이 바로 모델 바깥의 신뢰할 수 있는 지식을 연결해 주는 일입니다. 답의 근거를 모델의 흐릿한 기억이 아니라 검증된 문서에 두면, 지어낼 여지가 줄어듭니다.

또 하나의 한계는 지식의 유통기한입니다. 학습을 마친 시점 이후의 사건은 모델이 알 수 없습니다. 오늘 갱신된 사내 정책, 어제 나온 제품 사양, 방금 바뀐 가격표는 파라미터 안에 들어 있지 않습니다. 모델을 다시 학습시켜 최신 지식을 심으려면 막대한 비용과 시간이 듭니다. RAG는 이 문제를 돌아갑니다. 지식을 모델 바깥의 문서 저장소에 두고 문서만 갈아 끼우면, 모델은 그대로 두고도 최신 정보로 답할 수 있습니다.

검색으로 근거를 찾아 답에 붙이는 전체 흐름

RAG는 크게 두 단계로 움직입니다. 미리 준비해 두는 색인(indexing) 단계와, 질문이 들어올 때마다 도는 질의(query) 단계입니다. 색인은 책 뒤의 '찾아보기'를 만들어 두는 일과 비슷합니다. 색인 단계에서는 답의 재료가 될 문서를 잘게 쪼개고, 각 조각을 숫자 벡터(뜻을 숫자 목록으로 적은 좌표)로 바꿔 저장소에 넣어 둡니다. 이 작업은 한 번 해 두면 되고, 문서가 바뀔 때만 갱신합니다.

질의 단계는 실제 대화가 오갈 때 벌어집니다. 사용자의 질문이 들어오면 그 질문도 똑같이 벡터로 바꿉니다. 그다음 저장소에서 질문 벡터와 가장 가까운 문서 조각 몇 개를 찾아옵니다. 여기까지가 검색기의 일입니다. 찾아온 조각들을 원래 질문과 함께 하나의 프롬프트(AI에게 주는 지시문과 자료 묶음)로 엮어 LLM에 건넵니다. 이때 프롬프트는 대략 '아래 자료를 참고해 질문에 답하라'는 지시와 검색된 문서 본문, 그리고 사용자 질문으로 꾸립니다.

마지막으로 LLM은 건네받은 문서를 읽고 답을 짓습니다. 이 답은 모델의 기억이 아니라 눈앞의 자료에 뿌리를 둡니다. 좋은 RAG 시스템은 답과 함께 어떤 문서를 근거로 삼았는지 출처까지 표시합니다. 사용자가 원문을 확인할 수 있으니 신뢰가 올라가고, 틀렸을 때 어디서 어긋났는지 추적하기도 쉽습니다.

문서를 어떻게 쪼갤 것인가: 청킹 전략

RAG의 성능은 검색 이전, 문서를 어떻게 쪼갰는가에서 이미 갈립니다. 이 쪼개기를 청킹(chunking)이라 부르고, 쪼갠 한 덩어리를 청크라 합니다. 왜 통째로 넣지 않고 쪼갤까요? LLM에 한 번에 넣을 수 있는 컨텍스트 창(context window, AI가 한 번에 읽고 기억할 수 있는 글의 최대 분량)에는 한계가 있고, 질문과 무관한 긴 문서를 통째로 밀어 넣으면 정작 필요한 문장이 잡음에 묻힙니다. 검색의 정밀도를 생각해도 적당한 크기의 조각이 유리합니다.

청크가 너무 크면 한 조각 안에 여러 주제가 섞여, 검색은 됐지만 정작 답에 필요한 문장은 일부뿐인 상황이 생깁니다. 반대로 너무 작으면 문맥이 잘려 조각만 봐서는 무슨 말인지 알 수 없게 됩니다. 그래서 문단이나 문장 경계를 지키며 쪼개고, 이웃한 청크끼리 일부를 겹치게(overlap) 두는 방식을 흔히 씁니다. 겹침을 두면 경계에 걸친 문장이 어느 한쪽에서 온전히 살아남습니다.

전략은 문서의 성격에 맞춰 달리해야 합니다. 매뉴얼처럼 제목 구조가 뚜렷한 문서는 제목 단위로 쪼개면 의미가 잘 보존됩니다. 표나 코드가 섞인 문서는 그 경계를 함부로 자르면 안 됩니다. 견적서 양식의 가격표를 반으로 자르면 품목과 가격이 다른 조각으로 흩어지는 식입니다. 청킹은 한 번 정하고 끝내는 설정이 아니라, 실제 질문을 넣어 보며 다듬어 가는 실험의 대상입니다.

임베딩과 벡터 검색: 의미로 찾는다는 것

RAG의 의미 검색은 임베딩(embedding)을 바탕으로 합니다. 임베딩은 뜻이 비슷한 문장끼리 가까운 자리에 놓이도록 문장마다 주소를 매기는 일입니다. 도서관이 비슷한 주제의 책을 같은 서가에 꽂아 두는 것과 닮았습니다. 이때 주소는 수백 개의 숫자로 이뤄진 좌표이고, 앞에서 말한 벡터가 바로 이 좌표입니다. 핵심 성질은 '의미가 비슷한 문장은 좌표도 가깝게 놓인다'는 것입니다. '환불 정책'과 '반품 규정'은 글자는 다르지만 뜻이 통하므로 좌표끼리도 가깝습니다. 그래서 고객이 "환불돼요?"라고 물어도 '반품 규정' 문서를 찾아올 수 있습니다.

검색 방식은 크게 셋으로 나뉩니다. 첫째, 키워드 검색은 질문에 들어 있는 단어가 문서에 얼마나 겹치는지를 봅니다. BM25는 이 방식의 대표 계산법으로, 드물게 나오는 단어가 겹칠수록 점수를 더 줍니다. 정확한 용어나 제품명, 코드처럼 표기가 중요한 검색에 강합니다. 둘째, 의미(벡터) 검색은 방금 말한 임베딩 좌표가 얼마나 가까운지로 찾습니다. 표현이 달라도 뜻이 통하면 찾아냅니다. 셋째, 둘을 섞은 하이브리드 검색이 실무에서 가장 무난합니다. 정확한 표기와 의미의 유사성을 함께 챙깁니다.

아래 표는 세 방식의 성격을 정리한 것입니다.

의미 검색이 약한 장면을 하나 보겠습니다. 'ERR-4092 오류'라는 정확한 코드로 검색할 때, 임베딩은 '오류 처리'처럼 의미가 비슷한 엉뚱한 문서를 끌어올리곤 합니다. 이럴 때는 단어를 글자 그대로 맞추는 키워드 검색이 훨씬 정확합니다. 그래서 실무에서는 두 검색을 나란히 돌린 뒤 결과를 합치는 하이브리드 검색이 표준으로 자리 잡았습니다. 기술 지원이나 계약 검토처럼 정확한 매칭이 중요한 분야에서 특히 효과가 큽니다. 두 결과를 합치는 구체적인 계산법은 글 끝 심화 절에 모았습니다.

여기에 메타데이터(문서에 붙여 두는 작성일·부서·문서 종류 같은 꼬리표) 필터를 얹으면 검색이 한층 정교해집니다. 검색할 때 '2024년 이후 문서만' 같은 조건을 먼저 건 다음 찾는 식입니다. 오래된 규정 문서가 최신 답을 오염시키는 사고를 필터 하나로 막을 수 있습니다.

벡터 검색을 실제로 굴리려면 수많은 벡터 가운데 가장 가까운 것을 빠르게 찾아야 합니다. 이 일을 전담하는 저장소가 벡터 데이터베이스입니다. 근사 최근접 이웃(ANN) 검색은 모든 문서와 일일이 거리를 재는 대신, 가까울 만한 구역만 골라 살펴서 '거의 가장 가까운' 조각을 빠르게 찾는 방법입니다. 이 방법 덕분에 수백만 개 벡터 중에서도 순식간에 후보를 골라냅니다.

찾은 뒤 다시 줄 세우기: 재순위와 맥락 배치

검색기가 가져온 상위 문서가 곧 정답 근거라는 보장은 없습니다. 빠른 검색은 대개 근사치입니다. 그래서 검색으로 후보를 넉넉히(예를 들어 스무 개) 뽑은 다음, 더 정교한 모델로 질문과 각 후보의 관련성을 다시 채점해 진짜 상위 몇 개만 남기는 단계를 둡니다. 이 단계를 재순위(re-ranking, 관련도로 다시 매기는 일)라 부릅니다. 서류 전형으로 지원자를 넉넉히 거른 뒤 면접으로 최종 몇 명을 고르는 것과 같습니다. 검색은 넓고 빠르게, 재순위는 좁고 정밀하게 역할을 나눕니다.

찾은 문서를 프롬프트 어디에 놓느냐도 답의 질을 좌우합니다. 연구에 따르면 LLM은 긴 맥락의 중간에 놓인 정보를 놓치는 경향이 있습니다. 이른바 '중간에서 길을 잃는(lost in the middle)' 현상입니다. 스탠퍼드대 등의 연구진(Liu 등, 2023년 7월 공개)은 정답이 담긴 문서를 긴 자료 묶음의 맨 앞이나 맨 끝에 둘 때 성능이 가장 높고, 한가운데 둘 때 크게 떨어진다고 보고했습니다. 긴 회의록에서 첫머리와 결론만 기억에 남는 것과 비슷합니다. 그래서 가장 관련 있는 근거는 맥락의 맨 앞이나 맨 끝에 두고, 무턱대고 많은 문서를 밀어 넣기보다 잘 고른 몇 개를 넣는 편이 낫습니다. 순위와 놓는 위치를 따로 설계해야 한다는 뜻입니다.

검색과 생성을 잇는 접합부: 프롬프트에 근거를 심는 기술

검색으로 관련 문서를 잘 골라도, 그 문서를 모델에게 어떻게 건네느냐에 따라 답의 질이 크게 갈립니다. RAG 파이프라인에서 가장 과소평가되는 지점이 바로 이 접합부, 즉 검색 결과를 프롬프트로 조립하는 단계입니다. 흔히 쓰는 방식은 상위 몇 개의 청크를 순서대로 이어 붙인 뒤 '아래 문서를 근거로 질문에 답하라'는 지시문과 사용자 질문을 앞뒤에 두는 것입니다. 이때 앞 절에서 본 '중간에서 길을 잃는' 현상을 고려해 가장 믿을 만한 근거를 양 끝에 둡니다.

지시문 설계도 중요합니다. '근거에 없는 내용은 답하지 말고 모른다고 하라'는 제약을 분명히 적어 두면 억지 생성이 눈에 띄게 줄어듭니다. 여기에 각 청크 앞에 [문서 3] 같은 식별자를 붙이고 '답변에 사용한 문서 번호를 함께 표기하라'고 요구하면, 모델이 실제로 어느 근거를 봤는지 추적할 수 있습니다. 이 인용 표기는 나중에 답을 검증하거나 사용자에게 출처를 보여 줄 때 그대로 쓰입니다.

간단한 예시로 보는 RAG 파이프라인

사내 규정 챗봇을 만든다고 해 봅시다. 직원이 '재택근무 신청은 며칠 전에 해야 하나요?'라고 물으면, 안에서는 다음 순서로 일이 벌어집니다.

1. 미리 준비: 규정 문서를 문단 단위로 쪼개(chunk) 각 조각을 임베딩 모델로 좌표로 바꾸고, 원문과 함께 벡터 데이터베이스에 저장해 둡니다.
2. 질문을 좌표로: 직원의 질문도 같은 임베딩 모델로 좌표로 바꿉니다.
3. 넉넉히 찾기: 질문 좌표와 가까운 규정 조각을 스무 개쯤 후보로 뽑습니다.
4. 다시 줄 세우기: 재순위 모델로 후보를 다시 채점해 가장 관련 있는 세 개만 남깁니다.
5. 엮어서 건네기: '다음 자료를 참고해 답하라'는 지시, 남은 세 조각, 직원의 질문을 하나의 프롬프트로 엮어 LLM에 건넵니다.
6. 근거와 함께 답하기: LLM이 규정 원문을 읽고 답을 짓고, 근거가 된 조항을 함께 보여 줍니다.

같은 흐름을 코드로 적은 모습은 글 끝 심화 절에 있습니다.

이렇게 만든 답은 규정 원문에 뿌리를 두므로, 모델이 '아마 3일 전쯤'이라고 지어낼 여지가 크게 줄어듭니다. 근거가 된 문단을 함께 보여 주면 사용자가 직접 확인할 수 있습니다.

실무에서 RAG를 굴릴 때 챙길 것들

실무의 첫 관문은 데이터 품질입니다. RAG의 답은 검색된 문서를 넘지 못합니다. 문서가 낡았거나, 서로 모순되거나, 애초에 없는 내용이면 검색과 생성을 아무리 잘 튜닝해도 답은 부실합니다. '쓰레기를 넣으면 쓰레기가 나온다'는 격언이 여기서도 그대로 통합니다. 반품 규정이 2023년판과 2025년판 두 벌 섞여 있으면 AI는 어느 쪽을 근거로 삼을지 모릅니다. 문서를 최신으로 유지하고 중복·모순을 정리하는 일이 모델 튜닝보다 먼저입니다.

두 번째는 파인튜닝과의 역할 분담입니다. 파인튜닝(fine-tuning, 이미 학습된 모델에 우리 자료를 더 가르쳐 버릇을 바꾸는 일)은 모델에 새로운 말투나 형식, 특정 과제의 요령을 심는 데 강합니다. 반면 자주 바뀌는 사실 지식을 넣는 데는 RAG가 유리합니다. 문서만 갈면 지식이 갱신되기 때문입니다. 실무에서는 둘을 섞기도 합니다. 답의 형식은 파인튜닝으로, 사실 근거는 RAG로 대는 식입니다.

세 번째는 근거 표시와 거절입니다. 좋은 RAG는 답의 출처를 밝히고, 검색된 문서에 답이 없으면 '자료에서 확인할 수 없다'고 물러설 줄 알아야 합니다. 앞의 접합부 절에서 본 거절 지시를 프롬프트에 적어 두면, 근거 없이 지어내는 사고를 크게 줄일 수 있습니다.

RAG를 둘러싼 흔한 오해와 남는 한계

가장 큰 오해는 'RAG를 붙이면 환각이 사라진다'는 믿음입니다. 그렇지 않습니다. RAG는 지어낼 여지를 줄일 뿐 없애지는 못합니다. 검색이 엉뚱한 문서를 가져오면 모델은 그 잘못된 근거를 충실히 요약해 그럴듯한 오답을 냅니다. 정확한 근거가 있어도 모델이 그것을 무시하고 제 기억으로 답해 버리는 경우도 있습니다. 실제 사례도 있습니다. 2024년 5월 스탠퍼드대와 예일대 연구진은 "환각이 없다"고 홍보한 RAG 기반 법률 AI 연구 도구들을 시험했는데, 도구에 따라 답의 17%에서 33%에 환각이 섞여 있었습니다. 연구진은 범용 챗봇보다는 줄었지만 '환각 없음'이라는 홍보는 과장이라고 결론 내렸습니다. RAG는 만능 해독제가 아니라 위험을 관리하는 장치입니다.

두 번째 오해는 '문서를 많이 넣을수록 좋다'는 생각입니다. 앞서 본 '중간에서 길을 잃는' 현상 때문에, 관련 없는 문서를 잔뜩 넣으면 오히려 답이 나빠집니다. 검색과 재순위로 잘 고른 몇 개를 넣는 편이 낫습니다. 컨텍스트 창이 아무리 커졌다 해도 이 원칙은 그대로입니다.

세 번째로, RAG는 검색이 잘 되는 질문에 강하지만 여러 문서를 종합해 추론해야 하는 복잡한 질문이나, 문서에 드러나 있지 않은 함의를 끌어내는 질문에는 약할 수 있습니다. 이런 경우 질문을 여러 단계로 쪼개 검색을 반복하거나, 추론과 검색을 번갈아 하는 더 정교한 구성이 필요합니다. 다음 절에서 그 갈래를 살펴봅니다.

검색 품질, 임베딩 성능, 청킹 전략, 데이터 신선도, 프롬프트 설계가 모두 맞물려야 RAG가 제 힘을 냅니다. 어느 한 곳이 부실하면 전체가 흔들립니다.

RAG는 하나가 아니다: 나이브부터 에이전틱까지의 스펙트럼

RAG라고 뭉뚱그려 부르지만, 실제 구현은 성숙도에 따라 여러 층위로 나뉩니다. 가장 단순한 형태는 질문을 그대로 검색에 넣고, 나온 청크를 붙여 한 번에 답하는 방식입니다. 이른바 나이브(naive, 가장 기본형이라는 뜻) RAG입니다. 빠르게 만들 수 있지만, 질문이 모호하거나 여러 정보를 조합해야 하는 경우에는 금방 한계를 드러냅니다.

그다음 단계는 검색 전후에 손질을 더하는 고급 RAG입니다. 검색 전에는 질문을 다시 쓰거나(query rewriting) 여러 하위 질문으로 쪼개고, 검색 후에는 재순위와 중복 제거로 근거를 정제합니다. 여기서 한발 더 나아가면, 모델 스스로 '지금 검색이 필요한가', '검색 결과가 충분한가'를 판단하고 필요하면 다시 검색하는 흐름이 나옵니다. 반복 검색을 반복 추론과 엮은 이 구조를 에이전틱(agentic, 스스로 판단해 여러 단계를 밟는) RAG라 부릅니다.

아래 표는 이 스펙트럼의 차이를 정리한 것입니다. 아래 행으로 갈수록 답의 품질과 복잡한 질문 대응력은 올라가지만, 지연 시간과 비용, 구현 난도도 함께 뜁니다.

어떤 층위를 고를지는 서비스의 성격이 정합니다. 단순 FAQ 응답이라면 나이브로 충분합니다. 여러 문서를 교차 참조해야 하는 법률·의료 질의라면 에이전틱 쪽으로 무게가 실립니다. 문서끼리의 관계를 따라가야 하는 질문에는 사람·회사·제품 사이의 연결을 그래프로 엮어 두는 GraphRAG도 씁니다. 링크드인은 과거 고객 문의 기록을 이렇게 엮은 RAG를 고객 지원팀에서 약 6개월 운영해, 문의 한 건을 해결하는 시간의 중앙값을 28.6% 줄였다고 2024년 4월 논문에서 밝혔습니다. 처음부터 가장 복잡한 구조를 짜면 어느 단계에서 틀렸는지 찾기가 어려워집니다. 나이브로 뼈대를 세우고, 실패 사례를 보며 필요한 부분만 고급·에이전틱 기법으로 보강하는 순서가 현실적입니다.

잘 되는지 어떻게 아는가: RAG 평가의 두 축

RAG를 운영하다 보면 '답이 좋아진 것 같다'는 느낌만으로는 아무것도 개선할 수 없다는 사실을 깨닫게 됩니다. 정량 평가가 없으면 청킹 크기를 바꾸든 재순위를 넣든, 그 변화가 나아진 것인지 나빠진 것인지 판단할 근거가 없습니다. 그래서 RAG 평가는 검색과 생성이라는 두 단계를 따로 재는 데서 출발합니다.

검색 단계에서는 '정답이 담긴 문서가 상위 몇 개 안에 들어왔는가', '정답 문서가 몇 번째에 나왔는가'를 셉니다. 생성 단계에서는 '답이 가져온 근거를 벗어나지 않았는가', '질문에 제대로 답했는가'를 봅니다. 특히 답이 근거를 벗어나지 않았는지 재는 일은 환각을 잡는 최전선입니다. 답의 각 문장이 근거 청크로 뒷받침되는지 하나씩 대조하면, 근거를 벗어난 생성이 얼마나 섞였는지 수치로 드러납니다. 채점할 양이 많아서 요즘은 강한 AI 모델을 심판으로 세워 자동 채점하는 방식도 널리 쓰입니다.

평가를 붙일 때 흔히 저지르는 실수는 골든 데이터셋 없이 시작하는 것입니다. 골든 데이터셋은 미리 정답을 적어 둔 시험지입니다. 최소 수십 개라도 '질문, 정답 근거, 모범 답변' 세트를 손으로 만들어 두면, 이후 모든 개선을 이 기준선과 비교해 판단할 수 있습니다. 쇼핑몰이라면 자주 들어온 고객 문의 서른 개와 모범 답변으로 시작하면 됩니다. 처음엔 번거롭지만, 이 준비가 없으면 RAG를 고칠 때마다 감에 기대게 됩니다.

긴 맥락 모델이 나오면 RAG는 필요 없어지나

컨텍스트 창이 수십만 토큰(token, AI가 글을 읽고 쓰는 조각 단위로, 보통 단어 하나보다 조금 작은 단위)까지 늘어난 모델이 등장하면서, '문서를 통째로 넣으면 검색이 필요 없지 않냐'는 물음이 자주 나옵니다. 짧은 문서 몇 개라면 통째로 넣는 편이 실제로 더 단순합니다. 하지만 이 논리는 데이터 규모가 커지는 순간 무너집니다. 기업의 문서 저장소는 흔히 수십만, 수백만 페이지에 이릅니다. 컨텍스트 창이 아무리 넓어도 이 전부를 질문마다 밀어 넣을 수는 없습니다.

비용과 지연도 무시할 수 없는 벽입니다. 대부분의 모델은 입력 토큰 수에 비례해 요금을 매깁니다. 질문마다 20만 토큰을 넣으면, 정작 답에 필요한 근거는 그중 몇백 토큰뿐인데도 나머지 무관한 정보를 처리하는 비용까지 고스란히 뭅니다. RAG는 검색으로 필요한 조각만 추려 넣어 이 비용과 지연을 근본적으로 낮춥니다. 긴 맥락은 '넣을 수 있느냐'의 문제를, RAG는 '넣을 가치가 있느냐'의 문제를 푼다고 정리할 수 있습니다.

품질 면에서도 둘은 대립이 아니라 보완 관계입니다. 앞의 오해 절에서 본 것처럼 맥락이 길수록 '중간에서 길을 잃는' 위험도 커지므로, 필요한 근거만 골라 넣으면 긴 맥락 모델이라도 답이 더 정확해지는 경우가 많습니다.

정리하면, 긴 맥락 모델은 RAG를 대체하기보다 근거를 넣을 자리를 넉넉하게 해 줍니다. 또한 최신 정보 반영, 출처 추적, 접근 권한 통제 같은 요구는 컨텍스트 창 크기와 상관없이 검색 계층이 있어야 풀립니다. 두 기술은 각자의 자리에서 서로를 떠받칩니다.

실제 서비스로 만들려면

RAG를 실제 서비스로 구현하려면 검색 파이프라인 설계, 청크 전략, 재순위 모델 튜닝 같은 실무적 결정이 필요합니다. 젠아이랩스(GenAI Labs)의 AI 챗봇 솔루션은 이 과정을 기업 데이터에 맞춰 구축해 드립니다.

개발자를 위한 심화

이 부분은 직접 구현하는 개발자를 위한 내용입니다.

코드 흐름으로 본 파이프라인

아래는 앞의 '간단한 예시' 절의 여섯 단계를 색인 단계와 질의 단계로 나눠, 특정 라이브러리에 묶이지 않은 의사코드로 적은 것입니다.

# 색인 단계: 문서를 쪼개 벡터로 바꿔 저장
chunks = split(docs)
vectors = embed(chunks)
db.add(vectors, chunks)

# 질의 단계: 넉넉히 찾고, 재순위로 셋만 남겨 프롬프트로 엮는다
hits = db.search(embed(query), top_k=20)
top = rerank(query, hits)[:3]
prompt = f"다음 자료를 참고해 답하라.\n{top}\n질문: {query}"

생성 단계에서는 디코딩 파라미터를 보수적으로 둡니다. 사실을 다루는 RAG에서는 창의적 변주가 필요 없으므로 온도(temperature)를 낮게 두고, top-p나 top-k도 좁게 잡는 편이 안전합니다. 각 값의 뜻은 프롬프트 엔지니어링 글을 참고하세요.

재순위와 맥락 예산 짜기

재순위가 중요한 까닭은 검색의 정밀도(precision, 가져온 것 중 쓸모 있는 것의 비율)와 재현율(recall, 필요한 것 중 실제로 가져온 것의 비율) 사이의 균형 때문입니다. 후보를 적게 뽑으면 정작 필요한 조각을 놓칠 위험이 크고(재현율 하락), 많이 뽑으면 잡음이 섞입니다(정밀도 하락). 넓게 뽑아 재현율을 확보한 뒤 재순위로 정밀도를 끌어올리는 두 박자 구성이 이 딜레마를 누그러뜨립니다.

근거 청크의 총량이 모델의 컨텍스트 창을 넘지 않도록 예산을 짜야 합니다. 컨텍스트 창은 토큰 단위로 셉니다. 예를 들어 컨텍스트 창이 8천 토큰인데 청크 하나가 평균 400토큰이라면, 지시문과 질문, 출력 여유분을 빼고 열 개 남짓만 넣을 수 있습니다. 무작정 많이 넣는다고 좋아지지 않습니다. 관련성 낮은 청크를 함께 넣으면 오히려 잡음이 되어 답을 흐립니다. 정밀도와 재현율 사이의 균형을 맥락 예산 안에서 잡는 것이 접합부 설계의 핵심입니다.

하이브리드 검색: 밀집·희소 검색과 상호 순위 융합

의미를 잡는 밀집 벡터(dense) 검색과, 단어 빈도에 기반한 희소(sparse) 검색인 BM25를 나란히 돌린 뒤 결과를 합칩니다. 밀집 벡터는 수백 차원이 대부분 0이 아닌 값으로 채워진 임베딩이고, 희소 벡터는 어휘 사전 크기만큼의 차원 가운데 문서에 나온 단어 자리만 값이 있는 표현입니다. 합치는 대표적 방법이 상호 순위 융합(RRF, Reciprocal Rank Fusion)입니다. 각 검색 결과에서 문서의 순위를 역수로 환산해 더하는 단순한 방식인데, 척도가 서로 다른 두 점수를 억지로 정규화하지 않고도 안정적으로 합칠 수 있어 널리 쓰입니다.

하이브리드 구성은 공짜가 아닙니다. 인덱스를 두 벌 관리해야 하고, 융합 가중치나 필터 조건을 튜닝하는 손이 더 듭니다. 실제 로그에서 어떤 질문이 들어오는지 보고 키워드 매칭이 자주 필요하다면, 하이브리드로 넘어갈 때가 된 것입니다. 문장 임베딩 모델로는 Sentence-BERT 계열이 대표적이며, 벡터 데이터베이스는 대개 ANN 색인(HNSW 등)으로 근사 검색을 합니다.

평가 지표

검색 단계는 정보 검색 분야의 고전적 지표를 그대로 씁니다. 정답 근거가 상위 k개 안에 들어왔는지 보는 재현율@k, 상위 결과의 정확성을 보는 정밀도, 정답이 몇 번째에 왔는지를 반영하는 MRR(첫 정답 순위의 역수 평균) 같은 값입니다. 정답 근거 문서를 미리 표시한 평가셋만 있으면 이 지표들은 자동으로 계산됩니다. 청킹이나 임베딩 모델을 바꿀 때 가장 먼저 확인해야 할 숫자입니다.

생성 단계는 답이 근거에 충실한지(faithfulness), 질문에 제대로 답했는지(answer relevance), 검색된 맥락이 실제로 답에 쓸모 있었는지(context relevance)를 나눠 봅니다. 이 항목들은 강한 모델을 심판으로 세워 자동 채점하는 방식(LLM-as-a-judge)으로 재는 경우가 많습니다.

더 읽을거리

RAG의 뿌리를 보려면 2020년의 원 논문 'Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks'를 읽어 볼 만합니다. 검색기를 밀집 벡터로 구성한 DPR(Dense Passage Retrieval), 검색을 사전학습 단계부터 결합한 REALM은 RAG 이전과 이후를 잇는 중요한 이정표입니다. 이 세 편을 함께 보면 '검색을 학습에 어떻게 녹여 왔는가'라는 흐름이 잡힙니다.

실무 감각을 키우려면 맥락 활용의 한계를 다룬 'Lost in the Middle'과, 문장 임베딩의 기본을 세운 Sentence-BERT를 권합니다. 앞의 것은 문서를 프롬프트 어디에 놓아야 하는지 감을 잡게 해 주고, 뒤의 것은 의미 검색이 왜 통하는지를 설명합니다. 키워드 검색의 고전인 BM25도 하이브리드 검색을 설계할 때 꼭 알아 둬야 합니다.

개념 면에서는 임베딩, 토큰화, 어텐션 같은 LLM의 기본기를 함께 익히면 RAG의 각 단계가 왜 그렇게 설계됐는지 더 깊이 이해할 수 있습니다. 나아가 파인튜닝과 RAG의 차이, 그리고 검색과 추론을 번갈아 수행하는 에이전트형 구성으로 시야를 넓히면, 환각을 관리하며 LLM을 실무에 안착시키는 큰 그림이 완성됩니다.