컨텍스트를 추가할수록 에이전트가 멍청해지는 이유 — '배출 정책 없는 캐시'의 함정

무제한에 가까운 컨텍스트 윈도우가 주는 착각, 그리고 비용과 성능을 동시에 갉아먹는 '브루트 포스' 주입의 위험성을 분석합니다.

최근 기업용 AI 프로젝트들을 지켜보면서 참 안타까운 패턴을 많이 봤어요. 야심 차게 에이전트를 구축했는데, 정작 실전에서는 갈수록 엉뚱한 소리를 하거나 중요한 지침을 까먹는 경우가 많거든요. 실제로 많은 기업용 AI 사례에서 다단계 추론 과정 중 발생하는 컨텍스트 드리프트(Context Drift)나 메모리 손실이 성능 저하의 주요 원인으로 지목되곤 합니다 [7]. 많은 개발자가 “정보가 부족해서 그렇겠지”라고 생각하며 계속해서 컨텍스트를 쑤셔 넣지만, 사실 그게 독이 되는 경우가 많습니다.

여기서 우리가 깨달아야 할 핵심이 하나 있어요. LLM의 컨텍스트 윈도우는 단순히 데이터를 담아두는 저장소가 아니라, ‘배출 정책(Eviction Policy)이 없는 캐시’와 같다는 점이에요. 무분별하게 정보를 추가하는 건 결국 추론 성능 저하와 비용 상승이라는 ‘데스 스파이럴’로 가는 지름길입니다.

컨텍스트 윈도우의 환상: 1,000만 토큰이면 충분할까?

처음 LLM을 접했을 때만 해도 컨텍스트 윈도우는 정말 좁았죠. 2018년쯤엔 수백 토큰 수준이었는데, 2024년에는 100만 토큰을 넘어 최근 Llama 4 같은 모델은 무려 1,000만 토큰 시대에 진입했습니다 [2]. 이제는 책 몇 권, 아니 도서관 수준의 데이터를 한 번에 넣을 수 있게 된 거예요.

그런데 여기서 많은 분이 착각을 합니다. “윈도우가 이렇게 크니까 그냥 다 넣으면 되겠네?”라고 생각하는 거죠. 하지만 윈도우가 커진다고 해서 모델의 ‘지능’이나 ‘추출 정확도’가 정비례해서 올라가는 건 아닙니다. 오히려 너무 많은 텍스트를 한 번에 고려하게 되면 생성 속도는 느려지고, 비용은 치솟으며, 정작 필요한 정보를 정확히 뽑아내는 능력은 떨어질 수 있어요 [2].

“Having the option of long context windows is critical, but it may not make sense to use the entire window by default.” [2]

(긴 컨텍스트 윈도우 옵션이 있는 것은 중요하지만, 기본적으로 윈도우 전체를 사용하는 것이 항상 합리적인 것은 아닙니다.)

결국 단순히 윈도우가 크다고 해서 모든 정보를 다 밀어 넣는 ‘Stuff the window’ 방식은 한계가 명확합니다.

왜 컨텍스트를 추가할수록 성능이 떨어지는가?

그럼 정보를 더 줬는데 왜 모델이 더 멍청해질까요? 저는 이걸 ‘배출 정책이 없는 캐시’라는 관점에서 설명하고 싶어요. 일반적인 컴퓨터 캐시는 공간이 꽉 차면 오래된 데이터나 덜 중요한 데이터를 버리는 ‘배출 정책(Eviction Policy)’이 있죠. 하지만 LLM의 컨텍스트 윈도우는 우리가 명시적으로 관리하지 않는 한, 들어온 모든 토큰을 붙잡고 있습니다.

문제는 LLM의 핵심 메커니즘인 ‘어텐션(Attention)’에 있어요. 불필요한 정보(Noise)가 섞여 들어오면, 모델이 정말 집중해야 할 핵심 정보에 쏟아야 할 어텐션이 분산됩니다. 수만 토큰이 넘어가는 시점부터 성능이 저하되는 경향이 나타나는 이유가 바로 이거예요 [6].

결국 개발자는 정돈되지 않은 데이터 더미 위에서 매번 재계산 비용을 지불하고 있는 셈입니다.

“Your context window is a cache with no eviction policy — and you’re paying to recompute over your own mess.” [1]

(당신의 컨텍스트 윈도우는 배출 정책이 없는 캐시와 같으며, 당신은 스스로 만든 엉망진창인 데이터 위에서 재계산 비용을 지불하고 있습니다.)

안티패턴: ‘일단 다 집어넣기’와 Naive RAG의 함정

실무에서 가장 흔히 보는 안티패턴이 “에이전트가 실수하면 지침을 추가한다”는 전략이에요. “아, 이 부분에서 실수하네? 그럼 프롬프트에 ‘절대로 ~하지 마세요’라는 문구를 하나 더 넣자.” 이렇게 계속 덧붙이다 보면 프롬프트는 점점 비대해지고, 모델은 서로 충돌하는 지침 사이에서 혼란을 겪게 됩니다.

