Ch.06 · AI가 잘 읽는 노트는 어떻게 쓰는가 | 메타데이터와 연결
같은 내용도 어떻게 써두느냐에 따라 AI 검색 정밀도가 갈립니다. 노트의 이름표(메타데이터)와 노트끼리의 연결, 본문 구조를 다룹니다.
Overview
Ch.05에서 노트에 무엇을 담을지 — 이해하고 동의한 내용, 그리고 내 판단까지 — 정했습니다. 그런데 같은 내용을 담아도, 어떻게 써두느냐에 따라 AI가 잘 찾기도 하고 엉뚱한 노트를 집기도 합니다.
Ch.03에서 봤듯, AI는 노트를 통째로 읽지 않고 질문과 관련된 노트만 검색해서 읽습니다(RAG). 비슷한 노트가 여럿일 때 그중 무엇을 집을지 — 그 검색 정밀도는 폴더가 아니라 노트가 어떻게 쓰였는지에서 나옵니다. 이번 챕터는 그 작성법을 두 가지로 봅니다.
- 메타데이터: AI가 이 노트가 뭔지 빠르게 파악하게 하는 이름표와, 노트끼리의 연결
- 본문 구조: 제목·소제목으로 의미 단위를 나눠 쓴 본문
학습 목표
- 노트를 식별하게 하는 메타데이터 4가지를 설명할 수 있습니다
- 위키링크로 노트끼리 연결하면 왜 검색보다 정확한 맥락이 쌓이는지 이해합니다
- 본문을 의미 단위로 끊어 쓰는 것이 나중에 왜 도움이 되는지 압니다
메타데이터: AI가 빠르게 파악하게 하는 4가지
폴더가 영역을 나눠줘도, 그 안에 비슷한 노트가 여럿이면 AI는 어느 게 진짜 필요한지 가려내지 못합니다. 결국 비슷해 보이는 노트를 다 열어 읽게 되죠. 쓸데없는 내용까지 읽느라 토큰을 낭비하고, 엉뚱한 노트가 섞여 답도 흐려집니다.
예를 들어 "환불 정책" 관련 노트가 5개 있다고 해봅시다. 회의 기록, 외부 사례, 정책 안내문, A/B 테스트 결과, 임원 보고용 슬라이드 메모. "환불 정책 어떻게 결정했지?" 물어볼 때 진짜 필요한 건 회의 기록 하나뿐인데, 식별 정보가 없으면 나머지 4개까지 들춰보고 답이 흐려집니다.
그 식별 정보가 메타데이터입니다. 4가지를 챙기면 됩니다.
(1) 프론트매터: 이 노트의 이름표
노트 맨 위에 넣어두는 기본 정보입니다.
---
title: "환불 정책 의사결정 회의"
date: 2026-05-15
tags:
- product/policy
- decision/refund
---AI가 이 이름표만 봐도 "이 노트는 환불 정책 의사결정 회의구나"를 즉시 파악합니다.
(2) aliases: 다른 이름으로도 검색되게
aliases:
- "환불 24시간 정책 결정"
- "Refund 24h Decision"같은 노트를 다른 단어로도 찾을 수 있게 해줍니다. "환불"로 검색해도, "refund"로 검색해도 같은 노트가 검색됩니다.
(3) description: 한 줄 요약
description: "악용 대응을 위해 환불 정책을 결제 후 24시간으로 조정한 의사결정 기록"AI가 본문을 열어보지 않고도 "이게 어떤 내용인지" 파악하게 해주는 한 줄입니다. 100개 노트 중에 필요한 걸 빠르게 고를 때 결정적입니다.
(4) 위키링크: 노트끼리 연결해 자료실을 망으로 쌓는다
앞의 셋이 노트 하나하나에 붙는 이름표라면, 위키링크는 노트와 노트를 잇는 선입니다.
노트 하나는 보통 다른 노트들의 뒷받침을 받습니다. "환불 정책" 노트는 그 근거가 된 "환불 고객 데이터", 다른 회사 사례인 "타사 환불 정책" 같은 노트와 이어져 있죠. 문제는, 본문 내용만으로는 AI가 이 노트들이 서로 관련 있다는 걸 못 찾을 때가 많다는 겁니다. 쓰인 단어가 겹치지 않으면 키워드 검색으로는 검색되지 않으니까요.
그래서 [[타사 환불 정책]] 식으로 직접 연결해둡니다. 이러면 AI가 이 노트를 불러올 때 연결된 노트까지 따라가 읽도록 지정해둘 수 있습니다. "환불 정책"을 보면 "타사 환불 정책"까지 맥락에 끌어오게 만드는 거죠. 몇 단계(몇 홉)까지 따라가 읽게 할지도 정할 수 있습니다.
이 볼트에서는 노트 맨 아래 "관련 노트" 칸을 두고, 연결만 하는 게 아니라 어떻게 연결되는지 관계의 종류까지 함께 적어둡니다. 네 가지를 씁니다.
- 근거: 이 노트의 주장을 뒷받침하는 노트
- 확장: 이 노트의 생각을 더 밀고 나간 노트
- 반박: 이 노트와 충돌하거나 한계를 짚는 노트
- 사례: 이 노트의 구체적인 예가 되는 노트
실제로는 이런 모양입니다.
## 관련 노트
- [[환불 고객 데이터]] — [근거] 환불 정책의 바탕이 된 고객 데이터
- [[타사 환불 정책]] — [사례] 다른 회사의 환불 정책 사례관계까지 적어두면, AI가 단순히 "관련 있다"를 넘어 "이건 근거고, 저건 확장"이라는 것까지 알고 맥락을 채웁니다.
더 중요한 건, 이 연결이 쌓일수록 자료실 자체가 하나의 망(網)이 된다는 점입니다. 노트를 추가할 때마다 관련 노트와 이어두면, 흩어진 노트 더미가 아니라 서로 연결된 지식 구조가 됩니다. 한 노트를 부르면 연결된 맥락이 줄줄이 따라오니, Ch.04에서 본 "쌓일수록 가치가 불어나는 자료실"이 실제로 이 연결 위에서 만들어집니다.
본문 구조: 의미 단위로 끊어 쓰기
본문은 한 덩어리로 길게 쓰지 말고, 제목 → 소제목 → 내용으로 의미 단위를 나눠 씁니다. 회의록이면 "결정사항 / 검토한 안 / 다음 일정"처럼 소제목으로 끊는 식이죠.
소제목으로 끊어두면, 소제목 자체가 그 단위의 키워드이자 요약이 됩니다. 소제목 단어로 노트가 검색에 더 잘 걸리고, AI도 "결정사항" 같은 소제목을 보고 질문에 맞는 대목을 바로 짚죠. 반대로 한 덩어리로 뭉쳐 있으면, 찾아도 어디가 답인지 헤매 답이 흐려집니다.
사람이 다시 볼 때도 소제목이 있으면 훑기 쉽고요. 길어지면 끊는다 — 이 습관 하나면 충분합니다.
여기까지는 노트를 통째로 읽는 키워드 검색 기준입니다. Series 2의 의미 검색은 노트를 미리 조각으로 잘라두고, 질문과 뜻이 가까운 조각만 골라 옵니다 — 수백 개를 다 뒤지지 않고요. AI는 그 조각으로 단서를 잡고, 더 필요하면 그 노트만 콕 집어 더 읽죠. 소제목으로 잘 나눠 써두면 조각마다 의미가 또렷해져 더 정확히 검색됩니다.
자동화: 이걸 매번 직접 쓰진 않는다
메타데이터·연결·본문 구조를 노트마다 직접 채워야 할까요? 아닙니다. 우리가 할 일은 글의 내용을 주는 것뿐입니다. 형식은 미리 정해둔 규칙에 따라 AI 팀원이 저장할 때 알아서 작성합니다. 그 규칙을 만드는 방법은 다음 챕터에서 다룹니다.
핵심 포인트 정리
- 메타데이터 4가지: 프론트매터 / aliases / description / 위키링크 — AI가 노트를 빠르게 식별
- 위키링크는 연결 구조: 노트끼리 이어두면 검색보다 정확한 맥락이 따라오고, 쌓일수록 자료실이 하나의 망이 된다
- 본문 구조: 제목·소제목으로 의미 단위를 끊어 쓰기. 나중 의미 검색에서 딱 맞는 토막만 검색되게
FAQ
Q: 노트 연결도 일일이 직접 해야 하나요? A: AI가 비슷한 내용을 검색해 연결 후보를 제안해줍니다. 다만 내 의도와 다르게 해석해 엮을 수도 있으니, 실제 연결은 내가 확인하고 거는 걸 권합니다. 무엇을 잇느냐가 곧 내 판단이니까요.
Q: 본문을 꼭 소제목으로 나눠 써야 하나요? A: 짧은 노트면 굳이 안 나눠도 됩니다. 다만 길어지면 제목·소제목으로 끊어두세요. 나중에 의미 검색이 노트를 의미 단위로 잘라 찾기 때문에, 미리 나뉘어 있으면 딱 맞는 부분만 정확히 검색됩니다.
이어서 배울 내용
AI가 잘 읽는 노트의 형태까지 살펴봤습니다. 하지만 또 다른 문제가 남습니다. 이 형식을 매번 직접 맞춰 쓰면 며칠 못 갑니다. 프론트매터 챙기고 폴더 분류하는 게 번거로워 기록을 미루다 보면, PKM은 갱신이 끊겨 방치됩니다.
다음 챕터에서는 이 노트를 직접 쓰는 대신 AI 팀원에게 맡겨 저장하고 관리하는 방법을 살펴봅니다.
- 직접 쌓지 않는 자동 저장
- 매번 같은 양식을 강제하는 CLAUDE.md와 스킬
- 쌓인 노트를 옮기고 갱신하는 관리