일본: Apple, 12월까지 브라우저 엔진 금지 해제해야 함

• 일본 정부가 최근 스마트폰법을 통과시켜 Apple의 iOS에서 타사 브라우저 엔진 금지를 직접적으로 금지함
• 그동안 WebKit 엔진 강제로 인해 iOS 브라우저 경쟁이 사실상 차단되고, 웹앱들의 경쟁력이 저하되었음
• 새로운 가이드라인은 Apple이 기술적·상업적으로 비현실적인 방해도 허용하지 않음을 명시함
• 또한 브라우저를 위한 OS API 접근권이 기능상 동등하게 보장되어야 하며, 차별적인 성능 저하가 불가함
• 일본법 시행으로 EU·영국과 함께 브라우저 경쟁 복원을 위한 규제 환경이 조성되고 있으며, 2026년이 전환점이 될 전망임

---

일본, Apple의 브라우저 엔진 금지 해제 요구

일본은 최근 공식적으로 ‘스마트폰 소프트웨어 경쟁 촉진법’을 통과시켜, Apple이 iOS에서 타사 브라우저 엔진을 금지하는 오랜 정책을 직접적으로 금지함의 조치를 시행함

브라우저 엔진 금지 현황

• 기존에는 Apple이 WebKit 엔진만 사용을 허용해, Firefox, Chrome, Edge, Opera, Brave, Vivaldi 등 모든 주요 브라우저 엔진이 iOS에서 배제되는 효과가 있었음
• 이는 실질적으로 브라우저 경쟁이 차단되고, 웹앱이 네이티브 앱과 동등하게 경쟁하는 데 필요한 API나 성능을 사용할 수 없는 상황을 초래함

일본의 법제화 및 가이드라인

• 이 법은 디지털시장경쟁본부의 보고서를 기반으로 기획되었고, Open Web Advocacy의 자문도 반영됨
• 최근 모바일 소프트웨어 경쟁법(MSCA) 가이드라인이 출간되어, 법의 실제 해석과 집행 방식을 명확히 제시함

대안 브라우저 엔진 방해 금지

• 가이드라인은 제3자 브라우저 엔진의 도입을 방해하거나 저해하는 모든 행위를 명시적으로 금지함
  • 앱 공급자에게 과도한 기술적 제약을 가하거나, 비용 부담을 지우거나, 사용자를 대체 브라우저로부터 멀어지게 하는 조치 등이 이에 포함됨
  • 방해 행위 판단 시 공급자가 명백히 금지하는 경우 뿐만 아니라, 현실적으로 도입 가능성이 현저히 낮아지는 경우까지도 해당함
• 이 조항은 Apple이 명목상 허용하더라도 사실상 사용 불가하거나 상업적으로 의미 없는 상황을 허용하지 않음을 의미함

OS API 접근의 기능적 동등성

• MSCA는 OS API 접근권에 대해 기능적으로 동등한 접근을 보장하도록 규정함
• 대안적 API 제공이 허용되지만, 실질적으로 현저히 열등한 성능의 경우 기능적 동등으로 간주하지 않음
  • 즉, 기술 방식이 다르더라도, Apple 등 지정 공급자가 누리는 수준의 동등한 성능과 접근성을 타사 브라우저도 보장받아야 함

브라우저 선택 화면(Choice Screen) 의무

• 법은 브라우저(및 기타 소프트웨어)에 대해 선택화면(Choice Screen) 제공을 의무화함
• EU보다 강화된 지침으로, "최초 활성화 직후" 즉시 선택 화면을 표시해야 함
  • 스마트폰 첫 설정 시나 해당 앱 첫 실행 시, 사용자에게 특정 소프트웨어 선택을 유도해야 함

향후 동향

• 모바일 소프트웨어 경쟁법은 2025년 12월 시행 예정임
• 일본은 EU, 영국과 더불어 Apple이 타사 브라우저 엔진을 허용해야 하는 국가에 합류함
• 일본은 유럽·영국의 규제 경험을 참고해 집행을 준비할 것으로 예상됨
• EU와 영국 사례에서 보듯, 실질적 집행은 장기적이고 복잡한 절차가 될 전망임

