소설 쓰기, Plotiar와 Notion 중 언제 무엇을 쓸까

"완벽한 Notion 소설 템플릿"을 만드는 데 석 달을 썼어요. 그 템플릿은 지금도 제 작업 공간 어딘가, THE NOVEL OS라고 대문자로 제목을 붙인 위키 페이지 뒤에 있어요. 소리치듯 이름을 지으면 좀 더 그럴듯해 보일 줄 알았거든요. 인물마다 속성이 열네 개씩 붙은 데이터베이스가 있어요. 장면마다 등장인물을 전부 잇는 관계형 속성이 있어서, "마커스가 나오는 장면"으로 필터를 걸면 바로 답이 나와요. 챕터별 단어 수를 자동으로 합산해 실시간으로 갱신하는 롤업도 있어요. 어떤 기준으로 봐도 꽤 인상적인 정보 설계예요.

그 안에서 책을 끝낸 적은 한 번도 없어요.

"그 템플릿으로 쓰려던 책을 끝내지 못했다"는 얘기가 아니에요. 열성적인 Notion 사용자로 지낸 18개월 동안, 책을 한 권도 끝내지 못했어요. 문제가 제 의지가 아니라는 걸 인정하기 전까지요. 진짜 문제는 세상에서 가장 우아한 서류 캐비닛을 만들어 놓고 그걸 책상으로 착각했다는 거였어요.

Notion을 깎아내리려는 글이 아니에요. Notion은 지난 10년 동안 나온 소프트웨어 가운데 손꼽히게 훌륭한 도구예요. 다른 이야기를 하기 전에 이 점부터 분명히 해 두고 싶어요. "Notion 대안"을 다루는 글은 대부분 이 도구가 별로인 척하는데, 사실이 아니니까요. Notion의 매력은 진짜이고, 그럴 만한 이유가 있어요. 다만 Notion이 소설을 정리하는 데는 탁월하면서 정작 쓰는 데는 서툰 데에는 구조적이고 분명한 이유가 있어요. 그 이유가 눈에 들어오면 지난 18개월을 두고 자책하는 걸 멈추고, 초고를 실제로 끝낼 수 있는 작업 환경을 꾸리기 시작하게 돼요.

작가라면 누구나 결국 Notion을 열게 되는 이유

문서 여러 개를 흩어 놓고 소설을 계획해 본 적이 있다면 Notion의 매력은 정말 뿌리치기 어려워요. Notion에서는 데이터베이스끼리 서로 이어져요. 인물을 그 인물이 나오는 모든 장면, 모든 장소, 모든 플롯 줄기와 연결할 수 있고, 연결은 양쪽에서 자동으로 갱신돼요. 챕터용 칸반 보드, 글쓰기 연속 기록용 캘린더, 세계관 이미지용 갤러리 보기, "첫 등장" 순으로 정렬한 등장인물 표까지 모두 한 작업 공간 안에 만들 수 있어요. 형식이 자유로워서 남이 만든 템플릿을 받는 대신 구조를 직접 지어낼 수 있고요.

티아고 포르테가 『세컨드 브레인』(Building a Second Brain)에서 정리한 PARA 방법, 즉 프로젝트, 영역, 자료, 보관이라는 분류는 소설가가 아니라 고객 파일과 회의록을 정리하는 지식 노동자를 위해 나왔어요. 그런데도 소설에 대 보면 소름 끼칠 만큼 딱 들어맞아요. 원고는 프로젝트가 되고, 인물과 세계관과 조사 자료는 자료가 되고, 예전 초고는 보관이 돼요. "Notion 소설 템플릿"을 검색하면 이 논리를 그대로 따른 "소설 OS" 템플릿이 수십 개 나와요. 대부분 무료이고, 대부분 예쁘고, 장담하건대 대부분 만든 사람이 그 템플릿으로 계획한 소설을 아직 끝내지 못했을 거예요. 흉보려는 말이 아니에요. 저도 그중 하나였고, 템플릿을 만드는 일 자체가 바로 매력이 슬그머니 함정으로 바뀌는 지점이라서 하는 말이에요.

