웹 앱 설치를 둘러싼 교착 상태 — WebKit은 왜 installable web app에 제동을 거는가

본문

저자인 Jeremy Keith는 W3C의 초청 전문가(invited expert)가 되었다고 밝힙니다. 그는 이것이 대단한 일이 아니라며, 누구든 신청하고 승인되면 될 수 있는 자격이라고 설명합니다. installable web app, 즉 PWA 문제에 의견을 낸 이후 web applications working group의 초청 전문가가 되라는 강한 권유를 받았고, 첫 회의는 web apps 그룹이 아니라 큰 그림의 쟁점이 있을 때 다른 그룹을 돕는 메타 그룹인 Technical Architecture Group(TAG)과의 통화였다고 합니다.

WebKit이 거부하는 '전제'

회의에서 대부분의 참가자, 즉 브라우저 벤더들은 installable web app을 지원하기 위해 어떤 API를 구현할지 세부 사항을 논의하는 데 시간을 쓰고 싶어 했습니다. 반면 WebKit은 그 작업의 전제 자체를 거부했습니다. WebKit이 밝힌 입장은 이렇습니다. 개발자가 사용자에게 현재 웹사이트를 설치할 수 있는 방법을 제공해서는 안 되며, 설치는 브라우저에 맡겨야 한다는 것입니다. 또한 통계를 보면 사용자가 정말 이 기능을 원하는지도 의문이라고 덧붙였습니다.

저자는 이미 사용 가능한 웹 앱 설치 방법이 있다면 그 주장이 합리적일 수 있다고 인정합니다. 하지만 현실은 그렇지 않다고 지적합니다. iPhone에서 웹사이트를 홈 화면에 추가하는 것은 기술적으로는 가능하지만, 실질적으로는 복잡하고 난해한 사용성 악몽이라고 표현합니다. 한편 네이티브 앱은 'smart app banners', 저자가 'dickovers'라고 부르는 배너를 통해 사용자에게 적극적으로 노출되기 때문에, WebKit의 태도가 일종의 악의적 준수(malicious compliance)처럼 보이기 쉽다는 음모론적 해석의 유혹도 언급합니다.

WebKit의 인지 부조화

저자는 회의에서 드러난 WebKit 입장의 모순을 두 갈래로 분석합니다. 첫째, WebKit은 웹 앱 설치가 북마크와 비슷하다고 주장합니다. 북마킹 API가 없으니 설치 API도 필요 없다는 논리입니다. 저자는 북마크와 설치의 사용자 인터페이스가 비교 가능하다면 타당한 지적이겠지만, 북마크는 수십 년의 관례에 뒷받침되어 브라우저 경험의 정중앙에 있는 반면 웹 앱 설치는 '공유' 아이콘 뒤 다섯 단계 깊이에 묻혀 있다고 반박합니다. 게다가 논의 중인 API는 설치 자체를 수행하는 API가 아니라, 그 묻혀 있는 메뉴 항목이 발동하는 것과 동일한 설치 플로우를 개시하는 API이며, 그 플로우는 취소 옵션을 눈에 띄게 제시하는 것으로 시작한다고 강조합니다. 따라서 사용자가 속아서 홈 화면에 앱을 추가하게 된다는 식의 공포 조성은 부당하다는 것입니다.

둘째, WebKit은 설치된 웹 앱이 더 강력한 API에 접근하게 될 것을 우려합니다. 저자는 이 우려 자체에는 동의합니다. 홈 화면에서 실행된 웹 앱이 특별한 권한을 가져서는 안 되며, geolocation 같은 기능은 브라우저 안의 페이지와 마찬가지로 사용자 허가를 받아야 한다는 것입니다. 그런데 저자는 여기서 결정적 모순을 짚습니다. 그렇다면 Apple은 왜 push notifications를 설치된 웹 앱으로 제한했는가 하는 점입니다. 다른 브라우저들은 push notifications 같은 권한 기반 API를 문제없이 구현해 왔는데, Apple은 이 API를 안전하게 구현하는 유일한 방법이 설치된 웹 앱으로 제한하는 것이라고 판단했습니다. 정리하면 WebKit은 한편으로 설치는 북마크처럼 사소한 일이라고 말하면서, 다른 한편으로는 설치가 특별한 권한을 부여하는 중대한 일이라고 말합니다. 어느 쪽이냐는 것이 저자의 질문이며, 그는 WebKit이 성실하게 논의에 참여하기보다는 이 주제의 진전에 발목을 잡기로 이미 결론 내린 것 아니냐는 의구심을 드러냅니다.

개발자를 대표해 발언한 네 가지 요지

저자는 회의에서 개발자의 이해관계를 대변하는 역할로 10분의 발언 시간을 배정받았습니다. 그가 정리한 요지는 다음과 같습니다. 첫째, 개발자들은 설치 플로우를 개시할 방법을 원합니다. 대안이 브라우저별 안내 문구를 제공하는 것인데, 이는 언제나 나쁜 신호입니다. 둘째, 브라우저가 눈에 띄고 사용 가능한 설치 플로우 개시 방법을 제공했다면 이 요구가 이렇게 긴급하지는 않았을 것입니다. 셋째, 사용자는 네이티브 앱을 설치할 수 있는 것처럼 웹 앱도 설치할 수 있어야 합니다. 기술적으로는 두 선택지가 모두 존재하지만 실질적으로는 저울이 네이티브 앱 쪽으로 매우 크게 기울어 있습니다. 넷째, 네이티브 앱은 웹 앱과 다른 보안 모델을 가지며 사용자 데이터에 훨씬 넓게 접근할 수 있습니다. W3C가 보안과 프라이버시를 사용자에게 중요한 가치로 여긴다면, 저울을 다시 웹 앱 쪽으로 기울이기 위해 할 수 있는 모든 것을 해야 합니다.

Lobsters 반응

• 댓글 없음 — 커뮤니티 점수 9, 댓글 0으로 등록된 토론이 아직 없습니다.

원문: Adactio (Jeremy Keith) / 번역·요약: Trawling