Mozilla, 브라우저에서 플랫폼으로

그림: 본문 설명 참조

* Nigel McFarlane
* 2003년 12월 16일
* Linux Insider 원문
이 기사는 원래 2003년 12월 16일에 수록되었던 것을 ECT 뉴스 시리즈 최고 기사 중 하나로 2004년 2월 16일에 다시 올라온 것으로, 니겔 맥파레인 씨가 개발 환경에서의 모질라 플랫폼을 설명하고 있는 글입니다. 따라서 모질라의 현주소를 살펴보는 데 도움이 될 것 같아 제공합니다.–역주

스케이프는 브라우저 전쟁에서 졌다. 그 넷스케이프 제품 기술로부터 많은 도움을 받은 모질라는 갈수록 나아지고 있다. 넷스케이프는 사실상 죽었지만 모질라는 계속 앞으로 나아가고 있다. 이제 그 이유를 살펴보자.  2010년에 우리는 뒤돌아보면서 2003년이야말로 모질라가 진정으로 시작한 해라고 말할 것이다. 모질라 기반 제품들은 올해 많은 리뷰들로부터 칭찬을 받았고 여러 산업계 상을 수상했다. 동시에 모질라의 명백한 경쟁자인 마이크로소프트 인터넷 익스플로러와 아웃룩 익스프레스는 그 어느 때보다 침체된 한해였다. 사상 최악으로 버그 투성이에다가 보안 취약성에 노출된 데다가 사실상 마이크로소프트가 포기한 것이나 다름없는 형편이다.

올해 모질라 재단과 모질라 공동체와 그 친구들은 거의 매 분기마다 정규 마이너 릴리즈를 발표했다. 모질라 애플리케이션 슈트는 이제 1.6이고, 스탠드 얼론 모질라 브라우저(파이어버드)와 모질라 이메일 및 뉴스 리더(썬더버드)는 1.0 릴리즈를 향해 거세게 나아가고 있다. 모질라 기술은 이제 매우 안정되고 매우 능률적이고 날렵한 기능들로 가득 차 있다.

만약 이게 전부라면 우리는 그 팀이 오래지 않아 흩어지기 시작할 것이라고 예상할 것이다. 하지만 전혀 그렇지 않다. 모질라 재단에는 자금이 충분하고 수많은 친구들이 있다. 프로젝트가 끝나기는커녕 올해에는 훨씬 흥미로운 일이 생겼다. 모질라는 이제 소프트웨어 개발 플랫폼으로 성숙하고 있다. 즉, 앞으로 수많은 애플리케이션들이 그 플랫폼을 따르게 될 것이라는 얘기다.

플랫폼에 대한 생각
이제 분명해 보인다. 이메일러, HTML 컴포저, 달력, 디버거, 채팅 애플리케이션 및 주소록 같은 사용자 클라이언트를 가진 모질라는 단순한 웹 브라우저 그 이상임이 틀림없다. 모질라 브라우저는 모질라 플랫폼의 최상층에서 만들어진다. 여러분의 컴퓨터에 현재 모질라가 설치된 “chrome” 디렉토리를 보면 거기에 브라우저가 communicator.jar 또는 browser.jar이라는 단일 파일로 되어 있음을 알 수 있다. 이 파일들은 단순한 ZIP 아카이브로 사람이 읽을 수 있는 텍스트 파일 세트를 포함하고 있다.

모질라 플랫폼 그 자체는 프로그램 가능한 오브젝트들과 XML 처리기들을 하나의 프로그램으로 묶은 것이다. 이 플랫폼을 이용하는, 이미지나 XML, 텍스트 파일로 구성된 애플리케이션들은 플랫폼이 시작할 때 실시간으로 해석된다. 하나의 파일명을 인자로 주어서 플랫폼을 시작하면 브라우저가 나타난다. 다른 파일명으로 시작하면 이메일 클라이언트가 나타난다.

