jaysnote
12분

[LLM Wiki 13] Obsidian: 로컬 Markdown으로 지식 그래프를 만드는 작업대

Obsidian의 핵심 컨셉, Vault, 내부 링크, Graph View, Search, Properties, Dataview, Git, qmd와의 연결 흐름을 설명한다.

#LLM Wiki #Obsidian #Markdown #Graph View #지식관리

Obsidian의 핵심은 Vault다

Obsidian은 단순한 메모 앱처럼 보이지만, 실제 컨셉은 조금 다르다. Obsidian은 로컬 폴더 안의 Markdown 파일을 하나의 지식 작업 공간으로 다루는 도구다. 이 폴더를 Vault라고 부른다.

Vault 안의 노트는 일반 .md 파일이다. 그래서 Obsidian을 쓰다가 그만둬도 파일은 남는다. VS Code, 터미널, Git, qmd, LLM agent 같은 외부 도구가 그대로 읽을 수 있다. 이 점이 Notion이나 Confluence 같은 서버형 문서 도구와 가장 큰 차이다.

Obsidian을 LLM Wiki 관점에서 보면 이렇게 이해하면 쉽다.

  • Vault는 로컬 지식 저장소다.
  • Markdown 파일은 사람이 읽고 고칠 수 있는 지식 카드다.
  • Internal Link는 카드 사이의 연결이다.
  • Graph View는 그 연결 상태를 시각화한다.
  • Search와 Dataview는 필요한 노트를 찾고 상태를 점검한다.
  • Git과 qmd를 붙이면 버전 관리와 자연어 검색까지 확장된다.

Obsidian의 기본 컨셉

Obsidian은 문서를 서버에 올려서 관리하는 앱보다, 내 컴퓨터의 Markdown 폴더를 강력하게 탐색하는 앱에 가깝다.

핵심 단위는 세 가지다.

  • Vault: 노트들이 들어 있는 로컬 폴더
  • Note: Markdown 파일 하나
  • Link: 노트와 노트를 연결하는 참조

Obsidian의 강점은 노트를 폴더에만 가두지 않는다는 점이다. 폴더는 파일 위치를 정리하고, 링크는 생각의 관계를 정리한다.

예를 들어 회의록 하나가 있다고 하자.

  • 2026-06-28 제품 회의.md

이 회의록 안에서 Enterprise Pricing, usage-based pricing 결정, Jay usage data 확인 액션, 가격정책 같은 노트로 연결할 수 있다. 그러면 회의록은 더 이상 고립된 파일이 아니다. 프로젝트, 결정, 액션, 주제와 연결된 지식 노드가 된다.

Internal Link와 Graph View

Internal Link가 지식 그래프를 만든다

Obsidian에서 가장 중요한 기능은 Internal Link다. 보통 [[노트 이름]] 형태로 다른 노트를 연결한다. 이 링크가 쌓이면 Vault 안에 자연스럽게 지식 그래프가 만들어진다.

Graph View는 이 관계를 시각적으로 보여준다. 노트는 node처럼 보이고, 노트 사이의 링크는 edge처럼 보인다.

Graph View를 쓰면 다음을 빠르게 볼 수 있다.

  • 어떤 노트가 많은 문서와 연결되는 허브인지
  • 어떤 노트가 아무 곳에도 연결되지 않은 고립 노트인지
  • 특정 프로젝트 주변에 어떤 회의, 결정, 액션이 붙어 있는지
  • 너무 많은 링크가 한 노트에 몰려 구조가 뭉개지고 있지는 않은지

전체 Graph View는 Vault 전체의 구조를 보여준다. Local Graph는 현재 보고 있는 노트 주변만 보여준다. LLM Wiki나 회의록 시스템에서는 Local Graph가 더 실용적인 경우가 많다. 이 결정이 어떤 회의와 프로젝트에 연결되어 있나를 좁게 볼 수 있기 때문이다.

Obsidian과 LLM Wiki는 무엇이 다른가

Obsidian과 LLM Wiki 구현의 차이

Obsidian은 LLM Wiki의 구현체라기보다, LLM Wiki를 만들기 좋은 작업대에 가깝다. 둘 다 Markdown 파일과 링크를 중요하게 보지만, 역할이 다르다.

Obsidian은 사람이 노트를 읽고, 고치고, 연결하고, Graph View로 구조를 보는 앱이다. Vault, Note, Internal Link, Backlink, Graph View, Search 같은 기능을 제공한다. 하지만 이 기능만으로 원본 회의록을 자동으로 읽고, Meeting, Decision, Action, Project 카드로 분해하고, 누락을 점검하고, 오래된 결정을 갱신하는 일까지 해주지는 않는다.

LLM Wiki는 특정 앱 이름이 아니라 운영 방식이다. 원본 자료를 raw 계층에 두고, LLM이 스키마에 맞춰 wiki card를 만들고, 사람이 검토할 수 있게 누적한다. 여기에 검색(qmd), 상태 점검(Dataview), 변경 이력(Git), 관계 추출(Graph Index), 품질 점검(Lint)이 붙어야 비로소 회의록 LLM Wiki에 가까워진다.

직접 구현한다면 구조는 이렇게 나뉜다.

  • Obsidian: 사람이 보는 UI, 링크 탐색, Graph View
  • Markdown Vault: 실제 데이터 저장소
  • LLM Agent: 회의록을 읽고 카드 생성, 갱신
  • Schema와 Template: Meeting, Decision, Action 형식 고정
  • qmd: 관련 노트 후보 검색
  • Dataview 또는 스크립트: 누락 필드와 상태 점검
  • Git: LLM이 바꾼 내용의 diff, 복구, 감사 기록
  • Graph Index: 링크를 의미 있는 관계 edge로 정제

그래서 “Obsidian으로 LLM Wiki를 구현했다”는 말은 정확히는 “Obsidian Vault를 사람이 보는 지식층으로 두고, 그 주변에 LLM ingest, 검색, 검증, 버전 관리를 붙였다”는 뜻에 가깝다.

회의록 관리 흐름

회의록을 Obsidian에서 관리하는 기본 흐름

회의록을 Obsidian에서 관리한다면 흐름은 단순하게 시작하는 것이 좋다.

먼저 원문을 Markdown으로 남긴다. 회의 중 직접 쓴 메모, 녹취 요약, 회의 후 정리본 모두 가능하다.

그다음 Properties와 템플릿으로 기본 구조를 맞춘다. 날짜, 참석자, 프로젝트, 회의 타입, 상태, source 같은 필드를 넣으면 나중에 검색과 집계가 쉬워진다.

이후 회의록 안에서 중요한 정보를 링크로 연결한다. 결정은 Decision 노트로, 할 일은 Action 노트로, 진행 중인 일은 Project 노트로, 반복 주제는 Topic 노트로 연결한다.

마지막으로 Search, Graph View, Dataview로 누락을 점검한다. 예를 들어 source 없는 decision, owner 없는 action, 프로젝트와 연결되지 않은 meeting을 찾는다.

이 구조가 만들어지면 qmd나 LLM agent를 붙일 수 있다. LLM은 모든 원문을 매번 읽는 대신, 관련 노트와 링크 구조를 읽고 답할 수 있다.

주요 기능을 LLM Wiki 관점에서 보기

Obsidian에서 자주 쓰는 핵심 기능

Obsidian의 기능은 많지만, LLM Wiki나 회의록 지식베이스를 만들 때는 몇 가지만 잘 쓰면 된다.

Internal Links는 노트 사이의 명시적 연결이다. 회의록에서 나온 결정, 액션, 프로젝트, 주제를 연결할 때 쓴다.

