컨텍스트 변질: 입력 토큰이 많아질수록 LLM 성능이 어떻게 변하는가

• 최신 LLM의 입력 토큰 한도(컨텍스트 윈도우) 가 수백만 단위까지 확장되었으나, 단순 검색 벤치마크(Needle in a Haystack, NIAH)에서 높은 점수를 받아도 실제 긴 입력에서의 성능 저하는 명확히 존재함
• 연구진은 18개 모델을 대상으로 다양한 실험을 수행, 입력 길이 증가만을 통제한 상태에서도 성능 저하와 비일관적 패턴이 반복적으로 확인됨
• 질문-정답 유사도 하락, 방해문(디스트랙터) 추가, 지문 구조의 변화에 따라 성능 하락 속도가 가속되거나 예측 불가능하게 바뀌는 현상이 두드러짐
• 구조적 맥락(논리적 문단 흐름) 유지가 오히려 성능에 부정적 영향을 주는 등, 입력의 배열과 방식이 LLM 성능에 큰 영향을 미침
• 단순 반복 텍스트 복사처럼 매우 쉬운 작업조차 입력 길이가 늘어날수록 일관성 있는 결과를 내지 못하는 한계가 드러나, 실제 적용 시 맥락 설계(컨텍스트 엔지니어링)의 중요성이 강조됨

---

연구 배경과 목적

• 최근 LLM의 컨텍스트 윈도우가 100만~1000만 토큰까지 늘어나면서, 긴 입력에도 “성능이 보장된다”는 인식이 확산됨
  • Gemini 1.5 Pro, GPT-4.1, Llama 4 등이 대표적임
• 대표 벤치마크인 Needle in a Haystack(NIAH) 은 단순 문장 검색에 불과해, 실제 장문 문서 요약·질의응답 등 복합적 과제에서의 성능 저하를 제대로 반영하지 못함
• 본 연구는 입력 길이만 조절하고, 과제 난이도는 고정하는 방식으로 성능 변화를 체계적으로 검증함

주요 실험 및 결과

• 18개 최신 LLM(Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen 등) 을 대상으로 총 4가지 실험 설계:
  • 질문-정답(Needle-Question) 의미 유사도 변화
  • 방해문(디스트랙터) 추가
  • 지문(헤이스택) 주제/구조 변화
  • 반복 단어 복사(출력 길이와 입력 길이 동시 확장)
• 모든 실험에서 입력 길이가 길어질수록 성능이 급격히 저하되며, 특히 의미 유사도가 낮거나 방해문이 많을수록 하락폭이 커짐
• 질문-정답 유사도가 낮을수록 긴 입력에서 오답 비율이 급상승함
• 방해문이 하나만 추가돼도 정답률이 즉시 떨어지고, 4개 이상 추가하면 모델별로 혼동·환각(hallucination) 현상이 크게 증가함
  • 예시: Claude 계열은 오답 대신 “정답을 찾을 수 없음”이라고 회피하는 경향이 강하며, GPT 계열은 확신에 찬 오답을 더 많이 생성함
• 지문 구조(논리 흐름/무작위 배열) 에 따라 성능이 반전되는 특이 현상도 관찰됨
  • 논리적 흐름을 지키는 원본(Original) 지문에서는 오히려 모델 성능이 더 나빠짐
  • 문장이 무작위로 섞인(Shuffled) 지문에서는 오히려 검색 성능이 더 높아짐
• 반복 단어 복사 실험에서도 입력·출력 토큰이 늘어날수록 오답률·작업 거부·임의 단어 생성 등 예측 불가능한 패턴이 증가함
  • 예시: 2,500~5,000단어 이후 특정 모델에서 복사 거부, 임의 텍스트 생성 등 비정상 결과 급증

LongMemEval: 실전형 장기 대화 평가

• 실제 대화 기록이 포함된 LongMemEval 벤치마크에서 집중 입력(정답과 관련된 부분만 포함)과 전체 입력(정답과 무관한 맥락까지 포함) 을 비교
• 모든 모델에서 집중 입력이 훨씬 더 높은 정답률을 보였으며, 전체 입력에서는 관련 내용 찾기 자체가 추가 과제로 작용해 성능이 크게 저하됨
• Claude 계열 모델은 특히 모호한 상황에서 “정답 없음”으로 회피하는 경향이 뚜렷함

추가 분석 및 시사점

• 방해문별 혼동률, 답변 위치 정확도, 임의 단어 생성 위치 등 모델별 내부 동작 패턴 차이를 다양한 그래프로 정밀 분석함
• 반복 단어 복사 실험에서, 정답 단어가 앞쪽에 위치할수록 정확도 높음 등 위치 의존적 특성이 있음
• 컨텍스트 설계(정보 배열, 논리적 흐름 관리 등) 가 모델 성능에 미치는 영향이 매우 크므로, 실제 서비스 적용 시 단순 컨텍스트 확장만으로 일관된 성능을 기대할 수 없음을 시사함

결론

