에듀프레너의 엔진: Obsidian을 지식 운영체제로 쓰는 법

교육자와 1인 창작자가 Obsidian을 단순 노트앱이 아니라 Inbox, Reference, Permanent Note, Project, System으로 이어지는 지식 엔진으로 설계하는 방법.

Obsidian을 오래 쓰다 보면 한 가지 착각에 빠지기 쉽다.
링크가 많아지면 지식이 많아진 것 같고, 그래프가 예쁘게 퍼지면 생각도 정리된 것처럼 보인다.

하지만 노트앱은 그 자체로 지식 엔진이 아니다.
엔진이 되려면 흐름이 있어야 한다. 무엇이 들어오고, 어디서 검토되고, 어떤 것이 오래 남고, 어떤 것이 산출물로 나가는지 정해져 있어야 한다.

교육자, 강사, 1인 창작자, 학원 운영자에게 Obsidian은 단순한 메모장이 아니라 작은 운영체제가 될 수 있다. 수업 아이디어, 학부모 상담 기록, 원서 독해 자료, AI 실험, 블로그 초안, 워크시트, 강의안이 한곳에서 서로 연결될 수 있기 때문이다.

좋은 볼트는 폴더가 아니라 흐름으로 설계된다

내가 가장 실용적이라고 보는 구조는 다섯 구역이다.

구역 역할 질문
00_Inbox 수집 아직 판단하지 않은 것은 어디에 둘 것인가
10_References 참조 원문, 논문, 영상, 자료는 어디에 보관할 것인가
20_Permanent 통찰 시간이 지나도 남길 내 생각은 무엇인가
30_Projects 산출 지금 만들고 있는 글, 강의, 앱은 무엇인가
99_System 운영 템플릿, 스크립트, 규칙은 어디에 둘 것인가

이 구조의 핵심은 폴더 이름이 아니다.
판단의 순서다.

모든 생각을 곧바로 영구 노트로 만들려고 하면 볼트는 금세 무거워진다. 반대로 모든 것을 Inbox에만 쌓아두면 지식은 움직이지 않는다. 좋은 구조는 잡생각을 받아들이되, 일정한 통로를 지나게 만든다.

Inbox는 항구다.
References는 도서관이다.
Permanent Notes는 연구실이다.
Projects는 공장이다.
System은 엔진룸이다.

이 비유를 머릿속에 두면 Obsidian을 정리할 때 덜 헤맨다.

세 개의 플러그인만으로도 충분하다

Obsidian을 쓰다 보면 플러그인을 계속 설치하고 싶어진다. 하지만 지식 운영체제의 기본 엔진은 더 단순해도 된다.

첫째, Dataview.
노트를 데이터처럼 조회하게 해 준다. 예를 들어 최근 수정된 프로젝트 노트, 특정 태그가 붙은 수업 아이디어, 아직 발행하지 않은 블로그 초안을 표로 뽑을 수 있다.

1
2
3
4
TABLE file.mtime as "수정일", status as "상태"
FROM "30_Projects"
WHERE publish = true
SORT file.mtime DESC

둘째, Templater.
반복되는 frontmatter와 글 구조를 자동으로 채운다. 블로그 글, 독서 노트, 수업 설계안, 학부모 상담 기록은 매번 같은 질문을 필요로 한다. 템플릿은 그 질문을 잊지 않게 하는 장치다.

셋째, Git.
지식을 코드처럼 다루게 해 준다. 되돌릴 수 있고, 비교할 수 있고, 다른 로컬에서도 이어서 작업할 수 있다. LLM 에이전트에게 맡길 때도 Git이 있으면 변경 이력을 추적할 수 있다.

이 세 가지가 있으면 Obsidian은 단순한 노트앱에서 검토 가능한 지식 시스템으로 바뀐다.

Obsidian은 LLM Wiki의 IDE가 될 수 있다

LLM Wiki 관점에서 Obsidian의 장점은 명확하다.

  1. 파일이 Markdown이라 사람이 읽을 수 있다.
  2. 링크가 명시적이라 지식 구조가 보인다.
  3. frontmatter를 통해 메타데이터를 붙일 수 있다.
  4. Git으로 변경 이력을 남길 수 있다.
  5. 에이전트가 파일 단위로 읽고 고칠 수 있다.

중요한 것은 노트를 많이 모으는 일이 아니다.
에이전트가 다시 읽을 수 있는 구조로 남기는 일이다.

예를 들어 이런 frontmatter는 단순한 장식이 아니다.

1
2
3
4
5
6
7
8
9
---
type: "Permanent Note"
domain: "English Education"
status: "reviewed"
agent_usable: true
publishable: false
source_count: 3
updated: 2026-06-24
---

이 정보가 있으면 에이전트는 이 노트를 공개 글에 써도 되는지, 참조만 해야 하는지, 검토가 필요한지 판단할 수 있다. 즉 frontmatter는 사람을 위한 분류표이면서 동시에 AI를 위한 사용 허가서다.

무거운 파일은 볼트 안에 넣지 않는다

볼트가 느려지는 가장 흔한 이유는 모든 것을 안에 넣으려 하기 때문이다. 영상, 대용량 PDF, 이미지 원본, 음원 파일을 전부 Obsidian 안에 넣으면 검색과 동기화가 무거워진다.

대신 Obsidian은 지도를 맡고, 무거운 파일은 외부 저장소에 둔다.

1
[강의 영상 1강](file:///D:/LectureVideos/lesson-01.mp4)

이 방식은 단순하지만 강력하다. Obsidian에는 맥락, 요약, 태그, 링크, 판단이 남고, 원본 자산은 적절한 저장소에 머문다. 블로그도 같은 원리로 운영할 수 있다. 원본 노트와 공개 포스트, 이미지, 오디오, SRT, 배포 결과를 분리해야 한다.

건강한 볼트는 매주 점검된다

지식 시스템은 한 번 설계하고 끝나는 물건이 아니다.
정원처럼 계속 살펴야 한다.

간단한 점검 질문은 이렇다.

  • Inbox가 너무 오래 쌓여 있지 않은가?
  • References만 많고 Permanent Note가 부족하지 않은가?
  • Project 폴더에 끝나지 않은 초안이 너무 많지 않은가?
  • System 폴더의 템플릿이 실제 작업을 돕고 있는가?
  • 블로그로 나갈 수 있는 노트가 Ready 상태로 표시되어 있는가?

Dataview로도 확인할 수 있다.

1
2
3
4
TABLE length(rows) as "노트 수"
FROM !"99_System"
GROUP BY file.folder
SORT length(rows) DESC

00_Inbox만 비대해지고 있다면 수집은 되고 있지만 소화는 안 되는 상태다.
20_Permanent30_Projects가 함께 자라고 있다면 생각이 산출물로 이어지고 있는 상태다.

결론: 내 지식 엔진은 내가 튜닝해야 한다

좋은 Obsidian 볼트는 남이 준 템플릿을 그대로 복사해서 만들어지지 않는다.
자신의 일, 글쓰기, 수업, 연구, 블로그, 앱 개발 흐름에 맞춰 계속 튜닝해야 한다.

나에게 Obsidian은 더 이상 메모장이 아니다.
LLM Wiki의 IDE이고, 블로그의 원천 저장소이며, 에이전트가 다시 읽는 지식 코드베이스다.

핵심은 단순하다.

수집한다.
참조한다.
생각으로 바꾼다.
산출물로 만든다.
시스템으로 반복한다.

이 다섯 단계가 살아 있으면, 노트는 쌓이는 것이 아니라 움직인다.

Comments

댓글

GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.