지난 글 만으로 코드랩을 진행하고자 하였으나 막상 준비를 하다보니 사람들이 PWA는 어떤 기술들로 구성되어있는 지 궁금해할까 하여 이 글을 작성한다. 우선 명확하게 말하자면 그 어떤 기술도 PWA를 위해 반드시 사용할 필요는 없다.
예를 들어, Service Worker나 Web App Manifest를 사용했다고 해서 ‘이 웹앱이 지금부터 PWA입니다 짜잔' 하는 게 아니라는 점에 대해서 잘 이해해두어야한다.
PWA에 대해 잘 이해하려면 Progressive 라는 표현에 대해서 잘 이해해야 한다. 2008년경에는 전세계의 개발자들이 모두 IE에 고통을 받던 시절이다. Google Chrome이 2008년 9월에 출시되었으나, 여전히 브라우저 점유율에서 가장 높은 비중을 차지하는 건 IE였으며 IE의 버전별 표준 지원 범위는 버전별로 상당히 차이가 있다.
그 당시에 나왔던 전략이 Progressive Enhancement다. 표현이 어려워서 그렇지 쉽게 이야기하자면 HTML은 어떤 환경에서든 접근 가능하도록 하되 (즉 콘텐츠는 어디서든 접근 가능해야한다) CSS나 JS는 지원범위에 따라서 더 나은 UI를 제공하자는 것이다.
이 전략의 중요한 점은 모두가 콘텐츠를 이용할 수 있어야한다는 점과 지원 범위에 따라서 더 나은 사용성을 제공해준다라는 점이다. 그렇다면 이 전략이 지금 시대에 와서 왜 중요해진걸까?
PWA
처음에 이야기한 것처럼 PWA는 딱 정해진 규칙이 아니다. 웹 앱을 구현하기 위한 기술들을 집합시켜둔 것이며 그 기술 중 일부 기술이 필수처럼 보이는 것 뿐이다. 공식적으로 “이 기술을 반드시 사용하세요” 라고 하는 것은 현재까지는 존재하지 않는다.
PWA는 굳이 따지자면, 웹을 더 좋게 만들기 위한 기술의 집약체다. 예를 들어, 지금까지 이미지를 불러오기 위해서 img 요소를 사용하였지만 디스플레이/디바이스 타입에 따라서 다른 요소를 불러오기 위해서 picture 요소를 사용할 수 있다.
그렇다면 picture 요소를 사용하는 것은 PWA에서 필수일까? 성능을 더 좋게하기 위해서picture요소를 사용할 수도 있다. 하지만 img요소를 사용한다고 해서 PWA가 아니라고 말할 수는 없다.
일부 특성들은 일부 기술에 의존적인 경우도 있다. 예를 들어 Offline 지원은 현재까지는 Service Worker를 사용하는 방법 외에는 구현 방법이 없다.
만약 어떤 브라우저가 Service Worker를 지원하지 않는다면 어떨까? PWA를 구현하기 위한 전략을 세울 때에는 지원하지 않는 브라우저에서 어떤 Fallback 전략을 사용할 지 미리 정해두는 것이 좋다.
개인적으로는 지원하지 않는 곳에서는 굳이 Service Worker를 이용하지 않아도 된다고 생각하고, Web App Manifest를 대체할만한 수단이 없다면 웹 앱으로써 사용할 필요도 없다고 생각한다. 혹은 웹 앱을 PWA가 아닌 다른 수단으로 만들어도 괜찮다고 생각한다.
모든 웹 앱은 PWA가 될 수 있다. 여러분이 jQuery를 사용하고 있던 React를 사용하고 있던 크게 상관 없이 어떤 기술에서던 PWA가 될 수 있다. (아주 심각한 레거시만 아니라면 말이다) 다만 전략의 문제라고 생각한다.
F.I.R.E
솔직히 나는 이 약어를 별로 안좋아한다. 뭔가 힙하고 싶어보이는 사람이 억지로 만든 용어같아서 (…) 그리고 FIRE라는 약어가 PWA를 잘 나타내고 있는 지도 잘 모르겠다.
F.I.R.E는 PWA의 핵심 전략을 담고있는 키워드들의 집합이다.
- Fast
- Integrated
- Reliable
- Engaging
처음에 이야기했듯 어떤 기술을 사용한다고 PWA가 되는 것이 아니라 웹 앱을 만드는 접근방식에 따라서 PWA다 아니다를 가늠할 수 있다. 위 4개 키워드를 구성하는 것 중 전통적으로 PWA에서 중요한 기술은 아래 두가지가 있다.
- Service Worker
- Web App Manifest
Service Worker
Service Worker는 백그라운드에서 동작하는 Worker다. 특정 도메인을 기준으로 설치되는 형태로, 설치 후 활성화되면 설정해둔대로 동작하게 된다. Service Worker를 이용하면 여러가지 일이 가능하지만 대표적으로 할 수 있는 일은 Offline 지원이다.
Offline 지원이 반드시 Offline 상태에서만 좋은 것은 아니다. 서버가 불안정한 상황이나 유저 네트워크가 불안정한 상황에서도 불필요한 서버 리퀘스트를 줄일 수 있기 때문에 사용자에게 더 나은 사용성을 제공할 수 있다.
Push Notification을 구현할 때도 Service Worker를 사용한다. Push는 클라이언트에서 처리할 일보다는 서버에서 할 일이 더 많다. Push 서버를 구축하고 Push 전략을 세우고 앱과 웹 간의 데이터 구조를 맞추고 기타등등.. 할 일이 없다고 말할 수는 없겠다.
Push Notification을 추가하는 방법에 대해서는 위 글에서 더 자세히 설명한다. 그러니 Service Worker 하나를 추가하는 것만으로도 Fast, Engaging을 증진할 수 있다. 하지만, 다시 한번 이야기하자면 이는 필수가 아니며 여러분들의 환경에 맞게 조절하면 된다.
Web App Manifest
Web App Manifest는 이 웹 앱의 모양이 어떤 것인 지 보여주기 위한 설정 파일이다. 현재는 Chrome과 Edge 등에서 지원하고 있으며, Apple은 독자적인 메타 태그를 통해 구현하고 있다.
MDN의 Web App Manifest 링크가 더 자세히 설명하고 있다고 생각한다. Web App Manifest를 추가하여 Add to Homescreen 배너를 노출시키는 것이 가능하며 이를 통해 유저들이 웹앱을 더 설치하기 쉽게 만들어준다.
Twitter는 이런 전략을 잘 사용한 대표적인 웹앱이다. mobile.twitter.com 은 PWA의 Best Practice라고 말할 수 있는데 Twitter 앱과 거의 동일한 사용성을 제공하면서도 PWA로 구현되어있기 때문에 마치 App처럼 사용할 수 있다. Starbucks 웹 앱도 대표적인 PWA라고 할 수 있다.
그 외에도
더 나은 결제 경험을 제공하기 위한 Payment Request API, 더 나은 로그인 경험을 제공하기 위한 Credential Management API, 더 나은 페이지 전환 경험을 제공하기 위한 Portal 등 다양한 기술들이 생기고 있으며 그런 기술들이 사용자 경험을 더 좋게 만들고 있다.
여러분들이 웹 앱을 구현하는 방식에 따라서 여러 기술을 조합하여 전략해볼 수 있을 거라고 생각한다. 하지만 PWA를 도입하는 것이 여러분들의 웹 앱에 악영향을 미치지 않을 것이라고 나는 확신하고 있다.
읽어볼만한 가이드
web.dev는 Google Chrome팀에서 새로이 제작한 사이트로 PWA가 아니더라도 웹을 개선하기 위한 다양한 가이드를 가지고 있다. web.dev의 가이드를 통해서 PWA에 대해서 더 깊이 이해할 수 있을 거라 생각한다.
