r/openclaw에서 작지만 매우 유익한 스레드를 발견했습니다: “What do you use for memory?”.

추천(upvotes) 14개와 댓글 16개가 달렸습니다. Reddit 기준으로 보면 아주 작지만, 니치(niche)한 에이전트 커뮤니티에게는 실질적인 무언가를 끌어내기에 충분한 수치입니다.

요약하자면:

단순한 파일 기반 메모리 (file-based memory)가 많은 사람에게 효과적입니다. 하지만 에이전트가 정확한 사실, 검색 가능한 노트, 요약, 그리고 폴더나 작업 결과물로부터의 주변부 수집 (ambient ingestion)을 처리해야 한다면, 보통 하나 이상의 메모리 유형이 필요합니다.

스레드 전체를 읽고 난 후 제 견해는 다음과 같습니다:

• 정체성 (identity)을 위해서는 **파일 (files)**을 사용하세요.
• 정확한 검색 (exact retrieval)을 위해서는 SQLite FTS5를 사용하세요.
• 퍼지 회상 (fuzzy recall)을 위해서는 **벡터 검색 (vector search)**을 사용하세요.
• 들어오는 데이터 양이 실제로 정당화될 때만 요약 (summarization)을 추가하세요.

결과론적으로는 당연하게 들릴 수 있습니다. 하지만 대부분의 사람들은 에이전트 메모리를 처음 구축할 때 이렇게 하지 않습니다.

이 스레드는 사실 신뢰 경계 (trust boundaries)에 관한 것이었습니다

원문 게시물은 Gbrain, Screenpipe, Letta, 그리고 OpenMemory를 언급했습니다.

겉보기에는 평범한 도구 비교 스레드처럼 보입니다.

하지만 그렇지 않았습니다.

그 밑에 깔린 진짜 질문은 이것이었습니다:

내 노트, 문서, 그리고 개인적인 컨텍스트를 호스팅 서비스로 전송하지 않고 어떻게 OpenClaw 에이전트에게 메모리를 부여할 것인가?

이것이 답변들이 빠르게 주관적으로 변한 이유입니다.

사람들은 추상화 (abstractions)에 대해 논쟁하고 있었던 것이 아닙니다. 그들은 직접 검사하고, 이동하고, 백업하며, 신뢰할 수 있는 로컬 우선 (local-first) 설정을 이야기하고 있었습니다.

실제 워크플로우를 위한 에이전트를 구축하는 사람에게는, 멋진 메모리 데모보다 이것이 훨씬 더 중요합니다.

첫 번째 진영: 일반 파일과 내장 메모리만으로도 충분한 경우가 많다

스레드에서 가장 좋은 답변 중 하나는 기본적으로 다음과 같았습니다:

그냥 기본에 충실하고 중요한 것들을 폴더/파일에 영구 저장하세요.

이것은 기술 반대가 아닙니다. 과잉 엔지니어링 (overengineering)에 반대하는 것입니다.

만약 당신의 OpenClaw 에이전트에게 주로 필요한 것이 다음과 같다면:

• 안정적인 정체성 (identity)
• 몇 가지 지속적인 지침 (persistent instructions)
• 수동으로 저장된 몇 가지 사실들
• 아마도 적은 양의 장기 컨텍스트 (long-term context)

그렇다면 OpenClaw의 내장 메모리 코어 (built-in memory core) / memory_wiki 및 마크다운 (markdown) 파일은 확실한 해답입니다.

이처럼 지루해 보이는 것이 놀라울 정도로 큰 비중을 차지할 수 있습니다:

agent-memory/
├── IDENTITY.md
├── SOUL.md
...

이 방식이 효과적인 이유:

• 로컬 (local) 방식입니다
• 검사 가능 (inspectable) 합니다
• 백업이 쉽습니다
• 실패하더라도 그 방식이 이해 가능합니다
• 약한 의미론적 일치 (semantic matches)를 통해 "메모리"를 지어내지 않습니다

많은 에이전트 (agent) 시스템들이 메모리를 너무 일찍 자동화할 때 성능이 저하됩니다.

단순한 해답이 대화를 끝내지 못한 이유

다른 댓글 작성자가 핵심적인 지점을 짚었기 때문입니다:

메모리는 단일한 검색 (retrieval) 문제가 아닙니다.

이것이 전부입니다.

사람들은 "에이전트 메모리 (agent memory)"를 마치 하나의 기능인 것처럼 말합니다. 하지만 실제로 이는 여러 가지 서로 다른 작업들입니다:

1. 정체성 메모리 (Identity memory) — 에이전트가 누구인지, 어떻게 행동해야 하는지
2. 사실적 메모리 (Factual memory) — 사용자, 시스템, 선호도, 환경에 대한 정확한 사실
3. 검색 가능한 노트 (Searchable notes) — 마크다운 (markdown), 문서 (docs), 이전 요약본, 로그 (logs)
4. 의미론적 회상 (Semantic recall) — "이것은 지난달의 그 일과 관련이 있는 것 같다"는 느낌
5. 주변부 흡수 (Ambient ingestion) — 감시 중인 폴더나 워크플로 (workflows)로부터 자동으로 흘러 들어오는 파일들
6. 압축된 장기 컨텍스트 (Compressed long-term context) — 모델이 실제로 효율적으로 소비할 수 있는 요약본

문제를 이런 식으로 나누고 나면, 대부분의 메모리 논쟁은 더 쉬워집니다.

사람들이 서로 엇갈린 말을 하는 이유는 간단합니다:

그들은 서로 다른 실패 허용 오차 (failure tolerances)를 가진 서로 다른 메모리 작업들을 해결하고 있기 때문입니다.

SQLite vs 벡터 (vectors): 정확한 사실 vs 모호한 유사성

해당 스레드에서 가장 강력한 기술적 논점은 이것이었습니다:

임베딩 (embeddings)은 가치 (values)가 아니라 분위기 (vibes)를 검색합니다.

가혹한 표현이지만, 대부분 맞습니다.

벡터 검색 (Vector search)은 다음과 같은 작업에 탁월합니다:

• 관련 개념
• 모호한 매칭 (fuzzy matching)
• 주제별 회상 (thematic recall)
• "이것과 유사한 것을 찾아줘"

벡터 검색은 다음과 같은 작업에 취약합니다:

• 정확한 사실
• 결정론적 검색 (deterministic retrieval)
• 구조화된 진실 쿼리 (structured truth queries)
• "X의 현재 값은 무엇인가?"

만약 당신의 에이전트가 다음을 기억해야 한다면:

• 클라이언트가 송장을 PDF로 받기를 원함
• Raspberry Pi의 IP가 192.168.1.42임
• 워크플로 (workflow)는 오전 10시 이전에 절대 실행되어서는 안 됨
• 사용자가 계획 수립에는 Claude Opus 4.6을, 도구 사용에는 GPT-5.4를 선호함

그렇다면 의미론적 유사성 (semantic similarity)만으로는 충분하지 않습니다.

이 지점에서 SQLite FTS5가 제 역할을 다합니다.

실제로 말이 되는 실용적인 구분

만약 제가 이 스레드 전체를 한 문장으로 요약해야 한다면:

정체성에는 파일을, 사실 (facts)에는 SQLite를, 그리고 모호한 회상 (fuzzy recall)에는 벡터 (vectors)를 사용하세요.

이 스택은 유행을 따르는 것은 아닙니다. 하지만, 반박하기 매우 어렵습니다.

매우 단순한 로컬 메모리 스택

실용적인 것을 원하신다면, 여기서부터 시작하세요.

1) 마크다운 (markdown)에 정체성 유지하기

# IDENTITY.md
당신은 나의 로컬 OpenClaw 어시스턴트입니다.

...

2) SQLite FTS5로 노트 인덱싱하기

로컬 인덱스를 생성합니다:

CREATE VIRTUAL TABLE memory_index USING fts5(
  path,
  title,
...

예시 행은 다음과 같을 수 있습니다:

• IDENTITY.md
• SOUL.md
• MEMORY.md
• AGENTS.md
• docs/*.md
• notes/**/*.md

단순한 쿼리:

SELECT path, title
FROM memory_index
WHERE memory_index MATCH 'invoice AND PDF';

이 방식은 추론 (reasoning)을 하는 척하지 않고도, 정확에 가까운 어휘 검색 (lexical retrieval)을 제공합니다.

3) 파일 인제스터 (file ingester) 추가하기

Node.js에서 아주 작은 인제스션 (ingestion) 스크립트를 연결할 수 있습니다:

import Database from 'better-sqlite3';
import fs from 'fs';
import path from 'path';
...

이것이 화려한가요? 전혀 그렇지 않습니다.

디버깅이 가능한가요? 매우 그렇습니다.

더 숙련된 빌더들이 하고 있던 것

사람들이 실제 로컬 스택을 설명하면서 스레드는 더욱 흥미로워졌습니다.

SQLite FTS5 설정

한 댓글 작성자는 better-sqlite3와 Porter tokenizer를 사용한 커스텀 SQLite FTS5 설정을 설명했습니다.

그들은 다음과 같은 파일들을 인덱싱하고 있었습니다:

• MEMORY.md
• SOUL.md
• IDENTITY.md
• AGENTS.md
• 도구 문서 (tool documentation)
• 중첩된 memory/*/*.md 파일들

이것은 중대한 설계 결정입니다.

이는 다음을 의미합니다:

• 마크다운 (markdown)이 신뢰할 수 있는 단일 원천 (source of truth)이다
• 메모리는 검사 가능하다 (inspectable)
• 검색 (retrieval)은 우선적으로 결정론적 (deterministic)이어야 한다
• 마법 같은 것보다 로컬 (local) 방식이 낫다

저는 이것이 대부분의 개발자에게 올바른 직관이라고 생각합니다.

LanceDB 파이프라인

또 다른 댓글 작성자는 LanceDB를 활용한 더 자동화된 설정을 설명했습니다.

그 패턴은 다음과 같았습니다:

1. 상위 폴더를 감시 (watch)
2. 하위 디렉토리의 파일들을 수집 (ingest)
3. 로컬 모델 (local models)로 요약 (summarize)
4. 원본 콘텐츠 + 요약 + 태그를 LanceDB에 저장
5. 나중에 의미론적 (semantically)으로 검색

그들의 스택에는 다음이 포함되었습니다:

• 로컬 임베딩 (embeddings) 모델
• 요약을 위한 Qwen-Instruct
• 추론 (reasoning)을 위한 deepseek-7b-4bit

이것은 "채팅 메모리 (chat memory)"가 아닙니다.

이것은 로컬 지식 파이프라인 (local knowledge pipeline)입니다.

만약 당신의 에이전트 (agent)가 회의록, 브라우저 캡처, 프로젝트 문서, 그리고 무작위 작업 결과물들을 가져와 사용한다면, 그러한 아키텍처 (architecture)는 타당합니다.

하지만 훨씬 더 많은 구성 요소 (moving parts)가 필요합니다.

벡터 메모리를 아직 추가해서는 안 되는 경우

이 지점이 많은 에이전트 빌더들이 실수하는 부분이라고 생각합니다.

그들은 무엇이 사실(fact)로 간주되는지 결정하기도 전에 다음과 같은 것들부터 시작합니다:

• 임베딩 (embeddings)
• 벡터 데이터베이스 (vector DB)
• 요약 (summarization)
• 에이전트 기반 검색 (agentic retrieval)
• 자동 영속성 (automatic persistence)

이는 대개 데모에서는 똑똑해 보이지만, 실제 운영 (production) 환경에서는 불안정한 메모리 시스템을 만듭니다.

만약 당신의 주요 문제가 다음 중 하나라면, 벡터 메모리를 먼저 추가하지 마세요:

• "에이전트가 정확한 선호도를 기억해야 한다."
• "마크다운 문서로부터 신뢰할 수 있는 조회가 필요하다."
• "검사 가능한 로컬 영속성 (local persistence)이 필요하다."
• "에이전트가 왜 무언가를 검색했는지 디버깅 (debug)해야 한다."

그러한 경우에는 파일과 SQLite로 시작하세요.

벡터는 나중에 추가하십시오.

OpenClaw 메모리를 위한 좋은 경험칙

다음의 단계적 진행을 사용하세요:

1단계: 파일 기반 메모리 (file-based memory)

마크다운 (markdown) 파일만 사용합니다.

가장 적합한 경우:

• 정체성 (identity)
• 지침 (instructions)
• 안정적인 선호도 (stable preferences)
• 소규모 설정 (tiny setups)

2단계: SQLite FTS5

마크다운(markdown)과 문서(docs) 전반에 걸쳐 어휘 검색 (lexical search) 기능을 추가합니다.

가장 적합한 경우:

• 정확한 텍스트 검색 (exact text retrieval)
• 로컬 우선 시스템 (local-first systems)
• 결정론적 동작 (deterministic behavior)
• 쉬운 디버깅 (easy debugging)

3단계: 벡터 검색 (vector search)

의미론적 회상 (semantic recall)이 필요한 경우에만 LanceDB 또는 다른 벡터 저장소 (vector store)를 추가합니다.

가장 적합한 경우:

• 관련 노트 발견 (related-note discovery)
• 퍼지 매칭 (fuzzy matching)
• 대규모 노트 컬렉션
• 무질서한 비정형 콘텐츠 (unstructured content) 전반에 걸친 검색

4단계: 요약 파이프라인 (summarization pipeline)

유입되는 데이터 양이 너무 많아 원시 검색 (raw retrieval) 결과에 노이즈가 발생하는 경우에만 로컬 요약 (local summarization)을 추가합니다.

가장 적합한 경우:

• 회의록 (meeting notes)
• 대량의 파일 드롭 (large file drops)
• 브라우저 캡처 아카이브 (browser capture archives)
• 워크플로 산출물 (workflow artifacts)

이 순서는 매우 중요합니다.

대부분의 개발자가 관심을 가질 부분: 운영 (operations)

OpenClaw 사용자들에게 로컬 메모리가 승리하는 또 다른 이유가 있습니다.

운영 측면에서 합리적 (operationally sane)이라는 점입니다.

다음과 같은 작업이 가능합니다:

• 기기 간 복사
• Git을 이용한 일부 구성 요소의 버전 관리
• 일반적인 도구를 사용한 백업
• 손상 여부 직접 검사
• 필요 시 인덱스 (indexes) 재구축
• 민감한 데이터를 제3자 서버로부터 격리

폴더 하나와 SQLite 파일은 흥미진진하지 않습니다.

하지만 그것이 바로 끝까지 살아남는 '지루한 인프라 (boring infrastructure)'의 전형입니다.

이러한 본능은 지속성 (persistence), 기기 간 마이그레이션 (migration), 그리고 설정이 업무용으로 충분히 견고한지 여부와 같은 인접한 OpenClaw 논의에서도 나타납니다.

메모리는 이러한 우려 사항들이 더 이상 이론에 머물지 않는 지점입니다.

이것이 AI 자동화 비용과 관련 있는 이유

이 부분은 충분히 논의되지 않는 부분입니다.

일단 "챗봇 메모리"에서 **실제 에이전트 워크플로 (real agent workflows)**로 넘어가게 되면, 비용 프로필이 변화합니다.

이제 다음과 같은 작업들을 수행하게 됩니다:

• 긴 실행 시간 동안 메모리에 반복적으로 쿼리 (querying) 수행
• 유입되는 파일 요약
• 검색 (retrieval) 단계와 추론 (reasoning) 단계 사이의 라우팅 (routing)
• n8n, Make, Zapier, OpenClaw 또는 맞춤형 자동화에서 에이전트를 24/7 실행
• 백그라운드 작업이 문서, 노트, 산출물을 지속적으로 처리하도록 허용

이는 메모리 아키텍처 (memory architecture)와 컴퓨팅 가격 책정 (compute pricing)이 서로 연결되어 있음을 의미합니다.

데이터 수집 (ingestion), 요약 (summarization), 그리고 다단계 검색 (multi-step retrieval)을 포함하는 메모리 스택은 토큰 기반 과금 (token-metered) API를 빠르게 소진할 수 있습니다.

이것이 에이전트 빌더 (agent builders)들에게 예측 가능한 컴퓨팅 (predictable compute)이 매우 중요한 이유 중 하나입니다.

만약 여러분이 OpenClaw나 자동화 워크플로우 (automation workflows)를 OpenAI 호환 API에 연결하여 사용하고 있다면, 메모리 사용량을 늘리거나 또 다른 백그라운드 에이전트를 추가할 때마다 토큰 지출을 일일이 감시하고 싶지는 않을 것입니다.

그것이 바로 Standard Compute가 해결하고자 하는 문제입니다. OpenAI 호환 API를 사용하여 고정된 월간 가격으로 무제한 AI 컴퓨팅을 제공함으로써, 비용에 대한 불안감 없이 에이전트 워크플로우를 실행할 수 있게 합니다.

메모리 집약적인 자동화의 경우, 이러한 가격 모델은 토큰당 비용을 걱정하는 것보다 훨씬 더 합리적입니다.

대부분의 진지한 로컬 OpenClaw 사용자들을 위한 추천 스택

만약 제가 오늘 메모리 시스템을 구축한다면, 다음과 같이 구성하겠습니다:

1. OpenClaw memory_wiki 또는 일반 마크다운 (markdown) 파일: 정체성 (identity) 및 지속적인 지침 (durable instructions) 용도
2. SQLite FTS5: 노트, 문서, 메모리 파일 전반에 걸친 정확한 검색 (exact retrieval) 용도
3. LanceDB: 시맨틱 회상 (semantic recall)이 명확히 필요한 경우에만 사용
4. Qwen-Instruct 또는 다른 로컬 요약 모델 (summarizer): 데이터 수집 (ingestion) 볼륨이 실제로 커진 이후에만 사용
5. 더 강력한 추론 모델 (reasoning model): 에이전트가 검색된 자료를 종합 (synthesize)해야 할 때만 사용

이러한 순서는 많은 고통을 피하게 해줍니다.

또한 이는 훌륭한 시스템이 진화하는 방식과도 일치합니다. 즉, 명시적이고 검사 가능한 (inspectable) 방식에서 시작하여, 워크플로우가 요구할 때만 더 자동화된 방식으로 넘어가는 것입니다.

최종 결론

해당 r/openclaw 스레드의 가장 좋은 점은 가짜 승자를 만들어내지 않았다는 것입니다.

모두가 서로 다른 관점에서 옳았습니다.

파일 전용 (file-only) 방식을 주장한 사람들은 메모리가 빠르게 지나치게 복잡해질 수 있다는 점에서 옳았습니다.

하이브리드 (hybrid) 방식을 주장한 사람들은 하나의 검색 방법이 다섯 가지의 서로 다른 작업을 수행할 수는 없다는 점에서 옳았습니다.

그리고 SQLite 방식을 주장한 사람들은 특히 정확한 사실에는 정확한 검색 (exact retrieval)이 필요하다는 점에서 옳았습니다.

OpenClaw를 위한 메모리를 구축하고 있다면, 다음과 같은 사고 모델을 유지하시기 바랍니다:

• 정체성(identity)은 파일에 속해야 한다
• 사실(facts)은 쿼리 가능한(queryable) 무언가에 속해야 한다
• 의미론적 회상(semantic recall)은 벡터(vectors)에 속해야 한다
• 요약(summaries)은 기초(foundation)가 아닌 다운스트림(downstream)에 속해야 한다

임베딩(embeddings)에게 데이터베이스(database) 작업을 시키지 마세요.

그것이 이 스레드 전체에서 가장 깔끔한 교훈입니다.

그리고 메모리 아키텍처(memory architecture)가 중요할 정도로 에이전트(agents)를 충분히 오래 실행하고 있다면, 그 밑단의 컴퓨팅 레이어(compute layer)에 대해서도 똑같이 신경을 써야 합니다. 예측 불가능한 토큰당 과금(per-token billing) 방식 위에서 화려한 메모리를 구축하는 것은 스스로에게 새로운 운영상의 골칫거리를 만들어주는 아주 좋은 방법입니다.

만약 잘 작동하는 OpenClaw 메모리 스택을 구축하셨다면, 어떤 검색 분할(retrieval split) 방식을 선택하셨는지 꼭 듣고 싶습니다.