제7장. 골격 빌드, CSV가 옵시디안 파일이 되는 과정

13컬럼 CSV에 1,000개에서 2,000개의 표제어가 가지런히 정렬되어 있지만, 이 표는 아직 파일이 아닙니다. 옵시디안(Obsidian) 화면에는 아무것도 떠 있지 않아서 그래프 뷰도 없고 사이드바의 파일 목록도 비어 있으며, IP의 전체 어휘가 스프레드시트 한 장 안에 머물러 있을 뿐입니다.

이 표를 하나하나의 파일로 바꾸어 내는 작업이 3차 골격 빌드입니다. 표의 한 행이 곧 한 파일이 되고, 이 단계가 끝나야 비로소 Vault가 화면 가득 펼쳐집니다.

구조와 내용의 분리, 오래된 원칙 하나

책 한 권이 인쇄소에 들어가기 전, 원고를 받은 편집자는 빨간 펜으로 여백에 표시를 합니다. "이 제목은 14포인트 고딕체로", "이 단락은 들여쓰기 없이", "이 인용문은 이탤릭" 하는 식인데, 여기서 편집자가 표시하는 것은 내용이 아니라 구조입니다. 내용은 작가가 쓴 원문 그대로 두고, 그 원문을 어떻게 배열하고 표시할지만 별도로 기록하는 것입니다.

이것이 구조와 내용의 분리, 곧 내용을 손대지 않고도 디자인만 바꿀 수 있어야 한다는 원칙입니다. 같은 원고를 판형만 달리하여 문고판으로 다시 찍을 수 있어야 한다는 것이고, 컴퓨터가 등장하면서 이 원칙은 한층 또렷해졌습니다. 웹 페이지를 짜는 두 언어인 HTML과 CSS의 분업이 그 대표적인 예인데, HTML이 "이것은 제목이다, 이것은 단락이다"라며 글의 뼈대를 기술하면 CSS가 "제목은 이런 크기와 색으로, 단락은 이런 간격으로"라며 보이는 모양을 결정합니다. 그래서 같은 HTML에 다른 CSS를 입히면 전혀 다른 시각적 결과가 나옵니다. 데이터베이스도 다르지 않아서, 스키마는 어떤 칸이 있는지 그 구조를 정의하고 데이터는 그 칸에 실제로 들어오는 값입니다.

위키피디아의 인포박스가 이 원리를 가장 일상적으로 보여 줍니다. 어느 인물 문서를 펼쳐도 오른쪽 위 상자에 출생일, 국적, 직업, 배우자가 늘 같은 자리에 놓여 있습니다. 인물 정보 틀이라는 하나의 템플릿이 그 구조를 정해 두고, 각 인물 문서는 그 틀 안에 자기 데이터를 채워 넣을 따름입니다. 틀 하나를 살짝 고치면 그것을 쓰는 수만 페이지에 한꺼번에 반영되는데, 이런 일이 가능한 것도 구조와 내용을 갈라 둔 덕분입니다.

라이브러링의 3차 골격 빌드는 바로 이 원칙을 옵시디안 파일 안에 구현합니다. 마크다운(.md) 파일의 윗부분인 frontmatter가 구조를 맡고 아랫부분인 본문 텍스트가 내용을 맡는데, 둘은 또렷이 갈라진 채 저마다 다른 역할을 합니다.

결정적 변환이라는 말의 의미

3장에서 3차 골격 빌드를 "결정적 자동화"라고 불렀습니다. 1차 추출은 AI 작업 동료가 문서를 읽고 키워드를 끌어내는 단계여서 같은 문서를 다시 추출하면 결과가 조금씩 달라질 수 있고, 2차 통합도 동의어 후보를 다시 추려 내면 약간 다른 묶음이 나오곤 합니다. 두 단계 모두 AI 특유의 확률적 변수를 안고 있는 것입니다.

