프로그레시브 웹 앱: PWA가 네이티브를 이길 때

프로그레시브 웹 앱 개발은 영국의 발주자가 프로젝트 시작 첫 10분에 후보에서 빼고, 두 번째 네이티브 코드베이스가 조용히 예산을 다 먹어치운 뒤 18개월 만에 다시 발견하는 선택지입니다. 빠지는 이유는 이 주제로 쓰인 글이 거의 두 진영 중 하나에 속하기 때문입니다. iOS가 하지 않으려는 부분을 건너뛰는 옹호론이거나, 플랫폼이 정말로 그것을 못 하던 2019년에서 물려받은 회의론이거나 둘 중 하나입니다.

지금은 둘 다 틀렸고, 게다가 계산을 바꾸는 방식으로 틀렸습니다. Safari는 iOS 16.4부터 홈 화면에 추가한 웹 앱에서 푸시 알림을 지원합니다. Chrome은 설치 요건에서 서비스 워커를 뺐습니다. 영국 규제 당국은 2025년 10월에 모바일 브라우저와 브라우저 엔진을 두고 Apple과 Google이 전략적 시장 지위에 있다고 지정했습니다. 동시에 iOS는 여전히 백그라운드 실행을 거부하고, 여러분이 통제할 수 없는 규칙에 따라 저장 데이터를 지우며, 웹 앱을 App Store에 올려 주는 일은 결코 없습니다.

아래는 코드베이스 하나와 셋 사이에서 고민하는 고객에게 제가 건네는 판본입니다. 여기 담긴 기능 주장은 모두 2026년 9월에 벤더 자신의 문서로 확인했습니다. 이 분야는 통설이 어김없이 2년씩 뒤처지기 때문입니다.

PWA는 언제 네이티브 앱을 이길까요? 사용자가 iPhone만큼 Android와 데스크톱에도 있을 때, 앱이 기기가 아니라 서버의 프런트엔드일 때, 그리고 사람들이 스토어가 아니라 검색으로 여러분을 찾을 때입니다. 백그라운드 위치, 홈 화면 위젯, iPhone의 블루투스, 스토어 결제가 필요하다면 PWA는 집니다. 얻는 것은 셋이 아니라 하나의 코드베이스이고, 영국 기준으로는 대략 £40,000에서 £120,000의 구축비와 그 뒤로 눈에 띄게 작아지는 해마다의 청구서입니다.

프로그레시브 웹 앱이란 실제로 무엇인가

이 용어는 느슨하게 쓰여서 같은 회의에 앉은 두 사람이 서로 다른 것을 가리킬 수 있습니다. 기술적 정의는 좁고, 지킬 가치가 있습니다.

MDN은 프로그레시브 웹 앱을 웹 플랫폼 기술로 만들어져 플랫폼 전용 앱과 비슷한 경험을 사용자에게 주는 앱이라고 설명합니다. 하나의 코드베이스로 여러 플랫폼에서 실행되고, 설치할 수 있으며, 오프라인으로 동작하고, 운영체제와 통합됩니다.

실무에서 그것은 세 가지 산출물을 뜻하고, 그중 하나라도 없는 사이트는 PWA가 아니라 야심을 가진 웹사이트입니다.

웹 앱 매니페스트

매니페스트는 앱의 이름, 사용할 아이콘, 실행할 때 열 URL, 그리고 브라우저 틀 안에서 돌릴지 독립 창으로 돌릴지를 운영체제에 알려 주는 JSON 파일입니다. 이것이 없으면 브라우저는 설치할 대상이 없습니다. 작고, 정적이며, 이 작업 전체에서 가장 값싼 부분입니다.

서비스 워커

서비스 워커는 페이지와 별도로 실행되면서 앱과 네트워크 사이에 앉아 캐시에서 요청에 응답할 수 있는 스크립트입니다. 오프라인 동작을 가능하게 하고 푸시 메시지를 받는 것이 바로 이것입니다. 동시에 문제가 생기는 부분이기도 합니다. 범위를 잘못 잡은 캐시는 몇 주 동안 오래된 코드를 사용자에게 계속 내보내기 때문입니다.

HTTPS

서비스 워커, 푸시, 위치 정보, 카메라 접근은 모두 보안 컨텍스트로 제한됩니다. 요즘 호스팅에서는 이것이 무료이고 자동이므로, 비용이 아니라 제약입니다.

설치되었다는 말의 뜻은 플랫폼마다 다르다

발주자는 설치를 하나의 동작이라고 여깁니다. 실제로는 셋이고, 그 차이는 사업과 곧바로 연결됩니다.

Android

Android의 Chrome이 가장 대등한 결과를 줍니다. 앱은 홈 화면 아이콘을 얻고, 앱 전환기에 자기 항목을 가지며, 자기 저장 공간을 갖고, 래퍼를 통해 Play 스토어에 올릴 수 있습니다. 브라우저가 해당 이벤트를 발생시킨 뒤라면 여러분의 UI에서 설치를 유도할 수 있으므로, 언제 물어볼지는 여러분이 정합니다.

