에이전틱 엔지니어링의 부상 — 파트 2: 컨텍스트 윈도우(Context-Window) 군비 경쟁

컨텍스트 윈도우 (Context-Window) 군비 경쟁

대규모 언어 모델 (LLM) 주변의 기술적 흐름을 연대순으로 조사하는 시리즈의 두 번째 파트입니다. 파트 1은 ReAct가 프롬프트를 루프(loop)로 전환하며 마무리되었습니다. 이번 회차에서는 정보 문제에 대한 업계의 첫 번째 해답을 다룹니다: 모든 것을 담을 수 있을 만큼 컨테이너를 크게 만드는 것입니다.

요약 (TL;DR) — 2024년의 베팅은 거대한 컨텍스트 윈도우 (Context Window)가 정보 관리를 불필요하게 만들 것이라는 점이었습니다. 즉, 그냥 전부 다 집어넣으면 된다는 것이었죠. 하지만 연구 결과는 달랐습니다. 모델은 윈도우가 가득 차기 훨씬 오래전부터 성능이 저하되며, 정보의 존재만큼이나 위치가 중요하고 ("lost in the middle"), 테스트된 모든 모델은 입력값이 커질수록 신뢰도가 떨어집니다 ("context rot"). 교훈은 다음과 같습니다: 용량은 잘못된 지표입니다. 깨끗한 윈도우가 큰 윈도우보다 낫습니다.

베팅: 윈도우가 충분히 크다면, 신중할 필요가 없다

2024년 무렵, 특정한 낙관론이 자리 잡았습니다. 언어 모델을 기반으로 구축할 때의 핵심적인 어려움이 _어떤 정보를 모델 앞에 둘 것인가_를 결정하는 것이라면, 어쩌면 그 어려움은 순수한 용량 확장을 통해 공학적으로 해결할 수 있을지도 모른다는 생각이었습니다. 모델이 한 번에 입력으로 받을 수 있는 텍스트의 양인 컨텍스트 윈도우 (Context Window)를 충분히 크게 만들면, 모든 것을 그냥 넣을 수 있을 것이라 믿었습니다. 모든 문서, 모든 도구, 전체 대화 기록, 모든 지침까지 말이죠. 신중한 선택도, 검색 (Retrieval)도, 가지치기 (Pruning)도 필요 없습니다. 그냥 전부 던져 넣고 모델이 알아서 정리하게 두면 되는 것입니다.

모델 개발자들은 이에 부응했고, 수치는 빠르게 치솟았습니다. Databricks의 연구와 이후 Chroma의 보고서에 기록된 궤적은 대략 다음과 같습니다:

약 4년 만에 4,000 토큰 (tokens)에서 1,000만 토큰으로 증가했습니다. 각각의 도약은 가능해진 영역의 질적인 변화로 발표되었습니다.

모델 문서의 프레임워크(framing)는 이러한 낙관론을 더욱 강화했습니다. 예를 들어, Google의 Gemini 롱 컨텍스트(long-context) 자료들은 긴 형태의 텍스트 전체를 프롬프트(prompt)에 집어넣는 것과 같은 유스케이스(use cases)를 강조했습니다. 그 함의는 명확했습니다. 번거로운 정보 관리의 시대가 끝나가고 있다는 것이었습니다. Drew Breunig은 이후 당시의 분위기를 다음과 같이 요약했습니다. 긴 컨텍스트는 "RAG에 대한 열기를 꺾었고(프롬프트에 모두 넣을 수 있다면 굳이 최적의 문서를 찾을 필요가 없으니까요!), MCP 하이프(hype)를 가능하게 했으며(모든 도구에 연결하면 모델이 어떤 작업이든 수행할 수 있으니까요!), 에이전트(agents)에 대한 열광을 부채질했습니다."

이러한 베팅은 우리의 이야기에서 중요한데, 왜냐하면 이것이 선택되지 '않은' 경로이기 때문입니다. 업계는 컨텍스트 관리(context management)가 불필요하게 만들려고 시도했습니다. 하지만 그것이 불가능하다는 발견이 컨텍스트 관리를 하나의 전문 분야(discipline)로 만들었습니다. 이것이 바로 파트 3의 주제입니다.

"RAG는 죽었다" — 반복되는 논쟁

