제1장. 글로서리에서 클라우드로 - 우리가 다루는 자료의 변화

스타워즈를 한 단어로 설명하는 일은 불가능합니다.

"우주를 배경으로 한 선악의 대결"이라고 말하는 순간 정작 중요한 무언가가 빠져나가는데, 우선 포스가 빠집니다. 포스 없는 스타워즈는 스타워즈라고 부르기 어렵습니다. 그런데 포스를 넣으면 제다이 기사단이 자연스럽게 따라오고, 제다이를 넣으면 광선검이, 광선검을 넣으면 다스베이더가, 다스베이더를 넣으면 "나는 네 아버지다"라는 그 대사가 줄줄이 따라옵니다.

반란군과 은하 제국이 있고, 데스스타와 밀레니엄 팰컨이 있습니다. 이것들은 각각 따로 떨어져 존재하는 것이 아니라 서로 맞물려 있어서, 제다이와 다스베이더가 이어지고 포스와 광선검이 이어지며 반란군과 은하 제국이 이어집니다.

스타워즈는 이 연결망 전체입니다. 어느 한 단어가 아니라, 그 단어들이 엮여 있는 관계망이 곧 스타워즈입니다.

독자의 IP도 마찬가지입니다. 소설이든 게임이든 웹툰이든 룰북이든, 한 IP를 한 단어로 설명하면 거짓말이 되고 맙니다. 그 IP를 이루는 모든 단어들이 서로 어떻게 연결되어 있는가, 바로 그것이 그 IP입니다.

라이브러링이라고 부르는 작업은 이 관계망을 의도적으로 짓는 일입니다. 창작자의 머릿속에만 살아 있던 관계망을 꺼내어 눈으로 볼 수 있고 손으로 만질 수 있는 자료로 만드는 작업이며, 이 글은 그 일을 14장에 걸쳐 안내합니다.

자료가 연결되지 않는다는 것

한 IP를 5년쯤 운영해 온 사람의 책상을 떠올려 봅니다.

룰북이 있다면 일곱 권쯤 쌓여 있을 텐데, 본편이 1판과 2판, 3판으로 갈렸고 그 사이에 보조 자료집이 두어 권 끼어 있으며 한 번 갈아엎으려다 만 0판이 한 권 남아 있는 식입니다. 단편이 누적되어 있다면 폴더 안에 백 편을 가뿐히 넘기고, 외부 위키도 한쪽 모니터에 떠 있을 겁니다. 5년 전에 누군가 시작해 두었다가 손이 멈춘 페이지가 1천 개 가까이 쌓여 있지만 그중 살아 있는 페이지는 200개도 되지 않고, 기획서 폴더를 열어 보면 같은 이름의 파일이 버전을 달리해 서른 장쯤 들어 있습니다. v1.0, v1.1, v1.1_수정, v1.2_최종, v1.2_최종_재최종 같은 이름으로 말입니다.

이런 책상 앞에서 새 단편을 쓰려고 하면 곧장 사소한 질문들에 발이 묶입니다. 3년 전 룰북에 나왔던 그 인물의 이름이 무엇이었는지, 그 인물의 소속 세력이 기획서 어디에 적혀 있었는지, 그 세력과 적대하는 집단이 어느 단편에서 처음 등장했는지를 떠올려야 하는데, 이 질문들에 답하려면 일곱 권의 룰북과 백 편의 단편을 일일이 뒤지는 수밖에 없습니다. 검색이 되지 않고 링크가 없으며, 같은 단어가 어느 자료에도 일관되게 정리되어 있지 않기 때문입니다.

결국 작가는 비슷한 이름의 새 인물을 만들거나, 설정을 약간 바꿔 기존 인물로 쓰거나, 아니면 그냥 넘어가게 됩니다. 그러는 사이 IP 안에는 작은 모순이 쌓이기 시작해서, 한 인물이 두 이름을 갖고 한 사건의 날짜가 두 권에서 어긋나며 한 장소의 묘사가 전편과 후편에서 달라집니다. IP가 커질수록 이 모순의 양도 함께 불어납니다.

이것이 자료가 흩어진다는 문제의 실체입니다. 용어가 없어서 생기는 문제가 아니라, 관계가 없어서 생기는 문제입니다.