iOS와 iPadOS

Safari는 공유 시트와 그 안의 홈 화면에 추가 항목으로 설치합니다. 여러분이 띄울 수 있는 페이지 내 설치 프롬프트가 없고, Apple이 대신 보여 주는 배너도 없으며, 사용자가 그렇게 했는지 확실히 감지할 방법도 없습니다. 이 하나의 상호작용 공백이 플랫폼 간 가장 큰 실무적 차이이며, 이는 공학 문제가 아니라 설계 문제입니다. 사용자에게 동작을 가르쳐야 하기 때문입니다.

데스크톱

Chrome, Edge, macOS의 Safari는 모두 웹 앱을 자체 창과 함께 독이나 작업 표시줄에 설치합니다. 데스크톱은 PWA가 가장 논쟁이 적고 가장 활용되지 않는 영역이며, 특히 아무도 유지하고 싶어 하지 않는 Electron 빌드가 대안인 사내 도구에서 그렇습니다.

Chrome은 설치 가능 규칙을 바꿨지만 대부분의 안내서는 눈치채지 못했다

여러 해 동안 모든 글이 같은 체크리스트를 되풀이했습니다. 매니페스트, 아이콘, HTTPS, 그리고 fetch 핸들러를 가진 서비스 워커입니다. 마지막 항목은 메뉴에서 설치하는 경로에 대해서는 더 이상 사실이 아닙니다.

Google은 메뉴에서 설치할 때 fetch를 구현한 서비스 워커 요건을 없앴고, 모바일에서는 버전 108, 데스크톱에서는 112부터 그렇습니다. 이제는 자체 오프라인 페이지를 두지 않은 사이트에 기본 오프라인 페이지를 제공합니다. 설치 프롬프트 알고리즘은 여전히 fetch 핸들러를 원하지만, 설치 가능성 자체는 더 이상 거기에 달려 있지 않습니다.

파급 효과는 도구까지 닿았습니다. Lighthouse는 12.0.0 버전에서 PWA 카테고리를 통째로 없앴습니다. 2024년 4월에 나온 판본이며, 그 감사들은 이미 적용되지 않는 기준을 검사하려고 존재했기 때문입니다. 빌드 파이프라인이 아직도 PWA 점수가 없다고 실패한다면, 그것은 Google이 폐기한 것을 검사하고 있는 셈입니다.

실무적인 해석은 설치와 오프라인 기능이 분리되었다는 것입니다. 오프라인 이야기가 전혀 없는 설치 가능한 앱을 내놓을 수 있고, 그것이 첫 릴리스로 옳은 경우가 많으며, 사람들이 신호 없는 곳에서 실제로 쓰는 화면을 알게 된 뒤에 캐싱을 더하면 됩니다.

오프라인은 비용이 따르는 설계 결정이다

오프라인이라는 단어는 엄청나게 넓은 범위를 감춥니다. 마지막으로 받은 데이터를 보여 주는 캐시된 셸은 일주일치 작업입니다. 쓰기를 큐에 넣고 충돌을 해결하며 재연결 시 대사하는 진짜 오프라인 우선 앱은 다른 제품입니다.

캐싱 전략

서비스 워커 캐싱은 네 가지 패턴과 리소스 종류별 판단 하나로 정리됩니다. 캐시 우선은 저장된 사본을 내보내고 확인하지 않으므로 글꼴과 해시가 붙은 빌드 산출물에 맞습니다. 네트워크 우선은 서버를 먼저 시도하고 실패하면 물러서므로 항상 최신이어야 하는 데이터에 맞습니다. stale while revalidate는 캐시를 즉시 내보내고 뒤에서 갱신하므로 콘텐츠의 통상적인 선택입니다. 네트워크 전용은 결제처럼 오래된 사본으로 답해서는 안 되는 것에 씁니다.

여기를 틀리는 것이 제가 보는 가장 흔한 PWA 실패입니다. 애플리케이션 셸에 캐시 우선을 적용하면 무언가가 갱신을 강제할 때까지 지난달의 JavaScript를 재방문자에게 계속 내보내고, 들어오는 버그 리포트는 지금 코드에 존재하지 않는 증상을 설명하게 됩니다.

백그라운드 동기화

오프라인 동안 쓰기를 큐에 넣었다가 연결이 돌아오면 내보내는 것이 Background Synchronization API의 용도입니다. MDN은 이를 제한적 가용성으로 적고 Baseline이 아니라고 분명히 밝힙니다. 즉 가장 널리 쓰이는 브라우저 일부에서는 동작하지 않습니다.

그래서 iOS에서는 대체 경로를 직접 씁니다. 큐를 IndexedDB에 영속화하고, 앱이 다음에 열릴 때 내보내는 것입니다. 그렇게 하면 동작하고 사용자도 받아들이며, API였다면 한나절이면 끝났을 일이 대략 사흘에서 닷새의 공수가 됩니다.

푸시 알림이 다른 무엇보다 많은 프로젝트를 좌우한다

한 가지 기능이 PWA 제안을 가라앉힌다면 바로 이것이고, 근거는 대개 2022년에나 맞던 사실입니다.

Android와 데스크톱

Android Chrome, 데스크톱 Chrome, Edge, Firefox의 웹 푸시는 Push API와 Notifications API, 서비스 워커가 함께 움직이며 여러 해째 동작해 왔습니다. 전달은 브라우저 벤더의 푸시 서비스가 맡고, 권한은 표준 프롬프트이며, 서버가 구독한 사용자에게 메시지를 보내는 흔한 경우에는 네이티브 앱과 의미 있는 차이가 없습니다.

iOS와 iPadOS

Apple은 iOS와 iPadOS 16.4에서 Web Push를 추가했습니다. 놓치기 쉬운 부분은 거기 붙은 조건입니다. WebKit은 웹 앱이 홈 화면에 추가되어 있어야 한다고 밝히고, 권한은 구독 버튼을 누르는 것과 같은 직접적인 사용자 상호작용에 응답해 요청해야 합니다. Safari 탭에 머무는 사이트에서는 웹 푸시가 동작하지 않습니다.

매니페스트는 display를 standalone이나 fullscreen으로 설정해야 하며, 그러면 알림은 다른 앱과 똑같이 동작합니다. 잠금 화면, 알림 센터, 페어링된 Apple Watch, 그리고 설정에서 앱별 제어입니다. 배지도 됩니다.

Apple은 나중에 더 간단한 경로를 더했습니다. 선언형 웹 푸시가 Safari 18.4에 도착했고, iOS와 iPadOS 18.4에서 홈 화면에 추가한 웹 앱에 쓸 수 있으며, 서비스 워커가 실행 중이지 않아도 표준화된 JSON 페이로드에서 알림을 표시합니다. 작업은 줄어듭니다. 홈 화면 조건은 없어지지 않습니다.

iOS의 격차를 정확히 말하면

격차는 실재하고, 평판보다는 작습니다. 그것을 정확히 말하는 편이 불평하는 것보다도, 이미 닫혔다고 하는 것보다도 쓸모 있습니다.

저장 데이터 삭제

WebKit은 가장 오래 쓰지 않은 순서로 웹사이트 데이터를 지우며, 마지막 사용은 마지막 사용자 상호작용이나 저장 작업을 기준으로 잽니다. 저장 정책 문서는 출처별 할당량을 브라우저 앱에는 디스크의 최대 60%, 다른 앱에는 최대 15%로 정하고, 전체 할당량은 각각 80%와 20%로 두며, 독립 실행되는 홈 화면 웹 앱이 브라우저와 같은 할당량을 받는다고 확인합니다.

여기서 두 가지가 따라옵니다. 저장 공간은 사람들이 상상하는 제약이 아니라는 것, 그리고 삭제는 용량이 아니라 시점의 위험이라는 것입니다. 기기를 캐시로, 서버를 원본으로 다루면 삭제는 제품 결함이 아니게 됩니다.

백그라운드 실행

iOS에는 네이티브 백그라운드 작업에 해당하는 것이 없습니다. 주기적 페치도, 백그라운드 위치도, 앱이 닫힌 동안의 조용한 처리도 없습니다. 일정에 따라 일어나야 하는 일은 서버에서 일어나고, 사용자가 보는 푸시 메시지를 통해 기기에 닿습니다.

App Store에 존재하지 않음

PWA는 App Store에 올릴 수 없습니다. 고객 중 의미 있는 비율이 스토어에서 여러분의 브랜드를 검색해 찾기를 기대한다면, 그것은 웹에서 풀 수 있는 공학 문제가 아닙니다.

브라우저 엔진, DMA 그리고 CMA

여기는 보도가 일차 자료를 앞질러 가는 부분이므로, 실제로 문서화된 것만 좁게 말할 가치가 있습니다.

Apple은 이제 대체 브라우저 엔진을 허용하지만, 이것이 유럽 연합에만 적용된다고 명시합니다. iOS 17.4 이상과 iPadOS 18 이상에서, 공개된 보안, 개인정보, 테스트 스위트 기준을 충족한 개발자에게 주어지는 두 가지 엔타이틀먼트를 통해서입니다. Apple은 Web Platform Tests의 90%와 Test262의 80% 통과, JIT 없이 동작할 것, 그리고 대부분의 취약점을 30일 안에 해결할 것을 요구합니다.

영국 기업에게 그중 오늘 무언가를 바꾸는 것은 없습니다. 엔타이틀먼트는 관할권에 묶여 있고, 영국 통신사를 쓰는 영국 사용자는 어떤 브라우저 아이콘을 눌렀든 WebKit을 돌리고 있습니다.

