에이전트 메모리 (agent memory)를 사용하여 개발하는 모든 개발자가 결국 마주하게 되는 질문이 있습니다. 보통 3개월 차쯤, 대개 아주 불편한 시간에 찾아오는 질문입니다:

내 메모리는 실제로 어디에 저장되어 있으며, 다른 곳에서 그 메모리가 필요해지면 어떻게 되는가?

이 질문은 설계 검토 (design review) 단계에서 나타나지 않습니다. 사고 (incident)의 형태로 나타납니다. 프레임워크가 중대한 변경 사항 (breaking change)을 배포합니다. 사용 중인 임베딩 모델 (embedding model)이 지원 중단 (deprecated)됩니다. 두 번째 에이전트가 첫 번째 에이전트가 축적한 90일간의 컨텍스트 (context)를 필요로 합니다. 누군가 시스템이 특정 사용자에 대해 현재 믿고 있는 모든 정보의 목록을 요청합니다.

당신은 찾아 나섭니다. 이미 버전을 옮겨버린 모델에 키가 지정된 벡터 (vector) 테이블, 원시 턴 (raw turns)의 JSON 덤프, 그리고 프롬프트 (prompt) 내부에 존재했던 추출 규칙 (extraction rules)을 발견하게 됩니다.

이 포스트는 당신이 그런 상황에 처하기 전에 실행해 보아야 할 테스트와 그 근거에 관한 것입니다.

목차

• 논쟁은 읽기에 관한 것이다
• 메모리는 쓰기 문제다: 인덱스 (index)가 해결할 수 없는 다섯 가지 결정
• 내보내기 (export)의 세 가지 단계
• 임베딩의 함정 (the embedding trap)
• 플릿 (the fleet)이 상황을 악화시킨다
• OKF가 제대로 하고 있는 것
• OKF가 멈추는 지점
• 왕복 테스트 (the round-trip test)
• 전체 체크리스트

논쟁은 읽기에 관한 것이다

Google Cloud가 6월에 Open Knowledge Format (OKF)을 발표한 이후, 모든 논쟁은 OKF 대 RAG (Retrieval-Augmented Generation)로 나뉘었습니다. 권위 있는 사실을 위한 큐레이션된 마크다운 (curated markdown), 방대한 아카이브를 위한 검색 (retrieval).

그 안에는 실제적인 연구가 담겨 있습니다. Satvik Singh는 두 개의 운영 서비스에 대한 12개의 온콜 (on-call) 질문을 대상으로 큐레이션된 문서, 지식 그래프 (knowledge graph), BM25 검색, 그리고 단순한 에이전트식 grep을 벤치마킹했습니다. 그 결과, 도구의 이데올로기보다는 질문의 유형이 승자를 결정한다는 것을 발견했습니다. grep은 모든 코드 세부 사항 질문을 해결했고, 큐레이션된 문서는 모든 아키텍처 질문을 해결했으며, 모든 검색 (retrieval) 승리는 검색기가 큐레이션된 문서의 청크 (chunks)를 표면화한 결과였습니다.

하지만 이 논쟁의 모든 논점은 이미 존재하는 코퍼스 (corpus)에서 시작하여, 그중 올바른 부분을 어떻게 찾을 것인가를 묻습니다.

그것은 읽기 (reading) 문제입니다. 메모리는 나중에 읽기 문제가 되는 쓰기 (writing) 문제이며, 거의 모든 어려움은 검색 (retrieval)의 상류 (upstream) 단계에 존재합니다.

메모리는 쓰기 (write) 문제입니다

문서는 한 번 작성되어 여러 번 읽힙니다. 하지만 메모리는 작성되는 것이 아닙니다. 그것은 다른 무언가에 관한 상호작용으로부터 측면에서 점진적으로 축적 (accretes) 됩니다.

이로 인해 인덱스 (index)가 대신 결정해 줄 수 없는 다섯 가지 결정 사항이 발생합니다.

1. 중요도 (Salience). 이번 주 400번의 턴 (turn) 중 무엇이 중요했을까요? 대부분의 구현체는 휴리스틱 (heuristic)으로 답합니다:

# 거의 모든 사람이 시작하는 형태
if turn_count % 10 == 0:
    summary = llm.summarize(recent_turns)
...

그 휴리스틱이 바로 당신의 품질 상한선 (quality ceiling)입니다. 너무 많이 유지하면 불필요한 단계를 거쳐 대화 기록 (transcript)을 재구축한 꼴이 됩니다. 너무 적게 유지하면 에이전트는 정작 중요한 단 한 가지에 대해 자신만만하게 건망증을 앓게 됩니다.

2. 대체 (Supersession). 3월에 사용자는 토론토에 삽니다. 6월에 그들은 베를린을 언급합니다. 이것은 두 개의 사실이 아니라, 역사를 가진 하나의 사실입니다:

# 보통 얻게 되는 결과
[
  {"fact": "user lives in Toronto", "ts": "2026-03-04"},
...

이제 세 번의 세션에 걸쳐 세 명의 에이전트가 주장한 사실에 대해 생각해 보세요. 그중 두 개는 틀렸습니다.

3. 통합 (Consolidation). "화요일의 수출 흐름에 대해 좌절함"은 하나의 사건 (event)입니다. "수출 충실도 (export fidelity)를 중요하게 생각함"은 하나의 메모리 (memory)입니다. 이 둘 사이의 승격 (promotion)은 조각조각 도착하는 증거를 바탕으로 지속적으로 내려지는 판단 (judgment call)입니다.

4. 출처 (Provenance) 및 시간. 누가, 언제, 어떤 근거로 그것을 주장했는지, 그리고 그것이 만료되는지 여부입니다. 이러한 필드들이 없다면 당신은 정보를 조정 (reconcile)할 수 없고, 감사 (audit)할 수 없으며, 삭제 요청을 준수할 수 없고, 정보의 노후화 (staleness)와 의견 불일치 (disagreement)를 구분할 수 없습니다.

5. 망각 (Forgetting). 가장 적게 논의되지만, 법적으로 가장 중대한 영향을 미칩니다. 깔끔하게 잊을 수 없는 메모리 시스템은 기능 (feature)의 탈을 쓴 컴플라이언스 (compliance) 문제입니다.

이 모든 것은 조회 (lookup)나 유사도 점수 (similarity score)가 아니라 하나의 _결정 (decision)_입니다. 이것이 메모리가 검색 (retrieval)의 문제가 아니라 에이전트적 (agentic) 문제인 이유이며, 정답이 실제로는 행동 (behavior)임에도 불구하고 계속해서 인프라 (infrastructure)처럼 보이는 이유입니다.

내보내기 (export)의 세 가지 계층

어떤 메모리 제품에나 내보내기를 요청하면 무언가는 얻을 수 있습니다. 유용한 질문은 그것이 다음 세 가지 중 무엇인가 하는 점입니다.

임베딩의 함정 (The embedding trap)

이 부분은 미묘하면서도 비용이 많이 들기 때문에 별도로 언급할 가치가 있습니다.

만약 당신의 메모리의 영구적인 형태가 임베딩 (embedding)이라면, 당신의 메모리는 특정 임베딩 모델에 종속됩니다.

# 이것은 포맷 변환이 아닙니다
$ ./migrate.sh --re-embed --model text-embedding-v3
✓ 148,291개의 메모리가 재임베딩되었습니다
...

오류는 전혀 발생하지 않지만, 검색 품질 (retrieval quality)은 소리 없이 변해버립니다. 재임베딩 (re-embedding)은 실패가 눈에 보이지 않는 손실이 발생하는 재유도 (lossy re-derivation) 과정입니다. 아무런 에러도 발생하지 않지만, 회상 (recall) 능력은 3주 뒤에 '느낌적인 느낌 (vibes)'으로 나타날 방식으로 서서히 저하됩니다.

벡터 (Vectors)는 캐시 (cache)입니다. 캐시를 시스템의 기록 원천 (system of record)으로 취급하는 것이야말로 당신이 결국 벗어날 수 없게 만드는 정확한 방법입니다.

에이전트 군단이 상황을 악화시킨다 (The fleet makes it worse)

단일 에이전트 버전은 짜증 나는 수준이지만, 에이전트 군단 (fleet) 버전은 돈이 드는 문제입니다.

실제 배포 환경에서는 동일한 메모리 자산에 대해 여러 에이전트가 맞붙게 됩니다. IDE에 있는 에이전트 하나, 지원 티켓을 처리하는 에이전트 하나, 분석을 수행하는 에이전트 하나, 그리고 한 달 동안 아무도 검토하지 않은 예약된 작업을 실행하는 에이전트 하나가 있는 식입니다. 각 에이전트는 자신만의 저장소에, 자신만의 형태와 규칙에 따라 무언가를 학습합니다.

결국 조정 (reconciliation) 메커니즘이 없는 발산 (divergence)이 발생합니다. 왜냐하면 조정이라는 작업 자체가 애초에 에이전트 간의 교차 작업(cross-agent operation)으로 설계되지 않았기 때문입니다. 사용자가 지원 에이전트를 교정하면, 코딩 에이전트는 이전의 잘못된 정보를 무기한으로 믿게 됩니다.

Singh의 프레임링은 여기서 뼈아프게 다가옵니다: 유도된 계층 (derived layers)은 TTL (Time To Live)이 없는 캐시와 같다. 그가 5일 전에 구축한 지식 그래프 (knowledge graph)는, 해당 그래프가 유도된 작업 트리 (working tree)에 있는 2주 전의 기능에 대해 0/3점을 기록했습니다. 큐레이션된 문서 (curated docs) 역시 동일한 기능에 대해 전혀 다루지 않았습니다. 그 어떤 산출물 (artifact)도 자신이 뒤처져 있다는 신호를 보내지 않습니다.

당신이 실행하는 모든 에이전트가 각각 독립적으로 유도되고, 각자 자신의 일정에 따라 뒤처진다고 가정하면 이 문제는 배가됩니다.

OKF가 제대로 하고 있는 것 (What OKF gets right)

정확히 말하자면, 이 형식은 과장된 기대보다는 덜할지 몰라도 회의론보다는 훨씬 더 유용합니다.

OKF v0.1은 2026년 6월 12일 Google Cloud의 Data Cloud 팀에 의해 발표되었습니다. 번들 (bundle)은 YAML 프론트매터 (frontmatter)가 포함된 마크다운 (markdown) 파일들의 디렉토리이며, 파일당 하나의 개념을 담고 서로 상호 참조 (cross-linked)됩니다. 정확히 하나의 필드(type)만 필수입니다. 런타임 (runtime), SDK, 레지스트리 (registry), 계정이 필요 없습니다. GitHub에서 렌더링되며, tarball 형태로 배포되고, 어떤 파일 시스템 (filesystem)에도 마운트 (mount)할 수 있습니다.

그러한 형태의 메모리는 대략 다음과 같이 표현됩니다 — type은 명세 (spec) 요구 사항이며, 나머지는 관례적 또는 확장 필드입니다:

---
type: preference
title: "Export fidelity"
...

소유권 문제에 있어서, 이 속성들은 정확히 적절합니다:

• 사람이 새벽 3시에도 읽을 수 있습니다. 장애 상황 (incident) 발생 시, 이는 시스템이 무엇을 믿고 있는지 확인하는 것과 추측하는 것 사이의 차이를 만듭니다.
• Git은 이미 이를 어떻게 처리해야 할지 알고 있습니다. 차이점 (diffs), blame, PR, 리뷰. 큐레이션 (curation)은 불투명한 변이 (mutation)가 아닌, 검토 가능한 변경 사항이 됩니다.
• 당신의 스택 (stack)보다 오래 살아남습니다. SDK도, 버전 고정 (version pin)도, 당신의 로드맵이 곧 그들의 로드맵이 되어버리는 벤더 (vendor)도 필요 없습니다.
• 생산자와 소비자가 설계 단계부터 분리되어 있습니다. 이는 이식 가능성 (portable)의 정의이며, 문서 페이지의 약속이 아닌 명세 (spec)로서 명시된 것입니다.

OKF의 한계

여기에 솔직한 한계가 있습니다. 측정 결과가 보여주는 바를 고려할 때, 이를 생략하는 것은 부정직한 일일 것입니다.

Singh는 그가 벤치마킹한 큐레이션된 문서에서 세 가지의 확신에 찬 잘못된 사실을 발견했습니다. 각 사실은 문서가 작성되기 2년 전에 이미 결정된 코드와 모순되었습니다. 이는 단순히 오래된 정보가 아니라, AI 생성 단계에서부터 잘못 태생되었으며, 에이전트들이 신뢰하도록 교육받는 계층 (layer)에 자리 잡은 것이었습니다. 그 후 검색 (retrieval) 과정에서 그중 하나가 증폭되었습니다. 상위 결과들은 정답이 2번 언급되는 동안 오답을 26번 반복했습니다.

번들은 스냅샷 (snapshot)입니다. 메모리는 프로세스 (process)입니다. OKF를 채택하고 거기서 멈춘다면, 당신은 TTL (Time To Live)이 없는 아름답게 이식 가능한 캐시 (cache)를 구축한 것에 불과합니다.

그는 또한 왜 아무도 이를 규율(discipline) 있게 해결하지 못하는지 그 이유를 밝힙니다. 아무도 40개의 리포지토리(repo)를 위해 번들(bundle)을 직접 작성하고 직접 유지 관리하지 않기 때문입니다. 이를 "40개의 에이전트"로 바꾸어 생각해보십시오. 수동 큐레이션(Manual curation)은 규모(scale)의 문제를 마주하면 살아남지 못합니다. 즉, 큐레이션은 지치지 않고 검증 표준(verification standard)을 준수하는 무언가에 의해 수행되어야 합니다. 왜냐하면 자동화된 큐레이션(automated curation)의 실패 모드(failure mode)가 바로 그가 측정한 바로 그것이기 때문입니다.

거짓 이분법 (The false dichotomy): 큐레이션된 지식(curated knowledge)과 능동적 검색(active retrieval)은 대립 관계가 아닙니다. 능동적 축적 메모리(Active accumulating memory)는 세상의 정보를 받아들이는 방식입니다. 빠르고, 손실이 발생하며(lossy), 새로운 정보가 도착하는 곳입니다. 큐레이션된 확정 지식(Curated committed knowledge)은 당신이 진실이라고 결정한 것입니다. 느리고, 내구성이 있으며, 감사 가능(auditable)합니다. 제대로 작동하는 모든 시스템은 이 두 가지를 모두 가지고 있습니다.

진짜 질문은 이것입니다: 어떤 요소가 사실을 한 상태에서 다른 상태로 승격시키는지, 얼마나 자주, 어떤 근거로 그러하며 — 그리고 사실이 아니게 되었을 때 무엇이 그것을 강등(demote)시키는가?

그것은 하나의 '직무(job)'입니다. 포맷(Formats)은 큐레이션하지 않습니다. 리트리버(Retrievers)는 결정하지 않습니다.

라운드 트립 테스트 (The round-trip test)

이번 주에 실행해봐야 할 테스트입니다. 오후 시간 정도가 소요되지만, 이는 이식성 주장(portability claim)과 이식성 보장(portability guarantee)을 구분 짓는 단 하나의 테스트입니다.

# 1. 현재 시스템에서 내보내기 (export)
$ your-memory-tool export --out ./snapshot-a

...

당신이 찾아야 하는 것은 바이트 단위의 일치(byte equality)가 아닙니다. 타임스탬프(timestamps)와 ID는 변할 것입니다. 당신이 찾아야 하는 것은 **의미론적 손실 (semantic loss)**입니다:

• 상위 대체 체인(supersession chains)이 살아남았는가, 아니면 임포터(importer)가 이를 독립적인 사실들로 평탄화(flatten)해버렸는가?
• 출처(provenance)가 살아남았는가, 아니면 모든 항목의 asserted_by가 이제 null인가?
• 신뢰도(confidence)와 만료(expiry) 정보가 살아남았는가, 아니면 기본값(defaulted)으로 설정되었는가?
• 상호 참조(cross-references)가 살아남았는가, 아니면 고립(dangling)되어 있는가?
• 단위(units)의 개수를 세어보십시오. 만약 B가 A보다 적다면, 무언가가 조용히 누락된 것입니다.

대부분의 시스템은 이 중 최소 세 가지에서 실패합니다. 거의 아무도 마이그레이션(migration) 전까지는 확인하지 않으며, 확인하는 시점은 이미 마감 기한이 정해진 재작업(rewrite)을 해야 하는 상황입니다.

전체 체크리스트 (The full checklist)

1. 사람이 읽을 수 있는 정형화된 형태 (Canonical form). 만약 "시스템이 현재 X에 대해 무엇을 믿고 있는가?"라는 질문에 답하기 위해 쿼리를 날리고 코사인 유사도 (cosine scores)를 눈으로 직접 확인해야 한다면, 그것은 실패한 것입니다.
2. 모든 단위에 출처(Provenance)와 시간 기록. 누가, 언제, 어떤 근거로 작성했는지, 그리고 언제 만료되는지 기록되어야 합니다.
3. 덮어쓰기가 아닌 대체(Supersession) 기록. 토론토가 베를린으로 대체되었다면, 무엇이 언제 바뀌었는지 확인할 수 있어야 합니다.
4. 내구성이 있는 형태는 모델 독립적이어야 함 (Model-independent). 새로운 임베딩 모델 (embedding model)을 도입했을 때 정보 손실이 발생하는 재도출 (re-derivation) 과정이 필요하다면, 임베딩이 귀하의 기록 시스템 (system of record)이 되어버린 것입니다. 이 문제를 먼저 해결하십시오.
5. 내보내기 왕복 (Export round-trips). 위 항목 참조.
6. 소스에 대한 검증. 모든 큐레이션된 사실 (curated fact)은 정해진 일정에 따라 그것이 설명하는 대상과 대조하여 검증 가능해야 합니다.
7. 거부할 수 있어야 함. Fareed Khan의 파이프라인 작업은 이 점을 잘 보여줍니다. 증거가 없을 때 올바른 출력은 유창한 추측이 아닙니다. "그 정보가 없습니다"라고 말할 수 없는 메모리 시스템은 정보를 지어낼 것이며, 그 지어낸 정보는 큐레이션 레이어 (curated layer)의 권위를 그대로 물려받게 됩니다.
8. 삭제가 실제로 삭제되어야 함. 모든 파생된 인덱스 (index), 캐시 (cache), 요약 (summary), 그리고 해당 정보를 복사한 모든 에이전트 (agent)로부터 삭제되어야 합니다.

살아있는 메모리와 당신의 소유인 메모리 사이에서 하나를 선택해야만 해서는 안 됩니다. 축적되는 측면 (accumulating side)과 확정되는 측면 (committed side)은 동일한 프로세스의 두 가지 템포입니다. 우리가 구축할 가치가 있는 것은 메모리를 담아두는 또 다른 장소가 아니라, 메모리 사이에서 무엇이 이동할지를 결정하는 시스템입니다.

공개 사항 (Disclosure)

이것은 제가 작업하고 있는 분야이므로, 그에 따라 비중을 두어 판단하시기 바랍니다.

Memanto는 다른 에이전트들이 자신의 메모리를 관리할 수 있도록 돕는 오픈 소스 동반 메모리 에이전트 (companion memory agent)입니다. v0.2.8 기준으로 네이티브 Open Knowledge Format (OKF) 통합 기능을 제공하며, 이를 통해 메모리는 git에서 읽고, 차이점을 비교(diff)하고, 검토할 수 있는 OKF 번들로 통합됩니다. 또한 다른 메모리 시스템으로부터의 마이그레이션 (migration) 기능도 내장되어 있습니다:

$ pip install memanto
$ memanto migrate --from <source> --out ./memory-bundle
$ memanto export --format okf --out ./okf-bundle

제가 알기로는 두 가지를 모두 제공하는 유일한 메모리 에이전트(Memory Agent)입니다. MIT 라이선스를 따르고 있는데, 이는 이식성(portability)에 대한 주장이 가치를 가질 수 있는 유일한 라이선스입니다.

기억력(Recall): LongMemEval에서 89.8%, LoCoMo에서 87.1%.

제 말을 믿기 전에 이 에이전트를 대상으로 왕복 테스트(round-trip test)를 실행해 보세요. 어떤 경우든 현재 사용 중인 것이 무엇이든 간에 테스트를 실행해 보시기 바랍니다.

당신의 에이전트는 집중하고, Memanto는 기억합니다.