내 ePub은 멀쩡한데 Kobo에서만 깨진다고요? 진짜 범인은 어도비입니다

분명 표준대로 만들었는데, 왜 Kobo에서만 깨질까

전자책을 직접 만들어 본 분이라면 한 번쯤 겪는 황당한 경험이 있어요. ePub 파일을 정성껏 만들어서 EPUBCheck(전자책이 표준을 제대로 지켰는지 검사해 주는 공식 도구)도 무사히 통과했고, 아이폰의 Apple Books나 PC의 Calibre로 열어보면 글자도 이미지도 완벽하게 나와요. 그런데 이걸 Kobo 전자책 단말기에 넣는 순간, 갑자기 글자가 깨지거나 지정한 폰트가 무시되거나, 심하면 파일 자체를 못 여는 일이 벌어집니다. ‘내 파일은 멀쩡한데 왜 너만?’ 싶죠. 결론부터 말씀드리면, 범인은 당신의 파일도 Kobo도 아니에요. 진짜 범인은 어도비(Adobe)거든요.

ePub이 뭐냐면, 사실은 ‘웹페이지를 압축한 것’

먼저 ePub이 뭔지부터 짚고 갈게요. ePub은 무슨 특별한 마법 파일이 아니라, 여러 개의 HTML 파일과 CSS(화면 디자인을 정하는 스타일 언어), 그리고 이미지를 한 폴더에 모아서 zip으로 압축한 것에 불과해요. 확장자만 .epub일 뿐, 속을 까보면 우리가 웹사이트 만들 때 쓰는 그 HTML/CSS 그대로거든요. 그래서 ‘ePub을 만든다’는 건 사실상 ‘아주 작은 웹사이트를 만든다’와 거의 같아요. 웹 개발 좀 해보신 분이라면 금방 적응하시는 이유죠.

문제는 이 HTML/CSS를 실제 화면에 그려주는 ‘렌더링 엔진’이에요. 웹브라우저로 치면 크롬의 Blink, 사파리의 WebKit 같은 그 부품 말이에요. 전자책 단말기들도 저마다 이 엔진을 품고 있는데, 바로 여기서 비극이 시작됩니다.

진짜 범인: 어도비 RMSDK라는 낡은 엔진

Kobo를 비롯해 예전 Nook, Sony Reader 같은 수많은 전자책 단말기들이 엔진을 직접 만드는 대신, 어도비가 만든 RMSDK(Reader Mobile SDK)라는 걸 라이선스해서 썼어요. 쉽게 말하면 ‘전자책을 그려주는 부품’을 어도비한테서 사다가 끼워 넣은 거예요. 그런데 이 RMSDK가 굉장히 오래됐고, 표준을 어설프게만 지키며, 어도비가 적극적으로 업데이트도 안 해주는 물건이라는 게 문제예요. 그러니 표준 검사기는 통과해도, 이 낡은 엔진이 못 알아먹는 최신 CSS나 구조가 수두룩한 거죠.

예를 들면 이런 식이에요. 표준대로 폰트를 넣었는데 이 엔진이 폰트 임베딩을 무시해버리거나, 이미지 크기 지정을 제멋대로 해석하거나, 페이지 나누기(page-break) 규칙을 안 따라줘서 레이아웃이 밀려버려요. 분명 ‘표준상 맞는’ 코드인데, 현실의 단말기에서는 안 먹히는 거죠. 그래서 전자책을 만드는 사람은 ‘표준에 맞게’가 아니라 ‘이 낡은 엔진이 알아먹게’ 코드를 한 번 더 손봐야 합니다.

이거, 웹 개발자라면 데자뷔일걸요

웹 개발 오래 하신 분들은 이 상황이 묘하게 익숙할 거예요. 네, 그 악명 높던 인터넷 익스플로러 6 시절과 판박이거든요. 표준대로 깔끔하게 짜도 점유율 높은 구닥다리 브라우저가 못 알아먹으니, 결국 그 브라우저에 맞춰 별도 핵(hack)을 덕지덕지 붙여야 했잖아요. 전자책 세계에서는 RMSDK가 딱 그 IE6 포지션이에요. ‘표준 준수’가 목표가 아니라 ‘가장 후진 엔진도 견디는 최저 공통분모(lowest common denominator)’에 맞추는 게 현실적인 목표가 되어버린 거죠.

경쟁 구도를 보면 더 선명해요. Apple Books는 WebKit 기반이라 비교적 현대적인 CSS를 잘 소화하고, Calibre 같은 도구는 관대하게 잘 보여줘요. 반면 RMSDK 계열은 ‘되면 다행’ 수준이라, 결국 가장 까다로운 쪽에 맞춰 만들 수밖에 없는 거예요.

한국 개발자에게 주는 시사점

전자책을 직접 출판해 보려는 분, 특히 기술 서적이나 PDF 대신 ePub로 자가출판을 고민하는 분이라면 꼭 기억해 두세요. EPUBCheck 통과는 ‘출발점’이지 ‘완성’이 아니에요. 실제 단말기, 그중에서도 RMSDK 계열에서 직접 열어보고 검증하는 과정이 반드시 필요합니다.

더 넓게 보면 이건 ‘표준과 구현의 간극’이라는, 우리 일에서 늘 반복되는 교훈이에요. 명세서에 적혀 있다고 현실에서 다 동작하는 게 아니거든요. 브라우저든 단말기든 결제 모듈이든, ‘스펙상 맞음’과 ‘실제로 됨’은 다른 문제라는 걸 다시 한번 일깨워 주죠.

한 줄 정리: ePub은 작은 웹사이트고, Kobo의 호환성 문제는 어도비의 낡은 RMSDK 엔진 때문이며, 결국 ‘최저 공통분모에 맞추는’ 옛 웹 개발의 교훈이 그대로 반복되고 있다는 이야기예요.

혹시 여러분은 ‘표준은 맞는데 현실에선 안 되는’ 호환성 지옥, 어디서 가장 크게 데어 보셨나요?