Lottie React Native

지금 두 가지 상황 중 하나에 있을 가능성이 높습니다. 디자이너가 Lottie JSON을 건네며 "오늘 안에 앱에 넣을 수 있겠어?"라고 묻는 경우, 혹은 이미 연동은 마쳤지만 개발 환경에서는 잘 되던 애니메이션이 실제 기기, 시작 시간, 릴리스 빌드가 변수로 들어오면서 부담이 커지는 것을 느낀 경우입니다.

여기서 Lottie React Native가 흥미로워집니다. 기본 데모는 쉽습니다. 프로덕션에 쓸 수 있는 구현은 그렇지 않죠. 차이는 보통 설치 방식, 재생 제어 방법, 그리고 애니메이션 파일을 단순한 에셋으로 볼지 성능 예산의 일부로 볼지에 따라 갈립니다.

React Native 앱에 Lottie가 필수적인 이유
- 디자인과 엔지니어링, 이제 같은 싸움은 그만
- Lottie가 가장 잘 맞는 곳
Lottie 개발 환경 설정하기
첫 번째 Lottie 애니메이션 표시하기
Lottie 애니메이션 컨트롤 마스터하기
프로덕션 앱 성능 튜닝
자주 발생하는 Lottie 이슈 해결하기

React Native 앱에 Lottie가 필수적인 이유

React Native에서 완성도 높은 제품 애니메이션을 직접 다시 구현해봤다면 그 고통을 잘 알 겁니다. 작은 모션 디테일 하나가 타이밍 로직, 보간, 플랫폼별 특이사항 덩어리로 바뀌니까요. 애니메이션이 비슷해 보일 수는 있지만, 그 '비슷함'은 보통 디자이너가 넘긴 결과물이 아닙니다.

Lottie는 그 워크플로우를 바꿨습니다. 2016년 Airbnb가 Lottie를 오픈 소스로 공개했고, 그 릴리스는 엔지니어가 프레임 단위로 애니메이션을 다시 만들 필요 없이 디자이너가 직접 애니메이션을 전달할 수 있게 하면서 모바일 애니메이션을 바꿨습니다. 일부 엔터프라이즈 환경에서는 그 변화로 모바일 앱 개발 비용을 최대 40%이는 Airbnb의 Lottie 개요.

디자인과 엔지니어링, 이제 같은 싸움은 그만

Lottie React Native의 핵심 이점은 단순히 'JSON 기반의 아름다운 애니메이션'이 아닙니다. 관심사 분리가 핵심입니다. 디자이너는 After Effects에서 작업하고 Bodymovin으로 내보냅니다. 개발자는 모션을 커스텀 code로 변환하는 대신 네이티브 기반 재생으로 출력을 렌더링합니다.

이유는 애니메이션 작업이 쉽게 확산되기 때문입니다. 축하 상태 애니메이션 하나만으로도 디자인 리뷰, 제품 리뷰, Android 동작, iOS 동작, 접근성, 시작 성능까지 영향을 미칠 수 있습니다. Lottie는 이러한 영향 범위를 좁혀줍니다.

실무 원칙: 단순한 opacity나 translate 전환만 필요할 때가 아니라, 애니메이션이 제품 경험의 일부일 때 Lottie를 사용하세요.

사용자 경험 측면도 있습니다. 모션은 피드백을 제공하고, 동작을 확인시켜 주며, 로딩 상태를 덜 지루하게 만듭니다. 팀에서 인터페이스의 완성도, 리텐션, 신뢰를 진지하게 고민한다면 애니메이션은 그 논의의 일부입니다. 더 넓은 앱 사용자 경험 논의는 결국 같은 결론에 도달합니다: 빠른 피드백이 정적인 화면보다 낫습니다.

Lottie가 가장 잘 맞는 곳

Lottie React Native는 다음 경우에 가장 잘 맞습니다:

브랜드 마이크로 인터랙션 좋아요, 저장, 체크마크, 구매 성공 상태 등
온보딩 일러스트레이션 비디오를 배포하지 않고도 커스텀한 느낌을 줘야 할 때
로딩 및 빈 상태 정적인 UI가 미완성으로 느껴질 때
기능 교육 GIF나 MP4를 임베딩하지 않고 모션을 원하는 제품일 때

