최근에 프로젝트를 진행하며 처음으로 PWA를 적용해보았다.

관련해서 간단하게 공부하면서

웹앱, PWA, 웹뷰, 하이브리드 앱, 크로스플랫폼 앱 같은 용어들을 자주 접했었다.

또한, 처음에는

웹을 기반으로 앱처럼 사용할 수 있는 모든 것 = 웹앱
이라고 막연하게 이해하고 있었다.

하지만 정리해보니,

웹앱은 서비스의 ‘형태’이고

PWA나 하이브리드 앱은 그 웹앱을 ‘어떻게 배포하고 실행할 것인가’에 대한 전략에 가깝다는 걸 알게 되었다.

그 개념을 간단하게 좀 정리해보려고 한다.

1. 웹앱이란 무엇인가

웹 앱(Web Application)은 웹 브라우저에서 실행되는 소프트웨어를 의미한다.

별도의 설치 과정 없이, 인터넷 연결과 브라우저만 있다면 언제든 실행할 수 있다.

웹앱은 우리가 일반적으로 사용하는 웹 기술과 동일하게 개발된다.

HTML
CSS
JavaScript

즉, 웹에서 동작하는 프로그램이다.

우리가 만드는 대부분의 웹 서비스는 이미 웹앱의 성격을 띠고 있다.

2. 웹사이트 vs 웹앱

웹사이트와 웹앱은 종종 구분되지만, 요즘에는 사실 구분하기가 애매하다.

웹사이트

정보 제공 중심
정적인 콘텐츠 위주
예: 회사 소개 페이지, 위키피디아

웹앱

사용자와의 상호작용 중심
상태 변화, 입력, 기능 제공
예: 이메일, 캘린더, 유튜브, SNS

여기서, 뉴스 사이트에 댓글·좋아요·실시간 갱신 기능이 있다면 이미 웹앱의 성격을 띤다고 볼 수 있다.

그래서 요즘은 “URL로 접근해 브라우저에서 사용하는 서비스” 정도로 묶어서 이해해도 될 거 같다!

여기서 내가 가장 헷갈렸던 것은 아래처럼 생각했기 때문이었다.

웹앱 = 앱처럼 설치해서 쓰는 것

사실은 이렇게 생각하면 된다!

웹앱은 서비스의 형태
PWA, 웹뷰, 하이브리드 등은 그 웹앱을 어떻게 배포하고 실행할 것인가에 대한 전략

그럼 이제 이러한 관점에서 웹앱을 어떻게 배포하고 실행하는지를 보면 된다!

3. 웹앱을 배포/실행하는 방법들

1) 웹앱 (브라우저 기반)

브라우저에서 직접 실행되는 웹사이트
앱스토어 등록할 수 없으며, 사용자는 앱 다운로드 없이 URL 로 접근 가능
기본적으로는 푸시 알림, 카메라 등 네이티브 기능을 사용할 수 없음
(PWA나 일부 최신 브라우저 기능을 활용하면 제한적으로 가능)

2) 웹뷰 앱 (WebView 기반 앱)

웹앱을 네이티브 앱의 WebView로 감싼 형태
앱스토어에 등록 가능하며, 사용자는 앱을 설치해 사용
UI는 웹에서 렌더링되며, 필요에 따라 네이티브 기능 일부를 연동할 수 있음

3) 하이브리드앱

웹뷰를 기반으로 하지만, 주요 네이티브 기능을 연동할 거라는 전제로 설계된 앱
웹 개발자의 네이티브 SDK 연동 또는 JS와 네이티브 간의 브릿지 설정이 필요함
→ 이것들을 통해 카메라, 알림, 파일 접근 등의 기능을 연동
웹의 생산성과 앱의 기능성을 모두 갖춘 구조
예시 ) Capacitor, Ionic (UI 프레임워크)

4) 크로스플랫폼 앱

하나의 코드베이스이지만, 프레임워크를 사용해 IOS, Android 앱을 동시에 개발
앱 개발 역량이 필요하고, 프레임워크의 일부 기능 구현에 제약이 있음
대표 프레임워크 예시 ) React Native, Flutter 등
웹 뷰 기반이 아닌, UI 가 네이티브 컴포넌트 자체로 렌더링됨

5) 네이티브 앱

iOS, Android 각 플랫폼의 전용 언어로 직접 개발하는 방식
플랫폼에 최적화된 성능을 내어, 모든 요소를 세밀하게 구현 가능
다만, 플랫폼별로 각각 개발해야 하므로 리소스와 비용이 가장 많이 소요됨

+ PWA는?

위 종류를 살펴보며 프로젝트에 적용한 PWA는 어디에 속하지?라는 의문이 들었다.

결론적으로는, PWA는 웹앱과 웹뷰 사이의 위치정도 같다!

