AI-first 지식베이스가 나왔다 — 나는 WYSIWYG를 버렸다

Obsidian에 AI 플러그인을 붙이는 게 아니라, AI가 먼저인 노트 앱이 나왔다. OpenKnowledge라는 오픈소스 도구다. macOS 데스크톱 앱, 로컬 Markdown, WYSIWYG 편집, Claude·Codex·Cursor 내장 통합, MCP 서버 기본 탑재. 한마디로 “AI 에이전트를 위한 Notion”이다.

이걸 보면서 드는 생각은 하나다. 나는 Obsidian 위에 AI 에이전트 시스템을 올렸고, 이 팀은 AI 에이전트 위에 지식 관리 도구를 올렸다. 같은 게임을 반대 방향에서 푼 거다. 그리고 그 차이에 내 P0-P6 아키텍처의 이유가 전부 들어 있다.

어떤 도구인가

OpenKnowledge는 로컬 우선 WYSIWYG Markdown 편집기다. 마크다운 파일을 Google Docs나 Notion처럼 보이게 편집할 수 있고, Claude나 Codex 같은 AI 하네스와 바로 연동된다. 눈에 띄는 특징은:

• MCP 서버를 기본 내장해서 에이전트가 볼트를 직접 읽고 쓸 수 있다
• skills 시스템이 있어 에이전트한테 “이 볼트에선 이렇게 작업해”라고 지시 가능
• git 기반 동기화 — 코드 없이 팀 공유 가능
• agentic search — 시맨틱 검색 + 그래프 기반 탐색
• LLM 위키, 에이전트 세컨드 브레인, 지식 그래프를 위한 구조

GPL-3.0 라이선스, npm으로 설치해서 5분 안에 시작할 수 있다. 기술적으로 꽤 잘 만든 물건이다.

내가 Obsidian을 떠나지 않은 이유 — 그리고 OpenKnowledge가 옳은 이유

나는 Drewgent의 지식 저장소로 Obsidian vault를 쓴다. P0-brainstem부터 P6-prefrontal까지 7개 레이어로 쌓아놨고, AI 에이전트는 이 파일들을 직접 읽고 쓴다. filesystem이 single source of truth다. 벡터 DB가 아니다.

OpenKnowledge도 같은 결정을 했다. 로컬 Markdown 파일, 폴더 구조, git으로 버전 관리. 파일 시스템이 진실이다. 이건 우연이 아니다. AI 에이전트가 지식을 다룰 때, 벡터 임베딩만으로는 부족하다는 걸 둘 다 깨달은 거다.

차이는 어디서부터 시작했는가다.

• 나는 인간이 먼저였다 — Obsidian에서 글을 쓰고, 생각을 정리하고, 그 위에 AI가 접근할 수 있는 구조(P0-P6, wikilink, frontmatter)를 얹었다. Karpathy Compile pattern으로 P2(raw archive) → P5(compiled wiki)의 흐름을 만들었다. AI는 이 파이프라인의 소비자다.
• OpenKnowledge는 AI가 먼저다 — MCP 서버가 볼트의 네이티브 인터페이스다. 에이전트가 읽고 쓰는 걸 기본 동작으로 설계했고, 인간은 그 위에 WYSIWYG 편집기를 얹었다. 인간이 AI 파이프라인의 소비자다.

둘 다 맞다. 어떤 방향으로 쌓든, 결국 만나는 지점은 같다 — 파일 시스템, Markdown, MCP, git. 그게 taste의 수렴이다.

나한테는 Obsidian이 더 맞는 이유

내가 Obsidian 위에 AI 레이어를 쌓은 건 의도적인 taste 결정이었다.

• 글쓰기 경험이 먼저다. 나는 하루에도 수십 개의 노트를 쓴다. wikilink로 연결하고, 태그를 달고, Mermaid 다이어그램을 그린다. Obsidian은 이걸 4년 넘게 써온 환경이다. AI를 위해 이걸 버리는 건 말이 안 된다.
• 플러그인 생태계. Obsidian은 2,000개가 넘는 커뮤니티 플러그인이 있다. Excalidraw, Kanban, Dataview… 새 도구가 이걸 다 따라잡으려면 몇 년이 걸린다.
• AI는 내 도구지, 내 환경이 아니다. 에이전트가 Obsidian 안에 들어오길 원하지 않는다. 에이전트는 파일 시스템을 통해 볼트에 접근하고, 나는 Obsidian을 통해 접근한다. 인터페이스 분리가 오히려 깔끔하다.

하지만 이건 내 경우일 뿐이다. 새로 시작하는 사람이라면 OpenKnowledge가 훨씬 나을 수 있다. AI-first로 시작하면 “볼트를 에이전트가 이해할 수 있게 만드는” 단계를 스킵할 수 있기 때문이다.

같은 게임, 다른 시작점

이걸 표로 정리하면 이렇다:

진짜 인사이트: “AI가 어떻게 지식을 소비하는가”가 먼저다

OpenKnowledge가 내린 가장 중요한 taste 결정은 하나다. “에이전트가 이 볼트를 어떻게 읽을 것인가”를 설계의 1순위로 올린 것.

