공개 사항: 저는 에이전트의 도구 출력값을 압축하는(그 외 여러 기능을 수행하는) 오픈 소스 게이트웨이인 Lynkr를 관리하고 있습니다. 따라서 저는 이 사안에 이해관계가 있습니다. 하지만 이 글은 연구에 관한 것이며, 여기에 포함된 모든 수치는 원문 출처를 인용했습니다.

거의 모든 LLM 사용자가 공유하는 직관이 있습니다: 더 많은 컨텍스트(Context) = 더 나은 답변. 백만 토큰 규모의 컨텍스트 윈도우(Context Window)는 하나의 기능으로 마케팅됩니다. 우리는 "혹시 모르니까"라는 생각으로 파일 전체를 붙여넣습니다. 우리의 코딩 에이전트들은 모델이 필요할지도 모른다는 이론 하에 모든 grep 결과, 모든 파일 읽기, 모든 테스트 로그를 축적합니다.

연구 결과에 따르면 이러한 직관은 단순히 틀린 것이 아니라, 거꾸로 되어 있으며, 그 효과의 크기는 당혹스러울 정도입니다.

당신의 구축 방식을 바꿔야 할 결과

가장 명확한 증거는 Hindsight 메모리 시스템(arXiv:2512.12818, ACL 2026 데모)에서 나옵니다. 긴 대화 기록에 대한 질문을 다루는 벤치마크인 LongMemEval에서, 동일한 오픈 소스 20B 모델은 다음과 같은 점수를 기록했습니다:

• 39.0%: 전체 컨텍스트(Full Context) — 모든 것, 전체 기록을 제공했을 때
• 83.6%: 구조화된 메모리 시스템에 의해 선택된 _정제된 슬라이스(Curated Slice)_를 제공했을 때

동일한 모델입니다. 동일한 가용 정보입니다. 차이점은 한 설정은 모델이 모든 것을 읽게 만들었고, 다른 설정은 중요한 것을 선택했다는 점입니다. 차이는 44.6포인트입니다.

상황은 더 불편해집니다. 정제된 컨텍스트를 사용한 이 20B 모델은 동일한 벤치마크에서 60.2%를 기록한 전체 컨텍스트 기반의 GPT-4o를 능가합니다. 모델 크기는 훨씬 작음에도 불구하고, 누군가가 책상을 정리해 주었기 때문에 승리한 것입니다. 저자들이 언급했듯이, 성능을 주도하는 것은 모델의 규모가 아니라 메모리 아키텍처(Memory Architecture)입니다.

하나의 벤치마크, 하나의 논문일까요? 아닙니다. 이는 연쇄적인 결과입니다:

• "Lost in the middle" (Liu et al., 2023) 연구는 이 문제의 형태를 초기에 확립했습니다: 모델은 긴 컨텍스트(Context)의 시작과 끝부분에는 주의를 잘 기울이지만, 중간 부분에는 주의를 잘 기울이지 못합니다. 이는 바로 당신의 에이전트가 가져온 15번째 도구(Tool) 결과값이 위치하는 지점입니다.
• 컨텍스트 부패(Context-rot) 연구 (특히 Chroma의 2025년 보고서)는 추가된 토큰(Token)이 관련이 있는 경우에도 컨텍스트가 커짐에 따라 성능이 저하되며, 방해 요소(Distractor)인 경우 더 빠르게 저하된다는 것을 보여주었습니다.
• 2026년의 연구 흐름은 이제 컨텍스트를 최대화하는 것이 아니라 관리해야 할 자원으로 취급합니다: "에이전트적 컨텍스트 엔지니어링(Agentic Context Engineering)"이 ICLR 2026에 채택되었고, 능동적 컨텍스트 압축(Context Compression) 시스템은 자신의 작업 메모리(Working Memory)를 스스로 가지치기하며 (arXiv:2601.07190), 두 개의 통합 서베이 논문 (arXiv:2512.13564, arXiv:2603.07670)은 메모리를 쓰기-관리-읽기 루프(Write–manage–read loop)로 공식화하며, 여기서 "관리"가 핵심적인 역할을 수행합니다.

마케팅은 "더 큰 윈도우(Bigger window)"를 말했지만, 연구는 "더 나은 사서(Better librarian)"를 말합니다.

왜 더 많은 컨텍스트가 상황을 악화시키는가

모두 잘 문서화된 세 가지 메커니즘이 있습니다:

1. 어텐션(Attention)은 스포트라이트가 아니라 예산입니다. 컨텍스트 내의 모든 토큰은 어텐션 질량(Attention mass)을 차지하기 위해 경쟁합니다. 5만 개의 도구 출력 토큰을 채워 넣으면, 정작 중요한 세 줄의 정보는 49,900개의 노이즈 토큰과 경쟁하게 됩니다. 벤더들이 발표하는 '건더미 속 바늘 찾기(Needle-in-a-haystack)' 벤치마크는 심어진 문자열의 검색(Retrieval) 능력을 테스트하는 것이며, 모델은 이를 잘 수행합니다. 하지만 실제 작업은 컨텍스트에 대한 **추론(Reasoning)**을 요구하며, 이 능력은 훨씬 더 빠르게 저하됩니다.

2. 방해 요소는 단순히 희석하는 것에 그치지 않고, 적극적으로 오도합니다. 컨텍스트 부패(Context-rot) 연구 결과에 따르면, 의미적으로 유사하지만 관련이 없는 콘텐츠는 무작위 채우기(Random filler)보다 더 해롭습니다. 당신의 에이전트 컨텍스트는 이런 것들로 가득 차 있습니다: 편집 중인 파일의 이전 버전, 이미 수정된 버그의 에러 메시지, 폐기된 모듈에서 검색된 grep 결과 등입니다. 각각은 어텐션 헤드(Attention head) 하나 차이로 놓여 있는, 그럴듯해 보이는 오답들입니다.

