링크를 본문에 쓸까 메타데이터에 쓸까 — 발행되는 글이라면 답이 갈린다

▶ 동영상 개요 — 링크를 본문에 쓸까 메타데이터에 쓸까 — 발행되는 글이라면 답이 갈린다

5분 27초 — 발행 도구가 본문을 그대로 웹에 올리기 때문에 본문에 남은 대괄호 링크 표기가 독자 화면에 그대로 노출된다 — 밖으로 나갈 글은 메타데이터에, 내부 기록은 본문에 — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 링크를 본문에 쓸까 메타데이터에 쓸까 — 발행되는 글이라면 답이 갈린다

15분 53초 — 발행 도구가 본문을 그대로 웹에 올리기 때문에 본문에 남은 대괄호 링크 표기가 독자 화면에 그대로 노출된다 — 밖으로 나갈 글은 메타데이터에, 내부 기록은 본문에. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

노트끼리 잇는 방법은 크게 둘이다. 본문에 [[개념/증분-색인]]처럼 대괄호 표기를 적거나, 문서 머리 메타데이터에 related: 목록으로 적는다. 대부분의 글은 이걸 취향 문제로 다룬다. 나도 그렇게 생각했다.

그런데 그 노트 중 일부가 블로그 글로 나가기 시작하면 취향이 아니라 사고 여부의 문제가 된다. 본문에 남은 대괄호가 발행된 글에 그대로 찍혀 나가기 때문이다. 이 글은 그 경계에서 정리한 규칙 하나를 다룬다.

발행 파이프라인은 대괄호를 지워 주지 않는다

내가 쓰는 발행 도구를 열어 보고 확인한 사실이다. 위키링크 표기를 다루는 곳이 딱 한 군데 있었는데, 그마저도 관련 문서를 찾아내는 입력 신호로만 쓰고 있었다. 어떤 글을 쓸 때 참고할 다른 노트를 고르는 데 링크를 이용할 뿐, 본문에서 그 표기를 제거하는 단계는 어디에도 없었다.

즉 초안 본문에 [[concepts/증분-색인]]이 남아 있으면 그 문자열이 그대로 웹에 올라간다. 독자에게는 의미 없는 대괄호 덩어리로 보인다. 링크로 바뀌지도 않는다 — 대괄호 표기는 내 노트 앱 안에서만 통하는 약속이지 웹 표준이 아니기 때문이다.

다이어그램 설명. 노트에 적은 표기가 아무 변환도 거치지 않고 독자 화면까지 도달하는 경로다. 중간에 "링크로 바꾸거나 지우는" 단계가 없다는 게 핵심이다. 이런 유출은 배포 파이프라인에서 흔한 유형인데, 잘못된 것이 오류를 내지 않고 조용히 통과하기 때문에 발행 후 독자가 보고서야 알게 된다. 초안을 눈으로 검토하면 걸러진다고 생각하기 쉽지만, 글이 길어지면 본문 중간의 대괄호 하나는 잘 안 보인다.

메타데이터 링크는 다른 문으로 들어간다

같은 관계를 메타데이터에 적으면 그림이 달라진다.

---
title: "색인 파이프라인 설계 메모"
related:                     # 관계는 여기에 선언한다
  - concepts/증분-색인
  - tech/pgvector
---

본문에는 대괄호가 하나도 없다. 독자가 읽을 문장만 남는다.

코드 설명. related 목록이 관계를 담고, 본문은 사람이 읽을 문장만 갖는다. 발행 도구는 대개 메타데이터를 제목·태그·발행일 같은 설정으로만 쓰고 본문에 섞지 않으므로, 이 목록은 웹에 노출되지 않는다. 관계는 남고 지저분함은 사라지는 셈이다.

