내맘대로의 EPUB 제작 가이드

오늘은 전자책 편집 중 많이 하는 '실수'를 정리하겠습니다. 이런 실수를 해도 뷰어에서는 정상적으로 보입니다. 그래서 많은 분들이 이런 편집을 잘못이라고 생각하지 않어요. 하지만 잘못 사용한 코드는 언젠가 오류로 보답을 합니다. 아주 조금만 신경쓰면 되니까 아래 몇가지만 지켜보세요.

1. 제목은 반드시 헤딩 태드(h1 ~ h6)를 사용한다.

IDPF의 EPUB3 권고안에는 제목을 헤딩 태그를 사용하도록 강력하게 권하고 있습니다. 현재 유통되고 있는 전자책 중 제목을 헤딩 태그가 아닌 CSS 스타일과 p 태그로 지정한 책이 많습니다. 이런 책들은 뷰어에 정상처럼 보이지만 표준을 지키지 않은 편집이에요. 

시중에 유통되는 편집기 중에서도 제목을 헤딩 태그가 아닌 p태그에 스타일을 적용해 표현하는 경우가 많습니다. 편집기가 제공하는 기능이라고 표준에 맞는건 아니니 편집할 때 주의를 하세요.

2. 본문은 반드시 <p> 태그를 사용합니다.

Sigil로 편집한 책 중에 보면 <div>태그로 분문을 묶은 것을 종종 볼 수 있습니다. Sigil의 빈 화면에서 백스페이스를 마구 누르면 HTML 코드가 이렇게 되요.

이 상태에서 엔터를 치면 이렇게 됩니다.

여기에 텍스트를 붙여넣으면 본문 태그가 <p>가 아닌, <div>태그로 감싸지게 됩니다. 역시 뷰어에서는 아무 문제가 없어 보이지만, 아주 심각한 '실수'입니다. 본문은 반드시 <p>태그로 묶여야 하거든요. 

간혹 글상자를 만들때 이렇게 편집하는 분들도 있습니다. 

이건 표준에 벗어나지는 않지만 좋은 코드라고 보기 어려워요. 본문 내용은 <p> 태그로 묶어줘야 합니다.

3. 본문 스타일은 클래스를 지정하지 마세요.

본문을 클래스를 이용해 편집하는건 제약이 있는 것도, 표준에 어긋나는 것도 아닙니다. 하지만 그래야 할 필요가 없는데 불필요한 작업을 반복해서, 그것도 수천번을 반복해서 해줄 필요는 없잖아요.

무슨 소리냐고요?

CSS에 스타일을 적용할 때 본문 전체를 대표하는 스타일을 클래스로 지정하는 분들이 의외로 많이 있습니다. 이런 식이지요.

책 내용의 90%가 넘는 본문 스타일을 클래스로 지정하게 되면 class="maintext" 스타일이 수천번 들어갑니다. 이렇게 편집해야 할 이유는 전혀 없습니다. 그냥 p 태그에 스타일을 적용하면 되요.

그럼 <p> 태그로 묶여있지만 다른 스타일을 적용해야 할 때는 어떻게 해야하냐구요? 그 스타일만 클래스를 지정하면 되지요. CSS는 스타일 상속을 받지만, 마지막에 상속받은 스타일로 표현이 되기 때문에 <p> 태그에 기본 스타일을 적용한다 해도 다른 스타일을 적용하는데 아무 문제가 없습니다.

4. 불필요한 스타일은 넣지 마세요.

CSS 스타일을 만들 때 불필요한 스타일을 반복해서 쓰는 분들이 많이 있습니다. 전자책 편집기의 CSS 생성 프로그램을 이용해 만들었다고 강하게 의심이 되지만, 그래도 이런 편집은 피하는게 좋습니다.

/*필요 없는 스타일*/이라고 표시한 항목들은 뷰어 기본 설정을 따르도록 되어 있습니다. 뷰어 기본 설정을 따르는 스타일이나 적용해도 의미 없는 스타일은 추가할 필요가 없습니다. 넣지 않아도 뷰어에서 보이는건 똑같습니다. 

그럼 넣어도 상관 없잖아 라고 생각하실 수 있는데, 저런 코드가 들어가면 뷰어는 '아무것도 아닌 스타일'로 적용을 하느라 단말기 자원을 사용하게 됩니다. 쉽게 말해 뷰어에서 책이 열리는 속도가 느려지거나, 오류가 생길 가능성이 높아진다는 얘기에요.

* 참고로 들여쓰기가 필요 없는 스타일은 text-indent : 0; 을 추가해 주는게 좋아요. 강제 들여쓰기를 하는 뷰어가 많이 있어 들여쓰기 하면 안되는데 들여쓰기가 되는 경우가 종종 있거든요.

5. 똑같은 스타일은 재활용하세요.

시중에 유통되는 전자책 중에 아래처럼 똑같은 스타일이 무한반복되는 책들이 있습니다.

아마도 위지윅 방식의 편집기에서 텍스트 하나를 선택해 스타일 지정, 다른 텍스트 선택 후 스타일 지정... 이런 식으로 편집을 했기 때문일거예요.

이것 역시 책 열리는 속도가 느려지거나 오류 가능성을 높이게 됩니다. 똑같은 스타일은 특별한 의미를 둔 스타일이 아닌 이상 하나만 있으면 되요.

이런 부분들만 주의를 해도 전자책의 코드가 깔끔하게 정리될거예요. 코드가 깔끔한 책은 뷰어에서 열리는 속도가 빨라지고, 오류도 적게 발생합니다. 그리고, 어떤 환경에서도 편집자가 원하는 모양으로 책이 보이고요 ^^

책이 디지털로 변하면서, 종이책도 전자책도 아닌 제3의 매체가 될 분야를 설명하면서 예로 드는게 사전입니다. 운동, 여행, 요리레시피 같은 몇몇 카테고리는 책이 아닌 다른 형태로 발전을 할 수 있다고 얘기하면 종이책의 틀에 갇혀있는 분들은 이해를 하지 못합니다. 이때 '사전'을 예로 들어줍니다.

종이로 된 두꺼운 사전이 전자사전으로 바뀌었다가 이제는 전자사전 조차 역사가 될 판입니다. 백과사전의 절대 강자 브리태니커의 아성은 위키피디아에 무너져 내렸고, 아무리 정보의 '질'을 소리높여 외쳐봐도 간단한 정보는 '지식인'을 찾습니다.

운동, 여행, 요리레시피 같은 책들은 사전과 같은 길을 걷게 될거라고 생각합니다. 전자책이 될 가능성도 아주 낮습니다. 이 카테고리는 사전처럼 책의 분류에서 사라질 가능성이 아주 높습니다. 종이책의 틀에서 이 분류의 책을 만드신 분들은 말도 안된다고 생각할 수도 있습니다. 비디오 테잎, 동영상 CD, 유튜브 QR 코드 등을 활용하면서 다른 분야보다 기술 발전에 발빠르게 대응하고 있는데 무슨 소리냐고 하실 분들도 계실거예요.

골드님이 주신 질문입니다.

Sigil 에서 정규표현식을 이용하다 보면 원하지 않는 값까지 찾게 되는 경우가 있습니다.

한자나 한글은 조금 덜한 편인데 영문이나 숫자를 찾을 때 이런 문제가 자주 발생하지요.

예를 하나 들어보겠습니다.

이 문장을 정규표현식으로 찾아 스티브 잡스, 인크레더블, 토이스토리 뒤에 붙은 영문에만 스타일을 주고 싶다면 어떻게 해야 할까요?

먼저 정규표현식으로 영어 단어를 찾아보겠습니다. Sigil 찾기 창에서 정규표현식을 선택한 후 ([a-zA-Z]+) 를 입력합니다. 한 단어씩 찾기 위해 +를 추가했습니다. 그리고 찾기 버튼을 누르면 어떻게 될까요?

EPUB의 본문은 HTML로 되어 있어 본문의 단어를 찾기 전에 HTML 코드에 있는 xml이라는 영어를 먼저 찾아줍니다. 다음 찾기를 아무리 눌러 봐야 HTML에 영문이 너무 많아서 수작업으로 하는 것 보다 효율이 나지 않습니다.

이런 문제를 해결하려면 정규표현식을 사용하기 전에 무슨 목적으로 사용하느냐를 본인이 정확히 알아야 합니다.

이런것도 모르고 할 사람이 있을까 싶겠지만, 많은 사람들이 자신이 원하는게 뭔지 모르는 상태에서 막연한 개념만 갖고 시작하는 경우가 많습니다. 그러면 식을 세울 수가 없게 되지요.

전자책을 편집할 때 영어 단어를 찾아야 하는 이유가 뭐가 있을지를 먼저 생각해 보겠습니다.

제가 전자책을 만들면서 언제 정규표현식을 쓰는지를 정리하고,  각각의 상황에 맞는 식을 하나식 설명드리겠습니다.

저는 아래와 같은 이유로 정규표현식을 많이 사용합니다.

윗첨자 패턴의 영문, 한자, 일본어 단어에 스타일을 적용해야 할 때

주로, 단어 뒤에 붙은 설명을 윗첨자 형태로 스타일을 적용해야 할 때 많이 이용합니다. 

책을 편집하다 보면 이런 편집을 많이 사용합니다. 책 한권에 수백개 이상 들어있는 윗첨자를 하나씩 찾아내 수정하려면 시간이 오래 걸리기 때문에 정규표현식을 사용합니다.

이런 편집에는 '패턴'이 있습니다. 이 패턴을 찾는게 정규표현식을 세우는데 가장 중요합니다.

예로 든 텍스트들은 전자책으로 편집하기 전에는 윗첨자가 적용돼 있지 않습니다. 그렇기 때문에 윗첨자는 패턴이 될 수 없습니다.

스티브 잡스Steven Paul Jobs

이 문장에서 찾을 수 있는 가장 확실한 패턴은 한글영어단어, 한글한자, 한글일본어 등 한글 뒤에 바로 단어가 온다는 점입니다. 윗첨자 형으로 설명이 들어간 단어는 괄호 같은 구분기호를 붙이든, 구분기호 없이 바로 단어를 붙이든 한글에 붙어 영문이나 한자가 나오는게 일반적입니다.

한글영문 패턴은 책을 편집할때 많이 나오지 않습니다. 윗첨자 설명 같은 특수한 경우가 아닌 이상 한글과 영문은 띄어쓰도록 되어 있습니다. 그래서 한글영문은 정규표현식으로 사용하기 좋습니다. 그렇다고 본문의 모든 윗첨자만 이 패턴이 적용되고, 다른 내용에는 이런 패턴이 없다는 보장은 할 수 없으니 편집자가 책의 내용에 따라 패턴을 확인할 필요는 있습니다.

한글영문 패턴일 때는 이런 식을 쓸 수 있습니다.

그런데 결과가 이상하지요? 찾기를 원하는건 영문인데 선택은 한글 단어와 영문이 함께 됩니다. 

여기서 다시 '목적'을 생각해야 합니다. 만약, 영문 단어를 확인하려는 목적이라면 이렇게 선택된다 해도 아무 문제 없습니다. 눈으로 확인하면 되니까요. 그런데 영문 단어에만 스타일을 적용하고 싶다면, 다시 말해 찾아바꾸기를 하고 싶다면 이렇게 선택되서는 곤란합니다.

정말 곤란할까요?

만약 아래와 같은 단어라면 전혀 곤란할 일이 없습니다.

이렇게 한글 단어 하나에 영문 단어 하나짜리라면 위에 설명한 식으로 찾아바꾸기가 가능합니다.

찾기와 바꾸기 영역에 이렇게 해보세요. 그러면 결과는 이렇게 나옵니다.

Sigil은 정규표현식으로 단어를 찾을 때 괄호를 하나의 묶음으로 처리합니다. (표현식1)(표현식2) 처럼 식을 괄호로 묶어 주면 바꾸기를 할 때는 \1, \2로 찾은 단어를 넣어줄 수 있습니다. 찾기 영역에서 (표현식1)이 찾은 단어는 바꾸기 영역에서 \1로, (표현식2)가 찾은 단어는 \2로, 표현식이 3, 4, 5개로 늘어나면 \3, \4, \5로 대치를 할 수 있습니다. 그렇기 때문에 한글abc으로 선택됐다 해도 abc에만 스타일을 적용할 수 있게 됩니다.

참고로, ([가-힉]+)를 ([가-힉])으로 바꿔도 이 식에서는 지장이 없습니다. 잡스Jobs를 찾든, 스Jobs를 찾든 결과는 동일하니까요.

이번에는 조금 더 확장을 해 보겠습니다.

이런 패턴 역시 한글영문 패턴입니다. 다만 한글영문, 한글영문 영문... 의 패턴이 되는거지요.

이런 형태는 조금 까다롭습니다. 패턴이 분명하다면 문제가 되지 않는데 패턴이 2개 이상으로 복잡해집니다. 먼저 '스티브 잡스Steven Paul Jobs는' 패턴을 비교하면 이렇습니다.

한글영문 공백 영문 공백 영문...... 영문한글

이런 패턴이라면 이렇게 처리할 수 있습니다.

패턴의 중요한 포인트는 [한글영문....영문한글]입니다. 영문을 찾는 식에 물음포(?)를 넣어 준건 패턴을 너무 넗게 잡는걸 방지해주기 위해서입니다.

([a-zA-Z].+?)

이 식으로 찾은 영문단어에만 스타일을 지정하고 싶다면 바꾸기 영역에 아래처럼 넣어주면 됩니다.

그런데 이 식을 사용하면 '애니메이션Animation 제작사'가 문제가 됩니다. '《인크레더블The Incredibles》' 같은 패턴도 문제가 되고요.

애니메이션Animation 제작사

이 패턴은 \2가 대체하는 단어 영역이  'Animation '까지입니다. 공백이 포함되지요. 

《인크레더블The Incredibles》

여기서는 'The Incredibles》'까지 포함을 하게 됩니다. 

이런 문제를 해결할 방법이 아주 없는건 아닙니다. 하지만 식이 점점 복잡해지고, 식이 복잡해 지면 엉뚱한 결과가 나올 수 있습니다.

지금까지 설명도 상당히 복잡했는데 더 복잡해진다면 이 글도 보기 싫어지시겠지요^^?

그래서 제가 쓰는 아주 단순 무식한 방법이 하나 있습니다.

한번에 끝낼 수는 없지만 결과는 확실한 방법입니다.

먼저, 본문에 윗첨자가 달려야 하는 단어의 최대 갯수를 확인합니다. 인명이나 지명 같은 명사라면 많아야 4~5개 단어로 끝납니다. 만약 단어의 최대 갯수가 4개라면 아래 식을 반복합니다.

단순 무식한 방법이지만, 패턴을 단순화시켜 다양한 예외들을 모두 차단해 버렸습니다.

위 식의 패턴은 이렇습니다.

먼저 '한글영문1 영문2 영문3 영문4'을 찾습니다.

이 패턴은 한글영문, 한글영문1 영문2 패턴은 무시합니다. 만약 한글영문1 영문2 영문3 영문4 영문5라는 패턴이 있다면 문제가 됩니다. 그래서 가장 긴 영어단어 수를 확인해야 합니다. 

그 다음 영어단어를 하나씩 줄여가며 찾아줍니다. 

한글영문1 영문2 영문3은 영문4까지 있는 단어라면 문제가 되지만, 영문4까지 있는 단어는 이미 교체했기 때문에 영문3까지 있는 패턴에는 걸리지 않습니다. 영문2까지 있는 패턴 역시 영문3을 처리한 후라면 문제가 되지 않고요.

이 방식이 가능한 이유는, 대부분의 책이 윗첨자 설명을 문장 보다는 인명이나 지명 같은 단어를 처리하기 위해 사용하기 때문입니다. 그리고 인명이나 지명은 길어야 4~5단어 정도로 짧기 때문에 많아야 5번 내외로 반복해 주면 윗첨자형 설명은 모두 바꿀 수 있습니다.

본문 내에 있는 영어 단어만 찾아야 할 때도 있습니다.

윗첨자 같은 설명이 아닌, 본문 내의 영어 단어로, 한글과 다른 폰트를 적용하고 싶다면 '한글영문'이 아닌 '한글 영문' 형태의 패턴이 됩니다. 

이런 형태 역시 패턴을 먼저 찾는게 중요합니다.

본문 내에 쓰인 영문 단어라면 이런 패턴일 가능성이 높습니다.

한글 영문 한글

한글 영문1 영문2.... 한글

이런 패턴은 위의 식을 약간 수정해서 처리할 수 있습니다.

이런 패턴은 한글이 앞에 나오고, 한칸 공백을 띈 후 영문 단어가 여러개 나옵니다. 영문 단어 뒤에는 'CEO였다'cjfja 한글이 붙을 수도 있고, 'Toy Story 등을' 처럼 공백이 올 수도 있습니다.

공통되는 패턴은 한글+공백+영문, 영문이 몇개가 오든 시작은 이렇습니다. 그렇다면 윗첨자를 바꿀 때처럼 가장 긴 영어 단어 수에 맞춰 반복을 할 수 있습니다.

태그 사이에 영문만 들어있는 경우도 있습니다. 

위에 두 예는 한글이 들어있어 태그를 무시할 수 있었는데 태그와 태그 사이에 영문만 있을 경우에는 찾기 어렵습니다.

그럴 때는 태그 자체를 이용합니다. 

이 식은 <p...>태그를 찾아줍니다. <p> 태그 안에 어떤 클래스나 스타일, ID가 추가되든 상관 없습니다. 만약 <p class="title">...</p>로 묶인 영역을 <p>태그 대신 제목 태그인 <h2>로 바꾸고 싶다면 이 식을 활용할 수 있습니다.

<p> 태그 안에 영문만 있는 문단을 찾고 싶다면 (.*) 부분을 수정해 주면 됩니다. ([a-zA-Z].+) 처럼요.

원하는 패턴에 맞게 식을 세워주면 다양하게 활용할 수 있습니다.

정규표현식을 제대로 활용하려면 두가지를 꼭 기억하세요.

1. 내가 찾고자 하는 내용의 패턴을 알아낸다. 이 패턴이 정규표현식이 됩니다.

2. 사용할 목적을 확실히 알고 있어야 한다. 찾아바꾸고 싶은지, 확인만 할건지, 전부 바꿀건지, 부분만 바꾸고 싶은지 등에 따라 식이 달라지고, 바꿀 영역에 들어갈 내용도 달라집니다.

이 두가지만 정확히 알고 있어야 정규표현식의 도움을 받을 수 있습니다.

이북스펍 최피디님 덕에 알게된 EPUB 검사기입니다. IDPF에서 배포하고 있는건 터미널에서 명령을 입력해야 하는 방식이고, 윈도우 터미널에서는 오류가 많을 경우 전부 확인하기 어려운 문제가 있습니다. 웹으로 제공하는 validator 역시 10mb라는 용량 한계가 있어 이미지가 많이 들어있는 파일은 검사가 어려웠고요.

이 프로그램은 설치 없이 실행할 수 있고, 로그를 저장할 수도 있습니다. 사용법도 간단합니다. 검사할 파일을 선택 후 validate 버튼만 눌러주면 되거든요.

Sigil에서 Validator가 플러그인 형태로 바뀌며 빠졌는데 EPUB 검사기가 필요하신 분들은 이 프로그램을 사용하시면 도움이 될거예요.

1. 콘텐츠 표준이 없어 호환이 되지 않는다.[보러 가기]

2. DRM 때문에 하나의 뷰어로 서로 다른 서점의 서비스를 이용할 수 없다.

콘텐츠를 보기 위해 업체별로 다른 뷰어를 설치해야 하는 이유는 DRM 때문이다. 이 말은 반만 맞다. 

2009년에 삼성에서 만든 SNE-60이라는 모델의 전자책 전용 단말기를 보면 예스24, 조선일보(텍스토어), 교보문고의 책을 모두 이용할 수 있었다. 넥스트파피루스라는 업체의 페이지원도, 아이리버의 스토리도 여러 업체의 첵을 지원했다. DRM 때문에 뷰어 하나로 여러 유통사의 책을 볼 수 없다면 이런 기기들은 존재할 수 없다.

하나의 뷰어에 여러 DRM을 적용하는 일은 서비스 혹은 사업적인 이유지 기술적인 문제는 아니다. 뷰어에 있는 DRM 모듈은 복호화, 인증된 사용자 확인, 사용 기간 확인 등 비교적 간단한 기능을 요구 한다. 그래서 유통사가 이런 업무를 처리할 수 있는 모듈을 제공하면 어떤 뷰어에서라도 교보문고, 리디붃, 예스24의 전자책을 볼 수 있다. DRM 모듈은 DRM의 모든 비밀을 알려줄 수 있는 소스코드가 아닌, 필요한 기능만 사용하고, DRM의 비밀까지는 확인할 수 없도록 컴파일 된 SDK 형태로 제공을 한다. 뷰어 개발자는 DRM을 통해 콘텐츠를 복호화시키고 자신들의 뷰어에서 열어볼 수 있게 할 수는 있지만, DRM 자체를 해체시키지 못하고, 뷰어 개발사도 자신들이 제공한 SDK에 해당 뷰어에서 누가 언제 어떤 콘텐츠를 다운로다 받고 열어봤는지를 확인할 수 있기기 때문에 불법복제 등의 문제를 방지할 수 있다.

그런데 왜 유통사는 'DRM이 전자책 활성화를 방해하는 주범이다'라는 소리를 들으면서도 이런 서비스를 제공하지 않는 것일까?

업체별로 다른 뷰어를 사용해야 하는 이유는, 업체별로 서비스가 다르기 때문이다. DRM 문제가 아닌 서비스의 문제다. 이용자들은 책을 구매하고, 다운받아, 열어서 보는데 무슨 서비스냐 하겠지만, 구매에서 책을 보기까지, 그리고 보는 과정에서 행하는 여러 행동들은 아주 복잡한 시스템을 거치게 되어 있다. 그리고 어떤 업체는 EPUB2와 이미지를, 어떤 업체는 EPUB2와 EPUB3를, 어떤 업체는 자체 포멧의 파일과 EPUB2를 지원한다. 어떤 업체는 연재서비스를 제공하고 어떤 업체는 만화서비스를 제공한다. 한 기기에서 여러 DRM을 처리하는건 간단하지만, 한 기기가 업체별 서로 다른 서비스를 모두 지원하기는 아주 어렵다. 엄청난 비용이 들어가야 하는데 들인 비용만큼 수익을 낼 수는 없다. 뿐만 아니라 유통사가 원하는 서비스를 뷰어 제공 업체가 100% 이해하고 반영하는 것 역시 불가능하다. 

아주 간단한 예로, 네이버 서비스를 보자. 네이버는 EPUB/이미지 뷰어 기반의 네이버 북스 서비스와 이미지 연재 기반의 웹툰, 텍스트 연재인 웹소설 서비스를 제공한다. 그런데 이 서비스를 보는 뷰어는 모두 다르다. 네이버 북스, 네이버 웹툰, 네이버 웹소설을 각각 다른 앱으로 봐야한다. 네이버 같은 IT 전문 기업조차 서비스를 나누는데 '전자책'이라고 뭉뚱그려 유통사별로 서로 다른 서비스를 뷰어 하나에서 이용하도록 만들 수는 없다. DRM 때문에 하나의 뷰어로 여러 유통사 서비스를 이용할 수 없는게 아니고 유통사별로 제공하는 서비스가 서로 달라(독자들은 똑같다고 느끼겠지만 버스와 지하철 만큼 달라) 뷰어를 통합할 수 없는 것이다.

같은 운송수단이니 버스도 지하철처럼 철길을 깔고, 전력선을 세워 10량씩 운행하면 공해 문제도 해결할 수 있고, 길막힘도 없을 것 아니냐는 얘기와 비슷하다. 승객 입장에서는 문이 열리면 표를 내고 원하는 지점까지 이동하는 수단이니 버스와 지하철이 별 차이 없어보여도, 버스기사와 지하철 기관사의 입장에서는 둘은 전혀 다른, 서로 통합될 수 없는 운송서비스일 것이다. DRM도 이런 관점에서 바라봐야 왜 통합이 어려운지 이해할 수 있다.

DRM이 문제라고 하는 사람들한테 DRM이 뭐냐고 물어보면 제대로 답하는 사람이 거의 없다. 그럼 왜 DRM이 문제냐고 물어봐도 제대로 된 답을 하는 사람이 없다. 신문 기사로 본 얄팍한 지식으로 'DRM이 달라 책이 열리지 않는다'는 수준의 답을 할 뿐이다. 이 말 역시 반만 맞다.

DRM은 콘텐츠의 사용을 제어하기 위한 장치다. 하지만 현실에서는 조금 더 복잡한 의미를 담고 있다. 위키피디아에서 '혼동하기도 한다'는 복사 방지, 기술 보호 장치 까지 DRM 시스템에 포함되어 있으며 사용할 때 뿐 아니라 유통사의 서버에 저장할 때도 DRM을 걸어놓는다. 해킹을 당해 서버에서 직접 콘텐츠를 빼내더라도 파일이 암호화 되어 있어 만일의 사태에 대비할 수 있다.

DRM은 다른 역할도 있다. DRM은 단순히 인증 받은 기기에서 콘텐츠가 열리도록 제한하는 기능이 아니다. 이 사람이 콘텐츠를 다운받을 권한이 있는지, 언제까지 다운받을 수 있는지, 언제까지 이용할 수 있는지, 이용 기간이 지나면 어떻게 처리를 할지 등 서비스와도 긴밀하게 연결돼 있다. 페이지 일부만 보게 하는 것도 DRM 시스템이 담당하고 있다. 쉽게 말해 구매부터 콘텐츠를 열어보기까지 모든 과정이 DRM과 연결돼 있는 것이다.

이뿐 아니다. SNS 이용이 늘어나면서 책속의 좋은 문장을 공유하는 기능이 뷰어에 담겨있다. 그런데 책의 처음부터 끝까지 공유를 할 수 있다면 문제가 된다. 예전에는 본문 텍스트 선택 자체를 막았지만 공유를 위해 텍스트 선택을 열어뒀으니 얼만큼 선택이 가능하게 할지, 몇 번까지 공유를 하게 만들지 등을 제한하는 기술이 필요하고, DRM 시스템에 포함되지 않을 수는 있지만 넓은 의미에서 이 역시 DRM의 역할이다.

유통사별로 서로 다른 서비스를 제공하면서 DRM을 통일한다는 것은 현실적으로 불가능하다. DRM을 통일시키겠다는 프로젝트를 들여다 봐도 DRM 자체를 통일시킨다기 보다는 콘텐츠의 암호화/복호화 방식을 통일시키는 수준일 뿐이다. 콘텐츠의 암호화/복호화 기술을 통일시키면 교보에서 산 전자책을 예스24 뷰어로 볼 수 있을까? EPUB2로 제작된 책은 가능하다. 그런데 교보에서 판매중인 EPUB3 콘텐츠 '미움받을 용기 - 음악이 들리는 ebook'은? Sam 서비스 역시 예스24 뷰어로는 이용하기 어렵다. 네이버 N스토어에 있는 연재 콘텐츠를 교보문고 뷰어에서 보고싶지 않다. 연재는 결제와 긴밀하게 연결되어 있는데 DRM이 통일된다고 해도 네이버가 교보에 결제모듈까지 연동시키지는 않을 것이다. 

