WebKit

1. 개요[편집]

---

Apple에서 개발하는 웹 브라우저 및 운영 체제에도 쓰이는 브라우저 엔진의 일종.

KDE의 Konqueror에서 사용하는 KHTML이라는 엔진에서 파생되었으며, 렌더링 엔진과 JavaScript 엔진은 LGPL v2.1에 따라 소스 코드가 공개되어 있고, 나머지 Apple이 기여한 코드는 BSD 라이선스를 따른다.

2. 상세[편집]

---

Safari 및 iOS, iPadOS에서 돌아가는 모든 웹 브라우저에서 사용되고 있으며, 애플 정책에 따라 iOS, iPadOS의 모든 웹 브라우저는 웹키트가 강제된다. Opera 10의 프레스토와 함께 Acid3 테스트에서 100점을 획득한 엔진이기도 하다.[2] 단점으로는 유독 폼 요소의 디자인이 타 브라우저와 따로 노는 것이 많아[3] CSS 코더들에게 발암을 선사한다.

Chrome 및 Chromium 기반 브라우저들도 블링크로 분기(fork)하기 전까지 사용하였다. 정확히 하자면 WebKit의 렌더링 엔진에 해당하는 WebCore만 포크해갔다. 당시 Chromium의 웹키트를 탑재하기로 발표했던 Opera 역시 블링크에 합류하였다. 이로 인해 웹키트가 반으로 쪼개졌다. 웹키트와 블링크가 서로 얼마나 다르냐면 프로세스 처리 구조부터 완전히 다르며 특히 블링크는 코드 베이스에서 7000개의 파일을 삭제했다. 애플과 구글은 서로 견제하는 관계라 앞으로 코드의 차이가 심해질 수 있다. 다만 HTML5라는 아직 어떤 브라우저도 완벽하게 지원하지 못하는 허들 높은 표준안이 있기 때문에 호환성의 문제는 크지 않을 것이다. 오히려 과거 막장 브라우저의 대명사였던 Internet Explorer와 다른 브라우저들의 차이도 Internet Explorer 11 시점 기준으로 줄어들고 있지 늘어나지는 않고 있다.

최근 웹 브라우저의 경쟁은 과거의 배타적인 코드 해석 방식으로 이용자들에게 불편을 주는 장벽을 세우는 것 보다는 산업 표준을 준수하며 더 빠르고 편리한 사용성을 목표로 하는 바람직한 방향으로 나아가고 있다. 간혹 구글 Chrome의 구글 기어스 같이 웹 표준에 없는 신기능을 탑재하는 경우들이 있지만 이는 대체로 이를 이용해서 배타적인 장벽을 구축하려 하는 것이라기 보다는 경쟁사들이 자신들이 원하는 기능, 혹은 구현 방식에 있어 이견이 있는 기능을 자신들이 원하는 방식으로 웹 표준에 넣지 않으면 그러한 일을 실제로 벌일 수도 있다는 일종의 무력시위에 가까워진 상태이고 서비스 제공자들도 그런 의도를 알고 있기에 이런 실험적인 기능들을 실제로 채용하는 일은 거의 없다. 이런 이슈들은 과거처럼 끝없는 소모전을 일으키며 브라우저 제작사와 소비자들 중 어느 누구도 이익을 얻지 못하는 전쟁을 하는 것 보다는 결국 협상 과정을 거쳐 웹 표준을 업데이트 하는 원만한 합의절차도 구축이 되어 있는 상태이기 때문에 새 표준이 나오면 기존의 특정 브라우저 만의 실험적 기능은 곧바로 폐기되는 것이 관례처럼 굳어지고 있다.

iOS, iPadOS용 웹 브라우저는 웹키트가 강제된다. 웹키트 외의 브라우저 엔진을 쓰면 검수 과정에서 반려당한다.[4] 그래서 Firefox와 Edge, 네이버 웨일, Chrome 등 원래는 웹키트를 쓰지 않은 웹 브라우저들도 iOS, iPadOS에서만큼은 웹키트를 쓴다.[5] 당연하지만 이는 사파리의 점유율을 강제하기 위한 조치로, 당연히 그 웹키트의 소유자인 사파리는 다른 웹 브라우저들을 찍어 누르는 압도적인 성능을 보이고, 다른 웹 브라우저들은 동기화를 통한 다른 플랫폼과의 크로스 브라우징 등 다른 편의성들을 무기로 버티는 형국이다. 이는 애플 특유의 자사 플랫폼에 유저를 붙잡아두려는 교묘한 상술의 일환이다. macOS에서도 App Store에 들어가고 싶다면 운영 체제에 내장된 순정 웹키트 엔진을 사용해야 한다. 브라우저 시장의 특성상 서드파티 브라우저를 사용하는 사람들은 웹 사이트에서 다운로드 받는 것이 보통이지만 Maxthon 브라우저처럼 어차피 웹키트 엔진을 사용하는 브라우저에 한해서는, 혹은 각종 스트리밍 서비스 전용, 혹은 Gmail 전용으로 인터페이스가 커스터마이징 된 특수 목적 브라우저 등은 앱스토어 입점의 특혜를 누릴 수 있다.

