How Long Contexts Fail

https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html

에이전트의 성공을 위해서는 컨텍스트 관리가 핵심입니다

최신 모델의 컨텍스트 윈도우가 계속 커지고 있으며¹, 많은 모델이 최대 100만 토큰까지 지원하는 상황에서, 긴 컨텍스트 윈도우가 우리가 꿈꾸던 에이전트를 실현시켜줄 것이라는 기대가 커지고 있습니다. 결국 충분히 큰 윈도우가 있다면, 필요한 모든 것—도구, 문서, 지침 등—을 프롬프트에 그냥 넣고 모델이 알아서 처리하게 할 수 있습니다.

긴 컨텍스트는 RAG(검색 기반 생성)에 대한 열정을 약화시켰고(최적의 문서를 찾을 필요 없이 모두 프롬프트에 넣을 수 있으니까!), MCP(멀티 툴 연결) 열풍을 가능하게 했으며(모든 도구에 연결하면 모델이 어떤 작업도 할 수 있다!), 에이전트에 대한 기대를 높였습니다².

하지만 실제로는, 더 긴 컨텍스트가 더 나은 응답을 만들어내지 않습니다. 컨텍스트를 과도하게 넣으면 에이전트와 애플리케이션이 예상치 못한 방식으로 실패할 수 있습니다. 컨텍스트가 오염되거나, 산만해지거나, 혼란스럽거나, 충돌할 수 있습니다. 이는 정보를 수집하고, 결과를 종합하며, 행동을 조정하는 데 컨텍스트에 의존하는 에이전트에게 특히 문제가 됩니다.

컨텍스트가 어떻게 통제 불능이 되는지 살펴보고, 이를 완화하거나 완전히 피할 수 있는 방법을 검토해보겠습니다.

Context Fails

• 컨텍스트 오염: 환각이 컨텍스트에 포함되는 경우
• 컨텍스트 산만: 컨텍스트가 훈련 내용을 압도하는 경우
• 컨텍스트 혼란: 불필요한 컨텍스트가 응답에 영향을 주는 경우
• 컨텍스트 충돌: 컨텍스트의 일부가 서로 상충하는 경우

컨텍스트 오염(Context Poisoning)

컨텍스트 오염은 환각이나 기타 오류가 컨텍스트에 포함되어 반복적으로 참조되는 현상입니다.

Deep Mind 팀은 Gemini 2.5 기술 보고서(저희가 최근에 분석한)에서 컨텍스트 오염을 지적했습니다. 포켓몬 게임을 플레이할 때 Gemini 에이전트가 가끔 환각을 일으켜 컨텍스트를 오염시켰습니다:

특히 심각한 형태의 이 문제는 ‘컨텍스트 오염’으로, 컨텍스트(목표, 요약 등)의 많은 부분이 게임 상태에 대한 잘못된 정보로 ‘오염’되어, 이를 되돌리는 데 매우 오랜 시간이 걸릴 수 있습니다. 그 결과, 모델은 달성할 수 없거나 무의미한 목표를 달성하려고 집착하게 됩니다.

만약 컨텍스트의 “목표” 섹션이 오염된다면, 에이전트는 말도 안 되는 전략을 세우고 달성할 수 없는 목표를 반복적으로 추구하게 됩니다.

컨텍스트 산만(Context Distraction)

컨텍스트 산만은 컨텍스트가 너무 길어져 모델이 훈련 중에 배운 내용을 무시하고 컨텍스트에만 과도하게 집중하는 현상입니다.

에이전트 워크플로우에서 컨텍스트가 점점 길어지면서—모델이 더 많은 정보를 수집하고 히스토리를 쌓으면서—이 누적된 컨텍스트는 도움이 되기보다는 오히려 산만해질 수 있습니다. 포켓몬을 플레이하는 Gemini 에이전트는 이 문제를 명확히 보여줍니다:

