원고 하나로 인쇄용 PDF부터 점자까지
GLIO Works
요약
“AI는 결정만, 그리는 것은 코드.” 원고의 글자는 한 자도 바꾸지 않고, 포맷마다 새로 해석하던 제작을 하나의 원본에서 끝냅니다.
- 1.76배
- 5 → 7
- 96커밋
개요
책 한 권을 만들면 인쇄용 조판, EPUB, 큰글자, 점자가 각각 따로 원고를 다시 해석합니다. 교정도 여러 번 반복됩니다. 한국어 조판에는 일본어의 JIS X 4051 같은 업계 표준 구현도 없습니다. 유럽 접근성법(2025년 6월)과 한국의 디지털포용법(2026년 1월)이 시행되면서, 접근 가능한 형식은 선택이 아니라 의무가 되고 있습니다.
핵심 결정
AI는 결정만, 조판은 결정론적 코드가
책에서는 한 글자만 바뀌어도 쓸 수 없습니다.
생성 모델은 판단만 JSON으로 내고, 글자를 그리는 것은 엔진입니다. 엔진이 LLM 모듈을 불러오지 못하게 테스트로 막았습니다.
조판 엔진은 직접 만들고, IDML로 내보낸다
상용 조판 서버는 라이선스 비용이 크고, 한국어 조판 기술이 남의 플랫폼 위에 올라갑니다.
HarfBuzz와 자체 줄바꿈(Knuth–Plass), 데이터로 정리한 한국어 줄바꿈 규칙으로 엔진을 만들고, 디자이너가 InDesign에서 이어 작업할 수 있게 IDML을 내보냅니다.
사용자는 좌표가 아니라 역할을 고른다
단락마다 스타일을 덮어쓸 수 있으면 ‘40개 제목 중 하나만 다르게 보이는’ 사고가 생깁니다.
블록의 역할만 고르게 하고, mm와 좌표는 엔진이 정합니다.
첫 제품은 조판이 아니라 접근성 교정
통과와 실패가 객관적이고, 기준이 문서로 정해져 있으며, 이미 동작하는 프로토타입이 있었습니다.
접근성 검사 · 자동 수정 · 대체 텍스트 승인을 먼저 내고, 조판은 다음 단계로 둡니다.
모르면 본문으로 – 덜 해로운 쪽으로 틀린다
원고를 잘못 구조화하면 모든 포맷이 함께 틀립니다.
저자의 Word 스타일을 먼저 읽고, 그다음 레이아웃 추정, 마지막에만 선택적으로 LLM을 씁니다. 확신이 없으면 본문으로 둡니다.
유료 API 0원, 폰트는 기기 밖으로 나가지 않는다
상용 한글 폰트는 서버에서 쓸 수 있게 라이선스되지 않습니다.
규칙 엔진 → 로컬 모델 → 사용자의 구독형 AI(MCP) 3단으로 AI를 쓰고, macOS 앱은 원고와 폰트를 기기 안에서 처리합니다.
실제 책으로 검증하기 – 국립현대미술관 출판 지침
디자이너가 만든 실제 책을 기준으로 삼았습니다. 국립현대미술관(MMCA)의 『출판 지침』 2판(2020)은 같은 원고(docx)와 인쇄된 결과물이 모두 있어, 같은 원고를 GLIO에 넣고 나온 결과를 실제 책과 나란히 비교할 수 있습니다. 8월 15–16일 이틀 동안 이 책 하나로 결과 파일 114개를 내며 엔진을 고쳤습니다.
책을 펴는 중…
GLIO가 짠 지면
- 125×220mm 일치
- 300 / 263쪽
- 114개
- 판형은 맞췄다 – 첫 결과는 161×256mm였고, 반복하며 실제 책의 125×220mm로 맞췄습니다.
- 쪽수는 다르다 – 실제 책은 300쪽, GLIO는 263쪽입니다. 같은 원고가 더 촘촘히 짜였다는 뜻이라, 행간과 여백을 실제 책의 밀도에 맞추는 것이 다음 과제입니다.
- 서체는 다르다 – 실제 책은 Janson · AG 최정호 · Akzidenz 같은 상용 서체를, GLIO는 서버에서 쓸 수 있는 OFL 서체(EB Garamond · Noto Serif KR)를 씁니다.
다른 원고로도
성격이 다른 원고에서도 같은 엔진이 돕니다. 아래는 전시 도록 『한성부입니다』 원고를 넣어 GLIO가 짠 지면입니다. 한국어·영어·일본어가 한 지면에 놓입니다.
다른 테스트셋 4종
같은 방식으로 원고와 실제 결과물이 함께 있는 책들을 돌렸습니다.
- MMCA 출판 지침 1판 (2018) – 실제 300쪽 / GLIO 265쪽, 결과 파일 144개.
- MMCA 소장품 기술지침 (2023) – 실제 88쪽 / GLIO 61쪽, 결과 파일 111개.
- 서울시립미술관 소장품 기술지침 – 실제 52쪽 / GLIO 60쪽, 결과 파일 55개.
- 한성부입니다 (전시 도록) – 실제 176쪽 / GLIO 288쪽, 결과 파일 59개. 도판 중심의 도록은 아직 차이가 큽니다.
구조
- 엔진 – Python · FastAPI. HarfBuzz 셰이핑, 자체 줄바꿈, 한국어 조판 규칙 데이터.
- 스튜디오 – 의존성 없는 단일 파일 웹 UI.
- macOS 앱 – SwiftUI. 엔진을 HTTP 대신 로컬 프로세스로 불러, 원고와 폰트가 기기를 떠나지 않습니다.
- MCP 서버 – 작업물 분석, 사양 생성, 사전 검사, 교정지 렌더, 견적, 주문 요청 등의 도구를 AI 클라이언트에 엽니다. 결제는 실행하지 않고 승인 링크만 돌려줍니다.
결과
- 1.76배
- 659 → 508MB
- 57개 중 0
사람이 개입하는 지점
- 자동 – 원고 하나에서 인쇄 PDF, EPUB3, 큰글자, 접근성 PDF, 점자까지 한 번에 만듭니다. 조판 결과는 사람 눈이 아니라 규칙이 먼저 검사합니다.
- 사람 – 규칙이 잡지 못하는 자리(그림 설명, 표의 읽는 순서, 이름의 표기)는 편집자가 고칩니다. 도구는 초안을 끝까지 밀고, 판단은 남겨 둡니다.
회고
- 라이선스도 설계다. AGPL · GPL 라이브러리는 쓰지 않고, 폰트는 OFL만 씁니다. 좋은 도구여도 배포할 수 없으면 쓸 수 없습니다.
- 남은 일 – 쪽수와 밀도를 실제 책에 맞추는 것, 도판 중심의 도록을 다루는 것, 그리고 실제 고객의 책으로 검증하는 것.