웹뷰를 넘어서: 당근이 Lynx를 선택한 이유

당근 테크팀이 WebView 기반 화면의 첫 프레임 렌더링 지연 문제를 해결하기 위해 크로스플랫폼 프레임워크 Lynx를 도입한 과정을 다룬다. 1.9백만 사용자 A/B 테스트에서 Android 18%(735→610ms), iOS 37%(479→302ms)의 첫 프레임 시간 단축을 달성했다.

핵심 포인트

WebView는 네트워크 요청이 완료돼야 UI가 렌더되는 구조적 한계가 있어, SSR·서비스워커 같은 최적화를 쌓아도 로딩 자체를 없애는 것은 불가능하다.
Lynx는 PrimJS(QuickJS)와 듀얼 스레드 구조로 메인 스레드에서 첫 프레임을 즉시 렌더하고(IFR), 백그라운드 스레드에서 React 런타임을 처리한다.
React Native(생태계 복잡도)와 Flutter(독자 렌더링·CDN 독립 배포 불가) 대신 Lynx를 선택한 이유를 명확한 조건으로 정리했다.
PoC: 1.9백만 사용자 A/B 테스트, Android 18%(735→610ms), iOS 37%(479→302ms) 첫 프레임 단축.
전체 앱 전환이 아닌 화면 단위 점진적 적용 + 기존 WebView 폴백 경로 유지.

상세 정리

문제 정의: 첫 프레임에 플레이스홀더나 스켈레톤이 아닌 실제 제품 UI가 보여야 한다는 요구사항.
요구사항 5가지: 화면별 점진적 도입, 앱 바이너리 업데이트 없는 번들 독립 배포, 소규모 팀(프론트·iOS·Android 각 1명), WebView 폴백 경로.
Lynx 선택 이유 1 — PrimJS: 최대 처리량보다 런타임 초기화 비용이 낮아 모바일 UI 첫 프레임에 최적화돼 있다.
Lynx 선택 이유 2 — IFR: 메인 스레드가 번들·초기 데이터만 준비되면 즉시 첫 프레임을 렌더하고, 백그라운드 스레드는 전체 React 런타임을 처리한다.
Lynx 선택 이유 3 — 툴체인: Rspeedy(Rspack/Rsbuild 기반), HMR, webpack 호환, CDN 번들 독립 배포.
React Native 비교: 점진적 도입은 지원하지만 네이티브 모듈 호환성·권한·보안·버전 동기화의 생태계 복잡도가 크다.
Flutter 비교: 독자 렌더링 모델로 기존 동작 검증이 별도 필요하고, CDN 번들 서빙 모델을 지원하지 않는다.
코드베이스 직접 검증: 실사례가 적어 Lynx 레포를 클론 후 AI 에이전트로 탐색하며 iOS/Android 구현을 문서와 대조했다.
PoC 설계: 정적 "전체 서비스" 페이지 + 연속 스크롤 "마켓플레이스 카테고리 피드" — 특성이 다른 두 화면으로 리스크 분산.
PoC 결과: 1.9백만 사용자 A/B, Android 18%(735→610ms), iOS 37%(479→302ms) 첫 프레임 단축.
인프라 구축: CloudFront CDN 번들 배포, 공용 런타임 에셋 콘텐츠 주소 기반 장기 캐시, Lydl DSL(Langium)로 프론트·iOS·Android 인터페이스 코드 단일 소스 생성.
현재 범위(2026년 8월): 마켓플레이스 공유·최근 본 항목·즐겨찾기 등 일부 화면 — 전면 교체가 아닌 선택적 적용.

왜 읽나WebView 성능 한계를 크로스플랫폼 프레임워크로 대체하려는 모바일·프론트엔드 엔지니어에게 기술 선택 기준과 점진적 적용 전략의 실전 레퍼런스.

당근 테크블로그 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

웹뷰를 넘어서: 당근이 Lynx를 선택한 이유

이 글과 비슷한

웹뷰 다음의 레일을 깔다: 당근이 Lynx를 선택한 이유

토스의 디바이스 팜 만들기

AI 에이전트를 위한 Android CLI: 대규모 모바일 개발 환경에 적용하기