Scribe와 Obsidian: 지식 베이스 + 원고의 2단계 워크플로

Scribe와 Obsidian: 지식 베이스 + 원고의 2단계 워크플로

2026년 현재, Obsidian은 독립 저자들 사이에서 가장 많이 쓰이는 메모·지식 도구 중 하나입니다. 양방향 링크, 로컬 Markdown 파일, 플러그인 생태계 덕분에 “장기적인 참조 라이브러리를 키우는” 일에서는 거의 적수가 없습니다. 많은 저자가 책 한 권을 끝낸 뒤 돌아보고 깨닫습니다. 진짜 시간 투자는 초고에 들어간 수백 시간이 아니라, 몇 년째 운영해 온 — 캐릭터 파일, 연대표, 세계관 디테일로 가득한 — 볼트였다는 사실을 말입니다.

문제는 Obsidian의 강점이 “마무리” 단계에서는 곧 약점이 된다는 점입니다. 볼트는 원고가 아닙니다. 선형적인 “챕터 순서” 개념이 없고, PDF/EPUB 내보내기에서 위키링크는 일반 텍스트가 되며, 템플릿 플러그인이 만든 YAML 블록은 본문으로 새어 들어옵니다. 흩어진 메모 백여 개는 통일된 조판이나 폰트 체계를 공유하지 않습니다. 이는 설계 결함이 아니라 “지식 도구”와 “원고 도구” 사이의 내재적 차이입니다. 볼트를 그대로 인쇄로 보내려는 것은 잘못된 도구를 쓰는 일입니다.

이 흐름에서 Catalpas Atelier Scribe는 Obsidian의 대체재가 아닙니다. Obsidian의 하류에 자리합니다. Obsidian은 장기적인 성장 — 세계관, 캐릭터 시트, 리서치 메모, 영감의 파편 — 을 짊어집니다. Scribe는 “이 한 권의 책” — 선형 챕터, 조판, 최종 EPUB과 인쇄 PDF — 를 맡습니다. 경계가 그어지면 “이 메모는 어느 쪽에 속하나?”나 “챕터 초고를 계속 볼트 안에서 다듬어야 하나?”로 고민하는 일이 사라집니다.

볼트는 원고가 아닙니다: 억지로 만들지 말 것

Obsidian을 처음 써 보는 많은 저자가 볼트 안에서 챕터를 직접 써 보는 실험을 합니다. 메모 하나당 챕터 하나, 01-prologue.md, 02-chapter-1.md 식의 이름. 10챕터까지는 괜찮아 보입니다. 50챕터에 이르고, 수정 패스가 쌓이며, “12장 앞에 회상 장면을 끼워 넣고 싶다” 같은 구조 변경이 들어오면 문제가 쌓이기 시작합니다. Obsidian의 파일 탐색기는 장편 원고용 챕터 정렬, 일괄 재정렬, 버전 스냅숏을 제공하지 않습니다. 검색은 “어느 메모가 이 캐릭터를 언급했나”에는 강하지만 “이 단락의 지난 초고와 지금 초고가 어디가 달라졌나”에는 약합니다.

진짜 골치는 내보내기입니다. Obsidian의 공식 PDF 내보내기는 Markdown의 렌더 스타일을 그대로 보존하지만, 이는 인쇄에 충분히 정밀하지도, 안정적이지도 않습니다. 커뮤니티 플러그인(Pandoc Plugin, Better Export)은 더 복잡한 내보내기를 할 수 있으나 설정 비용이 높고, Obsidian이나 플러그인이 업그레이드될 때마다 파이프라인이 갑자기 깨질 수 있습니다. “볼트 안에서 챕터를 써도 되는가”의 진짜 질문은 기술적 가능성이 아니라, 초고가 80% 완성된 시점에 볼트가 도움이 되는지 발목을 잡는지입니다. 책 한 권을 완성해 본 거의 모든 저자가 말합니다. 어느 시점에 이르면 볼트가 발목을 잡기 시작한다고.

2단계 워크플로: 어디에서 전환할 것인가

보다 지속 가능한 접근은 Obsidian과 Scribe를 명확한 이양점이 있는 두 단계로 나누는 것입니다.

1단계(Obsidian에서) — 아직 형태를 잡지 못한 모든 것이 여기에 삽니다. 캐릭터 파일, 세계관, 리서치 클리핑, 영감의 파편, 대략의 챕터 순서, 챕터마다의 첫 한두 단락 시험 산문까지도. 이 단계의 특징은 “정보 밀도가 높고 구조가 느슨하다”는 점이며, 필요한 것은 볼트의 양방향 링크와 검색입니다. 다음 십 년의 집필을 위한 토대로서 장기 운영되는 볼트는 프로젝트를 가로질러 재사용할 수 있는 자산입니다.

이양 지점 — 특정 프로젝트의 아웃라인이 안정되어 “정해진 순서대로 챕터를 차례차례 본문으로 쓴다”는 단계로 들어갈 준비가 되면 전환의 때입니다. 흔한 신호는 챕터 제목의 80% 이상을 나열할 수 있고 각 챕터를 한두 문장으로 요약할 수 있는 시점입니다. 그 이전에는 Obsidian에 머무는 것이 옳고, 그 이후에는 머무는 것이 진행을 더디게 만듭니다.

