기업에서 최신 버전의 Windows로 업그레이드하려면 일반적으로 전체 비즈니스 앱에 대해 최신 버전의 Internet Explorer와의 호환성 테스트를 해야 합니다. 이 작업이 쉽지 않은 이유는 기업이 내부 비즈니스 응용 프로그램 카탈로그에서 중요하면서도 직원들이 사용하고 있는 응용 프로그램이 어느 것인지를 잘 모르기 때문입니다. 이 때문에 IT 전문가들은 내부 앱을 모두 테스트하게 되고, 심지어 사용하지 않는 앱까지도 테스트하게 되어 비용과 시간을 낭비하는 경우가 종종 있습니다. 테스트뿐 아니라, 응용 프로그램이 어떻게 구축되는지에 대해 제대로 잘 알지 못하면 호환성 문제를 해결하기가 어려울 수 있습니다.

엔터프라이즈 사이트 검색 도구 키트를 사용하면 사용자가 Internet Explorer 11으로 어떻게 검색하고 있는지를 IT 전문가들이 더 잘 파악할 수 있습니다. 이 도구 키트를 통해 Internet Explorer 11에서 엔터프라이즈 사용자들이 방문하는 모든 사이트에 대한 정보를 수집하여 기업 내에서 사용되고 있는 사이트 현황을 조사할 수 있습니다. 이 정보는 IT 전문가들이 Internet Explorer와의 앱 호환성 테스트를 어떤 응용 프로그램에 집중해야 할지 우선순위를 정하는 데 도움이 됩니다. 또한 이 도구 키트는 사이트가 어떻게 설계되고 Internet Explorer에서 어떻게 사용되는지에 대한 자세한 정보를 제공하며 이 정보를 통해 엔터프라이즈 모드 사이트 목록을 파악할 수 있어 중요한 사이트의 호환성 문제를 해결할 수 있습니다.

어떤 정보가 수집되나요?

기본적으로, 데이터 수집 기능은 설정이 해제되어 있습니다. 수집 기능을 설정하면 사용자가 Internet Explorer 11으로 방문한 모든 사이트에서 데이터가 수집됩니다. 각 사이트 검색 과정에서 데이터가 수집되어 여기에 표시된 검색 URL과 연결됩니다. 이 데이터 수집이 Internet Explorer의 성능에 미치는 영향은 무시할 정도로 미미합니다.

각 사이트 검색 과정에서 수집되는 데이터

이 데이터로 무엇을 할 수 있나요? 검색 도구 키트를 사용하면 IT 전문가들이 실제 사용자 데이터를 근거로 IE가 자신이 배포한 프로그램에서 어떻게 사용되고 있는지 확실하게 파악할 수 있습니다. 이를 통해 많은 질문에 대한 답을 얻을 수 있습니다. 예를 들면 다음과 같습니다.

• 사용자들이 가장 많이 방문하는 사이트는 어디인지?
• 어떤 문서 모드에서 페이지가 로드되며, 그 문서 모드는 어떻게 선택되었는지?
• 어떤 사이트에서 ActiveX 컨트롤이 사용되며, 얼마나 자주 사용되는지?
• 사용자들이 방문할 때 어떤 사이트가 충돌 또는 정지하는지?
• 신뢰할 수 있는 사이트 목록에서 삭제해야 할 사이트가 있는지?
• 엔터프라이즈 모드 사이트 목록에서 추가하거나 삭제해야 할 사이트가 있는지?

IT 전문가가 이 사이트 검색 도구 키트를 처음 사용하려면 어떻게 해야 하나요?

• 도구 키트에 대한 자세한 내용은 Technet을 참조하십시오.
• 최신 누적 업데이트(2014년 10월 이후)로 Internet Explorer를 업데이트하십시오.
• 구성 및 설정 스크립트를 다운로드하십시오.
• 샘플 보고서 살펴보기

우리는 이 도구 키트에 많은 기대를 걸고 있습니다. 여러분도 이 도구 키트를 체험해 보고 데이터 수집 기능을 사용해 보면서 그 진가를 느끼시기 바랍니다! 의견이 있으시면 @IEDevChat 또는 Connect를 통해 알려 주십시오.- Internet Explorer 프로그램 관리자, Deen King-Smith

Microsoft는 HTTP(Hypertext Transfer Protocol) 개선을 위한 중요한 재작업을 진행하기 위해 1999년 이후 최초로 Internet Explorer 지원 기능을 내놓을 계획입니다. 다소 시간이 오래 걸렸지만 이제는 때가 되었습니다.

지난 몇 년 동안 웹 아키텍처를 간소화하기 위해 많은 노력을 기울여 왔지만 HTTP/2 정도의 규모를 자랑한 적은 한 번도 없었습니다. IETF HTTPbis 작업 그룹의 일환으로 새롭고 효율적이며 호환성 높은 표준을 개발하는 이 작업을 지원하기 위해 많은 노력을 기울여왔습니다. 두 번째로 발표되는 것이기 때문에 HTTP/2라고 하며 Windows 10 기술 프리뷰부터 새로운 Internet Explorer에 포함되어 이제 사용 가능합니다.

Microsoft Open Technologies HTTP/2 페이지를 확인하면 HTTPbis 작업 그룹과 관련하여 진행해 온 작업의 개요를 볼 수 있습니다.

HTTP/2가 구현된 Internet Explorer가 최고인 이유는 무엇인가요?

점점 더 실시간에 가까워지고 모바일이 중요해지고 있는 요즘에는 성능이 중요합니다. 점차적으로 조금씩 개선되는 작은 변화도 중요한 시대입니다. 예를 들어 Bing에서 실시한 한 조사에 따르면 사이트의 페이지 로드 시간이 10ms 증가할수록 매출이 매년 25만 달러씩 저하됩니다. 눈을 깜박이는 속도의 1/3에 해당하는 100ms가 증가하면 검색 결과 관련성을 개선하여 사용자 참여도를 향상시킨 3개월의 작업이 수포로 돌아가게 됩니다. 거래 웹 페이지 응답 속도가 100ms 늘어나게 되면 규모가 큰 온라인 소매업체의 경우 검색 포기로 인해 매출이 최대 1%나 떨어지는 것이 확인되었습니다. 즉, 이 작업 그룹이 하고 있는 노력은 실질적인 경제적 효과를 창출합니다.

과거 방식에 문제가 있었던 것입니까?

전반적으로 말해 현재 웹 페이지가 로드되는 방식은 800x600픽셀 디스플레이의 시대와 거의 같은 방식이었습니다. 분명 지금의 웹은 예전보다 속도가 빨라졌지만 훨씬 더 빠르고 훨씬 더 리소스에 효율적으로 만들 수 있습니다.

페이지 구축하는 데 필요한 브라우저와 서버 간의 개별 쿼리의 수도 지금이 훨씬 많아졌고, 각 개별 호출은 다음 호출을 보내기 전에 서버가 응답할 때까지 대기해야 합니다. 물론 더욱 독립적인 병렬 연결을 더 많이 열 수는 있지만 그래도 동시에 요청할 수 있는 항목의 수가 제한됩니다. 또한 병렬 연결 수는 응답 순서를 좌우하고 서버가 응답을 최적화하지 못하게 만듭니다.

그렇다면 HTTP/2는 어떻게 다른가요?

HTTP/2는 사용 가능한 모든 대역폭을 활용하여 웹 페이지 요소를 더욱 빠르고 효율적으로 제공합니다. 연결이 오래 유지되고 다중화(다수의 요청을 하나의 연결로 결합할 수 있는 프로토콜의 기능)가 가능해져 더 많은 웹 페이지 항목들을 더욱 빨리 가져올 수 있습니다. 서버 푸시 및 요청 의존성과 같은 실험적인 HTTP/2 기능은 앞으로 웹 기능을 더 향상시킬 수 있습니다.

개발자에게는 어떤 의미가 있을까요?

HTTP/2는 처음부터 이전 버전인 HTTP/1.1와도 호환되도록 설계되었습니다. 그렇기 때문에 HTTP 라이브러리 개발자들은 API를 변경할 필요가 없고 그 라이브러리를 사용하는 개발자들도 응용 프로그램 코드를 변경할 필요가 없습니다. 엄청난 이점이 아닐 수 없습니다. 개발자들은 전에 했던 작업을 최신 상태로 만들기 위해 몇 달 동안 작업할 필요 없이 바로 진행할 수 있습니다.

네트워크와 보안은 어떤가요?

빈번한 연결 수가 적어졌다는 사실은 HTTP/2가 네트워크에 전달하는 부담이 줄어들었다는 의미도 됩니다. 그리고 현재 웹의 규모를 고려하면 네트워크, 특히 모바일 네트워크의 효율성이 상당히 높아질 수 있습니다. HTTP/2의 효율적인 연결 모델을 고려할 때, 사이트에 TLS를 추가하는 성능 효과가 줄어들어 더 많은 관리자들이 사이트에 TLS를 추가할 기회가 생겨납니다.

언제 사용할 수 있나요?

HTTP/2 지원은 Windows 10 기술 프리뷰의 IE에 포함됩니다. IE용 HTTP/2에 대한 작업은 실제로 실험적 SPDY 3.0 프로토콜을 추가한 Windows 및 Windows Phone 8.1에서 시작되었습니다. 이 기간 중에 HTTP 프로토콜 다중화 부분에서 경험을 쌓을 수 있었고 계속 작업을 진행하여 HTTP/2를 탄생시킬 수 있었습니다. 이제 이것이 업계 표준이 될 것입니다.

SPDY는 HTTP/2 표준에 알맞은 출발점이 되었지만 장기적인 채택에 도움이 되지 않는 실험적인 프로토콜입니다. HTTP/2이 개발되면서 향후 모든 IE 버전에서 SPDY 지원을 제거할 예정입니다. 현재 SPDY를 사용하고 있는 웹 사이트와 응용 프로그램을 거의 변경하지 않고도 HTTP/2로 마이그레이션할 수 있게 됩니다.

개발자와 사이트 소유자는 이러한 변화에 대해 어떤 준비를 해야 하나요?

• IE Windows 10 기술 프리뷰 버전 실행
• 개발자 도구를 시작하고 네트워크 추적 설정
• HTTP/2 초안-14를 지원하는 사이트 로드. 몇 가지의 유용한 사이트는 다음 구현자 페이지에 나열되어 있습니다. https://github.com/http2/http2-spec/wiki/Implementations
• HTTP/2 패킷 흐름 주시

기술 프리뷰에는 HTTP/2 서버 지원도 포함되어 있습니다. 즉, IIS에서 사이트를 만들고 처음부터 끝까지 콘텐츠를 테스트할 수 있습니다. 참고: IE와 IIS 모두 기술 프리뷰 버전에서 안전하지 않은 연결(즉, HTTP)은 HTTP/2에서 지원되지 않습니다. 안전한 연결(즉, HTTPS)만 HTTP/2에서 지원됩니다.

HTTP/2 구현에 대해 살펴보고 그 진가를 경험하시기 바랍니다! 의견이 있으시면 @IEDevChat 또는 Connect를 통해 알려 주십시오.

- 수석 프로그램 관리자 Rob Trace

- 수석 프로그램 관리자 David Walp

Windows 10 Technical Preview에 추가된 IE의 새로운 기능

HTTP/2

Windows 10 Technical Preview의 Internet Explorer에는 광범위한 업계 지원을 바탕으로 한 표준화 노력을 통해 탄생한 새로운 HTTP/2 네트워킹 프로토콜에 대한 지원이 포함되어 있습니다. HTTP/2는 IE11에서 SPDY/3 지원을 제공하는 환경을 기반으로 구축되며 다중화, 헤더 압축 및 서버 밀어넣기 등의 기술을 사용하여 웹에서 향상된 성능을 지원합니다.

Windows Technical Preview의 IE에서 F12 도구에 나와 있는 HTTP/2 지원

Chakra JavaScript 엔진 성능 개선

Windows 10 Technical Preview의 IE에는 Chakra JavaScript 엔진의 향상된 여러 가지 기능도 포함되어 있습니다. 빠른 시작을 제공하기 위한 Chakra의 실행 파이프라인 간소화, 스크립트 실행 처리량을 늘리기 위한 Chakra의 Just-in-Time 컴파일러 최적화, 앱과 사이트에 대한 더 나은 UI 응답성을 제공하기 위한 Chakra의 가비지 수집 하위 시스템 강화 등이 달라졌습니다.

상호 운용 가능한 최상위 도메인 구문 분석

Windows 10 Technical Preview의 IE는 https://publicsuffix.org에 나와 있는 알고리즘 및 도메인 목록을 사용하도록 도메인 이름의 구문 분석을 전환합니다.

UserVoice에서 IE Platform Suggestion Box 시작

또한 UserVoice 피드백 플랫폼을 기반으로 한 IE Platform Suggestion Box를 이용할 수 있게 되었음을 알려 드립니다. 이는 웹 개발자와 보다 효과적인 양방향 대화를 구축하기 위해 월간 #AskIE 세션과 8월의 Reddit AmA를 비롯해 지난 4월에 발표한 내용에서 가장 최근에 진행된 단계입니다.

UserVoice 투표 시스템을 사용하면 웹 개발자 커뮤니티에서 가장 많이 제안한 기능을 정확하게 파악할 수 있으므로 업무 우선 순위 결정에 도움이 될 것입니다. 또한 새로운 표준과 기능에 대한 웹 개발자의 의견을 더 쉽게 파악하기 위해 투표 수를 status.modern.ie에 직접 연결했습니다.

status.modern.ie의 기능에 대한 투표 수 - UserVoice에서 클릭 한 번으로 투표에 참여하세요!

Connect를 통해 특정 버그 보고서를 계속 보고해야 합니다. Internet Explorer 사용자 환경에 대한 의견이 있으시면 Windows 10 Technical Preview에 내장된 Windows 피드백 앱을 사용하세요.

최신 IE 웹 플랫폼 테스트 드라이브

향상된 피드백 채널 외에도 웹 개발자가 최신 IE 웹 플랫폼 사용에 익숙해지는 데 도움이 될 수 있도록 최선을 다하고 있습니다. 그 일환으로 지난 6월 IE11 정식 버전과 동시에 설치 가능한 IE 개발자 채널이 출시되었습니다. 보내주신 의견을 반영하여 IE 개발자 채널에서 검토했던 많은 기능들이 IE11의 8월 업데이트에 포함되었습니다.

최신 IE 웹 플랫폼의 새로운 기능을 계속 살펴보려면 Windows 참가자 프로그램에 등록하여 Windows 10 Technical Preview를 설치하세요. Windows 참가자 프로그램에 등록하시면 Windows와 Internet Explorer에 대한 Preview 빌드 업데이트를 정기적으로 수신하여 최신 기능들을 확인할 수 있습니다.

더 많은 기능 공개 예정

지금까지 HTTP/2, Chakra 성능 개선, 최상위 도메인 구문 분석 변경 및 Internet Explorer Platform Suggestion Box에 대해 간략하게 살펴봤습니다. 더욱 자세한 내용은 블로그 게시물에서 확인하시기 바랍니다. 더 자세한 내용을 알고 싶다면 10월 2일 오전 10시-12시(PST) #AskIE에서 @IEDevChat 주최로 진행되는 정기 트위터 채팅에 참여하세요.

- Internet Explorer 수석 프로그램 관리자, Charles Morris

Windows Phone 8.1 업데이트에는 모바일 웹과의 호환성을 크게 높여 주는 수백 가지의 Internet Explorer 11 향상 기능이 포함되어 있습니다.

여러분의 의견을 바탕으로 IE 사용자를 위한 웹 환경이 iOS 및 Android 장치에서 이용하는 웹 환경과 일치하도록 만들었습니다. 즉, 비표준 웹 플랫폼 기능도 추가할 수 있다는 의미입니다. 이것은 오늘날 표준화 수준이 낮은 모바일 웹의 실행을 위한 좀 더 현실적인 접근 방식이라 생각합니다.

500개 이상의 상위 모바일 웹 사이트를 테스트한 결과, 40% 이상의 모바일 웹 사이트에서 IE11 업데이트로 향상된 경험을 제공할 수 있음을 확인했습니다.

예를 들어, IE11에서 www.twitter.com을 방문하면 다음 화면이 표시되었습니다.

Windows Phone 8.1

그러나 업데이트된 IE11과 Firefox OS 및 iPhone에서의 화면은 다음과 같습니다.

Windows Phone 8.1 업데이트

Firefox OS

iOS7 지원 iPhone

이와 마찬가지로 IE11과 Firefox OS에서 www.baidu.com을 방문하면 다음 화면이 표시됩니다.

Windows Phone 8.1

Firefox OS

그러나 업데이트된 IE11과 iPhone에서의 화면은 다음과 같습니다.

Windows Phone 8.1 업데이트

iOS7 지원 iPhone

가장 인기 있는 웹 사이트 분석

대부분의 표준 기반 '데스크톱' 웹과 달리, 최신 모바일 웹 페이지는 iOS 및 iPhone에 맞게 설계 및 제작되었습니다. 이로 인해 다른 장치의 사용자들은 종종 성능이 저하된 환경을 경험하게 됩니다.

몇 주 전에 웹에 대한 우리의 비전과 우선순위에 대해 이야기했습니다. 우리는 "웹이 사용자, 개발자 및 기업 모두에게 최적의 사용 환경을 제공해야 한다."고 생각하여 모바일 웹이 고객을 위해 "최적의 사용 환경을 제공"하도록 만들기 위해 무엇이 필요한지 연구하기 시작했습니다.

세계에서 가장 인기 있는 모바일 웹 사이트를 조사하여 문제의 원인이 되는 일반적인 패턴을 찾기 시작했습니다. 잘못 작성된 브라우저 검색 코드를 사용하여 Windows Phone 사용자를 위한 데스크톱 사이트 경험에 영향을 주는 사이트가 종종 있습니다. 데스크톱 웹 사이트가 더 커지고 로드하는 시간이 더 느려지는 경향을 보이면서 사용자가 더 많은 데이터 요금을 부담해야 하는 상황이 발생하고 있으며, 이러한 사이트에는 결국 짧은 텍스트가 담겨 있어 콘텐츠를 읽기 위해 확대하고 이동하느라 많은 시간을 소요하게 되는 상황입니다. 또한 마우스를 사용해야 하므로 메뉴와 양식을 사용하는 것이 어려울 것으로 보입니다.

Windows Phone 8.1 RTM 릴리스에서는 데스크톱에서 PC 버전의 IE를 지원하는 이전처럼 빠른 표준 기반의 IE11 브라우저 엔진을 포함했습니다. 지난 몇 년 동안 우리는 기능 검색 및 순차적 기능 저하를 사용하는 모든 브라우저에 동일한 마크업을 제공하는 방법에 대해 알아보았습니다. 아직도 이 지침을 따르지 않아 중단된 데스크톱 사이트를 종종 볼 수 있지만 데스크톱에서의 상황이 개선되었습니다. 우리는 모바일 웹에서는 상황이 훨씬 다르다는 것을 확인했습니다. 많은 사이트에서 접두사가 없는 표준 버전을 지원하지 않는 기존의 공급업체별 접두사를 통해 기능을 사용하거나, 특정 장치에 대해서만 공급업체 접두사를 지원합니다. Safari 또는 Chrome에서만 작동하는 비표준 독점 API를 사용하는 사이트도 있습니다. 물론 IE에도 경쟁사의 브라우저를 위해 특별히 설계된 모바일 사이트에서 확연하게 드러난 버그나 누락된 기능이 있었습니다.

Windows Phone 8.1 업데이트에서 Internet Explorer 업데이트

우리는 호환성 데이터를 모두 수집한 후 IE에 필요한 변경 사항을 계획하기 시작했습니다. 이제 몇 가지 가장 중요한 변경 사항과 변경한 이유에 대해 알아보겠습니다. 모바일 웹 사이트에 영향을 미치는 문제는 다음과 같이 크게 다섯 가지의 주요 범주로 나뉩니다.

• IE를 모바일 브라우저가 아닌 데스크톱 환경으로 인식하는 브라우저 검색 오류
• 표준으로 대체된 이전 Webkit 접두사 기능만 사용
• 표준이 없는 고유 Webkit 접두사 기능 사용
• 순차적 대안 없이 IE에서 지원하지 않는 기능 사용
• IE에서 구현 차이 및 상호 운용성 버그 발생

사용자 에이전트 문자열 변경

지금까지 확인된 가장 중요한 문제 중 하나는 Windows Phone의 IE가 모바일 브라우저라는 것을 감지하지 못해 데스크톱 콘텐츠를 제공하는 사이트와 관련된 문제입니다. 이로 인해 사이트의 텍스트가 확대하고 이동해야 읽을 수 있도록 작게 표시되는 경우가 종종 발생합니다. 또한 콘텐츠가 모바일에 최적화되어 있지 않기 때문에 종종 휴대폰의 데이터 연결 한도 이상으로 더 많은 데이터가 전송되기도 합니다. 이미지는 커지고 더 많은 광고가 다운로드되어 표시됩니다.

사이트가 모바일 환경을 제공하는지 여부를 감지하는 다양한 많은 방법이 있습니다. 실제 사이트에서 확인한 한 가지 검사 방법을 여기서 소개합니다.

window.mobileCheck = function() {

var check = false;

(function(a){if(/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i.test(a.substr(0,4)))check = true})(navigator.userAgent||navigator.vendor||window.opera);

return check;
}

우리는 Windows Phone의 IE에서 최적의 모바일 콘텐츠를 정확하게 제공하는 사이트의 수를 증가시키기 위해 사용자 에이전트 문자열을 업데이트했습니다. 이로 인해 대부분의 웹 개발자가 모든 브라우저에서 처리해야 하는 적절하지 않은 패턴이 계속되었습니다. 예를 들면, 2006년 초 WebKit 버그에서 "Safari lies. Reports itself as Mozilla, Gecko and KHTML too."(Safari의 존재. Mozilla, Gecko 및 KHTML로도 보고)라는 제목의 흥미로운 논의가 진행되었습니다. 데스크톱에 IE11을 탑재할 때 데스크톱 사이트와의 호환성이 대폭 개선되었기 때문에 문자열에 "like Gecko"라는 토큰을 추가했습니다. Chrome 및 Opera도 웹 콘텐츠와의 호환성을 위해 like Gecko 및 Safari를 표방하고 있습니다.

IE11 및 Firefox OS를 통해 www.hawaiianairlines.com을 방문하면 다음과 같은 데스크톱 환경을 확인할 수 있습니다.

Windows Phone 8.1

Firefox OS

그러나 업데이트된 IE11과 iPhone에서의 화면은 다음과 같습니다.

Windows Phone 8.1 업데이트

iOS7 지원 iPhone

또한 IE11 및 Firefox OS를 통해 www.nytimes.com을 방문하면 다음과 같은 데스크톱 환경을 확인할 수 있습니다.

Windows Phone 8.1

Firefox OS

그러나 업데이트된 IE11과 iPhone에서의 화면은 다음과 같습니다.

Windows Phone 8.1 업데이트

iOS7 지원 iPhone

일반적으로 다른 장치의 기능에 적응할 수 있는 응답성이 뛰어난 사이트를 개발하는 것이 좋습니다. 모바일 전용 환경을 구축하기로 선택한 경우, 모바일에 최적화된 콘텐츠를 제공하는 시기를 결정하기 위해 사용자 에이전트 문자열에서 하위 문자열 "mobile"을 찾을 것을 권장합니다.

function isMobile() {
    return navigator.userAgent.toLowerCase().indexOf("mobile")>=0;
}

기존의 Webkit 접두사 기능을 IE 구현에 매핑

사용자 에이전트 문자열을 변경하여 IE가 다른 휴대폰 브라우저와 동일한 콘텐츠를 수신하게 되면, 모바일 환경에 오류를 일으키는 문제를 분석할 수 있습니다. 우리가 파악한 첫 번째 중요한 문제는 CSS 그라데이션, 플렉스박스, 전환 및 애니메이션을 위해 Webkit 접두사 콘텐츠만을 전달하는 모바일 사이트가 많다는 것입니다. IE11의 웹 표준 기반 엔진은 이미 브라우저 간 마크업이 있는 사이트를 지원하는 기능이 있습니다. Mozilla에서 확인된 바와 같이, WebKitCSSMatrix는 일반적으로 모바일 장치에 사용되고 있으며, IE는 MSCSSMatrix를 지원합니다. 또한 많은 사이트에서 최근에 부상하고 있는 표준인 screen.orientation 대신 window.orientation을 사용합니다. 여기서 확인된 두 번째 문제는 코드에 기존 구문을 사용하는 사이트가 많다는 것입니다. 예를 들면, 업데이트된 표준 기반 방식 대신 기존의 그라데이션 구문을 사용하는 문제입니다.

Windows Phone 8.1 업데이트에서는 이미 IE11의 일부인 표준 기반 지원에 많이 이용되는 Webkit 접두사 API의 매핑을 추가했습니다. 이를 통해 WebKit 코드만 전달하는 사이트가 페이지가 로드되면서 표준 기반 코드로 변환됩니다. 모든 Webkit 접두사 API를 지원할 계획은 없지만, 모바일 사이트에서 일반적으로 사용되어 없으면 앱이 작동되지 않는 Webkit 접두사 API에 대한 매핑을 추가했습니다.

IE11에서 www.macys.com을 방문하면 다음 화면이 표시됩니다.

Windows Phone 8.1

그러나 업데이트된 IE11과 iPhone에서 그라데이션이 정확하게 그려진 화면은 다음과 같습니다.

Windows Phone 8.1 업데이트

iOS7 지원 iPhone

IE11에서 www.answers.com을 방문하면 다음 화면이 표시됩니다.

Windows Phone 8.1

그러나 업데이트된 IE11과 iPhone에서 사이트가 정확하게 그려진 화면은 다음과 같습니다.

Windows Phone 8.1 업데이트

iOS7 지원 iPhone

비표준 고유 기능에 대한 지원 추가

우리는 Apple에 의해 대중화되어 iPhone에서 널리 사용되는 일부 비표준 기능을 확인했습니다. 해당 기능은 현재 표준 트랙에는 없지만, 이를 지원하지 않는 브라우저는 모바일 웹에서 인기 사이트에 대해 뛰어난 환경을 제공할 수 없습니다. 한 예로 페이지에서 기본 응용 프로그램에 맞게 요소의 스타일을 수정할 수 있는 -webkit-appearance를 들 수 있습니다. Mozilla는 "이는 비표준일 뿐만 아니라 브라우저마다 동작이 달라진다"고 지적합니다. 하지만 이러한 비표준 고유 기능에 대한 일정 수준의 지원이 없는 경우 웹 사이트를 이용하기가 훨씬 어렵습니다.

IE에서 지원되는 새로운 기능

데스크톱 사이트에서 자주 사용하지 않아 IE11에서 지원하지 않았던 몇 가지 표준 기반의 기능을 모바일 웹에서는 일반적으로 사용할 수 있습니다. IE11에서 더 많은 모바일 콘텐츠를 수신하게 되었으므로 해당 기능을 추가해야 합니다. 예를 들어, window.locationbar는 HTML5에 정의되어 있지만 데스크톱 사이트에서는 거의 사용되지 않습니다. 우리는 활성화된 모바일 사이트를 기반으로 몇 가지 새로운 기능을 우선적으로 구현했습니다.

모바일 사이트와의 호환성에 크게 영향을 미치는 API 관련 문제 중 하나는 터치 지원입니다. IE10에서는 현재 W3C의 권고 후보안인 포인터 이벤트에 대한 지원을 추가했으며, IE11에서는 사양에 변경 사항을 통합하기 위해 구현을 업데이트했습니다. 포인터 이벤트를 사용하면 마우스, 터치, 펜 또는 기타 포인터 입력 중 하나를 사용하려는 사이트에 성능 및 기능상 많은 이점을 제공하므로, 모든 장치에서 사용자를 지원하는 사이트에 가장 적합한 API로 이를 계속 사용할 것을 권장합니다.

모바일 웹에서 대부분의 사이트는 오래된 터치 이벤트 모델을 사용하도록 코딩되어 있어 사용자는 해당 사이트가 최적의 사용 환경을 제공할 것으로 기대합니다. IE11 업데이트에서는 해당 사이트가 정확하게 작동할 수 있도록 터치 이벤트에 대한 지원을 추가했습니다. 또한 조사 결과 데스크톱 웹에서 Windows 태블릿 및 투인원 장치와 같은 마우스를 지원하는 장치에 터치 이벤트를 활성화하는 것이 더 많은 문제의 원인이 되는 것으로 나타났습니다. 예를 들어, 터치 이벤트가 활성화되었을 때 약 10% 가량의 인기 있는 사이트에서 마우스 및 트랙패드 지원이 중단되는 것으로 확인되었습니다. 많은 사이트에서 터치 이벤트와 마우스 이벤트를 받을 것으로 기대하지 않고 하나만 지원합니다. 우리는 W3C 터치 이벤트 커뮤니티 그룹에서 다른 브라우저 공급업체와 협력하여 대규모로 이러한 웹 관련 문제를 해결하기 위해 노력하고 있습니다. 이 게시물에 포인터 이벤트와 터치 이벤트에 대한 자세한 내용이 나와 있습니다.

가장 영향력 있는 상호 운용성 문제 해결

우리는 Internet Explorer에서 제대로 작동하지 않는 사이트의 마크업에 대한 조사를 계속하면서 몇 가지 독특한 상호 운용성 문제를 발견했습니다. 예를 들면, <a> 링크 내부의 <button>과 <label> 요소는 어디에도 그 동작이 명확하게 문서화되지 않았지만 다른 브라우저에서 독립적으로 클릭할 수 있습니다. 또 다른 예로, <meta> 새로고침 지원이 있습니다. HTML5 사양에서는 다른 URL로 리디렉션하기 위해 "URL=" 문자열이 요소의 일부 콘텐츠가 될 것으로 기대합니다. 다른 브라우저에는 이것이 필요하지 않으며, 이 방법이 잘못 사용되면 IE의 페이지는 끊임없이 새로고침되어 표시됩니다.

마지막으로, 특히 인기 있는 모바일 사이트에 영향을 주는 Trident 엔진에서 몇 가지 버그를 발견했으며, 이번 업데이트에 해당 문제에 대한 수정을 포함했습니다. 예를 들어, 인기 있는 모바일 사이트에 영향을 주는 location.hash 와 관련된 몇 가지 탐색 문제와 일부 CSS 레이아웃 문제를 수정했습니다.

다음 단계

특히 변경 사항의 많은 부분이 해당 사이트에 게시된 기존의 공급업체 접두사 콘텐츠를 사용하는 것을 목표로 하고 있습니다. 모든 Webkit 공급업체 접두사 API를 지원하는 것이 목표는 아니지만, 해당 사이트의 표준 기반 마크업 채택을 장려하기 위한 우리의 지원 노력은 계속될 것이며, 추가된 지원은 모두에게 최적의 사용 환경을 제공해야 하는 오늘날의 모바일 웹에 반드시 필요할 것입니다. 또한 비표준 코드를 사용하는 사이트에도 도움이 될 수 있습니다. 즉, 중단된 사이트를 기록하기 위해 Mozilla와 webcompat.com에서 협력하고 있습니다. 중단된 사이트는 Firefox 및 IE를 비롯해 다양한 브라우저에서 문제를 일으키므로 문제가 있는 사이트를 쉽게 보고할 수 있습니다.

웹 개발자인 경우 해당 사이트를 스캐너 도구를 통해 https://modern.ie에서 실행하십시오. 이 도구는 공급업체 접두사 문제를 포함하여 일반적인 코딩 문제를 파악하여 코드를 수정하는 데 도움이 됩니다.

Windows Phone 8.1 업데이트에서 IE에 변경된 기능이 모두 함께 실행되는 경우, 가장 인기 있는 모바일 웹 사이트와의 호환성을 극적으로 향상시킬 수 있습니다. 업데이트는 개발자용 Windows Phone 8.1 Preview에서 이미 제공하고 있으며, 향후 몇 달 동안 Windows Phone 8.1을 실행하는 장치를 사용하는 소비자에게 선보일 계획입니다. 또한 MSDN에 IE 개발자 가이드에 대한 모든 변경 사항을 포괄적인 목록으로 게시했습니다.

궁금한 사항이 있는 경우 Twitter(@IEDevChat)를 통해 의견을 주시기 바랍니다. 다음 번 트윗 채팅은 #AskIE에서 오늘(7월 31일) 오전 10시-12시(PDT)에 있습니다. #AskIE에 질문을 남겨 주시기 바랍니다.

Internet Explorer 프로그램 관리자,
Adrian Bateman

Internet Explorer 프로그램 관리자,
Frank Olivier

Windows 블로그에서 언급했듯이, 앞으로도 계속 기존의 월별 업데이트 프로세스를 통해 보안 업데이트 외에도 향상된 기능을 더 자주 제공할 것입니다.

Internet Explorer 11의 새로운 기능

이 업데이트에는 고객 및 개발자 의견에 따른 4가지 향상 기능이 포함되어 있습니다. 이 향상 기능 중 일부는 Internet Explorer 개발자 채널에서 미리 살펴보았으며 여러분의 의견 덕분에 이제 소개할 수 있게 되었습니다.

F12 개발자 도구의 향상된 기능

이 업데이트는 F12 개발자 도구에서 현저하게 향상된 기능을 제공합니다. 즉, 사용자 인터페이스, 콘솔, DOM Explorer, 디버거, 에뮬레이션 도구, UI 응답성, 메모리 프로파일링 도구 등 이 모두에 새로운 기능과 버그 수정이 있습니다.

자세한 내용은 Microsoft Knowledge Base Article 2990946을 참조하십시오. 또한 향후 IE 블로그 글을 통해서도 F12의 향상된 기능에 대한 자세히 올릴 예정입니다.

업데이트된 F12 UI 응답성 도구

WebGL 렌더러의 향상된 기능

또한 WebGL 렌더러는 ANGLE_instanced_arrays, OES_element_index_uint 및 WEBGL_debug_renderer_info 확장자, failIfMajorPerformanceCaveat 컨텍스트 작성 특성, 16비트 텍스처, GLSL 적합성, 라인 루프, 삼각형 팬 기본 형식 등의 지원 기능이 업데이트되었습니다.

이뿐만 아니라 드라이버가 최신 상태인 경우 이제 더 많은 Windows 7 시스템이 하드웨어 모드에서 WebGL을 렌더링할 수 있습니다.

이 버전에서는 Khronos WebGL 적합성 테스트 1.0.3 점수가 89.9%에서 96.8%로 올랐습니다. 자세한 내용은 Microsoft 기술 자료 문서 2991001을 참조하십시오. WebGL에 대해서는 나중에 다른 블로그 글을 통해 자세히 살펴보겠습니다.

WebDriver 지원

또한 8월 업데이트에서는 웹 개발자들이 테스트를 작성하여 해당 사이트를 테스트할 웹 브라우저를 자동화할 수 있는 새로운 WebDriver 표준에 대한 IE11 지원의 토대도 마련됩니다. 이것은 복잡한 사용자 시나리오를 개발하고 웹 사이트와 브라우저에서 자동화된 방식으로 실행하기 위한 프로그래밍이 가능한 원격 제어입니다. 8월 업데이트에는 기본 WebDriver 지원을 제공하는 데 필요한 브라우저 엔진 변경 사항이 포함되어 있습니다. WebDriver 스크립트를 실행하려면 별도의 패키지를 설치해야 하는데, 조만간 소개할 예정입니다.

Internet Explorer에서 오래된 ActiveX 컨트롤 차단

Internet Explorer에서 오래된 ActiveX 컨트롤을 차단하면 ActiveX 컨트롤을 더 안전한 최신의 상태로 유지하는 데 도움이 됩니다. 자세한 내용은 블로그 게시물과 Microsoft 기술 자료 문서 2991000을 참조하십시오.

Internet Explorer 보안 업데이트

8월 업데이트에는 다음 보안 업데이트도 포함되어 있습니다.

• Microsoft 보안 공지 MS14-051 - 이 중요 보안 업데이트는 공개적으로 알려진 취약점 1건과 Internet Explorer에서 비공개적으로 보고된 취약점 25건을 해결합니다. 자세한 내용은 전체 공지를 참조하십시오.
• Flash Player에 대한 보안 업데이트(2982794) - 12월 10일부터는 지원 대상인 Windows 8, Windows 8.1과 Windows Server 2012 및 Windows Server 2012 R2 에디션의 Internet Explorer 10 및 11에 포함된 Adobe Flash Player에 대한 보안 업데이트도 가능합니다. 이 취약성에 대한 세부 내용은 Adobe 보안 공지 APSB14-18에 기록되어 있습니다. 이 업데이트는 Internet Explorer 10 및 Internet Explorer 11에 포함된, 영향을 받는 Adobe Flash 바이너리를 업데이트하여 Adobe Flash Player의 취약점을 해결합니다. 자세한 내용은 공지를 참조하십시오.

최신 상태 유지

대부분의 사용자는 자동 업데이트를 사용하고 있으므로 별도의 작업 없이도 이러한 업데이트가 자동으로 다운로드되어 설치됩니다. 자동 업데이트를 설정하지 않은 사용자는 업데이트가 있는지 확인한 후 수동으로 설치해야 합니다.

@IEDevChat 또는 Connect를 통해 의견을 보내 주십시오.

- Internet Explorer 프로그램 관리자, Sharon Meramore

- Internet Explorer 수석 프로그램 관리자, Charles Morris

이번 버전에서 선보이는 웹 개발자를 위한 새로운 기능에 대해서는 앞으로 나올 별도의 게시물을 참조하시기 바랍니다.

빠른 사이트 액세스

누구나 더 빠른 브라우저를 이용하고 싶어합니다. 이 문제를 해결하는 것은 어렵지만 흥미로운 작업 과정이며 MS 팀은 이 문제를 두 가지 부분으로 나눴습니다. 첫째는 브라우저에 이동하고자 하는 사이트를 입력하는 부분이고 둘째는 브라우저가 최대한 빨리 그 사이트를 열어주는 과정입니다. 많은 사람들이 주로 두 번째 부분에 관심을 기울이고 있으며 SunSpider, Acid3, Octane과 같은 브라우저 성능 측정 벤치마크가 이러한 논의를 주도하고 있습니다. 벤치마크에서 성과를 거둔 것은 사실이지만 이번에 주된 관심사가 된 것은 첫 번째 부분인 브라우저에 이동하고자 하는 사이트를 입력하는 과정을 획기적으로 개선시키는 일이었습니다. 그리고 그 방법은 다음과 같습니다.

자주 방문하는 사이트 + URL 예측

주소 표시줄을 탭하면 사용자가 지금 보고 있는 사이트가 아닌 다른 사이트로 이동하려는 것임을 IE가 파악합니다. 누구나 자주 방문하는 사이트가 몇 개 있는데 이제는 주소 표시줄을 간단하게 탭하면 그 사이트들을 바로 볼 수 있습니다. 브라우저를 사용하다 보면 이런 사이트가 업데이트되어 휴대폰에서 가장 많이 방문하는 사이트로 반영됩니다. 저의 브라우저 스크린샷입니다.

주소 표시줄에 주소를 입력하기 시작하면 이제 이동하려는 사이트를 예측합니다(아래 강조 표시된 부분). URL 전체를 입력하지 않고도 Enter 키만 탭하면 더욱 빠르게 해당 사이트로 이동할 수 있습니다. 한 번 사용해 보면 이 기능이 없는 브라우저를 상상하기 힘들어집니다. 그 결과 사이트 이동이 더욱 간편해지기 때문에 브라우저가 빨라진 느낌을 받을 수 있습니다.

이용하기 쉬운 무제한의 탭 + 어디에서나 하나의 IE 사용 가능

웹 검색이 점점 모바일 장치로 이동하면서 모바일 장치에서 더 복잡한 작업을 해내야 합니다. 한 가지 예는 다중 탭 검색입니다. 이전에는 탭이 6개까지만 허용되었고 "..." 메뉴에서 탭에 액세스하려면 약간의 스피드 범프가 있었습니다(설정을 사용하여 주소 표시줄 단추를 변경하는 경우 제외).

그래서 이러한 제한을 없애버리기로 결정했습니다. 정말로 탭을 원하는 만큼 열 수 있고 이제 따로 설정을 하지 않아도 주소 표시줄 옆에 있는 버튼으로 탭에 액세스할 수 있습니다. 탭을 액세스하기 쉽게 만든 변화는 환영을 받았지만 새로고침 액세스를 간편하게 해달라는 요청이 계속되었습니다. 그래서 두 가지 요청을 다 들어드리기로 했습니다. 탭 단추와 새로고침 단추 모두 즉시 액세스가 가능해졌음을 확인할 수 있습니다.

눈치가 빠른 사용자라면 위 스크린샷에서 "other" 피벗을 발견했을 것입니다. 저희는 Internet Explorer 11에서 휴대폰, 태블릿, PC 간에 데이터 검색을 동기화할 수 있음을 발표하게 되어 기쁩니다. 동기화 대상에는 즐겨찾기, 열어본 페이지 기록, 암호 및 열었던 탭이 포함됩니다. 장치를 바꿔서 작업을 하게 되더라도 이전에 진행하던 작업을 계속 이어서 할 수 있습니다. 이제는 더 이상 전자 메일로 직접 링크를 보내지 않아도 됩니다!

