EU 디지털시장법(DMA)의 압박으로 애플이 iOS를 열었다. iOS 17.4부터 EU 안에서는 Chrome의 Blink, Firefox의 Gecko 같은 대체 브라우저 엔진을 iPhone에 탑재하는 것이 "허용"됐다. 15년 넘게 이어진 WebKit 강제 사용의 벽에 처음으로 금이 간 사건이다.
다만 웹 개발자가 오해하면 안 되는 게 있다. 허용됐다고 실제로 바뀐 건 아직 거의 없다. 애플이 내건 조건이 워낙 빡빡해서, 2025년 말 기준으로 자체 엔진을 실제로 iPhone에 올린 브라우저는 사실상 없다. 그럼에도 이 사건이 크로스브라우저 테스트와 웹 표준의 미래에 무엇을 의미하는지, 그리고 왜 소형 브라우저들은 별개로 점유율을 늘렸는지를 개발자 관점에서 정리한다.
솔직히 이 소식을 처음 들었을 때 나는 반신반의했다. "드디어 iPhone에서도 진짜 Chrome을 쓸 수 있는 건가?" 웹 개발을 오래 한 사람이라면 iOS Safari가 얼마나 자주 발목을 잡는지 안다. 데스크톱 Chrome에서 멀쩡하던 CSS가 iOS에서만 깨지고, 그 원인이 결국 WebKit이었던 경험이 한두 번이 아니다. 그래서 이 변화가 반가우면서도, 막상 뜯어보니 "허용은 됐지만 현실은 그대로"라는 애매한 상태라 이 글을 쓴다.
무슨 일이 있었나 — DMA가 애플을 움직였다
핵심은 이렇다. EU의 디지털시장법(DMA)이 애플을 "게이트키퍼"로 지정했고, 그 규제에 맞추기 위해 애플은 2024년 3월 iOS 17.4에서 두 가지를 EU 사용자에게 열었다. 하나는 브라우저를 처음 열 때 기본 브라우저를 고르게 하는 브라우저 선택 화면(choice screen), 다른 하나는 Safari의 WebKit이 아닌 대체 렌더링 엔진을 쓸 수 있게 해주는 BrowserEngineKit 프레임워크다.
그동안 iOS의 규칙은 단순하고 답답했다. App Store의 어떤 브라우저든 내부적으로는 무조건 WebKit을 써야 했다. iPhone에 깔린 "Chrome"도, "Firefox"도 껍데기만 각자의 UI일 뿐 엔진은 전부 Safari와 같은 WebKit이었다. 그래서 iOS에서는 사실상 브라우저가 하나뿐이었던 셈이다. DMA는 이 강제 조항을 정조준했다.
참고로 데스크톱과 달리 모바일 시장 점유율 자체는 아직 크게 안 흔들렸다. 전 세계 모바일 브라우저에서 Chrome이 약 66%, Safari가 약 23%로 두 진영이 여전히 압도적이다. 아래 표는 개략적인 판세다.
| 구간 | Chrome 계열 | Safari(WebKit) | 기타(Edge·삼성·Firefox 등) |
|---|---|---|---|
| 모바일 전 세계 | ~66% | ~23% | 나머지 |
| iOS 내부 | 껍데기만(엔진은 WebKit) | 사실상 100% 엔진 점유 | 껍데기만 |
| DMA 이후 변화(EU) | 자체 엔진 "허용" | 기본값 지위 약화 | 선택 화면으로 점유율 상승 |
표에서 봐야 할 건 두 번째 줄이다. 엔진 기준으로 보면 iOS는 그동안 WebKit 100% 시장이었다. 겉보기 브라우저 점유율이 어떻든, 렌더링을 실제로 담당하는 엔진은 WebKit 하나였다는 뜻이다. 이게 웹 개발자에게 왜 골칫거리였는지가 다음 이야기다.
WebKit 독점이 개발자에게 왜 문제였나
한마디로 "iOS Safari가 웹의 인터넷 익스플로러가 됐다"는 비판 때문이다. 다른 엔진과의 경쟁이 없으니 새 웹 표준 지원이 느렸고, 그 느린 엔진을 iPhone 사용자 전원이 강제로 써야 했다. 그래서 개발자는 최신 API를 쓰고 싶어도 "iOS Safari가 되나?"를 항상 먼저 확인해야 했다.
구체적인 통증은 이런 식이다. 새로운 CSS나 웹 API가 나오면 Chrome(Blink)과 Firefox(Gecko)는 비교적 빨리 붙는데, WebKit은 몇 달, 심하면 몇 년 뒤에 따라오는 경우가 많았다. 대표적으로 웹 푸시 알림은 iOS에서 한참 동안 아예 없었고(2023년에야 홈 화면 추가 PWA 한정으로 들어왔다), IndexedDB 같은 기본기조차 특정 버전에서 악명 높은 버그를 냈다. 나는 예전에 iOS Safari의 100vh 처리 방식(주소창 높이 계산) 때문에 풀스크린 레이아웃이 잘려서 며칠을 날린 적이 있다.
그런데 왜 iPhone Chrome은 아직도 WebKit인가
허용은 됐는데 실제 도입이 없기 때문이다. 이게 이 사건의 가장 중요한 반전이다. 애플이 문을 열긴 열었지만, 그 문을 통과하는 조건을 브라우저 회사들이 받아들이기 어렵게 만들어 놨다. 2025년 말 기준으로도 자체 엔진을 실제 탑재해 EU에 출시한 iOS 브라우저는 사실상 전무하다.
조건들을 보면 왜 그런지 감이 온다.
- EU 지역 한정. 대체 엔진 브라우저는 EU 사용자에게만 배포할 수 있다. 그럼 회사는 "EU용 자체 엔진 빌드"와 "나머지 전 세계용 WebKit 빌드"를 둘 다 유지해야 한다.
- 기존 앱을 재활용 못 함. 초기 조건상 대체 엔진 앱은 별도 바이너리로 취급돼, 전 세계에서 쓰던 그 앱에 그냥 엔진만 갈아끼우는 식이 어려웠다. 사용자 이관 문제도 걸렸다.
- 운영 부담과 심사. BrowserEngineKit 사용 승인, 보안 요건, 업데이트 대응 등 유지비가 크다.
- 불확실성. 규제·정책이 계속 바뀌는 상황이라, 큰 투자를 걸기에 리스크가 컸다.
그래서 구글과 모질라 모두 "기술적으로는 준비했지만 애플 조건에선 실익이 없다"는 취지로 사실상 관망해 왔다. 개인적으로 이 대목이 제일 씁쓸하다. 문서상으로는 "iOS에서 Blink·Gecko 가능"이 맞는데, 필드에서 개발자가 만나는 iPhone은 여전히 WebKit 100%다. 스펙과 현실의 간극이 이렇게 큰 사례도 드물다.
그럼 소형 브라우저는 왜 점유율이 올랐나
엔진 개방이 아니라 "브라우저 선택 화면" 덕분이다. 두 변화를 헷갈리면 안 된다. 점유율을 실제로 움직인 건 엔진 스왑이 아니라, DMA가 강제한 선택 화면이다. iPhone·안드로이드를 처음 켜거나 Safari/Chrome을 처음 열 때 여러 브라우저 목록을 보여주고 고르게 하는 그 화면 말이다.
그전까지 대부분의 사용자는 기본으로 깔린 브라우저를 그냥 썼다. 선택 화면이 뜨자, 이름을 처음 보는 브라우저들도 목록에 노출되면서 노르웨이의 Vivaldi, 프라이버시·검색 기부로 알려진 독일의 Ecosia, 광고 차단을 앞세운 미국의 Brave 같은 소형 브라우저들이 눈에 띄게 다운로드와 점유율을 늘렸다. 규제가 실제로 시장 다양성을 만든 사례로 자주 인용된다.
| 브라우저 | 출신 | 엔진(데스크톱 기준) | 내세우는 강점 |
|---|---|---|---|
| Vivaldi | 노르웨이 | Blink(Chromium) | 극단적 커스터마이즈·생산성 |
| Ecosia | 독일 | Blink(Chromium) | 수익으로 나무 심기·프라이버시 |
| Brave | 미국 | Blink(Chromium) | 기본 광고·트래커 차단 |
| Firefox | 미국(모질라) | Gecko | 비영리·독립 엔진 |
| Safari | 미국(애플) | WebKit | iOS 통합·에너지 효율 |
재미있는 점 하나. 위 소형 브라우저 대부분은 데스크톱에선 Blink(Chromium) 기반이다. 즉 브랜드는 다양해졌지만 엔진 다양성은 오히려 Blink 쏠림이라는 아이러니가 있다. 웹 표준 관점에서 진짜 필요한 건 "브랜드 경쟁"이 아니라 "엔진 경쟁"인데, 시장은 브랜드 쪽으로만 다양해지는 중이다.
웹 개발자에게 실제로 뭐가 바뀌나
단기적으로 바뀌는 건 별로 없고, 중장기 방향성이 바뀐다. 지금 당장 코드를 뜯어고칠 일은 없지만, "엔진 독점이 완화될 수 있다"는 압력 자체가 WebKit의 표준 추종 속도를 높이는 효과가 있다. 실제로 경쟁 압박이 커진 뒤 애플이 웹 기능 개발에 더 적극적이라는 평가도 있다.
가장 큰 교훈은 방법론 쪽이다. 이런 시기일수록 엔진을 조건 분기하지 말고 기능을 감지하라는 원칙이 더 중요해진다. 브라우저 이름이나 엔진을 UA(User-Agent) 문자열로 추측해 분기하는 코드는 지금도 깨지기 쉬운데, 엔진 구성이 유동적인 시대엔 더 위험하다. 아래처럼 UA 스니핑 대신 기능 감지로 가야 한다.
/* 나쁜 예: UA로 브라우저/엔진을 추측해 분기 */
if (/iphone|ipad/i.test(navigator.userAgent)) {
// "iOS면 무조건 WebKit"이라는 가정 — 이제 깨질 수 있다
useWebkitFallback();
}
/* 좋은 예: 실제 기능이 있는지만 확인 (feature detection) */
if ("share" in navigator) {
navigator.share({ title: "공유", url: location.href });
} else {
showCopyLinkButton(); // 대체 UI
}CSS도 마찬가지다. 특정 브라우저 해킹(@supports (-webkit-touch-callout: none) 같은 iOS 판별 트릭) 대신, 쓰려는 속성 자체를 @supports로 물어보는 게 안전하다.
/* 엔진을 겨냥하지 말고, 기능이 있으면 쓴다 */
@supports (height: 100dvh) {
.hero { height: 100dvh; } /* 동적 뷰포트 단위 지원 시 */
}
@supports not (height: 100dvh) {
.hero { height: 100vh; } /* 예전 방식으로 폴백 */
}크로스브라우저 테스트, 지금 어떻게 챙길까
세 엔진(Blink·WebKit·Gecko)을 자동으로 다 도는 파이프라인을 갖추는 게 정답이다. 엔진 구성이 앞으로 어떻게 바뀌든, 세 엔진을 모두 CI에서 돌리고 있으면 흔들리지 않는다. Playwright가 이걸 가장 편하게 해준다 — 한 API로 Chromium·WebKit·Firefox를 모두 구동한다.
// playwright.config.ts
import { defineConfig, devices } from "@playwright/test";
export default defineConfig({
projects: [
// 세 엔진을 모두 CI에서 돌린다
{ name: "chromium", use: { ...devices["Desktop Chrome"] } },
{ name: "firefox", use: { ...devices["Desktop Firefox"] } },
{ name: "webkit", use: { ...devices["Desktop Safari"] } },
// 모바일 WebKit(iOS 근사) — iOS 대응은 여전히 필수다
{ name: "iphone", use: { ...devices["iPhone 14"] } },
],
});한 가지 현실적인 주의. Playwright의 "webkit"은 애플의 실제 iOS Safari가 아니라 WebKit 오픈소스를 빌드한 근사치다. 실기기 iOS Safari와 미묘하게 다를 수 있어서, 정말 중요한 결제·인증 플로우는 실기기나 BrowserStack 같은 실기기 클라우드로 한 번 더 확인하는 걸 권한다. 나는 자동화 테스트는 다 통과했는데 실제 iPhone에서만 특정 폰트 렌더링이 깨진 걸 뒤늦게 발견한 적이 있다.
그래서 지금 뭘 해야 하나 — 체크리스트
결론적인 실무 지침을 압축하면 이렇다. 화려한 변화는 없지만, 방향은 분명하다.
- iOS 대응을 빼지 마라. 엔진 개방은 "허용"일 뿐 현실은 WebKit 100%다. iOS Safari 테스트는 계속 1순위로 유지한다.
- UA 스니핑을 걷어내라. 브라우저·엔진 이름으로 분기하는 레거시 코드를 기능 감지(
@supports,in연산자)로 교체한다. - 세 엔진 CI를 갖춰라. Playwright로 Chromium·WebKit·Firefox를 자동으로 돌려, 앞으로 엔진 구성이 바뀌어도 대응할 수 있게 한다.
- caniuse를 습관화하라. 새 API를 쓸 때 WebKit 지원 시점을 먼저 확인하고, 없으면 폴백을 먼저 설계한다.
- 규제 흐름을 지켜봐라. DMA 조건이 완화되면 실제 엔진 도입이 시작될 수 있다. 그때가 크로스브라우저 전략을 재검토할 시점이다.
정리하면, 이번 사건은 "당장의 코드 변경"이 아니라 "15년 독점에 처음 생긴 균열"로 기억하는 게 맞다. 웹 개발자 입장에서 진짜 좋은 소식은 iPhone Chrome이 아니라, 그 압력 덕에 WebKit이 표준을 더 빨리 따라올 명분이 생겼다는 점이다. 엔진 하나가 시장 전체를 인질로 잡던 시대가 조금씩 저무는 신호인 셈이다.
자주 묻는 질문
이제 iPhone에서 진짜 Chrome 엔진(Blink)을 쓸 수 있나요?
아직은 사실상 아닙니다. iOS 17.4부터 EU에 한해 대체 엔진 탑재가 허용됐지만, 애플의 조건(EU 지역 한정, 별도 바이너리, 운영 부담)이 까다로워 2025년 말 기준으로 자체 엔진을 실제 출시한 iOS 브라우저는 사실상 없습니다. 지금 iPhone의 Chrome·Firefox는 여전히 내부적으로 WebKit을 씁니다.
그럼 이번 변화가 웹 개발에 당장 미치는 영향은 없나요?
당장 코드를 바꿀 일은 거의 없습니다. 다만 엔진 독점이 완화될 수 있다는 압력이 생기면서, WebKit의 표준 추종 속도가 빨라질 여지가 커졌습니다. 실무에서는 iOS Safari 대응을 그대로 유지하되, UA 스니핑을 기능 감지로 바꾸는 등 앞으로의 변화에 견디는 코드로 정리해 두는 게 좋습니다.
소형 브라우저(Vivaldi·Ecosia·Brave) 점유율이 오른 건 엔진 개방 때문인가요?
아니요. 그건 DMA가 강제한 브라우저 선택 화면 덕분입니다. 사용자가 첫 설정에서 브라우저를 직접 고르게 되면서, 그동안 기본값에 밀려 있던 소형 브라우저들이 노출되어 다운로드와 점유율을 늘렸습니다. 엔진 스왑 허용과는 별개의 변화입니다.
크로스브라우저 테스트에서 iOS Safari를 이제 빼도 되나요?
안 됩니다. iOS의 엔진은 여전히 WebKit 100%에 가깝고, iOS Safari는 점유율 대비 결제·전환 기여도가 높은 경우가 많습니다. Playwright 등으로 Chromium·WebKit·Firefox 세 엔진을 CI에서 모두 돌리는 구성을 유지하는 것을 권합니다.
브라우저 엔진에는 어떤 것들이 있나요?
크게 셋입니다. 구글의 Blink(Chrome·Edge·Opera·삼성인터넷·Brave·Vivaldi 등 대부분), 애플의 WebKit(Safari), 모질라의 Gecko(Firefox). Blink는 원래 WebKit에서 갈라져 나온 포크지만 지금은 상당히 다르게 동작합니다.
UA 스니핑 대신 기능 감지를 써야 하는 이유가 뭔가요?
브라우저·엔진 이름은 위장되거나 바뀔 수 있어 신뢰할 수 없기 때문입니다. 특히 엔진 구성이 유동적으로 바뀔 수 있는 지금은 "iOS면 WebKit" 같은 가정이 언제든 깨질 수 있습니다. @supports(CSS)나 "share" in navigator(JS)처럼 실제 기능 존재 여부만 확인하면 어떤 엔진이든 안전하게 대응됩니다.
DMA는 EU 밖 사용자에게도 적용되나요?
아니요. DMA는 EU 규제이고, 애플의 대체 엔진·선택 화면 조치도 기본적으로 EU 사용자 대상입니다. 그래서 EU 밖 iPhone은 변화가 없고, 이 지역 한정 조건이 브라우저 회사들이 자체 엔진 도입을 주저하는 큰 이유이기도 합니다.
댓글 0