나무모에 미러 (일반/밝은 화면)
최근 수정 시각 : 2025-10-24 18:03:57

검색증강생성

RAG에서 넘어옴


1. 개요2. 배경
2.1. LLM의 컷오프 문제2.2. 초기 해결 시도의 실패2.3. RAG의 등장
3. 작동 방식
3.1. 전체 흐름3.2. 검색 단계의 핵심3.3. 생성 단계의 핵심
4. 장점
4.1. 시간적 제약의 극복4.2. 부족한 지식 벌충4.3. 출처 투명성
5. 단점
5.1. 지식과 능력의 간극5.2. 외국어 번역 품질 문제5.3. 외부 의존성5.4. 창의성 감퇴
6. 실제 적용 사례
6.1. 검색 엔진 통합6.2. 전용 RAG 서비스6.3. 기업용 솔루션

1. 개요

검색증강생성, RAG(Retrieval-Augmented Generation)는 대규모 언어 모델(LLM)이 답변을 생성하기 전에 외부 지식 베이스에서 관련 정보를 검색하여 활용하도록 하는 기술이다. 쉽게 말하면, 모델이 모르는 것을 백과사전에서 찾아본 후 자기 말로 설명하는 것과 유사하다.

RAG 기술은 Facebook AI Research(FAIR)에서 개발되었으며, 2020년 발표된 논문 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」에서 처음 제안되었다.# 이후 정보 검색, 지식 기반 질의응답, 문서 요약 등 다양한 자연어 처리 연구 분야에서 주목받고 있다.

2. 배경

2.1. LLM의 컷오프 문제

대규모 언어 모델의 가장 고질적인 문제는 학습 종료 시점(cutoff) 이후의 정보를 알 수 없다는 것이다. 2025년 1월에 학습이 끝난 모델은 2025년 10월의 정보는 알지 못한다. 현대 사회에서 몇개월의 차이는 매우 크다. 선거 결과, 기업 실적, 기술 동향, 심지어 유행어까지 끊임없이 변한다. 사용자가 '최근' 정보를 물으면 모델은 낡은 답을 하거나, 아예 모른다고 인정하거나, 최악의 경우 지어낸 정보를 제공한다.

이 컷오프 문제는 LLM이 등장한 순간부터 지금까지 해결되지 않은 근본적 한계다. 사용자들은 "이 정보는 2024년 1월 기준입니다"라는 단서를 보면서 최신 정보를 얻지 못하는 것에 불만을 토로해왔다. 학습 데이터에 포함되지 않은 특수 분야 지식이나 기업 내부 문서 같은 정보 역시 LLM이 답할 수 없는 영역이었다.

2.2. 초기 해결 시도의 실패

컷오프 문제를 해결하기 위한 여러 시도가 있었으나, 각각 한계가 명확했다.

2.3. RAG의 등장

Facebook AI Research는 2020년 논문에서 RAG를 제안했다. 핵심 아이디어는 검색의 체계화였다. 단순히 키워드를 검색엔진에 던지는 것이 아니라, 다음과 같은 과정을 자동화하고 통합했다.
1. 사용자 질문을 분석하여 적절한 검색어를 생성
1. 관련 문서를 검색하고 관련도에 따라 순위화
1. 검색된 정보를 컨텍스트로 활용하여 답변 생성

이 모든 과정을 통합적으로 자동화하여, 사용자는 그냥 질문하면 되고, 시스템이 알아서 필요하면 검색하고 답한다. 초기 검색 Tool의 단순무식함을 넘어서는 정교한 통합이었다. 이후 RAG는 Perplexity, Microsoft Copilot, ChatGPT 웹 브라우징 기능 등 다양한 실제 서비스에 적용되며 LLM의 한계를 보완하는 핵심 기술로 자리잡았다.

3. 작동 방식

RAG의 작동 원리는 사람이 모르는 것을 백과사전에서 찾아본 후 자기 말로 설명하는 것과 유사하다. 사용자가 질문하면, 시스템은 먼저 관련 정보를 검색한 다음, 그 정보를 바탕으로 답변을 생성한다. 이 과정은 검색(Retrieval)과 생성(Generation)이라는 두 단계가 자동으로 연결되어 작동한다. 전통적인 LLM이 자신의 학습 데이터에만 의존하여 답변했다면, RAG는 필요할 때마다 외부 지식을 실시간으로 참조하여 더욱 정확하고 최신의 정보를 제공할 수 있다.

3.1. 전체 흐름

