WebKit
[image]
홈페이지
Apple에서 개발하는 웹 브라우저 및 운영체제에도 쓰이는 레이아웃 엔진의 일종.
KDE의 Konqueror에서 사용하는 KHTML이라는 엔진에서 파생되었으며 BSD 라이선스를 따라 소스 코드가 공개되어 있다.
전반적으로 파이어폭스의 구형 Gecko에 비해 빠른 게 특징.[1] 단점으로는 유독 폼 요소의 디자인이 타 브라우저와 따로 노는 것이 많아[2] CSS 코더들에게 발암을 선사한다(...).
Safari, 오페라, 구글 크롬 등의 브라우저부터 iOS, 안드로이드, 블랙베리, 타이젠과 같은 운영체제까지 안 들어가는 곳이 없을 정도다.
오페라 10의 프레스토와 함께 Acid3 테스트에서 100점을 획득한 엔진이기도 하다.[3]
차기 프로젝트로 웹키트 2.0이 있다.(사파리 6.0부터 장착되었다.) 웹키트2 소개(원문) 웹키트2 소개(번역문)
웹키트 2는 기존 웹키트와 호환되지 않는 API 가 일부 존재한다. 웹키트 2에서는 엔진 자체에 프로세스 제어 기능과 샌드박스 기능이 들어간다. 반응성, 안정성, (웹프로세스를 샌드박스화함으로써) 보안성에 잇점이 생기고 멀티코어 CPU를 더 잘 활용할 수 있게 된다. 모든 세세한 프로세스 관리를 위한 API도 제공된다. 웹키트2는 웹키트의 새로운 API 레이어로 프로세스 분리 모델을 지원하기 위해 바닥부터 다시 설계되었다. 프로세스 분리 모델에서는 웹 컨텐트(자바스크립트, HTML, 레이아웃 등등)가 애플리케이션 UI와 분리된 프로세스에서 동작하게 된다. 이 모델은 구글 크롬에서 구현된 것과 매우 유사하긴 한데, 가장 큰 차이점은 프로세스 분리 모델이 프레임워크에 직접 구현되어 있어 다른 웹키트 클라이언트가 이 모델을 이용할 수 있다는 점이다. 크롬의 멀티 프로세스 방식과 웹키트2의 방식을 비교하면 크롬의 방식은 크롬에서만 잘 작동하며 다른 곳에서 쓰려고 하면 API를 재설계를 해야하고 웹키트2는 재설계가 필요없다. 한마디로 웹키트2는 다른 곳에 이식하기 쉽다.
2011년 7월 21일, 애플의 사파리 5.1 버전부터 웹키트2를 이용하기 시작했다.
애플은 웹키트2로 이전하였고 구글은 웹키트의 분기(fork)인 블링크로 이전하였으며, 당시 크로뮴의 웹키트를 탑재하기로 발표됐던 오페라 역시 이 블링크에 합류하였다. 이로 인해 웹키트가 반으로 쪼개지면서 웹 브라우저의 파편화가 우려되는 상황이다.
두 개의 엔진이 얼마나 다르냐면 프로세스 처리 구조부터 완전히 다르며 특히 블링크는 코드 베이스에서 7000개의 파일을 삭제했다. 애플과 구글의 관계가 서로 견제하는 분위기라 앞으로 코드의 차이는 심해질 수 있다. 다만 HTML5라는 아직 어떤 브라우저도 완벽 지원을 하지 못하는 허들 높은 표준안이 있으니 여기에 맞춰 나가기 위해서라도 호환성의 문제는 크지 않을 것이다. 오히려 과거 막장 브라우저의 대명사였던 인터넷 익스플로러와 기타 브라우저의 차이도 IE 11 시점 기준으로 줄어들었으면 줄어들었지 늘어나지는 않는 판이다.
한데 애플이 웹키트2를 만들면서 소스코드 커밋 리뷰를 애플 직원만이 할 수 있도록 변경해버렸다. 구글이 문제가 아니라 자유 소프트웨어 본연의 문제이기도 한 것. X.Org, LibreOffice, MariaDB와 같은 문제가 재현된 셈이다. 다만 예시의 프로젝트들은 소스 커밋 권한도 권한이지만 프로젝트의 운영 자체가 개차반이 된 탓이 큰 것이 원인이 되었지만 웹키트 같은 경우엔 Darwin과 마찬가지로 애플이 사활을 걸고 개발하는 프로젝트이기 때문에 소스 커밋의 개방성은 문제가 되더라도 성능 개선이 늦어진다던가 하는 문제는 발생하지 않는다. 하여튼 애플의 오픈소스들은 어째 죄다 소스만 오픈하고 커밋은 자기들끼리만 하지만 성능은 얄밉게 잘 뽑아낸다는 것이 공통점일 듯.
iOS용 웹 브라우저는 웹키트가 '''강제'''된다. 웹키트 외의 엔진을 쓰면 검수 과정에서 광탈당한다.[4] 그래서 파이어폭스와 엣지 등 원래는 웹킷을 쓰지 않은 웹브라우저들도 iOS에서만큼은 웹키트를 쓴다. [5]당연하지만 이는 사파리의 점유율을 강제하기 위한 조치로, 당연히 그 웹킷의 소유자인 사파리는 다른 웹브라우저들을 찍어누르는 압도적인 퍼포먼스를 보이고, 다른 웹브라우저들은 동기화를 통한 다른 플랫폼과의 크로스 브라우징 등 다른 편의성들을 무기로 버티는 형국이다.[6]
물론 정반대로 안드로이드 등 다른 플랫폼에선 애플이 웹킷 사용을 강제할 수 없기 때문에 다른 환경에서 사용 가능한 웹킷 기반의 브라우저는 사실상 없어졌다.
1. 개요
홈페이지
Apple에서 개발하는 웹 브라우저 및 운영체제에도 쓰이는 레이아웃 엔진의 일종.
KDE의 Konqueror에서 사용하는 KHTML이라는 엔진에서 파생되었으며 BSD 라이선스를 따라 소스 코드가 공개되어 있다.
2. 상세
전반적으로 파이어폭스의 구형 Gecko에 비해 빠른 게 특징.[1] 단점으로는 유독 폼 요소의 디자인이 타 브라우저와 따로 노는 것이 많아[2] CSS 코더들에게 발암을 선사한다(...).
Safari, 오페라, 구글 크롬 등의 브라우저부터 iOS, 안드로이드, 블랙베리, 타이젠과 같은 운영체제까지 안 들어가는 곳이 없을 정도다.
오페라 10의 프레스토와 함께 Acid3 테스트에서 100점을 획득한 엔진이기도 하다.[3]
차기 프로젝트로 웹키트 2.0이 있다.(사파리 6.0부터 장착되었다.) 웹키트2 소개(원문) 웹키트2 소개(번역문)
웹키트 2는 기존 웹키트와 호환되지 않는 API 가 일부 존재한다. 웹키트 2에서는 엔진 자체에 프로세스 제어 기능과 샌드박스 기능이 들어간다. 반응성, 안정성, (웹프로세스를 샌드박스화함으로써) 보안성에 잇점이 생기고 멀티코어 CPU를 더 잘 활용할 수 있게 된다. 모든 세세한 프로세스 관리를 위한 API도 제공된다. 웹키트2는 웹키트의 새로운 API 레이어로 프로세스 분리 모델을 지원하기 위해 바닥부터 다시 설계되었다. 프로세스 분리 모델에서는 웹 컨텐트(자바스크립트, HTML, 레이아웃 등등)가 애플리케이션 UI와 분리된 프로세스에서 동작하게 된다. 이 모델은 구글 크롬에서 구현된 것과 매우 유사하긴 한데, 가장 큰 차이점은 프로세스 분리 모델이 프레임워크에 직접 구현되어 있어 다른 웹키트 클라이언트가 이 모델을 이용할 수 있다는 점이다. 크롬의 멀티 프로세스 방식과 웹키트2의 방식을 비교하면 크롬의 방식은 크롬에서만 잘 작동하며 다른 곳에서 쓰려고 하면 API를 재설계를 해야하고 웹키트2는 재설계가 필요없다. 한마디로 웹키트2는 다른 곳에 이식하기 쉽다.
2011년 7월 21일, 애플의 사파리 5.1 버전부터 웹키트2를 이용하기 시작했다.
애플은 웹키트2로 이전하였고 구글은 웹키트의 분기(fork)인 블링크로 이전하였으며, 당시 크로뮴의 웹키트를 탑재하기로 발표됐던 오페라 역시 이 블링크에 합류하였다. 이로 인해 웹키트가 반으로 쪼개지면서 웹 브라우저의 파편화가 우려되는 상황이다.
두 개의 엔진이 얼마나 다르냐면 프로세스 처리 구조부터 완전히 다르며 특히 블링크는 코드 베이스에서 7000개의 파일을 삭제했다. 애플과 구글의 관계가 서로 견제하는 분위기라 앞으로 코드의 차이는 심해질 수 있다. 다만 HTML5라는 아직 어떤 브라우저도 완벽 지원을 하지 못하는 허들 높은 표준안이 있으니 여기에 맞춰 나가기 위해서라도 호환성의 문제는 크지 않을 것이다. 오히려 과거 막장 브라우저의 대명사였던 인터넷 익스플로러와 기타 브라우저의 차이도 IE 11 시점 기준으로 줄어들었으면 줄어들었지 늘어나지는 않는 판이다.
한데 애플이 웹키트2를 만들면서 소스코드 커밋 리뷰를 애플 직원만이 할 수 있도록 변경해버렸다. 구글이 문제가 아니라 자유 소프트웨어 본연의 문제이기도 한 것. X.Org, LibreOffice, MariaDB와 같은 문제가 재현된 셈이다. 다만 예시의 프로젝트들은 소스 커밋 권한도 권한이지만 프로젝트의 운영 자체가 개차반이 된 탓이 큰 것이 원인이 되었지만 웹키트 같은 경우엔 Darwin과 마찬가지로 애플이 사활을 걸고 개발하는 프로젝트이기 때문에 소스 커밋의 개방성은 문제가 되더라도 성능 개선이 늦어진다던가 하는 문제는 발생하지 않는다. 하여튼 애플의 오픈소스들은 어째 죄다 소스만 오픈하고 커밋은 자기들끼리만 하지만 성능은 얄밉게 잘 뽑아낸다는 것이 공통점일 듯.
iOS용 웹 브라우저는 웹키트가 '''강제'''된다. 웹키트 외의 엔진을 쓰면 검수 과정에서 광탈당한다.[4] 그래서 파이어폭스와 엣지 등 원래는 웹킷을 쓰지 않은 웹브라우저들도 iOS에서만큼은 웹키트를 쓴다. [5]당연하지만 이는 사파리의 점유율을 강제하기 위한 조치로, 당연히 그 웹킷의 소유자인 사파리는 다른 웹브라우저들을 찍어누르는 압도적인 퍼포먼스를 보이고, 다른 웹브라우저들은 동기화를 통한 다른 플랫폼과의 크로스 브라우징 등 다른 편의성들을 무기로 버티는 형국이다.[6]
물론 정반대로 안드로이드 등 다른 플랫폼에선 애플이 웹킷 사용을 강제할 수 없기 때문에 다른 환경에서 사용 가능한 웹킷 기반의 브라우저는 사실상 없어졌다.
[1] 대략 파이어폭스 3.6.x 버전까지는 자바스크립트 엔진 속도가 느렸기 때문에 반은 맞는 소리였다. 다만 이후 램누수 현상 등 여러 가지를 개선해가며 그 격차는 상당히 줄었고, 파이어폭스가 60 버전부터는 서보를 도입해서 정통 웹키트는 뛰어넘은 지 오래.[2] 버튼, 선택 목록 등. 이를 보정하기 위해 웹키트만을 위한 CSS 구문만 수십줄이 추가되어야 하는 수준이다. 정작 웹키트에서 갈라져 나온 블링크는 이 문제가 없다.[3] 공식 버전만 가지고 따지면 웹키트가 먼저이고 비공식 버전까지 따지면 프레스토가 먼저.[4] 오페라 미니나 퍼핀 브라우저처럼 해당 브라우저를 배포하는 측이 자체적으로 갖춰 둔 서버에서 웹 화면을 프로세싱해서 스마트폰으로 뿌려주는 방식은 허용되었으나, 퍼핀 브라우저는 애플이 웹킷을 사용하지 않는다는 이유로 5.2.0 버전 이후 업데이트 심사가 계속 리젝되었으며, 결국 서비스가 종료됐다. 오페라미니도 2019년 서비스가 종료 되어 앱스토어에 자체 서버에서 화면을 프로세싱하는 방식의 브라우저는 없게 됐다.[5] 초기에는 서드파티 웹브라우저 제조사는 엔진을 사파리에서 쓰는 것 보다 성능이 많이 떨어지는 '''UIWebView'''만을 이용해야 했으나 현재는 그래도 웹킷을 쓸수 있도록 완화(…)되었다.[6] 이는 애플 특유의 자사 플랫폼에 유저를 붙잡아두려는 교묘한 상술의 일환이다. 애플 제품들은 같은 애플 소프트웨어, 애플 하드웨어와 함께 사용하면 시너지가 증가하지만 타사 소프트웨어나 하드웨어와 결합하면 퍼포먼스가 떨어지기 때문에 한번 애플 제품에 입문한 사용자는 결국 편의성을 위해 다른 제품들도 애플 제품으로 맞춰나가서 궁극적으로는 애플 생태계를 벗어나기 힘든 상황이 되어버린다. 물론 성공적으로 애플 생태계에 안착한 경우는 그렇지만 필연적으로 다른 플랫폼을 고집할 수 밖에 없는 이들은 이로 인해 애플의 생태계에 적응하지 못해 포기하고 등을 돌리는 경우도 많다. 대표적으로 데스크탑으로 게임하는 게이머들은 게임 지원이 미비한 애플 플랫폼에 입문하기가 어렵다.