대메뉴 바로가기 본문 바로가기

데이터 기술 자료

데이터 기술 자료 상세보기
제목 출판 편집자를 위한 EPUB 전자책 만들기 : EPUB 만들 때 이것만은!!
등록일 조회수 7121
첨부파일  

출판 편집자를 위한 EPUB 전자책 만들기

EPUB 만들 때 이것만은



이 글은 웹 편집 기술을 모르는 출판 편집자를 위한 EPUB 사용 설명서다. 이 글을 끝까지 다 읽는다고 곧바로 전자책을 출간할 사람은 많지 않겠지만, 이 글이 전자책이 무엇인지, 전자책을 만들려면 무엇을 알아야 하는지 이해하는 데에 도움이 되길 바란다.



이번 회에서는 EPUB을 제작할 때 주의할 점을 짚어본다. 이 내용은 표준과 다른 영역이다. 이 글에서 제시하는 것을 따르지 않는다고 하여 EPUB 표준을 위배하는 건 아니다. 하지만 지키지 않으면 국내 전자책 서점의 뷰어에서 해당 전자책이 온전히 열리지 않을 수 있다.



EPUB이 표준인데 “표준이 없다”는 말이 나오는 현실

IDPF는 EPUB이 기기나 환경에 영향을 받지 않고 동일한 형태로 책을 볼 수 있도록 여러가지 규칙을 정리했다. 이를 표준이라고 한다. 그런데 많은 편집자는 EPUB이 표준화되지 않아 유통사마다 EPUB을 별도로 제작해야 한다고 불평한다. 표준이 있는데도 표준이 없다는 볼멘 소리가 나오는 까닭은 다음과 같다.

IDPF는 EPUB에 대해 두 가지 규칙을 정리했다. EPUB을 만들 때와 EPUB 뷰어(IDPF 문서에는 리딩시스템이라고 되어있지만 편의상 ‘뷰어’라고 부르겠다)를 만들 때 지켜야 하는 규칙이다. 그런데 규칙에 세부적인 사항까지 규정하지 않았다. 공개 패키징 포맷(OPF) 2.0 문서에 보면 이런 말이 있다.

“출판물은 유니코드에 정의된 것과 같이 UTF-8이나 UTF-16 인코딩을 사용하여 전체 유니코드 문자 집합을 사용할 수 있다(http://www.unicode.org/unicode/standard/versions 참조). 유니코드의 사용으로 국제화, 그리고 여러가지 언어로 문서를 작성하는 일이 쉬워진다. 하지만, 리딩시스템은 모든 유니코드 문자에 대해 그림문자(glyph)를 제공할 의무는 없다.”

위 글에서 마지막 마지막 문장을 보자. 뷰어는 그림문자를 제공할 의무가 없다는 부분 말이다. 아래아한글을 선호하는 한국의 출판 편집자는 원문자나 괄호, @, $, %와 같은 그림문자를 종종 쓴다. 문제는 특정 글꼴로만 표현 가능한 그림문자()를 입력했을 때다. 이런 문자는 뷰어에 따라서 표시되거나 표시되지 않을 수 있다. 컴퓨터보다 성능이 떨어지고, 기본 폰트 종류가 적은 모바일 기기에 있는 뷰어에서는 표현되지 못할 가능성이 더 높다.

바로 이 지점에서 표준 얘기가 나온다. 그림문자를 포함한 EPUB 파일도 표준을 지켰고, 그림문자를 표현하지 못하는 뷰어도 표준을 지켰다. 그런데 EPUB 파일을 뷰어에서 열면 글자가 깨진다. 이 때문에 애플, 구글, 아마존은 EPUB 제작 가이드를 배포해서 전자책 파일을 까다롭게 검수한다. EPUB 표준을 완벽하게 지킨 전자책이어도 자기들이 세운 규칙과 어긋나면 되돌려 보낸다. 국내에는 전자책 서점이 많아도 전자책 제작 가이드를 배포하는 업체가 많지 않다.



전자책을 만들 때엔 사양 낮은 기기를 염두해야

전자책 독자 중 절반이 전자책을 스마트폰으로 읽는다. 그 때문에 전자책 파일은 스마트폰에 맞춰 만들어야 한다. PC에서 잘 열린다고 전자책 파일 용량을 생각하지 않고 제작하면 전자책 독자의 절반은 그 책을 읽을 수 없다. EPUB 3 전자책을 만들 때 고려해야 하는 최저 사양은 아래와 같다. 이는 EPUB2 전자책을 열 때도 크게 문제가 되지 않는 성능이다.

- 안드로이드 : NEXUS4 / OS 버전 : 4.4.x 이상
- iOS : 아이폰 4S / OS 버전 5.x 이상
*주의! 전자종이디스플레이(EPD)를 사용하는 전자책 전용 기기에서는 EPUB3.0이 작동하지 않을 수 있음)