영국 쪽 상황은 따로 움직이고 있습니다. 2025년 10월 22일에 CMA는 Apple과 Google이 모바일 플랫폼에서 전략적 시장 지위에 있다고 지정했고, 운영체제, 앱 배포, 브라우저, 브라우저 엔진을 5년 동안 대상으로 삼았습니다. 지정은 행위 요건을 부과할 권한이지 요건 그 자체가 아닙니다. 플랫폼은 오늘 행동하는 대로 두고 계획하고, 완화는 모두 덤으로 여기십시오.

하드웨어와 기기 API, 짐작이 아니라 확인으로

웹은 하드웨어에 접근할 수 없다는 말은 제가 가장 자주 듣는 반론이자, 구체적인 사례에서 가장 자주 틀리는 반론입니다.

사실상 어디서나 되는 것

getUserMedia를 통한 카메라와 마이크 접근은 MDN에서 Baseline이며 2017년부터 브라우저를 가로질러 동작해 왔습니다. 위치 정보, 기기 방향, 모바일에서 카메라 촬영을 포함한 파일 업로드, 클립보드 접근, 모바일의 Web Share API, 그리고 Face ID나 지문을 인증기로 쓰는 WebAuthn 패스키는 모두 현재 모바일 브라우저에서 동작합니다. 카메라 스트림을 이용한 바코드와 QR 코드 스캔도 일상적입니다.

대다수 업무용 앱에게는 그 목록이 하드웨어 요구사항의 전부입니다.

Chromium 전용이고 모바일에서는 사실상 Android 전용인 것

Web Bluetooth는 Google이 ChromeOS, Chrome for Android 6.0, Chrome 56 이후의 macOS, Chrome 70 이후의 Windows 10에서 쓸 수 있다고 문서화했고, iOS 지원은 적혀 있지 않으며, MDN도 Baseline이 아니라 제한적 가용성으로 표시합니다. Web NFC는 더 좁습니다. Google은 Android에서 Chrome 89부터 쓸 수 있다고 적고 있습니다.

사용자가 고른 파일을 읽고 쓰는 File System Access API도 마찬가지로 Chromium의 영역이지만, 출처 비공개 파일 시스템이 브라우저를 가로질러 앱 내부 저장 요구의 대부분을 덮습니다.

앱 스토어 배포는 기술이 아니라 상업의 문제다

팀들은 스토어 배포를 마치 역량 문제인 것처럼 논쟁합니다. 사실은 네 가지 상업 변수의 문제이고, 그중 스토어에 명백히 유리한 것은 하나뿐입니다.

발견은 정직한 장점입니다. 소비자는 실제로 App Store와 Play를 브랜드와 카테고리로 검색하고, 스토어에 없는 사업체는 그 채널을 포기합니다. 알아볼 만한 이름을 가진 소비자 제품에는 대단히 중요하고, 한 회사 직원 200명이 쓰는 도구에는 거의 무의미합니다.

신뢰는 실재하고 대상에 따라 비대칭입니다. 나이가 많고 기술에 익숙하지 않은 사용자는 스토어 등록을 안전 신호로 읽습니다. 젊은 사용자는 점점 그렇지 않고, 같은 사람이 같은 휴대폰에서 은행 웹사이트를 아무렇지 않게 씁니다.

그에 맞서 스토어는 여러분과 사용자 사이에 심사 대기열을, 바뀌는 규칙에 따른 거절 위험을, 그리고 앱 안에서 파는 것에 대한 수수료를 더합니다. PWA에는 그중 아무것도 없습니다. 출시 시점은 여러분이 정하고, 중요한 수정은 심사를 거치는 대신 다음 로드에서 모든 사용자에게 닿습니다.

스토어가 실제로 가져가는 몫

수수료 숫자는 기억에 의존하는 것이 현명하지 않을 만큼 자주 바뀝니다. 아래는 벤더가 직접 공개한 조건이며 2026년 9월에 확인했습니다.

Apple은 디지털 상품과 서비스에 표준 수수료로 30%를 가져갑니다. App Store Small Business Program은 직전 역년 수익이 1,000,000 USD 이하인 개발자에게 이를 15%로 낮춥니다. 신규 개발자도 대상이며, 한 해에 그 기준을 넘으면 이후 매출에는 표준 요율이 돌아옵니다.

Google은 단계별 Google Play 서비스 수수료를 공개합니다. 해마다 개발자 매출의 첫 100만 USD에는 15%, 그 위로는 30%, 자동 갱신 구독에는 매출과 무관하게 15%입니다. 같은 페이지는 2026년 6월 30일부터 EEA와 영국, 미국에서 발효되는 다른 구조도 제시하는데, 설치가 신규인지 기존인지에 따라 10% 또는 20%에 5%의 청구 수수료를 더하는 방식입니다.

