← 번역 목록으로

Limited Edition Jonathan · 2026년 3월 23일

그걸 메모리라고 부르지 마세요: 모든 \"AI + Obsidian\" 튜토리얼의 문제점

번역Limited Edition Jonathan원문 보기 ↗

그걸 메모리라고 부르지 마세요: 모든 "AI + Obsidian" 튜토리얼의 문제점

매주 제 피드에는 "Obsidian + Claude Code로 AI 세컨드 브레인을 만들었다"는 글이 또 하나씩 올라옵니다. Medium 글, Substack 글, 빛나는 마크다운 파일로 만들어진 두뇌 썸네일을 단 YouTube 영상까지. 다들 숨도 안 쉬고 어떻게 Claude를 Obsidian 볼트에 욱여넣어 "영구 메모리"와 "자비스급" 개인 비서 기능을 구현했는지 설명합니다.

이 얘기는 꼭 해야겠습니다. 지금 벌어지고 있는 일은 제가 AI 분야에서 본 것 중 가장 명확한 인플루언서-카고컬트 파이프라인 사례 중 하나거든요. 만약 이런 조언 위에 무언가를 쌓아 올리고 있다면, 당신은 정작 시스템이 제대로 동작해야 하는 순간에 무너져 내릴 토대 위에 모든 걸 짓고 있는 셈입니다.

하지만 우선 공정하게 가겠습니다. Obsidian 진영이 전부 틀린 건 아니거든요. 그저 가장 중요한 부분에서 틀렸을 뿐입니다.

Obsidian을 위한 가장 강한 변호 (정말로 가장 강력한 버전)

Obsidian 진영에 정당한 몫을 돌려드리죠. 이 조합이 사람들에게 매력적인 데에는 정당한 이유가 있고, 그걸 묵살하는 건 지적으로 게으른 일이니까요.

데이터를 완전히 로컬에서 소유합니다. 클라우드 의존성도, 독점 포맷도, 벤더 종속도 없습니다. 노트는 그냥 하드 드라이브에 있는 일반 텍스트 파일이에요. Obsidian이 내일 사라져도 모든 파일은 그대로 남아 있습니다. 이건 진짜 장점입니다. SaaS 도구가 서비스를 종료하거나 API를 바꿔서 데인 경험이 있다면 이게 왜 중요한지 이해하실 겁니다. Notion(데이터가 그들의 API 뒤, 그들의 포맷으로 사는)과 비교하면 데이터 주권 면에서 의미 있게 더 낫습니다.

LLM은 마크다운을 네이티브로 읽습니다. 변환 계층이 없습니다. Claude가 .md 파일을 읽을 때, 그것은 자신이 학습된 바로 그 포맷을 흡수하는 겁니다. 헤딩, 불릿, 일반 텍스트, 전부 그냥 동작합니다. API 호출도, JSON 파싱도, 미들웨어도 없습니다. 노트와 모델 사이의 마찰이 사실상 0입니다.

모든 것이 사람이 읽고 편집할 수 있습니다. 볼트의 어떤 파일이든 열어서 AI가 "알고 있는" 내용을 정확히 보고 텍스트 에디터로 바꿀 수 있습니다. 데이터베이스가 기본으로 제공하지 않는 투명성이 있죠. 내용을 들여다보기 위해 특별한 도구가 필요 없습니다.

위키링크 시스템이 가벼운 연결을 만들어 줍니다. Obsidian의 [[wikilink]] 문법은 노트 간 양방향 링크를 제공하고, 그래프 뷰는 그 연결을 시각적으로 보여줍니다. 데이터베이스를 건드리지 않고도 얻을 수 있는 가장 관계형 데이터에 가까운 형태죠.

셋업 비용 0. Obsidian은 무료입니다. 볼트 폴더에서 터미널을 열고 claude만 치면 Claude Code가 모든 것에 접근할 수 있습니다. 설계할 스키마도, 프로비저닝할 데이터베이스도, 배워야 할 SQL도 없습니다. 테이블과 쿼리의 차이를 모르는 사람에게 이건 가능한 가장 낮은 진입 장벽입니다.

Git 친화적인 버전 관리. 지식 베이스 전체가 diff 가능하고, 브랜치가 가능하며, 전체 히스토리가 남습니다. 무엇이 언제 바뀌었는지 정확히 볼 수 있고, 뭔가 망가지면 롤백할 수 있죠.

