혼돈의 비용
토요일 집필 세션이 시작된 지 세 시간, 문장이 흐르고 있습니다. 한 인물이 4장에서 등장한 거리 이름을 언급합니다. 잠깐 확인해 보고 싶습니다. 「느릅나무 거리」였던가, 「떡갈나무 거리」였던가. 초고 폴더에는 파일이 아홉 개 있습니다. 그중 셋은 “final”이 붙어 있습니다. 하나는 “USE THIS ONE”이라고 쓰여 있습니다. 어느 파일도 거리 이름이 일치하지 않습니다.
20분 뒤, 집필 세션은 끝났습니다. 라이터스 블록 때문이 아닙니다. 파일 시스템에 산 채로 잡아먹힌 것입니다.
이런 종류의 마찰은 종이 위에서는 사소해 보입니다. 끊긴 세션 한 번, 잃어버린 디테일 하나, 잘못 이름 붙인 파일 하나. 그러나 심리학자들은 그 뒤에 일어나는 일을 「과제 전환 비용(task-switching cost)」이라 부릅니다. 글쓰기 모드에서 파일 탐색 모드로 점프할 때마다 뇌는 차가운 상태에서 다시 시동을 걸어야 합니다. 하루에 열 번, 일주일에 일곱 번 이 일을 반복하면, 빠져나가는 것은 시간이 아닙니다. 의지력입니다. 문서를 열기도 전에 의자가 무겁게 느껴지기 시작합니다.
톨킨은 《반지의 제왕》에 12년을 쏟았습니다. 50만 단어. 세 권. 창작 엘프어 문법 매뉴얼, 비례를 갖춘 가운데땅 지도, 왕가 혈통의 가계도. 그는 폴더가 깔끔했기 때문에 글을 잘 쓴 것이 아닙니다. 필요한 것을 찾을 수 있었기 때문에 책을 끝낼 수 있었습니다. 이 구분이 대부분의 작가가 생각하는 것보다 훨씬 중요합니다.
“chapter3-final-FINAL-really-final-this-time.docx.” 이 파일명 뒤에는 잘못된 명명보다 더 나쁜 무언가가 자리합니다. 어딘가 바탕화면에 묻혀 있는 인물 프로필. 모르는 버전 안에 살고 있는 석 달 전 대사 한 구절. 주인공이 외동인지 형이 있는지를 알아내려고 30분을 헤맸는데도 답이 없는 상태.
그러니 진짜 질문은 정리할 것인가 말 것인가가 아닙니다. 「찾는 일」을 의식의 표면에서 영구히 지워 줄 시스템을, 어떻게 하면 최소의 노력으로 세울 것인가입니다.
책은 하나의 저장소입니다
수십 년 전, 소프트웨어 엔지니어들이 정확히 같은 벽에 부딪혔습니다.
수백만 줄의 코드를 수십 명이 동시에 편집하는데도, 버전은 명확하게 유지되고, 이력은 추적 가능하며, 과거의 어느 시점이든 복원할 수 있습니다. 초인적인 기억력 덕분이 아닙니다. 버전 관리, 즉 프로젝트 전체를 구조화된 저장소로 다루는 방식 덕분입니다.
Slima는 그 논리를 글쓰기로 가져옵니다. File Tree를 열면 평범한 폴더 구조처럼 보입니다. 그러나 그 아래에서는 모든 파일 변경이 추적됩니다. 모든 과거 버전이 보존됩니다. 과거의 어떤 상태든 언제든 다시 방문할 수 있습니다.
책은 이제 흩어진 .docx 파일 더미가 아닙니다. 층위가 있고, 버전이 있고, 기억을 품은 저장소가 됩니다. 창작의 과정과 창작의 산물 — 둘이 함께, 안전하게 보존됩니다.
엔지니어에게나 필요한 이야기처럼 들립니까? 다시 생각해 보십시오. 「그 단락을 안 고쳤더라면」이라고 후회해 본 적 없는 작가가 어디 있습니까?
구조 세우기
철학은 그만하면 충분합니다. 실제로 작동하는 구조는 이렇습니다.
장편 소설을 위한 검증된 폴더 구조입니다.
MyNovel/
├── drafts/
│ ├── part-one/
│ │ ├── 01-beginning.md
│ │ ├── 02-conflict.md
│ │ └── 03-turning-point.md
│ ├── part-two/
│ └── part-three/
├── characters/
│ ├── protagonists/
│ ├── supporting/
│ └── antagonists/
├── world/
│ ├── locations/
│ ├── history/
│ └── rules/
├── research/
└── outlines/
├── master-outline.md
├── chapter-outlines.md
└── timeline.md
전체를 관통하는 원칙은 하나입니다. 초고는 초고끼리, 인물은 인물끼리, 세계관은 세계관끼리. 인물의 배경을 확인해야 합니까? 챕터 파일을 뒤지지 마십시오. 곧장 characters 폴더로 가십시오. 장소 묘사를 확인해야 합니까? world/locations를 여십시오. 무언가가 어디에 살고 있는가는 절대로 「생각을 요구해서는」 안 됩니다.
이 분리에는 숨은 보너스가 있습니다. Slima의 AI Assistant는 정보가 잘 정리되어 있을수록 더 날카로워집니다. AI Chat Panel(Cmd+Shift+A / Ctrl+Shift+A)에서 “characters/protagonists” 폴더를 참조하면, AI는 즉시 맥락이 「플롯 메커니즘」이 아닌 「인물 발전」임을 이해합니다. 구조화된 입력은 구조화된 답을 만들어 냅니다.
구조는 또한 법이 아닙니다. 초고 중반에 「deleted-scenes」 폴더가 있었으면 좋겠다는 생각이 듭니까? 만드십시오. 「history」를 고대와 근대로 쪼개야 합니까? 쪼개십시오. File Tree는 드래그 앤 드롭을 지원합니다. 재정리는 블록을 재배치하는 느낌입니다.
명명의 기술
파일명을 과소평가하는 작가가 열 명 중 아홉 명입니다.
예전 방식은 모든 파일에 숫자 접두사를 붙이는 것이었습니다. 01-, 02-, 03-. 엔지니어가 이렇게 하는 이유는 코드 에디터가 알파벳 순으로 정렬하기 때문입니다. 그러나 Slima의 File Tree는 드래그 앤 드롭 정렬을 지원합니다. 파일과 폴더 모두를 직접 재배치할 수 있습니다. 순서를 이름 안에 인코딩할 필요가 없습니다.
그래서 챕터는 실제 제목을 그대로 가질 수 있습니다.
before-the-storm.md
the-meeting.md
first-secret.md
순서를 바꾸고 싶습니까? 드래그하십시오. 이름을 바꾸는 것보다 열 배 빠르고, 파일명은 깔끔하게 유지됩니다. 숫자 접두사가 더 편하거나, 다른 도구로 내보낼 때 순서를 유지해야 한다면 숫자도 여전히 잘 작동합니다. 취향의 문제입니다.
인물 파일은 역할 라벨에서 이득을 봅니다.
kim-jiho-protagonist.md
old-keeper-mentor.md
choi-yeongmin-antagonist.md
진짜 보상은 검색입니다. Quick Open(Cmd+P / Ctrl+P)을 띄우고 “protagonist”라고 입력하면 주인공 관련 파일이 모두 떠오릅니다. “antagonist”라고 치면 적대자가 모두 나타납니다. 모든 인물의 이름을 외울 필요가 없습니다.
세계관 파일은 묘사적인 이름이 필요합니다.
좋음: northern-kingdom-history.md
나쁨: setting3.md
“setting3”은 만든 그날에는 말이 됩니다. 석 달 뒤에는요? 완전한 미스터리입니다. “northern-kingdom-history”는 그 문제를 겪지 않습니다.
이름 바꾸기는 무통입니다. File Tree에서 파일을 선택하고 F2를 누르면 이름 바꾸기 모드로 들어갑니다. 내부 링크는 자동으로 갱신됩니다. 깨진 참조는 발생하지 않습니다.
Version Control — 모든 것을 바꾸는 안전망
톨킨의 종이 시스템에는 치명적 결함이 하나 있었습니다.
한 번 무언가가 바뀌면 옛 버전은 사라졌습니다. 석 달 전의 설정을 다시 보고 싶다면 — 사라지고 없습니다. 미리 손으로 베껴 두지 않은 한 그렇습니다. 그리고 누가 모든 편집에 앞서 손으로 백업을 만들겠습니까?
Slima의 Version Control은 이 문제를 뿌리부터 제거합니다. Cmd+Shift+G(Mac) 또는 Ctrl+Shift+G(Windows)를 누르면 타임라인이 펼쳐집니다. 모든 수정이 기록되고, 모든 상태가 보존되어 있습니다.
Snapshots는 수동 저장 지점입니다. 한 챕터를 마쳤습니다 — 하나 저장. 큰 개고를 시작하려 합니다 — 하나 저장. 베타 리더 피드백이 막 도착했고 칼이 들어가려 합니다 — 하나 저장. 「지금의 상태는 보존할 가치가 있다」고 느껴지는 어떤 순간이든 스냅숏을 받을 자격이 있습니다.
그러나 진짜 판도를 바꾸는 것은 Branches입니다.
시장의 다른 어떤 글쓰기 도구도 이것을 제공하지 않습니다. 개념은 직관적입니다. 메인 초고를 건드리지 않고 평행한 탐색 라인을 여는 일입니다.
소설 중반에 어떤 생각이 머리를 칩니다. 「여기서 멘토가 죽으면 어떨까?」 전통적인 방식은 이렇습니다. 프로젝트 전체를 복사하고, 복사본을 난도질하고, 안 되면 지우고, 양쪽 다 살려야 한다면 관리 지옥으로 내려갑니다.
Slima에서는 “experiment/mentor-dies”라는 브랜치를 만듭니다. 그 안에서 자유롭게 씁니다. 메인 라인은 꿈쩍도 하지 않습니다. 만족스럽다면 머지합니다. 만족스럽지 않다면 메인으로 다시 전환합니다. 브랜치는 거기 조용히 남아, 아무것도 방해하지 않습니다.
이 안전망은 글쓰기의 사고방식을 바꿉니다. 「바꿀 수 있다」가 아닙니다. 반드시 바꿉니다. 한 챕터 전체를 지우는 일이 더 이상 되돌릴 수 없는 일이 아니기 때문에, 과감한 실험에 대한 심리적 장벽이 0으로 떨어집니다.
이미 흩어진 것 정리하기
이미 흩어진 파일 더미 위에 앉아 있습니까? 너무 늦었습니까?
늦은 적은 없습니다.
먼저 인벤토리를 만드십시오. 바탕화면, 다운로드, 클라우드 스토리지, 이메일 첨부 — 프로젝트와 관련된 모든 파일을 나열합니다. 이 단계는 보통 충격을 안깁니다. 생각보다 훨씬 더 흩어져 있습니다.
다음은 분류입니다. 초고 내용, 인물 프로필, 세계관 자료, 리서치 참고, 개요와 계획. 분류를 거부하는 파일도 있습니다. 그것들은 “to-sort” 폴더에 던져 두십시오. 여기서 멈추지 마십시오.
그다음 Slima 안에 폴더 구조를 세우고, 파일을 하나씩 적절한 자리로 옮기면서 이름을 새로 붙여 나갑니다. 지루합니까? 그렇습니다. 그러나 이것은 일회성 비용입니다.
모든 것이 제자리를 잡는 순간, 즉시 스냅숏을 만드십시오. 그 스냅숏이 전환점을 표시합니다 — 혼돈에서 질서로의 전환점입니다.
어떻게 분류해야 할지 모르겠습니까? AI Assistant가 도울 수 있습니다. AI Chat Panel을 열고 파일 목록을 붙여 넣으십시오.
다음은 제 소설 프로젝트의 모든 파일입니다.
[파일 목록을 나열]
콘텐츠 유형에 따라 적절한 폴더 구조를 제안해 주시고, 각 폴더의 목적을 설명해 주십시오.
맞춤 추천이 몇 초 만에 돌아옵니다.
새 프로젝트를 처음부터 시작하기
새로운 장편 프로젝트가 시야에 들어왔습니까? 이것이 가능한 최고의 출발점입니다.
단 한 단어를 쓰기 전에 폴더 구조를 세우십시오. 시간 낭비처럼 느껴집니다. 정반대입니다. 3주가 지난 시점에 새 인물 프로필이 자리를 필요로 합니다 — 어디로 갈지 망설일 일이 없습니다. 두 달이 지난 시점에 리서치 노트가 정리될 자리를 찾습니다 — 경로가 자명합니다. 앞에서의 15분이 프로젝트 전체에 걸쳐 수십 시간의 마찰을 절약해 줍니다.
템플릿 파일을 준비해 두는 것도 좋습니다. characters 폴더에 “_character-template.md”를 하나 넣어 두십시오. 표준 필드는 기본 정보, 외모, 성격, 배경, 이야기 안에서의 역할 등입니다. 새 인물이 등장합니까? 템플릿을 복사하고 빈칸을 채우면 됩니다. 매번 바퀴를 다시 발명할 필요가 없습니다.
구조는 프로젝트가 자라면서 함께 진화합니다. 새 폴더가 생길 수도 있습니다. 옛 폴더가 합쳐질 수도 있습니다. 정상적인 일입니다. File Tree의 드래그 앤 드롭 재정리와, 무엇이 깨지든 되돌릴 수 있는 Version Control이 대기하고 있습니다. 어떤 변경도 비가역적이지 않습니다.
톨킨은 종이 기반 노트 시스템으로 12년의 창작을 관리했습니다. 컴퓨터도, 검색 기능도, 버전 관리도 없었습니다. 순전히 규율과 설계뿐이었습니다.
도구는 달라졌습니다. 종이는 글쓰기 스튜디오가 되었습니다. 손으로 만들던 백업은 Snapshots가 되었습니다. 가위와 풀은 File Tree의 드래그 앤 드롭이 되었습니다. 그러나 그 바탕의 사고는 흔들리지 않았습니다. 책을 무작위로 던져 둔 파일 더미가 아니라, 관리해야 할 프로젝트로 다루는 일입니다.
좋은 구조는 창의성을 제한하지 않습니다. 그것이 하는 일은 더 미묘합니다. 「찾는 일」을 의식의 층에서 제거함으로써, 주의력이 온전히 이야기 그 자체에 향할 수 있게 해 줍니다.
다음 글은 인물 데이터베이스입니다. 톨킨이 가운데땅의 혈통을 추적했던 것처럼, 이야기 속 모든 사람을 어떻게 추적할 것인가의 문제입니다.