프로그램 관리자로서 기능의 사양에 대한 글을 쓰는 것은 (꼭 필요한 사항이기 때문에) 정말 즐거운 일입니다. 어떤 사양에 대해서도 프로그램 관리자는 특정 설계의 장점과 단점의 조화 (영어), 고객의 요청에 대한 배려,이용 가능한 피드백이나 원격 측정법 정보 (영어) 등에 대해서 주의 깊게 심사 숙고합니다. 이러한 정보에 근거하여, 무엇을 어떻게 만들지에 대한 가설을 세웁니다. 최선의 계획을 세우기 위한 노력에도 불구하고, 초기에는 불가능했던 몇가지 가설들이 개발과정 중에 변경됩니다. 이렇게 자주 일어나는 변경 영역 중 하나가 웹 표준에 관한 사양입니다. 따라서 현재의 상황을 재평가하고, 필요하면 제품을 변경하기 위해 스케줄에 여유를 가지고 준비했습니다.

개발 주기의 중간 쯤에 웹 표준의 변경에 대응하는 것은 여러가지 이유에서 도전적인 작업입니다. 개발자의 입장에서 엄밀하게 말하면, 기능 변경은 항상 대가를 수반합니다. 일반적으로 그 대가는 검토하여 수정하는데 시간이 필요한 일련의 제품 버그입니다.  그리고 기준이 되는 표준이 변경될 가능성이 있기 때문에 위험이 따릅니다. 변경을 검토할 때는 항상 그 영향을  주의 깊게 심사숙고 해야 합니다.

이 글에서는 웹 표준의 진화에서  최근의 중요한 사건과 Internet Explorer 8 이 어떻게 대응하는지를  설명합니다. 이 글에서는 개발 기간 중의 웹 표준 변경에 대응한다는 복잡한 난제에 대해 독특한 시점을 제공하며, 동시에 곧 출시될 릴리스 후보에서의 변화를 알려드리는 좋은 기회도 될 것입니다.

ECMAScript 3.1

ECMAScript (영어) 는 JavaScript  정의 표준이지만, 최신 업데이트는 10 년 전이었습니다. 그러나 올 초,  “ECMAScript 3.1”로 알려진 개정판이 표준화를  위해 급속한 전진을 했습니다. Internet Explorer 8 개발에 착수한 시점에서는 ECMAScript 의 새로운 버전 책정이 나와서, 우리의 개발계획과 통합하는 충분한 시간적 여유가 있다고 예상했습니다. 최근 ECMAScript 3.1 의 급속한 진전으로,  그러한 예상이 가능하게 되었습니다. 특히 ECMAScript 3.1 드래프트 (영어) 에 포함된 기능에 대해 호환성이 없는 것을 Internet Explorer 8 에 탑재하지 않도록 주의를 기울였습니다.

ECMAScript 3.1 에는 웹 개발을 쉽고 보다 강력하게 만들기 위해, 많은 JavaScript 언어 확장이 포함되어 있습니다. 이러한 기능의 하나가 JSON 지원으로,  IE 8 의 네이티브 JSON API 를 ECMAScript 3.1 드래프트에 포함된 JSON API 와 동일하게 해야 한다고 결정했습니다. 또 주목할 만한 기능은 드래프트에 포함된 getters 와 setters 지원이었습니다.

DOM 프로토타입

최근 수개월간, JavaScript 프로토타입 개념을 DOM 에 도입 (영어) 하기 위해, DOM 과 JavaScript 의 호환성을 더 높이기 위한 기능을 연구했습니다. DOM 속성을 이용하여, 실력 있는 웹 개발자는 HTML 요소나 새로운 기능을 가진 DOM 개체를 쉽게 확장할 수 있습니다. 보다 고도의 라이브러리나 추상화 층을 개발하거나 또는 기본 제공 속성이나 메서드를 독자적으로 구현한 것과 바꾸는 것도 가능합니다. 이것은 유력한 JavaScript 전문가와 많은 사람들에게 가장 강력하게 요구되던 프로그래밍 기능의 하나입니다. 이 기능의 매우 중요한 부분 중 하나가 DOM 의 getter/setter 속성 (영어) 입니다.

버전 3.1 이전의 ECMAScropt 에는 getter/setter 속성 개념은 포함되어 있지 않았습니다. 그러나 일부 JavaScript 의 구현에서는 몇가지 IE 이외의 주요한 브라우저와 프로그래밍환경에서 지원된 (영어) API 를 사용하여 지원되었습니다. 우리가 DOM 프로토타입 지원을 위한 작업을 시작 했을 때에는 사실상의 표준 (de facto)이 되는 getter/setter API 를 구현하는 일이 었습니다.

ECMAScript 3.1에서는 초기 단계에서 getter/setter 속성을 포함하는 것이 결정되었지만, 사실상의 표준 대신보다 유연성 높은 API 를 사용합니다 (영어)(Word 형식). 이 결정은 이미 사실상 표준 getter/setter API 를 지원하는 브라우저를 포함한, 모든 주요한 브라우저 공급업체가 동의했습니다. ECMAScript 3.1 책정은 전진했지만, 일부 브라우저 공급업체에는 변화가 생겨, 우리는 중대한 선택을 해야만 했습니다. 예상하지 못한 변환에 대해, ECMAScript 3.1 의 DOM 에의 getter/setter API 구현을 추구해야 할지,  아니면 현재 완성된 기능으로 출시하고, ECMAScript 3.1 API 는 이후 버전에 포함해야 할지 고민했습니다.

그 대답은 웹 개발자에서 무엇이 최선인지를 생각했습니다. 개발자는 상호 운용성 (영어)을 필요로 하고, ECMAScript 3.1 에서 보여준 것처럼, getters/setters 를 지원하여 장기적인 상호 운용성이 제공됩니다. Beta 2 공개는 불과 몇 주 전에 결정되었고, 릴리스 품질을 저하시킬 수는 없었습니다. 게다가 Beta 2에서는 기능을 삭제하는 것 (RC1 까지 그대로 둠)보다는 현재의 구현 (사실상의 표준 getter/setter) 대로 출시하고 웹 개발자에게 유효성 검사 받아서 버그를 잡는 것이 중요하다고 판단했습니다. 피드백을 주신 것에 감사드리며, 이렇게 하여 호환성에 대응할 수 있는 충분한 시간을 가질 수 있었습니다.  

표준이 우선

Internet Explorer 8 릴리스 후보에서는 단지 고품질의 DOM 속성 구현하는 것 뿐만 아니라, getter/setter 구현을 ECMAScript 3.1 드래프트 표준에 따라서 구현하도록 변경할 수 있던 것을 기쁘게 생각합니다. 출시를 앞두고, JavaScript 엔진이나 DOM 은 ECMAScript 3.1 의 확장된 모든 기능을 지원하지는 않지만, 웹 개발자가 Internet Explorer 8 의 DOM 대상으로 getters 와 setters 를 추가하여 기술한 코드는 앞으로도 계속 기능합니다. 왜냐하면 그러한 코드는 웹 표준에 근거하기 때문입니다.

IE8 의 새로운 기능들에 기대가 큽니다. 시작하는데 도움을 드리기 위해 DOM 프로토타입과 getter/setter를 소개하는 글을 썼습니다. (새로운 구문은 곧 출시될  릴리스 후보 버전에서 일반적으로 이용 가능합니다)

• Document Object Model Prototypes, Part 1: Introduction (영어)
• Document Object Model Prototypes, Part 2: Accessor (getter/setter) Support (영어)

아마 알고 계실지도 모르지만, MSDN 도 Internet Explorer 8 에서 프로토타입 이용 가능(영어)이 반영되었습니다.

DOM 속성과 getters/setters 에 의해, 매우 세련된 프로그래밍 가능성이 커집니다. 앞으로 블로그에서 IE8에서는 어떠한 시나리오가 가능하게 되는지 세부 사항을 설명할 예정입니다. 기능을 사용하여 이미 세련된 시나리오를 구현하고 있다면, 꼭 댓글을 남겨 주세요.

변화에 대한 대응이라는 주제로 돌아와서, 먼저 웹을 위한 가장 좋은 사양이라고 생각했던 것이 제품 개발 도중에 변경될 수도 있습니다. Internet Explorer 8 의 DOM 의 getters/setters에 대한 제 경험이 그것을 개인적으로 증명하고 있습니다. IE8 를 완성한 후에도 우리는 적확한 정보를 수집하고, 고객의 피드백에 귀를 기울여 제품을 적절하고 유용하게 변경할 예정입니다. 우리 팀은 웹 표준과 상호 운용성을 달성하기 위해서 웹 표준 지원에 많은 노력을 하고 있으며,  최종적으로는 웹 개발자의 생산성 향상에 기여할 것입니다. ECMAScript 3.1 채용은 그것을 위한 커다란 전진입니다.

-Travis Leithead
프로그램 관리자

* 1/15 업데이트: 위에서 소개한 링크에서 참조할 수 있는 몇가지 예에는 속성 기술자가 “getter”속성과 “setter”속성이 된 경우가 있기 때문에 주의해 주십시오. 이러한 기술자는 최근에서야 “get”과 “set”으로 단순화 되었습니다. (이것은 ES3.1 언어 이외 부분과의 일관성 때문) 이 변경은 현재의 프로그램 이전에는 반영되었지만, 문서 업데이트는 작업 중입니다.

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

업데이트 일: 2009 년 1 월 13 일

영어 원본 : Responding to Change: Updated Getter/Setter Syntax in IE8 RC 1 (영어)

Internet Explorer 의 프로그램 관리자인 Tony Ross 입니다.  IE 팀은 IE8 를 가능한 가장 사용하기 쉬운 웹 브라우저가 될 수 있도록 개발하고 있습니다. 또 상호 운용성을 향상하여, 웹 개발자가 편리하게 이용할 수 있도록 주력하고 있습니다. 동적인 웹 컨텐츠에의 사용자 보조를 구현하는 구문인 ARIA 지원 강화를 위해서 RC (릴리스 후보)에서 변화된 것을 소개합니다. 이전의 IE에서 구현되었던 것과 현재 구현 가능한 것, 그리고 이런 변화가 전체적으로 어떤 의미가 있는지 소개합니다.

이전 IE에서 구현되었던 것

ARIA 지원은 Beta 1에서 추가되었지만, 브라우저 모드에 의존하는 구문의 상위가 존재했었습니다. IE8 표준모드에서는 표준 정의된 구문을 사용하여 스크립트에서 ARIA 특성에 액세스 할 수 있었습니다:

value = elm.getAttribute("aria-checked");

IE7 모드와 Quirks 모드 등의 상호교환모드에서는 특성 이름을 camelCased에서 지정해야 했습니다. 

value = elm.getAttribute("ariaChecked");

구문의 차이는 미묘하게 보일지 모르지만, 이 차이는 IE 특성과 속성 취급 방법의 결과입니다. 속성은 스크립트의 개체로서 존재하며, elm.property 에 속합니다. 개발자의 편의를 위해 IE 는 특성을 속성에 자동적으로 대응시킵니다. 네이티브 특성의 이름에 대시가 포함되어 있으면, IE 는 허용 가능한 속성 구문을 구성하도록 조정합니다:

value = elm.ariaChecked;

이 조정이 없는 경우, 각각의 대시는 스크립트 인터프리터에 의해 마이너스 기호로서 다루어집니다.

value = elm.aria-checked; //대시를 포함한 속성에 액세스 하고 싶다

value = elm.aria – checked; //스크립트의 인터프리터에는 대시가 이와 같이 보인다

이전 버전의 IE 와 상호교환 모드의 IE 8 은 속성과 특성의 양쪽 모두에서 같은 이름을 사용합니다. 그 결과, 속성 이름의 조정은 getAttribute 구문에도 같이 영향을 줍니다. 이 조정은 ARIA 에 포함된 것 뿐만이 아니고, 모든 대시를 포함한 이름의 네이티브 특성에 적용됩니다. IE 는 인식할 수 없는 특성은 바꾸지 않고, 이름을 “foo-bar”와 같이 그대로 남깁니다. IE8 표준모드는 속성과 특성에서 각각 이름을 유지하기 때문에 전체적으로 이러한 충돌을 피할 수가 있습니다.

현재 구현 가능한 것

처음에는 위와 같은 문제에 대처하기 위한 IE7 모드나 Quirks 모드에서의 표준 ARIA 구문 지원은 실시하지 않았습니다. 이러한 모드에서는 이전 버전과의 호환성이 가장 중요하기 때문에 그 동작의 변경에는 신중했습니다.

그 이후, ARIA 를 위한 다른 구문을 갖는 것에 대해 우려하는 피드백을 받았습니다. 이 피드백은 웹 개발자, 사용자 보조 기술의 공급업체, 표준에 대해 커뮤니티 멤버들로 부터 전해졌습니다. 그들의 우려는 주로 IE8 표준모드에 대응하지 않는 페이지에 대한 것으로 이러한 페이지에서 ARIA 를 지원하려면, 지원 대상의 구문 중 하나를 선택하거나 또는 양쪽 구문을 지원하기 위해서 노력해야 한다는 것이었습니다.

이러한 피드백에 근거하여, IE 의 ARIA 핸들링을 다시 한번 증명했습니다. 오래된 버전의 IE에서는 ARIA 를 지원하지 않습니다. ARIA 특성은 미지의 것으로 취급되어, 그 이름을 camelCase 표기에 변경하지 않습니다. 이것은 이 버전에서는 스크립트가 표준화 된 구문을 사용하여  ARIA 를 조작할 수 있는 것을 의미합니다. 다만 Microsoft Active Accessibility (MSAA)(영어) 와 같은 API 를 경유하여 정보가 공개되지 않습니다.

피드백을  검토하는 과정에서 이러한 정보를 추가한 결과, IE8 의 동작을 최선의 선택사항으로 변경하기로 결정했습니다. 어떤 모드에서도 IE8 는 ARIA 특성 이름에 포함된  대시를 유지합니다. 이 변경의 일부로서 앞에서 말한 것과 같은 충돌을 피하기 위해, camelCase 표기의 ARIA 속성을 열거했습니다. IE8 의 ARIA 지원을 위해서는 표준화 된 구문만 잘 사용하면브라우저 모드에는 관계없게 되었습니다.

value = elm.getAttribute("aria-checked");

변경의 의미

웹 개발자 대상

변경에 의해, ARIA  이용이 쉬워집니다. 복수의 ARIA 구문 지원이 필요 없습니다 .

• 단일 구문은 IE8 의 모든 모드를 통해서 기능합니다
• 단일 구문은 다른 브라우저와의 상호 운용성이 있습니다
• 단일 구문은 표준과 일치합니다

최종 사용자 대상

이 변경에 의해, IE8 의 모든 모드에서 ARIA 규격이 지원되어, 더 많은 사이트가 IE8 에서 액세스하기 쉬워질 것입니다.

ARIA

변경에 의해, 개발자가 다른 구문에 주위를 기울일 필요가 없고, 표준화된 ARIA 구문 보급에 도움이 될 것입니다. .

결론

IE 8에서는 Beta 1에서 복수 구문에 의해 ARIA 를 지원했지만, 표준과의 일치를 위해 하나로 줄였습니다. 이러한 변경으로 개발자, 최종 사용자, 그리고 ARIA 자신에게 종합적으로 좋은 영향을 줄 것이라고 믿습니다. 이러한 결정에 대해 항상 중요한 역할을 해주시는 커뮤니티의 피드백에 감사드립니다. 

Tony Ross
프로그램 관리자

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

업데이트 일: 2009 년 1 월 16 일

영어 원본 : Accessibility: Improved ARIA Support in the IE8 RC (영어)

Internet Explorer 8을  계획했었을 때, 보안팀은 현실에 일어나는 일반적인 공격과 공격자가 무엇을 다음 주의대상으로 하는지 경향을 분석했습니다. IE8 개발 과정에서 새로운 종류의 위협이 있는 곳을 알기 위해서, 보안연구 커뮤니티와 긴밀히 협력했습니다. 가장 흥미로운 웹 응용 프로그램의 취약성 중 하나는 보안연구가 Jeremiah Grossman 이 웹 취약성의 "잠자는 거인 (영어)"이라고 부른 Cross Site Request Forgery (영어)(RSRF)입니다. Jeremiah 가 보여준 것처럼, 일반적인 해결 방법이 존재하지 않기 때문에 CSRF 공격을 막는 것은 어렵습니다. 브라우저 보안모델의 구조적인 기반은 여러 웹 사이트가 동시에 상호작용 가능하여, 무관한 웹 사이트 사이를 끊김 없이 이동할 수 있도록 설계되었습니다. 그러나 이것들은 확실히 CSRF 공격이 이용하려는 기능 그 자체입니다. 최종 사용자 PC에서 개인적인 정보나 그 외의 높은 가치의 정보 저장 장소가 인기 있는 웹 응용 프로그램의 변화에 따라, CRSF 공격 (영어)  또는 그 외의 웹 응용 프로그램의 취약성으로 이어질 수 있습니다.

Internet Explorer 8 을 설계할 때 , CSRF 공격에 대한 브라우저의 공격 대상영역을 증대되지 않도록 세심한 주위를 기울였습니다. 일례로서 IE8 의 새로운 XdomainRequest 개체 (영어) 는 서버의 명시적인 허가 아래에서 크로스 도메인의 통신을 허가하지만, 새로운 유형의 CSRF 가 가능하지 않는 특정 제한을 포함합니다. 최종 사용자가 이용하지 않을 때는 민감한 정보를 취급하는 웹 사이트에서 로그오프 하거나 독립된 InPrivate Browsing 세션을 사용하여  CSRF 공격의 위협을 줄일 수 있습니다. (InPrivate 세션의 Cookie 저장 영역은 비어 있는 상태에서 시작되어,  저장된 Cookie 가 CSRF 공격으로 재사용되지 않습니다)

그렇지만 궁극적으로는 웹 응용 프로그램은 CSRF 취약성을 방지하도록 구축되어야 합니다. 최선으로 설계된 웹 응용 프로그램에서는 피해자인 사용자가 의도적으로 송신한 것인지 부정한 리퀘스트를 식별할 수 있는 챌린지 토큰 (영어) 이나 거기에 유사한 방법을 사용하여, 자신을 보호합니다. 하지만, 챌린지 토큰이나 거기에 유사한 방법은 취약성에 빠지기 쉽습니다.  가장 큰 취약성은 크로스 사이트 스크립팅(XSS)(영어)입니다. 토큰으로 보호된 웹 응용 프로그램에 크로스 사이트 스크립팅의 취약성이 있으면, 보안 토큰이 탈취되어 CSRF 공격이 가능해집니다. 다행히, Internet Explorer 8 에는 XSS 필터나 그 외의 기능 (영어) 이 있어, CSRF 를 막기 위한 챌린지 토큰의 탈취에 사용될 XSS 공격 방지에 도움이 됩니다.

작년 가을, 연구원인 Robert Hansen 과 Jeremiah Grossman 은 ClickJacking (영어) 으로 알려진, CSRF를 가능하게 하는 제 2의 요소를 공개했습니다. ClickJacking 은 사용자가 눈치채지 못하도록 애매하게 숨겨진 웹 요소를 클릭하도록 속이는데 사용되는 다중 테크닉(multiple technique) (영어)을 포함한 용어로 의도하지 않는 매매거래가 발생할 수 있습니다. 악성의 ClickJacking 공격은 사용자에 거래 확인을 요구하고 CSRF 를 막으려는 구조를 회피합니다. 예를 들면, Cookie 를 인증에 사용하고, 한번의 클릭으로  구입을 할 수 있는 단순한 웹 쇼핑몰 (영어)에 대해 생각해 봅시다.

악의가 있는 사이트 (영어)를  웹의 어딘가에서 생성하여 , 정상적인 쇼핑몰에서 표적이 되는 페이지를 IFRAME 에 의해서 꺼냅니다. 그리고 프레임내의 중요한 요소를 혼동하기 쉬운 텍스트나 이미지로 가립니다.

사용자가 속아서, 웹 쇼핑몰 페이지라고 생각하지 못하고 클릭할지도 모릅니다. 이 때 사용자가 쇼핑몰에 로그인 한 상태였을 경우, 의도하지 않는 주문이 발생합니다.

분명히, 이것은 매우 단순한 ClickJacking 공격으로, 보다 세련된 종류의 공격도 존재합니다.

ClickJacking에 대해서는 다양한 완화책 (영어) 이 만들어졌지만, 어떤 완화책에도 호환성이나 사용자 경험에 영향 혹은 기존 표준에 대한 변화의 필요성 등 절충되는 조건이 있습니다. 현시점에서, 가장 단순하고 가장 넓게 이용되는 ClickJacking 공격을 깨기 위한 메커니즘은 frame-busting 으로 공격받기 쉬운 페이지가 프레임내에서 표시되지 않도록 하는 단순한 동작을 의미 합니다. 그러나 전형적인 frame-busting (영어) 의 메커니즘은 스크립트에 의존, 그 결과 다양한 방법으로 회피됩니다.

12 월 초순에 다른 브라우저 공급업체에 개시한 것처럼, Internet Explorer 8 출시 후보에는 공격받기 쉬운 페이지를 프레임내에 표시되지 않도록 선언하여 웹 응용 프로그램이 ClickJacking 위험성을 줄일 수 있는 새로운 옵트인 메커니즘을 도입했습니다.

웹 개발자는 페이지가 프레임내에 표시되지 않도록  제한하기 위해서, X-FRAME-OPTIONS 라는 이름의 HTTP 응답 헤더를 HTML 페이지와 함께 송신할 수 있습니다. X-FRAME-OPTIONS 값에 DENY 토큰이 포함되어 있으면, 그 페이지가 프레임내에 포함된 경우에 IE8 는 페이지의 표시를 실시하지 않습니다. 값에 SAMEORIGIN 토큰이 포함되어 있으면, X-FRAME-OPTIONS 머리글을 포함한 페이지의 원래 서버와 프레임의 톱 레벨 문맥의 원래 서버가 다른 경우에  IE 는 페이지 표시를 하지 않습니다. 예를 들어, https://shop.example.com/confirm.asp 가 DENY 지시 자식을 포함하고 있으면, 부모 프레임 장소가 어디에 있는지 그 페이지 서브 프레임에는 표시되지 않습니다. 그것과는 대조적으로, X-FRAME-OPTIONS 머리글에 SAMEORIGIN 토큰이 포함된 페이지는 바르게 https://shop.example.com 를 원래 서버로 하는 페이지의 프레임내에 표시할 수 있습니다.

X-FRAME-OPTIONS 의 정책에 의해 표시가 차단되었을 경우, 제한된 설명과 프레임을 새로운 윈도우에서 열기 위한 링크가 표시된 로컬의 오류 페이지가 나타납니다. 서브 프레임 대신 새로운 윈도우에서 표시되면, 컨텐츠는 ClickJacking의 영향을 받지 않습니다.

중요한 정보를 취급하는 anti-CSRF 페이지를 보호하기 위해서 X-FRAME-OPTIONS 지시 자식을 사용하여 웹 개발자는 IE 8 사용자의 웹 응용 프로그램을 통한 공격을 즉시 줄일 수 있습니다. ClickJacking 위협에 대한 호환성이 높고 배포 하기 쉬운 방법으로  X-FRAME-OPTIONS 지시 자식이 다른 브라우저에도 구현되기를 기대합니다. 장기적으로 보면 보안연구가나 웹 표준화 조직은 브라우저에서 구현되는 웹 응용 프로그램의 보안정책의 설계가 진화를 계속한다고 예상합니다. 그들과 함께, 장래의 ClickJacking방어를 차기 버전의 브라우저는 보다 큰 보안정책 기능의 문맥 내에 형태 만드는 작업에 참여할 수 있기를 기대하고 있습니다.

감사합니다.
Eric Lawrence
프로그램 관리자

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

업데이트 일: 2009 년 1 월 27 일

영문 원본 : IE8 Security Part VII: ClickJacking Defenses

IE 팀에서 브라우저 성능을 담당하고 있는 프로그램 관리자 Christian Stockwell 입니다.

웹 사이트와 웹 브라우저의 전체적인 성능을 측정하는 일은 사용자가 경쟁 관계에 있는 브라우저를 비교하기 위해서,  개발자가 다운로드 시간이나 응답을 최적화하기 위해서, 브라우저 공급업체가 코드 변경과 성능 변화의 관련성을 조사하기 위해, 그리고 웹 사이트 성능에 대해 관심 있는 모든 사람들에게도 중요한 일입니다.

이 글은 브라우저 성능 테스트에 영향을 주는 문제나 브라우저 성능을 효율적으로 측정하기 위한 기술에 대해 기술할 예정입니다. 

브라우저 성능 측정

일반적인 성능 테스트의 접근 방식은 특정 벤치마킹 제품군 (패키지)에 집중합니다. 이것은 유효한 측정 방법이지만 소수를 타겟으로 하는 벤치마크만을  의존하기 때문에 사용자가 느끼는 성능을 잘못 이해할 가능성이 있습니다. 브라우저 성능을 측정하는 가장 정확한 방법에는 실제로 잘 행해지고 있는 브라우징 시나리오측정이 포함되어야 합니다. 실제 사이트에서 측정하면, 다른 벤치마크에서는 추출할 수 없는 요소를 포착할 수 있어 종합적인 측면에서의 성능을 알 수 있습니다. 실제 사이트에 대해서 브라우저 테스트를 실시하는 것은 몇가지 중요한 도전이 필요하지만, 이 글은 우리가 개발 과정에서 IE 성능을 효율적으로 측정하기 위해 사용한 해결 방법을 보여줍니다.

먼저, 성능 벤치마크를 유효하게 실시한다는 것은 생각보다 많은 어려움이 있다는 것을 미리 말해 두고 싶습니다. IE 팀은 매일 수천개의 독립적 테스트를 여러 서버에서 실시하기 위해, 수백 대의 데스크톱과 랩톱에서 유효성 검사와 성능 측정을 위한 실험 환경을 구축하기 위한 작업에 많은 노력을 했습니다. 그리고 성능 데이터 안정성, 정밀도 명확성을 개선하기 위한 새로운 아이디어를 매일 만들었습니다. .

브라우저 성능 측정의 도전 중 하나는 브라우저가 사용되는 방법이 방대하다는 것입니다. 사용자는 매일 다양한 사이트를 브라우즈징하며,  그 중에는 Flicker 와 같은 컨텐츠량이 많은 사이트에서 Google과 같이 최소화된 사이트도 포함되어 있습니다. Windows Live Hotmail 과 같은 상호작용 목표 AJAX 사이트도 방문하고, Craigslist와 같이 단순하고 정적인 HTML 사이트도 방문합니다. 또한 미션 크리티컬한 응용 프로그램에서 업무용으로 사용하는 사람도 있습니다.

이러한 각각의 카테고리 사이트  성능은 많은 경우 브라우저내의 다른 하부구조에 의존합니다. 예를 들어 이미지가 많은 사이트에서는 브라우저의 다운로드와 이미지의 배포 속도에 의존합니다. 대조적으로, 단순한 사이트의 성능은 HTML 렌더링 속도가 주요한 요소가 됩니다. 다른 예로서 AJAX 웹 사이트의 성능은 JavaScript 엔진과 CSS 엔진, DOM가  얼마나 긴밀히 통합되었는지,  각각의 하부구조가 속도 이상으로 중요한 요소입니다. Flash 나 Silverlight 와 같은 타사의 컨트롤이 포함되어 있으면, 많은 경우 성능은 컨트롤이 얼마나 효율적으로 브라우저와 통합되었는지 관련합니다.

여기서 소개하는 접근 방식은  IE8에서 행해진 성능 개선 배경과 관련되었으며, 또 우리의 개발 공정에 대해 알려드릴 것입니다. 이것들을 통해서, 이 글에서 브라우저와 사이트의 성능을 측정하여 검토하는 방법을 향상시키기 위한 아이디어를 찾기 바랍니다.  

캐싱 동작(Caching Behavior)

모든 브라우저는 기본적으로 네트워크에 의존하며, 어떠한 테스트에서도 성능 측정을 충분히 실시하려면 그 현실이 반영되어야 합니다.

브라우징 성능에 영향을 줄 수 있는 인터넷 성질 중 하나는 인터넷을 구성하는 다양한 수준의 서버 컨텐츠 저장 방법입니다. 이러한 저장 동작은 캐싱이라 불립니다.

브라우징 성능 측정에서는 www.microsoft.com 을 표시할 때  브라우저는 이 컨텐츠를 회사내의 프록시 서버나 로컬 서버, 전세계의 수많은 서버 등  여러 서버에 요청합니다 .

브라우징 스피드를 향상하고, 웹 페이지를 제공하는 작업을 분산화하기 위해, 표시한 페이지의 일부를 일시적으로 저장하여, 다른 사용자가 그 일부를 보다 빨리 취득할 수 있도록 합니다. 예를 들어 여러분이 아침에  제일 먼저 뉴스를 보기위해,  www.msnbc.com (영어)를 방문하는 경우, 먼저 회사의 프록시 서버에 요청합니다. 프록시 서버는 최종적으로 원격지 서버에서 페이지를 취득전에 로컬 서버에 그 요청을 중계합니다. 페이지 취득이 완료하면, 프록시 서버 또는 로컬 서버는 컨텐츠의 일부를 저장합니다. 이 때 동료인 Tracy 가 10 분 늦게 출근하여 www.msnbc.com (영어) 에 액세스하면, 원격지 서버 대신 프록시 서버에서 직접 컨텐츠를 취득하여, 사이트를 표시하는데 필요한 시간이 현저히 단축되어 Tracy 는 매우 행복해집니다.

마찬가지로 여러 브라우저에서 성능을 측정하는 경우, 캐싱 영향을 고려하는 것이 중요합니다. 예를 들어 첫번째 브라우저의 10 개 탭에서 10개의 다른 웹 사이트를 연 뒤, 두번째  브라우저에서도 같은 10 개의 탭을 열면, 두번째 브라우저가 빠르다는 다른 결과를 얻을 수 있습니다. 실제로는 이러한  차이는 주로,  브라우저가 처음에  페이지를 요청했을 때에 컨텐츠가 가까운 서버에 저장되어 있는지에 따라 달라집니다..

서버가 어떻게 캐시 하는지를 엄격히 제어하는 것은 어렵지만, 성능 측정의 일반적인 원칙은 어떠한 경우도 한번의 측정으로 끝내서는 안됩니다. 상위에서의 캐싱 영향을 따로 측정하려는 것이 아니면, 성능 데이터의 수집을 시작하기 전에 측정하고자 하는 사이트를 한 번은 방문해야 합니다. 실제로는 프록시는 사용자 에이전트 (브라우저) 마다 컨텐츠를 캐시하므로, 테스트를 원하는 사이트의 각각을 테스트 하는 모든 브라우저로 방문해야 합니다.

여기까지의 캐시 동작 소개는 단순화 한 것입니다. 보다 자세한 정보가 필요하면, 동작이 세부 사항에 해설된 중요한 리소스가 다수 있어, HTTP 프로토콜 규격 자체도 그 하나입니다. HTTP 프로토콜 규격 (영어) 가 매우 좋은 자료입니다.

샘플 양

정확하게 말하면, 브라우징 성능에 영향을 주는 요소는 매우 다방면에 걸쳐있기 때문에 성능 측정 횟수에 따라 그 결과에 큰 차이가 있는 경우가 있습니다.

앞에서 얘기한 것과 같이, 성능 측정의 일반적 원칙은 어떠한 경우도 한 번의 측정으로 끝내서는 안됩니다. 이 원칙을 「어떤 경우에도 충분한 회수 측정을 해야 한다」라고 확장하고 싶습니다. 「충분한 회수」가 무엇을 의미하는지에 대해는 신뢰구간이나 표준편차, 그 외의 통계학상의 흥미로운 응용에 근거한 여러 가지 의견이 있습니다.

우리가 수집한 다수의 성능 데이터에 관해서는 대부분의 경우, 실용적인 접근 방식을 채용하여 비교적 복잡한 과제를 피할 수 있었습니다. 유효성 검사 환경에서는 7~ 10 회의 반복으로 안정성있는 데이터 집합을 수집합니다. 다만 유효성 검사하는 환경 제어가 보다 불충분한 경우는 보다 많은 회수가 필요합니다.

성능 데이터를 수집되면, 결론을 이끌기 위해 결과를 요약해야 합니다 . 산술평균 (영어), 조화평균 (영어), 기하평균 (영어), 또는 그 외의 어떠한 방법을 사용하는 경우여도 데이터 요약 방법에 따라 결과가 달라 질 수 있다는 것을 충분히 이해하고 있어야 합니다.

예로서 두 개의 브라우저에서 단일 웹페이지를 표시하는 테스트에서 수집된 점수 데이터입니다.

	Browser A	Browser B
Sample 1	1.0	2.0
Sample 2	1.0	2.0
Sample 3	1.0	2.0
Sample 4	1.0	2.0
Sample 5	10.0	4.0
Arithmetic Mean	2.8	2.4
Geometric Mean	1.6	2.3
Harmonic Mean	1.2	2.2

억지로 맞춘 듯한 이 예에서 명확한 점은 데이터를 어떻게 요약하는지에 따라서 데이터 해석이 바뀐다는 것입니다. 이 예에서는 산술평균은 브라우저 B 가 브라우저 A 보다 빠르다고 보여주는 것에 반해, 기하평균과 조화평균에서는 그 반대의 결과가 나왔습니다.

대역폭 경쟁(Bandwidth Competition)

네트워크를 다른 사용자와 공용하는 것은 분명히 웹 브라우저가 같은 동작을 하는데 보다 많은 시간을 필요로 합니다.

Microsoft 와 같은 대기업에서 일을 하는 경우의 이점 중 하나는 직원이 다수이기 때문에 특정 현상을 측정가능하고 신뢰할 수 있습니다. 예를 들어 페이지 다운로드에 필요로 하는 시간을 하루 동안의 통계를 살펴보면 많은 Microsoft 직원은 오전 8 시에서 오전 9 시의 사이에 일을 시작하여 오후 5 시에서 오후 6 시의 사이에 퇴근하는 것이 확실합니다.

그 이유로서 명확하게 말할 수 있는 것은 많은 Microsoft 직원은 하루 종일 거의 끊임없이 네트워크에 액세스합니다. MSDN 를 참조하거나 SharePoint 문서를 읽거나 최신 Xbox 게임 테스트를 실시하는 등의 대역폭을 함께 사용합니다. 그러한 공유는 브라우저 성능을 측정하려면 회사 전체가 업무를 시작하여 전자 메일을 송신하기 시작하는 오전 9 시 대신, 오전 6 시에 가는 것이 일관된 결과를 확실히 얻을 수 있는 것을 의미합니다.

기업에 따라서 가능한 네트워크 구성 종류도 폭넓기 때문에 대역폭 경쟁 영향을 예상하는 일은 어렵습니다. 결과를 왜곡하지 않도록 권장하는 방법은 직장에서 성능 데이터를 수집하는 경우에는 주요 업무 시간 이외로 성능 데이터 수집을 하는 것입니다.

자택에서 성능 데이터의 수집을 실시하는 경우도 가족이나 주변 사람과 대역폭을 공유하는 것이 됩니다. 그러한 경우, 영업시간이나 또는 이른 아침 등 다른 사람이 브라우징을 많이 하지 않는 시간대에 맞춰 측정하면 좋을 것입니다.

리소스 경쟁

컴퓨터  리소스에 대한 응용 프로그램 사이의 경쟁도 대역폭의 경쟁과 같이 브라우징 성능에 크게 영향을 줍니다.

여러 응용 프로그램이 동일한 외부 응용 프로그램이나 플랫폼에 의존하는 경우, 이것은 특히 틀림없는 사실입니다. 예를 들어, 안티 바이러스 제품에는  여러 브라우저와 다른 방법으로 통합가능 하지만, 그 성능에 주는 결과는 불명확합니다.

두개의 브라우저를 병렬하여 테스트 하면, 정확하지 않은 결과가 되는 경우가 있습니다. 예를 들어, Windows 플랫폼에서는 아웃 바운드의 소켓 요청은 동시에 10개 까지 제한됩니다. 게다가 요청은 접속 요청이 성공 또는 실패할 때까지 차례를 대기합니다. 두 개의 브라우저를 병렬하여 테스트하면 이러한 제한에 쉽게 이릅니다. 그 결과, 어느 쪽이든 한쪽의 브라우저가 수 밀리초  빨리 실행을 시작하여 우위가 되는 결과가 나옵니다. 

여기에서는 두개의 단순한 예를 들었지만, 그 이외에도 문제는 확실히 존재합니다. 이것에 대해 보다 세부 사항에는 논하지 않지만, 브라우징 성능을 측정할 때의 복수 응용 프로그램의 실행에 대해서 명료한 조언이 있습니다. 

최악의 경우에도 다른 응용 프로그램에서의 영향을  줄이기 위해 다음 두 단계를 거쳐야 합니다. 

• 작업 표시의 우측 통지 영역에만 표시되는 것을 포함하여, 열려 있는 모든 응용 프로그램을 종료한다.
  이것은 다른 응용 프로그램이 네트워크를 사용하지 않기 위해 특히 중요합니다.
• 커멘드 프롬프트에서 다음의 코맨드를 실행하면, 테스트시의  시스템동작을 줄일 수 있습니다.

서버 상호작용(Server Interaction)

컴퓨터나 네트워크  리소스 공유에 의한 간섭을 넘어도 성능 결과는 액세스 대상의 서버 내부적인 동작으로 영향을 받습니다.

성능 측정의 포괄적인 원칙의 하나는 테스트를 통해서 일정한 상태를 유지하는 일입니다. 캐시 관리에서는 성능 데이터 수집 전에 상위의 서버를 기존 상태에 해야 하는 일로 또 네트워크에서는 외부적인 요소의 영향을 줄이기 위해 일정한 환경에서 테스트를 하도록 노력합니다. 

벤치마크에 영향을 주는 응용 프로그램 설계 특성의 예로서 온라인 뱅킹 응용 프로그램을 채택합시다. 보안상의 이유로, 뱅킹 응용 프로그램은 적절한 자격 정보가 제시되었을 경우에만 계정 정보에의 액세스를 허가합니다.  두 개 (또는 그 이상)의 브라우저를 이 온라인 뱅킹 웹 사이트에서 벤치마크 테스트 한다면, 어떤 브라우저에 대해서도 응용 프로그램을 확실히 동일한 상태로 하는 것이 중요합니다. 설계상, 대부분의 온라인 뱅킹 응용 프로그램은 동시에 두 개의 세션에서 사용자가 로그인 할 수 없습니다. 한편으로 로그인 하면, 한편에서는 로그 아웃 됩니다. 두번째 브라우저 테스트를 시작하기 전에 웹 응용 프로그램 상태를 초기화 하는데 실패하면, 서버 기반의 응용 프로그램은 두번째 요청을 분석하여, 최초의 세션을 종료하고 새로운 세션을 시작하기 위해 여분의 시간이 필요합니다.

이와 같이 시작 처리와 종료 처리는 벤치마크에 영향을 줍니다. 이것은 온라인 뱅킹 응용 프로그램에 한정된 것은 아니기 때문에 이러한 요소를 없애도록 해야 합니다. 더 일반적으로 말하면, 성능 테스트에 사용하기 전에 대상이 되는 사이트의 동작을 이해해야 합니다.

관찰자 효과(Observer Effect)

많은 분야에서 측정하는 작업 자체가 측정 대상을 변화시키는 잠재적인 가능성이 있습니다. 이 현상은 관찰자 효과 (영어) 라 부릅니다.

특정 브라우징 시나리오 측정 작업을 편의상, 수많은 프레임워크의 한쪽을  사용할 수가 있습니다. 이러한 프레임워크는 전형적으로는 개발자나 기술자를 대상으로 합니다. 그러한 프레임워크의 일례로서는 Jiffy (영어) 가 있습니다.

어떠한 인프에서든 측정 결과에 직접 영향을 준다면, 주의 깊게 액세스 하여 측정에 사용하는 프레임워크에 의한 성능 변화를 부르는 잠재적 가능성을 최소화해야 합니다.

여담이지만, IE 팀에서는 내부적인 테스트에 ETW 트레이스 로그인 인프라 구조를 사용하고 있습니다. 이것은 ETW 가 확장성 높은 로그인 인프라 구조로, 결과를 왜곡하는 관찰자 효과의 가능성을 최소화할 수 있기 때문입니다.

컴퓨터 구성(Machine Configuration)

사람과 마찬가지로, 엄밀하게 동일한 두 개의 컴퓨터는 존재하지 않습니다.

앞에서 얘기와 같이, IE 성능 유효성 검사 환경에서는 매일 성능 테스트를 실행하는 대량의 컴퓨터를 보유하고 있습니다. 유효성 검사 환경의 유연성을 최대로 하기 위해, IE8 의 초기에 일관된 성능 데이터집합을 만들어 내기 위한 기획했습니다. 이러한 컴퓨터는 연번의 직렬화Serialization) 넘버가 붙어있고,  같은 조립 라인으로 생산되어 각각의 구성요소는 "완전히 동일" 이었습니다. 이러한 노력에도 불구하고, 컴퓨터에서 수집된 데이터는 다양하기 때문에 다른 컴퓨터에서의 성능 결과를 직접 비교 하는 일은 피했습니다. 

이것은 놀라운 일은 아니지만, 다른 플랫폼간에 브라우저 성능은 가지각색이 되므로, 모든 브라우저의 테스트를 단일의 컴퓨터에서 실행해야 한다는 것을 알아 주셨으면 합니다.

Cold Start vs. Warm Start

브라우저를 시작하는데 필요한 시간의 총합은 브라우저 관할 외의 여러가지  요소에 의존합니다. 

캐시 동작과 같이, 브라우저를 시작하는 스피드는 외부 요소의 영향을 받기 쉽습니다. 이것은 특히 첫번째 브라우저 실행에서 현저하게 나타납니다. 브라우저가 웹 사이트에 전환을 시작하기 이전에 우선 자기 자신의 파트를 메모리에 로드하기 위한 시간이 소요되는 동작이 필요합니다. 첫번째  브라우저의 실행에서는 얼마나 많은 부분이 이미 메모리에 읽히고 있는지를 정확하게 아는 일은 어렵습니다. 특히 IE에서는 많은 구성요소가 다른 프로그램과 공유되기 때문에 매우 어렵습니다.

일관성이 있는 데이터를 수집하기 위해서는 테스트의 시작 전에 대상이 되는 브라우저를 각각 한 번 실행한 후 종료합니다. 브라우저에 필요한 구성요소의 일부를 운영 체제가 메모리에 로드하는 동작을 하는 다른 응용 프로그램이 없으면, 결과의 정확함과 일관성은 향상합니다. Windows Superfetch (영어) 와 같은 평상시 잘 사용하는 브라우저에 유리하게 될지도 모르는 기능을 특히 고려하면, 브라우저 사이의 비교도 공정하게 할 수 있습니다. 

웹 사이트 컨텐츠

웹 사이트는 항상 변화합니다. 유감스럽게도 성능 테스트를 시도하는 동안도 그 예외가 아닙니다.

IE 팀의 성능 유효성 검사 환경에서는 모든 웹 사이트의 컨텐츠는 테스트 기간 중 캐시된 상태가 되어 있었습니다. 캐시 동작의 영향 중 하나는 테스트 매회 반복하여 브라우저에 정확하게 같은 컨텐츠가 제공됩니다.  실제로는 이것이 그렇게 빈번히 일어나는 일이 아닙니다.

일례이지만, 뉴스 사이트는 화제가 널리 알려지는 것에 따라 컨텐츠를 업데이트합니다.  Facebook 나 MySpace 를 두 번 방문하면, 친구가 새로운 사진을 추가하거나 상태를 업데이트 하면, 완전히 다른 경험이 얻을 수 있습니다. 광고는 많은 웹 사이트에서는 빈번히 변경되므로, 즐겨 찾기의 사이트를 두 번 표시하면, 틀림없이 차이가 납니다.

유효성 검사 환경이 아니면, 이러한 변경을 제어하는 일은 어렵습니다. 이것에 대한 접근 방식은 확실히 존재합니다. Fiddler 와 같은 도구를 사용하여 브라우저가 받는 컨텐츠를 조작하는 것이 가능합니다. 그렇지만 이러한 접근 방식은 성능 결과에 영향을 줄 가능성이 큽니다. 결과적으로, 현실적인 해결 방법은 샘플 양에 대해 지적했을 때의 조언과 같습니다. 페이지를 몇차례 표시할 때 마다 매우 무거운 광고가 표시되는 경우, 유효성 검사가 있는 일련의 결과를 얻기 위해서 측정을 상당 회수 반복해야 합니다 .