낙관론의 첫 번째 희생양은 RAG가 될 예정이었습니다.

검색 증강 생성 (Retrieval-Augmented Generation, RAG)은 2020년 당시 Facebook AI의 Patrick Lewis와 동료들에 의해 도입되었습니다 (NeurIPS 2020에서 발표). 그들의 프레임워크를 정확히 기술할 가치가 있는데, 이는 RAG의 지속성을 설명해주기 때문입니다.

그들은 모델의 파라미터적 (parametric) 메모리(사전 학습된 seq2seq 모델의 가중치에 내재된 지식)와 모델이 생성 시점에 쿼리(query)할 수 있는 비파라미터적 (non-parametric) 메모리(그들의 경우 위키피디아의 밀집 벡터 인덱스)를 결합했습니다. 그들은 RAG 모델이 파라미터 전용 모델보다 "더 구체적이고 사실적인" 출력을 생성한다는 것을 보여주었습니다.

그들이 밝힌 동기 중 두 가지는 이 시리즈 전체에서 중요합니다. 검색은 **출처 (provenance)**를 제공하며(어떤 문서가 답변의 근거가 되었는지 인용할 수 있음), **업데이트 가능한 지식 (updatable knowledge)**을 제공합니다(모델을 재학습시키지 않고도 인덱스를 변경할 수 있음).

요약하자면, 아이디어는 이렇습니다. 모델이 학습 과정에서 배운 것에만 전적으로 의존하는 대신, 쿼리 시점에 관련 문서를 검색하여 프롬프트에 배치하는 것입니다. 수년 동안 이것은 모델이 갖지 못한 지식(최신 사실, 개인 문서, 도메인 특화 자료)을 제공하는 표준적인 방법이었습니다.

긴 컨텍스트 윈도우 (Long context windows)는 RAG를 쓸모없게 만드는 것처럼 보였습니다. 백만 토큰 규모의 윈도우에 모든 문서를 다 집어넣을 수 있는데, 왜 굳이 가장 좋은 몇 개의 문서를 찾기 위해 검색 파이프라인 (retrieval pipeline)을 구축해야 할까요? 모델이 획기적으로 더 큰 윈도우를 탑재하여 출시될 때마다, "RAG는 죽었다"라는 새로운 선언이 뒤따랐습니다. Breunig은 이 패턴을 명시적으로 언급합니다: "모델이 컨텍스트 윈도우의 판돈을 높일 때마다, 새로운 'RAG는 죽었다' 논쟁이 탄생합니다. 가장 최근의 중요한 사건은 1,000만 토큰 윈도우를 갖춘 Llama 4 Scout가 등장했을 때였습니다."

하지만 RAG는 계속해서 죽지 않았습니다. 그 이유는 이번 파트의 핵심입니다: 윈도우를 채우는 것에는 "모두 다 집어넣으면 된다"라는 관점이 간과했던 비용이 따랐다는 사실이 밝혀졌기 때문입니다.

컨텍스트 크기가 커질 때마다 새로운 "RAG는 죽었다"라는 부고장이 작성되었습니다. 하지만 RAG는 자신의 장례식에 계속해서 다시 나타났습니다.

반증 사례, 파트 1: 윈도우가 가득 차기 훨씬 전부터 성능이 저하된다

가장 직접적인 반박은 2024년 말 Databricks의 Mosaic Research에서 나왔습니다. 이들은 큐레이션된 RAG 데이터셋(Databricks DocsQA, FinanceBench, 그리고 학술용 Natural Questions 세트)을 대상으로 13개의 오픈 및 폐쇄형 모델에 대해 2,000회 이상의 대규모 벤치마크 (benchmark) 실험을 수행했으며, 보정된 LLM-as-judge를 통해 이를 평가했습니다.

두 가지 결과가 낙관론에 반하는 결론을 내놓았습니다. 첫째, 더 많은 문서를 검색하는 것이 일반적으로 도움이 되었습니다. 더 많은 검색 정보는 정답이 컨텍스트 어딘가에 존재할 확률을 높였고, 유능한 롱 컨텍스트 (long-context) 모델들은 이를 활용할 수 있었습니다. 여기까지는 "다다익선" 진영에 유리한 결과였습니다.

