Context Rot, RAG, 그리고 Long Context: 2026년 LLM 시스템 아키텍처 설계 방법

2M 토큰 윈도가 더 이상 중요하지 않게 된 해

2024년 말과 2025년 초의 약 6개월간, 엔지니어링 슬랙 채널에서 익숙한 주장이 돌았습니다. RAG는 이제 한물갔다. 그냥 다 붙여 넣으면 된다.

논리는 깔끔해 보였습니다. Anthropic은 1M 토큰 컨텍스트 윈도를 가진 Claude Sonnet을 출시했습니다. Google은 Gemini 2.5와 2.5 Pro를 2M 토큰까지 끌어올렸습니다. Meta는 이론상 10M 토큰 한계를 가진 Llama 4 Scout를 발표했습니다. 지식 베이스가 하나의 프롬프트 안에 들어간다면, 굳이 벡터 스토어와 임베딩 파이프라인, 청킹 전략을 신경 쓸 이유가 무엇이겠습니까?

그러나 2025년 7월, Chroma Research가 Kelly Hong, Anton Troynikov, Jeff Huber의 "Context Rot: How Increasing Input Tokens Impacts LLM Performance"를 발표했습니다. 이 논문은 18개 최전선 모델을 대상으로 정밀한 실험을 수행했고, 마케팅 페이지에는 나오지 않는 사실을 보여주었습니다. long context 윈도는 한계에 도달하기 훨씬 전부터, 명확하지 않은 방식으로 성능이 저하됩니다. 200K 토큰 윈도가 50K 토큰 입력에서 심각한 정확도 손실을 보일 수 있습니다. 1M 토큰 윈도가 1M 토큰 전반에 걸쳐 안정적으로 추론하지는 않습니다.

이 결과는 아키텍처 논의의 프레임을 다시 짰습니다. RAG는 한물간 것이 아닙니다. Long context는 공짜 점심이 아닙니다. 흥미로운 질문은 더 이상 "어느 쪽이 이기느냐"가 아니라, "어떤 패턴이 이 데이터 형태, 지연 시간 예산, 신선도 요구사항에 맞느냐"가 되었습니다.

이 글은 그 아키텍처 수준의 답입니다. 언제 시스템이 검색해야 하고, 언제 덤프해야 하며, 언제 둘 다 해야 하는지 다룹니다.

Chroma 논문이 실제로 보여준 것

Chroma 논문을 자세히 읽어볼 가치가 있습니다. 헤드라인("context rot이 존재한다")만으로는 실제 내용을 충분히 전달하지 못하기 때문입니다. 연구팀은 GPT-4.1, Claude 4 계열(Opus 4와 Sonnet 4 포함), Gemini 2.5, Qwen3을 대상으로 needle-in-a-haystack(NIAH) 벤치마크의 확장 버전을 실행했습니다. GitHub에 공개된 재현 키트를 통해 실험을 재현할 수 있습니다.

세 가지 발견이 두드러집니다.

발견 1: 입력 길이가 길어질수록 성능이 비균일하게 저하됩니다. 이것이 핵심 결과입니다. 모델은 입력이 길어진다고 해서 선형적으로 천천히, 예측 가능한 속도로 나빠지지 않습니다. 절벽에 부딪힙니다. 어떤 모델은 32K에서는 괜찮다가 64K에서 무너집니다. 다른 모델은 버티다가 어느 순간 갑자기 무너집니다. 문서화된 컨텍스트 윈도의 크기는 모델이 실제로 그 컨텍스트를 얼마나 잘 활용하는지와는 약한 상관관계만 보입니다.

발견 2: 길이보다 의미적 유사성이 감쇠를 더 많이 좌우합니다. "needle"이 주변 "haystack"과 의미적으로 뚜렷이 구분될 때는 모델이 잘 찾아냅니다. 방해 요소가 정답과 의미적으로 유사할 때는 정확도가 가파르게 떨어지고, 그 하락은 길이가 길어질수록 더 심해집니다. 다시 말해, 정답을 노이즈와 구분하기 어려울수록 long context는 더 빨리 무너집니다. 이는 Liu et al. (2024), "Lost in the Middle: How Language Models Use Long Contexts" in TACL의 또 다른 결과와도 일치하는데, 이 논문은 long context의 중간 부분이 체계적으로 과소평가되는 U자 형태의 성능 곡선을 보여주었습니다.

