Elasticsearch로 에이전틱 메모리 관리하기

Agent Builder는 이제 이제 정식 버전으로 이용 가능합니다. Elastic Cloud 체험판으로 시작하고, 여기에서 Agent Builder 문서를 확인 해 보세요.

새롭게 부상하는 컨텍스트 엔지니어링 분야에서는 AI 에이전트에 적절한 정보를 적시에 제공하는 것이 매우 중요합니다. 컨텍스트 엔지니어링의 가장 중요한 측면 중 하나는 AI의 메모리 관리입니다. 인간과 마찬가지로 AI 시스템도 정보를 기억하기 위해 단기 메모리와 장기 메모리에 모두 의존합니다. 대규모 언어 모델(LLM) 에이전트가 논리적인 대화를 이어가고 사용자 선호도를 기억하며 이전 결과나 응답을 기반으로 구축하려면 효과적인 메모리 메커니즘을 갖춰야 합니다.

결국 컨텍스트의 모든 요소가 AI의 응답에 영향을 미칩니다. 쓰레기를 넣으면 쓰레기가 나온다(Garbage in, garbage out)는 말이 딱 들어맞습니다.

이 글에서는 AI 에이전트에 단기 메모리와 장기 메모리가 어떤 의미를 갖는지 설명합니다. 특히 다음과 같은 내용을 다룹니다.

• 단기 메모리와 장기 메모리의 차이
• Elasticsearch와 같은 벡터 데이터베이스를 사용하는 Retrieval-Augmented Generation(RAG) 기술과의 관계 및 신중한 메모리 관리가 필요한 이유
• 컨텍스트 오버플로 및 컨텍스트 오염 등 메모리 관리 소홀의 위험성
• 컨텍스트 가지치기, 요약, 관련 정보만 검색 등 에이전트의 메모리를 유용하면서도 안전하게 유지하는 모범 사례
• Elasticsearch를 사용하여 에이전트가 혼동 없이 협업할 수 있도록 멀티 에이전트 시스템에서 메모리를 공유 및 전파하는 방법

AI 에이전트의 단기 메모리와 장기 메모리 비교

AI 에이전트의 단기 메모리는 일반적으로 즉각적인 대화 컨텍스트 또는 상태, 즉 현재 채팅 기록이나 활성 세션의 최근 메시지를 의미합니다. 여기에는 사용자의 최근 쿼리와 최근 주고받은 대화가 포함됩니다. 이는 사람이 대화 중에 기억하는 정보와 매우 유사합니다.

AI 프레임워크는 종종 이러한 임시 메모리를 에이전트 상태의 일부로 유지합니다(예: LangGraph의 이 예시처럼 체크포인터를 사용하여 대화 상태를 저장하는 방식). 단기 메모리는 세션 범위로 제한됩니다. 즉, 단일 대화 또는 작업 내에 존재하며 해당 세션이 종료되면 명시적으로 다른 곳에 저장하지 않는 한 재설정되거나 지워집니다. 세션에 종속된 단기 메모리의 예로는 ChatGPT에서 제공하는 임시 채팅 기능을 들 수 있습니다.

반면 장기 메모리는 여러 대화나 세션에 걸쳐 지속되는 정보를 말합니다. 이는 에이전트가 시간이 지남에 따라 보유하게 되는 지식, 이전에 학습한 사실, 사용자 선호도 또는 영구적으로 기억하도록 지시한 모든 데이터를 말합니다.

장기 메모리는 보통 즉각적인 컨텍스트 윈도우 밖에 있는 파일이나 벡터 데이터베이스와 같은 외부 소스에서 저장하고 가져오는 방식으로 구현됩니다. 단기 채팅 기록과 달리 장기 메모리는 모든 프롬프트에 자동으로 포함되지 않습니다. 대신 주어진 시나리오에 따라 에이전트가 관련 도구가 호출될 때 이를 불러오거나 검색해야 합니다. 실제로 장기 메모리에는 사용자의 프로필 정보, 에이전트가 작성한 이전 답변이나 분석, 에이전트가 쿼리할 수 있는 지식 기반 등이 포함될 수 있습니다.

예를 들어 여행 플래너 에이전트가 있다면 단기 메모리는 현재 여행 문의(날짜, 목적지, 예산) 및 해당 채팅에서의 후속 질문의 세부 사항을 포함할 것입니다. 반면에 장기 메모리는 사용자의 일반적인 여행 선호도, 과거 여정 및 이전 세션에서 공유된 기타 사실을 저장할 수 있습니다. 사용자가 나중에 다시 방문했을 때, 에이전트는 이러한 장기 데이터 저장소(예: 사용자는 해변과 산을 좋아하고, 평균 예산은 10만 루피이며, 방문하고 싶은 버킷리스트가 있고, 어린이 친화적인 명소보다는 역사와 문화 체험을 선호함)를 활용하여 매번 사용자에게 다시 묻지 않고 맞춤형 서비스를 제공할 수 있습니다.

단기 메모리(채팅 기록)는 즉각적인 컨텍스트와 연속성을 제공하는 반면, 장기 메모리는 에이전트가 필요할 때 활용할 수 있는 더 넓은 컨텍스트를 제공합니다. 대부분의 고급 AI 에이전트 프레임워크는 이 두 가지를 모두 지원합니다. 최근 대화를 추적하여 컨텍스트를 유지관리합니다. 그리고 장기 저장소에서 정보를 조회하거나 해당 저장소에 저장하는 메커니즘을 제공합니다. 단기 메모리를 관리하여 컨텍스트 윈도우 내에서 유지되도록 하고, 장기 메모리를 관리하여 에이전트가 이전 상호작용과 페르소나를 기반으로 답변을 확립할 수 있도록 합니다.

