[ByteByteGo] How AI Agents Manage Memory and Avoid Forgetfulness

https://blog.bytebytego.com/p/how-ai-agents-manage-memory-and-avoid?utm_source=post-email-title&publication_id=817132&post_id=203744632&utm_campaign=email-post-title&isFreemail=true&r=4auvy4&triedRedirect=true&utm_medium=email

How AI Agents Manage Memory and Avoid Forgetfulness

 

도입부

개발 스택에 포함된 정교한 AI 에이전트라고 해도, 매번 메시지를 시작할 때마다 완전한 백지 상태에서 출발하게 된다.

모델 자체는 오직 그 정확한 순간에 자신 앞에 놓인 텍스트만 볼 수 있으며, 나머지 대화 내용은 모델의 인지 범위 밖에 완전히 독립되어 존재한다.

 

우리가 클로드나 챗GPT와 대화할 때 느끼는 어떠한 연속성도 사실 주변 플랫폼 시스템이 모델을 대신해서 매 호출마다 적절한 컨텍스트를 다시 주입해 주도록 엔지니어링 한 결과물이다.

 

이 결정적 차이를 이해하고 나면, 에이전트 메모리라는 분야 전체가 처음 보이는 것과는 전혀 다른 차원의 엔지니어링 문제로 다가온다.

 

해당 포럼에서는 메모리 아키텍쳐가 왜 존재해야하는지 근본적인 제약 조건부터, 그에 따라 수반되는 트레이드 오프 관계에 이르기 까지 해당 아키텍쳐가 어떻게 구축되는지 확인할 수 있다.

 

Statelessness(무상태성)

LLM을 호출하는 과정은 단순한 패턴을 따르며 시스템이 프롬프트를 보내면 모델이 답변을 반환하고 해당 상호작용은 그 자리에서 끝이난다.

 

그 직후 1ms 뒤에 이루어지는 다음 호출이라도 완전히 새로운 백지 상태에서 다시 시작된다. 이것이 모든 상용 LLM의 API 규약이며 트랜스포머 모델이 트래픽을 처리하는 구조적 방식을 반영한 것이다.

 

 

우리가 클로드가 어제 나눈 대화를 기억하고 있네 라고 말하는 것은 실제 모델 자체의 특성이 아닌 제품으로서의 특성을 설명하는 것이다.

 

플랫폼이 시스템 모델을 대신하여 정보를 기록해두고, 정확히 필요한 타이밍에 그 내용을 프롬프트로 다시 읽어들여 제공함으로써 모델이 마치 처음부터 그 자리에 계속 있었던 것처럼 추론할 수 있게 만드는 것이다.

 

즉, 지능은 모델 내부에 존재하지만, 기억(Memory)는 모델을 둘러싸고 있는 외부 백엔드 시스템에 존재하는 구조이다.

 

만약 모델 자체가 이런 방식으로 동작한다면 매번 호출할 때마다 모델의 프롬프트 창에 그냥 과거의 모든 대화 내용을 몽땅 다 밀어 넣어서 메모리 문제를 해결할 수는 없을까? 라는 의문이 들 수 있다.

 

그리고 이 단순한 접근 방식이 한계에 부딪혀 어떻게 망가는지 살펴보면, 이 문제를 어떻게 해결해야 하는지 깊은 통찰을 얻을 수 있다.

 

 

Context(문맥)

모든 API 호출에는 컨텍스트 윈도우가 존재하며 이것은 기본적으로 모델이 답변을 생성할 때 읽을 수 있는 제한된 텍스트 조각을 의미한다.

여기에는 시스템 프롬프트, 사용자의 현재 메시지, 그리고 개발자가 그곳에 배치한 다른 모든 텍스트 데이터가 포함된다.

 

모델은 이 컨텍스트 윈도우 내부의 컨텐츠는 완벽하게 볼 수 있지만 윈도우 밖에 있는 것은 아예 다른 장치에 있는 것이나 다름없을 정도로 전혀 인지하지 못한다.

 

 

메모리 문제를 해결하는 가장 뻔하고 단순한 접근 방식은 매 호출마다 전체 대화 기록을 컨텍스트 윈도우에 밀어 넣는 것이다.

이 방식은 채팅의 처음 몇 번 동안은 꽤 잘 작동할 수 있다.

 

하지만 대화가 길어지면 다음과 같은 3가지 문제가 발생하기 시작한다.

 