3차 골격 빌드는 성격이 다른데, 13컬럼 CSV를 받아 마크다운 파일로 변환하는 규칙이 또렷하게 정해져 있기 때문입니다. 어떤 컬럼이 어느 frontmatter 필드로 들어가고 어떤 컬럼이 본문의 어느 자리에 놓이는지가 처음부터 고정되어 있어서, 같은 CSV에 같은 자동화 도구를 돌리면 언제나 똑같은 결과가 나옵니다. 이것이 결정적 변환입니다.

현재의 운영 방식에서는 이 결정적 변환을 단순한 "스크립트 실행"으로 두지 않고 하나의 계약으로 다룹니다. 무엇을 입력으로 받고, 무엇을 출력하며, 언제 실행하고, 무엇을 통과 조건으로 삼는지가 미리 정해져 있습니다. 표제어 파일 수가 2차 CSV 행 수와 맞는지, YAML이 깨진 파일은 없는지, 파일명 충돌은 없는지, 세계관축 필드가 빠진 파일은 없는지를 빌드 직후 바로 확인하는 것까지가 3차 골격 빌드의 일부입니다. 파일을 만들고 나서 나중에 검사하는 것이 아니라, 만들면서 동시에 검증 리포트를 받는 구조입니다.

이 단계에서 제작자가 할 일은 거의 없어 보입니다. 다만 "없다"가 아니라 "없어 보인다"라는 점이 중요한데, 그 차이가 사실은 제작자의 자세에서 갈리기 때문입니다. 원칙대로 하자면 자동화가 내놓은 1,500개의 결과를 하나도 빠뜨리지 않고 검수해야 하지만, 실제로 그 전부를 일일이 들여다보면 극심한 비효율과 병목이 생기고, 그렇다고 자동화가 내놓는 대로 손을 놓아 버리면 결과물은 제대로 설 수 없습니다. 손이 많이 가는 변환을 자동화에 넘기는 까닭도 3차에서 사람이 완전히 빠져도 된다는 뜻이 아니라, 정작 사람의 손길이 꼭 필요한 4차 서술 집필에 힘을 아껴 두기 위해서입니다.

결정성은 장점과 위험을 함께 가집니다. 변수가 없으니 1,500개의 파일이 사람의 손을 거치지 않고도 한꺼번에 만들어지지만, 변환 규칙에 결함이 하나라도 있으면 1,500개 파일이 똑같은 결함을 한꺼번에 떠안습니다. 한 곳의 실수가 1,500번 복제되는 셈입니다. 그래서 빌드가 끝나면 사람이 한 차례 검수를 합니다. 결함은 개별 파일이 아니라 규칙 단계에서 고치면 되므로, 규칙을 바로잡고 빌드를 다시 돌리면 1,500개 파일이 일괄로 수정됩니다. 규칙을 잘 세우고, 자동화가 처리하고, 사람이 결과를 확인하는 흐름입니다.

frontmatter, 기계가 읽는 계약서

골격 빌드로 만들어지는 마크다운 파일 하나의 구조를 살펴보겠습니다. 로맨스 판타지 세계관 「향궁」의 표제어 "조향사"를 예로 들겠습니다.

---
title: 조향사
aliases: [조향가, 향사]
category: 인물
worldbuilding_axis: 향
english: Perfumer
romanization: Johyangsa
version: 현행
tags:
  - category/인물
  - axis/향
  - version/현행
sources:
  - 룰북 3판 p.24
related:
  - "[[향]]"
  - "[[사교계]]"
  - "[[무후각]]"
---

**조향사는 향을 조합해 사람의 감정과 충성을 움직이는 기술자이다. 향이 곧 마법인 이 세계에서 조향사는 권력과 정보를 함께 쥔다.**

조향사는 [[향]]을 포집하고 증류해 매혹향과 충성향을 짓고, [[사교계]]에서 누구의 마음을 살지를 설계한다. 그러나 향에 면역인 [[무후각]] 앞에서는 어떤 조향도 통하지 않는다.

**번역**: Perfumer. 향궁의 조향사. 일반 향수 제작자가 아니라 향으로 감정과 충성을 조작하는 마법사 계층이므로, "perfumer" 단독으로는 뜻이 좁다. "scent-weaver" 또는 "scent-mage"로 의역하거나 원어 병기를 권장한다.

%% LLM %%

%% /LLM %%

%% 메모 %%

%% /메모 %%

파일의 윗부분, ---으로 감싸인 영역이 frontmatter입니다. YAML이라는 형식으로 쓰인 이 블록은 사람이 직접 들여다볼 일이 드물고, 대신 검색 기능과 자동화 도구가 이 필드들을 읽어 들입니다.

frontmatter를 "기계가 읽는 계약서"라고 부르는 데에는 이유가 있습니다. 사람은 "조향사"라는 글자만 보아도 맥락과 경험으로 그것이 향을 다루는 인물이며 인물 분류에 속한다는 것을 어렵지 않게 짐작하지만, 기계는 그렇게 하지 못해서 "이 파일의 분류는 인물이고, 속하는 세계관축은 향이다"라고 빠짐없이 명시해 주어야 합니다. frontmatter가 바로 그 역할을 맡아, category/인물이나 axis/향 같은 태그로 옵시디안에서 검색하면 해당 파일이 곧바로 추려집니다. 훗날 이 Vault를 바탕으로 새로운 자동화 도구를 만들 때도 그 도구는 frontmatter를 읽어 파일의 성질을 파악하므로, 지금 짜 두는 frontmatter는 당장의 작업만을 위한 것이 아니라 앞으로 이 IP와 함께 일할 모든 도구에게 건네는 약속의 문서인 셈입니다.

2차 CSV의 컬럼이 frontmatter 필드로 바뀌는 대응 관계는 하나하나가 또렷합니다. 대표키워드는 파일의 공식 이름인 title로, 이칭과 별칭은 대체 검색어 목록인 aliases로, 분류는 9분류 가운데 하나인 category로, 세계관축은 IP 고유의 축인 worldbuilding_axis로 들어갑니다. 영문명은 english, 로마자는 romanization, 버전상태는 version, 출처목록은 sources, 관련키워드는 wikilink 목록인 related로 옮겨집니다. 이렇게 대응이 일대일로 분명하기 때문에 이 변환은 온전히 자동화됩니다. 사람이 판단할 여지가 없습니다.

메타데이터라는 오래된 약속

frontmatter는 라이브러링만의 발명품이 아닙니다. 디지털 자료를 오래 다뤄 온 분야에서는 제목, 설명, 날짜, 형식, 출처, 관계 같은 정보를 본문 바깥에 따로 두는 방식을 메타데이터라고 불러 왔습니다. Dublin Core 같은 메타데이터 체계가 다루는 것도 결국 "이 자료의 이름은 무엇인가", "무엇에 관한 자료인가", "언제 만들어졌고 무엇과 관련되는가" 같은 기본 질문입니다.

라이브러링의 frontmatter도 같은 역할을 합니다. title은 이 표제어의 이름이고, aliases는 대체 이름이며, category와 worldbuilding_axis는 이 자료의 종류와 위치이고, sources는 어디에서 왔는지에 대한 기록입니다. 본문이 표제어의 의미를 설명한다면, frontmatter는 그 표제어 파일 자체가 어떤 자료인지를 설명합니다.

이 구분이 중요한 까닭은, 나중에 도구가 Vault를 읽을 때 본문 전체를 해석하지 않아도 되기 때문입니다. "향 축의 장치만 모아라", "폐기된 표제어만 찾아라", "출처가 룰북 3판인 항목을 뽑아라" 같은 질문은 frontmatter가 있으면 곧장 처리됩니다. 메타데이터가 단단하면 Vault는 읽기 좋은 문서 묶음에서, 검색하고 검증하고 재사용할 수 있는 자료 묶음으로 올라갑니다.