결론 및 시사점

• 일본, EU, 영국 모두 Apple의 타사 브라우저 엔진 지원 의무화로 iOS에서의 실질적인 브라우저 경쟁 복원이 추진 중임
• 2026년이 브라우저 시장 구조 변화의 전환점이 될 가능성 있음
• 최종적인 성패는 규제 당국의 집행 의지와 Apple의 실질적 개선 노력에 달려있음
• 브라우저 및 웹앱 경쟁 환경 개선을 위해 오랜 기간 노력을 기울여온 일본 정부 및 관계 단체의 역할이 강조됨

[galadbran]

흠... 저는 모든 브라우징 기능이 기반 라이브러리를 거치는 방식이라 시스템에서 특정 URL을 차단하면 모든 앱의 내부 브라우징 기능에서 우회할 수 없는 일관성이 좋은데 아쉽긴 하네요.

[tensun]

AI 브라우저 약진이 예상 됩니다

[prunusnira]

개발자 입장에서는 고려해야 할 환경이 더 늘어나는 결과가 되겠네요 ㅎㅎ..

[ndrgrd]

이제 웹 표준대로 개발해야죠. 없는 기능은 적극적으로 쓰지 말고.

[aqqnucs]

개수가 많아보이긴 하는데 결국엔 파폭이랑 크로뮴 엔진 아닌가요

[kwj9211]

금지 현황에 언급된 엔진 목록만 봐도 어지럽네요 @_@

[GN⁺]

Hacker News 의견

• 모두가 Chrome 얘기를 하고 있지만, 난 Android에서 Chrome을 꺼두고 Firefox를 사용 중임. 모바일 Firefox에 uBlock Origin을 넣어 쓰면 거의 데스크톱 웹 경험과 비슷함 느낌임. 광고 차단뿐 아니라, :has-text 등의 RegEx 규칙으로 내가 신경 안 쓰는 요소들도 바로바로 차단할 수 있음. Chrome은 이젠 데스크톱에서도 이런 걸 못함. Android를 메인 디바이스로 아예 옮길까 고민 중일 정도임. 다만 iMessage 때문에 맥북에서 바로 채팅 답장하는 편리함이 너무 커서 쉽게 못 끊겠음. 그거 빼면 Android가 전반적으로 훨씬 나음. iOS 키보드나 Siri 얘기는 꺼내지도 말아야 할 정도임

  • FF와 uBO 조합이 Android에 남게 만든 킬러앱임. Apple이 저걸 허용했다면 진작 넘어갔을 거임. 혹시 messages.google.com 고민해본 적 있음? Google의 메시지 앱이 필요하고(삼성 메시지 아님), 데스크탑에서 SMS와 RCS를 쓸 수 있어서 iMessage 대체로 딱임

  • 모바일 Firefox에서 consent-o-matic 확장도 정말 쓸 만함. 거의 모든 쿠키 배너를 자동으로 클릭해 넘겨줘서, 모바일에서 일일이 처리할 필요 없고 훨씬 편함

  • 나도 https://messages.google.com 사용해서 Android 기반의 데스크톱 iMessage 같은 환경을 만듦. 혹시 본인 용도에도 맞을지? 나는 iMessage를 안 써서 잘 모를 수는 있음

  • iMessage 없이 그냥 SMS로 가능하다면, KDE Connect로 Android에서 훌륭하게 데스크탑 메시징이 가능함(Linux, Windows, MacOS에서 쓸 수 있음, 플랫폼별 기능 차이는 있지만 SMS는 전부 지원함). https://kdeconnect.kde.org/

