AI로 전자책 자동 변환 파이프라인 만들기1인 출판 EPUB 제작 자동화 삽질기

자동화를 시작하기 전에, 자동화가 실수를 저질렀을 때 알아챌 방법부터 만든다. 이게 이번 작업 전체에서 가장 중요한 원칙이었어요.

---

이론은 깔끔한데, 실제로 돌려보니 예상 못 한 곳에서 계속 걸렸습니다. 몇 가지만 옮겨볼게요.

5-1. 문서에 적어둔 목차 구조가 실제 원고와 달랐다

작업 지시서에 "3부는 4개 장, 4부는 5개 장"이라고 손으로 적어뒀는데, 실제 원고를 기계로 읽어보니 "3부는 5개 장, 4부는 5개 장"이었습니다. 단순한 오타 같지만, 이 숫자가 틀리면 나중에 "2부를 산 사람에게 3부 내용이 보이는" 사고로 이어질 수 있는 숫자였어요.

교훈은 이거였습니다. 여러 곳에서 같이 쓰는 숫자는, 사람이 문서에 손으로 옮겨 적지 말고 원본 파일에서 기계가 직접 세어서 확정하게 만들어야 한다. 사람의 기억과 손은 틀리기 쉽지만, 파일을 세는 코드는 안 틀립니다.

5-2. 변환 프로그램이 챕터를 하나로 뭉쳐버렸다

EPUB 변환 프로그램(Pandoc)은 "제목처럼 생긴 줄"을 기준으로 챕터를 나눕니다. 그런데 웹사이트에서 읽을 원고 파일에는 제목이 따로 들어있지 않은 구조였어요(제목은 별도 목차 파일에 있었거든요). 그래서 프로그램 입장에서는 "제목이 하나도 없네? 그럼 전부 한 덩어리네"라고 판단해버린 겁니다. 23개 파일을 넣었는데 결과물은 1개 챕터로 나왔어요.

해결책은 원본을 고치는 게 아니라, 변환할 때만 임시로 제목을 붙여주는 중간 단계를 하나 끼워 넣는 것이었습니다. 원본은 그대로 두고, 변환 직전에만 "이 부분은 제목이야"라고 표시해주는 거예요.

5-3. "빈 값이어도 괜찮아야 한다"는 요구와 실제 규격이 충돌했다

책에 ISBN(국제표준도서번호)이 아직 없는 상태였습니다. "ISBN 없이도 일단 만들어질 수 있게 하자"고 정해뒀는데, 막상 만들어보니 EPUB 표준 검사기가 오류를 냈습니다. EPUB 규격상 이 항목은 아예 비워두는 게 허용되지 않았던 거예요.

그래서 ISBN이 없으면 임시로 고유한 대체 번호를 자동 생성해 채워 넣고, 나중에 진짜 ISBN이 나오면 그걸로 교체하는 식으로 바꿨습니다. "비워둬도 된다"는 바람과 "표준은 그걸 허용하지 않는다"는 현실이 부딪힐 때는, 현실 쪽 규칙을 찾아서 맞추는 수밖에 없더라고요.

5-4. 사소한 환경 문제가 제일 오래 잡아먹었다

정작 가장 시간을 많이 쓴 건 이런 "핵심 로직" 문제가 아니라, 개발 도구를 설치하는 과정에서 생긴 자잘한 충돌들이었습니다. 특정 프로그램이 요구하는 설치 조건이 컴퓨터 환경과 안 맞아서 우회 방법을 찾아야 했던 것, 오래된 버전의 기본 도구가 특정 상황에서 오작동하는 것 같은. 겉보기엔 별거 아닌데 몇 시간씩 잡아먹는 종류의 문제들이었어요.

---

여기까지 EPUB이 자동으로 뚝딱 나오는 파이프라인이 완성됐습니다. 그런데 실제로 원고를 열어보니 진짜 필요한 건 따로 있었어요. 오타를 고치는 것뿐 아니라 이미지를 특정 위치에 넣고, 사진 아래 설명 글(캡션)을 붙이고, 특정 문단을 강조 박스로 감싸는 것 같은 세밀한 편집이 필요했습니다.

여기서 또 한 번 "그럼 이것도 도구를 만들어서 해결할 수 있지 않을까?" 하는 생각이 들었습니다. 이번에는 방향을 조금 다르게 접근했어요.

