Scribe와 Word: docx로 이어지는 라운드트립 검수 워크플로
편집자, 협력자, 출판사는 종종 Word(혹은 그에 준하는 도구)만 받습니다. 본 글은 Scribe와 Word 사이의 docx 브리지, 검수 라운드 간 버전 관리, 그리고 언제 Word를 떠나 Markdown 쪽으로 돌아올지를 설명합니다.
Scribe와 Word: docx로 이어지는 라운드트립 검수 워크플로
저자가 무엇으로 쓰든, Microsoft Word는 2026년 현재도 출판·편집 워크플로에서 가장 흔한 “중간 포맷”으로 남아 있습니다. 인수 편집자, 라인 편집자, 문학 에이전트, 공동 저자, 전통 출판사 내부 검수 프로세스 — 대부분이 여전히 .docx를 공통 언어로 다룹니다. 몇 년째 Markdown으로 써 왔든, 셀프 출판을 계획하고 전통 채널을 건너뛰든, 파이프라인에 다른 사람이 한 명이라도 끼는 순간 docx는 피하기 어렵습니다. 본 글의 “Word”는 docx를 읽고 쓸 수 있는 동등한 도구들 — LibreOffice Writer, Apple Pages, Google Docs, WPS — 까지 포괄합니다. 협업 모델과 docx의 한계는 공유됩니다.
Catalpas Atelier Scribe는 Word를 대체하려 하지 않고, Word의 협업 기능과 정면 대결하려 하지도 않습니다. 이 파이프라인에서 Scribe는 “저자 쪽: 본문과 완성된 책”을 맡고, 편집자 쪽의 Word는 “코멘트, 수정, 절차 진행”을 맡습니다. 두 쪽은 docx로 원고를 주고받습니다. 질문은 “어느 도구냐”가 아니라 “언제 원고를 docx에 넘기고, 언제 다시 가져오는가”입니다.
현실: 협력자는 docx만 받습니다
독립 저자에게는 이것을 받아들이는 편이 싸웁니다. 함께 일하는 편집자가 기술적으로 Markdown을 읽을 수 있다 하더라도, 실제로 검수 단계에 들어가면 그들에게 필요한 것은 읽기 능력이 아니라 Word 주위에 만들어진 변경 사항 추적 + 코멘트의 협업 의례 전체입니다. Markdown에는 그만큼 성숙한 시각적 검수 시스템이 없습니다. CriticMarkup 류의 마커는 작은 동아리 안에서는 통하지만, “인수 편집자가 두 시간 안에 내 책의 모든 수정 사항을 훑게 한다”는 일에는 부족합니다.
그래서 현실적인 워크플로는 보통 이렇게 흘러갑니다. Scribe에서 본문을 쓰고, 챕터를 정리하고, 로컬에서 수정합니다. 검수 패스가 필요해지면 docx를 내보냅니다. 상대방은 Word(또는 LibreOffice, Pages, Google Docs)에서 변경 사항 추적과 코멘트로 작업한 뒤 돌려보냅니다. 저자는 Scribe로 돌아와 그 수정을 본문에 “번역”해 넣습니다. 매 라운드마다 포맷 변환이 따라붙으므로, 질문은 “그 변환을 어떻게 최대한 싸게 만드느냐”가 됩니다.
docx 브리지: 무엇이 건너가고 무엇이 사라지는가
Scribe가 docx를 내보내고(그리고 누군가가 수정한 docx를 다시 Scribe로 들여올 때) 여러 종류 콘텐츠의 운명을 미리 알아 두면 좋습니다.
구조와 챕터 제목은 비교적 충실하게 유지됩니다 — Heading 1 / Heading 2 매핑이 양쪽 모두 안정적입니다. 누군가 Word에서 챕터 순서를 바꾸거나 제목을 변경하면 Scribe가 그것을 돌아올 때 받아들인다는 뜻입니다.
본문 단락과 기본 서식(굵게, 기울임, 인용)도 라운드트립에서 살아남습니다. 단, 단락 간격, 행간, 글자 크기는 Scribe의 프로젝트 수준 조판이 통제하는 속성이며, docx에서 수동으로 손대서는 안 됩니다. 손대고 나면 돌아왔을 때 Scribe의 조판에 의해 덮어쓰이거나 국지적 불일치를 만듭니다. docx를 넘길 때 편집자에게 명시적으로 말하십시오. “텍스트와 구조만 바꿔 주세요 — 조판은 제 쪽에서 일괄 처리합니다.”
변경 사항 추적은 이 파이프라인에서 가장 가치 있는 것입니다 — 어느 단락이 편집되었는지, 무엇이 추가되고 삭제되었는지, 누가, 언제 했는지를 정확히 알려 줍니다. Scribe 쪽에서는 돌아온 docx를 “참조 파일”로 보관하고, 수정을 하나씩 훑어보며 수락/거부를 결정한 뒤 Scribe 안에서 손으로 적용하십시오. 자동 병합을 시도하지 마십시오 — 지금 어떤 도구도 Markdown ↔ docx 라운드트립에서 변경 사항 추적을 무손실로 보존하지 못하며, 앞에서 아낀 몇 분은 뒤에서 문제 해결에 쓰이는 시간을 메우지 못합니다.
코멘트도 비슷합니다 — docx의 코멘트를 Scribe 쪽에서 “할 일 목록”으로 다루고, 하나씩 처리하면서 Scribe 안의 본문을 편집한 뒤, 원본 docx를 보관해 둡니다. 코멘트는 Scribe 프로젝트 안에 본문과 함께 살 필요가 없고, 살아서도 안 됩니다.
사라지는 것: 복잡한 표, 임베디드 객체(수식, 차트, SmartArt), 텍스트 박스, 커스텀 스타일. 대부분의 소설 원고는 이를 쓰지 않습니다. 도표가 많은 논픽션을 쓴다면 편집자와 미리 합의하십시오. “도표는 지금 건드리지 말고 본문만 검수해 주세요” — 매 라운드마다 도표를 다시 끼워 넣지 않게 됩니다.
검수 라운드 간 버전 관리
두세 번의 라운드트립 검수를 할 때 파일명과 보관은 보이는 것보다 더 중요합니다. 한 가지 신뢰할 만한 방식:
- Scribe에서 편집자에게 내보낼 때:
책이름_v0.3_to-editor_20XX-MM-DD.docx - 편집자가 돌려보낼 때:
책이름_v0.3_from-editor_20XX-MM-DD.docx - 처리를 끝낸 뒤 Scribe 프로젝트 버전을
v0.4로 올리고 다음 라운드를 시작
요점은 예쁜 파일명이 아니라, 언제든 “지금 편집자가 가진 버전이 무엇인가” “양쪽 사이에 버전 어긋남이 있는가”에 답할 수 있어야 한다는 것입니다. 본문의 최신 버전은 항상 Scribe 프로젝트에 산다 — 나가는 docx는 스냅숏이고, 들어오는 docx는 피드백을 실은 스냅숏이지만, 어느 쪽도 진리의 원천은 아닙니다.
두 번째 규칙: 편집자의 회신이 도착했을 때 곧장 Scribe로 뛰어들지 마십시오. 돌아온 docx를 먼저 끝까지 읽으면서 모든 수정과 코멘트에 대해 판단(수락 / 거부 / 논의)을 내리고, 그 결정을 한꺼번에 Scribe로 가져오십시오. “docx 읽으면서 동시에 Scribe 편집하기”보다 훨씬 빠르고, 버전 어긋남도 줄어듭니다.
Word 쪽을 떠날 때: 지식이 Markdown으로 되돌아 자리잡습니다
마지막 결정 지점: 언제 docx 브리지를 거치는 일을 멈춰야 할까요?
셀프 출판을 하고 있고 아직 개인 초고 단계라면 첫 라운드 자체가 필요 없습니다 — Scribe 안에서 끝까지 쓰고, 스스로 다시 읽고, 수정하고, EPUB과 인쇄 PDF를 출고하십시오. docx는 “다른 사람에게 원고를 보여주고 그들의 수정을 받아들여야” 할 때만 비용을 치를 가치가 있습니다.
내용 편집과 카피 에디트 두세 라운드를 이미 끝냈다면 최종 잠금 단계는 완전히 Scribe 쪽으로 돌아와야 합니다: 이 시점부터 모든 변경은 Scribe 프로젝트 안에서만 일어나며, “사인을 받으려고 또 한 번 docx 보내기”는 없습니다. 매 라운드트립은 약간의 서식·조판 위험을 끌고 들어오며, 인쇄 직전 단계에서 그것을 계속 감수할 이유는 없습니다.
Word를 완전히 건너뛸 때는 언제일까요? 협력자 본인이 Markdown 협업을 받아들이고(소수의 기술적 성향 편집자나 밀접한 공동 집필 그룹) 변경 사항 추적 의례에 의존하지 않을 때입니다 — 그 시점이면 git diff나 Scribe 내장의 버전 비교로 변경을 소통할 수 있고, docx 라운드트립보다 가볍습니다. 다만 상대방의 실제 습관을 정직하게 평가하십시오. “그들이 Markdown을 쓰면 좋겠다”가 “그들이 실제로 일하는 방식”을 덮어쓰지 않도록 하십시오.
함께 읽어 보면 좋은 글
- Scribe 협업 허브 — 다른 집필·메모·검수 도구와의 워크플로 진입점
- Scribe와 Microsoft Word 비교 — 도구 비교에서 시작하고 싶다면