웹 프로젝트는 PWA이어야 한다

PWA를 잘 설명하는 좋은 무료 콘텐츠도 많지만, 잘못된 정보 역시 만연해 있다. 아마 다음 항목 중 하나 이상은 들어봤을 것이다.

• PWA를 구축하려면 자바스크립트^JavaScript 프레임워크를 사용해야 한다.
• PWA를 구축하려면 싱글 페이지 앱^{single page app(SPA)}으로 시작해야 한다.
• PWA는 오직 사용자가 설치할 수 있는 ‘앱’으로서만 의미가 있다.
• PWA는 오직 모바일에서만 유효하다.
• PWA는 안드로이드^Android와 관련된 것이다.

 
모두 사실이 아니다. 오늘날의 많은 잘못된 정보가 그렇듯이, 각각은 거짓으로 왜곡된 진실의 파편을 포함하고 있다. PWA를 구축하고자 할 때 아마도 자바스크립트 프레임워크와 싱글 페이지 앱을 고려하겠지만, 반드시 그래야 하는 것은 아니다. 그런 사항들은 다른 웹 프로젝트와 마찬가지로 PWA에서도 선택사항일 뿐이다. 어쨌든 PWA도 웹사이트이기 때문이다(아니, 웹사이트이어야 한다). PWA는 단지 몇 가지 기능(예를 들어 ‘설치’ 기능)을 추가하여 전통적인 웹사이트를 좀더 강화한 것이다. 그러나 마찬가지로 모든 PWA에 설치 기능이 있어야 하는 것도 아니다. 비록 초창기 PWA는 모바일에 초점을 맞췄고 안드로이드에서만 동작했지만, 지금은 더 이상 작은 화면의 기기에 한정돼 있지 않다. 구글^Google에서만 가능한 게 아니다. 마이크로소프트^Microsoft, 모질라^Mozilla, 오페라^Opera, 삼성^Samsung도 모두 합류했다. 애플^Apple은 최근 서비스 워커^{Service Worker}(PWA의 기반 기술 중 하나)를 구현하겠다는 계획을 밝혔다. 물론 설치 기능도 지원할지는 두고 봐야겠지만 말이다. 그러나 상관없다. 어차피 PWA는 사파리^Safari에서 잘 작동하니까 말이다!

불행히도 이런 잘못된 정보는 많은 디자이너와 개발자(그리고 그 관리 팀)에게 PWA가 자신들의 프로젝트에 적합하지 않다는 확신을 심어줬다. 그러나 그 반대다! 모든 사이트는 PWA이어야 한다. 이 접근 방법은 모든 웹 프로젝트에 유익한데, 이 글에서 짧게 요약하여 설명할 예정이다. 그에 앞서 정확히 PWA가 무엇인지에 대해 설명함으로써 눈높이를 맞추고자 한다. 만약 PWA에 대해 상세하게 알고 있거나 이미 구축한 경험이 있다면 다음 절은 건너뛰어도 좋다. 만약 PWA에 전혀 익숙하지 않거나 제대로 이해하고 있지 않다면 걱정할 필요 없다. 다음 절이 PWA를 신속하게 이해할 수 있는, 잘 요약된 입문서 역할을 할 테니까 말이다.

도대체 PWA란 무엇인가?

앞서 언급했듯이, PWA는 특별한 능력을 가진 웹사이트다. “프로그레시브 웹 앱”에서 “앱”이라는 단어는 사용자가 PWA에 기대하는 콘텐츠나 경험의 유형을 한정하는 말이 아니다. “프로그레시브 웹 앱”이라는 용어 자체에 집착하지 말기 바란다. 마케팅 용어일 뿐이다. PWA는 운영체제(따라서 그 사용자)와 깊은 수준에서 연결하는 능력을 갖고 있다. 이는 설치, 그리고 알림이나 주소록 접근 등의 기능을 제공하는 API를 통해 가능하다. 반드시 설치가 돼야 모든 API를 사용할 수 있는 것은 아니지만, 일부는 그렇다. 이를테면 PWA를 웹사이트 더블 플러스^website++라고 생각하면 편할 것이다.