본문의 세 층

frontmatter 아래, --- 다음부터가 본문입니다. 본문은 세 층으로 이루어집니다.

정의는 굵은 글씨로 된 첫 단락으로, 2차 CSV의 정의 컬럼이 한두 문장으로 완결된 모양 그대로 옮겨 옵니다. 다른 표제어 파일에서 이 표제어를 참조할 때, 또는 AI 작업 동료가 이 파일을 맥락으로 읽어 들일 때 가장 먼저 눈에 들어오는 문장이 바로 이것입니다. 한 표제어의 핵심을 한두 문장으로 압축한 이 정의가 잘 다듬어져 있을수록 Vault 전체의 인용 품질이 높아집니다.

상세설명은 정의 다음에 오는 단락으로, 2차 CSV의 상세설명 컬럼이 들어오며 [[링크]] 형태로 관련 표제어가 연결되어 있습니다. 이 링크 하나하나가 Vault의 연결망을 짜는 가닥이어서, 상세설명 속의 [[향]]이라는 링크 하나가 "조향사" 파일과 "향" 파일 사이를 잇는 연결선이 되고 그래프 뷰에서는 점과 점을 잇는 선으로 나타납니다.

번역노트는 2차 CSV의 번역노트 컬럼에 담긴 내용으로, 훗날의 번역자에게 부치는 편지라 할 만합니다. 이 표제어를 어느 언어로 옮길 때 무엇을 주의해야 하는지, 어떤 번역어가 이미 승인되었는지, 직역이 불가능하다면 그 까닭은 무엇인지를 적어 둡니다.

이 세 층 아래에는, 골격 빌드 시점에는 비어 있는 채로 만들어지는 두 블록이 따라옵니다. LLM 블록과 메모 블록입니다.

LLM 블록, 비워 두는 이유

%% LLM %%부터 %% /LLM %%까지의 블록은 왜 비어 있을까요? 4차 서술 집필에서 비로소 서술이 채워질 블록이기 때문입니다. 한 표제어를 하나의 흐름으로 풀어내는 200자에서 1,000자 분량의 글이 여기에 담깁니다.

여기에는 더 중요한 이유가 있습니다. 3차 골격 빌드는 자동화이고, 자동화는 구조를 세울 수는 있어도 창작을 할 수는 없습니다. 정의는 2차 CSV에서 그대로 옮겨 오고 상세설명도 마찬가지여서 이 둘은 자동화가 처리할 수 있지만, LLM 블록에 들어갈 서술은 다릅니다. 이 서술은 표제어를 IP 세계 안에서 숨 쉬는 존재로 그려 내는 글입니다. "조향사는 향으로 감정과 충성을 움직이는 기술자이다"라는 정의와, "향으로 사교계의 마음을 모두 사들인 조향사가 자기 향이 통하지 않는 무후각 앞에서 난생처음 꾸미지 않은 반응을 마주한 순간"을 써 내려가는 서술은 성격이 전혀 다릅니다. 후자는 창작이며, 4차에서 이루어집니다.

3차 골격 빌드가 끝난 Vault는 사전입니다. 4차 서술 집필까지 마친 Vault는 살아 있는 IP 세계의 기억 저장소입니다. 그 차이를 만들어 내는 것이 바로 LLM 블록입니다. %% 기호는 옵시디안에서 "이 안은 출력에 드러내지 않는 주석"을 뜻하는데, LLM 블록과 메모 블록 모두 이 주석 기호로 감싸 작업 공간과 완성된 출력물을 갈라 둡니다.

멱등성, 두 번 실행해도 안전하게

멱등성(idempotency)이란 같은 연산을 여러 번 실행해도 그 결과가 단 한 번 실행했을 때와 똑같이 유지되는 성질을 가리킵니다. 이를테면 "전등 스위치를 누른다"는 멱등하지 않은데, 처음 누르면 켜지고 다시 누르면 꺼지기 때문입니다. 반면 "전등을 켜진 상태로 맞춘다"는 이미 켜져 있는 상태에서 한 번 더 그렇게 해도 결과가 그대로이므로 멱등합니다. 데이터베이스에 빗대 보면, 같은 데이터를 그대로 추가하는 INSERT는 두 번 넣으면 행이 두 개 생기니 멱등하지 않은 반면, 이미 있으면 갱신하고 없으면 새로 넣는 UPSERT는 같은 데이터로 두 번 처리해도 결과가 하나로 남으므로 멱등합니다.

라이브러링에서 멱등성은 왜 중요할까요? IP는 운영되는 동안 끊임없이 달라져서 새 책이 나오고 기존 설정이 손질되며 새 표제어가 더해지고, 2차 CSV가 갱신될 때마다 3차 골격 빌드를 다시 돌려야 합니다. 그런데 그 무렵이면 4차 작업에서 이미 %% LLM %% 블록에 서술 1,500개를 써 둔 상태이고, 골격 빌드를 다시 돌렸다고 해서 그 서술이 지워져서는 안 됩니다. 수백 시간을 들여 쓴 서술이 재빌드 한 번에 사라진다면 그야말로 재앙입니다.

라이브러링의 멱등 업데이트 규칙이 바로 이 문제를 풀어 줍니다. frontmatter와 정의, 상세설명, 번역은 재실행 때마다 덮어쓰기 방식으로, 2차 CSV를 기준으로 갱신합니다. 반면 %% LLM %% 블록과 %% 메모 %% 블록은 보존 대상으로 두어, 4차에서 써 넣은 서술과 작업자가 손본 편집을 건드리지 않습니다.

이 규칙이 어떤 결과를 낳는지 보겠습니다. 운영 도중 "조향사"의 공식 영문명이 "Perfumer"에서 "Scent-Weaver"로 바뀌었다고 합시다. 2차 CSV에서 해당 행의 영문명 컬럼을 고치고 3차 골격 빌드를 다시 돌리면 됩니다. 결과는 이렇습니다. "조향사" 파일의 frontmatter english 필드는 새 값으로 갱신되지만, LLM 블록 안에 이미 완성된 서술은 그대로 남습니다. 새로운 IP 콘텐츠가 발표되어 "잔향"이라는 표제어의 상세설명을 보강한 경우도 마찬가지입니다. 2차 CSV를 갱신하고 재빌드하면 상세설명은 새로워지되 LLM 블록은 손대지 않은 채 유지됩니다. 이 멱등성 규칙 덕분에 IP가 살아 있는 내내 Vault를 거듭 갱신해도 이미 완성한 창작 작업을 잃지 않습니다.

Stub 파일, 별칭에 고유한 파일명을 마련하는 방법

골격 빌드가 만들어 내는 것은 표제어 파일만이 아닙니다. Stub 파일도 함께 생성됩니다.

옵시디안에서 [[조향가]]라는 링크를 입력하면 무슨 일이 일어날까요? 옵시디안은 "조향가"라는 이름의 파일을 찾는데, 이때 frontmatter의 aliases 필드도 검색 대상에 들어가므로 "조향사" 파일의 aliases 목록에 "조향가"가 들어 있다면 검색은 그 파일로 이어집니다.

그런데 한 가지 함정이 있습니다. 옵시디안의 wikilink는 파일명을 기준으로 작동하는데, aliases가 검색에서는 잘 작동하더라도 [[링크]] 형태로 다른 파일에서 연결할 때는 파일명과 정확히 맞아떨어져야 합니다. 그래서 파일명이 "조향사"인데 [[조향가]]를 입력하면, 옵시디안은 "조향가"라는 파일이 없으므로 이 링크를 "아직 만들어지지 않은 파일"로 표시하고, 두 파일 사이의 연결선은 이어지지 못합니다.

Stub 파일이 이 문제를 풀어 줍니다. 별칭마다 파일을 하나씩 만들고, 그 파일이 대표 표제어 파일을 가리키도록 해 두는 것입니다.

---
title: 조향가
redirect: 조향사
type: stub
tags: [stub]
---

[[조향사]] 참조.

이제 [[조향가]]라는 링크를 입력하면 "조향가" 파일로 이어지고 그 파일이 다시 "조향사"를 가리켜, 끊겼던 연결이 비로소 이어집니다. 위키피디아를 떠올리면 이해가 쉬운데, 위키피디아에서 "Kimchi"라고 영어로 검색해도 "김치" 문서로 이어지는 것은 "Kimchi"가 "김치" 문서로 보내는 리다이렉트(redirect) 페이지이기 때문입니다. Stub 파일이 바로 이 리다이렉트 페이지에 해당합니다.

"조향사" 표제어의 별칭이 "조향가"와 "향사"라면 이 두 별칭에 대한 Stub 파일이 두 개 만들어지듯, 한 IP에 Stub 파일이 수백 개에서 수천 개씩 생기는 것은 지극히 정상입니다. 표제어 1,500개에 별칭이 평균 한두 개씩 달려 있다면 Stub 파일도 1,500개에서 3,000개가 되는데, 이 파일들은 표제어 파일과 같은 폴더에 하위 폴더 없이 나란히 놓이며 frontmatter의 type: stub으로 구분되어 그래프 뷰에서 따로 걸러 내거나 숨길 수 있습니다.

manifest 파일, 빌드의 영수증

3차 골격 빌드가 내놓는 산출물은 마크다운 파일들만이 아닙니다. 이 빌드의 결과를 요약하는 manifest 파일도 함께 만들어집니다. 파일명은 _vault_manifest.json이며, Vault 폴더와 같은 위치에 놓입니다.

manifest 파일은 소프트웨어 개발에서 쓰는 빌드 manifest와 같은 역할을 합니다. 애플리케이션을 빌드하면 어떤 파일들이 만들어졌고 각 파일의 크기와 해시값은 무엇인지를 기록한 파일이 함께 생성되는데, 배포할 때 이 manifest만 보면 어떤 버전이 어떤 상태인지 곧바로 파악할 수 있습니다. 라이브러링의 manifest도 같은 역할을 하되, 파일 해시 대신 IP의 어휘 통계를 담습니다.

manifest에는 프로젝트명, Vault 경로, 빌드 일시, 원본 CSV 파일명이 적히고, 세계관축 허용값 목록과 각 축의 표제어 수, 전체 표제어 수와 9분류별 표제어 수, 버전상태별 표제어 수, Stub 파일 수가 함께 기록됩니다. 여기까지가 Vault의 통계입니다.

여기에 두 가지가 더 붙습니다. 하나는 진행 상태입니다. 지금 이 Vault가 1차, 2차, 3차, 4차 가운데 어디까지 왔는지, 어느 배치가 완료되었고 어느 배치가 남았는지를 manifest가 기억합니다. 4차 집필이 중간에 끊겼다가 다음 날 이어질 때, 작업자는 기억에 의존하지 않고 manifest에서 pending 상태인 배치부터 다시 시작하면 됩니다. 다른 하나는 핸드오프 상태입니다. 이 Vault가 다음 작업에서 읽어도 되는 상태인지, 아직 검증 전인지, 마지막으로 언제 넘겨졌는지가 manifest에 남습니다.

보조 문서 카탈로그도 여기에 들어갑니다. 인물관계도나 연대기처럼 표제어 파일은 아니지만 Vault 소비자가 필요로 하는 문서들이 처음부터 manifest에 등록되어 있어야, 나중에 검증 단계에서 "만들기로 한 보조 문서가 실제로 있는가"를 확인할 수 있습니다. 예전에는 이런 보조 문서를 4차가 끝난 뒤 기억으로 챙기곤 했지만, 이제는 골격 빌드 시점부터 목록에 올려 둡니다.

manifest의 실용적 가치는 검수에 있습니다. 2차 CSV에 행이 1,847개 있었다면 빌드 후 표제어 파일도 1,847개여야 하는데, manifest를 펼치면 5초 안에 이를 확인할 수 있습니다. 분류별로 들여다보는 것도 가능해서, "인물" 분류에 표제어가 단 두 개뿐이라면 어딘가 잘못되었다는 신호이고 향을 배경으로 삼은 IP인데 향 세계관축 표제어가 열 개밖에 없다면 추출이 모자랐다는 신호입니다. 게다가 4차 서술 집필을 여러 회차로 나누어 진행할 때는 manifest가 어디서부터 이어 가면 되는지를 알려 줍니다.

manifest는 또 하나의 역할을 합니다. 이 Vault가 어떤 입력에서, 어떤 활동을 거쳐, 어떤 담당자의 검수를 지나 현재 상태가 되었는지를 남기는 이력표입니다. W3C PROV가 데이터의 신뢰성을 판단하기 위해 생성 과정과 관련 주체를 기록하듯, 라이브러링의 manifest도 원본 문서, 추출, 통합, 빌드, 검증, 핸드오프의 흐름을 한 줄로 잇습니다. 여기서 원본 문서와 CSV와 .md 파일은 산출물이고, 추출과 병합과 빌드는 활동이며, 사람과 AI 작업 동료와 자동화 도구는 그 활동에 참여한 주체입니다.

이렇게 보면 manifest는 단순한 통계 파일이 아닙니다. "이 Vault가 지금 믿을 만한가"라는 질문에 답하는 증거 묶음입니다. 언제 빌드되었는지, 어떤 CSV에서 왔는지, 어떤 검증을 통과했는지, 다음 작업에 넘겨도 되는 상태인지를 남겨 두어야, 몇 달 뒤에 Vault를 다시 열었을 때도 그 상태를 판단할 수 있습니다.

골격 빌드를 마치고 처음으로 Vault를 마주하면

1,500개의 파일이 한꺼번에 만들어져 폴더 안에 쌓이던 순간을 지금도 기억합니다. 바로 직전까지 화면에는 스프레드시트 한 장뿐이었는데, 자동화를 실행하고 잠깐 기다리자 사이드바가 파일 이름으로 빼곡히 채워졌습니다. 줄곧 표의 한 칸에 머물던 단어들이 저마다 고유한 파일명을 가진 파일로 바뀐 것입니다. 왼쪽 사이드바에는 1,500개에서 2,000개의 파일이 가나다순으로 늘어서 있습니다. 파일 이름을 따라 스크롤을 내리다 보면 이 IP 안에 어떤 존재들이 살고 있는지가 어렴풋이 느껴집니다. "매혹향", "무풍의 골짜기", "무후각", "문향", "봉향", "사교계", "잔향"처럼 말입니다.

파일 하나를 눌러 펼치면 정의와 상세설명이 들어 있고, 그 아래 LLM 블록은 아직 비어 있습니다. 사전의 뼈대만 갖춰진 셈입니다.

그래프 뷰를 누르면 화면이 한 번에 바뀌어, 1,500개의 점과 그 사이를 잇는 선들이 화면 가득 펼쳐집니다. 점 하나가 표제어 하나이고 선 하나가 wikilink 하나이며, 점들은 9분류에 따라 인물은 파란색, 장소는 초록색, 장치는 주황색으로 서로 다르게 구분됩니다. 그 가운데 선이 유독 많이 모여드는 점이 곧 중심 표제어, 즉 hub 후보입니다.

