URL (Uniform Resource Locator)

URI(Uniform Resource Identifiers) 라는 특정한 자원에 대해 이름을 붙여두는 기술이 있습니다. 이름을 붙여둬야 부를때 용이해지겠죠? 늘 상 , "어이 거기~ 셋째줄에 두번째 자원 좀 들고와!" 이럴순 없잖아요. 그래서 고유한 이름을 붙여둡니다. URL 은 그 URI 의 하위에 소속되는 구성입니다. 특정한 리소스(자원) 에 접근할 수 있는 경로를 이야기하죠. 뭐 우리가 늘 상 사용하는 거니깐 특별한 설명은 필요없을 겁니다.

flash 가 접근 가능한 외부 자원 저장소들과 web 의 발전상

뭐 (딴지를 걸기 시작하면 손쉽게) 논란의 소지가 발생할 수도 있는 문제겠지만, 대충 대충 분류하자면 flash 가 사용할 수 있는 외부 자원은 이렇게 4가지 정도가 됩니다. web 상의 swf 만을 생각한다면 뭐 크게 생각해서 3가지 정도죠.

보 통 인터넷을 사용할 때 유저들의 시나리오를 보면 "어떤 컨텐츠를 제작하고", "그렇게 완성된 컨텐츠를 공유할 목적으로 업로드 하고", "나나 누군가가 그 컨텐츠를 소비한다" 라는 3가지 행위로 나뉘어지게 되는데요. 뭐 당연한 소리겠지만, 소비성향을 가진 세번째가 가장 큰 네트워크 트래픽을 사용하겠죠. 이건 읽어들일수밖에 없는거니깐요. 하지만, 현재 존재하는 html 이던 flash 던 인터넷 기술들이 첫번째 행위에서 "내 컴퓨터 안에 중간 저장을 할 수 있는" 기능이 지원되지 않기 때문에, 첫번째의 행위를 하면서 두번째의 행위를 어쩔수 없이 사용하게 됩니다. 이런게 약간 잡스런 트래픽을 유발하게 되기도 하죠.

뭐 쉽게 이야기해서 일기라는 개인이 쓰고, 개인이 읽는 행위에서 조차 웹기술의 한계상 두번째를 어쩔수 없이 거쳐야 하게 됩니다. 뭐 이런걸 해결하기 위해서 아마 1~2년 내에 등장하게 될 HTML5 에서는 내 컴퓨터에 특정한 저장소를 활용할 수 있게 하는 기술이 도입되게 됩니다. 이미 google 에서 gears 라는 이름으로 등장한 기술이기도 하구요.

뭐 주리주리 이상한 소리들을 늘어놓았는데… 이런걸 통해서 이야기 하고 싶은건 예전에도 이야기 했듯, 기술을 사용하려 하는데 있어서 인간으로서의 자연스러운 행동을 먼저 생각하라는 겁니다. 기술한계 때문에 컴퓨터 위주의 행동을 많이 해야하지만, 기술의 발전은 언제나 인간의 자연스러운 행동을 향해 나아가게 되거든요.

그 리 멀지 않은 몇 년안에 웹상에서도 "개인적인 내용들이나 제작중인 컨텐츠의 중간저장"은 자기 컴퓨터에 기록하고, "공유되어야 할 컨텐츠" 만을 최종적으로 인터넷에 업로드 하는 기술환경이 웹서비스 제작자들에게 주어지게 될 것 입니다. 기술이 등장해서 그것을 활용하는게 기술발전이 아니라, 필요한 기술이 등장하는게 기술발전 이라는거죠...

아 직은 웹 서비스 상에서 쓰기, 읽기 라는 두가지 행위만이 존재하지만, 그 기술환경이 주어지게 된다면, 쓰기, 중간 저장, 퍼블리싱, 읽기 라는 행위의 증가가 발생할 가능성이 높고, 그런 행위의 증가는 디자인, UX 등 여러가지 면에서 많은 변화를 가져오게 될 것이라고 봅니다.

뭐 컨텐츠의 퍼블리싱 등의 특정한 목적이 있는 web 저장소가 지금처럼 너무 용도에 맞지 않는 부분들에까지 무분별하게 사용되는 일은 조만간 없어질 것이라는 쓸데없는 소리였고, 그럼 시작해보죠. 히위고~

Web Server

뭐 온라인 게임이나 채팅 같은걸 테스트 할려면 소켓서버라는게 필요하고, 웹상의 데이터 교환을 테스트 하려면 웹서버가 필요하겠죠…;;; 좀 애매하긴 하지만, 일단 PHP 로 수업을 진행하겠습니다. 자기 웹호스팅이 있으신 분들이라면 간단하게 웹호스팅을 통해서 테스트 하시면 되겠고… 없는 분들이라면 별수 없죠 뭐…;;;

http://ssen.name/zb/1983

http://ssen.name/zb/1146

이 둘 중 하나를 선택해서 웹서버를 설치하세요…;;;

URLLoader

ActionScript 3.0 이 나오면서 2.0 때까지에 비해 많이 변화된 부분이 이 웹 자원에 대한 접근방식 입니다. 상당히 합리적으로 바뀌었다고 해야할까요… 뭐 2.0 때까지의 우후죽순 좀 조잡하게 구성되던 기능들이 깔끔하게 정리가 되었습니다.

뭐 일단 데이터가 될 txt 와 xml 을 만들어놔보죠.

test.xml 과

test.txt 를 대충 만들어둡니다.

fla 와 같은 위치 (swf 가 퍼블리싱 될 위치와 같은 위치)에 둡니다. 

뭐 간단한 코딩을 통해서 데이터를 불러봅니다. 간단하죠? 실행을 시켜보면

이렇게 정상적으로 표시가 됩니다. 

아… fla 파일에서 테스트 하고 싶을땐 이렇게 문서클래스에 연결시키면 됩니다. TestLoad.as 로 만든 파일을 문서클래스로 등록하면 flash 에서 테스트 할 수 있습니다. "어라… 저건 eclipse 가 없으면 못하는건가?" 이러지 마시구요…;;;

자… 그러면 좀 살펴보죠. 일단 addEventListener 는 EventDispatcher 나 MouseEvent, KeyboardEvent 에서 주구장창 보았던 것이죠? 이벤트는 쉽게 아실겁니다. 그럼 Event.COMPLETE 은 어떤 이유에서 쓰나… 뭐 예전에도 말했듯… 

F1 을 눌러보면 다 나옵니다. 수신완료시에 complete 이 발생된다고 나와있네요. 자… 근데 여기에 progress 라는 것도 있네요. "로딩바 어뜨케 만들어요 ㅜ ㄴ ㅜ" 이러는 분들이 많으신데, 어렵지 않습니다. 이 이벤트를 사용하면 간단하게 사용이 가능하니깐요.

progress 를 추가시켜 보죠.

뭐 이렇게 쓰면…

이렇게 간단하게 표시가 됩니다. (로컬상에서 테스트를 하는거라서 로딩이 제대로 표현이 안되네요…) 숫자들을 trace 가 아니라, MovieClip 등으로 표현하면 간단하게 로딩바가 만들어지는 거죠.

XML 불러오기

이렇게 Request 에 test.xml 파일을 불러오고, 아랫쪽 loaded 에 typeof 로 불러온 데이터의 형식을 테스트 해보면 

이 렇게 test.xml 이 정상적으로 불러지게 됩니다. 근데, 불러온 시점에서는 일단 event.target.data 는 String… 문자열 상태입니다. 즉, 불러들인 시점에서는 xml 이나 txt 나 똑같이 문자열 상태입니다. 그렇기에 불러온 xml string 을 제대로 된 xml tag 로 바꿔줘야 하죠.

이렇게 xml 로 만들어주면 

정상적으로 xml 로 변환이 됩니다.

패킷 확인해 보기 

뭐 데이터 파일들을 웹에 올려놨습니다.

그리고, request 를 경로에 맞게 바꿔주고 

패킷을 확인해보면 이렇게 나오게 됩니다. 뭐 어떤건지 아시겠죠?

URLVariables… 파라메터 전송해보기 

간단하게 php 파일을 만들고 

똑같이 웹서버에 올립니다.

그리고, request 에 파라메터를 넣어서 전송해봅니다. 

그러면 php 에 설정한데로 이렇게 나오게 됩니다. (PHP 부분까지 수업하기는 머시기 하니…;;;) 

패킷을 확인해보면 보이는데로 저렇게 기본 전송타입인 GET 으로 날라가게 되구요. 요걸 약간 바꿔볼까요?

이렇게 해준 다음에 method 를 POST 로 바꿔서 날려주면 

뭐 결과는 같지만…

request 패킷은 이렇게 다르게 날라가게 됩니다. GET 과 POST 의 차이지요. 장문이거나 대용량의 파일의 경우엔 이렇게 날릴수도 있습니다. 보통 글쓰기 같이 데이터가 많을 경우엔 POST 를 사용하게 됩니다.

좀 재미있는 실험을 해볼까요?

이렇게 이미지를 불러와보도록 하죠.

그러면 이렇게 알수없는 문자가 표시되지만,

패킷에는 이렇게 byte code 를 통해서 jpg 를 불러오게 됩니다. 이 데이터를 적절한 디코딩을 통해서 해석하면 bitmap 으로 변환이 가능합니다. 뭐… 그런 삽집을 하라는건 아니고, 그런것도 가능하다는거죠…

Loader… 이미지 불러오기

뭐 이미지의 경우엔 보통 Loader 를 사용합니다. 개발자가 손쉽게 사용할 수 있도록 flash 내부에 미리 만들어놓은 내장 기능이죠. 

사용법은 비슷합니다. 이렇게 URLLoader 대신에 Loader 를 사용해주고, 이벤트를 contentLoaderInfo 가 관리하게 되므로, contentLoaderInfo 에 이벤트를 걸어주도록 합니다. 

Loader 에는 로딩관련 이벤트가 발생하지 않습니다.

뭐 실행해보면 이렇게 표시가 됩니다.

화면에도 적절히 표시되게 되구요.

URLRequest 의 이런저런 기능들

뭐 보통 URLRequest 라고 하면 xml 같은 text 형식의 데이터를 로드하는 기능으로 아는 경우가 많은데,

이 contentType 을 적절히 활용하거나 해서, "현재 보고 있는 swf 화면을 스크린샷 찍어서 올리거나" 하는 기능도 만들수 있습니다. 

예전에 필요해서 만들었던 건데… 파일 업로더 기능이죠.

URLLoader 이전에 패킷을 먼저 설명한 것은 이렇게 여러가지 형식으로 request 를 보낼 수 있기 때문입니다. 뭐 뭘 만들다 보면 이렇게 파일을 전송해야 하는 경우도 있고, 경우에 따라서는 text/xml 타입으로 전송을 해야하기도 하고 그런데, 그럴때 인터넷의 패킷이라는 원시레벨을 모르는채 그저 URLLoader 의 사용방법만 알고 있으면 상황대처 자체가 불가능해지거든요. 원시레벨의 지식은 어설프게나마 인식하고 있는거랑, 아예 모르는거랑은 상당히 큰 차이를 불러오게 됩니다. 아예 모르면 상황이 불가능이 되고, 어설프게나마라도 알고 있으면 "존내 빡시겠지만, 존내 어설프겠지만 어쨌든 해결할 가능성은 보이는" 그런게 되거든요…;;;

flash, ajax 통신에서의 UI 디자인

뭐 이건 디자이너나 기획자를 겸업하시는 분들에게 도움이 될만한 내용이겠지만, 일단 flash 나 ajax 의 경우에는 html 처럼 데이터를 수신하게 된다고 해서 페이지가 변하거나 하지 않습니다. html 의 경우에서 통신이란 마치 책과 같아서 요청에 의해 데이터를 받아들이면, 책장을 넘기는 것처럼 아예 이전데이터를 삭제하고 이동해 버리지만, flash 의 경우엔 포스트잇을 붙이는 것처럼 데이터를 불러들이게 되죠.

이런 차이점은 굉장히 중요합니다.