이런 애플리케이션 엔진은 새로운 것은 아니다. 많은 4GL 데이터베이스 클라이언트들도 그런 식으로 동작하며, 스몰톡이나 이맥스, 포스트스크립트, 매크로메다 플래쉬 등도 다 그런 식이다. 모질라에 있어서 새로운 것은 XML이나 CSS, 자바스크립트 같은 웹 개발에서 사용되는 간단한 기술들이 모두 똑같이 모질라 애플리케이션에서도 명백히 적용 가능하다는 것이다. 웹 페이지 대신에 여러분은 이러한 기술로 사용자에게 친근한 전통적인 GUI 기반 애플리케이션을 만들 수 있는 것이다. 그런 애플리케이션을 개발하는 웹 프로그래머는 너무나 많다. 따라서 이제 웹 개발자들에게는 현재의 몹시 경쟁적인 웹 개발 시장을 넘어서 스스로의 기술과 경험을 넓힐 수 있는 새로운 기회가 주어진 것이다.

모질라 플랫폼의 진가를 확인하는 첫 번째 열쇠는 (대부분 GUI라 부르는) 그래픽 사용자 인터페이스를 새로운 각도에서 살펴보는 것이다.

XML: GUI를 위한 자연스런 해결책
항상 하드웨어가 해결의 실마리를 제공해왔다. 데스크탑 하드웨어는 계속 빨라져서 이제 프로그램은 예전처럼 빠른 코드, 컴파일된 코드로 자체의 GUI를 돌릴 필요가 없어졌다. 느린 코드, 인터프리트 방식 코드도 가능하게 된 것이다. 모질라의 트릭은 GUI와 XML의 두 가지 개념을 함께 뒤섞는 것이다. 결과는 XUL–XML의 한 방언(dialect)이고 기술적으로는 하나의 애플리케이션–이다. XUL 문서는 애플리케이션의 GUI를 toolbar나 menu, key, window와 같은 XML 태그를 사용한 평범한 텍스트로 기술한다. HTML에는 이러한 태그가 없다. 여러분이 지금 보고 있는 이 문서를 디스플레이할 때, 결국 보여지는 것은 표준 애플리케이션 GUI 윈도우지, 브라우저 윈도우 내의 HTML 페이지가 아니다. 그건 하나의 기술적 발전이다.

XUL에 주목하는 이유는 프로그래밍의 황금률 때문이다. 프로그래머가 원하는 결과를 아주 단순한 방법을 통해 제공하는 시스템은 히트를 친다. 명령행의 단순함이 초기 유닉스와 도스 시절의 키보드 사용자들에게 히트를 쳤고, SQL의 단순함이 데이터베이스에서 인기를 끌었고, RFC 622에서 기술한 단순한 이메일 메시지 헤더 형식이 네트웍 메시지 쪽에서 인기를 끌었다. 그렇듯 XML과 GUI 위젯 집합의 조합은 사용자에게 친근한 GUI 클라이언트 쪽에서 인기를 끈다. 실제로 보고 싶으면 모질라 이메일 클라이언트의 주소록을 열어보자. 일단의 XUL 태그로부터 만들어진 새 윈도우가 화면에 나타난다.

모질라의 XUL은 지금까지 성공적이었고 상당한 영향력을 발휘해서 마이크로소프트나 매크로미디어 같은 GUI 개발 시스템의 대부분 업체들이 이제 XUL 클론이나 자신들만의 XUL 대체물(XAML이나 Flex)을 제공하고 있다. 언젠가 거의 대부분의 전문화된 애플리케이션들이 이런 방식으로 자신들의 비주얼한 사용자 인터페이스를 가지게 될 것이다. 이것이 미래다.

모질라와 이식성
XUL은 XML 구문법을 따르고, XML은 이식 가능한 표준이다. CSS도 이식 가능한 표준이다. 자바스크립트도 또한 이식 가능한 표준이다. 모질라 애플리케이션들이 이러한 표준들을 사용하여 작성되었으므로 모질라 애플리케이션들도 또한 이식성이 좋다. 윈도우용 애플리케이션을 만들어 변경하지 않고 리눅스나 매킨토시, 그 밖의 시스템에서 작동하는 것을 확인해 보라.

이 이식성은 웹 페이지의 이식성과 동일하다. 정말 환영할 만한 일이다. 이게 단순히 갈라진 윈도우와 리눅스 사이에 다리를 놓기 때문만은 아니고, 컴퓨터 영역에서 시민권을 빼앗긴 플랫폼, 예를 들어 OpenVMS나 OS/2, 아미가 같은 플랫폼들을 다시 활용할 수 있게 해주기 때문이다. 이러한 운영체제들에 그 시스템을 위한 모질라 플랫폼의 포트가 제공되면 그 어떠한 모질라 애플리케이션들도 돌릴 수 있다. 오로지 아미가만 아직 완전하지 못하다.

이러한 이식성 좋은 표준의 구현은 모질라 플랫폼 속으로 통합된 오브젝트 집합이다. 정확하지는 않지만 대략 1천개에서 3천개 정도의 오브젝트가 있다. 이러한 오브젝트들은 웹 접속이나 파일 접근과 같은 온갖 중요한 애플리케이션들에게 필요한 백엔드 기능들을 제공한다. 이런 오브젝트들은 어떠한 플랫폼에서도 사용 가능하기 때문에, 모질라 플랫폼은 전체적으로 어떻게 보면 자바 환경 같기도 하다.

모질라는 자바의 온갖 오브젝트 기반 구문법을 사용하기보다는 단순화된 자바스크립트와 XML을 사용한다. XUL 문서는 HTML 문서처럼 벙어리이거나 둔감하지 않다. 아주 쌍방향적이고 사용자의 명령에 잘 대답한다. 모질라 플랫폼은 자바환경처럼 그렇게 격리된 것이 아니므로 그 성능도 여러 경우에 더 좋아질 수 있다. 이 플랫폼은 접근 시스템이나 윈도우 매니저, 또는 드래그앤드롭이나 테마 엔진과 같은 본연의 데스크탑 기능들과 보다 용이하고 자연스럽게 통합된다.

더할 나위 없는 이식성
의심할 여지없이 마이크로소프트는 운영체제를 무의미하게 만드는 다른 크로스 플랫폼 기술에는 별 관심이 없다. 마이크로소프트의 닷넷 이니셔티브나 윈도우즈의 롱혼 릴리즈는 둘 다, 모질라가 제공하는 단순한 엔진 기반 시스템으로부터 사용자들의 시선을 돌리기 위해 설계된 요소들을 가지고 있다. 마이크로소프트가 극도로 만들기를 기피하는 것은, 표준 기반 웹 서버에서부터 모질라 같은 OS 독립 뷰잉 시스템에 이르는 미래의 모든 소프트웨어 애플리케이션들이다. 더욱 난처한 점은 그런 시스템은 어떠한 인터넷 접속성 없이도 로컬에서 돌아갈 수 있다는 점이다. 그건 마이크로소프트가 비주얼 베이직의 통제권을 잃어버린 것과 같다.

보통 크로스 플랫폼을 지원하는 플랫폼을 완벽하게 짓는 것은 매우 어렵다. 그것은 플랫폼들이 제공하는 GUI 위젯 집합이 서로 구석구석 다르기 때문이다. 윈도우즈 버튼은 매킨토시 버튼과 같지 않다. 그리고 조금씩 다른 여러 변종들이 있다. 이러한 제약점들은 보통 소로 합심하여 이식성 전략을 죽이는 역할을 한다.