1. 비용(Cost)
   • 컨텍스트 윈도우 안의 모든 토큰은 호출할 때마다 금전적인 비용과 지연 시간 비용을 모두 지불해야 하므로, 대화가 선형적으로 늘어나면 금액도 똑같이 선형적으로 늘어난다.
   • 대략 80번째 메시지에 도달할 때쯤이면 시스템은 단지 대화의 연속성을 유지하겠다는 이유 하나만으로 매 턴마다 수만 개의 토큰을 반복해서 다시 전송해야 할 수 있다.
2. 지연 시간(Latency)
   • 컨텍스트 윈도우가 커질수록 이를 처리하는 데 더 오랜 시간이 걸린다
   • 짧은 프롬프트에서는 2초 만에 응답하는 모델이 윈도우를 꽉 채운 프롬프트에서는 응답하는 데 10초 또는 15초까지 걸릴 수 있다.
3. 중간 누락(Lost-in-the-middle)
   • 긴 컨텍스트 안에서는 모델의 집중력이 떨어진다.
   • 긴 프롬프트의 중간에 위치한 정보는 처음이나 끝에 위치한 정보보다 모델이 제대로 기억해 낼 확률이 훨씬 낮아진다.
   • 이를 Lost-in-the-middle 효과라고 부른다.

 

 

최근 트렌드 처럼 컨텍스트 윈도우 크기 자체가 커지면 메모리 문제가 완벽히 해결될 것처럼 느낀다

하지만 실제로 정보를 담아두는 공간만 키웠을 뿐, 그 방 안에서 원하는 정보를 찾아내는 탐색 문제는 해결하지 못한채 그대로 남겨두는 꼴이다.

즉, 아무리 중요한 정보가 윈도우 내부에 있어도 모델이 이를 무시하고 지나칠 수 있다는 의미이다.

 

결과적으로 단순히 큰 컨텍스트 윈도우를 쓰는 것만으로 이 문제를 해결할 수 없으며 우리에게 가장 필요한 것은 주어진 그 순간에 정확히 어떤 정보가 윈도우 안에 들어가야 하는지 결정해주는 아키텍쳐이다.

 

Hierarchy(계층)

실제 상용 서비스 시스템은 메모리를 여러 계층으로 구성하며 각 계층은 접근 속도, 전체 용량, 토큰당 비용 간의 트레이드 오프 관계를 가진다.

 

컨텍스트 창(Content Window)가 맨 위에 위치하며, 그 아래로 내려갈수록 점차 속도는 느려지지만 용량이 더 크고 비용이 저렴한 저장소들이 배치된다.

 

이는 운영체제(OS)의 메모리 구조와 매우 비슷하다.

 

현대의 에이전트 메모리 시스템은 운영체제가 빠른 RAM과 느린 디스크 사이에서 데이터를 페이징하는 방식에서 많은 영감을 얻었으며, 정보의 관련성이 오르고 내림에 따라 이를 상위 계층으로 승격 시키거나 하위 계층으로 강등시킨다.

 

전형적인 4계층 구조는 맨 위의 컨텍스트 창에서부터 시작한다.

 

1. 컨텍스트 윈도우
   • 처리 속도가 매우 빠르고 용량이 제한되어 있으며 대규모로 사용할 때 토큰당 비용이 비싸다.
2. 세션 메모리
   • 요약되거나 제거되지 않은 최근의 활동 기록을 보관한다.
3. 장기 저장소
   • 영구적인 사실(facts), 임베딩(Embeddings), 그리고 구조화된 요약본들이 여러 세션에 걸쳐 유지된다.
4. 콜드 아카이브
   • 감사나 향후 참조를 위해 보관하는, 거의 접근하지 않는 자료를 저장한다.

 

 

위로 갈수록 속도는 빨라지고 메모리의 크기는 줄어든다.

 

 

OS 시스템과 마찬가지로 Register가 가장 빠르지만 크기는 작다.

 

에이전트가 작동함에 따라 정보는 이 계층 구조를 따라 위아래로 이동한다. 예를 들어 세 세션 전에 언급된 사실은 장기 저장소에 있을 수 있지만, 현재 맥락과 관련이 생기는 순간 시스템이 이를 검색하여 컨텍스트 창으로 다시 승격시킨다.

 

반대로 세션이 종료되면, 컨텍스트 창에서 가장 유용한 부분들이 요약되어 하위 계층으로 저장된다.

 

챗GPT의 메모리 기능은 해당 개념의 단순화된 버전을 사용한다.

 

저장된 사용자의 개인 정보(Facts)와 최근 대화의 요약본이 매번 새로운 프롬프트 앞부분에 추가되며 현재 진행중인 세션은 활성화된 작업 계층을 차지하게 된다.

 

