▲

Lottie는 애니메이션 벡터 그래픽스를 위한 오픈 포맷임

 (lottie.github.io)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Lottie는 벡터 그래픽 애니메이션을 위한 오픈 파일 포맷으로, Adobe After Effects에서 만든 애니메이션을 웹과 모바일에서 쉽게 재생할 수 있게 해줌
  • 애니메이션은 JSON 포맷으로 저장되어, 키프레임, 이징 커브, 레이어 정보 등 모든 애니메이션 요소를 담고 있음
  • 이 포맷은 확장성, 해상도 독립성, 다양한 렌더러 구현 등을 갖춘 개방형 표준으로, 수많은 기업들이 사용자 경험 향상에 활용 중
  • Lottie Animation Community (LAC)는 Linux Foundation 산하의 비영리 오픈소스 프로젝트로, 이 포맷을 업계 표준으로 발전시키는 것을 목표로 함
  • 스펙 명세, 검증 도구, 구현체, 로드맵 등이 커뮤니티에 의해 개발·공개되며, 누구나 참여할 수 있는 투명하고 협력적인 구조로 운영 중

Lottie는 무엇인가

개요

  • Lottie는 2015년 Hernan Torrisi에 의해 개발된 오픈소스 벡터 애니메이션 포맷
  • After Effects에서 만든 애니메이션을 Lottie JSON 파일로 내보내어 다양한 플랫폼에서 재생 가능
  • 현재는 웹, 모바일, TV 등 다양한 플랫폼에서 광범위하게 사용되는 표준적인 포맷

특징

  • 벡터 그래픽 기반
    • 픽셀 기반이 아닌 기하학적 도형(선, 곡선 등) 으로 구성되어 해상도에 무관하게 선명한 이미지 표현 가능
  • 트위닝(Tweening)
    • 애니메이터가 정의한 키프레임 간의 변화를 자동으로 보간(interpolate)하는 방식
    • 복잡한 모션을 수동으로 만들지 않아도 부드러운 애니메이션 연출 가능
  • JSON 기반 포맷
    • JSON으로 표현되어 있어 웹에서 전송이 쉽고, 기존 툴로 편집하거나 자동화 처리하기 용이
    • 열린 표준이므로 누구나 구현체를 만들 수 있고, 상호 운용성이 뛰어남
  • 성숙한 생태계
    • 플레이어, 에셋, 제작 도구, 라이브러리 등 다양한 에코시스템이 잘 구축되어 있음
    • Airbnb, Google 등 수많은 기업들이 사용 중이며, 다양한 툴과 프레임워크에서 지원됨

Lottie Animation Community (LAC)

  • Lottie의 표준화와 보급을 위해 Linux Foundation 산하에 설립된 비영리 커뮤니티
  • Lottie 파일 포맷을 크로스 플랫폼 애니메이션 표준으로 확립하는 것을 목표
  • Joint Development Foundation의 거버넌스 하에 운영되며, 열린 협업 방식을 지향
  • 명확한 스펙 문서, 검증 도구(Validator), 구현체 목록, 로드맵 등을 통해 생태계 기반 제공
  • 누구나 참여하고 기여할 수 있는 구조로, 투명성과 커뮤니티 주도의 발전을 강조
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • Lottie를 사용할 때마다 아쉬움이 남는 이유는, 아이디어는 정말 멋지고, 애니메이터들이 이미 사용하는 툴에서 바로 애니메이션을 추출할 수 있다는 점이 매력적이지만, 구현 방식이 너무 실망스럽기 때문임. 이 분야에서는 훨씬 더 컴팩트한 바이너리 형식이 훨씬 적합한데, 수치 데이터 덩어리를 굳이 JSON으로 저장함. 또 JSON이 외부 파일을 참조할 수 있어서, 실제로는 여러 파일이 폴더에 담겨 있거나, 파일들이 base64로 JSON 안에 인라인되거나, 혹은 전체가 압축된 하나의 파일로 제공됨. 웹에서 로드하면, 엄청난 용량의 SDK를 불러와야 하고, 이 애니메이션은 여러 파일을 따로따로 불러오거나, 아니면 하나의 파일을 여러 번 다양한 파서(JSON, base64, png, lottie, zip 등)로 처리해야 함. .lottie 파일을 사용하면 JS 번들에 zip 디컴프레서까지 포함해야 하고, 별도의 .lottie 플레이어는 2MB wasm blob을 포함하는데, 왜 그런지 잘 모르겠음. 우리 앱에서는 이것 때문에 앱 용량 줄이느라 엄청 고생했고, 다행히 핵심 경로에서는 사용하지 않았기 때문에 이 정도로 정리함. 애니메이션 최적화, 경로와 인라인 문제 수작업 수정, 벡터가 png로 바뀌는 버그 처리 등 많은 삽질이 필요했음. 게다가 브라우저는 여러 개의 애니메이션을 동시에 재생하면 잘 버티지 못하는데(특히 저사양 기기에서), JS와 DOM에서 애니메이션 처리 효율이 생각보다 안 좋았음. 주말 프로젝트로 시간 나면, 이걸 최적화된 SVG 스프라이트로 변환해서 CSS 트랜지션으로 재생하면 좀 더 나아지는지 실험해볼까 하는 생각이 있음

    • 정말 공감하며, After Effects에서 Lottie로 내보내는 작업 흐름이 특히 끔찍했음. 많은 레이어와 스타일이 내보내기에서 제대로 동작하지 않기 때문에, 모션 디자이너에게 어떤 기능을 써야 하고 어떤 기능은 쓰지 말아야 하는지 하나하나 설명해야 했고, 이 부분을 디자이너들이 좋아하지는 않음. 사실 단순히 비디오로 렌더링해서 상호작용에 맞게 재생하는 게 오히려 훨씬 가볍고 작업량도 적었음. Rive에 대해서도 들어본 적이 있고, 이쪽은 Lottie의 문제점을 보완하는 방식에 집중하는 것 같음. 다만 아직 직접 써보진 않아서 결과는 케바케일 수 있음

    • 전에 다녔던 회사에서 웹앱 번들 크기가 8MB(압축하면 약 2MB)였는데, 잡아보니 대부분이 Lottie 라이브러리(2MB)와 단 네 개의 애니메이션 때문이었음. 이중 두 개 애니메이션을 제거하고, 나머지는 Lottie와 함께 지연 로딩으로 처리했음. 그래도 디자이너나 다른 개발자에게 번들 8MB가 얼마나 큰 문제인지 설득하지 못해서 결국 이 싸움은 진 것 같은 기분임

    • 브라우저가 Lottie 애니메이션 여러 개를 동시에 재생할 때 잘 버티지 못한다는 부분에 동의함. 2000년대 초반에도 애니메이션 Flash 광고로 도배된 웹페이지가 많았는데, 성능 이슈도 있었지만 당시의 단일 코어 CPU로도 충분히 돌아갔음

    • 반면에, JSON 형식은 압축하면 매우 작아지고 자바스크립트 VM에 로드하는 효율도 좋은 편임

    • 내가 Lottie를 써봤을 때 선택지는 mp4와 Lottie 사이였음. mp4와 비교할 때 Lottie가 훨씬 작았음

  • 오픈된 공통 포맷으로 애니메이션을 관리하는 방식이 마음에 듬. 하지만 실제로 웹 개발자들이 CSS나 SVG 애니메이션(훨씬 더 작고 쉽게 조정 가능함)을 더 공부하기보다, Lottie(라이브러리/래퍼만 해도 몇백 KB는 추가, 애니메이션별 추가 용량도 큼)를 너무 손쉽게 선택하는 아쉬움이 있음. Lottie 메인 사이트에서 파일이 작다고 자랑하는데, GIF나 PNG만 비교 대상으로 삼고, SVG/CSS 애니메이션과는 비교하지 않는 점도 마음에 들지 않음. 다만 네이티브 모바일 앱에서는 꽤 잘 어울릴 것 같음

    • Lottie의 핵심 의의는 CSS 트랜지션처럼 단순한 애니메이션이 아니라, 훨씬 복잡하고 자유로운 애니메이션(작은 만화같은 느낌)에 있음. 텔레그램 메신저에서 Lottie로 만든 움직이는 스티커(예시: https://tlgrm.eu/stickers/Princess)를 보면 잘 알 수 있음

    • 실제로 경험상 Lottie가 가장 빛을 발하는 곳은 디자인 저작 툴(특히 After Effects)에서의 타겟 포맷임. 첨부된 기사에서도 바로 이 지점이 Lottie와 파일 포맷의 원래 장점으로 언급되고 있음. 아무도 이걸 직접 손으로 작성하지 않음. 나는 모바일 앱 개발자로 Lottie 애니메이션을 다룬 적은 있지만, 직접 제작자는 아니었음

    • “CSS나 SVG 애니메이션을 더 배워야 한다”는 말에 대해 의견을 보태자면, Web 1.0의 Flash가 최고였음. CSS 및 다른 표준들이 Flash가 제공하던 경험을 아직도 제대로 따라오지 못하고 있음. Flash는 비디오 포맷, 애니메이션 포맷, 프로그래밍 환경, 비디오 플레이어, 대화형 UI 시스템, 게임 엔진, MMO 개발 엔진, 인포그래픽 툴 등 정말 다 되는 만능 도구였음. Adobe가 포맷과 플레이어를 오픈했다면 지금까지 살아남았을 것임. CSS/SVG/HTML/JS가 유일한 길이라는 고정관념을 깨야 하고, 40년이 지났지만 여전히 비슷한 문제를 겪는다는 걸 보면, 바퀴를 다시 발명해보는 시도가 필요함

    • Lottie 애니메이션을 SVG+JS로 컴파일하는 것도 가능하지 않을까? 이런 툴이 없을 뿐이라는 생각임

    • CSS 애니메이션(그리고 최신 Web Animations API)은 하드웨어 가속이 가능한 반면, 이런 라이브러리들(Lottie 등)은 그렇지 않음

  • Lottie와 Rive 둘 다 임베딩 및 구현 측면에서 최소한의 경험이 있는데, Rive가 훨씬 더 나은 경험이었음. 혹시 미래에 Lottie와 Rive 중 선택해야 할 때 내가 놓친 부분이 있는지 궁금함

    • Rive는 직접 써본 적은 없고 추이를 지켜보고 있음. Lottie를 만든 개발자가 2년 전쯤 Rive 팀에 합류했다는 사실이 흥미로움. 이 분야에서 신규 도구를 평가할 때 Rive를 꼭 고려할 것임. 내가 몸담은 프로젝트에서는 디자이너가 원하는 애니메이션에 비해 Lottie의 파일 크기를 정당화하기 어려워 적극적으로 반대했었음. SVGator도 성공적으로 써본 적 있음. Lottie가 파일 크기에 대한 언급 없이 많은 곳에서 과대홍보(특히 Webflow같은 툴, 업계 인플루언서 등)되는 것도 답답하기 때문에, Lottie에 딱 맞는 사용처가 분명히 있겠지만, 대부분의 일반적인 용도에는 더 나은 선택지가 존재한다고 생각함

    • Rive라는 도구를 들어본 적 없었는데, 내 프로젝트에 활용 가능한 것 같아서 흥분되는 발견임. 이런 정보 때문에 HN을 멈출 수 없음

  • 우리 회사 UI 라이브러리는 animated component(스피너, 프로그레스 바 등)에 lottie-web을 사용함. 그런데 https://airbnb.io/lottie/#/community-showcase 페이지를 방문하면 회사 노트북의 팬이 미친 듯이 돌아감. 만약 CSS로 만들었다면 이런 영향이 없었을 거라는 생각임

    • 그 페이지에 있는 것은 모두 애니메이션 GIF임

  • Lottie의 컨셉은 정말 멋지지만, 실제로 사용해보면 작업하기 아주 어려움. Rive는 Lottie에서 문제였던 부분을 해결하려는 새로운 플랫폼임. 특히 동적 데이터 업데이트는 Lottie에서는 사실상 불가능에 가까움. 그래도 우리는 Lottie로 Tracker.GG의 Valorant Backtrack(Spotify Wrapped와 유사한 포맷)에서 동적으로 데이터 업데이트되는 애니메이션을 구현했음(데모: https://tracker.gg/valorant/backtrack/…). 이를 위해 소스 파일(After Effects)에서 이름 붙여진 레이어를 직접 접근했고, 각 슬라이드가 별도의 Lottie 파일이 되도록 해서 슬라이드 간 자연스러운 전환을 수작업으로 구현했음. Lottie 자체에는 동적 레이어 접근이 기본적으로 지원되지 않아서 별도의 라이브러리로 Lottie 인스턴스를 제어하고, 그 위에 자체 데이터 컨트롤 레이어를 만듦. 디자이너와 엔지니어 사이에서 반복된 수많은 작업이 필요했고, 협업에 불리한 포맷임. 어떤 경우에는 레이어 속성을 실제 기본값(예: 색상)으로 타겟팅하는 수법도 써야 했음. 포맷 자체가 정말 다루기 힘듦. 앞으로는 Rive를 사용해보고 싶음

  • 우리는 PBS KIDS 브랜드 애니메이션에 수년간 Lottie를 사용 중임. 다른 포맷에 비해 다양한 장점이 있고, 2D 평면에서 런타임 렌더링이 많아지면 성능 저하가 있지만, 여러 파이프라인(게임, 앱, 비디오)에 모두 무난히 통합됨. 상대적으로 저사양 기기/플랫폼(Roku 등)에는 정적인 이미지를 대체로 제공함. After Effects와의 워크플로우 덕분에, 한 명의 디자이너가 루프되는 애니메이션을 만들면 Lottie/Bodymovin json, Mov(방송/유튜브용), SVG(저사양용)까지 모두 내보낼 수 있음. Flash 이후 아주 좋은 임시 대체 포맷이었음. 이제는 Rive도 활용하고 있고, 기존 json 애니메이션을 새로운 워크플로우에도 가져올 수 있음. 내가 이 분야의 핵심 인물(예: Pixi의 Mat Groves, CloudKid의 Matt Karl 등)과 협업해보았는데, Flash 전환기에 모두가 서로 다른 방식과 플러그인, 수학, 내보내기 포맷을 시도했었음. 이런 각각의 노력은 나름의 위치가 있고, 타임라인 기반 애니메이션의 소프트웨어 구조상 포맷 간 상호운용성 문제는 늘 존재함. 결국 프로젝트에 가장 적합한 툴을 선택하는 게 중요함

  • 우리 사이트(https://resonancy.io)의 애니메이션을 만들기 위해 lottielab을 썼고, 에디터는 정말 SVG기반으로 잘 만들어져서 온라인 툴 중 최고였음. 전체적으로 부드러운 경험이었음. 하지만, lottielab의 독점 압축 호스팅 서비스로 내보내지 않으면 애니메이션 용량이 너무 커서 랜딩페이지에 쓰기 거의 어려웠음. 압축 호스팅이 평균적으로 400% 용량을 줄여주어서 결국 월 30달러를 내고 호스팅함. 대안 포맷을 찾을 것이지만, 다시 애니메이션 제작 과정을 반복하고 싶지는 않음. 과거에 리액트 기반 애니메이션 라이브러리를 써본 경험으로는 복잡한 애니메이션을 직접 짜는 게 너무 힘들었는데, lottielab에서는 상상한 대로 상대적으로 쉽게 만들 수 있었음. Rive는 아직 써보지 않았지만 시험해볼 계획임. Lottie 포맷 압축을 잘해주는 외부 도구나 라이브러리 추천받고 싶음

  • SWF는 왜 문제인지 모르겠음. 사양도 공개되어 있고, 매우 효율적임. 보안 걱정이 많으면 Turing 완전한 고급 기능만 빼고도 구현 가능함. 형제 댓글의 “또 다른 JSON 포맷일 뿐”이라는 평에 동의함. 비효율적인 웹 환경에 젖어든 개발자 세대가 효율이라는 개념 자체를 잊어버린 느낌임

  • 오늘날 애니메이티드 벡터 그래픽 생성의 SOTA(최신 기술)는 무엇인지 궁금함. LLM은 SVG 경로를 미적으로 잘 그리지 못하고, diffusion 기반 이미지 모델도 비트맵만 지원함. After Effects와 결합된 생성AI Illustrator 수요가 큰데, 누군가 혁신적인 시도를 하길 기대함

  • Rive(경쟁 서비스)의 문제점은 예술적 관점에서 직관성이 떨어진다는 점임. 펜이나 블롭 도구로 직접 그릴 수 없고, 특정 워크플로우에 맞춰야 하며(대부분 SVG를 임포트), Flash처럼 직관적인 UI와는 거리가 있음. 물론 흥미로운 기능도 많지만, Flash만큼 손쉽고 직관적인 환경은 아님

    • 래스터(비트맵) 이미지도 입력 타입으로 지원함
답변달기