그렇지만 모질라는 이식성 쪽으로 고개를 돌렸다. 모질라가 GUI에서 사용하는 위젯들은 직접 제작한 수공품이지 운영체제에게서 빌린 것이 아니다. 모질라는 윈도우즈에서 윈도우즈 서비스의 극히 일부분만 사용한다. 심지어는 텍스트 멀티라인 레이아웃을 GDI 서브시스템으로 넘기는 것과 같은 쉽게 의지할 수 있는 윈도우즈 기능들조차도 피하고 있다. 모질라는 윈도우즈 기능을 빌리지 않고 구현할 수 있으면 윈도우즈 기능을 건드리지 않는다. 경쟁적인 기능이 있다면 그것을 지원할 것이다. 그리고 나서 가능하다면 그것을 다른 모든 플랫폼에서 돌아갈 수 있도록 지원할 것이다. 모질라가 한 것 중에서 이식성이 높으면서도 가장 공격적인 것은 마이크로소프트의 COM을 그 밑바닥에서부터 재구현한 것일지도 모른다. (이제는 ActiveX라 불리는) COM은 수많은 애플리케이션들 사이에서 광범위하게 사용되는 MS의 표준 글루(아교)다. 하나의 완벽하게 분리된 구현은 상대방을 조롱하는 것이기도 하고, 또 기술적으로 큰 노력을 요하는 것이기도 하다. 모질라를 윈도우즈에서 돌리면 두 개의 COM이 있는 셈이다. MS의 것과 모질라의 것. MS 입장에서 볼 때 더 건방진 것은, 모질라의 COM 버전(XPCOM)을 만든 모질라의 이식성 높은 엔진이 윈도우즈가 아닌 다른 많은 플랫폼에서도 사용 가능하다는 것이다.

그래서 리눅스와 BeOS에서도 이제 원하기만 한다면 COM 구현을 돌릴 수 있게 된 것이다. 게다가 전통적인 수많은 비주얼 베이직 프로그래머들이 COM과 짝짓기한 것은 여간 다행한 일이 아닐 수 없다. 모질라는 닷넷이나 롱혼의 복잡성에 빠져들고 싶어하지 않는 그러한 VB 애용자들을 위해 대체 업그레이드 패스를 제공한다.

한숨 돌리기
끝단에 있는 일반 사용자에게는 이 모든 경쟁적인 노력이 눈에 보이지 않을 것이다. 만일 여러분이 모질라 애플리케이션과 윈도우즈 애플리케이션의 차이를 모른다면, 그 근원적인 구현이 만드는 차이점은 무엇인가? 애플리케이션이 여전히 빠르게 성장하고 있는 리눅스를 여러분이 사용하고 있지 않다면 그 차이는 그리 많지 않을 것이다.

지금부터라도 모질라와 함께 돌아가는 이식성 높은 애플리케이션이나 새로운 애플리케이션을 찾아 보라. 우리는 벌써 지원센터 콜 추적 시스템과 고객 데이터베이스 시스템의 시작을 눈으로 보고 있다. 모든 게 다 프리는 아닐 테고, 또 모든 게 공개는 아닐 테지만, 어쨌든 일부는 이 둘 다를 지향할 것이다. 모질라 프로그래머들과 창의적인 웹 개발자들과 다른 개발자들에게 있어 지금은 진정으로 재미있는 시간이다.

모질라는 자체의 고수준 표준 기반, 표준 호환 구현들로 운영체제 전쟁을 새로운 단계로 끌어올리고 있다. 여러분이 애플리케이션 개발자가 아니라 하더라도 여전히 가지고 놀 수 있는 훌륭한 웹 브라우저가 있다. 즐기자.

니겔 맥파레인은 과학 기술 분야의 프리랜스 작가로 광범위한 프로그래밍 백그라운드를 가지고 있다. 최근에 출판한 책은 모질라로 빠른 애플리케이션 개발하기 Rapid Application Development with Mozilla (Prentice Hall, 2003).
연락처는 nrm@kingtide.com.au

여러분의 생각

의견 쓰기

이름* 이메일* 홈페이지(선택)