2 Results for '자바스크립트'

  1. 2009.01.28 온라인 자바스크립트 압축기 javascriptcompressor.com (4)
  2. 2008.02.08 실버라이트의 딜레마 (9)
이런 사이트가 너무 좋아 >_<
http://javascriptcompressor.com/

뭐, 아시는 분은 이미 다 아실거에요.
불필요하게 긴 자바스크립트를 최소화 시키는 툴인데요. 가장 좋은 건 온라인에서 바로 동작한다는 점.
요컨대 주석이랑 공백 뭐뭐 해서 40kb나 하던 스크립트가 10kb로 줄었어요 짠! 이런거죠.
저작자 표시 동일 조건 변경 허락
신고
Posted by gongdo

딜레마의 시작
실버라이트는 풍부한 사용자 경험을 제공하는 RIA를 위해 등장하였고, 특히 닷넷 프레임워크의 경험에 기반한 개발환경은 분명 닷넷 개발자들에게는 대단히 매력적인 것이었죠. 저 또한 실버라이트가 C#으로 개발 될 수 있다는 점 특히, 클라이언트 프로그래밍이란 점에서 굉장히 큰 매력을 느꼈고 지금까지 오게 되었어요.

실버라이트로 화려하고 풍부하고 멋진 RIA를 만들기 위해서는 어떤게 중요할까요? 한가지 분명한 것은 실버라이트의 개발 기반이 되는 닷넷 프레임워크가 제공하는 강력하고 편리한 개발환경이라던가 XAML로 구성되는 훌륭한 아키텍처상의 장점만이 전부는 아니라는 점이에요. 풍부하고 화려하고 멋진 RIA들은 대체로 비주얼, 사운드 및 사용자와의 인터랙션과 같은 감성적인 면에 집중되어 있고 이런 것들은 애플리케이션 개발의 효율성이나 재사용성과 같은 개발자적인 관점에 비해서 훨씬 더 중요한 것 같아요.

지금까지 제가 경험했던 런칭된-혹은 런칭 예정중인-실버라이트 애플리케이션들을 돌아봤을 때, RIA는 기존의 플래시나 웹 디자인에 대한 풍부한 경험이 있는 디자이너가 만드는 것이 훨씬 더 좋은 퀄리티를 보여준다는 것은 확실해요. 구체적으로, SBS의 NView는 탑레벨 디자인 에이전시에서 디자인되었고, MNet TVDeep은 MNet 자체의 디자이너가 전체적인 룩과 인터랙션을 디자인했어요. MNet의 방송 프로그램들을 보면 확실히 다른 풍부한 비주얼들을 보여주죠. 또 지금 개발중인 마이크로소프트의 모 사이트는 전문 탑레벨 디자인 에이전시에서 심지어 인터랙션 코드 개발까지 전담하고 있죠. 그런데, 이들 디자이너, 플래셔들은 대체로 C#이나 닷넷 프레임워크에 관심이 없거나, 익숙치 않거나 혹은 아예 필요치 않았어요. 바로 여기에서 실버라이트의 딜레마가 시작되는거죠.

애증의 JavaScript
자바스크립트를 전문적으로 그리고 심층적으로 다루는 분들은 자바스크립트가 흔히 웹 개발에서 떠올리는 alert따위로 끝나는게 아닌 매우 개방적이고 자유도가 높은 언어라는 것에 찬성할 거에요. 그러나, 자바스크립트의 개방성과 자유도는 오히려 복잡한 애플리케이션의 개발에는 적합하지 않다고 생각해요. 자바스크립트는 인터프리팅 방식의 언어이고 이런 언어는 말 그대로 누구나 쉽게 사용할 수 있는 스크립팅에 알맞지 정교한 사용자 컨트롤이나 혹은 복잡한 데이터 처리 및 연산에는 불리하다는 거죠. 물론 자바스크립트의 고수들은 저의 이런 주장에 명확한 이유로 반대를 할 수 있을 거에요. 하지만, 개발자에게 있어서 단지 변수명을 잘못 썼다고 해서 런타임이 되어서야 문제점을 발견할 수 있는 언어는 결코 생산적이지 못하다고 단언할 수 있어요.

어쨌든, 기존의 RIA 시장은 아시다시피 플래시가 독식해왔고 플래시는 웹에서 벡터 그래픽과 애니메이션을 구현하기 위한 일종의 '그래픽 툴'로 시작했죠. 그러다가 플래시에 하나둘씩 사용자의 인터랙션에 반응할 수 있는 기능들이 추가되고 사용자들은 점점 더 많은 기능과 인터랙션을 요구했고 급기야 액션 스크립트라는 자바스크립트-정확히는 ECMAScript-를 기반으로 한 언어까지 만들어지게 되었죠. 이게 무려 10년도 넘게 이어진 이야기에요. 제 기억엔 2000~2001년 무렵이었던 걸로 생각되는데요, 액션 스크립트가 등장하면서 디자이너가 해야 할지 개발자가 해야 할지에 대한 혼란이 대단히 컸었죠. 마치 지금의 실버라이트 처럼 말이에요!

중요한 점은 단순한 그래픽 디자인에서 보다 복잡한 인터랙션을 포함하는 플래시 애플리케이션을 만들기 위해 '플래셔'는 좀 더 세분화 되었고 특히 액션 스크립트를 전문적으로 다루는 디자이너 혹은 개발자가 나왔죠. 이들이 지금의 플래시와 스크립트에 적응하고 익숙해지는데 얼마나 오래 걸렸을까요? 과연 이들이 지금까지 힘들게 익혀왔던 기반인 자바스크립트를 쉽게 버릴 수 있을까요?

간단하죠. 아니에요.

저는 실버라이트가 C#을 사용할 수 있다는 점이 실버라이트의 가장 큰 매력중 하나라고 생각했지만 아이러니컬하게도 실버라이트 덕분에 자바스크립트를  더욱 더 깊게 다룰 수 있게 되었죠. 왜냐구요? 현재 실버라이트 닷넷 버전(1.1 alpha)은 오직 개발 테스트 및 평가를 위해서만 제공되고 애플리케이션으로 배포할 수 있는 것은 오직 자바스크립트만을 지원하는 1.0 버전이기 때문이죠.

한편으로는 디자이너 내지는 플래셔들에게 있어서 C#보다는 자바스크립트가 일단 눈에 더 익숙하고 거부감이 덜했을 거에요. 아마도 실버라이트 1.0은 '어디 한번 해볼까?' 정도로 다가올 수 있었을 것이고 심지어 비주얼 스튜디오 없이 익숙한 에디트 플러스(!!!)로도 척척 만들어 낼 수 있었죠. 비주얼 스튜디오 중독자인 저로선 정말이지 경이로운 능력이었어요. (어떻게 디버그 모드도 없는 에디터 따위로 애플리케이션을 만든단 말인가!)

기존의 협업 경험으로 봤을 때 디자인적인 감성이 우선되는 애플리케이션은 그래픽 오브젝트는 제외하더라도 애니메이션과 인터랙션을 제어하는 코드는 디자이너(플래시의 액션 스크립터)가 담당하는 것이 디자인 포인트를 저해하지 않는 일반적인 방식이라고 생각돼요. 그리고, 지금 당장 화려하고 동적인 RIA를 만들어 낼 수 있는건 실버라이트로 RIA를 시작한 개발자들 보다는 보다 풍부한 경험과 감성을 가지고 있는 디자이너들이라고 말 할 수 있을 거에요. 이 디자이너들에게 당장 C#을 시작하라는 것은 단지 강요가 될 뿐일 수도 있을 것 같다는 생각이 들어요. 그런 의미에서 실버라이트가 개발 언어로서는 골치아플 뿐인 자바스크립트를 지원하는 것은 올바른 선택이었다고 생각하지만 자바스크립트는 실버라이트에게 있어서 하나의 딜레마가 되죠.

Designers! Designers! Designers!
사용자의 입장에서, 애플리케이션이 어떤 기술로 만들어졌느냐는 떠다니는 먼지 한 개 만큼도 중요하지 않죠. RIA에서 가장 중요한 것은 결국 사용자에게 어떻게 보여지고 어떻게 느껴지는가가 아닐까요? 때로는 그것을 위해 깊은 기술적인 배경이 있을 수도 있지만 그런 것들은 다른 영역으로 분리될 수 있고 많은 경우 RIA는 결국 데이터와 그것을 보여줄 비주얼로 압축될 수 있을거에요.

현재 실버라이트의 비주얼은 주로 미디어 경험과 관련된 사항이 많고 그외의 부분은 사실상 딱히 대단해 보이는게 없어요. Tafiti의 Tree View는 글쎄요, 저에겐 기술적으로도 감성적으로도 잘 와닿지 않는 서비스였어요. 물론 Logi-craft의 사례처럼 비즈니스적으로 또한 개발자의 관점에서 멋진 사례도 있지만 비주얼적으로 한정해보자면 말이에요.

RIA가 사용자에게 주는 인상은 비주얼적인, 감성적인 측면이 가장 크고 이것을 표현하는 디자이너가 무엇보다 중요한 것 같아요. 그렇다면, 실버라이트는 과연 디자이너에게 어떤 비전을 보여주고 있을까요? 어떤 표현의 자유를 보장하고 있을까요? 저는 XAML에서 이 답을 얘기하고 싶지만, XAML을 디자인하는 툴 자체의 미숙함은 이 문제에 확실한 답을 하는 것을 주저하게 만들어요. 디자인 툴의 사용성은 그 기능은 접어두고서라도 반드시 개선되어야 할거에요.

또 실버라이트의 발전 방향은 주로 닷넷 프레임워크에 기반해 있기 때문에 많은 향상과 기능의 추가가 예고되어 있는 2.0의 경우 자바스크립트 지원에 관한 얘기는 아직 들어보지 못했어요. 과연 기존의 디자이너들이 실버라이트의 기능만을 보고 실버라이트를 선택하게 될지는 의문이에요. 가능한 1.0과 같이 자바스크립트를 함께 지원하는 것이 기존 디자이너들에게는 더 좋은 선택이 될 거에요. 물론 이 선택은 위에서 얘기한 딜레마의 원인이 되겠지만요.

딜레마의 해결 방법을 찾아서
한 가지는 협업의 포인트를 찾는 것, 디자이너가 닷넷 프레임워크 언어에 익숙하지 않더라도 닷넷 개발자와 함께 멋진 애플리케이션을 만들어 내는 것이죠. 현실적으로 지금 당장 디자이너가 닷넷 프레임워크를 익히고 C#으로 코드를 짠다는 것은 어려울 거에요. 그렇다면 어떻게 하면 디자이너와의 간극을 줄이면서 디자이너가 표현하고자 하는 바를 잘 나타낼 수 있을지, 어떻게 하면 닷넷을 어렵지 않게 접근할 수 있을 지 또는, 어떻게 하면 디자이너가 사용해야 하는 코드를 최소한으로 줄이면서 표현할 수 있게 할 수 있을지...에 대한 답을 찾아야겠죠. 아직은 답을 찾지 못했지만 할 수 있을 거라고 생각해요.

또 한 가지는 디자이너가 원하는 기능에 귀를 기울이는 것이죠. 대체로 단순한 그래픽의 표현은 Path, 이미지의 조합으로 얼마든지 할 수 있어서 큰 차이가 나지 않지만, 타이포 그라피의 표현력이나 이미지 프로세싱, 애니메이션의 성능 같은 것들은 상당히 중요할 것 같아요. 물론 디자인 툴의 향상도 아주 중요한 문제겠고요.

마지막으로 압도적으로 멋진 기능의 지원이 있겠죠. 지금도 실버라이트가 제공하는 미디어 기능은 상당히 뛰어나고 현재 상용으로 사용되는 실버라이트 애플리케이션의 대부분이 미디어에 집중되어 있는 것을 생각해보면 예를 들어 뛰어난 이미지 프로세싱 기능이 추가된다면 그 분야로도 더 많은 디자이너가 관심을 가질 수 있을 거에요.


쓰다보니 상당히 길어졌네요. 혹시 다른 종류의 고민이나 문제점들 또 해결 방법들에 대해서 피드백을 해주시면 많은 도움이 될거에요 :) 요즘 블로그에 피드백이 적네요. 피드백 좀 주시죠~ 굽실굽실.

신고
Posted by gongdo


티스토리 툴바