ActiveX, Vista, 그리고 웹표준이야기

올해 들어 많은 블로그나 언론 기사에서 한국에서만 난무하는 무분별한 ActiveX 컨트롤에 대한 글들이 쏟아지고 있습니다.

수년 동안 클라이언트 프로그램과 웹에서 동시에 사용할 수 있다는 최고의 개발 기술로 여겨졌던 ActiveX(COM) 의 몰락을 바라보면서, 아직까지 ATL 을 사용한 COM 개발 및 유지보수를 하고 있는 개발자로서 허탈감을 감출 수가 없네요.

오늘은 COM 과 비스타, 그리고 ActiveX 의 몰락과정에 대한 생각들을 적어 보려고 합니다.

COM, ActiveX

사실 COM(Component Object Model) 은 90년대 후반부터 2000년대 초까지만 해도 수많은 개발자를 먹여 살린 마이크로소프트의 효자 종목이었습니다.

COM 은

-       프로그램 언어 중립적이며(Language Independent)

-       파일 설치 위치에 상관없이 실행가능하며(Location Transparency)

-       DCOM 으로의 확장을 통해 원격에 있는 RPC 호출의 표준이 되고자 했었습니다.

ActiveX 는 이러한 COM 의 단순 리네임에 불가합니다. (처음에 ActiveX 는 웹에서 사용되는 COM 기술로 여겨지다가 이후 마이크로소프트는 두 단어를 혼용해 사용했습니다)

COM 은 결국엔 마이크로소프트 혼자만의 DE FACTO 표준이었지만,

-       OOP 개념으로 설계되어졌고

-       인터페이스기반으로 만들어져 프로젝트가 커질수록 발생할 수 있는 Dependency를 최소화 할 수 있으며

-       서로 다른 프로그램도 그 인터페이스만 알고 있다면 오늘날 웹 2.0 의 Open API 와 같이 손쉽게 사용할 수 있도록 되어 있습니다

 

“Developer’s Workshop To COM and ATL 3.0” 이라는 책에서 COM 에 대한 개념과 장밋빛 앞날에 감명받아 2000년도 이후 제가 개발하는 프로젝트의 중요 CORE 부분을 ATL 기반 COM 인터페이스로 만들기 시작했습니다.

 

이렇게 개발된 CORE 프로그램은 서로 다른 프로그램에서 호출할 수 있었고, 비록 IE 에서만 가능한 일이었지만, 웹에서도 해당 프로그램을 코드 수정 없이 바로 올려볼 수 있다는 엄청난 장점이 있었습니다.  이런 이유로, C/S 프로그램과 웹 프로그램을 한번 만든 코드로 재사용할 수 있다는 큰 장점 때문에 점점 더 많은 ActiveX를 양산하게 되었습니다.

 

가끔씩 네스케이프 사용자나 불여우 브라우저 사용자로부터 불평이 있긴 했지만 대부분의 사용자가 IE 사용자라고 믿고 있었고, 이보다 더 좋은 솔루션은 없다고 생각했기 때문에 거의 무시로 일관했었습니다.

 

Vista 의 출현과 그에 따른 파장

올해 초 마이크로소프트 비스타가 나오면서 상황은 180도 변했습니다.

마이크로소프트 비스타에서

-       모든 어플리케이션은 사용자가 어드민 권한을 가지고 있다고 하더라도 사용자(User) 권한으로 실행됩니다.

-       웹 브라우저는 사용자 권한보다 한 단계 낮은 권한으로 실행되며

-       ActiveX 설치는 어드민 권한으로의 권한상승(Escalation) 을 요구하고

-       PC 의 파일 핸들링이나 프로그램 실행, 레지스트리 변경 등 위험할 수 있는 작업은 권한상승이 허락된 별도 포맷의 ActiveX를 만들어야만 가능하도록 변경되었습니다.(사용자가 권한상승을 허락한 경우에만 작동)

 

이 얘기는 비스타에서 그 동안 ActiveX 를 이용해서 가능했던 대부분의 기능들이 중단되거나, 별도의 권한 상승 허락을 받아야만 가능하게끔 변경되어서 기존 ActiveX를 비스타용으로 별도로 개발 & 배포해야 함을 의미합니다.

 

이로 인해 2007년 2월 1일 비스타 출시를 앞두고 국내 대부분의 은행과 증권사, 카드회사, 그리고 보안관련 회사는 한차례 대혼란을 겪어야 했습니다.

