온톨로지 핵심 개념 빠르게 잡기
개체(Entity): "세상에 있다고 말할 수 있는 것"의 단위
예: 프로젝트 A, 회의, 책 한 권, 사람 한 명, 도구(Obsidian)
속성(Attribute): 개체가 "어떤 상태/값을 가지는지"
예: 프로젝트의 상태=진행중, 마감일=2026-03-20
관계(Relation): 개체와 개체 사이의 "연결의 의미"
예: 프로젝트 A --(사용함)→ Obsidian, 업무 X --(속함)→ 프로젝트 A
클래스(Class): 개체를 묶는 "타입/범주"
예: Project, Task, Tool, Person
인스턴스(Instance): 클래스에 속하는 "구체 1개"
예: Project(클래스) ↔ "프로젝트 A"(인스턴스)
택소노미 vs 온톨로지
택소노미: "분류(상하 구조)" 중심(폴더 트리 같은 느낌). 예: 도구 > 노트앱 > Obsidian
온톨로지: "분류 + 관계(다양한 연결)"까지 포함. 예: Obsidian은 "노트앱"이면서 "프로젝트 A에서 사용되고", "업무 X의 산출물 저장소로 쓰이고", "플러그인 Y에 의존"한다
왜 온톨로지 관점이 옵시디언에 유용한가
링크 중심의 그래프는 "분류"보다 "관계"를 잘 담아 지식이 커질수록 탐색이 쉬워진다
노트가 늘어도 "어디에 둘지(폴더)" 고민보다 "무엇과 연결할지(관계)"로 설계가 단순해진다
검색은 단어 찾기라면, 온톨로지는 "의미 있는 경로"를 만든다(프로젝트→업무→도구→문서로 타고 이동)
Dataview/쿼리 기반 정리는 "속성+관계"가 있어야 자동화가 된다(진행중 업무만 모으기, 특정 도구를 쓰는 프로젝트만 보기)
옵시디언 요소를 온톨로지에 매핑하기(링크·태그·폴더)
노트(파일) = 개체(또는 관계를 설명하는 노트)
"프로젝트 A.md", "업무-회의 준비.md", "Obsidian.md"
링크
[[노트]]= 관계의 존재(연결선)링크만 걸면 "연결은 있다"까지는 표현되지만, "무슨 관계인지"가 약해질 수 있다
태그
#...= 보조 분류/상태 플래그(가벼운 속성)추천 용도: 상태/흐름성 메타(#inbox, #wip, #done), 성격 표시(#idea, #reference)
비추천 용도: 주제 전체를 태그로 다 덮기(태그가 사실상 폴더 트리로 변함)
폴더 = 보관/권한/수명주기 같은 "운영상의 경계"
추천 예:
_templates/,00-inbox/,99-archive/,attachments/핵심 지식 구조를 폴더로만 만들면 택소노미에 갇히기 쉬움
속성은 템플릿 + YAML 프론트매터로 관리하기(예시)
원칙
클래스별로 "필수 속성"을 정해 템플릿에 박아 넣기
속성명은 짧고 일관되게(예:
status,due,owner,uses,partOf)링크로 표현 가능한 값은 링크로(사람/도구/프로젝트는
[[...]])
Project 템플릿 예시
---
type: Project
status: active # active | paused | done
start: 2026-03-01
due: 2026-03-20
owner: [[홍길동]]
uses:
- [[Obsidian]]
- [[GitHub]]
outputs:
- [[프로젝트 A - 결과물]]
---Task 템플릿 예시
---
type: Task
status: todo # todo | doing | done
due: 2026-03-15
partOf: [[프로젝트 A]]
relatedTools:
- [[Obsidian]]
dependsOn:
- [[업무 - 요구사항 정리]]
---Tool 템플릿 예시
---
type: Tool
category: note-taking
vendor: Obsidian
platform:
- mac
- windows
---관계 타입을 "보이게" 만드는 링크 문법/규칙
최소 규칙(가장 실무적)
링크는 항상 "문장"으로 감싸서 관계를 드러낸다
예: "이 업무는 [[프로젝트 A]]에 속한다."
예: "[[Obsidian]]으로 회의록을 작성한다."
관계를 더 명확히 하는 3가지 패턴(상황별로 하나만 골라 일관되게)
패턴 A: 본문 문장 + YAML 속성 병행(추천: 균형형)
YAML은 쿼리/자동화용, 본문은 맥락/의도 기록용
패턴 B: 관계 노트(관계 자체가 중요한 경우)
예: "프로젝트 A ↔ Obsidian 활용 전략" 같은 노트를 만들어 배경, 기준, 예외를 적는다
관계가 자주 바뀌거나 논쟁적일 때(정의/근거/버전) 특히 유용
패턴 C: 엣지(Edge) 노트(관계가 '객체'처럼 다뤄져야 할 때)
예: 회의(이벤트), 계약(법적 관계), 의존성(버전/조건)처럼 관계에 날짜/조건/책임자가 붙을 때
파일명 예:
rel - 프로젝트 A - uses - Obsidian.md구성 예: "누가/언제/왜 이 도구를 채택했는지", "대안", "전환 조건" 등
Dataview를 쓰는 경우(선택) - 간단 쿼리 예시
진행 중 프로젝트 모아보기
TABLE status, due, owner
FROM ""
WHERE type = "Project" AND status = "active"
SORT due ASC특정 프로젝트에 속한 업무만 보기
TABLE status, due, dependsOn
FROM ""
WHERE type = "Task" AND partOf = [[프로젝트 A]]
SORT due ASCObsidian을 쓰는 프로젝트 찾기(YAML의 uses 기반)
TABLE status, due
FROM ""
WHERE type = "Project" AND contains(uses, [[Obsidian]])
SORT due ASC작은 예시 도메인: '프로젝트-업무-도구' 샘플 구조
폴더(운영용 경계만)
00-inbox/임시 메모10-entities/핵심 개체 노트(프로젝트/업무/도구/사람)20-relationships/관계 노트(선택)_templates/템플릿
핵심 노트 예시
10-entities/프로젝트 A.mdYAML:
type: Project,uses: [[Obsidian]]본문: 목표/범위/결정사항, "어떤 업무가 왜 포함되는지"
링크:
[[업무 - 회의 준비]],[[업무 - 요구사항 정리]]
10-entities/업무 - 회의 준비.mdYAML:
type: Task,partOf: [[프로젝트 A]]본문: "이 업무는 [[프로젝트 A]]의 착수 회의를 위해 필요하다."
링크:
[[회의록 - 2026-03-13]],[[Obsidian]]
10-entities/Obsidian.mdYAML:
type: Tool본문: 사용 규칙(템플릿, 링크 규칙), 플러그인, 주의점
링크: "[[프로젝트 A]]에서 표준 노트 도구로 사용한다."
(선택)
20-relationships/프로젝트 A - uses - Obsidian.md채택 이유, 대안, 운영 규칙, 전환 조건, 예외 처리
시작 체크리스트(3~7단계)
내 도메인 클래스 3~5개만 정한다(예: Project/Task/Tool/Person)
클래스별 필수 속성 3~7개를 정하고 YAML 템플릿을 만든다
폴더는 운영용 최소만 두고, 지식 구조는 링크로 만든다
링크는 문장으로 써서 관계 타입이 드러나게 한다
"자주 묻는 질문"을 Dataview 쿼리 2~3개로 고정해 둔다(진행중, 마감임박, 프로젝트별 업무)
관계가 복잡해지는 지점부터 관계 노트/엣지 노트를 도입한다
흔한 실수(피하기)
태그를 주제 전체에 남발해서, 태그가 두 번째 폴더 트리가 되는 경우
폴더 구조에 집착해 "어디에 둘지"만 고민하고 "무엇과 어떤 관계인지"를 안 쓰는 경우
링크는 많은데 관계 타입(왜 연결되는지)이 본문에 남지 않아 나중에 의미가 사라지는 경우
YAML 속성명이 매번 바뀌어 쿼리/자동화가 깨지는 경우(예:
dueDate,deadline,due혼용)프로젝트/업무/도구 노트는 많은데, 정작 "결정의 근거/예외/조건"이 관계 노트로 남지 않는 경우
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.