Show HN: OpenKnowledge – Obsidian/Notion의 오픈소스 AI 우선 대안

2026-06-27 · 2026-06-27_openknowledge-obsidian-notion-ai-alternative-analysis.md

#지식관리 #AI #오픈소스 #교육 #미래

원문 출처

Show HN: OpenKnowledge – Obsidian/Notion의 오픈소스 AI 우선 대안

한 줄 요약

OpenKnowledge는 로컬 우선 WYSIWYG 마크다운 편집기로, Claude·Codex 등 AI 에이전트와의 긴밀한 통합을 내세우지만, Obsidian 같은 기존 도구 대비 뚜렷한 차별점이 부족하다는 논란과 함께 플랫폼 제한·명칭 충돌·진정한 오픈소스성에 대한 의문이 집중된 프로젝트다.

원문 핵심 내용

### 작동 방식: 마크다운을 구글 문서처럼 편집한다

OpenKnowledge의 핵심은 true WYSIWYG(What You See Is What You Get) 편집 경험이다. 일반 마크다운 편집기는 왼쪽에 원본 코드, 오른쪽에 미리보기를 두는 분할 화면을 사용하는데, 이 앱은 Notion이나 Google Docs처럼 입력하는 그대로 최종 결과물이 보인다. 예를 들어 ###를 치면 바로 제목 스타일로 바뀌고, **굵게**를 입력하면 실시간으로 굵은 글씨가 적용된다. 내부적으로는 마크다운 파일을 저장하지만, 사용자는 코드를 직접 다룰 필요가 없다.

### AI 통합: 여러 에이전트와 협업 편집

Claude(Anthropic), Codex(OpenAI), Cursor 등 데스크톱 AI 앱과 직접 연결된다. 사용자는 OpenKnowledge 안에서 편집하면서 옆에 Claude 터미널을 띄우거나, Codex가 문서를 수정하도록 명령할 수 있다. 더 나아가 MCP(Model Context Protocol)와 CLI를 통해 OpenCode 같은 에이전트용 하네스(harness)와도 연동된다. 즉, 단순 편집기를 넘어 AI 에이전트가 문서를 읽고 쓰는 '에이전트 세컨드 브레인(agent second brain)' 역할을 목표로 한다.

### 팀 공유와 동기화: Git/GitHub을 숨긴 협업

팀 공유 기능은 코드를 전혀 모르는 사람도 사용할 수 있도록 설계됐다. 내부적으로는 Git과 GitHub으로 동기화되지만, 사용자는 '공유' 버튼만 누르면 된다. 자동 병합(merge)과 충돌 해결은 앱이 처리한다. 단, 개인 저장소에 무단으로 푸시되지 않으며, 팀 공유 모드를 켜야만 GitHub 저장소에 반영된다. 대용량 파일은 Git LFS(Large File Storage)를 염두에 두고 있다.

### 설치와 플랫폼: macOS는 네이티브, 나머지는 CLI

  • macOS: DMG 파일을 받아 Applications 폴더에 드래그하면 바로 사용 가능한 데스크톱 앱.
  • Linux/Windows/Intel Mac: Node.js 24+가 필요하며, npm install -g @inkeep/open-knowledge로 설치 후 ok init → ok start --open으로 웹 브라우저에서 실행.
  • 안드로이드/iOS: 현재 공식 지원 없음. 개발 중인지는 불명확.
  • 라이선스는 GPL-3.0-or-later로 완전한 오픈소스.

### 트레이드오프: 단순함과 확장성의 줄타기

WYSIWYG는 직관적이지만, 마크다운의 원래 강점인 버전 관리 diff의 가독성이 희생된다. 또한 Obsidian처럼 데이터뷰(Dataview) 플러그인으로 문서 내 데이터를 쿼리하는 기능은 아직 없다. AI 통합은 외부 서비스(Claude API 등)에 의존하므로, 완전한 로컬 동작이 불가능하다. 개발자는 "아직 초기 단계이며, 내장 AI와 로컬 모델 지원을 로드맵에 올렸다"고 답했다.

Hacker News 커뮤니티 반응

댓글 처리 기록: HN 댓글 35여 개를 읽음. 창시자(engomez)가 거의 모든 댓글에 직접 응답하며 로드맵을 설명.

