에이전트에게 뭔가 유용한 걸 가르칩니다. 그 세션에서는 잘 작동합니다. 그런데 다음번에 다시 시작하면, 에이전트는 또 처음부터 시작합니다.

같은 링크를 다시 보여주고, 같은 PDF를 다시 첨부하고, 같은 메모를 다시 설명하고, “내 스타일과 제약조건을 기억해줘”를 또 반복합니다. AI 엔지니어 Louis Bouchard는 이 반복을 두고 “아주 생산적이다, 정말 2026년답다”고 비꼬았습니다.

Bouchard와 Paul Iusztin이 AI Engineer World’s Fair 온라인 트랙 기조연설에서 짚은 지점은 이렇습니다. 병목은 모델에게 정보를 한 번 주는 게 아니라, 그 정보를 나중에 다시 꺼내 쓰게 만드는 것이라고요.

출처:

• How to Build a Memory Your AI Agents Can Actually Reuse – Louis Bouchard (What’s AI)
• Choosing the Right AI Agent Memory Strategy: A Decision-Tree Approach – MachineLearningMastery

기억해야 할 정보는 한 가지가 아니다

에이전트 메모리를 설계할 때 흔히 저지르는 실수는 모든 정보를 하나의 저장소에 욱여넣는 것입니다. 하지만 “지금 이 대화”와 “사용자가 좋아하는 어조”와 “지난달 접수된 불만”은 서로 다른 성격의 정보입니다. 각각 다른 방식으로 저장되고 꺼내져야 하죠.

이 메모리는 네 종류로 나뉩니다.

1. 작업 메모리 — 지금 이 대화 안에만 존재하면 되는 정보. 이번 턴에서 이미 물어본 것, 이미 호출한 도구 결과가 여기 해당합니다.
2. 의미 메모리 — 이름이나 구독 등급, 선호하는 어조처럼 안정적이고 반복해서 물어볼 필요가 없는 사실.
3. 일화 메모리 — 지난번에 낸 불만이나 이전 단계에서 내린 결정처럼, 지금 상태가 아니라 그동안 무슨 일이 있었는지 자체가 가치를 갖는 기록.
4. 절차 메모리 — 같은 유형의 작업을 반복할수록 더 빠르고 정확해지도록 만드는, 학습된 처리 방식.

고객 지원 에이전트를 예로 들면, 지금 처리 중인 티켓은 작업 메모리에, 고객의 구독 등급은 의미 메모리에, 과거 불만 이력은 일화 메모리에, 학습된 환불 처리 절차는 절차 메모리에 담깁니다. 각 계층이 서로 다른 역할을 맡는 셈입니다.

어디에 저장할지는 순서대로 물어보면 된다

문제는 이 정보가 정확히 어느 계층에 속하는지 판단하는 일입니다. 이 판단은 다음 순서로 좁혀볼 수 있습니다.

1. 지금 턴을 넘어서까지 필요한 정보인가? 단발성 분류 요청의 문구나 이번 질문에만 쓰인 도구 호출 결과라면, 별도 메모리 없이 그 턴의 컨텍스트만으로 충분합니다. 다음 턴에도 필요하다면 다음 질문으로 넘어갑니다.
2. 세션을 넘어서도 살아남아야 하는가? 이미 물어본 내용이나 이미 호출한 도구처럼 세션 안에서만 유효하면 대화 버퍼로 충분합니다. 돌아온 고객의 선호도나 며칠씩 이어지는 프로젝트 상태처럼 세션을 넘어서야 한다면, 별도의 영구 저장이 필요해지죠.
3. 안정된 사실인가, 계속 달라지는 사건인가? 이름이나 기본 배송지처럼 매번 다시 묻거나 추론할 필요 없이 하나의 정답으로 저장해두는 게 나은 정보는 의미 메모리로, 지난달 접수된 불만이나 이전 단계의 결정처럼 시간에 따라 쌓이는 기록은 일화 메모리로 갑니다.

이 판단이 중요한 이유는 잘못된 계층에 정보를 넣었을 때 생기는 문제 때문입니다. 안정적인 사실을 벡터DB에 넣고 검색으로 찾게 하면 오히려 느리고 부정확해집니다. 반대로 전체 상호작용 이력을 통째로 검색하게 하면 이미 갱신된 정보와 오래된 정보가 섞여 나올 수 있죠. 구조화된 기록이었다면 이미 최신 값으로 덮어썼을 정보가 말입니다.

벡터DB 없이 파일만으로 만든 메모리

Bouchard와 Iusztin은 이 원칙을 실제로 구현하면서 벡터DB나 지식그래프 없이 순수한 파일 구조만으로 “AI 리서치 OS”를 만들었습니다. 세 개의 층으로 이루어져 있습니다.

1. 원본 층 — 에이전트가 읽어들인 글, 저장소, 녹취록, 메모, 하이라이트는 원본 그대로 보존됩니다. 요약은 디테일을 잃기 마련이라, 정확도가 중요할 때는 언제든 원본으로 돌아갈 수 있어야 하기 때문입니다.
2. 색인 — index.yaml 파일 하나가 무엇이 존재하는지, 어디에 있는지, 각 자료가 무엇에 관한 것인지, 어떤 파생 노트가 그 자료를 참조하는지를 알려줍니다. 에이전트는 모든 걸 다 불러오는 대신 이 카탈로그부터 읽고, 요약을 확인한 뒤, 필요한 파일만 엽니다.
3. 위키 — 자료들을 개념, 비교, 개체, 노트, 미해결 질문으로 바꿔놓는 단계입니다. 예를 들어 오픈소스 코딩 에이전트 저장소 몇 개를 넣으면, 권한 흐름이나 샌드박싱, 도구 레지스트리, 서브에이전트, 메모리 시스템에 대한 노트를 만들고 저장소들의 아키텍처를 비교하기도 합니다.

새로운 질문을 던지면 위키는 계속 자라납니다. 일반적인 리서치 문서가 한 번 쓰고 나면 서서히 낡아가는 것과 달리, 파일 기반 위키는 작업할수록 계속 쌓여갑니다.

물론 프로덕션 제품에는 벡터DB와 RAG가 여전히 필요한 경우가 많습니다. 다만 개인 리서치 워크플로우 수준에서는 폴더를 직접 열어보고, 잘못된 요약을 고치고, 약한 자료를 걸러내고, 에이전트가 왜 그렇게 답했는지 직접 이해할 수 있는 방식이 유리하다는 게 이들의 결론입니다. 모델이 모든 걸 기억하게 만들 게 아니라, 어디를 봐야 할지 알게 만드는 쪽이 더 오래가는 셈이죠.