책에 포함된 노트딥러닝의 감각 — 신경망에서 파운데이션 모델까지, AI를 끝까지 이해하는 가장 현실적인 지도

RAG: 검색으로 생성 모델 보강하기

2026-05-01Views 32약 9분생성형 AI 활용

생성형 AI를 처음 써본 사람은 종종 같은 놀라움을 두 번 경험한다. 첫 번째는 "와, 정말 그럴듯하게 말하네"라는 놀라움이다. 두 번째는 그보다 조금 덜 즐거운 놀라움이다. "아니, 왜 이렇게 자신 있게 틀리지?"

이 두 번째 놀라움이 바로 RAG를 이해해야 하는 이유다. LLM은 문장을 아주 잘 만든다. 하지만 문장을 잘 만든다는 것과, 지금 필요한 사실을 정확히 알고 있다는 것은 같은 말이 아니다. RAG는 이 간극을 메우는 설계다. 모델을 더 크게 만드는 대신, 필요한 순간에 바깥에서 더 잘 찾아오게 만드는 전략이라고 생각하면 된다.¹

RAG: 검색으로 생성 모델 보강하기

LLM은 왜 환각을 일으킬까

먼저 오해부터 풀자. LLM은 머릿속에 작은 백과사전을 넣고 그 책장을 뒤적이며 답하는 존재가 아니다. 모델이 아는 것은 파라메트릭 지식, 즉 학습 과정에서 가중치 안에 압축된 통계적 패턴이다. 쉽게 말해, 문장을 외우고 있는 것이 아니라 "이런 질문 뒤에는 이런 말이 그럴듯하게 이어질 확률이 높다"는 감각을 매우 정교하게 익힌 것이다.²

그래서 모델은 어떤 사실을 "조회"하기보다, 다음 토큰을 확률적으로 생성한다. 이 방식은 엄청난 장점이 있다. 요약도 하고, 설명도 하고, 문체도 바꾸고, 비유도 만든다. 하지만 동시에 약점도 분명하다. 최신 정보, 사내 문서, 비공개 정책, 방금 바뀐 가격표처럼 학습 가중치 바깥에 있는 정보는 원칙적으로 확실히 알 수 없다. 그런데도 모델은 침묵하는 대신, 가장 그럴듯한 문장을 이어 붙이려는 경향이 있다. 그 결과가 환각이다.¹²

예를 들어 회사 내부 복지 규정을 묻는다고 해보자. 모델은 "보통 회사는 이런 식으로 운영하겠지"라는 일반 패턴을 바탕으로 멀쩡한 답변을 만들 수 있다. 문제는 그 답이 당신 회사 규정과 다를 수 있다는 점이다. 말은 매끈한데 근거는 없다. 이때 필요한 것은 모델의 상상력이 아니라, 문서함에서 정확한 파일을 꺼내오는 능력이다.

RAG는 무엇을 바꾸는가

RAG는 Retrieval-Augmented Generation의 약자다. 이름 그대로 검색과 생성을 결합한다. 사용자의 질문이 들어오면 먼저 외부 지식베이스에서 관련 자료를 찾고, 그 자료를 질문과 함께 모델의 입력에 넣어 답을 생성하게 만든다. 즉, 모델의 가중치를 바꾸는 것이 아니라, 추론 시점의 컨텍스트를 바꾼다.¹²

이 차이는 실무에서 아주 크다. 정책 문서가 바뀌었을 때 모델을 다시 학습시킬 필요가 없다. 인덱스만 갱신하면 된다. 사내 문서처럼 비공개 데이터도 모델 안에 영구히 녹여 넣지 않고, 권한에 맞는 범위에서만 검색해 보여줄 수 있다. 답변에 어떤 문서가 근거가 되었는지도 추적하기 쉬워진다.²³

그래서 RAG를 한 문장으로 줄이면 이렇게 말할 수 있다.

LLM을 닫힌 책 시험에서 열린 책 시험으로 바꾸는 방법.

물론 열린 책 시험이라고 해서 자동으로 만점이 나오는 것은 아니다. 책장에서 엉뚱한 책을 꺼내오면, 오히려 틀린 답을 더 자신 있게 적을 수도 있다. 그래서 RAG의 핵심은 생성보다 검색 품질에 있다.