### 1. Obsidian은 '단순 마크다운'이 아니다 — 데이터베이스 기능이 핵심

  • 주장: Obsidian의 진정한 가치는 Dataview, Chart 등 플러그인으로 문서 내 데이터를 SQL처럼 쿼리하는 데 있다. (jfim)
  • 근거: “Obsidian is a lot more than 'just markdown' … reducing Obsidian vaults to 'just markdown' misses what some users use it for.” — jfim은 대시보드·할 일 목록·최근 편집 문서 뷰를 예시로 들음.
  • 반론/대댓글: engomez는 데이터베이스 측면을 아직 지원하지 않음을 인정하고 “로드맵에 포함시키겠다”고 답변.
  • 대표 작성자: [jfim], [devCassius]

### 2. 로컬 LLM 지원이 없다면 전환할 이유가 없다

  • 주장: Claude/Codex 같은 외부 AI에 의존하는 것은 독이 든 성배. 개인 지식 저장소에 민감한 데이터를 외부로 보내야 한다. (pcthrowaway)
  • 근거: “Personally I just want to see more support for local LLMs. … Gemma4-31b, LMStudio 같은 로컬 모델을 직접 연결할 수 있어야 한다.”
  • 반론/대댓글: engomez는 “Zed/OpenCode 가이드를 준비 중이며, MCP를 통해 로컬 모델도 사용 가능하다”고 해명. 그러나 pylotlight는 “현재 앱의 AI 통합은 덧붙여진 기능일 뿐, 앱 자체는 GPL이므로 문제 없다”고 반박.
  • 대표 작성자: [pcthrowaway], [jrm4], [pylotlight]

### 3. “그냥 Obsidian 플러그인이면 안 되나?” — 근본적인 의문

  • 주장: OpenKnowledge의 대부분 기능(WYSIWYG, AI 통합)은 Obsidian 플러그인으로도 구현 가능하다. (culi)
  • 근거: “I don’t understand how Obsidian, a collection of markdown files, isn't already AI friendly. … couldn't this have been a plugin?”
  • 반론/대댓글: engomez는 “진정한 WYSIWYG 편집기와 에이전트 내장 웹 뷰어 같은 독자적 경험은 플러그인으로는 불가능하다”고 답변. rnxrx는 “Obsidian에 이미 MCP 서버와 REST API가 있어 직접 설정하면 비슷하다”고 반론. NamlchakKhandro는 “플러그인으로는 수익을 낼 수 없다”며 cynic한 시각.
  • 대표 작성자: [culi], [rnxrx], [NamlchakKhandro]

### 4. macOS 전용: “데스크톱 점유율을 잊은 건가”

  • 주장: macOS만 네이티브 앱을 제공하고 Linux/Windows는 CLI+웹은 유용성이 떨어진다. (Imustaskforhelp, wollowollo)
  • 근거: “mac only? dead on arrival. Steam machine means everyone is moving to Linux.” — wollowollo는 멀티플랫폼 계획의 중요성을 강조.
  • 반론/대댓글: engomez는 Electron 기반 멀티플랫폼 앱을 준비 중이라고 밝혔으나, 구체적인 일정은 제시하지 않음.
  • 대표 작성자: [Imustaskforhelp], [wollowollo]

### 5. Git 동기화의 함정: 개인 정보는 안전한가

  • 주장: GitHub 기반 동기화는 편리하지만, 개인 vault가 실수로 공개될 위험이 있다. (pcthrowaway, mkt123)
  • 근거: 초기 댓글에서 동기화 방식이 모호했으나, mkt123이 명확히 선언: “OpenKnowledge will never publish your project to GitHub automatically.” 단, 팀 공유 모드에서만 저장소에 푸시됨.
  • 반론/대댓글: pcthrowaway는 이 해명을 듣고 “I've decided to try daily driving this instead of Obsidian”이라고 호의적으로 돌아섬.
  • 대표 작성자: [mkt123], [pcthrowaway]

### 6. “앱이 거짓말을 한다” — syabro의 강한 실망

  • 주장: 웹페이지에 있는 채팅 UI 기능이 실제 앱에 없고, 설치 과정에서 .zshrc를 묻지 않고 수정했으며, 속도도 느리다. (syabro)
  • 근거: “Webpage is lying and showing stuff what you don't have in the app … You made changes to my .zshrc without asking me. Slow.” → 즉시 삭제.
  • 반론/대댓글: engomez는 CLI 단축어 ‘ok’가 UX 문자열 오류였음을 인정하고 수정 약속. psoulos는 “나는 터미널에서 TUI로 잘 쓰고 있다”며 차분히 반박.
  • 대표 작성자: [syabro], [psoulos]