함정은 이거예요. 데이터베이스를 만드는 일이 글을 쓰는 것처럼 느껴져요. 겉모습이 똑같거든요. 앱을 열고, 결정을 내리고, 작업을 마칠 때 바라보며 뿌듯해할 결과물이 남아요. 하지만 속성 열네 개짜리 인물 데이터베이스는 장면이 아니에요. 장면을 위한 비계일 뿐이에요. 그리고 비계는 실제 원고 한 챕터와 달리 끝없이, 그것도 즐겁게 늘릴 수 있어요. 더할 속성은 언제나 하나 더 있어요. "데이터베이스는 다 됐으니 이제 가서 써"라고 말해 주는 자연스러운 끝은 오지 않아요. 원고에는 그런 끝이 있어요. 챕터는 끝나요. 데이터베이스는 내가 멈추지 않는 한 끝나지 않아요.

Notion이 정말 잘하는 것

Notion이 어디서 명성을 얻었는지 구체적으로 짚어 둘게요. 이 비교가 공정하려면 꼭 필요한 이야기라서요.

자료 조사용 데이터베이스로서 Notion은 글쓰기 전용 도구들 사이에 사실상 맞수가 없어요. 역사 소설을 쓰면서 17세기 암스테르담 해상 무역로에 관한 자료 스크랩, 인용문, 반쯤 정리된 사실을 300개쯤 쌓아 가고 있다면, 그 뒤죽박죽을 정리하는 데는 Notion의 태그와 필터, 상호 참조가 소설가 전용 도구 대부분보다 나아요. 여섯 권에 걸쳐 마흔 명이 되풀이해 나오는 시리즈라면 관계형 구조가 정말 유용해요. "이 인물이 나오는 책은 어느 어느 권이지?" 하고 물으면 원고 여섯 권을 뒤질 필요 없이 바로 답이 나와요. 장소가 세력과, 세력이 다시 소속 인물들과 이어지는 세계관 위키로 쓰면, Notion은 코드 한 줄 없이도 진짜 백과사전에 가까운 일을 해내요.

소설과는 전혀 상관없는 이야기도 하나 짚어 둘 만해요. 이 매력의 밑바닥에 깔린 원리거든요. 독일 사회학자 니클라스 루만은 제텔카스텐이라는 종이 카드 시스템을 만들었어요. 카드 9만 장쯤에 한 장당 생각 하나씩 적고, 손으로 매긴 번호로 관련 카드끼리 서로 가리키게 한 체계예요. 루만은 이걸로 평생 일흔 권이 넘는 책과 수백 편의 논문을 썼어요. Notion은 여러모로 제텔카스텐의 디지털 후손이에요. 잘게 쪼갠 메모를 촘촘하게 엮어, 구조를 위에서 정해 주는 대신 연결에서 저절로 떠오르게 하는 방식이죠. 정말 강력한 사고방식이고, 서로 얽힌 지식 체계를 쌓는 데는 더없이 좋아요. 다만 그것만으로는, 서로 사랑하는 두 사람이 부엌에서 해서는 안 될 말을 주고받는 장면 900단어를 쭉 이어 쓰는 방법이 되지 못해요.

8장쯤에서 탈이 벗겨지는 곳

지금부터는 Notion이 데이터베이스이기를 멈추고 워드프로세서 행세를 하기 시작하는 곳, 그래서 이음매가 드러나는 곳 이야기예요.

메모에는 그토록 유연한 Notion의 블록 기반 편집기가, 바로 그 구조 때문에 원고 6만 단어를 이어 쓰기에는 정말 불편한 곳이 돼요. 문단 하나, 줄 하나가 저마다 메타데이터와 렌더링 규칙을 지닌 독립된 블록이고, 앱은 그 블록들을 트리 구조 안에서 일일이 관리해야 해요. 회의록이나 프로젝트 요약 정도라면 괜찮아요. 하지만 챕터 하나 분량이 되면 성능 문제가 실제로 생기고, 원고 전체가 되면 더 심해져요. Notion의 긴 페이지는 화면을 그리는 쪽에서 보면 문서 한 편이 아니라 따로따로 관리되는 객체 수천 개이고, 글자 하나를 칠 때마다 그걸 전부 다시 계산해야 하니까요. Notion 페이지 하나에 챕터 하나를 통째로 써 본 사람이라면 2천 단어쯤 넘어가면서 나타나는 그 묘하게 맥 빠지는 지연을 알 거예요. 키를 누르고 글자가 뜨기까지 반 초쯤 걸리는데, 별것 아닌 것 같아도 문장의 리듬을 머릿속에 붙들고 쓰는데 문장이 손을 못 따라오면 그 반 초가 엄청 크게 느껴져요.