웹 사이트 설계

웹 사이트는 액세스 마다 변화할 뿐만 아니라, 다른 브라우저에는 각각 완전히 다른 버전의 웹 사이트가 제작자에 의해서 준비된 경우도 있습니다.

테스트 마다 웹 서버에서 확실히 같은 컨텐츠가 제공되도록 하는데  귀찮은 문제의 하나는 다른 브라우저에 대해서 분명하게 다른 코드를 반환하는 그러한 사이트입니다. 많은 경우, 그러한 차이는 사용자가 다른 웹 사이트를 방문했을 때의 경험을 정당하게 반영한다고 생각하여 브라우징 성능 측정에서는 차이를 무시해야 합니다.

그렇다고는 해도 웹 사이트가 제공하는 기능이 브라우저 간에 광범위하게 다르기 때문에, 브라우저 간의 비교가 의미를 만들어내지 않는 경우도 있습니다. 예를 들어, 최근 고객이 웹 사이트 이용에 IE8 를 사용하면 경쟁 관계의 다른 브라우저를 사용했을 경우보다 시간이 걸린다는 보고를 받아, 조사한 일이 있습니다. 조사의 결과, 그 웹 사이트는 IE 를 사용하면 IE 이외를 사용했을 경우에 비해 보다 리치한 기능을 제공하는 프레임워크를 사용한다는 것을 알았습니다. 다행히도 웹 사이트는 그러한 리치한 기능에 의존하지 않았기 때문에 프레임워크의 사용법을 조금 변경하여, 어느 브라우저에서도 같은 속도로 동작하도록 할 수 있었습니다.

이 예와 같이 웹 사이트가 프레임워크의 제공하는 확장기능을 사용하지 않고, 사이트를 업데이트 할 수 있는 경우도 있지만, 많은 경우 브라우저의 종류에 의존하여 완전히 다른 사용자 경험을 제공합니다. 이러한 웹 사이트의 평가는 대체로  경우에 따라 다르지만, 이러한 사이트는 브라우저 성능보다 사이트 개발자의 의도가 성능에 크게 반영되므로, 일반적으로는 직접적인 비교에는 해당하지 않는다고 생각합니다.

브라우저를 구별하는 사이트를 식별하는 것이 단순하지는 않습니다. 게다가 이 경우 웹 개발자는 조사 담당자를 제어할 수 있습니다. 웹 개발자는 프로파일러나 디버거, 그 외의 도구를 사용하여, 브라우저마다 웹 사이트가 완전히 다른 경험을 제공하기 위한 식별 방법을 자유롭게 결정할 수가 있습니다.

조사 담당자나 보다 기술에 경험이 많지 않은 사용자는 이용해 보고 분명하게 시각적으로나 동작이 다른 사이트에서 여러 개의 브라우저 성능 측정은 피해야 합니다. 그러한 사이트를 사용한 테스트에서는 브라우저 성능을 웹 사이트 설계의 영향에서 분리하는 일은 어렵습니다.

「페이지가 표시되었습니다」

「페이지가 표시되었습니다」라는 표시의 의미를 정확하게 정의할 수 있을까요. 복잡하고 인터랙티브 AJAX 사이트에서는 어떻습니까.

성능 측정에 대해 놀라울 정도 귀찮은 문제 증 하나는 페이지 전환으로, 「완료」란 무엇을 의미하는지를 정의하는 일입니다. 이 귀찮은 문제는 웹 사이트가 복잡하고 비동기적이며, 한층더 심각합니다. 브라우저가 페이지 전환을 완료된 것을 보여주는 표지로서 HTML "onload"(영어) 이벤트를 사용하는 웹 개발자도 있습니다.그러나 이 이벤트의 정의는 유감스럽게도 브라우저에 따라서 다른 해석이 됩니다.

IE 팀 내부에서는 여러가지 사이트에서의 페이지 로드를 측정하기 위해서 내부적인 이벤트 기록을 이용하고 있습니다. 이 기록은 IE 에 특화된 것으로, 브라우저 마다의 페이지 로드 성능을 측정하기 위한 크로스 브라우저의 간단한 해결책이 되지는 않습니다. 사이트 개발자가 각각의 시나리오의 「완료」를 정의하는데 도움이 되는 Jiffy (영어)  또는 Episodes (영어) 와 같은 프레임워크는 존재하지만, 일반 사용자에게 폭넓게 받아 들여지는 것이 아닙니다.

특정 코드 수준에 의한 식별 대신, 브라우저 진행률 표시기 (모래시계, 푸른 점, progress bar, 텍스트 박스나 그 외의 사용자 인터페이스 요소)를 페이지의 다운로드 완료 통지에 사용하는 사람도 있습니다. 그러나 이러한 요소는 어떠한 표준에도 잘 다뤄지지 않고, 브라우저 제조자는 이것을 언제 표시할지 (또 표시하지 않을지도) 독자적으로 결정할 수 있습니다.

이러한 현실에 직면한 다음 조사 담당자나 사용자에게 사용하도록  권장할 수 있는 것은 실제 웹 페이지의 동작에 대응하는 것을 확인할 수 있는 방법은 브라우저의 진행률 표시기를 사용하는 것입니다. 예를 들어 특정 웹 페이지가 얼마나 신속하게 로드 되는지 테스트한다면, 최초의 로드 시에 브라우저의 진행률 표시기를 사용해 봅니다. 만약 진행률 표시기가 완료되기 전에 웹 페이지가 로드되어, 읽기 조작 가능하게 된 것처럼 보인다면, 인디케이터는 무시하고 페이지의 보이는 방법을 측정을 위해서 사용합니다. 또는 다양한 브라우저 사이에 페이지 다운로드의 속도를 초기적으로 평가하는 것 뿐이면, 진행률 표시기로 충분할지도 모릅니다. 실제 페이지 로드와 브라우저 인디케이터의 표시가 얼마나 일치하는지를 평가하지 않으면 성능 측정 시에 인디케이터를 신뢰해야 할 것인지 판단할 수 없습니다.

브라우저 애드온

브라우저 테스트를 할 때에 애드온을 동작시키면, 브라우저 성능만을 테스트한다고 말할 수 없습니다.

4 월에 쓴 글에서 말한 것처럼, 애드온은 브라우저 성능에 매우 큰 영향을 줍니다. Microsoft 의 데이터 경로를 통해서 받은 데이터에서는 수십 개의 애드온이 설치된 브라우저는 드물지 않고, 아마 Mozilla corporation 에서 저와 같은 입장의 사람들도 그들의 브라우저에 대해 같이 말할 것입니다.

이러한 애드온은 모두 브라우저 안에서 독자적인 활동을 실행합니다. 이 영향에 대해 일화적으로 설명하면, 자주 사용하는 브라우저가 있는 사용자가 다른 브라우저에서도 평소 사용하는 브라우저보다 빠르다고 느끼는 것은 단지 새로운 브라우저는 깨끗한 상태이기 때문이라는 것을 알았습니다. 예를 들어, 많은 애드온이 설치된 Firefox 사용자가 IE 로 변경하면 성능이 크게 향상되었다고 느끼고, IE사용자가 Firefox 로 이행했을 경우도 같은 성능 향상을 느낍니다. 이 결과는 결코 모순된 것이 아니고, 브라우저 애드온 영향의 크기를 반영합니다.

결과적으로, 우리의 성능 유효성 검사 환경에서는 깨끗한 브라우저의 설치와 일반적으로 잘 사용되는 애드온을 설치한 브라우저를 모두 테스트 했습니다. IE8 로 애드온을 무효로 하려면, "도구" 메뉴를 클릭하여 "애드온 관리" 를 선택합니다. 애드온 관리 화면에서는 우선 "표시" 에서 "모든 애드온" 을 선택하고, 다음에 표시된 애드온을 한개씩 무효로 합니다. 또는 커멘드라인이 익숙하다면, 애드온을 무효로한 IE 를 "iexplore.exe -extoff" 커멘드로 실행 할 수 있습니다.

대부분의 브라우저 배급업체는 브라우저를 업그레이드해도 애드온이 계속 올바르게 기능하도록 보장하기 노력하고 있습니다. 그러나 어떠한 성능 향상이어도 단지 하나의 애드온 때문에 엉망이 되어버릴 수도 있기 때문에 위의 같은 절차를 밟는 일은 매우 중요합니다.

글이 조금 길어졌지만, 우리가 IE 의 성능을 측정할 때의 몇가지 기술을 여러분의 요구에 따라 이용해주시기를 바랍니다. 또 우리가 성능 테스트에 대해 어떠한 생각을 가지고 있는지 이해하고, 브라우징 성능 프로세스와 접근 방식을 보다 이해하게 되었으리라 생각합니다. 마지막으로 IE8 제공 과정에서 어떠한 노력을 하고 있는지 조금이라도 알아 주시면 감사하겠습니다.

Christian Stockwell
프로그램 관리자

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

업데이트 일: 2009 년 1 월 23 일

영문 원본 : Common Issues in Assessing Browser Performance

전체에서도 시스템의 일부에서도 안정적으로 동작하는 기술을 개발하는 것이 저희들의 목표이며, 신뢰할 수 있는 컴퓨팅의 중요한 부분입니다. 고객과 파트너는 언제, 어디서나 어떤 장치에서도 신뢰할 수 있는 기술과 서비스를 기대합니다. 우리는 기술과 서비스의 안정성을 향상시키는 일에 항상 집중하고 있습니다.

Internet Explorer 의 안정성이란, 브라우저가 언제나 신속히 실행하고, 신속하게 동작하여 인터넷에 확실히 접속할 수 있고, 크래쉬나 멈추지 않고 웹 사이트를 표시하는 것을 의미합니다. 대부분의 사용자는 자신의 브라우저가 크래쉬 되어도 그 후 신속하게 복귀하여, 정상적으로 웹을 표시하기를 바랍니다. 사용자는 문제의 원인이 불완전한 애드온에 있는지, 웹 사이트가 불완전한지 대해서는 관심이 없습니다. 안정성을 향상시키기 위해 Internet Explorer 8 을 성능, 복구, 디스플레이 등 모든 면에서 강력한 브라우저가 되도록 많은 노력을 거듭했습니다. 여기에서는 특히 다음과 같은 점에 대해 설명합니다.

Loosely­coupled Internet Explorer

부드러운 브라우징 성능을 얻기 위해서 브라우저의 각 구성요소를 분리하는 도움이 되는 아키텍처상의 기능입니다.

크래쉬 자동 복구 기능

이 기능은 크래쉬가 발생하면 가능한 신속하게 원래의 브라우징 상태를 복구할 수 있도록 설계되었습니다.

Windows 오류 보고

Internet Explorer 의 안정성을 개선하기 위한 정보를 이용자가 우리에게 제공할 수 있는 방법입니다.

Loosely­coupled Internet Explorer

가장 중요한 성과의 하나가 Loosely­coupled Internet Explorer (LCIE)로 불리는 기능으로, 이 아키텍처의 특징은 브라우저의 구성요소, 특히 프레임을 탭에서 분리하는 것이 쉽습니다. LCIE 는 나중에 이야기할 자동 복구 기능을 포함한 몇가지 기능의 기초가 됩니다.

만약 Beta 1 공개 때에 읽지 않았다면, 프레임 윈도우를 분리하는 방법을 언급한 글을 먼저 읽으시기를 권장합니다. 이 기능은 대체로 Google chrome 와 동등한 것으로, 탭을 각각 다른 프로세스로서 배포하여, 탭에서 크래쉬가 발생해도 브라우저 이외 부분이 포함되지 않도록 설계되었습니다. 그림에서 보이는 것과 같이 밝은 부분이 프레임 영역에서, 회색 부분이 탭 영역이 됩니다.

Beta 1에 탑재한 이 기능을 바탕으로, 한층 더 안정성과 성능을 향상시키기 위해, Internet Explorer Beta 2 용의 LCIE 의 개발을 계속하고 있습니다.

Beta 2에서는 다음과 같은 변화가 있습니다. 

프레임 프로세스 병합

실행 속도를 향상시키기 위해, 실행시의 프로세스를 줄였습니다. 브라우저를 실행 할 때마다 2 프로세스 (프레임을 위해 1 , 탭을 위해서 1)를 실행하는 것이 아니라, 먼저 Internet Explorer 를 실행할 때 1 개의 프레임의 프로세스만을 실행합니다. 이후 실행에서는 새로운 탭 프로세스를 실행하거나 기존의 탭 프로세스를 이용하여 새로운 탭을 엽니다.

여러 세션에서 웹 브라우징에 익숙한  사용자, 예를 들어  여러개의 웹 메일에 동시에 로그인 하는 경우 등은 "-nomerge" 커멘드를 실행하여 이 기능을 무효화할 수 있습니다.

탭 프로세스 증가

동작중의 Internet Explorer  세션은 많은 경우, 3 개 또는 그 이하의 탭을 열고 있는 경우가 많습니다. Internet Explorer 8 Beta 2에서는 3개의 탭 프로세스를 효율적으로 처리할 수 있습니다. 3 이라는 숫자 값은 컴퓨터의 처리 능력에 의존하며, 보다 강력한 컴퓨터의 경우, 어느 정도는 이 숫자 값이 증가하기도 합니다. 프로세스를 증가시키면, 문제가 발생한 프로세스를 유효하게 분리할 수 있습니다. 각각의 탭이 다른 프로세스로 구동된 경우, 각각의 탭에서 표시된 웹 사이트는 완전하게 분리됩니다.

가상 탭(Virtual tab)

"hot swap" 라 불리는 탭에 관한 내부처리 기능을 추가했습니다. 지금까지 보호 모드는 프로세스 별로 동작했습니다. 예를 들면, Internet Explorer 7 인 사이트를 신뢰하는 사이트에 추가합니다. 이 사이트에 신뢰하는 사이트에 없는 다른 사이트로 링크가 있는 경우, 이 링크를 클릭하면 새로운 윈도우가 열립니다.

프레임 윈도우에서 탭을 분리하는 LCIE 를 탑재한 Internet Explorer 8 beta 1에서 이 동작을 개선했습니다. 이 분리 기능에 의해서, 지금까지와 같이 다른 윈도우를 열지 않고, 같은 윈도우안에 새로운 탭을 열 수 있습니다.

가상 탭에 의해서, 탭 별로 적절한 유효성 검사 수준의 프로세스로 변경가능하기 때문에 보호 모드와 그렇지 않은 모드를 같은 탭에서 안내할 수 있습니다. 이것은 단순한 "조작성 향상" 이며, 가상 탭은 보호 모드의 유효 / 무효를 전환 할 때의 조작을 편리하게 하는 것 이외에 보안이나 보호 모드의 동작 자체에는 전혀 영향이 없습니다.

여러 개의 프로세스와 가상 탭에 의해서 브라우저의 각 부분을 분리하는 LCIE 의 능력은 Internet Explorer 의 성능과 안정성을 향상시킵니다.

