소설가를 위한 로컬 우선 집필 도구: 원고는 내 컴퓨터에 둔다
클라우드 집필 도구는 편리하지만, 원고의 소유권과 오프라인 가용성은 별개의 차원입니다. 로컬 우선이 곧 고립을 의미하지는 않습니다.
로컬 우선 집필 도구: 원고는 내 컴퓨터에 두되, 고립되지 않게
클라우드 집필 도구의 매력은 실재합니다 — 브라우저를 열고 글을 쓰고, 자동 저장되고, 기기 간 매끄럽게 이어집니다. 그러나 일부 작가, 특히 장편 작품 깊숙이 들어간 소설가에게 이 편리함은 당장은 느끼기 어려운 두 가지 비용을 숨깁니다. 첫 번째는 원고의 소유권입니다. 당신의 소설은 정확히 어디에 “살고” 있습니까? 그 도구가 내일 문을 닫거나, 가격을 바꾸거나, 인수된다면 — 원고를 온전한 형태로 되찾을 수 있고 얼마나 걸립니까? 두 번째는 오프라인 가용성입니다. 비행 중에, Wi-Fi가 불안정한 카페에서, 집 인터넷이 끊겼을 때 — 계속 쓸 수 있습니까? 어느 질문도 일이 잘 굴러갈 때는 나타나지 않지만, 일이 터질 때는 보통 최악의 순간입니다.