토글 목록, 콜아웃 블록, 삽입 데이터베이스, 색 글씨처럼 구조화된 메모에는 더없이 좋은 서식 기능들이 원고를 쓸 때는 오히려 방해가 돼요. 페이지가 없어요. 원고의 어디쯤에 와 있는지 감도 안 잡히고, 쪽 나눔도 없고, "이건 한 챕터이고 나름의 모양이 있어"라고 눈에 알려 주는 시각적 리듬도 없어요. 한 문단을 썼든 1만 1천 단어를 썼든 똑같아 보이는, 끝없이 내려가는 한 줄 기둥에 타이핑하는 거예요. 이 똑같음은 눈에 잘 안 띄지만 분명한 대가예요. 앤 라모트가 말한 "1인치짜리 액자", 눈앞의 작업 단위가 손에 쥘 만해 보일 때 더 잘 쓴다는 생각은, 그 단위가 전체와 실제로 달라 보여야 성립해요. Notion은 얼마나 썼든 늘 같은 밋밋한 스크롤을 보여 주니, "이 페이지만 쓰자"는 다짐이 붙잡을 시각적 손잡이가 없어요.

그리고 오프라인에서도 믿고 쓸 수 있다는 안심이 없어요. Notion은 쉬지 않고 클라우드와 동기화하고 대체로 잘 해내지만, 편집기의 반응 속도가 글쓰기 전용 도구와 달리 그 동기화 계층에 묶여 있어요. 문장을 쓰다 말고 페이지가 멈춘 채 구석에서 동기화 표시가 빙글빙글 도는 걸 본 작가라면 그 순간을 잊지 못해요. 회사로서의 Notion을 탓하려는 게 아니에요. 무엇이든 마음대로 다시 짤 수 있게 만든 메모 도구에게, 쓰는 문장 밑으로 감쪽같이 사라져야 하는 원고 편집기 노릇까지 시키면 무슨 일이 생기는지 설명하는 거예요. 둘은 다른 일이에요. Notion은 자기가 어느 쪽을 위해 만들어졌는지 솔직해요. 소설 계획 이야기를 솔직하게 하려면, 우리 대부분이 그렇지 않은 척했다는 걸 인정해야 해요.

글쓰기 전용 편집기가 실제로 주는 것

Plotiar는 바로 이 틈 때문에 생겼어요. 그냥 더 낫다고 주장하기보다 무엇이 다른지 설명할게요. "더 낫다"는 말은 구체적인 내용이 받쳐 주지 않으면 아무 쓸모가 없으니까요.

캔버스 편집기는 실제 페이지를 그려요. 쪽 나눔이 있는 진짜 A4 페이지, 인쇄된 원고와 같은 모습이라서, 문서가 끝없이 똑같은 스크롤이 아니라 쓰는 만큼 모양이 달라져요. 직접 느껴 보기 전에는 겉치레처럼 들릴 거예요. 차오르다 넘어가는 페이지는 라모트의 액자처럼 머릿속에 쥐고 있을 수 있는 단위지만, 끝없는 기둥은 그렇지 못해요. 댓글은 해당 줄 바로 옆 여백에 달려요. 사람 편집자가 메모를 남기듯이요. 특정 문단과 손으로 맞춰 봐야 하는 별도의 데이터베이스 항목이 아니에요. 그리고 편집기가 메모용 블록 구조를 빌려 온 게 아니라 처음부터 긴 원고를 위해 만들어졌기 때문에, 9만 단어짜리 원고도 2천 단어짜리처럼 빠릿빠릿하게 반응해요. 바탕의 문서 모델이 그 규모를 억지로 버티도록 고친 게 아니라 처음부터 그 규모에 맞춰 설계됐거든요.

