제11장. Vault의 평생 - 역류와 운영 사이클

검증을 마친 Vault가 출구 작업으로 넘어가면, 그 Vault를 바탕으로 단편이 집필되고 캐릭터 시트 작업이 진행됩니다. 그렇다면 일단 한 번 만들어 둔 Vault는 이제 역할을 다한 것일까요?

그렇지 않습니다. 그리고 이 대답은 라이브러링 운영의 가장 중요한 원칙 하나에서 나옵니다.

완성이라는 개념 자체의 오류

"Vault 완성"이라는 표현에는 완성된 Vault가 더 이상 변하지 않는 안정된 상태가 된다는 가정이 암묵적으로 깔려 있습니다.

그런데 IP는 변합니다. 새로운 작품이 나오고 설정이 수정되며, 새로운 인물이 등장하는가 하면 기존 인물이 새로운 면을 드러내기도 해서, IP가 살아 있는 한 IP의 어휘도 함께 변해 갑니다.

Vault를 한 번 완성하면 끝나는 것으로 여기면 다음과 같은 일이 벌어집니다. 처음 만들 때 공을 들여 1,500개의 파일을 갖추었는데, 2년 사이에 새 작품이 10편이나 나왔는데도 Vault는 처음 상태 그대로입니다. 집필자가 새 어휘를 Vault에서 찾아보지만 거기에 없으니, 찾을 수 없는 Vault를 쓰지 않게 되고 쓰이지 않는 Vault는 갱신할 이유마저 사라집니다. 그렇게 Vault는 방치된 끝에 더 이상 기능하지 못하는 상태에 이릅니다.

위키피디아를 떠올려 보면 도움이 됩니다. 위키피디아는 한 번도 "완성"된 적이 없어서, 영문 위키피디아에는 매일 수백 개의 새 항목이 생기고 수만 개의 기존 항목이 수정되며 어제 일어난 사건이 오늘 항목으로 만들어집니다. 이것이 살아 있는 문서(living document)입니다.

Vault도 마찬가지로 살아 있는 문서여서, 완성하면 끝나는 것이 아니라 IP가 살아 있는 한 그와 함께 변해 갑니다. 이 인식의 전환이 11장의 출발점입니다.

역류 - 집필이 Vault에 되돌아오는 사이클

라이브러링은 기본적으로 IP 문서에서 Vault로 정보가 흘러가는 방향으로 작동합니다. 1차 추출이 원본 문서에서 키워드를 끌어내고, 2차부터 4차까지를 거쳐 Vault 표제어로 완성됩니다.

역류(backflow)는 그 반대 방향으로, Vault를 활용해 단편을 집필하는 과정에서 새로 만들어진 어휘가 Vault로 되돌아오는 흐름입니다.

이 역방향 흐름이 왜 일어나는지를 이해하면, 역류가 예외적인 사건이 아니라 창작에서 자연스럽게 따라 나오는 부산물임을 알 수 있습니다.

집필자가 단편을 쓰는 상황을 생각해 봅니다. 기존 Vault를 참고하면서 미스터리 세계관 「로지할로우」의 "정정"과 "보정" 표제어를 활용하는데, 장면을 쓰다 보니 기존 설정에 없는 개념이 필요해져서 "역독(逆讀)"이라는 개념을 새로 만들어 씁니다. 정정이 흠을 지우면서 남기는 너무 새것인 흔적을 원안자가 거꾸로 읽어 무엇이 방금 지워졌는지를 복원하는 행위로, 흠을 지우는 정정과 정반대 방향으로 지워진 것을 되읽어 내는 작업이라고 할 수 있습니다.

이 개념은 이 단편에서 처음 등장했으므로 아직 Vault에 없지만, 앞으로 같은 IP의 다른 작품들에서도 쓰일 가능성이 높습니다. 바로 이 지점에서 역류가 필요해집니다.

집필자는 간략한 정의와 이 단편 안에서의 출처를 메모로 남기고, 그 메모가 역류 큐에 쌓입니다. 라이브러링은 다음 증분 실행에서 역류 큐를 확인해 그 안의 신규 어휘들을 검토합니다. 여기서 곧바로 자동 등록하지 않는다는 점이 중요합니다. 이 용어가 정말 Vault에 들어갈 표제어인지, 기존 표제어의 별칭인지, 한 단편에서만 쓰고 사라질 임시 표현인지는 사람이 먼저 판단합니다. 등록하기로 결정한 항목만 2차 CSV에 추가하고, 세계관축이 허용값 안에 있는지 확인한 뒤, 3차 골격 빌드가 증분으로 실행되어 신규 .md 파일들이 생성됩니다. 그다음 4차에서 서술이 채워지고, 역류 큐에는 등록 완료 시점이 남습니다.

집필에서 신규 어휘를 발견하고 그 어휘를 Vault에 등록하면 다음 집필에서 다시 참조하게 되는데, 이 순환이 멈추지 않을 때 Vault는 살아 있는 사전으로 성장합니다.

역류의 실용적 운영

집필자가 단편을 쓰다 보면 Vault에 없는 용어를 쓰게 되는 일이 자주 있습니다. 이때는 두 가지 방식 가운데 하나를 선택합니다. 하나는 즉시 등록으로, 집필을 잠깐 멈추고 해당 용어를 곧바로 Vault에 추가하는 방식입니다. 다른 하나는 역류 큐에 쌓기로, 집필을 멈추지 않고 새 용어를 발견했다는 메모만 남겨 두었다가 집필이 끝난 뒤 역류 큐를 한 번에 처리하는 방식입니다. 새 용어가 그 단편의 핵심 개념이라면 즉시 등록이 낫고, 주변 어휘가 처음 나온 정도라면 큐에 쌓아 두고 나중에 처리해도 됩니다. 즉시 등록을 해 두면 같은 단편 안에서 그 용어를 다시 쓸 때 곧바로 Vault에서 참조할 수 있다는 것도 이 방식의 장점입니다.

역류를 전혀 하지 않으면 Vault는 결국 기능을 멈춥니다. 역류 없이 집필만 계속하면 Vault와 집필 사이의 간극이 점점 벌어지다가 어느 순간 집필에서 쓰는 어휘가 Vault에서 찾아지지 않는 상황이 오고, 그러면 Vault가 쓸모없다는 인식이 굳어져 집필자가 더 이상 Vault를 참조하지 않게 됩니다.

그렇다고 역류를 지나치게 엄격하게 운영하는 것도 현실적이지 않습니다. 단어 하나를 쓸 때마다 집필을 멈추고 Vault를 갱신하면 집필의 흐름이 끊기는데, 역류가 집필의 부담이 되어서는 안 되기 때문입니다. 단편 하나가 끝날 때마다 역류 큐를 처리하는 리듬이 현실적인 균형입니다.

증분 갱신 - 변경된 부분만 다시 처리한다

IP를 운영하는 동안 새로운 자료가 추가되거나 수정되면 라이브러링을 다시 돌려야 하는데, 전체를 처음부터 다시 돌리면 첫 사이클 전체에 들었던 시간(9~16시간)이 또 들기 때문에 매번 그렇게 하는 것은 분명한 비효율입니다.

소프트웨어 개발의 버전 관리(git)를 떠올려 보면 좋은 비교가 됩니다. 코드를 수정했을 때 전체 코드를 다시 빌드하지 않고 변경된 파일만 다시 컴파일하며, 변경되지 않은 파일은 이전 빌드 결과를 그대로 쓰는데, 이것이 전체 빌드보다 훨씬 빠른 증분 빌드(incremental build)입니다.

라이브러링의 증분 갱신도 같은 원리를 따라 변경된 부분만 다시 처리합니다. 새 단편 하나가 들어왔을 때의 증분 갱신 흐름은 다음과 같습니다.

새 단편 파일만 1차 추출합니다. 기존 1차 CSV에 새 행들을 추가하고, 기존 행은 건드리지 않습니다.
2차 통합을 전체 재실행합니다. 신규 행들이 기존 표제어에 흡수되거나 새 표제어로 만들어집니다. 이 과정에서 기존 표제어의 이칭, 별칭, 관련키워드가 보강되기도 합니다.
3차 골격 빌드를 증분으로 실행합니다. 새 표제어에 대한 .md 파일만 생성합니다. 기존 파일은 멱등 규칙에 따라 frontmatter와 본문만 갱신하고 LLM 블록은 보존합니다.
4차 서술 집필을 증분으로 실행합니다. 새로 생성된 파일의 LLM 블록만 채웁니다.

한 단편에서 새로 생기는 표제어는 보통 30~~50개입니다. 이 정도의 증분 갱신에 드는 시간은 1.5~~2시간으로, 전체 재실행의 약 1/8~1/10에 해당합니다.

기존 LLM 서술이 보존되는 이유 - 멱등 규칙의 장기적 가치

7장에서 다룬 멱등 업데이트 규칙은 골격 빌드를 다시 돌려도 frontmatter와 정의, 상세는 새로 쓰되 사람이 채운 LLM 서술 블록은 건드리지 않고 그대로 보존하는 규칙입니다. 이 규칙이 장기 운영에서 얼마나 중요한지는 다음 상황을 보면 분명해집니다.

IP를 2년 운영하는 동안 단편이 50편 나왔고 증분 갱신을 50번 했다고 가정해 봅니다. LLM 블록의 서술 중 일부는 2년 전 처음 4차 집필에서 쓴 것이고 일부는 최근 증분 갱신에서 쓴 것인데, 50번의 재빌드를 거쳤어도 LLM 블록은 한 줄도 잃지 않고 모두 남아 있습니다. 멱등 규칙이 없었다면 이 2년의 집필 작업이 50번의 재빌드 가운데 어느 한 번에 사라질 수도 있었습니다.

증분 갱신에서 한 가지 주의할 점이 있습니다. 2차 CSV의 정의나 상세설명이 갱신되면 frontmatter와 본문은 새 정보로 갱신되지만 LLM 서술은 이전 버전 정보를 참조한 채로 남아 있을 수 있는데, 이런 불일치를 발견하면 해당 표제어의 LLM 서술을 증분으로 다시 집필합니다. 완전히 지우고 새로 쓰는 것이 아니라 기존 서술을 참조하면서 변경된 부분만 반영하는 방식입니다.

이 불일치가 얼마나 중요한 문제인지는 경우마다 다릅니다. "정정"의 공식 영문명이 바뀐 정도라면 LLM 서술 안에서 영문명이 쓰인 부분만 고치면 되지만, "정정"의 핵심 개념 자체가 바뀌었다면 LLM 서술 전체를 다시 써야 합니다. 앞의 경우는 P2 이슈이고 뒤의 경우는 P1 이슈입니다.

재구성, 더 큰 범위의 갱신

역류와 증분 갱신이 일상적인 운영이라면, 재구성은 비정기적으로 일어나는 더 큰 범위의 갱신입니다. 재구성은 두 종류로 나뉩니다.

첫째는 세계관축 재설계입니다. IP가 새로운 방향으로 확장되면서 기존의 세계관축 체계로는 분류할 수 없는 키워드들이 쌓였을 때 일어납니다. 이때는 프로파일링을 다시 해서 세계관축을 재설계하고 전체 표제어의 축 분류를 갱신합니다. 6장에서 세계관축은 처음에 잠정으로 정해 두고, 운영하면서 IP가 요구하는 방향으로 조정하라고 했습니다. 그 조정이 작으면 증분 갱신으로 처리할 수 있지만, IP가 처음 예상과 다른 방향으로 크게 확장되면 세계관축 자체가 IP를 담아내지 못하는 상황이 올 수 있습니다. 바로 그때가 재구성의 시점입니다. 재구성을 미룰수록 잘못된 축으로 분류된 표제어 수가 늘어나고 그 표제어들을 참조한 서술이 쌓여, 나중에 전부 다시 분류하는 비용이 커집니다. 그러므로 재구성이 필요하다는 신호가 보이면 일찍 처리하는 편이 낫습니다.

둘째는 명명 정책 변경입니다. 어떤 분류의 명명 규칙이 통일되지 않아 정리가 필요할 때 일어납니다. 표제어의 대표키워드가 어떤 것은 한국어, 어떤 것은 영어, 어떤 것은 혼용인 상태를 한 방향으로 통일하는 작업입니다. 2차 CSV에서 대표키워드를 일괄 수정하고 3차 골격 빌드를 재실행하면 되며, LLM 블록은 멱등 규칙으로 보존됩니다.

재구성을 할 때 저는 옛 표제어를 지우는 대신 버전상태를 바꿔 보존하는 쪽을 택합니다. 새 설정으로 갈아탄 표제어는 현행으로 두고, 더 이상 정사는 아니지만 작품 안에 그대로 남아 있는 옛 설정은 과거 버전으로 표시하며, 완전히 무효가 된 것만 폐기로 처리하는 식입니다. 이렇게 해 두면 나중에 옛 단편을 다시 읽거나 과거 설정을 참조할 일이 생겼을 때 그 어휘가 Vault에 그대로 남아 있습니다.

표제어 이름 자체가 바뀌는 경우에는 조금 더 조심해야 합니다. 새 대표키워드 파일을 만들고 옛 파일을 곧장 지워 버리면, 그 안에 있던 LLM 서술과 작업 메모까지 잃을 수 있습니다. 그래서 이름이 바뀐 표제어는 구 파일을 따로 격리해 두고, 그 안의 LLM 블록과 메모 블록을 새 표제어에 이식할지 확인합니다. 이름은 바뀌어도 그동안 쌓아 둔 서술과 판단의 흔적은 작업 자산이기 때문입니다.

살아 있는 IP는 실제로 이렇게 운영하는데, 스타워즈가 좋은 예입니다. 2014년 4월 루카스필름은 그동안 소설과 만화로 쌓인 기존 확장세계관 전체를 '레전드'로 묶어 정사에서 빼고 새 정사를 따로 관리하기 시작했으며, 이 정사를 총괄하는 스토리 그룹까지 따로 두었습니다. 옛 설정을 삭제한 것이 아니라 과거 버전으로 보존한 셈이니, 제가 재구성에서 옛 표제어를 폐기 대신 과거로 돌리는 것과 같은 발상입니다. DC 코믹스가 2011년 '뉴 52'로 작품 번호를 1호부터 다시 매기면서도 전부 갈아엎지 않고 일부 설정은 남기는 부분 리부트를 택한 것도, 어디까지 유지하고 어디부터 새로 시작할지를 정하는 캐논 버전 관리의 한 형태입니다.

운영 사이클의 주기

실제 운영에서 라이브러링 증분 갱신의 빈도는 IP의 형태에 따라 달라집니다. 단편 집필 프로젝트라면 단편이 완성될 때마다 증분 갱신을 하기를 권하는데, 10편이 쌓인 뒤 한 번에 처리하면 역류 큐가 부담스러울 만큼 커지고 신규 어휘가 오랫동안 Vault에 없는 상태로 집필에 활용되기 때문입니다. 장편 원고나 게임 콘텐츠라면 한 챕터가 완성되거나 한 패치가 릴리즈될 때 증분을 실행하는 챕터 단위나 패치 단위가 알맞습니다. 정기 갱신 주기가 정해진 IP라면 그 주기에 맞춰 라이브러링 갱신도 정기적으로 실행하는데, 가령 매달 첫 번째 월요일에 증분 갱신을 하기로 운영 달력에 적어 두면 Vault가 항상 최신 상태에 가깝게 유지됩니다.

운영 주기를 어떻게 정하든 한 가지 원칙은 변하지 않습니다. Vault 갱신이 "이번에 시간 나면 하자"는 일이 되는 순간 Vault는 방치되기 시작합니다. 갱신을 단편 완성, 챕터 완성, 패치 릴리즈 같은 특정 IP 이벤트에 자동으로 연결해 두는 것이 가장 안전합니다.

10년 운영한 Vault는 어떻게 생겼을까

라이브러링 운영 사이클이 잘 작동했다면 10년 뒤 Vault는 어떤 모습일까요.

처음에는 1,500개였던 표제어가, 10년 동안 나온 새 작품들에서 역류된 어휘가 그만큼 쌓이면서 3,000~5,000개로 늘었을 것입니다. 허브 구조도 달라져서, 처음에는 허브가 아니었지만 나중 작품들에서 자주 인용되면서 허브로 격상된 표제어들이 생겼을 것입니다.

LLM 블록의 서술도 일부는 10년 전에 쓰였고 일부는 최근에 쓰였는데, 멱등 규칙 덕분에 10년 전 서술이 거듭된 재빌드에도 지워지지 않고 살아남았습니다. 그 서술들을 죽 읽어 보면 이 IP가 그동안 어떤 목소리로 자신의 세계를 이야기해 왔는지가 고스란히 드러납니다.

이것이 라이브러링이 만들어 내는 IP의 기억 저장소이며, 한 IP의 10년이 한 폴더 안에 담겨 있는 셈입니다.

Vault를 살아 있게 유지한다는 것

Vault를 처음 만드는 일보다 그것을 살아 있게 유지하는 일이 오히려 더 어려울 수 있습니다. 만들기 시작할 때는 동기와 에너지가 충분하지만, 6개월 뒤에도 역류 큐를 처리하고 증분 갱신을 실행하려면 그 작업이 IP 창작의 자연스러운 일부가 되어 있어야 합니다. 별도로 떼어 두는 부가 작업이 아니라 IP 운영을 이루는 한 구성 요소가 되어야 한다는 뜻입니다.

12장은 Vault의 출구를 다룹니다. 라이브러링이 만든 Vault를 다음 작업들이 어떻게 사용하는지, Vault가 IP 생태계 안에서 어떤 역할을 하는지를 살펴봅니다.