AI 에이전트 메모리 관리: 컨텍스트 윈도우 (Context Window)를 넘어

당신의 에이전트는 5분 전에 올바르게 답변했습니다. 그런데 지금은 똑같은 정보를 다시 묻고 있습니다. 컨텍스트 윈도우 (Context Window)가 가득 찼고, 초기 메시지들이 밀려났으며(evicted), 그 모든 이력이 사라졌기 때문입니다.

이것은 환각 (Hallucination) 문제가 아닙니다. 메모리 아키텍처 (Memory Architecture) 문제입니다.

증상: 작업 도중 망각하는 에이전트

당신은 다단계 워크플로 (Multistep Workflows)를 처리하는 에이전트를 디버깅하고 있습니다. 15번째 턴(turn)쯤 되었을 때, 에이전트는 스스로 모순되는 말을 하기 시작합니다. 3번째 턴에서 이미 답변했던 질문을 다시 던집니다. 7번째 턴에서 내렸던 결정을 무시합니다.

컨텍스트 제한 (Context Limits)이 명백한 범인이지만, 진짜 문제는 더 깊은 곳에 있습니다. 대부분의 에이전트 구현체는 컨텍스트 윈도우 (Context Window)를 메모리로 취급합니다. 하지만 그것은 메모리가 아닙니다. 그것은 윈도우가 가득 차는 즉시 오래된 데이터를 밀어내는 작업 메모리 (Working Memory)입니다. 무언가가 컨텍스트 (Context) 밖으로 밀려나는 순간, 에이전트는 그것으로 돌아갈 수 있는 경로를 잃게 됩니다.

이 글은 바로 그 간극을 다룹니다.

작업 메모리 (Working Memory) vs 장기 메모리 (Longterm Memory)

컨텍스트 윈도우 (Context Window)는 에이전트의 작업 메모리 (Working Memory)입니다. 이는 현재의 대화, 현재의 작업 상태, 그리고 시작할 때 집어넣은 모든 것을 보유합니다. 읽는 속도는 빠르지만, 초기화됩니다. 모든 새로운 세션은 빈 상태로 시작됩니다.

장기 메모리 (Longterm Memory)는 세션 전반에 걸쳐 지속되는 것입니다: 사용자 선호도, 이전의 결정, 문제 도메인에 대해 학습된 사실들 말입니다. 이것이 없다면, 모든 세션은 에이전트에게 첫 번째 세션이 됩니다.

이 구분이 중요한 이유는 해결책이 다르기 때문입니다. 작업 메모리 문제 (작업 도중 망각)는 컨텍스트 관리 (Context Management) 기술이 필요합니다. 장기 메모리 문제 (세션 간 건망증)는 저장 및 검색 레이어 (Storage and Retrieval Layer)가 필요합니다.

대부분의 글은 이 둘을 혼동합니다. 대부분의 에이전트는 이 중 어느 것도 제대로 해결하지 못합니다.

중간 유실 문제 (Lost in the Middle Problem)와 위치가 중요한 이유

단일 컨텍스트 윈도우 (Context Window) 내부에서조차, 위치는 당신이 생각하는 것보다 더 중요합니다.

연구에 따르면 LLM(Large Language Models)은 "중간에서 길을 잃는 (lost in the middle)" 효과를 보입니다. 즉, 관련 정보가 컨텍스트 (Context)의 시작 부분이나 끝 부분에 있을 때 정확도가 가장 높으며, 중간에 파묻힌 정보에 대해서는 정확도가 현저히 떨어집니다. 만약 64k 토큰 윈도우 (Token Window)를 사용 중인데 가장 중요한 검색 문서 (Retrieved Documents)를 30k 위치에 배치한다면, 당신은 사실상 모델로부터 그 정보를 숨긴 것이나 다름없습니다.

실질적인 결과는 다음과 같습니다. RAG (Retrieval-Augmented Generation) 시스템을 구축할 때, 검색된 모든 청크 (Chunks)를 프롬프트 (Prompt) 중간에 쏟아붓고 모델이 이를 동일한 비중으로 처리하기를 기대해서는 안 됩니다. 모델은 그렇게 하지 않습니다.

실제 운영 환경에서의 해결책은 가장 신뢰도가 높은 검색 문서를 컨텍스트의 맨 처음과 맨 끝에 배치하는 것입니다. 컨텍스트 윈도우 (Context Window)를 샌드위치처럼 다루세요. 상단에 중요한 컨텍스트, 하단에 다시 중요한 컨텍스트를 두고, 중간에는 채우기용 정보를 넣는 방식입니다.

하이브리드 패턴: 시작 시 자동 검색(Autoretrieve), 이후 에이전트 주도 저장(Agent Driven Storage)

실제 운영 환경에서 유효한 패턴은 두 가지 메커니즘의 조합입니다.

요청 시작 시 자동 검색 (Autoretrieve at request start). 에이전트의 매 턴 (Turn)이 시작되기 전, 현재 쿼리 (Query) 또는 작업 상태를 기반으로 관련 장기 메모리 (Long-term Memories)를 자동으로 검색합니다. 이는 에이전트가 새로운 세션에서도 항상 사용 가능한 최선의 컨텍스트를 가지고 시작함을 의미합니다.

에이전트 주도 저장 (Agent driven storage). 무엇을 보관할 가치가 있는지 에이전트가 직접 결정하게 합니다. 작업을 완료하거나 중요한 결정을 내린 후, 에이전트는 장기 메모리에 다음과 같이 기록합니다: "사용자는 TypeScript의 strict mode를 선호함, 세 번 언급함." 이는 다음 세션에서 검색할 가치가 있는 정보입니다.