무엇이 PWA를 진정한 PWA로 만들어줄까? 사실 별게 없다. 다음 세 개의 요건이 전부다.

1. HTTPS를 운영해야 한다.

PWA는 운영체제의 여러 특별한 권한을 부여받기 때문에, 웹 서버와의 보안 연결은 필수다. 이와 관련하여 도움이 필요하다면 렛츠인크립트^{Let’s Encrypt}라는 무료 SSL 서비스를 확인해 보기 바란다.

2. 웹 앱 매니페스트^{Web App Manifest}가 있어야 한다.

이름만 보고 겁낼 필요는 없다. 단지 사이트와 관련된 정보를 담는 제이슨^JSON 파일일 뿐이다. 게다가 파비콘^favicon 생성기를 사용한다면 기본 뼈대를 갖춘 매니페스트 파일이 이미 있을 것이다. 브라우저나 검색 스파이더가 찾을 수 있도록 웹 페이지 head 부분에 link를 사용하여 참조시키면 된다.

3. 서비스 워커를 사용해야 한다.

아마도 이게 가장 복잡한 단계일 것이다. 하지만 서비스 워커 관련해서는 엄청난 수의 가이드가 있어, 원하는 작업 유형에 맞는 제작 방법을 참고할 수 있다. 그 중에서도 특히 모질라^Mozilla에서 제공한 가이드는 아주 훌륭하다.
이게 전부다. 일단 위와 같은 조건을 갖췄다면 그 웹사이트는 프로그레시브 웹 앱이다. 적어도 기술적으로는 그렇다. 그런데 왜 이런 자격 조건이 필요할까? 이에 대해서는 약간의 설명이 더 필요할 것 같다.
 
알렉스 러셀은 2015년에 PWA 개념을 처음 선보이며, 모든 PWA가 공통적으로 갖는 열 가지 특징을 설명했다. 그 중 대부분은 의심할 여지 없이 웹사이트를 구축하는 방법에 대한 것이었다. 하지만 일부는 보편적이지도 않고 어떤 종류의 프로젝트에도 적합하지 않은 사항이었다. 나는 이 점이 PWA 채택을 고려하는 많은 사람들에게 혼란을 준 원인 중 하나라고 의심한다. 또한 이 글을 쓰기로 결심한 이유이기도 하다.

PWA의 품질 경험과 보편적 이점

이후 몇 개의 절에서 웹 프로젝트의 몇 가지 원형을 설명한 뒤, PWA의 특성을 어떻게 적용해야 사용자에게 이득을 줄 수 있는지 논의할 것이다. 우리가 이런 일을 하는 이유는 결국 사용자를 위해서이기 때문이다. 먼저 어떤 웹 프로젝트에도 유용한 PWA의 일곱 가지 특징을 논의하고자 한다.

앞서 말했듯이 확실히 사용자에게 가치를 주기 때문에 시간을 들여 관심을 가질 만한 PWA의 특징들이 있다. 사실 이 특징들은 모두 웹 디자인과 개발에서 모범 사례^{best practice}로 꼽히는 것들이다.

첫째로, PWA는 안전해야 한다. 앞서 세 가지 기술 요건에서 언급했듯이, PWA는 반드시 HTTPS로 서비스돼야 한다, 끝! 다행히 HTTPS로 사이트를 운영하는 비용은 제로에 가까워졌다. 물론 기존의 대형 웹사이트에 HTTPS를 적용하려면 여러 작업이 필요하지만, 그럼에도 불구하고 그렇게 해야 하는 여러 이유가 있다. 주된 이유 중 하나는 ISP를 통한, 또는 호텔이나 공항에서의 감염된 라우터나 그 밖의 네트워크 접근을 통한 악의적인 중간자 공격^{man-in-the-middle attack}으로부터 사용자를 보호해야 하기 때문이다. HTTPS는 코드나 콘텐츠가 손상되지 않은 채로 사용자에게 전달되도록 보장한다. 비록 완벽하지 않을 수 있다. 하지만 HTTPS는 사용자와 데이터를 보호하기 위한 중요한 하나의 단계다. 또한 HTTPS는 지오로케이션^Geolocation[1]이나 서비스 워커 등 더 민감하고 최신의 API로 접근하기 위한 전제 조건이며, HTTP/2나 브로틀리^Brotli 압축 같은 성능 향상 기술을 사용하기 위한 필수 조건이다. 많은 브라우저가 HTTPS가 아닌 사이트를 “안전하지 않은^unsafe“이라고 표시하기 시작했으며, SSL 적용 여부가 검색 순위에도 영향을 주고 있다는 점을 주목하기 바란다.

