제12장. Vault의 출구 - 다음 작업이 가져가는 것

이제 Vault가 완성되었습니다. 1,500개의 표제어가 모이고 그것들을 서로 잇는 wikilink가 깔렸으며, 9분류와 세계관축이라는 두 좌표계가 갖추어진 위에 각 표제어마다 서술이 채워졌습니다.

여기서 나가는 출구는 넷입니다. 단편 집필, 캐릭터 빌드, 다국어 발간, 백과사전·로어북 제작이 그것인데, 이 네 작업이 저마다 Vault를 입력으로 받아 무언가를 만들어 냅니다. 이 장에서는 그 출구를 하나씩 짚어 보겠습니다. 뒤에 함께 다룰 B2B는 출구가 아니라, 여러 팀이 같은 Vault를 두고 갱신 권한을 나누는 운영 환경이므로 출구 넷과는 따로 구분하겠습니다.

Vault가 없으면 무슨 일이 생기는가

IP를 오랫동안 운영해 본 팀들은 비슷한 경험을 합니다.

"이 인물 이름이 어디선 강민지이고 어디선 강민서야. 어느 게 맞아?"

"이 장치의 제약 조건이 뭐였지? 아, 룰북 3판 어딘가에 있었는데…"

"우리가 작년에 이 설정을 바꿨는데 번역 팀에 알렸나? 번역팀 원고에 아직 구버전 이름이 쓰여 있어."

"신규 편집자가 합류했는데 세계관 공부하는 데 한 달은 걸릴 것 같아."

이 문제들은 모두 하나의 원인에서 나옵니다. 정보가 여러 곳에 분산되어 있고, 어느 것이 현재 공식 정보인지를 확인하는 단일 출처가 없습니다.

정보 분산의 비용은 생각보다 큽니다. 팀원 5명이 각자 일주일에 1시간씩 "이게 맞는 설정인가"를 확인하는 데 쓴다면 1년이면 260시간의 확인 비용이 쌓이고, 그 확인을 거치고도 잘못된 정보가 들어간 원고가 나온다면 그것을 되돌리는 수정 비용까지 따라붙습니다.

Vault는 모든 정보의 공식 버전을 한 곳에 모아 둠으로써 이 문제를 풉니다. 확인이 필요하면 Vault를 열면 됩니다.

단일 진실 공급원 - 빌려와서 더 어려워진 개념

단일 진실 공급원(Single Source of Truth)이라는 개념은 소프트웨어 공학에서 왔습니다. 그런데 저는 IP가 이 개념을 그대로 가져다 쓴다고는 말하지 않겠습니다. 빌려오기는 했지만, 더 어려운 문제에 들여놓은 것입니다.

소프트웨어의 SSOT는 풀기 쉬운 편입니다. 코드는 한 벌이고 그 한 벌이 곧 진실이어서, 같은 함수가 두 진실을 동시에 가질 수 없고 어느 값이 맞는지 다투면 실행되는 코드가 답을 정해 줍니다. 진실이 하나뿐이라서 SSOT가 자연히 성립하는 것입니다.

IP의 SSOT는 그렇지 않습니다. 「더 위쳐」처럼 소설과 게임과 드라마가 각자 별개의 줄기로 갈라진 IP에서는 정사가 하나가 아니라서, 갈라진 정사 여럿을 어느 줄기가 어느 작업의 진실인지 놓치지 않으면서 한 곳에서 동시에 관리해야 합니다. 코드는 한 벌이라 이런 일을 겪지 않지만, IP의 Vault는 여러 연속성을 나란히 품은 채로 SSOT 노릇을 해야 하는 것입니다. 결국 소프트웨어가 풀지 않아도 됐던 문제를 IP의 SSOT가 떠안는 셈입니다.

원리 자체는 IP보다 오래되었습니다. 법률 사무소가 한 사건을 처리할 때는 모든 팀원이 함께 공유하는 사건 파일 하나를 그 사건의 공식 기록으로 삼는데, 누군가 이 파일을 제쳐 두고 자기 메모만으로 일을 처리하면 오류가 생기기 때문에 모두가 같은 파일을 본다는 것이 곧 원칙입니다.

