⑤ 지식·업무 시스템 · 선택
폴더·태그·링크·속성 — 무엇을 기준으로 삼나
정리 도구가 네 가지나 있어서 오히려 결정을 못 한다. 공식 문서를 확인해 각자의 자리를 정리했다 — 다만 아직 이 기준으로 직접 운영해본 적은 없고, 그래서 단정하지 않는다.
노트가 쌓이기만 하고 다시 안 쓰이는 이유를 찾다 보면 대개 같은 자리에서 막힌다. 폴더로 나눌지, 태그를 붙일지, 링크로 이을지, 속성을 쓸지 정하지 못해 매번 다시 정리하는 것이다. 도구가 부족해서가 아니라 네 가지가 다 있어서 생기는 문제다.
이 글은 넷 중 하나를 고르라는 글이 아니다. 각자 다른 질문에 답하는 도구라서, 질문을 먼저 정하면 자리가 정해진다.
읽기 전에 한 번 골라보기
노트 속성에 「분야: #백엔드」 라고 쓰고, 다른 노트 본문에는 「#백엔드」 라고 썼다. 둘은 같은 태그로 묶일까?
일반 속성 안의 해시태그는 태그가 아니다
공식 문서에 명시돼 있다 — tags 는 Obsidian 의 기본 제공 속성이고, Tags 타입은 그 tags 속성에만 쓰는 특수 타입이다. 일반 텍스트 속성 안에 해시태그를 써도 태그가 생기지 않는다. 태그로 묶으려면 값을 tags 속성에 넣어야 한다. 속성 이름을 자유롭게 정할 수 있다는 점 때문에 여기서 어긋나기 쉽다.
넷은 서로 다른 층에 있다
공식 문서에서 확인한 것만 정리하면 이렇다.
| 무엇인가 | 개수 | 나중에 바꾸기 | 기계가 읽기 | |
|---|---|---|---|---|
| 폴더 | 파일 시스템 위치 | 노트당 하나 | 옮기면 경로가 바뀐다 | 경로로만 |
| 링크 | 노트 사이의 관계. [[노트 이름]] |
제한 없음 | 이름을 바꾸면 링크를 자동 갱신하는 옵션이 있다 | 관계 그래프 |
| 태그 | tags 속성의 특수 타입 |
여러 개 | 값만 고치면 됨 | 목록으로 |
| 속성 | YAML frontmatter 의 이름: 값 |
여러 개, 타입 있음 | 값·타입 변경 가능 | 구조화된 값으로 |
속성이 지원하는 타입은 일곱 가지다 — 텍스트, 목록, 숫자, 체크박스, 날짜, 날짜와 시간, 그리고 태그. 속성에는 자체 검색 문법이 있고, 템플릿을 삽입하면 그 템플릿의 속성이 노트에 함께 들어온다.
---
type: project
status: doing
due: 2026-08-15
tags:
- fieldwork
- obsidian
---
# 트랙 ⑤ 첫 글 쓰기
관련: [[Fieldwork 제품 정의]] · [[Obsidian 속성 실험]]여기서 type·status·due 는 값이 정해진 어휘이고, tags 는 느슨한 주제어이고, [[...]] 는 관계다. 같은 노트 안에서 세 층이 각자 할 일을 한다.
링크에는 두 가지 성질이 더 있다. 아직 없는 노트로도 링크를 걸 수 있고, 그 링크를 누르면 해당 경로에 노트가 만들어진다. 그리고 헤딩이나 블록 단위로도 가리킬 수 있다 — [[노트#헤딩]], [[노트#^블록id]].
그래서 어디에 넣나
이 정보를 어디에 넣을까
이건 다른 노트와의 관계인가?
나중에 이 값으로 노트를 골라내거나 정렬할 건가?
값이 정해진 어휘인가? (상태·유형·날짜처럼)
링크로 잇는다
아직 없는 노트로도 걸어둘 수 있고, 누르면 그 자리에 만들어진다. 헤딩·블록까지 가리킬 수 있으니 "어디를 참조했는지"까지 남긴다. 이름을 바꿀 계획이라면 링크 자동 갱신 옵션을 켜둔다.
속성에 넣는다
타입이 있는 값(날짜·숫자·체크박스·정해진 텍스트)은 속성이 맞다. Bases 로 표·리스트·카드 뷰를 만들 수 있어서, 나중에 "진행 중인 프로젝트만" 같은 목록이 자동으로 나온다.
태그로 붙인다
어휘가 아직 굳지 않은 주제어에 맞다. 단 tags 속성에 넣어야 태그가 된다 — 이름을 직접 만든 텍스트 속성 안의 해시태그는 태그로 잡히지 않는다.
폴더면 충분하다
골라낼 일이 없다면 굳이 태그·속성을 붙이지 않는다. 노트당 폴더는 하나뿐이라 분류 기준이 늘어나면 곧 막히지만, 그때 속성으로 옮기면 된다. 미리 다 붙여두는 게 재정리를 부른다.
마지막 결론이 이 글에서 제일 하고 싶은 말이다. 넷을 다 쓰지 않아도 된다. 쓰지 않기로 정하는 것도 구조다. 노트가 쌓이기만 하는 이유 중 하나는 아마 처음부터 완벽한 분류를 만들려다 매번 다시 정리하기 때문일 것이다 — 이건 추측이고, 아래에 적은 대로 아직 확인하지 못했다.
속성을 쓰면 뷰가 따라온다
속성에 값을 넣어두면 Bases 로 데이터베이스 같은 뷰를 만들 수 있다. 정식 코어 플러그인이고, .base 파일로 저장하거나 마크다운 문서 안 코드블록으로 끼워 넣는다. 속성으로 파일을 보고·편집·정렬·필터하며, 뷰는 네 가지다 — 표, 리스트, 카드, 지도.
이게 속성과 태그를 가르는 실용적인 이유다. 태그는 모아 보는 것까지이고, 속성은 조건을 걸어 목록을 만드는 것까지 간다. “이번 주 마감인 프로젝트 노트”를 원하면 due 는 태그가 아니라 날짜 속성이어야 한다.
아직 해보지 않은 것
이 글은 공식 문서를 확인해 정리한 것이고, 이 기준으로 Vault 를 실제로 운영해본 적은 없다. 그래서 다음은 알 수 없다.
- 속성 이름을 어디까지 통일해야 실제로 쓸모가 있는지
- 태그를 몇 개까지 두면 관리가 무너지는지
- Canvas 가 어떤 상황에서 표·리스트보다 나은지 (기능 확인만 했고 써보지 않았다)
- 노트 유형(수집·생각·프로젝트·레퍼런스)을 폴더로 나누는 게 나은지 속성으로 두는 게 나은지
이 판단들은 프로젝트 하나를 이 구조로 끝내봐야 나온다. 출발점은 정해뒀다 — 이 사이트를 만드는 작업 자체를 Vault 에서 관리해보는 것. 목적 없이 노트 앱을 익히는 것과 달리, 굴러가는 프로젝트가 붙어 있으면 무엇이 부족한지 바로 드러난다. 그 결과를 이 문서에 덧붙이고 근거를 올린다.
이 문서를 덮어도 되는 시점
지금 정리하려는 정보 하나를 위 세 질문에 통과시켜 자리를 정했고, 그중 “쓰지 않기로 한 것”이 하나라도 있으면 된다. 완벽한 분류 체계를 세우는 건 이 글의 목표가 아니다.
- 초안 작성(근거: 조사·정리). 공식 문서로 속성 7타입·tags 특수 타입·Bases·링크 성질 확인. 네 층 비교표와 선택 트리 정리. 실사용 경험 없음을 명시 (성숙도: 탐색 중)
- 이 사이트 작업을 Vault 에서 관리해본 뒤 — 속성 이름 통일 범위, 태그 한계, 노트 유형 분류 방식의 실제 결과를 덧붙이고 근거를 practiced 로 올린다