이 그래프를 처음 볼 때의 감각은, 여러 갈래의 도시 골목을 각각 걸어 다니기만 하다가 하늘 위에서 처음으로 그 전체 지도를 내려다보는 느낌과 비슷합니다. 표제어를 하나씩 읽을 때는 보이지 않던 구조가 그래프 뷰에서는 한눈에 들어옵니다. 어떤 표제어가 이 IP의 중심에 있고 어떤 표제어가 가장자리에 있는지, 어떤 분류에서 표제어가 유난히 많이 나왔는지가 그렇습니다. 이 그림이 바로 라이브러링의 3차 산출물입니다. 그리고 이 그래프가 4차 서술 집필의 지도가 됩니다. 선이 많이 모인 점부터 집필을 시작하면 됩니다.

3차에서 사람이 하는 일

3차 골격 빌드는 거의 자동으로 흘러갑니다. 그럼에도 사람이 직접 챙겨야 하는 일이 셋 있습니다.

빌드를 마친 뒤의 manifest 검수는 숫자를 맞춰 보는 일입니다. 2차 CSV의 행 수와 마크다운 파일 수가 정확히 일치하는지, 어떤 분류나 세계관축에서 표제어 수가 예상과 크게 어긋나지는 않는지, Stub 파일 수가 합리적인 범위 안에 들어 있는지를 살핍니다. 3분에서 5분이면 끝납니다.

Vault 파일 무작위 표본 검수는 사이드바에서 파일 열 개에서 스무 개를 무작위로 골라 펼쳐 보는 일로, frontmatter 필드가 제대로 채워졌는지, 정의가 표제어에 들어맞는지, 상세설명 속의 wikilink가 올바르게 걸렸는지를 확인합니다. 5분이면 충분합니다. 이 표본 검수에서 이상한 점이 발견되면 변환 규칙에 문제가 있거나 2차 CSV의 데이터 품질에 문제가 있다는 뜻이므로, 원인을 규칙 단계에서 찾아 바로잡고 재빌드해야 합니다. 파일을 하나씩 손으로 고치는 것은 잘못된 접근입니다.

빌드 직후 자동검증 확인. 상세설명 안에 [[링크]]가 있는데 그 대상 파일이 존재하지 않는 경우가 곧 끊어진 링크(dangling link)인데, 대상 파일이 없으면 옵시디안 그래프 뷰에서 그 링크는 아무 점에도 닿지 못한 채 빈 곳을 가리킵니다. 이런 링크 무결성뿐 아니라 .md 파일 수, frontmatter 파싱, 파일명 충돌, worldbuilding_axis 누락은 자동 검사로 모두 찾아낼 수 있습니다. 무엇보다 시급히 손봐야 할 문제이므로 발견하는 즉시 바로잡습니다. 끊어진 링크는 대개 두 가지에서 비롯됩니다. 하나는 2차 CSV에서 관련키워드를 입력할 때 표제어의 대표키워드와 다른 표기를 쓴 경우로, "무후각"이라고 써야 할 것을 "무후자"라고 입력하는 식입니다. 다른 하나는 관련키워드로 연결은 했지만 정작 그 키워드가 표제어로 등록되지 않은 경우입니다. 앞의 경우는 표기를 통일해 해결하고, 뒤의 경우는 그 키워드를 표제어로 추가할지 검토합니다.

골격이 세워지고 나면

3차 골격 빌드는 라이브러링의 파이프라인 가운데 사람의 손길이 가장 적게 드는 단계입니다. 창의적 판단이 거의 필요 없고, 자동화가 묵묵히 일을 처리합니다. 이 단계가 끝나면 Vault가 처음으로 눈에 보이는 형태를 갖춥니다.

8장에서는 hub와 leaf를 다룹니다. 그래프 위의 점들 가운데 어떤 점이 중심에 해당하는 hub이고 어떤 점이 말단에 해당하는 leaf인지를 무엇을 기준으로 가리는지, 그리고 집필을 hub에 먼저 집중해야 하는 까닭을 함께 짚어 보겠습니다.