RAG vs. 긴 컨텍스트 윈도우, 뭘 써야 할까?

RAG 컨텍스트 윈도우 아키텍처 선택 트레이드오프

RAG vs. 긴 컨텍스트 윈도우
"그냥 다 넣으면 안 되나?"

Claude는 200K 토큰, Gemini는 1M 토큰. 모델들의 컨텍스트 창이 폭발적으로 커졌습니다. 그렇다면 RAG는 이제 구시대 기술일까요? 비용·정확도·지연 시간·유지 보수 네 가지 축으로 냉정하게 따져봅니다.

2025 · 06 · 08 읽는 시간 약 14분 난이도 중급

왜 이 질문이 지금 중요한가

2023년까지만 해도 LLM의 컨텍스트 창은 4K~8K 토큰이 전부였습니다. 긴 문서를 처리하려면 RAG(Retrieval-Augmented Generation)가 사실상 유일한 선택지였죠. 그런데 지금은 다릅니다.

수백 페이지의 PDF도 통째로 집어넣을 수 있게 됐습니다. 덕분에 "그냥 다 넣으면 되는 거 아닌가요?"라는 질문이 자연스럽게 나옵니다. 실제로 일부 작업에선 이게 맞는 답입니다. 하지만 늘 그런 건 아닙니다.

핵심 전제

RAG와 긴 컨텍스트는 경쟁 관계가 아닙니다. 각자 잘하는 영역이 다른 보완적 도구입니다. "무엇이 더 좋은가"가 아니라 "언제 무엇을 쓸 것인가"가 올바른 질문입니다.

두 접근 방식 한눈에 보기

RAG — Retrieval-Augmented Generation

질문과 관련된 청크만 선별해 LLM에 전달

벡터 DB + 임베딩 모델 인프라 필요

문서 수가 늘어도 입력 토큰은 일정

검색 품질이 전체 품질을 좌우

문서 업데이트 시 인덱스만 갱신

Long Context — 전체 문서 삽입

모든 문서를 프롬프트에 그대로 삽입

추가 인프라 없이 API 호출 한 번으로 완결

문서량 비례로 입력 토큰·비용 증가

검색 단계 없어 "Lost in the Middle" 위험

구현 단순, 프로토타입에 즉시 적용 가능

네 가지 축으로 비교하기

추상적인 장단점 대신, 실제 결정에 영향을 미치는 네 가지 지표를 직접 비교해 봅시다.

// tradeoff analysis — relative scores (higher = better)

비용 효율 (대용량 문서 기준) RAG ▪ 높음 Long CTX ▪ 낮음

구현 단순성 RAG ▪ 낮음 Long CTX ▪ 높음

응답 속도 (첫 토큰까지) RAG ▪ 중간 Long CTX ▪ 낮음

전체 맥락 파악 정확도 RAG ▪ 중간 Long CTX ▪ 높음

실시간 문서 업데이트 대응 RAG ▪ 높음 Long CTX ▪ 높음

RAG

Long Context

비용: 숫자로 이해하기

"다 넣으면 된다"는 생각이 무너지는 첫 번째 지점이 바로 비용입니다. Claude Sonnet 기준으로 간단히 계산해 봅시다.

시나리오	입력 토큰	1,000회 호출 비용 (추정)	방식
사내 위키 Q&A (500페이지)	~400K/호출	~$1,200	Long Context
사내 위키 Q&A (500페이지)	~3K/호출	~$9	RAG (Top-5 청크)
계약서 단건 검토 (30페이지)	~24K/호출	~$72	Long Context
계약서 단건 검토 (30페이지)	~24K/호출	~$72	RAG (비효율, 비추천)

⚠ 주의

문서가 수십 페이지 이하 단건이라면 Long Context가 합리적입니다. 하지만 동일한 대규모 문서 집합에 반복적으로 질의하는 구조라면 비용 차이가 수백 배까지 벌어질 수 있습니다.

정확도: Lost in the Middle 문제

긴 컨텍스트의 가장 큰 함정은 "Lost in the Middle" 현상입니다. LLM은 컨텍스트의 앞부분과 뒷부분은 잘 기억하지만, 중간 부분의 정보는 상대적으로 소홀히 처리하는 경향이 있습니다.

연구 배경

2023년 Stanford 연구에 따르면 관련 문서가 컨텍스트 중간에 위치할 때 모델 성능이 최대 20%포인트 이상 하락하는 것이 관찰됐습니다. 이는 긴 컨텍스트를 사용할 때 문서 순서 설계가 중요함을 시사합니다.