하지만 두 번째, 그리고 결정적인 결과는 다음과 같습니다: 더 많은 컨텍스트가 항상 더 나은 것은 아니었으며, 대부분의 모델은 윈도우가 가득 차기도 훨씬 전부터 성능이 저하되기 시작했습니다. Databricks의 결과에 따르면, Llama-3.1-405B의 답변 정확도는 약 32,000 토큰 이후로 감소하기 시작했습니다. GPT-4-0125-preview는 약 64,000 토큰 이후로 감소했으며, 모든 컨텍스트 길이에 걸쳐 일관된 성능을 유지한 모델은 극소수에 불과했습니다. 대다수의 오픈 소스 (open-source) 모델은 광고된 용량의 아주 작은 부분인 약 16k~32k 토큰까지만 효과적인 RAG를 처리할 수 있었습니다.

Breunig은 명백한 결론을 도출했습니다: "만약 모델이 컨텍스트 윈도우 (context windows)가 채워지기도 훨씬 전에 오작동하기 시작한다면, 초거대 컨텍스트 윈도우가 무슨 의미가 있겠습니까?" 그의 답변은 거대한 윈도우가 요약 (summarization)과 사실 검색 (fact retrieval)이라는 두 가지 측면에서는 여전히 진정으로 유용하지만, 그 외의 경우에는 모든 모델이 그가 _주의력 한계 (distraction ceiling)_라고 부르는 지점을 가지고 있다는 것이었습니다. 즉, 컨텍스트를 더 추가할수록 응답이 개선되는 것이 아니라 오히려 저하되는 특정 길이를 의미합니다.

데이터를 담을 수 있을 만큼 충분히 큰 윈도우가 모델이 그 데이터를 잘 _사용할지_에 대해서는 아무것도 알려주지 않습니다.

Databricks가 기록한 실패 모드 (failure modes) 또한 매우 시사하는 바가 컸는데, 이는 성능 저하가 균일하게 나타나지 않음을 보여주었기 때문입니다. 즉, 서로 다른 모델들이 각기 다르고 특이한 방식으로 무너졌습니다. 어떤 모델들은 매우 긴 컨텍스트가 주어지면 실제 지시 사항을 무시한 채 단순히 입력을 요약해 버리기도 했습니다. 그리고 한 가지 눈에 띄는 패턴으로, Claude 3.5의 저작권 우려로 인한 답변 거부율은 16k 토큰에서 3.7%였으나 64k에서는 49.5%로 상승했습니다. DBRX의 지시 이행 (instruction-following) 능력은 8k에서 5.2%의 실패율을 보이다가 32k에서는 50.4%로 급락했습니다. 동일한 모델에 동일한 종류의 작업이 주어지더라도, 컨텍스트가 얼마나 차 있는지에 따라 마치 다른 시스템처럼 동작했습니다.

반대 증거, 파트 2: 정보가 어디에 위치하는지가 중요하다

Databricks가 컨텍스트가 커짐에 따라 성능이 떨어진다는 것을 보여주었다면, 그보다 1년 전의 한 연구는 모델들이 주어진 컨텍스트를 균등하게 사용하지조차 않는다는 사실을 이미 보여주었습니다.

"Lost in the Middle: How Language Models Use Long Contexts" (Nelson Liu 및 Stanford 대학교 동료 연구진, 2023; TACL 2024에 발표) 연구에서, 연구진은 긴 컨텍스트 (Long Context) 내의 서로 다른 위치에 단 하나의 관련 문서를 배치하고, 모델이 이를 얼마나 잘 찾아내고 사용하는지를 측정했습니다. 결과는 일관된 **U자형 성능 곡선 (U-shaped performance curve)**을 나타냈습니다. 모델은 관련 정보가 컨텍스트의 맨 처음이나 맨 끝에 있을 때 가장 좋은 성능을 보였으며, 중간에 있을 때는 현저히 낮은 성능을 보였습니다. 이는 긴 컨텍스트를 위해 명시적으로 설계된 모델들조차 마찬가지였습니다. 테스트된 가장 강력한 모델인 GPT-4는 다른 모델들보다 높은 절대 점수를 기록했지만, 여전히 동일한 U자형 패턴을 보여주었습니다.

"Lost in the middle" U자형 곡선: 관련 정보는 컨텍스트의 가장자리에서는 안정적으로 사용되지만, 중간 부분에서는 무시됩니다.

