책등은 정확해야 한다
인쇄용 표지는 화면에서 완벽해 보여도 인쇄기에 들어가는 순간 폐지가 될 수 있습니다. 표지를 망치는 주범은 보통 네 페이지 분량입니다.
경위는 이렇습니다. 인쇄소에서 특정 페이지 수의 책에 맞춰 책등 너비를 견적으로 알려줍니다. 여러분은 그 치수에 맞춰 펼침 표지(앞표지, 책등, 뒤표지가 하나의 평면 파일로 된)를 만듭니다. 그러다 6장의 문단 하나를 수정하면 본문 조판이 다시 흘러 책이 네 페이지 늘어나고, 책등은 이제 너무 좁아집니다. 화면에서는 아무것도 바뀌지 않습니다. 배송된 상자를 열어보고 나서야 책등의 제목이 앞표지 쪽으로 슬금슬금 밀려 나온 것을 발견하게 됩니다.
바로 이러한 실패 때문에 Junifye가 존재합니다. 제가 돈을 내고 쓸 수 있었던 어떤 편집기도 이에 대한 해결책을 제시하지 못했습니다. 편집기는 자신이 물리적인 물건을 만들고 있다는 사실을 알지 못하기 때문입니다.
인쇄기는 책을 알아야 한다
그래서 Junifye에서 인쇄소는 단순한 페이지 크기가 아닙니다. 프리셋에는 재단 규격, 내지 도련, 표지 도련, 최소 및 최대 페이지 수, 페이지 수에 따른 안여백 너비를 대응시킨 래더, 절취선 포함 여부, 표지의 바코드 침범 금지 영역, 그리고 책등 계산 공식(페이지당 밀리미터 값 더하기 상수)이 담겨 있습니다.
책의 인쇄 상태를 확인할 때 모든 값은 어떤 레이어가 그 값을 결정했는지 라벨이 붙어 반환됩니다. 인쇄소 프리셋인지, 사용자가 설정한 재정의인지, 아니면 인쇄소가 단순 견적으로 제시한 너비인지 말이죠. 위험한 것은 세 번째 라벨이며, 그 위에 경고가 표시되는 이유도 여기에 있습니다. 견적으로 제시된 책등은 해당 견적이 나왔던 페이지 수에 고정되어 있으며, Junifye는 책의 분량이 이를 벗어나는 순간 즉시 경고를 띄웁니다.
또한 두 가지 종류의 만료를 구분합니다. 렌더링된 파일은 책이 편집되었기 때문에 만료될 수도 있고, 그 아래의 서비스가 재배포되었기 때문에 만료될 수도 있습니다. 전자만이 인쇄소에 파일을 보내지 말아야 할 이유가 됩니다.
화면 렌더링은 더 조용하게 작동합니다. 어디에도 렌더링 버튼은 없습니다. 모든 변경 사항은 책의 버전을 올리며, 다음번에 PDF를 가져올 때 내용이 달라졌다면 다시 렌더링합니다. 라이트 모드와 다크 모드는 별도의 파일입니다. 한밤중에 스마트폰으로 읽는 책은 종이로 읽는 책과 같은 물건이 아니기 때문입니다.
책은 문서가 아니라 구조다
책이 그저 서식 붙은 텍스트 덩어리라면 이러한 인쇄 매커니즘은 하나도 작동하지 않았을 것입니다. 따라서 책은 그런 덩어리가 아닙니다. 책은 장을 담고, 장은 블록을 담으며, 모든 블록은 자신이 무엇인지 압니다. 문단, 제목, 목록, 표, 그림, 성경 인용구처럼 말입니다.
마지막 항목은 제가 가장 신경 쓰는 부분입니다. 성경 블록을 추가할 때 참조 구절과 번역본 코드를 지정하면, 구절 텍스트는 이 시스템의 다른 한 축인 원어 검색 도구 Darash에서 가져옵니다. 사용자가 직접 다시 입력할 필요가 없으며, 작업을 돕는 어시스턴트도 마찬가지입니다. 모델이 기억해 낸 내용이 아니라 실제로 기록된 내용이 책에 그대로 들어갑니다. 이는 연구서가 알게 모르게 틀어지는 가장 흔한 원인이므로, 나중에 검수하기보다는 설계 단계에서 아예 배제하는 것이 마땅했습니다.
글은 MCP를 통해 AI 어시스턴트와 대화하며 쓰거나, 웹 편집기에서 직접 작성합니다. 편집기 링크는 PIN으로 보호되며 계정이 필요 없으므로, 공동 저자에게 특정 섹션 하나만 넘겨줄 수 있습니다. 누군가 작업 중인 섹션은 잠기며 체크섬으로 저장을 보호하므로, 두 사람이 한 권의 책을 작업하다 서로 덮어쓰는 일이 없습니다.
자신이 판본임을 아는 판본들
라이브러리에는 36개 언어로 된 134개 타이틀이 있습니다. 그중 상당수는 다른 언어로 된 같은 책이며, 기존 출판 도구들이 대체로 두 손을 드는 지점이 바로 여기입니다.
Junifye에서 번역본은 원본에 연결됩니다. 원본 하나에 판본은 얼마든지 붙을 수 있고, 뷰어에는 언어 선택기가 제공됩니다. 그 구조는 의도적으로 평면적입니다. 판본이 번역본의 번역본이 될 수 없으며, 이미 하위 판본들을 거느린 책이 다른 누군가의 하위 판본이 될 수도 없습니다. 연쇄적인 관계는 시스템을 파멸로 이끌 테니까요.
이 연결의 진가는 편집할 때 드러납니다. 각 장은 위치에 따라 여러 판본 간에 쌍을 이루며, Junifye는 장별, 판본별로 마지막으로 동기화되었던 버전을 기억합니다. 노르웨이어 버전의 4장을 수정하면, 영어와 페르시아어 버전이 뒤처졌다는 사실과 어느 지점에서 갈라졌는지, 그리고 변경된 쪽에서 정확히 무엇이 바뀌었는지를 알려줍니다.
시스템은 서로 다른 언어 간의 diff를 시도하지 않습니다. 이는 편법이 아니라 의도된 결정이었습니다. 노르웨이어 산문과 페르시아어 산문을 비교하도록 설정된 기계는 확신에 찬 헛소리를 내놓을 뿐입니다. 대신 제공되는 것은 양쪽의 현재 전체 원문, 실제 변경 사항에 대한 동일 언어 diff이며, 판단은 사람이 내립니다. 번역을 반영하고 나면 완료 표시를 하고, 기준점이 재설정됩니다.
책이 완성되어 공개되면, 우리 자체 번호 대역에서 부여한 실제 ISBN이 배정됩니다. 이는 판권 페이지와 EPUB 메타데이터에 책 한 권당 하나씩 영구적으로 들어갑니다. 인쇄 표지의 바코드는 별개의 번호이며 저자 고유의 번호로 유지됩니다.
Junifye는 현재 베타 상태이며 제가 바라는 것보다 거친 구석들이 있습니다. 하지만 그 아래를 받치는 기반은 제가 어디서도 빌려 쓸 수 없었던 부분입니다.
"여호와께서 내게 대답하여 이르시되 너는 묵시를 기록하여 판에 명백히 새기되 달려가면서도 읽을 수 있게 하라." (하박국 2:2)
판에 명백하게. 화면에서만 명백하고 인쇄기에서는 어긋나는 것이 아니라.
junifye.publifye.pro에서 Junifye 베타 버전을 이용할 수 있습니다. MCP를 통해 AI 어시스턴트와 함께 작성하거나 웹 편집기에서 작업하여, 단 하나의 소스로 EPUB, 열람용 PDF, 인쇄 준비를 마친 표지까지 제작해 보세요.
Publifye AS의 설립자 예른 안드레 할세트(Jørn André Halseth) 작성 — 10년간 성경을 출판하고 출판 인쇄 시스템을 구축해 왔으며, 4,200개 이상의 성경 판본을 출판했고, Darash, Junifye, Lexifye, Tringine의 개발자입니다. 소개 · 문의