Safari 27이 525건의 수정을 출시하는 이유: WebKit 랩에서의 기록

WWDC 2026에서 Safari 팀이 한 말 중 가장 많은 것을 드러낸 부분은 어떤 기능에 관한 것이 아니었습니다. Safari and Web Technologies 그룹 랩에서 한 시간 동안 WebKit 엔지니어들은 한 가지 질문을 계속 맴돌았습니다. 브라우저 팀은 무엇을 만들지 어떻게 결정하며, 왜 그것이 바깥에서 보기에는 그토록 자주 느려 보이는가 하는 질문이었습니다. 랩에서 그들이 거듭 돌아온 답은, 풀어서 옮기자면, 그들이 정말로 진심으로 신경 쓰고 있으며 그것을 확인할 수 있는 숫자로 뒷받침된다는 것이었습니다. Safari 27은 58개의 새 기능과 525건의 수정을 출시하는데, WebKit은 이를 “최근 기억에 남는 어떤 Safari 릴리스에서도 가장 큰 수정 더미”라고 부릅니다.¹ 이 글은 그 숫자 밑에 깔린 논리에 관한 것으로, 랩에서 나온 이야기를 바탕으로 하고 WebKit 자체의 릴리스 노트에 근거를 둡니다.

WWDC 2026 Safari & Web Technologies Group Lab.

핵심 요약

• Safari 27은 58개의 새 기능과 525건의 수정을 출시하며, 이는 어떤 Safari 릴리스보다도 많은 수정 건수입니다.¹ 랩은 올해를 페이퍼컷 캠페인으로 규정했습니다. 화제가 되는 기능만 쫓는 것이 아니라, 플랫폼을 신뢰할 만하게 만드는 작은 정확성 버그들을 추적하는 것입니다.
• 가장 분명한 예는 JavaScript 모듈 로더의 재작성입니다. WebKit의 노트는 “표준 준수를 위해 ES module loader를 재작성하여 여러 top-level await 정확성 버그를 수정”했다고 설명하며, top-level await가 아예 등장하기도 전인 2016년의 폐기된 제안에 기반한 구현을 교체했습니다.¹
• 랩은 표준이 실제로 어떻게 풀려나가는지를 보여주는 사례 연구로 :has() 선택자를 사용했습니다. 엔지니어들이 수년간 불가능하다고 했던 기능이, Igalia의 엔지니어링이 그것을 충분히 빠르게 만들면서 마침내 모든 주요 엔진에 출시되었습니다.²³
• 폼 컨트롤 이야기는 한층 무르익었습니다. appearance: base-select는 네이티브 <select> 스타일링을 걷어내어 깨끗한 상태에서 시작할 수 있게 해주지만, “모든 폼 컨트롤을 스타일링한다”는 더 넓은 방향성은 패널이 공개적으로 서로 의견을 달리한, 아직 정착되지 않은 명세입니다.¹²
• WebKit과 JavaScriptCore는 watchOS를 포함한 모든 Apple OS에서 동작하며, SwiftUI에는 이제 정식 WebView가 있어서, “웹 엔진”은 단일 앱이라기보다 시스템 서비스에 더 가깝습니다.²⁴

그 숫자, 그리고 그것이 의미하는 바

WebKit이 Safari 27을 규정하는 방식은 유난히 정량적입니다. 새 기능을 차치하면, 이번 릴리스는 525건의 수정, 즉 “어떤 Safari 릴리스에서도 가장 큰 수정 더미”를 담고 있습니다.¹ 랩에서 팀은 그 숫자를 하나의 이정표가 아니라 하나의 태도와 연결했습니다. 풀어서 옮기자면, 웹 개발자들은 때때로 브라우저의 선택을 자신들의 일상 경험에 무관심하다는 뜻으로 읽지만, 팀의 답은 그 반대였습니다. Safari에서 웹을 더 나쁘게 만드는 데에는 아무런 이점이 없다는 것입니다.² 이 정서를 그저 믿음으로 받아들일 필요는 없습니다. 수정 건수가 그 증거이며, 랩 자체가 릴리스 노트를 두고 한참 동안 스크롤해 내려갈 만큼 길게 이어진다고 설명했기 때문입니다.²

