[펌글] 출판인의 역할은 이북을 위한 좋은 API를 제공하는 것이다

출판인의 역할은 이북을 위한 좋은 API를 제공하는 것이다

등록일 : 2013년 04월 04일 | 조회수 : 1,551

제공 : 한빛 네트워크
저자 : Hugh McGuire
역자 : 조현석
원문 : A Publisher’s Job Is to Provide a Good API for Books 

색인부터 시작하자 

서론 

여기에 생뚱맞은 말이 있다 : 출판인의 역할은 그들의 책을 위한 좋은 API(Application Programming Interfaces)를 제공하는 것이다. 현대에는 거의 모든 책이 전자제품 안에 들어간다(이북이라고 부른다). 미래의 좋은 출판인은 좋은 API를 제공하는 사람일 것이다. 이 글에서 나는 다음과 같은 내용을 설명하겠다.

• 왜 내가 출판인은 좋은 API를 제공해야 한다고 하는가. 
  
  
• 왜 이것이 당신이 생각하는 것보다 훨씬 쉽고 덜 무서운 일인가. 
  
  
• 왜 구닥다리 책 색인(index)이 책 API를 위한 좋은 시작점인가.

API란 무엇인가? 

API는 특정 조건에서 서로 다른 소프트웨어가 서로 소통하는 도구/규약이다. 테리 존스의 정의에 따르면 "UI가 사람에게 정보를 제공하듯이 API가 프로그램에게 정보를 제공한다." 당신이 이용해봤을 만한 API는 다음과 같다.

• 페이스북 "좋아요"를 누를 때 당신은 API를 사용해 보았을 것이다. 
  
  
• 트위터 앱이나 데스크톱용 어플을 사용해 보았다면 당신은 트위터 API를 사용한다. 
  
  
• 페이팔을 사용해서 결제를 해봤다면 API를 이용한다. 
  
  
• 지도를 보여주는 앱을 사용해봤다면 API를 이용한다.

API를 이해하는 다른 방법은 API는 특정 상황에서 한 서비스가 다른 서비스의 데이터를 사용하게 한다. 

이게 책이랑 무슨 상관인가? 

이게 책이랑 도대체 무슨 상관인가? 책은 영감을 준다. 책은 아이디어를 갖고 있고 전달해준다. 하지만 책은 또한 "데이터"를 갖고 있다. 책은(당신이 동의할지 모르지만) 데이터로 만들어진다. 폰으로 찍은 사진, Netflix를 통한 영화, 아이팟으로 듣는 mp3 등 이것들은 기술을 통해 이루어진다. 책, 특히 이북은 역시 데이터로 이루어졌다. 1과 0으로 (하지만 역시 HTML로) 이루어졌다. 

"데이터로서의 책"을 생각하기 시작하면 전통적인 출판인의 역할은 API를 제공하는 것과 비슷하다. 출판인의 일은 사람(독자) 혹은 다른 서비스(서점, 도서관)에서 책(데이터)에 언제 어떻게 접근할지 관리하는 것이다. 

우리는 이 일이 실제 매장에서만 책이 팔리는 과거 세상에서 어떻게 보일지 알고 있고 EPUB와 킨들이 존재하는 이 세상에서도 이해하고 있다고 확신한다. 

하지만 우리가 디지털 세상("우리 책을 서점에 보내주세요"라고 말하는 전통적인 방법에서 훨씬 발전한 이 시대에)으로 이동하고 있으니, 출판인은 그들의 디지털 API에 대해 최대한 빨리 생각하기 시작해야 한다.(걱정 마라! 이제부터 그 방법이 나오고, 무서운 것이 아니다) 

출판인이 하는 일은? 

역사적인 출판인에 대한 정의는 다음과 같다.

출판인 : (명사) 1. 15세기 중반 공중에 발표하는 사람, 2. 책, 정기간행물, 기타 출판업을 하는 사람 (출처:the Online Etymology Dictionary)

출판인의 일은 작가가 쓴 글을 보통 돈을 벌기 위해서 "대중에 공개" 하는 것이다. 

디지털이 출판인이 일하는 환경을 엄청나게 바꿨다는 것은 비밀이 아니다. 실제 매장은 사라지고 있고 온라인 서점의 매출은 늘어나고 출판의 장벽은 (특히 이북은) 없어졌다. 책을 파는 물리적 공간이 줄어들고 책이 홍수처럼 쏟아지는 이 시대에 "대중에 공개" 하는 일은 달라지고 있다. 

출판인이 독자에게 책을 공개하고 파는(즉, 제작, 유통, 판매)하는 전통적인 방법은 점점 대중화되고 작가 스스로 할 수 있다. 

만약 자가출판인이 출판인이 하던 일의 대부분을 할 수 있다면 대중에 글을 공개하는 새롭고 더 나은 방법을 찾는다면 미래에 좋은 출판인, 작가가 같이 일하고 싶은 출판인이 될 것이다. 

출판인이 갖고 있는 누구도 갖고 있지 않은 장점은 (심지어 아마존도 갖고 있지 않은) 자신의 책 내용에 대한 주의 깊고 문맥적인 지식이다. 출판인은 그들의 책을 기획하고 편집하고 교열하고 교정(어쩌면)하고 디자인 했다. 그들은 첫 장부터 끝장까지 안다. 

이 지식은 출판인이 그들의 책에 관한 관심, 집중을 가능하게 한다. 문제는 출판인이 책에 관한 모든 지식을 갖고 있다고 하더라도 그들의 지식을 공유하는 방법이나 그들의 지식을 대중에 널리 알리 좋은 도구 관한 지식은 부족하다. 

하지만 그것들을 배우기는 쉬울 것이다. 

출판인이 친숙한 지식은 "정확히" 무엇일까? 

책은 여러 가지로 설명할 수 있다: 표지, 저자 이름, 제목, 목차, 책 설명. 이것은 "메타데이터" 혹은 "도서관 도서 목록에 적는 것" . 

책안에는 단어와 문장, 어쩌면 약간의 사진이 들어 있다. 단어와 문장을 자세히 살펴보면 이런 것들로 구성되어 있다.

• 사람(실존인물 또는 가상인물) 
  
  
• 장소(실제 혹은 상상) 
  
  
• 시간/날짜

그리고 추상적인 것들

• 개념 
  
  
• 참고문헌 
  
  
• 사람, 책, 기사, 영화, 책, 기사, 영화, 음악인용 
  
  
• 예제

이 목록에 어떤 책을 만드느냐에 따라 다른 것들도 추가 할 수 있다. 

만약 API 대신 색인을 만든다면? 

위 목록에서 본 것처럼 특별히 논픽션이나 교과서를 만든다면 이 말에 동의 할 것이다. "그래 그게 우리가 색인에 넣는 것들이야". 

맞다. 색인은 "책에 있는 무언가가 어디 있는지 찾을 수 있게 하는 지도" 같은 거다. 전통적인 책의 색인은 사람이 책에 내용을 찾을 수 있는 좋은 도구이다. 사람이 읽을 수 있는 색인을 컴퓨터가 읽을 수 있는 색인으로 바꾸는 것을 어렵지 않다. 컴퓨터가 읽을 수 있게 색인을 만들면 거의 API가 되었다. (이것이 검색엔진이 동작하는 방법이다. 모든 웹사이트에 있는 단어에 대한 색인을 만들고 사람과 다른 프로그램에게 검색을 할 수 있는 API를 제공한다.) 

종이책의 경우 색인을 만드는 방법은 중요하다고 생각하는 것(사람, 장소, 날짜, 참고자료, 개념)의 목록을 만들고 몇 페이지에 있는지 적는 것이 일반적이다. 이 리스트를 참고문헌과 함께 부록에 인쇄할 것이다. 

이북의 경우 (좋은) 색인은 약간 다르다. 사람, 장소, 개념 등을 나열하고 책에서 나타난 곳을 링크할 것이다(페이지 번호는 이북에서 아무런 의미가 없다). 

그래서 이북에서는 (결국에는 이북은 HTML 파일의 꾸러미니까, 약간의 다른 것도 있지만) 색인은 그 단어가 나온 본문을 링크하는 HTML 파일의 앵커 태그이다. 

이런 글이 있다고 하자

어쩌고저쩌고 존 스미스 어쩌고저쩌고

그리고 색인에서 링크하기 위해 HTML 마크업을 만들었다.

어쩌고저쩌고 <a id="index-entry-000134">존 스미스</a> 어쩌고저쩌고

그리고 이북의 끝에 책 본문을 링크하는 각각의 항목에 대한 색인이 만든다.

<a href="chapter4/#index-entry-000134">스미스, 존</a>

이 색인페이지/HTML파일은 특정 단어가 어디에 나타나는지 나타내는 링크의 목록이다. 

시맨틱(의미가 있는) 데이터를 추가하고 흔들면 API가 생긴다 ― 최소한 나만의 API를 만들 지도가 생긴다 

색인 파일에 링크를 만드는 대신 더 많은 데이터를 추가하는 노력을 조금만 한다면 이런 것도 할 수 있다. 존 스미스를 사람의 이름으로 정의했다.

어쩌고저쩌고 < id="index-entry-000134" alt="Smith, John" class="person">존 스미스</a> 어쩌고저쩌고

장소에도 마찬가지로 태그할 수 있다.

어쩌고저쩌고 <a id="index-entry-000139" alt="Montreal" class="place">몬트리올</a> 어쩌고저쩌고

나중에 개념에 대해서도 다음과 같이 할 수 있다.

어쩌고저쩌고 <a id="index-entry-000157" alt="existentialism" class="concept">실존주의</a> 어쩌고저쩌고

만약 더 멋지게 하려면 schema.org 나 마이크로포멧 같은 정의된 스키마(형태)의 시맨틱 태킹을 할 수 있다. 이것은 "이 책에 있는 모든 것"에 대해 말할 때 표준화 할 수 있다. 

이제 만드는 모든 책에 적용하기로 마음먹었다면(혹은 사장님이 하게 허락해 주셨다면) 

가) 색인을 만든다(어쨌든 할 것이었지만). 

하지만 더 재미있게 

나) 똑똑한 색인을 만든다. 

그냥 존 스미스가 어디 있는지 알려주는 게 아니라

• 모든 사람이 등장하는 곳 
  
  
• 존 이라는 사람의 모든 사건이 일어나는 곳 
  
  
• 스미스라는 사람의 모든 사건이 일어나는 곳 
  
  
• "사랑하는 스미스 할머니"는 사람이고 "맛있는 스미스 할머니"는 사과라는 사실

그리고 (조금 만드는 데 노력이 들긴 하지만)그냥 색인 대신 완벽한 의미 지도 

그래서 

이런 의미지도는 강력한 API의 시작이다. 의미지도를 갖는 또 다른 의미는 책이 살아 있다는 것이다.(인증 장벽 안이든 밖이든) 의미 지도/API를 모두가 이용 가능하게 만들 수 있다.(무료로 혹은 상업적 계약에 의해) 그리고 말한다. "나의 신나는 책으로 신나는 것을 찾아보세요!" 

사람들은 책 API에서 무엇을 원할까?

• 책의 등장인물에 대한 목록과 그들의 간단한 신상정보 
  
  
• 책에 나오는 장소에 대한 목록, 지도가 있었으면 좋겠다. 
  
  
• 실존주의 근처에 있는 500단어 
  
  
• 책 스토리 진행 중에 다른 시간에 나오는 다른 인물들에 대한 타임라인 
  
  
• 타임라인과 연관된 지도 
  
  
• 책을 인물, 장소, 시간, 개념을 기준으로 읽기(책을 앞에서 뒤로 읽는 게 아니라)

아마도 의미지도를 인터넷에도 올리고 싶을 거다. 그러면 구글이나 다른 검색엔진도 너의 책을 잘 이해할 테니까. 그리고 119페이지에 나오는 특정 정보를 찾고 싶은 사람에게 검색엔진이 찾아 줄 테니까. 

그 외에도 다른 것도 많다. 이건 단지 기본이다. 그런데도 이미 사람들은 만들기 시작했다.

• Small Demons는 API를 통해서 인물/장소/물건 정보를 뽑아냈다. 그들은 출판사에 EPUB 파일을 요청했고 거기서 그 정보를 얻었다. 
  
  
• Dracula Dissected는 드라큘라 소설에서 인물과 시간, 장소를 기중으로 다르게 책을 읽는 방법을 만들었다. 
  
  
• Pearson's FT Press API는 EPUB에서 여러 가지 정보를 뽑을 수 있게 해준다. 
  
  
• wordnik.com 은 Simon과 Schuster 책의 정의 문장을 추출해서 사전 형태의 항목으로 보여준다.

지금은 초기이고 이것들은 초기의 예제들이다. 

이제 더 많은 것들이 나올 것이다. 

출판인의 일은 "대중에게 공개"하는 것이고 API는 어떻게 데이터가 대중에 공개 될 것인가에 관한 것이기 때문이다. 

책에 대한 API를 만드는 것은 쉽기 때문이다. 

무슨 일이 생길까? 

PressBooks 같은 웹기반의 책 만드는 도구는 이러한 의미기반의 색인을 만드는 것을 쉽게 해 놨다. 이런 색인도구는 자동으로 의미 기반의 색인을 만들어 주거나 수동으로 할 수도 있다. 하지만 가장 효율적인 건 둘 다 하는 것이다. 색인에 들어가 단어를 고르고 적절한 메타데이터를 넣는다(사람인가? 장소인가?). 그리고 다음을 누른다. 물론 좋은 색인을 만들고 좋은 메타데이터를 넣고 좋은 스키마를 만드는 것은 어렵다. 

이제 이북 완전 정복 

API와 함께 네트워크화 된 이북을 만들기 시작해야 한다. 

그렇게 만드는 건 어렵지 않다. 이런 최신식의 색인을 만드는 것의 핵심은 결국 구식의 색인이다.

http://www.hanb.co.kr/network/view.html?bi_id=1875