컨텍스트 창 포화가 에이전트 정확도를 떨어뜨리는 원인 — 검색(Retrieval) 트레이드오프

저는 제 에이전트들이 추론에 문제가 있다고 6주 동안 확신했습니다.

그들은 서로 모순되는 내용을 말하고, 작업을 반복하며, 아무도 확립하지 않은 사실들을 자신만만하게 인용했습니다. 저는 모델을 업그레이드했고, 프롬프트를 다시 작성했으며, 연구 자료에서 그래프가 미래라고 했기 때문에 지식 그래프(knowledge graph)까지 추가했습니다. 각 수정은 같은 실패들이 되돌아올 때까지 저에게 일주일간의 평온함을 사주었지만요.

전환점은 제가 '왜 제 에이전트들이 틀릴까요?'라는 질문을 멈추고, 다른 질문을 던지기 시작했을 때 찾아왔습니다. 바로 **'컨텍스트를 많이 줄수록 정확도가 떨어지는 이유는 무엇일까?'**였습니다.

그때 저는 답을 찾았고, 그것은 제가 예상했던 답이 아니었습니다.

계속 오진했던 실패 사례

저는 다섯 개의 에이전트(scout, analyst, synthesizer, fact-checker, writer)로 연구 파이프라인을 구축했습니다. 각 에이전트는 이전에 발생한 모든 것의 누적된 컨텍스트를 받았습니다. 출처가 읽히고, 결론이 도출되고, 초안 섹션이 작성되었으며, 중간 도구 출력물까지요. 전체 기록은 튜토리얼에서 보여주는 것처럼 하나의 커지는 덩어리로 전달되었습니다.

첫 번째 징후는 미묘했습니다. analyst가 scout가 이미 확립했던 결론을 새로운 발견인 양 반복하는 것이었습니다. 두 번째 징후는 더 명확했습니다. writer가 출처 자료 어디에서도 나타나지 않는 사실을 자신만만하게 주장했는데, 이 사실은 fact-checker가 이미 검증되지 않은 것으로 표시했던 중간 메모에서 암시된 것이었습니다.

저는 계속 추론 버그(reasoning bug)를 찾고 있었습니다. 하지만 제가 발견한 것은 **컨텍스트 버그(context bug)**였습니다.

Chroma의 2025년 연구는 이미 제가 경험하고 있던 것을 공식화했습니다. 그들은 GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등 18개의 최첨단 모델(frontier models)을 테스트했고, 입력 길이가 늘어날수록 모든 모델의 성능이 저하된다는 것을 발견했습니다. 일부 모델만 그런 것이 아닙니다. 대부분도 아닌 것입니다. 모두가 그렇습니다. 이 현상에는 이제 이름이 붙었습니다: **컨텍스트 부패(context rot)**입니다.

수치는 충격적입니다. Chroma는 입력 길이가 10k에서 100k+ 토큰으로 증가함에 따라 20~50%의 성능 저하를 발견했으며, 일관성 있는 문서가 오히려 무작위로 섞인 문서보다 성능을 더 많이 떨어뜨리는 역설적인 현상을 보였습니다. 추론 능력을 갖춘 모델은 문맥적 방해 요소(contextual distractors)로부터 최대 80%의 정확도 하락을 보였습니다. 그리고 이러한 저하는 절벽처럼 급격한 것이 아니라, 어떤 토큰 제한에 도달하기 훨씬 전부터 시작되는 지속적인 감소입니다. 200K 토큰 창을 가진 모델이라도 50K 토큰에서 상당한 성능 저하를 보일 수 있습니다.

저는 그동안 컨텍스트 창을 단순한 '컨테이너'로 취급해 왔습니다. 용량(Capacity)이 측정 기준이었고, 신호 대 잡음비(Signal-to-noise ratio)가 실제 출력 품질을 결정한다고 생각했습니다.

저의 구축 방식에 변화를 준 연구들

