이 글은 대규모 언어 모델(LLM)에서 발생하는 컨텍스트 실패 문제를 해결하기 위한 6가지 핵심 전략을 제시합니다. 컨텍스트 오염, 혼란, 충돌 등 다양한 실패 유형을 설명하고, RAG, 도구 로드아웃, 컨텍스트 격리, 가지치기, 요약, 오프로딩 기법을 통해 효율적인 정보 관리가 중요함을 강조합니다. 궁극적으로 컨텍스트 내 모든 정보가 모델의 응답에 영향을 미치므로, 불필요한 정보를 제거하고 관련성 높은 정보만 유지하는 것이 고품질 응답을 위한 핵심임을 역설합니다.


1. 컨텍스트 실패 유형 재확인 및 정보 관리의 중요성

이 글은 2025년 6월 22일 게시된 이전 글 "긴 컨텍스트가 실패하는 방법"에 이어, 컨텍스트 실패를 완화하거나 완전히 피하는 방법을 다룹니다. 먼저 긴 컨텍스트가 실패할 수 있는 몇 가지 주요 방식을 간략하게 다시 살펴봅니다.

  • 컨텍스트 오염 (Context Poisoning): 환각(Hallucination)이나 다른 오류가 컨텍스트에 유입되어 반복적으로 참조될 때 발생합니다.
  • 컨텍스트 분산 (Context Distraction): 컨텍스트가 너무 길어져 모델이 학습된 지식보다 컨텍스트에 과도하게 집중할 때 발생합니다.
  • 컨텍스트 혼란 (Context Confusion): 컨텍스트 내의 불필요한 정보가 모델에 의해 저품질 응답을 생성하는 데 사용될 때 발생합니다.
  • 컨텍스트 충돌 (Context Clash): 컨텍스트에 새로운 정보나 도구가 축적되어 프롬프트 내의 다른 정보와 충돌할 때 발생합니다.

이 모든 문제는 결국 정보 관리에 관한 것입니다. 컨텍스트 내의 모든 정보는 모델의 응답에 영향을 미치며, 이는 "쓰레기를 넣으면 쓰레기가 나온다(Garbage in, garbage out)"는 오래된 프로그래밍 격언과 일맥상통합니다. 다행히 이러한 문제들을 해결할 수 있는 다양한 방법들이 있습니다.


2. 컨텍스트 관리 전술 소개

컨텍스트 실패를 해결하기 위한 주요 관리 전술들은 다음과 같습니다.

  • RAG (Retrieval-Augmented Generation): LLM이 더 나은 응답을 생성하도록 관련 정보를 선별적으로 추가하는 방식입니다.
  • 도구 로드아웃 (Tool Loadout): 컨텍스트에 추가할 관련 도구 정의만 선택하는 방식입니다.
  • 컨텍스트 격리 (Context Quarantine): 컨텍스트를 자체 전용 스레드에 격리하여 하나 이상의 LLM이 개별적으로 사용하도록 하는 방식입니다.
  • 컨텍스트 가지치기 (Context Pruning): 컨텍스트에서 관련 없거나 불필요한 정보를 제거하는 방식입니다.
  • 컨텍스트 요약 (Context Summarization): 축적된 컨텍스트를 응축된 요약으로 줄이는 방식입니다.
  • 컨텍스트 오프로딩 (Context Offloading): LLM의 컨텍스트 외부에 정보를 저장하는 방식으로, 일반적으로 데이터를 저장하고 관리하는 도구를 통해 이루어집니다.

3. RAG (Retrieval-Augmented Generation) 📚

RAG는 LLM이 더 나은 응답을 생성하도록 관련 정보를 선별적으로 추가하는 기법입니다. RAG에 대해서는 이미 많은 글이 쓰였지만, 여전히 매우 중요한 기술입니다.

최근 Llama 4 Scout가 1,000만 토큰이라는 엄청난 컨텍스트 창을 선보이면서 "RAG는 죽었다"는 논쟁이 다시 불거지기도 했습니다. 하지만 컨텍스트를 잡동사니 서랍처럼 취급하면, 그 잡동사니가 응답에 영향을 미치게 됩니다. 즉, 컨텍스트 창이 아무리 커져도 관련성 없는 정보가 많으면 오히려 응답 품질이 저하될 수 있다는 점을 명심해야 합니다.


4. 도구 로드아웃 (Tool Loadout) 🔫