### 7. 명칭 충돌: Open Knowledge Foundation, Google OKF와의 혼동

  • 주장: ‘Open Knowledge’는 2004년부터 활동한 Open Knowledge Foundation(OKFN)이나 Google의 Open Knowledge Format(OKF)과 충돌한다. (tuukkah, zihotki)
  • 근거: “You had started your AI project before 2004?” — tuukkah가 engomez의 ‘시기가 비슷했다’는 발언을 반박.
  • 반론/대댓글: engomez는 OKF(Google)와 OKFN을 혼동했다고 인정. “명칭 충돌은 우연이며, 프로젝트는 OKF 형식을 준수한다”고 설명.
  • 대표 작성자: [tuukkah], [zihotki]

### 8. 다중 에이전트 환경: 문서 단위가 아닌 의미 단위 버전 관리 필요

  • 주장: AI 에이전트가 여러 문서를 동시에 수정할 때, 각 문서의 개별 버전이 아닌 원자적 변경셋(atomic changeset) 이 필요하다. (abdullin)
  • 근거: abdullin은 98M 에이전트 상호작용을 기록한 플랫폼 운영 경험에서 “Weak per-document versioning isn’t enough here”라고 강조.
  • 반론/대댓글: engomez는 이해하지만 현재는 Git 기반 단순 동기화만 지원. 로드맵에 포함하겠다고 답변.
  • 대표 작성자: [abdullin]

### 9. 실무자 증언: Obsidian + AI 워크플로는 이미 충분하다

  • 주장: Obsidian을 MCP 서버와 결합하면 OpenKnowledge가 제공하는 AI 통합을 이미 누릴 수 있다. (rnxrx, kylenessen)
  • 근거: rnxrx는 “Obsidian을 persistent context store로 사용 중. Claude Code, Hermes와 연동하면 완벽하다.” kylenessen은 “Obsidian + Claudian 플러그인으로 우측 패널에 로컬 Gemma4-31b를 띄워 쓴다”고 구체적 설정 공유.
  • 반론/대댓글: engomez는 “Obsidian 플러그인으로는 진정한 WYSIWYG와 내장 웹 뷰어 같은 통합 경험을 얻기 어렵다”고 재반박.
  • 대표 작성자: [rnxrx], [kylenessen]

### 10. ‘Red Lining’ 기능 제안 — 텍스트에 주석을 달아 LLM에 전달

  • 주장: 문서에서 특정 부분을 선택하고 거기에 주석(comment)을 달면, LLM이 그 주석들만 읽고 응답할 수 있어야 한다. (zby)
  • 근거: “select text and comment on it - then let the llm read all comments” — 마치 교정지(red lining)처럼.
  • 반론/대댓글: engomez가 즉시 “we'll ship this within the next week”라고 약속. 이는 창시자의 빠른 대응 능력을 보여줌.
  • 대표 작성자: [zby]

### 11. ‘오픈소스’ 꼬리표와 독점 AI 서비스의 모순

  • 주장: GPL 라이선스로 배포하면서 Claude·Codex 같은 독점 AI 서비스와의 통합에 의존하는 것은 ‘오픈소스’ 정신에 위배된다. (jrm4)
  • 근거: “There genuinely ought to be consequences for using 'open source' … tied to proprietary AI services.”
  • 반론/대댓글: pylotlight는 “앱 자체는 OSS이고 AI 통합은 선택적 추가 기능일 뿐”이라고 반박. engomez는 로컬 모델 지원을 최우선 순위로 올리겠다고 약속.
  • 대표 작성자: [jrm4], [pylotlight]

### 12. 프로젝트의 진짜 가치는 ‘팀 공유’와 ‘AI 통합’의 결합

  • 주장: 비기술자도 사용할 수 있는 팀 지식 베이스 + AI 편집이 진정한 차별점이다. (engomez, toozitax)
  • 근거: toozitax는 “every 'wysiwyg markdown' tool i've tried falls apart on YAML frontmatter / nested code fences round-trip”이라며 기존 도구의 한계를 지적. engomez는 Optimistic parsing으로 이 문제를 해결했다고 주장.
  • 반론/대댓글: rubywilde는 “yet another KM app without significant innovations”이라고 일축.
  • 대표 작성자: [toozitax], [rubywilde]

새로운 시각

### AI-우선 지식 도구의 딜레마: ‘에이전트의 뇌’ vs ‘인간의 노트’

