AI 도구에 관한 집필 조언의 대부분이 정확히 거꾸로 되어 있습니다.
통념은 이렇습니다. AI는 아직 충분히 똑똑하지 않으니, 다음 모델을 기다리라. GPT-5가 당신의 인물을 이해할 것이다. GPT-6가 당신의 서브플롯을 추적할 것이다. 어느 미래 버전이 마침내 당신의 20만 단어짜리 소설을 「알아차릴」 것이다.
여기서 완전히 놓치는 지점이 있습니다. 지능은 한 번도 병목이었던 적이 없습니다.
당신의 원고를 끝까지 다 읽은 평범한 독자가, 12장만 본 가장 강력한 AI보다 더 많은 연속성 오류를 잡아냅니다. 맥락이 능력을 이깁니다 — 매번. 문제는 AI가 사고하지 못한다는 것이 아닙니다. 문제는 AI가 보지 못한다는 것입니다.
그리고 그 문제는 AI를 더 똑똑하게 만든다고 해결되지 않습니다. AI가 무엇에 접근할 수 있는지를 바꿔야 풀립니다.
전통 워크플로의 세 가지 파열점
AI 집필에 관한 가장 큰 거짓말은 「AI가 아직 충분치 않다」가 아닙니다. 「AI가 충분하므로 무엇이든 다룰 수 있다」입니다.
ChatGPT를 집필 파트너로 쓰는 일은 그럴듯하게 들립니다. 채팅 창을 열고, 한 구절을 붙여 넣고, 「이 대사가 자연스럽게 들립니까?」 하고 묻습니다. 답이 옵니다. 잘된 답까지 옵니다. 결말 후보 세 가지를 요청합니다. 내놓습니다 — 그것도 진짜로 흥미롭게.
문제는 열일곱 번째 대화에서 시작됩니다. 진짜 질문이 마침내 떠오르는 순간. 「3장에서 주인공이 한 약속이 17장의 행동과 모순됩니까?」 AI는 자신만만하게 답합니다. 그러나 틀렸습니다. 그것은 3장을 한 번도 읽은 적이 없습니다.
책 전체를 붙여 넣겠습니까? 길이 한계. 인물 프로필을 표로 만들어 매번 같이 붙입니까? 다섯 번째 라운드쯤 가면 AI는 표마저 잊었습니다.
도구 세 개가 동시에 돌아갑니다 — 초고용 Word, 질문용 ChatGPT, 모든 것을 기억하는 당신의 뇌 — 셋 사이에 연결은 없습니다. 원고는 한 창에 살고, AI는 다른 창에 살며, 인물 아크와 심어 놓은 복선, 서브플롯 진행 상황은 — 모두 머리뼈 안에 욱여넣어져 있습니다. 이건 효율의 문제가 아닙니다. 근본적 설계 결함입니다.
Word는 20만 단어짜리 소설을 단일 문서로 다룹니다. 인물 프로필을 맨 위에 박아 놓고, 어떤 정보든 찾으려면 서른 페이지를 스크롤해야 합니다. 또는 열두 개 파일에 흩어 놓고, 디테일 하나를 확인할 때마다 창을 갈아타게 합니다 — 그때마다 사고의 흐름이 끊깁니다.
버전 관리는 더 나쁩니다. 단락을 지웠다가 후회할까 두려워 사본을 저장합니다. 결말을 바꾸었다가 망설여져 또 사본을 저장합니다. 석 달이 지나면 폴더에는 「final 버전」 다섯 개가 있고, 어느 것이 무엇인지 아무도 기억하지 못합니다.
AI는 더 똑똑해질 필요가 없다 — 완전한 맥락이 필요할 뿐
「GPT-5만 기다리라.」
그 문장이 깊은 오해를 드러냅니다.
대화 한 토막을 ChatGPT에 던지고 작동하는지 묻습니다 — AI는 그 한 번의 주고받음만 볼 수 있습니다. 두 인물 사이의 스무 장에 걸친 얽힌 내력? AI는 모릅니다. 이 대화가 장례식에서 벌어지는지 결혼식에서 벌어지는지? AI는 모릅니다. 책 전체가 다크 코미디로 향하는지 고전 비극으로 향하는지? 그것 또한 모릅니다.
모델이 아무리 강력해도 시력 상실은 시력 상실입니다. 책 전체를 다 읽은 평범한 독자가, 단 한 장면만 본 천재 AI를 앞섭니다. 매번.
그러니 진짜 질문은 한 번도 「AI가 충분히 똑똑한가?」가 아니었습니다. 늘 「AI가 얼마나 볼 수 있는가?」였습니다.
Slima의 글쓰기 스튜디오는 책 전체 구조 — 장, 인물 프로필, 세계관 메모, 아웃라인 — 를 하나의 프로젝트에 담습니다. AI Assistant는 지금 열린 파일만 보는 게 아닙니다. 프로젝트 전체 맥락을 이해합니다. 「이 인물의 결정이 말이 됩니까?」라고 물으면, 앞선 장에서 그녀가 한 말과 행동까지 거슬러 추적할 수 있습니다.
이건 「더 똑똑한 답」이 아닙니다. 더 잘 알고 답하는 것입니다. 그 차이는 어마어마합니다.
버전 관리: 작가에게 가장 과소평가된 필요
프로그래머는 결코 돌아가고 있는 코드를 직접 편집하지 않습니다. 절대로.
그들은 브랜치를 만들어 그 위에서 실험하고, 확신이 설 때에만 본선으로 합칩니다. 무엇이 부서졌습니까? 다시 돌아갑니다. 아무 일도 일어나지 않았습니다. 이 습관 덕에 그들은 무엇이든 시도할 수 있습니다 — 가장 거칠고 무모한 실험도, 결과에 대한 부담 없이.
작가에게는 이 습관이 없습니다. 원하지 않아서가 아닙니다. 도구가 한 번도 그것을 제공하지 않았기 때문입니다.
결정적 분기점에 도달합니다 — 주인공은 살아야 하는가, 죽어야 하는가? 전통 도구는 선택을 강요합니다. 한 길을 고릅니다. 다른 길은? 영영 사라집니다. 그것이 어디로 이어졌을지 알 길이 없습니다.
Slima의 Version Control이 이것을 완전히 바꿉니다. 큰 개정을 시작하기 전에 Snapshot을 만듭니다 — 책의 현재 상태 전체를 얼려 두는 것입니다. 다른 방향을 탐색하고 싶습니까? Branch를 엽니다. 본선과 브랜치를 자유롭게 오가고, 차이를 비교하며, 언제든 과거의 어떤 상태로든 돌아갑니다.
Branch는 코드보다 픽션에 더 중요합니다. 인물이 죽는 버전 — 끝까지 써 보고, 뜻밖의 정서적 깊이를 열어 준다는 사실을 발견합니다. 그녀가 사는 버전 — 결국 평탄해진다는 것을 알게 됩니다. Branch가 없다면 그 발견은 결코 일어나지 않습니다. 그 갈림길에서 대부분의 작가는 「안전한」 길을 고릅니다.
무언가를 망쳤습니까? 한 번 클릭으로 되돌립니다. 사소하게 들립니다. 그러나 그것이 실제로 바꾸는 것은 집필 중인 당신의 심리입니다 — 「이미 있는 것을 조심스레 지키자」에서 「일단 해 보자, 언제든 돌아갈 수 있으니」로.
AI 베타 리더로 이야기를 시험하라
초고가 끝났습니다. 베타 리더를 찾습니다. 이 워크플로는 수백 년간 존재해 왔습니다.
문제는 워크플로 자체가 아닙니다. 시간입니다. 자원해 줄 독자를 찾는 데 며칠. 그들이 다 읽어 줄 때까지 몇 주. 돌아오는 피드백은 — 「꽤 괜찮았어」 또는 「몇 군데가 좀 늘어졌어.」 손쓰기에는 너무 모호합니다. 피드백이 도착할 즈음에는 한두 달이 지나 있습니다. 그 부분들을 쓸 때 무엇을 생각하고 있었는지? 진작 사라졌습니다.
AI 베타 리더는 사람 독자를 대체하지 않습니다. 사람의 직관, 정서적 반응, 문화적 통찰 — 대체 불가입니다. 그러나 AI 베타 리더는 다른 일을 합니다. 초고를 마친 그날 구조적 피드백을 돌려줍니다.
AI 베타 리더 각각은 고유한 페르소나를 지닙니다. 페이싱에 민감한 리더는 늘어지는 곳마다 「여기는 건너뛰고 싶었다」고 표시합니다. 논리 구멍 사냥꾼은 「그녀가 어떻게 이 사실을 알았습니까? 앞에서 설명된 적이 없습니다」 하고 묻습니다. 상업적 잠재력을 평가하는 리더는 도입부가 독자를 페이지 너머로 끌어갈 수 있는지 가늠합니다.
핵심은 — AI Assistant가 책 전체를 읽었기 때문에 이 피드백은 무작위 흠집 잡기가 아니라는 점입니다. 3장이 무엇을 말했는지 진정으로 알고 있습니다. 그러므로 17장의 모순을 짚어 줄 때, 그 모순은 실재합니다.
한 장을 마치고 그날 다각도의 분석을 받습니다. 사고가 아직 생생할 때 개정합니다. 기다림이 없습니다.
프로젝트 관리: 소설을 문서가 아니라 프로젝트로 다루라
긴 소설 안에 얼마나 많은 것이 묻혀 있습니까?
서른 개의 장. 열다섯 명의 인물 프로필. 마법 체계 규칙서. 세 편의 역사 자료. 메인 타임라인 하나. 서브플롯 타임라인 네 개. 끝내 놓지 못한 삭제 단어 3만.
모든 것을 하나의 Word 파일에 욱여넣으면 — 그 파일은 미궁이 됩니다. 스무 개 파일로 쪼개면 — 창 갈아타기만으로도 하루에 쉰 번 집중을 깨뜨립니다.
File Tree는 프로그래밍 IDE의 설계를 빌립니다. 소설 전체가 하나의 프로젝트입니다. 장은 한 폴더에, 인물 프로필은 다른 폴더에, 세계관 메모는 세 번째 폴더에. 명료한 위계, 한눈에 찾아지는 모든 것.
12장을 쓰다가 갑자기 악역의 본명을 확인해야 합니까 — Cmd+P로 Quick Open이 열립니다. 두 글자를 치면 퍼지 매칭이 곧장 그 인물 프로필로 점프합니다. 2초. 지금 쓰고 있던 페이지를 떠나지 않은 채로.
Cmd+로 Split Window를 엽니다. 왼쪽에 12장, 오른쪽에 악역의 프로필. 두 문서를 나란히 두고, 쓰면서 동시에 참조합니다. 눈이 화면을 떠나지 않습니다.
이런 각각이 절약하는 시간은 사소합니다 — 2초, 3초. 그러나 하루 백 번이면 그 초들이 쌓여, 몰입 상태와 산산조각 난 주의의 차이가 됩니다. 도구가 사고의 속도를 따라잡을 때, 비로소 글쓰기가 시작됩니다.
Offline-First: 어디서든 씁니다
카페의 Wi-Fi가 끊깁니다. 비행기 안에는 인터넷이 없습니다. 기차가 터널을 통과하는 20분.
Google Docs는 이 순간들에 읽기 전용으로 바뀝니다 — 더 나쁘게는, 편집은 허용하지만 다시 연결됐을 때 제대로 동기화될지 보장하지 못합니다. API에 의존하는 AI 도구는 완전히 백지가 됩니다.
Slima의 아키텍처는 오프라인 우선입니다. 모든 데이터가 로컬 기기에 있습니다. 네트워크가 없습니까? 집필, 편집, File Tree에서의 파일 정리 — 전부 정상 작동합니다. 다시 온라인이 되면 자동 동기화.
AI Assistant는 연결이 필요합니다 — 대규모 언어 모델은 클라우드에서 돌고, 그건 피할 길이 없습니다. 그러나 글쓰기 자체에는 네트워크가 전혀 필요하지 않습니다. 영감이 올 때, 신호 강도부터 확인할 일이 없습니다.
올바른 도구를 어떻게 고를까
짧은 픽션 — 2만 단어 이하 — 은 솔직히 전용 집필 도구가 필요하지 않습니다. Word에 ChatGPT 정도면 충분합니다. 맥락 한계도 발목을 잡지 않고, 버전 관리 압박도 낮습니다.
장편은 다릅니다. 10만 단어를 넘어가면, 세 가지가 「있으면 좋은 것」에서 「없으면 기능 불가」로 옮겨 갑니다.
AI는 책 전체를 볼 수 있어야 합니다. 단편이 아니라. 전부. 그렇지 않으면 그가 주는 모든 조언은 맥락에서 떨어진 추측입니다. 맞는지 틀린지? 당신이 판단하십시오. 그러나 한 책에 마흔 명의 인물과 열두 개의 서브플롯이 있을 때, 「당신이 판단하십시오」는 그 자체가 문제의 일부입니다.
Version Control은 화려한 부가 기능이 아닙니다. 작가가 위험을 감수할 수 있게 해 주는 인프라입니다. 「다른 이름으로 저장」은 버전 관리로 가장한 인지 부하입니다.
프로젝트 구조는 책 한 권의 복잡성을 지지해야 합니다. 서른 개의 장, 열두 편의 참고 문서, 자료, 타임라인 — 이것들에는 정리 체계가 필요하지, 비슷한 이름의 .docx로 가득 찬 폴더가 아니라.
도구는 중요하지 않다 — 이야기를 끝내는 것이 중요하다
마지막 한 가지. 위의 모든 것과 다소 모순됩니다 —
도구 고르기에 너무 많은 시간을 들이지 마십시오.
이 글은 도구의 차이에 수천 단어를 쏟았습니다. 그러나 도구 고르기가 글쓰기를 미루는 핑계가 된다면, 도구 자체가 문제가 됩니다. 완벽한 도구는 존재하지 않습니다. 어떤 도구든 신경에 거슬리는 별난 점, 학습 곡선, 부족한 기능이 있습니다.
하나를 고르십시오. 쓰기 시작하십시오. 맞지 않게 느껴집니까? 갈아타십시오.
오로지 한 가지만 중요합니다. 이야기가 앞으로 나아갔는가? 오늘 자리에 앉아 몇백 단어를 썼는가?
AI는 도울 수 있습니다. 좋은 도구는 마찰을 줄입니다. 그러나 이야기를 세상에 존재하게 하는 유일한 것은 한 가지 행위입니다 — 자리에 앉아 쓰는 것.
이 글을 닫으십시오. 글쓰기 스튜디오를 여십시오.
오늘의 첫 단어를 쓰십시오.