웹앱을 기반으로 하되, 브라우저의 최신 기능을 활용해 네이티브 앱과 유사한 사용자 경험을 제공하도록 개선된 형태
앱 스토어가 아닌, 브라우저 주소창이나 메뉴에서 설치 가능
서비스 워커라는 개념으로 오프라인에도 작동 가능
모바일/데스크톱에 시스템 푸시 알림을 보낼 수 있음

이 중 기업 채용 공고에서 많이 보이던 웹뷰를 조금 더 알아보려고 한다!

4. WebView

웹뷰는 위에서 봤듯이 네이티브 앱 안에 포함된 웹을 보여주는 뷰이다.

즉, 네이티브 앱 내부에서 HTML / CSS / JavaScript로 만든 웹 페이지를 렌더링하는 컴포넌트

일반 브라우저랑 다르게

주소창 없음
새로고침 버튼 없음
탭, 즐겨찾기 없음
오직 “웹 콘텐츠 표시”에만 집중

WebView는 브라우저가 아니라 앱 UI의 일부로 들어가는 웹 렌더러다.

브라우저 vs WebView

구분	브라우저	WebView
실행 위치	독립 실행 앱	네이티브 앱 내부
UI	주소창, 탭, 메뉴 제공	없음 (앱 UI에 종속)
제어 주체	사용자	개발자
배포	URL 접속	앱 설치 필요
네이티브 연동	거의 불가	가능 (브릿지 통해)

핵심적인 차이는

브라우저는 사용자를 위한 도구
WebView는 개발자를 위한 도구

WebView의 장단점

장점

1) 한 번 개발로 여러 플랫폼 대응

2) 앱 업데이트 없이 즉시 반영

네이티브 앱: 수정 → 빌드 → 심사 → 배포
WebView: 서버에 배포만 하면 끝
→ 자주 바뀌는 화면 (약관, 이벤트, 공지, 마이페이지 등)에 매우 적합

3) 네트워크 기반 데이터 표현에 유리

이메일, 결제 내역, 피드, 게시글 등 항상 서버 데이터가 필요한 화면
→ 네이티브에서 UI + API + 상태관리 하는 것보다 웹으로 보여주는 게 단순

단점

1) 성능 한계

초기 로딩 시 리소스 다운로드 필요
- 네이티브 → 즉시 화면 보여줌
- WebView : 리소스 다운 + 렌더링
네이티브 화면 전환보다 체감상 느릴 수 있음

2) UI / UX 제약

네이티브의 세밀한 제스처, 애니메이션 구현 어려움
플랫폼별 UI 가이드라인 완전 대응 어려움

3) 보안

주소창이 없기에 접속한 URL 을 확인 할 수 없음
따라서 앱 화면 중 하나로 인식하여 가짜 페이지가 들어와도 눈치 채기 어려울 수 있음
JS ↔ Native 브릿지
JS에서 Native 함수를 호출할 수 있기 때문에, 보안상 문제가 생겼을 때 Native 의 권한까지 탈취될 수도 있음
→ 웹뷰자체의 문제보다는 브라우저가 기본으로 제공하던 보안 UX와 정책을 개발자가 직접 책임져야 하기 때문에 보안 사고가 발생하기 쉽다고 생각하면 될 것 같다.

WebView가 브라우저와 다르게 동작하는 이유

웹뷰(WebView)를 다루다 보면 이런 경험을 하게 된다.

브라우저에서는 잘 되는데 앱에서만 안 된다 …
Android에서는 되는데 iOS에서는 안 된다 ….
같은 웹 코드인데 동작이 뭔가 모르게 다르다 …

이 문제의 대부분은 웹뷰가 어떤 웹 엔진 위에서 동작하는지를 알면 설명할 수 있다.

웹뷰는 작은 브라우저가 아니다

WebView는 브라우저가 아니라, 웹 엔진을 UI 안에 포함시킨 컴포넌트다.

그렇다면 왜 브라우저가 아니라 컴포넌트인가?

Chrome, Safari 같은 브라우저는

웹 엔진
주소창
탭
개발자 도구
확장 기능

이 모든 것을 포함한 완성된 앱이다.

반면 WebView는

주소창, 탭, 개발자 도구 X
웹 페이지만 렌더링 O

즉, 웹 엔진만 가져다 앱 화면 안에 심어둔 형태다.

따라서, 개발자가 코드를 짤 때 웹뷰는 Button, TextView, Image와 같은 레벨의 UI 요소일 뿐이다.

레이아웃의 일부
- 일반 브라우저는 화면 전체를 차지하지만, 웹뷰는 레이아웃의 일부로 존재할 수 있다.
- 화면 상단은 네이티브 버튼 + 하단 30%만 웹뷰 등
- 실제 배민에서도 이 사각형 내부만 웹뷰라고 한다.
  모두의 웹뷰
