대부분의 AI 에이전트는 프롬프팅 (Prompting) 문제로 위장된 메모리 문제를 겪고 있습니다.

우리는 컨텍스트 윈도우 (Context window)에 대화 기록을 계속 추가하거나, 오래된 메시지를 요약하거나, 문서를 벡터 데이터베이스 (Vector database)에 배치합니다. 이러한 기술들은 유용하지만, 다음과 같은 몇 가지 중요한 질문에는 답하지 못합니다:

• 몇 시간, 몇 주, 또는 몇 달 동안 기억되어야 하는 것은 무엇인가?
• 유용성이 떨어지면 무엇이 소멸되어야 하는가?
• 어떤 소스가 저장된 주장을 뒷받침하는가?
• 두 개의 메모리가 서로 모순될 때 어떤 일이 발생하는가?
• 왜 특정 메모리가 반환되었는가?
• 한 사용자의 메모리가 다른 사용자의 컨텍스트로 유출되는 것을 어떻게 방지할 것인가?

저는 모델 옆에서 실행되는 관리되는 인지 계층 (Governed cognitive layer)으로서의 메모리라는 다른 접근 방식을 탐구하기 위해 Aura Memory를 구축했습니다.

모델은 상태가 없는 (Stateless) 상태를 유지할 수 있습니다. Aura가 영속성 (Persistence), 검색 (Retrieval), 생명주기 (Lifecycle), 출처 (Provenance), 그리고 제한된 적응 (Bounded adaptation)을 담당합니다.

트랜스크립트 (Transcript)는 메모리 시스템이 아닙니다

채팅 트랜스크립트는 발생한 일을 기록합니다. 메모리 시스템은 무엇이 유용하게 남을지를 결정합니다.

에이전트가 단일 대화보다 더 오래 실행되면 이 차이가 중요해집니다. 가공되지 않은 기록은 무한히 커집니다. 요약은 세부 사항을 잃습니다. 벡터 검색 (Vector search)은 의미론적으로 유사한 텍스트를 찾을 수는 있지만, 유사성만으로는 내구성, 신뢰성, 모순, 또는 기록이 대체되었는지 여부를 표현할 수 없습니다.

에이전트가 유용한 연속성을 개발하려면 메모리에 자체적인 생명주기가 필요합니다:

interaction (상호작용)
    ↓
관찰, 결정, 결과 또는 선호도를 저장
...

이것이 Aura가 채우도록 설계된 역할입니다.

Aura Memory란 무엇인가

Aura는 Rust 코어와 Python 바인딩 (Bindings)을 갖춘 오픈 소스 인지 메모리 런타임 (Cognitive memory runtime)입니다. 핵심 메모리 작업은 로컬에서 실행되며 LLM 호출, 임베딩 (Embedding) API 또는 클라우드 데이터베이스를 필요로 하지 않습니다.

기본 인터페이스는 의도적으로 작게 설계되었습니다:

pip install aura-memory

from aura import Aura, Level

brain = Aura("./agent_memory")
...

반환된 값은 모델 프롬프트(model prompt)에 삽입하거나 에이전트 도구(agent tool)에서 사용할 수 있는 경계 컨텍스트(bounded context)입니다. 저장(Storage)과 검색(Retrieval)은 모델 추론(model inference)과 분리되어 있으므로, 동일한 메모리를 Claude, Gemini, OpenAI 모델, Ollama, CrewAI, LangChain 또는 MCP 클라이언트와 함께 사용할 수 있습니다.

메모리는 서로 다른 시간 척도(timescales)를 가집니다

모든 기록이 영구 저장될 가치가 있는 것은 아닙니다. Aura는 기록을 네 가지 레벨(level)로 구성합니다:

유지보수 사이클(Maintenance cycles)은 감쇠(decay), 승격(promotion), 통합(consolidation) 및 아카이빙(archival)을 적용합니다. 자주 유용하거나 중요한 기록은 유지될 수 있지만, 가치가 낮은 작업 컨텍스트는 사라질 수 있습니다.

report = brain.run_maintenance()

이는 모든 메시지를 영원히 추가하는 방식과는 의도적으로 다릅니다. 망각(Forgetting)은 설계의 일부이며, 오류 조건이 아닙니다.

기록에서 인지 구조(cognitive structure)로

가공되지 않은 기록(Raw records)은 첫 번째 계층일 뿐입니다. Aura는 경계가 지정된 인지 오버레이(bounded cognitive overlays)를 구축할 수 있습니다:

기록 (Records) → 신념 (Beliefs) → 개념 (Concepts) → 인과 패턴 (Causal Patterns) → 정책 힌트 (Policy Hints)