Steph Ango의 Obsidian Skills는 잘 설계되어 있습니다. Obsidian의 CEO는 2026년 1월에 공식 Agent Skills를 공개했고, 이 스킬들은 Claude Code에게 Obsidian의 파일 포맷을 올바르게 다루는 법을 가르칩니다. 마크다운 문법, Bases 데이터베이스, JSON Canvas, CLI 명령. 이들은 합법적이고 적절히 범위가 좁혀진, 자기가 주장하는 그대로의 도구들입니다.

여기까지가 변호입니다. 솔직히 말해, 개인 노트 시스템으로, 아이디어를 캡처하기 위한 도구로, 직접 둘러보고 가꾸는 지식 정원을 만들기 위한 도구로 Obsidian은 훌륭합니다. 노트 앱으로서의 Obsidian에는 아무 불만도 없습니다.

문제는 사람들이 그걸 메모리라고 부를 때 시작됩니다. 데이터베이스라고 부를 때 시작됩니다. AI 생산성 콘텐츠 생태계 전체가 텍스트 파일이 든 폴더를 인프라라고 결정해 버릴 때 시작됩니다.

우리가 어쩌다 여기까지 왔나 (나쁜 아이디어의 고고학)

이건 우연이 아닙니다. 정당한 도구 설계에서 집단 망상까지 이어지는 분명한 자취가 있고, 그 자취를 따라가 보는 게 중요합니다. 사고가 정확히 어디서 어긋났는지 보여주거든요.

1단계: Tiago Forte가 "세컨드 브레인"을 기본 메타포로 만들었습니다.

"Building a Second Brain" 방법론(PARA, CODE)은 2017년 무렵부터 거대한 생산성 운동이 됐습니다. Obsidian의 홈페이지에는 한때 "A Second Brain. For You. Forever."라는 문구가 그대로 박혀 있었습니다. 그 표현이 커뮤니티 정체성에 깊이 새겨졌습니다. 원래 개념은 노트 작성과 지식 관리에 관한 것이었어요. 생각을 외부에 정리해 두면 진짜 두뇌는 사고에만 집중할 수 있다는 것. 합리적인 아이디어죠. "세컨드 브레인"은 잘 정리된 파일링 시스템에 대한 메타포였습니다.

하지만 메타포에는 결과가 따릅니다. 노트를 "두뇌"라고 부르기 시작하면, 사람들은 두뇌 같은 능력을 기대하기 시작합니다. 그리고 AI가 등장하면, "세컨드 브레인"은 더 이상 메타포가 아니라 제품 주장이 됩니다.

2단계: Anthropic이 CLAUDE.md와 Skills를 만들었습니다.

여기서부터 기술적으로 흥미로워지고, 혼란이 실제로 시작됩니다. Anthropic은 CLAUDE.md를 Claude Code의 프로젝트 스코프 지시 파일로 도입했습니다. Claude Code를 어떤 디렉토리에서 실행하면 시작 시 자동으로 CLAUDE.md를 읽습니다. 이 파일은 Claude에게 "이건 Python 프로젝트야. pytest를 써. CI 설정은 건드리지 마." 같은 것들을 알려줍니다. 이건 설정 파일입니다. .bashrc나 .env에 해당하죠.

그리고 Anthropic은 Skills를 도입했습니다. YAML 프론트매터가 달린 마크다운 파일로, 슬래시 명령으로 트리거되는 프롬프트 템플릿으로 동작합니다. /checkin은 행동을 정의하는 241줄짜리 프롬프트를 로드합니다. 마크다운은 프롬프트지, 저장된 데이터가 아닙니다.

이 둘 다 지시 전달 메커니즘입니다. Claude에게 어떻게 행동하고 어디를 봐야 할지 알려주죠. 당신의 삶에 대한 사실, 프로젝트 세부 정보, 연락처는 단 하나도 들어 있지 않습니다. 이 모든 파일을 .txt로 이름을 바꿔도 아무것도 달라지지 않을 겁니다. Claude는 그게 CLAUDE.md든 CLAUDE.txt든 CLAUDE.csv든 신경 쓰지 않습니다. 텍스트 콘텐츠를 파싱할 뿐이거든요.

하지만 포맷이 .md입니다. 그리고 자동 로드됩니다. 이 둘의 조합이 사람들이 보고 잘못 해석할 수 있는 패턴을 만들었습니다.

3단계: OpenClaw가 결정적인 아키텍처적 실수를 저질렀습니다.

OpenClaw는 자체 호스팅 멀티 채널 AI 에이전트 게이트웨이(WhatsApp, Telegram, Discord, Slack)입니다. 야심차고 흥미로운 프로젝트입니다. 하지만 그들이 내린 한 가지 결정이, 본인들도 예상치 못한 방식으로 파장을 일으켰습니다. 바로 MEMORY.md를 말 그대로의 메모리 저장소로 사용하고, memory/YYYY-MM-DD.md에 일일 로그 파일을 두는 결정이었죠.

그들의 문서는 명시적으로 "파일이 진실의 원천(source of truth)"이라고 말하고, 모델이 디스크에 기록된 것만 "기억"한다고 합니다. 그들은 이걸 "마크다운 우선 메모리 아키텍처"로 브랜딩했습니다.

여기서 핵심은 이겁니다. OpenClaw조차도 이게 실제로는 확장되지 않는다는 걸 알고 있습니다. 그들은 검색을 작동시키기 위해 SQLite 인덱싱과 벡터 검색(BM25 + 임베딩 모델 기반 시맨틱 검색)을 위에 덧붙였습니다. 단순히 평면 마크다운 파일을 읽는 것만으로는 통하지 않는다는 걸 발견했기 때문이죠. memsearch 라이브러리는 말 그대로 OpenClaw 코드베이스에서 독립 도구로 떼어내졌습니다. 커뮤니티가 게이트웨이 전체를 끌어들이지 않고도 검색 기능이 필요했기 때문입니다. 2026년 2월의 GitHub 이슈는 그 위에 무언가를 쌓고 있는 모두가 봐야 했을 말을 합니다. "OpenClaw의 메모리는 마크다운 파일로 만들어졌습니다. 장기적으로 확장 가능하지 않습니다."

하지만 콘텐츠 크리에이터들은 그 아래에 깔린 SQLite를 보지 못했습니다. 위에 올라간 .md 파일만 보고는 마크다운이 마법의 재료라고 세상에 떠벌렸죠.

4단계: Obsidian의 CEO가 Agent Skills를 공개했습니다 (2026년 1월).

Steph Ango는 Obsidian용 공식 Agent Skills를 공개했고, 이는 AI 에이전트에게 Obsidian의 전용 파일 포맷을 올바르게 다루는 법을 가르칩니다. 이 스킬들은 잘 설계되어 있고 적절히 범위가 좁혀져 있습니다. Claude Code에게 위키링크, 프론트매터, Bases 데이터베이스, JSON Canvas 파일의 올바른 문법을 가르치죠.

하지만 타이밍이 기름 같았습니다. 저장소는 GitHub 별 13.9k+를 찍었습니다. 콘텐츠 크리에이터들은 후크를 얻었죠. "Obsidian의 CEO가 방금 AI 통합을 공식화했다!" 스킬 자체는 메모리 시스템임을 주장하지 않습니다. 그저 포맷 명세일 뿐이죠. 메모리 내러티브는 커뮤니티가 그 위에 덧붙인 겁니다.

5단계: 콘텐츠 크리에이터 증폭 루프 (2026년 2월~3월).

그리고 댐이 무너졌습니다. 약 6주 동안 일어난 일들의 일부 목록입니다.

"World of AI"(YouTube 채널)는 Claude Code + Obsidian을 "AI의 메모리 문제에 대한 해법"으로 프레이밍했습니다. Geeky Gadgets가 그걸 받아 실었죠.

Chase AI는 CLAUDE.md를 "전두엽 피질"에 비유하며 몇 달 안에 "자비스급" 개인 비서 기능을 약속하는 가이드를 발행했습니다.

"Learn With Me AI"(이 글을 쓰는 시점으로부터 6일 전)는 "매 세션마다 Claude에게 다시 설명하는 걸 멈춰라. 영구 메모리 시스템을 만들었다"는 글을 올렸습니다. 저자는 자신이 Obsidian 전문가가 아니라고 솔직히 인정한 다음, "Claude Code에 연결된다. 그게 중요한 전부다"라고 말합니다.

XDA Developers는 CLAUDE.md를 "Claude의 메모리"라고 부르는 글을 실으면서, 영감의 출처로 "Coding with ADHD YouTube 채널"을 언급했습니다.

그 다음엔 GitHub 저장소들이 쏟아졌습니다. Claudesidian. obsidian-memory-for-ai. claude-note. 각각이 점점 더 정교한 비계를 같은 근본 아이디어 주위에 짓고 있습니다. 마크다운 파일이 곧 메모리라는 아이디어 말이죠.

콘텐츠 생태계 전체가 몇 주 만에 형성됐습니다. 각 글이 이전 글들을 검증의 근거로 인용하고, 그 누구도 그 토대 가정에 의문을 제기하지 않았습니다. 원래 메시지("CLAUDE.md는 설정 파일이다")가 "마크다운 파일이 AI에게 두뇌를 준다"로 변질되는 동안 그 사슬 어디에서도 그게 사실인지 확인하는 사람이 없었던, 일종의 전화 게임이죠.

"메모리"가 실제로 의미하는 것 (그리고 이 시스템들이 실제로 하는 일)

속도를 늦추고, 이런 Obsidian 셋업들이 Claude에게 "메모리"를 준다고 주장할 때 기계적으로 실제로 무엇을 하고 있는지 이야기해 봅시다.

  1. Claude가 .md 파일을 컨텍스트 윈도우로 읽어들임
  2. Claude가 그 파일에서 정보를 읽음
  3. Claude가 갱신된 정보를 다시 그 파일에 씀

그게 전부입니다. 이게 시스템의 전부예요. "메모리"는 그 파일들에 들어가는 텍스트, 그리고 주어진 세션 동안 Claude가 컨텍스트 윈도우로 로드하는 어떤 내용 그 자체입니다.

이건 일정 규모까지는, 매우 특정한 사용 사례에서는, 작동합니다. 그리고는 작동을 멈춥니다.

앞서 변호 섹션에서 나열한 각 장점이 한계에 부딪히는 지점을 보여드리죠.

"LLM은 마크다운을 네이티브로 읽는다"는 사실이지만, 그 읽기의 메커니즘은 파일 전체를 컨텍스트 윈도우에 던져 넣는 것입니다. 그건 쿼리가 아닙니다. 무차별 대입이죠. "메모리"가 50개의 노트일 때는 괜찮습니다. 500개가 되면 매 세션마다 관련 없는 컨텍스트에 토큰을 태우게 됩니다. 5,000개가 되면, 사용할수록 더 느려지고, 더 비싸지고, 덜 정확해지는 시스템을 만든 셈입니다. 컨텍스트 윈도우는 데이터베이스가 아닙니다. 그걸 데이터베이스처럼 다루는 건 모든 식재료를 한꺼번에 카운터에 올려놓고 식당 주방을 운영하려는 것과 같습니다.

"사람이 읽을 수 있다"는 항목이 50개일 때 좋습니다. 955개의 구조화된 레코드(제 실제 시스템이 가진 숫자)에서는 아무도 필요한 걸 찾으려고 마크다운 파일을 읽지 않습니다. 쿼리가 필요하죠. "필라델피아에서 비디오 프로젝트로 함께 일했던 사람 모두 보여줘"는 SQL 한 문장이면 밀리초 안에 답이 나오는 질문입니다. 마크다운 기반 시스템에서는 모든 파일을 읽고, 포맷이 일관됐기를 빌고, Claude가 모든 관련 언급을 잡아내기를 기도해야 하는 일이죠.

"위키링크가 관계를 만든다"는 기술적으로는 사실이지만, 시각화를 넘어서는 어떤 용도로도 실질적으로 쓸모가 없습니다. Obsidian의 그래프 뷰는 노트들 간의 연결을 보여줍니다. 예쁘죠. 하지만 쿼리할 수가 없습니다. "Supabase를 쓰는 프로젝트와 연결된 사람을 모두 찾아 줘" 같은 트래버설을 시킬 수 없습니다. 다중 홉 관계 조회를 할 수 없습니다. "이 두 무관한 프로젝트를 연결하는 개념은 무엇이지?"라고 물을 수도 없습니다. 링크된 마크다운 파일들의 폴더는 그래프 데이터베이스가 아닙니다. 벽에 붙은 포스트잇 거미줄이 관계형 스키마가 아닌 것과 마찬가지죠.

"셋업 비용 0"이 저를 가장 열받게 하는 부분인데, 가장 유혹적인 장점이자 가장 위험한 함정이기 때문입니다. 네, 즉시 시작할 수 있죠. 네, 설정할 게 아무것도 없습니다. 하지만 셋업 비용 0이라는 건 구조 0이라는 뜻이고, 그건 데이터를 선형적으로 읽는 것 외에는 쿼리, 필터, 정렬, 집계 그 어떤 것도 할 수 없다는 뜻입니다. 데이터베이스가 요구하는 "셋업 비용"은 오버헤드가 아닙니다. 시스템을 실제로 작동하게 만드는 부분이죠. 그걸 건너뛰는 건 콘크리트를 붓는 데 시간이 오래 걸린다는 이유로 집의 기초를 건너뛰는 것과 같습니다. 집은 더 빨리 올라갑니다. 그리고 무너지기도 하죠.

진짜 시스템은 이렇게 생겼습니다

