컨텍스트 로트란? 2026년 RAG vs 롱 컨텍스트

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

컨텍스트 로트(context rot)는 입력이 길어질수록 대규모 언어 모델의 정확도가 떨어지는 것으로 측정된 현상이며, 컨텍스트 윈도우가 다 차기 한참 전부터 나타납니다. 원인은 더 많은 토큰으로 흩어지는 어텐션, 정답처럼 보이는 방해 문장, 그리고 극단적인 길이에서의 추론을 거의 보상하지 않는 학습입니다. 해결책은 덜 보내는 것입니다. 검색하고 리랭크하고, 오래된 도구 출력을 비우고, 긴 세션은 컴팩션하거나 새로 시작하고, 사양서를 믿는 대신 자신의 안전 예산을 측정하세요.

Chroma Research는 2025년 7월, 18개 모델을 대상으로 이 현상에 숫자를 붙였고, 이 용어는 이제 Anthropic의 공식 문서가 직접 정의할 만큼 널리 퍼졌습니다. "토큰 수가 늘어날수록 정확도와 재현율이 저하되며, 이 현상을 컨텍스트 로트라고 합니다." 광고된 윈도우가 커지면 보낼 수 있는 양의 천장이 올라갑니다. 하지만 그 범위의 꼭대기에서도 바닥에서와 같은 정확도를 약속하지는 않습니다.

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

이 격차 때문에 2024년 말과 2025년 초 엔지니어링 채널을 휩쓸던 주장("이제 RAG는 한물갔다, 그냥 전부 붙여넣으면 된다")은 형편없이 낡았습니다. 큰 윈도우는 실제로 나왔습니다. Anthropic은 Claude Opus 5.5, Sonnet 5.5, 그리고 새로 나온 Haiku 5.5에서 1M 토큰을 기본으로 제공합니다. OpenAI의 GPT-6 모델들은 1.05M 윈도우를 갖추고 있고, 그중 922K까지를 입력으로 쓸 수 있습니다. Google의 Gemini 3.1 Pro와 Gemini 3.8 Flash는 약 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는 18개 모델로 통제 실험을 진행했습니다. 대상은 Claude Opus 4, Sonnet 4, Sonnet 3.7, Sonnet 3.5, Haiku 3.5; o3, GPT-4.1과 그 mini 및 nano 버전, GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo; Gemini 2.5 Pro, 2.5 Flash, 2.0 Flash; 그리고 세 가지 크기의 Qwen3입니다. 윈도우와 사고 예산(thinking budget)의 한계 때문에 모든 모델이 모든 실험에 참여하지는 않았습니다. GitHub에 공개된 재현 키트로 직접 다시 돌려볼 수 있습니다.

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

입력이 길어질수록 성능은 고르지 않게 저하됩니다. 컨텍스트 로트 그래프를 보러 오셨다면, 핵심은 그 모양입니다. 곡선이 하나로 정해져 있지 않다는 것입니다. Chroma 스스로의 요약에 따르면, 모델은 "컨텍스트를 균일하게 사용하지 않으며, 오히려 입력 길이가 늘어날수록 성능의 신뢰도가 점점 더 떨어집니다." 얼마나 빨리, 어디서 떨어지는지는 모델과 작업에 따라 다르고, 바로 그래서 특정 컨텍스트 크기에서 한 번 찔러본 결과는 다른 크기에서의 동작에 대해서는 거의 아무것도 알려주지 못합니다. Anthropic의 엔지니어링 팀은 같은 패턴을 "뚜렷한 절벽이라기보다는 성능의 기울기"라고 묘사합니다.

하락 폭은 큽니다. 대화형 질의응답 벤치마크인 LongMemEval에서 연구팀은 306개 프롬프트로 추린 뒤 각각의 두 버전을 비교했습니다. 집중 버전은 관련 자료만 담고 있고 평균 약 300토큰입니다. 전체 버전은 같은 정답을 주변 대화 속에 묻어두며 평균 약 113K 토큰입니다. 전체 버전에서는 일관되게 성능이 떨어졌습니다. 격차가 가장 컸던 것은 Claude 계열이었고, Chroma는 그 상당 부분을 답변 보류 탓으로 봅니다. Claude Opus 4와 Sonnet 4는 추측하기보다 답하기를 거절하는 경우가 많았습니다. 같은 질문, 같은 모델, 입력 안에 그대로 들어 있는 같은 정답. 주로 달라진 것은 함께 딸려 온 무관한 텍스트의 양이었습니다.

