공학석사학위논문

스마트 단말기용 앱북 제작을 위한

게임엔진 기반의 모듈 설계

Modularization of Game Engine Based

Animation Functions for Book Apps

for Smart Devices.

2013년 2월

서울시립대학교 산업대학원

제어계측공학과

남 중 구

스마트 단말기용 앱북 제작을 위한

게임엔진 기반의 모듈 설계

Modularization of Game Engine Based

Animation Functions for Book Apps

for Smart Devices.

지도교수 : 김용철

이 논문을 공학석사학위 청구논문으로 제출함

2012년 12월

서울시립대학교 산업대학원

제어계측공학과

남 중 구

남중구의 공학석사 학위논문을 인준함

심사위원장 최 기 상 ㊞

심사위원 이 준 화 ㊞

지도교수 김 용 철 ㊞

2012년 12월

서울시립대학교 산업대학원

국문 초록

스마트 단말기용 앱북 제작을 위한

게임엔진 기반의 모듈 설계

Modularization of Game Engine Based Animation Functions

for Book Apps for Smart Devices.

남 중 구

서울시립대학교 산업대학원

제어계측공학과

지도 : 김용철 교수

스마트 단말기의 사용이 확대됨에 따라, 단순한 멀티미디어 형태의 전자책 단계를 넘어서,

사용자와 상호작용하는 기능이 있는 앱북의 사용이 보편화 되고 있다. 앱북에는 상호작용을 위한

애니메이션이 필수적인 요소이며, 고성능의 애니메이션은 게임엔진을 이용하여 구현하는 것이 효

과적인데, 게임엔진을 이용할 수 있는 전문 프로그래머들은 인건비가 높다.

본 연구는 향후 앱북 표준 제안에 필요한 기반 연구로써, 연구의 목적은 사용자 상호 작용

이 많은 앱북의 기능 분석을 통해 자주 등장하는 애니메이션을 모듈화된 형태로 제공하고 이를 효

율적으로 사용하는 방법을 제안하는 것이다. 각각의 애니메이션들은 하나의 기호로 표현되며, 여러

기호들은 목록화한 스토리보드 작성용 기호표로 구성한다. 스토리보드 작성자와 개발자는 이 기호

들을 함께 사용하면서 앱북을 개발할 수 있다. 프로그래밍 난이도가 높고 기호화가 가능한 애니메

이션 블록들을 이와 같이 모듈화 함으로써 효율적인 협업이 이루어지고, 코드의 재사용성이 향상되

며, 비숙련 개발자도 앱북 프로그래밍 작업이 가능하게 되어 앱북의 개발 비용을 낮출 수 있다.

이와 같이 프로그래밍 난이도가 높고 기호화가 가능한 애니메이션 블록들을 모듈화 함으

로써 프로그래밍 비용을 낮추고 동시에 스토리보드 작성과 프로그래밍 작업의 협업성을 증대시켜

앱북의 개발 비용을 낮추는데 기여한다.

주요어 : 전자책, 게임엔진, 앱북

공학석사학위논문

스마트 단말기용 앱북 제작을 위한

게임엔진 기반의 모듈 설계

Modularization of Game Engine Based

Animation Functions for Book Apps

for Smart Devices.

2013년 2월

서울시립대학교 산업대학원

제어계측공학과

남 중 구

목 차

제 1장 서론! 1

제 1절 앱북 개발에서의 게임엔진 사용! 1

제 2절 모듈화의 필요성! 3

제 2장 앱북 관련 기술의 현황과 문제점 및 대안! 5

제 1절 국내 ·외 앱북 개발 현황! 5

제 2절 앱북 저작 도구를 이용한 개발의 한계! 6

제 3절 앱북에서 애니메이션 구현시 문제점! 8

제 4절 게임엔진 사용의 장점! 10

제 5절 게임엔진을 사용하는 앱북개발에서 모듈화의 필요성! 11

제 3장 앱북의 구성과 개발 과정! 13

제 1절 앱북 개발에 필요한 인력의 구성! 13

제 2절 앱북의 구성! 14

제 3절 앱북 개발 과정의 단계! 15

제 4장 앱북의 개발 단계와 모듈간의 관계! 20

제 1절 애니메이션을 구현할 모듈의 도출과정! 20

제 2 절 스토리보드에서 사용되는 기호와 모듈! 25

i

...................................................................................

.....................................

...........................................................

.......................

.................................................

............................

...............................

...................................................

.......

..................................................

.....................................

.................................................................

..................................................

................................

...........................

..........................

제 3절 모듈화가 가능한 기능! 26

제 5장 모듈 적용시 장점 분석! 36

제 1절 앱북 제작 과정상의 장점! 36

제 2절 프로그래밍 과정상의 장점! 40

제 3절 코드의 단순화 및 미리 제공되는 코드! 42

제 4절 보조 수단의 제공! 44

제 6 장 결 론! 49

참고 문헌! 50

부 록! 52

Abstract! 60

ii

...................................................

....................................................

...............................................

.............................................

............................

..........................................................

................................................................................

......................................................................................

............................................................................................

....................................................................................

그림 차례

2-1 : 앱북 저작도구의 기능 리스트........................................................................................7

3-1 : 스토리보드 작성용 기호표...........................................................................................14

3-2 : 원화 이미지와 실제 제작용으로 작성된 이미지 예...................................................16

3-3 : 스토리보드 작성 예.......................................................................................................17

4-1 : 설정창 예........................................................................................................................26

4-2 : 북마크 기능 예...............................................................................................................27

4-3 : 페이지 자동 넘기기 설정창 예.....................................................................................28

4-4 : 스프링 효과 예...............................................................................................................28

4-5 : 중력센서와 물리 엔진 이용.........................................................................................29

4-6 : 곡선을 따라 이미지 이동..............................................................................................30

4-7 : 화면 전환 효과 예..........................................................................................................30

4-8 : 이미지 전환 효과 예......................................................................................................31

4-9 : 곡선따라 회전하며 이동 하는 예................................................................................32

4-10 : 관절 효과 예.................................................................................................................32

4-11 : 화면확대와 화면회전을 동시에 적용한 예...............................................................33

4-12 : 화면보다 큰 이미지를 보여줄 때 자동 스크롤 예....................................................34

4-13 : 팝업북 효과 예.............................................................................................................34

5-1 : 기호와 앱북 프로그래밍 작업과의 관계.....................................................................37

5-2 : 앱북 프로그래밍을 하기 위한 산출물.........................................................................38

5-3 : 모듈 적용 과정...............................................................................................................39

5-4 : 모듈화된 함수의 사용 정도 검색.................................................................................42

iii

5-5 : 모듈을 통해 프로그래밍 하는 예.................................................................................43

5-6 : 좌표값을 구하기 위한 보조 화면을 호출하는 예.......................................................44

5-7 : 사용자가 터치로 이동 지점을 지정해 주는 예...........................................................45

5-8 : 터치한 지점의 좌표값을 가지고 있는 파일................................................................46

5-9 : 자동으로 생성된 파일을 프로젝트에 추가.................................................................46

5-10 : 곡선을 따라 회전하며 이동을 구현하는 코드..........................................................47

5-11 : 곡선을 따라 회전하며 이동을 구현한 예..................................................................48

iv

표 차례

2-1 앱북 구현 방법 별 장단점 분석.........................................................................................9

2-2 앱북 개발회사 및 판매가격.............................................................................................12

3-1 애니메이션 효과를 위해 분리된 이미지들....................................................................18

4-1 방귀쟁이 며느리의 애니메이션 기능.............................................................................21

4-2 Peter Rabbit의 애니메이션 기능.....................................................................................22

4-3 방귀쟁이 며느리와 Peter Rabbit간 기능 비교................................................................23

4-4 저작도구 모글루의 애니메이션 기능과 필요한 기능 리스트간 비교.........................24

v

제 1장 서론

제 1절 앱북 개발에서의 게임엔진 사용

종이책이 주류를 이루던 종래의 출판물 시장의 흐름이 태블릿 PC나 북리더기의 보

급으로 인하여 빠르게 전자책으로 바뀌어 가고 있다. 이에 종이책을 단순히 표준 이펍

(ePub) 형태의 전자책으로 변환할 수 있다 [13]. 또한, 근래에는 스마트폰이나 태블릿 PC 등

의 스마트 모바일 기기용으로 사용자 상호 작용이나 애니메이션 등의 멀티미디어 기능이

다수 포함된 전자책 출판도 증가하는 추세이다. 전자책은 단순한 텍스트 기반 정보의 디지

털화된 콘텐츠만을 의미하는 것도 아니고, 전자책 구현을 위한 소프트웨어 및 하드웨어 시

스템으로만 인식되어서도 안 된다. 전자책 안에는 텍스트 기반의 콘텐츠에 멀티미디어 요

소를 구현하는 기술 및 소프트웨어 플랫폼, 그리고 이 모두를 패키징 하는 하드웨어 시스

템이 융합되어 종이책의 물리적 한계를 뛰어넘는 새로운 창작 콘텐츠를 전달하는 매체의

역할을 담당하게 되었기 때문이다. 이에 더해, 라디오, 텔레비전, 신문 등 기존 매체의 디지

털화, 매체간의 융·복합 (convergence), 유무선 브로드밴드 보급의 확산 등에 힘입어 디지털

미디어는 콘텐츠를 전달할 수 있는 새로운 방법론으로 부상하고 있다. 다양한 멀티미디어

콘텐츠 구현기술과 쌍방향성이 확대된 콘텐츠가 전자책에 포함되면서 전자책은 새로운

미디어로 거듭나고 있다[10].

일반적으로 업계에서 정의하는 스마트폰은 기존의 전통적인 휴대전화기의 기능에

서 볼 수 있는 음성, 문자 전송 기능 등 보다 향상된 성능과 다양한 기능을 제공하는 제품으

로 분류한다. 좀 더 기술적으로 접근하여 어플리케이션을 구현하는 플랫폼의 관점에서 보

면 스마트폰이란 Open OS(Operating System)를 사용 하여 단말 제조사뿐만 아니라 이동통

신사, 써드 파티(3rd party) 업체 에서 누구나 쉽게 단말기에 새로운 Application 프로그램 을

제공할 수 있도록 만들어진 단말을 말한다[6]. 또한 사용자들이 고성능의 스마트폰 등 모바

- 1 -

일 기기를 이용하여 전자책을 접하게 되면서 표준을 준수하는 이펍 형태의 전자책으로는

표현이 어렵겠지만 상호작용이 많은 멀티미디어 위주의 앱북에 대한 관심도 많아졌다. 또

한, 스마트 폰 가운데에서도 GPU가 탑재된 고성능의 단말기가 출시되면서, 저성능의 CPU

에서는 실시간으로 렌더링 될 수 없던 효과들이 GPU를 이용하여 실시간으로 렌더링이 가

능하게 되었고, 이런 고성능 모바일 기기의 등장으로 인해 고화질의 모바일 3D 게임과 같

은 높은 품질의 콘텐츠에 대한 관심과 수요가 증가되었다[11].

“앱북”이라 함은 기존의 이펍에 비해 강화 된 인터랙티브 기능이 탑재된 멀티미디

어 콘텐츠를 가진 어플리케이션을 일컫는 말로 “application book”의 약어 표현이다[4]. 영

어 표현으로는 “book application”을 줄여서 “book app”이라고 표기한다.

전자책 저작 도구(Authoring Tool)는 두가지이다. 한가지는 이펍 전자책 표준을 준

수하는 HTML 기반의 이펍 저작 도구이고 다른 하나는 앱북 저작도구이다. 현재는 전자책

을 빠르고 쉽게 출판하기 위한 표준 이펍 저작 도구가 많이 보급되어 있다. 이러한 저작도

구들 중에는 동영상이나 이미지의 삽입 등과 같은 단순한 멀티미디어 삽입 기능을 제공하

는 것들이 대부분이다. 이러한 단순한 HTML 기반의 이펍 저작 도구는 사용자와 상호 작용

이 많은 전자책 개발에는 적당하지 않고, 이 중에 기능이 제한적이기는 하나 앱북 저작도

구를 통해 사용자 상호작용이 많은 앱북을 개발 할 수 있다. 예를들면, 유아용 전자책과 같

이 사용자 상호작용을 많이 포함하는 전자책의 경우 HTML4.1 기술을 가지고 이펍2 표준

으로 전자책을 개발하기에는 한계가 있다. HTML5를 기반한 이펍3 표준을 이용할 경우 사

용자와 상호 작용이 많은 다중 멀티미디어 기능을 구현할 수 있다. 그러나, 프로그래머가

HTML5기술을 이용해 사용자와 상호작용이 많은 전자책 전체를 코딩하는 것은 복잡하고

작업양도 많으며 더욱이 성능 또한 보장되지 않는다. 따라서, 이러한 웹 기술 기반의 디바

이스 API를 이용한 어플리케이션을 개발하려면 하루 빨리 디바이스 API의 표준화가 이루

어져야 할 것이며 다양한 HTML 표현방식에 대한 브라우저 벤더업체들 간의 협의도 진행

- 2 -

되어야 할것이며, 향후 이에 관한 다양한 연구가 필요할 것으로 보인다[8]. 그래서, 근래에

는 오브젝티브 C(Objective C) 또는 자바(Java)등의 언어와 라이브러리를 이용하여 전자책

을 이펍이 아닌 네이티브 앱(Native App) 형태의 앱북으로 구현하기도 한다.

앱북 개발에서 코드의 양을 줄이고 성능을 향상시키기 위한 대안으로 애니메이션

기능을 쉽게 구현할 수 있는 게임엔진을 이용하여 전자책 어플리케이션을 만들기도 한다.

뿐만 아니라 모바일 러닝(M-Learning) 교육 콘텐츠들을 개발 하기 위해서도 OpenGL ES를

기반으로 하는 게임엔진의 사용이 필요하다[2].

게임엔진은 게임을 제작하기 위해 제공되는 각종 API 집합이라고 정의할 수 있다.

일반적으로 게임엔진은 게임 하나만을 위해 사용되고 폐기되는 것이 아니라 게임 제작에

자주 이용되는 것들을 소프트웨어 라이브러리 또는 모듈 형태로 구현해 놓은 것을 말한다

[1]. HTML과 이펍 기술을 이용한 전통적인 전자책이나 게임엔진을 이용한 대부분의 앱북

은 코드의 재사용성을 고려하여 코딩된 것이 아니기 때문에 비슷한 기능의 앱북을 다시 만

들더라도 재사용될 수 없고, 다시 처음부터 코딩을 해야 하는 문제가 발생한다.

제 2절 모듈화의 필요성

일반적으로 게임엔진을 사용하여 개발한다는 것은 인건비가 비교적 비싼 전문 게

임 개발 인력이 투여됨을 의미 한다. 따라서, 전자책 출판의 단가를 올리는 원인이 된다. 본

연구는 이와 같은 전자책 출판 현황과 문제점들을 분석하고 사용자 상호작용이 많은 앱북

개발 비용과 기간을 줄일 수 있는 대안을 제시한다. 이러한 대안으로 앱북 제작에 사용되

는 빈도가 높고 개발 난이도가 높은 사용자 상호작용을 위한 애니메이션 및 게임 기능, 멀

티미디어 효과 등을 분석하여 목록으로 정리하고 이를 모듈화함으로써 게임엔진에 대한

경험이 부족한 일반 프로그래머도 모듈화된 함수를 사용하여 게임엔진을 사용하는 앱북

- 3 -

개발에 참여할 수 있게 함으로써 개발 비용을 절감하기 위해서라도 모듈화가 필요하다. 또

한 이러한 모듈을 이용하여 앱북을 개발 한다면 앱북 개발 효율성을 높여 개발 비용과 기

간을 줄일 수 있다. 이는 게임엔진을 사용하는 앱북의 대량 생산을 가능하게 해준다. 즉, 게

임엔진 사용이 익숙하지 않은 프로그래머에게 게임엔진을 이용하는 앱북 개발을 시키기

위해서는 앱북 개발에 특화된 모듈이 필요하다. 이렇게 개발된 모듈은 스토리보드

(Storyboard)의 작성 등 앱북의 제작 단계에 자연스럽게 적용되어 앱북 출판에 따른 시간과

비용을 많이 줄여줄 것으로 기대된다.

- 4 -

제 2장 앱북 관련 기술의 현황과 문제점 및 대안

제 1절 국내·외 앱북 개발 현황

전자출판 콘텐츠의 경우, 다양한 콘텐츠 유형과 용도에 따라 각 환경에 특화된 형

식의 콘텐츠가 등장하고 있다. 특히 전자책 환경에 특화되어 멀티미디어 요소가 포함된 콘

텐츠가 등장하고 있으며, 이러한 콘텐츠에는 음성, 동영상, 음악 등의 콘텐츠와, 중력센서,

터치 등의 미디어 매체의 진화 와 함께 융합되어 전자책의 장점을 극대화하려는 움직임이

일어나고 있다.

유아용 도서나 특정 장르의 도서, 예를 들어 공포소설을 읽을 때 무서운 음향효과

나 배경음악을 사용하거나, 여행도서 등에서 해당 여행지의 동영상 및 동적 콘텐츠 요소

및 증강 현실과 연계 된 기능을 포함하는 등 전자책으로서 기능을 극대화하려는 종합적이

고 다양한 움직임이 진행되고 있다고 할 수 있다[3]. 이러한 이유로 근래에 스마트 폰이나

스마트 패드와 같은 스마트 기기의 사용률 급증을 들 수 있는데 스마트 기기에서 사용되는

앱을 판매하는 시장도 스마트 기기 사용률과 함께 증가하고 있고 판매되는 전자책 중 상당

수가 이펍 형태가 아닌 앱북의 형태를 취하고 있기 때문이다. 즉, 스마트 기기용 앱이 판매

되는 시장을 통한 현금 유입이 앱북을 개발하는 투자로 이어져 앱북의 형태도 다양화되고

앱북 시장이 활성화 되는데 기여하고 있다.

전자책 개발은 크게 두가지로 나뉜다. 하나는 이펍 표준을 따르는 전자책 출판이고

다른 하나는 앱북이다. 앱북 개발 방법도 크게 두가지로 나뉜다. 하나는 스마트 기기를 작

동 시키는 운영 시스템 자체의 그래픽 라이브러리를 사용하여 개발하는 방법이고 다른 하

나는 OpenGL (Open Graphics Library, 오픈지엘)을 사용하여 개발하는 방법으로 근래에는

고성능 스마트기기 사용자의 급격한 증가와 다중 플랫폼 지원을 위해 OpenGL을 사용하여

앱북을 개발하는 사례도 많이 늘어나고 있다.

- 5 -

앱북 제작에서 시스템 자체의 그래픽 라이브러리를 사용하면 개발인력을 구하기

도 용이하고 숙련도가 높지 않은 개발자로도 개발이 가능하나 다른 OS에 포팅하기 어렵고

복잡한 애니메이션을 구현할때 부드러운 영상을 구현하기 힘들다는 단점이 있다.

제 2절 앱북 저작 도구를 이용한 개발의 한계

저작도구를 통해 앱북을 개발할 때 두가지 문제점이 발생한다. 첫 번째 문제는 저

작도구가 개발 편의성을 위해 개발되다 보니 결과물의 기능에 제한이 따른다. 높은 개발

편의성이라 함은 프로그래밍 없이 저작도구에서 멀티미디어 요소를을 드래그하고 이에

애니메이션 속성을 결정하는 방식으로 앱북을 개발하게 함으로써 프로그래밍을 할 줄 몰

라도 앱북을 개발할 수 있게 하는 것을 뜻한다. Figure 2-1은 비교적 인지도가 높은 모글루

(Moglue)1라고 하는 앱북 저작도구의 전체 애니메이션 기능 리스트이다. 앱북에서 흔히 볼

수 있는 팝업북 효과나 스프링 효과 등도 없으며, 이를 사용자가 추가할 수 있는 플러그인

기능 조차 없다. 동영상, 무빙 GIF , 스프라이트 이미지 삽입을 통해 애니메이션 기능 등을

지원하기는 하지만 제한된 애니메이션 기능으로 인해 저작도구로 제작된 앱북의 결과물

의 질에는 한계가 있다. 두번째 문제는 저작 도구가 윈도우 및 맥용 OS등을 지원하고 제작

된 앱북 또한 iOS와 안드로이드 OS등 여러 OS를 지원하는 등 저작도구와 저작물이 여러

OS를 지원해야 하는 문제로 인해 애니메이션 기능이 한정 될 수 밖에 없는 문제점들이 있

다. 이러한 두 가지 문제점들로 인해 저작도구를 통해 제작된 앱북은 기능이 한정적일 수

밖에 없다. 또한, 앱북 저작 도구가 지원하는 애니메이션만 추가해야 하는 한계까지 갖게

된다. 따라서, 종래의 앱북 저작 도구들이 갖는 한계를 벗어나 구현하고자 하는 기능을 충

분히 구현하기 위해서는 저작 도구가 아닌 프로그래밍을 통한 개발 방법이 필요하다. 이러

- 6 -

1 http://moglue.com

한 저작도구 애니메이션의 기능적 한계에 대한 더 자세한 비교 분석은 4장 1절에서 다룬

다.

Figure 2-1 앱북 저작도구의 기능 리스트

- 7 -

제 3절 앱북에서 애니메이션 구현시 문제점

저작도구가 아닌 프로그래밍을 통해 앱북 개발시 스프라이트 이미지 전환 방식을

이용하여 애니메이션 기능을 구현하는 시스템 자체의 그래픽 라이브러리를 이용하기 보

다는 OpenGL을 사용하여 개발할 경우 해당 애니메이션이 GPU를 통해 동작하기 때문에

복잡한 애니메이션을 구현할때도 부드러운 영상을 구현할 수 있다. 그러나, OpenGL을 통

해 개발할 경우 3D 프로그래밍에 관한 기본 지식을 습득하고 있어야 하고, C언어나 C++와

같은 한정된 언어를 사용해야 하는 제한이 따르며, 수많은 OpenGL 라이브러리 명세를 학

습해야 하는 등의 어려움이 있다. 따라서, 앱북 개발을 위해 OpenGL에 직접 접근해 앱북을

개발하는 인력을 구하는데 한계가 있다. 시스템 자체의 그래픽 라이브러리를 사용하는 앱

북 개발자를 양성하는 것에 비해 OpenGL 개발자를 양성하는 시간 또한 많이 소요됨으로

OpenGL에 직접 접근해 앱북을 개발하는 것은 특수한 경우를 제외하고는 그다지 효과적인

방법도 아니며 앱북의 대량 생산하고도 거리가 멀다. 따라서, 대부분의 경우 앱북 개발시

에 범용 혹은 업체별로 직접 개발한 게임엔진을 사용하여 OpenGL을 구현하는 앱북을 개

발하거나 기능이 제한적이기는 하나 앱북 저작 도구를 이용해 앱북을 개발한다.

표 2-1에서는 앱북의 개발 방법에 따른 장점과 단점을 비교해 놓은 표이다. 즉, 시스

템 자체의 그래픽 라이브러리를 사용하면 만족할 만한 품질의 앱북을 개발하는데 제한이

따른다. OpenGL에 직접 접근해서 개발할 경우 시스템 자체의 그래픽 라이브러리를 이용

하는 것에 비해 개발인력을 구하는 것이 힘들고 개발 비용이 비싸다는 문제점 때문에 대부

분 게임엔진을 이용하여 앱북을 개발한다. 그러나, 주로 게임엔진을 사용하는 개발자는 게

임 개발자이며 앱북에 특화된 게임엔진 개발인력도 구하기 힘들며 인건비 또한 시스템 자

체의 그래픽 라이브러리를 이용한 앱북 개발자 보다 높다. 이러한 상황들로 인해 앱북의

개발 비용이 저렴하지 않기 때문에 이러한 개발 비용 문제가 대량생산 및 시장 활성화를

- 8 -

저해하는 요인으로 작용한다. 이것 또한 앱북의 애니메이션 기능을 개발할 때 발생하는 문

제점이다.

표 2-1 : 앱북 구현 방법 별 장단점 분석

구현 방법 장점 단점 개발 난이도

시스템 자체의 그래픽 라이브러리

게임엔진 이용

OpenGL 직접 접근해서 개발

OpenGL을 사용하

지 않아 제작이 비

교적 쉽고 간편함.

여러 플랫폼을 지원

해야 할 경우 OS별

로 포팅하거나 다시

개발해야 함.

비교적 쉬움

내부적으로

OpenGL을 사용함

으로 성능면에서

우수하며 부드러운

애니메이션 기능을

구현할 수 있음.

인건비가 비싼 게임

프로그래머를 통해

개발되기 때문에 개

발 비용이 상승.

보통

OpenGL의 대부분

의 기능을 사용가

능하여 제한이 없

이 개발 가능.

개발인력을 구하기

힘들고, 개발 단가가

비싸서 특수한 목적

에서만 제한적으로

사용.

어려움

- 9 -

제 4절 게임엔진 사용의 장점

게임엔진을 사용하며 얻는 이익은 두 가지 측면에서 접근 가능하다. 먼저, 시스템

의 그래픽 라이브러리를 쓰는 것에 비해 얻을 수 있는 이익은 여러 플랫폼으로의 호환이

가능하다는 것과 내부적으로 OpenGL을 사용하는 라이브러리를 쓰는 게임엔진을 사용하

면 성능까지 향상되어 좀 더 부드러운 애니메이션 효과를 사용할 수 있다는 장점이 있다.

OpenGL에 직접 접근해 개발하는 것에 비해 게임엔진을 통해 앱북을 개발할 경우

얻어질 수 있는 장점은 개발시간을 단축할 수 있고, 개발인력을 구하기 쉽다는 장점과 이

미 만들어진 라이브러리를 통해 좀 더 효과적으로 애니메이션 효과를 구현할 수 있는 장점

들도 있다.

시스템 자체의 그래픽 라이브러리를 사용하면 대부분 CPU가 메모리에 저장된 이

미지를 순식간에 교체하는 스프라이트 (sprite) 방식으로 구현되며 복잡한 애니메이션을 구

현할 경우 애니메이션 자체가 느려지는 현상이 발생한다. 반면, 본 연구를 통해 제작된 모

듈에서 사용되는 게임엔진 또한 내부적으로는 OpenGL ES을 통해 구현된다. GPU를 통해

애니메이션을 구현하면 추가적인 프로세서 영역을 사용해 속도가 빨라진다는 장점 외에

구현상의 차이 때문에 애니메이션 자체가 느려지는 현상이 발생하지 않는다. 구현상의 차

이라 함은 OpenGL을 통해 애니메이션을 구현할 때 스프라이트 방식이 아닌 OpenGL이 구

현되는 가상 공간 내부의 모델들이 움직이고 특정 프레임마다 이미지를 화면에 출력하는

방식을 택하므로 애니애메이션 자체가 느려지는 현상이 발생활 확률은 적어진다.

앱북 개발에 사용되는 대부분의 게임엔진들은 물리엔진을 추가로 장착해서 사용

할 수 있으며 스마트 OS를 장착한 장비들은 대부분 중력센서를 갖추고 있다. 이런한 물리

엔진과 중력 센서를 적절히 응용하면 사용자의 흥미를 끌 수 있는 앱북의 기능을 손쉽게

만들 수 있다. 예를 들면, 앱북이 설치된 스마트 OS 장비를 흔들거나 기울임으로써 이에 따

- 10 -

라 화면에 보여지는 이미지들을 이리 저리 움직이게도 할 수 있고, 물리엔진상에 구현되는

강체(rigid body)들을 관절처럼 연결하여 장비의 기울임이나 흔들림에 따라 이미지들을 실

제 그네처럼 흔들리게 하는 기능들도 별다른 수학이나 물리학 지식 없이 프로그래밍 할 수

있다.

즉, 앱북을 만들때 게임엔진을 사용하면 구현상의 차이로 인해 만족할 만한 성능으

로 앱북을 구현할 수 있으며, 게임엔진을 적용하기 쉬워지는 등 시스템 자체의 그래픽 라

이브러리를 이용하는 앱북에 비해 유리한 점이 많아 진다. 또한, 게임엔진이 앱북에서 구

현해야할 애니메이션 효과들의 상당 부분을 API형태로 제공하는 경우가 많기 때문에 프로

그래밍해야할 부분이 줄어든다는 추가적인 장점도 있다.

제 5절 게임엔진을 사용하는 앱북개발에서 모듈화의 필요성

스마트 모바일 기기 사용자들이 급증함에 따라 앱북에 대한 요구는 점점 더 강해질

것이다. 특히 동화책이나 만화책 같이 이미지가 많은 책들은 더욱 더 앱북 형태 로 제작될

가능성이 크다. 하지만 앱북 개발을 위한 전용 저작 도가가 없는 현재의 HTML5 나 게임엔

진을 이용한 앱북 제작은 시스템 자체의 그래픽 라이브러리를 통해 개발하는 것에 비해 개

발 기간이 길고 비용이 많이 든다. 그래서 앱북의 가격이 높아지고, 앱북 시장 확대에 걸림

돌로 작용한다. 이에 본 연구에서 제안하는 게임엔진을 이용한 모듈은 향후 앱북 시장에

꼭 필요한 기반 모듈이다.

현재 앱북 제작에 대한 표준도 없거니와 공용모듈을 이용하여 앱북을 개발한 회사

또한 없다. 표 2-2는 앱북 개발회사 별 앱북 판매 가격을 표시한 예이다. 이들 회사 역시 개

발에서 사용된 모듈을 공개하거나 판매하고 있지 않다.

- 11 -

표 2-2 : 앱북 개발회사 및 판매가격

회사명 제품명 판매가격(달러)Loud Crow Interactive Inc. PopOut! The Tale of Peter Rabbit $4.99

(주)웅진씽크빅 방귀쟁이 며느리, 콩쥐팥쥐 $3.99

(주)엔씨소프트 누굴 닮았나 $2.99

(주)한글과 컴퓨터 구름빵 $5.99

Disney Inc. 토이 스토리 $5.99

본 논문에서 애니메이션 기능에 대한 모듈화는 객체 랩퍼(wrapper) 기술 중 계층화

(Layering)와 재공학(Reengineering)방법 등을 사용하여 진행 한다[5, 12]. 일반적인 게임 엔

진의 유지 보수에서는 게임엔진에 대한 재공학적인 측면으로 접근하는 객체 랩퍼기술을

응용한다. 그러나, 본 연구에서는 앱북에서 자주 사용되는 코드들로 객체 랩퍼 기술의 계

층화된 모듈을 작성 제작하고자 한다. 이를 앱북의 제작단계와 연동하여 앱북 제작의 효율

성을 향상시키는 방법을 제시 할 것이다. 이런 과정을 통해 앱북 개발의 문제점인 대량 생

산이 힘들다는 문제에 대한 대안을 제시 하고자 한다.

게임엔진을 이용한 앱북을 개발하는 회사가 있지만, 이것은 단순히 게임엔진을 이

용한 것일 뿐이지 게임엔진을 사용하는 앱북 전용 함수들을 모듈화하여 공유 혹은 판매 하

는 경우는 아직 없다. 현재로서는 게임엔진을 이용하는 앱북 개발을 위한 모듈에 대한 연

구나 정의 조차 없으며, 이러한 모듈의 공개 버전이나 시장 판매 또한 현재로써는 알려진

바가 없다. 따라서, 앱북의 대량 생산 및 일반화를 위해서는 일반 프로그래머를 앱북 개발

에 참여 시킬 수 있어야 하고, 그러기 위해서는 앱북 개발시 사용하기 쉬운 모듈이 필요하

다.

- 12 -

제 3장 앱북의 구성과 개발 과정

제 1절 앱북 개발에 필요한 인력의 구성

일반적으로 멀티미디어가 많이 포함되어 있고 사용자 상호작용이 많은 앱북의 개

발에는 최소 다섯가지 분야의 전문가가 필요하다. 첫번째는 스토리보드(Storyboard) 작성

과 개발 스케줄 및 인력배치를 담당하는 기획자가 필요하며, 두번째는 원화작가 및 그래픽

디자이너 등 실제 이미지를 제작하고 편집하는 인력이 필요하며, 세번째는 프로그래밍을

담당하는 프로그래머가 필요하며, 네번째는 시나리오 작가가 필요하며, 다섯번째는 사운

드관련 리소스를 제공하는 음원 제작 혹은 음원 구매를 담당하는 음향 담당자가 필요하다.

그 외에도 다국어 지원을 위해 번역가나 완벽한 품질을 위해 추가 QA(Quality assurance)인

력도 필요하다. 문제는 이들이 유기적으로 개발에 참여 하기 위해서는 각종 기능에 대한

명세 및 기능에 대한 한계를 이해해야 함은 물론이고 제작 단계를 숙지하고 있어야 각 구

성원들이 참여할 부분에 대한 작업이 별다른 충돌없이 원할히 이루어 진다. 특히 스토리보

드를 제작하는 기획자와 실제 앱북을 코딩하는 프로그래머는 제작 중 사용될 프로그래밍

모듈에 대해 Figure 3-1와 같이 미리 지정하고 시작하지 않으면 개발 기간을 예측하지 못하

거나 기획과 결과물간의 차이가 발생해 결과물의 질이 떨어질 수 있으므로, 기획자와 프로

그래머간의 앱북 개발에서 사용될 모듈에 대한 협의가 필요하다. Figure3-1에서 회전이나

이동 같이 구현이 쉬워서 굳이 모듈화할 필요 없는 것을 제외하고는 곡선따라 이동, 곡선

을 따라 회전하며 이동하는 경우 모듈화하면 개발기간을 단축할 수 있고, 기획자가 의도한

개발물을 정확히 구현할 수 있게 된다. 또한 기획자는 각 개발 단계에서 필요한 각 분야별

투여 인력들과 충분한 협의가 필요한데 이것 역시 스토리보드를 기반으로 협의해 앱북의

개발을 진행하게 된다.

- 13 -

Figure 3-1 스토리보드 작성용 기호표

제 2절 앱북의 구성

앱북은 크게 세가지 부분으로 구성된다. 첫번째는 인트로 부분으로 어플리케이션

이 작동할때 시작되며 일반적으로 콘텐츠의 성격 및 대표 이미지들을 애니메이션 형태로

보여준다. 두번째는 설정 부분이며 언어 선택과 볼륨조절 등 각종 설정이 여기서 이루어

지는 부분이다. 이러한 설정은 앱북의 특성에 따라 실행 중간 중간에 설정을 담당하는 기

능을 제공하는 앱북도 있고, 인트로 화면에서 설정기능을 구현하는 앱북도 있다. 세번째는

콘텐츠 부분이다. 콘텐츠는 실제 사용자에게 보여주고 사용자의 상호작용을 이끌어내는

부분이다. 콘텐츠는 수 십 여장의 씬(Scene)으로 이루어져 있다. 시나리오는 콘텐츠 부분을

구현하기 위한 것이다. 즉, 기획자가 각 시나리오를 씬별로 구분해 “Figure 3-3 스토리보드

- 14 -

작성 예”와 같이 표시해 스토리보드(Storyboard)를 작성하고, 프로그래머가 스토리보드를

참고하여 프로그래밍하면 콘텐츠 부분이 완성되는 것이다.

제 3절 앱북 개발 과정의 단계

1. 기획 및 시나리오 제작 단계

앱북 제작의 목적에 따른 예산 및 투여 인력에 대한 구성이 이루어 지며, 기획자와

시나리오 작가가 협력하여 시나리오를 작성하게 된다. 앱북의 시나리오는 영화용 시나리

오나 연극용 시나리오와 대부분 같다. 그러나, 사용자의 액션이라는 요소가 추가됨에 따라

크게 두 가지 측면에서 차이를 보인다.

첫째는 플롯의 흐름에 분기가 있을 수 있다. 시나리오는 앱북 구현시 사용자의 선

택에 따라 다른 플롯으로 스토리를 전개할 수 있으며 시나리오 작가는 사용자가 선택 후

구현될 플롯에 따른 시나리오를 각각 작성해야 한다.

둘째는 사용자의 액션을 감안해 시나리오를 작성해야 한다. 예를 들면 유저가 특정

액션을 취했을 경우 각각의 캐릭터가 특정한 대사를 표현할 수도 있으며, 표현해야할 대사

대신 동영상이나 애니메이션으로 표현될 수도 있다. 이러한 대사나 동영상 역시 시나리오

에 표현 되어야 한다.

시나리오 제작 단계를 개발 초기에 시작 해야 하는 이유는 플롯이 복잡해지면 개발

예산이 올라가는 등 기획과 밀접한 관련이 있는 만큼 기획단계에서 시나리오가 필요하다.

또 다른 이유는 대부분의 경우 시나리오를 기반으로 원화 이미지 작성시 사용될 각종 캐릭

터의 원화 이미지 컨셉이 결정되며 시나리오를 기반으로 스토리보드(Storyboard)가 작성되

기 때문에 시나리오 제작 단계가 기획과 함께 개발 초기에 시작되어야 한다.

- 15 -

2. 원화 이미지 작성 단계

시나리오에 맞게 각각의 등장인물의 특성을 잘 표현할 수 있도록 이미지를 작성한

다. 이때 아나로그로 제작된 저작물의 경우 이미지 스캐닝 및 이미지 보정을 통해 디지털

형태로 전환된다. Figure 3-2의 왼쪽 그림은 아날로그 형태의 저작물로써 회의 및 추가적인

구상을 통해 Figure 3-2의 오른쪽 그림과 같은 최종 디지털 형태의 저작물로 완성된 예이

다.

Figure 3-2 원화 이미지와 실제 제작용으로 작성된 이미지 예

3.스토리보드(Storyboard) 제작 단계

일명 콘티(Conti)작성이라고도 하는 이 제작 단계는 사용자와 앱북간의 상호 작용

및 애니메이션 효과등을 “Figure 3-1 스토리보드 작성용 기호표”를 이용해 표시하고 해당

효과에 대한 부가적인 설명도 표기한다. 자막 및 자막의 위치도 스토리보드 제작단계에 포

함된다. 또한 부가적인 동영상,배경음악, 음향효과 등 각종 멀티미디어의 출력에 대하여

기술한다. 이를 기반으로 디자이너 및 프로그레머가 세부적인 디자인 및 프로그래밍을 시

작 하게 된다. 스토리 보드의 제작 단계는 앱북 제작 단계의 핵심단계로써 시나리오의 분

- 16 -

량 확인 및 적합성 여부를 판단하여 시나리오 작가에게 수정요청을 할 수 있으며, 원화 이

미지가 화면에 차지하는 크기와 배경색과의 일치도를 가늠해 봄으로써 원화 이미지를 수

정하거나 개선할 피드백을 만들어 내기도 한다.

Figure 3-3 스토리보드 작성 예

4.이미지 분리 작업 단계

프로그래밍 작업을 하기전 애니메이션 효과를 위해 따로 움직이는 이미지들은 표

3-1처럼 모두 분리되어야 하고 이 분리된 이미지들은 충돌 방지를 위해 <Scene번호>+<이

- 17 -

미지 이름>+<확장자>형태의 파일명으로 저장되게 된다. 예를 들면 “Figure 3-3 스토리보드

작성 예”에 나오는 고양이가 숨겨진 발톱을 꺼내고 있다면 발 부분과 발톱 부분을 각각 다

른 이미지로 분리해 저장하게 된다.

표 3-1 : 애니메이션 효과를 위해 분리된 이미지들

이미지 Thumb Nail 파일명

scn11_cat_head.png

scn11_cat_leg.png

scn11_cat_nail_A.png

scn11_cat_nail_B.png

5. 프로그래밍 단계

Figure 3-3 스토리 보드와 Figure 3-1의 분리된 이미지를 통해 어플리케이션 제작에

들어간다. 이때 “Figure 3-1 스토리보드 작성용 기호표”에 해당하는 모듈을 미리 가지고 있

지 않다면 프로그래머의 자질 및 실력에 따라 결과물의 질과 개발 기간이 많이 달라지며,

추가 개발비용 또한 발생할 수 있다. 이는 개발 자체에 큰 위험요소이며, 이는 사용자 상호

- 18 -

작용과 애니메이션 효과를 지정하는 사람과 실제 구현하는 사람이 달라서 발생하는 문제

이다. 실제 모듈이 적용 전 사례와 적용된 사례는 본 논문의 부록 A를 통해 확인할 수 있다.

6. QA(Quality Assurance)단계

실제 장비에서 실행하여 대사 및 자막의 오탈자 검증, 스토리보드(Storyboard)에서

지시한 내용의 구현 여부, 안정성 테스트 등 스토어(혹은 마켓)에 업로드 하기 전 각종 기능

을 테스트 하며 버그를 최소화한다. 그리고, 기능 수정이 이루어 질때 각각의 애니메이션

들을 모듈화하지 않았다면 일일이 해당 코드를 찾아 다니며 수정해야 하지만 모듈화가 이

루어져 있다면 해당 모듈에 대한 코드만 수정하면 되기 때문에 QA시간을 많이 줄일 수 있

게 된다.

7. 스토어에 등록 및 프로모션 단계

판매 및 배포를 위해 각 스마트 기기의 해당 앱 스토어에 등록하게 된다. 이때 가격

을 결정하며 판매를 위한 프로모션도 같이 이루어 진다. 또한 소비자의 의견도 취합되어

QA 과정상에서 발견하지 못한 버그나 기능개선에 대한 의견도 패치를 통해 적용된다. 이

때 얼마나 빨리 소비자의 요구에 맞춰 버그를 수정하고 기능개선 패치를 적용하느냐가 프

로모션의 성패를 좌우하기도 한다.

- 19 -

제 4장 앱북의 개발 단계와 모듈간의 관계

제 1절 애니메이션을 구현할 모듈의 도출과정

인지도가 높은 두개의 앱북을 선택해서 해당 앱북의 애니메이션 기능들을 분석하

였다. 하나는 ‘woongjin thinkbig’1이라는 회사가 만든 ‘방귀쟁이 며느리’2라는 국내에서 제

작된 앱북이고 다른 하나는 ‘Loud Crow Interactive Inc.’3에서 개발한 ‘PopOut! Peter Rabbit’4

이라는 인지도 높은 앱북이다.

표 4-1은 “방귀쟁이 며느리” 구현시 필요한 기능들을 페이지별 동작 횟수로 정리한

표이다. 표 4-1에서는 화면 전환 효과나 북마크 기능을 제외하였고 이를 제외하더라도 씬

당 평균 10개 이상의 기능들이 포함되어 있는 것을 알 수 있다. 표4-1의 합계 부분을 보면

사용자의 입력부분에 대한 처리를 제외하고 이동, 회전, 이미지 전환 기능이 중점적으로

사용된 것을 알 수 있다. 표에서 사용자의 입력에 따라 여러번 구현되는 애니메이션 기능

에 대해서는 n이라고 표시했다. 앱북 저작도구 모글루로는 프로그램적 요소에 해당하는 n

에 해당하는 기능을 구현할 수 없다. 표 4-1을 보면 팝업북 효과라든지 관절효과 등 저작 도

구 모글루를 통해 구현하기 불가능한 기능들이 다수 포함되어 있는 것을 알 수 있다.

- 20 -

1 http://www.wjthinkbig.com

2 https://itunes.apple.com/kr/app/bang-gwijaeng-i-myeoneuli/id492211663?mt=8

3 http://www.loudcrow.com

4 https://itunes.apple.com/us/app/popout!-tale-peter-rabbit/id397864713?mt=8

표 4-1 방귀쟁이 며느리의 애니메이션 기능크기 변경

자동 스크롤

곡선 따라 이동

팝업북 효과

이미지 전환

중력센서적용

관절 효과

회전

이동

입력

합계

인트로

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15앤딩

합계

6 1 1 6 14

4 1 5 10

n 1 n 1 2 4+n 8+n*3

2 4 5 11

2 2 4 2 8 1 19

1 5 5 4 15

2 1 3

1 4 2 4 11

8 1 3 12

6 1 3 10

1 1 4 3 4 13

4 4 3 1 5 17

3 4 5 12

2 n n 2 2 2+n 8+n*3

2 n n 1 3 6+n*2

2 n n n 2 1 5+n*3

4 4

2+n 1 2 6 34 0+n*4 4+n*3 41+n 28 60+n*2 178+n*11

표4-2는 ‘PopOut! Peter Rabbit’의 구현시 필요한 기능들을 씬별 동작 횟수로

정리한 표이다. ‘PopOut! Peter Rabbit’은 스프링 기능으로 유명한 앱북으로 앱북에 등장하

는 거의 대부분의 캐릭터들에 스프링효과가 적용되어 있다. 곡선을 따라 회전하며 이동하

는 기능이 더 들어가 있으며 팝업북 효과는 구현되어 있지 않다. ‘PopOut! Peter Rabbit’은

씬당 평균 15회 이상의 기능들이 포함되어 있는 것을 알 수 있다.

- 21 -

표4-2 Peter Rabbit의 애니메이션 기능Zoom

-Out·In

곡선을 따라 회전하며 이동

이미지 전환

스프링 효과

중력센서적용

관절 효과

회전

이동

입력

합계

인트로표지2~34~56~78~9

10~1112~1314~1516~1718~1920~2122~2324~2526~2728~2930~3132~3334~3536~3738~3940~4142~4344~4546~4748~4950~5152~53앤딩합계

2 5 7 1411 11 225 n 1 6+n 12+n*24 2 1 2 9 185 1 1 2 9 181 2 2 2 7 147 n 7+n*2 14+n*3

2 1 3 62 2 2 2 8 162 2 4 8

1 7 12 20 401 2 1 2 6 12

2 2 4 83 n 3+n 3+n*2

1 5 1 1 8 165 6 11 22

4 5 2 11 221 5 6 12

4 7 4 15 301 2 3 6 12

1 3 1 5 105 1 1 7 142 n 3 5+n 10+n*2

2 5 1 8 167 2 2 9 202 2 4 85 4 9 186 2 1 9 1810 11 21

2 15 2 122 2+n*4 19 8 59 228+n*5 457+n*9

- 22 -

표4-3은 표4-1과 표4-2의 합계값을 비교하여 만든 ‘방귀쟁이 며느리’와 ‘PopOut!

Peter Rabbit’간 기능을 비교해 놓은 표이다. 표의 1행에 기능중 13개의 기능 중 6개의 기능

은 두 개의 앱에서 동시에 사용되고 있음을 알 수 있다. 두 개의 앱을 합쳐서 총 650여개(n

을 1이라고 했을때)의 기능이 구현되었음을 알 수 있으며, 씬당 평균 14.2개 정도의 기능이

구현되었음을 알 수 있다. 이는 전체 기능을 모듈화할 경우 씬 하나당 평균 14.2개 정도의

모듈을 호출한다는 것을 의미한다. 또한 이는 전체 13개의 기능을 모듈화할 경우 최소 650

번의 모듈 호출이 일어난다는 것을 의미하는데 만약 위 두 개의 앱을 13개의 모듈로 구현

할 경우 함수 한 개당 평균 50.38번 정도 호출됨을 알 수 있다. 따라서, 앱 하나에서 함수 한

개 당 평균 호출 횟수는 25.38번으로 모듈화 효율이 높다고 보여진다.

표 4-3 : 방귀쟁이 며느리와 Peter Rabbit간 기능 비교Zoom-Out·In

객체의 크기 변경

자동 스크롤

곡선 따라 이동

곡선을 따라 회전하며 이동

팝업북 효과

이미지 전환

스프링효과

중력센서적용

관절 효과

회전이동

입력

합계

방귀쟁이 며느리 0 2+n 1 2 0 6 34 0 0+n*4 4+n*3 41+n 28 60+n*2 178+n*11

Peter Rabbit 2 0 0 0 15 0 2 122 2+n*4 19 8 59 228+n*5 457+n*9

합계 2 2+n 1 2 15 6 36 122 2+n*8 23+n*3 49+n 87 288+n*7 635+n*20공통으로 사용된 기능

X X X X X X O X O O O O O 6/13

저작도구 모글루의 애니메이션 기능(Figure 2-2에 표현된 기능)과 ‘PopOut! Peter

Rabbit’,‘방귀쟁이 며느리’앱북을 개발할 때 필요한 기능 리스트(표4-3의 1행)를 비교하여

표4-4를 작성하였다. 표 4-4의 1열 기능이 2열 모글루 기능보다 많은 것을 알 수 있다. 이는

- 23 -

저작도구 모글루를 이용해서는 ‘PopOut! Peter Rabbit’과 ‘방귀쟁이 며느리’를 만들지 못한

다는 것을 의미하며 이는 저작도구의 한계이며 저작도구가 아닌 프로그래밍을 통해 앱북

을 개발해야 하는 이유이기도 하다.

표 4-4 : 저작도구 모글루의 애니메이션 기능과 필요한 기능 리스트간 비교

앱북 분석을 통해 구한 기능 모글루 기능 비고

Zoom-Out·In Scale 배경을 포함해 모든 이미지의 크기(Scale) 변경으로 구현

객체의 크기 변경 하며 이동

Scale

자동 스크롤 Move 배경을 포함해 모든 이미지를 이동(Move)해서 구현

곡선 따라 이동 Jump 곡선 따라 이동의 일부 기능임

곡선을 따라 회전 N/A

팝업북 효과 N/A

이미지 전환 Fade

회전 Waddle,Rotate Waddle기능은 Rotate와 같은 기능이나 회전의 중식점이 이미지의 아래임.

이동 Move

터치·드래그 Drag 모글루에서 터치는 속성으로 지원함.

스프링 효과 N/A

중력센서적용 Float

관절 효과 Swing

- 24 -

제 2 절 스토리보드에서 사용되는 기호와 모듈

제 3장에서 설명한 앱북의 제작 단계에서 앱북 개발에 가장 많은 영향을 미치는 단

계는 스토리 보드 제작 단계와 프로그래밍 단계이다. 두 단계의 핵심에는 스토리보드 제작

용 기호가 있다. 이유는 스토리보드 제작용 기호를 통해 스토리 보드가 작성되고 프로그래

머는 스토리보드에 표시된 기호를 통해 해당 애니메이션을 구현한다. 또한 이미지 분리작

업 단계에서 그래픽 디자이너가 스토리보드에 표시된 기호를 통해 이미지 분리 작업을 하

거나 추가로 필요한 이미지들을 제작하게 된다. 뿐만 아니라 스토리보드 제작용 기호들은

애니메이션 기능등을 위해 적용해야 할 모듈을 의미한다. 즉, 기획자가 특정 기호를 스토

리보드에 입력했다면 개발자는 해당 기호에 해당하는 모듈을 미리 만들어 두었다가 이를

적용해 프로그래밍 한다. 이러한 기호는 제1절의 표4-3에 1행의 앱북 기능 리스트를 기반

으로 Figure 3-1과 같은 스토리보드 작성용 기호표를 만들 수 있고 이를 기반으로 Figure 3-3

의 스토리보드 작성 예와 같은 스토리보드를 작성할수 있다.

스토리보드 작성시 앱북에서 구현될 애니메이션들을 기호로 정리하고 정리한 기

호를 스토리보드에 표기하는 방식으로 스토리보드를 작성하면 크게 세 가지의 장점이 있

다. 첫째는 스토리보드를 제작하는 사람 입장에서 말로 표현하는 것보다 쉽게 애니메이션

기능을 표기할 수 있고, 검토할 때 역시 빠르게 애니메이션 효과들을 이해할 수 있어 좀 더

좋은 품질의 스토리보드를 작성할 수 있다. 두번째는 앱북 개발에 참여하는 인력들이 자신

이 맡은 부분에 대한 분량을 파악하고 의견을 제시하고 협의 및 수정해 나갈 수 있는데 도

움을 준다. 이는 참여한 인력들의 전문 분야가 다름으로 인한 용어 차이로 인해 생기는 의

사소통의 문제를 어느 정도 해소해 준다. 세번째는 프로그래머 입장에서의 장점이다. 구현

해야할 기능의 명세를 명확히 함으로써 모듈화할 대상을 구분하기 쉬워지고, 이로 인한 작

업 분량 및 작업 소요 시간에 대한 예측이 가능해 진다. 게다가, 기호를 통해 중요 기능들이

- 25 -

이슈화 됨으로써 세부적인 기능에 대하여 시나리오 작성자와 토의할 수 있어 시나리오에

서 의도된 기능대로 구현될 가능성 또한 높아지게 된다.

제 3절 모듈화가 가능한 기능

1. 설정 창

사용자가 앱북을 실행할 때 Figure 4-1에서 같이 환경 설정 부분이 필요하다. 다국어

를 지원하는 앱북의 경우 언어 설정이 필요하며, 효과음이나 배경음악 등에서 출력되는 음

량을 설정할 수 있어야 하며, 추가적으로 자동으로 페이지를 넘기게 하는 기능이나 남자·

여자 목소리 선택과 같은 나레이션의 목소리 종류 등 앱 실행시 필요한 설정 정보들을 설

정하는 창이 필요하다. 설정 창 자체 기능으로는 평상시 작아져 있다가 사용자 터치에 의

해 커지면서 설정할 수 있는 부분이 서서히 나오는 형태의 설정창을 구현하기도 한다.

Figure 4-1 : 설정창 예

2. 북마크 기능

앱북의 구성요소 중 필수적인 요소는 아니나 사용자 편의를 위해 제공되는 기능으

로 아래 그림과 같이 사용자가 마지막으로 읽던 부분을 표시할 수 있게 해주는 기능이다.

- 26 -

사용자가 앱북 종료 후 다시 시작할 때 북마크로 표시한 지점부터 읽을 수 있는 기능도 같

이 제공되어야 한다. 콘텐츠가 20장 이상의 씬으로 구성되어 있을 경우 유효한 기능이다.

Figure 4-2는 사용자가 앱북의 컨텐츠 부분에서 해당 씬에 북마크 설정을 했을때 현재 씬이

북마크가 설정된 씬이라고 표시해 주는 예를 보여준다.

Figure 4-2 : 북마크 기능 예

3. 소리 내어 읽기 기능 및 페이지 자동 넘기기 설정 옵션

소리 내어 읽기 기능과 페이지 자동 넘기기 기능은 일반적으로 같이 구현되다. 사

용자가 Figure 4-3의 오른쪽 그림에서 자동을 선택하고 소리 내어 읽기 기능에 관한 셋팅이

켜진 상태에서 앱이 실행될 경우, 해당 페이지에 대한 자막이 음성으로 출력되고 씬의 모

든 자막에 해당하는 음성이 출력 되었을 경우 자동으로 다음 페이지를 보여주게 하는 옵션

이다. 이러한 기능은 앱북 뿐만 아니라 TTS기능을 통해 일반적인 이펍뷰어에서도 많이 구

현되는 기능이다.

- 27 -

Figure 4-3 : 페이지 자동 넘기기 설정창 예

4. 스프링 효과

이 기능은 터치나 스와이프시 이미지가 스프링 끝에 매달려 있는 것 처럼 일정 시

간 동안 이미지가 흔들리게 하는 기능으로 유아용 앱북에서 많이 구현되는 기능이다. 또한

구현 방식이나 프로그래머의 능력에 따라 자연스러운 흔들림으로 구현되기도 하고 단순

한 왕복운동으로 구현 되기도 한다.

Figure 4-4 : 스프링 효과 예

- 28 -

5. 중력센서와 물리엔진 이용

이 기능은 중력센서가 달려있는 스마트 기기에서 많이 구현되는 기능으로 앱북이

실행되는 장비를 기울였을때 지정한 객체들이 중력방향으로 움직이게 하는 기능이다. 일

반적으로 물리엔진은 게임엔진에 추가 모듈 형태로 구현되며 유아용 앱북에서 흔히 볼 수

있는 기능이다.

Figure 4-5 : 중력센서와 물리 엔진 이용

6. 곡선으로 이동

앱북에서 표현되는 캐릭터들은 대부분 가만히 있지 않고 사용자의 터치등에 의해

이동되는 경우가 많다. 곡선으로 이동하는 기능은 해당 캐릭터가 이동시 시작지점과 도착

할 지점과 곡선의 궤적등을 미리 지정하여 해당 캐릭터가 직선이 아닌 곡선으로 부드럽게

이동할 수 있게 해주는 기능이다. Figure4-6의 왼쪽 그림은 이미지가 이동하기전 화면이고

Figure4-6의 빨간색 화살표는 이미지가 이동한 경로를 표시한 그림이다.

- 29 -

Figure 4-6 : 곡선을 따라 이미지 이동

7. 화면 전환 효과

화면 전환 효과란 씬(Scene 혹은 페이지)이 이전 혹은 이후로 전환될 때 실행되는

애니메이션 효과를 말한다. 이펍에서는 뷰어앱이 화면 전환 효과를 구현하나 앱북에서는

앱북 자체의 코드에서 구현해야 한다.

Figure 4-7 : 화면 전환 효과 예

- 30 -

8. 이미지 전환 효과

이 기능은 디졸브 방식으로 이미지를 다른 이미지로 부드럽게 전환 해주는 전환 효

과를 말한다. Figure 4-8의 다섯개의 이미지는 왼쪽에서 부터 차례로 시간이 지남에 따라

이미지가 바뀌는 과정을 보여주는 예이다.

Figure 4-8 : 이미지 전환 효과 예

9. 이동 궤적에 맞춰 회전하며 이동

이미지를 이동시킬때 직선 혹은 곡선으로 이동시킬 수 있다. 직선으로 이동시킬 때

는 별다른 문제가 없지만 곡선을 따라 이미지가 이동할때는 이동 궤적에 맞춰 이미지를 회

전시켜 주어야 자연스러운 움직임을 표현할 수 있는 경우가 많다. Figure 4-9에서 처럼 나

무가 둥근 언덕면을 미끄러지듯이 이동한다고 하면 해당 이미지는 언덕면에 수직인 상태

를 유지하며 이동해야 자연스러운 애니메이션 효과를 구현할 수 있다.

- 31 -

Figure 4-9 : 곡선 따라 회전하며 이동 하는 예

10. 관절 효과

관절효과라 함은 일반적으로 물리엔진(Physics Engine)을 통해 구현된다. 게임엔진

에 적용되는 물리엔진은 폴리곤을 단위로 그들의 속성(mass, position, rotation)들을 가지고

있고 폴리곤들의 집합을 통하여 강체(rigid body)를 형성하고 강체의 특성에 따른 폴리곤들

의 연동관계(Joint)를 설정할 수 있도록 설계되어 있다[9]. 물리엔진에서 구현되는 연동관

계를 관절효과라고 부르기로 한다. Figure 4-10은 실제 구현된 관절효과의 예이다.

Figure 4-10 : 관절 효과 예

- 32 -

11. 화면의 확대, 축소,회전

화면의 Zoom-Out(축소)과 Zoon-In(확대)기능 및 회전 기능은 일시에 변화하는 것

이 아니라 애니애메이션 기능의 일환으로 동작된다. 예를 들면 씬 구석에 있는 캐릭터를

강조하기 위해 점차적으로 커져서 화면 전체에 위치하게끔 하는 기능에 Zoom-In기능이 사

용된다.

Figure 4-11 : 화면확대와 화면회전을 동시에 적용한 예

12. 자동 스크롤

자동 스크롤은 화면보다 큰 이미지를 보여줄 때 이미지를 자동으로 스크롤 시켜 전

체 화면을 보여주는 것을 의미한다. 스마트 기기와 같이 화면크기가 작은 장비에서 유용하

다. 앱북에서는 가로·세로 모두 넓은 씬 보다는 가로 혹은 세로만 넓은 씬을 보여줄때 세로

혹은 가로 방향으로만 스크롤시켜 보여주는 방식을 많이 사용한다. Figure 4-12는 실제 앱

북에서 자동 스크롤이 적용된 것을 보여주는 예이다. Figure 4-12의 왼쪽 그림은 자동 스크

롤 적용 전이고 사용자의 특정 액션에 의해 서서히 오른쪽으로 이동해 Figure 4-12의 오른

쪽 그림처럼 보이게 된다.

- 33 -

Figure 4-12 : 화면보다 큰 이미지를 보여줄 때 자동 스크롤 예

13. 팝업북 효과.

3D가 아닌 2D를 사용하는 게임엔진에서 이미지의 가로방향 크기는 그대로 두고 세

로 방향의 높이만 줄어든 이미지를 이미지의 아래 부분의 위치는 바꾸지 않고 세로 방향으

로 줄어 들었던 이미지를 원래 크기로 천천히 바꾸어 주면 Figure 4-13의 왼쪽 그림이 오른

쪽 그림처럼 누웠다가 일어나는 것 처럼 보인다. 이런 효과는 종이로 만들어진 아동용 팝

업북에서 페이지를 넘길때 종이로된 캐릭터들이 일어나면서 튀어나오는데 이런 효과를

앱북에서 구현한 것이다.

Figure 4-13 : 팝업북 효과 예

- 34 -

14. 미니게임

종이책과 달리 프로그래밍적인 요소를 삽입할 수 있는 이펍이나 앱북은 사용자의

흥미 유발을 위해 미니게임을 삽입할 수 있는 특징이 있다. 앱북을 표준 이펍과 비교해 보

면 시스템 그래픽 라이브러리에 직접적인 접근이 가능한 네이티브한 코드를 쓸 수 있다는

장점이 있다. 또한, 게임엔진을 통해 개발된 앱북의 경우 게임엔진 자체에서 제공되는 함

수들을 이용해 시스템의 그래픽 라이브러리를 사용해 만들어진 앱북보다도 미니게임을

삽입하기가 훨씬 더 용이해진다. 앱북에서 사용되는 미니게임들로는 직소 퍼즐, 두더지 게

임, 선 연결하기 게임, 미로 찾기 게임, 순서 맞추기 게임등이 있다.

- 35 -

제 5장 모듈 적용시 장점 분석

제 1절 앱북 제작 과정상의 장점

미리 작성된 시나리오를 기반으로 앱북을 개발하는 것이 아니라면 기획자와 시나

리오 작가가 협력하여 기획서 및 시나리오를 작성하게 된다. 기획자가 완성된 시나리오와

기획서와 기존에 작성된 시나리오 작성용 기호를 토대로 앱북의 스토리보드에 사용될 기

호들을 결정하는 작업을 하게 된다. 여기서 사용될 기호들은 기획자와 모듈 프로그래머가

구현 방법과 가능성을 타진하는 등의 협의을 통해 결정한다. 이때 기호를 결정하는 과정에

서 기호를 모듈화해서 개발한 기존의 프로잭트가 있다면 기획자가 기호들을 결정하는데

참고할 수 있고, 모듈 개발자가 추가로 개발해야하는 모듈을 가늠해 작업량을 결정할 수

있게 되어 이러한 앱북 제작 과정은 작업 간소화 및 분량 예측 가능화 등의 많은 장점을 갖

게된다.

Figure 5-1의 기호와 앱북 프로그래밍 작업과의 관계에서 처럼 기호는 모듈 작성의

기본이 되고, 스토리 보드는 이미지 분리 작업과 앱북 프로그래밍 작업과 음향 파일 생성

과 구매 작업을 하는데 사용된다. 스토리보드에 사용되는 기호가 모듈 개발자와 협의하여

생성된 기호라면 해당 기능을 모듈 개발자가 개발할 수 있는 기능이라는 것을 의미하게 된

다. 그렇기 때문에 이러한 기호를 기반으로 작성된 스토리 보드를 통해 앱북을 개발하게

되면 개발이 지연되거나 실패할 가능성이 적어지는 또 다른 장점도 있다.

기획자가 모듈프로그래머와 협의해 효과음 변조나 대사·지문에 대한 음성파일을

다국어로 지원하는 것에 대한 모듈의 지원 여부를 스토리보드를 통해 표현할 수 있으므로

사운드 전문가가 작업시 작업 범위가 일반화되어 불필요한 작업을 예방 것도 가능하다.

원화작가가 작성한 이미지를 그래픽 디자이너가 디지털화 한 뒤 보정한 이미지로

기획자가 스토리보드를 작성하는데, 이런 모듈과 대응되는 기호를 통해 작성된 스토리보

- 36 -

드는 그래픽 디자이너가 이미지를 분리할 때 분리 대상을 판별하는 기준이 된다. 그래픽

디자이너가 정확한 애니메이션 기능을 이해하고 있지 않으면 앱북 프로그래머가 상당한

어려움을 격게 된다. 따라서 이러한 방식의 개발은 시나리오에 표기된 기호를 통해 애니메

이션 기능을 이해한 그래픽 디자이너가 분리된 이미지를 실수 없이 만들어 앱북 프로그래

머가 분리된 이미지를 다시 분리하는 수고를 덜 수 있다는 장점을 가져다 준다.

음향 파일 생성 및 구매

스토리보드

앱북 프로그래밍이미지 분리

기호

모듈 작성

스토리보드 작성

Figure 5-1 : 기호와 앱북 프로그래밍 작업과의 관계