RAG 시스템은 4단계로 작동한다. 각 단계는 유기적으로 연결되어 있으며, 한 단계의 성공 여부가 다음 단계의 품질을 결정한다.

3.2. 검색 단계의 핵심

검색 단계의 가장 큰 문제는 키워드 매칭만으로는 의미적 관련성을 포착할 수 없다는 점이다. 전통적인 검색 엔진은 질문에 포함된 단어가 문서에 있는지를 찾는 방식이었다. 예를 들어 "자동차가 고장났어요"라는 질문에는 "자동차" 또는 "고장"이라는 단어가 포함된 문서만 검색했다. 이 방식의 문제점은 "차량 수리 방법"이라는 문서를 찾지 못한다는 것이다. "자동차"와 "차량"이 같은 의미임을 이해하지 못했기 때문이다.

더 심각한 문제는 동음이의어나 다의어를 구분하지 못한다는 점이다. "사과"라는 단어로 검색하면 과일 사과와 용서를 구하는 행위인 사과가 섞여서 나온다. "배"로 검색하면 과일, 신체 부위, 교통수단이 모두 검색된다. 맥락을 이해하지 못하는 키워드 검색의 근본적 한계였다.

RAG는 이를 벡터 임베딩(vector embedding)으로 해결한다. 텍스트를 고차원 공간의 점으로 표현하여, 의미가 비슷한 텍스트들은 공간상에서 가까운 위치에 놓이게 만든다. 이는 수백 차원에서 수천 차원의 벡터 공간에서 이루어지며, 각 차원은 언어의 특정 의미적 특성을 나타낸다. 예를 들어 어떤 차원은 "교통수단"의 의미를, 다른 차원은 "과일"의 의미를 포착할 수 있다.

이렇게 하면 표현이 다르더라도 의미가 같으면 관련 있다고 판단할 수 있다. "파리 여행"과 "프랑스 수도 관광"은 겹치는 단어가 없지만, 의미적으로 연결되어 벡터 공간에서 가까운 위치에 놓인다. "자동차 고장"과 "차량 수리"도 마찬가지다. 심지어 언어가 달라도 의미가 같으면 가까운 벡터를 가질 수 있다. 다국어 임베딩 모델을 사용하면 "car"와 "자동차"가 유사한 벡터로 표현된다.

다만 이 과정의 품질은 임베딩 모델의 성능에 크게 달려있다. 모델이 언어의 의미를 얼마나 정확하게 수치화할 수 있는가에 따라 검색 정확도가 결정된다. 특히 전문 분야나 비영어권 언어에서는 임베딩 품질이 떨어지는 경우가 많다. 일반적인 영어 텍스트로 학습된 임베딩 모델은 의학 용어나 법률 용어의 미묘한 차이를 잘 포착하지 못할 수 있다. 한국어 같은 비영어권 언어는 학습 데이터 자체가 부족하여 임베딩 품질이 영어보다 낮은 경우가 흔하다.

또한 검색 대상이 되는 문서들을 어떤 크기로 분할하는가(청킹, chunking) 역시 결과에 영향을 준다. 문서를 너무 작은 단위로 쪼개면 문맥 정보가 손실되어 의미 파악이 어려워진다. 반대로 너무 큰 단위로 유지하면 관련 없는 정보가 많이 섞여서 생성 단계의 부담이 커진다. 대부분의 RAG 시스템은 200~500 토큰(대략 150~400 단어) 정도의 청크를 사용하지만, 이는 문서의 특성과 사용 목적에 따라 달라진다.

3.3. 생성 단계의 핵심

생성 단계의 핵심 과제는 검색 결과를 단순히 복사하는 것이 아니라, 질문에 맞게 재구성해야 한다는 점이다. 검색된 문서는 질문과 관련은 있지만, 사용자가 원하는 형태로 작성되어 있지는 않다. 예를 들어 "파리의 인구는 얼마인가?"라는 질문에 대해 검색된 문서에는 "파리 광역권은 약 1,200만 명이 거주하는 프랑스 최대 도시권이며, 파리시 자체의 인구는 약 220만 명이다"라고 적혀 있을 수 있다.

이 경우 모델은 여러 판단을 해야 한다. 첫째, 사용자가 묻는 "파리"가 파리시를 의미하는가, 파리 광역권을 의미하는가? 문맥상 대부분의 사용자는 파리시를 묻지만, 일부는 광역권을 의미할 수 있다. 둘째, 두 숫자를 모두 제시할 것인가, 하나만 제시할 것인가? 셋째, "약"이라는 표현을 유지할 것인가, "약 220만 명" vs "220만 명"의 차이를 어떻게 다룰 것인가?

