Dragonkun in Tistory

redmines 는 주말쯤에 시간이 날 때, 다뤄보기로 하고 이번엔 Flex에 대한 생각을 정리하려 합니다.
왜 갑자기 Flex 냐 하면.. 제가 새 직장을 얻게 되어서 앞으로 Flex를 가지고 벌어 먹고 살게 되기 때문이죠.

이번 주는 실제 Flex를 다루지는 않았고, 약간 실제 프로젝트와는 거리가 있는
일종의 수습 기간 중 테스트로서 차후에 쓰이게 될 지도 모르는 커스텀 ssh/sftp 서버를 만들었습니다.
(Python, Paramiko 라이브러리로 제작했는데 이것도 기회가 되면 블로그에 정리해야 겠습니다.)
생각보다 일찍 완성이 되어서 Flex 공부하는 셈 치고, 이거저것 만져보고 rails 와 붙여보는 작업을 해 봤습니다.

퇴근 시간 전까지 잠깐 시간내서 만들어 본거라 거의 맛만 본 수준인데,
만들어 본 어플리케이션은 간단한 게시판의 형태로 글 쓰기, 수정, 삭제 까지는 못 만들었고;;
그냥 리스트만 가져와서 화면에 출력해 주는 수준이었습니다.

서버 사이드로는 간단하게 Rails 프로젝트가 REST Web Service 를 서비스하고 있고,
클라이언트 사이드에서 Flex가 작동하여 HTTP Request 를 이용해서 XML 형태로 데이터를 받아오고
리스트를 구성해 화면에 출력해 주는 형태로 작동하게 했습니다.
Flex 에서 기본으로 제공하는 디자인은 깔끔했고 애니메이션 효과도 훌륭했고,
액션 스크립트의 웹 서비스 클라이언트는 REST 도 잘 지원되고 Ajax와 같이 귀찮은 작업도 거의 없고..
오~ 이만하면 훌륭합니다.  조금 반응이 느리고 무거워 보인다는 단점 외에는 별다른 흠 잡을데가 없더군요.

하지만 아무리 Flex 의 기능이 훌륭하고 멋지다고 해도, 어떻게 보면 결국은 고품질의 swf 를 찍어내기 위한 거대한 프레임워크일 수 밖에 없더군요.
완성되어 나와진 html 에는 swf를 embed 하는 태그와 왜 있는지 잘 모르겠는 iframe 뿐이고..
과연 이것이 웹을 올바른 방향으로 이끄는 것인가에 대한 의문이 들더군요.

좀 쓰잘데기는 없지만 웹이 나아가야할 올바른 방향은 무엇인가에 대한 이야기는 예전에도 생각했던 적이 있습니다.
초창기의 웹은 분명 연결된 문서의 형태였습니다.  하지만 지금의 웹은 그러한 모습이라고는 보기 힘듭니다.
블로그와 위키 정도만이 그 형태를 유지할 뿐 거의 어플리케이션의 형태로 가고 있다고 보고 있습니다.
Ajax 역시 그 움직임을 가속화 시키기도 했구요.

그렇다고 웹이 어플리케이션으로 가게 되는 것인가 라고 생각을 해보면 그것 또한 끔찍한 모습입니다.
화려하고 동적인 페이지를 위해서 실제 얻고자 하는 정보와 무관한 큰 크기의 리소스들(Ajax 에는 큰 덩치의 JS 프레임워크, Flex 등의 swf 파일)을 받아야 한다니..
사실 모뎀 말고, 초고속 인터넷이 등장한 후 분명 통신의 속도도 빨라졌고, 사용하는 컴퓨터의 사양도 좋아졌지만,
불필요하게 웹의 덩치도 그것에 맞추어져 예전이나 지금이나 웹의 속도는 별로 빨라지지 않았다는 느낌도 듭니다.
그것 뿐이겠습니까.. 만약 Flex나 Silverlight 런타임 플러그인 위에서 돌아가게되는 구글을 통해 내용 검색을 할 수도 없게 되겠지요. 그렇게 되면 점차 시맨틱 웹이라는 것의 의미는 퇴색되게 되겠지요.

하지만, 그렇다고 해서 연결된 문서의 형태로 웹이 남아있어야 한다고 생각하지는 않습니다.
확실히 웹이 어플리케이션화 하면서 재미가 있었지고 사람들의 생활을 이롭게 한 것은 사실이니까요.

그래서 근본적인 취지에 맞게 웹 본래의 장점을 살려보자고 등장하던 것이 REST 였지만...
Flex 에서 REST 서비스를 이용하는 방식을 보면, 글쎄요.. 정말 REST가 답인가 하는 생각마저 들기도 합니다.

웹은 확실히 가장 성공한 TCP/IP 어플리케이션이지만..
시맨틱 웹, 웹 2.0 등등의 수식어에 여기저기 휘둘리는 웹의 모습이 왠지 안쓰러워 보입니다.

무슨 글을 쓰고 있는 지도 잘 모르겠습니다.  아주 예전에 있었던 논쟁글 몇 개 링크하고 마무리 짓습니다.
김국현 씨와 윤석찬 씨는 제가 매우 존경하는 분들입니다.
존경하는 분들의 논쟁을 보면 정말.. 즐겁기 그지 없습니다. :)

차세대 웹은 브라우저를 초월하여
반론 : 차세대 웹은 브라우저를 초월하여
반론에 대한 기록 : 차세대 웹은 브라우저를 초월하여

요즘의 웹 사이트들은 점점 Ajax 의 사용추세가 늘어나고 있습니다.
하지만 사실 Ajax 에는 치명적인 단점이 있습니다.
바로 웹 접근성이죠.

Ajax 가 처음 등장했을 때 문제로 제기된 큰 문제가 몇가지가 있었는데..
그 중 하나는 뒤로 가기 버튼이었고, 다른 하나가 이 접근성에 해당하는 문제였습니다.

물론 모든 Ajax가 웹 접근성을 해치는 것은 아닙니다.
Ajax 를 사용하더라도 접근성을 해치지 않는 방법들이 여럿 고안되었으니까요.
하지만 국내에서 사용되고 있는 Ajax 의 대부분은 Javascript(또는 기타 클라이언트 스크립트)에만 의존하는 경향이 있습니다.

<a href="#" onclick="sampleFunction();"> 는 이제 그만.

그 중 가장 간단히 생각할 수 있는 것이 <a href="#" onclick="javascript:"> 등으로 시작하는 코드입니다.
하지만, Javascript 가 제대로 동작할 수 없는 환경에선 무용지물입니다. 그럼 어떻게 해야하는가..

<a href="대체 URL" onclick="return !sampleFunction();">

여기서 포인트는 두 개입니다. 대체 URL 과 sampleFunction() 앞의 ! 죠.
대체 URL 은 말 그대로 Javascript 가 동작하지 않을 때 이동해야할 페이지입니다.
물론 해당 동작에 대한 대체 페이지가 마련되어야 겠죠.

그러면 클릭할 때, onclick 이 실행되는게 아니라 대체 URL로 이동해버리는 것이 아니냐..라고 생각하시는 분들이 계실텐데..
!(느낌표) 는 그것을 막기 위해 고려된 것입니다.
여기서 조건은 sampleFuntion 은 xmlHTTPRequest 가 성공하면 True, 실패하면 False 를 리턴하도록 구현되어야합니다.

만약 sampleFunction 이 동작을 성공하면 True가 리턴되고, <a> 태그의 동작은 return false; 가 되어 실제로 페이지 이동을 하지않게 됩니다.