관계에 이름을 붙이려면 — 문서 종류를 먼저 선언해야 하는 이유

▶ 동영상 개요 — 관계에 이름을 붙이려면 — 문서 종류를 먼저 선언해야 하는 이유

5분 31초 — 폴더 경로만으로는 문서 종류가 정해지지 않는다 — meetings 폴더에 넣어도 모임으로 인식되지 않아 참석 관계가 '언급함'으로 내려앉고, type을 직접 선… — NotebookLM 동영상 개요로 생성

🎧 오디오 개요 — 관계에 이름을 붙이려면 — 문서 종류를 먼저 선언해야 하는 이유

19분 13초 — 폴더 경로만으로는 문서 종류가 정해지지 않는다 — meetings 폴더에 넣어도 모임으로 인식되지 않아 참석 관계가 '언급함'으로 내려앉고, type을 직접 선…. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성

노트를 그래프로 엮다 보면 금방 다음 욕심이 생긴다. 처음에는 "이 문서와 저 문서가 이어져 있다"만으로 충분한데, 곧 어떻게 이어져 있는지를 알고 싶어진다. 그냥 언급한 것인지, 그 사람이 그 모임에 참석한 것인지, 그 프로젝트가 그 기술을 쓴 것인지는 전혀 다른 이야기다.

이걸 관계에 이름이 붙은 엣지, 줄여서 타입 있는 엣지라고 부른다. 그런데 내가 노트에 링크를 아무리 정확히 달아도 관계 이름이 전부 "언급함" 하나로만 찍히는 상태가 한동안 이어졌다. 원인은 표기법이 아니라 문서 종류를 선언하지 않은 것이었다.

관계 이름은 문서 종류에서 나온다

내가 쓴 도구는 링크를 볼 때 두 가지를 같이 본다. 하나는 어디를 가리키는지, 다른 하나는 가리키는 쪽 문서가 무슨 종류인지다. 관계 이름은 이 조합에서 결정된다.

예를 들어 "모임 종류의 문서"가 사람을 가리키면 참석함, "회사 종류의 문서"가 사람을 가리키면 재직함이 된다. 같은 사람을 가리켜도 출발점이 무엇이냐에 따라 관계가 달라진다. 종류를 모르면 도구가 할 수 있는 최선은 언급함이라는 가장 약한 이름을 붙이는 것뿐이다.

다이어그램 설명. 도착지가 같은 사람 문서인데도 출발지 문서의 종류에 따라 관계 이름이 셋으로 갈린다. "종류 = 모임"에서 나가면 참석 관계, "종류 = 회사"에서 나가면 재직 관계가 된다. 여기서 핵심은 맨 오른쪽 경로다 — 종류를 적지 않으면 링크가 사라지지는 않지만 가장 밋밋한 이름으로 내려앉는다. 오류가 아니라 조용한 품질 저하라서 알아채기 어렵다. "언급함" 엣지만 잔뜩 쌓인 그래프는 사실상 타입이 없는 그래프와 같다.

종류는 자동으로 정해지지 않는다 — 폴더만으로는 부족했다

여기서 내가 오래 착각한 지점이 있다. 나는 meetings/라는 폴더에 모임 기록을 모아 뒀으니 도구가 알아서 "모임 종류"로 읽을 거라고 생각했다. 실제 판정 규칙을 열어 보니 그렇지 않았다.

// 파일 경로만 보고 문서 종류를 추정하는 규칙 (발췌)
if (lower.includes('/people/'))    return 'person';    // 사람
if (lower.includes('/companies/')) return 'company';   // 회사
if (lower.includes('/projects/'))  return 'project';   // 프로젝트
if (lower.includes('/sources/'))   return 'source';    // 출처
return 'concept';                                      // 그 외 전부 — 기본값

코드 설명. 경로에 /people/이 들어 있으면 사람 문서, /companies/면 회사 문서로 본다. 그런데 이 목록을 끝까지 읽어도 모임(meeting)에 해당하는 줄이 없다. 모임 종류는 도구 안에 분명히 존재하고 참석함 관계를 만드는 근거로 쓰이는데, 경로 규칙으로는 절대 그 값이 나오지 않는다. meetings/ 폴더에 넣든 말든 마지막 줄의 기본값인 "개념 문서"로 떨어진다.

정리하면 이렇다. 폴더 이름은 일부 종류만 알려 주고, 나머지는 문서가 직접 말해 줘야 한다. 폴더 규칙에 없는 종류를 쓰고 싶다면 방법은 하나뿐이다.

문서 머리에 두 줄을 적는다

