2026년 도서 시리즈를 위한 Project 및 버전 도구
3부작에서 공유 사실, 별도 작품, 수정 초고, 출판 소스를 어떻게 관리해야 할까요? 시리즈 기획과 버전 경계를 위한 일곱 가지 접근을 알아보세요.
도서 시리즈는 흔히 하나의 개요에서 시작합니다. 2권이 수정 단계에 들어설 즈음이면 1권의 출판 원고, 새 판본을 위한 변경 사항, 편집자 검토를 거친 2권, 3권 아이디어, 세 권이 공유하는 이름과 인물 정보가 생깁니다. 왕실 평의회를 검색하면 다섯 가지 표현이 나옵니다. 파일명은 final에서 final-final-really-final까지 늘어났습니다.
정리되지 않은 이름만의 문제가 아닙니다. 시리즈 작업에는 서로 다른 여러 대상이 있습니다. 책들이 공유하는 세계의 사실, 각 작품의 원고, 의미 있는 원고 단계, 현재 출판에 사용할 기준 소스, 기기 또는 작업자의 실수가 생긴 뒤 작업을 복구할 수 있는 Project 전체 백업입니다. 이 모두를 “버전”이라고 부르면 어느 도구도 어떤 파일에 어떤 책임이 있는지 설명하기 어려워집니다.
시리즈 작가는 여러 시간 규모에서도 일합니다. 오늘 밤에는 2권의 논쟁 장면을 고칩니다. 이번 달에는 1권 새 판본에 오류 수정 사항을 반영합니다. 내년에는 왜 3권에서 예전 가정을 사용할 수 없는지 기억해야 합니다. 시리즈 전체를 보는 일은 중요합니다. 그러나 지금 편집 중인 작품과 원고 단계가 무엇인지, 그 결정이 다른 책에 영향을 주는지 알아야 진도가 나갑니다.
아래 일곱 가지 도구는 시각적 시리즈 기획, 전문 시간 모델, 성숙한 장문 Project, 이어지는 집필 Library, 협업 데이터베이스, 모듈식 창작, 로컬 Project를 통해 문제에 접근합니다. 책 사이의 관계와 지금 전달할 원고 가운데 어느 쪽을 더 자주 혼동하는지부터 생각해 보세요.

Plottr: 여러 책의 구조를 먼저 한눈에 보기
Plottr의 시각적 Timeline, 장면 카드, 서사 줄기, Series View는 여러 책에 걸친 구조를 위에서 내려다보듯 보여 줍니다. 인물의 아크가 여러 권을 가로지르는 모습을 보거나, 약속이 어디에서 심어지고 회수되는지 추적할 수 있습니다. Story Bible은 인물과 장소를 위한 기획 자료를 제공합니다.
초고를 쓰기 전에 시리즈의 리듬을 잡는 시각적 기획자에게 잘 맞습니다. 본문이 여러 차례 수정에 들어간 뒤에도 작가는 기준이 되는 원고 소스에 이름을 붙이고, 시각적 기획의 변경을 각 권에 언제 반영할지 결정해야 합니다.
Aeon Timeline: 여러 책의 연대를 계산 가능한 상태로 유지하기
수십 년에 걸쳐 이어지거나 여러 인물의 나이를 제약하거나 자체 달력을 사용하는 시리즈에서는 시간이 기반 시설이 됩니다. Aeon Timeline은 사건, 인물, 장소, 서사 순서, 나이, 지속 시간, 상대 날짜를 모델링하며 여러 Story나 책을 담은 기획을 지원할 수 있습니다.
연대 오류 하나가 시리즈 전체에 영향을 준다면 전문 모델을 기준으로 유지하는 것이 합리적입니다. 이 모델은 사건이 언제 일어나는지 답합니다. 각 책의 본문, 조사, 작가 작업, 정식 출판 소스에는 여전히 각자의 경계가 필요합니다.
Scrivener: 각 장문 작품을 위한 성숙한 Project
Binder, Corkboard, Outliner, Research, Snapshots, Compile은 책 한 권 분량의 원고와 보조 자료를 위한 검증된 구조를 Scrivener에 제공합니다. 권마다 Project를 하나씩 둘 수도 있고, 시리즈 정보와 원고를 계층화한 마스터 Project를 만들 수도 있습니다.
시리즈가 커지기 전에 Project의 경계를 정하세요. 공유 세계 정보는 어디에 두고, 어느 Compile 설정을 어느 판본에 사용하며, 출판된 자료와 계속 바뀌는 원고를 어떻게 구분할지 결정해야 합니다.
Ulysses: 이어지는 Library에서 집필의 흐름 지키기
Ulysses의 Library, Projects, Groups, Filters, Sheets는 Apple 기기 사이에서 차분한 집필 리듬을 유지하면서 여러 작품을 정돈합니다. Sheets를 나누고 합치고 순서를 바꿀 수 있으며, Projects와 Groups로 현재 시리즈를 다른 집필 작업과 구분할 수 있습니다.
이름과 그룹으로 시리즈를 관리하는 데 익숙한 본문 중심 작가에게는 이런 연속성이 분명한 가치가 있습니다. 여러 책에 걸친 Story data, 조사, 수정 작업, 출판 소스가 늘어나면 Library 계층이 여전히 그런 책임을 표현하는지 판단할 수 있습니다.
Notion: 시리즈 바이블과 제작 상태를 눈에 보이게 만들기
데이터베이스 보기, 댓글, 권한, 공유 Workspace는 시리즈 기획, 협업 조사, 제작 추적을 지원합니다. 인물, 장소, 책의 상태, 표지 작업, 캠페인 날짜를 서로 다른 보기로 표시하고 각 페이지 곁에서 논의할 수 있습니다.
지속적으로 초고를 쓰는 동안 협업 데이터베이스와 로컬 본문은 서로 다른 역할을 가질 수 있습니다. Offline Mode와 내보내기도 유용한 접근 경로를 더하지만, 내려받은 페이지와 내보낸 사본, 작가가 직접 관리하는 일반 로컬 Markdown Project는 서로 다른 형태입니다. 팀은 결정이 어디에 있고 정식 원고가 어디에 있는지 명시할 때 이점을 얻습니다.
Campfire: 권마다 필요한 창작 모듈 조합하기
Campfire는 Manuscript, Characters, Timeline, 세계관 설정을 모듈식 환경에 모읍니다. 시리즈 작가는 모든 책을 똑같이 무거운 표에 넣지 않고 각 권에 필요한 자료를 강조할 수 있습니다.
1권은 세계를 소개하고, 2권은 집단 관계를 강조하며, 3권은 어려운 연대를 다루는 것처럼 필요가 달라지는 시리즈에 이런 유연성이 잘 맞습니다. 변경 하나가 여러 설명을 남기지 않도록 어떤 사실을 공유하고 어떤 사실을 권마다 따로 둘지는 여전히 작가가 정해야 합니다.
Scroll: 작품, 원고 버전, 출판 소스를 명시하기
하나의 로컬 Scroll Project에는 하나 이상의 작품을 등록할 수 있으며, Story data, 본문, 참고문헌, 작업은 분명한 Project 경계 안에 남습니다. 작품은 “어느 책인가?”에 답합니다. 원고 버전은 같은 작품의 의미 있는 단계를 설명합니다. 출판 버전(Publish Version)은 현재 출판에 사용할 기준 소스를 기록합니다. 이런 구조는 결정을 표현할 뿐, 다른 원고를 복사하거나 고정하거나 생성하지 않습니다.
합의된 시리즈 사실을 정해진 한 위치에서 관리하고, 현재 Project에는 이 책에서 실제로 사용하는 인물, 장소, 사건을 둘 수 있습니다. 별도 Project끼리는 공유 데이터를 자동으로 동기화하지 않습니다. “편집자 검토”와 “새 판본 수정”은 서로 다른 버전 의미를 나타냅니다. 도서 제작에 들어가기 전에 작가는 의도한 출판 버전에 연결된 소스를 선택합니다. 그 선택은 출판 출력이 아니며, 다음 단계 애플리케이션이 소스를 인식했다는 뜻도 아닙니다.
1권 오류 수정과 2권 편집 메모가 동시에 도착해도 이런 경계가 위험한 추측을 줄여 줍니다. 작가는 1권 수정 소스에서 장소 이름을 고치고, 모든 파일을 “최신 시리즈 버전”이라고 선언하지 않은 채 2권에도 같은 이름을 확인하는 작업을 만듭니다. 결정이 안정되면 공유 사실에 관해 합의한 기준을 갱신합니다. 각 작품은 식별 가능한 원고를 유지하고, 시리즈 맥락은 어느 변경을 다른 책에도 반영해야 하는지 보여 줍니다.
원고 버전은 Git 스냅샷이 아닙니다. 본문을 덮어써도 버전 이름만으로 되돌릴 수 없습니다. 의미 있는 단계에는 여전히 실제 사본과 백업이 필요합니다. 하나의 Scroll Project에는 숨겨진 Project data가 들어 있을 수 있으므로, 백업은 눈에 보이는 Markdown 파일만 고르는 것이 아니라 Project 폴더 전체를 보존하는 일입니다. Scroll에는 현재 모든 Project를 한 번에 전체 내보내는 단일 내장 기능이 없습니다.
로컬 Project 백업을 둘 위치는 작가가 정합니다. Scroll을 닫은 뒤 만든 전체 사본을 다른 디스크, 외장 기기, 신뢰할 수 있는 클라우드 백업 위치에 둘 수 있습니다. 이런 통제권이 손실 위험을 없애는 것은 아닙니다. 동기화 충돌은 Scroll이 자동으로 조정하지 않으므로 양쪽을 모두 보존한 뒤 수동으로 비교해야 합니다.
원고가 안정되면 같은 Project를 Scribe에서 열고 작품, 출판 버전, 소스 폴더, 장 순서를 확인한 뒤 외관, 페이지 나누기, 출판 출력 작업을 시작할 수 있습니다. Scroll은 창작 맥락, 본문, 수정, 버전 의미, 소스 선택을 지원합니다. PDF, EPUB 또는 인쇄 레이아웃을 직접 출력하지 않으며, 출판 버전이 있다고 해서 Scribe에서 장을 인식했다는 뜻도 아닙니다.
이런 경계는 새 판본과 독립 출판에 특히 유용합니다. 초고를 쓰는 동안 페이지를 결정할 필요는 없지만, 어떤 작품과 버전, 장이 제작 단계로 들어가는지는 답할 수 있습니다. 작가가 직접 확인할 전체 과정은 원고가 Scribe로 넘어갈 준비가 되었다는 다섯 가지 신호에서 살펴보세요.
편집자와의 소통도 더 정확해집니다. “최신본을 검토해 주세요”라는 말은 맥락을 잃습니다. “2권 초판에 사용할 이 소스를 검토해 주세요. 1권 수정본은 별도입니다”라고 말하면 맥락이 남습니다. 도구가 팀의 명명 정책을 대신 만들 수는 없지만, 작품, 원고 버전, 실제 사본은 정책이 명확해진 뒤 결정을 보존할 수 있습니다.
Plottr는 여러 책의 시각적 구조로 바로 들어가는 경로를 제공합니다. Aeon은 전문적인 시간 모델의 깊이를 더하고, Scrivener는 성숙한 장문 Project를 제공하며, Ulysses는 이어지는 집필을 지킵니다. Notion은 협업 기획을, Campfire는 모듈식 세계관 설정을 담당할 수 있습니다. Scroll은 현재 작품, 수정 작업, 원고 버전, 로컬 소스, 다음 단계의 도서 제작을 하나의 설명 가능한 연결 고리로 유지해야 하는 작가에게 맞습니다.
원고 버전과 Project 전체 백업에서 계속 살펴보거나, 다른 창작 부담을 알아보려면 2026년 도구 가이드로 돌아가세요. Scroll 제품 페이지에서는 작품 및 버전 작업 방식을 소개합니다.