AI 에이전트 메모리와 상태 관리

이 Verified Node Spotlight는 오픈소스 에이전트 메모리 플랫폼인 Cognee의 FDE 책임자인 Veljko Kovac가 작성한 게스트 पोस्ट입니다.

모든 LLM 호출은 0에서 시작한다

LLM은 고유한 기억을 갖고 있지 않습니다. 각 요청은 독립적입니다. 모델은 프롬프트를 읽고 응답을 반환한 뒤, 아무것도 남기지 않습니다. 두 번째 요청을 보내도, 모델이 아는 한 첫 번째 요청은 존재하지 않았던 일입니다.

한 번만 묻는 질문에는 이것으로 충분합니다. 하지만 시간이 지나며 계속 동작해야 하는 무언가를 만들기 시작하는 순간 문제가 생깁니다. 예를 들어 후속 질문을 처리하는 고객 지원 에이전트, 갱신 통화를 준비하는 영업 어시스턴트, 또는 매시간 실행되며 지난번에 무엇을 했는지 알아야 하는 워크플로입니다. 이런 시스템에는 상태가 필요하지만, 모델은 그 상태를 대신 보관할 수 없습니다.

그래서 사람들이 LLM 메모리가 어떻게 작동하냐고 물으면, 정직한 답은 메모리가 모델 밖에 있다는 것입니다. 에이전트는 배운 내용을 다른 곳에 저장하고, 각 호출 전에 관련된 부분을 다시 가져와 프롬프트에 넣습니다. 이 외부 계층을 우리는 AI agent memory라고 부르며, 이를 어떻게 설계하느냐에 따라 에이전트가 중요한 것을 기억할지, 아니면 불필요한 정보에 파묻힐지가 결정됩니다.

이 글에서는 그 계층이 어떻게 동작하는지, 이를 구성하는 주요 방식은 무엇인지, 그리고 이를 n8n에서 어떻게 활용하는지 설명합니다. 워크플로가 조회할 수 있는 공유된 “회사 두뇌”로 쓰는 방법과, 단일 에이전틱 워크플로 내부의 메모리로 쓰는 방법 모두를 다룹니다.

단기 기억과 장기 기억

에이전트 메모리는 보통 두 가지 시간 축에서 작동하며, 흔히 두 개의 별도 구성 요소로 만들어집니다.

단기 기억은 지금 당장 일어나고 있는 일을 추적합니다. 최근 메시지, 중간 추론 과정, 도구 출력, 작업 상태 등이 여기에 해당합니다. 보통 에이전트에 가까운 곳, 종종 하니스 자체 안에 있습니다. 컨텍스트 창이 가득 차면, 흔한 방법은 지금까지의 대화를 요약해서 그 요약을 다시 넣는 것입니다. 이는 한계가 드러날 때까지는 잘 작동합니다. 요약은 세부 정보를 잃어버리고, 어떤 출력은 아예 압축하면 안 되기 때문입니다. 예를 들어 중간 초안이나 비용이 큰 계산의 결과가 그렇습니다.

장기 기억은 세션을 넘어서도 유지됩니다. 사용자 선호, 과거 작업의 결과, 무엇이 효과가 있었는지에 대한 교훈, 그리고 점점 더 자주, 에이전트가 스스로 생성하지 않은 회사 지식까지 담습니다. 문서, 티켓, CRM 기록이 여기에 해당합니다. 무엇을 보관할지, 어떻게 정리할지, 각 요청마다 무엇을 다시 가져올지 결정해야 하므로, 이것은 거의 항상 처음부터 전용 외부 계층이 필요합니다.

어느 쪽이든 전달 메커니즘은 바뀌지 않습니다. 모델은 여전히 하나의 프롬프트만 받습니다. 메모리는 그 프롬프트를 어떻게 구성하느냐를 바꿀 뿐입니다. 새 사용자 메시지에, 현재 세션의 진행 상황에, 그리고 지금 이 순간 관련 있는 장기 기억을 더해 프롬프트를 만듭니다.

