웹 MVP Web Share Target: 설치·수신·저장을 나누는 5가지 기준
모바일에서 읽던 링크를 “우리 서비스에 저장”하게 만들고 싶을 때, 공유 버튼 하나를 추가하는 일과 시스템 공유 시트에서 우리 웹앱을 받는 쪽으로 보이게 하는 일은 다릅니다. Web Share Target은 설치된 PWA가 시스템 공유 대화상자에서 공유 대상이 되도록 선언하는 방식입니다. 따라서 MVP의 핵심 질문은 “공유 버튼이 있나?”가 아니라, 어떤 사용자가 어떤 데이터를 어떤 화면에서 받아 최종 저장을 확인할지입니다.
먼저 설치 가능한 웹앱 여부, manifest의 share_target 선언, 들어오는 GET·POST 요청, 입력 검증, 사용자가 확인한 저장 결과를 다섯 단계로 나누세요. 기능 선언이나 테스트 기기에서의 노출만으로 모든 브라우저에서의 지원, 안전한 저장, 실제 이용을 뜻하지는 않습니다.
1. ‘보내기’와 ‘받기’부터 분리합니다
Web Share API는 웹페이지가 다른 앱으로 데이터를 보내는 API이고, Web Share Target은 PWA가 다른 앱이나 웹에서 공유한 내용을 받는 쪽으로 선언하는 manifest 기능입니다. 같은 ‘공유’라는 말 때문에 둘을 한 작업으로 묶기 쉽지만, 전자는 발신 화면의 행동이고 후자는 수신 앱의 등록·도착·처리 흐름입니다.
예를 들어 팀의 리서치 도구에서 외부 기사 링크를 수집하려면, 공유 시트에 앱 이름이 보이는지와 공유된 링크를 새 수집 초안에 넣는지는 별개입니다. 사용자가 링크를 보낼 수 있어도 시스템이 앱을 공유 대상으로 표시하지 않을 수 있고, 표시되어도 서버가 입력을 검증하지 않은 채 곧바로 저장하면 중복·잘못된 형식·의도하지 않은 저장 문제가 생길 수 있습니다.
상태 | 결정할 질문 | 출시 전 확인 |
|---|---|---|
제품 범위 | 링크·메모·파일 중 무엇을 받을 것인가 | 첫 공유 흐름과 저장 전 확인 화면 |
공유 대상 선언 | PWA manifest에 어떤 action과 params를 둘 것인가 | manifest와 action 경로의 범위 일치 |
수신 요청 | GET으로 초안을 열 것인가, POST로 저장 후보를 받을 것인가 | 실제 공유 시트에서 들어온 요청 기록 |
입력 검증 | 어떤 값·파일 형식·길이를 허용할 것인가 | 비정상 입력과 중복 입력 처리 결과 |
사용자 완료 | 사용자가 무엇을 확인한 뒤 저장되는가 | 초안·확정 저장·오류 안내를 분리한 화면 결과 |
2. manifest는 수신 형식을 약속하는 문서입니다
MDN은 share_target 객체에 action과 params가 필요하다고 설명합니다. action은 공유를 받았을 때 열 경로이고, params는 title·text·url을 어떤 이름으로 넘길지 정합니다. 즉 manifest를 넣었다는 기록은 제품 데이터 모델을 정했다는 뜻이 아닙니다. 받은 값이 ‘초안 제목’인지 ‘원본 URL’인지 팀이 먼저 정해야 합니다.
W3C 초안은 action이 manifest scope 안에 있고 신뢰할 수 있는 origin이어야 하며, method는 GET 또는 POST라고 규정합니다. 경로 하나를 정할 때에도 공개 보기 화면, 인증 뒤 저장 화면, 운영자 화면을 같은 action으로 합치지 않는 편이 좋습니다. 공유로 바로 들어온 사용자가 로그인되어 있지 않을 때 어디로 이동할지, 로그인 뒤 원래 입력을 보존할지도 제품 흐름으로 설계해야 합니다.
MVP의 수집·저장 흐름과 출시 전 검수 기준을 함께 정리하기
3. GET·POST와 파일 수신은 서로 다른 결정입니다
링크나 짧은 메모처럼 사용자가 내용을 확인한 뒤 저장할 데이터라면 GET으로 수신 화면을 열고, URL 검색 매개변수에서 값을 읽어 초안을 보여 주는 흐름을 검토할 수 있습니다. 반대로 공유 요청이 데이터 생성처럼 즉시 부작용을 일으키거나 바이너리 파일을 포함한다면 MDN은 POST를 사용하도록 안내합니다. 파일을 받으려면 POST와 multipart/form-data, 그리고 허용 MIME 유형 또는 확장자를 명시한 files 설정이 필요합니다.
여기서 POST가 ‘자동 저장해도 된다’는 뜻은 아닙니다. W3C 예시도 즉시 부작용이 있는 경우 POST를 쓰되, 제품은 수신 값의 신뢰·중복·권한을 별도로 판단해야 합니다. MVP에서는 공유받은 링크를 서버에 바로 확정하기보다, 제목·URL·태그를 보여 주고 사용자가 저장을 누르는 방식이 더 맞을 수 있습니다. 어느 방식이든 갱신 때 같은 POST가 다시 제출되지 않도록 응답과 전환 흐름을 확인하세요.
4. 설치 노출과 브라우저 지원을 완료 신호로 쓰지 않습니다
MDN은 Web Share Target을 Baseline이 아닌 제한적 가용성의 실험적 기능으로 표기하며, 설치된 PWA가 시스템 공유 대화상자의 대상이 될 수 있다고 설명합니다. 따라서 개발자 기기에서 앱 이름이 보였다는 관찰만으로 모든 기기·브라우저·운영체제에서 동일하게 노출된다고 말할 수 없습니다. 지원 범위는 출시 시점의 대상 브라우저와 실제 테스트 기기에서 따로 기록하세요.
PWA 설치 역시 별도의 조건입니다. MDN의 설치 안내는 지원 브라우저에서 manifest를 포함한 웹앱이 설치 대상으로 제안될 수 있음을 설명하지만, 설치 UI와 지원은 브라우저·플랫폼에 따라 달라진다고 명시합니다. 그러므로 “설치 가능”과 “공유 대상으로 등록됨”과 “공유 데이터가 저장됨”을 한 개의 체크박스로 닫지 마세요.
설치 가능한 웹앱의 기본 조건은 웹 MVP PWA 설치 준비도에서, 공유로 들어온 데이터를 다루는 책임은 이 글의 수신·검증 흐름에서 각각 검토할 수 있습니다.
5. 출시 판단은 다섯 개의 기록으로 닫습니다
범위 결정: 링크·텍스트·파일 중 MVP가 실제로 받는 데이터와 제외할 데이터를 적었다.
선언 확인: manifest의 action, method, params가 앱 scope와 제품 화면에 맞는다.
수신 확인: 지정한 기기·브라우저에서 공유 시트 선택 뒤 예상 경로와 값이 열렸다.
검증 확인: 빈 값, 잘못된 URL, 허용하지 않은 파일, 중복 요청의 처리 결과를 확인했다.
사용자 완료: 초안 표시, 사용자 확정 저장, 실패 안내를 서로 다른 결과로 남겼다.
이 구조는 공유 기능의 도입을 늦추기 위한 절차가 아닙니다. 시스템 공유 시트의 노출, HTTP 요청의 도착, 데이터베이스 저장, 사용자가 찾을 수 있는 결과가 서로 다른 지점임을 드러내기 위한 기록입니다. 특히 파일을 받는 기능은 용량·형식·보관 기간·권한을 제품 정책과 서버 검증으로 따로 정해야 합니다.
이 체크리스트는 특정 브라우저 지원, 설치 노출, 보안, 저장 성공 또는 전환 성과를 보장하지 않습니다. 대신 웹 MVP가 공유 데이터를 받는 범위와 확인 신호를 구분해, 출시 후 ‘공유됐는데 왜 저장되지 않았나’를 추적할 수 있게 하는 설계 기준입니다.
공식 문서
우리 웹 MVP의 공유 수신 범위와 검수 기록부터 점검하기
자주 묻는 질문
Web Share Target은 웹사이트의 공유 버튼인가요?
아닙니다. Web Share Target은 PWA가 시스템 공유 대화상자에서 공유 데이터를 받을 대상으로 선언하는 방식입니다. 웹에서 다른 앱으로 보내는 Web Share API와는 수신·발신의 역할이 다릅니다.
GET으로 받으면 저장 기능을 만들 수 없나요?
GET은 공유 값을 읽어 초안을 보여 주는 흐름에 쓸 수 있습니다. 저장 여부와 시점은 제품이 별도로 결정해야 하며, 즉시 부작용이나 파일 수신이 필요하면 POST와 검증 흐름을 검토해야 합니다.
파일을 받으려면 manifest에 무엇이 필요한가요?
MDN 안내에 따르면 POST, multipart/form-data, 그리고 이름과 허용 MIME 유형 또는 확장자를 지정한 files 설정이 필요합니다. 실제 파일의 검증·보관·권한 처리는 별도 구현과 정책으로 확인해야 합니다.
공유 시트에 PWA가 보이면 출시 검수가 끝난 건가요?
아닙니다. 브라우저와 플랫폼별 지원, 수신 경로, 입력 검증, 사용자 확인 뒤 저장 결과를 나누어 확인해야 합니다. 노출은 한 환경에서 확인한 관찰일 뿐 전체 지원이나 저장 성공을 뜻하지 않습니다.