컨텍스트 엔지니어링에서 메모리와 RAG

실제로 AI 에이전트에 유용한 장기 메모리를 부여하는 방법은 무엇일까요?

장기 메모리를 위한 대표적인 접근 방식 중 하나는 시맨틱 메모리로, retrieval-augmented generation(RAG)을 통해 구현되는 경우가 많습니다. 이는 LLM을 Elasticsearch와 같은 외부 지식 저장소 또는 벡터 지원 데이터 저장소와 결합하는 것을 의미합니다. LLM은 프롬프트나 기본 제공 학습에 포함된 정보 이상의 정보가 필요할 때 Elasticsearch를 대상으로 시맨틱 검색을 수행하고 가장 관련성이 높은 결과를 컨텍스트로 프롬프트에 삽입합니다. 이렇게 하면 모델의 유효 컨텍스트에 최근 대화(단기 메모리)뿐만 아니라 즉석에서 가져온 관련 장기 사실도 포함됩니다. 그런 다음 LLM은 자체 추론과 검색된 정보를 기반으로 답변을 구성하여 단기 메모리와 장기 메모리를 효과적으로 결합해 보다 정확하고 컨텍스트에 맞는 응답을 생성합니다.

Elasticsearch를 사용하여 AI 에이전트의 장기 메모리를 구현할 수 있습니다. 다음은 Elasticsearch에서 컨텍스트 정보를 검색하여 장기 메모리에 저장하는 방법에 대한 개략적인 예시입니다.

이렇게 하면 에이전트가 제한된 프롬프트에 모든 것을 저장하는 대신 관련 데이터를 검색하여 '기억'하기 때문에 다른 위험을 초래할 수 있습니다.

Elasticsearch 또는 벡터 저장소와 함께 RAG를 사용하면 다음과 같이 여러 가지 이점이 있습니다.

첫째, 학습 컷오프를 넘어 모델에 대한 지식을 확장합니다. 에이전트는 LLM이 알지 못할 수도 있는 최신 정보 또는 도메인별 데이터를 검색할 수 있습니다. 최근 이벤트나 전문 주제에 대한 질문이 있을 때 유용합니다.