제 임시방편적인 접근 방식을 대체한 학문 분야는 '컨텍스트 엔지니어링(context engineering)'이라는 이름이 있습니다. Google의 ADK 팀은 이를 컨텍스트를 자체 아키텍처, 수명 주기 및 제약 조건을 가진 일급 시스템(first-class system)으로 취급하는 것이라고 설명합니다. 핵심 논지는 컨텍스트가 각 에이전트가 독립적으로 축적하는 가변적인 문자열 버퍼(mutable string buffer)가 아니라, 더 풍부한 상태 기반 시스템(stateful system)에 대한 '컴파일된 뷰(compiled view)'여야 한다는 것입니다.

저는 네 가지 전략을 중심으로 파이프라인을 재구축했습니다.

컨텍스트 창이 아닌 외부 메모리에 쓰기. 에이전트의 컨텍스트에 모든 중간 출력을 축적하는 대신, 파일 시스템이나 구조화된 저장소에 기록합니다. LangChain의 Deep Agents SDK는 에이전트가 접근성을 잃지 않으면서 컨텍스트를 오프로드할 수 있도록 읽기(read), 쓰기(write), 편집(edit), 목록 보기(list), 검색(search)과 같은 파일 시스템 도구를 사용합니다. 컨텍스트 창은 간결하게 유지되고, 메모리는 지속됩니다.

각 에이전트가 실제로 필요로 하는 것만 선택하기. 이전에 발생한 모든 것이 다음에 올 내용에 관련 있는 것은 아닙니다. 다중 에이전트 파이프라인을 위한 컨텍스트 관리 미들웨어인 Sentex는 모든 에이전트의 출력을 공유 문장 그래프(shared sentence graph)에 넣고, 설정된 토큰 예산 내에서 다음 에이전트의 작업과 정확히 관련된 문장만을 검색합니다. 이는 에이전트 경계를 가로질러 의미론적 KNN 엣지(semantic KNN edges)를 탐색하는 방식입니다. 에이전트 3은 에이전트 1과 2의 전체 출력을 가지고 있지 않습니다. 오직 중요한 여덟 개의 문장만을 가지고 있습니다.

압축을 적극적으로 수행하세요. 중간 출력이 쌓이기 전에 요약해야 합니다. LangChain의 Deep Agents는 서브 에이전트를 사용하여 대규모 결과를 단일 압축된 출력으로 요약한 다음, 메인 에이전트가 이를 확인하도록 합니다. 메인 에이전트는 신호를 받고, 노이즈는 뒤에 남겨둡니다.**

역할별로 컨텍스트를 분리하세요. 각 에이전트는 역할에 의해 필터링된 공유 컨텍스트만의 시야를 갖습니다. 연구원은 작가의 초안을 필요로 하지 않습니다. 사실 확인자는 정찰병의 원시 검색 결과를 필요로 하지 않습니다.

대부분의 팀이 놓치는 검색 트레이드오프

제가 몇 달 동안 잘못 알고 있던 부분이 바로 이겁니다. 정확도가 떨어질 때, 본능적으로 검색을 덜 하려고 합니다—더 선택적이 되고, 더 적은 청크를 가져오고, 모델의 컨텍스트 창을 더 신뢰합니다.

그 본능은 절반은 맞고 절반은 위험합니다.

ICML 2025에서 발표된 LaRA 벤치마크는 11개 모델을 2,326개의 테스트 케이스에 걸쳐 평가했으며, RAG와 장문 컨텍스트 중 최적의 선택은 모델 능력, 컨텍스트 길이, 작업 유형 및 검색 특성의 복잡한 상호 작용에 달려 있음을 발견했습니다. RAG나 장문 컨텍스트 LLM 어느 쪽도 만능 해결책이 아닙니다.

수치는 미묘합니다. 32k 컨텍스트 길이에서는 장문 컨텍스트가 RAG보다 평균 정확도가 2.4% 더 높았습니다. 128k 컨텍스트 길이에서는 추세가 역전되어, RAG가 장문 컨텍스트보다 3.68% 우수했습니다.