예정된 변화가 또 있습니다. 데이터 사용량이 염려된다면 도움을 드리겠습니다. DataSense 앱에 데이터 한도를 입력하면 데이터 추가 요금이 나오지 않도록 이 데이터를 적시에 동기화합니다.

라이브 고정 사이트

시작 화면에 자주 방문하는 사이트를 고정해놓고 좋아하는 블로그로 바로 갈 수 있는 기능은 아주 편리한 기능이지만 지금까지 Windows Phone에서 사이트를 고정하는 기능은 상당히 어설픈 상태였습니다. 움직이지 않는 스크린샷만 보더라도 즐겨 찾는 앱의 멋지고 동적인 라이브 타일에 비해 떨어집니다. 이 모든 것을 바꿨습니다. Windows 8.1을 사용하고 있다면 이제 고정된 사이트가 굉장히 친숙하게 느껴질 것입니다.

이제 고정된 사이트에는 화려한 사이트 아이콘이 표시되고 다른 라이브 타일과 마찬가지로 즐겨 찾는 블로그의 최근 헤드라인과 이미지가 백그라운드에서 업데이트 됩니다. 웹 사이트를 운영하고 있다면 여기에서 이 기능을 웹 사이트에 활용할 수 있는 방법을 볼 수 있습니다. 힌트를 드리자면 Windows 8.1에서 마크업하는 것과 똑같습니다. 혹시 자주 방문하는 사이트에서 이 라이브 고정 사이트를 지원하지 않는다면 웹 사이트 운영자에게 이 기능을 활용하는 방법을 알려주면서 다른 모든 인기있는 사이트에서는 이 기능을 사용하고 있다고 귀띔해주세요. 개발자들을 위한 세부 정보는 추후 업데이트 하겠지만 그 전에 라이브 고정 사이트로만 구성된 이 시작 화면을 참고해 주십시오.

빠르고 유연한 브라우징

이제 사이트에 더 빨리 접속할 수 있게 되었다는 사실을 알게 되셨습니다. 좋아하는 콘텐츠를 빠르게 접속할 수 있는 만큼 그 콘텐츠를 이용할 때에도 아주 빠른 속도를 제공하고 싶었습니다. 그래서 사이트로 이동한 이후에도 빠른 브라우징 환경을 만들기 위해 인라인 동영상 재생, 읽기용 보기, 암호 기억, 살짝 밀어 앞뒤로 이동, 다운로드한 파일 저장하기와 같은 기능도 개선했습니다.

인라인 동영상 재생

YouTube 동영상을 보다가 "인터넷을 이용하는 다른 사람들은 이 동영상에 대해 어떻게 생각하고 있을까" 궁금해 한 적이 많을 것입니다. 이제 동영상을 보는 동시에 브라우저에서 동영상 아래에 나오는 수준 높은 의견을 볼 수 있습니다. 게다가 잠금 화면에서도 동영상이 계속 재생될 수 있게 했습니다. 개발자들이 이 훌륭한 인라인 동영상 재생 기능을 지원할 수 있도록 조만간 더 자세한 정보를 게시할 예정입니다.

읽기용 보기

혹시 이동 중에 연예인 가십 기사나 잡지 기사를 즐겨 보십니까? 태블릿 또는 PC에서 보는 것과 똑같이 주소 표시줄의 읽기용 보기 아이콘을 탭하면 아주 깔끔한 읽기 환경으로 전환할 수 있습니다. 방해 요소는 없애고 기사의 모든 페이지를 이을 수 있습니다. 왼쪽 아래 일반 사이트에서 보이는 기사가 오른쪽 아래 읽기용 보기에서는 어떻게 나타나는지 확인해 보십시오.

암호 기억

이 기능은 로그인을 훨씬 간편하게 만들어 줄 것입니다. 더 말할 것도 없습니다.
참고: 이제 암호를 IE에 동기화하여 휴대폰, 태블릿, PC에서 모두 사용할 수 있습니다.

살짝 밀어 앞뒤로 이동

PC나 태블릿과 비슷하다고요? 트렌드를 눈치 채셨나요? 이제 살짝 밀어 앞뒤로 이동할 수 있습니다. 그렇습니다. 오랫동안 기다렸던 앞으로 이동이 Windows Phone용 IE로 돌아왔습니다! 아래는 기사를 읽을 때 뒤로 가기의 스크린샷입니다.

다운로드한 파일 저장

이제 웹에서 다운로드한 파일을 저장할 수 있습니다. 만세!

안전 및 개인 정보 보호

Internet Explorer는 SmartScreen 필터로 피싱 방지 기능을 도입한 최초의 모바일 브라우저로서 늘어나는 개인 정보 보호에 대한 문제를 해결하기 위해 DNT(DoNotTrack) 신호도 추가했습니다. 브라우저를 사용하는 동안 여러분의 개인 정보를 안전하게 보호해주는 몇 가지 기능과 함께 다시 제공합니다.

InPrivate

유니콘에 매력을 느끼는 개인적인 취향을 친구들에게 숨기고 싶지는 않나요? 이제 InPrivate 탭을 이용하십시오. InPrivate 탭을 열면 탭을 닫을 때 그 탭과 연결된 모든 데이터가 삭제됩니다. 탭 화면에서 메뉴를 열고 “InPrivate 탭 열기"를 선택하면 됩니다.

DataSense High Savings Mode(데이터 절약 모드)

Windows Phone 8용 IE에 DataSense를 적용하여 브라우징 환경의 변화 없이 같은 양의 데이터로 더 많은 사이트를 이용할 수 있습니다. 이제 High Savings Mode(데이터 절약 모드)를 도입하여 웹 사이트의 가장 중요한 부분만 다운로드하고 이미지를 대폭 압축할 수 있습니다. 아래 스크린샷에서 High Savings Mode(데이터 절약 모드) 사용 시(왼쪽)와 미사용 시(오른쪽)의 화면을 비교해 보십시오.

사이트의 모습이 확연히 달라 보입니다. 낮은 데이터 요금제를 사용하고 있거나 해당 월의 데이터 요금제가 떨어져 갈 때 굉장히 유용한 기능입니다. Internet Explorer 설정에서는 언제든지 High Savings Mode(데이터 절약 모드)를 항상 사용, 항상 사용하지 않음, 자동으로 설정 중에서 선택할 수 있습니다. 자동으로 설정 기능은은 DataSense 앱에서 구성한 데이터 요금제의 데이터 한도에 가까워 지면 자동으로 High Savings Mode(데이터 절약 모드)로 전환되는 기능입니다. High Savings Mode(데이터 절약 모드)에서 해당 사이트의 풀 버전을 보려면 주소 표시줄의 아이콘을 탭하면 됩니다.

접근성

Microsoft는 모든 사용자의 요구를 파악하여 제품 디자인에 폭넓은 접근 방법을 사용합니다. IE11이 하이 콘트라스트 모드, 내레이터, 모든 웹 페이지의 확대를 가능하게 하는 오버라이드 스위치를 지원한다는 사실이 만족스럽습니다. 시스템 전체의 접근성에 대한 자세한 사항은 추후 게시될 Windows Phone 블로그 게시물을 참조하시기 바랍니다.

결론

휴! 많은 이야기를 했네요! 브라우저에 이 유용한 업데이트를 꼭 활용해보시기 바라며 다른 때와 마찬가지로 생각과 의견을 들려 주시기 바랍니다. 아래에 의견을 남기시거나 @IE으로 트윗하실 수 있습니다.

- Internet Explorer 프로그램 관리자, Amin Lakhani

이 게시물에 도움을 주신 Dhruv Chadha, Derek Liddell, Oren Freiberg에게 감사의 뜻을 전합니다.

웹과 연결되는 시작 화면

Internet Explorer 사용자는 자주 방문하는 웹 사이트를 Windows 및 Windows Phone 시작 화면에 고정하여 즐겨 찾는 앱 바로 옆에 둘 수 있습니다. IE에서 웹 사이트를 고정하면 사용자가 매번 웹 사이트를 탐색할 필요 없이 시작 화면에서 사이트에 바로 액세스할 수 있습니다.

사용자가 사이트를 고정하면 자신이 사이트를 자주 방문하고 그 사이트의 새로운 소식에 관심이 있다는 것을 나타냅니다. 그렇기 때문에 Internet Explorer에서 제공하는 웹 사이트용 라이브 타일을 사용하면 사용자가 브라우저를 열지 않아도 웹 사이트의 정보를 얻을 수 있습니다.

라이브 타일을 사용하면 뉴스 속보, 새로운 메시지 알림 또는 새로운 블로그 게시물의 제목과 같은 새로운 콘텐츠를 사용자의 시작 화면에 표시하여 더욱 빠르게 정보를 제공할 수 있습니다. 또한 웹 사이트에 맞는 여러 가지 타일 크기를 지원하므로, 사용자가 와이드 타일 또는 큰 타일로 사이트를 표시하여 눈에 잘 띄게 할 수 있습니다.

왼쪽 위부터 아래로 각 열 이동: IE 앱 타일, youtube.com, techmeme.com, theverge.com, anandtech.com, mathrubhumi.com, twitter.com, reuters.com, t.msn.com, aol.com, economictimes.indiatimes.com, 고정된 사이트용 IE 테스트 드라이브, wired.co.uk, lapresse.ca, cnet.com, contrejour.ie, dhakatimes.com.bd, outlook.com, wellsfargo.com, geekwire.com, nymag.com, gawker.com, indiatimes.com, facebook.com, vyclone.com, polygon.com, wpcentral.com, theage.com.au.

왼쪽 위부터 아래로 각 열 이동: IE 앱 타일, techmeme.com, contrejour.ie, wellsgargo.com, gawker.com, t.msn.com, youtube.com, vyclone.com, 고정된 사이트용 IE 테스트 드라이브, wpcentral.com

웹 사이트에 라이브 타일 추가

웹 사이트용 라이브 타일은 정기 알림을 통해 제공되며, 여기에서 플랫폼이 사전 정의된 폴링 간격으로 서버에서 호스팅된 폴링 URI로부터 텍스트와 이미지를 가져와 웹 사이트 타일에 콘텐츠를 표시합니다. 라이브 타일을 사이트에 추가하는 방법은 3가지로, 웹 페이지에서 메타 태그를 통한 방법, 매니페스트 파일을 만드는 방법 또는 JavaScript API를 통한 방법이 있습니다. 다음은 메타 태그를 사용하여 Windows 8.1용 타일을 설정한 사이트의 예입니다.