학술 연구팀이 데이터를 공유 저장소 하나에 보관하는 것도 같은 이치입니다. 팀원 각자가 같은 데이터를 복사해 따로 저장하면 복사본들 사이에 불일치가 생겨, "버전 2"와 "최종버전"과 "최최종버전"이 모두 다른 파일이 되어 버립니다. 이때 공유 저장소 하나만을 "진짜"로 인정하는 약속이 바로 SSOT입니다.

위키피디아는 아예 공개 지식의 SSOT를 목표로 만들어진 프로젝트입니다. "강민지"라는 이름이 공식인지 궁금할 때 "위키피디아에 어떻게 나와 있나"를 확인하듯, IP의 설정을 확인할 때 "Vault에 어떻게 나와 있나"를 먼저 보는 것이 라이브러링의 운영 방식입니다.

잘 정리된 IP 사전 하나가 여러 매체의 공통 입력이 되는 모습은 실제 콘텐츠에서도 확인됩니다. 「나 혼자만 레벨업」은 2016년 웹소설로 출발해 웹툰으로 이어졌고, 2024년에는 애니메이션과 넷마블의 모바일 게임으로, 다시 스핀오프 웹툰으로 확장되며 같은 세계를 공유한 채 매체를 넓혀 갔습니다. 저는 이것을 하나의 잘 정리된 세계관이 웹소설, 웹툰, 애니메이션, 게임이라는 서로 다른 작업의 공통 입력값이 된 경우로 읽습니다.

다만 매체가 늘어난다고 해서 모두가 같은 줄기를 공유하는 것은 아닙니다. 앞서 든 「더 위쳐」가 바로 그런 경우인데, 폴란드 소설에서 시작해 CD 프로젝트의 게임과 넷플릭스 드라마로 퍼지는 동안 게임과 드라마는 원작과 별개의 줄기로 가지를 쳤습니다. 이런 IP에서 SSOT는 하나의 진실만을 강제하는 장치가 아니어서, 갈라진 줄기가 있다면 그 줄기들 사이의 관계와 각 줄기의 정사 범위까지 Vault에 명시해 두어야 비로소 SSOT로 기능합니다.

Vault가 SSOT가 되는 구체적인 메커니즘

Vault가 단일 진실 공급원이 되려면 두 조건이 갖춰져야 합니다. 모든 공식 어휘가 Vault에 있어야 하고, 변경이 Vault에서 일어나야 합니다.

먼저 IP에서 쓰는 어휘 가운데 Vault에 없는 것이 하나라도 있다면 그 어휘에 대해서는 Vault가 SSOT 노릇을 하지 못합니다. 1차 추출에서 충분히 넓게 모으고 역류로 계속 보강하는 이유가 여기에 있으며, Vault의 커버리지가 높을수록 SSOT로서의 역할도 그만큼 강해집니다.

변경이 Vault에서 일어나야 한다는 말은 이런 뜻입니다. 팀원이 원고에서 인물 이름을 바꾸고 싶다면 원고에 손대기 전에 먼저 Vault의 대표키워드를 바꾸어야 하는데, Vault를 먼저 고치면 그 변경이 wikilink를 타고 Vault 전체로 전파되기 때문입니다. "강민지"를 "강민서"로 바꾸는 순간 Vault 안에서 [[강민지]]로 연결된 모든 파일의 링크가 자동으로 [[강민서]]로 갱신됩니다. 반대로 원고를 먼저 바꾸고 Vault를 나중에 바꾸거나 아예 안 바꾸면 Vault와 원고 사이에 불일치가 생기는데, 이것이 SSOT 붕괴의 시작입니다.

다만 출판된 로어북이나 공식 백과사전이 이미 존재하는 IP에서는 한 가지 위계가 더 생깁니다. 발간물은 독자에게 공개된 공식 텍스트이므로, 그 본문이 Vault의 작업 서술보다 우선합니다. 이런 경우 Vault는 발간물을 밀어내는 상위 진실원이 아니라, 발간물과 동기화되어 다음 작업을 준비하는 작업 자료의 중심이 됩니다. Vault와 발간 로어북 본문이 충돌하면 발간 본문을 기준으로 Vault를 갱신해야 합니다. 라이브러링의 SSOT는 "모든 것을 영원히 Vault가 이긴다"는 뜻이 아니라, 현재 작업 단계에서 어느 자료가 기준인지 명확히 하고 그 기준을 Vault에 반영해 모두가 같은 자료를 보게 한다는 뜻입니다.

