 |
|
XUL이란?
XUL은 XML User Interface Language의 약어다. XML이므로 선언적 언어(Declarative language)다. XUL은 풍부한 UI 위젯을 제공하여 개발 속력을 높여준다. 플랫폼에 무관한 언어로, 리눅스에서 짠 XUL 프로그램은 윈도우에서도 문제 없이 돌아간다. XUL은 자바스크립트, CSS(Cascading StyleSheet) 등과 같은 웹 기술을 크게 활용한다. 심지어 XUL 프로그램에다 HTML을 곧바로 넣어도 된다. 여기서는 XUL을 소개하고, 개발 플랫폼으로서 XML이 제공하는 매력도 살펴본다.
간단한 XUL 역사
XUL은 넷스케이프나 모질라 재단과 같은 의미다. 초창기부터 넷스케이프 브라우저는 플랫폼에 독립적인 브라우저를 표방했다. 그래서 OS와 관련한 레이아웃과 제어 위젯을 추상화하여 감추는 UI 프레임워크가 필요했으며, 추상화한 요소와 실제 OS 프로세스 사이에 네트워크, 파일 입출력 등과 같은 통신을 수행할 방법이 필요했다. 단순히 플랫폼에 독립적인 응용 프로그램을 작성할 방법뿐만 아니라 HTML과 웹 요소를 함께 사용할 방법도 필요했다. 이러한 의도에서 설계한 프레임워크가 바로 XPFE(Cross-Platform Front End)이다. 넷스케이프 커뮤니케이터를 포함하여 (전자메일과 채팅 클라이언트 등) 넷스케이프 커뮤니케이터 도구도 XPFE 프레임워크에서 구현되었다.
넷스케이프 사가 흥망한 내막을 잘 알지도 모르겠다. 1995년에 있었던 넷스케이프 사 IPO는 소위 닷컴 거품을 촉발하는 계기가 되었다. 1998년 즈음에 이르자 넷스케이프 사는 재정적으로 난관에 몰렸으나 기술적으로 상당한 성과를 이뤄냈다. 이러한 기술적인 성과 한가운데에 모질라 프로젝트가 있었다. 모질라 프로젝트는 오픈 소스 라이선스를 따라 넷스케이프 커뮤니케이터 4.0 코드를 공개하면서 탄생했다. 넷스케이프 커뮤니케이터 4.0 코드 기반은 개발하고 보수하기가 어렵다고 판명났으나, 다행스럽게도 기존 커뮤니케이터 코드를 공개한 이후에 넷스케이프 사는 다음으로 개발한 레이아웃 엔진 코드도 공개하기로 결정했다. 바로 이 브라우저 엔진이 게코(Gecko)가 되었다. 게코의 주요한 특징 중 하나가 선언적 XML 기반 UI 언어, 즉 XUL을 지원한다는 점이었다.
XUL: XML, JavaScript, CSS
XUL은 게코 엔진용으로 만들어진 독점 UI 언어다. 하지만 XML, 자바스크립트, CSS 등 표준 기술에 기반을 둔 덕택에 게코 기반 웹 브라우저 개발자 외에도 많은 개발자들이 관심을 보여왔다.
XUL은 XML 언어다. 즉, 문법이 간단하므로 읽어서 분석하기 쉽다. 또한 HTML과 여러모로 비슷해 웹 개발자들이 익히기도 쉽다. 심지어 XUL 위젯에 XHTML 요소를 섞어도 무방하다. 많은 측면에서 XUL은 XML이 UI 언어로 적합하다는 사실을 증명했다. 어도비 플렉스 프레임워크에서 사용하는 UI 언어인 MXML, 마이크로소프트 .NET 3.0과 WPF(Windows Presentation foundation)에서 사용하는 UI 언어인 XAML 등 이미 비슷한 언어가 존재한다는 사실 역시 이를 뒷받침한다.
물론, 선언적 프로그래밍 언어에는 한계가 있다. 때로는 명령형 프로그래밍 언어(Imperative programming language) 기능도 필요하다. 그래서 XUL은 (새 언어를 고안하거나 새 XML 문법을 추가하는 대신) 자바스크립트를 지원한다. 지금까지 자바스크립트는 프로그래밍 언어로 합당한 대접을 못받았다. 그저 비전문가 프로그래머가 집적거리는 언어, 브라우저 꼼수가 가득한 언어로 여겨졌다. 그러나 자바스크립트는 웹 응용 프로그램 개발에 근간이 된 강력한 언어다. Ajax에서 “J”는 바로 자바스크립트를 뜻한다. 자바스크립트는 절차적 언어를 좋아하는 개발자를 위해 객체 지향 프로그래밍(Object-Oriented Programming)을 지원하는 동시에 함수 프로그래밍(Functional Programming)도 지원한다. XUL은 데스크톱 프로그래밍 언어로 자바스크립트를 선봉에 세우며, 자바스크립트 DOM에 크게 의존한다. 어쨌거나 XUL은 XML에 기반하는 언어다.
XUL을 떠받치는 또 다른 기둥은 CSS다. 오늘날 CSS는 웹 페이지 모양새를 다듬는 ‘사실상 표준’으로 자리잡았다. “계단식(cascading)”이라는 특성으로 인해 (즉, 객체에 적용한 스타일은 자식 객체에 모두 적용되며 동시에 자식 객체에서 언제든지 스타일을 재정의할 수 있다는 특성으로 인해) CSS는 강력함과 유연함을 제공한다. 따라서 XUL 역시 이러한 강력함과 유연함을 데스크톱 응용 프로그램에 제공한다.
자바스크립트와 CSS는 브라우저마다 동작 방식이 다르다는 이유로 악명이 높다. 자바스크립트에서 브라우저 유형과 버전을 점검하는 코드를 찾아보기는 어렵지 않다. 브라우저 스니핑(sniffing)이라고도 하는 이 방식을 사용하여 프로그래머들은 브라우저 유형과 버전에 따라 다르게 동작하는 코드를 구현한다. 마찬가지로 CSS에서도 조건부 스타일을 많이 사용한다. 웹 개발에 어느 정도 경험이 있다면 이러한 브라우저 꼼수로 골치깨나 앓았으리라. 만약 지금까지 그래왔다면 XUL을 아주 좋아하게 되리라 생각한다. 왜? XUL에서는 브라우저 하나만 걱정하면 그만이다. 모두가 파이어폭스를 사용하는 세상에서 웹 응용 프로그램을 구현한다고 상상해보라.
XPCOM과 XBL
이미 XUL에 익숙하다면 내가 XUL에서 중요한 특징 두 가지인 XPCOM과 XBM을 빼먹었다고 염려할지도 모르겠다. 걱정은 접어두기 바란다. 우선 XPCOM과 XBM을 간략히 소개하고 나중에 실제로 사용할 계획이므로 여기서는 XUL로 개발한 응용 프로그램을 XPCOM과 XBL로 개선하는 방법에 초점을 맞춘다. 먼저, XPCOM을 살펴보자.
XPCOM(Cross Platform Component Model)은 COBRA나 마이크로소프트 COM과 비슷하다. XPCOM에서는 IDL(Interface Definition Language) 모델을 이용하여 코드 라이브러리를 표현한다(자바(Java™)나 C# 코드에서는 인터페이스에 해당하며, 웹 서비스에서는 WSDL에 해당한다고 하겠다). 따라서 다른 언어로 구현한 프로그램에서도 XPConnect 해석기를 이용하여 코드 라이브러리를 참조할 수 있다. 예를 들어, 게코 엔진이 제공하는 기능 거의 전부는 XPCOM으로 노출되어 있다. 엔진 자체는 C++로 작성되었지만, XPCOM 덕택에 (자바스크립트, C++, 펄, 파이썬 등) XPCOM을 지원하는 어느 언어에서나 엔진 라이브러리를 사용할 수 있다. 예를 들어, 게코 네트워크 라이브러리는 XPCOM 컴포넌트이므로 자바스크립트에서 접근할 수 있다.
XPCOM을 이용하면 수많은 라이브러리에서 수많은 기능을 사용할 수 있다. 개발자들에게 온갖 건축 자재를 제공하여 개발자들이 건축 자체에만 집중하도록 돕겠다는 생각, 이것이 바로 XUL에서 거듭 강조하는 원칙이다. 그래서 XUL은 온갓 UI 위젯이 담긴 거대한 라이브러리를 제공한다. 또한 XBL(XML Binding Language)을 사용하여 위젯 기능과 동작을 바꾸는 방법도 제공한다. 먼저 XBL로 자신이 원하는 위젯 동작 방식을 정의한 다음, 새 동작 방식을 원래 위젯에 바인딩하면 된다. 어떻게 바인딩하냐고? 이 부분이 재치가 있다. CSS selector를 사용하여 위젯과 동작 방식을 바인딩하면 된다. CSS selector로 위젯을 하나 이상 선택한 다음, 특수 CSS 속성인 -moz-binding으로 위젯 동작 방식을 정의하는 XUL 파일 URL을 지정한다.
XUL이 널리 전파된 배경
순전히 기술적인 측면에서 XUL은 ‘플랫폼에 독립적인 응용 프로그램을 개발하기에 매우 흥미로운 프레임워크’다. 기술적으로 매우 흥미로운 프레임워크, 이 정도로 끝날 수도 있었다. 하지만 파이어폭스라는 단 한 가지 요인 덕분에 XUL은 훨씬 더 커다란 영향력을 발휘하게 되었다. 넷스케이프를 다시 짜면서 모듈성을 높이려는 노력 속에서 XUL이 나왔고, 같은 철학이 모질라 파이어폭스 웹 브라우저 개발을 촉진했다.
파이어폭스는 게코 엔진에 기반을 두고 경량형 브라우저를 만들겠다는 시도에서 나온 작품이다. 게코의 모듈형 구조가 아니었다면 불가능한 일이었다. 결과는 커다란 성공이었다. 2007년 5월 파이어폭스는 시장 점유율 15%에 사용자 수가 7억 5000만에 이르렀다. 포브스나 PC 월드와 같은 주요 잡지로부터 칭찬도 쏟아졌다.
초반에 파이어폭스가 성공을 거둔 이유는 1) 빠른 렌더링 엔진(게코)과 2) 특히 보안이 낫다는 사실 때문이었다. 이후에도 계속하여 파이어폭스가 성공을 거두는 이유는 확장 기능 때문이다. 확장 기능 덕택에 어느 개발자든 자신이 구현한 기능을 파이어폭스에 추가할 수 있다. 파이어폭스 확장 기능은 믿기지 않을 정도로 인기를 끌었다. 이 튜토리얼을 작성하는 현재 모질라에서 제공하는 공식적인 확장 기능만해도 1800개가 넘는다. 모질라 공식 리스트에 들어있지 않은 확장 기능도 부지기수다.
파이어폭스 확장 기능이 성공한 이유는 강력한 기능을 구현하기가 아주 쉬운 덕분이다. 파이어폭스 확장 기능은 (파이어폭스 UI와 마찬가지로) XUL로 작성하며, XUL의 강력한 오버레이(overlay) 기능을 활용한다. 예를 들어, 자신이 만든 새 UI 컴포넌트를 기존 UI 컴포넌트에 삽입할 수 있다. 그림 1은 파이어폭스에 여러 확장 기능을 추가한 모습이다.
그림 1. 여러 확장 기능을 추가한 파이어폭스
빨간색 타원 세 개는 확장 기능으로 삽입한 UI를 표시한다. 큰 도구 모음 두 개가 있고, 홈 버튼과 주소 표시줄 사이에 색다른 버튼이 하나 있다. 브라우저 윈도우 밑단에 있는 상태 표시줄에도 아이콘이 있다. 이렇듯 XUL 오버레이 기능을 사용하면 UI 요소를 따로 구현해 파이어폭스로 매끈하게 통합하기가 매우 쉽다.
파이어폭스를 넘어서: XULRunner
파이어폭스는 XUL을 수백만 사용자에게 퍼뜨렸다. 하지만 XUL은 그저 파이어폭스와 확장 기능을 구현하는 기술이 아니다. 파이어폭스의 자매품 전자편지 프로그램은 모질라 썬더버드다. 이 프로그램 역시 XUL로 작성되었으며 XUL 오버레이 덕택에 수많은 확장 기능이 존재한다. 파이어폭스만큼 널리 퍼지지는 않았으나 다운로드 횟수가 5000만 번을 넘는다. 이제는 많은 ISP가 IMAP이나 POP 클라이언트로 썬더버드를 설정하는 방법을 기본적으로 제공할 정도다. XUL은 모질라 프로젝트라는 세상에만 국한하지 않는다. 설계 상 XUL은 플랫폼에 독립적인 응용 프로그램을 개발하는 플랫폼이기 때문이다. 그런데 파이어폭스와 썬더버드같은 응용 프로그램은 게코 엔진에 기반한다. 이러한 웹 응용 프로그램은 UI와 HTML 페이지, HTML 전자편지를 브라우저에 뿌려야 한다. 그렇지만 대다수 데스크톱 응용 프로그램은 HTML을 브라우저에 뿌릴 필요가 없다. 즉, 대다수 데스크톱 응용 프로그램은 게코 엔진이 필요하지 않다. 그렇다면 게코 엔진 없이도 XUL을 사용할 수 있을까?
이 질문에 대한 답이 XULRunner다. XULRunner는 게코 엔진 밖에서 돌아가는 순수한 XUL 런타임 환경으로, 모듈성이라는 게코의 전통을 그대로 따른다. XULRunner만 있으면 게코 엔진 없이도 데스크톱 응용 프로그램을 구현하여 돌릴 수 있다.
파이어폭스 3.0
XULRunner 상에서 응용 프로그램을 구현할 때 한 가지 단점이라면 XULRunner를 응용 프로그램에 포함시켜야 한다는 점이다. 이 때문에 최종 응용 프로그램 크기는 12MB 정도 증가한다. 송버드와 같은 미디어 재생기에서는 이를 별로 문제 삼지 않았다. 오늘날 대다수 미디어 재생기는 아주 크기 때문이다. 주스트와 같은 비디오 스트리밍 응용 프로그램에서도 이를 별로 문제 삼지 않았다. 비디오 스트리밍 사용자들은 대개 네트워크가 빠르므로, 대다수 주스트 사용자들에게 추가로 12MB를 내려받는 시간은 무시할 정도였다. 하지만 XULRunner 런타임 자체가 응용 프로그램 자체만큼 크거나 응용 프로그램보다 더 큰 경우도 생긴다. 이 부분에서 XULRnner는 매력이 좀 떨어진다.
그러나 XULRunner 없이도 XUL 응용 프로그램을 돌릴 날이 멀지 않았다. 파이어폭스 3.0이 XULRunner 런타임을 포함하기 때문이다. 현재 7억 5000만에 이르는 파이어폭스 사용자 모두가 파이어폭스 3.0으로 판올림한다면 (그리고 현재 추세가 이어져 파이어폭스 3.0 사용자 수가 더욱 늘어난다면) 7억 5000만에 이르는 사용자가 XULRunner를 갖추는 셈이다. 파이어폭스 개발팀도 이 사실을 놓치지 않았으며, 그래서 파이어폭스 3.0에 들어 있는 XUL 런타임을 다른 응용 프로그램에서도 사용할 수 있게 만들었다. 명령행 인수에 -app만 추가하면 파이어폭스 대신 XUL 런타임이 실행된다.
| 