앞서 말했지만 PWA는 결코 모바일만을 위한 접근 방법이 아니다. PWA는 모두를 위한 것이다. 각기 다른 운영체제, 브라우저, 시스템 API, 화면 크기를 갖는 더 다양한 기기로 더 많은 사람들이 웹사이트를 이용하게 하는 일은 성공으로 나아갈 가능성과 기회를 갖는 일이다. 여기가 바로 점진적 향상^{progressive enhancement}과 반응형 디자인^{responsive design}이 필요한 부분이다. 반응형 디자인은 기기의 크기나 창 크기에 관계없이, 주어진 화면에 맞는 최적의 레이아웃을 제공하도록 조정된다. 점진적 향상은 아주 다양한 실행 환경(기기, OS 등)과, 특히 다양한 사용자에게 웹사이트가 잘 맞춰지도록 해준다.

점진적 향상은 우리가 잘 모르거나 테스트하지 않은 기기와 브라우저로 사용자가 우리 사이트에 접근하다가 실패하는 상황을 방지하는 데 도움이 된다. 또한 기능과 관계없이 웹에 접속할 수 있는 기기라면 사이트가 잘 작동하도록 보장한다. 따라서 우리가 좀더 최신 브라우저와 기기의 사용자 경험을 최적화하는 데 집중하게 해준다. 장기적으로 보면 더 경제적이다.

알렉스가 식별한 또 다른 특성은 많은 PWA가 “유사 앱”이라는 점이다. “유사”라는 말에 주의하자. PWA는 앱이 아니며, 굳이 말하자면 사용자가 즐길 수 있는 유사 앱 경험^{app-like experience}을 제공한다. 더욱 일관되고 매끄러우며 편한 사용자 경험(즉 “유사 앱”이 암시하는 의미)을 제공할수록, 재방문하는 사용자의 수와 매출이 높아질 가능성이 커진다. 이는 반드시 자바스크립트를 사용해야 한다는 의미가 아니다. 단지 사용자가 사이트를 이용하는 흐름을 고려하고, 사용자가 목적을 이루는 과정에서 발생하는 걸림돌을 제거할 기회를 놓치지 않아야 한다는 의미다.

우리가 무언가를 만들 때, 사람들이 그것을 쉽게 찾기를 원할 것이다. PWA는 그 자체로 검색이 쉽다^{easy to discover}. 사이트의 콘텐츠는 사람들이 관련된 주제를 검색할 때 유기적으로 나타날 수 있는 방식으로 작성돼야 한다. 검색 결과가 스팸처럼 보이면 안 되며, 콘텐츠가 사려 깊고, 적절하며, 직관적인 방법으로 작성되도록 신경 써야 한다.

검색 용이성과 관련하여 PWA는 링커블^linkable하다. 사용자가 사이트를 돌아다니다가 어떤 지점에 도달했을 때, 우리는 사용자가 그 위치를 북마크하거나 또는 브라우저나 탭을 다시 열었을 때 그 페이지가 제대로 다시 열리도록 보장해야 한다. 이는 또한 사이트의 사용자 간 공유 범위를 어느 정도로 할 것인지도 관련이 있다. 기꺼이 시간을 들여 오픈 그래프^{Open Graph} 메타 태그와 일부 JSON-LD를 함께 사용하여 사이트의 콘텐츠를 좀더 널리 공유할 수도 있기 때문이다.

