장보기•쇼핑 성능 최적화 고군분투기: 웹 전환 과정에서의 경험과 교훈 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#webview#web-performance#caching#client-side-rendering#lazy-loading#code-splitting

AI 요약

빠른 실험과 배포를 위해 배민 장보기·쇼핑의 주요 화면을 native에서 web으로 전환한 뒤, 느린 첫 화면과 scroll·memory 문제를 측정해 단계적으로 개선한 사례다. 감상 대신 FCP 1.5초·LCP 2.35초·load 4.5초라는 baseline을 잡고 최적화의 출발점으로 삼는다.

핵심 포인트

모든 필수 API 응답을 기다려 흰 화면·spinner만 보이던 SSR을, 가벼운 HTML/JS를 CDN에서 즉시 주는 CSR로 바꿔 skeleton을 먼저 노출하고 API를 병렬 대기해 FCP 약 39% 단축
화면 밖 264개 image를 한꺼번에 받던 문제를 native lazy loading과 Lambda·S3 resize로 request 약 70% 절감, 비활성화됐던 WebView cache를 검증·clear 장치와 함께 재활성화해 AWS 월 비용 55.8%(연 약 천만 원) 절감
server-driven UI로 viewport 아래 section을 render하지 않고, main bundle보다 앞선 inline script로 critical API를 prefetch(Axios interceptor·cache 재사용), route·component code splitting으로 핵심 지표를 대부분 1초 안으로
약 천 개 상품을 모두 DOM에 남겨 GC·정지·crash를 부르던 list를 TanStack Virtual로 보이는 영역만 유지하고, 사용자 75%가 두 tab 이하만 방문한다는 data로 최근 두 tab만 memory에 보존(Sentry RUM으로 회귀 관찰)

왜 읽나native를 web으로 옮기며 native 수준 UX를 지켜야 하는 프론트엔드 팀에게, 지표 baseline부터 rendering·network·bundle·memory까지 비용과 함께 정리한 성능 최적화 로드맵.

챕터별 상세

011:58 – 9:13

빠른 실험을 위한 native-to-web 전환

Native는 iOS와 Android를 각각 개발하고 심사와 user update를 기다려야 하며 backend도 여러 app version의 API를 유지해야 하므로, quick-commerce의 빠른 experiment cycle에 제약이 있었다. 팀은 주요 화면을 web으로 전환하되 native 수준의 사용성을 지키기로 하고, 감상 대신 FCP 1.5초, LCP 2.35초, load 4.5초라는 baseline을 측정해 최적화의 출발점으로 삼았다.

기존 SSR은 모든 필수 API가 응답해야 HTML을 돌려줄 수 있어 그동안 WebView가 흰 화면과 spinner만 보여 줬고, app 내부 page에는 SEO 이점도 없으면서 server traffic과 장애 지점만 늘렸다. 가벼운 HTML과 JavaScript를 CDN에서 즉시 전달하는 CSR로 전환해 skeleton을 먼저 노출하고 API를 병렬로 기다리게 하면서 FCP를 약 39% 단축했다.

화면 밖 264개 image를 한꺼번에 받고 최대 1MB 원본까지 그대로 그리던 문제는 native lazy loading과 Lambda·S3 기반 resize pipeline으로 request를 약 70% 줄이고 load time을 크게 낮췄다. Native 설정 때문에 비활성화돼 있던 WebView cache도 조직 단위 검증과 cache clear 장치를 갖춰 다시 켜 FCP·LCP·load를 추가 개선했고, AWS 월 비용을 55.8% 줄여 연간 약 천만 원을 절감했다.

Server-driven UI로 viewport 아래 section을 애초에 render하지 않아 JavaScript 실행량을 줄이고, main bundle보다 앞선 inline script가 critical API를 prefetch한 뒤 Axios interceptor와 cache로 response를 재사용했다. Route와 component를 lazy load하는 code splitting까지 더해 여러 단계를 거치며 핵심 지표를 대부분 1초 안으로 낮췄고, Sentry real-user monitoring으로 release 이후의 성능 회귀를 계속 관찰했다.

Native list는 보이는 cell을 재활용하지만 web은 약 천 개 상품을 모두 DOM에 남겨 garbage collection, UI 정지와 app crash 위험을 만들었다. Dynamic row height 요구를 충족한 TanStack Virtual로 보이는 영역만 유지하고, 사용자 75%가 두 개 이하 tab만 방문한다는 data를 근거로 최근 두 tab의 상태만 memory에 보존해 native와 비슷한 탐색 경험과 자원 사용량 사이의 균형을 맞췄다.