 브라우저 엔진
| |
|---|---|
| 주요 엔진 |  Blink (크롬, 엣지, 웨일, 오페라 등) · Gecko (파이어폭스) ·  WebKit (사파리)
|
| 신흥·개발 중 |  Servo ·  Ladybird (LibWeb) · Flow
|
| 포크 | Goanna (Gecko 포크, Pale Moon) · KHTML (WebKit의 원형) |
| 개발 종료 |  Trident (인터넷 익스플로러) · EdgeHTML (구 엣지) ·  Presto (구 오페라) · Tasman
|
| 구성 요소·관련 | 자바스크립트 엔진 (V8, SpiderMonkey, JavaScriptCore) · Skia · HTML · CSS · DOM · 웹 표준 |
| WebKit | |
|---|---|
.svg){kind=logo} | |
| 원작자 | KDE (KHTML·KJS), 애플 |
| 개발자 | 애플, 이갈리아(Igalia), 소니 등 |
| 발표일 | 2003년 1월 7일 (사파리 베타와 함께 발표), 2005년 6월 (오픈 소스 공개) |
| 버전 정보 | 사파리 버전과 함께 릴리스 (2026년 10월 현재 사파리 27) |
| 개발 상태 | 개발 중 |
| 프로그래밍 언어 | C++, Swift 일부 |
| 운영 체제 | macOS, iOS, iPadOS, visionOS, 리눅스, Windows, 플레이스테이션 등 |
| 종류 | 브라우저 엔진 |
| 라이선스 | BSD 라이선스, LGPL |
| 웹 사이트 | webkit.org |
개요[편집 / 원본 편집]
WebKit(웹킷)은 애플이 주도하는 오픈 소스 브라우저 엔진이다. 애플의 웹 브라우저 사파리가 이 엔진으로 동작하며, iPhone과 iPad에서는 애플 정책에 따라 크롬·파이어폭스·엣지를 포함한 모든 브라우저가 WebKit을 써야 했기 때문에 모바일 웹에서 막강한 영향력을 가진다.
뿌리는 KDE 프로젝트의 렌더링 엔진 KHTML이다. 애플이 2001년 이를 분기해 WebKit을 만들었고, 구글은 2008년 크롬을 만들 때 WebKit을 가져다 썼다가 2013년 다시 분기해 Blink를 만들었다. 즉 오늘날 웹의 95% 이상을 그리는 Blink와 WebKit은 모두 KHTML이라는 같은 조상에서 나온 엔진이다.
현재 주요 브라우저 엔진은 Blink, WebKit, Gecko 세 가지이며, WebKit은 전 세계 페이지뷰 기준 약 16%로 2위를 차지한다. 데스크톱 점유율은 낮지만 모바일, 특히 iOS 기기에서는 사실상 유일한 엔진이다. 애플 외에도 리눅스 데스크톱용 WebKitGTK, 임베디드 기기용 WPE WebKit, 소니 플레이스테이션 등 다양한 플랫폼에서 쓰인다.
명칭[편집 / 원본 편집]
'WebKit'은 macOS의 개발 프레임워크 이름에서 온 것이다. 애플의 프레임워크들은 AppKit, UIKit, HealthKit처럼 '○○Kit'이라는 이름을 붙이는 전통이 있는데, 웹 콘텐츠를 앱에 넣는 프레임워크라서 WebKit이 되었다. 엄밀히 말하면 'WebKit'은 엔진 전체를 가리키는 프로젝트 이름이자, 그 위에서 앱 개발자가 쓰는 API 계층의 이름이기도 하다.
역사[편집 / 원본 편집]
KHTML과 애플의 분기 (1998~2005)[편집 / 원본 편집]
1998년 리눅스 데스크톱 환경 KDE는 자체 웹 브라우저 콘커러(Konqueror)를 위해 렌더링 엔진 KHTML과 자바스크립트 엔진 KJS를 개발했다. KHTML은 작고 깔끔한 코드로 평가받았다.
당시 애플은 Mac OS X에 쓸 자체 브라우저가 필요했다. 맥에서는 인터넷 익스플로러 for Mac이 기본 브라우저였는데, 마이크로소프트가 개발을 소홀히 하고 있었기 때문이다. 애플은 넷스케이프의 Gecko도 검토했지만, 규모가 작고 이해하기 쉬운 KHTML을 선택했다. 2001년 애플 엔지니어 돈 멜턴(Don Melton)이 이끄는 팀이 KHTML을 비공개로 분기해 개발을 시작했다.
2003년 1월 7일, 스티브 잡스는 맥월드 엑스포에서 새 브라우저 사파리를 발표했다. 사파리는 KHTML 기반의 'WebCore'와 KJS 기반의 'JavaScriptCore'로 동작했다. 애플은 LGPL 라이선스에 따라 수정한 소스 코드를 공개했지만, 거대한 변경 사항을 묶음으로 던져 주는 방식이라 KDE 개발자들은 이를 다시 받아들이기 어렵다며 불만을 표했다. 이 갈등은 이후 두 프로젝트가 따로 가는 계기가 되었다.
2005년 6월, 애플은 WebKit 전체를 오픈 소스로 공개하고 공개 저장소와 버그 추적 시스템을 열었다. 같은 해 사파리는 웹 표준 준수 시험 Acid2를 세계 최초로 통과한 브라우저가 되어 기술력을 인정받았다.
모바일 혁명 (2007~2013)[편집 / 원본 편집]
2007년 출시된 iPhone의 모바일 사파리는 WebKit 덕분에 휴대전화에서 데스크톱 수준의 웹을 보여 주었다. 당시 대부분의 휴대전화는 축소된 모바일 전용 페이지(WAP)만 볼 수 있었기 때문에, 이는 스마트폰 시대를 연 결정적인 요소 중 하나로 꼽힌다. 이어 안드로이드의 기본 브라우저도 WebKit을 썼고, 노키아의 심비안, 블랙베리, 팜 webOS 등 당시의 모바일 운영체제들이 앞다투어 WebKit을 채택했다. WebKit은 사실상 모바일 웹의 표준 엔진이 되었다.
2008년 구글이 크롬을 출시하면서 WebKit을 채택했고, 이후 구글은 애플과 함께 WebKit의 최대 기여자가 되었다. 2013년 2월에는 오페라도 자체 엔진 Presto를 버리고 WebKit으로 옮기겠다고 발표했다. 한때 WebKit은 데스크톱과 모바일을 아우르는 가장 널리 쓰이는 엔진이었다.
이 시기 애플은 엔진 내부에 멀티프로세스 구조를 넣은 WebKit2를 개발해 2011년 사파리 5.1에 적용했다. 또 자바스크립트 엔진 JavaScriptCore는 'SquirrelFish', 'Nitro' 등의 이름으로 대대적인 성능 개선을 거쳤다.
Blink 분기 이후 (2013~2019)[편집 / 원본 편집]
2013년 4월, 구글이 WebKit을 분기해 Blink를 만들면서 WebKit은 최대 기여자를 잃었다. 오페라도 곧바로 Blink로 방향을 틀었다. 같은 해 안드로이드 4.4(킷캣)부터 안드로이드의 시스템 웹뷰도 크로미움 기반으로 바뀌면서, WebKit은 사실상 애플의 엔진이 되었다. 분기 직후 애플과 구글은 각자 상대방 전용 코드를 대거 삭제했다.
이후 WebKit은 애플 기기 중심으로 발전했다.
- JavaScriptCore의 FTL JIT(2014) - 최상위 최적화 계층에 LLVM 컴파일러 기반 기술을 도입했다가, 2016년 자체 백엔드 B3로 교체했다.
- 지능형 추적 방지(Intelligent Tracking Prevention, ITP, 2017) - 기계 학습으로 광고 추적 도메인을 판별해 서드파티 쿠키를 제한하는 기능. 광고 업계의 거센 반발을 샀지만, 이후 브라우저들의 개인정보 보호 경쟁을 촉발했다. 2020년에는 서드파티 쿠키를 전면 차단했다.
- 잠금 모드(Lockdown Mode, 2022) - 국가급 해킹 위협을 받는 사용자를 위해 JIT 컴파일 등 위험한 기능을 끄는 iOS 16의 보안 모드.
'새로운 IE' 논란과 반전 (2020~2024)[편집 / 원본 편집]
2020년 전후 WebKit은 웹 개발자들 사이에서 "새로운 인터넷 익스플로러"라는 비판을 받았다. 웹 푸시 알림, 다양한 PWA(프로그레시브 웹 앱) 기능 등 다른 브라우저가 지원하는 기능이 사파리에서만 빠지거나 늦게 들어오고, 버그도 오래 고쳐지지 않는다는 것이다. 특히 iOS에서는 다른 엔진을 쓸 수 없어, 사파리가 지원하지 않는 기능은 iPhone의 모든 브라우저에서 쓸 수 없었다. 비판자들은 애플이 앱 스토어 수익을 지키기 위해 웹 앱의 발전을 일부러 늦춘다고 주장했다.
이에 애플은 2021년 이후 WebKit 투자를 크게 늘렸다. 2022~2023년 사파리 16~17에서는 웹 푸시(iOS 홈 화면 웹 앱 포함), 컨테이너 쿼리, CSS 서브그리드, :has() 선택자 등 대형 기능을 한꺼번에 탑재했으며, 일부 기능은 다른 브라우저보다 먼저 출시했다. 웹 호환성 개선 프로젝트 Interop에서도 적극적으로 활동해, Interop 2025에서 사파리(실험판)는 연초 43점에서 연말 99점으로 4개 브라우저 중 가장 큰 폭의 개선을 보였다.[1]
규제의 압박: iOS 엔진 개방[편집 / 원본 편집]
애플은 오랫동안 앱 스토어 심사 지침 2.5.6조("웹을 탐색하는 앱은 적절한 WebKit 프레임워크와 WebKit 자바스크립트를 사용해야 한다")로 iOS의 모든 브라우저에 WebKit 사용을 강제해 왔다. 애플은 보안과 배터리 효율을 이유로 들었지만, 경쟁 브라우저와 웹 개발자들은 이를 브라우저 엔진 금지라고 비판했다.
- 유럽 연합 - 디지털 시장법(DMA)에 따라 2024년 3월 iOS 17.4부터 EU 지역에서 다른 엔진이 허용되었고, 애플은 이를 위한 BrowserEngineKit 프레임워크를 공개했다.
- 일본 - 스마트폰 소프트웨어 경쟁 촉진법(모바일 소프트웨어 경쟁법)이 2025년 12월 18일 전면 시행되면서 iOS 26.2부터 일본에서도 다른 엔진이 허용되었다.
- 그러나 기존 사용자를 새 엔진 버전으로 그대로 옮길 수 없고 지역별로 별도의 앱을 내야 하는 등의 조건 때문에, 2026년 현재까지 구글·모질라·마이크로소프트 모두 시제품만 만들었을 뿐 Blink·Gecko 기반 iOS 브라우저를 정식 출시하지 않았다. 웹 개방성 단체 Open Web Advocacy는 애플이 규제를 형식적으로만 따르고 있다고 비판한다.[2]
사파리 26과 27 (2025~2026)[편집 / 원본 편집]
2025년 애플은 운영체제 버전 번호를 연도 기반으로 통일하면서 사파리도 18에서 26으로 건너뛰었다. 사파리 26은 WebGPU를 정식 지원했고, 표준화된 Scoped Custom Element Registries를 가장 먼저 탑재했다.
- 사파리 26.2(2025년 12월) - CSS
random()함수를 가장 먼저 지원했다. - 사파리 26.4(2026년 3월) - 신기능 44개와 버그 수정 191건. 핀터레스트 스타일의 '벽돌 쌓기'(masonry) 레이아웃을 CSS만으로 만드는 Grid Lanes(
display: grid-lanes), WebTransport, 키보드 잠금 API 등을 추가했다.[3] - 사파리 26.5(2026년 5월) -
:open의사 클래스, Origin API 등과 버그 수정 63건. - 사파리 27(2026년 9월) - iOS 27, macOS 27 등과 함께 출시되었다. 신기능 83개와 수정 844건으로 역대 가장 긴 릴리스 노트를 기록했다. CSS로 완전히 꾸밀 수 있는
<select>(appearance: base-select), 스크롤 앵커링, 3D 모델을 페이지에 넣는<model>요소의 iOS·macOS 확대, ECMAScript 모듈 로더 재작성 등이 포함되었다. 특히 AI 코딩 에이전트가 사파리 창을 직접 살펴보며 웹 페이지를 디버깅할 수 있게 하는 Safari MCP 서버를 기본 탑재해 화제가 되었다.[4]
애플은 2025~2026년 내내 "개발자들은 새 기능보다 기존 기능이 모든 브라우저에서 똑같이 동작하기를 원한다"며 품질 개선을 최우선 과제로 내세웠다. 또 수년에 걸쳐 레이아웃 엔진을 새 구조로 다시 쓰는 작업을 진행 중인데, 인라인 레이아웃(사파리 17.4)과 '인라인 안의 블록' 레이아웃(사파리 26.4)을 완료하고 플렉스박스와 CSS 그리드의 재작성을 진행하고 있다.
구조[편집 / 원본 편집]
구성 요소[편집 / 원본 편집]
| 구성 요소 | 역할 |
|---|---|
| WebCore | HTML·CSS 해석, DOM, 스타일, 레이아웃, 렌더링 등 엔진의 핵심. KHTML에서 유래했다. |
| JavaScriptCore(JSC) | 자바스크립트·WebAssembly 엔진. KJS에서 유래했다. |
| WebKit (API 계층) | 앱 개발자가 쓰는 API. macOS·iOS의 WKWebView, 리눅스의 WebKitGTK API 등
|
| WTF(Web Template Framework) | 문자열, 스레드, 자료 구조 등 공통 기반 라이브러리. 이름 때문에 자주 농담의 소재가 된다. |
| bmalloc / libpas | 보안을 강화한 전용 메모리 할당기 |
| Web Inspector | 개발자 도구 |
JavaScriptCore[편집 / 원본 편집]
JavaScriptCore는 4단계 실행 구조를 가진다.
| 단계 | 이름 | 설명 |
|---|---|---|
| 1 | LLInt (Low Level Interpreter) | 처음 실행되는 코드를 실행하는 인터프리터. 어셈블리에 가까운 자체 언어(offlineasm)로 작성되었다. |
| 2 | Baseline JIT | 빠르게 기계어로 번역하며 타입 정보를 수집한다. |
| 3 | DFG JIT (Data Flow Graph) | 중간 수준의 최적화 컴파일러. |
| 4 | FTL JIT (Faster Than Light) | 가장 공격적인 최적화를 수행한다. 자체 백엔드 B3를 사용한다. |
WebAssembly는 별도의 BBQ(빠른 컴파일)와 OMG(최적화) 계층으로 처리한다. 엔진 개발자들의 작명 센스가 돋보이는 부분이다. JavaScriptCore는 서버 측 자바스크립트 런타임 Bun의 엔진으로도 쓰인다.
멀티프로세스 구조[편집 / 원본 편집]
현재 WebKit은 다음과 같이 프로세스를 나눈다.
- UI 프로세스 - 앱(사파리 등) 자체. WebKit API를 호출한다.
- 웹 콘텐츠 프로세스 - DOM, 자바스크립트, 레이아웃을 처리한다. 샌드박스로 격리된다.
- 네트워크 프로세스 - 네트워크 통신, 쿠키, 캐시를 담당한다.
- GPU 프로세스 - WebGL, WebGPU, 미디어 재생 등을 담당한다(애플 플랫폼).
포트[편집 / 원본 편집]
WebKit은 하나의 코드에서 여러 플랫폼용 포트(port)를 만드는 구조다.
| 포트 | 관리 | 용도 |
|---|---|---|
| Apple 포트 (Cocoa) | 애플 | macOS·iOS·iPadOS·visionOS의 사파리와 WKWebView
|
| WebKitGTK | 이갈리아 등 | 리눅스 데스크톱. 그놈의 기본 브라우저 'GNOME 웹'(에피파니), 이메일 앱 에볼루션 등 |
| WPE WebKit | 이갈리아 | 셋톱박스, 스마트 TV, 자동차, 디지털 사이니지 등 임베디드 기기. 2025년에는 안드로이드(AOSP) 지원과 WebXR 구현도 진행되었다. |
| PlayStation | 소니 | 플레이스테이션 4·5의 내장 브라우저와 UI |
| Windows (WinCairo) | 소니, 애플 등 | 윈도우용 포트. 브라우저 자동화 도구 Playwright가 윈도우에서 WebKit 테스트를 할 때 쓰인다. |
이 중 이갈리아는 애플 다음가는 WebKit 기여자로, 2025년 한 해에만 1,700건이 넘는 기여를 했다.
WebKit 기반 소프트웨어[편집 / 원본 편집]
- 사파리 - macOS, iOS, iPadOS, visionOS.
- iOS·iPadOS의 모든 브라우저 - iOS용 크롬, 파이어폭스, 엣지, 웨일, 삼성 인터넷 등. 겉모습만 다를 뿐 내부는 사파리와 같은 엔진이다(EU·일본의 일부 예외 제외).
- iOS 앱의 인앱 브라우저 - 카카오톡, 인스타그램 등 앱 안에서 열리는 웹 페이지도
WKWebView를 쓴다. - GNOME 웹(에피파니), Orion(검색 업체 Kagi가 만든 맥·iOS용 브라우저. 크롬·파이어폭스 확장 기능 일부 지원) 등.
- 닌텐도 스위치 - 내장 웹 브라우저(공용 와이파이 로그인 등)가 WebKit 기반 엔진을 쓴다.
- 전자책 단말기, 스마트 TV, 자동차 인포테인먼트 등 수많은 임베디드 기기(WPE).
- 과거 사용처 - 구글 크롬(2008~2013), 안드로이드 기본 브라우저(~2013), 오페라(잠깐), 블랙베리, 노키아 심비안, 아마존 킨들, 삼성 타이젠 등.
점유율[편집 / 원본 편집]
StatCounter 기준 2026년 8월 사파리(WebKit)의 전 세계 페이지뷰 점유율은 약 15.8%로, Blink(약 78.7%)에 이어 2위다. 데스크톱에서는 약 5%에 불과하지만 모바일에서는 약 26%로 높다. 다만 이 통계는 사파리만 집계한 것으로, iOS용 크롬 등 다른 iOS 브라우저도 실제로는 WebKit을 쓰기 때문에 실제 WebKit 엔진의 비중은 이보다 높다. 미국 모바일에서는 사파리가 약 절반을 차지할 정도로 강하다.[5]
대한민국에서의 WebKit[편집 / 원본 편집]
한국은 iPhone 점유율이 20~30% 안팎으로, iPhone 사용자의 웹 경험은 전적으로 WebKit에 달려 있다. 과거 액티브X 시절에는 맥과 iPhone 사용자가 국내 금융·공공 사이트를 이용하기 어려웠고, 이는 국내 웹 표준화 요구의 중요한 배경이 되었다.
국내 웹 개발 현장에서는 "크롬에서는 되는데 iPhone 사파리에서 깨진다"는 문제가 흔한 고민거리다. 특히 iOS의 100vh 높이 문제, 입력창 확대(줌) 현상, 날짜 입력 UI 차이 등은 국내 프런트엔드 개발자들 사이에서 단골 이슈로 꼽힌다. 또 국내 서비스들의 iOS 앱 내 웹뷰도 모두 WebKit으로 동작하므로, iOS 대응은 WebKit 대응과 같은 말이다.
비판[편집 / 원본 편집]
- iOS 엔진 강제 - 앞서 말한 앱 스토어 2.5.6조 때문에 iOS에서는 브라우저 간 엔진 경쟁이 사실상 존재하지 않았다. 사파리가 기능을 지원하지 않거나 버그가 있으면, 사용자는 어떤 브라우저를 써도 피할 수 없다.
- 웹 앱 견제 의혹 - 웹 푸시, 백그라운드 동기화 등 PWA 기능을 늦게 지원하거나 제한해, 앱 스토어 수익을 지키려 한다는 의심을 받는다. 2024년 애플은 EU에서 홈 화면 웹 앱 기능을 아예 제거하려다 반발이 일자 철회하기도 했다.
- 느린 업데이트 주기 - 사파리는 운영체제 업데이트와 함께 배포되기 때문에, 구형 iOS·macOS를 쓰는 사용자는 최신 엔진을 받을 수 없다. 크롬과 파이어폭스가 2주마다 업데이트되는 것과 대조적이다.
- 반면 개인정보 보호(ITP, 서드파티 쿠키 차단, 지문 수집 방지)와 전력 효율 면에서는 다른 엔진보다 앞서 있다는 평가를 받으며, 구글 중심의 Blink 독주를 견제하는 균형추 역할을 한다는 긍정적인 시각도 있다.
여담[편집 / 원본 편집]
- 거의 모든 브라우저의 사용자 에이전트 문자열에 'WebKit'이나 'KHTML'이라는 문구가 들어 있다. 크롬의
AppleWebKit/537.36 (KHTML, like Gecko)가 대표적인데, KHTML(KDE) → WebKit(애플) → Blink(구글)로 이어지는 엔진의 족보가 문자열에 그대로 남아 있는 셈이다. - CSS 속성 앞에 붙는
-webkit-접두사는 WebKit이 표준화 전 실험 기능에 붙이던 것이다. 모바일 웹에서 WebKit이 너무 지배적이었던 탓에 많은 사이트가-webkit-접두사만 쓰자, 파이어폭스와 엣지까지-webkit-접두사 일부를 지원하게 되었다. - WebKit은 최신 기능을 미리 써 볼 수 있는 사파리 테크놀로지 프리뷰(Safari Technology Preview)를 약 2주 간격으로 배포한다.
- WebKit의 로고는 사파리 아이콘과 같은 나침반을 품은 육면체 모양으로, 2025년 새 디자인으로 바뀌었다.
- 사파리 27의 Safari MCP 서버처럼, 2026년에는 브라우저 엔진들이 AI 에이전트를 위한 기능을 앞다투어 도입하고 있다.
관련 문서[편집 / 원본 편집]
외부 링크[편집 / 원본 편집]
각주[편집 / 원본 편집]
- ↑ Launching Interop 2026 - Mozilla Hacks, 2026년 2월.
- ↑ How Apple’s Key Tactic Could Prevent Japan’s Smartphone Act from Improving Browser Competition - Open Web Advocacy, 2026년 1월.
- ↑ WebKit Features for Safari 26.4 - WebKit 블로그, 2026년 3월 24일.
- ↑ WebKit blog breaks down what’s new with Safari 27 for developers, including MCP support - 9to5Mac, 2026년 9월 17일.
- ↑ Browser Engine Market Share Statistics 2026 - Statcounter 2026년 8월 자료 기준.