견고한 에이전트 메모리 관리 (agent memory management)는 작업용 메모장 (Scratchpad) 옆에 있는 서류 캐비닛과 같다고 생각할 수 있습니다. 자동 검색 (Autoretrieve)은 매 턴이 시작될 때 캐비닛에서 관련 파일을 꺼내오고, 에이전트 주도 저장 (Agent driven storage)은 보관할 가치가 있는 것들을 다시 캐비닛에 파일로 정리해 넣습니다.

벡터 저장소의 역할과 리랭킹(Rerank) 방법

대규모의 장기 메모리(Long-term memory)는 벡터 데이터베이스(Vector database)에 저장됩니다. 메모리(또는 문서 청크)를 벡터 공간(Vector space)에 임베딩(Embedding)하고, 의미론적 유사성(Semantic similarity)에 따라 검색합니다. 새로운 쿼리(Query)가 들어오면 유사도 검색을 실행하여 가장 관련성이 높은 상위 K개의 청크를 가져옵니다.

문제는 "가장 유사한 것"과 "가장 유용한 것"이 동일하지 않다는 점입니다. 가공되지 않은 코사인 유사도(Cosine similarity) 점수를 반환하는 검색 시스템은 때때로 가장 관련성이 높은 결과보다 지엽적으로 관련된 콘텐츠를 상단에 노출할 수 있습니다. 바로 이 지점에서 리랭킹(Reranking)의 필요성이 생깁니다.

리랭커(Reranker)는 검색된 상위 K개의 청크를 가져와 더 비용이 많이 드는 크로스 인코더(Cross-encoder) 모델을 사용하여 다시 점수를 매깁니다. 벡터 유사도 검색보다 속도는 느리지만, 소수의 후보군(K는 보통 10~20개)을 대상으로 실행되므로 지연 시간(Latency)을 관리 가능한 수준으로 유지할 수 있습니다. 그 결과물은 가장 진정으로 유용한 청크가 상단에 위치하도록 재정렬된 리스트입니다.

기술 스택을 선택 중이라면, 확정하기 전에 지연 시간, 필터링 지원 및 관리형 호스팅 옵션에 따라 벡터 데이터베이스를 비교해 볼 수 있습니다.

코드로 구현한 최소한의 메모리 루프

다음은 하이브리드 패턴을 구현한 현실적인 Python 스케치입니다. 여기서는 벡터 저장소를 래핑(Wrapping)한 가상의 메모리 클라이언트를 사용합니다.

from memory_client import MemoryClient
from llm_client import LLMClient

...

should_store 플래그는 흥미로운 결정이 내려지는 지점입니다. 이를 두 번째 LLM 호출("이 응답이 향후 세션을 위해 기억할 가치가 있는 내용인가?"), 단순한 휴리스틱(특정 길이 이상의 결정 또는 명시적인 선호도가 포함된 응답), 또는 메인 LLM이 채우는 구조화된 출력(Structured output) 필드로 구현할 수 있습니다.

단순하게 시작하세요. 단순한 휴리스틱이라도 메모리가 아예 없는 것보다는 낫습니다. 에이전트가 실제로 무엇을 유지해야 하는지 파악한 후에 저장 로직을 업그레이드하면 됩니다.

FAQ

컨텍스트 윈도우(Context window)와 메모리의 차이점은 무엇인가요?

컨텍스트 윈도우(Context window)는 일시적인 작업 메모리(working memory)입니다. 이는 현재 턴(turn)의 정보를 보유하며 세션 사이에 초기화됩니다. 메모리(Memory)는 세션 리셋 후에도 유지되는 영구 저장소(persistent store)이며, 에이전트가 명시적으로 읽고 쓰는 데이터베이스(database)에 의해 뒷받침됩니다.

에이전트는 세션이 바뀌어도 어떻게 기억하나요?

자동으로 기억하지는 않습니다. 명시적인 저장소(보통 벡터 데이터베이스(vector database) 또는 구조화된 키-값 저장소(structured key-value store))와 검색(retrieval) 로직을 직접 연결해야 합니다. 에이전트는 작업이 끝날 때 중요한 정보를 저장소에 기록하고, 다음 세션이 시작될 때 관련 항목을 검색합니다.

'중간 유실 문제(lost in the middle problem)'란 무엇인가요?

대규모 언어 모델(LLMs)은 긴 컨텍스트 윈도우(context window)의 중간에 있는 정보보다 시작 부분이나 끝 부분에 있는 정보에 더 많은 주의(attention)를 기울입니다. 만약 가장 중요한 검색 문서들을 거대한 프롬프트(prompt)의 중앙에 배치한다면, 모델은 이를 사실상 무시할 수도 있습니다. 해결책은 신뢰도가 가장 높은 청크(chunks)를 컨텍스트의 맨 처음과 맨 끝에 배치하는 것입니다.

에이전트 메모리 아키텍처(agent memory architecture)에 대해 더 깊이 알고 싶다면, 제 사이트에서 더 자세히 다루고 있습니다.

이 기능을 귀하의 시스템에 엔드 투 엔드(end to end)로 직접 구축하고 싶다면, 바로 제가 수행하는 업무의 종류입니다.

귀하의 설정이 다르다면 댓글을 남겨주세요. 사람들이 실제 운영 환경(production)에서 어떤 메모리 스택(memory stacks)을 사용하고 있는지 궁금합니다.