마지막으로 중요한 사항은 네트워크 독립성^{network independence}으로, 개발자를 아주 흥분하게 만드는 대박 주제다. 어느 정도의 오프라인 기능과 오프라인용 영구 저장소는 이미 있었다. 예컨대 마이크로소프트는 무려 1999년에 클라이언트 측 데이터 저장소를 선보였다. IndexedDB나 localStorage 등 클라이언트 측 데이터 저장소는 지난 수 년간 확실히 발전했지만, 여전히 진정한 자원 캐싱에 대한 제어 부분은 형편없었다. 그리고 드디어 서비스 워커와 캐시^Cache API가 등장했다. 이 두 기술은 페치^Fetch API와 일치단결하여 사이트 안에서 만들어진 자원 요청을 작성하거나, 가로채거나, 증진시키거나, 저장한다. 즉, 사용자는 네트워크 연결이 중단된 상태에서도 여전히 콘텐츠에 접근할 수 있게 된다.

서비스 워커를 구구절절이 다루는 훌륭한 자료들은 많이 있으므로, 여기서는 기술적인 내용은 생략하고 서비스 워커로 할 수 있는 몇 가지 멋진 일을 소개한다.

• 사용자에게 필요할 자원을 사전 인출^prefetch하여 캐싱한다. 이는 성능을 극적으로 향상시킨다.
• 새로운 페이지를 로딩할 때마다 서버로부터 가져올 필요가 없도록 사이트에서 필요로 하는 모든 페이지와 자산을 캐싱한다. 반복적인 방문이 수월해질 뿐만 아니라 내비게이션 성능도 향상된다.
• 커스텀 “오프라인” 페이지를 정의할 수 있다. 이를 통해 사용자에게 “네트워크에 연결되어 있지 않습니다”라는 브라우저 기본 메시지를 보이지 않게 만들 수 있다.
• 네트워크 연결을 먼저 확인하여 가능하다면 실시간 복사를 하거나, 연결이 되어 있지 않다면 이전에 캐싱된 자원을 사용하게끔 한다. 이 역시 사용자에게 “네트워크에 연결되어 있지 않습니다”라는 메시지가 나타나지 않도록 만든다.
• 브라우저가 지원한다면 JPEG 이미지 요청에 대해 웹피^WebP(점점 더 크기가 축소되는 추세다) 버전의 이미지로 응답할 수 있게 한다. 이 전략을 사용하면 마크업을 수정하지 않고도 성능을 향상시키는 대체 이미지를 제공할 수 있다.

 
서비스 워커는 훨씬 더 많은 능력을 갖고 있으며, 머지 않아 더욱 놀라운 유용한 기능들을 제공하기 위해 진행 중이다. 서비스 워커는 이미 많은 웹 프로젝트에서 가치가 증명됐다. 여러 유용한 예제는 모질라의 활용법 문서나 크롬의 예제를 참고하기 바란다.

프로젝트의 유형에 따른 PWA의 이점

PWA의 보편적 이점을 알아봤으니, 이제 기어를 바꿔보자. 모든 프로젝트는 제각기 다르겠지만, 대부분의 웹 프로젝트는 몇 가지 원형^archetype으로 분류된다. 그리고 각각의 원형은 PWA를 채택함으로써 실질적인 이득을 얻을 수 있다.

정보 사이트

정보 사이트^{informational site}라고 하면 업계의 많은 사람들은 “브로셔웨어^brochureware“를 떠올린다. 취미나 유머 사이트가 대표적인 예다. 또한 상호작용이라고는 이메일이나 전화번호 링크가 전부인 중소기업 사이트도 있다. 레스토랑 홈페이지 같은 포트폴리오 사이트도 이 범주에 포함된다.

대개 이런 사이트는 우리가 누구인지, 우리의 사업이나 프로젝트가 무엇인지 사람들에게 알리는 용도다. 대부분의 경우 사람들이 반복적으로 방문하기를 기대하지는 않는다. 특정 정보를 찾기 위해 방문한 사람들은 쉽고 빠르게(그러기를 바란다) 정보를 얻은 다음 떠난다. 그들은 다시 올 수도 있고 오지 않을 수도 있다. 따라서 사용자들의 재방문이 잦은 사이트에 비해 서비스 워커의 오프라인 캐싱 기능으로 얻을 수 있는 성능상의 이점이 훨씬 적다. 또한 사용자가 이 PWA를 실제로 설치할 가능성도 매우 낮다.

구축하려는 사이트의 종류에 따라 디바이스 API와의 연계를 고려할 수도 있다. 예를 들어 오프라인 소매업을 위한 PWA라면 지오로케이션 기능이 필요할 것이다. 할인이나 특가 정보를 방문자에게 알리고 싶다면 알림 기능(웹 알림이든 푸시 알림이든)을 추가해야 할 것이다.

PWA의 장점으로 흔히 내세우는 두 가지 ‘주요’ 기능, 즉 설치 기능과 오프라인 사용 기능이 정보 사이트에는 크게 해당되지는 않지만, 그럼에도 PWA를 채택하는 것은 여전히 유용하다. 그 두 가지 기능이 PWA의 전부가 아니기 때문이다. 사용자는 어떤 기기에서든 작동하며, 사용하기 쉽고, 검색 기능이 있으며, 친구와 쉽게 공유할 수 있는 사이트에 만족할 것이다.

정기 사이트

정기 사이트^{periodical site}는 블로그, 뉴스레터, 팟캐스트부터 만화, 잡지, 신문기사, 동영상 프로그램까지 포함한다. 이는 정보 사이트와 비슷하지만, 정기적 또는 비정기적으로 계속 갱신되는 특징이 있다. 이런 사이트에는 새 기사를 읽기 위해, 새 동영상을 보기 위해, 새 팟캐스트 에피소드를 듣기 위해 주기적으로 방문하는 사용자가 있다. 정기 사이트는 정보 사이트의 DNA를 공유하므로, 정보 사이트가 갖는 PWA의 이점을 그대로 포함한다. 그러나 정기 사이트만이 취할 수 있는 이점도 있다.

앞서 정보 사이트에서 프로모션이나 특가 행사가 있을 때 푸시 알림을 사용할 수 있다고 했는데, 정기 사이트에서는 푸시 알림이 필수다. 푸시 알림은 사용자의 기기에 설치된 어떤 서비스 워커 인스턴스에도 서버로부터 갱신 사항을 전송할 수 있는 메커니즘을 제공한다. 또한 사용자가 권한만 허용했다면 설치된 PWA나 브라우저가 실행되고 있지 않아도 알림을 띄울 수 있다.

혹시라도 이를 스팸 발송의 기회로 삼을 생각은 하지 말기 바란다. 고객의 관심과 사업 기회를 잃기 싫다면 말이다. 그 대신 고객에게 알림을 줄 적절한 시점을 선택해야 한다. 한 주에 한두 번 업데이트하는 사이트라면 개별 포스트를 통해 알리는 방법이 좋을 것이며, 이는 구독을 하지 않은 사용자에게도 적절한 방법이다. 만약 빈번히 업데이트하는 사이트라면 매일 또는 매주 정해진 시간에 한꺼번에 알리는 것이 좋다. 이는 심지어 A/B 테스트의 훌륭한 시나리오가 될 수 있다.

또한 오프라인에서 읽을 수 있게 기사를 저장하는 간편한 페이지 내^in-page 도구를 제공함으로써 한층 더 발전시킬 수 있다. 그렇다면 사용자가 본 것들을 모두 서비스 워커를 사용하여 캐싱하지 않는 이유는 뭘까? 정기 사이트의 특성상 개별 콘텐츠 아이템이 재사용될 가능성은 매우 낮기 때문이다. 사용자가 본 모든 콘텐츠, 특히 고해상도 이미지가 다수 포함돼 있는 콘텐츠 모두를 캐싱한다면, 결코 다시 볼 일도 없는 콘텐츠로 캐시 공간을 가득 채우는 셈이다. 훌륭한 웹 시민이 되려면 자원을 마지막으로 사용한 시간을 추적하여 정기적으로 정리하거나(솔직히 간단한 일은 아니지만), 아니면 CSS나 자바스크립트 파일과 같이 지속적으로 사용되는 필수 자원만 캐싱하는 것이 좋다. 그리고 사용자에게는 원하는 콘텐츠를 저장하는 기능의 버튼을 제공하면 된다.