유사도가 하락의 모양을 결정합니다. 바늘(needle)이 질문과 의미적으로 덜 비슷할수록(Chroma는 이를 임베딩 유사도로 채점했습니다), 입력이 길어질 때 정확도는 더 빨리 떨어집니다. 정답과 닮은 방해 문장(distractor)도 해롭습니다. 단 하나만 있어도 바늘만 있는 기준선 대비 성능이 떨어지고, 네 개면 그 효과가 누적됩니다. 반면 위치는 이 작업에서 별 차이를 만들지 않았습니다. Chroma는 11개의 바늘 위치에 걸쳐 눈에 띄는 차이를 보지 못했습니다. Liu et al. (2024), "Lost in the Middle," in TACL이 다중 문서 질의응답에서 긴 컨텍스트의 중간 부분이 체계적으로 과소 반영되는 U자형 곡선을 발견했는데도 말입니다.

일관된 채움 텍스트가 뒤섞인 채움 텍스트보다 더 해로웠습니다. 엔지니어의 사고방식을 바꿔야 할 결과가 바로 이것입니다. 직관은 일관된 건초더미가 뒤죽박죽인 건초더미보다 찾기 쉬울 것이라고 말합니다. Chroma는 18개 모델 전부에서 일관되게 그 반대를 발견했습니다. 건초더미의 문장을 뒤섞어 논리적 흐름을 파괴하자 성능이 좋아졌습니다. 왜 그런지는 아직 열린 질문이고, Chroma도 입력의 구조가 어텐션 메커니즘이 적용되는 방식에 영향을 줄 수 있다는 정도까지만 말합니다. 실무로 옮길 부분에는 메커니즘이 필요 없습니다. 일관되고 주제에 맞는 패딩이라고 해서 자동으로 무해한 것은 아니라는 것입니다.

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

이것을 측정하는 팀이 Chroma만은 아닙니다. 자신의 워크로드와 닮은 컨텍스트 로트 벤치마크를 찾고 있다면, 주요 벤치마크는 다음과 같습니다.

기억해 둘 것은 마지막 행입니다. 모델이 관련 구절을 하나도 빠짐없이 완벽하게 검색해 내더라도, 입력이 길어지면 여전히 정확도를 잃습니다.

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

---

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

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

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

위치 인코딩은 범위를 늘려줄 뿐 문제를 없애지는 못합니다. RoPE는 학습 길이를 크게 벗어나 외삽할 때 성능이 떨어지므로, 32K 시퀀스로 학습해 1M에서 서비스하는 모델은 밑바탕의 수식이 온전히 뒷받침하지 못하는 외삽을 하고 있는 셈입니다. 예를 들어 Meta는 Llama 4 Scout의 사전 학습과 사후 학습을 256K 길이에서 진행했고 문서에는 10M 윈도우를 적어 두었으므로, 256K를 넘는 구간은 모두 길이 일반화(length generalization)에 기대고 있습니다. YaRN, 위치 보간(position interpolation), NTK 인지 스케일링은 모두 도움이 되지만, 그중 어느 것도 1M 토큰을 32K만큼 잘 쓰는 모델을 만들어내지는 못합니다.

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

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

---

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

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

2026년 6월에 처음 공개되고 8월에 대폭 개정된 Diagnosing and Mitigating Context Rot in Long-horizon Search에서 Shijie Xia, Yikun Wang, Zhen Huang, Pengfei Liu는 오픈 웨이트 플래그십 모델 네 개(GLM-4.7, GLM-5.0, Qwen3.5-397B-A17B, MiniMax-M2.5)를 세 가지 딥 서치 벤치마크에서 연구했습니다. BrowseComp, xbench-DeepSearch, 그리고 고정된 로컬 코퍼스를 검색하는 BrowseComp-Plus입니다. 클로즈드 모델은 추론 과정(reasoning trace)이 암호화되어 있어 대상에서 빠졌습니다. 개정판은 앞선 문헌이 건너뛰었던 실패 양상에 이름을 붙입니다. 바로 조기 종료(premature termination)입니다. 큰 컨텍스트 아래에서 모델은 윈도우를 다 쓰기 한참 전에 포기하거나, 스스로 불확실하다고 표시한 오답을 돌려줍니다. 질의의 난이도를 통제한 뒤에도 저자들은 조기 종료율이 컨텍스트 길이에 따라 올라간다는 것을 확인했습니다.

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