발견 3 (놀라운 것): 구조적이고 일관된 텍스트가 셔플된 텍스트보다 어텐션을 더 많이 떨어뜨립니다. 이것이 엔지니어들의 사고방식을 바꿔야 할 결과입니다. 직관적으로는, 깔끔하고 잘 정리된 100K 토큰 문서가 뒤죽박죽인 100K 토큰 덩어리보다 모델이 추론하기 더 쉬울 것이라고 생각합니다. 데이터는 그 반대를 말합니다. 적어도 항상 그렇지는 않습니다. 일관성 있는 텍스트는 긴 시퀀스 전반에 어텐션을 더 분산시키는 것으로 보이는 반면, 셔플된 텍스트는 모델이 붙잡을 수 있는 더 뚜렷한 국소 신호를 만들어냅니다. 시사점은 이렇습니다. 깔끔하고 잘 포맷된 PDF를 모델에 먹이는 것이 지저분한 검색 결과 집합을 먹이는 것보다 자동으로 더 안전하지는 않습니다.

Sequential-NIAH 벤치마크(arXiv 2504.04713)는 모델이 long context의 서로 다른 부분에서 여러 번의 검색을 연결할 수 있는지 테스트함으로써 이를 더 확장합니다. 거리를 가로지르는 다단계 추론에서는 하락 폭이 훨씬 더 가파릅니다.

Hamel Husain은 context rot에 대한 자신의 노트에서 실질적 시사점을 잘 요약했습니다. 엔지니어링 자세는 "전부 집어넣자"가 아니라 "질문에 답할 수 있는, 가장 작고 가장 관련성 높은 컨텍스트를 모델에 주자"여야 합니다.

Long Context가 실패하는 이유: 메커니즘

메커니즘이 중요한 이유는 그것이 어떤 워크로드가 실패할지를 예측하기 때문입니다.

표준 트랜스포머 어텐션은 모든 토큰 쌍에 대해 softmax를 사용합니다. 시퀀스 길이 N이 커질수록 어텐션 가중치는 더 많은 위치에 분산됩니다. RoPE(rotary position embeddings)나 ALiBi 같은 상대적 위치 인코딩이 있어도, softmax의 분모는 커지고 단일 토큰에 할당되는 위치당 가중치는 줄어듭니다. 1M 토큰에서 "정답" 토큰은 유한한 어텐션 예산을 두고 999,999개의 다른 토큰과 경쟁해야 합니다.

위치 인코딩이 도움이 되지만 마법은 아닙니다. RoPE는 학습 길이를 훨씬 넘어선 외삽(extrapolation)에서 알려진 저하 곡선을 가집니다. 최대 32K 토큰 시퀀스로 학습된 모델을 1M 토큰에서 배포하면, 기저의 수학이 완전히 뒷받침하지 않는 외삽을 수행하는 셈입니다. YaRN, position interpolation, NTK-aware scaling 같은 기법이 사용 가능한 범위를 확장하지만, 어느 것도 1M 토큰을 32K처럼 효과적으로 활용하는 모델을 만들어내지는 못합니다.

학습 데이터 문제도 있습니다. 모델이 긴 시퀀스로 학습되더라도, 800K 토큰에 걸친 교차 컨텍스트 추론을 요구하는 예시는 드뭅니다. 모델은 학습 데이터가 사용하도록 가르친 컨텍스트의 부분을 사용하는 법을 배웁니다.

Context rot은 다음 릴리스에서 고쳐질 버그가 아닙니다. 아키텍처와 학습 분포의 속성입니다. 미래 모델은 한계를 더 밀어붙이겠지만, 기본적인 패턴은 한동안 지속될 것입니다.

RAG가 여전히 이기는 영역

Context rot을 감안할 때, 검색 증강 생성(retrieval-augmented generation)은 레거시 인프라가 아닙니다. 2026년에도 RAG가 계속 이기는 영역은 다음과 같습니다.

대규모 다문서 코퍼스. 지식 베이스가 50,000개 문서, 총 500M 토큰이라면, 어떤 컨텍스트 윈도에도 들어가지 않습니다. 검색이 유일하게 실현 가능한 아키텍처입니다.

