Long Context vs RAG (Long Context vs RAG, 롱 컨텍스트 vs RAG)
2026.10.03 · 17분
1. 어떤 질문인가?
LLM의 컨텍스트 윈도우(Context Window)는 한 번의 요청에 넣을 수 있는 토큰의 최대 양입니다. 이 크기가 빠르게 커졌습니다. 2026년 10월 기준 Anthropic의 주력 모델(Claude Opus 5.5, Sonnet 5.5 등)은 100만(1M) 토큰 컨텍스트를 지원합니다. Anthropic 문서 기준으로 1M 토큰은 대략 영어 55만 단어 분량입니다.
그러자 이런 질문이 나왔습니다.
문서를 통째로 넣을 수 있다면, 굳이 청킹하고 임베딩하고 검색하는 RAG가 필요할까?
[RAG]
문서 1000개 ──> 청킹·임베딩·인덱스
질문 ──> 검색 ──> 관련 청크 5개 ──> LLM (컨텍스트: 수천 토큰)
[Long Context (통째로 넣기)]
문서 전체 ──────────────────────> LLM (컨텍스트: 수십만 토큰)
질문 ──────────────────────────────┘시험에 비유하면 다음과 같습니다.
| 구분 | 비유 | 특징 |
|---|---|---|
| RAG | 오픈북 시험인데 책은 사서가 찾아 준 몇 페이지만 볼 수 있다 | 빠르고 싸지만, 사서가 잘못 찾으면 끝이다 |
| Long Context | 책 전체를 책상에 펼쳐 놓고 시험을 본다 | 빠뜨릴 걱정은 적지만, 책이 두꺼울수록 찾는 데 시간이 걸리고 중간 내용을 놓치기도 한다 |
| CAG | 시험 전에 책을 미리 읽고 메모해 둔 상태로 들어간다 | 매번 처음부터 읽지 않아 빠르다. 단, 책이 바뀌면 다시 읽어야 한다 |
결론부터 말하면 둘은 상황에 따라 고르는 선택지입니다. 코퍼스 크기, 최신성, 권한, 비용, 지연 요구에 따라 고르거나 섞습니다.
2. 문서를 통째로 넣으면 좋은 점
| 장점 | 설명 |
|---|---|
| 검색 실패가 없다 | RAG의 가장 흔한 실패 원인인 "관련 청크를 못 찾음"이 사라진다 |
| 청킹으로 인한 맥락 손실이 없다 | 표, 각주, "앞에서 말한 바와 같이" 같은 참조가 그대로 살아 있다 |
| 전체를 봐야 하는 질문에 강하다 | "이 계약서에서 우리에게 불리한 조항을 모두 찾아라", "이 보고서를 요약하라" |
| 구현이 단순하다 | 임베딩 모델, 벡터 DB, 청킹 전략, 리랭커가 필요 없다 |
| 문서 간 비교가 쉽다 | 두 버전의 계약서를 나란히 넣고 차이를 묻는다 |
RAG는 전체를 훑어야 하는 질문에 특히 약합니다. "불리한 조항을 모두"라는 질문에 Top-5 청크만 가져오면 6번째 조항은 영영 보지 못합니다.
3. 통째로 넣기의 단점
3-1. Lost in the Middle
Lost in the Middle(Liu 외, 2023)은 긴 컨텍스트에서 관련 정보의 위치에 따라 성능이 달라진다는 것을 보인 연구입니다. 다중 문서 QA와 키-값 검색 실험에서 관련 정보가 맨 앞이나 맨 끝에 있을 때 성능이 가장 높고, 중간에 있을 때 크게 떨어지는 U자 곡선이 나타났습니다.
정확도
▲
│ ● ●
│ ● ●
│ ● ●
│ ● ● ● ●
│
└──────────────────────────────────▶ 관련 정보의 위치
맨 앞 중간 맨 끝이 연구는 2023년 당시 모델로 실험한 것입니다. 이후 모델들은 긴 컨텍스트 처리가 많이 개선되었지만, "길이가 길어질수록, 위치에 따라 성능이 흔들린다"는 경향 자체는 이후 연구에서도 계속 관찰됩니다.
3-2. Context Rot
Chroma의 기술 보고서 Context Rot(2025)은 18개 LLM을 대상으로 입력 길이가 늘어날수록 성능이 고르지 않고 점점 불안정해진다는 결과를 보고했습니다. 단순한 과제에서도 길이가 늘면 정확도가 떨어졌고, 방해 문장(Distractor)이나 문서 구조의 작은 변화에도 결과가 크게 흔들렸습니다. 컨텍스트에 넣을 수 있다고 해서 모델이 그 내용을 잘 활용한다는 보장은 없습니다.
3-3. 비용
LLM API는 대개 입력 토큰 수에 비례해 과금합니다.
RAG: 질문마다 입력 ≈ 시스템 프롬프트 + 청크 5개 (수천 토큰)
Long Context: 질문마다 입력 ≈ 시스템 프롬프트 + 문서 전체 (수십만 토큰)같은 질문을 하루 1만 번 받는다면, 질문마다 문서 전체를 다시 보내는 비용은 RAG보다 입력 토큰 비율만큼 커집니다. 이 문제를 줄이는 것이 5장의 프롬프트 캐싱입니다.
3-4. 지연 시간
모델은 답을 쓰기 전에 입력 전체를 처리(Prefill)해야 합니다. 입력이 길수록 첫 토큰이 나오기까지의 시간(TTFT, Time To First Token)이 길어집니다. 대화형 서비스에서는 체감이 큽니다.
3-5. 단점 정리
| 단점 | 원인 |
|---|
4. CAG (Cache-Augmented Generation)
4-1. 아이디어
CAG는 2024년 12월 논문 "Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks"(Chan 외)에서 제안된 방식입니다. 실시간 검색을 아예 없애는 것이 핵심입니다.
- 지식 베이스 전체를 미리 모델 컨텍스트에 넣는다.
- 그때 계산된 모델의 KV 캐시를 저장해 둔다.
- 질문이 오면 저장된 KV 캐시 뒤에 질문만 붙여 바로 생성한다.
[준비 단계 (1회)]
지식 문서 전체 ──> LLM 순전파 ──> KV 캐시 저장
[질문 단계 (매번)]
KV 캐시 불러오기 + 질문 토큰 ──> 생성
(문서를 다시 처리하지 않는다)
[다음 질문 전]
캐시 뒤에 붙었던 질문/답 토큰을 잘라내고 원래 캐시로 되돌린다논문은 이 방식이 검색 지연과 문서 선택 오류를 없애고 시스템 구조를 단순하게 만든다고 주장합니다. 다만 지식 베이스가 컨텍스트 윈도우에 들어갈 만큼 작고 자주 바뀌지 않아야 한다는 전제가 붙습니다.
4-2. KV 캐시란?
트랜스포머는 토큰마다 어텐션 계산에 쓰는 Key, Value 벡터를 만듭니다. 생성 중에는 앞 토큰들의 K, V를 매번 다시 계산하지 않도록 저장해 두는데, 이것이 KV 캐시입니다.
입력: [문서 토큰 50만 개] [질문 토큰 30개]
└── 여기의 K, V를 미리 계산해 저장해 두면
다음 질문 때 이 부분 계산(Prefill)을 건너뛴다| 구분 | 설명 |
|---|---|
| 무엇을 저장하나 | 각 레이어, 각 토큰의 Key/Value 텐서 |
| 왜 빨라지나 | 긴 문서 부분의 Prefill 계산을 다시 하지 않는다 |
| 제약 | 앞부분(Prefix)이 똑같아야 재사용할 수 있다. 문서 한 글자만 바뀌어도 그 뒤는 다시 계산한다 |
5. 프롬프트 캐싱
5-1. 개념
프롬프트 캐싱(Prompt Caching)은 API 제공자가 요청의 앞부분(Prefix)을 서버 쪽에 캐싱해 두고, 같은 Prefix로 시작하는 다음 요청에서 재사용하는 기능입니다. 사용자는 KV 캐시를 직접 다루지 않고, "여기까지 캐싱해 달라"고 표시만 합니다.
| 제공자 | 방식 (2026-10 기준 문서) |
|---|---|
| Anthropic | cache_control로 캐시 지점을 지정 (최대 4개) 또는 요청 최상위에 두어 자동 지정. 기본 TTL 5분, 1시간 옵션 |
| OpenAI | 일정 길이(1,024 토큰) 이상 프롬프트에 자동 적용, 응답의 cached_tokens로 확인 |
5-2. Anthropic 프롬프트 캐싱 요점
| 항목 | 내용 |
|---|---|
| 캐시 순서 | tools → system → messages 순서로 Prefix를 이룬다. 앞 단계가 바뀌면 그 뒤 캐시는 모두 무효 |
| TTL | 기본 5분 (사용할 때마다 갱신), "ttl": "1h"로 1시간 |
6. 그래도 RAG가 필요한 이유
6-1. 코퍼스 크기
1M 토큰 컨텍스트 ≈ 두꺼운 책 몇 권
사내 위키 + 계약서 + 티켓 + 매뉴얼 = 수억~수십억 토큰컨텍스트가 아무리 커져도 기업 지식 전체는 들어가지 않습니다. 들어간다 해도 3장의 성능 저하와 비용 문제가 커집니다. 그래서 어떤 형태로든 무엇을 넣을지 고르는 단계, 즉 검색이 필요합니다.
6-2. 최신성
| 상황 | Long Context / CAG | RAG |
|---|---|---|
| 문서가 하루 한 번 바뀐다 | 하루 한 번 캐시 재생성: 괜찮다 | 괜찮다 |
| 문서가 1분마다 바뀐다 (재고, 티켓, 채팅) | 캐시가 계속 깨진다 | 바뀐 문서만 재인덱싱 |
| 문서 하나가 추가된다 | Prefix 중간에 끼우면 그 뒤 캐시 무효 | 인덱스에 하나 추가 |
6-3. 권한
사용자 A (영업팀) → 영업 문서만 볼 수 있다
사용자 B (인사팀) → 인사 문서만 볼 수 있다문서를 통째로 넣는 방식은 사용자마다 다른 문서 묶음을 넣어야 하고, 그러면 캐시를 공유하기 어렵습니다. 권한 경계가 복잡하면 검색 단계에서 권한 필터를 거는 RAG가 훨씬 자연스럽습니다. 모든 문서를 넣고 "B에게는 인사 문서만 말해"라고 지시하는 것으로는 보안을 통제할 수 없습니다. 프롬프트 인젝션 한 번이면 뚫립니다.
6-4. 비용과 지연
| 요인 | Long Context가 불리해지는 조건 |
|---|
7. 결정 표
| 조건 | 추천 | 이유 |
|---|---|---|
| 문서가 컨텍스트에 넉넉히 들어가고 거의 안 바뀐다 | 통째로 + 캐싱 (CAG) | 검색 실패가 없고 단순하다 |
| 문서 하나를 깊이 분석 (요약, 전체 조항 검토, 비교) | 통째로 | 전체를 봐야 하는 질문 |
| 코퍼스가 컨텍스트보다 훨씬 크다 | RAG | 들어가지 않는다 |
| 문서가 자주 바뀐다 | RAG | 증분 인덱싱 |
| 사용자별 권한이 다르다 | RAG (검색 시 권한 필터) | 프롬프트로는 보안 통제가 안 된다 |
| 질문이 많고 지연·비용이 중요하다 | RAG (또는 캐시가 잘 맞는 CAG) | 질문당 입력 토큰이 작다 |
| 길고 구조화된 문서 몇 개 | 통째로 또는 |
8. 혼합 전략
실무에서는 둘을 섞어 쓰는 경우가 많습니다.
8-1. 검색으로 좁히고, 넓게 넣는다
질문 ──> RAG 검색 (문서 단위로 Top-3)
│
▼
청크 5개가 아니라 **문서 3개 전체**를 컨텍스트에 넣는다
│
▼
LLM긴 컨텍스트 덕분에 청크 대신 문서를 통째로 넣을 수 있게 되었습니다. 검색은 "어느 문서인가"만 맞히면 되므로 난도가 낮아지고, 청킹으로 인한 맥락 손실도 줄어듭니다.
8-2. 고정 지식은 캐시, 변하는 지식은 검색
[캐싱되는 Prefix]
시스템 프롬프트
회사 정책 문서 (자주 안 바뀜, 모든 사용자 공통) ← cache_control
[매 요청 바뀌는 부분]
RAG로 찾은 최신 티켓/재고/사용자별 문서
사용자 질문공통이고 안정적인 지식은 캐시로, 개인적이고 자주 바뀌는 지식은 검색으로 나눕니다.
8-3. 에이전트가 필요할 때만 불러온다
에이전트가 처음에는 가벼운 색인(파일 목록, 목차)만 들고 있다가 필요할 때 도구로 문서를 열어 보는 방식입니다. Anthropic은 이를 "Just-in-time" 컨텍스트라고 부릅니다. 컨텍스트를 필요한 만큼만 채운다는 점에서 Long Context와 RAG의 중간쯤에 있습니다. (Agentic RAG 노트 참고)
8-4. 혼합 전략 비교
| 전략 | 검색 역할 | 긴 컨텍스트 역할 | 적합한 경우 |
|---|---|---|---|
| 좁히고 넓게 넣기 | 문서 선택 | 선택된 문서 전체 읽기 | 문서 단위 질문이 많다 |
| 고정 캐시 + 동적 검색 | 변하는 지식 | 공통 지식 (캐싱) | 공통 정책 + 개인 데이터 |
9. 장점과 단점 요약
| Long Context (+캐싱) | RAG | |
|---|---|---|
| 검색 실패 | 없음 | 있음 (가장 흔한 실패 원인) |
| 맥락 보존 | 좋음 | 청킹에 따라 손실 |
| 전체 훑기 질문 | 강함 | 약함 |
| 규모 | 윈도우 한계 | 사실상 무제한 |
| 최신성 | 캐시 재생성 필요 | 증분 인덱싱 |
| 권한 | 어려움 | 검색 필터로 자연스러움 |
| 질문당 비용 | 큼 (캐싱으로 완화) | 작음 |
| 첫 응답 지연 | 김 (캐시 히트 시 완화) | 짧음 |
| 구현 복잡도 | 낮음 | 높음 (청킹, 임베딩, 인덱스, 평가) |
10. 참고 자료
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts (2023, TACL 2024): https://arxiv.org/abs/2307.03172
- Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance (2025): https://research.trychroma.com/context-rot
- Chan et al., Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks (2024): https://arxiv.org/abs/2412.15605
- CAG 구현 저장소: https://github.com/SpeedReach/CAG
- Claude API 문서, Prompt caching: https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- Claude API 문서, Models overview (컨텍스트 윈도우): https://platform.claude.com/docs/en/about-claude/models/overview
- OpenAI Cookbook, Prompt Caching 101: https://developers.openai.com/cookbook/examples/prompt_caching101
- Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
기준일: 2026-10-03
11. 핵심 정리
컨텍스트 윈도우가 100만 토큰급으로 커지면서 "문서를 통째로 넣으면 RAG가 필요 없지 않나?"라는 질문이 생겼다. 통째로 넣으면 검색 실패와 청킹 손실이 없고 전체를 훑는 질문에 강하지만, 중간 정보를 놓치는 Lost in the Middle, 길이에 따라 성능이 흔들리는 Context Rot, 질문마다 커지는 비용과 첫 응답 지연이 문제다. CAG는 지식 문서의 KV 캐시를 미리 만들어 재사용해 검색을 없애는 방식이고, API 환경에서는 변하지 않는 문서를 Prefix에 두고 프롬프트 캐싱을 거는 것이 실용적인 CAG다. 그래도 코퍼스가 윈도우보다 크거나, 자주 바뀌거나, 사용자별 권한이 다르거나, 질문당 비용·지연이 중요하면 RAG가 필요하다. 실무에서는 검색으로 문서를 고르고 문서 전체를 넣거나, 공통 지식은 캐싱하고 변하는 지식은 검색하는 혼합 전략이 흔하다.