이것이 해결하지 못하는 것은 모든 애니메이션 문제가 아닙니다. 기본적인 화면 전환의 경우, React Native 자체의 애니메이션 도구가 더 간단한 경우가 많습니다. 매우 크거나 상호작용이 높은 모션 시스템에서는 JSON 형식이 이점이 아니라 트레이드오프가 될 수 있습니다. 프로덕션 환경에 진입하면 이러한 트레이드오프가 더 중요해지는데, 대부분의 튜토리얼은 여기서 너무 일찍 끝납니다.

Lottie 개발 환경 설정하기

설치 경로는 먼저 하나의 결정에 따라 달라집니다: Expo managed workflow 또는 bare React Native. 두 방식의 개념을 혼동하지 마세요. 대부분의 설정 문제는 Expo 환경에서 bare workflow 가이드를 따르거나, Expo가 모든 네이티브 디테일을 알아서 처리해 줄 것이라고 오해할 때 발생합니다.

Expo 및 Bare React Native 프로젝트에서 Lottie 애니메이션을 설정하는 단계를 보여주는 플로우차트입니다.

설치 전에 워크플로우를 선택하세요

Expo 앱을 사용 중이고 가장 빠른 설정을 원한다면, 커스텀 네이티브 작업이 필요한 상황이 아닌 한 Expo 방식을 유지하세요. Bare 앱을 사용 중이거나 직접 제어가 필요한 네이티브 모듈에 이미 의존하고 있다면, 일반 네이티브 의존성으로 설치한 후 즉시 iOS와 Android 빌드를 모두 검증하세요.

많은 팀이 프로젝트 유형에 맞춰 설정을 유지하면 디버깅이 얼마나 쉬워지는지 과소평가하곤 합니다. 커스텀 네이티브 통합을 구축하는 많은 팀이 Expo EAS의 대안으로 Capgo를 앱 수정이 어려워질 때까지 기다리지 말고 미리 검토하세요.

Expo managed 설정

Expo managed 앱의 경우, 설정을 최소화하세요.

패키지 설치
```
npx expo install lottie-react-native
```
Metro 재시작
```
npx expo start -c
```
기기 또는 시뮬레이터에서 확인하세요 먼저 로컬 JSON 파일로 아주 작은 애니메이션부터 렌더링해 보세요. 대용량 에셋과 새 설치를 동시에 디버깅하지 마세요.

Expo에서 중요한 실무 참고 사항 몇 가지:

로컬 파일을 우선 사용하세요: 라이브러리 작동 여부만 확인하려는 단계에서 원격 애니메이션을 디버깅하면 네트워크 노이즈가 발생할 수 있습니다.
릴리스 동작을 조기에 테스트하세요: 개발 모드에서는 타이밍 및 성능 관련 이슈가 숨겨질 수 있습니다.
에셋 경로를 확인하세요: JSON 파일 경로가 잘못된 것은 "아무것도 렌더링되지 않는" 가장 흔한 원인 중 하나입니다.

Expo는 "작동"으로 가는 가장 빠른 길이지만, "확장"으로 가는 가장 빠른 길이라는 뜻은 아닙니다.

Bare React Native 설정

Bare 프로젝트라면 native dependencies를 즉시 설치하고 검증하세요.

패키지 설치
```
npm install lottie-react-native
```
iOS pod 설치
```
cd ios && pod install && cd ..
```

앱 재빌드

npx react-native run-ios

또는

npx react-native run-android

많은 퀵스타트 가이드가 건너뛰는 부분이 있습니다. 설치 후 무언가가 깨졌다고 판단하기 전에 반드시 전체 네이티브 재빌드를 수행하세요. 앱에 올바르게 컴파일되지 않은 네이티브 의존성은 핫 리로드로 해결할 수 없습니다.

시간을 절약하는 Bare workflow 체크

계속하기 전에 이 짧은 체크리스트를 확인하세요:

체크 항목	왜 중요한가
설치 후 재빌드	네이티브 모듈은 새 컴파일이 필요합니다
실행 `pod install`	이것 없이는 iOS가 안정적이지 않습니다
먼저 간단한 로컬 JSON을 사용하세요	설치 문제를 에셋 문제와 분리합니다
양쪽 플랫폼을 초기에 테스트하세요	Android와 iOS는 서로 다른 이유로 실패할 수 있습니다

패키지가 깨끗하게 설치되었는데 첫 번째 애니메이션이 표시되지 않는다면, 보통 설치 문제가 아닙니다. 대개 에셋 경로, 컴포넌트 크기, 또는 재생 설정 문제입니다.

첫 번째 Lottie 애니메이션 표시하기

처음 동작하는 애니메이션은 지루해야 합니다. 로컬 파일, 고정 크기, 자동 재생 켜기, 루프는 선택 사항. 조건부 재생, 원격 JSON, 또는 레이어가 복잡한 애니메이션 내보내기로 시작하지 마세요.

노트북에 code가 표시되고 모니터에 모바일 애니메이션 앱이 보이는 현대적인 개발자 워크스페이스.

로컬 애니메이션 파일 추가

아직 에셋 폴더가 없다면 하나를 만드세요:

assets/
  animations/
    success.json

이름은 간단하게 유지하세요. 공백, 특수 기호, 그리고 여러 단계로 중첩된 폴더를 피하세요. require() 경로가 명확하게 유지되도록 하세요.

Lottie를 초기 브랜드 로딩 화면이나 런칭 후 핸드오프에 사용할 계획이라면, 큰 애니메이션을 시작 경로에 넣기 전에 신중하게 고려하세요. 특히 React Native 스플래시 화면 동작.

LottieView로 렌더링하기

큰 화면 파일에 바로 넣지 말고 전용 컴포넌트를 만드세요:

import React from 'react';
import { View, StyleSheet } from 'react-native';
import LottieView from 'lottie-react-native';

export function SuccessAnimation() {
  return (
    <View style={styles.container}>
      <LottieView
        source={require('../assets/animations/success.json')}
        autoPlay
        loop={false}
        style={styles.animation}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    alignItems: 'center',
    justifyContent: 'center',
  },
  animation: {
    width: 220,
    height: 220,
  },
});

이렇게 하면 세 가지 유용한 효과를 얻습니다:

라이브러리가 올바르게 렌더링되는지 증명합니다
에셋 경로가 올바르게 해석되는지 확인합니다
나중에 재생 및 크기를 조정할 수 있는 독립된 장소를 제공합니다

기본 사항을 건너뛰면 바로 드러나는 몇 가지 함정이 있습니다:

너비나 높이가 없습니다: 애니메이션은 존재하지만 보이지 않을 수 있습니다.
잘못됨 require() 경로: Metro가 파일을 찾지 못합니다.
잘못된 export: 일부 JSON 파일은 기술적으로 유효하지만 모바일에서 예상대로 동작하지 않는 기능이 포함되어 있습니다.

첫 번째 렌더링은 로컬에서 결정적으로 유지하세요. 아키텍처가 아니라 통합을 테스트하는 것입니다.

더 나은 첫 화면 테스트

중립적인 배경의 간단한 화면에 컴포넌트를 배치하세요:

import React from 'react';
import { SafeAreaView, StyleSheet } from 'react-native';
import { SuccessAnimation } from './src/SuccessAnimation';

export default function App() {
  return (
    <SafeAreaView style={styles.screen}>
      <SuccessAnimation />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  screen: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#fff',
  },
});

iOS와 Android 시뮬레이터에서 모두 정상 작동한다면, 첫 번째 실질적인 장벽을 넘은 것입니다. 다음 단계는 더 많은 애니메이션을 추가하는 것이 아닙니다. 선언적 props를 사용할 때와 refs로 직접 제어할 때를 구분하는 법을 배우는 것입니다.

Lottie 애니메이션 컨트롤 마스터하기

대부분의 Lottie React Native 버그는 애니메이션이 상태에 반응해야 할 때 발생합니다. 자동 재생은 쉽습니다. 하지만 "사용자가 항목을 좋아하면 해당 세그먼트를 재생하고, 좋아하지 않으면 되감으며, 컴포넌트가 다시 렌더링될 때 버벅임이 없어야 한다"는 요구사항에서부터 복잡해집니다.