기존 노트 앱들은 이걸 거꾸로 한다. 인간 편집 경험이 먼저고, AI는 “나중에 플러그인으로 붙이면 되지” 하는 부가 기능이다. Notion AI? Obsidian Copilot? 전부 인간-퍼스트 설계 위에 AI를 덧댄 것뿐이다.

근데 2026년에는 이게 틀렸다. 에이전트가 만들어내는 지식의 양이 인간이 쓰는 양을 넘어서고 있다. 내 Drewgent만 해도 content-manager가 하루에 수천 단어의 콘텐츠를 생성하고, trend-harvester가 분석 리포트를 쏟아내고, cron job들이 로그와 메트릭을 쌓는다. 이 지식을 인간이 일일이 읽고 정리할 수 없다. 에이전트가 에이전트의 지식을 관리하는 구조가 필요하다.

내가 P0-P6를 Obsidian 위에 쌓으면서 가장 신경 쓴 것도 이거다. P2-hippocampus는 raw archive — 에이전트가 쓴 원본을 절대 건드리지 않는다. P5-ego/wiki는 compiled knowledge — 인간과 에이전트가 함께 쿼리하는 대상이다. Karpathy Compile pattern은 결국 “AI가 쓴 걸 AI가 읽을 수 있게 만드는” 파이프라인이다.

OpenKnowledge는 이걸 처음부터 내장했다. MCP 서버가 볼트의 네이티브 레이어다. skills 시스템으로 에이전트에게 컨텍스트를 주입한다. agentic search로 시맨틱 검색이 기본이다. 내가 7개 레이어와 3개월의 설계로 만든 걸, 얘는 처음부터 한 방에 해결했다. 존중할 만하다.

언제 뭘 선택할 것인가

이 질문에 대한 내 답은 간단하다:

• 이미 Obsidian/Notion에 수백 개의 노트가 있다면 — AI 레이어를 위에 쌓아라. MCP 서버를 붙이고, wikilink 그래프를 구축하고, P0-P6 같은 구조를 설계해라. 편집 환경을 포기할 이유가 없다.
• 새로 시작하는 팀이라면 — OpenKnowledge 같은 AI-first 도구를 진지하게 검토해라. AI 에이전트가 지식을 읽고 쓰는 방식으로 시작하는 게, 나중에 “AI도 읽을 수 있게” 마이그레이션하는 것보다 훨씬 싸다.
• 둘 다 아니라면 — filesystem-as-truth 원칙만 지켜라. Markdown 파일로, git으로 관리하고, 폴더 구조로 의미를 표현해라. 어떤 편집기를 쓰든 AI는 파일을 읽을 수 있어야 한다.

Taste의 수렴

OpenKnowledge를 보면서 느낀 건, taste는 결국 수렴한다는 거다. 서로 다른 출발점, 다른 사용자, 다른 기술 스택에서 시작했는데 만나는 지점이 같다:

• 파일 시스템이 진실이다 (벡터 DB가 아니다)
• Markdown이 유일한 포맷이다 (독점 포맷은 감옥이다)
• MCP가 AI 접근의 표준 인터페이스다
• git이 동기화의 정답이다
• 오픈소스여야 한다 (GPL-3.0)

이 다섯 가지는 2026년 AI 지식 관리의 baseline taste다. 이걸 충족하지 못하는 도구는 AI 에이전트 시대에 살아남기 어렵다. Notion은 독점 포맷 때문에, Evernote는 오픈소스가 아니라서, Roam은 MCP가 없어서 각각 한계가 있다.

OpenKnowledge는 저 다섯 가지를 모두 충족한다. 아직 젊은 프로젝트라 Obsidian 수준의 완성도는 아니지만, 방향은 정확하다.

내가 다음에 할 일

OpenKnowledge를 몇 주 정도 직접 써볼 생각이다. 특히 관심 가는 건:

• MCP 서버의 구현 품질 — Drewgent의 MCP 툴들과 얼마나 자연스럽게 연동되는지
• skills 시스템 — 내가 만든 100+ 스킬들을 이식할 수 있을지
• agentic search — gbrain의 hybrid search와 비교해서 어떤 차이가 있는지

Drewgent를 OpenKnowledge로 마이그레이션할 생각은 없다. Obsidian의 편집 경험과 플러그인 생태계를 포기할 이유가 없고, P0-P6 구조는 이미 파일 시스템 위에서 완벽하게 돌아가고 있다. 하지만 OpenKnowledge에서 배울 점은 분명히 있다. 특히 “MCP가 볼트의 네이티브 인터페이스”라는 설계는 내 Obsidian-MCP 연동을 더 단단하게 만드는 힌트가 될 거다.

읽어줘서 고맙다. AI-first 지식 관리에 대한 네 생각도 듣고 싶다. 나는 지금도 여전히 Obsidian을 열고 이 글을 쓰고 있고, 내 에이전트들은 이 파일을 읽으면서 다음 할 일을 정할 거다. 인간과 AI가 같은 파일 시스템을 바라보는 것 — 이게 내가 생각하는 지식 관리의 미래다.