원문: https://github.com/facebook/astryx/wiki/Animation-System · 번역 기준: 2026-09-03

Status: Design exploration. 오늘 존재하는 것은 기본 transition token뿐입니다. 이 스펙은 전체 애니메이션 시스템의 청사진입니다. 여기 있는 것 중 아직 구현된 것은 없습니다 — 애니메이션 작업이 시작될 때를 위한 목표 디자인을 담은 것입니다.

Exploration, 2026년 1월

배경

Astryx의 핵심 아키텍처는 제약을 enforcement합니다: zero styling, 테마 주도 token, 타입이 있는 API. 이 exploration은 애니메이션이 그 제약 기반 모델에 어떻게 들어맞는지 검토합니다.

질문은 "어떤 애니메이션 라이브러리를 써야 하는가?"가 아니라 "임의 값 금지, source of truth로서의 테마, 제약을 통한 AI 친화성이라는 Astryx의 철학에 애니메이션이 어떻게 통합되는가?"입니다.

가정: 이 문서는 Astryx가 스타일링에 StyleX를 사용한다고 가정합니다(Why StyleX 참고). 애니메이션 구현은 StyleX의 컴파일 타임, 제로 런타임 철학과 정렬됩니다.

핵심 원칙

애니메이션은 스타일링의 형제입니다. 같은 규칙이 적용됩니다.

Astryx 원칙 애니메이션 적용
Zero-styling: 인라인 스타일 없음, style prop 없음 Zero animation code: animate={{}} 없음, transition prop 없음
Source of truth로서의 테마 애니메이션 config는 theme.motion에 위치
Prop은 스타일이 아니라 의도를 정의 open={true}는 의도를 표현하고, 애니메이션은 구현 세부사항
타입이 있는 제약된 API 애니메이션 타입은 임의 값이 아니라 enum (`'fade' \
Edge case를 위한 swizzle 애니메이션 동작을 override하려면 컴포넌트를 swizzle
제약을 통한 AI 친화성 AI는 <Dialog open>을 작성하고, 애니메이션에 대해 아무것도 모름 
// What developers write:
<Dialog open={isOpen}>
  <DialogTitle>Confirm</DialogTitle>
  <DialogContent>Are you sure?</DialogContent>
</Dialog>

// Animation just happens (configured in theme)

애니메이션 라이브러리 대신 CSS인 이유

AI는 Motion이든 StyleX든 어느 쪽으로든 애니메이션을 쉽게 구현할 수 있습니다. 질문은 트레이드오프가 의존성 추가를 정당화하느냐입니다.

CSS / StyleX Motion (motion/react)
Enter 애니메이션 ✅ @starting-style이 처리 ✅ initial → animate
Exit 애니메이션 ⚠️ Custom unmount delay 필요 ✅ AnimatePresence로 공짜
Gesture 애니메이션 ⚠️ 더 장황하고 수동적 ✅ First-class drag/swipe
Spring physics ⚠️ Cubic-bezier 근사 (또는 직접 구현하지만 그럴 거면 왜 Motion을 안 쓰나?) ✅ 진짜 spring
번들 크기 ✅ 0KB ⚠️ ~18KB
철학 적합성 ✅ 컴파일 타임, 런타임 없음 ⚠️ 런타임 JS

솔직한 평가: