「컨텍스트 윈도우 (Context Window)가 100만 토큰이 되었다」라는 뉴스를 볼 때마다, 저는 그 반대로 생각합니다. 넣을 수 있는 양이 늘어났다고 해서, 넣어도 되는 양이 늘어난 것은 아닙니다.

오히려 실무에서는 반대입니다. 관련 없는 정보를 추가할수록 AI의 정답률은 떨어집니다. 이는 프롬프트 (Prompt) 작성 능력이 부족해서가 아닙니다. Transformer 구조에 뿌리를 둔, 피할 수 없는 현상입니다.

이 기사에서는 동일한 태스크 (Task)에 「관련 정보만」과 「관련 정보 + 대량의 노이즈」를 주었을 때, 입력 토큰 양과 정답률이 어떻게 움직이는지를 실측합니다. 결론부터 말하자면, 토큰을 늘릴수록 AI는 똑똑해지기는커녕 퇴화합니다.

이 기사는 컨텍스트 안에 섞이는 노이즈가 정밀도를 떨어뜨리는 현상 (context rot / lost in the middle)을 다룹니다. CLAUDE.md의 행수를 늘리면 설정 파일 자체가 비대해지는 이야기와는 별개의 축입니다. 전자는 「입력에 섞은 무관한 정보」의 문제이고, 후자는 「설정 파일의 사이즈」 문제입니다. 혼동하기 쉬우므로 먼저 구분해 두겠습니다.

context rot (컨텍스트 부패)란, 입력 토큰 양이 늘어날수록 LLM의 출력 품질이 저하되는 현상입니다. Chroma 연구팀이 2025년에 18개의 최첨단 모델을 검증했으며, 모든 모델에서 예외 없이 관측되었습니다.

검증 대상에는 Claude Sonnet 4, GPT-4.1, Gemini 2.5 Flash, Qwen3-32B가 포함됩니다. 태스크의 난이도를 일정하게 유지한 채 입력을 늘렸을 뿐인데, 모든 모델이 정밀도를 떨어뜨렸습니다.

정밀도를 좌우하는 것은 정보의 총량이 아니라, 그 안의 「무관한 정보의 혼입률」입니다. 동일한 정답을 찾는 태스크라도 주변의 노이즈가 늘어나면 정답을 찾기 어려워집니다. 도서관의 장서가 10배가 되어도, 목표로 하는 한 권을 찾기는 더 어려워질 뿐입니다.

Chroma의 연구는 또 하나의 중요한 지적을 하고 있습니다. 쿼리 (Query)와 정답의 의미적 유사성이 낮아질수록, 입력을 늘렸을 때의 퇴화가 가속화된다는 것입니다. 실제 환경에서 사용자는 정답과 완전히 일치하는 키워드로 질문하지 않습니다. 그렇기 때문에 실제 서비스일수록 context rot의 영향을 받기 쉽습니다. 깔끔한 테스트 질문으로는 문제가 없더라도, 현장의 모호한 질문에서는 무너집니다.

「컨텍스트는 많이 넣을수록 똑똑하다」라는 직관에는 근거가 있습니다. RAG 실험에서는 관련 문서를 추가하면 정답률이 극적으로 올라가기 때문입니다.

제가 이전에 검증한 케이스에서는 외부 지식을 주입함으로써 사실 정확성이 0에서 4.6(5점 만점)으로 뛰어올랐습니다. 그래서 「정보를 추가한다 = 똑똑해진다」라는 도식이 각인됩니다.

하지만 이 도식에는 전제가 있습니다. 추가하는 정보가 「관련되어 있다」는 것입니다. 관련 없는 정보를 추가하는 순간, 효과는 반전됩니다. 똑똑하게 만드는 것은 정보량이 아니라 관련도입니다. 이 점을 착각하면 컨텍스트에 쓰레기를 채워 넣는 방향으로 최적화하게 됩니다.

결론: 동일한 정답을 포함하는 컨텍스트라도, 무관한 토큰을 추가할수록 정답률은 단조롭게 떨어집니다.

저는 Anthropic API를 사용하여, 어떤 사내 사양에 대한 질문에 답하게 하는 실험을 구성했습니다. 정답의 근거가 되는 문서(약 300토큰)는 항상 포함한 채로, 주변에 무관한 문서를 추가하여 토큰량을 단계적으로 늘립니다.