두 번째 발견은 그대로 가져다 쓸 만합니다. 저자들은 세 계열(컴팩션, 트리밍, 서브에이전트를 통한 격리)에 걸친 일곱 가지 컨텍스트 관리 기법을 시험한 뒤, 이 기법들이 주로 테스트 타임 스케일링 전략으로 작동한다고 결론지었습니다. 조기 종료율을 낮춰 모델이 더 오래 탐색할 여유를 벌어주는 것입니다. 어느 계열이 도움이 되는지는 모델에 따라 다릅니다. 비교한 모델 중 에이전트 능력이 더 강한 Qwen3.5-397B-A17B에서는 작업을 서브에이전트로 격리하는 방식이 가장 높은 점수를 냈습니다. 더 약한 GLM-4.7에서는 서브에이전트가 가장 나쁜 선택지 축에 들었고, 최신 도구 결과만 남기고 요약을 더하는 방식이 정확도와 비용의 균형이 가장 좋았습니다. 저자들은 병렬 샘플링을 위한 행동 인지 필터링 전략도 만들어, 세 가지 집계 방식에서 평균 정확도를 2.6~4.9퍼센트포인트 끌어올렸습니다.

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

7월에서 10월 초 사이에 올라온 2026년 프리프린트 세 편도 같은 방향을 가리킵니다. Context as an Environment는 도구 출력을 영속적인 Python 세션의 변수로 보관하고, 에이전트가 출력(print)한 것만 컨텍스트에 들어가게 합니다. 기반 모델을 똑같이 Qwen3.8-Max로 두었을 때, 이 방식은 LOCA 벤치마크의 256K 토큰 조건에서 86.7퍼센트를 기록했고, 히스토리를 요약하는 에이전트는 65.3퍼센트였습니다. Stateless Language Agents는 대화를 계속 이어 가는 대신, 하네스가 보관하는 상태로부터 호출할 때마다 컨텍스트를 새로 구성합니다. 커널 최적화 작업에서는 84퍼센트 이상 적은 토큰으로 가장 강한 베이스라인의 최종 성능에 도달했습니다. 그리고 CompactionRL은 컴팩션을 나중에 덧붙이는 기능이 아니라 학습시켜야 할 기술로 다룹니다. 이 논문의 GLM-4.5-Air 모델은 추론 시점에 컴팩션을 덧붙인 같은 베이스 모델보다 SWE-bench Verified에서 6.6포인트 높은 점수를 냈습니다. 모두 프리프린트이지만, 방향에는 의견이 일치합니다. 작업 집합을 작게 유지하고, 모델이 그것을 작게 유지하는 데 능숙해지게 하라는 것입니다.

---

에이전트와 채팅 도구에서 컨텍스트 로트를 고치는 법

효과가 있는 해결책은 모두 같은 일을 합니다. 더 적고 더 좋은 토큰을 모델 앞에 놓는 것입니다. Anthropic의 엔지니어링 팀은 Effective context engineering for AI agents에서 이를 한 줄로 말합니다. "따라서 컨텍스트는 한계 수익이 체감하는 유한한 자원으로 다뤄야 합니다." 달라지는 것은 이 원칙을 어디에 적용하느냐입니다.

LLM 앱이나 에이전트를 만든다면:

• 덜 보내고, 잘 고르세요. 검색하고, 리랭크하고, 작업에 필요 없는 것은 버리세요. Google의 롱 컨텍스트 가이드도 같은 말을 합니다. "일반적으로, 모델에 전달할 필요가 없는 토큰이라면 전달하지 않는 것이 가장 좋습니다."
• 긴 문서는 앞에, 질문은 맨 뒤에 두세요. 20K 토큰 이상의 입력에 대해 Anthropic의 프롬프팅 가이드는 문서를 맨 위에, 질의를 맨 끝에 두라고 권하며, 질의를 끝에 두면 "테스트에서 응답 품질을 최대 30퍼센트까지 높일 수 있다"고 적고 있습니다. 답하기 전에 관련 구절을 먼저 인용하도록 모델에 요청하는 방법도 제안합니다. Google도 Gemini에 대해 같은 배치를 권합니다.
• 오래된 도구 결과를 비우세요. 지난 검색 결과와 파일 덤프는 지우기에 가장 값싼 토큰입니다. Anthropic은 도구 결과 비우기를 "가장 안전하고 가장 가벼운 형태의 컴팩션 중 하나"라고 부르며, 이를 컨텍스트 편집(context editing)이라는 기능으로 제공합니다. 기본값으로는 입력이 100,000토큰에 이르면 비우기 시작하고, 가장 최근의 도구 사용 세 건은 남겨 둡니다.
• 윈도우가 차기 전에 컴팩션하고, 요약을 시험하세요. Anthropic의 API는 임계값 컴팩션(기본 트리거: 입력 150,000토큰)과, 2026년 9월부터는 온디맨드 컴팩션을 제공합니다. OpenAI의 Responses API는 context_management 아래에 compact_threshold를 설정하면 서버 쪽에서 컴팩션하고, 독립된 compact 엔드포인트도 제공합니다. 요약에는 손실이 따르므로 무엇이 빠지는지 확인하세요. Anthropic의 조언은 먼저 재현율을 최대화한 다음, 불필요한 것을 잘라내라는 것입니다.
• 규칙과 상태는 요약 바깥에 두세요. 8월에 arXiv에 올라온 CIKM 2026 논문 The Compaction Cliff in Long-Running AI Agent Memory는 Sonnet 4.6에서 Claude Code의 컴팩션 프롬프트가 프로덕션 에이전트 설정에 담긴 안전 규칙을 1회차 뒤에는 53퍼센트, 5회차 뒤에는 10퍼센트만 남긴다는 사실을 발견했습니다. 저자들의 해결책은 안전 규칙과 절차는 원문 그대로 고정하고 나머지는 유형별로 압축하는 것으로, 다섯 회차에 걸쳐 96퍼센트의 재현율을 유지했습니다. 그러니 규칙은 에이전트가 다시 읽는 곳에 고정하고, 진행 상황은 채팅 기록이 아니라 노트나 메모리 도구, git에 남기세요.
• 탐색은 서브에이전트에 맡기세요. Anthropic의 표현을 빌리면, 서브에이전트는 자기 컨텍스트를 탐색에 쓰고 "작업을 압축하고 정제한 요약(대개 1,000~2,000토큰)"을 돌려줍니다. 다만 자신의 모델로 시험해 보세요. 조기 종료 논문에서 서브에이전트는 비교한 두 모델 중 강한 쪽에서는 가장 높은 점수를 냈지만, 약한 쪽에서는 가장 나쁜 축에 들었습니다. 서브에이전트, 스킬, 훅이 어떻게 맞물리는지는 에이전틱 엔지니어링 가이드에서 다룹니다.
• 컨텍스트 크기별로 측정하세요. 여러 입력 길이에서 자신의 평가를 채점하고, 조기 종료를 기록하세요. 그렇지 않으면 위의 모든 해결책은 추측에 불과합니다.

Anthropic은 이 조합에 대한 수치를 공개했습니다. 내부 에이전트 검색 평가에서 메모리 도구와 컨텍스트 편집을 함께 쓰자 기준선 대비 성능이 39퍼센트, 컨텍스트 편집만 썼을 때는 29퍼센트 향상되었습니다. 100턴짜리 웹 검색 테스트에서는 컨텍스트 편집이 토큰 사용량을 84퍼센트 줄였습니다. 벤더가 자사 제품에 대해 낸 수치이므로, 약속이 아니라 방향으로 읽으세요.

채팅 어시스턴트나 코딩 에이전트를 쓴다면:

• 작업 하나에 채팅 하나. Claude Code의 모범 사례 가이드는 이렇게 말합니다. "더 나은 프롬프트로 시작하는 깨끗한 세션은, 수정이 쌓인 긴 세션보다 거의 항상 더 좋은 결과를 냅니다." OpenAI의 Codex 가이드도 같은 입장입니다. "일관된 작업 단위 하나마다 채팅 하나를 유지하세요."
• 수정이 두 번 실패하면 다시 시작하세요. Claude Code가 직접 제시하는 경험칙입니다. /clear를 실행하고, 그동안 알게 된 것을 담아 더 나은 첫 프롬프트를 쓰세요.
• 컴팩션은 내가 정한 때에 하세요. Claude Code, Codex, Cursor는 모두 한계에 가까워지면 자동으로 요약합니다. 초점 지시와 함께 더 일찍 컴팩션하면(예: /compact Focus on the API changes) 무엇을 남길지에 내 의견을 반영할 수 있습니다. Claude Code는 "대화 초반의 상세한 지시가 사라질 수 있다"고 경고하므로, 계속 지켜야 할 규칙은 채팅이 아니라 CLAUDE.md처럼 에이전트가 다시 읽는 파일에 두어야 합니다.
• 계기판을 보세요. Claude Code의 /context는 무엇이 윈도우를 채우고 있는지 보여 주고, Codex의 /status는 윈도우를 얼마나 썼는지 보여 줍니다. Cursor는 입력창 옆에 컨텍스트 링을 두는데, 클릭하면 세부 내역이 열립니다.

명령어와 기본값은 릴리스마다 바뀌므로, 이 표는 2026년 10월 기준으로 정확한 정보로 받아들이고, 업그레이드한 뒤에는 사용하는 도구의 문서를 확인하세요.

---

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인데, 공교롭게도 바로 그 지점이 OpenAI와 Gemini 3.1 Pro에서 과금이 달라지는 곳입니다.

---

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

"자동 컴팩션에 맡기자." 자동 컴팩션은 세션을 살려 둡니다. 정확하게 유지해 주지는 않습니다. 요약은 지시를 빠뜨리고, Compaction Cliff 논문은 회차가 거듭될 때마다 규칙 유지율이 떨어지는 것을 지켜보았습니다. 무엇이 살아남아야 하는지 정하고, 그것을 대화 바깥에 저장하세요.

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

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

---

2026년에 달라진 것: 모델, 가격, 컴팩션

아래 내용의 대부분은 Anthropic, OpenAI, Google이 모두 새 모델을 내놓은 2026년 9월부터 10월 초 사이에 바뀌었고, 그 전부가 같은 방향을 가리키지는 않습니다.

모델 라인업이 전면 교체되었습니다. Anthropic은 9월 1일 Claude Fable 5.1, 9월 22일 Opus 5.5, 9월 28일 Sonnet 5.5, 10월 7일 Haiku 5.5를 출시했고, 모두 1M 토큰 윈도우를 갖췄습니다. OpenAI는 9월 3일 GPT-6 Astra, 9월 22일 GPT-6 Sol과 Luna, 9월 29일 GPT-6.1 Sol을 내놓았으며, 모두 1.05M 윈도우에 입력은 최대 922K 토큰입니다. Google은 9월 2일 Gemini 3.8 Flash를 정식 출시(GA)했고, Gemini 3.1 Pro는 아직 프리뷰 모델입니다.

최고 검색 점수는 뛰어올랐고, 모델 간 격차는 매우 큽니다. OpenAI의 발표에 따르면, OpenAI의 자체 8-needle 테스트인 OpenAI MRCR v2에서 GPT-6 Astra는 512K에서 1M 토큰 구간에 96.3퍼센트를 기록했고, GPT-5.6 Sol은 73.8퍼센트였습니다. Google의 모델 카드는 Gemini 3.1 Pro를 Google 자체의 MRCR v2(8-needle)로 채점하는데, 이름은 같아도 다른 데이터셋입니다. 결과는 128K까지 평균 84.9퍼센트, 1M에서 26.3퍼센트입니다. 따라서 벤더 간 격차는 하나의 신호일 뿐, 맞대결 결과가 아닙니다. 두 수치 모두 벤더가 직접 측정한 것이고(OpenAI는 여러 추론 강도 설정 가운데 가장 좋은 점수를 보고합니다), MRCR이 측정하는 것은 올바른 구절을 찾아 재현하는 능력이지 문서 전체를 넘나드는 추론이 아닙니다. 컨텍스트 로트는 사라지지 않았습니다. 모델마다 따로 측정해야 하는 것이 되었을 뿐입니다.

