n8n 에이전트가 대화를 잊어버리는 이유
Simple Memory는 창(window)이며, 그 창은 매우 작습니다
Simple Memory 노드의 Context Window Length 설정은 포함할 이전 상호작용의 수이며, 기본값은 5입니다. 하나의 상호작용은 사용자의 메시지와 에이전트의 답변으로 구성된 한 번의 대화(exchange)이므로, 기본값은 대략 마지막 10개의 메시지만 유지합니다. 이보다 오래된 내용은 아무런 오류 없이 조용히 창 밖으로 사라집니다. 에이전트는 단지 동일한 대화에서 이전에 일어났던 일을 참조하지 않게 될 뿐이며, 이 때문에 긴 대화는 완전히 끊어지기보다 서서히 품질이 저하됩니다.
워크플로우 데이터에 상주하므로 유지되지 않습니다
Simple Memory는 대화 기록을 세션 키 아래의 워크플로우 자체 데이터에 저장합니다. 이는 에디터에서는 편리하지만 다른 모든 환경에서는 매우 취약합니다. 대화 기록이 인스턴스의 작동 상태에 종속되어 있어 재시작이나 재배포 후에 사라지기 때문입니다. 이는 흔히 발생하는 "개발 환경에서는 잘 작동하는데 배포만 하면 다 잊어버린다"는 문제의 전형적인 원인이며, 라이브 배포 전에 Postgres나 Redis chat memory로 전환하라는 표준 권장 사항이 존재하는 이유이기도 합니다.
큐 모드(Queue mode)에서는 완전히 작동이 중단됩니다
n8n 문서에는 이 제한 사항이 명확히 명시되어 있습니다. 인스턴스가 큐 모드를 사용하는 경우, 메모리 호출이 동일한 워커(worker)로 라우팅된다는 보장이 없기 때문에 활성 프로덕션 워크플로우에서 이 노드가 작동하지 않습니다. n8n을 수평 확장한 후 메모리가 왜 이랬다저랬다 하는지(어떨 때는 기억하고 어떨 때는 잊어버리는지) 궁금했다면 바로 이 메커니즘 때문입니다. 요청이 서로 다른 워커에 도달하고, 각 워커는 이전에 무슨 대화가 오갔는지 서로 다르게 파악하고 있기 때문입니다.
세션 키가 누가 무엇을 기억할지 결정합니다
메모리는 세션 키별로 그룹화됩니다. Chat Trigger를 사용하면 n8n은 들어오는 sessionId로 이를 채우며, 이는 보통 원하는 방식입니다. 하지만 두 가지 흔한 잘못된 설정으로 인해 서로 정반대의 증상이 발생할 수 있습니다:
- 하드코딩된 정적 키를 사용하면 모든 사용자가 하나의 메모리를 공유하게 됩니다. 에이전트가 대화를 혼동하고 사람들 간에 컨텍스트를 유출하게 됩니다.
- 매 실행마다 변경되는 키를 사용하면 모든 메시지가 새로운 대화를 시작하게 됩니다. 기술적으로는 메모리가 작동하고 있음에도 에이전트는 기억상실증에 걸린 것처럼 보입니다.
메모리 범위는 워크플로우별, 에이전트 노드별로 제한됩니다
메모리 노드는 하나의 AI Agent 노드에 연결됩니다. 이는 자동화 전반에서 공유되는 저장소가 아닙니다. 워크플로우 A의 지원 에이전트는 동일한 고객에 대해 워크플로우 B의 온보딩 에이전트가 어제 내린 결론을 전혀 알지 못하며, 두 에이전트 모두 둘을 제어하는 SOP에 팀이 무엇을 작성했는지 알지 못합니다. 여러 에이전트를 실행하는 경우 이러한 파편화는 더욱 심화됩니다. 이 일반적인 문제는 multi-agent memory에서 다루고 있습니다.
팀들이 가장 먼저 시도하는 방법들
Context Window Length 늘리기
가장 확실한 해결책처럼 보이며 일시적으로는 도움이 됩니다. 하지만 호출할 때마다 유지되는 모든 메시지에 대해 비용을 지불해야 하고, 창은 여전히 제한되어 있으며, 여전히 휘발성입니다. 잊어버리는 시점을 늦췄을 뿐, 잊어버리는 현상 자체를 막은 것은 아닙니다.
Postgres 또는 Redis chat memory로 전환하기
이는 프로덕션 환경을 위한 올바른 조치이며 반드시 적용해야 합니다. 대화 기록이 재시작 후에도 유지되고 큐 모드에서도 작동합니다. 하지만 이것이 제공하는 것이 무엇인지 명확히 알아야 합니다. 이는 세션 키를 기반으로 하는 내구성 있는 대화 기록 저장소일 뿐이며, 조직이 알고 있는 지식이 아니라 입력된 텍스트만 보관합니다. 여기에는 제품 문서, 가격 책정 규칙, 지난 분기의 결정 사항, 또는 이 고객이 3월에 접수한 티켓의 해결 결과 등이 포함되어 있지 않습니다. 해당 세션의 메시지 범위를 벗어나는 질문을 하면 아무것도 대답할 수 없습니다.
시스템 프롬프트에 컨텍스트 밀어 넣기
많은 팀이 정책, 톤앤매너 가이드, FAQ를 에이전트의 시스템 메시지에 붙여넣습니다. 실행할 때마다 해당 토큰에 대한 비용을 지불해야 하고, 텍스트는 금방 낡은 정보가 되며, 이를 업데이트하려면 워크플로우를 하나씩 수정해야 합니다. 이는 AI에게 re-explaining context to your AI를 영원히 반복하는 자동화의 비효율적인 방식입니다.
자체 검색(Retrieval) 시스템 구축하기
그 다음 단계는 대개 벡터 저장소, 임베딩 파이프라인, 검색 서브 워크플로우를 결합하는 것입니다. 이는 작동할 수 있지만 청킹, 임베딩 갱신, 랭킹, 범위 지정, 만료 처리 등 상당한 공수가 드는 프로젝트입니다. 또한 why RAG isn't memory에서 읽어볼 만한 가치가 있는 이유들로 인해, 이것만으로는 메모리 문제를 해결할 수 없습니다. 검색은 문서를 찾는 것이고, 메모리는 결론을 기억하는 것이기 때문입니다.
해결책: n8n 에이전트에 영구 메모리 레이어 제공하기
대화 메모리(Chat memory)와 메모리(Memory)는 서로 다른 두 가지 작업입니다. 세션 내 대화의 연속성을 위해서는 Postgres나 Redis 메모리 노드를 유지하고, 영구적인 지식은 워크플로우, 워커, 또는 세션 키에 종속되지 않는 레이어에 배치하세요. 이것이 바로 MemoryLake가 수행하는 역할입니다. 에이전트가 읽고 쓸 수 있는 단 하나의 메모리로, 구축하는 모든 워크플로우에서 MCP 또는 API를 통해 액세스할 수 있습니다.
1단계: API 키 생성하기
키를 생성하고 약 30초 만에 첫 번째 요청을 보내보세요.
2단계: 첫 번째 메모리 업로드하기
제품 문서, SOP, 가격 및 정책 규칙, 에스컬레이션 경로, 이전 해결 사례 등 에이전트에게 지속적으로 필요한 문서, 이미지, 파일을 업로드하세요. 이는 대화 버퍼에 담아둘 성격의 지식이 아닙니다.
3단계: AI 및 에이전트 연결하기
Claude, Codex, OpenClaw 및 n8n 에이전트가 MCP 또는 API를 통해 해당 메모리에 액세스할 수 있도록 하세요. 도구가 지원하는 경우 MCP 연결을 사용하거나, 워크플로우 자체에서 일반 HTTP 요청을 보낼 수 있습니다. 어떤 워커에서 실행되든 모든 실행은 동일한 메모리에 도달합니다. 에이전트에게 자체 도구를 노출하는 경우, adding memory to a custom MCP server 및 memory for stateless MCP servers에서 관련 내용을 다룹니다.
실제 적용 시 변화되는 점
현재 워크플로우가 반복하고 있는 작업을 계산해 보세요. 각 실행마다 붙여넣은 정책 및 제품 컨텍스트 1,500 토큰이 포함되어 있고 워크플로우가 하루에 500번 실행된다면, 절대 변하지 않는 텍스트를 다시 전송하는 데 매일 750,000 토큰(한 달에 약 2,200만 토큰)을 소비하는 셈입니다. 메모리 레이어에서 관련 있는 부분만 검색해 오는 것은 대개 이 비용의 아주 일부만 소요됩니다.
더 큰 이점은 에이전트의 행동 변화입니다. 고객의 이전 티켓을 볼 수 있는 지원 에이전트는 계정 ID를 다시 묻지 않습니다. 지원 에이전트와 동일한 메모리를 읽는 온보딩 에이전트는 서로 모순되는 말을 하지 않습니다. 그리고 다음 분기에 워크플로우를 재구축하더라도, 지식은 삭제된 버전에 갇히지 않고 그대로 유지됩니다.
n8n 에이전트 메모리 모범 사례
대화 기록과 지식을 별도의 장소에 보관하세요
현재 대화의 마지막 몇 차례 대화에는 chat memory 노드를 사용하세요. 내일도 여전히 유효해야 하는 정보에는 메모리 레이어를 사용하세요. 이 둘을 섞으면 읽기에는 너무 방대하면서도 도움이 되기에는 너무 얕은 저장소가 되어 버립니다.
실행이 아닌 엔티티를 기준으로 메모리 키를 지정하세요
세션 키는 대화용입니다. 영구 메모리는 고객, 프로젝트 또는 계정과 같이 여러 워크플로우와 수개월에 걸쳐 동일한 의미를 갖는 대상을 기준으로 키를 지정해야 합니다. 그래야 두 번째 워크플로우가 첫 번째 워크플로우가 멈춘 지점부터 이어서 작업을 진행할 수 있습니다.
실행이 끝날 때 결론을 다시 기록하세요
실행 결과 결정된 사항(해결책, 허용된 예외 사항, 사용자가 밝힌 선호도 등)을 저장하는 마지막 단계를 추가하세요. 메모리를 읽기만 하는 에이전트는 결코 똑똑해지지 않으며, 메모리에 기록하는 에이전트는 지식을 축적해 나갑니다. 기록은 짧고 사실에 기반하여 작성하고, 오래된 사실 위에 새로운 사실을 쌓기보다는 기존 정보를 교체하는 방식을 권장합니다.
결론
n8n 에이전트가 고장 난 것이 아닙니다. Simple Memory는 문서에 명시된 대로 정확히 작동하고 있을 뿐입니다. 즉, 워크플로우 데이터에 몇 개의 최근 대화만 보관하기 때문에 재시작 시 증발하고 프로덕션의 큐 모드에서 작동하지 않는 것입니다. Postgres나 Redis로 전환하면 대화 기록의 내구성은 해결되지만, 더 큰 공백은 그대로 남게 됩니다. 단일 세션의 대화 기록은 비즈니스를 이해하는 것과는 완전히 다르기 때문입니다.
두 가지 작업을 분리하세요. 대화의 연속성은 chat memory 노드의 역할이며, 조직의 지식은 워크플로우가 MCP 또는 API를 통해 읽는 메모리 레이어의 역할입니다. 그렇게 하면 다음에 구축할 에이전트는 5개의 대화 깊이의 빈 창 대신, 이전 에이전트가 학습한 모든 것을 가지고 시작할 수 있습니다.