태스크는 「초대 링크의 유효 기간은 몇 시간인가」라는 일문일답입니다. 정답의 근거 문장은 고정합니다. 바꾸는 것은 노이즈의 양뿐입니다. 이를 통해 「총량이 늘어나면 어떤 일이 일어나는가」를 분리합니다.

주목해야 할 점은 떨어지는 방식입니다. 500에서 4,000 토큰까지는 96%에서 91%로 완만했습니다. 그런데 16,000을 넘어서는 시점부터 낙차가 급격해집니다. 노이즈에는 「여기서부터 단번에 영향을 미친다」는 임계값(Threshold)이 있는 것처럼 보입니다. 조금 추가하는 정도는 괜찮다고 방심하고 있으면, 특정 양을 넘어서는 순간 무너집니다.

제가 처음 이 실험을 구성했을 때, 솔직히 말해서 「정답이 들어있으니 조금 희석되어도 괜찮겠지」라고 얕잡아 보고 있었습니다. 결과는 예상을 뒤엎었습니다. 정답이 물리적으로 존재하는 것과, 모델이 그것을 읽는 것은 별개의 문제였습니다.

수치는 모델과 태스크 (Task)에 크게 의존합니다. 제 환경(Claude 급의 모델, 일문일답 방식의 검색 태스크)에서의 경향치이며, 절대적인 수치의 재현을 보장하지는 않습니다. 중요한 것은 절대값이 아니라 「우하향하는 형태」입니다.

비용과 레이턴시 (Latency)도 확인하십시오. 토큰을 8배 늘리면 정확도는 떨어지고, 비용은 20배, 레이턴시는 5배 이상이 됩니다. 성능이 저하된 결과에 불필요하게 돈과 시간을 더 지불하는 구조입니다. 이것이 「길수록 똑똑하다」는 말의 실체입니다.

제 수치만으로는 근거가 부족하므로 공개 데이터와 대조해 보겠습니다. RULER 벤치마크에서는 GPT-4-1106이 4K 토큰에서 96.6점이었으나, 128K 토큰에서는 81.2점까지 떨어졌습니다. Llama 3.1-70B의 경우 96.5점에서 66.6점으로 크게 침몰했습니다.

예외도 있습니다. Gemini 1.5 Pro는 128K에서도 94.4점을 유지하며 하락 폭이 2.3점에 불과했습니다. 즉, 모델에 따라 내성은 다르지만, 「길어지면 기본적으로 저하된다」는 방향성은 공통적입니다. 장문 내성 (Long-context robustness)은 모델 선정의 평가 축이 됩니다.

결론: 같은 정보라도 컨텍스트 (Context)의 중간에 두면 양 끝에 두었을 때보다 읽기 어려워집니다.

컨텍스트 로트 (Context rot)에는 위치 의존적 현상이 세트로 따라옵니다. 바로 lost in the middle (중간에서 길을 잃음) 현상입니다. LLM은 입력의 맨 앞과 맨 뒤 정보에 강하게 주의를 기울이며, 중간의 정보는 간과합니다.

정확도를 위치별로 플롯 (Plot)하면 양 끝은 높고 중간은 움푹 들어가는 U자형 커브가 나타납니다. 이는 모델, 태스크, 컨텍스트 길이를 바꿔도 일관되게 나타납니다.

수치로 보면 심각성을 알 수 있습니다. 20개 문서로 구성된 QA 태스크에서 정답이 맨 앞에 있으면 약 75%, 맨 뒤에 있어도 약 72%의 정답률을 보였습니다. 그런데 key-value 검색에서는 양 끝에서 거의 만점을 내던 모델이, 정답을 중간에 두자마자 40% 미만으로 무너졌습니다.

원인은 모델의 지능이 아니라 구조에 있습니다. 트랜스포머 (Transformer)의 인과적 어텐션 마스크 (Causal attention mask)와 위치 인코딩 (Position encoding)이 맨 앞을 향한 주의 (Primacy bias)와 맨 뒤를 향한 주의 (Recency bias)를 만들어냅니다.