가장 좋은 단 하나의 예시는 대부분의 개발자가 결코 보지 못하는 배관 작업입니다. WebKit은 JavaScript 모듈 로더를 재작성했습니다. 릴리스 노트는 구체적입니다. 팀은 “표준 준수를 위해 ES module loader를 재작성하여 여러 top-level await 정확성 버그를 수정”했는데, 이전 구현이 “top-level await가 아예 등장하기도 전인 2016년의 폐기된 WHATWG Loader 제안에 기반”했고, import가 export를 완전히 초기화되기 전에 접근하도록 허용할 수 있었기 때문입니다.¹ 한 부류의 await 순서 버그를 고치기 위해 모듈 로더를 재작성하는 것은, 제대로 해내면 아무도 알아채지 못하는 일에 들이는 막대한 노력입니다. 그것이 바로 커밋 하나에 담긴 페이퍼컷 캠페인입니다.

표준이 실제로 풀려나가는 방식: :has() 이야기

랩에서 가장 쓸모 있었던 서사는 CSS :has() 선택자, 오랫동안 염원해온 부모 선택자에 관한 것이었습니다. 패널에서 나온 이야기를 풀어서 옮기면 이렇습니다. 브라우저 엔지니어들은 거의 20년에 가까운 세월 동안 안 된다고 했는데, 페이지 성능을 망가뜨리지 않고 그것을 평가할 만큼 칩이 빠르지 않다는 이유에서였습니다. 그러다 마침내 이를 실현 가능하게 만드는 작업이 이루어졌고 여러 브라우저에 걸쳐 출시되었습니다.² 그 이야기 밑에 깔린, 검증 가능한 척추는 실재합니다. WebKit은 Safari 15.4에서 :has()를 출시했고, Chromium은 오픈소스 컨설팅 업체 Igalia가 주도한 엔지니어링으로 Chrome 105에서 뒤따랐으며, Firefox가 버전 121에서 마지막 자리를 채웠습니다. 그래서 수년간 “불가능”했던 선택자가 이제 모든 주요 엔진에서 동작합니다.³

랩은 이를 이름으로 알아둘 만한 한 가지 설계 원칙과 연결했습니다. HTML 프로젝트의 “이해당사자의 우선순위(priority of constituencies)”는 이해가 충돌할 때 누구의 필요가 이기는지를 순서 매깁니다. 작성자보다 사용자, 구현자보다 작성자, 명세자보다 구현자, 그리고 이 모두가 이론적 순수성에 우선합니다.⁵ 이것이 바로 브라우저가 사이트를 깨뜨리느니 차라리 보기 흉한 호환성 우회책을 영원히 짊어지는 이유를, 그리고 작성자에게 도움이 되는 기능이라도 그것을 구현하는 일이 성능을 통해 사용자에게 해를 끼친다면 수년을 기다릴 수 있는 이유를 설명하는 규칙입니다. :has()는 그 규칙이 슬로 모션으로 해결되는 모습입니다. 작성자에게 유용하지만, 그것을 빠르게 만드는 데 드는 사용자 비용에 막혀 있다가, 그 비용이 내려간 뒤에야 비로소 출시된 것입니다.

폼 컨트롤 프로젝트, 그리고 공개된 의견 차이

지난 10년간 가장 많이 요청된 CSS 역량이 마침내 도착하고 있습니다. <div>로 처음부터 다시 만들지 않고도 네이티브 폼 컨트롤을 스타일링하는 것입니다. Safari 27은 appearance: base-select를 출시하는데, WebKit의 표현을 빌리면 “네이티브 스타일링을 걷어내고 깨끗한 팔레트에서 시작”할 수 있게 해주며, 그런 다음 컨트롤의 진짜 의미론, 키보드 처리, 접근성을 유지한 채 자신만의 CSS를 입힐 수 있습니다.¹ 이것은 ::picker(select), ::picker-icon, ::checkmark, 그리고 <selectedcontent> 요소와 짝을 이루며, 진짜 select 요소를 스타일링하기에서 다룬 커스터마이즈 가능한 select 표면입니다.