RAG 파이프라인은 어떻게 흘러가는가

RAG 시스템은 보통 두 단계로 나뉜다. 하나는 미리 문서를 준비하는 단계이고, 다른 하나는 질문이 들어왔을 때 답하는 단계다.³

문서를 준비하는 단계에서는 먼저 자료를 모은다. PDF, 위키, 정책 문서, 고객 응대 기록, 데이터베이스 텍스트, API 응답 등 무엇이든 대상이 될 수 있다. 그다음 문서를 정리하고, 적절한 단위로 나누고, 임베딩을 만들어 인덱스에 저장한다. 이 작업이 허술하면 뒤가 모두 흔들린다. 표가 깨진 PDF, 잘못 읽힌 OCR, 제목이 잘린 문단, 버전이 섞인 문서가 들어가면 검색이 아무리 좋아도 출발부터 삐끗한다.²³

질문이 들어오면 이제 질의 처리 단계가 시작된다. 사용자의 질문을 그대로 쓰기도 하지만, 경우에 따라 검색 친화적으로 다시 쓰거나 여러 하위 질문으로 나누기도 한다. 그런 다음 관련 청크를 검색하고, 필요하면 재랭킹한 뒤, 정말 필요한 정보만 추려 프롬프트에 넣는다. 마지막으로 LLM이 이 문맥을 바탕으로 답을 생성한다.³⁴

그 흐름을 단순하게 그리면 이렇다.

문서 수집과 정제
문서 분할과 임베딩
인덱싱
사용자 질문 입력
검색과 재랭킹
컨텍스트 구성
답변 생성과 출처 제시

겉으로 보기엔 단순하지만, 실제 성능은 이 단계들 사이의 연결에서 갈린다. 많은 팀이 "LLM이 별로다"라고 생각하지만, 뜯어보면 문제는 거의 늘 다른 곳에 있다. 문서를 잘못 나눴거나, 검색이 엉뚱한 후보를 가져왔거나, 너무 많은 문맥을 넣어 모델을 헷갈리게 만든 경우가 많다.⁴

청킹은 작게 자르는 일이 아니라, 잘 자르는 일이다

RAG를 처음 만들 때 가장 과소평가되는 부분이 청킹이다. 긴 문서를 적당한 크기의 조각으로 나누는 일인데, 이게 생각보다 훨씬 중요하다. 너무 크게 자르면 하나의 청크 안에 여러 주제가 섞여서 벡터 의미가 흐려진다. 너무 작게 자르면 검색은 잘 되는 것 같아도, 막상 읽어보면 문맥이 잘려 답변에 쓸 수 없다.⁶

예를 들어 취소 정책이 이렇게 적혀 있다고 해보자. 첫 문단에는 "유료 구독은 월 단위로 갱신된다"가 있고, 다음 문단에는 "결제 후 7일 이내에는 환불 가능하다"가 있다. 이 둘이 각각 다른 청크로 갈라졌는데 사용자가 "구독 취소와 환불 규정이 어떻게 되나요?"라고 묻는다면, 검색은 둘 중 하나만 건질 수 있다. 반대로 다섯 페이지를 통째로 한 청크로 묶으면, 취소 정책 말고도 가격, 기능, 마케팅 문구가 한 덩어리로 들어가서 검색 정밀도가 떨어진다.

실무에서는 보통 256~512 토큰, 혹은 512 토큰 안팎에서 시작해 본다. 여기에 10~20% 정도의 오버랩을 줘 경계에서 정보가 끊기지 않게 하는 경우가 많다. 다만 이것은 어디까지나 출발점일 뿐이다. 계약서는 조항 단위가 낫고, 코드는 함수나 클래스 단위가 낫고, 제품 문서는 제목-본문 구조를 살리는 편이 낫다. 정답은 문서 종류와 질문 유형이 함께 결정한다.⁶⁷

좋은 청킹을 한 문장으로 요약하면 이렇다.

검색할 때는 작고 날카롭게, 읽힐 때는 충분히 완전하게.

그래서 최근에는 작은 자식 청크로 검색한 뒤, 실제 생성 단계에서는 주변의 더 큰 부모 청크를 함께 넣는 방식도 자주 쓴다. 찾을 때의 정밀도와 읽힐 때의 문맥을 분리하는 셈이다.⁶

검색은 한 번에 끝나지 않는다

많은 입문용 예제는 질문을 임베딩으로 바꿔서 벡터 검색만 한 뒤, 상위 몇 개 청크를 그대로 모델에 넣는다. 데모에서는 꽤 그럴듯하다. 하지만 현실 문서는 그렇게 친절하지 않다.

사용자는 "구독 해지"라고 묻고, 문서에는 "계정 종료 정책"이라고 적혀 있을 수 있다. 반대로 사용자는 정확한 에러 코드나 제품명처럼 키워드 일치가 꼭 필요한 질문을 던질 수도 있다. 이 때문에 실무에서는 의미 검색과 키워드 검색을 함께 쓰는 하이브리드 검색이 강력하다. 임베딩은 뜻이 비슷한 표현을 잡아내고, BM25 같은 전통 검색은 정확한 용어를 놓치지 않는다. 그 결과를 RRF 같은 방식으로 합쳐서 후보를 모으면 한쪽의 약점을 다른 쪽이 보완할 수 있다.⁸

그다음 많이 붙는 단계가 재랭킹이다. 첫 검색은 넓게 후보를 모으는 단계다. 여기서는 빠름이 중요하다. 하지만 최종적으로 LLM에게 넘길 문서는 아주 정확해야 한다. 그래서 상위 20개나 50개를 먼저 모은 뒤, 더 정교한 재랭커가 원래 질문과 각 문서를 함께 읽고 점수를 다시 매긴다. 이때 자주 쓰이는 것이 크로스 인코더다. 질의와 문서를 따로 압축해 비교하는 바이인코더보다 느리지만, 둘을 함께 읽기 때문에 세밀한 관련성을 더 잘 판단한다.⁵

쉽게 비유하면 이렇다. 첫 검색은 사서가 "관련 있을 법한 책 더미"를 수레째 끌고 오는 단계다. 재랭킹은 그 더미를 책상 위에 올려놓고, 정말 지금 질문에 답이 될 책을 순서대로 다시 세우는 단계다.

답변 품질은 검색 수보다 문맥의 질에 달려 있다

RAG를 만들다 보면 초보자는 종종 이런 유혹에 빠진다. "잘 모르겠으면 많이 넣자." 하지만 컨텍스트는 많다고 무조건 좋은 것이 아니다. 관련 없는 청크가 섞이면 오히려 핵심 신호가 흐려진다. 이를 문맥 오염, 혹은 컨텍스트 윈도 오염이라고 볼 수 있다.⁴

상상해 보자. 사용자는 환불 규정을 묻고 있는데 프롬프트 안에는 환불 정책 두 조각, 결제 수단 소개 세 조각, 이벤트 공지 두 조각, 오래된 버전 문서 한 조각이 함께 들어 있다. 모델은 그 안에서 평균을 내듯 답을 만든다. 그러면 맞는 말과 틀린 말이 이상하게 섞인, 어딘가 미끄러운 답변이 나온다.

그래서 중요한 것은 top-k를 크게 잡는 것이 아니라, LLM에게 들어가는 최종 문맥이 얼마나 깨끗한가다. 보통은 넓게 검색하고, 좁게 전달하는 편이 낫다. 질문과 직접 관련된 3~5개 청크가, 애매한 15개 청크보다 훨씬 유용한 경우가 많다.²⁴

컨텍스트를 구성할 때는 순서도 중요하다. 핵심 근거를 앞쪽에 두고, 출처와 섹션 정보를 함께 넣고, 중복 청크를 제거하는 편이 좋다. 또 프롬프트에 "주어진 문서에서 근거를 찾을 수 없으면 모른다고 말하라"는 규칙을 명시해야 한다. 검색 시스템은 대개 무언가를 항상 반환하기 때문에, 찾은 것과 답이 되는 것은 다를 수 있다.²

RAG는 왜 자주 실패할까

