final-final을 넘어서: 원고 버전, 기준 소스, Project 백업

밤 11시, 3부작 작가가 북 디자이너의 메시지를 받습니다. “2권 12장에 승인된 변경이 왜 빠져 있나요?” 2권의 첫 레이아웃을 준비하면서 1권 새 판본에는 독자가 알려 준 오류를 반영하는 중입니다. 폴더에는 “작가 최종본”, “편집자 검토본”, final-final이 있고, 동기화 드라이브는 충돌 사본을 하나 더 만들었습니다. 모든 이름이 그럴듯해 보입니다. 지금 어느 작품과 버전, 장을 제작에 넣어야 하는지는 아무것도 알려 주지 않습니다.

디자이너는 옛 초고가 책의 페이지 나누기와 교정으로 들어가기 전에 실수를 발견합니다. 작가는 final-final이라는 파일명에 서로 무관한 세 가지 역할을 맡겼다는 사실을 깨닫습니다. 현재 출판에 선택된 원고를 식별하고, 이전 시점의 실제 문장을 보존하며, 기기나 작업자의 실수가 발생했을 때 Project 전체를 복구하는 역할입니다. 파일명 하나가 세 책임을 모두 질 수는 없습니다.

이번 전달을 정확히 식별하세요

Scroll은 작가가 선택한 일반 로컬 Project 폴더를 사용합니다. 하나의 Project에 하나 이상의 작품을 등록할 수 있으므로, 1권 새 판본과 2권 초판을 모호한 “현재 시리즈 원고” 아래 섞지 않고 별도 경계로 유지할 수 있습니다.

시리즈의 사실 하나가 바뀌어도 원고 세 편이 모두 갱신되었다는 뜻은 아닙니다. 변경이 시리즈 전체, 한 작품, 특정 원고 단계 가운데 어디에 속하는지 먼저 결정합니다. Scroll은 별도 Project 사이에서 Story data를 자동으로 전파하지 않으며, 이전 판본이 이후의 사실을 받아들여야 한다고 판단하지도 않습니다.

작가는 2권에 해당하는 작품을 선택하고 원고 버전과 소스를 검토한 뒤, 현재 출판할 버전과 소스를 출판 버전(Publish Version)으로 기록합니다. 이제 디자이너에게 “2권 초판에는 이 장 묶음을 사용하세요. 1권 수정은 별도 작품에서 진행 중입니다”라고 말할 수 있습니다. 파일명을 보고 추측하는 대신 명시적인 결정을 확인하는 대화가 됩니다.

그 자체를 위한 행정 부담이 아닙니다. 1권 오류 수정과 2권 편집을 동시에 진행하면서도 각 원고의 정체성을 잃지 않게 합니다. 여러 책에 걸친 결정이 안정되면 Project 규칙에 따라 반영합니다.

버전 이름은 결정을, 실제 사본은 콘텐츠를 보존합니다

원고 소스는 작가가 열고 편집하고 저장하는 Markdown 파일입니다. 원고 버전을 등록해도 해당 파일을 복사하거나 고정하지 않으며 Git 방식의 기록도 만들지 않습니다. 소스가 계속 바뀌면 버전 이름이 새로운 스냅샷이 되지 않습니다. 다음 전달 전에는 장 범위, 순서, 해결되지 않은 표시를 다시 확인하세요.

의미 있는 편집 단계에는 실제 사본이 필요합니다. 편집자에게 보내기 전, 구조 수정 후, 교정 전의 사본처럼 보존합니다. 사본은 실제 문장을 보존합니다. 버전 기록은 그 문장이 작품에서 어떤 역할을 했는지 설명합니다.

중요한 사본 곁에 짧은 메모를 남기세요. 작품, 검토 단계, 사실 검토 상태, 이후 소스가 이 사본을 대체한 이유를 적습니다. 두 파일이 모두 유효한 문서지만 하나만 현재 결정일 때 특히 중요합니다. 수정 날짜만으로 무엇이 기준인지 정할 수 없습니다.

Project 전체 백업은 장 이외의 정보도 지킵니다