flash 에서는 html 은 할 수 없는 데이터의 추가 호출이 가능하다는 장점이 있지만, 대신 html 처럼 이동은 새롭게 만들어야 하기 때문에, flash 를 html 처럼 기획해 버리면 상당히 난해해져버리는 면이 많습니다. 아직 flash 나 ajax 기술에 대한 다른 직군 인력들에 대한 인식도가 많이 떨어지기 때문에 기획서가 html 처럼 오는 경우가 많은데… 이거 때문에 피보는 경우가 상당히 많죠.

뭐 쉽게 이야기해서 html 사이트는 "책" 처럼 한 장, 한 장 넘기면서 보는 구조로 되어있고, 그 한계성이 있지만, flash 의 경우엔 "문서함" 이라고 보면 됩니다. 즉… html 보다는 좀 더 하위 레벨의 개념인 페이지 들이 한 장, 한 장 다 분리되어 있다는거죠. 이런 특성은 책처럼 만들어야 한다는 상황이 주어졌을때 "책" 을 직접 구성해야 한다는 단점으로 존재하기도 하지만, 대신 여러가지 다채로운 액션을 가능하게 하는 자유도를 보장하게 됩니다.

뭐 쉽게 이야기해서 "비교 검증" 이라는 행위가 html 에서는 책의 구조이기 때문에 굉장히 어렵게 구현해야 하지만, flash 에서는 문서 한 장을 보고 있는 상황에서 다시 한 장을 불러올 뿐이므로, 매우 쉽게 구현이 가능하죠. 두 개의 문서를 서로 비교하면서 보는 기능을 만들어서 사용자가 직접 머리속에서 생각해야 하는 영역을 일정부분 시각적으로 미리 씹어서 먹여주는게 가능하다는게 됩니다. 이런 사용자의 지능이 부담해야 하는 영역의 행위를 미디어 자체가 일정 부분 부담하는 행위가 가능하기 때문에 flash 를 RIA… 즉 똑똑한 인터넷 어플리케이션 이라고 부를 수 있겠습니다.

"워~ 뭐 되는게 많네~" 뭐 이런것도 맞긴 하지만, 좀 더 제대로 이야기 하자면 "지능이 부담해야 하는 것" 을 매체 자체가 부담할 수 있는 구조로 되어있기 때문에 RIA 라고 부를수 있는게 아닐까 합니다.

당 연한 이야기지만, 그렇기에 단지 이쁘게 만들수 있다는 이유 만으로 html 로 만들어도 되는 것을 flash 로 만드는 것은 미친짓 입니다. 모션그래픽 처럼 영상적 면이라면 모를까 단지 미관 때문에 flash 를 사용하는 것은 말그대로 뻘짓일 가능성이 매우 높죠. flash 를 극도로 비판하는 많은 타분야 개발자들의 말에 반발하기 쉽지만, 아직까지 미관 이외에 사용자의 지능 경험에 대한 관념이 희박한 flash 업계의 상황에서는 들어도 뭐라 할 말이 없는 비판일 수도 있는거죠. (flash 를 극도로 싫어하는 웹 원리주의자들은 굉장히 많거든요.)

ActionScript 개발자는 어디까지나 개발을 해야 하는 사람이죠. ActionScript 를 조금이라도 아는 디자이너나 기획자가 충분히 가능성이 있고, 또 필요하다는 이야기는 이렇게 개발적인 지식을을 다채롭게 활용해서 무언가 가치를 창조해 낼 줄 아는 인력이 시장에 필요하기 때문입니다. 필요에 의해 직업이 만들어지는 거지, 직업에 의해 필요가 만들어지는 것은 아니니깐요. 필요를 충분히 소화해내지 못하는 시장구조 이기에 새로운 개념의 인력들은 아직 많이 필요합니다. 딱히 "난 개발자~", "난 디자이너~", "난 기획자~" 하면서 땅따먹기, 편가르기 하듯이 직업을 정할 필요는 없을겁니다. 물론… 수요가 딱히 고정되어 있지 않기 때문에 굉장히 가시밭길이 되긴 하지만요… ㅜ ㄴ ㅜ (젠장… 내 인생은 어디로 가는가…)

출처: ssen님의 레시피

http://ssen.name/zb/2325