옵시디언을 쓰면서 한동안 속성(Properties)을 꽤 많이 만들었다. 노트의 종류, 상태, 신뢰도, 분야까지 적어두면 나중에 무엇이든 골라낼 수 있을 것 같았다. 태그도 비슷했다. 관련 있어 보이는 단어는 일단 붙였다.
그런데 노트가 늘어나자 반대의 일이 생겼다. 같은 사실을 폴더와 속성에 두 번 적었고, 태그와 링크는 서로 같은 대상을 가리켰다. 기준이 조금만 바뀌어도 여러 곳을 함께 고쳐야 했다. 결국 분류는 많아졌는데 다시 찾기는 더 어려워졌다.
지금은 같은 YAML 안에 보이는 속성과 태그도 서로 다른 층으로 나눈다.
- Properties는 기계가 읽고 정렬·필터할 최소한의 구조를 담는다.
- tags는 여러 맥락을 가로지르며 다시 찾을 주제를 표시한다.
내가 세운 규칙의 출발점은 단순하다. 한 사실은 한 곳에만 적는다.
앞의 공간축 글이 파일의 자리를 정한다면, 여기서는 그 파일 위에 어떤 구조 정보와 주제 정보를 남길지 다룬다. 위키링크와 MOC가 담당하는 관계와 읽기 경로는 다음 글로 분리했다.
블로그의 다른 글 내 라이프사이클에 맞는 노트 시스템을 찾는 과정여러 노트테이킹 방법을 써 보며 겪은 실패와, 옵시디언에서 계속 쓰기 위해 세운 기준을 정리했다.Properties는 노트를 설명하는 설문지가 아니다
처음에는 속성이 많을수록 노트를 잘 설명한다고 생각했다. type, status, confidence, domain 같은 값을 만들었다. 문제는 설명을 잘하는 것과 실제로 다시 쓰는 것이 다르다는 데 있었다.
예를 들어 노트 종류를 type: source라고 적으면서 파일도 sources/에 둔다면 같은 사실이 두 곳에 있다. 처음에는 일치하더라도 언젠가는 한쪽만 바뀐다. 실제로 속성값이 비거나 폴더와 어긋난 노트가 쌓였다. 아무도 그 값으로 목록을 만들지 않는다면 관리 비용만 남는다.
그래서 지금 기본 Properties는 네 개만 쓴다.
---
created: 2026-09-01
tags: []
sources:
- https://example.com/
aliases:
- 다른 이름
---
created와 tags는 필수다. sources와 aliases는 필요할 때만 쓴다. 값이 없다면 빈 배열까지 남기지 않는다. 예외적으로 더는 고치지 않지만 관심 영역의 탐색·회고 경로로 남길 atlas/ MOC에만 state: archived를 쓴다.
속성은 프론트매터 YAML에만 쓴다. 인라인 key:: value는 쓰지 않는다. 같은 property 이름은 볼트 전체에서 같은 타입을 유지하고, tags는 언제나 배열로 적는다. 타입이 섞이면 Bases의 필터부터 어긋나기 때문이다.
여기서 중요한 것은 개수가 아니라 성격이다. Properties에는 정렬하거나 필터할 때 실제로 쓸 값만 둔다. 원문의 제목과 저자처럼 본문에서 읽는 편이 자연스러운 정보, 확신이 낮다는 판단, 프로젝트의 다음 행동까지 모두 YAML에 올리지 않는다. 시간축의 점·선분·반직선도 사고를 위한 비유이지 저장할 type이나 status가 아니다. 속성은 노트의 모든 특징을 요약하는 설문지가 아니라, 반복해서 계산할 작은 스키마다.
tags는 여러 노트를 가로지르는 주제다
태그는 “이 노트를 어느 주제로 다시 찾을까?”에만 답한다. 내 규칙은 다음과 같다.
- 0~3개만 쓴다.
- 소문자 영문 kebab-case를 쓴다.
- 계층 태그는 만들지 않는다.
- 폴더명, 노트 종류, 상태를 복제하지 않는다.
- 본문에
#해시태그를 쓰지 않는다. - 적어도 세 노트를 같은 이유로 다시 찾을 때만 새 태그를 만든다.
가장 자주 걸리는 기준은 그 노트가 정말 그 태그에 관한가라는 질문이다. Kubernetes 배포 중 장애를 다룬 노트라면 reliability는 주제가 될 수 있다. 하지만 그 글에 개발 도구가 등장했다는 이유만으로 dev까지 붙이면 태그의 범위가 끝없이 넓어진다.
고유명사도 태그로 만들지 않는다. #aws, #node-js, #kubernetes처럼 대상의 이름을 태그에 넣으면 그 대상이 어떤 관계로 등장했는지 알 수 없다. 그런 이름은 [[AWS]], [[Node.js]], [[Kubernetes]]처럼 링크한다.
태그가 YAML의 Properties 안에 보인다는 점은 조금 헷갈린다. 저장 형식으로 보면 tags도 하나의 property다. 하지만 운영 역할은 다르다. created가 구조적 사실이라면 tags는 다중 소속을 표현하는 주제 필터다. 같은 화면에 있다고 같은 질문에 답하는 것은 아니다.
태그에는 분명한 한계도 있다. 태그 하나에는 그 태그를 붙인 이유나 설명을 담기 어렵고, 태그가 많아질수록 붙이는 일과 태그로 다시 찾는 일이 모두 어려워진다. 태그와 태그 사이의 관계도 태그만으로는 문장처럼 남길 수 없다.
태그와 위키링크는 서로 대체하지 않는다
같은 횡단 주제로 결과를 모으는 일은 태그가 잘한다. 반면 사람·조직·제품·기술·사건처럼 반복해서 참조할 대상, 또는 두 생각 사이의 구체적인 관계는 위키링크가 맡는다. 같은 주제라는 이유만으로 모든 노트를 서로 링크하지 않고, 의미 관계가 없는데도 고유명사를 태그로 만들지 않는다.
그러므로 “태그보다 위키링크가 낫다”가 결론은 아니다. 태그는 횡단 주제, 위키링크는 의미 관계다. 위키링크를 문장 안에 남기고 MOC로 읽는 순서를 만드는 방법은 위키링크와 MOC 글에서 이어서 다룬다.
그럼 이 정보는 어디에 적을까
정보를 어디에 적을지 고를 때는 아래 순서로 생각한다.
저장 형식보다 나중에 어떤 질문으로 다시 찾을지를 먼저 정한다.
예를 들어 Kubernetes에서 Node가 중단된 사건을 정리한다고 해보자.
| 기록할 정보 | 사용할 수단 | 이유 |
|---|---|---|
| 노트를 만든 날짜 | created property | 날짜로 정렬하고 필터할 구조적 사실이다 |
| 참고한 문서 URL | sources property | 근거 자료를 모으는 정해진 필드다 |
reliability, security | tags | 다른 시스템과 프로젝트에도 걸쳐 다시 찾을 주제다 |
[[Kubernetes]], [[Node.js]] | wikilink | 이름 있는 대상이며 문장 안에서 관계를 설명할 수 있다 |
| 무엇이 잘못됐고 다음에는 어떻게 할지 | 본문 | 자연어로 읽고 판단해야 하는 내용이다 |
이렇게 나누면 하나의 정보가 두 군데에 들어가지 않는다. 주제가 추가됐다고 파일을 옮길 필요도 없고, 새로운 대상을 만났다고 태그 어휘를 늘릴 필요도 없다.
분류가 필요해 보일 때 먼저 의심한다
새 property나 태그를 만들고 싶을 때는 기능보다 갱신 비용을 먼저 생각한다.
기존 정보에서 계산할 수 있는가. 값의 경계가 명확한가. 앞으로도 내가 실제로 고칠 이유가 있는가. 세 질문 중 하나라도 답하기 어렵다면 새 필드를 만들지 않는다. 검색이나 Bases의 조건식으로 계산할 수 있는 것은 저장하지 않는 편이 낫다.
태그도 마찬가지다. 같은 태그가 30개를 넘으면 태그를 더 잘게 쪼개지 않고 MOC를 만든다. 필터 결과가 많아서 읽는 순서를 잃은 문제라면 분류보다 안내가 더 필요하기 때문이다. 태그는 무엇을 모을지 정하고, MOC는 무엇부터 읽을지 안내한다.
이 규칙은 옵시디언 기능을 적게 쓰자는 이야기가 아니다. 서로 다른 기능이 같은 일을 하지 않게 하자는 이야기다. Properties는 구조, tags는 주제를 맡긴다. 원문·당시 기록·계속 고칠 생각을 실제 폴더에서 나누는 기준은 sources, log, wikilink 글에서 이어서 정리했다. 하나의 도구가 하나의 질문에만 답하면 규칙도 짧아지고, 어긋날 곳도 줄어든다.
결국 노트 시스템은 분류를 잘했다는 만족감을 주기보다 시간을 돌려줘야 한다. 기록할 때 덜 망설이고, 다시 찾을 때 이유를 이해하고, 고칠 곳이 하나만 남는 것. 지금의 나는 그 정도면 충분하다고 생각한다.