입력, 처리, 출력

우 리가 세번째 시간에 배웠던 입력, 처리, 출력에서 이제 출력에 해당하는 내용을 조금 업그레이드 할 시간이 왔습니다. 그동안은 입력과 처리 부분의 기본 개념들을 강화하느라고 출력을 trace 로 고정해서 진행했었지만, 이제는 Flash 답게 눈으로 보여주는 출력을 해봐야겠죠. 데이터를 trace() 를 통해서 보여주는 것도 출력이고, 데이터를 MovieClip 으로 시각적으로 보여주는 것도 출력입니다.

DisplayObject 의 구조

일단 DisplayObject 를 이해하기 위해서 5번째 상속 시간에 봤었던 대빵 큰 그림 (http://ssen.name/develop/as/grand/Grand1.png) 을 다시 한 번 보도록 하겠습니다. 링크를 눌러서 한 번 보세요. 그림을 통해서 설명하도록 하겠습니다.

오른쪽부터 설명합니다.

Object

Flash 에서 사용하는 모든 객체들의 가장 기본 단위입니다.

EventDispatcher

Flash 의 이벤트 모델을 구현하기 위해서 필요한 기본 객체입니다. EventDispatcher 를 통해서 우리는 Click, RollOver, KeyDown, UploadComplete 등의 이벤트를 사용할 수 있습니다.

DisplayObject

Flash 에서 눈으로 보여지는 모든 객체들은 이 DisplayObject 를 상속받아 만들어지게 됩니다. 시각 출력을 위한 가장 하위 객체이죠. 눈으로 보여지면 될뿐인 Shape, Bitmap 등은 이 DisplayObject 에서 바로 상속되어서 구현되어지게 됩니다. 그래서, Bitmap 과 Shape 는 눈으로 볼수만 있고, 마우스 등으로 어떤 조작은 할 수 없죠.

InteractiveObject

눈 으로 보여지면서 동시에 마우스 (포인터 기기)나 키보드 등을 통해서 조작할 수 있는 시각객체로서의 최하단 입니다. 우리가 MouseEvent 를 사용할 수 있는것은 이 InteractiveObject 부터이죠. 단순하게 눈으로 보면서, 마우스 조작을 할 수 있는 객체인 SimpleButton 과 TextField 가 여기서 상속을 받게됩니다.

DisplayObjectContainer

무비클립 안에 무비클립 안에 무비클립... 이런식으로 트리형태의 포함구조를 만들수 있는 컨테이너 기능이 추가가 됩니다.

Sprite

사용자가 직접적으로 사용할 수 있는 (실제 생성가능한) Flash 의 기본 시각객체 입니다.

MovieClip

Sprite 에 영화처럼 frame 을 구성할 수 있는 기능이 추가된 시각객체 입니다. Flash 의 타임라인을 통해서 영상의 제작이 가능하죠.

(이런 상속관계는 http://ssen.name/develop/as/grand/AS3.jpg 이 그림을 보면 좀 더 쉽게 이해할 수 있을겁니다.)

대 충 Flash 가 사용하는 시각객체들은 이런 구성을 가지고 있습니다. 흠… 개인적으로는 Bitmap 이 DisplayObject 에서 상속을 받는게 아니라, InteractiveObject 에서 상속을 받아서 Event 를 가졌으면 어땠을까 생각을 하기도 합니다. 아니면, InteractiveBitmap 이라는게 있어도…;;; 개인적으로 대체적인 그래픽처리를 Bitmap 으로 하는데, Event 를 위해서 항상 Sprite 에 집어넣어서 사용해야 하는게 좀 불편하곤 하네요.

뭐 말로해서 이해될 거면 초보가 아니겠죠… ㅡ ㄴ ㅡ;;; 눈으로 보여드리겠습니다. 일단 기본 시각객체의 최상단에 위치하는 MovieClip 부터 시작해보죠.

MovieClip 

뭐 이렇게 코드상에서도 만들어낼 수는 있지만… MovieClip 의 목적인 Frame 은 Flash 에서만 편집할 수 있죠.

MovieClip 의 Frame 구조는 현재로서는 Flash 에서만 만들수 있죠. 조만간 Thermo 가 나온다면 Thermo 에서도 가능하겠지만, 어쨌든 지금으로서는 Flash 전용입니다.

뭐 디자이너, 모션과 협업이 잦은 분들을 위해 이야기해 드리자면, 제작설정에서 이렇게 SWC 내보내기를 체크한 다음에 Ctrl+Enter 를 하면…

이렇게 swf 뿐만 아니라, swc 파일도 하나 생성되는데요. 이 swc 파일을 

FDT 의 경우 이런 방식으로 Class path 에 포함시키면 

요렇게 라이브러리에 이름을 붙여둔 라이브러리들을 

이 렇게 개발자들이 사용할 수 있게됩니다. 이름에 test. 을 붙여서 package 를 구분해줬기 때문에 test package 에 소속되어있죠. 개발자에게 전달할때 적절한 package 경로로 구분을 해주면 개발자가 무척 편리하게 작업을 할 수 있습니다. (플래시에 관련되는 디자이너라면 이런 지식은 인력 간 협업을 위해서 당연히 알아야 하는 것입니다. 단지, 플래시 발전속도가 너무 빨랐고, 업무환경 자체가 너무 원시적 이기에 아직까지는 "해주면 좋은 것" 에 분류시키는 것 뿐이죠.) 

그렇게 만들어진 MovieClip 은 이렇게 개발자가 간단하게 사용을 할 수 있게됩니다. ^^ 

mc 의 타입을 TestMovieClip 으로 해도 되지만, 

으로 해도 됩니다.

그리고, Sprite 로 해도 되죠.

하지만, DisplayObjectContainer 로 하면 graphics 부분이 에러가 나게 되죠.

이유는 graphics 는 Sprite 부터 생기는 기능이기 때문입니다. 그렇기에 DisplayObject 까지 내려가면 graphics 는 존재하지 않는 기능으로 취급되어서 에러가 됩니다. 

뭐 graphics 부분을 빼면 이렇게 최하단 시각객체인 DisplayObject 로 지정을 해도 멀쩡히 돌아가게 됩니다. 다만 이 경우엔 MovieClip 이 가진 원래 기능인 gotoAndPlay 나 DisplayObjectContainer 의 addChild 같은 상위 기능들은 사용할 수 없게 되죠. 그런 기능을 사용하려면 

이 런 조건문을 통해서 사용을 할 수 있습니다. 이런 예외처리 기능은 Class A 가 사용하는 mc 가 최하단 DisplayObject 상속을 받은 Bitmap 일수도 있고, Sprite 일수도 있고, MovieClip 일수도 있을때, MovieClip 일 경우에만 어떤 특정한 처리를 할때 도움이 됩니다.

뭐… 보통 작업을 할때는 필요없겠지만, 이런 예외처리는 두고 두고 사용할 라이브러리를 만들때는 매우 중요합니다. 사용의 폭을 크게 넓혀주기 때문이죠.

Flash CS3 에서는 MovieClip 을 BaseClass 로 해서 확장시킨 Class 에서 frame1 이 아닌, 다른 frame 에 있는 linkage name object 를 읽어오지 못하는 문제를 비롯해서, ActionScript3.0 과 Flash 간의 호환성 문제가 꽤 많았기 때문에 실제적으로 Interactive Media 를 제작하는 웹 에이전시가 ActionScript3.0 으로 확장하는데 많은 어려움을 겪게 만들었지만, Flash CS4 (Flash player 10, SDK4) 에서는 그런 여러가지 호환성 문제가 해결된다고 하는군요. MotionGraphic 에 code 를 가미시키기 어려운 점이 많았지만, 조만간 그런 환경이 개선된다니 기존의 frame 안에 코딩을 하는 원시적인 작업방식도 많이 개선되어 나가지 않을까 싶습니다. 그런 작업환경의 개선은 모션그래픽 작업자는 Motion 만 작업하고, 개발자는 개발코드만 따로 작업함으로서 현재 뒤죽박죽이 되어서 여러 문제점을 일으키는 문제를 해결해주게 되겠죠.

Sprite

ActionScript 3.0 에서 등장한 frame 이 빠진 시각객체인 Sprite 는 Flash 의 속도개선에 큰 도움이 되었습니다. 쓰잘데기 없는 frame 관련 기능들이 빠짐으로서 꽤 가볍게 사용할 수 있게 된거죠.

뭐 특별히 설명할게 없네요. ㅡ ㄴ ㅡa 주구장창 사용하게 될 것이므로, 걍 사용하면 됩니다.

DisplayObjectContainer, InteractiveObject, DisplayObject

DisplayObjectContainer 와 InteractiveObject 와 DisplayObject 는 추상클래스로서 개발자가 생성할 수 없습니다.

뭐 이렇게 코딩을 한다고 실시간 에러가 뜨지는 않지만…

이 렇게 런타임 (실제 동작시) 에는 에러를 뱉게되죠. 이것들은 new 로서 개발자가 생성할 수 없습니다. 그러므로, 실제 개발자가 사용할 수 있는 시각객체의 최소는 Sprite 가 되게 됩니다. 뭐 조금 특수한 Bitmap 이나 Shape, SimpleButton, Loader, Stage 는 제외하고 말이죠.

Event 구조

예전에도 잠깐 이야기 했던 것이지만, ActionScript 를 공부한다는 것은 크게 두가지로 나뉘게 됩니다.

1 . ActionScript 라는 언어를 이해하는 것과

2 . ActionScript 가 사용하는 API 를 이해하는 것

이 중, API 를 공부하는 중에 자신이 접해보지 못한 Class 를 이해할 수 있는 탐구방법으로 Event 를 쌔리 다 걸어놓고 테스트 하는 방법이 있습니다. 구조를 이해하는데 큰 도움이 되죠.

뭐 쉽게 이야기해서 

오늘 배울 DisplayObject 의 Sprite 를 이해하기 위해서 이 이벤트들을 다 걸어보는 거죠…

...

하지만, 그런것은 설명하는 제가 매우 귀찮으므로…

요정도만 걸어보도록 하죠. 그래도 꽤 많네요. 그리고, 로그를 살펴보면 됩니다. mc 를 더블클릭 하는 순간에 removeChild 되어서 사라지게 되는 구조입니다.

대충 이런 로그가 남았습니다.

여 기서 생성시 로그는 render 까지입니다. 시각적으로 확인이 가능한 시각스테이지 위에 올려지는 addedToStage 가 우선 실행되며, 이후 해당 Object 가 가진 시각정보를 실제 그림으로 렌더링하는 render 가 실행됩니다. 여기까지가 어떤 시각객체가 addChild 되어서 렌더링 되는데까지 걸리는 과정입니다. 이 이후부터 removedFromStage 까지는 사용자의 동작에 반응하는 인터렉션 이벤트에 해당하죠.

이 런 이벤트 구조를 분석하다보면 Flash 의 시각객체가 실제적으로 어떤 원리에서 동작하는지를 알수가 있게 됩니다. 그리고, 원리란 언제나 아는 사람과 모르는 사람의 차이를 분명하게 내주는 요인이 되죠. 그리고, 보통 처음엔 Click 이나 KeyDown 정도가 눈에 띄게 되는데… 실력이 늘어날수록 처음에 잘 보이지 않았던 render 나 removedFromStage, tabIndexChange 같은 것들이 눈에 들어오게 될 겁니다. 그리고, 후회하게 되죠. "아… 씨… 예전에 내가 왜 이것들을 공부하지 않았었지? 미리 알았었다면 더 좋았을텐데…" 하지만, 아무리 후회를 해도 아는만큼 보인다… 라는 진실은 빗겨가질 않게 되곤 합니다. 그저 복잡하게만 보이는 ASDoc 일수 있겠지만, 아는만큼 보인다… 라는 사실을 두고 생각해보면 그저 쓸데없어 보이는 부분들이 알고보면 보물창고 라고 말씀드리고 싶네요. 사실 저도 아직 안보이는 부분이 많거든요… (분명 글씨가 있는데도 말이죠… 마치 마법처럼 안보여요...) 뭐… 그런것을 느낄때마다 학문이란 것과 인간이란 것에 대해서 조금 허탈한 재미를 느끼곤 합니다. 세상은 넓다 라는 것과 세상은 좁다 라는 이율배반적 진실이 동시에 이해된다고 할까요… 길가에 굴러가는 돌맹이에서 깨달음을 얻는것이 불가능하지 않다는 것도 생각하게 되구요. 아는 만큼 보이는 것이니까요...

중간 잡담

뭐 오늘은 기술적인 이야기는 거의 없었죠? 뭐 딱히 설명할게 없어서입니다. ㅡ ㄴ ㅡ;;; 언제까지 API 하나 하나 코드 짜주면서 설명할 수 있는것도 아니고, 그동안 주구장창 이야기했던 ASDoc 보면서 실제로 API 하나, 하나 코딩해봐야 합니다.

뭐 소개팅을 한다고 해도 주선자가 "자! 이제 너 머릿결을 쓰다듬으면서 입 맞추고, 혀는 45도 각도로 세반퀴 반 할짝할짝!" 이러지는 않죠… DisplayObject 를 소개팅 시켜줬으니 알아서 사귀어야 합니다…;;;

돈 백만원 받고 수업해주는 좋은 학원이래봤자 좀 열기 쉬운 문을 만들어주는 것 뿐이지, 실제로 문을 여는 것은 배우는 사람 스스로의 문제라는 것은 언제나 변함이 없습니다. (고급 교육기관 이라는 것은 언제나 그런 의미죠. 그래서 깨달음을 줄 것이라고 생각하고 돈을 쏟아붓는 사람은 언제나 실패를 하게 됩니다. 깨달음은 돈 수억을 쏟아부어도 언제나 셀프서비스죠…) 제 강좌는 열기 어려운 낡고 빡빡한 문이라서 여는게 좀 빡십니다.

시각출력

왜 눈으로 보여주는 것일까?

이 문제를 생각해본적이 있으신가요? 개발자고 디자이너도 모션이고 나발이고를 떠나서 HTML 에 비해 만들기 열라 피곤하고 괴로운 Flash 를 구지 써서 문자출력을 구지 시각출력으로 바꾸자 하는 이유가 뭘까요?

아름답기 때문에?

아니면, 그냥 이걸 원하는 사람들이 많아서 돈이 되니깐?

피 식 웃으면서 이야기 하자면, 무슨 도닦자는 것도 아니고 까놓고 이야기해서 생산자들은 대부분 두번째가 솔직한 진실이고, 소비자들은 대부분 첫번째 일것 입니다. 아무리 내 직업에 대해 자부심을 가지려고 해도, 실제 업무에서 보는 그저 천박한 장사치일 뿐인 소비자(클라이언트)들과 돈 백만원이 아쉽고, 시간에 쫒기며 허덕거리는 나 자신을 비롯한 대부분의 그저 막판 노가다꾼에 불과한 생산자들이 그런 고차원적인 철학적 관념을 가지는건 무리라고 생각되더군요. IT 가 무슨 지식산업이네 뭐네 개소리를 하는건지 실제 그라운드에서 일하다보면 이해가 안될때가 많죠.

뭐… 그래도 때려치지 못하고 꾸역꾸역 매달려있는 것은 아무리 막판 노가다꾼처럼 일한다고 해도, 마음 한구석은 학문에 대해 진지하게 생각하는 탐구자이기 때문이라고 생각을 합니다. (결코 장사할 돈이 없어서라고 생각하지 않습니다.)

Flash 에 매우 인접한 학문으로서 정보시각화와 인지과학 이라는 분야가 있습니다. 뭐 이건 뭘까해서 논문이라도 다운 받아 볼라치면 영어와 한문으로 떡칠이 되고, 알듯 모를듯 초장문으로 써진 글때문에 뇌가 지끈거리게 만드는 그런 학문분야들 인데…;;; 뭐 그럭저럭 비슷한 영역이라서 그런지 볼만은 하더군요. 그래도 이해는 안되지만요…;;; (쉬운말로 하면 학위를 안주나 봐요…)

HTML 이 HyperText 로서 텍스트 뿐만 아니라, 표 (Table) 과 그림 (Image) 소리와 영상까지 사용할 수 있다고는 해도, Document 로서 점진적 전달의 한계는 어쩔수 없이 존재하죠. 그런 것은 레이아웃을 통해서 배열을 하는것 만으로는 해결을 할 수 없는것 같습니다. 그리고, HTML 이 제공하는 시각화 도구만으로는 조금 무리가 있는것도 같습니다.

데 이터들을 있는 그대로 보여주는… 그저 보다 효율적으로 배열함으로서 정보를 전달하는데 그치는 문서와는 틀리게 Flash 는 보다 더 고차원적인 기능이 있습니다. 문서는 강조해야 할 부분을 보여주기 위해서 그저 노란색으로 마킹할 뿐이지만, Flash 는 그 이외의 영역을 블러처리 해서 뿌옇게 해버림으로서 강제적으로 집중할 수 있게도 할 수 있죠.

이 런 집중 처리 뿐만 아니라, 연관, 역정보의 교차배열과 특정 정보에 대한 검색시각화 등 여러가지 상상하는데로 만들수 있는 기법과 Flash 가 자랑하는 이 DisplayObject 라는 시각도구들을 통해서 정보를 기록보다 더 고차원적인 이해에 가까운 형태로 전달할 수 있지 않을까 합니다. 뭐… 그런것 이외에도 여러가지 의미를 가질수 있겠죠.

Flash 는 시각도구로서 뛰어난 능력을 지녔습니다. 사실상 만들기는 HTML 에 비해서 너무 괴로울 정도로 쓰잘데기 없이 복잡하죠. 그런데도 불구하고 왜 Flash 로 만들어서 "눈으로 보여주려는 것일까…" 를 가끔 생각해봐야 하지 않을까 싶습니다.

인 간은 자신의 욕구를 모두 말로 표현할 수 없죠. 우리에게 이렇게 이렇게 해달라고 하는 클라이언트의 설명인 말에 집중하는 것 보다 그 말의 근원인 욕구를 보려면 Flash 의 시각출력적 특징에 대한 이해를 가지고 있어야 되지 않을까 싶습니다. 우리는 정글을 탐험하기 원해서 정글안내자인 나에게 찾아온 여행자들에게 길안내를 맡기려 하는 경우가 많죠.

뭐… 생각해도 생각해도 골치아픈 문제이긴 하지만… 고민해볼 가치가 있는 문제이지 않을까요. 겁나 알고리즘을 잘 짜는 사람과 인간의 욕구를 해소해줄수 있는 사람… 그 둘 중 후자를 지향하는 저라서 기술적 문제보다 이런게 더 크게 다가오는 것일수도 있지만요... 

출처: ssen님의 레시피

http://ssen.name/zb/2609