이보다 성능이 낮은 기기를 쓰는 독자들도 있다. 하지만 한 유통사의 통계 자료에 의하면 위에서 제시한 최저 사양보다 낮은 모바일 기기를 쓰는 독자는 전체 전자책 독자 10명 중 1명도 안 된다. 안드로이드 OS 버전이 다양한 건 문제인데 아직 많은 사용자가 2.3대 버전(진저브레드)을 쓴다. 안드로이드 2.3대 버전 기기는 EPUB2 전자책을 표현하는 데에 무리가 없지만, EPUB3 파일을 지원하지 못한다. 따라서 EPUB3 전자책을 만든다면 이런 사용자를 포기해야 한다.



전자책 한 권당 파일 크기는 300MB 밑으로

기기와 뷰어마다 지원하는 EPUB 파일 크기가 제각각이다. 어느 업체 뷰어는 책 한 권당 2GB를 지원하는가 하면, 어느 업체는 용량이 100MB인 전자책을 제대로 열지 못한다. 고사양 스마트폰에서 잘 열리는 책이 저사양 스마트폰에서 오류가 나기도 한다. 국내 유통사 뷰어로 문제 없이 보게 하려면, 전자책 한 권당 용량이 300MB를 넘지 않는 게 좋다. 위에서 최저 사양 기기로 언급한 단말기에서 보이려면 말이다. 300MB는 그림과 같은 글을 제외한 다른 데이터를 포함한 크기다. 경험상 300MB로 전자책을 만들었을 때에 유통사 뷰어 대부분에서 문제 없이 책을 볼 수 있었다.

2GB까지 지원하는 전자책 서점이 있으니 최대한 그에 맞춰서 만들면 안되느냐는 의문이 들지 모르겠다. 서점은 2GB 전자책을 받아들일지 모르나 독자의 스마트폰은 그 책을 버거워할 수 있다. 구형 스마트폰은 작업 공간인 램이 1GB보다 작기 때문이다. 스마트폰을 살 때 램 2GB, 저장공간 16GB라는 말을 본 적이 있을 것이다. 스마트폰의 작업공간이란 램을 말한다.

램은 대체로 2GB이다. 구형 스마트폰은 1GB보다 작다. 2GB 전자책을 볼 때에 이 용량이 작업공간에 한번에 올라가지 않지만, 램이 1GB인 스마트폰으로 2GB 전자책을 열면 문제가 생길 가능성이 아주 높다. 기억하자. 램이 1GB인 스마트폰을 쓰는 사람들이 아직 많다.



챕터 하나(또는 HTML 파일 하나)의 용량은 200KB 밑으로

전자책 용량이 300MB보다 작다고 하여 문제가 전혀 없는 건 아니다. EPUB 파일은 첫 회에서 얘기했던 것처럼 여러 파일을 압축해서 만든 파일이기 때문에 압축파일에 있는 이미지, 폰트, 동영상, 음성 등 각각의 파일 크기도 살펴야 한다. 특히, HTML 파일은 200KB 이하여야 한다. 아마존이나 애플은 300KB로 제한하는데 이들 회사는 전자책을 볼 환경을 제한한다. 반면 국내 독자는 수십 개가 넘는 다양한 기기로 전자책을 읽는다. 이 때문에 가능한 한 낮은 사양에 맞춰 위와 같은 기준을 제시한다. 200KB는 아래아한글에서 글자 크기 10, 줄간격 160으로 설정하여 50쪽으로 작업한 분량이다.

