대부분의 AI 메모리 데모는 단순합니다.

사용자가 무언가를 말하면

시스템이 이를 임베딩 (embedding) 하고

벡터 데이터베이스 (vector database) 에 저장합니다.

나중에 어시스턴트가 이를 검색합니다.

데모용으로는 작동합니다.

하지만 제가 AI 어시스턴트 및 에이전트 시스템과 더 많이 작업할수록, 한 가지 질문 때문에 점점 더 불편해졌습니다.

AI 시스템이 단순히 저장할 수 있다는 이유만으로 모든 것을 기억하도록 허용해도 될까요?

그 질문이 MemoryOps AI의 시작점이 되었습니다.

GitHub: https://github.com/patibandlavenkatamanideep/memoryops-ai

단순한 AI 메모리의 문제점

많은 AI 메모리 시스템이 다음과 같은 패턴을 따릅니다:

채팅 메시지 → 벡터 데이터베이스 (vector database) → 나중에 검색

처음에는 그것이 유용하게 느껴집니다.

어시스턴트가 사용자의 선호도를 기억하고
프로젝트 세부 사항을 기억하며
과거 대화를 기억합니다.
미래의 응답을 개인화할 수 있습니다.

하지만 메모리는 단순한 컨텍스트 (context) 가 아닙니다.

메모리는 상태 (state) 입니다.

그리고 무언가가 상태가 되면, 새로운 질문들이 나타납니다:

• 이 메모리의 소유자는 누구인가?
• 애초에 저장해야 하는가?
• 민감한 정보인가?
• 삭제할 수 있는가?
• 그것이 어디에서 왔는지 증명할 수 있는가?
• 이 사용자를 위해 검색되어야 하는가?
• 한 테넌트 (tenant) 가 다른 테넌트의 메모리를 볼 수 있는가?
• 메모리가 오래되어 쓸모없게 되면 어떻게 되는가?
• 사용자가 동의를 철회하면 어떻게 되는가?

벡터 데이터베이스 (vector database) 하나만으로는 이러한 질문에 답할 수 없습니다.

그것이 제가 MemoryOps AI를 만들기 시작한 이유입니다.

MemoryOps AI란 무엇인가

MemoryOps AI는 AI 어시스턴트를 위한 엔터프라이즈 메모리 거버넌스 (governance) 레이어입니다.

목표는 단순히 어시스턴트가 기억하도록 돕는 것이 아닙니다.

목표는 전체 메모리 라이프사이클 (lifecycle) 을 제어하는 것입니다:

캡처 (Capture) → 저장 (Store) → 검색 (Retrieve) → 업데이트 (Update) → 망각 (Forget)

거버넌스 (Governance) 가 모든 단계를 감쌉니다.

메모리를 수동적인 저장소로 취급하는 대신, MemoryOps는 메모리를 관리되는 상태 (governed state) 로 취급합니다.

핵심 설계

시스템에는 세 가지 주요 경로가 있습니다.

1. 쓰기 경로 (Write path)

어떠한 정보도 메모리가 되기 전에 관리되는 쓰기 경로 (governed write path)를 거칩니다:

메시지 (Message)
→ 추출기 (Extractor)
→ 평가기 / 정책 중개자 (Evaluator / Policy Broker)
...

이는 메모리가 자동으로 저장되지 않음을 의미합니다.

시스템은 먼저 해당 정보를 저장할지, 차단할지, 버릴지, 업데이트할지, 병합할지, 또는 승인을 위해 보낼지를 결정합니다.

모든 사용자 메시지가 장기 메모리 (long-term memory)가 될 가치가 있는 것은 아니기 때문에 이 과정은 중요합니다.

어떤 정보는 유용하고
어떤 정보는 민감하며
어떤 정보는 일시적이고
어떤 정보는 효용성이 낮으며
어떤 정보는 절대 저장되어서는 안 됩니다.

2. 읽기 경로 (Read path)

검색 (Retrieval) 또한 관리됩니다:

메시지 (Message)
→ 검색기 (Retriever)
→ 랭커 (Ranker)
...

어시스턴트는 단순히 무작위의 메모리를 컨텍스트 (context)로 가져오지 않습니다.

메모리가 응답에 영향을 미치기 위해서는 반드시 검색, 순위 지정 (ranked), 구성 (composed), 그리고 범위 지정 (scoped) 과정을 거쳐야 합니다.

잘못된 메모리 검색은 잘못된 메모리 저장만큼이나 해로울 수 있기 때문에 이 과정은 중요합니다.

잘못된 시점에 잘못된 것을 기억하는 어시스턴트는 메모리가 전혀 없는 어시스턴트보다 더 나쁜 답변을 생성할 수 있습니다.

3. 백그라운드 라이프사이클 (Background lifecycle)

메모리는 시간이 지남에 따라 변화하기도 합니다.

따라서 MemoryOps는 라이프사이클 관리를 위한 백그라운드 워커 (background workers)를 포함합니다:

감쇠 작업 (Decay Job)
→ 성찰 에이전트 (Reflection Agent)
→ 충돌 해결사 (Conflict Resolver)
...