Gemini 2.5 Pro는 100만+ 토큰 컨텍스트를 지원하지만, 이를 에이전트에 효과적으로 활용하는 것은 새로운 연구 분야입니다. 이 에이전트 환경에서, 컨텍스트가 10만 토큰을 훨씬 넘어서면서 에이전트가 방대한 히스토리에서 과거 행동을 반복하는 경향을 보이고, 새로운 계획을 종합하는 대신 이를 선호하는 현상이 관찰되었습니다. 이 현상은 일화적이지만, 검색을 위한 긴 컨텍스트와 다단계 생성적 추론을 위한 긴 컨텍스트의 중요한 차이를 보여줍니다.

모델은 새로운 전략을 개발하기 위해 훈련 데이터를 활용하는 대신, 방대한 컨텍스트 히스토리에서 과거 행동을 반복하는 데 집착하게 됩니다.

더 작은 모델의 경우, 산만해지는 한계는 훨씬 낮습니다. Databricks 연구에 따르면 Llama 3.1 405b 모델은 32k 토큰 부근에서 정확도가 떨어지기 시작했고, 더 작은 모델은 더 일찍 하락했습니다.

모델이 컨텍스트 윈도우가 가득 차기 훨씬 전에 오작동하기 시작한다면, 초대형 컨텍스트 윈도우의 의미는 무엇일까요? 간단히 말하자면: 요약³과 사실 검색입니다. 이 두 가지가 아니라면, 선택한 모델의 산만 한계에 주의해야 합니다.

컨텍스트 혼란(Context Confusion)

컨텍스트 혼란은 컨텍스트에 불필요한 내용이 포함되어 모델이 저품질 응답을 생성하는 현상입니다.

한때 모든 사람이 MCP를 출시할 것처럼 보였습니다. 강력한 모델이 모든 서비스와 데이터를 연결해 모든 단순 작업을 처리해줄 것이라는 꿈이 현실에 가까워 보였습니다. 모든 도구 설명을 프롬프트에 넣고 실행하면 된다는 생각이었죠. Claude의 시스템 프롬프트는 대부분 도구 정의나 도구 사용 지침으로 구성되어 있습니다.

하지만 통합과 경쟁이 MCP를 늦추지 않더라도, _컨텍스트 혼란_이 문제를 일으킵니다. 너무 많은 도구가 있으면 문제가 생깁니다.

Berkeley Function-Calling Leaderboard는 모델이 도구를 효과적으로 사용해 프롬프트에 응답하는 능력을 평가하는 벤치마크입니다. 현재 3번째 버전인데, 모든 모델이 하나 이상의 도구를 제공받을 때 성능이 떨어진다는 것을 보여줍니다⁴. 또한 Berkeley 팀은 “제공된 함수 중 어느 것도 관련이 없는 시나리오를 설계했습니다…모델의 출력이 함수 호출이 없어야 한다고 기대합니다.”라고 밝혔습니다. 하지만 모든 모델은 때때로 관련 없는 도구를 호출합니다.

Function-calling 리더보드를 살펴보면, 모델이 작아질수록 문제가 더 심해지는 것을 볼 수 있습니다:

최근 논문에서는 GeoEngine 벤치마크에서 소형 모델의 성능을 평가했는데, 이 벤치마크에는 _46개의 도구_가 등장합니다. 팀이 양자화(압축)된 Llama 3.1 8b 모델에 46개 도구가 모두 포함된 쿼리를 주었더니 실패했지만, 19개 도구만 제공하자 성공했습니다.

문제는: 컨텍스트에 무언가를 넣으면 모델이 반드시 그것을 신경 써야 한다는 것 입니다. 관련 없는 정보나 불필요한 도구 정의일지라도, 모델은 반드시 이를 고려합니다. 대형 모델, 특히 추론 모델은 불필요한 컨텍스트를 무시하거나 버리는 데 점점 더 능숙해지고 있지만, 여전히 쓸모없는 정보가 에이전트를 방해하는 경우가 많습니다. 더 긴 컨텍스트는 더 많은 정보를 넣을 수 있게 해주지만, 이 능력에는 단점이 따릅니다.

컨텍스트 충돌(Context Clash)

컨텍스트 충돌은 컨텍스트에 새로운 정보와 도구가 추가되어 기존 정보와 충돌하는 현상입니다.

