PWA(Progressive Web App)란? 웹사이트를 앱처럼 사용하는 방법
PWA의 개념과 웹 앱 매니페스트, 서비스 워커, 설치와 오프라인 지원이 각각 어떤 역할을 하는지 정리합니다.
웹 서비스를 이용하다 보면 브라우저에서 보던 페이지를 휴대폰 홈 화면이나 컴퓨터의 앱 목록에 추가할 수 있는 경우가 있다. 설치한 뒤에는 브라우저 주소창 없이 별도 창으로 열리기도 한다. 이런 경험을 웹 기술로 제공하는 앱을 PWA(Progressive Web App)라고 한다.
PWA는 특정 프레임워크나 하나의 API를 가리키는 말이 아니다. 웹 주소로 바로 접근할 수 있는 특성과 배포 방식을 유지하면서, 설치·오프라인 사용·기기 기능 연동처럼 앱에 가까운 경험을 점진적으로 더하는 개발 방식이다. 어떤 기능을 제공할 수 있는지는 브라우저와 운영체제에 따라 달라진다.
PWA를 이루는 요소
PWA는 일반 웹사이트와 같은 HTML, CSS, JavaScript를 바탕으로 만든다. 여기에 앱의 표시 방식과 아이콘 등을 알려 주는 웹 앱 매니페스트(Web App Manifest), 네트워크 요청과 캐시를 다루는 서비스 워커(Service Worker) 같은 웹 플랫폼 기능을 활용한다.
두 요소는 서로 다른 일을 한다. 매니페스트는 브라우저와 운영체제에 앱의 이름, 아이콘, 실행할 주소, 창의 표시 방식을 설명한다. 서비스 워커는 웹 페이지와 네트워크 사이에서 요청을 처리할 수 있는 별도의 스크립트다. 파일을 캐시에 저장하거나 네트워크 상태에 따라 응답을 선택하는 동작은 개발자가 서비스 워커에 구현해야 한다.
매니페스트와 서비스 워커는 PWA에서 자주 활용하는 기능이지만, 모든 환경에 공통으로 적용되는 단일 구성 요건은 아니다. 설치 조건과 지원 기능은 브라우저와 운영체제에 따라 다르며, 설치 가능 여부와 오프라인 지원도 별개의 기능이다.
웹 앱 매니페스트는 JSON 파일이며, 페이지에서 다음처럼 연결한다.
1
<link rel="manifest" href="/manifest.webmanifest">
간단한 매니페스트에는 다음과 같은 정보가 들어갈 수 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"name": "학습 노트",
"short_name": "노트",
"start_url": "/",
"display": "standalone",
"icons": [
{
"src": "/assets/icons/app-192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "/assets/icons/app-512.png",
"sizes": "512x512",
"type": "image/png"
}
]
}
name은 앱의 전체 이름이고, short_name은 공간이 제한된 곳에 표시할 짧은 이름이다. start_url은 앱 아이콘을 눌렀을 때 열 주소로 사용된다. display: "standalone"은 지원되는 환경에서 브라우저의 일반적인 주소창과 탭을 숨기고 앱처럼 표시하도록 요청한다. icons에는 홈 화면이나 앱 목록처럼 표시되는 위치에 따라 브라우저가 골라 쓸 수 있도록 여러 크기의 아이콘을 등록한다.
예시의 아이콘 경로와 start_url은 실제 파일과 배포 경로에 맞춰야 한다.
서비스 워커가 오프라인을 만들어 주는 것은 아니다
서비스 워커는 브라우저가 별도의 실행 환경에서 관리하는 스크립트다. 페이지가 보낸 네트워크 요청을 받아 네트워크로 전달하거나, Cache Storage에 저장한 응답을 돌려주도록 구성할 수 있다. 따라서 네트워크가 불안정할 때 이미 저장해 둔 화면이나 자료를 보여 주는 기능을 만들 수 있다.
하지만 서비스 워커를 등록하는 것만으로 사이트가 오프라인에서 동작하지는 않는다. 어떤 파일과 응답을 언제 캐시에 넣을지, 캐시된 응답과 새 응답 중 무엇을 사용할지, 연결이 끊겼을 때 어떤 화면을 보여 줄지를 설계해야 한다. 예를 들어 정적인 화면 파일은 캐시에서 빠르게 제공하고, 자주 바뀌는 사용자 정보는 네트워크에서 새로 요청하도록 다르게 처리할 수 있다.
또한 첫 방문 때는 필요한 리소스가 아직 캐시에 없을 수 있다. 서버와 통신해야 하는 기능도 연결이 끊긴 동안에는 동작하지 않을 수 있다. 오프라인 지원은 앱 전체가 자동으로 되는 기능이라기보다, 서비스에서 필요한 작업을 골라 명시적으로 구현하는 기능이다.
서비스 워커는 보안상 신뢰할 수 있는 컨텍스트에서 동작해야 한다. 일반적으로 배포된 사이트에는 HTTPS가 필요하며, 개발을 위한 localhost는 예외적으로 허용된다.
설치는 브라우저와 운영체제마다 다르다
PWA를 설치하면 기기의 홈 화면이나 앱 목록에 아이콘을 추가하고, 별도 창으로 실행하는 경험을 제공할 수 있다. 그렇다고 모든 환경에서 같은 설치 버튼이나 안내가 나타나는 것은 아니다. 브라우저마다 설치 조건과 메뉴가 다르고, 일부 환경에서는 사용자가 브라우저 메뉴에서 직접 홈 화면에 추가해야 한다.
특히 iOS와 iPadOS에서는 다른 플랫폼처럼 브라우저의 설치 안내가 자동으로 표시되지 않을 수 있다. 사용자가 브라우저의 공유 메뉴에서 ‘홈 화면에 추가’를 선택하는 방식으로 설치할 수 있으며, 세부 절차는 브라우저와 운영체제 버전에 따라 달라질 수 있다. 따라서 “PWA는 버튼 하나로 어디서나 설치된다”고 가정하지 말고, 주요 대상 기기에서 실제 설치 경로를 확인하는 편이 좋다.
네이티브 앱과 어떻게 다를까?
PWA와 네이티브 앱은 서로 완전히 대체하는 관계라기보다, 제품의 요구사항과 이용 환경에 따라 선택하는 방식이 다르다.
| 비교 항목 | PWA | 네이티브 앱 |
|---|---|---|
| 주된 기술 | 웹 표준 기술 | iOS·Android 등 플랫폼별 기술 |
| 배포와 접근 | 웹 주소로 접속하고 지원 환경에서 설치 가능 | 보통 앱 스토어 등을 통해 배포 |
| 업데이트 | 웹 리소스를 배포하고 브라우저가 갱신 | 스토어 배포와 설치된 앱의 갱신 절차를 따름 |
| 기기 기능 | 브라우저가 제공하는 API와 정책에 따름 | 플랫폼 API를 폭넓게 활용 가능 |
PWA도 브라우저가 제공하는 위치 정보, 카메라, 알림 등의 기능을 사용할 수 있지만, 지원되는 API와 권한 정책은 플랫폼마다 다르다. 반대로 네이티브 앱도 네트워크가 필요하도록 만들어졌다면 오프라인에서 사용할 수 없다. 두 방식의 차이는 “웹은 오프라인이 안 되고 앱은 된다”처럼 단순하게 나뉘지 않는다.
콘텐츠 열람, 예약, 간단한 업무 처리처럼 웹에서 제공하는 기능이 제품의 중심이라면 PWA가 적합한 선택일 수 있다. 반면 특정 기기 기능에 깊게 의존하거나, 플랫폼별 사용 경험을 세밀하게 조정해야 한다면 네이티브 앱이 나을 수 있다. 필요한 기능이 실제 대상 브라우저에서 지원되는지와 유지보수 비용을 함께 살펴봐야 한다.
언제 PWA를 고려하면 좋을까?
PWA를 검토할 때는 먼저 사용자가 어떤 상황에서 서비스를 이용하는지 살펴본다. 이동 중에도 이전에 본 자료를 확인해야 하는지, 앱을 설치하지 않은 사용자도 바로 서비스를 써야 하는지, 홈 화면에서 빠르게 다시 여는 경험이 필요한지 같은 질문이 출발점이 된다.
그다음 필요한 기능을 구체적으로 정한다. 단순히 설치 아이콘이 필요하다면 매니페스트와 플랫폼별 설치 동작을 살펴볼 수 있다. 오프라인에서 특정 화면을 제공하려면 어떤 데이터를 캐시할지와 최신 상태를 어떻게 다룰지 정해야 한다. 알림이나 백그라운드 동작이 필요하다면 지원 브라우저, 권한 요청 시점, 사용자가 거부했을 때의 대안도 함께 설계해야 한다.
PWA라는 이름을 붙이는 것만으로 사용성이 좋아지는 것은 아니다. 빠르게 열리고, 작은 화면에서도 쓰기 편하며, 연결이 끊기거나 요청이 실패했을 때 상황을 알려 주는 웹사이트가 바탕이 되어야 한다. 필요한 앱 같은 기능을 사용자와 서비스의 조건에 맞춰 더할 때 PWA의 장점을 살릴 수 있다.