즉, 입력을 어디에 두느냐에 따라 「같은 정보의 읽기 쉬움」이 달라집니다. AI는 내용의 중요도가 아니라, 놓인 위치에 따라 정보를 편식합니다. 회의에서 처음과 마지막 발언만 기억에 남는 것과 같은 구조입니다.

여기에도 예외는 있습니다. Gemini 2.5 Flash는 단순한 사실 관계 Q&A라면 위치와 상관없이 정답을 찾아낼 수 있다는 보고가 있습니다. 장문 검색의 개선은 진행되고 있지만, 복잡한 태스크에서 U자형 커브가 사라진 것은 아닙니다. 「우리 모델은 괜찮다」고 단정 짓지 말고, 자신의 태스크에서 직접 측정하는 것이 안전합니다.

결론: 토큰이 늘어나면 어텐션 (Attention)이 희석되어, 정답의 근거로 향하는 비중이 낮아집니다.

원리는 간단합니다. LLM은 입력된 모든 토큰에 주의를 배분합니다. 주의의 총량에는 한계가 있기 때문에, 토큰이 늘어나면 1토큰당 배분되는 양은 희석됩니다.

정답의 근거로 향해야 할 주의가 무관한 토큰에 흡수되어 버립니다. 이것이 어텐션의 희석 (Attention dilution)입니다. 아래 코드는 컨텍스트 내 관련 토큰의 비율을 측정하는 최소한의 예시입니다.

def relevant_token_ratio(context_chunks, relevant_ids, count_tokens):
"""컨텍스트 중 관련 토큰 비율을 측정한다.
이 비율이 낮아질수록 Attention이 희석되어 정확도가 떨어진다."""
...

이 비율을 모니터링하면 컨텍스트가 너무 비대해지는 타이밍을 포착할 수 있습니다. 저는 0.3 미만으로 떨어지면 경고를 보내도록 설계하고 있습니다. 임계값은 태스크에 따라 다르지만, 시각화하는 것만으로도 「일단 전부 다 넣자」는 유혹을 떨쳐낼 수 있습니다.

나아가 무관한 정보는 어텐션을 희석할 뿐만 아니라, recency bias (최신성 편향)도 악화시킵니다. 노이즈를 맨 뒤에 쌓으면 모델은 그 노이즈를 우선적으로 읽고, 본래의 지시 사항을 뒤로 미룹니다. 정보를 채워 넣는 것은 이중으로 악영향을 미칩니다.

결론: 해결책은 「더 많이 넣는 것」이 아니라 「필요 충분한 수준까지 깎아내는 것」입니다.

컨텍스트 로트 (Context rot)와 lost in the middle에 대한 대책은 모두 컨텍스트를 현명하게 압축하는 방향으로 수렴됩니다. 2026년의 현장에서 유효할 대응책을 4가지로 정리합니다.

첫 번째 방어선은 리트리벌 (Retrieval)입니다. 검색이 허술하면 무관한 문서가 대량으로 흘러 들어옵니다. 청크 (Chunk) 사이즈 조정, 메타데이터 필터, 하이브리드 검색 (벡터 + 키워드)을 통해 입구에서의 관련도를 높여야 합니다.

문서의 수를 늘리기보다 관련도가 높은 소수로 압축하는 것이 정답률을 높입니다. top_k는 클수록 좋다는 고정관념은 버려야 합니다. 검색(retrieval)에서 20건을 뽑아 전부 집어넣는 것보다, 정말 효과적인 3건만 전달하는 것이 저의 실측 커브상 확실히 더 높은 정답률에 도달합니다.

retrieval로 뽑은 후보를 cross-encoder의 reranker로 재채점합니다. 쿼리(query)와의 진정한 관련도로 점수를 다시 매겨, 노이즈를 하위로 밀어내어 잘라냅니다.

2026년의 RAG 최적화에서는 이 reranking + 압축이 주역이 되고 있습니다. 검색으로 넓게 뽑고, reranking으로 날카롭게 좁힌다. 이 2단계 전략이 정석입니다.

에이전트(agent)를 길게 구동하면 과거의 대화 내용이 끝없이 쌓입니다. 이것이 그대로 노이즈가 됩니다. 오래된 이력의 요약, 해결된 태스크의 삭제, 중복 제거를 통해 이력을 가지치기해야 합니다.

