웹뷰 로딩 병목과 새로운 실행 환경의 필요성
당근 프론트엔드코어팀은 서비스 내 여러 화면에서 사용 중인 웹뷰의 초기 로딩 성능 병목을 극복하기 위해 크로스플랫폼 기술인 Lynx(링크스)를 프로덕션 환경에 검토 및 도입했다고 밝혔다. 당근 측 설명에 따르면, 웹뷰 환경에서는 서버 사이드 렌더링(SSR)을 적용하더라도 네트워크를 통해 웹 문서와 초기 데이터를 수신하는 과정 자체가 남아 근본적인 대기 시간을 없애기 어려웠다.
또한 클라이언트 캐싱이나 임시 네이티브 화면 노출 같은 보완책은 시스템 복잡도를 크게 가중시키는 문제가 있었다. 이에 따라 당근은 홈 피드나 채팅 등 핵심 비즈니스 화면은 기존 네이티브 스택으로 유지하되, 웹뷰가 맡고 있던 일부 영역을 화면 단위로 점진 교체할 수 있는 경량 렌더링 계층을 찾기 시작했다. 해당 과제에는 프론트엔드, iOS, Android 엔지니어 각 1명씩 총 3명의 최소 인력이 투입되었다.
Lynx의 기술적 아키텍처: PrimJS와 듀얼 스레드 렌더링
바이트댄스가 2025년 3월 오픈소스로 공개한 Lynx는 React와 유사한 문법 체계 및 CSS 모델을 모바일 네이티브 뷰 계층으로 변환하는 구조를 취한다. 당근이 주목한 주요 기술적 특징은 메인 스레드 런타임에 채택된 경량 자바스크립트 엔진 'PrimJS(QuickJS 기반)'다. 복잡한 연산의 최대 처리량보다 런타임 초기화 오버헤드를 낮추는 데 초점을 맞추어 화면 진입 시점의 지연을 줄였다.
여기에 듀얼 스레드 아키텍처(Dual-Thread Architecture)를 도입하여, 백그라운드 스레드가 React 생명주기 및 부수 효과를 연산하는 동안 메인 스레드가 첫 화면을 즉시 그리는 파이프라인을 지원한다. 또한 Rust 기반 빌드 도구인 Rspack 및 Rsbuild를 활용한 번들러 Rspeedy를 제공해 웹 개발자에게 친숙한 도구 체계를 유지하도록 설계되었다.
React Native·Flutter 대신 Lynx를 택한 운영적 이유
성숙한 생태계를 갖춘 React Native나 Flutter 대신 레퍼런스가 적은 Lynx를 택한 결정은 기술력 순위가 아니라 '운영 책임의 경계'에서 비롯됐다. React Native는 방대한 네이티브 모듈 생태계를 지녔지만, 앱 바이너리와 분리된 원격 번들을 배포할 경우 네이티브 모듈 버전 파편화, 권한, 플랫폼 수명주기까지 지속적으로 유지보수해야 하는 부담이 따른다. 전담 인력이 부족한 상태에서 모듈 사용을 제한하면 플랫폼 도입의 이점이 희석된다.
Flutter 역시 독자적 렌더링 엔진(Impeller/Skia)으로 인해 OS 고유의 동작 방식이나 접근성을 별도로 검증해야 하며, 표준 빌드 체계상 번들을 CDN을 통해 무중단 배포하는 구조를 마련하려면 추가 공수가 요구된다. 당근은 기존 네이티브 뷰 구조 안에 UI 블록이나 화면 단위로 삽입할 수 있는 '브라운필드(Brownfield)' 방식과 통제 가능한 런타임 표면을 확보하는 것이 장기적 관리 비용 측면에서 더 현실적이라고 판단했다.
IFR 구현의 물리적 조건과 검증상의 한계
Lynx가 내세우는 핵심 기능인 '즉각적인 첫 프레임 렌더링(IFR, Instant First-Frame Rendering)'은 무조건적인 즉시 표시를 보장하지 않는다. Lynx 공식 기술 문서에 명시되어 있듯이, UI 번들이 로컬에 없어 비동기 네트워크 다운로드를 거쳐야 하거나 첫 화면을 구성하는 핵심 데이터가 네트워크 응답 이후에 준비되는 구조라면 메인 스레드 역시 대기 상태에 빠질 수밖에 없다.
따라서 IFR의 이점을 실현하려면 번들을 사전에 내려받아 캐싱하거나 네이티브 계층에서 초기 렌더링 데이터를 동기적으로 주입하는 설계가 선행되어야 한다. 당근 측 역시 이러한 구조적 전제 조건을 확인한 뒤 번들 사전 수신 및 네이티브 데이터 주입 경로를 결합하는 방식으로 화면 최적화를 진행했다고 설명했다.
실무 적용 시 유의점과 추가 검증 과제
이번 사례는 성숙한 프레임워크의 풍부한 기능보다 '팀이 감당 가능한 운영 범위'에 기술 선택의 방점을 둔 실무적 접근을 보여준다. 대규모 전환 대신 웹뷰가 담당하던 영역에 한정해 위험을 격리하고, 문제 발생 시 웹뷰로 즉시 롤백할 수 있는 안전장치를 둔 점은 엔지니어링 리스크를 낮추는 타당한 전략이다.
다만 공개된 내용에는 정량적 데이터가 부재하다는 점을 감안해야 한다. 웹뷰 대비 구체적인 로딩 시간(ms) 단축 폭이나 메모리·배터리 소비량 등 객관적 수치는 공개되지 않았으며, 어떤 특정 서비스 화면에 우선 적용되었는지도 구체화되지 않았다. 오픈소스 공개 시점이 비교적 최근인 만큼, 외부 문서화 부족으로 인해 소스 코드를 직접 분석해야 하는 엔지니어링 비용이 수반된다는 점도 도입 검토 시 반드시 고려해야 할 요소다.
출처
당근 기술 블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
웹뷰 다음의 레일을 깔다: 당근이 Lynx를 선택한 이유 (새 창)
