솔직히 고백하겠습니다. 저는 앱이나 웹 디자인만 하면 되는 줄 알았습니다.
그런데 어느 날 기획자가 수줍게 다가와 이렇게 말하더군요.
"다은 님, 이번에 우리 서비스 매뉴얼을 ePub(전자책)으로도 배포해야 하는데요... 디자인 가이드 좀 잡아주실 수 있죠?"
"아, 네! HTML 기반이라니까 웹이랑 똑같이 하면 되겠죠?"
경기도 오산이었습니다.
웹에서 당연하게 쓰던 화려한 CSS, 최신 태그? 여기선 전부 '독약'입니다.
오늘은 제가 며칠 밤을 새우며 깨달은, 개발팀에게 "이거 왜 안 돼요?" 소리 안 듣는 ePub 디자인/개발 핸드오프의 비밀을 풉니다.
1. HTML? 아니요, '엄격한' XHTML입니다.
브라우저는 착합니다. <div> 태그 좀 안 닫아도 찰떡같이 알아서 보여주죠.
하지만 ePub 리더기는 자비가 없습니다.
태그 하나만 안 닫혀 있어도 화면 전체를 백지로 날려버립니다.
ePub은 2025년인 지금도 XHTML을 씁니다. 네, 그 옛날 옛적의 XHTML 맞습니다.
[망한 가이드]
개발자님, 그냥 평소처럼 코딩해주세요~ (Self-closing 태그 신경 안 씀)
[생존 가이드]
반드시 XML 문법을 지켜야 합니다.
- 모든 태그는 닫아야 함 (
<br />,<img />등 뒤에 슬래시 필수) - 속성값은 무조건 따옴표로 감싸기
- lang 속성 대신
xml:lang사용
이거 안 지키면 리더기에서 "에러 발생" 팝업만 보게 됩니다.
2. CSS: 10년 전으로 돌아갈 시간
"다은 님, 이번에 핫한 :is()랑 :not() 써서 스타일링 좀 편하게 할까요?"
절대 안 됩니다.
ePub 리더기는 최신 크롬 브라우저가 아닙니다. 어떤 건 10년 된 엔진을 씁니다.
화려한 CSS 선택자(Selector)나 최신 레이아웃 기법은 대부분 무시되거나 깨집니다.
가장 보수적인, 가장 원시적인 CSS만 살아남습니다.
[체크리스트]
- 복잡한
calc()연산 지양 - 최신 의사 클래스(
:has,:is등) 사용 금지 - 레이아웃은 최대한 단순하게 (Flexbox도 지원 안 하는 기기 있음)
3. 네임스페이스(Namespace)의 지옥
웹에서는 그냥 lang="fr" 하면 끝이죠?
ePub에선 CSS 선택자도 달라져야 합니다. XML 네임스페이스를 인식해야 하거든요.
/* 웹에서는 이렇게 쓰지만 */
q[lang] { font-style: italic; }
/* ePub에서는 이게 안 먹힙니다. 이렇게 써야 해요. */
@namespace xml "http://www.w3.org/XML/1998/namespace";
q[xml|lang] { font-style: italic; }저 | (파이프) 기호 보이시나요?
저거 하나 때문에 스타일이 적용 안 돼서 개발자랑 3시간 동안 모니터만 쳐다본 적 있습니다.
4. SVG와 MathML? 그냥 넣으면 깨집니다
디자이너로서 고해상도 아이콘을 위해 SVG를 사랑합니다.
하지만 ePub 코드 안에서 SVG나 수학 수식(MathML)을 쓰려면, "나 이거 쓴다!" 라고 명시적으로 선언해야 합니다.
<html> 태그 최상단에 주소(xmlns)를 박아넣고, 태그 앞에 svg:나 m: 같은 접두어를 붙여야 합니다.
안 그러면 리더기는 "이게 무슨 태그야?" 하고 무시해버립니다.
[Action Item]
개발자에게 전달할 때, SVG 코드를 그냥 복사해서 주지 마세요.
반드시 XHTML 네임스페이스가 적용된 스니펫으로 변환해서 줘야 서로 얼굴 붉힐 일이 없습니다.
5. 주석(Footnote) 팝업은 꿈도 꾸지 마라?
디자인 시안에 "주석 클릭하면 멋진 모달 팝업 뜨게 해주세요"라고 그렸나요?
그건 웹 앱일 때 얘기입니다.
ePub은 epub:type="noteref" 같은 전용 속성을 써야 리더기가 "아, 이거 주석이구나" 하고 알아먹고 자체 UI를 띄워줍니다.
애플 북스(Apple Books) 같은 곳에서는 role="doc-noteref" 같은 ARIA 속성이 아직 제대로 안 먹히기도 합니다.
그러니 제발 "토스 앱처럼 팝업 띄워주세요" 같은 기획은 접어두세요.
우리는 ePub 표준이 허락하는 범위 내에서만 놀 수 있습니다.
마무리하며
ePub 작업은 타임머신을 타고 과거로 돌아가는 것과 같습니다.
최신 기술을 뽐내는 게 아니라, 가장 열악한 환경에서도 깨지지 않는 단단함이 미덕인 곳입니다.
"왜 이렇게 안 되는 게 많아?"라고 불평하기보다, 이 제약 사항을 미리 파악하고 개발 가이드에 꼼꼼히 적어두는 것이 우리 디자이너의 역할 아닐까요?
오늘도 1px, 아니 태그 하나 때문에 고통받는 주니어 분들, 파이팅입니다.
(저처럼 epub:type 속성 안 넣어서 개발팀에 불려 가지 마시고요...)