구조를 계획하는 도구들도 원고와 같은 프로젝트 안에 있어요. 데이터베이스를 아무리 많이 만들어도 Notion이 줄 수 없는 부분이에요. Notion에는 플롯의 인과 사슬을 따라가는 전용 플로차트도, 서브플롯 네 개가 챕터마다 어떻게 엇갈리는지 보는 플롯 그리드도, 가계도도, 지도도 없으니까요. 표와 연결된 데이터베이스로 그중 몇 가지를 엉성하게 흉내 낼 수는 있어요. 저도 자기 자신을 참조하는 관계형 속성으로 그럭저럭 쓸 만한 인물 관계도를 만든 적이 있는데, 네 시간이 걸렸고 결과물은 분장한 스프레드시트처럼 보였어요. 전용 시각 도구는 같은 일을 몇 분 만에 해내고, 보이는 모습도 제 이름값을 해요. 현역 소설가들이 실제로 프로젝트를 정리하는 법에서 소개한 원고, 워크숍, 스크랩의 폴더 세 개 구조는 잘 만든 Notion 작업 공간이 지향하는 바와 사촌쯤 돼요. 차이는 Plotiar에서는 그 구조의 원고 쪽 절반이 진짜 글 쓰는 화면이라는 거예요. 원고인 척하는 데이터베이스 항목이 아니라요.

둘을 함께 쓰는 게 정말 맞을 때

그렇다고 솔직한 답이 "Notion을 완전히 버려라"라고는 생각하지 않아요. 그렇게 말하면 거짓말이에요. 원고를 다른 곳으로 옮긴 뒤에도 Notion이 계속 제 몫을 하는 작가들이 분명히 있으니까요.

자료 조사가 많은 프로젝트라면, 그러니까 1차 사료 스크랩이 수백 개인 역사 소설이나 여섯 권에 걸친 족보를 담은 시리즈 설정집, 루만에게 제텔카스텐이 쓸모 있었던 것만큼 상호 참조가 빽빽한 세계관 위키라면, Notion은 여전히 그런 자료를 담기에 정말 든든한 집이에요. 제가 18개월 동안 붙들고 있던 방식 말고 실제로 통하는 방식은 분업이에요. 원고는 문장 밑으로 감쪽같이 사라지게 만든 글쓰기 전용 도구에 두고, 원고가 앞뒤를 맞추는 데 필요한 모든 것을 담은 데이터베이스는 데이터베이스를 잘 담도록 만든 곳에 두는 거예요. 조사와 참조는 한쪽에서, 집필은 다른 쪽에서 해요. 둘이 같은 앱일 필요는 없어요. 같아야 한다고 믿는 것이야말로 이 모든 이야기에서 가장 흔하고 가장 비싼 실수라고 생각해요.

할 일	맡길 곳	이유
원고 집필	글쓰기 전용 캔버스 편집기	긴 원고, 쪽 나눔, 9만 단어에서도 빠른 반응에 맞춰 만들어짐
조사 자료와 출처	유연한 데이터베이스 도구	흩어진 사실 수백 개를 태그, 필터, 상호 참조로 정리
인물과 플롯 계획	전용 시각 도구	플로차트, 플롯 그리드, 가계도는 표로는 안 보이는 구조를 보여 줌
시리즈 전체의 연속성	관계형 데이터를 가장 잘 담는 쪽	시리즈마다 다름. 원고가 따로 있다면 어느 쪽이든 괜찮음

도구 갖추기와 진척을 헷갈렸을 때 치르는 대가를 생각하면 패트릭 로스퍼스가 자꾸 떠올라요. 『바람의 이름』(The Name of the Wind)은 2007년에 나왔어요. 그 속편의 속편인 『돌의 문』(The Doors of Stone)은 이 글을 쓰는 지금까지 나오지 않았고, 로스퍼스는 몇 년에 걸쳐 책을 끝내지 못하는 자신을 지켜보는 팬들의 압박에 대해 공개적으로 이야기해 왔어요. 다른 작가의 작업 과정을 안다고 할 생각은 없고, 남의 책을 밖에서 함부로 진단하지 않으려 조심하고 싶어요. 다만 그가 인터뷰에서 털어놓은 함정의 대략적인 모양, 그러니까 완벽주의, 그리고 다음 단어를 믿고 쓰려면 먼저 맞춰 놓아야 할 것이 자꾸만 늘어나는 느낌은, 저 말고는 아무도 읽지 않을 데이터베이스에 인물마다 속성을 열네 개씩 쌓으면서 제가 느낀 것과 같은 모양이었어요. 도구 갖추기에는 자연스러운 천장이 없어요. 챕터에는 있어요. 그 불균형이 위험의 전부예요.