저자들은 이를 심리학에서 오랫동안 알려진 현상인 순서 위치 효과 (serial-position effect), 즉 목록의 처음과 마지막 항목을 가장 잘 기억하는 인간의 경향성과 연결 지었습니다. 트랜스포머 (Transformer) 모델 내에서의 원인이 무엇이든 (시퀀스의 처음과 끝에 과도한 가중치를 두는 어텐션 (Attention) 패턴 등), "모두 다 집어넣으면 된다"는 접근 방식에 있어 실질적인 시사점은 매우 불편한 것이었습니다. 컨텍스트를 추가하는 것이 결국 성능을 저해할 뿐만 아니라, 주어진 사실을 사용하는 모델의 능력은 그 사실이 뭉치 중 어디에 위치하느냐에 따라 달라진다는 점입니다. 정보의 존재 여부뿐만 아니라, 위치가 정보의 사용 여부를 결정합니다.

반증, 파트 3: "컨텍스트 부패 (context rot)"

가장 명확한 공식화는 군비 경쟁이 한동안 지속된 후인 2025년 중반, 이 현상에 이름을 붙인 보고서를 통해 등장했습니다. Chroma Research의 "Context Rot: How Increasing Input Tokens Impacts LLM Performance" (Kelly Hong, Anton Troynikov, Jeff Huber, 2025년 7월)는 GPT-4.1, Claude 4 (Opus 및 Sonnet), Gemini 2.5, Qwen3를 포함한 18개의 최첨단 (state-of-the-art) 모델들을 평가했습니다.

가장 핵심적인 발견은 직설적이고 보편적이었습니다: 모델들은 "컨텍스트를 균일하게 사용하지 않으며, 대신 입력 길이가 길어질수록 성능이 점점 더 신뢰할 수 없게 된다"는 것이었습니다. 18개 모델 모두 입력이 길어짐에 따라 성능이 저하되었습니다. 일부나 대부분이 아니라, 전부였습니다. 이는 반복되는 단어 시퀀스를 복제하는 것과 같이 아주 쉬운 작업으로 설계된 태스크에서도 동일하게 나타났습니다.

긴 컨텍스트 (long context)에 대한 업계 표준 벤치마크인 '건초더미 속 바늘 찾기 (Needle in a Haystack, NIAH)'는 모델이 정확한 텍스트 조각을 찾을 수 있는지 여부만을 측정하기 때문에, 거의 완벽한 점수를 산출하며 문제를 숨깁니다. Chroma가 더 어려운 작업들 — 동일한 정보가 아닌 의미적으로 관련된 정보로부터 추론하기, 방해 요소 (distractors) 처리하기, 주변 "건초더미"를 다양하게 구성하기 — 을 테스트했을 때, 성능은 불균일하고 예측 불가능하게 떨어졌습니다.

어휘 선택이 중요했습니다. _컨텍스트 부패 (context rot)_는 그동안 혼동되어 왔던 두 가지 개념 사이에 명확한 선을 그었습니다:

• 컨텍스트 윈도우 오버플로 (Context-window overflow) — 모델의 최대 토큰 제한을 초과하는 것. 이는 급격한 절벽과 같습니다.
• 컨텍스트 부패 (Context rot) — 입력의 신호 대 잡음비 (signal-to-noise ratio)가 떨어짐에 따라, 제한에 도달하기 훨씬 전부터 지속적으로 발생하는 성능 저하. 200k 윈도우를 가진 모델이라도 50k 지점에서 성능이 크게 저하될 수 있습니다.

실무자들이 얻은 교훈은 _용량 (capacity)은 잘못된 지표_라는 것이었습니다. 윈도우가 데이터를 담기에 "충분히 크다"는 사실은 모델이 그 데이터를 잘 사용할지 여부에 대해 아무것도 말해주지 않습니다. 중요한 것은 관련 있는 토큰과 관련 없는 토큰의 비율을 높게 유지하는 것이며, 이는 바로 "모두 다 집어넣기 (throw it all in)\

상황이 정리될 때쯤, 빌더(builders)들 사이에서는 대략적인 합의가 형성되었습니다. 긴 컨텍스트 윈도우 (context windows)가 쓸모없다는 것이 아니라, 그것이 마케팅에서 암시하는 것과는 다른 도구라는 점이었습니다: