웹뷰 기반 모바일 UI의 지속된 로딩 한계
당근 앱은 다수의 화면을 웹뷰(WebView) 환경을 통해 운영해 왔습니다. 그러나 웹뷰 화면이 열릴 때 네트워크를 거쳐 웹 문서와 필수 데이터를 불러오는 과정에서 발생하는 초기 로딩 비용은 오랫동안 해결해야 할 과제로 남아 있었습니다.
서버 사이드 렌더링(SSR)을 적용하거나 네이티브 임시 화면 노출, 서비스 워커 캐싱 등의 방안을 적용할 수도 있었으나, 이는 제품 전체의 복잡도를 크게 끌어올리는 문제를 낳았습니다. 당근 프론트엔드 코어 팀은 로딩 시간을 단순히 몇 밀리초 단축하는 것을 넘어 사용자가 로딩 자체를 체감하지 못하도록 첫 프레임부터 의도한 UI를 보여주는 환경을 모색했습니다.
새로운 런타임 선정을 위한 명확한 기준
당근 프론트엔드 코어 팀은 신규 런타임을 검토할 때 앱 전면 개편이 아닌 점진적 전환을 필수 요건으로 세웠습니다. 사용자가 주로 탐색하는 홈 피드나 거래가 성사되는 채팅 영역과 같은 핵심 영역은 기존의 안정적이고 빠른 네이티브 스택(iOS/Android)에 그대로 유지해야 했습니다.
동시에 앱 바이너리 재배포 없이 프론트엔드 번들만 독립 배포할 수 있어야 했으며, 대규모 조직 구성 없이 프론트엔드 1명, iOS 1명, Android 1명이라는 최소 인원으로 시작할 수 있어야 했습니다. 특히 문제가 발생했을 때 즉각 기존 웹뷰 구현으로 되돌아갈 수 있는 롤백 경로 확보가 핵심 전제였습니다. 이러한 기준 속에서 2025년 3월 Lynx가 유력한 대안으로 검토되기 시작했습니다.
PrimJS 엔진과 듀얼 스레드 아키텍처의 구조적 특징
Lynx는 React 및 CSS와 유사한 개발 모델을 제공하면서도 런타임 초기화 방식에서 기존 기술과 뚜렷한 차이를 보였습니다. 메인 스레드 런타임으로 QuickJS 기반의 경량 임베디드 자바스크립트 엔진인 PrimJS를 채택하여 복잡한 연산 처리량보다 초기 화면을 띄우는 초기화 비용 절감에 집중했습니다.
또한 렌더링 파이프라인을 메인 스레드와 백그라운드 스레드로 분리했습니다. 메인 스레드는 첫 화면 렌더링과 UI 갱신을 전담하고, 백그라운드 스레드는 전체 React 런타임과 컴포넌트 생명주기 및 사이드 이펙트를 처리합니다. 이를 통해 번들과 초기 데이터가 갖춰진 경우 백그라운드 연산을 기다리지 않고 첫 프레임을 동기적으로 완성하는 즉각 첫 프레임 렌더링(IFR) 환경을 구현합니다.
화면 제약 조건과 네이티브 데이터 주입의 상관관계
Lynx가 제공하는 즉각 첫 프레임 렌더링(IFR)은 강력한 사용자 경험을 제시하지만 구조적인 제약 조건을 수반합니다. 번들을 비동기로 다운로드해야 하거나 화면에 필수적인 초기 데이터를 네트워크 요청을 통해 받아와야 하는 구조에서는 메인 스레드 동기 렌더링이 성립하기 어렵습니다.
따라서 실무에서는 클라이언트 앱 설계 단계부터 화면 번들의 사전 프리로딩 정책과 네이티브 단에서의 초기 데이터 주입 전략을 긴밀하게 맞물려야 합니다. 화면 단위의 분기 설계가 정교하지 않다면 IFR의 장점이 희석될 수 있으므로, 플랫폼 레벨의 캐싱과 데이터 동기화 파이프라인 구축이 성공적인 전환의 실질적인 선결 과제로 해석됩니다.
점진적 기술 검증과 리스크 관리 관점의 시사점
당근의 이번 의사결정은 전체 서비스를 특정 크로스플랫폼 프레임워크로 전면 재작성하는 과도한 위험을 피하고, 웹뷰가 유발하던 성능 병목 지점만 정밀하게 걷어내는 실용적 접근을 보여줍니다. 네이티브 코어와 웹뷰 롤백 안전망을 양단에 배치한 점은 기술 도입에 따른 제품 중단 리스크를 통제하는 모범적 기준을 제시합니다.
다만 실무 적용 시에는 Lynx 엔진의 버전별 API 호환성이나 네이티브 브릿지 연동 과정에서 발생할 수 있는 잠재적 유지보수 비용을 면밀히 모니터링해야 합니다. 초기 리소스 투입을 최소화한 조직 구성이라 할지라도, 운영 단계에서 화면별 최적화 작업이 늘어날 경우 장기적인 프론트엔드 및 네이티브 협업 프로세스에 대한 표준화 논의가 지속적으로 뒷받침되어야 할 것으로 보입니다.
출처
당근 기술 블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Laying the Rails Beyond WebView: Why Karrot Chose Lynx (새 창)
