한 문장으로 못 박는 RAG
RAG(검색 증강 생성, Retrieval-Augmented Generation)는 대규모 언어모델(LLM)이 답을 생성하기 전에 외부 지식 저장소에서 관련 문서를 먼저 검색하고, 그 문서를 근거로 삼아 답을 짓게 만드는 기법이다. 이름 그대로 '검색(retrieval)'으로 '생성(generation)'을 '증강(augmented)'한다. 모델 혼자 기억을 더듬어 답하는 대신, 시험 직전에 관련 자료를 펼쳐 놓고 그것을 보며 답을 쓰는 셈이다.
여기서 핵심은 두 부품이 나뉜다는 점이다. 하나는 질문과 연관된 문서 조각을 찾아오는 검색기(retriever), 다른 하나는 찾아온 조각을 읽고 자연스러운 문장으로 답을 짓는 생성기(generator), 즉 LLM이다. 이 둘을 파이프라인으로 잇는 구조가 RAG다.
2020년 페이스북 AI 연구진이 발표한 논문에서 이 이름이 자리를 잡았다. 그 뒤로 RAG는 사내 문서 검색, 고객 응대 챗봇, 법률·의료 문서 질의응답 같은 지식 집약적 과제에서 사실상 표준에 가까운 설계가 됐다. LLM을 실제 업무에 붙일 때 가장 먼저 검토하는 구조라고 봐도 무리가 없다.
왜 모델 혼자로는 부족한가 — 할루시네이션과 지식의 유통기한
LLM은 다음에 올 단어를 확률 분포에서 골라 문장을 잇는 기계다. 방대한 글로 학습하면서 세상의 지식을 파라미터(가중치) 안에 녹여 넣었지만, 그 지식은 '통계적으로 어울리는 조각'으로 압축돼 있을 뿐 사실을 대조하는 창구가 아니다. 그래서 그 자리에 올 법한 그럴듯한 내용을 지어내는 할루시네이션이 원리적으로 새어 나온다. 없는 논문을 제목과 저자까지 붙여 만들어 내거나, 일어난 적 없는 사건을 날짜까지 확신에 차 답하는 장면이 대표적이다.
문제는 이것이 코드를 잘못 짜서 생긴 버그가 아니라, 확률로 문장을 짓는 방식에 딸린 부작용이라는 데 있다. 완전히 없앨 수 없다면 관리해야 한다. 관리의 한 축이 바로 모델 바깥의 신뢰할 수 있는 지식을 연결해 주는 일이다. 답의 근거를 모델의 흐릿한 기억이 아니라 검증된 문서에 두면, 지어낼 여지가 줄어든다.
또 하나의 한계는 지식의 유통기한이다. 학습을 마친 시점 이후의 사건은 모델이 알 수 없다. 오늘 갱신된 사내 정책, 어제 나온 제품 사양, 방금 바뀐 가격표는 파라미터 안에 들어 있지 않다. 모델을 다시 학습시켜 최신 지식을 심으려면 막대한 비용과 시간이 든다. RAG는 이 문제를 우회한다. 지식을 모델 바깥의 문서 저장소에 두고, 문서만 갈아 끼우면 모델은 그대로 두고도 최신 정보로 답할 수 있다.
검색으로 근거를 찾아 답에 붙이는 전체 흐름
RAG의 작동은 크게 두 단계로 나뉜다. 미리 준비해 두는 색인(indexing) 단계와, 질문이 들어올 때마다 도는 질의(query) 단계다. 색인 단계에서는 답의 재료가 될 문서를 잘게 쪼개고, 각 조각을 숫자 벡터로 바꿔 저장소에 넣어 둔다. 이 작업은 한 번 해 두면 되고, 문서가 바뀔 때만 갱신한다.
질의 단계는 실제 대화가 오갈 때 벌어진다. 사용자의 질문이 들어오면 그 질문도 똑같이 벡터로 바꾼다. 그다음 저장소에서 질문 벡터와 가장 가까운 문서 조각 몇 개를 찾아온다. 여기까지가 검색기의 일이다. 찾아온 조각들을 원래 질문과 함께 하나의 프롬프트로 엮어 LLM에 건넨다. 이때 프롬프트는 대략 '아래 자료를 참고해 질문에 답하라'는 지시와, 검색된 문서 본문, 그리고 사용자 질문으로 구성한다.
마지막으로 LLM은 건네받은 문서를 읽고 답을 짓는다. 이 답은 모델의 기억이 아니라 눈앞의 자료에 뿌리를 둔다. 좋은 RAG 시스템은 답과 함께 어떤 문서를 근거로 삼았는지 출처까지 표시한다. 사용자가 원문을 확인할 수 있으니 신뢰가 올라가고, 틀렸을 때 어디서 어긋났는지 추적하기도 쉽다.
문서를 어떻게 쪼갤 것인가 — 청킹 전략
RAG의 성능은 검색 이전, 문서를 어떻게 쪼갰는가에서 이미 갈린다. 이 쪼개기를 청킹(chunking)이라 부른다. 왜 통째로 넣지 않고 쪼개는가. LLM에 한 번에 넣을 수 있는 맥락 창(context window)에는 한계가 있고, 질문과 무관한 긴 문서를 통으로 밀어 넣으면 정작 필요한 문장이 잡음에 묻힌다. 검색의 정밀도를 위해서도 적당한 크기의 조각이 유리하다.
청크가 너무 크면 한 조각 안에 여러 주제가 섞여, 검색은 됐지만 정작 답에 필요한 문장은 일부뿐인 상황이 생긴다. 반대로 너무 작으면 문맥이 잘려 조각만 봐서는 무슨 말인지 알 수 없게 된다. 그래서 문단이나 문장 경계를 존중하며 쪼개고, 인접한 청크끼리 일부를 겹치게(overlap) 두는 방식을 흔히 쓴다. 겹침을 두면 경계에 걸친 문장이 어느 한쪽에서 온전히 살아남는다.
문서의 성격에 맞춰 전략을 달리해야 한다. 매뉴얼처럼 제목 구조가 뚜렷한 문서는 제목 단위로 쪼개면 의미가 잘 보존된다. 표나 코드가 섞인 문서는 그 경계를 함부로 자르면 안 된다. 청킹은 한 번 정하고 끝내는 설정이 아니라, 실제 질문을 넣어 보며 다듬어 가는 실험의 대상이다.
임베딩과 벡터 검색 — 의미로 찾는다는 것
RAG의 심장은 임베딩(embedding)이다. 임베딩은 글자 덩어리를 고차원 숫자 벡터로 바꾸는 변환이다. 이때 핵심 성질은 '의미가 비슷한 문장은 벡터 공간에서도 가깝게 놓인다'는 것이다. '환불 정책'과 '반품 규정'은 글자는 다르지만 뜻이 통하므로 벡터끼리도 가깝다. Sentence-BERT 계열의 문장 임베딩 모델이 이런 표현을 잘 만들어 내는 대표 사례다.
검색 방식은 크게 셋으로 나뉜다. 첫째, 키워드 검색은 BM25 같은 알고리즘으로 단어가 얼마나 겹치는지를 본다. 정확한 용어나 제품명, 코드처럼 표기가 중요한 검색에 강하다. 둘째, 의미(벡터) 검색은 방금 말한 임베딩의 근접도로 찾는다. 표현이 달라도 뜻이 통하면 찾아낸다. 셋째, 둘을 섞은 하이브리드 검색이 실무에서 가장 무난하다. 정확한 표기와 의미적 유사성을 함께 챙긴다.
아래 표는 세 방식의 성격을 정리한 것이다.
| 검색 방식 | 무엇으로 찾나 | 강점 | 약점 |
|---|---|---|---|
| 키워드(BM25) | 단어의 겹침 | 정확한 용어·고유명사에 강함 | 표현이 다르면 놓침 |
| 의미(벡터) | 임베딩의 근접도 | 뜻이 통하면 찾아냄 | 정확한 표기에 약할 수 있음 |
| 하이브리드 | 둘을 결합 | 균형이 좋음 | 구성·튜닝이 복잡 |
벡터 검색을 실제로 굴리려면 수많은 벡터에서 가장 가까운 것을 빠르게 찾아야 한다. 이 일을 전담하는 저장소가 벡터 데이터베이스다. 근사 최근접 이웃(ANN) 알고리즘으로 수백만 개 벡터 중에서도 가까운 조각을 빠르게 골라낸다.
찾은 뒤 다시 줄 세우기 — 재순위와 맥락 배치
검색기가 가져온 상위 문서가 곧 정답 근거라는 보장은 없다. 빠른 검색은 대개 근사치다. 그래서 검색으로 후보를 넉넉히(예를 들어 스무 개) 뽑은 다음, 더 정교한 모델로 질문과 각 후보의 관련성을 다시 채점해 진짜 상위 몇 개만 남기는 단계를 둔다. 이 단계를 재순위(reranking)라 부른다. 검색은 넓고 빠르게, 재순위는 좁고 정밀하게 — 역할이 나뉜다.
재순위가 중요한 이유는 검색의 정밀도(precision)와 재현율(recall) 사이의 균형 때문이다. 후보를 적게 뽑으면 정작 필요한 조각을 놓칠 위험이 크고(재현율 하락), 많이 뽑으면 잡음이 섞인다(정밀도 하락). 넓게 뽑아 재현율을 확보한 뒤 재순위로 정밀도를 끌어올리는 두 박자 구성이 이 딜레마를 완화한다.
찾은 문서를 프롬프트 어디에 놓느냐도 답의 질을 좌우한다. 연구에 따르면 LLM은 긴 맥락의 중간에 놓인 정보를 놓치는 경향이 있다. 이른바 '중간에서 길을 잃는(lost in the middle)' 현상이다. 가장 관련 있는 근거는 맥락의 앞이나 뒤 끝에 배치하고, 무턱대고 많은 문서를 밀어 넣기보다 정선한 소수를 넣는 편이 낫다는 실무적 함의로 이어진다.
간단한 예시로 보는 RAG 파이프라인
개념을 코드 흐름으로 그려 보자. 사내 규정 챗봇을 만든다고 하면, 색인 단계는 대략 이렇게 흘러간다. 규정 문서를 문단 단위로 쪼개(chunk) 각 조각을 임베딩 모델로 벡터화하고, 벡터 데이터베이스에 원문과 함께 저장한다. 의사코드로 적으면 '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}"'처럼 근거와 질문을 엮어 LLM에 건넨다.
생성 단계에서 디코딩 파라미터도 신경 쓴다. 사실을 다루는 RAG에서는 창의적 변주가 필요 없으므로 온도(temperature)를 낮게 둔다. 온도가 0에 가까우면 모델은 확률이 가장 높은 단어를 뽑아 일관된 답을 내고, 온도가 높으면 분포를 평평하게 만들어 덜 흔한 단어까지 고르며 변주가 커진다. 근거에 충실한 답을 원한다면 낮은 온도에, top-p(누적 확률로 후보를 자르는 방식)나 top-k도 보수적으로 잡는 편이 안전하다.
이렇게 만든 답은 규정 원문에 뿌리를 두므로, 모델이 '아마 3일 전쯤'이라고 지어낼 여지가 크게 줄어든다. 근거가 된 문단을 함께 보여 주면 사용자가 직접 확인할 수 있다.
실무에서 RAG를 굴릴 때 챙길 것들
실무의 첫 관문은 데이터 품질이다. RAG의 답은 검색된 문서를 넘지 못한다. 문서가 낡았거나, 서로 모순되거나, 애초에 없는 내용이면 아무리 검색과 생성을 잘 튜닝해도 답은 부실하다. '쓰레기를 넣으면 쓰레기가 나온다'는 격언이 여기서도 그대로 통한다. 문서를 최신으로 유지하고 중복·모순을 정리하는 일이 모델 튜닝보다 먼저다.
두 번째는 평가다. RAG는 검색 부분과 생성 부분을 나눠 평가해야 병목을 짚을 수 있다. 검색이 정답 근거를 제대로 가져왔는지(재현율·정밀도), 생성이 그 근거에 충실하게 답했는지를 따로 본다. 답이 틀렸을 때 검색이 근거를 못 찾은 것인지, 근거는 왔는데 모델이 엉뚱하게 읽은 것인지 구분해야 고칠 지점이 보인다.
세 번째는 파인튜닝과의 역할 분담이다. 파인튜닝(fine-tuning)은 모델에 새로운 말투나 형식, 특정 과제의 요령을 심는 데 강하다. 반면 자주 바뀌는 사실 지식을 넣는 데는 RAG가 유리하다. 문서만 갈면 지식이 갱신되기 때문이다. 실무에서는 둘을 섞기도 한다. 답의 형식은 파인튜닝으로, 사실 근거는 RAG로 대는 식이다.
네 번째는 근거 표시와 거절이다. 좋은 RAG는 답의 출처를 밝히고, 검색된 문서에 답이 없으면 '자료에서 확인할 수 없다'고 물러설 줄 알아야 한다. 이 거절 규칙을 프롬프트에 명시해 두면, 근거 없이 지어내는 사고를 크게 줄일 수 있다.
RAG를 둘러싼 흔한 오해와 남는 한계
가장 큰 오해는 'RAG를 붙이면 할루시네이션이 사라진다'는 믿음이다. 그렇지 않다. RAG는 지어낼 여지를 줄일 뿐, 없애지 못한다. 검색이 엉뚱한 문서를 가져오면 모델은 그 잘못된 근거를 충실히 요약해 그럴듯한 오답을 낸다. 심지어 정확한 근거가 있어도 모델이 그것을 무시하고 제 기억으로 답해 버리는 경우도 있다. RAG는 만능 해독제가 아니라 위험을 관리하는 장치다.
두 번째 오해는 '문서를 많이 넣을수록 좋다'는 생각이다. 앞서 본 '중간에서 길을 잃는' 현상 때문에, 관련 없는 문서를 잔뜩 넣으면 오히려 답이 나빠진다. 검색과 재순위로 정선한 소수를 넣는 편이 낫다. 맥락 창이 아무리 커졌다 해도 이 원칙은 유효하다.
세 번째로, RAG는 검색이 잘 되는 질문에 강하지만, 여러 문서를 종합해 추론해야 하는 복잡한 질문이나 문서에 명시되지 않은 함의를 끌어내는 질문에는 약할 수 있다. 이런 경우 질문을 여러 단계로 쪼개 검색을 반복하거나, 추론과 검색을 번갈아 하는 더 정교한 구성이 필요하다.
한계를 정직하게 인정하는 편이 낫다. 검색 품질, 임베딩 성능, 청킹 전략, 데이터 신선도, 프롬프트 설계가 모두 맞물려야 RAG가 제 힘을 낸다. 어느 한 곳이 부실하면 전체가 흔들린다.
검색과 생성을 잇는 접합부 — 프롬프트에 근거를 심는 기술
검색으로 관련 문서를 잘 골라도, 그 문서를 모델에게 어떻게 건네느냐에 따라 답의 질이 크게 갈린다. RAG 파이프라인에서 가장 과소평가되는 지점이 바로 이 접합부, 즉 검색 결과를 프롬프트로 조립하는 단계다. 흔히 쓰는 방식은 상위 k개의 청크를 순서대로 이어 붙인 뒤 '아래 문서를 근거로 질문에 답하라'는 지시문과 사용자 질문을 앞뒤에 배치하는 것이다. 겉보기엔 단순하지만, 여기서 지시문의 강도와 근거의 배치 순서가 답의 사실성을 좌우한다.
모델은 프롬프트 안의 위치에 따라 정보를 다르게 취급한다. 긴 맥락을 넣으면 앞과 뒤에 놓인 내용은 잘 반영하지만 가운데 파묻힌 내용은 놓치는 경향이 보고돼 있다. 흔히 '중간 소실(lost in the middle)'이라 부르는 현상이다. 그래서 재순위로 가장 신뢰도 높은 청크를 골랐다면, 그 청크를 프롬프트의 맨 앞이나 맨 뒤에 두는 편이 유리하다. 순위와 물리적 배치를 따로 설계해야 한다는 뜻이다.
지시문 설계도 중요하다. '근거에 없는 내용은 답하지 말고 모른다고 하라'는 제약을 명시하면 억지 생성이 눈에 띄게 줄어든다. 여기에 각 청크 앞에 [문서 3] 같은 식별자를 붙이고 '답변에 사용한 문서 번호를 함께 표기하라'고 요구하면, 모델이 실제로 어느 근거를 봤는지 추적할 수 있다. 이 인용 표기는 나중에 답을 검증하거나 사용자에게 출처를 보여줄 때 그대로 쓰인다.
실무에서는 근거 청크의 총량이 모델의 맥락 창을 넘지 않도록 예산을 짜야 한다. 예를 들어 맥락 창이 8천 토큰인데 청크 하나가 평균 400토큰이라면, 지시문과 질문, 출력 여유분을 빼고 열 개 남짓만 넣을 수 있다. 무작정 많이 넣는다고 좋아지지 않는다. 관련성 낮은 청크를 함께 넣으면 오히려 잡음이 되어 답을 흐린다. 정밀도와 재현율 사이의 균형을 맥락 예산 안에서 잡는 것이 접합부 설계의 핵심이다.
RAG는 하나가 아니다 — 나이브부터 에이전틱까지의 스펙트럼
RAG라고 뭉뚱그려 부르지만, 실제 구현은 성숙도에 따라 여러 층위로 나뉜다. 가장 단순한 형태는 질문을 그대로 검색에 넣고, 나온 청크를 붙여 한 번에 답하는 방식이다. 이른바 나이브 RAG다. 빠르게 만들 수 있지만, 질문이 모호하거나 여러 정보를 조합해야 하는 경우에는 금방 한계를 드러낸다. 사용자가 던진 문장을 그대로 검색어로 쓰는 탓에, 검색 품질이 사용자의 표현력에 좌우된다.
그다음 단계는 검색 전후에 손질을 더하는 고급 RAG다. 검색 전에는 질문을 다시 쓰거나(query rewriting) 여러 하위 질문으로 쪼개고, 검색 후에는 재순위와 중복 제거로 근거를 정제한다. 여기서 한발 더 나아가면, 모델 스스로 '지금 검색이 필요한가', '검색 결과가 충분한가'를 판단하고 필요하면 재검색하는 흐름이 나온다. 반복 검색을 반복 추론과 엮은 이 구조를 에이전틱 RAG라 부른다.
아래 표는 이 스펙트럼의 차이를 정리한 것이다. 오른쪽으로 갈수록 답의 품질과 복잡한 질문 대응력은 올라가지만, 지연 시간과 비용, 구현 난도도 함께 뛴다.
| 유형 | 검색 방식 | 강점 | 약점 |
|---|---|---|---|
| 나이브 RAG | 질문 그대로 1회 검색 | 구현 쉬움, 빠름 | 모호한 질문에 취약 |
| 고급 RAG | 질문 재작성·재순위 포함 | 검색 정밀도 향상 | 전처리 비용 증가 |
| 에이전틱 RAG | 모델이 검색 여부·횟수 판단 | 복합 질문 대응 | 지연·비용 큼, 통제 난도 |
어떤 층위를 고를지는 서비스의 성격이 정한다. 단순 FAQ 응답이라면 나이브로 충분하다. 여러 문서를 교차 참조해야 하는 법률·의료 질의라면 에이전틱 쪽으로 무게가 실린다. 처음부터 가장 복잡한 구조를 짜려 들면 디버깅이 지옥이 된다. 나이브로 뼈대를 세우고, 실패 사례를 보며 필요한 부분만 고급·에이전틱 기법으로 보강하는 순서가 현실적이다.
잘 되는지 어떻게 아는가 — RAG 평가의 두 축
RAG를 운영하다 보면 '답이 좋아진 것 같다'는 느낌만으로는 아무것도 개선할 수 없다는 사실을 깨닫는다. 정량 평가가 없으면 청킹 크기를 바꾸든 재순위를 넣든, 그 변화가 나아진 것인지 나빠진 것인지 판단할 근거가 없다. 그래서 RAG 평가는 검색과 생성이라는 두 단계를 따로 재는 데서 출발한다. 검색이 엉망이면 아무리 좋은 모델도 근거 없는 답을 낼 수밖에 없으니, 병목이 어디인지부터 갈라내야 한다.
검색 단계는 정보 검색 분야의 고전적 지표를 그대로 쓴다. 정답 근거가 상위 k개 안에 들어왔는지 보는 재현율@k, 상위 결과의 정확성을 보는 정밀도, 정답이 몇 번째에 왔는지를 반영하는 MRR 같은 값이다. 정답 근거 문서를 미리 표시한 평가셋만 있으면 이 지표들은 자동으로 계산된다. 청킹이나 임베딩 모델을 바꿀 때 가장 먼저 확인해야 할 숫자다.
생성 단계는 조금 더 까다롭다. 답이 근거에 충실한지(faithfulness), 질문에 제대로 답했는지(answer relevance), 검색된 맥락이 실제로 답에 쓸모 있었는지(context relevance)를 나눠 본다. 이 항목들은 사람이 채점하기엔 양이 많아, 요즘은 강한 모델을 심판으로 세워 자동 채점하는 방식(LLM-as-a-judge)이 널리 쓰인다. 특히 충실성 평가는 할루시네이션을 잡는 최전선이다. 답의 각 문장이 근거 청크로 뒷받침되는지 하나씩 대조하는 식으로 재면, 근거를 벗어난 생성이 얼마나 섞였는지 수치로 드러난다.
평가를 붙일 때 흔히 저지르는 실수는 골든 데이터셋 없이 시작하는 것이다. 최소 수십 개라도 '질문–정답 근거–모범 답변' 세트를 손으로 만들어 두면, 이후 모든 개선이 이 기준선과의 비교로 정리된다. 처음엔 번거롭지만, 이 투자가 없으면 RAG 개선은 감에 의존하는 삽질로 전락한다.
임베딩만으로는 놓치는 것 — 하이브리드 검색과 밀도·희소의 결합
의미 기반 벡터 검색은 강력하지만 만능이 아니다. 임베딩은 문장의 뜻을 잘 잡는 대신, 정확히 일치해야 하는 고유명사·제품 코드·오탈자·숫자에는 약하다. 예컨대 'ERR-4092 오류'라는 정확한 코드로 검색할 때, 임베딩은 '오류 처리'라는 의미가 비슷한 엉뚱한 문서를 끌어올리곤 한다. 이럴 땐 단어의 표면형을 그대로 맞추는 전통적 키워드 검색이 훨씬 정확하다.
그래서 실무에서는 두 방식을 함께 쓰는 하이브리드 검색이 표준으로 자리 잡았다. 의미를 잡는 밀집 벡터(dense) 검색과, 단어 빈도에 기반한 희소(sparse) 검색인 BM25를 나란히 돌린 뒤 결과를 합친다. 합치는 대표적 방법이 상호 순위 융합(RRF)이다. 각 검색 결과에서 문서의 순위를 역수로 환산해 더하는 단순한 방식인데, 서로 척도가 다른 두 점수를 억지로 정규화하지 않고도 안정적으로 통합돼 널리 쓰인다.
여기에 메타데이터 필터링을 얹으면 검색이 한층 정교해진다. 문서마다 작성일, 부서, 문서 종류 같은 속성을 붙여 두고, 검색 시 '2024년 이후 문서만' 같은 조건을 먼저 건 다음 벡터·키워드 검색을 돌리는 식이다. 지식의 유통기한 문제를 완화하는 데도 이 필터가 요긴하다. 오래된 규정 문서가 최신 답을 오염시키는 사고를 필터 하나로 막을 수 있다.
하이브리드 구성은 공짜가 아니다. 인덱스를 두 벌 관리해야 하고, 융합 가중치나 필터 조건을 튜닝하는 손이 더 든다. 그래도 정확한 매칭이 중요한 도메인, 이를테면 기술 지원이나 계약 검토에서는 순수 벡터 검색보다 하이브리드가 재현율을 눈에 띄게 끌어올린다. 어떤 질문이 들어오는지 실제 로그를 보고, 키워드 매칭이 자주 필요하다면 하이브리드로 넘어갈 때가 된 것이다.
긴 맥락 모델이 나오면 RAG는 필요 없어지나
맥락 창이 수십만 토큰까지 늘어난 모델이 등장하면서, '문서를 통째로 넣으면 검색이 필요 없지 않냐'는 물음이 자주 나온다. 실제로 짧은 문서 몇 개를 다루는 일이라면 통째로 넣는 편이 파이프라인도 단순하고 맥락 손실도 없다. 하지만 이 논리는 데이터 규모가 커지는 순간 무너진다. 기업의 문서 저장소는 흔히 수십만, 수백만 페이지에 이른다. 아무리 맥락 창이 넓어도 이 전부를 매 질문마다 밀어 넣을 수는 없다.
비용과 지연도 무시할 수 없는 벽이다. 대부분의 모델은 입력 토큰 수에 비례해 요금을 매긴다. 매 질문에 20만 토큰을 넣으면, 정작 답에 필요한 근거는 그중 몇백 토큰뿐인데도 나머지 방대한 무관 정보에 대한 처리 비용을 고스란히 문다. 응답도 느려진다. RAG는 검색으로 필요한 조각만 추려 넣어, 이 비용과 지연을 근본적으로 낮춘다. 즉 긴 맥락은 '넣을 수 있느냐'의 문제를, RAG는 '넣을 가치가 있느냐'의 문제를 푼다.
품질 측면에서도 둘은 대립이 아니라 보완이다. 앞서 말한 중간 소실 현상 탓에, 맥락이 길어질수록 모델이 특정 정보를 놓칠 위험은 오히려 커진다. 관련 없는 내용이 잔뜩 섞이면 잡음이 늘어 답이 흐려지기도 한다. 검색으로 정말 필요한 근거만 골라 넣으면 신호 대 잡음 비가 좋아져, 긴 맥락 모델이라도 답이 더 정확해지는 경우가 많다.
정리하면, 긴 맥락 모델은 RAG를 대체하기보다 RAG의 접합부를 여유롭게 만든다. 예전엔 청크 수를 빡빡하게 줄여야 했지만, 이제는 재순위 상위 몇십 개를 넉넉히 넣고 모델이 그 안에서 걸러 쓰게 할 여지가 생겼다. 또한 최신 정보 반영, 출처 추적, 접근 권한 통제 같은 요구는 맥락 창 크기와 무관하게 검색 계층이 있어야 풀린다. 두 기술은 각자의 자리에서 서로를 떠받친다.
더 깊이 파고들려면 — 이어지는 개념들
RAG의 뿌리를 보려면 2020년의 원 논문 'Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks'를 읽어 볼 만하다. 검색기를 밀도 높은 벡터로 구성한 DPR(Dense Passage Retrieval), 검색을 사전학습 단계부터 결합한 REALM은 RAG 이전과 이후를 잇는 중요한 이정표다. 이 세 편을 함께 보면 '검색을 학습에 어떻게 녹여 왔는가'라는 흐름이 잡힌다.
실무 감각을 키우려면 맥락 활용의 한계를 다룬 'Lost in the Middle'과, 문장 임베딩의 기본을 세운 Sentence-BERT를 권한다. 앞의 것은 문서를 프롬프트 어디에 놓아야 하는지에 대한 직관을 주고, 뒤의 것은 의미 검색이 왜 통하는지를 설명한다. 키워드 검색의 고전 BM25도 하이브리드 검색을 설계할 때 반드시 알아 둬야 한다.
개념적으로는 임베딩, 토큰화, 어텐션 같은 LLM의 기본기와, 온도·top-p·top-k 같은 디코딩 파라미터를 함께 익히면 RAG의 각 단계가 왜 그렇게 설계됐는지 이해가 깊어진다. 나아가 파인튜닝과 RAG의 차이, 그리고 검색과 추론을 번갈아 수행하는 에이전트형 구성으로 시야를 넓히면, 할루시네이션을 관리하며 LLM을 실무에 안착시키는 큰 그림이 완성된다.