<meta name="application-name" content=" CenturyCutCook" /> <meta name="msapplication-TileColor" content=" #009900" />
 <!-- Logos for all four tile sizes --> <meta name="msapplication-square70x70logo" content="smalltile.png" /> <meta name="msapplication-square150x150logo" content="mediumtile.png" /> <meta name="msapplication-wide310x150logo" content="widetile.png" /> <meta name="msapplication-square310x310logo" content="largetile.png" />
 <!-- Notification URL --> <meta name="msapplication-notification" content="frequency=30; polling-uri=1.xml; polling-uri2=2.xml; polling-uri3=3.xml; polling-uri4=4.xml; polling-uri5=5.xml" />

이 예에서 정의된 폴링 URI에는 표시될 알림의 내용이 포함되어 있으며, URI는 30분마다 폴링됩니다. 따라서 사용자는 이 사이트의 업데이트를 30분 간격으로 최대 5개까지 볼 수 있기 때문에 사용자에게 웹 사이트의 정보를 수시로 제공할 수 있습니다.

폴링 URI에는 사전 정의된 템플릿을 준수하는 XML 마크업이 포함됩니다. 웹 사이트용과 Windows 애플리케이션용 템플릿은 서로 같으며, 템플릿에 따라 타일의 스타일이 달라집니다. 템플릿은 텍스트 기반이나 이미지 기반일 수도 있고 둘 다일 수도 있습니다. 다음은 중간, 와이드 및 큰 타일 크기용 바인딩이 있는 폴링 URI로 구성된 예입니다(큰 타일 크기는 Windows에서 지원되지만 Windows Phone에서는 지원되지 않음).

<tile>    <visual lang="en-US" version="2">       <binding template=" TileSquare310x310ImageAndTextOverlay02" branding="name">          <image id="1" src="cheddar_and_ham.png" />          <text id="1">Cheddar and Ham Skewers </text>          <text id="2">This recipe for Cheddar and Ham Skewers made with Sargento Tastings is perfect whether you’re looking for an appetizer to entertain with, or you’re looking for a special crave-worthy afternoon snack </text>       </binding>       <binding template=" TileWide310x150ImageAndText01" branding="logo">          <image id="1" src="cheddar_and_ham.png" />          <text id="1">Cheddar and Ham Skewers</text>       </binding>       <binding template="TileSquare150x150Image" branding="name">          <image id="1" src="cheddar_and_ham.png" />       </binding>    </visual> </tile>

이 바인딩은 다음과 같은 타일로 표시되며, 시작 화면에서 지원되는 4가지 크기에 모두 사용할 수 있습니다.

큰 타일, TileSquare310x310ImageAndTextOverlay02 템플릿 사용	와이드 타일, TileWide310x150ImageAndText01 템플릿 사용
중간 크기 타일, TileSquare150x150Image 템플릿 사용	작은 타일(알림 없음)

Microsoft의 코드 샘플을 사용하여 라이브 타일 구현에 대해 자세히 알아볼 수 있으며, 사이트에서 RSS 피드 알림을 설정하려면 Microsoft의 buildmypinnedsite 마법사를 사용하여 웹 사이트용 타일을 손쉽게 구현할 수 있습니다.

요약

Windows 8.1과 IE11을 사용하면 사용자가 브라우저 탭을 열지 않아도 사용자에게 사이트의 정보를 계속 제공할 수 있습니다. 라이브 타일을 지원하면 사용자들이 시작 화면에서 콘텐츠를 우연히 발견하게 하여 사이트를 더욱 자주 방문하도록 유도할 수 있습니다. 가장 좋은 점은 라이브 타일을 사이트에 손쉽게 추가할 수 있다는 점입니다!

- Internet Explorer 프로그램 관리자, Tanvi Surti

- Internet Explorer 프로그램 관리자, Derek Liddell

불과 몇 주 전에 IE 팀과 웹 개발 커뮤니티 간에 더욱 개방된 대화의 창을 마련하는 것에 대해 이야기했습니다. 오늘 Internet Explorer 개발자 채널을 선보일 수 있게 되어 기쁩니다. Internet Explorer 개발자 채널은 웹 개발자와 얼리 어답터 여러분이 현재 저희가 작업 중인 웹 플랫폼의 기능을 엿볼 수 있도록 설계된 모든 기능을 갖춘 브라우저입니다. 개발자 채널은 Internet Explorer 11을 사용 중인 Windows 8.1 및 Windows 7 SP1 고객의 경우 지금 바로 다운로드 가능합니다.

IE 개발자 채널은 IE11과 함께 사용할 수도 있고 IE11이 없어도 사용할 수 있으며 IE11에서 자주 사용하는 모든 브라우저 기능과 저희가 현재 준비중인 최신 플랫폼 기능도 모두 갖추고 있습니다. 이러한 기능을 시범적으로 사용해보시면서 @IEDevChat 또는 Connect를 통해 피드백을 주시기 바랍니다.

F12 개발자 도구에서 향상된 더 많은 기능

지난 4월, Windows 8.1 업데이트와 함께 IE11의 F12 개발자 도구에서 사용할 수 있는 몇 가지 새로운 기능을 소개했습니다. 그리고 이는 DOM Explorer에서 정확한 데이터를, 메모리 및 성능 도구에서 실행 가능한 데이터를 제공하는 것에 중점을 두고 있었습니다. IE 개발자 채널에는 다음과 같은 더 많은 F12 개발자 도구 개선 사항을 포함하고 있습니다.

• 이벤트 기반의 버그에 더 빨리 접근할 수 있는 이벤트 중단점을 통해 향상된 디버깅 환경
• 다차원 타임라인 필터를 통해 노이즈를 감소시키는 메모리 및 UI 응답성 프로파일러 전반에 걸친 더 풍부해진 분석 기능과 더불어 performance.measure() 기반 계측 및 도미네이터 폴딩의 시작으로 보고되고 있는 의미있는 데이터의 증가
• 더 많은 키보드 단축키(ctrl+[ 및 ctrl + ]) 및 새로운 헤더 알림을 제공하여 프로파일링 도구가 실행되고 있는지와 페이지에 있는 오류의 수를 신속하게 파악할 수 있는 개선된 탐색 환경

향상된 기능 전체는 MSDN 여기에서 볼 수 있습니다.

UI 응답성 도구에서의 새로운 DOM 색상화 살펴보기

WebDriver를 사용한 테스트 자동화

IE 개발자 채널에는 웹 개발자들이 테스트를 작성하여 사이트를 테스트할 웹 브라우저를 자동화할 수 있는 새로운 WebDriver 표준에 대한 지원도 포함됩니다. 이것은 복잡한 사용자 시나리오를 개발하고 웹 사이트와 브라우저에서 자동화된 방식으로 실행하기 위한 프로그래밍이 가능한 원격 제어입니다. IE 개발자 채널에서 WebDriver 설정을 하는 방법을 확인하고 이 샘플 WebDriver 프로젝트를 사용해 보시기 바랍니다.

웹 게임에 Xbox 컨트롤러 사용

브라우저에서 게임을 할 때 Xbox 컨트롤러를 사용하고 싶었던 적이 있습니까? IE 개발자 채널에는 새로운 게임패드 API 표준 지원이 포함되어 있어 JavaScript를 사용하여 웹 앱과 게임을 지원하는 게임 패드를 추가할 수 있습니다. Xbox 360 컨트롤러를 연결하여 XP에서 탈출하기 게임을 해보시거나 Atari Arcade 게임을, 또는 Hover.IE를 사용해 보시기 바랍니다!

Xbox 컨트롤러를 사용하여 XP 탈출하기

또한 IE 개발자 채널은 WebGL 성능을 개선하고 인스턴싱 확장자, 16비트 텍스처, GLSL 내장 변수 및 삼각형 팬에 대한 지원을 추가했습니다. 이 버전에서는 Khronos WebGL 적합성 테스트 1.0.2 점수가 89%에서 94%로 올랐습니다. 이러한 WebGL API에 대한 자세한 내용은 MSDN 여기를 둘러보십시오.

최초의 개발자 채널 버전

새로운 기능과 표준에 대한 작업을 하면서 IE 개발자 채널을 통해 지속적으로 초기 코드를 공유할 예정입니다. IE 개발자 채널의 최신 기능에 대한 자세한 내용을 알아보려면 언제든지 DevChannel.Modern.IE 페이지를 참조할 수 있습니다. IE 개발자 채널에서 지원되는 모든 새로운 기능은 상호 운용 가능 웹 플랫폼 기능에 대한 로드맵을 전달하는 새로운 포털인 Status.Modern.IE에도 정리되어 있습니다.

이 버전의 IE 개발자 채널은 코드 변경 사항과 가상화를 결합하여 IE11과 함께 사용할 수 있습니다. 이러한 가상화는 약간의 성능 문제 일으킬 수 있기 때문에 사이트 성능 측정에 이 버전을 사용하지 않는 것이 좋습니다. 또한 기업 환경에서는 이 버전을 설치하지 않는 것을 권장합니다. 알려진 문제점에 대한 자세한 내용은 FAQ 목록을 참조하시기 바랍니다.

@IEDevChat 또는 Connect를 통해 피드백을 보내 주시면 업계 발전에도 도움이 되고 브라우저를 지속적으로 발전시키는 자양분이 될 것입니다. 또한 6월 19일 목요일 태평양 표준시 기준 오전 10시-오후12시(한국 시간으로 새벽 2시부터 새벽 4시) 사이에 개최될 다음 #AskIE 세션에도 반드시 참석해 주시기 바랍니다.

- Internet Explorer 파트너 그룹 프로그램 관리자, Jason Weber

참고: IE 팀의 Charles Morris도 Channel 9 Studios에 들러 Internet Explorer 개발자 채널에 대한 대화를 Geoff Knutzen과 함께 나눴습니다.

Internet Explorer 11과 관련하여 Microsoft는 사용자가 사이트에 더욱 빠르고 안정적으로 로그인하고 자격 증명을 저장할 때 정확히 통제할 수 있도록 하기 위한 작업을 해왔습니다.  또한 IE11은 이제 Windows Phone 8.1용 IE11에 자격 증명을 로밍할 수 있게 되었습니다.

