RAG은 무엇일까?

RAG

RAG(Retrieval-augmented generation) 검색 증강 생성 은 비공개x또는 독점 데이터 소스의 정보를 활용하여 텍스트 생성을 보완하는 기술을 의미합니다. 이 기술은 대규모 데이터 세트 또는 지식 베이스 검색을 하도록 설계된 검색 모델과, 해당 정보를 입력받아 읽기 쉬운 텍스트 응답을 생성하는 LLM과 같은 생성 모델을 결합하여 사용됩니다.

그렇다면 이러한 RAG이 등장한 배경이 무엇일까요? 이는 LLM 의 Hallucination Response 때문입니다. LLM이 말하는 정보에 대한 신뢰할 수 있는 출처가 없는 경우가 있다는 것, 그리고 LLM이 참조하는 데이터가 최신의 데이터를 반영하지 못한다는 문제가 있습니다.

RAG 은 이러한 현상을 개선하기 위해서 등장한 아키텍처 패턴(Architectural Pattern) 이자 방법론(Methodology) 입니다. RAG을 구축하여 LLM 과 연결시키면 LLM 은 더이상 데이터를 추측하여 답변하지 않습니다. RAG 을 통해 유저가 프롬프트를 통해 요청하는 데이터를 찾아 반환하여 보다 정확한 답변을 얻을 수 있게 됩니다.

RAG

RAG을 사용하기 위해서는 Vector Database 가 필요합니다. 이러한 이유는 무엇일까요? Vector Database 는 관계형 데이터베이스(Relational Database, RDB) 와는 확연히 다른 데이터베이스입니다. 어떠한 점에서 다르고 무엇 때문에 RAG 을 구축하기 위해서 필요한지 설명해보겠습니다.

Embedding Model & Vector Database

벡터 데이터베이스에 데이터를 저장하기 위해서는 임배딩 모델(Embedding Model) 을 사용해 백터 임베딩(Vector Embedding) 을 수행하는 과정이 반드시 필요합니다. 백터 임베딩이란 단어나 이미지와 같은 비수학적 데이터를 비롯한 다양한 유형의 데이터를 머신러닝(ML) 모델에서 처리할 수 있도록 숫자의 배열로 표현하는 데이터 포인트를 수치로 표현한 것입니다.

위의 두 이미지를 살펴보겠습니다. 위의 두 이미지에서 데이터를 추출한다고 할 경우 어떠한 데이터를 추출할 수 있을까요? 숫자와 관련된 데이터가 아닌 색감이나 분위기와 같은 비수학적 데이터를 기준으로 생각해보겠습니다. 위의 이미지에서 가장 눈에 띄는 색상, 물, 산 등의 데이터를 추출했다고 가정해보겠습니다.

앞서 설명한 예시로 분위기, 색감등을 이야기한 이유는 백터 임베딩의 목적은 의미론적(Semantic) 특징을 추출하여 데이터로 변환하는 것을 목적으로 하기 때문입니다.

백터 임베딩은 단어, 텍스트, 이미지 등 컴퓨터가 직접 이해할 수 없는 비정형(비수학적) 데이터를 머신러닝 모델이 연산할 수 있도록 고차원의 숫자 배열(예: [0.24, -1.33, 0.85, ...])로 변환하뎌 백터 데이터베이스에 저장합니다.

이후 사용자가 "저녁 노을이 지는 바다 풍경 찾아줘"라고 텍스트로 검색(Query)하면, 텍스트 역시 유사한 벡터 좌표로 임베딩됩니다. 혹은 "저녁 노을이 지는 이미지를 찾아줘" 라고 검색을 수행할 경우 벡터 데이터베이스는 저장된 이미지들의 숫자 배열과 검색어의 숫자 배열 간의 거리(유사도)를 수학적으로 계산하여 가장 의미가 가까운 이미지를 결과로 반환합니다.

Prompt Augmentation

Prompt Augmentation 벡터 데이터베이스를 통해 사용자의 질문과 가장 유사한(의미가 가까운) 데이터를 검색해 냈다면, 이제 이 데이터를 LLM이 활용할 수 있도록 전달해야 합니다. 이 과정이 바로 프롬프트 증강(Prompt Augmentation)입니다.

프롬프트 증강은 사용자의 최초 질문(Query)에 벡터 데이터베이스에서 추출한 관련 정보(Context)를 결합하여, LLM에게 전달할 최종 입력값을 재구성하는 작업입니다. 단순히 사용자의 질문만 LLM에게 단독으로 전달하는 것이 아니라, 외부에서 가져온 신뢰할 수 있는 데이터를 함께 묶어 하나의 완성된 텍스트로 조립하는 데이터 전처리 과정입니다.

이 단계에서는 일반적으로 시스템 지시어(System Prompt)가 함께 포함됩니다. 예를 들어, "아래 제공된 참고 자료만을 바탕으로 사용자의 질문에 답변하고, 자료에 없는 내용은 절대 지어내지 마"와 같은 규칙을 검색된 데이터, 그리고 사용자의 원래 질문과 함께 병합합니다.

이러한 프롬프트 증강 작업을 거침으로써 글의 서두에서 언급했던 LLM의 환각(Hallucination) 현상을 효과적으로 통제할 수 있습니다. LLM은 자신의 과거 학습 데이터에 의존하여 불확실한 내용을 추측하는 대신, 프롬프트 내에 직접 주입된 사실 데이터를 유일한 근거로 삼아 텍스트를 생성하게 됩니다.

결과적으로 검색(Retrieval)된 데이터를 프롬프트에 주입하여 LLM의 생성(Generation) 능력을 보완(Augmentation)하는 RAG의 핵심 목적이 이 프롬프트 증강 단계를 통해 완성됩니다.

RAG은 여전히 유효한가?

RAG은 아직 필요한가? 에 대한 논의가 있었던 것을 보았습니다. 이러한 논의가 나오게 된 배경은 AI 가 빠르게 발전하면서 Context Window 에 저장이 가능한 데이터의 크기가 비약적으로 거대해졌기 때문입니다. 과거에는 4K 정도로 책 한권의 내용만 Context Window 에 저장이 가능했지만 오늘날에는 1M+ 의 정도로 반지의 제왕 전권에 대한 내용을 Context Window 에 저장하는 것이 가능해졌습니다.

이로 인해서 부상이 된 것이 Long Context 입니다. RAG 에 의존하지 않고 LLM의 컨텍스트 윈도우에서의 데이터만으로 쿼리 처리를 하는 것을 의미합니다. Long context가 RAG(검색 증강 생성) 방식보다 더 유리한 주요 이유는 세 가지로 요약할 수 있습니다.

Long Context의 장점

첫째, 인프라 구조의 단순화입니다. 프로덕션 환경에서 RAG 시스템을 구축하려면 데이터를 분할하는 청킹(chunking) 전략, 데이터를 인코딩할 임베딩 모델, 벡터 데이터베이스, 결과를 재정렬할 리랭커(reranker) 등 많은 구성 요소가 필요해 구조가 무거워집니다. 반면 Long context는 이러한 데이터베이스나 임베딩, 검색 로직을 모두 생략하고 데이터를 모델에 직접 전송하는 '노 스택 스택(no stack stack)' 접근법을 제공하여 아키텍처를 크게 단순화합니다.

둘째, 검색 실패(Silent Failure)의 방지입니다. RAG는 사용자의 질문과 가장 유사한 벡터를 찾는 확률론적 의미 검색(semantic search)을 수행하기 때문에, 데이터 안에 정답이 존재하더라도 검색 단계에서 알맞은 문서를 가져오지 못하는 실패(retrieval lottery)가 발생할 수 있습니다. Long context는 이러한 검색 단계 자체가 없으며, 모델이 제공된 모든 데이터를 직접 검토하기 때문에 정보 누락의 위험이 없습니다.

셋째, 전체 문맥 파악 및 비교(Whole Book Problem 해결) 에 뛰어납니다. RAG는 특정 텍스트 조각(snippet)만을 검색해오기 때문에, 여러 문서 간의 차이를 비교하거나 누락된 정보를 찾는 데는 한계가 있습니다. 예를 들어 요구사항 문서와 릴리스 노트를 비교해 '누락된 보안 요구사항'을 찾는다면, RAG는 파편화된 조각들만 가져와 모델이 전체적인 상황을 파악하기 어렵게 만듭니다. 반면 Long context는 관련된 전체 문서(Whole book)를 컨텍스트 창에 한꺼번에 쏟아부어, 모델이 전체 데이터를 직접 대조하고 누락된 부분을 찾아낼 수 있도록 돕습니다.

결과적으로, 분석해야 할 데이터가 한정되어 있고 특정 계약서 분석이나 책 요약과 같이 문서 전체에 대한 복잡한 포괄적 추론(global reasoning) 이 필요한 작업에서는 Long context를 활용하는 것이 아키텍처를 단순화하고 모델의 추론 성능을 높이는 데 훨씬 유리합니다.

Long Context의 단점

앞서 말씀드린 장점들에도 불구하고, Long context 방식이 가지는 단점들이 존재합니다.

첫째, 막대한 연산 비효율성(반복 읽기, Rereading text) 문제입니다. Long context는 사용자가 질문을 할 때마다 문서 전체를 프롬프트에 넣고 처리해야 합니다.