저는 Mac Mini 위에서 100% Anthropic 인프라(Claude Code) 위에 돌아가고 Telegram에 연결되어 실시간 상호작용을 하는 개인 비서 시스템을 만들고 있습니다. 진짜 메모리, 진짜 컨텍스트 관리가 있고, 두 가지 모두 우아하게 처리됩니다. 텍스트 파일이 데이터베이스인 척하는 대신 진짜 솔루션을 쓰고 있기 때문이죠.

스택은 이렇게 생겼습니다: (네 — 제 개인 AI 비서가 저 대신 이 영상을 만들었습니다)

SQLite (claude-memory.db, 832KB): 22개 카테고리에 걸친 955개의 구조화된 메모리. 67개의 이메일 상호작용. 49개의 세션 로그. 작업 큐. 키-값 저장소. 모두 인덱스되어 있고, 모두 쿼리 가능합니다.

Kuzu Graph DB (kuzu-graph/, 81MB): 726개의 노드(사람 475명, 프로젝트 116개, 개념 54개, 도구 43개). 12가지 관계 타입(KNOWS, WORKS_ON, PROJECT_USES 등)에 걸친 852개의 관계.

이 두 DB 모두 매일 자라고 있습니다.

Telegram 네이티브 채널: 실시간 푸시 메시징. 폴링 없음.

4개의 자율 에이전트 (Lex + data-miner + video-producer + content-scout): 각각 작업 로그, 처리 상태, 렌더 큐, 지식 베이스를 위한 자기만의 로컬 SQLite DB를 가집니다.

이 시스템에서 .md 파일은? 4개 파일에 걸쳐 총 636줄입니다. CLAUDE.md(123줄)는 부팅 지시서, 즉 설정 파일입니다. skill.md(241줄)는 프롬프트 템플릿입니다. 각 에이전트의 CLAUDE.md 파일은 직무 기술서입니다. 그 어디에도 제 삶이나 일에 대한 사실은 단 하나도 들어 있지 않습니다. 그것들은 Claude에게 어떻게 행동하고 어디를 봐야 할지 알려줄 뿐입니다. 실제 지식은 데이터베이스에 살고 있습니다.

마크다운 파일로는 말 그대로 할 수 없는, SQLite로 할 수 있는 일들입니다.

-- "필리에서 비디오 프로젝트로 함께 일한 사람은 누구지?"
SELECT DISTINCT content FROM memories
WHERE category='client' AND content LIKE '%Philly%';

-- "작년에 비슷한 일에 얼마를 받았지?"
SELECT topic, content FROM memories
WHERE category='business' AND tags LIKE '%pricing%'
ORDER BY created_at DESC;

-- "이 사람에 대해 내가 아는 모든 것 보여줘"
SELECT * FROM memories WHERE content LIKE '%John Torres%';
SELECT * FROM email_interactions WHERE contact_name LIKE '%John%';

그리고 파일로는 불가능한, 그래프 데이터베이스로 할 수 있는 일들입니다.

-- 관계 트래버설: "내가 아는 사람 중에
-- 내가 연결된 프로젝트에서도 일하는 사람은?" (2-홉 트래버설)
MATCH (j:Person {name: 'Jonathan Edwards'})-[:KNOWS]->(p:Person)
      -[:WORKS_ON]->(proj:Project)
RETURN p.name, proj.name

-- "이 두 무관한 프로젝트를 연결하는 개념은 무엇이지?"
MATCH (p1:Project)-[:PROJECT_EXPLORES]->(c:Concept)
      <-[:PROJECT_EXPLORES]-(p2:Project)
WHERE p1.name <> p2.name
RETURN p1.name, c.name, p2.name

이걸 마크다운 파일 폴더로 시도해 보세요. 모든 파일을 읽고, 텍스트를 파싱하고, 몇 달치 입력에 걸쳐 일관되게 포맷팅했기를 빌어야 하고, 그러고도 관계 트래버설은 여전히 못합니다. 그래프 쿼리는 726개 노드에 걸친 숨은 연결을 밀리초 안에 찾아냅니다. 마크다운 grep은 문자열 일치를 찾고는 그게 끝입니다.