먼저 시도한 건 "Calibre 자체를 AI와 연동해서, 말로 편집을 시킬 수 있지 않을까"였습니다. "이 문단 위에 이미지 넣고, 아래 캡션 달아줘" 같은 자연어 명령으로 실제 편집 프로그램을 조작하는 그림이었죠. 되면 제일 이상적인 방법이었을 겁니다.

그런데 알아보니, 지금 수준의 AI 연동 기술로는 이게 불가능하다는 결론에 도달했습니다. 기존 편집 프로그램을 자연어로 원격 조종하는 건, 아직 그 정도로 성숙한 방법이 없었어요.

그럼 "그 기능을 내가 직접 만들면 되지 않을까"로 넘어갔습니다. 그런데 여기서 문제를 다시 들여다보니, 애초에 제가 하려던 게 오탈자 몇 개 고치는 수준이 아니라, 이미지 배치·캡션·박스 스타일까지 다루는 제대로 된 편집기였다는 걸 깨달았습니다. 그 말은 곧, 제가 만들려는 게 사실상 Calibre가 이미 하고 있는 일을 처음부터 다시 만드는 것이었다는 뜻이에요.

책 한 권을 위해 전자책 편집 프로그램 하나를 통째로 새로 만드는 건, 아무리 봐도 배보다 배꼽이 더 큰 일이었습니다.

그래서 결론을 뒤집었습니다. 도구를 새로 만드는 대신, 이미 잘 만들어져 있는 Calibre를 제대로 배워서 쓰기로 했습니다. 처음엔 낯설어서 피하고 싶었던 그 프로그램을, 결국 시간을 들여 배우는 쪽이 가장 빠른 길이었던 거예요.

돌아보면 이 판단까지 세 단계를 거쳤습니다.

1. "Calibre가 낯서니 내가 아는 방식으로 직접 만들자" → 자동화 파이프라인은 실제로 유용했음
2. "그럼 AI로 Calibre 자체를 조종하면 어떨까" → 지금 기술 수준에서는 불가능
3. "그럼 내가 편집기를 직접 만들자" → 알고 보니 그건 기존 도구를 처음부터 다시 만드는 것과 같았음 → 결국 기존 도구를 배우는 게 정답이었다

---

돌아보면 이 과정 전체가 **"어디까지 직접 만들고, 어디서부터 남에게(또는 기존 도구에게) 맡길 것인가"**를 계속 판단하는 일이었습니다.

• 결제 시스템: 직접 만들지 않고 유통사에 맡겼습니다. 고정비를 지는 것보다 수수료를 내는 게 초기에는 훨씬 합리적이었어요.
• 전자책 변환: 직접 만들었습니다. 반복될 작업이었고, 한번 만들어두면 다음 책부터는 거저 나오니까요.
• 세밀한 편집: 직접 만들려다가, 결국 기존 프로그램을 배우는 쪽으로 돌아갔습니다. 필요한 기능의 범위를 제대로 들여다보니, 그건 도구를 만드는 게 아니라 도구를 하나 더 발명하는 일이었습니다.

세 판단의 기준은 결국 같은 질문이었습니다. "이걸 몇 번이나 다시 쓸 것인가"와 "직접 만드는 것이, 이미 있는 것을 배우는 것보다 정말 더 쉬운가."

첫인상만으로는 이 답을 알 수 없더라고요. 결제는 "만들면 되지" 싶다가 비용을 보고 접었고, 편집 도구는 "이건 만들 수 있겠는데" 싶다가 범위를 들여다보고 나서야 접었습니다. 직접 만들지, 남에게 맡길지는 시작할 때가 아니라, 실제로 뭐가 필요한지 구체적으로 파악한 다음에 판단해야 한다는 게 이번에 제일 크게 배운 것 같습니다.

그리고 AI를 실무에 끼워 넣을 때 얻은 교훈은 이거였어요.

AI에게 "구조를 만드는 일"은 믿고 맡기되, "판단이 필요한 일"은 반드시 사람이 확인하는 장치를 먼저 만들어둘 것. 그리고 AI가 모든 걸 대신할 수 있다고 가정하지 말고, 안 되는 지점은 빠르게 인정하고 다른 길을 찾을 것.

책 한 권을 세상에 내놓는 일이 이렇게 많은 갈림길을 지나야 하는 줄은 몰랐습니다. 그런데 그 갈림길마다 "이게 정말 필요한가"를 한 번씩 되물은 덕분에, 필요 이상으로 무겁게 만들지 않고 여기까지 올 수 있었던 것 같습니다.