단편 집필 도구에서 Vault를 활용하는 방법

단편, 소설, 시나리오를 집필하는 작업 도구는 Vault를 세 가지 방식으로 활용합니다. 세계관 어휘 참조, 일관성 검사, 커버리지 분석입니다.

세계관 어휘 참조란 집필 도중 특정 설정을 다시 확인해야 할 때 Vault를 여는 일입니다. 가령 "이 장치의 제약 조건이 무엇이었지?" 하는 의문이 들면 그 답을 Vault에서 찾는데, 9장에서 구조화 섹션(제약 조건과 확정 사실)을 정성껏 만들어 두라고 한 이유가 바로 여기에 있습니다. 이 섹션은 집필 도구가 프로그래매틱하게 읽기도 하고 집필자가 직접 눈으로 읽기도 합니다. 직물 세계관 「누비의 땅」에서 "고쳐 짜기"가 등장하는 장면을 쓴다고 해 보겠습니다. 누비를 다시 짜서 역사와 법을 바꾸려면 무엇이 필요한지, 누가 그 권한을 가지는지, 고쳐 짠 거짓을 누가 가려내는지가 모두 Vault에 정리되어 있으므로, 집필자는 장면을 써 내려가는 도중에 Vault를 열어 이 정보를 곧바로 확인합니다. Vault가 없다면 예전 원고들을 일일이 뒤지거나 기억에 의존하는 수밖에 없습니다.

일관성 검사는 집필이 끝난 원고에서 Vault의 어휘와 다르게 쓴 부분을 찾는 일입니다. 대표키워드와 별칭이 Vault에 모두 등록되어 있으면 검사 도구가 원고 안에서 그 표기들을 찾아내는데, 가령 "강민지"와 "강민서"가 둘 다 원고에 나올 경우 어느 것이 Vault의 공식 표기인지를 짚어 줍니다. Vault에 없는 새 표기가 발견되면 역류 큐에 올라가니, 집필자가 새로 만든 어휘를 자동으로 추적하는 메커니즘인 셈입니다.

커버리지 분석은 Vault의 어떤 표제어가 집필된 단편들에서 얼마나 활용되었는지를 들여다보는 일입니다. 아직 원고에 등장하지 않은 hub 표제어가 있다면 그 표제어를 중심으로 새 단편을 기획할 여지가 보이는데, 이런 의미에서 Vault는 "아직 쓰지 않은 이야기의 지도"이기도 합니다.

캐릭터 빌드 작업에서 Vault를 활용하는 방법

캐릭터 시트를 만드는 작업 도구는 Vault에서 두 종류의 정보를 가져갑니다. 세계관 키워드 참조와 인물 관계 지도 참조입니다.

새 캐릭터를 만들 때는 그 캐릭터가 속한 세계관축의 표제어들을 Vault에서 가져오는데, 가령 직조 기록 세계관축의 캐릭터를 만든다면 그 축의 장치, 개념, 가치 표제어들이 그 캐릭터의 배경을 이루고, 이것들이 캐릭터 시트의 "세계관 키워드" 항목에 자동으로 채워집니다. 새 캐릭터가 이 세계에 얼마나 자연스럽게 들어맞는지는 그 캐릭터를 설명하는 데 Vault의 표제어가 얼마나 잘 활용되는가로 가늠할 수 있어서, Vault의 어휘로 설명되지 않는 캐릭터는 이 IP 세계에서 그만큼 낯선 존재입니다.

씨족, 직조, 계급을 다루는 IP에서 "무문자"라는 새 캐릭터를 만든다고 해 보겠습니다. 무늬를 읽지도 짜지도 못하지만 오직 맨 기억만으로 씨족의 모든 것을 꿰고 있는 인물입니다.

