엣지(웹 브라우저)

• 상위 문서 : 웹 브라우저, 마이크로소프트
• 관련 문서 : 인터넷 익스플로러, Windows 10

주요 웹 브라우저
엣지	크롬	파이어폭스
사파리	오페라	비발디
인터넷 익스플로러 *	네이버 웨일
* 마이크로소프트 엣지 출시로 인하여 사실상 기능 업데이트가 중지 되었다. (보안 업데이트는 윈도우 지원 기간에 맞게 실시)

Microsoft Edge
마이크로소프트 엣지
width=100%
개발사	마이크로소프트
분류	웹 브라우저
공식 최신 버전	38.14393
엔진	레이아웃	EdgeHTML
	자바스크립트	Chakra
플랫폼	Windows 10
링크	공식 홈페이지 릴리즈 노트

1 개요

2015년 1월 21일에 발표된, 마이크로소프트의 인터넷 익스플로러를 대체하기 위해 만들어진 차세대형 웹 브라우저. Windows 10부터 시작하여 앞으로 마이크로소프트의 OS 제품군 및 각종 서비스를 사용하는 모든 장치의 기본 브라우저로 사용된다.

개발 기간 중에 쓰였던 코드네임은 헤일로 시리즈에서 주인공 마스터 치프가 속한 스파르탄 프로그램에서 따온 것으로 추정되는 'Project Spartan'이었으며, 2015년 4월 29일에 '마이크로소프트 엣지'로 정식 명칭이 확정되었다. 링크 아이콘이 여전히 익스플로러를 연상시키는 e 모양인데, 저 아이콘이 없으면 인터넷 안 되는 줄 아는 사람들을 배려한 아이콘이다. 컴맹은 당신이 생각하는 것보다 훨씬 많다. 그리고 저렇게 함으로써 엣지 점유율을 높이면 마소가 추구하는 대로 Active X 없는 인터넷 환경 구현도 가능해질 것이다. 대신 윈도 10의 처음 사용자들이 로고만 슬쩍보고 엣지를 IE로 오해하는 경우가 있다.

여담으로 대표적인 웹브라우져 점유율 통계 사이트인 #statcounter(트래픽을 기준)와 # netmarketshare.com(실사용자 수 기준) 에서 점유율을 확인할 수 있다.

2 기능

2.1 20.10240

2015년 3월 30일에 테크니컬 프리뷰의 10049 빌드를 통해 엣지가 처음으로 대중에 공개되었다. 발표회에서 밝혔던 필기 기능, 리딩 리스트 기능, 코타나 연동 등의 기능들이 전부 사용 가능한 상태로 풀렸다. 첫 번째 정식 버전인 20.10240.16384.0은 7월 29일에 윈도우 10과 함께 공개되었다.

• 원노트 연동

웹페이지에 바로 필기를 할 수 있고, 필기 후 원노트로 다른 사람들과 원노트로 공유할 수 있다.

• 읽기 뷰

웹페이지의 메뉴, 광고 등을 다 치워버리고 내용만 보여주며, 레이아웃 최적화를 통해 쉽게 읽을 수 있게 한다. 읽기 리스트에 웹페이지나 PDF 파일을 저장해 쉽게 볼 수 있고, 구성할 수 있다.맥 OS나 iOS의 읽기 목록을 생각하면 편하다.

• 쉽게 찾기

주소 바를 향상시켜, 추천 웹페이지를 보여주고, 주소바에 날씨, 증권, 정의, 계산 등을 할 수 있다.

• 코타나 연동

엣지에서 코타나를 통해 바로 예약을 하거나, 리뷰를 웹페이지를 벗어나지 않고 할 수 있고, 모르는 단어를 하이라이트 하면 설명해준다.

2.2 25.10586

두번째 정식 버전인 25.10586 버전이 2015년 11월 12일부터 Windows 10 TH2 업데이트와 함께 배포되었다. ObjectRTC 지원, 탭 미리보기 기능, 미디어 캐스팅 기능 등의 향상점이 있다.

2.2.1 EdgeHTML 13의 기능 업데이트

HTML 기능을 강화했다. 다음 사진은 HTML5Test라는 곳에서 즉정한 HTML5 표준 지원 정도를 나타내고 있는데, 7월에 나온 EdgeHTML 12보다 56점이 상승했다.

• CSS
  • CSS Mutability 의사 클래스
    • :read-write
    • :read-only
  • CSS Range 의사 클래스
    • :in-range
    • :out-of-range
  • CSS initial 키워드
  • CSS unset 키워드
• 파일 API
  • a[download] 속성
• 사용자 입력
  • input type="text" selectionDirection
  • input type="time"
  • input type="datetime-local"
  • <meter> 원소
  • 엘리먼트 문서와 창을 위한 oninvalid 이벤트 핸들러
  • 포인터 잠금 (마우스 잠금)
• 그래픽
  • 캔버스 타원
  • 캔버스 모드 섞기
  • 확장된 srcset과 사이즈
  • <picture> 원소
  • SVG 외부 원소
• 통신
  • Object RTC
• 도구
  • F12 개발도구 도킹 기능 복구
• 웹 컴포넌트
  • <template> 원소

2.2.2 차크라 엔진 기능 업데이트

자바스크립트 최적화를 위한 asm.js가 이제 기본으로 켜져 성능 향상이 있었다고 한다. 그리고 자바스크립트 최신 표준인 ES2016 지원을 확대해 Kangax EX6에서 가장 높은 점수를 보유하던 시기도 있었으나, 애플의 사파리 10 버전이 공식출시와 함께 100% 를 찍으면서 그 영광도 옛말이 되었다. 크롬등도 이미 97%의 지원률을 보이는 상황에서 엣지는 그보다 낮은 지원률을 기록하고 있다.

참고로 FF는 FireFox, CH는 Chrome을, SF는 Safari를 지칭한다.
about:flags에 다음과 같은 자바스크립트 기능들을 프리뷰로 제공한다.

• ES2016 비동기 함수들 (“실험적 기능”에 있다)
• ES2016 지수 연산자 (“실험적 기능”에 있다)
• asm.js가 기본으로 켜진다. (기존에는 플래그에 있었다)
• ES2015 클래스도 기본으로 켜진다. (기존에는 플래그에 있었다)
• ES2015 Destructuring이 추가되었다. (“실험적 기능"에 있다)

2.2.3 지원 플랫폼 확장

EdgeHTML 13은 PC, 폰, Xbox One에도 지원된다. <picture> element와 extended srcset로 적응형 이미지를 폰에 보여줄 수 있고, WebGL과 GamePad API로 Xbox One의 브라우저에서 게임을 즐길 수 있다.

2.2.4 새로운 사용자 기능들

Edge 25로 버전업을 했으며(렌더링 엔진과 혼동하지 말자. 렌더링 엔진 EdgeHTML는 13), 탭 프리뷰, 즐겨찾기와 읽기 목록 동기화, 무선 멀티미디어 캐스팅 등을 지원한다.

그 외에도 윈도우 커널의 코드 통합 강제 기능을 넣고, 스마트 스크린 필터를 업데이트해 드라이브-바이 다운로드(Drive-By download) 공격을 보호한다고 한다.

2.3 38.14393

2016년 8월 2일에 정식 배포되었다. 윈도우 스토어에서 브라우저 확장기능 설치, 수 많은 새 기능들, 전력 소모와 보안 향상 등을 했다. 그리고 브라우저들 중 처음으로 HTML5Accessibility.com에서 100% 점수를 받은 접근성이 좋은 브라우저이다.

2.3.1 마이크로소프트 확장 기능

윈도우 참가자들에게 몇 개의 확장 기능을 프리뷰로 제공하면서 확장 기능 플랫폼을 제공하려고 했다. 이제 1주년 업데이트로 완전히 공개되었다.

AdBlock, Adblock Plus, Amazon, Evernote, LastPass, 마이크로소프트 번역, Office Online, Pinterest, Pocket 등의 확장 기능들을 윈도우 스토어에서 제공한다. 이 외에도 미래에 다른 확장 기능들을 높은 퀄리티로 계속 윈도우 스토어에 제공할 것이라고 한다. 확장 기능은 마이크로소프트 엣지 메뉴의 "확장 기능"을 선택하거나 윈도우 스토어에서 찾을 수 있다.

2.3.2 접근성 기능 강화

그동안 접근성 기능 지원에 대한 로드맵과 작업을 해온 결과 EdgeHTML 14에서 HTML5Accessibility 브라우저 벤치마크에서 100점을 맞을 정도로 접근성 기능 지원이 좋은 브라우저가 되었다고 한다.

중요한 몇 가지 향상점들과 수 백개의 버그 픽스를 통해 키보드와 스크린 리더 같은 접근성 기술로 내비게이션이 쉬워졌고, PDF 파일 지원 강화와 주소 바 추천 및 즉각적인 답변에 대한 내레이터 지원, 그리고 탭, 창, 즐겨찾기 같은 일상적인 브라우저 기능들에 대한 넓은 범위의 향상을 이끌어냈다. 또한 렌더링 엔진에 새롭게 만든 접근성 아키텍처를 탑재해, 개발자들이 HTML5 기반 접근성 사용자 경험을 만들 수 있게 되었다. 또한 사이트들과 다른 브라우저 벤더들이 HTML5Accessibility 테스트 스위트를 자동으로 실행할 수 있도록 오픈소스 툴을 개발했다고 한다.

2.3.3 새로운 기능

• 탭 고정

크롬에 있는 기능.자주 사용하는 사이트들과 웹 앱들을 클릭 한 번으로 가기 위해 탭을 고정시킬 수 있다 - 아무 탭이나 우클릭 후 "고정"을 선택하면 된다.

고정된 탭들을 언제나 탭 행의 시작점에서 사이트 아이콘만 보일 것이다. 마이크로소프트 엣지 창에 있는 고정된 탭들은 앱을 닫아도 다시 열 때 보일 것이다.

• 붙여넣고 바로 이동

링크를 클립보드로 복사하면, 주소 바에 우클릭 하고 우클릭 메뉴에 "붙여넣고 바로 이동"를 누르면 바로 그 사이트로 갈 것이다.

링크말고 다른 것을 클립보드에 복사하면 대신 "붙여넣고 검색" 옵션을 볼 것이다.

• 웹사이트 알림

엣지에서 웹사이트들일 알림을 보낼 수 있게 되어, 웹용 스카이프, 슬랙, 왓츠앱 같은 즐겨찾는 사이트에서 즉시 메시지나 업데이트를 볼 수 있다.

그리고 항상 사이트가 알림을 보내기 전에 엣지가 권한을 물어볼 것이고, 마이크로소프트 엣지의 설정이나 윈도우 10의 액션 센터에서 알림을 우클릭 해서 알림을 관리할 수 있다.

• 쓸어서 넘기기

손가락을 쓸어서 뒤로/앞으로 가기를 할 수 있다. 터치스크린 PC나 윈도우 10 모바일 장치에서, 손가락으로 좌우로 밀면 히스토리의 전후 페이지로 가게 된다.

• 이미지를 코타나에 묻기

웹 상의 아무 사진이나 우클릭 후 “Ask Cortana”를 선택하면 연관된 정보나 사진들을 알아내서 더 많은 정보들을 제공할 것이다.

• 즐겨 찾기 강화

파이어폭스, 크롬, 인터넷 익스플로러에서 즐겨찾기를 가져올 수 있다. 다른 브라우저에서 즐겨찾기를 가져올 때, 이미 있던 즐겨찾기와 섞이지 않고 다른 폴더 안에 분리될 것이다. 즐겨찾기는 허브의 새 "트리" 디스플레이를 통해 더 쉽게 관리할 수 있다. 또한 폴더들을 확장하고 축소해서 안의 콘텐츠를 보고 싶은 많큼 볼 수 있다. 또한 즐겨찾기 탭의 즐겨찾기가 이름 순으로 정렬되어있고, 드래그 앤 드롭으로 재정렬 하거나 폴더 사이를 옮길 수 있다. 즐겨찾기 바에서 우클릭 해 디스플레이 아이콘만 보이게 하거나, 아이템의 이름을 바꾸거나, 새 폴더를 만들 수 있다.

• 다운로드 관리 강화

엣지를 닫아도 진행중인 다운로드에 대한 알림을 보내준다. 그에 따라 엣지를 닫아도 다운로드를 완료할 수 있게 해준다. 또한 기본으로 다운로드된 파일들을 저장할 곳을 설정할 수 있다. "설정"을 열고, "고급 설정"을 선택한 후, "다운로드" 및의 새 옵션들을 볼 수 있다.

• 폴더 드래그 앤 드롭

마이크로소프트 엣지에 폴더 째로 드래그 앤 드롭으로 OneDrive, Dropbox, Google Drive 같은 곳에 폴더를 업로드할 수 있다.

• 모바일에서 탭 향상

폰의 앱으로 새 탭을 열었을 경우에 엣지가 자동으로 관리한다. 만약에 앱에서 링크를 클릭해 새 탭을 열고, 뒤로 가기 버튼을 누르면 자동으로 탭을 닫고, 앱으로 돌아갈 것이다. 자동으로 탭들을 닫아 탭 리스트가 최소한으로 관리된다.

• 홀로렌즈에서 탭 프리뷰

홀로렌즈에서 탭 위에 시선을 두면 PC와 같이 페이지의 썸네일 프리뷰를 볼 수 있다.

• 기타

그것 말고도 더 많은 기능들을 보고 싶으면 "..." 메뉴를 열고 "새로운 기능과 팁"을 누르면 된다.

2.3.4 효율, 보안, 성능, 호환성 강화

기본적인 전력 효율, 보안, 성능, 호환성에 대해 지속적으로 투자했다고 한다.

• 전력 효율

EdgeHTML 14에서, 자바스크립트 타이머 실행 주기를 줄이는 방식으로 백그라운드 탭 효율을 향상시켜 몇몇 경우에 90%까지 에너지 소모를 줄였다고 한다. 또한 불필요한 플래시 콘텐츠를 사용자가 클릭해 재생할 때까지 일시 정시시켜 플래시 효율정을 높였다고 한다. 그리고 플래시를 분리된 프로세스로 만들어, 플래시가 너무 많은 리소스를 쓰거나 충돌하면, 엣지가 웹사이트의 나머지 부분에 영향을 주지 않고 플래시를 끌 수 있다고 한다.

• 보안 강화

브라우저에 노출되는 커널 컴포넌트를 줄이고 플래시와 콘텐츠 프로세스에서 호출 가능한 커널 콜 리스트를 만들고 강제하는 기능인 커널 공격 보호 기능을 엣지에 탑재했다고 한다. 또한 플래시가 분리된 AppContainer에서 돌아가기 떄문에 플래시 취약점과 연동된 위험들을 줄일 수 있었다고 한다.

• 성능 향상

브라우저 렌더링 엔즌은 몇 개의 다른 서브시스템들로 만들어지는데, 이는 각각의 페이지의 부하가 다르게 걸리게 했다. EdgeHTML 14에서, 더 빠른 경험을 위해 핵심 컴포넌트들이 더 빠르고 효율적으로 작동하게 하도록 성능을 측정하고 다듬었다고 한다. 밑의 애플과 구글에서 만든 벤치마크들에서도 엣지가 일관되게 이기고 있는 것을 볼 수 있다.

제품의 일반적인 튜닝과 더불어, 차크라 자바스크립트 엔진에서 함수들의 메모리 최적화와 이벤트 핸들러들의 지연 파싱, 그리고 frame.contentDocument, iframe.contentWindows, scriptElement.src, requestAnimationFrame 같은 일반적인 자바스크립트 API 성능 최적화와 콜백 오버헤드 감소 같은 성능 향상을 통해 많은 잘 알라젼 프레임워크들과 코딩 패턴들에서 더 좋은 경험을 할 수 있게 되었다.
마지막으로, 키보드와 스크롤바 액션들 같은 스크롤링을 UI 쓰레드에서 완전히 분리시켜 개선했다고 한다. 이는 복잡한 페이지들이 로딩과 렌더링하느라 바쁜 와중에도 터치, 터치패드, 마우스 휠, 키보드로 문서를 스크롤할 수 있다는 것이다.

• 호환성 향상

작년부터 상호 운용성(렌더링 엔진을 개발자들이 실제로 쓰고 있고 현재 유명한 브라우저들이 지원하는 "상호 운용 가능한 부분"에 대한 API를 맞추기)에 대해 집중했다고 한다. 1월부터, 마이크로소프트 엣지에서 사이트들이 "그냥 작동하도록" 자체적으로 평가를 했다고 한다.
11월의 EdgeHTML 13부터, IE11보더 현대 웹에 더 호환이 잘되어 구글 크롬과 비슷한 수준까지 올라갔다고 한다. 이 철학은 이전의 수동으로 관리되는 호환성 리스트보다 더 많은 웹 사이트에 적용할 수 있다고 한다.
EdgeHTML 14에도 똑같은 방식을 적용해, 윈도우 참가자 프로그램들과 마이크로소프트 엣지 개발의 툴을 통해 받은 개발자들과 소비자들의 직접적인 피드백과 어마어마한 인터넷 스케일 데이터를 통해 같은 전략 아래에서 만들었다고 한다.

Edge 14는 많은 새 HTML5 표준, 미디어 포맷, 그리고 자바스크립트 기능들을 포함해, HTML5Test에서 파이어폭스와 맞먹고, 사파리를 충실히 제치고 있다고 한다(최초 배포인 EdgeHTML 12부터). HTML5Test는 웹 플랫폼을 만드는 표준들의 부분집합의 존재 유무를 테스트하고 있다. 복잡한 벤치마크는 아니지만, 플랫폼 추이를 알 수 있고, 현대 렌더링 엔진들이 얼마나 핵심 기술들의 상호 운용 가능한 부분들을 커버하는지 알 수 있다고 한다.
EdgeHTML 14의 새 기능들은 다음과 같다.

• 새 HTML5 표준
  • 웹 알림 API
  • Fetch API
  • 웹 인증 API (FIDO 2.0 웹 API)
  • 비콘 인터페이스
  • time 요소
  • data 요소
  • output 요소
  • input type="color"
  • 캔버스 Path2D 오브젝트
  • 웹 음성 API (합성)
• 새 포맷
  • WOFF 2 폰트
  • Opus 오디오 재생

VP9 코덱을 포함할 수 있는 WebM 컨테이너가 지원하는 오디오 코덱 중 최신 오픈소스 오디오 코덱인 Opus를 지원하기 시작했다. 다만, Opus 오디오 코덱의 경우 MSE 활성화 설정값이 비활성이 기본이므로 about:flags 페이지에서 직접 설정해야한다.

• VP9 비디오 재생

구글이 유튜브에서 H.264의 열약한 화질을 극복하기 위하여 오픈소스로 개발한 VP9 코덱을 지원하기 시작했다. about:flags 페이지에서 VP9 코덱에 대한 MSE (Media Source Extension) 활성화 여부를 직접 설정할 수 있으며 기본값은 자동으로 되어있다. 위키러의 사양이 벅차서 VP9를 비활성화를 해도 좋다. 하지만 VP9의 단독 해상도인 1440p HFR (고속 프레임 레이트) 및 2160p HFR은 포기해야하고, VP9 코덱의 경우 1440p부터 H.264와 상당한 화질 격차가 날 정도로 우위를 보여준다는 점을 감안해야한다.

참고로 VP9는 PSNR 수치를 기준으로 H.264 대비 35%의 화질 개선이 가능하고 동일 해상도에서 H.264 대비 50%의 비트레이트 절감이 가능하여 H.265와 비슷한 화질 효율성을 보여준다. VP9 코덱은 64x64와 32x32 메크로 블록 도입 및 CTU와 CU의 이원화된 비대칭 DCT 알고리즘을 통해 H.264의 알고리즘보다 인코딩 및 디코딩 과정이 매우 복잡하여 사양의 부담이 더 높은 편이다. 그렇다고해도 저사양에서도 CPU 빨로 VP9를 통해 1080p부터 1440p HFR (고속 프레임 레이트) 해상도까지 재생하는데에는 크게 무리가 따르지 않는다. 하지만 최신 그래픽카드가 아니라면 VP9 코덱으로 2160p HFR 및 4320P (8K) 해상도는 포기해야한다. 더구나 H.264라고해도 최신 그래픽카드를 갖고있지 않다면 유튜브에서 H.264로 인코딩된 8K 동영상은 상당히 벅차다.

• 새 자바스크립트 기능 (기본으로 켜짐)
  • 기본 인수 (ES6)
  • 지수 연산자 (ES2016)
  • array.prototype.includes (ES2016)
  • object.values와 object.entries (ES2017)
• 실험적 자바스크립트 기능 (about:flags에서 활성화)
  • 모듈 (ES6)
  • async/await
  • 정규 표현식 심볼 (ES6)
• F12 개발자 툴
  • 접근성 트리 뷰
  • 확장 기능 디버깅
  • DOM API 프로파일링

2.3.5 기업용 기능

모든 윈도우 10 소비자들에게 더 빠르고, 효율적이고, 호환성이 좋고, 안전하고, 생산성이 좋은 브라우징 경험을 제공한다. 기업용 소비자들을 위한 다음 기능들을 추가했다: 조직들이 엣지를 기본 브라우저로 쓰고, 하위 호환성이 필요한 사이트들에 대해서만 인터넷 익스플로러 11로 내려가게 할 수 있다. "당신의 조직이 이 사이트를 인터넷 익스플로러로 열도록 설정했습니다"가 더 이상 기본으로 나오지 않고, 인터넷 익스플로러를 쓰는 사이트를 엔터프라이즈 모드 사이트 리스트에 추가해 제한할 수 있다. 또한 소비자 피드백을 기반으로 다른 관리 정책들을 "사용자"와 "컴퓨터" 정책에 둘 다 추가시켰다.

3 상세

3.1 엣지는 무엇인가?

엣지는 마이크로소프트가 현대 웹 디자인과의 호환성을 극대화하기 위해 기존 인터넷 익스플로러에 사용되던 렌더링 엔진인 트라이던트(mshtml.dll)를 하위호환을 고려하지 않고 바닥부터 개조하여 만들어낸 렌더링 엔진인 EdgeHTML(edgehtml.dll)을 기반으로 만들어진 새로운 웹 브라우저다. 원문 및 설명

간단하게 말하자면 엣지는 인터넷 익스플로러와 완전히 다른 브라우저다. 비유를 굳이 하자면, 집을 이사하지는 않았지만 안에 있는 각종 물건과 가구와 붙박이장까지 죄다 빼버리고 인테리어를 처음부터 다시 짜는 수준의 변화가 있었다. 그 변화의 폭이 어느 정도인지를 확인하려면 위의 그림을 확인하면 좋다. 인터넷 익스플로러 11은 IE11 뿐만이 아니라 10, 9, 8, 7, 6, 심지어 5.5까지 지원하기 위한 하위호환 코드들을 그대로 가지고 가고 있다. 하지만 엣지는 이 하위호환을 위한 코드를 전부 날려버리고, 심지어 바로 이전 브라우저인 IE11과의 호환을 위한 코드까지 남김없이 뜯어낸 뒤 웹킷 또는 게코와 비슷한 현대적인 방식으로 렌더링을 하고, 심지어 웹킷 전용 API까지 다수 끌어오면서 웹 표준을 따라 최근 만들어진 사이트들을 표시할 때 깨지거나 오류가 나는 상황을 최소화하는 것을 목적으로 하고 있다.

이것은 곧 MS가 드디어 액티브X를 버린 브라우저를 만들었다는 뜻이기도 하다.액티브X 독립 만세! 사실 액티브X를 위시한 IE6 방식의 웹 디자인은 해외에서도 그 문제가 심각한데, 특히 기업용 웹페이지 및 소프트웨어가 IE6을 요구하는 경우가 많다고 하며, 이런 부분 때문에 MS가 함부로 IE6 코드나 액티브X를 버리지 못한 측면이 크다. IE9 이래로 인터넷 익스플로러는 이 시절의 익스플로러에 비하면 훨씬 더 나아졌고 상당 부분 웹 표준을 따라가고 있지만, 아직 기본적인 원리는 IE5.5 내지 6 시절을 따라가고 있어 종종 오류가 나기도 했고, 반대로 웹페이지 쪽에서 사용자의 브라우저를 IE로 인식하는 바람에 웹 표준을 지키는 IE10이나 11을 사용함에도 불구하고 IE7/8 방식으로 코드를 보내주면서 문제가 생기기도 했었다. 엣지는 이를 막기 위해 레거시 코드를 통째로 날리고, 오히려 웹킷과의 호환성을 증대하는 방향으로 기존 엔진을 마개조하여 최신의 방식으로만 코드를 받고 표기하는 것을 목표로 한다.

3.2 엣지의 중요성

다 필요없고 윈도우10+마이크로소프트 서피스 프로 4+엣지는 무려 8시간 동영상 재생가능
빌드 9841 시절부터 윈도우 10 프리뷰를 따라온 사람들은 잘 알겠지만, 엣지의 실제 개발은 꽤나 뒤늦게 이루어졌다. 윈도우 10의 여러 기능들이 추후 업데이트로 밀리는 가운데에도 엣지는 심지어 이름을 제대로 정하기도 전에 공개되었고, 누가 봐도 빠듯해 보이는 일정 아래에서 매 업데이트마다 미친듯이 기능을 추가하고 버그를 고치며 RTM까지 달려왔다. 사실 IE팀은 2013년 중반에 윈도우 8.1 RTM에 맞춰 IE11이 마무리되고 나서야 윈도우 10에 들어갈 브라우저 개발 계획을 논의하기 시작했는데, 논의 과정에서도 별의별 아이디어가 다 있었다. 심지어 개발진 일부는 아예 웹킷을 사용하자는 의견까지 냈으나, 결국에는 기존 트라이던트를 고치는 방향으로 갔다고 한다. 하지만 이게 말이 고치는 것이지 변경 내역이 워낙에 장대해서, 인사이더 프리뷰 막바지까지도 다운이 된다든지, 특정 하이퍼링크가 작동하지 않는다든지 등의 자잘한 버그들이 정말로 많았다. 이러한 버그들은 RTM인 빌드 10240에 가서야 뒤늦게 해결되었는데, 기한을 앞두고 정말 간신히 개발을 마무리한 것이다. 갈려나간 개발자들을 위해 묵념

MS가 이렇게까지 다른 모든 것을 버려두면서도 엣지에 집착한 것은 그만큼 웹이 앞으로의 컴퓨팅 환경에서 중요하기 때문이다. 게임을 제외하고 지금 사용하는 데스크톱에 깔려 있는 프로그램이 몇 개인지 세어 보면 우리가 생각보다 프로그램에 대한 의존도는 낮다는 사실을 알 수 있다. 반면 우리가 브라우저를 켜고 들어가는 사이트의 수는 무궁무진하다. 컴퓨터의 성능이 올라가고 거의 대부분의 컴퓨터가 인터넷에 연결되면서 기존에는 프로그램으로 처리하던 작업의 대부분을 웹으로 처리하게 된 것이다. 모바일도 서서히 이 수순을 밟아가고 있는데, 2-3년 전에는 앱을 따로 만들었을 서비스들이 요즘은 웹에서 모든 것을 처리하거나, 앱을 만든다고 하더라도 웹 기반 앱인 경우를 종종 볼 수 있다. 이처럼 웹은 이미 전통적인 프로그램 중심의 컴퓨팅 환경을 완전히 바꾸어 놓았지만, MS는 이 환경에서 뒤쳐져 있다. 인터넷 붐을 타고 만들어져 웹을 꽉 잡고 있는 구글이나, 웹킷 엔진의 주요 개발자로서 자사 기기들을 통해 웹을 웹킷 중심으로 표준화하는 데에 큰 기여를 한 애플에 비해, MS는 도태된 API에 발목이 잡혀 잦은 렌더링 버그를 일으키는 인터넷 익스플로러를 붙잡고 있는 상황이었다. 이 현상은 특히 모바일 버전에서 더욱 심각해서, 크롬이나 사파리에서 아무 문제가 없던 사이트가 IE에서는 깨져 보이는 상황은 여전히 비일비재하며, 새로운 웹 기능을 추가하는 속도 역시 느린 감이 있었다.

엣지의 가장 놀라운 점은 IE7 이래로 MS가 개선하려고 했던 거의 모든 문제들을 넉넉히 잡아도 1년 반에서 2년이라는 지극히 짧은 시간 안에 해결했다는 것이다.역시 문제를 고치는것보다 갈아엎어서 새로 만드는게 낫다 한글 입력기 버그와 같이 IE의 오래된 버그들 뿐만 아니라 자잘한 렌더링 버그들 역시 많이 사라졌으며, 더욱 놀라운 점은 파이어폭스나 크롬보다도 속도가 빨라졌다는 점이다. IE 시절처럼 벤치 성능은 상대적으로 별로지만 플러그인 많이 깔린 크롬이나 파이어폭스보다 체감 성능이 빠르다는 식으로 조건이 붙거나 하는 게 아니고, 수치로 검증이 가능한 형태로 빠르다. 벤치 돌려서 확인해보자. MS도 본격 벤치딸에 맛을 들였다. 사실 누구나 자사 벤치에서는 자기가 제일 빠르다고 하지만 이러한 개선사항들은 특히 데스크톱보다도 모바일에서 두드러지는데, 모바일 웹 표기에 쥐약이었던 모바일 IE11과는 달리 뭘 던져줘도 정확하게 보여준다. 엣지는 데스크톱과 모바일을 막론하고 웹 중심으로 개편되고 있는 웹 환경에서 MS가 뒤쳐지지 않도록 해 줄 가장 중요한 도구다.

3.3 인터넷 익스플로러와의 관계

앞서 살펴본 바와 같이 엣지는 파이어폭스나 크롬과 같은 선상에 있는 완전히 새로운 브라우저이기 때문에, 액티브X로 떡칠되어 있는 온라인 뱅킹이나 인강 등의 서비스를 전혀 사용할 수 없다. 그렇다면 MS는 이로 인한 호환성 문제를 어떻게 해결했을까?

MS는 원래 엣지를 두 개의 엔진으로 돌리려고 하고 있었다. 대부분의 사이트는 새로 만든 EdgeHTML 엔진으로 보여주되, IE 레거시 코드를 필요로 하는 사이트들은 한정적으로 IE11의 엔진을 사용하는 방식이었다. 하지만 이렇게 하면 엣지가 나온다고 해도 레거시 코드로 그대로 돌아가니까 낡은 사이트들의 운영자들이 사이트를 갈아엎을 생각을 하지 않게 될 수밖에 없었고, 자동으로 EdgeHTML과 MSHTML을 오가게 하는 데에도 문제가 있어서, 결국에는 아래 그림에서처럼 엣지는 IE와 완전히 분리되게 되었다. 실제로 엣지를 써보면 이게 한국 사용자 입장에서 얼마나 답답하고 속터지는 결과를 가져왔을지 알 수 있다. 국내에서 들어가는 웹페이지들의 80%가 호환성 리스트에 올라와 있기 때문이다. 기껏 새 엔진 만들어놓고 IE11로 브라우징을 하게 될 뻔했다.

때문에 엣지로 인한 호환성 문제는 엣지와 별개로 IE11을 남겨두는 방식으로 상당히 간단하게 해결되었다. 아직 익스플로러의 구식 코드를 필요로 하는 사이트가 많고, 이런 사이트들이 많아질수록 호환성 구리다고 업그레이드 안할 사람들이 늘어나리라는 걸 MS가 모를리가 없기 때문에, 윈도우 10에서도 IE11은 여전히 있다. 다만 윈도우 10의 기본 브라우저는 엣지이며, IE11은 어디까지나 레거시 프로그램으로서 시작 메뉴의 보조프로그램 폴더로 들어가야 사용할 수 있다고 한다.

따라서 엣지가 차기 웹 브라우저로서 꾸준히 업데이트될 예정인 것과는 달리, 인터넷 익스플로러는 더 이상의 기능 변경 및 개선 없이 보안 패치만 해줄 예정이다. 레거시 지원을 위해 남아있기는 하지만.

여담이지만 Windows 8.1의 IE11과 Windows 10의 IE11은 약간의 차이가 있다. 예를 들어 8.1의 경우 '소스 보기'를 할 때 소스 보기 창이 열리지만, 10의 경우 개발자 도구가 열린다.

3.4 차크라코어

차크라코어 GitHub 페이지

사트야 나델라 체제 이래로 마이크로소프트가 꽤 많은 서비스들을 오픈소스로 전환하기 시작했고, EdgeHTML 엔진 역시 협력사의 커밋을 받는 등 상당히 개방적인 태도를 보이고 있어서, 한동안 EdgeHTML 및 엣지 브라우저가 오픈소스로 전환할 것이라는 관측이 있었다. 엣지 팀에서는 당장은 이들을 오픈소스로 전환할 계획은 없다고 밝혔으나, 결국 2015년 12월 5일에 IE 및 엣지의 자바스크립트 엔진인 차크라를 오픈소스로 전환한다는 발표가 있었다.

아직 윈도우가 오픈소스가 아니기 때문에 엔진에서 일부를 잘라낸 후 "차크라코어"라는 이름을 붙여 공개하기는 했지만, 위의 그림을 보면 사실상 엔진의 대부분을 공개했다. 브라우저 및 유니버설 윈도우 플랫폼 관련 부분 및 구형 API의 연결 부분만 잘라냈을 뿐, 브라우저의 내부 구조 및 여러 활용 방법과 관련이 있는 대부분의 API들이 전부 공개되었기 때문이다. 2016년 1월 현재 우선 과제 중 하나는 무려 리눅스 포팅으로, 우분투 리눅스 15.04 x64 버전에 차크라코어를 옮기는 것을 목적으로 하고 있다.

본인의 개발 실력과 영어 능력이 뒷받침 된다는 전제 하에 .NET과 함께 좋은 마이크로소프트 입사 도구라는 말이 있다. 비교적 새롭게 오픈 소스로 공개된 기획이기 때문에 손을 댈 여지도 많고, 개발 커뮤니티의 분위기 역시 비교적 우호적이기 때문에, 꾸준하게 의미 있는 커밋을 할 수 있다면 엣지 팀에서 먼저 관심을 가지고 입사원서도 쓰지 않았는데 스카웃 해 갈 수도 있다는 것이다.

3.5 로고

좌: Microsoft Internet Explorer의 아이콘	우: Microsoft Edge 의 아이콘

오토바이 헬멧
로고의 경우 이전 브라우저인 인터넷 익스플로러에서 explorer의 첫글자인 'e'를 로고로 사용했던것처럼 이번 엣지에서도 edge의 첫글자인 'e'를 로고문양으로 사용하였다.

근데 자세히 보면 로고에 고리가 없다. 'e', 'D', 'G' 형식이 다 나타나게 한 마이크로소프트의 센스를 볼수 있는데 일단 기본로고 자체가 'e'처럼 생겼고 'D'는 로고의 위 부분에 쉽게 보일수 있으며, 'G'는 파란색이 배경이고 흰색이 글씨라고 생각하면 약간 납작하지만 온전한 모양의 대문자 'G'가 바로 나타난다. 또한 상하좌우반전을 시킬경우 'G' 비슷한 모양으로 보인다.# 다만 후자보단 전자 쪽을 노렸을 가능성이 더 높다.

3.6 대한민국에서의 상황

width=100%

파일명이...? 아닛? 저 로봇 관절같은 로고는?
엣지가 나온 직후의 상황. 마이크로소프트 공식 스토어에서도 엣지로 상품을 구매할 수 없었다. 이후 결제 시스템이 외국과 같이 카드 번호만 입력하는 되는 방식으로 바뀌면서 결제는 가능해졌지만, 대신 외국 호환 카드로만 결제가 가능하게 되었다.

사실 정보가 처음 나올 때만 해도 그렇게 많은 사람들이 긴장하지는 않았다. MS가 웹 표준을 표방하면서 액티브X 그만 쓰라고 개발자들에게 애원하면서도 레거시 지원때문에 하위호환을 포기하지 못한 게 IE9 이래로 벌써 5년째이기 때문이다. 그러다가 2015년 4월이 되어서 서서히 새 브라우저의 윤곽이 드러나면서부터야 사람들도 이번엔 MS가 진심이라는 사실을 뒤늦게 깨달았다. 인사이더 프리뷰 빌드가 하나씩 나올 때마다 엣지와 IE의 차이점은 안드로메다행 급행열차를 타고 벌어져 나갔고, IE의 발전을 바라던 사람들의 관심과 함께 기존 보안 프로그램에 대한 걱정 또한 늘어갔다. 특히 한국 정·재계가 IT 상품의 프리뷰를 먹는 걸로 아는지라 걱정이 뒤집힐 확률은 0에 가까웠다. 원래 프리뷰라는 건 신상품이 이런 방향으로 나올 예정이니 미리 준비(개발자)하거나 경험(얼리어답터)하라는 의미로 뿌리는 것이다!

2015년 6월, 아니나 다를까 이번에도 똑같은 IE일줄만 알고 나중에 기존 방식에서 코드만 좀 바꿀 생각 하고 뒷짐 지던 사람들이 뒤늦게 사태를 파악하고 충격과 공포에 빠지기 시작했다. 특히 오랜 경고에도 불구하고 끝내 액티브X를 비롯한 비표준 솔루션을 버리지 못한 은행 보안업계 측에서는 윈도우 10 발매를 한 달 앞두고 나서야 뒤늦게 당황하고 있다. 그리고 이에 맞춰 MS가 횡포(...)를 부린다고 소설을 쓰는 기레기들도 출현하기 시작했다. 아카이브 당연하게도 멍청하지 않은 네티즌은 정부와 기자를 비난하고 있다. 심지어 공공기관 사이트에서 멀쩡히 출시일까지 발표한 윈도우 10 업그레이드 예약을 취소하라는 글을 올리기도 했다. 엄살을 부린다고 하기에는 무리가 있는 것이(따지고 보면 사실상 전부 자업자득이라 동정의 여지가 전혀 없다), 엣지의 발매를 앞둔 보안업계의 상황은 실제로 전례 없이 심각하다. 2015년 9월부터 구글 크롬 역시 현재 제한적으로 지원하고있는 NPAPI 플러그인 지원을 중단하기 때문이다. 이렇게 되면 윈도우 10 사용자들은 굉장히 곤란한 처지에 놓이게 된다. 엣지에서는 기존 플러그인이 작동하지 않으니 크롬을 사용하라고 할 수도 없는 일이고, 바탕화면에서는 제대로 보이지도 않아서 보조프로그램까지 들어가거나 엣지까지 한번 들어가서 열어야 하는 IE11을 통해 인터넷 뱅킹을 사용하는 방법을 일일히 알려줘야 하는 판이다. 컴퓨터에 능숙하지 않은 대부분의 사용자들에게는 엄청나게 불편할 수밖에 없다. MS와 구글 양 사 모두 진작부터 경고하던 상황이라 자업자득이긴 하지만... 여기에 더해서 2015년도 하반기의 어도비 플래시의 허점을 통한 랜섬웨어 감염 사태까지 겹쳐서 대한민국의 인터넷 환경은 그야말로 혼돈! 파괴! 망가! 상태.

보안 업계의 회담 내용을 보면 적어도 일부 기업 및 기관에서는 장기적으로는 모든 보안을 HTML5로 해결할 계획이 있는 듯. 이러한 전환 과정은 굳이 엣지와 NPAPI 폐기 같은 악재들이 겹치지 않아도 진작에 밟았어야 할 과정인데, 브라우저 내에서 모든 민감한 보안 업무를 처리해버리면 사용자도 편하고 기업 측에서도 돈도 적게 든다. 굳이 앱이나 플러그인을 만들 필요 없이, 엣지 뿐만이 아니라 크롬, 파이어폭스, 사파리, 심지어 IE11에서도 한 번에 모든 것을 해결할 수 있기 때문이다. 하지만 어떤 사정이 얽혀있든 간에 국내 기업들은 이런 가장 편한 방식을 진작에 시행하지 못했고, 결국 일러도 2015년 말까지는 IE11을 노인학대할 판이다. 포기 안 하는 이유 중 하나가 실시간 이체 때문이다. 즉 이것까지 잡고 가려면 금융업계에 대격변이 곧 일어날 것이라는 소리다. 그런데 실시간 이체는 뱅크월렛카카오로도 되지 않나?(뱅크월렛카카오는 별도의 앱을 통해서 해결한 경우다) 윈도우에서도 별도의 앱을 만들어서 하는 방법으로 하면 해결이 가능하다. 현재는 웹 브라우저기반으로 실시간 이체를 하게 하기 위해서 보안위험이 오히려 높은플러그인을 사용 하는 것이다. 심지어 IE8 노인학대는 국가기관에서도 한다! NEIS가 IE7/8만 지원하기 때문에 국내 모든 초, 중, 고등학교와 교육청은 꼼짝없이 Windows 7 + IE8 크리현재는 NEIS 및 업무관리 시스템, 에듀파인 등 대부분의 시스템이 IE11과 호환이 된다(물론 ActiveX 플러그인을 사용하므로 엣지와는 호환이 안 됨).

그리고... 많은 사람들이 예견했다시피 플러그인은 중단기적으로는 포기하지 않는 계획이 사실로 다가왔다. KISA의 보도자료에서 언젠가는 HTML5로 전환하도록 지금부터 업체를 선정하되 2015년 10월까지 모든 ActiveX 플러그인을 exe 플러그인으로 전환하여 12월부터 쭉 사용하겠다고 했는데, 제목부터 마치 곧 HTML5로 전환할 듯이 낚시를 걸어왔으니 미래는 안 봐도 뻔하다.

그런데, 2015년 8월 말, 국민은행이 최초로 플러그인을 일체 쓰지 않는 인터넷 뱅킹을 열었다!오오 국민은행 오오. 문제는 엣지나 크롬이 아니면 이 뱅킹을 못쓰도록 UA를 가린다는 것. 2015년 9월 현재까지 국민은행만이 웹표준을 지키면서도 웹상에서 보안키보드와 공인인증서를 구현했는데, 사실 이렇게 되는 게 원래 맞는 것이다. 이제 국민은행 계좌를 잔뜩 만들어 주면 다른 은행들도 따라할 것이니 국민은행을 쓰자

KEB하나은행의 경우 엣지 대응 업데이트를 하였으나 EXE 기반으로 업데이트가 되었다.망했어요 게다가 이 버전에서는 exe의 기능이 최소화되고 브라우저와 독립적으로 돌아가게 되면서 가상키보드가 의무화되었다. 덕분에 엣지에서는 플러그인은 플러그인대로 설치하고 물리키보드는 물리키보드대로 쓰지 못하고 무조건 마우스로 화상키보드 하나하나 클릭해야하는 헬게이트 확정.

이 외에도 NEIS도 대응이 안 되어 있는데, Adobe Air가 플래시기반이라서 그런 것인지 e교과서 다운로드가 엣지에서도(!)가능하다.

파일:Edge ps.jpg
레드스톤 이전까지는 '익스플로러에 최적화'된 사이트를 접속하려고 하면 IE11로 연결하라는 메시지가 표출되었지만, # 하지만 아래의 'Microsoft Edge에서 계속하기'를 클릭하면 대부분 정상적으로 접속된다. 이게 귀찮다면 주소창에 about:flags를 입력 후 개발자 설정의 Microsoft 호환성 목록 사용을 체크 해제하면 더 이상 IE로 연결하라는 메시지가 뜨지 않는 식으로 엣지에서도 웬만한 이용은 가능했다. 네이버나 다음 같은 경우에는 경고문만 무시하면 사실상 별 문제가 없는 수준이기도 하였고.

파일:Edgebrowserredstone1.png
그러나, 레드스톤 업데이트 이후로는, 여전히 구식 IE에 최적화된 사이트들은 아예 엣지로 접근할수조차 없게 되었다. 'Microsoft Edge에서 계속하기' 버튼이 빠지고 무조건 익스플로러를 대신 키는 버튼만 남은 것. 그나마, 레드스톤 업데이트 첫날인 2016년 8월 03일 시점에는 대부분의 국내 사이트들도 엣지에서 웬만하면 이용할 수 있게 대응된 상황이지만, 디시인사이드나 네이트 PC버전 사이트 등의 몇몇 큰 사이트들이 엣지에서 접속할수 없게 되었다.

3.6.1 IE 기술지원 상황

2016년 1월 16일에 Windows 7, Windows Server 2008 R2용 Internet Explorer 9의 지원이 종료되었다. 비슷한 시기에 Windows 8의 지원이 중단되었으며, Internet Explorer 10의 지원 역시 중단되었다.

2020년 1월 14일에 Windows 7, Windows Server 2008 R2용 Internet Explorer 11에 대한 지원이 중단되고, Windows 8.1은 연장 지원이 끝날 때 즈음인 2023년에 중단될 예정이다.

3.7 보안

Internet Explorer 11 에서도 10 에 비해 보안에 있어서는 많은 것이 향상되었던 것 처럼 Microsoft 의 최근 몇 년간의 행보는, 이전에 비해 Memory Corruption 류의 취약점을 이용하는 해킹에 대한 방어도 꽤나 적극적으로 하는 것을 보여주고 있다. 이번 Edge 브라우저에서도 역시 새로운 보안 기능이 많이 추가되었다. 아래의 내용들은 모두 여기 에서 공식적으로 발표된 내용에 기반한 것이다.

3.7.1 해킹 방어 기능

3.7.1.1 ActiveX를 포함한 각종 레거시 기술들의 지원 제거

이 문서에서도 줄기차게 언급되고 있고, 위 출처에서도 가장 먼저 나오는 내용인 만큼 그 중요성이 어느 정도인지는 굳이 얘기할 필요가 없을 것이다. 정확히 말하자면, 단지 ActiveX의 제거가 아니라 VML(Vector Markup Language), VBScript, BHO(Browser Helper Objects), ActiveX를 모두 제거한다는 것이다. ActiveX의 경우, 이를 제거하는 대신 더 보안성이 향상되고 HTML/자바스크립트 기반의 다른 확장 기능 모델을 추가한다는 내용이다. 아직 발표되지는 않았으나 오래 안가서 소개될 것이라 생각된다.

이는 IE에서만 지원하는 오래된 것들을 모두 제거하고, 보안성에 있어서도 문제가 되어 왔던 것들을 제거함으로서 상당히 큰 발전이라고 할 수 있다. 구글의 경우에도 NaCl(Native Client) 등의 고급 기술을 개발해서 샌드박스 내에서 서드파티 바이너리(확장기능 등)를 실행하는 것을 어렵사리 구현하고 있는데, ActiveX와 같이 아무런 부가적인 보안 요소 없이 그대로 로컬 액세스 권한을 주는 것은 지금 시대에서는 심각하게 뒤떨어진 것이다. 이를 마이크로소프트도 예전부터 인식하고 있었으나 호환성으로 인해 쉽게 제거하지 못하였는데 이제 엣지라는 별개의 브라우저로 개발하게 되면서 이를 모두 제거할 수 있는 일종의 기회를 얻었다고 볼 수 있다.

3.7.1.2 유니버설 윈도우 앱

엣지는 유니버설 윈도우 앱 기반으로 개발되었다. 이는 유니버설 윈도우 플랫폼(UWP) 기반으로 동작하는 애플리케이션으로, Windows 8에서 처음 소개된 것이다. 이름 그대로 모바일 기기와 데스크톱 PC 등을 모두 아우르는 앱을 개발하는 것인데, 엣지는 이 유니버설 앱으로 개발되었다. 언뜻 보면 이는 보안과는 별 관계는 없어 보이지만, 유니버설 윈도우 앱의 경우 애플리케이션에서 구현을 따로 하지 않아도 기본적으로 적용되는 보안 모델이 별개로 존재한다. 쉽게 말해서 마치 OS X 처럼 애플리케이션이 동작할 때 기본으로 샌드박스가 한 층 추가된다고 보면 된다. 실제로 엣지를 실행하고 처음 프로세스를 확인해 보면 Integrity Level이 AppContainer인 것을 볼 수 있다. 반면 인터넷 익스플로러의 경우 그냥 일반적인 프로그램이기 때문에 처음 실행되는 Broker 프로세서의 Integrity Level은 보통의 기본 유저 권한인 Medium이다.

다만 실제로 이로 인한 보안성을 이렇게 간단하게 나타낼 수는 없고, 무조건 보안성이 강화되었다고도 볼 수 없다. 현재 IE11 전환을 위한 것으로 추측되는 Medium 권한의 browser_broker.exe라는 프로세스가 따로 동작하고 있고 기존에 Broker(처음 실행한 프로세스)의 자식 프로세스로 Renderer 프로세스가 생성되었던 것과 달리 엣지의 경우 렌더러 프로세스가 RuntimeBroker.exe라는 Medium Integrity Level을 가지는 새로운 프로세스의 자식으로 생성된다. 아예 렌더링을 위한 프로세스는 프로그램 자체가 분리되어 MicrosoftEdgeCP.exe라는 이름으로 존재한다.(어찌 됐든 브라우저라는 프로그램은 로컬 리소스에 액세스가 필요하다. 파일을 다운로드해서 저장한다든지......) 그리고 MicrosoftEdgeCP.exe(Content Process)에서 웹 서버와의 소켓 통신을 개별적으로 직접 하고 있는 모습을 볼 수 있다. 이쪽 부분은 추후 구조가 자세히 판명되면 추가바람.

여하튼 이런 것이 가능한 이유는 위에서 언급했다시피 유니버설 윈도우 앱은 기본적으로 유니버설 윈도우 플랫폼이라는 플랫폼 위에서 동작하도록 되어 있기 때문이다. OS X의 경우에도 순수 커널 아래에서 동작하는 바이너리들이 샌드박스 내에서 동작하는 것이 아니라, XNU 커널 위에 또 다른 플랫폼을 쌓아 올리고, 이 플랫폼이 샌드박스를 구현하고, 개발자들은 그 새로운 플랫폼 대상으로 애플리케이션을 개발하는 식으로 하기 때문에 가능한 것이다. 즉 샌드박스 구조에 비유하면 UWP와 같은 플랫폼이 알아서 Broker 역할을 하는 것이다. 다만 OS X는 예전부터 이렇게 동작하는 것이 기본 옵션이었고 개발자들도 오랫동안 그렇게 개발해왔기 때문에 거의 모든 애플리케이션이 이렇게 동작하고 있지만, 윈도우는 윈도우 8에 와서야 소개했기 때문에 아직 적용이 늦다는 차이 뿐이다. 물론 아직까지도 윈도우는 이렇게 개발하는 것이 기본이 아니기 때문에 대부분의 응용 프로그램은 샌드박스 내에서 안전하게 동작하는 것이 아니라 지금까지처럼 '날것'으로 실행될 것이다.

3.7.1.3 AppContainer 샌드박스

인터넷 익스플로러 7에서 보호 모드라는 보안 모델을 소개했다. 이는 기본적으로 Integrity Level이라는 Windows의 새로운 권한 모델을 기반으로 하는 것인데, Windows XP 이하의 운영체제에서는 이런 것이 존재하지 않았고 Windows Vista에서 처음으로 소개되었다. 따라서 정확히는 Vista 이상(더 정확히는 UAC가 켜져 있을 때만)에서 동작하는 인터넷 익스플로러 7부터 보호모드가 적용되었다. 이는 샌드박스 모델인데, 브라우저가 페이지를 렌더링하는 데에 쓰는 프로세스를 따로 분리하여 이 분리한 프로세스의 권한을 낮게 주는 것이라고 보면 된다. 즉 제 3자가 만든 HTML 페이지에서는 IE의 취약점을 이용하는 악의적인 자바스크립트 코드 등이 있을 수 있는데, 이를 실행하면서 취약점이 발생하기 때문에 이런 렌더링 관련 작업은 따로 자식 프로세스를 생성하여 그 안에서 처리한다. 그러면 만약 여기서 취약점이 발생한다고 해도 이 프로세스 자체로는 권한이 낮기 때문에, 시스템의 중요 파일 등에 접근을 할 수 없으며 더 높은 Integrity Level을 가지는 프로세스에 (악성)코드 삽입 등을 하는 것도 불가능하며 그 외에도 시스템의 다양한 리소스들에 접근을 할 수 없다. 따라서 취약점으로 임의 코드 실행을 할 수 있다고 해도 해커가 시스템에 해를 끼치는 것에 한계가 있다.

이러한 보호 모드는 IE10부터 향상된 보호 모드(EPM)로 다른 보안 기능도 추가하면서 더욱 발전하였고 지금까지 계속 적용되어 왔다. Windows 8에서는 위에서 언급한 Integrity Level의 종류(System, High, Medium, Low, Untrusted)에 AppContainer를 하나 더 추가하였는데, 이는 이름에서 알 수 있다시피 앱으로 개발된 애플리케이션들이 기본으로 이 권한으로 동작한다. EPM은 Windows 8이상에서 브라우저가 동작할 때 렌더링 프로세스를 AppContainer 권한으로 실행하도록 한다.
다만 이는 실제로 브라우저가 App으로 개발되어 동작하는 것과는 다르다. App으로 개발한 애플리케이션은 그냥 실행하면 권한 자체가 기본적으로 AppContainer가 되고 App 플랫폼 내의 샌드박스에서 기본적으로 동작한다. 그러나 이 경우는 브라우저를 실행하면 처음 실행한 프로세스(Broker)의 Integrity Level은 그대로 Medium이다. 따라서 이는 App 플랫폼에 의한 것이 아닌 IE가 직접 구현한 샌드박스 모델에서 AppContainer 권한을 사용한 것 뿐이다.

즉 정확히는 이는 이미 IE10부터 적용이 되어 있었으나, 엣지에서 변경된 점은 IE10/11에서 EPM이 옵션으로 되어 있었기 때문에 기본값이 아니었던 점을 바꾸어 이제는 무조건 기본으로 적용하도록 바뀌었다. 당연히 이로 인해 보안성은 훨씬 더 강화되었다. 지금까지 이를 기본값으로 하지 못한 이유는 이 샌드박스라는 것은 치명적인 단점(?)으로 ActiveX와 같은 기존의 플러그인 실행에 문제가 생기기 때문이다. 샌드박스는 로컬 리소스에 액세스하는 것을 제한하는 기능인 반면 ActiveX는 로컬 리소스에 거의 제한 없이 액세스할 수 있는 기능이다. 따라서 페이지를 샌드박스 내에서 실행하는 경우 ActiveX와 같은 플러그인이 정상적으로 실행될 수가 없다. 다만 이는 곧 EPM의 적용은 ActiveX의 원천 차단을 의미하기 때문에 마이크로소프트에서도 당연히 이를 해결하기 위해 샌드박스와 호환이 되는(로컬 파일에 액세스하지 않는다거나) ActiveX 플러그인의 경우 EPM 내에서 실행을 할 수 있도록 하는 새로운 기능을 추가했었다. 물론 이는 기존의 ActiveX 플러그인을 그대로 사용할 수 있다는 것은 아니고, 다시 빌드해야 한다는 단점은 있었으나 Flash 등의 중요 플러그인은 이런식으로 호환되게 사용할 수 있었다. 물론 대부분의 ActiveX 플러그인은 로컬 리소스에 액세스해야하는 경우가 대부분이기 때문에 호환되게 할 수 없다.

엣지는 ActiveX와 같은 플러그인을 아예 제거해버렸기 때문에 샌드박스를 강제 적용하는 것에 아무런 문제가 없고, 따라서 이렇게 기본으로 지원을 하게 된 것이다. 이는 ActiveX라는 플러그인의 자체적인 보안과는 별개로, 이렇게 서드파티 바이너리를 아무런 보안 없이 네이티브로 실행하는 기능을 브라우저에서 제거해야하는 또 다른 이유였다고 할 수 있다. PWN2OWN과 같은 대회에서도 브라우저를 해킹할 때 샌드박스도 우회해야 해킹을 한 것으로 인정하는 만큼 샌드박스라는 보안 모델의 중요성은 이루 말할 수 없으며, 심지어 Adobe Reader 같은 소프트웨어도 자체적으로 샌드박스를 구현하고 있을 정도이다.

3.7.1.4 64비트 프로세스

인터넷 익스플로러도 64비트 운영체제에서 64비트로 동작하는 것을 지원하였으나, 옵션으로 64비트 프로세스 사용 설정을 따로 해야 하는 경우가 있었다. 엣지는 64비트 운영체제인 경우 기본적으로 64비트 프로세스로 동작을 하게 되어 보안성이 향상되었다. 64비트인 경우 보안에 있어서 잇점이 되는 부분은 ASLR(Address Space Layout Randomization)에 있어서 32비트보다 훨씬 더 큰 entropy를 가지는 랜덤성이 가능하다는 점이다. 이는 애플리케이션이 적재되는 Base Address에 랜덤성을 부여하는 기능으로, Windows Vista에서 처음 소개된 이후로 exe의 옵션으로 설정할 수 있던 시대를 지나 지금은 강제로 적용하고 있다.

기본적으로 Windows에서 32비트 프로세스의 경우 프로세스 주소 공간이 2^32(0x00000000 ~ 0xFFFFFFFF)로 제한이 되고, 여기서 커널 공간을 제외하면 0x00000000 ~ 0x7FFFFFFF )까지의 메모리에만 액세스가 가능하다.(※이는 PAE 등의 기능으로 달라질 수 있으나 기본 설정을 기준으로 설명하였다.) 즉 32비트 주소 공간에서는 주소가 위치할 수 있는 경우의 수도 그 만큼 작으므로 추측이 비교적 쉽다. 그러나 64비트의 경우 2^64 라는 어마어마한 주소 공간을 사용할 수 있고(물론 x86_64(x64) 아키텍쳐에서는 2^48 만 사용하지만 이 역시 32비트에 비하면 엄청나다.) 이는 사실상 추측이 불가능한 entropy로 ASLR을 적용할 수 있다.

