# 당신의 ePub은 정상입니다

> Clean Markdown view of GeekNews topic #30501. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30501](https://news.hada.io/topic?id=30501)
- GeekNews Markdown: [https://news.hada.io/topic/30501.md](https://news.hada.io/topic/30501.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-15T14:36:11+09:00
- Updated: 2026-06-15T14:36:11+09:00
- Original source: [andreklein.net](https://andreklein.net/your-epub-is-fine-kobo-disagrees-blame-adobe/)
- Points: 2
- Comments: 1

## Topic Body

- 검증을 통과한 **DRM 없는 EPUB**도 Kobo에서는 “corrupted”로 처리될 수 있으며, 문제는 파일 형식 오류가 아니라 렌더링 엔진 호환성에서 발생함
- **epubcheck**는 EPUB 구조와 규칙 준수 여부를 확인하는 사실상 표준 검증 도구지만, 특정 렌더러의 오래된 CSS 파서 문제까지 잡아내지는 못함
- Kobo는 Adobe의 독점 전자책 렌더링 엔진인 **RMSDK**를 사용하며, 이 엔진은 EPUB2 기반으로 만들어진 뒤 EPUB3용으로 가볍게 갱신됐지만 현대화되지 않았음
- 문제의 원인은 `max-width: min(150px, 30vw);` 한 줄이었고, 이 유효한 **CSS level 4** 코드는 RMSDK에서 지원되지 않아 Adobe Digital Editions와 Kobo에서 책 로딩 실패를 일으킴
- Kobo 호환성을 확인하려면 epubcheck만으로는 부족하며, **Adobe Digital Editions**에서 실제로 열어보는 추가 검증이 필요함

---

### epubcheck를 통과한 EPUB에서 시작된 문제
- Adobe 도구는 Creative Suite가 업계 표준이거나 대안이 부족해 사용되는 경우가 많으며, 이 글의 문제의식은 Adobe 소프트웨어에 대한 불만에서 출발함
- 새 책은 독자에게 직접 제공되는 **DRM 없는 `EPUB` 파일**로 배포됐고, 배포 전 여러 과정을 거쳐 `epubcheck` 검사를 통과함
- `epubcheck`는 잘 구성된 전자책을 확인하는 사실상 표준 도구이며, `manifest`가 책 안의 조각과 이미지를 빠짐없이 반영해야 통과함
- HTML 요소 순서가 맞지 않거나 International Digital Publishing Forum의 규칙에서 조금만 벗어나도 검증에 실패함
- `epubcheck`를 100% 통과시키는 일은 초보자에게 쉽지 않지만, 출판 작업자에게는 타입 린터나 형식적 테스트 스위트에 가까운 역할을 함
- 원래 기대는 `epubcheck`를 통과한 책이 EPUB 호환 리더나 앱 어디서나 작동하는 것임

### Kobo에서만 “corrupted”가 발생함
- 새 책은 **`epubcheck` ruleset 3.3**을 통과했지만, 한 독자에게서 “corrupted”라는 메시지가 발생함
- 하위 호환성 가능성을 확인하기 위해 EPUB2 버전도 제공했지만, 그 파일도 규칙을 완전히 준수했음에도 같은 문제가 발생함
- 해당 독자는 여러 세대의 **Kobo 기기**에서 책이 열리지 않는다고 전함
- 같은 EPUB은 Amazon Kindle, Apple Books, Thorium 등 다른 환경에서는 문제없이 작동함
- 조사 결과 Kobo는 Adobe의 독점 전자책 렌더링 엔진인 **RMSDK**를 사용함

### RMSDK와 Adobe Digital Editions로 좁혀진 원인
- RMSDK는 **Adobe Digital Editions**의 핵심 엔진이며, 여러 Kobo 기기와 구형 Sony·Nook 기기에서도 쓰임
- 이 엔진은 2010년 무렵 EPUB2를 중심으로 만들어졌고, EPUB3용으로 가볍게 갱신됐지만 현대화되지는 않았음
- RMSDK 사용 사실은 `epubcheck`와 Kobo 결과가 엇갈리는 문제를 곧바로 해결하지는 못했지만, 디버깅 방향을 제공함
- Adobe Digital Editions에 책을 넣자 예상대로 로딩에 실패했으며, 오류 메시지도 나타나지 않음
- 다시 불러오려 하면 이미 추가한 책이라 가져올 수 없다는 메시지가 나왔지만, 화면은 흰색으로 남아 있었음
- 이후 여러 변형 파일을 만들며 테스트했고, 모든 변형은 계속 `epubcheck`를 통과함
  - 폴더 구조 재배치, 메타데이터 제거, 언어 속성 제거, 새 UUID 생성, 디렉터리 평탄화, 확장자 변경, ZIP 재생성, `manifest` 변경을 시도함
  - 이 모든 시도에도 Adobe Digital Editions 로딩 실패는 반복됨

### 실제 원인: 유효한 CSS 한 줄
- 스타일시트를 비활성화하자 책이 갑자기 로딩되면서, 문제 범위가 **스타일시트**로 좁혀짐
- 스타일시트 일부만 적용한 여러 변형을 더 만든 끝에 문제를 일으키는 한 줄이 확인됨

```css
.copyright img {
    max-width: min(150px, 30vw);
}
```

- 해당 코드는 완전히 유효한 **CSS level 4** 코드지만, RMSDK는 이를 지원하지 못함
- 코드를 더 오래된 방식인 `max-width: 150px;`로 바꾸자 Adobe Digital Editions에서 책이 정상적으로 열림
- RMSDK의 CSS 파서는 대략 2013년 상태에 머물러 있으며, flexbox, grid, 수학 함수, 사용자 지정 속성을 지원하지 않음
- 인식하지 못하는 CSS를 만나면 폴백이나 명확한 오류 대신 조용히 충돌함
- `epubcheck`는 기본적인 CSS 검사를 수행하지만, 근본적으로 망가진 특정 렌더러에 맞춰 CSS를 검증할 수는 없음

### Kobo 호환성 검증의 교훈
- 2026년에도 Kobo가 책 렌더링의 기반으로 RMSDK를 사용하면서, 유효한 CSS 한 줄이 유효한 EPUB 전체를 “corrupted file”로 만들 수 있음
- 이 경우 Kobo는 명확한 오류 메시지나 폴백 없이 책 전체를 열지 못함
- 문제를 피하기 위해 새 버전이 배포됐고, 독자들이 같은 오류를 다시 겪지 않도록 조치됨
- 이상적인 환경이라면 RMSDK가 CSS 구식 상태에서 벗어나거나 최소한 오류 처리를 제공해야 하지만, 현재 문제는 그대로 남아 있음
- Kobo 호환성을 확실히 하려면 **`epubcheck`만으로는 부족**하며, Adobe Digital Editions에서 실제 로딩 여부를 확인해야 함
- EPUB은 전자책을 위한 훌륭한 개방형 표준이지만, 많은 구현은 접근 제한을 우선하는 구조 속에서 근본적인 결함을 드러냄

## Comments



### Comment 59673

- Author: neo
- Created: 2026-06-15T14:36:12+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48533848) 
- **Adobe**도 늘 이런 식이었음. Flash의 막대한 시장점유율을 날려먹었는데, 대안은 QA에 몇백만 달러만 쓰면 되는 일이었고 결국 모든 브라우저 제조사가 “웹은 이렇게 못 믿을 파트너 없이 가는 편이 낫다”는 데 합의하게 만들었음  
  예전에 Flash로 몇 가지를 출시했지만, 임의 충돌과 한 영역의 변경이 다른 모듈의 무관한 기능을 깨는 **하이젠버그**가 넘치는 끔찍한 소프트웨어였음. 가격은 800달러쯤 했는데 지원은 사실상 없었고, 축소 테스트 케이스까지 붙여 쉽게 재현되는 버그를 여러 개 냈지만 다음 릴리스가 나온 뒤 “고쳐졌을 수도 있으니 정가 라이선스를 사서 확인해보라”는 자동 안내만 받았음
  - Steve Jobs를 좋아하든 싫어하든, iPhone에서 Flash를 지원하지 않고 **HTML5**를 밀어붙인 결정이 Flash의 몰락을 크게 앞당겼음
  - Flash는 **VideoWorks**라고 불리던 시절이 더 나았음 ;)  
    **MusicWorks**도 있었고 둘 다 아주 초기의 Mac 전용이었음. 이 얘기만 해도 나이가 드러남
  - Flash는 아직도 가장 쉬운 **퍼블리싱 매체**로는 따라올 게 없음  
    JavaScript 빌드 시스템의 겹겹이 쌓인 구조와 “웹 표준”은, 그냥 뭔가를 그리고 간단한 함수를 조금 쓴 뒤 어디에나 임베드하거나 다운로드할 수 있는 정적 파일을 만드는 것보다 훨씬 어렵다. Flash 대안을 쓰려면 설정에 시간을 너무 많이 쓰게 되고, 그 “표준”들도 더 나쁨  
    Flash를 죽인 Steve Jobs도 싫고, 웹의 가장 놀라운 기술 중 하나를 형편없이 관리한 Adobe도 싫음. 요즘 자라는 아이들은 Flash가 얼마나 마법 같았는지 모른다. 웹용 Roblox나 Minecraft 같은 존재였음  
    웹사이트는 아직도 2000년대 초 Flash보다 못함. 수십 년이 지났는데도 그 힘의 일부만 흉내 낼 뿐이고, 쉬움은 전혀 따라오지 못함