해결책은 노트 맨 위 메타데이터 영역(frontmatter — 문서 본문 앞에 ---로 감싸 적는 속성 블록)에 종류와 대상을 직접 선언하는 것이다.

---
title: "8월 독서 모임 — 데이터 중심 애플리케이션 설계 3장"
type: meeting          # 종류를 직접 선언한다. 폴더 이름으로는 이 값이 안 나온다
attendees:             # 이 목록이 '참석함' 관계가 된다
  - 이수민
  - 박도현
---

코드 설명. type: meeting 한 줄이 이 문서를 모임으로 승격시키고, 그제서야 attendees 목록이 참석함 관계로 해석된다. 두 줄이 세트다 — attendees만 적고 type을 빠뜨리면 목록은 그냥 문자열로 남고 아무 엣지도 생기지 않는다. 반대로 type만 적고 목록이 없으면 선언만 있고 관계가 없다. 이름을 본문이 아니라 메타데이터에 적는 이유는 뒤에서 다시 짚는다.

여기서 앞 글에서 다룬 함정이 그대로 따라온다. 이수민이라는 사람 문서가 실제로 존재해야 관계가 만들어진다. 없으면 목록에 이름이 적혀 있어도 엣지는 생기지 않는다. 그래서 실무 순서는 사람 문서 만들기 → 모임 문서에 종류·참석자 적기가 된다.

그래서 무엇을 할 수 있게 되나

타입이 붙으면 그전에는 물어볼 수조차 없던 질문이 열린다.

다이어그램 설명. 관계 이름으로 걸러 낸 뒤 그 방향으로만 따라가는 질의다. "이수민이 참석한 모임 전부"에서 출발해 참석 관계만 통과시키면 모임 문서 목록이 그대로 떨어진다. 이 질문이 왜 특별하냐면 답이 순위가 아니라 목록이기 때문이다. 검색은 "이수민과 관련 있어 보이는 문서"를 점수순으로 주지만 어디서 끊어야 전부인지 말해 주지 않는다. 관계를 따라가면 빠짐이 없다는 보장이 생긴다. 대신 그 보장은 공짜가 아니라 type과 attendees를 적어 둔 대가다.

어디까지 적을 가치가 있나

모든 노트에 종류와 관계를 선언하자는 얘기는 아니다. 나는 내 기록을 실제로 세어 보고 범위를 좁혔다. 참석자를 표 형태로 정리해 둔 노트는 전체의 극히 일부인 61건이었고, 정작 가리킬 사람 문서는 0개였다. 즉 관계를 적기 전에 만들어야 할 개체 문서가 먼저 없는 상태였다.

여기서 얻은 기준이 하나 있다. "이 관계로 목록을 뽑아 볼 일이 실제로 있는가?" 있다면 적을 값어치가 있고, 없으면 종류 선언은 장식이다. 나는 "누가 어떤 모임에 있었나"는 가끔 필요했지만 "어떤 문서가 어떤 문서를 언급했나"는 한 번도 필요하지 않았다. 그래서 전자만 남겼다.

그리고 이 작업은 소급해서 몰아 하기보다 새 기록을 쓸 때 두 줄 더 적는 방식이 훨씬 싸다. 이미 쌓인 수천 개를 한꺼번에 손보려면 결국 자동 도구를 붙여야 하는데, 사람 이름 표기가 제각각인 기록에서 그걸 정확히 해내는 건 만만치 않다. 앞으로 쓸 기록에 두 줄을 얹는 건 그냥 습관 문제다.

정리 — 관계 이름은 선언한 만큼만 생긴다

링크를 정확히 달았는데 관계가 전부 "언급함"으로만 찍힌다면, 표기법이 아니라 출발지 문서가 자기 종류를 말하지 않은 것을 의심한다. 폴더 이름은 일부 종류만 알려 주고, 그 목록에 없는 종류는 문서가 직접 선언해야 한다.

개인 기록에 적용한다면 이렇게 시작하면 충분하다. 목록으로 뽑아 볼 일이 실제로 있는 관계 하나를 고르고, 그 관계에 필요한 개체 문서를 먼저 만들고, 앞으로 쓰는 기록의 머리에 두 줄을 얹는다. 세 단계를 건너뛰고 링크만 열심히 달면 그래프는 커지지만 아무것도 물어볼 수 없는 상태로 커진다.

---

참고한 공개 자료:

• gbrain — 개인 지식 브레인 오픈소스: https://github.com/garrytan/gbrain
• YAML frontmatter 개요(Jekyll 문서): https://jekyllrb.com/docs/front-matter/
• Obsidian 속성(properties) 문서: https://help.obsidian.md/Editing+and+formatting/Properties

---

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