검색은 한 번 실행하는 고정된 파이프라인이 아니게 되었다. 에이전트가 작동하는 동안 계속해서 내리는 결정이 되었다. 내가 어떻게 그 지점에 도달했는지, 그리고 무엇이 바뀌었는지 알려주겠다.

2023년에 모두가 구현했던 패턴

몇 년 전에 RAG 시스템을 구축했다면, 아마도 내가 했던 것과 비슷한 것을 만들었을 것이다. 문서를 가져와서 고정 크기의 청크(chunk)로 잘라내고, 각 청크를 임베딩(embed)한 다음, 벡터들을 데이터베이스에 저장한다. 쿼리 시간이 되면 질문을 임베딩하고, 가장 가까운 상위 몇 개의 청크를 가져와 프롬프트에 붙여넣은 후 모델이 답변하게 한다.

Naive Rag

이것은 보기에는 완벽하다. 질문을 하면 올바른 단락을 가져오고, 답변도 훌륭해 보이며, 모두가 고개를 끄덕인다. 그러다가 실제 사용자에게 적용되면서 조용히 잘못된 결과를 내기 시작한다.

나는 이것이 일어나는 것을 여러 번 목격했다. 짜증 나는 부분은 아무것도 오류를 발생시키지 않는다는 것이다. 검색은 실행되고, 청크가 돌아오고, 모델은 완전한 확신을 가지고 답변한다. 단지 잘못된 컨텍스트(context)에서 답변하고 있을 뿐이며, 다운스트림(downstream)의 누군가가 답변이 틀렸다는 것을 알아차릴 때만 알게 된다.

그래서 2023년 패턴이 왜 깨지는지에 대해 솔직하게 이야기할 가치가 있다. 왜냐하면 실패가 무작위적이지 않기 때문이다.

이것이 깨지는 이유

첫 번째 문제는 벡터 유사성(vector similarity)이 관련성(relevance)과 같지 않다는 것이다. 두 청크는 임베딩 공간에서 서로 가깝게 위치할 수 있지만, 실제로는 정반대의 의미를 가질 수 있다. 나는 정책 등급을 다루는 시스템에서 이것을 명확하게 보았다. 그곳에서는

두 번째 문제는 파편화 (fragmentation)입니다. 고정된 글자 수로 분할할 때, 하나의 사실이 종종 두 개의 청크 (chunk)에 걸쳐 잘리게 됩니다. Top-k는 그중 절반만 가져오고 나머지 절반은 놓치게 되며, 세상 그 어떤 리랭커 (reranker)도 처음부터 온전하게 검색되지 않은 사실을 바로잡을 수는 없습니다. 나는 왜 청킹 (chunking)이 전처리 (preprocessing)가 아닌 모델링 결정 (modeling decision)인지에 대해 별도의 글을 쓴 적이 있는데, 이것이 바로 그 핵심입니다.

세 번째 문제는 사람들이 과소평가하는 문제입니다. 실제 사용자 쿼리 (query)는 무질서하며, 놀라울 정도로 많은 비율이 임베딩 모델 (embedding model)이 학습된 분포 (distribution)를 벗어납니다. 한 분석에 따르면 실제 쿼리의 약 31%가 분포 외 (out of distribution)에 해당하며, 이는 검색 실패의 급증과 일치합니다. 당신의 임베딩 (embeddings)은 깨끗한 텍스트로 튜닝되었습니다. 하지만 당신의 사용자들은 파편화된 문장, 오타, 그리고 미완성된 질문을 입력합니다. 이 격차는 잘못된 검색 결과로 나타납니다.

이 중 어느 것도 생소한 것이 아닙니다. 이것들은 단순한 패턴의 기본 동작이며, 바로 이 점 때문에

하지만 여기서 제가 강조하고 싶은 부분이 있습니다. 왜냐하면 대부분의 사람들이 이 부분을 그냥 지나치기 때문입니다. 측정하지 않는 검색(retrieval)은 개선할 수 없습니다. 저는 어떤 검색 변경 사항을 신뢰하기 전에, 각 질문에 대해 반환되어야 하는 청크(chunk)들을 포함한 소규모의 실제 질문 세트를 구축하고, 그 세트를 바탕으로 검색 성능을 점수화합니다. 올바른 청크가 top-k 안에 포함되었는지 여부를 확인하는 것입니다. 이것이 없다면, 여러분은 단순히 느낌(vibes)에 의존하여 튜닝을 하고 있는 것이며, 실제 개선 여부와 상관없이 모든 변화가 진전처럼 느껴질 뿐입니다.

에이전트 방식(agentic)으로 전환되는 지점

하이브리드 검색(Hybrid retrieval)은 여전히 고정된 파이프라인입니다. 모든 쿼리에 대해 동일한 단계가 동일한 순서로 진행됩니다. 저에게 있어 단순한 RAG를 실제로 종결시킨 진정한 변화는, 검색을 항상 실행해야 하는 단계가 아니라 에이전트가 내리는 하나의 결정으로 취급하는 것입니다.

신중한 연구자가 어떻게 행동하는지 생각해 보십시오. 그들은 사용자의 질문을 그대로 임베딩(embedding)하여 세 개의 단락을 가져오지 않습니다. 그들은 질문을 검색 가능한 형태로 재구성(rephrase)합니다. 심지어 무언가를 찾아볼 필요가 있는지조차 결정합니다. 첫 번째 검색 결과가 빈약하다면, 다른 관점으로 시도합니다. 복잡한 질문에 대해서는 질문을 여러 부분으로 나누고 각각을 추적합니다.

에이전트 기반 검색(Agentic retrieval)은 이러한 행동을 루프(loop) 안에 내장시킨 것입니다. 구체적인 몇 가지 요소는 다음과 같습니다:

첫 번째는 쿼리 재작성(Query rewriting)입니다. 사용자의 가공되지 않은 질문은 종종 나쁜 검색 쿼리가 되기 때문에, 에이전트는 인덱스(index)에 접근하기 전에 이를 하나 이상의 더 깔끔한 쿼리로 재작성합니다. 이것만으로도 분포 외 데이터(out-of-distribution) 문제의 상당 부분을 해결할 수 있습니다.

다음은 검색을 수행할지 여부에 대한 결정입니다. 모든 단계에서 조회가 필요하지는 않습니다. 매 턴마다 검색을 수행하는 에이전트는 토큰을 낭비하고 노이즈를 끌어들입니다. 더 나은 에이전트는 이미 필요한 정보를 가지고 있는지 스스로에게 묻습니다.

어려운 질문의 경우, 에이전트는 계획을 세웁니다. 다중 부분 질문을 하위 질문(sub-questions)으로 나누고, 각각에 대해 검색을 수행한 뒤, 결과로 돌아온 것들을 결합합니다. 이것이 바로 단일 샷(single-shot) RAG가 무너지고 에이전트 루프가 빛을 발하는 지점입니다. 왜냐하면 하나의 하위 질문에 대한 답변이 다음 검색의 형태를 결정하기 때문입니다.

그리고 검색 결과가 부실할 때, 에이전트는 빈약한 근거를 바탕으로 자신 있게 답변하는 대신, 이를 인지하고 다른 쿼리(query)나 다른 소스를 사용하여 다시 시도할 수 있습니다.

제 머릿속에 남은 사고 모델(mental model)은 검색(retrieval)이 한 번 호출하고 신뢰하는 고정된 함수가 아니라, 에이전트가 자신이 처한 상태(state)에 따라 결정하는 정책(policy)으로 변했다는 점입니다.

검색을 아예 하지 말아야 할 때를 아는 법

업계가 새로운 극단으로 치우쳤기 때문에, 짧지만 중요한 이야기를 잠시 해보겠습니다. 수백만 토큰의 컨텍스트 윈도우(context window)가 등장하면서, 많은 이들이 검색은 무의미하며 그냥 모든 것을 프롬프트(prompt)에 넣으면 된다고 말합니다.

때로는 그 말이 맞습니다. 관련 입력 전체가 작고 모델이 그 모든 내용을 한꺼번에 추론해야 한다면, 긴 컨텍스트(long context)가 더 단순하고 종종 더 낫습니다. 하지만 그 윈도우 안의 모든 토큰은 호출할 때마다 비용이 발생하므로, 규모가 커지면 비용이 빠르게 증가하며, 핵심 세부 사항이 거대한 프롬프트 속에 묻히면서 품질이 떨어질 수 있습니다. 측정된 비교 결과에 따르면, 워크로드에 따라 검색은 동일한 코퍼스(corpus)를 컨텍스트에 밀어 넣는 것보다 대략 8배에서 82배까지 저렴한 것으로 나타났습니다.

따라서 이는 RAG냐 긴 컨텍스트냐의 문제가 아닙니다. 작고 미묘한 입력에는 긴 컨텍스트를, 방대하거나 빠르게 변하는 지식에는 검색을 사용해야 합니다. 그리고 멀티홉(multi-hop) 에이전트 추론의 경우에는 두 가지를 함께 사용해야 합니다. 범위를 좁히기 위해 검색을 수행하고, 검색된 결과에 대해 추론하기 위해 컨텍스트를 사용하는 방식입니다.