계속해서 서비스 워커와 관련된 얘기로, 새로운 자원을 주기적으로 가져오고 싶다면 백그라운드 싱크^{Background Sync}를 사용해 볼 수 있다. 뉴스의 경우 매일 아침 사용자의 캐시에 첫 페이지와 주요 기사를 준비해 놓으면 좋을 것이다. 팟캐스트의 경우 주기적으로 최신 에피소드를 로딩할 수 있다. 다시 말하지만 오래된 기사나 에피소드 등을 주기적으로 정리하면 사용자에게 놀랍도록 빠른 경험을 제공할 수 있다. 브라우저가 그 날의 이슈를 보여주기 위한 모든 사항을 이미 갖춘 상태에서 사용자가 우리 사이트를 실행하는 상상을 해보라. 이건 마법이다!

마지막으로, 정기 사이트는 사이트를 처음 시작할 때 설치하는 것이 유리하다. 어떤 사람들은 홈 화면이나 시작 메뉴에 있는 아이콘을 눌러 뉴스를 실행하곤 한다. 모든 사람이 꼭 설치해야 하지는 않으며 모든 정기 사이트에 적합하지도 않지만, 설치는 여전히 훌륭한 선택 사항이다. 그리고 사용자들이 PWA를 자유롭게 설치할 수 있기 때문에, PWA 설치 시 사용자들에게 훌륭한 사용자 경험을 제공하기 위해서는 웹 앱 매니페스트가 신중하게 작성됐는지 확인해야 한다.

트랜잭션 사이트

사용자와의 정보 교환이 가능한 모든 사이트를 트랜잭션 사이트라고 할 수 있다. 가장 흔한 예로 온라인 쇼핑몰, 뱅킹, 주식 거래, 여행 예약, 공과금 납부 포털 등이 있다. PWA는 이미 이 분야에서 자신의 가치를 충분히 증명해 왔다. 다음은 몇 가지 성공 사례로, PWA Stats를 방문하면 바로 알 수 있다.

• 라파엘 호텔^{The Raphael Hotels}의 웹사이트는 PWA를 채택하면서 전환율^{conversion rate}이 20%, 페이지뷰는 66%, 세션은 59% 증가했으며, 이탈율^{bounce rate}은 51% 감소했다.
• 메이크아미트립^MakeMyTrip은 네이티브 앱일 때보다 전환율이 3배, 쇼핑 세션은 160%, 첫 쇼핑자의 전환율은 3배 이상 높아졌다고 보았다.
• 랑콤^Lancome은 전환율이 17% 증가했고, 전체 모바일 세션은 51%, iOS만의 세션은 53% 증가한 것으로 보았다.

마지막 부분에서 깜짝 놀라지 않았는가? 그렇다. iOS는 심지어 서비스 워커를 지원하지도 않는데 말이다!

잘 알려진 바대로 페이지 성능을 향상시키면 전환율이 높아지기 때문에, 서비스 워커의 스마트 캐싱과 오프라인 지원 전략을 통해 속도를 높이는 일은 매우 중요하다. 그러나 그 밖에도 트랜잭션 사이트가 PWA를 통해 얻을 수 있는 것들이 많다.

오프라인에 대해 얘기했는데, 오프라인 전략의 시작과 끝이 반드시 서비스 워커일 필요는 없다는 사실을 덧붙이고 싶다. 한동안 장바구니 아이템과 같은 트랜잭션 데이터를 잃지 않으려고 쿠키를 사용한 적이 있었다. 그러나 쿠키는 모든 네트워크 요청마다 전송되므로 저장할 수 있는 데이터의 양이 심각하게 제한된다. IndexedDB, localStorage, sessionStorage 등을 사용하면 트랜잭션과 관련된 더 많고 자세한 데이터를 클라이언트 측에 저장할 수 있다. 클라이언트 측에 정보를 저장하면 네트워크 오류 등의 장애가 발생해도 쉽게 복구할 수 있다. 만약 트랜잭션이 실패하더라도 POST 전송 문제로 잃어버렸을 데이터에 여전히 접근할 수 있으며, 트랜잭션을 주기적으로 다시 시도하거나 네트워크가 복구될 때까지 기다리는 방법을 택하면 된다. 어쨌든, 무슨 일이 일어나고 있는지, 그리고 그걸 해결하기 위해 어떻게 하고 있는지에 대해 실시간 메시지를 추가함으로써 데이터를 잃지 않는다는 점을 사용자에게 확신시킬 수 있다.

