# iOS가 일본에서 대체 브라우저 엔진을 허용 시작 > Clean Markdown view of GeekNews topic #25504. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25504](https://news.hada.io/topic?id=25504) - GeekNews Markdown: [https://news.hada.io/topic/25504.md](https://news.hada.io/topic/25504.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-02T09:49:21+09:00 - Updated: 2026-01-02T09:49:21+09:00 - Original source: [developer.apple.com](https://developer.apple.com/support/alternative-browser-engines-jp/) - Points: 8 - Comments: 3 ## Summary iOS 26.2부터 일본에서는 **WebKit 외의 대체 브라우저 엔진**을 사용하는 앱이 공식적으로 허용됩니다. Apple은 승인된 개발자에게 **JIT 컴파일과 멀티프로세스 접근 권한**을 제공하지만, 보안 개발 프로세스 준수와 쿠키 차단, 메모리 안전성 등 상당히 엄격한 조건을 요구합니다. EU가 아닌 일본을 첫 적용 지역으로 삼았다는 점이 의외인데, Apple이 통제권을 유지한 채 어디까지 변화를 허용할지 지켜보는 재미가 있을 것 같습니다. ## Topic Body - iOS 26.2 이상에서 일본 사용자용 앱은 **WebKit 이외의 브라우저 엔진**을 사용할 수 있으며, 전체 브라우저 앱과 **임베디드 브라우저 엔진을 사용하는 앱** 두 종류가 허용됨 - Apple은 승인된 개발자에게 **JIT 컴파일, 멀티프로세스 지원** 등 고성능 브라우저 엔진 구현을 위한 시스템 기술 접근 권한을 제공함 - 보안 위험을 이유로, Apple은 **엄격한 보안·프라이버시 요건**을 충족하고 지속적인 보안 업데이트를 약속한 개발자에게만 권한을 부여함 - 브라우저 앱과 인앱 브라우징 앱 모두 **테스트 통과율, 메모리 안전성, 취약점 대응, 쿠키 차단 정책** 등 세부 기준을 충족해야 함 - 이번 조치는 일본 시장에서 **브라우저 엔진 선택의 폭을 확대하면서도 사용자 보안을 유지하려는 정책 변화**로 평가됨 --- ### iOS 26.2에서의 대체 브라우저 엔진 허용 개요 - iOS 26.2 이상 버전에서 일본 내 사용자용으로 **WebKit 외의 브라우저 엔진 사용이 허용**됨 - 허용 대상은 두 가지 유형의 앱: 1. **전용 브라우저 앱**(전체 웹 브라우징 경험 제공) 2. **브라우저 엔진 관리자가 제공하는 인앱 브라우징 앱**(임베디드 엔진 사용) - Apple은 승인된 개발자에게 **JIT 컴파일, 멀티프로세스 지원 등 핵심 시스템 기술** 접근 권한을 부여함 - 브라우저 엔진은 악성 콘텐츠와 민감한 사용자 데이터에 노출되므로, Apple은 **특정 기준을 충족하고 지속적 보안 요건을 이행하는 개발자만 승인**함 ### Web Browser Engine Entitlement (전용 브라우저 앱용) - 이 권한을 통해 **대체 브라우저 엔진을 사용하는 브라우저 앱**을 개발 가능 - 신청 전 요건 검토 후 Apple에 요청 제출 필요 - 기술 참고 자료로 **BrowserEngineKit**, **BrowserEngineCore**, **기본 브라우저 설정 가이드** 제공 #### 자격 요건 - 앱은 **일본 내 iOS 전용 배포**여야 하며, 시스템 제공 엔진을 사용하는 다른 앱과 **별도 바이너리**로 구성 - **Default Browser Entitlement**를 보유해야 함 - 기능 요건: - **Web Platform Tests 90% 이상**, **Test262 80% 이상** 통과 - JIT 비활성화 상태(예: Lockdown Mode)에서도 동일 기준 충족 #### 보안 요건 - **보안 개발 프로세스** 채택 및 공급망 취약점 모니터링 - **취약점 공개 정책 URL** 제공 및 제3자 보고 채널 확보 - **30일 내 취약점 완화 조치** 등 신속 대응 의무 - **해결된 취약점 공개 페이지** 운영 - **루트 인증서 정책 공개** 및 CA/Browser Forum 참여 - **TLS 최신 프로토콜 지원** 필수 #### 프로그램 보안 요건 - **메모리 안전 언어** 또는 안전 기능 사용 - **Pointer Authentication Codes(PAC)** , **Memory Integrity Enforcement(MIE)** 등 최신 완화 기술 적용 - **프로세스 분리 및 IPC 검증**, **취약점 우선 해결** - **보안 업데이트 중단된 라이브러리 사용 금지** #### 프라이버시 요건 - **서드파티 쿠키 기본 차단**, 사용자 동의 시만 허용 - **사이트별 스토리지 분리** 및 교차 사이트 접근 차단 - **앱 간 상태 동기화 금지**, 명시적 사용자 허가 시만 허용 - **기기 식별자 공유 금지**, **App Privacy Report 라벨링** 필수 - **PII 접근 API**는 사용자 활성화 및 동의 필요 ### Embedded Browser Engine Entitlement (인앱 브라우징용) - 앱 내에서 **대체 브라우저 엔진을 임베드**해 웹 콘텐츠 표시 가능 - 인앱 브라우징은 웹 브라우저에서 접근 가능한 콘텐츠 표시 목적에 한정 - UI는 **화면 대부분을 차지**, **기본 브라우저로 열기 버튼**, **도메인/URL 표시** 필요 #### 자격 요건 - 신청자는 **브라우저 엔진 관리 주체(browser engine steward)** 여야 함 - 엔진의 **운영·보안 대응 책임**을 직접 지는 조직 - **독립적 아키텍처와 Web API 지원**을 가진 별도 엔진이어야 함 #### 앱 요건 - 일본 내 iOS 전용 배포, **기본 브라우저 권한 보유 금지** - **Web Platform Tests 90%** , **Test262 80%** 이상 통과 - JIT 비활성화 상태에서도 동일 기준 충족 #### 보안 및 프로그램 요건 - **보안 개발 프로세스**, **취약점 공개 정책**, **30일 내 대응**, **TLS 지원** 등 전용 브라우저 앱과 동일 - **메모리 안전 언어 사용**, **최신 보안 완화 기술 적용**, **취약점 우선 해결** 의무 - **보안 업데이트 중단된 라이브러리 사용 금지** #### 프라이버시 요건 - **서드파티 쿠키 차단**, **사이트별 스토리지 분리**, **기기 식별자 공유 금지** - **App Privacy Report 라벨링** 및 **PII 접근 시 사용자 동의** 필요 #### 추가 요건 - 앱 제출 시 **임베디드 엔진 이름과 버전 명시** - 엔진 새 버전 공개 후 **15일 이내 앱 업데이트 제출** ### 개발자 참고 자료 및 보안 가이드 - **Secure SDLC**: 위협 모델링, 코드 감사, 퍼징 테스트 등 보안 중심 개발 권장 - **Memory Safety**: Swift의 기본 메모리 안전성, C/C++의 `std::span`, `-fbounds-safety` 옵션 등 활용 - **Vulnerability Management**: CVE-ID 기반 공개 취약점 관리, 신속한 패치 배포 필요 - **Network Security**: iOS SDK의 **Network framework**, **SecTrust API** 사용 권장 - **TLS 1.2, 1.3** 지원 필수, 구버전 프로토콜 사용 시 사용자 경고 필요 ### 관련 문서 및 계약서 - **Embedded Browser Engine Entitlement Addendum for Apps in Japan** - **Web Browser Engine Entitlement Addendum for Apps in Japan** ## Comments ### Comment 48697 - Author: wedding - Created: 2026-01-05T15:32:03+09:00 - Points: 1 비꼬는건 아닌데 사파리는 저 수많은 요건들을 잘..지키고 있는거겠죠? ### Comment 48606 - Author: kimjoin2 - Created: 2026-01-03T09:55:28+09:00 - Points: 1 Wow 일본에서 시작된것도 신기하네요. 이런건 유럽이나 미국이 먼저가 될 줄 알았는대 ### Comment 48565 - Author: neo - Created: 2026-01-02T09:49:21+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46453950) - 나는 Apple이 경쟁 브라우저를 막을 거라 생각하지 않지만, **그 일이 일어날 것**은 알고 있음 iPhone이 사실상 **Chrome/Chromium 독점**을 막는 마지막 보루라고 생각함 Google이 Microsoft처럼 방치하진 않겠지만, 그만큼의 영향력을 가지게 될 것임 대부분의 사이트가 Chrome에서만 제대로 작동하는 상황은 정말 원치 않음 결국 Apple의 고집이, 의도치 않게라도, 이 흐름을 막고 있는 셈임 - 규제 기관이 Apple의 **독재적 통제**를 전면적으로 제한하길 바람 Chrome이 웹을 지배한다는 걱정은 과장이라 생각함. 새로운 API가 추가된다고 해서 모든 웹사이트가 그걸 쓰는 건 아님 Firefox가 95% 점유율의 IE 시대에도 웹을 구했는데, 왜 지금은 Apple 하나에 의존해야 하는지 모르겠음 이건 일종의 **학습된 무기력** 같음 - Safari가 기본 앱으로 설정되어 있는 한, iOS에서 Chrome이 큰 위협이 될 거라 보지 않음 게다가 모바일 웹 자체가 점점 **앱 중심으로 축소**되고 있음 AI 검색이 웹 검색을 대체하려는 흐름도 있어서, 웹의 영향력은 더 줄어들 것 같음 - 이미 그 배는 떠났음. Apple도 문제의 일부임 예를 들어, FaceTime이 Firefox를 지원하지 않아 Edge를 썼는데, 결국 **Google Meet**으로 옮겨야 했음 - 예전 IE가 새로운 기능을 추가하며 시장을 장악했을 때, 사람들은 오히려 좋아했음 문제는 그들이 **혁신을 멈췄을 때** 시작됐음 ActiveX, Flash, Silverlight 같은 기술들이 보안 문제를 일으키며 웹을 망쳤고, 결국 IE는 개발자와 사용자 모두에게 지옥이 됨 지금의 **Mobile Safari**가 그 역할을 이어받았다고 생각함 나는 PC와 Android에서는 Firefox를 쓰지만, 모바일에서는 **Chromium 기반 브라우저**가 더 나은 선택이라 봄 - Safari가 너무 별로라서, iOS에서 **진짜 Chrome 경험**을 하고 싶음 - 일본의 새로운 규정 중 “**메모리 안전 언어 사용**” 요구사항이 흥미로웠음 그런데 Apple 자신은 이걸 충족할까? WebKit은 C++로 작성되어 있음 “메모리 안전성을 개선하는 기능”이 구체적으로 뭘 의미하는지도 모호함 - WebKit의 [Safer C++ Guidelines](https://github.com/WebKit/WebKit/wiki/Safer-CPP-Guidelines) 문서를 참고할 수 있음 - 언젠가 Apple이 WebKit을 **Swift 기반 엔진**으로 교체하거나 점진적으로 전환할지도 궁금함 - Apple이 아직 전 세계적으로 개방하지 않은 게 놀라움 한 나라에서는 열고, 다른 나라에서는 막는 시스템을 유지하는 건 결국 **혼란과 비용**으로 이어질 것임 - 하지만 Apple은 **수익이 유지되는 한** 계속 이런 방식을 고수할 것임 다국적 기업에게 이런 복잡한 규제 대응은 일상적인 일임 - 기술적으론 가능하지만, 지역별 규칙을 관리하고 직원과 고객을 교육하는 데 드는 **정신적·운영적 비용**이 클 것임 브라우저 엔진 통제는 수익보다 **통제력 유지**의 문제로 보임 - 하루빨리 **Firefox와 uBlock Origin**을 제대로 쓸 수 있길 바람 - “FeatureToggles.swift”라니, 농담 같지만 Apple의 정책을 풍자하는 말 같음 - Apple은 **지시받는 걸 극도로 싫어함** 일본과의 협상은 EU보다 나았지만, 여전히 불만이 많음 그래서 전 세계적으로 쉽게 굴복하지 않을 것임 - Apple이 EU에서 만든 **제3자 브라우저 엔진 허용 규칙**을 일본에도 그대로 적용하는 듯함 하지만 조건이 너무 까다로워서, 실제로 EU에서도 **대체 엔진 브라우저가 출시된 적이 없음** 앱을 완전히 별도의 바이너리로 만들어야 해서, Chrome 같은 대형 브라우저는 전환이 어려움 - 게다가 EU에서는 **개발사가 EU 내에 있어야 함**이라는 추가 제약도 있음 - 일본과 EU의 법이 전 세계적 변화를 유도하길 바랐지만, 대기업들은 **국가별 비효율을 감수할 여력**이 있음 - 하드웨어 측면에서는 USB-C처럼 통일이 이루어졌지만, 소프트웨어는 여전히 분리됨 예를 들어, iPhone은 위치 기반으로 **대체 앱스토어 접근을 제한**함 [관련 기사](https://www.macrumors.com/2024/03/06/alternative-ios-app-sto...) 참고 - 만약 법이 Apple의 **트래킹 투명성 팝업** 같은 기능을 제거하라고 한다면? 이미 두 나라에서 Apple이 그 팝업으로 벌금을 맞았음 - Apple의 많은 정책이 반경쟁적이지만, **브라우저 엔진 제한**은 보안·배터리·표준화 목적이 더 크다고 생각함 - “브라우저 엔진 관리자” 요건을 보면, 사실상 **Google과 Mozilla만 자격**이 있는 듯함 Microsoft조차 Blink 기반이라 제외됨 소규모 엔진들은 기본 기능 요건을 충족하기 어려워, 실질적으로 **진입 불가능**해 보임 - 이젠 iOS에서 **진짜 Firefox + uBlock Origin**을 쓸 수 있을까 궁금함 - Apple은 법의 **문자적 준수**만 할 뿐, 여전히 모든 수단으로 저항할 것임 복잡한 요구사항, 제한된 API, 버그 방치 등으로 개발자들이 고생할 것임 일본 시장만을 위해 완전한 엔진을 이식할 만큼의 **법무·개발 리소스**를 투자할 회사는 없을 듯함 - Mozilla도 **지역별 앱 유지 부담** 때문에 참여하지 않을 가능성이 높음 [관련 기사](https://www.theverge.com/2024/1/26/24052067/mozilla-apple-ios-browser-rules-firefox) - 그동안은 Safari용 [uBlock Origin Lite](https://github.com/uBlockOrigin/uBOL-home?tab=readme-ov-file)를 쓰면 됨 꽤 괜찮음 - EU에서도 같은 규칙이 적용됐지만, **대체 엔진 브라우저는 등장하지 않았음** 지금은 Safari용 uBlock Origin Lite나 다른 광고 차단기를 쓸 수 있음 - 참고로 iOS Safari는 이미 **uBlock Origin Lite**를 지원함 Firefox도 자체 추적 차단 기능이 있음 - Apple이 생태계를 열면 **소비자 친화적 이미지**가 사라질까 두려워하는 사람들을 자주 봄 하지만 “Apple이 통제하지 않으면 혼란이 온다”는 논리는 **양극단의 선택지**일 뿐임 우리는 Apple의 완전 통제와, 사용자 방임 사이의 **중간 지점**이 필요함 시장이 경쟁적으로 작동하지 않는다면, 규제가 사용자와 개발자를 보호해야 함 Apple이 하드웨어를 잠그는 건 **위험한 선례**이며, 다른 기업들이 이를 따라할까 우려됨 - Apple은 iOS의 **혁신 속도와 방향을 직접 통제**함 새로운 기능이나 앱은 Apple이 허락하지 않으면 존재할 수 없음 Dropbox, GDrive 같은 서비스도 Apple의 **버그 많은 백엔드**에 맞추느라 기능을 잃었음 이런 구조는 비정상적임 - 대안은 결국 **Android**밖에 없는 걸까? - Apple의 **별도 바이너리 요구**는 사실상 법 위반 수준임 로그인 상태 공유 금지, 쿠키 차단 강제 등은 OS가 할 일이 아님 심지어 Apple 자신은 **30일 내 보안 패치 규정**을 지키지 않음 - Apple이 특정 국가에서만 예외를 두기 위해 **극단적인 노력**을 기울이는 게 놀라움