3.7.2 메모리 손상 방어

3.7.2.1 MemGC

MemGC의 경우 정확히는 엣지만의 보안 기능이라기 보다 Windows 10에서 동작하는 엣지와 IE에 대한 보안 기능이기 때문에 이 문단에 넣기는 조금 애매하긴 하지만 일단 엣지가 나옴과 동시에 새로 소개된 보안 기능이기 때문에 여기서 간단하게만 소개를 하도록 한다. 좀 더 자세한 내용은 여기와 좀더 쉽게 잘 설명된 여기를 참고하자.

이것은 기능이라기 보다는 메모리 관리와 관련한 동작 알고리즘의 추가/변경이라고 하는 것이 더 적절하다. 이것은 Use-After-Free 공격을 방어하기 위한 기법이며, 다른 종류의 버그(Buffer Overflow, Out-of-bound Read/Write, etc..)와는 별 상관이 없는 내용이다. 현재 가장 활발하게 발견되고 이용되는 취약점이 대부분 Use-After-Free 취약점이기 때문에 마이크로소프트는 IE11부터 이 공격에 대해 적극적인 방어 기법을 선보여왔다. 대표적으로 과거 IE11에서 이미 적용된 Isolated Heap, Memory Protector 등을 예로 들 수 있다. MemGC의 경우 과거의 Memory Protector 를 한 단계 더 강화한 것으로 보면 된다. 그러니까 즉 MemGC는 엄밀히 말해서 전혀 다른 새로운 보호 기법이라기 보다 Memory Protector 를 대체할 수 있는 발전된 기법이다. 또한 레지스트리 설정값 변경으로 과거 Memory Protector를 사용할지 MemGC를 사용할지 선택도 가능하다.(물론 일반 사용자는 건드릴 필요가 전혀 없다.)

