AI 모델의 컨텍스트 창은 빠르게 커지고 있습니다. 이제 128K 토큰 이상을 처리한다고 주장하는 장문 컨텍스트 모델도 흔합니다.1 하지만 컨텍스트 창이 크다는 말은 “많이 넣을 수 있다”는 뜻이지, “끝까지 안정적으로 활용한다”는 뜻은 아닙니다.
롱 컨텍스트 저하(long-context degradation)는 입력이 길어질수록 모델의 답변 품질, 지시 준수, 추론 일관성이 떨어지는 현상입니다. 창이 물리적으로 꽉 차서 실패하는 문제가 아니라, 중요한 정보가 오래된 지시, 중간 산출물, 로그, 실패한 시도 사이에 묻히면서 모델이 덜 정확하게 사용하는 문제에 가깝습니다.
2026년 5월 27일 OP#420Teortaxes가 X에 올린 게시물도 이런 실무적 불안을 잘 보여줍니다. 해당 게시물은 V4 Pro에서 약 35만 토큰 또는 400턴 주변의 장문 컨텍스트를 언급하며, 모델이 임시 수정, 삭제, 커밋 누락 같은 성능 저하를 보였다고 주장했습니다. 이 사례 자체보다 중요한 것은 질문입니다. 긴 컨텍스트를 지원한다는 모델을 우리는 어떻게 평가하고, 어떻게 써야 할까요?
긴 컨텍스트의 핵심 변수는 길이만이 아니다
긴 입력에서 모델은 모든 위치의 정보를 똑같이 잘 쓰지 못할 수 있습니다. 그래서 Needle-in-a-Haystack이나 RULER 같은 검색 평가는 정답 위치를 컨텍스트의 앞, 중간, 뒤로 옮겨가며 성능을 봅니다.1 정보의 위치가 성능에 영향을 준다는 점을 평가 설계에 반영하는 것입니다.
문제는 많은 장문 추론 벤치마크가 이 변수를 충분히 통제하지 않는다는 데 있습니다. SCROLLS, LongBench, L-Eval, LooGLE은 과제 관련 정보의 위치를 실험자가 지정하지 않고 원문 문서의 위치를 그대로 따릅니다.1 또한 조사된 11개 장문 컨텍스트 벤치마크 중 추론 과제에서 과제 위치, 필러 내용, 컨텍스트 길이를 함께 통제한 사례는 없었습니다.1
따라서 “긴 문서를 입력했다”는 사실만으로는 충분하지 않습니다. 모델이 문서 중간에 있는 조건, 오래전에 나온 제약, 뒤쪽에 추가된 변경사항을 실제로 안정적으로 반영하는지 별도로 확인해야 합니다.
좋은 에이전트·코딩 점수가 장문 안정성을 보장하지는 않는다
최근 모델 발표에서도 이 간극이 보입니다. DeepSeek-V4-Pro, MiMo-V2.5-Pro, Kimi-K2.6, GLM-5.1의 주요 결과표에는 NIAH, RULER, LongBench 계열 벤치마크 항목이 없었습니다.1 대신 SWE-Bench와 브라우저·터미널 기반 에이전트/코딩 벤치마크가 전면에 배치됐습니다.1
예를 들어 DeepSeek-V4-Pro의 주요 Instruct 표에는 SWE-Bench Verified 80.6, BrowseComp 83.4, Terminal-Bench 67.9가 보고됐습니다.1 반면 LongBench-V2 51.5 EM은 Base 평가표에만 등장했습니다.1
이런 점수들이 무의미하다는 뜻은 아닙니다. 코딩, 브라우징, 터미널 작업 성능은 분명 중요한 능력입니다. 다만 그 점수만으로 모델이 10만 토큰 뒤의 지시, 중간에 묻힌 예외 조건, 오래된 작업 로그를 안정적으로 유지한다고 판단해서는 안 됩니다. 에이전트 성능과 장문 컨텍스트 안정성은 겹치지만 같은 지표가 아닙니다.
실무에서 보이는 신호들
롱 컨텍스트 저하는 대개 명확한 오류 메시지보다 행동의 흔들림으로 드러납니다.
이미 실패한 수정을 다시 시도한다.
이전 요구사항과 최신 요구사항을 섞는다.
금지한 작업을 수행하려 한다.
임시 수정만 하고 핵심 변경을 놓친다.
삭제, 커밋, 테스트 같은 절차적 단계를 누락한다.
긴 로그나 파일을 넣었는데 정작 중요한 한 줄을 반영하지 못한다.
이런 증상이 나타났다고 해서 모델의 기본 지능이 갑자기 낮아졌다고 볼 필요는 없습니다. 더 흔한 원인은 컨텍스트 관리 실패입니다. 즉, 모델이 필요한 정보를 못 받은 것이 아니라, 너무 많은 정보 속에서 무엇을 우선해야 하는지 불안정해진 것입니다.
긴 컨텍스트는 저장소가 아니라 작업 공간이다
실무적으로는 컨텍스트를 “가능한 한 많이 넣는 공간”이 아니라 “현재 작업에 필요한 정보를 배치하는 작업 공간”으로 다뤄야 합니다.
가장 중요한 원칙은 세 가지입니다.
긴 작업은 세션을 나눈다
한 세션에 모든 대화, 로그, 실패한 시도, 파일 내용을 계속 누적하지 않습니다. 일정 단계가 끝나면 새 세션을 만들고, 핵심 목표와 현재 상태만 짧게 인수인계합니다.핵심 제약은 잘 보이게 둔다
반드시 지켜야 하는 조건은 프롬프트의 앞부분이나 끝부분처럼 눈에 띄는 위치에 둡니다. 긴 중간 로그 속에 중요한 제약을 한 번만 넣어두는 방식은 위험합니다.오래된 정보는 요약하거나 제거한다
실패한 접근, 폐기된 요구사항, 더 이상 필요 없는 로그는 그대로 누적하지 않습니다. 필요한 경우 “시도했지만 폐기한 방법” 정도로 짧게 정리하고, 현재 의사결정에 필요한 정보만 남깁니다.
긴 컨텍스트 모델은 유용합니다. 큰 코드베이스, 긴 문서, 복잡한 작업 기록을 한 번에 다룰 수 있게 해주기 때문입니다. 그러나 긴 컨텍스트는 완벽한 기억장이 아닙니다. 많이 넣는 것보다 중요한 것은 지금 필요한 정보를 모델이 찾기 쉬운 위치에, 덜 헷갈리는 형태로 제공하는 것입니다.
결국 롱 컨텍스트 저하가 주는 실무적 교훈은 단순합니다. 컨텍스트 창의 크기를 모델 능력의 상한으로 착각하지 말아야 합니다. 긴 작업일수록 정보를 줄이고, 정리하고, 재배치하는 능력이 모델 선택만큼 중요합니다.
1Positional Failures in Long-Context LLMs: A Blind Spot in Reasoning Benchmarks
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.