원고 디렉터리만 복사하면 본문은 보존할 수 있지만 작업, 저장된 Story 보기, 캔버스, Project 설정, 전달 기록은 빠질 수 있습니다. Project 전체 백업은 Scroll을 닫은 뒤 숨김 파일과 폴더까지 포함해 Project 폴더 전체를 보존합니다. 지원되는 절차는 현재 데이터 안전과 복구 문서를 따르세요.

로컬 우선 방식에서는 작가가 백업 위치와 전략을 정합니다. 닫힌 Project의 전체 사본을 다른 디스크, 외장 기기, 신뢰할 수 있는 클라우드 백업 위치에 둘 수 있습니다. 로컬 파일이 손실되지 않는다는 뜻은 아니며, 동기화 성공 표시가 서비스에서 원고 버전의 의미를 이해했다는 증거도 아닙니다.

구조 수정, 기기 변경, 정식 전달 전에는 작은 복원 확인을 해 보세요. 백업을 임시 위치에 복사해 Project를 열고 첫 장과 마지막 장, 작가 작업, 작품 정보를 살펴봅니다. 목표는 텍스트만 복구하는 것이 아니라 현재 맥락과 함께 작업을 재개하는 것입니다.

오래 이어지는 시리즈라면 몇 개의 복구 지점을 의미 있는 단계에 연결하세요. 구조 수정 완료, 편집자에게 전달, Scribe로 넘어갈 준비 완료 같은 시점입니다. 빈도는 위험에 따라 정합니다. 목적을 아무도 기억하지 못하는 많은 사본보다 설명할 수 있고 시험까지 마친 소수의 복구 지점이 더 유용합니다.

외부 편집자와 여러 기기를 사용하면 여전히 충돌이 생길 수 있습니다. 수동으로 비교하기 전에 양쪽을 모두 보존하세요. 충돌 사본은 결정을 내려야 할 실제 파일입니다. 수정 시각이 더 최근이라고 기준이 되지는 않으며, Scroll은 양쪽의 창작 결정을 자동으로 조정하지 않습니다.

도서 제작에는 여전히 명시적인 전달이 필요합니다

원고가 안정되면 Scribe가 외관, 페이지 나누기, PDF, EPUB과 그 밖의 지원되는 출판 출력을 담당합니다. Scroll은 작품, 원고 버전, 사용할 소스를 기록합니다. 같은 Project를 Scribe에서 열고 인식된 작품, 출판 버전, 소스 폴더, 장 수, 장 순서를 확인합니다.

이 과정은 업로드가 아니며 Scroll을 레이아웃 애플리케이션으로 바꾸지도 않습니다. 앞 단계의 준비 상태만으로 Scribe가 의도한 소스를 인식했거나 페이지가 올바르다고 증명할 수 없습니다. Scribe에서 소스 폴더, 장 수, 순서, 원고 버전을 확인한 뒤 페이지 작업을 시작하세요.

명시적인 전달은 실질적인 손해를 제한합니다. 옛 초고가 제작에 들어가면 페이지를 다시 나누고, 교정을 반복하고, 교정쇄를 폐기하거나, 출시를 미뤄야 할 수 있습니다. 분명한 소스가 모든 오류를 없애지는 못합니다. 다만 모호한 파일명 하나가 실수 하나를 전체 제작 과정으로 끌고 가는 일을 막습니다.

전체 사전 점검은 원고가 Scribe로 넘어갈 준비가 되었다는 다섯 가지 신호에서 확인하세요. 더 넓은 업무 구분은 Scroll에서 Scribe로 이어지는 워크플로에서 살펴볼 수 있습니다. 아직 구조 수정이 끝나지 않았다면 첫 초고 이후의 구조 수정 워크플로부터 시작하세요. 시리즈 작가는 도서 시리즈를 위한 Project 및 버전 도구에서 여러 접근을 비교할 수 있습니다.

“무엇을 바꾸고 있는가, 지금 어느 소스를 기준으로 삼는가, 어디에서 Project를 복구할 수 있는가?”에 답할 수 있게 되면 final-final은 기준의 증거가 아니라 평범한 파일명으로 돌아갑니다. Scroll 장문 집필 워크플로로 돌아가거나, Scroll 제품 페이지에서 로컬 Project, 작품, 출판 소스를 정리하는 방식을 확인하세요.