일부에서는 MP3를 예로 들면서 non-DRM이라면 뷰어가 통합될 수 있지 않겠냐고 얘기한다. 그런데 MP3 플레이어는 통합되어 있을까? 단순히 음악을 듣는 서비스라면 non-DRM MP3 파일은 어떤 플레이어에서도 이용이 가능하다. MP3는 음악을 듣는 서비스에 치중되어 있어 플레이어(전자책에서라면 뷰어) 통합된 것 처럼 보인다. 하지만 이 역시 사실이 아니다.

이용율은 낮아도 시중에는 다양한 형태의 MP3 파일이 존재한다. 그리고 음악 서비스는 MP3로만 제공되지 않는다. MP3 뷰어가 정말 통합되어 있다면 멜론의 스트리밍 서비스를 벅스에서도 들을 수 있어야 한다. 너무 나갔다고 생각했다면, m4b 포멧을 보자. 이 역시 MP3에 기반한 파일이지만 오디오북을 위해 만들어졌다. 일반 MP3 플레이어에서는 m4b 포멧을 제대로 지원하지 않는다. 지원을 하더라도 m4b가 제공하는 오디오북에 특화된 기능은 지원하지 못한다. 그래서 별도의 오디오북용 플레이어가 존재한다. 

음악 CD를 음원 손실 없이 추출해 주는 유형의 포멧도 있다. 이 파일은 mp3처럼 음악별로 하나의 파일로 저장되는게 아니고, CD가 통으로 하나의 파일이 된다. 많은 MP3 플레이어가 이 포멧을 지원하지만 제대로 듣기는 어렵다. 대부분 CD의 1트랙부터 플레이를 하는 방식이다. 하지만 일부 플레이어는 파일 안에 있는 음악을 트랙별로 선택해 들을 수 있고, 다른 파일과 목록 구분 없이 플레이할 수도 있다.

MP3 역시 서비스가 서로 다르기 때문에 그에 최적화 된 플레이어가 존재하는 것이다. 전자책 역시 서로 다른 서비스를 제공하기 때문에 유통사별로 서로 다른 뷰어를 사용하는 것이지 DRM이 통합되지 않아서 서로 다른 뷰어를 이용하도록 강요하는게 아니다.

DRM은 단순히 콘텐츠의 불법 유통을 막는 장치가 아니다. '전자책 서비스'의 구석 구석에 DRM이 연결되어 있다. 그리고 DRM만 단독으로 작동하지도 않는다. DRM은 회원정보와 연결되어 있고, 결제시스템과 연결되어 있다. DRM 때문에 하나의 뷰어로 여러 유통사의 콘텐츠를 볼 수 없는게 아니고 '전자책 시스템'과 '전자책 서비스'가 유통사마다 다르기 때문에 뷰어를 통합시키기 어려운 것이다. 

모든 유통사가 EPUB2, EPUB3를 지원하고, 회원관리도 하지 않으며 콘텐츠를 일정 기간만 다운받을 수 있게 한다면 DRM 통합이 가능하다. 이런 서비스라면 DRM에 콘텐츠 사용 권한을 부여받은 사람(구매자)의 정보를 담아 암호화시킨 후 통합뷰어가 이를 복호화 할 수 있도록 하면 쉽게 통합뷰어를 만들 수 있다. 독자들이 음악만 듣는 MP3 다운로드 방식의 서비스를 이용하듯이 텍스트 중심의 책만 읽어도 된다면 말이다.

통신사를 통한 전자책 판매량은 생각보다 많습니다. 통신사와 거래를 하고 있지 않다고 생각하는 출판사도 자신들의 전자책이 북큐브, 한국이퍼브, 교보문고 등을 통해 B2BC로 판매가 되고 있다는건 알거예요. 아직 모르셨다면 지금이 알아야 하는 때입니다.

지금까지는 SKT가 매출이 가장 높았고, KT와 LG는 활성화되지 못했습니다. 하지만 이통 3사가 공동으로 서비스 하는 플랫폼이라면 시너지가 클 것이라 생각됩니다.