이런 판단은 단순한 정보 추출이 아니라 이해와 분석을 요구한다. 생성 모델은 검색 결과의 의미를 파악하고, 질문의 의도를 해석하며, 두 가지를 조합하여 적절한 답변을 구성해야 한다.

더 복잡한 상황은 검색 결과가 여러 개이고 서로 상충되는 정보를 담고 있을 때다. "커피가 건강에 좋은가?"라는 질문에 대해 한 문서는 "커피는 항산화 물질이 풍부하여 심혈관 질환 예방에 도움이 된다"고 하고, 다른 문서는 "과도한 카페인 섭취는 불안감과 수면 장애를 유발할 수 있다"고 말할 수 있다. 모델은 이 두 정보가 모순되는 것이 아니라 서로 다른 측면을 다루고 있음을 이해하고, "적정량의 커피는 건강에 이로운 측면이 있지만, 과다 섭취는 부작용을 일으킬 수 있다"는 식으로 균형잡힌 답변을 생성해야 한다.

이 과정에서 모델의 기본 능력이 결정적이다. 모델이 검색 결과의 의미를 올바르게 파악하지 못하면, 정확한 정보를 가져와도 틀린 답변을 생성할 수 있다. 예를 들어 2025년 출시된 GPT-5는 UNCURK의 문제점을 찾아보라 할 때 이승만과 박정희 정권을 추인했다는 사실을 응답에 빼먹고 엉뚱한 냉전 구도만 이야기하는 편이다. 이는 RAG가 단순히 검색 기능만 추가한다고 해결되는 것이 아니라, 모델 자체의 이해력과 판단력이 뒷받침되어야 함을 보여준다.

또한 검색 결과의 품질이 최종 답변의 품질을 좌우한다는 근본적 한계가 있다. 아무리 생성 모델이 뛰어나더라도, 검색 단계에서 잘못된 정보나 관련 없는 정보를 가져오면 올바른 답변을 생성할 수 없다. 쓰레기가 들어가면 쓰레기가 나온다는 컴퓨팅의 오랜 격언이 RAG에도 그대로 적용된다. 이것이 RAG가 "외부 의존성"이라는 태생적 약점을 갖는 이유다. 검색 데이터베이스의 품질, 검색 알고리즘의 정확성, 그리고 원본 문서의 신뢰성이 모두 최종 결과에 영향을 준다.

마지막으로, 생성 단계에서는 환각(hallucination) 문제가 여전히 존재할 수 있다. RAG가 환각을 완전히 제거하지는 못한다. 모델이 검색 결과를 무시하고 자신의 학습 데이터나 잘못된 추론에 기반하여 정보를 지어낼 수 있기 때문이다. 특히 검색 결과가 불완전하거나 애매할 때, 모델은 그 빈틈을 자신의 "상상"으로 채우려는 경향이 있다. 이를 방지하려면 생성 프롬프트에서 "반드시 제공된 문서의 정보만을 사용하여 답변하고, 확실하지 않으면 모른다고 말하라"는 지시를 명확히 해야 한다. 하지만 이것도 완벽한 해결책은 아니며, 모델의 근본적인 언어 이해 능력과 지시 준수 능력에 달려있다.

4. 장점

4.1. 시간적 제약의 극복

RAG의 가장 명확한 장점은 모델의 학습 cutoff 이후의 정보에 접근할 수 있다는 것이다. 2025년 1월에 학습이 끝난 모델이라도, RAG를 통해 10월의 최신 뉴스나 데이터를 검색하여 답변할 수 있다. 이는 RAG 없이는 불가능한 기능이다.

이 장점은 시간에 민감한 정보를 다룰 때 특히 중요하다. 주식 시장 동향, 최신 연구 결과, 정치 상황, 날씨 정보 등은 매일 또는 매시간 변하므로, 모델의 학습 데이터만으로는 답변할 수 없다. RAG는 이런 정보를 실시간으로 검색하여 제공함으로써 LLM의 실용성을 크게 높인다.

예를 들어 "오늘 서울 날씨는?"이라는 질문에 학습 데이터만 있는 모델은 "2025년 1월 이후의 정보는 알 수 없습니다"라고 답할 수밖에 없다. 반면 RAG를 사용하는 시스템은 기상청 웹사이트를 검색하여 "오늘 서울은 맑고 최고기온 15도입니다"라고 정확하게 답변할 수 있다.