MemGC는 Memory Garbage Collector의 약자이고 이름 그대로 기존 IE의 일부 메모리 관리자를 보안적인 측면에서 좀 더 개선한 것이다. 할당/해제 과정과 가비지 컬렉션등에서 기존의 Memory Protector에서 사용하던 기법들보다 한 단계 더 보안성을 강화하였다. 좀 더 기술적으로 자세한 내용은 위의 링크들을 참조하면 된다. 이러한 내용들은 모두 마이크로소프트가 Memory Corruption 류의 버그에 적극적으로 대응을 할 의지가 IE11에 이어 여전히 현재 진행형이라는 점을 시사한다.

3.7.2.2 제어 흐름 보호

Visual Studio 2015에 적용된 기능으로, 컴파일시 포인터 기반 간접 점프를 확인하는 기능이다. 메모리 손상 취약점의 목표는 해커가 원래 프로그램 코드 중 간접 점프 코드를 통해 자신이 원하는 새로 넣은 코드로 점프해 악성코드를 실행하는 것이다. 제어 흐름 보호는 이런 점프 목적지를 원래 코드 함수 시작점으로 제한해 메모리 손상 취약점을 방어해 해커의 의도를 무력화시키려는 것이다. 엣지를 컴파일할 때 이 기능을 넣고 컴파일했다고 한다. IE에도 적용된 기능이다.