• 일본이 Apple이 EU에서 보여줬던 ‘말장난식 규정 준수’ 사례에서 교훈을 얻은 듯 보임. 이런 식으로 나온다면 Apple이 진짜로 타격 받는 제대로 된 벌금을 일본에서도 맞게 되길 바람. "if"가 아니라 "when"이라고 생각함

  • 판매 및 수입을 금지하는 상상도 해봄, 그러면 Apple Store를 얼마나 오래 닫아야 Apple이 무릎을 꿇을지 궁금함

  • 나는 스스로 뭔가 실수하는 걸 막아주는 walled garden이 좋음. Apple이 내 좌표를 함부로 넘겨주거나 이상한 Monarch가 나를 추적한다든가, 사생활 유출 걱정도 줄어드니까 고마움. (+4500 upvotes) Reddit에서 안티-Apple 헤드라인이 +3만 업보트 받으면서, 정작 프로-Apple 댓글이 그에 비해 훨씬 적어서 항상 의심스러웠음. 마케팅팀이나 트롤팜이 평판관리를 했던 게 아닐까 생각함

• 이 글로벌 입법 움직임이 iOS의 더 개방적인 앱 생태계로 이어진다면 정말 환영할 만함. BrowserEngineKit은 XPC와 iOS 확장 시스템의 얇은 래퍼에 불과함. XPC가 오픈 API였다면, 그리고 Apple의 허락 없이도 격리된 서브프로세스에 JIT을 허용했다면 개발하기 훨씬 좋았을 것임. 예를 들어, 메신저 앱이 신뢰하지 못하는 입력값을 처리하는 별도 서브프로세스를 둘 수 있고(iMessage는 이미 하고 있음), 앱의 불안정한 컴포넌트를 격리해서 사용성이나 크래시 복구가 나아질 수 있고, 레트로 시스템 에뮬레이터 속도가 훨씬 빨라지고, iOS에서 WASM 활용도 가능하게 됨, 브라우저 역시 특수 목적 API 없이도 XPC를 쓸 수 있었을 것임. 문제는, 이런 게 가능해지면 앱 스토어 심사 이후에도 네이티브 속도로 돌아가는 코드를 앱 안에 로딩하는 게 쉬워지고, 다들 알다시피 그런 세상이 온다면 재앙이 올 거란 얘기임

  • 그 ‘재앙’이 오면 MacRumors 같은 사이트에서 사람들 난리나는 걸 구경하고 싶음. Apple이 스스로 경제적 이익을 위해 인터넷 내 내러티브를 밀어주는 사이트, 홍보를 후원하지 않을 거라고 순진하게 생각하긴 힘듦. 예를 들어, 폰을 자유롭게 쓸 자유가 모두의 보안과 프라이버시를 위협한다는 식의 말도 안 되는 의견이 사실상 계속 반복되고 있음

  • 이렇게 하면 시스템 수준 맬웨어 방지 부담이 앱 샌드박스에 굉장히 많이 넘어가게 됨. 사실 지금도 샌드박스는 노터리제이션, 권한, 앱 심사 등 여러 방어 레이어 중 하나였음. 나도 사용자가 원하는 앱은 뭘 깔든 찬성하지만, 이렇게 하면 일반 아이폰이 Android처럼 맬웨어 감염에 더 쉽게 노출되는 현실도 인정할 필요 있음. Apple이 이런 정책을 취하는 배경에는 독점욕 외에도 실제 보안 문제도 있음(비록 주동력은 이익일 가능성이 크지만)

  • 브라우저 자체도 일종의 앱스토어라서, 사실상 우린 매번 Apple의 심사 없이 거기서 앱을 돌림. 이런 맥락에서 왜 AppStore의 보안성을 Apple과 팬들이 그토록 강조하는지 잘 이해 안 감

  • JIT 허용이 되면 단순히 빠른 에뮬 수준에서 끝나는 게 아니라, 해석기로 뺑뺑이 안 돌려도 되니 효율도 좋아지고, 배터리 수명 관리나 2008년 게임 돌릴 때 폰 발열 문제도 개선 가능한 것임

  • (의미 없는 의견은 생략)

• “차단 가능성”을 넓게 해석하면 예를 들어, “대체 브라우저 엔진이 일본 Apple 계정에만 출시 가능하도록 리전락 걸기” 같은 것도 본질적으로 대체 브라우저의 실질적 존재 자체를 막는 것으로 간주할 수 있음. Mozilla도 그런 식이면 타겟층이 너무 작아서 iOS용 Firefox 포팅할 이유가 없어짐. 현실성은 낮지만, 어쩌면 이게 글로벌 브라우저 선택권의 작은 출발점일 수도 있겠음

  • 리전락 해서 특정 계정에만 대체 브라우저 엔진 허용, Apple이 EU에서 하고 있는 것 중 하나임

  • Gecko(Firefox 엔진)는 이미 iOS에 포팅된 것으로 알고 있음

  • 시장 점유율이 원래 적은데 그걸 극소수만 더 늘리자고 포팅할까 의문임

  • Mozilla는 원래 소수점유율에 익숙한 조직임. 이런 상황도 그다지 다르지 않을 거고, 오히려 시장 오픈 전에 사용자를 통한 QA 버전 배포 기회가 될 수도 있음

• EU와 UK에 이어 일본도 iOS 대체 브라우저 엔진 금지에 이제 종지부를 찍음. 세 군데 모두 큰 시장이라서 Chrome이나 Firefox가 iOS용 자체 엔진을 쓴 버전(즉 Blink와 Gecko 기반 브라우저)에 투자할 동기가 충분히 생기는지 궁금함. 그동안 이 이유 때문에 개발이 지체됐다는 소문 많았음

  • 같은 사이트에서 보니 Apple이 여전히 대형 브라우저 업체가 자체 엔진을 내지 못하도록 온갖 방해를 하고 있음 관련 블로그

  • UK의 경우 2024년 Digital Markets Act 등 관련 법을 정부가 소극적으로 집행한다는 얘기로 알고 있음

  • 일본 문화상 이런 변화에 크게 신경이 쓰이지는 않을 거임. 일본의 Linux 활용도를 보더라도, 소수 열혈 사용자들은 무슨 일이 있어도 계속 그걸 쓰지만, 일반 대중은 편한 걸 그냥 씀. 시스템이나 설정 뜯어고치는 걸 별로 좋아하지 않음

  • Apple이 브라우저 개발자들을 워낙 힘들게 해서 누구도 그 장벽을 못 넘었기 때문이라는 시각도 있음

  • Firefox가 Blink로 스위치해서 Google과 협력해서 iOS용 대체 엔진을 만드는 게 현실성 있고 더 쉬운 선택이 아닐까 고민됨

• 이런 변화가 과연 좋은 것인지 궁금함. 시장에서 Chromium 점유율을 더 키워주는 결과 아닌지 고민됨

  • Safari는 구조적으로 좋은 브라우저가 아님. Apple의 이해관계상 웹 플랫폼을 일부러 미약하게 만들기 때문임. 제대로 된 경쟁 브라우저가 아니면 억지로 사용하게 할 수 없으니, 사용자가 선택하는 진짜 좋은 브라우저를 만드는 게 진짜 시장경쟁임

  • 그렇긴 함. 결국 Safari가 iOS에서 웹 전체가 "All Chrome Everywhere"로 바뀌는 걸 억제하는 마지막 보루였음

  • 정부가 시장 독점을 해결할 수도 있음 미 법무부 vs Google 소송 위키

  • 맞음, 그래서 고민이 복잡함. 한편으론 Apple이 반드시 iOS를 더 개방하게 만들어야 하지만, 또 한편으론 결국 Chrome 독점이 강화됨

  • 제대로 된 Firefox를 iOS에서 쓸 수 있게 되는 장점이 큼. 그리고 이건 긍정적인 변화임. Apple이 Web 표준을 자기 이익 위해 깎아내리는(예: WebGPU에서 SPIR-V 지원 방해) 합당치 않은 영향력이 줄어듦