둘째, 요청 시 컨텍스트를 검색하면 환각을 줄이는 데 도움이 됩니다. 특히 LLM은 귀하의 특정 사용 사례에 상대적인 독점적 또는 고도로 전문화된 데이터에 대해 훈련되지 않았기 때문에 환각에 노출될 가능성이 매우 높습니다. 최근 OpenAI 논문(왜 언어 모델이 환각을 일으키는 이유(Why Language Models Hallucinate)에서 강조된 것처럼 LLM이 평가를 통해 추측하거나 새로운 정보를 창조하는 대신, 이 모델은 Elasticsearch의 사실 참조를 통해 근거를 마련할 수 있습니다. 당연히 LLM은 벡터 저장소 내 데이터의 신뢰성에 의존하여 잘못된 정보를 진정으로 방지하고, 관련 데이터는 핵심 관련성 측정에 따라 검색됩니다.

셋째, RAG를 사용하면 에이전트가 프롬프트에 담을 수 있는 것보다 훨씬 더 큰 지식 기반을 활용할 수 있습니다. 긴 연구 논문이나 정책 문서와 같은 전체 문서를 컨텍스트 윈도우에 입력하여 과부하를 초래하거나 관련 없는 정보로 인해 모델의 추론이 컨텍스트 오염될 위험을 감수하는 대신, RAG는 청킹 방식을 사용합니다. 대용량 문서는 의미론적으로 유의미한 더 작은 조각으로 분할되며, 시스템은 쿼리와 가장 관련성이 높은 몇 개의 조각만 검색합니다. 이렇게 하면 모델은 지식이 풍부해 보이기 위한 수백만 개의 토큰으로 이루어진 컨텍스트가 필요하지 않고, 훨씬 더 큰 코퍼스에서 적절한 청크에만 액세스하기만 하면 됩니다.

LLM 컨텍스트 윈도우가 커짐에 따라(일부 모델은 이제 수십만, 심지어 수백만 개의 토큰을 지원함) RAG가 '사라졌는지'에 대한 논쟁이 제기되었다는 점에 주목할 필요가 있습니다. 모든 데이터를 프롬프트에 넣으면 안 되는 이유가 무엇일까요? 만약 여러분도 같은 생각을 하고 있다면, 제 동료인 제프리 렌기포(Jeffrey Rengifo)와 에두아르트 마틴(Eduard Martin)이 쓴 더 긴 컨텍스트 ≠ 더 나은 것: RAG가 여전히 중요한 이유(Longer context ≠ better: Why RAG still matters)라는 훌륭한 글을 참고해 보세요. 이렇게 하면 '쓰레기를 넣으면 쓰레기가 나온다'는 문제를 피할 수 있습니다. LLM은 노이즈를 처리하는 대신 중요한 몇 개의 청크에 집중할 수 있습니다.

즉, Elasticsearch 또는 벡터 저장소를 AI 에이전트 아키텍처에 통합하면 장기적인 메모리를 제공합니다. 에이전트는 지식을 외부 저장소에 저장하고 필요할 때 메모리 컨텍스트로 불러옵니다. 이는 각 사용자 쿼리 후에 에이전트가 Elasticsearch에서 관련 정보를 검색한 다음 LLM을 호출하기 전에 프롬프트에 상위 결과를 추가하는 아키텍처로 구현할 수 있습니다. 응답에 유용한 새로운 정보가 포함되어 있으면 장기 저장소에 다시 저장할 수도 있습니다(학습의 피드백 루프 생성). 이러한 검색 기반 메모리를 사용함으로써 에이전트는 모든 프롬프트에 알고 있는 모든 것을 집어넣을 필요 없이 정보를 유지하고 최신 상태로 유지합니다. 컨텍스트 윈도우가 100만 토큰을 지원한다고 하더라도 마찬가지입니다. 이 기술은 정보 검색과 생성형 AI의 강점을 결합한 컨텍스트 엔지니어링의 초석입니다.

다음은 세션 중 단기 메모리에 대한 LangGraph의 체크포인트 시스템을 사용하여 관리되는 인메모리 대화 상태의 예시입니다. (지원되는 컨텍스트 엔지니어링 앱을 참조하세요.)

체크포인트를 저장하는 방법은 다음과 같습니다.

장기 메모리의 경우, Elasticsearch에서 시맨틱 검색을 수행하여 체크포인트를 요약하고 색인한 후 벡터 임베딩을 사용하여 관련 이전 대화를 검색하는 방법은 다음과 같습니다.

이제 Elasticsearch에서 LangGraph의 체크포인트를 사용해 단기 메모리와 장기 메모리를 색인하고 가져오는 방법을 알아보았으니, 전체 대화를 색인하고 덤핑하는 것이 왜 위험한지 잠시 시간을 내어 살펴보겠습니다.

컨텍스트 메모리를 관리하지 않을 경우의 위험성

컨텍스트 엔지니어링과 단기 및 장기 메모리에 대해 많이 이야기하고 있으니, 에이전트의 메모리와 컨텍스트를 제대로 관리하지 않으면 어떤 일이 발생하는지 알아보겠습니다.

안타깝게도 AI의 컨텍스트가 지나치게 길어지거나 잘못된 정보를 포함할 경우 여러 가지 문제가 발생할 수 있습니다. 컨텍스트 윈도우가 커질수록 다음과 같은 새로운 오류 유형이 나타납니다.

• 컨텍스트 오염
• 컨텍스트 방해
• 컨텍스트 혼동
• 컨텍스트 충돌
• 컨텍스트 누출 및 지식 충돌
• 환각 및 잘못된 정보

컨텍스트 관리가 부실할 때 발생하는 이러한 문제점과 기타 위험 요소를 자세히 살펴보겠습니다.

컨텍스트 오염

컨텍스트 오염이란 부정확하거나 해로운 정보가 컨텍스트에 유입되어 모델의 후속 출력에 악영향을 미치는 현상을 말합니다. 흔한 예로는 모델이 착각한 내용을 사실로 받아들여 대화 기록에 삽입하는 경우가 있습니다. 그러면 모델은 이후 응답에서 해당 오류를 바탕으로 더 나아가 오류를 증폭시킬 수 있습니다. 반복적인 에이전트 루프에서 잘못된 정보가 공유 컨텍스트(예: 에이전트의 작업 노트 요약)에 들어가면 그 정보는 계속해서 강화될 수 있습니다.

DeepMind 연구진은 Gemini 2.5 보고서(요약본은 여기 참조)에서 장시간 실행된 포켓몬 게임 에이전트에서 다음과 같은 현상을 관찰했습니다. 에이전트가 잘못된 게임 상태를 환각으로 인식하고, 그 환각이 에이전트의 컨텍스트(목표에 대한 메모리)에 기록되면, 에이전트는 불가능한 목표를 중심으로 비합리적인 전략을 세우고 결국 막히게 된다는 것입니다. 다시 말해 오염된 메모리는 에이전트를 잘못된 경로로 무한정 몰아넣을 수 있습니다.

컨텍스트 오염은 의도치 않게(실수로) 발생할 수도 있고, 악의적으로 발생할 수도 있습니다. 예를 들어 프롬프트 주입 공격을 통해 사용자나 제3자가 에이전트가 기억하고 따르는 숨겨진 지침이나 허위 사실을 몰래 삽입하는 경우가 있습니다.

권장 대응책

Wiz, Zerlo, Anthropic의 사례를 바탕으로 컨텍스트 오염 방지 대책은 LLM의 프롬프트, 컨텍스트 윈도우 또는 검색 파이프라인에 잘못되거나 오해의 소지가 있는 정보가 유입되는 것을 막는 데 중점을 둡니다. 주요 단계는 다음과 같습니다.

• 컨텍스트를 지속적으로 확인하세요. 시작 프롬프트뿐만 아니라 대화 내용이나 검색된 텍스트에서 의심스럽거나 유해한 내용이 있는지 모니터링하세요.
• 신뢰할 수 있는 출처를 사용하세요. 신뢰도에 따라 문서에 점수를 매기거나 레이블을 지정하여 시스템이 신뢰할 수 있는 정보를 우선시하고 점수가 낮은 데이터는 무시하도록 하세요.
• 비정상적인 데이터를 탐지하세요. 이상하거나 부적절하거나 조작된 콘텐츠를 감지하는 도구를 사용하여 모델이 사용하기 전에 제거하세요.
• 입력 및 출력을 필터링하세요. 유해하거나 오해의 소지가 있는 텍스트가 시스템에 쉽게 유입되거나 모델에 의해 반복되지 않도록 안전장치를 추가하세요.
• 모델을 정제된 데이터로 업데이트하세요. 시스템을 정기적으로 검증된 정보로 갱신하여 눈에 띄지 않게 침투한 불량 데이터를 차단하세요.
• 사람의 개입을 활용하세요(Human-in-the-loop). 중요한 출력물을 사람이 검토하거나 알려진 신뢰할 수 있는 출처와 비교하도록 하세요.

간단한 사용자 습관도 도움이 됩니다. 긴 채팅을 초기화하고, 관련 정보만 공유하고, 복잡한 작업을 작은 단계로 나누고, 모델 외부에서 깔끔한 메모를 유지관리하는 것 등이 그 예입니다.

이러한 조치를 종합하면 LLM을 컨텍스트 오염으로부터 보호하고 출력의 정확성과 신뢰성을 유지하는 다층적인 방어 체계가 구축됩니다.

여기서 언급한 대응책이 없다면 에이전트는 공격자가 삽입한 지시(예: 이전 지침 또는 사소한 사실 무시)를 기억하여 악의적인 출력을 생성할 수 있습니다.

컨텍스트 방해

컨텍스트 방해는 컨텍스트가 너무 길어져 모델이 학습 중에 습득한 내용을 무시하고 컨텍스트에 과도하게 집중하는 경우를 말합니다. 극단적인 경우, 이는 치명적인 망각과 유사합니다. 즉, 모델이 기본 지식을 사실상 '망각'하고 눈앞에 놓인 정보에 지나치게 집착하게 되는 것입니다. 이전 연구에 따르면 LLM은 프롬프트가 극도로 길 때 종종 집중력을 잃는 것으로 나타났습니다.

예를 들어 Gemini 2.5 에이전트는 100만 토큰 윈도우를 지원했지만, 컨텍스트가 특정 지점(실험에서 10만 토큰 정도)을 넘어서자 새로운 솔루션을 제시하는 대신 과거의 행동을 반복하는 데 집착하기 시작했습니다. 말하자면, 에이전트는 방대한 과거 이력에 갇힌 것입니다. 기본 학습 지식을 활용해 새롭고 참신한 전략을 고안하는 대신, 이전 행동의 긴 로그(컨텍스트)를 계속 살펴보고 이를 모방했습니다.

이는 역효과를 초래합니다. 우리는 모델이 추론을 돕기 위해 관련 컨텍스트를 사용하길 원하지, 모델의 사고 능력을 무시하길 원하지 않습니다. 특히, 방대한 데이터 윈도우를 가진 모델조차도 이러한 컨텍스트 왜곡 현상을 보입니다. 즉, 토큰이 추가될수록 성능이 불균일하게 저하됩니다. 주의력 예산이 있는 것으로 보입니다. 작업 기억이 제한된 인간과 마찬가지로 LLM도 토큰에 집중할 수 있는 용량이 한정되어 있으며, 그 예산이 늘어날수록 정확도와 집중력이 떨어집니다.

이러한 문제를 완화하기 위해 청킹, 적절한 정보 엔지니어링, 정기적인 컨텍스트 요약, 점수화를 통한 응답의 정확성을 측정하는 평가 및 모니터링 기법을 사용하여 컨텍스트 방해를 방지할 수 있습니다.

이러한 방법은 모델이 관련 컨텍스트와 기본 학습에 기반을 두도록 하여 주의가 산만해질 위험을 줄이고 전반적인 추론 품질을 향상합니다.

컨텍스트 혼동

컨텍스트 혼동이란 모델이 컨텍스트에 있는 불필요한 콘텐츠를 사용하여 품질이 낮은 응답을 생성하는 것을 말합니다. 대표적인 예로 에이전트에 사용할 수 있는 많은 도구나 API 정의를 제공하는 경우를 들 수 있습니다. 이러한 도구 중 상당수가 현재 작업과 관련이 없더라도, 모델은 컨텍스트에 있다는 이유만으로 부적절하게 사용하려고 시도할 수 있습니다. 실험 결과, 필요하지 않은 도구나 문서를 더 많이 제공하면 오히려 성능이 저하될 수 있다는 사실이 밝혀졌습니다. 에이전트가 잘못된 함수를 호출하거나 관련 없는 텍스트를 참조하는 등의 오류를 범하기 시작하는 것입니다.

한 사례에서 소형 Llama 3.1 8B 모델은 고려해야 할 도구가 46개 주어졌을 때는 작업에 실패했지만, 19개만 주어졌을 때는 성공했습니다. 컨텍스트 길이가 제한 내에 있었음에도 불구하고, 추가 도구는 혼동을 야기했습니다. 근본적인 문제는 프롬프트에 포함된 모든 정보가 모델에 의해 처리된다는 점입니다. 모델이 어떤 정보를 무시해야 하는지 알지 못하면, 그 정보가 모델의 출력에 원치 않는 영향을 미칠 수 있습니다. 관련 없는 정보가 모델의 주의를 분산시켜 잘못된 방향으로 이끌 수 있습니다(예를 들어 관련 없는 문서로 인해 에이전트가 질문과 다른 답변을 할 수 있습니다). 컨텍스트 혼동은 종종 모델이 관련 없는 컨텍스트를 통합하여 품질이 낮은 응답을 생성하는 형태로 나타납니다. 관련 연구 논문 적을수록 낫다: 엣지 디바이스에서의 LLM 실행을 위한 함수 호출 최적화(Less is More: Optimizing Function Calling for LLM Execution on Edge Devices)를 참조하세요.

이는 더 많은 컨텍스트가 항상 더 나은 것은 아니라는 점을 상기시켜 줍니다. 특히 관련성에 맞게 선별되지 않았다면 더욱 그렇습니다.

컨텍스트 충돌

컨텍스트 충돌은 컨텍스트의 일부가 서로 모순되어 모델의 추론을 방해하는 내부 불일치를 일으킬 때 발생합니다. 에이전트가 충돌하는 여러 정보를 축적하는 경우 충돌이 발생할 수 있습니다.

예를 들어 에이전트가 두 개의 출처에서 데이터를 가져왔다고 가정해 보겠습니다. 하나는 A 항공편이 오후 5시에 출발한다고 하고, 다른 하나는 A 항공편이 오후 6시에 출발한다고 합니다. 두 사실이 모두 컨텍스트에 포함되면, 성능이 떨어지는 모델은 어느 것이 정확한지 알 수 없습니다. 혼란스러워하거나 부정확한 답변 또는 유사하지 않은 답변을 생성할 수 있습니다.

컨텍스트 충돌은 모델이 이전에 시도했던 답변이 나중에 추가된 정보와 함께 컨텍스트에 남아 있는 다중 턴 대화에서도 자주 발생합니다.

Microsoft와 Salesforce의 연구에 따르면 복잡한 쿼리를 여러 번의 챗봇 턴 대화로 나누어 (세부 정보를 점진적으로 추가하여) 답변할 경우, 모든 정보를 한 번에 제공하는 경우에 비해 최종 정확도가 크게 떨어지는 것으로 나타났습니다. 왜 그럴까요? 초기 턴에는 모델의 부분적이거나 부정확한 중간 답변이 포함되어 있고 이러한 답변이 컨텍스트에 남아 있기 때문입니다. 나중에 모델이 모든 정보를 가지고 답변을 시도할 때, 모델의 메모리에는 여전히 이러한 잘못된 답변이 포함되어 있으며, 이는 수정된 정보와 충돌하여 잘못된 방향으로 나아가게 합니다. 본질적으로 대화의 컨텍스트가 스스로 충돌하는 것입니다. 모델은 새로운 정보를 추가한 후에도 적용되지 않는 오래된 컨텍스트(이전 턴의 컨텍스트)를 의도치 않게 사용할 수 있습니다.

에이전트 시스템에서 컨텍스트 충돌은 특히 위험한데, 에이전트가 서로 다른 도구나 하위 에이전트의 출력을 결합할 수 있기 때문입니다. 이러한 출력이 서로 일치하지 않으면 통합된 컨텍스트가 일관성을 잃게 됩니다. 그러면 에이전트는 모순을 해결하려다 오류가 발생하거나 비합리적인 결과를 생성할 수 있습니다. 컨텍스트 충돌을 방지하려면 컨텍스트를 최신 상태로 유지하고 일관성을 보장해야 합니다. 예를 들어 오래된 정보를 삭제하거나 업데이트하고, 일관성 검증을 거치지 않은 소스를 혼합해서 사용하지 않아야 합니다.

컨텍스트 누출 및 지식 충돌

여러 에이전트 또는 사용자가 메모리 저장소를 공유하는 시스템에서는 컨텍스트 간에 정보가 유출될 위험이 있습니다.

예를 들어 적절한 액세스 제어 없이 두 사용자의 데이터 임베딩이 동일한 벡터 데이터베이스에 저장된 경우, 사용자 A의 쿼리에 응답하는 에이전트가 실수로 사용자 B의 메모리 일부를 가져올 수 있습니다. 이러한 컨텍스트 간 누출은 개인 정보를 노출하거나 응답에 혼란을 초래할 수 있습니다.

LLM 애플리케이션을 위한 OWASP Top 10에 따르면 멀티테넌트 벡터 데이터베이스는 이러한 누출을 방지해야 합니다.

LLM08:2025 벡터 및 임베딩 약점에 따르면, 일반적인 위험 중 하나는 컨텍스트 누출입니다.

여러 사용자 또는 애플리케이션이 동일한 벡터 데이터베이스를 공유하는 멀티테넌트 환경에서는 사용자 또는 쿼리 간에 컨텍스트 누출 위험이 있습니다. 데이터 페더레이션 지식 충돌 오류는 여러 소스의 데이터가 서로 모순될 때 발생할 수 있습니다. 또한 LLM이 학습 과정에서 얻은 기존 지식을 검색 증강을 통해 얻은 새로운 데이터로 대체하지 못할 때도 이러한 오류가 발생할 수 있습니다.

또 다른 측면은 LLM이 기본 제공 지식을 메모리의 새로운 정보로 재정의하는 데 어려움을 겪을 수 있다는 것입니다. 모델이 특정 사실에 기반하여 학습되었는데 검색된 컨텍스트가 그와 반대되는 내용을 담고 있다면 모델은 어떤 것을 신뢰해야 할지 혼란스러워할 수 있습니다. 적절한 설계가 없으면 에이전트가 컨텍스트를 혼동하거나 기존 지식을 새로운 증거로 업데이트하지 못하여 오래되거나 부정확한 답변을 내놓을 수 있습니다.

환각 및 잘못된 정보

환각(LLM이 그럴듯하지만, 틀린 정보를 만드는 것)은 긴 설명이 필요 없는 잘 알려진 문제로, 메모리 관리가 제대로 이루어지지 않으면 더욱 심해질 수 있습니다.

에이전트의 메모리에 중요한 사실이 누락된 경우, 모델은 추측으로 그 공백을 채울 수 있으며, 만약 그 추측이 컨텍스트에 들어가게 되면(컨텍스트를 오염시키면서) 오류가 지속됩니다.

OWASP LLM 보안 보고서(LLM09:2025 잘못된 정보)는 잘못된 정보를 핵심 취약점으로 지적합니다. LLM은 확신에 찬 듯 보이지만 조작된 답변을 생성할 수 있으며, 사용자는 이를 과신할 수 있습니다. 장기 메모리가 불량하거나 오래된 에이전트는 메모리가 최신 상태로 유지되지 않으면 작년에는 사실이었지만 지금은 거짓인 정보를 확신에 차서 인용할 수 있습니다.

AI의 출력에 지나치게 의존하는 것(사용자 또는 에이전트 자체가 반복적인 과정에서)은 이러한 문제를 악화시킬 수 있습니다. 메모리에 저장된 정보를 아무도 검증하지 않으면 에이전트는 잘못된 정보를 축적하게 됩니다. 이것이 바로 RAG가 환각을 줄이는 데 자주 사용되는 이유입니다. RAG를 통해 권위 있는 출처를 검색함으로써 모델은 사실을 만들어낼 필요가 없습니다. 하지만 잘못된 문서(예: 잘못된 정보가 포함된 문서)를 검색하거나 초기 환각을 제거하지 않으면 시스템은 해당 잘못된 정보를 전체 작업에 전파할 수 있습니다.

결론적으로 메모리 관리에 실패하면 부정확하고 오해의 소지가 있는 출력으로 이어질 수 있으며, 이는 특히 위험 부담이 큰 경우(예: 금융이나 의료 분야에서 잘못된 조언) 심각한 피해를 초래할 수 있습니다. 에이전트는 컨텍스트에 있는 내용을 무조건 신뢰하는 것이 아니라 메모리 내용을 검증하거나 수정할 수 있는 메커니즘을 갖춰야 합니다.

요약하자면 AI 에이전트에 무한히 긴 메모리를 제공하거나 가능한 모든 것을 컨텍스트에 넣는 것은 성공의 비결이 아닙니다.

LLM 애플리케이션에서의 메모리 관리 모범 사례

위에서 언급한 문제점을 방지하고자 개발자와 연구자는 AI 시스템에서 컨텍스트와 메모리를 관리하는 여러 가지 모범 사례를 고안했습니다. 이러한 사례는 AI의 작업 컨텍스트를 간결하고 관련성 있으며 최신 상태로 유지하는 것을 목표로 합니다. 다음은 주요 전략 몇 가지와 그 효과를 보여주는 예시입니다.

RAG: 타겟팅된 컨텍스트 사용

RAG에 대한 내용은 이전 섹션에서 이미 많이 다루었습니다. 이 부분은 실용적인 핵심 사항을 간략하게 다시 한번 상기시켜 드리는 것입니다.

• 대량 로딩이 아닌 대상 검색을 사용하세요. 전체 문서나 전체 대화 기록을 프롬프트에 입력하는 대신 가장 관련성이 높은 청크만 검색하세요.
• RAG를 적절한 시기에 메모리를 불러오는 기능으로 활용하세요. 모든 정보를 턴 전반에 가져가지 말고, 필요할 때만 컨텍스트를 가져오세요.
• 관련성 인식 검색 전략을 선호하세요. 상위 k개 시멘틱 검색, 상호 순위 융합 또는 도구 구성 필터링과 같은 접근 방식은 노이즈를 줄이고 근거를 개선하는 데 도움이 됩니다.
• 컨텍스트 윈도우가 크다고 해서 RAG의 필요성이 없어지는 것은 아닙니다. 관련성이 높은 두 갱의 단락이 관련성이 낮은 20페이지 분량의 문서보다 거의 항상 더 효과적입니다.

즉, RAG는 더 많은 컨텍스트를 추가하는 것이 아니라 적절한 컨텍스트를 추가하는 것입니다.

도구 구성

도구 구성은 모델에 특정 작업에 실제로 필요한 도구만 제공하는 것을 의미합니다. 이 용어는 게임에서 유래했는데, 상황에 맞는 구성을 선택하는 것과 같습니다. 도구가 너무 많으면 속도가 느려지고, 잘못된 도구는 실패로 이어집니다. 연구 논문 적을수록 낫다(Less is more)에 따르면 LM도 마찬가지로 동작합니다. 도구가 약 30개를 넘어서면 설명이 중복되어 모델이 혼란스러워집니다. 100개를 넘어서면 실패가 거의 확실해집니다. 이는 컨텍스트 윈도우 문제가 아니라 컨텍스트 혼동 문제입니다.

간단하면서도 효과적인 해결책은 RAG-MCP입니다. 모든 도구를 프롬프트에 나열하는 대신, 도구 설명을 벡터 데이터베이스에 저장하고 요청 시 가장 관련성이 높은 도구만 불러옵니다. 실제로 이렇게 하면 도구 구성이 간결하고 집중적으로 유지되고 프롬프트 표시 시간이 크게 단축되며 도구 선택 정확도가 최대 3배까지 향상될 수 있습니다.

소규모 모델일수록 이러한 한계에 더 빨리 부딪힙니다. 연구 결과에 따르면 80억 단위의 모델은 수십 개의 도구를 사용할 때는 제대로 작동하지 않지만, 도구 구성을 줄이면 성공하는 것으로 나타났습니다. 필요한 도구를 추론하여 동적으로 선택하는 방식(때로는 LLM을 먼저 사용하는 방식)은 성능을 44% 향상하면서 전력 소비와 지연 시간도 줄일 수 있습니다. 핵심은 대부분의 에이전트는 몇 개의 도구만 필요하지만, 시스템 규모가 커질수록 도구 구성과 RAG-MCP가 설계에서 가장 중요한 고려 사항이 된다는 것입니다.

컨텍스트 가지치기: 채팅 기록 길이 제한

대화가 여러 차례 이어지면 누적된 채팅 기록이 너무 커져서 컨텍스트 오버플로가 발생하거나 모델에 방해가 될 수 있습니다.

트리밍이란 대화가 길어짐에 따라 중요도가 낮은 부분을 프로그램적으로 제거하거나 축약하는 것을 의미합니다. 간단한 방법으로는 특정 한계에 도달했을 때 가장 오래된 대화 내용을 삭제하고 최근 N개의 메시지만 남기는 것이 있습니다. 더 정교한 가지치기는 관련 없는 곁가지 이야기나 더 이상 필요하지 않은 이전 지시 사항을 제거할 수 있습니다. 목표는 컨텍스트 윈도우를 오래된 정보로 어지럽히지 않고 깔끔하게 유지하는 것입니다.

예를 들어 에이전트가 10턴 전에 하위 문제를 해결했고 그 이후로 넘어갔다면 더 이상 필요하지 않다고 가정하여 해당 기록 부분을 컨텍스트에서 삭제할 수 있습니다(더 이상 필요하지 않다고 가정). 많은 채팅 기반 구현이 이와 같은 방식을 사용합니다. 즉, 최근 메시지의 롤링 윈도우를 유지관리합니다.

트리밍은 대화의 앞부분이 요약되었거나 관련성이 없다고 판단되면 해당 부분을 '잊어버리는' 것처럼 간단하게 할 수 있습니다. 이렇게 하면 컨텍스트 오버플로 오류 위험과 컨텍스트 방해를 줄여 모델이 오래되거나 주제에서 벗어난 콘텐츠에 현혹되지 않도록 할 수 있습니다. 이는 사람이 한 시간짜리 대화의 모든 단어는 기억하지 못하지만 핵심 내용은 기억하는 것과 매우 유사합니다.

컨텍스트 가지치기가 헷갈린다면, 저자 드류 브루니그(Drew Breunig)가 여기서 강조했듯이, 질문 답변을 위한 가볍고(1.75GB), 효율적이며 정확한 컨텍스트 가지치기 도구인 Provence (`naver/provence-reranker-debertav3-v1`) 모델을 사용해 보시면 도움이 될 수 있습니다. 이 모델은 방대한 문서를 특정 쿼리에 가장 관련성이 높은 텍스트만 남기도록 다듬어 줍니다. 특정 간격으로 호출할 수도 있습니다.

컨텍스트 가지치기를 위해 코드에서 `provence-reranker` 모델을 호출하는 방법은 다음과 같습니다.

문장 관련성 점수 계산에는 Provence reranker 모델(`naver/provence-reranker-debertav3-v1`)을 사용합니다. 임계값 기반 필터링을 통해 관련성 임계값 이상의 문장만 남깁니다. 또한 가지치기가 실패할 경우 원래 컨텍스트으로 되돌아가는 폴백(fallback) 메커니즘을 도입했습니다. 마지막으로 상세 모드에서는 통계 로깅을 통해 감소율을 추적합니다.

컨텍스트 요약: 이전 정보를 완전히 삭제하는 대신 축약

요약은 트리밍의 동반자입니다. 기록이나 지식 베이스가 너무 커지면 위의 코드에서 수행한 것처럼 LLM을 사용하여 중요한 요점에 대한 간략한 요약을 생성하고 앞으로 전체 콘텐츠 대신 이 요약을 사용할 수 있습니다.

예를 들어 AI 어시스턴트가 50턴 대화를 나눴다고 가정해 봅시다. 51턴 대화에서 50턴까지 대화를 한꺼번에 보내는 대신(용량 부족 문제 발생 가능성이 높음), 시스템은 1~40턴까지 대화만 처리하고 모델이 이를 요약하여 단락으로 작성하도록 한 다음, 다음 대화에서는 해당 요약본과 마지막 10턴까지의 대화 내용만 제공할 수 있습니다. 이렇게 하면 모델은 모든 세부 정보를 입력받지 않고도 어떤 내용이 논의되었는지 파악할 수 있습니다. 초기 챗봇 사용자는 "지금까지 나눈 대화를 요약해 줄 수 있나요?"라고 수동으로 질문하고, 요약 내용을 바탕으로 새로운 대화를 이어갔습니다. 이제는 이 작업을 자동화할 수 있습니다. 요약은 컨텍스트 윈도우 공간을 절약할 뿐만 아니라 불필요한 세부 정보를 제거하고 중요한 사실만 유지함으로써 컨텍스트 혼동/방해를 줄일 수 있습니다.

여기서는 OpenAI 모델(다른 LLM 모델도 사용 가능)을 활용하여 모든 관련 정보를 보존하면서 컨텍스트를 축약하고 중복 및 비효율성을 제거하는 방법을 설명합니다.

중요한 것은 컨텍스트가 요약되면 (요약이 정확하다는 가정 하에) 모델이 사소한 세부 사항이나 과거 오류에 압도될 가능성이 줄어든다는 점입니다.

하지만 요약은 신중하게 해야 합니다. 요약이 잘못되면 중요한 세부 사항이 누락되거나 오류가 발생할 수도 있습니다. 요약은 본질적으로 모델에 대한 또 다른 프롬프트("이것을 요약하세요")이기 때문에 뉘앙스가 왜곡되거나 사라질 수 있습니다. 가장 좋은 방법은 점진적으로 요약하고 일부 표준적인 사실은 요약하지 않는 것입니다.

그럼에도 불구하고 이는 매우 유용한 것으로 입증되었습니다. Gemini 에이전트 시나리오에서 약 10만 토큰마다 컨텍스트를 요약하는 것은 모델의 반복적인 경향을 상쇄하는 방법이었습니다. 요약은 대화 또는 데이터의 압축된 메모리 역할을 합니다. 개발자는 에이전트가 대화 기록이나 긴 문서에 대해 주기적으로 요약 함수(소규모 LLM 또는 전용 루틴)를 호출하도록 구현할 수 있습니다. 결과로 생성된 요약은 프롬프트의 원래 내용을 대체합니다. 이 전략은 컨텍스트를 제한적으로 유지하고 정보를 추출하는 데 널리 사용됩니다.

컨텍스트 격리: 가능한 경우 컨텍스트 격리

이는 복잡한 에이전트 시스템이나 다단계 워크플로우에서 더욱 중요합니다. 컨텍스트 세분화의 핵심 아이디어는 큰 작업을 각각 고유한 컨텍스트를 가진 더 작고 독립적인 작업으로 나누는 것입니다. 이렇게 하면 모든 것을 포함하는 하나의 거대한 컨텍스트가 누적되는 것을 방지할 수 있습니다. 각 하위 에이전트 또는 하위 작업은 특정 컨텍스트에 집중하여 문제 일부를 해결하고, 상위 에이전트, 감독자 또는 조정자가 결과를 통합합니다.

Anthropic의 연구 전략은 여러 개의 하위 에이전트를 활용합니다. 각 하위 에이전트는 고유한 컨텍스트 윈도우를 가지고 질문의 서로 다른 측면을 조사하며, 리드 에이전트는 이러한 하위 에이전트가 도출한 결과를 종합적으로 분석합니다. 이러한 병렬적인 모듈식 접근 방식 덕분에 어느 하나의 컨텍스트 윈도우도 과도하게 복잡해지지 않습니다. 또한 관련 없는 정보가 섞일 가능성을 줄이고, 각 스레드는 주제에서 벗어나지 않으며(컨텍스트 혼동 방지), 특정 하위 질문에 답할 때 불필요한 정보를 포함하지 않습니다. 마치 사고 과정 전체가 아닌 결과만 공유하는 별개의 독립적인 사고 스레드를 실행하는 것과 같습니다.

멀티 에이전트 시스템에서는 이러한 접근 방식이 필수적입니다. 에이전트 A가 작업 A를 처리하고 에이전트 B가 작업 B를 처리하는 경우, 정말 필요한 경우가 아니라면 어느 에이전트도 다른 에이전트의 전체 컨텍스트를 소비할 이유가 없습니다. 대신 에이전트는 필요한 정보만 교환할 수 있습니다. 예를 들어 에이전트 A는 감독 에이전트를 통해 에이전트 B에 조사 결과의 통합 요약을 전달할 수 있으며, 각 하위 에이전트는 자체적인 전용 컨텍스트 스레드를 유지관리합니다. 이러한 구성은 사람의 개입이 필요하지 않으며, 최소한의 제어된 컨텍스트 공유 기능을 갖춘 도구를 사용하는 감독 에이전트에 의존합니다.

그럼에도 불구하고 에이전트나 도구가 필요한 컨텍스트 중복을 최소화하면서 작동하도록 시스템을 설계하면 명확성과 성능을 크게 향상할 수 있습니다. 이를 AI를 위한 마이크로서비스라고 생각하면 됩니다. 각 구성 요소는 고유한 컨텍스트를 처리하고, 단일 컨텍스트 대신 제어된 방식으로 구성 요소 간에 메시지를 전달합니다. 이러한 모범 사례는 종종 함께 사용됩니다. 또한 이를 통해 사소한 기록을 트리밍하고 중요한 이전 메시지나 대화를 요약하며, 상세한 로그를 Elasticsearch에 저장하여 장기적인 컨텍스트를 유지하고 필요할 때 관련 정보를 검색할 수 있는 유연성을 확보할 수 있습니다.

앞서 언급했듯이, 핵심 원칙은 컨텍스트는 제한적이고 귀중한 자원이라는 것입니다. 프롬프트의 모든 토큰은 제 역할을 다해야 하며, 출력의 질 향상에 기여해야 합니다. 메모리에 저장된 요소가 제 역할을 하지 못하고 더 나아가 혼동을 야기하는 경우 그 항목을 제거하거나 요약하거나 제외해야 합니다.

개발자로서 이제 코드를 프로그래밍하듯이 컨텍스트를 프로그래밍할 수 있습니다. 어떤 정보를 포함할지, 어떤 형식으로 표현할지, 언제 생략하거나 업데이트할지 결정할 수 있습니다. 이러한 방식을 따르면 LLM 에이전트가 앞서 설명한 오류 모드에 빠지지 않고 작업을 수행하는 데 필요한 컨텍스트를 제공할 수 있습니다. 결과적으로 에이전트는 기억할 정보는 기억하고, 기억할 필요 없는 정보는 잊고, 필요한 정보는 적시에 검색할 수 있게 됩니다.

결론

메모리는 에이전트에 추가하는 것이 아니라 설계하는 것입니다. 단기 메모리는 에이전트의 작업 임시 저장소 역할을 하고, 장기 메모리는 영구적인 지식 저장소 역할을 합니다. RAG는 이 둘을 연결하는 다리 역할을 하며, Elasticsearch와 같은 수동적인 데이터 저장소를 능동적인 재현 메커니즘으로 전환하여 출력을 안정적으로 유지하고 에이전트를 최신 상태로 유지합니다.

하지만 메모리는 양날의 검과도 같습니다. 컨텍스트를 방치하는 순간 오염, 방해, 혼동, 충돌이 발생하고 공유 시스템에서는 데이터 누출까지 일어날 수 있습니다. 그렇기 때문에 가장 중요한 메모리 작업은 '더 많이 저장'하는 것이 아니라 '더 잘 선별'하는 것입니다. 선택적으로 검색하고 공격적으로 정리하며, 신중하게 요약하고 업무에 꼭 필요한 경우가 아니라면 관련 없는 컨텍스트를 섞지 마세요.

실제로 훌륭한 컨텍스트 엔지니어링은 훌륭한 시스템 설계와 유사합니다. 즉, 작고 충분한 컨텍스트, 구성 요소 간의 제어된 인터페이스, 그리고 원시 상태와 모델이 실제로 인식해야 하는 정제된 상태를 명확하게 구분하는 것입니다. 제대로 구현하면 모든 것을 기억하는 에이전트를 만드는 것이 아니라, 적시에 적합한 이유로 적절한 정보를 기억하는 에이전트를 만들 수 있습니다.