내가 확인한 도구 쪽 동작도 이 구조를 뒷받침했다. 본문 대괄호 표기는 미리 정해진 디렉토리 목록을 통과해야만 인정되는데, 메타데이터의 related·see_also 목록은 그 목록을 거치지 않고 이름을 문서로 바로 찾아 준다. 실제로 내 기록 3,275개에서 본문 표기로 인정된 관계는 1개뿐이었다 — 링크를 안 달아서가 아니라 내 폴더 이름이 그 목록에 없었기 때문이다. 메타데이터 경로였다면 그 제약에 걸리지 않았다.

다이어그램 설명. 같은 관계를 두 방식으로 적었을 때 부딪히는 조건이 다르다는 걸 보여준다. 본문 표기 쪽은 통과해야 할 관문이 하나 더 있고 그마저 통과해도 발행물에 흔적이 남는다. 메타데이터 쪽은 두 문제를 모두 비켜 간다. 다만 이걸 "메타데이터가 항상 우월하다"로 읽으면 곤란하다 — 다음 절에서 보듯 본문 표기에만 있는 정보가 있다.

그래도 본문 표기를 버리지 않는 이유

메타데이터가 깨끗하다고 전부 그쪽으로 옮기면 잃는 게 있다. 문맥이다.

본문에 링크를 걸면 그 링크가 어떤 문장 안에서 등장했는지가 함께 남는다. 관계를 저장할 때 주변 문장을 같이 기록해 두면, 나중에 그래프를 열었을 때 "왜 이 둘이 이어져 있지?"에 대한 답이 그 자리에 있다. 메타데이터 목록은 관계가 있다는 사실만 말하고 이유는 말하지 않는다.

또 하나, 본문 표기는 읽는 흐름 안에서 자연스럽게 생긴다. 문장을 쓰다가 "아 이건 저 개념이지" 싶을 때 그 자리에 걸면 된다. 메타데이터는 글을 다 쓰고 나서 위로 올라가 따로 적어야 해서, 솔직히 자주 잊는다.

그래서 나는 이렇게 나눴다

기준을 문서의 운명으로 잡았다. 밖으로 나갈 글이냐 아니냐다.

다이어그램 설명. 판단을 한 가지 질문으로 줄인 결정 규칙이다. 밖으로 나갈 글이면 메타데이터에, 내 안에만 있을 기록이면 본문에 적는다. 규칙을 단순하게 만든 이유가 있다 — 글을 쓰는 순간에 판단을 오래 하면 결국 아무 데도 안 적게 된다. 발행 여부는 대개 쓰기 시작할 때 이미 알고 있어서 망설일 일이 없다.

애매한 경우에는 메타데이터 쪽으로 기운다. 내부 노트에 메타데이터로 적어 두면 문맥은 잃지만 사고는 안 난다. 반대 방향의 실수는 발행된 글에 대괄호가 찍혀 나가는 것이라 비용이 훨씬 크다. 되돌리려면 이미 읽은 사람이 있는 상태에서 글을 고쳐야 한다.

정리 — 링크 표기법은 노출 경계와 함께 정한다

본문이냐 메타데이터냐는 취향 문제로 보이지만, 그 노트가 발행 경로에 올라타는 순간 노출 경계 문제가 된다. 발행 도구가 본문을 있는 그대로 옮긴다면 본문에 남긴 내부 표기는 전부 밖으로 나간다고 가정하는 편이 안전하다.

개인 기록에 적용한다면, 노트 폴더를 훑어보고 "여기 있는 글이 밖으로 나갈 수 있나"를 폴더 단위로 한 번만 정해 두는 걸 권한다. 그러면 글을 쓸 때마다 고민할 필요 없이 폴더가 표기법을 알려 준다. 규칙이 손에 붙어야 링크가 실제로 쌓인다.

---

참고한 공개 자료:

• gbrain — 개인 지식 브레인 오픈소스: https://github.com/garrytan/gbrain
• Obsidian 내부 링크(위키링크) 표기법: https://help.obsidian.md/Linking+notes+and+files/Internal+links
• Obsidian 속성(properties) 문서: https://help.obsidian.md/Editing+and+formatting/Properties

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.