신선도와 최신성. 벡터 스토어는 점진적으로 업데이트됩니다. Long context 프롬프트는 콘텐츠가 바뀔 때마다 프롬프트를 다시 구성해야 합니다. 시간 단위로 업데이트되는 문서(뉴스, 카탈로그, 지원 티켓, 코드 저장소)에 대해서는 검색이 변경을 저렴하게 처리합니다.

비용. 추론 비용은 입력 토큰에 거의 선형적으로 비례합니다. 200K 토큰을 보내는 것은 1K 토큰의 200배 비용입니다. 쿼리의 95%가 관련 토큰 5K로 답할 수 있다면, 검색은 정확도 손실 없이 40배의 비용 절감을 제공합니다.

인용과 출처. 검색은 보여주고, 링크하고, 순위를 매길 수 있는 구조화된 소스 문서 목록을 제공합니다. Long-context 출력은 추가적인 인용 추출 배관 작업 없이는 특정 출처에 근거를 두기 더 어렵습니다.

접근 제어와 테넌시. 코퍼스가 사용자별, 테넌트별, 역할별 가시성을 가진다면 모두 한꺼번에 덤프할 수 없습니다. 검색은 모델이 데이터를 보기 전에 접근 정책으로 필터링합니다. B2B 제품에서는 협상의 여지가 없습니다.

다중 코퍼스 추론. 답이 Slack 메시지, Notion 페이지, Linear 이슈, GitHub PR을 결합해야 할 때, 검색이 다리 역할을 합니다.

제품이 이 중 어느 항목에 해당한다면 RAG는 선택이 아닙니다. 질문은 검색을 할지 말지가 아니라, 검색을 어떻게 잘할지가 됩니다.

Long Context가 이기는 영역

Long context도 그것이 정답인 워크로드가 있습니다.

단일 문서 심층 추론. 100페이지짜리 법률 계약을 읽고 조항 전체에 걸쳐 질문에 답하기. 연구 논문 분석. 실적 발표 요약. 정답이 80페이지 떨어진 두 단락을 연결할 때, 검색은 종종 그 연결을 끊습니다. Long context는 그것을 보존합니다.

저장소 내 코드 이해. 많은 코드 추론 작업은 import, 타입, 정의, 호출 위치를 동시에 필요로 합니다. 파일 단위로 청킹하면 파일 간 관계가 사라집니다. 저장소 전체를 컨텍스트에 넣으면(들어갈 때) 구조가 보존됩니다.

대화의 연속성. 장기간 진행되는 에이전트 세션은 전체 이력을 컨텍스트에 두는 것이 유리합니다. 대화 이력에 대한 검색은 취약합니다. 의미적으로 가장 유사한 50개 턴이 아니라, 마지막 50개 턴이 필요한 경우가 많습니다.

쿼리를 모르는 탐색적 추론. 문서를 추론하기 시작하기 전까지 무엇을 물어볼지 모르겠다면, 검색을 사용하기 어렵습니다. 사전에 쿼리를 작성할 수 없습니다. Long context는 모델이 자료를 탐색하게 해줍니다.

일관된 단위 내 교차 참조. 교과서 챕터, 연구 논문, 법률 의견서는 논리적으로 통합되어 있습니다. 청킹하고 재조립하면 종종 논증 구조가 사라집니다.

대략적인 휴리스틱은 다음과 같습니다. 데이터가 하나의 논리적 문서이고 들어간다면 long context가 더 깔끔한 아키텍처입니다.

실제로 작동하는 하이브리드 패턴

진지한 LLM 시스템의 2026년 기본값은 순수 RAG도 순수 long context도 아닙니다. 하이브리드입니다. 상당하지만 한정된 토큰 집합을 검색한 다음, 이를 long-context로 추론합니다.

표준 흐름은 다음과 같습니다.

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

왜 작동하는가. 각 단계가 상대의 실패 모드를 다룹니다. 검색은 어떤 컨텍스트 윈도에도 너무 큰 코퍼스를 관리 가능한 집합으로 좁힙니다. 검색 결과 집합에 대한 long-context 추론은, 순수 RAG가 상위 5개 청크만 보낼 때 자주 깨뜨리는 다문서, 다청크 추론을 복원합니다.