그리고 맥락을 위한 실제 숫자입니다. SQLite 데이터베이스에는 클라이언트, 프로젝트, 개인 노트, 창작 작업, 비즈니스 데이터, 자산에 걸친 955개의 구조화된 레코드가 832KB 안에 들어 있습니다. Kuzu 그래프 데이터베이스에는 6개의 노드 타입과 12개의 관계 타입에 걸쳐 726개의 노드와 852개의 관계가 81MB로 들어 있습니다. 이메일 상호작용(연락처 정보, 날짜, 제목, CC가 교차 참조된 67개의 스레드)은 SQLite 안에 살고 있습니다. 각 자율 에이전트는 작업 로그, 처리 상태, 렌더 큐, 지식 베이스, 음성 프로필을 위한 자기만의 로컬 SQLite DB(약 200KB씩)를 가집니다. 시스템 전체의 .md 지시 파일 합계는? 636줄입니다.

데이터베이스가 지식을 담고 있습니다. .md 파일은 그 지식을 어떻게 사용할지에 대한 지시를 담고 있습니다. 이 둘을 혼동하는 건 파일링 캐비닛과 거기 붙은 라벨을 혼동하는 것과 같습니다.

아무도 이야기하지 않는 다섯 가지 문제

모든 Obsidian-as-memory 시스템이 부딪히게 될, 구체적이고 예측 가능한 실패 모드들이 있습니다. 부딪힐 수도 있는 게 아니라, 부딪힙니다. 평면 파일을 데이터 저장소로 쓰는 데서 본질적으로 따라오는 것들이거든요.

1. 쿼리가 안 됩니다.

"'client' 태그가 붙고 importance > 7인 연락처를 모두 보여줘"라고 물을 수 없습니다. 필터링도, 정렬도, 집계도 안 됩니다. 가능한 유일한 연산은 "파일을 읽고 Claude가 필요한 걸 찾아주기를 바라는 것"입니다. 파일이 자랄수록 Claude가 관련 정보를 놓칠 확률도 함께 자랍니다. 컨텍스트 윈도우는 검색 엔진이 아닙니다. 텍스트 버퍼입니다.

2. 관계가 없습니다.

연결을 트래버스할 수 없습니다. "이 연락처가 아는 사람 중에 내가 연결된 프로젝트에서도 일하는 사람은?"은 구조화된 데이터와 조인을 요구합니다. 그래프 데이터베이스에서는 이건 단일 쿼리입니다. 마크다운에서는 불가능합니다. 노트끼리 링크할 수는 있지만, 그 링크들의 구조에 대해 프로그래밍적으로 질문할 수는 없습니다.

3. 확장 한계.

"메모리" 파일이 몇 천 줄에 도달하면, 매 세션마다 엄청난 양의 텍스트를 컨텍스트 윈도우에 던져 넣게 됩니다. 비싸고(관련 없을지도 모를 컨텍스트에 토큰을 태우니까요), 느리고(입력 토큰이 많아질수록 처리 시간도 길어지니까요), 실제 작업을 밀어냅니다(컨텍스트 윈도우는 유한하고, "메모리"에 쓴 모든 토큰은 당면 작업에 쓸 수 없는 토큰입니다).

4. 스키마 강제가 없습니다.

강제된 구조가 없습니다. 어떤 세션에서는 Claude가 연락처를 ## John Torres - Bright Pixel Media로 포맷합니다. 다음 세션에서는 **John Torres** (Bright Pixel)로 씁니다. 그 다음 세션에서는 John T. - video producer, Philly area입니다. 그걸 프로그래밍적으로 파싱해 보세요. 행운을 빕니다. John을 검색해 세 항목을 모두 찾는 것조차 행운을 빕니다. SQLite에는 스키마가 있습니다. 모든 레코드가 같은 구조를 따릅니다. 믿고 의지할 수 있죠.

5. 동시 접근이 없습니다.

두 에이전트가 동시에 같은 마크다운 파일을 안전하게 읽고 쓸 수 없습니다. 여러 자율 에이전트를 돌리고 있다면(이 분야가 빠르게 향하는 방향입니다) 동시 접근을 다룰 수 있는 데이터 저장소가 필요합니다. SQLite는 WAL 모드로 이걸 네이티브로 처리합니다. 마크다운 파일은 두 프로세스가 동시에 쓸 때 데이터를 조용히 손상시키는 방식으로 처리합니다.

진짜 대안들 (실제로 작동하는 것들)

Obsidian-as-memory 트렌드를 따라오면서 한계를 느끼기 시작했다면, 대신 봐야 할 것들이 여기 있습니다. 이론적인 게 아닙니다. 제가 매일 프로덕션에서 쓰고 있는 도구들이에요.

