RAG vs Long Context
LLM 컨텍스트 윈도우가 커지고 있다. 2023년에는 GPT-3.5가 4K~8K, 2024년 초에는 GPT-4 Turbo가 128K, 2024년 Claude 3가 200K로 늘어났던 것이 바로 엊그제 같은데, 2026년 들어서는 Claude Opus와 Gemini가 1M~2M, Llama 4 Scout가 10M까지 광고하고 있는 상황이다.
이렇게 컨텍스트 윈도우가 커지자 ‘RAG is dead’와 같은 주장이 X와 기술 블로그 곳곳에서 다시 고개를 들고 있다. 사실 1M 토큰이면 단행본 한 권을 통째로 집어넣고도 자리가 남는다. 그런데 굳이 임베딩 모델을 돌리고, 벡터 DB를 운영하고, chunking 전략을 고민하고, retrieval 파이프라인을 디버깅하면서 RAG 스택을 통째로 들고 갈 이유가 있을까. 그냥 문서를 통째로 컨텍스트에 부어 넣고 모델에게 알아서 찾게 하는 편이 더 단순해 보일 수 있다. 그러나 실제로는 그렇게 간단히 문제가 풀리지는 않는다.
RAG가 풀던 문제
RAG(Retrieval-Augmented Generation)는 LLM이 모르는 정보를 외부 지식으로 보충하는 가장 표준적인 패턴이다. 사내 문서, 최신 뉴스, 사용자의 개인 메모처럼 모델 학습 시점에 포함되지 않은 데이터를 다루려면 어떤 식으로든 모델 바깥에서 정보를 끌어와야 한다. 2023년경의 컨텍스트 윈도우로는 위키피디아 한 페이지조차 통째로 넣기 어려웠으니, 질문과 관련 있는 일부 조각만 추려서 모델에 전달하는 것이 거의 유일한 선택지였다.
이 시기 표준화된 구성은 비교적 단순하다. 문서를 일정 크기로 자르고(chunking), 각 조각을 임베딩 모델로 벡터화해 벡터 DB에 적재한다. 사용자가 질문을 하면 질문도 같은 임베딩 공간에 사상한 뒤, 코사인 유사도로 가까운 chunk 몇 개를 골라 와 프롬프트에 끼워 넣는다. 그 위에 키워드 검색(BM25)과 reranker를 얹은 하이브리드 구조까지가 2024~2025년 사이에 굳어진 형태다.
RAG가 풀어 준 문제는 명확하다. 용량이 부족한 컴퓨터에 외장하드를 연결하듯, 모델은 작아도 외부 지식은 임의로 키울 수 있고, 데이터가 바뀌면 인덱스만 갱신하면 된다. 답변에 출처를 붙일 수 있어 hallucination을 그나마 통제할 수 있고, 토큰 비용도 필요한 chunk만 보내니 비교적 저렴하다. ‘LLM에 회사 데이터 붙이고 싶다’는 요구의 90%는 이 패턴으로 풀렸고, 그래서 한동안 LLM 애플리케이션의 표준이 됐다.
LLM 모델의 발전
그런데 2025년 이후 모델의 컨텍스트 크기가 커지고, 토큰 비용이 저렴해지면서 RAG의 필요성이 흔들리기 시작했다. Gemini 1.5 Pro가 1M을 들고 나오고, Claude가 200K에서 1M으로 확장하고, 일부 오픈 모델은 10M을 광고하기 시작했다. 동시에 토큰 단가가 떨어졌다. Gemini 1.5 Flash 기준 입력 1M 토큰이 약 $0.075 수준이고, 프롬프트 캐싱이 보편화되면서 같은 컨텍스트를 반복해서 보내는 비용도 한 자릿수 분의 1로 줄었다. 200K 토큰을 한 번 보내고 그 위에서 여러 번 질문하는 구성이라면, 두 번째 호출부터는 거의 무료에 가깝게 굴러간다.
또한, Claude Code, Codex, Cursor 같은 코딩 에이전트가 보여 준 패턴은 RAG의 대안이 될 수 있음을 보여주었다. 이들은 벡터 DB를 쓰지 않고, 대신 ripgrep으로 코드베이스를 lexical 검색하고, 결과를 모델 컨텍스트에 그대로 넣는다. 임베딩이 필요 없고, 인덱스도 필요 없으며, 파일이 바뀌면 다음 grep이 곧바로 새 결과를 가져온다. 이 단순한 구조가 실제로 잘 동작한다는 사실이 알려지자, ‘RAG라는 인프라를 짊어질 필요가 정말 있는가’라는 질문이 다시 진지하게 던져지기 시작했다.
2023년 정도만 하더라도 모델이 비싸고 작아서, 똑똑한 retriever로 정밀하게 골라 줘야 했다. 그런데 2026년에는 모델이 싸고 크다. 그러면 retriever는 오히려 단순한 편이 낫다. 정밀도가 떨어지더라도 recall만 충분히 높으면, 나머지 필터링은 모델 자신이 컨텍스트 안에서 처리한다. 임베딩 기반 검색이 흔히 일으키는 문제(가까운 듯 보이지만 실제로는 무관한 문서가 잡히는 false neighbor, chunk 경계가 표나 함수 정의를 끊어 놓는 destructive chunking, 검색이 왜 실패했는지조차 알기 어려운 opaque failure 등)가 grep + long context 구성에서는 대부분 사라진다.
그럼에도 RAG가 필요한 이유
하지만 Databricks가 2024년 말에 13개 LLM을 대상으로 2,000회 이상 진행한 long context 실험은 모델별 실패 양상을 꽤 디테일하게 짚는다. GPT-4o와 Claude 3.5 Sonnet은 긴 컨텍스트에서도 비교적 잘 버티지만, Llama 3.1 405B는 32K를 넘기면서 정확도가 떨어지기 시작한다. Claude 3 Sonnet은 64K 부근에서 답을 거부하는 비율이 3.7%에서 49.5%까지 뛰고, DBRX-instruct는 32K에서 답하는 대신 컨텍스트를 요약해 버리는 빈도가 50%를 넘는다. 컨텍스트 윈도우가 광고된 크기라고 해서 그 안에서 실제 추론 품질이 유지되는 게 아니라는 뜻이다.
이전 글에서도 언급했지만, Claude Opus의 1M 컨텍스트도 실사용에서는 300K 부근부터 결과 품질이 빠르게 무너진다. ‘Lost in the Middle’이라는 이름으로 알려진 현상도 같은 맥락이다. 관련 정보가 컨텍스트의 시작이나 끝이 아니라 중간에 위치하면, 같은 모델이 같은 질문에서 10~25%까지 정확도가 떨어진다는 보고가 여러 벤치마크에서 일관되게 나온다. 자기회귀 트랜스포머 구조에서 어쩌면 자연스러운 결과지만, ‘컨텍스트에 다 부어 넣으면 된다’는 가정이 그대로 통하지는 않는다는 점은 분명하다.
비용과 지연시간 문제도 남는다. 단일 호출의 토큰 단가가 떨어졌다고 해도, 1M 토큰을 매 요청마다 보내면 누적 비용은 빠르게 커진다. 실제 운영 사례에서 보면, 같은 질문 패턴을 RAG로 처리할 때와 long context로 처리할 때의 비용 차이가 1,000배 단위로 벌어지는 경우가 흔하다. 응답 시간도 마찬가지다. 200K~1M 토큰을 매번 처리하면 첫 토큰이 나오기까지 수십 초가 걸리는데, 챗봇이나 검색형 인터페이스에서는 사용자가 기다려 주지 않는다. 사내 정책 Q&A처럼 한 번에 한 질문이면 모를까, 트래픽이 많은 서비스에서는 retrieval로 컨텍스트를 줄여 두는 편이 거의 항상 유리하다.
데이터 규모와 신선도 문제도 짚어야 한다. 1M 토큰이 단행본 한 권 분량이라고 해도, 실제 엔터프라이즈 지식 베이스는 테라바이트 단위인 경우가 보통이다. 컨텍스트 윈도우가 10M으로 늘어나도 전체의 1%를 못 본다. 데이터가 분 단위로 바뀌는 도메인에서는 매번 데이터를 컨텍스트에 다시 부어 넣는 것보다 인덱스를 갱신하는 편이 자연스럽다. 컴플라이언스나 감사 로그처럼 ‘어느 문서에서 이 답을 끌어왔는가’가 답변 자체보다 중요한 경우에도 retrieval 단계의 구분이 필요하다.
이러한 흐름의 결과로, 2025년 말부터 자리를 잡고 있는 패턴이 ‘Retrieval-Augmented Long Context’다. RAG와 long context를 경쟁 관계가 아니라 직렬로 잇는 구성이다. 거대한 코퍼스에서 retrieval 단계가 50K~300K 토큰 정도의 후보를 골라낸다. 이때 retrieval은 굳이 정밀할 필요가 없다. recall 위주로 후보를 넉넉히 잡고, 다음 단계의 long-context 모델이 그 안에서 진짜 관련 정보를 골라 추론한다. retrieval 쪽에서 BM25 같은 lexical 검색만 써도 큰 문제가 없는 경우가 많다. BEIR 벤치마크에서도 BM25가 zero-shot 환경에서 여전히 최상위권 임베딩 모델과 경쟁한다는 결과가 꾸준히 나오고 있다.
retrieval과 long context를 함께 쓸 때 자주 거론되는 보완책 중 하나가 Anthropic이 2024년에 공개한 Contextual Retrieval이다. chunk를 그대로 임베딩하지 않고, 각 chunk를 원본 문서 전체의 맥락 안에서 한 번 요약/리라이팅한 뒤 임베딩한다. chunk 경계 문제로 retrieval이 헛다리를 짚는 비율을 35~50% 정도 줄였다는 보고가 함께 따라붙었다. lexical과 vector를 같이 쓰고, 마지막에 reranker를 한 단계 더 끼우는 구성도 같은 맥락의 보강이다.
Google DeepMind가 EMNLP 2024에서 발표한 비교 평가와 LaRA(ICML 2025)의 결론도 이 그림과 잘 맞는다. 자원이 충분할 때 long context가 평균 품질에서 RAG를 앞서지만, 토큰 효율과 지연시간을 함께 보면 RAG가 여전히 유리하고, 어떤 쪽이 더 낫다고 단언하기 어려울 만큼 태스크와 모델에 따라 결과가 갈린다는 것이다.
정리
적어도 아직까지는 RAG와 long context는 병행하여 사용되어야 하고, 그 비중은 아래의 기준들에 의해 결정된다고 보는 것이 현실적인 듯 하다.
1) 데이터 규모: 컨텍스트 윈도우 안에 들어갈 수 있는 분량이라면 long context로 단순화하는 편이 거의 항상 좋다. 인프라 부담이 사라지고, chunking 경계 문제도 사라진다. 사내 위키 한 섹션, 단일 제품 매뉴얼, 한 프로젝트의 코드베이스 정도라면 retrieval 없이 통째로 부어 넣고 시작해도 무방하다.
2) 호출 빈도와 지연 요건: 같은 컨텍스트 위에서 사용자 질문이 반복되는 구조라면 prompt caching과 long context의 조합이 유리하다. 반대로 매 요청마다 다른 도메인의 다른 데이터가 필요한 고트래픽 서비스라면, retrieval로 컨텍스트를 줄여 두는 편이 비용과 응답 시간 모두에서 유리하다.
3) 데이터가 만들어진 시점과 출처 추적: 데이터가 자주 바뀌고, 답변에 어느 문서를 참조했는지 명시해야 하는 도메인 — 법률, 금융, 의료, 보안 — 에서는 retrieval 단계 자체가 빠지기 어렵다. long context로 통째로 처리해도 출처를 모델 출력으로부터 사후 추적해야 하는데, 이 과정 자체가 retrieval과 비슷한 일을 한 번 더 하는 것이 된다.
4) retrieval 자체의 단순화 여부: 굳이 벡터 DB를 새로 세우지 않더라도, 파일 시스템 grep, SQLite FTS5, PostgreSQL의 full-text search만으로 충분한 경우가 많다. ‘RAG를 쓴다’와 ‘벡터 DB를 운영한다’는 같은 의미가 아니다. 코딩 에이전트들이 grep만으로 잘 돌아가는 것을 보면, 어떤 종류의 retrieval이 자기 도메인에 적합한지를 다시 점검해 보는 편이 좋다.