정반대 방향으로 간 작가들도 눈여겨볼 만해요. 조지 R. R. 마틴은 여러 인터뷰에서, 특히 2014년 코넌 오브라이언 쇼에 나와 두고두고 회자된 자리에서, 『얼음과 불의 노래』를 지금도 WordStar 4.0이 돌아가는 DOS 컴퓨터로 쓴다고 말했어요. 자동 고침도, 추천도 없고, 친 글자를 화면에 띄우는 것 말고는 아무것도 못 하기 때문이래요. 모든 작가가 1985년으로 돌아가야 한다는 말이 아니에요. "도구가 할 수 있는 일의 양"과 "실제로 써지는 글의 양"이 정비례하지 않고, 어느 선을 넘으면 오히려 반비례한다는 말이에요. 인물마다 속성이 열네 개인 작업 공간과 속성이 하나도 없는 작업 공간은 각자의 방식으로 같은 문제를 풀려는 거예요. 문장이 태어날 만큼은 작가의 앞길을 비켜 주는 문제요. Notion은 모든 걸 내주고 필요한 것만 골라 쓰리라 믿는 방식으로 그 문제를 풀어요. 저를 포함해 우리 대부분은 그 믿음에 보답할 만큼 절제력이 있지 않아요.

한쪽 도구에 집중해야 할 때

프로젝트 초반인데 자료 조사나 상호 참조의 양이 정말로 작가 한 사람 머리로 감당할 수준을 넘는다면, 예를 들어 규모가 진짜로 큰 시리즈 설정집이나 문서고를 뒤져야 할 만큼 출처가 많은 역사 소설이라면, 그 층은 Notion이나 비슷한 도구에 맡기세요. 대신 원고까지 그 안에 들이지 않도록 단단히 선을 그으세요. 평범한 규모의 장편 한 편을 쓰는데, 원고를 쓰는 날보다 데이터베이스를 다듬는 날이 더 많다는 걸 알아챘다면, 그게 멈추라는 신호예요. 18개월을 두고 자책하라는 게 아니에요. 저도 제 18개월과는 어느 정도 화해했어요. 그냥 멈추고, 문장이 시작되면 알아서 비켜 주는 도구로 실제 집필을 옮기면 돼요.

THE NOVEL OS를 놓은 지 몇 달 지난 지금 제가 쓰는 기준은 단순해요. 작업을 마칠 때, 원고를 썼나, 아니면 이론상 원고가 들어갈 수도 있는 자리를 만들었나? 세 번 연속 뒤쪽이라면 아직 도구가 문제인 건 아니에요. 힘을 엉뚱한 데 쏟고 있는 거예요. 하지만 도구 자체가 뒤쪽을 앞쪽보다 쉽게 만든다면, 블록 편집기가 데이터베이스를 만들 때는 눈에 보이는 진척으로 상을 주고 챕터를 쓸 때는 지연으로 벌을 준다면, 결국 도구도 문제가 돼요. 제가 알아채기까지 1년 반이 걸렸던 것처럼요.

지금도 가끔 Notion을 열어요. 지금 쓰는 작품을 위한 자료 조사 데이터베이스가 있는데, THE NOVEL OS와 달리 이건 정말 자랑스러워요. 담아야 할 것만 딱 담고 그 밖에는 아무것도 없거든요. 출처, 어긋나면 안 되는 실제 역사적 사건의 연표, 30장쯤에서 실수로 겹치지 않게 이미 쓴 이름 목록이요. 원고는 이제 다른 곳에 있어요. Scrivener와도 솔직하게 비교해 본 도구, 끝없이 스크롤되는 대신 페이지가 넘어가는 캔버스가 있는 도구요. THE NOVEL OS는 지금도 미완성인 채 속성 열네 개 깊이로 남아 있어요. 아주 흔하고도 아주 구체적인, 책을 쓰지 않는 방식의 기념비예요. 지우지는 않아요. 그냥 더는 열지 않을 뿐이에요. 어떤 구조물은 내가 직접 지었기에, 그리고 결국 그 안에서 살지 않는 법을 배웠기에 남겨 둘 만해요.

Plotiar는 Notion과 함께 쓰기 좋아요. 자료 조사 데이터베이스는 이미 잘 쓰고 있는 곳에 그대로 두고, 원고는 문장 밑으로 감쪽같이 사라지도록 만든 캔버스에서 쓰세요. 무료로 프로젝트를 시작해 두 가지 일이 마침내 각자의 방을 갖게 되면 무엇이 달라지는지 확인해 보세요.