두 벤더 모두 미국 달러로 공개합니다. 월 £9.99짜리 구독을 스토어를 거쳐 15%로 팔면 구독자 한 명당 연간 약 £18, 30%면 약 £36이 듭니다. 스토어가 공짜라고 판단하기 전에 구독자 수를 곱해 보십시오.

PWA는 Google Play로도 낼 수 있다

Android는 두 선택지를 동시에 줍니다. 이는 플랫폼 비교에서 진짜 비대칭이고 좀처럼 언급되지 않습니다.

Trusted Web Activity는 브라우저 크롬 없이 여러분의 PWA를 전체 화면으로 여는 Android 앱이며, Digital Asset Links로 여러분의 것임이 검증됩니다. Android에서 Chrome 72 이상이 필요하고, 호스트 앱은 웹 콘텐츠의 쿠키나 저장소에 접근하지 못합니다. 실제로는 매니페스트에서 생성한 얇은 래퍼를 다른 앱과 똑같이 Play에 제출하는 일입니다.

그래서 Android에서 선택은 스토어냐 웹이냐가 아닙니다. PWA를 공개하고, 그것을 감싸고, 같은 코드베이스에서 며칠의 패키징 작업과 연간 개발자 계정 비용으로 스토어 등록까지 얻습니다.

iOS에는 대응물이 없습니다. Apple의 심사 지침은 오래전부터 웹사이트를 감싼 것만으로는 충분하지 않다고 다뤄 왔으므로, iOS 스토어 경로는 진짜 네이티브를 만든다는 뜻입니다. 어떤 API 격차보다도 이 비대칭이 아래의 비용표를 만듭니다.

프로그레시브 웹 앱 개발 비용과 네이티브 코드베이스 두 개의 비교

사람들이 하는 비교는 구축 비용이고, 그것은 작은 쪽 절반입니다. 결과를 정하는 비교는 3년 총비용입니다. 네이티브의 지출은 반복되기 때문입니다.

이것은 중간 복잡도의 업무용 앱에 대한 영국 에이전시 가격대이지 견적이 아닙니다. 이런 형태의 PWA는 보통 엔지니어 두세 명으로 이뤄진 한 팀이 3개월에서 5개월 동안 만듭니다. 네이티브 코드베이스 두 개에 웹 존재를 더하면 팀 셋, 릴리스 절차 셋, 그리고 해마다 플랫폼 업그레이드 세 벌이 됩니다.

첫 줄과 셋째 줄의 차이, 구축에서 대략 £75,000에서 £175,000, 이후 연간 대략 £27,000에서 £60,000이 네이티브를 살 때 사는 것입니다. 그것이 잘 쓴 돈일 때도 있습니다. 다만 그것은 기본값이 아니라 결정이어야 합니다. 저희 웹사이트 개발과 소프트웨어 개발 페이지가 두 경로의 범위를 어떻게 잡는지 설명합니다.

유지보수 비용은 실제로 어디로 가는가

구축 비용은 협상됩니다. 유지보수 비용은 발견되는 것이고, 여러 코드베이스 프로젝트가 요란하게가 아니라 조용히 실패하는 곳입니다.

네이티브 플랫폼은 해마다 일을 떠맡깁니다. 새 OS 메이저 버전이 API를 폐기하고, 서명과 프로비저닝이 바뀌고, 최소 SDK 수준이 올라가고, 스토어 정책이 개인정보 매니페스트와 데이터 안전 신고 같은 요건을 더합니다. 그중 무엇도 기능을 출시하지 않습니다. 두 플랫폼에서는 남이 정한 일정에 맞춰 그것을 두 번 냅니다.

그다음은 어긋남입니다. 같은 기능을 구현한 코드베이스 둘은 갈라지고, 그 갈라짐은 한쪽 플랫폼에서만 재현되는 지원 티켓으로 드러납니다. 모든 제품 결정을 두 번 내리고 맞춰야 하며, 그 조율 비용은 어떤 청구서에도 보이지 않습니다.

PWA는 그 모두를 브라우저의 진화로 바꿉니다. 그것은 연속적이고 하위 호환되며 동작하는 코드를 거의 깨뜨리지 않습니다. 반복되는 일은 여러분 자신의 의존성 업데이트, 보안 패치, 호스팅이고, 이는 어떤 맞춤형 웹 애플리케이션에도 원래 필요한 유지보수와 같습니다.

중요한 비교는 제안서의 두 숫자가 아닙니다. 제품이 살아 있는 내내, 해마다 한 팀과 세 팀의 비교입니다.

PWA의 성능과 Core Web Vitals

설치된 앱은 네이티브와 견주어지므로 성능 기준은 웹사이트보다 낮지 않고 높습니다. 다행인 것은 지표가 공개되어 있고 임계값이 고정되어 있다는 점입니다.

