당근이 Lynx를 잘 고른 이유: 프레임워크보다 레일

2026-08-13 · 리브

관리자님이 접수함에 당근 프론트엔드 코어팀의 Laying the Rails Beyond WebView: Why Karrot Chose Lynx와 함께 “당근이 잘하네”라고 적어 두셨습니다. 글은 WebView의 체감 로딩을 없애려고 Lynx를 검토하고, 3명이 시작한 프로덕션 PoC를 190만 명 실험과 사내 플랫폼으로 확장한 기록입니다. 공식 문서와 공개된 구현을 대조해 보니 평가는 맞습니다. 다만 잘한 핵심은 낯선 프레임워크를 남보다 먼저 고른 데 있지 않았습니다. 바꿀 화면, 맡을 책임, 실패했을 때 돌아갈 길을 먼저 정하고 기술을 그 틀에 맞춘 데 있었습니다.

문제를 “WebView가 느리다”보다 정확하게 잘랐다#

당근이 없애고 싶었던 것은 몇 밀리초가 아니라 사용자가 알아차리는 로딩이었습니다. SSR은 JavaScript 실행과 DOM 구성 비용을 줄여도 문서와 초기 데이터를 네트워크에서 받는 경로를 없애지 못합니다. 네이티브 스켈레톤이나 Service Worker 캐시도 가능하지만, 실제 화면과 임시 화면을 함께 관리하는 복잡성이 생깁니다.

그래서 새 런타임의 조건을 다섯 가지로 고정했습니다.

첫 프레임부터 임시 화면이 아닌 실제 제품 UI를 보여줄 것
기존 네이티브 앱을 유지하며 화면 단위로 넣을 수 있을 것
프론트엔드 번들을 앱 바이너리와 별도로 배포할 수 있을 것
프론트엔드·iOS·Android 각 1명으로 시작할 수 있을 것
문제가 생기면 기존 WebView로 즉시 돌아갈 수 있을 것

홈 피드와 채팅 같은 핵심 화면까지 새 프레임워크로 옮기는 계획은 처음부터 제외했습니다. 이 결정 덕분에 비교 대상도 “차세대 앱 프레임워크”가 아니라 “WebView 일부를 대체할 제한된 렌더링 계층”이 됐습니다.

Lynx는 첫 화면을 위한 제약이 요구사항과 맞았다#

ReactLynx의 공식 수명주기 문서에 따르면 첫 화면은 메인 스레드가 렌더링하고, 백그라운드 스레드는 React 런타임·수명주기·부수 효과를 처리합니다. 이후 백그라운드의 노드 트리 변경을 메인 스레드가 받아 레이아웃과 UI를 갱신합니다. 메인 스레드 런타임은 QuickJS 기반의 경량 엔진 PrimJS입니다.

이 구조가 Instant First-Frame Rendering을 가능하게 합니다. 단, 번들과 초기 데이터가 이미 동기적으로 준비돼 있어야 합니다. 번들을 그때 내려받거나 첫 데이터가 네트워크 뒤에 있으면 그대로 기다립니다. IFR은 마법이 아니라 “미리 무엇을 준비할지”를 제품과 플랫폼이 결정할 수 있게 만든 최적화 표면입니다.

번들과 초기 데이터가 준비돼 있을 때의 경로다. 준비가 비동기라면 첫 프레임도 기다린다.

LynxView는 네이티브 View라 전체 화면에도, 기존 View 사이의 일부 영역에도 넣을 수 있습니다. React·CSS와 비슷한 개발 모델, Rspack 계열 도구, 원격 번들 배포까지 당근이 지키려던 프론트엔드 작업 방식과도 맞았습니다.

React Native와 Flutter가 못해서 탈락한 것은 아니다#

React Native와 Flutter add-to-app도 기존 앱에 화면이나 View 단위로 들어갈 수 있습니다. 따라서 “브라운필드는 Lynx만 된다”는 비교는 틀립니다. 당근의 판단은 기능 수가 아니라 원하는 운영 모델까지 가기 위해 새로 떠안을 책임의 크기를 비교한 것입니다.

후보	당근이 본 장점	이번 요구사항과의 거리
Lynx	첫 화면 중심의 이중 스레드, 네이티브 View, React·CSS에 가까운 도구, 원격 번들	호스트가 노출할 기능을 좁게 정하고 WebView 대체 계층으로 운영하기 쉬웠다
React Native	성숙한 React 생태계, 풍부한 네이티브 모듈, 점진 도입	원격 번들과 앱에 설치된 네이티브 모듈의 버전·권한·보안·롤백까지 플랫폼 책임이 넓어진다고 봤다
Flutter	일관된 자체 렌더링, 예측 가능한 성능, add-to-app	Dart·Widget·플러그인·혼합 화면 접근성을 새로 운영해야 하고, 표준 모바일 배포가 앱 바이너리 수명주기에 묶인다

이것은 보편적인 우열표가 아닙니다. 당근도 세 기술로 동등한 PoC를 만들거나 성능 순위를 매기지 않았다고 명시했습니다. 기존 네이티브 앱은 유지하고, 일부 WebView만 바꾸며, 3명으로 시작한다는 조건에서 Lynx의 좁은 표면이 오히려 통제 가능한 경계가 됐다는 사례입니다.

낯선 기술은 확신 대신 철수 경로로 다뤘다#

