컨텍스트 로트: 2026년 RAG vs 롱 컨텍스트

Q: 롱 컨텍스트가 RAG를 대체하나요?

일반적인 경우에는 아닙니다. Chroma의 [Context Rot 보고서](https://www.trychroma.com/research/context-rot)는 윈도우가 차기 한참 전에 성능이 저하된다는 것을 보여주었고, 이후 벤더들도 자사 제품으로 이에 동의했습니다. Anthropic의 옵트인 컴팩션은 1M 토큰 모델에서 기본값 150K부터 요약하고, OpenAI는 입력 272K 토큰 위에서, Google은 200K 위에서 요청 단가를 다시 매깁니다. 다만 측정한 안전 예산 안에 들어가는 한도가 정해진 문서 한 편에 대해서라면, 롱 컨텍스트가 RAG를 대체합니다.

Q: 제 에이전트가 긴 작업에서 일찍 멈춥니다. 이것도 컨텍스트 로트인가요?

아마 그럴 것이고, 이제 이름도 생겼습니다. 2026년 논문 [Diagnosing and Mitigating Context Rot in Long-horizon Search](https://arxiv.org/abs/2606.29718)는 이를 조기 종료라고 부릅니다. 무거운 컨텍스트 아래에서 모델이 윈도우를 다 쓰기 전에 포기하거나 근거 없는 확신으로 답해버리는 현상이며, 그 비율은 컨텍스트 길이에 따라 올라갑니다. 컨텍스트 관리가 도움이 되는 주된 경로는 이 비율을 낮춰 에이전트가 계속 탐색하게 만드는 것입니다. 조기 종료를 별도의 지표로 계측하세요.

LLM에서 컨텍스트 로트란 무엇인가

컨텍스트 로트(context rot)는 입력이 길어질수록 대규모 언어 모델이 정보를 더 못 쓰게 되는 경향을 측정한 것이며, 컨텍스트 윈도우가 다 차기 한참 전부터 나타납니다. Chroma Research는 2025년 7월 18개 프런티어 모델을 대상으로 이 현상에 숫자를 붙였고, 2026년까지 이어진 후속 연구는 그 결론을 누그러뜨리기는커녕 더 날카롭게 다듬었습니다. 1M 토큰을 내세우는 모델이라도 30K에서 보여주는 품질로 1M 토큰을 추론하지는 못합니다.

무엇을 만들지 결정하는 사람에게 실용적으로 바꿔 말하면 이렇습니다. 문서에 적힌 컨텍스트 윈도우는 "보내도 되는 양"입니다. 여러분의 실사용 가능한 윈도우는 모델이 여전히 여러분의 품질 기준을 넘기는 지점입니다. 이 둘은 서로 다른 숫자이고, 후자는 보통 전자의 일부에 지나지 않습니다.

이 격차 때문에 2024년 말과 2025년 초 엔지니어링 채널을 휩쓸던 주장("이제 RAG는 한물갔다, 그냥 전부 붙여넣으면 된다")은 형편없이 낡았습니다. 윈도우는 실제로 도착했습니다. Anthropic은 Claude Opus 5와 Claude Sonnet 5에 1M 토큰을 제공합니다. OpenAI의 GPT-5.6 계열은 약 1.05M을 지원합니다. Google의 Gemini 3.1 Pro는 1M입니다. Meta의 Llama 4 Scout은 문서상 10M입니다. 도착하지 않은 것은 그 전부를 잘 쓰는 모델이었습니다.

그래서 흥미로운 질문은 "어느 쪽이 이기는가"가 아니라 "이 데이터 형태, 이 지연 예산, 이 신선도 요구사항, 이 청구서에는 어떤 패턴이 맞는가"로 바뀌었습니다. 이 글의 나머지는 그 질문에 답합니다.

Chroma의 컨텍스트 로트 연구가 보여준 것

"컨텍스트 로트는 존재한다"라는 헤드라인은 이 연구를 실제보다 작아 보이게 만듭니다. 2025년 7월 14일 공개된 Context Rot: How Increasing Input Tokens Impacts LLM Performance에서 Kelly Hong, Anton Troynikov, Jeff Huber는 Claude 4 계열과 Claude 3.7 및 3.5, o3, GPT-4.1 계열, GPT-4o, GPT-4 Turbo, Gemini 2.5 Pro와 Flash, 그리고 세 가지 크기의 Qwen3를 포함한 18개 모델로 통제 실험을 진행했습니다. GitHub에 공개된 재현 키트로 직접 다시 돌려볼 수 있습니다.

아키텍처 관점에서 중요한 발견은 네 가지입니다.

입력이 길어질수록 성능은 비균일하게 저하됩니다. 컨텍스트 로트 그래프를 보러 오셨다면, 핵심은 그 모양입니다. 완만한 직선 하강이 아닙니다. 정확도는 버티다가 절벽에서 떨어지고, 그 절벽의 위치는 모델마다 다릅니다. 그려보면 경사로가 아니라 들쭉날쭉한 하강이 나오는데, 바로 그래서 특정 컨텍스트 크기에서 한 번 찔러본 결과는 다른 크기에서의 동작을 거의 아무것도 말해주지 못합니다.

하락 폭은 큽니다. 대화형 질의응답 벤치마크인 LongMemEval에서 연구팀은 306개 프롬프트로 추린 뒤 각각의 두 버전을 비교했습니다. 집중 버전은 관련 자료만 담고 있고 평균 약 300토큰입니다. 전체 버전은 같은 정답을 주변 대화 속에 묻어두며 평균 약 113k 토큰입니다. 모델들은 집중 버전을 잘 처리했지만 전체 버전에서는 일관되게 성능이 떨어졌습니다. 격차는 모델마다 편차가 크며, Chroma는 Claude 계열에서 이 현상이 가장 두드러졌다고 밝혔습니다. 같은 질문, 같은 모델, 입력 안에 그대로 들어 있는 같은 정답. 달라진 것은 함께 딸려 온 무관한 텍스트의 양뿐이었습니다.

성능 저하를 이끄는 것은 길이보다 의미적 유사도입니다. "바늘"을 "건초더미"와 쉽게 구별할 수 있으면 모델은 그것을 찾아냅니다. 방해 문장(distractor)이 정답과 의미적으로 비슷해 보이면 정확도는 급격히 떨어지고, 그 낙폭은 길이가 늘수록 커집니다. 방해 문장이 단 하나만 있어도 바늘만 있는 기준선 대비 성능이 떨어지고, 네 개면 그 효과가 누적됩니다. 이는 긴 컨텍스트의 중간 부분이 체계적으로 과소 반영된다는 U자형 곡선을 발견한 Liu et al. (2024), "Lost in the Middle," in TACL과도 맞아떨어집니다.

구조가 잡힌 일관된 텍스트가 뒤섞인 텍스트보다 어텐션을 더 망가뜨립니다. 엔지니어의 사고방식을 바꿔야 할 결과가 바로 이것입니다. 직관은 깔끔한 100K 토큰 문서가 뒤죽박죽인 문서보다 추론하기 쉽다고 말합니다. Chroma는 18개 모델 전부에서 일관되게 그 반대를 발견했습니다. 건초더미를 뒤섞어 논리적 흐름을 파괴하자 성능이 좋아졌습니다. 왜 그런지는 아직 열린 질문이고, Chroma도 입력의 구조가 어텐션이 적용되는 방식에 영향을 줄 수 있다는 정도까지만 말합니다. 실무로 옮길 부분에는 메커니즘이 필요 없습니다. 단정하고 서식이 잘 잡힌 PDF가 자동으로 안전한 선택지가 되지는 않는다는 것입니다.

프로덕션까지 가져갈 디테일이 하나 더 있습니다. 실패 양상은 모델마다 다릅니다. 방해 문장이 있을 때 Claude 계열은 환각률이 가장 낮았고 확신이 없으면 답을 보류하는 경향을 보인 반면, GPT 계열은 환각률이 가장 높았고 자신 있게 틀린 답을 내놓는 경향을 보였습니다. 둘 중에서 고르고 있다면, 어느 쪽 실패를 디버깅하고 싶은지도 함께 고르는 셈입니다.

무엇을 바꾸는가	정확도에 무슨 일이 일어나는가	파이프라인에 주는 의미
입력이 ~300에서 ~113k 토큰으로 증가	LongMemEval에서 일관된 성능 저하	무관한 컨텍스트는 공짜 패딩이 아닙니다
바늘이 건초더미와 닮았을 때	급격한 하락, 길이가 늘수록 악화	토큰만 늘리지 말고 정밀도를 위해 리랭크하세요
방해 문장 하나 추가	기준선 대비 측정 가능한 하락	조립 전에 아슬아슬하게 빗나간 후보를 잘라내세요
뒤섞인 건초더미 vs 일관된 건초더미	18개 모델 전부에서 뒤섞은 쪽이 더 높은 점수	깔끔한 서식은 안전 마진이 아닙니다
방해 문장 아래에서 모델 교체	Claude는 답을 보류하고 GPT는 환각을 냅니다	탐지할 수 있는 실패 양상을 고르세요

Sequential-NIAH 벤치마크 (arXiv 2504.04713)는 같은 이음매를 다른 각도에서 눌러봅니다. 정해진 순서대로 돌려줘야 하는 바늘들을 모델이 뽑아낼 수 있는지 시험한 것입니다. 8K에서 128K 컨텍스트에 걸쳐 6개 LLM을 시험한 결과, 최고 성적이 63.5퍼센트였습니다. 거리를 가로지르는 다단계 검색은 바늘 하나짜리 데모가 시사하는 것보다 어렵습니다.

좀 더 부드러운 입구를 원한다면, Hamel Husain이 Kelly Hong을 초대해 연구를 함께 짚어보고 그 강연에 주석을 단 글을 공개했습니다. 결론이 닿는 지점은 보고서와 같습니다. 성능은 컨텍스트 길이에 따라 균일하지 않고, 정보를 어떻게 제시하는지가 중요하며, 의도적인 컨텍스트 엔지니어링이 지렛대라는 것입니다.

롱 컨텍스트가 실패하는 이유: 그 메커니즘

메커니즘이 중요한 이유는 그것이 어떤 워크로드가 깨질지를 예측해 주기 때문입니다.

트랜스포머 어텐션은 토큰 쌍에 대해 softmax를 계산합니다. 시퀀스 길이가 늘어나면 어텐션은 더 많은 위치로 퍼집니다. RoPE나 ALiBi 같은 상대 위치 인코딩을 쓰더라도 softmax의 분모는 커지고 개별 토큰 하나에 돌아갈 가중치는 줄어듭니다. 1M 토큰에서는 정답 토큰이 유한한 예산을 두고 나머지 999,999개와 경쟁합니다.

위치 인코딩은 범위를 늘려줄 뿐 문제를 없애지는 못합니다. RoPE는 학습 길이를 크게 벗어나 외삽할 때 성능이 떨어지므로, 32K 시퀀스로 학습해 1M에서 서비스하는 모델은 밑바탕의 수식이 온전히 뒷받침하지 못하는 외삽을 하고 있는 셈입니다. YaRN, 위치 보간(position interpolation), NTK 인지 스케일링은 모두 도움이 되지만, 그중 어느 것도 1M 토큰을 32K만큼 잘 쓰는 모델을 만들어내지는 못합니다.

학습 데이터 문제도 있습니다. 모델이 긴 시퀀스로 학습하더라도 800K 토큰을 가로지르는 진짜 추론을 요구하는 예시는 드뭅니다. 모델은 학습 데이터가 쓰라고 가르친 부분의 컨텍스트만 쓰는 법을 배웁니다.

그러므로 컨텍스트 로트는 다음 릴리스가 패치해 없앨 버그라기보다 아키텍처와 학습 분포의 성질입니다. 앞으로의 모델은 경계를 더 밀어붙이겠지만, 성능 저하의 모양 자체는 남을 것입니다.

조기 종료: 2026년 연구가 더한 것

이 글이 처음 공개된 이후 가장 쓸모 있는 새 결과는 벤치마크 연구가 아니라 장기 실행 에이전트 연구에서 나왔습니다.

2026년 6월 Diagnosing and Mitigating Context Rot in Long-horizon Search에서 Shijie Xia, Yikun Wang, Zhen Huang, Pengfei Liu는 세 개 벤치마크에 걸쳐 네 개의 플래그십 모델을 연구했고, 앞선 문헌이 건너뛰었던 실패 양상에 이름을 붙였습니다. 바로 조기 종료(premature termination)입니다. 큰 컨텍스트 아래에서 모델은 윈도우를 다 쓰기 한참 전에 포기하거나 확신 없는 오답을 돌려줍니다. 질의의 난이도를 통제한 뒤에도 조기 종료율은 컨텍스트 길이에 따라 올라갔습니다.

이는 문제를 다시 규정합니다. 컨텍스트 로트는 서로 다른 두 가지 실패를 아우르며, 둘은 정반대의 처방을 요구합니다. 모델이 더 이상 바늘을 찾지 못하는 것이라면 정밀도를 높여야 합니다. 모델이 찾기를 멈춘 것이라면 계속 탐색할 여유와 이유를 줘야 합니다. 다단계 검색을 수행하는 에이전트에서 이 둘을 뒤섞으면 몇 주가 날아갑니다.

두 번째 발견은 그대로 가져다 쓸 만합니다. 저자들은 세 범주에 걸친 일곱 가지 컨텍스트 관리 기법을 분석한 뒤, 이 기법들이 주로 테스트 타임 스케일링 전략으로 작동한다고 결론지었습니다. 조기 종료율을 낮춰 모델이 더 오래 탐색할 여유를 벌어주는 것입니다. 컴팩션과 프루닝은 단순한 비용 절감 장치가 아니라 정확도 기능으로서 제 몫을 합니다. 저자들은 병렬 샘플링을 위한 행동 인지 필터링 전략도 만들어 세 가지 집계 방식에서 2.6~4.9퍼센트의 향상을 측정했습니다.

긴 세션에서 에이전트를 돌린다면, 여러분의 에이전트가 얼마나 자주 일찍 그만두는지 추적하세요. 값싼 지표인데 계측하는 곳이 거의 없습니다.

RAG가 여전히 이기는 곳

지금까지의 이야기를 감안해도 검색 증강 생성(RAG)은 여전히 제자리를 지킬 자격이 있습니다. 계속 이기는 지점들은 다음과 같습니다.

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

신선도와 최신성. 벡터 스토어는 증분 업데이트가 됩니다. 롱 컨텍스트 프롬프트는 내용이 바뀔 때마다 다시 만들어야 합니다. 시간 단위로 갱신되는 것(뉴스, 카탈로그, 지원 티켓, 코드)이라면 검색이 변화를 값싸게 처리합니다.

비용. 입력 비용은 입력 토큰에 비례해 늘고, 특정 임계값을 넘으면 선형보다 나쁘게 늘어납니다. 질의의 95퍼센트를 관련 토큰 5K로 답할 수 있다면, 검색은 정확도 손실 없이 몇 배로 저렴합니다.

인용과 출처. 검색은 보여주고, 링크하고, 순위를 매길 수 있는 구조화된 출처 목록을 건네줍니다. 반면 롱 컨텍스트 답변을 특정 출처에 근거 짓게 하려면 별도의 추가 작업이 필요합니다. 요약이 아니라 구절과 그 출처를 함께 보관하는 읽기 도구가 더 나은 이유도 같습니다. Glasp에서 저장해 둔 모든 것에 걸쳐 질문하면, 모든 답변이 그 답이 나온 하이라이트를 되짚어 가리킬 수 있습니다.

접근 제어와 테넌시. 코퍼스에 사용자별, 테넌트별, 역할별 공개 범위가 있다면 전부 밀어 넣을 수 없습니다. 검색은 모델이 무언가를 보기 전에 정책으로 걸러냅니다. B2B에서는 타협의 여지가 없는 조건입니다.

여러 코퍼스를 넘나드는 추론. 정답이 Slack 스레드, Notion 페이지, Linear 이슈, GitHub PR에 걸쳐 있을 때 그 사이를 잇는 다리가 검색입니다.

이 중 하나라도 해당한다면 RAG는 선택이 아닙니다. 질문은 검색을 할지 말지가 아니라 검색을 어떻게 잘할지가 됩니다.

롱 컨텍스트가 이기는 곳

롱 컨텍스트가 그냥 정답인 워크로드도 있습니다.

단일 문서 심층 추론. 100쪽짜리 계약서를 읽고 조항을 넘나들며 답하는 일. 논문을 분석하는 일. 실적 발표 콜을 따라가는 일. 정답이 80쪽 떨어진 두 문단을 이어야 할 때, 청킹은 그 연결을 끊어버리기 일쑤입니다.

저장소 안에서의 코드 이해. 많은 코드 작업은 import, 타입, 정의, 호출 지점을 한꺼번에 필요로 합니다. 파일 단위로 청킹하면 파일 사이의 관계가 사라집니다.

대화의 연속성. 긴 에이전트 세션은 진짜 히스토리에서 이득을 봅니다. 대화 기록에 대한 검색은 취약한데, 보통 필요한 것은 의미적으로 가장 비슷한 50턴이 아니라 마지막 50턴이기 때문입니다.

아직 질의를 모르는 탐색적 추론. 질의를 미리 쓸 수 없다면 검색은 조준하기 어렵습니다. 롱 컨텍스트는 모델이 직접 훑어보게 해줍니다.

일관된 단위 안에서의 상호 참조. 교과서의 한 장, 논문 한 편, 법률 의견서. 이런 것들을 잘랐다가 다시 조립하면 논지를 잃기 쉽습니다.

거친 휴리스틱 하나. 데이터가 논리적으로 하나의 문서이고 측정해 둔 안전 예산 안에 들어간다면, 롱 컨텍스트가 더 깔끔한 아키텍처입니다.

대부분의 팀이 도달하는 하이브리드 패턴

진지한 시스템의 2026년 기본값은 순수 RAG도, 순수 롱 컨텍스트도 아닙니다. 상당한 양이되 한도가 정해진 토큰 집합을 검색해 온 다음, 그 위에서 추론하는 것입니다.

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

각 단계가 다른 단계의 실패 양상을 메웁니다. 검색은 어떤 윈도우에도 안 들어갈 만큼 큰 코퍼스를 감당할 만한 크기로 좁힙니다. 검색된 집합 전체 위에서 추론하면, 고전적인 top-5 RAG가 버리는 청크 간 추론이 되살아납니다.

여기서 가장 결정적인 선택은 검색 집합의 크기입니다. 토큰이 너무 적으면 top-5 RAG를 다시 만든 것에 지나지 않습니다. 너무 많으면 로트 구간에 들어가, 더 나쁜 답에 더 많은 돈을 내게 됩니다. 다음 절에서 측정으로 바꿀 실용적인 경험칙은 이렇습니다. 문서화된 윈도우의 20~40퍼센트 언저리를 안전 예산으로 잡고, 자신의 데이터로 검증하세요. 200K 윈도우 모델이라면 40K에서 80K입니다. 1M 윈도우 모델이라면 200K에서 400K인데, 공교롭게도 바로 그 지점이 과금이 달라지는 곳입니다.

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

이 숫자들은 보편적 진리가 아닙니다. 프로덕션에서 버텨온 출발점입니다.

청크 크기. 산문은 500~~1,500토큰. 코드는 함수나 논리 블록 단위로 200~~500토큰. 청크 안의 맥락 자체가 의미를 담는 법률이나 학술 텍스트는 1,500~~3,000토큰. 겹침은 10~~20퍼센트로 잡습니다.

Top-k 검색. 보낼 양보다 많이 가져오세요. 상위 50~200개를 검색한 다음 리랭크합니다. 크로스 인코더는 쌍당 비용이 임베딩 모델보다 비싸지만, 세밀한 관련성 판단에서는 압도적으로 낫습니다.

리랭크 후 컨텍스트 비율. 리랭킹이 끝나면 상위 20~100개 청크를 남깁니다. 정확한 숫자는 청크 크기와 안전 예산에서 따라 나옵니다.

하이브리드 검색. 밀집(dense) 검색과 희소(sparse, BM25, SPLADE) 검색을 reciprocal rank fusion으로 결합하세요. 밀집만 쓰면 SKU, 에러 코드, 고유명사 같은 정확 일치를 놓칩니다. 희소만 쓰면 바꿔 쓴 표현을 놓칩니다.

이 다이얼 중 두 개는 한 줄로 끝낼 수 없습니다. 팀들이 눈치채지 못한 채 정확도를 잃는 지점이기 때문입니다.

첫째는 안전 컨텍스트 예산이고, 이를 정하는 정직한 방법은 측정뿐입니다. 여러 청크를 넘나드는 추론이 필요한 질문으로 작은 평가 세트를 만들고, 16K, 32K, 64K, 128K, 256K로 채운 컨텍스트에서 정확도를 채점하세요. 기준을 여전히 통과하는 가장 큰 크기를 고른 뒤, 여유를 위해 그보다 20퍼센트 낮게 운영하세요. 이렇게 측정한 숫자는 앞의 20~40퍼센트 규칙 근처에 떨어질 텐데, 그렇지 않다면 휴리스틱보다 자신의 평가를 믿으세요.

둘째는 모델을 업그레이드할 때 벌어지는 일이고, 2026년에 여러 팀이 여기에 물렸습니다. Anthropic의 토크나이저가 Claude Opus 4.7에서 바뀌면서, 같은 텍스트가 이제 내용에 따라 대략 1.0배에서 1.35배의 토큰으로 매핑됩니다. Anthropic은 이를 약 30퍼센트 증가로 요약합니다. 문서가 커진 것이 아닙니다. 예산이 줄어든 것입니다. 1년 전에 토큰 상한을 못 박아 두고 그 아래의 모델만 갈아 끼웠다면, 그 상한은 지금 다른 의미를 갖게 되었고 로그의 어떤 것도 그 사실을 알려주지 않습니다.

질의가 그렇게 말하면 검색을 통째로 건너뛰세요. "방금 업로드한 문서를 요약해줘"는 단일 문서 작업입니다. 작은 분류기로 이런 요청을 감지해 검색을 건너뛰면 지연을 아끼고 무관한 잡음이 끼어드는 것도 막을 수 있습니다.

요약과 프루닝 레이어. 아주 긴 히스토리라면 조립 전에 오래된 자료를 압축하세요. 요약도 토큰을 쓰므로, 실제로 도움이 되는지 측정해야 합니다.

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

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

이름을 붙여둘 만큼 자주 반복되는 함정이 몇 가지 있습니다.

"그냥 컨텍스트에 전부 밀어 넣자." 윈도우를 두 배로 키운 릴리스가 나올 때마다 솔깃해집니다. 성능 저하는 조용히 일어나므로 몇 번 찔러보는 검사는 통과하고, 정작 컨텍스트를 넘나드는 추론이 필요했던 질의에서 프로덕션이 무너집니다. 출시 전에 목표 크기에서 평가를 돌리세요.

"항상 RAG를 쓰자." 반사적인 검색은 단일 문서 사례를 놓칩니다. 50쪽짜리 PDF를 인덱싱해 상위 5개 청크를 꺼내는 방식은 대개 아무것도 안 하는 것보다는 낫지만, PDF를 통째로 보내는 것보다는 못합니다.

"조립된 토큰 수는 신경 쓰지 말자." 팀들은 top-k를 "들어가는 만큼"으로 설정해 두었다가, 석 달 뒤에야 평균 프롬프트가 350K 토큰이고 정확도가 조용히 떨어졌으며 아무도 읽지 않은 임계값에서 청구서가 두 배가 되었다는 사실을 발견합니다. 조립된 컨텍스트 크기를 일급 지표로 추적하고 알림을 거세요.

"문서에 적힌 윈도우를 믿자." 문서에 적힌 한계는 보내도 되는 양입니다. 실사용 가능한 한계는 품질이 유지되는 지점입니다. 이 둘은 서로 다른 숫자이고, 사양서에 적히는 것은 그중 하나뿐입니다.

"이제 모델이 좋아졌으니 평가는 건너뛰자." 모델 업그레이드는 어떤 아키텍처가 옳은지를 바꾸고, 때로는 여러분 모르게 토큰 회계까지 바꿔놓습니다. 모델이 바뀌면 다시 평가하세요.

"조용한 실패는 안전한 실패라고 치자." 방해 문장 아래에서 어떤 모델은 환각을 내고 어떤 모델은 답을 보류하며, 장기 실행 작업에서는 그냥 일찍 멈춰버리는 모델도 있습니다. 여러분의 모델이 어느 쪽인지 알고, 그에 맞춰 계측하세요.

2026년에 달라진 것: 윈도우, 가격, 컴팩션

이 글의 첫 버전 이후 두 가지가 달라졌고, 둘 다 같은 방향을 가리킵니다.

이제 롱 컨텍스트에는 공개된 가격 절벽이 있고, 그것도 두 벤더에 있습니다. OpenAI는 GPT-5.6 계열에 두 가지 요금 체계로 과금합니다. 임계값 아래에서 GPT-5.6 Sol은 입력 100만 토큰당 $4, 출력 100만 토큰당 $20입니다. 임계값을 넘으면 같은 모델이 $8와 $30이 됩니다. Terra는 $2/$12에서 $4/$18로, Luna는 $0.20/$1.20에서 $0.40/$1.80으로 올라갑니다. 임계값은 입력 272K 토큰에 있고, 이를 넘으면 초과분만이 아니라 요청 전체의 단가가 다시 매겨집니다. 272,001토큰짜리 프롬프트는 그 토큰 전부가 높은 요율로 청구됩니다. 광고된 1.05M 토큰 윈도우에 견주면, 광고된 가격이 적용되는 구간은 그중 약 4분의 1인 셈입니다.

Google도 더 낮은 임계값에서 같은 일을 합니다. Gemini 3.1 Pro는 200K 토큰까지의 프롬프트에 입력 100만 토큰당 $2, 출력 100만 토큰당 $12를 받고, 그 위에서는 $4와 $18을 받습니다. 입력 2배, 출력 1.5배라는 같은 구조가 72K 토큰 더 일찍 찾아오는 것입니다. OpenAI의 절벽에 맞춰 파이프라인 크기를 정해 놓고 벤더를 바꿨다면, 코드 한 줄 고치지 않고도 Google의 절벽을 그대로 넘어갈 수 있습니다.

서로 독립적인 두 벤더가 롱 컨텍스트에 프리미엄을 매긴다는 사실은 어느 한쪽만 볼 때보다 강한 증거입니다. 이는 품질 논쟁을 예산 논쟁으로 바꿉니다. 안전 컨텍스트 예산 아래에 머무는 것은 이미 정확도를 지키는 선택이었고, 이제는 청구서 하나와 둘의 차이이기도 합니다.

벤더들이 컨텍스트 관리를 제품 기능으로 내놓습니다. Anthropic의 컴팩션은 대화가 길어지면 서버 쪽에서 앞선 컨텍스트를 요약합니다. 기본 활성화가 아니라 옵트인이지만, 켜고 나면 트리거 임계값의 기본값이 윈도우 1M인 모델에서 150K 토큰입니다. 다시 읽어보세요. 100만 토큰 윈도우를 가진 벤더가 자기 기본값을 그 15퍼센트로 잡은 것입니다. Anthropic은 컨텍스트 편집도 제공하는데, 오래된 도구 실행 결과나 사고 블록을 요약하는 대신 아예 비웁니다. 서로 다른 두 메커니즘이지만, 바탕에 깔린 자백은 같습니다.

진짜 비용 지렛대는 프롬프트 캐싱이고, 이것은 실제로 효과가 있습니다. 두 주요 API 모두에서 캐시된 입력 읽기는 일반 입력 가격의 약 10분의 1입니다. 캐싱은 안정적인 콘텐츠에 반복 질의할 때 비용을 크게 낮춰줍니다. 하지만 컨텍스트 로트를 고쳐주지는 않고, OpenAI에서는 롱 컨텍스트 요율 구간을 면제해 주지도 않습니다.

모델	문서화된 윈도우	실무상 주의점
Claude Opus 5 / Sonnet 5	1M 토큰	활성화하면 컴팩션 기본값이 150K
Claude Haiku 4.5	200K 토큰	안전 예산은 40K-80K 언저리
GPT-5.6 (Sol / Terra / Luna)	약 1.05M 토큰	입력 272K를 넘으면 요청 전체가 재과금
Gemini 3.1 Pro	1M 토큰	200K를 넘으면 요청 전체가 재과금
Llama 4 Scout	10M 토큰 (iRoPE)	문서에만 있을 뿐 그 깊이에서 실증되지 않음

달라지지 않은 것은 바탕에 깔린 결과입니다. 이 릴리스 중 어느 것도 윈도우를 키우면 로트가 해결된다는 증거를 함께 내놓지 않았습니다. 윈도우가 커지면 천장은 올라가지만 성능 저하의 모양은 그대로이고, 신선도가 중요하거나 멀티테넌트이거나 여러 소스를 다루는 워크로드에는 여전히 검색이 필요합니다.

이는 컨텍스트 엔지니어링 전반에서 나타나는 것과 같은 규율입니다. 프롬프트에서 무엇을 빼느냐가 무엇을 넣느냐만큼 중요하다는 것입니다. 검색 레이어가 다른 입력 경로와 똑같은 검증을 받아야 하는 이유도 여기에 있습니다. 간접 프롬프트 인젝션은 사용자가 아니라 검색된 문서를 통해 들어오기 때문입니다.

오늘 바로 적용할 수 있는 의사결정 프레임워크

새 LLM 기능을 만들 때마다 위에서 아래로 훑어보세요.

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

전체 100K 토큰 미만: 검색을 건너뛰고 롱 컨텍스트를 쓰세요.
100K에서 1M 토큰: 신선도에 달렸습니다. 2단계로 가세요.
1M 토큰 초과: 검색이 필수입니다.

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

시간 단위 이하: 검색입니다. 긴 프롬프트를 다시 만드는 비용이 너무 큽니다.
일 단위에서 주 단위: 어느 패턴이든 됩니다.
정적: 프롬프트 캐싱을 곁들인 롱 컨텍스트가 값싸고 깔끔합니다.

3단계: 질의의 형태는 어떤가요?

단일 문서 심층 추론: 롱 컨텍스트 쪽으로.
다중 문서 종합: 하이브리드 쪽으로.
조회나 사실 검색: 고전적인 RAG 쪽으로.
탐색적: 문서 집합에 한도가 있으면 롱 컨텍스트, 아니면 하이브리드.

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

둘 중 하나라도 그렇다면 검색이 필수입니다. 롱 컨텍스트 전용 설계에 인용과 사용자별 필터링을 나중에 덧붙이는 일은 고통스럽습니다.

5단계: 지연 예산은 얼마인가요?

1초 미만: 고전적인 RAG.
1초에서 5초: 하이브리드가 가능합니다.
5초 초과: 어느 패턴이든 됩니다.

6단계: 긴 질의에서 정확도의 하한선은 어디인가요?

50K 토큰을 넘는 다단계 추론에서 높은 정확도가 필요하다면: 리랭커를 붙인 하이브리드.
최선을 다하는 정도면 충분하다면: 고전적인 RAG로도 대개 괜찮습니다.

7단계: 조립된 프롬프트는 가격 절벽 대비 어디에 놓이나요?

OpenAI에서 272K 미만, Google에서 200K 미만, 그 밖에서는 측정한 안전 예산 미만이라면 괜찮습니다.
어느 쪽 임계값 근처에서 아슬아슬하다면 리랭커를 추가하고 검색 집합을 줄이세요. 대개 더 나은 답과 더 작은 청구서를 동시에 얻게 됩니다.

대부분의 프로덕션 시스템은 하이브리드에 안착합니다. 실제 워크로드에는 순수 롱 컨텍스트를 깨뜨리는 제약(멀티테넌시, 신선도, 비용, 인용)이 적어도 하나, 순수 top-k RAG를 깨뜨리는 제약(단일 문서 추론, 컨텍스트를 넘나드는 질의, 탐색)도 적어도 하나 들어 있기 때문입니다.

같은 기술의 인간 버전도 있습니다. 무엇이 추론 과정 앞에 놓일 자격이 있는지 정하는 일은 꼼꼼한 독자들이 늘 손으로 해온 일이고, 하이라이트는 그 결정을 겉으로 드러낸 것입니다. Glasp의 웹 하이라이터는 페이지 전체가 아니라 여러분이 남길 가치가 있다고 판단한 구절을 보관합니다. 사람이 리랭커 역할을 하는 검색인 셈입니다. 자신의 도구를 그 집합에 연결하고 싶다면, Glasp의 MCP 커넥터가 여러분의 하이라이트를 LLM에 직접 노출해 줍니다. 그 구성에 관해서는 노트를 MCP 서버로 만들기에서 더 자세히 다뤘습니다.

자주 묻는 질문

LLM에서 컨텍스트 로트란 무엇인가요?

컨텍스트 로트는 LLM이 마케팅에서 시사하는 것보다 긴 컨텍스트를 잘 쓰지 못한다는 관찰입니다. 토큰을 더 밀어 넣을수록 검색과 추론의 정확도는 비선형으로 떨어지는데, 경사로를 미끄러져 내려가는 것이 아니라 절벽을 만납니다. 방해 텍스트가 정답과 닮아 있으면 더 빨리 나빠지고, Chroma는 시험한 18개 모델 전부에서 일관되고 잘 구조화된 입력조차 뒤섞인 입력보다 어텐션에 더 해로웠다는 사실을 발견했습니다. 1M 토큰 윈도우를 채운다고 1M 토큰 품질의 답이 나오지는 않습니다.

2026년에 RAG는 한물간 기술인가요?

아니요, 증거는 오히려 반대를 가리킵니다. 어떤 윈도우보다도 큰 코퍼스, 시간 단위로 바뀌는 데이터, 테넌트별 접근 제어, 인용에는 여전히 검색이 필요합니다. 한물간 것은 고전적인 top-5 RAG를 유일한 패턴으로 쓰는 방식입니다. 지금의 기본값은 하이브리드입니다. 한도가 정해진 집합을 검색한 다음 그 전부 위에서 추론하는 것입니다. 컨텍스트 윈도우가 커지면서 달라진 것은 얼마나 많이 검색할지이지, 검색을 할지 말지가 아닙니다.

롱 컨텍스트가 RAG를 대체하나요?

일반적인 경우에는 아닙니다. Chroma의 Context Rot 보고서는 윈도우가 차기 한참 전에 성능이 저하된다는 것을 보여주었고, 이후 벤더들도 자사 제품으로 이에 동의했습니다. Anthropic의 옵트인 컴팩션은 1M 토큰 모델에서 기본값 150K부터 요약하고, OpenAI는 입력 272K 토큰 위에서, Google은 200K 위에서 요청 단가를 다시 매깁니다. 다만 측정한 안전 예산 안에 들어가는 한도가 정해진 문서 한 편에 대해서라면, 롱 컨텍스트가 RAG를 대체합니다.

컨텍스트 로트가 시작되기 전까지 검색 집합은 얼마나 커도 되나요?

쓰는 모델로 직접 시험해야 하지만, 합리적인 출발점은 문서화된 윈도우의 20~40퍼센트입니다. 200K 모델이면 40K에서 80K, 1M 모델이면 200K에서 400K입니다. 다만 OpenAI에서는 과금 때문에 272K 아래에, Google에서는 200K 아래에 머무는 편이 좋습니다. 멀티홉 질문으로 작은 평가 세트를 만들어 컨텍스트 크기별 정확도를 측정하고, 기준을 여전히 통과하는 가장 큰 크기를 고르세요.

프롬프트 캐싱이 컨텍스트 로트를 해결해 주나요?

아니요. 캐싱이 해결하는 것은 비용이지 정확도가 아닙니다. 캐시된 입력 읽기는 일반 입력 가격의 약 10분의 1이므로, 안정적인 콘텐츠에 대한 롱 컨텍스트 질의는 훨씬 저렴해지고 RAG의 비용 우위는 좁아집니다. 하지만 모델은 여전히 같은 긴 컨텍스트를 읽고 같은 방식으로 성능이 떨어지므로, 더 약한 같은 답에 돈을 덜 내는 것뿐입니다. OpenAI에서는 캐싱을 해도 롱 컨텍스트 요율 구간이 면제되지 않습니다.

롱 컨텍스트로 보내기 전에 리랭커를 써야 하나요?

대부분의 프로덕션 하이브리드 시스템이라면 그렇습니다. 검색한 상위 50~200개 청크를 크로스 인코더로 채점하면 추론 단계에 도달하는 내용이 크게 좋아집니다. 리랭크를 건너뛰면 대개 약해진 정밀도를 만회하려고 토큰을 더 밀어 넣게 되는데, 그러면 로트 구간과 가격 절벽 양쪽으로 밀려가게 됩니다. 하이브리드 파이프라인에 가할 수 있는 가장 효과가 큰 변경 중 하나입니다.

제 에이전트가 긴 작업에서 일찍 멈춥니다. 이것도 컨텍스트 로트인가요?

아마 그럴 것이고, 이제 이름도 생겼습니다. 2026년 논문 Diagnosing and Mitigating Context Rot in Long-horizon Search는 이를 조기 종료라고 부릅니다. 무거운 컨텍스트 아래에서 모델이 윈도우를 다 쓰기 전에 포기하거나 근거 없는 확신으로 답해버리는 현상이며, 그 비율은 컨텍스트 길이에 따라 올라갑니다. 컨텍스트 관리가 도움이 되는 주된 경로는 이 비율을 낮춰 에이전트가 계속 탐색하게 만드는 것입니다. 조기 종료를 별도의 지표로 계측하세요.

맺으며

더 큰 윈도우를 들고 나오는 릴리스마다 같은 약속이 암시되어 있습니다. 엔지니어링은 그만두고 그냥 밀어 넣으라는 것입니다. Chroma는 그 약속이 왜 지켜지지 않았는지에 단단한 숫자를 붙였고, 2026년의 연구는 아무도 지켜보지 않던 두 번째 실패 양상을 더했으며, 바탕의 수식(softmax 희석, 위치 외삽, 학습 분포)은 100M 토큰에서도 그 약속이 깔끔하게 지켜지지는 않을 것이라고 말합니다.

남은 것은 지루하지만 생산적인 답입니다. 검색을 만드세요. 튜닝하세요. 리랭커를 붙이세요. 사양서를 믿는 대신 측정으로 안전 컨텍스트 예산을 정하고, 모델이나 토크나이저가 바뀌면 다시 측정하세요. 정답을 담고 있는 가장 작고 가장 관련성 높은 토큰 집합을 보내세요. 모델이 그 위에서 추론하게 하세요. 출처를 인용하세요.

2026년의 반전은 이제 벤더들이 여러분에게 동의하는 것처럼 가격을 매기고 제품을 설계한다는 점입니다. 272K와 200K의 절벽, 그리고 150K라는 컴팩션 기본값은 모두 실사용 가능한 윈도우가 광고된 윈도우의 일부에 지나지 않는다는 자백입니다. 이는 유용한 소식인데, 규율 있는 아키텍처가 곧 값싼 아키텍처라는 뜻이기 때문입니다. 이 둘이 같은 방향을 가리키는 일은 흔치 않습니다.

어떤 작업에 어떤 모델을 쓸지에 대한 더 넓은 지도를 원한다면, AI 작업과 모델 매트릭스에 정리해 두었습니다. 아키텍처 결정은 모델 릴리스보다 오래갑니다. 이것들을 제대로 잡아두면 다음 업그레이드는 강제된 재작성이 아니라 공짜 개선이 됩니다.