Vault에서 이 캐릭터의 배경을 이루는 표제어들을 꺼내면, 직조 축에서 [[누비]], [[무늬]], [[고쳐 짜기]]가 나오고 기억 축에서 [[맨 기억]], [[분서]], [[무문자]]가 나오며, 인물 관계로는 무늬를 읽고 짜는 자인 [[직녀 (인물)]]이 함께 딸려 나옵니다.

이렇게 모인 표제어들이 캐릭터 시트의 "세계관 키워드" 항목에 들어가는데, 작성자가 Vault를 직접 뒤지지 않아도 직조 축과 기억 축의 교집합 표제어가 자동으로 후보로 제시되는 것입니다. Vault 없이 같은 캐릭터를 만들려면 작성자가 IP 원본을 다시 읽어 가며 세계관 어휘를 손수 수집해야 합니다.

인물 관계 지도 참조는 이런 것입니다. 기존 인물 표제어들의 related 필드와 구조화 섹션("관련 인물")을 살피면 인물들 사이의 관계망이 한눈에 드러나는데, 새 캐릭터를 이 관계망의 어느 위치에 더할지, 또 어떤 관계(스승/제자, 라이벌, 가족, 동료)로 둘지를 그 관계망을 짚어 가며 결정합니다. Vault가 없으면 기존 인물들의 관계를 머릿속으로 일일이 그려 가며 작업해야 합니다.

다국어 발간 작업에서 Vault를 활용하는 방법

IP를 다른 언어로 발간하려면 번역 작업이 따르는데, 이때 Vault의 번역 관련 컬럼들이 핵심 자료가 됩니다.

각 표제어의 영문명 컬럼, 로마자 컬럼, 번역노트 컬럼이야말로 번역자가 가장 먼저 여는 자료이며, 5장에서 설명한 "미래 번역자에게 보내는 편지"가 바로 이 번역노트입니다.

번역 작업에서 Vault의 번역노트가 어떻게 작동하는지 구체적인 사례로 살펴보겠습니다.

번역자가 원고에서 "무문자"라는 어휘를 만나 이를 어떻게 영어로 옮길지 판단해야 하는 상황입니다. Vault의 "무문자" 표제어를 열면 이렇게 적혀 있습니다.

영문명: Munmunja (the unwoven) 번역노트: "무문자(無紋者)"는 모든 지식을 천에 짜 넣는 이 세계에서 무늬를 읽지도 짜지도 못하는 자를 가리키는 복합 개념으로 직역이 불가능합니다. 단순히 "illiterate"로 옮기면 천에 짜인 글을 못 읽는다는 이 세계 고유의 함의가 사라집니다. "Munmunja (the unwoven)"를 1회 정의 후 이후 원어 병기 없이 "Munmunja"로 씁니다. 원고 내에서 처음 등장할 때만 괄호 해설을 붙입니다.

번역자가 이 결정을 따르면, 이 IP의 모든 번역자가 "무문자"를 같은 방식으로 옮기게 됩니다. Vault가 없을 때는 번역자마다 이 결정을 독자적으로 내리는 탓에 누구는 "Munmunja"로, 누구는 "the unwoven"으로, 누구는 "illiterate"로 옮겨, 같은 IP의 영문판 1권과 2권에서 같은 어휘의 번역이 달라지는 문제가 생깁니다.

이칭/별칭 컬럼도 번역 작업에서 못지않게 중요합니다. 원본 텍스트에 "고쳐 짜기"와 "누비 위조"와 "다시 짜기"가 모두 등장했을 때, 이 세 표기가 사실 같은 것을 가리킨다는 점을 Vault가 알려 주므로, 번역자는 셋을 번역어 하나로 통일할지 각각 다른 번역어를 쓸지를 판단할 수 있습니다. 별칭 정보가 없으면 번역자는 "다시 짜기"를 처음 만났을 때 그것이 이미 나온 개념임을 알아차리지 못합니다.

번역 작업이 끝나면 그 과정에서 내려진 번역 결정들이 Vault로 역류합니다. "이 어휘는 특정 번역어로 확정한다"는 결정이 번역노트에 기록되어 다음 번역 작업에서 그대로 재사용됩니다.

