파일이냐 그래프냐 — 마크다운 한 장과 시간 그래프에 같은 고객 10명을 기억시켜 봤다

크게 보기

이 글은 연재의 네 번째 실측편입니다. 기억에 유효기간을 적다에서 Graphiti 시간 그래프를 코드로 읽었고, 옛 사실은 정말 닫히나에서 한국어 상담 로그로 쟀고, 시간을 기억하는 SQL에서 데이터베이스의 답을 봤고, 날짜 하나로 기억을 바꾼다에서 거짓말을 넣어 봤습니다. 이번에는 가장 단순한 경쟁자를 링에 올립니다. 마크다운 파일 한 장.

0. 그래프를 만들 필요가 있었나

지금 이 글을 쓰는 코딩 에이전트에게도 기억이 있습니다. 프로젝트 폴더의 CLAUDE.md, 그리고 사용자별 memory/ 폴더 안의 마크다운 파일 몇 개입니다. 지식 그래프도, 임베딩 인덱스도 없습니다. 에이전트는 대화를 시작할 때 파일을 읽고, 배운 것이 생기면 파일에 한 줄 적습니다.

2026년의 에이전트 업계는 대부분 이쪽으로 왔습니다. Claude Code의 CLAUDE.md와 자동 기억, OpenAI Codex가 시작해 리눅스 재단으로 넘어간 AGENTS.md, Letta가 기본값으로 삼은 git 기반 메모리 파일 시스템(MemFS), Manus의 "파일 시스템은 궁극의 맥락". 2025년 8월 Letta는 「AI 에이전트 기억 벤치마크: 파일 시스템이면 충분한가?」라는 글에서 대화 기록을 파일 하나에 넣고 grep·의미 검색 같은 파일 도구를 준 에이전트로 LoCoMo 74.0%를 내며 그래프 기억(Mem0 그래프판 68.4%)을 앞섰다고 발표했습니다.

그렇다면 이 연재가 네 편에 걸쳐 들여다본 시간 지식 그래프는 무엇을 위해 있는 걸까요. 질문을 실험으로 바꿨습니다. 같은 고객 10명의 같은 대화를, 같은 모델로, 파일 네 가지와 Graphiti에 각각 기억시키고, 같은 질문 21개를 던졌습니다. 대화를 150마디로 늘린 규모 실험과, 지난 편의 위조 메일을 그대로 넣은 오염 실험도 했습니다.

결과를 먼저 요약합니다.

• 24마디에서는 파일이 이겼습니다. 대화를 날짜와 함께 그대로 적어 둔 파일(LLM 호출 0번)이 95.2%, 이력을 남기며 통째로 다시 쓴 파일이 91.9%, Graphiti는 엣지 전체를 줘도 81.4%였습니다.
• '현재 상태만' 남긴 파일은 47.6%로 꼴찌였습니다. 과거 시점 질문을 거의 못 맞혔습니다. 파일이 이긴 건 파일이라서가 아니라 이력을 남겼기 때문입니다.
• 같은 거짓말에 둘은 다른 곳에서 속았습니다. 날짜를 과거로 소급한 위조에 그래프는 버티고 파일은 모두 속았습니다. 미래 날짜 위조에는 반대로 파일(다시 쓰기)이 버텼습니다.
• 규모 실험 결과는 5장에 있습니다.

크게 보기

1. 두 갈래의 기억

파일 갈래: 사람이 읽는 텍스트

프로그램의 기억을 사람이 읽는 텍스트 파일에 두는 전통은 오래됐습니다. 1960년대 MIT CTSS의 RUNCOM에서 온 'rc'가 지금도 .bashrc라는 이름에 화석처럼 남아 있고, 1995년 워드 커닝햄의 첫 위키는 누구나 고치는 텍스트 페이지를 집단 기억으로 만들었습니다. 니클라스 루만의 메모 상자(제텔카스텐)는 카드 9만 장을 번호와 참조로 이었습니다.