오래된 문제

이 문제는 새로운 것이 아닙니다. 톨킨은 수십 년에 걸쳐 손으로 쓴 방대한 노트를 남겼지만 그 자료가 체계적으로 관리되지 않은 탓에, 사후에 아들 크리스토퍼가 그것을 정리하는 데 다시 수십 년이 걸렸습니다. 프랭크 허버트의 《듄》 세계관 역시 아들이 시리즈를 이어 가면서 재구성에 적잖은 어려움을 겪었습니다.

웹소설과 웹툰의 시대로 오면 이 문제는 훨씬 큰 규모로 불거집니다. 수백 화를 연재하는 동안 수십 명의 인물과 수백 개의 고유 용어를 일관되게 관리해야 하는데, 팬들이 먼저 나서서 위키를 만들어 주기는 하지만 그것은 어디까지나 독자의 자료일 뿐 작가의 내부 자료가 되지는 못합니다. 거기에는 독자의 해석과 오독이 섞여 들기 마련이고, 무엇보다 작가가 다음 화를 쓰면서 곁에 두고 참조할 도구로는 기능하지 않기 때문입니다.

한 IP의 자료가 한 곳에 정리되어 있지 않다. 이 문제는 지금도 풀리지 않은 채 남아 있습니다.

글로서리라는 첫 번째 답

이 문제에 대한 첫 번째 답은 글로서리, 곧 용어집입니다. 한 작품에 등장하는 고유 명사와 전문 용어, 세계관 키워드를 순서대로 나열하고 각 항목 옆에 짧은 정의를 붙인 표 한 장이 글로서리입니다.

글로서리를 만드는 작업 방식 자체는 누구에게나 익숙합니다. 한 작품을 시작하면 작가 노트 한쪽에 글로서리 페이지를 따로 두고 새 단어가 등장할 때마다 한 줄씩 더해 가는 식인데, 한 작품의 테두리 안에서만 보면 이 방식은 충분히 효율적입니다. 글로서리를 펼치는 것만으로 어떤 인물이 빠져 있고 어떤 기제가 아직 정의되지 않은 채 남아 있는지를 한눈에 확인할 수 있기 때문입니다.

그러나 작품이 두 편이 되는 순간 풍경이 달라지기 시작합니다. 두 번째 작품의 새 항목을 첫 작품의 글로서리에 추가해야 하는데, 그 가운데 누군가는 첫 작품에서 이미 한 줄로 언급된 적이 있을 수 있어 같은 인물인지 다른 인물인지를 먼저 결정해야 합니다. 같은 인물이라고 판단했다면 첫 작품의 한 줄을 두 번째 작품의 정보로 보강해야 하고, 작품이 다섯 편, 열 편으로 늘어나면 이런 결정의 양이 폭발적으로 불어납니다.

글로서리가 실패하는 이유는 단순히 양이 많아서가 아닙니다. 목록이라는 형식 자체가 IP 지식의 성격과 구조적으로 맞지 않기 때문입니다.

목록 형식의 결함은 두 가지입니다.

첫째, 항목과 항목 사이의 관계를 담을 수 없습니다. 한 인물이 어떤 장소에서 태어났는지, 어떤 사건에서 어떤 역할을 했는지 같은 관계는 "관련: A, B, C"라는 식으로 적어 둘 수는 있지만, 그 "A, B, C"가 각각 어떤 항목인지를 다시 확인하려면 목록을 처음부터 다시 넘겨야 합니다. 관계가 저장되어 있더라도 그 관계를 따라 이동하기가 불편한 것입니다.

이 점이 중요한 까닭은, IP 지식의 핵심이 사실이 아니라 관계에 있기 때문입니다. "어떤 인물이 어떤 이름을 가지고 있다"는 사실보다 "그 인물이 이 사건에서 저 인물과 왜 충돌했는가"가 훨씬 더 중요한 정보이고, 관계를 편하게 따라갈 수 없는 자료 형식은 바로 그 핵심을 표현하는 데 한계를 드러냅니다.

둘째, 목록은 단방향입니다. 인물 A의 항목에 "관련: 장소 B, 사건 C"라고 적어 두어도, 장소 B의 항목을 찾아갔을 때 "이 장소와 관련된 인물: A, D, E"라는 역방향 정보는 자동으로 나타나지 않습니다. 역방향 정보를 유지하려면 인물 A와 장소 B 양쪽에 같은 내용을 손수 적어 두어야 하는데, 항목이 늘어날수록 이런 수동 관리는 점점 비현실적이 됩니다.

실제 작업에서 이 두 결함이 어떻게 드러나는지 살펴봅니다. 어떤 IP에서 "헌스포드 사택"이라는 장소를 수정해야 할 일이 생겨 글로서리에서 그 항목을 찾아 고쳤다고 합시다. 그런데 헌스포드 사택에서 일어난 사건들, 그 사택을 배경으로 한 장면들, 그 사택이 등장하는 인물들의 이야기까지 모두 찾아 일관성을 맞추려면 결국 글로서리 전체를 처음부터 다시 읽어야 합니다. 항목들 사이에 연결이 없기 때문입니다.

연결이 없으면 한쪽을 고쳤을 때 그 변화가 다른 쪽에 어떤 영향을 주었는지 확인하기가 어렵습니다. 이것이 IP가 커질수록 작가들이 겪는 그 답답함의 구조적 원인입니다.

관계를 담는 형식

글로서리의 실패에서 출발한 대안은 항목과 항목을 직접 연결하자는 발상입니다.

백과사전을 펴 보면 "→ 참조: 항목명" 같은 표기가 붙어 있는데, 이렇게 항목을 직접 잇는 발상 자체는 사실 꽤 오래된 것입니다. 독자가 A를 읽다가 B로 넘어가고 다시 B에서 C로 넘어가는 연쇄를, 종이 백과사전도 나름의 방식으로 구현하려 했습니다.

이 발상을 완전히 실현한 것이 인터넷입니다. 월드와이드웹의 핵심 아이디어가 문서와 문서를 링크로 연결하는 것이고, 위키백과는 그 아이디어를 백과사전 형식에 적용한 결과입니다. "나폴레옹 전쟁"을 읽다가 "트라팔가르 해전"을 클릭하고 다시 "넬슨 제독"으로 넘어가는 연쇄가 가능하며, 어느 항목에나 "이 문서를 참조하는 문서"가 함께 표시되어 역방향 연결까지 확인됩니다.

흥미롭게도, 인기 IP는 자라날수록 결국 이런 링크된 사전의 모양에 가까워집니다. 저는 「전지적 독자 시점」을 그 예로 즐겨 드는데, 원작 웹소설과 웹툰과 영화가 각각 큰 항목으로 갈라져 서로 링크로 이어지고 한 인물에서 그가 속한 사건과 세계관 설정으로 곧장 건너뛸 수 있습니다. 인기 한국 웹소설도 결국 표제어끼리 링크된 사전으로 자라는 것입니다. 게임 쪽에서는 「리그 오브 레전드」의 제작사가 'Universe'라는 공식 로어 사이트를 직접 운영하면서, 챔피언 한 명에서 그가 속한 지역과 사건으로 바로 건너뛰는 링크된 캐논 데이터베이스를 마련해 두었습니다.

IP 자료 관리에 이 발상을 적용하면 다음과 같은 그림이 나옵니다. 한 인물의 페이지 안에 그가 관련된 사건과 자주 등장하는 장소와 그가 사용하는 기제가 모두 링크로 연결되어 있고, 사건의 페이지에는 그 사건에 얽힌 다른 인물들이, 장소의 페이지에는 그 장소를 배경으로 한 사건들이 다시 링크로 나열되어 있는 모습입니다.

이것이 IP의 자료를 목록이 아닌 망으로 관리하는 발상이고, 이 연결된 망을 키워드 클라우드라고 부릅니다. 글로서리가 연결 없는 목록이라면, 키워드 클라우드는 그 키워드들이 서로 연결된 관계망입니다.

여기서 링크 자체가 곧 정보입니다. 두 항목 사이에 링크가 있다는 것은 이 둘이 IP 안에서 어떤 방식으로든 연관된다는 편집자의 판단을 담고 있고, 그래서 연결의 밀도가 높은 항목은 IP의 핵심에, 연결이 거의 없는 항목은 주변부에 놓이게 됩니다. 링크를 따라가다 보면 IP의 지형이 자연스럽게 드러납니다.

그래프 뷰를 처음 띄운 날

이 발상을 실현하는 도구가 있습니다. 옵시디안(Obsidian)이라는 노트 도구입니다.

옵시디안은 사용자가 만든 모든 노트를 한 작업 폴더 안에 .md 파일 형태로 보관합니다. .md는 마크다운이라는 형식의 확장자로, 평문 텍스트에 가벼운 부호 몇 개를 더해 제목과 강조와 링크를 표시하게 해 주는 형식입니다. 워드 파일처럼 무거운 형식이 아니라 메모장으로도 열리는 가벼운 텍스트입니다.

옵시디안은 이 .md 파일들을 [[항목 이름]] 표기로 자유롭게 연결시켜 주는데, 이 표기를 보통 wikilink라고 부릅니다. wikilink로 이어진 연결망을 옵시디안은 그래프 뷰라는 화면으로 한 번에 펼쳐 보여 주어서, 점들이 화면 위에 떠 있고 그 점들 사이에 선이 걸려 있는 그림이 나타납니다.

5년치 자료를 옵시디안에 옮기고 처음 그래프 뷰를 띄운 날이 있었습니다.

그 전까지는 자료가 얼마나 있는지조차 가늠하지 못했습니다. 글로서리에 적힌 항목 수는 알고 있었지만 그 항목들이 서로 어떻게 연결되어 있는지, 어떤 인물이 이 IP의 실제 중심에 있고 어떤 인물이 예상과 달리 주변부에 있는지, 어떤 사건이 가장 많은 표제어와 이어져 있는지, 어떤 개념이 이 세계관을 가장 깊이 떠받치고 있는지는 알 길이 없었습니다.

그래프 뷰를 띄우자 비로소 이것들이 보이기 시작했습니다. IP의 어느 영역이 빽빽하고 어느 영역이 비어 있는지, 어떤 인물이 생각보다 훨씬 많은 표제어와 연결되어 있고 어떤 인물이 외따로 떨어져 있는지가, 글로서리에서는 끝내 보이지 않던 자료의 풍경으로 한눈에 들어왔습니다.

글로서리에서 클라우드로 넘어온 것은 바로 그 순간이었습니다.

라이브러링이라는 작업

한 IP의 자료를 클라우드로 짓는 이 작업을 **〈라이브러링〉**이라고 부릅니다.

라이브러리(library)가 도서관 또는 사전을 뜻한다면, 라이브러링(librarying)은 그 사전을 짓는 작업을 동사형으로 만든 말입니다. 한 IP의 도서관을 짓는 일을 라이브러링이라고 부르는 것입니다.

이 호칭에는 작은 의도가 담겨 있습니다. 도서관이 한 번 세워졌다고 끝나지 않듯이 라이브러링도 한 번 짓고 끝나는 작업이 아니어서, 새 책이 들어오면 분류 체계를 살펴 어디에 둘지 결정하고 책장이 차면 새 책장을 들이며 분류가 흐트러지면 한 번씩 정리하게 됩니다. 도서관 운영이 그렇듯, 한 IP의 키워드 클라우드도 살아 움직이는 자료입니다.

도서관이라는 비유에는 또 하나의 의미가 있습니다. 도서관은 책을 그냥 쌓아 두지 않고 분류해서, 정해진 기준에 따라 모든 책에 번호를 매기고 위치를 지정합니다. 이 분류가 없으면 도서관은 그저 창고일 뿐이고, 책이 아무리 많아도 찾을 수 없다면 없는 것과 다르지 않습니다.

라이브러링도 마찬가지입니다. 키워드를 쌓아 두는 것이 목표가 아니라 분류하고 연결하고 찾을 수 있게 만드는 것이 목표이며, 그 목표를 향한 4단계 작업이 라이브러링의 본체입니다.

위키 만들기가 아니다

여기서 오해 하나를 끊어 두고 싶습니다. 옵시디안으로 위키를 만드는 법은 이미 흔해서 검색하면 수십 개가 쏟아져 나오지만, 라이브러링은 그 위키 만들기가 아닙니다. 차이는 그릇이 아니라 자르는 법에 있습니다.