Lottie에서 선언적 및 명령형 애니메이션 제어 방식의 차이와 구체적인 사용 사례를 비교한 차트.

재생이 단순할 때는 props 사용하기

비인터랙티브 재생에는 props만으로도 충분합니다.

<LottieView
  source={require('../assets/animations/loading.json')}
  autoPlay
  loop
  speed={1}
/>

이 스타일은 다음 경우에 적합합니다:

로딩 인디케이터
패시브 온보딩 일러스트레이션
장식용 빈 상태

선언적이고 가독성이 좋습니다. 컴포넌트가 마운트되면 재생이 시작되고, React가 전체를 관리합니다. 애니메이션 로직을 props만으로 완전히 설명할 수 있다면, 그 안에 유지하세요.

더 고급스러운 선언형 사례는 progress입니다. 여기서 애니메이션 프레임을 다른 값에 연결합니다. 움직임이 외부 진행 소스를 반영해야 할 때 잘 작동하지만, 일회성 트리거 이벤트에는 덜 편리합니다.

refs로 넘어가기 전에 간단한 시각적 비교를 해보겠습니다:

상태 기반 애니메이션에는 refs 사용하기

사용자가 탭하거나 토글하거나 작업을 완료할 때, ref가 일반적으로 더 안전한 도구입니다. 실제 데이터에 따르면 하이브리드 프레임워크를 사용하는 개발자의 68%가 useEffect hooks에서 ref 처리 부주의로 인해 애니메이션 트리거 실패를 보고했으며, 이것이 animation.current.play() 중요한 이유입니다. 이 Capacitor에 초점을 맞춘 실패한 트리거 토론에서 언급했듯이.

이 문제는 하이브리드 앱에만 국한되지 않습니다. 순수 React Native에서도 발생하며, 특히 개발자가 refs를 재생성하거나 마운트 전에 재생을 트리거하거나 애니메이션 호출을 불안정한 effects에 연결할 때 더 흔합니다.

import React, { useRef, useState } from 'react';
import { Pressable } from 'react-native';
import LottieView from 'lottie-react-native';

export function LikeButton() {
  const animationRef = useRef<LottieView>(null);
  const [liked, setLiked] = useState(false);

  const onPress = () => {
    if (!animationRef.current) return;

    if (liked) {
      animationRef.current.play(60, 0);
    } else {
      animationRef.current.play(0, 60);
    }

    setLiked(!liked);
  };

  return (
    <Pressable onPress={onPress}>
      <LottieView
        ref={animationRef}
        source={require('../assets/animations/like.json')}
        loop={false}
        autoPlay={false}
        style={{ width: 96, height: 96 }}
      />
    </Pressable>
  );
}

신뢰할 수 있는 좋아요/좋아요 취소 패턴

이 패턴은 state가 바뀔 때마다 play() 내부에서 useEffect 호출하는 것보다 프로덕션에서 더 안정적입니다.

이유:

이벤트가 애니메이션 트리거를 소유합니다: press 이벤트는 재생을 시작하기에 안정적인 시점입니다.
ref는 로컬에 유지되며 지속됩니다: useRef 불필요한 리렌더링을 방지합니다.
컴포넌트는 autoplay 충돌을 방지합니다: 마운트 동작이 사용자 트리거 동작과 충돌하게 두면 안 됩니다.

피해야 할 흔한 실수:

ref가 존재하기 전에 트리거하는 경우
만약 animationRef.current null이면 재생되지 않습니다. 가드하세요.
사용하기 autoPlay imperative controls 사용 시
재생을 담당할 기본 소유자를 하나만 지정하세요.
모든 것을 구동하는 방식 useEffect
이펙트는 유용하지만, UI 액션의 경우 타이밍 문제를 해결하기보다 오히려 일으키는 경우가 많습니다.

애니메이션이 탭에 반응한다면 먼저 탭 핸들러 안에서 트리거하세요. 다음 경우에만 사용하세요: useEffect 상태의 원천(source of truth)이 해당 인터랙션 외부에 있을 때.

프로덕션 앱 성능 튜닝