이제 Windows Phone 8.1용 IE11으로 암호 저장 및 로밍 가능

안정적인 로그인 양식 감지

IE11에서는 로그인 양식 감지 기능을 강화해 IE가 이제 웹에서의 로그인 양식 90% 이상에 해당하는 암호를 기억할지 묻습니다.  이것은 이전 버전의 IE에 비해 상당한 개선된 사항입니다.

암호 저장 여부를 사용자가 결정

특정 사이트의 암호 저장 여부를 결정할 때 사용자가 이를 통제할 수 있도록 하고 있습니다.  IE11은 이제 로그인 양식에 autocomplete=off 특성이 설정되어 있어도 암호를 저장할 것인지 사용자에게 묻는 메시지를 표시합니다.  IE는 그 외 다른 양식 필드(예: 사용자 이름, 신용 카드, 주소, 이름 등)에 대해서도 이 특성을 지속적으로 준수할 것입니다.  이렇게 하는 주된 이유는 두 가지입니다. 하나는 IE가 특정 사이트에서 암호를 기억하지 않는 이유에 대해 사용자가 혼란스러워 할 수 있는 문제를 해결하기 위해서입니다. 둘째로 양식에서 autocomplete=off 특성을 준수하는 것보다 강력하고 고유한 암호를 만들도록 권장하는 것이 더욱 중요하다고 생각하기 때문입니다. 사용자는 특정 장치와 특정 상황에서 암호를 저장하는 것이 안전한지 직접 결정할 수 있어야 합니다. 

신속한 로그인

IE는 페이지가 로드된 후 안전하다고 판단되면 자격 증명을 자동으로 사전 입력하여 시간을 절약합니다. 이전에는 사용자가 사용자 이름을 선택하여 암호를 입력하려면 사용자 이름 필드를 클릭하거나 탭한 다음 다시 클릭하거나 탭해야 했습니다.  이 때문에 터치 장치에서는 쿠키 정보에서 사용자 이름을 사전 입력하는 사이트에서 두 번 탭하여 확대/축소가 트리거되는 문제가 발생했습니다. 로그인 양식에서의 이러한 자동 완성 동작의 변경은 사이트가 특정 보안 기준을 충족하지 못하는 경우 IE가 기존의 탭하여 선택하는 동작으로 전환되기 때문에 안전합니다. 이러한 설계는 Microsoft가 사용자 보안 유지에 집중한 결과입니다.

태블릿 사용자의 경우 자동 완성 항목을 탭하여 선택하면 광학 줌이 트리거되는 문제를 해결하기 위해 입력 요소에는 두 번 탭하여 확대/축소하는 기능이 비활성화되었습니다. 마지막으로, 사이트가 사용자 이름과 암호 입력 시 감지할 수 있도록 IE는 이제 양식에 자격 증명을 사전 입력할 때 '입력' 및 '변경' 이벤트를 발생시킵니다.

한 번 로그인으로 모든 사이트 사용

Windows 8.1 및 Windows Phone 8.1의 사용자는 이전에 IE에 저장한 Windows 또는 Windows Phone 스토어 앱에서 같은 도메인에 대해서는 자격 증명을 다시 입력하지 않아도 됩니다.  이러한 조치를 통해 모든 앱과 장치에서 로그인 환경의 속도를 대폭 높일 수 있습니다. IE11에서는 Windows가 웹 인증 브로커를 통해 스토어 앱에서 같은 도메인으로 호스팅된 앱에 대해 IE 저장 자격 증명을 사용합니다. 항상 그랬듯 스토어 앱은 IE에 저장된 자격 증명을 읽을 수 없습니다.

Windows는 IE11의 사용자 로그인 정보를 Windows 스토어 앱에서 호스팅되는 같은 도메인에 사용할 예정

현재 웹 인증 브로커를 사용하는 Windows 스토어 앱은 추가 마크업 없이도 이와 같은 환경이 자동으로 제공됩니다. 또한 사이트와 앱 자격 증명은 PC와 모바일 장치 간에도 로밍됩니다.

암호 관리

Windows 8.1용 IE11은 Windows 자격 증명 보관에 자격 증명을 저장합니다. 웹 사이트 암호는 Windows 8에서 자격 증명 관리자 데스크톱 제어판에서 관리할 수 있습니다. Windows 8.1용 IE11의 경우 이제 최신 인터넷 옵션에서 직접 웹 계정을 관리할 수 있습니다. 최신 IE에서 이렇게 하려면 오른쪽부터 살짝 밀어 참 메뉴를 열고 설정을 탭합니다. 여기에서 바탕 화면으로 전환하지 않고도 계정을 열고 자격 증명을 관리할 수 있습니다.

이제 웹 사이트 계정을 브라우저 내에서 직접 관리 가능

또한 이전에 언급한 대로 모든 자격 증명을 모든 Windows 8.1 장치로 로밍할 수 있습니다.

이러한 로밍 환경을 체험해 보려면 Windows 8.1, Windows Phone 8.1 또는 Windows 7에서 IE11을 사용해 보십시오! 여러분의 많은 의견을 기다리겠습니다.

감사합니다!

- Internet Explorer 수석 프로그램 관리자, Amy Adams

몇 가지 개발자 참고 사항:

사이트에 IE11의 암호 관리자를 사용할 수 있으려면 로그인 양식이 다음 기준을 충족해야 합니다.

• 서비스 로그인을 위한 사용자 이름과 암호가 둘 다 포함
• 사용자 이름과 암호 필드가 HTML5 양식 요소에 캡슐화
• 자유 양식 사용자 입력을 허용하는 사용자 이름 필드에 HTML5 표준 입력 형식 사용
• 암호 필드에 사용하는 HTML5 암호 입력 필드 사용
• DOM 수준 2 제출 이벤트는 양식 제출 시 발생하고 자격 증명은 제출 이벤트 발생 전에 지워지지 않음
]]> https://docs.microsoft.com/archive/blogs/ie_ko/windows-8-1-f12 Mon, 21 Apr 2014 09:50:00 GMT https://blogs.msdn.microsoft.com/ie_ko/2014/04/21/windows-8-1-f12/ IE 개발자 도구(F12)와 Visual Studio 2013 업데이트 2에 대한 대대적인 업데이트를 선보이게 되어 기쁩니다. F12 업데이트는 IE11의 최신 버전과 함께 발표됩니다.

앞서 게시된 기사에서는 빠르고 반복적인 워크플로, DOM 탐색기에서의 정확한 데이터 제공, 메모리 및 성능 도구에서 실행 가능한 데이터 제공에 중점을 두고 F12의 기능을 설명했습니다.

이번 업데이트가 적용된 F12를 사용하면 다음과 같은 향상된 기능을 확인할 수 있습니다.

• CSS 도구에 변경 추적 기능이 도입되어 보다 정확하고 반복적인 워크플로
• 소스 맵 지원을 통해 CoffeeScript 또는 TypeScript 등과 같이 작성한 코드를 디버깅하는 기능과 다른 개발자의 라이브러리를 사용하는 경우 "JMC(Just My Code)"를 디버깅하는 기능
• JS 스냅샷 도구 및 필터링이 향상되어 메모리 누수를 찾는 경우 등의 상황에서 솔루션으로 더 빨리 이동할 수 있도록 지원

아래에서는 F12 도구에서 향상된 이러한 기능에 대해 살펴보겠습니다.

변경 표시줄로 CSS에서 변경한 내용 추적

F12와 같은 도구의 중요한 장점 중 하나는 소스 코드가 없어도 브라우저 안에서 직접 웹 사이트의 모양을 편집할 수 있다는 점입니다. 하지만 편집하는 데 시간이 든다면 CSS에서 변경한 모든 내용을 추적하고 최종 편집 내용을 원본 소스로 다시 적용하기가 어렵습니다. 이러한 상황을 개선하기 위해 '변경 표시줄'을 사용한 시각적 방법과 DOM 탐색기의 새로운 '변경 내용' CSS 패널을 통한 방법 두 가지를 사용하는 변경 내용 기록 및 추적 기능을 도입했습니다.

DOM 탐색기의 스타일 창에서 CSS 규칙과 속성을 변경한 경우 편집한 속성 또는 규칙 왼쪽 여백에 시각적인 힌트가 표시됩니다. 이러한 시각적 힌트를 '변경 표시줄'이라고 하며 새로운 속성은 녹색, 변경된 속성과 값은 노란색, 삭제된 속성은 빨간색으로 나타납니다. 이 변경 표시줄은 다른 DOM 노드를 살펴보는 경우에도 유지됩니다.



스타일 탭의 변경 표시줄

여러 노드에서 여러 번 편집을 할 수 있기 때문에 현재 F12 세션에서 소스 코드를 수동으로 편집할 때 검사 목록으로 사용할 수 있도록 CSS 패널에 '비교' 보기로 모든 변경 내용을 정리하는 새로운 탭을 추가했습니다. 또한 상황에 맞는 메뉴를 통해 변경 내용을 복사하고 되돌리는 기능을 지원합니다.



새로운 변경 내용 탭

"JMC(Just My Code)"를 사용한 앱 디버깅

웹 사이트 및 앱을 개발하는 경우 jQuery 또는 Angular와 같은 타사 라이브러리를 사용할 가능성이 높은데 일반적으로 이러한 라이브러리는 축소되는 경우가 많습니다. 코드를 디버깅하는 개발자들은 라이브러리 코드를 한 단계씩 실행하다가 그 라이브러리에 너무 깊이 들어가게 되어 정작 문제를 디버깅해야 하는 코드로 돌아오지 못하는 경우가 많습니다.

Visual Studio는 일정 기간 동안 "JMC(Just My Code)" 관리 언어라는 기능을 지원해왔는데 Visual Studio 2012에서도 JavaScript에 사용됩니다. JMC의 기본적인 아이디어는 변경할 수 없는 코드가 아니라 디버깅하려는 코드에 디버거를 배치하는 것입니다.

이제 F12에서 이 기능을 제공하므로 디버깅할 때 다음과 같은 두 가지의 중요한 사항을 확인할 수 있습니다.

• 라이브러리 코드로 표시된 파일(라이브러리)은 한 단계씩 실행하지 않아도 됩니다. 파일을 한 단계씩 실행했더라도 디버거의 파일 선택기에서 라이브러리를 표시할 수 있습니다(아래 참조). 일단 라이브러리로 표시하면 어떤 단계에서도 원래 코드로 이동할 수 있습니다.
• "모든 예외 발생 시 중단"을 사용하더라도 라이브러리 코드에서 반환 및 처리되는 예외에 대해서는 중단되지 않습니다.