• 기록 (Records): 관찰, 결정, 선호도 및 결과를 보존합니다.
• 신념 (Beliefs): 뒷받침하거나 상충하는 증거들을 그룹화합니다.
• 개념 (Concepts): 안정적인 신념 전반에 걸쳐 반복되는 추상화를 포착합니다.
• 인과 패턴 (Causal patterns): 반복되는 원인과 결과 관계를 나타냅니다.
• 정책 힌트 (Policy hints): “먼저 스테이징을 선호하라”와 같은 권고 지침을 표면화합니다.

여기서 중요한 단어는 *권고(advisory)*입니다. 정책 힌트는 동작을 실행하지 않습니다. 인지적 재순위화(Cognitive reranking)는 경계가 지정되어 있고, 검사 가능하며, 비활성화할 수 있습니다. 에이전트가 무엇을 할 수 있는지 결정하는 책임은 여전히 애플리케이션에 있습니다.

brain.enable_full_cognitive_stack()

hints = brain.get_surfaced_policy_hints()

이러한 분리는 위험한 설계 패턴, 즉 자동으로 생성된 메모리가 무제한의 권한을 가진 명령(instruction)으로 조용히 변하는 것을 방지하는 데 도움이 됩니다.

검색은 스스로를 설명할 수 있어야 합니다

메모리가 에이전트의 답변에 영향을 미칠 때, "벡터 데이터베이스(vector database)가 이를 반환했습니다"라는 설명만으로는 충분하지 않습니다.

Aura는 다음과 같은 검사 인터페이스(inspection surfaces)를 제공합니다:

brain.explain_recall("deployment decision", top_k=5)
brain.explain_record(record_id)
brain.provenance_chain(record_id)

목표는 메모리 동작을 운영자가 볼 수 있게(operator-visible) 만드는 것입니다. 애플리케이션은 특정 레코드가 왜 나타났는지, 어떻게 유도되었는지, 다른 정보와 충돌하는지, 그리고 수정 사항이 대기 중인지 등을 검사할 수 있습니다.

Aura는 또한 관리되는 수정(governed correction)과 제한된 적응(bounded adaptation)을 지원합니다. 이를 통해 경험(experiences)은 모델 가중치(model weights)를 직접 다시 쓰거나 신뢰도가 높은 지식을 조용히 변이시키는 대신, 검토 가능한 파이프라인(reviewable pipeline)에 진입할 수 있습니다.

1.5.6 버전에서 변경된 사항

1.5.6 릴리스는 연구 및 프로덕션 에이전트에게 매우 중요한 문제, 즉 "그럴듯한 주장(plausible claim)이 검증 가능한 주장(verifiable claim)과 동일하지 않다"는 문제에 집중합니다.

불변의 증거 계보 (Immutable evidence lineage)

증거 계보(Evidence lineage)는 주장을 다음 항목들과 결합합니다:

1. 특정 소스 문서의 리비전(revision);
2. 증거로 사용된 정확한 바이트 범위(byte span);
3. 콘텐츠 해시(content hash);
4. 검증 상태(verification status);
5. 독립적인 답변 권한 결정(independent answer-permission decision).

높은 신뢰도 점수(confidence score)라 할지라도 변경된 소스 해시, 대체된 주장, 또는 차단된 인용 허용을 무시할 수 없습니다. 증거 인식 보고서(Evidence-aware reports)는 허용된 결과만을 구성하여, 차단된 소스 자료가 자유 형식의 합성(free-form synthesis)을 통해 간접적으로 재도입되는 것을 방지합니다.

결정론적 컨텍스트 캡슐 (Deterministic context capsules)

에이전트는 종종 작업을 위해 안정적인 "작업 세트(working set)"가 필요합니다. 광범위한 검색(recall)을 반복 실행하면 불필요한 컨텍스트 혼란(context churn)이 발생할 수 있고, 별도의 위키(wiki)를 유지하는 것은 또 다른 진실의 원천(source of truth)을 만드는 일이 됩니다.

컨텍스트 캡슐(Context capsules)은 기존 메모리에 대해 읽기 전용이며 토큰 제한이 있는 투영(projection)을 제공합니다:

capsule = brain.build_context_capsule(
    purpose="continue the current reliability investigation",
    token_budget=2000,
...

캡슐(capsule)은 각 레코드가 왜 선택되었는지, 얼마나 많은 레코드가 누락되었는지, 예상 토큰 수(token count), 그리고 안정적인 콘텐츠 해시(content hash)를 보고합니다. 차단되었거나 대체된 레코드는 제외됩니다.

관찰 가능한 빈 회상 (Observable empty recall)

“검색이 성공적으로 완료되었으나 아무것도 찾지 못했습니다”는 단순한 빈 리스트가 아니라 하나의 운영 이벤트입니다.

버전 1.5.6에서는 포맷된 회상 (formatted recall), 구조화된 회상 (structured recall), 티어 회상 (tier recall), 그리고 정확한 검색 (exact search) 전반에 걸쳐 전체 및 빈 회상/검색 결과에 대한 카운터를 추가합니다. 이를 통해 빈 회상율 (empty-recall rates)을 모니터링하고, 지식의 부재를 전송 오류나 모델 실패와 구분할 수 있습니다.

한 명의 사용자, 하나의 격리된 메모리 경계

로컬 개발은 간단합니다. 하나의 에이전트 프로세스가 하나의 Aura 디렉토리를 사용할 수 있습니다.

호스팅되는 멀티 유저 시스템에는 명시적인 격리 전략 (isolation strategy)이 필요합니다. 가장 안전한 모델은 각 사용자의 메모리를 별도의 데이터 경계 (data boundary)로 취급하는 것입니다.

from pathlib import Path
from aura import Aura

...

네임스페이스 (Namespaces)를 통해 추가적인 논리적 격리를 제공할 수 있지만, 인증 (authentication)과 인가 (authorization)는 여전히 애플리케이션의 영역입니다. 브라우저 요청으로부터 임의의 저장 경로(storage path)나 네임스페이스를 직접 받아들이지 마십시오.

호스팅되는 TypeScript 프론트엔드의 경우, Aura는 신뢰할 수 있는 백엔드 또는 전용 메모리 서비스 뒤에서 실행되어야 합니다. 프론트엔드는 인증된 API를 호출하며, 서비스는 올바른 사용자 소유의 저장소 (store)를 선택합니다. Python 패키지는 정적 프론트엔드 번들 내부에서 실행되도록 설계되지 않았습니다.

이러한 배포 세부 사항은 놓치기 쉽습니다. 라이브러리는 로컬 설치를 간단하게 만들 수 있지만, 영구 메모리 (persistent memory)는 여전히 어딘가에서 실행되어야 하며 그 데이터는 백업, 암호화, 관찰 및 격리되어야 합니다.

Aura가 하지 않는 것

Aura는 언어 모델 (language model)이 아니며 최종 답변을 생성하지 않습니다. Aura는 검증되지 않은 입력을 사실로 만들지 않습니다. 또한 애플리케이션의 인가 (authorization), 도구 권한 확인 (tool permission checks), 또는 백업 전략을 대체하지 않습니다.

또한 이것은 호스팅된 데이터베이스 서비스(database-as-a-service)도 아닙니다. 서버에 배포할 경우, 런타임(runtime)과 스토리지 라이프사이클(storage lifecycle)에 대한 소유권은 사용자에게 있습니다. 이러한 트레이드오프(tradeoff)는 의도된 것입니다. 로컬 제어와 오프라인 작동에는 운영상의 책임이 따릅니다.

희소 분산 표현(Sparse Distributed Representation) 인덱싱이 기본 로컬 검색 경로이며, 애플리케이션이 필요할 경우 선택적인 임베딩(embeddings)을 제공할 수 있습니다. 성능은 워크로드(workload)와 하드웨어에 따라 달라집니다. 프로젝트에 벤치마크(benchmarks)가 포함되어 있지만, 프로덕션 시스템(production systems)은 자체 코퍼스(corpus)와 액세스 패턴(access patterns)을 직접 측정해야 합니다.

왜 모델 외부에서 메모리를 구축해야 하는가?

모델은 변합니다. 제공업체도 변합니다. 컨텍스트 윈도우(context-window) 가격 정책도 변합니다. 에이전트 메모리가 추론 레이어(inference layer)가 교체될 때마다 사라져서는 안 됩니다.

모델 외부에 메모리를 유지하면 안정적인 경계(boundary)를 생성할 수 있습니다:

에이전트 런타임 (Agent runtime)
    ├── 모델 (model): 추론 및 생성
    ├── 도구 (tools): 세상에서의 행동
...

이러한 경계는 메모리를 모델 간에 이식 가능하게 만들고 독립적으로 검사하기 쉽게 만듭니다. 더 중요한 것은, 운영자가 보존(retention), 출처(provenance), 격리(isolation) 및 수정(correction) 정책을 강제할 수 있는 구체적인 장소를 제공한다는 점입니다.

이 프로젝트는 MIT 라이선스를 따릅니다. GitHub에서 소스 코드와 예제를 탐색하거나, PyPI에서 패키지를 설치하거나, aurasdk.dev에서 개요를 읽어볼 수 있습니다.

저는 특히 다른 개발자들이 다음 세 가지 질문을 어떻게 다루는지에 대해 관심이 있습니다:

1. 대화 기록(conversation history)과 영구 메모리(durable memory) 사이의 경계를 어디에 설정하십니까?
2. 다중 사용자 에이전트(multi-user agents)에서 메모리를 어떻게 격리하십니까?
3. 에이전트가 답변에서 저장된 주장(claim)을 사용하기 전에 어떤 증거를 지녀야 한다고 요구해야 합니까?