이 글은 오래된 전에 작성된 글입니다. 따라서 최신 버전의 기술에 알맞지 않거나 오류를 유발할 수 있습니다.
저자는 이 글에 대한 질문을 받지 않을 것입니다. 하지만 이 글이 리뉴얼 되면 이 글에 대한 질문을 하거나
토론을 할 수도 있습니다.
얼마 전 글을 포스트하고 검색을 해 보니, 이번 패치에 대해 잘못 이해하는 내용의 글들을 많이 발견할 수 있었습니다. 그만큼 제대로 된 홍보가 안되었다고 밖에 생각이 안되더군요. 그래서 이번 패치에 대해 대표적으로 잘 못된 오해 몇 가지를 이야기 할까 합니다. 여기서 다루는 내용은 IE 업데이트에 대한 기술적 FAQ 문서와 상당히 중복되는 것도 있습니다만, 제 개인적인 견해와 더불어 직접 테스트한 내용을 같이 포함시켰으므로 이 글과 FAQ 문서를 모두 참조하시는 것이 좋습니다.
극적으로 MS가 IE 업데이트를 취소하지 않는 한, 어차피 업데이트가 진행된다면 니가 잘했네 못했네를 논하는 것 보다 SP2 때와 같은 혼란을 겪지 않기 위해 업데이트에 대한 정확한 내용을 이해하는 것이 중요하다고 생각합니다. 더불어, 이러한 사항을 주위의 여러 개발자, IT 관리자, 웹 마스터 등에게 알리는 것 역시 중요하다고 생각합니다. 이 글을 읽는 독자 분들도 2월 15일 1차 업데이트와 4월에 예정된 2차 업데이트를 준비할 수 있도록 주위 분들에게 알려 주셨으면 합니다.
저는 MS 직원도 아니며, MS에 뭘 바라고 이런 글을 쓰는 것도 아닙니다(튀기는 똥물도 없겠지만...). 다만 개발자들이 이로 인해 급하게 며칠 밤을 새우는 일이 없기를 바라는 마음이며, MS 기술이라면 무슨 독배를 마시는 것처럼 무조건 싫어하는 시각이 싫어서 이 글을 씁니다. 개인적으로 COM, .NET 등의 MS 기술이 좋을 뿐이지 MS라는 회사를 좋아 하진 않습니다. 그렇다고 싫어하지도 않지요... 킁... 킁...
Misunderstanding of New IE Update
2월 계획된 IE의 ActiveX 활성화(Activation) 변경에 대한 패치를 놓고 오해가 많은 것 같아서 좀 정리를 하고자 한다. 병적인 반 MS 감정과 이상한 풍문까지 더해져서 IE를 사용하지 말자는 의견부터 Windows 대신 Linux를 쓰자는 의견까지 분분하게 나오고 있다. 이런 의견을 개진하기 전에 IE의 패치가 어떻게 영향을 주는가 확실히 파악하는 것이 우선되어야 할 것이다. 여기에 나온 내용은 필자가 IE Update Preview를 설치하고 테스트한 결과를 기반으로 한 것이므로 앞으로 나올 실제 패치와는 다를 수 있음에 유의해 주기 바란다.
패치 이후 OBJECT, EMBED, APPLET 태그는 사용할 수 없다?
그렇지 않다. 패치 후에도 OBJECT, EMBED, APPLET 태그는 여전히 사용할 수 있다. 다만 HTML 내에 직접적으로 이들 태그가 사용되면 컨트롤들은 비활성화된 채로 로드 된다. 비활성화된 컨트롤은 사용자 입력에 반응하지 않는다. 예를 들어 키보드 입력이나 마우스 이동을 추적하거나, 마우스 클릭을 감지하는 등의 사용자 입력은 컨트롤에 전달되지 않는다. 또한 컨트롤은 활성화 되기 전에는 DHTML 이벤트 역시 발생시키지 않는다. 사용자가 컨트롤을 클릭하여 활성화 한 후에는 이전과 동일하게 작동한다. 이는 컨트롤이 활성화되기 전에는 윈도우 메시지(WM_MOUSEMOVE, WM_LBUTTONDOWN, WM_KEYDOWN 등)의 일부를 컨트롤에 전달하지 않기 때문이다. 하지만 컨트롤을 표시하는데 필요한 WM_PAINT, WM_TIMER 등의 메시지는 컨트롤 활성화 여부에 관계없이 전달된다. 항상 전달되는 윈도우 메시지의 전체 목록은 ActiveX 컨트롤 활성화 관련 기술 문서에서 확인할 수 있다.
모든 ActiveX 컨트롤이 영향을 받는다?
그렇지 않다. IE의 새로운 패치는 UI를 갖는 컨트롤들에만 영향을 준다. 앞서 IE가 활성화되지 않은 컨트롤에 윈도우 메시지를 전달하지 않는다는 것에서 명확하게 알 수 있다. UI를 갖지 않는 ActiveX 컨트롤들은 IE의 새로운 패치와 무관하게 작동한다. 비활성화된 컨트롤도 스크립트로부터 호출되는 메쏘드나 속성 액세스에는 반응하기 때문이다. 금융권에서 사용하는 보안 관련 ActiveX 컨트롤은 이번 패치와 무관하게 작동할 것이다. 이들은 대부분 UI를 갖지 않고 주어진 데이터를 암호화/복호화 하는 데만 사용되는 것이 대부분이기 때문이다.
UI를 갖더라도 사용자 입력을 전혀 받지 않는 컨트롤 역시 이번 패치와는 무관하게 작동할 것이다. 예를 들어 단순히 웹 페이지에 동영상을 표시하기 위해 사용되는 플래시는 사용자가 클릭과 같은 사용자 입력을 하지 않을 뿐더러 컨트롤이 이것을 기대하지도 않기 때문에 이번 패치의 영향을 받지 않는 것으로 간주할 수 있다. 다만 마우스가 비활성화된 컨트롤 위로 움직이면, 컨트롤이 비활성화 되어 있음을 알리는 영역 사각형이 컨트롤 주위에 나타날 것이다.
MS의 가이드 대로 외부 스크립트를 통해 컨트롤을 만들어도 활성화 과정이 필요하다?
그렇지 않다. 필자가 직접 테스트한 결과 ActiveX 컨트롤 활성화 관련 기술 문서의 지침대로 HTML을 수정하면, 컨트롤이 활성화 된 채로 로드 되었다. 즉, 외부 스크립트 파일(대개 *.js)의 스크립트에 의해 OBJECT, EMBED, APPLET 요소가 동적으로 생성되면 이들에 의해 생성되는 컨트롤은 곧바로 활성화되어 마우스에 반응하는 등의 사용자 입력을 수용했다. IE가 업데이트 되더라도 업데이트 되기 전과 동일한 웹 페이지를 원하는 사이트라면 지금 곧바로 웹 페이지를 가이드 대로 수정하는 것이 좋을 것이다. 한가지 주의할 사항은 HTML 페이지 내에 직접 작성된 스크립트 코드는 효과가 없다는 것이다. 분쟁 중인 특허는 HTML 문서 내부에 사용되는 태그와 스크립트에 의해 컨트롤이 자동으로 활성화 되는 기술에 대한 것이므로 반드시 외부 스크립트 파일이 사용되어야 한다는 점을 기억하자.
이 부분은 구체적인 예를 들어 설명하겠다. 다음 HTML은 ActiveX 컨트롤(필가 작성한 임의의 컨트롤이다)사용하는 웹 페이지이다(리스트1).
<html>
<body>
<object classid="clsid:E99E2B4A-4446-41E2-9400-BF8CCB1F8D32"></object>
</body>
</html>
리스트1. ActiveX 컨트롤을 사용한 HTML 예제
위 HTML 이 IE 업데이트 이후 사용되면 화면1과 같이 컨트롤이 활성화 된 후라야 사용자 입력을 받게 된다.
화면1. IE 업데이트 적용후 비활성화 된 ActiveX 컨트롤
OBJECT 태그가 직접적으로 사용되었으므로 ActiveX 컨트롤이 비활성화 된 채로 로드 된 것이다. OBJECT 태그를 직접적으로 사용하지 않고 리스트2와 같이 스크립트의 document.write 메쏘드를 통해 OBJECT 요소를 만들면 어떨까?
<html>
<body>
<h1>New IE ActiveX Activation Model Test</h1>
<script>
document.write("<object classid='clsid:E99E2B4A-4446-41E2-9400-BF8CCB1F8D32'></object>");
</script>
</body>
</html>
리스트2. document.write를 이용하여 OBJECT 요소 생성. 여전히 비활성화 된다.
HTML 문서 내에 직접적으로 포함된 스크립트에 의해 생성된 OBJECT 요소는 ActiveX 컨트롤이 비활성화 되는 것을 막지 못한다. 스크립트에 의해 생성할 때는 반드시 스크립트가 외부 파일로 존재해야 하며 SCRIPT 태그의 src 속성에 의해 참조 되어야만 한다.
HTML Content :
<html>
<body>
<script src="activate.js"></script>
</body>
</html>
activate.js file :
document.write("<object classid='clsid:E99E2B4A-4446-41E2-9400-BF8CCB1F8D32'></object>");
리스트3. 외부 스크립트 사용으로 ActiveX 컨트롤은 곧바로 활성화 된다.
스마트 클라이언트는 ActiveX가 아니므로 이번 업데이트와는 무관하다?
브라우저에 임베딩 되는 스마트 클라이언트는 필자의 스마트 클라이언트 원리에 대한 글에서 밝혔듯이 ActiveX 와 동일한 방식을 취한다. IE 브라우저에게 있어서 스마트 클라이언트는 ActiveX와 전혀 다를 바 없는 컨트롤이다. 뭐 OBJECT 태그가 사용된다는 점에서 당연하게 여길 수 있겠다.
따라서 브라우저 임베디드 스마트 클라이언트 역시 이번 IE 업데이트의 영향을 받게 된다. 즉 ActiveX 컨트롤 활성화 관련 기술 문서의 지침대로 HTML을 수정하지 않으면 사용자와의 인터페이스를 하기 위해 활성화 과정을 거쳐야 한다. 화면2는 필자의 스마트 클라이언트, 그것을 알려주마 (II) : 맛보기 예제 에서 사용한 예제 스마트 클라이언트가 IE 업데이트 이후 나타나는 현상을 보여 주고 있다. 스마트 클라이언트가 곧바로 활성화 되지 않고 있다.
화면2. 스마트 클라이언트 역시 IE 업데이트의 영향을 받는다.
스마트 클라이언트를 임베딩 하는 웹 페이지 역시 앞서 언급한 방법 대로 외부 스크립트 파일에 의해 OBJECT를 동적으로 생성해야만 스마트 클라이언트 컨트롤이 비활성화 된 채로 로드 되는 것을 막을 수 있다.
IE 외에 다른 브라우저를 사용하면 된다?
단기적으로는 그렇지만 장기적으로는 그렇지 않다. IE 외의 다른 브라우저를 사용한다면 당장은 IE 업데이트의 영향을 받지 않고 플래시 같은 플러그 인(ActiveX와는 다르다)을 사용할 수 있을 것이다. 하지만 현재 MS가 이올라스와 캘리포니아 주립대와 특허 논쟁 중인 내용은 HTML 내에 플러그 인, 애플릿, ActiveX 컨트롤을 포함하는 컨트롤이 자동적으로(즉시) 사용자와 상호 작용하는 것에 대한 내용이다. 요즘 한창 주가를 올리는 파이어폭스 역시 플래시를 표시하기 위해 EMBED 태그를 인식하고 표시하기 때문에 이 특허가 정의하는 권리를 피해갈 수 없다. 이 때문에 MS 진영이든 반 MS 진영이든 가리지 않고 이 특허 논쟁에서 이올라스를 곱게 보지 않는 이유이다. 이올라스의 특허 분쟁은 IE 뿐만 아니라 모든 브라우저에게 적용되는 인터넷 전체 기술에 대한 분쟁인 것이다. 따라서 이번 IE 업데이트를 가지고 기술 MS에 대한 기술 종속성을 운운하는 것은 내용을 병적인 반 MS 감정으로 인한 상당한 오버이다.
만약 MS가 패소하게 되면 다른 브라우저들 역시 줄줄이 이 특허를 인정해야 할 것이며, 특허 사용료를 지불하던가 아니면 IE와 동등한 업데이트를 수행해야 할 것이다. 특허를 보유한 이올라스와 캘리포니아 주립대가 MS에게만 5억불(5천억원 이다!!!)이 넘는 특허 관련 비용을 요구하고 다른 브라우저 개발사(?)에 대해선 특허를 무료로 사용하도록 하는 이상한 시츄에이션이나, 다른 브라우저 개발사가 특허료를 지불할 능력이 있을 수도 있겠지만 그럴 가능성은 높지 않다고 본다. 고로 다른 브라우저도 장기적으로 본다면 동일한 문제에 접할 가능성이 대단히 높을 것이라는 것이 필자의 견해이다.
ActiveX를 사용하지 않으면 된다?
ActiveX 만 사용하지 않으면 될까? 꼭 그렇지만은 않다. 플래시나 애플릿 역시 이번 특허와 연관이 있으므로 플래시 광고를 사용하거나, 플래시로 메뉴를 만들거나 애플릿도 사용하지 말아야 한다. 사실 우리나라의 웹 페이지들은 필요 이상으로 매우 화려하며 많은 기능을 단일 페이지에 집어 넣으려는 측면이 있다. 문화적 차이라고 할 수도 있지만 포털 사이트의 과도한 경쟁도 한 몫을 하고 있으며, 이러한 사용자 인터페이스만을 고집하는 최종 사용자에게도 문제가 있다(이뿌지 않은 사이트는 사용자들이 자주 방문하지도 않는다). 이미 눈이 높아질 대로 높아져 버린 사람들이 ActiveX 컨트롤, 플래시 등이 제거된 썰렁한 구글과 같은 UI를 허용할까? 이제와서 ActiveX, 플래시를 쓰지 말자고 하는 것은 이미 출발한 기차를 항해 손 흔드는 거나 마찬가지 이다.
Summary
요약하자면, IE 업데이트 이후 웹 페이지를 그대로 두면 사용자와 상호작용을 요구하는 ActiveX 컨트롤들, 플래시 같은 플러그 인, 애플릿은 활성화 되지 않은 채로 로드 되게 되며 활성화를 위해 사용자는 컨트롤을 클릭하거나 탭키를 통해 컨트롤을 선택하고 스페이스 혹은 엔터 키를 눌러야 한다. 하지만 UI가 전혀 없는 컨트롤이나 사용자의 입력을 요구하지 않는 컨트롤들은 이번 업데이트의 영향을 받지 않을 것이다. 또한 외부 스크립트에 의해 OBJECT, EMBED, APPLET 태그가 동적으로 생성되는 경우, 컨트롤은 로드와 동시에 곧바로 활성화 된다. 즉, 업데이트 이전과 완전히 동일하게 작동한다. IE 업데이트는 OBJECT 태그를 사용하며 ActiveX 와 동일한 작동 방식을 갖는 닷넷 스마트 클라이언트에게도 동일하게 적용된다.
IE 업데이트의 영향을 받지 않기 위해 다른 브라우저를 사용하는 방법도 고려해 볼 수 있지만, 장기적으로 보아 다른 브라우저들 역시 IE와 동일한 특허권 침해 소송을 받을 가능성이 높다. 이올라스와 MS의 특허 분쟁은 단순히 두 회사의 문제가 아니라 인터넷 전체에 적용되는 분쟁임을 명심해야 한다.
짧은 기간에 검색을 통해 수집한 자료로 작성한 글이므로 오류가 있을 수 있다. 잘못된 내용을 지적하거나 생산적인 토론은 환영하는 바입니다만, 단순히 감정적인 반박이나 비난은 사양하는 바이다. 초글링이나 쓰는 그 따위 글은 이런 곳 말고 비 생산적인 비난을 토해내는 다른 까페, 게시판, 사이트를 이용해 주길 바란다.
Comments (read-only)
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 블로그쥔장 / 1/31/2006 1:55:00 PM
2월 15일 업데이트는 자동 업데이트가 아닌 Windows Update 사이트에서
권장 업데이트 형식으로 배포된다고 합니다.
그러나 4월12일 부터는 자동 업데이트로서 배포된다고 하니 늦어도
4월12일까지는 준비를 해야 할 것으로 보입니다.
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 달봉 / 2/1/2006 5:47:00 PM
말로만 듣던 그것이 이렇게 임박해 있었을 줄야. 흠.....!
항상 좋은 정보 감솨합니다.
새해도 건강하시고요.
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 정준명 / 2/8/2006 3:10:00 PM
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 블로그쥔장 / 2/8/2006 4:23:00 PM
http://www.nalbam.com/blog.php?seq=2951 이 글에서 나온 방법대로 테스트 해보았습니다.
잘 작동하더군요. 하지만 SafeForScripting 이 선언되지 않은 ActiveX를 OBJECT 태그로 사용하는 경우,
위 방법은 경고 창이 나타나게 됩니다만... 대부분의 ActiveX가 SafeForScripting을 지원하므로
나쁘지 않은 방법이겠군요. 게다가... 달랑 링크 목적으로 사용되는 플래시를 위해서는 간단한 방법인듯...
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 붸리준 / 6/29/2006 10:46:00 PM
저는 위에서 하는 말이 도져히 무슨말인지 몰라서 여기저기 또뒤져보다 kb912812를 삭제하라고 해서 그걸 삭제했더니 테두리가 안나타나네요
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 쿠쿠쿠111 / 11/21/2006 4:11:00 PM
^^, 드뎌 쥔장 코치대로 해서 하나 해결했다.
매번 이것도 못하면, 직업바꾸라는둥 밥숟가락을 놓으라는둥의 압력에 내적갈등이 심했는데^^
아싸, 시작이 반이다. 우리것이 좋은 것이여~~
#re: IE ActiveX 활성화 변경에 대한 진실 혹은 거짓말 / 블로그쥔장 / 11/21/2006 4:21:00 PM
ㅎㅎㅎ 축하 합니다...
제글이 도움이 되셨다니 기쁘기 한량 없습니다.