Scribe와 Notion: 공동 아웃라인에서 단독 원고로의 이양

Scribe와 Notion: 공동 아웃라인에서 단독 원고로의 이양

2026년 현재, 많은 집필 모임에서 Notion은 가장 매끄러운 협업 도구입니다. “심층적인 개인 지식 베이스” 영역에 자리한 Obsidian과 달리, Notion의 진짜 강점은 여러 사람이 같은 콘텐츠를 동시에 보고 편집하고 논의할 수 있다는 점에 있습니다. 공동 저자가 있는 소설 모임, 합작 IP 개발, 처음부터 끝까지 함께 가는 책임 편집자가 있는 저자 — 이런 경우에는 Notion 안에 방대한 프로젝트 공간이 자라기 마련입니다. 아웃라인, 인물 설정, 리서치, 토론 기록, 출간 일정이 같은 워크스페이스에 모두 들어 있습니다.

그러나 Notion은 실제 산문을 쓰기에 좋은 곳은 아닙니다. 블록 기반 에디터는 길게 이어지는 독서에 잘 맞지 않습니다. 커서 이동, 페이지 전환, 단어 수 표시가 모두 평문 에디터보다 반박자씩 느립니다. “페이지” 개념은 책의 챕터 경계를 흐릿하게 만듭니다. “3장의 후반부가 하위 페이지 안에 들어 있는” 식의 구조적 혼란이 쉽게 생깁니다. 보다 실용적인 문제는 Notion이 클라우드 협업 도구라는 점입니다. 편집하려면 모든 것이 인터넷 연결을 필요로 합니다. 이는 장편 집필이 요구하는 몰입 상태에 좋지 않고, 아직 발표되지 않아 엄격한 접근 통제가 필요한 원고에도 좋지 않습니다.

Catalpas Atelier Scribe와 Notion의 관계는 “초기 협업 → 후기 마무리”에 가깝습니다. 진정으로 여러 사람이 필요한 부분 — 아웃라인 합의, 자료 수집, 일정 조율 — 은 Notion에 남깁니다. “혼자 챕터 단위로 쓰는 일”과 “EPUB·인쇄 PDF 내보내기”는 Scribe가 맡습니다. 두 도구는 충돌하지 않으며, 중요한 것은 이양이 적절한 시점에 일어나는 일입니다.

Notion은 아웃라인용으로 좋고, 산문 집필용으로는 아닙니다

많은 저자가 시범 기간 동안 Notion의 유연성에 매료되어 “여기서 본문도 다 써 버릴 수 없을까?” 하는 생각을 합니다. 단기적으로는 가능합니다. 2만 단어 이하의 중편이나 단선 논픽션이라면 Notion이 감당합니다. 하지만 8만 단어 이상의 장편 원고를 Notion에 넣고 시간이 흐르면 몇 가지 문제가 수면 위로 떠오릅니다.

첫째, 장문 편집 성능. 한 페이지가 수만 단어를 넘기면 Notion의 커서 응답성, 자동 저장, 스크롤에 모두 체감 가능한 지연이 생깁니다. 이는 장문 문서 위에서 동작하는 블록 기반 아키텍처의 내재적 속성이며, 단일 버전 업데이트로 영구히 해결되지 않습니다. 둘째, 챕터 구조의 파편화. Notion의 하위 페이지 체계는 챕터마다 하위 페이지로 쪼개도록 유도하지만, 조판을 일괄적으로 조정하거나 전체 단어 수를 집계하거나 처음부터 끝까지 곧장 읽고자 할 때 하위 페이지를 가로지르는 작업은 고통스러워집니다. 셋째, 오프라인과 백업. Notion의 오프라인 모드는 여전히 제한적이며, “내 파일은 내 하드디스크에 있어야 한다”는 장편 원고의 기본 요구를 충족하지 못합니다.

이는 설계 결함이 아니라 “협업 워크스페이스”와 “장편 집필 도구” 사이의 내재적 차이입니다. Notion은 자기 영역에서는 여전히 훌륭합니다.

이양 지점: 아웃라인 고정 + 1장 잠금 직전

언제 Notion에서 Scribe로 전환해야 할까요? 두 신호가 겹치는 시점이 이양 지점입니다.

신호 1: 아웃라인 고정 — 협력자(또는 편집자)와 Notion에서 아웃라인에 합의했고, 챕터 순서, 핵심 플롯 비트, 캐릭터 아크의 80% 이상이 잠겼습니다. 앞으로의 변경은 국지적입니다. 아웃라인이 여전히 크게 수정되는 중이라면 이른 전환은 양쪽을 반복해서 동기화하느라 몇 시간을 태우는 결과만 낳습니다.

신호 2: 1장 잠금 직전 — 본문을 아직 시작하지 않았거나, 시험 삼아 짧은 장면만 써 본 정도입니다. Notion에서 이미 5~6개 챕터를 초고로 썼다면 “기존 산문은 어떻게 할 것인가”라는 추가 질문에 마주치게 됩니다. 그 경우 현실적인 선택은 기존 산문을 Scribe에 “초안 자료”로 복사해 두고 Scribe 안에서 챕터별로 다듬는 것입니다. “무손실 마이그레이션”을 시도하지 마십시오.

전환 이후에도 Notion 아웃라인 페이지를 삭제하지 말고, “참조 상태”라고 명시적으로 표시하십시오. 앞으로 아웃라인이 바뀌면 Scribe 프로젝트의 아웃라인 뷰에서 먼저 바꾸고, 협력자가 볼 수 있도록 Notion에 역방향으로 채워 넣습니다. 핵심 규칙은 단순합니다. 산문과 아웃라인의 최신 버전은 오직 한 곳에만 존재할 수 있다.

Notion 내보내기 함정: 중첩 토글, 데이터베이스, 하위 페이지

Notion을 Markdown으로 내보내면 정보가 손실됩니다. 가장 흔한 세 가지 손실을 미리 알아 두면 전환 중에 놀랄 일이 줄어듭니다.

중첩 토글 — Notion의 토글 블록(클릭하여 펼치기/접기)은 Markdown 내보내기에서 들여쓰기가 있는 일반 제목이 되며, 2단 이상 깊이의 토글은 대개 뒤엉킵니다. 아웃라인 깊이가 토글 접기에 의존한다면 내보내기 전에 H2/H3 제목 구조로 평탄화해 두십시오.

데이터베이스 — Notion의 데이터베이스(캐릭터 시트, 챕터 테이블, 할 일 목록)는 일반 테이블이나 링크 더미로 내보내지며, 구조적 관계 대부분이 사라집니다. 가장 안전한 방법은 내보내기 전에 중요한 데이터베이스마다 스크린숏을 찍고 핵심 필드를 별도 파일의 Markdown 테이블에 복사하는 것입니다. “내보낸 뒤에 관계를 다시 만든다”는 접근은 사실상 통하지 않습니다.

하위 페이지 — 하위 페이지는 Markdown 내보내기에서 기본적으로 별도의 폴더와 파일이 되고, 링크 관계가 흩어집니다. Notion에서 콘텐츠를 조직하기 위해 하위 페이지를 적극적으로 사용했다면, 내보낸 뒤에는 손으로 다시 꿰매야 하는 느슨한 .md 파일 더미가 남습니다.

이 함정들을 알고 나면, 최선의 선택은 “아웃라인 + 캐릭터 시트의 핵심 필드”만 옮기는 것이지, Notion 워크스페이스 전체를 로컬에 거울처럼 복제하려 들지 않는 것입니다. Notion 협업 공간은 살아남아 계속 유지되어야 합니다. 협업 과정의 운반체이지, 원고 자체는 아니기 때문입니다.

출판 이후: 지식이 가는 자리

책이 완성되어 출고된 뒤에는 Notion의 프로젝트 페이지에도 계획이 필요합니다. 흔한 두 가지 선택지가 있습니다.

참조 자료로 보관 — 워크스페이스를 “완료”로 표시하고 권한을 읽기 전용으로 전환한 뒤, 앞으로의 프로젝트를 위한 참조 라이브러리로 Notion에 남겨 둡니다. 같은 협력자들과 다음 책에서도 함께 일할 예정이라면 비용이 가장 적은 선택입니다.

개인 지식 베이스로 추리기 — Obsidian 볼트나 비슷한 장기 시스템을 함께 유지한다면, 프로젝트를 가로질러 재사용 가능한 콘텐츠(세계관 설정, 공통 설정, 리서치 자료)를 내보내 개인 베이스에 병합합니다. 프로젝트 고유의 일정과 토론 기록은 Notion에 남깁니다.

하지 말아야 할 일: “혹시 모르니까”라며 Notion의 모든 것을 Scribe 프로젝트나 로컬 보관함에 욱여넣지 마십시오. Scribe 프로젝트는 이 책의 완성 원고이지, 프로젝트의 보관함이 아닙니다. 모든 것을 욱여넣으면 프로젝트 파일이 부풀고 내보내기 시점에 이상한 조판 결함이 생깁니다.

Notion과 Scribe의 장기 공존에는 단순한 근거가 있습니다. 협업은 사라지지 않고(다음 책에서도 편집자와 아웃라인을 잡아야 할 수 있음), 마무리 공정도 사라지지 않습니다(책마다 납품할 EPUB과 인쇄 PDF가 필요함). 각 도구가 잘하는 영역을 맡으면 워크플로는 훨씬 깔끔해집니다.

Scribe를 열어 Notion 공동 아웃라인 다음 단계에 어떻게 끼워 넣는지 확인해 보십시오 →

함께 읽어 보면 좋은 글

• Scribe 협업 허브 — 다른 집필·메모·검수 도구와의 워크플로 진입점
• Scribe와 Obsidian: 지식 베이스 + 원고의 2단계 워크플로 — Obsidian에서 개인 지식 베이스를 함께 유지한다면