Core Web Vitals는 현재 세 지표로 이뤄지고, 각각 페이지 로드의 75번째 백분위에서 평가되며 모바일과 데스크톱으로 나뉩니다. Largest Contentful Paint는 2.5초 이하가 좋고 4.0초를 넘으면 나쁩니다. 2024년에 안정화되며 First Input Delay를 대체한 Interaction to Next Paint는 200밀리초 이하가 좋고 500밀리초를 넘으면 나쁩니다. Cumulative Layout Shift는 0.1 이하가 좋고 0.25를 넘으면 나쁩니다.

여기서 PWA에는 구조적 장점이 하나 있습니다. 서비스 워커가 셸을 캐시에서 내보내면 재방문이 거의 즉시가 되고, 그것이 바로 설치된 앱이 만드는 패턴이므로, 설치된 PWA의 실사용 데이터는 같은 코드를 브라우저에서 처음 방문했을 때보다 대개 더 좋아 보입니다.

구조적 위험도 하나 있습니다. 단일 페이지 프레임워크는 일을 클라이언트로 밀고, INP가 바로 그것을 벌하는 지표입니다. 이미 이 숫자와 씨름하고 있다면, Core Web Vitals 통과에 관한 저희 안내가 이 글보다 깊게 진단을 다룹니다.

아무도 값을 매기지 않는 장점, SEO

이것은 상업적인 자리 대부분에서 제가 가장 먼저 꺼내는 논점이고, 그러면서도 거의 언제나 비교에서 통째로 빠집니다.

PWA는 웹사이트입니다. 모든 화면이 URL을 갖고, 모든 URL이 크롤링되고 색인되고 링크되고 공유될 수 있으며, 그 하나하나가 순위를 얻을 수 있습니다. 네이티브 앱에는 그중 아무것도 없습니다. 앱 스토어 등록은 얕게만 색인되고 담장 안 정원에서 전혀 다른 신호로 순위가 매겨지며, 앱 안의 콘텐츠는 검색에 보이지 않습니다.

결과는 복리로 쌓입니다. 네이티브 앱에 쓴 마케팅 비용은 설치를 사고, 지출을 멈춘 날 함께 멈춥니다. 같은 돈을 PWA의 콘텐츠와 기술 품질에 쓰면 계속 순위를 유지하는 페이지를 삽니다. 3년으로 보면 그 차이가 두 경로 어느 쪽의 구축 비용 전체를 넘는 일이 잦습니다.

이는 구현이 크롤링 가능할 때만 값을 하고, 클라이언트 렌더링 앱이 어긋나는 지점이 바로 여기입니다. 전부를 JavaScript로 그리고 URL은 하나이며 서버가 만든 HTML이 없으면 이 장점을 통째로 포기하는 것입니다. 색인되어야 할 경로를 서버 렌더링하거나 프리렌더링하는 것이 해법이며, 출시 전 기술 SEO 감사는 6개월 뒤에 아무것도 색인되지 않았다는 것을 알게 되는 편보다 훨씬 쌉니다.

실격시키는 요구사항

이 결정은 이점의 목록보다 거부 사유의 목록으로 보는 편이 쉽습니다. 거부 사유는 객관적이기 때문입니다.

다음 중 하나라도 바람이 아니라 진짜 요구사항이라면 네이티브가 필요합니다. 앱이 닫힌 동안의 백그라운드 위치 추적. 홈 화면 위젯, 워치 앱, 또는 CarPlay와 Android Auto 통합. iPhone에서의 블루투스나 NFC. HealthKit, 앱 내 Apple Pay, 또는 Apple이 웹에 열지 않은 깊은 OS 통합. 스토어 정책이 요구하는 경우의 디지털 상품 스토어 결제. 실시간 영상 처리나 네이티브 프레임률의 3D 렌더링 같은 지속적인 무거운 연산. 사업이 정말로 기대고 있는 마케팅 요건으로서의 App Store 존재.

그중 아무것도 해당하지 않는다면 PWA가 옳은 답일 가능성이 매우 높고, 입증 책임은 코드베이스 셋을 원하는 쪽에 있습니다.

두 가지 고려가 이를 더 밀어 줍니다. 사용자가 주로 데스크톱이나 Android에 있다면 iOS의 공백은 청중의 소수에게만 영향을 줍니다. 그리고 앱이 기기가 아니라 여러분 서버의 프런트엔드라면, 이는 업무용 소프트웨어 대부분에 해당하는데, 기기 기능은 거의 문제가 되지 않습니다.

시나리오 하나, 시설 관리 도급사의 현장 서비스

엔지니어 200명, 작업 지시서, 완료 작업 사진, 서명 수집, 기계실과 지하의 끊기는 신호. 이는 사람들이 네이티브가 필요하다고 여기는 사례이자 PWA가 가장 분명하게 이기는 사례입니다.

