RAG-token, Rag-sequence의 차이에 대한 이해를 해보자!

RAG를 단순하게 컨텍스트 기반 검색으로 원하는 검색 범위를 지정해서 검색할 수 있는 검색 기능으로 이해하고 있었다.

하지만 RAG를 깊게 공부해볼수록 여러 가지 방식으로 검색이 가능함을 알 수 있었다.

공부 파바바바바바ㅏㄱ

RAG의 진짜 목적

RAG는 단순 검색이 아니다. LLM이 학습 데이터 이후의 정보를 모르거나, 특정 도메인 데이터가 없을 때 할루시네이션이 발생하는 근본적인 한계를 보완하는 아키텍처다. 실제 데이터 기반으로 답변을 생성하기 때문에 정확도가 올라간다.

 

RAG-Sequence vs RAG-Token

크게 RAG는 2가지로 token, sequence 기반 검색 방식으로 나뉜다.

RAG-Sequence는 검색을 1번만 진행하고 전체 답변을 한 번에 생성한다. 일반적인 QA 서비스에서 쓰기 적합하고 비용도 저렴하다.

RAG-Token은 토큰을 생성할 때마다 다른 문서를 참조해서 정밀도와 완성도 높은 답변을 얻을 수 있다. 하지만 토큰 수만큼 검색과 LLM 호출이 발생해서 비용이 폭발적으로 늘어난다.

이를 보완하고 발전된 방식으로, 2026년에 가장 큰 변화는 RAG와 에이전트 루프의 결합이다. Agentic RAG는 시스템이 한 번만 검색하는 게 아니라, 무엇을 검색할지, 언제 멈출지를 스스로 추론한다. 이게 2026년 대부분의 프로덕션 RAG 시스템을 이끄는 아키텍처다.

 

Agentic RAG

RAG-Token의 비용 문제를 보완하고 발전된 방식이 Agentic RAG다. 검색 횟수를 고정하지 않고 Agent가 스스로 "지금 정보가 부족하다"고 판단할 때만 추가 검색을 진행한다. 무엇을 검색할지, 언제 멈출지를 스스로 추론하는 방식이다. 2026년 대부분의 프로덕션 RAG 시스템이 이 방향으로 가고 있다.

 

Chunking 전략

청크를 어떻게 나누냐가 RAG 품질을 직접적으로 결정한다. Fixed Size는 단순하지만 문장 중간에서 잘리는 문제가 있다. Sliding Window는 청크 경계에서 컨텍스트가 끊기지 않도록 overlap을 준다. 회의록처럼 발화자 정보가 있으면 발화자 단위가 가장 자연스럽다.

 

Hybrid Retrieval

Dense(벡터 유사도 기반)와 Sparse(키워드 기반)를 결합한 Hybrid Retrieval이 실무에서 가장 효과적이다. 의미 기반 검색과 정확한 키워드 검색을 동시에 잡을 수 있기 때문이다.

Hybrid Retrieval의 간단한 예시 상황

추가 공부 : Long Context와 RAG의 관계

2024~2025년부터 LLM의 컨텍스트 윈도우가 급격히 커졌다. Claude 4.6 기준 100만 토큰까지 처리 가능해지면서 "RAG 없이 전체 문서를 통째로 넣으면 되지 않냐"는 얘기가 나오기 시작했다.

 

실제로 고트래픽 서비스에서는 Prompt Caching과 결합하면 Long Context가 RAG보다 저렴한 경우도 생겼다. 하지만 회의록처럼 대용량 파일을 다루는 서비스에서는 여전히 관련 청크만 검색해서 LLM에 전달하는 RAG 방식이 비용 효율적이다.

 

결국 Long Context와 RAG는 경쟁 관계가 아니라 상황에 따라 선택하거나 결합하는 방식으로 가고 있다.