예를 들어 500페이지 분량의 매뉴얼(약 25만 토큰)을 입력한다면, 매 질문마다 모델이 이 방대한 문서를 처음부터 끝까지 다시 처리하는 비용을 지불해야 합니다. 정적인 데이터라면 프롬프트 캐싱을 통해 어느 정도 상쇄할 수 있지만, 내용이 자주 변경되는 동적 데이터의 경우 매 요청마다 막대한 연산 비용(Full tax)을 고스란히 부담해야 합니다. 반면 RAG 방식은 데이터를 처음 색인(Indexing)할 때 한 번만 처리 비용을 지불하면 된다는 차이가 있습니다.

둘째, 건초더미에서 바늘 찾기(Needle in the haystack) 현상입니다. 컨텍스트 창에 아무리 많은 데이터를 넣을 수 있다 하더라도, 텍스트가 수십만 토큰 단위로 늘어나면 모델의 주의력(Attention mechanism)이 흐려지게 됩니다.

2,000페이지가 넘는 문서 중간에 파묻힌 단 하나의 특정 문단에 대해 질문할 경우, 모델이 해당 정보를 찾지 못하거나 주변 텍스트를 바탕으로 환각(Hallucination) 오류를 일으킬 확률이 높아집니다. 반면 RAG 방식은 노이즈(건초더미)를 제거하고 가장 관련성 높은 정보(바늘)만 5개 정도 추려 모델에 제공하기 때문에 모델이 핵심에 집중하기 더 좋습니다.

셋째, 무한한 데이터 세트(Infinite data set)를 다루기에는 여전히 용량이 부족합니다. 모델의 컨텍스트 창이 수백만 토큰으로 늘어났다 하더라도, 테라바이트나 페타바이트 단위로 측정되는 기업의 방대한 데이터 호수(Data lake)에 비하면 이는 '새발의 피(Drop in the bucket)'에 불과합니다. 따라서 거대한 기업 데이터를 전부 컨텍스트 창에 집어넣는 것은 불가능하며, 방대한 정보 중 필요한 것만 걸러내어 모델의 컨텍스트 창 크기에 맞게 전달해 주는 검색 계층(Retrieval layer)과 벡터 데이터베이스는 여전히 필수적입니다.

결론적으로, 분석할 데이터가 제한적이고 문서 전체의 포괄적인 비교 분석이 필요할 때는 Long context가 유리하지만, 데이터의 양이 무한에 가깝게 방대하거나 특정 세부 정보를 정확히 찾아야 할 때, 그리고 연산 비용을 효율적으로 관리해야 할 때는 여전히 RAG 방식이 필요하다고 볼 수 있습니다.

결론: RAG과 Long Context의 상호 보완적 미래

지금까지 RAG의 개념과 도입 배경, 동작 원리부터 최근 대두된 Long context와의 비교까지 살펴보았습니다. LLM의 Context Window가 비약적으로 확장되면서 Long context라는 강력한 대안이 등장했고, 아키텍처의 단순화나 포괄적 추론(Global reasoning) 측면에서 뚜렷한 강점을 보여주고 있는 것은 사실입니다.

하지만 앞서 살펴본 바와 같이 Long context가 RAG을 완전히 대체할 수는 없습니다. 현실의 비즈니스 환경에서 생성되고 축적되는 데이터의 규모는 LLM이 한 번에 감당할 수 있는 한계를 항상 뛰어넘기 마련입니다. 또한, 매 요청마다 전체 문서를 다시 읽어야 하는 막대한 연산 비용(Full tax)과 방대한 정보 속에서 핵심을 놓치는 현상(Needle in the haystack)은 실무 도입에 있어 명확한 한계점으로 작용합니다.

따라서 "RAG은 여전히 유효한가?"라는 질문에 대한 답은 명백히 "그렇다"입니다. 두 기술은 상호 배타적인 경쟁 관계가 아닙니다. 데이터의 규모가 작고 전체적인 문맥 파악이 중요하다면 Long context를 활용하고, 무한에 가까운 데이터 풀에서 비용 효율적으로 정확한 근거를 찾아야 한다면 RAG을 활용하는 식의 전략적 선택이 필요합니다.

결과적으로 향후 AI 서비스는 이 두 가지 방식을 이분법적으로 나누기보다는, 해결하고자 하는 문제의 성격과 데이터의 특성에 맞춰 적절히 혼합하여 사용하는 방향으로 발전할 것입니다. LLM 자체의 성능과 용량이 아무리 발전하더라도, 외부의 거대한 지식 베이스에서 필요한 정보를 효율적으로 검색해 모델의 환각을 통제하고 신뢰성을 부여하는 RAG의 본질적인 역할은 앞으로도 굳건히 유지될 것입니다.

참고자료

RAG