왜 AI 에이전트는 세션 사이에 내용을 잊어버릴까요?

기본적으로 대부분의 에이전트는 애초에 메모리(Memory)가 없기 때문입니다. 에이전트가 대화 중간에 "알게 되는" 모든 것은 전적으로 컨텍스트 윈도우 (Context Window) 내에 존재하며, 컨텍스트 윈도우는 세션이 종료되는 순간 비워집니다. 첫날에는 매우 영리해 보였던 데모가 둘째 날에 정확히 똑같은 온보딩 (Onboarding) 질문을 던질 수 있는데, 이는 모델의 성능이 저하되어서가 아니라 이전 세션에 대한 그 어떤 것도 세션 이후까지 살아남도록 설계되지 않았기 때문입니다. 훌륭한 데모에서 메모리처럼 보이는 것은 대개 길고 비용이 많이 드는 프롬프트 (Prompt)일 뿐입니다.

이것은 특정 도구만의 결함이 아닙니다. 이는 지금까지 대부분의 에이전트가 구축되어 온 방식의 구조적 격차이며, 인상적인 데모와 팀이 실제로 의존할 수 있는 시스템을 구분 짓는 요소입니다.

더 큰 컨텍스트 윈도우가 이 문제를 해결해 주지 않을까요?

그렇지 않습니다. 세 가지 매우 실질적인 이유 때문입니다.

첫 번째는 비용입니다. 매 호출마다 계속해서 늘어나는 히스토리를 다시 보내는 것은 비용이 빠르게 누적됩니다. 두 번째는 관련성입니다. 느슨하게 연결된 방대한 히스토리 더미를 헤매는 모델은 잘못된 정보를 가져오거나 전혀 유용한 것을 찾지 못하는 경향이 있는데, 이러한 패턴은 종종 "컨텍스트 부패 (Context Rot)"라고 불립니다. 그리고 세 번째 이유는 가장 중요한 이유입니다. 큰 컨텍스트 윈도우는 여전히 "작업" 메모리 (Working Memory)입니다. 그것이 아무리 크더라도 세션이 종료되는 순간 사라집니다. 매일 밤 지워지는 화이트보드는 크기가 커진다고 해서 도움이 되지 않습니다.

에이전트에게 실제로 필요한 메모리의 종류는 무엇인가요?

이 문제에 대한 대부분의 진지한 연구는 인간의 기억이 묘사되는 방식과 유사하게, 몇 가지 뚜렷한 계층(Layers)으로 수렴됩니다:

• 작업 기억 (Working memory) — 실시간 컨텍스트 윈도우 (context window). 즉각적이고 빠르며, 세션이 종료되면 사라집니다.
• 일화 기억 (Episodic memory) — 이전 세션에서 일어난 일들: 내린 결정, 주어진 수정 사항, 무엇이 효과적이었고 무엇이 그렇지 않았는지에 대한 내용입니다.
• 의미 기억 (Semantic memory) — 거의 변하지 않는 지속적인 사실과 선호도: 팀의 관례, 고객의 이력, 사용자의 기술 스택 등입니다.
• 절차 기억 (Procedural memory) — 더 조용하지만 아마도 가장 가치 있는 계층: 단순히 무엇을 해야 하는지가 아니라, 팀이 무언가를 수행하는 '방식'에 관한 것입니다. 머지(merge) 전에 어떤 테스트를 실행하는지, 릴리스 노트(release notes)가 어떻게 포맷팅되는지, PR(Pull Request)이 어떻게 구성되는지 등이 여기에 해당합니다.

초기 에이전트 도구 대부분은 첫 번째 계층만을 가지고 있었습니다. 올해 Mem0, Zep, Letta, Cognee 및 몇몇 새로운 진입자들이 주목받고 있는 프레임워크들은 나머지 세 가지 계층을 추가하기 위해 특별히 구축되었습니다.

메모리를 저장하는 것이 어려운 부분일까요, 아니면 다른 무엇일까요?

저장은 쉬운 부분입니다. 대부분의 시스템이 실제로 실패하는 지점은 재사용 (Reuse) 입니다. 즉, 인간이 조용히 수정해 줄 필요 없이 에이전트가 즉시 행동에 옮길 수 있는 형태로, 적절한 순간에 적절한 메모리를 검색해내는 것이 핵심입니다.