다만 검색어를 제대로 생성할 능력은 여전히 필요하다. 모델이 "오늘 서울 날씨"를 "서울 기후 특성"으로 잘못 이해하면, 일반적인 기후 정보만 검색하여 오늘의 날씨를 알려주지 못한다. 또한 LLM은 별도의 Tool이나 시스템 프롬프트 없이는 오늘 날짜를 알지 못하는데, 따라서 오늘 날짜를 오인하여 미래나 과거의 날씨를 검색할 가능성도 충분하다. 따라서 이 장점도 모델의 기본 이해력에 어느 정도 달려있지만, 다른 장점들에 비하면 가장 확실한 편이다.

4.2. 부족한 지식 벌충

RAG는 모델이 학습하지 못한 특정 정보를 검색으로 보완할 수 있다. 이는 학습 데이터에 포함되지 않은 전문 분야 지식, 기업 내부 문서, 특정 커뮤니티의 정보 등을 활용할 수 있게 한다.

예를 들어 일본 애니메이션에 대한 정보가 부족한 모델이라도, RAG를 통해 애니메이션 데이터베이스를 검색하여 "이 작품의 감독은 누구인가?", "이 캐릭터의 성우는?" 같은 질문에 답할 수 있다. 마찬가지로 특정 기업의 내부 정책이나 제품 사양서 같은 정보도, 해당 문서들을 벡터 데이터베이스에 저장해두면 RAG를 통해 접근할 수 있다.

이것의 핵심은 선택적 보완이다. 모델이 잘 아는 일반적인 질문에는 학습 데이터만으로 답하고, 모르는 특수한 질문에는 검색을 통해 보완한다. 이론적으로는 매우 효율적인 방식이다.

문제는 모델이 "자기가 모른다는 것을 알 정도로" 똑똑해야 한다는 점이다. 멍청한 모델은 모르는데도 아는 척하거나(환각), 검색해야 할 타이밍을 판단하지 못한다. 또한 검색된 정보를 제대로 이해하지 못하면, 좋은 자료를 가져와도 활용하지 못하거나 잘못 해석한다. 따라서 이 장점은 모델의 메타인지 능력과 이해력에 크게 달려있다.

4.3. 출처 투명성

RAG 시스템은 답변과 함께 참고한 문서의 출처를 제시할 수 있다. 이는 사용자가 정보의 근거를 직접 확인할 수 있게 하여 투명성을 높인다. Perplexity 같은 서비스는 각 문장마다 각주 형식으로 출처를 명시하며, Microsoft Copilot도 답변 하단에 참고 링크를 제공한다.

출처 제공의 진짜 가치는 검증 가능성이다. 사용자는 "이 정보가 정말 맞는가?"를 궁금해할 때 출처 링크를 클릭하여 원본을 확인할 수 있다. 또한 더 자세한 정보가 필요하면 원본 문서를 직접 읽을 수 있다. 이는 전통적인 LLM이 제공하지 못하던 기능이다.

다만 출처가 있다고 내용이 맞는 것은 아니다. RAG 시스템이 신뢰할 수 없는 웹사이트를 검색할 수도 있고, 검색된 정보를 잘못 해석하여 출처와 다른 내용을 답변할 수도 있다. 심지어 출처가 명시되어 있으면 사용자가 더 쉽게 믿는 경향이 있어, 잘못된 정보가 더 위험할 수도 있다.

따라서 출처 투명성은 신뢰성의 증거가 아니라 검증 가능성의 제공이다. "이 답변을 믿어도 된다"는 보증이 아니라, "직접 확인해볼 수 있다"는 수단을 주는 것이다. 검증 책임은 여전히 사용자에게 있다.

5. 단점

5.1. 지식과 능력의 간극

RAG의 가장 근본적인 한계는 검색으로 정보는 가져올 수 있지만, 그것을 이해하고 활용하는 능력까지 보충하지는 못한다는 점이다. 이는 2025년 출시된 GPT-5가 극명하게 보여준 문제다.

5.2. 외국어 번역 품질 문제

RAG는 다국어 환경에서 구조적 약점을 보인다. 특히 영어 중심으로 학습된 모델이 비영어권 쿼리를 처리할 때 심각한 품질 저하가 발생한다.