라이브러링은 키워드를 가나다순이나 등장순으로 늘어놓지 않고 서사적 기능으로 가릅니다. 이 단어가 인물인가, 장치인가, 가치인가를 먼저 묻는 것입니다. 그 위에 IP마다 다르게 설계한 세계관축을 교차시키면, 「공동」에서 '협회와 얽힌 인물 표제어만' 또는 '던전에 딸린 사물 표제어만' 같은 두 좌표 검색이 가능해집니다. 분류 기준이 하나뿐인 사전으로는 할 수 없는 일입니다.

그래서 결과물의 위상이 다릅니다. 팬 위키가 독자의 참조용이고 메모 앱의 볼트가 개인의 기억 보조라면, 라이브러링이 짓는 Vault는 제작자가 IP 전체를 운영하는 단 하나의 원본입니다. 새 단편도, 새 캐릭터도, 외국어 번역도, 백과사전도 모두 이 한 권을 통과해 나옵니다. 그릇은 같은 옵시디안이어도, 무엇을 어떻게 담는가가 다른 것입니다.

사람이 읽는 그래프와 기계가 읽는 그래프

이 지점에서 라이브러링은 지식그래프라는 더 큰 흐름과 닿습니다. 위키데이터와 그 바탕 도구인 Wikibase를 보면, 사람 여럿이 같은 지식을 협업으로 고치되 그 결과가 기계도 읽을 수 있는 구조화 데이터로 남습니다. 사람은 항목의 이름과 설명을 읽고, 기계는 그 항목의 속성과 관계를 읽습니다. 같은 자료를 사람과 기계가 서로 다른 방식으로 읽는 것입니다.

라이브러링의 Vault는 당장 그런 구조화 데이터베이스를 만들려는 작업은 아닙니다. 옵시디안 .md 파일은 사람이 읽기 쉬운 쪽에 더 가까우며, 제작자가 창작 도중 곧바로 열어 볼 수 있어야 합니다. 다만 표제어, 별칭, 9분류, 세계관축, 관련키워드, 출처를 일정한 필드로 나누는 순간, 이 Vault도 기계가 읽을 수 있는 지식그래프의 성격을 조금씩 갖기 시작합니다.

그래서 라이브러링을 "위키 만들기"라고 부르면 작아지고, "완성된 지식그래프 시스템"이라고 부르면 과해집니다. 정확히는 그 사이에 있습니다. 사람의 손에 맞는 옵시디안 Vault로 시작하되, 장기적으로는 구조화 데이터와 지식그래프로 넘어갈 수 있는 형태로 IP의 관계망을 정리하는 작업입니다.

4단계의 흐름

라이브러링의 입력으로는 룰북과 단편, 기획서, 외부 위키, 대본처럼 흩어진 문서들이 모두 들어오고, 출력으로는 옵시디안 위키가 나옵니다. 그 사이를 잇는 것이 1차 추출, 2차 통합, 3차 골격 빌드, 4차 서술 집필이라는 네 단계입니다.

1차 추출은 모든 입력에서 키워드를 끌어내는 단계입니다. 한 룰북에 등장하는 모든 인물과 장소, 사물, 사건, 장치, 개념, 가치를 9가지 분류에 따라 빠짐없이 적어 두되 중복은 신경 쓰지 않고, 같은 인물이 다른 표기로 등장하더라도 일단 그대로 끌어냅니다. 한 IP의 1차 추출 결과는 5,000행에서 15,000행에 이르는 거대한 표가 됩니다.

그 표가 2차 통합으로 들어가면 같은 의미들이 한 표제어로 묶입니다. 표제어란 사전의 항목처럼 키워드가 정식으로 등록된 모양을 말하는데, 예를 들어 "흑공", "검은 연기", "Tenebre" 같은 세 표기를 한 표제어로 묶으면 그 행 안에 영어와 한국어, 정의, 관련 키워드, 번역 후보가 가지런히 정렬됩니다. 그 결과 5,000~~15,000행이 1,000~~2,000개의 표제어로 줄어듭니다.

표제어 표가 갖춰지면 3차 골격 빌드가 그 표를 옵시디안 .md 파일 1,500개로 변환합니다. 한 표제어가 한 .md 파일이 되고, 그 파일 안에는 정의와 상세 설명, 관련 키워드의 wikilink가 담기며 아직 글이 들어가지 않은 집필 공간이 남습니다.

마지막 4차 서술 집필이 그 집필 공간에 각 표제어의 글을 써 넣습니다. 한 표제어당 분량은 200자에서 1,000자 사이인데, 현대 헌터물 세계관 「공동」을 예로 들면 "농도는 게이트에서 스며든 마나의 밀도이다"라는 정의 한 줄에 그치지 않고 그 개념이 이 IP의 세계 안에서 어떤 의미를 갖는지를 한 흐름으로 풀어내는 글입니다. 1,500개의 집필 공간이 이런 서술로 채워지고 나서야, 비로소 한 IP의 키워드 클라우드가 완성됩니다.

1차와 2차, 3차의 본질이 기계적 정리라면 4차의 본질은 집필이고, 이 두 본질의 차이가 작업의 성격을 갈라놓습니다. 그리고 바로 이 차이가 이 글에서 가장 중요하게 다루는 주제, 곧 AI 작업 동료와의 협업의 결을 결정합니다.

두 손으로 짓는 작업

1,500개의 .md 파일을 한 사람이 다 지을 수 있을까요.

가능은 합니다. 다만 한 사람이 손으로만 끌고 가면 몇 달이 걸리는데, 손으로만 작업하던 시절에는 한 IP의 라이브러링에 6개월이 가깝게 들었습니다. 6개월이 걸리는 작업은 결국 자주 하지 않게 되고, 자주 하지 않으면 자료가 갱신되지 않으며, 갱신되지 않은 자료는 끝내 죽은 자료가 됩니다.

라이브러링을 지금처럼 정기적으로 운영할 수 있게 된 배경에는 두 가지 변화가 있습니다. 첫째는 절차의 정리입니다. 4단계의 흐름을 세우고 각 단계의 입력과 출력과 합격선을 미리 정해 두었습니다. 둘째는 AI 작업 동료의 도입입니다.

AI가 없어도 라이브러링은 작동합니다. 방법론 자체가 AI와 무관해서, 4단계의 파이프라인도, 9가지 분류 체계도, 두 좌표 축의 설계도, 13개 컬럼의 표제어 구조도 모두 그렇습니다. 낯선 용어가 한꺼번에 나왔지만 지금 외울 필요는 없고, 4장부터 9장에 걸쳐 하나씩 풀어 갈 것입니다. 여기서 중요한 점은 이것들이 AI가 등장하기 전에도 수작업으로 구현할 수 있는 방법이었고, 실제로 오랫동안 그렇게 해 왔다는 사실입니다.

다만 현재의 운영형 워크플로는 AI 작업 동료와 자동화 계약을 전제로 합니다. 사람 손으로도 가능한 방법을, 반복 가능한 시간 안에, 여러 IP에 다시 적용할 수 있게 만든 것이 지금의 라이브러링입니다. AI는 방법론을 대신하지 않고, 그 방법론을 지속 가능한 운영 시간 안으로 끌어옵니다.

AI는 이 방법론을 현실적인 시간 안에 운영할 수 있게 받쳐 주는 도구입니다. 1차 추출의 대량 처리, 동의어 후보 추출, 4차 서술 집필의 초고 작성이 AI의 몫이고, 사람이 손으로 하면 몇 달이 걸리는 일이 AI와 협업하면 9~16시간 안에 끝납니다.

그러나 결정적인 판단은 언제나 사람의 몫이어서, 어떤 표기가 같은 인물을 가리키는지, 표제어를 무엇으로 명명할지, 세계관축을 어떻게 설계할지, 집필이 합격선을 넘었는지를 끝내 정하는 것은 AI가 아니라 사람입니다.

AI가 1,500개를 쓴다고 하면 양산물처럼 들립니다. 정확히는 반대입니다. 제작자가 직접 쓴 대표 hub 몇 편이 나머지 표제어의 목소리를 정하기 때문입니다. AI는 손이고, 제작자는 목소리입니다. 손이 빠를 뿐, 무엇을 어떤 톤으로 쓸지는 목소리가 정합니다.

두 역할이 함께 갈 때 작업은 대략 하루 이틀, 9~16시간 안에 듭니다. 솔직히 첫 사이클은 그보다 더 걸리는데, 손에 익기 전에는 예상의 1.4배쯤 들고 두세 번째 사이클부터 이 범위에 안착합니다. 그래도 6개월이 며칠로 줄어든 셈입니다.

이 글은 매 단계에서 무엇을 주고받는지, 왜 위임하는지, 무엇이 좋아지는지, 어디까지를 사람이 직접 결정해야 하는지를 한 줄씩 짚어 갑니다. "AI를 쓰면 좋다"는 막연한 권유서가 아니라, 어디서 사람이 멈추고 어디서 도구가 시작하는지를 또렷이 구분해 보이는 글입니다.

자매 글과의 관계

이 글과 함께 이어지는 자매 글이 둘 있습니다. 〈서연각〉과 〈신규 캐릭터 빌드〉입니다.

〈서연각〉은 외국어 작품을 깊이 읽는 작업을 다룹니다. 제인 오스틴의 「오만과 편견」 같은 작품을 한 권 받아 들고, 번역과 각색에 들어가기 전에 인물과 사건, 세계관, 언어를 정밀하게 분석하고 문서화하는 6단계 작업을 14장에 걸쳐 풀어내는 글입니다. 〈신규 캐릭터 빌드〉는 0에서 한 인물을 빚어내는 작업을 다룹니다.

이 글은 두 자매 글이 모두 사용하는 공통 자료 기반을 짓는 일을 다룹니다. 〈서연각〉이 작품을 깊이 읽는 일이고 〈신규 캐릭터 빌드〉가 인물을 빚는 일이라면, 〈라이브러링〉은 그 깊이 읽기와 인물 빚기가 모두 통과하는 한 권의 사전을 짓는 일입니다. 자매 글을 아직 읽지 않았더라도 이 글은 독립적으로 따라올 수 있습니다.

앞으로의 흐름

14장의 흐름을 미리 펼쳐 둡니다.

1장에서는 글로서리에서 클라우드로, 목록에서 망으로, 한 사람에서 두 손으로 옮겨 가는 방향을 잡았습니다. 이어서 2장은 제작자와 AI 작업 동료의 역할을 더 자세히 들여다보고, 3장은 4단계 흐름의 전모를 한 번에 펼쳐 보입니다.

4장부터는 본격적인 작업입니다. 4장에서 1차 추출의 방법을, 5장에서 2차 통합을, 6장에서 두 분류 기준인 9분류와 세계관축을 다룹니다. 7장과 8장, 9장은 Vault의 모양에 관한 장으로, 7장은 3차 골격 빌드를, 8장은 hub와 leaf의 분류를 다룹니다. 이 글의 클라이맥스인 9장은 제작자가 직접 쓴 대표 hub 몇 편이 나머지의 톤을 정하고 AI 작업 동료가 그 톤으로 표제어들을 채워 가는 4차 서술 집필의 규격을, 한 장 전체에 걸쳐 자세히 들여다봅니다.

10장과 11장, 12장은 검증과 운영을 다루고, 13장은 실전 회고, 14장은 마무리 장입니다.

관계망으로 돌아오며

처음의 스타워즈로 돌아갑니다.

포스와 제다이, 광선검, 다스베이더, 반란군, 은하 제국이 서로 어떻게 연결되어 있는가가 곧 스타워즈입니다. 이 관계망은 조지 루카스의 머릿속에 먼저 있었고, 그 머릿속의 관계망이 룰북이 되고 영화 각본이 되고 캐릭터 설정집이 되었습니다. 그 자료들이 충분히 정리되어 있었기에, 스타워즈는 한 세대가 지난 뒤에도 다른 제작자의 손에서 일관되게 살아납니다.

v1.2_최종_재최종이 아직 폴더 어딘가에 있고 그 관계망이 한 곳에 정리되지 않은 상태라면, 14장을 모두 거치고 났을 때 비로소 보이는 것이 있습니다. 어떤 인물이 이 IP의 실제 중심에 있는지, 어떤 개념이 이 세계관을 가장 깊이 떠받치고 있는지가 눈에 들어옵니다.

그 관계망을 의도적으로 짓는 14장을 이제 시작합니다.