다름아닌, 정통부 지시에 의해 모든 은행과 증권사에 설치된 공인인증서, 키보드 보안 프로그램, 개인방화벽이 모두 수정되어야 했기 때문입니다.

다행히 공인인증서와 관련된 모듈은 대부분 2월 1일 비스타 출시와 함께 대부분 일부 기능에 대한 어드민 권한상승으로 해결해서 오픈 했지만, 키보드 보안 프로그램등과 같은 OS 와 밀접하게 연관된 ActiveX 는 출시가 연기되어 결국에는 은행 및 증권사에 로그온 조차 할 수 없는 초유의 일이 벌어졌습니다.

이때부터 각종 언론 및 블로거들의 비난이 쏟아지기 시작했습니다.

전세계 비스타 오픈을 앞두고 이런 난리가 난 나라가 대한민국밖에 없었기 때문입니다.

 

정통부, 금감원 그리고 ActiveX

사실 대한민국의 모든 금융사이트가 ActiveX를 보안 프로그램으로 선택한 데에는 정통부, 금감원과 같은 정부의 영향이 큽니다.

얼마 전 개정된 전자금융거래법 및 전자금융감독규정에 따르면 해킹 등으로 인한 사용자 피해에 대해 금융기관이 책임을 지도록 명시하고 있습니다. 이 말은 키보드 해킹 등으로 고객의 비밀번호를 획득한 제 3자에 의해 고객이 피해를 입을 경우 배상책임이 금융기간에 있음을 의미합니다. 또 금감원은 전 금융기간에 키보드 보안 프로그램 및 개인 방화벽프로그램설치를 강제화 하도록 감독, 감시하고 있습니다.

금융기관입장에서는 이러한 피해를 최소화하기 위해, PC 의 키보드 드라이브까지 제어할 수 있는 키보드 보안 프로그램을 필수적으로 설치하지 않을 수 없게 됩니다.  이러한 기능을 웹에서 구현하기 위해서는 표준이 아니긴 하나 ActiveX이외에 다른 대안이 없습니다.

또한 정통부에 의해 전 금융기관에 의무적으로 설치하게 되어 있는 공인인증서는 인증서 내보내기, 인증서 발급받기 등 파일 핸들링 부분에서 역시 ActiveX 가 아닌 다른 웹 표준 기술로 구현하기 힘든 요건을 가지고 있습니다 (개인적으로 키보드 해킹 프로그램에 의해 간단하게 비밀번호가 노출되어 재발급 받아 질 수 있는 공인인증서를 왜 국가적 차원에서 전 금융기관을 의무화 했는지 납득하기 힘듭니다.)

이런 저런 이유 등으로 대한민국 금융기관은 특정 브라우저, 특정 기술(ActiveX) 에 의존하는 기형적인 금융사이트를 구축했고 이 과정에서 각 금융회사마다 서로 다른 보안 업체와의 계약 및 자체 개발로 인해 사용자가 생각하기도 끔찍할 만큼 수 많은 ActiveX를 설치하여야만 했습니다.

 

마이크로소프트, ActiveX, .NET 3.0

서두에 얘기한 것과 같이 COM 은 몇 년 전까지만 해도 마이크로소프트의 주요 전략 중에 하나였습니다. (대부분 MS 제품들은 IE나 OFFICE 를 포함해서 모두 COM 인터페이스 형식으로 접근 가능합니다) 그러던 것이 마이크로소프트 .NET 이 나오면서 점점 COM으로의 개발이 필요 없어지게 된다는 얘기가 나오기 시작했습니다.  윈도우 XP 이상에서만 가능한 .NET 은 모든 프로그램이 중간언어 단계로 컴파일 되어 수행되기 때문에 언어중립성을 위해 COM 형식으로 프로그램 할 필요가 없어지게 되고 위치 투명성에 대한 정보도 MANIFEST 를 이용할 수 있게 되어 더 이상 COM 기반 기술이 중요하지 않게 되었고, 자바진영과의 전쟁을 위한 전략적 대 전환으로 .NET 을 밀게 되었습니다.

윈도우 비스타로 가면서 마이크로소프트는 .NET 2.0을 .NET 3.0으로 업그레이드 하고 WPF 와 같은 멋진 UI 기술로 개발자를 유혹하고 있습니다.

