오늘날 대부분의 에이전트 설정은 전통적인 RAG(Retrieval-Augmented Generation) 방식으로 작동합니다. 질문을 하면, 에이전트는 사용자의 문서를 검색하고, 관련 청크(chunk)를 가져와 답변을 구성합니다.

이 방식은 한 번의 대화에서는 효과적입니다. 하지만 다음에 관련된 것을 물어보면, 동일한 검색을 수행하고, 동일한 청크를 가져오며, 컨텍스트를 다시 '0'부터 재구축합니다.

저는 에이전트가 더 복잡하고 지속적인 프로젝트를 처리하면서 이 패턴이 무너지는 것을 지켜보고 있습니다. 빌더들은 같은 해결책으로 수렴하고 있으며, 이를 위키 메모리(wiki memory)라고 부릅니다.

에이전트가 매번 원시 문서(raw documents)를 기반으로 추론하는 대신, 데이터로부터 작고 구조화된 Markdown 형식의 위키를 만듭니다. 이는 AI가 스스로 작성하고 유지하는 개인 지식 기반이라고 생각할 수 있습니다.

첫 번째 대화를 통해 이 위키가 생성됩니다. 그 이후의 모든 대화는 이를 개선합니다.

사용자의 에이전트는 더 큰 모델 덕분이 아니라, 더 나은 메모리 덕분에 시간이 지남에 따라 특정 컨텍스트에서 더 빠르고 정확해집니다.

아키텍처 작동 방식은 다음과 같습니다.

사용자 소스 데이터(노트, 문서, 연구 자료)는 제자리에 있습니다. 많은 설정에서 MCP 서버가 중간에 위치하여 로직을 처리합니다. 이 서버는 데이터를 검색하고, 위키 페이지를 구축하며, 소스가 변경될 때 동기화하고, 새로운 지식을 영속화합니다.

에이전트는 모든 것을 처음부터 다시 검색하는 대신 위키를 읽습니다.

전통적인 RAG 대비 가장 큰 장점은 '복리 효과(compounding)'입니다. 매 상호작용이 에이전트가 이미 알고 있는 지식에 추가될 뿐, 0으로 초기화되지 않습니다.

또한 전체 데이터셋에 걸친 완전한 지식 그래프가 필요하지 않습니다. 위키는 간단한 파일 참조를 통해 페이지들을 연결하는 경량의 대안 역할을 합니다.

그리고 메모리가 모델 내부에 있는 것이 아니라 위키에 존재하기 때문에, 에이전트가 학습한 내용을 잃지 않고 Claude에서 ChatGPT로, 또는 Codex로 전환할 수 있습니다.

LangChain 공동 창업자인 Harrison Chase는 위키 메모리를 장기적인 에이전트 메모리를 위한 하나의 공통 패턴으로 설명했습니다. 빌더들은 모두 이 방향으로 수렴하고 있습니다.

만약 간단한 질의응답(Q&A) 이상의 용도로 AI 에이전트를 사용한다면, 다음으로 이해할 가치가 있는 메모리 패턴입니다.