핵심적인 엔지니어링 결정은 검색 결과 집합의 크기입니다. 토큰을 너무 적게 보내면 long-context의 이점을 잃습니다(고전적인 top-5 RAG를 하는 것과 다를 바 없습니다). 너무 많이 보내면 context rot을 유발합니다. Chroma 데이터는 안전한 상한선이 모델의 문서화된 한계보다 훨씬 낮으며, 종종 4배에서 10배까지 낮다는 것을 시사합니다. 200K 윈도 모델은 보통 40K~~80K까지 안정적입니다. 1M 윈도 모델은 최소한의 rot으로 150K~~300K를 자주 처리할 수 있습니다.

이것이 2025년 말까지 규모 있는 LLM 기능을 출시하는 대부분의 팀이 수렴한 아키텍처 패턴입니다. 화려하지는 않지만, 작동합니다.

하이브리드 튜닝: 숫자와 휴리스틱

다이얼에 숫자를 붙여보겠습니다. 보편적 진리는 아니지만, 많은 팀에게 프로덕션에서 작동하는 출발점입니다.

청크 크기. 대부분의 산문은 청크당 500~~1,500 토큰. 코드는 함수 단위나 논리 블록 단위로 200~~500. 청크 내 컨텍스트가 중요한 법률 또는 학술 텍스트는 1,500~~3,000. 청크 간 10~~20% 중첩.

Top-k 검색. 보내려는 것보다 더 많이 가져오세요. 상위 50~200을 검색한 뒤 재순위화합니다. 재순위화기(cross-encoder, 종종 Cohere Rerank 같은 소형 특화 모델이나 파인튜닝된 BGE 리랭커)는 임베딩 모델보다 쌍당 비용이 더 많이 들지만, 세밀한 관련성에서는 극적으로 더 정확합니다.

Rerank-to-context 비율. 재순위화 후, long-context 단계를 위해 상위 20~100 청크를 유지하세요. 정확한 숫자는 청크 크기와 안전 컨텍스트 예산에 따라 다릅니다.

하이브리드 검색. dense(벡터)와 sparse(BM25, SPLADE) 검색을 reciprocal rank fusion으로 결합하세요. 순수 dense는 정확 일치 쿼리(SKU, 오류 코드, 고유명사)를 놓칩니다. 순수 sparse는 패러프레이즈를 놓칩니다. 하이브리드는 둘 다 잡습니다.

안전 컨텍스트 예산. 모델을 테스트하세요. 서로 다른 컨텍스트 길이에서 여러 청크에 걸친 추론이 필요한 질문들로 작은 평가 집합을 구축하세요. 16K, 32K, 64K, 128K, 256K 토큰으로 채워진 컨텍스트에서 정확도를 측정하세요. 여전히 정확도가 수용 가능한 가장 큰 크기를 고르세요. 그것이 여러분의 안전 예산입니다. 프로덕션에서는 여유를 두기 위해 그보다 20% 아래에 머무세요.

검색 완전 우회. "방금 업로드한 문서를 요약해주세요"는 단일 문서 작업입니다. 작은 분류기로 이런 쿼리를 감지하고 검색을 건너뛰세요. 지연 시간을 절약하고 관련 없는 노이즈가 떠오르는 것을 막습니다.

요약 레이어. 매우 긴 이력(다달 대화, 대형 코드베이스)에 대해서는, 어셈블리 전에 오래된 자료를 압축하는 요약 단계를 끼워 넣으세요. 요약도 토큰을 소비하므로, 도움이 되는지 테스트하세요.

다음은 절충점을 정리한 비교표입니다.

축	순수 RAG (top-5 청크)	순수 Long Context	하이브리드 (50K-200K 검색 후 추론)
데이터 형태	많은 문서, 넓은 코퍼스	한 문서 또는 소규모 집합	많은 문서, 심층 추론
일반적 입력 크기	2K-10K 토큰	100K-2M 토큰	50K-200K 토큰
지연 시간	빠름	느림	중간
쿼리당 비용	낮음	높음	중간
규모에서 정확도	top-k가 맞으면 양호	rot으로 저하	복잡한 쿼리에 최적
신선도	쉬움 (인덱스 업데이트)	어려움 (프롬프트 재구성)	쉬움 (인덱스 업데이트)
인용	기본 제공	추가 작업 필요	기본 제공 (검색 집합 통해)
접근 제어	기본 제공 (검색 시 필터링)	어려움	기본 제공
단일 문서 추론	자주 깨짐	강함	강함
다문서 추론	제한적 (top-k만)	한 문서가 아니면 불가	강함