이 두 질문을 둘러싸고, 2026년 독립 작가들의 대화에서 “로컬 우선”이 점점 더 자주 등장하고 있습니다. “반(反)클라우드”나 “오프라인으로 일해야 한다”로 자주 오해되지만, 로컬 우선은 고립이 아닙니다. 그 핵심 명제는 이렇습니다 — 원고의 진실의 원천은 로컬 디스크에 있다. 동기화하고, 백업하고, 협업하되, 저장을 누르는 순간 당신은 완전히 통제하는 로컬 파일에 씁니다. 클라우드는 당신이 선택하는 확장이지, 받아들여야 하는 전제 조건이 아닙니다.
주류 클라우드 집필 도구 — Google Docs, Notion, Atticus, Reedsy Book Editor — 는 사용 편의성과 협업에서 진정으로 앞서 있고, 대부분의 작가에게 진정으로 충분합니다. 본 글은 그것들을 부정하려는 것이 아닙니다. 본 글은 또 다른 그룹의 작가들 — 원고 소유권, 오프라인 가용성, 장기 이식성에 더 민감한 작가들 — 을 위해 실행 가능한 로컬 우선 경로를 그려 보이고, 그 경로가 동기화와 협업을 포기하는 것이 아님을 보여 줍니다.
본 글은 네 가지 차원을 다룹니다: 데이터 소유권, 로컬 우선이 왜 고립이 아닌지, Git을 버전 관리와 협업에 사용하기, 그리고 Catalpas Atelier Scribe가 이 경로에서 취하는 형태.
데이터 소유권: 원고는 어디에 사는가?
많은 클라우드 집필 도구에 “내보내기” 기능이 있지만, 종종 깊숙이 감춰져 있고 내보내기 포맷이 항상 소스인 것도 아닙니다. PDF로 내보내는 것은 소스를 내보내는 것이 아닙니다 — PDF는 출력입니다. 다시 편집하려면 원래 플랫폼으로 돌아가야 합니다. .docx로 내보내는 것은 구조화된 문서를 단일 포맷으로 평탄화합니다. 어떤 도구의 내보내기는 내부 링크, 댓글, 임베드된 자원을 잃기까지 합니다.
더 미묘한 문제는 장기 가독성입니다. 지금부터 10년 뒤, 오늘 어떤 클라우드 도구에서 쓴 원고가 여전히 작동할까요? 누구도 보장할 수 없습니다. 그러나 원고가 평문 Markdown 파일 폴더와 일군의 이미지 자산이라면, 10년 뒤에도 — 텍스트 에디터가 여전히 .md를 열고 이미지 포맷이 여전히 지원되는 한 — 작동할 것입니다. 그 “포맷이 특정 도구에 묶여 있지 않다”는 속성이 로컬 우선의 가장 겸손하면서도 가장 중요한 가치입니다.
데이터 소유권은 또한 원치 않는 학습 데이터로의 사용을 포함합니다. 2026년 거의 모든 클라우드 집필 도구의 서비스 약관은 사용자 콘텐츠를 분석하고, 서비스를 개선하고, 모델을 학습시킬 권리를 유보합니다. 그 약관의 경계는 플랫폼마다 다르고, 어떤 작가에게는 그 불확실성 자체가 받아들일 수 없는 것입니다. 로컬 우선 도구는 기본적으로 아무것도 업로드하지 않습니다 — 사용자가 능동적으로 동기화 서비스를 연결하지 않는 한.
로컬 우선이 곧 고립을 의미하지는 않습니다
로컬 우선에 대한 가장 흔한 오해는 이것입니다. 로컬 우선이 동기화·협업·백업을 포기한다는 뜻이 아닙니다. 그것은 단지 통제의 방향을 바꿉니다.
예를 들어 보겠습니다. 당신의 소설 원고가 로컬 디스크에 폴더 구조로 살고 있습니다:
my-novel/
├─ chapters/
│ ├─ 01.md
│ ├─ 02.md
│ └─ ...
├─ images/
└─ metadata.yaml
이 폴더를 Dropbox / iCloud / Google Drive에 두면 즉시 기기 간 동기화를 얻습니다 — 그러나 동기화되는 것은 당신이 동기화하기로 결정한 로컬 파일이지 기본적으로 모든 것이 아닙니다. rclone으로 어떤 객체 저장소에든 일정에 따라 백업할 수 있습니다. Git 저장소에 두어 버전을 관리할 수 있습니다. Resilio Sync을 통해 공동 편집자가 같은 로컬 폴더를 공유하도록 권한을 줄 수 있습니다. 이 모두는 “로컬 위에 더해진” 확장이지 “클라우드에 의한 대체”가 아닙니다.
이 구조의 또 다른 이점: 클라우드 서비스에 무언가가 잘못되어도(계정 잠김, 구독 만료, 플랫폼 정책 변경) 원고는 갇히지 않습니다 — 언제나 당신의 디스크에 있습니다. 클라우드는 당신이 선택한 편의 계층일 뿐입니다.
Git을 협업과 버전 관리에 사용하기
약간의 도구 학습을 마다하지 않는 소설가에게, Git은 “버전 관리”를 클라우드 집필 도구가 도달할 수 없는 정밀도로 끌어올립니다. 장편 집필에서 그 가치는 커밋 동작 자체에 있지 않습니다 — 가치는 이것입니다:
- 어떤 역사 스냅숏으로든 롤백 — 3개월 전에 쓴 결말이 현재 버전보다 좋았다? 한 명령으로 복원할 수 있고 원본 초고가 그 자리에 있습니다.
- 브랜치로 메인 초고를 오염시키지 않고 실험 — 새 플롯 라인을 시도하고 싶다? 브랜치를 열고 한두 챕터를 쓰고, 마음에 안 들면 버리고 마음에 들면 병합합니다.
- 편집자나 공저자와의 정밀한 협업 — 편집자가 자기 브랜치에서 편집하고 당신은 자기 브랜치에서 새 챕터를 쓰며, 병합할 때 Git이 어느 단락이 충돌하는지 단락 단위로 정확히 알려 줍니다.
학습 곡선은 실재합니다 — Git은 처음에는 친절하지 않고, 커밋/브랜치/병합의 사고 모델을 익히는 데 하루나 이틀이 걸립니다. 그러나 일단 익숙해지면 장편 작업에 가져다주는 안전성은 클라우드의 “자동 저장”을 훨씬 능가합니다. 로컬 .md 파일에 Git 저장소를 더하면(개인 GitHub / GitLab / 자가 호스팅 Gitea로 푸시) 로컬이고 동기화되고 협업 준비가 된 워크플로가 됩니다 — 그리고 진실의 원천은 여전히 당신의 디스크에 살아 있습니다.
Catalpas Atelier Scribe: 로컬 우선 작업 환경
로컬 우선은 도구가 함께 맞춰 줘야 작동합니다. 집필 도구가 독점 포맷(Scrivener의 .scriv 패키지처럼)을 고집한다면, 파일이 디스크에 있어도 로컬 우선의 핵심 가치 — 평문 이식성 — 는 평가절하됩니다. **Catalpas Atelier Scribe**는 3개 플랫폼 네이티브 애플리케이션에서 로컬 우선을 기본값으로 삼습니다.
소스는 폴더 안의 Markdown
챕터당 .md 하나, YAML 메타데이터. 이 구조는 어떤 에디터(VS Code, Obsidian, Sublime, 심지어 메모장)에서도 열리고, Git에 들어갈 수 있으며, 어떤 동기화 도구로도 인식 가능합니다. Scribe는 원고를 독점 데이터베이스에 가두지 않습니다.
기본 로컬, 선택적 클라우드 Scribe는 계정 로그인이나 클라우드 동기화를 강요하지 않습니다. 파일은 기본적으로 로컬 경로에 저장되고, 클라우드 동기화(Dropbox / iCloud / Google Drive, 당신의 선택)는 능동적으로 설정할 때만 활성화됩니다. 그 “기본 로컬, 필요할 때 확장” 입장이 로컬 우선 도구의 표식입니다.
3개 플랫폼 네이티브 + 완전한 워크플로 Windows, macOS, Linux 모두에 네이티브 클라이언트가 있고 모든 티어가 세 플랫폼에서 사용 가능합니다. Free에서 집필 + CJK 세로쓰기 + 이미지 내보내기가 무료로 제공되고, Plus는 EPUB 3와 그레이스케일 / RGB PDF를 해제하며, Pro는 CMYK, 커스텀 인쇄 마스터, 루비, LaTeX를 추가합니다 — 완전한 인쇄 파이프라인. Pro는 얼리버드 $79.99/년, 정가 $129.99/년.
동기화 도구와의 호환성 소스가 평문 폴더이므로 Scribe는 어떤 파일 단위 동기화 도구와도 자연스럽게 호환됩니다. 프로젝트를 Dropbox에 두어 기기 간 동기화하고, Git에 두어 버전 관리와 협업하고, rclone 파이프라인에 두어 외부 백업하기 — 이런 것들은 로컬 우선 위에 옵션으로 쌓이는 것이지 Scribe가 내부적으로 지원해야 하는 기능이 아닙니다.
자신에게 맞는 선택
이미 클라우드 도구에서 편안히 쓰고 있고, 협업과 동기화에 만족하며, 데이터 소유권 질문에 민감하지 않다면, “로컬 우선”이라는 단어를 위해 이주를 강요할 이유가 없습니다. 클라우드의 편리함은 실재합니다.
그러나 다음과 같은 경우, 로컬 우선이 더 잘 맞을 수 있습니다:
- 원고가 당신에게 장기적 가치를 가지며, 10년 뒤에도 특정 플랫폼과 무관하게 열 수 있기를 원한다;
- 작업 환경에 잦은 오프라인 구간이 있다(비행, 원격 작가 레지던시, 불안정한 네트워크);
- 원치 않는 학습 데이터 사용, 플랫폼 정책 변경, 구독 종료 등 불확실성에 민감하다;
- 더 정밀한 버전 관리와 협업을 얻기 위해 약간의 Git이나 파일 단위 동기화를 배울 의향이 있다;
- 이미 자신만의 백업·동기화 인프라(NAS, 개인 Git 서버, 객체 저장소)가 있고 집필 도구가 그것과 충돌하지 않기를 원한다.
가장 좋은 로컬 우선 도구는 당신의 기존 백업·동기화 습관에 가장 잘 맞는 것입니다. Free 티어에서 시작해 몇 챕터를 써 보고 자신의 리듬에 맞는지 확인하십시오.
더 읽기:
- 2026년 소설가를 위한 집필 소프트웨어
- 2026년 크로스 플랫폼(Windows / Mac / Linux) 집필 소프트웨어
- 하나의 원고에서 EPUB과 인쇄 PDF 내보내기: 인디 작가의 단일 파일 워크플로
- Scribe 해결책 허브: 워크플로별 진입점 찾기