현 거대 언어 모델(LLM)은 지난 몇 년간 급격한 성장을 이루었습니다. 단순히 AI 모델을 사용하는 것을 넘어, 자사의 방대한 내부 데이터를 LLM에 연동하여 실질적인 비즈니스 가치를 창출하고자 하는 요구에 직면해 있습니다. 이런 배경에는 RAG(Retrieval-Augmented-Generation)가 있습니다. RAG는 모델에 없는 최신 정보나 비공개 기업 데이터에 접근할 수 있도록, 데이터베이스에서 관련 내용을 검색하여 프롬프트에 주입하는 기술입니다. 이는 이론적으로 LLM의 가장 큰 약점이었던 환각(Hallucination) 현상을 완화하고, 지식의 최신성을 보장하는 완벽한 솔루션처럼 보였습니다.
Dzone에 언급된 https://dzone.com/articles/rag-illusion-grafting-memory-limitations 내용에 의하면 현재의 RAG 방식이 가진 근본적인 한계를 지적하며 이를 환상적 접목이라는 은유로 설명을 하고 있습니다. “접목”의 사전적 의미는 서로 다른 두 식물의 조직을 연결하여 하나의 개체처럼 자라게 하는 기술이지만, 접목된 두 식물은 기능적으로 공존할 뿐, 유전적으로나 구조적으로 완전히 융합된 것은 아닙니다.
현재의 RAG도 이와 유사합니다. 검색(Retriever)라는 “가지”를 생성 모델(Generator)라는 “나무”에 억지로 붙여놓은 형상입니다. 겉으로 보기에는 LLM이 기업 데이터를 완벽히 이해하고 답변하는 것처럼 보이지만, 실제로는 두 모듈이 서로의 작동 원리를 이해하지 못한 채 단절된 상태로 기능하고 있습니다. 검색 모듈은 생성 모델이 어떤 논리를 필요로 하는지 모른 채 키워드 유사성에만 의존해 결과를 던져주고, 생성 모델은 그 문서가 적절한지 판단할 수 있는 피드백 채널 없이 주어진 텍스트를 앵무새처럼 가공할 뿐입니다. 이런 구조적 분열은 복잡한 추론이 필요한 실 비즈니스 환경에서 심각한 오류와 비효율을 초래할 수 있습니다.
본 글은 RAG 아키텍처의 한계를 살펴보고, 그 대안을 살펴봅니다.
RAG 아키텍처의 구조적 결함
현재 RAG 시스템의 결함은 검색 모듈과 생성 모듈이 서로 다른 목적을 위해서 서로 다른 방식으로 최적화되었다는 점입니다. 이를 “분절된 최적화”라고 표현합니다.
- 검색: 검색은 주로 유사성을 기준으로 작동합니다. 사용자의 질문과 데이터베이스 내 데이터 간의 벡터 거리를 계산하여 가장 가까운 문서를 찾습니다. 이는 마치 도서관 사서가 책의 내용이 사용자에게 얼마나 도움이 되는지를 판단하는게 아니라, 사용자가 말한 단어가 포함된 책을 무조건 가져다주는 것과 같습니다.
- 생성: LLM은 인과성과 문맥을 기반으로 다음 단어를 예측하도록 훈련했습니다. LLM은 논리적인 답변을 구성하기 위해 특정 정보가 필요한데, 검색은 문맥적 필요성이 아닌 표면적 유사성만으로 정보를 제공합니다.
위 두 모듈 사이에는 피드백 루프가 존재하지 않습니다. 만약 검색 모듈이 엉뚱한 문서를 가져오더라도, 생성 모듈이 “이 문서는 답변을 만드는 데 쓸모가 없어, 다른 것을 찾아줘!”라고 요청 할 수 없습니다. 그저 주어진 엉뚱한 정보를 바탕으로 그럴듯한 환각을 만들어내거나, 답변을 거부할 뿐입니다. 이는 두 명의 전문가가 서로의 말을 듣지 못한 채 각자 떠드는 것과 같습니다.
RAG의 핵심 저장소인 백테 데이터베이스는 텍스트의 의미를 숫자의 나열 즉, 임베딩 벡터로 변환하여 저장합니다. 그러나 이 방식은 상관관계의 함정에 취약합니다.
검색 알고리즘은 질문과 키워드가 많이 겹치는 문서를 선호합니다. 그러나 복잡한 문제 해결을 위해서는 키워드가 겹치지 않아도 논리적으로 연결된 정보가 필요합니다. 예를 들어서, “프로젝트 A의 지연 원인”을 질문했을 때, 벡터 검색은 “프로젝트 A”, “지연”이라는 단어가 들어간 보고서를 찾습니다. 그러나 진짜 원인이 “공급망 파트너사의 파산”이라는 제목의 이메일이 있고 그 메일에 “프로젝트 A”라는 단어가 명시적으로 없다면., 벡터 검색은 이 결정적인 단서를 놓치게 됩니다. 이는 검색 모듈이 표면적 유사성에 매몰되어 인과적 정보를 무시하기 때문입니다.
더욱 심각한 기술적 문제는 벡터 임베딩이 인간의 언어 논리 중에 “부정”을 제대로 처리하지 못한다는 점입니다. 대부분의 임베딩 모델은 문맥상 함께 자주 등장하는 단어들을 가까운 벡터 공간에 배치합니다. 문제는 긍정과 부정이 대부분의 단어를 공유한다는 점입니다.
- 문장 A: “이 약은 부작용이 있다.”
- 문장 B: “이 약은 부작용이 없다.”
위 두 문장은 “이”, “약”, “부작용”이라는 핵심 단어를 공유하며, “있다”와 “없다”의 차이만 존재합니다. 벡터 공간에서 이 두 문장은 매우 가깝게 위치하게 됩니다. 따라서 사용자가 “부작용이 없는 약”을 질의 했을 때, RAG는 “부작용이 있다”는 문서들을 대거 검색해오는 오류를 범할 수 있습니다. 이는 단순한 검색 실패라기보다는 사용자의 의도와 정반대되는 정보를 제공할 수 있는 구조적 결함입니다.
문맥 창(Context Window)를 늘리면 해결될 문제라고 생각할 수 있습니다. 100만 토큰을 처리할 수 있는 모델들이 등장하면서, 모든 문서를 프롬프트에 넣으면 된다는 주장이 있을 수 있습니다. 그러나 문맥(Context)은 기억이 아닙니다.
문맥 창에 데이터를 집어넣는 것은 마치 시험 직전에 벼락치기로 내용을 보는 것과 같습니다. 모델은 그 내용을 학습하거나 구조화하여 장기 기억으로 전환하지 않습니다. 매번 질문할 때마다 큰 문서를 다시 읽어야 하기에 연산 비용이 증가하고, 무엇보다 정보의 양이 많아질수록 중간에 위치한 정보를 망각하는 소실 현상이 발생할 수 있습니다. 이는 단순히 양적인 확장이 질적인 추론 능력 향상으로 이어지지 않음을 시사합니다. (참고: https://medium.aiplanet.com/overcome-lost-in-middle-phenomenon-in-rag-using-longcontextretriver-2334dc022f0e, https://arxiv.org/abs/2307.03172)
대안
RAG의 한계를 극복할 대안으로 Apple과 에든버러 대학 연구진이 개발한 CLaRa(Continuous Latent Reasoning) 프레임워크를 제시합니다. CLaRA는 텍스트를 읽는 것이 아니라 의미를 다운로드 하는 방식으로의 패러다임 전환을 의미합니다. (참고: https://github.com/apple/ml-clara)
CLaRa는 데이터를 처리하는 방식이 다릅니다. 기존 RAG는 원본 텍스트를 그대로 잘라서 사용합니다. 반면 CLaRa는 SCP(Salient Compressor Pretraining)라는 과정을 통해 문서를 기억 토큰으로 압축합니다.
SCP의 작동 원리는 모방입니다. 우리가 책을 읽고 나면 책의 모든 문장을 토시 하나도 안틀리고 기억하는 것이 아니라, 핵심 내용과 논리 구조만을 뇌에 저장하지 않나요? SCP는 이 과정을 모방합니다.
또한, 긴 문서를 입력받았기에 불필요한 조사나 반복적인 표현 그리고 문법적 장식 등을 제거하고 오로지 “의미”와 “논리”만을 담은 고밀도 벡터로 압축합니다.
고밀도 벡터는 아래 두 가지 과제를 수행하며 훈련합니다.
- 질의 응답: 압축된 정보만으로 문서 내용에 대한 질문에 답할 수 있어야 한다.
- 의역: 문자의 형태가 바뀌더라도 의미는 동일하게 유지해야 한다.
위 과정을 통해 CLaRa는 기존 텍스트 기반 RAG 대비해서 많은 양의 데이터를 줄일 수 있고, 이는 LLM이 처리해야 할 데이터의 양이 줄어들기에 “중간 소실” 현상을 방지하는데 기여합니다.
CLaRa는 검색과 생성을 수학적으로 연결합니다. 앞에서 언급한 “분절” 문제를 해결하기 위해 CLaRa는 검색 과정을 미분 가능한 함수로 만듭니다.
기존 RAG는 검색 -> 분절 -> 생성의 형태로 답변을 했고, 이 플로우에서는 생성 모듈의 오류가 검색 모듈로 전달되지 않았습니다.
CLaRa는 검색 모듈과 생성 모듈이 하나의 연속적인 잠재 공간을 공유합니다. 생성 모듈의 답변이 틀리면, 그 오차를 계산하여 검색 모듈까지 전달합니다. 즉, 생성 모듈이 검색 모듈에게 “너가 전달한 이 압축 벡터는 답변을 만드는데 도움이 안돼. 다음에는 논리적으로 더 적합한 벡터를 전달해줘”라고 수학적인 신호를 보냅니다. 이렇게 피드백 루프가 형성되기에 검색 모듈은 단순한 단어 유사성보다, 답변 생성에 필요한 의미를 기준으로 데이터를 찾도록 피드백을 통해 진화합니다.
이것이 바로 “접목”을 넘어선 “융합”의 개념입니다. 검색과 생성은 더 이상 별개의 작업이 아니라, 하나의 거대한 추론 과정이 되는 것이지요.
비교
조금 더 이해를 돕기위해 세 가지 주요 접근 방식을 표로 비교해봅니다.
| 항목 | 기존 RAG (접목) | 긴 문맥 (물량) | CLaRa (융합) |
| 철학 | 검색해서 보여주자 | 전부 다 읽어보자 | 핵심만 기억하자 |
| 데이터 형태 | 원본 텍스트 조각 | 원본 문서 전체 | 압축된 기억 토큰 |
| 연결 방식 | 단절 | 검색 안함 | 미분 가능 |
| 한계 | 검색 정확도에 의존 | 중간 소실 현상 발생 | 압축으로 한계 극복 |
| 추론 비용 | 높음 (매번 재독해) | 매우 높음 (토큰당 과금) | 낮음 (압축 정보 처리) |
| 학습 가능 여부 | 불가능 (검색 모듈 고정) | 불가능 (Pre-training 고정) | 가능 (피드백 학습) |
| 예시 | 오픈북 시험 | 책 한권 외우기 | 개념 이해 후 시험 |
RAG가 실패하고 CLaRa가 성공하는 시나리오를 작성해봤습니다.
#시나리오: 기업 내부 감사
상황: 감사팀이 “2025년 프로젝트 지연의 근본 원인”을 찾고자 한다.
기존 RAG:
- 사용자 질문: “2025년 프로젝트 지연 원인 알려줘”
- 벡터 검색: “2025년”, “프로젝트”, “지연”이라는 단어가 포함된 주간 보고서를 찾는다. 보고서에는 “부품 수급 문제로 지연됨”이라고만 적혀 있다.
- 답변: “부품 수급 문제 때문입니다.” (표면적 원인)
CLaRa:
- 사용자 질문: “2025년 프로젝트 지연 원인 알려줘”
- CLaRa는 모든 이메일과 주간 보고서를 압축하여 “기억 토큰”으로 가지고 있습니다.
- 생성 모델은 “부품 수급 문제”라는 단서를 보고, 그 원인을 찾기 위해 관련된 잠재 벡터를 탐색합니다.
- 이 과정에서 “2025년”, “지연”이라는 단어는 없지만, “공급사 A 파산 선고”라는 제목의 이메일이 “부품 수급”과 인과적으로 연결되어 있음을 잠재 공간에서 파악합니다.
- 답변: “직접적인 원인은 부품 수급 문제이나, 근본적으로는 주요 공급사 A의 파산이 영향을 미친 것으로 보입니다.” (심층 추론)
결론
현재의 RAG는 과도기적 기술입니다. 검색 모듈을 통해 LLM에 접목하는 방식은 단순한 사실 검색에는 유용하지만, 고차원적인 문제 해결과 추론에는 한계가 드러납니다.
CLaRa와 같은 프레임워크는 이러한 한계를 극복하기 위해 압축과 통합을 제안합니다.
- 압축: 방대한 문서를 날것으로 읽지 않고, 핵심 의미로 압축하여 효율성을 높임
- 통합: 검색과 생성을 별개의 작업이 아닌, 미분 가능한 하나의 활동으로 연결
여기서 얻을 수 있는 시사점은 단순히 어떤 벡터 데이터베이스를 사용할까? 혹은 어떤 LLM을 붙일까?를 고민하는 단계를 벗어나야 한다는 것입니다.
첫째, 단순히 텍스트를 검색하는 것을 넘어, 데이터의 의미를 어떻게 추출하고 압축할 것인가(SCP)에 대한 고민이 필요합니다.
둘째, 검색 정확도만 따질 것이 아니라, 최종 답변의 완결성과 인과 관계 파악 능력도 평가해야 합니다.
셋째, CLaRa와 같은 기술이 어느정도 완성이 되기 전까지는, 벡터 검색의 한계를 보완하기 위해 키워드 검색을 병행하고, 지식 그래프 등을 활용하여 인과성을 보강하는 전략이 필요합니다.
우리는 지금 “책을 펴고 시험보는 RAG”에서 “내용을 이해하고 숙지한” 단계로 진화하는 변곡점에 서 있습니다. “접목”을 넘어 “융합”으로 나아가는 것, 이것이 핵심이지 않을까 합니다.