답변을 감사 가능하게 만들기 (auditable)

장난감 수준의 프로젝트와 실제 사용자 앞에 내놓을 수 있는 결과물을 구분 짓는 또 하나의 요소입니다. 에이전트는 단순히 답변만 해서는 안 되며, 자신의 작업 과정을 보여주어야 합니다. 출력되는 모든 주장은 그것이 가져온 청크(chunk)를 다시 가리켜야 합니다.

이것은 두 가지 역할을 합니다. 인간이 답변을 무조건 신뢰하는 대신 검증할 수 있게 해주며, 검색(retrieval)이 취약했을 때 신호를 제공합니다. 확실한 근거가 없는 답변은 실제로 포착할 수 있는 위험 신호(red flag)이기 때문입니다. 근거 제시(Grounding)와 인용 강제(citation enforcement)는 있으면 좋은 기능(nice-to-have)이 아닙니다. 틀렸을 때 실제 비용이 발생하는 시스템에서, 이는 데모와 도구를 가르는 차이입니다.

실제 사례에서의 모습

제가 조사 에이전트(Research Investigation Agent)를 구축했을 때, 대략 다음과 같은 형태를 띠었습니다. 이는 단일 호출(single call)이라기보다 단계들로 이루어진 작은 그래프(graph)에 가깝습니다. 질문은 먼저 해석되고 계획됩니다. 검색은 웹 검색(web search)과 벡터 저장소(vector store) 모두에서 정보를 가져오는 하이브리드(hybrid) 방식이므로, 하나의 신호에만 의존하지 않습니다. 에이전트가 수집한 증거가 실제로 충분한지 확인하는 자기 성찰(self-reflection) 단계가 있으며, 만약 충분하지 않다면 무언가를 작성하기 전에 다시 돌아가 재검색을 수행합니다. 그리고 전체 실행 과정은 추적(traced)되므로, 어떤 단계에서 어떤 결정이 내려졌는지 확인할 수 있습니다.

여기에 언급된 개별 아이디어 중 그 누구의 것도 제 것이 아닙니다. 저에게 변화를 준 것은 이 아이디어들이 하나의 시스템으로 결합되는 것을 본 것이었습니다. 즉, 검색을 시작 시점에 한 번 시도하고 요행을 바라는 단일 조회(lookup)가 아니라, 루프(loop) 내부에서 지속적으로 결정되고, 확인되고, 반복되는 과정으로 보는 것입니다.

요약

단순 RAG(Naive RAG)가 죽은 이유는 검색이 중요하지 않게 되었기 때문이 아닙니다. "임베딩(embed)하고, 상위 k개(top-k)를 검색하고, 붙여넣고, 기도하기" 방식이 항상 검색이 가질 수 있는 가장 취약한 형태였기 때문에 죽은 것입니다. 이를 대체한 것은 사람이 실제로 조사하는 방식에 더 가깝습니다. 질문을 재구성합니다. 검색 여부를 결정합니다. 한 가지 이상의 방법으로 검색합니다. 증거가 유효한지 확인합니다. 유효하지 않다면 다시 시도합니다. 답변이 어디에서 왔는지 보여줍니다.

만약 당신의 RAG 시스템이 추측을 하고 있는 것처럼 느껴진다면, 실제로 그러고 있을 가능성이 높습니다. 해결책은 대개 더 큰 모델이나 더 긴 프롬프트(prompt)가 아닙니다. 검색에 '생각할 수 있는 능력'을 부여하는 것입니다.

현재 당신의 검색 스택(retrieval stack)은 어떤 모습입니까? 고정된 파이프라인(fixed pipeline)입니까, 아니면 스스로 결정할 수 있는 루프(loop)입니까?

출처

• 벡터 유사도 (Vector similarity) 대 관련성 (relevance), 그리고 실제 RAG 실패 모드 (failure modes): https://towardsai.net/p/machine-learning/5-things-that-broke-my-rag-system
• 전략 간 청킹 재현율 격차 (동일 코퍼스에서 약 9%): https://ragflow.io/blog/rag-review-2025-from-rag-to-context
• 분포 외 쿼리 (Out-of-distribution queries, 약 31%) 및 검색 실패: https://ragaboutit.com/7-zero-shot-rag-failures-that-cost-enterprises-millions/
• RAG 대 긴 컨텍스트 (long context) 비용 격차 (대략 8배에서 82배): https://byteiota.com/rag-vs-long-context-2026-retrieval-debate/ ; https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval