Ajax 유명한지는 좀 되었지만, 최근 Ajax 기반의 각종 라이브러리들(Prototype, Dojo, Mochikit, jQuery, YUI 등)이 활발히 개발되면서 또 다른 전성기를 맞고 있는 것 같다. 그리고 Ajax하면 항상 하는 말이 크로스 플랫폼, 크로스 브라우저 등등 하는 개념이다. 그간 프로그래밍 언어만 보느라 웹 프로그래밍에 별로 관심이 없었는데, 시간 내서 Ajax와 웹 프로그래밍 개념들을 좀 공부해보니 뭔가 이상하다. Ajax 이거 별로 매력적이지 않다.


크로스 브라우저? (혹은 크로스 플랫폼)

표준인 HTML(혹은 XHTML)과 CSS, 자바스크립트만 사용하면 어떤 플랫폼, 브라우저에서든 동작하지는 프로그램을 만들 수 있을까? 결론부터 말하면 만들 수 있다. 하지만 절대 쉽게 만들지 못한다.

일단 Ajax의 근간이 되는 XMLHttpRequest부터 심상치 않다. IE는 ActiveX 컨트롤이고 다른 브라우저는 이 기능만 훔쳐다가 네이티브 오브젝트로 만들어놨다. 결국 브라우저에 맞춰서 if else... 구문이 잔뜩 들어박혀야 한다. 그래도 XMLHttpRequest야 공식적으로 표준화된 적도 없고 그냥 어쩌다 보니 많이 쓰인 API인 셈이니 일단 넘어가자.

DOM은 사정이 어떨까? DOM이라 하면 W3C가 적극 밀어주는 표준 API가 아닌가! 하지만 브라우저 별로 또 구현을 조금씩 다르게 해놨다. 특히 IE가 말썽인데, 항상 표준대로 구현하지 아니하고 프로퍼티 이름을 한 두 개씩 바꿔서 클라이언트 코드에 if else... 를 박지 아니할 수 없게 한다. 또 DOM 레벨 2 이벤트 모델 표준 제정에 직접 참여한 MS가 왜 DOM 2 이벤트 모델을 제공 안 한단 말인가. 표준 회의에는 왜 간 건지 의심스럽다.

JavaScript가 너무 다양한 버전으로 존재하는 것도 문제다. 현재 JavaScript 1.5 기반이면 거의 통하기는 한다. (구버전 IE는 여기서조차 Array의 중요 메서드 몇 개를 빼먹었다.) 하지만 Firefox가 JavaScript 1.6, 1.7로 올리고 일부 Array API를 네이티브로 내려서 속도 향상을 시도해도, 크로스 브라우저에 맞추려면 이런 기능을 적극 활용하기가 힘들다.

CSS도 브라우저 별로 뭐는 되고, 뭐는 안 되고 이런 게 너무 많다. 이른바 방탄웹으로 유명한 책이 처음 하는 얘기가 각 브라우저 CSS 처리기의 버그를 이용해 여러 브라우저에서 동일한 화면을 만들어내는 데 있다는 걸 보고 충격 먹었다. 버그에 의존하는 코드라니, 정말 고통스러운 개발 환경이다.

여기까지만 보면 UNIX와 Windows, MacOS X 등에서 컴파일되기 위해 #ifdef #endif를 때려 박은 C 언어 라이브러리랑 별로 차이가 없어 보인다. C 언어는 안 되면 아예 컴파일을 못하기라도 하는데, 웹 프로그래밍은 결국 같은 바탕에서 출발해서 조금씩 미묘하게 다른지라 잘될 것 같기도 하고 안 될 것 같기도 한 애매한 상태이다.

결국은 이런 플랫폼(혹은 브라우저)의 차이를 잘 감춰주는 Ajax 라이브러리를 이용하는 방법 밖에 없다. 현재 Ajax라이브러리의 춘추전국시대(?)처럼 보이는데, 정말 쓸만한 라이브러리 몇 개로 통폐합 될 때까지는 어떤 라이브러리를 골라야 할지도 고통이 따를 게다.

웹프로그래밍이라는 거 실제로 필요한 로직을 만드는 것보다 사소하게 신경 써야 할 일이 너무 많다. Frederick P. Brooks의 말을 빌리자면 아직까지 Accidental Complexity가 너무 심하다. 사실 데스크톱에서 RAD 툴로 어플리케이션 만들어 본 사람이라면 지금의 웹프로그래밍은 정말 고통스러운 거 아닐까? 화려한 Ajax라고 해봐야 결국 데이터 조금 주고 받고 화면 이쁘게 꾸미는 것 밖에 없지 않은가? Ajax 라이브러리가 발전하고 예전에는 안 되던 각종 효과를 보여주는 것만으로 놀라는 것도 이해하지만, 실상 웹이랑 담쌓고 데스크톱 개발자가 들어와서 보면 정말 웹프로그래밍은 프로그램 개발에 관해서는 기술적으로 퇴보한 셈이다.

원래 큰 기술적인 도약이 있기 전에는 한 단계 퇴보하는 게 IT 역사의 법칙이긴 하다. 예를 들어, 과거 TP Monitor라고 해서 비행기 예약시스템 등에 도입되어 사용된 트랜잭션 시스템은 이미 기술적으로 성숙해 있었는데, 인터넷 초기에 나온 WAS 서버들은 트랜잭션 처리 면에서는 오히려 기술적으로 퇴보했다. 인터넷이 크게 성장하면서 지금에 와서는 예전 수준을 넘어섰지만 플랫폼의 변경과 같은 큰 기술적인 변화 속에서는 다른 기술이 순간적으로 퇴보하는 것은 사실이다.

지금은 웹 프로그래밍이라는 것도 어쩌면 잔뜩 웅크린 상태에서 다음 도약을 노리는 게 아닐까 싶다. 하지만 경계해야 할 점은, 멋진 개발 프레임워크와 도구가 갖추어지고 나면, 지금 Ajax 프로그래머의 노하우는 한줌의 먼지가 될지도 모른다는 사실이다.

Firefox Extension 기능을 시험해 볼 겸 간단히 네이버 영어 사전 애드온을 만들어 보았습니다.

호호딕 0.1

마우스로 단어를 두번 클릭해주면 네이버 Open API를 사용해서 새창으로 단어 뜻을 찾아주는 간단한 프로그램입니다. '도구-부가기능-HohoDic설정'에 가셔서 발급받은 네이버 Open API 키를 넣어주시면 됩니다. 디폴트로 제 키가 들어있습니다. 프로그램을 시작하면 오른쪽 아래 상태바에 사전 아이콘이 나타나는데, 처음에는 회색으로 되어 있습니다. 한 번 클릭해주면 파란색으로 돌아오는데, 이때가 활성화된 모드입니다. 파란색인 상태에서 영어 단어를 고르면 팝업이 떠서 단어의 뜻을 알 수 있습니다. 기능이 필요 없으면 사전 아이콘을 한 번 더 눌러서 끄면 됩니다.




뭐 어디 공개하기는 부끄러운 프로그램이라 제 블로그에만 올려둡니다.

이거 만들었다는 얘기를 하고 싶은 게 아니고, Firefox Extension 제작의 어려움(?)을 토로하고자 합니다. 결론부터 말하면 생각보다 쉽지 않더군요. 일단 모질라 사이트가 언뜻 보면 방대한 문서가 있는 것 같은데, 처음 접하는 사람이 체계적으로 접근하기가 어려웠습니다. API 문서도 생각보다 정리가 안 되어 있어서 찾아보기가 상당히 어렵더군요.

Firefox를 비롯한 Mozilla 소프트웨어들은 전부 XPCOM이라는 컴포넌트 기술에 기반하고 있는데, 이 컴포넌트를 자바스크립트에서 불러 쓰는 것도 상당히 귀찮은 일이더군요. jsLib이라고 이걸 좀 간단하게 만들고자 노력한 라이브러리도 있지만 많이 부족해 보였고요.

또 스크립트 언어 특유의 '타이핑 실수'로 인한 버그를 잡아내는 게 무척 힘들었습니다. 뭔가 사소한 이유로 안 되는 것 같은데 뭐가 문제인지 몰라서 한참을 헤매게 되더군요. 물론 콘솔에 오류를 찍게 할 수도 있고 자바스크립트 디버거들도 있지만 익숙하지 않아서 그런지...

XUL을 쓰던 안 쓰던 UI 같은 건 WYSWYG으로 딱딱 보이는 게 좋은데라는 아쉬움도 들었고요. 애드온 개발을 위한 좋은 개발 환경 셋팅에 대해서 잘 아시는 분 도움을 부탁드립니다.

야후 위젯(Yahoo Widget!)과 애플의 대시보드(Dashboard), 윈도 비스타의 가젯(gadget) 등 위젯 서비스가 줄을 이으면서, 국내에서도 네이버, 미니플, 다음(나온 순서대로) 등이 위젯 서비스를 시작했다. 주로 날씨, 달력, 메모, 메신저, 시계, 증권 등 위젯하면 생각나는 프로그램이 주종이다. 네이버나 다음은 자사가 가지고 있는 메일, 까페, 검색 등의 서비스를 추가로 제공하기도 한다.

국내 위젯 서비스를 둘러보니 외국 위젯 서비스의 미투(me too) 서비스인 것은 분명한데, 한 가지 큰 차이가 있었다. 외국 위젯 서비스들은 사용하기 편한 여러 위젯을 제공하는 동시에, 사용자들이 필요한 위젯을 쉽게 만들 수 있도록 플랫폼(API+개발도구)를 제공한다. 반면에 국내 위젯 서비스는 엔진을 설치한 후에 자사가 제공하는 위젯을 설치할 수만 있을 뿐 사용자 위젯을 추가적으로 만들 수 있는 방법을 제공하지 않고 있다.

네이버나 다음의 경우 홈페이지를 둘러봐도 향후 위젯 제작을 오픈하겠다는 말이 없었다. 반면에 미니플은 최근에 3.0 오픈베타를 발표하면서 앞으로 ‘유무선 통합 플랫폼’을 추구한다고 한다. 즉, 미니플을 PC, PDA, WIBRO, IPTV 단말기 등 여러 플랫폼에 집어 넣는다는 말이다. 하지만 향후 공개하겠다는 말이 있을 뿐 플래시 기반이라는 사실 외에는 그 내부 구조가 어떻게 되어있고 어떤 API를 제공하겠다는 건지는 알 수가 없었다.

네이버나 다음이 내부적으로 어떤 기술 사용했는지는 모르겠지만, 야후 위젯이나 대시 보드, 오페라 위젯 등은 대부분 유사한 기술에 바탕을 두고 있다. 보통 위젯은 다음 세 가지 요소로 구성된다.

1) XML이나 HTML 형식으로 UI의 구조를 정의
2) UI에 액션을 줄 수 있는 스크립트(주로 자바스크립트)
3) UI에 멋진 모양을 낼 수 있는 스킨(보통 CSS)

예를 들어, 오페라 위젯은 HTML에 자바스크립트, CSS를 사용하여 일반 웹프로그래밍과 가장 유사한 환경을 제공한다. 다른 위젯들도 HTML 대신에 UI 구조를 위해 자체적으로 정의한 XML을 사용할 뿐 위젯 어플리케이션을 구성하는 근본적인 기술은 상당히 유사하다. (이 부분은 UI를 위해 XUL을 사용하는 Firefox의 Extension도 마찬가지다.)

국내 위젯사들이 이 정도나마 플랫폼 형태를 갖추고 있는지, 아니면 정말 위젯 하나 하나를 정성스러운 손길로 수제작하는지는 알 수가 없다. 물론 수제작이 나쁘다는 건 아니다. 그건 어디까지나 회사의 전략이니깐. 사실 국내에만 한정 지을 경우 API를 오픈한다고 해서 얼마나 많은 개발자들이 위젯을 개발해 줄지는 의문이기도 하다. ‘플랫폼’으로 절대적인 기술 우위를 점하지 않는 한 위젯 제공사들은 플랫폼보다는 컨텐츠로서 위젯에 더 가치를 두는지도 모르겠고…