앱이 “느리다”는 말은 감상평처럼 들리지만, 그로스 관점에선 명확한 지표입니다. 첫 실행이 늦고, 스크롤이 끊기고, 화면이 한 번 비면 유저는 온보딩 퍼널에서 바로 이탈합니다. 특히 React Native처럼 JS/UI 스레드가 얽힌 구조에선 ‘체감 속도’가 곧 마찰(Friction)이고, 마찰은 D1/D7 리텐션을 깎아먹는 세금이에요.
dev.to의 「React Native Performance: What I Measure and Fix First」는 이 문제를 아주 실전적으로 정리합니다. 핵심은 “최적화”가 아니라 “측정 가능한 병목부터 잡는 우선순위”예요. 저자가 제일 먼저 보는 건 ① 시작 시간(탭→첫 의미 있는 화면), ② 프레임레이트(FPS, 스크롤/애니메이션), ③ 리스트 스크롤(FlatList 병목), ④ 메모리(누수/큰 할당), ⑤ 번들 크기(스타트업 지연)입니다. Flipper, RN 퍼프 툴, 네이티브 타임스탬프 같은 도구로 전후를 비교해 ‘회귀(regression)’를 막는 접근이죠.
왜 이게 그로스 레버냐고요? 시작 시간이 1~2초만 늘어나도 첫 세션에서 “아, 별로네” 판단이 내려지고, 그 판단은 재방문 확률을 크게 떨어뜨립니다. 스크롤 잔렉(jank)은 더 치명적입니다. 유저가 피드를 탐색하는 핵심 모먼트에 프레임 드랍이 발생하면 콘텐츠 품질이 아니라 앱 품질로 인식돼요. 즉, 성능은 기능 만족도가 아니라 신뢰를 깎습니다. 신뢰가 무너지면 ‘다음 액션(가입/권한 허용/첫 저장/첫 결제)’까지 못 갑니다.
여기서 “와 이거다!” 포인트는 성능 최적화가 실험 루프를 만들기 좋다는 점입니다. 저자가 말한 것처럼 릴리즈마다 스타트업 타임, 메인 피드 FPS, 5분 후 메모리 같은 베이스라인을 남겨두면, 신규 기능이 들어올 때마다 성장팀이 싫어하는 ‘체감 논쟁’을 끝낼 수 있어요. 숫자가 회귀하면 곧바로 원인을 좁히고 롤백/핫픽스 의사결정이 빨라집니다. 속도가 곧 실행력이고, 실행력이 곧 성장 속도입니다.
개선 액션도 전형적인 “퍼널 고장 지점”과 맞닿아 있습니다. 리스트가 느리면 FlatList(또는 FlashList)로 처리량을 끌어올리고, getItemLayout로 측정 비용을 줄이고, windowSize/maxToRenderPerBatch로 렌더 트리를 제한합니다. renderItem에서 인라인 함수/객체를 줄이고 메모이제이션(React.memo, useCallback, useMemo)으로 불필요한 리렌더를 막으면 스크롤 체감이 확 바뀝니다. 유저 입장에선 “피드가 잘 넘어간다” 한 줄이지만, 퍼널 관점에선 세션 길이와 탐색 깊이가 늘어나는 신호죠.
이미지는 또 하나의 숨은 범인입니다. 과한 해상도, 캐시 전략 부재, 오프스크린까지 한 번에 로드하는 패턴은 메모리와 FPS를 같이 터뜨립니다. 적정 사이즈 서빙(CDN 리사이즈), lazy-load, 필요 시 fast-image 같은 캐시 개선은 ‘콘텐츠 앱’에서 특히 효과가 큽니다. 콘텐츠가 많은 앱일수록 스크롤 성능이 곧 상품 진열대 품질이니까요.
시작 시간은 온보딩의 생사여부를 가릅니다. 초기 JS를 줄이고(지연 로딩, 비필수 import defer, 의존성 다이어트), Hermes로 스타트업/메모리 이득을 얻는 건 RN에서 흔한 “첫 30분에 낼 수 있는 임팩트”입니다(dev.to 기사도 Hermes를 대표 처방으로 언급). 유저는 로딩 스피너를 기다리며 우리 브랜드를 이해하지 않습니다. 기다리는 동안 설치를 후회합니다.
velog의 김프뷰(KIMPVIEW) 트러블슈팅 글도 같은 메시지를 다른 각도에서 보여줍니다. cache-first(SWR)로 “즉시 데이터 노출”을 만들려다, 최초 진입에서 ‘full render 전제가 깨져 화면이 아예 비는’ 버그가 발생했죠. 해결은 단순히 조건문 하나였지만, 본질은 렌더링 상태 머신의 전제를 지키는 설계였습니다(출처: velog). 이 사례가 중요한 이유는, 성능 최적화가 잘못되면 ‘더 빠르게’가 아니라 ‘아예 안 보이게’ 만들 수도 있다는 경고예요. 속도 개선은 반드시 관측(계측)과 안전장치(최초 1회 보장 같은 불변조건)와 함께 가야 합니다.
시사점은 명확합니다. React Native 성능 최적화는 “개발자 만족” 작업이 아니라 “리텐션 비용 절감” 작업입니다. 추천 실험 설계는 이렇게 가면 빨라요: 1) 핵심 스크린(홈/피드/검색/온보딩)만 타겟, 2) 성능 KPI를 2~3개로 고정(예: TTFMP, 스크롤 FPS, 메모리), 3) 한 영역만 수정하고, 4) 성능 지표 + D1/D7 + 온보딩 단계 전환율을 함께 본다. Conversion rate가 얼마나 오를까요? 제품마다 다르지만, 적어도 “초기 이탈”이 큰 앱은 작은 ms 개선이 큰 %로 환산되는 구간이 자주 나옵니다.
전망: 앞으로 RN 생태계는 더 빨라지겠지만, 경쟁도 그만큼 ‘기본기 상향평준화’가 됩니다. 결국 이기는 팀은 성능을 일회성 최적화가 아니라 “릴리즈 게이트(베이스라인 회귀 방지) + 실험 루프”로 운영하는 팀입니다. 빨리 테스트해봐야 돼요. 속도는 기능이 아니라 성장 채널이고, 성능 계측은 그 채널의 대시보드입니다.