RAG vs 롱 컨텍스트 — LLM에 데이터 주입, 어떤 방식이 정답일까

핵심 메시지

• LLM은 학습 시점에 멈춰 있어 최신 정보나 내부 데이터를 모르므로 '컨텍스트 주입' 문제를 풀어야 한다.
• RAG는 문서를 청크로 나눠 벡터 DB에 저장하고 의미 검색으로 관련 부분만 찾아 주입하는 공학적 접근이다.
• 롱 컨텍스트는 문서를 통째로 컨텍스트 창에 넣어 모델의 어텐션이 답을 찾게 하는 단순한 접근이다.
• 롱 컨텍스트는 인프라 단순화·검색 실패 제거·문서 전체 비교라는 강점이 있다.
• RAG는 재처리 비용 절감·대규모 컨텍스트의 집중력 저하 방지·무한한 기업 데이터 대응에서 여전히 유효하다.

쉽게 이해하기

영상은 LLM의 근본적 한계에서 출발한다. LLM은 학습 마감 시점 이후의 세상이나 사용자의 사적 데이터, 사내 위키, 독점 코드베이스에 대해 전혀 알지 못한다. 그래서 ' 어떻게 적절한 데이터를 적절한 시점에 모델에 넣을 것인가'라는 컨텍스트 주입 문제가 생기고, 이를 푸는 두 가지 상반된 방식을 비교한다.

첫 번째는 공학적 접근인 RAG(검색 증강 생성)다. 미리 PDF·코드·책 같은 문서를 작은 청크로 쪼개 임베딩 모델로 벡터화하고 전용 벡터 데이터베이스에 저장한다. 사용자가 질문하면 의미 검색으로 가장 관련 있는 청크를 찾아 사용자 프롬프트와 함께 컨텍스트 창에 주입한다. 다만 이 방식은 검색 로직이 실제로 올바른 정보를 찾아냈다는 '희망'에 의존한다.

두 번째는 더 단순한 롱 컨텍스트 방식이다. 데이터베이스와 임베딩 모델을 건너뛰고 문서를 그대로 컨텍스트 창에 넣은 뒤, 모델의 어텐션 메커니즘이 답을 찾도록 맡긴다. 과거에는 컨텍스트 창이 4K 토큰 수준으로 작아 불가능했지만, 오늘날 일부 모델은 100만 토큰(약 70만 단어, 반지의 제왕 전권 분량)을 넘어서며 선택지가 됐다.

영상은 롱 컨텍스트의 장점 세 가지를 든다. 첫째, 청킹·임베딩·벡터 DB·리랭커 등 무거운 인프라를 걷어내 구조가 단순해진다. 둘째, 확률적 의미 검색이 관련 문서를 못 찾아 답이 있어도 모델이 못 보는 '조용한 실패'가 사라진다. 셋째, 요구사항 문서와 릴리스 노트처럼 두 문서의 '빠진 부분(공백)'을 비교해야 할 때, 단편만 보는 RAG와 달리 전체를 넣어 비교가 가능하다.

그렇다고 RAG가 끝난 것은 아니다. 첫째, 롱 컨텍스트는 매 질의마다 문서 전체를 토큰으로 처리해 비효율적인 반면 RAG는 색인 시점에 한 번만 처리한다(프롬프트 캐싱은 정적 데이터에만 부분적 도움). 둘째, 컨텍스트가 커질수록 어텐션이 희석돼 깊이 묻힌 문단을 놓치거나 환각이 생기는데, RAG는 상위 몇 개 청크만 줘 잡음을 줄인다. 셋째, 테라바이트·페타바이트급 기업 데이터는 컨텍스트 창에 다 들어갈 수 없어 검색 계층이 필요하다. 결론적으로 경계가 분명한 데이터의 전역적 추론은 롱 컨텍스트가, 무한한 기업 데이터는 RAG가 적합하다.

주요 인사이트

• RAG와 롱 컨텍스트는 대립이 아니라 데이터의 성격에 따라 갈리는 선택지다. 경계가 분명하면 롱 컨텍스트, 무한히 커지면 RAG가 답이다.
• '조용한 실패'는 답이 데이터에 있는데도 검색이 못 찾아 모델이 보지 못하는 RAG의 치명적 약점으로, 롱 컨텍스트는 이 단계를 아예 없앤다.
• 컨텍스트 창이 크다고 무조건 좋은 것은 아니다. 100만 토큰 속에 묻힌 한 문단은 어텐션 희석으로 오히려 놓치거나 환각을 부를 수 있다.
• RAG의 진짜 비용 우위는 문서를 '색인 시 한 번만' 처리한다는 점이며, 자주 바뀌는 동적 데이터에서는 프롬프트 캐싱으로도 이 이점을 대체하기 어렵다.
• '문서에 없는 것'을 물을 때 RAG는 단편만 검색해 공백을 못 보지만, 전체를 넣는 롱 컨텍스트는 누락된 부분까지 비교해낼 수 있다.

자주 묻는 질문

관련 AI 소식