파일을 라이브러리 코드로 표시

F12는 기본적으로 URL *.min.js와 일치하는 파일을 라이브러리 코드로 인식합니다. 하지만 디버거에서 파일을 연 경우 디버거의 파일 선택기 또는 파일 탭의 상황에 맞는 메뉴에서 라이브러리를 표시하면 이 동작을 수정할 수 있습니다.

후속 블로그 글을 통해 이 기능과 워크플로에 대해 좀더 자세히 알아보도록 하겠습니다.

소스 맵을 사용하여 다른 언어로 작성된 앱 디버깅(v3)

최근에 JavaScript 앱이 점점 더 복잡해지고 있기 때문에 JavaScript를 준수하는 다른 언어로 작성하는 추세가 늘어나고 있습니다. 예를 들어 F12 도구는 TypeScript로 작성되고 JavaScript로 컴파일되었습니다. 이와 마찬가지로 앱을 작성한 원본 소스가 아닌 JavaScript 코드를 축소했을 수 있습니다. 이러한 컴파일 프로세스를 사용하면 브라우저에서 실행되고 디버깅되는 JavaScript가 편집기의 코드가 아니기 때문에 디버깅하기가 더 까다로워집니다.

이 문제를 해결하기 위해 커뮤니티에서는 다양한 브라우저와 Visual Studio에서 많은 관심을 이끌었던 원본 소스 및 "소스 맵"(사양)이라는 컴파일된 파일을 매핑하는 방법을 모색했습니다. 이러한 맵은 컴파일 중에 생성되며 이 버전의 F12에서는 소스 맵 사양의 v3에 대한 지원을 추가했습니다.

컴파일된 JavaScript 파일이 유효한 소스 맵을 정의하는 경우, 디버거의 단추를 클릭하여 소스 맵을 사용하도록 하면 F12는 JS 파일을 실행하는 대신 원본 소스 파일을 로드하도록 기본값이 설정됩니다. 다음과 같은 기능을 사용할 수 있습니다.

• 파일 선택기에 표시된 파일은 실행 중인 문서 대신 원본 소스 이름을 사용합니다.
• 디버거에서 열고 코드를 단계적으로 실행하는 데 사용되는 파일은 원본 소스 파일이고 TypeScript, CoffeeScript 및 Script #의 경우에는 해당 파일들이 적절한 색으로 구분되어 표시됩니다(아래 TypeScript 파일 참조).



소스 맵에 대해서도 JMC의 경우와 마찬가지로 후속 블로그 글을 통해 좀더 자세히 알아보겠습니다.

3단계 스냅샷

메모리 누수를 디버깅할 때는 일반적으로 필터링되었더라도 메모리 프로파일러가 만든 대량의 데이터가 표시되기 때문에 메모리 누수를 찾는 과정이 복잡합니다. 이전 버전의 F12에서는 스냅샷 타일을 통해 앱의 상태를 요약하고 DOM 정보를 분리하여 표시하는 한편 잠재적인 문제를 간편하게 파악할 수 있도록 조치를 취했습니다. 하지만 이번 업데이트에서는 이러한 조치를 확장하여 개발자가 다양한 문제를 근본적인 측면부터 훨씬 더 쉽게 해결할 수 있도록 지원하기 위해 노력했습니다.

이제 F12 메모리 도구에는 3개의 스냅샷을 비교하고 해당 스냅샷의 범위 지정 보기를 가져오는 기능이 포함되어 있어 메모리 누수를 보다 명확하게 파악할 수 있게 되었습니다. 이러한 스냅샷은 다음과 같은 특성을 가집니다.

• 시나리오를 시작하기 전 앱의 초기 상태로, 앱에 포함된 개체에 대한 기준을 제공합니다.
• 시나리오가 완료되면 앱에 대한 가능한 기준이 확장되며 시나리오를 다시 실행하면 추가 스냅샷이 필요하게 됩니다.
• 시나리오를 다시 시도하면 응용 프로그램이 '기본 상태로 전환'됩니다. 이 상태에서는 시나리오의 모든 개체가 해제되거나 사용이 가능해져야 합니다.

이러한 스냅샷을 통해 서로를 비교하고 새로운 "범위" 필터 드롭다운을 사용하여 시나리오의 최종 상태를 파악할 수 있으며, 아래에서 볼 수 있는 것과 같이 더 이상 남아 있으면 안 되는 개체 집합을 나타낼 가능성이 있는 "스냅샷 #2에서 남아 있는 개체"를 선택할 수 있습니다.



범위 필터

위와 같은 형식 보기에는 개체 목록과 잠재적인 문제가 있을 수 있는 위치를 나타내는 표시기가 나타납니다.

Visual Studio 2013 업데이트 2에서 Windows Phone용 IE 도구 지원

웹 사이트를 모바일 버전으로 만드는 데 많은 시간을 들였더라도 모바일 브라우저에서 모양이나 작동이 잘못되는 문제가 발생할 가능성이 높습니다.  Windows Phone에서 이러한 문제를 해결하기 위해 Visual Studio 2013 업데이트 2에 Windows Phone 8.1용 Internet Explorer를 대상으로 Visual Studio 디버그 및 성능 도구를 사용할 수 있도록 지원하게 되어 기쁩니다. 이에 대한 자세한 내용은 이 주제에 대한 Visual Studio ALM 블로그 에서 확인할 수 있습니다.

다양한 기타 개선 사항

이번 버전의 F12에서는 여러 고객의 요청을 반영하고 네트워크 검사기로 인해 발생하고 F12를 사용하여 하위 문서 모드를 에뮬레이션할 때 조건부 주석이 반영되지 않는 여러 가지 충돌 등의 버그를 해결하기 위해 노력했습니다. 여기에 버그 목록을 게시하는 대신 Microsoft Connect IE 사이트(https://connect.microsoft.com/IE/Feedback)에 버그를 업데이트할 예정입니다.

이번 버전의 F12에서 확인할 수 있는 좀더 자세한 변경 사항은 다음과 같습니다.

셸

• Ctrl+[ 및 Ctrl+]를 사용하여 도구 탐색

콘솔

• 실행 대상을 열거하는 드롭다운
• printf-style 서식이 포함된 console.log를 통해 검사 개체 로깅
• 콘솔에서 IntelliSense를 통해 중단점에 로컬 변수 지정 가능
• Console $_ shortcut을 통해 콘솔의 최근 평가 결과 액세스
• F12 실행 전에도 항상 콘솔 메시지 기록([인터넷 옵션] -> [고급] -> [개발자 콘솔 메시지 항상 기록] 선택)

디버거

• BP, Watch, Tab 등이 유지되므로 상태가 손실되지 않음
• 소스 맵을 사용하여 F12 내에서 Typescript/컴파일된 코드 디버깅 가능
• JMC 디버깅 지원을 통해 라이브러리 코드(JMC)에 신경 쓸 필요가 없음
• //#sourceUrl=<url> 주석을 통해 평가 코드 이름 지정
• Ctrl+Shift+F5를 통해 중단되는 경우 페이지 중단 및 새로 고침을 위한 키보드 바로 가기 제공
• 호출 스택 및 프로파일러 보기에 정규화된 기능 이름(예: a.b.c) 포함

DOM 탐색기

• CSS 의사 상태 - 의사 스타일을 테스트할 요소에 대해 의사 상태 설정
• CSS 변경 표시줄 - 스타일 보기에서 변경된 값 표시
• CSS 변경 내용 보기 - 최종 적용된 CSS 변경 내용을 확인하고 클립보드에 복사 가능
• 통합 컴퓨팅을 지원하는 스타일 패널 - 유기적인 CSS 창에서 CSS 스타일을 보고 링크를 소스에 추가 및 편집
• DOM 탐색기에서 선택한 요소에 대해 Ctrl+b 사용 가능

에뮬레이션

• 문서 모드 인식 - 페이지가 특정 문서 모드로 표시되는 이유를 알려주므로 호환성 시나리오 이해도 향상

UI 반응

• 타임라인 세부 정보 보기에서 모든 수준의 이벤트를 기간별로 정렬
• 이벤트를 특정 범주(예: GC, 이미지 디코딩)로 필터링하여 타임라인 세부 정보 보기 간소화
• 그래프 및 세부 정보 보기를 특정 이벤트 인스턴스에 대한 기간에 따라 간편하게 확대/축소(상황에 맞는 메뉴 사용)
• DOM 요소의 인라인 스타일이 프로그래밍 방식으로 수정될 때 변경된 속성을 정확하게 파악하고 변경된 값을 식별할 수 있음

메모리

• 특정 기능을 할당하는 코드 줄을 식별할 수 있으므로 메모리와 소스의 상관 관계 파악 가능
• 상황에 맞는 메뉴 항목을 통해 도미네이터 보기에서 개체 표시, 보존 크기 확인 등
• 형식 보기가 업데이트되어 비교 보기를 통해 변경 사항이 많은 형식이 표시되므로 개체 변동을 보다 쉽게 추론 가능
• 표 UI의 눈금선
• 설정 UI(내장, 원형 참조, 개체 ID 표시)

요약

이번 IE 11 및 F12를 통해 개발자 도구를 더 자주 업데이트하여 최대한 신속하게 최신 기능을 제공하고 버그를 수정할 수 있게 되었습니다. 조만간 더 많은 내용을 알려 드릴 수 있도록 최선을 다하겠습니다. 의견이 있거나 새로운 기능 및 지원이 필요한 경우에는 트위터(@IEDevChat)로 문의하거나 IE11 의견 보내기 도구 또는 Connect를 통해 알려 주십시오.

이 글에서는 F12의 새로운 기능을 간략하게만 소개했습니다. 앞으로 몇 주 간 F12에 대해 자세히 설명하고 사용하는 방법을 보여 주는 블로그 내용을 게시할 예정입니다. MSDN에서도 F12 개발자 도구 설명서 전문을 볼 수 있습니다.

여러분의 많은 의견을 기다리겠습니다. 트위터(@IEDevChat)로 문의하거나 IE11 의견 보내기 도구 또는 Connect를 통해 팀에 연락할 수 있습니다.

- Andy Sterland, F12 도구 프로그램 관리자

- Jonathan Carter, F12 도구 프로그램 관리자

- Simon Calvert, F12 도구 수석 프로그램 관리자

]]>