이제 가격 절벽은 벤더마다 다릅니다. OpenAI는 여전히 입력 272K 토큰을 넘으면 요청 전체의 단가를 다시 매기며, GPT-6 모델에서 그것은 "입력 및 캐시 요율 2배, 출력 1.5배"를 뜻합니다. GPT-6.1 Sol은 입력과 출력 100만 토큰당 $2와 $10에서 $4와 $15로, GPT-6 Astra는 $10와 $50에서 $20와 $75로 오릅니다. GPT-5.6 Sol의 $4와 $20는 적어도 2026년 11월 21일까지 이어지는 프로모션 가격이며, 같은 선을 넘으면 $8와 $30로 오릅니다. Google은 200K를 넘는 Gemini 3.1 Pro 프롬프트에 $2와 $12 대신 $4와 $18를 청구하지만, Gemini 3.8 Flash에는 그런 구간이 없습니다. Anthropic은 Claude 4.6 이후 모델에서 1M 윈도우 전체를 표준 요율로 청구합니다(요금 페이지에 따르면 "900k 토큰 요청도 9k 토큰 요청과 같은 토큰당 요율로 청구됩니다"). 예외는 하나입니다. Haiku 5.5에서는 100,000토큰을 넘는 프롬프트가 다섯 배 비싸, $0.10와 $0.50 대신 $0.50와 $2.50가 됩니다.

컴팩션이 제품이 되었습니다. 설정 방법은 앞의 해결책에서 다뤘습니다. 달라진 점은 이제 벤더가 컴팩션을 대신 실행해 준다는 것입니다. Anthropic의 문서는 새로 나온 온디맨드 컴팩션을 "사용할 수 있는 곳이라면 어디서나" 쓰라고 권합니다. OpenAI의 Responses API는 컴팩션된 컨텍스트를 사람이 읽도록 만들어지지 않은 불투명한 항목으로 돌려주고, 9월 10일부터 공개 베타인 Agents API는 "세션 오케스트레이션, 컨텍스트 컴팩션, 복구는 OpenAI가 처리합니다"라고 말합니다. 그래도 기본값에 주목하세요. 100만 토큰 윈도우를 가진 벤더가 임계값 컴팩션을 150K에서 시작합니다.

캐싱은 더 싸졌습니다. 그래도 로트를 고치지는 못합니다. 캐시 읽기는 대부분의 Anthropic 모델에서 기본 입력 가격의 10분의 1, Opus 5.5와 Sonnet 5.5에서는 20분의 1, Fable 5.1에서는 40분의 1입니다. OpenAI는 대부분의 모델에서 10분의 1, GPT-6.1 Sol에서 20분의 1을 받으며, GPT-5.6부터는 캐시 쓰기를 입력 요율의 1.25배로 청구합니다. 캐싱은 안정적인 콘텐츠에 반복 질의할 때 비용을 크게 낮춰줍니다. 하지만 모델이 긴 입력을 다루는 방식은 바꾸지 못하며, OpenAI에서는 캐시된 토큰도 캐시되지 않은 입력과 마찬가지로 272K를 넘으면 가격이 두 배가 됩니다.

달라지지 않은 것은 바탕에 깔린 결과입니다. 더 좋은 모델은 곡선을 움직이지만, 윈도우가 커지는 것만으로는 아무것도 해결되지 않으며, 신선도가 중요하거나 멀티테넌트이거나 여러 소스를 다루는 워크로드에는 여전히 검색이 필요합니다.

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8단계: 긴 세션이나 에이전트로 실행되나요?

• 그렇다면 무엇을 비울지(오래된 도구 결과), 무엇을 컴팩션할지, 무엇을 대화 바깥에 둘지(규칙, 진행 상황), 에이전트가 언제 새로 시작할지를 미리 정하세요. 조기 종료도 기록하세요.
• 아니라면 단발성 요청에는 1단계부터 7단계까지면 충분합니다.

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

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

---

자주 묻는 질문

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

컨텍스트 로트는 입력이 길어질수록 LLM이 그 입력을 활용하는 능력이 떨어지는 것으로 측정된 현상이며, 컨텍스트 윈도우가 다 차기 한참 전부터 나타납니다. 검색과 추론의 정확도는 고르지 않게, 모델마다 다른 폭으로 떨어지며, 방해 텍스트가 정답과 닮아 있으면 더 빨리 떨어집니다. Chroma는 시험한 18개 모델 전부에서 일관된 건초더미가 뒤섞인 건초더미보다 더 해로웠다는 사실을 발견했고, Anthropic의 문서는 이제 이 용어를 직접 정의합니다. "토큰 수가 늘어날수록 정확도와 재현율이 저하되며, 이 현상을 컨텍스트 로트라고 합니다." 1M 토큰 윈도우를 채운다고 1M 토큰 품질의 답이 나오지는 않습니다.