도구 로드아웃은 주어진 작업에 가장 적합한 도구 정의만 컨텍스트에 추가하는 것을 의미합니다. 이는 게임에서 특정 상황에 맞춰 능력, 무기, 장비를 선택하는 '로드아웃' 개념에서 차용한 것입니다.

가장 간단한 방법은 도구 설명에 RAG를 적용하는 것입니다. Tiantian Gan과 Qiyao Sun은 "RAG MCP" 논문에서 도구 설명을 벡터 데이터베이스에 저장하여 입력 프롬프트에 따라 가장 관련성 높은 도구를 선택하는 방법을 제시했습니다. DeepSeek-v3 모델을 테스트한 결과, 30개 이상의 도구가 있을 때 올바른 도구 선택이 중요해지며, 100개 이상의 도구에서는 모델이 거의 확실히 실패한다는 것을 발견했습니다. RAG 기법을 사용하여 30개 미만의 도구를 선택했을 때 프롬프트가 훨씬 짧아지고 도구 선택 정확도가 최대 3배 향상되었습니다.

"Less is More" 논문에서는 Llama 3.1 8b 모델이 46개의 도구가 주어졌을 때는 벤치마크에 실패했지만, 19개의 도구만 주어졌을 때는 성공했음을 보여주며, 이는 컨텍스트 창 제한이 아닌 컨텍스트 혼란이 문제임을 시사합니다. 이 논문의 연구팀은 LLM 기반 도구 추천기를 사용하여 동적으로 도구를 선택하는 방법을 개발했고, 이를 통해 Llama 3.1 8b의 성능이 44% 향상되었습니다. 또한, 이 방법은 전력 소비를 18%, 속도를 77% 절감하는 부가적인 이점도 제공합니다.

대부분의 에이전트는 소수의 수동으로 선별된 도구만 필요하지만, 기능의 폭이나 통합의 양이 확장되어야 할 때는 항상 로드아웃을 고려해야 합니다.


5. 컨텍스트 격리 (Context Quarantine) 🔔

컨텍스트 격리는 컨텍스트를 자체 전용 스레드에 격리하여 하나 이상의 LLM이 개별적으로 사용하도록 하는 방식입니다. 컨텍스트가 너무 길거나 관련 없는 내용으로 채워지지 않도록 하는 효과적인 방법은 작업을 더 작고 독립적인 작업으로 분할하고, 각 작업에 자체 컨텍스트를 부여하는 것입니다.

Anthropic의 다중 에이전트 연구 시스템에 대한 블로그 게시물은 이 전략의 좋은 예시를 제공합니다. 그들은 "검색의 본질은 압축"이며, 하위 에이전트들이 각자의 컨텍스트 창에서 병렬로 작동하여 질문의 다양한 측면을 동시에 탐색한 후 가장 중요한 토큰을 선임 연구 에이전트에게 압축하여 전달한다고 설명합니다. 이는 정보 수집 및 증류 속도를 높일 뿐만 아니라, 각 컨텍스트가 너무 많은 정보나 특정 프롬프트와 관련 없는 정보를 축적하는 것을 방지하여 더 높은 품질의 결과를 제공합니다.

"우리의 내부 평가에 따르면, 다중 에이전트 연구 시스템은 특히 여러 독립적인 방향을 동시에 추구해야 하는 광범위한 쿼리에 탁월합니다. 우리는 Claude Opus 4를 선임 에이전트로, Claude Sonnet 4를 하위 에이전트로 사용하는 다중 에이전트 시스템이 내부 연구 평가에서 단일 에이전트 Claude Opus 4보다 90.2% 더 나은 성능을 보였습니다."

이 접근 방식은 에이전트 설계자가 자체 전용 로드아웃과 각 도구 활용 방법에 대한 지침을 가진 여러 에이전트 아키타입을 생성할 수 있으므로 도구 로드아웃에도 도움이 됩니다. 에이전트 빌더의 과제는 병렬화에 적합한 독립적인 작업을 찾아 별도의 스레드로 분리하는 것입니다. 여러 에이전트 간에 컨텍스트 공유가 필요한 문제는 이 전술에 적합하지 않습니다.


6. 컨텍스트 가지치기 (Context Pruning) ✂️

