출처: Drew Breunig Blog
최신 AI 모델들이 1백만 토큰에 달하는 긴 컨텍스트 윈도우를 지원하면서, 많은 개발자들이 흥미로운 꿈을 꾸기 시작했습니다. “이제 필요한 모든 것을 프롬프트에 넣을 수 있다! 문서, 도구, 지시사항까지 모든 것을 컨텍스트에 집어넣고 모델이 알아서 처리하게 하면 된다!”
이러한 기대감은 RAG(Retrieval-Augmented Generation)에 대한 회의론을 불러일으켰고(“가장 좋은 문서를 찾을 필요가 뭐 있어? 다 집어넣으면 되는데!”), MCP(Model Context Protocol)에 대한 열광을 낳았으며(“모든 도구에 연결하면 모델이 모든 일을 할 수 있어!”), AI 에이전트에 대한 기대를 부풀렸습니다.
하지만 현실은 달랐습니다. 긴 프롬프트가 반드시 더 좋은 응답을 만들어내지는 않습니다. 오히려 컨텍스트를 과도하게 채우면 에이전트와 애플리케이션이 예상치 못한 방식으로 실패할 수 있습니다. 컨텍스트가 오염되거나, 산만해지거나, 혼란스러워지거나, 서로 충돌하는 문제들이 발생하죠. 특히 정보 수집, 결과 종합, 행동 조율에 컨텍스트를 의존하는 AI 에이전트에게는 더욱 치명적입니다.
컨텍스트가 실패하는 4가지 방식
1. 컨텍스트 중독 (Context Poisoning): 잘못된 정보의 악순환
컨텍스트 중독은 환각(hallucination)이나 다른 오류가 컨텍스트에 포함되어 반복적으로 참조되는 현상입니다.
구글 딥마인드 팀은 Gemini 2.5 기술 보고서에서 이 문제를 명확히 지적했습니다. 포켓몬 게임을 플레이하는 Gemini 에이전트는 가끔 게임을 하면서 환각을 일으켜 컨텍스트를 오염시켰습니다:
“특히 심각한 형태의 문제는 ‘컨텍스트 중독’으로 나타날 수 있습니다. 컨텍스트의 많은 부분(목표, 요약)이 게임 상태에 대한 잘못된 정보로 ‘중독’되며, 이를 되돌리는 데 매우 오랜 시간이 걸릴 수 있습니다. 결과적으로 모델은 불가능하거나 무관한 목표를 달성하는 데 집착하게 됩니다.”
컨텍스트의 “목표” 섹션이 중독되면, 에이전트는 말이 안 되는 전략을 개발하고 달성할 수 없는 목표를 추구하며 동일한 행동을 반복하게 됩니다.
2. 컨텍스트 산만 (Context Distraction): 학습보다 기록에 의존하기
컨텍스트 산만은 프롬프트가 너무 길어져서 모델이 훈련 중 학습한 내용을 무시하고 컨텍스트에만 과도하게 집중하는 현상입니다.
에이전트 워크플로우 중에 컨텍스트가 성장하면서—모델이 더 많은 정보를 수집하고 기록을 쌓아가면서—이렇게 축적된 컨텍스트는 도움이 되기보다 산만해질 수 있습니다. 포켓몬을 플레이하는 Gemini 에이전트가 이 문제를 명확히 보여주었습니다:
“Gemini 2.5 Pro는 1백만 토큰 이상의 컨텍스트를 지원하지만, 에이전트에서 이를 효과적으로 활용하는 것은 새로운 연구 영역입니다. 이 에이전트 설정에서 컨텍스트가 10만 토큰을 크게 넘어서자, 에이전트는 새로운 계획을 종합하기보다 방대한 기록에서 과거 행동을 반복하는 경향을 보였습니다.”
새로운 전략을 개발하기 위해 훈련된 지식을 사용하는 대신, 에이전트는 광범위한 컨텍스트 기록에서 과거 행동을 반복하는 데 집착했습니다.
더 작은 모델의 경우 산만함 임계점이 훨씬 낮습니다. Databricks 연구에 따르면, Llama 3.1 405b의 경우 약 32,000토큰 근처에서부터 모델 정확도가 떨어지기 시작했고, 더 작은 모델들은 그보다 일찍 성능이 저하되었습니다.
모델들이 컨텍스트 윈도우가 다 차기 훨씬 전부터 오작동을 시작한다면, 초대형 컨텍스트 윈도우의 의미는 무엇일까요? 한마디로 요약과 사실 검색입니다. 이 두 가지를 하지 않는다면, 선택한 모델의 산만함 임계점을 주의해야 합니다.
3. 컨텍스트 혼란 (Context Confusion): 불필요한 정보의 부작용
컨텍스트 혼란은 프롬프트의 불필요한 내용이 모델의 저품질 응답 생성에 사용되는 현상입니다.
한때 모든 사람이 MCP를 출시할 것처럼 보였습니다. 모든 서비스와 도구에 연결된 강력한 모델이 모든 일상적인 작업을 처리해주는 꿈이 손에 닿을 듯했죠. 모든 도구 설명을 프롬프트에 넣고 실행하기만 하면 되는 것처럼 보였습니다.
하지만 통합과 경쟁이 MCP를 늦추지 않는다 해도, 컨텍스트 혼란이 그 역할을 할 것입니다. 도구가 너무 많은 것도 문제가 될 수 있다는 사실이 밝혀졌기 때문입니다.
버클리 함수 호출 리더보드는 모델이 프롬프트에 응답하기 위해 도구를 효과적으로 사용하는 능력을 평가하는 벤치마크입니다. 현재 3번째 버전인 이 리더보드는 모든 모델이 하나 이상의 도구를 제공받았을 때 성능이 더 나빠진다는 것을 보여줍니다. 게다가 버클리 팀은 “제공된 함수들이 모두 관련이 없는 시나리오를 설계했으며… 모델의 출력이 함수 호출을 하지 않기를 기대했습니다.” 그런데도 모든 모델이 가끔 관련 없는 도구를 호출했습니다.
출처: Drew Breunig Blog – 모델 크기가 작을수록 불필요한 도구 호출이 증가
함수 호출 리더보드를 살펴보면, 모델이 작아질수록 문제가 더 심해지는 것을 볼 수 있습니다.
컨텍스트 혼란의 극명한 예는 최근 논문에서 볼 수 있습니다. 이 논문은 46가지 다른 도구를 특징으로 하는 GeoEngine 벤치마크에서 소형 모델 성능을 평가했습니다. 연구팀이 양자화된(압축된) Llama 3.1 8b에게 46개 도구 모두와 함께 쿼리를 주었을 때, 컨텍스트가 16k 컨텍스트 윈도우 내에 충분히 들어갔음에도 실패했습니다. 하지만 19개 도구만 제공했을 때는 성공했습니다.
문제는 프롬프트에 무언가를 넣으면 모델이 그것에 주의를 기울여야 한다는 점입니다. 그것이 무관한 정보나 불필요한 도구 정의일지라도, 모델은 그것을 고려할 것입니다. 대형 모델, 특히 추론 모델들은 불필요한 컨텍스트를 무시하거나 버리는 능력이 향상되고 있지만, 여전히 쓸모없는 정보가 에이전트를 방해하는 경우를 계속 목격하고 있습니다.
4. 컨텍스트 충돌 (Context Clash): 내부 모순의 함정
컨텍스트 충돌은 컨텍스트에 새로운 정보와 도구를 축적하면서 프롬프트의 다른 정보와 충돌하는 현상입니다.
이는 컨텍스트 혼란의 더 문제가 되는 버전입니다. 여기서 나쁜 컨텍스트는 무관한 것이 아니라 프롬프트의 다른 정보와 직접적으로 충돌합니다.
마이크로소프트와 세일즈포스 팀이 최근 논문에서 이를 훌륭하게 문서화했습니다. 팀은 여러 벤치마크에서 프롬프트를 가져와 정보를 여러 프롬프트로 ‘분할’했습니다. 이렇게 생각해보세요: 때로는 ChatGPT나 Claude에 앉아서 엔터를 누르기 전에 모든 필요한 세부사항을 고려하여 단락들을 타이핑할 수 있습니다. 다른 때는 간단한 프롬프트로 시작한 다음, 챗봇의 답변이 만족스럽지 않을 때 추가 세부사항을 더할 수 있습니다. 마이크로소프트/세일즈포스 팀은 벤치마크 프롬프트를 이러한 다단계 교환처럼 보이도록 수정했습니다.
출처: Drew Breunig Blog – 단일 프롬프트 vs 분할된 프롬프트 비교
왼쪽 프롬프트의 모든 정보가 오른쪽의 여러 메시지에 포함되어 있으며, 이는 여러 채팅 라운드에서 진행될 것입니다.
분할된 프롬프트는 평균 39% 하락으로 극적으로 나쁜 결과를 가져왔습니다. 그리고 팀은 다양한 모델을 테스트했는데, OpenAI의 자랑스러운 o3의 점수는 98.1에서 64.1로 떨어졌습니다.
무슨 일이 일어나고 있는 걸까요? 정보가 한 번에 모두 제공되지 않고 단계적으로 수집된다면 왜 모델이 더 나쁜 성능을 보이는 걸까요?
답은 컨텍스트 혼란입니다. 전체 채팅 교환을 포함하는 조립된 컨텍스트에는 모든 정보를 갖기 전에 모델이 도전에 답하려는 초기 시도들이 포함되어 있습니다. 이러한 잘못된 답변들이 컨텍스트에 남아 있어 모델이 최종 답변을 생성할 때 영향을 미칩니다. 팀은 다음과 같이 씁니다:
“LLM들이 종종 초기 턴에서 가정을 하고 성급하게 최종 해결책을 만들려고 시도하며, 이에 과도하게 의존한다는 것을 발견했습니다. 간단히 말해서, LLM이 대화에서 잘못된 방향으로 갈 때, 길을 잃고 회복하지 못한다는 것을 발견했습니다.”
이는 에이전트 빌더들에게 좋지 않은 소식입니다. 에이전트들은 문서, 도구 호출, 그리고 하위 문제를 담당하는 다른 모델들로부터 컨텍스트를 조립합니다. 이 모든 컨텍스트는 다양한 소스에서 가져오기 때문에 서로 불일치할 가능성이 있습니다. 게다가 직접 만들지 않은 MCP 도구에 연결할 때, 그들의 설명과 지시사항이 프롬프트의 나머지 부분과 충돌할 가능성이 더 큽니다.
에이전트에게 특히 치명적인 이유
1백만 토큰 컨텍스트 윈도우의 등장은 변혁적으로 느껴졌습니다. 에이전트가 필요로 할 수 있는 모든 것을 프롬프트에 넣을 수 있는 능력은 모든 문서에 액세스하고, 모든 도구에 연결하며, 완벽한 기억을 유지할 수 있는 초지능 어시스턴트의 비전을 불러일으켰습니다.
하지만 보았듯이, 더 큰 컨텍스트는 새로운 실패 모드를 만들어냅니다. 컨텍스트 중독은 시간이 지나면서 복합되는 오류를 내장합니다. 컨텍스트 산만은 에이전트가 앞으로 나아가기보다 과거 행동을 반복하게 만듭니다. 컨텍스트 혼란은 무관한 도구나 문서 사용으로 이어집니다. 컨텍스트 충돌은 추론을 방해하는 내부 모순을 만듭니다.
이러한 실패는 에이전트가 컨텍스트가 급격히 증가하는 정확한 시나리오에서 작동하기 때문에 에이전트에게 가장 큰 타격을 줍니다. 여러 소스에서 정보를 수집하고, 순차적인 도구 호출을 하며, 다중 턴 추론에 참여하고, 광범위한 기록을 축적하는 과정에서 말이죠.
새로운 접근법이 필요한 시점
RAG가 “죽었다”고 선언하는 사람들이 많지만, 실제로는 긴 컨텍스트와 RAG는 상호 보완적인 관계에 있습니다. 최근 Anthropic의 연구에 따르면, 20만 토큰 이상의 컨텍스트 윈도우를 가져도 RAG는 대규모 지식 베이스에 대해 여전히 더 비용 효과적이고 확장 가능한 솔루션입니다.
MCP 역시 모든 도구를 한 번에 연결하는 것보다는 상황에 맞는 도구만 선별적으로 제공하는 RAG-MCP 같은 접근법이 주목받고 있습니다. 이는 컨텍스트 윈도우 과부하를 피하면서도 필요한 도구에 접근할 수 있게 해줍니다.
결국 중요한 것은 컨텍스트의 크기가 아니라 관리입니다. 긴 컨텍스트는 분명 강력한 도구이지만, 이를 효과적으로 활용하려면 언제, 어떻게 사용할지에 대한 새로운 전략이 필요합니다. 컨텍스트를 동적으로 로딩하고, 필요하지 않은 정보를 격리하며, 충돌하는 정보를 조정하는 기법들이 미래의 AI 에이전트 개발에서 핵심이 될 것입니다.
1백만 토큰의 시대가 가져다준 것은 무한한 가능성이 아니라, 더 정교한 컨텍스트 관리의 필요성이었습니다.
참고자료:
Comments