Obsidian을 3년 사용한 뒤 폴더 구조를 다시 정비했습니다. 처음 세운 구조가 실제 사용 패턴과 어긋난 지점들이 쌓였고, 이번 재정비에서 배운 것들을 정리합니다.
처음 세운 구조와 문제점
3년 전 처음 Obsidian을 도입했을 때는 PARA 방법론(Projects, Areas, Resources, Archive)에 기반한 4개 최상위 폴더로 시작했습니다.
Vault/
├── 01-Projects/
├── 02-Areas/
├── 03-Resources/
└── 04-Archive/깔끔하고 이론적으로 설득력 있는 구조였지만, 실제 사용에서 몇 가지 문제가 드러났습니다.
첫째, “Areas”와 “Projects”의 경계가 모호했습니다. 이론적으로는 Areas가 지속적 책임, Projects가 완결 목표를 가진 것이었지만, 실제 편집 활동에서는 이 둘이 명확히 나뉘지 않았습니다. 하나의 리뷰 기획이 특정 프로젝트인지 지속적 Area인지 판단이 매번 어려웠고, 결국 노트가 어느 폴더에 있는지 찾기 위해 검색에 의존하게 되었습니다.
둘째, “Resources” 폴더가 잡동사니가 되었습니다. 참고 자료라는 명목으로 무엇이든 여기 들어갔고, 3년 후 이 폴더에는 6백 개가 넘는 노트가 있었습니다. 계층 구조로 세분화해야 했지만 명확한 분류 기준을 잡기 어려웠습니다.
셋째, “Archive” 폴더로 옮기는 의사결정을 미루게 되었습니다. 프로젝트가 완료된 것 같지만 완전히 끝나지 않은 애매한 상태의 노트들이 Projects 폴더에 남아있었고, 이것이 액티브 프로젝트와 뒤섞였습니다.
재정비 원칙
이번 재정비에서 세운 원칙들:
실제 접근 빈도가 우선. 자주 접근하는 노트는 얕은 경로에, 드물게 접근하는 노트는 깊은 경로에. 개념적으로 아름다운 구조보다 실제 사용 패턴을 반영.
분류 기준은 하나만. 각 폴더 레벨에서 하나의 명확한 분류 기준을 유지. 여러 기준이 섞이면 노트가 어디 있는지 예측할 수 없게 됩니다.
태그로 대체 가능한 것은 폴더로 만들지 않기. 폴더는 계층적, 태그는 다차원적. 여러 관점에서 접근하고 싶은 속성은 태그로.
노트가 몇 개 이상 쌓이면 세분화. 하나의 폴더에 30-50개 이상 노트가 쌓이면 서브 폴더로 나누기. 이 임계치는 대략적 감각.
새로운 구조
Vault/
├── inbox/
├── daily/
├── editorial/
│ ├── active/
│ ├── planned/
│ └── done/
├── reference/
│ ├── apps/
│ ├── workflows/
│ ├── dev/
│ └── legacy/
├── knowledge/
│ ├── swift/
│ ├── macos-history/
│ └── writing-craft/
└── meta/inbox/
모든 새 노트가 시작되는 폴더. 웹클리핑, 임시 노트, 나중에 정리할 아이디어. 매주 정리 세션에서 이 폴더의 노트들을 적절한 곳으로 옮기거나 삭제.
이 폴더의 존재 자체가 재정비의 중요한 변화입니다. 새 노트를 만들 때 “어디에 넣을까”라는 판단을 즉시 내리지 않아도 됩니다. inbox에 넣고, 나중에 정리 세션에서 판단.
daily/
일일 노트. 각 노트가 하나의 날짜에 대응. 일지, 미팅 노트, 그날의 아이디어 스크랩. 파일명은 2024-11-15.md 형식.
일일 노트는 Obsidian의 Daily Notes 플러그인으로 자동 생성되고, 템플릿이 자동 적용됩니다. 형식이 일관되어 있어 나중에 검색이 편합니다.
editorial/
편집 관련 활동. 리뷰 기획, 원고 초안, 편집 노트. 상태에 따라 3개 하위 폴더로 명확히 분리.
active/: 지금 진행 중인 편집 작업. 이 폴더는 대개 5-10개 노트만 유지되어야 함. 많으면 정말로 active한 것과 아닌 것이 섞여 있는 상태.
planned/: 앞으로 진행할 편집 아이디어. 아직 시작하지 않은 것. 한 달에 한 번 이 폴더를 재검토하고, 실제로 시작할 수 있는 것은 active로, 실현 가능성이 낮은 것은 삭제하거나 별도 폴더로.
done/: 완료된 편집물. 게시 후에도 참조 가치가 있는 노트들. 년-월 서브 폴더로 자동 아카이빙.
reference/
참조 자료. 도메인별로 하위 폴더 분리.
apps/: 앱별 노트. 각 앱마다 하나의 노트를 유지하고, 시간이 지나면서 관찰과 팁을 여기 추가. 리뷰 원고를 쓸 때 이 노트가 기초 자료.
workflows/: 워크플로우별 노트. 이메일 트리아지, 스크린샷 관리 등. 리뷰 원고와는 별개로 실제 개인 워크플로우 기록.
dev/: 개발 관련 참조. 코드 스니펫, 라이브러리 정보, 자주 참조하는 API.
legacy/: Classic Mac OS 시대와 관련된 자료. 트로픽 소프트웨어의 과거 프로덕트, Mac 소프트웨어 역사 자료.
knowledge/
깊이 있는 지식 노트. reference와 다른 점은 knowledge는 스스로 정리한 개념적 노트, reference는 즉시 참조용 사실 정보.
swift/: Swift 언어와 표준 라이브러리에 대한 학습 노트.
macos-history/: macOS와 Classic Mac OS의 역사, 문화, 변천사에 대한 노트.
writing-craft/: 글쓰기 방법론, 편집 원칙, 스타일 가이드.
meta/
Vault 자체에 대한 노트. Vault 구조 설명, 템플릿, 태그 시스템 정의, 재정비 회고. 이 노트가 지금 여러분이 읽고 있는 이 글의 원형입니다.
태그 시스템
폴더가 하나의 축(주제 도메인)이라면 태그는 다른 축들을 담당합니다.
#status/: 노트의 상태. #status/draft, #status/ready, #status/published. 편집 활동의 상태 관리.
#type/: 노트의 유형. #type/review, #type/workflow, #type/reference, #type/meeting.
#priority/: 우선순위. #priority/high, #priority/low. 대시보드 쿼리에서 활용.
#project/: 관련 프로젝트. #project/mac-review-series. 여러 폴더에 걸친 노트들을 하나의 프로젝트로 묶기.
태그의 계층 구조(/로 구분)는 Obsidian이 자동으로 지원합니다. #status로 태그 뷰를 필터하면 모든 상태별 하위 태그가 그룹으로 표시됩니다.
링크 사용의 재정비
[[백링크]]는 Obsidian의 강점이지만, 처음에는 남용했습니다. 언급되는 모든 개념을 링크로 만들었고, 그래프 뷰가 지나치게 복잡해져 오히려 유용성이 떨어졌습니다.
재정비에서 링크 사용 원칙을 재조정했습니다.
고유명사만 링크. 앱 이름, 사람 이름, 프로젝트 이름은 링크로. 일반명사(에디터, 워크플로우, 개발)는 링크로 만들지 않기.
노트 파일이 있는 것만 링크. 링크가 있는데 대응하는 노트 파일이 없으면 그래프가 깨집니다. 실제 노트가 있을 때만 링크.
Related 섹션 활용. 각 노트의 하단에 “Related” 섹션을 두고, 명시적으로 관련 노트를 링크로 나열. 본문 중간에 자연스럽게 나오는 링크보다 이 방식이 유지보수에 유리.
템플릿
재정비하면서 몇 가지 표준 템플릿을 정의했습니다.
일일 노트 템플릿. 오늘 할 일, 아이디어, 관찰, 로그 섹션. 매일 아침 자동 생성.
앱 노트 템플릿. reference/apps/ 폴더의 노트를 위한 표준. 앱 이름, 카테고리, 첫 도입 시기, 관찰, 팁, 관련 리뷰 링크.
워크플로우 노트 템플릿. reference/workflows/ 폴더용. 문제 정의, 도구, 실제 셋업, 관찰, 대안.
편집 노트 템플릿. editorial/ 폴더용. 주제, 각도, 대상 독자, 취재 목록, 개요, 초안, 상태.
템플릿은 Obsidian의 Templates 코어 플러그인으로 관리됩니다. 새 노트 생성 시 Command+Palette에서 “Insert template”로 삽입.
이전 절차
이전 구조에서 새 구조로 옮기는 것은 큰 작업이었습니다. 접근:
1. 새 폴더 구조 먼저 생성. 기존 노트는 그대로 둔 채 새 폴더만 만들기.
2. 앞으로 새로 만드는 노트만 새 구조에 맞춰 배치. 기존 노트는 자연스럽게 접근할 때마다 새 위치로 옮김.
3. 4주가 지나면 자주 접근하는 노트는 대부분 새 구조로 이동해 있음. 나머지는 3개월 후 대량 이전 세션 진행.
4. 대량 이전 세션에서는 옮길 것과 아카이브할 것, 삭제할 것을 결정. 3년 전 만든 노트 중 다시 참조된 적 없는 것은 대부분 삭제해도 무방.
이 방식이 한 번에 모든 노트를 재분류하는 것보다 부담이 적었습니다. 실제 사용 패턴에 따라 자연스럽게 정리되었습니다.
3년 사용 후 배운 것
이 재정비를 하면서 가장 크게 느낀 것은 “구조는 사용 패턴을 반영해야 한다”는 원칙입니다. 개념적으로 아름다운 구조가 실제 사용에는 마찰을 만들 수 있고, 반대로 약간 어수선해 보이는 구조가 실제 워크플로우에는 잘 맞을 수 있습니다.
다른 배운 것: 노트 관리 시스템은 만들고 끝나는 것이 아니라 계속 진화하는 것. 3년마다는 아니어도 1-2년에 한 번씩 구조를 재검토하고 조정하는 시간을 갖는 것이 유용합니다.
그리고 마지막으로, Obsidian이든 다른 앱이든 노트 관리에 과도한 시간을 쓰지 말 것. 노트를 관리하는 것이 목표가 아니라 그 노트가 편집 활동을 지원하는 것이 목표. 이 균형을 잃지 않는 것이 장기적으로 중요합니다.