엔지니어들이 계속 출시하는 안티패턴

자주 반복되어서 짚고 넘어가야 할 함정 몇 가지입니다.

"그냥 전부 컨텍스트에 덤프해." 윈도가 두 배로 늘어나는 릴리스가 나올 때마다 솔깃해집니다. Chroma 데이터는 그것이 조용히 성능을 떨어뜨린다고 말합니다. 스팟 체크는 통과하지만, 교차 컨텍스트 추론이 필요한 쿼리에서 프로덕션에서 실패하게 됩니다. 출시 전에 항상 목표 컨텍스트 크기에서 평가를 실행하세요.

"항상 RAG를 써." 모든 워크로드에 반사적으로 RAG를 적용하면 단일 문서 사례를 놓칩니다. 50페이지 PDF를 벡터 인덱스에 넣고 상위 5개 청크를 검색하는 것은, 전체 PDF를 모델에 먹이는 것보다 보통 더 나쁜 답을 만듭니다. 휴리스틱: 단일 문서가 안전 컨텍스트 예산에 들어가고 쿼리가 그 문서에 관한 것이라면 검색을 건너뛰세요.

"검색 집합의 토큰 수를 무시해." 팀이 top-k를 "들어가는 만큼"으로 설정해 놓고, 3개월 뒤에야 평균 프롬프트가 350K 토큰이고 정확도가 조용히 떨어졌다는 것을 발견합니다. 조립된 컨텍스트 크기를 1급 지표로 추적하세요. 알림을 거세요.

"문서화된 윈도를 믿어." 1M 토큰 윈도가 모델이 1M 토큰을 모두 똑같이 잘 활용한다는 뜻은 아닙니다. 문서화된 한계는 기술적으로 보낼 수 있는 양입니다. 사용 가능한 한계는 모델이 여전히 여러분의 품질 기준에서 수행하는 지점입니다. 둘은 다른 숫자이며, 종종 한 자릿수만큼 차이가 납니다.

"모델이 이제 좋으니 평가를 건너뛰자." 최전선 모델 업그레이드는 최적의 아키텍처 선택을 바꿉니다. GPT-4-32K에서 RAG가 필요했던 워크로드가 Gemini 2.5 Pro의 long context에서는 괜찮을 수 있습니다. 모델이 바뀌면 다시 평가하세요.

2026년 하드웨어가 바꾸는 것

더 큰 윈도는 일부 결정을 바꿉니다. 어떤 것을 바꾸는지 구체적으로 살펴보는 것이 중요합니다.

Llama 4 Scout 10M 토큰. 사용 가능한 컨텍스트가 문서화된 한계의 절반에 불과해도, 중간 규모 코퍼스 전체가 하나의 프롬프트에 들어갑니다. 1M 토큰 내부 지식 베이스에 대한 단일 테넌트 어시스턴트는 검색을 건너뛸 수 있습니다. 다만 경제성이 중요합니다. 최전선 모델에서 5M 토큰 입력은 쿼리당 비쌉니다.

Gemini 2.5 / 3 Pro 2M 토큰. 프롬프트 캐싱이 적용된 2M 윈도는 동일한 대형 문서 집합을 반복적으로 쿼리하는 워크플로의 계산을 바꿉니다. 1.5M 토큰의 배경 컨텍스트를 캐시하고, 한계 쿼리에만 비용을 지불하면, 쿼리당 비용이 검색과 경쟁하기 시작합니다.

Claude Sonnet 1M. 세션 상태가 커지는 에이전트 워크로드에 유용합니다. 자기 이력에 대해 요약하거나 RAG를 해야 했던 대화형 에이전트가 이제 더 많은 원시 이력을 컨텍스트에 그대로 담을 수 있습니다.

벤더 전반의 프롬프트 캐싱. Anthropic, Google, OpenAI 모두 입력 캐싱을 지원합니다. 안정적인 콘텐츠에 대한 반복 쿼리에서 long-context 아키텍처는 훨씬 저렴해집니다. 캐싱이 작동하면 RAG의 비용 우위는 줄어들지만, 사라지지는 않습니다.