LLM 에이전트에서 이 갈래를 연 것은 2023년 10월의 MemGPT입니다. 운영체제의 메모리 계층을 흉내 내, 모델이 늘 보는 '작업 맥락'(작은 텍스트 블록)과 필요할 때 꺼내는 '회상 저장소'·'보관 저장소'를 나눴습니다. 핵심은 모델이 함수 호출로 자기 기억을 직접 고친다는 것이었습니다. 이 '작업 맥락'이 나중에 Letta(MemGPT의 후신)의 기억 블록이 되고, 2026년 2월에는 git으로 버전 관리되는 마크다운 파일 묶음(Context Repositories, 지금의 MemFS)이 됐습니다.

2025년은 파일 갈래의 해였습니다.

• 2월 Claude Code가 저장소의 CLAUDE.md를 프로젝트 기억으로 쓰기 시작했습니다.
• 7월 Manus는 "파일 시스템을 궁극의 맥락으로 다룬다. 크기 제한이 없고, 본래 영속적이며, 에이전트가 직접 다룰 수 있다"고 썼습니다.
• 8월 AGENTS.md가 공개됐고, 12월 리눅스 재단 산하 Agentic AI Foundation으로 넘어가며 "6만 개 넘는 프로젝트가 채택"했다고 발표됐습니다. 이 글을 쓰는 날 GitHub 코드 검색에서 AGENTS.md라는 이름의 파일은 약 108만 개, CLAUDE.md는 약 88만 개입니다(포크·하위 폴더 포함 파일 수).
• 9월 Anthropic은 API에 메모리 도구(view·create·str_replace·insert·delete·rename)를 넣었습니다. 기억은 앱이 관리하는 /memories 디렉터리의 파일입니다.

Letta는 파일이 이기는 이유를 이렇게 설명합니다. "오늘날의 에이전트는 파일 시스템 도구를 매우 잘 쓴다. 에이전트 코딩 작업을 위한 사후 학습 덕분이다. 지식 그래프 같은 더 복잡한 해법은 특정 영역에서는 도움이 되겠지만, LLM이 이해하기 더 어렵다는 대가가 따를 수 있다."

그래프 갈래: 사실과 관계와 시간

다른 갈래는 1950년대의 의미망에서 2012년 구글 지식 그래프("문자열이 아니라 사물")로 이어진 지식 표현의 전통입니다. 에이전트 기억에서 이 갈래의 대표가 2025년 1월의 Zep/Graphiti입니다. 대화를 사실(엣지)로 쪼개고, 사실마다 '언제부터 언제까지 참이었나'(유효 시간)와 '언제 알게 됐나'(기록 시간)를 붙입니다. 새 사실이 옛 사실과 모순되면 옛 사실에 끝 날짜를 적습니다. 이 연재 1편이 다룬 구조입니다.

그래프 갈래의 주장은 파일이 시간과 변경에 약하다는 것입니다. 2024년 10월의 LongMemEval은 지식 갱신과 시간 추론을 따로 재는 벤치마크를 만들며 "시간을 모르는 기억 설계는 시간 추론에서 성적이 나쁘다"고 썼습니다. 그리고 2026년, 파일 갈래의 제품들은 실제로 하나둘 시간을 덧대고 있습니다.

그런데 이 표의 시간은 모두 파일이 언제 쓰였나(기록 시간)입니다. 그 사실이 언제 참이었나(유효 시간)를 기록하는 것은 없습니다. 이 차이가 실험에서 어떻게 드러나는지가 이 글의 관심사입니다.

2. 지금까지 나온 비교들

공정한 비교는 의외로 드뭅니다. 업체 벤치마크는 서로의 설정을 두고 다툽니다. 몇 가지 숫자를 정리하면 이렇습니다.

두 가지가 눈에 띕니다. 첫째, 원문을 통째로 넣는 기준선이 생각보다 강합니다. Mem0 논문의 표에서도, Zep 논문의 DMR 표(전체 대화 94.4% 대 Zep 94.8%)에서도 그렇습니다. 둘째, 그래프의 장점은 지식 갱신(바뀐 사실을 바로잡기)에 모입니다. 이 연재의 실험 데이터가 정확히 그 영역입니다. 이사, 이직, 약 변경, 요금제 변경이 있는 대화니까요. 그래프에 유리한 땅에서 붙여 보면 어떻게 될까요.

3. 실험 설계: 같은 대화, 같은 모델, 다섯 가지 기억

지난 실측의 가상 고객 10명이 1년 동안 남긴 한국어 상담 24마디를 그대로 썼습니다. 이사, 이직, 약 변경, 요금제 두 번 변경, 취미 중단, 늦게 도착한 옛 거주지 이야기, 퇴사 계획, 잡담이 들어 있습니다. 같은 대화를 다섯 가지 기억에 넣었습니다.

크게 보기

공정하게 비교하려고 기억을 쓰는 모델을 모두 gemini-3.5-flash-lite 하나로 맞췄습니다. Graphiti의 추출 모델과 모순 판정 모델(small_model)도 같은 모델입니다. 지난 실측에서 판정 모델을 키우면 잘못 닫힘이 0이 됐기 때문에, 그래프에 가장 유리한 설정입니다. 사내 게이트웨이의 OpenAI·Anthropic 상류 크레딧이 바닥난 상태라 지난 실측(OpenAI)과 모델이 다르다는 점은 밝혀 둡니다.

기억을 다 쓴 뒤에는 고객마다 같은 질문 21개를 던졌습니다. 질문은 세 종류입니다.

기억을 읽고 답하는 모델(독자)과 채점 모델은 한 급 위인 gemini-3.5-flash로 모든 기억에 똑같이 썼습니다. 독자는 '기억에 있는 내용만 근거로 답하고, 없으면 모름'이라는 지시를 받습니다. 그래프는 두 가지로 줬습니다. 하나는 앱에서 보통 쓰는 방식인 질문으로 검색한 상위 10개 엣지, 다른 하나는 그 고객의 엣지 전체입니다. 둘 다 엣지마다 '유효: 시작 ~ 끝'을 붙였습니다.

4. 결과 1: 24마디에서는 파일이 이겼다

고객 10명 × 질문 21개 = 210문항. 쓰기 비용은 gemini-3.5-flash-lite 정가(입력 100만 토큰당 0.30달러, 출력 2.50달러) 기준입니다. 질문 두 개('지금 하는 취미', '부업')는 '주말에 여행 블로그 운영'처럼 취미와 부업의 경계가 모호해 모든 기억이 함께 틀렸습니다. 이 둘을 빼고 190문항으로 다시 세도 순위는 같았습니다(그대로 기록 97.9%, 다시 쓰기 96.8%, 부분 편집 88.9%, 그래프 85.3%·81.6%, 현재만 47.4%).

가장 놀라운 줄은 맨 위입니다. LLM을 한 번도 부르지 않고 대화를 날짜와 함께 그대로 적어 둔 파일이 1등이었습니다. 독자 모델(gemini-3.5-flash)이 질문을 받을 때마다 1,260자 남짓한 원문을 통째로 읽고 직접 추론했기 때문입니다. '지난주 월요일'이나 '지난달 15일' 같은 상대 날짜도 원문에 받은 날짜가 붙어 있으니 독자가 계산하면 됩니다. '언제' 질문 50개를 모두 맞혔습니다.

두 번째는 이력을 남기라고 지시하고 파일 전체를 다시 쓰게 한 방식입니다. 과거 시점 질문 80개 중 79개를 맞혔습니다. 고객 1의 최종 파일은 이렇습니다.

이 고객의 변경 날짜 일곱 개가 모두 정답입니다. '3일 전부터 약을 바꿨다'는 05-01로, '지난달 15일에 이사했다'는 06-15로 정확히 계산돼 있습니다. 같은 고객의 그래프는 이렇습니다(일부).

지난 실측에서 본 세 가지 약점이 그대로 나옵니다. '그만뒀다'는 말이 옛 사실을 닫지 못하고(러닝이 여전히 현재), 늦게 도착한 옛 이야기가 열린 채 들어오며(대전 거주가 현재), 퇴사 '계획'이 실제 퇴사보다 먼저 직장을 닫습니다(한빛소프트 05-31 종료, 실제 퇴사는 06-30). 그래프는 사실을 문장 하나씩 따로 판단하므로, 문장 사이의 관계(그만둠 → 취미 종료, 대전 → 마포 이전)를 놓치면 날짜가 틀어집니다. 파일을 다시 쓰는 모델은 고객의 전체 그림을 한 번에 보며 고치기 때문에 이 관계를 잘 잡았습니다.

반대로 현재 상태만 남긴 파일은 47.6%로 꼴찌였습니다. 현재 질문은 82.5%로 괜찮았지만 과거 시점 질문은 21.2%였습니다. 옛 값을 지웠으니 당연합니다. 더 흥미로운 것은 '언제' 질문(34.0%)입니다. 이 파일은 '세종시 (2025-08-05 변경)'처럼(고객 4, 실제 이사일 07-15) 고객이 말한 날이 아니라 말을 들은 날을 변경일로 적는 경우가 많았습니다. 기록 시간과 유효 시간을 구분하지 않으면 생기는 바로 그 혼동입니다(시간을 기억하는 SQL 참고).

부분 편집은 비용이 가장 싼 LLM 방식이었지만(1,000마디당 0.33달러) 정확도는 다시 쓰기보다 7.6포인트 낮았습니다. 편집 명령 189개 중 적용 실패는 1개뿐이었으니 도구 사용 자체의 문제는 아닙니다. 대신 한 줄씩 덧붙이다 보니 직장: 한빛소프트 줄과 직장: 한빛소프트 ( ~ 2025-06-30), 누리랩스 이직 (2025-07-01 등록) 줄이 함께 남는 식의 중복과 모순이 쌓였고, 경기 하남 (2025-09-03 기준)처럼 이사일 대신 들은 날을 적은 경우도 있었습니다(고객 6, 실제 이사일 07-15). 파일 전체를 다시 보지 않으면 앞뒤를 맞추기 어렵습니다.

비용과 속도

쓰기 비용은 그래프가 가장 비쌌습니다. Graphiti는 마디 하나에 평균 3.3번 LLM을 부르고(추출·중복 판정·모순 판정·날짜 추출), 판정할 때마다 기존 엣지와 노드를 맥락에 넣습니다. 그래서 입력 토큰이 다시 쓰기 파일의 9.8배(135만 대 13.8만)였습니다. 1,000마디로 환산하면 그래프 2.31달러, 다시 쓰기 파일 0.93달러, 부분 편집 0.33달러입니다. 고객 10명을 병렬로 넣었을 때 걸린 시간은 그래프 115초, 다시 쓰기 31초였습니다.

다만 이 비교는 쓰기만 본 것입니다. 읽기 쪽은 반대입니다. 그대로 기록은 쓰기가 공짜인 대신 질문마다 원문 전체를 읽습니다. 24마디에서는 1,260자라 문제없지만, 대화가 쌓이면 이 숫자는 끝없이 커집니다. 그래서 다음 실험이 필요했습니다.

5. 결과 2: 150마디로 늘리면

파일 기억에 대한 가장 흔한 걱정은 '커지면 어떡하나'입니다. 통째로 다시 쓰는 파일은 매번 전체를 출력해야 하고, 원문을 쌓는 파일은 매번 전체를 읽어야 합니다. 그래서 고객 3명의 대화에 작은 사실 126마디를 섞어 150마디로 늘렸습니다. 어제 어디서 무엇을 샀다(50마디), 형·조카·팀장 이름(20마디), 음식 취향(20마디), 잡담(36마디)입니다. 핵심 질문 21개에 '전기 포트는 어디서 샀나요?', '고객의 조카 이름은?' 같은 작은 사실 질문 20개를 더했습니다.

크게 보기

고객 3명 × 질문 41개 = 123문항이라 표본이 작습니다. 핵심 21은 고객 3명의 핵심 질문 63문항, 작은 사실 20은 60문항 기준입니다. 쓰기 비용은 gemini-3.5-flash-lite 정가 기준입니다.

세 가지가 보입니다.

첫째, 걱정했던 붕괴는 없었습니다. ACE 논문은 통째로 다시 쓰는 기억이 한 단계 만에 18,282토큰에서 122토큰으로 무너진 사례를 보고했습니다. 이 실험의 다시 쓰기 파일 세 개는 150마디 동안 한 번도 직전보다 40% 넘게 줄지 않았고, 끝까지 꾸준히 커졌습니다. 작은 사실 60개 중 5개를 놓쳤는데, 모두 고객 2의 구매처였습니다. 들여다보니 지워진 게 아니라 처음부터 적히지 않았습니다. 모델이 구매 기록을 전기 그릴 (2025-01-22 구매, 출처: 2025-01-23 채팅)이라는 형식으로 정한 뒤, 어디서 샀는지는 끝까지 빼고 적었습니다. 다시 쓰기 방식은 형식을 모델이 고르고, 모델이 고른 형식이 무엇을 남길지 정합니다. 원문을 쌓거나 한 줄씩 덧붙인 파일은 작은 사실을 하나도 놓치지 않았습니다.

둘째, 비용의 순위가 뒤집혔습니다. 24마디에서는 다시 쓰기 파일이 그래프보다 쌌습니다(1,000마디당 0.93달러 대 2.31달러). 150마디에서는 다시 쓰기 파일이 2.29달러로 그래프(1.22달러)의 두 배 가까이 됐습니다. 파일이 커질수록 매번 그 전체를 다시 출력해야 하기 때문입니다. 한 마디 처리 시간도 첫 10마디 평균 1.0초에서 마지막 10마디 7.8초로 늘었습니다. 출력 토큰은 입력보다 8배 비싸니, 다시 쓰기의 비용은 대화 길이에 대해 거의 제곱으로 늘어납니다. 부분 편집은 바뀐 줄만 출력하므로 0.37달러로 가장 쌌고, 작은 사실도 다 지켰습니다. 대신 '언제' 질문이 66.7%로 약했습니다.

셋째, 그래프의 진짜 장점은 정확도가 아니라 '읽는 양'입니다. 검색 상위 10개만 주면 독자가 읽는 맥락이 460자로, 그대로 기록(7,072자)의 15분의 1입니다. 정확도는 74.8%로 가장 낮은 축이었지만, 읽는 양은 대화가 길어져도 거의 늘지 않습니다. 반면 그대로 기록은 1,000마디면 약 5만 자, 1만 마디면 50만 자가 됩니다. LongMemEval_S의 대화가 약 11.5만 토큰인데, Zep 논문에서는 그 길이에서 전체 맥락(gpt-4o 60.2%)이 Zep(71.2%)에 졌습니다. Chroma의 '맥락 부패(context rot)' 실험도 18개 모델 모두 입력이 길수록 성능이 고르지 않게 떨어진다고 보고했습니다.

정리하면, 150마디(약 7천 자)는 아직 파일의 땅입니다. 이 실험은 교차점이 어디인지까지 재지 못했습니다. 다만 비용은 이미 교차했고(다시 쓰기 > 그래프), 읽는 양의 차이(15배)는 대화가 길어질수록 벌어집니다. 그래프 검색의 정확도를 끌어올리는 것(지난 실측에서 본 한국어 검색 문제, 닫히지 않는 옛 사실)이 그래프 쪽의 숙제입니다.

크게 보기

흔한 걱정을 그린 그림입니다. 이 실험의 150마디에서는 파일이 무너지지 않았고, 대신 비용과 시간이 늘었습니다.

6. 결과 3: 같은 거짓말에 둘은 다르게 속았다

3편 기억 오염 실측의 위조 메일과 주입 지시문을 파일 기억 세 가지에도 똑같이 넣었습니다. 고객마다 기초 상담 8마디 뒤에 공격 1건을 넣고, 독자 모델에게 "지금 사는 곳"을 물었습니다. 그래프 쪽은 3편에서 만든 그래프(판정 3.1 Flash-Lite)의 엣지 전체를 맥락으로 줬습니다.

크게 보기

숫자는 고객 10명 중 독자가 가짜 값(수영구·해커컴퍼니·999)을 답한 수입니다. 마지막 줄만 새 주소를 맞힌 수입니다.

결과는 '어느 쪽이 더 안전하다'가 아니라 '어디서 속는지가 다르다' 입니다.

• 과거 소급 위조에 그래프는 버텼고(0/10) 파일은 모두 속았습니다(10/10). 그래프는 '더 늦게 시작한 사실이 이긴다'는 코드 규칙 덕분에 2024년부터라고 주장한 가짜를 스스로 닫았습니다. 파일을 고치는 LLM에게는 그런 규칙이 없습니다. "2024년부터 수영구에 거주 중인 것으로 확인되었습니다"를 읽고 그냥 주소를 고쳤습니다. 다시 쓰기 파일에는 거주지: 부산 수영구 광안로 12 (2024-01-01~) / 이전: 서울 마포구 (2025-01-06~2025-05-05) (※ 출처: 2025-05-06 고객지원팀 외부 이메일)이 남았습니다. 출처가 외부 이메일이라고 스스로 적어 놓고도 주소를 바꿨습니다.
• 앞으로 날짜 위조에는 반대로 다시 쓰기 파일이 버텼습니다(60일 뒤에도 2/10). 모델이 "6월 20일부로 변경됩니다"를 확정 사실이 아니라 계획: 등록 주소 부산 수영구 광안로 12로 변경 예정 (출처: 외부 이메일, 2025-06-20~)으로 적었기 때문입니다. '계획은 확정 사실과 구분하라'는 지시가 통한 것입니다. 그래프는 3편에서 본 대로 그날이 되자 10/10 가짜로 넘어갔습니다. 현재만 남기는 파일과 부분 편집 파일도 60일 뒤에는 모두 속았습니다.
• 주입 지시문의 결제 계좌는 그래프가 덜 속았습니다(2/10). 그래프 추출 단계가 '결제 계좌'를 사실로 뽑지 않은 경우가 많았기 때문이고, 파일은 세 방식 모두 999-999-999를 그대로 적었습니다. 주소와 직장은 둘 다 속았습니다.
• 오늘부로 위조는 모두에게 통했습니다. 이건 위조가 아니라 진짜 이사(대조군)와 구별할 정보가 내용에 없기 때문입니다. 출처로 막아야 하는 공격입니다.

정리하면, 그래프의 강점은 규칙이 코드에 있다는 것입니다. 그 규칙이 맞는 공격(소급)은 막고, 그 규칙을 역이용하는 공격(앞으로 날짜)에는 기계적으로 집니다. 파일의 강점은 모델이 맥락을 판단한다는 것입니다. 계획과 사실을 구분하라는 지시는 따르지만, 출처를 적어 놓고도 그 출처를 이유로 거부하지는 않습니다. 둘 다 3편의 결론과 같은 처방이 필요합니다. 출처를 보고 쓰기 자체를 막거나 격리해야 합니다. 파일이라면 "외부 문서에서 온 변경은 기존 값을 바꾸지 말고 '확인 필요'에 적어라" 같은 규칙을 지시문이 아니라 쓰기 함수에 넣어야 합니다.

7. 그래서 무엇을 쓸까: 둘은 경쟁자가 아니라 층이다

실험을 정리하면, 파일과 그래프는 같은 문제를 두고 다투는 경쟁자라기보다 서로 다른 층에 있습니다.

크게 보기

이미 많은 제품이 둘을 겹쳐 씁니다. Zep은 그래프에서 고른 사실을 '컨텍스트 블록'이라는 텍스트로 만들어 모델에게 줍니다. Letta는 늘 보는 핵심 기억 블록(파일)과 필요할 때 찾는 보관 기억을 나눕니다. Basic Memory는 마크다운 파일을 원본으로 두고 그 안의 링크에서 그래프를 만들어 냅니다. 이 실험이 가리키는 조합도 비슷합니다.

맺으며: 파일이 이긴 진짜 이유

처음 질문으로 돌아가겠습니다. 그래프를 만들 필요가 있었나. 고객 한 명에 대화 몇백 마디라면, 이 실험에서는 아니었습니다. 원문을 날짜와 함께 쌓아 두거나, 이력을 남기며 한 장으로 정리한 파일이 Graphiti보다 정확하고 싸고 빨랐습니다.

하지만 파일이 이긴 이유를 정확히 봐야 합니다. 현재 상태만 남긴 파일은 47.6%로 꼴찌였습니다. 1등 파일과 꼴찌 파일의 차이는 형식이 아니라 '옛 값을 언제까지였는지와 함께 남겼느냐' 하나였습니다. 그것은 바로 시간 그래프가 처음부터 하려던 일, 이 연재의 첫 글 제목대로 기억에 유효기간을 적는 일입니다. 결국 이긴 것은 파일이 아니라 이중 시간의 생각이었고, 이번에는 그 생각을 LLM이 마크다운으로 더 잘 구현했을 뿐입니다.

2026년의 파일 기억 제품들이 하나같이 수정 시각, 유효 기한, 꿈꾸기(dreaming) 같은 시간 장치를 덧대고 있는 것도 같은 이야기입니다. 규모가 커지고, 여러 에이전트가 함께 쓰고, '그때는 어땠나'를 기계가 물어야 하는 순간, 글자로 적힌 날짜는 필드가 돼야 합니다. 그때 다시 그래프와 이중 시간 테이블이 필요해집니다.

연재의 마지막 편에서는 이 모든 실험의 바탕이 된 질문 자체를 의심해 보겠습니다. LoCoMo, LongMemEval 같은 메모리 벤치마크는 무엇을 재고 무엇을 놓치는가.

참고 자료

논문

• Packer et al., "MemGPT: Towards LLMs as Operating Systems", arXiv 2310.08560
• Park et al., "Generative Agents", arXiv 2304.03442
• Maharana et al., "LoCoMo", arXiv 2402.17753
• Wu et al., "LongMemEval", ICLR 2025, arXiv 2410.10813
• Rasmussen et al., "Zep: A Temporal Knowledge Graph Architecture for Agent Memory", arXiv 2501.13956
• Xu et al., "A-MEM", arXiv 2502.12110
• Chhikara et al., "Mem0", arXiv 2504.19413
• Zhang et al., "Agentic Context Engineering(ACE)", arXiv 2510.04618
• "LongMemEval-V2", arXiv 2605.12493
• "Are We Ready For An Agent-Native Memory System?", arXiv 2606.24775
• Gadgil et al., "Bad Memory", arXiv 2607.14611

제품 문서·글

• Letta, "Benchmarking AI Agent Memory: Is a Filesystem All You Need?" (2025-08-12), "Context Repositories" (2026-02-12), MemFS 문서
• Anthropic, Claude Code 기억 문서, 메모리 도구, "Effective context engineering for AI agents" (2025-09-29)
• OpenAI, AGENTS.md, Codex memories, ChatGPT 「Dreaming」
• Manus, "Context Engineering for AI Agents: Lessons from Building Manus" (2025-07-18)
• GitHub, Copilot Memory
• getzep/graphiti v0.30.2