이것은 컨텍스트 혼란 의 더 심각한 버전입니다: 여기서 문제의 컨텍스트는 관련 없는 것이 아니라, 프롬프트 내의 다른 정보와 직접적으로 충돌합니다.

Microsoft와 Salesforce 팀은 최근 논문에서 이를 훌륭하게 문서화했습니다. 이 팀은 여러 벤치마크의 프롬프트를 가져와 정보를 여러 프롬프트에 ‘샤딩’했습니다. 예를 들어, 때로는 ChatGPT나 Claude에 입력할 때 모든 필요한 세부 정보를 한 번에 입력하는 경우가 있고, 다른 때는 간단한 프롬프트로 시작한 뒤 챗봇의 답변이 만족스럽지 않으면 추가 정보를 입력하는 경우가 있습니다. Microsoft/Salesforce 팀은 벤치마크 프롬프트를 이런 다단계 대화처럼 수정했습니다:

왼쪽 프롬프트의 모든 정보가 오른쪽의 여러 메시지에 나뉘어 포함되어, 여러 채팅 라운드에서 진행됩니다.

샤딩된 프롬프트는 결과가 극적으로 나빠졌으며, 평균 39% 하락했습니다. 그리고 이 팀은 다양한 모델을 테스트했는데—OpenAI의 유명한 o3 모델의 점수는 98.1에서 64.1로 떨어졌습니다.

무슨 일이 일어난 걸까요? 왜 정보를 단계적으로 수집하면 모델의 성능이 떨어질까요?

답은 컨텍스트 혼란 입니다: 대화 전체를 포함하는 컨텍스트에는 모델이 도전 과제를 완전히 이해하기 전에 시도한 초기 답변이 남아 있습니다. 이 잘못된 답변이 컨텍스트에 남아 모델이 최종 답변을 생성할 때 영향을 미칩니다. 연구팀은 다음과 같이 설명합니다:

LLM은 초기 턴에서 가정을 하고 너무 일찍 최종 솔루션을 생성하려고 시도하며, 이에 과도하게 의존하는 경향이 있습니다. 더 간단히 말하면, LLM이 대화에서 잘못된 방향으로 가면, 길을 잃고 회복하지 못합니다.

이는 에이전트 개발자에게 좋지 않은 소식입니다. 에이전트는 문서, 도구 호출, 하위 문제를 담당하는 다른 모델 등 다양한 소스에서 컨텍스트를 수집합니다. 이렇게 다양한 소스에서 가져온 컨텍스트는 서로 충돌할 가능성이 있습니다. 또한, 직접 만들지 않은 MCP 도구에 연결하면 그 설명과 지침이 프롬프트의 나머지 부분과 충돌할 가능성이 더 높아집니다.

100만 토큰 컨텍스트 윈도우의 등장은 혁신적으로 느껴졌습니다. 에이전트가 필요로 할 모든 것을 프롬프트에 넣을 수 있다는 능력은, 모든 문서에 접근하고, 모든 도구에 연결하며, 완벽한 기억을 유지하는 초지능형 어시스턴트에 대한 비전을 불러일으켰습니다.

하지만 보았듯이, 더 큰 컨텍스트는 새로운 실패 모드를 만듭니다. 컨텍스트 오염은 시간이 지남에 따라 오류가 누적되게 하고, 컨텍스트 산만은 에이전트가 컨텍스트에만 집착해 과거 행동을 반복하게 하며, 컨텍스트 혼란은 관련 없는 도구나 문서 사용을 유발합니다. 컨텍스트 충돌은 내부 모순을 만들어 추론을 방해합니다.

이러한 실패는 에이전트에게 가장 큰 타격을 줍니다. 에이전트는 바로 컨텍스트가 커지는 환경—여러 소스에서 정보를 수집하고, 연속적인 도구 호출을 하고, 다단계 추론을 하며, 방대한 히스토리를 축적하는—에서 작동하기 때문입니다.

다행히도, 해결책이 있습니다! 다음 글에서는 도구를 동적으로 로딩하는 방법부터 컨텍스트 격리(context quarantine)까지, 이러한 문제를 완화하거나 피할 수 있는 기술을 다룰 예정입니다.

후속 글 “How to Fix Your Context”를 읽어보세요