또 하나 위험한 게 ‘Naive RAG’입니다. 벡터 스토어에서 유사도 기반으로 상위 K개의 문서를 가져와서 그대로 컨텍스트에 쏟아붓는 방식이죠. 정교한 필터링이나 메타데이터 관리 없이 단순 텍스트 덩어리로 윈도우를 채우는 건 사실상 ‘브루트 포스’ 주입에 불과합니다. 이런 방식은 결국 막다른 길로 이어질 수밖에 없어요 [3].

잘못된 예시를 코드로 보면 이런 식일 겁니다.

# ❌ 안티패턴: 필터링 없이 무조건 다 집어넣는 Naive RAG 방식
def generate_response(user_query, vector_db):
    # 단순 유사도 기반으로 20개의 청크를 가져와 모두 주입 (Noise 증가)
    docs = vector_db.similarity_search(user_query, k=20) 
    context = "\n".join([doc.page_content for doc in docs])
    
    # 지침이 계속 추가되어 비대해진 프롬프트
    prompt = f"""
    당신은 전문 어시스턴트입니다. 
    지침 1: 친절하게 답하세요.
    지침 2: 전문 용어를 사용하세요.
    지침 3: (최근 추가) 답변은 반드시 3문장 이내로 하세요.
    지침 4: (최근 추가) 하지만 상세한 설명이 필요하면 길게 쓰세요. # 서로 충돌하는 지침
    
    컨텍스트: {context}
    질문: {user_query}
    """
    return llm.call(prompt)

위 코드처럼 무작정 k값을 높이거나 충돌하는 지침을 계속 추가하는 것은 모델의 추론 능력을 갉아먹는 행위입니다.

지속 가능한 에이전트를 위한 컨텍스트 엔지니어링 전략

그렇다면 어떻게 해야 할까요? 핵심은 ‘주입’이 아니라 ‘관리’입니다. 제가 추천하는 전략은 크게 세 가지예요.

첫째, RAG와 롱 컨텍스트의 하이브리드 운용입니다. 수만 페이지의 기업 지식 베이스는 RAG로 필요한 부분만 선택적으로 검색하고, 그렇게 추려진 개별 문서나 짧은 대화 맥락을 추론할 때만 롱 컨텍스트 모델의 능력을 활용하는 거죠 [3].

둘째, KV 캐시 배출(Eviction) 전략의 도입입니다. 모든 토큰을 다 들고 있는 게 아니라, 중요도가 낮은 토큰을 제거하는 프레임워크를 사용하는 거예요. 예를 들어 NACL 같은 프레임워크는 필수 정보는 유지하면서 중복 데이터를 제거해 모델의 강건성을 높여줍니다 [4].

셋째, 액티브 메타데이터(Active Metadata) 활용입니다. 단순히 텍스트만 넣는 게 아니라, 이 정보가 언제 생성되었는지, 신뢰도는 어느 정도인지 등의 메타데이터를 통해 입력 정보를 제어하는 레이어를 두는 것입니다 [3].

이를 구현하기 위한 더 나은 구조의 예시는 다음과 같습니다.

# ✅ 개선된 컨텍스트 관리 전략 (Conceptual Config)
context_strategy:
  retrieval:
    method: "hybrid_search" # 벡터 + 키워드 검색으로 정확도 향상
    top_k: 5 # 무조건 많이보다 '정확한' 소수 선택
    reranking: true # 검색 결과 재정렬을 통해 노이즈 제거
  
  eviction_policy:
    type: "importance_based" # NACL 등 중요도 기반 배출 적용 (출처: aclanthology.org⁴)
    max_kv_cache_size: "20%" # 핵심 토큰만 남기고 메모리 최적화
    
  governance:
    active_metadata:
      filter_stale_data: true # 오래된 정보는 컨텍스트에서 제외
      priority_weight: 
        system_instruction: 1.0 # 시스템 지침 최우선
        retrieved_doc: 0.7 # 검색 문서 차순위

이런 식으로 ‘무엇을 넣을까’보다 ‘무엇을 버릴까’를 고민하는 설계가 필요합니다.

짚고 넘어갈 한계와 주의점

물론 “모델이 계속 발전하면 결국 RAG 없이 다 넣는 게 정답 아니냐”는 의견이 있을 수 있습니다 [2, 3]. 이론적으로는 가능하겠지만, 실제 운영 환경에서는 비용과 지연 시간(Latency)이라는 현실적인 벽이 있습니다.

또한, KV 캐시 배출 전략이 구현 복잡도를 높이고, 자칫 잘못 설정하면 정말 중요한 핵심 정보를 유실시킬 위험이 있다는 점도 주의해야 합니다 [5]. 결국 정답은 ‘무조건적인 자동화’가 아니라, 도메인에 맞는 적절한 거버넌스를 구축하는 것입니다.