컨텍스트 로트는 어떻게 고치나요?

더 적고 더 좋은 토큰을 보내세요. 앱과 에이전트라면, 밀어 넣는 대신 검색하고 리랭크하기, 긴 문서를 질문보다 앞에 두기, 오래된 도구 결과 비우기, 윈도우가 차기 전에 컴팩션하기, 규칙과 진행 상황을 대화 바깥에 두기, 탐색을 서브에이전트에 맡기기를 뜻합니다. 채팅 도구와 코딩 도구라면, 작업 하나에 채팅 하나, 수정이 두 번 실패하면 다시 시작하기, 초점 지시와 함께 일찍 컴팩션하기, 계속 지켜야 할 규칙은 CLAUDE.md처럼 에이전트가 다시 읽는 파일에 두기를 뜻합니다.

Claude Opus 5.5나 GPT-6 같은 최신 모델은 컨텍스트 로트를 해결하나요?

면역인 모델은 없지만, 모델 간 격차는 큽니다. OpenAI는 자사 8-needle MRCR에서 GPT-6 Astra가 512K에서 1M 토큰 구간에 96.3퍼센트를 기록했다고 발표했고, Google의 모델 카드는 같은 테스트의 Google 자체 버전에서 Gemini 3.1 Pro가 1M에서 26.3퍼센트라고 밝힙니다. 데이터셋은 다르지만, 무시하기에는 격차가 너무 큽니다. Anthropic의 문서는 컨텍스트 로트를 입력이 커지면 나타나는 일반적인 성질로 설명하고, Claude Code의 문서는 성능이 "채워질수록 저하된다"고 말합니다. 실제로 쓰는 모델을, 여러분의 입력과 닮은 입력으로 측정하세요.

2026년에도 RAG는 여전히 유효한가요?

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

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

일반적인 경우에는 아닙니다. Chroma의 Context Rot 보고서는 윈도우가 차기 한참 전에 성능이 저하된다는 것을 보여주었고, 벤더들도 이에 동의하는 것처럼 제품을 만듭니다. Anthropic의 임계값 컴팩션은 1M 토큰 모델에서 기본값이 150K이고, OpenAI는 입력 272K 토큰 위에서 요청 단가를 다시 매기며, Google은 200K를 넘는 Gemini 3.1 Pro 프롬프트에 더 높은 요금을 받습니다. 다만 측정한 안전 예산 안에 들어가는 한도가 정해진 문서 한 편에 대해서라면, 롱 컨텍스트가 RAG를 대체합니다.

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

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

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

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

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

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

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

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

---

맺으며

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

남은 것은 지루하지만 생산적인 답입니다. 검색을 만드세요. 튜닝하세요. 리랭커를 붙이세요. 모델에 더는 필요 없는 것은 비우고, 절대 잃어서는 안 되는 것은 대화 바깥에 보관하세요. 사양서를 믿는 대신 측정으로 안전 컨텍스트 예산을 정하고, 모델이나 토크나이저가 바뀌면 다시 측정하세요. 2026년 9월부터 10월 초 사이에는 Anthropic, OpenAI, Google 모두에서 바로 그런 변화가 있었습니다. 정답을 담고 있는 가장 작고 가장 관련성 높은 토큰 집합을 보내세요. 모델이 그 위에서 추론하게 하세요. 출처를 인용하세요.

2026년의 반전은 이제 벤더들이 여러분에게 동의하는 것처럼 제품을 설계한다는 점입니다. OpenAI의 272K 선, Gemini 3.1 Pro에 그어진 Google의 200K 선, Haiku 5.5의 100K 선, 그리고 100만 토큰 Claude 모델의 150K라는 컴팩션 기본값은 모두 실사용 가능한 윈도우가 광고된 윈도우의 일부에 지나지 않는다는 자백입니다. Anthropic이 더 큰 모델에 적용하는 균일 요금은 가격 절벽을 없애지만 정확도 비용까지 없애지는 못하며, 균일 요금에서도 토큰이 적을수록 비용은 여전히 적게 듭니다. 그러니 규율 있는 아키텍처가 곧 값싼 아키텍처이기도 합니다. 이 둘이 같은 방향을 가리키는 일은 흔치 않습니다.

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