2026년의 연구에서는 에이전트 스스로가 "언제 학습을 통합하고, 언제 생로그(raw log)를 버릴 것인가"를 판단하는 자율적인 메모리 관리(memory management)가 제안되고 있습니다. 이력은 방치하면 부패합니다. 저도 에이전트를 장시간 실행했을 때, 초반의 지시를 후반에 무시하기 시작한 경험이 있습니다. 원인을 추적해 보니, 중간에 쌓인 생로그가 지시 사항을 중간 지점으로 밀어내고 있었습니다. lost in the middle 현상이 이력의 축적을 통해 조용히 작용하고 있었던 것입니다.

lost in the middle 대책으로서, 가장 중요한 정보는 컨텍스트(context)의 맨 앞이나 맨 뒤에 배치합니다. 중간에 파묻히게 하지 않는 것만으로도 읽힐 확률이 올라갑니다.

지시나 규칙은 맨 뒤에, 전제 지식은 맨 앞에. 중간에는 우선순위가 낮은 보충 설명을 배치합니다. 동일한 정보량이라도 배치 방법을 바꾸는 것만으로 정밀도가 움직입니다. 비용과 토큰 수도 변하지 않는데 정밀도만 올라가므로, 이는 가장 먼저 시도해 볼 가치가 있습니다.

지금까지의 실측을 통해 알게 된 점을 정리합니다.

• 입력 토큰을 늘릴수록 정답률은 떨어진다 (context rot). 저의 실측에서는 96%에서 52%까지 저하되었습니다.
• 공개 벤치마크에서도 동일한 경향이 나타납니다. GPT-4-1106은 4K에서 96.6점이었으나 128K에서는 81.2점으로 떨어졌습니다.
• 동일한 정보라도 중간에 두면 무시된다 (lost in the middle). 중간의 정답률은 40% 미만으로 무너지는 경우가 있습니다.
• 원인은 모델의 결함이 아니라 Transformer의 구조입니다. Attention의 희석과 위치 편향(position bias) 때문입니다.
• 대책은 "더하는 것"이 아니라 "깎는 것"입니다. retrieval 정밀도, reranking, 이력 가지치기, 구조화입니다.

"컨텍스트는 길수록 똑똑하다"는 말은 관련 정보에 한해서만 해당되는 이야기입니다. 무관한 정보까지 포함하면 길이는 곧 성능 저하와 직결됩니다. 100만 토큰을 넣을 수 있다고 해서, 100만 토큰을 넣어야 할 이유는 되지 않습니다.

실무에서 사용할 수 있도록, 투입 전 확인해야 할 항목을 정리합니다.

• 이 컨텍스트에 태스크와 무관한 문서가 섞여 있지 않은가
• 관련 토큰 비율을 측정했는가 (기준: 0.3 미만이면 위험)
• retrieval의 top_k를 "많을수록 좋다"는 기준으로 결정하지 않았는가
• reranking을 통해 저관련 チャンク(chunk)를 탈락시키고 있는가
• 대화 이력에 오래된, 해결된, 혹은 중복된 정보가 쌓여 있지 않은가
• 가장 중요한 지시/지식을 컨텍스트의 양 끝에 배치했는가
• 장문에서의 저하 내성을 자신의 태스크로 실측했는가
• 토큰 증가에 따른 비용과 레이턴시(latency)를 허용할 수 있는가

여러분은 자신의 RAG나 에이전트에서 관련 토큰 비율을 측정해 본 적이 있습니까? 저의 실측치는 어디까지나 하나의 예시입니다. 다른 모델이나 태스크에서 다른 형태의 커브가 나타난다면 꼭 댓글로 공유해 주세요. 어디서 저하가 시작되는지는 현장마다 다를 것입니다.

• Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma)
• Lost in the Middle: How Language Models Use Long Contexts (arXiv)
• RAG부터 reranking까지, 컨텍스트 설계를 체계적으로 배우는 서적으로 『컨텍스트 엔지니어링』을 저술했습니다. 본 기사의 실측 근거가 된 실험 절차도 수록되어 있습니다.