챗 GPT 시스템은 읽기 시점의 복잡한 검색 기술보다는, 애초에 어떤 정보를 장기 메모리로 승격시킬지 결정하는 판단 기준에 있다.

 

계층 구조는 기억이 어디에 존재하는지를 설명해 준다.

 

우리가 어떤 종류의 기억을 저장하고 있는가는 전혀 별개의 문제이며 이는 다른 축을 따라 분류된다.

 

Types(종류)

이 분야는 cognitive science 개념을 언어 모델 에이전트에 맞게 변형하여, 에이전트 메모리를 크게 4가지 기능적 범주로 정했다.

 

1. Working memory
   
   1. 현재 수행 중인 작업을 위해 활성화된 컨텍스트 창에 머무르는 모든 정보를 보유한다.
   2. ex) 에이전트가 지금 당장 우리가 작성한 함수의 디버깅을 돕고 있다면, 해당 함수의 소스 코드와 최근 주고받은 메시지들이 바로 이 작업 메모리를 차지하게 된다.
   3. 그리고 이 작업이 끝나는 순간 작업 메모리는 비워진다.
2. Episodic memory
   • 시간 순서로 고정된, 과거의 구체적인 상호작용 기록들을 보유한다.
   • ex) 사흘 전, 이 사용자가 신규 엔지니어 온보딩에 대해 물어보았고, 우리는 체크리스트 템플릿에 대해 논의했다와 같은 문장이 일화 메모리의 대표적인 예시이며 특정 사건을 당시 맥락과 함께 그대로 포착한다.
3. Semantic memory
   • 특정 상호작용이나 대화 맥락으로 독립적으로 존재하는 순수한 사실과 지식을 저장한다.
   • ex) 아담은 자바스크립트보다 파이썬을 선호한다라거나 그 팀은 CI를 위해 깃허브 액션을 사용한다와 같은 진술이 의미 메모리로 기능한다. 이 기억들은 세선이 바뀌어도 살아남으며, 관련된 맥락이 생기면 어디에서나 적용된다.
4. Procedural memory
   • 절차 메모리는 일을 처리하는 과정에 학습된 방식이나 노하우를 포착한다.
   • ex) 에이전트가 이 사용자는 업무 보고를 할 때 3개의 섹션으로 구성된 형식을 선호한다는 점을 파악했다면 그 선호도가 절차 메모리가 된다. 그래서 다음에 사용자가 업무 보고를 요청하면 에이전트는 별도의 지시가 없어도 그 형식을 자동으로 적용한다.

 

이 4가지 유형은 계층 구조와 서로 독립적이다.

 

마치 데이터의 물리적 저장 위치와 데이터의 포맷이 서로 다른 축인 것과 같은 이치이다.

 

예시로 의미 메모리의 한 조각이 물리적으로 하위 계층인 장기 저장소에 저장되어 있다가, 관련성이 생기는 순간 최상위 계층인 컨텍스트 창으로 끌어올려질 수 있다.

 

실제 서비스 환경의 에이전트들은 대부분 이 유형 중 최소한 세 가지 이상을 구현하며, 그 조합 비율은 에이전트가 어떤 목적으로 빌드되었는지에 따라 달라진다.

 

예시로 고객 응대 에이전트는 과거 상담 이력과 고객 정보에 크게 의존하는 반면, 코딩 에이전트는 개발 스타일이나 빌드 방식에 더 많이 의존한다.

 

즉 어떤 기억들을 어떻게 섞을지 적절한 혼합 비율은 고정된 공식이 있는 것이 아닌 시스템 아키텍쳐의 디자인 선택이다.

 

Retrieval(검색)

사용자 input에 대한 내용을 바탕으로 생성된 정보를 저장하는 것은 쉬운 문제이다. (특정 db에 기록하거나 벡터 저장소에 인덱싱 하는 작업)은 이미 잘 작성된 툴이기 때문이다.

 

하지만 어려운 부분은 검색하는 부분이며 대화가 한 턴씩 진행될때마다 모델이 어떤것을 떠올리고 인지해야 하는지 결정하는 것이다.

 

 

해당 다이어그램에서 유저가 메시지를 보낼때마다 항상 실행되는 구조이다.

 

사용자가 메시지를 보내면 시스템은 keyword search, semantic similarity, recency signals를 종합해서 각 메모리 계층에서 관련 있는 항목들을 검색한다.

시스템은 의도적인 순서로 컨텍스트 윈도우를 조립하는데 모델의 집중도가 강력하게 높은 시작 부분과 끝 부분에 가장 중요한 자료를 배치한다.