문제의 메커니즘은 다음과 같다. 영어 중심 모델이 한국어 질문을 받으면, 질문을 영어로 번역하거나 영어 키워드로 검색한다. 그 결과 영어 문서를 검색하게 되고, 이를 다시 한국어로 번역하여 제시한다. 이 과정에서 맥락과 뉘앙스가 완전히 파괴되고 한국어 문법이 제대로 반영되지도 않은[2] 괴상한 내용이 작성된다.

GPT-5 추론 모델에서 큰 문제가 되는 부분이 바로 이것이다. 한국어 질문에 대해 영어 문서를 검색한 후, 어색한 한국어로 번역하거나 아예 영어 문장의 구조 그대로 때려박아 답변한다. 그런 식의 대답은 불쾌한 골짜기와 유사한 효과를 일으킨다. 사용자가 답변의 이해를 거부하고 해당 모델을 욕하는 것이다.

결과적으로 비영어권 사용자는 부정확한 번역, 어색한 표현, 문화적 맥락 무시라는 삼중고를 겪는다. RAG가 다국어를 지원한다고 주장하지만, 실제로는 영어 중심 설계의 한계를 넘지 못한다.

5.3. 외부 의존성

RAG는 외부 지식에 의존하므로, 검색된 정보가 올바르지 않으면 부정확한 결과가 나온다. 이는 피할 수 없는 구조적 한계다.

검색 대상이 되는 데이터베이스의 품질이 최종 답변을 결정한다. 잘못된 정보, 편향된 정보, 낡은 정보가 데이터베이스에 있으면, 아무리 모델이 뛰어나도 틀린 답변을 생성한다. 인터넷은 정보의 바다인 동시에 정보의 쓰레기통이기 때문에, 웹 검색 기반 RAG는 항상 이 위험에 노출된다.

또한 검색 시스템 자체의 장애나 한계도 문제가 된다. 검색 API가 다운되면 RAG는 작동하지 않는다. 검색 속도가 느리면 답변 생성 시간이 길어져 사용자 경험이 나빠진다. 특정 사이트가 robots.txt로 크롤링을 차단하면 그 정보에는 접근할 수 없다.

이는 LLM만 사용할 때는 없던 새로운 종류의 실패 가능성을 추가한다. 전통적인 LLM은 느려도 항상 답변하지만, RAG는 검색이 실패하면 답변 자체를 생성하지 못할 수 있다.

5.4. 창의성 감퇴

RAG의 검색 기반 응답에 과도하게 의존하면 모델의 독창적 생성 능력이 저하될 수 있다. 이는 특히 창작이나 추상적 사고가 필요한 작업에서 문제가 된다.

검색은 본질적으로 기존에 존재하는 정보를 찾는 과정이다. 따라서 RAG는 사실 확인에는 강하지만, 새로운 아이디어 생성에는 약하다. 소설 쓰기, 시 창작, 가상 시나리오 상상 같은 작업은 검색할 자료가 없으므로, RAG가 도움이 되지 않는다.

더 심각한 것은 GPT-5에서 보이듯 RAG에 과도하게 의존하도록 설계된 모델은 검색 없이는 제대로 작동하지 못하는 경향을 보인다는 것이다. 창의적 질문에도 무리하게 검색을 시도하거나, 검색어 및 검색 결과를 짜맞추려다 오히려 이상한 답변을 생성하거나, 아예 검색하지 말라는 프롬프트를 거부하기도 한다.

또한 검색 결과에 얽매여 예상 밖의 관점이나 독특한 해석을 제시하지 못하는 경향도 있다. 검색된 문서들이 제시하는 주류 의견만 반복하게 되어, 모델 자체의 종합적 사고나 참신한 접근이 사라진다. 희귀한 사례를 설명하고 이에 대한 대책을 요구할 때도 통상적인 사례만 앵무새처럼 읊으며 제대로 응답하지 못하는 경향이 있다.[3] 이는 RAG가 잘못 사용되었을 때의 부작용이지만, 현실에서 자주 관찰되는 문제다.

6. 실제 적용 사례

6.1. 검색 엔진 통합

6.2. 전용 RAG 서비스

6.3. 기업용 솔루션

[1] 더 극단적으로 말하면, 야동을 검색하라면 야동이라는 키워드를 치는 수준이었다. 당연히 멍청한 소리가 나올 수 밖에 없는 구조였다.[2] 대표적으로 조사가 없다.[3] 대표적으로, BRIR같은 희귀한 음향 세팅에 관해 물어보면 제대로 응답할 가능성이 거의 없다. 전통적인 LLM으로도 제대로 응답하지 못하는 경향이 있지만, RAG가 문제를 해결할 수 없는 부분이다.

분류