Android 등 애플의 권한이 미치지 못하는 다른 플랫폼의 웹키트 기반의 브라우저는 소니와 닌텐도의 게임기들에 사용하고 있는 것이다. 닌텐도는 닌텐도 3DS와 닌텐도 스위치에 ACCESS의 넷프론트라는 웹 브라우저를 사용하고 있으며 이것이 웹키트 기반이다. 소니는 과거 PSP와 PlayStation 3의 웹 브라우저로 ACCESS의 넷프론트를 사용한 적 있으나 이후 PlayStation 4부터 웹키트 엔진 기반 자체 웹 브라우저를 만들어 사용하고 있다. 다만 PlayStation 5와 닌텐도 스위치는 웹 브라우저의 보안 취약점을 악용하는 것을 막기 위해 직접 접근을 막아놓고 닌텐도 e숍이나 PlayStation 스토어 접근 정도로 제한해 사용하고 있다.

Android의 웹 브라우저들은 대부분 블링크를 쓰는데, 블링크도 웹키트 기반으로 포크해서 만든 엔진이라 웹키트와 연관이 없는 브라우저는 찾기가 굉장히 어렵다. 심지어 Microsoft Edge Android도 EdgeHTML이 아닌 블링크 엔진을 썼을 정도다. 다만 앞서 말했듯 현 시점 기준으로는 두 엔진의 차이가 크기 때문에 말 그대로 연관만 있다 뿐이지 완전히 다른 엔진으로 봐도 무방하다. 게다가 자바스크립트 엔진은 각각 V8과 JavaScriptCore라는 근본부터 다른 물건이 들어가기 때문에 더더욱.[6]

3. WebKit 2[편집]

---

2010년 4월 8일 애플은 웹키트 2를 발표했다. # 번역 맥은 Safari 5.1부터 이전했으며, 아이폰과 아이패드는 iOS 8부터 이전했다.

웹키트 2는 기존 웹키트와 호환되지 않는 API가 일부 있다. 웹키트 2는 엔진 자체에 프로세스 제어 기능과 샌드박스 기능이 들어간다. 반응성, 안정성, 웹 프로세스를 샌드박스화함으로써 보안에 이점이 생기고 멀티코어 CPU를 더 잘 활용할 수 있게 된다. 모든 세세한 프로세스 관리를 위한 API도 제공된다. 웹키트 2는 프로세스 분리 모델을 지원하기 위해 바닥부터 다시 설계되었다. 프로세스 분리 모델에서는 웹 콘텐트(JavaScript, HTML, CSS 등)가 애플리케이션 UI와 분리된 프로세스에서 동작하게 된다. 이 모델은 구글 크롬에서 구현된 것과 매우 유사하긴 한데, 가장 큰 차이점은 프로세스 분리 모델이 프레임워크에 직접 구현되어 있어 다른 웹키트 클라이언트가 이 모델을 이용할 수 있다는 점이다. 크롬의 멀티 프로세스 방식과 웹키트 2의 방식을 비교하면 크롬의 방식은 크롬에서만 잘 작동하며 다른 곳에서 쓰려고 하면 API를 재설계를 해야하지만 웹키트 2는 그럴 필요가 없다. 한마디로 웹키트 2는 다른 곳에 이식하기 쉽다.

한데 애플이 웹키트 2를 만들면서 소스코드 커밋 리뷰를 애플 직원만이 할 수 있도록 변경해 버렸다. 구글이 문제가 아니라 자유 소프트웨어 본연의 문제이기도 하다. X.Org, LibreOffice, MariaDB와 같은 문제가 재현된 셈이다. 다만 예시의 프로젝트들은 소스코드 커밋 권한 문제도 있지만 프로젝트의 운영 자체가 개차반이 된 탓이 컸지만 웹키트 같은 경우엔 Darwin과 마찬가지로 애플이 사활을 걸고 개발하는 프로젝트이기 때문에 소스 커밋의 개방성은 문제가 되더라도 성능 개선이 늦어진다든가 하는 문제는 발생하지 않는다. 하여튼 애플의 오픈소스들은 어째 죄다 소스 코드 오픈만 하고 커밋은 자기들끼리만 하지만 성능은 얄밉게 잘 뽑아낸다는 것이 공통점일 듯.

2014년 4월 30일 애플은 기존 WebKit API를 WebKitLegacy API로 변경했으며, 2017년 7월 10일에는 WebKit2 API를 WebKit API로 변경했다. 쉽게 말해 웹키트 2가 웹키트로 되었다.

2022년 8월 31일 애플은 WebKit 개발을 Github로 이주했으며#, 소스 코드 커밋도 다시 개방했다.##