랩이 덧붙인 것은 더 넓은 비전이 얼마나 미완성인지에 대한 솔직함이었습니다. appearance: base를 모든 폼 컨트롤로 확장하는 것은 명시된 방향이지 출시된 명세가 아니며, 패널은 가장 어려운 질문, 즉 스타일이 입혀지지 않은 기준선이 도대체 어떤 모습이어야 하는지를 두고 카메라 앞에서 스스로 의견을 달리했습니다. 그 주고받음을 풀어서 옮기면, 한쪽 입장은 스타일이 입혀지지 않은 컨트롤이 평범한 현대적 컨트롤처럼 보여야 한다는 것이었습니다. 이에 대한 반박은 “현대적”이란 움직이는 유행의 표적이지 명세가 못 박을 수 있는 무언가가 아니라는 것이었고, 따라서 기준선은 페이지로부터 가능한 한 많이 상속받고 그 외에는 가능한 한 의견을 거의 두지 말아야 한다는 것이었습니다.² 그들이 합의한 엔지니어링 제약이 진정으로 어려운 부분입니다. 이 기능은 기본 렌더링과 DOM 구조가 브라우저 전반에 걸쳐 동일할 때에만 작동합니다. 작성자들이 그 둘 모두를 상대로 스타일을 입힐 것이기 때문입니다.² 그것이 바로 30년 묵은 문제가 체크박스 하나가 아니라 여전히 진행 중인 작업인 이유입니다.

웹 엔진은 하나의 시스템 서비스다

랩에서 나온 쓸모 있는 재구성 하나는 이렇습니다. WebKit은 Safari를 훨씬 넘어서는 존재라는 것입니다. WebKit과 JavaScriptCore는 브라우저가 아예 없는 watchOS를 포함한 모든 Apple 운영체제에 탑재되며, JavaScript를 실행하는 모든 앱은 JavaScriptCore에 기대고 있습니다.² WebKit 자체의 WWDC 자료도 같은 점을 짚으며, 앱 인터페이스가 “Safari 내부와 동일한 엔진인 WebKit과 JavaScriptCore가 렌더링하는 HTML, CSS, JavaScript로 구동된다”고 여러 플랫폼에 걸쳐 설명합니다.¹ 개발자에게 실질적 결과는 2025년에 도착했습니다. SwiftUI가 네이티브 WebView와 WebPage 모델을 갖추면서, WebKit이 UIViewRepresentable로 감싼 WKWebView가 아니라 정식 SwiftUI 뷰가 된 것입니다.⁴ 웹 엔진이 이만큼 OS 깊숙이 들어와 있으면, “이건 네이티브여야 하나 웹이어야 하나”는 더 이상 양자택일이 아니게 됩니다.

WebKit이 가장 먼저 출시하는 것, 그리고 다음으로 만드는 것

개발자가 주목할 만한 더 작은 갈래가 둘 있습니다. 첫째, Safari는 다른 엔진보다 앞서 CSS 기능을 계속 출시합니다. hanging-punctuation은 수년간 Safari 전용이었고, CSS filter() 함수(널리 지원되는 filter 속성과는 구별됩니다)는 여전히 WebKit 전용이며, Safari는 최근 random() 함수를 출시했고, CSS Values 초안에 정의된 이산 값들 가운데서 선택하기 위한 동반 함수 random-item()도 함께 내놓았습니다.⁶⁷ “Safari는 뒤처져 있다”는 반사적 반응은 그것이 얼마나 자주 가장 앞서는지를 놓칩니다.

둘째, 웹 익스텐션 이야기가 통합되고 있습니다. 크로스 브라우저 WebExtensions 노력은 여러 해에 걸친 커뮤니티 그룹에서 정식 W3C Working Group으로 옮겨가고 있으며, 진정한 상호운용성 명세를 겨냥한 2025년 초안 헌장을 두고 있습니다.⁸ 그리고 Apple은 WWDC 2026 기조연설에서 소비자를 향한 한 가지 반전을 발표했습니다. 바로 “Describe an Extension”으로, Apple Intelligence를 사용해 평이한 자연어 설명으로부터 맞춤형 Safari 익스텐션을 생성하고 설치하는 기능이며, Xcode도 App Store 왕복도 필요 없습니다.⁹ 이것은 개발자 API라기보다 기조연설 발표로 받아들이는 편이 좋지만, 방향은 분명합니다. 익스텐션 표면이 표준 계층과 최종 사용자 계층에서 동시에 넓어지고 있습니다.

여기서 얻을 것

랩은 대부분의 기능 보도가 건너뛰는 한 가지 트레이드오프를 들여다보는 창입니다. 브라우저 팀은 화제가 되는 기능을 쫓을 수도, 정확성을 쫓을 수도 있는데, WebKit은 이번 릴리스에서 눈에 띄게 후자를 선택했습니다. 525건의 수정, 한 부류의 await 버그를 위해 재작성된 모듈 로더, 하드웨어가 따라잡기를 20년 기다린 부모 선택자가 그것입니다. 이 플랫폼 위에서 무언가를 만드는 누구에게나 주는 교훈은, 실제로 무엇이 나아졌는지 알고 싶다면 기조연설이 아니라 릴리스 노트를 읽으라는 것입니다. 기능은 커스터마이즈 가능한 select, CSS Grid Lanes, HTML model 요소에 있고, 그 속도 뒤에 깔린 논리는 랩에 있습니다.

자주 묻는 질문

Safari 27에는 수정이 몇 건 있나요?

58개의 새 기능과 함께 525건의 수정이 있으며, WebKit은 이를 어떤 Safari 릴리스보다도 많은 수정 건수라고 설명합니다.¹ 랩은 올해를 화제가 되는 기능이 아니라 정확성과 “페이퍼컷”을 중심으로 규정했습니다.

모듈 로더 재작성이란 무엇인가요?

WebKit은 표준 준수를 위해 Safari의 ES module loader를 재작성하여 여러 top-level await 정확성 버그를 수정했습니다. 이전 구현은 top-level await보다 앞선 2016년의 폐기된 WHATWG Loader 제안에 기반했고, import가 export를 완전히 초기화되기 전에 접근하도록 허용할 수 있었습니다.¹

appearance: base가 출시되나요?

appearance: base-select는 Safari 27에서 <select> 요소를 대상으로 출시되어, 네이티브 스타일링을 걷어내어 컨트롤의 의미론을 유지하면서 자신만의 CSS를 적용할 수 있게 해줍니다.¹ appearance: base를 모든 폼 컨트롤로 확장하는 것은 명시된 방향이지만 아직 정착되지 않은 명세이며, 랩 패널은 스타일이 입혀지지 않은 기본값이 어떤 모습이어야 하는지를 두고 공개적으로 의견을 달리했습니다.²

Apple이 정말로 AI 생성 Safari 익스텐션을 추가했나요?

네. Apple은 WWDC 2026 기조연설에서 “Describe an Extension”을 발표했습니다. Apple Intelligence를 사용해 자연어 설명으로부터 맞춤형 Safari 익스텐션을 생성하고 설치하는 기능이며, Xcode나 App Store가 필요 없습니다.⁹ 이것은 개발자 API가 아니라 소비자 기능입니다.

Safari 기능 글들은 무엇을 다룹니다. 진짜 <select> 스타일링하기, 네이티브 메이슨리를 위한 CSS Grid Lanes, 그리고 HTML <model> 요소가 그것입니다. 이 글은 그 속도 뒤에 깔린 이유를 다룹니다. 전체 시리즈 허브는 Apple Ecosystem 시리즈입니다.

참고 문헌