모델이 동작해서 답변을 하게 되면 시스템은 주고받은 대화의 일부를 다시 메모리에 저장합니다. 보통 요약본 형태로 이루어지며, 가끔 시간이 지남에 따라 중요도가 흐려지도록 감쇠 점수를 부여한다.

 

• Semantic Similarity
  • 사용자의 질문과 뜻이 통하는 기억을 찾는 방식
  • 사용자가 새로운 메시지를 보내면 그 메시지를 고차원의 벡터로 변환하여 코사인 유사도를 통해 의미가 유사한 후보군을 뽑아낸다.
• Keyword Search
  • 현재 질문에 포함된 단어가 과거 메모리에 그대로 들어있는지 매칭 점수를 매겨서 후보군을 뽑아낸다.
• Recency signals
  • 데이터베이스 쿼리 단에서 시간 조건을 걸어서 최근에 나눴던 대화 이력만 가져오거나 하는 시간 데이터 자체를 검색의 인덱스로 사용해서 후보군을 뽑아내는 방식

 

검색이 왜 중요한지 알아보기 위해 2가지 상황을 가정하자

 

1. 과거에 나눈 모든 상호작용 데이터가 완벽하게 저장된 데이터베이스를 가지고 있지만 이와 쌍을 가진 retrieval 시스템은 엉뚱한 기록을 골라낸다.

 

2. 기억 저장소가 완전히 비어 있어서 현재 세션(현재 나누고 있는 대화)에서 사용자가 말해주는 정보에 의존해 작동한다.

 

두번째 에이전트가 종종 첫번째 에이전트보다 성능이 잘나온다 왜냐하면 두번째는 자신이 신뢰할 수 있는 정보와 한계(범위)를 명확히 이해하지만 첫번째는 이미 지난 정보나 전혀 상관없는 정보를 자신 있게 끄집어내서 사실인것 처럼 추론을 쌓아 나간다.

 

즉 서비스 환경에서 메모리의 오류는 대부분 retrieval 실패가 메모리 오류인척 위장하고 있는 것이다.

 

 

Tradeoffs

메모리 아키텍쳐는 엔지니어링 팀이 신중하게 조율해야 하는 여러 트레이드 오프를 포함한다 그중 4가지를 한번 살펴보자

 

1. 최신성 vs 관련성
   • 메모리에서 가장 최근의 항목을 가져와야 할지, 의미론적으로 유사한것을 가져와야할지이다.
   • 대부분 시스템은 두 가지를 모두 수행하며 두 가지 신호를 적절히 섞는 것은 현재 엔지니어링 난제이다.
   • 최신성에 치우치면 에이전트가 과거의 유용한 컨텍스트를 잊어버리게 되고, 반대로 관련성에 치우치면 지난 정보에 집착하게 된다.
2. 요약 vs 충실도
   • 오래된 컨텍스트를 압축하면 토큰이 절약되므로 비용이 훨씬 저렴해지고 처리 속도도 빨라진다.
   • but 이러한 압축은 데이터 손실이 발생하는 손실 압축이며, 손실은 균일하지 않게 발생한다.
   • 요약과정에서 이름, 날짜, 구체적인 약속 같은 세부 디테일은 자연스럽게 사라지는 반면 대략적인 핵심 주제나 맥락만 살아남는다.
   • 세부정보가 사라진 후에도 에이전트는 자신감있게 답변을 작성한다.
3. 정보의 오래됨
   • 6개월 전에 진실이였던 사실이, 오늘날에는 오답이 될 수 있다.
   • ex) 2024년에 에이전트에게 나 채식주의자야라고 말했던 사용자가 2026년인 지금은 다시 육식을 할 수 있다.
   • 메모리 시스템은 세상이 변했다는 것을 추측할 만한 아주 단순하고 무딘 휴리스틱밖에 없기에 과거의 오래된 사실을 여전히 신뢰하며 모델에 계속 제공하게 된다.
   • 이처럼 현재 질문과는 관련성이 높지만 이미 오래된 기억을 어떻게 처리할 것인지에 대한 문제는 연구 과제로 남겨졌다.
4. 메모리 오염
   • 장기기억은 장기적인 공격 경로가 될 수 있다.
   • 메모리를 유용하게 만드는 특성인 영속성이 저장된 내용이 잘못되었거나 적대적일 때는 오히려 시스템을 위험하게 만들 수 있다.

 

메모리 시스템은 에이전트가 여러 세션에 걸쳐 연속성을 유지해야 하거나, 맥락이 겹겹히 쌓이는 장기적인 과제를 수행할때 설계할 가치가 있다.