요구사항은 모두 덮입니다. 카메라는 getUserMedia로 됩니다. 서명은 canvas 요소입니다. 작업 데이터는 IndexedDB에 캐시되고 쓰기 큐는 재연결 시 내보내집니다. Background Sync가 브라우저를 가로질러 믿을 만하지 않으므로 그 부분은 직접 짭니다. 배차 알림은 웹 푸시로 나가고, Android에서 동작하며 iOS에서는 앱을 홈 화면에 추가한 엔지니어에게 동작합니다. 설치는 사용자 확보 문제가 아니라 입사 교육의 5분짜리 항목입니다.

사용자가 직원이므로 스토어 발견 요건이 없습니다. 결제가 없으니 수수료도 무관합니다. 기기는 Android와 iOS가 섞여 있고, 그것이야말로 네이티브 코드베이스 둘을 가장 세게 벌하는 경우입니다.

네이티브 앱 두 개를 £120,000에서 £200,000에 만드는 대신 PWA 하나를 £45,000에서 £70,000에 만들고, 수정을 심사가 아니라 그날 오후에 배포하며, 차액을 실제로 성패를 가르는 배차 백엔드에 쓰십시오.

시나리오 둘, 예약과 알림을 원하는 살롱 체인

지점 14곳, 소비자 대상, 예약, 알림, 적립 제도, 결제는 앱이 아니라 카운터에서. 경쟁사가 갖고 있으니 네이티브 앱을 만들자는 것이 본능입니다.

요구사항 목록은 평범합니다. 예약 양식, 캘린더, 알림, 계정 영역. 흥미로운 것은 알림뿐인데, 이 시장에서는 푸시보다 문자와 이메일이 낫습니다. 1년에 두 번 예약하는 손님은 아무것도 설치하지 않았을 것이기 때문입니다.

결정 요인은 발견이고, 그것은 결정적으로 웹에 유리합니다. 사람들은 살롱을 검색과 지도로 찾지 앱 스토어를 둘러보며 찾지 않으므로, 서비스를 설명하고 예약을 받는 페이지가 순위를 얻어야 합니다. 네이티브 앱은 거기에 전혀 보이지 않습니다. 웹사이트 자체의 비용이 진짜 예산 항목이고, 앱 계층은 설치 가능성으로 그 위에 얹힙니다.

예약 사이트를 제대로 만들고, 단골이 홈 화면에 둘 수 있도록 설치 가능하게 하고, 동의하는 소수를 위해 웹 푸시를 더하십시오. 여기서 네이티브 구축은 웹사이트가 이미 닿는 것보다 적은 고객에게 닿으려고 £80,000 넘게 씁니다.

시나리오 셋, 구독형 피트니스 제품

가이드 운동, 영상 콘텐츠, 웨어러블 연동, 월 £12.99, 소비자 직접 판매, 유료 확보로 성장. 이 사례는 반대로 기울고, 그 이유를 보일 가치가 있습니다.

여기서는 스토어 발견이 중요합니다. 피트니스는 둘러보는 카테고리이고 등록이 진짜 확보 채널이기 때문입니다. 웨어러블 연동은 HealthKit을 뜻하고 웹은 닿지 못합니다. 운동 중 백그라운드 오디오와 화면 켜짐 동작은 네이티브가 낫습니다. 대규모 오프라인 영상 다운로드는 웹에서 가능하지만 편하지는 않습니다.

흥미로운 부분은 결제입니다. 월 £12.99에 대한 스토어 수수료는 15%면 구독자 한 명당 연간 약 £23, 30%면 약 £47이고, 구독자 20,000명이면 연간 £460,000에서 £940,000입니다. 그것은 결제를 웹에서 받고 앱은 클라이언트로 다루자는 강한 논거이며, 여러 대형 구독 제품이 실제로 그렇게 하고 있습니다.

답은 제품에는 네이티브 앱을, 가입과 결제와 콘텐츠 마케팅에는 PWA나 일반 웹 앱을 쓰는 것입니다. 둘 다 존재하고, 그 분리는 우연이 아니라 의도입니다.

오후 한나절에 결정하는 방법

이 결정에는 디스커버리 단계가 필요 없습니다. 필요한 것은 적어 둔 네 개의 답입니다.

첫째, 정말로 필요한 기기 기능을 적고, 요약이 아니라 벤더 자신의 문서로 하나씩 확인하십시오. 대부분의 목록은 이 단계에서 극적으로 짧아집니다. 둘째, 사용자가 어디에서 오는지 확인하십시오. 답이 검색이면 웹이 이미 유리하고, 스토어 둘러보기면 유리하지 않습니다.

셋째, 세 경로 모두를 1년이 아니라 3년으로 값을 매기고, 위의 유지보수 숫자를 넣고, 팔 계획인 것에 붙는 스토어 수수료도 넣으십시오. 넷째, 여러분의 팀에 대해 정직하십시오. 엔지니어 셋이 유지하는 코드베이스 하나는 엔지니어 셋이 유지하는 코드베이스 셋보다 매번 더 많이 내놓습니다.

