요즘 frontier 모델에는 1M context가 낯설지 않습니다. GPT-6 Astra도 약 105만 토큰의 context window를 제공합니다.
그러면 자연스럽게 질문이 생깁니다.
문서를 전부 넣을 수 있는데 RAG가 아직 필요할까?
결론부터 말하면 컨텍스트 크기와 retrieval은 해결하는 문제가 다릅니다.
Context Window는 저장소가 아닙니다
context window는 한 요청에서 모델이 참고할 수 있는 입력 범위입니다.
Database / Files
↓
필요한 내용을 prompt에 넣음
↓
Context Window
↓
Model response
1M context가 있다고 해서 모델 안에 문서가 영구 저장되는 것은 아닙니다. 다음 요청에서 같은 자료가 필요하면 다시 제공하거나 session/harness가 상태를 유지해야 합니다.
긴 컨텍스트는 가격 구조도 달라질 수 있습니다
GPT-6 Astra API는 1,050,000 토큰 context를 지원하지만, 공식 문서상 입력이 272K 토큰을 넘는 prompt는 더 높은 long-context 요율이 적용됩니다.
즉 "들어간다"와 "경제적이다"는 다른 질문입니다.
예를 들어 600K 토큰 문서 묶음을 매 요청마다 그대로 보낸다면:
질문 1 → 600K 입력
질문 2 → 다시 600K 입력
질문 3 → 다시 600K 입력
비용과 latency가 커질 수 있습니다.
RAG는 '못 넣어서'만 쓰는 기술이 아닙니다
RAG의 핵심 가치는 필요한 근거를 좁혀주는 것에도 있습니다.
전체 600K tokens
↓ retrieval
관련 8K tokens
↓
LLM
이 구조는 비용뿐 아니라 다음에도 도움이 됩니다.
- 어떤 근거를 사용했는지 추적
- 문서별 권한 제어
- 자주 바뀌는 자료 업데이트
- source citation
- 대규모 corpus 확장
따라서 context window가 커져도 retrieval의 운영상 장점은 남습니다.
그렇다면 Long Context가 더 좋은 경우는?
반대로 retrieval이 문맥을 잘라버리면 안 되는 작업도 있습니다.
예:
- 계약서 전체 조항의 상호 관계 검토
- 한 repository의 architecture 전체 파악
- 긴 인터뷰/회의의 흐름 분석
- 여러 문서 사이의 넓은 비교
이런 경우에는 넓은 context를 유지하는 것이 유리할 수 있습니다.
CodeBridge Mini Lab: Full Context vs Retrieval
같은 문서 묶음에 같은 질문 20개를 준비합니다.
A 방식:
모든 문서를 매번 prompt에 포함
B 방식:
retrieval top-k
→ 관련 chunk만 모델에 전달
측정합니다.
answer correctness
source correctness
input tokens
latency
cost per question
특히 질문을 한 개가 아니라 여러 개로 해야 합니다. Long context의 비용 문제는 반복 질문에서 더 잘 드러납니다.
Hybrid가 현실적인 경우가 많습니다
둘 중 하나를 고를 필요도 없습니다.
RAG로 후보 문서 선택
↓
관련 문서 전체 또는 넓은 구간 로드
↓
Long-context model로 종합
이 구조는 retrieval이 너무 작은 chunk만 가져오는 문제와 전체 corpus를 매번 넣는 비용을 절충할 수 있습니다.
결론: 1M Context는 RAG의 종료가 아니라 선택지가 하나 늘어난 것입니다
큰 context window는 매우 강력합니다. 하지만 데이터가 커질수록 비용, 권한, 최신성, 근거 추적 같은 문제가 남습니다.
그래서 질문은:
RAG가 필요하냐, 1M context가 필요하냐?
가 아니라:
이 작업에서 어떤 정보는 미리 좁히고, 어떤 정보는 넓게 유지해야 하는가?
가 더 유용합니다.