라온피플

RAG, 정말 거대 컨텍스트 창만 있으면 될까?

검색 증강 생성(Retrieval-Augmented Generation, RAG)은 이제 AI 분야의 핵심 기술로 확고히 자리 잡았습니다. LLM이 사전 훈련 데이터에만 의존하지 않고, 외부의 최신 정보를 바탕으로 더 정확하고 신뢰성 있는 답변을 생성하게 해주는 강력한 접근법이죠. 최근에는 Gemini, Claude 등 ‘거대 컨텍스트 창’을 자랑하는 모델들이 속속 등장하면서, 일각에서는 “이제 수많은 문서를 통째로 컨텍스트에 넣으면 되니, 복잡한 검색 과정은 필요 없어지는 것 아닌가?” 하는 기대 섞인 목소리가 나오고 있습니다.

하지만 정말 그것만으로 충분할까요? RAG의 세계는 우리가 생각하는 것보다 훨씬 더 깊고 흥미로운 비밀을 품고 있습니다. 성공적인 RAG 시스템은 단순히 컨텍스트 창 크기에 의존하는 것을 넘어, 데이터의 본질을 꿰뚫는 정교한 전략을 요구합니다. 이 글에서는 평범한 프로토타입을 넘어 운영 가능한 지능형 애플리케이션으로 RAG 시스템을 성숙시키는 여정을 함께하며, 기존 통념을 깨는 4가지 놀라운 진실을 파헤쳐 보겠습니다.

“거대 컨텍스트 창이 만능 해결책은 아니다.”

모델 성능을 압도하는 청킹과 검색의 시너지

거대 컨텍스트 창의 등장이 검색(Retrieval)의 종말을 고할 것이라는 예측이 무성했지만, 실제 연구 결과는 정반대의 이야기를 들려줍니다. Snowflake의 금융 문서 분석 사례 연구에 따르면, 최종 답변 품질에 가장 큰 영향을 미친 것은 생성 모델(LLM) 자체의 성능이 아니라, 청킹(chunking)과 검색 전략 간의 정교한 상호작용이었습니다.

이는 매우 강력한 메시지를 전달합니다. 심지어 성능이 약간 낮은 모델이라도 우수한 검색 파이프라인과 결합하면, 빈약한 검색 시스템을 사용하는 최상위 모델을 능가할 수 있다는 것입니다.

실험 결과는 더욱 구체적인 사실을 보여줍니다. 많은 이들이 컨텍스트 창이 크니 청크(chunk) 크기도 최대한 키우는 게 좋다고 생각하지만, 이는 오히려 함정입니다. 너무 큰 청크(예: 14,400자)를 사용하면 핵심 정보가 수많은 부가 정보에 희석되어 ‘컨텍스트 혼란(context confusion)’을 야기합니다. LLM이 엉뚱한 연도의 정보를 가져오거나 비슷한 용어를 혼동하는 등의 오류를 일으키며 최종 답변의 정확도가 약 10%~20%까지 하락했습니다.

반면, 적절한 크기(예: 1,800자)의 청크를 더 많이(예: 상위 50개) 검색하여 LLM에게 제공했을 때 훨씬 더 높은 성능을 보였습니다. 즉, 무작정 많이 넣는 것보다 ‘잘’ 골라서 ‘적절히’ 넣는 영리한 전략이 훨씬 중요하다는 것입니다. 검색의 중요성이 여전하다면, 이제 우리는 어떻게 더 ‘잘’ 검색할 수 있을지 고민해야 합니다.

“문서는 ‘텍스트’가 전부가 아니다.”

페이지 전체를 이미지로 ‘보는’ 새로운 접근법

검색이 핵심이라면, 우리는 과연 문서의 정보를 올바르게 검색하고 있을까요? 기존 RAG 시스템은 문서를 단순한 텍스트의 나열로 취급하는 근본적인 한계를 가집니다. 하지만 금융 보고서, 연구 논문, 기술 매뉴얼을 떠올려 보십시오. 복잡한 표, 그래프, 다이어그램, 그리고 이 모든 것을 아우르는 페이지 레이아웃 자체가 중요한 정보를 담고 있습니다. 기존 방식은 이 모든 시각적 맥락을 놓치고 맙니다.

이러한 한계를 극복하기 위해 ColPali라는 혁신적인 접근법이 등장했습니다. 이 방법은 OCR, 텍스트 추출, 레이아웃 분석과 같은 복잡하고 오류가 발생하기 쉬운 파이프라인을 완전히 생략합니다. 대신, 문서 페이지를 통째로 하나의 ‘이미지’로 취급합니다.

이는 RAG의 패러다임을 “추출한 것을 검색하는 것(What you extract is what you search)”에서 “보는 것을 검색하는 것(What you see is what you search)”으로 전환시킵니다. 그 작동 원리는 비전-언어 모델(VLM, Vision Language Model)이 페이지 이미지를 32×32 격자와 같은 작은 패치(patch)들의 그리드로 처리하는 데 있습니다. 모델은 각 패치에 대해 주변의 시각적, 텍스트적 맥락을 모두 이해하는 임베딩을 생성하여 페이지의 공간적, 구조적 정보를 벡터에 그대로 보존합니다. 덕분에 표의 구조나 그래프의 추세 같은 정보가 임베딩에 녹아들어, 시각적으로 복잡한 문서에서 기존 텍스트 기반 RAG는 절대 따라올 수 없는 강력한 성능을 발휘합니다.

“모든 것을 임베딩하는 것이 최선은 아니다.”

‘요약’으로 검색하고, ‘원본’으로 답하다

이제 우리는 문서의 시각적 구조까지 이해하게 되었습니다. 하지만 검색을 위해 모든 정보를 하나의 벡터로 압축하는 것이 항상 최선일까요? 일반적인 RAG에서는 문서의 원본 청크를 그대로 임베딩하여 검색에 사용합니다. 하지만 수십 개의 행과 열로 이루어진 복잡한 표나 여러 주제를 담고 있는 긴 텍스트 블록을 하나의 벡터로 압축하면 핵심 의미는 희석되고 ‘노이즈가 많은’ 벡터가 생성됩니다. 이는 결국 검색 성능을 심각하게 저하시키는 원인이 됩니다.

이 문제에 대한 우아한 해결책이 바로 ‘다중 벡터 리트리버(multi-vector retriever)’ 기법입니다. 이 기법의 핵심 아이디어는 검색 단계와 생성 단계에 사용하는 데이터의 형태를 분리하는 것입니다.

검색 단계: 원본 텍스트 청크나 표의 ‘간결한 요약’을 LLM을 통해 생성하거나, 또는 내용을 대표하는 가상 질문 같은 다른 대표 벡터를 만들어 냅니다. 검색 시에는 바로 이 ‘요약 임베딩’을 사용해 가장 관련성 높은 문서 조각을 찾습니다.
생성 단계: 요약본을 통해 가장 관련성 높은 원본 문서의 ID를 찾았다면, 벡터 저장소가 아닌 별도의 문서 저장소(docstore)에서 해당 ID를 가진 ‘온전한 원본(full, raw)’ 텍스트나 표를 가져옵니다. 그리고 이 완전한 원본 데이터를 LLM에게 전달하여 최종 답변을 생성하게 합니다.

이 방식은 검색에 최적화된 간결한 벡터로 정확성을 높이고, 답변 생성에는 풍부한 원본 정보를 제공하여 품질을 높이는, 두 마리 토끼를 모두 잡는 효과적인 전략입니다. 특히 다양한 형식이 섞인 반정형(semi-structured) 데이터를 다룰 때 그 진가가 드러납니다.

“의미론적 검색만으로는 부족하다.”

‘키워드’와 ‘관계’를 더하여 완성도를 높여라

지금까지 우리는 검색할 정보의 ‘형태’를 최적화했습니다. 하지만 검색 ‘방식’ 자체는 어떨까요? 벡터 기반의 의미론적 검색(semantic search)은 RAG의 심장이지만, 실제 운영 환경의 복잡한 질문에 답하기엔 그것만으로 부족할 때가 많습니다.

하이브리드 검색 (Hybrid Search): 의미론적 검색은 ‘SSO’, ‘SKU-123’과 같은 드문 약어나 특정 제품 ID를 놓치는 경향이 있습니다. 왜냐하면 이런 용어들은 문서 전체에서 등장 빈도가 낮아, 벡터 공간에서 그 중요성이 제대로 표현되지 않기 때문입니다. 이를 해결하기 위해 전통적인 키워드 기반 검색(lexical search, 예: BM25)을 결합하는 ‘하이브리드 검색’이 필수적입니다. 키워드 검색으로 정확한 용어를 잡아내고, 의미론적 검색으로 문맥적 유사성을 파악하여 두 결과를 결합하면 검색의 완성도를 극적으로 높일 수 있습니다.
지식 그래프 RAG (GraphRAG): 벡터 검색은 유사한 텍스트 조각을 찾는 ‘지역적 조회(local lookup)’에는 강하지만, 여러 문서에 흩어진 정보를 연결하고 다단계 추론이 필요한 ‘전체적 질문(global question)’에는 무력합니다. 예를 들어 다음과 같은 질문을 생각해 봅시다.

“지난 분기에 계약을 갱신한 기업 고객 중 SSO 관련 지원 티켓을 연 고객은 누구인가?”

이 질문에 답하려면 유사한 텍스트 조각을 찾는 것을 넘어, ‘고객’, ‘계약 갱신’, ‘지원 티켓’이라는 개체(entity)들 사이의 관계를 파악해야 합니다. 바로 이 지점에서 데이터셋 전체에 걸친 관계망을 탐색하는 지식 그래프(Knowledge Graph)가 강력한 힘을 발휘합니다. GraphRAG는 텍스트가 아닌 ‘관계’ 자체를 탐색하여, 기존 RAG로는 불가능했던 복잡한 분석적 질문에 대한 답을 찾아냅니다.