Six Ways to Fix Context Failures

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

1. context 실패 유형 재확인 및 정보 관리의 중요성

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

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

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

2. context 관리 전술 소개

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

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

3. RAG (Retrieval-Augmented Generation) 📚

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

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

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

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

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

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

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

5. context 격리 (Context Quarantine) 🔔

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

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

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

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

6. context 가지치기 (Context Pruning) ✂️

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

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

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

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

7. context 요약 (Context Summarization) 🦆

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

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

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

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

8. context 오프로딩 (Context Offloading) 📦

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

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

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

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

Anthropic은 context 오프로딩 패턴이 유용한 세 가지 시나리오를 식별.

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

9. Conclusion

context 관리는 agent 구축에서 가장 어려운 부분 중 하나. Karpathy가 말했듯이, LLM이 "context 창을 적절하게 채우도록" programming하고, 도구와 정보를 스마트하게 deployment하며, 정기적인 context 유지 관리를 수행하는 것이 바로 agent 설계자의 핵심 업무.

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

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