3.7.3 바이너리 주입 보호

3.7.3.1 기존 브라우저의 문제점

해커가 브라우저에 동적 라이브러리를 집어넣어 브라우저의 보안 기능을 우회하고 브라우저에 추가적인 광고를 띄우는 경우가 있다. 이를 통해 추가적인 광고 등을 넣어 이득을 보는 경우가 있다. 직접 브라우저 확장 프로그램 설치를 통해 동적 라이브러리를 주입하거나 아니면 위의 메모리 손상 취약점을 통해 강제로 주입할 수 있다. 이것이 가능한 이유는 브라우저에서 확장 프로그램을 로드할 때 동적 라이브러리의 인증 여부를 검사하지 않기 때문이다.

3.7.3.2 모듈 코드 통합 강제 기능

그래서 EdgeHTML 13부터 엣지에서 로드하는 모든 동적 라이브러리는 WHQL 인증을 받아야 한다. 여러분이 설치하는 거의 대부분의 드라이버는 마이크로소프트에서 WHQL 인증을 받는데, 이는 대부분 드라이버가 관리자 권한을 가지기 때문이다. 이것을 똑같이 브라우저 동적 라이브러리에도 적용시킨다고 보면 된다. 엣지는 WHQL 인증을 받은 라이브러리만 로드하고, 아닌 라이브러리들은 막는다. 이 기능을 프로세스 단에서 할 수도 있고, 커널 단에서 할 수 있는데, 프로세스 단에서 하면 프로세스가 감염됐을 때 기능이 작동하지 않을 수 있다는 단점이 있다. 그래서 윈도우 커널 단에서 라이브러리를 확인해 프로세스가 감염되어도 커널에서 프로세스를 강제로 꺼버릴 수 있고, 프로세스에서 커널에 접근하기도 힘들어 이 기능을 유지할 수 있다.