트랜잭션이 매우 많은 사이트의 경우, 사용자의 로컬 데이터와 서버 데이터의 동기화를 유지하는 방법으로 백그라운드 싱크를 고려해 볼 만하다. 예를 들어 뱅킹 시스템이라면 최근 거래와 현재 잔액 같은 정보를 동기화하면 사용자에게 매우 유용할 것이다. 마찬가지로 주식 거래 시스템이라면 현재 주가와 계좌 잔고 등을 동기화할 수 있다.

대부분의 트랜잭션 시나리오에서 알림은 매우 유용하다. 앞서 얘기한 시나리오로 예를 들자면, 트랜잭션이 완료됐을 때 누군가에게 알림을 보낼 수 있다(PWA에서는 사이트가 실행되고 있지 않더라도 백그라운드 싱크로 트랜잭션이 완료될 수 있다). 알림에는 두 가지 종류가 있다. 하나는 현재 페이지에서 자바스크립트를 통해 실행되는 웹 알림^{Web Notification}이며, 다른 하나는 사이트의 실행 여부와 관계 없이 서버가 전송하는 푸시 알림^{Push Notification}이다. 시나리오에 따라 적절한 방식을 사용하면 되지만, 푸시 알림에 대한 지원이 아직은 웹 알림보다 적다는 점에 주의하기 바란다.

사용자의 방문이 빈번한(매우 상대적인 표현이지만) 트랜잭션 사이트라면, PWA의 설치 기능이 매우 큰 기능을 한다. 사이트를 독립적인 앱 컨테이너로 분리하면, 사용자는 산만한 다른 탭이 없는 화면에서 원하는 일에만 집중할 수 있다. 또한 브라우저에 열려 있는 다른 사이트의 프로세스로부터 우리 코드를 보호할 수 있다. 게다가 실행되고 있는 브라우저의 부가 기능도 없으므로 오버헤드도 적다. 이 모든 이점이 함께 작용하여 능률적이고 마찰 없는 사용자 경험이 완성된다.

일단 설치되면 운영체제는 PWA가 시스템 내부 API에 접근할 수 있도록 허용한다. 아마도 사용자는 선물하고 싶은 사람을 자신의 연락처에서 선택하기 원할 것이다. 또는 방금 예약한 항공권 정보를 캘린더에 추가하고 싶어 할 수 있다. 또는 가상 비서와 연동하여 음성 지원을 받고 싶을 수도 있다. PWA에서는 이 모든 시나리오가 가능하며, 특히 트랜잭션 웹사이트에서는 엄청난 혜택이다.

소셜 서비스

트위터^Twitter나 페이스북^Facebook 같은 소셜 웹사이트는 PWA의 훌륭한 후보다. 사실 트위터는 이미 PWA의 길로 들어갔다. 소셜 사이트는 정기 사이트와 트랜잭션 사이트의 측면이 조합된 사이트로, 자연스럽게 그 두 원형이 갖는 PWA의 이점을 모두 포함한다. 이런 종류의 사이트에서는 특히 푸시 알림이 필수인데, 사용자의 재방문이 장기적인 성공을 좌우하기 때문이다. 그런 점에서 설치 기능 또한 중요하다.

성능, 특히 초기 실행 속도는 소셜 프로젝트에서 중요한 벤치마크 대상이다. 사용자는 이미지와 동영상을 포함한 콘텐츠가 로딩될 때까지 한가로이 앉아서 기다리지 않기 때문이다. 사이트의 자원을 캐싱하는 것이 약간이나마 도움이 될 수 있다. 그러나 상황에 따라 다르겠지만 아마도 백그라운드 싱크를 이용하여, 사용자가 다시 왔을 때 콘텐츠를 즉시 보여주는 것이 좋을 것이다.

트랜잭션 사이트와 마찬가지로, 소셜 사이트도 설치가 돼야 시스템 API에 접근하여 혜택을 누릴 수 있다. 예를 들어 대부분의 소셜 네트워크는 동일한 서비스를 이용하는 친구나 동료를 찾아주기 위해 연락처로의 접근 권한을 요청한다. 물론 우리의 서비스를 알린다는 명목 하에 사용자의 친구들에게 스팸을 보내는 용도로 권한을 악용하면 안 된다. 사용자와 그 개인 정보를 존중하지 않는다면 결국 모든 것을 잃게 될 것이다.