이러한 마이크로소프트의 전략적 기술변화와 웹 표준과 관련된 전세계적인 트랜드를 바르게 보지 못하고, 특정 기술과 브라우저에 100% 의존할 수 밖에 없는 기술을 요건으로 제시하는 정책기반자들에 의해 ActiveX 는 모두에게 비난의 대상이 된 것입니다.

 

하위호환성을 무시하는 마이크로소프트

조엘 스폴스키가 쓴 “조엘 온 소프트웨어” 책에는 윈도우 95 출시 당시 윈도우 3.1 용 어플리케이션을 윈도우 95에서도 완벽하게 돌아갈 수 있게끔 노력했었던 마이크로소프트의 눈물 나는 노력에 대한 얘기가 나옵니다.

 

“마이크로소프트사는 이 점에 대해서만은 병적으로 집착했습니다. 옛날 프로그램을 모두 구해다 윈도우 95에서 테스트하느라 엄청난 시간을 투자했습니다. 윈도우 3.X 용 심시티를 만들었던 존 로스가 제게 해 준 이야기가 있습니다. 심시티에 해제한 메모리를 다시 읽는 버그가 있었는데, 메모리를 그냥 내버려 두는 윈도우 3.X 에서는 문제가 없었답니다. 여기서부터가 놀랐습니다. 윈도우 95 베타 버전에서 심시티가 돌아가지 않았습니다. 마이크로소프트사는 버그를 찾은 후, 윈도우 95에서 심시티를 처리하기 위한 특별 코드를 추가했습니다. 윈도우 95 에서 심시티가 돌고 있으면, 메모리 할당자는 특수 모드로 들어가 메모리를 즉각 해제하지 않습니다. 사용자가 윈도우 95 로 기꺼이 업그레이드하게 된 배경에는 하위 호환성을 보장하겠다는 이런 철저함이 도사리고 있습니다.”

 

하위호환성을 위해 잘못된 타사 어플리케이션까지 보완해 주던 마이크로소프트는 수년 전부터 정책을 바꾼 듯 합니다. 윈도우 XP까지 문제 없이 돌아가던 프로그램들이 윈도우 비스타에서는 정상적으로 수행되지 않는 경우가 비일비재 합니다.

특히 게임 프로그램이 그러하고 UAC 문제가 걸리면 귀찮은 어드민 권한으로의 상승을 요구하는 대화상자를 매번 확인해 줘야 합니다. (이 때문에 저는 아직 비스타로 업그레이드를 하지 않고 있습니다)

마이크로소프트의 정책이 어떻든 이전 XP 에서 문제 없이 잘 돌아가는 프로그램이라면 OS 업그레이드 버전인 비스타에서도 역시 잘 돌아가야 했습니다. 단지 마이크로소프트가 미국회사이고 미국 개발자들에게는 전혀 이슈화가 되지 않기 때문에 한국의 LEGACY 어플리케이션을 지원하지 않는 다는 것은 정말이지 이해하기 힘든 경우였습니다. (한국에서 ActiveX 를 Abuse 했다 치더라도!)

물론 ActiveX 에 의한 컴퓨터 초보자들의 피해를 보완하기 위한 방법은 반드시 있어야 합니다. 하지만 이번 비스타의 경우처럼 하위호완성과 기존 개발자들을 무시한 정책은, 마이크로소프트가 제공하는 개발 툴로 먹고 살고, 소위 말하는 마이크로소프트빠의 한 사람인 저 같은 개발자도 동의할 수 없네요.

Adobe Flash 그리고 웹 표준,

요즈음 웹 표준과 관련된 책이나 블로그들의 글을 많이 읽으면서 특정 브라우저에 국한된 기술에 대한 문제를 다시 알게 되는 계기가 되었습니다.  

전세계 97% 이상의 브라우저에 설치되어 있다는 Adobe 사의 Flash 는 사실 IE 에서는 ActiveX로 작동합니다. 다른 ActiveX와 차이가 있다면

-       IE 이외의 불여우와 같은 다른 브라우저에서도 사용할 수 있고

-      윈도우, MAC, SOLARIS, HP-UX, POCKET PC, OS/2, QNX, SYMBIAN, PALM OS, BEOS, IRIX 와 같은 다양한 운영체제에서도 할 수 있다는 점 때문입니다

왜 우리 나라는 이런 범용성을 등한시 했을까요? 사용자가 적다는 이유로, 소수를 무시하는 개발자, 정책수립자의 잘못된 생각 때문이 아닐까요?