당근 프론트엔드코어팀이 WebView 기반 화면의 첫 프레임 렌더링 문제를 해결하기 위해 Lynx를 도입한 기록이다. 레퍼런스가 거의 없는 기술을 코드베이스 직접 분석으로 검증한 뒤 프로덕션에 적용했고, 1.9백만 사용자 A/B에서 Android 18%, iOS 37%의 첫 프레임 단축을 달성했다.
핵심 포인트- WebView는 SSR·서비스워커로 최적화해도 "네트워크로 문서·데이터를 가져와야 UI가 렌더된다"는 구조적 한계가 남는다.
- Lynx의 듀얼 스레드 구조: 메인 스레드(PrimJS/QuickJS)가 번들·초기 데이터만 있으면 첫 프레임을 즉시 렌더하고(IFR), 백그라운드 스레드가 전체 React 런타임을 처리한다.
- React Native 대신 Lynx를 선택한 핵심 이유: 앱 생태계 전체를 책임지는 프레임워크가 아니라 "화면 단위로 WebView를 대체하는 렌더링 계층"이 필요했다.
- Flutter는 독자 렌더링 모델로 기존 동작 재검증이 필요하고, CDN 번들 독립 배포 모델을 지원하지 않아 제외했다.
- PoC: 1.9백만 사용자 A/B, Android 18%(735→610ms), iOS 37%(479→302ms) 첫 프레임 단축.
상세 정리- 핵심 문제 재정의: 로딩 시간을 몇 ms 줄이는 게 아니라 "사용자가 로딩을 느끼지 못하게 만드는 것" — 첫 프레임에 실제 제품 UI가 보여야 한다.
- 요구사항: 화면별 점진적 도입, 앱 바이너리 업데이트 없는 번들 CDN 독립 배포, 소규모 팀(프론트·iOS·Android 각 1명), WebView 폴백 경로.
- PrimJS(QuickJS) 선택 이유: 최대 처리량보다 런타임 초기화 비용이 낮고, 호스트 앱이 노출할 API를 직접 제한할 수 있는 통제 가능한 실행 환경.
- IFR 조건: 번들과 핵심 데이터를 동기적으로 준비해야 함 — 이 제약이 번들 프리로드, 초기 데이터 네이티브 주입 등 첫 화면을 설계할 여지를 열어줬다.
- 툴체인: Rspeedy(Rspack/Rsbuild 기반), HMR 지원, webpack 생태계 호환, Brownfield 통합(LynxView를 네이티브 뷰 계층에 삽입).
- React Native 비교: Brownfield 지원은 있지만 네이티브 모듈 호환성·권한·보안·버전 동기화 등 생태계 복잡도가 "렌더링 계층만 필요한" 요구사항을 넘는다.
- 코드베이스 직접 검증: 레퍼런스가 없어 Lynx 레포를 클론, AI 에이전트로 탐색, iOS/Android 구현을 문서와 직접 대조했다.
- PoC 화면 선정: 정적 "전체 서비스" 페이지 + 연속 데이터 로딩·스크롤 "마켓플레이스 카테고리 피드" — 특성이 다른 두 화면으로 위험 분산.
- PoC 결과: 비최적화 상태에서 Android 18%(735→610ms), iOS 37%(479→302ms). 번들 최적화·청크 분리·프리로드·초기 데이터 주입으로 추가 개선 여지 남음.
- 인프라: CloudFront CDN 번들 배포, 공용 런타임 에셋 콘텐츠 주소 기반 장기 캐시, Lydl(Langium DSL)로 프론트·iOS·Android 인터페이스 코드를 단일 소스에서 생성.
- SEED Design 연동: @seed-design/lynx-react 패키지로 디자인 시스템을 Lynx 환경에서도 사용 가능하게 했다.
- 현재 범위(2026년 8월): 마켓플레이스 공유·최근 본 항목·즐겨찾기 — 전면 교체가 아닌 화면별 선택적 적용.
왜 읽나WebView를 크로스플랫폼 프레임워크로 점진적으로 대체하려는 모바일·프론트엔드 엔지니어에게, 기술 선택 기준 설정부터 코드베이스 직접 검증, 인프라 설계, PoC 측정까지 전 과정을 담은 실전 레퍼런스.
당근 테크블로그·
토스 SLASH·
LY Corporation·