하지만 진짜 문제는 단순한 검색 실패보다 더 심각합니다. 2025년 EMNLP 논문인

저는 6주 동안 검색(retrieval) 최적화에 매달렸습니다. 문제는 검색이 아니었습니다. 문제는 길이였습니다.

침묵의 살인자: 중간에서 길을 잃다 (Lost in the Middle)

두 번째 실패 양상은 첫 번째 것을 더욱 악화시킵니다. 2026년 방글라어(Bangla) 장문 컨텍스트 연구는 원래 스탠퍼드(Stanford)의 '중간에서 길을 잃음(Lost in the Middle)' 연구가 밝혀낸 바와 같이, LLM은 U자형 성능 곡선을 보이며 입력의 시작 부분(초두 효과/primacy bias)과 끝 부분(최신성 효과/recency bias)에 있는 정보에 우선순위를 두고 중간 부분을 무시하는 경향이 있음을 확인했습니다.

영어의 경우, 중간 위치에서의 정확도 하락은 20~25 퍼센트 포인트에 달합니다. 방글라어에서도 같은 패턴이 나타났습니다. 이 편향은 언어적인 것이 아니라 아키텍처적인 것입니다.

제 파이프라인에서 가장 중요한 발견들—분석가(analyst)의 결론, 사실 확인자(fact-checker)가 표시한 문제점들—은 거의 항상 컨텍스트의 중간에 있었습니다. 작가는 그것들을 보았지만 사용하지 않았습니다. 모델은 양 끝단에 주의를 기울이고 중앙을 훑고 지나갔던 것입니다.

프로덕션 팀들이 실제로 운영하는 방식

멀티 에이전트 시스템을 프로덕션 환경에 배포하는 팀들은 더 긴 컨텍스트 창으로 이 문제를 해결하지 않습니다. 그들은 **아키텍처적인 규율(architectural discipline)**로 해결합니다.

Microsoft의 Azure SRE Agent는 100개 이상의 전문 도구와 50개 이상의 에이전트로 시작했습니다. 하지만 프로덕션에서 실패했습니다—조정 실패, 무한 루프, 낮은 일반화 성능 등이었습니다. 그들은 다섯 개의 광범위한 도구(주로 az 및 kubectl)와 소수의 범용 에이전트, 그리고 공격적인 컨텍스트 관리 방식으로 방향을 틀었습니다. 그 영향은 혁신적이었습니다: 도구 정의에 의해 이전에 소비되던 여유 공간(headroom)을 회복하여 대규모 컨텍스트 압축을 달성했고, 모델이 전체 CLI 표면적(CLI surface area)에 접근할 수 있게 되어 기능이 확장되었으며, LLM이 이미 학습 데이터에서 표준 CLI에 대한 지식을 가지고 있기 때문에 추론 품질이 향상되었습니다.

문제는 도구의 개수가 아니었습니다. 컨텍스트가 부풀려진 것이 문제였습니다.

