My Words, Your Memory

ActiveX 컨트롤이 웹 생태계에 미치는 가장 나쁜 영향은, 웹을 Windows 라는 OS에 의존적으로 만든다는 것이다- 라고 생각하기 쉽지만, "실제로" 일어나는 일은 이런 것이다.

ActiveX 컨트롤을 사용한다
-> IE만 컨트롤을 지원한다
-> IE 이외의 브라우저들에서는 테스트되지 않는다
-> 각종 HTML Tag, CSS, Javascript 들 중 IE에서만 정상 동작하는 코드들이 끼어든다.
-> 위에서 뭐라고 한다
-> IE가 아닌 모든 브라우저에 대해서는 'Netscape는 지원하지 않습니다' 라는 경고 문구를 발생시키고 잊어버린다
-> 사이트가 커진다. 여전히 IE 외에서는 테스트되지 않는다. 같은 상황이 이어진다.
-> 위에서 뭐라고 한다
-> 사이트를 고치려고 해보지만 이미 너무 많은 부분을 갈아 엎어야 한다. 비용이 증가한다.
-> 비용상의 이유로 포기한다.

실제로 많은 경우, ActiveX 컨트롤을 만들 수 있는 기술이 있다면 같은 일을 하는 Netscape Plugin 도 어렵지 않게 만들 수 있지만- 그런 Netscape Plugin을 적용하는 것은 사이트 입장에서 부대 비용이 너무 많이 발생하게 되므로 '기각'되기 십상이다. 즉, 솔루션을 제공하는 업체가 Netscape Plugin과 ActiveX 컨트롤을 함께 제공하는 경우에도, 웹 사이트 자체가 IE 전용 코드들로 만들어지기 때문에 plugin 을 사용할 수 없는 상황이 벌어지는 것이다.

ActiveX Container 만드는 것 보다, ActiveX 컨트롤에 연계된 Legacy Javascript/VBScript 들과의 호환성을 맞추는게 더 어렵다. ActiveX 컨트롤을 지원하는 것 자체는 웹브라우저의 내부 Component Model 과 MS-COM 간의 Bridge 를 만들어주는 방식으로 구현할 수 있지만, 그렇게 올려놓은 컨트롤들이 정작 웹 페이지와 제대로 통신을 못하는 엿같은 상황은 누구도 어떻게 해줄 수 없는 것이다. 세상엔 능력있는 개발자들이 많고, 적절한 기회가 있다면 Mozilla 소스를 고쳐서 ActiveX를 지원하게 해줄 수도 있는 거고, 구글 친구들도 ActiveX 지원하게 WebKit을 고쳐줄 수 있는 거지만 이미 존재하는 사이트들의 코드를 다 고쳐줄 수는 없는 것이다.

어쩌란 말인가. 어차피 ActiveX 컨트롤들로 부터 한번에 벗어날 수는 없는 노릇이고, 조금씩 대안을 찾아갈 수 밖에 없다면, 그 첫걸음은 대안 기술을 찾는 것이 아니라 사이트를 철저하게 표준 호환으로 만드는 것이다. 대안은 조금씩 늘어날 것이나, 있어도 선택할 수 없는 대안이라면 이미 대안이 아니다.

큰 틀에서 보고, 조금씩 바꿔나갈 수 있는 토양을 만들어나가야 한다는 얘기다. 이대로는 설령 ActiveX 컨트롤들이 대한민국에서 사라진다고 하더라도, 그와 유사한 다른 문제들에 시달릴 수 밖에 없지 않겠는가? 특정 회사의 특정 기술에 의존하는 웹이란 결국 재앙을 불러일으키게 될 것이다. ActiveX는 그런 의미에서 대표적인 '발암물질'이라 할테지만, 어디 꼭 ActiveX 뿐이겠는가.