LLM 메모리, 컨텍스트, RAG, 에이전트 메모리: 차이가 무엇일까?

이 네 용어는 서로 바꿔 쓰이곤 하지만, 지식이 존재할 수 있는 서로 다른 위치를 설명합니다. 실제 시스템은 종종 이 모든 것을 함께 사용합니다.

엄밀한 의미의 LLM 메모리는 모델이 학습 과정에서 흡수한 것입니다. 이는 압축된 패턴이지 조회 테이블이 아니므로, 모델이 오래된 정보를 자신 있게 되풀이할 수 있습니다. 파인튜닝으로 도메인 지식을 추가할 수는 있지만, 느리고 비싸며 검토하기 어렵고, 살아 있는 세션에서 생긴 내용을 담을 수는 없습니다.

컨텍스트 엔지니어링은 이번 호출을 위해 컨텍스트 창에 무엇을 넣을지 정하는 것입니다. 더 큰 창은 도움이 되지만, 그것만으로 메모리 문제가 해결되지는 않습니다. 세션이 끝나면 컨텍스트는 사라지고, 긴 프롬프트는 비용이 더 들며, 모델은 아주 긴 입력의 모든 부분에 똑같이 주의를 기울이지 않습니다.

RAG는 기존 지식 원천(문서, 데이터베이스, API)에서 정보를 가져와 그 결과를 프롬프트에 추가합니다. 핵심적인 한계는 방향성입니다. RAG는 읽을 뿐, 다시 써 넣지는 않습니다. 사용자가 지난주에 무엇을 물었는지나 어떤 수정이 이미 실패했는지는 기억하지 못합니다.

Agent memory는 에이전트가 기록을 남기기 시작하는 지점에서 시작합니다. 이는 작업을 진행하면서 새 사실, 선호도, 결과를 저장하고, 나중에 다시 불러옵니다. 예를 들어, 판매 도우미가 RAG를 통해 이번 분기의 수치를 가져오면서도, 이 사용자가 EU 수치를 국가별로 나누어 유로로 보고 싶어 한다는 사실을 이전 대화에서 기억하고 있는 모습을 떠올려 보세요.

에이전트 메모리는 실제로 어떻게 작동하나

높은 수준에서 보면, 어떤 메모리 시스템이든 세 가지 요소가 필요합니다. 기억이 영구 저장되는 데이터 저장소, 무엇을 어떤 방식으로 저장할지 결정하는 쓰기 로직, 그리고 에이전트가 관련 기억을 찾을 수 있게 해 주는 검색 인터페이스입니다. 선택한 저장소는 나머지 두 요소에 큰 영향을 미칩니다. 어떤 쓰기 로직이 타당한지, 그리고 검색이 무엇을 할 수 있는지를 좌우하기 때문입니다. 따라서 여기서는 저장소 유형별로 주요 아키텍처를 살펴보겠습니다.

벡터 데이터베이스. 기억은 임베딩으로 변환되어 의미적 유사성을 기준으로 찾습니다. 설정이 쉽고 지원도 잘 되어 있지만, 유사성이 전부는 아닙니다. "Q3 sales"와 "Q4 sales"는 벡터 공간에서 거의 겹쳐 보이고, 어떤 사실이 현재인지에 대한 개념이 없으며, 관련은 있지만 표현이 다른 항목은 완전히 놓칠 수 있습니다.

일반 파일. 에이전트가 읽고 편집하는 MEMORY.md(또는 이와 유사한 파일)를 유지합니다. 코딩 에이전트들이 이를 대중화했습니다. 투명하고 버전 관리가 가능하지만, 검색은 전부를 불러오거나 grep 하는 수준으로 제한되며, 여러 에이전트가 하나의 파일을 공유하면 금세 복잡해집니다.

