# 옵시디언 메타데이터(Obsidian Metadata) 완벽 가이드 Obsidian에서 **메타데이터(Metadata)**란 각 노트에 부가적인 정보를 첨부하는 방법을 말합니다. 이를 통해 노트의 내용 외에도 분류, 태그, 상태 등 **데이터에 대한 데이터**를 기록할 수 있습니다. Obsidian은 일반적으로 YAML 형식의 **프론트매터(frontmatter)** 블록을 사용하여 메타데이터를 지정합니다[1](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fn-1). 메타데이터는 노트 상단의 `---`로 구분된 영역에 **키-값 구조(key-value structure)**로 작성되며, Obsidian과 플러그인들이 이 정보를 활용해 노트를 필터링하거나 특수 기능을 수행할 수 있습니다[2](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fn-2). ## 1. Obsidian의 메타데이터란? (YAML 프론트매터 등) **YAML 프론트매터(YAML frontmatter)**는 노트 맨 앞부분에 위치하는 메타데이터 블록입니다. YAML은 들여쓰기와 하이픈 등을 활용하는 인간 친화적인 데이터 포맷으로, Obsidian에서는 노트의 속성정보를 기록하는 데 사용됩니다. 프론트매터 블록은 반드시 노트의 **첫 줄부터** 시작해야 하며, 시작과 끝을 세 개의 하이픈(`---`)으로 구분합니다[1](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fn-1). 그 안에 `키: 값` 형태로 원하는 속성을 정의하면 해당 노트의 메타데이터로 인식됩니다. 예를 들면 다음과 같습니다: ```yaml --- title: 메타데이터의 활용 # 노트 제목 (filename과 다를 경우) tags: [지식관리, 메타데이터] # 태그 목록 category: 생산성 # 분류 or 카테고리 status: 진행중 # 현재 상태 (예: 아이디어, 진행중, 완료) date: 2025-03-25 # 작성 또는 사건 발생 날짜 --- ``` 위 예시에서 `title`, `tags`, `category`, `status`, `date`는 **키(key)**이고 각 줄의 콜론(`:`) 이후는 해당 **값(value)**입니다. 값은 문자열, 숫자, 불리언(boolean), 날짜 형식 등 다양하게 넣을 수 있습니다. 여러 값을 갖는 키(예: 태그)는 대괄호 `[ ]`로 감싸 **리스트(list)** 형태로 작성합니다. 프론트매터에 작성한 태그는 노트 내용에 `#태그`를 직접 넣는 것과 동일하게 취급되어 Obsidian **태그 페이지(Tag Pane)**나 검색에서 인식됩니다. 프론트매터 블록은 기본적으로 미리보기 모드에서 숨겨져 노트 본문을 방해하지 않으며[2](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fn-2), 편집 모드에서만 확인할 수 있습니다. (Obsidian v1.4 기준으로 **Properties(속성)** 창을 통해 UI로도 편집 가능해졌습니다.) **참고:** Obsidian에서 YAML 프론트매터로 메타데이터를 지정하는 것은 선택 사항이지만, 일관된 지식 관리를 위해 많은 사용자가 이를 적극 활용합니다. YAML 키 이름은 일반적으로 영문을 사용하며(예: `tags`, `status` 등), 임의의 키도 정의할 수 있지만 일부 키워드는 특별한 기능을 가집니다. 예를 들어 `tags`(또는 `tag`)와 `aliases`(별칭)는 Obsidian이 인식하는 기본 메타데이터로, 별칭에 등록된 이름으로도 노트를 찾아 링크할 수 있습니다. 또 `cssclass`라는 키를 지정하면 노트별로 커스텀 CSS 스타일을 적용하는 등 특수 활용도 가능합니다. ## 2. Obsidian 메타데이터 vs. Notion 데이터베이스 구조 차이 메타데이터 활용에 있어 Obsidian과 Notion은 근본적인 구조 철학이 다릅니다. **노션(Notion)의 데이터베이스(DB)**는 테이블 형태로 체계화된 **스Chemema(스키마)**가 있는 구조입니다. Notion에서는 하나의 데이터베이스에 속한 모든 페이지가 동일한 속성 필드를 가지며(예: 이름, 태그, 날짜, 상태 등 컬럼이 고정됨), 각 페이지는 해당 데이터베이스의 레코드로 취급됩니다. 사용자는 노트를 작성하기 전에 어느 데이터베이스(또는 폴더)에 넣을지 결정하고, 미리 정의된 속성 값들을 채우는 방식입니다. 반면 **Obsidian의 메타데이터**는 훨씬 **유동적이고 자유로운 구조**입니다. Obsidian에서는 각 노트 파일 자체가 독립적인 문서이며, 필요한 메타데이터 키를 **필요한 순간에 정의**하면 됩니다. 모든 노트에 동일한 속성이 있을 필요가 없고, 새로운 속성이 필요하면 그때그때 YAML 프론트매터에 추가해 사용할 수 있습니다 (일종의 **아래로부터의(bottom-up)** 분류 방식). 이로 인해 몇 가지 차이점이 있습니다: - **구조 강제 vs 자율성:** Notion은 데이터베이스를 만들 때 속성(필드)를 미리 정의하고, 모든 항목이 그 구조를 따릅니다. Obsidian은 사전 정의된 스키마가 없으며, 메타데이터 필드는 전적으로 사용자에게 달려 있습니다. 예를 들어 어떤 노트에는 `author` 필드를 둘 수도 있고, 다른 노트에는 전혀 없을 수 있습니다. - **유연한 분류:** Obsidian에서는 태그나 메타데이터 키를 활용해 **한 노트를 여러 범주에 동시 분류**할 수 있습니다. Notion에서는 하나의 데이터베이스 내에서 필드를 통해 다중 분류도 가능하지만, 노트를 여러 데이터베이스에 동시에 속하게 할 수는 없습니다. Obsidian + Dataview 플러그인을 사용하면 **모든 노트를 하나의 통합 DB처럼** 다룰 수 있어, 특정 조건에 맞는 노트들의 뷰(리스트나 표)를 **수시로 생성**할 수 있습니다 ([Notion vs Obsidian // Databases vs Dataview | Video Summary and Q&A | Glasp](https://glasp.co/youtube/p/notion-vs-obsidian-databases-vs-dataview#:~:text=,the%20need%20for%20separate%20databases)) ([Notion vs Obsidian // Databases vs Dataview | Video Summary and Q&A | Glasp](https://glasp.co/youtube/p/notion-vs-obsidian-databases-vs-dataview#:~:text=Obsidian%20Dataview%20turns%20all%20notes,adaptability%20make%20it%20easier%20to)). Notion에서는 각 데이터베이스별로 정리된 뷰를 만들지만, 데이터베이스가 다르면 교차 참조가 번거롭습니다 ([Notion vs Obsidian // Databases vs Dataview | Video Summary and Q&A | Glasp](https://glasp.co/youtube/p/notion-vs-obsidian-databases-vs-dataview#:~:text=,the%20complexity%20of%20human%20thought)). - **속성 타입:** Notion은 각 필드 타입이 지정됩니다 (텍스트, 선택, 멀티선택, 날짜, 체크박스 등) 그리고 UI에서 해당 타입에 맞게 입력을 제한하고 도와줍니다. Obsidian 메타데이터의 값 타입은 엄격히 강제되진 않지만, Dataview 등에서 **값의 형태에 따라**(날짜 문자열은 날짜로, `[ ]`는 리스트로 등) 적절히 해석합니다. 타입 일관성 유지도 사용자 몫이라, 약속된 포맷을 지키는 것이 좋습니다. - **뷰와 활용:** Notion은 데이터베이스 항목을 **보드, 캘린더, 갤러리** 등 다양한 방식으로 시각화하고 관리할 수 있는 장점이 있습니다. Obsidian은 기본적으로 텍스트 편집기이므로 이러한 시각화는 **커뮤니티 플러그인**을 통해 보완합니다 (예: Dataview로 표/리스트, Calendar 플러그인으로 달력 뷰, Kanban 플러그인으로 보드 등). 다시 말해 Obsidian에서는 **메타데이터 + 플러그인 조합**으로 Notion의 데이터베이스 기능 상당수를 구현할 수 있지만, 즉시 눈앞에 보이는 데이터베이스 UI가 있는 것은 아닙니다. 대신 사용자의 **사고 흐름에 따라 자유롭게 메타데이터를 부여하고 사후적으로 구조화**할 수 있다는 장점이 있죠 ([Notion vs Obsidian // Databases vs Dataview | Video Summary and Q&A | Glasp](https://glasp.co/youtube/p/notion-vs-obsidian-databases-vs-dataview#:~:text=Obsidian%20takes%20a%20bottom,view%20information%20from%20different%20angles)). 정리하면, **Notion**은 처음부터 체계를 세워 넣는 **체계적(top-down)** 접근에 강하고, **Obsidian**은 일단 노트를 만들고 나중에 메타데이터로 엮는 **자유로운(bottom-up)** 접근에 강합니다. Obsidian에서 메타데이터와 Dataview 등을 활용하면 Notion의 데이터베이스처럼 구조화된 관리도 가능하지만, _강제되지 않는 구조_이므로 오히려 **사용자 정의 워크플로우** (예: CMDS 같은 자신만의 지식 흐름)에 맞춘 유연한 설계가 가능합니다. ## 3. 메타데이터 주요 키(Key)와 값(Value) 종류 (예시 포함) Obsidian 메타데이터로 활용되는 주요 키와 그 값의 유형을 살펴보겠습니다. 앞서 언급했듯 **키(key)** 이름은 자유롭게 정할 수 있지만, 관례적으로 많이 쓰이거나 Obsidian/플러그인이 특별히 인식하는 키들이 있습니다. 아래는 자주 사용되는 메타데이터 키들과 예시입니다: - **title(제목):** 노트의 제목을 명시적으로 지정할 때 사용합니다. 주로 파일명과 별도로 표시할 제목이 있을 때 씁니다. 예:`title: 매트릭스 영화 리뷰`. 이 키가 없으면 보통 파일명이 제목으로 간주됩니다. - **aliases(별칭):** 노트의 다른 이름들을 배열로 지정합니다. 이를 설정하면 [[링크]] 작성 시 별칭으로도 해당 노트를 인식할 수 있습니다. 예: `aliases: [매트릭스, The Matrix]`라 하면 두 용어로 모두 링크 가능. - **tags(태그):** 노트에 태그를 부여합니다. YAML에서는 보통 리스트로 작성하며, Obsidian은 여기에 적힌 단어들을 태그로 인식합니다. 예: `tags: [영화, 리뷰, SF]`. (`태그: [ ]`처럼 한글 키를 써도 되지만, 가능하면 영문 `tags`를 사용하는 것이 호환성에 유리합니다.) - **category(카테고리):** 노트의 분류를 나타내는 사용자 정의 필드입니다. 예: `category: 독서/경영서` 혹은 `category: 프로젝트`. 태그와 달리 하나의 주요 분류를 지정하거나 계층 구조를 나타낼 때 사용할 수 있습니다. (예: `category: 삶>건강>운동`) - **status(상태):** 해당 노트의 상태나 진행 단계 등을 표현합니다. 프로젝트나 글감의 진행도를 추적하기 위해 자주 쓰이는 키입니다. 예: `status: 아이디어` 또는 `status: 완료`. 사용자가 정의한 어떤 값도 가능하며, 추후 이 값을 기준으로 필터링하여 진행 상황을 관리할 수 있습니다. - **date(날짜):** 노트와 관련된 날짜를 기록합니다. 작성일이나 사건/소재의 일자를 넣을 수 있습니다. 예: `date: 2025-03-25`. 날짜 형식은 `YYYY-MM-DD`처럼 표준 형태가 좋으며, Dataview 플러그인은 이를 Date 타입으로 인식해 정렬하거나 날짜 계산에 활용할 수 있습니다. 이 밖에 **created(생성일)**, **updated(갱신일)** 같이 특정 의미를 지닌 날짜 키를 둘 수도 있습니다 (일부 플러그인은 이러한 키명을 자동 관리해주기도 함). - **참고용 키들:** 그 외에도 용도에 따라 무궁무진한 키를 둘 수 있습니다. 예를 들어 참고 자료 노트라면 `author: 저자명`, `source: URL`이나 `publication: 출판사` 등을 넣어 서지정보를 관리할 수 있고, 할 일 관리 노트라면 `due: 2025-04-01` (마감일), `priority: 높음` 같은 필드를 둘 수도 있습니다. **값(value)의 유형**은 YAML 문법에 따라 결정됩니다. 기본적으로는 문자열(텍스트)을 쓰면 되지만, 특수한 형식은 자동으로 인식됩니다: - `"true"/"false"` 혹은 `true/false` (따옴표 없이)로 쓰면 불리언 값으로 해석될 수 있습니다. - 숫자는 따옴표 없이 쓰면 정수/실수로 인식됩니다. 예: `progress: 75` (숫자). - 리스트는 `[` `]` 대괄호로 감싸고 콤마로 구분하거나, 다음 줄에 `-`로 시작하는 항목 목록으로 쓸 수도 있습니다. 예: ```yaml tags: - 일기 - 개인 ``` 는 `tags: [일기, 개인]`과 동일합니다. - 날짜도 따옴표 없이 `YYYY-MM-DD` 혹은 시간까지 `YYYY-MM-DD HH:mm`로 쓰면 대체로 인식됩니다. 만약 값에 콜론(`:`) 등 YAML에서 특별한 문자가 포함되면 전체를 `" "` 따옴표로 감싸야 파싱 오류를 피할 수 있습니다. (예: `time: "15:30 ~ 18:00"` 처럼) > **예시:** 사용자 A는 자신의 Obsidian vault에서 메모를 체계화하기 위해 아래와 같은 메타데이터 템플릿을 사용합니다. (여기서 CMDS 체계를 반영하여 필요한 키들을 포함) ```yaml --- index: "2023-001" # 노트 고유 번호 또는 식별자 title: 워크플로우 개선 아이디어 # 노트 제목 (파일명과 동일할 수도 있음) category: 업무/프로젝트 # 상위 분류 (폴더와 별개로 분류 체계 표현) tags: [생산성, 아이디어] # 주요 태그들 (토픽/주제 중심) status: "Connect" # 상태/단계: 현재는 연결(아이디어 수집) 단계 date: 2023-11-01 # 생성 또는 획득 날짜 author: 홍길동 # (예시) 작성자 or 출처 사람 이름 source: "http://example.com/article" # (예시) 참고한 외부 자료 링크 --- ``` 위 YAML 메타데이터 샘플을 해석해보면 다음과 같습니다: - `index` : 이 노트에 부여한 식별 코드입니다. 사용자는 노트를 생성한 순서대로 일련번호를 붙이고 있으며, `2023-001`은 2023년에 만든 첫 번째 노트를 의미합니다. 나중에 노트를 참조하거나 **파일 이름에 이 번호를 포함**해 정렬할 때 사용합니다. - `title` : 노트 제목을 명시적으로 작성했습니다. 파일명이 `2023-001 워크플로우 개선.md`일 수 있지만, 별도로 `title`을 두어 가독성 있는 제목을 부여한 것입니다. Dataview 등을 통해 노트를 목록화할 때 이 제목을 표시하도록 할 수 있습니다. - `category` : 이 노트가 속하는 카테고리를 _업무/프로젝트_로 지정했습니다. 사용자는 vault 내에 폴더로 업무 관련 노트를 관리하면서도, 메타데이터 `category` 필드를 추가로 사용해 보다 논리적인 분류(업무 vs 개인 등)를 병행하고 있습니다. 나중에 `category: 업무/프로젝트`인 노트들만 따로 모아볼 수 있겠죠. - `tags` : 노트의 주요 키워드 태그로 _생산성_, _아이디어_를 지정했습니다. 앞에 `#` 없이 작성했지만 Obsidian은 이를 태그로 인식합니다. 태그 패널이나 검색에서 해당 태그로 이 노트를 찾을 수 있고, Graph 뷰에서 태그 노드로 연결도 표시될 것입니다. - `status` : 이 노트의 현재 상태를 _Connect_ 단계로 표시했습니다. 사용자는 CMDS 흐름의 첫 단계(Connect: 지식 연결/수집 단계)에 있는 아이디어 메모임을 나타내기 위해 status 필드를 활용합니다. 이후 진행되면서 이 값을 Merge/Develop/Share 등으로 갱신할 것입니다. 이렇게 두면 나중에 status 값으로 필터링하여 어떤 단계의 노트들인지 한눈에 관리할 수 있습니다. - `date` : 노트를 만든 날짜(또는 아이디어를 얻은 날짜)를 기록했습니다. 이는 회고 시점이나 추후 노트를 정리할 때 연대순으로 살펴보는 데 유용합니다. Dataview로 특정 기간에 생성된 노트를 모은다거나 할 때 활용할 수 있습니다. - `author`와 `source` : 외부 자료를 참고한 경우 함께 기록해두는 임의의 속성입니다. 예를 들어 이 아이디어가 어떤 블로그 글에서 힌트를 얻었다면 그 글의 작성자와 URL을 남겨둔 것입니다. 훗날 출처를 찾거나 인용할 때 유용하며, 다른 노트들과 출처를 기준으로 연결짓는 것도 가능합니다. 이렇듯 **메타데이터 키**는 사용 목적에 따라 자유롭게 확장할 수 있습니다. 중요한 것은 **일관성(consistency)**인데, 같은 의미의 정보를 표현하는 키 이름을 통일하고 값의 형식을 규칙적으로 유지해야 나중에 검색이나 쿼리시 정확하게 필터링할 수 있습니다. 위 예시의 키들은 지식관리(CMDS) 맥락에서 자주 쓰일 만한 것들을 모두 넣어본 것이고, 필요에 따라 더 줄이거나 늘릴 수 있습니다. ## 4. 메타데이터 활용 예시 (검색 필터링, 태그 기반 연결, 상태 관리 등) 메타데이터를 잘 활용하면 Obsidian에서 노트들을 체계적으로 관리하고 필요한 정보를 빠르게 찾아낼 수 있습니다. 주요 활용 시나리오를 몇 가지 살펴보겠습니다. - **검색 필터링(Search Filtering):** 메타데이터를 활용한 강력한 기능 중 하나는 원하는 노트를 쉽고 빠르게 **필터링**하는 것입니다. 예를 들어, 특정 태그를 가진 노트만 검색하고 싶다면 Obsidian의 검색창에 `tag:생산성`처럼 입력하여 태그가 "생산성"인 모든 노트를 찾을 수 있습니다. 이때 YAML 프론트매터의 tags 필드에 지정한 태그도 동일하게 검색됩니다. 또 다른 예로, 메타데이터에 `status: 완료`라고 적힌 노트만 골라보고 싶다면, 기본 검색으로는 `status: 완료` 텍스트를 포함한 노트를 찾게 되지만, 더 나은 방법은 **Dataview** 플러그인을 사용하는 것입니다 (자세한 설명은 뒤 섹션 참조). Dataview를 쓰면 `WHERE status = "완료"` 같은 쿼리로 특정 메타데이터 값을 가진 노트를 걸러낼 수 있습니다. 이를 통해 수백 개 노트 중에서도 원하는 조건(특정 카테고리, 날짜 범위, 커스텀 필드 값 등)에 맞는 노트를 몇 초 내 추려낼 수 있습니다. 복잡한 조건도 조합 가능하며, 예를 들어 "2022년 이후 생성되었고 status가 Develop이며 tag에 '프로젝트'가 포함된 노트"처럼 세부 필터링도 구현할 수 있습니다. **즉, 메타데이터는 노트 검색을 위한 풍부한 **인덱스(index)** 역할을 합니다.** - **태그 기반 연결(Tag-based Connections):** 태그는 Obsidian에서 노트를 서로 연결하는 가장 간단한 메타데이터입니다. 메모들에 공통된 태그를 달아두면, 해당 태그를 클릭했을 때 관련된 모든 노트를 한꺼번에 볼 수 있어 일종의 **주제별 모아보기**가 됩니다. 예를 들어 `#AI` 태그가 붙은 논문 정리 노트 10개가 있다면, 그 중 하나를 보고 있을 때 태그를 클릭해서 다른 9개를 쉽게 찾아볼 수 있습니다. Graph 뷰에서 태그를 노드로 표시하도록 설정하면, `#AI` 태그가 **노드**로 나타나고 그것을 공유하는 노트들이 태그 노드에 서로 연결되어 시각화됩니다. 이를 통해 특정 주제나 속성으로 묶인 지식의 **맥락(context)**을 파악하기 쉽습니다. 또한 Obsidian은 태그에 계층을 부여할 수 있습니다 (예: `#개인/건강`, `#개인/재정`처럼 슬래시(`/`)로 구분). 이런 **네임스페이스 태그** 체계는 메타데이터를 더 체계적으로 만드는 방법입니다. `tags: [개인/건강/운동]`처럼 계층 태그를 달면, 큰 범주(개인), 하위 범주(건강), 세부(운동)까지 한 번에 표현 가능하고, 상위 태그만 검색하면 하위 태그를 모두 포함하는 식으로 활용할 수도 있습니다. 태그 기반 연결의 장점은 **빠른 연결**과 **자유로운 그룹화**입니다. 파일을 여러 폴더에 복사해 둘 수는 없지만, 태그를 통해서는 하나의 노트를 여러 그룹에 속하게 하는 효과를 얻습니다. 특히 Zettelkasten 등에서는 태그를 통해 **토픽별 느슨한 연결**을 만들고, MOC(Map of Content) 노트 등을 통해 태그별로 노트 목록을 정리하기도 합니다. YAML의 tags 필드에 태그를 모아서 넣어두면 본문에 태그를 일일이 적지 않고도 메타데이터로 관리할 수 있다는 이점도 있습니다. - **상태 관리(Status Management) 및 워크플로우 추적:** 메타데이터를 이용하면 각 노트의 진행 상태나 분류 상태를 관리할 수 있습니다. 예를 들어 위에서 소개한 `status` 키를 적극 활용한다고 합시다. 사용자 B는 아이디어 메모에는 `status: 아이디어`, 진행 중인 원고에는 `status: 작성중`, 다 쓴 글에는 `status: 완료` 등을 태깅해 둡니다. 그리고 Dataview를 이용해 대시보드 노트를 하나 만들고, 거기에 "📌 **진행 중인 글 목록**"이라는 섹션을 추가하여 `TABLE title, category, date WHERE status = "작성중"` 이런 쿼리를 적어둡니다. 그러면 vault 내 모든 노트를 훑어 `status` 값이 "작성중"인 노트들만 표로 정리해 보여줍니다. 이 목록을 보면서 현재 작성중인 것이 몇 개인지, 가장 최근에 시작한 것이 무엇인지 등을 한눈에 파악할 수 있습니다. 마찬가지로 `status: 아이디어` 단계의 노트들을 모아 인큐베이팅 중인 아이디어 함으로 보거나, `status: 완료`인 것들만 모아 아카이브된 글 목록을 만들 수도 있습니다. Obsidian **Tasks** 플러그인이나 **Kanban** 보드 플러그인과도 연계하면, 메타데이터의 상태값에 따라 자동으로 To-Do 리스트를 생성하거나 칸반보드 컬럼으로 분류해주는 활용도 가능합니다. 이렇듯 메타데이터는 노트 하나하나의 상태를 넘어, 노트들의 집합을 **프로세스 관점에서 관리**할 수 있게 합니다. 특히 개인 지식관리(PKM)나 프로젝트 관리에서 "현재 무엇이 어느 단계에 있는가?"를 파악하는 데 큰 도움이 됩니다. - **연결 강화 및 맥락 부여:** 메타데이터는 노트 간의 관계를 풍부하게 만들어줍니다. 예를 들어 노트 A의 프론트매터에 `related: [노트B, 노트C]` 같은 식으로 관련 노트를 명시하는 필드를 둘 수 있습니다. 물론 Obsidian에서는 본문 내 [[링크]]만으로도 충분히 연결할 수 있지만, 별도의 메타데이터 필드에 관련 항목들을 모아두면 플러그인을 통해 그 정보를 특수 표시하거나 활용할 수 있습니다. 일부 사용자는 참고문헌 관리하듯이 `references` 필드를 만들어 그 노트가 참고하고 있는 문헌 리스트를 넣기도 하고, `parents`나 `children` 필드를 써서 노트 간 위계나 트리 구조를 명시하기도 합니다. 이런 메타데이터는 일종의 **명시적 연결(explicit connection)**로서, 콘텐츠 안에서 자연스럽게 드러나지 않는 추가 관계 정보를 담습니다. 나아가, Supercharged Links 같은 플러그인을 쓰면 이 메타데이터를 기반으로 노트 링크 옆에 아이콘을 달거나 색상을 바꿔서 **맥락 표시**를 할 수 있습니다 (예: 미팅 노트는 링크에 📅 아이콘 표시, 사람 노트는 👤 아이콘 표시 등). - **노트 템플릿 및 자동화 활용:** 메타데이터는 새로운 노트를 만들 때 일괄적으로 넣어야 하는 공통 정보(예: 작성자, 분류, 템플릿별 고정 태그 등)를 미리 채워넣는 용도로도 쓰입니다. Templater 같은 플러그인을 이용하면 새 노트 생성 시점에 자동으로 프론트매터 블록을 삽입하고, 오늘 날짜나 주차, 사용자 이름 등을 값으로 넣어줄 수 있습니다. 예를 들어 회의록 템플릿에 `category: 회의`, `tags: [프로젝트X, 회의록]`, `date: <% tp.date.now("YYYY-MM-DD") %>` 등을 미리 적어두고 단축키로 템플릿을 적용하면, 매번 메타데이터를 수동 작성하지 않아도 일관된 형식의 메타데이터가 채워집니다. 이는 생산성을 높이고 실수를 줄여줍니다. 요약하자면, **메타데이터는 Obsidian에서 노트를 분류, 연결, 추적하는 데 핵심적인 역할**을 합니다. 단순한 텍스트 메모들을, 풍부한 속성을 지닌 **데이터 객체**로 격상시켜 준다고 볼 수 있죠. 적절한 메타데이터를 미리 설계해두면 수백 개의 노트도 체계 있게 관리할 수 있고, 필요할 때 원하는 관점으로 정보를 끄집어낼 수 있습니다. ## 5. 메타데이터 관련 주요 플러그인 종류와 기능 (Dataview, Templater, Supercharged Links 등) Obsidian의 강력함은 **커뮤니티 플러그인(plugin)**에서 나오며, 메타데이터 활용을 극대화하는 다양한 플러그인이 존재합니다. 여기서는 대표적인 몇 가지와 그 기능을 소개합니다: |플러그인 (Plugin)|주요 기능 및 역할| |---|---| |**Dataview (데이터뷰)**|Obsidian 노트들을 **데이터베이스처럼 조회**할 수 있게 해주는 강력한 플러그인입니다. 별도의 데이터베이스를 만드는 것이 아니라, Vault 내 모든 마크다운 노트를 대상으로 질의(Query)를 수행합니다. Dataview를 쓰면 메타데이터와 노트 내용을 조합하여 표, 리스트, 일정 등 원하는 형태로 보여줄 수 있습니다. 예를 들어 `TABLE 제목, 상태 FROM "" WHERE category = "프로젝트"`처럼 쓰면 카테고리가 "프로젝트"인 노트의 제목과 상태 필드를 표로 출력합니다. Dataview는 JavaScript를 활용한 DataviewJS도 지원해 매우 유연한 리포트도 생성 가능합니다. Notion의 데이터베이스 뷰와 거의 맞먹는 기능을 제공하기 때문에, Obsidian 사용자들에게는 사실상의 "디지털 레이버리" 역할을 ([Notion vs Obsidian // Databases vs Dataview| |**Templater (템플레이터)**|노트 생성 시 자동으로 일정 내용이나 코드를 삽입해주는 **템플릿 자동화** 플러그인입니다. 기본 템플릿 기능보다 강력하며, JavaScript 코드를 이용해 동적인 값도 넣을 수 있습니다. 메타데이터와 관련해 Templater는 새 노트를 만들 때 프론트매터를 자동 작성하거나, 기존 노트의 프론트매터를 업데이트하는 스크립트를 실행할 수 있습니다. 예를 들어 일기 노트를 만들면 자동으로 `date`를 오늘 날짜로, `tags`에 `일기` 태그를 넣도록 하거나, 특정 명령으로 `status: 완료` 시간을 찍어주는 등 활용이 가능합니다. 이를 통해 일관된 메타데이터 구조를 유지하고 수작업을 줄일 수 있습니다. (Templater 사용 시 주의: 템플릿 파일 내의 `---` 프론트매터 구문이 실제 노트의 메타데이터로 인식되지 않도록 하는 해키도 있습니다[3](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fn-3).)| |**Supercharged Links (슈퍼차지드 링크)**|노트의 **메타데이터를 기반으로 링크를 꾸며주는** 플러그인입니다. 이 플러그인을 사용하면 노트에 지정된 태그나 YAML 속성 값에 따라 해당 노트로 향하는 링크의 색상, 배경, 아이콘 등을 자동으로 다르게 표시할 수 있 ([GitHub - mdelobelle/obsidian_supercharged_links: obsidian plugin to add attributes and context menu options to internal links](https://github.com/mdelobelle/obsidian_supercharged_links#:~:text=Supercharged%20Links%20is%20an%20Obsidian,appealing%20and%20easier%20to%20navigate))82】. 예컨대 메타데이터에 `type: 사람`으로 되어 있는 노트들의 링크는 앞에 👤 사람 이모지를 붙인다든지, `status: 진행중`인 노트들의 링크는 글자색을 빨강으로 강조한다든지 하는 식입니다. 시각적 단서를 통해 링크된 노트의 성격이나 상태를 바로 알 수 있어 **맥락 파악**에 도움을 줍니다. 설정에서 태그 기준, 메타데이터 키 기준, 파일 경로(폴더) 기준으로 스타일 규칙을 정할 수 있어 유연합니다. Supercharged Links는 스타일 적용 외에도, 링크를 우클릭했을 때 그 대상 노트의 메타데이터를 편집할 수 있는 컨텍스트 메뉴 추가 기능도 있었는데, 이러한 편집 기능은 현재 **Metadata Menu** 플러그인으로 통합되었습니다.| |**Metadata Menu (메타데이터 메뉴)**|YAML 프론트매터를 보다 **손쉽게 관리**하기 위한 UI를 제공하는 플러그인입니다. 이 플러그인을 사용하면 일일이 텍스트 편집으로 메타데이터를 고치지 않고, 노트 보면서 속성 필드를 추가/수정할 수 있는 양식(form)이 나타납니다. 예를 들어 노트 상단에 현재 `status: 진행중`으로 되어있다면, 드롭다운 등으로 값을 변경하거나 새로운 키를 추가할 수 있습니다. 또한 특정 폴더나 태그에 속한 노트들에 공통으로 적용할 **필드 템플릿(필드 정의)**을 만들어 일괄적인 메타데이터 관리를 도와줍니다. Metadata Menu는 Supercharged Links와 상호보완적으로 쓰여, 링크의 컨텍스트 메뉴에서 메타데이터 수정 옵션을 제공하기도 합니다. 메타데이터 입력 실수를 줄이고 좀 더 **데이터베이스 앱처럼** Obsidian을 활용하고 싶을 때 유용합니다.| |**기타 플러그인들**|그 밖에도 메타데이터와 연계되는 플러그인은 많습니다. **Calendar**와 **Periodic Notes**는 날짜 메타데이터(일자)에 기반한 일일/주간 노트 체계를 돕고, **Tasks** 플러그인은 할 일 체크박스와 함께 `📅 due, 🔁 repeat` 같은 키워드를 인라인(본문)에 쓰면 이를 메타정보로 해석해 할 일 관리에 활용합니다. **Kanban** 플러그인은 보드의 카드들을 실제 마크다운 파일로 저장하면서 카드의 상태 등을 YAML에 기록해두기도 합니다. 또한 **QuickAdd (퀵애드)** 플러그인은 사용자 정의 폼을 통해 새 노트를 만들거나 특정 매크로 작업을 할 때 메타데이터를 포함시켜 줄 수 있고, **DataviewJS**를 응용하면 Obsidian 바깥의 데이터(API 호출 결과 등)를 메타데이터로 삽입하는 것도 가능합니다. 최근에는 AI를 활용해 메타데이터를 자동 생성해주는 플러그인 (예: Metadata Auto-Classifier, Auto Tagger 등)도 등장하여, 사용자가 직접 태그나 분류를 달지 않아도 내용에 맞춰 AI가 적절한 메타데이터를 추천/부착해주는 실험적인 기능도 이용해볼 수 있습니다 (다음 섹션에서 추가 설명).| ## 6. 외부 자동화 도구(n8n, Make 등)와 Webhook 연동 시 메타데이터 처리 주의사항 Obsidian은 로컬 파일 기반으로 동작하지만, **웹훅(Webhook)**이나 자동화 도구를 사용하면 외부 서비스와 데이터를 주고받을 수 있습니다. 대표적으로 n8n이나 Make(com)의 워크플로우 자동화에 Obsidian 노트를 활용하는 시나리오가 있습니다. 예를 들어 Obsidian에서 특정 노트가 업데이트될 때 웹훅을 호출해 외부 데이터베이스에 반영하거나, 반대로 외부에서 웹훅을 통해 Obsidian Vault에 노트를 생성하는 통합입니다. 이때 **메타데이터 처리**에 관한 몇 가지 주의점과 팁은 다음과 같습니다: - **YAML 추출 및 파싱:** Obsidian 노트 파일을 그대로 전달하면 맨 위에 YAML 메타데이터 블록이 포함되어 있게 됩니다. 외부에서 이 데이터를 받았을 때 YAML 부분을 파싱(parse)하여 키-값 쌍으로 이용할 수 있습니다. 예를 들어 n8n에서는 코드 노드(JavaScript)나 YAML 파서 노드를 통해 `---` 사이의 내용을 객체로 변환할 수 있습니다. 다행히 Post Webhook 등의 플러그인을 사용하면 이러한 작업이 수월해집니다. **Post Webhook** 플러그인은 Obsidian 노트의 **전체 콘텐츠(본문 + 메타데이터)**를 웹훅으로 전송할 수 있는데, 이때 YAML 메타데이터도 구조화된 형태로 함 ([Connect Obsidian and n8n with the Post Webhook Plugin - Built with n8n - n8n Community](https://community.n8n.io/t/connect-obsidian-and-n8n-with-the-post-webhook-plugin/63821#:~:text=With%20Post%20Webhook%2C%20you%20can,in%20your%20automated%20n8n%20workflows))L1-L4】. 즉, 외부 자동화 시 YAML을 쉽게 활용할 수 있도록 도와줍니다. 실제 사례로, Obsidian 노트에 `to: [email protected]`, `subject: 메시지 제목` 등을 메타데이터로 써두고, Post Webhook + n8n을 통해 이 노트를 이메일로 보내는 자동화가 ([Connect Obsidian and n8n with the Post Webhook Plugin - Built with n8n - n8n Community](https://community.n8n.io/t/connect-obsidian-and-n8n-with-the-post-webhook-plugin/63821#:~:text=To%20give%20you%20a%20sense,always%20have%20a%20complete%20record))5-L33】. n8n 쪽에서 노트 내용을 받아 YAML 필드를 읽어와 이메일 수신자, 제목 등을 채우고 본문과 첨부파일을 메일 발송한 뒤, 발송 완료 상태를 다시 Obsidian 노트에 업데이트해주는 식입니다. 이처럼 **메타데이터를 일종의 파라미터 설정**으로 활용하면 노트 내용 자체를 제어하지 않고도 외부 자동화를 다룰 수 있어 편리합니다. - **포맷 유지:** 외부 도구가 Obsidian 노트를 편집하거나 생성할 때는 YAML 포맷이 깨지지 않도록 유의해야 합니다. 예컨대 자동화 스크립트가 파일의 맨 앞에 몇 줄을 삽입한다면, 기존 `---` 구문을 보존하고 정확히 맨 앞줄에 위치시켜야 합니다. YAML은 들여쓰기와 특수문자에 민감하므로, 자동화 도구에서 값을 채울 때 따옴표나 이스케이프 처리를 신경써야 할 수 있습니다. (특히 콜론 `:`이나 하이픈 `-` 등이 값에 들어갈 경우). 또한 탭(tab)은 YAML에서 허용되지 않고 공백(space)만 가능하므로, 혹시 코드가 들여쓰기를 탭으로 넣지 않도록 해야 합니다. - **메타데이터와 본문 분리:** 노션이나 다른 노트 앱으로 Obsidian 노트를 내보낼 때, 상단의 YAML을 어떻게 처리할지도 결정해야 합니다. 어떤 도구는 `---` 구문을 인식 못 하고 그대로 본문에 남겨둘 수 있습니다. 만약 Obsidian 메타데이터를 Notion DB의 속성으로 옮기고 싶다면, 자동화 과정에서 YAML 블록을 제거하고 그 내용을 개별 필드로 매핑하는 작업이 필요합니다. 예를 들어 `category: 프로젝트` -> Notion의 "Category" 속성, `status: 진행중` -> Notion의 "Status" 속성 등으로 옮기는 식입니다. n8n이나 Zapier에서 이러한 매핑을 수행할 수 있으며, Obsidian 메타데이터 키 이름과 Notion 데이터베이스 속성명을 동일하게 맞춰두면 관리가 수월해집니다. - **양방향 동기화 주의:** 만약 외부에서 메타데이터를 수정해 Obsidian으로 다시 가져온다면, 충돌 관리에 유의하세요. Obsidian에서 같은 파일을 편집 중인데 외부에서 웹훅으로 수정된 버전을 넣으면 **동기화 충돌**이 발생할 수 있습니다. Obsidian Sync나 Git을 사용 중이라면, 메타데이터만 달라져도 충돌이 나올 수 있으므로 한쪽을 단일 진실 소스로 정하거나, 충돌 시 우선순위를 정해 자동 머지하도록 설정해야 합니다. 메타데이터 특성상 여러 키-값이 줄 단위로 나뉘어 있으므로, 줄 단위 머지가 가능할 수도 있지만 복잡한 경우엔 수동 확인이 필요합니다. - **보안 고려:** 메타데이터에는 종종 민감한 정보(예: API 키, 비번, 개인식별정보 등)가 들어갈 수도 있습니다. 외부 웹훅으로 노트 데이터를 보낼 때 이런 정보가 노출되지 않도록 주의해야 합니다. 필요한 경우 해당 키는 웹훅 전송 전 필터링하거나 암호화해서 보내는 것이 좋습니다. 반대로 외부에서 받은 데이터로 메타데이터를 구성할 때도 신뢰할 수 없는 값을 그대로 넣으면 보안 이슈나 Obsidian 렌더링 오류를 일으킬 수 있으니 유의합니다. 정리하면, Obsidian의 메타데이터는 외부 자동화와 통합될 때 매우 유용한 **매개층**이 됩니다. 노트의 내용과 형식을 크게 변경하지 않고도, YAML 메타데이터를 통해 외부 시스템과 소통할 수 있기 때문입니다. 다만 포맷 준수와 충돌 관리 등 기술적인 세부사항에 신경 써야 하며, 가능하다면 관련 기능을 제공하는 커뮤니티 플러그인(Post Webhook 등)을 활용해 시행착오를 줄이는 것 ([Connect Obsidian and n8n with the Post Webhook Plugin - Built with n8n - n8n Community](https://community.n8n.io/t/connect-obsidian-and-n8n-with-the-post-webhook-plugin/63821#:~:text=With%20Post%20Webhook%2C%20you%20can,in%20your%20automated%20n8n%20workflows))1-L29】. ## 7. 메타데이터 편집 방법 (직접 YAML 편집, AI 활용 등) 메타데이터를 관리하고 편집하는 방법은 **직접 편집**부터 **도구 활용**까지 다양합니다. 몇 가지 접근 방식을 소개합니다: - **직접 YAML 편집:** 가장 기본은 노트의 맨 위 YAML 블록을 수동으로 편집하는 것입니다. Obsidian에서 편집 모드로 해당 노트를 열고, 필요한 키-값을 추가하거나 수정한 뒤 저장하면 됩니다. 이 방식은 단순하지만, 사람이 수동으로 입력하다 보니 **문법 오류**를 낼 가능성이 있습니다. 예를 들어 콜론을 빼먹거나, 따옴표를 짝지어 쓰지 않거나, 리스트 항목 앞에 공백을 안 넣는다든지 하면 해당 노트의 메타데이터 파싱이 실패할 수 있습니다. 따라서 몇 가지 팁을 참고하면 좋습니다: - 키 이름에 공백이나 특수문자가 필요한 경우 피하고, 가능한 한 알파벳/숫자/하이픈으로 짓습니다. (공백이 필요하면 `"키 이름"`처럼 따옴표로 감싸야 하는데 번거롭습니다.) - 값에 콜론(`:`)이나 `#`이 포함되면 전체 값을 `" "`로 감싸주세요. 그렇지 않으면 YAML에서 콜론은 키-값 구분자로 혼동되고 `#`은 주석으로 처리됩니다. - 여러 줄 값(multi-line text)을 메타데이터 값으로 넣어야 하면 `|` 파이프 표기법을 사용할 수 있지만, 특수한 경우를 빼면 노트 본문에 쓰는 편이 낫습니다. 메타데이터에는 가급적 한 줄로 표현될 수 있는 정보 위주로 넣는 것이 좋습니다. - Obsidian 1.4 버전부터는 **Properties(속성) UI**가 추가되어, 프론트매터를 더 쉽게 다룰 수 있게 되었습니다. 노트 우측 상단 "Properties" 버튼이나 단축키 `Ctrl/Cmd+;`로 속성 편집 창을 열어 키-값을 편집할 수 있습니다. 이 UI에서는 YAML 문법을 몰라도 필드 추가/삭제가 가능하고, 데이터 타입별 입력 보조(날짜 선택 등)를 제공하므로 적극 활용해보세요. - 여러 노트의 메타데이터를 한꺼번에 수정해야 한다면, 전역 검색과 정규식 등의 기능을 활용해 일괄 편집하거나, **VS Code 등으로 폴더 열기**하여 교체(Replacer) 기능을 사용할 수도 있습니다. 다만 이 경우도 앞뒤 맥락을 잘 살펴 정확히 원하는 부분만 수정되도록 주의해야 합니다. - **플러그인 활용(UI 편집):** 앞서 소개한 **Metadata Menu** 같은 플러그인은 메타데이터 편집 과정을 훨씬 수월하게 만들어줍니다. 한 번 설정해두면, 지정한 키에 대해 미리 정의한 선택지 목록(예: status 키에 대해 "아이디어/진행중/완료" 옵션들) 중에서 고르는 식으로 입력할 수 있고, 날짜나 태그 입력도 자동 완성됩니다. **MetaEdit**이라는 간단한 플러그인도 있는데, 이는 커맨드 팔레트에서 `Metaedit: Add/Update Meta`를 실행해 현재 노트의 특정 메타데이터 값을 바로 수정할 수 있게 합니다. 이러한 도구들을 사용하면 YAML 구조를 직접 만지지 않아도 되므로 형식 오류 위험이 적고, **일관성 유지**에도 도움이 됩니다. 예컨대 사람마다 다르게 쓸 수 있는 상태 값을 드롭다운으로 통일한다거나, 태그 철자 실수를 줄인다거나 하는 식입니다. - **AI 활용 (자동 태깅 및 요약):** 최근에는 **인공지능(AI)**의 도움을 받아 메타데이터를 생성하거나 편집하는 시도가 늘고 있습니다. Obsidian 커뮤니티에도 AI 관련 플러그인들이 등장했는데, 대표적으로 **Metadata Auto-Classifier**가 있습니다. 이 플러그인은 노트 내용을 분석하여 **자동으로 적절한 태그와 카테고리 등을 추천/부여 ([Metadata auto classifier : The Power of AI-Driven Metadata in Obsidian | by Berom | Medium](https://beromkoh.medium.com/metadata-auto-classifier-the-power-of-ai-driven-metadata-in-obsidian-efae0ffc7f4e#:~:text=The%20Metadata%20Auto%20Classifier%20uses,Here%E2%80%99s%20why%20this%20is%20revolutionary))8-L77】. 예를 들어 수백 개의 문서가 있는 Vault에서 AI가 각 문서를 읽고 일관된 주제 태그를 붙여주거나, 중요 키워드를 꼽아 태그로 달아줄 수 있습니다. 이를 통해 사람이 일일이 태깅하는 노력을 덜고, 놓칠 수 있는 연관성까지 발견할 수 있다는 장점이 있습니다 (예: 경제학 글에 AI가 "인류학" 태그도 달아줘서 색다른 연관성을 찾아낼 수 있음). 다만, AI 태깅은 **100% 신뢰보다는 보조 수단**으로 보는 것이 좋습니다. Vault의 도메인 지식과 맥락을 완벽히 파악하지 못할 수 있고, 과한 태깅으로 오히려 혼란을 줄 위험도 있습니다. 그래서 Auto-Classifier는 결과를 한 번에 확정짓기보다 제안 형식으로 보여주고 사용자가 채택할지 결정하는 방식이 더 유용할 것입니다. Obsidian 자체 내에서 돌아가는 플러그인 외에도, ChatGPT 같은 외부 AI를 활용하는 방법도 있습니다. 예를 들어 어떤 노트의 요약문을 메타데이터로 넣고 싶다면, 노트 내용을 복사하여 ChatGPT에게 요약해 달라고 한 후 그 결과를 `summary` 키로 프론트매터에 붙여넣는 식입니다. 혹은, Vault의 모든 노트를 대상으로 파이썬 스크립트를 작성해 OpenAI API를 호출함으로써 태그를 생성하고 YAML에 추가하게 할 수도 있습니다[4](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fn-4). 이런 자동화는 강력하지만 API 비용과 시간을 고려해야 하며, 앞서 언급한 일관성 문제도 감안해야 합니다. **n8n, Zapier 등의 시나리오**에서도 AI 서비스를 연결하면, 새 노트가 생길 때 AI로 메타데이터를 채워넣는 자동화가 가능합니다. - **템플릿/자동 완성 활용:** 메타데이터 편집에 항상 거창한 툴이 필요한 건 아닙니다. Obsidian의 **스니펫(Snippet)**이나 **자동 완성(Auto-complete)** 기능도 작은 도움이 됩니다. 예를 들어 자주 쓰는 YAML 조각을 텍스트 확장 프로그램(AHK, Espanso 등)에 등록해두고 `;meta`라고 치면 기본 프론트매터 양식이 삽입되게 할 수 있습니다. 또는 Dataview로 현재 사용 중인 모든 키 목록을 뽑아볼 수도 있으니, 이를 참고하여 철자나 명칭을 통일할 수도 있습니다. --- 이상으로 Obsidian에서 메타데이터의 개념부터 구조, 활용, 확장까지 살펴보았습니다. 마지막으로, 질문 주신 **CMDS 지식관리 흐름**의 각 단계에서 메타데이터가 어떻게 유용하게 쓰일 수 있는지, 하나의 **시나리오**를 통해 종합적으로 설명하겠습니다. ## 8. CMDS 지식관리 흐름 단계별 메타데이터 활용 시나리오 (Connect → Merge → Develop → Share) 사용자님이 제시한 **CMDS**는 **Connect(연결)** - **Merge(병합)** - **Develop(발전)** - **Share(공유)**의 약자로, 지식을 수집하고 가공하여 최종 산출물로 공유하기까지의 네 단계 흐름을 나타냅니다. 이제 한 사용자의 Vault에서 이 CMDS 프로세스를 메타데이터와 함께 구현하는 예시를 들어보겠습니다. **가정 시나리오:** 사용자 C는 "인공지능의 윤리적 이슈"라는 주제로 자료를 조사하여 최종 보고서를 작성하려고 합니다. C는 Obsidian을 활용해 관련 정보를 모으고 정리하는데, CMDS 메타데이터 체계를 도입하여 단계별로 노트의 상태를 관리합니다. - **1. Connect(연결) 단계 – 아이디어 및 정보 수집:** 이 단계에서는 주제와 관련된 다양한 외부 자료와 아이디어를 **연결**합니다. 사용자 C는 뉴스를 읽다가 AI 윤리에 관한 흥미로운 기사를 발견하면 Obsidian에 새 노트를 만듭니다. 템플릿을 통해 프론트매터에 `status: Connect`로 지정되고, `tags: [AI, 윤리, 자료]` 같은 태그와 출처 URL 메타데이터가 자동 채워집니다. 예를 들어 노트 **"AI윤리_기사요약"**의 YAML은 다음과 같을 수 있습니다: ```yaml --- title: AI 윤리 관련 기사 요약 status: Connect tags: [AI, 윤리, 자료] source: "https://news.example.com/ai-ethics" date: 2025-06-10 --- ``` 본문에는 해당 기사에서 얻은 핵심 문장과 요약이 적혀 있습니다. `status: Connect`를 메타데이터로 표시함으로써, 이 노트가 아직 가공되지 않은 **수집된 정보**임을 나타냅니다. Vault 내 다른 Connect 단계 노트로는 관련 논문 초록 정리, 아이디어 스크랩 노트 등이 있습니다. - _메타데이터 활용:_ C는 주기적으로 **"Inbox"** 역할의 대시보드 노트를 확인하는데, 여기에 Dataview로 `WHERE status = "Connect"`인 노트 목록을 출력해 둡니다. 이를 통해 현재 **수집한 자료들**이 무엇무엇인지 한눈에 파악합니다. 또한 Graph 뷰에서 태그로 연결된 모습을 보면, 방금 수집한 기사요약 노트와 유사 태그(AI, 윤리)를 가진 기존 노트들이 한데 묶여 보여집니다. 이로써 새로운 정보가 기존 지식망에 어떻게 연결되는지 시각적으로 확인하고, 추가로 읽을만한 관련 메모를 쉽게 찾아갑니다. 예를 들어 이전에 작성했던 "AI 윤리 개요" 노트에도 `#AI` 태그가 달려 있었다면 Graph 상에서 서로 연결되어 보일 것입니다. - **2. Merge(병합) 단계 – 정보 통합 및 아이디어 결합:** 여러 Connect 단계 자료를 수집한 C는 이제 **Merge 단계**로 넘어갑니다. 이는 **관련된 조각들을 하나로 융합**하여 통찰을 얻는 과정입니다. C는 앞서 수집한 기사, 논문 노트들을 바탕으로 새로운 노트 **"AI 윤리 쟁점 정리"**를 작성하기 시작합니다. 이 노트는 Merge 단계의 산출물이므로 프론트매터에 `status: Merge`를 설정합니다. 또한 이 노트에는 어떤 소스들을 병합했는지 추적하기 위해 사용자 정의 필드 `sources:`를 추가하고, 값으로 관련 노트들의 제목이나 ID를 나열합니다. 예: ```yaml --- title: AI 윤리 쟁점 정리 status: Merge tags: [AI, 윤리, 통합] sources: ["AI윤리_기사요약", "OpenAI_정책논문"] date: 2025-06-15 --- ``` 본문에는 여러 출처에서 얻은 내용들을 재구성하여 하나의 정리된 글 형태로 작성합니다. 이전 단계의 개별 메모들에서 핵심만 발췌하고, C 자신의 해석을 덧붙여 **통합된 새로운 지식**을 만들어냅니다. 아직 완전한 최종 글은 아니지만, 토론해야 할 쟁점들을 이 노트 하나에 모은 것입니다. - _메타데이터 활용:_ `status: Merge` 메타데이터 덕분에, C는 대시보드의 "🗒️ **통합 중 노트**" 목록에서 현재 Merge 단계에 있는 노트들을 관리합니다. 이 목록에는 위 "AI 윤리 쟁점 정리" 외에도 Merge 상태인 다른 프로젝트 노트들이 나타나 있으며, 각 노트에 연결된 `sources` 필드도 함께 표시되도록 Dataview 쿼리를 구성했습니다. 그렇게 하면 **어떤 자료들이 결합되었는지 추적**이 쉽습니다. 나아가, Supercharged Links 플러그인을 세팅해 두었다면 Merge 단계 노트에 대한 링크들은 예를 들어 노란색 배경으로 표시되도록 했을 것입니다. 그래서 Vault 내 어디서든 "AI 윤리 쟁점 정리" 노트로의 링크를 보면 배경이 노란색이라 "아, 이건 지금 여러 자료를 합쳐서 정리 중인 노트구나" 하고 바로 알 수 있습니다. C는 이 노트를 작성하며 필요에 따라 원본 소스 노트들을 다시 참조하는데, `sources` 필드에 적어둔 노트 제목들을 하나씩 클릭해가며 세부 내용을 확인하고 있습니다. 만약 Merge 노트 작성을 마쳤다면 C는 프론트매터의 `status`를 다음 단계로 수동 업데이트하거나(혹은 Metadata Menu로 드롭다운 선택), 그냥 Develop 단계에서 덮어쓸 새 노트를 만들 수도 있습니다. - **3. Develop(발전) 단계 – 콘텐츠 심화 및 작성:** Develop 단계에서는 Merge 단계까지 정리된 내용을 토대로 **최종 산출물 수준으로 발전**시키는 작업을 합니다. C는 "AI 윤리 쟁점 정리" 노트를 바탕으로 실제 보고서 초안 작성을 시작합니다. 이때 기존 노트를 발전시켜도 되고, 새로운 노트를 만들어 내용을 이어나갈 수도 있습니다. 여기서는 같은 노트를 계속 다듬는다고 가정하겠습니다. C는 해당 노트의 `status`를 `Develop`으로 변경합니다 (예: Metadata Menu로 상태 필드를 Develop로 선택). 그리고 프론트매터에 `draft: 1` 같은 커스텀 키를 추가해 현재 초안 버전을 표시하거나, `deadline: 2025-06-20`처럼 마감 기한을 넣어두었습니다. 노트 본문은 점차 완성된 보고서 형태를 갖춰갑니다. - _메타데이터 활용:_ Develop 단계 노트는 보통 상당한 분량의 텍스트와 구조를 가지므로, C는 편집에 집중하되 메타데이터를 통해 **남은 할 일과 진행 상황**을 관리합니다. 예를 들어 본문에 체크박스 `- [ ] 결론 부분 쓰기` 등을 추가해 Tasks 플러그인으로 관리하거나, 프론트매터에 `progress: 70%`처럼 진행률을 수동 기입해볼 수도 있습니다. status가 Develop인 노트는 Supercharged Links 설정에 따라 링크 색상이 주황색으로 보이는데, 이는 팀원들과 공유된 Vault라면 "이건 지금 작성 진행 중인 문서"임을 모두에게 시각적으로 알려줍니다. 또한 C는 Dataview로 "이번 달 내 완료해야 할 Develop 단계 노트"를 쿼리하여, `WHERE status = "Develop" AND deadline <= date(2025-06-30)` 등의 목록을 미리 만들어 두었습니다. 이러면 마감이 임박한 작성중인 작업들을 한 눈에 볼 수 있어 **우선순위 관리**에 도움이 됩니다. 만약 보고서 작성 중 참고해야 할 다른 노트가 생각나면, 해당 노트를 `related` 필드에 추가해두기도 합니다. 예를 들어 `related: ["AI 윤리 개요", "AI법규 메모"]` 식으로 메타데이터에 써놓으면, 나중에 빠뜨리지 않고 참고했는지 검토할 때 편합니다. (Dataview로 Develop 노트에 연결된 related 노트들이 제대로 참조되었는지 리스트업할 수도 있죠.) - **4. Share(공유) 단계 – 최종 공유 및 출판:** 마침내 C의 보고서가 완성되었습니다. 이제 이를 발표하거나 블로그에 게시하는 등 **공유 단계**로 넘어갑니다. Obsidian 상에서는 최종본이라는 표시로 `status: Share` 또는 `status: Published`로 메타데이터를 수정합니다. 그리고 추가로 `publish: true` 라는 키를 넣어 공개 대상임을 명시했습니다. 또한 웹 출판을 할 경우를 대비해 `slug: ai-ethics-issues` (공유용 URL 슬러그)나 `summary: "...요약문..."` 등을 메타데이터에 포함시킵니다. C는 이 노트를 PDF로 내보내 colleagues에게 배포했고, 자신의 기술 블로그에 마크다운으로도 게시했습니다. - _메타데이터 활용:_ Share 단계로 바뀐 노트는 Vault 내 **지식 자산 레파지토리**에 편입됩니다. C는 Obsidian에서 별도로 `status: Share`인 문서들만 모아두는 폴더를 운영하거나 Dataview로 목록을 관리합니다. 가령 "📚 **완료된 아티클**"이라는 노트에 `WHERE status = "Share"`로 쿼리해두면, 지금까지 자신이 완성하여 공유한 글들의 목록이 자동으로 업데이트됩니다. 각 항목에는 `date`(완료일)와 `slug`(URL) 메타데이터도 표시되어, 나중에 빠르게 블로그 링크를 찾아보거나 한 해의 성과를 정리하는 데 활용합니다. 만약 이 Vault를 다른 사람과 공유한다면, Share 단계 문서들만 읽기 권한을 주고 나머지는 비공개로 두는 식의 접근제어도 가능합니다(예: publish:true 키를 기준으로 스크립트가 Vault에서 추출). 또한 Supercharged Links 설정에 따라 Share 단계 노트는 링크에 녹색 하이라이트가 되어, 누구나 봐도 "완성된 문서"로 인지하게 됩니다. 그 링크를 클릭하면 프론트매터에 `status: Share`와 함께 `✅ Published on 2025-06-18` 같은 추가 정보도 기록되어 있어서, **최종 배포 시점과 경로**를 추적할 수 있습니다. 이는 차후에 이 문서를 업데이트해야 할 필요가 생겼을 때 (새로운 윤리 규정이 나왔다든지) 과거에 어디까지 공유됐었는지 참고하기 위함입니다. **전체 흐름 요약:** 위 시나리오에서 보듯이, 메타데이터는 CMDS의 각 단계에서 노트의 **맥락과 상태를 명확히 규정**해주고, 단계 전환 시 업데이트되면서 자연스럽게 워크플로우 관리 도구가 됩니다. **Connect** 단계에서는 메타데이터가 정보의 출처와 분류를 담아주어 수집한 자료들을 체계화하고, **Merge** 단계에서는 어떤 재료들이 통합되고 있는지 추적 가능하게 해주며, **Develop** 단계에서는 작업 진행상황과 관련 참고사항을 메타데이터로 관리하여 최종 완성을 돕고, **Share** 단계에서는 완성본의 배포 정보와 아카이빙에 활용됩니다. Obsidian의 검색과 Dataview, 그리고 시각화 플러그인들은 이 메타데이터를 활용해 각 단계의 노트들을 필요한 형식으로 보여주어 사용자의 **지식관리 흐름을 지원**합니다. 마지막으로 중요한 포인트는, **일관성 있는 체계 설계**입니다. CMDS 단계 구분도 결국 사용자 정의 메타데이터 체계의 하나이므로, 자신만의 표기법과 규칙을 정해두고 꾸준히 적용해야 합니다. 예를 들어 status 필드를 쓸지 태그 (`#status/Connect` 등)를 쓸지 결정하고, 사용할 값(Connect/Merge/Develop/Share)을 정확히 정해 일관되게 사용하세요. 또한 주기적으로 메타데이터가 잘못 붙은 노트는 없는지(오타난 status 등) 점검하고, 필요시 일괄 정정하여 **신뢰성 있는 메타데이터 환경**을 유지하는 것이 좋습니다. 그렇게 할 때 Obsidian 메타데이터는 강력한 **나만의 지식 데이터베이스**로 기능하며, 노트 간 **Connect(연결)**을 풍부하게 하고, 아이디어를 **Merge(융합)**하며, 지식을 **Develop(발전)**시키고, 최종 산물을 **Share(공유)**하는 전 과정에 걸쳐 든든한 도구가 되어줄 것입니다. ## Footnotes 1. YAML 프론트매터는 노트의 첫 줄부터 시작해 `---`로 시작하고 끝나는 구간에 작성합니다 ([YAML frontmatter formatting - Help - Obsidian Forum](https://forum.obsidian.md/t/yaml-frontmatter-formatting/43673#:~:text=YAML%20frontmatter%20formatting%20,first%20line%20of%20the%20note)). 이 구간에 있는 내용이 메타데이터로 인식됩니다. [↩](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fnref-1) [↩2](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fnref-1-2) 2. Obsidian은 기본 설정상 읽기 모드에서 프론트매터를 표시하지 않아 메타데이터가 노트 본문에 드러나지 않습니다 ([YAML Frontmatter - Fork My Brain](https://notes.nicolevanderhoeven.com/obsidian-playbook/Using+Obsidian/03+Linking+and+organizing/YAML+Frontmatter#:~:text=YAML%20Frontmatter%20,when%20you%27re%20viewing%20a%20note)). (환경설정의 'Show frontmatter' 옵션으로 표시 여부를 조정 가능) [↩](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fnref-2) [↩2](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fnref-2-2) 3. Templater로 템플릿을 만들 때, 템플릿 파일 내의 YAML 프론트매터가 Obsidian에 의해 실제 메타데이터로 잘못 인식되지 않도록 `<%---%>` 구문을 쓰는 팁 ([Hacking Obsidian: Frontmatter and Templater | by TfTHacker | Obsidian Observer | Medium](https://medium.com/obsidian-observer/hacking-obsidian-frontmatter-and-templater-f4912a689cdc#:~:text=To%20prevent%20Obsidian%20from%20detecting,template%2C%20try%20this%20straightforward%20hack)) ([Hacking Obsidian: Frontmatter and Templater | by TfTHacker | Obsidian Observer | Medium](https://medium.com/obsidian-observer/hacking-obsidian-frontmatter-and-templater-f4912a689cdc#:~:text=Of%20course%20when%20you%20use,document%20now%20has%20valid%20frontmatter))-L120】. 템플릿에서는 `<%---%>`로 메타데이터를 감싸두고, 템플릿 적용 시 Templater가 이를 `---`로 변환하여 최종 노트에는 올바른 프론트매터가 생기도록 합니다. [↩](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fnref-3) 4. 예시: 파이썬으로 Obsidian Vault의 모든 `.md` 파일을 읽어 OpenAI GPT에 내용을 요약/태깅 요청하고, 결과를 각 파일의 YAML에 `tags`나 `summary`로 써넣는 스크립트를 작성할 ([How to auto-tag your Obsidian notes using OpenAI - Medium](https://medium.com/@absurdreality/how-to-auto-tag-your-obsidian-notes-using-openai-662dce703a0d#:~:text=How%20to%20auto,file%20in%20your%20Obsidian%20vault))5-L43】. 다만 자동 태깅 결과는 검수 과정을 거쳐야 하고, API 키 관리 및 요금 주의가 필요합니다. [↩](https://chatgpt.com/c/67e2647b-e56c-8006-8a11-6cbae6fa7a4c#user-content-fnref-4)