EPUB에서 HTML 파일 하나는 대체로 챕터 하나에 해당한다. 그런데 종종 책 한 권을 HTML 파일 하나에 담는 편집자를 본다. 책 한 권이 수십 쪽 분량이면 이렇게 해도 별 문제가 생기지 않지만, 종이책 기준으로 300쪽이 넘는 책을 HTML 파일 하나에 담으면 여지없이 문제가 발생한다. 일단 뷰어에서 책을 여는 데에 시간이 오래 걸린다. 평소 전자책을 읽을 때에 책장을 넘기는데 시간이 오래 걸린다는 느낌이 든다면, HTML 파일의 용량 때문일 수 있다.



전자책 한 권에 HTML 파일은 300개까지만

2014년 상반기 기준으로 국대 전자책 독자 사이에서 비중이 높았던 넥서스S, 갤럭시 S2, 아이폰4 이전 모델로 테스트를 했을 때 전자책 한 권에 200KB HTML 파일 300개가 있는 게 적당했다. HTML 파일이 400개가 넘어가면 초기 로딩 시간이 길어지고 페이지를 넘기는 속도가 현저히 떨어진다.

전자책 한 권에 챕터가 300개나 있었던 건 내가 테스트한 책이 판형을 고정한 EPUB(Fixed Layout EPUB) 전자책이었기 때문이다. 첫 회에서 말했듯이 EPUB 전자책은 독자가 글꼴과 글자크기, 줄간격, 여백 등을 조절할 수 있으며, 화면 크기에 따라 한 쪽에 들어가는 글자 수가 달라진다. 판형을 고정한 EPUB은 PDF처럼 독자가 글자 크기를 바꿀 수 없다. 말 그대로 고정형이다. 이와 같은 판형을 고정한 EPUB 전자책은 페이지 하나가 HTML 파일 하나가 된다. 이 때에 HTML 파일 하나의 용량은 200KB보다 작다. 현재 판형을 고정한 EPUB을 지원하는 뷰어가 제한적이어서 정확한 판단을 내리기는 어렵지만, 몇몇 뷰어에서 테스트해 본 결과 600페이지 정도는 무리 없이 표현했다.



표지 이미지는 300DPI 1400픽셀이면 충분

표지 이미지는 가능한 좋은 품질에 큰 크기를 사용해야 한다. 아래 이미지는 7인치 아이패드와 4인치 스마트폰에서 본 같은 책의 표지이미지다. 4인치 스마트폰에서는 화면 가득 표지 이미지가 표시되지만 아이패드에서는 오른쪽과 아래쪽 여백이 많이 남는다.


스마트폰에서 본 표지

아이패드에서 본 표지

표지 이미지는 아무리 작더라도 세로(긴쪽) 사이즈를 기준으로 96DPI에 1024 픽셀보다 커야 한다. 1024 픽셀 이미지라면 고해상도 디스플레이에서 확대를 해도 심하게 깨져 보이지 않는다. 권장하는 크기는 300DPI에 1400 픽셀 이상의 이미지이다. 그리고 최대 300DPI에 4000픽셀보다는 작은 게 좋다. 이보다 크면 낮은 성능의 기기에서는 이미지를 불러오는데 문제가 생길 수 있다. 그리고 이미지 파일 크기는 5MB를 넘지 않는 게 좋다.

- 최소 크기 : 96DPI / 1024 픽셀 이상
- 권장 크기 : 300DPI / 1400 픽셀
- 최대 크기 : 300DPI / 4000 픽셀 미만



본문 이미지는 72DPI이면서 5MB 넘지 않게

본문 이미지는 표지 이미지보다 낮은 품질(DPI)을 사용한다. 전자책 본문에 들어가는 이미지는 96DPI나 72DPI 정도의 웹용 이미지가 적당하다. 이미지 크기는 세로(긴쪽) 기준 4000px 미만, 이미지 크기는 5MB를 넘기지 않아야 한다.

- 권장 크기 : 96DPI 혹은 72DPI로 이미지 내용을 선명하게 확인할 수 있는 크기
- 이미지 파일 하나당 용량 : 5MB 미만
- 한 챕터 내 총 이미지 양 : 30MB 미만

간혹 인디자인이나 으로 작업한 이미지를 전자책에 그대로 쓰는 모습을 본다. 얼마 전 사내에서 테스트하는데 책이 뷰어에서 잘 열리지 않았다. 용량이 400MB가 넘었다. 이미지가 100장이 들었다. 혹시나 하여 이미지 해상도를 보니 600DPI급 인쇄용이었다. 인디지안이나 으로 작업한 이미지를 전자책에 그대로 썼던 것이다. 이 책에 든 이미지를 72DPI로 바꿨더니 용량이 400MB에서 25MB로 줄었다. 독자에게 같은 이미지를 600DPI와 72DPI로 보여주어 차이를 느끼는지 실험한 적이 있는데 다들 차이를 느끼지 못했다. 20인치 모니터와 태블릿, 스마트폰에서 각각 테스트했지만 결과는 같았다.

이미지에 글자가 들어가 있다면 확대를 해도 글자가 선명하게 보이도록 큰 이미지를 사용해야 한다. 대부분의 뷰어에서 본문 이미지를 확대할 수 있는 기능을 지원하기 때문에 표처럼 글자가 들어있는 이미지가 있다면 확대를 했을 때 글자가 선명하게 보일 수 있도록 해야 한다.



폰트는 용량이 크지 않고 모바일에 적합한 것으로

폰트는 모바일에 적합한 걸 써야 한다. IDPF는 TTF, OTF, WOFF등의 폰트를 허용하고 있는데 모바일 기기에 따라 OTF와 WOFF를 지원하지 않을 수 있다. 시간이 지나면 이 부분도 개선이 되겠지만 현재 환경에서 가장 적합한 폰트는 TFF이다. OTF나 WOFF 폰트를 쓰면 기기에 따라 시스템 폰트로 대체될 수 있다.

폰트 파일 하나의 용량은 10MB를 넘지 않도록 하고 여러 개의 폰트를 사용할 경우 폰트 파일 용량의 합이 30MB를 넘지 않도록 하자. 폰트 파일은 전자책을 열때 작업공간(램)에 모두 올라간다. 30MB파일이 한 번에 올라가려면 시간이 오래 걸리기 때문에 책을 여는 시간이 오래 걸리고, 사양이 낮은 기기에서는 공간이 부족해 강제 종료가 될 수도 있다.

- 개별 폰트 파일 크기 : 10MB 미만
- 첨부한 폰트의 총 용량 : 30MB 미만



오디오 파일은 AAC, MPEG3, VBR

아이폰과 안드로이드 그리고 컴퓨터에서 공통으로 사용할 수 있는 형식이 AAC, MPEG3, VBR이다. 이 세 형식 모두 MP3 파일이다. 오디오 품질은 콘텐츠의 내용에 따라 달라질 수 있으나 96kbps ~ 192kbps의 품질을 권한다. 최신 기기에서는 그 이상의 품질도 지원이 가능하지만 EPUB을 볼 수 있는 최저 사양의 기기를 고려해야 한다. 토익 듣기용 MP3 파일은 96kbps이면 충분하다. 클래식 음악을 소개하는 책이라면 192kbps 정도의 고음질을 사용한다.



비디오 파일은 H.264 MPEG4로 인코딩

H.264, MPEG-4로 인코딩 된 파일이면 iOS와 안드로이드 기기에서 모두 사용할 수 있다. 두 형식의 확장자는 MP4, AVI이다. 화면 크기는 640(720)×480 혹은 720p 해상도를 권장한다. EPUB3로 제작을 한다면 풀HD급인 1080p를 사용해도 된다. 이보다 작으면 영상의 품질이 떨어지고, 크면 용량이 크게 증가할 수 있다.



파일 이름은 반드시 영어로

EPUB내에 포함된 모든 파일의 이름은 영문, 숫자, 언더바(_) 하이픈(-)만 사용하기를 권한다. 그리고 영문명으로 시작해야 한다. 파일 이름을 한글로 적는 편집자가 많은데 주의해야 한다. 대소문자 구분도 확실히 해야한다. 컴퓨터에 word라는 단어와 WORD라는 단어는 서로 다르다. 당연히 Section.html과 section.html도 서로 다른 파일이다. 펀집자들이 많이 하는 실수를 몇가지 소개한다. 아래 파일 이름은 윈도우 PC에서 문제가 되지 않더라도 iOS, 안드로이드, 리눅스 등에서는 문제를 일으킬 수 있다.

- 한글 파일명 : 챕터001.html
- 특수문자를 사용한 파일명 : chapter#01&001.html
- 숫자나 특수문자로 시작되는 파일명 : 001_image.jpg
- 대소문자로 구분된 동일한 파일명 : cover.html / COVER.html
- 공백이 삽입된 파일명 : image 001.jpg

파일명의 길이도 확인을 해야한다. 파일명은 확장자를 포함해서 255byte를 넘어서는 안된다. 영어와 숫자는 글자 하나가 1byte이고, 한글은 글자 하나가 2byte이다. 파일명에 대해서는 IDPF의 설명을 참고하자. (http://www.idpf.org/epub/30/spec/epub30-ocf.html#sec-container-filenames)



HTML 파일에 빠뜨리면 안 되는 것 : 언어설정, 네임스페이스

[?댁??곌린瑜??????? 諛⑸??????. ?ㅼ??곌린??]
뷰어에서 책을 열었는데 본문이 위와 같이 보인다면 HTML 파일 상단에 아래 내용을 포함해야 한다.

< ?xml version="1.0" encoding="utf-8"?>

위와 같이 하였는데 아래의 예시처럼 글자가 표시가 안 된다면
[????? ????? ??? ????? ??? ??]
[ㅁㅁㅁㅁ ㅁㅁ ㅁㅁㅁㅁ ㅁㅁㅁ ㅁㅁㅁㅁ ㅁㅁ.]

언어를 제대로 설정했는지 확인하자. HTML 파일에 아래와 같은 내용이 있는지 점검하기 바란다. 해당 전자책이 한국어로 쓰였다는 뜻이다.

< html xml:lang="ko" lang="ko">

EPUB 제작기는 HTML 파일을 기본으로 UTF-8로 설정한다. 하지만 언어설정은 반드시 편집자가 지정해야 한다. 편집 프로그램 별로 환경설정에서 기본 언어설정을 지정할 수 있게 되어 있다. 네임스페이스는 HTML 파일 안에 포함된 내용이 어떤 종류인지를 뷰어가 이해할 수 있도록 알려주는 역할을 한다. 예를 들어 HTML 안에 SVG이미지가 포함되어 있다면 이 파일에는 SVG가 포함되어 있다고 뷰어에게 알려줘야 한다. 그렇지 않으면 EPUB Checker에서 오류가 발생하고 뷰어에서 제대로 보이지 않을 수 있다. 네임스페이스는 아래처럼 지정한다.

< html xmlns="http://www.idpf.org/2007/ops">

EPUB에서 많이 사용하는 네임스페이스는 아래와 같다.

속성별 네임스페이스는 IDPF 문서에서 확인하자.

http://www.idpf.org/epub/301/spec/epub-contentdocs.html#sec-overview-nspfx

인코딩은 HTML파일 상단에서 설정을 해 주고, 언어설정과 네임스페이스는 태그에서 지정한다. HTML파일 내용에 따라 언어 설정과 네임스페이스는 달라질 수 있으니 주의해야 한다. 그리고 언어설정과 네임스페이스는 모두 태그에서 지정해 주기 때문에 아래처럼 둘을 동시에 지정할 수 있다.

< html xmlns="http://www.idpf.org/2007/ops" xml:k:lang="ko" lang="ko">



출처 : 마이크로소프트웨어 9월호

제공 : 데이터 전문가 지식포털 DBguide.net