지식 그래프. 사실은 엔터티와 관계가 됩니다. 판매 보고서는 EU 거래를 포함하고 있고, EU 거래는 유로로 처리되며, 수치는 청구 내보내기에서 나옵니다. 검색은 진입점을 찾은 뒤 간선을 따라가므로, 에이전트는 질문과 논리적으로 관련된 사실을 얻지, 단지 비슷하게 들리는 것만 얻는 것이 아닙니다. 대신 수집 시점의 작업량이 더 많다는 점이 단점입니다.

하이브리드 시스템. 실제로는 하나의 저장소만으로는 모든 것을 커버할 수 없습니다. 정확한 ID는 구조화된 인덱스가 필요하고, 관계는 그래프가 필요하며, 애매한 일치는 벡터가 필요하고, "지난 3월에 고객이 무엇을 선호했지?" 같은 질문에는 타임스탬프가 필요합니다. 운영 환경의 메모리 계층은 여러 저장소를 결합하고, 무엇을 어디에 둘지 결정하는 로직을 그 위에 얹습니다. 이것이 메모리 계층이 데이터베이스 이상인 이유이기도 합니다. 저장소는 단지 데이터가 머무는 곳일 뿐이고, 메모리 계층은 그 위에 자리합니다. 무엇을 어떤 형태로 저장할지 결정하고, 에이전트가 쓰기, 검색, 업데이트, 삭제를 수행하는 데 사용하는 작업을 제공합니다.

메모리는 단순히 쌓기만 해서는 안 되고, 관리되어야 한다

쌓이기만 하는 메모리 계층은 시간이 지날수록 더 나빠집니다. 사실은 변하고, 선호도는 바뀌며, 오래된 항목은 올바른 항목과 경쟁하기 시작합니다. 좋은 메모리 시스템은 저장 위에 여러 과정을 처리합니다. 핵심 세 가지는 다음과 같습니다.

• 통합. 원시 항목은 유용해지기 훨씬 전에 계속 쌓입니다. 시스템은 정기적으로 이를 더 적고 더 높은 수준의 기록(요약, 도출된 사실)으로 바꾸되, 원본으로 되돌아갈 수 있는 흔적은 유지해야 합니다.
• 업데이트. 사실이 바뀌면 무턱대고 덮어쓰는 방식은 이력을 잃게 만듭니다. 무엇이 이전에 참이었는지, 그리고 언제 바뀌었는지 말입니다. 사실에 시간 정보를 유지하면 에이전트는 "지금은 무엇이 참인가?"와 "3월에는 무엇을 믿고 있었는가?" दोनों에 답할 수 있습니다.
• 망각. 일부 데이터는 없어져야 합니다. 오래된 데이터셋, 수정 사항, 삭제 요청 등이 그렇습니다. 이는 덜 유용한 기억이 서서히 중요도를 잃게 두는 부드러운 작업과는 별개로, 명시적이고 의도적인 작업이어야 합니다.

가장 좋은 시스템은 사용으로부터도 학습합니다. 어떤 답이 확인되면 그 답을 뒷받침한 기억의 가중치가 올라가고, 수정되면 오해를 낳은 기억의 가중치는 내려갑니다. 몇 주가 지나면 검색은 더 예리해져야지, 더 산만해져서는 안 됩니다.

메모리가 제대로 작동하는지 어떻게 알 수 있나?

공개 벤치마크는 유용한 첫 신호를 제공합니다. 대부분은 같은 두 단계 패턴을 따릅니다. 먼저 긴 이력을 메모리 시스템에 넣고, 그다음에는 나중에 업데이트되었거나 반박된 것까지 포함해 올바른 사실을 저장하고 검색해야만 답할 수 있는 질문을 던집니다.