• LLM의 장문 입력 처리 능력은 벤치마크 점수로 보장되지 않으며, 실제 입력 길이 증가만으로도 비일관적 성능 저하가 나타남
• 관련 정보의 단순 포함만으로는 충분치 않으며, 정보의 배열·구조·방해문·유사도 등이 모두 성능에 결정적 영향을 줌
• LLM 활용 시 장문 컨텍스트 관리와 설계(컨텍스트 엔지니어링) 가 반드시 필요함

[ididid393939]

2.5 나온지도 한참은 됐는데 1.5를 왜

[GN⁺]

Hacker News 의견

• 나 역시 이와 비슷한 경험을 했음. 특히 Gemini Pro를 사용할 때 긴 텍스트 레퍼런스를 제공하면, 여러 문서를 한 번에 컨텍스트 윈도우에 넣는 것보다 먼저 각 문서를 요약해서 질문을 한 다음, 필요하면 세부 문서 전체를 RAG 스타일 또는 간단한 에이전트 루프로 제공하는 것이 훨씬 더 좋은 답변을 얻을 수 있었음. 비슷하게 Claude Code를 Opus나 Sonnet과 함께 쓸 때도, 컴팩션(compaction)이 많이 일어날수록 결과가 나빠지는 걸 직접 경험함. 요약의 질이 떨어져서 그런 건지, 아니면 컨텍스트 윈도우 내에 덜 관련된 데이터 비중이 높아져서 그런 건지는 확실하지 않지만, 컨텍스트를 비우고 관련 파일만 다시 읽으라고 하면 (이전 요약에서 이미 언급됐다 해도) 훨씬 더 결과가 괜찮았음

  • Gemini는 챗 컨텍스트 한계에 이르기 전에 이미 일관성과 추론력에서 무너지기 시작함. 그런데도 이 보고서에 따르면 여러 면에서 최고 모델임. 결론은 컨텍스트 엔지니어링이 여전히 중요하고, RAG 접근법도 여전히 유효함

  • "컴팩션"은 결국 트랜스크립트를 요약으로 단축하는 것 아닌가? 그렇다면 정보가 실제로 손실되기 때문에 성능이 나빠지는 건 당연함. 하지만 이건 컨텍스트 로트(context rot) 때문이 아님. 진짜 컨텍스트 로트 신호는 오토-컴팩트(자동 축약) 임계점에 다가갈 때 나타남. 내가 제대로 이해하고 있는 것 같음?

  • 최적의 코딩 에이전트라면 이런 과정을 자동으로 해줄 것 같음. 필요한 코드, MCP 응답, 레포 맵 등을 수집해서 가끔 요약하고, 모두를 새로운 챗 메시지로 합쳐서 정말 필요한 부분만 남겨놓는 식임. 난 aider라는 도구로 이미 이런 스타일을 쓰고 있는데, 많은 컨텍스트가 필요한 상황에선 에이전틱하거나 자동화된 워크플로보다 훨씬 성능이 좋았음. 단, 손이 많이 감

  • NotebookLM을 써봤는지? 이 앱은 백그라운드에서 문서를 쪼개고 요약해주며, RAG를 통해 전체 문서에 챗 형태로 질문할 수 있음

• Cursor에서 새로운 기능이나 코드 변경에 대해 오랜 시간 대화할수록 결과물이 점점 안 좋아지는 것을 경험함. 가장 좋은 결과는 명확하고 구체적인 지침과 계획을 먼저 세우고, 수정할 파일들을 컨텍스트 프롬프트에 직접 끌어다 놓았을 때 나왔음

  • "Explore → plan → code → test → commit" 흐름으로 진행하는 게 훨씬 더 도움이 되었음. 필요하다면 각 단계마다 컨텍스트를 클리어해서 효과를 높일 수 있음

  • 특정 작업을 위한 충분한 정보가 모이면, 그때 컨텍스트를 저장함. 품질이 떨어지는 게 보이면, 지금까지의 작업을 다시 요약해서 이전 체크포인트에 덧붙임

• 이 현상은 잘 알려져 있지만 제대로 문서화된 곳이 별로 없어서 이번 글이 매우 반가움. 벤치마크로 쉽게 측정하기 힘들 정도로 실질적 영향이 더 크다고 생각함. 진짜 쓸모 있는 LLM 기반 앱들은 모델이 해낼 수 있는 한계점에 머물러 있음. 즉, 실제 질문이나 작업에서 논리적으로 몇 번씩 "점프"해야 하는 컨텍스트를 따라가야 할 때 의미가 큼. 여러 번의 논리적 "점프"가 필요할수록 컨텍스트 로트 문제가 폭발적으로 심해진다고 생각함. 각 점프마다 주의해야 할 대상이 늘어나기 때문임