컨텍스트 가지치기는 컨텍스트에서 관련 없거나 불필요한 정보를 제거하는 행위입니다. 에이전트는 도구를 실행하고 문서를 조합하면서 컨텍스트를 축적합니다. 때로는 축적된 내용을 평가하고 불필요한 부분을 제거하는 것이 중요합니다. 이는 주 LLM에 맡기거나, 컨텍스트를 검토하고 편집하는 별도의 LLM 기반 도구를 설계할 수도 있습니다.

컨텍스트 가지치기는 ChatGPT 이전, 컨텍스트 길이가 더 큰 병목 현상이었던 자연어 처리(NLP) 분야에서 비교적 오랜 역사를 가지고 있습니다. 현재의 가지치기 방법 중 하나는 "질의응답을 위한 효율적이고 견고한 컨텍스트 가지치기"인 Provence입니다.

Provence는 빠르고 정확하며 사용하기 쉽고 비교적 작습니다(1.75GB). 몇 줄의 코드로 호출할 수 있습니다. 예를 들어, 캘리포니아 알라메다의 위키피디아 항목을 질문에 따라 95%까지 줄여 관련성 높은 부분만 남기는 데 성공했습니다.

이러한 가지치기 함수를 사용하여 문서나 전체 컨텍스트를 정리할 수 있습니다. 또한, 이 패턴은 컨텍스트의 구조화된 버전을 딕셔너리나 다른 형태로 유지하여 모든 LLM 호출 전에 컴파일된 문자열로 조립하는 강력한 근거가 됩니다. 이 구조는 가지치기 시 유용하며, 주요 지침과 목표는 보존하면서 문서나 기록 섹션은 가지치기하거나 요약할 수 있도록 합니다.


7. 컨텍스트 요약 (Context Summarization) 🦆

컨텍스트 요약은 축적된 컨텍스트를 응축된 요약으로 줄이는 행위입니다. 이 기법은 원래 더 작은 컨텍스트 창을 다루기 위한 도구로 처음 등장했습니다. 채팅 세션이 최대 컨텍스트 길이에 가까워지면 요약이 생성되고 새 스레드가 시작되는 방식이었습니다. 챗봇 사용자들은 ChatGPT나 Claude에서 수동으로 요약을 요청하고 새 세션에 붙여넣곤 했습니다.

그러나 컨텍스트 창이 증가하면서 에이전트 빌더들은 요약이 전체 컨텍스트 제한을 유지하는 것 이상의 이점이 있다는 것을 발견했습니다. 컨텍스트가 길어질수록 모델이 학습된 지식에 덜 의존하고 산만해지는 컨텍스트 분산 현상이 발생합니다. 포켓몬을 플레이하는 Gemini 에이전트 팀은 10만 토큰을 넘어서면 이러한 행동이 유발된다는 것을 발견했습니다.

"Gemini 2.5 Pro는 100만 개 이상의 토큰 컨텍스트를 지원하지만, 에이전트에 효과적으로 사용하는 것은 새로운 연구 분야를 제시합니다. 이 에이전트 설정에서 컨텍스트가 10만 토큰을 훨씬 넘어서면서 에이전트가 새로운 계획을 합성하기보다는 방대한 기록에서 행동을 반복하는 경향을 보였습니다. 이 현상은 일화적이지만, 검색을 위한 긴 컨텍스트와 다단계 생성 추론을 위한 긴 컨텍스트 사이의 중요한 차이점을 강조합니다."

컨텍스트를 요약하는 것은 쉽지만, 특정 에이전트에 완벽하게 적용하기는 어렵습니다. 어떤 정보를 보존해야 하는지 파악하고, 이를 LLM 기반 압축 단계에 상세히 지시하는 것이 에이전트 빌더에게 중요합니다. 이 기능을 자체 LLM 기반 단계 또는 앱으로 분리하여 평가 데이터를 수집하고 이 작업을 직접 최적화할 수 있도록 하는 것이 좋습니다.


8. 컨텍스트 오프로딩 (Context Offloading) 📦

컨텍스트 오프로딩은 LLM의 컨텍스트 외부에 정보를 저장하는 행위로, 일반적으로 데이터를 저장하고 관리하는 도구를 통해 이루어집니다. 이 방법은 너무나 간단해서 효과가 있을지 믿기지 않을 정도입니다.

Anthropic은 "think" 도구에 대한 좋은 설명을 제공하는데, 이는 기본적으로 스크래치패드와 같습니다.