바뀌지 않은 것: context rot. 이 릴리스 중 어느 것도 더 큰 윈도가 rot 문제를 해결한다는 벤치마크 데이터를 포함하지 않습니다. 더 큰 윈도는 천장을 높이지만, 동일한 형태의 저하는 지속됩니다. 여전히 안전 예산을 측정해야 합니다. 신선하고, 다중 테넌트이며, 다중 소스인 워크로드에는 여전히 검색이 필요합니다. 하이브리드가 여전히 올바른 기본값입니다.

실제로 적용 가능한 의사결정 프레임워크

새로운 LLM 기능에 적용할 수 있는 흐름입니다. 위에서 아래로 따라가세요.

1단계: 코퍼스가 얼마나 큰가요?

전체 100K 토큰 미만: 검색을 건너뛰고 long context를 직접 사용.
100K~1M 토큰: 신선도에 따라 다름 (2단계로 이동).
1M 토큰 초과: 검색 필수.

2단계: 데이터가 얼마나 신선해야 하나요?

시간당 이상 업데이트: 검색. Long-context 프롬프트는 재구성 비용이 너무 큽니다.
일~주 단위 업데이트: 어느 패턴이든 가능.
정적이거나 드물게 업데이트: 프롬프트 캐싱과 함께 long context가 저렴하고 깔끔합니다.

3단계: 쿼리 형태는 무엇인가요?

단일 문서 심층 추론: long context 쪽으로 기울이세요.
다문서 종합: 하이브리드 쪽으로 기울이세요.
조회 또는 사실 검색: 고전적 RAG 쪽으로 기울이세요 (top-k, 작은 컨텍스트).
탐색적 또는 오픈엔디드: 문서 집합이 한정되어 있으면 long context, 그렇지 않으면 하이브리드.

4단계: 인용이나 접근 제어가 필요한가요?

어느 쪽이든 필요: 검색 필수 (고전적 RAG 또는 하이브리드). Long-context 전용 아키텍처는 인용과 사용자별 필터링을 나중에 끼워 넣기가 매우 어렵습니다.

5단계: 지연 시간 예산은 어떻게 되나요?

1초 미만: 고전적 RAG (작은 컨텍스트, 빠름).
1~5초: 하이브리드 가능.
5초 초과: 어떤 패턴이든 가능.

6단계: 긴 쿼리에서 정확도 하한은 무엇인가요?

50K 이상 토큰에 걸친 다단계 추론에서 높은 정확도: 재순위화기를 사용한 하이브리드.
최선 노력: 고전적 RAG로 보통 충분합니다.

이 여섯 단계를 따르면 세 가지 아키텍처 중 하나에 도달하게 됩니다. 고전적 top-k RAG, 순수 long context, 또는 하이브리드입니다. 진지한 워크로드의 대부분 프로덕션 시스템은 하이브리드에 도달합니다. 하이브리드가 보편적으로 더 낫기 때문이 아니라, 실제 워크로드는 보통 순수 long context를 깨뜨리는 제약(다중 테넌트 데이터, 신선도, 비용, 인용)이 적어도 하나는 있고, 순수 top-k RAG를 깨뜨리는 제약(단일 문서 추론, 교차 컨텍스트 쿼리, 탐색)도 적어도 하나는 있기 때문입니다.

Chroma 논문은 담론을 바꿨습니다. long-context 대 RAG 논쟁을 돌이켜 보면 조금 민망하게 느껴지게 만들었습니다. 둘은 경쟁자가 아닙니다. 작동하는 LLM 스택을 구성하는 세 가지 요소 중 두 가지이고, 세 번째 요소(재순위화)가 하이브리드를 안정적으로 만듭니다.

자주 묻는 질문

Gemini의 2M 컨텍스트 윈도가 RAG를 죽였나요?

아니요. 2M 토큰 윈도는 실재하지만, Chroma "Context Rot" 논문은 윈도가 가득 차기 훨씬 전부터 성능이 저하된다는 사실을 보여주었습니다. 2M 윈도 모델의 실용적 안전 컨텍스트 예산은 고정확도 워크로드에서 150K~400K 토큰 수준에 머무는 경우가 많으며, 이는 마케팅된 한계보다 훨씬 적습니다. RAG(또는 검색 후 추론하는 하이브리드 패턴)는 크고, 다문서이며, 신선하거나, 다중 테넌트인 코퍼스에 대해 여전히 올바른 아키텍처입니다.

Context rot을 쉽게 설명하면 무엇인가요?