3. 위치 효과는 턴(turn)이 거듭될수록 누적됩니다. 에이전트는 내용을 추가(append)합니다. 매 턴마다 중요한 초기 정보(작업 지침! 제약 조건!)는 컨텍스트의 중간 부분, 즉 어텐션 데드 존(attention dead zone)으로 밀려나고, 최근의 신호는 상투적인 도구 출력물(boilerplate tool output) 아래에 묻히게 됩니다. 긴 에이전트 세션은 최악의 어텐션 레이아웃(attention layouts)을 구축하는 기계와 같습니다.

코딩 에이전트는 이 세 가지 문제가 동시에 발생하는 병리적인 사례입니다. 이들은 수십 번의 턴에 걸쳐 기계적인 속도로 방대하고, 주의를 분산시키며, 구조적으로 반복되는 컨텍스트(JSON 도구 결과, 파일 덤프, 테스트 로그)를 생성합니다.

연구가 제시하는 대안

기존 문헌에서 성공적인 시스템들은 공통된 형태를 공유합니다. 이들은 모델에게 모든 것을 보여주는 대신, 모델이 무엇을 볼지 결정하는 데 연산(compute)을 사용합니다.

• 포함보다는 선택 (Selection over inclusion). Hindsight의 네 가지 메모리 네트워크(사실 vs 경험 vs 요약 vs 신념)는 검색(retrieval)이 각 질문에 맞는 올바른 종류의 메모리를 가져올 수 있도록 존재합니다. 일반적인 교훈은 다음과 같습니다: 작은 컨텍스트로의 검색(retrieval)이 큰 컨텍스트에 상주하는 것보다 낫습니다.
• 1급 연산으로서의 압축 (Compression as a first-class operation). 능동적 컨텍스트 압축(Active-context-compression) 에이전트는 "작업 세트(working set)를 축소하라"를 도구 호출(tool calls)과 동등한, 에이전트 스스로 수행하는 하나의 액션으로 취급합니다. 해결된 내용은 요약하고, 대체된 내용은 버리며, 활성화된 내용은 유지합니다.
• 구조가 나열보다 낫다 (Structure beats soup). 표 형식(Tabular), 라벨링(labeled), 중복 제거(deduplicated)된 컨텍스트는 동일한 정보의 가공되지 않은 덤프(raw dumps)보다 일관되게 우수한 성능을 보입니다. 모델이 파싱(parsing)이 아닌 콘텐츠 자체에 어텐션(attention)을 쏟을 수 있기 때문입니다.

오늘 바로 적용할 수 있는 방법

연구용 메모리 시스템이 없어도 이점은 얻을 수 있습니다:

1. 컨텍스트(Context)를 자산이 아닌 이자가 붙는 부채로 취급하세요. 윈도우에 남겨두는 모든 도구 결과물은 이후의 모든 턴에서 다시 읽히고(그리고 다시 비용이 청구되며), 매 턴 에이전트를 조금씩 더 멍청하게 만듭니다.
2. 공격적이고 조기에 압축(Compact)하세요. 에이전트의 압축/삭제 메커니즘이 무엇이든(/compact, /clear, 작업당 새로운 세션 등), 품질이 저하되기 전에 사용하세요. 에이전트가 제자리를 맴도는 것을 알아차렸을 때쯤이면, 이미 컨텍스트가 여러 턴 동안 당신에게 해를 끼치고 있었을 것입니다.
3. 세션의 범위를 작업(Task) 단위로 제한하세요. 하나의 작업에는 하나의 세션만 사용하세요. 40턴에 달하는 종합 세션(Omnibus session)은 위치 효과(Position-effect) 연구가 경고하는 바로 그 시나리오입니다.
4. 연구(Research)와 실행(Execution)을 분리하세요. 많이 읽고 적게 보고하는 서브 에이전트(Subagents, 또는 별도의 세션)는 컨텍스트 방화벽 역할을 합니다. 요약본은 넘어가지만, 30k 토큰에 달하는 grep 출력값은 넘어가지 않습니다.
5. 도구 출력물을 컨텍스트에 진입시키기 전에 압축하세요. 테스트 로그, JSON 블롭(JSON blobs), 디렉토리 목록은 모델이 실제로 필요로 하는 정보의 손실 없이 40~90%까지 압축할 수 있습니다. 프록시 레이어(이 부분에서 Lynkr가 하는 역할이 바로 이것입니다)를 사용하든, 하네스(Harness) 설정이나 래퍼 스크립트(Wrapper script)를 사용하든, 어디에서든 이를 수행하세요.

다음에 모델 출시 소식이 컨텍스트 윈도우(Context-window) 크기를 앞세워 나온다면, 훌륭한 사서(Librarian)를 갖춘 20B 모델이 방대한 데이터를 쌓아둔 GPT-4o를 이기는 사례를 기억하세요. 용량(Capacity)이 곧 능력(Capability)은 아닙니다. 큐레이션(Curation)이 능력입니다.

주요 출처: Hindsight (arXiv:2512.12818) · benchmark data · Lost in the Middle (Liu et al.) · Active Context Compression (arXiv:2601.07190) · Memory in the Age of AI Agents — survey (arXiv:2512.13564) · Memory for Autonomous LLM Agents — survey (arXiv:2603.07670)