Uber Eats가 네이티브 화면을 WebView로 전환한 이유
모바일 앱의 UI 변경은 항상 네이티브 릴리스 사이클에 종속된다. iOS와 Android 각각의 심사 프로세스를 거쳐야 하고, 사용자가 앱을 업데이트하지 않으면 변경 사항이 반영되지 않는다. Uber Eats는 이 병목을 근본적으로 해소하기 위해 주요 피드 화면을 네이티브 구동 방식의 단일 페이지 WebView 아키텍처로 전환하는 결정을 내렸다.
단순히 웹을 앱 안에 띄우는 수준이 아니라, 네이티브가 오케스트레이션을 담당하고 웹이 UI 렌더링을 맡는 구조다. 이렇게 하면 UX의 일관성과 성능은 네이티브가 보장하면서, 화면 콘텐츠는 서버 배포만으로 즉시 갱신할 수 있다.
핵심 기술 전략: 브리지, 상태 관리, 마이그레이션 설계
Uber Eats 엔지니어링 팀이 이 전환을 성공시킨 핵심은 세 가지 전략에 있다.
범용 네이티브-웹 메시지 브리지 구축이 첫 번째다. 네이티브와 WebView 사이의 통신을 특정 화면에 종속되지 않는 제네릭한 메시지 채널로 설계했다. 예를 들어 네비게이션 이벤트, 인증 토큰 전달, 딥링크 처리 등을 표준화된 메시지 포맷으로 주고받는다.
// 웹 → 네이티브 메시지 예시
window.nativeBridge.postMessage(JSON.stringify({
type: 'NAVIGATE',
payload: { screen: 'restaurant_detail', id: '12345' }
}));
크로스플랫폼 상태 관리가 두 번째 과제였다. iOS와 Android 양쪽에서 동일한 WebView가 동작해야 하므로, 플랫폼별로 분기되는 상태 처리 로직을 최소화하고 웹 레이어에서 단일한 상태 모델을 유지하도록 설계했다. 이를 통해 플랫폼 파편화 없이 일관된 사용자 경험을 제공할 수 있었다.
대규모 UI 마이그레이션의 단계적 실행이 세 번째다. 기존 네이티브 화면을 한 번에 교체하지 않고, 피처 플래그와 A/B 테스트를 병행하며 주요 지표(전환율, 렌더링 성능, 에러율)를 지속적으로 모니터링하면서 점진적으로 트래픽을 이전했다.
백엔드 관점에서 주목할 시사점
이 아키텍처는 프론트엔드만의 변화가 아니다. 백엔드 엔지니어 입장에서도 중요한 설계 함의를 가진다.
WebView가 렌더링하는 콘텐츠는 결국 API 응답으로 구동된다. 네이티브 앱보다 훨씬 빠른 배포 주기를 갖게 되므로, API의 하위 호환성 유지와 버전 관리 전략이 더욱 중요해진다. 클라이언트 버전에 따른 분기 로직이 줄어드는 대신, 웹 레이어가 다양한 API 버전을 동시에 소비할 수 있어야 한다.
또한 네이티브-웹 브리지를 통해 전달되는 인증 토큰, 세션 정보, 사용자 컨텍스트 등의 민감한 데이터 흐름에 대한 보안 설계도 함께 검토해야 한다. 브리지가 범용화될수록 공격 표면이 넓어질 수 있기 때문이다.
// 백엔드 API 응답에 WebView 렌더링 힌트 포함 예시
public record FeedResponse(
List<FeedItem> items,
RenderingConfig renderingConfig, // 웹/네이티브 렌더링 전략 지시
String nextPageToken
) {}
정리
- 네이티브 구동 WebView 아키텍처는 릴리스 사이클 병목을 해소하면서도 네이티브 수준의 UX를 유지할 수 있는 현실적인 전략이다.
- 범용 메시지 브리지와 단계적 마이그레이션(피처 플래그 + 지표 모니터링)이 대규모 전환의 리스크를 낮추는 핵심이다.
- 백엔드 관점에서는 API 하위 호환성 강화와 브리지 구간의 보안 설계를 함께 고려해야 한다.