애니메이션 툴을 바꾼다고 해서 사용자 반응이 달라질까요? 저는 반신반의하면서 Lottie를 버리고 Rive로 갈아탔고, 결과적으로 NPS가 6에서 9로 뛰었습니다. 도구 하나가 그 차이를 만들었다기보다, 상태 기계(State Machine)라는 개념이 인터랙션 설계 방식 자체를 바꿔놓은 겁니다. 이 글은 그 경험을 토대로 Rive 상태 기계의 구조와 실무 적용법을 논리적으로 풀어봅니다.
상태 기계 입문: 노드와 트랜지션의 구조
Rive의 애니메이션 작업은 타임라인(Timeline) 방식과 상태 기계(State Machine) 방식으로 나뉩니다. 타임라인은 Lottie와 비슷하게 프레임 단위로 움직임을 정의하는 방식입니다. 반면 상태 기계는 각 애니메이션을 하나의 '상태(State)'로 보고, 상태 간 전환 조건을 설계하는 방식입니다. 쉽게 말해, 캐릭터가 '대기 중인지', '클릭됐는지', '축하 중인지'를 노드(Node)로 나누고 그 사이를 화살표로 연결하는 구조입니다.
제가 직접 써봤는데, 처음에는 이 노드 그래프 방식이 낯설었습니다. Lottie에서는 그냥 JSON 파일을 넘기면 끝이었으니까요. 하지만 사용자 입력에 반응하는 애니메이션이 필요해지는 순간, Lottie는 한계가 명확했습니다. 버튼을 눌렀을 때 다른 애니메이션으로 전환하거나, hover 상태를 별도로 정의하는 것이 구조적으로 불가능했습니다.
Rive 상태 기계의 기본 구조를 정리하면 다음과 같습니다.
- Entry State: 상태 기계가 시작될 때 자동으로 활성화되는 진입점으로, 오직 시작 시점에만 한 번 쓰입니다.
- Any State: 현재 어떤 상태에 있든 관계없이 특정 조건이 충족되면 전환을 실행하는 특수 노드입니다.
- Exit State: 상태 기계를 종료할 때 사용하는 탈출점입니다.
- Transition(트랜지션): 상태와 상태를 잇는 화살표로, 조건(Condition)과 Exit Time을 지정할 수 있습니다.
여기서 Exit Time이란 현재 재생 중인 애니메이션이 일정 비율 혹은 특정 시간까지 진행된 후에야 다음 상태로 전환되도록 제어하는 속성입니다. 100%로 설정하면 애니메이션이 끝까지 재생된 뒤에야 전환이 일어납니다. 제 외주 프로젝트에서 캐릭터 클릭 반응이 도중에 끊기는 문제가 있었는데, Exit Time 100%를 적용하고 나서야 깔끔하게 해결됐습니다.
세 가지 Input 타입과 실무 선택 기준
Rive 상태 기계에서 트랜지션을 제어하는 방법은 Input(인풋) 타입에 따라 달라집니다. 타입은 세 가지입니다.
트리거(Trigger)는 버튼처럼 한 번 발동하고 사라지는 단발성 입력입니다. 포탄 발사 애니메이션처럼 "한 번 재생하고 끝"인 구조에 적합합니다. 불리언(Boolean)은 true/false 두 값만 가지는 토글형 입력입니다. 여기서 불리언이란 참(true) 또는 거짓(false) 두 상태만 가지는 논리값을 의미합니다. 메뉴 아이콘이 화살표로 바뀌었다가 다시 메뉴로 돌아오는 토글 인터랙션에 딱 맞습니다. 넘버(Number)는 임의의 숫자 값을 조건으로 쓰는 입력입니다. 여러 상태를 숫자로 매핑해서 하나의 인풋으로 네 개 이상의 상태를 제어할 수 있습니다.
솔직히 이건 예상 밖이었습니다. 처음엔 트리거만 써도 충분하다고 생각했는데, 로그인 캐릭터 컴포넌트를 만들면서 대기·타이핑·성공·실패 네 가지 상태를 하나의 넘버 인풋으로 제어하자 코드 쪽 연동이 훨씬 단순해졌습니다. 외주 클라이언트 개발자도 "이게 이렇게 깔끔할 줄 몰랐다"는 반응이었습니다.
트랜지션 속성에서 Duration(지속 시간)과 커브(Interpolation Curve)를 설정하면, 타임라인에 키프레임을 촘촘히 박지 않아도 상태 기계 안에서 자연스러운 보간 애니메이션을 얻을 수 있습니다. 여기서 보간(Interpolation)이란 두 상태 사이의 값을 시간 흐름에 따라 부드럽게 채워주는 수학적 처리를 의미합니다. 선형(Linear), 큐빅(Cubic), 엘라스틱(Elastic) 등의 커브를 선택할 수 있고, 키프레임 수를 최소화하면서도 풍부한 움직임을 만들 수 있다는 게 Rive가 Lottie 대비 갖는 실질적 강점입니다.
Figma 디자인 시스템과 .riv 파일 동기화 워크플로우
일반적으로 Rive는 단독 애니메이션 툴로만 쓰인다고 보는 시각도 있는데, 제 경험상 이건 좀 다릅니다. 디자인 시스템과 연동하면 디자이너가 개발자 없이도 애니메이션을 운영할 수 있는 구조가 됩니다.
제가 정립한 워크플로우의 핵심은 Figma 컴포넌트와 .riv 파일의 상태를 1:1로 매핑하는 것입니다. 예를 들어 Figma에서 버튼 컴포넌트의 상태가 Default, Hover, Pressed, Disabled 네 가지라면, .riv 파일의 상태 기계 노드도 동일하게 idle, hover, press, disabled 네 개로 구성합니다. 네이밍 컨벤션을 통일하면 개발자가 Rive의 런타임 API로 상태를 호출할 때 Figma 스펙 문서를 별도로 참조하지 않아도 됩니다.
여기서 런타임 API란 웹이나 앱 환경에서 .riv 파일을 실제로 실행하고 상태를 코드로 제어하기 위한 프로그래밍 인터페이스를 의미합니다. Rive는 Web, Flutter, React Native, iOS, Android용 런타임을 공식 제공합니다(출처: Rive 공식 문서).
이 워크플로우를 도입한 뒤 디자이너 단독으로 .riv 파일을 수정하고 업데이트할 수 있게 됐습니다. 개발자에게 매번 "이 애니메이션 조금만 바꿔주세요"를 요청하는 사이클이 사라진 겁니다. 외주 특성상 빠른 수정이 곧 비용 절감인데, 이 구조가 실질적인 차이를 만들었습니다.
.riv 파일 크기도 중요한 변수입니다. 제가 가이드로 정해둔 임계값은 150KB입니다. 이를 초과하면 모바일 환경에서 초기 로딩 지연이 체감될 수 있습니다. 국내 모바일 평균 웹페이지 로딩 시간은 3초 이상이면 이탈률이 급격히 상승한다는 분석이 있는 만큼(출처: Google PageSpeed Insights), 파일 크기 관리는 퍼포먼스 측면에서 놓쳐서는 안 되는 부분입니다.
재사용 가능한 Rive 컴포넌트 라이브러리 구축 전략
Rive 상태 기계를 프로젝트마다 처음부터 다시 만드는 것은 시간 낭비입니다. 제 경우에는 외주 2건에서 공통으로 쓸 수 있는 컴포넌트 6종을 라이브러리로 정리해두었고, 이게 실제로 견적 협상에서 강점이 됩니다. "비슷한 컴포넌트가 이미 있어서 빠르게 납품 가능합니다"는 말이 클라이언트 입장에서 꽤 설득력 있게 들립니다.
제가 관리 중인 컴포넌트 목록은 다음과 같습니다.
- 캐릭터 반응(대기·hover·클릭·축하 4노드 구조)
- 로그인 캐릭터(타이핑 감지 연동 포함)
- 로딩 풍차(루핑 애니메이션 + 완료 트랜지션)
- 축하 비주얼(트리거 기반 단발 재생)
- 인터랙티브 버튼(불리언 토글 구조)
- 튜토리얼 캐릭터(넘버 인풋 기반 단계 전환)
각 컴포넌트는 .riv 파일 크기 150KB 이하, 상태 이름 Figma 컴포넌트와 1:1 매핑, 런타임 API 호출 방식 문서화 세 가지 기준을 충족하도록 관리합니다. 이 기준이 없으면 컴포넌트를 재사용할 때 오히려 수정 공수가 더 들기 때문입니다.
Rive 상태 기계가 국내에서 주목받아야 하는 이유는 시장 수요와도 연결됩니다. 국내 게임·교육·헬스케어 앱에서 인터랙티브 캐릭터를 활용한 UX 설계가 빠르게 늘고 있습니다. 한국 모바일 앱 시장에서 사용자 경험 품질이 리텐션(Retention)과 직결된다는 사실은 이미 여러 데이터가 뒷받침합니다. 여기서 리텐션이란 앱이나 서비스에 사용자가 다시 돌아오는 비율을 의미하며, 단순 설치 수보다 실질적인 서비스 성장을 보여주는 지표로 쓰입니다.
Rive 상태 기계는 도구 그 자체보다 그것을 디자인 시스템, 컴포넌트 전략, 파일 관리 기준과 함께 묶어야 진짜 위력을 발휘합니다. 영상에서 다루는 인터페이스 조작법은 시작점이고, 실제 실무에서는 Storybook에 .riv를 등록하는 방법이나 Figma 동기화 워크플로우까지 함께 설계해야 재사용 가능한 자산이 됩니다. Rive를 처음 도입하려는 분이라면 트리거 인풋 하나로 간단한 캐릭터 반응부터 만들어보는 것을 권합니다. 노드 그래프가 눈에 들어오기 시작하면, 그 다음은 생각보다 빠르게 확장됩니다.