핵심 요약

• 컨텍스트 윈도우 크기는 ‘용량’일 뿐, 그것이 곧 모델의 ‘지능’을 의미하지는 않습니다.
• 에이전트가 멍청해지는 건 정보가 부족해서가 아니라, ‘정보의 무질서’와 노이즈 때문인 경우가 많습니다.
• 무조건 정보를 추가하기보다, 무엇을 버릴 것인가(Eviction)에 집중하는 것이 진짜 엔지니어링입니다.
• RAG와 롱 컨텍스트는 서로 대체하는 관계가 아니라, 상호보완적으로 설계해야 합니다.
• 입력 단계에서 메타데이터를 통해 정보를 제어하는 거버넌스 체계가 최종 출력 퀄리티를 결정합니다.

사실 저도 예전에는 에이전트가 답을 못 하면 프롬프트를 더 길게 쓰고 예시를 더 많이 넣는 게 정답이라고 생각했어요. 하지만 경험해 보니, 불필요한 예시 하나를 걷어내는 것이 열 가지 지침을 추가하는 것보다 훨씬 효과적이더라고요. 결국 친절한 가이드란 ‘더 많은 데이터’를 주는 것이 아니라, ‘정확히 필요한 데이터’만 남겨주는 것임을 깨달았습니다.

---

참고 자료 (References)

1. [ai.plainenglish.io] I kept adding context to fix my agent. It kept getting worse. — https://ai.plainenglish.io/i-kept-adding-context-to-fix-my-agent-it-kept-getting-worse-c4e697ae9d05?source=rss——artificial_intelligence-5 2. [meibel.ai] Understanding the Impact of Increasing LLM Context Windows — https://www.meibel.ai/post/understanding-the-impact-of-increasing-llm-context-windows 3. [atlan.com] LLM Context Window Limitations in 2026 – Atlan — https://atlan.com/know/llm-context-window-limitations 4. [aclanthology.org] A General and Effective KV Cache Eviction Framework for LLMs at Inference Time — https://aclanthology.org/2024.acl-long.428.pdf 5. [arxiv.org] Reformulating KV Cache Eviction Problem for Long-Context LLM Inference — https://arxiv.org/html/2605.07234v1 6. [redis.io] LLM context windows: what they are & how they work – Redis — https://redis.io/blog/llm-context-windows 7. [zylos.ai] LLM Context Window Management and Long-Context Strategies 2026 — https://zylos.ai/research/2026-01-19-llm-context-management/

관련 글 추천

• https://infobuza.com/2026/06/05/20260605-kz8993/
• https://infobuza.com/2026/06/05/20260605-9n7n98/

FAQ

컨텍스트 윈도우가 커지면 모델의 지능이나 추출 정확도도 함께 올라가나요?

아니요, 윈도우가 커진다고 해서 모델의 지능이나 추출 정확도가 정비례해서 올라가는 것은 아닙니다. 오히려 너무 많은 텍스트를 한 번에 넣으면 생성 속도가 느려지고 비용이 상승하며, 필요한 정보를 정확히 뽑아내는 능력이 떨어질 수 있습니다.

정보를 더 많이 제공했음에도 에이전트의 성능이 떨어지는 이유는 무엇인가요?

LLM의 컨텍스트 윈도우는 '배출 정책이 없는 캐시'와 같아서 모든 토큰을 붙잡고 있기 때문입니다. 이로 인해 불필요한 정보(노이즈)가 섞이면 모델이 핵심 정보에 집중해야 할 어텐션(Attention)이 분산되어 성능 저하가 발생합니다.

본문에서 언급한 'Naive RAG'의 문제점은 무엇인가요?

정교한 필터링이나 메타데이터 관리 없이, 단순히 유사도 기반으로 상위 K개의 문서를 가져와 컨텍스트에 그대로 쏟아붓는 방식입니다. 이는 사실상 '브루트 포스' 주입에 불과하며 결국 성능 저하로 이어지는 안티패턴입니다.

지속 가능한 에이전트를 위해 추천하는 컨텍스트 엔지니어링 전략 세 가지는 무엇인가요?

첫째, RAG로 필요한 부분만 검색하고 추론 시에만 롱 컨텍스트를 활용하는 하이브리드 운용, 둘째, 중요도가 낮은 토큰을 제거하는 KV 캐시 배출(Eviction) 전략 도입, 셋째, 정보의 생성 시점이나 신뢰도 등을 제어하는 액티브 메타데이터 활용입니다.

롱 컨텍스트 모델이 발전하면 결국 RAG 없이 모든 데이터를 다 넣는 것이 정답이 될까요?

이론적으로는 가능할 수 있으나, 실제 운영 환경에서는 비용과 지연 시간(Latency)이라는 현실적인 제약이 있습니다. 따라서 무조건적인 자동화보다는 도메인에 맞는 적절한 거버넌스를 구축하는 것이 중요합니다.