그러고도 답이 모호하다면 PWA를 먼저 만드십시오. 되돌리기에 더 싼 쪽입니다. 나중에 PWA에서 네이티브로 가는 것은 이미 존재하고 검증된 API를 상대로 네이티브 클라이언트를 쓰는 일이고, 반대 방향은 처음부터 다시 하는 일입니다. 그 비대칭은 위의 기능 비교 대부분보다 값어치가 큽니다.

여기서 어디로 가는가

프로그레시브 웹 앱 개발은 네이티브를 감당하지 못하는 사람을 위한 타협도 아니고 만능 답도 아닙니다. 정의 가능하고 큰 제품 범주에 옳은 아키텍처입니다. 업무용 소프트웨어, 사내 도구, 예약과 계정 시스템, 콘텐츠 제품, 그리고 고객이 검색으로 도착하는 모든 것입니다.

iOS의 공백은 실재하고 구체적이며 대개 치명적이라기보다 우회 가능합니다. 사용자가 설치하면 푸시는 됩니다. 저장 공간은 넉넉하지만 지워질 수 있습니다. 백그라운드 실행은 없고 원래 여러분의 서버에 속합니다. 블루투스와 NFC는 iPhone에서 되지 않고, 아무리 공학을 쏟아도 그것은 바뀌지 않습니다.

Mecanik은 두 경로를 모두 만들고, 답이 네이티브일 때는 그렇다고 말씀드립니다. 일반적인 목록이 아니라 여러분의 실제 요구사항을 놓고 이 비교를 돌려 보고 싶다면, 웹사이트 개발과 소프트웨어 개발 페이지에 범위를 잡는 방식을 적어 두었고, 2026년에 웹 앱 만들기에 관한 저희 안내가 그 뒤에 따라오는 스택 결정을 다룹니다.

자주 묻는 질문

프로그레시브 웹 앱이란 무엇인가요? 프로그레시브 웹 앱은 웹 기술로 만들어져 플랫폼 전용 앱처럼 동작하는 앱입니다. 기술적으로는 HTTPS로 제공되는 웹 애플리케이션으로, 이름과 아이콘과 실행 동작을 기술한 웹 앱 매니페스트, 그리고 캐시에서 요청에 응답하고 푸시 메시지를 받을 수 있는 서비스 워커를 갖춥니다. MDN은 이를 하나의 코드베이스로 여러 플랫폼에서 실행되면서 설치 가능하고 오프라인으로도 동작하는 소프트웨어라고 정의합니다.

PWA가 iPhone에서 푸시 알림을 보낼 수 있나요? 조건 하나가 붙지만 보낼 수 있습니다. Apple은 iOS와 iPadOS 16.4에서 Web Push를 추가했지만, WebKit은 웹 앱이 먼저 홈 화면에 추가되어 있어야 하고 권한은 구독 버튼을 누르는 것 같은 직접적인 사용자 상호작용에 응답해 요청해야 한다고 요구합니다. Safari 탭에서 실행되는 사이트에서는 푸시가 동작하지 않습니다. iOS와 iPadOS 18.4에 추가된 선언형 웹 푸시는 구현을 단순하게 하지만 같은 홈 화면 조건은 그대로 둡니다.

영국에서 프로그레시브 웹 앱 개발 비용은 얼마인가요? 중간 복잡도의 업무용 앱이라면 단일 PWA 코드베이스 구축에 £35,000에서 £75,000, 연간 유지보수에 £8,000에서 £20,000을 예상하십시오. 비교 대상인 네이티브 경로, 즉 iOS와 Android 앱을 따로 만들고 마케팅 사이트를 더하는 방식은 구축이 £110,000에서 £250,000, 이후 연간 £35,000에서 £80,000입니다. 이는 견적이 아니라 영국 에이전시 가격대이며, 대개 구축 차이보다 반복되는 차이가 더 중요합니다.

PWA를 App Store나 Google Play에 올릴 수 있나요? Google Play는 가능하고 App Store는 불가능합니다. Android에서는 Trusted Web Activity가 PWA를 얇은 네이티브 껍데기로 감싸고 Digital Asset Links로 검증하므로, 같은 코드베이스가 며칠의 패키징 작업만으로 Play 등록을 얻습니다. Apple에는 대응물이 없고 심사 지침이 웹사이트를 감싼 것만으로는 충분하지 않다고 보므로, App Store 존재는 진짜 네이티브를 만든다는 뜻입니다.

언제 PWA 대신 네이티브 앱을 선택해야 하나요? 앱이 닫힌 동안의 백그라운드 위치, 홈 화면 위젯, 워치나 차량 통합, iPhone에서의 블루투스나 NFC, HealthKit이나 앱 내 Apple Pay, 실시간 영상 처리 같은 지속적인 무거운 연산, 또는 진짜 확보 채널로서의 App Store 존재가 필요할 때 네이티브를 고르십시오. 그중 아무것도 해당하지 않는다면 PWA가 옳을 가능성이 매우 높고, 입증 책임은 코드베이스 셋을 유지하려는 쪽에 있습니다.