작가는 생각보다 자주 도구를 바꾸게 된다. 프로그램이 더 이상 업데이트되지 않기도 하고, 구독료가 갑자기 오르기도 하고, 더 나은 작업 방식이 등장하기도 하고, 시리즈가 처음 시작한 자리를 그냥 넘어서 버리기도 한다. 본문은 대개 무사히 옮겨 간다. 사라지는 것은 그 주변의 모든 것이다. 인물 노트, 세계관의 규칙, 개요, 장면 계획, 12장 시점에 누가 무엇을 알고 있는지에 대한 기록. 긴 책이나 시리즈에서는 바로 이 자료가 진짜 작업 자본이며, 동시에 가장 두고 떠나기 쉬운 부분이다. 이 가이드는 스토리 바이블이 소프트웨어 관점에서 정확히 무엇인지, 왜 옮기기 어려운지, 그리고 어떤 도구의 내보내기 기능이든 믿고 맡기기 전에 무엇을 확인해야 하는지를 다룬다.
원고는 본문만이 아니다
완성된 장편소설의 작업 파일을 떠올려 보자. 각 장이 있고, 인물마다 과거와 말투를 정리한 등장인물 목록이 있다. 장소와 세력, 마법이 작동하는 방식을 적은 페이지가 있다. 여러 세대에 걸쳐 고쳐 쓴 개요가 있고, 각 장면이 무엇을 해내야 하는지 적은 장면 단위의 계획이 있다. 책이 시리즈의 일부라면 이야기의 현재 상태에 대한 감각도 계속 이어진다. 누가 비밀을 알게 되었는지, 누가 죽었는지, 주인공이 아직 배낭에 무엇을 지니고 있는지.
이 모두를 스토리 바이블이라고 부르자. 작가는 이것을 천천히 쌓아 올리며, 3권이 1권과 어긋나지 않을 수 있는 것도 이 덕분이다. 또한 작가의 결정 대부분이 한 번 적어 두면 다시 내릴 필요가 없도록 보관되는 곳이기도 하다. 잃어버린 초고는 잘 갖춘 바이블이 있으면 다시 쓸 수 있다. 바이블을 잃어버리면 수년간의 결정을 기억과 본문에 의지해 다시 짜 맞춰야 하는데, 이는 더디고, 3권에 모순이 스며드는 바로 그 경로이기도 하다.
스토리 바이블은 실제로 어디에 있는가
평범한 워드프로세서에서는 바이블이 직접 만든 문서 묶음이므로, 옮기는 일은 파일을 복사하는 것으로 끝난다. 집필 전용 도구는 다르다. 이런 도구는 인물, 장소, 플롯 포인트를 자체 데이터베이스 안에 필드와 태그, 그리고 서로 간의 연결을 가진 레코드로 저장한다. 이 구조가 도구를 유용하게 만든다. 한 인물이 등장하는 모든 장면을 볼 수 있고, 플롯 가닥별로 개요를 걸러 볼 수도 있다. 그리고 바로 이 구조 때문에 도구를 떠나기도 어려워진다.
이런 도구가 내보내기를 제공할 때는, 그 내보내기가 무엇을 위해 설계되었는지 물어볼 만하다. 많은 도구는 원고를 중심으로 내보내기를 만든다. 작가가 편집자, 에이전트, 출판사에 보내는 것이 원고이기 때문이다. Word 파일, EPUB, PDF 같은 것들이다. 본문은 아름답게 나온다. 그러나 레코드로 저장된 구조화된 자료는 따로 나오거나, 일부만 나오거나, 아예 나오지 않을 수 있다. 본문만 내보내고 스토리 바이블은 안쪽에 그대로 가두어 두는 도구도 있다. 이것이 꼭 악의에서 비롯된 것은 아니다. 내보내기 기능은 가장 흔한 요청을 위해 만들어지고, "원고를 어딘가에 보낸다"는 요청은 "내 프로젝트 전체를 옮긴다"는 요청보다 훨씬 흔하다.
어려운 부분은 연결이다
도구가 바이블을 내보내 준다 해도, 인물 노트를 평평하게 나열한 목록은 작가가 쌓아 온 것의 일부에 불과하다. 의미의 상당 부분은 항목들 사이의 연결에 담겨 있다.
작동 중인 프로젝트가 무엇을 알고 있는지 생각해 보자. 이 장면은 이 인물의 시점으로 서술된다. 이 세 인물이 이 장면에 등장한다. 이 플롯 가닥은 4장에서 열려 20장에서 해소된다. 이 인물은 9장에서 배신을 알게 되었으므로 15장에서 그 일에 놀란 척할 수 없다. 이런 사실 하나하나가 두 레코드 사이의 연결이며, 데이터베이스에서는 그 연결이 지면의 말이 아니라 내부 참조로 유지된다.
각 레코드를 별개의 문서로 풀어 쓰면서 연결을 버리는 내보내기는 조각만 주고 조립은 주지 않는다. 손으로 다시 맞출 수는 있지만, 시리즈라면 며칠이 걸릴 수 있고, 특정 장면에 묶여 있는 상태 변화 같은 미묘한 연결이 가장 먼저 사라진다. 좋은 내보내기는 연결을 명시적으로 유지한다. 그래야 나중에 파일을 읽는 쪽이 어느 인물이 누구인지, 각 사실이 어디에 속하는지 알아낼 수 있다.
내보내기를 믿기 전에 확인할 것
내보내기를 시험해 볼 때는 필요해지기 전, 프로젝트가 건강하고 도구가 아직 열려 있을 때가 좋다. 다섯 가지 질문이면 대부분을 짚을 수 있다.
책만이 아니라 바이블도 들어 있는가? 출력물에서 인물, 장소, 참고 문서가 이름만이 아니라 전체 본문과 함께 들어 있는지 살펴보자. 개요와 장면 계획, 개별 장면에 붙은 메모도 확인해야 한다.
사람이 읽을 수 있는가? 일반 텍스트 편집기로 파일을 열어 보자. Markdown과 일반 텍스트는 오래가고 어디서나 열리지만, 독점 바이너리 파일은 그것을 만든 프로그램에서만 열리므로 내보내기의 목적이 무색해진다.
프로그램이 읽을 수 있는가? 구조가 사라졌다면 사람이 읽을 수 있다는 것만으로는 충분하지 않다. 레코드 사이의 연결이 참조로 유지되는 JSON 같은 구조화된 형식이어야, 다른 도구가 프로젝트를 다시 세울 수 있고 작가가 처음부터 다시 입력하지 않아도 된다.
형식이 문서로 공개되어 있는가? 각 부분에 무엇이 담기고 레코드들이 서로를 어떻게 가리키는지 설명한 공개 문서가 있으면, 그 내보내기는 어떤 도구나 도움을 주려는 어떤 프로그래머와도 함께 쓸 수 있는 것이 된다. 문서화되지 않은 내보내기는 만든 쪽만 온전히 이해하는 형식이다.
시리즈 전체를 아우르는가? 책들이 인물과 세계를 공유한다면, 공유 자료가 각 책과 함께 나오는지, 그리고 한 번에 여러 권을 내보낼 수 있는지 확인하자.
왕복 시험을 해 보라
가장 많은 것을 알려 주는 시험은 프로젝트를 내보낸 뒤 곧바로 같은 도구나 새 계정으로 다시 가져와 보는 것이다. 도구가 자신이 만든 내보내기를 읽지 못한다면, 문제가 생겼을 때 그 파일은 별 도움이 되지 않는다. 읽을 수 있다면 둘을 비교해 보자. 인물들이 전체 항목과 함께 모두 있는가? 장면들이 여전히 누가 등장하는지 알고 있는가? 개요가 일치하는가? 왕복에서 빠진 것은 다른 곳으로 옮길 때도 틀림없이 빠질 것이다.
그 김에 그 내보내기본의 사본을 도구 바깥 어딘가에 보관해 두고, 큰 기획 작업을 마칠 때마다 습관으로 삼자. 클라우드 서비스가 데이터를 잃는 일은 드물지만, 계정이 잠기기도 하고 회사가 방향을 바꾸기도 한다. 직접 가진 사본만이 믿을 수 있는 유일한 사본이다.
떠날 수 있는 도구를 고르기
긴 프로젝트를 맡기기에 가장 믿음직한 도구는 대개 떠나기 쉬운 도구다. 모든 것을 다른 소프트웨어가 읽을 수 있는 형태로 내보내 주는 기능은, 도구가 약속이 아니라 코드로 지킨 다짐이다. 새 집필 도구를 저울질할 때는 들어오는 길보다 나가는 길을 먼저 살펴보자. 무엇이, 어떤 형태로 나오는지, 그리고 다시 들어갈 수 있는지를 물어보면 된다.
Novelmint는 이 기준을 염두에 두고 만들어졌다. 시리즈 전체가 하나의 개방형 프로젝트 파일로 내보내진다. 어디서든 읽을 수 있는 Markdown과, 인물·장소·플롯 가닥·장 계획·비트·본문 사이의 연결을 유지하는 문서화된 JSON이 들어 있으며, 각 책의 표지도 함께 담긴다. 같은 파일은 새 시리즈로, 또는 원래 있던 시리즈로 다시 가져올 수 있으므로, 백업은 실제로 복원할 수 있는 것이 된다.