기억은 과정이 아니라 데이터다 - 메모리필드가 파일 형식으로 에이전트 기억을 다루는 방식

기억은 과정이 아니라 데이터다

TL;DR

• 전제가 벤치마크 관행을 비판하며 시작하는데 많은 모델 벤치마크가 빈 컨텍스트 창에서 출발하고 이것이 AI의 백지상태이며 공정성을 위해서는 어느 정도 타당하다는 것이다. 그런데 실전은 다르다. 실제 에이전트는 결코 빈 컨텍스트 창에서 시작해서는 안 되고 가능한 한 많은 관련 정보를 가지고 시작해야 하며, 당신의 AI 에이전트는 기억을 가지고 시작해야 한다.
• 기존 시스템 셋이 각각 다른 이유로 기각되는데 첫째는 특정 하네스에 의도적으로 묶는 것으로 대화 이력에서 정보를 캐내므로 기억 대부분이 당신에 관한 것인데 세계에 관한 정보가 대체로 훨씬 유용하다. 둘째는 pgvector와 Neo4j 그래프 데이터베이스, 자체 LLM까지 필요한 터무니없이 복잡한 것이고, 셋째는 그래프와 논리 명제를 상상하는 고도 근대주의 종류로 정보를 맥락에서 체계적으로 벗겨 내 고립시킨다.
• 진단이 한 문장으로 압축되는데 그것들의 공통점은 기억을 과정으로 취급한다는 것이고 기억은 특히 모델에게는 데이터로 표현되는 것이 훨씬 낫다는 것이다. 근거로 브룩스가 인용된다. 흐름도를 보여 주고 표를 숨기면 나는 계속 어리둥절할 것이고, 표를 보여 주면 흐름도는 자명해질 것이므로 대개 필요하지 않다.
• 형식은 놀랍도록 단순한데 zip 파일 안에 마크다운 페이지들과 SQLite 벡터 색인 하나이고 프론트매터와 색인은 모두 선택이다. 첫 설계 결정이 덩어리나 사실이 아니라 산문을 쓰는 것이다. 기억은 형성되는 시점에 산문을 완전히 쓸 수 있는 AI 에이전트에게 직접 일어나고 있으므로, 덩어리로 쪼개거나 이중 요약할 필요 없이 에이전트가 가장 좋아하는 형식인 마크다운으로 직접 쓰게 하면 된다.
• 지식 그래프를 버린 이유가 가장 실용적인데 관련 정보가 그래프에서 N단계 깊이면 그것을 가져오는 데 N+1번의 도구 호출이 필요하고 각 호출이 2, 3초씩 걸리는 동안 수십억 달러 모델이 멈춰 있어야 한다는 것이다. 그래서 대안이 제시된다. 의미 검색으로 관련 페이지에 직접 도약해 모두 병렬로 읽으면 도구 호출은 최대 두 번이면 되고, 관련 없는 입력 토큰이 최소화된다.

Source

Agent memory as a file format — Cal Paterson, 2026년 8월