Slack의 보안 조사 시스템은 수백 건의 추론 요청과 메가바이트 단위의 출력을 아우르는 조사를 처리합니다. 그들의 솔루션은 세 가지 전문화된 컨텍스트 채널로 구성되어 있습니다. 구조화된 작업 기억을 위한 디렉터스 저널(Director's Journal), 신뢰도 점수가 매겨진 발견 사항이 담긴 크리틱 리뷰(Critic's Review), 그리고 통합된 시간 순서 증거를 위한 크리틱 타임라인(Critic's Timeline)입니다. 결정적으로, 그들은 에이전트 호출 간 메시지 기록을 전달하지 않습니다. 크리틱은 개연성 임계값(plausibility thresholds)을 충족하지 못하는 발견 사항 중 약 26%를 필터링합니다.

Lyft의 LangGraph 기반 지원 시스템은 상태 관리와 핸드오프가 흐름에 내장된 라우터 기반 멀티 에이전트 아키텍처를 사용합니다. 이로 인해 에이전트 개발 기간이 약 6개월에서 단 몇 주 만으로 단축되었습니다.

Rippling은 동적 스킬 주입을 위해 Deep Agents 미들웨어를 사용하여 컨텍스트 비대화(context bloat)를 줄이는 세 가지 컨텍스트 엔지니어링 패턴을 개발했습니다.

실제로 효과가 있는 완화 방법 (The Mitigation That Actually Works)

컨텍스트 엔지니어링 분야에는 네 가지 핵심 전략이 있으며, 저는 이 모든 것을 중심으로 제 파이프라인을 재구축했습니다.

첫째, 기준을 명시적으로 정의해야 합니다.

넷째, 암송(recitation) 완화 기법을 사용해야 합니다. EMNLP 논문에서 제시한 간단하고 모델에 구애받지 않는(model-agnostic) 완화 전략은 장문 컨텍스트 작업을 단문 컨텍스트 작업으로 변환하는 것입니다. 이는 모델에게 문제를 해결하려고 시도하기 전에 검색된 증거를 암송하도록 프롬프팅하는 방식입니다. RULER에서 이 기법을 적용한 결과, 이미 강력했던 기준선(baseline) 대비 GPT-4o의 성능이 최대 **4%**까지 일관되게 향상되었습니다.

당신이 수용하고 있는 트레이드오프

컨텍스트 엔지니어링은 공짜가 아닙니다. 단순히 모든 것을 프롬프트에 쏟아붓고 기대하는 것보다 더 많은 노력이 필요합니다.

당신은 각 에이전트가 무엇을 보게 할지 설계하고 있습니다. 올바른 컨텍스트를 적절한 시점에 올바른 에이전트에게 전달해 주는 검색 레이어(retrieval layer)를 구축하고 있습니다. 중간 출력을 요약하는 압축 로직(compaction logic)을 작성하고 있습니다. 단순히 읽기만 하는 것이 아니라, 컨텍스트가 쿼리 가능하도록 만드는 스키마(schema)를 유지 관리하고 있습니다.

또한 당신은 일부 컨텍스트가 손실된다는 점도 수용해야 합니다. 공격적인 압축(Aggressive compression)은 작성자가 분석가가 고려한 모든 세부 사항을 보지 못하게 만듭니다. 단계적 공개(Progressive disclosure)는 CEO가 원본 작업자 출력물(raw worker output) 전체를 볼 수 없게 만듭니다. 당신은 완전성(completeness)과 신호(signal) 사이에서 트레이드오프를 하고 있는 것입니다. 연구에 따르면 컨텍스트 부패(context rot)는 컨텍스트가 일관되더라도 성능을 저하시킵니다. 하지만 이것은 우발적으로가 아니라 의도적으로 해야 하는 트레이드오프입니다.

그리고 당신은 컨텍스트 엔지니어링이 일회성 해결책이 아니라 하나의 학문적 분야(discipline)라는 점도 수용해야 합니다. 5단계 파이프라인에 적합했던 컨텍스트가 15단계 파이프라인에는 적합하지 않을 수 있습니다.

제가 계속 되돌아가는 질문

만약 지금 당신의 에이전트들이 실제로 무엇을 보고 있는지 살펴본다면, 그 컨텍스트 중 얼마나 많은 부분이 부하를 지탱하는 핵심 정보(load-bearing)이고, 얼마나 많은 부분이 부패한 정보(rot)인지 아십니까?

어떤 방식으로 결정했는지 듣고 싶습니다. 파일 시스템 오프로딩(Filesystem offloading), 단계적 공개, 공격적인 압축, 혹은 실제로 측정해 본 적 없는 컨텍스트 예산(context budget)이든 간에—그리고 무엇이 마침내 당신의 시선을 사로잡았는지요?