번역 산업에서 이런 자료는 termbase, 곧 용어 데이터베이스에 가깝습니다. ITS 같은 국제화·현지화 체계가 어떤 문자열을 번역해야 하는지, 어떤 용어가 특정 의미를 갖는지, 번역자에게 어떤 노트를 보여 주어야 하는지를 따로 표시하는 것도 같은 이유입니다. 번역자는 단어만 받는 것이 아니라, 그 단어를 어떤 조건에서 어떻게 다뤄야 하는지까지 받아야 합니다.

라이브러링의 Vault가 번역팀에 줄 수 있는 정보도 바로 이것입니다. 어떤 고유명은 번역하지 않고 원어로 두어야 하고, 어떤 용어는 첫 등장 때만 괄호 해설을 붙여야 하며, 어떤 별칭은 같은 표제어를 가리키지만 장면에 따라 일부러 다르게 번역해야 합니다. 이 정보가 번역노트에 들어가 있으면 번역자는 매번 새로 결정하지 않고, IP가 이미 내린 결정을 이어받습니다.

그래서 다국어 발간에서 Vault는 단순한 참고자료가 아니라 승인된 용어 결정을 저장하는 운영 자료입니다. 원문 표기, 공식 번역명, 금지 표기, 원어 병기 여부, 첫 등장 해설, 문화적 주의사항이 한 표제어 안에서 함께 관리될 때, 번역의 일관성은 개인의 기억이 아니라 자료 구조에 기대게 됩니다.

백과사전·로어북 제작에서 Vault를 활용하는 방법

IP의 공식 백과사전이나 로어북을 만들 때는 Vault가 곧 원천 자료가 됩니다.

Vault의 1,500개 표제어가 그대로 백과사전의 1,500개 항목이 되고, 4차에서 작성한 LLM 서술이 그 항목의 본문이 됩니다. hub 표제어 서술을 애초에 백과사전 항목 수준으로 써 두었다면 그 서술이 거의 손볼 것 없이 항목으로 옮겨 가는 것입니다.

Vault에서 백과사전으로 옮기는 데 추가로 드는 일은 편집과 배열뿐입니다. 독자가 어떤 순서로 읽을지를 고려한 배열, 이미지와 도표 추가, 출판 포맷 편집이 거기에 해당하는데, 이 작업들에 드는 시간은 Vault가 없을 때의 백과사전 제작 전체 시간에 비하면 훨씬 짧습니다. Vault가 있으면 "어떤 항목을 어떻게 쓸지"가 이미 결정된 상태로 출판 작업에 들어가기 때문입니다.

백과사전·로어북 제작이 라이브러링 이후 얼마나 달라지는지를 직접 겪어 본 제작자들은 이렇게 말합니다. "예전에는 백과사전 한 권을 만드는 데 몇 달이 걸렸는데, Vault가 있으면 편집과 디자인에만 집중할 수 있습니다."

B2B 환경에서 Vault의 역할

출구 넷을 짚었으니 이제 운영 환경 이야기로 넘어가겠습니다. B2B는 Vault가 무언가를 만들어 내는 출구가 아니라 여러 팀이 같은 Vault를 두고 갱신 권한을 나누는 환경이며, 여기서 Vault는 팀 사이의 공유 자료로 쓰입니다.

IP 개발팀과 번역팀, 게임 개발팀, 출판팀이 같은 IP를 함께 다룬다고 해 보겠습니다. IP 개발팀이 설정을 업데이트하면 나머지 팀들이 즉시 그 변경을 알아야 하는데, Vault가 없으면 이 업데이트가 이메일과 문서와 회의를 거쳐 전달되는 탓에 어떤 팀은 받고 어떤 팀은 놓칩니다. Vault가 있으면 그것이 갱신되는 순간 모든 팀이 같은 최신 정보를 손에 쥡니다.

이 환경에서 핵심이 되는 것은 갱신 권한입니다. 어떤 팀이 Vault를 갱신하고 그 갱신을 다른 팀들이 언제 받아 가는지의 흐름이 미리 정해져 있어야 합니다.

일반적인 구조에서는 IP 개발팀이 라이브러링 담당팀을 겸해, IP의 공식 설정 변경을 이 팀이 Vault에 반영합니다. 다른 팀들은 Vault를 읽을 수는 있어도 직접 수정하지는 않고, 수정이 필요하면 라이브러링 담당팀에 요청합니다.