흥미로운 점은 이 프로젝트가 인간 사용자보다 AI 에이전트를 1차 고객으로 삼고 있다는 것이다. ‘MCP 서버’, ‘에이전트 세컨드 브레인’ 같은 용어에서 드러나듯, 문서는 인간이 읽기 위한 것이 아니라 AI가 읽고 쓰기 위한 구조로 진화하고 있다. 이는 미래에 지식 베이스가 ‘인간 친화적 마크다운’에서 ‘기계 최적화 지식 그래프’로 바뀔 수 있음을 암시한다. 하지만 HN 댓글의 핵심 비판은 정반대였다: “인간이 편하게 쓰는 도구가 먼저여야 한다.” AI가 문서를 자동 생성·수정하는 시대에, 인간은 여전히 직관적 편집기와 데이터 쿼리 기능을 원한다. 이 괴리가 OpenKnowledge의 가장 큰 도전 과제다.

### ‘로컬 우선’이라는 허상: 진짜 로컬은 GPU가 필요하다

OpenKnowledge는 ‘로컬 우선’을 내세우지만, AI 통합은 여전히 클라우드 API에 의존한다. 진정한 로컬 우선이 되려면 로컬 GPU에서 돌아가는 LLM(예: Llama 3, Gemma 4)을 기본 엔진으로 채택해야 한다. 현재의 접근은 마치 ‘로컬에서 편집하지만 인쇄는 클라우드로 보낸다’는 모순과 같다. 앞으로 2~3년 안에 소비자용 GPU에서 70B급 모델이 실시간으로 구동된다면, 이러한 하이브리드 방식은 도태될 가능성이 크다.

### 교육과 의료 분야에의 함의: ‘설명 가능한 AI’와 ‘데이터 주권’

사용자가 의료 종사자라는 점을 고려하면, OpenKnowledge의 구조는 환자 데이터 보호 측면에서 위험하다. 소화기 내시경 영상 분석이나 종양학 판독에 AI를 활용할 때, 민감한 의료 정보가 Claude/Codex 서버로 전송된다면 HIPAA(미국 건강보험 이전 및 책임에 관한 법률)·GDPR(유럽 일반 개인정보보호법) 위반이 될 수 있다. 반면, 로컬 LLM을 활용한 지식 베이스는 의사가 개인용 로컬 모델로 논문을 요약하고, 진단 보조 도구로 사용할 수 있는 안전한 길이다. 이 프로젝트가 ‘로컬 LLM 우선’으로 선회한다면 의료 분야에서도 실제로 사용될 가능성이 있다.

자녀와 미래에 대한 시사점

### 다음 세대에게 필요한 능력: AI와 협업하는 문서 작성법

OpenKnowledge가 표방하는 ‘AI와 공동 편집’은 앞으로 모든 지식 작업의 기본이 될 것이다. 아이들은 지금처럼 마크다운 문법을 외우기보다, AI에게 원하는 결과물을 지시(프롬프트)하고 결과를 검토·수정하는 능력을 키워야 한다. 학교에서도 ‘AI 보조 글쓰기’를 정규 교과에 포함시켜야 하며, 단순히 AI가 대신 써주는 것이 아니라 인간이 방향을 제시하고 검증하는 훈련이 중요하다.

### 가르쳐야 할 것: 데이터 주권 개념과 오픈소스 정신

아이들이 자라면서 자신의 지식 저장소를 만들게 될 때, 데이터가 어디에 저장되고 누가 접근할 수 있는지를 이해해야 한다. OpenKnowledge 논란에서 보듯, ‘오픈소스’라는 말에 속아 데이터가 외부 AI에 넘어가는 상황을 경계해야 한다. 가정과 학교에서는 ‘내 정보는 내가 통제한다’는 원칙과 함께, 오픈소스 라이선스의 의미(예: GPL이 강제하는 자유)를 실제 사례로 가르칠 필요가 있다.

### 의료 분야에서의 시사점: 로컬 LLM 기반 지식 관리가 필수

사용자의 소화기·내시경·종양학 분야에서는 최신 연구 논문, 케이스 리포트, 진료 지침을 정리하는 지식 베이스가 매우 중요하다. 만약 미래에 OpenKnowledge 같은 도구가 완전한 로컬 LLM을 지원하게 된다면, 병원 내부망에서 환자 정보를 외부로 유출하지 않고 AI의 도움을 받아 지식을 축적·활용할 수 있다. 반면, 현재처럼 클라우드 AI에 의존하는 도구는 의료 현장에서 사용하기 어렵다. 따라서 의료인을 위한 지식 관리 도구의 미래는 반드시 로컬 우선+로컬 LLM이어야 한다는 교훈을 얻을 수 있다.