자동 복구 기능(Automatic Crash Recovery)

크래쉬 발생시, 자동 복구 기능은 가능한 한 신속하게, 원래의 브라우징 상태를 복구하도록 설계되었습니다. 문제를 특정 탭에 국소화하기 위해서 LCIE 기술이 이용됩니다. Internet Explorer 8 beta 1에서 크래쉬가 발생했을 때, 다음과 같은 도움말 풍선을 본 적이 있을지도 모릅니다.

이것이 "탭 복구 기능" 입니다. 이것에 의해 트러블은 문제가 발생한 탭으로 한정되었습니다. 브라우저expression body 는 소멸하지 않고, 신속하게 원래의 웹 사이트가 다시 표시됩니다.

이러한 현상이 발생했을 경우, 탭에 관한 각종 정보는 저장되어 복구 시에 이용됩니다. Internet Explorer beta 1에서는 다음의 정보가 유지 됩니다.

-  현재 URI

-  탐색 로그 (전/ 후 검색 기록)

-  탭 순서

-  어느 탭이 활성화되었는지

크래쉬가 발생하면 문제가 발생한 탭 프로세스는 닫혀지고, 새로운 탭 프로세스를 시동하여, 보관되었던 정보가 복원됩니다. 여러 웹 사이트에서 이 기능은 유효하게 동작하지만, 폼을 이용하고 있는 사이트나 로그온이 필요한 사이트의 경우, 정상적으로 동작하지 않을 수도 있습니다.

Internet Explorer beta 2에서는 다음과 같은 점에서 크게 개선되었습니다. 

세션 쿠키(Session cookie)

세션 쿠키는 웹 사이트가 사용자를 인증하기 위해서 이용됩니다. 세션 쿠키는 일시적인 쿠키로, 그 수명은 세션중에서만 입니다. 웹 사이트에 로그온하면, 일반적으로는 로그온 안에 사용자를 식별하기 위해 유일 토큰을 포함한 세션 쿠키가 제공됩니다. 웹 사이트 내를 이동하는 경우, Internet Explorer 는 이 세션 쿠키를 송신하고, 웹 사이트는 토큰을 조사하여 사용자가 인증되었는지 판정할 수 있습니다. 연속적으로 이용되는 쿠키와는 달리, 세션 쿠키는 하드 디스크에는 기록되지 않습니다.

Internet Explorer 8 beta 2 는 세션 쿠키의 복구를 가능하게 하지만, 하드 디스크에 기록하는 것은 아닙니다. Internet Explorer 8 beta 2 는 세션 쿠키의 복사를 프레임 프로세스에 저장합니다. 탭에 크래쉬가 발생했을 경우, 프레임 프로세스에서 탭 프로세스에 복원에 필요한 정보 (예를 들면 Web 메일, 블로그, SNS 등)가 자동적으로 다시 써집니다. 

세션 쿠키의 복원은 탭의 크래쉬가 발생했을 때에 만 행해지는 점에 주의해야 합니다. 대부분의 경우 크래쉬의 영향은 탭에만 머문다고 생각하지만, 만약 브라우저 전체가 크래쉬 했을 경우, 세션 쿠키는 없어집니다. 이러한 현상은 탭의 분리 기능에 대응하지 않는 애드온에 기인할 가능성이 높다고 생각할 수 있습니다.

폼 데이터(Form data)

Internet Explorer 8 beta 2에서는 폼에 입력한 데이터 복원도 가능합니다.  전자 메일이나 블로그의 글이나 댓글과 같이 HTML 폼에 입력한 정보도 복구할 수 있습니다.

LCIE 에 의한 탭의 분리 기능에 의해서, 자동 복구 기능은 데이터를 재입력하지 않아도 크래쉬 직전 상태를 복구할 수 있습니다. LCIE 와 자동 복구 기능 연동은 매우 혁신적으로 매우 훌륭한 크래쉬에서의 복구 수단을 제공합니다.

Windows 오류 보고 (Watson)

크래쉬나 멈추는 경우를 만났을 때 ,"Microsoft 에 정보를 송신 합니다" 라는 선택사항이 봤던 적이 있을지도 모릅니다. 보내진 정보를 우리가 어떻게 이용하고 있는지에 대한 의문을 가지고 있었을지도 모릅니다.

단적으로 말하면, 우리는 보내진 정보를 매일 확인하고 있습니다. 이러한 데이터는 매우 중요한 것이기 위해, 진지하게 보고서를 작성합니다. 그 뿐만 아니라, 현재 전세계로 어떠한 문제가 발생하는지 알 수 있어 그 원인을 한층 더 특정할 수도 있습니다. 실제로 오류 보고에 의해서 수정되는 사례도 있습니다.

Internet Explorer 가 크래쉬 또는 멈춰서, Windows 오류 보고의 송신을 선택했을 경우, 현상 발생시에 문제의 프로그램이 어떠한 상태에 있었는가 하는 정보가 모아집니다. Internet Explorer 가 크래쉬 했을 때에 어떠한 동작을 하고 있었는지, 어떠한 애드온이 로드되어 있었는지를 확인할 수 있습니다. 확인 담당의 프로그래머를 위해 메모리 덤프와 호출 스택도 송신합니다. 여러분이 Windows 용 응용 프로그램이나 Internet Explorer 용의 애드온을 생성한 프로그래머라면, 왓슨 데이터 취득하여 (영어) 여러분의 응용 프로그램의 품질을 개선할 수도 있습니다.

Windows 오류 보고에서는 유사한 문제를 일반적으로 같은 근본 원인을 가지는 현상으로서 "buckets" 에 정리합니다. Internet Explorer 의 프로그램코드에 기인하여 자주 문제가 발생한 경우, 코드를 수정하고 있습니다. Internet Explorer 8에서는 우리는 왓슨에 의해서 송신되는 모든 정보 가운데, 상위 50 %  (Internet Explorer 7에서 계속 발생하는 문제 포함)를 집중적으로 수정했습니다.

Microsoft 는 고객이 오류 리포트를 송신할 때의 프라이버시 보호에 대해서 전력을 기울이고 있습니다. 오류 발생시에 생성되는 보고용 데이터는 문제 해결에 필요한 최소한으로 합니다. 오류 리포트에는 어떠한 개인정보도 포함되지 않고, Microsoft 에 정보가 보내지기 전에 사용자 확인이 요구됩니다. Microsoft 는 오류 리포트의 송신자를 특정하지 않습니다 (송신자가 과거에 유사한 사례가 있는지를 확인하는 것을 선택했을 경우를 제외합니다). 비록, 문제 해결을 위해 보다 세부 사항정보가 필요한 경우에도 Microsoft 의 개발자는 고객을 확인할 수 없습니다.

Internet Explorer 8 beta 2 준비

LCIE 와 자동 복구 기능, 여러 가지 문제 수정하여 Internet Explorer 8 beta 2 는 충분히 신뢰할 수 있는 브라우저입니다. Internet Explorer 8 beta 2 가 공개되면 이 점에 꼭 주목해 주십시오.

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

영문 원본 :IE8 and Reliability

업데이트 일: 2008 년 7 월 28 일

이전 글에서는 일반적인 안정성 확보를 위한 행동 지침 (영어)과 제품의 세부 사항 (XSS Filter 와 안정성 (영어))에 대해 설명했습니다. 프라이버시 확보는 신뢰할 수 있는 컴퓨팅에서 중요한 위치를 차지합니다. 이 글에서는 타사 컨텐츠에 대한 웹에서의 프라이버시를 다룹니다.

웹 서핑을 하는 대부분의 사람들이 주소 표시줄에 표시된 URL과 현재 보고 있는 사이트가 같은 것이라고 생각합니다. 그러나 현재 웹 사이트는 많은 다른 웹 사이트에서 내용을 가져옵니다. 정확한 용어를 사용하면, 사용자가 직접 열람하는 사이트 (주소 표시줄에 URL 가 표시되는 사이트)를 퍼스트 파티 (first-party) 사이트, 퍼스트 파티 사이트가 도입한 내용을 제공하는 사이트 (이쪽은 사용자가 선택하지 않았습니다)를 타사 (third-party) 사이트라고 부릅니다.

퍼스트 파티 사이트를 열람할 때, 여러분이 이 사이트를 어떻게 이용하는지에 대한 정보를 수집할 수 있다는 것은 알고 계시리라 생각합니다. 그러나 많은 사용자는 타사 사이트에서도 같은 정보를 수집하는 것이 기술적으로 가능하다는 것은 모르고 있습니다. 어느 사이트가 정보를 수집하는지, 이 정보를 현재 어떻게 이용하고 있는지, 이 정보를 앞으로 어떻게 이용할지에 대해 일반 사용자들은 정확한 지식이 없습니다. 

타사 사이트 식별

현재 웹 사이트의 대부분이 실제로는 다른 여러개의 웹 사이트를 모자이크로 조합하거나 또는 매쉬업 됩니다. 이것은 프라이버시 리포트 (Internet Explorer 7 의 [페이지] 단추 또는 Internet Explorer 6 의 [표시]에서 [웹 페이지 프라이버시 정책] 을 선택합니다)를 실행하면 확인할 수 있습니다.

주소 표시줄에는 현재 표시되는 퍼스트 파티 사이트의 주소가 표시되는데 , 이 대화상자에는 다른 웹 사이트 (타사 사이트 포함)의 주소가 모두 표시됩니다. 브라우저는 현재의 웹 페이지 컨텐츠를 표시하기 위해, 모든 웹 사이트에 액세스합니다.

이와 같이 다른 사이트의 컨텐츠를 유용하게 하는 방법은 최근의 웹에서는 유익하고 강력한 일반적 방법입니다. 이러한 방법은 웹의 근간을 이루는 개념으로, 높이 평가되는 기능 (레스토랑 웹 사이트에 인터랙티브 지도를 찾거나  뉴스의 문서 내에 "공유하는" 라는 링크를 묻는)을 가능하게 합니다.

타사 사이트와 프라이버시

다른 웹 사이트에서 정보를 찾는 것은 동시에 프라이버시 유지에 영향을 줍니다. 이 문제의 좋은 예는 대부분의 사람들이 전자 메일에서 경험하고 있습니다. 많은 전자 메일 시스템은 불확실한 발신자가 보낸 전자 메일을 받을 때, 특수한 방법으로 이미지를 차단하여 (영어) , 다음과 같은 메시지를 표시합니다.

메시지 본문에는 일반적으로, 이미지가 보이지 않는 것을 나타내는 붉은× 마크와 「이미지를 다운로드 하려면 여기를 오른쪽 클릭해 주세요. 프라이버시 보호하기 위해, 메시지 내의 이미지는 자동적으로는 다운로드 되지 않습니다」라는 텍스트가 표시됩니다.

왜 전자 메일 시스템은 이러한 외부 이미지를 차단할까요?  이 송신자는 외부 이미지에 수신자 고유 정보 (예를 들면, 외부 이미지 파일 이름이나 주소에 수신자 주소를 포함하는 등)를 프로그래밍 할지도 모릅니다. 송신자는 특정 이미지가 다운로드 되었을 경우, 전자 메일이 도착한 것과 유효한 전자 메일 계정이 이 메일을 열었다는 것을 알게 됩니다. 이미지 파일을 다운로드하지 않으면, 수신자 정보가 확인되지 않아서, 불확실한 송신자로부터 프라이버시가 보호됩니다. 경우에 따라서는 임의로 보내지는 메일로부터  보호 받을 수  있습니다. 

일반적으로, 컴퓨터가 웹 사이트에 요청하는 모든 웹 컨텐츠는 그 사이트에 통지됩니다. 이 기본적인 기술은 다른 퍼스트 파티 사이트에서 만나도 같을 타사제품의 컨텐츠를 포함한 사이트이면, 타사에 의한 방문자 추적을 가능하게 합니다. 여러 개의 웹 사이트가 같은 타사의 웹 사이트에서의 컨텐츠 (사진이나 문서의 전달 등)를 게재했을 경우, 이 타사 사이트는 어느 웹 사이트에서 어느 방문자가 열람했는지를 확인할 수 있습니다.

예를 들면, Site1.com 와 Site2.com 라는 전혀 관계가 없는 사이트가 MySyndicatedPhotos.com 에서 전달하는 이미지를 게재했다고 합니다. 어떤 사용자가 Site1.com, Site2.com  두 곳을 모두 열람했을 경우, 사용자 브라우저는 이러한 사이트에 포함되는 이미지를 취득하기 위해, MySyndicatedPhotos.com 를 호출합니다. MySyndicatedPhotos.com 는 같은 컴퓨터가 두 다른 사이트를 방문했다는 것을 (여러 가지 방법으로) 확인할 수 있습니다.

같은 타사 사이트의 컨텐츠를 표시하는 사이트를 방문하는 사용자가 있으면, 타사 사이트는 그 컨텐츠를 포함한 웹 사이트를 어떻게 사용자가 이동하는지 활동 소개를 확인할 수 있는 입장에 있습니다.

Cookie는 확실히 도움이 되는 기술이며, "Cookie 를 이용한 추적 (트래킹 Cookie)" (영어) 에 관련된 걱정과 혼란이 오랜 세월에 걸쳐 계속 되어 있지만, 사실 어떤 컨텐츠도 타사 사이트는 트래킹 Cookie와 같이 기능시킬 수 있습니다. 그 컨텐츠가 의도하는 내용 (사진, 문서, 로고, 특정 용도의 분석 이미지, 텍스트, 스크립트)과 추적에 이용될 가능성과는 기술적인 관련성은 없습니다. 모든 Cookie 를 차단해도 다른 컨텐츠가 사용자 행동을 분석할 수 있는 것에 주의해야 합니다. 타사의 컨텐츠는 그 선악과 관계 없이 이러한 방법으로 이용하는 것이 기술적으로 가능합니다.

무엇이 일어나고 있는지, 기술적으로 무엇이 가능한가 그리고 그 외의 의문

문제를 명쾌하게 하기 위해, 여러 다른 사이트에 컨텐츠를 제공하는 웹 사이트는 무엇이 가능한지에 대해 다루고 있지만, 다른 사이트에 컨텐츠를 제공하는 모든 사이트가 실제로 이와 같은 것은 아닙니다. 타사 사이트에 제공된 이용 가능한 정보를 어떻게 이용하고 있는지를 확인하는 것에는 몇가지 측면에서 매우 어렵습니다. 타사 사이트는 활동 내용을 안내하기 위해, 명확하게, 적절히, 눈에 띄도록 제시된 프라이버시 정책을 게재할 수 있습니다. 그러나 그 내용처럼 행동하지 않을지도 모릅니다. 정책에 위반하거나, 수집한 데이터가 들어간 노트 PC를 분실하거나 맬웨어에 감염되거나 수집한 정보를 공개하는 종업원을 고용하고 있을지도 모릅니다. 수집한 데이터를 제공하는 것을 조건으로 개업 자금을 조달했을지도 모릅니다.

이 글은 사용자를 추적하기 위한 고도의 기술이나 고도의 기술을 가지는 사용자가 흥미를 가진 추적에 대한 대응책에 대해는 언급하지 않습니다. 여기에서는 퍼스트 파티 사이트가 방문자의 개체 식별을 위해서 수집한 정보가 타사 사이트에도  이동한다는 기술적인 일반론을 주제로 합니다. (앞의 전자 메일의 경우나 여기 (영어)에서 논함) .예를 들어, 웹 페이지 프라이버시 정책의 대화상자에서 보이는 웹주소가 대부분의 경우 긴 개체 식별자(dentifiers)를 포함합니다.  이러한 안건을 논의하는데 적합한 장소가 있습니다. 예를 들면, 새로운 리치 디자인인 사이트의 웹 표준의 개발에 관한 IRC  최근 화제 (영어)  가 그렇습니다. 이것은 매우  길지만, Cookie 를 송신하거나 하지 않아도 추적된 사람들의 이야기 (영어) 나 Cookie 없이도 웹 상에서의 활동을 추적할 수 있는 누군가… USER AGENT 의 문자열, IP 주소, 화면 크기, Java Script 나 HTTP 의 액세스 설정에서 쉽게 사람들의 "지문" 을 채취할 수 있어 간단한 분석용 스크립트를 이용하여 AOL 가 유출시킨 "익명" 검색 정보에서 찾을 수 있습니다 .

웹 브라우징은 타사 사이트가 없어도, 익명성은 없고, 완전하게 비공개도 아닙니다. 예를 들면, 인터넷 접속을 (집, 호텔, 찻집, 학교, 직장) 제공하는 공급자는 컴퓨터가 어디에 접속했는지를 관찰할 수 있습니다. 일반적으로, 공급자는 사용 조건을 제시하기 위해, 사용자는 명확한 주의를 받은 다음, 조건을 수락했는지, 거부하는지를 선택할 수 있습니다. 컴퓨터에서 동작하는 모든 소프트웨어는 이 컴퓨터가 어느 사이트를 방문했는지를 확인할 수 있습니다. 이 기술은 사용자의 브라우징 저널을 복사하여 웹 사이트에 업로딩하여 다른 컴퓨터에서도 이용할 수 있도록 하는 도구 막대나 브라우저 저널 기능의 기본이 됩니다. 반복하지만, 사용 조건과 프라이버시 정책은 사용자에서 지금 있는 중요한 도구입니다. 웹 사이트는 방문자 정보를 확인할 수 있습니다(예를 들면, 대체 위치 (영어)) .또 사용 조건을 클릭하거나 선택하여 웹 사이트에 직접 정보를 전달합니다.

타사 사이트의 신용성

웹 브라우징에 익명성이 없고, 이러한 구조로 움직인다면, 무엇이 신용에 관한 문제일까요? 많은 사람들에서, 신용은 보안에서 시작됩니다. 어떤 사이트를 방문하면 잠재적으로 다른 웹 사이트의 악의가 있는 컨텐츠에 노출되는 보안적인 위험은 명백합니다. 신뢰할 수 있을 것 같은 컨텐츠로 구성된 것처럼 보이는 사이트를 방문해도 현실에서는 다른 사이트의 내용이 포함되어 있는 일이 있습니다. 이러한 예를 웹에서 찾는 것은 어렵지 않습니다. 일부 유력 사이트 (예 1 (영어) ,예 2 (영어) ,예 3 (영어))의 방문자에게도 발생하고 있습니다.

이와 같이 신용은 프라이버시도 포함합니다. 프라이버시에 관해서는 사용자 선택과 어떤 정보를 제공할지 컨트롤이 관련합니다. 현시점에서는 브라우징 활동 상태에 대한 정보를 웹 사이트가 수집하는 것을 사용자가 컨트롤할 수 없습니다. 그 결과, 방문한 사이트와 관계가 명시되어 있지 않은 사이트가 브라우징 경향을 분석하기 위한 모습을 사용자는 눈치채지 못합니다.

Internet Explorer (와 신뢰할 수 있는 컴퓨팅에 관련하는 Microsoft 의 모두)를 위해서 안내하는 지침에서는 이용자가 컨트롤 해야 합니다. 일반 이용자는 브라우저의 보안 및 보호 기능을 기대하며, 동시에 프라이버시 보호에 대해서도 높은 기대를 갖고 있습니다. 여기서 말하는 컨트롤과는 이용자에게 명확한 주의가 주어지는 것으로, 어떠한 사이트가 어떠한 사용 조건아래에서 정보를 공개할지 아는 것입니다. 컨트롤과는 동시에 사용자가 누구에게 어떤 정보를 공개하는지를 선택할 수 있는 것을 의미합니다. 정보 누설을 막는 것은 컨텐츠 차단을 의미하지만, 컨텐츠 차단은 페이지의 외형이나 기능에 영향을 미칠 가능성이 있습니다.

또한 책임에 대한 현안이 있습니다. 어느 쪽에도 같은 타사 사이트의 컨텐츠를 포함한 다른 사이트를 방문했을 때, 사용자 정보를 수집하는 것에 대하여, 누가 이것을 설명하고 누가 책임을 지는 것입니까? 오늘날의 웹에서는 그것이 완전히 명확하지 않습니다.

타사의 컨텐츠에 관련된 프라이버시와 신용 문제는 복잡하고 중요한 문제입니다. 이 블로그에서  논의되었듯이 신뢰할 수 있는 브라우징은 많은 근면한 도전과 다른 많은 노력 (상호 운용성의 확보 등)을 포함하여 협조와 절충을 요청합니다. 웹에서의 프라이버시는 단순한 cookie 의 차단에 머물지 않고 보다 많은 일과 관련합니다. 이것을 깨달을 수 있으면, 사용자는 프라이버시를 관리할 수 있게 되겠지요. 이후 다른 글에서 사용자가 자신의 정보를 관리하는 도움이 되는 Internet Explorer 8 의 기능에 대해 설명합니다.

Dean Hachamovitch
General Manager

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

영문 원본 :Privacy Beyond Blocking Cookies: Bringing Awareness to Third-Party Content

업데이트 일: 2008 년 8 월 25 일

Internet Explorer 8 계획을 시작했을 때, 웹 사이트의 호환성을 유지하는 것을 공약으로 했습니다. 이 공약은 여전히 유효하고, Microsoft 의 상호 운용성에 관한 방침과도 일치하고, 우리의 성명 (영어) 에도 단기적인 영향을 주고 있는 것은 주목할 만합니다. 바꾸어 말하면, Internet Explorer 8 의 새로운 기능 중 가장 중요한 것은 호환성 확보이며 또 그것을 유지하는 것입니다.

Beta 2에서는 호환 표시로 불리는 새로운 기능을 탑재한다고 발표했습니다. 호환 표시는 이전 버전에서 디자인된 사이트를 Internet Explorer 8 이 적절히 표시하는 기능입니다.

호환 표시와 최종 사용자

웹 사이트가 최신의 웹 표준을 지원한다고 선언했을 경우, Intenret Exporer 8 은 그 선언을 존중하여 가장 표준에 맞는 메커니즘을 사용하여 이 사이트를 표시합니다. 대부분의 경우, 이것 때문에 문제는 없습니다. 그러나 드물게 「최신 표준을 사용하여 표시해 주세요」라는 선언이 사실은 「Internet Explorer 7 의 최신 표준으로 표시해 주세요」를 의미하는 경우가 있습니다. 이것은 호환 표시의 순서입니다.

드로잉 엔진에는 여러 가지가 변경되었지만, 알아 두어야 할 것은 다음과 같습니다.

• 일반 인터넷 사이트는 IE8 표준모드에서 표시됩니다.
• 호환 표시 기능의 변환 (IE7 표준모드와 IE8 표준모드)은 재시동 없이 즉시 실행됩니다.
• 호환 표시 기능은 도메인 단위로 기능합니다.

호환 표시를 컨트롤하는 새로운 사용자 인터페이스 단추는 탐색 모음 내의  주소 표시줄 우측 (업데이트 단추 근처)에 배포되어 Beta 1 의 Emulate IE7 단추를 대체합니다 .

표준모드에서의 표시중 과 같이 호환 표시로 전환하는 보다 좋은 결과를 얻을 수 있는 경우에만, Internet Explorer 는 이 단추를 표시합니다. Quirks 모드 혹은 인트라넷 사이트의 표시중 (다음에서 채택하지만, 이러한 경우는 이미 호환 표시 모드에서 표시) Internet Explorer 는 단추를 숨깁니다.

컴퓨터 처리 속도에 따라서는 호환 표시 단추를 선택한 후, 화면의 다시 읽기 포함을 확인할 수 있을지도 모릅니다. 어쨌든, 풍선 팁이 표시되어 현재 호환 표시 모드에서 동작중인 것을 알려줍니다. 또한 풍선 팁이 사라진 후도 호환 표시의 아이콘이 「누름」상태가 되어, 호환 표시로 동작중인 것을 확인할 수 있습니다.

에뮬레이션의 「효과 범위」는 단추를 누른 현재 표시중의 도메인으로 한정되어 실행 중 다른 프로세스나 탭에는 미치지 않습니다. 그리고, Internet Explorer 는 로컬 목록에 이 도메인 이름을 유지하기 때문에 같은 사이트를 방문했을 경우, 다시 단추를 누를 필요는 없습니다.

호환 표시와 엔터프라이즈

현재, 대다수의 기업용 웹 응용 프로그램은 Internet Explorer 7 이용을 전제로 합니다. 호환성을 유지하기 때문에 Internet Explorer 8 은 영역 판정에 근거하는 현명한 초기값을 설정해서 출시됩니다. 초기값에서는 인터넷의 모든 사이트는 Internet Explorer 8 표준모드 (호환 표시 무효)로 표시되어 인트라넷의 모든 웹 사이트는 Internet Explorer 7 표준모드 (호환 표시 유효)에서 표시됩니다.

몇가지 예를 봐 주세요.

jp.msn.com 이나 home.live.com 과 같은 인터넷에서 사이트를 표시하는 경우, 호환 표시는 초기값에서 무효가 됩니다. Internet Explorer 8 은 자신의 UserAgent 문자열을 "8" , 내부 버전을 "8" 이라고 인식하고, 표준 드로잉 모드를 Intenret Explorer 8 표준모드에서 전환하고, 웹 페이지를 표시합니다. https://192.168.0. 1 이라고 하는 IP 주소에 의한 지정도 같습니다. Internet Explorer 가 IP 주소를 내부 주소인가 외부 주소인가 분별할 수 없는 경우는 후자로 가정하여 동작합니다. 호환 표시에 의한 웹 사이트의 문제 수정은 이전의 Emulate IE7 단추를 이용한 것과 같습니다.

만약 https://myPortal 나 https://sharepoint/sites/mySite 라고 하는 로컬 인트라넷의 사이트로 이동했을 경우, Internet Explorer 는 자신의 UserAgent 를 "7" , 내부 버전을 "7" 이라고 인식하여, 표준 드로잉 모드를 Internet Explorer 7 표준모드에서 전환하고, 웹 페이지를 표시합니다. 이 편성은 Internet Explorer 7에서 정상적으로 표시되던 페이지를 Internet Explorer 8에서도 계속 이용하는 것을 가능하게 합니다.

완전을 기한다면, C:\Temp\MyWebPage.htm 라고 하는 로컬 페이지는 Internet Explorer 8 표준모드 (호환 표시 무효)로 표시하는 점에 주의할 필요가 있습니다.

[도구] 메뉴에 새롭게 추가된 항목은 이 기능의 세부 사항설정을 가능하게 합니다.

모든 인트라넷 사이트를 Internet Explorer 8 표준모드에서 표시하도록 설정할 수 있습니다. 모든 사이트를 Internet Explorer 7 표준모드에서 표시하는 것 (Emulate IE7 단추가 눌린 상태의 Internet Explorer 8 beta 1에서 같은 동작) 과 같이 정책을 설정할 수도 있습니다. 한층 더 항상 호환 표시 모드에서 표시해야 할 사이트를 사전에 등록하거나 호환 표시 단추를 눌러 등록한 목록을 편집할 수도 있습니다. Internet Explorer 8 의 UserAgent 스트링을 부정한 것으로 판단하여 차단하여, Quirks 모드에서 표시하는 페이지에 조우했을 경우, 현재 표시하는 문제의 사이트를 추가하는 본래의 기능은 특히 편리합니다.

이러한 새로운 기능의 모든 것이 그룹 정책으로 여러 가지 단추와 스위치를 조작하여 자세하게 설정할 수 있습니다. 대부분의 설정은 IEAK 를 이용하여 구성할 수도 있습니다.

호환 표시와 웹 개발자

최신의 웹 표준에 따라 DOCTYPE 선언에 의해서, 명시적으로 레이아웃 모드를 지정한 페이지를 생성했을 경우, Internet Explorer 는 예상대로 Quirks 인 DOCTYPE 는 Quirks 모드에 표준적인 DOCTYPE 는 Internet Explorer 8 표준모드에 관련됩니다. Beta 1 에서는 <META> 태그나 HTTP 머리글 (영어) , Internet Explorer 8 표준모드를 옵트 아웃(opt-out)할 수 있었습니다.

이용자가 웹 사이트를 최고 상태로 표시할 수 있어, 호환 표시 모드를 이용하지 않고 좋게 만들기 위한 가장 적절한 방법은 Internet Explorer 8 에 의한 테스트를 실시하여, 필요에 따라서 웹 사이트를 업데이트하는 것입니다. 이용자가 사이트를 표시하기 위해서 호환 표시 모드를 선택한 경우, 적절한 <META> 태그나 HTTP 머리글을 이용하고, 바람직한 레이아웃 모드에 "반환" 이 가능합니다. 새로운 content 값인 "IE=EmulateIE8" 는 이용 가능한 값의 목록을 완전하게 하여, 이 특별한 목적에 도움이 됩니다.

Content  설정 값

소개

IE=EmulateIE8

표준적인 DOCTYPE 의 경우, Internet Explorer 8 표준모드에서 표시합니다. Quirks DOCTYPE 의 경우, Quirks 모드에서 표시합니다. 이 태그를 사용하면, 클라이언트의 호환 표시 모드 설정을 무효로 하여, 표준적인 DOCTYPE 는 강제적으로 IE8 표준모드에서 표시합니다.

이 <META> 태그, 혹은 HTTP 머리글이 존재하는 경우, 이 사이트는 Internet Explorer 8 을 지원하기 위해서 업데이트된다고 보여, 이 값 이외의 클라이언트로 설정된 호환 표시 모드보다 우선됩니다. <META> 태그, 혹은 HTTP 머리글에는 다른 효과도 있습니다. 그 하나는 이 설정은 사용자가 장기간에 걸쳐 저장한 호환 표시의 웹 사이트 목록을 제거하는 트리거가 되어, 결과적으로 이 <META> 태그나 HTTP 머리글을 동시에 둘 필요가 없어집니다 (덧붙여서 브라우저 탐색 정보를 삭제하면 호환 표시를 위한 목록은 삭제됩니다) .또 하나는 <META> 태그 혹은 HTTP 머리글이 존재하는 경우, 명령 모음의 호환 표시 단추가 표시되지 않도록 , 대부분의 사용자가 호환 표시 목록에 사이트를 추가하여 효과적으로 관리할 수 있습니다.

User Agent 에 포함되는 새로운 태그는 호환 표시 모드를 이용하는 클라이언트 파악을 가능하게 합니다. Internet Explorer 8 표준모드의 태그도 존재합니다.

• 호환 표시 모드 :
  User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; Media Center PC 5.0; .NET CLR 3.5.21022)
• 최신의 Internet Explorer 8 의 UA String:
  User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; Media Center PC 5.0; .NET CLR 3.5.21022)

마지막으로, 이 기능에 대응한 개발자 도구의 업데이트도 완료했습니다. [브라우저모드] 메뉴에서는 서버나 웹 사이트에서 지정되는 동작 모드에 관련되지 않고, Internet Explorer 의 동작을 변경할 수 있습니다. 이 기능을 사용하면, Internet Explorer 8 표준모드에서 표시시켰을 경우, Internet Explorer 7 표준모드에서 표시시켰을 경우, Internet Explorer 8 의 호환 표시 모드에서 표시시켰을 경우의 동작을 확인할 수 있습니다.

[문서 모드] 는 [브라우저모드] 와는 독립해 존재해, 웹 사이트측에서 다른 DOCTYPE 나 <META> 태그를 사용했을 경우의 레이아웃의 변화를 확인할 수 있습니다.

요약

호환 표시 기능이 Emulate IE7 에 비해, 어떠한 점에서 개선되었는지 보았습니다. 

만약 호환 표시 기능으로 문제를 해결할 수 없는 웹 사이트를 발견하면 연락을 주세요.  Report a Webpage Problem (영어) 을 참조하시면 도움이 됩니다.

Scott Dickens
Lead Program Manager

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

영문 원본 : Introducing Compatibility View

업데이트 일: 2008 년 8 월 27 일

지난  1 년간, Internet Explorer 개발시에 웹 개발자의 생산성 향상을 도모하기 위한 다양한 도구 (Web Development Tools for Internet Explorer (영어)  또는 Tools for Detecting Memory Leaks (영어))에 대한 글을 써 왔습니다. 이러한 도구는 Microsoft 내부/외부 파트너가 개발한 것입니다. 그 중의 하나 (IE Developer Toolbar) (영어)는 사이트를 IE에서 디버그 하는데 도움이 되고, 무료이며 가벼운 도구를 원하는 요구에 따라 IE 팀이 개발한 것입니다.

IE8 Developer Tools 는 Internet Explorer에서 개발자의 생산성 향상을 지원하는 다음 단계입니다. 이 글에서는 IE8 Beta 1에서 이용 가능한 도구를 소개해고, 그러한 도구에 관한 상세 정보를 알려드립니다.

통합화되어 사용하기 쉬운 Developer Tools

Internet Explorer 8에서는 개발도구를 쉽게 바로 사용할 수 있도록 디버그 과정을 간소화했습니다. 다른 디버그용 응용 프로그램을 찾아서 다운로드하여 설치할 필요가 없습니다. Shift 키를 누르고, F12 키를 누르거나 명령 모음의［개발도구］아이콘을 클릭하면, 바로 사용할 수 있습니다.

또, JScript 를 디버그 할 때 ,［ Script (스크립트 ) ］ 탭으로 전환하여［ Start Debugging (디버그 시작 ) ］ 단추를 누릅니다. 스크립트 디버깅 기능이 활성화되지 않은 경우에도 Internet Explorer 8은 알림 메시지를 보여주고, 페이지를 새로 갱신하면서 현재 IE 창에 대해서만 디버깅 기능을 활성화 합니다. 또, 페이지를 갱신하는 것과 대화상자를 표시하지 않으려면 인터넷 옵션 컨트롤 패널의 ［ Advanced (세부 사항 ) ］ 탭에서 Internet Explorer 의 스크립트 디버그를 유효하게 하면 됩니다. 

다음은 디버거를 보여줍니다.

도구를 열고 있지 않은 경우에도 IE Developer Toolbar (영어)이 성능에 영향을 준다는 피드백을 받고, 그 문제를 해결하기 위한 설계를 했습니다. Beta 1 에서는 이 새로운 설계를 빌드하면서 IE 개발자 도구 모음의 새로운 기능을 모두 구현하는 것보다 새로운 시나리오 적용에 중점을 두었습니다. 결과적으로, IE 개발자 도구 모음이 많은 기능이 IE8 Beta 1에서는 이용할 수 없습니다. 그렇지만, 이후 Beta 버전에서는 새로운 기능을 추가하는 것과 동시에 개발자 도구 모음의 기능을 원래대로 하여, 이미 친숙한 기능을 사용할 수 있도록 할 예정입니다.

플랫폼의 비주얼 인터페이스

IE8 Developer Tools에서는 디버그 프로세스 간소화에 추가하여, 사이트에 관한 새로운 분석 관점이 제공됩니다. 단순히 관련된 Internet Explorer 의 내부표현을 표시할 수 있습니다. 예를 들어, 이 도구의 DOM 트리는 소스를 사용하는 것이 아니라, IE 가 내부에 생성한 트리를 사용하여 페이지를 표시합니다. 따라서, 스크립트 또는 트리를 변경하면, IE8에서도 업데이트한 트리가 표시됩니다. 요소의 스타일 정보를 표시하여, 다음과 같이 어느 규칙이 적용되는지 또는 어느 규칙이 기존의 스타일 속성을 지정할지를 훨씬 더 잘 이해할 수 있습니다.

검증 고속화

또, Internet Explorer 8 Developer Tools 는 IE 내부에서 사이트를 편집하여, 검증과 반복을 신속하게 실시할 수 있습니다. 예를 들어, 관심 있는 스타일 규칙이나 속성이 있으면, 그것을 유효화 또는 무효화하는 체크 박스를 클릭하거나 DOM 트리의 특성을 클릭하여, 그 자리에서 편집합니다.

이 도구를 사용하면, 이용 가능한 모든 표시 모드에 액세스가 쉽기 때문에 다른 모드를 빨리 테스트 할 수 있습니다.

변경 저장, 응용 프로그램 간의 변환, 페이지 업데이트를 할 필요가 없기 때문에  테스트, 디버그, 검증을 보다 빠르고 쉽게 실시할 수 있습니다.

그 외의 정보

Internet Explorer Developer Tools 에 대한 자세한 내용은 다음의 리소스를 참조해 주세요.

• Internet Explorer 8 Beta 1 베타 버전을 다운로드하여 도구를 시험하고,  사용 소감을 보내 주세요.
• Developer Tools 백서 (영어)
• Developer Tools SDK 페이지 (영어)
• 데모 비디오 : 소개 (영어)(비디오 버전 )
• 데모 비디오 : 디버그 (영어)( 약 6 분 )
• Internet Explorer 8 Beta 1 출시 노트

감사합니다.

John Hrvatin
프로그램 매니저
Internet Explorer

편집 : 「호환성 모드」의 이미지 업데이트

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

영문 원본 :Improved Productivity Through Internet Explorer 8 Developer Tools

업데이트 일: 2008 년 3 월 7 일

안녕하세요, Internet Explorer 의 User Experience 팀의 프로그램 매니저 헬렌입니다. IE8 의 즐겨찾기 모음을 소개하게 되어 영광입니다. 

즐겨찾기 모음의 새로운 기능 :

지금까지 링크 막대라 부르던 즐겨찾기 모음에 새로운 기능이 추가되어 즐겨 찾기의 웹 사이트 정보를 빠르고 쉽게 표시할 수 있습니다. IE8 의 새로운 즐겨찾기 모음에는 한번만 클릭하면 바로가는 즐겨 찾기 링크가 있지만, 웹 조각(IE8 의 새로운 기능 )과 피드도 즐겨찾기 모음에 추가되어 탐색이 더욱 쉬워집니다. 즐겨찾기 모음의 웹 조각와 피드에서는 즐겨 찾기의 웹 사이트로 이동하지 않고 그 컨텐츠가 업데이트 되었는지 확인할 수 있습니다.

다음에 보이는 즐겨찾기 모음에는 피드, 피드를 보관한 폴더 및 웹 조각이 포함되어 있습니다.

웹 조각(WebSlice) 소개

제인이 이전에 그녀의 블로그 「Internet Explorer 8 의 새로운 기능 : Activities 와 WebSlice」에서 설명했듯이, 웹 조각(WebSlice)이라는 IE8 의 새로운 기능을 사용하면, 옥션 가격, 최신 뉴스 등, 즐겨 찾기의 웹 사이트에 업데이트 된 컨텐츠를 바로 표시할 수 있습니다. 웹 조각(WebSlice)이란, 구독할 수 있는 웹 페이지의 부분 (“Slice ”)입니다. 구독한 웹 조각은 즐겨찾기 모음에 바로 가기로서 표시됩니다.

웹 조각이 표시되는 것은 웹 조각을 지원하는 웹 페이지만이라는 것에 주의해 주세요. 현시점에서는 Ebay , Facebook , Stumble Upon 등의 웹 사이트가 웹 조각(WebSlice) 지원을 추가했습니다. 자신의 웹 사이트에 웹 조각 지원을 추가하는 방법은 Internet Explorer 8 Beta 1 백서 (영어)를 참조해 주세요.

웹 조각(WebSlice) 사용 방법

웹 페이지에서 웹 조각을 추가할 수 있는지를 확인하는 방법은 두가지 있습니다. 하나는 명령 모음에서 웹 조각 버튼의 색깔이 변합니다. 

웹 페이지의 웹 조각에 마우스를 이동하면, 컨텐츠 옆에 웹 조각 아이콘도 표시됩니다. 이 아이콘은 즐겨찾기 모음에 추가할 수 있습니다. 다음에 예를 보여줍니다.

즐겨찾기 모음에 웹 조각을 추가하려면 명령 모음의 웹 조각 버튼을 클릭하거나 페이지의 웹 조각 아이콘을 클릭합니다.

IE8에서는 즐겨찾기 모음의 바로 가기 텍스트를 보면, 항목 상태를 알 수 있습니다. 웹 조각이 앞에서 사용한 뒤에 업데이트 되면,  텍스트가 굵은 글씨가 되고, 웹 조각의 유효기간이 다가오는 경우는 텍스트가 굵은 글씨의 기울임꼴, 유효기간이 끝나면 회색이 됩니다. 이 정보는 옥션 아이템을 체크하는 경우 등에도 많은 도움이 됩니다.

IE8 의 즐겨찾기 모음을 사용하면, 현재 열람하고 있는 웹 사이트에서 이동하지 않고 , 업데이트된 웹 조각의 컨텐츠를 미리 보기 할 수 있습니다. 즐겨찾기 모음의 웹 조각 바로 가기를 클릭하면, 웹 페이지를 미리 보기할 수 있고, 그 페이지를 클릭하면 그 웹 사이트로 이동할 수 있습니다.

웹 조각 미리 보기 ：

즐겨찾기 모음에 피드 추가

IE8에서는 즐겨찾기 모음에 피드를 추가할 수 있습니다. 피드를 구독하면, 컨텐츠가 업데이트 되었는지 즐겨찾기 모음에서 볼 수 있습니다.

아시는 바와 같이 피드를 구독하고, 즐겨찾기 모음에서 보려면 우선 [Feed Discovery (피드 탐색)]  를 클릭하여 피드를 표시한 후, 피드 페이지에서 [Subscribe to this Feed (이 피드 구독) ] 를 클릭합니다. 이 피드를 즐겨찾기 모음에서 보려면 [Add to Favorites (즐겨 찾기에 추가)]  를 클릭하여, [Monitor on Favorites Bar (즐겨찾기 모음에서 보기)] 를 클릭합니다. 즐겨 찾기 센터에서 즐겨찾기 모음에 피드 또는 피드의 폴더 전체를 드래그 엔드 드롭 할 수도 있습니다.

즐겨찾기 모음에서 피드의 바로 가기를 클릭하면, 기독의 피드 항목 (표준문자)과 미독의 피드 항목 (굵은 글씨)을 간단하게 구별할 수 있습니다.

그외 힌트와 바로 가기

• [Add to Favorites (즐겨 찾기에 추가)] 를 사용하여 링크를 추가하는 것과 함께, 즐겨찾기 모음에 링크를 드래그 엔드 드롭 하거나 주소 표시줄에서 즐겨찾기 모음에 웹 페이지의 아이콘을 드래그 하거나 웹 페이지에서 즐겨찾기 모음에 링크를 직접 드래그할 수 있습니다.
• 즐겨찾기 모음의 항목을 정리하려면 항목을 드래그하여 이동하거나, 폴더를 생성하여 즐겨 찾기 링크, 웹 조각  및 피드를 폴더내에 드래그 엔드 드롭 합니다.
• 폴더내의 항목이 업데이트되면, 폴더 자체가 업데이트 상태로서 표시됩니다. 폴더를 열지 않아도 폴더가 굵은 글씨가 아닌 경우는 폴더내 항목이 업데이트 되지 않은 것을 알 수 있습니다.
• 즐겨찾기 모음을 사용한 탐색도 편리합니다. 즐겨찾기 모음의 첫번째 항목에 커서를 이동하려면 Alt 키와 B키를  같이 누릅니다.
• 즐겨찾기 모음은 일반적링크와 같이 탭과 윈도우 바로 가기를 지원합니다. 예를 들어, 즐겨찾기 모음의 항목 또는 폴더를 Ctrl키를 누르면서 클릭하거나 내부를  클릭하면, 이 항목 또는 이 폴더의 컨텐츠가 배경의 하나 또는 여러 개의 새로운 탭에서 열립니다.
• 마찬가지로 즐겨찾기 모음 항목을 Ctrl키를 누르면서 Shift키를 눌러 클릭하면, 전경의 탭에 이 항목이 열립니다.

이상은 IE8 즐겨찾기 모음을 사용하여 즐겨 찾기 웹 페이지 정보를 빠르고 간단하게 표시하는 방법을 소개했습니다. 

IE8 Beta 1 을 시험해 주셔 감사합니다. 이 기능에 대한 여러분들의 피드백을 기다리겠습니다.

Helen Drislane
프로그램 매니저

* 이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

영문 원본 :The IE8 Favorites Bar

업데이트 일: 2008 년 3 월 12 일

최근 Internet Explorer 8 Beta 1 출시를 위해 개발중인 IE 팀은 성능에 심혈을 기울이고 있습니다. IE  향상을 위한 노력의 일환으로 실행한 조사에서, 몇가지 애드온에 성능상의 문제가 있다는 것을 알았습니다. 이 글에서는 우리가 발견한 공통의 테마를 이야기합니다.

우선 먼저 이 블로그에 관한 피드백을 IE Beta 뉴스 그룹이나 around the web (영어) 를 통해 주신 여러분에게 감사합니다. Internet Explorer 팀은 IE8 의 성능에 관해서 열심히 노력을 계속하고 있으며, 초기 단계에서 성과로 이어진 것을 매우 기쁘게 생각합니다. 아직 개선의 여지 (와 계획)는 있지만, IE8 Beta1 의 성능 개선에 관한 자세한 내용은 개발자 백서 (영어)를 참조해 주세요.

IE 의 애드온 개발이 처음으로, 참조가 필요한 경우에는 다음의 몇가지 링크에서 시작하는 것을 권장합니다.

• Visual Studio 2005 의 브라우저 도우미 개체 개발 (영어)
• 안정된 브라우저 확장기능 생성 (영어)
• 애드온 개발 (영어)

대략적으로 말하면, 애드온 성능 문제는 일반적으로 두가지 영역에서 IE 사용자에 영향을 줍니다.

1. IE 윈도우 또는 각각의 탭 열기/닫기
2. 브라우저 반응

윈도우나 탭이 열리고 닫히는 속도는 생성될 때마다 부하가 높은 일을 많이 실행하는 애드온에 크게 영향을 받습니다. 특별히 공통된 문제의 하나는 브라우저를 실행하거나 종료하는 동안에 애드온이 업데이트를 확인하는 것입니다.

레지스트리를 잘못 사용하면 반응을 느리게 만듭니다. 이것은 공통된 문제의 하나입니다. 애드온의 상당수는 부하가 높은 레지스트리 조작을 실행하지만, 이것은 Internet Explorer 반응을 저하시킬 가능성이 있습니다.

다음에서 이 두가지 영역을 설명하고, 애드온 성능을 설계할 때의 지침을 몇가지 소개합니다.

애드온 초기화와 업데이트 확인

• 원칙 1 : 무리하지 않음 : 힘든 일은 다른 스레드에 맡김
• 원칙 2 : 부스에 도착한 후 요금을 지불

시작할 때, Internet Explorer 는 레지스트리를 조사하여, 설치된 애드온을 확인합니다. 브라우저 도우미 개체 또는 도구 막대가 설치된 것을 IE 가 검색하면 CoCreateInstance 를 호출하여, 설치되어 유효한 애드온을 인스턴스화합니다. Internet Explorer 는 기본적으로 애드온을 인 프로세스 서버로서 생성하여, IE 의 메인 UI 스레드 중에서 실행합니다. 하위호환성을 위해 Internet Explorer 는 열린 각 탭에 대해서 이러한 단계에 따릅니다. 이 동작은 몇가지 이유 때문에 중요합니다. 그 이유는 애드온이 직면한 가장 일반적인 문제를 설명하면 이해하실 수 있을 것입니다.

무리를 하지 않는 : 힘든 일은 다른 스레드에 맡긴다

일반적으로 많은 애드온에서 공통된 경향의 하나는 온라인 컨텐츠와의 통합입니다. 라이브 데이터에 관해서 이 통합화를 유지하려면 항상 업데이트 메커니즘이 필요합니다. 조사한 결과에 따르면 많은 경우에 초기화 동안에 IE 가 제어를 애드온 SetSite 구현에 전달할 때, 애드온은 동기 업데이트 확인을 실행합니다. 다음은 Internet Explorer에서 애드온이 초기화되는 방법에 대한 설명으로, 이러한 종류의 업데이트 확인이 어떤 영향을 미치는지를 추측할 수 있습니다. 다음과 같은 흐름을 생각해 주세요.

1. IE 가 초기화 시작
2. Foo 도구 막대가 설치된 것을 IE 가 검색
3. IE 는 Foo 도구 막대의 SetSite 메서드 호출
4. 업데이트 된 컨텐츠를 확인하기 위해, Foo 도구 막대는 https://foo.example.com 에 액세스
5. Foo 도구 막대는 IE 에 제어 반환
6. IE 는 초기화를 계속하여 사용자 홈 페이지 표시

문제가 이해 되셨나요?  단계 4를 생각해 주세요. 만약, Foo 도구 막대가 업데이트해야 할 컨텐츠를 다수 찾아내거나, 컨텐츠 서버와의 접속이 늦어지거나 또는 사용자가 오프라인으로 작업하면 어떻게 될까요? 대답은 (애드온은 UI 스레드의 문맥내에서 실행되므로 ) 도구 막대를 위해서, IE 가 장시간 반응하지 않게 되거나 실행과 종료의 소요 시간이 크게 늘어납니다. 보다 좋은 방법은 작업 스레드를 생성하여, 컨텐츠 업데이트를 비동기로 실시하는 것입니다.

추천 방법은 SHCreateThread (영어) (애드온을 C++ 로 개발 한 경우)를 다음과 같이 사용하는 것입니다.

STDMETHODIMP SetSite(IUnknown* pUnkSite)

{

if (pUnkSite != NULL && IsUpdateRequired())

{

        SHCreateThread(Update, NULL, CTF_COINIT | CTF_PROCESS_REF, NULL);

}

else

{

         // Release cached pointers and other resources here.

}

// Return the base class implementation

return IObjectWithSiteImpl<CHelloWorldBHO>::SetSite(pUnkSite);

}

DWORD WINAPI Update(LPVOID pParam)

{

            DWORD dw = 1;

            // Perform update here

           return dw;

}

DWORD WINAPI IsUpdateRequired()

{

           DWORD dw = 1;

            // Perform a low-cost check here to verify that an update should be

            // performed. This can be accomplished by checking a registry key. 

           return dw;

}

앞에서 말한 바와 같이, SetSite 는 신규 스레드를 생성하여 업데이트 메서드를 실행하는 것에 주의해 주세요. 이 방법을 이용하면, SetSite 가 장시간 UI 스레드를 차단할 위험이 없고, 애드온은 컨텐츠를 업데이트할 수 있습니다. 또, 적절한 빈도 (2 , 3 매일등 )로 업데이트 확인을 실시하여, 브라우저나 탭을 열 때마다 업데이트를 확인하는 부담을 사용자에게 주지 않고 애드온을 빠르게 업데이트 할 수 있습니다.

이 방법을 사용하면 장시간 계속되는 처리를 IE 메인 UI 스레드에서 제외할 수 있어 체감상의 성능을 향상시킬 수 있습니다. 다만, 작업 스레드 작업이 반드시 좋은 방법은 아니라는 것은 알고 있어야 합니다. 잠재적인 문제는 여러가지 있습니다. 예를 들어, 작업 스레드에서 이행하는 장점보다, 부하가 높은 스레드에 걸치는 많은 COM 호출 부하가 더 클 가능성이 있습니다.

부스에 도착하고 나서 요금을 지불한다

장시간의 조작을 작업 스레드에서 이행하는 것으로, UI 행을 회피할 수 있습니다. 그럼에도 불구하고, 애드온이 초기화될 때마다, 사용자는 지불할 필요가 없는 비용을 미리 선불해야 할 가능성이 있습니다. 사용자는 IE 를 실행 할 때에 업데이트 컨텐츠를 잘 이용하지 않는 경우가 자주 있습니다. 이러한 경우에서는 사용자와 컨텐츠 공급자 모두가 거기에 알맞은 이익이 없음에도 불구하고, 업데이트 확인에 수반하는 불필요한 비용을 지불합니다.

컨텐츠 업데이트를 실시하는 궁극의 방법은［업데이트 확인］메뉴 항목을 클릭하고, 사용자가 명시적으로 신규 컨텐츠를 요청할 때만 업데이트를 실시하는 방식입니다. 그렇지만, 이 해결책은 애드온 성능을 떨어트릴 가능성이 있기 때문에 많은 경우에 비현실적인 방법입니다. 예를 들어, 드롭 다운 메뉴를 클릭했을 때, 업데이트 컨텐츠가 다운로드되는 동안, 부수된 드롭 다운 메뉴의 표시를 잠깐이라도 기다려야 한다면, 참기 어려울 것입니다. 

더 효과적인 방법으로 사용자 경험과 선불 비용의 균형을 맞추는 기술은 그 밖에 여러 가지 있습니다. 예를 들어, 도구 막대 개발자는 업데이트 확인을 SetSite에서 완전히 이동하여, 사용자가 처음 마우스를 도구 막대 위에 움직였을 때 또는 고정 스케줄에서 업데이트  확인하는 것이 좋을 수도 있습니다. 최적의 해결책은 애드온 마다 다르기 때문에 항상 크리에이티브한 것, 그리고, 가능한 사용자에게 고정된 부담을 주지 않도록 노력하는 것이 중요합니다.

거의 모든 경우에 SetSite 또는 OnDocumentComplete 처리기에서  많은 작업을 회피할 수 있는 방법이 있습니다. 이러한 영역에서 문제를 해결하고, 여분의 시간을 할애하는 것은 성능 문제를 회피하고, 사용자가 확실하게 애드온을 설치할 수 있는 아주 좋은 방법입니다.

레지스트리 사용

• 원칙 3 : 캐싱 활용
• 원칙 4 : 나쁜 버릇을 멈춘다 (플러시 금지 )

캐싱을 활용한다

레지스트리 사용에서 연상되는 것은 1996 년 즈음에 유행했던 마카레나 (영어)입니다. 단계를 알고 있는 사람은 극히 소수이지만, 춤을 잘 출 수 있는 사람은 훨씬 더 적었지만, 모두가 참여하는데  그 사실이 전혀 방해되지 않았습니다. 레지스트리의 과도한 사용은 Windows 응용 프로그램에서는 일반적이고, IE8에서는 레지스트리 액세스를 줄이기 위해서 상당한 노력을 했습니다.

레지스트리의 과도한 사용이 꺼려지는 것은 레지스트리 조작의 오버헤드가 중대한 문제가 될 가능성이 있기 때문입니다. 캐시 키의 개폐나 로드는 몇만 주기 분의 부하가 될 수 도 있습니다. 시작시에 각각의 애드온이 수백, 수천, 때로는 수만번 레지스트리에 액세스 하는 것은 비교적 보통이므로, 액세스 수가 누적하면 브라우저가 급속하게 늦어집니다.

다행히, 레지스트리 사용의 부하를 줄이는 것은 가능합니다. 무엇보다도 우선, 공통의 경우에서  최적화합니다. 애드온 실행중, 대부분의 레지스트리 값은 변경되지 않기 때문에 값을 한 번 로드하여 캐시에서 유지하면 각 레지스트리에의 액세스 회수를 크게 줄일 수 있습니다.

레지스트리에의 액세스는 배제할 수 없지만, 나머지 조작의 부하는 줄일 수 있습니다. 레지스트리의 완전 경로 (HKEY_LOCAL_MACHINE\Foo\Bar 등 )를 사용하여 키에 액세스 하는 것은 주어진 루트에서 대상 키까지의 계층수에 의해, 상대경로에 비해 2 , 3 배의 부하가 걸립니다. 애드온에서는 일반적으로, 설정 대부분이 키나 소수의 키 집합의 아래에 있습니다. 예를 들어, 애드온에서 IE 에서 사용되는 연결을 취득해야 합니다. 이 경우, 다음의 레지스트리키에 액세스해야 합니다 (HKEY_LOCAL_MACHINE 아래 ) .

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\FileAssociations

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\MIMEAssociations

\SOFTWARE\Microsoft\Internet Explorer\Capabilities\UrlAssociations

Win32 메서드 RegOpenKey 를 사용하면, 다음에 발췌한 것 같은 코드로 각 regkeys 에 액세스 할 수 있습니다 (예로서 FileAssociations 를 사용합니다) .

HKEY hk;

RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities\\FileAssociations", &hk);

나머지 키는 HKEY_LOCAL_MACHINE 를 루트로 하여 같이 액세스 할 수 있습니다. 그렇지만, 이 경우 더 좋은 방법은 Capabilities 키의 핸들을 생성하여, 추가의 상대경로 RegOpenKey 조작을 실시해서, 나머지 값을 취득하는 것입니다. 그 방법은 다음과 같습니다 (다시, 예로서 FileAssociations 를 사용합니다 ) .

HKEY hkRoot;

RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities", &hkRoot);

HKEY hkFileAssoc;

RegOpenKey(hkRoot, L"FileAssociations", &hkFileAssoc);

나쁜 버릇을  고치다(플러시 금지)

마지막으로, 레지스트리 값이 확실히 디스크에 써지도록,RegFlushKey 를 사용하는 애드온이 과거에 있었습니다. 상황에 따라서는 다른 탭이나 윈도우에서 실행중의 애드온 두가지의 인스턴스 간의 상태를 유지하기 위해서 이 처리를 실시합니다.

RegFlushKey 에 관한 MSDN 문서 (영어)에서  말한 것처럼, 이 API 를 사용할 필요는 거의 없습니다. 또한 레지스트리를 백업하는 모든 데이터가 확실히 디스크에 쓰여지도록 하기 위해,RegFlushKey 호출은 놀라울 정도로 부하가 높아질 가능성이 있습니다. 이 처리는 호출한 프로그램에 제어가 반환될 때까지 수백 밀리 초가 소요될 가능성이 있습니다.  그리고, 단점은 그 처리가 완료할 때까지, 레지스트리 액세스가 차단됩니다.

결과적으로,RegFlushKey 호출은 IE 에 영향을 줄 뿐만 아니라, 시스템 전체의 성능을 저하시킬 가능성이 있습니다. 인스턴스간의 동기에게 이 레지스트리를 사용하는 애드온은 레지스트리를 플러시하는 것보다도 상태 유지에 RegNotifyChangeKeyValue (영어)를 사용할 수 있습니다. 자세한 것은 다음에 있는 랠리·오스타만과 레이몬드·첸의 블로그 글을 참조해 주세요. 레지스트리 사용에 관한 것으로, 도움이 될 것 입니다. 

• 심리적 성능 분석 또는「RegFlushKey 는 정말로 레지스트리키를 플러시 한다」 (영어) (랠리·오스타만)
• 레지스트리키 읽기 성능 비용 (영어) (레이몬드·첸)

애드온 성능 개선에 관한 말씀드린 내용이 지금까지 접한 공통 문제의 몇가지를 이해하는데 도움이 되기를 바랍니다.

Internet Explorer 의 에코시스템에 훌륭한 애드온을 제공해주어 감사합니다. 여러분의 피드백을 기다리겠습니다. 

Christian Stockwell
프로그램 매니저
성능 담당

편집 : 다음의 행에 Root 를 추가 : RegOpenKey(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Microsoft\\Internet Explorer\\Capabilities", &hkRoot);

*  이 글은 Internet Explorer 개발 팀 블로그 (영어)의 번역 문서입니다. 이 글에 포함된 정보는 Internet Explorer 개발 팀 블로그 (영어)가 생성된 시점의 내용으로, 제품의 사양이나 기능이 보장되는 것은 아닙니다. 이 글에 포함된 정보의 이용은 사용 조건을 참조해 주세요. 그리고, 이 글의 게재 시점에서 Internet Explorer 개발 팀 블로그 (영어)의 내용이 변경될 수 도 있습니다. 최신 정보는 Internet Explorer 개발 팀 블로그 (영어)를 참조하십시오. 

영문 원본 :Designing for Add-on Performance

업데이트 일: 2008 년 4 월 8 일