- 37 -

Figure 5-2의 그림에서 처럼 앱북 프로그램은 모듈과 스토리보드 만으로 진행되는

것이 아니라 그 밖에 분리된 이미지나 각종 음향 파일을 가지고 하는 멀티미디어 프로그래

밍이다.

분리된 이미지 모듈스토리보드

앱북 프로그래밍

효과음

배경음악

대사 음성파일,,,,,

Figure 5-2 : 앱북 프로그래밍을 하기 위한 산출물

Figure 5-3의 모듈 적용 과정은 앱북의 개발과정을 작업 흐름에 따라 도식화하여 표

현한 그림이다. QA작업시에도 모듈을 기반으로한 스토리 보드를 통해 많은 이득을 볼 수

있다. QA작업 중 확인된 버그가 해당 기호를 통해 구현된 기능이라면 해당기호가 사용되

어진 다른 씬을 빠르고 빠짐 없이 테스트 해봄으로써 QA작업을 좀더 꼼꼼하게 진행할 수

있게 된다. 이는, 꼼꼼하게 진행된 QA로 인해 안정성 높은 앱북을 개발하는데 일조 한다.

뿐만아니라 개발자 입장에서 보면 모듈화하지 않았을 경우 QA결과로 버그를 제거할 때

일일이 해당 씬의 소스코드들을 찾아다니며 버그를 제거해야 하나 모듈화하여 개발하게

되면 QA결과에 포함된 기호를 통해 해당 모듈의 버그를 빠르게 찾아 제거함으로써 개발

자는 소스코드를 일일이 찾아다니며 버그를 제거하지 않아도 되는 이익을 누리게 된다.

- 38 -

음향 파일 생성 및 구매

스토어 등록

1차 완성된 앱북

분리된 이미지

모듈

스토리보드

기호원화이미지

기존 개발 모듈

기존 작성 기호

시나리오

QA작업

앱북 프로그래밍

모듈 작성

모듈 및 코드 업그레이드(필요시)

구현 가능여부 및 구현 방법 대한 협의

이미지 분리

원화 이미지 디지털화

원화 스케치 작업

기능 분석

시나리오 작성 기획서 작성

스토어에 등록된 앱북 버전업

버그 및 요구 사항 취합

프로젝트 시작

기획서

개발 범위 및 컨셉에 협의

시나리오, 작가,,

기획자,,,

효과음

배경음악

대사 음성파일,,,,,

모듈 및 코드 업그레이드(필요시)

시나리오 분석

2차 완성된앱북

모듈,, 프로그래머,,

원화,, 작가,

원화,, 작가,

그래픽,, 디자이너

그래픽,, 디자이너

사운드,, 전문가,,

앱북,,, 프로그래머,,

모듈,, 프로그래머,,

모듈,, 프로그래머,,

앱북,,, 프로그래머,,

기획자,,,

버그 및 유저 요구사항

앱북,,, 프로그래머,,

앱북,,, 프로그래머,,

앱북,,, 프로그래머,,

기획자,,,앱북,,,

프로그래머,,

QA결과물

이미지 보정그래픽,, 디자이너

기획자,,,

기호화기획자,,,

스토리보드 작성

기획자,,,

보정된이미지

업그레이드된앱북

블록 설 명시작작업산출물작업자

Figure 5-3 : 모듈 적용 과정

- 39 -

프로모션단계에서도 사용자의 평가는 매출에 지대한 영향을 미치는 경우가 많다.

사용자의 좋은 평가를 유지하는 방법중의 하나가 사용자의 요구 사항 및 버그 지적사항에

대한 발빠른 업그레이드이다. QA작업시와 마찬가지로 기획자가 기호를 기반으로 빠르게

사용자의 요구사항을 개발자에게 전달하고, 개발자는 일일이 코드를 찾아 다니지 않음으

로써 발빠르게 업그레이드를 시행한다면, 사용자의 좋은 평가를 유지할 가능성도 높아지

게 된다.

정리하자면, 기호를 통한 코드의 모듈화, 스토리보드 기반의 멀티미디어 리소스 제

작, 모듈을 통한 앱북 프로그래밍, 기호를 통한 꼼꼼한 QA, 모듈을 통한 빠른 업그레이드

등 이러한 기호를 통한 모듈화는 앱북의 제작 과정에 많은 영향을 미친다.

제 2절 프로그래밍 과정상의 장점

“3장 1절 3. 스토리보드(Storyboard) 제작 단계”에서 구현할 기능과 구현가능한 범

위를 정의하기 위해서는 기획자와 모듈 프로그래머간에 많은 의견 교환이 필요하다. 이는

앱북 시장이 초기 상황이다 보니, 앱북 개발 절차에 대한 표준이나 통상적인 절차가 아직

까지는 제대로 마련되지 않았기 때문에 많은 의견 교환을 통하여 세밀한 부분까지 정의할

필요가 있는 것이다. 그런데, 기획자와 모듈 개발자의 충분한 협의가 부족하여 구현될 기

능에 대한 정의가 제대로 이루어 지지 않으면 구현될 앱북이 기획자의 의도와 달라져 추가

개발이나 재개발이 필요하게 될 가능성이 높아진다.

또한, “3장 1절 5. 프로그래밍 단계” 역시 구현 방식에 있어서 기능에 대한 정의가

제대로 이루어져 있지 않거나 미리 준비된 모듈이 없다면 프로그래머의 개인적 역량이나

취향에 따라 결과물이 다르게 나오며 이는 QA기간의 증가와 개발 비용의 상승으로 이어

진다. 매우 안 좋은 경우에는 처음부터 다시 구현해야 하는 상황까지 발생한다.

- 40 -

“3장 2절 5의 프로그래밍 단계”에서 발생하는 문제들을 해결 하기 위해서 기획자와

모듈 개발자는 각 기능 및 구현 방식을 따르는 기호를 정확하게 정의하고 이 정의에 따라

서 기획자는 스토리보드에 정의된 기호를 적절하게 표시해야 하고 프로그래머는 명시된

기호에 따라 각 기능을 구현해 주어야 한다. 구현 과정에서 프로그래머는 미리 개발된 모

듈이 있다면 이를 적용하며 구현에 따르는 노력과 기간을 단축한다. 이러한 개발 과정을

효과적으로 진행하면 “Figure 3-1 스토리보드 작성용 기호표”에서 제시한 기호를 정의하고

각 기호에 따르는 기능을 모듈화하여 이를 적용하여 프로그래밍 해야 한다.

! 결론적으로, 사용자 상호작용이 많은 어플리케이션 형태의 전자책을 개발하는데

있어서 다음과 같은 작업들이 미리 이루어져 있다면 개발에 따른 비용과 기간을 크게 줄일

수 있고, 좋은 품질의 앱북을 만들 수 있다.

-필요한 기능을 정의

-정의된 기능을 기호화

-기호에 따르는 기능을 프로그래밍한 모듈

앱북을 개발하기 위한 각 담당자들의 입장에서 보면, 기획자는 미리 정의된 기호를

이용함으로써 자신의 기획의도를 간단하고 정확하게 정의할 수 있고, 프로그래머에게 정

확히 전달할 수 있다. 프로그래머는 정의된 기호를 구현할때 기획자의 의도를 정확히 파악

할 수 있다. 또한 프로그래머는 정의된 기호에 따른 모듈을 이용함으로써 개발에 따른 노

력을 줄이고 개발 기간을 단축할 수 있다. 제작자 입장에서는 정의된 기호와 모듈을 이용

함으로써 구현된 결과물이 균등한 품질로 제작될 수 있고, 구현된 앱북의 원가를 낮출 수

있다.

- 41 -

제 3절 코드의 단순화 및 미리 제공되는 코드

부록A는 유저의 터치 영역을 구하는 부분이다. 게임 프로그래머는 아주 쉽게 구현

할 수 있는 코드이다. 다만, 게임엔진에 익숙하지 않은 일반 프로그래머 입장에서는 어려

운 코드이다. Figure 5-4은 얼마나 많은 부분에서 부록A의 코드를 사용하는지 IDE환경을

통해 검색한 결과이다. 17개의 파일에 거처서 72번 사용되었다는 의미인데, 모듈의 정의부

와 구현부에서 사용된 2번씩을 각각 빼면 15개의 파일, 즉, 15개의 씬에서 총 70회 호출 되

었다는 의미이다. 모듈의 함수를 한번 만들어서 70회를 사용했다는 의미이다.

Figure 5-4 : 모듈화된 함수의 사용 정도 검색

코드를 단순화하여 얻어지는 잇점은 많이 있지만 이번 사례를 통해서는 두가지의

잇점이 발견된다. 첫번째는 입력되는 글자수의 감소로 프로그래밍 시간이 단축됨을 들 수

있고, 두번째는 코드가 줄어들어 코드를 해석하기 쉬워지는 장점도 있다.

비디오 게임 제작처럼 앱북에서 자주 사용되는 기능이 있다. 이런 애니메이션 기능

중의 하나가 곡선으로 이미지를 이동시키는 기능이다. 부록B는 이러한 기능을 구현한 소

- 42 -

스코드이다. 부록B에서 처럼 곡선으로 이미지를 이동시켜주는 코드를 모듈화하면 함수 하

나로 아주 간단하게 곡선으로 이미지를 이동시키는 기능이 구현되어 일반 프로그래머들

도 별다른 스킬없이 곡선으로 이미지를 이동시키는 기능을 구현 할 수 있게 된다. 또한 부

록B의 코드는 Figure 3-1의 “곡선 따라 이동”을 구현한 예 이기도 하다. 향후 다른 앱북을

제작할 때 같은 스토리보드 제작용 기호를 사용하여 스토리보드를 제작 한다면 해당 기호

의 사용 여부만 가지고도 부록B의 모듈에 대한 재사용 여부를 쉽게 판단할 수 있게 된다.

Figure 5-5은 모듈을 통해 프로그래밍 하는 과정을 보여주는 예이다. Figure 5-5의 그

림은 함수 이름 중 앞의 몇 글자만 적었을때 자동완성 되어 함수의 파라메터들을 미리 보

여주는 코드 자동완성의 예이며 아래쪽 그림은 탭키를 이동해가며 함수의 파라메터값을

입력해 함수를 호출하는 코드를 완성한 예이다. IDE환경의 코드 자동완성 기능을 사용하

면 Figure 5-5에서 처럼 모듈화된 함수의 앞 몇글자만 외우고 있으면 모듈을 적용하는 것을

쉽고 빠르게 할 수 있다.

Figure 5-5 : 모듈을 통해 프로그래밍 하는 예

다른 앱북 제작시에도 모듈화할 필요가 있는 기능이 있으면 그 기능에 대하여 기호

와 이름을 정하고 기획자가 게임엔진에 익숙한 프로그래머와 상의하여 모듈화 하고 일반

- 43 -

프로그래머가 모듈의 적용부를 프로그래밍하면 인건비를 많이 줄일 수 있다. 이런 방식의

앱북 개발이 일반화 되고 앱북 개발용 모듈이 더욱 발전하면 추가로 만들어야할 모듈의 갯

수가 상당히 줄어들고 대부분의 기능을 게임엔진에 경험이 적은 프로그래머를 통해서도

개발이 가능해질 것이다. 즉, 제대로 구현된 모듈만 있으면 인건비가 비교적 비싼 게임 개

발자가 아니더라도 앱북을 쉽게 개발 할 수 있다는 것이다.

제 4절 보조 수단의 제공

별도의 저작도구가 없는 상태에서는 Figure 4-9의 곡선을 따라 회전하며 이동 하는

예를 구현하려면 이미지가 이동해야 하는 특정 지점들의 좌표값을 프로그래머가 직접 타

이핑해야 한다. 이는 생산성을 저해하는 요소이다. 따라서 이러한 문제를 해결하기 위해서

는 이동해야 하는 특정 지점들을 직접 터치하고 이를 캡쳐해 해당 좌표를 저장해주는 보조

프로그램이 필요하다. 보조프로그램이 없다고 하더라도 해당 좌표값을 구해주는 모듈이

있다면, 굳이 보조 프로그램의 도움을 받지 않아도 된다. 부록 C는 Figure 4-9의 곡선을 따

라 회전하며 이동하는 예를 구현한 코드이며, Figure 5-6는 해당 좌표값을 구하기 위한 보

조 화면을 호출하는 예이다.

Figure 5-6 : 좌표값을 구하기 위한 보조 화면을 호출하는 예

- 44 -

Figure 5-7는 사용자가 터치로 이동 지점을 지정해 주는 예로써 Figure 5-6를 실행하

면 해당 씬이 실행되고 “End”라는 글자가 적혀있는 스크린 화면이 나타나며, 개발자가 화

면을 터치하면 배열을 생성하는 코드를 자동으로 생성한다. 이에 대한 모듈의 실행 코드는

부록 D에서 확인할 수 있다. 부록 D는 부록 C에서 사용될 배열을 생성하는 코드를 자동

생성하는 모듈인 것이다. 부록C가 적용될 씬에서 Figure 5-6 에서 처럼 부록D의 모듈이 호

출 되도록 프로그래밍하고 앱북을 실행해 준다. 그리고, Figure 5-7의 그림에서 처럼 개발

자가 연속해서 이미지가 이동할 부분에 해당하는 화면을 터치해 주고 “End”를 클릭해 주

면, 부록D의 모듈이 생성한 파일을 읽을 수 있게 된다.

Figure 5-7 : 사용자가 터치로 이동 지점을 지정해 주는 예

Figure 5-7의 “End”를 탭하면 Figure 5-8에서 처럼 콘솔창에 터치한 지점의 좌표값을

가지고 있는 파일의 패쓰가 나타나고 이를 복사해서 Figure 5-9에서 처럼 앱북 프로잭트에

추가시킬 수 있다. 이렇게 되면 부록C의 코드는 개발자의 직접적인 좌표 입력이나 보조툴

없이 구현할 수 있게 된다. 좌표만 만들어 주는 범용적인 보조 도구보다 모듈에서 지원하

- 45 -

는 보조 도구가 배경이미지나 실제 등장할 객체들을 연동하여 좌표들을 만들어 줄 수 있

고, 좌표들이 들어있는 배열자체를 리턴하는 코드들을 자동으로 프로그래밍해 주는 기능

을 제공함으로써 모듈에서 지원하는 보조 도구로써의 기능이 범용적인 보조 도구보다 개

발 생선성과 앱북의 질을 향상시키는데 일조한다.

Figure 5-8 : 터치한 지점의 좌표값을 가지고 있는 파일

Figure 5-9 : 자동으로 생성된 파일을 프로젝트에 추가

- 46 -

Figure 5-8의 사각형 부분의 코드는 곡선을 따라 회전하는 코드를 구동 시키는 코드

이다. 앱북 개발자는 터치 몇번과 파일 복사 한번 그리고, 한줄의 코드로 곡선을 따라 회전

하는 코드를 쉽게 구현할 수 있게 된다.

Figure 5-10 : 곡선을 따라 회전하며 이동을 구현하는 코드

Figure 5-11는 Figure 5-10의 코드를 사용하여 구현한 예이다. 내부적으로는 이동 궤

적은 CatmullRoom 알고리즘을 통해 구현되고, 이미지의 회전은 터치한 지점의 이웃값의

기울기를 이용하여 회전을 시켰다. 추가적인 보조선이 없어도 이미지가 이동할 지점에 대

한 좌표값만을 가지고 충분히 부드러운 곡선을 따라 화전하며 이동함을 구현할 수 있다.

- 47 -

Figure 5-11 : 곡선을 따라 회전하며 이동을 구현한 예

모듈은 앱북의 구현 뿐만 아니라 구현에 필요한 데이터를 생성하는 앱북 개발용 보

조툴의 역할도 구현할 수 있으며, 이러한 보조수단으로써 모듈의 역할은 앱북 제작시 별도

의 저작툴이 없는 상황에서 개발 생산성을 향상 시키기 위해 꼭 필요한 기능이다.

- 48 -

제 6 장 결 론

현재 게임엔진을 이용하는 앱북 시장은 형성되는 단계이다. 하지만, 사용자 상호작

용이 많은 앱북을 효과적으로 구현하기 위한 연구가 이루어지지 않고 있다. 따라서 효과적

인 앱북 개발을 위해 작업 단계를 지정하고 많이 쓰는 기능을 스토리보드 제작 단계부터

기호화 하여 기호화된 기능을 위주로 모듈화 할 것을 제안하는 바이다. 이러한 모듈화는

단순히 프로그래밍 작업상의 장점도 있지만 추가적인 이익도 분명히 있다. 이는 영화를 만

들때 여러 전문인력이 필요 하듯이 사용자 상호작용이 많고 멀티미디어가 다수 포함되는

앱북을 개발하는데 있어서도 프로그래머 뿐만 아니라 기획자, 시나리오 작가, 원화 작가,

그래픽 디자이너, 음원관련 전문가 등 여러 전문인력이 필요하고 이러한 인력이 효율적으

로 앱북을 개발하기 위해서는 작업 단계를 미리 지정하고 앱북을 개발하는 것이 필요하다.

스토리보드 작성용 기호표를 통해 스토리보드 제작 단계부터 모듈화를 한다는 전제를 기

반으로 앱북이 개발 된다면 핵심기능에 대하여 기획자와 프로그래머 간의 협의가 용이해

지고, 프로그램 소스들이 효과적으로 모듈화되며 각 작업 단계들이 유기적으로 연계된다.

그러므로 기획 단계에서 개발기간의 예측이 가능하고, 개발 위험 요소도 제거되고, 소프트

웨어의 질이 향상되며, 개발인력의 비용이 감소되며, 개발기간이 단축되는 등 여러 이익이

발생하게 된다.

이러한 개발 방법이 공개되어 이슈화 되고 앱북 제작시 개발 과정과 모듈들이 본

연구에서 제시한 방법대로 발전한다면, 크게 두가지의 이익이 있을 것이다. 첫번째는 작업

단계를 일반화 하고 조직화 함으로써 작업 참여자의 역할 분담이 효과적으로 이루어 질 것

이며, 둘째는 이러한 스토리보드 작성용 기호표를 기반으로 한 모듈화를 통해 코드가 재사

용 되어질 가능성이 높아지고, 개발 시간 또한 줄어들어 게임엔진 기반의 앱북 시장이 활

성화되고 대량생산 시대가 열릴 것을 기대한다.

- 49 -

참고 문헌

[1] 김정훈, 2007, “게임엔진 기술의 최근 동향”, 주간기술동향, 1290호, 정보통신산업진흥

원,서울,1-11쪽

[2] 김태호,김영봉, 2008, ”OpenGL ES 기반의 모바일 3D 입체 학습시스템 설계”, 한국멀티

미디어학회 학술발표 논문집, 2008년도 춘계학술발표논문집, 한국멀티미디어학회, 부

산, 483-486쪽

[3] 남동선, 2011,”전자책 및 전자출판 시장 동향”, 정보과학회지, 제28권 제10호, 한국정보

과학회, 서울, 16-25쪽

[4] 박미희, 2011,”애니메이션 <토이 스토리> 시리즈의 앱북 전환 특성 연구”, 인문콘텐츠,

제25호,인문콘텐츠학회,경기도,175-194쪽

[5] 서봉원, 최은만, 1999, “객체 랩퍼 클래스를 이용한 RPC 프로그램의 재공학 기법”, 정보

과학회논문지, 제26권 제3호, 한국정보과학회, 401-411쪽

[6] 이소현, 오승환, 2012,”비접촉형 콘텐츠로서의 앱북 제안”, 한국디자인학회 학술발표대

회 논문집, 2012.5, 인문콘텐츠학회,경기도,232-233쪽

[7] 제갈병직, 2010, “스마트폰 시장과 모바일OS 동향”, Semiconductor Insight, May-June

2010, 한국반도체산업협회, 서울,9-18족

[8] 조수선,2011,”웹 공통 API를 이용한 스마트폰 전자책 응용”, 한국콘텐츠학회 논문지, 제

11호, 한국콘텐츠학회,대전, 28-33쪽

[9] 최종화, 권기달, 신동규, 신동일, 2003, “물리엔진을 활용한 실감형 게임콘텐츠의 설계

및 제작”, 한국정보과학회 2003년도 가을 학술발표논문집 ,제30권 제2호(Ⅱ), 한국정보

과학회, 670-672쪽

- 50 -

[10] 편집인, 2010,”전자출판산업동향”, 전자출판산업동향, 2010년 8월, 한국전자출판협회,

경기도,3-4쪽

[11] 황규현,박상훈, 2008, “DMGL: OpenGL ES 기반 모바일 3D 렌더링 라이브러리”, 멀티

미디어학회논문지, Vol. 11 No. 8. August 2008, 한국멀티미디어학회, 1160-1168쪽

[12] Gamma, Eric, “Design patterns : elements of reusable object-oriented software”

[13] International Digital Publishing Forum, ePub Specifications, http://www.idpf.org/

[14] Ivar Jacobson, Fredrik Lindström, 1991, “Re-engineering of old systems to an object-

oriented architecture.”, OOPSLA’91, ACM Press, 340-350p

- 51 -

부 록

A.코드의 단순화를 위해 구현된 모듈 ( 단순 랩퍼로써의 역할)

아래 코드는 모듈없이 코드를 구현한 예이다.

// 스프라이트 터치시if(CGRectContainsPoint (CGRectMake (door.position.x - door.anchorPoint.x * door.contentSizeInPixels.width * door.scale, door.position.y - door.anchorPoint.y * door.contentSizeInPixels.height * door.scale, door.contentSizeInPixels.width * door.scale, door.contentSizeInPixels.height* door.scale) ,location) &&allowAction_door){ allowAction_door=NO; [self doorTouched];}

아래 모듈은 복잡한 코드를 간단하게 구현하도록 만들어 놓은 모듈이다.

//CCSprite로 터치 영역 구함 +(CGRect)getTouchAreaBySprite:(CCSprite *)sprite{ CGRect r= CGRectMake( sprite.position.x - sprite.anchorPoint.x * sprite.contentSizeInPixels.width * sprite.scale, sprite.position.y - sprite.anchorPoint.y * sprite.contentSizeInPixels.height * sprite.scale, sprite.contentSizeInPixels.width *sprite.scale, sprite.contentSizeInPixels.height*sprite.scale); return r;}

아래 코드는 위 모듈을 호출하는 예이다.(이탤릭체 부분)

// 스프라이트 터치시// if(CGRectContainsPoint([FinfraCocos getTouchAreaBySprite:door],location) &&allowAction_door){ allowAction_door=NO; [self doorTouched];}

- 52 -

B. 미리 제공되는 코드 : Figure 4-6의 곡선을 따라 이미지 이동 모듈, 사용 빈도가 높은 기

능 구현.

아래 모듈은 복잡한 코드를 간단하게 구현하도록 만들어 놓은 모듈이다.

// +(void)moveFromSprite:(CCSprite *)sprite1 From:(CGPoint)pointA To:(CGPoint)pointB WithImageName:(NSString*)imgName TempSprite:(CCSprite *)sprite2 Delegate:(id<FinfraCocosMoveFromSpriteProtocol>)target UpHeight:(float)upHeight Duration:(float)duration{ CCMoveTo * action1; CCMoveTo * action2; ccBezierConfig bezier; [sprite2 setVisible:YES]; bezier.controlPoint_1 = ccp(0, 0+upHeight); bezier.controlPoint_2 = ccp(pointB.x-pointA.x, pointB.y-pointA.y+upHeight); bezier.endPosition =ccp(pointB.x-pointA.x, pointB.y-pointA.y); id toMove1 = [CCBezierBy actionWithDuration:duration bezier:bezier]; id toMove2 = [toMove1 copy]; action1 = [CCSpawn actions: [CCFadeOut actionWithDuration:duration], toMove1, nil]; [sprite1 runAction:[CCSequence actions: action1, [CCCallFunc actionWithTarget:target selector:@selector(moveFromSpriteEnd)], nil] ]; action2 = [CCSpawn actions: [CCFadeIn actionWithDuration:duration], toMove2, nil]; [sprite2 setTexture:[[CCTextureCache sharedTextureCache] addImage:imgName]]; [sprite2 runAction:[CCSequence actions: [CCMoveTo actionWithDuration:0 position:pointA], action2, nil] ];}

- 53 -

해당 애니메이션을 구현하기 위해 앱북 프로그래머가 구현해야할 코드

[FinfraCocos moveFromSprite:_kong From:congpOrg To:congp WithImageName:congi TempSprite:_kongTmp Delegate:self UpHeight:200 Duration:1];

C. 부록 D(보조 수단)의 결과를 이용해 구현됨 : Figure 4-9을 구현하는 곡선을 따라 회전하

며 이동 하기를 구현하는 예

// +(CCSpawn *)spawnWithSprite:img1 Path:(CCPointArray*)pa{ NSMutableArray *ra=[NSMutableArray arrayWithCapacity:10]; for (int i=1; i<pa.count; i++) { float x1=0,x2=0,y1=0,y2=0; CGPoint bp = [pa getControlPointAtIndex:i-1]; CGPoint np = [pa getControlPointAtIndex:i+(i==pa.count-1?0:1)]; x1+=bp.x; y1+=bp.y; x2+=np.x; y2+=np.y; float dy = y2-y1; float dx = x2-x1; float angle; if ( dx>0 ) angle = - atanf(dy/dx); else if( dx<0 ) angle = M_PI - atanf(dy/dx); else if( dx==0 && dy>0) angle = - M_PI/2; else if( dx==0 && dy<0) angle = M_PI/2; angle= CC_RADIANS_TO_DEGREES(angle); [ra addObject:[CCRotateTo actionWithDuration:1 angle:angle]]; } CCAction *act = [CCCatmullRomTo actionWithDuration:5 points:pa tension:.01]; CCAction *act2 = [CCSequence actionWithArray:ra ]; CCSpawn *sp = [CCSpawn actions:(CCFiniteTimeAction *)act, act2,nil]; return sp;}

D.프로그래밍의 보조 수단으로써 제공되는 모듈 : Figure 4-9에 곡선을 따라 회전하며 이

동 하는 예에서 사용할 좌표값을 앱북 프로그래머의 터치 입력에 따라 좌표값을 리턴하

는 객체에 대한 소스코드를 자동으로 프로그램해 주는 모듈의 클레스이다.

- 54 -

// FCMakePath.h#import <Foundation/Foundation.h>#import <GameKit/GameKit.h>

#import "cocos2d.h"#define kWriteFileName @"ccfPath"#define kWriteTmpCodePath @"/tmp/"typedef enum { kDraw, kTouch,} FCPathMakerMode;

@interface FCPathMaker : CCLayer@property (nonatomic) FCPathMakerMode mode;@property (retain,nonatomic) NSMutableArray * path;@property (retain,nonatomic) CCLayer *scene;@property (retain,nonatomic) NSString *fileName;-(FCPathMaker *)initWithScene:(CCLayer *)scene;-(FCPathMaker *)initWithScene:(CCLayer *)scene FileName:(NSString*)fileName;-(FCPathMaker *)initWithScene:(CCLayer *)scene FileName:(NSString*)fileName Mode:(FCPathMakerMode)mode;

+(FCPathMaker *)pathMakerWithScene:(CCLayer *)scene;+(FCPathMaker *)pathMakerWithScene:(CCLayer *)scene FileName:(NSString*)fileName;+(FCPathMaker *)pathMakerWithScene:(CCLayer *)scene FileName:(NSString*)fileName Mode:(FCPathMakerMode)mode;@end

// FCMakePath.m#import "FCPathMaker.h"#import "AppDelegate.h"@implementation FCPathMaker@synthesize path=_path;@synthesize scene=_scene;@synthesize fileName=_fileName;@synthesize mode=_mode;- (id)init{ self = [super init]; if (self) { _mode=kDraw; _path =[NSMutableArray arrayWithCapacity:100]; [_path retain]; } return self;}-(FCPathMaker *)initWithScene:(CCLayer *)scene{ [self init]; _scene=scene; _scene.isTouchEnabled=NO;

- 55 -

self.isTouchEnabled=YES;

self.anchorPoint = _scene.anchorPoint; self.contentSize = _scene.contentSize; CCLayerColor *colorLayer = [CCLayerColor layerWithColor:ccc4(0, 0, 255, 99) width:480 height:320 ]; [self addChild:colorLayer]; CCMenuItem *itemAchievement = [CCMenuItemFont itemWithString:@"End" block:^(id sender) { [self touchsWrite]; } ]; CCMenu *menu = [CCMenu menuWithItems:itemAchievement, nil]; [menu alignItemsHorizontallyWithPadding:20]; [menu setPosition:ccp( 30,20)]; // Add the menu to the layer [self addChild:menu];

return self;}-(FCPathMaker *)initWithScene:(CCLayer *)scene FileName:(NSString*)fileName{ FCPathMaker *fpm = [[FCPathMaker alloc] initWithScene:scene]; fpm.fileName=fileName; return fpm;}-(FCPathMaker *)initWithScene:(CCLayer *)scene FileName:(NSString*)fileName Mode:(FCPathMakerMode)mode{ FCPathMaker *fpm = [[FCPathMaker alloc] initWithScene:scene FileName:fileName]; _mode=mode; return fpm;}+(FCPathMaker *)pathMakerWithScene:(CCLayer *)scene{ return [[FCPathMaker alloc] initWithScene:scene];}+(FCPathMaker *)pathMakerWithScene:(CCLayer *)scene FileName:(NSString*)fileName{ return [[FCPathMaker alloc] initWithScene:scene FileName:fileName];}+(FCPathMaker *)pathMakerWithScene:(CCLayer *)scene FileName:(NSString*)fileName Mode:(FCPathMakerMode)mode{ return [[FCPathMaker alloc] initWithScene:scene FileName:fileName Mode:mode];}#pragma mark - Touch-(void)touchsWrite{ NSDate *d = [NSDate dateWithTimeIntervalSinceNow:0 ]; //초단위 NSDateFormatter * df = [[NSDateFormatter alloc] init ];

- 56 -

NSTimeZone *tz = [NSTimeZone timeZoneForSecondsFromGMT:(+9 * 60 * 60)]; df.timeZone =tz ; NSLocale *krLocale = [[NSLocale alloc] initWithLocaleIdentifier:@"ko_KR"]; //en_US df.dateFormat=@"yyMMdd_HHmmss"; df.locale=krLocale; NSString *theTime =[df stringFromDate:d]; NSString *theFileName = [NSString stringWithFormat:@"%@%@",_fileName==nil?kWriteFileName:_fileName, _fileName==nil?theTime:@""]; NSString *thePath = [NSString stringWithFormat:@"%@%@.h",kWriteTmpCodePath,theFileName]; NSFileManager *filemgr; filemgr = [NSFileManager defaultManager]; if ([filemgr fileExistsAtPath: thePath ] == YES) NSLog (@"File exists"); else { //File not found [filemgr createFileAtPath:thePath contents:nil attributes:nil]; } NSFileHandle *writeFile;

writeFile = [NSFileHandle fileHandleForWritingAtPath:thePath]; if(writeFile == nil) { NSLog(@"fail to read file"); return ; } NSMutableString* text = [NSMutableString stringWithCapacity:1000]; if (_mode == kDraw) { [text appendFormat:@"\₩#import <Foundation/Foundation.h> \₩n\₩#import \₩"cocos2d.h\₩" \₩n\₩#define kMoveDuration 0.1 \₩n\₩@interface %@ \₩n\₩+(NSMutableArray*)array; \₩n\₩@end \₩n\₩@implementation %@ \₩n\₩+(NSMutableArray*)array{ \₩n\₩return \₩n\₩[NSMutableArray arrayWithObjects: \₩n" , theFileName,theFileName]; for (NSString *t in _path) { [text appendFormat:@"%@ \₩n" ,t]; } [text appendString:@"nil]; \₩n\₩} \₩n\₩@end \₩n\₩ "]; }else if(_mode == kTouch){ [text appendFormat:@"\₩

- 57 -

#import <Foundation/Foundation.h> \₩n\₩#import \₩"cocos2d.h\₩" \₩n\₩#define kMoveDuration 0.1 \₩n\₩@interface %@ \₩n\₩+(CCPointArray*)array; \₩n\₩@end \₩n\₩@implementation %@ \₩n\₩+(CCPointArray*)array{ \₩n\₩ CCPointArray *pa =[CCPointArray arrayWithCapacity:2]; \₩n" , theFileName,theFileName]; for (NSString *t in _path) { [text appendFormat:@"%@ \₩n" ,t]; } [text appendString:@" \₩n\₩return pa; \₩n\₩} \₩n\₩@end \₩n\₩ "]; } NSData *data =[text dataUsingEncoding:NSUTF8StringEncoding allowLossyConversion:YES]; [writeFile writeData:data]; [writeFile closeFile]; NSLog(@"open %@",thePath);

}

-(void)ccTouchesBegan:(NSSet *)touches withEvent:(UIEvent *)event { UITouch *touch = [touches anyObject]; CGPoint location = [touch locationInView:[touch view]]; location = [[CCDirector sharedDirector] convertToGL:location]; //노드 찍는 코드 - 파일에 출력하기 위해 문자열로 만듦 CGPoint touchPoint = location; if (_mode == kDraw) { if(_path.count!=0) [_path removeAllObjects]; [_path addObject: [NSString stringWithFormat: @"[CCMoveTo actionWithDuration:kMoveDuration position:CGPointMake(%f,%f) ]," ,touchPoint.x,touchPoint.y] ]; }else if(_mode == kTouch){

}}#pragma mark - Touch- (void)ccTouchesMoved:(NSSet *)touches withEvent:(UIEvent *)event{ UITouch *touch = [touches anyObject]; CGPoint location = [touch locationInView:[touch view]]; location = [[CCDirector sharedDirector] convertToGL:location]; //노드 찍는 코드 - 파일에 출력하기 위해 문자열로 만듦 CGPoint touchPoint = location; if (_mode == kDraw) {

- 58 -

[_path addObject: [NSString stringWithFormat: @"[CCMoveTo actionWithDuration:kMoveDuration position:CGPointMake(%f,%f) ]," ,touchPoint.x,touchPoint.y] ]; }else if(_mode == kTouch){}}- (void)ccTouchesEnded:(NSSet *)touches withEvent:(UIEvent *)event{ UITouch *touch = [touches anyObject]; CGPoint location = [touch locationInView:[touch view]]; location = [[CCDirector sharedDirector] convertToGL:location]; //노드 찍는 코드 - 파일에 출력하기 위해 문자열로 만듦 CGPoint touchPoint = location; if (_mode == kDraw) { [_path addObject: [NSString stringWithFormat: @"[CCMoveTo actionWithDuration:kMoveDuration position:CGPointMake(%f,%f) ]," ,touchPoint.x,touchPoint.y] ]; [self touchsWrite]; }else if(_mode == kTouch){ [_path addObject: [NSString stringWithFormat: @"[pa addControlPoint:ccp(%f, %f)];" ,touchPoint.x,touchPoint.y] ]; }}- (void)ccTouchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event{ if (_mode == kDraw) { NSLog(@"%u point-- touch canceled but Touchs will be write.-----end",_path.count); [self touchsWrite]; }}@end

- 59 -

Abstract

As the use of smart devices increases, book apps get more popular whose user interaction

functionality far surpasses the simple multimedia type e-book. User-interactive animation is the

key element of book apps. While game engine based programming may produce high

performance animation functions, the cost for software programmers with such expertise is high.

In this Thesis, we propose the modularization of game engine based animation functions

to facilitate low-cost high performance animation. By using animation modules encapsulated

from game engine, instead of direct coding from game engine, programmers can easily

implement various animation functions for book apps. We analyzed the process of book app

development to select most popular animations. We made a story board composition menu where

each symbol stands for one of selected animations. The symbols in the menu are the building

blocks both for the story board writers and for the software programmers. As they share the same

composition menu, a coherent development of book app is made possible. Modularized coding

helps to increase the productivity of less experienced programmers and to enhance software

reusability. In summary, modularization of game engine based animation functions reduces the

programming cost and increase the work coherence among team members.

Key words: e-book, game engine, Book App

- 60 -

감사의 글

먼저 본 논문이 나오기까지 부족한 저에게 처음부터 끝까지 아낌 없고 꼼꼼한 지도

를 해주신 김용철 교수님께 감사드립니다. 그리고, 논문이 완성되기까지 여러 조언을 해

주신 최기상 교수님과 이준화 교수님께 감사드립니다.

1999년 바쁜 사업 때문에 논문을 마치지 못하고 이듬해 군대를 가게 되었고, 논문

대신 여자 친구(현재의 집사람)에게 시집 한권을 남기고 군대를 간 이후 세월이 흘러 오늘

에서야 늦은 논문을 탈고 하고 있습니다. 내년 박사과정을 밟게 되면 또 수많은 논문을 쓰

겠지만 이러한 나를 발전 시키는 첫 석사 논문을 작성하는 시간이 참 감사하게 느껴집니

다.

본 논문이 나오기까지 많은 분들의 도움이 있었습니다. 가깝게는 연구실에서 오타

수정 및 많은 시간을 절약해 준 연구실 동생들(봉원선, 이선민)도 있고, 논문에 등장하는 기

획자의 역할과 디자이너의 역할을 상세히 설명해 주시고 논문에 등장하는 대부분의 기호

들을 설계해 주신 디자인 락의 이상용 사장님도 있고, 늦은 논문을 시작하게 용기를 준 시

소드림(주) 이원희 대표도 있고, 모듈을 실제 앱북 개발에 적용해 모듈의 신뢰도를 높여준

김성국 개발자도 있고, 본문에 등장하는 원화 이미지를 그려준 원화 디자이너 임영이 양도

있고 이런 많은 분의 도움 속에서 논문이 작성되었으며, 그 밖에도 도움을 주신 모든 분들

께 감사의 인사를 드립니다.

본 논문에 등장하는 삽화나 스토리보드는 앞으로 출시될 “선인장 고양이와 가시복

어”라는 앱북을 만들기 위한 자료이며, 스크린 샷은 피터 래빗, 콩쥐 팥쥐, 방귀쟁이 며느

- 61 -

리라는 3가지 앱북에서 구한 것인데 이들 앱북을 만드는 관계자 분들에게 본 논문을 통해

감사의 뜻을 전합니다.

또한, 저는 본 논문을 13년 동안 미뤄둔 어려운 숙제가 아닌 박사과정을 시작하기

위한 과정의 일부로 생각합니다. 세 아이의 아버지고, 다섯 식구를 책임지는 가장으로써

전일제 박사과정을 시작한다는 것은 참으로 어려운 선택이었지만, 제 뜻을 이해 해주고 격

려해 주는 집사람과 아이들에게 감사 인사 보다는 ‘사랑한다’는 세삼스런 인사를 전합니

다.

끝으로, 양수리 양지 바른 언덕에서 기뻐하고 계시는 아버지와 언제나 사랑스런 눈

으로 저를 지켜 보시는 어머니께 감사인사 드립니다.

- 62 -