# \#obsidian **URL:** https://discuss.pytorch.kr/tag/obsidian/7219.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [llmwiki-serve: Markdown/Obsidian 문서를 코딩 에이전트용 읽기 전용 컨텍스트로 연결하기](https://discuss.pytorch.kr/t/llmwiki-serve-markdown-obsidian/12026)
**Author:** [@HwangJohn](https://discuss.pytorch.kr/u/HwangJohn)\ **댓글:** 0\ **마지막 업데이트:** [9월 27, 2026, 12:56오후 UTC](https://discuss.pytorch.kr/t/llmwiki-serve-markdown-obsidian/12026 "2026-09-27T12:56:48Z")
llmwiki-serve는 이미 가지고 있는 Markdown, Obsidian 또는 LLMWiki 폴더를 코딩 에이전트가 조회할 수 있는 읽기 전용 Knowledge Source로 열어주는 로컬 서버입니다. 문서를 새로 생성하는 위키 컴파일러가 아니라, 기존 파일을 그대로 두고 필요한 근거를 CLI, HTTP, MCP로 찾고 읽게 하는 도구입니다. 현재 공개 버전은 0.2.13이며 Python 3.11 이상에서 사용할 수 있습니다. 어떤 문제를 해결하나 프로젝트가 커지면 README 외에도 ADR, spec, 릴리스 체크리스트, 회의 노트, 개인 Obsidian 문서가 계속 쌓입니다. 하지만 Codex나 Claude Code 같은 코딩 에이전트가 매 작업마다 이 문서를 모두 알고 있는 것은 아닙니다. 관련 파일을 매번 프롬프트에 붙이는 것은 번거롭고, 문서를 참고시키기 위해 별도의 호스팅형 RAG 서비스나 채팅 UI까지 운영하는 것도 작은 프로젝트에는 부담스러울 수 있습니다. llmwiki-serve는 기존 작성 방식을 바꾸지 않고, 필요한 문서만 근거와 함께 조회하는 계층을 제공합니다. 기존 Markdown/Obsidian 폴더 ↓ 읽기 전용 projection llmwiki-serve ↓ CLI / HTTP / MCP Codex, Claude Code, IDE 에이전트, 스크립트 에이전트는 다음과 같은 질문에 필요한 문서를 먼저 찾을 수 있습니다. "이번 릴리스 전에 확인해야 할 체크리스트가 뭐야?" "이 설계 변경과 관련된 ADR을 찾아줘." "이 기능을 수정하기 전에 읽어야 할 spec이 있어?" "내 Obsidian 문서에서 이 주제와 연결된 노트를 찾아줘." 무엇을 제공하나 Markdown/Obsidian 스타일 wikilink, YAML front matter, heading, tag, 문서 간 링크를 읽습니다. 같은 읽기 전용 projection을 CLI, HTTP, MCP Str… --- ## [llm-wiki: Karpathy의 방법론으로 흩어진 정보를 지식 그래프로 키우는 에이전트 스킬](https://discuss.pytorch.kr/t/llm-wiki-karpathy/10843)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 10\ **마지막 업데이트:** [8월 23, 2026, 1:19오후 UTC](https://discuss.pytorch.kr/t/llm-wiki-karpathy/10843 "2026-08-23T13:19:12Z")
llm-wiki 소개 논문, 블로그 글, 트윗, 메모처럼 매일 접하는 정보는 대개 한 번 읽고 흩어집니다. 필요할 때마다 다시 검색하고 같은 자료를 또 읽지만, 정작 그 사이의 연결은 머릿속에만 남습니다. llm-wiki는 이런 파편화된 정보를 한 번 정제해 두고 계속 이어 붙이는 개인 지식 베이스로 바꾸는 에이전트 스킬입니다. 핵심 차이는 같은 질문에 매번 처음부터 답을 만들어 내지 않고, 지식을 한 번 컴파일해 지속적으로 유지 한다는 점입니다. 이 스킬은 Andrej Karpathy가 제안한 llm-wiki 방법론을 바탕으로 합니다. 자료를 받아 분석한 뒤, 엔티티 페이지·주제 페이지·출처 요약을 자동으로 생성하고 \[\[양방향 링크\]\] 로 서로 연결합니다. 결과물은 모두 로컬 마크다운이라 Obsidian 에서 그대로 열 수 있고, 별도의 인터랙티브 지식 그래프 HTML 로도 탐색할 수 있습니다. llm-wiki 는 특정 도구에 묶이지 않고 Claude Code, Codex, OpenClaw, Hermes 등 여러 에이전트 플랫폼에서 동작합니다. 설치 후에는 "지식 베이스를 초기화해줘", "이 글을 정리해줘: " 처럼 자연어로 지시하면 스킬이 수집·분석·정리·연결을 대신 수행합니다. llm-wiki가 지식을 쌓는 방식 자료를 받아들이는 과정은 두 단계로 나뉩니다. 먼저 내용을 분석하고, 그 결과를 바탕으로 페이지를 생성합니다. 긴 글은 사고를 이어 가는 방식으로 처리하며, 스크립트가 분석 결과의 형식을 자동 검증하기 때문에 성능이 약한 모델을 써도 깨진 데이터가 만들어지지 않도록 설계되어 있습니다. 또한 URL 도메인에 따라 가장 적합한 추출 방식을 자동으로 고릅니다. 생성된 위키 페이지에는 사실의 출처를 구분하는 신뢰도 표시 가 붙습니다. EXTRACTED(원문에서 추출), INFERRED(추론), AMBIGUOUS(모호), UNVERIFIED(미검증)로 표기되어, 어떤 내용이 검증이 필요한지 한눈에 알 수 있습니다. 같은 자료를 중복 처리… --- ## [OpenHuman: 메모리 트리와 Obsidian 호환 볼트를 갖춘 로컬 우선 에이전트형 AI 어시스턴트](https://discuss.pytorch.kr/t/openhuman-obsidian-ai/10383)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 17, 2026, 11:30오전 UTC](https://discuss.pytorch.kr/t/openhuman-obsidian-ai/10383 "2026-06-17T11:30:32Z")
OpenHuman 소개 OpenHuman은 데스크톱에서 동작하는 에이전트형(agentic) AI 어시스턴트로, 메일·캘린더·문서·코드 도구를 한 자리에서 다루는 것을 목표로 합니다. 프로젝트는 자신을 "open-source agentic assistant designed to integrate with you in your daily life" 라고 소개하면서, "Personal AI super intelligence: local memory, managed services where needed, simple and powerful" 라는 한 줄로 핵심 콘셉트를 정리하고 있습니다. OpenHuman의 가장 큰 차별점은 두 가지 저장 계층의 조합 입니다. 사용자가 연결한 외부 서비스의 데이터를 약 3,000 토큰 이하의 Markdown 청크로 정규화한 뒤, SQLite에 저장되는 계층적 요약 트리(memory tree)와 Obsidian과 호환되는 Markdown 볼트(Obsidian Wiki)에 동시에 보관합니다. 메모리 트리는 LLM이 빠르게 훑을 수 있는 형태이고, Obsidian 볼트는 사람이 직접 열어 보고 편집할 수 있는 형태입니다. 프로젝트는 이 구조가 Andrej Karpathy가 공유한 obsidian-wiki 워크플로우에서 영감을 받았다고 밝히고 있습니다. 기본 동작은 OpenHuman 측이 관리하는 백엔드(계정 로그인, 모델 라우팅, 웹 검색 프록시, OAuth/Composio 커넥터)에 의존하지만, 사용자가 자신의 모델·검색·Composio 자격증명을 직접 설정해 custom/local 모드 로 옮길 수 있습니다. 다만 실시간 트리거나 일부 hosted 기능은 managed 백엔드에 남아 있다고 본문 상단에서 명시하고 있습니다. 저장소는 "Early Beta — Under active development. Expect rough edges" 라는 안내가 함께 붙어 있는 활발한 개발 단계 프로젝트입니다. OpenHuman의… --- ## [LLM Wiki: 문서를 자동으로 위키 형태 지식 베이스로 컴파일하는 데스크톱 애플리케이션 (feat. Karpathy LLM Wiki 패턴)](https://discuss.pytorch.kr/t/llm-wiki-feat-karpathy-llm-wiki/10139)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 17, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/llm-wiki-feat-karpathy-llm-wiki/10139 "2026-06-17T09:30:19Z")
LLM Wiki 소개 개인 지식 관리에 LLM을 도입하면 흔히 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 패턴이 먼저 떠오릅니다. 그러나 RAG는 사용자가 질문할 때마다 원본 문서에서 매번 처음부터 검색하고 답변을 생성하는 방식이라, 동일한 자료에 대해 같은 추론이 반복되고 그 과정에서 토큰과 시간이 계속 소모됩니다. 또한 검색된 청크(chunk) 단위 응답이라 원본 문서 사이의 관계, 모순, 빈 곳을 사용자가 한눈에 보기 어렵습니다. Andrej Karpathy는 이러한 한계를 극복하기 위해 LLM이 점진적으로 위키(wiki)를 만들고 유지·보수하는 패턴을 llm-wiki.md 라는 짧은 문서로 제안했습니다. LLM Wiki는 이 패턴을 추상 디자인이 아니라 누구나 설치해 사용할 수 있는 크로스플랫폼 데스크톱 애플리케이션으로 구현한 오픈소스 프로젝트입니다. LLM Wiki의 핵심 접근법은 RAG와 달리 LLM이 한 번 분석한 결과를 위키 페이지로 영속화하고, 새 자료가 들어올 때만 점진적으로 업데이트하는 점입니다. 사용자가 PDF나 DOCX, PPTX 같은 문서를 등록하면 LLM은 두 단계 사고 사슬(Two-Step Chain-of-Thought) 인제스트를 통해 먼저 핵심 엔티티와 개념, 기존 위키와의 모순을 분석하고, 이어서 그 분석 결과를 바탕으로 위키 페이지를 생성합니다. 페이지 사이 관계는 \[\[wikilinks\]\]와 4 신호 관련도 모델(4-Signal Relevance Model)로 구성된 지식 그래프(Knowledge Graph)에 반영되며, Louvain 커뮤니티 탐지(Community Detection)를 통해 자료 사이의 자연스러운 클러스터까지 드러냅니다. 그 결과 사용자는 RAG처럼 매번 처음부터 검색되는 답변이 아니라, 시간이 지날수록 풍부해지는 자기만의 위키와 대화하게 됩니다. 기능적으로 LLM Wiki는 단순한 노트 앱을 넘어 위키, 지식 그래프, 검색, Lint, 리뷰, Deep Re… --- ## [obsidian-second-brain: Obsidian 저장소(Vault)를 스스로 갱신되는 AI 세컨드 브레인으로 만드는 스킬](https://discuss.pytorch.kr/t/obsidian-second-brain-obsidian-vault-ai/10730)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 16, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/obsidian-second-brain-obsidian-vault-ai/10730 "2026-06-16T09:30:22Z")
obsidian-second-brain 소개 매일 Claude를 쓰지만 세션은 매번 처음부터 시작합니다. 같은 맥락을 다시 설명하고, 대화가 끝나면 그 내용은 사라집니다. 한편 Obsidian에는 수백 개의 노트가 쌓여 있지만 그냥 거기 머물러 있을 뿐입니다. 6개월 전에 내린 결정을 잊고 같은 판단을 두 번 하기도 합니다. obsidian-second-brain은 이렇게 분리되어 있던 두 도구를 연결해, Obsidian 볼트를 스스로 갱신되는 AI 세컨드 브레인으로 바꾸는 크로스 CLI 스킬입니다. 이 스킬은 하나의 코드베이스로 Claude Code, Codex CLI, Gemini CLI, OpenCode 네 가지 CLI에서 동일하게 동작합니다. 40여 개의 슬래시 명령으로 회의록과 음성 메모, 스크린샷, 영상, 웹·X 검색 결과를 볼트에 흡수시키고, 그 과정에서 노트를 정리합니다. 저자는 이 프로젝트를 Andrej Karpathy의 LLM Wiki 패턴을 발전시킨 결과물이라고 소개합니다. 핵심 차이는 한 문장으로 요약됩니다. Karpathy의 위키가 LLM과 함께 직접 관리하는 지식 베이스라면, obsidian-second-brain은 스스로를 관리하는 지식 베이스입니다. 새 출처가 들어오면 새 페이지를 덧붙이는 대신 기존 페이지를 다시 쓰고, 모순을 자동으로 조정하며, 패턴이 보이면 종합 페이지를 만듭니다. obsidian-second-brain이 Karpathy의 LLM Wiki를 확장하는 방식 저자는 두 접근의 차이를 표로 정리해 두었습니다. Karpathy의 패턴이 출처를 떨어뜨리면 LLM이 위키 페이지를 만들고 질문에 답하는 구조라면, 이 스킬은 그 위에 자동 유지보수 계층을 더합니다. 구분 Karpathy의 LLM Wiki obsidian-second-brain 새 출처 새 페이지를 덧붙이고 상호 참조 기존 페이지를 다시 씀. 인물 정보가 갱신되고, 주장이 수정되며, 오래된 사실이 교체됨 모순 표시만 하고 사… --- ## [claude-obsidian: Claude Code와 Obsidian으로 만드는 자동 정리형 지식 위키](https://discuss.pytorch.kr/t/claude-obsidian-claude-code-obsidian/10325)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [5월 23, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/claude-obsidian-claude-code-obsidian/10325 "2026-05-23T03:30:37Z")
claude-obsidian 소개 개인 자료를 모아두는 Obsidian 같은 노트 앱은 시간이 지날수록 정리가 어려워집니다. 자료를 모으는 속도는 빠른데, 새 글이 들어왔을 때 기존 페이지와 어떻게 연결되는지를 사람이 직접 관리해야 하고, 며칠만 지나도 어떤 문서가 어디 있었는지 잊어버리기 쉽습니다. claude-obsidian은 이 문제를 지속적으로 누적되는 자동 정리형 위키(persistent, compounding wiki vault) 라는 접근으로 풀려는 오픈소스 프로젝트입니다. Obsidian 볼트(vault) 위에서 Claude Code가 실제 운영자로 동작하며, 새로 추가되는 자료를 읽고, 엔티티와 개념을 추출하고, 교차 참조를 갱신하며, 페이지를 새로 만들거나 수정합니다. claude-obsidian의 설계는 Andrej Karpathy가 제안한 LLM Wiki pattern 을 기반으로 합니다. 핵심 아이디어는 단순합니다. AI가 답을 즉석에서 만들어내는 대신, 사용자가 누적한 자료에서 직접 인용해 답하도록 만드는 것입니다. Claude는 인덱스, 도메인 서브 인덱스, 그리고 개별 위키 페이지를 단계적으로 읽어 답을 합성하고, 그 결과를 학습 데이터가 아닌 사용자의 위키 페이지(specific wiki pages) 로 인용합니다. 모든 세션이 끝날 때마다 hot cache 파일이 갱신되어 다음 세션의 출발점이 되기 때문에, 대화를 다시 시작하더라도 최근 맥락을 처음부터 설명할 필요가 없습니다. claude-obsidian은 MIT 라이선스로 공개된 Claude Code 플러그인이자 Obsidian 볼트 템플릿으로, README 기준 11개의 스킬(skills)을 갖추고 있습니다. 본 게시물에서는 claude-obsidian이 노트 관리에 접근하는 방식, 핵심 명령과 모드, 그리고 설치하여 자신의 자료로 위키를 시작하는 방법을 살펴봅니다. claude-obsidian의 동작 방식 claude-obsidian이 노트를 다루는 사이클은 크게… --- ## [seCall: AI 에이전트와 나눈 대화를 로컬 위키로 정리하고 검색하는 Rust 도구](https://discuss.pytorch.kr/t/secall-ai-rust/10112)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [5월 9, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/secall-ai-rust/10112 "2026-05-09T09:30:12Z")
seCall 소개 Claude Code, Codex CLI, Gemini CLI, claude.ai, ChatGPT 등 여러 AI 에이전트와 주고받은 대화는 각자의 형식과 위치에 흩어져 저장됩니다. 어제 디버깅하면서 합의한 아키텍처 결정이나 의존성 업그레이드 시 적용했던 패치 노트가 어느 세션에 있었는지 다시 찾으려고 하면, 결국 폴더를 뒤지고 grep을 돌리는 일이 반복됩니다. AI 에이전트가 늘어날수록 이 흩어짐 문제는 더 커지고, "지난번에 그 업스트림 에러 어떻게 패치했더라"를 추적하는 것 자체가 부담이 됩니다. seCall은 이 문제를 로컬 퍼스트(local-first) 도구로 풀어내는 Rust 기반 오픈소스입니다. 여러 에이전트의 세션 로그를 통일된 형식으로 파싱하여 SQLite와 Obsidian 호환 마크다운 볼트(vault)에 저장하고, 그 위에 LLM이 정리한 위키(wiki) 페이지를 얹어 두 계층을 모두 검색할 수 있게 합니다. 검색은 BM25 전문 검색과 BGE-M3 임베딩(embedding) 기반 시맨틱 검색을 동시에 사용하는 하이브리드 방식이며, CLI, 내장 웹 UI, REST API, MCP 서버, Obsidian 플러그인 등 어디서든 같은 인덱스에 접근할 수 있습니다. seCall 프로젝트는 Andrej Karpathy의 LLM Wiki 컨셉(원본 소스를 보존한 채 LLM이 점진적으로 위키를 빌드하는 패턴)과 Tobi Lütke의 마크다운 검색 도구 qmd를 직접적인 출발점으로 삼고 있으며, 그래프 추출 부분은 Safi Shamsi의 graphify에서 영감을 받았습니다. 자체 멀티 에이전트 워크플로우 도구인 tunaFlow로 Claude Code와 Codex를 오케스트레이션해 개발된 것도 특징입니다. seCall의 멀티 에이전트 수집 파이프라인 seCall은 코딩 에이전트별로 다른 세션 포맷을 통합 모델(Session → Turn → Action)로 정규화하여 다룹니다. 현재 안정 단계로 지원되는 에이전트는 다음과…