ePub 폰트 임베딩했는데 리더기마다 글꼴이 달라 보이는 이유

폰트 파일을 꼼꼼히 넣고 @font-face까지 선언했는데, 킨들에서 열면 엉뚱한 서체가 나와요. 애플 북스에서는 맞게 보이다가 리디에서 열면 또 달라지고요. 이 상황에서 가장 먼저 떠오르는 의심이 "파일이 잘못됐나"인데, 보통 그게 아니에요.

W3C EPUB 3.3 표준이 "임베딩 폰트를 반드시 써야 한다"고 리더 앱에 강제하지 않는다는 게 핵심이에요. 각 플랫폼이 독자 설정과 임베딩 CSS 사이의 우선순위를 제각각 정하기 때문에 결과가 갈려 나오는 거예요.

배포 경로·라이선스·원하는 결과 세 축으로 내 상황에 맞는 선택을 찾아가 봐요.

폰트를 넣기 전에 임베딩 허용 라이선스인지 확인해요

어느 플랫폼으로 내보내든, 폰트를 ePub에 넣기 전에 꼭 짚어야 할 게 있어요. 해당 폰트가 '임베딩 및 재배포'를 허용하는 라이선스인지 여부예요. 인쇄 허용과 임베딩 허용은 별개 사안이거든요.

가장 안전한 선택지는 OFL(SIL Open Font License) 폰트예요. OFL은 문서 내 임베딩과 배포를 명시적으로 허용해요. 나눔고딕(네이버)·Noto Sans/Serif CJK(구글)가 대표적인데, 이 폰트들은 ePub에 파일을 포함해서 배포해도 라이선스 문제가 없어요.

상업 서체는 달라요. 유료 서체는 ePub 임베딩을 별도 계약 사항으로 두는 경우가 많아서, '인쇄 출판 허용' 라이선스로 전자책에 넣으면 위반이 될 수 있어요.

폰트 라이선스를 한눈에 확인하려면 폰트비에서 해당 폰트를 검색한 뒤 '사용 범위' 항목을 보세요. 임베딩 허용 여부가 인쇄·웹사이트·영상·포장지 항목과 함께 정리돼 있어요. 실제 근거는 폰트 제작사 공식 배포처 라이선스 원문에서 최종 확인하는 게 순서고요.

→ 임베딩 불허 폰트라면 여기서 멈추고 OFL 대체 폰트를 찾아야 해요. 아래 흐름은 임베딩이 허용된 폰트를 전제로 해요.

킨들로 낸다면 본문 폰트 강제는 포기하는 게 맞아요

킨들은 리플로우형 전자책에서 body CSS에 font-family를 명시하면 그 선언을 의도적으로 제거해요. KDP 공식 지침이 "본문 글꼴은 기본값으로 두라"고 명시하고 있고, 심한 경우엔 임베딩 폰트 파일 자체가 통째로 제거되기도 해요.

다만 제목(h1~h3)·목차·특수 단락 같은 비본문 요소에는 임베딩 폰트가 적용돼요. 독자가 킨들 글꼴 설정에서 'Publisher Font'를 직접 고르면 임베딩 폰트 전체가 살아나고요. 단, 기본값은 킨들 자체 서체이고 대부분의 독자는 그 설정을 건드리지 않아요.

→ 킨들 배포라면: 제목·섹션 구분 요소에만 임베딩 폰트를 쓰고, 본문은 font-family: serif 또는 sans-serif만 남겨요. 분위기를 살려야 하는 표지나 장 시작 이미지는 텍스트 대신 이미지로 처리하면 원하는 서체를 그대로 쓸 수 있어요.

애플 북스는 OPF 선언 하나가 있고 없고를 판가름해요

애플 북스는 임베딩 폰트를 존중하는 편이에요. 단 조건이 하나 있어요. OPF 파일에 <meta property="ibooks:specified-fonts">true</meta> 선언이 없으면 기기 기본 글꼴로 덮어써요. 폰트 파일을 넣었어도 이 선언을 빠뜨리면 고딕 계열 시스템 폰트가 나오고, 많은 분들이 여기서 막히더라고요. 아울러 OPF <package> 요소에 prefix="ibooks: http://vocabulary.itunes.apple.com/rdf/ibooks/vocabulary-extensions-1.0/" 선언도 함께 넣어야 해요.

→ 애플 북스 배포라면: OPF에 specified-fonts 메타 선언부터 넣어요. 이게 없으면 임베딩 자체가 무의미하거든요. 폰트는 OFL이거나 임베딩이 명시적으로 허용된 것만 쓸 수 있고요.

리디북스 등 국내 서점이라면 폰트보다 CSS 기본값을 잡아요

리디는 독자에게 글꼴 선택지를 직접 제공해요. '[원본] 글꼴'을 선택하면 임베딩 폰트가 그대로 나오고, 다른 서체로 바꾸면 임베딩 폰트는 무시돼요. 제작자가 심어둔 폰트가 살아날지는 결국 독자 선택에 달려 있어요.

→ 국내 서점 배포라면: 폰트 조절보다 문단 들여쓰기·행간 같은 CSS 기본값을 꼼꼼히 잡는 게 오히려 더 중요해요. 폰트가 바뀌어도 레이아웃이 흔들리지 않아야 하거든요.

파일 직접 배포는 임베딩 폰트가 가장 잘 살아나는 환경이에요

Calibre나 Thorium Reader 같은 데스크톱 뷰어로 직접 열 때는 @font-face가 의도대로 동작하는 편이에요. 별도 설정을 건드리지 않는 한 임베딩 폰트가 비교적 충실하게 작동하는 환경이에요.

→ 직접 배포라면: 폴백 폰트 스택을 '원하는폰트', 'Noto Serif CJK KR', serif 형태로 구성해두면, 임베딩 폰트가 없는 환경에서도 한글이 깨지지 않아요.

여러 플랫폼에 동시 배포할 때는 강조 요소에만 폰트를 집중해요

킨들·애플 북스·리디를 동시에 노린다면 어떤 플랫폼에서도 깨지지 않는 공통분모로 맞춰야 해요. 본문 폰트는 플랫폼에 맡기고, 표지·제목·인용 블록처럼 '강조 요소'에만 폰트 개성을 집중하는 전략이 가장 넓은 독자층에 통해요.

임베딩했는데 안 보이는 이유가 파일 오류가 아니라 플랫폼 설계라는 걸 알면 절반은 해결된 거예요. 배포 경로를 먼저 짚으면 나머지 선택은 자연히 따라오더라고요. 🙌