2단계(Scribe에서) — 아웃라인을 독립된 Scribe 프로젝트에 떨어뜨립니다. 여기에서는 구조가 “챕터”를 일급 시민으로 다루고, 조판과 폰트가 통일되며, EPUB과 인쇄 PDF로 가는 내보내기 경로가 있습니다. 이 순간부터 산문의 최신 버전은 Scribe 프로젝트에만 존재하며, 볼트 안의 챕터 초고(있다면)는 “참조”로 강등되어 더는 편집되지 않습니다.

이 2단계 접근의 핵심은 기술이 아니라 규율입니다. 어떤 결과물이 어떤 도구 안에 있을지 명시적으로 결정하고, 산문의 “최신 버전”이 양쪽에 동시에 살지 못하게 하십시오. 산문을 양쪽에서 유지하기 시작하는 순간 작업량은 1.5배로 부풀고, 버전 불일치 위험은 곱셈으로 늘어납니다.

자산 이전: 무엇을 가져가고 무엇을 남길 것인가

2단계가 시작되면 볼트에서 일부를 가져오게 되지만, 전부는 아닙니다.

가져갈 것: 이 프로젝트의 챕터 아웃라인(볼트에서 작성된 경우), 캐릭터 카드의 핵심 필드(이름, 관계, 책 전체를 관통하는 핵심 세계관), 그리고 원고에 직접 나타나야 하는 인용·자료. 이런 항목들은 집필 중 반복적으로 참조되며, 그때마다 도구를 바꾸는 일은 낭비입니다. 손으로 복사하십시오. “일괄 동기화”를 시도하지 마십시오. 일괄 동기화 시스템은 그 자체로 또 하나의 장기 유지보수 프로젝트이며, 독립 저자에게 좋은 거래가 아닙니다.

남겨 둘 것: 프로젝트를 가로지르는 세계관(여러 책이 같은 세계관을 공유한다면), 리서치 메모(3권에서도 필요할 수 있음), 그리고 영감의 파편(대다수는 이 책에 들어가지 않을 것). 이것들은 Obsidian에 남기고 필요할 때 꺼내십시오. Scribe 프로젝트에 욱여넣으면 원고 파일이 부풀어 오릅니다.

이전 시 서식 함정: 볼트에서 복사·붙여넣기로 가져오는 텍스트의 가장 흔한 오염원 두 가지는 위키링크([[캐릭터 이름]])와 템플릿이 만든 YAML 블록입니다. 위키링크는 Scribe에서 자동 해석되지 않으므로 가져오기 전에 일반 텍스트로 변환해야 합니다. 또는 Obsidian의 “Copy as Markdown”을 써서 위키 문법을 제거하십시오. Scribe 프로젝트가 실제로 쓰는 필드가 아닌 YAML 블록은 그냥 삭제하십시오. 어느 단계도 어렵지 않지만, 건너뛰면 내보내기 시점에 “왜 이 단락만 이상하게 조판되지” 하는 버그 사냥이 시작됩니다.

두 도구의 장기 공존: 임시 셋업이 아닙니다

많은 “도구 마이그레이션” 글은 종착지를 “모든 것을 한 도구로”라고 전제합니다. Obsidian + Scribe는 마이그레이션 관계가 아니라 장기 공존 관계입니다. 이유는 단순합니다. 볼트는 이 책이 출간된 뒤에도 멈추지 않고 자라는 10년짜리 자산이고, Scribe 프로젝트는 한 권의 책의 “완성 상태”이며, 다음 책은 새 프로젝트를 엽니다. 두 도구의 수명 주기는 애초에 동기화되어 있지 않습니다.

이 사실을 받아들이면 워크플로가 깔끔해집니다. “언젠가 다 합쳐야 하지 않나?”라는 고민이 사라지고, “실시간 양방향 동기화” 같은 묘기에 시간을 쓰지 않게 됩니다. Obsidian은 계속해서 지식 베이스를 키우고, Scribe는 계속해서 다음 책을 납품합니다. 두 단계 사이의 이양은 수동적이고 의도적이며 프로젝트별로 이루어집니다. 그 자체가 좋은 일입니다. 전환 지점에서 “이 아웃라인이 정말 안정적인가?”를 다시 확인하게 만들기 때문입니다.

이미 Obsidian에 큰 볼트가 있고 “이걸 다음 책으로 어떻게 옮기지”에서 막혔다면, 필요한 것은 아마 Obsidian 플러그인이 더 있는 일이 아닐 것입니다. “마무리” 공정을 그 일에 특화된 도구에 떼어 주는 일입니다. 그게 Scribe가 되고자 하는 것입니다.

Scribe를 열어 Obsidian 볼트의 하류에 어떻게 끼워 넣는지 확인해 보십시오 →

함께 읽어 보면 좋은 글

• Scribe 협업 허브 — 다른 집필·메모·검수 도구와의 워크플로 진입점
• 로컬 우선 글쓰기 소프트웨어 — 로컬 파일과 Markdown에 대한 좀 더 긴 논의