Obsidian CEO Steph Ango의 볼트 운영 철학은 “루트에 전부 넣어라”입니다. 폴더 중심 정리와 링크 중심 정리는 근본적으로 다른 지식관리 철학이고, 여기에 Notion DB 기반 온톨로지 접근법까지 더하면 선택지가 3가지가 됩니다. 어떤 게 맞냐는 사람마다 달라요. 2026년 2월 기준.
사실 저도 폴더 정리를 믿었어요
저 Obsidian 쓴 지 꽤 됐는데, 솔직히 말하면 처음엔 폴더 구조에 엄청 공을 들였어요.
“AI 관련 노트는 여기, 재테크는 저기, 업무는 저 폴더에.” 그렇게 열심히 분류했는데요.
6개월 후에 어떻게 됐냐면.
어떤 노트가 어디 있는지 제가 모릅니다. 검색 쳐서 찾습니다. 결국 폴더는 있으나마나가 됐어요.
이거 저만 그런 게 아니더라고요. Obsidian 쓰는 사람들한테 물어보면 거의 다 비슷한 경험을 얘기해요. “처음엔 폴더 엄청 만들었는데 지금은 다 검색으로 찾아요.”
왜 폴더 중심 정리가 오래 못 가는가
폴더 정리에는 구조적인 한계가 있어요.
첫째, 하나의 노트는 여러 맥락에 걸쳐 있어요.
예를 들어 “Claude API 비용 최적화”라는 노트가 있다고 해봐요. 이게 AI 폴더에 들어가야 할까요, 비용 관리 폴더에 들어가야 할까요, 아니면 개발 팁 폴더에 들어가야 할까요?
어디에 넣든 나머지 맥락에서는 “없는 노트”가 됩니다.
둘째, 폴더 구조는 시간이 지나면서 당신의 생각 구조와 어긋나기 시작해요.
2년 전에 만든 폴더 분류 기준이 지금 당신의 생각 방식과 같을 리가 없거든요. 근데 폴더는 그 구조를 그대로 유지하고 있어요. 그래서 점점 “이게 어디 들어가야 하지?”가 늘어납니다.
셋째, 폴더는 관계를 표현 못해요.
AI와 비용 관리가 연결된다는 사실, 어떤 기술이 어떤 다른 개념과 연결된다는 사실을 폴더 구조는 담을 수 없어요. 폴더는 분류를 하지, 연결을 하지는 않거든요.
Steph Ango: “폴더 쓰지 마세요”
Obsidian CEO인 Steph Ango(GitHub username: kepano)는 자신의 볼트 운영 방식을 공개했어요.
출처: https://stephango.com/vault
핵심만 뽑으면 이렇습니다.
원칙 1: 거의 모든 노트는 루트(최상위 폴더)에 넣는다
폴더를 최소화합니다. 그의 볼트 폴더 구조는 이렇게요:
루트 (Root) ├── References/ ← 외부 세계의 것들 (책, 영화, 사람, 장소, 팟캐스트) ├── Clippings/ ← 다른 사람이 쓴 글 클리핑 ├── Attachments/ ← 미디어 파일 (파일 탐색에 안 뜨게) └── Daily/ ← 일간 노트 (파일 탐색에 안 뜨게)
그리고 나머지, 즉 본인이 직접 쓴 에세이, 저널, 에버그린 노트는 전부 루트에 있어요.
왜요? “루트에 있으면 내가 직접 쓴 것”이라는 의미가 부여되기 때문이에요. 자연스러운 신호가 생기는 거죠.
원칙 2: 분류는 categories 속성(property)으로 한다
폴더 대신 YAML 프론트매터에 categories 속성을 씁니다. 하나의 노트가 여러 카테고리에 속할 수 있어요. 폴더는 하나만 선택해야 하지만, 속성은 여러 개를 달 수 있거든요.
--- categories: - ai - productivity - tools ---
이걸 Obsidian Bases(데이터뷰 후속)로 보면 카테고리별 개요 뷰가 됩니다. 그는 3,000개가 넘던 Dataview 쿼리를 약 30개의 Bases로 마이그레이션했다고 해요.
원칙 3: 링크를 아낌없이 쓴다
[[이중 괄호]] 링크를 쓰는 게 핵심이에요. 특히 그는 “아직 존재하지 않는 노트로의 링크(Unresolved Links)”도 적극적으로 씁니다.
일간 노트 쓸 때 나중에 만들 노트로 링크를 걸어두는 거예요. 그러면 그 링크가 “아직 안 만든 노트”라는 신호를 주고, 언젠가 그 주제를 다룰 때 이미 연결이 형성되어 있어요.
원칙 4: 날짜는 YYYY-MM-DD 포맷으로 어디서나
파일명, 속성, 본문 어디서든 2026-02-19 형식을 씁니다. ISO 8601 표준이고, 소팅도 자연스럽고, 10년 후에도 읽기 쉬워요.
원칙 5: 자동화는 최소한으로
템플릿은 쓰되, 지나친 자동화는 안 해요. 마찰이 없는 시스템은 오히려 생각을 멈추게 한다고 봐요. 노트를 만드는 과정에서 생기는 약간의 마찰이 오히려 사고를 유발한다는 관점이에요.
링크 중심 vs DB 중심 — 다른 방향의 두 접근법
Steph Ango의 방식이 “링크 중심”이라면, 반대쪽에는 “DB 중심” 접근법이 있어요.
Notion 같은 도구를 외부 DB로 활용하는 사람들은 다른 방향으로 갑니다.
DB 중심 접근법이란?
지식을 관계형 데이터베이스처럼 구조화하는 방식이에요. 노트 하나하나가 DB 레코드가 되고, 각 레코드는 속성을 가지고, 레코드들은 명시적인 관계(relation)로 연결됩니다.
예를 들어 이런 구조예요:
[개념 DB]
└── "트랜스포머" 노트
├── 유형: 아키텍처
├── 도메인: AI/ML
├── 연결된 논문: [Attention is All You Need]
├── 응용 사례: [GPT, BERT, Claude]
└── 관련 개념: [어텐션 메커니즘, 임베딩]
[논문 DB]
└── "Attention is All You Need" 노트
├── 발행연도: 2017
├── 저자: Vaswani et al.
├── 관련 개념: [트랜스포머]
└── 후속 연구: [BERT, GPT]
이렇게 하면 “트랜스포머 아키텍처를 사용한 모든 논문을 보여줘”같은 쿼리가 가능해집니다.
링크 중심 방식과 뭐가 다르냐면:
| 항목 | 링크 중심 (Steph Ango 방식) | DB 중심 (온톨로지 방식) |
|---|---|---|
| 연결 방식 | 자유로운 [[링크]] | 명시적 Relation 필드 |
| 구조 | 자연 발생 (Bottom-up) | 설계 필요 (Top-down) |
| 진입 비용 | 낮음 | 높음 (스키마 설계 필요) |
| 쿼리 가능성 | 제한적 | 높음 |
| 유연성 | 높음 | 중간 (스키마에 묶임) |
| 시각화 | 그래프 뷰 | 테이블/캘린더/보드 |
| AI 연동 | 텍스트 기반 RAG | 구조화 데이터 + 에이전트 |
DB 중심 방식을 택하는 사람들이 주로 쓰는 패턴이 있어요. Obsidian을 글쓰기/연결 도구로, Notion을 구조화된 DB로 분리해서 쓰는 거예요.
이런 “투 툴 접근법”을 쓰는 사람들은 이런 식으로 역할을 나눠요:
- Obsidian: 자유롭게 생각하고 연결하는 공간. 일간 노트, 에버그린 노트, 아이디어 흐름.
- Notion (외부 DB): 구조화된 지식 레코드. 책 DB, 프로젝트 DB, 개념 온톨로지.
그리고 최근에는 AI 에이전트를 연동해서 Notion DB에 쿼리를 날리는 방식까지 발전하고 있어요. “내 독서 DB에서 AI 관련 책 중 별점 4점 이상인 것만 보여줘”같은 게 가능해지는 거죠.
어떤 사람에게 어떤 방식이 맞는가
솔직하게 나눠볼게요.
Steph Ango의 링크 중심 방식이 맞는 사람
- 글을 많이 쓰는 사람 (블로거, 작가, 연구자)
- 아이디어 사이의 연결을 발견하는 게 중요한 사람
- 관리 부담 없이 빠르게 노트를 던져두고 싶은 사람
- “지금 이 노트가 어디 들어가지?”로 시간 낭비하기 싫은 사람
- 개인 사용 위주, 협업 필요 없는 사람
이 방식의 핵심 메시지는 **”시스템이 당신의 생각을 방해하지 않아야 한다”**는 거예요. 폴더 선택에 인지 자원을 쓰지 말고, 그냥 루트에 던지고 링크로 연결하면 그래프가 알아서 구조를 보여준다는 철학입니다.
실제로 이 방식을 쓰는 사람들이 하는 말이 있어요. “일단 쓴다, 정리는 나중에”가 아니라 “링크가 곧 정리”라는 거예요.
DB 중심 온톨로지 방식이 맞는 사람
- 특정 도메인 지식을 깊게 파고드는 사람 (연구자, 전문가)
- 나중에 쿼리해서 패턴을 찾고 싶은 사람
- AI 에이전트와 연동해서 지식을 활용하고 싶은 사람
- 다른 사람과 지식을 공유하거나 협업하는 사람
- “이 개념들 사이의 관계를 명시적으로 표현하고 싶다”는 욕구가 있는 사람
이 방식의 핵심은 **”나중에 쓸 수 있는 구조를 지금 만들어놓는다”**는 거예요. 초기 비용이 크지만, 나중에 도구(AI 포함)가 그 구조를 활용할 수 있게 됩니다.
특히 최근 AI 도구들이 구조화된 데이터를 잘 활용하면서, 이 방식의 장점이 더 두드러지고 있어요. Notion API나 MCP(Model Context Protocol) 같은 걸 활용하면 AI 에이전트가 직접 DB를 쿼리할 수 있거든요.
근데 두 방식 중에 하나만 골라야 하는 건 아니에요.
실제로 둘을 조합하는 사람들이 많아요:
- Obsidian에서 생각하고, Notion/DB에서 정리한다
- 아이디어 단계는 링크 중심, 완성된 개념은 DB에 레코드로 옮긴다
- 일간 노트/저널은 Obsidian, 프로젝트/지식 베이스는 Notion
어떤 조합이든, 중요한 건 **”이 시스템이 내 생각을 돕고 있는가, 아니면 관리 부담이 되고 있는가”**를 주기적으로 점검하는 거예요.
“File over App” — Steph Ango의 더 깊은 철학
Steph Ango가 Obsidian을 만든 방향성에는 단순한 노트 앱을 넘어선 철학이 있어요.
2023년 그가 제안한 개념이 “File over App“이에요.
핵심은 이거예요: 앱은 결국 사라지지만, 파일은 남는다.
당신이 5년 동안 정성들여 쌓은 노션 DB가 있다고 해봐요. 노션이 갑자기 서비스를 종료하거나, 비즈니스 모델을 바꾸거나, 인수되면 어떻게 됩니까? 그 안에 있는 데이터는 노션 포맷에 묶여있어요.
반면 Obsidian이 없어진다면? 볼트 안의 파일들은 그냥 Markdown 텍스트 파일이에요. 어느 텍스트 에디터로든 열 수 있어요. VS Code, Vim, 메모장으로도요.
이게 Ango가 “1960년대 컴퓨터로도 읽을 수 있어야 진짜 오래 가는 것”이라고 말한 맥락이에요.
지금 당장 적용할 수 있는 최소 원칙
자, 정리해봅시다.
지금 Obsidian(또는 어떤 노트 앱이든) 쓰면서 폴더 정리가 계속 무너진다면, 세 가지 중 하나를 해보세요.
옵션 A: Steph Ango 방식 적용
바로 오늘 시작할 수 있는 최소 버전:
1. 새 노트는 일단 루트에 넣는다 2. 파일명에 날짜 붙인다 (YYYY-MM-DD 형식) 3. 본문 쓸 때 관련 개념에 [[링크]] 건다 4. 폴더는 References, Clippings, Attachments 세 개만 5. 카테고리는 YAML 속성으로 처리
이게 전부예요. 폴더 열심히 만들지 마세요.
옵션 B: DB 중심 방식 실험
본인의 핵심 관심 도메인 하나를 골라서 Notion에 DB를 만들어보세요.
예를 들어 책을 많이 읽는다면:
[독서 DB] - 제목 - 저자 - 카테고리 (다중 선택) - 독서일 - 핵심 인사이트 (텍스트) - 관련 개념 (다른 DB와 관계) - 별점
이걸 만들어두면 나중에 “AI 관련 책 중 5점짜리만 뽑아줘”가 가능해집니다.
옵션 C: 지금 시스템 점검
아무것도 바꾸기 전에, 지금 시스템에 대해 이 질문에 답해보세요:
- 6개월 전에 쓴 노트를 쉽게 찾을 수 있는가?
- 새 노트 만들 때 “어디에 넣지?”로 5초 이상 고민하는가?
- 노트들 사이의 연결이 보이는가?
- 관리 부담 때문에 노트 쓰기가 귀찮아진 적 있는가?
대부분 “예”라면 현재 시스템이 당신의 생각을 방해하고 있는 거예요. 뭔가를 바꿀 시점입니다.
결론: 맞고 틀린 게 없다, 근데 물어봐야 할 건 있다
Steph Ango의 링크 중심 방식도 맞고, DB 중심 온톨로지 방식도 맞아요.
공통점이 뭔지 아세요?
둘 다 “폴더 계층 구조로 모든 걸 분류하겠다”는 환상을 버렸다는 거예요.
폴더 중심 정리의 근본 문제는 “하나의 노트는 하나의 폴더에만 들어갈 수 있다”는 제약이에요. 근데 현실의 지식은 그런 식으로 존재하지 않거든요.
링크 중심은 그 제약을 관계망으로 풀고, DB 중심은 그 제약을 관계형 구조로 풀어요.
당신한테 맞는 질문은 이거예요:
“내가 지식에서 원하는 게 연결인가, 쿼리인가?”
연결을 원하면 Steph Ango 방식. 내 생각들이 어떻게 이어지는지 보고 싶다면요.
쿼리를 원하면 DB 방식. “이런 조건의 정보를 뽑아줘”가 중요하다면요.
둘 다 원하면? 조합하면 됩니다. Obsidian에서 생각하고, DB에서 정리하고.
가장 나쁜 선택은 폴더 열심히 만들면서 6개월마다 리셋하는 거예요.
참고 자료
- Steph Ango 볼트 운영 방식 원문: https://stephango.com/vault
- Steph Ango GitHub 볼트 템플릿: https://github.com/kepano/kepano-obsidian
- File over App 철학: https://stephango.com/file-over-app