반응형
파이어폭스 사용자가 늘어나면서 한국 모질라 커뮤니티에서는 사이트 접근성에 대한 논란을 심심치 않게 볼 수 있다. 대부분 XX 사이트에서 XX 기능이 안되더라”, “인터넷 뱅킹을 할 수 없다” 등이었다. 이는 해당 웹 페이지들이 액티브X 컨트롤을 사용하기 때문이다.
특히 국내는 액티브X 컨트롤을 사용하는 웹 페이지가 상당히 많기 때문에 파이어폭스와 같은 비 인터넷 익스플로러 계열의 웹 브라우저에서는 해당 페이지의 접근성이 현저하게 떨어지기 마련이다. 여기서는 액티브 X에 대응하기 위한 모질라 진영 대안과 XPCOM 플러그인을 살펴보고, 간단한 예제를 통해 웹 사이트 접근성을 높일 수 있는 방안을 모색해 본다.
1995년 넷스케이프는 웹 브라우저와 외부 프로그램과의 통신에 있어 좀 더 다이내믹한 인터넷 경험을 제공하기 위해 플러그인이라는 기술을 선보였다. 그러나 MS는 인터넷 익스플로러(이하 IE)를 시장에 도입하면서 이에 대응하는 액티브X 기술을 발표하게 된다.
액티브X는 윈도우의 COM/DCOM 환경에서 인터넷을 자유자재로 사용할 수 있는 기술 플랫폼으로 IE에 임베딩되어 실행 가능하다. 이후 IE와 윈도우가 브라우저와 운영체제를 독점하게 됨에 따라 윈도우 환경에서는 자바 애플릿이나 넷스케이프 플러그인 기술을 대체하게 되었다
IE가 웹 브라우저 시장 독점체제를 구축하는 동안 국내에서는 세계에서도 유래를 찾아 볼 수 없을 정도로 급속한 인터넷 환경을 갖추게 되었다. 이러한 성장 이면에는 몇 가지 문제점이 발견됐는데 바로 특정 운영체제와 플랫폼에 종속성이 심화된 것이다.
웹 페이지를 만들 때도 현재의 W3C에서 발표한 웹 표준 스펙을 이용하지 않고, 당시 넷스케이프와 IE에서 경쟁적으로 내놓은 비표준 태그와 MS 표준을 기반으로 한 문서 객체(Document Object Model)만 사용하려는 행태가 현재에도 고쳐지지 않고 있다(IE도 최소한의 W3C 표준을 지키고 있어 표준을 따르기만 하면 쉽게 모든 브라우저를 지원하게 된다).
또한, 플러그인 사용에 있어 액티브X 종속성이 더 심화되어 비 윈도우, 비 IE 환경에서는 사용이 거의 불가능하다는 것이다.
액티브X 종속성은 외국에 비해 국내의 경우 매우 심각하다. 액티브X 컨트롤을 배포할 때 사용하는 코드사인(Codesign) 인증서의 경우, 베리사인으로부터 국내에 공급되는 양은 거의 800여 개가 된다. 인증서 하나를 하나의 회사에서 사용한다고 본다면 적어도 800개의 업체에서 800개의 액티브X 컨트롤이 배포되고 있다는 것을 의미한다. 이는 세계에서 최대 규모이며 적어도 코드사인 인증서의 경우 세계 최대 시장이라고 들었다. 필자도 윈도우에 최소로 액티브X를 설치하는 데도 30여 개 정도가 설치되어 있다.
왜 액티브X가 문제인가?
액티브X를 국내에서 급속도로 쓸 수밖에 없었던 이유는 몇 가지 있다. 첫 번째는 초고속 인터넷의 급속한 확대이다. 플러그인이 구동되기 위해서는 별도의 프로그램을 다운받아 설치해야 하는데 크기가 큰 것은 모뎀 수준의 연결 속도에서는 다운받을 때까지 기다릴 수 없다. 이런 이유로 아직 외국에서는 액티브X 같은 플러그인 기술을 사용하는 웹사이트가 거의 드물다. 플래시와 윈도우 미디어, 리얼플레이어 등과 어도비 아크로뱃 리더처럼 설치시 제공하는 플러그인 정도가 대부분이다.
이에 반해 국내는 로그인, 채팅, 파일 첨부, 광고, 카드 결제, 인터넷 뱅킹, 사이버 트레이딩, 게임, 심지어 정부 민원 업무까지 그야말로 쓰이지 않는 곳이 거의 없을 지경이다. 초고속망 국가로 빨리 진입한 것이 플러그인을 부담 없이 사용하게 한 원인이다.
두 번째는 웹과 애플리케이션의 구별이 모호하다는 것이다. 웹은 정보의 자유로운 공유라는 측면에서 발전되어 왔다. 하지만 국내에서는 웹을 애플리케이션이 하는 기능의 연장선상에서 바라보고 있으며, 그에 따라 부가 기능들이 계속적으로 필요로 하게 된 것이다. 소프트웨어의 모든 기능을 웹이 할 수 있다는 생각에 여러 기능들이 덕지덕지 붙어 결국 웹도 애플리케이션도 아닌 어중간한 웹사이트들이 만들어진 것이다.
세 번째는 국가 차원에서 플러그인 기술 장려를 들 수 있다. 국내에서 플러그인 기술이 가장 먼저 도입된 것도 인터넷 뱅킹과 공인 인증 기술에 있다. 1999년 당시 128비트 암호화가 탑재된 웹 브라우저가 미국 밖으로 수출이 안 되고 있는 사이, 우리나라에서는 128비트 암호화가 가능한 SEED라는 알고리즘을 개발했고, 이를 국가 인증 기술로 탑재하는 과정에서 플러그인 기술을 사용하게 된 것이다. 당시에는 넷스케이프와 IE 양쪽에 모두 포팅 했으나 브라우저 점유율 확대에 따라 지금은 액티브X만 남게 되었다.
플러그인은 자신의 PC에 다른 프로그램을 설치하는 것으로 보안 때문이라도 신중하게 설치 여부를 검토해야 한다. 하지만 인터넷 뱅킹, 사이버 트레이딩, 공인 인증 등 액티브X 프로그램을 보안 경고창의 ‘예’ 버튼 한번으로 설치했던 경험때문에 일반인들에게 거부감 없이 받아들여지고 있다(최근 IE의 보안 이슈와 악성 플러그인이 범람함에 따라 좀 더 신중하게 액티브X를 설치하는 사람들이 늘어나고 있기는 하지만).
대안 없는 무분별한 액티브X 사용은 그것이 자랑할만한 독자 기술이었다 해도 다시 특정 기술 플랫폼 종속적이 될 수밖에 없다는 실례를 국내의 공인 인증 기술에서 찾아볼 수 있다. 99%가 사용하고 있으니 그것만 지원하는 것이 효율적이라는 생각에는 종속성이 커짐에 따라 증대하는 관성과 더딘 기술의 진보, 그리고 상상할 수 없는 비용의 증가를 예고하는 것이다.
얼마 전 윈도우 XP 서비스팩 2 출시에 따른 액티브X 설치 방법의 변경으로 인해 생긴 문제 때문에 국내만 서비스팩 2 출시를 몇달 간 연기하고서 모든 웹사이트들이 이 문제에 매달렸던 것만 봐도 알 수 있다. 그래서 운영체제나 디바이스 플랫폼에 독립적인 데다 오픈소스이기도 한 모질라 플랫폼에서 제공하는 대안 기술을 주목해야 하는 것이다.
대안 1. 액티브X 플러그인 기술
많은 사람들이 파이어폭스가 액티브X를 지원하면 많은 문제가 해결되는데 왜 그렇게 하지 않는지 의문을 가진다. 액티브X는 윈도우 종속적인 기술이고 모질라는 크로스 플랫폼을 지향하는 특성상 그렇게 할 수가 없다. 그러나 같은 기능을 두 가지로 개발하는 비용을 들이는데 비해 우선 사용자 층이 두터운 윈도우 플랫폼에서 액티브X를 사용할 수 있게 한다면 또한 윈도우 개발자들도 모질라 플랫폼을 쉽게 가져다 쓸 수 있다면 서로를 이해하고 접근 하는데 더 용이하지 않을까?
그래서 시작된 것이 바로 모질라 액티브X 프로젝트(http://www.iol.ie/~locka/mozilla/mozilla.htm)이다. 이 프로젝트는 성격상 모질라의 공식 프로젝트는 아니지만 자원봉사로 꾸준히 업데이트되고 있다.
이 프로젝트의 결과물은 크게 두 가지 부분으로 나눠진다. 그 첫 번째는 액티브X 플러그인(Plug-in For ActiveX controls) 기술이다. 이것은 기존의 모질라 플러그인 기술을 사용하여 윈도우에 설치된 액티브X를 감지하고 실행해 주는 플러그인이다. 즉, 파이어폭스에서 액티브X를 실행할 수 있게 해준다.
이를 위해서는 먼저 IE와 파이어폭스가 플러그인을 인식하는 방법을 맞출 필요가 있다. 똑같이 표준 태그인 <object>를 사용하고 있지만 그 속성을 인식할 때 IE는 classid="CLSID:XXXX...", 파이어폭스는 type="application/x-oleobject" 등과 같은 방법을 사용한다.
액티브X 플러그인은 일단 classid를 인식하게 해준다. 그리고 clsid에 해당하는 액티브X를 호스팅하여 실행한다. 만약 비표준 자바스크립트나 VBScript로 액티브X를 제어하면 제대로 동작하지 않겠지만, 그렇지 않은 경우 대부분 잘 동작한다.
이 프로그램에 모든 액티브X가 실행되는 것은 아니다. 만약 실행하고 싶은 액티브X가 있으면 파이어폭스 디렉토리 내에 activex.js 파일에 클래스 ID를 추가해줘야 한다.
pref("general.useragent.vendorComment", "ax");
pref("security.xpconnect.activex.global.hosting_flags", 9);
pref("security.classID.allowByDefault", false);
pref("capability.policy.default.ClassID.CID6BF52A52-394A-11D3-B153-00C04F79FAA6", "AllAccess");
pref("capability.policy.default.ClassID.CID22D6F312-B0F6-11D0-94AB-0080C74C7E95", "AllAccess");
이렇게 하는 이유는 보안상의 문제로 사용자가 실행할 액티브X를 결정할 수 있도록 하기 위해서이다. 아직 테스트 프로젝트이므로 편리한 인터페이스가 필요하다는 생각이 든다.
두 번째는 플러그인 액티브X(ActiveX hosting Plugin in IE)이다. 이 액티브X 컨트롤은 IE에서 넷스케이프 플러그인을 실행할 수 있도록 해 준다. MS가 IE 5.5 SP2부터 넷스케이프 플러그인에 대한 지원을 없애 버렸기 때문에 이 기능을 이용하면 넷스케이프 플러그인 개발자에게는 유용한 방식이다.
만약 넷스케이프 플러그인 만으로 구현 가능한 기술이라면, 액티브X 컨트롤을 중복해서 만들지 않더라도 모든 브라우저에서도 지원할 수 있다는 것을 의미한다. 이 방법을 테스트 해볼 수 있는 예제는lxr.mozilla.org/seamonkey/ 에서 얻을 수 있다.
이렇듯 액티브X와 모질라 플랫폼 연결 고리가 가능하게 되자 이 프로젝트에서는 모질라 액티브X 컨트롤(http://www.iol.ie/~locka/mozilla/control.htm)이라는 것을 구현하고 있다. 윈도우 개발자들은 IWebBrowser 같은 객체를 통해 IE를 간단하게 임베딩하여 프로그램에 사용할 수 있다.
이 모질라 액티브X도 마찬가지로 VC++, VB, 델파이, 닷넷 등에서 모질라를 간단하게 임베딩하여 코드를 사용할 수 있다. 간단한 예제를 만들어 실행하는 방법과 소스코드는 이 웹 페이지나 모질라 액티브X 소스코드 트리(lxr.mozilla.org/seamonkey/)를 참고하면 된다.
대안 2. XPCOM 플러그인 기술
액티브X와 모질라를 이어주는 플러그인 기술은 그 자체로서 크로스 플랫폼을 지원하지 않기 때문에 매우 불안정한 대안이라고 밖에 볼 수 없다. 모질라가 가지고 있는 근본적인 대안은 XPCOM(Cross-Platform Component Object Model)을 이용하여 모든 플랫폼을 동시에 지원하면서 XUL, 자바스크립트, CSS 등을 통해 리치 인터넷 애플리케이션(Rich Internet Application)을 만드는 기술의 확대를 꾀하는 것이다. 예전 플러그인이 수행했던 외부와의 통신 기능도 XML-RPC, SOAP, XMLHTTP 등의 기술로서 이미 해결되었기 때문에 확장 기능 등에서 활용도는 매우 높아지고 있다.
그러나 그밖에 외부 기술을 도입하고자 한다면 모질라 내부에 구현해야 한다. XPCOM 플러그인 기술은 XPIDL로 정의한 인터페이스를 구현한 플러그인 API와 이를 호출하는 XUL 및 자바스크립트로 구성되어 자유자재로 구현 가능하다. 각 API의 경우 각 운영체제별로 고려하고 컴파일하는 수고를 제외하고는 크로스 플랫폼에서 훌륭하게 돌아갈 수 있다. 글의 뒤 부분에서 XPCOM 플러그인을 활용한 구현 방법과 사례가 자세히 다뤄질 것이다.
대안 3. 새로운 표준 활동 WHATWG
그간 웹 표준화 기구인 W3C(www.w3.org)를 통해 수많은 웹 표준들이 제정됐음에도 불구하고 플러그인 기술 즉 웹 애플리케이션 기술에 대한 표준은 만들어지지 못했다. 표준은 상호운용성과 개방성 측면에서 매우 중요하며, 공정한 경쟁을 유도할 수 있는 제도적 장치이다. 이러한 필요성에 따라 W3C는 2004년 4월 웹 애플리케이션에 대한 워크샵을 개최하고 이에 대한 의견을 나누었다.
이 워크샵에서 가장 큰 쟁점은 MS와 오페라/모질라 재단 연합이 발표한 웹 애플리케이션 방향에 대한 것이다. MS는 XAML/아발론 등으로 대별되는 롱혼(Longhorn) 전략과 자사가 제안한 CSS3에 대한 이야기만 한 반면, 오페라/모질라 연합은 기존의 웹 표준 기술을 활용한 중간 단계의 웹 애플리케이션 표준을 빨리 만들자는 제안을 했다.
이에 대해 많은 참석자들은 부정적인 반응을 나타냈다. 이런 문제를 다룰 워킹그룹이 아직 존재하지 않는다는 이유를 달았지만 이미 W3C는 데스크탑 환경에서 웹 표준 문제보다는 오히려 모바일 같은 비 PC 디바이스에서 상호운용성에 관심을 가진 사람들이 많았으며 그곳에 초점을 두고 있었기 때문이다.
이에 2004년 6월 오페라와 모질라의 이안 힉슨과 데이비드 바론, 애플의 데이비드 하야트 등이 주축이 되어 W3C와 별도로 표준안을 만들기 위한 웹 애플리케이션 기술 워킹그룹(Web Hypertext Application Techology Working Group, http://whatwg.org)을 조직하고 활동에 들어갔다. 이 워킹그룹은 W3C 형식에 준하는 표준안 작업을 한 후 향후 IETF나 W3C에 기초안(draft)를 제안할 예정이다.
이 워킹그룹이 작업 중인 표준안은 크게 세 가지 영역으로 나눠져 있다. 그 중 가장 관심을 끄는 웹 애플리케이션 1.0은 애플리케이션 개발을 하기 위해 기존의 HTML을 확장하는 것이다. 흔히 HTML5라고 불리는 이 표준안은 XUL의 경험을 기초로 복잡한 XML을 사용하기보다는 기존의 HTML을 확장하여 UI를 만드는 것을 목표로 하는 것으로 기존의 파이어폭스 확장 기능보다도 더 쉽게 웹 애플리케이션을 만드는 방법을 제안할 것이다.
예를 들어 메뉴바를 만들기 위해서 다음과 같이 우리에게 익숙한 HTML 태그와 그 확장 태그를 쓰겠다는 것이다.
<menubar>
<li>
<a href="#file">File</a>
<menu id="file">
<li><button type="button" onclick="fnew()">New...</button></li>
<li><button type="button" onclick="fopen()">Open...</button></li>
<li><button type="button" onclick="fsave()" id="save">Save</button></li>
<li><button type="button" onclick="fsaveas()">Save as...</button></li>
</menu>
</li>
</menubar>
이 표준안은 XHTML, CSS 같은 기존 표준안과는 연동되지만, XUL/XAML과는 독립적으로 구성하겠다는 뜻을 가지고 있어 웹 표준으로서 기술을 주도하겠다는 생각을 가지고 있다. 웹 폼 2.0(Web Forms 2.0)은 HTML 4.01의 폼 부분의 기능을 확장하는 작업으로 웹 애플리케이션에서 사용하는 데이터 입력 및 출력 그리고 추가 등을 위해 기초적으로 필요한 작업이다. 따라서 이 표준안 작업은 꽤 많이 진척되어 2004년 연말까지 거의 완성되었다.
W3C에는 이와 유사한, IBM이 제안하여 표준안이 된 XForm이 있다. XForm은 기계들 간의 데이터 교환 표준으로 삼고, WebForm은 사용자 인터페이스에 사용하게 하여 애플리케이션 개발자들이 이해하기 쉽도록 하자는 것이 이 표준안의 취지이다. 이 표준안이 W3C나 IETF에 받아들여진다면 비 MS 진영의 브라우저 애플리케이션 개발에 획기적인 플랫폼이 만들어질 것으로 예상된다.
마지막으로 웹 컨트롤 1.0(Web Controls 1.0)은 새로운 WebForm과 UI에 대한 컨트롤과 외양 표시가 가능하도록 DOM과 CSS의 기존 표준을 확장하는 작업이다. 이 부분은 기존의 DOM/CSS의 객체 사용 방법이 어느 정도 성숙되어 있기 때문에 제일 마지막에 할 작업이 될 것이다.
표준은 표준으로만 존재하는 것이 아니라 구현됐을 때 빛을 발하게 된다. 모질라와 오페라, 애플이 만드는 새로운 표준은 웹 개방성과 상호운용성 문제를 해결할 수 있는 중요한 시발점이 될 것이다. 표준이 되더라도 과연 MS가 이를 수용할지 여부는 알 수 없지만 검증된 개발 방법론을 기초로 대안을 제시할 수 있다고 생각한다.
액티브X 넘어서기, XPCOM 구현
현재 모든 플랫폼에서 모질라 계열 웹 브라우저와 오페라, 매킨토시의 사파리(Safari) 등은 공통적으로 XPCOM 플러그인을 지원한다. 이 연합은 MS를 제외시켜 IE는 게코 플러그인이 지원하지 않는 유일한 웹 브라우저이다(인터넷 뱅킹을 할 때 <화면 3>과 같은 오류 메시지가 뜨는 것도 이 때문이다. 재미있는 것은 매킨토시용 익스플로러는 XPCOM 플러그인을 지원한다는 사실이다).
국내 웹사이트의 현실을 볼 때 액티브X를 지원하지 않는 파이어폭스를 메인 웹 브라우저로 사용한다는 것은 여간 힘든 일이 아니다. 물론 IE 뷰 확장이나, 액티브X 호스팅 플러그인이 있지만 어디까지나 윈도우에서 파이어폭스를 사용하는 경우에 한정돼 있으며 근본적인 해결책이라 보기도 힘들다.
이런 점에서 앞서 언급한 넷스케이프의 다중 플랫폼 플러그인 지원 정책은 주목할 만하다. 국내의 경우 국가적으로 비 윈도우 운영체제에서의 웹 사이트 접근성을 높이려는 방안 등이 모색되고 있어 더욱 의미가 있다. 물론 액티브X가 이미 수많은 웹 사이트에 만연(?)해 있어, 일부 중복 개발의 우려가 있는 것도 사실이다. 그러나 플러그인 하나를 개발해 다양한 플랫폼에서 (IE를 제외한) 다양한 웹 브라우저를 지원할 수 있다는 점은 이런 우려를 불식시키기에 충분해 보인다.
파이어폭스의 XPCOM 플러그인은 XPCOM의 컴포넌트로 분류돼 플랫폼에 독립적인 공통 인터페이스를 제공한다. 넷스케이프 게코 플러그인 SDK를 이용해 개발하는데, SDK에 포함된 XPIDL로 플러그인에 접근하기 위한 타입 라이브러리를 만들고, 자바스크립트를 통해 스크립터블(scriptable : 호스트 오브젝트를 IDL을 통해 스크립트처럼 사용함을 말함)하게 접근할 수 있는 인터페이스를 만드는 것이다.
플러그인의 내부는 플러그인 측면(Plug-in side) API, 브라우저 측면(Browser side) API(동작 원리에서 설명), XPIDL에서 선언한 인터페이스들을 구현함으로써 완성된다. 이 때 한번 작성된 IDL(Interface Definition Language)과 플러그인은 플랫폼 독립적으로 유지, 보수할 수 있는 것이 특징이다(이 부분은 <그림 2>을 참조하면 이해가 쉽다). 빌드가 끝난 플러그인은 다음과 같이 각 플랫폼에 적절한 동적 라이브러리 형식을 취하게 된다.
◆ MS 윈도우 : Dynamic Link Library(.dll)
◆ 유닉스 : Share Object(.so 혹은 .dso)
◆ Mac OS : PPC Shared Library(.dylib)
이는 표준 인터페이스를 이용해 플랫폼 변화에 유연하게 대처할 수 있다는 장점이 있다. 플랫폼에 유연하다는 것 자체가 액티브 X에서는 불가능했던 개념으로, 플랫폼마다 최적의 네이티브 코드(native code)를 플러그인에 접목시켜 각 플랫폼의 특성에 맞게 작성할 수 있다. 그러나 각 플랫폼마다의 네이티브 코드를 고려해야 하고, 빌드를 따로 해야 하는 번거로움이 있다.
플러그인 동작 원리
파이어폭스용 넷스케이프 플러그인은 기본적으로 다음 과정을 거쳐서 실행된다.
[1] MIME 타입에 해당하는 플러그인의 유무 검사
[2] 플러그인이 존재한다면 해당 플러그인을 메모리에 로드
[3] 플러그인 초기화
[4] 해당 플러그인의 인스턴스 생성
로딩된 플러그인 인스턴스는 다른 파이어폭스 브라우저 창에서 동시에 접속할 경우 인스턴스가 각각 생성되며 사용자가 해당 웹 페이지를 닫으면 소멸된다. 플러그인 오브젝트와 관련된 API는 플러그인 측면 API로 분류돼 브라우저가 콜백 함수처럼 호출한다. 브라우저 측면 API는 플러그인에서 호출하는 함수로, 메모리, 스트림, URL 제어 관련 함수들이 포함되며, 플러그인 측면 API처럼 플랫폼에 따라 적절하게 구현할 수 있다(양 측면 API 모두 사용자가 플랫폼의 특성을 고려하여 적절하게 구현할 수 있다). 모질라 웹 사이트(lxr.mozilla.org/)에 접속하면 다양한 플러그인 예제들을 볼 수 있다.
파이어폭스 플러그인 개발
그럼, 리눅스, 파이어폭스 환경에서 스크립터블하게 플러그인을 작성하는 예제를 본격적으로 살펴보자. 먼저 <리스트 1>과 같이 XPIDL을 정의한다.
이 때 XPIDL 내에서 사용할 수 있는 데이터 타입과 플러그인 내부에서 매치되는 타입은 <표 1>과 같다.
wstring(플러그 인 타입 PRUnichar*에 해당하는) 타입은 UTF-16이며, 리눅스 glibc에서 사용하는 wchar* 타입은 UTF-32이므로 타입 사용에 있어 혼동하지 않기 바란다. 아울러 처리하게 될 문자들이 모두 ASCII로 이뤄지지 않는 이상 반드시 wstring을 선언해서 구현해야 한다. 이제 플러그인에서 include하는 헤더를 생성한다. -m header는 IDL에 대한 헤더를 출력하는 옵션으로 확장자가 .h로 생성된다.
xpidl -I /home/hkyang/gecko-sdk/xpcom/idl -m header nsIXecurePlugin.idl
생성된 헤더 파일의 내용은 다음과 같다. 함수의 첫 글자가 모두 대문자로 바뀐다는 사실에 유의하자. 각 함수에 대한 코멘트(comment)는 자동으로 생성된다. GetVal, SetVal는 선언한 long 타입의 attribute val 변수의 값을 설정하고 얻어올 수 있는 함수이다. attribute마다 한 쌍의 getter, setter 함수가 존재한다.
class NS_NO_VTABLE nsIXecurePlugin : public nsParentClass {
…
/* void foo1 (); */
NS_IMETHOD Foo1(void) = 0;
/* void foo2 (); */
NS_IMETHOD Foo2(void) = 0;
…
}
이 때 함수의 반환형은 NS_IMETHOD로 선언되며 플러그인 내부에서 NS_IMETHODIMP 타입으로 구현된다. NS_IMETHODIMP 타입은 플러그인 함수 호출에 대한 성공 여부, 실패 시 상태 값을 가진다. 자세한 내용은 SDK의 xpcom/nsError.h 파일을 참조하기 바란다. 함수 반환 값은 void로 선언하지 않은 이상 모든 경우에서 함수의 마지막 인자로 _retval 변수의 해당 타입에 해당하는 포인터로 선언된다. 이제 파이어폭스와 플러그인 사이의 인터페이스용 타입 라이브러리를 만들 차례다. -m typelib 옵션을 통해 생성하며 확장자가 .xpt로 생성된다.
xpidl -I /home/hkyang/gecko-sdk/xpcom/idl
-m typelib nsIXecurePlugin.idl
이제 플러그인 측면 API를 구현한다. 예제 사이트에 보면 각 플랫폼 별로 구현돼 있어 수정할 일이 거의 없지만 디버깅할 일이 있을지도 모르니 한번 다뤄보는 것도 좋다.
이제 플러그인 헤더를 정의한다. 플러그인이 스크립터블하기 위해서는 nsIClassInfo 클래스를 상속받아 구현해야 한다. nsIClassInfo 클래스는 모질라 시큐리티 매니저(mozilla security manage)가 자바스크립트의 해당 플러그인에 접근하도록 허가한다. IDL 인터페이스에서 선언한 nsIXecurePlugin 클래스와 플러그인을 스크립터블하게 접근하기 위해 상속받은 nsClassInfoMixin 클래스를 다중 상속받아 nsScriptablePeer를 선언한다.
class nsClassInfoMixin : public nsIClassInfo
{
…
}
class nsScriptablePeer : public nsIXecurePlugin,
public nsClassInfoMixin
{
…
}
이제 앞에서 선언한 nsScriptablePeer 클래스의 내부를 구현한다. IDL 파일에서 선언한 Foo1(), Foo2() 인터페이스의 내용을 구현해주면 된다.
NS_IMETHODIMP nsScriptablePeer::Foo1()
{
…
return NS_OK; // 플러그인이 정상적으로 호출되었음을 나타낸다.
}
이제 테스트에 사용할 html 페이지를 만들어 보자. 액티브 X와 XPCOM 플러그인 모두를 지원하며, 여기서는 EMBED invokeURLs=false 태그를 사용했지만 OBJECT 태그를 사용할 것을 권장한다. EMBED invokeURLs=false 태그는 파이어폭스에서 지원하기는 하나, 표준이 아니며 어디까지나 호환성을 위해 지원하는 것이다.
빌드가 끝난 후 최종적으로 생성된 타입 라이브러리 파일은 웹 브라우저 디렉토리 하단의 components 디렉토리에, 플러그인 라이브러리 파일은 웹 브라우저 디렉토리 하단의 plugins 디렉토리에 복사하거나 다른 디렉토리에 저장하고 심볼릭 링크를 걸어주면 인식된다. 타입 라이브러리 파일이 정확히 설치됐는지 여부는 다음과 같이 확인할 수 있다.
[hkyang@localhost xw_plugin]$ ls /파이어폭스/components/*.xpt -al
-rwx------ 1 root root 1636 1월20 17:34 /파이어폭스/components/nsIXecurePlugin.xpt
플러그인에 대한 라이브러리 파일은 추후 관리가 용이하도록 심볼릭 링크를 걸어두는 것이 편하다.
[hkyang@localhost xw_plugin]$ ls /firefox/plugins/ -al
drwxr-xr-x 2 root root 4096 12월24 17:54 .
drwxrwxr-x 11 hkyang hkyang 4096 12월15 11:26 ..
lrwxrwxrwx 1 root root 46 12월24 17:54 libXecure.so
-> /home/hkyang/.softforum/XecureWeb/libXecure.so
이제 <화면 4>와 같이 about:plugin 페이지에서 플러그인이 정상적으로 설치되었는지 최종적으로 확인해 볼 수 있다.
파이어폭스에서 인터넷 뱅킹을!
<그림 3>은 필자가 참여한 리눅스용 인터넷 뱅킹 데모 화면의 일부이다. 현재 리눅스 유저들이 인터넷 뱅킹을 할 수 없었던 이유는 플러그인에 대한 지원이 미비하고 인터넷 뱅킹 클라이언트가 없었기 때문이다. 클라이언트의 경우 XPCOM 플러그인이 플랫폼에 유연하게 대응할 수 있기 때문에 리눅스를 포함한 윈도우 이외의 운영체제에서 빠르게 포팅할 수 있도록 설계, 구현했다.
특히 국내는 액티브X 컨트롤을 사용하는 웹 페이지가 상당히 많기 때문에 파이어폭스와 같은 비 인터넷 익스플로러 계열의 웹 브라우저에서는 해당 페이지의 접근성이 현저하게 떨어지기 마련이다. 여기서는 액티브 X에 대응하기 위한 모질라 진영 대안과 XPCOM 플러그인을 살펴보고, 간단한 예제를 통해 웹 사이트 접근성을 높일 수 있는 방안을 모색해 본다.
1995년 넷스케이프는 웹 브라우저와 외부 프로그램과의 통신에 있어 좀 더 다이내믹한 인터넷 경험을 제공하기 위해 플러그인이라는 기술을 선보였다. 그러나 MS는 인터넷 익스플로러(이하 IE)를 시장에 도입하면서 이에 대응하는 액티브X 기술을 발표하게 된다.
액티브X는 윈도우의 COM/DCOM 환경에서 인터넷을 자유자재로 사용할 수 있는 기술 플랫폼으로 IE에 임베딩되어 실행 가능하다. 이후 IE와 윈도우가 브라우저와 운영체제를 독점하게 됨에 따라 윈도우 환경에서는 자바 애플릿이나 넷스케이프 플러그인 기술을 대체하게 되었다
IE가 웹 브라우저 시장 독점체제를 구축하는 동안 국내에서는 세계에서도 유래를 찾아 볼 수 없을 정도로 급속한 인터넷 환경을 갖추게 되었다. 이러한 성장 이면에는 몇 가지 문제점이 발견됐는데 바로 특정 운영체제와 플랫폼에 종속성이 심화된 것이다.
웹 페이지를 만들 때도 현재의 W3C에서 발표한 웹 표준 스펙을 이용하지 않고, 당시 넷스케이프와 IE에서 경쟁적으로 내놓은 비표준 태그와 MS 표준을 기반으로 한 문서 객체(Document Object Model)만 사용하려는 행태가 현재에도 고쳐지지 않고 있다(IE도 최소한의 W3C 표준을 지키고 있어 표준을 따르기만 하면 쉽게 모든 브라우저를 지원하게 된다).
또한, 플러그인 사용에 있어 액티브X 종속성이 더 심화되어 비 윈도우, 비 IE 환경에서는 사용이 거의 불가능하다는 것이다.
액티브X 종속성은 외국에 비해 국내의 경우 매우 심각하다. 액티브X 컨트롤을 배포할 때 사용하는 코드사인(Codesign) 인증서의 경우, 베리사인으로부터 국내에 공급되는 양은 거의 800여 개가 된다. 인증서 하나를 하나의 회사에서 사용한다고 본다면 적어도 800개의 업체에서 800개의 액티브X 컨트롤이 배포되고 있다는 것을 의미한다. 이는 세계에서 최대 규모이며 적어도 코드사인 인증서의 경우 세계 최대 시장이라고 들었다. 필자도 윈도우에 최소로 액티브X를 설치하는 데도 30여 개 정도가 설치되어 있다.
왜 액티브X가 문제인가?
액티브X를 국내에서 급속도로 쓸 수밖에 없었던 이유는 몇 가지 있다. 첫 번째는 초고속 인터넷의 급속한 확대이다. 플러그인이 구동되기 위해서는 별도의 프로그램을 다운받아 설치해야 하는데 크기가 큰 것은 모뎀 수준의 연결 속도에서는 다운받을 때까지 기다릴 수 없다. 이런 이유로 아직 외국에서는 액티브X 같은 플러그인 기술을 사용하는 웹사이트가 거의 드물다. 플래시와 윈도우 미디어, 리얼플레이어 등과 어도비 아크로뱃 리더처럼 설치시 제공하는 플러그인 정도가 대부분이다.
이에 반해 국내는 로그인, 채팅, 파일 첨부, 광고, 카드 결제, 인터넷 뱅킹, 사이버 트레이딩, 게임, 심지어 정부 민원 업무까지 그야말로 쓰이지 않는 곳이 거의 없을 지경이다. 초고속망 국가로 빨리 진입한 것이 플러그인을 부담 없이 사용하게 한 원인이다.
두 번째는 웹과 애플리케이션의 구별이 모호하다는 것이다. 웹은 정보의 자유로운 공유라는 측면에서 발전되어 왔다. 하지만 국내에서는 웹을 애플리케이션이 하는 기능의 연장선상에서 바라보고 있으며, 그에 따라 부가 기능들이 계속적으로 필요로 하게 된 것이다. 소프트웨어의 모든 기능을 웹이 할 수 있다는 생각에 여러 기능들이 덕지덕지 붙어 결국 웹도 애플리케이션도 아닌 어중간한 웹사이트들이 만들어진 것이다.
세 번째는 국가 차원에서 플러그인 기술 장려를 들 수 있다. 국내에서 플러그인 기술이 가장 먼저 도입된 것도 인터넷 뱅킹과 공인 인증 기술에 있다. 1999년 당시 128비트 암호화가 탑재된 웹 브라우저가 미국 밖으로 수출이 안 되고 있는 사이, 우리나라에서는 128비트 암호화가 가능한 SEED라는 알고리즘을 개발했고, 이를 국가 인증 기술로 탑재하는 과정에서 플러그인 기술을 사용하게 된 것이다. 당시에는 넷스케이프와 IE 양쪽에 모두 포팅 했으나 브라우저 점유율 확대에 따라 지금은 액티브X만 남게 되었다.
플러그인은 자신의 PC에 다른 프로그램을 설치하는 것으로 보안 때문이라도 신중하게 설치 여부를 검토해야 한다. 하지만 인터넷 뱅킹, 사이버 트레이딩, 공인 인증 등 액티브X 프로그램을 보안 경고창의 ‘예’ 버튼 한번으로 설치했던 경험때문에 일반인들에게 거부감 없이 받아들여지고 있다(최근 IE의 보안 이슈와 악성 플러그인이 범람함에 따라 좀 더 신중하게 액티브X를 설치하는 사람들이 늘어나고 있기는 하지만).
대안 없는 무분별한 액티브X 사용은 그것이 자랑할만한 독자 기술이었다 해도 다시 특정 기술 플랫폼 종속적이 될 수밖에 없다는 실례를 국내의 공인 인증 기술에서 찾아볼 수 있다. 99%가 사용하고 있으니 그것만 지원하는 것이 효율적이라는 생각에는 종속성이 커짐에 따라 증대하는 관성과 더딘 기술의 진보, 그리고 상상할 수 없는 비용의 증가를 예고하는 것이다.
얼마 전 윈도우 XP 서비스팩 2 출시에 따른 액티브X 설치 방법의 변경으로 인해 생긴 문제 때문에 국내만 서비스팩 2 출시를 몇달 간 연기하고서 모든 웹사이트들이 이 문제에 매달렸던 것만 봐도 알 수 있다. 그래서 운영체제나 디바이스 플랫폼에 독립적인 데다 오픈소스이기도 한 모질라 플랫폼에서 제공하는 대안 기술을 주목해야 하는 것이다.
대안 1. 액티브X 플러그인 기술
많은 사람들이 파이어폭스가 액티브X를 지원하면 많은 문제가 해결되는데 왜 그렇게 하지 않는지 의문을 가진다. 액티브X는 윈도우 종속적인 기술이고 모질라는 크로스 플랫폼을 지향하는 특성상 그렇게 할 수가 없다. 그러나 같은 기능을 두 가지로 개발하는 비용을 들이는데 비해 우선 사용자 층이 두터운 윈도우 플랫폼에서 액티브X를 사용할 수 있게 한다면 또한 윈도우 개발자들도 모질라 플랫폼을 쉽게 가져다 쓸 수 있다면 서로를 이해하고 접근 하는데 더 용이하지 않을까?
그래서 시작된 것이 바로 모질라 액티브X 프로젝트(http://www.iol.ie/~locka/mozilla/mozilla.htm)이다. 이 프로젝트는 성격상 모질라의 공식 프로젝트는 아니지만 자원봉사로 꾸준히 업데이트되고 있다.
이 프로젝트의 결과물은 크게 두 가지 부분으로 나눠진다. 그 첫 번째는 액티브X 플러그인(Plug-in For ActiveX controls) 기술이다. 이것은 기존의 모질라 플러그인 기술을 사용하여 윈도우에 설치된 액티브X를 감지하고 실행해 주는 플러그인이다. 즉, 파이어폭스에서 액티브X를 실행할 수 있게 해준다.
이를 위해서는 먼저 IE와 파이어폭스가 플러그인을 인식하는 방법을 맞출 필요가 있다. 똑같이 표준 태그인 <object>를 사용하고 있지만 그 속성을 인식할 때 IE는 classid="CLSID:XXXX...", 파이어폭스는 type="application/x-oleobject" 등과 같은 방법을 사용한다.
액티브X 플러그인은 일단 classid를 인식하게 해준다. 그리고 clsid에 해당하는 액티브X를 호스팅하여 실행한다. 만약 비표준 자바스크립트나 VBScript로 액티브X를 제어하면 제대로 동작하지 않겠지만, 그렇지 않은 경우 대부분 잘 동작한다.
 |
| <화면 1> 파이어폭스에서 윈도우 미디어 플레이어 액티브X가 실행되는 모습 |
이 프로그램에 모든 액티브X가 실행되는 것은 아니다. 만약 실행하고 싶은 액티브X가 있으면 파이어폭스 디렉토리 내에 activex.js 파일에 클래스 ID를 추가해줘야 한다.
pref("general.useragent.vendorComment", "ax");
pref("security.xpconnect.activex.global.hosting_flags", 9);
pref("security.classID.allowByDefault", false);
pref("capability.policy.default.ClassID.CID6BF52A52-394A-11D3-B153-00C04F79FAA6", "AllAccess");
pref("capability.policy.default.ClassID.CID22D6F312-B0F6-11D0-94AB-0080C74C7E95", "AllAccess");
이렇게 하는 이유는 보안상의 문제로 사용자가 실행할 액티브X를 결정할 수 있도록 하기 위해서이다. 아직 테스트 프로젝트이므로 편리한 인터페이스가 필요하다는 생각이 든다.
두 번째는 플러그인 액티브X(ActiveX hosting Plugin in IE)이다. 이 액티브X 컨트롤은 IE에서 넷스케이프 플러그인을 실행할 수 있도록 해 준다. MS가 IE 5.5 SP2부터 넷스케이프 플러그인에 대한 지원을 없애 버렸기 때문에 이 기능을 이용하면 넷스케이프 플러그인 개발자에게는 유용한 방식이다.
만약 넷스케이프 플러그인 만으로 구현 가능한 기술이라면, 액티브X 컨트롤을 중복해서 만들지 않더라도 모든 브라우저에서도 지원할 수 있다는 것을 의미한다. 이 방법을 테스트 해볼 수 있는 예제는lxr.mozilla.org/seamonkey/ 에서 얻을 수 있다.
이렇듯 액티브X와 모질라 플랫폼 연결 고리가 가능하게 되자 이 프로젝트에서는 모질라 액티브X 컨트롤(http://www.iol.ie/~locka/mozilla/control.htm)이라는 것을 구현하고 있다. 윈도우 개발자들은 IWebBrowser 같은 객체를 통해 IE를 간단하게 임베딩하여 프로그램에 사용할 수 있다.
 |
| <화면 2> 비주얼 베이직으로 모질라를 임베딩한 예제 실행 화면 |
이 모질라 액티브X도 마찬가지로 VC++, VB, 델파이, 닷넷 등에서 모질라를 간단하게 임베딩하여 코드를 사용할 수 있다. 간단한 예제를 만들어 실행하는 방법과 소스코드는 이 웹 페이지나 모질라 액티브X 소스코드 트리(lxr.mozilla.org/seamonkey/)를 참고하면 된다.
대안 2. XPCOM 플러그인 기술
액티브X와 모질라를 이어주는 플러그인 기술은 그 자체로서 크로스 플랫폼을 지원하지 않기 때문에 매우 불안정한 대안이라고 밖에 볼 수 없다. 모질라가 가지고 있는 근본적인 대안은 XPCOM(Cross-Platform Component Object Model)을 이용하여 모든 플랫폼을 동시에 지원하면서 XUL, 자바스크립트, CSS 등을 통해 리치 인터넷 애플리케이션(Rich Internet Application)을 만드는 기술의 확대를 꾀하는 것이다. 예전 플러그인이 수행했던 외부와의 통신 기능도 XML-RPC, SOAP, XMLHTTP 등의 기술로서 이미 해결되었기 때문에 확장 기능 등에서 활용도는 매우 높아지고 있다.
그러나 그밖에 외부 기술을 도입하고자 한다면 모질라 내부에 구현해야 한다. XPCOM 플러그인 기술은 XPIDL로 정의한 인터페이스를 구현한 플러그인 API와 이를 호출하는 XUL 및 자바스크립트로 구성되어 자유자재로 구현 가능하다. 각 API의 경우 각 운영체제별로 고려하고 컴파일하는 수고를 제외하고는 크로스 플랫폼에서 훌륭하게 돌아갈 수 있다. 글의 뒤 부분에서 XPCOM 플러그인을 활용한 구현 방법과 사례가 자세히 다뤄질 것이다.
대안 3. 새로운 표준 활동 WHATWG
그간 웹 표준화 기구인 W3C(www.w3.org)를 통해 수많은 웹 표준들이 제정됐음에도 불구하고 플러그인 기술 즉 웹 애플리케이션 기술에 대한 표준은 만들어지지 못했다. 표준은 상호운용성과 개방성 측면에서 매우 중요하며, 공정한 경쟁을 유도할 수 있는 제도적 장치이다. 이러한 필요성에 따라 W3C는 2004년 4월 웹 애플리케이션에 대한 워크샵을 개최하고 이에 대한 의견을 나누었다.
이 워크샵에서 가장 큰 쟁점은 MS와 오페라/모질라 재단 연합이 발표한 웹 애플리케이션 방향에 대한 것이다. MS는 XAML/아발론 등으로 대별되는 롱혼(Longhorn) 전략과 자사가 제안한 CSS3에 대한 이야기만 한 반면, 오페라/모질라 연합은 기존의 웹 표준 기술을 활용한 중간 단계의 웹 애플리케이션 표준을 빨리 만들자는 제안을 했다.
이에 대해 많은 참석자들은 부정적인 반응을 나타냈다. 이런 문제를 다룰 워킹그룹이 아직 존재하지 않는다는 이유를 달았지만 이미 W3C는 데스크탑 환경에서 웹 표준 문제보다는 오히려 모바일 같은 비 PC 디바이스에서 상호운용성에 관심을 가진 사람들이 많았으며 그곳에 초점을 두고 있었기 때문이다.
이에 2004년 6월 오페라와 모질라의 이안 힉슨과 데이비드 바론, 애플의 데이비드 하야트 등이 주축이 되어 W3C와 별도로 표준안을 만들기 위한 웹 애플리케이션 기술 워킹그룹(Web Hypertext Application Techology Working Group, http://whatwg.org)을 조직하고 활동에 들어갔다. 이 워킹그룹은 W3C 형식에 준하는 표준안 작업을 한 후 향후 IETF나 W3C에 기초안(draft)를 제안할 예정이다.
이 워킹그룹이 작업 중인 표준안은 크게 세 가지 영역으로 나눠져 있다. 그 중 가장 관심을 끄는 웹 애플리케이션 1.0은 애플리케이션 개발을 하기 위해 기존의 HTML을 확장하는 것이다. 흔히 HTML5라고 불리는 이 표준안은 XUL의 경험을 기초로 복잡한 XML을 사용하기보다는 기존의 HTML을 확장하여 UI를 만드는 것을 목표로 하는 것으로 기존의 파이어폭스 확장 기능보다도 더 쉽게 웹 애플리케이션을 만드는 방법을 제안할 것이다.
예를 들어 메뉴바를 만들기 위해서 다음과 같이 우리에게 익숙한 HTML 태그와 그 확장 태그를 쓰겠다는 것이다.
<menubar>
<li>
<a href="#file">File</a>
<menu id="file">
<li><button type="button" onclick="fnew()">New...</button></li>
<li><button type="button" onclick="fopen()">Open...</button></li>
<li><button type="button" onclick="fsave()" id="save">Save</button></li>
<li><button type="button" onclick="fsaveas()">Save as...</button></li>
</menu>
</li>
</menubar>
이 표준안은 XHTML, CSS 같은 기존 표준안과는 연동되지만, XUL/XAML과는 독립적으로 구성하겠다는 뜻을 가지고 있어 웹 표준으로서 기술을 주도하겠다는 생각을 가지고 있다. 웹 폼 2.0(Web Forms 2.0)은 HTML 4.01의 폼 부분의 기능을 확장하는 작업으로 웹 애플리케이션에서 사용하는 데이터 입력 및 출력 그리고 추가 등을 위해 기초적으로 필요한 작업이다. 따라서 이 표준안 작업은 꽤 많이 진척되어 2004년 연말까지 거의 완성되었다.
W3C에는 이와 유사한, IBM이 제안하여 표준안이 된 XForm이 있다. XForm은 기계들 간의 데이터 교환 표준으로 삼고, WebForm은 사용자 인터페이스에 사용하게 하여 애플리케이션 개발자들이 이해하기 쉽도록 하자는 것이 이 표준안의 취지이다. 이 표준안이 W3C나 IETF에 받아들여진다면 비 MS 진영의 브라우저 애플리케이션 개발에 획기적인 플랫폼이 만들어질 것으로 예상된다.
 |
| <그림 1> XForm과 WebForm의 관계도 |
마지막으로 웹 컨트롤 1.0(Web Controls 1.0)은 새로운 WebForm과 UI에 대한 컨트롤과 외양 표시가 가능하도록 DOM과 CSS의 기존 표준을 확장하는 작업이다. 이 부분은 기존의 DOM/CSS의 객체 사용 방법이 어느 정도 성숙되어 있기 때문에 제일 마지막에 할 작업이 될 것이다.
표준은 표준으로만 존재하는 것이 아니라 구현됐을 때 빛을 발하게 된다. 모질라와 오페라, 애플이 만드는 새로운 표준은 웹 개방성과 상호운용성 문제를 해결할 수 있는 중요한 시발점이 될 것이다. 표준이 되더라도 과연 MS가 이를 수용할지 여부는 알 수 없지만 검증된 개발 방법론을 기초로 대안을 제시할 수 있다고 생각한다.
액티브X 넘어서기, XPCOM 구현
현재 모든 플랫폼에서 모질라 계열 웹 브라우저와 오페라, 매킨토시의 사파리(Safari) 등은 공통적으로 XPCOM 플러그인을 지원한다. 이 연합은 MS를 제외시켜 IE는 게코 플러그인이 지원하지 않는 유일한 웹 브라우저이다(인터넷 뱅킹을 할 때 <화면 3>과 같은 오류 메시지가 뜨는 것도 이 때문이다. 재미있는 것은 매킨토시용 익스플로러는 XPCOM 플러그인을 지원한다는 사실이다).
 |
| <화면 3> 파이어폭스로 은행 인터넷 뱅킹 접속시 출력 화면 |
| ||||||
| ||||||
|
국내 웹사이트의 현실을 볼 때 액티브X를 지원하지 않는 파이어폭스를 메인 웹 브라우저로 사용한다는 것은 여간 힘든 일이 아니다. 물론 IE 뷰 확장이나, 액티브X 호스팅 플러그인이 있지만 어디까지나 윈도우에서 파이어폭스를 사용하는 경우에 한정돼 있으며 근본적인 해결책이라 보기도 힘들다.
이런 점에서 앞서 언급한 넷스케이프의 다중 플랫폼 플러그인 지원 정책은 주목할 만하다. 국내의 경우 국가적으로 비 윈도우 운영체제에서의 웹 사이트 접근성을 높이려는 방안 등이 모색되고 있어 더욱 의미가 있다. 물론 액티브X가 이미 수많은 웹 사이트에 만연(?)해 있어, 일부 중복 개발의 우려가 있는 것도 사실이다. 그러나 플러그인 하나를 개발해 다양한 플랫폼에서 (IE를 제외한) 다양한 웹 브라우저를 지원할 수 있다는 점은 이런 우려를 불식시키기에 충분해 보인다.
파이어폭스의 XPCOM 플러그인은 XPCOM의 컴포넌트로 분류돼 플랫폼에 독립적인 공통 인터페이스를 제공한다. 넷스케이프 게코 플러그인 SDK를 이용해 개발하는데, SDK에 포함된 XPIDL로 플러그인에 접근하기 위한 타입 라이브러리를 만들고, 자바스크립트를 통해 스크립터블(scriptable : 호스트 오브젝트를 IDL을 통해 스크립트처럼 사용함을 말함)하게 접근할 수 있는 인터페이스를 만드는 것이다.
플러그인의 내부는 플러그인 측면(Plug-in side) API, 브라우저 측면(Browser side) API(동작 원리에서 설명), XPIDL에서 선언한 인터페이스들을 구현함으로써 완성된다. 이 때 한번 작성된 IDL(Interface Definition Language)과 플러그인은 플랫폼 독립적으로 유지, 보수할 수 있는 것이 특징이다(이 부분은 <그림 2>을 참조하면 이해가 쉽다). 빌드가 끝난 플러그인은 다음과 같이 각 플랫폼에 적절한 동적 라이브러리 형식을 취하게 된다.
◆ MS 윈도우 : Dynamic Link Library(.dll)
◆ 유닉스 : Share Object(.so 혹은 .dso)
◆ Mac OS : PPC Shared Library(.dylib)
이는 표준 인터페이스를 이용해 플랫폼 변화에 유연하게 대처할 수 있다는 장점이 있다. 플랫폼에 유연하다는 것 자체가 액티브 X에서는 불가능했던 개념으로, 플랫폼마다 최적의 네이티브 코드(native code)를 플러그인에 접목시켜 각 플랫폼의 특성에 맞게 작성할 수 있다. 그러나 각 플랫폼마다의 네이티브 코드를 고려해야 하고, 빌드를 따로 해야 하는 번거로움이 있다.
 |
| <그림 2> 넷스케이프 플러그인의 구조 |
플러그인 동작 원리
파이어폭스용 넷스케이프 플러그인은 기본적으로 다음 과정을 거쳐서 실행된다.
[1] MIME 타입에 해당하는 플러그인의 유무 검사
[2] 플러그인이 존재한다면 해당 플러그인을 메모리에 로드
[3] 플러그인 초기화
[4] 해당 플러그인의 인스턴스 생성
로딩된 플러그인 인스턴스는 다른 파이어폭스 브라우저 창에서 동시에 접속할 경우 인스턴스가 각각 생성되며 사용자가 해당 웹 페이지를 닫으면 소멸된다. 플러그인 오브젝트와 관련된 API는 플러그인 측면 API로 분류돼 브라우저가 콜백 함수처럼 호출한다. 브라우저 측면 API는 플러그인에서 호출하는 함수로, 메모리, 스트림, URL 제어 관련 함수들이 포함되며, 플러그인 측면 API처럼 플랫폼에 따라 적절하게 구현할 수 있다(양 측면 API 모두 사용자가 플랫폼의 특성을 고려하여 적절하게 구현할 수 있다). 모질라 웹 사이트(lxr.mozilla.org/)에 접속하면 다양한 플러그인 예제들을 볼 수 있다.
파이어폭스 플러그인 개발
그럼, 리눅스, 파이어폭스 환경에서 스크립터블하게 플러그인을 작성하는 예제를 본격적으로 살펴보자. 먼저 <리스트 1>과 같이 XPIDL을 정의한다.
이 때 XPIDL 내에서 사용할 수 있는 데이터 타입과 플러그인 내부에서 매치되는 타입은 <표 1>과 같다.
 |
| <표 1> XPIDL 타입과 플러그인에서 사용되는 타입간 관계 |
wstring(플러그 인 타입 PRUnichar*에 해당하는) 타입은 UTF-16이며, 리눅스 glibc에서 사용하는 wchar* 타입은 UTF-32이므로 타입 사용에 있어 혼동하지 않기 바란다. 아울러 처리하게 될 문자들이 모두 ASCII로 이뤄지지 않는 이상 반드시 wstring을 선언해서 구현해야 한다. 이제 플러그인에서 include하는 헤더를 생성한다. -m header는 IDL에 대한 헤더를 출력하는 옵션으로 확장자가 .h로 생성된다.
xpidl -I /home/hkyang/gecko-sdk/xpcom/idl -m header nsIXecurePlugin.idl
생성된 헤더 파일의 내용은 다음과 같다. 함수의 첫 글자가 모두 대문자로 바뀐다는 사실에 유의하자. 각 함수에 대한 코멘트(comment)는 자동으로 생성된다. GetVal, SetVal는 선언한 long 타입의 attribute val 변수의 값을 설정하고 얻어올 수 있는 함수이다. attribute마다 한 쌍의 getter, setter 함수가 존재한다.
class NS_NO_VTABLE nsIXecurePlugin : public nsParentClass {
…
/* void foo1 (); */
NS_IMETHOD Foo1(void) = 0;
/* void foo2 (); */
NS_IMETHOD Foo2(void) = 0;
…
}
이 때 함수의 반환형은 NS_IMETHOD로 선언되며 플러그인 내부에서 NS_IMETHODIMP 타입으로 구현된다. NS_IMETHODIMP 타입은 플러그인 함수 호출에 대한 성공 여부, 실패 시 상태 값을 가진다. 자세한 내용은 SDK의 xpcom/nsError.h 파일을 참조하기 바란다. 함수 반환 값은 void로 선언하지 않은 이상 모든 경우에서 함수의 마지막 인자로 _retval 변수의 해당 타입에 해당하는 포인터로 선언된다. 이제 파이어폭스와 플러그인 사이의 인터페이스용 타입 라이브러리를 만들 차례다. -m typelib 옵션을 통해 생성하며 확장자가 .xpt로 생성된다.
xpidl -I /home/hkyang/gecko-sdk/xpcom/idl
-m typelib nsIXecurePlugin.idl
이제 플러그인 측면 API를 구현한다. 예제 사이트에 보면 각 플랫폼 별로 구현돼 있어 수정할 일이 거의 없지만 디버깅할 일이 있을지도 모르니 한번 다뤄보는 것도 좋다.
| ||||
| ||||
이제 플러그인 헤더를 정의한다. 플러그인이 스크립터블하기 위해서는 nsIClassInfo 클래스를 상속받아 구현해야 한다. nsIClassInfo 클래스는 모질라 시큐리티 매니저(mozilla security manage)가 자바스크립트의 해당 플러그인에 접근하도록 허가한다. IDL 인터페이스에서 선언한 nsIXecurePlugin 클래스와 플러그인을 스크립터블하게 접근하기 위해 상속받은 nsClassInfoMixin 클래스를 다중 상속받아 nsScriptablePeer를 선언한다.
class nsClassInfoMixin : public nsIClassInfo
{
…
}
class nsScriptablePeer : public nsIXecurePlugin,
public nsClassInfoMixin
{
…
}
이제 앞에서 선언한 nsScriptablePeer 클래스의 내부를 구현한다. IDL 파일에서 선언한 Foo1(), Foo2() 인터페이스의 내용을 구현해주면 된다.
NS_IMETHODIMP nsScriptablePeer::Foo1()
{
…
return NS_OK; // 플러그인이 정상적으로 호출되었음을 나타낸다.
}
이제 테스트에 사용할 html 페이지를 만들어 보자. 액티브 X와 XPCOM 플러그인 모두를 지원하며, 여기서는 EMBED invokeURLs=false 태그를 사용했지만 OBJECT 태그를 사용할 것을 권장한다. EMBED invokeURLs=false 태그는 파이어폭스에서 지원하기는 하나, 표준이 아니며 어디까지나 호환성을 위해 지원하는 것이다.
| ||||
| ||||
빌드가 끝난 후 최종적으로 생성된 타입 라이브러리 파일은 웹 브라우저 디렉토리 하단의 components 디렉토리에, 플러그인 라이브러리 파일은 웹 브라우저 디렉토리 하단의 plugins 디렉토리에 복사하거나 다른 디렉토리에 저장하고 심볼릭 링크를 걸어주면 인식된다. 타입 라이브러리 파일이 정확히 설치됐는지 여부는 다음과 같이 확인할 수 있다.
[hkyang@localhost xw_plugin]$ ls /파이어폭스/components/*.xpt -al
-rwx------ 1 root root 1636 1월20 17:34 /파이어폭스/components/nsIXecurePlugin.xpt
플러그인에 대한 라이브러리 파일은 추후 관리가 용이하도록 심볼릭 링크를 걸어두는 것이 편하다.
[hkyang@localhost xw_plugin]$ ls /firefox/plugins/ -al
drwxr-xr-x 2 root root 4096 12월24 17:54 .
drwxrwxr-x 11 hkyang hkyang 4096 12월15 11:26 ..
lrwxrwxrwx 1 root root 46 12월24 17:54 libXecure.so
-> /home/hkyang/.softforum/XecureWeb/libXecure.so
이제 <화면 4>와 같이 about:plugin 페이지에서 플러그인이 정상적으로 설치되었는지 최종적으로 확인해 볼 수 있다.
 |
| <화면 4> 플러그인 설치 여부 확인하는 about:plugin |
파이어폭스에서 인터넷 뱅킹을!
<그림 3>은 필자가 참여한 리눅스용 인터넷 뱅킹 데모 화면의 일부이다. 현재 리눅스 유저들이 인터넷 뱅킹을 할 수 없었던 이유는 플러그인에 대한 지원이 미비하고 인터넷 뱅킹 클라이언트가 없었기 때문이다. 클라이언트의 경우 XPCOM 플러그인이 플랫폼에 유연하게 대응할 수 있기 때문에 리눅스를 포함한 윈도우 이외의 운영체제에서 빠르게 포팅할 수 있도록 설계, 구현했다.
 |
| <화면 5> XPCOM 플러그인을 이용한 인터넷 뱅킹 |
플러그인의 경우 이미 수많은 사이트에서 액티브 X로 적용이 이뤄졌기 때문에 구축된 사이트의 변경 작업을 최소화하도록 설계 방향을 잡았고, 그 결과 XPCOM 플러그인을 사용하기로 결정했다. 기존에 구축한 사이트는 앞서 <리스트 3>처럼 user agent string을 구분해 <object> 태그를 걸어주기만 하면 모든 운영체제와 웹 브라우저를 지원할 수 있으며, 윈도우와 동일하게 작동한다.
물론 이 플러그인은 운영체제만 동일하다면 리눅스 환경의 오페라에서도 코드 수정없이 실행된다(참고로 오페라는 자신의 플러그인 디렉토리에 설치하지 않더라도 넷스케이프, 파이어폭스에 설치된 플러그인 위치만 지정하면 직접 가져다 쓸 수 있다).
현재 XPCOM 플러그인의 가장 큰 걸림돌은 플러그인을 xpinstall 형태로 배포하는 과정에서 XPI의 서명 검증 문제다. 사용자는 플러그인의 배포자가 누구인지, 또 그 플러그인이 합법적으로 배포되어 사용자의 웹 브라우저에 설치될 수 있는 것인지 검증할 수 없다는 것이다. 그러나 플랫폼 독립적이고 다양한 웹 브라우저를 지원하는 플러그인이라는 점에서 액티브 X 의존적인 시장에 변화가 있었으면 하는 것이 필자의 바람이다.
실제 변화를 추동하는 데에는 기업과 개발자가 담당해야 할 몫이 있다. 채 10%가 안되는 파이어폭스 사용자를 고려하지 않는다는 것은 기회 비용의 10%를 배제하고 개발하는 것과 다를 바 없기 때문이다. 이는 단지 10이라는 숫자가 1이었다 하더라도, 역으로 파이어폭스가 99이고 IE가 1이 되는 상황이 된다 해도 의미의 크기는 변함이 없다.@