RAG가 실패하는 장면은 놀랄 만큼 비슷하다. 모델이 아주 유창하게, 틀린 문서를 근거로, 틀린 답을 말한다. 이 실패를 크게 세 갈래로 보면 이해하기 쉽다.

첫째는 데이터 품질 문제다. 문서가 낡았거나, OCR이 깨졌거나, 표가 본문처럼 이어 붙었거나, 같은 정책의 서로 다른 버전이 섞여 있으면 검색이 올바른 근거를 찾기 어렵다. RAG는 없는 사실을 만들어내기 전에, 먼저 엉망인 저장소를 뒤진다. 그러니 지식베이스 자체가 탁하면 결과도 탁해진다.²³

둘째는 검색 미스매치다. 사용자의 표현과 문서 표현이 다를 수 있고, 정확한 용어가 필요한 질문일 수도 있고, 하나의 질문이 사실 여러 단계를 거쳐야 풀리는 질문일 수도 있다. 더 까다로운 경우도 있다. 임베딩 검색은 뜻이 비슷한 문장을 잘 묶지만, 문장 구조의 미세한 차이를 놓칠 때가 있다. "A가 B를 금지한다"와 "A가 B를 허용한다"처럼 단어는 비슷하지만 의미는 반대인 경우, 단일 벡터 기반 검색이 헷갈릴 수 있다.⁹

셋째는 컨텍스트 오염이다. 검색 결과에 근접하지만 불필요한 조각이 많이 포함되거나, 서로 충돌하는 문서가 함께 들어오거나, 너무 많은 청크를 억지로 넣는 경우다. 이때 모델은 잘못된 문맥까지 그럴듯하게 봉합해 버린다. 그래서 RAG 실패는 종종 "생성 실패"처럼 보이지만, 실제로는 검색과 컨텍스트 구성 실패인 경우가 더 많다.⁴

좋은 RAG는 답을 잘하는 시스템이 아니라, 근거를 잘 다루는 시스템이다

RAG를 잘 만든다는 것은 단순히 챗봇을 똑똑하게 보이게 하는 일이 아니다. 그보다 더 중요한 목표는 답변이 어디서 왔는지 추적 가능하게 만드는 것이다. 어느 문서를 찾았는지, 왜 그 문서를 상위에 올렸는지, 최종 답에 어떤 근거가 들어갔는지를 알 수 있어야 한다.²³

이 감각은 매우 중요하다. 순수 LLM만 쓸 때는 모델의 머릿속을 추정해야 한다. 하지만 RAG에서는 적어도 "무슨 자료를 읽고 이렇게 말했는가"를 볼 수 있다. 즉, 완전한 해석 가능성은 아니더라도, 실무적으로 훨씬 감사 가능하고 수정 가능한 시스템이 된다.

그래서 좋은 RAG 팀은 모델 프롬프트만 붙잡고 있지 않는다. 문서 수집 파이프라인을 다듬고, 청킹 규칙을 실험하고, 검색 로그를 분석하고, 재랭커를 조정하고, 실패한 질문 세트를 따로 모아 반복 측정한다. 겉보기엔 챗봇 프로젝트 같지만, 실제로는 검색 시스템과 지식 시스템을 함께 설계하는 일에 가깝다.

RAG와 파인튜닝은 무엇이 다를까

이쯤에서 자연스럽게 다음 질문이 나온다. "그렇다면 정보를 더 잘 넣고 싶을 때는 RAG를 써야 할까, 파인튜닝을 해야 할까?"

핵심만 먼저 말하면, RAG는 사실과 근거를 바깥에서 가져오는 기술이고, 파인튜닝은 행동 방식과 답변 습관을 조정하는 기술에 가깝다. 자주 바뀌는 문서, 비공개 지식, 출처 제시가 필요한 업무는 RAG가 유리하다. 반대로 말투, 출력 형식, 특정 절차를 따르는 방식처럼 모델의 응답 스타일을 안정화하고 싶다면 파인튜닝이 더 맞을 수 있다.²

실전에서는 둘이 경쟁 관계라기보다 역할 분담 관계에 가깝다. 무엇을 기억시킬 것인가보다, 무엇을 그때그때 찾아오게 할 것인가를 먼저 구분하는 편이 좋다.