핵심 아이디어는 메모리가 영원히 정적 (static) 상태로 있어서는 안 된다는 것입니다.

어떤 메모리는 감쇠 (decay)되어야 하고
어떤 메모리는 아카이브 (archived)되어야 하며
어떤 메모리는 업데이트되어야 하고
어떤 메모리는 삭제되어야 하며
어떤 메모리는 압축 (compressed)되어야 합니다.
또한 어떤 메모리는 최신 정보와 충돌할 수도 있습니다.

이는 메모리를 영구적인 덤프 (dump)가 아닌, 활발한 라이프사이클로 전환시킵니다.

가장 중요한 원칙

저에게 있어 MemoryOps에서 가장 중요한 원칙은 다음과 같습니다:

저장보다 정책 우선 (Policy before storage)

모델이 무엇을 메모리로 만들지 스스로 결정해서는 안 됩니다.

대화와 메모리 저장소 사이에 정책 레이어 (policy layer)가 위치해야 합니다.

해당 레이어는 다음 사항들을 확인할 수 있습니다:

• 민감한 정보 (sensitive information)
• 비밀 정보 (secrets)
• 효용성이 낮은 메모리 (low-utility memories)
• 테넌트 경계 (tenant boundaries)
• 동의 상태 (consent state)
• 임시 채팅 모드 (temporary chat mode)
• 삭제 규칙 (deletion rules)
• 거버넌스 요구사항 (governance requirements)

이를 통해 메모리는 더욱 안전해지고 검사 가능해집니다.

어시스턴트는 메모리를 제안할 수 있지만,
시스템이 그것을 허용할지 결정합니다.

타입 지정된 메모리 (typed memory)가 중요한 이유

모든 메모리가 동일한 것은 아닙니다.

MemoryOps는 메모리를 다음과 같은 유형으로 구분합니다:

• 에피소드 메모리 (episodic memory)
• 의미론적 메모리 (semantic memory)
• 절차적 메모리 (procedural memory)
• 프로젝트 메모리 (project memory)
• 지식 메모리 (knowledge memory)
• 시스템 메모리 (system memory)

이것이 중요한 이유는 메모리 유형마다 동작 방식이 다르기 때문입니다.

사용자 선호도는 프로젝트 사실과 같지 않습니다.

워크플로 지침은 과거의 사건과 같지 않습니다.

시스템 수준의 규칙은 일상적인 대화의 세부 사항과 같지 않습니다.

메모리에 타입을 지정하면 평가, 검색, 업데이트 및 거버넌스를 수행하기가 더 쉬워집니다.

삭제는 일급 기능 (first-class feature)이어야 합니다

AI 메모리에서 가장 어려운 부분 중 하나는 잊는 것입니다.

많은 시스템이 메모리를 어떻게 저장하고 검색할지에 집중합니다.

하지만 삭제 또한 그만큼 중요합니다.

MemoryOps는 삭제 보장 (deletion guarantees), 보존 정책 (retention policies), 법적 보존 (legal hold), 동의 기반 메모리 (consent-aware memory), 그리고 삭제 검증 (deletion verification)을 포함합니다.

목표는 단순합니다:

메모리가 삭제되었다면, 검색 시 다시 나타나서는 안 됩니다.

당연하게 들릴 수도 있습니다.

하지만 AI 시스템에서 삭제는 복잡할 수 있는데, 메모리가 다음과 같은 다양한 형태로 존재할 수 있기 때문입니다:

• 원문 텍스트 (raw text)
• 정규화된 텍스트 (normalized text)
• 임베딩 (embeddings)
• 출처 발췌본 (provenance excerpts)
• 검색된 컨텍스트 (retrieved context)
• 감사 참조 (audit references)
• 백그라운드 워커 출력 (background worker outputs)

따라서 망각은 의도적으로 설계되어야 합니다.

그것은 사후 고려 사항 (afterthought)이 되어서는 안 됩니다.

감사 가능성 (Auditability)이 시스템을 변화시킵니다

MemoryOps의 모든 메모리 생명주기 이벤트는 감사 이벤트 (audit event)를 생성합니다.

여기에는 다음과 같은 작업들이 포함됩니다:

• 메모리 캡처 (memory captured)
• 메모리 저장 (memory stored)
• 정책 결정 (policy decision made)
• 메모리 검색 (memory retrieved)
• 메모리 업데이트 (memory updated)
• 메모리 삭제 (memory deleted)
• 보존 결정 (retention decision made)
• 워커 작업 실행 (worker job executed)

이를 통해 시스템을 더 쉽게 검사할 수 있습니다.

만약 특정 메모리가 응답에 영향을 미쳤다면, 시스템은 어떤 메모리가 사용되었고 어디에서 왔는지 설명할 수 있어야 합니다.

이는 디버깅 (debugging)에 중요합니다.

또한 신뢰를 구축하는 데 있어서도 중요합니다.

루프 엔지니어링 (Loop engineering)

제가 구축하며 즐거웠던 프로젝트의 한 부분은 루프 엔지니어링 (loop engineering) 레이어입니다.

MemoryOps는 메모리를 하나의 수동적인 파이프라인 (passive pipeline)으로 취급하지 않습니다.

대신 메모리를 관리되는 루프 (governed loops)의 집합으로 모델링합니다:

• 메모리 쓰기 루프 (Memory Write Loop)
• 메모리 읽기 루프 (Memory Read Loop)
• 거버넌스 루프 (Governance Loop)
• 평가 루프 (Evaluation Loop)
• 릴리스 게이트 루프 (Release Gate Loop)
• 지속적 학습 루프 (Continuous Learning Loop)

각 루프는 상태 (states), 정책 게이트 (policy gates), 감사 이벤트 (audit events), 폴백 동작 (fallback behavior), 그리고 증거 요구 사항 (evidence requirements)을 가집니다.

이는 제가 메모리를 데이터베이스 기능이라기보다 시스템 동작 (system behavior)에 가깝게 생각하도록 도와주었습니다.

메모리 시스템은 단순히 다음과 같지 않습니다:

저장 → 검색 (save → retrieve)

그것은 다음과 같습니다:

관찰 → 결정 → 저장 → 검색 → 평가 → 업데이트 → 망각 (observe → decide → store → retrieve → evaluate → update → forget)

이 루프는 반드시 제어되어야 합니다.

평가는 중요합니다

메모리 품질은 테스트 가능해야 합니다.

MemoryOps는 시스템이 불변성 (invariants)을 준수하는지 확인하기 위해 골든 케이스 (golden cases)와 적대적 케이스 (adversarial cases)를 포함합니다.

주요 불변성 중 일부는 다음과 같습니다:

• 테넌트 격리 (Tenant isolation)
• 삭제된 메모리는 다시는 검색되지 않음
• 임시 채팅은 메모리를 쓰거나 검색하지 않음
• 안전하지 않거나 비밀과 유사한 콘텐츠는 저장 전에 차단됨
• 모든 메모리는 출처 (provenance)를 가짐
• 검색 실패가 응답 생성을 차단하지 않음
• 정책 결정이 저장 전에 강제됨
• 시스템은 어떤 메모리가 응답에 영향을 미쳤는지 설명할 수 있음

이러한 행동 양식들이 단순한 메모리 데모와 메모리 인프라를 구분 짓는 요소입니다.

내가 배운 것

MemoryOps AI를 구축하며 얻은 가장 큰 교훈은 AI 메모리가 단순히 검색 (retrieval) 문제만이 아니라는 점입니다.

그것은 거버넌스 (governance) 문제입니다.

검색은 다음과 같이 답합니다:

어떤 컨텍스트 (context)를 다시 가져와야 하는가?

거버넌스는 다음과 같이 묻습니다:

이 정보가 메모리로서 존재해도 되는가?

두 번째 질문이 바로 진정한 시스템 설계가 시작되는 지점입니다.

왜냐하면 AI 어시스턴트가 더욱 지속적이고, 개인화되며, 에이전트적 (agentic)으로 변모하려면, 메모리에는 더 강력한 제어가 필요하기 때문입니다.

단순히 더 큰 컨텍스트 윈도우 (context windows)만으로는 부족합니다.

단순히 더 나은 임베딩 (embeddings)만으로도 부족합니다.

단순히 벡터 데이터베이스 (vector database)만으로는 부족합니다.

메모리에는 정책이 필요합니다.
메모리에는 출처 (provenance)가 필요합니다.
메모리에는 삭제 기능이 필요합니다.
메모리에는 감사 가능성 (auditability)이 필요합니다.
메모리에는 평가 (evaluation)가 필요합니다.
메모리에는 테넌트 격리 (tenant isolation)가 필요합니다.
메모리에는 동의 (consent)가 필요합니다.

현재 상태

MemoryOps AI는 다음과 같은 요소들을 갖춘 관리형 메모리 런타임 (governed memory runtime)으로 구축되었습니다:

• FastAPI 백엔드
• Next.js 프론트엔드
• Python SDK
• 타입이 지정된 메모리 저장소 (typed memory stores)
• 하이브리드 검색 (hybrid retrieval)
• 정책 브로커 (policy broker)
• 감사 로그 (audit log)
• 라이프사이클 워커 (lifecycle workers)
• 보존 및 동의 제어 (retention and consent controls)
• 루프 엔지니어링 레이어 (loop engineering layer)
• 플레이그라운드 데모 (playground demo)
• Railway 배포 경로

프로젝트는 여전히 진화 중이지만, 핵심 아이디어는 안정적입니다:

AI 메모리는 모든 것이 쏟아부어지는 장소가 되어서는 안 됩니다.

그것은 통제된 인프라가 되어야 합니다.

마지막 생각

AI 어시스턴트의 미래는 그들이 얼마나 잘 대답하느냐에만 달려 있지 않을 것입니다.

그들이 얼마나 잘 기억하느냐에도 달려 있을 것입니다.

그리고 더 중요한 것은:

얼마나 안전하게 잊느냐 하는 것입니다.

그것이 바로 MemoryOps AI가 해결하고자 하는 문제입니다.

GitHub: https://github.com/patibandlavenkatamanideep/memoryops-ai