Lottie React Native는 처음엔 가벼워 보이지만, 팀에서 대용량 JSON 파일을 앱 bundle에 넣기 시작하면 왜 앱 시작 속도가 느려졌는지 의아해하게 되는 라이브러리 중 하나입니다. 문제는 애니메이션 자체가 아니라, 이를 전달하는 전략에 있습니다.

Lottie 성능 튜닝의 세 가지 핵심 이점을 보여주는 인포그래픽: bundle 크기 감소, 프레임 레이트 향상, 메모리 사용량 절감.

팀들이 흔히 겪는 문제들

가장 하기 쉬운 실수는 모든 애니메이션을 JavaScript에 직접 bundle해 너무 일찍 전부 로드하는 것입니다. Lottie JSON을 잘못 배포하는 방법을 다룬 이 가이드에 따르면,, JS bundle에 Lottie JSON 같은 에셋을 과도하게 넣으면 앱 시작 시간이 중급 기기에서 40% 이상 늘어날 수 있습니다., 그리고 이를 네이티브 에셋으로 이동하여 온디맨드 로딩하는 것이 핵심 최적화입니다.

많은 팀이 실제로 겪는 상황과 일치합니다. 문제는 작은 성공 애니메이션 하나가 아닙니다. 누적된 부하입니다:

온보딩 모션
로더 상태
이커머스 반응 애니메이션
브랜드 스타일의 빈 화면
그 옆에 놓인 로케일 파일 및 기타 번들 용량이 큰 에셋

앱에 이미 스타트업 예산 문제가 있다면, Lottie 파일은 이를 빠르게 악화시킬 수 있습니다.

무엇을 먼저 최적화할까

내보내기부터 시작하세요. 부실한 애니메이션 내보내기는 나중에 파싱, 메모리, 렌더링 안정성에서 대가를 치르게 합니다. 디자이너의 모든 내보내기 파일을 그대로 받아들이지 마세요.

이 프로덕션 체크리스트를 사용하세요:

배포 전 JSON을 압축하세요: 파일이 작을수록 로딩이 쉽고 스타트업 부풀어 오를 가능성이 낮습니다.
비핵심 애니메이션을 JS 번들에서 분리하세요: 앱이 즉시 필요한 것에만 초점을 맞춰 런칭 code를 유지하세요.
애니메이션을 필요할 때 로드하세요: 화면이나 액션이 필요할 때 렌더링하세요.
구형 기기 동작을 감사하세요: 최신 시뮬레이터는 비용이 높은 재생을 가릴 수 있습니다.
앱 시작 장식에 큰 Lottie 파일을 사용하지 마세요: 첫 상호작용에 필수적이지 않다면 앱 로딩과 경쟁해서는 안 됩니다.

진지하게 모바일 성능 최적화를 진행하는 팀이라면 AppLighter의 모바일 성능 가이드 앱 시작, 렌더링, framework 트레이드오프라는 더 큰 맥락에서 애니메이션 결정을 다루므로 유용한 참고 자료입니다.

어려운 진실 하나: 첫 상호작용을 지연시키는 아름다운 애니메이션은 디자인의 승리라기보다 제품 버그인 경우가 많습니다.

React Native를 고립된 상태로만 생각하지 마세요. 하이브리드 스택을 다루는 팀도 비슷한 자산 로딩 문제에 직면하며, 더 넓은 범위의 Capacitor 앱용 애니메이션 성능 가이드 는 Lottie 결정에도 잘 적용됩니다.

로컬 파일 vs 원격 전달

로컬 파일은 예측 가능합니다. 오프라인에서도 작동하고 네트워크 변동성을 제거하며 테스트하기 쉽습니다. 하지만 과도하게 번들링하기也容易합니다.

원격 배포는 바이너리를 더 가볍게 유지하지만, 이제 애니메이션의 가용성, 캐싱, 폴백 문제를 고려해야 합니다. 이 트레이드오프는 비핵심 모션에는 괜찮지만, 구매 확인이나 인증 성공 같은 주요 UX 상태에는 위험합니다.

실무에서는 이렇게 나누면 좋습니다:

에셋 유형	더 나은 기본값
핵심 인터랙션 애니메이션	로컬, 최적화, 과하지 않은 크기
가끔 사용되는 프로모션 모션	폴백이 있는 원격
시작 경로 애니메이션	꼭 필요할 때만 로컬
거의 사용되지 않는 기능 일러스트	요청 시 로드

이 섹션에서 규칙을 하나만 적용한다면, 이걸 적용하세요: Lottie JSON을 그냥 장식이 아니라 성능에 민감한 에셋으로 취급하세요.

자주 발생하는 Lottie 이슈 해결하기

Lottie가 깨질 때 원인은 대개 뻔합니다. 잘못된 경로, 크기 누락, 잘못된 ref 타이밍, 너무 무거운 JSON. 가장 빠른 디버깅 방법은 변수를 줄이는 것입니다.

Android에서 애니메이션이 렌더링되지 않음

먼저 JSON 파일이 제대로 로드되는지 확인하세요. 그다음 컴포넌트에 명시적인 dimensions를 지정하세요.

<LottieView
  source={require('../assets/animations/success.json')}
  autoPlay
  style={{ width: 200, height: 200 }}
/>

그래도 안 된다면, 이미 검증된 다른 애니메이션으로 교체해 보세요. 그러면 문제가 파일 자체에 있는지 설정에 있는지 알 수 있습니다.

구형 기기에서 재생이 끊김

이는 보통 컴포넌트 API이 아니라 에셋 쪽 문제입니다.

다음 해결 방법을 시도해 보세요:

애니메이션 복잡도 줄이기: 원본 파일이 너무 무겁다면 더 가벼운 파일로 다시 export해 달라고 요청하세요.
나중에 로드: 초기 화면 렌더링 작업과 충돌하지 않도록 하세요.
압축된 버전으로 테스트하기: 압축된 파일이 더 잘 작동한다면, 병목 지점을 찾은 것입니다.
Lottie 뷰를 여러 개 동시에 띄우지 마세요: 한 화면에 애니메이션이 여러 개 있으면 과할 수 있습니다.

ref가 null이거나 play가 아무 동작도 하지 않음

Null ref는 보통 트리거가 마운트 전에 실행됐거나 컴포넌트가 조건부로 제거됐다는 뜻입니다.

if (animationRef.current) {
  animationRef.current.play();
}

ref를 안정적으로 유지하려면 useRef, 애니메이션 컴포넌트를 불필요하게 다시 생성하지 마세요. 로컬 빌드에서 반복되는 이상 동작을 디버깅 중이라면, 오래된 캐시를 지우는 것이 도움이 됩니다. 간단한 Yarn 캐시 정리 루틴만으로도 때로는 개발 중 잘못된 에셋 동작을 없애기에 충분합니다.

화면 크기에 따라 애니메이션이 깨짐

애니메이션이 레이아웃을 결정하게 두지 마세요. 컨테이너 안에 넣고 크기를 의도적으로 지정하세요.

아이콘과 리액션에는 고정된 영역을 사용하세요
큰 일러스트레이션에는 비율을 고려한 wrapper를 사용하세요
내보낸 파일의 의도된 구성을 확인하지 않고 전체 너비로 늘리지 마세요.

대부분의 “Lottie가 깨졌다”는 보고는 레이아웃, 에셋, 또는 타이밍 문제에서 비롯됩니다. 라이브러리는 요청한 대로 정확히 작동하는 경우가 많습니다.

최종 디버깅 단축키가 필요하면 모든 고급 prop을 제거하고, 중앙 정렬된 뷰에서 로컬 애니메이션 하나만 렌더링한 뒤 거기서부터 다시 구성해 보세요. 이 접근법은 복잡한 프로덕션 화면을 주시하는 것보다 문제를 훨씬 빠르게 분리할 수 있습니다.

Capgo는 스토어 리뷰를 기다리지 않고 Capacitor 앱에 JavaScript, 에셋, 설정 수정 사항을 배포하는 데 도움이 됩니다. 하이브리드 앱을 유지 관리하면서 업데이트를 더 안전하게 푸시하고, 단계적 롤아웃을 처리하며, 프론트엔드 문제를 빠르게 복구해야 한다면, Capgo 한 번 살펴볼 가치가 있습니다.