크기는 사람들이 예상하는 것보다 더 중요합니다. 벤치마크의 전체 이력이 현대적인 컨텍스트 윈도우에 들어간다면, 메모리를 완전히 건너뛰고 모든 것을 프롬프트에 붙여 넣을 수 있으므로, 이 테스트는 메모리보다 모델에 대해 더 많은 것을 말해 줍니다. 그렇다고 모델이 완벽하게 답한다는 뜻은 아닙니다. 모델은 긴 컨텍스트를 고르게 활용하지 않으며, 긴 프롬프트의 중간에 묻힌 세부 사항은 덜 주의를 받을 수 있습니다. LoCoMo 대화는 대략 26k 토큰 규모이고, LongMemEval의 일반적인 변형은 약 115k입니다. BEAM은 셋 중 가장 까다로운 벤치마크로, 최대 10M 토큰의 대화에서 10가지 메모리 능력을 테스트합니다. 즉, 이때는 외부 메모리가 실제로 일을 해야 합니다. BEAM에서 보고된 최고 성능은 100K 토큰에서 79%, 10M에서 67%이며, Cognee가 설정했습니다. 이전 최고 기록인 73.4%와 64.1%에서 올라간 수치입니다.

하지만 벤치마크는 주로 최종 답변만 확인합니다. 실제로 메모리가 무엇을 저장했는지, 몇 주에 걸친 업데이트 이후에도 얼마나 잘 유지되는지, 여러 에이전트가 함께 사용할 때 어떻게 동작하는지는 보지 않습니다. 각 벤치마크가 무엇을 측정하고 어디가 부족한지 전체 지도를 보려면 AI 메모리 벤치마크 가이드를 참고하세요.

가장 중요한 테스트는 여러분 자신의 테스트입니다. 메모리를 켠 상태와 끈 상태로 같은 워크플로를 실행하고, 해결된 티켓 수, 반복 질문 감소, 올바른 후속 응답 같은 여러분이 중요하게 여기는 결과를 측정하세요.

n8n 워크플로에 메모리 추가하기

n8n 워크플로는 LLM과 한 가지 특성을 공유합니다. 기본적으로 각 실행은 새로 시작된다는 점입니다. 그래서 월요일에 수정안을 작성한 지원 워크플로도 수요일에 후속 문의가 오면 그 내용을 자동으로 알지 못합니다. 많은 팀이 이를 Postgres 테이블이나 Airtable base로 처리하는데, 이는 잘 작동하지만 각 워크플로마다 별도의 저장소 설정과 무엇을 보관할지에 대한 자체 규칙이 필요합니다.

1. 모든 워크플로를 위한 공유 두뇌

가장 단순한 형태에서 메모리는 어떤 워크플로든 마지막 실행이 끝난 지점부터 이어서 작업하게 해 줍니다. 하나의 노드는 워크플로가 배운 내용을 저장하고, 다른 노드는 다음 실행 때 그것을 조회합니다. 그리고 메모리가 단일 워크플로 바깥에 존재하므로, 여러 워크플로가 이를 공유할 수 있습니다.

가장 큰 효과는 중앙 집중식 "두뇌"입니다. 모든 워크플로가 읽고 쓰는 하나의 공유 메모리입니다. 이를 회사 전체로 확장하면 "회사 두뇌"가 됩니다. 회사 전반에 이미 가장 유용한 맥락이 흩어져 있습니다. Slack 스레드, 티켓, 문서, CRM 메모, 통화 녹취록 등이 그것입니다. n8n은 이런 모든 도구에서 그 정보를 수집할 수 있고, 메모리 계층은 이를 구조화하고 서로 연결할 수 있으므로, 모든 워크플로가 회사가 알고 있는 것에 대한 동일한 그림을 바탕으로 동작하게 됩니다.

패턴은 간단합니다:

• 수집 워크플로는 n8n의 트리거와 앱 통합을 사용해, 닫힌 티켓, 통화 요약, 양식 제출 같은 새 자료가 나타나는 즉시 이를 가져와 메모리 계층으로 보내고, 메모리 계층은 이를 구조화하고 연결합니다.
• 행동 워크플로는 답장을 작성하거나, 에스컬레이션을 라우팅하거나, 영업 브리프를 준비하기 직전에 같은 메모리를 조회합니다. 이들은 "Acme의 현재 상태는 무엇이고, 우리는 그들에게 무엇을 약속했나요?"처럼 평이한 영어로 질문할 수 있고, 그 답을 다음 노드로 넘길 수 있습니다.