소프트웨어

우리가 “웹 앱”에 대해 얘기할 때, 대개 자연스럽게 온라인 소프트웨어를 마음 속으로 떠올리게 된다. 몇 가지 예를 들자면 이메일 클라이언트, 회계 도구, 프로젝트 관리 패키지, 버전 관리 시스템, 사진 편집기 등이 여기에 해당한다. 이와 같은 온라인 소프트웨어는 전통적으로 웹상에만 존재하는 것으로 여겨졌다. 지금까지는 말이다.

PWA의 마법은 이와 같은 서비스형 소프트웨어^{Software as a Service}(SaaS)를 그 자체로 완전한 데스크톱(또는 모바일) 애플리케이션으로 만들어 준다. 따라서 지금까지 웹 기술에만 올인했던 팀이라 할지라도 PWA를 통해 네이티브 플랫폼 설치 기능도 제공하게 됨으로써, 여전히 자기 고유의 영역에 대한 투자를 지속하거나 확대할 수 있게 됐다. 물론 네이티브 소프트웨어 제작을 해야 하는 몇 가지 확고한 이유는 분명 있다. 그러나 대부분의 경우 애플리케이션에서 필요한 모든 기능은 웹에서도 제공된다. 이것이 웹 방식으로 먼저 시작하는 이유다.

오프라인 데이터 저장소, 백그라운드 동기화, 파일 시스템 접근 능력도 역시 사용자 경험을 한층 더 증진시킬 것이다. 따라서 소셜 서비스는 프로그레시브 웹 앱의 가장 큰 수혜자라 할 수 있다.

기관 사이트

어떤 프로젝트는 여러 방면에 걸쳐 있는 것이 많아서 하나의 원형으로 분류하기 힘들다. 학교, 대기업, 거대 금융기관 등의 프로젝트가 그렇다. 이는 여러 원형의 혼합된 형태로, 각 원형에서의 이점이 모두 누적된다.

대형 기관의 프로젝트의 경우 PWA를 적용하기 위한 중요한 전략을 어떻게 구성할지 판단하기 어려울 수도 있다. 그러나 꼭 그럴 필요는 없다. 프로젝트를 여러 개의 독립적인 PWA로 나누는 방법도 있기 때문이다.

온라인 교육 시스템을 예로 들어 보자. 교육 시스템 자체를 하나의 PWA로 만들 수도 있지만, 개별 과정으로 쪼개어 각각 설치 가능한 PWA로 만들 수도 있다. 그렇게 할 수 있는 이유는 서비스 워커와 웹 앱 매니페스트의 적용 영역을 정할 수 있기 때문이다. 예컨대 특정 호스트 이름으로 범위를 정할 수도 있으며, 또는 URL의 특정 경로로만 한정할 수도 있다. 분명히 복잡해 보이긴 하지만, 각 과정을 하나의 교육 과정 템플릿이라고 하고 웹 앱 매니페스트와 서비스 워커를 그 템플릿의 일부라고 생각하면 감을 잡기 쉬울 것이다.

이제 여러분의 차례다

프로그레시브 웹 앱이 너무 기술적으로 보이거나 현실 프로젝트의 요구보다 너무 과잉된 것으로 보일 수도 있다. 그러나 실제로는 그렇지 않다. PWA는 높은 품질의 웹 경험을 만들기 위한 지름길일 뿐이다. 사용자의 삶에 절대적인 차별성을 주는 경험 말이다. 만약 이전에 PWA 구축을 전혀 고려해 본 적이 없었다면, 이 글을 통해 그 마음이 바뀌었기를 기대한다. 만약 서비스 워커에 이미 깊이 빠져 있다면, 진행 중인 프로젝트에 대한 새로운 접근 방법으로서 약간이나마 아이디어를 얻었기를 바란다.
[1] 유무선망에 연결된 휴대 전화, 컴퓨터 등 기기의 지리적 위치 정보. (출처: 한국정보통신기술협회 IT용어사전)