• (Narrator) 1년 후 일본에서 Chrome 점유율이 100%에 달했고, 모든 웹사이트가 오로지 이 브라우저용으로만 설계됨

  • 기본값의 힘을 너무 무시하는 것임. 대부분의 사용자는 시스템 기본 설정을 거의 바꾸지 않음

• 일본은 Apple과 독특한 관계임. 예를 들어, Felica(일본식 NFC 시스템) 기반 티켓 기능이 모든 iPhone에 내장돼 전 세계 iOS 사용자도 일본에서 훨씬 편하게 삶을 누릴 수 있음. 더 놀라운 건 실제 티켓 사용에 그 어떤 앱도 필요 없이 Apple Pay만 있으면 된다는 점임. 이런 흐름이 점점 네이티브 앱의 강점 자체를 좁히고 있음(아직까지는 네이티브 앱에도 고유 장점이 남아있지만), 한편으론 Apple이 결국은 ‘문지기 역할’을 다른 영역으로 옮긴다는 주장에 반박하기 힘듦

  • FeliCa 네트워크 지원은 일본에서 모바일 교통과 결제 기술이 iPhone보다 먼저 자리 잡았던 것이 주된 이유임. Mobile Suica와 Osaifu-Keitai가 있던 상황이라, Apple이 경쟁력을 유지하려면 적극적으로 따라붙을 필요가 있었음. 일본 한정 SKU iPhone에서 시작해서 이후에 글로벌로 확장된 것임. 심지어 지금도 일본에선 모바일 결제시장이 독점이 아님. Apple이 경쟁 압박을 받으면, Suica 같은 엑스프레스 트랜짓을 추가하는 등 변화가 일어남. 그리고 PayPay처럼 일본산 QR코드 결제앱이 신용카드 결제보다 더 보급되어 있음

  • 일본의 iOS 점유율은 미국(59%)이나 UK(47%), 유럽(34%)보다 더 높아서 64%임 statcounter 출처

  • FeliCa는 특허 라이선스 문제임. Apple이 어디선가 유리한 계약을 따낸 듯함. Google Pixel도 칩은 다 들어가 있지만, 일본 모델 아닌 경우에는 그 기능이 소프트웨어로 막혀 있음(루팅하면 풀 수 있음)

• "할 수 있다는 힘"의 위력을 실감함. 한 나라가 해내면, 20년간 불가능하다던 다른 나라들도 ‘우리도 할 수 있는데 뒤처질 순 없다’라고 변화하게 됨

  • 그게 오히려 무서울 수도 있음. 예를 들어, UK에서 실명 ID 나이 인증을 도입한 후로, 다른 나라들이 정부 발행 ID 관련 법안을 우후죽순 도입하는 사례도 있음

• Google이 ‘진짜’ Chrome을 iOS에 내놓을 수 있도록 꾸준히 준비해왔다는 전제를 가질 수밖에 없음. 아마 법 개정 타이밍에 바로 출시하려고 오래 전부터 만들었겠지?

  • Google이 Blink(iOS용 Chrome 엔진)을 옮기는 중이며 점진적으로 진척이 있음. Chromium 버그트래커에 트래킹이 올라와 있음 트래킹 링크. 아마 Apple의 지역락(EU geofencing) 정책과 BrowserEngineKit의 여러 제한 때문에, 아직 실서비스용으로 리소스 투입이 덜 된 상황임

  • 2023년 2월: “Google, iOS에서 Apple WebKit 대신 Blink 엔진으로 Chrome 구동 작업 시작” 관련 기사

  • (Blink는 Chrome의 웹 렌더링 엔진임) iOS용 Chromium/Chrome을 빌드하는 방법 공식문서에 보면 ‘blink web platform’은 실험적이라 분석용으로만 사용하라는 안내가 있음. 관련 타겟으로 content_shell과 chrome이 유용하다고 명시됨. 공식 빌드 문서