반면 RAG는 검색 단계에서 이미 관련 청크를 선별하므로, LLM에게 전달되는 정보의 밀도가 높습니다. 단, RAG의 정확도는 검색 품질에 강하게 의존합니다— 검색이 실패하면 정답이 있어도 모델이 볼 수 없습니다.

하이브리드 접근: 실전 구현

실제로는 두 방식을 함께 사용하는 것이 가장 강력합니다. RAG로 후보 청크를 좁히고, 그 청크들을 컨텍스트로 넘기는 패턴입니다.

청크 검색 + LLM 호출 파이프라인

from anthropic import Anthropic
from typing import Protocol

client = Anthropic()

class VectorStore(Protocol):
    def search(self, query: str, top_k: int) -> list[dict]: ...

def rag_query(
    question: str,
    store: VectorStore,
    top_k: int = 5,
    rerank: bool = True
) -> str:
    # 1단계: 벡터 검색으로 후보 청크 수집
    chunks = store.search(question, top_k=top_k * 2)

    # 2단계: 선택적 재순위화 (LLM-as-reranker)
    if rerank:
        chunks = llm_rerank(question, chunks, top_k)

    # 3단계: 컨텍스트 조립
    context = "\n\n---\n\n".join(
        f"[출처: {c['source']}, 페이지 {c['page']}]\n{c['text']}"
        for c in chunks[:top_k]
    )

    # 4단계: LLM 호출
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=2048,
        system="""당신은 제공된 문서만을 근거로 답변합니다.
문서에 없는 내용은 '문서에서 확인할 수 없습니다'라고 명시하세요.""",
        messages=[{
            "role": "user",
            "content": f"참고 문서:\n{context}\n\n질문: {question}"
        }]
    )
    return response.content[0].text


def llm_rerank(question: str, chunks: list, top_k: int) -> list:
    # 각 청크의 관련성을 LLM이 0-10으로 평가
    prompt = f"""다음 청크들을 질문과의 관련성 순으로 상위 {top_k}개 선별하세요.
질문: {question}
청크 목록: {[c['text'][:200] for c in chunks]}
JSON 배열로 인덱스만 반환: [0, 3, 1, ...]"""

    res = client.messages.create(
        model="claude-haiku-4-5-20251001",  # 저렴한 모델로 재순위화
        max_tokens=100,
        messages=[{"role": "user", "content": prompt}]
    )
    import json
    indices = json.loads(res.content[0].text)
    return [chunks[i] for i in indices[:top_k]]

결국 언제 무엇을 써야 하나

모든 상황을 커버하는 단일 규칙은 없지만, 실무에서 반복적으로 유효했던 의사결정 흐름을 정리했습니다.

// decision flow — which approach to pick

총 문서 크기가 컨텍스트 한도의 30% 이하인가?

↓

YES

Long Context 고려

NO

RAG 필수

↓ (Long Context 고려 시)

동일 문서셋에 하루 100회 이상 반복 질의하는가?

↓

YES

RAG로 전환 (비용)

NO

Long Context OK

↓ (복잡한 추론 작업)

문서 전체 맥락을 종합해야 하는가?

↓

YES

Hybrid (RAG + Long CTX)

NO

RAG 충분

한 줄 요약 정리

상황	추천	이유
소규모 문서 단건 분석 (≤50페이지)	Long Context	구현 간단, 비용 차이 미미
대규모 문서 반복 질의 (사내 위키, 매뉴얼)	RAG	비용 수십~수백 배 절감
프로토타입 / PoC	Long Context	빠른 검증, 인프라 불필요
프로덕션 (대용량)	RAG	비용·속도·확장성 모두 유리
복잡한 다문서 추론	Hybrid	RAG로 압축 → Long CTX로 종합
실시간 스트리밍 데이터	Long Context	인덱싱 지연 없이 즉시 처리

결론

긴 컨텍스트 윈도우는 RAG를 대체하지 않습니다. 프로토타입 속도가 필요하다면 Long Context, 프로덕션 규모의 비용과 성능이 필요하다면 RAG— 그리고 복잡한 추론이 필요하다면 둘을 함께 쓰는 것이 현실적인 답입니다.

다음 글에서는 RAG의 핵심 병목인 청크 전략과 하이브리드 검색(BM25 + 벡터)을 코드와 함께 심층적으로 다룰 예정입니다.