- 전자책 리더 소프트웨어를 꽤 오래 만들려다가, 결국 악마와 거래하는 셈 치고 **RMSDK** 위에 올려보려 했음  
  그런데 접근할 방법이 전혀 없음. 독립 개발자에게 라이선스 비용이 너무 비싸다는 뜻이 아니라, 물론 그것도 맞겠지만, 아예 이야기할 상대가 없다. 웹사이트에 적힌 이메일은 아무 답도 하지 않고 “관심 가져줘서 고맙다”거나 “다시 연락하겠다”는 말조차 없음  
  예전에 그곳에서 일했던 동료에게 RMSDK 접근 절차를 물었더니 내부 문서를 찾아봤지만 아무것도 못 찾았다고 했음. LinkedIn에서 RMSDK와 관련 있어 보이는 사람을 찾아 물어봐도 마찬가지였음  
  한편 출판사들은 대부분의 책을 Apple, Amazon, Adobe 같은 알려진 **DRM 벤더** 중 하나를 통해서만 배포하고, 앞의 두 곳은 완전히 닫혀 있음. 이게 반경쟁적 독점 행위가 아니라면 뭔지 모르겠음
  - **FBReader** 앱으로 책을 많이 읽었는데, 다른 앱에서 쓸 수 있도록 SDK를 공개하고 있음

- 내가 알기로 Kobo 기기는 파일명을 `.kepub.epub`로 지정하면 더 발전된 **렌더링 엔진**을 씀. ePub 3 기반인 것 같고, 여기 문제를 고칠지는 모르겠음  
  개인적으로는 Kobo로 옮기기 전에 ePub을 kepubify([https://pgaskin.net/kepubify/try/](<https://pgaskin.net/kepubify/try/>))로 변환함
  - 맞음, 나도 모든 파일에 그렇게 함. Standard Ebooks 같은 출판사도 **kepub 다운로드**를 제공하고, 여기서 설명하듯 Adobe 리더에도 문제가 있음  
    [https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...](<https://standardebooks.org/help/how-to-use-our-ebooks#kobo-faq>)  
    Kobo Clara Colour를 정말 좋아하고, Adobe 리더만 제거하면 완벽할 것 같음. KOReader도 써봤지만 OverDrive 도서관 책과 Kobo Store를 좋아해서 완전히 갈아타지는 않았음

- 아쉽게도 **epub**와 epubcheck는 글쓴이가 말한 것처럼 논란 없는 훌륭한 기준이 아님. W3C, Inc.가 ePub 3.1 무렵 명세 관리를 맡으면서 WHATWG HTML과 계속 커지는 브라우저 명세들을 그대로 참조했음([1])  
  이런 “살아 있는 표준”에는 버전 관리나 QA가 없다. 그 결과 헤더와 섹셔닝을 재정의한 HTML 버전을 기반으로 하면서, ePub 3.2는 기존 ePub들을 비준수로 만들어버렸음. 그래서 Calibre와 다른 도구들이 여전히 3.1, 더 낫게는 2를 권하는 것임  
  CSS `min()` 함수가 거부되는 사례도, 지나치게 복잡한 CSS 명세를 통째로 가져오는 게 별 도움이 안 되는 지점임. 전자책 리더는 항상 최신 상태로 갱신되는 브라우저가 아니기 때문임  
  [1]: [https://news.ycombinator.com/item?id=41326179](<https://news.ycombinator.com/item?id=41326179>)
  - ePub 쪽에서는 **3.1이나 2를 목표**로 삼는 편이 더 제정신인 선택이라는 게 널리 알려져 있음  
    EPUB 호환성 문제에서는 CSS를 항상 1순위로 의심해야 함. “현대적” CSS 기능을 쓰고 플렉스박스나 그리드가 없다고 불평하는 건 웹 개발자의 사고방식임  
    EPUB이 웹과 스택 일부를 공유한다고 해서 둘이 완전히 겹친다는 뜻은 아니고, 그래야 하는 것도 아님. 전자잉크 내장 리더 기기 대부분은 렌더링에 브라우저를 쓰지 않고, 목적별 HTML/CSS 파싱·렌더링 도구체인을 펌웨어에 구워 넣은 뒤 아주 가끔만 업데이트함. 관심 있으면 KOReader의 crengine이나 ESP32에서 돌아가는 Crosspoint reader를 보면 됨  
    해당 블로그 글은 지나치게 자신만만한 **AI 문체** 냄새가 나지만, 속으면 안 됨

- 기기를 찾는 사람이라면 **PineNote**도 있음  
  [https://pine64.org/devices/pinenote/](<https://pine64.org/devices/pinenote/>)  
  더 비싸고 바로 쓸 수 있는 소프트웨어는 적지만, 기기 소유권과 어떤 소프트웨어를 실행할 수 있는지에 대해서는 훨씬 직설적이고 걸리는 조건이 적음  
  PineNote 사용기를 잘 정리한 글들도 있음  
  [https://shom.dev/posts/20250308_pinenote-day-one/](<https://shom.dev/posts/20250308_pinenote-day-one/>)  
  [https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...](<https://shom.dev/posts/20250406_a-pinenote-only-5-day-weekend/>)
  - PineNote를 직접 써봤는지 궁금함. 가격이 **400달러**이고, “임베디드 시스템 지식이 풍부한 Linux 개발자나 모바일 Linux 경험자 대상”이라고 되어 있음. 링크된 커뮤니티 제공 펌웨어도 1년 넘게 업데이트되지 않았음  
    Kobo도 할 수 있는 일을 제한하지는 않음. KOReader 같은 대체 전자책 리더 소프트웨어를 사이드로드해서 내장 리더 기능을 개선할 수 있음
  - 이 사람의 **오픈소스 60Hz 전자잉크 화면**도 살펴볼 만함: [video] [https://www.youtube.com/watch?v=nHbA2-_qzH4](<https://www.youtube.com/watch?v=nHbA2-_qzH4>)

- Kobo는 실제로 전자책 리더 소프트웨어를 완전히 다시 쓰는 중이고, EU에서는 베타를 내려받을 수 있음. 거의 확실히 더 이상 **RMSDK 기반**이 아님  
  Adobe는 관리자로서 부실했고, 이후 마이그레이션을 망쳐 최종 사용자와 플랫폼을 더 화나게 한 제3자에게 팔아넘기면서 EPUB DRM 시장을 **LCP**에 은쟁반째 넘겨준 셈임. 플랫폼들이 어느 때보다 빠르게 Adobe에서 벗어나고 있음
  - 베타를 써봤는지 궁금함. 실제로 꽤 나아졌는지 알고 싶음

- “몇 달 작업을 끝내고 완성한 책에서 검증 버튼을 누르는 순간이 두려웠다. 항상 뭔가 트집 잡을 걸 찾아냈기 때문이다”라는 대목을 보니, **LaTeX 논문 초안**을 컴파일하려다 울먹이던 석사생이 떠오름  
  “일단 쓰고 서식은 나중에 생각하라”는 말을 너무 문자 그대로 받아들여서, 마감 직전에야 처음으로 컴파일을 시도하고 있었음
  - 그래도 전체적으로는 시간이 꽤 절약됐을 가능성이 있음. 컴파일 시간만 봐도 더 일찍 반복 확인했다면 훨씬 많은 시간을 낭비했을 수 있음  
    다가오는 마감이 그 체감에 어떤 영향을 줬는지는 알 수 없지만 ;-P

- 독자가 애초에 `max-width` 같은 걸 지원하거나 적어도 무시하는 **ePub 리더**를 쓴다면 다행이라고 봐야 함 :-P  
  개인적으로는 ePub 리더를 쓰면서, 불필요한 스타일 때문에 작동하지 않거나 이상하게 표시되는 파일을 가끔 직접 고쳐야 했음. 내 쪽에서는 문제가 없던 파일이 다른 사람에게는 읽을 수 없었다는 얘기도 들었고, 정말 필요한 화려한 서식이 아니라면 IE4도 크게 틀리게 렌더링하지 않을 정도의 가장 기본적인 HTML에 머무르는 게 낫다는 생각이 듦  
  그래서 언젠가 ePub을 가장 단순한 HTML/CSS로 재구성해주는 **epub reconstruct** 도구를 만들까 생각할 때가 있음. 이상적으로는 최대 호환성을 위해 설정 가능해야 함
  - 목표 웹 브라우저 환경에서도 **HTML/CSS**가 겨우 동작하는 판인데, 왜 누가 이걸 책에 쓰는 게 좋은 생각이라고 봤는지 모르겠음  
    어떤 컴퓨터에서도 빠르게 동작하는 하위 집합을 정해서 내가 만드는 웹페이지에는 그것만 쓰면 어떨까 자주 생각했음. ePub에서도 누군가 그런 범위를 정리한다면 훨씬 더 유용해질 것임
  - 그림을 그릴 때도 어떤 사람의 안경에 금이 가 있어서 그림이 이상하게 보일 수 있으니 가운데를 칠하지 않는 식인가 봄. 아니면 안경 제조사에게 더 나은 안경을 만들라고 하고, 예술가가 자기 예술을 하게 둬야 할지도 모름

- **Adobe Digital Editions**와 RMSDK는 최근 Wipro Engineering에 매각됐음: [https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...](<https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-editions.html>)
  - 매각인지, 아니면 **아웃소싱**인지가 궁금함

- 글쓴이의 답답함은 이해하지만, 오래되고 업그레이드되지 않았거나 업그레이드할 수 없는 ePub 리더를 쓰는 독자가 얼마나 될까? 저자가 모든 독자에게 작품을 제공하고 싶다면 **최소 공통분모**에 맞춰야 함  
  그게 2013년 무언가라면 유감이지만 그게 시장의 현실임
  - 2026년에 나오는 새 Kobo가 CSS 규칙이 **2013년에 멈춘 Adobe DRM 소프트웨어**를 쓴다는 뜻으로 읽었음