구조화된 메모리에는 SQLite. SQLite는 서버 셋업이 필요 없는 단일 파일 데이터베이스입니다. 당신의 머신 위에서 직접 돌아갑니다. Claude Code는 단순한 SQL 쿼리로 거기서 읽고 쓸 수 있습니다. 스키마, 인덱스, 쿼리, 정렬, 필터링, 동시 접근을 얻을 수 있죠. 955개 메모리 시스템 전체를 위한 데이터베이스가 832KB입니다. 파일 하나. 서버 없음. 클라우드 없음. 여전히 로컬 우선이고, 여전히 당신의 머신 위에 있고, 여전히 당신 것입니다. 이제 실제로 쿼리할 수 있다는 점만 다르죠.

관계에는 Kuzu (또는 임의의 임베디드 그래프 데이터베이스). 사람, 프로젝트, 개념, 도구가 어떻게 서로 연결되는지 이해해야 한다면, 그래프가 필요합니다. 링크된 파일들의 예쁜 시각화가 아니라, 트래버설을 돌리고, 패턴을 찾고, 수백 개의 노드에 걸쳐 연결을 발견할 수 있는 실제 쿼리 가능한 그래프 말입니다. Kuzu는 로컬에서, 애플리케이션에 임베드되어, 서버 없이 돌아갑니다.

완전한 시스템을 원한다면 Open Brain (OB1). Nate Jones의 Open Brain 프로젝트는 Supabase 백엔드 기반의 개인 지식 인프라로, 기본 제공으로 구조화된 저장소, 벡터 검색, 진짜 쿼리 능력을 줍니다. AI에게 영구적이고, 구조화되고, 쿼리 가능한 컨텍스트를 주는, 정확히 이런 사용 사례를 위해 설계되었습니다. 그리고 진짜 데이터베이스를 사용합니다. 이 문제가 요구하는 게 그것이기 때문이죠.

개인 백엔드로서의 Supabase. 셋업이 조금 더 편하다면, Supabase는 PostgreSQL(제대로 된 관계형 데이터베이스), 벡터 검색, 실시간 구독, 엣지 함수를 제공합니다. 오픈 소스이고, 자체 호스팅 가능하며, "AI 메모리"가 실제로 요구하는 종류의 구조화된 데이터를 위해 설계되었습니다. 한참 동안 같은 북을 쳐 왔습니다. 진짜 데이터베이스 하나가 SaaS 구독 열두 개를 대체하고, 실제로 당신의 인생을 쿼리할 수 있게 해 줍니다.

이 모두를 관통하는 공통점은 이겁니다. 그것들은 데이터베이스입니다. 스키마가 있습니다. 쿼리를 처리합니다. 확장됩니다. 일관성을 강제합니다. 마크다운 파일이 범주적으로 할 수 없는 일, 즉 데이터에 대해 질문하고 신뢰할 만한 답을 얻는 일을 합니다.

포스트잇 비유

무슨 일이 일어났는지 가장 단순하게 설명할 수 있는 방법은 이렇습니다.

잘 굴러가는 사무실로 누군가가 들어간다고 상상해 보세요. 그곳에서 모니터에 "David에게 Q3 숫자 건으로 전화"라는 포스트잇이 붙어 있는 한 시니어 임원을 봅니다. 포스트잇은 알림이고, 작은 지시이고, 행동을 가리키는 포인터입니다. Q3에 대한 실제 데이터는 스프레드시트, 데이터베이스, 재무 시스템, ERP 플랫폼에 있습니다.

이제 어떤 생산성 인플루언서가 그 사무실에 들어가서 그 포스트잇을 보고 "이 임원은 회사 전체를 포스트잇으로 운영한다"는 YouTube 영상을 만든다고 상상해 보세요. 영상은 바이럴이 됩니다. 몇 주 안에 사람들은 산업적 양의 포스트잇을 사들이고 자신들의 고객 데이터베이스, 재무 기록, 프로젝트 일정, 직원 정보 전체를 거기다 적기 시작합니다. 그것들을 벽에 붙이고는 "시각적 지식 그래프"라고 부릅니다. 색깔 탭으로 분류해 두고는 "구조화된 데이터"라고 부릅니다. 누군가 이게 미친 짓이라고 지적하면 그들은 말합니다. "하지만 포스트잇은 사람이 읽을 수 있어! 그리고 그 임원도 쓰잖아! 그리고 로컬 우선이야!"

CLAUDE.md와 Obsidian에 일어난 일이 그겁니다. Anthropic은 Claude의 모니터에 포스트잇(프로젝트 지시) 하나를 붙였고, 콘텐츠 생태계 전체가 포스트잇을 인프라라고 결정해 버렸습니다. 그 임원은 데이터를 포스트잇에 저장한 적이 없습니다. Anthropic은 .md 파일을 데이터베이스로 설계한 적이 없습니다. 하지만 포맷은 눈에 보였고 목적은 오해됐고, 이제 수천 명의 사람들이 결코 무게를 견디도록 만들어진 적 없는 토대 위에 자신들의 AI 시스템을 짓고 있습니다.

Obsidian이 실제로 쓰여야 할 곳 (그리고 그건 괜찮습니다)

분명히 해두고 싶습니다. Obsidian은 좋은 노트 앱입니다. Steph Ango의 Agent Skills는 잘 설계되어 있습니다. Obsidian 볼트 안에서 Claude Code를 사용해 노트를 정리하고, 요약을 생성하고, 링크된 문서를 만들고, 개인 지식 정원을 관리하는 것은 완전히 정당합니다.

정당하지 않은 건 그걸 메모리라고 부르는 겁니다. 정당하지 않은 건 그걸 데이터베이스라고 부르는 겁니다. 정당하지 않은 건 텍스트 파일들의 폴더 위에 자율 에이전트 시스템을 짓고 그게 확장되기를 기대하는 겁니다.

Obsidian은 만들어진 목적대로 쓰세요. 노트를 작성하고 정리하는 일. 데이터베이스는 만들어진 목적대로 쓰세요. 데이터를 저장하고, 구조화하고, 쿼리하는 일. 구분은 복잡하지 않습니다. 노트북은 파일링 캐비닛이 아닙니다. 파일링 캐비닛은 데이터베이스가 아닙니다. 각 도구에는 목적이 있고, 잘못된 도구를 쓰는 건 영리한 일이 아닙니다. 시스템을 취약하게 만드는 일이죠.

더 깊은 문제

Obsidian-as-memory 트렌드는 단순한 기술적 실수가 아닙니다. 사람들이 AI 도구에 접근하는 방식에 있는 더 큰 문제의 증상입니다. 사람들은 시스템 능력 대신 셋업 속도를 최적화하려고 합니다.

마크다운 파일은 즉시 로드됩니다. 데이터베이스는 셋업에 20분이 걸립니다. 그래서 사람들은 마크다운 파일을 고릅니다. 그러고는 다음 6개월을 그 한계를 우회하는 데 씁니다. 검색 도구를 덧대고, 벡터 인덱스를 추가하고, 구조의 부재를 보완하기 위해 정교한 프롬프트 엔지니어링을 짜고, 결국 필요한 일을 해낼 수 없다는 걸 깨닫고는 전체를 다시 짓습니다.

20분의 셋업이 6개월의 우회 작업을 아낄 수 있었습니다. 하지만 콘텐츠 생태계는 내구성 있는 아키텍처보다 빠른 데모에 인센티브를 줍니다. "10분 만에 AI 세컨드 브레인을 셋업했다"는 클릭을 받습니다. "주말 내내 제대로 된 데이터 스키마를 설계했고 이제 이 시스템은 몇 년 동안 확장될 수 있다"는 그렇지 않습니다. 인센티브 구조가 정확히 잘못된 행동에 보상을 줍니다.

그리고 이 모든 것에서 저를 좌절하게 만드는 게 그겁니다. 마크다운 파일이 나쁘다는 게 아닙니다. Obsidian이 나쁘다는 게 아닙니다. 이런 가이드를 쓰는 사람들이 다른 사람들에게 모래 위에 짓는 법을 가르치고 있다는 게 문제입니다. 콘크리트보다 셋업이 빠르다는 이유로 말이죠. 그리고 그들은 자신들이 짓고 있는 게 무너질 거라는 걸 모르거나, 신경 쓰지 않습니다.

진짜 메모리를 가진 개인 AI 비서를 만들 거라면, 진짜 인프라 위에 만드세요. 데이터베이스를 쓰세요. 스키마를 설계하세요. 쿼리를 작성하세요. 시작하는 데 더 오래 걸릴 겁니다(AI에게 대신 세워달라고 시키세요). 하지만 작동할 겁니다.

솔직한 얘기: Substack은 "Rising in Technology" 리스트에서 무료 구독자보다 유료 구독자를 훨씬 더 무겁게 가중치 매깁니다. 이 글을 읽는 1,300명 중에 13명이 돈을 내고 있습니다. 돈 때문에 하는 게 아닙니다 — 모든 건 무료로 남고, 그건 바뀌지 않습니다. 하지만 새로운 사람들이 이 글을 발견할 수 있는 곳에 제가 실제로 보이도록 도와주고 싶다면, 월 8달러가 그 방법입니다. 콘텐츠를 사는 게 아닙니다. 제게 더 좋은 자리 하나를 사 주는 겁니다.