[브라우저 이해하기] 1. 브라우저와 엔진의 종류

다양한 브라우저 환경은 Web FE 개발자로써 고통받았던 영역이자(특히 IE...), 훌륭한 사용자 경험을 위해 이해해야할 필수적인 영역이기에 정리해보고자 한다.

브라우저의 종류와 점유율

 

현 시점에서 브라우저의 종류와 엔진을 점유율 순으로 살펴보면 다음과 같다.

순위	브라우저명	렌더링 엔진	JS 엔진	점유율
1	Chrome	Blink (fork Webkit)	V8	62.78%
2	Safari	Webkit	Nitro	19.3%
3	Firefox	Gecko	SpiderMonkey	4.2%
4	Edge	Blink (fork Webkit)	V8	4.05%
5	Samsung Internet	Blink (fork Webkit)	V8	2.77%
6	Opera	Blink (fork Webkit)	V8	2.26%
...
9	IE	Trident		0.47%

(출처: statcounter)

 

Chrome의 독보적인 질주에 힘입어 크롬의 Blink 엔진도 타 브라우저에서 채택되어 사용되고 있음을 알 수 있다.

 

또 살펴볼 점은 Webkit2와 Blink엔진은 같은 Webkit엔진에 뿌리를 두고 있기 때문에, 더 큰 개념에선 Webkit엔진이 약 90%정도의 점유율을 갖게 되었다고도 생각해볼 수 있다.

 

브라우저별 렌더링 엔진 & JS 엔진

브라우저별 렌더링, JS 엔진 (출처 : LambdaTest)

 

같은 뿌리, 다른 엔진 Blink vs Webkit

구글과 애플, 모바일 브라우저 강자들이 각각 주도적으로 개발하고 있는 두가지 엔진이다.

 

Blink엔진과 Webkit엔진은 왜 같은 뿌리에서 출발했음에도 갈라질수 밖에 없었는지, 그리고 개발자에 입장에서 피부로 느낄만한 차이점이 궁금하여 분석해보았다.

 

Chrome열풍의 주역, Webkit 엔진

구글이 주도적으로 개발했을것으로 생각했던(개인적 생각) Webkit은 의외로 애플이 처음 개발한 엔진이다.

1998년 당시 애플은 사파리 웹 브라우저에 탑재할 렌더링 엔진으로 오픈소스인 KHTML을 선택하고, 이를 포킹하여 Webkit을 탄생시켰다.

 

Webkit의 정체성에 대해 애플은 이렇게 말한다.

Webkit은 Web Content 엔진으로, 컨텐츠를 표준화된 기술 (예를 들면 HTML, CSS, Javascript, DOM 등)을 활용하여 World Wide Web 환경에 제공하는 것이 주 목적이다.

또한 우리는 다양한 어플리케이션에 Webkit엔진을 탑재하여, 범용 디스플레이 & 인터렉션 엔진으로 활용되길 희망한다.

(이미 Electron으로 상당히 달성한것 같다...!)

 

지금은 HTML/CSS/JS가 웹 하면 떠오르는 자연스러운 기술스택이지만, 미래에는 그렇지 않을수도 있다는 (더 좋은 표준이 등장할지도..?) 발전 가능성을 염두에 둔 메세지가 아닌가 싶다.

 

2005년 7월 월드와이드 개발자 컨퍼런스에서 애플은 Webkit을 오픈소스로 만들겠다고 발표한다. 이 발표는 많은 모바일 제조사들의 관심을 끌었고, Webkit 엔진을 너도나도 채택하기 시작한다.

 

마침내 2008년 9월, Google은 Webkit엔진을 기반으로 한 Chrome 브라우저를 출시하였다.

 

스마트폰의 보급과 더불어 HTML5 표준은 빠르게 퍼져나갔고, (악명높은) 어도비 플래시의 몰락과 함께 HTML5의 시대가 본격적으로 열린다.

 

2013년 2월, Opera Software가 Webkit 진영에 합류하였고

2013년 4월, Google과 Opera Software는 Blink 엔진 개발을 발표했다. (Opera의 빠른 태세전환!)

 

이때를 기점으로 Blink 엔진이 Webkit으로 부터 분리(fork)되었다.

여담으로 Google이 Webkit에 본격적으로 기여한 2009년부터 분리를 결정한 2013년까지 Webkit 코드에 가장 큰 기여(커밋수 기준)를 했다고 한다.
구글이 Chrome을 성공시키면서 덩달아 Webkit의 성장도 가파를수 있었다고 짐작해본다.

이제 남은 의문은, Google은 왜 Blink를 만들게 되었을까? 이다.

구글은 Chromium 홈페이지에 이를 (장황하게)설명해두었는데, 크게 두가지 이유를 들었다.

 

첫째, Chromium은 다른 Webkit 기반 브라우저들과는 다른 멀티프로세스 아키텍처를 사용하기 때문이다. 여러 아키텍처를 지원해야하는 문제는 Webkit 커뮤니티와 Chromium 커뮤니티 양측을 모두 복잡하게 만들었고, 이는 혁신속도를 저하시켰다.

 

둘째, 이러한 이슈는 성능 개선 전략을 원점에서 생각할 기회를 주었다. 우리는 웹 어플리케이션이 가능한 한 최고의 속도를 낼수 있도록 하고싶다.

우리는 최대한 많은 브라우저가 작업을 병렬처리하여 메인스레드를 온전히 어플리케이션 코드 실행에 집중할 수 있게 하고싶다. 우리는 이미 이 분야에서 상당한 진전을 이루었고, 예를들면 '페이지 스크롤 도중 Javascript와 Layout에 미치는 영향을 최소화 하는것' 등 어플리케이션이 무거운 Javascript 작업을 수행중일때도 항상 60fps를 유지할 수 있도록 하였다.

 

정리하자면, '우리는 멀티프로세스 아키텍처가 맞다고 생각하는데, 다른 브라우저들은 어떻게 생각하니?' 였다. 아마 다른 브라우저들이 주저하는 모습을 보고 직접 보여주겠다고 판단하지 않았나 싶다.

 

개발자를 떠나 하나의 웹 사용자로써 Chrome이 가져다준 혁신을 경험해봤기 때문에, 앞으로도 Google의 행보가 기대된다.

 

다음 글에서는 Webkit 엔진의 구조와 특징을 하나씩 살펴볼 것이다. 

 

 

참고 문서

https://www.lambdatest.com/blog/browser-engines-the-crux-of-cross-browser-compatibility/

https://www.chromium.org/blink/developer-faq/#why-is-chrome-spawning-a-new-browser-engine

https://medium.com/@andriyyevseytsev/web-engines-and-webkit-4c23456665fd

Web Engines and WebKit