요약

  • W3C가 2019년 12월 공개한 첫 Web Share 초안은 웹사이트가 글이나 URL을 건네고, 사용자 에이전트가 공유 대상을 고르는 화면을 제공하는 흐름을 설명했다.
  • 2023년 5월 권고안은 파일, canShare() 검사, 사용자 동작으로 시작하는 share()와 취소 처리를 다뤘다.

한때 기사 옆 공유 버튼은 작은 상가 같았다. 이 서비스로 보내기, 저 서비스에 올리기, 이름을 처음 듣는 곳으로 건너가기. 정작 독자가 쓰는 앱은 그 줄에 없을 수 있었다. 웹사이트는 독자의 휴대전화 안에 살지 않는다. 누구에게 보낼지, 자기 메모에 담아 둘지, 가까운 기기에 넘길지 알 길도 없다. 그런데도 버튼 줄은 아는 체하기 바빴다.

휴대전화는 자기 문을 안다. 지금 쓸 수 있는 앱과 공유 방법을 알고, 선택지를 어떻게 그릴지도 결정한다. 사이트는 기사에 관해서 안다. 제목, 짧은 설명, 정확한 URL을 줄 수 있다. Web Share API는 이 두 종류의 지식을 한 창구에서 만나게 했다. 사이트가 꾸러미를 내밀면 기기가 문을 보여 주고, 마지막으로 독자가 손가락을 움직인다.

2019년 12월 17일 공개된 W3C 첫 공개 작업 초안에는 버튼을 누른 뒤 navigator.share()에 제목과 URL 같은 정보를 건네는 예가 나온다. 사용자 에이전트가 대상을 고르는 창을 연다. 초기 데이터 항목은 제목, 텍스트, URL이었다. 사이트가 모든 기기의 앱 목록을 관리해야 한다는 요구는 없다.

덕분에 편집자는 버튼 하나를 정직하게 만들 수 있다. 독자는 기사를 친구에게 보내거나, 나중에 볼 메모에 보관하거나, 그 순간 기기에 나타난 다른 곳으로 옮길 수 있다. 기기의 선택지가 바뀌어도 기사 주소는 그대로다. 독자의 습관을 추측해 쌓아 놓은 로고보다, 목적지가 열려 있는 버튼 하나가 오래간다.

2023년 5월 30일 W3C 권고안에는 파일도 공유 자료로 등장한다. 규격의 예는 File을 files 배열에 담는다. navigator.canShare(data)는 선택 창을 열기 전에 그 자료를 공유할 수 있는지 확인한다. 택배 창구에서 상자를 먼저 재 보는 셈이다. 실제 선택을 시작하는 호출은 share()다.

공유는 사용자의 동작을 바탕으로 시작한다. 버튼을 누르는 장면이 가장 익숙하다. 권고안은 이미 진행 중인 공유, 거절, 취소도 다룬다. 독자가 창을 열었다가 닫을 수 있다는 뜻이다. 그때 페이지는 원래 읽던 자리로 자연스럽게 돌아가면 된다. 보내기를 그만둔 사람에게 실패했다고 야단치는 버튼은 어딘가 사람을 잘못 배웠다.

어느 목적지가 보이는지는 사용자 에이전트의 환경에 달렸다. 앱, 웹사이트, 연락처가 대상이 될 수 있다. 어떤 전화기는 공유 시트를, 다른 기기는 별도 메뉴를 보여 준다. 규격이 모든 화면의 생김새를 하나로 묶지는 않는다. 약속하는 것은 자료를 넘기는 방식과 최종 선택의 자리다.

W3C의 공개 이력을 보면 첫 공개 초안은 2019년, 권고안은 2023년에 나왔다. 그 사이 파일과 사전 확인에 관한 설명이 정리됐다. 그러나 이야기의 중심은 그대로다. 사이트가 봉투를 건네고, 기기가 문패를 보여 주고, 사람이 하나를 가리킨다.

사이트가 지켜야 할 몫도 뚜렷하다. 공유 창의 제목이 실제 기사와 다르면 잘못 적은 택배 송장이다. URL이 엉뚱한 페이지를 열면 화려한 선택 화면도 소용없다. 내용과 주소를 정확히 적는 일은 기기에 떠넘길 수 없다.

Web Share API가 남긴 인상적인 장면은 결국 작은 양보다. 웹사이트는 독자의 연락처를 꿰고 있지 않아도 기사를 건넬 수 있다. 다만 문턱에서 멈추고, 어느 문을 열지 고르는 사람에게 공간을 내줘야 한다.