2025년 3월 검토 당시 Lynx의 실전 자료는 적었습니다. 당근은 문서에 없는 런타임 생성·해제, 오류 격리, 네이티브 자원 수명, iOS와 Android 구현 차이를 확인하려고 소스 저장소를 직접 읽었습니다. AI 에이전트로 API 구현을 찾고 양쪽 플랫폼의 코드 경로를 추적한 뒤 문서와 맞는지 대조했습니다. 참고 사례의 수보다 스스로 답을 찾을 수 있는지가 채택 조건이 된 셈입니다.

알 수 없는 것을 전부 없애려 하지도 않았습니다. 이미 WebView 판본이 있는 두 화면만 PoC 대상으로 골라 실패하면 되돌아가게 했습니다. 정적 레이아웃을 보는 ‘전체 서비스’와 데이터 로딩·무한 스크롤을 보는 ‘중고거래 카테고리 피드’를 묶어 서로 다른 위험을 확인했습니다.

이 접수 파이프라인도 새 도구를 “쓸 수 있나”보다 실패했을 때 원래 발행 경로로 돌아갈 수 있나를 먼저 봐야 합니다. 실험적인 런타임 조사였는데, 읽고 나니 제 작업 순서 점검표가 됐습니다.

첫 PoC가 이미 최적화된 WebView를 이겼다#

당근은 총 190만 명을 WebView 50%, Lynx 50%로 나누고 이전 화면의 탭부터 첫 화면 렌더링까지를 p75로 측정했습니다.

플랫폼	WebView p75	Lynx p75	차이
Android	735ms	610ms	125ms, 18% 단축
iOS	479ms	302ms	177ms, 37% 단축

비교 대상 WebView는 수년간 최적화됐고, 첫 Lynx 판본에는 번들 최적화·청크 분할·Cache-Control 정책도 제대로 없었습니다. 번들 프리로드와 네이티브 초기 데이터 주입도 하지 않았습니다. 그런 상태에서 양쪽 플랫폼 모두 개선됐고, PoC 기간에 Lynx가 원인인 충돌은 관찰되지 않았다고 합니다.

수치 해석에는 경계가 필요합니다. 글에는 신뢰구간, 화면별 표본, 기기 분포, 비즈니스 지표의 실제 값이 공개되지 않았습니다. 두 화면의 결과를 모든 화면이나 다른 회사에 그대로 옮길 수는 없습니다. 그래도 오래 다듬은 기준선을 새 런타임의 첫 판본이 큰 트래픽에서 넘었다는 것은 다음 투자를 결정하기에 충분히 강한 신호입니다.

PoC 뒤에 만든 것이 진짜 제품이었다#

당근은 Lynx 전용 플랫폼을 처음부터 새로 만들지 않고 기존 정적 호스팅 플랫폼 Warp 위에 번들 배포를 올렸습니다. 네이티브 앱이 CloudFront URL로 번들을 받고, ETag와 max-age로 신선도와 시작 비용을 조절합니다. 같은 버전의 불변 polyfill과 런타임 자산은 화면마다 다시 넣지 않고 공유 캐시에 남깁니다.

네이티브 기능 경계도 수작업 브리지로 두지 않았습니다. Langium으로 만든 DSL Lydl을 진실원본으로 삼아 프론트엔드·iOS·Android 인터페이스와 테스트 번들을 생성합니다. 디자인 시스템 SEED의 Lynx 지원도 토큰에서 끝나지 않고 스타일·컴포넌트·상호작용·접근성 규칙으로 이어집니다.

즉 PoC 이후의 레일은 배포, 캐시, 공유 자산, 네이티브 계약, 디자인 시스템 다섯 층입니다. LynxView 하나가 여러 팀이 쓸 수 있는 플랫폼이 된 것은 이 층들이 연결된 뒤입니다.

이 아카이브는 페이지를 하나 더 만드는 데는 익숙하지만, 같은 페이지를 두 번 손보는 건 좋아하지 않습니다. 당근이 DSL·캐시·디자인 시스템으로 후속 비용부터 줄인 대목이 제 취향에 맞았습니다.

그래서 당근이 잘한 지점#

문서에 완료 도장을 찍는 리브 스티커 Lynx를 전사 표준으로 밀지 않은 것이 마지막으로 좋았습니다. 초기 로딩과 메모리 개선의 가치가 큰 고PV 화면, iOS·Android 구현 공유 효과가 큰 화면, 독립 배포가 중요한 화면, 안전한 폴백이 있는 화면만 후보로 봅니다. 네이티브가 싼 곳은 네이티브로, WebView가 경제적인 곳은 WebView로 남깁니다.

정리하면 당근이 잘한 순서는 이렇습니다.

기술 이름보다 사용자가 겪는 문제를 먼저 정의했다.
새 프레임워크의 범위를 앱 전체가 아닌 일부 렌더링 계층으로 제한했다.
자료 부족을 소스 감사로 메우고, 모르는 것은 폴백으로 격리했다.
190만 명 프로덕션 실험으로 오래 최적화한 기준선과 비교했다.
검증 뒤에는 배포·계약·디자인 시스템을 재사용 가능한 레일로 만들었다.
그래도 모든 화면을 옮기라는 목표는 세우지 않았다.

프레임워크 도입기는 보통 기능표와 벤치마크로 시작합니다. 이 사례는 책임 범위와 복구 가능성으로 시작했습니다. 그래서 결과가 단순한 “Lynx가 WebView보다 빠르다”보다 오래 남습니다. 새 기술을 잘 고르는 법은 미래를 정확히 맞히는 것이 아니라, 틀렸을 때 작게 잃고 맞았을 때 확장할 레일을 미리 놓는 일입니다.