벡터 저장소 (Vector store)는 쿼리(query)와 의미적으로 유사한 것이 무엇인지 알려줄 수 있습니다. 하지만 무엇이 여전히 사실인지, 무엇이 오래되어 쓸모없게 되었는지, 혹은 근본적인 사실이 변경되어 무엇을 잊어야 하는지에 대해서는 훨씬 취약합니다. 모든 에이전트가 동일한 공유된 진실의 원천 (shared source of truth)으로부터 정보를 가져오지 않는 한, 하나는 계획하고, 하나는 구축하며, 하나는 검토하는 식으로 여러 에이전트가 루프(loop)에 참여하게 되면 이 문제는 더욱 어려워집니다. 최근 멀티 에이전트 시스템 (multi-agent systems)에 관한 엔지니어링 글들은 이를 명시적으로 계층적 구조로 정의합니다: 컨텍스트 윈도우 (context window) 내의 작업 메모리 (working memory), 세션 기록을 위한 에피소드 메모리 (episodic memory), 그리고 에이전트 팀 전체가 활용할 수 있는 그 아래의 공유된 영구 계층 (shared persistent layer)입니다 (멀티 에이전트 메모리 인프라에 관한 AWS의 글에서 이를 자세히 설명하고 있습니다). 이 공유 계층을 생략하면 각 에이전트는 자신만의 거품 속에서 작동하게 되며, 이는 여러 에이전트를 함께 실행하는 대부분의 이유를 퇴색시킵니다.

왜 이것이 나중이 아니라 지금 시급한 문제가 되고 있는가?

에이전트형 AI (agentic AI)가 틈새 실험에 머물러 있지 않기 때문입니다. Deloitte의 2026년 전망에 따르면, 이미 생성형 AI (generative AI)를 사용 중인 기업의 거의 절반이 2027년까지 에이전트형 AI 파일럿 또는 프로덕션 배포를 실행할 것으로 예상되며, 이는 2025년 수치의 약 두 배에 달합니다 (최근 에이전트 메모리 상태에 관한 연구 요약에서 인용됨). 프로덕션 시스템은 일회성 데모와 달리 기억 상실을 용납하지 않는 사람들에 의해 매일 사용됩니다.

도구(tooling) 측면에서도 이미 이러한 압박이 반영되고 있습니다. 이 분야의 오픈 소스 메모리 플랫폼 중 하나인 Cognee는 파이프라인 볼륨이 단 1년 만에 약 500배 성장하며 100만 회 실행을 돌파했다고 보고했습니다 (에이전트를 위한 지속성 메모리 계층 구축에 관한 그들의 자체 기술 블로그에 상세히 설명됨). 이러한 종류의 채택 곡선은 단순히 '있으면 좋은(nice-to-have)' 기능 때문에 발생하는 것이 아닙니다. 충분히 많은 팀이 동일한 벽에 부딪히고, 동시에 해결책을 찾기 시작할 때 발생합니다.

이는 또한 단순히 독립적인 메모리 라이브러리뿐만 아니라, 전체 빌드 플랫폼(full build platforms)에 대해 사람들이 기대하는 바를 변화시키고 있습니다. 예를 들어, 8080.ai와 같은 플랫폼은 프로젝트가 진화함에 따라 에이전트가 참조할 수 있는 살아있는 시스템 요구사항 문서와 아키텍처 기록을 유지합니다. 이는 매 세션마다 프로젝트 구조를 처음부터 다시 유도하는 대신, 마치 복귀한 엔지니어가 이미 알고 있는 코드베이스를 파악하는 방식에 더 가깝게 작동합니다. 서류상으로는 작은 설계상의 선택처럼 보일 수 있지만, 이는 업계 전반에서 일어나고 있는 동일한 변화를 반영합니다. 즉, 메모리는 사후에 덧붙여지는 것이 아니라, 계획(planning) 및 아키텍처와 함께 처음부터 설계되고 있습니다.

기존 에이전트에 메모리를 사후 장착(retrofitting)하는 것은 실제로 무엇을 의미하는가?

대부분의 팀은 메모리를 처음부터 설계할 여유가 없습니다. 그들은 이미 라이브 상태이고, 이미 사용자가 있으며, 어딘가에 쌓여가는 반구조화된(half-structured) 대화 로그 더미를 가진 에이전트에 메모리를 추가하고 있는 것입니다. 이러한 사후 장착(retrofit)은 상당히 예측 가능한 경로를 따르는 경향이 있습니다.