3.7.4 스마트스크린 필터를 통한 드라이브-바이 다운로드 공격 방어

3.7.4.1 드라이브 바이 다운로드 공격

스마트스크린 필터는 URL 평판과 앱 평판을 기반하여 악성 URL을 차단하고, 악성 프로그램을 받지 못하게 하는 기능이다. 그래서 많은 악성 웹사이트에 사용자들의 접근을 막아 브라우저를 안전하게 한 기능이다. 그래서 드라이브-바이 다운로드(Drive-By download) 공격이라는 것이 생겼는데, 이는 기존의 잘 알려진 웹사이트를 해킹해 자신의 악성코드를 사이트에 올리고, 그 웹사이트에 접속한 사용자들을 취약점을 통해 감염시키는 공격이다. 이렇게 하면 평판 기반 방어는 그 사이트가 잘 알려진 웹사이트이기 때문에 성공적으로 방어할 수 없다. 이런 드라이브-바이 다운로드 공격은 보통 취약점 킷(익스플로잇 킷;여러 취약점들을 동시에 노리는 코드)을 통해 이뤄지며, 많은 사용자들이 모든 프로그램을 제때 업데이트하지 않기 때문에 성공할 확률이 높다. 특히 현재 추세가 아래와 같이 이런 취약점 킷 공격이 많아지고 있는 추세라 사용자들이 더욱 위험해질 수 있다.

그래서 윈도우 디펜더, 엣지, 인터넷 익스플로러, 빙, EMET 등의 툴들을 통해 수집된 악성 신호들을 실시간으로 스마트스크린 필터에 적용해 이런 취약점 킷 공격을 방어하는 것이다. 실제로, 이 기능을 통해 HanJuan EK라는 취약점 킷이 디펜더와 EMET에 잡히자 마자 스마트스크린 필터에 등록되고, 조사를 통해 이 취약점 킷이 어도비 플래시 플레이어 제로데이 취약점을 이용한다는 것을 알아냈다. 이 취약점은 CVE-2015-0313로 명명되었다.

3.7.4.2 스마트스크린 필터 개선

이런 드라이브-바이 다운로드 공격을 방어하기 위해서는 이런 공격들이 웹페이지가 렌더링 되기 전에 탐지되고 차단되어야 한다. 이는 브라우저 성능에도 미칠 수 있기 때문에, 스마트스크린 필터는 작은 캐쉬 파일에 악성 파일을 기록하고, 그걸 기반으로 드라이브-바이 다운로드 공격을 방어한다. 새로운 악성코드가 계속 나오기 때문에, 당연히 이 캐쉬 파일은 주기적으로 업데이트된다.
URL이 악성으로 판명되면 다음과 같이 대문짝만하게 웹페이지가 위험하다고 알려준다.

레드스크린인줄 알았다 무서워

또한, 프레임 단위 경고 기능을 추가해, 위험한 광고 프레임만 차단하고 나머지 정상적인 부분들은 렌더링하는 기능도 추가했다. 그래서 일부만 문제가 있어도 전체 내용을 보지 못하던 경험을 개선했다고 한다.

만약에 스마트스크린 필터가 오탐했다고 생각되면 자세한 정보 링크를 통해 경고 페이지를 확장해 우회할 수 있지만 추천하지는 않는다. 프레임 단위로 차단되었을 경우에는 안전하지 않은 콘텐츠 뱃지를 눌러서 똑같이 우회할 수 있다. 그리고 기존의 스마트스크린 설정과 컨트롤들(그룹 정책 포함)은 새 드라이브-바이 다운로드 공격 보호 기능을 자동으로 추가했다.

3.7.4.3 신고 기능

스마트스크린 필더가 차단하지 않았지만 웹페이지가 위험하다고 생각되면 다음과 같이 마이크로소프트에 보고할 수 있다.

• 엣지: 자세한 메뉴에 들어가 피드백 보내기를 누르고 안전하지 않은 웹사이트 보고를 선택하면 된다.
• 윈도우 10의 익스 11: 툴 버튼을 누르고, 안전 탭에서 안전하지 않은 웹사이트 보고를 선택하면 된다.

3.7.5 플래시 콘텐츠 자동 일시 정지

안전하고 좋은 성능과 안정적인 브라우저를 제공하기 위해 플래시의 리소스와 전력을 조정했다. 1주년 업데이트부터 웹페이지에서 중요하지 않은 플래시 콘텐츠는 자동으로 일시정지된다.

애니메이션이나 광고같은 주변부 콘텐츠는 유저가 콘텐츠를 재생하도록 클릭을 하지 않는 이상 일시정지된 상태로 있을 것이다. 이로 인해 전체 콘텐츠를 재생하는 것 보다 전력 소모가 감소하고 성능이 향상될 것이다. 비디오나 게임같은 페이지 중심에 있는 콘텐츠는 일시정지되지 않는다.

또한 웹 표준의 기능을 더더욱 강화시켜 더 안전하고 성능이 향상된 경험을 플래시 없이 사이트들이 제공할 수 있도록 노력한다고 한다. 웹 표준을 사용할 때 배터리 수명이 늘어나고 CPU 부하와 메모리 소모가 감소한다고 한다. 개발자들은 웹표준을 통해 모든 브라우저와 모바일 같은 플래시를 쓸 수 없는 장치에서 사이트들이 잘 작동하게 만들 수 있다.

3.7.6 Windows Hello 지원

빌드 2016에서 마이크로소프트 엣지가 전 세계에서 처음으로 안전하고 쉽게 웹에서 인증을 할 수 있게 Windows Hello를 지원하는 브라우저가 될 것이라고 발표되었다. 이는 웹 인증 (이전에는 FIDO 2.0 Web API로 불림)의 초기 구현에 의해 작동하고, FIDO Alliance와 W3C 웹 인증 작업 그룹에서 이들 API를 표준화하기 위해 작업하고 있다고 한다. 테스트 드라이브 데모에서 이를 체험해볼 수 있다.

기존 패스워드에 많은 문제점들이 있는데, 많은 사람들이 모든 사이트들에 대해 강력하고 전부 다 다른 패스워드를 쓰지 않는다는 것이다. 보통 기억하기 쉽게 만들거나 모든 계정들에 대해 같은 패스워드를 사용한다. 또, 패스워드를 바꾸더라도 "123456"이나 "password" 같은 쉬운걸로 바꾸는 경우가 많다. 해커들은 보통 사회 공학적 기법, 피싱, 키로깅 기법으로 개인 컴퓨터에서 패스워드를 빼내게나, 패스워드를 저장한 사이트를 장악해서 빼내는 경우가 많다. 만약에 패스워드가 여러 사이트에서 동시에 사용된다면, 한 계정만 해킹해도 다른 계정들도 위험해진다.

하지만 이 기술을 통해 인증을 위해 유저가 더 이상 패스워드를 기억하지 않아도 되고, 서버가 저장하지 않아도 된다. 웹 인증과 Windows Hello를 결합해서 생체인식 기술과 비대칭 암호화를 통해 구현한다고 한다. 유저를 인증하기 위해서, 서버가 브라우저에 평문 텍스트 문구을 먼저 보낸다. 엣지가 유저를 Windows Hello로 식별할 수 있다면, 시스템이 유저에 할당된 개인키로 문구에 서명하고 인증서를 서버로 보낸다. 만약에 서버가 이 인증서를 공개 키로 인증서를 확인할 수 있다면, 유저에서 온 것을 확인할 수 있고, 유저를 안전하게 인증할 수 있다.

이 키들은 강력한 계정들을 제공할 뿐만 아니라 추측할 수 없고, 원본 외에서 다시 사용될 수 없다. 공개키는 그 자체로 의미 없고, 개인키는 공유되지 않기 때문이다. Windows Hello로 더 좋은 유저 경험을 제공할 뿐만 아니라, 패스워드 추측, 피싱, 키로깅, 서버 데이터베이스 공격으로 계정을 탈취할 수 없다.

3.7.6.1 웹 인증: 패스워드 없이 작동하고, 2단계 인증 지원

FIDO Alliance에 참가해 웹에서 패스워드를 제거하고 강력한 계정을 생성할 수 있도록 여러 기업들과 같이 작업을 하고 있다고 한다. FIDO Alliance의 주 목표는 이런 인터페이스들을 표준화해, 웹사이트들이 Windows Hello와 다른 생체 인식 기술들을 모들 브라우저에서 사용할 수 있게 하는 것이다. FIDO Alliance는 FIDO 2.0 제안을 W3C에 제출했고, 새로 생긴 웹 인증 작업 그룹은 이들 API를 W3C 웹 인증 표준안에 넣기 위해 이들 API를 표준화하고 있다.

웹 인증 표준안은 다음 2가지 인증 시나리오를 정의하고 있다: 패스워드 없이 인증, 2단계 인증. 패스워드 없이 인증하는 경우는, 유저가 웹페이지에 로그인하기 위해 유저 이름이나 패스워드 없이 - Windows Hello만으로 로그인할 수 있다. 2단계 인증의 경우는, 유저가 유저 이름과 패스워드로 로그인하지만, Windows Hello가 2단계 인증을 해 전체적인 인증을 강력하게 할 수 있다.

전통적인 패스워드 인증은 유저가 패스워드를 생성하고 서버에 알려줘서 서버가 패스워드를 해시화해 저장한다. 유저, 또는 패스워드를 취득한 공걱자는 똑같은 패스워드를 어느 장치에서나 서버에 인증하기 위해 쓸 수 있다. 하지만 웹 인증 표준안은 비대칭 키 인증을 사용한다. 비대칭 키 인증에서는, 유저 컴퓨터가 비밀 키와 공개 키로 구성된 강력한 암호화 키 쌍를 생성해, 공개 키를 서버에 제공하고, 개인 키를 컴퓨터의 TPM 같은 전용 하드웨어에 저장해 컴퓨터에서 다른 곳으로 이동할 수 없게 한다. 이 방식은 클라이언트와 서버 둘 다에 대한 공격을 방어할 수 있다 - 다른 곳에서 공격자가 인증하려는 클라이언트 공격은 성립되지 않고, 서버를 공격해도 공개키 리스트만 얻을 수 있다.

마이크로소프트 엣지는 현재 웹 인증 스펙의 초기 구현을 지원한다 - 사실, 최근 작업안이 업데이트되어 현재 구현을 벗어나있고, 표준안 프로세스를 지나면서 스펙이 계속 변경될 것이다. 그래서 현재 API들은 ms-prefix가 붙어있고, 이들 API들은 미래에 바뀔 가능성이 높다. 그래서 표준안이 만들어질 때까지 API들을 업데이트해 변경점을 제대로 지원할 것이다.

웹 인증 API들은 매우 간단한다 - 두 메서드: window.webauthn.makeCredential와 window.webauthn.getAssertion로 구현된다. 이를 지원하려면 서버와 클라이언트 모두 수정을 해야 한다.

3.7.7 TCP Fast Open, TLS False Start, TLS 1.3

밑에 설명할 TCP Fast Open, TLS False Start, TLS 1.3으로 성능과 보안 두마리 토끼를 다 잡을 수 있다고 한다. TCP Fast Open은 about:flags 설정에서 켤 수 있다. 다만 Adguard와 같은 네트워크 프로그램을 해당 옵션과 병행하여 쓸 경우 높은 확률로 시스템이 다운된다.

3.7.7.1 TLS 1.3으로의 여정

금융 정보 같은 중요한 정보들은 인터넷에서 움직일 때 보안이 충족되어야 하고 안정성이 보장되어야 한다. 웹 상의 보안 네트워크 트래픽 절반 이상이 TLS로 채워져있고, 매일 이 숫자는 늘어나고 있다. 현대적인 암호화 자체는 매우 빼르지만, 페이지 리소스를 가져오기 전에 연결을 활성화하기 위해서 키교환을 해야 한다. 각각의 네트워크 상의 추가적인 교환은 연결을 만드는데 한 "왕복 시간"(RTT) 만큼 느리게 만든다.
현재 표준에서, TCP 위의 TLS는 교환을 위해 서버 사이에 여러 번 왕복(3-RTT)해야 한다 - 첫번째는 TCP, 두번째는 TLS - 처음 HTTP GET 명령 같은 유용한 정보를 처음 보내기 전에 반드시 수행되어야 한다. 이는 사이트가 콘텐츠를 여러 도메인에 나눴을 떄 더 문제가 된다. 대게, 암호화를 하면 페이지 로딩 시간에 수백 밀리초 정도가 추가된다. 연구자들은 250ms 지연도 사용자들이 다른 웹사이트로 넘어가게 만들 수 있다고 한다.

TLS 1.3은 개발자들이 암호화된 콘텐츠를 전달하면서 이런 지연 시간을 제거할 수 있게 한다. 이 뜻은 현대 암호화와 지속적으로 개선되는 TCP 스택을 계속 사용하면서 성능과 보안을 다 충족시킬 수 있다는 것이다. TLS 1.3은 표준화 과정을 밟고 있고, IETF는 2016년 여름에 발표될 것으로 예상가고 있다. 하지만 TLS 1.3 없이도, TCP Fast Open과 TLS False Start 옵션으로 지연 시간을 3-RTT에서 1-RTT로 줄일 수 있다. 페이지 로딩 시간을 50ms만 줄여도 더 나은 웹서핑을 즐길 수 있다는 것을 고려해보면 된다.

3.7.7.2 TCP와 TLS의 전체 핸드 쉐이크

현재 TCP와 TLS 표준은 서버에 3번 왕복해야 한다 (3-RTT). 첫 번쨰 왕복은 TCP 연결 인수를 교환하기 위해 필요하다. 두 번째 왕복에서, 클라이언트와 서버가 연결의 키와 인수를 교환하기 위해 클라이언트 Hello와 서버 Hello로 시작하는 TLS 메시지를 교환한다. 마지막 왕복에서는 TLS 핸드 쉐이크 무결성을 확인하기 위해 클라이언트와 서버 완료 메시지를 교환한다.

3.7.7.3 TLS False Start와 TCP Fast Open으로 1-RTT 지원

TLS False Start 옵션은 클라이언트가 암호화된 데이터를 첫 번째 TLS 왕복 직후에 바로 보낼 수 있다. 이를 통해 TLS 기준 1-RTT, TCP 연결 기준 2-RTT로 줄일 수 있다. 이미 엣지에 강력한 암호화 스위트를 탑재하고 TLS False Start 옵션이 켜져있다.

다음 향상점은 RFC 7413에 정의된 TCP Fast Open 과정에 있다. RFC는 "Fast Open 쿠키"를 포함한 새로운 TCP 옵션을 정의했다. "Fast Open을 사용 가능한" 클라이언트가 처음 서버에 연결하면, 초기 TCP SYN 메시지에 빈 쿠키를 집어넣어서 서버가 응답에 유효한 쿠키를 넣어서 보낼 수 있게 한다. 이수 연결들에서, 클라이언트느 쿠키를 TCP SYN 메시지 안에 넣어서 데이터를 즉시 보낸다. 만약에 서버가 데이터가 무결하다고 인식하면, 데이터를 받고 앱에 보낼 것이다. TCP Fast Open이 켜져 있으면, 연결이 완성되기 전에 데이터를 보내서, 응답이 즉시 돌아올 것이다. TCP Fast Open과 TLS False Start를 조합하면, 최초 TCP 핸드 쉐이크에 키 교환이 동시에 이뤄질 것이다. 이는 HTTP 트래픽이 시작하기 전에 1-RTT만큼만 걸린다는 것을 의미한다.

3.7.7.4 TLS 1.3으로 0-RTT 지원

TCP Fast Open about:flags 설정에서 지원한다. 주소 창에서 about:flags라 치면 TCP Fast Open 설정을 관리할 수 있다. 현재는 기본값으로 꺼져 있고, 더 많은 텔레메트리 데이터를 수집하기 위해 조정할 수 있다고 한다.

다음 단계는 TLS 1.3으로 1-RTT에서 0-RTT로 향상시키는 것이다. 0-RTT를 안전하게 실현하는 것은 어렵다 - 모든 0-RTT 해법들은 클라이언트에서 키와 암호화된 데이터를 서버에서 오는 피드백을 기다리지 않고 바로 보내야 한다. 최소한, 공격자가 메시지를 잡아내고 다시 볼 수 있다는 것이다. 이 뜻은 이 기능은 굉장히 조심스럽게 사용되어야 한다는 것이다. 또한, Hello 메시지에 식별자를 평문 텍스트에 넣어서 개인 정보를 침해하는 방법이나 최초 암호화가 서버 공개키에 의존하는 방법이어서 다음 연결이 위험한 경우 같은 잠재적인 장애물들이 있다. IETF 작업 그룹은 이런 문제들에 대해 의논하고 있고, 그것들이 해결되면 이 기능이 2016년 여름에 구현될 것이고, 표준안은 몇달 뒤에 발표될 것이다.

HTTP 2.0, TLS 1.3, TCP Fast Open, TLS False Start로 엣지에 0-RTT 경험을 전달하고 있다. 또한 상호 운용 가능한 TLS 1.3 솔루션을 제공하기 위해 표준안에 참여하고 있다.

4 장단점들

4.1 장점

• 빠른 브라우징 속도

위에서도 언급되었지만 인터넷 익스플로러 대비 속도가 크게 개선되었다. UI가 완전히 달라진 것에 더해 체감이 가능한 수준의 속도 차이가 나다 보니, 별 관심이 없는 사람들까지도 덕분에 엣지가 기존의 익스플로러와는 다른 것 같다는 사실을 체감하고 있다. 크롬, 파이어폭스, 사파리등의 다른 경쟁 브라우저와 비교해도 속도가 뒤쳐지지 않고, 오히려 앞서는 면도 보여준다. 하지만 구글 크롬이 촉진시킨 웹 브라우저 경쟁덕에 웹브라우저 개발사들은 지금도 피터지게 최적화를 하고 있고, 매 업데이트 마다 벤치마크 순위는 바뀔 수 있는데다가 초창기 크롬처럼 타 브라우저를 압살하는 성능을 지닌것도 아니라서 경쟁 브라우저 대비 큰 장점이라 할 수는 없다. 하지만 기존 IE에 비하면 확실한 장점.

• 여타 브라우저와의 유사성

엣지는 기존 익스플로러를 깡그리 무시하고 웹킷 위주로 만들어진 현대의 웹 환경을 의식하면서 만들어졌다. 그래서 기존에 익스플로러를 사용할 때 종종 깨져 나오던 사이트들 중 상당수가 다른 브라우저를 쓸 때와 같이 정상적으로 보인다. 특히 IE11이 많이 미진했던 모바일에서는 효과가 더욱 크다.

참고로 user-agent가 빌드 10240 64비트 기준으로 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240로 나타난다. (참고로 유저-에이전트 정보는 [1] 에서 확인할 수 있다. 여기서 15년 8월 기준 주요 웹 브라우져의 유저 에이전트를 볼 수 있다.)

• 다양한 편의 기능

웹페이지를 통째로 하드 드라이브, 원노트 또는 원드라이브에 저장하고 그 위에 서피스 프로 등의 장치에서 사용하는 펜으로 필기를 할 수 있는 기능이 있다. MS에서는 이 기능을 엣지의 주력 기능 중 하나로 밀고 있다. 한편 읽기 목록 기능은 기존 윈도우에서도 별도의 앱으로 지원하고 있었고, 다른 OS들도 마찬가지였지만OS X 제외, 엣지는 이 기능을 브라우저 안으로 끌고 들어와서 언제든지 오프라인으로 저장해 읽을 수 있도록 한다. 읽기 모드 또한 다른 브라우저들보다 더 다양한 옵션을 지원한다.

• 코타나 연동

윈도우폰 8.1에서 처음 등장한 코타나가 윈도우 10에 이어 엣지에도 결합되었다! 엣지의 검색창(주소창)에 "날씨" 등 간단한 키워드를 입력하면 코타나가 알아서 검색어를 인식하고 엔터를 누르기도 전에 원하는 정보들을 간략하게 보여주기도 하며, 특정한 단어나 문구를 선택하여 오른쪽 버튼을 누르면 (터치 화면에서는 길게 누르면) "코타나에게 물어보기"가 뜨면서 즉시 원하는 정보를 검색하도록 해 준다.

• 빠른 업데이트

엣지는 비교적 뒤늦게 개발을 시작했음에도 불구하고 빌드가 올라갈 때마다 계속해서 새로운 기능을 추가하면서 개발하고 있는데, 특히 HTML5test 결과가 Redstone 1 애니버서리 업데이트와 함께 제공되는 Edge 14의 경우 파이어폭스 47 기준 456점에 Edge 14는 460점으로 파이어폭스를 HTML5 호환성으로 넘게 되었다. 가끔씩은 도저히 구제할 수 없는 기존 소프트웨어를 싹 엎고 새로 만드는 편이 나을 수도 있다는 점을 보여주는 대표적인 사례다.

• 데스크탑 브라우저 중 최고 수준의 터치 친화성