[calpaterson.com/memoryfields.html](https://calpaterson.com/memoryfields.html)

Knowledge

왜 기존 기억 시스템은 작동하지 않는가

글은 벤치마크 관행에서 시작한다. 많은 모델 벤치마크가 빈 컨텍스트 창에서 출발하고 이것이 AI의 백지상태라는 것이다. 그리고 공정성을 유지하려는 취지에서 어느 정도 타당하다고 인정한다.

그런데 곧바로 실전과 구분한다. 실제 에이전트는 결코 빈 컨텍스트 창에서 시작해서는 안 되고 가능한 한 많은 관련 정보를 에이전트가 쓸 수 있는 상태로 시작해야 한다는 것이다. 그래서 요구가 한 문장으로 정리된다. 당신의 AI 에이전트는 기억을 가지고 시작해야 한다.

문제 제기가 직설적이다. 많은 에이전트 기억 시스템이 실제로 상당히 형편없다는 것이고 현재 대략 세 종류가 인기 있는데 각각 자기 방식으로 작동하지 않는다고 본다.

첫째 종류는 특정 하네스에 의도적으로 묶는 것이고 보통 그 하네스를 임대해 주는 연구소가 작성한 것이다. 동기가 지목된다. 그 연구소는 경쟁이 심한 API 사업에서 훨씬 수익성 좋은 플랫폼 사업으로 옮겨 가기를 간절히 원한다는 것이다. 작동 방식이 문제로 이어진다. 보통 대화 이력에서 정보를 캐내는 방식으로 작동하므로 기억 대부분이 당신에 관한 것이 되는데, 세계에 관한 정보가 대체로 훨씬 유용하다는 것이다.

둘째 종류는 터무니없이 복잡한 것이다. 무엇이 기억할 가치가 있는지 결정하기 위해서만 pgvector와 Neo4j 그래프 데이터베이스, 그리고 자체 LLM까지 필요한 유명한 시스템을 알고 있다는 것이다. 문제가 둘로 지목된다. 이 복잡성이 관리하기 어렵기만 한 것이 아니라, 이런 큰 시스템들이 모델도 혼란스럽게 한다는 것이다. 그리고 모델 프런티어가 전진할 때 함께 확장되지 못한다.

셋째 종류는 고도 근대주의 변종이라고 명명된다. 이상화되고 합리주의적인 형태의 기억을 상상하는 것이고 필연적으로 그래프가 들어가며 때로는 논리 명제까지 들어간다. 그리고 판정이 붙는다. 이 종류는 정보를 맥락에서 체계적으로 벗겨 내 에이전트에게도 당신에게도 고립되고 무의미한 상태로 남긴다는 것이다. 반문이 이어진다. 결국 증류된 사실의 단순한 목록이 얼마나 유용하겠느냐는 것이다.

그래서 공통점이 진단된다. 그것들이 기억을 과정으로 취급한다는 것이고 기억은 특히 모델에게는 데이터로 표현되는 것이 훨씬 낫다는 것이다.

표를 보여 주면 흐름도는 자명해진다

주장의 근거로 브룩스가 인용된다. 흐름도를 보여 주고 표를 숨기면 자기는 계속 어리둥절할 것이며 표를 보여 주면 흐름도는 대개 필요하지 않을 텐데 자명해질 것이라는 문장이다.

그리고 형식이 곧바로 제시된다. 이식 가능한 기억 파일 형식이고 확장자가 memoryfield.zip이다. 구조가 단순하다. 그 안에 탄소 섬유 웍이나 핀란드 관료제 팁, 2026 WEC 시즌 노트 같은 마크다운 파일 여러 개와, nomic-embed-text-v1.5.sqlite3라는 파일 하나가 들어 있다.

정의가 세 줄로 정리된다. 마크다운 페이지들이고 선택적으로 YAML 프론트매터가 있고 선택적으로 의미 검색을 위한 SQLite 벡터 색인이 있다는 것이다. 그리고 전제가 붙는다. 에이전트는 파일과 가장 잘 작동한다는 것이다.

첫째 결정 — 덩어리나 사실이 아니라 산문

첫 설계 결정의 근거가 RAG 파이프라인이 복잡한 이유를 짚는 데서 나온다. RAG 파이프라인이 아주 복잡해질 수 있는 주된 이유는 기존에 사람이 작성한 문서 덩어리를 AI 에이전트가 읽을 수 있게 만들려 하기 때문이라는 것이다. 그런 문서들은 예컨대 큰 PDF라서 에이전트가 직접 읽기 아주 어려운 경우가 많다.

그런데 에이전트 기억은 다르다. 기억은 형성되는 시점에 산문을 완전히 쓸 수 있는 AI 에이전트에게 직접 일어나고 있다는 것이다. 그래서 결론이 명확하다. 그 산문은 덩어리로 쪼개거나 보강하거나 이중 요약하거나 기계적으로 처리할 필요가 없고 에이전트가 가장 좋아하는 형식인 마크다운으로 기억을 직접 쓰게 하면 된다는 것이다.

페이지 예시가 제시된다. 프론트매터에 제목과 생성 시각, 갱신 시각, UUID, 요약이 들어가고 본문에 탄소 섬유 웍이 열을 고르게 전달한다는 내용이 이어지는 형태다.

유일한 제약도 밝힌다. 페이지가 벡터 임베딩에 들어갈 만큼 짧아야 하므로 약 8킬로바이트, 대략 2,000 토큰의 연성 상한이 있다는 것이다. 그런데 이것을 실무적으로 유익한 제약으로 재해석한다. 8,000자는 약 1,300단어이고 중간 길이 잡지 기사 분량인데, 사실 어차피 두는 것이 합당한 제약이라는 것이다. 더 자세히 쓰려면 페이지를 더 추가하면 되고 에이전트는 그것을 어려워하지 않는다고 덧붙인다.

둘째 결정 — 그래프 순회가 아니라 의미 도약

선행 연구로 카파시 위키가 지목된다. 하이퍼링크된 마크다운 파일을 중심으로 구성되고 롬이나 옵시디언이 쓰는 방식을 본뜬 것이며 에이전트가 지식 그래프를 걸어 관련 페이지를 찾는다는 발상이었다.

그런데 실전 판정이 강하다. AI 에이전트에게 지식 그래프를 순회하게 하는 것은 느리고 신뢰할 수 없으며 에이전트에게 혼란스럽다는 것이다. 그림 설명에 촌평이 붙는다. 아름다운 지식 그래프인데 당신의 AI 에이전트가 그것을 절대적으로 싫어한다는 점이 정말 안타깝다는 것이다.

느린 이유가 알고리즘으로 설명된다. 위키 첫 페이지를 읽고 관련 링크를 찾고 링크된 페이지를 읽고 다시 관련 링크를 찾고 충분한 정보를 찾았는지 판단하고 아니면 되돌아가는 절차다. 각 읽기가 도구 호출이라는 점이 문제다. 그래서 계산이 나온다. 관련 정보가 그래프에서 N단계 깊이면 그것을 가져오는 데 N+1번의 도구 호출이 필요하다는 것이다. 그리고 비용이 지목된다. 각 도구 호출이 아마 2, 3초씩 걸리는 동안 수십억 달러, 어쩌면 수조 달러 LLM 모델이 멈춰 있어야 한다는 것이다. 그리고 역설이 붙는다. 이것이 깊이 중첩된 지식 그래프에 심하게 불리한데, 솔직히 그것은 지식 그래프의 요점 전체를 가로지른다는 것이다.

신뢰할 수 없는 이유도 구조적이다. AI가 자료가 관련 있는지 판단할 수 있는 근거가 링크 텍스트나 어쩌면 페이지 제목뿐이라는 것이다. 그래서 에이전트에게 1990년대 검색엔진 최적화 방식의 페이지 메타데이터 해킹을 하도록 큰 압력이 가해진다. 각 페이지의 링크 텍스트와 제목, 캡션이 간결하고 정확해야 하기 때문이다. 그런데 그렇게 하면 대가가 따른다. 여담과 부수적 세부의 주변적 기록, 큰 텍스트 코퍼스에서 흔하고 아주 유용한 종류의 암묵적 전승을 벌하게 된다는 것이다. 그래서 실전 결과가 나온다. 카파시 위키에서 관련 정보가 자주 놓치는데, 검색하는 에이전트에게 충분히 매력적으로 보이는 방식으로 제목이나 캡션이 붙지 않았기 때문이라는 것이다.

혼란스러운 이유가 셋째다. 그래프를 돌아다니며 관련 없는 정보를 많이 훑어야 하는 경우가 많다는 것이다. 무심코 관련 없는 정보를 읽는 것이, 첫 페이지가 주된 범인인데, 모델의 컨텍스트 창에 잡음을 넣어 출력 품질을 낮추고 이상한 것에 고착된 것처럼 보이게 만든다.

그래서 해법이 정리된다. 의미 검색으로 관련 페이지 전부에 곧바로 도약하고 페이지 메타데이터가 아니라 실제 내용에 기반해 찾으며 에이전트가 관련 페이지 전부를 한 번에 병렬로 읽게 하는 것이다. 그리고 지금 대다수 모델이 그렇게 한다고 덧붙인다. 결과가 수치로 온다. 메모리필드에서는 도구 호출이 최대 두 번 필요하다는 것이다. 검색이 첫 번째이고 병렬 읽기가 두 번째다. 그래서 관련 있는 것이 실제로 발견되고 관련 없는 입력 토큰이 최소화된다.

셋째 결정 — 기제는 줄이고 모델에 맡긴다

고도 기제 기억 시스템의 문제가 인터페이스 미로로 표현된다. 특별히 만든 API나 데이터베이스가 많이 포함된 종류를 쓰려면 에이전트가 목표를 이루기 위해 인터페이스 미로를 항해해야 한다는 것이다. 딜레마가 명확하다. 인터페이스가 크면 openapi.json을 컨텍스트에 많이 적재하게 되고 작으면 제한적이라는 것이다. 균형이 맞아도 문제가 남는다. 종종 API가 여전히 틀렸다는 것이고 당신의 필요를 예견하지 못한 다른 사람이 쓴 API를 써야 했던 때를 떠올려 보라며 그 경험이 즐거웠느냐고 묻는다.

그래서 저기제 시스템의 이점이 도출된다. 메모리필드는 그냥 파일 형식이므로 에이전트가 자기만의 접근 패턴을 발명할 훨씬 큰 여지를 준다는 것이다. 도움이 되기를 바라는 도구가 제공되지만 에이전트는 원하는 어떤 접근 패턴이든 완전히 자유롭게 쓸 수 있다. 실제 목격한 예가 둘 제시된다. 코퍼스 전체에 찾아 바꾸기를 하려고 펄을 쓰는 것과, 기억 안에 인라인 CSV 파일을 넣고 그것을 SQLite로 질의하는 것이다.

저기제라는 것이 모델 프런티어와 함께 확장된다는 점도 논증된다. 모델이 좋아지면 에이전트가 할 일을 더 많이 생각해 낸다는 것이다. 그리고 최근 돌파 하나가 지목된다. 모델들이 우연히도 배시에 아주 능하다는 것이고 마크다운에도 능하며 SQLite에도 능하다. 그래서 이유가 정리된다. 메모리필드가 실제 에이전트 안에서 잘 작동하는 이유 하나는, 에이전트가 기억을 읽을 수 있게 되기 전까지 가진 것이 훈련 데이터뿐인데 그 훈련 데이터에서 무슨 일이 일어나고 있는지 근본적으로 파악할 수 있기 때문이라는 것이다. 기억 파이프라인 안의 신체 없는 LLM 호출로서는 그럴 수 없다.

그리고 대비가 온다. 모델이 좋아지면 자동으로 기억을 조금 더 영리하게 쓰기 시작하는데, 옆에 매달린 가방식 기억 시스템은 좀처럼 그렇지 않다는 것이다. 고정된 API 종점 집합을 더 상상력 있게 쓰는 방법은 그렇게 많지 않기 때문이다.

넷째 결정 — 열린 형식과 전송 무관성

기억이 쌓이면 소중해진다는 관찰이 근거가 된다. 배운 교훈과 힘겹게 얻은 확립된 사실의 축적된 보물이라는 것이고 특정 하네스나 모델, 에이전트에 묶이고 싶지 않을 것이라고 본다.

그래서 파일 형식에 대한 RFC 방식 명세를 썼다고 밝힌다. 목적이 명확하다. 주로 모호함을 없애고 특정 임베딩 함수에 묶이지 않게 하기 위해서라는 것이다. 그리고 명세만으로 필요한 도구를 바이브 코딩할 수 있다고 하면서도, 스킬과 에이전트에 최적화된 명령줄 도구도 제공한다고 한다.

전송에 대한 태도가 특히 열려 있다. 정본 보관 형식은 zip 파일인데 데이터 교환을 가능한 한 쉽게 하기 위한 것이라는 것이다. 그런데 명세는 로컬 파일이나 아마존 S3, 깃허브, HTTP로 제공되는 것도 가능하도록 의도적으로 열려 있다고 한다. 실은 파일이 있는 어떤 것이든 작동한다는 것이고 저자 자신은 개인 메모리필드에는 싱크싱을 쓰고 다른 사람과 공유하는 것에는 S3를 쓰는 혼합 방식이라고 밝힌다.

시작 방법도 제시된다. 명세를 내려받아 에이전트에게 구현을 바이브하게 할 수도 있지만 가장 단순한 방법은 제공된 도구를 쓰는 것이라는 것이다. 올라마와 uv, npx가 필요하고 임베딩 모델을 받고 CLI 도구를 설치하고 스킬을 설치하는 세 단계다. 그리고 이후는 에이전트가 도와줄 것이라고 한다.

데모 메모리필드도 소개된다. 소프스톤스라는 이전 프로젝트에서 정리해 내보낸 것이고 에이전트가 데이터에 접근하는 방법에 대한 무게당 가치가 높은 기억이 많다는 것이다. 에이전트로서 레딧을 검색하는 법, 지나 리더를 쓰는 법, 미디어위키 API로 위키를 효과적으로 읽는 법 같은 것들이다.

이건 그냥 RAG 아닌가

흔한 반론 넷이 문답으로 다뤄진다.

첫째 반론이 이것이 그냥 RAG 아니냐는 것이다. 답이 두 층으로 나온다. RAG가 지금 극도로 넓게 해석되어 에이전트가 데이터를 가져오기만 하면 RAG가 일어났다고 하므로, 그 의미에서는 그렇다는 것이다. 그런데 반전이 붙는다. 거의 모든 에이전트가 데이터를 가져오고 예컨대 웹을 검색한다는 것이며 RAG 시스템과 보통 연관되는 기법 대부분이 여기 없다. 덩어리 쪼개기도 없고 재순위화도 없고 하이브리드 검색도 없다. 그리고 다른 면이 지목된다. 기억을 쓰는 것이 에이전트라는 점이다. RAG 시스템은 종종 읽기에 관한 것인데 메모리필드는 쓰기에도 쓰인다는 것이다.

둘째 반론은 임베딩 모델이 2년도 더 됐고 더 새롭고 좋은 모델이 있지 않느냐는 것이다. 답이 명확하다. 임베딩 모델은 프런티어 모델만큼 크지도 않고 그만큼 빠르게 움직이지도 않는다는 것이다. nomic-embed-text-v1.5가 작음과 강력함 사이의 좋은 균형으로 남아 있고 270메가바이트로 충분히 작고 GPU가 없는 하드웨어에서 돌 만큼 빠르며 널리 인기 있고 자주 권장되는 기본 임베딩 모델이라고 한다. 다만 명세가 다른 임베딩 사용을 허용한다고 덧붙인다.

셋째 반론은 무엇이 좋은 기억인지 어떻게 판단하고 쓰레기로 기억을 채우는 것을 어떻게 피하느냐는 것이다. 답이 구조에서 나온다. 기억 시스템에 흔한 두려움이지만 메모리필드에는 정말 적용되지 않는다는 것이다. 관련 없는 자료는 의미 검색에서 애초에 표면화되지 않기 때문이다. 관련 없는 기억이 공간을 차지하기는 하고 주기적으로 정리하고 싶을 수는 있지만 에이전트를 어떤 식으로도 방해하지 않는다는 것이다. 그래서 권고가 나온다. 최선의 결과를 위해 메모리필드에 자유롭게 넣으라는 것이다. 다만 팁 하나가 붙는다. 기억은 인용을 포함할 때 가장 잘 작동하고 이상적으로는 URL 형태라는 것이다. 그것이 미래에 기억을 다시 훑을 때 강화하는 데 도움이 되고 에이전트가 낡거나 의심스러운 자료를 사실 확인하는 데 도움이 된다.

넷째 반론은 보안이다. 답이 단호하다. 신뢰하지 않는 당사자와 컨텍스트 창을 공유해서는 안 되며 기억을 통해서도 안 된다는 것이다. 그래서 명세에 정적 zip 파일 형식이 포함된 이유 하나가 밝혀진다. 다른 사람에게서 받은 메모리필드를 수동으로 검토하고 sha256sum으로 고정할 수 있게 하기 위해서라는 것이다. 그리고 근본 한계가 명시된다. 에이전트가 좋은 프롬프트와 악한 프롬프트를 구별하게 할 방법이 여전히 없다는 것이다.

데이터가 먼저다

결론에서 흐름도를 명시적으로 진술한다. 기억을 마크다운으로 쓰고 그것을 임베딩해 벡터를 SQLite에 저장하고 의미적으로 검색해 기억을 다시 찾는 세 단계다. 앞서 브룩스를 인용한 취지대로 표를 먼저 보여 줬으니 흐름도는 이제 자명하다는 논리다.

그리고 이 시스템의 이례성이 규정된다. 메모리필드가 기억 시스템으로서 이례적인 점은 과정이 아니라 데이터 구조를 명세한다는 것이다. 추출 파이프라인도 없고 배경 처리 서비스도 없고 플러그인 가능한 무엇도 없다. 벡터 색인은 있지만 그것은 삭제 가능한 캐시이고 시스템이 아니라는 점이 강조된다.

마지막 두 문장이 이 글의 요지다. 기억은 데이터라는 것과, 에이전트와 그 데이터 사이에 고정된 기계를 덜 놓을수록 에이전트가 더 좋아질 수 있다는 것이다.

주석에 솔직한 자기 비판도 남는다. 자기 설치 절차가 세어 보니 네 가지 다른 패키지 관리자를 포함하고 있고 더 나은 방법이 있어야 할 것처럼 느껴진다는 것이다. 그리고 명세에 대한 사람의 검토를 높이 평가한다고 요청한다.

더 생각해보기

• 기억을 과정이 아니라 데이터로 보는 전환은 어디까지 일반화되는가. 다른 에이전트 인프라에도 같은 논리가 적용되는가.
• 8킬로바이트 연성 상한이 유익한 제약이라는 주장은, 긴 맥락이 필요한 기억에는 어떻게 대응하는가.
• N+1 도구 호출 문제는 병렬 도구 호출이 보편화되면 사라지는가, 아니면 구조적으로 남는가.
• 링크 텍스트에 의존하면 페이지 메타데이터 해킹을 유발한다는 지적은, 사람이 쓰는 위키에도 같은 문제가 있다는 뜻인가.
• 관련 없는 기억이 의미 검색에서 표면화되지 않으므로 해롭지 않다는 주장은, 유사하지만 틀린 기억에도 성립하는가.
• 저기제 설계가 모델 프런티어와 함께 확장된다는 논거는, 모델이 나빠지거나 정체될 경우 어떤 위험을 남기는가.
• 기억을 zip으로 교환하고 sha256으로 고정하는 방식은 프롬프트 주입을 실제로 막는가, 아니면 책임을 사용자에게 넘기는가.
• 에이전트가 기억을 스스로 쓴다면, 잘못 학습된 기억이 누적되는 것은 어떻게 교정되는가.
• 벡터 색인을 삭제 가능한 캐시로 규정한 선택은 재구축 비용을 감안하면 실무에서 유지되는가.