첫 번째 단계는 보관할 가치가 있는 것과 그렇지 않은 것을 분리하는 것입니다. 세션의 모든 메시지가 장기 기억(long-term memory)이 될 가치가 있는 것은 아닙니다. 대부분은 실제로 중요한 한두 가지 결정 주위를 둘러싼 비계(scaffolding)에 불과합니다. 이 단계를 건너뛰면 그 결과는 기억 상실(amnesia)의 정반대 상황이 됩니다. 즉, 노이즈로 너무 혼잡해진 메모리 저장소 때문에 시스템이 실행될수록 검색(retrieval) 성능이 좋아지는 것이 아니라 오히려 악화되는 것입니다.

두 번째 단계는 "망각 (forgetting)"이 어떤 모습이어야 하는지 결정하는 것입니다. 18개월 전 고객의 배송 주소는 폐기할 가치가 있을 수 있습니다. 지난 분기의 팀 코딩 컨벤션 (coding convention)은 위에 쌓아두는 것이 아니라 덮어쓰여야 할 것입니다. 아무것도 잊지 않는 시스템은 통찰력을 쌓는 것보다 모순을 더 빠르게 축적하는 경향이 있으며, 동일한 사물에 대한 두 가지 모순된 "사실 (facts)"을 조정하라는 요청을 받은 에이전트는 종로 종종 무작위로 하나를 선택하게 되는데, 이는 메모리가 아예 없는 것보다 더 나쁠 수 있습니다.

세 번째 단계는 보통 눈에 보이는 문제가 발생할 때까지 우선순위에서 밀려나곤 합니다. 바로 메모리가 동일한 에이전트의 세션(session) 간뿐만 아니라, 에이전트들 사이에서 어떻게 공유되는가 하는 문제입니다. 계획 에이전트 (planning agent)의 결정은 이를 실행하는 에이전트와 나중에 해당 실행을 검토하는 에이전트 모두에게 보여야 합니다. 그렇지 않으면 에이전트 "팀"은 사실상 병렬적으로 고립되어 작업하는 여러 에이전트에 불과하며, 결과적으로 사람이 일일이 수동으로 조정해야 하는 모순된 출력을 가끔씩 만들어내게 됩니다.

이 모든 것은 생소한 엔지니어링이 아닙니다. 이는 데이터베이스 스키마 (database schema) 대신 언어 모델 (language model)에 의해 구동되는 시스템에 적용된, 무엇이 영구적이고 무엇이 일회용인지, 그리고 누가 무엇을 보아야 하는지를 결정하는 정보 설계 (information architecture)의 지루한 작업에 더 가깝습니다.

메모리 시스템에서 실제로 무엇을 살펴봐야 할까요?

몇 가지 질문이 견고한 설정과 취약한 설정을 구분하는 기준이 됩니다.

• 작업 컨텍스트 (working context)와 영구 메모리 (persistent memory)를 분리하는가, 아니면 그저 메모리라는 라벨을 붙인 더 큰 버퍼 (buffer)에 불과한가?
• 의도적으로 무언가를 잊을 수 있는가? 만료 기간이나 수정 경로가 없는 시스템은 유용한 정보를 쌓는 만큼이나 빠르게 오래된 사실들을 축적합니다.
• 단순한 유사도 검색 (similarity search)을 넘어설 수 있는가? 이력이 길어지면 엔티티 인식 (entity-aware) 및 관계형 검색 (relational retrieval)이 순수 벡터 검색 (vector search)보다 성능이 뛰어난 경향이 있습니다.
• 하나의 에이전트 프레임워크 (agent framework)에 종속되는가, 아니면 나중에 도구를 변경하더라도 메모리 계층 (memory layer)을 그대로 가져갈 수 있는가?

단 하나의 정답은 없습니다. 단일 에이전트를 실행하는지, 아니면 조정된 에이전트 팀을 실행하는지, 그리고 가치가 대화 기록 (conversation history)에 있는지 아니면 축적된 운영 지식 (operational knowledge)에 있는지에 따라 달라집니다. 하지만 이러한 질문을 초기에 던지는 것은 에이전트가 프로덕션 (production)에 투입된 지 6개월이 지난 후에 공백을 발견하는 것보다 훨씬 비용이 적게 듭니다.

지금으로부터 1년 후에도 여전히 유용하게 느껴질 에이전트는 아마도 가장 큰 컨텍스트 윈도우 (context windows)를 가진 에이전트가 아닐 것입니다. 그들은 중요한 것은 조용히 기억하고, 중요하지 않은 것은 잊어버리며, 정확히 멈췄던 지점에서 다시 시작하는 에이전트가 될 것입니다.