생명주기의 종속성
- 브라우저는 사용자가 끄기 전까지 살아있다.
- 웹뷰는 자신을 포함한

따라서, 웹뷰는 브라우저에서 '머리(주소창, 탭, 뒤로 가기 버튼)'를 떼어내고 '몸통(엔진)'만 가져온 상태라고 생각하면 된다.

엔진은 같다
안드로이드는 Chromium, iOS는 WebKit 엔진을 사용한다. 그래서 최신 JS 문법은 잘 알아들음!
손발은 개발자가 달아줘야 한다
브라우저에 당연히 있는 '뒤로 가기'나 '새로고침' 기능을 웹뷰에서 쓰려면, 개발자가 직접 코드로 구현해야 한다.
예) 사용자가 폰의 뒤로 가기를 누르면 웹뷰를 이전 페이지로 돌려라..

알아두면 좋은 간단한 웹엔진 구조

iOS와 Android WebView는 아예 다른 엔진이다!

iOS WebView : WebKit

애플에서 개발한 웹 엔진
Safary 브라우저와 아이폰에서 동작하는 웹 뷰가 WebKit에 의해 동작
- JavaScript 엔진: JavaScriptCore
- Safari 브라우저와 동일한 엔진
- iOS에서는 WebKit만 사용 가능

Android WebView : Chromium

구글에서 개발한 웹 웬진
Chrome 브라우저와 안드로이드 모바일 웹뷰, 다양한 셋탑박스, 자동차에서 돌아가는 안드로이드 오토, VSCODE도 Chromium을 사용중
- JavaScript 엔진: V8
- Chrome 브라우저와 동일한 엔진

그래서, 작업을 하다보면 IOS만 안된다.하는 문제들이 꽤나 발생한다고 한다.

이건 내부적으로 엔진자체가 다르기 때문이었다!!

WebKit은 왜 이렇게 복잡할까? (초간단 개념)

WebKit 내부는 여러 프로세스로 나뉘어 있다.

WebProcess: HTML, CSS, JS 실행
NetworkProcess: 네트워크 요청
GPUProcess: 렌더링
UIProcess: 앱과 연결되는 레이어

즉, 웹뷰는 싱글 프로세스처럼 보이지만, 실제로는 멀티 프로세스로 동작한다

이로 인해

쿠키가 동기화되지 않거나
로그인 상태가 어긋나거나
화면이 갑자기 하얗게 되는 문제가 발생할 수 있다.

WebView에서 쿠키가 어긋나는 실제 이유는 ..

브라우저의 구조와 내부적으로 차이가 있어, 쿠키를 누가 관리하느냐가 다르다!

브라우저의 구조

쿠키는 탭 단위가 아닌, 브라우저 전체의 공유 리소스다.
모든 탭이 같은 Cookie Store 를 보기에, Network Process 만 값을 가지고 있다.

[Browser(UI) Process]  ← 최상위 관리자
   |
   ├── Network Process  ← 쿠키 저장/전송
   ├── Renderer Process (탭들)
   └── GPU Process

웹 뷰의 구조

웹뷰는 브라우저 전체 관리자가 아니고, 앱마다 웹뷰의 인스턴스가 분리된다.

[App Process]
   |
   └── WebView (WebKit)
        ├── WebProcess
        ├── NetworkProcess
        └── GPUProcess

그래서, 실제로 WebView에서 쿠키가 어긋나는 실제 이유들은 아래와 같다.

WebView 인스턴스가 여러 개
- A WebView
- B WebView
→ 즉, 같은 앱이어도 웹뷰끼리 서로 다른 프로세스를 가져, 다른 쿠키 스토어를 가질 수 있다.
앱 ↔ WebView 경계
웹뷰에는 브라우저에는 없는 경계가 있다.
따라서 native 앱에서 네트워크 요청, webView 에서 요청
두 요청 간에 쿠키 공유가 자동으로 되지 않는다.
```
네이티브 앱 영역  ← 경계 →  웹 영역
```
→ 로그인 상태가 어긋나게 되는 원인
프로세스 재시작이 조용히 일어나게 된다
WebView는 메모리 부족, 백그라운드, IOS 정책 등으로 인해
WebProcess / NetworkProcess가 죽었다가 재생성될 수 있다.
그럼 이때 아래와 같은 문제들로 인해 화면이 하얗게 보일 수 있다!
- JS context 날아감
- sessionStorage 날아감
- 쿠키도 타이밍 이슈 발생

따라서, 간단하게 아래 내용들만 생각하면 좋을 것 같다

웹앱은 서비스의 형태이다
PWA, WebView, 하이브리드는 배포 전략이다
WebView는 하나의 브라우저가 아닌 앱 UI의 일부다
iOS와 Android는 웹 엔진이 다르다
WebView는 멀티 프로세스 구조다
브라우저에서 되던 게 안 될 수 있다

출처