Windows 10이 모바일 환경까지 감안하고 개발된 OS인 만큼 그 OS의 기본 웹브라우저인 엣지 또한 높은 수준의 터치 친화성을 보인다. 구글 크롬이나 오페라, 파이어폭스의 경우 데스크톱 프로그램이 억지로 터치를 지원하게끔 만든 느낌이라면 엣지는 다른 모바일 브라우저처럼 물 흐르듯 자연스러운 터치감을 선보이며 마우스로 오른쪽 클릭하는 것과 터치를 길게 하여 열리는 확장 메뉴의 사이즈 크기가 다른 것 등 데스크톱 환경과 터치 환경 모두를 적절하게 수용해낼 수 있는 인터페이스를 갖추고 있다. 구글 크롬의 경우 터치로 길게 누르는 것을 인식하지 못하며 파이어폭스의 경우에는 확장 메뉴가 활성화되기는 하되 터치로 조작하기 불편하게끔 작게 나온다. IE11 메트로 앱에서 선보였던 스와이프 기능 또한 Edge 14부터 추가되어 높은 수준의 터치 친화성을 또다시 입증해보였다.

4.2 단점

• 이유 없는 프로그램 종료
  • 종종 오래 실행시키면 프로그램이 종료되는 현상이 있다. 글이나 온라인 문서 등을 작성하다가 꺼지면 멘붕이 온다. 문제는 이 현상이 지나치게 빈번하다는것. 개선이 시급하다. 이후 업데이트로 개선되었으나 아직도 이 현상이 일어나는 경우가 있다.
• 즐겨찾기 기능 미비
  • 즐겨찾기 폴더를 휠클릭해도 반응하지 않는다.
  • 즐겨찾기에 추가해놓은 인터넷 사이트 파일을 바탕화면이나 문서 폴더 같은 곳으로 옮길 수 없다.

• 컨텍스트 메뉴가 극도로 간략화되면서 현재는 페이지 및 이미지 등록정보를 확인할 수 없다. 그 외에도 여러모로 인터넷 익스플로러를 비롯한 타 브라우저에 비해 컨텍스트 메뉴를 통해 할 수 있는 일들이 많이 줄어들었다. 때문에 브라우저 자체의 성능은 인터넷 익스플로러에 비해 상당히 향상되었음에도, 인터넷 익스플로러를 비롯한 타 브라우저에 익숙해진 사용자의 입장에서는 데스크톱 환경에서 불편함을 상당히 느낄 수 있을 것이다. 물론 모바일 환경에서는 큰 지장이 되는 문제는 아니지만.

• 컨텍스트 메뉴의 각 항목을 마우스 오른쪽 버튼으로는 실행할 수 없다. IE를 포함한 기존 브라우저는 컨텍스트 메뉴의 항목을 왼쪽 버튼 뿐만 아니라 오른쪽 버튼으로 클릭해도 실행이 되었는데, 이 기능이 없어진 것.

• 공식적인 글꼴 설정 옵션이 없는데, 그 와중에 한글 기본 서체가 굴림체다. MS의 굴림계획 맑은고딕은? 일해라 마소코

레지스트리에 손을 대서 수정하는 방법이 있으며, 왜 그러는지는 모르겠지만 나눔글꼴팩을 설치하면 굴림체가 전부 나눔고딕으로 바뀐다. 이 문서 맨 위의 스크린샷도 같은 경우다. 다만 이 방법을 사용하면 던전 앤 파이터의 폰트가 개발살나는 등 일부 프로그램에서 문제가 있을 수 있다.

• 인코딩 관련 설정이 없어서 인코딩 설정이 되어 있지 않은 페이지가 깨져서 나온다. 다만 HTML 명세에는 인코딩 선언이 필수이며, 인코딩 선언이 없는 홈페이지는 IE6을 현역으로 굴리고 있었던 엄청나게 오래된 홈페이지임을 감안하면 큰 문제는 아닐 수도 있다.

• 특정 웹페이지에 들어가면 응답이 없는 경우가 상당히 잦다.

• 타 브라우저(IE11 포함)에 있는 기능인 이미지를 드래그해서 첨부하는 기능이 없다.

• 메트로 앱 기반이라 그런지 데스크탑용 브라우저에서 지원하는 작업표시줄 기반 기능들을 몇몇 지원하지 않는다. 슈퍼바 탭, 파일 전송 미터기 등. 이들 중 새 창 열기는 10586 기준으로 다시 지원하고 있다.

• 전체화면 기능이 없다.

• 단축키 기능이 부실하다.

• 마우스 키에서 클릭이 안먹힌다. 출시전 테크니컬 프리뷰에서 발견된 문제지만 아직도 해결되지 않았다.

• 마우스 오른클릭 후 검색이 안된다. 코타나 활성화 후 코타나에게 물어보기로 검색을 할 수 있으나 검색엔진은 Bing밖에 대응을 안한다.

• 주소창을 통해 검색 시 한글을 입력할 경우, 엔터를 두 번 쳐야한다.

5 기타

• Project Spartan 시절에는 300 및 헤일로 드립이, 엣지로 이름이 확정되자 헨타이 드립이 흥하는 등 공개 이래 각종 개드립을 끌고 다녔었다.

• 고급설정에서 검색자 확장자로 나무위키 검색을 추가할 수 있다.

• 처음에는 IE11보다도 갖춰놓은 표준 기능이 부족했으나, 빠른 속도로 따라잡고 있다. 브라우저의 웹 표준 기능을 확인하는 테스트인 HTML5test 점수를 기준으로 볼 때 IE11은 555점 만점에 336점을 기록하고 있었는데, 처음에 프리뷰에서 IE 밑에 EdgeHTML을 숨겨놓았을 때는 오히려 더 낮은 320점대가 나올 정도로 발전 상태가 미비했다. 그러나 빌드 10240이 정식으로 공개되었을 때는 402점을 기록했으며, 이후 인사이더 프리뷰로 공개된 10525 및 10532에서는 440점, 10547에서는 453점까지 찍었다. 한편 같은 시기 크롬 44는 526점, 파이어폭스 41은 466점을 기록중으로, 조만간 표준 기능에 있어서는 파이어폭스는 넘을 수 있을 것으로 보인다. 그리고 마침내 Redstone 1 애니버서리 업데이트로 파이어폭스를 추월하게 되었다.

• 엣지가 익스플로러와 비교해서 얼마나 바뀌었는지 확인하고 싶다면 여길 참조하면 좋다. 웹 개발자들에게 곶통고통을 안겨준 굵직굵직한 MSHTML 전용 기능들이 덩어리채 잘려나가면서 22만줄의 코드가 지워지고, 지운 양보다 더 많은 코드를 현대 웹 브라우저와의 상호호환을 위해 이것저것 추가했다고 한다.

• 어도비가 엣지 및 EdgeHTML의 그래픽 부분에 손을 대고 있으며, 인텔은 SIMD 연산 기능을 직접 적용했다. 어도비는 과거 오픈소스 기획인 웹키트 및 게코에도 상당 부분 기여를 한 바가 있고 애플 OS X가 자랑하는 데스크톱OS 최강의 2D 엔진 쿼츠 역시 어도비의 기술이 많이 사용되었다. MS의 브라우저에 손을 대는 것은 이번이 처음이라고 한다. 관련 글 이러한 움직임이 이어진 결과 결국에는 위에서 언급한 바와 같이 자바스크립트 엔진의 대부분을 차크라코어라는 이름으로 오픈소스화 하기에 이르렀다.

• 외래어 표기법상 에지가 맞는 표기다.근데 마이크로소프트에서도 엣지라고 쓰는것이 함정 사실 윈도우도 윈도가 맞다는게 함정2

• 일러스트가 처음 공개되었을 때의 해외 반응(...) 익스플로러와 비슷한 아이콘이기에 설마 아니겠지 싶어하는 프라이의 눈초리가 매우 적절하다(...)

• 램디스크 사용시 Direct I/O 를 사용하면 램디스크에 다운로드가 불가능하다. SCSI 방식으로 변경하면 문제없이 사용 가능하다. 참고

• 버전 분류가 약간 혼란스러울 수 있어서 구분 방법을 남긴다. 엣지 자체는 버전이 20에서부터 시작되어 윈도우 참가자 프로그램을 통해 빌드가 공개될 때마다 필요에 따라서 숫자가 올라가고 있다. 하지만 EdgeHTML 엔진은 IE의 넘버링을 이어받아 공식 릴리즈가 나올 때마다 버전이 하나씩 올라간다. 따라서 Threshold 1과 함께 공개된 버전 20에서는 EdgeHTML 12, 이후 Threshold 2의 버전 25에서는 EdgeHTML 13이 사용되고 있다.

• 700px
  한편 초창기 버전의 크고 아름다운 RAM사용량이 화제가 되었다. 그 램 포식자 크롬보다 높았다!

• Windows 10은 Windows 8부터 추가된 앱과 기존의 레거시 데스크톱 프로그램과의 경계선이 희미해졌으므로 굳이 구분해야 될 이유는 없지만, 엣지부터는 앱으로만 존재한다. 기존의 Win8(.1)까지는 인터넷 익스플로러가 데스크톱 프로그램과 메트로UI의 앱이 따로 존재하였으나 Win10의 엣지부터는 앱으로만 제공되고 있다. 겉으로 보기에 레거시 프로그램과 외형적 차이가 없을뿐이다. 또한, 윈도우 10의 IE11은 ActiveX등의 호환성을 위해 메인브라우저가 아니라 보조프로그램으로써 격하되어 탑재되었으므로 데스크톱모드만 존재한다. 데스크톱용 프로그램이 없기 때문에 Administrator 계정으로는 실행할 수 없다.

• 현대의 웹 환경과의 호환성을 위해 다른 브라우저들을 적극적으로 벤치마킹 했다고 하는데, 잘 보면 집중적인 벤치마킹의 대상이 된 브라우저는 파이어폭스도, 크롬도 아닌, 엉뚱하게도 사파리다. 버전 25 기준으로 파이어폭스와 크롬은 지원하지 않는데 사파리는 지원하는 기술들이 꽤 많이 추가되어 있다. 이 때문에 아이패드 프로가 공개될 당시의 애플 키노트에서 황당한 사태가 있었는데, 익히 알려진 바와 같이 애플 키노트는 오로지 사파리에서만 볼 수 있도록 되어 있었다. 이건 사파리만 사용하는 HLS(HTTP Live Streaming) 기능을 타사의 브라우저가 지원하지 않기 때문인데, 뜬금없이 엣지 20이 이걸 지원하는 바람에 엣지는 사파리 이외에 애플 키노트를 볼 수 있는 유일한 브라우저가 되었다(...) 한때는 지원 브라우저 목록에서 빠졌었지만 지금은 지원 브라우저 목록에도 있고, 여전히 당시 영상을 엣지로 보는 데에는 아무 문제가 없다. 윈도우10에 킬러컨텐츠 추가요 근데 왜 킬러컨텐츠가 남의 회사 하드웨어를 팔아주죠? 마침 그 키노트 때 MS에서 올라와서 오피스 선전했잖아 맥에다 윈도우 깔라고 이후의 애플 키노트도 전부 엣지에서 볼 수 있다.

• Windows 10에서의 기본 PDF 뷰어로도 사용된다. 기존 뷰어보다 불편해지고 기능 적어진건 덤

• 파이어폭스나 크롬과 같이 플러그인 및 확장기능을 지원할 예정이다. 이 플러그인은 크롬과 동일하게 C++ 기반이며, 빌드 2015에서는 크롬의 Pinterest 및 Reddit Enhancement Suite가 엣지에서 돌아가는 모습을 보여주기도 했다. 플러그인 스토어는 따로 운영하지 않고 윈도우 스토어를 이용할 것으로 알려져 있다. 단, 초기 정식 빌드인 10240과 TH2 빌드인 10586은 이를 지원하지 않으며, 2016년 윈도우 10 1주년 업데이트인 레드스톤 1에서 추가된 기능이다.

• 10월 1일 기준 재생시간이 긴 유튜브 영상을 장시간 시청하면 초월적인 CPU 점유율이 나오는 버그가 있다.