Context rot은 LLM이 long context를 마케팅 자료가 시사하는 것보다 더 못 사용한다는 관찰입니다. 토큰을 더 많이 넣을수록 검색 및 추론 작업의 정확도가 비선형적으로 저하됩니다. 방해 텍스트가 정답과 의미적으로 유사할 때 더 빨리 나빠지며, 심지어 일관성 있고 잘 구조화된 입력이 셔플된 입력보다 어텐션을 더 많이 해칠 수 있습니다. 결과: 1M 토큰 윈도를 채운다고 해서 1M 토큰 품질의 답이 나오지는 않습니다.

Context rot이 시작되기 전에 검색 집합은 얼마나 커야 하나요?

구체적인 모델을 테스트하세요. 대략적인 출발점은 다음과 같습니다. 고정확도 워크로드의 경우 문서화된 컨텍스트 윈도의 20~~40%에 머무세요. 200K 윈도 모델이라면 40K~~80K 토큰의 검색입니다. 1M 윈도 모델이라면 200K~400K입니다. 다중 홉 추론 질문으로 구성된 작은 평가 집합을 구축하고, 컨텍스트 크기 전반에 걸쳐 정확도를 측정하세요. 정확도가 여전히 품질 범위 안에 있는 가장 큰 크기를 고르세요.

프롬프트 캐싱이 계산을 바꾸나요?

네, 의미 있게 바꿉니다. 프롬프트 캐싱(Anthropic, Google, OpenAI 전반에서 사용 가능)은 안정적인 콘텐츠에 대한 long-context 쿼리의 한계 비용을 훨씬 저렴하게 만듭니다. 대규모 배경 문서 집합을 캐시하고 쿼리당 델타만 지불할 수 있다면, 정적에 가까운 코퍼스에 대해 long context는 검색과 경제적으로 경쟁력을 갖게 됩니다. 다만 캐싱은 context rot을 고치지 않습니다. 캐시된 long context도 여전히 long context이며, 동일한 정확도 저하를 가집니다.

Long context로 보내기 전에 재순위화기를 써야 하나요?

대부분의 프로덕션 하이브리드 시스템에서는, 네. 검색된 상위 50~200 청크에 대한 재순위화기(쿼리-문서 쌍을 점수화하는 cross-encoder 모델)는 long-context 단계로 전달하는 것의 관련성을 극적으로 향상시킵니다. 재순위화를 건너뛰면 낮은 정밀도를 보완하기 위해 더 많은 토큰을 채우게 되고, 이는 rot 영역으로 밀어 넣습니다. 재순위화는 하이브리드 파이프라인에 가할 수 있는 가장 레버리지가 큰 개선 중 하나입니다.

맺는말

더 큰 윈도를 가진 새로운 모델 릴리스마다 매혹적인 것은 그것이 함축하는 약속입니다. "엔지니어링을 멈추고 그냥 덤프하세요." Chroma 논문은 그 약속이 왜 지켜지지 않았는지에 대해 단단한 숫자를 내놓았고, 그 기저의 수학(softmax 희석, 위치 인코딩 외삽, 학습 분포)은 컨텍스트 윈도가 100M 토큰까지 커져도 그 약속이 깔끔하게 지켜지지는 않을 것이라고 시사합니다.

남는 것은 지루하지만 생산적인 답입니다. 검색을 구축하세요. 튜닝하세요. 재순위화기를 추가하세요. 사양표를 믿지 말고 측정해서 안전 컨텍스트 예산을 고르세요. 실제로 정답을 포함하는, 가장 작고 가장 관련성 높은 토큰 집합을 모델에 보내세요. 그 위에서 추론하게 하세요. 출처를 인용하세요.

이것은 "AGI가 도래했으니 코드베이스를 그냥 붙여 넣어라"보다는 덜 흥미롭지만, 프로덕션에서 작동하는 기능을 출시합니다. 2026년에 조용히 좋은 LLM 제품을 만드는 팀은 long-context 내러티브를 회의적으로 다루고 RAG 내러티브도 똑같이 회의적으로 다룬, 그리고 실제로 가진 워크로드를 처리하는 하이브리드 파이프라인에 도달한 팀입니다.

아키텍처 결정은 모델 릴리스보다 오래갑니다. 그것을 제대로 하면 다음 모델 업그레이드는 강제 재작성이 아니라 공짜 개선이 됩니다.