" 'think' 도구를 통해 우리는 Claude에게 최종 답변에 도달하는 과정의 일부로 추가적인 사고 단계(자체 지정된 공간 포함)를 포함할 수 있는 능력을 부여하고 있습니다... 이는 긴 도구 호출 체인을 수행하거나 사용자와의 긴 다단계 대화에서 특히 유용합니다."

이 도구의 이름이 scratchpad였다면 그 기능을 즉시 알 수 있었을 것입니다. 이는 모델이 컨텍스트를 흐리지 않으면서 나중에 참조할 수 있는 메모와 진행 상황을 기록하는 공간입니다. Anthropic은 "think" 도구를 도메인별 프롬프트와 결합하면 전문 에이전트의 벤치마크에서 최대 54%의 상당한 성능 향상을 가져온다고 보여줍니다.

Anthropic은 컨텍스트 오프로딩 패턴이 유용한 세 가지 시나리오를 식별했습니다.

  1. 도구 출력 분석: Claude가 행동하기 전에 이전 도구 호출의 출력을 신중하게 처리하고 접근 방식을 되돌려야 할 수 있을 때.
  2. 정책 중심 환경: Claude가 상세한 지침을 따르고 규정 준수를 확인해야 할 때.
  3. 순차적 의사 결정: 각 행동이 이전 행동을 기반으로 하며 실수가 큰 비용을 초래할 때 (종종 다단계 도메인에서 발견됨).

9. 마무리

컨텍스트 관리는 에이전트 구축에서 가장 어려운 부분 중 하나입니다. Karpathy가 말했듯이, LLM이 "컨텍스트 창을 적절하게 채우도록" 프로그래밍하고, 도구와 정보를 스마트하게 배포하며, 정기적인 컨텍스트 유지 관리를 수행하는 것이 바로 에이전트 설계자의 핵심 업무입니다.

위에서 언급된 모든 전술의 핵심 통찰은 컨텍스트는 공짜가 아니라는 것입니다. 컨텍스트 내의 모든 토큰은 모델의 행동에 좋든 나쁘든 영향을 미칩니다. 최신 LLM의 거대한 컨텍스트 창은 강력한 기능이지만, 정보 관리에 소홀해도 된다는 변명이 될 수는 없습니다.

다음 에이전트를 구축하거나 기존 에이전트를 최적화할 때, 스스로에게 질문해 보세요: "이 컨텍스트에 있는 모든 것이 제 역할을 하고 있는가?" 그렇지 않다면, 이제 이를 해결할 수 있는 여섯 가지 방법을 알게 되었습니다. 🚀

Related writing

Related writing

HarvestAIKorean

에이전트가 ‘코딩’하고, 연구가 ‘루프’를 돌기 시작한 시대: 안드레이 카파시 대담 요약

안드레이 카파시는 최근 몇 달 사이 코딩 에이전트의 도약으로 인해, 사람이 직접 코드를 치기보다 “에이전트에게 의도를 전달하는 일”이 핵심이 됐다고 말합니다. 그는 이 흐름이 오토리서치(AutoResearch)처럼 “실험–학습–최적화”를 사람이 거의 개입하지 않고 굴리는 자율 연구 루프로...

Mar 21, 2026Read more
HarvestAIKorean

Claude 코드 서브 에이전트 vs 에이전트 팀: 무엇이 다를까요?

이 영상은 Shaw Talebi가 Claude 코드의 서브 에이전트와 에이전트 팀 기능을 자세히 설명하고, 실제 작업에 이 두 접근 방식을 비교하는 실험 결과를 공유합니다. 영상은 Claude 코드의 기본 개념부터 시작하여 AI 에이전트가 직면하는 문맥 처리의 한계, 그리고 이를 극복하기...

Mar 16, 2026Read more
HarvestAIKorean

'SaaS는 죽었다' 월 10억 SaaS 창업가의 경고, 알렉스 베커(Alex Becker) 요약

이 영상은 'SaaS는 죽었다'고 경고하는 월 10억 매출의 SaaS 창업가, 알렉스 베커의 인사이트를 담고 있습니다. AI 시대에 코딩 장벽이 낮아지면서 SaaS 시장의 변화를 예측하고, 기존 SaaS 모델의 위기와 미래 지향적인 사업 구조를 제시합니다. 특히, 기업들이 왜 거대한 올인원...

Mar 15, 2026Read more