양쪽이 같은 메모리를 가리키기 때문에, 워크플로는 구현 세부 사항을 공유하지 않으면서도 맥락을 공유합니다. 그리고 메모리가 엔티티 간 관계를 유지하면, 행동 워크플로는 단순한 유사도 검색으로는 놓칠 수 있는, 예를 들어 다음 분기에 만료되는 계약이 무엇인지 또는 어떤 계정들이 같은 근본 원인을 공유하는지 같은 연결된 답변을 얻을 수 있습니다.

2. 에이전트 워크플로 안의 메모리

두 번째 패턴은 하나의 n8n AI Agent 내부에 있으며, 앞서 설명한 단기 기억과 장기 기억의 분리에 대응합니다. 메모리가 없으면 에이전트가 받는 모든 메시지는 0부터 시작합니다. n8n은 AI Agent의 Memory 포트를 통해 단기 기억을 처리합니다. n8n의 기본값인 "Simple Memory"는 현재 세션의 채팅 기록 중 사용자 지정 가능한 길이를 저장하며, 시작하기 가장 쉬운 방법입니다. 아래와 같이 이 기본값을 그대로 사용하거나, 더 고급인 서드파티 메모리 제공자를 선택할 수 있습니다:

하지만 채팅 메모리는 대화만 기억합니다. 사용자 선호도, 과거 작업의 결과, 회사 컨텍스트 같은 장기 지식은 채팅 로그만으로는 부족합니다. 이를 위해 메모리 레이어를 Agent의 Tool 포트에 연결하세요. 여기에 에이전트가 추가 컨텍스트나 리소스에 접근하는 데 사용할 수 있는 애드온을 연결합니다. 그러면 에이전트는 무엇을 새로 기억해야 하는지, 그리고 회사가 이미 알고 있는 것을 언제 검색해야 하는지 스스로 판단할 수 있습니다. 그 결과 현재 대화의 흐름을 유지하면서도 작업 도중에 공유된 회사 지식에 접근할 수 있는 에이전트가 됩니다.

간단히 말해, n8n의 내장 메모리는 단일 채팅 에이전트를 위한 좋은 출발점입니다. 하지만 시간이 지나며 발전하고 워크플로와 에이전트 전반에 공유되는 메모리가 필요하다면, 이를 메모리 레이어와 결합하세요. 대화 중인 내용은 채팅 메모리에 저장하고, 공유 메모리는 회사가 이미 알고 있는 것에서 출발하게 만들어 매번 새로 시작하지 않도록 합니다.

결론

LLM은 호출할 때마다 처음부터 시작하므로, 시간이 지나도 안정적으로 작동하는 AI 에이전트를 만들려면 모델 바깥의 메모리가 필요합니다. 하지만 정보를 저장하는 것만으로는 절반에 불과합니다. 에이전트는 작업과 워크플로 전반에서 올바른 컨텍스트를 포착하고, 검색하고, 이에 맞게 행동할 수 있는 방법도 필요합니다.

n8n과 Cognee는 이 문제를 함께 해결합니다. n8n은 앱을 연결하고, AI 에이전트를 오케스트레이션하며, 시스템 간 정보 흐름을 자동화합니다. Cognee는 그 정보를 에이전트가 검색하고, 업데이트하고, 공유할 수 있는 구조화된 영속 메모리로 바꿉니다.

이 둘을 함께 사용하면, 단순히 작업을 개별적으로 실행하는 데 그치지 않고 이전 상호작용에서 학습하고, 세션 간 컨텍스트를 유지하며, 회사 지식에 대한 공유된 이해를 바탕으로 동작하는 AI 워크플로를 구축할 수 있습니다.

장기 기억을 가진 AI 에이전트를 만들 준비가 되셨나요? n8n으로 시작하기와 Cognee 연결하기를 통해 워크플로에 공유 메모리 레이어를 더해 보세요.

출처

• 원문: https://blog.n8n.io/ai-agent-memory-how-llm-agents-manage-state-in-production/ (2026-10-23 · n8n team)