LottieFiles for Figma 플러그인을 에셋을 찾고 내보내는 도구에서, 모션을 만들고 문제를 확인하며 실제 제품에 전달하는 창작 도구로 확장, 이를 알기 쉽게 공유하며 플러그인 성장을 주도했습니다.
피그마 → 로티 모션을 성공적으로 변환 & 저장하는 UX, 새로운 로티 스펙과 피그마 연동, 대시보드, 로티 크리에이터, 실제 적용 환경 등 플러그인 밖 환경과의 유기적인 연결 등 플러그인 전반의 UX를 설계했어요.
2024년 당시, 피그마 유저는 이미 여러 프레임과 프로토타입 연결로 움직임을 표현하고 있었습니다. 그런데 이를 실제 제품에서 재생되는 애니메이션으로 만들려면 별도의 모션 도구와 키프레임 베이스 작업 방식을 다시 배워야 했어요. 로티파일즈 플러그인은 별도의 러닝커브 없이 피그마 유저의 프레임 단위 작업 방식을 존중하면서 애니메이션을 만들 수 있게 해서 많은 유저들의 사랑을 받고 있었어요. 선택한 프레임으로 모션을 만들고, 미리 보고, Lottie로 내보내도록 했죠.
다만 피그마 유저의 익숙한 작업 방식에서 시작한다고 로티와 피그마 프로토타입의 기술적 차이까지 사라지지는 않았습니다. 가장 어려웠던 건 프레임 사이의 레이어 구조를 로티로 옮기는 문제였어요.
유저는 피그마 캔버스에서 프레임을 편집하면서 자연스럽게 여러 프레임을 복제하며 애니메이션 작업을 이어갑니다. 마치 프로토타입 플로우를 만들듯이요. 그 과정에서 유저는 특정 프레임에만 레이어를 추가하거나, 아예 새로운 프레임을 플로우에 추가하기도 하고, 로티에서 지원하지 않는 피그마 기능을 자유롭게 활용하기도 해요. 하지만 막상 로티로 변환하려면 여러 프레임의 레이어가 통일된 상태로 보여져야 했는데요. 플러그인은 그렇게 연결이 끊긴 프레임 사이를 완전히 대응하지 못하고, 구조가 다르거나 인식하지 못하는 값을 받으면 애니메이션 결과 대신 실패 화면을 보여주는 상황이었어요. 유저가 많은 만큼, 2024년부터 2025년 12월 개선 배포 전까지 월평균 약 2만 건의 렌더 실패가 일어나고 있는 심각한 상황이었습니다.
피쳐체커를 설계하며 세운 기준을 플러그인 전체에도 적용했습니다. 사용자가 Figma에서 이미 표현한 의도를 읽고, 필요한 로티 기능으로 연결하는 것이었어요. 이미 플러그인 Explore 탭에서는 커뮤니티의 애니메이션을 찾고 활용할 수 있었고, 직접 그래픽을 준비하려는 사용자에게는 Raster to Vector 와 Prompt to Vector를 Tools 의 하위 탭으로 제공하고 있었어요.
그런데 tools 속에 숨어있다보니 유저가 기능의 존재를 알지 못하고 지나치는 경우가 많았습니다. 저는 이러한 AI 기능이 플러그인을 연 원래 목적을 방해하지 않는 선에서 맥락적으로 노출하려고 했어요. 예를 들어 피그마에서 이미지 레이어를 선택했을 때 Vectorize를 주요 행동으로 보여줘, 첫 화면에서 특정 조건을 만족한 경우 바로 Raster to Vector 툴의 가치를 발견하고 작업을 시작할 수 있게 했거든요. 이 과정에서 벡터 변환 자체를 찾는 사용자와 기존 LottieFiles 플러그인에 진입한 사용자의 멘탈 모델이 다르다는 사실에 착안해, AI Vectorizer를 독립 플러그인으로 빠르게 출시해 기존 모션 작업 흐름을 유지하면서도 벡터 변환을 위한 별도의 SEO & 진입점을 만들기도 했어요. 결과적으로 피그마 플러그인 카니발 없이 추가 유저를 더 많이 모을 수 있게 되었고요.
같은 Export 버튼을 눌러도 사용자가 준비한 디자인은 다릅니다. 여러 프레임으로 모션을 만들기도 하고, 프로토타입에 인터랙션을 연결하거나 변수와 컴포넌트로 재사용할 디자인을 구성하기도 해요. 저는 이러한 작업 맥락을 플러그인에서 다시 입력하게 하기보다, 이미 설정된 정보를 인식해 관련 기능으로 연결하도록 설계했습니다. 프레임의 움직임은 Figma Motion으로, 프로토타입 인터랙션은 State Machine으로, 변수에 담긴 값은 Motion Tokens와 테마 플로우로 이어지게 했어요. 그 과정에서 로티로 옮길 수 없는 요소는 검사 결과로 알려주고, 수정할 레이어로 바로 이동할 수 있게 했습니다. 사용자는 새로운 기술의 설정 화면보다 자신의 디자인과 실제 애니메이션 프리뷰를 중심으로 작업을 이어갈 수 있게 했습니다.
모든 편집과 관리 기능을 플러그인에 담으려 하지는 않았습니다. Figma보다 세밀한 모션 편집이 필요하면 Lottie Creator로, 저장한 애니메이션의 버전 관리와 CDN 배포가 필요하면 웹 워크스페이스로 이어지도록 했어요.
핵심은 플러그인 안에서 모든 일을 끝내게 하는 것이 아니었습니다. Figma에서 시작한 디자인을 반복해서 설명하거나 다시 만들지 않고, 작업의 깊이와 목적에 맞는 도구에서 계속 활용할 수 있게 하는 것이었어요.
결과적으로 이러한 다양한 경험 개선을 통해 현재 유저는 피그마에서 만든 디자인을 로티파일즈 플러그인을 통해 프로덕션에 사용가능한 형태로 변환할 수 있게 되었고, 단일 플러그인의 이용자는 65만에서 100만으로 약 54% 성장했어요. 유저당 로티 애니메이션 저장 수는 2.07회에서 3.18회로, 종전 대비 50% 이상 늘었습니다.
팀에 상황을 공유하고 2가지를 물어봤어요.
최종 목표는 이러한 문제점과 렌더 오류를 숨기는 것이 아니라, 이유를 알 수 없는 실패를 최소화하고 궁극적으로 유저 스스로 해결할 수 있는 문제로 바꾸는 것으로 잡았습니다.
이를 제대로 해결하기 위해, 저는 정확히 어떤 상황에서 렌더링이 실패하는지 알고 싶었어요. 그래서 수십 회에 달하는 온, 오프라인 커뮤니티 세션과 기업 온보딩을 진행하며 반복되는 실패 사례를 모으고, 베스트 프랙티스를 정의, 문서화했고, 팀내 개발자들과 기술을 검토하며 검사할 조건을 샘플과 함께 문서로 정리했습니다. 레이어 구조뿐 아니라 이너 섀도우 등 로티 스펙에서 지원하지 않는 피그마 이펙트도 검사와 안내의 대상으로 삼았어요. 그 과정에서 완전한 렌더 실패가 아닌 부분 렌더가 가능한 곳들은 모두 열어두었고요. 문제가 있는 레이어의 이름을 보여주고, 클릭하면 해당 레이어가 선택되도록 설계했어요. 사용자가 파일 전체를 뒤지지 않고 수정할 곳으로 바로 이동해 스스로 고치게 했습니다.
피쳐체커 릴리스 노트2025년 12월 배포 직후부터 실패 건수는 급감해, 현재까지 월평균 50건 미만으로 줄어들었어요. 여기에는 개발팀이 부분 렌더링을 허용하고, 기존의 일부 실패를 미지원 요소 감지와 안내로 전환한 개선이 포함됩니다. 유저는 인지하지 못한 채 사용한 로티 미지원 스펙이나 레이어 불일치를 '렌더 실패'라는 극단적인 결과가 아닌, 스스로 쉽게 해결할 수 있는 형태로 마주하고 고칠 수 있게 되었어요.