Backlinks는 역방향 연결이다. 현재 노트를 언급한 다른 노트를 보여준다. 예를 들어 Enterprise Pricing 프로젝트 노트를 열었을 때, 이 프로젝트를 언급한 모든 회의록과 결정 노트를 볼 수 있다.

Graph View는 전체 구조를 눈으로 보는 기능이다. 완성된 답을 주는 도구는 아니지만, 지식베이스가 잘 연결되고 있는지 점검하는 데 좋다.

Search는 기본 검색이다. 키워드로 빠르게 찾을 때 유용하다. 다만 회의록이 아주 많아지고 자연어 질문이 많아지면 qmd 같은 별도 검색 레이어를 붙이는 편이 더 강하다.

Properties는 노트의 메타데이터다. 예를 들어 type, date, project, status 같은 필드를 둘 수 있다. 이 필드는 Dataview, 검색, LLM ingest에 모두 유용하다.

Templates는 노트 형식을 일정하게 만든다. 회의록, 결정, 액션, 프로젝트 노트의 섹션을 미리 정해두면 LLM이 읽기에도 좋고 사람이 검토하기에도 좋다.

Obsidian과 Dataview, qmd, Git

Obsidian을 LLM Wiki 작업대로 쓰는 구조

Obsidian만으로도 개인 지식관리는 가능하다. 하지만 회의록 LLM Wiki처럼 운영형 지식베이스를 만들려면 주변 도구를 붙이는 것이 좋다.

Dataview는 Obsidian의 community plugin으로, Markdown 노트의 Properties를 읽어 표나 목록을 만들 수 있다. 예를 들어 열린 action 목록, due date가 지난 action, source가 없는 decision을 찾아낼 수 있다.

qmd는 자연어 검색 레이어로 붙일 수 있다. Obsidian Vault는 결국 Markdown 폴더이므로, qmd가 색인하기 좋다. qmd는 BM25, vector search, reranking으로 가격 부담이 나온 고객 미팅 같은 질문에 맞는 노트를 찾아준다.

Git은 버전 관리와 복구에 유용하다. 특히 LLM agent가 노트를 자동으로 만들거나 수정한다면 Git diff가 중요하다. 어떤 노트가 바뀌었는지, LLM이 잘못 지운 내용은 없는지, 이전 버전으로 되돌릴 수 있는지 확인할 수 있다.

이 조합을 쓰면 Obsidian은 사람이 읽고 고치는 UI가 되고, qmd는 검색, Dataview는 상태 점검, Git은 변경 이력, LLM agent는 반복 편집을 맡는다.

외부 사용 예

Obsidian의 대표적 사용 예

Obsidian은 특정 분야 전용 도구가 아니다. Markdown 파일과 링크 구조가 필요한 곳이면 여러 방식으로 쓸 수 있다.

개인 지식관리에서는 읽은 글, 아이디어, 공부 노트를 연결한다. 책 요약, 논문 메모, 기술 개념, 질문 목록을 따로 쓰고 서로 링크한다.

연구와 글쓰기에서는 출처 노트, 주장 노트, 초안 노트를 분리할 수 있다. 하나의 긴 문서에 모든 것을 넣기보다, 작은 노트를 연결해 글의 재료를 만든다.

프로젝트 운영에서는 회의록, 결정, 액션, 리스크, 프로젝트 상태를 연결한다. 이 방식은 회의록 LLM Wiki와 특히 잘 맞는다.

LLM Wiki에서는 LLM이 만든 요약과 카드가 Obsidian Vault에 쌓인다. 사람이 Obsidian에서 읽고 고치고, LLM은 그 Vault를 다시 읽어 다음 답변이나 요약을 만든다.

Obsidian을 회의록 LLM Wiki에 쓸 때의 장점

Obsidian의 가장 큰 장점은 데이터가 단순하다는 것이다. 파일은 Markdown이고, 링크는 텍스트이며, 메타데이터는 Properties로 남는다. 그래서 다른 도구와 연결하기 쉽다.

회의록 LLM Wiki에서는 특히 다음 장점이 크다.

  • 원본과 요약을 파일로 명확히 분리할 수 있다.
  • Meeting, Decision, Action, Project, Topic 카드를 작게 나눌 수 있다.
  • Internal Link로 사람이 이해할 수 있는 관계를 만들 수 있다.
  • Graph View로 연결 상태를 눈으로 확인할 수 있다.
  • Dataview로 누락과 상태를 점검할 수 있다.
  • Git으로 LLM 수정 이력을 추적할 수 있다.
  • qmd로 자연어 검색을 붙일 수 있다.

즉 Obsidian은 완성된 엔터프라이즈 지식 시스템이라기보다, LLM Wiki를 시작하기 좋은 로컬 작업대에 가깝다.

한계도 있다

Obsidian은 강하지만 모든 것을 해결하지는 않는다.

첫째, 기본 Graph View는 관계의 의미를 구분하지 않는다. 링크가 언급인지, 영향인지, 대체인지, 담당인지는 사람이 정하거나 별도 스키마로 관리해야 한다.

둘째, 권한 관리와 협업 워크플로는 Confluence나 Notion 같은 서버형 도구보다 약할 수 있다. 개인 vault에는 좋지만, 큰 조직의 승인, 권한, 감사 로그가 필요하면 별도 시스템이 필요하다.

셋째, 검색은 기본 Search만으로는 한계가 있다. 회의록이 많고 자연어 질문이 중요하다면 qmd, vector search, reranker 같은 검색 계층을 붙이는 편이 좋다.

넷째, LLM 자동 편집을 붙이면 검증 장치가 필요하다. 스키마, 템플릿, Git diff, source 링크, audit log 없이는 wiki가 금방 지저분해질 수 있다.

다섯째, Obsidian Graph View는 예쁜 관계 지도일 수는 있지만 그 자체가 Graph RAG 엔진은 아니다. Graph RAG로 쓰려면 Meeting creates Decision, Decision affects Project, Action owned_by Person처럼 관계 타입을 명시적으로 추출하고, 그 관계를 검색 가능한 인덱스로 따로 저장해야 한다.

여섯째, 직접 구현한 LLM Wiki는 품질 책임이 구현자에게 있다. LLM이 잘못 요약하거나, 오래된 결정과 새 결정을 섞거나, 링크를 과하게 만들 수 있다. 그래서 source 링크, 버전 번호, 변경 로그, 검증 질문 세트, 사람이 승인하는 단계가 필요하다.

권장 시작 구조

회의록 LLM Wiki를 Obsidian으로 시작한다면 처음부터 복잡하게 만들 필요는 없다.

폴더는 이 정도면 충분하다.

raw/
  meetings/
wiki/
  meetings/
  decisions/
  actions/
  projects/
  topics/
  monthly/
templates/
  meeting.md
  decision.md
  action.md
schemas/
  common.md
  meeting.md
  decision.md
logs/
  ingest-log.md

처음에는 Meeting, Decision, Action, Project, Topic 다섯 종류만 잘 나눠도 된다. 그다음 Properties를 붙이고, Dataview로 상태를 보고, qmd로 검색을 붙이고, 나중에 Graph RAG로 확장하면 된다.

Obsidian은 LLM Wiki의 전부는 아니다. 하지만 사람이 읽고 고칠 수 있는 중간 지식층을 만들기에는 매우 좋은 출발점이다.

출처와 이미지 사용

이 글의 도식 이미지는 외부 스크린샷을 가져온 것이 아니라, 설명을 위해 직접 만든 개념도다. 저작권 문제가 생길 수 있는 실제 Obsidian 화면 캡처나 커뮤니티 예제 이미지는 사용하지 않았다.

참고한 공식 문서와 공개 자료:

관련 글

← 목록으로