• 컨텍스트를 손쉽게 잘라낼 방법이 꼭 필요함. 모델과 전체 대화를 내가 직접 관리할 수 있으면, 대략 20만 토큰짜리 코딩 세션에서 훨씬 더 많은 퍼포먼스를 뽑아낼 수 있을 것 같음. 그런데 현실은 좋은 인스턴스를 쓰더라도 2만 토큰쯤 지나면 모델이 자꾸 이상해지고, 세션도 완전히 로트됨. 그냥 이 부분을 잘라내버릴 수 있으면 좋겠음

  • 로컬 LLM은 원하는 대로 컨텍스트를 편집할 수 있어서, LLM의 응답 자체를 수정해 두면 나중에 모델이 자신이 원래 말한 것처럼 착각할 수도 있음. 그래서 원하는 방향으로 유도하는 데 유리함. 반면 LLM-as-a-service 모델은 이런 기능을 제공하지 않는데, 검열 우회를 쉽게 만들 수 있기 때문임

  • "헤이 Claude, 이제 컨텍스트를 리셋할 건데 앞으로 계속 작업할 수 있도록 프롬프트 하나 만들어줘"라고 요청한 뒤, Claude가 제안한 프롬프트를 미리 살펴보고 다듬어서 다시 넣는 실험을 해봤음

  • 이전 체크포인트로 쉽게 롤백할 수 있으면 정말 최고의 기능일 것 같음

  • 대부분의 CLI 에이전트에서는 /compress 명령어로 이런 작업을 할 수 있음

• Claude code를 쓰다 보면 점점 자신의 실수와 내 지시를 구분하지 못함. 헷갈리기 시작하면, 세션을 새로 여는 게 답임. 세션이 길어질수록 같은 루프를 돌거나 스스로 테스트가 이미 깨졌다고 우겨서 무시해버림(실제로는 이 세션에서 깨졌는데도). 내가 프롬프트를 잘못 넣은 탓이겠지만, 요즘 Claude가 어느샌가 30 IQ 정도 떨어진 것 같음

  • 나도 똑같이 느낌. 맥스 플랜인데도 성능 좋을 때와 안 좋을 때가 확실히 있음

  • "내 프롬프트와 컨텍스트가 문제겠지"라고 생각하는 거, 우리 모두 내면화된 가스라이팅 느낌임

• 이건 정보 검색 문제의 한 유형이지만, 컨텍스트 길이 변화에 의한 성능 저하는 단순 검색 답변과 다르게 작동할 수 있다고 생각함. 예를 들어 “이 버튼을 빨갛게 수정하려면?” 같은 질문이나 “위의 문장들은 어떤 카테고리에 속하는가?” 같은 문제에서는 다르게 동작할 수 있음. 예전에 인상적이었던 논문으로 Many-Shot In-Context Learning 있었음. 이 연구에선 예시로 컨텍스트를 채울수록 성능이 크게 뛰는 현상을 보임. 결국 문제마다 실제로 직접 테스트해봐야 LLM이 컨텍스트 내용과 길이에 따라 어떻게 바뀌는지 알 수 있음. 항상 컨텍스트 길이가 길어지면 성능이 낮아진다고 가정하면 안 됨

  • 내 직관상 추론이 필요한 질문은 단순 검색 질문보다 예외 없이 항상 성능이 낮음. 특히 부정형 질문이나 덜 관련된 정보가 포함되어 있을 땐 더함. 그래도 직관이 데이터는 아니라는 점, 실제 숫자가 궁금함. In-context learning 현상은 장문 컨텍스트로 인한 성능 저하와 별개임. 두 현상은 동시에 존재함. 'lost-in-the-middle' 문제처럼, 예시 위치에 따라 성능이 달라질 수 있음

• 내용이 매우 쿨하고 통찰 많은 기사임. 다만 미디어 리터러시 관점에서 Chroma는 벡터DB 회사라는 점을 참고하면 좋겠음

  • Chroma는 벡터, 전체 텍스트, 정규식 검색까지 모두 지원함. 그리고 AI 애플리케이션에서 많이 쓰는 멀티테넌트 워크로드 환경에 최적임. 단순 벡터DB만 하는 회사가 아님

• 최근 Gemini 2.5 Flash로 장편 소설을 여럿 썼는데, 컨텍스트 로트는 분명히 느껴지지만 이 기사에서 제시한 것보다 훨씬 더 나중에 나타남. 내 경우 5만~10만 토큰 정도 지나야 초반 컨텍스트(예: 출력 언어 등)를 무시하기 시작했음. 아마 창작 같은 복잡한 태스크는 효과 측정이 더 어렵거나 덜 뚜렷할 수도 있음. 어쨌거나, 가끔 빠진 컨텍스트만 다시 넣어주면 쓸 만한 수준은 유지함

  • 소설 얘기 좀 더 듣고 싶음. 재밌게 잘 나왔는지, 출간 계획은 있는지 궁금함

• 나도 비슷하게 경험함. 프로젝트 중 영상 트랜스크립트 검색기능을 개발하는데, 텍스트 길이가 아주 길었음. GPT 4.1 같은 모델이 컨텍스트 윈도우가 크니까 RAG가 필요 없을 줄 알았는데, 특히 작은 모델에서 이상한 현상이 자주 발생했음. 질문에 제대로 답변하지 않고, 그냥 콘텐츠 전체 요약만 하는 경우가 있었음

• 흥미로운 리포트임. 모델별로 추천하는 컨텍스트 크기 같은 게 있는지 궁금함. 내 유스케이스에 어느 선까지가 적절한지 알 수 있는 방법이 있는지 알고 싶음