이 구조가 없으면 여러 팀이 Vault를 각자 수정하면서 Vault가 팀별로 갈라지고, 결국 SSOT가 팀 수만큼 생겨나고 맙니다.

여기에 별도의 유지보수 층이 붙습니다. 인덱스를 만들고, 어떤 표제어가 충분히 쓰였는지 커버리지를 확인하고, 어떤 hub가 다른 표제어에 큰 영향을 미치는지를 주기적으로 보는 일은 단편 집필이나 번역 같은 출구 작업과는 다릅니다. 이것은 Vault를 오래 쓰기 위한 운영 작업입니다. 자동화가 갖춰져 있으면 인덱스와 커버리지와 영향력 스냅샷을 정기적으로 만들고, 아직 갖춰지지 않았다면 담당자가 수동으로라도 그 상태를 기록해야 합니다.

장기적으로는 이 Vault가 더 구조화된 지식베이스로 옮겨 갈 수도 있습니다. Wikibase 같은 도구는 여러 사람이 구조화 정보를 협업으로 고치고, 그 정보를 사람과 기계가 함께 재사용할 수 있게 하는 쪽에 강합니다. 옵시디안 Vault가 사람이 읽고 쓰기 좋은 작업장이라면, Wikibase식 지식베이스는 질의와 재사용과 공개 연동에 더 가까운 운영장입니다.

처음부터 그 단계로 갈 필요는 없습니다. 창작팀이 당장 필요한 것은 완성된 데이터베이스가 아니라 오늘 쓸 수 있는 Vault이기 때문입니다. 다만 frontmatter와 manifest와 표제어 관계를 일정하게 유지해 두면, 나중에 일부 자료를 지식그래프나 데이터베이스로 옮길 길이 열립니다. 라이브러링은 그 가능성을 남겨 둔 채, 먼저 사람이 실제로 운영할 수 있는 형태에서 시작합니다.

Vault가 있을 때와 없을 때

Vault가 있는 IP 운영과 없는 IP 운영을 나란히 놓고 견주어 보겠습니다.

Vault가 없을 때는 설정 하나를 확인하려 해도 원본 문서들을 뒤져야 하는데 그마저 어디 있는지 기억이 흐릿하고, 같은 개념이 원고마다 다른 표기로 쓰이며, 신규 팀원이 세계관을 파악하는 데 1~3개월이 걸립니다. 번역자들은 같은 어휘를 각자 다르게 옮기고, 백과사전을 만들려면 원본 문서들을 처음부터 다시 읽으며 항목을 새로 써야 합니다. 5년 뒤 원작자가 아닌 사람이 IP를 떠맡게 되었을 때는 세계관의 상당 부분이 집필자 머릿속에만 남아 있어 전달 자체가 막힙니다.

Vault가 있을 때는 사정이 다릅니다. 설정 확인은 옵시디안을 열어 검색하면 끝나고, 표제어마다 공식 표기가 하나로 정해진 채 별칭이 모두 등록되어 있습니다. 신규 팀원은 hub 100개를 읽으면 IP의 핵심을 잡고, 번역자는 번역노트를 따라 통일된 번역 결정을 이어 가며, 백과사전 제작은 편집과 디자인에만 집중하면 됩니다. 5년 뒤 IP를 새로 맡은 팀도 Vault를 열어 세계관을 처음부터 파악할 수 있습니다.

Vault는 출발점이다

Vault는 종착점이 아니라 출발점입니다. 라이브러링이 만들어 낸 Vault에서 단편 집필이 시작되고 캐릭터 시트가 만들어지며 번역 작업이 진행되고, 그 작업들에서 나온 새 어휘와 결정이 다시 역류로 Vault에 되돌아옵니다. 단일 진실 공급원이란 결국 모든 팀과 모든 작업과 모든 도구가 같은 Vault 하나를 바라본다는 뜻입니다.

13장은 실전 회고입니다. 1,500개를 직접 빚어 보며 배운 것, 예상과 달랐던 부분, 그리고 다시 한다면 무엇을 다르게 할지를 솔직하게 담습니다.